Definition "Schlüssel" in einer Datenbank

[faux]

Hallo!

Ich beschäftige mich gerade etwas genauer mit Datenbanksystemen. Im Prinzip weiß ich was genau ein Schlüssel ist, jedoch muss ich für ein Referat eine genaue Definition finden. Im Wikipedia steht unter Schlüssel (Datenbank) folgender Satz:

Zitat:

Ein Schlüssel dient in einer Relationalen Datenbank dazu, die Tupel einer Relation eindeutig zu identifizieren. Anschaulich kann man sich eine Relation als Tabelle vorstellen. Der Schlüssel einer solchen Tabelle ist dann eine Gruppe von Spalten, die so ausgewählt wird, dass jede Zeile in dieser Gruppe eine einmalige Wertekombination hat.
...
Fremdschlüssel: Ein Attribut einer Relation, welches auf einen Primärschlüssel einer anderen Relation verweist.

Jetzt stellt sich allerdings für mich die Frage, wie man eine 1:n (oder n:m) Beziehung darstellen kann, wenn laut dieser Definition jeder Wert nur einmal vorkommen darf?

Beispiel:

Code:

+--------------+
| Abteilungen  |
+----+---------+
| ID | Name    |
+----+---------+
| 1  | EDV     |
| 2  | Telekom |
| 3  | Zubehör |
+----+---------+

+------------------+
| Mitarbeiter      |
+------+-----------+
| Name | Abteilung |
+------+-----------+
| Mayr | 2         |
| Böck | 3         |
| Faux | 2         |
+------+-----------+

Abteilung wäre laut der Definition ein Fremdschlüssel (auch ein Index, wodurch er laut Definition eines Indexes wieder zu einem Schlüssel werden muss). Hier muss ich aber 2 öfter als einmal vorkommen lassen, da ich sonst keine 1:n Beziehung erstellen kann, wodurch die Grunddefinition eines Schlüssels nicht mehr stimmt (...identifiziert eine Entität eindeutig...). :?
Habe ich da einen Denkfehler, oder ist die Definition wirklich nicht okay?

Grüße
Faux

[Pfoto]

Hallo,

letzendlich könnte die Tabelle Mitarbeiter wieder eigene Primärschlüssel haben...

Es ist zudem nicht ungültig, wenn die Fremdschlüssel in der Tabelle Mitarbeiter öfter vorkommen; weisen sie doch unmissverständlich auf den richtigen Eintrag der Tabelle Abteilungen

Gruß
Pfoto

[faux]

Zitat:

Zitat von Pfoto

letzendlich könnte die Tabelle Mitarbeiter wieder eigene Primärschlüssel haben...

Bei mir ist der Name der Primärschlüssel. :tongue:
Es ist ja nur ein Beispiel...

Zitat:

Zitat von Pfoto

Es ist zudem nicht ungültig, wenn die Fremdschlüssel in der Tabelle Mitarbeiter öfter vorkommen; weisen sie doch unmissverständlich auf den richtigen Eintrag der Tabelle Abteilungen

Achsoooo, das identisch bezieht sich deiner Meinung nach nicht auf den Frendschlüssel selbst, sondern sein "Ziel"?

Grüße
Faux

[Jürgen Thomas]

Tja, so ist das mit den Definitionen. Aus der Wiki-Erklärung geht indirekt hervor, dass Schlüssel als Kurzform für Primärschlüssel (Primary Key) verstanden wird. Der Fremdschlüssel (Foreign Key) stellt eine Beziehung (Relation) dar, die auf den Primärschlüssel der anderen Tabelle verweist.

Bei Deinem Beispiel gilt:
Abteilungen hat einen Primärschlüssel, nämlich ID.
Mitarbeiter hat keinen Primärschlüssel, aber einen Fremdschlüssel, bei dem das Feld "Abteilung" auf den Primärschlüssel der anderen Tabelle verweist.

Jeder Schlüssel kann sich auf ein oder mehrere Felder beziehen. Aus Geschwindigkeitsgründen und wegen der besseren Wartungsmöglichkeit sind Schlüssel für ein Feld meistens besser. Tabellen ohne Primärschlüssel sind "quasi verboten" (nicht unbedingt was die Theorie betrifft, sondern von der Praxis).

Ich hoffe, ich konnte zur Klarheit beitragen. Jürgen

Nachtrag:

Zitat:

Zitat von Faux

Achsoooo, das identisch bezieht sich deiner Meinung nach nicht auf den Frendschlüssel selbst, sondern sein "Ziel"?

So ist es.

Der Name ist als Primärschlüssel völlig ungeeignet, auch in der Kombination mit Vorname oder Geburtstag. Auch dafür ist eine ID das sinnvollste; das sollte man sich als Regel für (fast) jede Tabelle vornehmen. Ausnahmen wären allenfalls Tabellen, bei denen alle Felder gemeinsam als Primärschlüssel gelten würden und jedes Feld zu einem Fremdschlüssel gehört.

[faux]

Danke sehr für die Erklärung.

Zitat:

Zitat von Jürgen Thomas

Der Name ist als Primärschlüssel völlig ungeeignet, auch in der Kombination mit Vorname oder Geburtstag. Auch dafür ist eine ID das sinnvollste; das sollte man sich als Regel für (fast) jede Tabelle vornehmen. Ausnahmen wären allenfalls Tabellen, bei denen alle Felder gemeinsam als Primärschlüssel gelten würden und jedes Feld zu einem Fremdschlüssel gehört.

Das mit dem Namen-Primärschlüssel war auch nichts ernst gemeint. ;)

[Reinhard Kern]

Zitat:

Zitat von faux

Hallo!

Ich beschäftige mich gerade etwas genauer mit Datenbanksystemen. Im Prinzip weiß ich was genau ein Schlüssel ist, jedoch muss ich für ein Referat eine genaue Definition finden. Im Wikipedia steht unter Schlüssel (Datenbank) folgender Satz:

Zitat:

Ein Schlüssel dient in einer Relationalen Datenbank dazu, die Tupel einer Relation eindeutig zu identifizieren. Anschaulich kann man sich eine Relation als Tabelle vorstellen. Der Schlüssel einer solchen Tabelle ist dann eine Gruppe von Spalten, die so ausgewählt wird, dass jede Zeile in dieser Gruppe eine einmalige Wertekombination hat.
...
Fremdschlüssel: Ein Attribut einer Relation, welches auf einen Primärschlüssel einer anderen Relation verweist.

Jetzt stellt sich allerdings für mich die Frage, wie man eine 1:n (oder n:m) Beziehung darstellen kann, wenn laut dieser Definition jeder Wert nur einmal vorkommen darf?
...
Grüße
Faux

Hallo,

wörtlich genommen ist die Wikipedia-Aussage falsch. Es gibt normalerweise einen Primärschlüssel, der eindeutig ist, und weitere Schlüssel, nach denen die Tabelle gezielt durchsucht werden kann, die aber eben nicht eindeutig sind, wichtigstes Beispiel ist der Name: schliesslich kann ich ja keinen Müller als Kunden ablehnen, weil schon einer in der Tabelle steht. In der nach Namen sortierten Anzeige kommen die Müllers eben nacheinander. In den meisten Datenbanken kann man wählen, ob ein bestimmter Schlüssel eindeutig sein muss oder nicht.

Eine Auftragsdatenbank hat z.B. einen eindeutigen Primärschlüssel, das ist die Auftragsnummer, und Sekundärschlüssel wie z. B. Kunde oder Lieferdatum, die nicht eindeutig sind - ein Kunde kann ja mehrere Aufträge erteilt haben.

Gruss Reinhard

[alzaimar]

Zitat:

Zitat von Reinhard Kern

wörtlich genommen ist die Wikipedia-Aussage falsch. Es gibt normalerweise einen Primärschlüssel, der eindeutig ist, und weitere Schlüssel, nach denen die Tabelle gezielt durchsucht werden kann, die aber eben nicht eindeutig sind, wichtigstes Beispiel ist der Name: schliesslich kann ich ja keinen Müller als Kunden ablehnen, weil schon einer in der Tabelle steht. In der nach Namen sortierten Anzeige kommen die Müllers eben nacheinander. In den meisten Datenbanken kann man wählen, ob ein bestimmter Schlüssel eindeutig sein muss oder nicht.

Das klingt mir zusehr nach Paradox. Nach Deiner Definition wären somit alle Spalten einer Tabelle gleichzeitig 'Schlüssel'. Primärschlüssel identifizieren ein Objekt oder einen Datensatz eindeutig. Daneben gibt es dann eine Reihe weiterer (zusammengesetzter) Schlüssel, die aber eines gemeinsam haben: Sie sind eindeutig! Insofern ist die Wiki-Definition korrekt. Selbst ein scheinbar mehrdeutiger Schlüssel ist intern eindeutig, weil die Datensatz-ID (Record-ID) mit abgespeichert wird. Schliesslich muss die DB-Engine ja den zu dem Schlüssel gehörigen Datensätz finden können. Desweiteren bauen die verwendeten Datenstrukturen (B-Baum) auf einer totalen Ordnung auf. Und die bedingt nunmal Eindeutigkeit (und Ordnung).

Ich würde das so machen:
Tabelle "Abteilung" besteht aus
AbteilungID (PK) | Abteilung

Tabelle "Mitarbeiter" besteht aus
MitarbeiterID (PK)| Mitarbeiter

Tabelle "Abteilungsmitglieder" besteht aus
AbteilungID (FK) | MitarbeiterID (FK)

(PK)=Primary Key (FK)=Foreign Key.

Die Tabelle "AbteilungMitglieder" definiert die Relation (Mitarbeiter) "ist Mitglied von" (Abteilung). Damit hättest Du deine m:n Beziehung. Jeder Mitarbeiter kann in beliebig vielen Abteilungen sein und jede Abteilung kann beliebig viele Mitarbeiter beinhalten.

Die Tabelle "Abteilungsmitglieder" hat hier keinen PK. Könnte sie aber (sollte sie vielleicht auch, obwohl ich das nicht mache).

Durch die Bedingung, das die Kombination AbteilungID/MitarbeiterID eindeutig sein muss (ist also ein "Candidate Key", laut Wiki), ist die m:n Beziehung sauber definiert.

Eine 1:n Beziehung (Jeder Mitarbeiter ist in genau einer Abteilung) bekommst Du hin, indem Du in die Tabelle "Mitarbeiter" eine Spalte "AbteilungID" anfügst, und auf die Relation "ist Mitglied von" verzichtest.

Hoffe, mich nicht verhaspelt zu haben :freak:

[Hansa]

Zitat:

Zitat von alzaimar

...Hoffe, mich nicht verhaspelt zu haben :freak:

Ne, aber trotzdem fast. :mrgreen: Es geht darum, die DB-Felder bzw. die Daten an sich unabhängig zu machen von dem ganzen Drumrum. Deshalb gibt es die IDs, die allerdings nur intern verwendet werden sollten. Wenn man im eigenen Programm den Müller in Mueller umbenennen will, dann bleibt die ID immer noch, wie sie ist. Der lässt sich also immer noch eindeutig identifizieren. Abhängige Daten beziehen sich also dann immer noch auf die ID. Dieses Prinzip sollte man wissen.

[marabu]

Hallo,

ein paar Anmerkungen:

Zitat:

Es gibt normalerweise einen Primärschlüssel, der eindeutig ist, und weitere Schlüssel, nach denen die Tabelle gezielt durchsucht werden kann, die aber eben nicht eindeutig sind

der Primärschlüssel ist ein Begriff aus dem Relational Model for Database Management, die "weiteren Schlüssel" von Reinhard sind eine begriffliche Ungenauigkeit aus einem anderen Themengebiet. Für Definitionen sollte man stets Primärliteratur zu Rate ziehen.

Zum Begriff Schlüssel findet man in Chris J. Date: An Intoduction to Database Systems Vol. I zu Beginn von Chapter 11 folgenden Absatz:

C.J. Date über Schlüssel (1986)

The term "key" is one of the most overworked in the entire database field. In the relational model alone we find primary, candidate, alternate, and foreign keys. In other areas of database technology we meet index keys, hash keys, search keys, secondary keys, ordering keys, parent keys, child keys, and many other kinds of key. It therefore seems advisable to avoid use of the unqualified term "key" and always to state explicitly in any discussion of the subject just what kind of key is meant. However, if any one of that multiplicity of keys does deserve to be called just the key, it is clearly the primary key. The primary key is easily the most important one of all.

Also beim Referat darauf achten: Definition und Abgrenzung - beides ist wichtig. Primäre Quelle für alle Begriffsdefinitionen im RDBMS-Bereich ist für mich Edgar F. Codd: The Relational Model for Database Management: Version 2.

Freundliche Grüße vom marabu

[Hansa]

Zitat:

Zitat von faux

Jetzt stellt sich allerdings für mich die Frage, wie man eine 1:n (oder n:m) Beziehung darstellen kann, wenn laut dieser Definition jeder Wert nur einmal vorkommen darf?

Beispiel:

Code:

+--------------+
| Abteilungen  |
+----+---------+
| ID | Name    |
+----+---------+
| 1  | EDV     |
| 2  | Telekom |
| 3  | Zubehör |
+----+---------+

+------------------+
| Mitarbeiter      |
+------+-----------+
| Name | Abteilung |
+------+-----------+
| Mayr | 2         |
| Böck | 3         |
| Faux | 2         |
+------+-----------+

Habe ich da einen Denkfehler, oder ist die Definition wirklich nicht okay?

Denkfehler : ja. Definition Okay ? Nein. :angel: Warum ? Tabelle Abteilungen ist ja ok. In Tabelle Mitarbeiter fehlt : ID und ID_Abteilung. Gäbe bei mir lediglich 4-6 von 15 Punkten. Vielleicht auch 8. :mrgreen:

[faux]

Danke für die Antworten, so habe ich mir das auch gedacht, bis ich den Wiki-Artikel gesehen hab. ;)
Kanne es z. B. von MySQL wo man zwischen "UNIQUE", "PIMARY" und "FULLTEXT" wählen kann.

Zitat:

Zitat von Hansa

Denkfehler : ja. Definition Okay ? Nein. :angel: Warum ? Tabelle Abteilungen ist ja ok. In Tabelle Mitarbeiter fehlt : ID und ID_Abteilung. Gäbe bei mir lediglich 4-6 von 15 Punkten. Vielleicht auch 8. :mrgreen:

Danke, dass ihr mir zum dritten Mal mein Beispiel vorhält. Ich weiß wie man Tabellen erstellt. Das war ein extra für diese Frage erstelltes BEISPIEL. Die Tabelle gibt es nicht, hat es nie gegeben und wird es (hoffentlich) auch nie... :evil:

Grüße
Faux

[alzaimar]

Zitat:

Zitat von faux

Danke, dass ihr mir zum dritten Mal mein Beispiel vorhält. Ich weiß wie man Tabellen erstellt. Das war ein extra für diese Frage erstelltes BEISPIEL. Die Tabelle gibt es nicht, hat es nie gegeben und wird es (hoffentlich) auch nie... :evil:

Es wird dich für den Rest deines Lebens verfolgen :mrgreen: .

[radekj]

Und jetzt aus der Praxis,

verwende nie eine sichtbare Spalte als Schlüssel,

weil wen z.B. du die Kunden-ID als Schlüssel nimmst und jemand sich bei der Eingabe vertippt oder später
die ID ändern will dann gibt es Probleme.

Benutze einen Synthetischen-Schlüssel also generiere eine nicht sichtbare Spalte und fülle die z.B.:
mit UUID als Primären-Schlüssel und das was, dann kanst du mit den Sichtbaren-Spalten machen was du willst
und die Relationen bleiben immer korrekt.

ciao
Radek

[Reinhard Kern]

Zitat:

Zitat von alzaimar

Daneben gibt es dann eine Reihe weiterer (zusammengesetzter) Schlüssel, die aber eines gemeinsam haben: Sie sind eindeutig! Insofern ist die Wiki-Definition korrekt. Selbst ein scheinbar mehrdeutiger Schlüssel ist intern eindeutig, weil die Datensatz-ID (Record-ID) mit abgespeichert wird. Schliesslich muss die DB-Engine ja den zu dem Schlüssel gehörigen Datensätz finden können.

...

Die Tabelle "AbteilungMitglieder" definiert die Relation (Mitarbeiter) "ist Mitglied von" (Abteilung). Damit hättest Du deine m:n Beziehung. Jeder Mitarbeiter kann in beliebig vielen Abteilungen sein und jede Abteilung kann beliebig viele Mitarbeiter beinhalten.

Hoffe, mich nicht verhaspelt zu haben :freak:

Hallo,

das mag eine (für dich) wünschenwerte Theorie sein, das, was ich beschrieben habe, ist aber Realität und seit mehr als 20 Jahren so problemlos in der Industrie im Einsatz:

1. Natürlich ist der Primärschlüssel eindeutig - in der Tabelle, in der er eben der Primärschlüssel ist. Nicht aber in einer anderen Tabelle, eben wegen der Möglichkeit von 1:n-Beziehungen. Konkret: Die Kundennummer ist eindeutig in der Tabelle Kunden, nicht aber in der Tabelle Auftrag, da gibt es mehrere zum gleichen Kunden. Wenn einem dabei wohler ist, kann man das ja dort als Index-Schlüssel bezeichnen oder Sekundär-Schlüssel, was anderes habe ich auch nicht behuptet. Dass dieser intern durch Anhängen von IDs eindeutig gemacht würde, ist falsch - ich kenne die Index-Strukturen auf Binärebene, da steht tatsächlich nur die Kundennummer drin.

2. Eine Folge davon ist, dass die Tabelle AbteilungMitglieder überhaupt nicht gebraucht wird. Ein (nicht eindeutiger) Index über die Spalte Abteilung in der Tabelle Mitglieder liefert das Gewünschte.

Das mag nach Paradox klingen (wäre das eine Schande?), gilt aber für die meisten Datenbanken der 80iger Jahre. Deine Behauptung, das wäre alles funktionsunfähig, wird durch tausende von noch arbeitenden Programmen widerlegt. Wenn du nur sagen willst, der grösste Teil der heute existierenden Software wäre deiner Meinung nach falsch programmiert, damit könnte man leben.

Gruss Reinhard

[alzaimar]

Ich verstehe nicht, was Du an meiner Aussage kritisierst und wieso Du diese Bemerkungen von Dir gibst...

Schlüssel sind per definitionem eindeutig. Ob Du das als Anwender mitbekommst, oder nicht, ist für die Definition unerheblich. Im Übrigen ist es auch unerheblich, ob bei einem Index die RecID nun explizit oder implizit mit angegeben ist. Implizit ("Clustered Index" heisst das bei MSSQL) bedeutet hier z.B., das die gesammte Tabelle ('Datenmenge') anhand eines Index sortiert abgelegt ist. Dann kannst Du auf Binärbebene suchen bis der Arzt kommt, ein Tupel (Key/RecID) wirst du natürlich so nicht finden, aber da die RecID des Key im Index = RecID des Datensatzes ist, haben wir wieder die Zuordnung. Und auch wenn dieser Index (=Schlüssel) für sich gesehen nicht eindeutig ist, ist die Kombination (Schlüssel-RecordID) natürlich eindeutig.

Wenn Du den B-Baum (oder welche Struktur auch immer Du meinst) auf Binärebene kennst, und dann keine (logische?) Zuordnung zum Datensatz siehst, dann erkläre mir bitte, wie die DB-Engine beim Suchen nach dem 'Sekundärindex' "Müller" auf die Datensätze 1234, 5678 und 98765 kommt? Wie schafft sie das nur?

Dessenungeachtet benötigt nun mal jede DB eine total Ordnung ("gleich" gibts nicht) auf den Schlüsseln, ja selbst auf den Datensätzen selbst. SQL macht hier natürlich auf der User-Seite (DQL, DML) mit Absicht nicht mit, weil eine Datenmenge (auch 'per definitionem') keine Ordnung aufweist. Intern haben die Datensätze logischerweise eine Record-ID, bei IB/FB z.B. gibt es dafür sogar irgendso eine "$xxx" Krücke.

Gerade weil (und nur weil) die Schlüssel (Fremd-, 'Sekundär'(wo ist die Def.?), Komposite, Kandidaten-) eindeutig sind, funktionieren Datenbankapplikationen überhaupt, auch die aus den 80er Jahren.

So... und nun zum Kleinkram...

Zitat:

Zitat von Reinhard Kern

das mag eine (für dich) wünschenwerte Theorie sein, das, was ich beschrieben habe, ist aber Realität und seit mehr als 20 Jahren so problemlos in der Industrie im Einsatz:

Es ist für mich keine wünschenswerte Theorie, sondern Realität, das Schlüssel eindeutig sind. Immer und überall. Soweit ich weiss, sogar seit bald 40 Jahren (1970, Codd) :mrgreen:

Zitat:

Zitat von Reinhard Kern

2. Eine Folge davon ist, dass die Tabelle AbteilungMitglieder überhaupt nicht gebraucht wird. Ein (nicht eindeutiger) Index über die Spalte Abteilung in der Tabelle Mitglieder liefert das Gewünschte.

:stupid: Aber wie stellst Du dann dar, das Müller in Abteilung X und gleichzeitig in Abteilung Y ist (m:n)?

Zitat:

Zitat von Reinhard Kern

Das mag nach Paradox klingen (wäre das eine Schande?),

Ja. :zwinker: , aber ich meinte eher, das ich den Terminus "Sekundärindex" so nicht kenne, sondern nur in Verbindung mit Paradox. Und deswegen klingt mir das eben zusehr nach Paradox.

Zitat:

Zitat von Reinhard Kern

gilt aber für die meisten Datenbanken der 80iger Jahre. Deine Behauptung, das wäre alles funktionsunfähig...

Wo hab ich das gemacht? Finde ich nicht. :gruebel:

Zitat:

Zitat von Reinhard Kern

...Wenn du nur sagen willst, der grösste Teil der heute existierenden Software wäre deiner Meinung nach falsch programmiert, damit könnte man leben.

Eine Studie (USA, wo sonst) bescheinigt 60% aller laufenden C/S DB-Applikationen eine den Grundregeln (1-3 Semester) des DB-Designs widersprechende Architektur. Man muss damit leben, aber wohl ist mir dabei nicht. Das ist aber nicht die Aussage meines Posts...

Abschließend sei noch Eins gesagt: "Schlüssel" können aus der Anwendersicht natürlich mehrdeutig sein (Deine Behauptung), sie sind es aber aus DB-Sicht nicht (meine Behauptung). Da ist kein Widerspruch drin, sondern jeweils nur eine Erweiterung Deiner/Meiner Definition.

[Hansa]

Mittlerweile echt lustiger Thread. :stupid: Egal welche falsch programmierten uralten Programme noch im Umlauf sind oder was die Theorie so neues sagt. Ende 2006 ist das hier gültig :

Zitat:

Zitat von faux

Beispiel:

Code:

+--------------+
| Abteilungen  |
+----+---------+
| ID | Name    |
+----+---------+
| 1  | EDV     |
| 2  | Telekom |
| 3  | Zubehör |
+----+---------+
 ^PK 
+------------------+
| Mitarbeiter      |
+------------------+-------               -----------+
| ID| ID_ABTEILUNG | Name |                Abteilung |
+------------------+-------               -----------+
| 1 |       2      | Mayr |                2         |
| 2 |       3      | Böck |                3         |
| 3 |       2      | Faux |                2         |
+------------------+-------               -----------+
 ^PK       ^FK(Verweis auf PK Abteilung)            ^ überflüssig, Punktabzug wegen redundanter Datenhaltung :P

1+1=2 und basta. :mrgreen:

[alzaimar]

Hansa: Jetzt ist Mayr im Vertrieb und in der EDV?

Könnt Ihr alle nicht lesen? :freak: Ich schreib Doch ständig von (m:n) Beziehungen. Das geht doch nur mit einer separaten Tabelle (AbetilungID/MitarbeiterID). War im Eingangs-Post des Threads nicht auch eine Frage bezügl. m:n? Oder bin ich jetzt schon :wall: ?

Egal. Ende 2006 ist das gleiche gültig wie 1970: Frohes Fest und :dp:

[Hansa]

Zitat:

Zitat von faux

...wie man eine 1:n (oder n:m) Beziehung darstellen kann, wenn laut dieser Definition jeder Wert nur einmal vorkommen darf?..

Sowohl aus dem nicht ausgeklammerten, als auch aus dem Kontext könnte man darauf schließen, dass es um 1:n geht. :shock: Falls wir aber schon soweit sind, dass der Koch notfalls auch den Linux-Server administriert oder die Tipse geht mal eben für 2 Stunden an den Hochofen, na dann gute Nacht. :mrgreen:

[alzaimar]

:mrgreen: Da steht aber auch n:m. Irgendwie jedenfalls. (Und der Kontext ist jetzt egal :mrgreen:)

:dancer:

[Reinhard Kern]

Zitat:

Zitat von alzaimar

Ich verstehe nicht, was Du an meiner Aussage kritisierst und wieso Du diese Bemerkungen von Dir gibst...

Schlüssel sind per definitionem eindeutig. Ob Du das als Anwender mitbekommst, oder nicht, ist für die Definition unerheblich. Im Übrigen ist es auch unerheblich, ob bei einem Index die RecID nun explizit oder implizit mit angegeben ist. Implizit ("Clustered Index" heisst das bei MSSQL) bedeutet hier z.B., das die gesammte Tabelle ('Datenmenge') anhand eines Index sortiert abgelegt ist. Dann kannst Du auf Binärbebene suchen bis der Arzt kommt, ein Tupel (Key/RecID) wirst du natürlich so nicht finden, aber da die RecID des Key im Index = RecID des Datensatzes ist, haben wir wieder die Zuordnung. Und auch wenn dieser Index (=Schlüssel) für sich gesehen nicht eindeutig ist, ist die Kombination (Schlüssel-RecordID) natürlich eindeutig.

...

Abschließend sei noch Eins gesagt: "Schlüssel" können aus der Anwendersicht natürlich mehrdeutig sein (Deine Behauptung), sie sind es aber aus DB-Sicht nicht (meine Behauptung). Da ist kein Widerspruch drin, sondern jeweils nur eine Erweiterung Deiner/Meiner Definition.

Hallo,

leider schlicht falsch. Du denkst viel zu kompliziert, aber ein Problem mit möglichst hohem Aufwand zu lösen, ist nicht die Aufgabe eines Programmierers.

Bei der von mir erwähnten und real existierenden Auftragsdatei ist es viel einfacher: Der Index "K" ordnet diese Datei nach Kunden, wobei ein Kunde natürlich mehr als einen Auftrag haben kann, z.B. 5. Dann enthält die Indexdatei eben 5 Einträge nacheinander, jeder besteht genau aus der Kunden-ID und der absoluten Position des entsprechenden Auftrags in der Datei. Ganz schlicht und einfach. Ich habe mit so etwas ja auch nicht allein gearbeitet, sondern eine Million andere haben es auch so gemacht. Auch wenn das aus deiner Sicht alles Mist ist - allerdings hast du offensichtlich die Funktion von Datenbanken wie DBase, Clipper, Fox usw. (auch Paradox)überhaupt nicht verstanden. Trotzdem ist vieles davon heute noch im Einsatz. Es waren ja auch nicht alle blöd, die schon im letzten Jahrtausend programmiert haben.

Wenn ein grosser Teil der Software an der Theorie vorbei geschrieben ist, so spricht das im übrigen nicht sehr für Nutzen und Konsistenz der Theorie; dazu kommt noch, dass oft rechtliche Grundsätze dazu zwingen, von der Theorie abzuweichen, aber das würde hier zu weit führen.

Gruss Reinhard

[alzaimar]

Reinhard: Ich verstehe immer noch nicht, was du mir sagen willst. Offenkundig ignorierst oder mißverstehst Du mich. Da ich mich mehrfach klar geäußert habe, bleibt nur ersters.

Ich denke auch nicht kompliziert, sondern zitiere eigentlich nur, was nunmal eine Tatsache ist: Nämlich wie eine DB intern funktioniert. Dafür kann ich Nichts.

Ich verwende "mehrdeutige" Schlüssel auch, weil ich doch, auch wenn Du es nicht glaubst, schon mal ein Programm geschrieben habe. Ich habe auch studiert und weiss, wie man DBMS schreibt und warum die 3.Normalform etwas umständlich ist. Ich habe auch schon mal ein SQL-DBMS entwickelt, falls Dich das interessiert. Aber sonst habe ich vielleicht ja doch keine Ahnung von Softwareentwicklung, Tabellen und so.

Aber das hier ist schon grenzwertig:

Zitat:

Zitat von Reinhard Kern

...Dann enthält die Indexdatei eben 5 Einträge nacheinander, jeder besteht genau aus der Kunden-ID und der absoluten Position des entsprechenden Auftrags in der Datei.

Ich schrieb (was du so vehement als Theorie und an der Realität vorbei bezeichnet hast)

Zitat:

Zitat von alzaimar

daneben gibt es dann eine Reihe weiterer (zusammengesetzter) Schlüssel, die aber eines gemeinsam haben: Sie sind eindeutig! ... Selbst ein scheinbar mehrdeutiger Schlüssel ist intern eindeutig, weil die Datensatz-ID (Record-ID) mit abgespeichert wird. ..

Nachdem Du meine erste Frage nicht beantwortet hast

Zitat:

Zitat von Ich

Wenn Du den B-Baum (oder welche Struktur auch immer Du meinst) auf Binärebene kennst, und dann keine (logische?) Zuordnung zum Datensatz siehst, dann erkläre mir bitte, wie die DB-Engine beim Suchen nach dem 'Sekundärindex' "Müller" auf die Datensätze 1234, 5678 und 98765 kommt? Wie schafft sie das nur?

magst du vielleicht diese Frage beantworten:

Zitat:

Zitat von Ich

Wie kannst Du eine Behauptung von mir erst anzweifeln, um Sie dann selbst zu äußern?

Das einzige, was ich gewagt habe, anzuzweifeln (oh, es waren zwei Dinge) sind:
1. 'Sekundärschlüssel'. Diese Bezeichnung ist mir DBMS-technisch nicht bekannt, sondern nur Paradox-seitig untergekommen. Es tut mir leid, wenn meine Kenntnisse hier bescheiden sind.
2. 'Schlüssel' können auch mehrdeutig sein und werden zum Suchen verwendet... Hmm Vielleicht meine Ich "Index" und Du "Schlüssel" oder umgekehrt.

Zitat:

Zitat von Reinhard Kern

Auch wenn das aus deiner Sicht alles Mist ist

Wo sage ich das? Zeig mal oder sei ruhig.

Zitat:

Zitat von Reinhard Kern

allerdings hast du offensichtlich die Funktion von Datenbanken wie DBase, Clipper, Fox usw. (auch Paradox)überhaupt nicht verstanden.

Ach? Wieso habe ich diese Frickelprogrämmchen nicht verstanden?

Zitat:

Zitat von Reinhard Kern

Es waren ja auch nicht alle blöd, die schon im letzten Jahrtausend programmiert haben.

Nee, nicht Alle (ich z.B.) aber Einige schon.

Zitat:

Zitat von Reinhard Kern

Wenn ein grosser Teil der Software an der Theorie vorbei geschrieben ist, so spricht das im übrigen nicht sehr für Nutzen und Konsistenz der Theorie; dazu kommt noch, dass oft rechtliche Grundsätze dazu zwingen, von der Theorie abzuweichen,

Klar. Fresst Sch***, denn 10.000.000 Fliegen können nicht irren.
Oder: Wenn alle Windows verwenden, MUSS es ja gut sein.

Mmmppf.

Ich würde den Satz so formulieren:

Zitat:

Wenn ein grosser Teil der Software an der Theorie vorbei geschrieben ist, so spricht das im übrigen nicht sehr für Nutzen und Fähigkeiten der Programmierer; dazu kommt noch, dass oft zelebrale Grundsätze dazu zwingen, von der Theorie abzuweichen...

Reinhard: Bitte unterlasse Unterstellungen oder Behauptungen, die Du nicht belegen kannst. Das wird sehr schnell albern. Und beantworte bitte meine Fragen

[Reinhard Kern]

Hallo,

Zitat aus der aktuellen Oracle-Dokumentation:

Zitat:
A SecondaryConfig object is used to configure the secondary database. The SecondaryConfig class extends the DatabaseConfig class, and most steps for configuring a secondary database are the same as for configuring a primary database. The main difference in the example above is that the SecondaryConfig.setSortedDuplicates() method is called to allow duplicate index keys. This is how more than one Supplier may be in the same City. If this property is not specified, the default is that the index keys of all records must be unique.

For a primary database, duplicate keys are not normally used since a primary database with duplicate keys may not have any associated secondary indices. If primary database keys are not unique, there is no way for a secondary key to reference a specific record in the primary database.
Zitat Ende

Wenn Oracle das offiziell so dokumentiert, kann meine Ausdrucksweise so unsinnig nicht sein. Wer englisch lesen kann, findet im Zitat eindeutige und mehrdeutige Schlüssel erwähnt ebenso wie die deiner Meinung nach unbekannten Sekundärschlüssel. Sogar die Möglichkeit nicht eindeutiger Primaärschlüssel wird erwähnt. Vielleicht wendest du dich ja mal an Oracle und bringst deren Kenntnisse auf den neuesten Stand?

Gruss Reinhard

[alzaimar]

Den Begriff "Sekundärschlüssel" habe ich nie verwendet, und immer nur im Zusammenhang mit Paradox und der leidigen "Datenbankoberfläche" gesehen.

Alternativ zum wenig hilfreichen Oracle-Zitat einfach mal bei Wiki vorbeischauen.

Na gut, überzeugt :mrgreen: . Ich erkenne die Daseinsberechtigung von Sekundärschlüsseln außerhalb einer Paradoxtabelle ausdrücklich an und beuge mich der Fachwelt. Ich hatte ja auch nur behauptet, den Begriff nicht zu kennen, gell?

Bleiben noch die beiden bisher unbeantworteten Fragen...

[marabu]

Mit Verlaub,

ich verurteile den Begriff Sekundärschlüssel. Auch wenn auf der Wikipedia-Seite jemand eine Begriffserklärung zu geben versucht, bleibe ich bei meiner Auffassung, die ich in Beitrag #9 mit einem Zitat von Chris Date belegt habe: Sekundärschlüssel ist ein terminus technicus, der nicht aus der Relational Theory stammt. Der Versuch dort, ihn als Schwester des wohldefinierten Begriffes Primärschlüssel zu etablieren, ist hemdsärmelig. Der Autor benutzt die Beschreibung eines candidate key für einen Sortierbegriff und nennt das dann einen Sekundärschlüssel. Dieser Artikel muss zweifellos noch reifen. Ich rate euch einstweilen Primärquellen zur Begriffsdefinition heranzuziehen.

Entsetzte Grüße vom marabu

[alzaimar]

Oh. :lol: War ich mit meinem Gefühl und alterndem Wissen doch nicht allein auf weiter Flur?

Also muß ich mich nicht beugen und hinnehmen, das sich Sekundärschlüssel breit machen?

Andererseits: Lass sie doch. Wer damit glücklich(er) wird.

Aber ich kann jetzt beruhigt nach Hause gehen und die Skundärschlüssel dort lassen, wo sie sind. :mrgreen:

[Peinhard]

Hier noch etwas zum Schmunzeln aus einer Seminarbeschreibung des bfi Steiermark:

Zitat:

Grundlagen Programmierung und Datenbankdesign

Inhalt:
Grundlagen Programmierung: Programmierlogik, Konstrukte, einfache Befehle, Variablen, Operatoren, Ein-, Mehrfachverzweigungen, Schleifen, Arrays, grafische Darstellung von Programmen; Datenbank-Design: Normalisieren von Tabellen (1., 2., 3. Normalform); Beziehungen (1:1, 1:N, N:1,M:N); Primär-, Fremd-, Sekundär- und KandidatInnenschlüssel; referentielle Integrität (Quelle)

Sehr PC... :mrgreen:
.