One true lookup table

Bei OTLT oder One true lookup table handelt es sich um ein Verfahren, welches zunächst die Anzahl Tabellen eines DB-Schemas und damit den Aktualisierungsaufwand reduzieren soll. Dazu wird eine Tabelle angelegt, die neben dem Bezeichner und typischerweise einem Surrogatschlüssel eine Domäne (Fachbereich) aufweist. Anstatt nun eine eigens dafür angelegte Tabelle zu referenzieren, wird einfach der Schlüssel einer für die aktuelle Entität vorgesehene Domäne angesprochen.

Ansatt einer weiteren Tabelle, welche nur die infrage kommenden Entitäten enthält, wird in der Anwendungslogik auf die zutreffende Domäne diskriminiert.

Fig. 1 - Standardumsetzung

In der einfachsten Umsetzungsvariante (vgl. Fig. 1) wird bei einer 1:n-Relation direkt der Surrogatschlüssel der Lookup-Tabelle referenziert. Das sieht zunächst sehr elegant aus, weshalb sich der OTLT-Ansatz grosser Beliebtheit erfreut. Bei genauerer Betrachtung fällt indes auf, dass ein wesentliches Alleinstellungsmerkmal von relationalen Datenbanken damit ausgehebelt wird. Ein RDBMS soll die Datenintegrität sicherstellen. Bei der einfachsten Umsetzung überlassen wir das nun der nutzenden Anwendung, da die erforderliche Einschränkung auf die zutreffende Domäne nur der Anwendung möglich ist. Unter der Voraussetzung, dass...

  1. aktuell und künftig ausschliesslich die eine zurzeit bekannte Anwendung pflegend (also mit Update-, Insert- und Delete-Statements) auf die Lookup-Tabelle zugreift und
  2. diese Anwendung absolut fehlerfrei ist (also keinen einzigen Bug aufweist)

..kann dieser Ansatz als sicher gelten und gefährdet die Datenintegrität nicht. Die erste Bedingung ist selten erfüllt und die zweit nie. ist Integriätserhalt wichtig, dann fällt diese Art der Umsetzung ausser Betracht.

Um wenigsten Datenintegriät sicherstellen zu können, müssen wir diesen Ansatz etwas ausweiten und folgende Anpassungen vornehmen (vgl. dazu Fig. 2):

  1. Zunächst müssen wir in der Lookup-Tabelle neben dem Surrogatschlüssel die Referenzierung der Lookup-Domäne als Primärschlüssel aufnehmen und erhalten damit einen zusammengesetzten Schlüssel. Der Bezeichner, der zusammen mit der Domäne Schlüsselkandidat ist, vewenden wir dazu mit Vorteil nicht, da sonst eine spätere Anpassung nicht mehr ohne Weiteres möglich ist.
  2. Durch die Referenzierung eines zusammengsetzten Schlüssels besteht nun freilich auch der Fremdschlüssel aus zwei Werten. Nämlich der referenzierten Entität sowie deren Domäne.
Fig. 2 - Ideale Umsetzung

Jetzt ist allerdings immer noch möglich, dass für ein Merkmal, welches die Domäne A referenzieren soll, durch die Anwendung eine Entität der Domäne B gesetzt wird. Was normalerweise durch die Relationsbildung sichergestellt ist, müssen wir an dieser Stelle mit einem weiteren Constraint erzwingen. Und zwar muss - abhängig davon, ob ein Not-Null-Constraint durchgesetzt werden soll - der Wert des Teilschlüssels LOOKUP_DOMAIN_LOOKUP_TABLE entweder Null sein, wenn auch der Wert von LOOKUP_TABLE_ID Null ist oder - im anderen Fall - muss der Wert genau dem Schlüssel der vorgesehen Domäne entsprechen.

Damit wäre dann der Datenintegrität Genüge getan. Allerdings haben wir gleichzeitig alle scheinbaren Vorteile der One-true-lookup-table wieder zunichte gemacht. Die Umsetzung ist wesentllich komplexer als die Erstellung einzelner Lookup-Tablellen, wir haben zwei Schlüssel anstatt einen und wir haben einen zusätzlichen Check-Constraint zu etablieren.

Wir haben bei dieser Umsetzung immer noch den scheinbaren Vorteil, dass nur eine Tabelle gepflegt werden. Dieser Vorteil ist jedoch aus zwei Gründen nicht sehr gross:

  1. Viele Lookup-Tabellen enthalten Daten, die kaum je der Pflege bedürfen. Ein Status zum Beispiel, dem in einer Anwendung eine bestimmte Bedeutung zukommt, kann nicht ohne Weiteres entfernt, aktualisiert oder durch weitere Stati ergänzt werden. Die Zahl der zu pflegenden Tabellen ist ohnehin geringer, als die insgesamt auftretende Anzahl Tabellen.
  2. Die zentrale Pflege ist ohne Weiteres auch mit mehreren Tabellen möglich. Zum Beispiel indem eine aktualisierbare View die betroffenen Tabellen zusammenfasst.

Auch bei idealer Umsetzung in Bezug auf den Integritätserhalt ist eine OTLT-Umsetzung wenig interessant. Da sie notwendigerweise mehr Einträge enthält als eine einzelne ansonsten anzulegende Lookup-Tabelle (genau genommen eben die Summe aller Entitäten in allen Lookup-Tabellen) wird ein Join auf diese Tabelle ein grösseres Produkt erwirken, als es bei der Anwendung einfacher Lookup-Tabellen der Fall wäre.

Insgesamt haben wir eine Situation vorliegen, in welcher der OTLT-Ansatz bei genauerer Betrachtung ausschliesslich Nachteile mit sich bringt:

  1. Entweder ist die Datenintegrität gefährdet, weil die referentielle Integrität nicht hinreichend sichergestellt ist oder
  2. die Umsetzung ist durch die Verwendung eines zusammengesetzten Schlüssels und zusätzlich benötigter Check-Constraint erheblich komplexer
  3. und last not least leidet die Leistung der Datenbank darunter, dass die OTL-Tabelle ein Vielfaches an Entitäten enthält, als das bei einfachen Lookup-Tabeles der Fall wäre.

Der einzige damit einhergehende scheinbare Gewinn lässt sich auch ohne OTLT sehr einfach realisieren. Das Fazit dürfte also sein, dass man diesen Ansatz mit Vorteil nie anwendet.

Weiterführende Links

Ticker

03.01.12  -  Die Pause ist vorüber und wir sind mit neuem Tatendrang wieder an der Arbeit. Willkommen im 2012!

23.12.11  -  Wir wünschen allen frohe Festtage und einen guten Rutsch ins Neue Jahr!