Tabellen durch Entity-Attribute-Values dynamisieren
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?