Sonstiges > Infrastruktur
Glanz und Elend von RDBMS aus Sicht der Anwendungsentwicklung
Marinero Atlántico:
Ich liefere am Wochenenden Tabellen für PostgreSQL und DB2. 8)
animate:
--- Zitat von: Semeaphoros am 28.04.05 - 13:13:08 ---Beziehungskiste:
Wer kennt wen?
A kennt B und E, B kennt C und D, C kennt B und E, E kennt B und C .......
--- Ende Zitat ---
--- Zitat von: Thomas Schulte am 28.04.05 - 13:25:41 ---RDBS im Klassichen Sinn sind auch dann überfordert, wenn jede beliebige Tabelle mit jeder anderen beliebigen Tabelle in einer Beziehung stehen kann (aber nicht muss).
Haus A gehört Person B
Person C wohnt in Haus A
Telefonanschluss D ist in Wohnung E
Wohnung E ist in Haus A
Person F telefoniert mit Telefonanschluß D
TelefonAnschluß D ist angemeldet von Person B
--- Ende Zitat ---
Hmm? Das sind doch stinknormale Relationen, oder nicht?
Sowas kann ich auf jeden Fall in UML-Klassendiagramm darstellen und ich denke auch, dass ich das auf eine relationale Datenbank übertragen kann (Bin da nicht so der ultra Spezialist, aber ich weiß, dass wir hier aus Klassendiagrammen die Tabellen generieren lassen und das ist sowas an der Tagesordnung).
Marinero Atlántico:
Jens Beispiel würde ich auch eindeutig als M-N Beziehung auf sich selber sehen.
Also auf fränkisch vielleicht ???:
|--------------------------------|*-------------------| relationship (u.U. als Beziehungsklasse (spelling?) an die Assoziation hängen
| Person | |
| |*-------------------|
*------------------------------- |
Thomas Schulte versucht es mit einem DB-Warehouse Trick. Er könnte sich berufen auf "... mit jeder anderen Tabelle in Beziehung stehen kann (aber nicht muss).
Ich kenn mich nicht mit Datawarehouse aus. Aber ich glaub, da müssen die Beziehungen zwischen den Relationen schon irgendwie definiert sein. Jedenfalls stimme ich mit Thomas V. überein. Bisher waren das alles ganz normale Relationen.
Semeaphoros:
Beziehungen auf sich selber sind in Codd (und Nachfolger) nicht erlaubt. Damit durchbricht so etwas das relationale Modell. Dass man das in UML darstellen kann, hat in dieser Hinsicht keine Bedeutung. Fakt ist, dass bei einem solchen Datenmodell Referenzintegrität und ähnliches nicht mehr mit den gängigen Mitteln sichergestellt werden kann. Es hat auch niemand - weder Thomas noch ich - gesagt, dass sich sowas nicht darstellen lassen kann, es ist einfach nicht mehr relational
Marinero Atlántico:
In der relationalen Integrität sehe ich auch ein kleines Problem (die Beziehung kann doppelt vorhanden sein). Man braucht dafür aber nur einen kleinen Validitätscheck aus der Anwendung heraus. Oder man macht die Inserts/Updates als stored procedures und checkt das da ab.
Als wirkliche Einschränkung sehe ich das nur sehr bedingt.
Table Person
ID Identity (autogenerated primary key)
nameP varchar(50)
Table Relation
ID Identity (autogenerated primary key)
IDPersonA BigInt --- Fremdschlüssel auf idPerson
IDPersonB BigInt --- Fremdschlüssel auf idPerson.
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln