Z problematyki tworzenia baz danych na potrzeby badań archeologicznych


Miłosz Pigłas

milosz@archeocs.com





1. Wprowadzenie

Jednym z aspektów procesu "informatyzacji" badań archeologicznych, a więc wykorzystywania tak zwanych metod komputerowych do analizy zjawisk pradziejowych, jest problem gromadzenia i składowania danych w postaci cyfrowej. Postulaty tworzenia źródeł danych w takiej formie, jako wysoce efektywnych i opłacalnych, pojawiają się od kilku lat w polskiej literaturze archeologicznej (np. Kurnatowski, Kobusiewicz 2000, 594). O ile zasadność tego pozostaje poza dyskusją, o tyle stosowane do tego metody mogą budzić kontrowersje. Codzienna praktyka badań archeologicznych wygląda w większości przypadków tak, że w celu przeniesienia danych źródłowych do postaci cyfrowej, sięga się po nieodpowiednie narzędzia, na przykład edytory tekstu, lub arkusze kalkulacyjne. Dotyczy to w szczególności programów z pierwszej kategorii - umożliwiających szybkie i dość wygodne wprowadzenie informacji, jednak nie udostępniających funkcji, które przyspieszałyby ich przetwarzanie na etapie analizy. W przypadku arkuszy kalkulacyjnych sytuacja wygląda lepiej, ze względu na to, że z definicji mają one postać tabelaryczną, a ponadto wbudowany mają zestaw procedur ułatwiających na przykład istotne dla archeologów obliczenia statystyczne. Wyszukiwanie niezbędnych informacji można w aplikacjach tego typu zrealizować za pomocą funkcji filtrujących, jednak jest to rozwiązanie czasochłonne i mało efektywne. W sytuacji, gdy przychodzi nam wykorzystać dane cyfrowe w innym programie, niż ten, w którym zostały wprowadzone, okazuje się, że jedyną metodą dostępu do nich jest wczytanie zawierającego je pliku. To oczywiście automatycznie eliminuje możliwość wykorzystania choćby ww. procedur wyszukiwania.

Sposobem na uniknięcie wspomnianych niedogodności, jest wykorzystanie do gromadzenia i składowania danych oprogramowania, które zostało zaprojektowane do tego celu. W tym wypadku zarządzanie bazą danych na etapie jej tworzenia i eksploatacji jest realizowane na poziomie programów określanych jako Systemy Zarządzania Bazami Danych - SZBD, dalej określane jako systemy baz danych. Celem ich jest składowanie informacji na dysku komputera i udostępnianie ich poprzez zdefiniowane procedury wstawiania, usuwania i wyszukiwania (selekcji). Zaawansowane mechanizmy, które realizuje system w odpowiedzi na żądanie użytkownika, pozwalają po pierwsze na ich efektywne przetwarzanie w przeznaczonych do tego aplikacjach, które nawiązują z nim połączenie drogą wywoływania wspomnianych funkcji. Po drugie zabezpiecza dane przed ich utratą i zniszczeniem, na przykład udostępniając procedury odtwarzania. Po trzecie pozwala odwzorować zależności, które zachodzą między nimi w świecie rzeczywistym.

Do efektywnego składowania danych nie wystarczy jednak stosowanie takiego oprogramowania, a konieczne jest zdefiniowanie struktury, która by uwzględniała ich charakter i wzajemne relacje. Celem tej krótkiej rozprawy jest wprowadzenie czytelnika w problematykę tworzenia baz danych z uwzględnieniem etapu ich projektowania i implementacji. Zagadnienia te zostaną poruszone w kolejnych rozdziałach w zakresie takim, który z jednej strony pozwoli uniknąć wnikania w skomplikowane szczegóły techniczne, zaś z drugiej zaprojektować bazę tak, że korzystanie z niej nie będzie stwarzało problemów, które pojawiają się, jeśli struktura danych jest nieprawidłowa. Przyswojenie sobie prezentowanego materiału pozwoli na tworzenie bazy danych z wykorzystaniem dostępnego na rynku oprogramowania, udostępnianego bezpłatnie, lub za opłatą, bowiem przyjęty standard określanych jako ANSI SQL jest niezależny od producenta systemu zarządzania bazami danych. Prezentowane wprowadzenie zostało ułożone w ten sposób, by baza danych, na przykładzie której omawiane są najważniejsze aspekty związane z korzystaniem z SZBD, mogła zostać wdrożona w aplikacjach, które wypełniają standard. Publikacja jest kierowana przede wszystkim do archeologów, jednak poruszane w niej zagadnienia są na tyle uniwersalne, że może być podstawą do stosowania baz danych w innych celach, także poza naukowych.


2. Terminologia

Baza danych jest pewnym odzwierciedleniem świata rzeczywistego, jego obiektów i zależności, które między nimi występują. Dlatego zdefiniowano tak zwany model danych, który określa przede wszystkim struktury, za pomocą których są one reprezentowane. Ponadto zawiera zbiór predefiniowanych operacji, które mogą być wykonywane na informacjach zgromadzonych w bazie. W dalszych rozważaniach będę odnosił się do najpowszechniejszego relacyjnego modelu danych, który jest tak określany ze względu na jego swoiste właściwości. Jak można się spodziewać, podstawowymi strukturami, służącymi do reprezentacji danych, są relacje, których zbiór tworzy bazę danych. Oprócz nazwy relacji jej schemat definiują atrybuty, z których każdy posiada dziedzinę (zbiór wartości, które może przyjmować). Wyobraźmy sobie następujący schemat relacji: obiekty(numer, artefakty, nazwisko rysownika, ). Tym sposobem zdefiniowaliśmy relację o nazwie "obiekty", która zawiera atrybuty "numer" - określający numer obiektu, "artefakty" - informujący, czy znaleziono w nim artefakty, czy też nie oraz "nazwisko rysownika" - nazwisko osoby, która wykonała rysunek profilu obiektu. Dziedziną pierwszego są wszystkie liczby całkowite, większe od 0, znak - litera, lub cyfra, trzeciego - ciąg co najwyżej 20 znaków. Każda relacja składa się z dowolnej liczby krotek - uporządkowanej listy elementów, których liczba jest równa liczbie atrybutów zdefiniowanych w jej schemacie. Krotkę relacji "obiekty" może być następująca lista: "3, t, Kowalski", gdzie przecinkami oddzielono poszczególne elementy. Można to odczytać następująco: "Obiekt numer 3, znaleziono w nim artefakty, został narysowany przez Kowalskiego". Oczywistym w tym momencie jest to, że relacja w terminologii systemów baz danych odpowiada temu, co potocznie zwykło się określać jako tabela. Poszczególne krotki odpowiadają jej wierszom, a atrybuty - nagłówkom kolumn. Zbiór relacji tworzy bazę danych, natomiast zbiór schematów relacji - schemat bazy danych. Należy przy tym podkreślić, że nazwy relacji w pojedynczym schemacie bazy danych muszą być unikalne, podobnie rzecz ma się z atrybutami, które nie mogą się powtarzać w pojedynczym schemacie relacji. Nie miałoby bowiem sensu na przykład tworzenie tabeli, w której dwa razy występowałaby kolumna o nagłówku "nazwisko rysownika".

Na każdą relację i jej poszczególne atrybuty można nałożyć ograniczenia integralnościowe, które określają poprawność danych. Przedtem wypełnijmy relację "obiekty" wartościami takim, jak przedstawia poniższa tabela:


Obiekty

nr

artefatky

nazwisko rysownika

1

n

Kowalski

2

t

Nowak

3

t

Kowalski

4

n

Iksińska

5

t

Nowak



Wyróżnia się następujące ograniczenia integralnościowe: klucz podstawowy (ang. PRIMARY KEY) - to wartość, która w sposób jednoznaczny definiuje krotkę. Wprowadzając kolejne dane do tabeli SZBD automatycznie sprawdzi, czy wartość w kolumnie, dla której zdefiniowano to ograniczenie jest unikalna i niepusta. Jeśli jest inaczej, nie pozwoli na wstawienie krotki do relacji. Kolejnym ograniczeniem jest unikalność (ang. UNIQUE) - w odróżnieniu od poprzedniego wartość lub zbiór wartości w krotce musi być unikalny, ale może być też pusty. Ograniczenia zawężającego dziedzinę dla danego atrybutu (CHECK), używamy, jeśli chcemy dokładniej określić, jakie wartości może przyjmować. W przykładowej relacji "obiekty" można nałożyć na atrybut "artefakty", który może mieć tylko i wyłącznie wartość "t" - oznaczającą obecność przedmiotów wykonanych przez człowieka w obiekcie, lub "n" - ich brak. Wstawienie z innymi wartościami, np "5, tak, Wiśniewska" zostanie zablokowane przez SZBD. Jeśli przyjdzie nam wskazać związek między dwoma relacjami, możemy użyć ograniczenia określanego jako klucz obcy (FOREIGN KEY) . Nałożenie go na atrybut oznacza, że wskazuje on na klucz podstawowy innej relacji w bazie danych. Ilustruje to następujący przykład. Do naszej przykładowej bazy danych dodajemy kolejną relację o nazwie "artefakty", która będzie zawierała informacje o przedmiotach znalezionych w obiektach.


Artefakty

nr obiektu

nazwa artefaktu

nr iwentarza

2

szpila

08/1

2

zapinka

08/2

3

szpila

08/3



Ma ona następujący schemat: artefakty(nr obiektu, nazwa artefaktu, nr inwentarza). Na atrybut "nr obiektu" nakładamy ograniczenie klucza obcego, tak, że ma wskazywać na atrybut "nr" w relacji "obiekty". Jeśli podejmiemy próbę wstawienia do niej następującą krotkę "5, szpila, 08/4", system bazy danych sprawdzi, czy w relacji "obiekty" istnieje krotka, w której atrybut "nr" ma wartość 5. Jeśli nie, operacja wstawiania nie zostanie wykonana. Zablokowane zostanie równie usuwanie z relacji "obiekty" krotek, o takich wartościach które ma atrybut "nr obiektu" relacji "artefakty", na przykład "2, t, Nowak". Podsumowując: nakładanie ograniczeń integralnościowych na atrybuty pozwala na częściowe zwolnienie użytkownika z odpowiedzialności za spójność danych. Nie musimy się obawiać, że na przykład do relacji "obiekty" zostanie dwa razy wprowadzony obiekt o tym samym numerze, lub do tabeli zawierającej informacje o artefaktach taki przedmiot, który ma przypisany numer niezarejestrowanego obiektu. Polecenia, których używa się do definiowania relacji i ich własności zostaną omówione w rozdziale pt. "Implementacja".


3. Projektowanie

Przed przystąpieniem do projektowania bazy danych, należy zapoznać się z wymaganiami, które ma ona spełniać, a więc przede wszystkim określić, jakie relacje mają ją tworzyć i jakie atrybuty każda z nich ma zawierać. Specyfikacja własności bazy danych zazwyczaj nie określa, jakie dokładnie tabele ta ma zawierać. Jest wskazówką dla projektującego strukturę, jakie związki zachodzą między jej elementami - poszczególnymi atrybutami, wartościami i tabelami. Jego zadaniem jest eliminacja niepożądanych własności, które mogą utrudniać utrzymywanie danych w bazie i ich przetwarzanie. Oprócz problemu unikania takich zjawisk, w rozdziale zajmiemy się modelowaniem związków między obiektami świata rzeczywistego. Zanim do tego przystąpimy, zdefiniujmy wymagania dla przykładowej bazy danych.

W okresie kilku sezonów wykopaliskowych prowadzono badania na stanowisku S. W ich trakcie zebrano pewien zbiór informacji, na które składają się dane dotyczące eksplorowanych wykopów. Każdemu z nich przyporządkowane są warstwy (co najmniej) jedna (mechaniczne lub naturalne), które zaobserwowano w trakcie eksploracji oraz obiekty (jeśli zarejestrowano takowe). Dla każdej warstwy sporządzano rysunek planu płaskiego, a dla obiektu - rysunek profilu. Dodatkowo w bazie mają być zgromadzone informacje o próbkach, które pobrano w poszczególnych wykopach.

Powyższa specyfikacja wymagań jest podstawą do sporządzenia modelu bazy danych, to znaczy wyznaczenia poszczególnych obiektów świata rzeczywistego, o których informacje będą w niej składowane i ich wzajemnych powiązaniach. Etap ten poprzedza tworzenie modelu relacyjnego bazy danych, zgodnie z którym będzie ona implementowana w wybranym SZBD. W tej procedurze opisu własności obiektów i charakteru związków, które zachodzą między atrybutami używa się powszechnie tak zwanego modelu encji-związków (ang. entity-relationship model - ER), w którym encja reprezentuje zbiór obiektów charakteryzujących się tymi samymi cechami. Zgodnie z przedstawioną specyfikacją można wyróżnić następujące encje: "sezon", "wykop", "warstwa", "obiekt", "rysunek", "próbka". Model bazy danych ma postać graficzną - każdą encję reprezentuje prostokąt z wpisanym na samej górze jej identyfikatorem, tak jak przedstawia to Rysunek 1.


Ponadto w modelu należy uwzględnić atrybuty, które są elementem opisu każdego obiektu. Każdy sezon, o którym informacja znajdzie się w bazie danych jest charakteryzowany datą jego rozpoczęcia, datą zakończenia, nazwiskiem kierownika badań oraz unikalnym identyfikatorem. Atrybutami obiektu "wykop" jest jego unikalny identyfikator (w obrębie całej bazy), szerokość, długość oraz głębokość. Każda warstwa jest opisana przez identyfikator, numer rysunku i zabytki wydzielone. Podobnie wygląda definicja obiektu, poszerzona o jego przewidywaną funkcję. Próbka posiada unikalny identyfikator, datę pobrania, typ wykonanej analizy, nazwisko eksperta , nazwę instytucji w której była wykonywana i jej wynik, oraz symbol raportu, w którym został zawarty. Rysunek charakteryzuje jego numer, data wykonania, nazwisko rysownika Rysunek 2. prezentuje wszystkie wymienione encje wraz z atrybutami.


Na etapie modelowania encjami można zdefiniować klucz podstawowy relacji, który jak pamiętamy jest jej identyfikatorem, co oznacza się przez postawienie # przed nazwą atrybutu, lub zbioru atrybutów, które go tworzą. Ponadto gwiazdką oznaczamy poszczególne cechy jako obowiązkowe (nie mogą mieć wartości pustej), na "rysunek" w encjach "warstwa" i "obiekt". Okrąg postawiony przed nazwą atrybutu oznacza jego opcjonalność, na przykład "ekspert", lub "instytucja" w encji "próbka".

Do określenia powiązań między obiektami w modelu ER używa się elementów określanych jako związki - linie ciągłe lub przerywane, z rozwidleniem na końcu lub bez, opatrzone opisem, który ma ułatwiać jego interpretację. Rysunek 3. prezentuje końcowy model bazy danych, do której wymagania zostały wymienione na początku.


Na jego podstawie można zinterpretować powiązania między poszczególnymi encjami, a więc także między obiektami, które te reprezentują. "Sezon" i "wykop" zostały połączone linią ciągłą, rozwidloną po prawej stronie. Ten typ związku, określa się jako "jeden do wielu" (1:M). Oznacza to, że każdemu wystąpieniu w bazie obiektu typu sezon musi towarzyszyć co najmniej jedno wystąpienie obiektu typu wykop. Podobnie rzecz ma się w przypadku powiązań encji "Obiekt" i "Warstwa" z encją "Wykop". Ponieważ w każdym wykopie musi być zarejestrowana co najmniej jedna warstwa, związek między tymi obiektami jest obustronnie obowiązkowy (linia ciągła na całej długości). Wystąpienie obiektu w wykopie nie jest obligatoryjne, dlatego jest to związek jednostronnie obowiązkowy (linia przerywana po stronie encji oznacza opcjonalność jej wystąpienia). Ponieważ nie jest obowiązkiem pobranie próbki w każdym z wykopów, które były eksplorowane, encje reprezentujące obiekty tego typu zostały połączone związkiem 1:M obowiązkowym po stronie "Próbki". Obiekt typu "Rysunek" jest powiązany zarówno z "Warstwą" jak i "Obiektem". Ze względu na to, że w danym momencie może zachodzić tylko jeden z nich - jeśli zostanie wykonany rysunek profilu obiektu, to na pewno nie będzie on planem płaskim warstwy. Jakkolwiek brzmi to nieco absurdalnie, takie powiązania muszą zostać jednoznacznie odwzorowane w modelu. Związek wyłączny oznacza się łukiem łączącym poszczególne związki, w tym wypadku "Rysunek" - "Obiekt" (1:1) i "Rysunek" - "Warstwa" (1:1).

Przekształcenie modelu ER do relacyjnego schematu bazy danych jest zadaniem trywialnym, pod warunkiem stosowania określonych reguł. Zgodnie z nimi każda encja reprezentowana jest przez relację, której nazwę tworzy się od nazwy encji w liczbie mnogiej. Zatem możemy wyróżnić tabele sezony(...), wykopy(...), warstwy(...), obiekty(...), próbki(...), rysunki(...). Do definiowania związków stosuje się klucze obce definiowane według następujących zasad:

  1. w związku 1:M wstawiamy klucz obcy po stronie "wiele" wskazujący na klucz podstawowy relacji po stronie "jeden". W zależności, czy związek jest obowiązkowy czy opcjonalny po stronie "wiele", klucz obcy nie może lub może przyjmować wartości puste;

  2. w przypadku związku wyłącznego klucze wstawione do encji wskazują na pozostałe z nią połączone, z których w danym momencie wystąpić może tylko jedna z nich. Klucze obce mogą przyjmować wartości puste.

  3. w związku 1:1 do relacji po stronie obowiązkowej wstawia się klucz obcy, który nie może przyjmować wartości pustej;

Po przekształceniu modelu encji - związków do modelu relacyjnego, po uwzględnieniu kluczy obcych otrzymaliśmy następujące relacje: sezony(id, data rozpoczęcia, data zakończenia, kierownik), wykopy(id, szerokość, długość, głębokość, sezon), warstwy(id, rysunek, wydzielone, wykop), obiekty(id, rysunek, wydzielone, funkcja, wykop), rysunki(id, rysownik, data, obiekt, warstwa), próbki(id, symbol, data, ekspert, typ analizy, wynik, instytucja, wykop)


We wstępie do rozdziału zostało wspomniane, że w fazie projektowania struktury bazy danych, kładzie się nacisk nie tylko na wydajność i efektywność przetwarzania gromadzonych w niej informacji, ale także, a może przede wszystkim na jej poprawność. Znaczenie tej cechy, jaką można zobrazujemy na przykładzie wcześniej utworzonej relacji "próbki". Jej fragment wypełniony przykładowymi danymi prezentuje tabela 3.


Próbki

id

data

wykop

instytucja

ekspert

wynik

typ

symbol

1

79.06.02

II/79

UJ

Krępy

r. 930

dendro

D21/83

4

79.07.13

II/79

UJ

Krępy

r.890

dendro

D 22/83

1

79.07.02

II/79

Kijów

Pawluk

brak

C14

K-C-3

6

79.07.15

I/79

UW

Mazur

dąb

pyłki

UW/1

7

79.06.02

III/79

UW

Mazur

brzoza

pyłki

UW/2

1

85.05.03

Ia/85


Zielski

krowa

kości

AA/74

2

85.05.04

IV/85


Zielski

ptactwo

kości

AA/76

3

85.05.04

IV/85


Zielski

krowa

kości

AA/75

5

86.06.10

IIIa/86


Zielski

koza

kości

AA/172




Z modelu encji-związków dowiadujemy się, że jej identyfikator tworzą atrybuty "id", "data" i "symbol", a zatem nie mogą one przyjmować wartości pustych. Taki zbiór w kategoriach modelu relacyjnego określa się jako klucz relacji. Oznacza to, że w sposób jednoznaczny identyfikuje każdą krotkę, gdyż sekwencja wartości w tych kolumnach musi być niepowtarzalna i niepusta. Wszystkie atrybuty będące elementami klucza relacji nazywamy podstawowymi, a pozostałe wtórnymi.

Przyglądając się takiej bazie danych, intuicyjnie wyczuwamy, że ma ona pewne niedogodności. Zwraca uwagę przede wszystkim nadmiarowość danych, gdyż zauważmy, że wielokrotnie powtarzają się informacje o miejscu zatrudnienia ekspertów oraz miejscu i dacie pobrania poszczególnych próbek. Nie jest to dotkliwe, szczególnie że baza ma niewielkie rozmiary, jednak redundancja danych jest źródłem niepożądanych zjawisk, które mogą się pojawić na etapie ich przetwarzania. Wyobraźmy sobie sytuację, że ekspert o nazwisku Zielski znalazł zatrudnienie na Uniwersytet Rzeszowski. Chcąc zachować poprawność zgromadzonych danych, należy uaktualnić je zgodnie z faktycznym stanem rzeczy. W tym celu musimy zmodyfikować odpowiednie wartości w aż sześciu krotkach, zamiast w jednej, jak należałoby oczekiwać. W terminologii SZBD zjawisko to określa się jako anomalię uaktualniania danych. Dane zawarte w bazie danych na tym etapie są niepełne, bowiem nie zawierają informacji o wszystkich próbkach, które zebraliśmy na stanowisku, a więc inaczej niż to było określone w specyfikacji wymagań. Wynika to z faktu, że wprowadzenie takich, dla których nie wykonano żadnych analiz będzie niemożliwe, gdyż jednym z atrybutów podstawowych relacji jest "symbol" oznaczający godło wykonanej ekspertyzy. Jeśli taka nie została wykonana, to pole musiałoby pozostać puste, co jest sprzeczne z definicją klucza relacji, który nie może zawierać takich wartości. Mamy tu do czynienia z kolejną anomalią, tym razem wstawiania danych. Jeśli stwierdzimy, że wykonana analiza nie spełnia naszych oczekiwań i będziemy dążyć do usunięcia informacji o niej, zostaniemy zmuszeni do pozbycia się wszystkich innych danych dotyczących określonej próbki, a więc pojawia się anomalia usuwania danych.

Pierwszym zadaniem przed przystąpieniem do implementacji bazy w systemie zarządzania, będzie takie przekształcenie powyższej struktury, by wyeliminować niekorzystne zjawiska. Można to osiągnąć rozdzielając relację "próbki" na mniejsze o pożądanych własnościach, zachowując przy tym wszystkie informacje. Proces dekomponowania schematu relacji określa się mianem normalizacji, gdyż polega on na sprawdzaniu czy znajduje się on w odpowiedniej postaci normalnej (jednej z pięciu) i ewentualnie doprowadzanie go do niej. Każda z nich definiuje kryteria, zgodnie z którymi bada się, w jakim stopniu baza danych jest odporna na ww. anomalie.

Schemat relacji jest w pierwszej postaci normalnej (1NF), jeśli wszystkie wartości w krotkach są niepodzielne. Jak można zauważyć tabela "próbki" spełnia ten warunek, a więc można od razu przyjrzeć się drugiej postaci normalnej (2NF). Schemat relacji jest w 2NF wtedy i tylko wtedy, gdy jest w 1NF, a każdy atrybut wtórny jest w pełni zależny funkcyjnie od klucza relacji. W schemacie relacji występuje zależność funkcyjna (FD) między zbiorami atrybutów X i Y, co zapisujemy następująco: X -> Y, jeśli dla każdych dwóch krotek t1 i t2 z tej relacji prawdą jest, że jeśli t1[X] = t2[X] to t1[Y] = t2[Y]. W przypadku tabeli "próbki" możemy wyróżnić następujące zależności funkcyjne:


  1. id, data -> wykop

  2. id,data-> symbol

  3. id,data,symbol -> typ

  4. id,data,symbol -> wynik

  5. symbol -> wynik

  6. symbol -> typ

  7. symbol -> instytucja

  8. symbol -> ekspert

  9. ekspert -> instytucja


Pełną zależnością funkcyjną nazywamy taką FD, że jeśli X -> Y to nie istnieje taki zbiór X' zawierający się w X, że X' -> Y. Jak można zauważyć wśród powyżej wymienionych zależności nie ma takiej, w której atrybut wtórny zależałby w pełni od klucza relacji, którym przypomnijmy jest zbiór "id, data, symbol". Warunek ten spełniałyby jedynie 4. i 5. gdyby nie to, że istnieje także FD tylko między nimi a atrybutem "symbol".

Wobec tego należy rozdzielić relację "próbki" na następujące: próbki(id, data, wykop) i analizy(symbol, typ, wynik, instytucja, ekspert, id, data). Należy zauważyć, że dokonanie takiego podziału nie skutkuje utratą informacji, gdyż chcąc wyszukać wyniki analizy dla danej próbki, wystarczy znajomość jej identyfikatora (numeru inwentarzowego) oraz datę jej pobrania. Przeglądając relację "analizy" pod kątem tych kryteriów otrzymamy zbiór krotek (może być pusty) zawierających dane o ekspertyzach wykonanych na próbkach. W ujęciu algebry zbiorów warunek zachowania informacji po dekompozycji można ująć następująco: jeśli rozdzielamy relację R na relacje R1 i R2, to ich iloczyn tych zbiorów krotek musi być równy R.

Analizując relacje utworzone po dekompozycji można zauważyć, że nie zostały wyeliminowane wszystkie anomalie, które występowały wcześniej. Chcąc zmienić dane o miejscu pracy Zielskiego trzeba zaktualizować 4 krotki, zamiast jednej, jak należałoby oczekiwać. Wynika to z faktu, że relacja analizy(symbol, typ, wynik, instytucja, ekspert, id, data) nie spełnia warunku pozostawania w trzeciej postaci normalnej (3NF). Oznacza to, że istnieją w jej schemacie atrybuty wtórne, które są przechodnio zależne od klucza relacji. Dowodem takiego stwierdzenia mogą być zależności funkcyjne 8. i 9. Atrybut "instytucja" jest funkcyjnie zależny od atrybutu "ekspert", który z kolei jest funkcyjnie zależny od klucza relacji "symbol". Z powyższego i definicji relacji przechodniej, która brzmi: X -> Z ^ Z -> Y => X -> Y wynika, że atrybut "instytucja" jest przechodnio zależny od klucza relacji. . Panaceum, które pozwoli wyeliminować tą własność relacji "analizy" jest jej ponowna dekompozycja na następujące tabele: analizy((symbol, typ, wynik, ekspert, id, data), eksperci(ekspert, instytucja). Jeśli zostaniemy zmuszeni zmodyfikować miejsce i adres pracy osoby o nazwisku "Zielski" operacji nie będzie trzeba dokonywać w 4 krotkach, a tylko jednej.

Mimo, że teoria SZBD wyróżnia 5 postaci normalnych, w praktyce uznaje się, że schematy w 3 NF, poza nielicznymi przypadkami, są schematami poprawnymi. Doprowadzenie do takiej postaci jest gwarancją, że informacje zgromadzone w bazie danych pozostaną poprawne i spójne.


4. Implementacja

Ostatnim etapem na drodze do uzyskania działającej bazy danych jest implementacja utworzonego schematu w wybranym SZBD. Dokonuje się tego, wprowadzając polecenia utworzenia relacji (tabeli) oraz wstawienia do niej kolejnych krotek, lub pojedynczych wartości. W trakcie użytkowania bazy danych można ponadto korzystać z funkcji aktualizacji danych, przeszukiwania relacji pod kątem wybranych kryteriów, czy usuwania poszczególnych rekordów z tabeli. Celem ich realizacji zdefiniowano w ramach standardu Amerykańskiego Instytutu Standardów (ANSI) język SQL, który określa gramatykę i semantykę poleceń służących zarządzaniu bazą danych. W rozdziale tym zostaną omówione podstawy ANSI SQL w stopniu, który po pierwsze pozwoli na utworzenie bazy danych i jej eksploatacja, a po drugie będzie dobrą podstawą do dalszego pogłębiania wiedzy na ten temat.

ANSI SQL należy do rodziny tak zwanych języków deklaratywnych. Oznacza to, że osoba programująca bazę danych wprowadzając polecenia, które są jego elementem deklaruje oczekiwanie, co do wyniku jego wykonania. Nie jest więc wymagana szczegółowa znajomość np. struktur fizycznych, w których składowane są dane, czy mechanizmów dostępu do nich. Ponieważ ww. standard został zaimplementowanych w całości w większości komercyjnych i bezpłatnych SZBD, bez względu na wybór oprogramowania, implementacja w wybranym nie powinna stanowić problemu.

Pierwszym zadaniem, które należy zrealizować jest oczywiście utworzenie relacji (tabel) zgodnie z modelem schematu bazy danych, który został wykonany w trakcie projektowania struktury. Służy do tego polecenie CREATE TABLE (wielkość liter jest nie istotna). Ma ono następującą postać (w wersji podstawowej):

CREATE TABLE nazwa_tabeli (nazwa_atrybuty typ (rozmiar) [DEFAULT wartość_domyślna] [ograniczenie_integralnościowe], nazwa_atrybutu typ (rozmiar) [DEFAULT wartość_domyślna] [ograniczenia_integralnościowe], ... )

Po poleceniu CREATE TABLE wprowadzana jest unikalna (w całej bazie danych) nazwa tabeli, a następnie w nawiasach okrągłych nazwy atrybutów i ich własności. Obowiązkowe jest podanie jedynie typu danych, które ma reprezentować atrybut oraz jego rozmiar, na przykład INTEGER - liczba całkowita, NUMERIC (p,s) - typ zmiennoprzecinkowy, gdzie p oznacza liczbę cyfr, a s - rozmiar części ułamkowej. Np w polu o atrybucie NUMERIC(3,2) można zapisać liczbę 3,1 lub 4,32, ale już nie 5,678, gdyż część ułamkowa zawiera trzy cyfry, zamiast maksymalnie dwóch jak to zostało zadeklarowane. Ponadto warto pamiętać o typach łańcuchowych, które służą do definiowania atrybutów, w których mają być przechowywane ciągi znaków. Np. CHAR (n) - łańcuchy o stałej długości n, CHAR VARYING (n) - łańcuchy nie dłuższe niż n. Typ atrybutu, w którym powinna być przechowywana data być zdeklarowany słowem DATE.

Opcjonalnie po typie atrybutu może nastąpić definicja wartości domyślnej (poprzedzana słowem kluczowym DEFAULT), którą będzie przyjmował, jeśli nie zostanie wstawiona inna oraz ograniczenia klucza obcego - FOREIGN KEY, podstawowego - PRIMARY KEY, unikalności UNIQUE i zawężenia dziedziny. Ostatnie wprowadza się słowem kluczowym CHECK, po którym następuje deklaracja zakresu. Np. jeśli chcemy, by atrybut "liczba" przyjmował wartości mniejsze od 100 wpisujemy "CHECK liczba < 100". Poszczególne atrybuty i ich wartości oddziela się przecinkami. Następujące polecenia utworzą przykładowe relacje z poprzedniego rozdziału:

  1. CREATE TABLE sezony (id CHAR VARYING(5) PRIMARY KEY, data_rozpoczecia DATE NOT NULL, data_zakonczenia DATE NOT NULL, kierownik CHAR VARYING (20) NOT NULL, CHECK data_zakonczenia > data_rozpoczecia)


  1. CREATE TABLE wykopy (id CHAR VARYING (5) PRIMARY KEY, szerokosc NUMERIC(4,1) CHECK szerokosc > 0 NOT NULL, dlugosc NUMERIC(4,1) CHECK dlugosc > 0 NOT NULL, glebokosc NUMERIC(4,1) CHECK glebokosc > 0, sezon CHAR VARYING (5), FOREIGN KEY (sezon) REFERENCES sezony (id))


  1. CREATE TABLE obiekty (id CHAR VARYING (5) PRIMARY KEY, rysunek CHAR VARYING (6) NOT NULL, wydzielone CHAR (1) CHECK (wydzielone IN ('T', 'N'), funkcja CHAR VARYING (40), wykop CHAR VARYING (5), FOREIGN KEY (wykop) REFERENCES wykopy(id) )


  1. CREATE TABLE warstwy (id CHAR VARYING (5) PRIMARY KEY, rysunek CHAR VARYING (6) NOT NULL, wydzielone CHAR (1) CHECK (wydzielone IN ('T', 'N')), wykop CHAR VARYING (5), FOREIGN KEY (wykop) REFERENCES wykopy(id) )

  2. CREATE TABLE rysunki (id CHAR VARYING (5) PRIMARY KEY, rysownik CHAR VARYING (20), data DATE NOT NULL, obiekt CHAR VARYING (5), warstwa CHAR VARYING (5), FOREIGN KEY obiekt NULL REFERENCES obiekty(id), FOREIGN KEY warstwa NULL REFERENCES warstwy(id))


  1. CREATE TABLE probki (id CHAR VARYING (5), data DATE, wykop CHAR VARYING (5), PRIMARY KEY (id, data), FOREING KEY (wykop) REFERENCES wykopy(id))


  1. CREATE TABLE analizy (symbol CHAR VARYING (10) PRIMARY KEY, typ CHAR VARYING (15), wynik CHAR VARYING (50), ekspert CHAR VARYING (20), id CHAR VARYING (5), data DATE, FOREIGN KEY (id, data) REFERENCES probki(id,data), FOREIGN KEY (ekspert) REFERENCES eksperci(nazwisko)


  1. CREATAE TABLE eksperci (nazwisko CHAR VARYING (20) PRIMARY KEY, instytucja CHAR VARYING (25))


Stosując powyższe polecenia, w bazie danych zostanie utworzone osiem tabel, gdyż przewidywana na etapie modelu encji-związków relacja "próbki", po normalizacji została rozbita na trzy mniejsze. Atrybutom, na które zostało nałożone wymaganie, by nie przyjmowały wartości pustych (w modelu encji-związków oznacza się to gwiazdką) towarzyszy słowo kluczowe NOT NULL. Analizując przedstawione polecenia można zauważyć, że ograniczenia integralnościowe nie w każdym przypadku występują bezpośrednio po deklaracji nazwy i typu wartości atrybutu. Pozwala na to gramatyka języka SQL, a w sytuacji, gdy ograniczenie dotyczy więcej niż jednego atrybutu relacji, taka konstrukcja polecenia jest obowiązkowa. Ponadto warto zwrócić uwagę na to, jak deklarowany jest klucz obcy. Po słowie kluczowym FOREIGN KEY w nawiasach podaje się nazwę (-y) atrybutu (-ów), które są wskaźnikiem na klucz podstawowy innej relacji, który wstawia się po słowie REFERENCES.

Po utworzeniu relacji w bazie danych możliwe jest wstawianie do nich nowych krotek. Używa się do tego polecenia INSERT, którego składnia jest następująca:


INSERT INTO nazwa_tabeli [(atrybut1, atrybut2,..., atrybutn)] VALUES (wartość1, wartość2,... ,wartośćn)


Lista atrybutów (atrybut1, atrybut2,.... , atrybutn) może zostać pominięta, o ile wstawiamy do tabeli tyle wartości, ile atrybutów zostało zdeklarowanych w trakcie jej tworzenia. Na przykład chcąc umieścić w relacji "eksperci" o miejscu pracy Mazura wystarczy wprowadzić polecenie INSERT INTO eksperci VALUES ('Mazur', 'UW'). Natomiast w przypadku Zielskiego, który nigdzie nie jest zatrudniony wprowadzimy je w następującej postaci: INSERT INTO eksperci (nazwisko) VALUES ('Zielski'). Przy tym należy pamiętać, że ciąg znaków rozpoczyna się i kończy apostrofem.

Do modyfikowania danych, które już znajdują się w tabeli stosuje się polecenie UPDATE w następującej konwencji:


UPDATE nazwa_tabeli SET atrybut1 = wartość1, atrybut2 = wartość2, [...] [WHERE warunek]


Atrybutom, w tych krotkach dla których prawdziwy jest warunek zadeklarowany po słowie kluczowym WHERE przypisuje się nowe wartości. Oczywiście jeśli żaden warunek nie zostanie umieszczony w poleceniu, operacja zostanie wykonana dla wszystkich wierszy tabeli. Jeśli ekspert Zielski zacznie pracować na Uniwersytecie Gdańskim, to wstawimy tą informację do relacji "eksperci" poleceniem UPDATE instytucja = 'UJ' WHERE nazwisko = 'Zielski'.

Na koniec można wspomnieć jeszcze o poleceniu selekcji SELECT, które używane jest do poszukiwania krotek, które spełniają określone warunki. Jego składnia jest następująca:


SELECT atrybut1, atrybut2,... FROM nazwa_tabeli [WHERE warunek]


Ponieważ w artykule skupiam się przede wszystkim na niektórych zagadnieniach związanych z problematyką tworzenia bazy danych, nie będę szczegółowo omawiał polecenia wyboru krotek, a jedynie wskażę najbardziej elementarne przykłady zapytań do bazy danych.

SELECT * FROM probki

SELECT symbol, wynik, ekspert FROM analizy

SELECT * FROM analizy WHERE ekspert = 'Mazur'

SELECT p.wykop, a.symbol FROM probki p, analizy a WHERE p.id = a.id and p.data = a.data and a.


Składnia polecenia SELECT jest bardzo rozbudowana, ze względu na liczbę różnorodnych funkcji (często uzależnionych od wykorzystywanego SZBD), które pozwalają na szybsze uzyskiwanie satysfakcjonujących wyników, możliwości sortowania i grupowania wyników według zadanych kryteriów i operatorów, które można zastosować po słowie kluczowym WHERE. Zainteresowani tym czytelnicy powinni sięgnąć do literatury, która została wymieniona na końcu artykułu, bądź skorzystać z zasobów sieci WWW.

Na omówieniu polecenia wyboru krotek kończy się rozdział poświęcony implementacji schematu bazy danych w SZBD. Na podstawie prostej specyfikacji wymagań udało się utworzyć poprawną bazę danych, w której gromadzić można wybrane informacje w celu ich dalszej eksploatacji.


5. Podsumowanie


Prezentowany wycinek problematyki związanej z systemami zarządzania bazami danych dotyczył przede wszystkim tworzenia baz danych oraz ich utrzymywania (zapewniania poprawności i spójności danych). Osobnym tematem, który zasługiwałby na oddzielne potraktowanie, jest efektywne wykorzystywanie narzędzi tego typu w badaniach archeologicznych. Celem artykułu było zaprezentowanie metodyki tworzenia poprawnych schematów relacji, w których gromadzone są informacje, tak by SZBD mógł kontrolować ich poprawność. Trzeba przy tym podkreślić, że prawidłowe zaprojektowanie bazy danych jest i jej implementacja jest środkiem do wykorzystania możliwości, które płyną z ich wykorzystywania.

Chociaż zagadnienia związane z tworzeniem bazy danych nie są trywialne, warto mieć je na względzie w przypadku, gdy zajdzie potrzeba gromadzenia większych ilości danych.


Literatura


Kurnatowski S., M. Kobusiewicz, Osiągnięcia i zaniedbania w polskiej archeologii i prahistorii ostatniego półwiecza, [w:] Kurnatowski S., M. Kobusiewicz (red.), Archeologia i prahistoria polska w ostatnim półwieczu, 581-662. Poznań.


http://wazniak.mimuw.edu.pl/index.php?title=Bazy_danych


Ullman J. D., J. Widom, Podstawowy wykład z systemów baz danych, Warszawa.


Ten utwór objęty jest licencją Creative Commons Uznanie autorstwa-Użycie niekomercyjne-Na tych samych warunkach 2.5 Polska. Aby zobaczyć kopię niniejszej licencji przejdź na stronę http://creativecommons.org/licenses/by-nc-sa/2.5/pl/ lub napisz do Creative Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.