Kernquali 2005/06: Datenbank 3. Normalform

[RanmaSaoToMe]

Hallo leute,

ich verzweifle gerade an der folgenden Datenbankaufgabe:

http://img280.imageshack.us/img280/121/db5wa.jpg

Jemand n Vorschlag wie man diese löst?

[Mike77]

Du könntest ja mal beschreiben, warum du daran verzweifelst.

Da ist ein Beleg angegeben, der zu einem bestimmten Gerät (Gerätenummer) gehört. Folglich musst du die verschiedenen Tabellen (Gerät, Zubehör, Zähler, Kosten, Störungen) bilden und diese von der Gerätenummer abhängig machen (Primärschlüssel setzen). Beziehungen mit Kardinalitäten sind geschenkt.

[RanmaSaoToMe]

Du könntest ja mal beschreiben, warum du daran verzweifelst.

Da ist ein Beleg angegeben, der zu einem bestimmten Gerät (Gerätenummer) gehört. Folglich musst du die verschiedenen Tabellen (Gerät, Zubehör, Zähler, Kosten, Störungen) bilden und diese von der Gerätenummer abhängig machen (Primärschlüssel setzen). Beziehungen mit Kardinalitäten sind geschenkt.

oh stimmt, vergessen zu schreiben... also ich weiss nicht wie die kardinalitäten aussehen... die tabellen hab ich schon mal, nämlich beleg, gerät, zubehör, zähler, kosten und störungen....

[Patrick_erlangen]

Also hier mal ein Lösungsversuch:

1. NF

-----

Erfassungsbeleg: GeräteID, Lieferdatum, Einkaufspreis, Kundennummer,

Standort,Wartungsvertrag, Datum_letze_Wartung,

Zubehörnummer, Zählerdatum, Zählerstand

Kosten_datum, Kostenart, Kostenbetrag,

Bemerkung, Störung ID, Störung_Datum, Störung_Art

_______________________________________________________________

Erste NF besagt, jedes Feld muss atomar sein - keine berechenbaren Felder

_______________________________________________________________

2. NF

-----

Gerät: GeräteID, Lieferdatum, Einkaufspreis, Kundennummer,

Standort,Wartungsvertrag, Datum_letze_Wartung,

Zubehör: GeräteID,Zubehörnummer

Zähler: GeräteID, Zählerdatum, Zählerstand

Kosten: GeräteID, Kosten_datum, Kostenart, Kostenbetrag,

Bemerkung

Störung GeräteID, Störung ID, Störung_Datum, Störung_Art

_______________________________________________________________

Zweite NF

Alle nicht primären Attribute (nicht Teil des Schlüssels) sind vom ganzen Schlüssel abhängig, nicht von nur einem Teil des Schlüssels.

________________________________________________________________

3. NF

Gerät: GeräteID, Lieferdatum, Einkaufspreis, Kundennummer,

Standort,Wartungsvertrag, Datum_letze_Wartung,

Zubehör: ZubehörID

Zähler: ZählerID, Zählerdatum, Zählerstand

Kosten: KostenID, Kosten_datum, Kostenart, Kostenbetrag,

Bemerkung

Störung Störung ID, Störung_Datum, Störung_Art

Zwischentabelle: GeräteID, ZubehörID, ZählerID, KostenID, Störung ID

Stimmt das alles ?

[tg_]

@ Patrick hab die Lösungen von dieser Prüfung leider nicht aber ich hätte das auch so gemacht

mag sein dass der Lösungsvorschlag anders ist (wahrscheinlich) aber trotzdem wäre das richtig und dann kommt es halt aufn Prüfer drauf an.

BTW: nen lehrer von mir hatte bei einen Lösungsvorschlag mal entdeckt dass der Falsch ist kein Kommentar....

Und bei solchen Aufgaben Datenbanken, struktogramme usw. bloß nicht zu komplioziert denken

[bndr]

@Patrik_Erlangen

Die Zwischentabelle kannst du dir hier sparen wenn du in jede Tabelle die GeräteNummer aufnimmst

@tg

Fehler in den Lösungsvorschlägen kommen häufig vor... hab auch schon ein paar entdeckt

Sind ja zum Glück nur 'Vorschläge' :mod:

[pello]

So würde meine Antwort aussehen, aufgeteilt auf 6 Tabellen. Ich habe eine zusätzlich noch eine Kundentabelle erstellt, da es u.U. auch mal vorkommen kann, das ein Kunde mehrere Geräte besitzt, oder sich die Daten des Kunden ändern, etc. . Ist einfach sauberer Kunden und Geräte zu trennen ;-) . Bei Fragen oder Verbesserungen einfach melden.

MfG Pello

Anhang:

http://img454.imageshack.us/img454/7619/dsc001193bz.jpg

[alpha-centauri]

pello, so haette ich das auch gemacht. 3. normalform ist nicht wirklich so schwer, wenn man es geblickt hat.

fremschlüssel, primärschlüssel kennzeichnen. N:m hinschreiben. paar striche rein.

und das ganze in tabellen aufteilen.

[RanmaSaoToMe]

http://img454.imageshack.us/img454/7619/dsc001193bz.jpg

verlese ich mich oder hast du wirklich mehrere primary keys in einer tabelle?

[pello]

Ja, das habe ich, nennt sich SuperKey (http://de.wikipedia.org/wiki/Prim%C3%A4rschl%C3%BCssel#Superschl.C3.BCssel)

MfG pello

[espressomann]

Also ich würde zwar auch eine Kundentabelle machen, aber die Kundennummer nur einmal als ForeignKey in der Gerätetabelle einsetzen.

Somit spart man sich die Aufnahme einer Kundennummer in fast jeder anderen Tabelle und das sogar als PK.

Da alle anderen Tabellen mit der Gerätetabelle verbunden sind, kann damit auch zu jeder Störung, jedem Zählerstand usw. auch ein Kunde zugeordnet werden.

Wenn interesse besteht kann ich meine Lösung mal einscannen...

Grüsse Espresso

[RanmaSaoToMe]

Ja, das habe ich, nennt sich SuperKey (http://de.wikipedia.org/wiki/Prim%C3%A4rschl%C3%BCssel#Superschl.C3.BCssel)

MfG pello

wenn du pech hast und einen prüfer erwischt, der nicht über viel technischem wissen besitzt, dann wird es ziemlich riskant werden... wir haben noch nie was von superkey gehört... ich machst sicherheitshalber einfach als foreign key... trotzdem thx für lösungsvorschlag!

[pello]

Viele Wege führen nach Rom und einer ist kürzer, der andere länger . Stimmt natürlich, es wäre viel sauberer wenn man die Kd_Nr als Foreign_Key setzen würde, dann gäbe es in den anderen Tabellen maximal 3 PKs. Der Managementaufwand ist in meiner Lösung auch viel höher, da die Kd_Nrn in allen Tabellen verwaltet werden wollen. Also meine Lösung ist unsauber *g*. Danke für den Hinweis, das nächste Mal (sicherlich in der Prüfung) werde ich mehr als 3 Min in das Diagramm investieren.

MfG Pello

P.S.: Super-Keys sind eigentl. Gang und Gebe und wenn sich ein Prüfer Querstellen sollte (werde meine Prüfung anfordern), gibts ne Beschwerde seitens meiner Firma. Also von daher :floet: . Du musst trotzdem einen eindeutigen Schlüssel haben, also brauchst du Zwangsläufig entweder Super-Keys, oder eine Zählvariable in der Kostentabelle, der Zaehlertabelle, der Zubehörtabelle,... . Ein Super-Key kann sich auch aus 1 PK und mehreren FKs zusammensetzen.

[boxi06]

Moinsen!

Also ich hab ne GANZ andere Lösung:

Kunden (KdNr, ...)

Geräte (GerätID, ...)

Kunde_Gerät (KdNr, GerätID, Lieferdatum, EK-Preis, Standort, Wartungsvertrag, letzte_Wartung)

Zubehör (ZID, ...)

Gerät_Zubehör (GerätID, ZID)

Kunde_Gerät_Kosten (KostenID, KdNr, GerätID, Datum, KostenartID, Betrag, Bemerkung)

Kostenarten (KostenartID, Name)

Kunde_Gerät_Störung (StörungID, KdNr, GerätID, Datum, StörungsartID )

Störungsarten (StörungsartID, Beschreibung)

Primärschlüssel sind unterstrichen und Fremdschlüssel kursiv. Über die Existenz der Tabellen "Kostenarten" und "Störungsarten" kann man streiten; ich find es sauberer, sie zu benutzen. Hätte gern Feedback zu meiner Lösung!

Gute Nacht und frohes Gelingen in der Prüfung!

[stone2601]

Ja, das habe ich, nennt sich SuperKey (http://de.wikipedia.org/wiki/Prim%C3%A4rschl%C3%BCssel#Superschl.C3.BCssel)

MfG pello

kann man auch einfach zusammengesetzter primärschlüssel sagen, oder irre ich mich? ^^

superkey hab ich auch noch nie gehört

[alpha-centauri]

wenn du pech hast und einen prüfer erwischt, der nicht über viel technischem wissen besitzt, dann wird es ziemlich riskant werden... wir haben noch nie was von superkey gehört... ich machst sicherheitshalber einfach als foreign key... trotzdem thx für lösungsvorschlag!

Also ich hab grad unseren Programmierer gefragt: Dem ist nix von Superkey bekannt.

[RanmaSaoToMe]

Also ich hab grad unseren Programmierer gefragt: Dem ist nix von Superkey bekannt.

wem sagst du das? ich schrieb ja, das die meisten dies gar net kennen.. nicht mal die datenbanklehrer an unserer berufschule haben je was davon gehört...

[DarkGhost]

@ boxi:

hätt ich auch so ähnlich gemacht; auf jeden Fall müssen n-m-Beziehungen (Zischentabellen!) zwischen Störung/Gerät und Kosten/Gerät, aber den Kunden brauchst da nicht mehr reinbringen, der ist ja schon über die 1n Beziehung mit Gerät verbunden

[boxi06]

gut, ich wollte betonen, dass die kundennummer ein fremdschlüssel ist. vollständigerweise habe ich dann eine kundentabelle angedeutet.

[pello]

Also ich weiß ja nicht, was ihr für Lehrer habt, aber Super-Key sollte eigentlich jedem etwas sagen, da dies ein anderer Begriff ist für "zusammengesetzter Prmärschlüssel". "Zusammengesetzter Prmärschlüssel" ist auch mehr die Deutsche Übersetzung als ein anderes Wort. Also Super-Key merken, oder bei der deutschen Fassung bleiben . Sollte die IHK dies dann als Fehler anstreichen, werde ich wie gesagt Widerspruch einlegen und Recht bekommen, da eine deutsche Übersetzung für einen englischen Fachbegriff <b>niemals</b> als einzig richtige Lösung gewertet werden darf. Wäre ja noch schöner, wenn wir gezwungen werden würden statt Motherboard nurnoch Hauptplatine zu schreiben oder sowas in der Art. So hoffe niemanden allzusehr verwirrt zu haben. Viel Glück und noch nen schönen Tag.

MfG Pello

[wettmasta]

@ pello. Ich verstehe was du mit deinem Superkey meinst aber das wäre dann meiner Meinung nach nicht die 3. Normalform, da du nur einen zusammengesetzen PrimaryKey z.B. in der Tabelle Zubehör hast.

Meiner Meinung nach müßte man um die 3. Normalform zu erreichen eine Extra Tabelle wie z.B. Geräte_Zubehör erzeugen was dann eine n:m beziehung zur folge hätte. Diese lösung wurde hier schon vorgeschlagen und ist wohl auch richtig....

Gruß

wettmasta

Edit: habe gerade nochmal nachgeschaut. Es muß Quasi eine dritte Tabelle (Geräte_Zubhör) usw. esrtellt werden um die 3. Normalform zu erreichen. http://de.wikipedia.org/wiki/3NF#Erste_Normalform_.281NF.29

[DarkGhost]

@boxi:

die kundennummer als fremdschlüssel würd ich in die gerätetabelle tun

[boxi06]

@wettmasta: guckst du meine lösung, erste seite.

@darkghost:

nein, eben nicht: ein gerät hat in erster linie nichts mit einem kunden zu tun. das gerät enthält nur eigenschaften, welche direkt mit dem gerät zu tun haben (--> 3. normalform), also z.b. bezeichnung, maße etc.

ein gerät (kein konkretes exemplar, sondern z.b. "hp deskjet 1234") kann durch viele kunden benutzt werden und ein kunde benutzt u.U. viele geräte, also eine n:m-beziehung.

also:

kunden (kundennummer, name, .....)

geräte (gerätenummer, weitere_eigenschaft, ....)

n:m -->

kunden_geräte (kundennummer, gerätenummer, datum, persönlicher-ek-preis, .....)

gell?

[wettmasta]

@boxi06

Dein Vorschlag war ja auch richtig, deshalb hatte ich ja auch geschrieben

"Diese lösung wurde hier schon vorgeschlagen und ist wohl auch richtig...."

Ich wollte halt nur Pello darauf hinweisen, das seine Lösung mit dem "SuperKey" so gesehen falsch ist, weil keine 3.Normalform.

[pello]

--- GEÄNDERT ---

Kommando zurück, sehe gerade meinen Fehler, in der Tabelle Kunden kommt es zu Mehrfachnennungen eines Kunden beim Besitz mehrerer Geräte (keine Redundanz durch PKs, aber keine richitge 3. Normalform). Also n:m auf Zusatzgerätetabelle, dann stimmts wieder. Danke für den Hinweis.

MfG Pello

P.S.: So werde mir jetzt noch einwenig was zu HTT (Hyper-Threading-Technologie) und SATA anschauen gehen.