Tabellen durch Entity-Attribute-Values dynamisieren

Tabellen durch Entity-Attribute-Values dynamisieren
Page content

Dieser Artikel behandelt die Grundlagen von Entity-Attribute-Values. Mit Hilfe dieser Tabellen können Datensätze dynamisch erweiter werden.

Aufbau und Struktur

Entity-Attribute-Values (im Folgenden EAV) sind im Prinzip Key-Value-Tabellen, die mit einer bestehenden Tabelle verknüpft sind. Hierdurch lassen sich zu einzelnen Datensätzen weitere Eigenschaften ergänzen.

Gehen wir davon aus, wir haben eine einfache Personen-Tabelle:

Tabelle 1: Personen

ID Vorname Nachname
1 Max Müller

In dieser Tabelle sind nur bestimmte Felder vorhanden. Aufgrund der Übersichtlichkeit habe ich Elemente wie Adresse etc. gekürzt. Ein EAV sieht folgendermaßen aus:

Tabelle 2: Personen_EAV

ID PersonID Schlüssel Wert
1 1 Augenfarbe blau
2 1 Größe 1,80 m
3 1 Gewicht 75 kg

Die ID ist der eindeutige Datensatz in der Ergänzungstabelle. PersonID ist die Verknüpfung zum originalen Datensatz. Schlüssel stellt den Namen der Eigenschaft dar und Wert ist die Ausprägung.

In diesem Beispiel wird Max Müller um die Eigenschaften Augenfarbe, Körpergröße und Gewicht ergänzt.

Sinn und Zweck

Bisher kenne ich diese Tabellen nur aus dem medizinischen Bereich. Es gibt viele Eigenschaften, die bei einem Arztbesuch oder Krankheitsfall wichtig sein können. Nennen wir einfach mal die Temperatur (bei Fiber) oder Husten.

In anderen Fällen ist eventuell der Puls wichtig und das Körpergewicht.

Gäbe es eine Tabelle mit zig Spalten (Temperatur, Husten vorhanden, Art von Husten, Puls, Körpergewicht..) würde in den meisten davon der Wert „NULL“ stehen. Ein Arzt kann entscheiden, welche Werte für den jetzigen Patienten wichtig sind.

Auf der anderen Seite können Benutzer Datensätze um spezifische Eigenschaften erweitern, wie in oberen Beispiel gezeigt.

Verbesserungen

In oberem Beispiel gibt es ein Problem mit dem Schlüssel. Dieser ist eine Zeichenkette und kann ggfs. Tippfehler aufweisen. Zudem ist auch eine Lokalisierung in andere Sprachen nur schwer möglich. Es ist auch keine Prüfung auf den Typ des Wertes möglich. Diese Einschränkungen lassen sich durch eine weitere Tabelle ergänzen. Diese Tabelle definiert die Typen der EAV.

Tabelle 3: Personen_EAV_Definition

ID Schlüssel AnzeigeSchlüssel Typ Einheit
1 Augenfarbe RES_EYE_COLOR color
2 Körpergröße RES_SIZE float meter
3 Weight RES_WEIGTH float kg

Tabelle 4: Personen_EAV (Aktualisiert)

ID PersonID PersonEAVID Value
1 1 1 blau
2 1 2 1,80
3 1 3 75

Tabelle 3 definiert den jeweiligen Datentyp. Der Einfachheit halber habe ich diese Tabelle auf Schlüssel, AnzeigeSchlüssel, Typ und Einheit begrenzt.

Der Schlüssel ist nur ein lesbarer Wert während der Entwicklung oder wenn in die Datenbank geschaut wird. Hier könnte auch eine Beschreibung oder ähnliches enthalten sein. AnzeigeSchlüssel ist ein Platzhalter für die Anwendung. Der Wert RES_EYE_COLOR kann durch Augenfarbe (deutsch) oder eye color (englisch) aufgelöst werden. Hiermit wäre eine Lokalisierung möglich.

Durch die Spalten Typ und Einheit kann die Anwendung die Eingabedaten prüfen. Beispielsweise sind bei einem float (Fließkommazahl) keine Buchstaben erlaubt. Die Anwendung könnte in diesem Falle eine Fehlermeldung ausgeben.

Fazit

EAVs bieten eine schöne Möglichkeit, Tabellen „schmal“ zu halten und viele NULL-Felder zu vermeiden. Auf der anderen Seite erhöhen Sie die Komplexität aufgrund der zusätzlichen Verknüpfung. Habt ihr schon mit EAVs gearbeitet und wie steht ihr dazu?