Modellierung meiner Datenbank
- Ersteller Sophus
- Erstellt am
Werbung:
Sophus
SQL-Guru
- Beiträge
- 135
Im Alltag kennen wir es ja alle, ein Film entsteht niemals von alleine - es sind immer Firmen daran beteiligt. Logisch, sie wollen alle ihr Geld verdienen bzw. sich an den Gewinn beteiligen
Und der Film soll ja auch bei den Kunden ankommen, wenn es fertig ist. Aber bevor der Film zu den Kunden gelangt, muss der Film sozusagen viele Prozeduren durchlaufen.Und da kommt die Relation Firmen und die Zwischentabelle FilmAllgemein_Firmen ins Spiel. Die Überlegung meinerseits ist also, dass zu einem Film (FilmAllgemein) n Firmen für bestimmte Aufgaben herangezogen werden und eine Firma n Filme in Auftrag nehmen können. Wäre ja blöd, wenn sie nur einen Film in Auftrag nehmen würden. Die könnten nach dem einen Film dann die Laden wieder dicht machen
Deswegen dachte ich mir, wäre hier eine n:m-Beziehung eine bessere Wahl.Nun zu der Relation FirmenKategorie: Es gibt Firmen, die den Film produzieren (sogenannte Filmproduktion), es gibt Firmen, die den Film noch bearbeiten müssen (sogenannte Filmstudio), es gibt Firmen, die den Film vermarkten müssen (sogenannte Filmverleiher) und so weiter. Unter FirmenKategorie verstehe ich also sowas wie »Aufgabenbereiche der Firmen«. Und da eine Firma sich für mehre Aufgaben gleichzeitig verschreiben können, so dachte ich an eine 1:n-Beziehung. Das heißt, eine Firma kann n Aufgaben (FirmenKategorie) annehmen, und n Aufgaben könne nur einer Firma zugeordnet werden. Zum Beispiel: Es wäre durchaus denkbar, dass die Firma Wir lieben Filme GmbH so groß ist, dass sie den Film Hampelmann sowohl produzieren als auch vermarkten. Somit ist die Firma Wir lieben Filme GmbH beides, einmal als Filmproduktion und einmal als Filmverleiher.
Jedoch komme ich etwas ins Straucheln, ob zwischen den Relationen Firmen und FirmenKategorie doch noch eine Zwischentabelle platziert werden soll. Was meint ihr?
ukulele
Datenbank-Guru
- Beiträge
- 5.142
Also erstmal zur "Firma":
"Firma" ist mir von der Begrifflichkeit her schon etwas zu schwammig. Die Firma ist umgangssprachlich ein Unternehmen aber im Handelsrecht eigentlich der Unternehmensname einer im Handelsregister eingetragenen Unternehmung. Ist dein Unternehmen ein Einzelunternehmen oder eine GbR ist es nicht eingetragen. Bist du eingetragener Kaufmann hast du eine Firma, das sagt aber nichts über die Größe deiner Unternehmung aus. Hast du eine GmbH & Co. KG vor dir gibt es immerhin schonmal zwei Firmen, eine Verwaltungs-GmbH und eine Komplementärgesellschaft. Auch wenn das vieleicht etwas Haarspalterei ist so würde ich doch eher eine Begrifflichkeit wie Organisation oder Unternehmen vorziehen.
Außerdem sollten diese Unternehmen auch untereinander Beziehungen n:m abbilden können. So das Gesellschaften, vor allem große Filmstudios auch mit Subunternehmen (deren Beteiligung an einem Film dir nicht zwingend bekannt ist) und Konsortien oder Genossenschaften oder was weiß ich was es im Verleihgeschäft gibt auch abgebildet werden können. Deine n:m Tabelle sollte außerdem Zeiträume für diese Beziehungen abbilden können.
Und jetzt zu deinem eigentlichen Problem: Ich würde keine Kategorie Tabelle machen. Deine FilmAllgemein-Firmen Tabelle sollte alle dir bekannten Beziehungen zu "Firmen" abbilden. Welcher Art diese Beziehungen sind würde ich in einer 1:n Tabelle zu dieser Tabelle abbilden. Auch wieder mit Zeitraum und genauer Definition wie "hält Namensrechte", "produziert", "vermarktet", etc. aber ganz wichtig, diese Beziehungen können sich ändern! - Daher Zeitraum abbilden.
Deine Variante hat ein Problem. Sobald Ein großes Studio mehrere Kategorien hat und ein Film zugeordnet wurde weißt du nicht, welche Kategorien auch angewandt werden, und vor allem von wann bis wann. Hier kann man sich wirklich tot-normalisieren.
"Firma" ist mir von der Begrifflichkeit her schon etwas zu schwammig. Die Firma ist umgangssprachlich ein Unternehmen aber im Handelsrecht eigentlich der Unternehmensname einer im Handelsregister eingetragenen Unternehmung. Ist dein Unternehmen ein Einzelunternehmen oder eine GbR ist es nicht eingetragen. Bist du eingetragener Kaufmann hast du eine Firma, das sagt aber nichts über die Größe deiner Unternehmung aus. Hast du eine GmbH & Co. KG vor dir gibt es immerhin schonmal zwei Firmen, eine Verwaltungs-GmbH und eine Komplementärgesellschaft. Auch wenn das vieleicht etwas Haarspalterei ist so würde ich doch eher eine Begrifflichkeit wie Organisation oder Unternehmen vorziehen.
Außerdem sollten diese Unternehmen auch untereinander Beziehungen n:m abbilden können. So das Gesellschaften, vor allem große Filmstudios auch mit Subunternehmen (deren Beteiligung an einem Film dir nicht zwingend bekannt ist) und Konsortien oder Genossenschaften oder was weiß ich was es im Verleihgeschäft gibt auch abgebildet werden können. Deine n:m Tabelle sollte außerdem Zeiträume für diese Beziehungen abbilden können.
Und jetzt zu deinem eigentlichen Problem: Ich würde keine Kategorie Tabelle machen. Deine FilmAllgemein-Firmen Tabelle sollte alle dir bekannten Beziehungen zu "Firmen" abbilden. Welcher Art diese Beziehungen sind würde ich in einer 1:n Tabelle zu dieser Tabelle abbilden. Auch wieder mit Zeitraum und genauer Definition wie "hält Namensrechte", "produziert", "vermarktet", etc. aber ganz wichtig, diese Beziehungen können sich ändern! - Daher Zeitraum abbilden.
Deine Variante hat ein Problem. Sobald Ein großes Studio mehrere Kategorien hat und ein Film zugeordnet wurde weißt du nicht, welche Kategorien auch angewandt werden, und vor allem von wann bis wann. Hier kann man sich wirklich tot-normalisieren.
Sophus
SQL-Guru
- Beiträge
- 135
Hallo ukulele,
ich muss gestehen, dass du mich eher verwirrst, als das du mich aufklären willst. Von welchen Zeiträumen schreibst du? Ein Unternehmen hat für einen Film YXZ als Filmverleiher argiert. Dazu ist keine Zeitangabe notwendig. Denn in der Relation FilmAllgemein gibt es ein Attribut Produktionsjahr/Erscheinungsjahr. Dort steht dann das Jahr drin, in welcher der Film erschien bzw. produziert wurde. Sagen wir mal der Film XYZ erschein im Jahr 2006, so haben all die andern Unternehmen sich in diesem Jahr daran beteilgt. Wenn du damit die Fassungs-Ebene meinst, dass zum Beispiel eine bestimmte Fassung eines Filmes - sagen wir mal die Blood-Edition - später von einer anderen Firme vermarktet wurde, dann müsste ich nur eine Beziehung zu der Fassung herstellen. Dies würde ich aber mit einer n:m-Beziehung lösen.
Meine Überlegung ist eher, soll zwischen der Relation FilmmAllgemein und der Relation Firmen ebenfalls eine n:m-Beziehung hergestellt werden oder bei einer 1:n-Beziehung bleiben?
Ich bin gerade in der Universität. Wenn ich zu Hause bin, werde ich mal schnell eine Skizze anfertigen, damit wir mal was visuelles haben und ihr wisst, was ich meine
Gruß
Sophus
ich muss gestehen, dass du mich eher verwirrst, als das du mich aufklären willst. Von welchen Zeiträumen schreibst du? Ein Unternehmen hat für einen Film YXZ als Filmverleiher argiert. Dazu ist keine Zeitangabe notwendig. Denn in der Relation FilmAllgemein gibt es ein Attribut Produktionsjahr/Erscheinungsjahr. Dort steht dann das Jahr drin, in welcher der Film erschien bzw. produziert wurde. Sagen wir mal der Film XYZ erschein im Jahr 2006, so haben all die andern Unternehmen sich in diesem Jahr daran beteilgt. Wenn du damit die Fassungs-Ebene meinst, dass zum Beispiel eine bestimmte Fassung eines Filmes - sagen wir mal die Blood-Edition - später von einer anderen Firme vermarktet wurde, dann müsste ich nur eine Beziehung zu der Fassung herstellen. Dies würde ich aber mit einer n:m-Beziehung lösen.
Meine Überlegung ist eher, soll zwischen der Relation FilmmAllgemein und der Relation Firmen ebenfalls eine n:m-Beziehung hergestellt werden oder bei einer 1:n-Beziehung bleiben?
Ich bin gerade in der Universität. Wenn ich zu Hause bin, werde ich mal schnell eine Skizze anfertigen, damit wir mal was visuelles haben und ihr wisst, was ich meine
Gruß
Sophus
Sophus
SQL-Guru
- Beiträge
- 135
Bei dieser Skizze dachte ich folgendes: Ein Film wird nach dem letzten Drehtag nun digital bearbeitet. Natürlich setzt sich der Regisseur nicht alleine hin und »bastelt« seine Szenen zu einem Film zusammen und baut bestimmte Effekte ein, fügt für bestimmte Sprache entsprechende Tonspuren ein und verkauft den Film am Ende selbst. Nein. Dafür werden Firmen/Unternehmen eingebunden.
Zunächst einmal zu den Relationen Firmen und FirmenKategorie: In der Relation Firmen werden Namen eingegeben, die der Anwender natürlich selbst verwalten muss. Diese Relation dient ebenfalls als »Stammdaten-Halter«-Relation. Firmennamen können sein wie WaltDisney, Warner Bros., New Line etc. Sämtliche Namen die in der Filmindustrie/Filmbranche arbeiten. In der Relation FirmenKategorie sollen deren Aufgaben/Funktionen ebenfalls als »Stammdaten-Halter« vom Anwender eingetragen werden. Wie der Anwender sie benennt, ist seine Angelegenheit. Ich denke eher dabei so an Filmproduktion, Filmstudio, Filmverleih etc.
Nun, jetzt stellen wir uns vor, wir wollen einen Film namens X-Men in meine Datenbank abspeichern. Jetzt schauen wir zunächst einmal, welche Unternehmer/Firmen an dem Film beteiligt waren. Dies sieht man immer sehr deutlich am Anfang, bevor der Film beginnt. Dort werden die Firmen wie New Line, Paramount etc ja gezeigt. Auch im Abspannt werden diese Firmen detaillierter vorgestellt. Meiner Überlegung nach kann der Film X-Men viele Firmen/Unternehmen beschäftigen. Und ein Unternehmen / eine Firma kann ja in mehreren Filmen mitgewirkt haben. Warner Bros. oder Walt Disney haben ja nicht nur in einem einzigen Film mitgewirkt. Deswegen dachte ich, wäre zwischen den Relationen FilmAllgemein und Firmen eine Zwischentabelle FilmAllgemein_Firmen notwendig - also eine n:m-Beziehung.
Und da ein Unternehmen / eine Firma durchaus mehrere Aufgaben zum Film »X-Men« ausführen können, dachte ich hierbei ebenfals an eine n:m-Beziehung. Denn in diesem besagten Film kann das Unternehmen »Twentieth Century Fox Film Corporation« sowohl als Filmproduktion als auch als Filmverleiher agieren. Es ist ja nicht gesagt, dass dieses Unternehmen nur eine Aufgabe übernehmen. Wenn ein Unternehmen dementsprechend groß ist, übernimmt sie mehrere Aufgaben. Deswegen dachte ich, wäre die Zwischentabelle Firmen_FirmenKategorie ebenfalls notwendig.
Zuletzt bearbeitet:
ukulele
Datenbank-Guru
- Beiträge
- 5.142
Es ist sicherlich nicht die Regel aber kommt immer wieder vor das Personen oder Unternehmen nur Zeitweise an einem Film mitwirken. Nimm z.B. den neuen Star Trek, die haben jetzt den dritten Regisseur verpflichtet. Oben hatte ich das Beispiel Rechte angeführt, insbesondere Namensrechte werden manchmal veräußert und nicht immer nur von einem Unternehmen gehalten. Auch gehen Unternehmen pleite und Projekte werden anderweitig aufgegriffen. Ich würde also Zeiträume mit abbilden wenn du es sehr genau modelieren willst. Man kann auf diese Information aber auch verzichten, auf irgendwas verzichtet man eigentlich immer.
Wenn du deine Kategorien nur den Firmen zuordnest (egal ob 1:n oder n:m) kannst du später nicht sagen bei welchem Film welche Firma in welcher Kategorie tätig war. Ich würde die Kategorien der Beziehung Film/Firma zuordnen und diese Beziehung sollte meiner Meinung nach n:m sein wie in deinem ersten Bild.
Wenn du deine Kategorien nur den Firmen zuordnest (egal ob 1:n oder n:m) kannst du später nicht sagen bei welchem Film welche Firma in welcher Kategorie tätig war. Ich würde die Kategorien der Beziehung Film/Firma zuordnen und diese Beziehung sollte meiner Meinung nach n:m sein wie in deinem ersten Bild.
Sophus
SQL-Guru
- Beiträge
- 135
Hey ukulele,
das Unterenehmen Pleite gehen, Regisseure sich wechseln, Namensrechte ausgehen etc, das weiß ich. Jedoch soll der Anwender meinem Programm unter anderem Filme verwalten, und nicht Firmen Die Firmen dienen nur dazu, dass man später zum Beispiel fragen kann "Ja, wo hat Warner Bros über alle mitgewirkt?".
Dein Einwand bezüglich der Beziehung ist berechtigt, und werde ich mal darüber nachdenken und wenn es mir gefällt auch umsetzen. Besten Dank
das Unterenehmen Pleite gehen, Regisseure sich wechseln, Namensrechte ausgehen etc, das weiß ich. Jedoch soll der Anwender meinem Programm unter anderem Filme verwalten, und nicht Firmen
Die Firmen dienen nur dazu, dass man später zum Beispiel fragen kann "Ja, wo hat Warner Bros über alle mitgewirkt?". Dein Einwand bezüglich der Beziehung ist berechtigt, und werde ich mal darüber nachdenken und wenn es mir gefällt auch umsetzen. Besten Dank
Sophus
SQL-Guru
- Beiträge
- 135
Hallo Leute,
jetzt kommen wir zum nächsten Schritt. Jetzt kommen wir zum Thema »Bildformate«. Ein jeder Film hat in seiner Fassung seine Bildformate. Hier ein kleines Beispiel, wie ich mir die Tabelle in Etwa vorstelle. Die Tabelle ist natürlich nicht vollständig, dient nur als Beispiel.
Wenn ich mir also diese obige Tabelle anschaue, so habe ich es wie folgt modelliert:
Die Rleationen BildFormat und BildKategorie sollen hierbei wieder als eine Art »Stammdaten-Halter« dienen. Die Anwender sollen diese Daten selbst verwalten. In die Relation BildKategorie gehören die Information aus der Spalte der obigen Tabelle. In die Relation BildFormat kommen Seitenverhältnis und System rein. Warum ich eine Zwischentabelle FilmFassung_Bildformat platziert habe? Nun, es ist durchaus möglich, dass in einer Fassung nicht nur ein Bildformat angeboten wird. Stellt euch vor, ihr kauft einen Horrorfilm, dieser ist eine Fassung Director's Cut und auf einer DVD. Da wäre es möglich, dass auf dieser DVD dann mehrere Bildformate angeboten werden.
Wobei, wenn ich mir die obige Tabelle noch einmal ansehe, müsste man für das System nochmal eine Tabelle anlegen oder? Meine Überlegung wäre dann, das Attribut System aus der Tabelle BildFormat zu entnehmen und daraus eine Relation System zu erstellen und diese dann mit der Zwischentabelle FilmFassung_Bildformat zu verbinden. Was meint ihr? Hättet ihr eine andere Alternative?
Oder die erstellte Relation System mittelt einer Zwischentabelle System_BildFormt mit der Relation BildFormat eine Beziehung herzustellen?
Was findet ihr besser?
jetzt kommen wir zum nächsten Schritt. Jetzt kommen wir zum Thema »Bildformate«. Ein jeder Film hat in seiner Fassung seine Bildformate. Hier ein kleines Beispiel, wie ich mir die Tabelle in Etwa vorstelle. Die Tabelle ist natürlich nicht vollständig, dient nur als Beispiel.
Wenn ich mir also diese obige Tabelle anschaue, so habe ich es wie folgt modelliert:
Die Rleationen BildFormat und BildKategorie sollen hierbei wieder als eine Art »Stammdaten-Halter« dienen. Die Anwender sollen diese Daten selbst verwalten. In die Relation BildKategorie gehören die Information aus der Spalte der obigen Tabelle. In die Relation BildFormat kommen Seitenverhältnis und System rein. Warum ich eine Zwischentabelle FilmFassung_Bildformat platziert habe? Nun, es ist durchaus möglich, dass in einer Fassung nicht nur ein Bildformat angeboten wird. Stellt euch vor, ihr kauft einen Horrorfilm, dieser ist eine Fassung Director's Cut und auf einer DVD. Da wäre es möglich, dass auf dieser DVD dann mehrere Bildformate angeboten werden.Wobei, wenn ich mir die obige Tabelle noch einmal ansehe, müsste man für das System nochmal eine Tabelle anlegen oder? Meine Überlegung wäre dann, das Attribut System aus der Tabelle BildFormat zu entnehmen und daraus eine Relation System zu erstellen und diese dann mit der Zwischentabelle FilmFassung_Bildformat zu verbinden. Was meint ihr? Hättet ihr eine andere Alternative?
Oder die erstellte Relation System mittelt einer Zwischentabelle System_BildFormt mit der Relation BildFormat eine Beziehung herzustellen?
Was findet ihr besser?
ukulele
Datenbank-Guru
- Beiträge
- 5.142
Ich würde das eher technisch nachbilden. Eine Filmfassung gibt es auf mehreren Medien (Blueray, DVD, VHS, Datei). Ein Medium kann mehrere Filme beinhalten (auch Bonus Material oder eben zweite Filmversion) die jeweils immer eine Videospur haben (wenn ich mich nicht irre geht es nicht anders) und mehere Tonspuren beinhalten können. Jede Videospur eines Films hat mindestens das technisch vorgegebene Seitenverhältnis und, Gott bewahre ein reales Seitenverhältnis wenn im Film Schwarze Balken mit kodiert wurden. Beide würde ich wenn dann direkt in der Tabelle abbilden, in der auch die anderen Informationen zum Film liegen. Das Seitenverhältnis könnte dann entweder einer deiner bekannten Varianten entsprechen und würde in diesem Fall wie ein Fremdschlüssel fungieren, könnte aber auch ein völlig ungenormtes Format haben.
Sophus
SQL-Guru
- Beiträge
- 135
Hallo ukulele,
zum Thema »Medium« werde ich noch kommen. Wir müssen ja auch nicht so banal denken. Es ist ja auch Möglich, dass man einen Film als Datei auf seinem Rechner liegen hat. Und auf einen DVD-Rolling dann mehrere Film-Dateien kopiert. Dies hast du ja schon angedeutet. Aber wenn ich dich richtig verstanden habe, würdest du in diesem Fall keine n:m-Beziehung bevorzugen, so wie ich es gerade abgebildet habe? Du würdest die Relationen BildFormat und BildKategorie als Attribute in die Relation FilmFassung einbauen? Oder meintest du eher eine 1:n-Beziehung? Ich gin immer davon aus, dass auf einer originalen DVD mehrere Bildformate angeboten werden - genauso wie bei Audioformate. Daher nahm ich an, wäre eine n:m-Beziehung angebracht. Im Falle einer Film-Datei ist es richtig, dass diese Fassung dann nur ein Audioformat und ein Bildformat hat. Es sei denn, man rippt die komplette DVD als Sicherheitskopie. So hat man quasi alles übernommen.
zum Thema »Medium« werde ich noch kommen. Wir müssen ja auch nicht so banal denken. Es ist ja auch Möglich, dass man einen Film als Datei auf seinem Rechner liegen hat. Und auf einen DVD-Rolling dann mehrere Film-Dateien kopiert. Dies hast du ja schon angedeutet. Aber wenn ich dich richtig verstanden habe, würdest du in diesem Fall keine n:m-Beziehung bevorzugen, so wie ich es gerade abgebildet habe? Du würdest die Relationen BildFormat und BildKategorie als Attribute in die Relation FilmFassung einbauen? Oder meintest du eher eine 1:n-Beziehung? Ich gin immer davon aus, dass auf einer originalen DVD mehrere Bildformate angeboten werden - genauso wie bei Audioformate. Daher nahm ich an, wäre eine n:m-Beziehung angebracht. Im Falle einer Film-Datei ist es richtig, dass diese Fassung dann nur ein Audioformat und ein Bildformat hat. Es sei denn, man rippt die komplette DVD als Sicherheitskopie. So hat man quasi alles übernommen.
ukulele
Datenbank-Guru
- Beiträge
- 5.142
Ich dachte eher an sowas:
Filmfassung/Edition <--1:n--> Medium <-- 1:n --> Inhalt (Atribut Bildformat) <-- n:1 --> genormte_Formate
Die Tabelle Medium beinhaltet dann DVDs etc., für nicht physikalische Medien wie z.B. ein Download oder Stream on Demand oder ähnliches könnte man hier später etwas aufbohren. Dann kann ein Medium ggf. auch eine (Archiv)-Datei sein, auch wenn es etwas verwirrend wird.
Die Tabelle Inhalt bildet dann für jedes Video oder jede Datei die durch das Medium geliefert wird die Atribute ab inklusive Bildformat. Tonspuren/Formate müssen nochmal per 1:n Beziehung ausgelagert werden, jedes Video/Datei/Film in Inhalt hat aber maximal eine Videospur und somit auch maximal ein Format.
Über eine Tabelle genormte_Formate ließe sich dann z.B. der Academy-Standard des Videos identifizieren, es müsste aber nicht zwingend einem Standard entsprechen.
Abschließend nochmal zum Medium: Ein Medium kann theoretisch auch mehrere Filmfassungen beinhalten (was wohl eher selten der Fall sein wird). Hier wäre auch eine n:m Beziehung denkbar, die macht die Sache aber deutlich komplexer.
Filmfassung/Edition <--1:n--> Medium <-- 1:n --> Inhalt (Atribut Bildformat) <-- n:1 --> genormte_Formate
Die Tabelle Medium beinhaltet dann DVDs etc., für nicht physikalische Medien wie z.B. ein Download oder Stream on Demand oder ähnliches könnte man hier später etwas aufbohren. Dann kann ein Medium ggf. auch eine (Archiv)-Datei sein, auch wenn es etwas verwirrend wird.
Die Tabelle Inhalt bildet dann für jedes Video oder jede Datei die durch das Medium geliefert wird die Atribute ab inklusive Bildformat. Tonspuren/Formate müssen nochmal per 1:n Beziehung ausgelagert werden, jedes Video/Datei/Film in Inhalt hat aber maximal eine Videospur und somit auch maximal ein Format.
Über eine Tabelle genormte_Formate ließe sich dann z.B. der Academy-Standard des Videos identifizieren, es müsste aber nicht zwingend einem Standard entsprechen.
Abschließend nochmal zum Medium: Ein Medium kann theoretisch auch mehrere Filmfassungen beinhalten (was wohl eher selten der Fall sein wird). Hier wäre auch eine n:m Beziehung denkbar, die macht die Sache aber deutlich komplexer.
Sophus
SQL-Guru
- Beiträge
- 135
Da bin ich wieder,
hier erst einmal meine grafische Modellierung:
Sieht im ersten Moment recht viel aus, ist aber fast die gleiche Modellierung, nur dass ich hierbei das Thema »Medium« mit eingebunden habe. Wir sehen hier zwischen der Relation FilmFassung und Medium eine Zwischentabelle Filmfassung_Medium. Der Grund für die n:m-Beziehung war: nehmen wir mal an, wir haben von einem Film mehrere Fassungen, und diese als Dateien (angenommen, er oder sie hat es via VoD erworben). Jetzt haben wir also von einem Horrorfilm gleich mehrere Fassungen, diese sind dann auf einem DVD-Rolling kopiert worden. Hier würde dann eine 1:n-Beziehung ausreichen. Aber es ist ja auch möglich, dass die Fassungen von diesem einen Film verteilt sind, und zwar auf DVD-Rolling A und auf DVD-Rolling B und so weiter, weil nicht alle Filme auf einen DVD-Rolling gepasst haben. Und schon wäre es eine n:m-Beziehung.
Und wenn ich später mal fragen möchte: Wo ist der Horrorfilm mit diesem bestimmten Bildformat? Als Antwort müsste es ungefähr lauten: Dieser Film, den du suchst, ist auf dem DVD-Rolling, mit der Beschriftung »A« und liegt im Wohnung im Regal.
Oder andersrum kann man auch fragen: Was ist alles auf diesem Medium (DVD-Rolling »A«)? Als mögliche Antwort: Auf diesem Medium (DVD-Rolling »A«) sind insgesamt 5 Filme, mit entsprechenden Informationen.
Übrigens, Editionen und Fassungen sind nicht das gleiche, und werden in meiner Modellierung auch getrennt voneinander behandelt
hier erst einmal meine grafische Modellierung:
Sieht im ersten Moment recht viel aus, ist aber fast die gleiche Modellierung, nur dass ich hierbei das Thema »Medium« mit eingebunden habe. Wir sehen hier zwischen der Relation FilmFassung und Medium eine Zwischentabelle Filmfassung_Medium. Der Grund für die n:m-Beziehung war: nehmen wir mal an, wir haben von einem Film mehrere Fassungen, und diese als Dateien (angenommen, er oder sie hat es via VoD erworben). Jetzt haben wir also von einem Horrorfilm gleich mehrere Fassungen, diese sind dann auf einem DVD-Rolling kopiert worden. Hier würde dann eine 1:n-Beziehung ausreichen. Aber es ist ja auch möglich, dass die Fassungen von diesem einen Film verteilt sind, und zwar auf DVD-Rolling A und auf DVD-Rolling B und so weiter, weil nicht alle Filme auf einen DVD-Rolling gepasst haben. Und schon wäre es eine n:m-Beziehung.
Und wenn ich später mal fragen möchte: Wo ist der Horrorfilm mit diesem bestimmten Bildformat? Als Antwort müsste es ungefähr lauten: Dieser Film, den du suchst, ist auf dem DVD-Rolling, mit der Beschriftung »A« und liegt im Wohnung im Regal.
Oder andersrum kann man auch fragen: Was ist alles auf diesem Medium (DVD-Rolling »A«)? Als mögliche Antwort: Auf diesem Medium (DVD-Rolling »A«) sind insgesamt 5 Filme, mit entsprechenden Informationen.
Übrigens, Editionen und Fassungen sind nicht das gleiche, und werden in meiner Modellierung auch getrennt voneinander behandelt
Werbung:
ukulele
Datenbank-Guru
- Beiträge
- 5.142
Sieht schonmal gut aus, im wesentlichen stimme ich zu.
Mein "Medium" bezog sich allerdings gedanklich erstmal auf "Kauf-" oder "Bezugs-Medium" wie Stream oder Download. Wenn dann 2 DVDs in der Hülle stecken wäre das für mich erstmal nur ein Eintrag. Natürlich wird es im privaten Umfeld dann schnell schwierig wenn der Film dann zur 2 CD-Version wird oder in 100MB RAR-Files dargestellt werden soll
Mein "Medium" bezog sich allerdings gedanklich erstmal auf "Kauf-" oder "Bezugs-Medium" wie Stream oder Download. Wenn dann 2 DVDs in der Hülle stecken wäre das für mich erstmal nur ein Eintrag. Natürlich wird es im privaten Umfeld dann schnell schwierig wenn der Film dann zur 2 CD-Version wird oder in 100MB RAR-Files dargestellt werden soll
Ähnliche Themen
