Projektowanie bazy danych programem GProject

Program GProject pozwala zaprojektować bazę danych zgodnie teorią rachunku relacji. Struktury są pamiętane w postaci tabel bazy danych. W wersji instalacyjnej programu znajduje się wypełniona baza z przykładową strukturą (tejże bazy). Program umożliwia automatyczne wygenerowanie rozkładu do trzeciej postaci normalnej, sprawdzenie odwracalności rozkładu i zachowania zależności.

Wykonanie projektu

1. Atrybuty i powiązania

Projekt rozpoczynamy od spisania wszystkich atrybutów, jakie mogą się znaleźć w relacjach. Oczywistym źródłem tych danych jest analiza strukturalna (obiektowa) problemu. Wiele narzędzi CASE zakłada wręcz tożsamość obiektów i struktur tabel/relacji baz danych. To, czy element projektu pojawia się jako obiekt, czy też struktura relacji, zależy czasem jedynie od sposobu wyświetlenia. Sens takiego podejścia zdaje się znajdować potwierdzenie w stosowaniu mapowania obiektowo-relacyjnego (ORM). Jednak takie podejście dla dużych projektów ma pewne wady. Celem analizy obiektowej jest dokładne opisanie problemu w sposób możliwie ścisły. Natomiast celem procesu projektowania baz danych jest utworzenie optymalnych struktur danych. Te dwa cele nie są tożsame. Dlatego program Gproject przyjmuje założenie, że analiza obiektowa i projekt struktury relacyjnej bazy danych to dwa różne (następujące po sobie) procesy.

Spis atrybutów jest wprowadzany do tabeli programu na zakładce atrybuty (w obecnej wersji programu proces wprowadzania atrybutów nie jest zautomatyzowany):




Wprowadzana jest nazwa (przyszłej kolumny tabeli), typ (obecnie jeden z dwóch: N=numeryk, C=znakowy), rozmiar oraz ilość miejsc dziesiętnych (pozostałe kolumny nie są ważne z punktu widzenia projektu).

Na następnej zakładce wprowadzamy powiązania funkcyjne:




Literą L oznaczono obiekty po lewej stronie zależności, a literą R – po prawej. Powyższy rysunek pokazuje zatem zależność (assoc_id, pr_id) → (assoc_type, assoc_name, class1, class2). Przyciski pośrodku pozwalają usuwać i dodawać atrybuty (wybrane w prawym górnym okienku). Lewe górne okienko pozwala na przeglądanie powiązań (nazwa nie jest obowiązkowa).

Powiązania funkcyjne między atrybutami przekazują informację, na podstawie których atrybutów można ustalić jednoznacznie wartość innych atrybutów (na przykład numer PESEL pozwala jednoznacznie ustalić nazwisko i imię). Poniżej podano kilka dodatkowych wskazówek praktycznych dotyczących tego zagadnienia.



2. Minimalizacja zbioru powiązań

Kolejnym krokiem projektu jest minimalizacja zbioru zależności. Służy temu funkcja Operacje → Czy zbiór zależności jest minimalny. Analizowane są wszystkie zależności i wyświetlane te z nich, które są nadmiarowe. Korekt musimy dokonywać „ręcznie”. Po uzyskaniu minimalnego zbioru zależności pojawia się komunikat: „Zbiór zależności jest minimalny”.

3. Rozkład do trzeciej postaci normalnej

Po uzyskaniu minimalnego zbioru zależności, możemy na tej podstawie dokonać rozkładu do trzeciej postaci normalnej (funkcja Operacje → Rozkład do 3NF). Wcześniej możemy sprawdzić jak wygląda klucz główny relacji uniwersalnej (funkcja: Operacje → Szukaj klucza głównego). Ma to znaczenie przede wszystkim dla wykrycia atrybutów, które powinny się znaleźć po prawej stronie zależności, ale zostały pominięte. Jeśli na przykład wśród atrybutów jest PESEL, a w kluczu głównym pojawia się nazwisko, to najpewniej brakuje powiązania (PESEL)->(nazwisko).

Wykonanie rozkładu do 3NF powoduje wyświetlenie zbioru relacji. Można go w tym momencie zapisać do bazy funkcją Dane->Zapisz rozkład.

4. Sprawdzenie zbioru zależności

Ostatnie dwie funkcje: Operacja->Czy rozkład jest odwracalny oraz Operacja->Czy rozkład zachowuje zależności, służą do sprawdzenia uzyskanego rozkładu. W poprawnie zrealizowanym projekcie rozkład zawsze JEST odwracalny. Gorzej z zachowaniem zależności. Aby zaimplementowany algorytm wykazał zachowanie zależności, należy rozkład uzupełnić o relację klucza głównego (w praktyce taka relacja w bazie danych jest zbędna).

Uwagi praktyczne

1. Zależności wielowartościowe

W praktyce często mamy do czynienia z zależnościami wielowartościowymi (nie-funkcyjnymi). Czasem założenia przyjęte w trakcie projektu tego nie wykazują. Na przykład możemy założyć, że jedna osoba może z biblioteki pożyczyć tylko jedną książkę. Wówczas zależność – w uproszczeniu: (kod_czytelnika)->(książka) jest funkcyjna. Podobnie jak (kod_czytelnika)->(nazwisko). W oparciu o takie założenia może powstać projekt relacji: (kod_czytelnika, nazwisko, książka). Kiedy okazuje się, że czytelnik może pożyczyć więcej książek, zachodzi konieczność podzielnia tej relacji na dwie (kod_czytelnika)->(nazwisko) i (kod_czytelnika)->(książka). Lewa strona zależności powinna pozostać w obu relacjach otrzymanych z podziału.

W podobny sposób możemy postępować z zależnościami, które uprościliśmy do zależności funkcyjnych, aby nie komplikować projektu. Dokonanie powyżej opisaną metodą podziału relacji nie burzy ani teorii, ani własności rozkładu.

2. Stosowanie kodów

Zamiast atrybutu książka może się w projekcie pojawić kod książki, który wskazuje jednoznacznie na wszystkie istotne atrybuty książki. Wprowadzenie do schematu atrybutów – kodów nie tylko ułatwia odpowiednie zaprojektowanie bazy danych. Stosowanie kodowania informacji umożliwia także:

  • zmniejszenie zajętości pamięci (zmniejszenie pól rekordów);

  • zmniejszenie wielkości pól wchodzących w skład klucza, co powoduje m. in. usprawnienie indeksowych metod dostępu;

  • ułatwienie zachowania jednoznaczności.

W bazach danych kod bywa często identyfikatorem automatycznie zwiększającym się przy każdym nowym wierszu (autoincrement).

3. Redundancje

Argumentem wysuwanym niekiedy przeciw stosowaniu w praktyce rozkładu do trzeciej postaci normalnej jest duża ilość otrzymywanych tabel. Weźmy za przykład zestawienie dużej ilość dokumentów, z których zdecydowana większość jest dokumentami jednopozycyjnymi. Intuicyjnie najlepszym rozwiązaniem jest umieszczenie ich w jednej tabeli, którego jeden rekord odpowiada jednej pozycji na dokumencie.

Postępując zgodnie z teorią należałoby dla nagłówków dokumentów (informacje typu: data, kontrahent, itp.. utworzyć odrębną relację. Wyższość tego rozwiązania ujawnia się natychmiast, gdy wskutek zmiany specyfikacji bazę trzeba zmodyfikować i w nagłówku dokumentu pojawia się duża ilość dodatkowych informacji. Odstępstwa od teorii bardzo rzadko znajdują uzasadnienie.

Jest jeszcze inna strona tego zagadnienia. Unikanie redundancji w projektowaniu struktury bazy danych nie tylko nie przynosi korzyści, ale wręcz może być przyczyną problemów, gdy system nie zostanie zabezpieczony przed pojawieniem się niejednoznacznych danych. Jeśli do bazy zostaną wprowadzone dwa różne dokumenty o tym samym kluczu (numer, magazyn), dokonanie połączenia nagłówków z pozycjami dokumentu może okazać się niemożliwe.

Link do programu: http://galicea.org/download/GProject001.exe

Ostatnia modyfikacja: wtorek, 29 styczeń 2013, 17:53