Baza danych jest to zestaw danych pozbawiony redundancji (nadmiarowości) wzajemnie powiązanych i zorganizowanych w celu ich wielokrotnego wykorzystania.

Dane mogą być organizowane w różne struktury, takie jak:

• rekord (ang. record);
• tablica (ang. array);
• lista (ang. list);
• drzewo (ang. tree);
• kolejka (ang. queue), wg zasady FIFO - First In, First Out;
• stos (ang. stack), wg zasady LIFO - Last In, First Out i in.

Rekord jest zestawem związanych ze sobą informacji zawartych w polach (ang. fields) różnych typów (np.: tekstowe, numeryczne, daty, logiczne i in.).

Logicznym odpowiednikiem rekordu jest krotka. Krotka, zwana także n-tką, jest to lista n elementów, które nie muszą należeć do tego samego zbioru. Jest więc krotka uogólnieniem pojęcia ciągu skończonego.

Systemy zarządzania bazami danych SZBD (ang. DBMS - Database Management System) są czymś więcej niż tylko jednolitym repozytorium (magazynem) informacji. Wszystkie systemy zarządzania bazami danych posiadają następujące właściwości:

• mechanizmy usuwania niekompletnych tranzakcji i odtwarzania transakcji po awarii nośnika;
• narzędzia do zarządzania relacjami;
• jednoczesną obsługę dostępu wielu użytkowników;
• język dostępu do danych, który może być osadzony w kodzie aplikacji.

Transakcja jest sekwencją instrukcji, po wykonaniu której baza danych z jednego stanu spójnego przechodzi w inny stan spójny. Transakcja jest operacją elementarną, co oznacza, że SZBD wykonuje po kolei wszystkie instrukcje wchodzące w jej skład lub nie wykonuje żadnej. W przypadku niepowodzenia którejś z kolejnno wykonywanych instrukcji system wycofuje poprzednio wykonane, tzw. wycofanie transakcji (ang. rollback) i przywraca status quo ante.

Ze względu na organizację danych można wyróżnić następujące rodzaje baz danych:

• kartotekowe (ang. Flat Files);
• hierarchiczne (ang. Hierarchical Database);
• sieciowe (ang. Network Database);
• relacyjne (ang. Relational Database);
• obiektowe (ang. Object-Oriented Database).

Kartotekowe bazy danych są także nazywane bazami o płaskich plikach danych ze względu na brak powiązań z innymi plikami danych.

Podstawową ich wadą był brak jednolitego formatu danych. Bazy tego typu można spotkać już tylko na odizolowanych stanowiskach.

Hierarchiczny model bazy danych polega na zorganizowaniu danych w struktury drzewiaste z węzłami i łączeniu ich za pomocą tzw. gałęzi (ang. branches). Najwyższy węzeł nosi miano korzenia (ang. root).Każdy węzeł, z wyjątkiem korzenia, jest połączony w górę z jednym węzłem zwanym "rodzicem" (ang. parent).

Do zalet modelu należy zaliczyć łatwość projektowania i ustalania relacji typu jeden-do-wielu. Wadami są natomiast utrudnione usuwanie i wstawianie danych oraz tworzenie relacji wiele-do-wielu.

Sieciowy model danych przypisuje danym wewnętrzne identyfikatory (adresy), a związki pomiędzy danymi reprezentowane są poprzez powiązania referencyjne lub wskaźnikowe. Struktura danych tworzy więc graf, czyli sieć.

W modelu tym stosunkowo szybko są wyszukiwane rekordy powiązane z innymi rekordami, ale wyszukiwanie komplikuje się w językach używających wielu znaków diakrytycznych.

Relacyjny model danych przedstawił w roku 1970 Edgar Ted Codd z firmy IBM. W modelu tym dane są przechowywane w prostych plikach liniowych nazywanych relacjami lub tablicami. Jedną z dużych zalet modelu relacyjnego w stosunku do poprzedników jest jego prostota. Z modelem relacyjnym IBM wprowadził język SQL w celu ułatwienia dostępu do danych i ich modyfikowania.

Wiersze tablic są nazywane krotkami (ang. tuples), natomiast kolumny atrybutami. W relacyjnych bazach danych tablice są niezależne, w przeciwieństwie do modeli hierarchicznego i sieciowego, gdzie występują połączenia wskaźnikowe. Tablica relacyjna może zawierać tylko jeden rodzaj krotek, które posiadają stałą liczbę nazwanych pól określonego typu (atrybutów).

Klucz główny jednoznacznie identyfikuje wiersz w tablicy. Klucz ten może zostać stworzony na podstawie jednego lub kilku pól. Klucz obcy (ang. foreign key), którego wartością jest wartość pewnego klucza głównego, pozwala na łączenie tablic.

Trzy zasady tworzenia tablicy (relacji) danych:

1. każda dana w tablicy może wystąpić tylko raz (normalizacja I rzedu);
2. dane nie w pełni zależne od podstawowego klucza danej tablicy należy przenieść do innej tablicy (normalizacja II rzedu);
3. należy usunąć wszystkie pola których wartość może być wyznaczona z innych danych tablicy (normalizacja III rzedu);

Relacja posiada następujące właściwości:

• wszystkie jej krotki są różne;
• wszystkie jej atrybuty są różne;
• kolejność krotek nie ma znaczenia i w ogólności nie jest ona znana;
• kolejność atrybutów nie ma znaczenia;
• wartości atrybutów są elementarne, tzn. nie mogą być dzielone.

W relacyjnej bazie danych nie ma odpowiedników rekordów w pełnym tego słowa znaczeniu, tzn. o zmiennych rozmiarach lub liczbie składowych. Dlatego w tym przypadku używa się w literaturze raczej określenia krotka.

Główną zaletą baz relacyjnych są łatwość projektowania i implementacji. Niezależność danych pozwala na łatwe wprowadzanie zmian i tworzenie relacji. Zaletą jest także prosty język dostępu do danych SQL (ang. Structured Query Language).

Obiektowe bazy danych nie są jeszcze tak powszechne jak bazy relacyjne.

Obiekty, do zarządzania danymi, zostały wprowadzone po raz pierwszy na początku lat siedemdziesiątych przez Palo Alto Research Center z firmy Xerox.

Logicznym odpowiednikiem jednostki informacji o obiekcie jest encja (ang. entity). Jest to reprezentacja wyobrażonego lub rzeczywistego obiektu stosowana przy modelowaniu danych podczas analizy informatycznej. Encja ma nazwę (l.poj.) i może posiadać cechy oraz operacje. Encja może być modelem obiektu rzeczywistego, lub nierzeczywistego, materialnego, lub niematerialnego, może odwoływać się do pojęcia faktu, zdarzenia itp.

Tablica 1. Przykłady encji

Wg nomenklatury Rozszerzonego Języka Znaczników XML (ang. Extensible Markup Language), encja jest obiektem przechowywania danych. Podstawową encją w tym przypadku jest sam dokument.

Elementarnymi dla obiektowości pojęciami, które wchodzą w skład modelu obiektowego, są:

• klasa;
• dziedziczenie i hierarchia klas;
• obiekt i jego tożsamość;
• właściwość (atrybut) i metoda;
• hermetyzacja;
• polimorfizm;
• komunikat.

Wymienione pojęcia zostały krótko przedstawione w notatce pt.: "Obiektowe podejście do problemów CAD/CAM" .

Istnienie unikalnych identyfikatorów obiektów czyni w zasadzie zbędnym pojęcie klucza podstawowego, występujące w modelu relacyjnym.

Atrybuty (ang. attributes) są częścią definicji klasy. Poprzez przypisywane im wartości tworzą stan obiektu. Atrybuty obiektu są analogiczne do typów krotek relacji (kolumn tablic) w relacyjnych bazach danych.

Obiektowe bazy danych pozwalają na łatwiejsze przechodzenie od rzeczywistej dziedziny problemu, poprzez abstrakcyjny model pojęciowy do implementacji w danych języku programowania. W ten sposób podejście obiektowe daje nadzieję na zniesienie granic pomiędzy projektantem a programistą.

Obiektowe systemy baz danych, mimo iż wyznaczają aktualnie trend rozwoju baz danych, nie mają jeszcze odpowiedniej infrastruktury, aby zastąpić całkowicie relacyjne bazy danych, podobnie jak bazy relacyjne wyparły systemy hierarchiczny i sieciowy.

Obiektowo-relacyjne bazy danych są najnowszym osiągnięciem w rozwoju hybrydowych architektur baz danych. Systemy te pojawiły się między innymi z powodu ogromnych inwestycji poczynionych przez różne organizacje w systemy relacyjnych baz danych i ze względu na perspektywę dużych kosztów związanych z migracją na inny format danych. Znaczące firmy takie jak Oracle, Informix, Sybase, czy IBM przekształcają swoje systemy danych w systemy obiektowo-relacyjne, które są lepiej przystosowane np. do danych multimedialnych (duże obiekty typu BLOB - ang. Binary Large Object), danych przestrzennych, abstrakcyjnych typów danych (ADT) i innych danych złożonych. Systemy te zachowują jednocześnie wiele technologii, które sprawdziły się w systemach relacyjnych (takie jak architektura klient/serwer, mechanizmy buforowania i indeksowania, przetwarzanie transakcji, czy optymalizacja zapytań). Obiektowo-relacyjne bazy danych stanowią więc kompromis pomiędzy rozwiązaniami najnowszymi i sprawdzonymi.

1. Shalloway A., Trott J.R., Wzorce projektowe. Projektowanie zorientowane obiektowo, Wyd. Helion, Gliwice 2001
2. Struzińska-Walczak A., Walczak K., Nauka programowania systemów baz danych, Wyd. W&W, Warszawa 1999

---