42642 ullman008 (2)

22 1 DZIEDZINA SYSTEMÓW BAZ DANYCH

(Komitet ds. systemów i języków danych (Cotnmiltee on Data System and languages)‘• W podrozdziale 2.7 Czytelnicy będą mieli sposobność poznać oba te modele: hierarchiczny i sieciowy, mimo że obecnie mają one już tylko historyczne znaczenie.

Kłopot z używaniem pierwszych modeli i systemów polegał na tym, że nie dawały one możliwości korzy stania z języków zapytań wysokiego poziomu. Na przykład język opracowany przez CODASYL dostarczał instrukcje poruszania się pomiędzy' elementami danych w postaci grafu wskaźników do nich. Trzeba było nie lada wysiłku, aby napisać w tym języku program, obsługujący nawet bardzo prosie zapytania.

1.1.2. Relacyjne systemy baz danych

Systemy baz danych zmieniły się znacznie od ukazania się w roku 1970 słynnego artykułu Teda Codda“. Propozycja Codda polegała na umożliwieniu prezentowania użytkownikowi danych w postaci tabel, nazywanych relacjami. Wewnątrz systemu natomiast mogła powstawać złożona struktura danych, która gwarantowała uzyskiwanie błyskawicznych wyników dla różnorodnych zapytań. Ale w przeciwieństwie do wczesnych baz danych użytkownik relacyjnych baz danych nic nie musiał wiedzieć o tej wewnętrznej strukturze. Zapytania można było wyrażać w języku bardzo wysokiego poziomu, co w znaczny sposób podniosło wydajność pracy programistów baz danych. Model relacyjny systemów baz danych dominuje w naszym podręczniku, poczynając od rozdziału 3, gdzie pojawia sic opis podstawowych pojęć. Od rozdziału 5 rozpocznie sic nauka języka SQL (struclured query language -język zapytań strukturalnych), najważniejszego języka zapytań dla modeli relacyjnych. Krótkie wprowadzenie do relacji pozwoli Czytelnikowi uchwycić prostotę tego modelu, a przedstawiony poniżej przykład w $QL obrazuje to, że model relacyjny umożliwia naturalny zapis zapytania bez szczegółowej „nawigacji” w bazie danych.

PRŻYKLAD 1.1

Relacje są przedstawione w postaci tabel. W nagłówkach kolumn znajdują się atrybuty, które opisują zawartość kolumn. Oto przykład relacji nazwanej Konta, służącej do księgowania kont bankowych, ich bilansu i typu.

Nr konta	Bilans	Typ
12345 67890	1000,00 2846,92	oszczędnościowy rozliczeniowy

‘ CODASYl. Data Basc Task Group Apil 1971 Report. ACM. New York.

** Codd F..F.: A relationa! model for largc shared data banks. Comm. ACH, 13 : 6. s. 377-

W nagłówkach kolumn występują trzy atrybuty: nr konta, bilans oraz typ. Pod nazwami atrybutów znajdują sic wiersze nazywane krotkami. Zostały wypisane dwie krotki., wielokropki umieszczone pod nimi sugerują, że jest o wiele więcej krotek, po jednej dla każdego konta w banku. Pierwsza krotka informuje o tym. że na koncie o numerze 12345 zgromadzono tysiąc dolarów' i że jest to rachunek oszczędnościowy. Dane z drugiej krotki dotyczą konta rozliczeniowego o numerze 67890 z bilansem w wysokości 2846,92S.

Załóżmy, żc chcemy z bazy danych otrzymać informację o bieżącym bilansie konta nr 67890. Zapytanie w SQL wygląda następująco:

SELECT bilans

FROM Kónta

WHERE nr konta = 67890;

W następnym przykładzie pokażemy, w jaki sposób zapytać o konta oszczędnościowe z. bilansem ujemnym:

SELECT r.r konta

FRCM Konta

WHERE typ = 'oszczędnościowe' AND bilans < 0;

Nie oczekujemy oczywiście, że podanie dwóch przykładów wystarczy, aby Czytelnicy stali się ekspertami w zakresie programowania w $QL. Powinno to jednak umożliwić zrozumienie istoty zapisu instrukcji select-from-where tego języka. W zasadzie w przykładach tych zleca się systemowi baz danych przeprowadzenie następujących operacji:

1.    Sprawdzenie wszystkich krotek relacji Konta, wymienionej w klauzuli FROM.

2.    Wyszukanie wszystkich tych krotek, które spełniają w arunek opisany w^: klauzuli WHERE.

3.    Sformułowanie odpowiedzi zawierającej wybrane krotki z uwzględnieniem atry butów wskazanych w klauzuli SELECT.

W praktyce system musi zapewnić „optymalizację” zapytania i znaleźć wydajny sposób znalezienia odpowiedzi, nawet jeśli relacje, których dotyczy zapytanie, są bardzo obszerne.

□

Najwcześniej na rynku pojawiły się relacyjne i „przedrelacyjne” systemy DBMS, produkowane w firmie IBM. Poza tym, aby tworzyć i sprzedawać relacyjne systemy DBMS, specjalnie powstawały nowe firmy. Niektóre z nich znajdują się obecnie wśród największych producentów- oprogramowania na święcie.