Mal eben diese simple Frage…
Beide stellen doch die Eindeutigkeit klar, oder?
Kann / sollten der PK / UK unterschiedlich sein. Dient der UK „nur“ dazu, den IndexTablespace zuzuweisen?
Danke für die Nachhilfe…!!
Chris
Mal eben diese simple Frage…
Beide stellen doch die Eindeutigkeit klar, oder?
Kann / sollten der PK / UK unterschiedlich sein. Dient der UK
„nur“ dazu, den IndexTablespace zuzuweisen?Danke für die Nachhilfe…!!
Hallo.
Eindeutigkeit ist nur ein Kriterium. Nach der reinen Lehre (ommmmm) soll der Primary Key nicht an Dateninhalte geknüpft sein, u.a. wegen der Schwierigkeiten bei Format- oder Datenbereichsänderungen.
Außerdem ist es häufig sinnvoll, mehrere Felder mit Non Unique-Indes zu einem Unique Index zusammenzufassen (bleistiftsweise ein NU-Index auf Nachname+Vorname und einen Unique Index auf Nachname+Vorname+Geburtsdatum). In der gleichen Tabelle sind auch mehrere Unique-Indizes denkbar, damit wird dann allerdings die wasweißichwievielte Normalform verletzt, bin jetzt zu faul zum Nachschlagen (bumm).
Beides verwenden, und den PK automatisch vergeben lassen, ist der Weg, der zum Heile führet.
Gruß kw
danke!
das rückt mein schwaches weltbild doch wieder gerade… auch pks werden ja wohl manchmal auf mehrere columns vergeben…??? so wie du’d schreibst, hab’s bisher auch gedacht und denke es jetzt wieder…
chris
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
danke!
Gern geschehen.
das rückt mein schwaches weltbild doch wieder gerade… auch
pks werden ja wohl manchmal auf mehrere columns
vergeben…???
Es gibt nix, was es nicht gibt, aber :
Nach der reinen Lehre (ommmmm) soll der Primary Key nicht an Dateninhalte geknüpft sein, u.a. wegen der Schwierigkeiten bei Format- oder Datenbereichsänderungen.
Gruß kw
ja, ja das „auch“ sollte eigentlich „aber“ heissen und meinte die Praxis einiger Leute bzw. auch die Möglichkeit z.B. im Oracle Designer (CASE-Tool) mehrere Columns als PK zu definieren; wie gesagt: find’ ich auch blöd:smile: und hatte mich eben verwirrt.
… ich erinnere mich (aber), dass in einem design-kurs mal stand, dass der pk ein nicht-sprechender schluesseln „sein sollte“ , bzw. man sich das angewöhnen „solle“… in der praxis eben wegen immer wieder und nicht abzustellender aenderungen sehr nachvollziehbar! klang für mich dort nicht wie „reine lehre“, eher wie „praxis-empfehlung“;
wenn es aber so korrekt/reine lehre ist, dann finde ich das gut und nachvollziehbar und mache es bei meinen „first steps“ so oder so so…
gruesse, chris
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo zusammen!
Ein Schlüssel identifiziert ein Tupel eindeutig. Jetzt kann es vorkommen, dass mehrere Attribute diese Anforderung erfüllen. Dann nennt man beide Attribute Schlüsselkandidaten. Eines dieser beiden Attribute sucht man sich dann aus, um die referentielle Integrität (Schlüssel-/Fremdschlüsselbeziehungen) zu realisieren, dieses Attribut ist dann der Primärschlüssel (primary key). So weit, so gut.
Von dem zweiten Attribut weiß man aufgrund der zu modellierenden Semantik, dass die Werte ebenfalls eindeutig sein müssen. Um diese Eigenschaft sicherzustellen, kreiert man einen unique index oder einen unique constraint. unique constraint ist in meinen Augen sauberer, da Sinn und Zweck dieser Maßnahme deutlich werden: Ich definiere eine Eigenschaft, der die Daten entsprechen müssen.
Beispiel Personaldaten: Dann ist typischerweise die Mitarbeiternummer der Prmärschlüssel. Wird jetzt auch noch die Personalausweisnummer geführt, dann kann es Sinn machen, darauf einen unique constraint / unique index zu setzen.
ciao,
Bernhard
natural vs virtual key
Hi,
vielleicht wird’s jetzt ein wenig off topic, aber et muss mal gesaacht wern: Die künstlichen Schlüssel entbinden den Designer nicht von der Pflicht, sich über die Identität eines Tupels Gedanken zu machen.
… ich erinnere mich (aber), dass in einem design-kurs mal
stand, dass der pk ein nicht-sprechender schluesseln „sein
sollte“ , bzw. man sich das angewöhnen „solle“…
Wenn in der Personaldatei der Heinerich (Tschulljung) zum zwölften Male auftaucht, nur weil der Schlüssel automatich vergeben wird (zB „Zähler“ in MSAccess), dann läuft was schief. Meine Empfehlung: Zu jedem Objekt den natürlichen Schlüssel dokumentieren, also die Eigenschaften, die den unique key bilden könnten , und daraus die Regeln für die Neuvergabe eines virtual key ableiten.
zu primary vs unique:
- Der primary key ist der einzige, auf den sich die referentielle Integrität bezieht, und er muss nicht unique sein. Ob das sinnvoll ist, ist eine andere Frage.
- Eine Tabelle kann beliebig viele unique keys haben. Einen Verstoß gegen die Normalformen 1-3 sehe ich hierin nicht; weitergehende NFs sind wohl eher akademischer Quark.
Mit relationalem Gruß
Ralf