Diskussion:Einführung in SQL: Relationale Datenbanken
Ich finde die Begriffe Entität und Attribut sehr mühsam, und hätte sie gerne für ein einfaches Verständnis definiert:
Vlt:
Datenmodelle auf der Entitätenebene bestehen aus Entitäten und Relationen zwischen diesen Entitäten.
Eine Entität bezeichnet eine Einheit aus der Realität, die als Tabelle in der Datenbank abgebildet wird.
Entitäten besitzen auch Eigenschaften, sog. "Attribute", die als Tabellenspalte abgebildet werden.
Der Begriff Entität ist nicht so leicht zu erklären, zeigt sich in der Praxis aber häufig als intuitiv identifizierbar:
"Mitarbeiter" ist z.B. eine Entität, und an Attributen wird man sicherlich "Name", "Addresse", "Telefon", etc. festhalten wollen (also entsprechende Tabellenspalten anlegen).
Eine Entität kann aber auch abstrakter sein, zB. "Fahrt" wäre eine Entität, wie sie in einer Fahrzeugverwaltung zu identifizieren wäre, mit Attributen wie "Start", "Ziel", "Startzeit", "AnkunftZeit", etc.
Zwischen diesen Entitäten besteht eine Beziehung, (auch als "Relation" bezeichnet), welche ganz einfach definiert ist:
"Ein Mitarbeiter kann mehrere Fahrten absolviert haben."
Diese Art von Relation bezeichnet man als 1:n - Relation
...
Dann würde ich gleich eine passende ER-Grafik zufügen, und Entität, Attribut, Relation daran beschriften.
Im Abschnitt Tabellenmodell würde ich das Beispiel fortführen, sodaß der Leser MITARBEITER und FAHRT in beiden Ansichten vorfindet.
Das finde ich nämlich etwas unglücklich, dass erst ein Versicherungsbeispiel eingeführt wird, und dann auf etwas mit Abteilungen und Mitarbeitern geswitcht wird.
Auch Relation und Schlüssel würde ich anhand des Fahrten-Beispieles aufzeigen - ich sehe gerade, da besteht ja schon eine FahrzeugVerwaltung in der Beispiel-Datenbank.
Auch fällt mir auf, daß die DB-Tabellen offensichtlich plural-flexiert benamt sind - ich denke, Standard ist, singular-flexiert zu benamen.
Weil, dass mehrere Verträge in einer VERTRAG - Tabelle enthalten sind, ist ja evident, aber wenn später mit einzelnen Datensätzen programmiert wird, ergeben sich dort irreführende Namen wie "VERTRAEGERow".
(Ich würde auch nur Anfangsbuchstaben von tabellen groß schreiben, schon weil man häufig zusammengesetzte Worte verwendet, und die lassen sich per Groß/Klein-Schreibung einfach strukturieren, wo man ansonsten den umständlichen "_" bemühen muß.
Vergleiche VERTRAEGE_POSITIONENRow mit "VertragPositionRow")
Das Fahrtenbeispiel finde ich nützlich, weil es zeigt (so nebenbei), dass Entitäten nicht immer konkrete Objekte bezeichnen, und es daher keine wirkliche Alternative für diesen eigentlich schwer fassbaren Begriff gibt.
Auch den Abschnitt Relation würde ich direkt an den BeispielTabellen "Mitarbeiter" und "Fahrt" aufhängen.
Also angenommen, es werden 4 Zeilen von MITARBEITER gezeigt, und mw. 10 Zeilen von FAHRT, daran ungefähr so anschließen:
Wie ist nun die 1:n-Relation Mitarbeiter-Fahrt auf Tabellen-Ebene abgebildet?
Sehr einfach, jede Fahrt hat ein zusätzliches Attribut/zusätzliche Spalte "MitarbeiterID", und der dort eingetragene Wert ist identisch mit dem Wert "MitarbeiterID" eines Datensatzes der Tabelle "Mitarbeiter".
Über diesen einfachen Mechanismus kann der DB-Provider jedem Mitarbeiter "seine" Fahrten zuordnen, wenn diese Information abgefragt wird.
Darin liegt übrigens ein grundlegender "Trick" der relationalen Datenbanken: Mit nur 2 Tabellen können beliebig viele Tabellen "vorgetäuscht" werden. Denn eigentlich, wenn 10 Mitarbeiter je 5 Fahrten absolvieren, würde das doch auch 10 Tabellen erfordern, um jedem Mitarbeiter seine Fahrten zuzuordnen.
Aber nein: Alle Fahrten kommen in dieselbe Tabelle, nur werden sie je mit unterschiedlichem "Fremdschlüssel"/"ForeignKey" versehen.
Eine 1:n-Relation zwischen zwei Entitäten wird also auf Tabellen-Ebene abgebildet, indem die übergeordnete Tabelle ("Mitarbeiter") eine Primärschlüssel/PrimaryKey - Spalte erhält, die eigentlich gar kein Attribut des Mitarbeiters repräsentiert, sondern nur eindeutig innerhalb der Tabelle sein muß.
Die untergeordnete Tabelle erhält eine ForeignKey-Spalte, und die darin auftretenden Werte spezifizieren den übergeordneten Datensatz. ForeignKey-Werte können logischerweise mehrfach in derselben Tabelle auftreten, im Beispiel nämlich, wenn mehrere Fahrten existieren, die vom selben Mitarbeiter absolviert wurden.
So irgendwie fände ich die Erklärung einfacher verständlich.
Im Anschluß kann man dann exakter werden, erläutern, dass die SpaltenNamen von Prim und ForeignKey nicht identisch sein müssen (tät ich aber empfehlen), Constraints, evtl. mehrspaltige Keys (würde ich aber eher weglassen)
Muß man natürlich noch layouten, Fachbegriffe hervorheben, etc - ich weiß da nicht, welcher Standard da für dieses Buch vorgesehen ist.
--ErfinderDesRades 17:45, 2. Okt. 2009 (CEST)
- Ich danke dir, dass du dich an der Diskussion beteiligst. Ich gebe dir weitestgehend recht mit deinen Anmerkungen. Ich weiß allerdings nicht, was davon "jetzt" noch berücksichtigt werden kann und soll. Bitte lies deshalb auch die anderen Diskussionen, vor allem auf der Hauptseite. Außerdem ist dies ein Buch als Einführung; und die gesamten (vor allem von mir verwendeten) Beispiele gehen nicht so tief. Vielleicht bist du dann ebenfalls der Meinung, dass wir eine Reihe deiner Gesichtspunkte ignorieren und als weniger wichtig ansehen können.
- Übrigens: Die Konzeption stammt von 2006/2007; ich habe das als gegeben hingenommen. -- Juetho 18:09, 2. Okt. 2009 (CEST)
- Ich schlage vor, die gesamte Diskussion über RDBMS und die Beispieldatenbank auf der Hauptseite Diskussion:Einführung in SQL fortzuführen. Die Argumente, die ErfinderDesRades hier und unter Beispieldatenbank gebracht hat, sind so grundlegender Natur, dass sie Auswirkungen auf das gesamte Buch haben. Ich möchte es deshalb auf der Hauptseite zusammengefasst diskutieren.
- Wenn du einverstanden bist, werde ich deinen obigen Kommentar dorthin kopieren und hier löschen, damit aller Text zusammen steht. Dein Einverständnis solltest du hier ausdrücklich erklären; ich möchte es nicht einfach nach einer gewissen Zeit als gegeben annehmen. -- Juetho 10:54, 3. Okt. 2009 (CEST)