Wie gestalte datenbankstruktur am besten
ich möchte zur Übung eine kleine Datenbank machen, doch habe ein Problem:
Ich möchte für Kunden ein Offert ausstellen können und falls dieses Angebot kommt, also ein Auftrag entsteht, muss ich eine Auftragstasche machen. Diese hat zu 90% die gleichen Informationen, allerdings einige nur Firmeninterne. Jetzt muss ich aber viele Offerte erstellen können, bevor es überhaupt zu einem Auftrag kommt und eine Auftragstasche erstellen, falls ich einmal kein Offert im vorhinein brauche.
Mein Ansatz:
Ich mache eine Tabelle 'Auftrag' und in dieser kann ich über einen Fremdschlüssel die Tabelle 'Offert' und die die Tabelle 'Auftragstasche' verknüpfen. So kann ich mir meinen Auftrag zusammen bauen. Aber da im Offert und in der Auftragstasche zu 90% die gleichen Daten stehen, wäre das nicht gut. Außerdem möchte ich bei einer Auftragstasche gleich die Daten von einem Offert übernehmen und nicht neu schreiben müssen.
!
,
spiele08
5 Antworten zur Frage
Videos zum Thema
YouTube Videos
Wie gestalte ich diese Datenbankstruktur am besten?
Lagere alle Daten, die in mehr als einer Tabelle vorkommen, aus diesen Tabellen aus in eine bis mehrere weitere Tabellen.
Diese neuen Tabellen versiehst mit Primärschlüsseln und in den bisherigen speicherst nur noch diesen Primärschlüssel als Fremdschlüssel.
Bei Bedarf kannst dann noch Constraints definieren, die dann automatisch prüfen, ob es zum Fremdschlüssel einen passenden Eintrag in der neuen Tabelle gibt - also z.B. bei einer Kundennummer, ob es diese auch im Kundenstamm gibt.
Bei praktisch allen vernünftigen DBMS ist ein Fremdschlüssel automatisch auch ein Constraint. Wäre ja auch doof, wenn man einfach so die referentielle Integrität verletzen könnte.
Üblicherweise ja, aber ich hoffe, Du kannst Dir zumindest vorstellen, was ich oft genug erleben musste:
"Schlüssel speichern: JA, Schlüssel prüfen: NÖ, weil. blablabla
Pack einfach alles in eine Tabelle und setze ein Flag für Angebot oder Auftrag … die Kundendaten würde ich natürlich in eine separate Tabelle packen und die dann mit der Auftragstabelle verknüpfen. Das ist klar.
Grundregel: niemals ein Datum in zwei Tabellen halten! Redundanz in Datenbanken bringt eine Menge Ärger.
Eine Tabelle könnte die Stammdaten des Kunden halten. Diese benötigst Du sowohl für Angebote als auch für Aufträge. Haben die Kunden eine übergeordnete Struktur, z.B. mehrere Ansprechpartner in einer Firma, dann kommen die Firmendaten in eine Tabelle, die Kundendaten in eine zweite, und die Firmendaten werden verknüpft.
Informationen für das Angebot kommen in eine weitere verknüpfte Tabelle. Die zusätzlichen Daten für den Auftrag würde ich wiederum seperat erfassen und mit dem Auftrag verknüpfen.
Jetzt mußt Du noch überlegen, ob Du eine Historie benötigst. In dem Fall würde ich eine weitere Tabelle "Historie" anlegen, in die alle Daten kopiert werden, wenn der Auftrag als "geliefert" markiert wird. So kannst Du auch später noch suchen, wohin welcher Auftrag gegangen ist. eventuell mußt Du auch Angebote so ablegen.
Im allgemeinen ist es nicht zielführend, einfach drauflos Tabellen zu erstellen. Besser man fängt mit einem sauberen, konzeptionellen Modell an und setzt das dann um. Wenn man das richtig macht, kommen ganz von selbst normalisierte Tabellen ohne unerwünschte Redundanz raus.