"is-a" Beziehung / Spezialisierungsbeziehung (in MySQL Datenbank)

SvenGWK · 25. November 2011

Denke mal das passt am ehesten hier her...
Ich habe in einem ERM eine Fallunterschidung drin, hier speziell:

Es gibt "Video" (mit Attributen) und einer File-ID als Primärschlüssel.

Ein Video kann a.) ein Film (mit Attributen) oder b.) Eine Episode (mit anderen Attributen) sein, welche dann wiederrum mit Staffel und Serie in Verbindung steht.
Wie ich letzteres umzusetzen habe glaube ich zu wissen, allerdings ist mir die Umsetzung der "is-a" Beziehung nicht klar.
Mein Dozent meinte ich müsse aus "Film" und "Episode" jeweils eine Tabelle machen und diese in 1:1 Beziehung mit dem übergeordneten Objekt Video stellen.

Nachdem was ich über die Normalisierung von 1:1 weiss wird das dann jedoch eine Tabelle, also hätte ich am ende eine Tabelle namens "Film" und eine namens "Episode".
Ist das so korrekt?
Im Endeffekt hätten dann ja beide Tabellen die File-ID als Primärschlüssel, hätten aber an und für sich miteinander nichts zu tun.
Das ist mir irgendwie unklar.
Hat jemand einen guten Tip bzw. eine Seite wo speziell auf "is-a" eingegangen wird?
Die seiten welche ich bisher gefunden habe waren zu dieser Thematik nicht besonders aufschlussreich... .-/

tag · 26. November 2011

Zitat von SvenGWK

Mein Dozent meinte ich müsse aus "Film" und "Episode" jeweils eine Tabelle machen und diese in 1:1 Beziehung mit dem übergeordneten Objekt Video stellen.

Du brauchst also drei Tabellen: Video (gemeinsame Attribute; ID ist Primärschlüssel), Filme und Episoden (jeweils spezifische Attribute; ID ist Fremdschlüssel auf die Video-ID und wegen der 1:1-Beziehung ebenfalls Primärschlüssel). Zusätzlich gilt, dass jedes Video ein Film oder eine Episode sein muss, aber nicht beides gleichzeitig sein kann. Das muss aber nicht immer so sein.

rechenknechtler · 26. November 2011

Klassisches Problem in der Informatik. Eigentlich (und tatsächlich) passen Objekte und relationale Datenbanken nicht so recht zusammen. Ein RDBS gibt nicht vor wie die Abbildung von solch einer Vererbungshierarchie aussehen soll. RDBS sind dafür auch gar nicht gemacht geworden. Dennoch: Je eine Relation pro Klasse ist ein Ansatz, würde ich hier auch so realisieren. Also Relationen "Video", "Film", "Episode". Andere Ansätze findest du unter http://de.wikipedia.org/wiki/Objektrelationale_Abbildung und mehr Details unter http://de.wikipedia.org/wiki/O…tional_impedance_mismatch sowie in Vorlesungen zu OODBs.

Edit: Die referentielle Integrität mittels Schlüsselbeziehungen reicht für die Abbildung nicht aus. Das RDBS kann so nicht verhindern, dass ein Film nicht auch eine Episode ist und umgekehrt. Aber bei deinem Anwendungsfall ist das eher theoretische Spielerei und nicht so entscheidend.

SvenGWK · 26. November 2011

Hmm,
denke ich ahbe es so gemacht - auf jeden Fall wird die DB erstellt ohne zu meckern.
Ein kleines Füllscript habe ich auch schon geschrieben, mal schauen ob die Abfagen laufen werden...

Das DB Script:

Code

DROP DATABASE /*! IF EXISTS */ myvideodatenbank;


CREATE DATABASE myvideodatenbank 
       CHARACTER SET latin1 
       COLLATE latin1_german2_ci;


USE myVideoDatenbank;


CREATE TABLE Video (
File_ID        INT          UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL, 
Laenge         INT          NULL DEFAULT NULL,
Titel          VARCHAR(200) NOT NULL,
Titel_origin   VARCHAR(200) NULL DEFAULT NULL,
FSK            INT		    NULL DEFAULT NULL,
Qualitaet      ENUM('HDTV', 'SDTV', 'DVD-Rip', 'BLUERAY-RIP', 'CAMRIP','FULL-MPEG', 'DIVX', 'MP4') NOT NULL DEFAULT 'SDTV',
Inhalt         VARCHAR(2000) NOT NULL,
Sprache		   VARCHAR(400) NULL DEFAULT NULL,
Lagerort	   VARCHAR(80)  NOT NULL
) AUTO_INCREMENT=10000 ENGINE = InnoDB;


CREATE TABLE Film (
File_ID        INT          UNSIGNED PRIMARY KEY NOT NULL,
Jahr           INT		    UNSIGNED NOT NULL,
Filmcover	   VARCHAR(200) NOT NULL DEFAULT 'D:\\myVideoDatenbank\\Images\\Filmcover\\0.jpg',
FOREIGN KEY ( FILE_ID )     REFERENCES Video (File_ID)
) ENGINE = InnoDB;


CREATE TABLE Serie (
Serie_ID       INT          UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
Serientitel    VARCHAR(200) NOT NULL,
Serienbesch	   VARCHAR(2000)NOT NULL,
Serienlogo	   VARCHAR(200) NOT NULL DEFAULT 'D:\\myVideoDatenbank\\Images\\Serienlogos\\0.jpg'	
) AUTO_INCREMENT=10 ENGINE = InnoDB;


CREATE TABLE Staffel (
Staffel_ID     INT          UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
Staffel_Nr	   INT			UNSIGNED NOT NULL,
Staffelcover   VARCHAR(200) NOT NULL DEFAULT 'D:\\myVideoDatenbank\\Images\\Staffelcover\\0.jpg',
Serie_ID	   INT			UNSIGNED NOT NULL,
FOREIGN KEY ( Serie_ID )    REFERENCES Serie (Serie_ID)
) AUTO_INCREMENT=2000       ENGINE = InnoDB;


CREATE TABLE Episode (
File_ID        INT          UNSIGNED PRIMARY KEY NOT NULL,
Epi_Nr_ges	   INT			NOT NULL,
Epi_Nr_Sta	   INT			NOT NULL,
Erstaustr      DATE         NOT NULL,
dt_Erstaustr   DATE			NULL DEFAULT NULL,
Staffel_ID	   INT			UNSIGNED NOT NULL,	
FOREIGN KEY ( File_ID )     REFERENCES Video   (File_ID),
FOREIGN KEY ( Staffel_ID )  REFERENCES Staffel (Staffel_ID)
) ENGINE = InnoDB;


CREATE TABLE Herkunft (
Land_ID        INT          UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
Land           VARCHAR(20)	NOT NULL
) AUTO_INCREMENT=1          ENGINE = InnoDB;


CREATE TABLE Studios (
Studio_ID      INT          UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
Land           VARCHAR(40)	NULL DEFAULT NULL
) AUTO_INCREMENT=1          ENGINE = InnoDB;


CREATE TABLE Regisseur (
Reg_ID         INT          UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
Regisseur      VARCHAR(40)  NOT NULL
) AUTO_INCREMENT=1          ENGINE = InnoDB;


CREATE TABLE Genre (
G_Abk          CHAR(2)      PRIMARY KEY NOT NULL,
G_Langform	   VARCHAR(20)  NOT NULL
)                           ENGINE = InnoDB;


CREATE TABLE Schauspieler (
Star_ID        INT          UNSIGNED PRIMARY KEY NOT NULL,
Star           VARCHAR(40)  NOT NULL,
Starphoto	   VARCHAR(200) NOT NULL DEFAULT 'D:\\myVideoDatenbank\\Images\\Stars\\0.jpg'
) AUTO_INCREMENT=1          ENGINE = InnoDB;


CREATE TABLE stammt_aus (
File_ID        INT          UNSIGNED NOT NULL,
Land_ID        INT          UNSIGNED NOT NULL,
PRIMARY KEY ( File_ID, Land_ID ),
FOREIGN KEY ( File_ID )     REFERENCES Video       (File_ID),
FOREIGN KEY ( Land_ID )     REFERENCES Herkunft    (Land_ID)
)                           ENGINE = InnoDB;


CREATE TABLE produziert_von (
File_ID        INT          UNSIGNED NOT NULL,
Studio_ID      INT          UNSIGNED NOT NULL,
PRIMARY KEY ( File_ID, Studio_ID ),
FOREIGN KEY ( File_ID )     REFERENCES Video       (File_ID),
FOREIGN KEY ( Studio_ID )   REFERENCES Studios     (Studio_ID)
)                           ENGINE = InnoDB;


CREATE TABLE fuehrt_Regie (
File_ID       INT          UNSIGNED NOT NULL,
Reg_ID        INT          UNSIGNED NOT NULL,
PRIMARY KEY ( File_ID, Reg_ID ),
FOREIGN KEY ( File_ID )    REFERENCES Video        (File_ID),
FOREIGN KEY ( Reg_ID )     REFERENCES Regisseur    (Reg_ID)
)                          ENGINE = InnoDB;


CREATE TABLE zugeordnet_zu (
File_ID       INT          UNSIGNED NOT NULL,
G_Abk     	  CHAR(2)      NOT NULL,
PRIMARY KEY ( File_ID, G_Abk ),
FOREIGN KEY ( File_ID )    REFERENCES Video        (File_ID),
FOREIGN KEY ( G_Abk )      REFERENCES Genre        (G_Abk)
)                          ENGINE = InnoDB;


CREATE TABLE wirkt_mit (
File_ID       INT          UNSIGNED NOT NULL,
Star_ID       INT          UNSIGNED NOT NULL,
PRIMARY KEY ( File_ID, Star_ID ),
FOREIGN KEY ( File_ID )    REFERENCES Video        (File_ID),
FOREIGN KEY ( Star_ID )    REFERENCES Schauspieler (Star_ID)
)                          ENGINE = InnoDB;

Alles anzeigen

Falls da noch offensichtliche Fehler auffallen...?
Danke für eure Hilfe!

rechenknechtler · 27. November 2011

Sieht gut aus. Theoretische Entscheidung wäre noch: Wenn du keine Transaktionssicherheit brauchst reicht als Engine MyISAM, die ist ohne ACID schneller als InnoDB.

Ansonsten würde ich Schauspieler und Regisseur ähnlich wie mit Videos modellieren, nur das eine Person tatsächlich beides sein kann (Clint Eastwood...). Alternativ kannst du auch ma in der XBMC-Datenbank "spicken". Insgesamt drehen sich die Entscheidungen ja darum wie detailiert du es machen möchtest.

Gruß

SvenGWK · 27. November 2011

InnoDB sollen wir nehmen, wegen der referenziellen Integrität.
Das mit den Schauspielern/Regisseuren ist mir gestern aufgefallen beim befüllen - im Falle Sylvester Stallone...
Die Leute bekommen jetzt von mir statt Star_ID und Reg_ID eine "Personalnummer" verpasst, so spare ich wieder eine Tabelle ein.
Danke für´s drüberschauen - sieht so aus als wenn ich doch noch vor dem offiziellen Zeitplan damit fertig werde.

SvenGWK · 27. November 2011

so, hier wäre nun das aktuelle ERM.
Ich spare zwar keine Tabellen ein, aber der Aufbau ist logischer, da nun Stallone oder Eastwood die gleiche Person ist, egal ob er Regie führt,schauspielert oder beides macht.

Was mir noch nicht so ganz klar ist - wie baut man das nun wirklich sinnvoll in Tabellen um?
Auf diversen Seiten findet sich der Hinweis das man 1:1 auflöst und aus den 3 Tabellen eben 2 Tabellen macht.
Ich hatte bisher für das 1:1 / is_a eben 3 Tabellen genutzt, was das ganze bei einer Unterscheidung zwischen Film und Episode meines Erachtens übersichtlich gestaltet, da ja bei den Speziellen
noch unterschiedliche Attribute zu finden sind.
Nun macht das ja eher keinen Sinn mehr, wenn die Objekte Schauspieler und Regisseur ja alles erben was das Objekt Prominenter an Attributen hat,
selbst aber keine speziellen Attribute besitzen.
Ich würde nun also die dem Prominenten vergebene Pro_ID direkt in die Tabellen führt_Regie und/oder wirkt_mit eintragen, korrekt?

rechenknechtler · 27. November 2011

Zitat

Ich hatte bisher für das 1:1 / is_a eben 3 Tabellen genutzt, was das ganze bei einer Unterscheidung zwischen Film und Episode meines Erachtens übersichtlich gestaltet, da ja bei den Speziellen
noch unterschiedliche Attribute zu finden sind.

Da gibt es hier kein richtig oder falsch. Kommt drauf an, was man modellieren will. Mit der dritten Tabelle "Video" kannst du halt nach Instanzen verschiedener Klassen "Film" und "Episode" fragen. Das wäre die eher objektorientierte Sicht.

Weil ich jetzt gerade so darüber nachdenke: Vermutlich würde ich Film und Episode in der Datenbank nicht mit Video in einen Topf werfen. Aber das heißt nicht, dass irgendwas falsch ist an deinem Ansatz. Du hast deine Entwurfsentscheidung begründet und von daher passt das ganz gut.

Zitat

Ich würde nun also die dem Prominenten vergebene Pro_ID direkt in die Tabellen führt_Regie und/oder wirkt_mit eintragen, korrekt?

Ja genau. Die Beziehung drückt ja die Rolle des Prominenten aus, benenne einfach die beiden Attribute die die Fremdschlüssel tragen entsprechend.

SvenGWK · 27. November 2011

OK - vielen Dank,
werd ich morgen mal entsprechend einbauen.

"is-a" Beziehung / Spezialisierungsbeziehung (in MySQL Datenbank)

Jetzt mitmachen!

Teilen