2NF / 3NF, Warum legt Workbrench solche Schlüssel an ?

[MrSpoocy]

Hi,

also ich habe ein simples Beispiel gemacht. Dieses habe ich mit dem EER von MySQL Workbrench erstellt.

Hier das fertige Bild erst einmal

Der SQL Code (um die Keys zu sehen)

CREATE  TABLE IF NOT EXISTS `mydb`.`stadt` (  
  `idstadt` INT NOT NULL AUTO_INCREMENT ,  
  `Name` VARCHAR(45) NULL ,  
  PRIMARY KEY (`idstadt`) )  
ENGINE = InnoDB;  
  
  
-- -----------------------------------------------------  
-- Table `mydb`.`bezirk`  
-- -----------------------------------------------------  
CREATE  TABLE IF NOT EXISTS `mydb`.`bezirk` (  
  `idbezirk` INT NOT NULL AUTO_INCREMENT ,  
  `stadt_idstadt` INT NOT NULL ,  
  `bName` VARCHAR(45) NULL ,  
  PRIMARY KEY (`idbezirk`, `stadt_idstadt`) ,  
  CONSTRAINT `fk_bezirk_stadt`  
    FOREIGN KEY (`stadt_idstadt` )  
    REFERENCES `mydb`.`stadt` (`idstadt` )  
    ON DELETE CASCADE  
    ON UPDATE CASCADE)  
ENGINE = InnoDB;  
  
CREATE INDEX `fk_bezirk_stadt` ON `mydb`.`bezirk` (`stadt_idstadt` ASC) ;  
  
  
-- -----------------------------------------------------  
-- Table `mydb`.`parkhaeuser`  
-- -----------------------------------------------------  
CREATE  TABLE IF NOT EXISTS `mydb`.`parkhaeuser` (  
  `bezirk_idbezirk` INT NOT NULL ,  
  `bezirk_stadt_idstadt` INT NOT NULL ,  
  `Strasse` VARCHAR(45) NULL ,  
  PRIMARY KEY (`bezirk_idbezirk`, `bezirk_stadt_idstadt`) ,  
  CONSTRAINT `fk_parkhaeuser_bezirk1`  
    FOREIGN KEY (`bezirk_idbezirk` , `bezirk_stadt_idstadt` )  
    REFERENCES `mydb`.`bezirk` (`idbezirk` , `stadt_idstadt` )  
    ON DELETE NO ACTION  
    ON UPDATE NO ACTION)  
ENGINE = InnoDB;  
  
  
-- -----------------------------------------------------  
-- Table `mydb`.`parkhaeuser2`  
-- -----------------------------------------------------  
CREATE  TABLE IF NOT EXISTS `mydb`.`parkhaeuser2` (  
  `bezirk_idbezirk` INT NOT NULL ,  
  PRIMARY KEY (`bezirk_idbezirk`) ,  
  CONSTRAINT `fk_bezirk`  
    FOREIGN KEY (`bezirk_idbezirk` )  
    REFERENCES `mydb`.`bezirk` (`idbezirk` )  
    ON DELETE NO ACTION  
    ON UPDATE NO ACTION)  
ENGINE = InnoDB;  
  
CREATE INDEX `fk_bezirk` ON `mydb`.`parkhaeuser2` (`bezirk_idbezirk` ASC) ;

Nun zu meiner Frage, mich wundert das Workbrench bei "parkhaeuser" beide Schlüssel als Primary key benutzt. Ich Persönlich würde es so wie bei "parkhaeuser2" (von mir per Hand erstellt) machen. Denn die idbezirk ist doch eh schon eindeutig, wozu dann noch die ID von Stadt mit reinnehmen ?

[Jens Holzkämper]

Tach,

Nun zu meiner Frage, mich wundert das Workbrench bei "parkhaeuser" beide Schlüssel als Primary key benutzt. Ich Persönlich würde es so wie bei "parkhaeuser2" (von mir per Hand erstellt) machen. Denn die idbezirk ist doch eh schon eindeutig, wozu dann noch die ID von Stadt mit reinnehmen ?

du hast irgendwoher die Vorstellung, die Workbench würde aus von dir gegebenen Schlüsselkandidaten selber Schlüssel auswählen, das widerspricht meinen Erfahrungen mit dem Tool. Soweit ich das kenne, kannst du da Tabellen anlegen und Spalten als Primary Key kennzeichnen; wenn du das mit mehreren machst, erhältst du halt einen zusammengesetzten Schlüssel.

mfg
Woodfighter

[Frank (no reg)]

Hallo, du hast einen eigenen Denkfehler in deinem logischen Datenmodell. z.b. eine einzelne Tabelle mit nur einer Spalte, die gleichzeitig Primary Key und Foreign Key ist, macht in 99.9% absolut keinen Sinn. Beseitige deinen Denkfehler, dann macht vielleicht auch der Rest Sinn. Ciao, Frank

[MrSpoocy]

Hallo, du hast einen eigenen Denkfehler in deinem logischen Datenmodell. z.b. eine einzelne Tabelle mit nur einer Spalte, die gleichzeitig Primary Key und Foreign Key ist, macht in 99.9% absolut keinen Sinn. Beseitige deinen Denkfehler, dann macht vielleicht auch der Rest Sinn. Ciao, Frank

Meinst du die Tabelle parkhaeuser2 ? Dies soll die gleiche wie parkhaeuser sein nur wie ich sie hätte gemacht. Hab vergessen das feld "Strasse" hinzuzufügen weil das nicht der kern des Problems war. Es geht eher darum warum Workbrench mir die Schlüssel wie in tabelle parkhaeuser vorschläge. Denn ich hätte es gemacht wie in parkhaeuser2.

[Frank (no reg)]

Das Tool macht sicher nichts von allein. Was imho in dem Diagramm fehlt, damit es halbwegs Sinn macht (so wie es das Tool gemacht haben will), dass es einen zusammengesetzten Schluessel aus Stadt und Bezirk hat, ist eine Fremdschluesselbeziehung von 'parkhaeuser' zu Stadt. Evt. war diese Beziehung schon mal irgendwie da?

Ich sehe auch nicht so ganz den Sinn hinter dieser Normalisierung fuer 'parkhaeuser'. (Parkhaus hat eine Adresse: Planet, Kontinent, Land, Bundesland, Stadt, Stadtbezirk, Strasse, Nr ..., und PLZ vielleicht). Aber das liegt vielleicht am gewaehlten Beispiel selbst.

Gruss von der Insel
Frank

[MrSpoocy]

Wieso muss man denn eine Beziehung von parkhaeuser zu Stadt direckt haben ? Man kommt doch schon über bezirk daran :/

[Harlequin]

Yerf!

Das Tool macht sicher nichts von allein. Was imho in dem Diagramm fehlt, damit es halbwegs Sinn macht (so wie es das Tool gemacht haben will), dass es einen zusammengesetzten Schluessel aus Stadt und Bezirk hat, ist eine Fremdschluesselbeziehung von 'parkhaeuser' zu Stadt. Evt. war diese Beziehung schon mal irgendwie da?

Ich denk mal eher das es daran liegt, das die Bezirk-Tabelle bereits einen kombinierten Primkey über BezirksNr und Stadt hat...

Gruß,

Harlequin

[MrSpoocy]

Hi,

meine Frage wer denn jetzt wie würde man diese simple beispiel datenbank "richtig" machen, also wie würde man welche key's setzen / felder erstellen/löschen ?

[Harlequin]

Yerf!

Wenn ich dein Beispiel richtig verstanden hab und jeder Bezirk unabhängig davon in welcher Stadt er ist eine eindeutige ID hat müsste man nur den PrimKey der Bezirkstabelle abändern, das er nur die BezirksId enthält (und nicht auch nocht die StadtId)

Der "komische" FK in der Parkhäuser-Tabelle ist nur ein Folgefehler, der aus dem zusammengesetzten PK resultiert (denn in dem Fall ist nicht gewährleistet das die BezirksID eindeutig ist).

Gruß,

Harlequin

[MrSpoocy]

Aber warum setzt Workbrech das so, also wenn ich die "verbindung" Stadt -> Bezirk lösche, und damit auch das Feld "stadt_idstadt". Habe ich ja nur noch idbezirk als Primary Key. So weit so gut, wenn ich jetzt eine Beziehung wieder zu Stadt herstelle erstellt er automatisch den Fremdschlüssel stadt_idstadt, was soweit ja auch noch O.k. ist, aber im gleichen Zug macht er daraus dann auch einen Primary Key in Verbindung mit idbezirk. Mich wundert warum er das macht, ich hab immer angst das meine Denkweise falsch ist und das Programm schon wissen wird was richtig ist und wie es "best practices" ist.

[Harlequin]

Yerf!

Weshalb das Programm es so macht kann ich nicht sagen, aber es ist Quatsch. Der Foreign-Key ist wie schon erkannt korrekt, aber das Erweitern des PrimKey ist falsch, außer man möchte ein und die selbe Berziks_ID mehreren Städten zuordnen können (deiner Beschreibung nach ist das aber nicht gewünscht)

Evtl. "denkt" das Programm es würde sich um eine n:m Beziehungstabelle handeln, weil schon eine weitere Beziehung zur 3. Tabelle existiert...

Gruß,

Harlequin