Projektowanie logicznego modelu bazy danych - uwagi praktyczne

Pełen tekst

(1)Zeszyty Naukowe nr. 770. Uniwersytetu Ekonomicznego w Krakowie. 2009. Dariusz Put Katedra Systemów Obliczeniowych. Piotr Soja Katedra Informatyki. Projektowanie logicznego modelu bazy danych – uwagi praktyczne Streszczenie. Utworzenie właściwego projektu logicznego bazy danych ma kluczowe znaczenie z punktu widzenia poprawności działania całego systemu informatycznego. W artykule omówiono niektóre praktyczne problemy pojawiające się w procesie projekto wania bazy danych. Zwrócono m.in. uwagę na konieczność identyfikacji faktów i sposób ich reprezentacji w bazie danych, ustalenie zasad nazewnictwa obiektów, metody eliminacji niepożądanych pól, celowość podjęcia działań dla zapewnienia integralności danych oraz zasadność weryfikacji projektu pod kątem funkcjonalności. Uwzględnienie w praktyce omówionych zagadnień przyczyni się do stworzenia poprawnego projektu logicznego bazy danych i w konsekwencji pozwoli na uniknięcie różnorodnych anomalii i błędów podczas eksploatacji systemu. Słowa kluczowe: baza danych, klucz podstawowy, projektowanie bazy danych, reguły integralności, relacja, rodzaje tabel, typ pola.. 1. Wstęp W teorii relacyjnych baz danych wyróżnia się sześć postaci normalnych. W procesie projektowania dąży się do tego, aby w każdym kolejnym stadium projektu baza danych była w wyższej postaci normalnej. Dla zrozumienia teorii normalizacji wymagana jest znajomość wielu zagadnień związanych z rachunkiem relacyjnym i algebrą relacyjną, m.in.: pojęcia zależności funkcyjnej, zależności trywialnej i nietrywialnej, zagadnienia rozkładu bezstratnego. Tymczasem z praktyk i wynika, że można stworzyć w pełni funkcjonalną, znormalizowaną bazę danych, nie kierując się bezpośrednio zasadami normalizacji. W artykule.

(2) 238. Dariusz Put, Piotr Soja. zwrócono uwagę na niektóre praktyczne problemy tworzenia baz danych oraz zaproponowano sposoby postępowania prowadzące do ich rozwiązania. Podstawą rozważań jest algorytm projektowania bazy danych. 2. Projektowanie bazy danych 2.1. Identyfikacja faktów, stworzenie tabel i ustalenie atrybutów. Proces projektowania bazy danych składa się z kilku etapów. W toku postępowania budowany jest projekt pojęciowy, następnie logiczny i fizyczny (por. np.: [Date 2000], [Todman 2003]). Tworzy się tabele, ustala dziedziny i typy występujących w nich atrybutów, buduje relacje, a informacji dla poprawnego zdefiniowania tych elementów dostarcza analiza systemu. Dąży się do tego, aby końcowa wersja bazy danych była adekwatna do projektowanej rzeczywistości i umożliwiała wykonywanie wszystkich niezbędnych operacji, a więc rejestrowanie faktów, ich modyfikację, usuwanie oraz wyszukiwanie. Pierwszy etap procesu projektowania logicznego modelu bazy danych (rys. 1) polega na zidentyfikowaniu typów (klas) faktów, czyli zdefiniowaniu obiektów i zdarzeń, o których mają być przechowywane dane oraz zbioru charakteryzu jących je atrybutów. Fakty są identyfikowane na podstawie przeprowadzonej analizy systemu, która obejmuje między innymi prowadzenie wywiadów z przyszłymi użytkownikami, rozpoznanie schematu organizacyjnego, analizę istniejącej bazy spadkowej. Etap ten powinien doprowadzić do powstania listy tabel wraz z atrybutami charakteryzującymi fakty, które będą w nich przechowywane, przy czym każda tabela ma odpowiadać jednemu obiektowi lub zdarzeniu. Na etapie definiowania tabel korzystne jest rozstrzygnięcie, które z nich będą stanowiły swoisty interfejs bazy danych i będą wykorzystywane przez zewnętrzne aplikacje (takie jak np. generatory raportów), które zaś będą tzw. tabelami wewnętrznymi, niedostępnymi dla projektowanych później aplikacji. Uzasadnienie dla takiego rozróżnienia można znaleźć w podejściu stosowanym w technologii obiektowej, a szczególnie w jednym z jej kluczowych zagadnień, które polega na rozdzieleniu interfejsu od implementacji (por. np. [Jacobson i in. 1995], [Mattison 1994], [Soja 1999]). Takie rozdzielenie jest wskazane, gdyż nie można założyć, że struktura bazy danych będzie niezmienna w całym okresie jej eksploatacji. Tabele stanowiące interfejs powinny podlegać minimalnym zmianom podczas użytkowania bazy danych, co zapobiegnie czasochłonnym operacjom przebudowywania opartych na nich aplikacji i raportów. Zmiany dokonane na tabelach oznaczonych jako wewnętrzne będą mniej kłopotliwe, gdyż nie pociągają za sobą konieczności modyfikacji aplikacji..

(3) Projektowanie logicznego modelu bazy…. 239. Start. Utwórz tabele i zdefiniuj atrybuty Ustal zasady nazewnictwa Wyeliminuj niepożądane pola Utwórz tabele-podzbiory i tabele walidacji Zdefiniuj klucze podstawowe Utwórz relacje. T. Baza danych funkcjonalna. N. Ustal typy pól Ustaw reguły integralności Stop. Rys. 1. Algorytm projektowania bazy danych Źródło: opracowanie własne.. 2.2. Ustalenie zasad nazewnictwa obiektów. Kolejny etap obejmuje ustalenie zasad nazewnictwa oraz nadanie utworzonym tabelom i atrybutom ostatecznych nazw. Przyjęło się, aby nazwy tabel – o ile to możliwe – były tworzone w mianowniku liczby mnogiej, a nazwy atrybutów w mianowniku liczby pojedynczej. Należy także przyjąć i konsekwentnie stosować jedną z metod tworzenia nazw składających się z więcej niż jednego wyrazu..

(4) Dariusz Put, Piotr Soja. 240. Ułatwi to pracę w kolejnych etapach procesu projektowania, a szczególnie tworzenie aplikacji bazodanowej. Identyfikatory są zwykle tworzone na jeden z trzech sposobów: – ze spacją między poszczególnymi wyrazami (data zatrudnienia, nazwisko pracownika)1, – łącznie, z wyróżnieniem każdego wyrazu wielką literą (DataZatrudnienia, NazwiskoPracownika), – z separatorem (najczęściej znakiem podkreślenia) między poszczególnymi wyrazami (data_zatrudnienia, nazwisko_pracownika). Zaleca się, aby atrybutom nadawać nazwy znaczące (np. data_zatrudnienia, a nie data), ale niezbyt długie. 2.3. Usunięcie niepożądanych pól. Baza danych powinna przechowywać wyłącznie wartości skalarne2. W przeciwnym wypadku podczas jej eksploatacji wystąpi wiele problemów związanych z wyszukiwaniem danych, aktualizacją, aktualnością, usuwaniem, a także z możliwością występowania niepożądanej nadmiarowości. Z projektu należy więc wyeliminować pola zawierające więcej niż jeden typ wartości (tzw. pola segmentowe), wiele wartości tego samego rodzaju (pola wielowartościowe) oraz pola będące wynikiem operacji matematycznej lub konkatenacji na wartościach innych pól (pola wyliczane). Przykładem pola segmentowego jest adres składający się z ulicy (wraz z numerem)3, kodu pocztowego oraz miejscowości i w bazie danych powinien być reprezentowany przez trzy pola. Pole wyliczane to na przykład wartość liczona jako cena × ilość. W bazie danych należy przechowywać cenę i ilość, a wartość usunąć z projektu bez podejmowania dodatkowej akcji. Innym przykładem jest wiek będący różnicą między datą bieżącą a datą urodzenia. Istnienie pola wiek przechowującego aktualny wiek osób, o których dane są przechowywane w tabeli stwarza problemy aktualizacyjne. Znacznie wygodniej jest przechowywać niezmienną datę urodzenia, a w razie konieczności obliczyć wiek, tworząc pole wyliczane. Eliminacja pól wielowartościowych wiąże się z koniecznością utworzenia dodatkowej tabeli zawierającej wszystkie dopuszczalne wartości oraz relacji wiele-do-wielu między tą tabelą a tabelą faktów. Na tym etapie projektu pola wielowartościowe należy zastąpić tabelą zawierającą tylko jeden atrybut. Zostaną do niej wpisane wszystkie dopuszczalne wartości, które będą mogły się pojawić w usuwanym polu Nie wszystkie systemy bazodanowe pozwalają na tworzenie identyfikatorów zawierających spację. 1. Jest to warunek występowania bazy danych w pierwszej postaci normalnej.. 2. Niekiedy celowe jest utworzenie oddzielnych pól dla numeru domu i lokalu.. 3.

(5) Projektowanie logicznego modelu bazy…. 241. wielowartościowym. Docelowo – w jednym z dalszych etapów projektu – między tą tabelą a tabelą faktów zostanie utworzona relacja wiele-do-wielu. Proces eliminacji niepożądanych pól powinien więc polegać na: – zastąpieniu pól segmentowych taką liczbą atrybutów, ile segmentów można wyróżnić w usuwanym polu, – usunięciu pól wyliczanych z zachowaniem możliwości obliczenia przechowywanych w nich wartości, co może się wiązać z koniecznością utworzenia dodatkowego pola (pól) zawierającego wartości niezmienne lub niestwarzające problemów aktualizacji, – usunięciu pól wielowartościowych i zastąpieniu ich dodatkową tabelą z jednym atrybutem. Tabela 1. Rodzaje pól złożonych i metody ich eliminacji Rodzaj pola. Zawartość. Metoda eliminacji. Segmentowe. Kilka wartości różnego typu. Podział na tyle atrybutów, ile segmentów znajduje się w polu. Wielowartościowe. Kilka wartości tego samego rodzaju. Wyliczane. Wynik operacji matematycznej Usunięcie, pozostawienie lub konkatenacji na wartowartości pierwotnych umożliściach pierwotnych wiających wyliczenie. Utworzenie tabeli jednoatrybutowej, a docelowo relacji wiele-do-wielu. Źródło: opracowanie własne.. 2.4. Utworzenie tabel podzbiorów i tabel walidacji. Wszystkie tabele w relacyjnej bazie danych zawierają dane, niemniej jednak pod względem spełnianych funkcji w systemie, w teorii baz danych wyróżnia się kilka rodzajów tabel: – tabele zawierające dane o obiektach i zdarzeniach. Są to najczęściej występujące tabele w bazach danych. Przechowują dane o rejestrowanych faktach; –tabele-podzbiory. Zawierają dane opisujące temat innej tabeli w bardziej szczegółowy sposób; – tabele walidacji (słownikowe). Umieszcza się w nich wszystkie dopuszczalne wartości, które można umieścić w polu innej tabeli. Czasem tabele słownikowe zawierają dodatkowe atrybuty; – tabele łączące. Służą do tworzenia relacji wiele-do-wielu. Dla zapewnienia funkcjonalności bazy danych wymagane jest niekiedy umieszczenie w nich dodatkowych atrybutów..

(6) 242. Dariusz Put, Piotr Soja. Wynikiem omówionych dotychczas etapów projektowania jest lista tabel zawierających dane o wszystkich faktach oraz tabel jednoatrybutowych powstałych w wyniku eliminacji pól wielowartościowych. W toku dalszej analizy należy rozważyć utworzenie tabel podzbiorów oraz tabel walidacji. Niektóre obiekty lub zdarzenia rejestrowane w tej samej tabeli mogą być charakter yzowane przez różną liczbę atrybutów. Zwykle oznacza to, że część obiektów jest opisywana przez dodatkowe atrybuty, które nie występują dla innych. Można wskazać wiele takich sytuacji, m.in.: – pracownicy i wykładowcy: wykładowca jest pracownikiem, ale nie każdy pracownik jest wykładowcą. Oznacza to, że o wykładowcach należy przechowywać dodatkowe dane, które są charakterystyczne tylko dla nich; – mecze i mecze mistrzowskie. Mecze mistrzowskie są pojęciem bardziej szczegółowym i mogą wymagać rejestracji dodatkowych atrybutów, które nie istnieją dla meczy; – pojazdy i samochody. Samochody są pojazdami, ale nie każdy pojazd jest samochodem. Opisywana sytuacja może być rozwiązana dwojako. Poprzez utworzenie jednej tabeli i zgodę na występowanie wartości pustych w wypadku tych obiektów, które są opisywane przez mniejszą liczbę atrybutów lub utworzenie dwóch tabel: jednej zawierającej atrybuty charakteryzujące wszystkie obiekty (wszystkich pracowników, wszystkie mecze, wszystkie pojazdy) i tabeli-podzbioru zawierającej dodatkowe dane (opisujące wykładowców, mecze mistrzowskie, samochody). Dane o obiektach opisywanych przez mniejszą liczbę atrybutów będą wtedy rejestrowane w jednej tabeli, a o tych charakteryzowanych przez wszystkie atrybuty w obydwu. Żadne z tych rozwiązań nie jest jednoznacznie lepsze od drugiego. Z jednej bowiem strony w bazach danych należy unikać atrybutów, co do których istnieje uzasadnione podejrzenie, że dla wielu rekordów będą przyjmować wartość pustą (Null), gdyż takie rozwiązanie stwarza wiele problemów (por. np.: [Date 2000, s. 151–157]). Z drugiej strony, jeśli projektowane tabele będą zawierać wiele rekordów, często wykonywana będzie operacja wyszukiwania oraz baza danych będzie współużytkowana przez licznych użytkowników, wąskim gardłem całego systemu może być wyszukiwanie danych i wtedy pierwsze rozwiązanie może okazać się bardziej efektywne (por. np.: [Put 2004]). Decyzja w tym względzie powinna być więc podjęta na podstawie analizy przyszłego funkcjonowania systemu w omawianym zakresie. Dla niektórych pól w bazie danych celowe jest zdefiniowanie tabel walidacji. Tworzy się je dla tych atrybutów, które zawierają skończony, nieciągły zbiór powtarzających się wartości. Pozwala to na zachowanie integralności bazy danych i utrudnia lub nawet uniemożliwia rejestrację tej samej wartości na dwa lub więcej sposobów. Przykładem może tu być tabela zawierająca nazwy wszystkich państw,.

(7) Projektowanie logicznego modelu bazy…. 243. które są częścią adresu i są zapisywane w polu kraj innej tabeli. Tabela walidacji ułatwia umieszczanie poprawnych danych w tym polu, zawierając jednoznaczne wartości. Pewnym odpowiednikiem tabel walidacji są reguły poprawności: każdą tabelę słownikową można zastąpić zbiorem dopuszczalnych wartości i zapisać jako regułę poprawności. Takie rozwiązanie ma jednak zasadniczą wadę: gdy wystąpi konieczność dokonania zmiany w zbiorze wartości dopuszczalnych, trzeba będzie zmodyfikować projekt fizyczny bazy danych, co jest trudniejsze w implementacji niż zmiana zawartości tabeli walidacji. Reguły poprawności tworzy się wyłącznie wtedy, gdy jest niemal pewne, że zbiór dopuszczalnych wartości nie ulegnie zmianie podczas eksploatacji bazy danych (np. płeć). W każdym innym wypadku lepszym rozwiązaniem jest tabela walidacji. Reguły poprawności znajdują także zastosowanie wszędzie tam, gdzie zbiór dopuszczalnych wartości jest ciągły (np. przedział liczbowy). 2.5. Wybór kluczy podstawowych. Ten etap projektowania powinien doprowadzić do wybrania lub utworzenia w każdej tabeli klucza podstawowego. Niektóre tabele mogą mieć wiele kluczy kandydujących4, dla innych wystąpi potrzeba utworzenia kluczy sztucznych. W zakresie tworzenia kluczy podstawowych należy stosować następujące zasady: – wybierając klucz podstawowy spośród kluczy kandydujących należy wskazać pole, którego wartość będzie niezmienna lub będzie się zmieniać najrzadziej oraz w którym wartość będzie istnieć dla każdego rekordu w chwili rejestracji nowego faktu w bazie danych, – przy braku jednopolowego klucza kandydującego lepiej utworzyć klucz sztuczny, niż wielopolowy; zasada ta odnosi się do tabel z danymi – istnieją bowiem takie sytuacje, w któr ych utworzenie wielopolowego klucza podstawowego jest zalecane, gdyż ułatwia zachowanie integralności bazy danych i nie dopuszcza do rejestrowania danych zwielok rotnionych (np. tabele łączące w relacjach wiele-do-wielu mają wielopolowy klucz podstawowy), – kluczem podstawowym w tabeli walidacji jest jedyne występujące w niej pole, – kluczem podstawowym w tabeli-podzbiorze jest pole przechowujące tę samą wartość, co klucz podstawowy tabeli macierzystej.. 4 Klucz kandydujący to pole, które może pełnić rolę klucza podstawowego. Klucz podstawowy to taki klucz kandydujący, który będzie wskazany jako primary key w projekcie fizycznym bazy danych..

(8) 244. Dariusz Put, Piotr Soja. 2.6. Zdefiniowanie relacji. Etap ten polega na utworzeniu relacji, czyli związków między tabelami. Projektując połączenia, należy kierować się wynikami analizy systemu. Pomocny będzie tu także diagram związków encji powstały na etapie analizy systemu i będący elementem logicznego projektu bazy danych. W zakresie tworzenia połączeń między tabelami trudno wskazać jakieś ogólnie obowiązujące reguły, gdyż schemat bazy danych w tym zakresie zależy od powiązań między rejestrowanymi w niej danymi. Można jednak zwrócić uwagę, że: – tabela walidacji jest połączona z tabelą macierzystą relacją jeden-do-wielu nad jedynym (zwykle) polem w niej występującym. Tabela walidacji jest w tym związku tabelą podstawową; – tabele-podzbiory są połączone z tabelami macierzystymi. Kluczem obcym jest klucz podstawowy tabeli-podzbioru. Jest to więc zawsze relacja typu jedendo-jednego; – tabele powstałe w wyniku likwidacji pól wielowartościowych są połączone z tabelami macierzystymi relacją wiele-do-wielu. Ten typ relacji wymaga utworzenia tabeli łączącej, która ma wielopolowy (zwykle dwupolowy) klucz podstawowy, w którego skład wchodzą klucze podstawowe obydwu tabel biorących udział w relacji. Po utworzeniu relacji i wskazaniu ich typów należy ustalić pozostałe atrybuty relacji, do których zalicza się reguły usuwania i modyfikacji rekordów oraz stopień uczestnictwa tabel w relacji. 2.7. Weryfikacja bazy danych pod kątem funkcjonalności. Po utworzeniu tabel i relacji należy dokonać weryfikacji bazy danych pod kątem jej funkcjonalności, czyli możliwości sprawnego i bezbłędnego rejestrowania, usuwania i modyfikacji danych o obiektach i zdarzeniach, które mają być w niej przechowywane. Operacja ta polega na przeanalizowaniu, czy wszystko to, co ma być zapisane w bazie danych da się w niej zapisać oraz do których tabel należy dodawać rekordy, gdy operacja rejestracji faktu wymaga wpisania danych do większej liczby tabel. Szczególną uwagę należy zwrócić na relacje wiele-do-wielu. Ich utworzenie może bowiem w niektórych wypadkach wręcz uniemożliwić sprawne funkcjonowanie bazy danych. Problem taki rozwiązuje się zwykle przenosząc do tabeli łączącej niektóre pola z tabel połączonych relacją wiele‑do‑wielu. Dokonując analizy funkcjonalności, należy także zwrócić uwagę, czy rejestracja jednego faktu nie wymaga wielokrotnego wpisywania do bazy danych tych samych wartości. Jeśli przeprowadzona analiza wykaże błędy w projekcie, kon ieczny będzie powrót do etapu tworzenia tabel walidacji lub (i) tabel-podzbiorów albo nawet na.

(9) Projektowanie logicznego modelu bazy…. 245. początek projektu, jeśli wymagana będzie weryfikacja istniejących tabel i atrybutów. 2.8. Ustalenie typów pól. Na tym etapie projektu zdefiniowane są wszystkie tabele tworzące bazę danych oraz występujące w nich atrybuty. Można więc przystąpić do ustalania typów pól. Zwykle większość atrybutów nie stwarza problemów: nazwisko jest polem tekstowym, każda data jest typu daty, cena, to liczba rzeczywista5. Typy niektórych pól nie są jednak oczywiste. Na przykład PESEL może być zarówno liczbą całkowitą, jak i tekstem o długości 11 znaków, płeć może być oznaczana na wiele sposobów: jako pole logiczne, w którym jedna wartość oznacza kobietę, druga mężczyznę, pole tekstowe o długości 1, przyjmujące wartość k lub m albo pole tekstowe, w którym będzie można zapisać dłuższy tekst (mężczyzna lub kobieta). Ustalając typy pól, co do których istnieją wątpliwości, należy kierować się następującymi zasadami: – sztuczne klucze podstawowe powinny być autonumerowane, dzięki czemu projektując aplikację bazodanową, nie trzeba będzie zwracać uwagi na problem istnienia wartości w polu będącym kluczem podstawowym oraz na unikalność tych wartości, – klucze obce połączone z polami autonumerowanymi muszą być typu całkowitego i powinny mieć największy możliwy rozmiar dostępny w SZBD, – pole, które może być tekstowe i numeryczne, powinno być polem tekstowym, jeśli na wartościach w nim zapisywanych nie będą wykonywane operacje matematyczne (np.: PESEL powinien być polem tekstowym), – pola powinny mieć najmniejszy możliwy rozmiar – rozmiar niektórych pól nie budzi wątpliwości, gdyż będzie ustalany na podstawie specyfiki wartości w nich przechowywanych (kod pocztowy, PESEL, NIP), dla innych należy dobrać go na podstawie analizy przewidywanej długości przechowywanych w nich wartości (nazwisko, tytuł książki), – jeśli istotna jest szybkość działania bazy danych (tabele będą zawierały miliony rekordów oraz będą intensywnie współużytkowane), należy stosować pola o stałej długości kosztem zajmowania większej przestrzeni dyskowej (dotyczy pól tekstowych). Wszystkie pola przechowujące wartość tego samego rodzaju powinny być tego samego (lub zgodnego) typu i rozmiaru i mieć taką samą nazwę.. 5. Niektóre systemy posiadają typ walutowy, który de facto jest typem rzeczywistym..

(10) 246. Dariusz Put, Piotr Soja. 2.9. Reguły integralności. W teorii baz danych wyróżnia się następujące typy reguł integralności: – bazodanowe – mogą być wpisane w fizyczny projekt bazy danych, – aplikacyjne – dla ich zachowania niezbędne jest utworzenie procedury na etapie implementacji aplikacji bazodanowej. Bazodanowe reguły integralności dzielą się z kolei na: – reguły dotyczące pól i tabel, – reguły dotyczące relacji (tzw. integralność referencyjna). Odpowiednio ustawione reguły integralności zmniejszają ryzyko pojawienia się błędów i nieprawidłowości podczas eksploatacji bazy danych. Zadanie takie spełniają także opisane powyżej tabele walidacji ułatwiające utrzymanie jednoznaczności wartości wpisywanych do pola, którego dotyczą, klucze podstawowe wybrane w każdej tabeli bazy danych, czy odpowiednio dobrane typy i rozmiary pól. W zachowaniu integralności pomogą ponadto następujące mechanizmy: 1) wpisywane w arkusz specyfikacji poszczególnych atrybutów tabel bazy danych: – reguły poprawności – są ustalane dla poszczególnych pól występujących w tabelach bazy danych lub dla tabeli, gdy utworzenie odpowiedniej reguły wymaga użycia wartości występujących w więcej niż jednym polu tabeli bazy danych, – wymagalność – należy włączyć co najmniej dla tych pól, w których istnienie wartości jest niezbędne, aby dopisanie rekordu do tabeli bazy danych miało sens, – unikalność – ustawiana dla kluczy kandydujących, w których wartości nie będą mogły się powtarzać; 2) wpisywane w projekt logiczny bazy danych: – reguły usuwania rekordów dotyczą każdej relacji i mogą być kaskadowe, gdy usunięcie rekordu z tabeli podstawowej ma pociągać za sobą automatyczne usunięcie wszystkich powiązanych z nim rekordów z tabeli związanej lub restrykcyjne, gdy usunięcie rekordu z tabeli podstawowej będzie niemożliwe, gdy w tabeli związanej będą istniały związane z nim rekordy, – reguły modyfikacji rekordów także są ustawiane dla relacji i dotyczą możliwości modyfikacji wartości w polu biorącym udział w relacji po stronie tabeli podstawowej, gdy w tabeli związanej istnieją powiązane z nim rekordy, – stopień uczestnictwa tabel w relacji określający minimalną i maksymalną liczbę rekordów jednej tabeli, które mogą być powiązane z pojedynczym rekordem drugiej tabeli. Więzy integralności należy wpisać w logiczny projekt bazy danych będący częścią specyfikacji systemu. Na rys. 2 pokazano przykładowy fragment logicznego projektu bazy danych z wpisanymi regułami integralności. Oznaczono klucze podstawowe (KP), klucze obce (KO), reguły usuwania (R – restrykcyjna,.

(11) Projektowanie logicznego modelu bazy…. 247. K – kaskadowa) oraz stopień uczestnictwa w relacji tabeli Studenci z tabelą Studenci_Wykłady (wynoszący (5, 10)). Kraje. STUDENCI. Kraj KP (R). id_studenta KP … kraj KO …. (5, 10). (K). STUDENCI_WYKŁADY id_studenta KP, KO id_wykładu KP. Rys. 2. Fragment projektu logicznego bazy danych Źródło: opracowanie własne.. 3. Podsumowanie W literaturze można spotkać wiele szczegółowych opracowań dotyczących projektowania bazy danych. Na tle zaprezentowanego algorytmu, niemal nie różniącego się od podejścia tradycyjnego, zwrócono uwagę na niektóre praktyczne problemy oraz zaproponowano metody ich rozwiązania. Przestrzeganie zamieszczonych tu uwag praktycznych ułatwi stworzenie w pełni funkcjonalnej bazy danych, wolnej od anomalii, umożliwiającej zarówno sprawne tworzenia aplikacji dla użytkownika, w tym także zapytań wybierających, jak i bezbłędne rejestrowanie faktów w fazie eksploatacji. Literatura Begg C., Connolly T. [2004], Systemy baz danych. Praktyczne metody projektowania, implementacji i zarządzania, t. 1 i 2, RM, Warszawa. Beynon-Davies P. [2003], Systemy baz danych, WNT, Warszawa. Buneman P., Fan W., Weinstein S. [2003], Interaction between Path and Type Constraints, ACM Transactions on Computational Logic (TOCL) 4 (4). Date C.J. [1986], Relational Database: Selected Writings, Addison-Wesley. Date C.J. [2000], Wprowadzenie do systemów baz danych, WNT, Warszawa. Ferrandin M., de Camargo M.S. [2004], Referential Integrity Model for XML Data Integrated from Heterogeneous Databases Systems, Proceedings of ICEIS 2004, Porto. Fotache M. [2005], Database Designers and Normalization: Anathomy of a Divorce [w:] Business Information Systems, red. W. Abramowicz, Proceedings of BIS 2005, Poznań. Jacobson I., Ericsson M., Jacobson A. [1995], The Object Advantage. Business Process Reengineering with Object Technology, ACM Press Books..

(12) 248. Dariusz Put, Piotr Soja. Mattison, R. [1994], The Object-Oriented Enterprise: Making Corporate Information Systems Work, McGraw-Hill. Melton J., Simon A. [1993], Understanding the New SQL: A Complete Guide, Morgan Kauffman. Put D. [2007], Pierwsza postać normalna a efektywność zapytań wybierających, Zeszyty Naukowe UEK w Krakowie, nr 764, Kraków. Soja P. [1999], Technologia obiektowa w przedsiębiorstwie, Zeszyty Naukowe AE w Krakowie, nr 522, Kraków. Todman C. [2003], Projektowanie hurtowni danych, WNT, Warszawa. Database Logical Model Designing – Practical Remarks Construction of a sufficient logical project of a database has a fundamental significance as far as a correct performance of a whole information system is concerned. The article describes selected practical problems that occur during a database designing process. An attention has been paid, among others, to necessity for facts identification and their representation in a database, rules of object denotation, methods of unnecessary fields removal, need for ensuring data integrity, and necessity for a project verification with regard to its functionality. Consideration of the discussed issues in practice will contribute to creation of a correct logical project of a database and, consequently, will allow to avoid various anomalies and faults during the system exploitation. Key words: database, database designing, integrity rules, relationship, tables types, fields types..

(13)