[db-allgemein] implementierungsproblem

moin,

ich würde gerne mal von einem profi hören, wie man so etwas löst:

ich muss eine db konstruieren, die später daten zu büchern enthalten wird.
es gibt eine festgelegte liste an schlagwörtern wie z.b.:
rheinland-pfalz, reiseführer, fotografie, freizeit, garten, kochen, kunst, ratgeber, mit kindern… [das ist eine endliche liste, die schon feststeht]
der primary-key wird die isbn-nummer eines jeden buches selbst sein. zu jedem buch soll es die möglichkeit geben aus dieser festgelegten liste MEHRERE schlagwörter auszuwählen.
also gibt es bücher, auf die ‚rheinland-pfalz, fotografie und garten‘ als schlagwörter zutreffen.

wie setze ich das in der db und im user-interface um? mit check-boxen, die der user einzeln anklicken kann? schreibe ich dann in die db 0 oder 1 zurück, ob das schlagwort jetzt für diesen titel gültig ist oder nicht?

auf eine antwort würde ich mich sehr freuen.
gruß
tobias

Das ist eine klassische n:m-Verknüpfung zwischen deinen Tabellen „Schlagwort“ und „Buch“. Wenn deine Datenbank keine n:m-Verknüpfungen unterstützt (was i.d.R. der Fall ist), brauchst du eine Zwischentabelle, die die Verknüpfung realisiert. Wie die wiederum in der Benutzerschnittstelle abgebildet wird, ist eine andere Frage, die sehr von den Möglichkeiten des jeweiligen Frontends abhängt (in Access würde ich ein Unterformular oder ein Listenfeld nehmen…)

Reinhard

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

Hallo

Ich würde die ISBN nummer nicht als primary-key nehmen.

gruss, Giuseppe

Ich würde die ISBN nummer nicht als primary-key nehmen.

warum? sie ist einmalig für jedes buch…

gruß
tobias

Ich würde die ISBN nummer nicht als primary-key nehmen.

warum? sie ist einmalig für jedes buch…

Momentan ist sie so definiert. Du begibst Dich aber in die Abhängigkeit von „außen“. Deine Datenbank gehört Dir, lege selbst ein PK fest. Für die ISBN kannst Du ja ein unique index anlegen.

Ich würde davon abraten, die SW als Spalten einer Tabelle abzubilden, das ist gegen die 3. Normalform und widerspricht jedem guten Design. Unter anderem hast Du später Schwierigkeiten, herauszufinden, wieviele Schlagworte einem Buch zugeordnet sind (gibt Monster-SQLs).
Die Schlagworte würde ich in einer m:n-Beziehung darstellen (zu einem Buch gibt es kein…mehrere SW; zu einem SW gibt es kein…mehrere Bücher). Dazu mußt Du eine weitere Tabelle, sagen wir Buecher_SW, die nur die jeweiligen PKs enzthält. Das macht es flexibler (Du mußt Dich nicht auf die Anzahl festlegen; einfach anfügen und fertig).
In der GUI würde ich persönlich eher eine Liste mit Mehrfachauswahl vorziehen, sonst passen Dir die Checkboxen nicht auf den Bildschirm. Für jedes ausgewählte SW insertest Du einen Datensatz in der Tabelle Buecher_SW.
Alternativ gibt es dieses Spiel mit den beiden Listen und den Knöpfen:

------- -------
| bla | -\> | uno |
| nix | 
wobei links die verfügbaren, rechts die zugeordneten Schlagworte entstehen.

Hoffe geholfen zu haben

Gruß

J.