andi.007 Geschrieben 23. Mai 2001 Geschrieben 23. Mai 2001 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 ] Zitieren
han-shan Geschrieben 24. Mai 2001 Geschrieben 24. Mai 2001 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 ... Zitieren
andi.007 Geschrieben 24. Mai 2001 Autor Geschrieben 24. Mai 2001 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 Zitieren
*I C Q* Geschrieben 25. Mai 2001 Geschrieben 25. Mai 2001 Ã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 Zitieren
andi.007 Geschrieben 25. Mai 2001 Autor Geschrieben 25. Mai 2001 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 Zitieren
Cenobyte-- Geschrieben 28. Mai 2001 Geschrieben 28. Mai 2001 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... Zitieren
andi.007 Geschrieben 28. Mai 2001 Autor Geschrieben 28. Mai 2001 @ Cenobyte[] Also, ich habe keine Stunde dafür gebraucht. Ist meiner Meinung auch etwas viel Zeit. 30 min sollten eigentlich ausreichen. Zitieren
*I C Q* Geschrieben 28. Mai 2001 Geschrieben 28. Mai 2001 @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 Zitieren
kampi Geschrieben 29. Mai 2001 Geschrieben 29. Mai 2001 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 Zitieren
han-shan Geschrieben 30. Mai 2001 Geschrieben 30. Mai 2001 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? Zitieren
andi.007 Geschrieben 30. Mai 2001 Autor Geschrieben 30. Mai 2001 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: Zitieren
Sellew Geschrieben 1. Juni 2001 Geschrieben 1. Juni 2001 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 Zitieren
Sunday Geschrieben 3. Juni 2001 Geschrieben 3. Juni 2001 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 Zitieren
andi.007 Geschrieben 4. Juni 2001 Autor Geschrieben 4. Juni 2001 @ 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. Zitieren
wielux Geschrieben 4. Juni 2001 Geschrieben 4. Juni 2001 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 Zitieren
andi.007 Geschrieben 5. Juni 2001 Autor Geschrieben 5. Juni 2001 @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: Zitieren
Magier Geschrieben 5. Juni 2001 Geschrieben 5. Juni 2001 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? Zitieren
andi.007 Geschrieben 5. Juni 2001 Autor Geschrieben 5. Juni 2001 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 Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.