Praca magisterska



Pobieranie 1,09 Mb.
Strona1/16
Data20.11.2017
Rozmiar1,09 Mb.
  1   2   3   4   5   6   7   8   9   ...   16

Język zapytań dla XML oparty na podejściu stosowym

POLSKO-JAPOŃSKA WYŻSZA SZKOŁA TECHNIK KOMPUTEROWYCH


PRACA MAGISTERSKA
Nr ................

Język zapytań dla XML oparty na podejściu stosowym



Studenci

Rafał Hryniów

Tomasz Pieciukiewicz

Nr albumu

829

871


Promotor

prof. dr hab. Kazimierz Subieta

Specjalność

Bazy Danych i Inżynieria Oprogramowania

Katedra

Inżynierii Oprogramowania

Data zatwierdzenia tematu

20.05.2001

Data zakończenia pracy

15.06.2002



Podpis promotora pracy

Podpis kierownika katedry

....................................

.........................................

Streszczenie

Niniejsza praca przedstawia zaimplementowany przez autorów język zapytań do XML oparty na podejściu stosowym. Obszary, których dotyczy praca to: języki zapytań, XML i narzędzia wspomagające tworzenie repozytoriów dokumentów.

We wstępie autorzy przedstawiają cel powstania niniejszej pracy oraz motywacje stojące za jego wyborem. Opisują też podział pracy pomiędzy autorów.

W rozdziale dotyczącym stanu sztuki autorzy przedstawiają standardy i technologie dotyczące poszczególnych obszarów, których dotyczy praca, jak również wskazują niedostatki istniejących rozwiązań i kroki, jakie należy podjąć w celu ich wyeliminowania.

W rozdziale dotyczącym narzędzi i teorii znajdują się informacje dotyczące narzędzi użytych podczas tworzenia implementacji języka zapytań, jak również zwięzły opis teorii, na której opiera się główny element niniejszej pracy.

Rozdział omawiający rezultaty pracy opisuje składnię i semantykę stworzonego języka oraz API udostępniane użytkownikowi.

Kolejny rozdział zawiera szczegółowy opis implementacji i zastosowanych rozwiązań technicznych, użyte struktury danych, jak również zastosowane algorytmy.

W ostatnim rozdziale można znaleźć informacje na temat trudności napotkanych podczas realizacji pracy. Autorzy wskazują również potencjalne obszary zastosowań stworzonego języka zapytań, jak również możliwości jego dalszego rozwoju.



Spis Treści

I.Wstęp 5

II.Stan sztuki 7

1.Repozytoria 7



1.1.Zastosowanie repozytoriów 7

1.2.Informacje o dokumentach przechowywanych w repozytoriach 7

1.3. Podstawowe założenia repozytoriów 8

1.4.Uchwyty 9

1.5.Struktura Repozytorium 9

1.6.Repository Access Protocol 10

1.7.Inne podejścia 10

1.8.Dostrzeżone braki 11

1.9.Proponowane rozwiązanie 11

2.XML (eXtensible Markup Language) 11



2.1.Geneza XML 12

2.2.Własności XML 12

2.3.Znaczenie XML 14

2.4.XML – Zastosowanie 14

2.5.Technologie i standardy powiązane z XML 16

3.Języki zapytań 22



3.1.Języki zapytań w systemach relacyjnych 23

3.2.Języki zapytań w systemach obiektowych 24

3.3.Języki zapytań dla XML 25

3.4.Próba oceny przydatności istniejących rozwiązań 32

3.5.Proponowane rozwiązanie 33

III.Narzędzia i teorie zastosowane podczas realizacji pracy 34

4.Język Java 34



4.1.Co to jest Java 34

4.2.Java a inne języki programowania 35

4.3.Java a XML 36

4.4.Dlaczego właśnie Java? 36

5.Parser XERCES i standard DOM 37



5.1.Standard DOM 37

5.2.Parser XERCES 38

6.Narzędzia wspomagające tworzenie parserów 38



6.1.JFLEX 38

6.2.CUP 39

7.Teoria stosowych języków zapytań 39



7.1.Podejście stosowe 39

7.2.Podejście stosowe a języki zapytań 42

7.3.Podejście stosowe na tle innych teorii 44

7.4.Podejście stosowe a XML 44

IV.Omówienie rezultatów pracy 45

8.Omówienie języka zapytań dla XML stanowiącego zasadniczy rezultat pracy 45



8.1.Składania języka 45

8.2.Stos rezultatów 47

8.3.Semantyka języka zapytań dla XML 47

8.4.Linki i sposób ich użycia 56

9.Omówienie API udostępnianego przez system 58



9.1.Klasa edu.t2r.magisterka.QueryExecutor 58

9.2.Klasa edu.t2r.magisterka.ReferenceManager 59

9.3.Klasy klasa edu.t2r.magisterka.parser i edu.t2r.magisterka.Lexer 60

9.4.Klasa edu.t2r.magisterka.LinkManager 60

9.5.Metody służące do operacji na węzłach XML 61

V.Omówienie implementacji 62

10.Rozwiązania implementacyjne – struktury danych 62



10.1.Skład obiektów 62

10.2.Stos środowisk i rezultatów 62

10.3.Bindery 63

10.4.Zarządzanie referencjami 64

11.Rozwiązania implementacyjne – implementacja operatorów algebraicznych 65



11.1.Operatory arytmetyczne 65

11.2.Operatory działające na łańcuchach tekstowych 66

11.3.Operatory logiczne 67

11.4.Operatory porównań 69

11.5.Operatory działające na kolekcjach 71

11.6.Operatory zmiany nazwy 72

11.7.Złączenia 74

12.Rozwiązania implementacyjne – implementacja operatorów nie-algebraicznych 75



12.1.Operatory selekcji 75

12.2.Kwantyfikatory 76

12.3.Złączenia 77

12.4.Inne operatory 78

13.Rozwiązania implementacyjne – operacje ellipse i $ 79



13.1.Implementacja operacji 79

13.2.O czym należy pamiętać przy rozszerzaniu funkcjonalności języka o operacje aktualizacji 80

14.Rozwiązania implementacyjne – implementacja linków 80



14.1.Zebranie informacji o węzłach z identyfikatorami 80

14.2.Obsługa linków w trakcie wykonywania zapytań 80

14.3.O czym należy pamiętać przy rozszerzaniu funkcjonalności języka o operacje aktualizacji 80

15.Rozwiązania implementacyjne – interpretacja zapytań 81



15.1.Konstrukcja skanera 81

15.2.Konstrukcja parsera 82

15.3.Konstrukcja drzewa rozbioru gramatycznego 85

VI.Zakończenie 88

16.Trudności przy realizacji pracy 88



16.1.Wpływ DOM na sposób realizacji pracy 88

16.2.Inne napotkane trudności 88

17.Wady i zalety przyjętego rozwiązania 89



17.1.Zalety przyjętego rozwiązania 89

17.2.Wady przyjętego rozwiązania 89

18.Potencjalne zastosowania pracy 89



18.1.Możliwości wykorzystania rezultatu pracy w konstrukcji repozytorium dokumentów 89

18.2.Możliwości wykorzystania pracy w konstrukcji aplikacji 90

19.Możliwości rozwoju pracy 90






  1. Wstęp

W dotychczasowym toku studiów magistranci dostrzegli brak dobrych rozwiązań dotyczących dwóch istotnych zdaniem autorów zagadnień:

  • Brak opartego na mocnych podstawach teoretycznych i łatwo rozszerzalnego języka zapytań dla XML

  • Brak języka zapytań umożliwiającego łatwe wyszukiwanie żądanych informacji w repozytoriach dokumentów.

Znane jest wiele języków zapytań do XML jednak ich podstawy teoretyczne oraz wygoda użytkowania pozostawiają wiele do życzenia. W przypadku repozytoriów języki zapytań języki wydają się być jedyną dziedziną pominięta przez autorów prac związanych z tą dziedziną.

Podstawową motywacją autorów było ukazanie siły podejścia stosowego dla języków zapytań poprzez implementację prototypowego języka zapytań dla XML. Autorzy często odczuwają potrzebę korzystania z niewielkich repozytoriów dokumentów, nie są jednak usatysfakcjonowani obecnie istniejącymi rozwiązaniami w zakresie wyszukiwania informacji w repozytoriach.

Celem pracy jest stworzenie generycznego narzędzia, które da podstawy dla dalszych prac nad tworzeniem systemów repozytoriów, wyszukiwarek, systemów zarządzania wersjami, itp. W tym celu autorzy zamierzają stworzyć język zapytań dla dokumentów XML, który zdecydowanie usprawni proces tworzenia takich systemów.

Proponowanym rozwiązaniem jest język zapytań dla XML zbudowany w oparciu o podejście stosowe dla języków zapytań opracowane przez Kazimierza Subietę ([3]).

W toku prac zastosowano następujące narzędzia:


  • Java – jako język programowania użyty do implementacji prototypu języka zapytań dla XML

  • Xerces – parser dokumentów XML, zgodny ze standardem DOM 2.0

  • JFlex – generator skanerów użyty przy konstrukcji parsera dla stworzonego języka zapytań.

  • CUP – generator parserów LALR(1) użyty przy konstrukcji parsera dla stworzonego języka zapytań.

Rezultatem pracy jest język zapytań stworzony w oparciu o podejście stosowe, umożliwiający wykonywanie zapytań na wielu dokumentach XML jednocześnie.

Udowodniono, że podejście stosowe dobrze nadaje się do języka zapytań dla dokumentów XML. Ponadto stworzono generyczne narzędzie umożliwiające tworzenie systemów, w których potrzebny jest język zapytań, a duży serwer bazodanowy jest z pewnych przyczyn nieodpowiedni.



Jako, że praca ta była tworzona w zespole dwuosobowym, konieczne był podział pracy między obu członków zespołu. Podział pracy był następujący:

  • Rafał Hryniów:

    • Implementacja zarządzania referencjami

    • Implementacja stosu środowisk i binderów

    • Implementacja operatorów nie-algebraicznych

    • Implementacja operacji shallow ($)

    • Stan sztuki, opis narzędzi i teorii – Java, oraz XML wraz z językami zapytań dla XML, podejście stosowe

  • Tomasz Pieciukiewicz:

    • Stworzenie parsera, łącznie z konstrukcją drzewa rozbioru zapytania

    • Implementacja linków.

    • Adaptacja drzewa DOM do potrzeb pracy

    • Implementacja operatorów algebraicznych

    • Implementacja operacji ellipse

    • Stan sztuki, opis narzędzi i teorii – repozytoria dokumentów, języki zapytań (bez języków zapytań dla XML), ewaluacja przydatności poszczególnych rozwiązań w zakresie języków zapytań do potrzeb niniejszej pracy, JFLex, CUP, DOM

Każdy z członków zespołu odpowiedzialny był za napisanie części pracy magisterskiej odpowiadającej jego zadaniom implementacyjnym. Pozostała część pracy została napisana wspólnie.

  1. Stan sztuki

Niniejszy rozdział stanowi próbę przedstawienia czytelnikowi istniejących rozwiązań w zakresie repozytoriów dokumentów, XML wraz z technologiami pochodnymi oraz języków zapytań, jak również wskazania najważniejszych według autorów braków w istniejących już rozwiązaniach. Autorzy zdają sobie sprawę, że opis ten nie może być kompletny, gdyż wszystkie trzy wspomniane dziedziny są bardzo rozbudowane, jak również szybko ewoluują i próba ich pełnego opisu skazana jest na niepowodzenie.

  1. Repozytoria

Repozytoria są szczególnym przypadkiem systemów gromadzenia danych. W przeciwieństwie do najpopularniejszych – systemów zarządzania bazami danych - repozytoria służą do przechowywania i wyszukiwania różnego rodzaju dokumentów elektronicznych (zamiast starannie obrobionych danych o określonej strukturze). Dokumenty przechowywane w repozytoriach mogą być różnego typu – od czystych dokumentów tekstowych, przez dokumenty w językach takich jak HTML lub XML, kody źródłowe programów, po pliki binarne takie jak zdjęcia lub programy wykonywalne. Repozytoria muszą dostarczać sposobów wyszukiwania tego typu danych, przechowywania informacji o ich wzajemnych powiązaniach, różnych wersjach tego samego dokumentu itd. Informacje zawarte w tej części pracy oparte są na standardzie opracowanym w Corporation for National Research Initiatives (CNRI), opisanym w [8], stosowanym z większymi lub mniejszymi zmianami w większości powstających obecnie cyfrowych bibliotek.

    1. Zastosowanie repozytoriów

Repozytoria stosowane są w kilku obszarach:

  • W bibliotekach cyfrowych takich jak na przykład CSTR (Computer Science Technical Reports) w celu przechowywania, wyszukiwania i udostępniania dokumentów znajdujących się w tych bibliotekach.

  • W systemach zarządzania wersjami lub konfiguracją (takich jak CVS, ClearCase lub internetowy SourceForge), w celu przechowywania wszystkich objętych kontrolą składników oprogramowania.

  • Wyszukiwarki internetowe, takie jak np. Altavista lub Google, również można uznać za swego rodzaju repozytoria (zwłaszcza, że przechowują one kopie znajdujących się w ich katalogach dokumentów).

    1. Informacje o dokumentach przechowywanych w repozytoriach

Zgodnie z [8], informacje o dokumentach przechowywanych w repozytoriach powinny zawierać następujące dane:

  • Związki z innymi dokumentami. Dokument może być częścią innego dokumentu (na przykład zdjęcie może być częścią artykułu prasowego). Dokument może też składać się z innych dokumentów (na przykład książka z rozdziałów), lub też należeć do jakiejś sekwencji (na przykład jeden z serii tygodniowych raportów z postępów prac). Repozytorium musi zapewniać możliwość przechowywania informacji o związkach każdego z dokumentów z innymi i naturze tych związków.

  • Format, w jakim przechowywany jest dany dokument. Ten sam dokument może być przechowywany w różnych formatach, czasem różniących się przenoszoną informacją (na przykład zdjęcie nie skompresowane i poddane kompresji stratnej), czasem zawierające tą samą informację i umożliwiające przeprowadzenie konwersji (na przykład zdjęcie nie skompresowane i poddane kompresji bezstratnej). Repozytorium powinno zapewniać możliwość przechowywania informacji o formatach, w jakich dostępny jest dany dokument i umożliwiać pobranie dokumentu w żądanym formacie (jeśli taki jest dostępny).

  • Wersja dokumentu. Dokumenty mogą być zmieniane – w każdej z wersji mogą różnić się pojedynczym bitem, lub całą zawartością. Repozytorium powinno umożliwiać przechowywanie dokumentów z rozróżnieniem wersji, w jakiej są przechowywane, oraz pobieranie żądanej wersji.

Ponadto w repozytoriach należałoby przechowywać następujące informacje, pozwalające na łatwe wyszukiwanie dokumentów:

  • Informacje identyfikujące autorów danego dokumentu, instytucje zaangażowane w jego powstanie, datę i miejsce publikacji, ewentualnie dane wydawcy itd.

  • Informacje mówiące o zawartości dokumentu, takie jak słowa kluczowe, nazwiska osób, nazwy miejsc itd., których dotyczy dokument, ewentualnie kategorie tematyczne.

  • Inne (zgodne z zapotrzebowaniem) dane dotyczące dokumentu.

    1. Podstawowe założenia repozytoriów

Podczas projektowania architektura informacji w repozytoriach należy brać pod uwagę następujące założenia ([8]):

  • Należy dać użytkownikowi jak największą elastyczność. Ponieważ użytkownicy przeszukują materiały na wiele różnych sposobów, organizacja informacji nie może być oparta na oczekiwaniach dotyczących podejścia użytkownika do materiałów, jego poziomu doświadczenia, lub kolejności dostępu do pozycji.

  • Kolekcje muszą być proste w zarządzaniu. W bibliotekach cyfrowych (jak we wszystkich bibliotekach), niewielki zespół specjalistów zarządza bardzo dużymi zbiorami. Architektura musi pozwalać temu zespołowi skupić się na istotnych zadaniach, uwalniając ich od rutynowych zajęć. (Dotyczy to też wykorzystania repozytoriów w zastosowaniach innych niż biblioteki cyfrowe, w celu redukcji kosztów administracyjnych).

  • Architektura musi odzwierciedlać ekonomiczne, społeczne i prawne ramy infrastruktury informatycznej. W szczególności należy pamiętać, iż informacja jest wartościowa, podlega rozmaitym uregulowaniom prawnym i jest transmitowana przez (zazwyczaj) niezabezpieczone sieci, przekraczające granice państwowe.

Ponadto, system powinien spełniać następujące warunki dotyczące sposobu przechowywania i opisywania dokumentów ([8]):

  • Wszystkie dane (dokumenty) mają przypisany typ danych
    Każdy dokument ma przypisany do niego typ danych. Typ określa, w jakim formacie jest dany dokument (na przykład format ASCII lub JPEG), w jaki sposób powinien być przetwarzany (na przykład, jeśli jest programem napisanym w C), lub jaką ma organizację (na przykład tekst opisany znacznikami SGML).

  • Metadane są kodowane explicite
    Używane metadane są kodowane explicite. Żadna informacja semantyczna zawarta np. w części nazwy nie może być pominięta w metadanych (w przeciwieństwie do np. systemów plików w systemach operacyjnych, gdzie informacja semantyczna jest często zawarta w nazwie pliku – np. „.txt” wskazuje na plik tekstowy).

  • Uchwyty są przypisane pojedynczym obiektom będącym własnością intelektualną
    Jeśli informacja może być użyta samodzielnie, przyznawany jej jest własny uchwyt i tworzony jest z niej osobny obiekt. Dzięki posiadaniu przez nią własnego uchwytu, można uzyskać do niej bezpośredni dostęp. Pozwala to na dużą elastyczność. (Przykładowo, tekst może zawierać ilustracje. Przy tym podejściu każda z ilustracji będzie osobnym obiektem z własnym uchwytem).

  • Metaobiekty są używane do agregowania obiektów
    W bibliotece elektronicznej pełne metadane dotyczące pojedynczej pozycji informacji, jak również jej kopie, mogą istnieć w wielu miejscach w repozytorium, jak również w zewnętrznych systemach. Dla każdego obiektu w związku z tym należy tworzyć metaobiekt, zawierający dane dotyczące obiektu oraz łącza do wszystkich wersji obiektu w repozytorium.

  • Uchwyty są używane do identyfikacji obiektów zawartych w metaobiektach
    Metaobiekt zawiera listę. Pozycje w liście identyfikowane są przy pomocy uchwytów.

Przykład użycia metaobiektu:
W repozytorium znajdują się 3 wersje tej samej fotografii: wersja o wysokiej, średniej i niskiej rozdzielczości. Każda z wersji jest opisana przy pomocy własnego zestawu metadanych. Uchwyty do wszystkich trzech wersji fotografii znajdują się w metaobiekcie. Metadane tego metaobiektu zawierają informacje wspólne dla wszystkich trzech wersji fotografii. Jeśli w jakimś innym dokumencie znajdzie się odniesienie do tego metaobiektu, użytkownik próbujący pobrać fotografię będzie miał wybór między wszystkimi dostępnymi wersjami.


    1. Uchwyty

Uchwyt jest unikalnym identyfikatorem obiektu, pozwalającym na jego identyfikację. Zasoby identyfikowane przez uchwyt mogą być zmieniane, przenoszone w inne miejsca, przechowywane w wielu miejscach repozytorium lub w inny sposób zmieniać się w czasie, lecz uchwyt do obiektu pozostanie niezmienny. System jest w stanie powiązać uchwyt z konkretnym zasobem – obiektem. Wszelkie powiązania między obiektami realizowane są właśnie przy pomocy uchwytów. Uchwyty zbudowane są z dwóch części – kodu instytucji nadającej nazwy (naming authority) i kodu zasobu. Przykładem uchwytu może być np. loc.pp/4a32371, gdzie loc.pp odnosi się do instytucji nadającej nazwy, zaś 4a32371 do konkretnego zasobu.

    1. Struktura Repozytorium

Repozytorium oparte na standardzie opracowanym w CRNI jest systemem wielowarstwowym. Do komunikacji między repozytoriami, oraz między repozytorium a aplikacją kliencką wykorzystywany jest protokół RAP (Repository Access Protocol) oparty na standardzie CORBA (protokół ten to po prostu definicja interfejsu CORBA, realizującego 9 podstawowych operacji na repozytorium).

Repozytorium składa się z trzech warstw:



  • Interfejs repozytorium (Repository shell) udostępniający interfejs do repozytorium. Implementuje protokół RAP, zapewnia konwersję między wewnętrzną i zewnętrzną reprezentacją obiektów oraz zarządza prawami i uprawnieniami.

  • Warstwa zarządzania obiektami (Object management Layer) zapewnia interfejs między usługami trwałego składu i usługami interfejsu repozytorium. Zapewnia mapowanie uchwytów na rzeczywiste obiekty.

  • Trwały skład (Persistent store) służy do przechowywania informacji zawartej w repozytorium. Implementacja trwałego składu jest ukryta przed światem zewnętrznym, dzięki czemu możliwe jest użycie we wdrażanym systemie dowolnego z dostępnych systemów trwałego składu.

Obiekty w składzie nie są przechowywane w postaci pojedynczego bloku danych. Każdy obiekt mapowany jest na pewną strukturę:

  • Element jest najbardziej podstawową ze struktur składu. Każdy element składa się z unikalnego (w ramach danego składu) identyfikatora, atrybutów opisujących dany element (takich jak typ lub rola) oraz bloku danych (dowolnej sekwencji bajtów).

  • Pakiet jest kolekcją elementów oraz innych pakietów, posiadającą własne ID.

  • Obiekt jest pakietem lub elementem uzupełnionym o opisujące go metadane, przeznaczonym do udostępnienia. ID obiektu to jego uchwyt.

Przykładowo, książka (obiekt w repozytorium) może składać się z rozdziałów (pakietów), zaś każdy z rozdziałów zawierać elementy w postaci tekstu rozdziału i odpowiednich ilustracji.(Uwaga – rozdziały, tekst i ilustracje, jeśli przypisane zostaną im odpowiednie metadane również bez przeszkód mogą zostać udostępnione jako obiekty).

    1. Repository Access Protocol

Repository Access Protocol używany jest we wszystkich interakcjach pomiędzy światem zewnętrznym a repozytorium. Systemy opisywane w [8] implementują następujące metody składające się na interfejs RAP:

  • VerifyHandle pozwala sprawdzić, czy uchwyt został zarejestrowany w systemie uchwytów,

  • AccessRepoMeta pozwala na dostęp do metadanych repozytorium,

  • Verify_DO pozwala sprawdzić, czy repozytorium przechowuje obiekt z danym uchwytem,

  • AccessMeta pozwala na dostęp do metadanych konkretnego obiektu,

  • Access_DO pozwala na dostęp do obiektu,

  • Deposit_DO pozwala na wprowadzenie obiektu do repozytorium,

  • Delete_DO pozwala na usunięcie obiektu z repozytorium,

  • MutateMeta pozwala na edycję metadanych obiektu,

  • Mutate_DO pozwala na edycję obiektu,

Te 9 operacji pozwala na wykonywanie podstawowych działań na repozytorium. Oprogramowanie klienckie opracowane w ramach programu początkowo wykorzystywało RAP, później jednak zdecydowano się na odejście od idei grubego klienta na rzecz dostępu do repozytorium przez WWW za pośrednictwem skryptów CGI, które z kolei kontaktowały się z repozytorium za pomocą RAP.

    1. Inne podejścia

Prezentowane podejście jest najbardziej zaawansowanym ze wszystkich znanych autorom rozwiązań. Najczęściej spotykane systemy - używane wyłącznie w rozwoju oprogramowania, takie jak CVS są bardzo ograniczone pod względem możliwości – małą elastyczność, jeśli chodzi o definiowanie metadanych, sposób przechowywania zasobów (zazwyczaj jedynie przy pomocy systemu plików) itd. Niestety, bardzo trudno jest uzyskać dane na temat struktury repozytoriów w systemach komercyjnych, jednak określanie przez producenta możliwości dowolnego nazywania wersji obiektu w repozytorium (nie zaś tylko przy pomocy numeru wersji) jako osiągnięcia (Visual SourceSafe ([9]) świadczy o tym, że pod względem elastyczności tych systemów jest niewiele lepiej, niż w przypadku systemów darmowych. Niektóre systemy komercyjne, takie jak np. Continuus oferują możliwość wykonywania zapytań (w tym tworzenia raportów) na metadanych, przechowywanych w relacyjnej bazie danych. Niestety, znaczny koszt komercyjnych systemów typu Configuration Management uniemożliwia autorom osobiste zapoznanie się z zastosowanymi w nich rozwiązaniami.

    1. Dostrzeżone braki

Prezentowane rozwiązanie wydaje się być dość rozsądne i atrakcyjne, należy jednak zwrócić uwagę na bardzo istotne niedomaganie. Rozbudowane metadane związane z obiektami i możliwość tworzenia powiązań (zarówno typu „część-całość” jak i „związany z”) między nimi są raczej obciążeniem dla poszukujących informacji, nie zaś ułatwieniem, w sytuacji, gdy brak efektywnego narzędzia służącego do nawigowania wśród danych – takiego jak język zapytań. Prezentowany standard nie zakłada niczego na temat takiego języka, w znanych autorom materiałach brak jakiejkolwiek wzmianki o konieczności jego istnienia. Niektóre systemy komercyjne używają języka zapytań (zazwyczaj SQL), jednak są one silnie ukierunkowane na jeden obszar zastosowań.

    1. Proponowane rozwiązanie


  1   2   3   4   5   6   7   8   9   ...   16


©operacji.org 2017
wyślij wiadomość

    Strona główna