Podstawowe zadania w projektowaniu baz danych

1.1 Wprowadzenie

Projektowanie bazy danych jest nieco podobne do projektowania architektury projektu Java. Możesz umieścić wszystkie dane w kilku tabelach lub zbudować piękną strukturę danych ze schematów i dziesiątek tabel.

Oto zadania, przed którymi zwykle stoi programista podczas projektowania bazy danych:

1. Zapewnienie, że wszystkie niezbędne informacje są przechowywane w bazie danych.
2. Zapewnienie możliwości uzyskania danych o wszystkich niezbędnych żądaniach.
3. Zmniejszenie redundancji i powielania danych.
4. Zapewnienie integralności bazy danych
5. Optymalizacja szybkości dostępu do danych

Najważniejszą rzeczą do zapamiętania jest to, że nie można stworzyć idealnej struktury bazy danych, ponieważ. to, podobnie jak twój kod, będzie się stale zmieniać. Istnieją trzy rzeczy, o których należy pamiętać podczas projektowania struktury bazy danych:

1. Struktura musi być wystarczająco dobra.
2. We wszystkim, co inni ludzie mogą zrozumieć, musi być logika.
3. Przedwczesna optymalizacja jest źródłem wszelkiego zła.

Nie musisz tworzyć najlepszej na świecie struktury bazy danych. Ona jeszcze się zmieni. Twoim zadaniem jest upewnienie się, że po 20 zmianach w strukturze Twojej bazy danych, będzie to dość łatwe do rozgryzienia.

Najprawdopodobniej w pierwszych latach pracy nikt nie powierzy Ci zaprojektowania bazy od podstaw. Będziesz wprowadzać zmiany w istniejącym schemacie. Trzeba spróbować zrozumieć na podstawie jakich zasad jest to ułożone i się do nich stosować . Ze swoim statutem nie wchodzą do czyjegoś klasztoru.

Nie optymalizuj bazy danych, dopóki nie będzie to konieczne. Jeśli tabela ma tylko kilkaset wierszy, najprawdopodobniej DBMS będzie przechowywać ją w pamięci i przesyłać do niej zapytania w pamięci podręcznej.

Z drugiej strony powinieneś być w stanie przyspieszyć pracę ważnych próśb dziesiątki, a nawet setki razy. I byłoby miło, gdybyś wiedział, jak to zrobić. Jak mówią w liceum w pierwszej klasie? „Zapomnij o wszystkim, czego nauczyłeś się w szkole…”

Jeśli wiesz, czym jest normalizacja baz danych, to spieszę, by cię zadowolić, w swojej pracy najprawdopodobniej będziesz miał do czynienia z de-normalizacją . Nic nie jest ważniejsze dla sanktuariów projektu niż szybkość bazy danych. A jeśli w celu przyspieszenia selekcji danych z bazy trzeba połączyć 200 (!) Tablic w jedną (z monstrualną redundancją), trzeba będzie to zrobić.

1.2 Projekt biblioteki

Zagłębmy się trochę w ten obszar tematyczny i pomyślmy o projektowaniu bazy danych przy użyciu czegoś tak prostego, jak typowa biblioteka książek.

Głównym zadaniem każdej biblioteki jest przetwarzanie funduszu książkowego. Łatwo wyróżnić trzy główne grupy użytkowników systemu: czytelnik, bibliotekarz, administrator . Aktywność każdego z nich jest pokazana na diagramie przypadków użycia.

Już teraz można wyróżnić niektóre encje i relacje przyszłej bazy danych:

Przy takim podejściu nie jest jasne, jak powiązać czytelnika z książką (czytnik nie występuje w relacji „wydanie/odbiór”). Jeśli książka ma kilka egzemplarzy, to może być wydana kilku czytelnikom. Nawet jeśli przez książkę rozumie się jeden egzemplarz, to po zapisaniu w spisie książek aktualnego czytelnika nie będzie można uzyskać informacji o tym, kto (i ile razy) wziął tę książkę wcześniej.

Rozwiązaniem może być wprowadzenie dodatkowego podmiotu – karty do wydania książki. Przy wydawaniu książki czytelnikowi tworzona jest karta, a przy przekazywaniu książki umieszczany jest na niej odpowiedni znak. Za pomocą tych kart określa się zadłużenie każdego użytkownika i oblicza statystyki korzystania z książek. Przy rezerwacji literatury przez czytelnika uruchamiana jest również karta, jeśli zarezerwowana literatura nie zostanie pobrana przez czytelnika w określonym czasie, karta ulega zniszczeniu. Liczba książek, które czytelnik może zarezerwować, jest ograniczona.

Podczas wyboru literatury użytkownik przegląda katalog literatury z możliwością filtrowania wyników wyszukiwania według autora, tytułu, roku wydania.

Możliwe jest obliczenie statystyk dla wszystkich książek znajdujących się w bibliotece, a jednocześnie liczby wydanych egzemplarzy książki za dany okres czasu. Można również ustawić minimalną liczbę wystąpień księgi, dla których wykonywane są obliczenia. Na podstawie tych statystyk niewykorzystane książki są odpisywane z biblioteki.

Można wyróżnić następujące główne podmioty obszaru tematycznego:

• użytkownik (bibliotekarze i administratorzy);
• czytelnik;
• Czytelnia;
• książka;
• karta wydania książki;
• zarezerwuj kartę rezerwacji.

Zmodyfikowany diagram ER bazy danych pokazano na rysunku.

Zgodnie z przypadkami użycia pokazanymi na rysunku 1, baza danych powinna implementować następujące zapytania (lista nie jest wyczerpująca):

• wyświetlać książki spełniające określone warunki;
• wyświetlać użytkowników, którzy mają karty do wydawania książek, które nie zostały zamknięte w terminie (bibliotekarz szuka dłużników);
• wyświetlić wszystkie książki, które odpowiadają kartom wypożyczeń danego użytkownika, które nie zostały zamknięte w terminie (użytkownik przyszedł do biblioteki po nowe książki - trzeba sprawdzić, czy jest dłużnikiem i poinformować go o tym);
• usuń wszystkie karty rezerwacji utworzone ponad N sekund temu;
• wyświetlić wszystkie książki odpowiadające niezamkniętym kartom rezerwacji książek wskazanego użytkownika (czytelnik zamówił książki i przyszedł po nie do biblioteki - bibliotekarz musi zdobyć tę listę, aby ją wydać).

1.3 Tworzenie schematu

Aby utworzyć schemat danych, należy najpierw uzupełnić diagram ER o szczegóły jednostek (doprecyzować). Czasem przy okazji można znaleźć błędy w konstruowaniu diagramu ER – w tym zadaniu stwierdzono, że książkę trzeba „jakoś” połączyć z salą biblioteczną.

Można to zrobić poprzez umieszczenie w księdze wymaganego „numeru sali”, jednak przy takim podejściu ta sama książka będzie musiała zostać opisana w bazie kilka razy (jeśli występuje w różnych salach). Bardziej poprawnym podejściem jest wprowadzenie dodatkowego podmiotu „lokacja księgowa”. Rysunek przedstawia diagram ER z dodaną jednostką i rekwizytami.

Powyższy diagram ER odzwierciedla główne tabele, relacje i atrybuty, na jego podstawie można zbudować model bazy danych. Nie ma standardu dla diagramu ER, ale istnieje wiele notacji (Chen, IDEFIX, Martin itp.), ale nie można znaleźć ani standardu, ani notacji dla modelu dziedzinowego. Jednak w trakcie konstruowania takiego diagramu konieczne jest podkreślenie kluczowych pól (zewnętrznych i wewnętrznych), czasem indeksów i typów danych.

W tym przypadku na poniższym schemacie:

• w przypadku linków notacja Martina („kurze łapki”);
• tabele są wyświetlane jako prostokąty podzielone na 3 sekcje:
• Nazwa tabeli;
• klawisze wewnętrzne (oznaczone znacznikiem);
• pozostałe pola, natomiast pola obowiązkowe są zaznaczone znacznikiem.

Przy opracowywaniu tego modelu istniała chęć połączenia tabeli administratorów z tabelą bibliotekarzy - dodajmy jednak tabelę users:

• administrator nie jest powiązany z konkretnym pokojem (należy wypełnić odpowiednie pole wartościami pustymi);
• skomplikowałoby to zapewne dystrybucję praw dostępu - teraz tylko administrator bazy danych (który pracuje poprzez specjalny panel DBMS i nie posiada konta w tworzonym systemie) ma dostęp do tablicy administrators. Jednak podczas łączenia tabel zapytania użytkowników wymagałyby dostępu do nowej tabeli.

Podczas konstruowania tego diagramu znaleziono i skorygowano błąd w diagramie ER - dodano tabelę, librarians_roomsktóra łączy bibliotekarzy i sale. Jest to konieczne, ponieważ jeden bibliotekarz może pracować w kilku pomieszczeniach, ale kilku bibliotekarzy może pracować w tym samym pomieszczeniu.

Projektując bazy danych, powinieneś być w stanie rozumować co najmniej tak, jak w powyższym przykładzie. Jeśli uważasz, że Ci się udało, przejdźmy dalej: jeszcze więcej teorii.