Join-Tabelle hat zusammengesetzte PK`s ???

[pel]

Hallo Allerseits

In meinen Lernunterlagen/Datenbank-Buch finde eine M:N Beziehung die mich verwirrt...

Mitarbeiter (PersonalNr , Name , Vorname , AbtNr, AbutBezeichnung)

Projekt (ProjNr , ProjektBeschreibung)

TätigkeitMA (PersonalNr , ProjNr , Tätigkeit ) (JOIN-Tabelle)

Warum wird hier ein zusammengestzter Primärschlüssel benutzt der sich aus beiden PK`s der anderen Tabellen zusammensetzt, anstatt einen künstlichen PK wie TätigkeitMA_ID zu nehmen? Weiterhin frage ich mich bzw. eigentlich müssten die beiden PK`s doch Fremdschlüssel sein... jeder zeigt auf seine Tabelle bzw. deren Tupel.

[Gast Hornochse]

Das sind auch beides Fremdschlüssel, wenn man sie je für sich sehen würde. Da man die beiden aber zusammen nimmt und so eine einzigartige Beziehung entsteht, braucht man keinen "neuen" Primärschlüssel, sondern fasst diese beiden zu einem Primärschlüssel zusammen.

[pel]

Das sind auch beides Fremdschlüssel, wenn man sie je für sich sehen würde. Da man die beiden aber zusammen nimmt und so eine einzigartige Beziehung entsteht, braucht man keinen "neuen" Primärschlüssel, sondern fasst diese beiden zu einem Primärschlüssel zusammen.

ja aber ich kann sie nur auf eine Art sehen und zwar so wie sie dargestellt werden nämlich unterstrichen, als ist es ein zusammengesetzter PK und keine FK`s so sehe ich das?!

[flashpixx]

ja aber ich kann sie nur auf eine Art sehen und zwar so wie sie dargestellt werden nämlich unterstrichen, als ist es ein zusammengesetzter PK und keine FK`s so sehe ich das?!

Auf Deiner "TätigkeitMA" ist der PK der zusammengesetzte Schlüssel aus

PersonalNr + ProjNr. Das sind die einzelnen PKs der beiden Tabellen, denn andernfalls könntest Du nicht eindeutig zuordnen, was dem PK widerspricht.

Du könntest natürlich auch einen FK über die jeweiligen Felder anlegen und einen eigenen PK genieren, aber wie stellst Du die Verbindung her !? Im Grunde immer über die zusammengesetzten Felder, d.h. Du hättest mit einem eigenen Schlüssel eine unnötige Information, die nicht nötig ist

Phil

[pel]

Du könntest natürlich auch einen FK über die jeweiligen Felder anlegen und einen eigenen PK genieren, aber wie stellst Du die Verbindung her !? Im Grunde immer über die zusammengesetzten Felder, d.h. Du hättest mit einem eigenen Schlüssel eine unnötige Information, die nicht nötig ist

Phil

Ihr seid mir witzig... oder eher der Dotore Dimitri... indem anderen Thread habe ich Vorschläge gemacht zu einer M:N Tabelle die einen PK hat mit 2 FK`s zu je einer anderen Tabelle.

z.B. die Schueler/Fach ZwischenTabelle... da sind nur 2 FK`s drin (1PK würde da noch reinkommen da jede Tabelle einen PK braucht nur die excel zeichnung ist alt...)

http://forum.fachinformatiker.de/datenbanken/118624-haltet-diesem-erd-bitte-um-kritik.html

http://forum.fachinformatiker.de/attachments/a/2046-haltet-diesem-erd-bitte-um-kritik-erd.png

[dr.dimitri]

Ihr seid mir witzig... oder eher der Dotore Dimitri

Wat bin ich?

Ich hab die anderen Beiträge jetzt nicht so genau gelesen, da es bereits halb zwei Uhr nachts ist. Daher kann es sein, dass ich evtl. einiges wiederhole - aber egal.

In meinen Lernunterlagen/Datenbank-Buch finde eine M:N Beziehung die mich verwirrt.

Die n:m Verbindung an sich ist ja richtig. Eine Mitarbeiter kann in mehreren Projekten sein, ein Projekt kann mehrere Mitarbeiter haben. da brauchts dann die Auflösungstabelle, wo wir schon beim Thema wären.

Warum wird hier ein zusammengestzter Primärschlüssel benutzt der sich aus beiden PK`s der anderen Tabellen zusammensetzt, anstatt einen künstlichen PK wie TätigkeitMA_ID

Ja das ist rein technisch gesehen erstmal möglich, von der Datenmodellierungsseite gesehen aber falsch. Warum?

1.) Du kannst eine Verbindung von einer Person zu einem Projekt eintragen, die überhaupt nicht existiert. Es gibt keine RI die dich daran hindert.

2.) Da keine RI existiert, werden Verbindungen auch nicht automatisch gelöscht bzw. das Löschen von Projekten/Personen verhindert solange eine Verbindung existiert (je nachdem wie der FK angelegt wurde).

3.) Das Datenmodell ist nicht normalisiert, denn die Tätigkeit muss in einer eigenen Entität abgelegt werden. Diese kann dann aber auch per FK in die Auflösungstabelle mit eingebaut werden.

4.) Ein Mitarbeiter kann im derzeitigen Datenmodell pro Projekt nur eine Tätigkeit verrichten, da ansonsten der PK nicht mehr eindeutig wäre (Uniqueconstraintverletzung, der Satz könnte nicht eingefügt werden). Das ist m.M. nach nicht sehr realitätsnah.

Die angegebene Tabelle ist also eindeutig falsch aufgebaut, Deine Aussage bezüglich den FKs und dem technischen PK ist eindeutig richtig.

Fazit: Verkauf dieses ominöse Buch oder besser: verbrenn' es.

Dim

[pel]

Die angegebene Tabelle ist also eindeutig falsch aufgebaut, Deine Aussage bezüglich den FKs und dem technischen PK ist eindeutig richtig.

Fazit: Verkauf dieses ominöse Buch oder besser: verbrenn' es.

Dim

du machst es mir nicht leicht. Stehe jetzt auch vor einer Art Gewissenskonflikt... wem glaube ich? Ich habe hier Lernunterlagen und das DB-Buch von Frank Geisler... egal nochmals was von meiner inkompetenten Lehrerin: 1 Student hat N Adressen kann durchaus sein (Bei Familie und in Studentenwohnheim...) doch schau dir mal die Tabelle ADRESSE an und die PK`s und FK`s fällt dir was auf?

[dr.dimitri]

doch schau dir mal die Tabelle ADRESSE an und die PK`s und FK`s fällt dir was auf?

Sicher. Der PK ist nicht unique, der FK referenziert keinen übergeordneten Schlüssel. Bis auf den ersten Adressatz würde keine DB die ich kenne das Einfügen der anderen erlauben.

Dim

[pel]

Sicher. Der PK ist nicht unique, der FK referenziert keinen übergeordneten Schlüssel. Bis auf den ersten Adressatz würde keine DB die ich kenne das Einfügen der anderen erlauben.

Dim

richtig... mir ist schon klar , dass ein Lehrer für jedes Beispiel keine super normalisierte TAbelle hinlegen muss um zu zeigen was insert anomalie ist doch das mindeste ist, dass man drunter schreibt was an der Tabelle noch fehlt, weil so findet man keinen roten Faden in den Unterlagen... da siehste mal was für ein ******* ich lernen muss!

Danke Dimi nochmals ich denk echt du rockst und der Rest ****t! schön dass ich dieses Forum entdeckt habe

[pel]

achso obiges ist keine 1:N Beziehung 1 Student hat 1 Adresse... stimmt nicht, sondern eine Adresse hat auch mehrere Studenten siehe Studenten-WG :eek sprich realistisch gesehen muss es eine M:N Relation sein. Nur so am Rande...

[dr.dimitri]

Wenn man diesen Weg geht, dann muss man sowohl die PLZ als auch die Adressen in eine eigene Tabelle auslagern und dann in der Auflösungstabelle die IDs der entsprechenden Adressbestandteile entsprechend zusammenfügen.

[edit]Eigentlich müsste man es noch etwas aufwändiger machen. Die ID der PLZ gehört per ID in die Adresstabelle (also dort wo die Strassennamen drinnen sind), dann hat man auch direkt eine Plausi und kann zu einer eingegebenen PLZ alle Strassennamen auflisten. In die Auflösungstabelle wird dann nur noch die ID der Adresstabelle eingetragen.[/edit]

Dim

Bearbeitet 24. August 2008 von dr.dimitri

[pel]

so jetzt nehm ich mal alles außenander was mir net koscher erscheint ich wills einfach wissen...

untenstehendes Bild habe ich von wiki "gerippt". Die Relation ist angeblich in der 2.Normalform.

zitat:"sowie die Tabelle einen eindeutigen Primärschlüssel (Verbundschlüssel aus den Spalten CD_ID und Track) ..."

wo ist dann in der Tabelle Lieder der Fremdschlüssel, der ja die Relation herstellt zur Tabelle CD ? gibts keinen FK obwohl 1:N Beziehung. Sag mir Dimi bitte das Beispiel ist falsch... vor allem den zusammengesetzten PK finde ich nicht gut. Bitte Dimi wie würdest du die CD/Lied Relation richtig machen?

Normalisierung (Datenbank ? Wikipedia)

Weiterhin habe ich immer noch massive Probleme mit diesen Entitäts-Kopien dies es laut dir nicht gibt, mir fehlt es da irgendwie an Vorstellungsvermögen oder das es "klick" macht.

1 CD hat mehrere Lieder,

1 Lied ist auf mehreren CDs -> ja ne das eine Lied kann ja nur auf einer CD sein ... kann man daraus eine N:M Relation machen? das verwirrt mich gewaltig.

[pel]

edit ging nicht mehr...

Was spricht gegen meine Lösung? Die Tabelle CD bleibt gleich, habe nur die Tabelle Lieder angepasst:

[dr.dimitri]

Sag mir Dimi bitte das Beispiel ist falsch

Naja technisch gesehen ist es nicht falsch. Von dem richtig - falsch Gedanken musst Du auch wegkommen. Es gibt eher Begriffe wie "elegant gelöst" und "bescheuert gelöst" in der IT sowie alles mögliche dazwischen. Technisch richtig kann dabei alles sein.

Bei dem Beispiel aus der Wikipedia würd ich sagen, dass es zwar technisch richtig ist, in der Praxis würd ich einem meiner Entwickler aber sagen, dass es eher zu der Sorte "bescheuert gelöst" gehört.

Warum?

Ich bin strikt dagegen fachliche Felder als PK zu verwenden. Ein PK, der aus den Inhalten von fachlichen Feldern gebildet wird ist ok, eine fortlaufende Nummer - kein Problem, eine GUID? Warum nicht. Aber nie ein fachliches Feld als PK missbrauchen.

Der Grund liegt darin, dass in der Praxis ein ER-Modell gewissen fachliche Anforderungen und Prozessen zugrundeliegt. Man modelliert ja nicht ins blaue hinein. Diese fachlichen Anforderungen können sich irgendwann ändern (auch wenn alle behaupten sie ändern sich nie - glaub ihnen kein Wort sie werden sich ändern spätestens wenn die Firma mal gekauft wird).

Dann wird noch ein Teil des PK zusätzlich als FK für die übergeordnete Tabelle verwendet. Technisch möglich keine Frage, aber auch wieder bescheuert gelöst.

Es gibt z.B. die Möglichkeit einen FK mit der Option "ON DELETE SET NULL" anzulegen. Dabei wird das FK Feld auf NULL gesetzt wenn der übergeordnete Satz gelöscht wird.

Ich hab also NULL in meinem PK stehen und damit beginnt die Sache interessant zu werden.

Nehmen wir an, der FK wurde mit der obigen Option angelegt, und es werden aus der übergeordneten Tabelle die Einträge mit der CD_ID 4711 und 4712 gelöscht.

Damit verändere ich zum einen meinen PK der untergeordneten Tabelle (und der sollte ja eigentlich unveränderlich sein, was wäre wenn es noch FKs gibt, die die Tabelle Lieder referenzieren?) und zum einen ist meine Tabelle dann nicht mehr normalisiert.

Ich könnte dann nämlich folgendes SQL abschicken:

select * from lieder where cd_id is null and track=1

Dann würde ich bei einem Zugriff über den PK 2 Einträge bekommen und das darf nie sein.

So wie Du es gemacht hast, wäre es aus meiner Sicht elegant gelöst.

Dim

[dr.dimitri]

Glatt vergessen.

Weiterhin habe ich immer noch massive Probleme mit diesen Entitäts-Kopien dies es laut dir nicht gibt, mir fehlt es da irgendwie an Vorstellungsvermögen oder das es "klick" macht.

1 CD hat mehrere Lieder,

1 Lied ist auf mehreren CDs -> ja ne das eine Lied kann ja nur auf einer CD sein ... kann man daraus eine N:M Relation machen? das verwirrt mich gewaltig.

Du musst eine Entität wie eine Blaupause sehen. Die Felder sind der Bauplan was alles reingehört. Eine übergeordnete Entität wiederum sorgt dafür, dass die Einträge der untergeordenten Entität zum Leben erwachen.

Lieder, die NULL im FK Feld stehen haben existieren per Definition nicht. Erst ein CD Eintrag erweckt sie zum Leben und macht sie greifbar für die nächste Entität die der Tabelle CD übergeordnet ist. macht man hier weiter, könnte am Ende evtl. eine CD Verwaltung herauskommen, in der mehrere Personen zwar die gleiche CD besitzen, diese aber nur einmal in der CD Tabelle eingetragen ist.

Dim