ERM - Einfache Fragen - Einfache Antworten? :)

[uglygeorge08]

Hallo zusammen,

Für eine Homepage starte ich gerade den Versuch, ein doch eher grösseres ERM zu erstellen. Leider sind mir trotz vielen Hilfeseiten und Büchern noch diverse Fragen offen ..

Hier ein kleinen Überblich über meinen Fragekatalog:

1. Was ist in erster Linie das Ziel eines ERM?

Mir ist durchaus klar, dass es die Datenbankstruktur darstellen sollte, aber wie kann man z.B ein gutes ERM von einem schlechten unterscheiden?

- möglichst wenig Tables?

- keine redundanz an Attributen?

- gute visuelle Überschaubarkeit?

Kann man auch indirekt Einfluss auf die Geschwindigkeit einer Datenbank haben (zuviele tables, zu lange Namen).

2. Welche Relation würdet ihr in folgendem Beispiel verwenden, wenn auf einer Homepage, diverse User, diverse Gästebucheinträge machen können?

[user]-||-----|<- [Einträge]

oder

[user]||-----|< [user_Einträge] >|-----||[Einträge]

a) (1 - n) Ein User kann einen oder mehrere Einträge machen.

(n - m ) Ein oder mehrere User können einen oder mehrere Einträge machen.

Für mich persönlich hört sich beides logisch an?

3. Wie beschreibt ihr bei einer Zwischenentität die Tabelle? Ich habe hier enorme Probleme, einen passenden Namen zu finden ...

Ich danke euch schon im voraus für euren Aufwand und bin für jeden noch so kleinen Hinweis unendlich dankbar ..

Schöne Festtage.

Gruss

Uglygoerge08

[127.0.0.1]

zu 2.

die relation ist 1:n

ein user kann viele einträge machen; ein eintrag kann nur von genau einem user gemacht werden.

zu 3.

genau so, wie du es getan hast:

>>user<<, >>eintraege<< --> T_user_eintraege

[uglygeorge08]

zu 2.

die relation ist 1:n

ein user kann viele einträge machen; ein eintrag kann nur von genau einem user gemacht werden.

zu 3.

genau so, wie du es getan hast:

>>user<<, >>eintraege<< --> T_user_eintraege

Danke du hast mir schon enorm geholfen ..

Ich will euch ja nicht nerven, aber vielleicht wisst ihr auch folgende Frage:

Facebook hat ja xxx Millionen Kunden welche alle ihre Daten wie Name, Vorname, Strasse, Hausnummer angeben.

Es wäre also nicht falsch bei einer Entität "Adresse", für alle Attribute (Vorname, Nachname, Strasse, PLZ, Ort) eine eigene Entität zu machen?^^

Bsp:

Adresse:

AdresseID

Name_ID

Vorname_ID

Strasse_ID

Name

NameID

Name

Vorname:

Vorname_ID

Vorname

Für die Relation verwende ich eine "nicht intenfizierte" Verknüpfung". Ergibt das soweit einen Sinn?^^

Wenn man das hochrechnen würde, so könnte man doch blöd viel Speicherplatz sparen?

Danke dir für deine Hilfe.

Gruss

Ugly

Bearbeitet 23. Dezember 2010 von uglygeorge08

[uglygeorge08]

bump ..

[dr.dimitri]

Es wäre also nicht falsch bei einer Entität "Adresse", für alle Attribute (Vorname, Nachname, Strasse, PLZ, Ort) eine eigene Entität zu machen?

Die Adresse kommt in eine eigene Entität, die Personendaten ebenfalls. Weiter würde ich das nicht mehr trennen, denn ansonsten wäre es viel zu langsam hier die Daten wieder zusammenzusuchen.

Wie beschreibt ihr bei einer Zwischenentität die Tabelle?

Das was sie macht. Wenn z.B. ein Artikel und eine Rechnung eine n:m Beziehung aufweisen, dann ist die Verknüpfungstabelle eben die Bestellposition.

Kann man auch indirekt Einfluss auf die Geschwindigkeit einer Datenbank haben (zuviele tables, zu lange Namen).

Die Namen sind egal, die Anzahl der Tabellen auch. Wenn Du 1000 brauchst, dann brauchst Du eben 1000. Wenn Du aber eine Beziehung mit 3 Tabellen beschreiben kannst, es ohne Not aber mit 7 machst, dann wird das Deine Performance deutlich beeinflussen sobald Last auf die Maschine kommt und die Tabellen mit Daten befüllt werden.

Dim

[uglygeorge08]

Die Adresse kommt in eine eigene Entität, die Personendaten ebenfalls. Weiter würde ich das nicht mehr trennen, denn ansonsten wäre es viel zu langsam hier die Daten wieder zusammenzusuchen.

Das was sie macht. Wenn z.B. ein Artikel und eine Rechnung eine n:m Beziehung aufweisen, dann ist die Verknüpfungstabelle eben die Bestellposition.

Die Namen sind egal, die Anzahl der Tabellen auch. Wenn Du 1000 brauchst, dann brauchst Du eben 1000. Wenn Du aber eine Beziehung mit 3 Tabellen beschreiben kannst, es ohne Not aber mit 7 machst, dann wird das Deine Performance deutlich beeinflussen sobald Last auf die Maschine kommt und die Tabellen mit Daten befüllt werden.

Dim

Danke Dim,

Du hast mir schon ernorm geholfen und man sieht das du auf diesem Gebiet ein grosses Know-How hast ..

Ich finde bei einem ERM ist es saumässig schwer, eine Balance zwischen "wenig Tabellen" und "gute Administration" zu finden.

Momentan bin ich soweit, dass ich sogar Strassen in eine neue Tabelle packe und so fast nur mit Primär und Fremdschlüssel arbeite.

Auf der einen Seite würde das bei vielen Nutzern sicher Speicherplatz sparen und die Administration erleichtern.

Leider habe ich jetzt aber von dir erfahren, dass dann die Datenbank länger für die Verarbeitung der Daten benötigt.

Gibt es eine Grundregel wie man diesen Spagat zwischen "schnelle DB" und "wenig Speicherplatz / leichte Administation" lösen kann?

Wichtig ist wahrscheinlich auch die Anzahl User welche dann auf die DB zugreifen werden, Facebook wird wahrscheinlich mit Sicherheit auch Namen, Strassen etc in eine neue Tabelle verpackt haben?

Nichts destotrotz danke ich dir für deine Hilfe, dann werde ich das ganze mal wieder ein bisschen umstrukturieren ... ^^

Achja vielleicht kannst du mir auch diese Frage beantworten:

Du hast mir gesagt, dass eine Menge an Tables nicht gut sei, aber ich vermute dass du da die Relationen zu den Entitäten gemeint hast? Schlussendlich wird die die Tabelle Adresse ja keinen Einfluss z.B auf das Wetter haben ...

okey okey - wenn ich keine lokale Prognose möchte .. ^^

Frohe Weihnachten & Gruss aus der Schweiz

Ugly

Bearbeitet 26. Dezember 2010 von uglygeorge08

[uglygeorge08]

Danke Dim,

Du hast mir schon ernorm geholfen und man sieht das du auf diesem Gebiet ein grosses Know-How hast ..

Ich finde bei einem ERM ist es saumässig schwer, eine Balance zwischen "wenig Tabellen" und "gute Administration" zu finden.

Momentan bin ich soweit, dass ich sogar Strassen in eine neue Tabelle packe und so fast nur mit Primär und Fremdschlüssel arbeite.

Auf der einen Seite würde das bei vielen Nutzern sicher Speicherplatz sparen und die Administration erleichtern.

Leider habe ich jetzt aber von dir erfahren, dass dann die Datenbank länger für die Verarbeitung der Daten benötigt.

Gibt es eine Grundregel wie man diesen Spagat zwischen "schnelle DB" und "wenig Speicherplatz / leichte Administation" lösen kann?

Wichtig ist wahrscheinlich auch die Anzahl User welche dann auf die DB zugreifen werden, Facebook wird wahrscheinlich mit Sicherheit auch Namen, Strassen etc in eine neue Tabelle verpackt haben?

Nichts destotrotz danke ich dir für deine Hilfe, dann werde ich das ganze mal wieder ein bisschen umstrukturieren ... ^^

Achja vielleicht kannst du mir auch diese Frage beantworten:

Du hast mir gesagt, dass eine Menge an Tables nicht gut sei, aber ich vermute dass du da die Relationen zu den Entitäten gemeint hast? Schlussendlich wird die die Tabelle Adresse ja keinen Einfluss z.B auf das Wetter haben ...

okey okey - wenn ich keine lokale Prognose möchte .. ^^

Frohe Weihnachten & Gruss aus der Schweiz

Ugly

Konnte leider nicht mehr reineditieren.

"2. Ich habe eine Tabelle "Benutzer", jetzt habe ich aber ein Attribut in einer anderen Tabelle mi dem Namen "Letzte Antwort", welches auf einen Benutzer verweist.

z.B Die letzte Antwort bei diesem Thema hat der "Benutzer A" gemacht. Verlinke ich nun die Benutzer_ID von der Entität Benutzer in die Tabelle "Einträge", so erscheint dort logischerweise die "Benutzer_ID. Wie soll ich aber in einer Woche noch wissen, dass die Benutzer_ID für die letzte Antwort steht und nicht für was anderes?^^

Benutzer_ID ist ja nicht sehr eindeutig, was die Aussage betrifft. Soll ich da eine neue Tabelle "Letzte Antwort" erstellen und sie mit dem Benutzer verlinken? Eventuell noch das Datum hinzufügen? oder Ebenfalls von der Tabelle Datum verlinken? ^^"

Gruss

Ugly

[dr.dimitri]

Ich finde bei einem ERM ist es saumässig schwer, eine Balance zwischen "wenig Tabellen" und "gute Administration" zu finden.

Da gibt es eigentlich keine Balance zu finden. Was gebraucht wird, wird angelegt. Einer Datenbank ist es egal, ob sie 100 oder 120 Tabellen beinhaltet. Das macht auch die Administration nicht einfacher oder schwerer.

Momentan bin ich soweit, dass ich sogar Strassen in eine neue Tabelle packe und so fast nur mit Primär und Fremdschlüssel arbeite.

Das kann man als Lookuptabelle durchaus so machen (um z.B. einen eingegebenen Strassennamen zu prüfen) abspeichern würde ich das aber immer als Klartext in der entsprechenden Tabelle. Sprich Du hast als Stammdaten z.B. eine Tabelle mit PLZ und Strassennamen, eine mit Vorwahlnummern etc. aber wenn der User dann seine Adresse wirklich eingegeben hat, wird der, vorher anhand der Stammtabellen verifizierte Inhalt, im Klartext in die Adresstabelle geschrieben.

Auf der einen Seite würde das bei vielen Nutzern sicher Speicherplatz sparen

Speicherplatz ist billig. Eine zu langsame Datenbank nicht. Wieviel GB benötigt man, um 10 Millionen Adressdaten zu speichern? Wenn man mal von, sagen wir 500 Byte pro User ausgeht, dann würden 10 Millionen auf ~5GB kommen - also nix. Wenn ich das jetzt auf 2GB drücken kann, weil ich extrem normalisiert habe, spare ich mir wieviel Euro?

Dagegen stehen dann eine deutlich verschlechterte Performance, weil meine SQL Statements für jeden Zugriff noch über weitere Tabellen joinen müssen, ausserdem erhöhter Entwicklungsaufwand, denn jede zusätzliche Tabelle erhöht die technische Komplexität - bei gleicher fachlichkeit des Programms.

Grundsätzlich geht man so heran, dass man zuerst mal ein ER-Modell designed, welches die Anforderungen an Daten und Flexibilität erfüllt - dazu ist selbstverständlich eine genaue fachliche Anforderung nötig. Dieses ER-Modell liegt dann in der 3. NF vor. Jetzt beginnt man gezieht zu denormalisieren d.h. Redundanzen einzubauen, um Zugriffe zu beschleunigen und die Entwicklung zu vereinfachen. Das ganze ist natürlich auch Übungssache, wie auch beim Autofahren so wird aus des Modellieren mit der Zeit besser werden (zumindest bei den meisten...)

Facebook wird wahrscheinlich mit Sicherheit auch Namen, Strassen etc in eine neue Tabelle verpackt haben?

Keine Ahnung. Ich bin nicht mal bei facebook angemeldet geschweige denn, dass ich irgendeine Ahnung von deren Datenmodell hätte. Webdatenbanken sind aber allgemein eher stärker denormalisiert, da es im Netz nix schlimmeres gibt als eine Wartezeit länger als 2 Sekunden. Dazwischen gibt es selbstversändlich noch Proxies, die Abfragen cachen, Loadbalancer etc. etc. um die Last auf die Datenbanken so gering wie möglich zu halten.

Wie soll ich aber in einer Woche noch wissen, dass die Benutzer_ID für die letzte Antwort steht und nicht für was anderes?

Das Problem hast Du doch überall. Dazu gibt es Tabellen- und Spaltenkommentare, die in der DDL eingefügt werden können (je nach Datenbank ist die Syntax unterschiedlich) und zum anderen natürlich eine Dokumentation des Modells in Prosa bzw. über Constraints (die Benutzer_id wird vermutlich einen FK-Constraint auf die Benutzertabelle haben).

Dann weißt Du auch noch in einer Woche, dass dieses Feld die Benutzertabelle referenziert. Wenn Du aber nicht mehr sicher bist, warum das nötig war solltest Du dir die Anforderung nochmal durchlesen

Dim

[uglygeorge08]

Da gibt es eigentlich keine Balance zu finden. Was gebraucht wird, wird angelegt. Einer Datenbank ist es egal, ob sie 100 oder 120 Tabellen beinhaltet. Das macht auch die Administration nicht einfacher oder schwerer.

Das kann man als Lookuptabelle durchaus so machen (um z.B. einen eingegebenen Strassennamen zu prüfen) abspeichern würde ich das aber immer als Klartext in der entsprechenden Tabelle. Sprich Du hast als Stammdaten z.B. eine Tabelle mit PLZ und Strassennamen, eine mit Vorwahlnummern etc. aber wenn der User dann seine Adresse wirklich eingegeben hat, wird der, vorher anhand der Stammtabellen verifizierte Inhalt, im Klartext in die Adresstabelle geschrieben.

Speicherplatz ist billig. Eine zu langsame Datenbank nicht. Wieviel GB benötigt man, um 10 Millionen Adressdaten zu speichern? Wenn man mal von, sagen wir 500 Byte pro User ausgeht, dann würden 10 Millionen auf ~5GB kommen - also nix. Wenn ich das jetzt auf 2GB drücken kann, weil ich extrem normalisiert habe, spare ich mir wieviel Euro?

Dagegen stehen dann eine deutlich verschlechterte Performance, weil meine SQL Statements für jeden Zugriff noch über weitere Tabellen joinen müssen, ausserdem erhöhter Entwicklungsaufwand, denn jede zusätzliche Tabelle erhöht die technische Komplexität - bei gleicher fachlichkeit des Programms.

Grundsätzlich geht man so heran, dass man zuerst mal ein ER-Modell designed, welches die Anforderungen an Daten und Flexibilität erfüllt - dazu ist selbstverständlich eine genaue fachliche Anforderung nötig. Dieses ER-Modell liegt dann in der 3. NF vor. Jetzt beginnt man gezieht zu denormalisieren d.h. Redundanzen einzubauen, um Zugriffe zu beschleunigen und die Entwicklung zu vereinfachen. Das ganze ist natürlich auch Übungssache, wie auch beim Autofahren so wird aus des Modellieren mit der Zeit besser werden (zumindest bei den meisten...)

Keine Ahnung. Ich bin nicht mal bei facebook angemeldet geschweige denn, dass ich irgendeine Ahnung von deren Datenmodell hätte. Webdatenbanken sind aber allgemein eher stärker denormalisiert, da es im Netz nix schlimmeres gibt als eine Wartezeit länger als 2 Sekunden. Dazwischen gibt es selbstversändlich noch Proxies, die Abfragen cachen, Loadbalancer etc. etc. um die Last auf die Datenbanken so gering wie möglich zu halten.

Das Problem hast Du doch überall. Dazu gibt es Tabellen- und Spaltenkommentare, die in der DDL eingefügt werden können (je nach Datenbank ist die Syntax unterschiedlich) und zum anderen natürlich eine Dokumentation des Modells in Prosa bzw. über Constraints (die Benutzer_id wird vermutlich einen FK-Constraint auf die Benutzertabelle haben).

Dann weißt Du auch noch in einer Woche, dass dieses Feld die Benutzertabelle referenziert. Wenn Du aber nicht mehr sicher bist, warum das nötig war solltest Du dir die Anforderung nochmal durchlesen

Dim

Wow besten Dank für deine top ausführliche Antwort ..

Falls ich mich mal revanchieren kann, einfach melden .. ^^

Gruss

Ugly

[uglygeorge08]

Jetzt liegt mir schon wieder die nächste Frage auf den Lippen ... :hells:

Und zwar geht es dieses mal um den Unterschied von "idenzifizierten" und "nicht identifizierten" Relationen.

Gewisse Dinge konnte ich schon herausfinden:

- identifizierte Relationen geben die ebenfalls idenzfizierten Schlüsse der Tabelle an die nächste weiter.

- werden bei der n - m Beziehung angewendet, bei welcher der Primärschlüssel, zugleich dem Fremdschlüssel entspricht.

- werden dann angewendet, wenn man nur mit deinem Primärschlüssel den Datensatz nicht eindeutig idenzifizieren kann?

Habe diverse Erklärung zu diesem Thema durchgelesen, aber wirklich auf die Sprünge geholfen hat es mir nicht.

Wenn es dir nichts ausmacht, könntest du mir das an einem einfachen Beispiel erklären?

Ich hoffe das ich dir nicht auf die nerven gehe. Ich möchte einfach ein wirklich gutes ERM für meine Homepage erstellen, damit ich es zu einem späteren Zeitpunkt nicht bereue ....

achja ... mit welchen Datenbankschemen hast du in Vergangenheit eigentlich gearbeitet?

Gruss

Ugly

[dr.dimitri]

Hmm ich hab die Begriffe so noch nie gehört, gehören wohl eher in die theoretische Abteilung

identifizierte Relationen geben die ebenfalls idenzfizierten Schlüsse der Tabelle an die nächste weiter.

Das ist der Normalfall. Der PK der übergeordneten Tabelle wird als FK in der untergeordneten abgelegt.

werden bei der n - m Beziehung angewendet, bei welcher der Primärschlüssel, zugleich dem Fremdschlüssel entspricht.

Kann man machen, ich würde aber davon abraten einen PK gleichzeitig auch als FK zu verwenden. Zum einen könnest Du Probleme bekommen, wenn doppelte Einträge vorhanden sind (ein PK ist immer Unique) zum anderen macht es die Sache m.M. nach unübersichtlicher. So knapp sind wir nicht an Spalten und dieses Vorgehen erinnert mich an den Code, den diverse "Gurus" in ihren Programmen hinterlassen (Variablen haben grundsätzlich nur einen Buchstaben, alles was nicht unbedingt sein muss wird weggelassen. Sieht cool aus, kann nur keiner mehr lesen). Wir machen sowas natürlich nicht, sondern legen eine eigene Spalte für den PK an.

werden dann angewendet, wenn man nur mit deinem Primärschlüssel den Datensatz nicht eindeutig idenzifizieren kann?

Da Du hoffentlich für einen PK immer ein rein technisches Feld ohne jeglichen fachlichen Bezug verwendet hast, kommst Du überhaupt nicht in diese Verlegenheit. Verwende als PK immer eine laufende Nummer (generiert von der DB per Sequenze, AutoInc) oder eine GUID. Möglich wäre auch, ein per Definition eindeutiges fachliches Feld zu verwenden und dieses in der Tabelle zu doppeln.

Beispiel: Die Sozialversicherungsnummer ist eindeutig. Dann hast Du ein Feld ID für den PK und ein Feld SOZVERSNR, welche mit identischen Werten bestückt werden.

Kann manchmal ganz nützlich sein, wenn man als Entwickler "weis", dass der PK einen gewissen fachlichen Hintergrund hat. Im Programm selbst wird natürlich nur die SOZVERSNR an die Oberfläche geliefert, die ID wird lediglich im Hintergrund verwendet.

achja ... mit welchen Datenbankschemen hast du in Vergangenheit eigentlich gearbeitet?

Schema? Du meinst den Hersteller? Fast ausschließlich Oracle.

Dim

[uglygeorge08]

Hmm ich hab die Begriffe so noch nie gehört, gehören wohl eher in die theoretische Abteilung

Das ist der Normalfall. Der PK der übergeordneten Tabelle wird als FK in der untergeordneten abgelegt.

Kann man machen, ich würde aber davon abraten einen PK gleichzeitig auch als FK zu verwenden. Zum einen könnest Du Probleme bekommen, wenn doppelte Einträge vorhanden sind (ein PK ist immer Unique) zum anderen macht es die Sache m.M. nach unübersichtlicher. So knapp sind wir nicht an Spalten und dieses Vorgehen erinnert mich an den Code, den diverse "Gurus" in ihren Programmen hinterlassen (Variablen haben grundsätzlich nur einen Buchstaben, alles was nicht unbedingt sein muss wird weggelassen. Sieht cool aus, kann nur keiner mehr lesen). Wir machen sowas natürlich nicht, sondern legen eine eigene Spalte für den PK an.

Da Du hoffentlich für einen PK immer ein rein technisches Feld ohne jeglichen fachlichen Bezug verwendet hast, kommst Du überhaupt nicht in diese Verlegenheit. Verwende als PK immer eine laufende Nummer (generiert von der DB per Sequenze, AutoInc) oder eine GUID. Möglich wäre auch, ein per Definition eindeutiges fachliches Feld zu verwenden und dieses in der Tabelle zu doppeln.

Beispiel: Die Sozialversicherungsnummer ist eindeutig. Dann hast Du ein Feld ID für den PK und ein Feld SOZVERSNR, welche mit identischen Werten bestückt werden.

Kann manchmal ganz nützlich sein, wenn man als Entwickler "weis", dass der PK einen gewissen fachlichen Hintergrund hat. Im Programm selbst wird natürlich nur die SOZVERSNR an die Oberfläche geliefert, die ID wird lediglich im Hintergrund verwendet.

Schema? Du meinst den Hersteller? Fast ausschließlich Oracle.

Dim

Hallo Dim,

Und wiedermal hast du mir wieder aus der Schlinge geholfen ..

Mit den Schemen meinte ich folgendes:

Schneeflockenschema:

Schneeflockenschema ? Wikipedia

Sternschema:

Sternschema ? Wikipedia

Gruss

Ugly

Bearbeitet 29. Dezember 2010 von uglygeorge08

[uglygeorge08]

Hey Dim,

War wieder mal zu langsam beim editieren ..

Zum nochmals deine Aussage zusammenzufassen, dü würdest also auf "identifizierte Relationen" verzichten und alles mit eindeutigen PK"s machen?

Sprich bei einer N-M Beziehung anstatt:

Bold = FK

Unterline = PK

Das erste Beispiel wäre mit itendifizierten und das zweite mit non - identifizierten Relationen ..

Gruss

Ugly

Bearbeitet 29. Dezember 2010 von uglygeorge08

[dr.dimitri]

Letzteres wäre meine Wahl.

Bezüglich der Schemate: Ich bin im Schneeflockenschema zuhause. Reine OLAP Systeme habe ich bisher noch nicht designed.

Dim

[uglygeorge08]

Letzteres wäre meine Wahl.

Bezüglich der Schemate: Ich bin im Schneeflockenschema zuhause. Reine OLAP Systeme habe ich bisher noch nicht designed.

Dim

Okey danke dir ..