Datenbankdesign: Den Grad des Hirnrisses bestimmen

Hallo Leute,

Ich bin heute bei einer von uns zu pflegenden Datebank auf zwei Konzepte gestoßen, die ich höchst merkwürdig finde:

1. Semantisch äquivalente Daten in unterschiedlichen Tabellen
Sagen wir, wir haben eine Tabelle 'Aufträge'. Nun entdecke ich eine weitere Tabelle 'AufträgeVonOstblockKunden' und eine 'AufträgeAnFremdfirmen'. Und -oh- 'AufträgeVonOstblockKundenVomLetzenJahr' usw.

Aber: Ein Auftrag wandert äußerst selten von einer Tabelle zur nächsten. Nur beim Jahreswechsel werden die Aufträge an Ostblockkunden in die Tabelle vomletzenJahr verschoben.

2. Spalte als "Foreign Key" zeigt auf unterschiedliche Tabellen.
Ich habe drei Tabellen: A1, A2 und B. B enhält eine Spalte 'FID' und eine Spalte 'FTBL'.
In FID steht eine ID drin. Wenn in FTBL der Wert 'A1' steht, dann ist die ID der PK von A1. Steht in FTBL 'A2', ist die ID der PK von A2.

(A1 und A2 sind also die unterschiedlichen Auftrags-Tabellen).

Ich glaube, der Designer hat (2) so umgesetzt, weil er sich mit (1) schon ins Knie geschossen hat.

Nun ist die Firma, die das gebaut hat, ziemlich groß und schon lange als recht guter Softwaredienstleister weltweit vertreten. Ich habe also Probleme, denen zu sagen, das ihr Design Schrott ist (ich mach das aber, wenn ich mir sicher bin).

Das System ist über die Jahre gewachsen (typisch). Aber die Verteilung von eigentlich kompatiblen Daten auf unterschiedliche Tabellen ist mutwillig und wird heute noch so praktiziert.

Ich frage mich also, was die Motivation für so ein Design sein könnte.

Weiterhin frage ich mich, gegen welche Norm bzw. Grundsätze (Stichwort: Normalform) dieses Design verstößt.

Für sachdienliche Hinweise wäre ich dankbar.

**mkinzler**

Zu 1.) Eine Trennung in Tabellen nach Jahren ist eigentlich unnötig, es herrscht aber oft die Vermutung, dass es schneller sei/wird wenn die Anzahl der DS geringer ist/man diese verringert.
Eine tabellarische Trennung nach Kundenarten(-erkunft) macht imho noch weniger Sinn ( höchstens man benötigt verschiedene Rechnungskreise).
Zu 2.) Wenn man schon 1. prakiziert sollte man das dann konsequent tun und auch die Detailtabellen trennen.

**jobo**

Ich geh mal davon aus, dass es bei den Problemen nicht um Mandantenverfahren handelt.

Trennung der Tabelle nach Kriterien (Jahr) wird allgemein als Partitionierung bezeichnet und vom RDBMS selbst durchgeführt, sofern es dazu in der Lage ist (die teure Option gekauft/lizensiert wurde)
Was Du schreibst ist also gewissermaßen Partitionierung für Arme. Ich halte es je nach Umständen/Historie des Produkts, etc. für legitim. Insbesondere, wenn es eine logische Schicht gibt (einfache Union Views), die für einen generellen Zugriff auch die Gesamtsicht liefern.
(Z.B. wenn das Datenvolumen in den Terrabytebereich geht, irgendwann kommt der Performanceunterschied, oder Produktivdaten, die sehr stark am Geschäftsjahr orientiert sind- und später uninteressant bzw eher DWH Charakter haben- ohne das ein DWH da ist)
Variable Relationen

Wenn es gut modelliert ist, finde ich auch das nicht "schlimm".
Beispiel "Adresse":
Nimm eine Firma (Standort, Produktion A, B, ..) und Personen, die in der Firma arbeiten. Alle haben Adressen. Nun kann man je nach Anforderung
a) die Firma gar nicht abbilden (außer im denormalisierten Firmennamen des MA- der immer wieder auftaucht)
b) Firma und Mitarbeiter identisch "modellieren" und in eine (juristische)PersonTabelle packen. Man spendiert noch ein paar entweder oder Spalten je nach Typ oder verschiedene 1:1 Tabellen, die spezifische Daten ausmodellieren
c) man verwendet von vornherein verschiedene Tabellen für Firmen und Mitarbeiterm, trotzdem haben beide eine Adresse (und Telefon und Email ... je nach Sicht)
Sowas macht man nach rei(f/ch)licher Überlegung und mit einer perfekten Absicherung im Backend. (siehe auch Dein eigener Beitrag zu ERP, btw: ich hab es mir noch nie angetan ein ORM Datenmodell eines komplexen Systems zu produzieren oder zu analysieren, vermutlich annotiert man sich tot, um etwas brauchbares hinzubekommen )

Ich finde sowas sogar so "brauchbar", dass ich eigentlich nur darauf warte, wann soetwas logisch von einem RDBMS unterstützt wird. (was wohl nie passieren wird)
Noch was:
Eine solche variierte Referenzierung kannst Du im Backend so wrappen, dass es niemand merkt, den es nichts angeht (Entwickler, Kunden).
Ob das gegen eine (wissenschaftliche) Norm verstößt, wäre mir ziemlich egal. Es geht doch darum, die Möglichkeiten eines Systems intelligent und effizient auszunutzen. Daran hindert mich höchstens der Kunde selbst.
Natürlich müssen solche Verfahren angemessen dokumentiert sein.

Ein weiterer Stichpunkt wäre noch Zugriffs / Rechtekonzept.
Falls ein RDBMS keine inhaltsorientieren Berechtigungskonzepte mitbringt, könnte es auch zu solchen "Lösungen" führen. Vorstellbar wäre z.B. eine Schmiergeldtabelle je nach Himmelsrichtung. Die darf natürlich nicht jeder bearbeiten oder sehen, etc. pp blabla

**Uwe Raabe**

Zitat von Furtbichler:

Nun ist die Firma, die das gebaut hat, ziemlich groß und schon lange als recht guter Softwaredienstleister weltweit vertreten. Ich habe also Probleme, denen zu sagen, das ihr Design Schrott ist (ich mach das aber, wenn ich mir sicher bin).

Vielleicht kannst du es ja anders anfangen und darum bitten, dir die Gründe für dieses Design zu erklären. Am besten gleich mit deinem Änderungsvorschlag mit der Bitte um Prüfung, ob das nicht irgendwelche Vorgaben verletzt, die dir vielleicht nicht bekannt sind. Manchmal ist es leichter einen Fehler einzuräumen als ihn zu rechtfertigen - insbesondere wenn der damals Verantwortliche womöglich jetzt gar nicht mehr im Unternehmen ist.

Es mag durchaus Gründe für dieses Design geben oder gegeben haben (kann ich mir zwar nicht vorstellen), aber es mag andere Lösungen dafür geben, die etwas geradliniger sind.

**joachimd**

Zitat von Uwe Raabe:

Es mag durchaus Gründe für dieses Design geben oder gegeben haben (kann ich mir zwar nicht vorstellen), aber es mag andere Lösungen dafür geben, die etwas geradliniger sind.

Vielleicht war es auch eine gewachsene Applikation, welche früher an DBF-Grenzen stieß (2GB bzw 4GB, je nach Treiber) - oder ein Entwickler, der solche Grenzen im Kopf hatte. Da wir DBF als natives Storage unterstützen, sehe ich das sehr oft

**Blup**

Gerade bei älteren Projekte waren zum Zeitpunkt des Entwurfs noch keine SQL-Datenbanken geplant.
Die Zugriffszeiten waren häufig direkt proportional der Menge der gespeicherten Daten in einer Tabelle.
Deshalb hatte es da durchaus Sinn ältere oder wenig gebrauchte Daten auszulagern.
Bei einem späteren Umstieg wird in der Regel kein Datenbankdesigner beauftragt, kostet ja alles erst einmal Zeit und Geld. Man verändert das Konzept nicht sondern verlagert nur die Daten. Damit spart man auch gleich den Aufwand die Abfragen im Programm zu optimieren. Solange die Software damit alle gestellten Anforderungen erfüllen kann, ist auch alles in Ordnung. Ist das nicht mehr der Fall, hat man natürlich das Problem dem Kunden klar zu machen, daß eine Weiterentwicklung nur mit einer relativ aufwendigen Änderung der Grundstrukur möglich ist.

- Analyse der vorhandenen Anwendungsfälle und Anwendungstest entwickeln
- neue Datenstruktur entwickeln
- Ersetzen der alten Tabellen durch DB-View und/oder DB-Procedure für alte Programmteile
- Konvertierung der Daten
- Testen

Zitat:

2. Spalte als "Foreign Key" zeigt auf unterschiedliche Tabellen.
Ich habe drei Tabellen: A1, A2 und B. B enhält eine Spalte 'FID' und eine Spalte 'FTBL'.
In FID steht eine ID drin. Wenn in FTBL der Wert 'A1' steht, dann ist die ID der PK von A1. Steht in FTBL 'A2', ist die ID der PK von A2.

Das hört sich eigentlich so an als währen A1 und A2 Rollen von B.
Dann ist die ID in A1, A2 und B Primärschlüssel, in A1 und A2 zusätzlich "Foreign Key" auf B.
B <- A1
B <- A2
Als Objektmodel:
- Das Objekt wird immer mit ID und den Eigenschaften der Basisklasse in B gespeichert.
- Für Ableitungen(A1) werden unter der selben ID in der Tabelle A1 die zusätzlichen Eigenschaften gespeichert
- Für Ableitungen(A2) werden unter der selben ID in der Tabelle A2 die zusätzlichen Eigenschaften gespeichert

**Sir Rufo**

Zitat von joachimd:

Zitat von Uwe Raabe:

Es mag durchaus Gründe für dieses Design geben oder gegeben haben (kann ich mir zwar nicht vorstellen), aber es mag andere Lösungen dafür geben, die etwas geradliniger sind.

Vielleicht war es auch eine gewachsene Applikation, welche früher an DBF-Grenzen stieß (2GB bzw 4GB, je nach Treiber) - oder ein Entwickler, der solche Grenzen im Kopf hatte. Da wir DBF als natives Storage unterstützen, sehe ich das sehr oft

Mir scheint es eher, als ob da nach der Planungs-/Entwicklungsphase noch ein Änderungswunsch hinzukam, der so fix auf dem kleinen Dienstweg gebastelt wurde. Sollte nix kosten nur eben tuten ...

**stalkingwolf**

Blup hat es auf den Punkt gebracht.
Wenn ein Programm schon mehr als 20 Jahre alt ist, aber funktioniert, dann wird die Logik samt Datenmodell übernommen. Sprich Dos->Windows BDE -> Windows SQL. Dann sieht die Datenstruktur vermutlich wie zu DOS Zeiten aus.
Es gibt ja immer die Theoretiker und dann die , welche praktisch damit arbeiten. Die Theoretiker philosophieren über neue Modelle und Arbeitswege, da haben die anderen das schon programmiert.
Es geht nämlich darum Geld zu verdienen. Und zwar jetzt und nicht in 12 Monaten, wo man vorher evtl schon Pleite ist. Und evtl bei der ganzen Umstrukturierung die Hälfte vergessen hat, oder weg lassen musste, weil es fertig werden muss.

Wenn man natürlich bei einem neuen Projekt das genau so macht, dann sollte man evtl den Job wechseln.

Ich habe schon unzählige Datenübernahmen aus Fremprojekten programmiert. Darunter auch schon aus MS Axapta. Bei einigen Datenmodellen kam man sich vor, als hätte jemand ne Doktorarbeit geschrieben und sich Nachts darauf einen runter... hat. Oder evtl wollte er zum Mond damit.
Sah irgendwie auch gut aus, aber um an die Daten zu kommen, hat man sich nen Wolf programmiert

**mkinzler**

Zitat:

Es gibt ja immer die Theoretiker und dann die , welche praktisch damit arbeiten. Die Theoretiker philosophieren über neue Modelle und Arbeitswege, da haben die anderen das schon programmiert.
Es geht nämlich darum Geld zu verdienen.

Das würde ich so nich grundsätzllich unterschreiben. Das mag grundsätzlich manchmal so gelten. In vielen Fällen lohnt es sich aber verschiedene Lösungen zu betrachten und dann abzuwägen, welcher besser ist. Oft lohnt sich ein wenig Mehraufwand jetzt um einen größeren Mehraufwand in der Zukunft zu vermeiden. zudem verhindern solche Strukturen Möglichkeiten neuer DBMS ( constraints usw.)

**Captnemo**

Einen ähnlichen Fall habe ich auch bei einem Kunden.

Seit Jahren läuft die Software mit Postgre-DB laut Softwarehersteller. Bei genauerer Betrachtung stellt sich dann aber heraus, das sämtliche Kundendaten und weitere Daten als CSV-Text-Dateien in einem Verzeichnis liegen und auch nur dort gehalten werden. Wie der genaue Zugriff darauf realisiert ist, kann ich nicht sagen. Jedoch sind in der Postgre-DB keinerlei Kundendaten zu finden.

Als ich dann mal bei einem Entwickler dieser Firma vorsichtig nachgefragt habe, sagte diese, dass das noch überbleibsel aus dem alten DOS-Programm wären. Und weil der Programmierer, der das damals entwickelt hat, schon sehr alt ist, aber auch noch zur Geschäftslietung gehört, will dieser nicht, dass das geändert wird. Eben weil er immer noch seine DOS-Programme schreibt, und der Zugriff im Hintergrund immer noch über diese Programme erfolgt. Mit "so'n neumodischen Kram" wie SQL-Server will der nix zu tun haben

Also, wenn der dann endlich mal in Rente geht, wird das wohl endlich verschwinden.

Also manchmal sind es einfach nur Querköpfe, die sowas verursachen.