DE69530595T2

DE69530595T2 - System und verfahren für die x.500-datenbanknorm

Info

Publication number: DE69530595T2
Application number: DE69530595T
Authority: DE
Inventors: Hans Richard HARVEY
Original assignee: Computer Associates Think Inc
Current assignee: CA Inc
Priority date: 1994-09-01
Filing date: 1995-08-30
Publication date: 2004-03-18
Anticipated expiration: 2015-08-31
Also published as: JPH10505690A; EP1313037B1; EP0777883A4; US7685142B2; US20030105749A1; EP0777883A1; WO1996007147A1; US20020169767A1; US20020116370A1; DE69530595D1; ATE239257T1; EP1313039A3; ES2204962T3; EP1313036A3; EP1313037A2; US20020103785A1; US20060020613A1; US20030213316A1; EP0777883B1; US6052681A

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft eine Datenverarbeitungseinrichtung, und ist in der Anwendung der X.500-Norm auf eine relationale Datenbank von besonderer Bedeutung. Insbesondere ist die hier vorliegende Erfindung nachfolgend so beschrieben, als ob sie auf eine Implementierung unter Verwendung eines RDBMS (relationalen Datenbank-Management-Systems) gerichtet ist.
Stand der Technik
X.500 ist der internationale Standard für elektronische Directories [CCITT89]. Diese Standards definieren die Dienste, Protokolle und das Informationsmodell einer sehr flexiblen und allgemein verwendbaren Datenbank. X.500 ist in Informationssystemen anwendbar, in welchen die Daten ziemlich statisch sind (zum Beispiel einem Telefon-Directory), jedoch verteilt werden müssen (zum Beispiel zwischen Organisationen oder Ländern), erweiterbar sein müssen (zum Beispiel zum Speichern von Namen, Adressen, Jobtiteln, Einrichtungen, usw.), objektorientiert sein müssen (zum Beispiel, um auf Daten Regeln auszuführen) und/oder fernsteuerbar zugreifbar sein müssen.
Relationales Datenbank-Management-System
(RDBMS) stellt Möglichkeiten für Anwendungen zum Speichern und Verändern von Daten bereit. Unter den vielen Eigenschaften, die dieselben anbieten, sind Datenintegrität, Datenkonsistenz, Datengleichzeitigkeit, Indizierungsmechanismen, Anfrageoptimierungen, Datenwiederherstellung, Datenzurückverfolgung und Sicherheit. Sie können auch eine Vielzahl von Werkzeugen zur Leistungssteigerung, zum Import/Export, zum Backup, zum sogenannten Auditing und zur Anwendungsentwicklung bereitstellen.
RDBMS ist die bevorzugte Wahl der meisten Datenmanager von großem Umfang. Sie sind gegenwärtig bereits verfügbar und als zuverlässig bekannt, und verfügen über eine Vielzahl nützlicher Managementwerkzeuge. Es gibt eine große Basis von RDBMS-Installationen und daher eine große Anzahl existierender Erfahrung und Investitionen in Menschen und Prozesse, um diese Systeme zu betreiben, und daher versuchen Datenmanager diese zu nutzen, wenn ein neues System angeschafft wird. Die meisten relationalen Datenbankprodukte unterstützen den Industriestandard SQL (Structured Query Language).
Es hat auch eine Bewegung in Richtung auf objektorientierte Systeme gegeben, die eine Daten-Ausdehnbarkeit bereitstellen und die Möglichkeit aufweisen, beliebig komplexe Daten-Gesichtspunkte handzuhaben. Weiterhin verfügen viele Unternehmen und Regierungsabteilungen über eine große Anzahl von Datenbankanwendungen, die nicht untereinander verknüpft sind. Datenmanager suchen nach Lösungen, die es ihnen ermöglichen, ihre Daten zu integrieren und das Management dieser Daten zu vereinfachen. X.500 und die damit verbundenen Standards stellen einen Rahmen und einen Grad an Funktionalität bereit, welcher es ermöglicht, dies zu erreichen. Die Tatsache, dass X.500 ein internationaler Standard ist, bedeutet, dass Datenverknüpfungen zwischen Unternehmen und zwischen unterschiedlichen Ländern erzielt werden können.
Das Problem liegt daher darin, die Bedürfnisse der Datenmanager zu adressieren und X.500 mit der gesamten Flexibilität von objektorientierten Systemen zu implementieren, jedoch ein SQL-Produkt zu verwenden, so dass es die Installierbarkeit und inhärente Leistungsfähigkeit von relationalen System verbunden mit der Stabilität, Robustheit, Portabilität und Kosteneffektivität von gegenwärtigen SQL-Produkten verknüpfen kann.
Es hat eine Anzahl von Versuchen gegeben, das obige Problem über eine vernünftige Zeitspanne zu lösen. Keiner dieser Versuche haben in ein Produkt gemündet, welches unter Beweis gestellt hat, dass es kommerziell im Markt akzeptiert ist, und daher gibt es auf dem Markt seit langem ein Bedürfnis, welches bis heute noch nicht befriedigt worden ist.
1 zeigt eine Zusammenfassung aus den "GOSIPNews", Ausgabe Nr. 4, datiert von April 1994 (Quelle: "Interoperability Products", welches in Australien durch das Zentrum für offene Systeme vertrieben wird) und welches die gegenwärtig verfügbaren X.500-Produkte auflistet. Keines dieser Produkte verwendet eine SQL-Datenbank als eine zugrundeliegende Datenspeicherung und keines dieser Produkte adressiert daher erfolgreich die Bedürfnisse des Marktes nach der Implementierung von X.500 unter Verwendung einer SQL RDBMS.
Die Proceedings von IFIP WG6.6 Internationales Symposium (ISBN: 0444 889 167) haben ein durch Francois Perruchond, Cuno Lanz und Bernard Plattner präsentiertes Papier veröffentlicht, welches den Titel trägt "A Relational Data Base Design for an X.500 Directory System Agent". Das veröffentlichte Directory-System ist, wie die meisten Systeme nach dem Stand der Technik, im Betrieb relativ langsam, insbesondere dann, wenn die Datenbank relativ ausführlich ist und in seiner Implementierung von X.500 unvollständig ist, wie zum Beispiel Aliases, Untersuchen und Dateneingaben.
Ein anderer Versucht ist veröffentlicht in den Proceedings von IEEE, ISBN 0909 394 253, Proceedings April 22–24, 1991 durch C. M. R. Leung. In dieser Veröffentlichung ist ein Datenbankschema beschrieben, in welchem eine einzelne Eingabetabelle detaillierte Information über jedes Directory-Objekt bereithält, es ist jedoch unvollständig in seiner Implementierung von X.500.
Dieser Versuch wurde in einer Anzahl von Textbüchern und nach dem Stand der Technik, so zum Beispiel in "bject Oriented Modeling and Design" durch J. Rumbaugh, et al, 1991, ISBN 0-13-630054-5, diskreditiert, in welchem in Abschnitt 17.3.8 klar ausgedrückt ist, dass "das Einfügen aller Eingaben in eine Tabelle kein guter Lösungsansatz für das Design von relationalen Datenbanken ist".
Die Veröffentlichung Cooke E. E. et al: "Directory Services in the HP Map 3.0 Environment", Hewlett Packard Journal, Volume 41, Ausgabe 4, 1. August 1990, Seiten 15–23, XP000149608 beschreibt ein System zur Bereitstellung von Datenbankdiensten unter Verwendung einer relationalen Datenbank, die drei Tabellen aufweist. Es wird der X.500 Directory-Standard verwendet.
Zusammenfassung der Erfindung
Das Ziel der hier vorliegenden Erfindung liegt in der Adressierung des Problems der Implementierung von X.500 in ein RDBMS, welches SQL oder jede andere relationale Sprache unterstützt. X.500-Dienste können durch eine Anzahl von Protokollen genutzt werden, wie zum Beispiel X.500 und LDAP.
In diesem Dokument ist zum Zeitpunkt seiner Einreichung SQL die am meisten populäre, relationale Sprache, obwohl es nur eine von mehreren relationalen Sprachen ist, ist es die Absicht der hier vorliegenden Erfindung, eine Anwendbarkeit auf eine andere Form einer relationalen Sprache zu ermöglichen, nicht nur auf SQL.
Nach der hier vorliegenden Erfindung wird ein Datenbanksystem zur Bereitstellung von Directory-Diensten bezüglich Datenobjekten bereitgestellt, wobei jedes Datenobjekt wenigstens ein Attribut und jedes Attribut einen oder mehrere Werte aufweist, mit: Empfangsmitteln zum Empfangen von Directory-Dienst-Operationsbefehlen; und Datenbankmitteln, die angeordnet sind, um Daten zu speichern und Directory-Dienst-Operationen in Übereinstimmung mit den von den Empfangsmitteln empfangenden Directory-Dienst-Operationsbefehlen auszuführen; dadurch gekennzeichnet, dass die Datenbankmittel umfassen: Hierarchiedefinitionsmittel (wie zum Beispiel eine hierarchische Tabelle HIERARCHY; DIT) zur Definition von Beziehungen zwischen Objekten und einem Entry-Identifikator, der jedes Objekt identifiziert; Attributdefinitionsmittel (wie zum Beispiel eine Attributtabelle ATTRIBUTE), um eine Vielzahl von Attributdefinitionen zu speichern, wobei jede Attributdefinition ein entsprechendes Attribut definiert und einen Attribut-Identifikator umfasst; Mittel (wie zum Beispiel eine Objekttabelle OBJECT; ENTRY) zur Speicherung von Wertedaten für ein Objekt, wobei die Wertedaten (zum Beispiel ValueNam; ValueRaw) Attributwerte und, verbunden mit jedem Attributwert, einen entsprechenden Attribut-Identifikator (AID) und einen Entry-Identifikator (EID) aufweisen, der das Objekt identifiziert, auf welches sich der Attributwert bezieht, und Mittel, die auf die Directory-Dienst-Operationsbefehle antworten, um die Datenobjekte zu ermitteln und/oder zu übertragen, welche die durch die Hierarchiedefinitionsmittel, die gespeicherten Attributdefinitionen und die gespeicherten Wertedaten definierten. Beziehungen verwenden.
Es ist bevorzugt, dass die Hierarchiedefinitionsmittel (HIERARCHY; IT) vorhanden sind, um Ursprungsdaten (Parent; Path) zu speichern, die den EID eines jeden Objekts zu einem anderen EID oder einem Root-Objekt in Beziehung setzen.
Vorzugsweise sind die Datenbankmittel weiterhin angeordnet, um dem EID eines jeden Objekts zugeordnete Pfaddaten (Path) zu speichern, die einer relativen, hierarchischen Beziehung des Objekts bezüglich des Root-Objekts entsprechen, wobei die Datenbankmittel vorgesehen sind, um Directory-Dienst-Operationen unter Verwendung dieser Pfaddaten auszuführen. So können die Datenbankmittel zum Beispiel angeordnet sein, um die Pfaddaten (Path) in einem Pfaddefinitionsmittel (TREE) getrennt von den Hierarchiedefinitionsmitteln (HIERARCHY; DIT) zu speichern.
Die Datenbankmittel sind insbesondere vorgesehen, um Alias-Daten (Alias) zu speichern, welche die Äquivalenz eines Objekts in Bezug auf ein anderes Objekt wiedergeben, wobei das Datenbankmittel vorgesehen ist, um die Directory-Dienst-Operationen auszuführen, indem Referenzen auf einen EID eines Objekts, welches durch seine Alias-Daten (Alias) als ein Äquivalent für ein anderes Objekt erkannt wird, in Referenzen auf die EIDs ihrer äquivalenten Objekte unter Verwendung der Alias-Daten konvertiert werden. Zum Beispiel können die Datenbankmittel vorgesehen sein, um die Alias-Daten (Alias) in Alias-Definitionsmitteln (ALIAS) getrennt von den Hierarchiedefinitionsmitteln zu speichern.
Die Datenbankmittel sind insbesondere vorgesehen, um Wertedaten für jedes Objekt in einer ersten Form (ValueNorm) und in einer zweiten Form (ValueRaw) zu speichern, wobei das Datenbankmittel angeordnet ist, um die Directory-Dienst-Operationen unter Verwendung eines Vergleichs der Wertedaten mit Daten auszuführen, die von den Empfangsmitteln unter Verwendung von in der ersten Form (ValueNorm) gespeicherten Daten empfangen werden, und um Daten unter Verwendung von in der zweiten Form (ValueRaw) gespeicherten Daten auszugeben. Zum Beispiel können die Datenbankmittel vorgesehen sein, um die Wertedaten (ValueNorm) in der ersten Form und die Wertedaten in der zweiten Form (ValueRaw) in getrennten Attributdefinitionsmitteln zu speichern (SEARCH, ENTRY).
Die Datenbankmittel können weiterhin vorgesehen sein, um Konvertierungsdaten zu speichern, die der Konvertierung von Daten zwischen als Teil von Directory-Dienst-Operationsbefehlen empfangenen Daten, die Typdaten (Type; Object ID) entsprechen, und Attribut-Identifikatoren (AID) dienen.
Die Datenbankmittel sind insbesondere vorgesehen, um Namen-Identifikationsdaten (Disting) zu speichern, die für ein Objekt Wertedaten (ValueNorm; ValueRaw) als Daten identifizieren, die einen Teil eines eindeutigen Namens für jedes Objekt bilden, und sind insbesondere vorgesehen, um für jedes Objekt Namensdaten zu erzeugen, und zwar unter Verwendung der oben erwähnten Wertedaten (ValueNorm; ValueRaw) die Namens-Identifikationsdaten (Disting) zu geordnet sind, die wiedergeben, dass die Wertedaten Teil eines Namens für ein Objekt bilden, um für jedes Objekt einen eindeutigen Namen (RDN) zu erzeugen, und zwar unter Verwendung der Namens-Identifikationsdaten (Disting) und der Daten, die einem Objekt und seiner hierarchischen Beziehung relativ zu einem Root-Objekt direkt oder über andere Objekte entsprechen. Es ist insbesondere vorgesehen, um diesen eindeutigen Namen (RDN) für ein Objekt unter Bezugnahme auf den dem Objekt zugeordneten EID zu speichern und um einen eindeutigen Namen für das Objekt unter Verwendung der Namens-Identifikationsdaten und der Pfaddaten zu erzeugen. Es ist weiterhin insbesondere vorgesehen, um den eindeutigen Namen (RDN) mit EID, der die Namensdaten einem entsprechenden Objekt zuordnet, in einem Namensdefinitionsmittel (NAME) getrennt von den Hierarchie-Definitionsmittel (HIERARCHY; DIT) zu speichern.
Der eindeutige Name (RDN) für jedes Objekt kann in einer ersten Form (NameNorm) und in einer zweiten Form (NameRaw) gespeichert werden, und die Datenbankmittel können angeordnet sein, um die Directory-Dienst-Operationen unter Verwendung eines Vergleichs der eindeutigen Namensdaten (RDN) mit Daten auszuführen, die von den Empfangsmitteln unter Verwendung von in der ersten Form (NameNorm) gespeicherten Daten empfangen werden, und um Daten unter Verwendung von in der zweiten Form (NameRaw) gespeicherter Daten auszugeben.
Die Empfangsmittel können angepasst sein, um Directory-Dienst-Befehle zu empfangen, umfassend Suchkriterien definierende Suchdaten, die eine Anforderung zur Ausführung einer Suchfunktion identifizieren. Die Suchdaten können Daten umfassen, die eine oder mehrere von den Wertedaten (ValueNorm; ValueRaw) zu erfüllende Bedingungen umfassen, und die Antwortmittel können angeordnet sein, um nach Empfang der Befehle durch die Empfangsmittel Daten auszugeben, die in den Datenbankmitteln gespeichert sind, und zwar in Verbindung mit einem EID entsprechend den EIDS, die in Verbindung mit den Attributwerten gespeichert sind, die eine oder mehrere zu erfüllende Bedingungen erfüllen.
Es folgt eine Beschreibung einer Implementierung der vorliegenden Erfindung, und zwar in einem Kontext, von dem Stand der Technik zugeordneten Problemen. Die Beschreibung wird unter Bezugnahme auf die folgenden Überschriften zweckmäßig dargestellt:

1. grundlegendes Design

2. konzeptionelle Methoden

3. konzeptionelle Design

4. logisches Design

5. logische Methoden

6. physikalisches Design

7. Beispielimplementierung
Der X.500-Standard gibt in keiner Art und Weise an, wie ein Directory zu implementieren ist, nur seine Möglichkeiten und sein Verhalten. Ein Schlüssel in der Lösung des Implementierungsproblems ist die Realisierung, dass X.500 einen vorgegebenen Satz von Diensten (zum Beispiel Add, Modify, Search, usw.) definiert, der beliebige Daten abarbeiten kann.
Es wurde erkannt, dass mit dem Stand der Technik verbundene Probleme durch einen einzigartigen Versuch beseitigt werden können, durch was man als invertiertes, relationales Theoriemodell bezeichnen kann, aus einem Datenmodellierungsversuch in einen Servicemodellierungsversuch. Das ist, ausgehend vom Problem: Abarbeiten beliebiger Anfragen eines festgegebenen Datensatzes auf eine vorhandene Lösung der Abarbeitung beliebiger Daten unter Verwendung eines gegebenen Satzes von Anfragen/Diensten.
Jeder Dienst wird modelliert (anstelle jedes Datentyps) und die Beziehung zwischen jedem Dienst wird definiert (anstelle der Beziehung zwischen den Datentypen).
Die Implementierung einer Dienstmodellierung unter Verwendung relationaler Anfragen zur Befriedigung von X.500-Diensten ermöglicht die Vorteile von zu verwendenden RDBMS.
Dieser Lösungsversuch hat viele Vorteile. Eine Zusammenfassung ist in 3 angegeben. Einige dieser Vorzüge umfassen:

– relativ schnelle Startzeiten.
– Die Möglichkeit, Speicheranforderungen bezüglich speicherresistenter System zu reduzieren.
– Die Möglichkeit, X.500 auf einer SQL-Datenbank aufzubauen und dabei das Investment in Produkte, Erfahrungen und Prozesse im Umgang mit existierenden Systemen zu sichern.
– Die Möglichkeit, Leistung relativ unabhängig von der Größe und relativ unabhängig von der Komplexität der Datentypen zu erzielen. Jeder Datentyp wird allgemein behandelt. Jeder Datentyp hat auf demselben einen Index. Das Ergebnis der Indizierung ergibt die Möglichkeit effektiv im Directory zu suchen, ohne große Teile des Directorys in den Speicher zu laden. Im Gegensatz zu bekannten Systemen, in welchen entweder nur ein Index genutzt werden kann, um eine gegebene Anfrage zu befriedigen, oder große Bereiche von Informationen im System intensiv geladen und im Speicher durchsucht werden müssen.
– Die Möglichkeit, verschiedene Sprachen (zum Beispiel Spanisch, Hebräisch und Khanschi) zu unterstützen, welche eine Vielzahl unterschiedlicher, kritisch zu vergleichender Sequenzen aufweisen können, einzelne, doppelte oder andere Bitcharaktersätze können auch unterstützt werden.
– Verwendung eines Disk-basierten Modells zur Minimierung von Eingaben/Ausgaben und zur effektiven Abarbeitung von Eingaben/Ausgaben.
– Die Möglichkeit, komplexe X.500-Suchen auszuführen.
– Die Möglichkeit, X.500-Datenbanken zu erzeugen, und zwar von wesentlich größerer Größe als bisher möglich, ohne die Leistungsfähigkeit oder Robustheit zu beeinträchtigen. Die Datenbank kann klein oder groß (250000, 1 Million oder mehr Einträge) sein.
– Ein optimales Tabellendesign minimiert Verschwendung von Speicherraum.
– Die Möglichkeit Hunderte von Mannjahren von Erfahrungen in der Entwicklung relationaler Datenbanken auszunutzen und industriell erprobte Datenbanken mit bewiesener Zuverlässigkeit, Integrität, Sicherheit und Werkzeugen zur Entwicklung, hochleistungsfähiger Anwendungen auszunutzen.

Aufbauend auf diesem einzigartigen Lösungsweg, wird die folgende Offenbarung eine Anzahl von Erfindungen unter Bezugnahme auf 2A und 2B im Detail darstellen, wobei 2A und 2B schematisch einen Überblick des gegenwärtigen X.500-Systems geben. Die Tabellen und Spalten, Namen, die Anzahl der Spalten und die numerischen Werte werden auf einer beliebigen Basis zum Überblick angegeben. Die Anzahl der offenbarten Spalten gibt ein bevorzugtes ausführbares Beispiel wieder. Zusätzliche Spalten gehen der Verwendung der hier angegebenen Spalten nicht entgegen.
1. PRINZIPIELLES DESIGN
Dem X.500-Stand der Technik war es bei der Implementierung nicht möglich, die relativ einfachen, strukturellen und betrieblichen Unterschiede zwischen den X.500-Anforderungen und den Funktionalitäten sowie SQL zu überwinden. Der X.500-Standard hat von Natur aus eine praktische Struktur, wohingegen SQL entworfen ist, um relational strukturierte Tabellen zu betreiben.
Für eine typische, relationale Datenbankanwendung ist die Natur der Daten gut bekannt, so bestehen zum Beispiel Tabellen aus einer Anzahl von Spalten, und jede Spalte enthält Daten bezüglich eines speziellen Datentyps (s. Tabelle B1). Die unterschiedlichen Datentypen, die gespeichert werden können, ist auf die Anzahl der Spalten der Tabelle begrenzt. Die Datentypen sind ebenso begrenzt, auf die Typen, die von der Tabelle unterstützt werden (zum Beispiel ein String, numerische Daten, Geld, Datum). Die Datenbank kann auch Daten speichern, die eine Form haben, die aus der Datenbank heraus selbst nicht verständlich sind, jedoch durch die Anwendung zum Beispiel binärer Daten verstanden werden kann.
Tabelle B1: Arbeitnehmertabelle
Falls ein zusätzlicher Datentyp hinzugefügt werden muss (zum Beispiel mobile Telefonnummer), dann muss eine neue Spalte an die Tabelle angefügt werden. Dies kann Probleme verursachen, falls Änderungen der Datentabellen nicht einfach implementiert werden können. Weiterhin können sich dann, wenn der neue Datentyp nicht intensiv benutzt wird (zum Beispiel weniger als 1% der Organisation), signifikante, redundante Datenspeichermengen ergeben. Siehe Tabelle B2.
Tabelle B2: Arbeitnehmertabelle
Eine Erfindung in der Anwendung von X.500 liegt darin, die Erweiterbarkeit von X.500-Attributen nach dem Stand der Technik:
wie oben beschrieben dadurch zu überkommen, dass diese Zeichen wie folgt dargestellt werden
wobei die letztere Darstellung eine erweiterbare Darstellung ist und daher an eine Implementierung mit SQL angepasst ist. Die letztere Darstellung ist als Metadaten bekannt. Der Metadatenwert kann binär sein.
Eine weitere Weiterentwicklung aufbauend auf dem obigen prinzipiellen Design ist die Anpassung des prinzipiellen Design an X.500. Diese Anpassung wurde realisiert durch die Bereit stellung einer Eigenschaftstabelle, in welcher Objektname und Ursprungsname dem prinzipiellen Design zugefügt werden.
Weitere Vorteile ergeben sich aus der oben beschriebenen Implementierung; umfassend:

a. Unabhängigkeit von der Komplexität eines Filters – die offenbarte Implementierung kann einen in SQL bereitgestellten Anfrageoptimierer verwenden, und daher gibt es keine Notwendigkeit, einen Anfrageoptimierer in jeder Eigenschaftsdatenbank, in welcher die vorliegende Erfindung angewendet wird, zu replizieren,
b. Unabhängigkeit von Größe – die beschriebene Implementierung kann skaliert werden,
c. Unabhängigkeit von der Tiefe eines Baums – die offenbarte Implementierung hat hierarchische Vergleichseigenschaften,
d. Leistungsfähigkeit – falls ein Index auf einen Spaltentyp gesetzt ist, dann ist jeder oder jeder Typ indiziert.

2. KONZEPTIONELLES DESIGN
Der Stand der Technik hatte Schwierigkeiten in der Implementierung von X.500, da es nicht für Erweiterbarkeit, Objektorientierung und Hierarchie, welches Anforderungen an X.500 sind, strukturiert war.
Dies wird in Übereinstimmung mit der hier vorliegenden Erfindung dadurch adressiert, dass die Eigenschaftstabelle funktional zerlegt wird, und was in dem hier als konzeptionelles Design genannten Ergebnis mündet.
Das konzeptionelle Design liegt in der Bereitstellung von:

1. Attributtabellen, wobei die Erweiterbarkeit dadurch adressiert wird, dass die Definition eines neuen Attributtyps in der Tabelle ermöglicht wird durch das Hinzufügen einer Spalte der Tabelle;
2. Objekttabellen, welche die Attribute innerhalb eines jeden Objekts definieren; und/oder
3. Hierarchietabellen, welche die Beziehungen zwischen den Objekten definieren.

Die Struktur der Tabellen können in Übereinstimmung mit den in 2A und 2B gezeigten Strukturen sein.
Weitere bevorzugte Aspekte der Erfindung liegen in Adressierungsproblemen von Datentoleranzen durch die Bereitstellung eines gegenwärtigen X.500-Systems für den Austausch von Wertespalten eines Objekts mit dem Wert "Norm" und dem Wert "Raw" Spalten und/oder mit dem Austauschen der RDN-Spalte in der Hierarchietabelle durch "NameNorm"-Spalten und "NameRaw"-Spalten.
Weiterhin wird die Schwierigkeit von Systemen nach dem Stand der Technik in der Bereitstellung passender Alias-Daten dadurch adressiert, dass in einem vorhandenen X.500-System eine "Alias"-Spalte in der Hierarchietabelle bereitgestellt wird. Die "Alias"-Spalte ist hervorgehoben, um anzuzeigen, dass der Eintrag ein Alias ist.
Eine weitere Verbesserung kann durch das Ersetzen der "Alias"-Spalte durch Alias-Spalten und A-EID-Spalten bereitgestellt werden. Eine A-EID stellt Informationen darüber bereit, wo die Alias-Punkte sind.
Eine weitere Verbesserung kann darin liegen, dass die "Ursprung"-Spalte in der Hierarchietabelle durch "Ursprung"-Spalten und "Pfad"-Spalten ersetzt werden.
Der "Pfad" adressiert das Problem der Implementierung von X.500-Suchen, mit Alias und Unterbäumen. Der "Pfad" hat wenigstens zwei einzigartige Eigenschaften: a) die Bestimmung der absoluten Position in der Hierarchie; und b) die Bestimmung, ob ein Eintrag in einem gegebenen Unterbaum ist, wird durch die Verwendung dessen Präfix durchgeführt.
3. KONZEPTIONELLE METHODE
Eine Vielzahl einzigartiger Methoden zur Umsetzung des konzeptionellen Designs werden in der nachfolgenden, detaillierten Beschreibung offenbart, umfassend:

a) das Mappen von X.500-Diensten in eine Folge von SQL-Statements;
b) die Suchstrategie liegt in der Anwendung eines Filterns über den Suchbereich unter Verwendung der Pfadspalten oder Ursprungsspalten und/oder;
c) in der Handhabung mit Alias-Daten während der Navigation – wo ein Alias-Punkt in der A-EID-Spalte gespeichert ist;
d) in der Handhabung mit Alias-Daten während der Suche – Finden eines einzigartigen Satzes von Basisobjekten, welche Bereiche von Bäumen definieren, die durchsucht werden müssen, und dann Anwenden von b) auf jeden Bereich des Baums.

Eine weitere Erfindung ist realisiert durch die Verwendung der Attributtabelle für eingehende Daten, um in der AID-Form die X.500-Objekt-ID zu finden, und um ausgehende Daten aus der Datenbank zu lesen, und andersherum.
Weiterhin wird für jeden einkommenden, unterscheidenden Namen auf seine entsprechende EID navigiert, wobei dann jede Suche, wie von X.500 erfordert, durchgeführt wird.
Weiterhin kann eine jede Suche, Filter und Unterbaumsuche durch eine einzelne Pfadlösung unter Verwendung der Pfadspalte bereitgestellt werden. Eine Erfindung liegt in der Verwendung eines "Pfad"-Felds, um gleichzeitig einen beliebigen Filter über einen beliebigen Unterbaum anzuwenden. Die Komplikationen von Alias-Daten werden durch die Anwendung der oben beschriebenen Methode auf einen einzigartig aufgelösten Unterbaum angewendet.
Eine weitere einzigartige Methode liegt in der Speicherung des "Pfads" für jeden Eintrag als einen String. Jeder Pfad wird dann durch den Pfad und seinen ursprünglichen Eintrag vorbestimmt. Dies ist für den Filter im Suchdienst hilfreich.
4. LOGISCHES DESIGN
Das logische Design basiert auf einem Dienst, der das konzeptionelle Design zerlegt, wodurch die Realisierung der X.500-Servicekomponenten unabhängig wird.
Die hieraus sich ergebenden Vorteile umfassen:

1. Reduzierung der Anzahl von Indices je Tabelle, je mehr Tabellen bereitgestellt werden. Es hat sich herausgestellt, dass der erste Index der effektivste (Geschwindigkeit, Größe) ist und der zweite Index große Überhänge (Geschwindigkeit, Größe) aufweisen kann.
2. Die Ermöglichung des Clusterns der Daten in den Tabellen. Das Clustern ergibt sich als Ergebnis des ersten Schlüssels (Speicherstruktur), und daher können Daten auf der Platte um deren Schlüssel herum organisiert werden. Zum Beispiel können für die "Such"-Tabelle Nachnamen zusammengeclustert werden.
3. Management – kleinere Tabellen können einfacher gemanagt werden, zum Beispiel in einer schnelleren Erneuerung der Indices, im Sammeln von Statistiken, im Audit, im Backup usw.
4. Verringerten Eingaben/Ausgaben – Verbesserungen in der Geschwindigkeit in Folge von kleineren Spalten, was mehr Spalten je Zeile bedeutet und daher weniger Eingaben/Ausgaben durchgeführt werden müssen.

5. LOGISCHE METHODEN
In der folgenden Beschreibung wird eine Anzahl einzigartiger Methoden zur Anwendung der logischen Designtabellen beschrieben.
Zusätzlich liegt eine Methode im Zwischenspeichern der Attributstabellen. Daher werden (mit Ausnahme des anfänglichen Ladens) keine SQL-Statements in der Datenbank benötigt. Im vorhandenen X.500-System werden Umwandlungen im Speicher durchgeführt. Dies ermöglicht eine substantielle Geschwindigkeitsverbesserung.
Weiterhin wird die Validierung im Speicher durchgeführt, was ein Zurückrollen in der Datenbank überflüssig macht, das Zurückrollen ist sehr zeitintensiv und beansprucht das System.
Weiterhin wird für einen beliebigen Filter ein dynamisches SQL-Äquivalent gebildet. Dies ermöglicht beliebige Komplexität in X.500-Suchen.
Für Suchergebnisse verwendet das gegenwärtige System Satz-Orientierungs-Anfragen von SQL, um "Spalte zu einer Zeit" Bearbeitungen zu vermeiden. Als Folge können Suchergebnisse parallel im Speicher aufgebaut werden.
6. PHYSIKALISCHES DESIGN
Neue Tabellen und neue Spalten werden eingeführt, um Beschränkungen in der Spaltenbreite und Schlüsselgröße zu überwinden und um Platzoptimierungen zu ermöglichen.
Der folgende Text ist eine Offenbarung von Ausführungsbeispielen der Erfindung:
1. PRINZIPIELLES DESIGN
Unter Bezugnahme auf 2A adressiert das prinzipielle Design das grundlegende Problem der Darstellung der erweiterbaren, objektorientierten und hierarchischen Natur von X.500 in relationalen Tabellen. In diesem Abschnitt wird (mit Beispielen) beschrieben, dass das prinzipielle Tabellendesign durch eine einzelne Tabelle dargestellt werden kann, wie sie unten in Tabelle 1 dargestellt ist.
Tabelle 1 – X.500-Eigenschaftstabelle
Innerhalb dieser und der folgenden Abschnitte sind alle Spaltennamen und deren Positionen in jeder Tabelle beliebig. Die Absicht besteht darin, das zu definieren, was sie enthalten und wie sie benutzt werden.
1.1 Erweiterbarkeit
Für eine typische relationale Datenbankanwendung ist die Natur der Daten gut bekannt, so werden zum Beispiel die Tabellen aus einer Anzahl von Spalten bestehen und jede Spalte enthält Daten betreffend einen speziellen Datentyp (siehe Tabelle 1.1a). Die Tabelle ist selbstbeschreibend, so liegt zum Beispiel die Beziehung zwischen Datenobjekten, darin, dass sie in der selben Zeile angeordnet sind (das ist die Grundlage der relationalen Theorie).
Tabelle 1.1a – Typische relationale Datenbank
Der obige Lösungsweg ist jedoch nicht erweiterbar, weil die Anzahl der unterschiedlichen Datentypen auf die Anzahl der Spalten je Tabelle beschränkt ist. Falls ein neuer Datentyp hinzugefügt werden muss (zum Beispiel die mobile Telefonnummer), dann muss eine neue Spalte an die Tabelle angefügt werden (siehe Tabelle 1.1b). Jede Anwendung, die auf diese Tabelle zugreift, muss upgedatet werden, um explizit darauf zuzugreifen.
Tabelle 1.1b – Relationale Tabelle mit einer extra Spalte
In der Praxis bestehen auch andere Probleme. Falls ein neuer Datentyp nicht häufig verwendet wird (zum Beispiel weniger als 1% in der Organisation verfügt über eine mobile Telefonnummer), dann wird die Tabelle lückenhaft sein (zum Beispiel dann, falls eine gegebene Person über keine mobile Telefonnummer verfügt, dann wird der Zeilen/Spalten-Eintrag NULL sein). Weiterhin sind die Datentypen auf solche Typen beschränkt, die durch die Datenbank unterstützt werden (zum Beispiel String, numerisch, Geld, Datum, etc.).
Die Lösung liegt darin, die Datentypen als generic handzuhaben. Die vorliegenden Erfindung übernimmt die Methode der Darstellung beliebiger Attribute (zum Beispiel XOM[X/OPEN Objektmanagement] API [Anwendungsprogrammierungsinterface]) als eine Typ, Syntax, Wertkombination (s. Tabelle 1.1c).
Tabelle 1.1c – Darstellung beliebiger Attribute
1.2 Objektorientierung
X.500 definiert Objekte (zum Beispiel Personen, Organisationen, etc.), welche eine beliebige Anzahl von "Attributen" enthalten können. Da viele Objekte in der Tabelle auftreten können müssen, ist ein Mechanismus erforderlich, jedes Objekt voneinander zu unterscheiden. Eine Spalte "Objektname" wird für diesen Zweck an die Tabelle angefügt (siehe Tabelle 1.2a).
Tabelle 1.2a – Darstellung von Objekten mit beliebigen Werten
Die oben beschriebene Methode ermöglicht es, jede Anzahl von Attributen einem Eintrag zuzuordnen. Die Attribute können von beliebiger Komplexität sein (zum Beispiel kann eine mehrzeilige, postalische Adresse gehandelt werden). Da die Anzahl der Spalten fest ist, können neue Attribute zu jedem Objekt hinzugefügt werden, ohne dass die Anwendung neu definiert werden muss. Falls ein neues Attribut hinzugefügt wird, so wird eine Anwendung, welche den Eintrag liest, eine extra Zeile zurückbekommen.
1.3 Hierarchie
Ein Verfahren zur Darstellung hierarchischer Systeme (zum Beispiel Teile-Explosion) liegt in der Verwendung einer Ursprungs/Kind-Kombination (siehe Tabelle 1.3a).
Tabelle 1.3a – Teile-Explosion-Hierarchie
X.500 definiert seine Objekte so, dass sie hierarchisch sind. Die Beziehungen zwischen Objekten folgt einer Baumstruktur, wobei jedes Objekt ein Ursprungsobjekt und jedes Ursprungsobjekt ein oder mehrere Kinder aufweisen kann. Diese Beziehung kann in einer allgemeinen Eigenschaftstabelle dargestellt werden, indem eine Spalte "Ursprungsname" hinzugefügt wird, die verwendet wird, um den Namen des Ursprungsobjekts zu speichern (siehe Tabelle 1.3b).
Tabelle 1.3b – X.500-Eigenschaftstabelle
Es sollte bemerkt werden, dass die Wurzel des Baums keinen Ursprung hat. Falls also Chris und Alana beide für Datacraft arbeiten und Datacraft ein Kind der Wurzel ist, dann kann man sagen, dass Chris und Alana Kinder von Datacraft sind und dass Datacraft der Ursprung von Chris und Alana ist.
2. KONZEPTIONELLES DESIGN
In Abschnitt 1 wurde gezeigt, dass eine einzelne Eigenschaftstabelle die erweiterbare, objektorientierte und hierarchische Natur von X.500 darstellen kann (s. Tabelle 2a).
Tabelle 2a – Eigenschaftstabelle
Unter Bezugnahme auf 2a wird in diesem Abschnitt gezeigt, dass die volle X.500-Funktiohalität dargestellt werden kann, indem drei Tabellen benutzt werden, wie sie unten gezeigt werden (s. Tabelle 2b und 2A). Hierarchietabelle
Objekttabelle
Attributtabelle
Tabelle 2b – Volles, konzeptionelles Design
Das konzeptionelle Design adressiert die Hauptprobleme bei der Implementierung der vollen X.500-Funktionalität in relationalen Tabellen. Da jeder Hauptdesigngesichtpunkt dargestellt ist, werden Beispiele bereitgestellt, um die Lösung aufzuzeigen.
2.1 Funktionelle Zergliederung
Die Eigenschaftstabelle (2A) kann in einzelne Tabellen zergliedert werden, welche die hierarchische, objektorientierte und erweiterbare Natur von X.500 Wiederspiegeln, vorzugsweise wie folgt:

– eine Hierarchietabelle, die die strukturelle Beziehung zwischen den Objekten definiert,
– eine Objekttabelle, die die Attributwerte innerhalb jedes Objekts definiert,
– eine Attributtabelle, die die unterschiedlichen Attributwerte definiert.

Diese Tabellen ergeben sich aus einem Prozess, der als funktionale Zergliederung bezeichnet wird.
Um das Problem der Korrelierung von Beziehungen zwischen Tabellen zu adressieren, werden, beliebige, numerische Identifikatoren eingeführt. Der EID oder "Entry-Identifikator" korreliert jedes Objekt mit seiner hierarchischen Information. Der AID oder "Attribut-Identifikator" korreliert jeden Wert in der Objekttabelle mit dessen Attributinformation.
Das Design wird als sehr effizient bewertet, weil die sich wiederholenden Gruppen in der Eigenschaftstabelle (Typ-Syntax und Objektname-Ursprungsname) entfernt worden sind. Weiterhin sind für SQL die Verbindungsspalten einfache Integerwerte.
Hierarchietabelle
Objekttabelle
Attributtabelle
Tabelle 2.1 – Grundlegendes, konzeptionelles Design
2.2 X.500-Attribute
X.500-Attribute verfügen über einen Protokoll-Identifizierer, welcher transferiert wird, wenn irgendwelche Daten zwischen Endsystemen ausgetauscht werden. Diese Identifikatoren sind international definiert und werden als Objekt-Identifikatoren bezeichnet (zum Beispiel 2.5.4.4 bedeutet einen Nachname-String). Daher kann eine Spalte "Objekt-ID" an die Attributtabelle hinzugefügt werden, so dass ein Austausch zwischen X.500-Objekt-Identifikatoren und den internationalen Attribut-Identifikatoren durchgeführt werden kann.
Zusätzlich ermöglicht es X.500 einem Attribut eine beliebige Anzahl von Werten aufzuweisen (zum Beispiel kann eine mobile Telefonnummer einfach wie eine zweite Telefonnummer gehandhabt werden). Daher wird ein "Werte-Identifikator" oder VID eingeführt, um Werte innerhalb eines Attributs in der Objekttabelle zu identifizieren.
Hierarchische Tabelle
Objekttabelle
Attributtabelle
Tabelle 2.2 – Konzeptionelles Design mit X.500-Attributen
2.3 X.500-Namen
In X.500 verwendet jeder Eintrag eine oder mehrere seiner Attributwerte (unterscheidende Werte) zur Benennung der Einträge. Eine "Disting" Spalte wird an die Objekttabelle hinzugefügt, um sich unterscheidende Werte zu kennzeichnen.
Die sich unterscheidenden Werte kombinieren sich um einen relativen sich unterscheidenden Namen (RDN) zu bilden, welcher den Eintrag benennt. Eine "Name" Spalte in der hierarchischen Tabelle speichert den RDN. Dies ist eine Optimierung, die die Notwendigkeit aufhebt, den RDN aus den sich unterscheidenden Werten in der Objekttabelle zu konstruieren.
Ein Entry wird einzigartig benannt durch einen unterscheidenden Namen (DN), der aus allen RDNs seiner Ancestors ausgehend unten von der Wurzel und dem RDN seines Objekts selbst besteht. Eine Erfindung liegt darin, eine Spalte "Pfad" der Hierarchietabelle hinzuzufügen, welche die absolute Position eines Eintrags in dem Baum als eine Liste von EIDS definiert. Der Pfad verfügt über drei wichtige Eigenschaften:

1) Er ermöglicht die schnelle Konstruktion von DNs, (die EID-Liste definiert alle RDNs).
2) Er ermöglicht schnelle Unterbaum-Suchen (s. konzeptionelle Methoden).
3) Er ist unabhängig von seiner DN (jede der RDNs in der DN kann umbenannt werden, ohne den Pfad zu beeinflussen).

Hierarchietabelle
Objekttabelle
Attributtabelle
Tabelle 2.3 – Konzeptionelles Design mit X.500-Attributen und Namen
2.4 X.500-Aliases
X.500 hat auch ein Konzept von "Aliases". Ein Alias-Objekt zeigt effektiv auf einen anderen Eintrag und stellt daher einen alternativen Namen für diesen Eintrag bereit. Daher wird ein "Alias"-Flag an die Hierarchietabelle hinzugefügt. Wenn ein Alias während einer Navigation entdeckt wird (zum Beispiel enthält das bereitgestellte DN einen Alias), dann muss der Alias-Wert aus der Objekttabelle gelesen werden. Dieser Alias-DN muss dahin gelöst werden, wohin das Alias zeigt, bevor die Navigation mit dem Originaleintrag fortgesetzt werden kann.
Eine Erfindung liegt in der Verwendung einer Spalte "Alias EID" oder einer A-EID, um zu speichern, "wohin das Alias" zeigt. Dies beseitigt die Notwendigkeit, wiederholend durch ein Alias zu navigieren.
Hierarchietabelle
Objekttabelle
Attributtabelle
Tabelle 2.4 – Konzeptionelles Design mit X.500-Attributen, Namen und Aliases
2.5 X.500-Datentoleranz
Jedes X.500-Attribut hat eine (international definierte) Syntax. X.500-Attributsyntaxes definieren, wie ein Attribut gehandhabt werden soll. In allen String-Syntaxes (zum Beispiel printable, numeric, usw.) sollte überflüssiger Raum ignoriert werden. In einigen Syntaxes ist der Fall nicht wichtig (zum Beispiel Fall ignoriere String und Fall ignoriere Liste) und so können die Namen "Chris Masters", "Chris MASTERS" und "ChRis MaSTeRS" als identisch angesehen werden.
Um Vergleiche auszuführen (zum Beispiel Suche nach einem speziellen Wert), können die Syntax-Regeln angewendet werden, um eine normierte Form zu erzeugen (zum Beispiel "CHRIS MASTERS"). Falls diese normierte Form in der Datenbank gespeichert ist, dann können jegliche Abweichungen in der Eingabeform effektiv beseitigt werden, und eine exakte Übereinstimmung kann verwendet werden, was notwendig ist, wenn SQL verwendet wird.
Sowohl die normierten Daten als auch die "Raw" Daten werden in der Datenbank gespeichert. Die "Raw" Daten sind notwendig, damit die Benutzer die Daten exakt in dem Format empfangen können, wie sie ursprünglich eingegeben wurden. Daher wird die Spalte "Name" in der Hierarchietabelle zur Spalte "NamRaw" und eine Spalte "NameNorm" wird hinzugefügt. Ähnlich wird die Spalte "Wert" in der Objekttabelle zur Spalte "WertRaw" und eine Spalte "WertNorm" wird hinzugefügt.
Hierarchietabelle
Objekttabelle
Attributtabelle
Tabelle 2.5 – Volles, konzeptionelles Design
3. KONZEPTIONELLE METHODEN
Dieser Abschnitt führt in die grundlegende X.500-Dienste ein und zeigt, wie das in Tabelle 3a oder 2A gezeigte, konzeptionelle Tabelledesign, geeignet ist, um X.500-Dienste und deren Komplexitäten zu implementieren.
Hierarchische Tabelle
Objekttabelle
Attributtabelle
Tabelle 3a – Konzeptionelles Tabellendesign
Die Beispiel-Hierarchie, gezeigt in Tabelle 3, wird verwendet, um die Dienste zu verdeutlichen. Jeder Name in dem Diagramm gibt einen Objekteintrag in der Datenbank wieder. Das Dreieck gibt einen Alias-Eintrag wieder, und die gestrichelte Linie zeigt die Verbindung zwischen dem Alias-Eintrag und dem Objekt, auf das es zeigt. Die Nummern benachbart zu jedem Eintrag sind die Eintrag-IDs.
Im Beispiel verfügt der Eintrag "1" über eine RDN mit dem Wert "Datacraft", der Eintrag "11" verfügt über eine RDN mit einem Wert "Sales", der Eintrag "20" verfügt über eine RDN mit dem Wert "Network Products" und der Eintrag "31" verfügt über eine RDN mit dem Wert "Alana Morgan". Die DN des Eintrags "31" ergibt sich aus einer Folge der RDNs, nämlich "Datacraft", "Sales", "Network Products", "Alana Morgan".
Der Alias-Eintrag "Datacraft/Networks" zeigt auf den Eintrag "Datacraft", "Sales", "Network Products". Bei der Navigation zu diesem Eintrag würde der Navigationsprozess den Alias-Eintrag finden, dann die DN des Objekts finden, durch welches durch den Alias gezeigt wird, und dann ausgehend von der Wurzel auf den Objekteintrag navigieren, welcher eine EID von "20" und einen Pfad von "1.11.20." wiedergibt.
Tabelle 3b – Eintragbaum
Unten sind Beispieltabellen aufgeführt, die zeigen, wie Daten gespeichert sind. Die Hierarchietabelle (Tabelle 3c) zeigt, wie die Einträge in der Beispielhierarchie gespeichert sind. Die Attributtabelle (Tabelle 3e) zeigt, Attribute, die in dem Eintrag "Datacraft/Sales/Network Products/Chris Masters" enthalten sind. Die Objekttabelle (Tabelle 3d) zeigt, wie die Werte von diesen Attributen gespeichert sind.
Tabelle 3c – Beispiel Hierarchietabelle
Tabelle 3d – Beispiel Objekttabelle
Tabelle 3e – Beispiel Attributtabelle
Unterscheidende Namen
Für den in der Beispiel-Objekttabelle (Tabelle 3d) gezeigten Eintrag zwei der Attribute, common name und Nachname, sind sich unterscheidende Werte (oder Namenswerte), welche in Kombination den RDN für den Eintrag bilden. Dieser RDN ist in der Hierarchietabelle gespeichert.
Attribute mit mehreren Werten
In X.500 ist es für ein Attribut zulässig, mehrere Werte aufzuweisen. Die VID-Spalte wird benutzt, um zwischen Werten eines Attributs zu unterscheiden. Im Beispiel der Objekttabelle ist die Telefonnummer mit mehreren Werten.
3.1 Mapping-Dienste in SQL
3.1.1 Attributtypen und Werte
Alle durch einen X-500-Service bereitgestellten Daten sind als eine Liste von Objekt-IDs und deren zugehörigen Werten bereitgestellt. Dies muss in AIDS (unter Verwendung der Attributtabelle) konvertiert werden und in normierte Werte (unter Verwendung der Objekttabelle) zur Verwendung durch die X.500-Anwendung. Die Datenbank gibt Daten als AIDS und Raw- Werte zurück, die dann in Objekt-IDs und ihre zugehörigen Werte in dem X.500-Ergebnis konvertiert werden müssen.
3.1.2 Navigation
Jeder X.500-Dienst stellt einen unterscheidenden Namen bereit, der in eine EID für Verwendung durch eine X.500-Anwendung konvertiert ist. Wenn die Anwendung einen Dienst abarbeitet, gibt er ein oder mehrere EIDS zurück. Diese EIDS können kann zurück in unterscheidende Namen in dem X.500-Ergebnis zurückübersetzt werden.
Alle X.500-Dienste ruhen auf der Navigation des Directory-Baums. Um auf einen speziellen Eintrag zu navigieren, wird die folgende Prozedur durchgeführt:

– Ist die DN für den Eintrag gegeben, so ermittle den Eintrag in der Hierarchietabelle, der die RDN aufweist, die der ersten RDN in der DN entspricht.
– Speichere die EID.
– Ermittele rekursiv den Eintrag, der eine RDN aufweist, die gleich der nächsten RDN in der DN ist und die einen Ursprung hat, der gleich der gespeicherten EID ist.

Beispiel
Navigiere auf den Eintrag "Datacraft/Sales/Network Products/Peter Evans". Dies resultiert in einer Anzahl von Auswahl-Statements, wobei jede zurückgegebene EID als Wert des Ursprungs im nächsten Statement verwendet wird.
Wähle EID aus HIERARCHIE
Wo Ursprung = 0 und RDN = "DATACRAFT"
Wähle EID aus HIERARCHIE
Wo Ursprung = 1 und RDN = "SALES"
Wähle EID aus HIERARCHIE
Wo Ursprung = 11 und RDN = "NETWORK PRODUCTS"
Wähle EID aus HIERARCHIE
Wo Parent = 20 und RDN = "PETER EVANS"
3.1.3 Lesen
Ausgewählte Attribute, die gelesen werden, können bereitgestellt werden. Nur die Werte dieser Attribute (falls sie in dem Eintrag vorliegen) werden zurückgegeben.
"Typen only" können als Leseoption gewählt werden, wobei in diesem Fall keine Werte zurückgegeben werden. Alle in einem Eintrag vorliegenden Typen, oder die ausgewählten, werden zurückgegeben werden.
Navigieren zu dem Eintrag, der gelesen werden soll. Speichere die EID. Lese in der Objekttabelle die Werte von allen Spalten, die der gespeicherten EID entsprechen.
Beispiel
Lese den Eintrag "Datacraft/HQ/Network Products" und gebe alle Typen und Werte aus.
Navigiere zu dem Eintrag (wie in 3.1.2) und dann;
wähle AID, ValueRaw aus Objekt
wo EID = 20.
3.1.4 Vergleichen
Die Vergleichsfunktion gibt ein "übereinstimmendes" oder "nicht übereinstimmendes" Ergebnis zurück. Der Raw-Wert ist ein Eingang, die Vergleichsfunktion wird jedoch unter Verwendung des normierten Werts durchgeführt.
Navigiere auf den erforderten Eintrag. Speichere die EID. Teste die Objekttabelle nach einem passenden Wert in allen Spalten, die der gespeicherten EID und dem spezifizierten AID entsprechen.
Beispiel
Vergleiche die Telefonnummer "03 272 9256" mit dem Eintrag "Datacraft/Sales/Network Products/Chris Masters".
Navigiere zu dem Eintrag und dann;
wähle ValueRaw aus dem Objekt
wo EID = 30
und AID = 20
und ValueNorm = "03 727 9456".
Falls ein Wert ausgewählt wird, gebe "übereinstimmend" zurück, anderenfalls gebe "nicht übereinstimmend" zurück.
3.1.5 Liste
Navigiere auf den erforderlichen Eintrag. Speichere die EID. In der Hierarchietabelle gebe die RDNs für alle Spalten mit einem Ursprung entsprechend der gespeicherten EID zurück.
Beispiel
Liste aus dem Eintrag "Datacraft/Sales".
Navigiere auf den Eintrag und dann;
wähle NameRaw aus Hierarchie
wo Ursprung = 11.
3.1.6 Füge Eintrag hinzu
Navigiere auf den erforderlichen Ursprungseintrag. Speichere die EID des Ursprungs. Füge eine neue EID in der Hierarchietabelle hinzu und füge Spalten in der Objekttabelle für jeden Wert im neuen Eintrag hinzu.
Beispiel
Füge einen neuen Eintrag unter dem Eintrag "Datacraft/Sales/ Network Products" hinzu.
Navigiere zu dem Eintrag und dann;
füge ein in Objekt
(EID, AID, VID, Disting, ValueNorm, ValueRaw)
Werte (33, 3, 1, 1, EDWIN MAHER, Edwin Maher)
und
füge ein in Hierarchie
(EID, Urspruch, Pfad, Alias, A-EID, NameNorm, NameRaw)
Werte (33, 20, 1.11.20.33., 0, 0, EDWIN MAHER, Edwin Maher).
3.1.7 Entferne Einträge
Navigiere auf den erforderlichen Eintrag, prüfe, ob der Eintrag im Baum ein Blatt ist (zum Beispiel prüfe, dass es keine Untereinträge in dem Baum gibt). Speichere die EID. Entferne den Eintrag aus der Hierarchietabelle. Entferne in der Objekttabelle alle Spalten, die der gespeicherten EID entsprechen.
Beispiel
Entferne einen Eintrag (mit EID = 33) unter dem Eintrag "Datacraft/Sales/Network Products".
Navigiere auf den Eintrag und dann;
entferne aus Objekt
wo EID = 33
und
entferne aus Hierarchie
wo EID = 33.
3.1.8 Ändere Eintrag ab
Navigiere auf den erforderlichen Eintrag. Speichere die EID. Füge in der Objekttabelle zu, entferne oder modifiziere Spalten in Übereinstimmung mit der gespeicherten EID.
Beispiel
Modifiziere den Eintrag "Datacraft/Sales/Network Products/Alana Morgan".
Füge den Wert hinzu – Titel = "Branch Manager"
Navigieren auf den Eintrag und dann;
wähle aus EID, AID, VID, ValueNorm aus dem Objekt
wo EID = 31
überprüfe die zurückgegebenen Spalten für ein Attribut aus Titel, falls keines existiert, kann das Attribut hinzugefügt werden, anderenfalls muss das Attribut überprüft werden, um festzustellen, falls es mehrere Werte aufweisen kann und ob es bereits existiert.
Füge ein in Objekt
(EID, AID, VID, Disting, ValueNorm, ValueRaw)
Werte (31, 12, 1, 0, BRANCH MANAGER, Branch Manager).
3.1.9 Ändere RDN ab
Navigiere auf den erforderlichen Eintrag. Prüfe, dass der neue Name (RDN) nicht existiert im gegenwärtigen Level des Unterbaums (zum Beispiel, dass die neue DN unterscheidungskräftig ist). Speichere die EID. Modifiziere den Eintrag in der Hierarchietabelle und Objekttabelle.
Beispiel
Modifiziere die RDN des Eintrags "Datacraft/Sales/Network Products/Chris Masters" in "Christine Masters".
Navigiere auf den Eintrag und dann;
wähle EID aus Hierarchie
wo Ursprung = 20
und ValueNorm = "CHRISTINE MASTERS".
Falls keine Werte zurückgegeben werden, kann die neue RDN eingefügt werden. Setze zuerst die alte RDN auf einen nicht-unterscheidungskräftigen Wert.
Update Objekt
setze Disting = 0
wo EID = 30 und ValueNorm "CHRIS"
und
update Hierarchie
setze NameNorm = "CHRISTINE MASTERS" und
setze NameRaw = "Christine Masters"
wo EID = 30
und
füge ein in Objekt
(EID, AID, VID, Disting, WertNorm, WertRaw)
Werte (30, 3, 1, 1, "CHRISTINE", "Christine").
3.2 Suchstrategie
Der leistungsfähigste und nutzvollste X.500-Dienst ist der Suchdienst. Der Suchdienst erlaubt es, einen beliebig komplexen Filter über einen Bereich eines Directory-Informationsbaums (den Suchbereich) anzuwenden.

– Ein Filter ist eine Kombination einer oder mehrerer Filtergesichtspunkte, verknüpft durch die Operatoren AND, OR und NOT. Zum Beispiel; Nachname = "Masters" und Titel = "Sales Manager".
– Der Suchbereich ist ein Abschnitt des Baums, der durch die Suche abgedeckt wird (Basis-Objekt-ausschließlich, Ein-Level oder Gesamt-Unterbaum).

Eine Technik zum Lösen von Suchen liegt in der Anwendung des Filters und dann in der Überprüfung, ob in dem Suchbereich irgendwelche übereinstimmenden Einträge vorliegen. In diesem Fall ist ein Filter auf den gesamten Baum anzuwenden und EIDS für alle Spalten, die mit dem Filter übereinstimmen, werden zurückgegeben. Dann wird für jede gefundene EID eine Schrittsuche durch die Hierarchie durchgeführt, um zu überprüfen, ob der Eintrag ein Unterordnung eines Basisobjekts ist (zum Beispiel hat der Eintrag einen Ursprung/Urursprung/..., der das Basisobjekt ist). Falls die Anzahl der Übereinstimmungen groß ist und der Unterbaum klein ist, ist dies sehr ineffizient. Diese Technik trägt nicht den Aliases Rechnung, weil ein Alias kein Ursprung für ein Objekt ist, auf das es zeigt, und weil viele Aliases auf ein einzelnes Objekt zeigen können.
Eine zweite Strategie liegt darin, eine Liste aller EIDS in dem Suchbereich zu erhalten und dann den Filter auf diese EIDS anzuwenden. Falls ein Alias aufgelöst wird, das außerhalb des ursprünglichen Suchbereichs zeigt, dann wird der Un terbaum, auf den durch das Alias gezeigt wird, erweitert und die EIDs in dem Unterbaum werden an die Liste angehängt. Der Filter wird dann auf die erweiterten EIDs angewendet. Dies ist ziemlich schlecht, falls der Suchbereich groß ist.
Eine Erfindung liegt in der gleichzeitigen Anwendung des Filters über dem Suchbereich (anstelle der sequentiellen Anwendung wie in den beiden obigen Methoden beschrieben). Dies wird als Single-Pass-Lösung bezeichnet. Dieses Verfahren ist geeignet, um eine merkliche Leistungssteigerung über den obigen Methoden bereitzustellen, weil die Spalten, die empfangen werden, die sind, die sowohl den Filter als auch die Umfangsanforderungen der Suche erfüllen.
Bei Ausführung einer einstufigen Suche, wird der Filter auf alle Einträge angewandt, die einen Ursprung aufweisen, der dem EID des Basisobjekts entspricht (zum Beispiel; Suche wo Ursprung = 20 wird den Filter auf die Einträge 30, 31 und 32 anwenden).
Bei der Ausführung einer Unterbaumsuche wird der Pfad verwendet, um die Suche auf den Suchbereich auszudehnen. Der "Pfad" für jeden Eintrag ist eine String von Zahlen (zum Beispiel "1.10.50.222.", der anzeigt, dass der Eintrag 222 einen Ursprung von 50 hat, einen Urursprung von 10 und einen Ururursprung von 1). Der Pfad verfügt über die einzigartige Eigenschaft, dass der Pfad eines jeden Eintrags ein Präfix des Pfads für alle Einträge ist, die dem Eintrag untergeordnet sind. Der Pfad eines Eintrags bildet das Präfix des Pfads für alle Einträge im Unterbaum unterhalb des Eintrags. Daher erhält man, wenn man eine Unterbaumsuche ausführt, das Basisobjekt des Unterbaums und dann wird der Filter auf alle Einträge angewendet, die einen durch den Pfad des Basisobjekts be reitgestelltes Präfix aufweisen (zum Beispiel; zur Suche nach allen Einträgen unter "Sales" wird eine Suche durchgeführt, wo der Pfad entspricht 1.1.%).
Basisobjektsuche:
Navigiere auf das Basisobjekt. Speichere die EID. Lese in der Objekttabelle normierte Werte der Spalten, die der gespeicherten EID entsprechen, wo ein Filterkriterium erfüllt ist, zum Beispiel Telefon-Präfix = "727".
Beispiel
Suche nach dem Basisobjekt "Datacraft/Sales/Network Products" für einen Eintrag mit dem Nachname = "Morgan", unter Verwendung einer "Base-Object-Only"-Suche.
Navigier auf das Basisobjekt und dann;
wähle AID, ValueRaw aus Objekt
wo EID = 20 und AID = 4
und NameNorm = "MORGAN".
Einstufige Suche:
Navigiere auf das Basisobjekt. Speichere die EID. Gebe eine Liste von EIDs aus, welche eine Ursprungs-EID in Übereinstimmung mit der gespeicherten EID (in der Hierarchietabelle) haben und Werte aufweisen, die das Filterkriterium (Objekttabelle) erfüllen. Lese in der Objekttabelle normierte Werte für die zurückgegebenen EIDS aus.
Beispiel
Suche aus dem Basisobjekt "Datacraft/Sales/Network Products" für einen Eintrag mit dem Nachnamen = "MORGAN", verwende eine "One-Level-Only" Suche.
Navigiere auf das Basisobjekt und dann;
wähle H.EID aus Hierarchie h, Objekt 0
wo Ursprung = 20 und AID = 4 und NameNorm = "MORGAN"
und H.EID gleich O.EID
dann platziere die zurückgegebenen EIDS in die EID-Liste und
wähle AID, ValueRaw aus Objekt
wo EID in [EID-Liste].
Unterbaumsuche:
Navigiere auf das Basisobjekt. Speichere die EID. Gebe die Liste von allen EIDs zurück mit einem Pfad entsprechend dem Basisobjekt (Hierarchietabelle) und Werten, die das Filterkriterium (Objekttabelle) erfüllen. Lese in der Objekttabelle die normierten Werte für die zurückgegebenen EIDs.
Beispiel
Suche aus dem Basisobjekt "Datacraft/Sales/Network Products" für einen Eintrag mit dem Nachnamen = "MORGAN", unter Verwendung einer "Whole-Subtree"-Suche.
Navigiere auf das Basisobjekt und dann;
wähle H.EID aus Hierarchie h, Objekt O
wo Pfad ähnlich "1.11.20%" und AID = 4
und NameNorm = "MORGAN"
und H.EID = O.EID.
Dann platziere die zurückgegebenen EIDs in die EID-Liste und
wähle AID, ValueRaw aus Objekt
wo EID in [EID-Liste].
3.3. Aliases und Navigation
Aliases werden während der Navigation aufgelöst, falls das "Don't-Dereference-Alias" Zeichen nicht gesetzt ist und der Dienst kein Update-Dienst (add, delete, modify, modify RDN) ist.
Falls ein Alias während der Navigation erkannt wird, muss das Alias aufgelöst werden. Das bedeutet, dass das Objekt erhalten werden muss, auf das das Alias zeigt. Zuerst wird die A-EID-Spalte der Hierarchietabelle überprüft. Falls A-EID 0 ist, so muss das Objekt, auf das das Alias zeigt, aus der Objekttabelle erhalten werden, und das Objekt muss dann darauf navigiert werden und die sich ergebene EID muss in der A-EID-Spalte gespeichert werden. Falls dies erfolgreich durchgeführt wird, kann das Verbleibende des Pfads navigiert werden. Durch das Speicherns des EID des Alias-Objekts in der A-EID-Spalte der Hierarchietabelle ist es möglich, das Navigieren auf Alias-Objekte zu vermeiden. Hierdurch kann Zeit gespart werden, insbesondere falls die Alias-Objekte sich in einem niederen Level der Hierarchie befinden.
3.4 Aliases und Suche
Aliases werden während der Suche dereferenziert, falls das "Search-Aliases-Zeichen" im Suchkriterium gesetzt ist. Die Leistung des Suchdienstes während der Dereferenzierung der Aliases ist ein zweistufiger Prozess. Zuerst definiert man den Suchbereich und wendet den Filter auf die Einträge im Suchbereich an. Dereferenzierte Aliases als Teil des Suchdienstes können den Suchbereich, auf den der Filter angewendet wird, aufweiten. Sie schränken auch den Suchbereich ein, indem alle dereferenzierten Aliases aus dem Suchbereich ausgeschlossen werden.
Aliases und einstufige Suche
Falls Aliases als Teil einer einstufigen Suche dereferenziert werden und ein Alias-Eintrag gefunden wird, muss das Alias aufgelöst werden (unter Verwendung der Objekttabelle oder der A-EID). Das Alias-Objekt wird dann dem Suchbereich hinzugefügt, auf welchen der Filter angewendet wird. In einer einstufigen Suche, in welcher Aliases gefunden werden, wird der Suchbereich aus Nicht-Alias-Einträgen bestehen, die direkt dem Basisobjekt und allen dereferenzierten Aliases untergeordnet sind.
Aliases und Unterbaumsuche
Falls Aliases als Teil einer gesamten Unterbaumsuche dereferenziert werden und ein Alias-Eintrag gefunden wird, muss dieser Alias-Eintrag aufgelöst werden (unter Verwendung der Objekttabelle oder der A-EID) und dieses EID muss dann als ein anderes Basisobjekt behandelt werden, es sei denn es ist Teil eines bereits abgearbeiteten Unterbaums.
Wenn Aliases während einer Suche dereferenziert werden, kann die "Pfad"-Spalte genutzt werden, um Alias-Entries innerhalb einer Unterbaum-Verzweigung zu finden. Falls ein Alias-Entry gefunden wird, der außerhalb des gegenwärtigen Unterbaums zeigt, dann kann der Unterbaum, auf den durch das Alias gezeigt wird, auch nach Aliases durchsucht werden. Eine Eigenschaft der hierarchischen Baumstruktur liegt darin, dass jeder Unterbaum durch ein einzigartiges Basisobjekt einzigartig repräsentiert wird (zum Beispiel überlappen sich Unterbäume nicht). Wenn eine Unterbaumsuche durchgeführt wird, wird eine Liste von Basisobjekten aufgebaut, die einzigartige Unterbäume definieren. Falls keine Aliases gefunden werden, wird diese Liste lediglich ein Basisobjekt enthalten. Falls ein Alias gefunden wird, das außerhalb des bearbeiteten Unterbaums zeigt, wird ein Alias-Objekt zu der Liste des Basisobjekts hinzugefügt (es sei denn, das eine oder mehrere der Basisobjekte den Alias-Objekt untergeordnet sind, wobei in diesem Fall, die untergeordneten Basisobjekte durch das Alias-Objekt ersetzt werden). Der Suchbereich wird daher Nicht-Alias-Entries umfassen, die einen Pfad aufweisen, dessen Präfix durch den Pfad eines oder mehrerer Basisobjekte bestimmt wird.
4. LOGISCHES DESIGN
Obwohl das konzeptionelle Design (s. Tabelle 4a) ausreichend ist, um die X.500-Funktionalität zu implementieren, können weitere Leistungsverbesserungen erzielt werden.
Hierarchische Tabelle
Objekttabelle
Attributtabelle
Tabelle 4a – Konzeptionelles Design
Leistungssteigerungen in diesem konventionellen, relationalen Design können erzielt werden, weil Annahmen über die Daten getroffen werden können – die Daten sind im Wesentlichen fi xiert zu der Zeit, zu der die Anwendung entworfen wird. In X.500 ist keine der Datentypen bekannt. Es können jedoch Leistungsverbesserungen erzielt werden, weil Annahmen über die Dienste getroffen werden können – diese sind zu der Zeit, zu der die X.500-Anwendung entworfen wird, bekannt.
Unter Bezugnahme auf 2B liegt eine Erfindung darin, zu erkennen, dass jede Tabelle um eine Hauptdienst-Beziehung herum organisiert werden kann (anstelle der Organisation um eine Hauptdaten-Beziehung herum wie nach dem konventionellen, relationalen Design). Es soll gezeigt werden, dass die obigen Tabellen in eine Anzahl kleinerer Tabellen und effektiveren Tabellen zerlegt werden können, wie dies unten dargestellt ist.
DIT
Name
Baum
Alias
Suche
Entry
ATTR
Tabelle 4b – Logisches Design
4.1 Dienstzergliederung
Die praktische Realität der meisten RDBMS's liegt in großen Tabellen mit vielen Spalten, die weniger gut arbeiten als kleine Tabellen mit weniger Spalten. Die Hauptgründe liegen in der Indizierung von Optionen, in der Eingabe/Ausgabeleistung und im Tabellenmanagement (s. Abschnitte 4.5 und 4.6). Das ist der Grund, warum relationalen Designtechniken nach dem Stand der Technik primäre Informationen nicht in getrennte Tabellen fokusieren und sekundäre Informationen aus Tabellenverbindungen ableiten (zum Beispiel Normalisierung und Fragmentierungstechniken).
Eine Neuerung in der Erzielung von X.500 Leistungsfähigkeit liegt in der Zergliederung von Tabellen um primäre Dienstbeziehungen herum und in dem Ableiten von sekundären Diensten über Verbindungen. Dieser Prozess wird als Dienstzergliederung bezeichnet. Die folgenden Überlegungen werden angestellt:

(1) Spalten, die starke Beziehungen aufweisen, werden bevorzugt zusammengehalten (um unnötige Verbindungen zu vermeiden);
(2) falls die Anzahl der signifikanten Zeilen in einer gegebenen Spalte unabhängig von den anderen bezogenen Spalten ist, dann ist die gegebene Spalte ein Kandidat für eine separate Tabelle;
(3) falls eine Spalte nur zur Lokalisierung von Information (Eingabe) oder nur zur Rückübertrage von Ergebnissen (Ausgabe) verwendet wird, dann ist dieselbe ein Kandidat für eine eigene Tabelle;
(4) falls eine Spalte als ein Schlüssel für einen oder mehrere Dienste verwendet wird, dann ist diese bevorzugt ein erster Schlüssel und dafür in einer eigenen Tabelle (jede Tabelle kann nur einen primären Schlüssel aufweisen);
(5) Schlüssel sind bevorzugt einzigartig oder wenigstens stark (nicht-wiederholend).

Eine ersten Stufenanalyse der Spaltenverwendung ist in Tabelle 4.1 gezeigt.
Tabelle 4.1 – Basisspaltenverwendung#
Schlüsselsymbole in der obigen Tabelle sind:

H: hierarchische Tabelle
O: Objekttabelle
S: bereitgestellte Wert (verwendet in SQL zum Suchen der Tabelle)
R: zurückübertragener Wert (Wert entnommen aus den Tabellen)
( ): Punkt, der oder der nicht vorhanden sein kann, abhängig von den Optionen der Dienste.

Ausgehend von der obigen Information und der weiteren Analyse kann die konzeptionelle Designtabelle weiter zergliedert werden in eine Anzahl kleineren Tabellen, wie dies in den nachfolgenden Abschnitten beschrieben wird.
4.2 Zergliederung der Hierarchietabelle
Die Hierarchietabelle umfasst die folgenden Spalten:
Tabelle 4.2a – Hierarchietabelle
Die Hierarchietabelle enthält Informationen über Objekte und deren Ursprünge, deren Namen, deren absolute Position in der Hierarchie und ggf. über die Aliases. Diese Tabelle kann daher in vier Tabellen aufgespalten werden: DIT, Name, Baum und Alias.
Die Ursprungsinformation wird verwendet, um ein gegebenes Kind aufzufinden oder um diese auf Einträge anzuwenden, die einen gegebenen Ursprung haben. Zum Auffinden eines Kinds (zum Beispiel Ursprung = 0, NameNorm = "Datacraft") ist die Basis zur Navigation und zur Update-Überprüfung (Überprüfung der Existenz eines Objekts bevor dem Hinzufügen oder Modifizieren der RDN). Das Agieren bzw. Anwenden auf Eingaben, die einen gegebenen Ursprung haben, wird während des Auflistens oder der einstufigen Suche verwendet. Daher hat die DIT-Tabelle (Directory Informationsbaum) Informationen, die zur Navigation benötigt werden, sie ermöglicht es jedoch, dass deren Ursprungsspalte für andere Dienste verwendet wird.
Tabelle 4.2b – DIT-Tabelle
Ein Objekt wird aus seinen Abkömmlingen abgeleitet über den relativ unterscheidenden Namen (RDN). RDNs werden für eine Liste zurückübertragen (in Verbindung mit einem gegebenen Ursprung) oder als Teil eines voll unterscheidenden Namens (Lesen, Suchen). Daher verfügt die Namentabelle über Informationen, die zur Zurückübertragung von Namen benötigt werden (die RawRDN).
Tabelle 4.2c – Namentabelle
Die absolute Position eines Objekts in der Hierarchie ist erforderlich, um die DN's aufzubauen (aus der die RawRDNs empfangen werden) und um Unterbäume während der Suche auszuweiten. Daher verfügt die Baumtabelle über Informationen über den Pfad eines Eintrags (die Folge von EIDs, ausgehend von der Wurzel).
Tabelle 4.2d – Baumtabelle
Alias-Information wird zwischengespeichert, so dass zu jeder Zeit, zu der ein Alias während der Navigation verwendet wird, es nicht wiederholend aufgelöst werden muss. Als Folge enthält die Alias-Tabelle nur Einträge, die Aliases sind. Dies wird auch während der einstufigen Suche (in Verbindung mit der DIT-Ursprungsspalte) und der Unterbaumsuche (in Verbindung mit der Pfadspalte) verwendet, um zu bestimmen, ob es irgendwelche Aliases im Suchbereich gibt.
Tabelle 4.2e – Aliastabelle
4.3 Zergliederung der Objekttabelle
Die Objekttabelle enthält die folgenden Spalten:
Tabelle 4.3a – Objekttabelle
Die Objekttabelle erhält im Wesentlichen Informationen zum Auffinden eines speziellen Werts (zum Beispiel AID = Nachname, ValueNorm = "HARVEY") und zum Empfangen von Werten (zum Beispiel AID = Nachname, ValueRaw = "Harvey"). Diese Tabelle kann daher in zwei Untertabellen aufgesplittet werden: Suche und Eingabe.
Die Suchetabelle wird verwendet, um Filter im Suchdienst aufzulösen. Es wird auch verwendet, um Werte während des Vergleichens, Modifizierens oder Modifizierens der RDN aufzufinden. Die Suchtabelle enthält eine Zeile für jeden Attributwert eines Eintrags. Nur die normierten Werte sind in dieser Tabelle gespeichert.
Tabelle 4.3b – Suchtabelle
Die Eingabetabelle wird verwendet, um Werte in Lesen und Suchen auszugeben. Die Eingabetabelle enthält eine Zeile für jeden Attributwert eines jeden Eintrags. Der RawWert ist der Wert, wie exakt ursprünglich bereitgestellt, wenn der Eintrag hinzugefügt oder modifiziert wurde.
Tabelle 4.3c – Eingabetabelle
4.4 Attributtabelle
Die Attributtabelle entspricht im Wesentlichen dem konzeptionellen Design. In der Praxis ist das "Typ"-Feld nur beschreibend, weil jeder eingehende/ausgehende X.500-Objekt-Identifikator in den ursprünglichen bzw. aus dem ursprünglichen Attribut-Identifikator AID konvertiert wird. Daher wurde diese Spalte in DESC umbenannt, um anzuzeigen, dass es sich um ein beschreibendes Feld handelt.
Tabelle 4.4 – ATTR-Tabelle
4.5 Indexauswahl
Bei Verwendung von SQL kann eine Leistung erzielt werden, weil der RDBMS in der Lage ist, eine Anfrage unter Verwendung eines relevanten Index zu befriedigen. Das bedeutet, dass jede Anfrage, die eine Bedingung aufweist (die "where" Bedingung in SQL) bevorzugt einen zugeordneten Index aufweist (anderenfalls hat die RDBMS die Tabelle bezüglich eines Pegelscans neu zu sortieren). In praktischen RDBMS's gilt jedoch:

– dass die Anzahl der Indices beschränkt ist;
– dass es einen großen Overhead gibt, um sekundäre Indices zu erlangen;
– dass zusammengesetzte Indices benötigt werden, um eine Anfrage zu befriedigen. Daher können, falls eine Anfrage über Spalten (zum Beispiel; Typ = Vorname und Wert = "Smith") durchgeführt wird, separate Indices auf Typ und Wert nicht in einen vollständig indizierten Zugriff resultieren. Ein zusammengesetzter Index sowohl für Typ und Wert mag erforderlich sein.

Eine Neuerung in der Tabellenzergliederung in den vorangegangenen Abschnitten liegt in der Maximierung der Verwendung von primären Indices über die Tabellen. Dies reduziert die Anzahl der sekundären Indices (zum Beispiel werden diese primäre Indices ihre eigenen Tabellen). Nachfolgend ist eine Liste von Indices für jede der sechs Tabellen wiedergegeben, die im logischen Design verwendet werden.
Tabelle 4.5 – Tabellenindices des logischen Designs
Das Tabellendesign bedeutet, dass viele Anfragen ohne Verknüpfungen gehandhabt werden können, was merkliche Leistungsverbesserungen ermöglicht.
Die Verknüpfungen, die als notwendig angesehen werden, sind unten angegeben:

– Auflisten – zum Rückübertragen der Raw-RDNs unter einem gegebenen Objekt (DIT verknüpft mit Name);
– Suche/Unterbaum – zum Auffinden der EIDS, die einen Filter über einen gesamten Unterbaum erfüllen (wo das Basisobjekt nicht die Wurzel ist) (Baum verknüpft mit Suche);
– Suche/einstufig – zum Auffinden der EIDs, die einen einstufigen Filter unter dem Basisobjekt erfüllen (DIT verknüpft mit Suche);
– Suche/Aliases/Unterbaum – zum Auffinden aller Aliases in einem Unterbaum (Baum verknüpft mit Alias);
– Suche/Aliases/einstufig – zum Auffinden aller Aliases unter einem gegebenen Objekt (DIT verknüpft mit Alias).

Bemerke, dass die oben angegebenen Verknüpfungen alle einstufig Verknüpfungen sind (zum Beispiel zwischen nur zwei Tabellen). Es ist wünschenswert, keine Verknüpfungen höherer Ordnung zu verwenden.
4.6 Eingabe/Ausgabe-Leistung
Eine Neuerung in der Zergliederung von Tabellen um Dienste herum, was die Anzahl der Tabellen vergrößert, liegt darin, dass die neuen Tabellen wesentlich kleiner sind als die unfragmentierten Tabellen. Dies kann merklich den Betrag von Eingaben/Ausgaben wegen der folgenden Gründe reduzieren:
Spaltengröße
Durch Verringerung der Anzahl der Spalten in jeder Reihe wird die Reihenbreite verkürzt. Dies bedeutet, dass mehr Zeilen auf eine Seite passen (wo angenommen wird, dass eine Disk Eingabe/Ausgabe auf einer "Seite" von Informationen erscheint). In Kombination mit dem unten angegebenen Clustering müssen immer dann, wenn ein Satz von Zeilen empfangen werden muss, nur eine (oder ein paar) Seiten aus der Disk gelesen werden (zum Beispiel, wenn Attribute eines Objekts gelesen werden, falls die Eingabetabelle auf EID, AID, VID geschlüsselt ist, dann werden alle Zeilen betreffend dieses Objekts zusammensein und sich wahrscheinlich auf einer Seite befinden).
Clustering
Jede der fragmentierten Tabellen umfasst bevorzugterweise ihren eigenen (unabhängigen) primären Schlüssel, der es denselben ermöglicht, Daten danach zu Clustern, wie diese verwendet werden. Der primäre Schlüssel kann die "Speicherstruktur" vorgeben. So werden in der Suchtabelle, falls der primäre Schlüssel auf AID, Norm (zum Beispiel Typ, Wert) besetzt ist, alle Daten des selben Typs (zum Beispiel Nachname) oder ähnliche Werte (zum Beispiel Harvey, Harrison) im selben Bereich der Disk geclustert. Das bedeutet, dass während einer Suche (zum Beispiel Nachnamen beginnend mit "har") ähnliche Daten auf einer (oder einiger weniger) Diskseiten gesammelt werden. Falls die Zeilen klein sind, so wird die Anzahl der zu adressierenden Diskseiten merklich reduziert.
Zwischenspeichern (Caching)
Die kommerziell geläufigsten RDMBS's verfügen über die Möglichkeit, Seiten, auf die häufig zugegriffen wird, zwischenzuspeichern. Weil Tabellen effektiv der Eingabe (zum Beispiel Navigation unter Verwendung der DIT-Tabelle) oder der Ausgabe (zum Beispiel Empfangen von Informationen aus der Eingabeta belle) dienen, werden ähnliche Anfragen (zum Beispiel Suchen über den selben Bereich eines Baums) dazu führen, dass häufig benutzte Seiten zwischengespeichert werden, was bedeutet, dass häufig erteilte Anfragen deutliche Verbesserungen beisteuern. Weiterhin ist die Zwischenspeicherung auch effektiver, da die Seiten "informationsintensiv sind", was sich als Folge einer kleinen Zeilengröße und des Clusterings ergibt.
Management
Kleinere Tabellen sind wesentlich einfacher zu managen: zum Beispiel anzuschauen, zu erzeugen, zu indizieren, Statistiken zu erzeugen, für Auditing, für Backups, usw.
5. LOGISCHE METHODEN
Dieser Abschnitt beschreibt Methoden des Zusammenspiels der logischen Designtabellen unter Bezugnahme auf 2b. Innerhalb dieses Abschnitts wird jede X.500-Methode definiert und mit einem Beispiel illustriert. Tabelle 5a zeigt einen kleinen hierarchischen Baum, der eine Alias-Referenz enthält. Die entsprechenden Tabelleninhalte sind in Tabelle 5b gezeigt.
Tabelle 5a – einfacher Hierarchiebaum
DIT
Name
Merke: [...] gibt eine binäre Kodierung des exakten Dateneingabewerts an.
Baum
Alias
Attribut
Suche
Eintrag
Tabelle 5b – Beispieltabellen
Merke: [...] gibt einen binären Code für einen exakten Dateneingabewert an.
5.1 Gemeinschaftliche Dienste
Baumnavigation
Alle X.500-Dienste beruhen auf einer Navigation des Directory-Baums. Der Zweck der Baumnavigation liegt darin, die EID eines Eintrags entsprechend dem bereitgestellten, unterscheidenden Namen zu bekommen. Die Navigation beginnt ausgehend von der Wurzel des Baum und setzt sich den Baum durch fort, bis alle die RDNs in einer DN aufgelöst (verifiziert) worden sind. Dieser Prozess ist als ein sogenanntes "Tree Work" bekannt.
Die DIT-Tabelle ist die primäre, die zur Baumnavigation verwendet wird. Bezugnehmend auf das Beispiel des Hierarchiebaums, das Auflösen der DN "Datacraft/Sales/Network Products/Peter Evans" umfasst die folgenden Prozesse:

– Scannen der DIT-Tabelle nach einer Linie, die Ursprung = 0 und RDN = "DATACRAFT" enthält. Die EID für diese Zeile ist 1.
– Scannen der Tabelle nach einer Zeile, die Ursprung = 1 und RDN = "SALES" enthält. Die EID für diese Zeile ist 11.
– Scannen der DIT-Tabelle nach einer Zeile, die Ursprung = 11 und RDN = "NETWORK PRODUCTS" enthält. Die EID für diese Zeile ist 20.
– Scannen der DIT-Tabelle nach einer Zeile, die Ursprung = 20 und RDN = "PETER EVANS" enthält. Die EID für diese Zeile ist 32.

Die DN wurde aufgelöst und alle Werte bezüglich des Objekts können aus der Entry-Tabelle unter Verwendung der Schlüssel-EID = 32 enthalten werden.
Aliases
Manchmal kann eine DN ein Alias umfassen, was effektiv eine andere DN ist. Aliases komplizieren den sogenannten "Tree Work"-Prozess, weil der "Tree Work" nicht durchgeführt werden kann, bis das Alias aufgelöst ist. Das erfordert einen separaten "Tree Work" für das Alias.
Beispielhaft sei die DN "Datacraft/Networks/Peter Evans" betrachtet. Die ersten beiden Schritte im Auflösen dieser DN würden sein:

– Scanne die DIT-Tabelle nach einer Zeile enthalend Ursprung = 0 und RDN = "DATACRAFT". Die EID für diese Zeile ist 1.
– Scanne die DIT-Tabelle nach einer Zeile enthaltend Ursprung = 1 und RDN = "Networks". Die EID für diese Zeile ist 10.

In diesem Zustand wird entdeckt, dass dieser Eintrag ein Alias ist. Die Alias-Tabelle wird gecheckt, um festzustellen, ob die EID des Alias zwischengespeichert ist. Falls dies ein erstmaliger Versuch ist, das Alias aufzulösen, dann wird die A-EID-Spalte in dieser Alias-Tabelle 0 sein. Zum Zweck der nachfolgenden Diskussion wird angenommen, dass es erste Mal ist.
Um das Alias aufzulösen, muss die DN des Alias-Objekts bestimmt werden. Diese ist gespeichert im "Alias Object Name"-Attribut des Alias-Eintrags. Der Alias Object Name hat einen AID = 1 (aus der ATTR-Tabelle) und so erhält man die DN aus der Eintragtabelle (RawWert), wo EID = 10 und AID = 1.
In diesem Beispiel ist die DN des Alias "Datacraft/Sales/Network Products". Diese DN wird unter Verwendung des normalen "Tree Work"-Prozesses aufgelöst. Der Wert der EID ist 20. In dieser Stufe wird die Navigation für die noch nicht aufgelöste RDNs in der Original-DN, nämlich "Peter Evans", fortgeführt. Der letzte erforderliche Schritt ist dann:

– Scanne die DIT-Tabelle nach einer Zeile enthaltend Ursprung = 20 und RDN = "PETER EVANS".

Sobald das Alias aufgelöst wurde, kann es in die Alias-Tabelle hinzugefügt werden (zwischengespeichert) werden. Diese Tabelle enthält eine Referenz, A-EID, zum Aliasobjekt. Im obigen Beispiel würde ein Eintrag in der Aliastabelle mit einer EID von 10 eine A-EID von 20 aufweisen. Sobald ein Alias zwischengespeichert wurde, ist ein "Tree Work" nicht mehr erforderlich, um ein Alias aufzulösen.
Directory-Pfade
Wenn Objekte in eine DIT-Tabelle hinzugefügt werden, wird eine korrespondierende Zeile in eine andere Tabelle hinzugefügt, die Baumtabelle genannt wird. Diese Tabelle speichert eine Liste von EIDs, die einen "Pfad" zu einem Objekt identifizieren.
Unterscheidungskräftige Namen
Die meisten Dienste erfordern es, dass die unterscheidungskräftigen Namen im Dienstergebnis übermittelt werden. Unter Verwendung des Directory-Pfads aus der Baumtabelle kann eine DN aus den RawRND-Werten konstruiert werden, die in der Namentabelle gespeichert sind.
Eingabeinformationsauswahl
Viele der X.500-Dienste werden mit einem Argument angefragt, das als "Entry Information Selection" oder EIS bezeichnet wird. Diese EIS-Anfrage wird benutzt, um anzuzeigen, welche Information in dem Entry übermittel werden soll. Prinzipiell kann EIS optional sein:

– keine Information
– Attribute oder Werte für ausgewählte oder alle Attribute
– Werte nur für ausgewählte oder alle Attribute

Eingabeinformationen
Eingabeinformation ist ein sogenannter "Return-Parameter" für das Lesen und Suchen. Er umfasst immer den unterscheidungskräftigen Namen eines ausgewählten Eintrags und, optional, Attribute und/oder Werte, wie sie in dem EIS-Argument der Anfrage gespeichert sind.
Gemeinsame Argumente
Alle X.500-Dienste leiten einen Satz von gemeinsamen Argumenten in einer Dienstanfrage weiter. Gemeinsame Argumente enthalten Informationen, wie zum Beispiel Dienststeuerungen (Zeitlimit oder Größenlimit), die DN des Anfragenden des Services und Sicherheitsinformationen.
Gemeinsame Ergebnisse
Einige X.500-Dienste leiten einen Satz von gemeinsamen Ergebnissen in der Dienstantwort weiter. Gemeinsame Ergebnisse enthalten Informationen, wie Sicherheitsparameter, die DN des Ausführenden des Service und eine "Alias dereferenziertes" Zeichen, weiter.
5.2 Lesedienste
Ein Lesebetrieb wird benutzt, um Informationen aus einem explizit identifizierten Eintrag zu extrahieren.
X.500-Definition
Methode

– Ausführung eines "Tree Work" unter Verwendung der DIT-Tabelle, falls notwendig Auflösen von Aliases. Erhalten der Basis-EID.
– Verwenden des Pfads aus der Baumtabelle und der RawRDNs aus der Namenstabelle, bilde eine DN.
– Falls die EIS keine Attribute oder Werte spezifiziert, gebe nur die DN zurück.
– Falls die EIS ALL-Typen und Werte spezifiziert, gebe die Raw-Werte aus der Entry-Tabelle zurück, für die EID erfüllt ist.
– Falls EIS ausgewählt Typen und Werte spezifiziert, erhalte die RIDs aus der Attributtabelle und geben dann ausgewählte Typen und/oder Werte zurück, für die EID erfüllt ist.

Beispiel
Lese den Eintrag "Datacraft/Sales/Network Products/Peter Evans". EIS ist zu setzen auf: Attributtypen = ALL-Attributes, Info-Types = Attribute-Types and Values.
Verwende die DIT-Tabelle und führe einen "Tree Work" aus unter Verwendung der EIDs 1, 11, 20 und 32 für den normierten RDN "Datacraft/Sales/Network Products/Peter Evans". Die EID des ausgewählten Objekts ist 32.
Extrahiere den Pfad aus der Baumtabelle für EID = 32. Der Pfad ist 1.11.20.32.
Erzeuge eine DN aus den RawWerten in der Namenstabelle für die EIDs 1, 11, 20, 32.
Verwende die Entry-Tabelle und die Attributtabelle für jedes übereinstimmende EID.
Gebe die Objekt-IDs aus der Attributtabelle und der ASN.1 kodierten Raw-Werte aus der Entry-Tabelle aus.

2.5.4.0 [2.5.6.7]

2.5.4.3 [PETER]

2.5.4.4 [EVANS]

2.5.4.9 [SALES PERSON]

2.5.4.20 [(03)727-9454]
Gebe die DN zurück.
5.3 Vergleichsdienste
Eine Vergleichsoperation wird verwendet, um einen Wert (der durch ein Argument einer Anfrage bereitgestellt wird) mit einem Wert oder Werten eines speziellen Attributtyps in einem speziellen Objekteintrag zu vergleichen.
X.500-Definiton
Methoden

– Ausführen eines sogenannten "Tree Work" unter Verwendung der DIT-Tabelle, Auflösen, falls notwendig der Aliases. Erhalten der EID des Basisobjekts.
– Aus der Attributtabelle erhalten der AID des zu vergleichenden Attributs.
– Aus der Entry-Tabelle auswählen der Zeile bzw. Zeilen, die mit dem EID und AID übereinstimmen.
– Vergleichen der Werte.
– Ausgeben wahr oder falsch als Ergebnis des Vergleichs.
– Falls ein Alias zu dereferenzieren ist, ausgeben der DN des ausgewählten Objekts, verwenden des Pfads aus der Baumtabelle und der RawRDNs aus der Namenstabelle.

Beispiel
Vergleiche die DN "Datacraft/Sales/Network Products/Peter Evans" mit einer Attribute Value Exultation enthaltend "Titel = [Sales Person]".
Erhalten der EID für das gegebene DN unter Verwendung eines "Tree Work". Die EID des ausgewählten Objekts ist 32.
Verwenden der Attributtabelle, erhalten der AID für "Titel", zum Beispiel AID = 12.
Verwenden der Suchtabelle zum Lokalisieren von Zeilen von mit EID = 32 und AID = 12 und Testen für "Norm = Sales Person".
Ausgeben wahr oder falsch, abhängig vom Ergebnis dieses Tests. In diesem Umstand wird das Ergebnis wahr sein.
Da keine Aliases zu dereferenzieren sind, wird der DN dieses Eintrags nicht zurückübertragen.
5.4 Listen-Dienste
Ein Listen-Betrieb wird verwendet, um eine Liste von unmittelbaren, untergeordneten Werten eines explizit definierten Eintrags zu erhalten.
X.500-Definition
Methode

– Ausführen eines sogenannten "Tree Work" unter Verwendung der DIT-Tabelle, falls nötig Auflösen der Aliases. Erhalten der EID des Basisobjekts.
– Verwenden der DIT- und der Namenstabelle, Übertragen des Alias Flag und der RawRDN, Ursprung ist der gleich der EID des Basisobjekts.

Beispiel
Ausführen einer Liste für den DN "Datacraft".
Erhalten der EID für die DN unter Verwendung eines "Tree Work". Die EID des ausgewählten Objekts ist "1".
Für jede EID mit einem Ursprung = 1

– Rückübertragung der RawRDN für die Namenstabelle, zum Beispiel [Networks], [Sales], [Marketing]
– Zurückübertragen der Alias Flags, zum Beispiel wahr, falsch, falsch.

Wenn kein Alias im "Tree Work" dereferenziert wurde, wird die DN des ausgewählten Objekts nicht rückübertragen. Man soll bemerken, dass der Alias-Eintrag [Networks] nicht dereferenziert ist.
5.5 Suchdienste
Der Suchdienst ist der am meisten komplexe von allen X.500-Diensten. Suchargumente geben an, wo die Suche zu starten ist (Basisobjekt), den Umfang der Suche (Subset), die anzuwendenden Bedingungen (Filter) und welche Information zurückgegeben werden sollte (Selection). Weiterhin wird ein sogenanntes Flag übertragen, um anzuzeigen, ob Aliases dereferenziert werden sollten (Search Aliases).
Die möglichen Werten für Subset sind Basisobjekt, Einstufe und gesamter Subtree. Das Basisobjekt gibt an, dass der Suchfilter nur auf Attribute und Werte innerhalb des Basisobjekts angewendet wird. Einstufe gibt an, dass der Suchfilter auf die unmittelbaren, untergeordneten Werte des Basisobjekts angewendet wird. Gesamter Unterbaum gibt an, dass der Suchfil ter auf das Basisobjekt und alle seine untergeordneten Werte angewendet wird.
Ein einfaches Beispiel einer Filterbedingung würde sein:
Nachname = "EVANS" oder Telefonnummer anwesend.
X.500-Definitionen
Die Suchprozeduren für jeden Suchumfang werden, wie unten angegeben, beschrieben:
Basisobjekt

– Führe einen "Tree Work" unter Verwendung der DIT-Tabelle aus, falls nötig, löse Aliases auf. Erhalte die EID für das Basisobjekt.
– Wende den Filter auf Attribute und Werte in der Suchtabelle mit dem EID des ausgewählten Objekts an.
– Falls die Filterbedingung erfüllt ist, gebe die Eintraginformation aus der Eintragtabelle zurück.

Falls ein Alias zu dereferenzieren ist, übermittle die DN zurück unter Verwendung der Baumtabelle, um den Pfad zu extrahieren und unter Verwendung der Namenstabelle, um die DN zu bilden.
Eine Stufe

– Führe einen "Tree Work" unter Verwendung der DIT-Tabelle aus, falls nötig, löse Aliases auf. Erhalte die EID des Basisobjekts.
– Prüfe, um festzustellen, ob irgendwelche Aliases existieren mit Ursprung = EID, und falls so, löse dieselben auf, um eine Liste dereferenzierter Aliases zu erhalten.
– Verwende die Suchtabelle und DIT-Tabelle, wende den Filter (Attribut/Wertebedingungen) und den Umfang (Ursprung = EID des ausgewählten Objekts und jeglicher dereferenzierter Aliases) an. Eine Liste von übereinstimmenden EID wird zurückübertragen.
– Falls ein Alias zu dereferenzieren ist, gebe das DN zurück unter Verwendung der Baumtabelle zur Extrahierung des Wegs und unter Verwendung der Namenstabelle, um das DN zu bilden.

Für jedes übereinstimmende EID:

– Gebe die Eintragsinformationen zurück, die aus der Suchtabelle erhalten werden unter Verwendung der Eintragtabelle (als Lesedienst).

Gesamter Unterbaum

– Führe einen "Tree Work" unter Verwendung der DIT-Tabelle aus, falls nötig, löse Aliases auf. Erhalte die EID des Basisobjekts.
– Prüfe, um festzustellen, ob irgendwelche Aliases existieren, mit einem Pfad-Präfix entsprechend dem Pfad des ausgewählten Objekts.
– Für jedes entdeckte Aliases prüfe, um festzustellen, falls das Alias außerhalb des aktuellen Unterbaums zeigt, und wiederhole diesen Schritt, falls es dieses tut. Sobald alle Aliases aufgelöst wurden, wird ein Satz von einzigartigen Basisobjekten gefunden sein (ohne überlappende Bereiche).
– Verwende die Suchtabelle und Baumtabelle, wende den Filter (Attribut/Wertebedingungen) und den Umfang (Pfad ähnlich dem Pfad-Präfix des ausgewählten Objekts) an, und zwar auf jedes einzigartige Basisobjekt. Eine Liste von übereinstimmenden EIDs wird zurückübertragen.
– Falls ein Alias während der Navigation zu dereferenzieren ist (nicht während der Suche), gebe das DN aus unter Verwendung der Baumtabelle, um den Pfad zu extrahieren und unter Verwendung der Namenstabelle, um DN zu bilden.

Für jedes übereinstimmende EID:
Gebe die Entry-Information aus, die aus der Suchtabelle unter Verwendung der Eintragstabelle erhalten wurde (als ein Lesedienst).
Beispiel
Führe eine Suche auf dem Basisobjekt "Datacraft/Sales" aus mit.

– Umfang gesetzt auf gesamten Unterbaum
– ein Filter "Nachname, anfänglicher Substring = M". (Suche alle Nachnamen, die mit "M")
– setze Search Aliases auf wahr
– setze EIS auf Attributtypen = all attributes, setze infotypes = attribute types and values.

Methode
Erhalte die EID des Basisobjekts, DN unter Verwendung eines "Tree Work". Die EID des Basisobjekts ist "11".
Aus der Baumtabelle erhalte den Pfad für EID = 11, zum Beispiel "1.11.".
Prüfe für jede Aliases unter den Einträgen, die einen Pfad aufweisen, beginnend mit "1.11.". In diesem Fall gibt es keine Aliases.
Erhalte das AID für das Attribut "Nachname" in der Attributtabelle, zum Beispiel: 4.
Wende den Filter und den Umfang gleichzeitig an. Zum Beispiel verwende die Suchtabelle, erhalte eine Liste von EIDs aus der Zielliste, wo AID = 4 und die Werte beginnen mit einem "m", verknüpft mit der Baumtabelle, deren Pfad ähnlich ist "1.11.%". Die übereinstimmenden EIDS sind 30 und 31.
Verwende die Entry-Tabelle und die Attributtabelle für jedes übereinstimmende EID:

– rückübertrage die Objekt-IDs aus der Attributtabelle und und der ASN.1 kodierten Raw-Werte aus der Eintragtabelle, zum Beispiel

2.5.4.0	[2.5.6.7]
2.5.4.3	[Chris]
2.5.4.4	[Masters]
2.5.4.9	[Sales Manager]
2.5.4.20	[(03)727-9456]
2.5.4.20	[(018)042671)
2.5.4.0	[2.5.6.7)
2.5.4.3	[Alana]
2.5.4.4	[Morgan]
2.5.4.9	[Sales Support)
2.5.4.20	[(03)727-9454]

5.6 Hinzufügen Eingabedienst
Ein Hinzufügen Eingabe-Betrieb wird verwendet, um einen Blatteintrag entweder einem Objekteintrag oder einem Directory-Informationsbaum hinzuzufügen.
X.500-Definition
Methode

– Verwenden der DIT-Tabelle, Ausführen eines "Tree Work" auf den Ursprung des hinzuzufügenden Eintrags (Ursprung EID).
– Verwenden der DIT-Tabelle, prüfe, ob der Eintrag existiert (prüfe für RDN gleich neue RDN und Ursprung = Ursprung EID).
– Falls der Entry nicht weiter existiert, ordne eine neue EID zu und füge den Eintrag hinzu. Füge ein in die DIT-Tabelle, die Namenstabelle, die Baumtabelle, die Suchtabelle, die Entry-Tabelle und, falls es ein Alias-Eintrag ist, in die Alias-Tabelle.

Beispiel
Unter dem Objekt mit einer DN "Datacraft/Marketing" füge ein Objekt mit den folgenden Attributen und Werten an.

Nachname [Delahunty]

Gemeinsamer Name [Mary]

Titel [Marketing Manager]

Telefonnummer [(03)727-9523]
Erhalte die EID des Basisobjekts DN unter Verwendung eines "Tree Work". Die EID dieses Basisobjekts ist "12".
Verwende die DIT-Tabelle, ermittele einen duplizierten Eintrag, zum Beispiel Ursprung = 12 und RDN = "MARY DELAHUNTY". Es existieren keine duplizierten Einträge.
Füge die folgenden Zeilen an die gezeigten Tabellen an.
DIT
Name
Baum
Suche
Eintrag
5.7 Entferne Entry-Dienst
Eine Entferne Entry-Operation wird verwendet, um einen Blatteintrag (entweder ein Objekteintrag oder einen Alias-Eintrag) aus dem Directory-Informationsbaum zu entfernen.
X.500-Definition
Methode

– Führe einen "Tree Work" unter Verwendung der DIT-Tabelle aus. Erhalte die EID des Basisobjekts.
– Falls ein Eintrag existiert und dieser Eintrag ein Blatteintrag ist, entferne für die Bedingung EID = EID des ausgewählten Objekts diesen aus der DIT-Tabelle, der Namenstabelle, der Baumtabelle, der Suchtabelle, der Eingabetabelle und, falls es ein Alias-Eintrag ist, aus der Alias-Tabelle.

Beispiel
Entferne das Objekt mit einer DN "Datacraft/Marketing/Mary Delahunty".
Methode
Erhalte die EID des Basisobjekts DN unter Verwendung eines "Tree Work". Die EID für das Basisobjekt ist "21". Prüfe, dass keine Einträge den Ursprung = 21 aufweisen.
Entferne alle Zeilen aus der DIT-Tabelle, der Namenstabelle, der Baumtabelle, der Suchtabelle und der Eingabetabelle (siehe auch add entry Beispiel) für die EID = 21 ist.
5.8 Ein Dienst zum Modifizieren eines Eintrags
Der Modifiziere Eintrag-Betrieb wird verwendet, um eine Serie von einen oder mehreren der folgenden Modifikationen auf einen einzelnen Eintrag anzuwenden:

– füge ein neues Attribut hinzu
– entferne ein Attribut
– füge einen Attributwert hinzu
– entferne einen Attributwert
– ersetze ein Attribut
– verändere ein Alias

X.500-Definition
Methode

– Führe einen "Tree Work" unter Verwendung der DIT-Tabelle aus. Erhalte die EID des ausgewählten Objekts.

Für jedes ausgewählte Objekt führe eine oder mehrere der folgenden Aktionen aus: Hinzufügen eines Werts, Entfernen eines Werts, Hinzufügen eines Attributs, Entfernen eines Attributs. Die Schritte, die für jede dieser Aktionen erforderlich sind, sind die folgenden:
Füge Wert hinzu

– Falls das Attribut existiert, füge den Wert in die Eingabetabelle und in die Suchtabelle. Überprüfungen sind: ist das Attribut ein Test mit einem einzigen Wert für einen existierenden Wert; ist das Attribut ein Test mit mehreren Werten für einen duplizierten Wert.

Lösche Wert

– Für die Eingabetabelle und die Suchetabelle lösche die Werte, falls sie existieren. Ein unterscheidungskräftiger Wert kann nicht gelöscht werden.

Füge Attribut hinzu

– Falls ein Attribut nicht existiert, füge den Attributwert in die Eingabetabelle und die Suchtabelle ein.

Entferne Attribut

– Für die Eingabetabelle und die Suchtabelle lösche diese, falls das Attribut existiert. Lösche alle Werte mit AID = ATTR und EID = Basisobjekt. Namensattribute können nicht gelöscht werden.

Beispiel
Ändere den Eintrag "Datacraft/Sales/Network Products/Chris Masters" mit den folgenden Änderungen:
Die Suchtabelle und Entry-Tabelle reflektiert die Änderungen.
Suche
Eintrag
5.9 Ändere RDN-Dienst
Die ändere RDN-Operation wird verwendet, um relativ unterscheidungskräftige Namen eines Blatteintrags (entweder ein Objekteintrag oder eine Alias-Eintrag) aus dem Directory Informationsbaum zu ändern.
Methode

- Führe einen "Tree Work" unter Verwendung der DIT-Tabelle aus. Erhalte die EID und die Ursprungs-EID des Basisobjekts.
- Verwende die DIT-Tabelle, prüfe nach äquivalenten Einträgen und gebe Fehler zurück, falls einer gefunden ist. Ein äquivalenter Entry hat RDN = neue RDN und Ursprung = Ursprung-EID.
– Verwende die Namentabelle, ersetze die alte RDN durch die neue RDN.
– Verwende die DIT-Tabelle, ersetze die alte RDN durch die neue RDN
– Verwende die Entry-Tabelle, füge einen neuen Wert ein.
– Verwende die Suchen-Tabelle, ermittele Wert = alte RDN und setze Disting auf 0. Füge neuen Wert ein.

Falls lösche alte RDN auf wahr gesetzt ist, folgt die Prozedur dem "Tree Work", wie folgt:

– verwende die DIT-Tabelle, prüfe nach einem Abkömmling mit dem selben Namen und einer EID ungleich der Basis-EID
– verwende die Namentabelle, ersetze die alte RDN durch die neue RDN
– verwende die DIT-Tabelle, ersetze die alte RDN durch die neue RDN
– verwende die Entry-Tabelle, lösche die alten Werte und setze die neuen Werte ein
– verwende die Suchen-Tabelle, lösche die alten Werte und setze die neuen Werte ein.

Beispiel
Ändere die RDN "Datacraft/Sales/Network Products/Chris Masters". Die neue RDN ist "Christine Masters".
Lösche alte RDN ist gesetzt auf falsch.
Die Änderungen in den Tabellen werden folgende sein: DIT
Name
Suche
Eintrag
5.10 Komplikationen
Falls ein Fehler, eine Beschränkung oder ein Aufgeben während des Prozesses eines der Dienste eintritt, so wird die Bearbeitung unterbrochen und eine geeignete Fehlermeldung ausgegeben.
Fehler
Jeder X.500-Dienst besteht aus drei Teilen: ARGUMENT, ERGEBNIS und FEHLER. In der obigen Beschreibung der Dienste wurden ARGUMENT und ERGEBNIS in die X.500-Definitionen einge schlossen. Fehlerbedingungen sind jedoch sehr viele und unterschiedlich, so dass kein Versuch unternommen wird, sie in diesem Dokument zu beschreiben. Das Dokument des Nationalen Instituts für Standards und Technologie (NIST) "Stabile Implementierungsübereinkommen für Verknüpfungsprotokolle offener Systeme, Version 3" gibt einen vollen Überblick von Fehlern innerhalb des X.500-Standards.
Zeitbegrenzungen und Größenbegrenzungen
Zeitbegrenzungen und Größenbegrenzungen bilden einen Teil der Dienststeuerung. Sie können optional auf ein begrenztes Limit gesetzt werden und sind in den gemeinsamen Argumenten enthalten.
Das Zeitlimit gibt die maximale eingeschlossene Zeit in Sekunden an, innerhalb dessen der Dienst bereitgestellt werden soll. Größenbegrenzungen (nur anwendbar auf Listen und Suchen) geben die maximale Anzahl von zurückzuübermittelnden Objekten an. Falls eine der Grenzen erreicht wird, wird ein Fehler berichtet. Für ein auf einer Liste oder einer Suche erreichtes Limit ist das Ergebnis eine beliebige Auswahl von akkumulierten Ergebnissen.
Aufgabe
Operationen, die mit dem Directory interagieren, zum Beispiel Lesen, Vergleichen, Auflisten und Suchen, können unter Verwendung des Aufgabekriteriums aufgegeben werden, falls der Benutzer nicht weiter an dem Ergebnis interessiert ist.
Aliases und Suche
Falls ein Alias in eine Suche eingebunden ist und das Alias auf eine eigenständige Abzweigung eines Directory-Baums zeigt, so ist eine Dereferenzierung des Alias erforderlich:

– Navigation ausgehend vom Wurzeleintrag auf den referenzierten Eintrag
– Suchen aller untergeordneter Punkte des referenzierten Eintrags

In dem in Tabelle 5.10 gezeigten Beispiel würde, falls eine gesamte Unterbaumsuche auf Basis des Objekts "Telco/Corporate/Dataservices" durchgeführt wurde, die Eingaben "Marvin Powis" und das Alias "Strategic" gesucht werden. Strategic zeigt jedoch auf eine unterschiedliche Abzweigung des Baums, was ein Suchen des Eintrags "Strategic" und aller seiner untergeordneten Größen erfordert, zum Beispiel "Alan Bond", "Rex Hunt", "Wayne Carrey" und "John Longmeyer".
Tabelle 5.10 – Ein Beispielbaum mit einem Alias, welches sich auf einen unterschiedlichen Abzweig des Baums referenziert.
5.11 Implementierungs-Optimierungen
Die logischen Methoden umfassen eine Anzahl von Optimierungen, die die Leistung verbessern. Diese Methoden werden unten beschrieben.
Zwischenspeichern
Die Attributtabelle kann zwischengespeichert sein. Dies bedeutet, dass (abgesehen vom anfänglichen Landen der Attribute) keine SQL-Statements in der Datenbank beachtet werden müssen, wenn Attribute dekodiert oder kodiert werden. Im gegenwärtigen X.500-System werden Attributkonvertierungen im Speicher durchgeführt. Dies stellt eine merkliche Geschwindigkeitsverbesserung dar.
Validierung
Abfrageoptimierungen werden, wo möglich, im Speicher durchgeführt. Dies verhindert, das Zurückrollen in Datenbanken, was sehr zeit- und systemintensiv ist. Zum Beispiel dann, wenn ein Eintrag hinzugefügt wird, wird jedes Attribut validiert, bevor ein Versuch unternommen wird, den Eintrag hinzuzufügen. Falls ein Fehler gefunden wird, müssen keine SQL-Anfragen berücksichtigt werden.
Optimierung der Anfragehandhabung
Weil die Formate der meisten Dienste bekannt sind, können viele Probleme dieser Dienste während des statischen SQL-Statements gelöst werden. Komplexere Dienste, wie zum Beispiel Suchen mit komplexen Filtern, können bunter Verwendung einer dynamischen SQL gelöst werden. Dies erlaubt es, beliebig komplexe Suchen durchzuführen.
Parallele Anfragen
Auch dann, wenn Sucherergebnisse bearbeitet werden, verwendet das vorliegende System Satzorientierungsanfragen von SQL, um "Zeilen zu einer Zeit"-Bearbeitungen zu vermeiden. Demnach können Suchergebnisse parallel im Speicher zusammengefügt werden.
Datenspeicherung
Die Tabellen, die Raw-Daten speichern, speichern die Daten im ASN.1-Format. Dies stellt ein effizientes Mittel bereit, um Daten in die Datenbank zu transferieren oder aus derselben herauszutransferieren.
Datenbanktechniken
Komplexe Dienste können weiterhin dadurch verbessert werden, indem Anfrageoptimierer verwendet werden, die einen Mechanismus zur Reduzierung der verwendeten Zeit in der Abarbeitung einer Anfrage bereitstellen. Die Verwendung einer relationalen Datenbank stellt auch einen effektiven Gebrauch des Speichers dar und ermöglicht es, große Datenbanken zu konstruieren, ohne dass eine große Anzahl von verfügbarem Speicher erforderlich ist. Viele andere X.500-Anwendungen speichern die gesamte Datenbank im Speicher zwischen, um gute Leistung zu erzielen. Dieses Verfahren benötigt große Speichermengen und ist nicht skalierbar.
6. PHYSIKALISCHES DESIGN
Das physikalische Design ergibt sich aus einem Prozess, der als physikalische Transformation des logischen Designs bezeichnet wird. Das physikalische Design stellt eine bevorzugte Realisierung oder Ausführung des logischen Designs dar. 2b und die weiter unten angegebenen Tabellen zeigen eine Form des physikalischen Designs. Neue Spalten und Tabellen sind durch doppelte Linien hervorgehoben.
Tabelle 6 – physikalisches Design
Die Gründe für die obigen Änderungen werden unten beschrieben.
6.1 Effizienz
Infotabelle
Diese Tabelle hält den höchsten EID-Wert, der in der Datenbank verwendet wurde. Der Einschluss der Infotabelle ermöglicht es, den nächsten EID zu erhalten, ohne jegliche Berechnung des maximalen EIDS, der in der Datenbank verwendet wurde. Dies stellt eine verbesserte Effizienz im Hinzufügen von Einträgen in die Datenbank bereit. Noch wichtiger, das Einschließen der Infotabelle, entfernt Inhaltsprobleme, die auftreten können, wenn mehrere DSA's zu einer Zeit Einträge hinzufügen.
Schattenschlüssel
Drei Tabellen wurden Schattenschlüssel hinzugefügt. Diese sind:

a) die Norm-Key-Spalte in der Suchtabelle
b) die RDN-Key-Spalte in der DIT-Tabelle
c) die ELV1-, ELV2-, ELV3- und ELV4-Spalten in der Baumtabelle.

Jede dieser Schattenschlüsselspalten ist eine gekürzte Version einer größeren Spalte. Sie wurden hinzugefügt, um die Indices jeder Tabelle zu kürzen. Dies stellt eine verbesserte Leistungsfähigkeit für jede Anfrage bereit, die die Indices benutzen, und es verbessert auch den Gebrauch von Diskraum, weil kleine Indices weniger Raum verbrauchen als große Indices.
Schattenschlüssel in der Pfadtabelle verwenden die strukturierte Natur des Pfads. Sind diese ein zusammengesetzter Schlüssel, so kann eine exakte Übereinstimmung in SQL benutzt werden, anstelle des "Like"-Operators.
Zum Beispiel, wenn ELV1 = 1 und ELV2 = 10 und ... anstelle des wo Pfad ähnlich "1.10.".
Falls jede der ELV-Spalten ihren eigenen Index aufweist, dann braucht eine Unterbaumsuche nur das Basisobjekt zu verwenden. Zum Beispiel ELV2 = 10, weil alle Objekte unter dem Eintrag 10 ein ELV2 = 10 aufweisen werden.
SENTRY-Tabelle
Einige Typen von Attributwerten brauchen nicht normalisiert zu werden, zum Beispiel Integer-Daten, Boolsche Daten, Datumsdaten. Anstelle dieselben zweimal zu speichern (Suche.Norm und Entry.Raw), können dieselben nur einmal in einer hybriden Tabelle gespeichert werden, die als S-Entry-Tabelle bezeichnet ist. Dies verringert die Tabellengröße und vergrößert die Speichereffizienz auf Kosten von der Durchsuchung von zwei Tabellen und dem Empfangen von zwei Tabellen.
OCLASS-Tabelle
Die meisten Attribute verfügen über eine große Variation ihrer Werte, zum Beispiel Nachnamen können variieren zwischen AALDERS bis ZYLA mit einer großen Anzahl verschiedener Werte dazwischen. Objektklassen (deren Werte Objekt-Identifikatoren oder OIDs sind) haben jedoch nur sehr wenige Werte, zum Beispiel in einer Organisation von 1000 Menschen, die einzigen Objektklassen in dem Directory können für die Organisation, Organisationseinheit und Organisationspersonal bestehen (für welche die letztgenannte die Meisten aufweisen). Die Oclass-Tabelle gibt eine numerische Beschreibung für eine Objektklasse, genannte OCID. Die OCID kann in der S-Entry-Tabelle gespeichert werden und es kann immer dann ein Mapping durchgeführt werden, wenn eine Objektklasse gesucht oder erhalten wird. Die anderen Listspalten speichern Standard-Objektklassen-Konfigurationsinformationen – nämlich die Attribute, die enthalten sein müssen und können, und die inhärenten Superklassen.
6.2 Portabilität
BLOB-Tabelle
Diese Tabelle wurde eingeführt, um "binary large objects" zu umfassen. Die maximale Größe eines Zeilenantrags in der Entry-Tabelle ist beschränkt durch die Länge des Raw-Felds. Dies bedeutet, dass Einträge fragmentiert werden müssen. Fragmentierte Einträge besetzen mehr als eine Zeile und so muss ein VFRAG-Feld verwendet werden, um das Fragment des Eintrags anzuzeigen, das in der speziellen Zeile gespeichert wird.
Es gibt zwei Optionen zum Speichern sehr großer Werte:

a) füge ein "Fragmentflag" in die Eintragtabelle ein und speichere den Eintrag in Fragmenten über eine Anzahl von Linien; oder
b) füge eine BLOB-Tabelle zu, um den Eintrag zu speichern, und füge ein "BLOB-Flag" in die Entry-Tabelle ein, um anzuzeigen, dass dieser Wert in der BLOB-Tabelle gespeichert ist.

Die zweite Option hat eine Vielzahl von Vorteilen. Zuerst vermeidet das Einschließen einer BLOB-Tabelle, dass die Ein tragtabelle sehr groß wird. Typischerweise sind die meisten Einträge kleiner als einige hundert Zeichen in der Länge, so dass die Länge des Raw-Felds in der Entry-Tabelle dementsprechend reduziert werden kann, um auf solche Einträge abgestimmt zu sein, und das Raw-Feld in der BLOB-Tabelle kann vergrößert werden auf einen Wert, der die maximale Rekordgröße erreicht. Das wird das Speichern effizienter gestalten, zum Beispiel die Anzahl ungenutzter Bits in jeder Spalte einer jeden Tabelle reduzieren und die Anzahl der benötigten Fragmente für jeden Eintrag in BLOB-Tabelle reduzieren. Dies bedeutet auch, dass jeder Wert nur einen Eintrag in der Eintragtabelle hat und dass die Eintragtabelle und Suchtabelle ihre 1-1-Korrelation beibehalten.
Weiterhin erlaubt die Verwendung einer BLOB-Tabelle, dass Anwendungen alle Datenbanken verwenden, die binary large objects unterstützen (zum Beispiel 64 k Binary-Spalten).
6.3 Funktionale Erweiterbarkeit
Flag-Spalten
Es ist bevorzugt Flag-Spalten hinzuzufügen. Diese Spalten wurden hinzugefügt, um die Erweiterbarkeit des Designs zu ermöglichen. Spezielle Werte können hinzugefügt werden an die Flags als neue, erforderliche Funktionalitäten, ohne die Struktur der Tabellen zu ändern.
Merke:

a) In der Suchtabelle kann das Disting-Feld in das Flag-Feld absorbiert sein.
b) In der DIT-Tabelle kann das Alias-Feld in das Flag-Feld adsorbiert sein.

Die Flag-Spalten können auch eine "Summen"-Funktion für jede der Tabellen bereitstellen. Das bedeutet, dass die Natur eines Eintrags zu einem gewissen Umfang bestimmt werden kann, indem der Wert des Flagfelds überprüft wird. So kann zum Beispiel ein Flag in der DIT-Tabelle gesetzt werden, wenn der Eintrag ein Blatt ist. Die Überprüfung dieses Flags ist einfacher als das Überprüfen der Kinder des Eintrags.
Die Flag-Spalten können auch verwendet werden, um Sicherheitsinformationen zu speichern, ob ein Alias-Punkt innerhalb seines Ursprungsunterbaums ist, ob ein Wert ein BLOB ist, usw.
7. BEISPIEL-IMPLEMENTIERUNG
Die folgende Beschreibung stellt ein Beispiel der Leistung und der Möglichkeiten des Systems dar. Es soll verstanden werden, dass die vorliegende Erfindung durch die folgende Beschreibung nicht beschränkt wird.
7.1 Insgesamte Systemvorteile
Die vorliegende Erfindung stellt eine Vielzahl verbesserter Leistungen gegenüber dem Stand der Technik bereit. Die Leistung kann auf vielfältige Art und Weise verbessert werden, umfassend:
Aliases;
Größe (Verwendung der relationalen Theorie);
Komplexität (Verwendung eines Anfrageoptimierers und von Suchmethoden);
Erweiterbarkeit (Verwendung von Metadaten); und
im Wesentlichen ohne das Verschlechtern der Effizienz (Verwendung des disparsierten Modells) und der Zuverlässigkeit (Verwendung von RDBMS).
Die vorliegende Erfindung ist einzigartig darin, dass es möglich ist, Leistungsverbesserungen in allen oben angegebenen Bereichen zu erzielen.
7.2 Testergebnisse
Leistungstests der vorliegenden Erfindung wurden ausgeführt mit dem Ziel von:

– Beweisen, dass ein SQL-basiertes X.500-Anwendungssystem hohe Geschwindigkeiten ausführen kann, widerlegend einen im Markt weitverbreiteten Mythos, dass es unmöglich ist, eine X.500-DSA-Anwendung als eine integrierte RDBMS-Anwendung zu implementieren und Effizienz und Leistung bereitzustellen.
– Beweisen, dass das Design einer SQL-basierten X.500-Anwendung stehende, speicherresistente X.500-Designs in der Leistung übertreffen kann, insbesondere für Datenbanken größer als 100000 Einträge, was ein typisches Limit für gewöhnliche Designs ist.
– Bereitstellung eines strukturierten Umfangs von Tests, die obige Leistung nach Bedarf für eine große Vielzahl von Diensten und Datenbankgrößen unter Beweisstellen können.

Die Ergebnisse sind in der folgenden Tabelle 7a wiedergegeben.
Tabelle 7a
Anmerkungen:

1. Alle Suchen und Abfragen geben alle Informationen zurück
2. Alle Tests wurden durchgeführt unter der folgenden Umgebung;
– Sun Spark Station 5 mit 32 MB Speicher (Entry-Level Unix-Maschine)
– Ingres 6.1/04 konfigurierte für 32 Anwender (Standard-Ingres-Installation)
– DSA-Prototyp V2.1.2
– Zeiten wurden auf der DSA-Konsole gemessen (zum Beispiel umfasst dies nicht Netwerk-Overheads)

Alle Zahlen sind in der Einheit von Sekunden angegeben und "K" bedeutet 1000.
7.3 Test Ergebnisse
Ein Satz von Directories wurde konstruiert in einem Bereich von 1K bis 200K Einträgen mit variierender Breite und Tiefe der Hierarchie, und ein korrespondierender Testplan wurde produziert. Die Tests wurden mehrfach durchgeführt, um deren Konsistenz sicherzustellen. Die folgenden Argumenten können aus den Tests gezogen werden:

1. Die Effekte der Navigation waren im Test vernachlässigbar.
2. Das Lesen eines Objekts gegenüber einem Alias zeigte im Test keine messbare Vergrößerung in der Leistung und in einigen Fällen war sogar das Lesen eines Objekts gegenüber einem Alias schneller als das Lesen des Objekt-Directories. Dies ergibt sich aus der verringerten, erforderlichen Navigation, wenn ein Alias nach unten zeigt auf ein Objekt, das tiefer in der Baumstruktur ist als der Alias-Eintrag.
3. Die Suchergebnisse waren "flach" über unterschiedliche bemessene Unterbäume in unterschiedlich bemessenen Directories sowohl für exakte als auch anfängliche Stringsuchen.
4. Anfängliche und exakte Suchen des gesamten Baums waren im Test geringfügig schneller als ihre entsprechenden Unterbaumsuchen, und zwar dann, wenn die Anzahl der Suchen größer war. Das liegt darin begründet, dass die Suchen des vollen Baums SQL effizienter nutzen können (es sind keine Tabellenverzweigungen erforderlich).
5. Alle Dienste wurden im Test unter einer Sekunde durchgeführt, ausgenommen für Suchen, die eine große Menge von Daten übermitteln. Die durchschnittliche Zeit des Empfangens je Eintrag fällt, wenn die Anzahl der empfangenen Einträge fällt (zum Beispiel für 10 Einträge ist die Empfangszeit näherungsweise 50 msec. je Eintrag, für 100 Einträge fällt dies auf annäherungsweise 20 msec. je Eintrag).
6. Alle komplexen Suchen wurden im Test unter einer Sekunde durchgeführt. Es gab jedoch einige obskure Suchen (zum Beispiel die Kombinationen mit NOT enthalten, die nicht genauso gut arbeiten).

Weil dies ein Disk-basiertes System ist (eher als ein Speicherbasiertes System) hängt die Leistung im Wesentlichen nur von der Anzahl der aktuell zu übertragenden Einträge ab. Dies ist relativ unabhängig von der Komplexität der Suche, der tiefe der Hierarchie, der Anzahl der Attribute je Eintrag oder der Attributtypen, die in der Anfrage benutzt werden. In einer "Live"-Anwendung des Systems kann es möglich sein, die erzielten Testergebnisse dadurch zu verbessern, dass das Zwischenspeichern der Parameter eingestellt wird, und indem eine größere Vielfalt von Attributen verwendet wird.

Claims

Datenverarbeitungsvorrichtung zur Bereitstellung von Directorydiensten bezüglich Datenobjekten, wobei jedes Datenobjekt wenigstens ein Attribut und jedes Attribut einen oder mehrere Werte aufweist, mit: Empfangsmitteln zum Empfangen von Directorydienst-Operationsbefehlen; und Datenbankmitteln, die angeordnet sind, um Daten zu speichern und Directorydienst-Operationen in Übereinstimmung mit den von den Empfangsmitteln empfangenen Directorydienst-Operationsbefehlen auszuführen; dadurch gekennzeichnet, dass die Datenbankmittel umfassen: Hierarchiedefinitionsmittel zur Definition von Beziehungen zwischen Objekten und einem Entry-Identifikator, der jedes Objekt identifiziert; Attributdefinitionsmittel, um eine Vielzahl von Attributdefinitionen zu speichern, wobei jede Attributdefinition ein entsprechendes Attribut definiert und einen Attribut-Identifikator umfasst; Mittel zur Speicherung von Wertedaten für jedes Objekt, wobei die Wertedaten Attributwerte und, verbunden mit jedem Attributwert, einen entsprechenden Attribut-Identifikator und einen Entry-Identifikator aufweisen, der das Objekt identifiziert, auf welches sich der Attributwert bezieht; und Mittel die auf die Directorydienst-Operationsbefehle antworten, um die Datenobjekte zu ermitteln und/oder zu übertragen, welche die durch die Hierarchiedefinitionsmittel, die gespeicherten Attributdefinitionen und die gespeicherten Wertedaten definierten Beziehungen verwenden.
Eine Vorrichtung nach Anspruch 1, wobei das Hierarchiedefinitionsmittel vorgesehen ist, um Ursprungsdaten zu speichern, die den Entry-Identifikator eines jeden Objekts auf einen anderen Entry-Identifikator oder ein Rootobjekt beziehen, wodurch Daten gespeichert werden, die für jedes Objekt einer hierarchischen Beziehung relativ zu dem Rootobjekt direkt oder über andere Objekte entsprechen, wobei das Datenbankmittel vorgesehen ist, um Directorydienst-Operationen unter Verwendung der Ursprungsdaten auszuführen.
Vorrichtung nach Anspruch 1 oder 2, wobei das Datenbankmittel weiterhin vorgesehen ist, um dem Entry-Identifikator eines jeden Objektes zugeordnete Pfaddaten zu speichern, die einer relativen hierarchischen Beziehung des Objekts bezüglich des Rootobjektes entsprechen, und wobei die Datenbankmittel vorgesehen sind, um Directorydienst-Operationen unter Verwendung dieser Pfaddaten auszuführen.
Vorrichtung nach Anspruch 3, wobei das Datenbankmittel vorgesehen ist, um die Pfaddaten in einem Pfaddefinitionsmittel getrennt von den Hierarchiedefinitionsmitteln zu speichern.
Vorrichtung nach jedem der vorstehenden Ansprüche, wobei das Datenbankmittel vorgesehen ist, um Aliasdaten zu speichern, die die Äquivalenz eines Objektes in Bezug auf ein anderes Objekt wiedergeben, wobei das Datenbankmittel vorgesehen ist, um die Directorydienst-Operationen auszuführen, indem Referenzen auf einen Entry-Identifikator eines Objektes, welches durch seine Aliasdaten als ein Äquivalent für ein anderes Objekt erkannt wird, in Referenzen auf die Entry-Identifkatoren ihrer äquivalenten Objekte unter Verwendung der Aliasdaten konvertiert werden.
Vorrichtung nach Anspruch 5, wobei das Datenbankmittel vorgesehen ist, um die Aliasdaten in Aliasdefinitionsmitteln getrennt von dem Hierarchiedefinitionsmittel zu speichern.
Vorrichtung nach jedem der vorstehenden Ansprüche, wobei das Datenbankmittel vorgesehen ist, um Wertedaten für jedes Objekt in einer ersten Form und in einer zweiten Form zu speichern, wobei das Datenbankmittel angeordnet ist, um die Directorydienst-Operationen unter Verwendung eines Vergleiches der Wertedaten mit Daten auszuführen, die von den Empfangsmitteln unter Verwendung von in der ersten Form gespeicherten Daten empfangen werden, und um Daten unter Verwendung von in der zweiten Form gespeicherten Daten auszugeben.
Vorrichtung nach Anspruch 7, wobei das Datenbankmittel vorgesehen ist, um die Wertedaten in der ersten Form und die Wertedaten in der zweiten Form in getrennten Attributdefinitionsmitteln zu speichern.
Vorrichtung nach jedem der vorstehenden Ansprüche, wobei das Datenbankmittel weiterhin vorgesehen ist, um Konvertierungsdaten zu speichern, die der Konvertierung von Daten zwischen als Teil von Directorydienst-Operationsbefehlen empfangenen Daten, die Typdaten entsprechen, und Attribut-Identifikatoren dienen.
Vorrichtung in Übereinstimmung mit jedem der vorstehenden Ansprüche, wobei das Datenbankmittel vorgesehen ist, um Daten zu speichern, die der Generierung von eindeutigen Namen für jedes der Objekte dienen, wobei das Datenbankmittel vorgesehen ist, um die Directorydienst-Befehle unter Verwendung der eindeutigen Namen für die Objekte auszuführen.
Vorrichtung nach Anspruch 10, wobei das Datenbankmittel vorgesehen ist, um Namen-Identifikationsdaten zu speichern, die für ein Objekt Wertedaten als Daten identifizieren, die einen Teil des eindeutigen Namens für jedes Objekt bilden.
Vorrichtung nach Anspruch 11 unter direkter oder indirekter Abhängigkeit auf Anspruch 2, wobei das Datenbankmittel vorgesehen ist, um für jedes Objekt Namensdaten zu erzeugen, und zwar unter Verwendung von Wertedaten, die Namens-Identifikationsdaten zugeordnet sind, die wiedergeben, dass die Wertedaten einen Teil eines Namens für ein Objekt bilden, und um für jedes Objekt einen eindeutigen Namen zu erzeugen, und zwar unter Verwendung der Namens-Identifikationsdaten und der Daten, die einem Objekt und seiner hierarchischen Beziehung relativ zu einem Rootobjekt direkt oder über andere Objekte entsprechen.
Vorrichtung nach Anspruch 11 oder Anspruch 12, direkt oder indirekt abhängig von Anspruch 3, wobei das Datenbankmittel vorgesehen ist, um den eindeutigen Namen für ein Objekt unter Bezugnahme auf den dem Objekt zugeordneten Entry-Identifikator zu speichern, wobei das Datenbankmittel vorgesehen ist, um den eindeutigen Namen für das Objekt unter Verwendung der Namens-Identifikationsdaten und der Pfaddaten zu erzeugen.
Vorrichtung nach Anspruch 13, wobei das Datenbankmittel vorgesehen ist, um den eindeutigen Namen mit dem Entry-Identifikator, der die Namensdaten einem entsprechenden Objekt zuordnet, in einem Namensdefinitionsmittel getrennt von dem Hierarchiedefinitionsmittel zu speichern.
Vorrichtung in Übereinstimmung mit Anspruch 14, wobei das Datenbankmittel vorgesehen ist, um den eindeutigen Namen für jedes Objekt in einer ersten Form und in einer zweiten Form zu speichern, wobei das Datenbankmittel vorgesehen ist, um die Directorydienst-Operationen unter Verwendung eines Vergleiches der eindeutigen Namensdaten mit Daten auszuführen, die von den Empfangsmitteln unter Verwendung von in der ersten Form gespeicherter Daten empfangen werden, und um Daten unter Verwendung von in der zweiten Form gespeicherter Daten auszugeben.
Vorrichtung nach jedem der vorstehenden Ansprüche, wobei das Empfangsmittel angepasst ist, um Directorydienst-Befehle zu empfangen, die eine Anforderung zur Ausführung einer Vergleichsfunktion identifizieren, und wobei das Datenbankmittel vorgesehen ist, um nach Empfang eines solchen Befehls durch das Empfangsmittel die Anforderung des Vergleiches von Daten, die den Datenobjekten und anderen Daten zugeordnet sind, auszugeben.
Vorrichtung nach Anspruch 16, wobei das Empfangsmittel angepasst ist, um eine Anfrage zur Ausführung einer Vergleichsfunktion zu empfangen, wobei der Befehl Daten aufweist, die mit Daten zu vergleichen sind, welche Datenobjekten zugeordnet sind.
Vorrichtung nach Anspruch 16, wobei das Empfangsmittel angepasst ist, um Directorydienst-Befehle zu empfangen, die eine Vergleichsanforderung identifizieren, wobei die Befehle Daten umfassen, die eine Vielzahl von Datenobjekten wiedergeben, und wobei das Antwortmittel angeordnet ist, um nach Empfang dieser Befehle durch das Empfangsmittel die Datenobjekte zu lokalisieren und um das Ergebnis des Vergleichs der Daten, die den lokalisierten Datenobjekten zugeordnet sind, auszugeben.
Vorrichtung nach jedem der vorstehenden Ansprüche, wobei das Empfangsmittel angepasst ist, um Directorydienst-Befehle zu empfangen, die eine Anforderung identifizieren, um in den Datenbankmitteln gespeicherte Daten abzuändern, und wobei das Antwortmittel vorgesehen ist, um nach Empfang dieser Befehle durch das Empfangsmittel die in den Datenbankmitteln gespeicherten Daten abzuändern.
Vorrichtung nach jedem der vorstehenden Ansprüche, wobei das Empfangsmittel angepasst ist, um Directorydienst-Befehle zu empfangen, die eine Anforderung zur Ausführung einer Suchfunktion identifizieren, wobei die Befehle Suchkriterien definierende Suchdaten umfassen, wobei das Antwortmittel vorgesehen ist, um nach Empfang dieser Befehle durch das Empfangsmittel Daten auszugeben, welche in der Datenbank in Verbindung mit Entry-Identifikatoren gespeichert sind, entsprechend Entry-Identifikatoren, die in Verbindung mit Daten gespeichert sind, die das durch die empfangenen Suchdaten definierte Suchkriterium erfüllen.
Vorrichtung nach Anspruch 20, wobei die Suchdaten Daten umfassen, welche eine oder mehrere durch Wertedaten zu erfüllende Kriterien umfassen, um wobei das Antwortmittel vorgesehen ist, um nach Empfang der Instruktionen durch das Empfangsmittel Daten auszugeben, welche in dem Datenbankmittel in Verbindung mit Entry-Identifikatoren gespeichert sind, die Entry-Identifikatoren entsprechen, welche in Verbindung mit Attributwerten gespeichert sind, die eine oder mehrere der zu erfüllenden Bedingungen erfüllen.
Vorrichtung nach Anspruch 20 oder 21 unter direkter oder indirekter Abhängigkeit auf Anspruch 2, wobei die Suchdaten Umfangsdaten umfassen, die eine oder mehrere Bedingungen definieren, welche den Umfang einer Suche festlegen, und wobei das Antwortmittel vorgesehen ist, um nach Empfang der Instruktionen durch das Empfangsmittel Daten auszugeben, welche das durch die empfangenen Suchdaten definierte Suchkriterium erfüllen, die in Verbindung mit den Entry-Identifikatoren gespeichert sind, wobei in dem Datenbankmittel Daten gespeichert sind, die den Entry-Identifikatoren Daten mit einer hierarchischen Beziehung, welche eine oder mehrere der durch die Umfangsdaten definierten Bedingungen erfüllen, zuordnen.