Gestaltung der Tabellen in einer DB

[Mirilin]

Ich habe eine Frage, bezüglich der Form meiner Tabellen.
Und zwar habe ich vor - um einwenig Datenbankprogrammierungs-Luft zuschnappen - eine DBs mit meinen Büchern anzulegen. Nun hab ich das Problem mit den Tabellen, wie ich das am Besten mache.

Ich hatte mir gedacht, dass ich eine Tabelle anlege, die den Buchtitel und ISBN etc enthält. Die Autoren wollte ich in einer separaten Tabelle auflisten (da ja ev verschiedene Bücher von einem Autor vorhanden sind). Nun hab ich das Problem, wie ich das am Besten mache.
Wenn ich in der Buchtabelle ein Feld mache, in welchem die ID des Autors steht, dann habe ich das Problem mit den Büchern, die mehrere Autoren haben.

Ich habe überhaupt keine Idee, wie ich das klug lösen könnte.


mfg Tobias

[Hansa]

Wo gibts denn so was ? Mirilin und Datenbanken.

Ich würde max. 3 Autoren pro Buch vorsehen. Sind es noch mehr, so müssen die eben irgendwie abgekürzt in den 3 Feldern untergebracht werden. Deshalb würde ich die Felder nicht zu klein machen.

[Bernhard Geyer]

Tabelle Bücher:
ISBN-Nummer (Primärschlüssel: PK)
Titel

Tabelle Autoren:
ID (PK)
Name,
Vorname,
...

Tabelle Buchautoren:
ISBN-Nummer
Laufende Nummer
Autoren-ID

Damit können auch mehrere Autoren an einem Buch geschrieben haben.

[Mirilin]

Danke schonmal.
Dann könnt ich ja auch gleich in der Haupttabelle ein Feld für die Autoren machen, aber das kommt mir irgendwie nicht "sauber" vor ^^ weiss auch nicht warum.

Code:

Haupttabelle
+----+---------+-----------+-----------+-----------+---------+
+ ID | Titel   | Autor1-ID | Autor2-ID | Autor3-ID | ....    |

AutorTabelle
+----+------------+
| AID| Name       |

Das wäre ja eine möglichkeit, aber dann sind die Autoren eben begrenzt und gefalten tut es mir auch nicht ^^

Oder wie hast Du es genau gemeint?

mfg Tobias

[Jelly]

Zitat von Hansa:

Ich würde max. 3 Autoren pro Buch vorsehen. Sind es noch mehr, so müssen die eben irgendwie abgekürzt in den 3 Feldern untergebracht werden. Deshalb würde ich die Felder nicht zu klein machen.

Tut mir leid, aber so löst man die Art Probleme nicht. Mirlins Problem beschreibt eine klassische n:n Beziehung zwischen 2 Tabellen, sprich, ein Autor kann mehrere Bücher schreiben, sowie ein Buch kann von mehreren Autoren sein...
Die Lösung ist eine 3. Tabelle, welche die Beziehungen zwischen den beiden anderen Tabellen herstellt. Für die Tabelle reichen im Prinzip 3 Spalten aus: 1. ein Primary Key (gehört immer rein), 2. ein Foreign Key zur Bücher Tabelle und 3. man glaubt es nicht: ein Foreign Key auf die Autoren Tabelle. Zusätzlich sollte man noch ein Unique Index auf die beiden letzt genannten Spalten legen, um doppelte Einträge gleich im Vorfeld zu vermeiden...

Gruß,
Tom

[Hansa]

Bín eben Praktiker. Wie oft kommt es vor, daß es z.B. 5 Autoren gibt ? Aber Bernhard Geyers Vorschlag ist der sauberste. Er dreht quasi Mirilins Vorhaben um. Nicht die Autoren werden bei den Büchern gespeichert, sondern die Bücher bei den Autoren. Sucht man nun die Autoren zu einem Buch, so genügt es, die Autorentable nach der ISBN zu durchsuchen.

[Mirilin]

herzlichen Dank für Eure Antworten *verneig*


mfg Tobias

[Jelly]

Zitat von Hansa:

Bín eben Praktiker. Wie oft kommt es vor, daß es z.B. 5 Autoren gibt ? Aber Bernhard Geyers Vorschlag ist der sauberste. Er dreht quasi Mirilins Vorhaben um. Nicht die Autoren werden bei den Büchern gespeichert, sondern die Bücher bei den Autoren. Sucht man nun die Autoren zu einem Buch, so genügt es, die Autorentable nach der ISBN zu durchsuchen.

Sorry, immer noch nicht Die Lösung von Bernhard verwendet eben auch 3 Tabellen. Und damit kannst du rein theoretisch 1 Milion Bücher pro Autor haben und 1 Million Autoren pro Buch.

Gruß,

[Bernhard Geyer]

Zitat von Hansa:

Er dreht quasi Mirilins Vorhaben um.

Nich ganz umgedreht. Es lößt nur die n:m-Beziehung von der Jelly redet in Tabellen auf.

Vieleicht besser:
Tabelle Buchautoren:
ISBN-Nummer (PK)
Autoren-ID (PK)
Autorenstatus (z.B. H = Hauptautor, N = Nebenautor, L = Lektor, ....)

[Leuselator]

Ihr habt da einen Klassiker am Wickel - der einzig Sinnvolle Weg, soetwas zu lösen und im Zweifel weder ein Feld zu wenig oder zu viel noch so böse böse Ideen wie die vom Hansa verwirklichen zu müssen lautet: Zwischentabelle!

Delphi-Quellcode:

                             +---------------------+
                             |Tabelle Buch_Autor   |
+--------------------+       +---------------------+
|Tabelle Bücher      |       |idBuch_Autor(int)(PK)|
+--------------------+       |                     |
|idBuch (int)(PK)    |<------|idBuch  (int) (FK)   |
|                    |       |                     |
|... weitere Felder  |   +---|idAutor (int) (FK)   |
|                    |   |   |                     |
+--------------------+   |   +---------------------+
                         |
+--------------------+   |
|Tabelle Autoren     |   |
+--------------------+   |
|idAutor (int)(PK)   |<--+
|                    |
|... weitere Felder  |
+--------------------+

(PK) steht für Primary Key (Primärschlüssel) ein Tabellenweit eindeutiger Wert (einfachste Variante: fortlaufende Zahl /Autoincrement)

(FK) steht für Foreign Key (Fremdschlüssel), verweist auf genau einen Datensatz in der bezogenen Tabelle

Wenn mann nun einen Autor hat, der 2 Bücher geschrieben hat, legt man einfach 2 Datensätze in der Tabelle Buch_Autor an, die beide auf den selben Autor, aber auf unterschiedliche Bücher zeigen.

Hat man ein Buch, an dem 3 Autoren mitgewirkt haben, legt man 3 Datensätze in der Tabelle Buch_Autor an, die alle auf das selbe Buch, jedoch auf jeweils andere Autoren zeigen.

Um solche "normalisierten" Tabellen wieder in einer Abfrage zu einem logisch zusammenhängenden Datensatz zusammenzufügen, benutzt man Joins.

Soviel als kleine Einführung.
Gruß