W obliczu zbliżającego się rozpoczęcia kolejnej edycji kursu przygotowaliśmy niewielki autorski materiał z ważnymi wskazówkami dotyczącymi konstruowania baz danych. Mamy nadzieję, że ten materiał będzie dla Was przydatny.
Bazy danych są wszechobecne: od najprostszych blogów i katalogów po niezawodne systemy informacyjne i duże sieci społecznościowe. Nie jest tak istotne, czy baza danych jest prosta czy skomplikowana, jak to, aby była właściwie zaprojektowana. Kiedy baza jest zaprojektowana bezmyślnie i bez jasnego zrozumienia celu, staje się nie tylko nieefektywna, ale dalsza praca z nią to prawdziwe męczarnie, nieprzenikniony las dla użytkowników. Oto kilka wskazówek dotyczących konstruowania bazy danych, które pomogą stworzyć użyteczny i łatwy w obsłudze produkt.
1. Określ, do czego służy tabela i jaka jest jej struktura
Dziś takie metody rozwoju, jak Scrum czy RAD (szybkie wytwarzanie aplikacji), pomagają zespołom IT szybko opracowywać bazy danych. Jednak w pościgu za czasem ogromny jest pokusa, by od razu zanurzyć się w budowę bazy, nie mając jasno określonego celu i końcowych wyników.
Jakby zespół dążył do efektywnej, szybkiej pracy, ale to miraż. Im dalej i szybciej zanurzać się w projekt, tym więcej czasu zajmie wykrycie i wprowadzenie poprawek w projekcie bazy.
Dlatego pierwsze, co należy rozstrzygnąć, to określenie celu dla Twojej bazy danych. Do jakiego typu aplikacji jest rozwijana baza? Użytkownik tylko będzie pracować z rekordami i należy zwrócić uwagę na transakcje, czy też bardziej interesuje go analiza danych? Gdzie baza ma być uruchomiona? Czy będzie śledzić zachowania klientów, czy po prostu zarządzać relacjami między nimi?
Im wcześniej zespół projektowy odpowie na te pytania, tym łagodniej i płynniej przebiegnie proces projektowania bazy danych.
2. Jakie dane wybrać do przechowywania?
Planowanie z wyprzedzeniem. Zastanów się, co w przyszłości będzie robić strona lub system, dla których projektowana jest baza danych. Ważne jest, aby wyjść poza proste wymagania specyfikacji technicznej. Tylko proszę, nie zaczynaj od razu myśleć o wszystkich możliwych typach danych, które kiedykolwiek będą przechowywane przez użytkowników. Lepiej pomyśl, czy użytkownicy będą mogli pisać posty, przesyłać dokumenty lub zdjęcia, czy wymieniać się wiadomościami. Jeśli tak, w bazie należy zarezerwować miejsce na nie.
Pracuj z zespołem, departamentem lub organizacją, dla których w przyszłości będzie wspierany projektowana baza. Komunikuj się z ludźmi na różnych poziomach, od specjalistów obsługi klienta do kierowników działów. Dzięki informacji zwrotnej uzyskasz jasny obraz wymagań firmy.
Niezbędne będzie pogodzenie potrzeb użytkowników nawet w ramach jednego departamentu. Jeśli się z tym zmierzysz, nie bój się polegać na własnym doświadczeniu i znaleźć kompromis, który usatysfakcjonuje wszystkie strony i zaspokoi ostateczny cel bazy danych. Bądź pewny: w przyszłości zyskasz +100500 punktów w karmie oraz stos ciasteczek.
3. Modeluj dane ostrożnie
Istnieje kilka kluczowych kwestii, na które warto zwrócić uwagę podczas modelowania danych. Jak już wcześniej wspomniano, od celu bazy danych zależy, jakie metody zastosować przy modelowaniu. Jeśli projektujemy bazę danych do operacyjnego przetwarzania zapisów (OLTP), w innych słowach do ich tworzenia, edytowania i usuwania, to stosujemy modelowanie transakcji. Jeśli natomiast baza danych ma być relacyjna, najlepiej zastosować modelowanie wielowymiarowe.
Podczas modelowania tworzone są modele koncepcyjne (CDM), fizyczne (PDM) i logiczne (LDM).
Modele koncepcyjne opisują byty oraz typy danych, które zawierają, a także relacje między nimi. Dzielenie danych na logiczne kawałki sprawia, że życie staje się znacznie prostsze.
Najważniejsza jest miara, nie przesadzaj.
Jeśli byt jest bardzo trudny do skategoryzowania jednym słowem lub frazą, nadeszła pora na użycie typów podrzędnych (bytów podrzędnych).
Jeśli jednak byt prowadzi własne życie, ma atrybuty, które opisują jego zachowanie i jego wygląd, a także relacje z innymi obiektami, to można śmiało używać nie tylko podtypu, ale i supertypu (rodzicielskiego bytu).
Ignorując tę zasadę, inni programiści pogubią się w twoim modelu i nie do końca będą rozumieć dane i zasady ich zbierania.
Modele koncepcyjne realizowane są za pomocą logicznych. Modele te działają jak mapa drogowa do projektowania fizycznej bazy danych. W modelu logicznym wyróżnia się byty danych biznesowych, definiuje się typy danych, status klucza oraz zasady regulujące relacje między danymi.
Następnie model logiczny danych jest zestawiany z wcześniej wybraną platformą systemu zarządzania bazą danych (DBMS), zarządzania bazami danych) otrzymując model fizyczny. Opisuje on sposób fizycznego przechowywania danych.
4. Używaj odpowiednich typów danych.
Zastosowanie niewłaściwego typu danych może prowadzić do mniej dokładnych wyników, trudności w łączeniu tabel, synchronizacji atrybutów oraz zwiększenia rozmiarów plików.
Aby zapewnić integralność informacji, atrybut powinien zawierać tylko akceptowalne dla niego typy danych. Jeśli do bazy danych trafia wiek, upewnij się, że w kolumnie przechowywane są liczby całkowite o maksymalnie 3 cyfrach.
Twórz jak najmniej pustych kolumn z wartością NULL. Jeśli tworzysz wszystkie kolumny jako NULL, to poważny błąd. Jeśli jednak potrzebujesz pustej kolumny do realizacji konkretnej funkcji biznesowej, gdy dane są nieznane lub jeszcze nie mają sensu, nie wahaj się jej stworzyć. Nie możemy przecież z góry uzupełniać kolumn ‘Data śmierci’ czy ‘Data rozwiązania umowy’, przecież nie jesteśmy wróżbitami, aby zgadywać :-).
Większość oprogramowania do modelowania (ER/Studio, MySQL Workbench, SQL DBM, gliffy.com) danych umożliwia tworzenie prototypów obszarów danych. Zapewnia to nie tylko odpowiedni typ danych, logikę aplikacji i dobrą wydajność, ale także obowiązkowe przypisanie wartości.
5. Preferuj naturalne
Kiedy decydujesz, którą kolumnę w tabeli wybrać jako klucz, zawsze zwracaj uwagę, które pola mogą być edytowane przez użytkownika. Nigdy nie wybieraj ich jako klucza — to zły pomysł. Może się zdarzyć wszystko, a ty musisz zapewnić unikalność.
Najlepiej używać naturalnego lub biznesowego klucza (natural key). Ma on znaczenie semantyczne, dzięki czemu unikniesz duplikacji w bazie danych.
Jeśli tylko klucz biznesowy nie jest unikalny (imię, nazwisko, stanowisko) i powtarza się w różnych wierszach tabeli lub musi być zmieniany, to jako klucz podstawowy warto wyznaczyć wygenerowany sztuczny klucz (artificial key).
6. Normalizuj umiarkowanie
Aby efektywnie zorganizować dane w bazie danych, należy przestrzegać zestawu zaleceń i normalizować bazę danych. Istnieje pięć normalnych form, których należy przestrzegać.
Dzięki normalizacji unikniesz nadmiarowości i zapewnisz integralność danych wykorzystywanych w aplikacji lub na stronie internetowej.
Jak zawsze, wszystko powinno być w umiarze, nawet normalizacja. Jeśli w bazie danych jest zbyt wiele tabel z identycznymi unikalnymi kluczami, to przesadziłeś i nadmiernie znormalizowałeś bazę danych. Nadmierna normalizacja negatywnie wpływa na wydajność bazy danych.
7. Testuj wcześnie, testuj częściej
Plan testów i odpowiednie testowanie powinny być częścią projektowania bazy danych.
Najlepiej testować bazę danych przez Continuous Integration (ciągłą integrację). Modeluj scenariusz „Jeden dzień z życia bazy danych” i sprawdzaj, czy wszystkie przypadki brzegowe są obsługiwane, jakie interakcje użytkowników są prawdopodobne. Im wcześniej znajdziesz błędy, tym więcej zaoszczędzisz zarówno czasu, jak i pieniędzy.
To zaledwie siedem wskazówek, dzięki którym możesz zaprojektować znakomitą bazę danych pod względem wydajności i efektywności. Jeśli będziesz ich przestrzegać, unikniesz większości przyszłych bóli głowy. Te wskazówki to tylko wierzchołek góry lodowej w modelowaniu bazy danych. Istnieje ogromna liczba życiowych sztuczek. Z jakich korzystasz?
Źródło: habr.com
