Hallöchen zusammen,

was haltet Ihr von dieser Lösung für die GH1, Handlungsschritt 4 ? Bin für Anregungen und Kritik offen.

andi.007

[ 07. Juni 2001: Beitrag editiert von: andi.007 ]

der primärschlüssel der tabelle "Orte" ist meiner ansicht nach problematisch, denn mehrere orte können dieselbe postleitzahl haben (kleinere orte werden manchmal in einer PLZ zusammengefasst) ... und Ort kommt als primärschlüssel auch nicht in frage, da ortsnamen nicht auch mehrfach vorkommen ...

Was würdest Du denn vorschlagen? Ein Feld Ort_Nr einfügen und als Primärschlüssel deklarieren?

Bist Du denn mit dem Rest einverstanden?

andi.007

Ãlso ich denke, dass die Tabelle "Buchungspositionen" über ist, da Du ja bei jeder Buchung nur ein(!) Auto bestellst.

Der Logik deines Aufbaus nach könnte man für jede Buchung mehrere Autos bestellen, und das ist nicht gefordert

Cya,

Red Bull

Einverstanden! Ich hätte der Tabelle 'Buchungen' am besten den Namen 'Rechnungen' und der Tabelle 'Buchungspositionen' den Name 'Rechnungspositionen' verpassen sollen. Und dann sollte es eigentlich passen, da die Rechnung ja für einen Zeitraum (z.B. ein Monat) erstellt wird und man pro Zeitraum mehrere Autos buchen kann.

andi.007

He Leute. Gute Lösung.

Nur mal eine Frage.

Um die Aufgabe richtig zu lösen braucht man normalerweise mind. 1 Stunde - wir hatten nicht mal die Hälfte.

Wenn ich da nicht richtig liege, sagts mir...

@ Cenobyte[]

Also, ich habe keine Stunde dafür gebraucht. Ist meiner Meinung auch etwas viel Zeit. 30 min sollten eigentlich ausreichen.

@Cenobyte:

Ne Stunde scheint mir auch 'n bissel viel zu sein. Persönlich habe ich ca. 15 Min. gebraucht, ich geh mit dem (MÄÄÄP) aber auch jeden Tag um.

Aber für jemanden, der sowas schonmal gesehen hat, sollte das in 30 Min. machbar sein. Für alle anderen sieht's natürlich schlechter aus

Cya 2gether,

Red Bull

mit einer halben stunde sollte man auskommen. nur bei der 1. aufgabe brauchte man mehr. ich auf jeden fall. habe noch nie irgentwas mit uml gemacht. das struktogramm war einfach und die sql-anweisungen komplett aus dem tabellenbuch. insgesamt war die zeit dann doch ok

cu

---

es gibt tage da verliert man und es gibt tage da gewinnen die andern

Original erstellt von andi.007:

<STRONG>Was würdest Du denn vorschlagen? Ein Feld Ort_Nr einfügen und als Primärschlüssel deklarieren?

</STRONG>

können PLZ und Ort nicht einfach spalten in der tabelle kunden sein?

Natürlich können PLZ und Ort einfach Spalten in der Tabelle Kunden sein. Damit hast Du dann aber redundante Datenhaltung. Und es ist eben Sinn einer Datenbank, diese zu vermeiden. Sonst könntest Du Dir doch den Aufwand sparen und einfach alle Werte in eine Excel-Tabelle hauen. Is halt nich Sinn der Sache :cool:

hi,

hier muss ich andy wieder recht geben, denn es können ja 2 Kunden aus ein und demselben ort kommen und schon sind die daten redundant.

aber mit seiner plz wird es auch mist als primary key. nehmen wir an ein kunde kommt aus der etwas größeren stadt und der zweite aus pupsdorf um die ecke. beide haben die selbe plz. was nu? du kriegst auf jedenfall nur einen von beiden orten über die plz raus.

ich würd noch eine ort_id einführen.

Gruß

Sellew

hi,

also erstmal ist es völliger quatsch um jeden preis redundante daten zu verhindern. das wird alles viel zu unübersichtlich, wenn du für jeden krimskrams ne eigene tabelle anlegst.

zu einem kunden gehört nunmal vorname, nachname, strasse, plz, ort, telefon, fax, kontonr und blz.

da ist es echt überflüssig noch ne tabelle für orte anzulegen. da könnte man genauso gut ne extra tabelle für alle vor- und nachnamen machen. alle vorwahlen der telefon und faxnummern seperat speichern und ebenso die blz zusammenfassen.

mehr als 4 tabelle sind bei korrekter auflösung der entities nicht nötig!

3 tabelle fuer ein fahrzeug?? puh...

worin liegt denn jetzt der unterschied zwischen fahrzeugklassen und fahrzeugtypen?

was soll ausserdem BLZ als primärschlüssel, wenn da noch die kundennummer drin steht?

ich finde ein bissel abschätzen in wie weit auflösung der daten in mehrere tabelle sinnvoll ist, sollte man schon, aber einfach tabellen anlegen um jede redundanz zu verhindern, wird dir sowieso nicht gelingen und ist meiner meinung nach übertrieben.

so long

@ Sunday

Ich will es mal so sagen: es gibt die 3 Normalformen bei der Entwicklung der Datenbanken. Und wenn es in der Prüfung heißt: Bringen Sie die Tabellen in die 3. Normalform, so würde ich mich auch unbedingt daran halten, um keine Punkte zu verschenken

also erstmal ist es völliger quatsch um jeden preis redundante daten zu verhindern. das wird alles viel zu unübersichtlich, wenn du für jeden krimskrams ne eigene tabelle anlegst.

Im Falle einer kleinen Datenbank magt Du recht haben. Aber was machst, wenn diese auf Kundenwunsch erweitert werden muß? Dann mußt unter Umständen die ganze DB und Deine Applikation neu entwickeln. Das ist absolut tödlich in der Praxis.

worin liegt denn jetzt der unterschied zwischen fahrzeugklassen und fahrzeugtypen?

Die Miet-Preise gelten pro Fahrzeugklasse. Fahrzeugtypen sind z.B. Ford KA, Smart Cabrio etc.

Also andi,

ich hab da zwei Anmerkungen zu deinem ER-Diagramm.

Erstens: Die Referenz (FK) in der Tabelle Fahrzeugklassen ist zu viel. Du musst immer auf der n-Seite referenzieren. Also weg mit dem Attribut und den FK auf Fahrzzeugtypen.Fahzeugklassen_Nr legen.

Zweitens: An welcher Stelle ist die Bankverbindung des Kunden verlangt gewesen? Stand das in der Aufgabenstellung? Wenn ja ist die Bankleitzahl kein Primärschlüssel (Inhalt nie als Schlüssel ), da sie sich ändern kann (theoretisch). Und wie Sunday schon schrieb gehört die Kundennummer nicht in die Tabelle der Bankverbindung, dafür wäre dann die BLZ ein Fremdschlüssel in der Kundentabelle. Dasselbe gilt für die Postleitzahl (wir erinnern uns an die Postleitzahlenumstellung :confused: ). Im Grunde musst du hier den Ort auslagern, die Postleitzahl auslagern und diese m:n also mit Verknüpfungstabelle zusammenbinden. Diese Verknüpfung migriert dann irgendwie (z.B. eigener Schlüssel) in die Kundentabelle.

Aber realistisch betrachtet macht das doch kein Mensch, Redundanz hin - Redundanz her. Performance und Übersichtlichkeit sind auch wichtig und in der Prüfung denke ich werden die Korrekteure die nicht3NF ebenfalls mit 100% bewerten.

Ich hoffe das wolltest du lesen!

so long

@Nussknacker

Endlich mal was ordentliches

Erstens: Die Referenz (FK) in der Tabelle Fahrzeugklassen ist zu viel. Du musst immer auf der n-Seite referenzieren. Also weg mit dem Attribut und den FK auf Fahrzzeugtypen.Fahzeugklassen_Nr legen.

Hast recht. Gehört da nicht hin.

Zweitens: An welcher Stelle ist die Bankverbindung des Kunden verlangt gewesen? Stand das in der Aufgabenstellung?

Vorgegeben war eine Rechnung, die an den Kunden ausgestellt wird, und da war halt auch die Bankverbindung (des Kunden) mit angegeben.

Und wie Sunday schon schrieb gehört die Kundennummer nicht in die Tabelle der Bankverbindung

Stimmt auch, würde ich heute auch nicht mehr so machen.

dafür wäre dann die BLZ ein Fremdschlüssel in der Kundentabelle

Ist auch.

Aber realistisch betrachtet macht das doch kein Mensch, Redundanz hin - Redundanz her. Performance und Übersichtlichkeit sind auch wichtig und in der Prüfung denke ich werden die Korrekteure die nicht3NF ebenfalls mit 100% bewerten.

Da wäre ich mir nicht ganz so sicher. Wenn die explizit nach der 3. NF fragen, dann würde ich mich auch daran halten :cool:

Mag sein, daß es in der 3.NF sein muss, dss ich wg. Redundanz PLZ/Ort auslagere. Mache ich das so, muß ich mir jedoch auch im klaren drüber sein, dass meine Autoverleihfirma nicht zu stark - sprich über die Staatsgrenze hinaus - wachsen darf, weil ich meine Kunden aus Holland wegen der beschissenen PLZ-Tabelle dann nicht mehr erfassen kann, stimmts ?

Und was nun, eine Ländertabelle einfügen?

Ja, würde ich sagen. Was sollte denn dagegen sprechen?

Das haben wir im Unterricht über Datenbanken gelernt und ich meine, dass das so im Prinzip ok ist. Ansonsten besucht doch mal eine Datenbank-Schulung und belehrt mich gerne eines besseren