Hilfe zu Aufgabe ERM/Normalisierung

Wenn ich Zeit hab, mach ich das heut nacht vielleicht eben. Hast Du Visio? Wenn nein, stell ich die Tabellen eben in Excel ein.
Grüße,
Con

Tsts, ganz ohne Visio ein ERM erstellen Sowas ist ja beinahe gegen die göttliche (Microsoft)-Ordnung. Vorschlag: Wenn Du mehr im Bereich DB arbeitest, besorge dir die Studentenversion. Wenn Du irgendwas mit Informationstechnik studierst, bekommst Du meist von der MS Academic Alliance eine kostenfreie Version

Vielleicht kann nachher (morgen) jemand meine Ergebnisse qualitätssichern. Aus bisheriger Erfahrung, würde ich Dich Markus dafür bevorzugen, wenn Du die Zeit erübrigen kannst
So dann will ich mal nach einem kleinen Weizenfest mich der Aufgabe annehmen. Vielleicht kommt ja etwas sinnvolles heraus
Grüße,
Con

Edit 1: (02:04 Uhr) ERM
(Vorsicht: Kein Relationales ERM!)
Entity Relationship Model als generell einsetzbares Modellierungswerkzeug für Relationale Datenbanken

Fazit: Gähn, ich mach morgen weiter.
bis denne
Edit 2: (02:14 Uhr) Fein-ERM

Also nach grober Durchsicht passt mir die Darstellung auch, puh, Normalform, das ist schon länger her, das kann ich nicht mehr wirklich. Schon eigene Ansätze?

Gruß
Markus

Hallo!

Leider etwas spät (ich habe mich erst heute registriert), aber hier mein Vorschlag der Normalisierung:

Tabelle Ausleiher:

.) ID (Primary Key)
.) Name
.) Matrikelnummer

Tabelle Verlag:

.) ID (Primary Key)
.) Name
.) Ort

Tabelle Autor:

.) ID (Primary Key)
.) Name
.) ... (eventuelle weitere Daten)

Tabelle Buch:

.) ID (Primary Key)
.) Buchnummer
.) AutorID (--> FK zu Tabelle Autor)
.) VerlagID (--> FK zu Tabelle Verlag)
.) AbteilungID (--> FK zu Tabelle Abteilung)
.) Erscheinungsjahr
.) ... (eventuelle weitere Daten)

Tabelle Abteilung:

.) ID (Primary Key)
.) Name
.) ... (eventuelle weitere Daten)

Tabelle Ausleihungen:

.) AusleiherID (--> FK zu Tabelle Ausleiher)
.) BuchID (--> FK zu Tabelle Ausleiher)
.) ... (eventuelle weitere Daten)

Ich weiß, man könnte hier einige "Änderungen" vornehmen (z.B. die Matrikelnummer, die ja an sich eindeutig sein müsste, als Primary Key verwenden --> würde ein Feld ersparen (somit Speicherplatz etc.)), aber ich muss sagen in meinen Praxisprojekten habe ich einfach "gelernt", jedem Datensatz eine eigene ID zu geben. Fällt dann bei komplexeren Aufgaben (die evtl. nicht eingeplant waren) einfacher, wenn plötzlich Relationen abgebildet werden müssen, die sonst aus Foreign Keys bestehen würden, die aus mehreren Feldern bestehen.

Liebe Grüße,
Bernd