W oczekiwaniu na rozpoczęcie kolejnego przepływu w tempie Przygotowaliśmy mały materiał autorski z ważnymi wskazówkami dotyczącymi projektowania bazy danych. Mamy nadzieję, że ten materiał będzie dla Ciebie przydatny.
Bazy danych są wszędzie: od najprostszych blogów i katalogów po niezawodne systemy informacyjne i duże sieci społecznościowe. To, czy baza danych jest prosta czy złożona, nie jest tak ważne, jak ważne jest jej prawidłowe zaprojektowanie. Kiedy baza danych zostanie zaprojektowana bezmyślnie i bez jasnego zrozumienia celu, będzie nie tylko nieefektywna, ale dalsza praca z bazą danych będzie prawdziwą udręką, lasem nieprzeniknionym dla użytkowników. Oto kilka wskazówek dotyczących projektowania baz danych, które pomogą Ci stworzyć użyteczny i łatwy w użyciu produkt.
1. Określ do czego służy stół i jaka jest jego konstrukcja
Obecnie metody programistyczne takie jak Scrum czy RAD (Rapid Application Development) pomagają zespołom IT szybko rozwijać bazy danych. Jednak w pogoni za czasem istnieje bardzo duża pokusa, aby od razu zająć się budowaniem bazy, niejasno wyobrażając sobie, jaki jest sam cel i jakie powinny być końcowe rezultaty.
To tak, jakby zespół był nastawiony na wydajną, szybką pracę, ale to miraż. Im głębiej i szybciej zagłębisz się w projekt, tym więcej czasu zajmie identyfikacja i zmiana błędów w projekcie bazy danych.
Pierwszą rzeczą, którą musisz podjąć, jest zdefiniowanie celu Twojej bazy danych. Dla jakiego typu aplikacji jest tworzona baza danych? Czy użytkownik będzie pracował tylko z rekordami i będzie musiał zwracać uwagę na transakcje, czy może bardziej interesuje go analityka danych? Gdzie należy rozmieścić bazę? Czy będzie śledzić zachowania klientów, czy po prostu zarządzać relacjami z klientami?
Im szybciej zespół projektowy odpowie na te pytania, tym płynniejszy będzie proces projektowania bazy danych.
2. Jakie dane wybrać do przechowywania?
Planować naprzód. Myśli o tym, co witryna lub system, dla którego baza danych jest projektowana, będzie działać w przyszłości. Ważne jest, aby wyjść poza proste wymagania specyfikacji technicznych. Tylko proszę, nie myśl o wszystkich możliwych typach danych, jakie użytkownik kiedykolwiek będzie przechowywać. Zamiast tego zastanów się, czy użytkownicy będą mogli pisać posty, przesyłać dokumenty lub zdjęcia lub wymieniać wiadomości. Jeżeli tak jest to należy przydzielić dla nich miejsce w bazie danych.
Współpracuj z zespołem, działem lub organizacją, dla której w przyszłości będzie wspierana baza projektowa. Komunikuj się z ludźmi na różnych poziomach, od specjalistów ds. obsługi klienta po szefów działów. W ten sposób, za pomocą informacji zwrotnej, uzyskasz jasny obraz wymagań firmy.
Nieuchronnie potrzeby użytkowników nawet w tym samym dziale będą sprzeczne. Jeśli się z tym spotkasz, nie bój się polegać na własnym doświadczeniu i znaleźć kompromis, który będzie odpowiadał wszystkim stronom i spełni ostateczny cel, jakim jest baza danych. Bądź pewien: w przyszłości otrzymasz +100500 karmy i górę ciasteczek.
3. Modeluj dane ostrożnie
Modelując dane, należy zwrócić uwagę na kilka kluczowych kwestii. Jak powiedzieliśmy wcześniej, cel bazy danych determinuje, jakich metod użyć w modelowaniu. Jeśli projektujemy bazę danych do przetwarzania rekordów online (OLTP), czyli tworzenia, edycji i usuwania rekordów, korzystamy z modelowania transakcji. Jeśli baza danych musi być relacyjna, najlepiej zastosować modelowanie wielowymiarowe.
Podczas modelowania budowane są modele danych koncepcyjne (CDM), fizyczne (PDM) i logiczne (LDM).
Modele koncepcyjne opisują jednostki i typy danych, które zawierają, a także relacje między nimi. Podziel swoje dane na logiczne fragmenty - to znacznie ułatwia życie.
Najważniejsze jest umiar, nie przesadzaj.
Jeśli encja jest bardzo trudna do sklasyfikowania w jednym słowie lub wyrażeniu, wówczas nadszedł czas na użycie podtypów (obiektów podrzędnych).
Jeśli byt prowadzi własne życie, posiada atrybuty opisujące jego zachowanie i wygląd, a także relacje z innymi obiektami, to można bezpiecznie posłużyć się nie tylko podtypem, ale także nadtypem (bytem nadrzędnym).
Jeśli zlekceważysz tę zasadę, inni programiści będą zdezorientowani w Twoim modelu i nie będą w pełni rozumieć danych oraz zasad ich gromadzenia.
Modele koncepcyjne realizowane są przy użyciu modeli logicznych. Modele te przypominają mapę drogową projektowania fizycznych baz danych. W modelu logicznym identyfikowane są jednostki danych biznesowych, określane są typy danych i określany jest status klucza reguły rządzącej relacjami pomiędzy danymi.
Następnie porównuje się Logiczny Model Danych z wybraną wcześniej platformą DBMS (system zarządzania bazami danych) i uzyskuje się Model Fizyczny. Opisuje, w jaki sposób dane są fizycznie przechowywane.
4. Używaj właściwych typów danych
Użycie niewłaściwego typu danych może skutkować mniej dokładnymi danymi, trudnościami w łączeniu tabel, trudnościami w synchronizacji atrybutów i nadmiernymi rozmiarami plików.
Aby zapewnić integralność informacji, atrybut musi zawierać wyłącznie typy danych, które są dla niego akceptowalne. Jeśli do bazy danych wpisano wiek, należy upewnić się, że w kolumnie znajdują się liczby całkowite składające się maksymalnie z 3 cyfr.
Utwórz minimum pustych kolumn z wartością NULL. Jeśli utworzysz wszystkie kolumny jako NULL, jest to duży błąd. Jeśli potrzebujesz pustej kolumny do wykonania określonej funkcji biznesowej, gdy dane są nieznane lub nie mają jeszcze sensu, możesz ją utworzyć. Przecież nie możemy z góry wypełnić kolumn „Data śmierci” ani „Data zwolnienia”, nie jesteśmy predyktorami wytykającymi palcami niebo :-).
Większość oprogramowania do modelowania (ER/Studio, MySQL Workbench, SQL DBM, gliffy.com) data umożliwia tworzenie prototypów obszarów danych. Zapewnia to nie tylko poprawny typ danych, logikę aplikacji i dobrą wydajność, ale także to, że wartość jest wymagana.
5. Bądź naturalny
Podejmując decyzję, której kolumny w tabeli użyć jako klucza, zawsze rozważ, które pola użytkownik może edytować. Nigdy nie wybieraj ich jako klucza - zły pomysł. Wszystko może się zdarzyć, ale musisz zadbać o to, aby było wyjątkowe.
Najlepiej jest użyć klucza naturalnego lub biznesowego. Ma znaczenie semantyczne, dzięki czemu unikniesz powielania w bazie danych.
O ile klucz biznesowy nie jest unikalny (imię, nazwisko, stanowisko) i powtarza się w różnych wierszach tabeli lub musi ulec zmianie, wówczas wygenerowany klucz sztuczny należy wyznaczyć jako klucz podstawowy.
6. Normalizuj z umiarem
Aby skutecznie uporządkować dane w bazie danych, należy postępować zgodnie z określonymi wytycznymi i normalizować bazę danych. Istnieje pięć normalnych form, których należy przestrzegać.
Dzięki normalizacji unikasz nadmiarowości i zapewniasz integralność danych wykorzystywanych w Twojej aplikacji lub witrynie.
Jak zawsze we wszystkim należy zachować umiar, nawet normalizację. Jeśli w bazie danych znajduje się zbyt wiele tabel z tymi samymi unikalnymi kluczami, oznacza to, że dałeś się ponieść emocjom i nadmiernie znormalizowałeś bazę danych. Nadmierna normalizacja negatywnie wpływa na wydajność bazy danych.
7. Testuj wcześnie, rób często
Plan testów i odpowiednie testowanie powinny być częścią projektu bazy danych.
Najlepszym sposobem przetestowania bazy danych jest ciągła integracja. Symuluj scenariusz „dnia z życia bazy danych” i sprawdź, czy wszystkie przypadki brzegowe są obsługiwane i jakie są prawdopodobne interakcje użytkowników. Im szybciej znajdziesz błędy, tym więcej zaoszczędzisz czasu i pieniędzy.
To tylko siedem wskazówek, które możesz zastosować, aby zaprojektować doskonałą bazę danych dotyczącą produktywności i wydajności. Jeśli będziesz ich przestrzegać, unikniesz większości problemów w przyszłości. Te wskazówki to tylko wierzchołek góry lodowej w modelowaniu baz danych. Istnieje ogromna liczba lifehacków. Z których korzystacie?
Źródło: www.habr.com