Datenbank-Entwurf

[Mohamed_7e2064]

Hallo allerseits,

könnte mal jemand folgende (Übungs-)Planung einer Webshop-Datenbank überfliegen und schauen, ob die Vorgehensweise in puncto Normalisierung okay und auch ansonsten sinnvoll ist?

ERM-Diagramm: http://www.arabisch.tv/_other/sc1.JPG
Theoretische Notation: http://www.arabisch.tv/_other/sc2.JPG

Anmerkung: Da ein Artikel auch zu mehr als einer Kategorie gehören könnte, wurde für die Abbildung der Zugehörigkeit eine m:n-Beziehung gewählt - darum die Zwischentabelle „katZugehörigkeit“.

Schöne Grüße,

Mohamed.

[drambeldier]

Moin, Mohamed,

beim Überfliegen sehe ich drei 1:1-Beziehungen, die ganz sicher keine sind. Und ein Beziehungsname „berechnen“ erscheint fragwürdig, Beziehungen drücken immer ein „hat zu tun mit“ aus.

Was ist das für eine Notation - der alte Chen? Rauten malt doch schon lange niemand mehr.

Gruß Ralf

[Tomh]

Hi!

beim Überfliegen sehe ich drei 1:1-Beziehungen, die ganz
sicher keine sind. Und ein Beziehungsname „berechnen“
erscheint fragwürdig, Beziehungen drücken immer ein „hat zu
tun mit“ aus.

Dem kann ich mich nur anschließen, wobei ich noch etwas bemerken möchte:

Die Beziehungen von „Lieferung“, „Rechnung“, „Konten“ und „Wahlartikel“ (sollte doch wohl eher „Bestellung“ heißen, oder?) sind (je nach fachlichem Hintergrund) so gut wie immer n:m-Beziehungen.

Dazu würde ich zu „Lieferung“, „Rechnung“ und „Bestellung“ (mir gefällt „Wahlartikel“ nicht) noch die Entitäten „Positionen“ hinzufügen, die schlußendlich wirklich mit dem Artikel verknüft sind.

Grüße,
Tomh

PS: Und die Raute kenne ich auch nicht, obwohl ich schon seit 20 Jahrne ERDs „male“ …

[Mohamed_7e2064]

Zusatzfragen
Hallo drambeldier und Tomh,

ja, es ist der Chen-Stil. Aber ist das nicht der Standard-Stil? Die meisten Lehrbücher benutzen diesen doch. Und weder Google noch Wikipedia lassen auf etwas Anderes schließen (wenn auch Alternativen dort nicht ganz verschwiegen werden.):

http://images.google.de/images?um=1&hl=de&q=ERM&btnG…
http://de.wikipedia.org/wiki/Entity-Relationship-Modell

Auch an der Uni Duisburg-Essen wird er offenbar noch benutzt: http://www.is.informatik.uni-duisburg.de/courses/dbp…

Ich male die Rauten gerne, denn dann kann ich ihnen Attribute hinzufügen, durch die ich sehe, dass der Beziehungstyp eine Zwischentabelle z.B. für m:n-Beziehungen darstellt. Was malt ihr denn für Diagramme?

Jemand hat mal in seinem Lehrbuch verzapft, man solle als Namen für Entitätstypen immer einen Plural nehmen. Da ich das nach Durchsicht so einiger DB-Entwürfe nur halb glauben kann, hat sich das in meinem ER-Diagramm als Inkonsequenz niedergeschlagen - mal heißt es „Rechnungen“, mal „Kunde“. Momentan halte ich Singular für sinnvoller, oder liege ich da falsch?

Zum Beziehungstyp „Rechnungen -> Wahlartikel“: Ich habe „berechnen“ gewählt, da es ja das geforderte Teil-Abbild der Wirklichkeit ist. Eine Rechnung berechnet halt die Summe der Preise der gewählten Artikel. „Berechnen“ sollte also nur eine Abkürzung für „berechnet_die_Summe_der_Preise_von“ sein. Oder was hättet ihr genommen?

Und was genau habe ich mir unter einer „Rechnungsposition“ vorzustellen? Google- & Wikipedia-Suche war diesbezüglich nicht so ertragreich.

Zur Infragestellung der 1:1-Beziehungen:

Ich glaube nachvollziehen zu können, dass bei der Beziehung „Rechnung -> Konto“ ein „n“ bei „Rechnung“ stehen muss. Schließlich kann ein Konto von mehreren Rechnungen angegeben werden. Ist es richtig, dass die Richtung dann auf einmal „Konto -> Rechnung“ sein muss, so dass der Beziehungstyp „wird_angegeben_von“ statt „gibt_an“ heißt? Von n:1-Beziehungen spricht man ja nicht.

Aber könnte man die Multiplizität bei „Rechnung -> Lieferung“ nicht so lassen (1:1)? Es ist vorgesehen, dass zu jeder Rechnung nur eine einzige Lieferung gehört und jeder Lieferung nur eine einzige Rechnung beiliegt.

Auch kommt die Artikelnummer eines „Wahlartikels“ nur ein einziges Mal in der Tabelle „Lagerartikel“ vor, zumal mehrfaches Vorhandensein durch die Attribute „Wahlartikel.stueckzahl“ und „Lagerartikel.vorrat“ ausgedrückt wird. Ist das nicht doch eine 1:1-Beziehung?

Schöne Grüße,

Mohamed.

[drambeldier]

Hi Mohamed,

von Hand kann jeder malen, wie er mag, die heutigen Entwicklungsumgebungen zeichnen maschinell. Da gibt es für 1:n-Beziehungen nur noch die Linie mit einer Beschriftung (manchmal 2), n:m-Beziehungen werden sofort in eine Entität umgesetzt.

Entitätsnamen stehen immer im Singular, das erleichtert das Denken in Entitäts typen und deren Beschreibung.

Beziehungsnamen sollten keine Funktion beschreiben, sondern die Art, wie 2 Entitäten miteinander zu tun haben. Manchmal ist das läppisch wie bei Rechnung > Posten, da können aber durchaus fachliche Inhalte stehen wie Mitarbeiter > Mitarbeiter. Die Krux kommt bei aufgelösten m:n-Beziehungen, da wird’s wirklich trivial, deshalb ist dann der Entitätsname um so wichtiger.

Eine Rechnungsposition enthält einen Posten mit Preis und Menge. Jede Rechnung besteht aus beliebig vielen Positionen, dazu gehören nicht nur Artikel, sondern auch zB Versandkosten.

Von n:1-Beziehungen spricht man ja nicht.

Jein. Auf eine Beziehung kann ich aus zwei Richtungen schauen; zum Beschreiben geht man besser von der n-Seite aus, weil in der anderen Richtung meist nur ein „hat“ herauskommt.

Es ist vorgesehen, dass zu
jeder Rechnung nur eine einzige Lieferung gehört und jeder
Lieferung nur eine einzige Rechnung beiliegt.

So ist es heute, morgen überlegt es sich der Auftraggeber anders, glaub mir.

Auch kommt die Artikelnummer eines „Wahlartikels“ nur ein
einziges Mal in der Tabelle „Lagerartikel“ vor

Schon beim Begriff „Wahlartikel“ stellen sich mir die Federn auf. Ist das eine Bestellung? Dann kann doch ein Artikel auf beliebig vielen Bestellungen auftauchen.

Gruß Ralf

[Mohamed_7e2064]

Beidseitigkeit
Hallo Drambeldier,

du schriebst:

Entitätsnamen stehen immer im Singular, das
erleichtert das Denken in Entitäts typen und
deren Beschreibung.

Okay, danke, da halte ich mich erstmal dran.

Eine Rechnungsposition enthält einen Posten mit Preis und
Menge. Jede Rechnung besteht aus beliebig vielen Positionen,
dazu gehören nicht nur Artikel, sondern auch zB Versandkosten.

Ach sooo .

Es ist vorgesehen, dass zu
jeder Rechnung nur eine einzige Lieferung gehört und jeder
Lieferung nur eine einzige Rechnung beiliegt.

So ist es heute, morgen überlegt es sich der Auftraggeber
anders, glaub mir.

Gut, ich lese daraus, dass eine zuverlässige Glaskugel vorausgesetzt die 1:1-Beziehung zumindest theoretisch richtig ist. Aber Du hast Recht, ein Kunde könnte wünschen, die gekauften Artikel auf verschiedene Zieladressen zu verteilen. Realistisch wäre also mindestens eine 1:n-Beziehung.

Auch kommt die Artikelnummer eines „Wahlartikels“ nur ein
einziges Mal in der Tabelle „Lagerartikel“ vor

Schon beim Begriff „Wahlartikel“ stellen sich mir die Federn
auf. Ist das eine Bestellung? Dann kann doch ein Artikel auf
beliebig vielen Bestellungen auftauchen.

Die Bezeichnung „Wahlartikel“ ist nicht die Granate, ich weiß. Ich meine damit einfach die vom Käufer gewählten, sprich gekauften Artikel. Aber klar, jetzt fällt’s mir wie Schuppen vor den Augen, dieselbe Artikelnummer kann in „Wahlartikel“ mehrfach auftauchen. Man muss eine Beziehung eben immer von beiden Seiten beleuchten.

Das wiederum heißt, dass „artikelNr“ in „Wahlartikel“ kein Primärschlüssel sein darf, das ist schon einmal ein Fehler in der Theoretischen Notation.

Da Du und Tomh zur Normalisierung nichts gesagt habt, hoffe ich, dass dies bedeutet, dass sie einigermaßen gelungen ist.

Herzlichen Dank,

Mohamed.

[Tomh]

Hi!

Gut, ich lese daraus, dass eine zuverlässige Glaskugel
vorausgesetzt die 1:1-Beziehung zumindest theoretisch richtig
ist. Aber Du hast Recht, ein Kunde könnte wünschen, die
gekauften Artikel auf verschiedene Zieladressen zu verteilen.
Realistisch wäre also mindestens eine 1:n-Beziehung.

Oder mehrere Rechnungen zu einer Lieferung auf eine Adresse, aber, je nach Artikel, auf veschiedene Konten …
Wie es IST und wie es sein SOLL ändert sich dann oft schon nach ein paar Tagen (manchmal ein paar Jahre) in ein „so KÖNNTE es auch sein“.

Ich meine damit einfach die vom Käufer gewählten, sprich
gekauften Artikel.

Bestellposition?

Da Du und Tomh zur Normalisierung nichts gesagt habt, hoffe
ich, dass dies bedeutet, dass sie einigermaßen gelungen ist.

„Einigermaßen“ ist das richtige Wort, wobei das Wort „Normalisierung“ in der Entwicklung bzw. in „Echt“ dann zum „Unwort“ wird - eine Redundanz kann schon mal die Entwickluns- und Wartungskosten ziemlich nach unten drücken … unbedacht aber auch ganz schnell nach oben …

Grüße,
Tomh