| Einführung und Erläuterung nicht-relationaler Datenbanken im Unternehmenseinsatz |
|
There are no translations available. © 2010, TEDIC GmbH
Hier ist erkennbar, dass nicht nur ausgehend von "Web-2.0-Anwendungen" Bedarf an eine andere Form von Datenbanken besteht, sondern auch für typische Unternehmensanwendungen. So beispielsweise im Controlling, für die Koordination der Projektzusammenarbeit oder für die Erfassung und Auswertung komplexer Informationen aus Dokumenten (Vertragsdaten, Internetseiten oder Personen- und Firmen-Profilen).
Die "neue Form" von Datenbanken und die entsprechenden Datenmodelle bieten für solche komplexen Strukturen und umfangreiche Datenmengen eine einfache Speicherung und schnelle Abfragemöglichkeit. Datensätze werden hierbei nicht mehr, wie bisher, als Zeile einer (nahezu statischen) Tabelle betrachtet, die wiederum mit anderen Tabellen in Relation stehen (siehe Tabellenabbildung links), sondern als autonome Objekte innerhalb der Datenbank abgelegt, die ggf. aufeinander "verweisen" (siehe Kreisabbildung rechts).
Jedes autonome Objekt innerhalb einer solchen Datenbank wird durch Attribute (Eigenschaften) beschrieben, so dass ausschließlich die verwendeten Felder je Datensatz gespeichert werden (dynamische Satzstruktur) und kein vorgegebenes Schema eingehalten werden muss (schemalose Speicherung). Die Abfrage, das Ändern und Erzeugen von Objekten erfolgt dabei häufig anhand einer Entwicklerschnittstelle (API), die sich ein Entwickler aneignen muss, die aber häufig erheblich schneller erlernt werden kann als tiefergehende SQL-Kenntnisse und herstellerspezifische Anpassungen relationaler Datenbanken. Mehrere Hersteller der alternativen Datenbanken setzen allerdings schon jetzt SQL-ähnliche Abfragemechanismen ein, so dass eine Umstellung für Entwickler erheblich einfacher fällt. Nicht-relationale Datenbanken lassen sich grundsätzlich in fünf Grundarten unterteilen:
Objektorientierte Lösungen bieten die Möglichkeit einer Speicherung von Objekten aus der objektorientierten Softwareentwicklung (z.B. Java oder C#). Hierbei ist daher keine „Konvertierung“ (ein sog. „objektrelationales Mapping“) auf ein relationales Modell notwendig. Weiterhin ist bei Datenbanken aus diesem Bereich ein Schema aufgrund des Klassendiagramms im Sinne der Softwareentwicklung festzulegen. Im Gegensatz zu den weiteren Bereichen ist daher ersichtlich, dass dieses die einzige Ausnahme in Bezug auf die schemalose Speicherung darstellt. Als einfachste Form der schemalosen Speicherung können Schlüssel/Wert‐Paar‐Datenbanken (Key/Value‐Stores) angesehen werden. Hierbei handelt es sich nicht um die Speicherung von Datensätzen im herkömmlichen Sinn. Ein Datensatz besteht hier nur aus einem eindeutigen Schlüssel und einem (oder mehreren) Werten. Je nach Datenbankhersteller müssen die einzelnen Werte manuell indiziert werden, oder es greift ein Automatismus, der jedes Feld mit jedem Inhalt indiziert und so äußerst schnell Inhalte findet. Im Sinne der Softwareentwicklung kann hier von assoziativen Arrays gesprochen werden. Als Ergänzung zu den Key/Value‐Stores lassen sich dokumentorientierte Datenbanken ansehen. Diese zeichnen sich durch die Zuweisung von mehreren Werten und Feldern aus. Dabei erhält im Allgemeinen jeder Datensatz eine eindeutige Identifikation („ID“) und weitere Felder beliebiger Größe und Menge (wie es z.B. beim Harmony‐Datenbankserver der Fall ist). Teilweise bieten mehrere Datenbankprodukte die Möglichkeit, tiefergehende Hierarchien je Datensatz abzulegen. Vergleichbar wäre diese Art mit XML‐Strukturen, die ohne Konvertierung in dieser Form abgelegt werden können; Daher der Begriff „dokumentorientiert“ oder auch „Document‐Store“.
Ausgehend von der Analogie einer XML-Struktur bieten Graphdatenbanken die Möglichkeit, allgemeine Informationen eines Objektes innerhalb einer Struktur abzulegen und in weiteren Strukturen desselben Datensatzes auf andere Objekte zu verweisen. Erweitert wird diese Art der Ablage durch die Abfragefunktionen, die nicht nur Felder und deren Inhalte zurückgegeben können, sondern auch die Verweise auf andere Objekte und wiederum deren Verweise. Die Problemstellungen sozialer Netze und systemischer Abbildungen aus Sicht sozialer Systemtheorien sind somit einfach umsetzbar.
Bei spaltenorientierten Lösungen können pro Datensatz beliebige Felder genutzt werden, die allerdings vor einer Speicherung typisiert werden müssen (ein Feldtyp, wie numerisch, alphanumerisch u.ä., ist also festzulegen). Häufig besteht daher eine Spalte eines Datensatzes aus mehreren Einzelfeldern für die Ablage des Feldtyps, eines Zeitstempels und des eigentlichen Feldes. Alle Datenbanken aus den genannten Bereichen ermöglichen die Zusammenführung von Informationen aus unterschiedlichen Datenquellen und verschiedenen Formaten, wie beispielsweise anderer Datenbanken, einer maschinellen Erfassung oder manueller Eingaben. Mögliche Einsatzszenarien liegen damit einerseits bei typischen Datenbankanwendungen, aber andererseits auch bei unternehmensübergreifenden Konsolidierungs- und Implementierungsmaßnahmen. Hierbei kann beispielsweise für einen Übergangszeitraum eine temporäre Lösung geschaffen werden, ohne im ersten Schritt an das Endprodukt denken zu müssen.
Anstatt einer Vielzahl loser Kopplungen zwischen den eingesetzten Systemen besteht zudem bei einigen nicht-relationalen Lösungen die Möglichkeit einer "zentralen Kopplung" an eine Datenbank oder deren Replikate. Selektionen, Auswertungen und Controlling-Maßnahmen sind daher an zentraler Stelle möglich. Auftretende Fehler wie Doubletten oder Falscheingaben können dort festgestellt, behoben und an jedes angeschlossene System wieder zurückgegeben werden. Dabei ist es unerheblich, ob direkt mit der Hauptdatenbank (Master-Server) oder einer abgeleiteten Kopie (Replikation) Daten ausgetauscht werden.
Die Replikate bieten den Vorteil, dass hierbei nur gefilterte Kopien aller Daten bereitgestellt werden können. Ein Zugriff auf alle Daten durch die angeschlossenen Systeme (interne, wie auch externe) ist daher (im Idealfall) nicht möglich. Somit können unterschiedlichen Abteilungen oder externen Partnern unterschiedliche Datenmengen zur Verfügung gestellt werden. Die Konsistenz wird dabei durch den zentralen Server gewährleistet.
Durch die Nutzung der partiellen Datensatzaktualisierung (nur geänderte Felder werden geschrieben, der restliche Datensatz bleibt unangetastet) werden zudem Konflikte minimiert, da ein Konflikt nur dann möglich ist, wenn der Inhalt eines Feldes innerhalb eines Datensatzes zum gleichen Zeitpunkt (bzw. innerhalb der gleichen Zeitspanne) von verschiedenen Benutzern auf unterschiedliche Werte geändert wird. In diesem Fall greift entweder eine vordefinierte Entscheidungsvorgabe oder es wird vom Benutzer eine Reaktion erwartet.
Je nach Hersteller der nicht-relationalen Lösungen wurden die Konfliktbehandlung und die Replikationsmechanismen unterschiedlich umgesetzt. Da viele Datenbanken für die Nutzung von Cloud-Anwendungen konzipiert wurden, stehen häufig „nur“ ein vollständiger Abgleich unter den beteiligten Servern und eine rudimentäre Konfliktauflösung zur Verfügung. Einige Datenbanken, die aus der Problemsicht von Unternehmensanwendungen erstellt wurden, bieten hingegen zentrale Server mit beliebigen Replikaten, ausgeprägter Benutzerverwaltung, Konfliktlösungen, sowie Backup- und Restore-Mechanismen (Stand: April 2010).
 Die Auseinandersetzung mit diesem Thema und die mittelfristige Analyse von Google-Suchergebnissen zeigen, dass das Thema "NoSQL" derzeitig in verschiedenen Medien und Ausprägungen diskutiert wird. Mit den zahlreichen Datenbanken, von der jede als Werkzeug für unterschiedliche Probleme herangezogen werden kann, können von umfangreichen Internet-Portalen wie Facebook oder Twitter bis hin zu organisationsübergreifenden Anwendungen Herausforderungen gelöst werden. Dabei ist der Begriff "NoSQL" nicht als Ersatz zu den langjährig eingesetzten SQL-Applikationen zu sehen, sondern erweitert und vereinfacht die bisherigen Lösungen im Sinne von "not only SQL" („nicht nur SQL“).
Mit dem Produkt „Harmony“ bietet die TEDIC GmbH ihren Kunden eine Key/Value-Store-Technologie, die schon vielfach im Bereich des CRM, des Vertriebscontrollings und als Managementinformationssystem Einsatz findet.
Artikel als PDF herunterladen...
Weiterlesen in Datenmodelle und Einsatz dokumentorientierter Datenbanken – insbesondere des Harmony-Datenbanksystems
|
