Wymagania dotyczące projektu do przedmiotu: Systemy baz danych 2 / Bazy danych projekt 1 (P) Założenie: zaprojektowanie schematu bazy danych modelującej wybrany fragment oraz implementacja tego schematu w konkretnej bazie danych. UWAGA: podane narzędzia są to propozycje można korzystać z innych, o ile efekt końcowy będzie osiągnięty. Wymagania szczegółowe (minimalne) 1. Przygotowanie schematu/modelu logicznego bazy danych (narzędzie: Oracle SQL Developer Data Modeller) 2. Wielkość bazy: 20 tabel/encji relacje wiele-do-wiele można traktować jako encje 3. Utworzenie fizycznej bazy danych implementującej podany schemat (MySQL) 4. Przygotowanie aplikacji (desktop, GUI) do obsługi wybranych fragmentów bazy danych (niekoniecznie całą bazę): a. Obsługa danych (wyświetlanie) w postaci tabelarycznej (min. 2 formatki), b. Podstawowe operacje zmieniające dane: UPDATE, INSERT, DELETE, w tym edycja danych z wyborem wartości z listy (słownik) c. Obsługę dodatkowej funkcjonalności, innej niż z pkt. a, np. przeliczenie stanów magazynowych w bazie danych oddzielna formatka z polami i przyciskiem d. Raporty: po jednym przykładzie i. raport w układzie tabelarycznym ii. raport w układzie master-detail: np. grupa dziekańska oraz lista studentów, następna grupa dziekańska oraz lista studentów itd. e. propozycja technologii wykonania: i. JavaFX formatki ii. JasperReport raporty 5. Przygotowanie dokumentacji technicznej (~3-4 strony) zawierającej: a. Ogólny opis architektury i technologii wykonania aplikacji b. Szczegółowy opis niestandardowych elementów aplikacji c. Schemat logiczny i fizyczny (relacyjny) bazy danych 6. Przygotowanie dokumentacji użytkowej, wraz ze zrzutami ekranów. Uwagi dodatkowe: 1. Nie jest wymagane przygotowanie wersji standalone tzn. takiej, że przegrywamy aplikację na inny komputer i od razu działa aplikacja powinna być możliwa do uruchomienia/zaprezentowania w zaproponowanym przeze mnie środowisku programistycznym lub w innym przygotowanym przez studenta (jeżeli nie korzysta z
zaproponowanego). M. in. dopuszczalne jest ustawianie na sztywno ścieżek do katalogów i bibliotek. 2. Nie jest wymagana obsługa użytkowników i logowanie hasła mogą być wpisane do aplikacji. 3. Zaleca się aby wszystkie te wartości (ścieżki, hasła itp.) były dostępne w jednym miejscu (klasie, pliku konfiguracji itp.)
Zasady projektowania bazy danych podejście praktyczne Zasada podstawowa: żadna, przewidziana przez nas w schemacie (aplikacji) zmiana danych nie może (nie powinna) powodować zmiany w strukturze bazy danych. (Anty-)przykład: jeżeli przy towarach zastosujemy stawki VAT jako kolejne kolumny (typu logicznego) to pojawienie się kolejnej stawki spowoduje konieczność dołożenia kolumny => niedopuszczalne. Klucze główne, klucze obce 1. Nie używamy jako kluczy głównych atrybutów, które użytkownik może modyfikować. a. mogą zajmować dużo miejsca (kolumny tekstowe); b. jeżeli od tabeli z takim kluczem głównym zależą inne tabele z dużą liczbą rekordów, przy konieczności zmiany wartości klucza, konieczna jest modyfikacja innych tabel zależnych; 2. W praktyce stosujemy dodatkowe, sztucznie wygenerowane kolumny, a wartościach całkowitych (BIGINT, 64bity) do generowania wartości używamy specjalnych konstrukcji: a. sekwencje, generatory, b. kolumny z automatyczną numeracją: SERIAL, AUTOINCREMENT 3. Nazewnictwo: ID lub ID_tabela (np. ID_OSOBA) Nazewnictwo obiektów 1. PL czy EN zalecam jednak EN, zazwyczaj krótsze nazwy, w przypadku PL stosowanie ogonków nie zawsze możliwe, a nazwy bez ogonków mogą być niepoprawne (BŁĄD => BLAD). 2. Liczba pojedyncza vs liczba mnoga (PERSON vs PERSONS, OSOBA vs OSOBY) 3. W przypadku nazw PL: nazwy z mianowniku czy dopełniaczu (klucze obce): ID_OSOBA czy ID_OSOBY. 4. Przedrostki (prefix) dla różnych grup obiektów a. podział funkcjonalny obiektów: K_ - kadra, S_ - sprzedaż, T_ - dział techniczny itp.; b. podział ze względu na rodzaj obiektu: T_ - tablice, V_ - perspektywy, PL_ - procedury i funkcje, TG_ - wyzwalacze; Relacje Klasyczna relacja 1:n (jeden-do-wiele) Czytamy ją: każdemu towarowi odpowiada jedna kategoria każdej kategorii może odpowiadać wiele towarów Na pokazanym przykładzie, relacja w żadną ze stron nie jest wymagana (linia przerywana). Relacji wymaganej odpowiadałaby linia ciągła. Możliwe są inne sposoby wizualizacji relacji (notacje):
notacja IE inne kreski : Relacja wymagana (dla 1) Relacja niewymagana (dla 1) Klasyczna relacja n:m (wiele-do-wiele) Możliwe są inne rodzaje relacji, ale będziemy stosować tylko powyższe. W szczególności nie stosujemy: 1:1 rozbicie tablicy (relacji) na dwie składowe (stosuje się w wyjątkowych sytuacjach, np. ze względów optymalizacyjnych/wydajnościowych); 1:n gdzie relacja dla n jest wymagana; dowolny rodzaj relacji, gdzie relacja jest wymagana w obie strony fizycznie nie da się tego zrealizować Schematy Schemat logiczny W modelu tym określamy tabele (encje) oraz relacje pomiędzy nimi. Dla tabel określamy atrybuty: tylko takie, które nie wynikają z relacji oraz klucz główny (ID).
Model fizyczny (relacyjny) Typy kolumn określamy na etapie modelu logicznego. Dla relacji 1:n tworzona jest dodatkowa kolumna (VAT_ID) w tabeli (w zależności od tego, czy relacja jest wymagana, czy też nie będzie to kolumna not null bądź bez not null). Dla relacji n:m tworzona jest dodatkowa tabela, nazwana tak jak relacja (trzeba określić nazwę relacji w modelu logicznym). Uwagi UWAGA 1: w modelu logicznym możemy dodać do relacji dodatkowe atrybuty, ale żeby atrybuty te były należy włączyć ich pokazywanie. Oczywiście atrybuty takie będą zamienione w modelu fizycznym (relacyjnym) na konkretne kolumny. UWAGA 2: nie znam metody na pokazanie (w Oracle Data Modeller ze) nazw relacji; można co najwyżej pokazać (wyświetlić) nazwy w określoną stronę (NameOnSource, NameOnTarget). Podział danych na grupy/kategorie Klasycznie: 1:n, ale co się stanie jeżeli są towary, które pasują do obu? => Relacja n:m Struktura drzewiasta kategorii: KATEGORIA ID NAZWA ID_PARENT
trzeba pilnować aby nie powstały cykle (zapętlenia), większość baz danych nie ma obsługi takich struktur w standardzie (z wyjątkiem Oracle) Przykład: 1 2 3 4 5 UWAGA: cykl powstałby, gdyby np. dodać teraz do rekordu ID=1 rodzica ID_PARENT = 5. Jak wtedy wyświetlić wszystkie rekordy od 1 w dół? Tabela KATEGORIA ID ID_PARENT 1 <null> 2 1 3 1 4 3 5 3 Tablica pomocnicza dla KATEGORIA (struktura drzewiasta) gdy nie ma natywnej obsługi: ID_CHIL ID_PARENT D 1 1 2 2 2 1 3 3 3 1 4 4 4 3 4 1 5 5 5 3 5 1 Jak widać, dla wygody dodajemy także pary o takich samych wartościach ID (łatwiej jest wtedy wyszukać wszystkie elementy od np. 2 w dół => szukamy wszystkich, gdzie ID_PARENT = 2). Dodanie kolejnego elementu (np. 6 jako podrzędny do 5) polega: dodaniu elementy 6-6, dodaniu elementów 6-ID_PARENT, dla wszystkich par, gdzie ID_CHILD = 5, czyli (kolejno): 6-5, 6-3, 6-1 (ostatnie 3 rekordy w tabeli) UWAGA: każde rozszerzenie funkcjonalność (1:n => n:m lub dołożenie struktury drzewiastej lub oba łącznie) powoduje skomplikowanie struktury bazy danych a także konieczność rozbudowy interface u (a co za tym idzie bardziej skomplikowaną obsługę dla użytkownika końćowego).
Słowniki UWAGA: nie każda relacja 1:n (lub n:m) jest słownikiem. Tutaj zajmiemy się klasycznymi słownikami i kryteriami ich doboru. UWAGA: należy pamiętać, że wydzielenie słownika (utworzenie oddzielnej tabeli) powoduje m.in. konieczność stosowania złączeń tablic (join) przy wczytywaniu danych (lub odpowiedniej organizacji interface u użytkownika). Zasady wydzielania słowników: 1. liczba wartości dla danego atrybuty jest stałą, bez względu na liczbę rekordów; 2. wartości atrybutu są określone przez wymogi formalno-prawne (organizacyjne): stawki VAT 3. możliwość podziału danych ze względu na wartości atrybutu są dla nas istotne ze względów funkcjonalnych (np. podział danych na kategorie w raporcie). Oczywiście mogą się pojawiać takie relacje, w których dane przyrastają w obu tablicach: np. pracownicy i pobrane klucze (relacja 1:n każde pobranie przez dokładnie jednego pracownika). Generowanie fizycznej bazy danych Aby wygenerować fizyczną bazę danych, należy utworzyć skrypt DDL (Data Definition Language). W tym celu należy uruchomić opcję File Export DDL File. Mamy możliwość wygenerowania pliku SQL z komendami tworzącymi bazę danych. Zasadniczym (dla nas) problemem jest brak możliwości wygenerowania pliku właśćiwego dla bazy MySql. Najlepszym rozwiązaniem jest ustawienie jako bazy (w modelu relacyjnym) Oracle, a potem ręczna zamiana wybranych typów danych: 1. varchar2 varchar 2. numeric decimal Ewentualne inne ustawienia, takie jak ustawienie opcji autoincrement dla wybranych kluczy głównych, robimy już za pomocą narzędzi przeznaczonych do bezpośredniego zarządzania bazą danych. Przy generowaniu pliku DDL istnieje możliwość wygenerowania komend usuwających tabele, niemniej jednak jest problem z kolejnością usuwania, a MySql ma nieco inną składnię usuwania kaskadowego (czyli usuwania tabeli i wszystkich table z nią związanych). Wydaje się, że najprostszą opcją jest po prostu usunięcie całej bazy danych i utworzenie jej od nowa. Przy tworzeniu bazy danych, praktycznie w każdym systemie zarządzania, potrzebne jest określenie strony kodowej czyli jakie znaki można w niej przechowywać i w jaki sposób są określane np. sortowanie czy zamiana znaków małe/duże. Aktualnie jedyną rozsądną opcją wydaje się wybranie UTF8, w przypadku MySql są to: utf8_general_ci lub utf8_polish_ci.