Datenbanken allgemein
Von: Κrіѕtіnа (abgemeldet), 15.2.2007 16:20 Uhr
Hallo,
Ich entwerfe gerade eine Datenbank. Dabei soll es später ein Eingabeformular geben, bei welchem einige Eingaben aus einer Drop-Down-Liste ausgewählt werden.
Die Werte für die Drop-Down-Listen sollen in einer oder mehreren Tabellen gespeichert werden.

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",…

Es wäre nett, wenn ihr mir auch sagt, warum ihr welche Version bevorzugen würdet.

Vielen Dank für eure Hilfe,
Kristina



  1. Antwort von Ulrісһ Vаіd 0
    Re: Datenbank Design

    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",…
    Hallo

    - ich würde auf jeden Fall für jede Entität eine eigene Tabelle erstellen. Wenn du alle Codewerte in einer Tabelle anlegst, hast du es viel schwerer, eventuell vorhandene Beziehungen zu modelieren, also z.b Foreign Keys etc. Und genau dass sind ja, die Gründe, weswegen du eine RDBMS benutzt...


    Gruss
    1 Kommentare
    • von Τоmһ 0
      Re^2: Datenbank Design
      Hi Kristina und OCP-Genosse! - ich würde auf jeden Fall für jede Entität eine eigene
      Tabelle erstellen.
      Wenn du alle Codewerte in einer Tabelle
      anlegst, hast du es viel schwerer, eventuell vorhandene
      Beziehungen zu modelieren, also z.b Foreign Keys etc. Und
      genau dass sind ja, die Gründe, weswegen du eine RDBMS
      benutzt...
      Ich würde eher sagen: Es kommt drauf an, wieviele Werte die Tabelle enthält - die CG_REF_CODES unter Oracle ist ja das schönste Beispiel dafür, wie mehrere Entitäten in einer Tabelle abgehandelt werden; ein Check-Constraint ersetzt dann den Foreign-Key (bei den Jahren z.B. würde ich nicht gerade extra eine Tabelle anlegen - und wenn ich nur eine handvoll Länder dazu habe ist eine Codes-Tabelle bereits optimal)

      Aber im Großen und Ganzen ist alleine schon rein von der sauberen Datenstruktur die "eine Entität - eine Tabelle"-Struktur vorzuziehen - und spätere Entwickler und DBA's werden es Dir danken :)

      Grüße,
      Tomh
  2. Antwort von Dоm312 (abgemeldet) 0
    Re: Datenbank Design
    Hallo,
    Ich entwerfe gerade eine Datenbank. Dabei soll es später ein
    Eingabeformular geben, bei welchem einige Eingaben aus einer
    Drop-Down-Liste ausgewählt werden.
    Die Werte für die Drop-Down-Listen sollen in einer oder
    mehreren Tabellen gespeichert werden.
    Baue auch gerade eine DB und werde später auch Formulare mit drop-down-Auswahl haben. 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. Es wäre nett, wenn ihr mir auch sagt, warum ihr welche Version
    bevorzugen würdet.
    Wenn Du mit Auswahlboxen arbeitest, schränkst Du bewusst die Eingabemöglichkeiten der Anwender ein. 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.

    WICHTIG:
    beim DB-Design solltest Du Dich nicht so sehr von zukünftig geplanten Auswahlboxen leiten lassen. Vielmehr solltest Du den Entitätenansatz verfolgen. Sprich: Welche Entitäten hast Du?
    - Land
    - Ort
    - Person
    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

    Du modelierst zunächst Deine Entitäten und deren Beziehungen untereinander. 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)

    Wenn Du dem Anwender nun ein Eingabeformular zur Verfügung stellst und seine Eingaben bei bestimmten Feldern einschränkst, dann befüllst Du die Liste im Formular mit den in der jeweiligen Tabelle vorgesehenen Werten Vielen Dank für eure Hilfe,
    Kristina
    Hoffe das hilft, Dom
    1 Kommentare
    • von Τоmһ 0
      Re^2: Datenbank Design
      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
  3. Antwort von Μаrkuѕ Оnlеіn 0
    Re: Datenbank Design
    Ich entwerfe gerade eine Datenbank. Dabei soll es später ein
    Eingabeformular geben, bei welchem einige Eingaben aus einer
    Drop-Down-Liste ausgewählt werden.
    Hallo Kristina,
    falls du Access verwendest, gibt es in der Tabelle und auch im Formular die Möglichkeit, alle bisher eingegebenen Werte der Spalte als Auswahlliste "Kombinationsfeld" darzustellen. Bei manueller Eingabe wird dann mit jedem eingegebenen Zeichen der erste übereinstimmende Wert vorgeschlagen.
    So ist die Liste flexibel und immer aktuell ohne Pflege einer zusätzlichen Tabelle.
    Freundliche Grüsse,
    Markus