Interpreter Języka Zapytań SBQL dla Office Object Portal

Transkrypt

1 POLSKO-JAPOŃSKA WYŻSZA SZKOŁA TECHNIK KOMPUTEROWYCH PRACA MAGISTERSKA Nr... Interpreter Języka Zapytań SBQL dla Office Object Portal Student/studentka Nr albumu Promotor Specjalność Katedra Data zatwierdzenia tematu Data zakończenia pracy Bogdan Bogucki, Marcin Michalak s1819, s1744 Prof. dr hab.kazimierz Subieta Inżynieria Oprogramowania i Baz Danych Systemów Informacyjnych Podpis promotora pracy Podpis kierownika katedry......

2 Streszczenie Praca przedstawia zaimplementowany przez autorów język zapytań SBQL, oparty o podejście stosowe, dla Office Object Portal, które jest repozytorium dla systemu Inteligentnego Zarządzania Wiedzą tworzonego w ramach piątego ramowego (ICONS). We wstępie jest przedstawiony cel pracy oraz jej podział pomiędzy autorów. W rozdziale dotyczącym stanu sztuki zostają przedstawione najważniejsze standardy oraz rozwiązania dostępne na rynku języków zapytań. Zostają przedstawione ich cechy oraz braki oraz zostaje przedstawiony oraz uzasadniony wybór rozwiązania jaki podjęli autorzy. W rozdziale dotyczących rozwiązań architektonicznych zostaje przedstawiona budowa oraz model danych Office Object Portal repozytorium dla którego autorzy tworzą język zapytań. W rozdziale dotyczącym języka SBQL zostaje on dokładnie przedstawiony. Opisana zostaje zasada działania. Przedstawiona jest też dokładnie specyfikacja języka jaki został zaimplementowany dla Office Object Portal. Rozdział poświecony interfejsowi graficznemu pokrótce go przedstawia oraz charakteryzuje. W rozdziale dotyczącym narzędzi zostają przedstawione narzędzia jakie zostały wybrane do implementacji oraz uzasadniony zostaje ich wybór. Kolejny rozdział przedstawia rozwiązania implementacyjne jakie zostały wybrane do realizacji pracy. W ostatnim rozdziale zostaje podsumowany rezultat pracy autorów oraz możliwości dalszej rozbudowy stworzonego języka zapytań.

3 Spis treści 1 Wstęp Stan Sztuki ICONS OfficeObjects Portal Języki zapytań Czym są języki zapytań? SQL Obiektowe języki zapytań OQL SBQL Wybór rozwiązania Założenia architektoniczne Model danych ooportal Język SBQL dla ooportal oparty o podejście stosowe (SBA) Podejście stosowe (SBA) Stos środowisk (ENVS) Rezultaty zwracane przez zapytania Stos rezultatów (QRES) Specyfikacja Gramatyki SBQL dla ooportal Proces ewaluacji zapytań Ewalujaca elementarnych zapytań Wywoływanie operatorów algebraicznych Wywoływanie operatorów nie-alegbraicznych Specyfikacja oraz opis działania operatorów zaimplementowanych w SBQL dla ooportal Operatory algebraiczn Operatory agregujące Operatory arytmetyczne Operatory porównania Operatory logiczne Operatory kolekcji Operatory matematyczne Operatory definiowania pomocniczej nazwy Operatory porządku Operatory języków narodowych Inne Operatory Operatory nie algebraiczne Interfejs programistyczny dla SBQL Rezultaty zwracane przez zapytania Interferes...72

4 5 Interfejs graficzny Narzędzia wykorzystane do realizacji pracy Język Java Charakterystyka Javy Różnice między Javą a C Generator skanerów leksykalnych Jflex Generator parserów LALR CUP SKN Wrapper Rozwiązania implementacyjne Konstrukcja skanera leksyklanego Konstrukcja parsera LALR Zakończenie Literatura...88 Dodatki...88 Dodatek A: Słownik użytej terminologii i skrótów...88

5 1.Wstęp Magistranci podjęli się implementacji prototypu języka zapytań opartego o podejście stosowe dla repozytorium Office Object Portal, które jest częścią europejskiego projektu ICONS. Repozytorium ooportal nie posiadało narzędzia które w sprawny oraz łatwy sposób było by w stanie odpytywać repozytorium, język taki powinien mieć podstawowe cechy: Mieć mocne podstawy teoretyczne Być łatwo rozszerzalny Przystosowany do modelu obiektowego Istnieje wiele języków zapytań, jednak wśród znanych magistrantom języków zapytań niewiele z nich spełnia dwie wyżej wymienione cechy. Prototyp języka dla repozytorium ooportal oparty o podejście stosowe doskonale pokazuje, że język mający mocne podstawy teoretyczne doskonale się sprawdza w przypadku dużych systemów. Pokazuje też że język jest: w pełni implementowalny, jest prosty w implementacji, łatwo rozszerzalny, prosty w użytkowaniu. Proponowane rozwiązanie oparte o podejście stosowe dla języków zapytań opracowane zostało przez Kazimierza Subiete oraz dokładnie opisane w książce Teoria i konstrukcja obiektowych języków zapytań [Subieta 2004]. Przy pracy nad prototypem języka zastosowano następujące narzędzia: Java język programowania użyty do implementacji prototypu języka zapytań dla repozytorium ooportal. JFlex generator analizatorów leksykalnych użyty przy konstrukcji parsera dla języka zapytań. CUP generator parserów LALR(1) użyty przy konstrukcji parsera dla języka zapytań. Rezultatem pracy jest prototyp języka zapytań oparty o podejście stosowe, umożliwiający zadawanie zapytań do repozytorium Office Object Portal. W oparciu o prototyp systemu inteligentnego zarządzania wiedzą, zbudowanego w ramach projektu ICONS opartego na repozytorium ooportal, został stworzony system zarządzania funduszami strukturalnymi do tego systemu magistranci stworzyli Interfejs graficzny pozwalający zadawać zapytania z poziomu strony WWW. Stworzony został także moduł pozwalający na użycie SBQL dla ooportal przez Structural Knowledge Graph Manager (SKGM). SKGM jest modułem pozwalającym przeglądanie zawartości repozytorium w sposób graficzny, nawigując po grafie.

6 Praca była tworzona w zespole dwuosobowym, więc konieczne było podzielenie pracy między członków zespołu. Podział pracy wyglądał następująco: Bogdan Bogucki: Implementacja skanera leksykalnego Implementacja operatorów Implementacja Graficznego Interfejsu z poziomu strony WWW Stworzenie dokumentacji na potrzeby projekty ICONS Marcin Michalak: Implementacja parsera Implementacja stosu środowiskowego Implementacja zarządzania referencjami Implementacja operatorów Implementacja API dla Javy oraz modułu dla SGKM Każdy z członków zespołu napisał swoją część pracy magisterskiej, która odpowiadała zakresowi pracy jaki wykonał w trakcie implementacji prototypu.

7 2.Stan Sztuki Rozdział ten ma na celu przybliżenie czytelnikowi projekt ICONS oraz systemu OfficeObjects Portal, rdzenia projektu ICONS) jak i przedstawienie istniejących rozwiązań w zakresie języków zapytań. Zostanie tutaj przedstawiona oraz scharakteryzowana tylko część najbardziej popularnych rozwiązań dotyczących języków zapytań ponieważ obszar związanych z językami zapytań jest tak olbrzymi, że stworzenie pełnego ich przeglądu jest niemożliwe. 2.1ICONS Celem projektu ICONS jest połączenie jednolitą całość rezultatów badań, technologii, standardów oraz istniejących narzędzi. Opracowana architektura ma posłużyć do budowy systemów zarządzania wiedzą oraz zawartością multimedialną. Integracja takich dziedzin jak sztuczna inteligencja, bazy danych połączone z zaawansowanymi cechami nowych architektur informatycznych da nowatorską architekturę Systemu Inteligentnego Zarządzania Zawartością (Intilligent CONtent Managment System ICONS). Badania w zakresie reprezentacji wiedzy są pokrywane przez takie paradygmaty jak logika (disjunctive Datalog), sieci semantyczne oparte o takie standardy jak UML, RDF oraz wiedzę proceduralną o procesach działalności opartą o grafy skierowane zgodnie z zaleceniami koalicji (WfMC). Wypracowane metody będą stanowiły bazę dla budowy Systemu Inteligentnego Zarządzania Zawartością (ICONS) w oparciu o wybraną platformę zarządzania zawartością. Prototyp ICONS ma zarządzać opartym na XML, multimedialnym repozytorium zawartości, przechowywać złożone obiekty informacyjne i reprezentacje (proxy) zewnętrznych informacji znajdujących się w heterogenicznych bazach, danych generowanych na wyjściach innych systemów przetwarzających, stronach Web oraz odpowiednich ontologii dziedzinowych. Portal Zarządzania Wiedzą o Projektach Funduszy Strukturalnych będzie dostępny poprzez Internet i będzie najlepszą demonstracją wyników projektu ICONS. [Ricons] 2.2OfficeObjects Portal OfficeObjects Portal (ooportal) jest portalem korporacyjnym mającym na celu zapewnienie dostępu do różnych rodzajów wiedzy gromadzonej w firmie. Ma to na celu pomoc pracownikom, zarządowi oraz partnerom handlowym czy klientom w kontrolowanym dostępie do korzystania z zasobów wiedzy firmy. Cechy ooportalu to: dostęp za pośrednictwem zwykłej przeglądarki internetowej pełne zintegrowanie wszystkich działających w firmie systemów informatycznych i powiązanie ze sobą rozdzielonych dotychczas zasobów danych za pośrednictwem Internetu pobieranie aktualnych danych z zewnętrznych źródeł, jak np. notowania giełdowe czy informacje z agencji prasowych i ich integrowanie z zasobami wiedzy firmy zarządzanie obiegiem dokumentów i wewnętrzną komunikacją w firmie (dzięki pośrednictwu wewnętrznej sieci intranetu) porządkowanie i kategoryzacja danych wg ustalonych i precyzyjnych kryteriów wymiana na bieżąco aktualizowanych informacji ze światem (z klientem, partnerem handlowym, mediami) nawiązywanie nowych kontaktów handlowych (z możliwością udzielenia natychmiastowej odpowiedzi)

8 dokonywanie za pośrednictwem Internetu transakcji handlowych (zamówienia on line) zapewnienie dobrego wizerunku firmy na zewnątrz oraz wśród pracowników (działania z zakresu Public Relations) dynamiczne wsparcie wszystkich działań promocyjnych i marketingowych firmy system informatyczny, zbierający całą firmową wiedzę do tej pory funkcjonował tylko i wyłącznie w jej wnętrzu (np. systemy klasy ERP). ooportal przy każdym wdrożeniu jest dostosowywany do potrzeb oraz specyfikacji danej firmy. [RooPortal] 2.3 Języki zapytań Każdy system którego przeznaczaniem jest zbieranie oraz przetwarzanie danych musi posiadać narzędzie które pozwoli odzyskiwać zgromadzone dane. Systemy Zarządzania Bazami Danych (SZBD) gromadzą duże ilości danych więc narzędzia wydobywające z nich dane muszą być odpowiednio rozbudowane oraz powinny spełniać określone wymagania. Za pomocą takich narzędzi powinny być możliwe wyszukiwanie danych spełniających określone warunki, agregowanie danych oraz inne dostosowane do odpowiednich wymagań operacje. Systemy te są generyczne więc potrzebują uniwersalnych narzędzi, takimi narzędziami są języki zapytań Czym są języki zapytań? Języki zapytań (query langages) są interfejsami najczęściej programistycznymi, które pozwalają przeszukiwać bazę danych według zadanych kryteriów. Trudno jest jednoznacznie określić czym są lub czym powinny być języki zapytań. W tej sprawnie zdania są podzielone, możemy sie spotkać z takimi definicjami języków zapytań: Prosty interfejs dla użytkownika. Takie podejście przedstawiają takie języki zapytań jak SQL, OQL, języki oparte o formularze Query by Example czy inne graficzne języki zapytań. Gdy byl tworzony SQL twórcy tego języka mieli nadzieje, że będzie on przeznaczony dla użytkownika nie znającego sie na programowaniu, lecz okazało się, że nawet taki język jest zbyt skomplikowany dla tego typu użytkownika. Dlatego obecnie języki zapytań oparte graficzne o formę graficzną są przeznaczone dla powszechnego użytkownika, a języki typu SQL dla programistów. Języki oparte o matematyczne teorie. Języki te oparte są o teorie matematyczne np. logikę matematyczną. Jednak tego typu podejście nie jest już lansowane. Języki takie nie sprawdziły sie w dziedzinie baz danych. Języki zapytań zanurzane w języki programowania. Takie podejście jest bardzo często stosowane np. ExecSQL (SQL zanurzony w język C). Podejście to jednak niesie ze sobą wiele problemów jak niezgodności impedancji. Języki te są na różnych poziomach abstrakcji co prowadzi do niezgodności miedzy innymi takich rzeczy jak: składni, systemu typów, semantyki. Konstrukcje wysokiego poziomu zintegrowane z językiem programowania. W języku tego typu oprócz zdań języka zapytań występują instrukcje imperatywne (programistyczne) co tworzy z tego języka pełny interfejs do programowania aplikacji. Przykładem takiego języka jest PL/SQL systemu Oracle czy SBQL systemu Loqis. Język zapytań dla Office Object Portal jest skierowany do programistów, dlatego magistranci wybrali ostatnie z wymienionych rozwiązań. Jest ono najbardziej dojrzałe oraz pozwala

9 efektywnie tworzyć aplikacje. Implementacja dla potrzeb ooportal zawiera jedynie zdania języka zapytań ale język ten może być bez problemu rozbudowany o instrukcje imperatywne SQL Uważa się ogólnie, że języki zapytań powinny mieć następującej własności: Wysoki poziom abstrakcji. Użytkownik tworzący zapytanie powinien móc posługiwać sie tylko logicznym schematem danych. Danie powinny być niezależne od ich organizacji fizycznej. Deklamacyjność. Oznacza skupienie się na tym co wyszukujemy a nie jak. Makroskopowość. Działanie na kolekcjach danych nieograniczonych i nieznanych rozmiarach. Naturalność. Wspomaganie naturalnych schematów myślenia użytkownika. Efektywność. Akceptowalne czasy wykonywania zapytań. Sprowadza się to do możliwości użycia automatycznych optymalizacji zapytań. Optymalizacja taka ma na celu zmniejszenie nieakceptowalnego czasu (np. 100 lat) do akceptowalnego (np. kilka sekund). Uniwersalność. Zdolność języka do dowolnych operacji wyszukiwania danych. Niezależność od dziedziny zastosowań. Wykonywanie zapytań w trybie interpretacyjnym. Późne dynamiczne wiązanie, brak kompilacji oraz konsolidacji z aplikacją. Język dla ooportal musi spełniać wszystkie te własności. Funkcjonowanie współczesnych systemów relacyjnych baz danych oparte jest głównie na języku SQL (Structured Query Language, strukturalny język zapytań). Wszystkie Relacyjne SZBD korzystają z jakiejś modyfikacji języka SQL. W roku 1970 E.F. Codd, naukowiec pracujący w firmie IBM publikuje prace zatytułowaną "A Relational Model of Data for Large Shared Data Banks" Codd proponuje wykorzystanie relacyjnej algebry jako podstawy do tworzenia oprogramowania bazodanowego. Propozycja Codda zostaje szybko zauważona przez jego firmę, której dział R&D w roku 1976 tworzy relacyjną bazę danych nazwaną SYSTEM/R oraz nowy język relacyjny nazwany Strukturalnym Językiem Zapytań. Istnieje wiele standardów tego języka: SQL-86, SQL-89, SQL-92, SQL3 nad którym prac zaprzestano na rzecz obecnie tworzonego standardu SQL1999. Mimo, że istnieje tyle standardów trudno znaleźć SZBD który jest zgodny w 100% z jednym z wyżej wymienionych standardów. Większość producentów, zwłaszcza czołowych, wprowadza wiele własnych elementów do języka, co prowadzi do niekompatybilności kodu programu na różnych SZBD oraz osłabieniu standardu. Najczęściej stosuje się dwa sposoby użycia SQL: Dynamiczne lub statyczne wywołania za pomocą odpowiednich API (ODBC, JDBC) SQL zanurzony w rożne języki niższego poziomu C/C++, Java. Zanurzenie SQL w język niższego poziomu może odbywać sie na kilka sposobów. Jest to realizowane za pomocą API producenta danego SZBD. Sposoby wyżej wymienione napotykają na problem zwany niezgodnością

10 impedancji. Problem ten wynika z różnych koncepcji pomiędzy językami stosowanymi do budowy aplikacji a SQL. Problemy te są możliwe poprzez zastosowanie zbudowanie języka opartego na języku zapytań a jednocześnie zdolnego do budowy aplikacji. Przykładem takiego języka jest PL/SQL firmy Orcale. Jednak i w tym języku występuje niezgodności impedancji jest to spowodowane złym podejściem do budowy tego typu języków. PL/SQL jednak potrafi budować aplikacje tylko w oparciu o strony WWW ponieważ jego kod jest wykonywany po stronie serwera. Słabą stroną SQL jest brak ortogonalności operatorów. Ortogonalnością nazywamy taką własność języka gdy każda kombinacja cech języka, która ma sens jest dozwolona. Brak ortogonalności skutkuje strasznie dużą specyfikacją języka oraz trudna,wręcz niemożliwą implementacją standardu. Specyfikacja standardu SQL1999 sięga 1000 stron i jak dotąd nie została w pełni zaimplementowana w żadnym SZBD. Język SQL posiada także kilka anomalii, czyli specyficznego oraz nieregularnego traktowania niektórych cech języka. Przykładem może tu być obsługa typu NULL, Która jest w zależności od sytuacji różnie traktowana. Charakterystyka SQL: Oparty o model relacyjny, Pozwala na przetwarzanie wielozbiorów oraz zbiorów krotek, Duża specyfikacja standardu, Nie jest w pełni implementowany, Brak ortogonalności operatorów, Złe przystosowanie do obsługi wyrażeń scieżkowych, Możliwość używania SQL z poziomu innych języków, lecz wtedy powstaje problem niezgodności impedancji, SQL jest najpopularniejszym językiem zapytań Obiektowe języki zapytań Repozytorium Office Object Portal jest oparte o model obiektowy. Z tego powodu język zapytań dla ooportal powinien obsługiwać taki model danych. Systemy relacyjne w dziedzinie języków zapytań zostały całkowicie zdominowane przez język SQL, natomiast obiektowe SZBD nie doczekały ogólnie przyjętego standardu, który był by implementowany w większości obiektowych SZBD. Istnieje standard ODMG, który zawiera specyfikacje języka OQL (Object Query Language) lecz standard ten nie został powszechnie przyjęty przez producentów obiektowych SZBD. Większość producentów obiektowych SZBD raczej skupia się na zapewnieniu trwałości obiektów niż na języku zapytań, często też implementują rozbudowana wersje SQL OQL Głównym powodem małej popularności obiektowych SZBD był brak standardu. Relacyjne SZBD swój sukces zawdzięczają głównie przez przyjęcia SQL za standard. Postanowiono więc u standaryzować także obiektowe bazy danych co miało na celu pisanie kompatybilnego kodu na różne obiektowe bazy danych. Inicjatorem pomysłu standaryzacji był Rick Cattel. Można wymienić w punktach następujące osiągnięcia organizacji ODMG:

11 Została powołana grupa pracy nad standardem nazwana ODMG (Object Database Management Group). Pierwszy zarys standardu został opublikowany w roku Został nazwany ODMG 93 (1.0). W roku 1993 nastąpiło stowarzyszenie z OMG (Object Management Group). W roku 1996 został opublikowany standard ODMG wersja 1.2. ODMG 2.0 został opublikowany w roku ODMG 3.0 został opublikowany w roku Architektura przedstawiona przez standard ODMG wygląda następująco: Model obiektowy. Jako model obiektowy zaproponowany został model przedstawiony przez OMG. Język specyfikacji obiektu ODL. Jako podstawa do budowy tego języka ODL został wybrany IDL (Interface Definition Language) znany z CORBA. Obiektowy język zapytań OQL. Język zapytań jest językiem deklaratywnym. Oparty on został o SQL. Wiązanie do języków programowania C++, Smalltalk, Java. Standard umożliwia wiązania OQL do języków programowania i zanurzania zapytań w kodzie języka programowania. Grupa ODMG przyniosła standard obiektowych baz danych, jednak i on nie został zaakceptowany przez przemysł obiektowych SZBD. Powodów tej sytuacji jest kilka: Standard ten ma wiele braków. (np. mętny oraz niespójny system metadanych zapożyczony z repozytorium metadanych standardu OMG dotyczącego CORBY). Część standardu nie jest w pełni implementowalna (np. OQL). Konsorcjum ODMG jest duże, duże komitety charakteryzuje powolny system działania oraz wprowadzania zmian. Standard jest dość duży i trudno implementowalny, wielu producentów obiektowych baz danych wolało wprowadzać własne rozwiązania najczęściej hybrydowe obiektoworelacyjne, jako język zapytań stosując rozbudowana wersję SQL. Miało to także charakter marketingowy. O ile język definicji obiektów (ODL) wzorowany na IDL z CORB-y jest spójny łatwy w użyciu i kompletny, to OQL wzorowany na SQL jest językiem niekompletnym trudnym w użyciu posiadającym cech oraz rozwiązań. Charakterystyka OQL:[WykODMG04] Przypomina SQL. Podobieństwo jednak dotyczy tylko lukru syntaktycznego, czyli słów kluczowych.(np. Select, Where itp). Przewiduje konstrukcje wysokiego poziomu do obsługi zbiorów obiektów. Zapewnia ortogonalne kombinowanie operatorów o ile pozwala na to mocna kontrola typów.

12 Pozwala na zanurzanie zapytań OQL w językach programowania dla których ODMG zdefiniowało wiązania. Nadal jednak istnieje tutaj niezgodność impedancji. Nie posiada operacji aktualizujących. Aktualizacje na bazie danych można wywołać tylko z poziomu języka programowania do którego zostało zdefiniowane wiązanie przez ODMG. Jest językiem deklaracyjnym SBQL Historia podejścia stosowego (SBA Stack Based Aproach) zaczyna się w latach kiedy Kazimierz Subieta twórca tej teorii zaimplementował system Linda. System ten posiadał jedynie zarys podejścia stosowego. Przez kolejne lata podejście to było rozwijane oraz implementowane w różnych systemach. Kolejne etapy rozwoju tej teorii były następujące [Subieta 2004]: Praca habilitacyjna autora podejścia stosowego z roku 1985 była pierwszym dokumentem opisującym istotę teorii. [Subieta 1985]. W 1989 roku w firmie Intra-Video z Berlina Zachodniego powstaje pierwsza implementacja zwierająca już sprecyzowane zasady SBA. System o nazwie Netul był produktem przemysłowym i został użyty do budowy systemów eksperckich. W Instytucie Podstaw Informatyki w 1990 roku powstaje prototyp obiektowej bazy danych Loqis zawierający praktycznie większość cech SBA jakie posiada ono obecnie. W 1996 roku teoria zostaje rozwinięta o techniki optymalizacyjne. W kolejnych latach powstają kolejne implementacje SBA między inymi język zapytań dla XML [PieHryXML], czy całkiem nowy SZBD o nazwie YAOD obecnie nazwa zmieniła się na ODRA. Obecnie trwają dalsze prace nad rozwijaniem SBA m.in. W kierunku modelu obiektowego z rolami, aktualizowanych obiektowych perspektyw, meta-modelu, przetwarzaniu zapytań w środowiskach rozproszonych i innych. Oprócz wymienionych wcześniej właściwości jakie powinien posiadać język zapytań SBQL posiada inne nie spotykane dotąd w tej dziedzinie. Właściwości te stawiają go wśród języków zapytań, zdaniem autorów pracy, na pierwszym miejscu. Są to [Subieta 2004]: Koncepcyjna prostota, czysta i precyzyjna semantyka języka zapytań. Minimalizacja zestawu pojęć niezbędnych do opisu semantyki. Uniwersalność podejścia i tworzonych na jego podstawie języków. Kompozycyjność i ortogonalność; minimalizacja konstrukcji gramatyczno - semantycznych tworzonych języków. Jednorodne podejście do wszystkich pojęć modelu obiektowego (złożone obiekty, tożsamość, klasy, dziedziczenie, hermetyzacja, role, itd.). Jednorodne podejście do konstrukcji programistycznych bazujących na języku zapytań (perspektywy, procedury, metody, parametry procedur i metod, itd.). Modularność definicji języka (możliwość dowolnej hermetyzacji jego konstrukcji).

13 Wysoki potencjał dla optymalizacji zapytań. Bardzo łatwo rozszerzalny o nowe komponenty zależne od dziedziny w jakiej ma być używany. Język SBQL nie opiera sie na SQL nie ma z nim związków nie powiela więc błędów oraz problemów jakie spotykamy przy SQL. Rozbudowany SBQL jest językiem 4 generacji ideą przypomina PL/SQL język programowania zintegrowany z językiem zapytań. SBQL jednak dzięki traktowaniu wyrażeń języka programowania jako zapytań rozwiązuje problem niezgodności impedancji. Istnieją SZBD oparte o SBQL takie jak Loqis czy ODRA udowadniają że jest on możliwy do implementacji Wybór rozwiązania Magistranci wybrali język SBQL ponieważ jest to język przystosowany do systemów obiektowych a repozytorium Office Object Portal jest oparte o model obiektowy. Język ten jest możliwy do zaimplementowania, a jego implementacja jest prosta. Łatwo jest go dostosować do potrzeb oraz rozbudować do języka programowania. Język ten także łatwo sie rozbudowuje, a SBQL dla ooportal będzie w przyszłości rozbudowywane o takie elementy jak optymalizacja kontrola typów czy równania stało punktowe. 3.Założenia architektoniczne Zawartość repozytorium prototypu ICONS jest oparte o inny model danych niż systemy relacyjne więc użycie języka SQL jako języka do wydobywania danych jest niemożliwe. Coraz częściej spotyka się z opinają, że czas relacyjnych systemów już się powoli kończy, szczególnie w przypadku systemów o złożonym modelu danych. Język zapytań, czyli interfejs programowania dla bazy danych, skierowany jest bardziej do programistów niż do użytkowników końcowych systemu. Język zapytań dla repozytorium ICONS powinien spełniać następujące kryteria: Uniwersalność, zdolność do definiowania dowolnych operacji wyszukiwania. Obsługa uniwersalnych oraz złożonych modeli danych. Wypełni implementowany. Prosty oraz przyjazny dla użytkowników. Posiadający precyzyjnie zdefiniowana semantykę. Mający możliwość automatycznej optymalizacji. Możliwość integracji języka z instrukcji imperatywnymi. Możliwość obsługi klas, metod, widoków, trigerów. Jedynym językiem spełniającym wszystkie te założenia jest język SBQL oparty o podejście stosowe (SBA). Inne języki jak SQL(wykorzystywany w systemach relacyjnych), OQL(stosowany systemach obiektowych) czy XQuery(język zapytań dla XML'a) nie spełniały tych wszystkich założeń. SBQL przykrywa wszystkie cechy jakie posiada repozytorium ICONS co więcej pozwala na obsługę o wiele większych i bardziej złożonych modeli danych zawierających takie cech jak (hermetyzacje klas, dziedziczenie oraz polimorfizm, metody, dynamiczne role, aktualizowane perspektywy). SBQL jest oparty o abstrakcyjna składnie i nie jest stworzony dla konkretnego modelu składu. Język ten da się dostosować do konkretnego modelu składu oraz konkretnej składni wedle potrzeb danego

14 systemu. SBQL posiada wszystkie klasyczne operatory posiada także bardzo potężny system nawigacji po danych dzięki wyrażeniom ścieżkowym. Obecnie istnieją implementacje prototypów SBQL dla klasycznego obiektowego modelu danych (LOQIS), dla modelu danych XML (model składu oparty na DOM) oraz dla rozszerzonego modelu obiektowego zawierającego statyczne oraz dynamiczne dziedziczenie (dynamiczne role). W naszym podejściu język zapytań jest zbiorem klas Javy wraz z odpowiednimi interfejsami które pozwalają z poziomu języka Java zadać zapytanie wykonać je oraz wynik zapytania zwrócić jako obiekty Javy, gdzie mogą być przetwarzane za pomocą standardowych cech Javy. Językiem implementacji SBQL jest Java gdyż zapewnia ona najłatwiejszą integracje języka zapytań z repozytorium ICONS, które w dużej części jest także zaimplementowane w Javie. Poniżej znajduje się ogólna architektura implementacji SBQL dla repozytorium ICONS. JAVA Application QRES SBQL JAVA API ENVS Metabase SBQL Module SKN Wrapper Repozytorium ICONS Interfejs SBQL dla JAVY: jeden z interfejsów pozwalających z poziomu programu javy wykonać zapytanie SBQL oraz zwróci wynik zapytania w postaci obiektów javy, gdzie dalej za pomocą programu w javie będą dalej przetwarzane. Moduł SBQL: parser oraz interpreter języka SBQL przetwarzający zapytania. SKN Wrapper: interfejs zapewniający dostarczanie danych oraz meta danych z repozytorium. Meta dane: struktura zawierająca obecny schemat repozytorium razem z informacjami pozwalającymi na kontrole typów oraz optymalizacje zapytań. Stos Środowiskowy: struktura z której korzysta SBQL trzymając tam tymczasowy stan języka zapytań podczas przetwarzana zapytania, odpowiada za wiązanie nazw, przekazywanie parametrów, kontrolowanie zakresów itp. Stos ten występuje pod dwoma postaciami statyczny stos środowiskowy wykorzystywany w pierwszej fazie kiedy następuje optymalizacja zapytania, oraz stos środowiskowy czasu wykonania wykorzystywany podczas ewaluacji zapytania. Stos rezultatów: struktura danych trzymająca pośrednie oraz końcowe wyniki zapytania. Stos rezultatów także występuje w dwóch postaciach. Statyczny stos rezultatów wykorzystywany w pierwszej fazie kiedy następuje optymalizacja zapytania, oraz stos rezultatów czasu wykonania wykorzystywany podczas ewaluacji zapytania.

15 3.1Model danych ooportal. Model danych ooportal, na którym pracuje SBQL przypomina prosty system obiektowy. Język operuje na obiektach, które są wystąpieniem klasy. Klasy mogą być połączone ze sobą asocjacjami binarnymi. Każda asocjacja ma nazwę (role) oraz druga bliźniaczą asocjacje. Wystąpieniem asocjacji jest link. Linki są połączeniami między obiektami. Każdy obiekt posiada unikalny identyfikator oraz nazwę. Obiekt zawiera atrybuty, które są wartościami atomowymi, obiekty złożone jako atrybuty nie obsługiwane przez ooportal. W ooportal jest kilka rodzajów atrybutów. Atrybut może należeć do jednego z rodzajów lub być ich kombinacją. Oto rodzaje atrybutów jakie są stosowane w modelu danych ooportal. Atrybut wymagany atrybut który musi zawierać wartość w konkretnym wystąpieniu obiektu. Np.: atrybut Nazwisko czy PESEL które powinny być obowiązkowe dla każdego obiektu klasy Pracownik. Atrybut opcjonalny - taki który w konkretnym wystąpieniu obiektu może posiadać wartości lub nie. Np.: atrybut Nazwisko Panieńskie, atrybut taki nie wszyscy pracownicy będą wstanie posiadać. Atrybut powtarzalny, który to przechowuje pewien zestaw wartości o nieokreślonej i zmiennej w czasie liczbie elementów. Np.: atrybut specjalność, niektórzy pracownicy maja więcej specjalności inni mniej poza tym wraz z ukończonymi kursami danego pracownika atrybut ten może zwiększać liczbę elementów. Atrybut słownikowy, którego zbiór wartości jakie może przyjąć określa zdefiniowany w bazie danych słownik. Atrybut słownikowy jest powiązany z danym słownikiem. np.: atrybut dzień typu String powiązany ze słownikiem Dni Tygodnia który to zawiera wartości { Poniedziałek, Wtorek, Środa, Czwartek, Piątek, Sobota, Niedziela }, który przyjmuje jako wartość dni tygodnia zdefiniowane w słowniku. Każdy atrybut poza swoim rodzajem lub ich kombinacją posiada także typ ooportal udostępnia następujące typy proste dla atrybutów: Number (Integer), liczba całkowita Float, liczba rzeczywista String, łańcuch znaków Date, data Boolean, wartość logiczna

16 Przykładowy diagram klas w modelu ooportal. Employee! String Name! String - Surname? String - Maiden Name! Number - Salary! Date Born Date!$* String - Specjality PracujeW Zatrudnia Kieruje Szef Department! String - Name!* String Location Dictionary Specjality { Programmer, Asistant, Designer,, Administrator } Legenda:! - atrybut wymagany? - atrybut opcjonalny $ - atrybut słownikowy * - atrybut powtarzalny Warto w tym momencie zauważyć, że język SBQL został stworzony i jest zdolny obsługiwać o wiele bardziej skomplikowane struktury danych, które uwzględniają takie aspekty jak: Zagnieżdżone obiekty posiadające nie tylko atrybuty atomowe ale także złożone oraz struktury typu XML, istnieje implementacja języka zapytań dla XML oparta o podejście stosowe. Hermetyzacja, hierarchia klas oraz dziedziczenie. Metody oraz procedury. Dynamiczne role. Oraz porusza i rozwiązuje zagadnienia z jakimi borykają się komercyjne systemy baz danych (relacyjne jak i obiektowe) od lat, związane miedzy innymi z: Aktualizowanymi perspektywami Instrukcjami Imperatywnymi Kontrolą typologiczną. Traktowaniem języka zapytań jako pełnego języka programowania. Praktycznie każdy z wyżej wymienionych aspektów posiada działającą implementacje potwierdzająca możliwości języka SBQL oraz łatwość implementacji. Model jaki oferuje ooportal pokazuje jedynie mały procent mocy oraz możliwości jakie drzemie w języku SBQL. 4. Język SBQL dla ooportal oparty o podejście stosowe (SBA) Język SBQL dla ooportal jest oparty o podejście stosowe. Konstrukcje semantyki języka opierać będziemy na pojęciach nazywania, zakresu oraz wiązania, które to występują praktycznie w każdym języku programowania. Operacje te są wykonywane na stosie środowiskowym Stąd nazwa podejście stosowe. Język SBQL dla ooportal zakłada tylko instrukcje wyszukiwana danych, tzn. nie zmienia stanu repozytorium ICONS.