KONTROLA TYPÓW

Model semistrukturalny jako model „samoopisujący” się:

· Brak schematu opisującego strukturę danych ( w przeciwieństwie do modelu relacyjnego i obiektowego)

· Pomijanie istniejącego schematu

· Brak podanej struktury w jawny sposób (obejmuje część danych, może ulegać niekontrolowanym zmianom, jest zbyt złożona do opisania przez tradycyjny model bazodanowy)

Zalety określonych struktur danych:

· Wydajne przetwarzanie danych (optymalizacja obliczenia zapytania)

· Ekonomiczne wykorzystanie powierzchni dyskowych (optymalizacja przetrzymywania)

· Łatwiejsza orientacja i kontrola przez użytkownika

· Integracja różnych źródeł danych (znamy struktury dwóch źródeł – tworzymy strukturę dla danych zintegrowanych i określamy sposób konwersji)

· Tworzenie indeksów ( często powiązane z konkretną strukturą, np. klasa „company” i atrybut „name” – indeks)

Pomysł, żeby budować strukturę dla danych semistrukturalnych jest nowy (prowadzone są badania). Powstało już wiele opisów formalnych opisujących struktury dla modelu semistrukturalnego (wykorzystujące logikę, grafy).

Proponowane schematy zakładają specyfikowanie typów po umieszczeniu danych w bazie – inaczej niż w bazach relacyjnych i obiektowych. W takim rozwiązaniu można tym samym danym przyporządkować wiele typów.

Ekstrakcja systemu – szukanie najlepszego schematu dla określonej porcji danych.

Znajdowanie najlepszego schematu na podstawie analizy zapytania.

Przykład:

select row: { name: N, resume; R }

where {name: N, resume: R } in Person,

{title: T, address.country: “France” } in R,

contains ( T, “SGML” )

Co wiemy – wynik to zbiór par i element „resume” to kolejna para (z tego powinna korzystać aplikacja która przetwarza wyniki).

Nie jest wymagany składnik “resume” w obiekcie “person” – wynik zapytania pusty.

Przeglądanie danych

Informacje o strukturze są pomocne podczas przeglądania danych

· Mapa witryny

· System Lore – przewodnik

Optymalizacja obliczania zapytań

Przykład

select X.title

from biblio._X

where X.*.zip = “12345”

Żeby znaleźć tytuł zawierający atrybut zip o wartości “12345” należy przeszukać wszystkie podobiekty obiektu „biblio”. Po przyjęciu pewnej struktury – atrybut zip może pojawić się w obiekcie book otrzymamy zoptymalizowane zapytanie.

select X.title

from biblio.book X

where X.address.zip = “12345”

Optymalizacja przechowywania danych

Dowolny graf możemy przechować w relacyjnej bazie danych, np.

ref ( source: oid, label: dom, destination: oid )

var ( obj: oid, value: dom )

Dane są podzielone na wiele małych części, przechowywanych w odległych miejscach. Gdy założymy, że baza zawiera dużo obiektów „book” to możemy użyć relacji:

book ( source: oid, title: string,

firstname: string, lastname: string,

street: string, city: string, zip: string )

Pobranie takich informacji wymaga odczytania tylko jednego rekordu.

Typ nie może ograniczać możliwości bazy danych – książka może posiadać wielu autorów, inne atrybuty (trzymamy je w dowolnym miejscu – nie są określone przez strukturę).

Typy danych semistrukturalnych

Informacja o typie – opis struktury każdej z klas i jej relacji z innymi klasami.

· Klasy są zdefiniowane mniej precyzyjnie – obiekty mogą należeć do więcej niż jednej klasy

· Niektóre obiekty należą tylko do klasy domyślnej „object”

· Przybliżona zgodność z typem.

Szukanie schematu w danych

Dane w modelu semistrukturalnym mogą mieć różne schematy – poszukiwania najlepszego schematu dla konkretnej porcji danych – problem ekstrakcji schematu.

· Przewodniki – system Lore. Stosowane jako streszczenie zawartości grafu danych.

Przykład

employee

employee.name

employee.manages

employee.manages.managedby

employee.manages.managedby.manages

employee.manages.managedby.manages.managedby

company

company.name

company.worksfor

company.worksfor.name

… (lista nie skończona – graf danych zawiera cykle)

Chcemy stworzyć skończony graf (opis powyższej listy) – przewodnik (konstrukcja przypomina niedeterministyczne przekształcenie automatu w stan deterministyczny). Musi być zapewniona:

· Dokładność: każda ścieżka z grafu danych występuje w przewodniku (i odwrotnie) – czasami lepiej mieć automat

· Zwięzłość: każda ścieżka występuje w przewodniku tylko raz

Odwzorowywanie schematów na podstawie zapytań

Dane semistrukturalne generowane przez starsze systemy lub jako wynik zapytania – odwzorowywanie struktury z zapytań.

Przykład: (StruQL)

where bib -> L -> X, X-> „author” -> A, X -> „title” -> T,

X -> “year” -> Y

create Root(), HomePage(A), YearEntry(A,Y), PaperEntry(X)

link Root() -> “person” -> HomePage(A),

HomePage(A) -> “year” -> YearEntry(A,Y),

YearEntry(A,Y) -> “paper” -> PaperEntry(X),

PaperEntry(X) -> “title” -> T,

PaperEntry(X) -> “author” -> HomePage(A),

PaperEntry(X) -> “year” -> Y

(pobieranie plik z bibliografią i tworzy stronę dla każdego autora)

Graf schematu odwzorowanego na podstawie zapytania:

Współdzielenie

Przykład:

Relacja „r” z dwoma atrybutami a i b typu integer

I { tuple: o1 { a: o2(5), b: o3(6) }

tuple: o4 { a: o5(5), b: o6(7) } }

type r = { tuple: v1 { a: v2(string), b: v3(string) } }

I’ { tuple: o1 { a: o2(5), b: o3(6) }

tuple: o4 { a: o2(5), b: o6(7) } } I oraz I’ są typu „r”

Czasami przydatne jest rozróżnienie między komponentami współdzielonymi a niewspółdzielonymi oraz możliwość wykluczenia współdzielenia lokalnego.

I jest typu „r”, a I’ jest typu „r’” który umożliwia współdzielenie pola a.

type r = { tuple : v1 { a: &v2, b: v3(string) } }

Przykład:

type t = { a: t, b: t } OR string (drzewa binarne bez współdzielenia)

type t = { a: &t, b: &t } OR string (graf obiektów t, które są ciągami)

Wieloznaczność atrybutów

Możliwość kontroli wieloznaczności określonego atrybutu – wyrażenia regularne.

Przykład 1:

type p = { (author: string)+, title: string, (year: int)? }

Obiekt jest typu p jeśli zawiera przynajmniej jeden atrybut author, dokładnie jeden title oraz opcjonalnie year.

Przykład 2:

type b = { ( paper: { (author: string)+,

title: string,

(year: int)? }

| book: { (author: string)+,

title: string,

publisher: string,

(edition: int)* } )* }

Kolejność

Wprowadza się dwa rodzaje obiektów: nieuporządkowane i uporządkowane.

Przykład:

type Company =

{ (person:

{name: string, assignments: Assign, (phone: string)? }) *}

type Assign =

[ (assignment:

{name: string, year: string, (kind: string)* }) ]

[ … ] – rozszerzenie składni – uporządkowane podobiekty.

c1 { person:

{name: „Dupont”,

assignments:

[ assignment: { name: „prototype design”,

year: 1994,

kind: “low priority” },

assignment: { name: “production design”,

year: 1997,

kind: “high priority” } ],

phone: “2345” },

person: { … } }

Ograniczenia ścieżek w danych semistrukturalnych

Ograniczenie to umożliwia uzyskanie pewnego stopnia semantycznej integralności, a także umożliwia optymalizację zapytań.

Przykład:

select row: P2

from r.publication P1,

r.publication P2,

P1.auth A

where “Database Systems” in P1.title and

A in P2.auth

select row: P’

from r.publication P,

P.auth A,

A.pub P’

Where “Database Systems” in P.title

Ograniczenia w języku XML

Istnieje kilka systemów typizacji umożliwiających stosowanie ograniczeń struktury dokumentów XML:

· XML – Data

…

</elementType>

…

</elementType>

(range – ogranicza typ powiązanego elementu, nie wskazuje lokalizacji danych)

· XML – Link

Ograniczenia koreferencji.

Do tej pory nie ma wersji XML, która pozwala na stosowanie ograniczeń dotyczących ścieżek i zawierania