Wissen > 1. Klassische Datenbanken > Erfolgsgeschichte klassischer Datenbanken > Warum Relational?
Was ist es, was relationale Datenbanken so speziell macht? Warum wird heute kaum noch etwas anderes eingesetzt? Die Antwort ist relativ simpel und liegt in der Komplexität und Umständlichkeit der Vorgänger.
Mitte der Sechziger Jahre begannen Firmen ihre Buchhaltung zu automatisieren und verwendeten Cobol um täglich angesammelte Transaktionsbefehle am Abend als "Batch"-Job auf Tape-Master zu schreiben. Irgendwann ergab sich allderdings der Bedarf, Datenänderungen "online" zu übernehmen und man begann an der Entwicklung von Datenbanken (im mehr oder weniger heutigen Sinne) zu arbeiten.
Schlussendlich landete man bei Netzwerkdatenbanken, die man mit Hilfe von Codaysl [1] DBTG bearbeitete. Diese Konzepte hatten allerdings beide eine Vielzahl grober Probleme:
Separation und Isolation von Daten
Verdopplung von Daten
hinsichtlich der Integrität und
dem Speicherplatz
Datenabhängigkeit
Datei-Inkompatibilität - Applikationsabhängigkeit
Feste Abfragen, Änderung der Datebank verlange Änderung des Programms
Einer der gravierendsten Konzeptfehler war vermutlich, dass die Datendefinitionen stets im Programm implementiert sein mussten und datenbankseitig keine Zugriffskontrolle existierte.
Dementsprechend finden sich die Vorteile von relationalen Datenbanken in den Punkten
Datenintegrität
Zugriffskontrolle
Concurrency Control
Recovery Control
Datendefinition gekoppelt mit Daten gespeichert
Eine Grundlage für dieses Konzept war speziell die Tatsache, dass Daten für Gewöhnlich länger existieren (müssen), als die Applikation, die zur Manipulation verwendet wird. Ein weiterer Schlüsselaspekt ist der Fakt, dass oftmals mehrere Applikationen auf ein und die selben Stammdaten zugreifen.
Dennoch liefern heute auch relationale Datenbanken gewisse Problemzonen; dies liegt vor allem an den folgenden Punkten:
Individuelle Firmenabteilungen bzw. die Entwicklungsteams sind im Allgemeinfall "Applikations-fokkusiert", d.h. auf die Notwendigkeit "sofort" ein Produkt zu liefern bedacht
Prototypen werden als "gut genug" akzeptiert
End-User Datenbanksysteme werden als "Schnellschuss"-Loesung geliefert
Prinzipiell gibt es - wie bei den Vorgängern relationaler Datenbanken - sowohl positive, als auch negative Aspekte am Konzept:
+ Kontrolle der Datenredundanz
+ Datenkonsistenz
+ Mehr Informationen aus den Daten extrahierbar
+ Datensharing
+ Datenintegrität
+ Datensicherheit
+ Einhaltung von Standards
+ Economy of Scale
+ Ausgeglichene widersprechende Anforderungen (? balanced conflicting requirements ?)
+ Verbesserte Zugriffsmöglichkeit und Antwortzeit
+ Erhöhte Produktivität
+ Verbesserte Concurrency
+ Verbesserte Backup & Recovery Möglichkeiten
-- Komplexität
-- Grösse
-- Kosten von DBMS und geschultem Personal (schlechtes Beispiel, da die Vorgänger erst recht genau das selbe Problem besassen)
-- zusätzliche Hardwarekosten (siehe voriges Argument)
-- Konvertierungskosten / Umstiegskosten (kein aktuelles Problem mehr)
-- Performance (nicht unbedingt aktuelles Problem mehr)
-- stärkere Auswirkung bei Fehlern: Fehler im Konzept könnte er spät erkannt werden
Zusätzlich werden in vielen Fällen relationale Datenbanken verwendet, in denen andere Datenbankkonzepte möglicherweise besser passen würden. Aufgrund der starken Etablierung relationaler Datenbankprodukte am industriellen Markt, wird über Alternativen gar nicht erst nachgedacht.
> Warum DBTG nicht gewinnen konnte