Diskussion:Sekundärschlüssel
Fehler in diesem Artikel: 1. Suchschlüssel und Sekundärschlüssel sind nicht synonym. (vgl. auch die im Artikel angegebene Quelle)
2. "Im Gegensatz zu einem Schlüssel ist ein Suchschlüssel nicht eindeutig." ist falsch. Ein Suchschlüssel muß nicht eindeutig sein, das heisst nicht dass er zwangsläufig nicht eindeutig ist. Auch ein Primärschlüssel kann als Suchschlüssel verwendet werden.
3. Der ganze Abschnitt Fremdschlüssel als Sekundärschlüssel macht keinen Sinn. Das nehme ich zurück! Der Abschnitt stimmt.
Gruss JohnTB 19:21, 11. Jun. 2007 (CEST)
- Zu Punkt eins: siehe Diskussion Diskussion:Schlüssel (Datenbank).
- Zu Punkt zwei: Kann dein Argument nicht nachvollziehen. Dort steht nicht, dass er mehrdeutig sein muss. -- sparti 21:30, 11. Jun. 2007 (CEST)
Doch! - genau das steht da!: "Im Gegensatz zu einem Schlüssel ist ein Suchschlüssel nicht eindeutig." Wenn ein Suchschlüssel nicht eindeutig ist dann ist er mehrdeutig. JohnTB 02:16, 12. Jun. 2007 (CEST)
- Also ich lese dort, daß Eindeutigkeit keine geforderte Eigenschaft ist. Dahinter stehts dann sogar nochmal für Laien, was das bedeutet. Es steht dir aber frei es so zu formulieren, daß es keine Missverständnisse geben kann. -- sparti 11:03, 12. Jun. 2007 (CEST)
- Spreche ich chinesisch? JohnTB 11:40, 12. Jun. 2007 (CEST)
- Hmm, es fällt schwer darauf höflich zu antworten. Trotzdem will ich es probieren. Wenn ich eine Eigenschaft nicht fordere, dann heißt das, daß es mir egal ist, wie die Daten beschaffen sind. Also dürfen sie eindeutig, doppeldeutig, dreifachdeutig usw. sein. -- sparti
- Mir fällt es auch langsam schwer höflich zu bleiben: Im Text steht wörtlich "EIN SUCHSCHLÜSSEL IST NICHT EINDEUTIG". Da steht nicht "muss nicht eindeutig sein" da steht auch nicht "ist nicht immer eindeutig" und auch nicht "Die Eindeutigkeit wird nicht gefordert", sondern da steht "ist nicht eindeutig". Auch hier wollte ich nur auf einen Fehler hinweisen. Aber wenn das nicht möglich ist, dann lass ichs halt.JohnTB 13:58, 12. Jun. 2007 (CEST)
- Nun, mit dem langsam untertreibst du ein wenig. Aber wie ich oben schon sagte: Es steht dir frei es zu ändern. -- sparti 16:36, 12. Jun. 2007 (CEST)
Beispiel Bearbeiten
Hallo zusammen,
was soll mit dem Beispiel verdeutlicht werden?
Schlüssel Bearbeiten
Moin, meiner Ansicht nach werden hier 2 Dinge in ein und denselben Topf geworfen. Zum einen wird das Wort "Schlüssel" verwendet. Ein Schlüssel ist jedoch immer eindeutig (nämlich identifizierend), zumindest was DBSe angeht. Was mehrdeutig sein kann, sind Indexe. Natürlich kann man auch einen unique Index setzen (der wiederum eindeutig ist), das war vorallem noch in alten Zeiten, um einen Primärschlüssel oder Alternativschlüssel anzulegen. Im Artikelbeispiel wird auch mal vom Sekundärindex geschrieben, wobei mir nicht schlüssig wird, warum das Wort "sekundär" verwendet wird.
veranschaulichende Beispiele:
create table test(
id number(4) primary key, -- Primärschlüssel (ein DBS sollte hier automatisch einen unique Index setzen)
nachname varchar(10) not null,
vorname varchar(10) unique); --Alternativschlüssel (manche DBS bilden hier automatisch einen unique Index)
create index name_mehrdeutig on test (nachname); --Index über nachname anlegen
insert into test values (1, 'Müller', 'Andreas');
1 rows inserted
insert into test values (1, 'Müller', 'Mary');
Unique Constraint verletzt -- die 1 steht schon drin
insert into test values (2, 'Müller', 'Mary');
1 rows inserted
insert into test values (3, 'Schmidt', 'Mary');
Unique Constraint verletzt
% das Attribut vorname ist als Alternativschlüssel definiert, 2mal Mary geht nicht einzutragen
insert into test values (3, 'Schmidt', 'Anne');
1 rows inserted
insert into test values (4, 'Schmidt', NULL); -- NULL bei Alternativschlüsseln erlaubt
1 rows inserted
insert into test values (5, 'Schmidt', NULL); -- auch mehrfaches Eintragen von NULL
1 rows inserted
insert into test values (NULL, 'Schmidt', NULL); -- NULL beim Primärschlüssel nicht erlaubt
Einfuegen von NULL in test.id nicht moeglich
Und nun das ganze mal mit Fremdschlüsseln:
create table verheiratet (
urkunden_id number(10) not null primary key,
mann number(4) not null references test, -- Fremdschlüssel auf Primärschlüssel von test
frau number(4) not null references test); -- Fremdschlüssel auf Primärschlüssel von test
% Der gleiche mann und die gleiche frau können (zu unterschiedlichen Zeiten) mehrfach miteinander verheiratet gewesen sein:
create index er_sie on verheiratet (mann, frau);
insert into verheiratet values (1234, 1, 2);
1 rows inserted
insert into verheiratet values (4321, 1, 2);
1 rows inserted
delete from verheiratet; -- alle Datensätze in verheiratet löschen und den Index wegschmeissen
2 rows deleted
drop index er_sie;
% Der gleiche mann und die gleiche frau dürfen nur einmal miteinander verheiratet gewesen sein:
create unique index er_sie on verheiratet (mann, frau);
insert into verheiratet values (1234, 1, 2);
1 rows inserted
insert into verheiratet values (4321, 1, 2);
Unique Constraint verletzt
Mit freundlichen Grüßen --CS-squirrel 11:07, 2. Nov. 2011 (CET)
Defekter Weblink Bearbeiten
| Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt. |
|---|
|
- http://cl1.fh-lueneburg.de:7776/db/Datenbanken.ppt
- Vielleicht ist eine archivierte Version geeignet: archive.org
- Netzwerk-Fehler (7) andere Artikel, gleiche Domain
- Im Jahr 2012 bereits defekt gewesen.