|
Hat man Daten in Datenbanken, so ist es wichtig, diese
Informationen zu strukturieren. Besonders, wenn viele
verschiedene Clients auf die Datenbank zugreifen wollen, zum
Beispiel Netscape, Outlook und andere, muss die Struktur genau
definiert sein. Wenn ein Mailclient eine eMail-Adresse braucht,
muss er wissen, wie er diese bekommt.
Es gibt viele Definitionen, an die man sich halten muss, soll am
Ende auch etwas funktionieren. Bei LDAP werden Objekte mit
Eigenschaften verwendet. Jedes Objekt hat zunächst einen
eindeutigen Namen, an dem es von allen anderen unterschieden
werden kann ("distinguished name", kurz: DN). Die Eigenschaften
eines Objekts hängen davon ab, zu welcher Klasse es gehört (es
kann sogar zu mehreren Klassen gehören).
|
Es sind nun Klassen für Personen definiert. Zu einer Person
("person") gehören zwingend objectClass (die Objektklasse
selbst), sn (der Nachname) und
cn (commonName, etwa: üblicher
Name, hier wird üblicherweise Vor- und Nachname verwendet).
Zusätzlich gibt es optionale Attribute, die nicht unbedingt
angegeben werden müssen. Diese sind hier
description (beliebige
Beschreibung), seeAlso (verweist auf ein anderes Objekt),
telephoneNumber (Telefonnummer),
userPassword (ein Password). Da
häufig noch mehr Attribute mit einer Person verknüpft sind, gibt
es auch eine Objektklasse organizationalPerson. Diese hat die
gleichen geforderten Eigenschaften wie Person, aber erlaubt viele
optionale Eigenschaften, wie zum Beispiel Felder der Adresse und
eine FAX-Nummer. Es gibt noch mehr Klassen, zum Beispiel
newPilotPerson (die als optionale Eigenschaft
eine eMail-Adresse
mail einführt) und natürlich Klassen für
Organisationen/Firmen,
Abteilungen, Bilder, Dokumente, Geräte und so weiter.
|
|
Wenn man also irgendwo eine Person im Verzeichnis hat, ist klar,
dass diese ein cn haben muss,
und eine Telefonnummer haben kann
(und dass diese genau telephoneNumber heißt).
Soll ein Programm
eine eMail-Addresse suchen, muss es nur nachschauen, ob es ein
Attribut mail gibt. Es kann eben nicht sein, dass diese
Eigenschaft email oder anders heißt.
mail ist vorgeschrieben,
und nichts anderes.
An diesem Beispiel kann man zeigen, dass eine natürliche Person zu
mehreren Klassen gehört: person,
organizationalPerson und
newPilotPerson. Eine weitere Klasse ist
top. Im Prinzip gehört
so ziemlich jedes Objekt auch zur Klasse top, die lediglich
vorschreibt, dass die Eigenschaft objectClass gesetzt sein muss
(was bei allen Personenklassen ohnehin gefordert ist).
Durch das Verwenden der Klassen definiert man, welche
Eigenschaften vorhanden sein müssen, und welche vorhanden sein
können. Eine Person darf zum Beispiel keine Farbtiefe haben, ein Bild
hingegen schon. Verwendet man mehrere Klassen, so muss das
entsprechende Objekt alle von mindestens einer Klasse geforderten
Eigenschaften haben, und kann alle insgesamt erlaubten
Eigenschaften haben.
|
|
Den Eigenschaften sind Typen zugeordnet. Es gibt Typen, die eine
Zeichenkette enthalten, und andere, die eine Telefonnummer
enthalten. Diese Typen definieren weiterhin, wie Werte verglichen
(und damit sortiert und gesucht) werden. Zeichenketten
beispielsweise kann man abhängig von Groß- und Kleinschreibung
vergleichen oder auch nicht. Bei Telefonnummer spielen gewisse
Füllzeichen möglicherweise keine Rolle. Passwörter hingegen
müssen genau übereinstimmen.
Es gibt nun also Objekte (die zu bestimmten Klassen gehören).
Diese werden nun anderen Objekten untergeordnet (beziehungsweise
werden anderen Objekte viele zugeordnet, dies ist die richtige
Reihenfolge). Diese baumartige Struktur kann man (mit etwas
Phantasie) auch in der Realität finden: In Ländern gibt es
Firmen, in Firmen gibt es Abteilungen und in Abteilungen letztlich
Personen. So wird das in LDAP auch gesehen. Die Baumstruktur
wird hier "Directory Information Tree" genannt, kurz
DIT. Es gibt
Länder (also Objekte der Klasse country [Land]) mit u.A. der
Eigenschaft c (kurz für country),
Firmen (organisations mit der
Eigenschaft o), Abteilungen (Organisations Einheit,
organisationalUnit mit der Eigenschaft
ou). Hierbei enthalten
diese Objekte normalerweise viele weitere Eigenschaften; eine
Firma hat zum Beispiel eine Postanschrift.
|
|
Ein Schema ist eine Sammlung von Strukturdefinitionen. Dazu
gehören die Schreibungen vieler Klassen und der verwendeten
Typen. Es gibt verschiedene Schemata, und es ist möglich, eigene
zu definieren (oder bestehende zu erweitern) was jedoch nicht
interoperabel mit anderen Diensten sein muss. Das ist außerhalb
der Betrachtungen dieses Dokumentes.
|
|
Der LDAP-Server speichert seine Informationen in einer
baumartigen Struktur. Diese wird auch "Directory Information Tree"
genannt, kurz DIT.
Zum Speichern benutzt der LDAP-Server Objekte, die er mit
Attributen versehen kann. Dadurch kann man die Struktur flexibel
an die eigenen Bedürfnisse anpassen. Das RFC 2256 spezifiziert
die Standard-Objekte des LDAP-Servers. Man wird zwar von
niemandem gezwungen, diese Vorgaben auch zu benutzen. Um aber
eine möglichst große Konformität zu erzielen, sollte man diese
Vorgaben einhalten.
|
|
SelfLinux 
