Normalisierung

[OnDemand]

Hallo zusammen,

ich bin grad an dabei Normalisierung zu verstehen.

Meine Tabelle ist nun in der 1NF und ich will sie in die zweite überführen. Aber irgendwie hängt da alles von allem ab, ich kann keinen Anfang finden.


Frage 1:
Kann mir jemand sagen, wie ich am besten herausfinde, ob eine Abhängigkeit besteht? Desto länger ich mir das ansehe, desto verwirrter werde ich und alles hängt von allem ab

Frage 2:
Primärkeys bekomme ich raus indem ich mich frage, ob ich durch diesen einen (oder mehrerern) Key auf genau einen Datensatz gelange, richtig?

Zumal ich es nicht hin bekomme die Wiederholungen zu entfernen, dass macht die Sache schwerer

Ich hoffe auf positive Unterstützung, hab mir schon sämtliche Definitionen angesehen, aber die waren alle so "nicht in eigenen Worten"

 

[Thallius]

Fang doch einfach mal an und sag uns wie weit du gekommen bist.

Macht ja keinen Sinn wenn wir Dir das Ergebnis jetzt hier hinschreiben

Gruß

Claus

 

[OnDemand]

Huhu hast Recht, also erstmal hab ich Bestellnummer und Artikelnummer als Primarykey festgelegt. Da ich mit diesen beiden Keys einen Datensatz 100% finden kann.

So dann hab ich alle Attribute, die von einem Teilkey abhängen in eine separate Relation gebracht sieh Anhang.

Nun gehts schon los, wie mach ich jetzt weiter? Ich finde kein Attribute mehr, dass nur von einem Teilkey abhängt. Zb Anzahl bestellter Artikel, ist das nun von der Bestellung abhängig oder vom Artikelcode oder von beidem ?!

 

[Thallius]

Das sieht doch schon mal ganz gut aus.

Was dir jetzt noch fehlt ist eine Tabelle Bestellung die dann auf die Artikel und Lieferanten referenziert.

Manchmal so wie du denkst das die aussehen sollte.

Gruss

Claus

 

[OnDemand]

Hi, so nun hab ich in meiner Tabelle immer noch Wiederholungsfolgen drin Aber wie soll man das machen ohne Wiederholungen?

In der Aufgabe steht auch als Hinweis, dass am Ende 4 Relationen rauskommen

 

[Thallius]

Du darfst natürlich in deinen Artikel und liefrantentabellen keine doppelten Einträge haben. Brauchst du ja auch nicht. Wozu?

Der Auftragswert und die Summe haben in der Tabelle nichts verloren. Die errechnen sich aus der Anzahl der Artikel und dem Artikelpreis und müssen somit nicht extra gespeichert werden. Das wäre redundant.
Die Bestellnummer sollte zwingend unique sein. Es darf keine zwei Bestellungen mit der gleichen Nummer geben.

Graus

Claus

 

[OnDemand]

Ach die Gesamtsummen werden nicht gespeichert??? Das ist ja interessant, hätte ich nicht gedacht! Die doppelten Einträge kommen daher, weil in einer Bestellung mehrere Artikel sein können, diese eine Bestellung (mit mehreren Artikeln) geht an genau einen Lieferanten.

Edit: Bei Liefernat hab ichs nur vergessen, da ist es mir klar,dass ich es nur 1 Mal brauche

 

[Thallius]

Wenn eine Bestellung mehrere Artikel haben kann, dann brauchst Du eine Cross-Referenz-Tabelle

Die sieht dann etwa so aus:

BestellteArtikel

ID (int, autoincrement)
Bestellnummer
Artikelnummer

Dann trägst du für jeden Artikel einer Bestellung in diese Tabelle einen Eintrag ein.

Gruß

Claus

 

[OnDemand]

Das versteh ich nicht Jede Bestellung kann verschiedene Artikel beinhalten, wie kann da eine ID helfen?

 

[Thallius]

Die ID ist nicht unbedingt nötig. Es geht auch ohne. Ich habe aber auch schon erlebt, dass sich Datenbanken später so entwickelt haben dass es schlau war eine ID hinzuzufügen und die braucht nicht viel Platz und macht einen Datensatz immer einwandfrei identifizierbar. Ich habe in allen meinen Tabellen eine ID drin. Also bei mir wäre auch eine in den Artikeln, Lieferanten und Bestellungen. Aber für Deine Aufgabenstellung ist diese nicht zwingend notwendig.

Die mehreren Artikel ergeben sich aus der Bestellnummer. Eine Bestellung mit der Bestellnummer 1000 und den Artikeln 100,101 und 102 würde dann drei Einträge in der Cross-Referenz-Tabelle erfordern.

1000 , 100
1000 , 101
1000 , 102

Gruß

Claus

 

[OnDemand]

Hio, ok, das macht Sinn.

Könnte ich auch meine Bestellnummer als ID nehmn, siehe Anhang?

 

[Thallius]

Sicher kannst du das. Du must dann halt nur selber sicherstellen, dass diese unique ist. Das kannst du z.B. machen indem Du einen primary key darauf legst. Wenn du einen Spalte mit einer id (int, autoincrement) in eine Tabelle machst, kannst du halt sicher sein, dass die Werte darin fortlaufend und unique sind. Das nimmt Dir dann die Arbeit ab den Wert selber zu bestimmen. Die Spalte muss natuerlich auch nicht ID heissen. Die kannst du nennen wie du willst.

Gruß

Claus

 

[OnDemand]

So nun hab ich meine Tabellen hoffe ich fertig und auch ein ER Diagramm dazu erstellt.

An den Beziehungen muss ich noch was machen.

Meinst ihr die Tabelle "Anzahl" ist dort richtig abgeleitet oder sollte sie lieber von "Bestellung" abgeleitet werden?

 

[Thallius]

Also die Tabelle ist so gut. Würde ich genauso machen.

Mit den Diagrammen kenne ich mich nicht aus aber rein gefühlt würde ich die Bestellung quasi als Kopf oben drüber nehmen und dann von dem Lieferantencode der Bestellung eine Beziehung zum Lieferanten machen und von der Bestellnummer eine Beziehung zu der Menge und dort von dem Artikelcode eine Beziehung zum Artikel.

Ich hoffe es ist klar was ich meine? Aber wie gesagt. Ich weiß nicht wie die Anforderungen da jetzt genau sind. Kann auch sein das ich da komplett verkehrt liege.

Gruß

Claus

P.S. Achja un der Lieferantencode muss natürlich auch ein primär Schlüssel sein. Hast du bestimmt nur vergessen.

 

[OnDemand]

Ja ich weiß was du meinst, dank Dir! Vielleicht hat ja noch jemand eine Meinung

 

[stg]

Die Tabellen sehen gut aus, ja. Man könnte gegebenenfalls noch zwischen Bestellung und Lieferung unterscheiden, um später auch Teillieferungen berücksichtigen zu können oder Teilbestellungen zu einer Gesamtbestellung zusammenfassen oder dergleichen, aber das muss hier (im Rahmen der gestellten Aufgabe) mMn nicht gemacht werden.

Mit deinem ER-Diagramm bin ich so aber nicht einverstanden. Einträge der Tabelle "Menge" können nicht ohne entsprechende Einträge aus den Tabellen "Artikel" und "Bestellung" existieren. Die Beziehung "beinhaltet", die du hier aufführst enspricht tatsächlich schon der Tabelle "Menge" und die Beziehung bekommt direkt das (einzige) Attribut "Menge".
Unabhängig davon stimmen in deinem Diagramm die Kardinalitäten nicht.

 

[stg]

Ich kann meinen Beitrag leider nicht mehr ändern. Die Beziehung bekommt natürlich das Attribut "Anzahl" und nicht "Menge". Das ist natürlich nur ein sprachlicher Unterschied, aber so deckt es sich dann mit deinem Datenbankmodell.

 

[OnDemand]

Hallo stg, lieben Dank für deine Anmerkung, die Beziehungen schaue ich mir nochmal an

 

[OnDemand]

Soo nun hab ich es nochmal überarbeitet, Bestellung nach oben. Nun liest es sich quasi:

Eine Bestellung beinhaltet eine Anzahlvon Artikeln

Zu den Kardinalitäten:
Mehrere Bstellungen (m) können mehrere Artikel beinhalten(n) müssen aber mindestens 1 oder mehr (1:m) Anzahlen haben. Und ein Lieferant liefert mindestens 1 oder auch mehr Artikel aus (1:m).

Oder soll der Lieferant doch oben über die Bestellung?! Man kann es echt drehen und wenden....nur wie ist es korrekt

Viele Grüße!

PS Nun auch noch ein hierarchisches Baumdiagramm (Die Namen der Tabellen muss ich überall noch anpassen, hab irgendwie immer andere Namen genutzt). Das Baumdiagramm soll aus allen gegebenen Attributen bestehen. Muss da auch schon der "Aufbau" der Tabellen beachtet werden, aber die Hierarchie hat ja nix mit den Tabellen zu tun sondern zeigt nur wie die Attribute miteinander verwandt sind oder :bahnhof:?

 

[stg]

Generell gibt es meist einige gleichwertige oder sich nur geringfügig unterscheidende Modelle... dein erster Versuch war aber gar nicht schlecht und ich hatte da doch nur eine Kleinigkeit angemerkt. Das war kein Grund gleich alles über den Haufen zu schmeißen

Vergleich doch mal das hier mit deinem ersten Entwurf und lies parallel dazu noch einmal meine vorherige Antwort.

Ein wenig flexibler bist du, wenn du den Lieferantencode noch aus der Bestellung herausnimmst, das meinte ich mit der anderen Anmerkung aus meiner vorherigen Antwort. Das könnte dann zum Beispiel so aussehen. Allerdings passt das nicht mehr exakt auf dein Datenbankmodell

Die Kardinalitäten hab ich mal zunächst ganz weggelassen. Da nur noch eine kleine generelle Anmerkung. Mir ist aufgefallen, dass du verschiedene Notationsformen bunt mischst. Das ist verständlich, wenn du gerade erst mit der Modellierung anfängst, da es doch eine ganze Menge verschiedener Notationsformen gibt und das zu Beginn sicherlich auch verwirrend ist. Dabei einfach in deinem eigenen Interesse ein wenig konzentrierter und sorgfältiger überlegen, welche Notationsform man verwenden will und wie (u.A.) dann die Kardinalitätszahlen auszuschauen haben.

 

[OnDemand]

Hmm mit dem Liferdatum weis ich nicht, was gemeint ist entweder das tatsächliche Lieferdatum oder ob das Lieferdatum bei der Bestellung vorgegeben wird. Das wäre wichtig zu wissen denke ich

 

[stg]

...das ist auch ein wenig Haarspalterei und sicher nicht im Sinne der Aufgabenstellung. Genrell ist die Überlegung aber natürlich sinnvoll und so etwas muss man dann mit dem Kunden genau besprechen

Interessant ist in erster Linie wirklich nur der Unterschied zwischen deinem Entwurf und der von mir vorgeschlagenen Ändeurng. Ist dieser dir denn klar?

 

[OnDemand]

@stg
deine Änderung kann ich nicht nachvollziehen, du machst dort eine Entität zu einem Attribut?!

Was sagt ihr zu meinem Baumhierachie-Dingens?

Sind die Strukturen dort abhängig vom Tabellenaufbau? http://www.java-forum.org/attachmen...erung/6377d1405443003-normalisierung-baum.jpg

 

[OnDemand]

Nun hab ich nochmal nachgedacht...irgendwie finde ich muss der Lieferant doch als erstes stehen^^

Nun noch ne Frage: Bei den Beziehungen, wann nimmt man "m" und wann "n" für einen Entitätstypen oder ist das Wurst?

 

[Thallius]

Es gibt

1:1
1:n
n:1
n:m

Beziehungen. Bei der letzen braucht man halt einfach einen weiteren Buchstaben

Gruß

Claus

 

[OnDemand]

Achsooo

Hab meine Kardinalitäten nochmal angeschaut, passen die soweit, was sagst du dazu?
Was sagst zu meinem Baum

Dieses ganze gezeichne nervt

 

[stg]

Die Kardinalitäten sind immer noch falsch. Bestellung zu Artikel ist eine n:m-Relation. Diese Relation wird näher beschreiben durch die Entität "Anzahl" oder "Menge", wie du es vorher genannt hast. Und zwar für jeden Artikel in jeder Bestellung genau einmal.

Ich würde nach wie vor das Attribut "Anzahl" (nicht die Entitität) direkt an die Beziehung "besteht" aus hängen.

 

[OnDemand]

Hallo stg,

warum ist das eine n:m? hmm..wenn ich näher drüber nachdenke: es können mehrere Artikel in mehrerern Bestellungen von EINEM Lieferanten erfolgen, richtig?

Dann wäre

Lieferant und Bestellung 1:n
Bestellung zu Artikel n:m oder m:n (ist das egal wie rum?)

Bezgl. der "Anzahl": Darf man das Attribut einfach so aus der Entität nehmen? Was passiert dann mit den anderen Attributen der Enitität "Anzahl" bleiben die einfach weg?

Danke Dir

 

[stg]

Wovon ich die ganze Zeit rede, ist die Tatsache, dass deine Tabelle "Anzahl" keiner vollwertigen Entität, sondern einer Beziehung entspricht. Das Attribut "Anzahl" beschreibt die Beziehung zwischen Bestellung und Artikel. Es kann keine "Anzahl von Artikeln in einer Bestellung" geben, wenn es Bestellung oder Artikel nicht gibt.
(an den sprachlichen Schwierigkeiten bist du aufgrund deiner Umbenennung von "Menge" in "Anzahl" nun selbst Schuld )

Ich hab mal im Netz geschaut und das hier gefunden:
http://www2.cs.uni-paderborn.de/cs/ag-klbue/de/courses/ws09/model/folien/kb-er.pdf
Schau dir mal die Folien 2-9 an

Fremdschlüssel gehören mMn übrigens eigentlich auch gar nicht in ein ER-Diagramm, denn damit legst du dich direkt schon auf eine Umsetzung auf relationalen Datenbanken fest. ER-Diagramme sollten aber allgemein-gültig bleiben.

Wie rum du das n und das m bei den Kardinalitäten setzt, ist egal. Die unterschiedlichen Buchstaben sollen nur kenntlich machen, dass nicht auf beiden Seiten exakt gleich viele Instanzen vorhanden sein müssen. So kannst du z.B. eine Bestellung über drei Artikel haben, aber andere Artikel werden wiederrum gar nicht bestellt.

 

[OnDemand]

Hallo nochmal,

muss nochmal zum Thema Normalisierung kommen. Ich habe jetzt noch einmal die 3 Stufen durchehen wollen um es einfach zu verstehen.

Als Anlage sind meine 1NF und 2NF, 3NF die stimmen soweit richtig? Aber wie wird aus der 2NF dort die 3NF? Es liegt doch gar keine transitive Abhängigkeit vor, ist das der Grund, dass die Tabelle 2NF automatisch in der 3NF ist, weil keine transitive Abhängig (mehr) vorhanden ist? Im Bild 3NF ist oben die Ausgangstabelle, also "der übrige Rest" nach Bildung der 2NF. Ist diese "Reste-Tabelle" nun die noch nötige (abhängigkeitsfreie) Relation?

Ich hoffe irgendwer kann nachvollziehen, was ich hier von mir gebe :bloed:

 

[ceving]

In deinem Bild sind vier Entitäten:

1.) Lieferant: Besteht aus Lieferanten-Code und Lieferanten-Name.

2.) Bestellung: Besteht aus Bestellnummer, Bestelldatum, Verweis auf Lieferant, Gesamtbetrag und ein eine Liste von Bestellpositionen.

3.) Bestellposition: Besteht aus Verweis auf Artikel, Anzahl, Gesamtpreis.

4.) Artikel: Besteht aus Artikel-Code, Artikelbezeichnung und Einzelpreis

Bestellpositionen sind das Paradebeispiel für Primary-Forein-Keys.

Der Lieferant hat einen einfachen Primärschlüssel (Lieferanten-Code), die Bestellung hat auch einen einfachen Primärschlüssel (Bestellnummer) und die Artikel haben auch einen einfachen Primärschlüssel (Artikel-Code). Aber eine Bestellposition kann nicht ohne eine Bestellung existieren. Deswegen hat sie einen kombinierten Primärschlüssel bestehend aus dem Primärschlüssel der Bestellung und der Positionsnummer relativ zur Bestellung. Es reicht bei einer Bestellposition nicht aus, nur von Bestellposition 3 zu sprechen. Damit ist nicht klar, welche Bestellposition gemeint ist, weil es die Bestellposition 3 sowohl auf Bestellung ABC wie auf Bestellung XYZ geben kann. Um eine Bestellposition zu referenzieren man muss man immer sagen Bestellposition 3 auf Bestellung XYZ.

Eine Bestellung beinhaltet zwar eine Liste von Bestellpositionen aber man speichert dazu nicht in der Bestellung den Verweis sondern man dreht die Verweisrichtung um. Die Bestellposition verweist auf die Bestellung. Die Tabellen sehen also so aus:

lieferant: code*, name
bestellung: nummer*, datum, lieferant_code, gesamtbetrag
bestellposition: bestellung_nummer*, positionsnummer*, artikel_code, anzahl, gesamtpreis
artikel: code*, bezeichnung, einzelpreis

Mit Stern sind die Primary-Keys gekennzeichnet. Mit Unterstrich sind die Forein-Keys gekennzeichnet. Stern und Unterstrich zusammen gibt Primary-Foreign-Key.

 

[OnDemand]

Hallo Ceving,

lieben dank für deine ausführliche Antwort. In deinen Ausführungen sind jedoch Attribute (Positionsnummer) welche nicht in der Aufgabenstellung vorkommen. Es soll auch nur mit den gegebenen Attributen normalisiert werden.

Das macht die Sache schwierig

 

[ceving]

In deinen Ausführungen sind jedoch Attribute (Positionsnummer) welche nicht in der Aufgabenstellung vorkommen. Es soll auch nur mit den gegebenen Attributen normalisiert werden.

Das macht die Sache schwierig

Vielleicht ist die Aufgabenstellung Schrott. Bestellungen ohne Positionsnummern gibt es eigentlich nicht.