I.
Wprowadzenie do  języków zapytań (1)
II.
Wprowadzenie do  języków zapytań (2)
  Wstęp
  1. Niezgodność impedancji
  2. Schemat i organizacja danych - nieodłączne cechy języka zapytań
  3. Pomiędzy złożonością modelu danych a złożonością zapytań
  4. Architektura SZBD włączająca przetwarzanie zapytań
  Podsumowanie
  Zadania
III.
Pojęcia obiektowości w bazach danych (1)
IV.
Pojęcia obiektowości w bazach danych (2)
V.
Podstawy semantyczne języków zapytań
VI.
Modele składu obiektów
VII.
Stos środowisk, rezultaty zapytań, funkcja nested
VIII.
Język SBQL (Stack-Based Query Language) (1)
IX.
X.
Dalsze własności SBQL
XI.
Operatory order by i group by
XII.
Przetwarzanie struktur nieregularnych
XIII.
Rozszerzenie języków zapytań o konstrukcje imperatywne
XIV.
Procedury, procedury funkcyjne, metody, reguły zakresu
XV.
Parametry procedur i metod, procedury rekurencyjne, optymalizacja poprzez modyfikację zapytań

 

3. Pomiędzy złożonością modelu danych a złożonością zapytań

Istnieje dość prosta zależność  pomiędzy złożonością modelu obiektowego a złożonością języka zapytań:

Im więcej informacji semantycznej znajduje się w strukturach danych, tym mniej pracochłonne, mniej złożone i krótsze są zapytania; i odwrotnie.

Jeżeli model danych nie daje możliwości zapisu pewnych informacji semantycznych, lub je gubi, wówczas schemat danych niezbędny do rozumienia biznesowej roli danych jest prosty formalnie, ale koncepcyjnie jest złożony. Przez to jest mniej czytelny dla programisty, co wydłuża czas formułowania zapytań. Dodatkowo, programista formułujący zapytanie musi te zależności uwzględnić w zapytaniu, przez co jest ono bardziej złożone. Zatem brak możliwości uwzględnienia w schemacie danych pewnych informacji dotyczących semantyki danych oznacza podwójną stratę: dodatkowy wysiłek programisty na zrozumienie zależności w strukturze danych i zależności pomiędzy strukturami danych a dziedziną biznesową oraz dodatkowy wysiłek na sformułowanie zapytania. Są jeszcze dalsze straty: zwiększony rozmiar programów aplikacyjnych, co zwiększa koszt ich tworzenia i (szczególnie) pielęgnacji, oraz zwiększony koszt/czas ewaluacji takiego bardziej złożonego zapytania. To oznacza konieczność większego nacisku na metody optymalizacji zapytań. Znaczna część procesów optymalizacji zapytań w relacyjnych SZBD, w szczególności optymalizacja zapytań ze złączeniami, zajmuje się niczym innym, jak reperowaniem tego, co zostało zepsute poprzez zgubienie informacji semantycznej w relacyjnej strukturze danych.

3
Rys.3. Schemat prostej obiektowej bazy danych

Ta zależność pomiędzy złożonością modelu danych a złożonością formułowania i wykonywania zapytań nie jest zwykle dobrze rozumiana. Zwolennicy relacyjnego modelu danych podkreślają, że ogromną zaletą relacyjnych struktur danych jest ich "koncepcyjna prostota" oraz tzw. niezależność danych (data independence), rozumiana jako możliwość zmian w strukturach danych bez konieczności dramatycznych zmian w aplikacjach działających na tych danych. Zwykle w tej dyskusji umyka fakt, że prostota struktur danych jest pozorna: proste struktury danych oznaczają dodatkową ilość nieformalnych związków pomiędzy danymi, nie reprezentowanych w tej strukturze, o których musi wiedzieć programista, aby poprawnie pisać zapytania i programy. "Prostotę" uzyskuje się więc poprzez wyrzucenie ze schematu struktury danych tych niezbędnych informacji semantycznych, które są niewygodne dla zadanego modelu danych. Przypomina to "prostotę" samochodu, w którym (dla uproszczenia konstrukcji) zrezygnowano z nadwozia, foteli i wycieraczek. Na dodatek, zapytania, które formułuje programista, stają się bardziej złożone, dłuższe i wolniejsze. Wspomniana niezależność danych sprowadza się natomiast do tego, że programista nie widzi i nie musi uwzględniać wielu szczegółów organizacji i reprezentacji danych (np. indeksów). Ale ten efekt można uzyskać także dla obiektowych baz danych (a raczej dla praktycznie dowolnych baz danych), co pokażemy w tym wykładzie.

Powyższą tezę zilustrujemy na prostym przykładzie. Rys.3 przedstawia prosty obiektowy schemat bazy danych zapisany w notacji przypominającej UML.

4
Rys.4. Schemat relacyjny bazy danych równoważny schematowi z Rys.3

Programista po 2-3 minutach wyjaśnień jest w stanie zorientować się w zawartości bazy danych. Zawiera ona cztery klasy obiektów, związki asocjacji z rolami, liczności kolekcji obiektów, asocjacji i atrybutów oraz związek dziedziczenia. Ze schematu wynika np. że każdy pracownik jest osobą, ma jedno nazwisko, lecz może mieć wiele imion i adresów, może pracować w wielu firmach, posiadać wiele wypłat i ocen w każdej z nich itd. Ładunek informacji semantycznej zawartej w tym schemacie i niezbędnej do prawidłowego zadawania zapytań jest więc znaczny.

Na Rys.4 przedstawiamy równoważną bazę danych, która zostałaby zrealizowana w systemie relacyjnym. Strzałki oznaczają związki referencyjne pomiędzy kluczem obcym i kluczem głównym, które programista musi dokładnie rozumieć, aby poprawnie budować zapytania. Związki te są niejawne w schemacie relacyjnym i prawie nieczytelne w sytuacji, gdy nazwa klucza obcego jest inna niż nazwa klucza głównego. Nie ma oczywiście związku dziedziczenia, zaś każdy atrybut posiadający potencjalnie więcej niż jedną wartość musi być reprezentowany jako odrębna tabela. Część informacji semantycznej została utracona, np. informacja o licznościach niektórych atrybutów i związków. Nie ma wątpliwości, że programista spędzi kilkanaście lub kilkadziesiąt minut nad zrozumieniem zależności w tej strukturze danych i będzie to okupione dodatkowym czasem pracy przy formułowaniu każdego zapytania odnoszącego się do tej struktury.

Utrudnione rozumienie schematu, w którym zostały zgubione pewne związki semantyczne w danych, nie jest główną niedogodnością, na którą jest narażony programista. Prześledzimy na prostym przykładzie, jak będą wyglądać zapytania do powyższych dwóch struktur danych ("Podaj nazwiska i stanowiska pracowników pracujących w firmach zlokalizowanych w Radomiu"):

P2.1.
SBQL, model obiektowy:

(Firma where "Radom" Miejsce).
FZ.Zatrudnienie.ZP.Pracownik.(Nazwisko, Stan)

P2.2.
SQL, model relacyjny:

select s.Nazwisko, w.Stan
from Firma as f, Lokal as k, Zatrudnienie as z,
Pracownik as p, Wyszkolenie as w, Osoba as s
where k.Miejsce = "Radom" and k.NrF = f.NrF
and f.NrF = z.ZF and z.ZP = p.NrP and w.NrP = p.NrP
and p.NrOs = s.NrOs

Zapytanie w SBQL ma 21 elementów leksykalnych, podczas gdy zapytanie w SQL ma 78 elementów leksykalnych. Zapytanie w SQL jest znacznie dłuższe od zapytania w SBQL głównie wskutek tego, że w SQL konieczne są "złączeniowe" predykaty (takie jak k.NrF = f.NrF i następne) kojarzące informację semantyczną, która została zgubiona podczas projektowania relacyjnej struktury danych.  Drew Wade porównuje to do sytuacji, w której zaparkowanie samochodu w garażu (czytaj: zapisanie informacji w bazie danych) wymaga rozmontowania go na części. Wyjazd z garażu (czytaj: sformułowanie zapytania przez programistę) implikuje konieczność ponownego zmontowania samochodu, co jest oczywiście czasochłonne i kosztowne. Jakkolwiek porównanie wyolbrzymia negatywy, jest w nim wiele racji. Według szacunków zwolenników obiektowych baz danych, ilość kodu napisanego dla aplikacji działającej na relacyjnej bazie danych w przybliżeniu trzykrotnie przerasta tę ilość kodu, która jest niezbędna do zapisania logiki tej aplikacji w przypadku systemów i języków obiektowych. Jest to szacunek dość wiarygodny, zważywszy chociażby na przedstawiony wyżej mini-przykład. Ma to oczywiste skutki dla czasu i kosztu budowy oprogramowania oraz jego jakości. Te skutki są najbardziej niekorzystne dla zmian oprogramowania (maintenance) rozłożonych na wiele lat, gdyż skomplikowanie schematu danych oraz zwiększenie długości kodu aplikacji w oczywisty sposób utrudnia nanoszenie zmian, przyczyniając się do znacznej ich bezwładności oraz znacznego zwiększenia czasu ich wykonania, kosztu i pracochłonności.

Copyrights © 2006 PJWSTK
Materiały zostały opracowane w PJWSTK w projekcie współfinansowanym ze środków EFS.