Attribut mit mehreren Datentypen

[Dr.Schlumpf]

Hallo zusammen,

ich entwerfe gerade eine Datenbank (zum ersten Mal) für eine große jährliche Unternehmensbefragung. Kurz ein paar Worte zum Projekt: Es wird einmal im Jahr ein Fragebogen an Unternehmen geschickt. Die darin abgefragten Informationen / Daten sind (über ein Anwendung) in einer Oracle-DB zu erfassen und auch später zu korrigieren, anzufragen und auszuwerten. Ein Unternehmen beantwortet nicht immer alle Fragen. In der Regel werden jedes Jahr ein paar Informationen / Fragen / Daten durch neue ausgetauscht. Die abgefragten Daten sind von unterschiedlichen Datentypen, hauptsächlich Zahlen (numbers), aber auch Strings (char, varchars), Dates und Booleans. Meine Frage ist nun, wie ich das sinnvoll modelliere. Meine Idee bisher:

• eine Tabelle, die alle Variablen (inkl. Datentyp) enthält, die in einem Fragebogen vorkommen können:
  fbvar(id, bezeichnung, Beschreibung, datentyp)
• eine Tabelle, die den Eingang eines Fragebogen eines Unternehmens erfasst:
  fbeingang(id,id_unt,datum)
  mit id_unt als FK zum Tabelle unternehmen
• eine Tabelle mit den Werten der Variablen, die ein Unternehmen zurückliefert:
  fbeingang_fbvar(id, id_fbvar, id_fbeingang, value)
  mit id_fbvar als FK zur Tabelle fbvar, id_fbeingang als FK zur Tabelle fbeingang und value als der zurückgelieferte Wert

Der Vorteil dieser Lösung ist m.E., dass man (1) jederzeit neue Variablen in die Tabelle fbvar einfügen kann und (2) für die Variablen, die ein Unternehmen nicht beantwortet hat, keine NULL-Werte in der Tabelle fbeingang_fbvar hat. Das Problem, vor dem ich nun stehe, ist, dass für die Spalte/das Attribut value in der Tabelle fbeingang_fbvar nicht ein fester Datentyp vergeben werden kann, da die Variablen aus fbvar ja unterschiedliche Datentypen haben. In meiner bisherige Recherche bin ich auf zwei Lösungsmöglichkeiten gestoßen:

1. Für jeden Datentyp eine eigene fbeingang_fbvar Tabelle, also z.B. fbeingang_fbvar_char, fbeingang_fbvar_num, ...
2. Datentyp ANYTYPE für die Spalte value

Leider sind mit die Vor- und Nachteile dieser beiden Optionen nicht so ganz klar bzw. ob es noch weitere Optionen gibt bzw. wie praktikabel sie im Umgang mit Datenerfassung, - abfragen und -auswertungen sind.

Ich würde mich freue, wenn mir jemand bei der Lösung meines Problem helfen könnte und vielleicht aus seiner Erfahrung etc. berichten könnte, wie er / sie so etwas löst (ich hoffe, ich konnte mein Problem klar genug beschrieben ;-)).

Vielen Dank schon einmal für eure Mühe!

 

[akretschmer]

etwas ähnlich zu Deiner Frage war ein Vortrag zur diesjährigen deutschen PostgreSQL-Konferenz von meinem geschätzten Freund aus der Schweiz, Charles Clavadetscher.
Conference Schedule - PGConf.DE 2019 - PostgreSQL Europe

Vielleicht helfen Dir die Slides, vielleicht magst Du den Autor kontaktieren. Falls ja: liebe Grüße von mir ;-)

 

[ukulele]

Du nutzt EAV
Entity–attribute–value model - Wikipedia
Das kann man durchaus machen. Ich würde nicht pro Datentyp eine eigene Tabelle machen, das scheint mir unnötig, zumal du den Datentypen ja in einer anderen Tabelle definierst. Du könntest die Daten verifizieren, z.B. per Trigger aber von wievielen Daten reden wir denn? Das scheint mir mit einer einfachen Prüfung der Daten vor der Auswertung getan.

 

[akretschmer]

Yeah. Die gute, alte EAV.

Mit der Zeit etwas angestaubt. Modernere Lösungen sind Key-Value-Stores wie die hstore-Extension von PostgreSQL (PostgreSQL: Documentation: 11: F.16. hstore), oder, und mehr hipp heutzutage und dazu auch strukturiert, JSON-Dokumente, in der PostgreSQL-Welt als JSONB zu bevorzugen : JSONB Archives - 2ndQuadrant | PostgreSQL

 

[Dr.Schlumpf]

Danke für die hilfreichen Antworten, Anmerkungen und Links ... jetzt habe ich endlichen eine Namen für das Kind und weitere Ansatzpunkte zum Einlesen.
Ein Frage noch zum EAV (mit JSON kenne ich mich noch gar nicht aus und muss mich erst noch einlesen). Ist dann die value-Spalte vom Typ varchar und den "echten" Typ bzw. die Typumwandlung bekomme ich dann über den Eintrag in der datentyp-Spalte in der Tabelle fbvar oder würde sich eher der Datentyp ANYTYPE anbieten.

 

[ukulele]

Also im Prinzip verzichtest du auf die Einhaltung eines Datentypen. Natürlich brauchst du ein Feld das die Werte aufnehmen kann, da würden sich z.B. VARCHAR oder NVWARCHAR anbieten. Wenn du nur numerische Werte hast gingen auch andere Typen. ANYTYPE ist mir nicht geläufig, das ist wohl eher datenbankspezifisch.

Die Prüfung auf valide Daten musst du dann "manuell" durchführen. Also entweder bei der Eingabe in der Anwendung prüfen oder über ein Trigger in der DB oder später bevor du eine Auswertung machst. In jedem Fall musst du Code schreiben der prüft, ob die Daten korrekt formatiert sind.

 

[Dr.Schlumpf]

Danke und okay verstanden und ja, ANYTYPE ist wohl Oracle-spezifisch.

Jetzt habe ich das mal mit EAV und / oder Json weitergespielt. Dabei kam - wie soll es anders bei Anfängern auch sein - natürlich direkt die nächste Frage auf, die sich in diesem Zusammenhang stellt. ;-) Die Daten, die letztendlich in der oben genannten Struktur gespeichert werden sollen, kommen derzeit in einem Excelformat mit der klassischen Spalten-Form an:

id | ausfuelldatum | var1 | var2 | var3 | var4 | ...
-----------------------------------------------------------------------------
1 | 1.1.18 | 10 | ja | 2100,43 | Dienstleistungen | ...
2 | 10.1.18 | 15 | ja | 314 | Steine | ...
...

, d.h. die Variablen stehen nebeneinander und die Unternehmen untereinander. Um die Daten in meine EAV-DB-Tabellen bzw. in JSON-Form zu bekommen, muss ich sie ja irgendwie transponieren. Mach ich das sinnvollerweise über die Anwendung, in dem ich die Daten zeilenweise auslese und dann nacheinander und untereinander in die entsprechende Tabelle schreibe oder gibt es auch direkt einen Importbefehl, der diese Arbeit abnimmt oder erleichtert?

 

[ukulele]

Also der Import von Daten ist natürlich erstmal unterschiedlich je nach verwendetem DBMS. Du schreibst was von Oracle, da kenne ich mich nicht aus. Du kannst das also möglicherweise mit deiner Anwendung oder einem Import-Tool von Oracle machen.

In SQL ginge es grundsätzlich auch. Dazu wären drei Faktoren wichtig:
a) Ist das Format immer das selbe oder variieren die Daten, wenn auch nur in der Reihenfolge?
b) Kommen weitere Spalten hinzu?
c) Wieviele Spalten sind betroffen?

In den meisten Fällen würde ich sagen man baut sich das händlich passend in ein SQL Statement.

 

[Dr.Schlumpf]

Danke für Eure Hilfe! Ich denke, ich habe mein Problem jetzt mit eurer Hilfe zufriedenstellend lösen können