Glanz und Elend von RDBMS aus Sicht der Anwendungsentwicklung

[Thomas Schulte]

Sorry das ich dich enttäuschen muss Axel, aber das ist keine hypothetischer Grenzfall, sondern tatsächlich eine Anwendung die international bei einer großen Behörde eingesetzt wird. Und die im ersten Step genauso "gelöst" wurde bis man eingesehen hat das es so dann doch nicht geht, nachdem man bei 54 Tabellen angekommen war. Du siehst also die Grenze liegt noch deutlich unter den angenommenen 100 Tabellen.
Zu den beschriebenen Tabellen gehörten,
Personen, Fahrzeuge, Telefone, Telefongespräche, Zusammenkünfte, Häuser, Wohnungen, Mieter, Vermieter, ........
Das Ganze dient dazu Beziehungsmuster aufzuklären und die die sowas benutzen sorgen dafür das unser Leben schön sicher bleibt.

[Thomas Schulte]

Axel, Du wolltest Beispiele, von Praxistauglichkeit hat niemand geredet

Auch wenn du recht hast Jens aber jetzt spaltest du Haare 

Außerdem gibt es mindestens eine echte Anwendung für sowas die ich kenne.

[Semeaphoros]

Auch wenn du recht hast Jens aber jetzt spaltest du Haare 

Ach, ich würd mal behaupten, das Haarespalten hab ich irgendwo hier gelernt .....   

[Marinero Atlántico]

@Thomas: Das ist aber auch kein RDBMS spezifisches Problem.
Wenn du in einer Notes-Datenbank 100 DBLookups auf 100 unterschiedliche Views macht, würden vermutlich nach Tabelle 54 auch nur die ganz hartgesottenen weitermachen, denen Responsivität völlig egal ist.
Das gleiche gilt imho für OODBMS. Dort in einem Objekt 100 Pointer auf Objekte in anderen Objektbäumen ist vermutlich auch nicht so das Gelbe.

[Semeaphoros]

Das schreit tatsächlich nach Caching, aber das ist schon wieder ein völlig anderes Kapitel und stimmt, Performance und Scalability sind nur insofern technologieabhängig, als sie sich unterschiedlich zeigen. Sie treten aber tatsächlich überall irgendwann auf.

[Thomas Schulte]

@Thomas: Das ist aber auch kein RDBMS spezifisches Problem.
Wenn du in einer Notes-Datenbank 100 DBLookups auf 100 unterschiedliche Views macht, würden vermutlich nach Tabelle 54 auch nur die ganz hartgesottenen weitermachen, denen Responsivität völlig egal ist.
Das gleiche gilt imho für OODBMS. Dort in einem Objekt 100 Pointer auf Objekte in anderen Objektbäumen ist vermutlich auch nicht so das Gelbe.

Hat ja auch keiner behauptet. 
Was ich allerdings behaupte ist, das es für dieses Problem eine Lösung gibt, die genau diese Anforderungen abdeckt, die performant und stabil ist und die man sowohl mit nicht strukturierten Systemen (Notes) , mit RBDs und mit OODBMS hinkriegt. Wobei man und da wären wir wieder beim Thema RDBs schon etwas verbiegen müsste, so das es den strengen Anforderungen nicht mehr entsprechen würde.

[Thomas Schulte]

Ach ja Jens, das geht dann auch ohne Caching

[Semeaphoros]

Ja, das glaub ich Dir auch (hatte schliesslich mit ähnlichen Strukturen schon zu tun ) - Aber wie schon erwähnt, wir kommen vom Thema ab.

[animate]

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).

Das ist jede für sich tatsächlich eine Stinknormale Relation.
ABER alles zusammen nicht mehr vernünftig mit den Relationalen Modell darstellbar. da du ja in jeder Tabelle für jede Beziehung zu jeder anderen Tabelle einen neuen Foreign Key eintragen müsstest. Und zusätzlich müsste jeder dieser Keys Mehrfachwerte annehmen was eigentlich auch nicht erlaubt ist.

ich hab keine Ahnung, ob ich damit eine Regel breche, aber ich muss doch weder x ForeignKeys noch Mehrfachwerte in einer Spalte haben. Das kann ich doch alles über Beziehungs-Tabellen machen, in denen jeweils die ID der zueinander in Beziehung stehenden Datensätze steht.

Und es geht nicht darum ob man das mit UML darstellen kann, oder ob es mit einer kleinen Beugung des Relationalen Modells nicht doch geht sondern wie Jens schon gesagt hat darum ob das die Regeln bricht. Und das machen beide Definitionen,  die von Jens und meine auch..

Das mit der UML habe ich deshalb aufgeführt, weil mich ER-Diagramme immer an Klassenmodelle erinnern. Und ein ER-Diagramm biette mir ebenfalls die Möglichkeit, die oben genannten Beispiele zu modellieren.

Beziehungen auf sich selber sind in Codd (und Nachfolger) nicht erlaubt

Codd kenne ich nur als "irgendein Datenbankguru aus den 60ern"
Heißt das, eine Tabelle darf keine Beziehung mit sich selbst haben?
Auch nicht über eine "reine Beziehungstabelle"?

[Semeaphoros]

Codd kenne ich nur als "irgendein Datenbankguru aus den 60ern"
Heißt das, eine Tabelle darf keine Beziehung mit sich selbst haben?
Auch nicht über eine "reine Beziehungstabelle"?

Aendere mal die Zeit um ca. 10 Jahre nach hinten , auch wenn er in den 60ern damit angefangen hat. Und ja, Relfexivität ist in reinen relationalen DBs nicht erlaubt. Man kann es auch anders herum sagen: Relationale DBs sind zwingend hierarchisch aufgebaut (man beachte dabei, dass eine Tabelle nur ein Bestandteil einer DB ist).

Natürlich gibt es für diese Restriktion irgendwelche Gründe, aber frag mic nicht danach, ich weiss es nicht mehr.

Hab auch keine Ahnung mehr, wie das in einer Netzwerk-DB aussehen würde, kann sein, dass es sich dort direkt abbilden lässt. Aber diese Tierchen kennt ja wohl eh niemand mehr.

[Marinero Atlántico]

In diesem Hibernate-Mapping-File aus der caveatemperor Beispielanwendung von Gavin King / Christian Bauer geht deutlich hervor, dass Gavin King und Christian Bauer Tupel der Category Tabelle auf sich selbst in eine 1 zu n Beziehung stellen.

Code

<class name="Category"
<!-- WICHTIGER PUNKT -->
<!-- WICHTIGER PUNKT -->
<!-- WICHTIGER PUNKT -->
<!-- WICHTIGER PUNKT -->

	   table="CATEGORY"
	   lazy="true">

	<!-- Common id property. -->
	<id name="id"
		type="long"
		column="CATEGORY_ID"
		unsaved-value="null"
		access="org.hibernate.auction.persistence.DirectSetAccessor">
		<generator class="native"/>
	</id>

<!-- lots of stuff. Gelöscht von Axel -->

	<!-- Parent can be null for root categories. -->
	<many-to-one name="parentCategory"
				 cascade="none"
				 outer-join="false"
				 foreign-key="FK1_PARENT_CATEGORY_ID">
		<column name="PARENT_CATEGORY_ID"
				not-null="false"
				unique-key="UNIQUE_NAME_AT_LEVEL"/>
	</many-to-one>

	<!-- We use a Set for this bidirectional one-to-many. Batch fetching is
		 particulary interesting for  this association: We expect that the
		 application will need much more childCategories if it accesses
		 one. Batch fetching can significantly improve fetching of the
		 whole category graph.
	-->
	<set    name="childCategories"
			cascade="all-delete-orphan"
			inverse="true"
			lazy="true"
			batch-size="10"
			access="org.hibernate.auction.persistence.DirectSetAccessor">
		<key column="PARENT_CATEGORY_ID"/>
<!-- WICHTIGER PUNKT -->
<!-- WICHTIGER PUNKT -->
<!-- WICHTIGER PUNKT -->
<!-- WICHTIGER PUNKT -->

		<one-to-many class="Category"/>
	</set>

Will hier jetzt jemand behaupten, Gavin King/Christian Bauer haben keine Ahnung von Datenbankmodellierung und haben Codd nicht verstanden

[Semeaphoros]

Axel, das ist die falsche Frage, ob man von Datenbankmodellierung eine Ahnung hat, hängt eh nicht am relationalen Modell. Und selbst wenn man Codd verstanden hat, kann man solche Sachen machen, vorausgesetzt man weiss was und warum man es tut. Selbst Codd hat das Durchbrechen der Regeln grundsätzlich nicht verboten.

[Marinero Atlántico]

Thomas erzeugt offenbar sein Datenbankschema automatisiert aus UML Diagrammen. Mit Hibernate habe ich das auch schon automatisiert aus Objekten hibernate-xml Dateien gemacht und daraus Datenbankschemen. Die Leute bei uns im Büro machen das auch sehr oft (mit Hibernate).
Ich hab sowieso Probleme mit dieser sogenannten "Strenge" von RDBMS.
Worin besteht diese Strenge?
Dass es überhaupt ein Datenmodell gibt, über das die Validität der eingegebenen Daten geprüft werden kann?
Ist das nicht vielleicht ein Vorteil?
Imho kann man ein Datenmodell schnell ändern, wenn man sich ein bischen auskennt.
Ich benutze z.B. ein AntScript, dass die entsprechenden Data Definition Language Befehle (DDL, sowas wie Create Table, Drop Table, etc.) gegen die Datenbank sendet und dann direkt mit Data Manipulation Language (DML, Insert/Select/Update) die Datenbank mit Beispieldaten füllt.
Genau dass lässt sich nämlich schon flexibel ändern. Das ginge auch mit bestehenden Datenbanken.

Axel 

[Marinero Atlántico]

Mit dem Äpfel und Birnenvergleich war natürlich zum Teil berechtigt.
Steht ein Programmierer vor einer Notes Datenbank, einer OODBMS oder einem RDBMS steht er vor verschiedenen Dingen.
Begreift man buzzword-kompatibel alles, was ein Entwickler von den eingespannten Ressourcen benutzt als Dienst, dann würd ich jetzt mal festlegen, dass alle 3 einen gleichen - sagen wir - Zentraldienst liefern:
Persistierung von Daten.
Was ist Persistierung von Daten?
Daten dauerhaft zugreifbar macht.
Jeder kann in einem kleinen Experiment feststellen, was persistente Daten sind:
1. Du stellst dich hinter jemanden, der in verschiedenen Anwendungen arbeitet.
2. Du ziehst das Kabel des Computers aus der Steckdose.
3. Der User fährt seinen Computer wieder hoch.
4. Alle Daten, die dem User von den vorherigen Eingaben fehlen waren leider nicht persistent gespeichert, sondern nur im ram. Alles was noch da ist, waren zu seinem Glück persistente Daten. Die sind noch da. 
Persistente Daten werden auf die Festplatte geschrieben (oft in Form einer Datei). RDBMS , Notes oder OODBMS managed das.
Wieso muss diese Persistierung gemanaged werden?
Ein wichtiger Grund ist, dass viele Personen auf diese persitenten Daten lesend und schreibend zugreifen. Es versteht sich von selbst, dass diese Zugriffe irgendwie organisiert werden müssen.

Gut. Nachdem hier festgelegt worden ist, dass gemeinsamer schreibender und lesender Zugriff auf Daten im konkurrierenden Zugriff von mehreren Usern der zentrale Dienst von RDBMS, Notes und OODBMS ist, bleibt noch die Frage, welche zusätzlichen Dienste die 3 Obstsorten äh Systemtypen anbieten, anhand denen man die Systeme vergleichen kann.
Dazu später mehr.
   

[Marinero Atlántico]

Zusätzliche Dienste sind aus meiner Sicht:
1. Security des Daten/Schemazugriffs: Autentifizierung/Autorisierung und Berechtigung der User bestimmte Operationen durchzuführen
- Daten löschen
- Daten einfügen
- Daten ändern
- Daten lesen
- Datenbankschema/Schablone ändern
- Code auf Datenbankserver laufen lassen
- Datenbank erstellen/löschen

2. Security der Datenübertragung (SSL, ssh, etc.)

3. Transaktionsunterstützung: Eine Transaktion sind mehrere Operationen gegen eine Datenbank in einer atomaren zusammengefasst. Und dies explizit vor dem Hintergrund des konkurrierenden Zugriffs mehrerer User. Atomistisch heisst ja auch, dass User A die Ergebnisse der transaktionalen Operationen von User B erst sehen darf, wenn die Transaktion ganz abgeschlossen ist (keine Zwischenergebnisse). Schliesslich ist es eine atomistische Operation.

4. Erweiterbarkeit der Datenbank (wie einfach sind Änderungen im Schema und wie kontrollierbar sind diese Änderungen--> vermeiden unerwünschter Seiteneffekte, die die Konsistenz der Daten gefährden)

5. Unterstützung von binären Daten.

6. Recovery Tools (Zurückdrehen bei inkonsistenten Zustand der daten).
7. Sprache, um Operationen in der Datenbank durchzuführen.
8. Validitätsüberprüfungen auf die Plausibilität der ankommenden Daten.
9. Möglichkeiten der Replikation. Wenn es etwa auf Grund der schlechten Leitungen zwischen Standort A und Standort B jeder Standort eine eigene Datenbank benötigt.
10. Robustheit/Failover/Clustering-Mechanismen
11. Integration mit anderen Plattformen
12. Reporting Tools.