Und es ist noch keine Ende in Sicht!

Es geht wahnsinnig harzig voran – doch immerhin kommen wir vom Fleck. 🙂 Das Problem dabei ist, dass meist die Lösung eines Problems ein neues hervorruft oder andere Unklarheiten schafft. Zudem ergeben sich ungeant verschiedene Lösungsmöglichkeiten eines Problems, bei denen man nicht einfach eine davon Umsetzen kann, sondern alle Analysieren und evtl. auch implementieren sollte.

Hier ein kleines Beispiel: Wie sollte man eine logische 1:1 Relation zwischen zwei Entitätsmengen korrekt physikalsich relational auflösen?

Lösung 1: Man könnte einfach eine Tabelle A und eine Tabelle B erstellen. Tabelle B hätte dann den Primärschlüssel von Tabelle A als Fremdschlüssel. Easy.

Lösung 2: Man könnte dies aber auch gerade umgekehr implementieren. Tabelle A besässe dann den Fremdschlüssel. Dies ist eine Überlegung wert, weil sich daraus Performanceeinbussen vermeiden liessen. Hätte Tabelle B nähmlich tausende von Datensätzen und Tabelle A nur sehr wenige, wäre diese Lösung besser als die Lösung 1. Bei der Lösung 1 gäbe es ja sonst auch extrem viele NULL Werte beim Fremdschlüssel.

Lösung 3: Man könnte hier aber auch eine Zwischentabelle einfügen, wie es bei einer n:m Relation der brauch ist. Wichtig dabei ist, dass die jeweiligen Fremdschlüssel in der Zwischentabelle einzeln mit dem Unique-Index-Constraint versehen würden – ansonsten hätte man ja wirklich eine n:m Relation abgebildet. Mit dieser Lösung würde man definieren, dass eine Tabelle A zur Tabelle B gleichberechtigt ist. Dies wäre die Lösung des sog. Verheiratungsproblem mit den Entitätsmengen Mann und Frau. Hier muss logisch eine Zwischentabelle eingefügt werden, denn würde beim Verheiratungsproblem die Lösung 1 oder 2 implementiert, könnte es vorkommen, dass eine Frau mit mehreren Männern oder ein Mann mit mehreren Frauen verheiratet ist, was laut unserem Gesetzgebuch nicht wirklich erlaubt ist.

Dies sind nun die 3 Lösungen zu physikalisch relationaler Abbildung von einer 1:1 Beziehung. Hätte diese Beziehung nun noch zusätzlich ein Attribut, wäre eine weitere Entscheidung fällig. Kommt das Attribut auf der Beziehung, nun in Tabelle A oder B oder muss hier zwingend eine Zwischentabelle generiert werden.

Eine weitere Frage ist, wie sich dieses logische Modell nun auf physikalisch objektorientiert abbilden lässt… nun geht die Lösungssuche von neuem los. Und auch danach hat man erst die 1:1 Beziehung analysiert… 1:n, 1:m und is-a Beziehungen folgen dann… Und auch danach hat man ja noch keine Definitionen resp. Variantenabklärungen für Notationen, Domains, den Codegeneratoren… Zudem fehlen ja auch so Kleinigkeiten wie Softwarearchitekturen oder Testszenarien…

Hauptsache, mir wird nicht langweilig, denn programmieren sollten wir diese Software nach all unseren Analysen dann auch noch 😀

Wir schreiben und schreiben und schreiben…

Heute haben wir endlich mit der Konzeptionierung begonnen. In unserem Fall heisst das erstmals alles aufschreiben, was diskutiert, rausgefunden und entschieden wurde. Danach mussten wir noch die Sitzungsprotokolle und den Statusreport an die Dozentin schicken. Eigentlich alles recht aufwändig und langweilig 🙂 .

Aus Spass an der Sache haben wir der Applikation auch schon einen Namen verpasst: dataMagus. Zudem soll die Software ja auch ein Gesicht bekommen. Und der erste Weg dazu ist ein Icon, welches heute fertig wurde… Danke Benny!

Wir diskutieren und diskutieren und diskutieren…

Die letzten paar Tage haben wir uns extrem viele Gedanken über die Möglichkeiten zum Designen von logischen und physischen Datenbankmodellen gemacht. Man glaub kaum, auf wieviele Probleme man auch bei recht einfachen und kleinen Modellen stossen kann. Vorallem da unsere Software ja auch noch neben relationalen Modellen die objektorientierten unterstützen soll. Auch die Notationen in den Modellen selber oder die abstrakte resp. logische Sicht auf das Modell brachten viele Fragezeichen zu Tage. Hier ein paar Müsterchen:

  • Wie ist eine n-teilige logische Relation physisch abzubilden?
  • Wie kann man in der Information Engineering (Crows foot) Notation Relationen mit Attributen abbilden?
  • Kann man bei n:m Relationen auch schwache Entitäten definieren? Wenn ja, wie sind diese physisch aufzulösen?
  • Wie und wo müssen wir Interfaces andenken, damit man später andere Notationen und SQL resp. ODL Generatoren per PlugIn anhängen kann?
  • Wieweit kann man auf der physischen Ebene Veränderungen vornehmen, um evtl. generatorspezifischen Features abzudecken?

Nun haben wir zwei zusammen schon stundenlange Diskussionen darüber geführt und bis dato noch kein einziger Buchstaben Konzept geschrieben 🙂 . Darauf werden wir uns nächste Woche konzentrieren, da wir nun (hoffentlich) alle nötigen Informationen zur Umsetzung besitzen.

Ich bin ja gespannt, ob unsere Ideen einer Implementation standhalten 🙂 na mal schauen…

Ready – Steady – Go!

Mit der Abgabe unserer Aufgabenstellung begann heute für Moni und mich die Projektarbeit.

Zudem sind wir heute beide besonders gut drauf, denn wir haben beide unsere Diplomprüfungen bestanden und bereits mit einem Proseccöchen angestossen.