Navigationsdatabase - Navigational database

En navigationsdatabase er en type database , hvor poster eller objekter primært findes ved at følge referencer fra andre objekter. Udtrykket blev populariseret med titlen på Charles Bachmans 1973 Turing Award- papir, The Programmer as Navigator . Dette papir understregede det faktum, at de nye diskbaserede databasesystemer tillod programmøren at vælge vilkårlige navigationsruter efter forhold fra record til record, hvilket kontrasterer dette med begrænsningerne fra tidligere magnetbånd og stansede kortsystemer, hvor dataadgang var strengt sekventiel.

En af de tidligste navigationsdatabaser var Integrated Data Store (IDS), som blev udviklet af Bachman til General Electric i 1960'erne. IDS blev grundlaget for CODASYL- databasemodellen i 1969.

Selvom Bachman beskrev begrebet navigation i abstrakte termer, kom ideen om navigationsadgang til at være stærkt forbundet med det proceduremæssige design af CODASYL Data Manipulation Language . I 1982 skrev Tsichritzis og Lochovsky for eksempel, at "begrebet valuta er centralt i begrebet navigation." Ved begrebet valuta henviser de til tanken om, at et program (eksplicit eller implicit) opretholder en nuværende position i enhver sekvens af poster, som det behandler, og at operationer såsom GET NEXT og GET PRIOR henter poster i forhold til denne aktuelle position, mens de også ændres den aktuelle position til den post, der hentes.

Navigational databaseprogrammering dermed kom til at blive opfattet som uløseligt proceduremæssige ; og desuden at afhænge af opretholdelsen af ​​et implicit sæt af globale variabler ( valutaindikatorer ), der holder den nuværende tilstand. Som sådan blev tilgangen set som diametralt modsat til den deklarative programmeringsstil , der blev brugt af den relationelle model . Den deklarative karakter af relationelle sprog som SQL tilbød bedre programmørproduktivitet og et højere niveau af datauafhængighed (det vil sige programmers evne til at fortsætte med at arbejde, når databasestrukturen udvikler sig.) Navigationsgrænseflader blev derfor gradvist formørket i løbet af 1980'erne ved deklarative forespørgselssprog.

I løbet af 1990'erne begyndte det at blive klart, at relationelle beregninger havde begrænsninger for visse applikationer, der håndterer komplekse data (for eksempel rumlige databaser og tekniske databaser). På det tidspunkt begyndte en ny vurdering af hele databasemarkedet, hvor flere virksomheder beskrev de nye systemer ved hjælp af markedsføringsbetegnelsen NoSQL . Mange af disse systemer indførte datamanipulationssprog, som, selvom de var langt væk fra CODASYL DML med sine valutaindikatorer, kunne forstås som implementering af Bachmans "navigationsvision". Nogle af disse sprog er proceduremæssige; andre (såsom XPath ) er helt deklarative. Offshoots af navigationskonceptet, såsom grafdatabasen , fandt nye anvendelser i moderne arbejdsbelastninger til transaktionsbehandling .

Beskrivelse

Navigationsadgang er traditionelt forbundet med netværksmodellen og den hierarkiske model af databasen og beskriver konventionelt databehandlings-API'er, hvor poster (eller objekter) behandles en ad gangen iterativt. Det væsentlige kendetegn som beskrevet af Bachman er imidlertid at finde poster i kraft af deres forhold til andre poster: så en grænseflade kan stadig være navigationsdygtig, hvis den har sætorienterede funktioner. Fra dette synspunkt er nøgleforskellen mellem navigationsdatamanipulationssprog og relationelle sprog brugen af ​​eksplicitte navngivne relationer snarere end værdibaserede sammenføjninger: 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" .

I praksis har de fleste navigations-API'er imidlertid været proceduremæssige: ovenstående forespørgsel vil blive udført ved hjælp af procedurelogik i retning af følgende pseudokode: 

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
}

På dette synspunkt er nøgleforskellen mellem navigations-API'er og relationsmodellen (implementeret i relationsdatabaser ), at relations-API'er bruger "deklarative" eller logiske programmeringsteknikker , der spørger systemet, hvad de skal hente, mens navigations-API'er instruerer systemet i en rækkefølge af trin, hvordan man når de krævede poster.

Mest kritik af navigations-API'er falder i en af ​​to kategorier:

  • Brugervenlighed: applikationskode bliver hurtigt uleselig og vanskelig at fejle
  • Datauafhængighed: applikationskoden skal ændres, når datastrukturen ændres

I mange år var det primære forsvar for navigations-API'er ydeevne. Databasesystemer, der understøtter navigations-API'er, bruger ofte interne lagringsstrukturer, der indeholder fysiske links eller markører fra en post til en anden. Selvom sådanne strukturer muligvis muliggør meget effektiv navigation, har de ulemper, fordi det bliver svært at omorganisere den fysiske placering af data. Det er meget muligt at implementere navigations-API'er uden at jage på lavt niveau markør (Bachmans papir forudsagde, at logiske relationer blev implementeret ligesom i relationelle systemer ved hjælp af primære nøgler og fremmednøgler), så de to ideer bør ikke sammenflettes. Men uden præstationsfordelene ved markører på lavt niveau bliver navigations-API'er sværere at retfærdiggøre.

Hierarkiske modeller konstruerer ofte primære nøgler til poster ved at sammenkæde de nøgler, der vises på hvert niveau i hierarkiet. Sådanne sammensatte identifikatorer findes i computerens filnavne ( /usr/david/docs/index.txt ), i URI'er, i Dewey-decimalsystemet og for den sags skyld i postadresser. En sådan sammensat nøgle kan betragtes som repræsenterende en navigationssti til en post; men ligeledes kan det betragtes som en simpel primær nøgle, der tillader associativ adgang.

Da relationssystemer blev fremtrædende i 1980'erne, blev navigations-API'er (og især proceduremæssige API'er) kritiseret og faldt ud af favør. I 1990'erne bragte imidlertid en ny bølge af objektorienterede databaser, der ofte leverede både deklarative og proceduremæssige grænseflader. En forklaring på dette er, at de ofte blev brugt til at repræsentere grafstrukturerede oplysninger (for eksempel geodata og ingeniørdata), hvor adgang i sig selv er rekursiv: matematikken, der understøtter SQL (specifikt første ordens prædikatberegning) har ikke tilstrækkelig kraft til at understøtter rekursive forespørgsler, selv de så enkle som en midlertidig lukning .

Et aktuelt eksempel på en populær navigations-API findes i Document Object Model (DOM), der ofte bruges i webbrowsere og tæt knyttet til JavaScript . DOM er i det væsentlige en hierarkisk database i hukommelsen med en API, der er både processuel og navigationsmæssig. I modsætning hertil kan de samme data ( XML eller HTML ) tilgås ved hjælp af XPath , som kan kategoriseres som deklarativ og navigationsmæssig: data tilgås ved at følge relationer, men det opkaldende program udsteder ikke en række instruktioner, der skal følges i rækkefølge. Sprog som SPARQL, der bruges til at hente sammenkædede data fra det semantiske web, er også samtidigt deklarative og navigationsmæssige.

Eksempler

Se også

Referencer

eksterne links