logisches vs. physisches Datenmodell

[Benrath]

Kann mir da jemand genau den Zusammenhang bzw. den Unterschied erklären.

Also ich habe es so verstanden, dass das logische erst mal nur abstrakt alle Bezüge und Zusammenhänge darstellt und das physische dann die genaue Syntax für das Datenbanksystem darstellt. Soviel von Wikipedia.


Brauch ich das logische Datenbankmodell dann nur einmal am Anfang und sobald einmal ein physisches erstellt wurde, arbeite ich nur noch an dem Weiter, wenn z.B. neue Felder oder Blöck in meine DB sollen?

Macht es dann Sinn mir zu viele Gedanken zum logischen zu machen oder sollte ich dann nicht eher beim pysischen drauf achten, dass auch das rauskommt was ich mir vorgestellt hatte? Ob z.B. die alten Daten auch wirklich in die Datenbank passen?

 

[parats']

Logische Datemodelle beschreiben eigentlich Entitäten, Beziehungen und Attribute. Je genauer man dort arbeitet, desto eher erkennt man auch Fehler vor der Implementierung. Die Überführung in die physische Struktur ist dann ein Teil des physischen Datenmodells, allerdings kommen dann noch Aspekte wie bspw. Indizes zur Optimierung oder Regeln zur Datenintegrität etc pp.

Wenn Du ein Datenmodell von Grund auf entwirfst, macht es schon Sinn einmal vorher alles zu modellieren. Vor allem bekommt man ein Gefühl für seine Datenstrukturen.

Ob diese Reihenfolge konsequent befolgt werden sollte, hängt vom Umfang ab. Wir machen es hier nicht immer, einfach weil das Datewarehouse als ganzes Modell später richtiung molap, rolap uns tabular nochmal separieren und dort dann recht modular arbeiten. Relational ist das aber sinnlos bei 100+ Entitäten (+ 500-700 durch die tieferen Schichten) und 500TB Volumen.

 

[Benrath]

Ok ich schwanke halt ein bisschen gerade, ob sich das bei unserer Datenmenge so sehr gelohnt hat ein logisches Datenmodell zu erstellen oder ich einfach unsere Excel in die Datenbank geschmissen hätte und dann irgendwie verknüpft hätte.

Von einem Data Warehouse träume ich noch lange.

Was ist genau eine Entität für dich?

 

[parats']

Bezogen auf die Modellierung von Daten eindeutige Objekte wie Dimensionen (mit sub typen wie rel/bridge Tabellen, SCD1/SCD2 Konstrukten) und Fakten.
Am Ende sollten sich relational Referenzen zwischen Entitäten bilden lassen.

Ein Datawarehouse ist in vielen Fällen nicht des Rätsels Lösung, je nach Anforderung reichen einfache Silo-Lösungen.
Interessant wird es dann, wenn ein Unternehmen anfängt sein komplettes Berichtswesen soweit zu zentralisieren, dass es einen single point of truth gibt.

 

[Benrath]

wenn ihr jetzt jemand wärt der ein physisches Datenmodell von einem Berater abnehmen darf. Auf was würdet ihr besonders achten?

Ich glaub das logisches hatte jetzt so wie es war Sinn gemacht und wo möglich generelle Klasse definiert etc..
Mir ist halt noch unklar wie ich das physisches Modell validieren soll außer, dass meine Daten die jetzt in einer n x k Excel Matrix liegen auch ins Modell passen.

 

[parats']

Normalerweise müsstest ihr anfangen das Datenmodell zu füllen um die Erkenntnis zu erlangen, ob die Umsetzung bzw die Planung davor korrekt war.
Entwicklung am Reißbrett funktioniert nur bedingt, denn vieles hängt dann von der Ausgestaltung der Daten selbst ab und wie eben modelliert worden ist.
Ich behaupte mal frech, dass Datenmodelle selten im ersten Schritt zu 100% passen, dafür sind zu viele unbekannte Variablen vorhanden. Wichtig ist, dass man sich das Modell von Anfang an nicht verbaut und möglichst offen an die Aufgabe herangeht.


Vielleicht ein kleines Beispiel - es macht Sinn bei einer Attribuierung von Fakten auf eine Junk-Dimension (mittels Kreuzprodukt der Attribute) zu setzen, wenn beispielsweise Probleme mit dem Bufferlimit (ETL-seitig) vorliegen oder aber später auf eine multidimensionale Hierarchie (bspw mit MOLAP) gesetzt wird. Es gibt noch diverse andere Gründe, diese sind aber wohl am untechnischten und sowas ist dir bei der Reißbrettplanung nur bedingt klar.

 

[Benrath]

Nochmal zum pushen, weil ich irgendwie hinterfrage, was mein Berater als physisches Datenmodell designet hat.

Ich hab jetzt ein sehr komplexes verschachteltes Model aber alle Verknüpfungen laufen über generische IDs, obwohl ich eigentlich eine existierende Laufnummern (8 Stellen varchar ("02314234")) und das Jahr hätte, die zusammen unique wären.

Ich hab ne Haupttabelle und dort verweißt ein Foreignkey auf eine Nebentabelle.
z.B. FK_Personal und dann gibts ne Tabelle Peronal in der stehen 5 Spalten mit Beschäftigte, davon Teilzeit, etc.. (Das könnte man wohl auch noch mal mit ner Metatabelle normalisieren, in der die 5 Spalten stünden)

Das macht mir jetzt eigentlich mein Leben schwer, weil ich die Nebentabelle erstellen und dann auf die Werte in der Haupttabelle zurückmatchen muss.
Ich könnte aber eigentlich auch die Nebentabelle mit der Laufnummer und dem Jahr erstellen und dann passen Haupttabelle und Nebentabelle automatisch zusammen.

Setze ich dann immer noch nen Constraint von Haupt zu Nebentabelle oder umgekehrt? Ich würden dann ja eher einen Constraint setzen, dass der Eintrag in der Nebentabelle nicht existieren kann, wenn es die Kombo Laufnummer und Jahr nicht in der Haupttabelle gibt?

 

[parats']

Hast du das mal modelliert als Bild rumfliegen?

Wenn ich dich recht verstehe, willst Du deine Fakten um Informationen aus Dimensionen erweitern, richtig?
Wenn ja, dann bricht das die 2NF bzw die 3NF, je nach genauer Ausgestaltung.

Mit einem Bild vom Modell, könnte man das aber etwas besser verstehen.

 

[Benrath]

Hab mal was angehangen. Ist einfach nur ein einfaches Beispiel der Haupttabelle zur ner Folgetabelle in der der weitere Infos stehen. Die sind über den FK "vermoegensituation_id" verbunden. Hm sehe gerade, dass die Übertabelle fehlt. Die "Unternehemensarten" Tabellen ist noch über "unternehmen_id" mit der Unternehmenstabelle verbunden und da steht eine bsnr und Jahr variable, die ich an sich überall stehen haben könnte.

Ich mach noch mal ein besseres Bild morgen.

https://ibb.co/T2wPjX4

 

[parats']

Besteht zwischen der Unternehmensart und dem Unternehmen eine 1:1 Beziehung?
BSNR + Jahr ist nicht das Primärattribut deiner Tabellen wie bspw. Vermögenssituation. Ich nehme aber mal an, dass Unternehmensarten.id dein künstlicher Schlüssel aus BSNR + Jahr ist?
Ansonsten hilft das big picture, also mehr Informationen zum Modell und konkretes Problem.

p.s. Überlegt euch mal einen einheitlichen Standard bei der Benennung von Spalten (bspw. Singular, CamelCase, komplette Spaltennamen zum referenzieren).

 

[Benrath]

Es gibt Unternehmen mit BSNR + Jahr

und jedes Unternehmen kann im Jahr mehrere Betreiber_Typen einnehmen. Daher verweist die "unternehmen_id" auf die Unternehmens Tabelle.

Kann auch zwei größere Bilder von Stammdaten und dem Rest posten. Ist an sich nicht geheim.

Die Spaltennamen kamen vom Berater, da hatten wir nichts überlegt. Wir tendieren wohl zu alles klein, ohne Sonderzeichen und mit _ getrennt.

 

[parats']

Was genau ist denn dein Problem? Geht es noch um :

Das macht mir jetzt eigentlich mein Leben schwer, weil ich die Nebentabelle erstellen und dann auf die Werte in der Haupttabelle zurückmatchen muss.
Ich könnte aber eigentlich auch die Nebentabelle mit der Laufnummer und dem Jahr erstellen und dann passen Haupttabelle und Nebentabelle automatisch zusammen.

Ist die Nebentabelle in diesem Fall vermoegenssituationen? Ich versuche erstmal zu verstehen was genau jetzt ein Problem aufwirft, denn es besteht auch die Möglichkeit das dieses prinzipiell kein Problem ist, da das befüllen der Tabellen per ETL-Prozess inhärente Vorgänge impliziert um die Datenintegrität zu gewährleisten.

Wie ihr da Standards definiert, das ist eure Sache. Man muss sich nur comitten und das durchziehen. Generell ist der plural aber bspw. mega unüblich und wenn, dann muss er durchgezogen werden - z.B. die Tabelle vermoegenssituationen -> vermoegenssituation_id (aus deinem Beispiel) wäre ein Bruch dieser Norm. Datentypen wären ein anderes Thema - gerade die Auswahl von bspw char und nchar (wahlweise mit var dazu) kann bei entsprechender Zeichensatzwahl (Stichwort Unicode) später ungewollte Probleme aufwerfen.
Wir verwenden bspw. neben der Integer-Palette nur NVarChar (mindestlänge 5 für <N/A> anstelle von NULL) und Decimal. Den Rest braucht ehrlich gesagt kein Mensch im realen Anwendungsfall.

 

[Benrath]

Zu Erinnerung, dass Datenmodell bildet Fragebögen an Unternehmen ab.

Mein Problem ist eher dass ich beim importieren der Altdaten ziehmlich viel hin und her matchen muss, obwohl ich eigentlich einen unique key überall in den Daten habe. Eine Berichtstellennummer (bsnr) und ein Jahr. Dadurch, dass mein Berater aber immer über generische ids verknüpft, muss ich die immer erst ersetzen und Tabellen hierarisch erstellen, weil sonst die FK Constraints nicht erfüllt sind.

Es gibt eine Liste von Unternehmen mit bsnr und Jahr und deren id die mit der Tabelle unternehmesarten verbunden ist in der für jeden betreiber_typ ein Eintrag stehen kann. Unternehmen X kann z.B. in den Jahren 2015-2018 und jeweils 3 Betreiberarten geantwortet haben.



Daher ist hier schon die Frage warum ich in Unternehmesarten so dringend eine eigene id als PK brauche, wenn ich auch einfach weiter bsnr und Jahr nehmen könnte und den betreiber_typ hinzunehmen, damit ich weiter nen unique identifier habe.



Das setzt sich hier dann fort. Ich hab jetzt Leistungsdaten, die nach Verkehrsart, Leistungsart, Beauftragungsart differenziert sind und über unternehmensart_id zurück auf die Unternehmensarten Tabelle verweisen. Wenn ich da weider bsnr, Jahr und betreiber_typ hätte, bräuchte ich keine anderen Ids, oder?

das geht dann in den Folgetabellen weiter, dass die auch wieder auf die evu_leistungen zurückverweisen müssen etc. Ich hab das zwar jetzt gelöst und merge munter hin und her, aber k.a. ob das dauerhaft so eine gute Idee ist.

Ich hatte das halt nicht so hart hinterfragt, weil der Berater dass so gemacht hat und ich eigentlich gar nicht aus der Datenbank Design welt komme.



https://ibb.co/TPkGs2W


https://ibb.co/dBQ79cf

 

[parats']

Wieso der Berater einen eigenen PK wählt statt eines natürlichen Schlüssel über 3 Spalten ist mir so ad hoc auch nicht ganz klar.
Ich kenne Konstrukte da konsolidiert man gerne in einen einzelnen Schlüssel aus unterschiedlichen Detailstufen auf das kleinste Element, das macht man aber eher bei zig verschiedenen Quellsystemen - Beispielsweise bei Kundenstammdaten (üblicherweise im B2B Bereich). Da ist es bequem mit dem _einen_ Schlüssel zu referenzieren, weil sämtliche Logik innerhalb des Datenmodells der Kundenstammdaten ermittelt wird und am Ende die Wahrheit entsteht.
kommst Du denn im Bereich "End Branch" noch an die drei Spalten ran, oder sind die im Zuge der PK Wandlung weggefallen (wenn ich den linken constraint von avu_leistungen korrekt lese, ist dort die Entität "unternehmensarten")?

 

[Benrath]

Ich komm nur über Umwege an die unternehmsarten_id die evu_leistungen mit unternehmsarten verknüpft.

Ich erstell mir die Tabelle mit den alten Daten und da steht die bsnr und das Jahr drin. Darüber bekomme ich die unternehmen_id und die id aus der unternehmensarten Tabelle, die mir dann unternehmensarten_id für die evu_leistungen Tabelle gibt.

Für die Tabellen noch eins teifer wie evu_leistungen_infra, mach ich es ähnlich mit einem Schritt mehr.


Das Projekt steht eh gerade etwas auf Hold und der Dienstleister der die Webformulare für die Befragung programmieren soll, muss das Datenmodell am Ende noch mal prüfen. Mal gucken, was die sagen, ob ihnen der "natürliche" Schlüssel lieber ist. Wenn ich einfach den natürlichen Schlüsse nutzen würde, müsste ich weniger Sachen in die DB schieben oder wieder auslesen um die IDs zu bekommen. Wahrscheinlich müsste ich nur die Metatabellen aus der DB ziehen und das wäre ok.