Benutzer:Panicp/COIN Datenmodelle

COIN-Datenmodelle (von engl. COlumn INdependent, spaltenunabhängig) ordnen Informationen Angaben in weiteren Spalten zu und erweitern somit das Key/Value-Modell um eine informationsbasierte Dimension. COIN-Datenmodelle unterscheiden sich somit von zeilen- oder spaltenorientierten Datenmodellen durch die Zuordnung von Informationen. Sämtliche Informationen werden vertikal abgelegt und mithilfe von Werten in weiteren schlüsselgebenden Spalten strukturell logisch zugeordnet. Tupelbildende Tabellenschemata werden in COIN-Datenmodellen nicht durch physisch vorhandene Tabellen definiert, sondern leiten sich aus Werten der schlüsselgebenden Spalten von informationshaltenden Tabellen sowie Zuordnungen ab.

einfache Tabelle eines COIN Datenmodells

Schlüssel		Wert
Datensatzkennung	Spaltenkennung	Wert
1	Landname	Vereinigte Staaten von Amerika
1	Kontinentname	Nordamerika
2	Landname	Schweiz
2	Kontinentname	Europa

Vorteile

Identische Struktur aller informationshaltenden Tabellen

Da sämtliche informationshaltenden Tabellen dieselbe Struktur besitzen, können Abfragen generisch formuliert werden. Da sämtliche informationshaltenden Tabellen dieselbe Struktur besitzen, können Abfragen generisch formuliert werden. Dadurch können die Entwicklungszeit von Anwendungen und die Fehleranfälligkeit bei Abfragen deutlich gesenkt werden.

Unterschiedliche Datenstrukturen in einer Tabelle

Während in herkömmlichen relationalen Datenmodellen für weitere Wertestrukturen neue Tabellen erstellt werden müssen, können Werte für unterschiedliche Datenstrukturen in COIN Datenmodellen in der gleichen Tabelle gehalten werden:

unterschiedliche Datenstrukturen innerhalb einer Tabelle

Schlüssel		Wert
Datensatzkennung	Spaltenkennung	Wert
1	Landname	Vereinigte Staaten von Amerika
1	Kontinent	1
2	Landname	Schweiz
2	Kontinent	2
1	Kontinentname	Nordamerika
2	Kontinentname	Europa

Werte für unterschiedliche Datenstrukturen in der gleichen Tabelle: Die Datensatzkennung 1 der Spaltenkennung „Kontinentname“ wird als Wert der Datensatzkennung 1 der Spaltenkennung „Kontinent“ abgelegt.

Schlüsselerweiternde Spalten

Lediglich durch die Einführung schlüsselerweiternde Spalten können Datenstrukturen erweitert werden. Z.B. für sprachsensitive Werte:

Strukturerweiterung durch schlüsselerweiternde Spalten, Beispiel sprachsenstivie Werte:

Schlüssel			Wert
Datensatzkennung	Spaltenkennung	Sprachkennung	Wert
1	Landname	1	Vereinigte Staaten von Amerika
1	Landname	2	United Stated Of America
2	Landname	1	Schweiz
2	Landname	2	Switzerland
1	Name der Sprache	1	deutsch
1	Name der Sprache	2	german
2	Name der Sprache	1	englisch
2	Name der Sprache	2	english

Abbildung sprachsensitiver Informationen: Die Datensatzkennungen der Spaltenkennung „Name der Sprache“ wird als Sprachkennung der Datensatzkennung der Spaltenkennung „Landname“ abgelegt. Der Wert ist nun abhängig von der Sprachkennung. In diesem Fall gilt das auch für den Namen der Sprache.

Dies gilt analog z.B. auch für die Verwaltung von Mehrfachantworten:

Strukturerweiterung durch schlüsselerweiternde Spalten, Beispiel Mehrfachantworten:

Schlüssel			Wert
Datensatzkennung	Spaltenkennung	Antwortkennung	Wert
1	Landname	NULL	Schweiz
1	Sprache	1	NULL
1	Sprache	2	NULL
1	Sprache	3	NULL
1	Sprache	4	NULL
1	Sprachenname	NULL	deutsch
2	Sprachenname	NULL	französisch
3	Sprachenname	NULL	italienisch
4	Sprachenname	NULL	rätoromanisch

Abbildung Mehrfachantworten für eine Spalte: Die Datensatzkennungen 1,2,3,4 der Spaltenkennung Sprachenname werden als Antwortkennung der Datensatzkennung 1 der Spaltenkennung „Sprache“ abgelegt. Hieraus ist abzuleiten, dass in der Schweiz diese vier Sprachen gesprochen werden: deutsch, französisch, italienisch und rätoromanisch.

Informationsbasierte Metadaten

Da alle Werte untereinander abgebildet werden, steht die horizontale Dimension der physisch vorhandenen Tabellen für weitere informationsbasierte Werte zur Verfügung. COIN-Datenmodelle erlauben somit die Verwaltung von Metadaten pro Information und nicht nur pro Datensatz. Beispiele hierfür wären die Gültigkeitsdauer einer Information, den aktuellen Besitzer, das letzte Bearbeitungsdatum oder den Aktivitätsstatus einer Information:

Informationsbasierte Metadaten:

Schlüssel			Wert	Metainformation n
Datensatzkennung	Spaltenkennung	Sprachkennung	Wert	Besitzer
1	Kontinent	NULL	1	1
1	Landname	1	Vereinigte Staaten von Amerika	2
1	Landname	2	United Stated Of America	2

Informationsbasierte Metadaten: Der Wert der Spaltenkennung „Kontinent“ von Datensatzkennung 1 ist im Besitz von Besitzer 1, die Werte der Spaltenkennung „Landname“ von Besitzer 2. Dieser Fall zeigt, dass COIN-Datenmodelle eine simultane Bearbeitung von Werten unterschiedlicher Spaltenkennungen durch unterschiedliche Nutzer ohne die Gefahr von Transaktionskolisionen ermöglichen.

Benutzerdefinierte Spaltenattribute

Die Abkopplung der logischen Tabellenschemata von den physischen Tabellen ermöglicht die gleiche Verwaltung auch für die logischen Spalten. Der Name einer Spalte ist daher nur eines von beliebigen Attibuten. COIN-Datenmodelle ermöglichen auf diese Weise aber die Nutzung von benutzerdefinierten Attributen. Beispielhaft lassen sich so

• regulärerer Ausdruck, mit dem alle Werte einer Spalte übereinstimmen müssen,
• Maximal- oder Minimalanzahl von Zeichen,
• Maximal- oder Minimalwerte z.B. für Integerwerte,
• die automatische Eintragung von bestimmten Werten (z.B. aktueller Zeitstempel),
• nur Groß- oder Kleinbuchstaben,
• Datumsformat,
• Anzahl von Dezimalstellen, etc.

pro Spalte festlegen. Selbst Attribute von Attributen werden auf diese Weise ermöglicht, sodass beispielsweise die sprachsensitiven Werte des Spaltennamens auf die gleiche Weise abgelegt werden können. Dabei werden zunächst Attributwerte definiert. Diese sind Eigenschaften der Attribute selbst. Beispielsweise der Name des Attributs, oder ob das Attribut sprachsensitiv sein kann:

Attributwerte

Schlüssel		Wert
Attributwertkennung	Sprachkennung	Wert
1	1	Attributname
1	2	Attribute Name
2	NULL	Sprachsensitivität

In diesem Fall wird definiert, dass ein Spaltenattribut "Attributname" sprachsensitiv ist.

Danach werden die Spaltenattribute definiert:

Spaltenattribute

Schlüssel			Wert
Attributkennung	Attributwertkennung	Sprachkennung	Wert
1	1	1	Spaltenname
1	1	2	Column Name
1	2	NULL	TRUE
2	1	1	regulärer Ausdruck
2	1	2	Regular Expression
2	2	NULL	FALSE
3	1	1	Sprachsensitivität
3	1	2	Language Sensitivity
3	2	NULL	FALSE

In diesem Fall werden die Attribute "Spaltenname", "regulärer Ausdruck" und "Sprachsensitivität" definiert, die nun für eine Spaltendefinition verwendet werden können. Das Attribut "Spaltenname" ist sprachsensitiv (Zeile 3, Wert "TRUE"), die anderen beiden nicht. Auch der das Attribut "regulärer Ausdruck" könnte mithilfe des Wertes "TRUE" in Zeile 6 sprachsensitiv werden, sodass Werte in unterschiedlichen Sprachen auch unterschiedlichen regulären Ausdrücken entsprechen müssten.

Um eine Wiederverwendung der Attribute zu ermöglichen, werden den Spalten nun zugehörige Attributwerte zugeordnet:

Spalten - Attribute Matrix

Spaltenkennung	Attributkennung
1	1
1	2
1	3

In diesem Fall besitzt Spalte 1 die Attribute 1, 2 und 3, also ("Spaltenname", "regulärer Ausdruck" und "Sprachsensitivität").

Dann wird eine Spalte mit Werten für die zugeordneten Attribute definiert:

Spalten

Schlüssel			Wert
Spaltenkennung	Spaltenattributkennung	Sprachkennung	Wert
1	1	1	Landname
1	1	2	Country Name
1	2	NULL	[A-Za-z]*
1	3	NULL	TRUE

Das Attribut "Spaltenname" ist sprachsensitiv, daher wird ein Wert pro Sprache angegeben. In diesem Fall wird eine Spalte definiert, deren Name "Landname" bzw. "Country Name" ist, deren Werte mit dem regulären Ausdruck "[A-Za-z]*" übereinstimmen müssen und deren Werte ebenfalls sprachsensitiv sind.

Implizite Fremdschlüsselverwaltung

Im Gegensatz zu zeilenorientierten Modellen ist die individuelle Kenntnis der Fremdschlüsselbeziehungen nicht notwendig, da Fremdschlüsselbeziehungen wiederum als Datensätze geführt werden können. Das bietet diese Vorteile:

• Der Grad der Inkonsistenz ist steuerbar, indem das gewünschte Verhalten (Löschen des ganzen Datensatzes der Fremdschlüsselbeziehung/Löschen nur der Information im Datensatz der Fremdschlüsselbeziehung/Zulassen einer Inkonsistenz) bei jeder Fremdschlüsselbeziehung mitgeführt werden kann.
• Falls es sich um eine Verknüpfung zu z.B. Werten für ein Auswahlfeld handelt, können
  • sowohl die Informationen über Sortierschlüssel und -richtung für jede einzelne Fremdschlüsselbeziehung als auch
  • die anzuzeigenden Felder der Fremdschlüsseldatensätze und ggf. deren Verbindung mitgeführt werden (z.B. "[Nachname], [Vorname]").
• Da sich die Fremdschlüsselbeziehungen direkt aus dem System ableiten, können diese sehr leicht nachvollzogen werden. Eine entsprechende Dokumentation kann somit direkt und systematisch erstellt werden.

Informationsbasierte Historisierung

Eine informationsbasierte Historisierung ist aufgrund der identischen Tabellenstruktur der informationshaltenden Tabellen in parallel geführten identischen Tabellen mit zusätzlichen Spalten für die Identifikation der Historisierungsschicht realisierbar. Bei dieser Art der Historisierung entstehen signifikant weniger Daten als bei einer Protokollierung von Datenbankabfragen. Zusätzlich lassen auf COIN-Datenmodellen beruhende Systeme eine gezielte Abfrage von ausgewählten Historisierungsdaten unter Nutzung der gleichen systematischen Abfrage wie zur Abfrage von Produktivdaten zu.

Tabellennamen

Die Namen der physischen Tabellen können ebenfalls als Werte im COIN-Datenmodell abgelegt werden. Somit entfällt die Notwendigkeit der Kenntnis von Namen der physisch vorhandenen Tabellen. Vor jeder Abfrage können also zunächst die von der Abfrage betroffenen Tabellennamen ermittelt werden.

Flexible Anzahl physischer Tabellen

Die Werte einer Spalte können sich in jeder beliebigen informationshaltenden Tabelle befinden. Das führt zu einer Möglichkeit der automatischen Optimierung der Anzahl genutzter physischer informationshaltenden Tabellen. Falls die Zeilenanzahl einer Tabelle zu nachteiligen Einflüssen führt, können die Werte für eine oder mehrere Spalten in eine neue Tabelle übertragen werden ohne das Gesamtsystem zu beeinflussen. Dabei ist es unerheblich, ob nur die Werte für eine oder für mehrere Spalten in einer physischen Tabelle vorhanden sind.

Reduktion auf vorhandene Werte

Auf einem COIN-Datenmodell basierende Systeme können so ausgeprägt werden, dass sie eine Entscheidung zulassen, leere oder nicht vorhandene Informationen (z.B. „“, NULL) nicht zu berücksichtigen. Das kann für lesende Operationen einen Performancevorteil bedeuten, erfordert für schreibende Operationen allerdings auch eine Identifizierungsschicht für die einzelnen Datenbankoperationen und eine Prüfungsschicht von existierenden Werten vor der schreibenden Operation.

Nachteile

Datenbankoperationen

Eine aus relationaler Sicht durchzuführende Operation (CRUD) erfordert in COIN-Datenmodellen unter Umständen mehrere unterschiedliche Operationen. Bei einer Ausprägung, die auf eine Verwaltung von leeren Informationen (z.B. „“, NULL) verzichtet, sind weitere Anpassungen notwendig. In diesem Fall kann eine Aktualisierung z.B. die Löschung einer bestehenden oder auch das Einfügen einer neuen Zeile bedeuten. In dieser Ausprägung muss die Ergebnismenge zusätzlich auf die Existenz einer Information geprüft werden, denn es entstehen dynamische Tupel, die aus unterschiedlich vielen Informationen eines aus relationaer Sicht definierten Datensatzes bestehen können.

Datentypen

Eine Nutzung mehrerer Datentypen verbreitert die informationshaltenden Tabellen um eine Spalte pro Datentyp und erzeugt n-1 leere Zellen pro Information. Das stellt allerdings erst dann einen Nachteil dar, wenn die Nutzung von leeren Zellen den Speicherbedarf bzw. die Operationen über weitere Spalten die Performance signifikant erhöhen.

Datensatzbildung in Applikationen

Der Betrieb eines COIN-Datenmodells auf einem relationalen System (z.B. SQL) erfordert von Applikationen das Durchlaufen von ggf. wesentlich mehr Zeilen der Rückgaberessource einer Abfrage, um die benötigte Zuordnung der Informationen aufzubauen, da jede Information in einer eigenen Zeile untergebracht ist. Diesem Nachteil könnte begegnet werden, in dem die Abfragesyntax des relationalen Systems um die Möglichkeit, eine abhängige Ressource zurückzugeben, erweitert würde. Da sämtliche strukturellen Abhängigkeiten für jede Information bereits in der Tabelle vorhanden sind und somit in die Ergebnismenge aufgenommen werden können, könnte zumindest bei auf relationaler Arbeitsweise genutzten Tabellensystem (z.B. SQL-Systemen) die Abhängigkeiten der Abfrageergebnisse bereits in der Abfrage formulieren werden:

Die Abfrage

"SELECT table.information AS ARRAY (col1,coln) FROM table;"

würde diese Ressource zurückgeben: $result_col1,coln=Wert

Intern könnte hierzu auch der Index eines neuen Typs "DEPENDENCY" genutzt werden:

"CREATE DEPENDENCY INDEX index1 ON table (col1,coln);"

"SELECT table.information USING index1 FROM table;"

Diese Vorgehensweise würde signifikanten Performancevorteil bieten, weil eine das Abfrageergebnis nutzende Anwendung auf ein Durchlaufen der Ergebnismenge vollständig verzichten könnte.

Datenkonsistenz und Normalform

COIN-Datenmodelle erlauben die Bildung von unregelmäßigen Tabellen für jede denkbare Datenstruktur und ermöglichen deren Anpassung. Die Normalform dieser Tabellen ist daher nicht vorgeschrieben. Die in Umsetzungen von auf COIN-Datenmodellen basierenden Systemen genutzte Tabellenstruktur stellt ausschließlich Werte/Schlüsselpaare dar, wobei die Schlüsselelemente aus hierarchischen Abhängigkeiten bestehen können. Diese Simplizität lässt eine Interpretation des Primärschlüssels über mehrere Spalten zu. Somit bildet eine Umsetzung von Datenstrukturen auf COIN-Datenmodellen basierenden Systemen zunächst untereinander abhängigkeitsfreie Werte ab und bleibt in sich konsistent.

Weblinks

Daniel J. Abadi, Samuel R. Madden, Nabil Hachem: Column Stores vs. Row-Stores: How Different Are They Really?

Mike Stonebraker, Daniel Abadi, Adam Batkin, Xuedong Chen, Mitch Cherniack, Miguel Ferreira, Edmond Lau, Amerson Lin, Sam Madden, Elizabeth O'Neil, Pat O'Neil, Alex Rasin, Nga Tran and Stan Zdonik. VLDB, pages 553-564, 2005: C-Store: A Column Oriented DBMS

Nikita Ivanov: Columnar vs. Key-Value Storage Models

Peter Sonntag: COIN data model

Literatur

Edgar F. Codd: The Relational Model for Database Management. Version 2. Addison-Wesley, Reading u. a. 1990, ISBN 0-201-14192-2

Clive Finkelstein (1992): "Information Engineering: Strategic Systems Development". Sydney: Addison-Wesley.

James Martin and Clive Finkelstein (1981): Information engineering. Technical Report (2 volumes), Savant Institute, Carnforth, Lancs, UK.

James Martin (1989): Information engineering. (3 volumes), Prentice-Hall Inc.

Paulraj Ponniah (2007): "Data Modeling Fundamentals: a practical guide for IT professionals", John Wiley & Sons, Inc. Hoboken, New Jersey, ISBN 0-471-79049-4

Werte für unterschiedliche Datenstrukturen in der gleichen Tabelle: Die Datensatzkennung 1 der Spaltenkennung „Kontinentname“ wird als Wert der Datensatzkennung 1 der Spaltenkennung „Kontinent“ abgelegt.

Dieser Artikel ist im Entstehen und noch nicht Bestandteil der freien Enzyklopädie Wikipedia.

Solltest du über eine Suchmaschine darauf gestoVorlage:SSen sein, bedenke, dass der Text noch unvollständig sein und Fehler oder ungeprüfte Aussagen enthalten kann. Wenn du Fragen zum Thema hast, nimm Kontakt mit dem Autor Panicp auf.