Diskussion:Schlüssel (Datenbank)

Disk. 1

Es gibt bereits eine Seite Primärschlüssel und eine Seite Superschlüssel! Fragment 02:12, 12. Aug 2005 (CEST)

Die werden im Zuge dieser Zusammenstellung zu Redirects umfunktioniert. Bisher war Primärschlüssel der Überbegriff für eine Zusammenstellung, ich halte das nicht für sinnvoll - obwohl der Artikel gut ist - denn Primärschlüssel ist nur einer von vielen Schlüsselbegriffen (wenn vielleicht auch der wichtigste). --Thetawave 09:04, 12. Aug 2005 (CEST)

Ich habe Primärschlüssel, Superschlüssel, Schlüsselkandidat und Kandidatenschlüssel zu Redirects auf diese Seite umfunktioniert. Vergleicht die letzten Versionen mit diesem Artikel und stellt sicher, dass ich nichts wichtiges bei der Übernahme der Inhalte vergessen habe. Seht auch mal Fremdschlüssel nach und beurteilt, ob die Erklärung hier den dort ausführlicher beschriebenen Sachverhalt genügend deutlich darstellt. --Thetawave 10:05, 12. Aug 2005 (CEST)

Das halte ich für eine schlechte Idee. Wer schnell nach z. B. Fremdschlüssel sucht, muss erst lange den Artikel lesen und kommt nur mühsam zum Ziel. Es ist ja gerade eine Stärke der Verlinkung innerhalb der Wikipedia, die Artikel möglichst kurz zu halten. Es gab wissenschaftliche Untersuchungen, dass man auf diese Weise schneller zum Ziel kommt, wenn man sucht. Also besser wieder auslagern! Zudem sind erst dann Interwikilinks auf Artikel möglich, wenn diese auch eine inhaltliche Einheit darstellen. Zudem sind solche "Mehrere Artikel in einem" in der Wikipedia völlig unüblich. Stern !? 00:41, 21. Aug 2005 (CEST)

Ahem ... nicht so ... also

1. Der Artikel behandelt nicht thematisch Unzusammenhängendes. Die Konzepte sind sachlich nicht voneinader zu trennen. Das Konzept "Kandidatenschlüssel" ist nicht von "Primärschlüssel" zu trennen, oder _beide_ werden unverständlich. Das gilt erst recht für die vergleichsweise wichtigeren "Fremdschlüssel", die ohne den Begriff "Primärschlüssel" nicht verständlich sind.

2. Übergreifende Themen, wie die Unterbringung von Schlüsseln in Relationen, werden so viel schlechter darstellbar. Dein Argument lässt sich so umdrehen: Wenn ich wissen will, wie ich Fremdschlüssel in Relationen unterzubringen habe, damit ich eine 1:n-Beziehung erhalte, und "Fremdschlüssel" eingebe, muss ich erst Fremdschlüssel durchlesen und einen evtl. versteckten Link finden, auf den ich dann klicken muss, um die gewünschte Information zu bekommen.

3. Die letzten "Artikel des Tages" waren alle tierisch lang. Eine Diskussion über die generelle Artikellänge ("wissenschaftliche Untersuchungen" ...) ist hier nicht angebracht.

4. Deine Argumentation unterstellt als Zweck "schneller zum Ziel kommen, wenn man sucht". Da kuckst Du glaube ich besser bei google als im Wiki. Ich persönlich nutze Wikipedia als Infotainment und für einen Überblick. Ich habe für diesen Artikel google genutzt.

5. Die Artikel wie vorher hier oder in en: zu trennen, war meines Erachtens nach eine von Anfang an schlechte Idee. Ich habe mich dort dahingehend bemerkbar gemacht, aber das zählt natürlich nicht. Wie ist die Verlinkung sonst in solchen Fällen geregelt? Englisch->Deutsch trivial, Deutsch->Englisch vielleicht über eine eigene Kategorieseite Category:Key (Database)?

Also ich bin klar pro Zusammenfassung. Auch, wenn ich keine Stimme habe ;-)

Grüße, Fragment 01:30, 21. Aug 2005 (CEST)

Hier hat jeder eine Stimme :-) Stern !? 10:15, 21. Aug 2005 (CEST)

Ich bin auch kein Freund langer Artikel. Die Frage nach der Zusammenfassung sollte aber für jeden Artikel einzeln entschieden werden. Der Zusammenhang zwischen den Schlüsselbegriffen wird nur klar, wenn man sie direkt gegenüber stellt - ansonsten sind Laien tierisch aufgeschmissen. Jeder Begriff hat einen eigenen Abschnitt, jeder Abschnitt ruht in sich selbst. Die Navigation zu dem eigentlich gesuchten Begriff ist also kein Hexenwerk. --Thetawave 18:03, 21. Aug 2005 (CEST)

Also ich stimme beiden Ansichten hier voll zu. Meiner Ansicht nach benoetigen wir beides. Sowohl einen Uebersichtsartike als auch spezialisierte Artikel zu jedem einzelnen Lemma. Redundanz ist hier sowohl erwuenscht als auch notwendig. Einzige Ausnahme waere, wenn man die einzelnen Lemmata in einem Uebersichtsartikel inkludiert. Dabe wuerde man aber die Chance verlieren die einzelnen Lemmata aus verschiedenen Blickwinkel zu betrachten: Einmal individuell und einmal im Zusammenspiel aller Begriffe.

Uebrigens ist der Artikel Objektorientierte Programmierung ein absolutes Negativbeispiel im Zusmmanefassen von Lemmatas! Gruss -- sparti 18:50, 21. Aug 2005 (CEST)

Ich sehe ein Argument, dass gegen einzelne Artikel zu den Begriffen spricht: Es gibt nicht mehr zu sagen! Man kann natürlich immer weitere Beispiele und zusätzliche Zweitformulierungen anbringen, aber die Begriffe werden bereits in diesem kurzen Artikel fast erschöpfend behandelt... --Thetawave 19:10, 21. Aug 2005 (CEST)

Darstellung funktionale Abhängigkeit

Ahoi, mein Buch, mein Prof und der Wiki-Artikel verwenden alle einen Pfeil ohne Punkt, also einfach α→A. Fragment 09:41, 13. Aug 2005 (CEST)

Ja, für die funktionale Abhängigkeit. Doch wie sieht es mit der vollen funktionalen Abhängigkeit aus? Also eine Abhängigkeit, bei der die linke Seite nicht mehr verkleinert werden kann. Ich kenne leider nur die Schreibweise von A.Kemper/A.Eickler. Oder fügen andere einfach den Beisatz ist „die linke Seite ist minimal identifizierend“ hinzu? --Thetawave 11:42, 13. Aug 2005 (CEST)

Den Begriff kannte ich gar nicht, ich habe ihn heute morgen in den FA-Artikel gemacht, nachdem ich ihn hier gelesen hatte ;-) Heuer, Saake verwenden Text:

Heuer, Saake: Teilmenge der Attribute, die übliche Formel Schlüsselbedingung, dann "Ein Schlüssel ist eine bzgl. (Teilmenge) minimale, identifizierende Attributmenge" (S.110)

Heuer, Saake im Teil FAen: "Ein Schlüssel X liegt also vor, wenn für ein Relationenschema R eine FA X->R gilt und X minimal ist." (S.232)

Definition Fremdschlüssel

Die Fremdschlüssel-Verweise werden beim Datenbankentwurf geplant und sind demzufolge auch schon im Vorfeld bekannt. Wozu brauche ich dann eine Definition, mit der ich testen kann, ob Fremdschlüssel existieren? Ich halte die Definition darüber hinaus für falsch: Wenn ich nur die Wertebereiche überprüfe, ist doch noch lange nicht garantiert, dass tatsächlich ein inhaltlicher Zusammenhang besteht - oder? Beispiel: Ich notiere Alter und Hausnummer von Personen, beide könnten (zufällig) denselben Wertebereich haben, haben aber inhaltlich überhaupt nichts miteinander zu tun! --Thetawave 11:24, 17. Aug 2005 (CEST)

Wie kommst Du jetzt auf diese Frage? Wo steht denn das mit dem Testen? Gruss -- sparti 12:31, 17. Aug 2005 (CEST)

Ahoi, die Definition kommt sinngemäß aus meinem DB-Buch. "falsch" in diesem Sinne ist die Definition nicht ... unvollständig schon eher. Ich war schon drauf und dran (, und wenn dies so gewollt ist) dahinter zu schreiben, aber das war mir zu hässlich. Eine bessere Formulierung ist mir nicht mehr eingefallen.

Das Entscheidende ist, dass zwischen den Werten beider Attributmengen eine Teilmengenbeziehung besteht, also im Fremdschlüssel keine Werte stehen dürfen, die nicht im Primärschlüssel vorkommen.

Feel free, Fragment 14:00, 17. Aug 2005 (CEST)

Außer NULL -- bg phaidros 21:30, 12. Mai 2007 (CEST)

• Die Formulierung „Ein Fremdschlüssel in S existiert, wenn blablabla“ legt nahe, dass die Definition zur Suche nach potenziellen Fremdschlüsseln benutzt wird. Ansonsten wäre doch „Eine Attributmenge x aus S heißt Fremdschlüssel, wenn blablabla“ passender, oder?
• Es ist also nur dann ein Fremdschlüssel, wenn die referentielle Integrität gewahrt ist? Ich dachte, das seien zwei verschiedene Paar Schuhe!? Sprich: Wer auf die referentielle Integrität pfeift, kann Werte in den Fremdschlüssel schreiben, zu denen (noch) kein Primärschlüssel existiert. --Thetawave 14:23, 17. Aug 2005 (CEST)

1. Was hältst Du von "Wenn eine Attributmenge ein Fremdschlüssel sein soll, so gilt ..."?
2. Die Angabe "foreign key (Attributliste) references Tabelle" bei create table in SQL-92 tut genau das :-), nämlich eine Integritätsbedingung für die Datenbank (also über Relationen hinweg) zu setzen, so dass Operationen, die diese Bedingung verletzen, zurückgewiesen werden. Fragment 15:15, 17. Aug 2005 (CEST)

Woher hast Du denn diese Definition, ich habe davon noch nicht gehoert. Gruss -- sparti 20:39, 17. Aug 2005 (CEST)

Wie anstrengend wird das denn? Habe einen Abschnitt "Literatur" eingefügt, im Heuer,Saake, dort S.113. Ich zitiere: Ein Fremdschlüssel ist eine Attributliste X in einem Relationenschema R1, wenn in einem Relationenschema R2 eine kompatible Attributliste Y Primärschlüssel ist und die Attributwerte zu X in der Relation r1(R1) auch in den entsprechenden Spalten Y der Relation r2(R2) enthalten sind. Danach folgt eine halbformale Definition. Der Text ist "andersrum": r1(R1) wird S, r2(R2) wird R, für Attributmengen habe ich analog zu anderen Wiki-Artikel α, β verwendet statt X, Y, Teilmengenbeziehung der Werte ist dann klar?

Wenn Ihr was besseres habt, schreibt es bitte hin!

Grüße, Fragment 23:47, 17. Aug 2005 (CEST)

Ahoi, so besser? Fragment 23:55, 17. Aug 2005 (CEST)

Yup, nur solltest Du dir fett Schreiben abegewoehnen, das kommt hier nicht so gut an. Die Idee eines Wikis ist, dass wir zusammenarbeiten und das funktioniert besser, wenn alle verstehen, warum jemand etwas schreibt. Selbst dann, wenn man den Eindruck hat, dass etwas auf der Hand liegt, passiert es, dass andere einfach andere Erfahrungen oder anderes Wissen haben. Ein Erlaeuterung hilft dann ungemein. Freundliche Gruesse -- sparti 22:29, 18. Aug 2005 (CEST)

Dude, das "so besser" war völlig erst gemeint, und fett habe ich geschrieben, weil der Einzeiler sonst eventuell nicht aufgefallen wäre. Die Intention war nicht, rumzuschreien. Nichts für ungut, Fragment 22:49, 18. Aug 2005 (CEST)

Sorry, war wohl etwas ueberempfindlich. Ich freue mich uber die super Arbeit von Dir und Thetawave! -- sparti 00:02, 19. Aug 2005 (CEST)

Perfekt. --Thetawave 20:31, 18. Aug 2005 (CEST)

Ich habe noch eın anderes Problem mıt der Defınıtıon: "Ein Fremdschlüssel ist ein Sekundärschlüssel einer Relation, der in einer anderen Relation Primärschlüssel oder Schlüsselkandidat ist." Ein Sekundärschlüssel besitzt aber nach wie vor voneinander verschiedene Werte in einer Relation (daher "Schlüssel"), aber ein Fremdschlüssel in einer Relation darf bei mehreren Datensätzen durchaus gleiche Werte besitzen, da sonst damit keine 1:n-Beziehungen modelliert werden könnten. Also entweder ist diese Definition im Text falsch, oder ich habe das selber etwas falsch verstanden mit Fremdschlüsseln, Sekundärschlüsseln und Beziehungen usw. :) -- 88.78.77.202 01:27, 12. Feb. 2011 (CET)

Ich meine auch das ist falsch formuliert und habe das geändert in: 'Ein Fremdschlüssel ist ein Attribut einer Relation, dass in einer anderen Relation Primärschlüssel oder Schlüsselkandidat ist'. So passt es. ollio 22:47, 12. Feb. 2011 (CET)

Ja, so passt das schon besser, das andere ist meiner Meinung nach nämlich schlicht falsch gewesen, danke dir! -- 88.78.77.202 23:06, 20. Feb. 2011 (CET)

Weitere Schluesselbegriff: Abgleichcode

Der Artikel muss auch dringend integriert werden. Vielleicht reicht hier einfach ein Redirect und eine kurze Notiz bei Verbundschluessel. Aber vielleicht moechte jemand noch mehr dazu schreiben? Gruss -- sparti 12:28, 23. Aug 2005 (CEST)

ISBN als Primärschlüssel

Die ISBN ist tatsächlich als Primärschlüssel nur begrenzt verwendbar. Sie ist zwar eindeutig und wird über die Lebenszeit der zugehörigen Entität nicht verändert, ist aber nicht für jedes Buch vorhanden (Kleinstverlage, Selbstverlage). Innerhalb eines Verlages der ISBN verwendet also nutzbar, ebenso für Grossisten, die nur etablierte Verlage im Programm haben. Nicht aber für Bibliotheken. Viele Grüße von Buttgereit

Danke für den Hinweis. War aber das einfachste Beispiel, was aufzutreiben war. ;-) Natürlich sind Beispiele wie Sozialversicherungsnummern oder Personalausweisnummern formal exakter. --Thetawave 18:12, 30. Aug 2005 (CEST)

Gut, dann nehmen wir einfach ein ISBN-Verzeichnis als Beispiel, dann stimmts wieder :-) -- sparti 19:38, 30. Aug 2005 (CEST)

Sekundärschlüssel: FALSCH

Alle Schlüsselkandidaten, die nicht zum Primärschlüssel ernannt worden sind heissen Alternativschlüssel.

Wenn Sekundärschlüssel eindeutig sein sollen, dann sind sekundärschlüssel ausgewählte Alternativschlüssel. Wenn Sekundärschlüssel nicht eindeutig sein müssen kann jedes Attribut oder jede Attributkombination zum einem Sekundärschlüssel ernannt werden.

Ob Sekundärschlüssel nun eindeutig sein müssen oder nicht wird unterschiedlich gehandhabt.

dito: IMHO ist der Sekundärschlüssel TEIL eines Primärschlüssels, der selbst Schlüsselkandidat ist. Das hat nichts mit der Beschreibung im Artikel zu tun, und wir sollten es recht bald ändern. Die Wikipedia wird auch von Studenten als alternative Quelle genutzt, und es ergeben sich immer wieder Fragen!

bg Phaidros.vie 13:57, 11. Mai 2007 (CEST)

so, nochmal ich: habe mir erlaubt, das gleich zu ändern.

bG Phaidros.vie 14:15, 11. Mai 2007 (CEST)

So, habe es mir erlaubt das rueckgaengig zu machen. Deine Definition ist mir so nicht glaeufig. Kannst Du dafuer eine Literaturangabe machen? -- sparti 14:21, 11. Mai 2007 (CEST)

muss ich suchen: entweder war das bei codd selbst, oder bei can türker - ich weiß es jetzt nicht mehr. aber so ist der sekundärschlüssel ziemlich sicher falsch (obwohl du mich jetzt unsicher machst). Gegenfrage: gibt's eine Literaturangabe für diese Definition des Sekundärschlüssel? bG Phaidros.vie 14:25, 11. Mai 2007 (CEST)

Also, ich bin jetzt auch etwas verunsichert. Aber soweit ich mich erinnere stimmt die Defintion im Artikel mit A. Eickler, A.Kemper: Datenbanksysteme überein. Das kann ich aber erst heute Abend überprüfen. Bisdahin schlage ich vor, den Artikel so zu belassen, da der ursprüngliche Autor eigentlich immer recht zuverlässig recherchiert hat. Gruss -- sparti 14:33, 11. Mai 2007 (CEST)

Also, schlagmichblau, egal wo man hinschaut (jedenfalls im Web): es scheinen die Begriffe Alternativschlüssel & Sekundärschlüssel identisch zu sein. Wenn ich das nicht finde (ich tippe auf Can Türker - SQL:1999/2003) dann habe ich keine Ahnung, wo ich diese Definition her habe. Verrückt, denn ich war selbst ziemlich verwundert, als ich es so in mein eigenes DB-Skriptum aufgenommen habe. Und ich bin 100%ig sicher, damals 25 mal nachgelesen zu haben, und es *nicht* falsch verstanden zu haben, auch, wenn ich mich jetzt auf einmal nicht mehr erinnern kann .. na klar, der text bleibt so. Und wenn ich die Stelle nicht wiederfinde, werde ich im Gegenteil mit rotem Schädel mein Skriptum ändern! ;-) LG Phaidros.vie 15:18, 11. Mai 2007 (CEST)

Äh, SORRY! Noch dazu sehe ich gerade, dass ich überhaupt einen Fehler in die Anmerkung oben eingebaut habe. Richtig muss es heißen: IMHO ist der Sekundärschlüssel TEIL eines Primärschlüssels, der selbst FREMDSCHLÜSSEL ist. Keine Ahnung, wie das dahin gekommen ist... Ändert aber nix an der Diskussion gerade eben LG Phaidros.vie 15:22, 11. Mai 2007 (CEST)

Ok, soweit denke ich, sind wir uns einig. Aber warum ersetzt Du dann Sekundärschlüssel durch Alternativschlüssel. Wir sollten wenn beide Begriff erläutern.

D'accord!

Weiterhin verstehe ich dann diese Zeile nicht: "Sekundärschlüssel: Teile eines kombinierten Primärschlüssel, die selbst Fremdschlüssel sind". Meiner Ansicht nach existiert ein Sekundärschlüssel völlig unabhängig von irgendwelchen Fremdschlüsseln.

Und das glaube ich jetzt langsam doch wieder weniger. Obwohl ich die eigentliche Textstelle, auf die ich mich beziehe, nicht im Internet finden werde, habe ich doch nach kleiner Recherche folgende Stellen gefunden, aus denen unzweifelhaft hervorgeht, dass ein Sekundärschlüssel nicht eindeutig sein muss - also kein "übrig gebliebener" Schlüsselkandidat sein kann, bzw. sogar ein Synonym für "Fremdschlüssel" ist:

http://www.forst.uni-muenchen.de/EXT/LST/AWINF/LEHRE/JAVA/UNTERLAGEN/string.html

http://ifgivor.uni-muenster.de/vorlesungen/Geoinformatik/kap/kap6/k06_2.htm

http://wwwiti.cs.uni-magdeburg.de/iti_db/lehre/db2/2007/Vorlesungsfolien/Architekturup4.pdf

http://cis.cs.tu-berlin.de/Lehre/WS-0304/Sonstiges/db-pages/Inhalt/Uebungsblaetter/ueb1-loesung.pdf

http://winfoline.wirtschaft.uni-kassel.de/ss2000/datenbanken/datenbanken/drucken/ft3.htm

http://user.uni-frankfurt.de/~bartnick/vwa4.html

http://www.informatik.uni-hamburg.de/Frauen/Admina/Projekte/Bremen/Bremen98/www/Heike/glossar.html

Bitte im jeweiligen HTML oder PDF "Sekundärschlüssel" suchen, um die jeweilige Textstelle zu finden. Meine Theorie ist, dass es sich bei dem Verständnis "Sekundärschlüssel = Schlüsselkandidat" um ein modernes Märchen und einen Selbstläufer handelt - einer übernimmt es vom anderen, und der Gedanke drängt sich ja auch förmlich auf. Wenn wir allerdings wirklich belegen, dass dem so nicht ist, sollten wir eher gesondert darauf hinweisen (vll. in einem Kasten), als einfach die "landläufige" Meinung zu übernehmen, oder was meinst Du?

Dann vielleicht noch allgemeine Anmerkung zu Deinen Änderungen: Du kommentierst die Definitionen mit hinweisen auf die Praxis in Datenbanksystem und DB2. Ich finde man sollte den Theorie- und den Praxisteil strikt trennen. Die Defintionnen sind voellig unabhaengig von moeglichen Implementierungen. Ein eigener Teil ueber Probleme in realen Umsetzungen faend ich aber ganz interessant. -- sparti 15:33, 11. Mai 2007 (CEST)

Kein Problem damit, habe DB/2 ja auch nur als Beispiel genannt.

BG Phaidros.vie 15:54, 11. Mai 2007 (CEST)

Hallo Phaidros, ich bin fast überzeugt. Bitte gib mir dennoch die Gelegenheit das im Eicker/Kemper zu verifizieren. Ich habe diese Definition tatsaechlich noch nie gehört - aber man lernt ja nicht aus. -- sparti 16:18, 11. Mai 2007 (CEST)

Sparti! Habe den Türker jetzt im Büro (eh klar, ich brauch ihn 2x in 3 jahren, und dann hab ich ihn nicht da) Aber eins ist mir jetzt aufgegangen, was u.U. zu diesem Selbstläufer (gemäß meiner Theorie) beiträgt: jeder Schlüsselkandidat *ist* ein Sekundärschlüssel gemäß dieser Definition, ABER HALT NICHT UMGEKEHRT. Hab das aber auch gerade erst behirnt. Weiters glaube ich, dass ich auch einem Irrtum aufgesessen bin: ich glaube jetzt, dass der Sekundärschlüssel als Attributteilmenge eines Primärschlüssels lediglich ein (mehr oder weniger bis gar nicht erwähnenswerter) Spezialfall ist. Richtig dürfte vielmehr sein, dass ein Sekundärschlüssel zur Beschreibung, aber nicht zur Identifizierung von Datensätzen herangezogen werden kann. BG phaidros 21:44, 11. Mai 2007 (CEST)

Ok, ich hab auch nochmal im Eicker/Kemper nachgesehen. Und es scheint so, dass du mit Deiner Maerchentheorie recht hast. Eicker/Kemper definiert den Sekundärschlüssel überhaupt nicht. Dort ist lediglich die Rede von einem Sekundärindex, was vielleicht einige Leute verleitet anzunehmen, dass es auch einen zugehoerigen Sekundärschlüssel gibt. Aber das ist von den Autoren definitv so nicht gemeint.

Also, Du hast offensichtlich mit Deiner Definition eines Sekundärschlüssels recht und wir sollten den Artikel entsprechend anpassen. -- sparti 10:58, 12. Mai 2007 (CEST)

Okidok, habe den Abschnitt jetzt entsprechend angepasst, und auch den Alternativschlüssel dabei in Klammern erwähnt. Bitte gegenlesen, danke! -- bg phaidros 17:50, 12. Mai 2007 (CEST)

Das hat sich wieder eingeschlichen - in der Diskussion hier wurde aber, glaube ich, unterm Strich recht deutlich, was Sekundärschlüssel ist und was nicht. Bessere das nochmals aus. -- bg phaidros 08:32, 4. Feb. 2012 (CET)

Nochmal in anderen Worten: Was ist ein Primär- und was ein Sekundärschlüssel? FALSCH?

sorry, aber was hat den der Sekundärschlüssel mit Indizes zu tun? Geht es dabei nicht um die Verknüpfung von Relationen (Erklärung weiter oben) und, dass man dadurch nur das in eine Relation eintragen kann, was bereits in einer anderen steht?

Ich bin mehr und mehr überzeugt, dass ein Sekundärschlüssel im Allgemeinen zur Beschreibung, aber nicht zur Identifizierung von Datensätzen herangezogen werden kann. (Siehe Diskussion direkt oberhalb) Das würde für die Implementierung einfach einen Index bedeuten. Das ergäbe jedenfalls ein schlüssiges Bild, und dürfte auch den gesuchten Zusammenhang liefern. BG phaidros 22:01, 11. Mai 2007 (CEST)

Zum anonymen Frager: Nein, Du sprichst von einem »Fremdschlüssel«. Sekundärschlüssel ist einfach gleichbedeutend mit »häufiges Suchkriterium«. Siehe obige Diskussion -- bg phaidros 08:30, 4. Feb. 2012 (CET)

Bewertung

Zitat: "Gelegentlich wird auch die Bezeichnung Kandidatenschlüssel verwendet, was eine zu wörtliche Übersetzung des englischen Fachbegriffs candidate key ist."

Was soll denn diese Bewertung? Ich hab das Wort 'zu' rausgenommen. --noLo 20:27, 14. Jan. 2007 (CET)

Ich finde "zu wörtlich" alles andere als falsch: schließlich ist ein Schlüsselkandidat ein Kandidat, und ein Kandidatenschlüssel ein Schlüssel (für einen Kandidaten?). Im Englischen aber immer ein "Candidate key". Und das kann man imho genausowenig mit "Kandidatenschlüssel" übersetzen (obwohl es getan wird), wie man "President elect" nicht mit "Präsidentenwahl" übersetzen kann, sondern mit "designierter Präsident" übersetzen muss. BG phaidros, 11. Mai 2007 (CEST)

Das Problem hier ist, dass unabhängig davon, ob eine Übersetzung richtig oder falsch ist, keine Wertung vorgenommen werden darf. Eine Enzyklopädie bemüht sich Fakten zusammmen zu tragen, die Bewertung wird aber dem Leser überlassen, siehe NPOV.

Also es bleibt zu erwähnen, daß Kandidatenschlüssel nicht die korrekte Übersetzung von Candidate Key ist. Mutmaßungen, wie es dazu gekommen ist, gehören - auch wenns manchmal schwer fällt - aber nicht hier her. -- sparti 11:04, 12. Mai 2007 (CEST)

Und was sagt ihr eigentlich zu dieser Bewertung: "Es gibt leider auch Datenbanksysteme .. ", gleich im 3. Satz des Abschnitts "Einführung". Was sucht das Wort 'leider' in einer neutralen Enzyklopädie? Das ist doch sogar krasser als das Zitat da oben, ich denke das sollte auch raus :-). -- 88.78.77.202 00:04, 11. Feb. 2011 (CET)

Yep, hab's ein wenig umformuliert. Danke und Gruss --Toni am See 09:26, 11. Feb. 2011 (CET)

"Ein Fremdschlüssel ist der Primärschlüssel einer anderen Relation" ??

Servus, im Abschnitt Einleitung kann doch was net stimmen, oder??

Ansonsten ein hervorragender Artikel, weiter so :-)

brahimj@web.de

Hmm, doch inhaltlich ist das korrekt. Ich vermute Du bist unzufrieden mit der Formulierung? -- sparti 12:41, 8. Feb. 2007 (CET)

So wie's formuliert war, hätte der Fremdschlüssel in der Kopftabelle sein müssen, wo er gleichzeitig Primärschlüssel ist. Habe das umgedreht, denn der Fremdschlüssel ist Bestandteil der Detailtabelle. Grafik und Erklärung sind richtig, haben also gar nicht zur Definition gepasst! Besonders nach der obigen Diskussion über Sekundärschlüssel: vll. täte ein Hinweis gut, dass der Begriff "Schlüssel" keineswegs immer und in allen Situationen Eindeutigkeit bedeutet - eigentlich nur für Primärschlüssel, Schlüsselkandidat und Superschlüssel. Was haltet Ihr davon? -- bg phaidros 21:35, 12. Mai 2007 (CEST)

Also, da ein Schlüssel als voll funktional Abhängig definiert ist und ich denke, dass es an dieser Definition keinen Zweifel gibt, finde ich die Idee nicht so gut. Allerdings unterscheiden Kemper und Eickler Schlüssel und Suchschlüssel. Zweiter muss keineswegs eindeutig sein und entspricht damit eher einem Sekundärschlüssel. Ich finde diese Unterscheidung sinnvoll und anschaulich. -- sparti 22:20, 12. Mai 2007 (CEST)

Ich meine damit, dass Sekundärschlüssel, Fremdschlüssel und, wie Du zitierst Suchschlüssel, nicht eindeutig sein müssen, obwohl das Wort "Schlüssel" vorkommt. Ich schlage vor, daraus einen Hinweis zu machen: "Schlüssel im Wort bedeutet nicht immer Eindeutigkeit, nur bei Primär~, Super~ und ~kandidat. Die anderen "%Schlüssel" können situationsbedingt eindeutig sein, oder auch nicht. Ich glaube, dass das zur Entwirrung beitragen könnte.

BTW: In meinem Verständnis ist ein "Suchschlüssel" dasselbe wie ein "Sekundärschlüssel", ich finde aber keine strenge Definition. Meint ihr, wir sollten ganz am Artikelanfang bei den Begriffserklärungen das aufnehmen? -- bg phaidros 07:29, 13. Mai 2007 (CEST)

Ok, damit bin ich vollkommen einverstanden. Ich glaube sogar, dass wir eigene Artikel zu Suchschlüssel bzw. Sekundärschüssel anlegen sollten, um diese Abgrenzung zu verdeutlichen. -- sparti 10:27, 13. Mai 2007 (CEST)

PS.: Als anschauliche Erklaerung finde ich folgende Quelle (Unterpunkt Sekundaerschluessel) nicht schlecht: [1]

Bild Fremdschlüssel

Salu

Ich finde die Veranschaulichung super. Nur frage ich mich, ob die zweite Tabelle (IstChefVon) nicht gegen die erste Normalform verstösst. Oder ist es die Tabelle von? Dann würde ich diese nach links ziehen, denn es ist einfacher nachzuvollziehen, wenn die Primärschlüssel immer am selben Rand stehen.

Grüsse

1NF verlangt nur atomare Feldinhalte und keine Wiederholungsgruppen. Ist bei dieser Tabelle gegeben, obwohl hier 2 Personalnummern auftauchen: es sind zwei unterschiedliche Verwendungen (Vorgesetzter, Untergebener), und es kann keine dritte dazu kommen. Das unterscheidet sie von der Wiederholungsgruppe. Eine andere Formulierung für die 1NF habe ich einmal gelesen, die im Grunde intuitiver ist: atomare Inhalte und die Tabelle eine feste Breite hat - es also niemals nötig werden wird, Spalten dazuzupimpern. Das ist hier der Fall, und damit lautet die Antwort klipp und klar: die Tabelle ist in 1NF. -- bg phaidros 21:39, 12. Mai 2007 (CEST)

Graphik Superschlüssel - Kandidat - Primärschlüssel defekt

Irgendwie ist das Teilmengensymbol beim letzten Edit kaputt gegangen - wenn ich weiß, wie mand das behebt, mache ich es selbst... -- bg phaidros 14:08, 14. Mai 2007 (CEST)

Korrektur: Ein Sekundärschlüssel ist ein alternativer Suchschlüssel, wenn ich nicht über den Primärschlüssel zugreifen will, aber nicht synonym zum Begriff Suchschlüssel.JohnTB 10:54, 7. Jun. 2007 (CEST)

Bitte beachte auch die Diskussion oben zu dem Thema. Da es bei diesem Thema anscheinend eine sehr grosse Konfusion gibt, bitte Deine Meinung mit stichhaltigen Literaturquellen belegen. Danke. -- sparti 11:18, 7. Jun. 2007 (CEST)

Da gibt es nichts zu beachten. Suchschlüssel und Sekundärschlüssel sind nicht synonym. In der Diskussion oben sehe ich auch keinerlei Quellenangaben. Aber bitte: http://www.solid.phys.ethz.ch/pescia/datenbank_def.htm - Gruss JohnTB 17:13, 11. Jun. 2007 (CEST)

Hmm, also ich sehe da oben eine Menge Quellen. Ausserdem befinden sich zwei Literaturquellen im Artikel selbst. Darunter auch das Standardwerk von Kemper/Eickler. In allen Quellen sind die Definitionen leicht verschieden. Häufig sind aber folgende anzutreffen:

• Sekundärschlüssel sind einzelne Datenfelder oder eine Kombination von Datenfeldern, die einen Datensatz zwar beschreiben aber nicht eindeutig identifizieren können. (http://winfoline.wirtschaft.uni-kassel.de/ss2000/datenbanken/datenbanken/drucken/ft3.htm)
• Wenn ein Attribut-Wert mehrere Datentupel identifizieren kann (also eine 1:n-Assoziation besteht), so heisst dieses Attribut ein Sekundärschlüssel. (http://ifgivor.uni-muenster.de/vorlesungen/Geoinformatik/kap/kap6/k06_2.htm)
• Sekundärschlüssel = Fremdschlüssel; in einer Tabelle verwendeter Schlüssel, der auf eine andere Tabelle verweist und dort ein Primärschlüssel ist. (http://www.informatik.uni-hamburg.de/Frauen/Admina/Projekte/Bremen/Bremen98/www/Heike/glossar.html)

usw.

Nach Eicker/Kemper ist ein Suchschlüssel ein zum Index gehörendes Suchkriterium. Dabei muss dieser nicht eindeutig sein und hat ausdrücklich keine Schlüssel Eigenschaften im Sinne eines formalen Datenbankschluessels.

Meine Schlussfolgerung:
1. Es gibt keine einheitliche Defintion von Sekundaerschluessel.
2. Sekundaerschluessel und Suchschluessel sind beides nicht eindeutig identifizierende Attributmengen.
3. Keine der Defintionen oben bestaetigt, die Defintion Deiner Quelle. Auch wenn die Defintion von Sekundaerschluessel - je nach dem, was man unter Hilfsorganisation versteht - durchaus kompatibel zur ersten Defintion oben von der Uni Kassel sein koennte.

-- sparti 20:17, 11. Jun. 2007 (CEST)

In satzorientierten Dateien dient der Primärschlüssel dem direkten Satzzugriff. Ein Sekundärschlüssel wird neben dem Primärschlüssel als zusätzlicher Suchschlüssel verwendet. Sowohl Primär- als auch Sekundärschlüssel können als Suchschlüssel verwendet werden. Ich habe immer noch keine Quelle gesehen, in der steht "Sekundärschlüssel" sei ein Synonym für "Suchschlüssel". Ich habe aber eine Quelle angegeben, in der verschiedene Definitionen drinstehen. Mit der Definition von Kemper/Eickler bin ich 100% einverstanden und sie widerspricht nicht der von mir angegebenen Quelle. JohnTB 02:08, 12. Jun. 2007 (CEST)

Also zunaechstmal vorweg: Wir reden hier ueber Relationale Datenbanken. Hier ist der Primaerschluessel eine Attributmenge einer Relation. Das sollte aber am Ende analog für Satzdateien sein.

So, die Definition von Sekundärschlüssel hier verbietet nicht, den Primaerschluessel als Sekundärschlüssel zu verwenden. Somit ist die Definition von Sekundärschlüssel und Suchschlüssel weiterhin gleich. Bisher kann nicht erkennen, warum eine Unterscheidung überhaupt wichtig sein sollte. Ganz nebenbei scheint das Thema sonst auch nicht von großem Interesse, da es bei einer schnellen Suche praktisch keine formale Definition von Suchschlüssel und Sekundaerschlüssel vom gleichen Autor gibt, außer die von der ETH. -- sparti 10:21, 12. Jun. 2007 (CEST)

Interessante Argumetation: Kuh hat 4 Beine, Pferd hat auch 4 Beine, also Kuh = Pferd. JohnTB 11:47, 12. Jun. 2007 (CEST)

Was ist daran falsch, wenn 4 Beine das einzige Merkmal ist, was eine Kuh und ein Pferd hat? -- sparti 13:19, 12. Jun. 2007 (CEST)

Trautloft/Lindner definieren Sekundärschlüssel explizit als "beliebige Attributkombination, die NICHT Primärschlüssel ist". Wäre Suchschlüssel ein Synonym, dann dürfte ich also nicht mit dem Primärschlüssel suchen. In der beim Artikel Sekundärschlüssel selbst als Referenz angegebenen Webquelle heisst es "Ein Sekundärschlüssel ist ein ALTERNATIVER Suchschlüssel" - Wäre Suchschlüssel ein Synonym stünde hier also nichts anderes als "Ein Suchschlüssel ist eine alternativer Suchschlüssel" - Sehr aufschlussreich. Du sagst sehr richtig, dass diese Diskussion eigentlich völlig uninteressant ist, ich habe ja auch nur auf einen Fehler hingewiesen. Gruss JohnTB 13:59, 12. Jun. 2007 (CEST)

Also ich vermute Du meinst diese Quelle hier: [2]. Ich lese dort folgende Definition: Sekundärschlüssel identifizieren Datensätze nicht. Sekundärschlüssel dienen als alternatives Suchkriterium. Also das ist eben genau das, was ich unter einem Suchschlüssel verstehe.

Um ganz ehrlich zu sein, wenn ich mir die unterschiedlichen Definitionen so betrachte, finde ich es sehr schwer hier ein Richtig oder Falsch zu erkennen. Aber vielleicht sollte genau das in den Artikel einfließen. -- sparti 16:50, 12. Jun. 2007 (CEST)

Lieber Sparti, "Sekundärschlüssel" ist kein Synonym zu "Suchschlüssel". Das ist alles was ich sage. Warum müssen wir ohne Not diese zwei unabhängigen Begriffe zueinander in Beziehung setzen? Das eine hat mit dem anderen wirklich nichts zu tun. Erkennst du die Definition von Trautloft/Lindner an? Wenn ja, dann ist meine Aussage sofort belegt. Wenn nein, dann überleg dir doch mal, ob die zwei Begriffe wirklich austauschbar sind. Die inneren Knoten eines B-Baums enthalten Werte des zugehörigen Suchschlüssels, die als Diskriminatoren für die Verzweigung dienen. Könntest du hier "Suchschlüssel" durch "Sekundärschlüssel" ersetzen? Nein? Warum wohl nicht? JohnTB 19:40, 12. Jun. 2007 (CEST) Nachtrag: "Jeder Schlüssel, der kein Primärschlüssel ist, wird in der Datenbanktheorie als ein Sekundärschlüssel bezeichnet.(vgl. http://www.redmonds.de/RE11656Probe.pdf) Gruss. JohnTB 20:11, 12. Jun. 2007 (CEST)

Also zunaechst mal zum Nachtrag: Das genau ist der Punkt, der oben mit Phaidros diskutiert wurde. Jeder Schluesel kann natuerlich Sekundaerschluessel sein. Umgekehrt gilt das aber eben nicht, da ein Sekundaerschluessel nicht identifizierend ist. Somit gilt hier keine Equivalenz.

Allerdings scheint Trautloft und Linder ebenfalls eine akzeptierte Quelle zu sein, auch wenn ich sie selbst nicht kenne. Daher gebe ich jetzt erstmal nach und werde mich selbst nochmal auf Literaturrechereche begeben. -- sparti 21:38, 12. Jun. 2007 (CEST)

Mir wärs lieber, du würdest nicht "nachgeben" sondern verstehen und zustimmen. Gruss JohnTB 23:00, 12. Jun. 2007 (CEST).

Die Argumentation über den Baum ist stark und nachvollziehbar, wenngleich ich die Frage zurück gebe: warum kann ich nicht Suchschlüssel durch Sekundärschlüssel ersetzen? Ich habe leider derzeit absolut keine Zeit, um selbst ein bisschen zu recherchieren und/oder zu belegen! Aber ich möchte nicht, dass sich mglw. firmeninterne Begrifflichkeiten sich auf einmal in einem allgemeinen, enzyklopädischen Text wiederfinden! Mir sind Trautloft/Lindner unbekannt, und bitte nicht bös sein: MS-Paper sind als Quelle in den meisten Fällen ungeeignet und auch nicht wirklich anerkannt, und ein "Access Aufbaukurs" ist ganz sicher (!!) keine geeignete Quelle. -- bg phaidros 16:44, 13. Jun. 2007 (CEST)

Was MS betrifft: Völlig einverstanden. Das Dokument aus Redmond habe ich auch nur angeführt weil es zufällig die gleiche Definition enthält wie Trautloft/Lindner, was immerhin andeutet dass das auch ausserhalb eines akademischen Lehrbuchs so gesehen wird. Zur Rückfrage: Die Bezeichnungen "Suchschlüssel" und "Sekundärschlüssel" sind nicht verwendungsäquialent, und damit nicht synonym, weil die Bezeichnung "Sekundärschlüssel" immer dann verwendet wird, wenn ich zum Ausdruck bringen will, dass nicht der Primärschlüssel gemeint ist, während die Bezeichnung "Suchschlüssel" dann verwendet wird, wenn es mir auf diese Unterscheidung nicht ankommt. Stattdessen möchte ich beim "Suchschlüssel" zum Ausdruck bringen, dass von einem Suchkriterium die Rede ist, und natürlich kann ich auch über einen Primärschlüssel suchen.

Viele Lehrbücher definieren die Begriffe nicht, weil sie nur in einem definierten Kontext verwendet werden (z.B. Sekundärschlüssel im Kontext Sekundärindex). Neben Trautloft/Lindner gibt es aber beispielsweise noch explizite Definitionen in:

Kähler: Relationales und Objektrelationales SQL: "Um andere Zugriffsschlüssel gegenüber einem Primärschlüssel abzugrenzen verwendet man den Begriff Sekundärschlüssel".

Schneider: Implementierungskonzepte für Datenbanksysteme: "Eine Attributkombination ungleich dem Primärschlüssel wird Sekundärschlüssel genannt"

Gleiche Quelle: "Ein Suchschlüssel unterscheidet sich vom Konzept eines Schlüssels und beschreibt irgendeine Kombination von Attributen, für die wir Werte spezifizieren und passende Datensätze erhalten wollen". JohnTB 19:44, 13. Jun. 2007 (CEST)

Hmm, das klingt zwar plausibel, ich glaube aber nicht, dass dir da alle Autoren so folgen. Mein Eindruck ist, dass viele - auch wichtige - Autoren eine wesentlich entspanntere Definition verwenden. Entweder sie definieren es garnicht, oder z.B. Inmon: Er bezeichnet einen Secondary Key schlicht als "a non-unique attribute used to identify a class of records in a database".

Ein "Non-unique key" ist ein Schlüssel der in jedem Fall nicht eindeutig ist, also auch nicht mit dem Primärschlüssel übereinstimmen kann. Das ist also eine noch engere Definition als die von Trautloft/Lindner. JohnTB 09:22, 14. Jun. 2007 (CEST)

Meinetwegen verzichten wir auf eine Gleichstellung von Suchschlüssel und Sekundärschlüssel. Aber eines muss ganz klar gestellt sein: Ein Sekundärschlüssel ist kein Schlüssel im engeren Sinne. Das geht aber heute so nicht aus der Definition im Artikel hervor. Ist aber zum Verständnis des Themas essentiell. -- sparti 23:35, 13. Jun. 2007 (CEST)

Ein Suchschlüssel ist auch kein Schlüssel im engeren Sinne. Eindeutigkeit ist nicht das einzige Merkmal einer Begriffsdefinition. JohnTB 09:22, 14. Jun. 2007 (CEST)

Nachtrag: Du sagst ein Sekundärschlüssel ist kein Schlüssel im engeren Sinne. Damit bin ich persönlich einverstanden. Aber es gibt auch namhafte Autoren, die das anders definieren:

Elmsri/Navathe. Fundamentals of Database Systems (3rd. ed.) p. 485: "If a relation has more than one key each is called a candidate key. One of the candidate keys is arbitrarily designated to be the primary key, and the others are calles secondary keys." Diese Definition steht im Widerspruch zu deiner Definition, was aber allen hier aufgeführten Definitionen gemeinsam ist: Der Sekundärschlüssel steht im Gegensatz zum Primärschlüssel. JohnTB 10:58, 14. Jun. 2007 (CEST)

Das stand mal ganz ursprünglich im Artikel. Aber damit stehen die Autoren scheinbar ganz allein. Daher hatten wir uns auch auf die Änderungen geeinigt. -- sparti 11:17, 14. Jun. 2007 (CEST)

PS: Aus meiner Sicht sind Suchschluessel und Sekundaerschluessel in einem Index sehr gut austauschbar. Beide Begriffe wurden hier mehrfach als Suchkriterium definiert, es sind also beide sehr gut zur Navigation in einem Baum geeignet. Warum auch sollte es einen Unterschied machen, ob ich mich an der Wurzel befinde oder an einem inneren Knoten? -- sparti 23:35, 13. Jun. 2007 (CEST)

"Suchschlüssel" und "Sekundärschlüssel" sollen also austauschbar sein? Dann tauschen wir die Begriffe doch mal in Deiner eigenen Definition aus. Resultat: "A search key is a non-unique attribute ...". Das ist falsch! Über die Eindeutigkeit eines Suchschüssels wird keine Aussage getroffen. JohnTB 09:22, 14. Jun. 2007 (CEST)

Also eben haben wir noch über einen B-Baum gesprochen. Dort ist er austauschbar!

Ganz nebenbei ist in meiner Sprache die Aussage, dass ein Suchschlüssel nicht eindeutig ist, nach wie vor richtig. Aber bitte, lass uns hier über Haarspaltereien nicht weitermachen.

Ich möchte die Diskussion abschließen und schlage daher folgendes Ergebnis vor:

Wie ich schon oben sagte ich verzichte auf eine Gleichstellung zwischen Sekundärschlüssel und Suchschlüssel. Es gibt in der Tat keinen Beleg dafür, auch wenn die Unterschiede marginal sind.

Es gibt keine einheitliche Definition von Sekundärschlüssel und Suchschlüssel. Die literarische Fundierung ist sogar insgesamt sehr, sehr dünn. Selbst nach Deiner Interpretation unterscheiden sich Inmon und Trautlof/Lindner in der Anzahl der Attribute. Und dann kommt noch Elmsri/Navathe dazu. Es gibt noch weitere stark abweichende Definitionen. Im Artikel sollte ein entsprechender Hinweis sein.

Einig sind sich aber fast alle Autoren, daß ein Sekundärschlüssel kein Schlüssel im engeren Sinne ist. Somit ist die Definition im Artikel unzureichend.

Soll ich es Anpassungen durchführen oder machst Du es? -- sparti 11:17, 14. Jun. 2007 (CEST)

Nachttrag: Auch im B-Baum Kontext sind die Begriffe nicht austauschbar und ich habe bereits erklärt warum. Ich kann auch für einen Primärschlüssel einen Index anlegen und dann suche ich nicht über einen Sekundärschlüssel in diesem Index. By the way: Auch der Wurzelknoten ist ein innerer Knoten - Aber das hat mit der Debatte hier eh nichts zu tun. JohnTB 10:58, 14. Jun. 2007 (CEST)

Ich rück mal wieder an den linken Rand, damit uns nicht der Platz ausgeht :-)

Zu blöd, ich hatte eine lange Antwort, aber ehe ich gespeichert habe, habe ich sie irgendwie verloren. Ich versuche, hier nochmal zusammenzufassen: Imho kommt es auf die Sichtweise an: formaltheoretisch vs. implementierungstechnisch.

Formaltheoretisch besehen hat imho "Sparti Recht", implementierungstechnisch JohnTB.

Formaltheoretisch betrachtet (also eben nicht unter Einbeziehung von implementierungsspezifischen Details) gibt es keinerlei Index o.dgl.! Die Definition (mehrfach nachlesbar, auch in o.a. Quellen) lautet sinngemäß: Ein Sekundärschlüssel ist geeignet, um Tupel zu beschreiben. Damit ist er genau das, was JohnTB als Suchschlüssel beschreibt. Erst durch Implementierungsaspekte kann man da einen Unterschied erkennen, aber als Enzyklopädietext besteht dieser Anspruch hier m.E. definitiv nicht!

Ja, ein Sekundärschlüssel ist ein Suchschlüssel. Gut. Das macht die Begriffe nicht synonym! Eine Kuh ist ein Lebewesen. Daraus folgt nicht, dass jedes Lebewesen auch eine Kuh ist.

Nein, nicht nur implementierungstechnisch gibt es einen Unterschied, sondern semantisch. JohnTB 13:13, 14. Jun. 2007 (CEST)

Implementierungstechnisch könnte man den Sekundärschlüssel als Index auffassen, der aber nicht auf die Datensätze verweist, sondern auf die Primärschlüsseleinträge, und erst die referenzieren die Dantesätze. (Das wäre dann auch die "Hilfsorganisation", das hat mich auch auf diesen Gedanken gebracht.M$-SQL Server macht das bspw. so) Nach wie vor: mit der derzeitigen Definition bin ich gar nicht sehr glücklich, weil ihr nichts zu entnehmen ist. B-Bäume u.dgl. haben auf dieser Seite m.E. nichts verloren, es geht hier um die Definition formaler Begriffe. Wie seht Ihr das? -- bg phaidros 12:19, 14. Jun. 2007 (CEST)

Ich habe das Beispiel mit dem Index nach der sovielten Erlärung nur gebracht um deutlich zu machen, dass die Begriffe nicht synonym sind. Natürlich hat das nichts im Artikel verloren. Auch völlig unabhängig von Implementierungsaspekten sind die Begriffe nicht synonym. JohnTB 13:02, 14. Jun. 2007 (CEST)

Ist schon klar, habe ich auch so aufgefasst. -- sparti 13:18, 14. Jun. 2007 (CEST)

Tut mir leid, kann ich nicht erblicken: Auch in Deiner Argumentation erwähnst Du irgendwann, dass der Sekundärschlüssel nicht in einem inneren Knoten des B-Baumes auftauchen kann. Das ist ein reiner Implementierungsaspekt. Bitte um Aufklärung: was ist ein Sekundärschlüssel in Deinen Augen? Der Definition im Artikel kann (vermutlich nicht nur) ich nämlich nichts entnehmen.

Hat bei mir auch ein bischen gedauert. Ich glaub jetzt hab ichs kapiert. Ein Sekundärschlüssel kann dann nicht verwendet werden, wenn es ein Primaerindex ist! -- sparti 13:18, 14. Jun. 2007 (CEST)

Tut mir leid: da ist schon wieder der Implemntierungsaspekt: denn der Primärindex hat hier einfach nix verloren. Nochmal: Formaltheoretisch besteht (sogar definitionsgemäß!) kein Unterschied zwischen Primärschlüssel und Schlüsselkandidaten. Sowie irgendwo ein Unterschied auftaucht, befinden wir uns im Implementierungsbereich. Und dort gehören wir nicht hin. -- bg phaidros 13:48, 14. Jun. 2007 (CEST)

@phaidros: Du hast recht es geht nicht um Implementierungsaspekte, und wenn du das aus meinem Beispiel rausliest, dann hast du es falsch verstanden. Es geht um die Verwendung der Bezeichnungen "Suchschlüssel" und "Sekundärschlüssel" in verschiedenen Kontexten. Bitte lies das Beispiel nochmal durch, oder ignorier es doch einfach. JohnTB 14:12, 14. Jun. 2007 (CEST)

Warum die Absätze entfernen, die Schlüsselkandidaten etc. näher erläutern? Gerade die schaffen Verständnis! Tut mir leid, in meinen Augen wird der Artikel durch Deine Änderungen derzeit laufend schlechter statt besser. Es dient nicht dazu, Leute zu befriedigen, die ohnehin schon wissen, wovon sie reden, sondern soll Unbedarften die Begriffe näher bringen! Das tut er weniger und weniger. Schade. -- bg phaidros 13:08, 14. Jun. 2007 (CEST)

Nachsatz: "Schlüssel im engeren Sinn" & "Schlüssel im weiteren Sinn" ist so glaube ich auch nicht in der Literatur zu finden. Wir sollten darauf verzichten. -- bg phaidros 13:12, 14. Jun. 2007 (CEST)

Mit den Änderungen bin ich weitgehend einverstanden, bis "im weiteren Sinne" und auf den Satz zum Primär Schlüssse: "darüber hinaus sollte darauf geachtet werden, dass der ausgewählte Primärschlüssel tatsächlich die eindeutige Identifizierbarkeit der realen Objekte erlaubt,". Statt sollte muß hier doch wohl "muß" stehen, richig? Gruss -- sparti 13:18, 14. Jun. 2007 (CEST)

Nachtrag: Hab ich erst gerade gesehen: Die Erläuterung zum Schlüsselkandidaten sollte unbedingt drinn bleiben. War das ein versehen? -- sparti 13:22, 14. Jun. 2007 (CEST)

Danke, Sparti. Ich hätte jetzt echt aufgegeben.

Zu "im weiteren Sinn": steht sinngemäss so auch im Kemper/Eickler.

Zu "muss" statt "sollte": Einverstanden. Habe ich geändert.

Zum entfernten Abschnitt: Es steht bereits ein Abschnitt zu Schlüsselkandidaten drin. Ausserdem stehn im entfernetn Abschnitt so irreführende oder falsche Aussagen drin wie: "Alle Schlüsselkandidaten sind somit Sekundärschlüssel." Wir haben doch gerade geklärt, dass der Primärschlüssel kein Sekundärschlüssel ist, er ist aber doch ein Schlüsselkandidat. Weiterhin war da zu lesen:"... Ein Fremdschlüssel ist ein Verweis auf den Primärschlüssel (bzw. Schlüsselkandidat) einer anderen Relation. Er ist also die Kopie dieses Schlüssels ...". Schluck. Das muss ich wohl nicht kommentieren. Ich finde nicht dass dieser Abschnitt etwas zur Begriffsklärung beiträgt. Gruss JohnTB 13:55, 14. Jun. 2007 (CEST)

Also zur Index Diskussion. Wenn man nicht auf die Unterscheidung zwischen Primaer- und Sekundärindex macht, dann spielt der Unterschied zwischen Such- und Sekundärschlüssel praktisch keine Rolle. Wenn man diesen Aspekt aber berücksichtigt, dann ergibt auch die Definition von JohnTB oben einen Sinn. Ob das jetzt bereits Implementierungsdetails berührt oder nicht, finde ich da nicht soo entscheidend.

Von mir aus, einverstanden: aber wir sollten darauf hinweisen! Der Unterschied wird dann schlagend, wenn Du versuchst, die Nuss formal zu knacken (und diese Situation vermute ich beim Leser). Da brauchst Du vorerst das zugegebenermaßen geringfügig gröbere Bild. Hast Du diesen Bissen verdaut, wirst Du auch die (Implementierungs)-Details verstehen. Ich bleibe dabei: die formale Defintion "Ein Sekundärschlüssel dient zum Beschreiben von Datensätzen" halte ich für richtig. In meinen Augen ist diese Unterscheidung "ja, aber kein Primärschlüssel" eine völlige Spiztfindigkeit, die keine relevanten Auswirkungen in der Datenbank entfaltet.

@phaidros: Entschuldige bitte, dass ich dich nochmal korrigiere - Es ist das letzte Mal. Du liegst hier falsch:

Du schreibst: "die formale Defintion "Ein Sekundärschlüssel dient zum Beschreiben von Datensätzen" halte ich für richtig". Das ist keine formale Definition, sondern ein Merkmal eines Sekunärschlüssels - Nicht die Begriffsdefinition. Ich habe hier nach wie vor noch keine Quelle gesehen, in der das als Begriffsdefinition drinsteht. Ich wollte diese Diskussion hier nicht, ich habe nur auf einen Fehler hingewiesen, und bekomme nun endlos "Contra" und am ende bin ich der Böse der die Experten mit "Spitzfindigkeiten" nervt. Und die Korrektur wird dann mit einem "Meinetwegen" gerade mal eben so hingenommen. Das brauche ich nicht. JohnTB 10:28, 15. Jun. 2007 (CEST)

@JohnTB: Keine Entschuldigung nötig - wo Du recht hast, hast Du recht: selbstverständlich ist das keine formale Definition, sondern nur eine schlampige Formluierung von mir. Was ich sagen wollte ist: "eine unter formalen Gesichtspunkten zu interpretierende Definition". Besser so? Denn ich will eben auf den Unterschied zwischen den formalen Überlegungen zu RDB-Konzepten und implementierungsspezifischen Details hinweisen. Das kann imho nämlich manchmal - eigentlich oft - den Blick verstellen! Und deswegen sollten wir sehr klar trennen, denn dann können wir ev. manchem Leser die Zeit bis zum Durchblick verkürzen. Nur darum geht's mir. Dass gerade beim Thema Datenbanken Spitzfindigkeiten angebracht und erwünscht sind, ist eben das Pech (oder Glück? - eben das Los) "unserer" Branche. Aber von "meinetwegen gerade mal eben so hingenommen" kann m.E. nicht die Rede sein: Du wurdest kein einziges Mal rückgebessert (jedenfalls nicht von mir), oder Dein Text irgendwie verändert oder sonstwas. Dass es hier tw. harte Diskussionen gibt, erachte ich als unser aller Ringen um höchstmögliche Textqualität, und habe selbst nicht das geringste Problem damit, auch meine eigenen, bescheidenen Beiträge auf Punkt und Komma durchdiskutieren zu müssen. Sparti kann Dir sicher bestätigen, dass uns so manche Erkenntnis gerade eben durch diese Diskussion gekommen ist! So lange Du uns nicht zeigen kannst, dass Du (mindestens) eine Stufe über uns stehst (was freilich sein könnte), sind da Kommentare wie "brauch ich nicht" eher nicht so angebracht. Zu den Quellen: Lies sie doch bitte einmal durch, bevor Du kommentierst, dass etwas nicht drin stünde. Es steht nämlich drin. Ich suche die Zitate jetzt nicht detaillierter heraus, denn ich bin zwar Lehrer, aber nicht Deiner. -- bg phaidros 10:58, 18. Jun. 2007 (CEST)

@phaidros: Hallo. Ich habe die angegebenen Quellen schon angeschaut. Da steht entweder fälschlich drin "Sekundärschlüssel = Fremdschlüssel" oder "Sekundarschlüssel ist ein nicht eindeutiger Suchschlüssel", was wie bereits erläutert noch restriktiver ist, als nur zu fordern Sek.Schl. <> Primärschlüssel. Nirgendwo, steht Sek.Schl. = Suchschl. Vielleicht habe ich was übersehen. Mit den bislang aufgeführten Quellen von meiner Seite dürfte die Fortführung dieser Diskussion aber eh nicht mehr notwendig sein.Nichts für ungut.Gruss.JohnTB 11:09, 19. Jun. 2007 (CEST).

@JohnTB: Hi nochmal. Dann bliebe also nur noch die Frage zu klären, wieso "Deine" Quellen besser sind als "meine" (immerhin 7 voneinander unabhängige). Sag, merkst Du da nix? Nichts für ungut. -- bg phaidros 15:58, 19. Jun. 2007 (CEST)

Meine Güte! Ich erhebe keinen Besitzanspruch auf irgendwelche Quellen. Abgesehen, von denen die da sagen "Fremdschl" = "Sek.Schl." widersprechen "Deine" Quellen "Meinen" in keiner Weise. Es steht aber nicht drin, wie du behauptest, dass Sekundärschlüssel und Suchschlüssel synonyme Begriffe sind. Weder in deinen noch in meinen Quellen. JohnTB 23:24, 19. Jun. 2007 (CEST).

Hey, ok es war eine schwere Geburt. Die Gleichheitsbehauptung stammte übrigens von mir, nicht von Phaidros. Ich sehe aber auch Phaidros Punkt, dass es ja theoretisch möglich ist, daß die oben genannte Quelle die einzig richtig ist. Das kann man eben nur durch den Vergleich mit mehreren Quellen feststellen. Ein "ich weiss aber, dass es so ist" ist eben auf der anderen Seite des Computers erstmal nicht nachvollziehbar, insbesondere wenn man gegenteilige Quellen vorliegen hat. Bis wir dann an einen Punkt kamen, wo wir einen ausreichenden Beleg für die Endfassung hatten, war es etwas zäh. Liegt aber wie ich schon sagte auch am Thema (insgesamt dünne Quellenlage) und dass man sowas eigentlich nicht übers Wiki diskutieren sollte. Ich finde das Ergebnis ist am Ende doch gelungen und (hoffentlich) ist der Artikel jetzt einiges richtiger geworden. Also lasst uns schauen, wos weiter geht. JohnTB kennst Du Dich mit Data Warehouses aus?

Ich gebe JohnTB auch recht, daß der gelöschte Abschnitt verbessert werden kann. Ich würde mir aber eben wünschen, daß er verbessert wird, statt ihn einfach zu löschen. JohnTB hast Du einen Vorschlag, wie man einen Fremdschlüssel intuitiver erklären kann?

Wieder einverstanden. (Obwohl: so falsch, wie JohnTB tut, ist die Definition nicht. Sie ist nur ungeschickt formuliert, denn gemeint war, dass die Werte kopiert werden - und das ist völlig richtig)

Den Hinweis, daß ein Primärschlüssel sich formal nicht von den anderen Schlüsselkandidaten unterscheidet finde ich sogar sehr wichtig. Bei mir hat sich am anfangs immer etwas Unsicherheit bei dieser Frage ergeben, da ja nicht klar ist, was der unterschiedet einen Primärschlüssel.

Genau so sehe ich das auch. Die erläuternden Texte haben wir uns ja mühsam abgerungen, weil mit den rudimentären Definitionstexten Verständnisprobleme blieben. Ich jedenfalls wurde *wiederholt* von meinen Studenten gefragt!

Die Aussage, daß alle Schlüsselkandidaten Sekundärschlüssel sind, kann man auch analog korrigieren.

Einverstanden! Das ist ja wirklich eine winzige Retusche. Obwohl ich gerne zugebe, dass hier I-Tüpfelchen-Reiterei *sehr wohl* angebracht ist.

Also ich möchte jetzt keine neue Grundsatzdiskussion starten. Aber vielleicht können wir absprechen, wie man den erläuternden Abschnitt wieder einbringen kann, so daß er den jetzigen Definitionen gerecht wird. -- sparti 15:04, 14. Jun. 2007 (CEST)

Genau so sehe ich das auch. -- bg phaidros 16:02, 14. Jun. 2007 (CEST)

Hallo JohnTB,

die Diskussion hier ist für alle beteiligten nervig. Das liegt aber weniger an Personen und deren Qualifikation. Ich habe den Eindruck wir sind da alle auf einem ausreichenden Level um hier sachlich und fair zu diskutieren. Das Problem sehe ich eher am Thema und dass ein Wiki als Medium völlig ungeeignet ist, um dieses hier zu diskutieren. Manches ist vielleicht spitzfindig, auf der anderen Seite haben wir hier ja eine Enzyklopädie, die zunehmend das Weltwissen beeinflusst (Ja das meine ich ernst). Das heißt wir tragen eine Verantwortung dafür, was wir hier schreiben. Also seien wir lieber einmal zu spitzfindig, als einmal zu nachlässig.

Mir wäre daher wohler, Du machst einfach einen Vorschlag, wie wir einen schlüssigen gut erläuternden Absatz wieder einfügen können. Ich hoffe ich finde im heute Abend die Zeit selbst einen Vorschlag zu unterbreiten. Gruss -- sparti 10:54, 15. Jun. 2007 (CEST)

Ja, der neue Absatz gefällt mir sehr gut. Genau das hat gefehlt. Vielen Dank. -- sparti 12:26, 15. Jun. 2007 (CEST)

gern geschehen. Gruss. JohnTB 11:09, 19. Jun. 2007 (CEST).

Unterschied Schlüssel / Schlüsselkandidat?

Was genau ist der Unterschied zwischen einem Schlüssel und einem Schlüsselkandidat? Ich habe mal versucht, die beiden gegebenen Definitionen in Punkt 1.1 und Punkt 3 in Prosa zu übersetzen. Bin aber in beiden Fällen auf das gleiche gekommen, nämlich:

„eine Kombination von Attributen, die für alle Tupel unterschiedliche, nichtfehlende Werte enthält, und zwar so, dass dies für keine echte Teilmenge der Attributkombination ebenfalls gilt.“

Irgendwas habe ich übersehen, wo ist der Haken? Danke und Gruss --Toni am See 06:43, 4. Jan. 2010 (CET)

Jeder Schlüsselkandidat ist ein Schlüssel aber nicht jeder Schlüssel ein Schlüsselkandidat. Wenn man den Primärschlüssel nicht mehr als Schlüsselkandidat versteht, kann ein Schlüssel entweder Primärschlüssel oder Schlüsselkandidat sein. Wenn man darüberhinaus nicht die Anforderung der Minimalität an einen Schlüssel stellt, wie es eigentlich üblich ist, hätte auch der Superschlüssel eine Schlüsseleigenschaft. Schlüsselkandidaten sind danach nur eine Teilmenge aller Schlüssel. Es geht aber auch um sprachliche Klarheit: man muß zwischen dem inflationär verwendeten Schlüsselbegriff und definierten Schlüsseleigenschaften unterscheiden. Zwar heißt ein Sekundärschlüssel auch Schlüssel aber es fehlt hier nach jeder bekannten Definition die Schlüsseleigenschaft. Verständnisprobleme können durch Konkretisierung umschifft werden. Alauda 00:00, 5. Jan. 2010 (CET)

Mir wird etwas schlüsselich, äh, schlüsselant. Halten wir fest:

Schlüsselkandidaten sind (…) eine (echte) Teilmenge aller Schlüssel.

Was mir irgendwie noch fehlt, ist ein Beispiel für einen Schlüssel, der aber kein Schlüsselkandidat ist. Kennt jemand solch ein Beispiel? Danke und Gruss --Toni am See 22:01, 5. Jan. 2010 (CET)

Alaudas Aesserung 'Jeder Schlüsselkandidat ist ein Schlüssel aber nicht jeder Schlüssel ein Schlüsselkandidat' macht keine zweckmässige Aussage, insbesondere weil mit Schlüssel irgendwas gemeint sein kann z.B auch ein Such- oder Sortierschlüssel, die Aussage an sich aber damit keinen praktischen Anwendungswert mehr erkennen lässt. Ich versuche deshalb, die Möglichkeit für ein pragmatisches Verständnis aufzuzeigen. Ich meine auch, zuerst ist die inflationäre Begriffsverwendung einzugrenzen. Ich verstehe das so: Die Begriffe Schlüsselkanditat und Primärschlüssel stehen zueinander in Beziehung. Beide bilden sich aus einer minimalen Menge von Attributen der Entität und erlauben eine eindeutige Identitfikation in der jeweiligen Entität - auch mit Blick in die Zukunft, wo kein Schlüsselbruch entstehen soll. Es kann im DB-Design mehrere Kandidaten geben für den Primärschlüssel. Sinnvollerweise wird aber im ganzen DB-System bzw. sogar systemübergreifend mit einem einheitlichen Primärschlüssel gearbeitet. Neben der Verwendung als Primärschlüssel wird die gleiche Domäne ja auch als Fremdschlüssel in referenzierenden Drittentitäten verwendet. Aufgrund des nicht nur eindeutigen sondern auch einheitlichen Objektidentifizierers sind durchgängige JOIN-Operationen auf allen betroffenen Entitäten möglich, ohne das zwischen verschiedenen äquivalenten Schlüsselkandidaten übergeschlüsselt werden muss. Den Satz von Alauda lässt sich dann zweckmässig umformulieren als: 'Jeder Primärschlüssel ist ein Schlüsselkandidat, aber nur ein Schlüsselkandidat wird als Schlüsselkandidat verwendet'. Verwende ich in verschiedenen Drittentitäten unterschiedliche Schlüsselkandidaten um z.B. die Entität Kundenauftrag zu referenzieren, habe ich ein inkonsistentes und unzweckmässiges Datenmodell vorliegen und es wäre eine Schlüsselharmonisierung angebracht. ollio 16:55, 11. Feb. 2011 (CET)

"Minimal"

Artikel:

Minimalität

Keine echte Teilmenge von S erfüllt bereits die Bedingung der Eindeutigkeit.

Das ist für einen Schlüssel wünschenswert, aber nicht notwendig. Aus z.B. fachlichen Gründen kann man als (Primär-)Schlüssel durchaus auch etwas wählen, was neben den (zur eindeutigen Unterscheidung) notwendigen Spalten auch (zur Unterscheidung) nicht-notwendige Spalten hinzu nimmt.

Im Artikel wird so getan, als sei die Minimalität eine Notwendigkeit. Bitte korrigieren.

--arilou (Diskussion) 12:02, 16. Nov. 2015 (CET)

Artikelqualität/Verständlichkeit

Habe den Eindruck, als wenn Teile des Artikels so geschrieben wurden, dass sie möglichst wenige verstehen, die sich noch nicht intensiv mit Informatik auseinander gesetzt haben... 79.205.236.72 10:42, 21. Jan. 2016 (CET)

Bitte detailliertere Kritik, in welchen Abschnitten was Verständnisprobleme/Widersprüche verursacht.

Auf eine Allgemein-Kritik ist es schwer zu reagieren.

--arilou (Diskussion) 15:02, 2. Feb. 2016 (CET)

"Um mitzuteilen, welchen der Schlüsselkandidaten man zur Identifikation der Tupel in einer Relation bevorzugt, wird aus allen Schlüsselkandidaten der Primärschlüssel ausgewählt. "

das ist sprachlich recht schief.

Jwalter (Diskussion) 11:10, 9. Feb. 2017 (CET)

Das ist eine konkrete Kritik (und ich seh' das genauso, der Satz ist echt ziemlich "schief"), und ich habe den Artikel (hoffentlich) dahingehend verbessert. --arilou (Diskussion) 14:36, 9. Feb. 2017 (CET)

Unterschied Schlüssel / Superschlüssel?

Die Artikel-Einleitung definiert "Schlüssel" wie folgt:

Gruppe von Spalten, die so ausgewählt wird, dass jede Tabellenzeile über den Werten dieser Spaltengruppe eine einmalige Wertekombination hat

Der Abschnitt Einführung definiert den Begriff "Superschlüssel" wie folgt:

Menge von Attributen (Feldern) in einer Relation (Tabelle), die die Tupel (Zeilen) in dieser Relation eindeutig identifizieren

Hört sich so an, als ob beide Begriffe dasselbe bedeuten. Aber wenn das so ist, warum wird es nicht ausdrücklich gesagt?

Auch anderswo im Netz scheint da Verwirrung zu herrschen:

• Die Englische Wikipedia deutet in der Einleitung zum Artikel Unique key an, dass "Unique key" und "Key" und "Superkey" Synonyme seien - hat dann aber trotzdem einen separaten Artikel Superkey, der nicht weiter auf den Zusammenhang eingegeht.
• Eine StackExchange-Antwort definiert "super key" als einen Schlüssel, der nicht minimal ist (also kein Schlüsselkandidat sein kann).
• Eine andere, als Menge aller möglichen Schlüssel einer Relation.

Was ist nun richtig? Kann jemand der sich auskennt, bitte diesen Artikel editieren um das klar zu machen? --79.227.176.47 09:05, 9. Okt. 2017 (CEST)

Nicht jeder "Fachbegriff" ist eindeutig definiert, so mancher wird von verschiedenen Menschen widersprüchlich verwendet.

Wichtig ist, dass dem Leser klar wird, dass ein Schlüssel a) eine Eindeutigkeit beschreiben/herstellen soll und b) zugleich (leider) auch nicht-minimal sein kann.

Des weiteren lernt man die Bedeutungen der Fachbegriffe aus seinem Vorlesungsskript, und gibt sie dann genau so in der Prüfung wieder, um selbige zu bestehen...

--arilou (Diskussion) 16:21, 19. Okt. 2017 (CEST)

"Du sollst nicht haben andere Chefs neben mir"-Prinzip; Version 182234546 vom 28.10.18

Ich habe das geändert, weil - wie ich finde, korrekterweise - im übrigen Text im Zweifelsfalle das Primat der fachlich-inhaltlichen Adäquanz angewendet wurde. Fachlich-inhaltlich kommt es im Regelfall nicht vor, daß ein und derselbe MA (hier: 512) zwei direkte Vorgesetzte hat. --NameDerGeht2018 (Diskussion) 17:28, 28. Okt. 2018 (CET)

Die Relation heißt ja auch nicht "istDirekterChefVon", sondern "istChefVon". Und Chefs haben die meisten Arbeitnehmer dann doch mehrere - mehrere Hierarchie-Ebenen.

--arilou (Diskussion) 13:52, 29. Okt. 2018 (CET)

Nein, eben nicht. Wir argumentieren hier fachlich-inhaltlich. Und da ist es gewöhnlich so, daß der MA nur operative Anweisungen von seinem direkten Vorgesetzten erhält. Insofern gibt es fachlich-inhaltlich gar keine Beziehung zwischen dem MA und den "höheren" Vorgesetzten gar keine abzubildende Beziehung.

Sieht man es hingegen ausschließlich aus DB-Sicht, ist eine Tabelle in "deinem" Verständnis ohnehin ein Design-Fehler, ihr Inhalt ist auf Grundlage einer Abfrage darzustellen. Voraussetzung dafür ist, daß alle Vorgesetzten auch als Mitarbeiter geführt werden (in der Relation Mitarbeiter, die es hier nicht gibt, in der Realität schon, weil in der gezeigten Tabelle die Schlüssel nur Fremdschlüssel sind). In der gezeigten Relation fehlen dann lediglich die Mitarbeiter, die auf der höchsten Hierarchieebene sind. Die genannte Abfrage benutzt - wenn nötig mehrfach - einen Selfjoin.

Insgesamt wäre es besser, hier ein ganz anderes Beispiel zu wählen, habe ich aber keine Zeit für.

Ich werde jetzt deinen Revert revertieren und bitte Dich, das nicht als persönlichen Affront zu werten oder als Auftakt zu einem Edit-War.

--NameDerGeht2018 (Diskussion) 14:47, 29. Okt. 2018 (CET)

Ich weiß ja nicht, in welcher Welt du lebst, aber in allen Firmen, in denen ich bisher gearbeitet habe, darf (und tut gelegentlich) der Chef-Chef (oder Chef-Chef-Chef) direkt einem Unter- oder Unter-Untergebenem Anweisungen erteilen. Nennt man "durchregieren". Stellt auch eine Beziehung dar/her.

Mir schlechtes DB-Design vorzuwerfen, betrachte ich sehrwohl als persönlichen Affront.
Das DB-Design hängt davon ab, welche Informationen die DB erfassen soll, und welche Abfragen sie erlauben soll. Daher ist ein bestimmtes DB-Design nicht per-se "fehlerhaft", nur weil eine bestimmte Abfrage nicht möglich sein mag.

--arilou (Diskussion) 15:23, 29. Okt. 2018 (CET)

Nachtrag: In vielen Firmen gibt es nicht nur disziplinarische, sondern auch noch fachliche Vorgesetzte; ebenfalls direkt oder indirekt. Sind auch Mitarbeiter mit "istChefVon", ja sogar "istDirekterChefVon" -Beziehung zu untergebenen Mitarbeitern. Wer nicht genau in nur 1 Fachgebiet arbeitet, kann dann auch mal 3 'direkte Vorgesetzte' haben - einen disziplinarischen und zwei fachliche...

Vorweg und wichtigster Punkt: Wenn du dich trotz meiner Bitte persönlich angegriffen fühlst, tut es mir wirklich aufrichtig leid. Für mich ist das ein sachlich begründeter Standpunkt, daß es sich bei der Tabelle um einen Design-Fehler handelt und habe deshalb auch die Spaltenüberschriften geändert. Dazu kann man andere Auffassungen haben, aber das dann als persönlichen Affront zu sehen, will mir nicht so recht eingehen. Aber ich respektiere deine Reaktion und entschuldige mich für diese bei größerer Umsicht vielleicht vermeidbare "Konfrontation".

Ansonsten bin ich, was die fachlich-inhaltliche Sicht betrifft, viel mehr bei dir als du ahnst: Ich stehe kurz vor dem Eintritt ins Rentenalter und denkst du etwa, da hätte ich nicht all diese Erfahrungen, die du aufzählst gemacht und noch viel mehr?! Ich war selbst 9 Jahre "Chef" und habe andauernd "durchregiert". Und wehe, einer hätte das infrage gestellt!... Guter Stil ist das nicht, aber das steht hier überhaupt nicht zur Diskussion.

Maßgeblich ist hier a. daß bei der Abbildung betrieblicher Gegebenheiten im Zusammenhang mit Dingen wie "Chef" usw. die Aufbauorganisation im Vordergrund steht und b. es sich ja hier um ein Beispiel handelt und die sollen erstens einfach sein und zweitens sich am "Modellfall" des betr. Sachgebiets orientieren.

Ich bleibe dabei: Es ist einfach ein schlecht gewähltes Beispiel.

Ansonsten: Wir sind nicht so weit auseinander - auch z.B. der Unterschied zwischen Dienstvorgesetztem und Fachvorgesetztem blieb in meinen Ausführungen bisher zu Unrecht unerwähnt usw. usf.

Ich habe nur die Bitte an dich: Laß es jetzt so, wie es ist, denn jetzt ist es erstmal in sich widerspruchsfrei. Ich bin gerade dabei, einen Datenbankkurs vorzubereiten und mir fällt sicher noch ein besseres Beispiel ein, das ich dann als Ersatz einfügen werde. Dir einen schönen restlichen Nachmittag und Abend! --NameDerGeht2018 (Diskussion) 15:56, 29. Okt. 2018 (CET)

Widersprüchliche Begriffe und -Definitionen

Beginnen wir mit Sekundärschlüssel. Ich weiß, da oben wurde schon mal drüber diskutiert. Mein Problem ist jedoch:

• Was hier als Sekundärschlüssel definiert wird, ist kein Schlüssel. Der englische Name dieses Artikels (unique key) macht deutlich, dass ein Schlüssel eindeutig ist.
• Es gibt in der Wikipedia die Artikel Sekundärschlüssel und Index. Ich würde diese Lemmata nach den Definitionen als synonym bezeichnen. Der letztere Artikel ist technischer, von meinem Empfinden her würde ich beide jedoch zusammenlegen und (Datenbank-)Index nennen, auch um den Begriff Schlüssel loszuwerden.

Kommen wir zum Begriff Alternativschlüssel. Hier scheint es verschiedene Definitionen zu geben:

steht wo	kann gleichzeitig PK sein?	muss minimal sein
Abschnitt „Einführung“ definiert ihn als Synonym für Schlüsselkandidat	ja	ja
konkrete Implementierung in Datenbanksystemen (als UNIQUE)	müsste man getrennt voneinander anlegen	nein, kann das System aber auch nicht wissen
Abschnitt „Primärschlüssel und Alternativschlüssel“ – „alle anderen Schlüsselkandidaten“	nein	ja

Jetzt kommt noch dazu, dass die englische Wikipedia Schlüsselkandidaten unique key nennt, aber wenn ich in einem Datenbanksystem einen unique key anlege, ist dieser selbst niemals der Primärschlüssel (der müsste manuell angelegt werden) und zudem nicht minimal. Der englische Artikel beschreibt – obwohl er hier verlinkt ist – somit leider auch nicht den Begriff Superschlüssel, den dieser Artikel – richtigerweise – zusammen mit Schlüsselkandidaten unter dem Lemma Schlüssel behandelt. Die beiden Artikel sind somit nicht exakt deckungsgleich.

Im Abschnitt „Einführung“ steht, nur Primärschlüssel seien geeignete Fremdschlüssel, im Abschnitt „Primärschlüssel und Alternativschlüssel“ steht im letzten Satz, auch Alternativschlüssel könnten Fremdschlüssel sein.

Kommen wir zum Superschlüssel. „Ein trivialer Superschlüssel wäre zum Beispiel die Menge aller Attribute einer Relation gemeinsam. Ein trivialer Superschlüssel wäre zum Beispiel die Menge aller Attribute einer Relation gemeinsam. (Trivial deswegen, weil eine Relation eine Menge von Tupeln ist. Die Elemente von Mengen müssen eindeutig sein, also darf es in einer Relation keine zwei gleichen Tupel geben.)“ Wer sagt, dass eine Relation eine Menge sein muss (weshalb Tupel eindeutig sind)?

Jetzt kann man sich ganz naiv fragen, was eigentlich der Unterschied zwischen Primärschlüssel und Schlüsselkandidaten ist. Es gibt höchstens einen Primärschlüssel pro Relation, das ist klar, aber was macht ihn besonders? Und hier wird’s dann in Sachen Theorie sehr problematisch, da das vom praktisch eingesetzten Datenbanksystem abhängt, wo die funktionalen Unterschiede liegen:

• In SQL Server ist die Tabelle nach dem PK sortiert, wenn man nichts anderes angibt. UNIQUE-Indizes können 1 NULL enthalten, Primärschlüssel gar keine.
• In MySQL (und ANSI-SQL) können UNIQUE-Constraints mehrere NULLs enthalten.

Zumindest in der SQL-Server-Terminologie scheint man sich nicht klar darüber zu sein, ob man nicht-primäre Schlüssel unique key (so heißt es in der GUI), unique index (so heißt es in der Syntax) oder unique constraint (so heißt es in der Doku) nennen will.

--Яedeemer 19:34, 11. Okt. 2019 (CEST)

Ich hab' deine Kritik nicht komplett durchgeprüft; zur Ursache vermute ich mal, dass (leider) oft auch beim Suchen und Sortieren von "Suchschlüssel" und "Sortierschlüssel" die Rede ist, anstatt über "Suchkriterium" und "Sortierkriterium" zu sprechen. Übrigens durchaus auch im Englischen, die haben auch "searching keys", auf die es dann mehrere Suchtreffer geben kann. Ein englischer 'key' ist also ebenfalls nicht immer 'unique', wenn's nicht extra dazugenannt wird...

--arilou (Diskussion) 14:06, 30. Okt. 2019 (CET)

Primärschlüssel, Alternativschlüssel, Kandidatschlüssel...

Meinem Verständnis nach sind Kandidatschlüssel die Kombination aus Primärschlüssel und Alternativschlüssel, da eine Alternative ja ein Subjekt haben muss, zu dem es eine Alternative ist. Das widerspricht der Formulierung "Schlüsselkandidat (auch Kandidatenschlüssel oder Alternativschlüssel genannt)"

Weiterhin steht beim Primärschlüssel: "Die Werte dieses Schlüssels werden in referenzierenden Tabellen als Fremdschlüssel verwendet." Ich denke, es ist irreführend, dies unter Primärschlüssel zu zeigen, wenn Fremdschlüssel auf beliebige Kandidatschlüssel zeigen können. So steht es z. B. auch auf der englischen Seite: "a foreign key is a set of attributes that references a candidate key" (nicht signierter Beitrag von Makrom (Diskussion | Beiträge) 20:53, 8. Jun. 2020 (CEST))

In meiner Ausbildung war da allerdings noch ein -hm- zeitlicher Aspekt mit dabei:

Wenn ich eine neue Datenbank anlegen will, um einen ("wilden") Datenbestand aufzunehmen, dann muss ich diese Daten erst einmal "in Ordnung" bringen (Redundanzen finden, entfernen, die Daten in Tabellen aufteilen, Spaltennamen finden/ausdenken, ...). Und dabei stellt sich dann irgendwann das Problem, dass für die Tabellen ja auch Schlüssel benötigt werden. Möglicherweise gibt es verschiedene Spalten(kombinationen), die sich theoretisch als Schlüssel eignen würden - sie sind Kandidaten für meine "Wahl" eines Primärschlüssels (die ich ja erst noch treffen muss). Dann wäge ich ab, welcher Kandidatschlüssel mir am geeignetsten erscheint, und küre ihn zum Primärschlüssel. Evtl. ist für manche Aufgaben aber ein anderer Kandidat doch besser geeignet, dann bestimme ich diesen zum Alternativschlüssel. Die restlichen Kandidatschlüssel landen in Ablage-Rund.

Natürlich waren (und sind für alle Zeiten) Primärschlüssel und Alternativschlüssel auch immer 'Kandidaten' - aber die Wahl ist inzwischen passée.

Möglicherweise gibt's aber noch Tabellen (aus früheren Zeiten), die (als "Fremdschlüssel") eine andere Spaltenkombination beinhalten, um auf meine neue Tabelle zu verlinken. Das ist dann einer von den alten 'Kandidaten', sollte eigentlich auf den mittlerweile festgelegten Primärschlüssel geändert werden, muss aber nicht zwingend.

Ein Kandidatschlüssel heißt 'Kandidat', weil er bei der (noch ausstehenden Wahl des Primärschlüssels) als Wahl-Kandidat zur Verfügung steht.

Sobald die Wahl gelaufen ist, ist 'Kandidatschlüssel' (nur noch) die Menge aller (ehemals) möglichen verschiedenen Schlüssel für eine Tabelle. (Zu dieser Menge gehören natürlich - auch nach der Wahl immernoch - Primärschlüssel und alle gewählten Alternativschlüssel.)

--arilou (Diskussion) 09:34, 9. Jun. 2020 (CEST)