Jak wygląda projekt informatyczny

 Kilka dni temu znalazłem ciekawy wpis na eX blog . Poniżej pozwoliłem sobie go w całości zacytować, ale polecam również komentarze do orginalnego wpisu.

"Kilka zaleceń pozwalających dobrze projektować aplikacje wykorzystujące bazy danych, opartych na doświadczeniu, materiałach ze studiów, książkach i wyszperanych w internecie stronach. Bardzo ciekawe rzeczy można znaleźć na stronie Tomasza Traczyka i Roberta Chwastka.

Projektowanie aplikacji korzystającej z bazy danych należy zacząć od stworzenia modelu danych. Implementację należy rozpocząć stworzeniem funkcjonujęcej bazy danych i wypełnieniem jej przykładowymi danym. Jest to dobre posunięcie w sytuacji prowadzenia równoległych prac nad różnymi modułami systemu. Powinny być one względnie od siebie niezależne. Łącznikiem między nimi jest przede wszystkim baza danych.

Wszystkie bazy danych powinny być projektowane zgodnie z regułami sztuki. Każde odstępstwo powinno być szczegółowo przemyślane, zwłaszcza pod kątem możliwości modyfikacji i rozbudowy modelu danych.

Narzędzia projektowe

W aplikacjach korzystających z baz danych poprawny model danych jest podstawą całego systemu. Uzyskanie takiego modelu ułatwiają narzędzia CASE. Należy z nich korzystać ponieważ:

  • Dzięki modelowaniu graficznemu ułatwiają zrozumienie modelu.
  • Pozwalają uniknąć sporej liczby błędów dzięki wbudowanym walidatorom.
  • Usprawniają wprowadzanie zmian do modelu.
  • Eliminują błędy w skryptach generujących schemat bazy danych.
  • Umożliwiają tworzenie modelu w oparciu o funkcjonujące bazy danych.
  • Ułatwiają współpracę wielu projektantów.
  • Ułatwiają tworzenie dokumentacji modelu danych.

Model danych

Należy dążyć do tego, aby model danych był jak najlepszy.

  • Model danych powinien być doprowadzony przynajmniej do trzeciej postaci normalnej.
  • Dane nie powinny być redundantne. Wielokrotne przechowywanie tych samych danych dopuszczalne jest w przypadku potrzeby śledzenia zmian w zawartości tabel lub w przypadku systemów transakcyjnych (np. sklepów internetowych, gdzie cena towaru może ulec zmianie).
  • Należy unikać stosowania tricków projektowych. Każdy wykorzystany trick powinien być dokładnie udokumentowany.
  • Należy stosować ograniczenia deklaratywne umożliwiające kontrolę wprowadzanych danych na poziomie systemu bazodanowego.
  • Indeksy należy projektować zgodnie z operacjami dominującymi w tabeli. Duża liczba indeksów założonych na tabele często zapisywane powoduje znaczący spadek wydajności.
  • Nazwy tabel i kolumn powinny być samotłumaczące się, ale nie za długie. Należy unikać skrótów zrozumiałych tylko dla projektanta.
  • Nazwy więzów integralności powinny umożliwiać łatwe zidentyfikowanie poszczególnych więzów.
  • Kolumny z kluczami obcymi powinny mieć taka sama nazwę, jak kolumna z kluczem głównym w tabeli, do której klucz obcy sie odnosi.
  • Należy unikać określania dopuszczalnych wartości kolumn, z wyjątkiem kolumn, których dopuszczalne wartości można zastąpić prawdą/fałszem. Zamiast kolumn typu enum (MySQL) należy stosować tabele słownikowe.
  • Powiązania 1:1 są podejrzane. Ich wystąpienie świadczy na ogół o niepotrzebnym podziale tabel. Dopuszczalne są w zasadzie tylko ze względów wydajnościowych.
  • Klucze główne powinny być jak najprostsze. Należy unikać traktowania jako kluczy głównych kolumn przechowujących np. PESEL, NIP.
  • Każda tabela powinna mieć klucz główny.
  • Kaskadowe/restrykcyjne usuwanie powiązanych danych powinno być dokładnie przemyślane. Blokada możłiwości usunięcia rekordu z powiązanymi danymi może być zrealizowana na poziomie aplikacji korzystającej z bazy danych.
  • Dane przechowywane w tabelach powinny byc typów prostych, chyba że wybrany RDBMS umożliwia przechowywanie kolekcji danych. Przechowywanie w bazie danych zserializowanych obiektów nie jest dobrym pomysłem.
  • Nie należy tworzyć indeksów dla kolumn przechowujących małą liczbę rożnych wartości (prawda/fałsz, płeć itd.)

Systemy zarządzania bazami danych

  • Nie należy korzystać z systemów nie obsługujących kluczy obcych (np. stare wersje MySQL).
  • Jeśli zmiana systemu bazodanowego nie jest prawdopodobna, należy w pełni wykorzystwać możliwości wybranego RDBMS.
  • Wszystkie wartości wykorzystywane w funkcjach lub procedurach składowanych powinny dawać się modyfikować.
  • System zarządzania bazą danych powinien umożliwiać zarządzanie uprawnieniami użytkowników. Dobrym sposobem zarządzania uprawnieniami jest organizowania ich w role.

Projekty funkcjonalne

Każdy system powinien być poprzedzony dokładną analizą funkcjonalną. Należy określić przede wszystkim:

  • liczbę i rodzaj użytkowników systemu;
  • liczbę i rodzaj wejść do systemu;
  • liczbę i rodzaj wyjść z systemu.

Warto stworzyć model przypadków użycia systemu. Dobre scenariusze wykorzystania systemu pozwalają uniknąć wielu nieporozumień i problemów w czasie implementacji systemu."