No només són jeràrquiques les dades de l'LDAP, sinó que les metadades LDAP també ho són. Les metadades LDAP es defineix creant les definicions dels classe d'objecte i els tipus d'atribut. La entrada classe d'objecte defineix els diferents atributs que poden guardar-se ne una entrada. Una classe d'objecte es defineix per la llista:

• Nom. Una cadena de caràcter pel qual es coneix la classe d'objecte.
• Atributs obligatoris. Atributs que han d'ésser presents en qualsevol entrada de la classe d'objecte.
• Atributs opcionals. Atributs que poden ésser presents en qualsevol entrada la classe d'objecte.
• Superclasse. El nom d'una classe d'objecte d'on aquesta classe d'objecte hereta tots els atributs obligatoris i opcionals.
• Tipus. Indica si els objectes del tipus poden crear-se en el Directori (estructural) i si la classe d'objecte pot utilitzar-se només com una super-classe en la creació d'altres classe d'objectes (abstractes). El tipus també indica si la classe d'objecte s'utilitza per augmentar una entrada que ja està guardada en el Directori (auxiliar).

Per exemple, considera la següent definició de classe d'objecte, agafada de la RFC 2256.2:

( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY 
( userPassword $ telephoneNumber $ seeAlso $ description ) )

En aquestes definicions, hi ha dos noms per a cada classe d'objecte. L'identificador d'objecte numèric va seguit del nom textual. Llavors la super-classe, si existeix, que li segueix el tipus de la classe de l'objecte. Finalment, es llisten el atributs obligatoris i els opcionals. Fixa't que el caràcter "$" s'utilitza com a separador. Fixa't que les entrades amb la classe d'objecte "person" hereta l'atribut "objectClass" de la seva super-classe. Com que la classe d'objecte "top" és abstracta, llavors no es poden crear entrades d'aquesta classe. Tanmateix, les entrades que són de la classe d'objecte "person" si que es poden crear. En la classe d'objecte "person", l'atribut "cn" és l'abreujament de nom comú i s'utilitza normalment per indicar el nom únic de l'entrada dins del contenidor.

Els tipus d'atributs es defineixen de forma semblant. Les parts més importants d'un tipus d'atribut són:

• Nom. Una cadena de caràcters amb que es coneix l'atribut.
• Sintaxi. La definició dels valors legals d'un atribut (p.e. cadena de caràcters, booleà, etc.).
• Numero de valors permesos. Indica si hi pot haver més d'un valor de l'atribut en una única classe d'objecte.

A LDAP, la majoria d'atributs són multi-valor. Per exemple, una entrada de la classe d'objecte "person" tindria un tipus d'atribut "objectClass" amb dos valors:

• "top"
• "person"

Ara, considera la següent definició de classe d'objecte, que s'utilitzarà en la creació d'un exemple d'arbre de directori:

( NAME 'department' SUP top STRUCTURAL MUST departmentName MAY description )

Fixa't que el nom numèric de la classe d'objecte s'ha omès per abreujar. La següent figura mostra una vista de la informació en un Directori d'exemple:

En la figura, els noms de la classe d'objecte s'indiquen utilitzant el tipus d'atribut oc. En aquest exemple, hi ha set entrades, amb les següents dn's, amb els noms de les classes d'objecte indicant entre parèntesi després del dn:

• departmentName = uc (department,top)
• departmentName = cs, departmentName = uc (department,top)
• departmentName = art, departmentName = uc (department,top)
• departmentName = cafe, departmentName = uc (department,top)
• cn = pablo, departmentName = art, departmentName = uc (person,top)
• cn = henri, departmentName = art, departmentName = uc (person,top)
• cn = augustus, departmentName = art, departmentName = uc (person,top)

Fixa't que l'atribut descripció de l'entrada per "cn = pablo" té dos valors diferents. La informació s'ha recuperat d'un Directori utilitzant una operació de cerca LDAP. Una operació de cerca pot utilitzar-se per recuperar atributs d'una entrada única, d'entrades del contenidor sota d'una entrada, o des d'un sub-arbre complet d'entrades. Hi ha quatre paràmetres d'interès en l'operació de cerca (actualment hi ha vuit paràmetres, però els altres no afecten aquesta discussió)

• Objecte base. El punt d'inici de la cerca. És un nom distingible.
• Abast. Indica si la cerca serà per un únic objecte, un contenidor o un sub-arbre.
• Filtre. Descriu les condicions que han d'encaixar completament per a que una entrada sigui retornada en una operació de cerca. El filtre encaixa o no encaixa en una entrada.
• Atributs. Diu la llista d'atributs que han de retornar de les entrades que encaixen amb el filtre. Si un atribut és llistat, llavors tots els valors d'aquest atribut seran retornats en el resultat de la cerca. Si no es llisten els atributs, llavors vol dir que s'han de retornar tots els atributs de les entrades.

Considera les següents operacions de cerca que s'han aplicat al mateix Directori d'exemple de la figura anterior:

• Base Object = "departmentName = uc," Scope = subtree, Filter = _"description = *sculptor"
  • Aquesta cerca hauria d'encaixar en una entrada: cn = augustus, departmentName = art, departmentName = uc.
• Base Object = "departmentName = uc," Scope = single level, Filter = "description = *sculptor"
  • Aquesta cerca no ha d'encaixar per cap entrada.
• Base Object = "departmentName = uc," Scope = subtree, Filter = _"description = *artist"
  • Aquesta cerca hauria d'encaixar en dues entrades:
    • cn = pablo, departmentName = art, departmentName = uc (person,top).
    • cn = henri, departmentName = art, departmentName = uc (person,top)
• Base Object = "departmentName = uc," Scope = subtree, Filter = _"description = *"
  • Aquesta cerca hauria d'encaixar en totes les entrades del Directori.

Problemes típics en el Disseny d'Esquemes LDAP

Els problemes típics que poden afectar en un disseny d'esquema LDAP són semblants a que et poden passar en el disseny d'un esquema de base de dades relacionant. Aquest problemes són:

• Dades redundants
• Esborrat anòmal
• Modificació anòmala
• Retornar dades no desitjades

La redundància ocorre quan la mateixa informació es repeteix en molts objectes dins el Directori. Recollir la informació en una entrada comuna en una entrada separada pot, sovint, eliminar aquesta redundància de dades. Així, quan informació comuna ha de modificar-se, aquesta només es canviarà en una entrada, no en moltes entrades del Directori.

Un esborrat anòmal ocorre quan un objecte apunta a una altre i aquest últim s'esborra del Directori. Això pot succeir freqüentment en Directoris, ja que moltes entrades tenen atributs que són noms distingibles d'altres entrades en el Directori.

Una modificació anòmala ocorre quan un objecte origen o destí es modificat i la relació implicada pel no és vàlida. Considera la situació en que una entrada té un atribut que indica el número de departament d'un usuari i l'administrador del departament. Si l'usuari canvia de departament, ambdós atributs han de canviar per a que l'entrada sigui vàlida. De forma semblant, quan el departament canvia d'administradors, l'entrada de cada usuari del departament ha de canviar amb el nom del nou administrador.

Retornar dades no desitjades ocorre quan el servidor LDAP retorna valors d'atributs que no són necessaris pel client LDAP. Això ocorre en l'LDAP perquè l'operació de cerca LDAP estàndard no permet retornar valors d'atributs individuals. A LDAP, tots els valors d'un atribut multi-valor particular retornen al client o cap d'ells ho és. En les següents seccions, hi haurà exemples dels esquemes LDAP amb aquests problema, i solucions per resoldre aquestes problemes que presentem.

Normalització de Bases de Dades Relacionals

En bases de dades relacionals, normalitzar les taules relacionals resol aquests problemes. Una base de dades relacional està feta de taules. Els tipus de dades d'una taula estan definides per la definició de la columna. Cada fila en una taula ha d'estar conforme amb les definicions de la columna. Per exemple, considera una taula usada per representar sortidors de parts que poden ordenar-se. De la forma més simple hi hauria una columna pel nom i una columna pel nom de la ciutat. Ambdós columnes són cadenes. En aquest cas, la columna del nom podria considerar-se com a clau primària que identifica una fila com a única. Això significa que no hi poden haver dues files en la taula amb el mateix nom.

Hi ha moltes regles de normalització en la teoria de les bases de dades, però les bàsiques són aquestes tres:

• Primera normalització. Una taula es diu que té la primera normalització si totes les cel·les de la taula contenen només valors atòmics. Això vol dir que no es permeten conjunts de valors en cel·les individuals.
• Segona normalització. Es diu que una taula té segona normalització si cada atribut que no és clau depèn completament de la clau primària. Aquesta també ha de complir la primera normalització.
• Tercera normalització. Es diu que una taula te tercera normalització si tots els atributs que no són clau depenen només de la clau principal. Si un d'aquests atributs depèn d'un atribut a banda de la clau principal, aquest pot ocasionar modificacions anòmales.

Passar de la segona normalització a la tercera és crea una taula de addicional. El típic exemple que usa una taula per mantenir informació de l'adreça de l'usuari. Aquesta taula tindria les següents cinc columnes:

1. User Name (clau)
2. Direcció del Carrer
3. Ciutat
4. Estat
5. Codi Postal

Aquesta taula està en la segona normalització, perquè el nom de l'usuari determina les columnes 2 a 5. Però no la tercera, ja que les columnes 2 a 4 determinen 5ena columna. Així, per passar a la tercera normalització, aquesta taula hauria de dividir-se en dues taules separades, cadascuna de les quals obeeix a la tercera normalització.

Aquestes tres regles de normalització poden aplicar-se al disseny d'esquemes LDAP per eliminar alguns dels problemes comuns. Per aplicar les regles de normalització al disseny d'esquemes LDAP, simplement substitueix la taula de les regles per la classe d'objecte, substitueix la clau primària per el nom distingible (RDN), i substitueix la cel·la per el valor de l'atribut. Aquestes són les regles per la normalització dels esquemes LDAP:

• Primera normalització. Una objecte de classe es diu que té la primera normalització si tots els valors d'atributs de la classe d'objecte contenen només valors atòmics. Això vol dir que no es permeten conjunts de valors en un únic valor d'atribut.
• Segona normalització. Es diu que una objecte de classe té segona normalització si cada atribut que no és clau depèn completament del RDN. Aquesta també ha de complir la primera normalització.
• Tercera normalització. Es diu que una objecte de classe te tercera normalització si tots els atributs que no són clau depenen només del RDN. Si un d'aquests atributs depèn d'un atribut a banda del RDN, aquest pot ocasionar modificacions anòmales.

Redundància de Dades

Considera la següent definició de classe d'objecte de persona realçada:

( NAME 'enhancedPerson' SUP person STRUCTURAL MUST ( email ) 
   MAY ( streetAddress $ city $ state $ postalCode ) )

Utilitzant aquesta la definició d'esquema, cada persona en el Directori tindrà informació emmagatzemada sobre les seves adreces de correu. En els directoris d'organitzacions con virtualment tots els usuaris tenen informació d'adreces comuna, aquesta és una forma de desaprofitar molt d'espai i és un potencial problema per a dades inconsistents. Una millor solució és eliminar la redundància normalitzant la informació posta en una classe d'objecte separada.

( NAME 'enhancedPerson' SUP person STRUCTURAL MUST ( email ) 
   MAY postalInformationDN )
( NAME 'postalInformation' SUP top STRUCTURAL MUST 
   ( cn $ streetAddress $ city $ state $ postalCode ) )

Fixa't que la informació de la persona només guarda el nom d'un altre objecte del Directori que guarda la informació actual. La classe d'objecte postalInformation s'ha dissenyat especialment per a mantenir aquesta informació.

La següent figura mostra un exemple de Directori amb aquesta informació.

Eliminant la redundància de dades.

Retornar Dades No desitjades

A LDAP, tots els valors d'un atribut són retornats com a resultat d'una cerca si el nom del tipus d'atribut està llistat en el camp atributs del filtre de cerca. Això pot ser un problema si una entrada té nombrosos valors per un atribut i el client LDAP només està interessat per un o dos dels valors. Considera l'escenari d'un correu-e segur. En una implementació típica de tecnologia de clau-pública, si un usuari anomenat Alice vol enviar un missatge encriptat a una altre usuari anomenat Bob, Alice primer haurà de rebre la clau pública d'en Bob. Quan la informació de la clau-pública està emmagatzemada en un Directori, aquesta sovint està guardada en un format especial, conegut com a Certificat.

Una definició típic d'esquema LDAP permet que el certificat d'en Bob estigui guardat en un entrada del Directori utilitzant la següent definició de classe:

( NAME 'strongAuthenticationUser SUP top AUXILIARY MAY _( userCertificate ) )
( 2.5.4.36 NAME 'userCertificate' SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )

Com que la definició del userCertificate no especifica el nombre de valors, l'atribut pot tenir qualsevol nombre de valors. En certs entorns militars i d'alta seguretat, un únic usuari pot tenir centenars de certificats. En aquesta situació, encara que un client LDAP només vulgui un certificat, tots els certificats dels usuaris seran enviats i hauran d'examinar-se un a un en ordre per trobar el certificat desitjat. No només són tots els certificats retornats pel servidor LDAP, ell els ha retornat desordenats, així el client els haurà de comprovar tots per trobar el que li interessa. Un certificat normal té uns 2K bytes. Així, un resultat LDAP amb 250 certificats contindria 500K de dades. Així, a més del sobre-cost de computació d'examinar cada certificat, el sobre-esforç de la xarxa i la lentitud de resposta. Una situació millor seria re-estructurar l'esquema i revisar el DIT. Un esquema alternatiu que resoldria aquest problema seria el proposat en l'actual Internet. Aquest esquema conté la següent definició de classe d'objecte següent:

( NAME 'certificateType' SUP top STRUCTURAL MUST typeName MAY ( serialNumber $ 
issuer $ validityNotBefore $ validityNotAfter $ subject $ subjectPublicKeyInfo $ 
 certificateExtension $ otherInfo ))

Aquesta definició extreu molts camps de l'estructura de dades del certificat per a que puguin cercar-se fàcilment per les operacions de cerca estàndard LDAP. Tots els camps excepte el certificateExtension són definits com a SINGLE-VALUE. Fixa't que no inclou un atribut de certificat. Això és així perquè el certificat està adjunt a l'entrada certificateType utilitzant un classe d'objecte auxiliar, com a strongAuthenticationUser. Aquest nou disseny pel DIT col·loca tots els certificats de l'usuari en un contenidor sota de l'entrada de l'usuari en comptes d'unida a l'entrada que ocorria en el disseny anterior. Aquesta figura ho il·lustra:

En aquest DIT l'usuari henri té tres certificats que es troben en les entrades immediatament a sota de l'entrada en el DIT. Tenen els seus noms distingibles:

• tn = Visa, cn = henri, departmentName = art, departmentName = uc
• tn = Master Card, cn = henri, departmentName = art, departmentName = uc
• tn = American Express, cn = henri, departmentName = art, departmentName = uc

Això permet que una operació de certa LDAP retorni exactament els certificats que un vol i cap més. Per exemple, per retornar el certificat de la Visa d'en Henri, hauria d'usar-se aquesta cerca:

• Base Object = "cn = henri, departmentName = art, departmentName = uc," Scope = single level, Filter = "typeName = Visa"
  • Aquesta cerca hauria d'encaixar només amb tn = Visa, cn = henri, departmentName = art, departmentName = uc

Si s'utilitza l'esquema anterior, tots els certificats de l'usuari henri haurien de guardar-se en l'atribut userCertificate. El client LDAP hauria de retornar tots els certificats i analitzar-los per trobar el que s'usés per la Visa. Fixa't que aquest disseny d'ara encara permet retornar tots els certificats d'en Henri. Això es faria utilitzant la següent operació de cerca:

• Base Object = "cn = henri, departmentName = art, departmentName = uc," Scope = single level, Filter = "objectClass = certificateType"
  • Aquesta cerca hauria d'encaixar amb els tres entrades dels certificats en DIT sota l'entrada.

Aquesta mateix mecanime de re-estructuració del DIT i redefinir les classes poden utiltizar-se en qualsevol lloc on els atributs puguin tenir numerosos valors i els clients LDAP necessiten retornar pocs valors a l'hora. Aquest mecanisme també fa que sigui simple trobar certificats d'un cert tipus. Per exemple, trobar tots els certificats del departament d'art que són per la Visa, s'utiltizaria la següent operació de cerca:

• Base Object = "departmentName = art, departmentName = uc," Scope = subtree, Filter = "typeName = Visa"
  • Aquesta cerca hauria d'encaixar amb els tres certificats Visa.
    • tn = Visa, cn = henri, departmentName = art, departmentName = uc
    • tn = Visa, cn = pablo, departmentName = art, departmentName = uc
    • tn = Visa, cn = augustus, departmentName = art, departmentName = uc

En aquests exemples, totes les entrades certificateType són retornades. Fixa't que és possible retornar el propi certificat pel nom de l'atribut "type" des de l'operació de cerca. Fixa't que si hi ha múltiples certificats Visa per un únic usuari, llavors l'atribut userCertificate hauria de tenir múltiples valors per aquesta entrada certificateType. Si passa aquesta situació, s'hauria de desenvolupar un nou esquema per les entrades certificateType.

Eliminar i Actualitzar Anomalies

Eliminar i Actualitzar Anomalies ocorre a LDAP quan hi ha una referència en una entrada a un nom distingible d'una altra entrada. Quan el nom distingible referenciat és eliminat o modificat, les referències de les entrades ya no són vàlides. Algunes implementacions LDAP van a aquests problemes quan les entrades són eliminades o mogudes per assegurar-se que tots els objectes que que referencien l'entrada modificada o eliminada són actualitzats correctament.

Un millor solució que elimina aquestes anomalies és re-estructurar el DIT aprofitant la jerarquia. Algunes classe d'objecte utilitzen la tècnica de situar els noms distingibles de les entrades referenciades directament en l'entrada com en una classe d'objecte estàndard LDAP:

(2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST _
( member $ cn ) MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )

quan l'atribut membre té aquesta definició:

( 2.5.4.31 NAME 'member' SUP distinguishedName )

L'ús de la designació SUP en la definició del tipus d'atribut és semblant a l'ús en la definició de la classe d'objecte. És una indicació que les regles de sintaxi i equivalència en el tipus d'atribut SUP especificat han d'usar-se en aquesta definició de tipus d'atribut. Utilitzant aquesta definició, cada cop que un membre en el groupOfNames és eliminat o se li canviï el nom, l'objecte groupOfNames ha de modificar-se per a que tots els valors de l'atribut membre siguin vàlids. Una solució millor és eliminar l'atribut membre de la classe d'objecte groupOfNames i situar totes les entrades membre en el DIT sota l'objecte groupOfNames. Desafortunadament, aquesta no és una solució ja que no permet que la mateixa entrada membre sigui membre en múltiples grups. Tanmateix, hi ha moltes aplicacions que re-estructuren els DIT d'aquesta manera.

Un Exemple

Un esquema LDAP pot dissenyar-se per mantenir la mateixa informació que un esquema d'una base de dades relacional. Utiltizant les recomanacions anteriors per evitar els mateixos problemes en el disseny dels esquemes LDAP. Considereu el següent esquema de base de dades:

Aquest esquema representa la informació sobre els articles que poden ordenar-se de varis proveïdors. Les columnes amb asterisc "*" al final dels seus noms són columnes sense clau que són claus primàries d'altres taules. Aquestes columnes s'anomenen claus foranies. Una companyia té oficines en varies ciutats i pot fer ordres d'articles de varis fonts que les tinguin disponibles. Les diferents fonts i les seves situacions estan representades en la taula Proveïdor. L'estatus de cadascuna de de les oficines de la companyia estan representades de la taula Estat ciutat. La informació sobre les diferents articles que poden demanar-se estan representades en la taula Article. Finalment, la llista actual d'articles que ha estat estat demanada a varis proveïdors es representa en la taula Enviament. S'assumeix que qualsevol article pot demanar a cada proveïdors situat en una única ciutat. Aquest esquema és una tercera normalització.

Dades de la Taula Proveïdors

Dades de la Taula Estat Ciutat

Dades de la Taula Article

Dades de la Taula Enviaments

Assumeix que les taules de la base de dades tenen aquesta informació. Ara, com es pot crear un esquema LDAP que representi la mateixa informació? És directe crear una classe d'objecte que tingui els mateixos atributs que cada taula. Tanmateix, és crucial entendre les relacions de les claus foranies, que t'ajudaran a crear l'estructura del DIT. Sempre que sigui possible, si una taula té una clau forana llavors les entrades LDAP que són en la classe d'objecte que corresponen a aquesta taula han de ser filles de les entrades LDAP que corresponen a la taula en que la clau forana és clau principal. Per exemple, la columna ciutat de la taula proveïdor és una clau forana. És la clau primària de la taula Estat Ciutat. Així les entrades proveïdor de l'LDAP haurien de ser filles de les entrades Estat Ciutat. Això ens porta a les definicions de les dos primeres classes d'objecte:

( NAME 'cityStatus' SUP top STRUCTURAL MUST (cityName $ status) ) 
( NAME 'supplier' SUP top STRUCTURAL MUST supplierNumber )

Fixa't que la classe d'objecte proveïdor no inclou l'atribut nom_ciutat. Això és així perquè l'atribut és implícit per la relació pare-fill i pot retornar-se pel DN de la entrada del proveïdor. La següent figura il·lustra la porció del DIT resultant que les entrades fetes amb aquestes dues classes d'objecte.

En aquesta figura pots veure que cada entrada de proveïdor és un fill d'una entrada ciutat on és situat. Així, els DN de les entrades dels proveïdors són:

• SupplierNumber = S1, cityName = London, o =acme.com
• SupplierNumber = S2, cityName = London, o =acme.com
• SupplierNumber = S3, cityName = London, o =acme.com
• SupplierNumber = S4, cityName = London, o =acme.com
• SupplierNumber = S5, cityName = London, o =acme.com

Una de les propietat dels esquemes de les bases de dades relacionals és que les ciutats poden ser representades en la base de dades, encara que no tinguin proveïdor en aquesta ciutat. Fixa't que aquesta representació preserva aquesta propietat.

Fixa't també que la taula Article no té claus foranies. Les seves entrades poden residir en el mateix nivell del DIT que les entrades "ciutat". Però per claredat, seran situades en una entrada organizationalUnit anomenada ou=parts. Les entrades d'Enviaments són un altres cas. Tenen dues claus foranies. Un de les claus foranies s'escollirà com una entrada pare en el DIT, mentre en l'altre s'usarà una referència. Les referències de classes d'objectes LDAP a altres entrades sempre són representades com a DN. Això ens duu a les altres dues definicions de classe d'objecte:

( NAME 'part' SUP top STRUCTURAL MUST (partNumber $ partName $ color $ weight) ) 
( NAME 'supplierShipment' SUP top STRUCTURAL MUST (partNumberDN $ quantity ) )

Aquestes classes d'objecte usaran aquestes definicions de tipus d'atribut:

NAME 'cityName' SUP name )
NAME 'status' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
NAME 'supplierNumber' SUP name )
NAME 'partNumber' SUP name )
NAME 'partName' SUP name )
NAME 'color' SUP name )
NAME 'weight' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
NAME 'partNumberDN' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
NAME 'quantity' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

La sintaxi usada en aquesta definició de tipus d'atribut està definida en la RFC 2252. L'esquema complet DIT que correspon a la informació definida en la base de dades relacional es mostra en la següent figura:

Fixa't que aquesta representació permet accedir a una única ordre de cada proveïdor. Si hi hagués un requeriment de múltiples ordres d'un únic proveïdor, la classe d'objecte supplierShipment podria tenir un atribut de número d'ordre. Donat que cada número d'ordre seria únic, aquest nou atribut permetria la creació de múltiples ordres des d'un únic proveidor. Ja que aquest no és un requeriment de la base de dades relacional, no s'ha afegit en l'esquema LDAP. En el DIT, cada entrada d'Enviament és una filla del corresponent proveïdor i té un punter a número d'article que ha ordenat al proveïdor. Cercar per varis elements en aquest DIT és directe. Considera els següents problemes i les cerques LDAP resultants:

• Trobar totes les ordres del número de part P3
  • Base Object = "o = acme.com," Scope = subtree, Filter = "(&(object-Class = supplierShipment) (partnumberDN = 'partnumber-P3, ou = parts, o = acme.com'))"
• Trobar totes les ordres del proveïdor S2
  • Base Object = "supplierNumber = S2, cityName = Paris, o = acme .com," Scope = single-level, Filter = "objectClass = supplierShipment"

Quan es necessitin entrar noves ordres al sistema, llavors s'hauran de crear només entrades d'enviament en el DIT. Per exemple, per afegir una ordre de 500 unitats de l'article P4 des del proveïdor S3, s'hauria de fer la següent operació d'afegir:

• Nom de la nova entrada.—"partnumberDN = 'partnumber-P4, ou = parts, o = acme.com', supplierNumber = S3, cityName = Paris, o = acme.com"
• Atributs:
  • ObjectClass—Top, supplierShipment
  • Quantity—500

Fixa't que el DN del número d'article s'utilitza com part del DN de la entrada de l'enviament. Encara que faci els DN llargs, no és il·legal. Tanmateix, per conveniència amb el món real, els numero d'odres segurament haurien d'analitzar-se més a fons.

Resum

Com s'ha mostrat en aquest capítol, les regles de normalització SQL poden aplicar-se directament a la jerarquia natural d'un esquema LDAP i en dissenys DIT. El capítol mostra com les lliçons apresses en la normalització de bases de dades SQL poden aplicar-se a l'LDAP eliminant des dades redundants, reduint les possibilitats de retornar dades no desitjades i mostrar com les anomalies d'eliminar i modificar poden eliminar-se en certes circumstàncies.