#2 20. Februar 2014 AW: 3. Normalform Datenbank Hallo! Du könntest auch eure Schritte beschreiben. Das würde es einfacher machen eure Lösung zu korrigieren. 1NF: Elementare Wertebereiche Nicht erfüllt für: Mietzeitraum, Mietvertrag abgeschlossen bei, Zuständige Werkstatt In eurer Lösung gibt es aber noch einen Mietzeitraum. Den solltet ihr zu Mietanfang (DATE) und Mietende (DATE) auflösen. 2NF: Funktionale Abhängigkeit der Nicht-Schlüsselattribute von Schlüsselattributen Mögliche Schlüssel: KundenNummer, MaschinenNummer, ... welche habt ihr identifiziert? 3NF: Keine transitiven Schlüsselabhängigkeiten Hängt von 2NF ab. Z.B. Typ der Maschine/Maschinenart könnte transitiv von MaschinenNummer abhängen. Prinzipiell müsst ihr nur danach Ausschau halten, wo Redundanzen vorkommen, also ein Fakt mehrmals da steht. Das liefert meistens gute Hinweise bezüglich der Normalisierung. Bezüglich ER-Schema und euren Tabellen in 3NF: Euch ist klar, dass jede Tabelle mit einem Entity aus dem ER-Schema korrespondieren sollte. Ihr habt 6 Tabellen, aber nur 4 Entities. Wenn ich die Pfeile mit Doppelspitze als n:m interpretiere, dann müsstet ihr aus dem ER-Diagramm 5 Tabellen ableiten können. Hier stimmt also etwas nicht. Sobald ihr übrigens die 3NF aufgestellt habt ist die Überführung in ein ER-Schema relativ einfach. Jede Tabelle, die einen Primärschlüssel besitzt, der kein Fremdschlüssel ist, ist ein Entity. Jede Tabelle, deren Primärschlüssel ein zusammengesetzter Schlüssel aus Fremdschlüssel anderer Tabellen ist, ist ein R-Typ, d.h. hier liegt eine n:m-Kardinalität vor. Eure Notation zur ER-Modellierung ist mir außerdem unbekannt. Vielleicht hilft euch UMLet bei der Modellierung. Mfg, Kolazomai + Multi-Zitat Zitieren
#3 20. Februar 2014 AW: 3. Normalform Datenbank Meine Vorlesung zu Datenbanken ist schon ein bisschen her aber ich versuchs mal. Die dritte Normalform ist erreicht, wenn sich das Relationenschema in 2NF befindet, und kein Nichtschlüsselattribut von einem anderen Nichtschlüsselattribut funktional abhängig ist. Die 2. NF ist aber noch nicht erreicht, da Informationen redundant sind. Zum Beispiel die Spalte "Typ der Maschine" in der Tabelle "Maschine" und "Maschinentyp" in "Typpreis". Dafür muss eine eigene Tabelle angelegt werden, z.B. "Maschinentyp" mit den Spalten "id" und "Bezeichnung". Die referenzierst du dann in den anderen Tabellen (foreign keys). In der Tabelle Vertrag hast du die Spalte "Mietvertrag geschlossen bei" und Ansprechpartner. Der Ansprechpartner ist abhängig von der Niederlassung. Also eine Tabelle "Ansprechpartner" und eine Tabelle "Niederlassung" anlegen. Niederlassung hat nur id und Standort, Ansprechpartner hat id, Name und Niederlassungs_id. Dann reicht es wenn du in "Vertrag" nur die id des Ansprechpartners referenzierst, die Infos über die Niederlassung hängt ja dann am Ansprechpartner. So kannst du versuchen alle Tabellen zu zerlegen. // zu langsam + Multi-Zitat Zitieren
#4 20. Februar 2014 Zuletzt von einem Moderator bearbeitet: 14. April 2017 AW: 3. Normalform Datenbank Hey, erstmal vielen Dank das Ihr drüber geguckt habt^^. Ich hab jetzt versucht mal alle eure Vorschläge umzusetzen und denk eigentlich das mir das gelungen ist nur leider liegt mir das ER-Modell so gar nicht und die Normalform erst recht nicht ^^ (bin eigentlich für die Umsetzung in Access verantwortlich in der Gruppe). Ich hab das ganze jetzt mal mit DIA umgesetzt welches mir an anderer Stelle empfohlen wurde zwecks Übersichtlichkeit und der schlechten Lesbarkeit der Bilder(sorry dafür). ER-Modell (mit dia):https://www0.xup.in/exec/ximg.php?fid=64800137 + Multi-Zitat Zitieren
#5 20. Februar 2014 Zuletzt von einem Moderator bearbeitet: 14. April 2017 AW: 3. Normalform Datenbank Hallo! Das hast du tatsächlich nicht so gut verstanden. Ich hab mal versucht aus deinem ER abzuleiten, wie eine Lösung aussehen könnte. Ich muss dazu sagen, dass ich mir den Angabentext nicht sehr aufmerksam durchgelesen habe und deshalb bestimmte Annahmen getroffen habe, die gegebenfalls nicht stimmen könnten. Kundentyp: KundentypID (PK), Beschreibung, Rabatt Maschinentyp: MaschinentypID (PK), Beschreibung Hersteller: HerstellerID (PK), Name, WerkstattOrt Niederlassung: NiederlassungID (PK), Name Kunde: KundeID (PK), KundentypID (FK), (Kundennummer,) Name, Wohnort Maschine: MaschineID (PK), MaschinentypID (FK), HerstellerID (FK), (Maschinennummer,) PreisProKM, PreisProTag, KFZ-Kennzeichen, Inspektion, Kaufdatum, Kilometer, Einsatzbereitschaft Mitarbeiter: MitarbeiterID (PK), NiederlassungID (FK), Name Vertrag: VetragID (PK), KundeID (FK), MaschineID (FK), MitarbeiterID (FK), (Vetragsnummer,) Mietanfang, Mietende, Nachweis, PreisProKM, PreisProTag Die *nummer-Attribute können gegebenfalls die ID ersetzen, wenn sie denn eindeutig sind. Es macht aber auch nichts, wenn sie als Attribut vorkommen und ihnen ein UNIQUE-Constraint gegeben wird. Der Preis ist sowohl einem Vertrag als auch einer Maschine zugeordnet, weil sonst bei einer Preisänderung für eine Maschine alle Verträge rückwirkend ihren Preis ändern würden, das macht keinen Sinn. Wenn noch Attribute irgendwo fehlen, können die natürlich ergänzt werden. Die R-Typen (auf die Spitze gestellte Rechtecke) habe ich nicht benannt, weil sie im DBVS nicht als Tabellen explizit angelegt werden müssen. Die einfachste Form sie zu benennen wäre "<von>_<zu>", z.B. "Kunde_Vertrag". Um ehrlich zu sein solltest du dir die Datenmodellierung und die Normalisierung aneignen. Das ist nichts, was man dann nur in der Schule braucht... // EDIT: Noch kurz zu deinen Fehlern beim Modellieren: Du hast Zyklen drin, das fällt dir spätestens bei der Umsetzung in ein DBVS auf die Füße. Die Kardinalitäten sind oft falsch modelliert (n:m wo es 1:n sein sollte). Du kannst dir immer leise aufsagen: "Ein Vertrag bezieht sich auf X bis Y Kunde(n). Ein Kunde hat A bis B Verträge." Damit findest du die Kardinalitäten recht leicht raus (wenn min,max-Kardinalitäten, funktioniert aber auch gut für n:m-Kardinalitäten). Dein Schema ist außerdem viel zu komplex. Echte R-Typen mit n:m sind nämlich relativ selten, meistens ist es 1:n. Mfg, Kolazomai + Multi-Zitat Zitieren