Modellierung meiner Datenbank

[ukulele]

Vom praktischen Standpunkt gesehen ist die Frage, was passiert mit dem Vornamen. Wird er immer in voller Länge angezeigt und immer eindeutig gesucht oder werden z.B. Vergleiche angestellt. Beispiel in meinem Fall CRM:
Ein Unternehmen, 3 bekannte Personen aus verschiedenen Datenquellen:
P1 Hans Müller
P2 Hans W. Mülller
P3 Hans Werner Müller
Ich gehe daher und versuche Dubletten zu finden in dem ich z.B. annehme, das zumindest P2 und P3 identisch sind. Wenn ich hier jetzt mit Warscheinlichkeiten Anfange könnte ich auf die Idee kommen die Häufigkeit von Vornamen zu ermitteln, das geht nur sehr ungenau wenn Hans Werner und Hans als unterschiedliche Vornamen angesehen werden.

Auch könnte ich auf die Idee kommen wie in meinen vorherigen Beispielen Vornamen verkürzt anzuzeigen. Wenn sich Hans Werner mit Werner vorstellt und ansprechen läßt muss ich das abbilden können. Anrede Briefpost kann dann Hans Werner und Anrede E-Mail Werner sein. Anzeigename könnte automatisch für die Kurzdarstellung auf Hans W. gesetzt werden, und so weiter.

Beim Nachnamen sollte es eigentlich immer nur einen geben, der zu einem Zeitpunkt Gültigkeit besitzt. Meines wissens nach werden Nachnamen in DE nicht abgekürzt oder ähnliches.

 

[Sophus]

@Sophus In meinem Beispiel ist auch der Vorname atomisiert. Du kannst ja soviele Namen vom Typ "Vorname" angeben wie du willst Oder willst du das ganze auf die einzelnen Buchstaben runterbrechen ?

Und generell würde ich sagen mach es einfach. In einem Jahr kommt dann jemand auf die Idee irgendeine Abfrage auf Vornamen laufen zu lassen und du musst dein Design wieder ändern

Ich glaube ich formuliere mich unglücklich. Das was Distrilec gemacht hat, ist bis aufs äußerste atomisiert. Die Vornamen sind zerlegt. Für mich stellt sich die Frage, ob dieser Vorgang übertrieben ist oder nicht? Es ist nämlich so, dass ein Bekannter von mir meinte "Ja, man kann auch mit der Atomisierung übertreiben", weil er meinte, dass viele Programm zum Beispiel Adressbücher sämtliche Vornamen einheitlich zusammenfassen, sprich, egal wie viele Vornamen ein Mensch hat, all diese Vornamen werden in die Datenbank in eine Zeile gebracht. Das war nur meine Überlegung.

 

[Sophus]

Vom praktischen Standpunkt gesehen ist die Frage, was passiert mit dem Vornamen. Wird er immer in voller Länge angezeigt und immer eindeutig gesucht oder werden z.B. Vergleiche angestellt. Beispiel in meinem Fall CRM:
Ein Unternehmen, 3 bekannte Personen aus verschiedenen Datenquellen:
P1 Hans Müller
P2 Hans W. Mülller
P3 Hans Werner Müller
Ich gehe daher und versuche Dubletten zu finden in dem ich z.B. annehme, das zumindest P2 und P3 identisch sind. Wenn ich hier jetzt mit Warscheinlichkeiten Anfange könnte ich auf die Idee kommen die Häufigkeit von Vornamen zu ermitteln, das geht nur sehr ungenau wenn Hans Werner und Hans als unterschiedliche Vornamen angesehen werden.

Auch könnte ich auf die Idee kommen wie in meinen vorherigen Beispielen Vornamen verkürzt anzuzeigen. Wenn sich Hans Werner mit Werner vorstellt und ansprechen läßt muss ich das abbilden können. Anrede Briefpost kann dann Hans Werner und Anrede E-Mail Werner sein. Anzeigename könnte automatisch für die Kurzdarstellung auf Hans W. gesetzt werden, und so weiter.

Beim Nachnamen sollte es eigentlich immer nur einen geben, der zu einem Zeitpunkt Gültigkeit besitzt. Meines wissens nach werden Nachnamen in DE nicht abgekürzt oder ähnliches.

So extrem wie bei dir werde ich mit den Namen nicht arbeiten. Mein Programm zielt darauf hinaus bestimmte Medien zu verwalten wie Filme, Serien, Bücher, Alben, Singles, Schallplatten, Magazine, Briefmarke, Videospiele etc. Und zur Zeit fange ich bei der Kategorie Filme an. Dort werden Personen gespeichert die entweder als Schauspieler, Kameramann, Regisseur, Drehbuchautor etc fungieren. Es soll also keine Kundenverwaltung werden wie in deinem Fall.

 

[ukulele]

So extrem wie bei dir werde ich mit den Namen nicht arbeiten. Mein Programm zielt darauf hinaus bestimmte Medien zu verwalten wie Filme, Serien, Bücher, Alben, Singles, Schallplatten, Magazine, Briefmarke, Videospiele etc. Und zur Zeit fange ich bei der Kategorie Filme an. Dort werden Personen gespeichert die entweder als Schauspieler, Kameramann, Regisseur, Drehbuchautor etc fungieren. Es soll also keine Kundenverwaltung werden wie in deinem Fall.

Bei Filmen könnte man auf die Idee kommen auch die Namen der Charaktäre in der selben Tabelle abzuspeichern. Für deinen Anwendungsfall würde ich aber auf die Zerlegung von Vornamen verzichten.

 

[Distrilec]

Vom praktischen Standpunkt gesehen ist die Frage, was passiert mit dem Vornamen. Wird er immer in voller Länge angezeigt und immer eindeutig gesucht oder werden z.B. Vergleiche angestellt.

@Sophus Ist das nicht die Antwort auf deine Frage ?
Atomisieren muss man soweit, wie man später auch Auswertungen laufen lassen will...
Du kannst Vorname, Nachname und Künstlername auch einfach Kommagetrennt in ein Feld packen, wenn dir der Name erstmal vollkommen egal ist und rein informativ da ist

 

[Hony%]

Das heißt jedoch, dass ich auf der Seite meines Programms CASCADE ON UPDATE "ansprechen" muss? Denn von allein kommt die Datenbank sicherlich nicht auf die Idee dies auszuführen.

Das ist ja der Witz. Durch die Definition von CASCADE wird die Datenbank das ganz automatisch und selbstständig tun.

Zumal diese CASCADE ON UPDATE-Funktion nicht von allen bzw. von den meisten DBMS unterstützt werden.

Ich weiß ja nicht welche Exoten du unterstützen willst. Meines Wissens nach unterstützen heute alle namhaften Systeme CASCADE. Sogar Access sollte damit umgehen können.

Meine Frage ist einfach, ob man sämtliche Vornamen einfach unatomisiert in eine Zeile verlegen soll oder diese zerlegen soll?

Alle Vornamen als String zu speichern wäre ein Verstoß gegen die 1. Normalform. Natürlich zwingt dich niemand dazu solche Regeln einzuhalten. Wenn dir dein Design irgendwann auf die Füße fällt brauchst du dich dann aber auch nicht zu beschweren. ;-)

 

[Sophus]

Hallo Leute,

nach langem Hin und Her habe ich mich dazu entschieden alle Vornamen in eine Zeile zu speichern, sprich, keine weitere Atomisierung vorzunehmen.


Wir sehen in meiner Abbildung, dass ich bei KünstlerVorname und Vorname extra 200 Zeichen zulasse. Sollte allein der KünstlerVorname oder Vorname weit über 200 Zeichen gehen, dann ist dies verdammt exotisch.

Damit wir weiter vorankommen, habe ich zwei neue Elemente hinzugeholt. Einmal die Tabelle Funktion und Rolle. Was soll in diesen Tabellen gespeichert werden? In der Tabelle Funktion sollen zum Beispiel folgende Funktionen abgespeichert werden: Schauspieler, Drehbuchautor, Visagist, Kameramann, Regisseur etc. Und da eine Person mehre Funktionen übernehmen kann, zum Beispiel kann eine Person Regisseur, Drehbuchautor und Schauspieler zugleich sein, so habe ich eine Zwischentabelle/Verknüpfungstabelle eingerichtet. Bei der Tabelle Rolle werden die Rollennamen gespeichert, die von einem Schauspieler gespielt werden. Nun könnte man sich fragen, wieso hier wieder eine Zwischentabelle/Verknüpfungstabelle eingerichtet wurde. In den meisten Fällen spielt ein Schauspieler in einem Film auch nur eine Rolle. Aber es gibt einen Film, der heißt "Der verrückte Professor", der 1996 rauskam. In dem Film spielt der Schauspieler Eddie Murphy gleich mehrere Rollen. Daher kam ich auf die Idee mit der Verknüpfungstabelle.

Ich bin auf eure Anmerkungen und Kritik gespannt.

 

[Distrilec]

@Sophus legst du denn für jeden Film eine neue Person an, oder warum haben die Tabellen Funktion und Rolle kein FK zum Film ? ^^

 

[Sophus]

@Sophus legst du denn für jeden Film eine neue Person an, oder warum haben die Tabellen Funktion und Rolle kein FK zum Film ? ^^

Hallo Distrilec, denke doch nicht gleich so schnell ;-) Bevor ich zu dem Film-Teil rüber gehe, wollte ich zunächst einmal den Person-Teil in sich abschließen. Wenn ich eins in meinem Studium gelernt habe, ist, dass man niemals zu viel auf einmal thematisieren sollte. Selbstverständlich werden keine Personen angelegt die bereits existieren ;-) Zum Film-Teil also hier nach ;-) Ersteinmal wollte ich eure erfahrene Meinung, ob ihr etwas anzumerken habt.

 

[Sophus]

Das ist ja der Witz. Durch die Definition von CASCADE wird die Datenbank das ganz automatisch und selbstständig tun.


Ich weiß ja nicht welche Exoten du unterstützen willst. Meines Wissens nach unterstützen heute alle namhaften Systeme CASCADE. Sogar Access sollte damit umgehen können.

Dann muss ich einmal schauen wie man sowas unter Access definiert. Die Sache ist einfach, das der Anwender keine bereits leere strukturierte existierende Datenbank von mir bekommt, sondern, dass die Datenbank von meinem Programm aus erstellt wird. Und über diesen Weg muss ich dann also schauen wie ich die Tabellen als Cascade definiere. Wie wird dies über das Access-Programm definiert, wenn ich die Datenbank über die hauseigene Software von Microsoft bearbeiten bzw. erstellen will? Ich befürchte eher, dass dies nur über Beziehungen funktioniert.

 

[Distrilec]

@Sophus http://www.webucator.com/blog/2010/09/cascade-updates-in-microsoft-access-2010/ Zwei Sekunden mit Google

 

[Sophus]

@Sophus http://www.webucator.com/blog/2010/09/cascade-updates-in-microsoft-access-2010/ Zwei Sekunden mit Google

Jetzt stoppst du auch die Zeit beim Surfen Aber mal Spaß beiseite. Ich weiß nicht ob es in der Informatik "unmoralisch" ist, wenn ich auf Beziehungen verzichten und nur über Fremdschlüssel arbeiten werde. Und da eine Cascade nur im Zusammenhang von Beziehungen arbeitet, fällt für mich diese Option also weg. Ich werde an vielen Stellen nur mit nummerischen IDs arbeiten. Der entscheidene Faktor ist, dass diese IDs sich im Laufe der Verwaltung nie ändern wird. Ich kenne sowohl in der Theorie als auch in der Praxis keinen Grund, weshalb sich eine bereits eindeutig festgelegte nummerische ID sich hinterher nochmal ändern sollte. Wenn ich einige Situationen übersehen habe, so lasst es mich ruhig wissen.

Ein weiterer Grund, weshalb ich mich von Beziehungen fernhalte, ist, dass zum Beispiel zwischen Access-Datenbank und MySQL erhebliche Unterschiede gibt. Eine Access-Datenbank ist ja im Grunde eine Jet Engine-Datenkbank. Man kann über die hauseigene Software von Microsoft Access die Beziehungen einmalig definieren und festlegen. Hier ein Schaubild, was ich meine:

Und so wird nun in MySQl nicht gearbeitet. Zumindest ist mir kein Tool unter MySQL bekannt, das mir erlaubt so wie bei Access die Beziehungen so grafisch einmalig festzulegen. Soweit ich informiert bin, läuft das bei MySQL über Joins-Statements. Und diese müssen jedesmal erneut erstellt werden. Und da mein Programm sowohl Access als auch MySQL unterstützen soll, möchte ich mich soweit es geht universell halten, und lasse die Tabellen in den beiden DBMS einfach "reglos" nebeneinander liegen, ohne irgendwelche Beziehungen, und arbeite einfach nur über Fremdschlüssel. Wie gesagt, eine ID ändert sich nicht. Von daher sehe ich keinen Grund mit Beziehungen zu arbeiten.

Sollte ich irgendwelche Denkfehler haben, dann nur her damit

 

[Hony%]

Sollte ich irgendwelche Denkfehler haben, dann nur her damit

Und da eine Cascade nur im Zusammenhang von Beziehungen arbeitet, fällt für mich diese Option also weg.

Also Das hätte ich jetzt gerne genauer erklärt.

Soweit ich informiert bin, läuft das bei MySQL über Joins-Statements. […] und arbeite einfach nur über Fremdschlüssel.

Und wie genau gedenkst du ohne JOINs an deine Datensätze zu kommen?

 

[Sophus]

Wie ich an die Datensätze ohne Joins komme? Ich muss hier erst einmal gestehen, dass ich mit einer MySQL-Datenbank noch nicht intensiv gearbeitet habe, sondern nur mit Access. Aber ich stelle es mir so vor, dass ich über Verknüpfungstabellen (auch Relationalen Tabellen genannt) mir die Schlüssel hole, und diese dann in meine Abfrage dann einbaue.

Bildlich gesprochen stellen wir uns eine Form/Eingabemaske oder ein Formular vor. Das Fenster ist offen, und dort gibt es unteranderem eine ListView (eine Art Liste) in welcher die Schauspieler zu einem bestimmten Film angezeigt werden. Beim öffnen der Form / des Formulars werden zunächst einmal die Filmdaten geladen. Nun habe ich die Film-ID, die ich weiterverarbeiten kann. Nun schau mit Hilfe einer Abfrage in der Verknüpfungstabelle, welche Schauspieler-ID der Film-ID zugeordnet sind. Nun habe ich alle Schauspielr-IDs, die dem Film zugeordnet sind, und suche dann weiter in der Tabelle Person, wer sich alles hinter den Schauspielerr-Ids verbirgt und liste sie dann über meine ListView auf. Und das gleiche verfahre ich dann mit den Rollen, die die Schauspieler in dem Film spielen. So ungefähr ist meine Vorstellung. Im Grunde das, was ein INNER JOIN macht, nur dass ich es manuel mache.

Und zum Thema Cascade, dass diese nur im Zusammenhang der Beziehung funktioniere. Distrilec gab mir einen Link, in welcher gezeigt wird, wie man eine Cascade unter Access einrichten kann. Und dort wird es im Zusammenhang einer Beziehung gezeigt. Ohne Beziehung gäbe es anscheint keine Cascade-Option, wenn ich es richtig verstanden habe. Da ich aber weitestgehend mit nummerischen IDs arbeiten werde, wääre für mich die Cascade-Option sowieso hinfällig.

 

[Hony%]

Im Grunde das, was ein INNER JOIN macht, nur dass ich es manuel mache.

Wenn ich dich richtig verstehe willst du also tatsächlich alles manuell zusammen suchen? Du solltest als Backend wirklich plattformunabhängige Textdateien benutzen. Oder irgendeinen propritären Binärmatsch. Dürfte vermutlich deutlich schneller sein.

Und dort wird es im Zusammenhang einer Beziehung gezeigt. Ohne Beziehung gäbe es anscheint keine Cascade-Option, wenn ich es richtig verstanden habe.

Weil Microsoft das in unendlicher Weisheit so genannt hat. Sobald du Fremdschlüssel definierst, definierst du implizit Beziehungen. Beziehungen sind keine besondere Konstruktion oder Magie. Es handelt sich dabei nur um Metainformationen. In deinem »beziehungsfreien« Entwurf sind jede Menge Beziehungen enthalten. Du siehst sie nur nicht, weil du sie nicht verstanden hast.