sobota, 7 maja 2011

Podstawy LDAP

Wstęp


Większość artykułów na ten temat wędruje strasznie dookoła z definicją, co to właściwie jest ten LDAP. Na początek formalna definicja: LDAP to skrót od terminu "Lighweight Directory Access Protocol", czyli "Lekki Protokół Dostępu do Usług Katalogowych". Skąd ten "lekki"? Otóż LDAP jest uproszczeniem strasznie zakręconego protokołu X.500, który opisywany jest jako "DAP". Tyle teoria - co to jest w praktyce?

Na początek LDAP można potraktować jak zwykłą bazę danych: Są w niej rekordy, w rekordach są pola z danymi, można dopisywać i kasować rekordy oraz wyszukiwać rekordy spełniające podane kryteria. Dobrze - to potrafią zwykłe bazy danych. Po co wprowadzać nowy standard? Otóż klasyczne bazy danych (Relational Database, RDB) mają dwie podstawowe cechy:

  • baza jest homogeniczna, czyli wszystkie rekordy mają tą samą strukturę (kolejność, nazwy i typy pól)

  • baza jest płaska czyli można ją zapisać rekord za rekordem jako tablicę - wszystkie rekordy są równorzędne i w podejściu klasycznym nieuporządkowane.


Opisać to można jako worek z jednakowo zbudowanymi pudełkami w środku.

W LDAP dla odmiany obie te reguły są złamane:

  • baza LDAP jest heterogeniczna, czyli każdy rekord może mieć inną strukturę - co więcej, budowa rekordu może się zmieniać w czasie

  • baza LDAP jest hierarchiczna (drzewiasta), czyli jedne rekordy mogą być rekordami podrzędnymi dla innych. Dodatkowo zamiast rekodu można umieścić odnośnik do zupełnie innego miejsca w drzewie.


Opisać to można jak matrioszkę - pudełka w pudełkach, a każde może być inaczej zbudowane.

Adresowanie rekordów


Ze względu na różną reprezentację "logiczną" baz, w RDB i LDAP różnie adresuje się rekordy.

W RDB do adresowania rekordów służy tzw. klucz główny - specjalna kolumna zawierająca wartość unikalną i różną dla każdego rekordu (często stosowany jest numer kolejny rekordu w bazie). Czyli adres rekordu to np. "1158".

W LDAP też można zasymulować klucz główny. Można zrobić pole rekordu z unikalnym numerem i według niego szukać, ale nie o to przecież chodzi. LDAP do wskazania rekordów wykorzystuje ścieżkę do rekordu (distinguished name, DN). W obrębie jednego poziomu hierarchii (jednego rekordu nadrzędnego) stosowany jest skrót, nazwa rekordu (relative distinguished name, RDN). Żeby było bardziej obrazowo - LDAP zachowuje się jak dysk: rekordy to pliki, DN to absolutna ścieżka do pliku a RDN to względna ścieżka do pliku. Adresy rekordów LDAP są dłuższe od kluczy RDB, jednak sa bardziej obrazowe: "cn=Kowalski,ou=Kadry,dc=Firma,dc=pl". Jak zmrużycie oczy, to wygląda to trochę jak nazwa domenowa ('kowalski.kadry.firma.pl'). Jak to się czyta?

Podana zazwa składa się tutaj z 4 części, czytanych od prawej do lewej i oddzielonych przecinkami. Każda część ma postać typ=nazwa. Typ określa charakter danej opisanej nazwą:

  • cn - nazwa rekordu (od common name) - to jest najbliższe kluczowi głównemu.

  • dc - fragment adresu DNS podmiotu opisanego DN, czyli firma.pl staje się dc=Firma,dc=pl (od directory context)

  • o - nazwa firmy (od organization)

  • ou - oddział firmy (od organizational unit)

  • c - kraj (od country)

  • l - miasto (od locality)


Ostatnia część DN, wspólna dla wszystkich rekordów w bazie LDAP to tzw adres bazowy (base distingushed name). Może być konstruowany na kilka sposobów:

  • od adresu DNS firmy: dc=Firma,dc=pl (forma preferowana) bądź o=firma.com (forma przestarzała)

  • od nazwy firmy: o=Super Firma,c=pl

  • od lokalizacji geograficznej: o=Super Firma,l=Szczecin,st=Zachodniopomorskie,c=pl


Przykład


Zasadniczą różnicę między LDAP a RDB pokażę w dekompozycji uproszczonego problemu pod tytułem faktura VAT (moi studenci z baz danych już pewnie mają gęsią skórkę na karku). Żeby zbytnio nie przeciągąć:

RDB



  • Faktura jest rekordem w tabeli FAKTURY zawierającym dane faktury, jako całości: datę, numer, forma płatności, dane kontrahenta, itd.

  • Faktura ma kolejne wpisy umieszczone w tabeli SZCZEGÓŁY. Każdy wpis zawiera towar, ilość, cenę, podatek, numer wpisu na fakturze i numer faktury do której należy.


Jak widać, w tym super-duper-uproszczonym przypadku mamy już dwie tabele, przy realizacji praktycznej trzeba jeszcze zrobić tabele z kontrahentami, produktami, cenami, stawkami VAT, itp - w ogólności należy przeprowadzić normalizację bazy danych.

LDAP



  • jest drzewo ogólnych danych firmy dc=Firma,dc=pl

  • jest tam poddrzewo 'faktury' ou=faktury,dc=Firma,dc=pl

  • każda faktura jest rekordem zawierającym dane faktury - datę, numer, dane kontrahenta, itd. cn=FV01/06,ou=faktury,dc=Firma,dc=pl

  • szczegóły faktury są podrekordami danej faktury: zawierają towar, ilość, cenę, podatek cn=1,cn=FV01/06,ou=faktury,dc=Firma,dc=pl


Jak widać faktura w RDB jest rozsmarowana po wielu rekordach co najmniej dwóch tabel a w LDAP jest zebrana jako jeden rekord z przynależnymi mu podrekordami (tzw. poddrzewo).