3 projekty relacyjnej bazy danych

Wstęp

Zadaniem relacyjnej bazy danych jest odwzorowanie rzeczywistych procesów przetwarzania danych w organizacji. Zanim wypełnisz tabele danymi ze swojej aplikacji warto poświęcić trochę czasu i dobrze zaprojektować bazę danych. Projekt bazy danych powstaje w trzech etapach. Poprzedzony jest analizą potrzeb użytkowników, a zakończony implementacją przy wykorzystaniu motoru baz danych dla którego stosunek dostarczanych funkcjonalności do kosztów jest najbardziej korzystny.

Publikacja w formie wideo

Analiza potrzeb

Etap analizy potrzeb nazywany jest także analizą wymagań. Na tym etapie ustalasz jakie dane będą przechowywane. Na przykład ustrukturyzowane i powiązane ze sobą czy o zmiennej ilości atrybutów i mało powiązane. Jak będą używane? Na przykład szybkie transakcje na małej ilości danych czy przekrojowe zapytania agregujące na dużej ilości danych. Jakie operacje będą wykonywane? Na przykład częste aktualizacje małej ilości danych czy częste odczyty dużej ilości danych. Jakie są wymagania dotyczące skalowalności, spójności, szybkości? Na przykład księgowość gdzie spójność danych jest kluczowa czy system obsługujący miliony użytkowników z możliwością skalowania poziomego.

Projekt koncepcyjny

Po wnikliwej analizie potrzeb użytkowników projektowanie bazy danych zaczynasz od etapu koncepcyjnego. Jest to najbardziej abstrakcyjny poziom. Abstrakcyjny czyli totalnie oderwany od technologii czy konkretnego motoru baz danych. Na tym etapie wybierasz model danych. Ja wybieram relacyjny.

Następnie skupiasz się na zrozumieniu i opisaniu danych oraz ich powiązań z perspektywy wybranego modelu. Celem jest zrozumienie jakie dane są organizacji potrzebne oraz jak przetwarza je w informacje. Rozpoznanie bytów, ich cech oraz powiązań pomiędzy bytami. Zamiast terminu byt możesz spotkać się z określeniem encja. Tak czy inaczej jest to istotny dla organizacji obiekt – osoba, przedmiot, lokalizacja, pojęcie lub zdarzenie – które ma swoją nazwę, cechy, identyfikator i może być odróżnione od innych obiektów. Zamiast terminu cecha możesz spotkać się z określeniem atrybut. Jedno i drugie oznacza charakterystykę bytu, która jest ważna dla organizacji. Na przykład w bazie danych biblioteki przechowywane są dane trzech bytów o nazwach książka, autor i czytelnik.

Tekstowa forma diagramu encji

Przykładami powiązań są: każdy czytelnik może wypożyczyć wiele książek. Każda książka może być napisana przez wielu autorów. Oprócz autora cechami książki są tytuł, data wydania i wydawnictwo. Cechami czytelnika są imię, nazwisko oraz adres. Identyfikatorem książki może być numer ISBN, a czytelnika numer PESEL. Rozpoznane byty i powiązania opisujesz krótko, treściwie i jednoznacznie oraz zapisujesz w wybranym narzędziu. Kartki papieru lub pliki notatnika są wystarczające. Ważne aby były prowadzone sumiennie, systematycznie i z zachowaniem wybranej konwencji.

Projekt logiczny

Pomostem pomiędzy projektem koncepcyjnym, a fizycznym jest projekt logiczny. Na tym poziomie:

  • zamieniasz rozpoznane na poziomie koncepcyjnym byty i atrybuty na konkretne tabele zawierające kolumny określonego typu
  • upewniasz się, że każda tabela odpowiada tylko jednemu bytowi
  • dbasz aby kolumny miały jednoznaczne nazwy, nie zawierały wartości wyliczanych, nie były wielowartościowe czy wieloczęściowe
  • rozdzielasz złożone dane na proste i czytelne kolumny
  • spośród rozpoznanych identyfikatorów bytu wybierasz jeden lub tworzysz własny, który staje się kluczem głównym. Własnoręcznie stworzony klucz główny nazywa się kluczem sztucznym. Jego wartości nadaje aplikacja
  • następnie redukujesz redundancję danych. Czyli dbasz aby konkretne dane pojawiały się tylko w jednej kolumnie w całej bazie danych
  • ustalasz podstawowe reguły integralności jak wartość domyślna czy dozwolenie NULL
  • definiujesz typ i stopień powiązań pomiędzy wierszami

Przykładowo w bazie danych biblioteki definiujesz tabele książka, autor i czytelnik

Przykład projektu logicznego bazy danych biblioteki

Tabela autor ma kolumny autor_nazwisko typu tekstowego, autor_imię typu tekstowego oraz autor_id typu liczbowego. Tabela książka to kolumny książka_tytuł typu tekstowego, książka_wydana typu datoczasowego, wydawnictwo_id typu liczbowego, książka_isbn typu liczbowego oraz książka_id typu liczbowego. Autor_id i książka_id zostają kluczami głównymi z wartościami nadawanymi przez aplikację. Powiązanie wiele do wiele autora i książki zostaje zamienione na dwa powiązania jeden do wiele z tabelą pośrednią autor_książka zawierającą kopię kluczy głównych autor_id i książka_id. Kolumna wydawnictwo_id jest kluczem obcym. Czyli kluczem głównym nowej tabeli wydawnictwo skopiowanym do tabeli książka. Dla kolumny książka_isbn definiujesz więz integralności wymuszający dziesięć lub trzynaście cyfr. Natomiast dla kolumny książka_wydana wymuszający datę z przeszłości. Jak uważasz czy dobrze zrobiłem tworząc sztuczny klucz główny dla książki czy lepiej byłoby użyć klucza naturalnego w postaci numeru ISBN?

Projekt fizyczny

Projekt fizyczny polega na przekształceniu projektu logicznego w konkretną strukturę techniczną, dostosowaną do wybranego motoru bazy danych. W projekcie fizycznym określasz w jaki sposób dane będą faktycznie przechowywane, zarządzane i optymalizowane w systemie.

Motor bazy danych wybierasz w oparciu o możliwości implementacji projektu logicznego. Czyli o dostępne w motorze funkcjonalności pozwalające na implementację reguł biznesowych zidentyfikowanych podczas wywiadów z użytkownikami i uwzględnionych w projekcie logicznym. Nie bez znaczenia jest wielkość budżetu przeznaczonego na stworzenie i późniejsze utrzymanie bazy danych. Podczas dokonywania wyboru motoru należy wziąć pod uwagę łatwość zarządzania i funkcjonalności zapewniające jak najwyższą dostępność oraz możliwość skalowania.

Na etapie projektu fizycznego optymalizujesz strukturę bazy danych pod wydajność na konkretnym sprzęcie. W oparciu o ścieżki dostępu do danych definiujesz indeksy, partycjonujesz tabele oraz dobierasz fizyczny typ tabeli. Na przykład zwykła sterta, skompresowana czy klastrowa.

Komendy SQL tworzące strukturę bazy danych zoptymalizowaną pod konkretną instalację

Przekładasz ogólne typy danych jak liczbowy, tekstowy czy datoczasowy na konkretny typ dostępny w danym motorze baz danych. Na przykład tekstowa kolumna wydawnictwo_nazwa na VARCHAR2 o długości stu znaków w Oracle. Liczbowa kolumna książka_isbn na int w MySQL. Czy datoczasowa książka_wydana na typ date w SQL Server. Warto zaimplementować cykl życia danych. Czyli na podstawie regulacji prawnych i sposobu używania danych przez organizację zaimplementować archiwizację potrzebnych, ale nie modyfikowanych danych. Na przykład dane potrzebne, ale sporadycznie lub w ogóle nie modyfikowane przenieść do skompresowanych partycji. Lub usunąć partycje z danymi, których nie wolno lub nie potrzeba przechowywać dłużej niż określony czas. W projekcie fizycznym planujesz bezpieczeństwo aplikacji. Czyli tworzysz użytkowników, ich role oraz nadajesz uprawnienia. Warto kierować się zasadą: co nie jest dozwolone jest zakazane.

Implementacja

Implementacja projektu fizycznego polega na przeniesieniu zaprojektowanej struktury bazy danych do realnego środowiska systemu zarządzania bazą danych poprzez tworzenie rzeczywistych obiektów, konfigurację mechanizmów bezpieczeństwa oraz optymalizację dostępu i przechowywania danych. W praktyce proces polega na wykonaniu zestawu skryptów zawierających komendy SQL na zainstalowanej wcześniej, skonfigurowanej i uruchomionej instancji bazy danych. Warto posiłkować się środowiskiem kontroli wersji w rodzaju GitHub aby zachować historię zmian w treści skryptów. Należy pamiętać, że nawet najstaranniej zaprojektowana baza danych jest tworem żywym i podlegającym zmianom. Jest wysoce prawdopodobne, że w bliższej lub dalszej przyszłości potrzebne będą modyfikacje. Staranne przygotowanie skryptów instalujących poprawki oraz jasno określona procedura ich wprowadzania znacznie poprawiają dostępność bazy danych. Na etapie implementacji należy zatroszczyć się o zgodną z potrzebami organizacji dostępność danych. Na przykład konfigurując backup czy replikację.

Podsumowanie

Dziękuję za przeczytanie niniejszej publikacji. Wiesz z niej, że

  • w analizie wymagań nie tylko zbierasz informacje o danych, ale także określasz, co z nimi będzie robione i jakie cechy systemu są kluczowe. Zależy od tego, jaki model bazy danych wybierzesz
  • projekt koncepcyjny definiuje strukturę informacyjną systemu poprzez opisanie bytów, ich atrybutów i relacji między nimi, bez uwzględniania typów danych czy implementacji fizycznej
  • projekt logiczny precyzyjnie opisuje „co” i „jak” będzie przechowywane w bazie danych, bez wdrażania szczegółów technicznych
  • projekt fizyczny służy do technicznego odwzorowania struktury bazy danych w wybranym systemie zarządzania bazą danych, zapewniając efektywność, bezpieczeństwo i zgodność ze środowiskiem produkcyjnym
  • implementacja polega na wdrożeniu w życie projektu fizycznego
Podsumowanie faz projektowania relacyjnej bazy danych razem z opisem czynności  dla każdej z faz

Niech solidność Twoich projektów zawsze wspiera spójność Twoich danych! A jeśli chcesz, by każdy Twój projekt fizyczny smukle przeszedł fazę implementacji – koniecznie śledź mój blog!

Marcin Badtke

Przyjaźnie o SQL, bazach danych i ludziach

Może Ci się spodobać...

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *