Hi!
Meine Frage nun: Ist es sinnvoller eine einzige Tabelle
„Auswahl“ anzulegen, und in dieser für die verschiedenen
Auswahl-Menüs (z.B. Ort (Stuttgart, Tübingen, Esslingen,…),
Land(Deutschland, Frankreich,…), Jahr (1999, 2000,…)) einzelne
Spalten einzuführen, oder ist es sinnvoller, für jedes Menü
eine extra Tabelle anzulegen, also „Ort“, „Land“, „Jahr“,…
Definitiv eine Tabelle je Entität.
Und für z.B. Stati auch eine eigene Tabelle? Für Listen mit 4-5 Auswahlmöglichkeiten auch? Oder doch lieber eine Tabelle mit einer zugeordneten „Domäne“ (wie z.B. „Status“ oder „Land“, wenn es nur bei Deutschland-Österreich-Schweiz bleibt) und mit den dazugehörigen Werten (wie bei „Status“ z.b. „aktiv“,„inaktiv“,„storniert“, etc.)
Natürlich wäre es am schönsten, wirklich eine Tabelle je Entität zu haben, allerdings kommt’s halt auch auf die Applikation an: Diese kennt halt nur die definierten - sagen wir mal - vier Statuswerte und jeder weitere (der durch eine Tabelle ja äußerst einfach anlegbar ist) würde die Applikation ins Nirvana schicken.
Wenn Du mit Auswahlboxen arbeitest, schränkst Du bewusst die
Eingabemöglichkeiten der Anwender ein.
Je weniger der Anwender eingeben kann, umso weniger Fehler kann er machen. _Der_ Anwender will eigentlich so wenig wie möglich frei eingeben, je mehr aus vordefinierten Werten auswählen kann, umso lieber ist es ihm - denn auch er weiß um seine Fehlerquelle.
Das macht nur dann
Sinn, wenn beispielsweise nur Orte ausgewählt werden sollen,
die in deiner DB bereits angelegt sind. Das erhöht die
Datenkonsistenz. Bei Freitexteingabe (und dadurch bedingtem
anlegen neuer Orte) kann es sonst dazu kommen, dass eine
Person in Stuttgart wohnt und eine andere in Stutgart.
Das große Problem bei den Orten liegt eher an der Aktualität der Datenbank bzw. wiederum am Wissen der Anwender. Der Anwender soll eine Person aus Hintertupfing (irgendwo z.B. in einer E-Mail angegeben) eingeben, findet diesen Ort aber nicht, da dieser Ort eigentlich zu Vordertupfing gehört; oder - und das ist der schlechteste Fall - die Datenbank „lernt“ mit jedem neuen Ort mit - und da haben wir wieder das „Stuttgart“-„Stutgart“-Problem.
WICHTIG:
beim DB-Design solltest Du Dich nicht so sehr von zukünftig
geplanten Auswahlboxen leiten lassen.
Doch, doch, … denn nur so kannst Du schlußendlich das Datenmodell VOR der Implementierung in die dritte Normalform bringen …
Vielmehr solltest Du den
Entitätenansatz verfolgen. Sprich: Welche Entitäten hast Du?
Diese ergeben sich dann aus dem obigen Fall - aus den „Auswahlboxen“ aus dem Grobdesign hole ich mir die Entitäten und deren Beziehungen raus.
Welche Informationen (zusätzlich zum Namen) möchtest Du in der
Datenbank vorhalten bzw. benötigst Du?
- Ort y: liegt in Land x
- Person z: wohnt in Ort y
Allerdings gibt es den Ort y dreimal im Land x und sogar 5-mal im Land xy - und die Person z wohnt in Ort y und im Ort yz - und dieser Ort ist wiederum mehrmals in veschiedenen Ländern definiert.
Du modelierst zunächst Deine Entitäten und deren Beziehungen
untereinander.
Und löst die n:m-Beziehungen auf …
Dann überlegst du Dir welche Informationen vom
Anwender eingegeben werden müssen (wenn Orte bereits Ländern
zugeordnet sind, ist es z.B. unnötig Ort UND Land eingeben zu
lassen. Der Ort reicht)
Eben nicht - wie obiger Fall zeigt: In der „realen“ Welt ist es mir bisher äußerst selten passiert, daß ein eingebbares Attribut wirklich ein eindeutiger Schlüssel ist. Erst die Kombination mit Verknüpfen auf verjointe Tabellen und anderen Tabellenfeldern ergibt die Eindeutigkeit eines Datensatzes.
Grüße,
Tomh
