Nawigacyjna baza danych - Navigational database

Bazie nawigacyjne to rodzaj bazy danych , w którym rekordy lub obiekty znajdują się przede wszystkim następujące referencje od innych obiektów. Termin został spopularyzowany przez tytuł pracy Charlesa Bachmana z 1973 r. Turinga , The Programmer as Navigator . W artykule podkreślono fakt, że nowe dyskowe systemy baz danych umożliwiły programiście wybór dowolnych tras nawigacyjnych zgodnie z relacjami od rekordu do zapisu, kontrastując to z ograniczeniami wcześniejszych systemów taśm magnetycznych i kart perforowanych, w których dostęp do danych był ściśle sekwencyjny.

Jedną z najwcześniejszych nawigacyjnych baz danych był Integrated Data Store (IDS), który został opracowany przez Bachmana dla General Electric w latach sześćdziesiątych XX wieku. IDS stał się podstawą modelu bazy danych CODASYL w 1969 roku.

Chociaż Bachman opisał koncepcję nawigacji w kategoriach abstrakcyjnych, idea dostępu nawigacyjnego zaczęła być silnie kojarzona z proceduralnym projektem języka manipulacji danymi CODASYL . Na przykład Tsichritzis i Lochovsky pisząc w 1982 r. Stwierdzają, że „Pojęcie waluty jest centralne w koncepcji nawigacji”. Przez pojęcie waluty odnoszą się do idei, że program utrzymuje (jawnie lub niejawnie) bieżącą pozycję w dowolnej sekwencji rekordów, które przetwarza, oraz że operacje takie jak GET NEXT i GET PRIOR odzyskiwanie rekordów w odniesieniu do tej bieżącej pozycji, jednocześnie zmieniając bieżąca pozycja do rekordu, który jest pobierany.

W ten sposób programowanie nawigacyjnych baz danych zaczęto postrzegać jako z natury proceduralne ; a ponadto polegać na utrzymywaniu domyślnego zestawu zmiennych globalnych ( wskaźników walutowych ) utrzymujących stan bieżący. W związku z tym podejście to było postrzegane jako diametralne przeciwieństwo deklaratywnego stylu programowania używanego przez model relacyjny . Deklaratywny charakter języków relacyjnych, takich jak SQL, oferował lepszą produktywność programistów i wyższy poziom niezależności danych (to znaczy zdolność programów do kontynuowania pracy wraz z rozwojem struktury bazy danych). W rezultacie interfejsy nawigacyjne były stopniowo przyćmione podczas Przez deklaratywne języki zapytań.

W latach dziewięćdziesiątych stało się jasne, że w przypadku niektórych aplikacji obsługujących złożone dane (na przykład przestrzenne bazy danych i inżynieryjne bazy danych) rachunek relacyjny ma ograniczenia. W tym czasie rozpoczęła się ponowna ocena całego rynku baz danych, a kilka firm opisało nowe systemy przy użyciu marketingowego terminu NoSQL . Wiele z tych systemów wprowadziło języki manipulacji danymi, które, choć dalekie od CODASYL DML z jego wskaźnikami walutowymi, mogą być rozumiane jako implementacja „nawigacyjnej” wizji Bachmana. Niektóre z tych języków mają charakter proceduralny; inne (takie jak XPath ) są całkowicie deklaratywne. Odłamki koncepcji nawigacyjnej, takie jak baza danych wykresów , znalazły nowe zastosowania w nowoczesnych obciążeniach przetwarzania transakcji .

Opis

Nawigacyjne dostępu tradycyjnie związane z modelu sieci i hierarchicznego modelu w bazie danych , a typowo opisuje API manipulacji danych, w którym zapisy (lub obiekty) są przetwarzane jeden po drugim, iteracyjnie. Zasadniczą cechą opisaną przez Bachmana jest jednak znajdowanie rekordów na podstawie ich relacji z innymi rekordami: więc interfejs może nadal służyć do nawigacji, jeśli ma cechy zorientowane na zestaw. Z tego punktu widzenia kluczową różnicą między językami manipulacji danymi nawigacyjnymi a językami relacyjnymi jest użycie jawnych nazwanych relacji, a nie sprzężeń opartych na wartościach: for department with name="Sales", find all employees in set department-employees versus find employees, departments where employee.department-code = department.code and department.name="Sales" .

W praktyce jednak większość nawigacyjnych interfejsów API ma charakter proceduralny: powyższe zapytanie byłoby wykonane przy użyciu logiki proceduralnej na podstawie następującego pseudokodu: 

get department with name='Sales'
get first employee in set department-employees
until end-of-set do {
  get next employee in set department-employees
  process employee
}

Z tego punktu widzenia kluczową różnicą między nawigacyjnymi interfejsami API a modelem relacyjnym (zaimplementowanym w relacyjnych bazach danych ) jest to, że relacyjne interfejsy API używają „deklaratywnych” lub logicznych technik programowania , które pytają system, co ma pobrać, podczas gdy nawigacyjne interfejsy API instruują system w sekwencji kroki, jak dotrzeć do wymaganych rekordów.

Większość uwag krytycznych dotyczących nawigacyjnych interfejsów API należy do jednej z dwóch kategorii:

  • Użyteczność: kod aplikacji szybko staje się nieczytelny i trudny do debugowania
  • Niezależność danych: kod aplikacji musi się zmieniać za każdym razem, gdy zmienia się struktura danych

Przez wiele lat podstawową obroną nawigacyjnych interfejsów API była wydajność. Systemy baz danych obsługujące nawigacyjne interfejsy API często używają struktur pamięci wewnętrznej, które zawierają fizyczne łącza lub wskaźniki z jednego rekordu do drugiego. Chociaż takie struktury mogą umożliwiać bardzo wydajną nawigację, mają one wady, ponieważ reorganizacja fizycznego rozmieszczenia danych staje się trudna. Jest całkiem możliwe zaimplementowanie nawigacyjnych interfejsów API bez podążania za wskaźnikami niskiego poziomu (artykuł Bachmana przewidywał zaimplementowanie relacji logicznych tak samo, jak w systemach relacyjnych, przy użyciu kluczy podstawowych i kluczy obcych), więc tych dwóch pomysłów nie należy łączyć. Ale bez korzyści wydajnościowych wskaźników niskiego poziomu, nawigacyjne interfejsy API stają się trudniejsze do uzasadnienia.

Modele hierarchiczne często konstruują klucze podstawowe dla rekordów poprzez konkatenację kluczy, które pojawiają się na każdym poziomie w hierarchii. Takie złożone identyfikatory można znaleźć w nazwach plików komputerowych ( /usr/david/docs/index.txt ), w identyfikatorach URI, w systemie dziesiętnym Deweya , a także w adresach pocztowych. Taki klucz złożony można uznać za reprezentujący ścieżkę nawigacyjną do rekordu; ale równie dobrze można go uważać za prosty klucz podstawowy umożliwiający dostęp asocjacyjny.

Gdy systemy relacyjne zyskały na znaczeniu w latach 80. XX wieku, nawigacyjne interfejsy API (aw szczególności procedury proceduralne) zostały skrytykowane i wypadły z łask. Jednak lata dziewięćdziesiąte przyniosły nową falę obiektowych baz danych, które często zapewniały zarówno deklaratywne, jak i proceduralne interfejsy. Jednym z wyjaśnień jest to, że były one często używane do przedstawiania informacji o strukturze graficznej (na przykład danych przestrzennych i danych inżynierskich), gdzie dostęp jest z natury rekurencyjny: matematyka leżąca u podstaw SQL (w szczególności rachunek predykatów pierwszego rzędu) nie ma wystarczającej mocy, aby obsługują zapytania rekurencyjne, nawet tak proste, jak domknięcie przechodnie .

Aktualny przykład popularnego nawigacyjnego interfejsu API można znaleźć w Document Object Model (DOM) często używanym w przeglądarkach internetowych i ściśle związanym z JavaScript . DOM jest zasadniczo hierarchiczną bazą danych w pamięci z interfejsem API, który jest zarówno proceduralny, jak i nawigacyjny. Natomiast dostęp do tych samych danych ( XML lub HTML ) można uzyskać za pomocą XPath , który można sklasyfikować jako deklaratywne i nawigacyjne: dostęp do danych uzyskuje się za pomocą następujących relacji, ale program wywołujący nie wydaje sekwencji instrukcji, których należy przestrzegać w kolejności. Języki takie jak SPARQL używane do pobierania danych połączonych z sieci semantycznej są jednocześnie deklaratywne i nawigacyjne.

Przykłady

Zobacz też

Bibliografia

Zewnętrzne linki