Jakie są etapy projektowania bazy danych?

Projektowanie bazy danych jest jednym z najważniejszych czynników wpływających na wydajność aplikacji. W związku z tym, jak dobrze zaprojektowana baza danych ma ogromne znaczenie. Projektowanie bazy danych polega na efektywnym organizowaniu danych w oparciu o przepływy pracy produktów, przyszłą mapę drogową i oczekiwane wzorce użytkowania.

Wynikiem ćwiczenia projektowania bazy danych jest model danych. Model danych reprezentuje wszystkie obiekty, encje, atrybuty, relacje i ograniczenia w systemie. Mówiąc ogólnie, modele danych mogą być dwojakiego rodzaju:logiczne lub fizyczne . Reprezentacja modelu danych odbywa się poprzez utworzenie diagramu ER, znanego również jako diagram relacji encji, diagram ERD lub diagram bazy danych.

Fizyczny model danych odnosi się do rzeczywistych szczegółów implementacji w bazie danych. Z drugiej strony, logiczny model danych abstrahuje od technicznych aspektów implementacji. To sprawia, że logiczny model danych jest użyteczny dla firmy. Jedną z kluczowych różnic między tymi dwoma modelami jest to, że model logiczny jest niezależny od bazy danych, podczas gdy model fizyczny musi być specyficzny dla używanej bazy danych.

Właściwy projekt bazy danych jest często niedoceniany i zaniedbywany podczas tworzenia aplikacji. Koszt tego zaniedbania jest zwykle uświadamiany znacznie później, gdy pojawiają się nowe funkcje aplikacji lub gdy stare funkcje wymagają zmiany. Wtedy projekt bazy danych przestaje mieć sens. Chociaż nie jest możliwe zabezpieczenie projektu bazy danych w przyszłości, bardzo możliwe jest podjęcie wysiłku, aby jak najlepiej zrozumieć biznesowe przypadki użycia i odpowiednio zaprojektować bazę danych. Przeczytaj więcej o wskazówkach dotyczących lepszego projektowania baz danych tutaj.

Mając to na uwadze, przejdźmy przez kolejne etapy projektowania bazy danych.

Krok 1:Zbierz wymagania biznesowe

Pierwszym krokiem jest rozmowa z firmą o jej wymaganiach. Jeśli rozmowa jest efektywna, powinna zaowocować wystarczającą ilością informacji do rozpoczęcia pracy nad konceptualnym modelem danych, który jest abstrakcją modelu logicznego. Rozmowa z biznesem przede wszystkim zapewnia pełny obraz procesów biznesowych, który z kolei dostarcza informacji o różnych punktach danych, które są ważne dla firmy do przechwytywania i śledzenia. Na przykład w modelu rezerwacji taksówki warto zadać sobie następujące pytania:

Czy firma chce, aby dane śledzenia pojazdów znajdowały się w bazie danych, niezależnie od tego, czy jest aktywna podróż, czy nie? Jeśli tak, to pole vehicle_trip_id w tabeli vehicle_trips byłoby nieważne . W przeciwnym razie nie będzie nullable .
Czy firma chce historii zmian w trip_status? przechowywane w bazie danych? Jeśli tak, to za każdym razem trip_status zmiany, pojawi się kolejny rekord w trips stół. W przeciwnym razie za każdym razem, gdy trip_status zmiany, trip_status zostanie zaktualizowany.

Jak pokazano w tym przykładzie, w oparciu o dane wejściowe z firmy, ostatecznie wybrałbyś jedną opcję zamiast drugiej. Spowodowałoby to zmianę zainteresowanych podmiotów i ich relacji.

Zbieranie wymagań obejmuje również zazwyczaj rozpoczęcie rozmowy na temat bezpieczeństwa danych, na przykład tego, które dane należy zamaskować i zaszyfrować. Ćwiczenie gromadzenia wymagań skutkuje powstaniem dokumentu wymagań często wspieranego roboczym projektem koncepcyjnego modelu danych.

Krok 2:Zrozumienie planu biznesowego

Firmy cały czas zmieniają swoje procesy; ich zdolność do adaptacji sprawia, że są mniej podatne na porażkę. Zmiana procesów biznesowych oznacza zmianę przepływów pracy i modeli danych. Chociaż nie jest możliwe poznanie tych zmian z dużym wyprzedzeniem, z pewnością można być na bieżąco z planem biznesowym.

Na przykład, jeśli firma planuje kierować reklamy na nowy region geograficzny, model musiałby uwzględniać obsługę języków, waluty, strefy czasowe i tak dalej. Korzyści płynące ze zrozumienia długoterminowego planu biznesowego często pojawiają się w płynniejszym przejściu do nowych procesów biznesowych.

Pozwólcie, że przedstawię jeszcze jeden przykład, który dotyczy nieustannej ewolucji priorytetów biznesowych. Na początku pandemii COVID-19 źle wpłynął na biznes taksówkowy. Jako firma taksówkarska chcesz działać zapobiegawczo, aby zapewnić ludzi, że robisz wszystko, aby Twoja podróż w taksówce była jak najbardziej bezpieczna, że pojazd jest codziennie dezynfekowany, że kierowca w ogóle nosi maskę razy i że w kabinie jest dostępny środek do dezynfekcji rąk. Teraz, aby uchwycić wszystkie te informacje, zmiany w dwóch jednostkach, drivers i vehicles , byłoby wymagane. Kilka pól flag logicznych muszą zostać dodane do tych jednostek, aby zaspokoić ten biznesowy przypadek użycia.

Krok 3:Zidentyfikuj jednostki i atrybuty

Po zebraniu wymagań biznesowych informacje można wykorzystać do identyfikacji jednostek wraz z podstawowym zestawem atrybutów. Jedna lub więcej jednostek zazwyczaj mapuje się bezpośrednio na procesy biznesowe, a relacje między tymi jednostkami również naśladują przepływ pracy procesu biznesowego.

Ten krok służy również do określenia, które atrybuty będą działać jako identyfikatory w encjach. Identyfikatory przekładają się na klucze podstawowe w modelu fizycznym. Ponadto powszechne jest również określanie typów danych dla wszystkich atrybutów w tym kroku.

Na przykład w modelu rezerwacji taksówek musiałbyś określić atrybuty, które będą obowiązywać jako pola obowiązkowe do rejestracji użytkowników i kierowców z aplikacji rezerwacyjnej. Rejestracja użytkownika odbywałaby się za pomocą user_phone a rejestracja kierowcy odbywałaby się za pomocą driver_phone .

Podobnie, inne jednostki i atrybuty są identyfikowane na tym etapie, po zmapowaniu ich do przepływów pracy procesów biznesowych.

Krok 4:Zidentyfikuj relacje

Po zidentyfikowaniu jednostek i ich atrybutów następnym krokiem jest zdefiniowanie relacji między jednostkami na podstawie biznesowych przepływów pracy, które zostały udokumentowane w fazie zbierania wymagań. Oprócz ustalenia, że istnieje relacja między dwoma podmiotami, ważne jest również, aby określić, który z poniższych czterech typów relacji istnieje między nimi. Rozważ dwa dowolne byty, A i B:

Jeden do jednego → Jeden rekord w A odpowiada co najwyżej jednemu rekordowi w B.
Jeden do wielu → Jeden rekord w A odpowiada wielu rekordom w B.
Wiele do jednego → Wiele rekordów w A odpowiada co najwyżej jednemu rekordowi w B.
Wiele do wielu → Wiele rekordów w A odpowiada wielu rekordom w B.

W modelu rezerwacji taksówki zastosowano tylko jeden rodzaj relacji, tj. jeden-do-wielu. Weźmy na przykład relację między users i trips jako przykład. W modelu przyjęto założenie, że tylko jeden użytkownik może być powiązany z podróżą, co oznacza, że nie ma wspólnych lub połączonych taksówek. Ale gdyby istniały wspólne lub połączone taksówki, prawdopodobnie istniałaby relacja wiele-do-wielu między users i trips , jeśli wielu użytkowników współdzieli ten sam trip_id .

Krok 5:Utwórz logiczny diagram ER

Po zdefiniowaniu encji, atrybutów i relacji encji następnym krokiem jest narysowanie diagramu ER. Wszystkie powyższe kroki można wykonać w Vertabelo. Nie ma sztywnych i szybkich reguł dotyczących sposobu, w jaki ma być wykonane modelowanie logiczne, z możliwym wyjątkiem notacji referencyjnej.

Na przykład spójrz na poniższy przykład logicznego diagramu ER. Przechwytuje prosty biznesowy przepływ pracy firmy taksówkowej, w którym użytkownik może zarezerwować przejazd z możliwością śledzenia pojazdu.

Krok 6:Sprawdź poprawność logicznego diagramu ER

Modelowanie logiczne to proces, w którym wiele informacji biznesowych należy przełożyć na projekt bazy danych. Bez dokładnych kontroli ta faza tworzenia bazy danych jest podatna na błędy, które na późniejszym etapie mogą okazać się dość kosztowne.

Aby się tym zająć, Vertabelo ma dokładną listę sprawdzeń, które można wykonać na modelu logicznym. Kontrole można przeprowadzać na wszystkich poziomach szczegółowości, od modelu jako całości po poszczególne atrybuty i wszystko pomiędzy. Niektóre z prostych sprawdzeń to:

Nazwy podmiotów, atrybutów, relacji itp. nie mogą być puste i muszą być niepowtarzalne.
Eencja musi mieć co najmniej 1 atrybut.
Identyfikatory (PK) muszą być zdefiniowane dla każdej jednostki.
Model musi używać jednego z wymienionych typów danych dla atrybutów.

Wszystkie te sprawdzenia są opcjonalne i można je skonfigurować tak, aby można je było pominąć, jeśli istnieje inna platforma walidacji. Właściwa walidacja Vertabelo pomaga przejść do następnego kroku z minimalnym możliwym tarciem.

Krok 7:Utwórz fizyczny diagram ER

Po utworzeniu logicznego diagramu ER następnym krokiem jest utworzenie fizycznego modelu danych. Fizyczny model danych będzie specyficzny dla bazy danych, w której chcesz wdrożyć model danych. Wszystkie bazy danych mają swoją unikalną implementację reguł nomenklatury, typów danych i ograniczeń. Z tego powodu język definicji danych (DDL) często różni się w zależności od bazy danych.

Aby utworzyć fizyczny model danych, wykonaj następujące kroki:

Znajdź najbliższy typ danych w docelowej bazie danych, aby zastąpić ogólny typ danych wybrany w logicznym modelu danych.
Przestrzegaj zasad nazewnictwa dla tabel, kolumn i ograniczeń zgodnie z docelową bazą danych.
Zmodyfikuj model, aby dopasować go do wstępnie zdefiniowanych przepływów pracy zapytań. Zwykle powoduje to zwiększenie redundancji w celu zapisywania połączeń.
Na koniec możesz tworzyć indeksy, partycje, klucze dystrybucji i klucze sortowania. To wtedy możesz tworzyć w modelu dowolne modyfikacje poprawiające wydajność.

Te kroki można wykonać za pomocą dowolnego narzędzia do modelowania danych, którego można użyć do utworzenia modelu danych od podstaw. Vertabelo ma jednak opcję konwersji logicznego modelu danych na pełnoprawny fizyczny model danych dla wszystkich głównych systemów baz danych, takich jak MySQL, PostgreSQL, Oracle, Microsoft SQL Server, Amazon Redshift, Google BigQuery i innych. Gdy logiczny model danych zostanie przekonwertowany na fizyczny model danych, możesz przejść do czterech omówionych przez nas kroków.

Vertabelo ma również opcję dodawania skryptów przed i po wdrożeniu na poziomie tabeli wraz z wszelkimi komentarzami na bardzo szczegółowym poziomie modelu. Komentarze okazują się przydatne w przypadku korzystania z funkcji generowania dokumentacji oferowanej przez Vertabelo. Dokument bazy danych można wyeksportować w dowolnym z następujących trzech formatów:HTML, PDF lub DOCX.

Kontynuując przykład rezerwacji taksówki, spójrzmy na fizyczny model danych generowany przez Vertabelo.

Krok 8:Sprawdź poprawność fizycznego diagramu ER

Podobnie jak walidowano logiczny diagram ER, Vertabelo ma narzędzie do walidacji fizycznych diagramów ER z kilkoma dodatkowymi kontrolami, takimi jak czy istnieją FK i czy długość nazwy tabeli lub nazwy kolumny przekracza limit na podstawie wybranej bazy danych.

Walidacja nie musi być przeprowadzana jawnie. Dzieje się tak, gdy schemat jest modyfikowany. Problemy z modelem należą do jednej z trzech kategorii:błędy, ostrzeżenia i wskazówki w kolejności malejącej ważności. Jest przydatny, dobrze napisany artykuł, który opowiada o typowych błędach popełnianych podczas procesu projektowania bazy danych.

Krok 9:Napraw problemy z fizycznym diagramem ER

Wyniki walidacji mogą wskazywać problemy, które należy naprawić. Niektóre z najczęstszych problemów to:

Brakujące klucze obce, w których zdefiniowano relacje encji.
Brakujące klucze podstawowe z tabel.
Nieobsługiwane typy danych dla wybranej bazy danych.

Po rozwiązaniu tych i innych podobnych problemów model jest gotowy do wyeksportowania do możliwego do wdrożenia skryptu SQL dla wybranego systemu zarządzania bazą danych.

Krok 10:Wygeneruj skrypty DDL do wdrożenia modelu

Projektowanie bazy danych to nie tylko tworzenie diagramów ER. Ćwiczenie modelowania danych przy użyciu diagramów ER jest skuteczne tylko wtedy, gdy daje coś, co można wdrożyć. Vertabelo posiada wygodną opcję eksportu modelu fizycznego do gotowego do wdrożenia skryptu SQL. Po wygenerowaniu wszelkie oczekujące problemy można rozwiązać bezpośrednio w skrypcie SQL.

Jednak zmiana wygenerowanego skryptu SQL nie jest zalecana. Powoduje dryf między fizycznym modelem danych a skryptem SQL wdrożonym w bazie danych, co może również oznaczać dryf między rzeczywistymi tabelami a dokumentacją bazy danych.

Teraz, gdy dotarliśmy do końca procesu projektowania bazy danych, spójrzmy na kod SQL wygenerowany przez Vertabelo.

Podziel się swoimi przemyśleniami

Projektowanie baz danych to działanie o dużym znaczeniu w tworzeniu oprogramowania. Dziedzina projektowania baz danych ewoluowała na przestrzeni lat dzięki nowym sposobom przedstawiania projektu dla biznesu, dla inżynierów i dla analityków danych. Często prowadziło to do powstania nowych typów diagramów, standardów modelowania i notacji. Znaczna część ewolucji została omówiona w sekcji z podstawami projektowania.

Chętnie zobaczymy Twoje doświadczenia w projektowaniu baz danych. Napisz do nas na [email protected].