Definition "Schlüssel" in einer Datenbank

[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 von Hansa:

Denkfehler : ja. Definition Okay ? Nein. 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.

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

Grüße
Faux

[alzaimar]

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

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

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

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.

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

Zitat von Reinhard Kern:

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

Ja. , 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 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.

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

[alzaimar]

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

Könnt Ihr alle nicht lesen? 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 ?

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

[Hansa]

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

[alzaimar]

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

[Reinhard Kern]

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