2.1. Projekt koncepcyjny

Projektowanie bazy danych odbywa się w trzech etapach:

  1. projekt koncepcyjny;
  2. logiczny projekt;
  3. projekt fizyczny.

Celem fazy projektowania koncepcyjnego jest stworzenie koncepcyjnego modelu danych w oparciu o pomysły użytkowników dotyczące obszaru tematycznego. Aby to osiągnąć, przeprowadza się szereg sekwencyjnych procedur. Przykład schematu encji (koncepcyjnego):

1. Definicja podmiotów i ich dokumentacja. Aby zidentyfikować jednostki, definiuje się obiekty, które istnieją niezależnie od innych. Takimi obiektami są byty. Każda jednostka otrzymuje zrozumiałą nazwę, zrozumiałą dla użytkowników. Nazwy i opisy podmiotów są wprowadzane do słownika danych. Jeśli to możliwe, ustawiana jest oczekiwana liczba wystąpień każdej jednostki.

2. Określenie powiązań między podmiotami i ich dokumentacji. Zdefiniowane są tylko te relacje między jednostkami, które są niezbędne do spełnienia wymagań projektu bazy danych. Typ każdego z nich jest ustawiony. Klasa członkostwa jednostek jest ujawniona. Łączom przypisuje się znaczące nazwy wyrażone czasownikami. Do słownika danych wprowadzany jest szczegółowy opis każdego połączenia, wskazujący jego typ oraz klasę przynależności podmiotów uczestniczących w połączeniu.

3. Stworzenie modelu ER obszaru tematycznego. Diagramy ER służą do przedstawiania jednostek i relacji między nimi. Na ich podstawie tworzony jest pojedynczy obraz wizualny modelowanego obszaru tematycznego - model ER obszaru tematycznego.

4. Definicja atrybutów i ich dokumentacja. Ujawniane są wszystkie atrybuty opisujące jednostki utworzonego modelu ER. Każdemu atrybutowi nadawana jest zrozumiała nazwa, zrozumiała dla użytkowników. Następujące informacje są przechowywane w słowniku danych dla każdego atrybutu:

  • nazwa i opis atrybutu;
  • typ i wymiar wartości;
  • domyślna wartość atrybutu (jeśli istnieje);
  • czy atrybut może mieć wartości NULL;
  • czy atrybut jest złożony, a jeśli tak, to z jakich prostych atrybutów się składa. Na przykład atrybut „Imię i nazwisko klienta” może składać się z prostych atrybutów „Nazwisko”, „Imię”, „Patronimiczny” lub może być prosty, zawierający pojedyncze wartości, na przykład „Sidorski Jewgienij Michajłowicz”. Jeżeli użytkownik nie potrzebuje dostępu do poszczególnych elementów „Nazwy”, wówczas atrybut prezentowany jest jako prosty;
  • czy atrybut jest obliczany, a jeśli tak, to w jaki sposób obliczane są jego wartości.
Java webinar

5. Definicja wartości atrybutów i ich dokumentacja. Dla każdego atrybutu podmiotu uczestniczącego w modelu ER określany jest zestaw prawidłowych wartości i przypisywana jest mu nazwa. Na przykład atrybut „Typ konta” może mieć tylko wartości „depozyt”, „bieżący”, „na żądanie”, „konto karty”. Pozycje słownika danych związane z atrybutami są aktualizowane o nazwy zestawów wartości atrybutów.

6. Definicja kluczy podstawowych dla podmiotów i ich dokumentacji. W tym kroku kierujemy się definicją klucza podstawowego – jako atrybutu lub zbioru atrybutów podmiotu, który pozwala na jednoznaczną identyfikację jego instancji. Informacje o kluczu podstawowym są umieszczane w słowniku danych.

7. Omówienie konceptualnego modelu danych z użytkownikami końcowymi. Konceptualny model danych jest reprezentowany przez model ER wraz z towarzyszącą mu dokumentacją zawierającą opis opracowanego modelu danych. W przypadku stwierdzenia niespójności domenowych wprowadzane są zmiany w modelu do momentu, aż użytkownicy potwierdzą, że zaproponowany przez nich model odpowiednio odzwierciedla ich osobiste poglądy.

2.2 Projekt logiki

Celem etapu projektowania logicznego jest przekształcenie modelu koncepcyjnego opartego na wybranym modelu danych na model logiczny niezależny od cech SZBD wykorzystanego później do fizycznej implementacji bazy danych. Aby to osiągnąć, wykonywane są następujące procedury.

Przykład logicznego schematu bazy danych.

1. Wybór modelu danych. Najczęściej wybierany jest relacyjny model danych ze względu na przejrzystość tabelarycznej prezentacji danych i wygodę pracy z nimi.

2. Zdefiniowanie zestawu tabel w oparciu o model ER i ich udokumentowanie. Dla każdej jednostki modelu ER tworzona jest tabela. Nazwa jednostki to nazwa tabeli. Relacje między tabelami są ustalane poprzez mechanizm kluczy podstawowych i obcych. Udokumentowana jest struktura tabel i ustalone relacje między nimi.

3. Normalizacja tablic. Aby prawidłowo przeprowadzić normalizację, projektant musi dogłębnie zrozumieć semantykę i wzorce użycia danych. W tym kroku sprawdza poprawność struktury tabel utworzonych w poprzednim kroku, stosując do nich procedurę normalizacji. Polega na doprowadzeniu każdego ze stolików do co najmniej 3 NF. W wyniku normalizacji uzyskuje się bardzo elastyczną konstrukcję bazy danych, co ułatwia dokonywanie do niej niezbędnych rozszerzeń.

4. Sprawdzenie logicznego modelu danych pod kątem możliwości wykonania wszystkich transakcji podanych przez użytkowników. Transakcja to zestaw działań wykonywanych przez indywidualnego użytkownika lub aplikację w celu zmiany zawartości bazy danych. Tak więc przykładem transakcji w projekcie BANK może być przeniesienie prawa do zarządzania rachunkami jednego klienta na innego klienta. W takim przypadku konieczne będzie jednoczesne wprowadzenie kilku zmian w bazie danych. Jeśli komputer ulegnie awarii podczas transakcji, baza danych będzie w niespójnym stanie, ponieważ niektóre zmiany zostały już wprowadzone, a inne nie. Dlatego wszystkie częściowe zmiany muszą zostać cofnięte, aby przywrócić bazę danych do poprzedniego spójnego stanu.

Lista transakcji jest ustalana na podstawie działań użytkowników w obszarze tematycznym. Korzystając z modelu ER, słownika danych oraz ustalonych relacji między kluczami głównymi i obcymi, podejmuje się próbę ręcznego wykonania wszystkich niezbędnych operacji dostępu do danych. Jeśli jakakolwiek operacja ręczna zawiedzie, to skompilowany logiczny model danych jest nieodpowiedni i zawiera błędy, które należy wyeliminować. Być może są one związane z luką w modelu encji, relacji lub atrybutu.

5. Określenie wymagań wspierających integralność danych i ich dokumentacja. Te wymagania to ograniczenia wprowadzone w celu zapobieżenia wprowadzaniu do bazy danych sprzecznych danych. Na tym etapie omawiane są kwestie integralności danych bez względu na konkretne aspekty ich implementacji. Należy wziąć pod uwagę następujące rodzaje ograniczeń:

  • wymagane dane. Sprawdzanie, czy istnieją atrybuty, które nie mogą mieć wartości NULL;
  • ograniczenia dotyczące wartości atrybutów. Zdefiniowane są prawidłowe wartości atrybutów;
  • integralność podmiotu. Osiąga się to, jeśli klucz podstawowy encji nie zawiera wartości NULL;
  • więzy integralności. Rozumie się, że wartość klucza obcego musi być obecna w kluczu głównym jednego z wierszy tabeli dla jednostki nadrzędnej;
  • ograniczenia narzucone przez reguły biznesowe. Na przykład w przypadku projektu BANK może zostać przyjęta reguła, która zabrania klientowi zarządzania, powiedzmy, więcej niż trzema rachunkami.

Informacje o wszystkich ustanowionych ograniczeniach integralności danych umieszczane są w słowniku danych.

6. Stworzenie ostatecznej wersji logicznego modelu danych i dyskusja z użytkownikami. Ten krok przygotowuje ostateczną wersję modelu ER, który reprezentuje logiczny model danych. Sam model i zaktualizowana dokumentacja, w tym słownik danych i schemat powiązań tabeli relacyjnej, są przedstawiane użytkownikom do przeglądu i analizy, którzy muszą upewnić się, że dokładnie odzwierciedlają obszar tematyczny.

2.3. Projekt fizyczny

Celem etapu projektowania fizycznego jest opisanie konkretnej implementacji bazy danych znajdującej się w pamięci zewnętrznej komputera. Jest to opis struktury przechowywania danych oraz efektywnych metod dostępu do danych bazodanowych. W projektowaniu logicznym odpowiadają na pytanie - co należy zrobić, aw projekcie fizycznym - wybiera się sposób, w jaki to zrobić. Fizyczne procedury projektowania są następujące.

1. Projektowanie tabel bazodanowych z wykorzystaniem wybranego SZBD. Wybrano relacyjny system DBMS do utworzenia bazy danych hostowanej na nośniku maszynowym. Jego funkcjonalność do projektowania tabel jest dogłębnie zbadana. Następnie wykonywany jest projekt tabel oraz schemat ich połączenia w środowisku DBMS. Przygotowany projekt bazy danych został opisany w załączonej dokumentacji.

2. Implementacja reguł biznesowych w środowisku wybranego DBMS. Aktualizowanie informacji w tabelach może być ograniczone regułami biznesowymi. Sposób ich implementacji zależy od wybranego DBMS. Jedne systemy do realizacji wymagań danej dziedziny oferują więcej funkcji, inne mniej. W niektórych systemach w ogóle nie ma wsparcia dla implementacji reguł biznesowych. W takim przypadku aplikacje są opracowywane w celu implementacji ich ograniczeń.

Wszelkie decyzje podjęte w związku z wdrożeniem domenowych reguł biznesowych są szczegółowo opisane w załączonej dokumentacji.

3. Projektowanie fizycznej organizacji bazy danych. Ten krok wybiera najlepszą organizację plików dla tabel. Zidentyfikowane są transakcje, które będą wykonywane w projektowanej bazie danych, a najważniejsze z nich zostaną wyróżnione. Analizowana jest przepustowość transakcji - liczba transakcji, które można przetworzyć w danym przedziale czasu, oraz czas odpowiedzi - czas potrzebny do zrealizowania jednej transakcji. Dążą do zwiększenia przepustowości transakcji i skrócenia czasu odpowiedzi.

Na podstawie tych wskaźników podejmowane są decyzje optymalizujące wydajność bazy danych poprzez definiowanie w tabelach indeksów przyspieszających selekcję danych z bazy lub zmniejszanie wymagań co do poziomu normalizacji tabeli. Przestrzeń dyskowa wymagana do umieszczenia utworzonej bazy danych jest szacowana. Staraj się go minimalizować.

Decyzje podjęte w powyższych kwestiach są dokumentowane.

4. Opracowanie strategii ochrony baz danych. Baza danych jest cennym zasobem korporacyjnym i wiele uwagi poświęca się jej ochronie. Aby to zrobić, projektanci muszą mieć pełne i jasne zrozumienie wszystkich zabezpieczeń zapewnianych przez wybrany DBMS.

5. Organizacja monitoringu funkcjonowania bazy danych i jego dostosowanie. Po utworzeniu fizycznego projektu bazy danych organizowany jest stały monitoring jej funkcjonowania. Uzyskane w ten sposób informacje o poziomie wydajności bazy danych służą do jej strojenia. W tym celu zaangażowane są również środki wybranego DBMS.

Decyzje o wprowadzeniu jakichkolwiek zmian w funkcjonującej bazie danych powinny być dokładnie przemyślane i przemyślane.