Primärschlüssel identifizieren

[thehasso]

Hallo zusammen,

leutz ich hab ne Frage und zwar würd ich gern wissen, wie man wenn man eine Relation sind also eine Tabelle welche der Primärschlüssel ist. Der Primärschlüssel kann bei den Aufgaben auch eine Kombination von mehreren Schlüsseln sein. Leider weiß ich nie genau welches Attribut die nicht Schlüsselattribute Identifiziert.

Hinweis vom dozent ist das der Prämärschlüssel bzw. Schlüsselkombination eindeutig und Minimal sein muss.

http://www.bilder-space.de/show_img.php?img=f56b21-1276110850.png&size=original

das Bild ist das beispiel!

Ich hätte gedacht die RIchtige Lösung wär, Kundennummer und Artikelnummer.

Da wenn man identifizieren will, welcher Kunde welche Artikel_ID gekauft hat sind diese beiden ID zu gebrauchen! Von Artikel_ID schließt man ja auf die Artikelgruppe und von der Artikel-ID und Kundennr auf die Menge, die ein Kunde an gekauften Artikel gekauft hat.

Weshalb Datum, noch als Schlüssel vorkommt, ist mir nicht ganz klar?

Ich danke im voraus!

 

[FrankBooth]

Hallo,

da du offensichtlich nicht ließt, was du postest ist es sehr schwer zu sagen, was du willst.

Wenn ich mir das Bild ansehe, kann ich nur denken das ist alles Käse.
Ein Kunde kann theroretisch an dem selben Tag 2 mal die gleiche Bestellung aufgeben. Dann kannst du mit den Felden nichts eindeutig identifizieren.


Wenn Datum ein Timestamp ist, also mit Uhrzeit, liegst du richtig. Dann ist es Kundennummer, Artikelnummer und Datum mit Uhrzeit. Wobei ich davon ausgehe, dass eine Bestellung auch mehrere Artikel enthalten kann. Sonst sollte Datum und Kundennummer reichen.

 

[thehasso]

Hallo,

Ja, das Datum soll ein TImestamp sein.

Ein Kunde kann theroretisch an dem selben Tag 2 mal die gleiche Bestellung aufgeben. Dann kannst du mit den Felden nichts eindeutig identifizieren.

Also nehmen wir mal an das sind die beiden Bestellungen die an dem selben Tag bestellt wurden.

Wenn ich nur die Kundennummer als Primärschlüssel hätte, hätte ich 2 Ergebnisse also nicht eindeutig! Da immer 1 Ergbnis raus ermittelt werden muss bei einen eindeutigen Primärschlüssel.

Bei Kundennummer und Artikelnummer hät ich das selbe Problem.

Wieso reicht dann nicht nur das Datum aus? Damit kann man doch ermitteln welcher Kunde welchen Artikel gekauft hat. Aber halt nur ein Artikel. Man muss aber die möglichkeit haben einen oder mehrere zu ermitteln oder ? Deswegen dann Datum und Kundennr wie du zuletzt sagtest:

Select * FROM Bestellung WHERE Kundennr = 55 AND Datum 22.12.2001 12:04:11 OR Datum = 22.12.2001 13:04:13;

Kundennr 55
Artikelnummer 211
Artíkelgruppe Iphone
Menge 10
Datum 22.12.2001 12:04:11

Kundennr 55
Artikelnummer 211
Artíkelgruppe Iphone
Menge 10
Datum 22.12.2001 13:04:13

Kundennr 599
Artikelnummer 211
Artíkelgruppe Iphone
Menge 10
Datum 22.12.2001 13:04:13

Dann versteh ich aber nicht weshalb Artikelnummer noch hinzugefügt wurde. Ein anderes Ergebnis sollte Falsch sein.

Nochmals lieben dank, aber tu mich wie gesagt etwas schwer....

MFG

 

[FrankBooth]

Der Schlüssel soll minimal sein, also so wenig Felder wie nötig.


Der Primärschlüssel bedeutet, dass durch ihn ein Datensatz eindeutig ist.
Wenn eine Bestellung nur ein Artikel sein kann, muss Datum mit Kundennummer reichen. Eine Person kann nicht zwei Bestellungen gleichzeitig ausführen.

Normalerweise würde man ja sagen, Kunde 55 will Artikel 1 10*, Artikel 2 20* und Artikel 3 30*. Das klickt er sich in einem Formular zusammen und sendet es ab. Das führt zu den Einträgen:

Kundennr 55
Artikelnummer 1
Artíkelgruppe Iphone
Menge 10
Datum 22.12.2001 12:04:11

Kundennr 55
Artikelnummer 2
Artíkelgruppe Bphone
Menge 20
Datum 22.12.2001 12:04:11

Kundennr 55
Artikelnummer 3
Artíkelgruppe Cphone
Menge 30
Datum 22.12.2001 12:04:11

Dann brauchst du alle 3 als Primärschlüssel.

 

[gorefest]

*lol* so eine weltfremde tabelle.

wo ist denn die referenz auf den bestellvorgang? wenn da bestellungen drin gehalten werden sollen, dann braucht man für _den bestellvorgang_ mindestens folgende attribute :

1. datum / uhrzeit
2. umsatzsteuersatz
3. lieferadresse

da diese referenz aber in der von dir aufgeführten tabelle fehlt, musst du wohl den timestamp mit in den PK nehmen und das wiederum ist von der logik her absoluter blödsinn, da du zur eindeutigen identifikation deines datensatzes den sekundengenauen timestamp kennen musst. ansonsten kann ein kunde einen artikel genau nur einmal bestellen.

kurzum: realtitätsfremde tabellendefinition.

dein dozent sollte wissen, dass man bei codd'scher normalisierung nicht nur irgendwelche nur akademischen spielchen treibt, sondern vor allem redundanzen vermeiden und für die genaue identifizierbarkeit eines records sorgen muss.

das ist mit einem timestamp - der nichts anderes als ein generiertes hilfskonstrukt ist - überhaupt nicht möglich.

grüße
gore

 

[vfl_freak]

Moin,

schau mal hier:
http://de.wikipedia.org/wiki/Schlüssel_(Datenbank)

BTW: ob die Tabelle nun weltfremd ist oder nicht, lassen wir mal dahingestellt sein ... sie erfüllt aber IMHO durchaus ihren Zwecke als Übung !

Gruß
Klaus

 

[gorefest]

Jein

Übungen sollten was mit der Realität zu tun haben. Ausserdem ist ein Timestamp ein alternativsurrogat und damit ist

"welche die Identifizierung der Tupel ermöglicht (Schlüsselkandidaten ? Superschlüssel)."

nicht mehr erfüllbar.

Genauso wenig ist ein AUTO_INCREMENT ein Primary Key, sondern nur ein Surrogat. Ein Primary Key für eine Entität muss logisch auflösbar sein und darf keine Generate enthalten.

 

[FrankBooth]

Hallo,

wenn ich mich da mal mit meiner bescheidenen Meinung einmischen darf. Ich denke es wird an dieser Stelle etwas spitzfindig und imho ist der primary key der, den ich als pkey definiere.

Wenn ich eine Tabelle habe die eine id besitzt, die aus einer sequenz generiert wird und habe in meine Tabellendefinition stehen:

CREATE TABLE table_name
(id number not null,
...
CONSTRAINT constraint_name PRIMARY KEY (id)
);

dann ist es trotzdem mein pkey, auch wenn es inhaltlich nur ein surrogat ist . Das ist übrigens ein Beispiel aus der Realität

Damit müßte für

Genauso wenig ist ein AUTO_INCREMENT ein Primary Key, sondern nur ein Surrogat

auch jein gelten.

Grüße

 

[Sven Mintel]

Vielleicht ist das einfach eine Fangfrage.

Ich glaube, wir sind uns da eigentlich einig, dass sich anhand der Felder kein Datensatz eindeutig identifizieren lassen wird....warum also versuchen, etwas anderes zu Behaupten

 

[gorefest]

100% ack ;-)