Hallo,

Ich arbeite aktuell an meinem YouTube Kanal zum Thema Informatik. Tatsächlich muss ich zugeben, dass es mich bei meinem vorherigen Beitrag sehr gefreut hat, dass viele auf meinen Kanal aufmerksam geworden sind. Daher, poste ich es hier noch einmal. Ihr seid ja auch meine Zielgruppe Würde mich freuen, wenn ihr mal reinschaut. Ich habe eine Playlist angehangen.

 

Wenn das nicht erwünscht ist, einfach löschen.

Vielen Dank:)

Warum ist das ER-Modell so wichtig für die Implementierungsphase?

Genau das halte ich für falsch. Die Datenbank ist für die Speicherung der Daten zuständig und sie sollte nicht maßgeblich für die Domämenmodelle sein, die wir bei der Implementierung der Domänenlogik benötigen. Ergo: Die Datenbank ist nur ein Detail und sollte nicht im Mittelpunkt der Implementierung stehen. Genau dies versucht man ja mit der Hexagonal Architektur bzw. der Clean Architecture zu korrigieren, indem die Domämenmodelle im Vordergrund stehen.

Gerade in der Informatik ist nichts in Steinen gemeißelt. Das Domämenmodell wird sich in Laufe der Zeit ändern aber es ist sehr aufwendig Spalten in eine relationale Datenbank hinzuzufügen. Es müssen Migrationsskripte, etc. geschrieben werden und Historisierungskonzepte sind in relationalen Datenbanken sehr schwer umsetzbar. Wer dann auch noch eine objektorientierte Sprache verwendet, muss die Daten von der objektorientierten Welt in die relationale Welt überführen und umgekehrt (O/R-Mapper), was zusätzliche Komplexität in unserer Anwendung bedeutet.

Anstatt also relationale Datenbanken und somit das ER-Modell als die heilige Seekuh darzustellen, wäre ein kritischer Blick auf all das mal sinnvoller.

Ich persönlich habe damit in meiner Zeit als Entwickler sehr gute Erfahrungen gemacht. Wir haben oftmals im Team in verschiedenen Phasen mit den Fachabteilungen zusammengesessen und das ER-Modell diente als Grundlage. Das hat für uns sehr gut funktioniert. Es ist aber völlig in Ordnung, dass du das anders siehst.

Das ER-Modell ist zu technisch, sodass Fachabteilungen damit überhaupt nichts anfangen können. Eine Fachabteilung kann oft nicht abschätzen, welche Daten sie wirklich brauchen und schon gar nicht in welcher Kardinalität sie zueinander stehen. Im Zweifel wollen sie alles haben was sie kriegen können, weil alles irgendwie mal wichtig sein könnte und wäre schön, es im Vorwege zur Verfügung steht. Das sehe ich beruflich auch jeden Tag. Im Ernst, wir hatten mal einen Kunden, der die Anforderung stellte, dass unsere Software "alles reporten können soll" (echtes Zitat).Das bedeutet auch mehr Komplexität und Kompliziertheit in der Anwendung. Was aber eine Fachabteilung kann, ist deren Arbeitsalltag zu beschreiben und genau daraus entstand DDD (Domain-driven Design) und der Begriff feiert auch schon fast seinen 20-jährigen Geburtstag.

Ein ER-Modell hab ich schon seit 10 Jahren nicht mehr geschrieben. Höchstens nur noch zur späteren Dokumentation aber nie in der Implementierungsphase. Wie gesagt, das ER-Modell zwingt einen, die Daten als relationale Daten zu betrachten. Die Welt der relationalen Daten sieht aber anders aus, als die Welt der objektorientierten Daten. Also braucht man da auch wieder einen komplexen Mapper. Sei es z.B. das Entity Framework für .NET-Sprachen oder Niberhate für Java, etc. z.B. möchte ich vielleicht ein Dictionary (C#) bzw. ein HashMap (Java) in die Datenbank speichern. Viel Spaß beim Mapping... Mit z.B. dokumentbasierten Datenbanken kann dies aber ggf. wegfallen und ich spare mir die Abhängigkeit zum O/R-Mapper.

Bearbeitet 27. Dezember 20214 j von Whiz-zarD

Meine Erfahrungen sind andere. Aber gut, lassen wir das mal so stehen. Ich nehme deinen Hinweis mit auf. Aber selbst wenn du zu 100 Prozent recht hast, steht das ER-Modell im Lehrplan und zwar in allen Bildungsgängen. Daher komme ich (und auch meine SuS) in keinem Fall drumherum.

 

VG