ZSBD-2st-1.2-w6.tresc-1.1-Slajd16

Z Studia Informatyczne
Wersja z dnia 16:27, 11 sie 2006 autorstwa PKrzyzagorski (dyskusja | edycje)
(różn.) ← poprzednia wersja | przejdź do aktualnej wersji (różn.) | następna wersja → (różn.)
Przejdź do nawigacjiPrzejdź do wyszukiwania

Indeksowanie hierarchii rozszerzeń klas

Indeksowanie hierarchii rozszerzeń klas


W obiektowych bazach danych typowe są zapytania wykonywane na heterogenicznych kolekcjach obiektów. Przykład takich zapytań przedstawiono na slajdzie. Zapytania adresują heterogeniczny zbiór osób obejmujący: kierowników, pracowników, którzy nie są kierownikami, studentów i pozostałe osoby, które nie są ani pracownikami, ani studentami. Zapytanie Q1 wyszukuje w tej heterogenicznej kolekcji, osób w wieku poniżej 30 lat. Wynikiem zapytania mogą być kierownicy, pracownicy, którzy nie są kierownikami, studenci oraz osoby nie będące ani pracownikami, ani studentami. Z kolei zapytanie Q2 dotyczy wyspecjalizowanego podzbioru osób, które pracują na stanowisku kierowniczym.

Dostępne są dwie alternatywy zastosowania klasycznych indeksów dla przyśpieszenia wykonywania przedstawionych zapytań. Pierwsze rozwiązanie polega na utworzeniu jednego wspólnego indeksu dla wszystkich podzbiorów w hierarchii. Taki indeks będzie przydatny dla efektywnej realizacji zapytań klasy Q1, natomiast nie będzie przydatny dla zapytań klasy Q2. W tym drugim przypadku duża część wskazywanych przez indeks obiektów spełniających zadane kryterium wiekowe, nie będzie spełniała kryterium typu danych. Ponieważ indeks wskazuje również osoby, które nie są kierownikami.

Drugie potencjalne rozwiązanie polega na utworzeniu osobnych indeksów dla każdego podzbioru obiektów. Przeciwnie niż dla poprzedniego rozwiązania, zbiór indeksów będzie dobrze wspierał wydajną realizację zapytań klasy Q2, a znacznie gorzej będzie wspierał zapytania klasy Q1. Znalezienie wszystkich osób w wieku 25 lat będzie wymagało przejrzenia wszystkich czterech indeksów.

Z powyższej analizy wynika, że potrzebne są nowe rozwiązania, które będą dedykowane dla heterogenicznych kolekcji danych i, które będą przydatne dla dowolnej klasy selektywnych zapytań na takiej kolekcji.


<< Poprzedni slajd | Spis treści | Następny slajd >>