SQL Datenbank erstellen

rudpower

ich bin ziemlicher Neuling was Datenbank betrifft. Ich arbeite mit Visual Studio 2008 und wollte mir eine Datenbank erstellen. Es soll eine Art Hotelverwaltung werden mit Kunde, Ort und Zimmer. Also hab ich mir 3 Tabellen erstellt. Probleme hab ich nun bei den Beziehungen.
Hab es so aufgebaut:
tabKunde: Spalten: KdNr (key), Name, Vorname
tabOrt: Spalten: Plz (key), Ortsname
tabZimmer: ZiNr (key), Bettenanzahl

Ich denke ich brauch 2 Beziehungen hier: Kunde wohnt in Ort (n : 1) und Kunde reserviert Zimmer (n : 1)

Nun möchte ich die Beziehungen aufbauen. Wie mach ich das?

Zeus

Du musst deine Tabellen um Fremdschlüssel erweitern.

rudpower

mit den Fremdschlüsseln kann ich noch nicht so richtig was anfangen. Ich denke mal so:
tabKunde: Spalten: KdNr (key), Name, Vorname
tabOrt: Spalten: Plz (key), Ortsname, KdNr (fremdschlüssel)
tabZimmer: ZiNr (key), Bettenanzahl, KdNr (fremdschlüssel)

Is so korrekt?

Zeus

Notation:
Tabelle(Primärschlüssel, Fremdschlüssel, Spalten,...)

Kunde(KdNr, Name, Vorname)
Ort(Plz, Ortsname)
Zimmer(ZiNr, Bettenanzahl)

Kunde:
001 Müller Albert
002 Schlager Otto
003 Lauch Sabine

Ort:
12345 Berlin
28690 Hanover

Zimmer:
101 2
102 3

Mark mal mit [Tabelle oder Wert eines Schlüssel] wo du Fremdschlüssel setzen würdest. In der Tabelle, nicht in der Notation

rudpower

Kunde(KdNr, Name, Vorname)
Ort(Plz, KdNr, Ortsname)
Zimmer(ZiNr, KdNr, Bettenanzahl)

Kunde:
001 Müller Albert
002 Schlager Otto
003 Lauch Sabine

Ort:
12345 Berlin
28690 Hanover

Zimmer:
101 2
102 3

ich merk grad das ich den Fremdschlüssel KdNr bei der Tabelle Ort und Zimmer nicht nehmen dürfte, da es ja mehrere Kunden geben kann die zB in Berlin wohnen. Da weiss ich jetzt nicht weiter

Zeus

Ich hab doch gesagt, in den Tabellen nicht in der Notation.
Ausserdem meinte ich nicht das du die Formatierung der Notation in Tabellen setzen sollst -.-

Also für
Kunde wohnt in Ort (n : 1)

Kunde:
001 Müller Albert [12345]
002 Schlager Otto [28690]
003 Lauch Sabine [12345]

Ort:
12345 Berlin
28690 Hanover

würdest du es so notieren?

Dann hast du das Schema:
Kunde(KdNr, OrtId, Name, Vorname)

zwutz

Du hast erstmal zwei relevante Entitäten, Kunde und Zimmer

Die Beziehung zwischen den beiden ist das nächste, was du ermitteln musst.
Ein Kunde kann in mehreren Zimmern wohnen (nur nicht zeitgleich), ein Zimmer kann von mehreren Kunden bewohnt werden (auch hier aber nicht zeitgleich)

Eine simple Fremdschlüsselbeziehung klappt also nicht, da du damit keine n:m-Beziehungen abbilden kannst. Du brauchst also eine Zwischentabelle.

Als nächstes kommen die einzelnen Werte.
Kunde (KdNr, Vorname, Nachname, PLZ, Ort) *
Zimmer (ZiNr, Betten)
Reservierung (KdNr, ZiNr, DatumVon, DatumBis)

Damit wär eigentlich bereits alles erledigt

* Ja, ich weiß. PLZ und Ort lagern viele in eine eigene Tabelle aus, aber dieser Ansicht widerspreche ich aus gutem Grund: Es gibt mehrere Orte mit gleicher Postleitzahl und mehrere Postleitzahlen für einen Ort. Von daher ist das ebenfalls eine m:n-Beziehung.
Über den Straßennamen lässt sich auch nicht der richtige Ort ermitteln, da z.B. hier in Bayern in den 70er Jahren eine Gebietsreform war und es seitdem in einer Gemeinde mehrere Orte mit derselben Straße geben kann. Von daher ist die einzig 100% eindeutige Methode, den Ortsnamen mit abzuspeichern

rudpower

also bekommt Reservierung 2 Fremdschlüssel. Mit den Fremdschlüsseln hab ich nicht so richtig verstanden.

Hab versucht mal in Visual Studio die Beziehungen einzurichten. Bin einfach auf die Tabelle von Kunde. Dann auf "Beziehungen". Beziehung hinzufügen->Tabellen-und Spaltenspezifikationen-> "...":

[b]FK_Reservierung_Kunde:[/b]
Primärschlüsseltabelle:   Fremschlüsseltabelle:
Kunde                     Reservierung 
KdNr                      KdNr

[b]FK_Reservierung_Zimmer:[/b]
Primärschlüsseltabelle:   Fremschlüsseltabelle:
Zimmer                    Reservierung
ZiNr                      ZiNr

Das müsste ja eigentlich so passen oder?

zwutz

Sieht gut aus, ja

asc

zwutz schrieb:

Über den Straßennamen lässt sich auch nicht der richtige Ort ermitteln, da z.B. hier in Bayern in den 70er Jahren eine Gebietsreform war und es seitdem in einer Gemeinde mehrere Orte mit derselben Straße geben kann.

Auch bei sehr langen Straßen passiert dies bereits in einem Ort.

Als ich vor langer Zeit noch mit den sogenannten Postleitdaten gearbeitet habe, war dies eine komplexe Tabellenhirachie, in der Straßen mit Hausnummerbereichen angegeben wurden. Man kann also durchaus einen Ortsnamen oder eine PLZ herleiten, benötigt dann aber neben dem jeweils anderen teilweise auch die Hausnummer.

Unix-Tom

PLZ sollte in eine eigene Tabelle.
Für die DB ist es egal ob in der Kundentabelle der Ort steht.
Gem. Normalisierung wir dies aber in eine eigene Tsbelle ausgelagert und nur die ID in die Kundentabelle.
Dabei spielt es keine Rolle wieviele Orte es zu einer PLZ gibt.
Hintergrund: Ändert sich zu einer PLZ der Ort braucht man nur eine ROW ändern. Alle Kunden fallen dann da rein.
So muss man alle ROWS der Kunden durchgehen.
Hat man viele Kunden muss man sich nur vorstellen wie groß die Tabelle wird wenn da auch noch Ort als VARCHAR u.s.w gespeichert wird. Da ist ein INT schon etwas kleiner.
Zumindest die ersten 3 Formen sollen eingehalten werden.

asc

Unix-Tom schrieb:

PLZ sollte in eine eigene Tabelle.

Rein von der Praxiserfahrung her: Kunden meckern dann, wenn ein Ort oder eine PLZ nicht gepflegt ist (und wenn es "automatisch" aus den Eingaben generiert wird, hast du am Schluß einen ziemlichen Wildwuchs an Schreibfehlern, oder Ergänzungen).

Ich halte es aber auch nicht für verkehrt, PLZ/Ort (+ ggf. Ländercode, Vorwahl...) in einer separaten Tabelle zu hinterlegen (mit einer Id als Schlüssel, die PLZ ist dafür ungeeignet), dann muss man aber auch dafür sorgen, das diese möglichst vollständig und richtig initialisiert ist (Was den Vorteil hätte, das wenn man eine Seite eingibt, die Andere zu einer reinen Auswahl werden könnte).

zwutz

eine ID ist auch möglich, aber wie asc sagt sollte man dafür nicht die PLZ verwenden

Hintergrund: Ändert sich zu einer PLZ der Ort braucht man nur eine ROW ändern. Alle Kunden fallen dann da rein.

Wie oft kommt das vor? Da lässt man am Sonntag Abend nen Update drüberrauschen und fertig

Zumindest die ersten 3 Formen sollen eingehalten werden.

stimme ich dir zu. Aber wie bei jeder Regel gibt es auch hier Ausnahmen. Besonders bei Abfragen die sehr schnell sein müssen verzichtet man dann gerne auf die Normalisierung um sich zeitintensive Joins zu sparen

Unix-Tom

Man kann PLZ-Tabellen aus dem INET gratis bekommen.
Aus der Praxis:
Man macht eine eigene PLZ-Tabelle bzw. verwendet eine.

PLZ-Tabelle wird nicht aus den Eingaben generiert.
PLZ ist kein PrimKey da nicht eindeutig.
Das ist die einfachste Form der Normalisierung.
Ein JOIN ist schneller als in einer großen Tabelle suchen die unnötig groß ist.
In Eingabemasken kann man die PLZ-Tabelle verwenden.

Bei Postleitzahlen ignoriere ich gepflegt die Normalformen und füge sie einfach als spalten in den adressdaten hinzu.

Warum?
Die zusammenhängigkeit Ortsname <--> Plz sind nicht immer eindeutig, sind nicht immer eindeutig bekannt.
Ein Kumpel von mir wohnte frühr in einem kleinen Kuhdorf (ich weiss den Namen nichtmehr. Nennen wir es mal Mühldorf). Die Dazugehörige Plz (wieder frei erfunden) war 34543.
Das Nachbar dorf hatte die selbe PLZ, hiess aber Apfelheim.

So schrieben sie es auch immer in die adressen ein. Der eine wohnte in 34543 Apfelheim, der andere in 34543 Mühldorf.

Damit fällt auf jedenfall schonmal die PLZ als pk durch. Der Ortsname ist nicht eindeutig von der Plz abhängig.

Andersrum gilt das selbe. Berlin hat zig verschiedene PLZ. Und vor allem gibts immer viele Schreibweisen. Der eine wohnt einfach nur in 10965 Berlin, der andere in 10965 Berlin-Neukölln, und der nächste in 10965 Berlin Neukölln. Ob as nun Amtlich richtig ist, interresiert die Leute aber nicht. Und wenn sie Berlin-Neukölln eintragen wollen, das aber nicht können sind sie verwirrt/verunsichert.
Ausserdem is der Ortsname weitgehend unwichtig für die Deutsche Post. Kommt auch fast immer alles ohne an. Daher liegt mir da nicht sonderlich viel Wert an Konsistenz zwischen plz und Ort. Wichtig ist, das es beides gibt.

Und an dieser Stelle ist mir der Aufwand/Nutzen faktor einfach zu gering.

Klar ist die Datenbank dann nicht zu 100% in der Normalform, aber es gibt schlimmeres.

asc

o_O schrieb:

Die zusammenhängigkeit Ortsname <--> Plz sind nicht immer eindeutig, sind nicht immer eindeutig bekannt.

Das wurde aber bereits oben mehrfach erwähnt. Ich würde schon eine Zuordnung PLZ-Ort trennen (ggf. in Kombination mit der Vorwahl etc), nicht aber die PLZ als Schlüssel verwenden.

Zu den unterschiedlichen Schreibweisen: Weißt du wie bescheiden es ist, wenn in einer Adressverwaltung Kunden sich beschweren, weil in ihrer Suche nicht alle Datensätze gefunden werden? Dies passiert ganz häufig wegen Eingabefehlern, oder uneinheitlichen Namensgebungen.

Wenn man eine PLZ/Ort-Tabelle führt könnte man nun die Auswahl zumindest einschränken (z.B. in Form einer Combobox), und (ggf. über spezielle Rechte) auch die direkte Eingabe weiterer erlauben.

o_O schrieb:

Und an dieser Stelle ist mir der Aufwand/Nutzen faktor einfach zu gering.

Kommt auf das an, was mit den Datensätzen gemacht werden soll. Bei einer Suche kann ein Eingabefehler schon schnell zu einem Ausschluss des Datensatzes führen, was wiederum Konsequenzen nach sich ziehen kann (Sei es doppelte Eingabe des Datensatzes, sei es das Wichtige Gesprächsnotizen etc. nicht mehr gefunden werden...).