Guten Abend
Kann mir jemand sagen, warum im ERM eine Beziehung ebenfalls Attribute haben kann und ob die dann nach der Überfürhung in eine Datenbank eine separate Relation ergeben?
Besten Dank für jede Unterstützung
Carla
Guten Abend
Kann mir jemand sagen, warum im ERM eine Beziehung ebenfalls Attribute haben kann und ob die dann nach der Überfürhung in eine Datenbank eine separate Relation ergeben?
Besten Dank für jede Unterstützung
Carla
Hallo Carla,
Attribute, die die Beziehung beschreiben gehören zur Relation.
Kunde - kauft - Produkt
|
Preis
Der Preis gehört nicht zum Produkt, sondern zum Kaufvorgang.
1:N-Relationen brauchen keine eigene Tabelle, N:M immer. Weil sich das nicht anders als 1:N - M:1 modellieren lässt. Mit den Attributen hat das wenig zu tun.
Manchmal ist es günstig eine 1:1 - 1:N Relation zu verwenden. (Also für eine 1:N Relation eine eigene Tabelle zu spendieren) Dann kann man die Attribute der Relation NOT NULL setzen.
Schau mal bei den Skripten unter www.fies-und-gemein.de. Da ist auch was über Datenbankmodellierung dabei.
Gruß
Peter
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo peter
Die doku auf www.fies-und-gemein.de ist ja sehr gut. Ich arbeite nun schon seit 15 Jahren mit sql und qmf, aber diese abhängigkeiten hat mir noch keiner von unseren datenbank-leuten erklärt. Ich habe auf meinem space munter tabellen createt und auch munter mal einen drop gemacht und auch immer einen index auf meine tabellen gelegt, egal ob das feld nun ein text oder eine nummer enthalten hat.
Mein grösstes query war mal etwa 8’000 zeilen lang (nachrichten-loses-vermögen), und hat ca. 14 stunden gebraucht, bis es durch war. Mit deinen info’s, sage ich nun mal, hätte das query nur 2 stunden gebraucht. Ich brauchte damals eine proc und musste mehrmals eine tabelle erstellen, weiterlesen, wieder eine tabelle erstellen, und bei den alten tabellen ein drop table machen.
Also danke,
Gruss and
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
ERM & Normalisierung
Hallo Peter
Vielen, vielen Dank für Deine plausible Erklärung. Darf ich Dein Wissen nochmals anzapfen? Wenn man ein ERm gemacht hat und das dann in eine relationale Datenbank überführt, beginnt man dann mit der Normalisierung? Oder braucht es gar keine Normalisierung, wenn man ein ERM anwendet?
Nochmals vielen Dank und einen schönen Abend
Carla
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo an dieser Stelle.
Wenn man ein ERm gemacht hat
und das dann in eine relationale Datenbank überführt, :beginnt man dann mit der Normalisierung?
Normalerweise sollte man eine DB erst auf Papier (oder auf dem Computer) modellieren und normalisieren. Und dann erst implementieren
Oder braucht es gar keine
Normalisierung, wenn man ein ERM anwendet?
Wenn man sich die Skripte der verlinkten Seite so betrachtet, braucht man beides. Wenn das ERM sauber ist, klappt es auch mit der Normalisierung (bzw. diese gehen Hand in Hand)
HTH
mfg M.L.
Hallo Carla,
am Besten hat man die Normalisierung bereits frühzeitig gemacht. Beim Eintippen in die DB ist das sicherlich zu spät.
Ich mache immer zuerst ein klassisches ER-Modell. So richtig mit Kästchen und Rauten aber noch ohne typen. Das ist meist schon gut normalisiert. Dann mache ich daraus ein Tabellenschema. Viele bezeichnen das Tabellenschema auch als ER-Diagramm. Die meisten Programme liefern dieses. Jetzt muss man sich festlegen, welche 1:N Relationen man als eigene Tabelle führen möchte. Dann kommen die Typen dazu und die Not Null Constraints.
Als Informatiker darf man einfallslos sein. DATE, VARCHAR(30, 60, 90, 120, 255, 512), INTEGER, DECIMAL(16,6) reichen völlig aus. Genauso wie bei den Kardinalitäten 1, 0,1, *, 1…* ausreichen. Warum: daqmit man später leichter ändern kann und damit die Felder passen.
Hier kann man auch die Normalisierung prüfen. Meist sind so entworfene Modelle bereits in der 3. NF. Manchmal schleichen sich 3NF-Verletzungen ein, wenn man eine Tabelle erweitert. Z.B. du hast eine Tabelle Artikel und darunter eine schwache Entity mit Textzeilen. Also eine ganz normale 1:N Relation. Bis hierhin alles okay. Jetzt erweitern wir die Tabelle um eine Textart. Und haben die 2NF verletzt. Warum: Textart ist nur von einem Teilschlüssel abhängig.
Der letzte Schritt ist dann das SQL-Skript erstellen. Aber das ist dann eher mechanisch.
Eine gute mathematische Erklärung für die Normalisierungsregeln findest du übrigens im Lehrbuch von Kemper/Eickler.
Du kannst mir aber ruhig ein Modell schicken und ich zeige Dir, was ich anders gemacht hätte. Wenn ich etwas anders gemacht hätte.
Gruß
Peter
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]