Architekturproblem

Hallo community

Ich habe irgendwie ein Architekturproblem mit der Datenbank.
Ich habe in dieser Firmen erfasst und Kunden, diese mit einem Fremdschlüssel zur Firma. Nun habe ich ein Programm, mit welchem man Termine verwaltet. Ein Termin kann nun aber einer Einzelperson, dem Kunden, oder der ganzen Firma gewidmet sein. Wie löse ich dies am besten?
Bisher dachte ich an eine Termintabelle, mit zwei Fremdschlüsseln. Einer zum Kunden, der andere zur Firma. Hoffe ihr habt bessere Ideen 😉

LG Michael

Hallo michaelschuler,

sauberer ist es wohl, wenn du zwei Zwischentabellen einführst. Eine die KundenIds den TerminIds zuordnet und eine, die das für FirmenIds tut.

herbivore

Hmmm, wie kann eine FIRMA einen Termin haben?

Aber trotzdem ein tolles Beispiel wie schlecht man mit relationalem Ansatz saubere Modelle zimmern kann. Vermutlich der Sinn der Übungsaufgabe.....

Leider keine Übungsaufgabe...
Wenn ich nun zwei zwischentabellen mache, habe ich das Problem auf der Datenbankseite gut gelöst. Denke zumindest, dass dies ein guter Ansatz ist.
Doch wie sieht es in OOP aus? Wenn ich die Termine z.b. in einer ListView anschaue, was nehme ich hier? Wie baue ich dies auf?
Ich habe ja die Möglichkeit über vererbung, Schnittstelle oder abstrakte klasse. ich möchte schliesslich beides gleich handhaben.
Weiss evtl jemand, ob es ein geeignetes pattern dafür gibt. irgendwie fände ich das abstract factory pattern hier noch sinnvoll. allerdings kenne ich dieses pattern nur aus meinem superbuch in der theorie 🙁

Danke für eure Mühe!!
Michael

Hallo michaelschuler,

also, dass es separate Klassen für Firma, Kunde und Termin gibt, setze ich mal voraus.

Die Frage ist also nur, wie diese zu koppeln sind.

Dabei ist es aus meiner Sicht unkritisch, wenn Firma und Kunde ihre Termine kennen. Kunde kann also durchaus eine Exemplarvariable (ArrayList o.ä.) für seine Termine enthalten, dito für die Firma.

Bleibt also die Notwendigkeit, die Rückrichtung zu entkoppeln. Termin sollte also weder Kunde noch Firma kennen, damit die Termin-Klasse auch funktionieren kann, wenn sie später von einer anderen Klasse benutzt werden soll. Da aber Termin sehr wohl Informationen über das Objekt, dem er zugeordnet ist, benötigt, z.B. um sich selbst vollständig anzeigen zu können, bietet es sich m.E. an, dass Kunde und Firma ein Interface TerminEigner implementieren, über das sie dem Termin-Objekt die nötigen Informationen liefern können (bzw. der Termin die Informationen mittelns diese Interfaces abfragen kann).

Der Termin würde also eine Exemplarvariable vom Typ TerminEigener enthalten.

herbivore

Auf diese Idee bin ich gar noch nicht gekommen, finde ich sehr gut. Tja, berufserfahrung darf man halt nicht unterschätzen...
Möchte dir für deine Mühe danken, jetzt bin ich meinem Ziel ein grosses Stück weiter 🙂

Liebe Grüsse
Michael

Original von michaelschuler
Leider keine Übungsaufgabe...
Wenn ich nun zwei zwischentabellen mache, habe ich das Problem auf der Datenbankseite gut gelöst. Denke zumindest, dass dies ein guter Ansatz ist.

Ansichtssache. Eine GUTE relationale Lösung würde es ermöglichen, mit EINER Anfrage alle Teilnehmer an Terminen zu erhalten. Hier muss du aber zwei Anfragen machen (hole Termine der Mitarbeiter und hole Termine der Firmen). Nun kann man die mit UNION zwar zusammenfügen, aber auch das ist keine optimale Lösung (siehe unten).

Mit OO-Mitteln hätte man entweder ein Interface oder eine Oberklasse definiert und könnte eine solche Anfrage ohne Probleme stellen.

Der Effekt dieser "relationalen Schwäche" ist, dass der Code schlecht wartbar wird. Pro Unterklasse brauchst du eine eigene Tabelle. In einem Objektmodell könntest du eine weitere Klasse einführen OHNE den Abfragecode zu ändern (bezieht sich ja immer noch auf "Teilnehmer" eines Termins und nicht auf konkrete Ausprägungen).

Das ist der typische Gap zwischen Objektentwicklung und relationaler Modellierung. Letztere ist weniger mächtig, d.h. man muss im Code "drumrumfrickeln".

Das zweite große Problem ist die fehlenden Trennung zwischen Entität und Attribut. Damit ist es de facto unmöglich dynymische Daten zu speichern und diese wieder per Abfrage zusammenzuführen (zumindest nach SQL92). Was dazu notwendig wäre sind Pivot-Funktionen, die Zeilen zur Spalten machen können. Dies sind aber bisher proprietäre Erweiterungen (z.B. Oracle). Also hat man die Qual der Wahl zwischen "freien Feldern" oder Attributtabellen, die aber nicht mit den Entitäten per SQL zusammenzufügen sind und letztlich nur aus Code zu nutzen sind (stehen Reports via SQL nicht zur Verfügung).

SQL und OO werden immer Krücken sein. Die beiden passen schlicht nicht zusammen.

Svenson, wie würdest du das Problem denn Lösen, ohne auf Pivot-Funktionen zurückzugreifen?

Kommt darauf an. Am besten alles auf einmal 🙂

Ich hab z.B. gerade eine Anwendung, da verwenden wir Attributtabellen, in vollem Wissen, dass uns diese Daten für Reports nicht zur Verfügung stehen. In einer speziellen Applikation können wir die Daten für Einzelfälle dann natürlich holen und anzeigen.

Bei anderen Fällen werden wir das DB-Schema migrieren, wenn neue Anforderungen neue Felder notwendig werden lassen, "freie Felder" haben wir trotzdem vorgesehen aber noch nicht genutzt.

An einer Stelle, wo wir beliebige, unbekannte Datenstrukturen speichern wollen, speichern wir sogar XML in die DB! Aber auch hier natürlich keine echter SQL-Zugriff.

Alles in allem eine totale Krücke, bei der sich mit die Haare hochstellen, aber es gibt schlicht keine Alternative, außer Oracle oder eine OO- oder XML-Datenbank einzusetzen.

Relationale Datenbanken sind nunmal auf feste Daten-Schemata zugeschnitten. Sobald Dynamik ins Spiel kommt beginnt die Frickelei.

Hört man meine Verachtung für relationale DBs auch richtig gut raus? 🙂 Wäre ich Diktator, würde ich sie verbieten.... 🙂