Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Directory Services vs. Relationale Datenbanken LDAP und das relationale Datenbankmodell.

Ähnliche Präsentationen


Präsentation zum Thema: "Directory Services vs. Relationale Datenbanken LDAP und das relationale Datenbankmodell."—  Präsentation transkript:

1 Directory Services vs. Relationale Datenbanken LDAP und das relationale Datenbankmodell

2 Copyright ©2002 by NetUSE AG2 LDAP im Schnelldurchlauf Wald von Bäumen aus Knoten Jeder Knoten hat mindestens die Attribute dn, objectClass Attribute sind ein- oder mehrwertig, haben Syntax (Typ) Besonderes mehrwertiges Attribut objectClass bestimmt, welche Attribute vorhanden sind MÜSSEN und DÜRFEN Einwertiges Attribut dn enthält den Pfad durch den Baum und ist Schlüssel (PK)

3 Copyright ©2002 by NetUSE AG3 SQL im Schnelldurchlauf Datenbank als Kollektion von Tabellen, Tabellen als Kollektion von Spalten, Spalten haben Typen Spalten sind NULL, NOT NULL. Spalten sind einwertig. Eine Spalte oder Gruppe von Spalten ist der PK.

4 Copyright ©2002 by NetUSE AG4 SQL Operationen SQL erlaubt komplexe Operationen auf Tabellen: –Selektion (WHERE- Clause) wählt Zeilen –Projektion (Spaltenliste) wählt Spalten –Aggregation (GROUP BY-Clause) erlaubt Zählungen –Join erlaubt Tabellenverknüpfungen –Rename erlaubt Self- Joins und damit rekursive Strukturen (Bäume etc)

5 Copyright ©2002 by NetUSE AG5 LDAP Anwendungen Authentisierung –am OS (PAM) –an der Anwendung (mod_auth_ldap etc.) Konfigurationsdaten –Netscape Roaming –sendmail Aliases etc. Verzeichnis (Recherche) –Adreßverzeichnisse Characteristika: –kurze Verbindungen connect, query, disconnect connect, disconnect (authentication only) –triviale Queries Existenzanfragen Attributanfragen (dn, attribut) -> (werte) Objektauslesung (dn) -> (attribute, werte)

6 Copyright ©2002 by NetUSE AG6 SQL Anwendungen Datenspeicher für Anwendungsdaten –Persistente Daten –Normalisierte Daten Business Rules –Integritätsbedingungen –Accessfunktionen Lockingmechanismen –Zugriff durch mehrere Instanzen derselben Anwendung –Zugriff durch verschiedene Anwendungen Characteristika: –lange Connects mit vielen Queries –langlaufende Queries Joins Sortierungen berechnete Werte –viele Schreiboperationen konkurrente Schreiboperationen -> Locking zusammengesetzte Schreiboperationen -> Transaktionen

7 Copyright ©2002 by NetUSE AG7 Relationenmodell in Verzeichnisdiensten Woher kommen die Daten im Verzeichnis? –Welches ist das führende System? Wie strukturiere ich den Verzeichnisbaum? –Nebenbedingungen: Replikation Naming Attributes Wie strukturiere ich meine objectClasses? –Welche Art von Anfragen wird erwartet? Sollte ich nicht doch lieber ein RDBMs nehmen?

8 Copyright ©2002 by NetUSE AG8 Häufige Designprobleme in LDAP LDAP wird als führende Datenbank eingesetzt LDAP wird stark beschrieben LDAP wird konkurrent beschrieben LDAP dynamisch beschrieben Es bestehen abzufragende Beziehungen zwischen LDAP-Objekten LDAP wird zur Reportgenerierung verwendet Der LDAP-Bestand wird hierarchisch strukturiert Der LDAP-Bestand muß hierarchisch strukturiert werden

9 Copyright ©2002 by NetUSE AG9 LDAP wird als führende Datenbank eingesetzt LDAP-Attribute haben eine Syntax (einen Typ) –Typen sind zahlreich und im Standard vordefiniert –Typen sind schwer erweiterbar –Integritätsbedingungen können nicht definiert werden. iPlanet erlaubt Plugins, die Integrität checken können. Beziehungen zwischen Objekten sind in LDAP nur schwer darstellbar und instabil. –PK ist immer der dn –dn's sind jedoch unter Umständen instabil –Aliases sind ein optionales Feature von LDAP Nur Blattknoten können Aliases sein.

10 Copyright ©2002 by NetUSE AG10 LDAP wird stark beschrieben LDAP ist als Protokoll für Leseoperationen optimiert. Es existiert noch kein standardisiertes Bulk-Update Protokoll. –In OpenLDAP und iPlanet ist der LDAP- Datenspeicher ein Sleepycat DB/3. –In einigen LDAP-Servern sind Schreiboperationen ungeschickt implementiert. Flush nach jedem Write. Replikation zwischen Servern skaliert sich nicht gut bei starken Schreiboperationen. –Nicht standarisiert. –Oft als reguläre Schreiboperation eines privilegierten Benutzers implementiert ("triviale Implementierung") iPlanet kann immerhin out-of-sync Replica automatisch neu aufbauen.

11 Copyright ©2002 by NetUSE AG11 LDAP wird konkurrent beschrieben LDAP definiert einzelne add oder modify-Operationen als atomar. LDAP kennt keine Locks und keine Transaktionen –Synchronisation und Konsistenz sind damit Sache der Anwendung.

12 Copyright ©2002 by NetUSE AG12 LDAP wird dynamisch beschrieben Viele LDAP-Server speichern die Schemadefinition out-of- band –Externe Dateien, die per include in die Serverkonfiguration mit eingebunden werden. Damit ist eine Änderung des Schema im Betrieb und durch LDAP unmöglich. –Dies fördert sehr entspannte objectClass- Definitionen ("MAY"- Inflation) Out-of-band Schemadefinition macht Introspektion schwierig –Welche objectClasses kennt der Server? Welche Attribute erlauben und definieren sie?

13 Copyright ©2002 by NetUSE AG13 Beziehungen zwischen LDAP-Objekten Der PK in LDAP ist immer der dn. –Der dn ist nicht opaque, sondern hat Struktur: Pfadinformation. –Konsequenz: dn's sind instabil. Verschiebt man ein Objekt im Baum, ändert sich der dn. Damit sind alle Referenzen auf das Objekt ungültig. –iPlanet dn Plugin LDAP kennt keine JOIN- Operation –Prejoined Structures über Aliases oder andere Referenzen keine dynamisch zusammengesetzten Strukturen. Aliases sind nicht generisch (Leaf-Nodes only).

14 Copyright ©2002 by NetUSE AG14 LDAP wird zur Reportgenerierung verwendet LDAP kennt keine Aggregation –Reports können nur durch Durchlesen des Bestandes erstellt werden. LDAP kennt keine serverseitigen Funktionen –Funktionswerte können nur durch Durchlesen des Bestandes erstellt werden. LDAP kennt keinen JOIN –Reports machen oft Gebrauch von ad-hoc Beziehungen zwischen Teilmengen ohne Join können diese nicht effizient generiert werden.

15 Copyright ©2002 by NetUSE AG15 Hierarchische Struktur im LDAP I Der PK in LDAP ist immer der dn. Der dn enthält Strukturinformation. Ändert sich die Position eines Objektes in der Struktur, ändert sich der PK dieses Objektes Klassischer Fall von nicht normalisierter Struktur: Daten und Struktur nicht getrennt Ein Objekt ist oft Mitglied in verschiedenen Hierarchien –Mitarbeiter ist einsortiert organisatorisch ("Abteilung 1.3.2") räumlich ("Deutschland, SH, Kiel, Hauptstelle") projektbezogen ("IT Infrastruktur, Netzwerke, UMTS- Pilot") –Redundante Datenhaltung durch nicht normalisiertes Datenmodell

16 Copyright ©2002 by NetUSE AG16 Hierarchische Struktur im LDAP II LDAP erlaubt die Partitionierung des Bestandes nur nach Teilbäumen –Erzwingt die Bildung von Hierarchien im Bestand –Erzwingt damit instabile dn's

17 Copyright ©2002 by NetUSE AG17 Fazit I LDAP ist der Teil von X.500, der "brauchbar" war. LDAP verwirft elementare Erkenntnisse des relationalen Datenmodells. Damit ist auch der brauchbare Teil von LDAP aus der Sicht des Datenbankdesigners unbrauchbar und gefährlich. Der Einsatz von LDAP als führende Datenbank ist zu vermeiden. LDAP-Bestände sind möglichst als flache Tabellen zu strukturieren. Nichttriviale Dinge sind mit LDAP nicht zu realisieren. Triviale Dinge sind mit LDAP schwierig oder gefährlich.

18 Copyright ©2002 by NetUSE AG18 Warum dann keine relationalen Systeme? Deutschland, 9.00 Uhr: – MA loggen sich ein. –Jedes Login ist ein Connect, gefolgt von einem Disconnect. –Jeder Connect erzeugt in Oracle einen fork, einen exec und einen 5 MB schweren Subprozeß –der dann sofort weggeworfen wird. LDAP als wire-protocol ist genormt. LDAP als query-language ist unbrauchbar, aber sehr rigide genormt. LDAP ist auf connect/disconnect optimiert.

19 Copyright ©2002 by NetUSE AG19 Warum dann keine relationalen Systeme? MySQL? –Connect/disconnect problemlos –read-mostly –Replikation –Hat volle SQL-Syntax Selektion Projektion Aggregation Join Rename –Speichereffizienter als iPlanet oder OpenLDAP Als wire protocol nicht genormt –aber: Source liegt offen, GPL bzw. LGPL In kommerziellen Clients nicht unterstützt. –aber mod_auth_mysql, PAM usw Trivial zu implementieren. Kein IETF-Prozeß.

20 Copyright ©2002 by NetUSE AG20 Und XML? LDAP und XML haben strukturell viel gemeinsam –Rückkehr zu hierarchischen (Datenbank-) Systemen. –Liste der Nachteile dieser Systeme in Datenbanken 101 nachlesbar. Keine führende Datenhaltung in hierarchischen Systemen! –Wir haben in den Betrieben für viel Geld diesen Unsinn gerade ausgerottet und nun kommt er mit wieder. Mit Macht!


Herunterladen ppt "Directory Services vs. Relationale Datenbanken LDAP und das relationale Datenbankmodell."

Ähnliche Präsentationen


Google-Anzeigen