Wskazówki dotyczące lepszego projektowania baz danych

Przez lata pracy jako modelarz danych i architekt baz danych zauważyłem, że istnieje kilka zasad, których należy przestrzegać podczas modelowania i tworzenia danych. Tutaj opisuję kilka wskazówek w nadziei, że mogą ci pomóc. Wymieniłem wskazówki w kolejności, w jakiej występują podczas cyklu życia projektu, zamiast wymieniać je według ważności lub częstości występowania.

1. Planuj z wyprzedzeniem

Niepowodzenie w planowaniu oznacza niepowodzenie.

Alan Lakein

Jednym z problemów, który zauważyłem, jest to, że modelowanie danych występuje w tym samym czasie, co tworzenie oprogramowania. To jest jak budowanie fundamentu przed ukończeniem planów. W przeszłości planowanie wydawało się oczywistym krokiem przed rozpoczęciem rozwoju. Zespoły programistyczne nie tworzyłyby baz danych bez planowania, podobnie jak architekci nie budowaliby budynków bez planów.

Podczas tworzenia aplikacji bardzo ważne jest zrozumienie natury danych.

Planowanie jest często ignorowane, aby programiści mogli po prostu „zacząć kodować”. Projekt się rozpoczyna, a gdy pojawiają się problemy, nie ma czasu na ich rozwiązanie. Deweloperzy idą na skróty z zamiarem naprawienia ich później, ale to rzadko, jeśli w ogóle się zdarza.

Staranne planowanie jest sposobem, aby upewnić się, że otrzymasz odpowiednią bazę danych, która nie zostanie zhakowana razem. Jeśli nie poświęcisz czasu i wysiłku z góry na adresowanie danych wymaganych przez procesy, zapłacisz za to później, korzystając z bazy danych, którą należy przerobić, wymienić lub zezłomować.

Nawet jeśli planowanie nie zawsze jest wykonywane, wielu projektantów danych nadal postępuje zgodnie z tymi wytycznymi. Nie oznacza to, że możemy z góry przewidzieć każdą potrzebę projektową, ale większość modelarzy uważa, że ​​warto podjąć wysiłek, aby zrozumieć dane i ich wykorzystanie. Nie chciałbyś projektu do przetwarzania transakcji, gdy potrzebne jest tworzenie raportów analitycznych.

Czasy się zmieniły; Metodologie zwinne są bardziej rozpowszechnione, więc zespoły bazodanowe muszą przemyśleć swoje podejście do modelowania danych. W Agile model domeny z przypadków użycia jest używany zamiast diagramów relacji encji. Jednak potrzeba planowania nie zmniejszyła się. Musimy zrozumieć dane i ich przeznaczenie. Ogólnie rzecz biorąc, kilka pierwszych Sprintów musi koncentrować się na projektowaniu danych.

Więc to nie Agile jest problemem dla modelarzy baz danych, ale raczej dla osób, które nie rozumieją natury danych. Niektórzy uważają, że tworzenie baz danych to to samo, co tworzenie aplikacji. Modelowanie baz danych i tworzenie oprogramowania są różne i wymagają odpowiedniego ukierunkowania.

Baza danych stanowi rdzeń większości aplikacji. Musisz poświęcić czas na przeanalizowanie wymagań i sposobu, w jaki model danych je spełni. Zmniejsza to szansę, że rozwój straci kierunek i kierunek.

Deweloperzy muszą zrozumieć znaczenie danych i ich wkład w proces rozwoju. Żyjemy w erze informacji. Aplikacje wyświetlają i manipulują danymi. To informacje zawarte w danych nadają sens aplikacji.

Nie jest możliwe przewidzenie każdego wymagania ani każdego problemu, ale ważne jest, aby przygotować się na problemy poprzez staranne planowanie.

2. Udokumentuj swój model

Podczas tworzenia modelu danych wszystko wydaje się oczywiste. Nazywasz przedmioty tak, aby ich przeznaczenie było oczywiste, a wszyscy zrozumieli znaczenie po prostu czytając nazwę. Może to prawda, ale nie jest to tak oczywiste, jak mogłoby się wydawać. Wybierając nazwy tabel i kolumn, wyjaśnij, jakie będzie zastosowanie każdego obiektu. Z biegiem czasu znaczenie obiektów będzie niejasne bez dokumentacji.

Stosowanie konwencji nazewnictwa to jeden krok w kierunku efektywnej dokumentacji. Kiedy będziesz musiał wprowadzić zmiany w przyszłości, docenisz każdą istniejącą dokumentację. Krótki, prosty dokument opisujący podjęte przez Ciebie decyzje i opisujący projekt pomoże wyjaśnić wybór projektu w tym czasie.

Potrzebujesz wystarczającej dokumentacji, aby baza danych mogła być zarządzana przez nowego administratora i aby mógł zrozumieć znaczenie bez konieczności wracania do Ciebie w celu wyjaśnienia. Jeśli model danych i środowisko nie są udokumentowane, trudno jest je utrzymać lub zmienić w miarę zmiany wymagań.

Do pewnego stopnia dokumentacja ma niewiele wspólnego z modelowaniem danych. Dokumentacja dotyczy komunikacji projektu i uczynienia go zrozumiałym w przyszłości.

Dokumentacja jest często refleksją. Gdy harmonogramy są krótkie, dokumentacja jest ignorowana. Jest to jednak dług techniczny o wysokich kosztach. Wykraczanie na skróty podczas cyklu rozwoju spowoduje w przyszłości naliczanie kosztów zmian w bazie danych, identyfikacji problemów, śledzenia błędów oraz zrozumienia modelu danych i charakteru danych.

Na przykład modele danych często mają pole „ID” jako klucz podstawowy tabeli lub część nazwy klucza. Może to być klucz podstawowy, taki jak TransactionID na Transaction stół. Jeśli niektóre tabele używają „Liczby” jako części nazwy klucza, dobrze jest udokumentować dlaczego. Być może ReferenceNumber jest używana jako nazwa klucza podstawowego w wiadomości, ponieważ tak nazywa się odwołanie w obszarze biznesowym. Na przykład w usługach finansowych komunikaty finansowe zazwyczaj zawierają numer referencyjny.

Udokumentuj definicję tabel, kolumn i relacji, aby programiści mieli dostęp do informacji. Dokumentacja musi opisywać oczekiwania dotyczące struktury bazy danych.

W narzędziu Vertabelo mogę natychmiast dołączyć komentarze do dowolnego elementu:tabel, kolumn, referencji, kluczy alternatywnych, co oznacza, że ​​dokumentacja jest przechowywana natychmiast z moim modelem, a nie w jakimś dodatkowym dokumencie, który należy prowadzić oddzielnie.

Słaba dokumentacja lub jej brak często wynika z krótkowzrocznego myślenia, ale nie należy lekceważyć jej znaczenia. Jest to wciąż problem do rozwiązania.

3. Postępuj zgodnie z konwencjami

Konwencje nazewnictwa mogą nie wydawać się ważne podczas projektowania. W rzeczywistości nazwy zapewniają wgląd w zrozumienie modelu. Stanowią wprowadzenie i powinny być logiczne.

Niespójne nazewnictwo nie ma sensu. To tylko frustruje programistów, którzy muszą uzyskać dostęp do danych, administratorów bazy danych i modelarzy, którzy muszą wprowadzać zmiany w przyszłości.

Gdy „ID” jest używane dla niektórych sztucznych kluczy, ale niektóre tabele używają innej konwencji nazewnictwa (np. Numer), programiści, analitycy i administratorzy baz danych mogą tracić czas na zrozumienie wyjątków. Słabe konwencje nazewnictwa również prowadzą do błędów w rozwoju, ponieważ nazewnictwo nie jest spójne.

W parze z dokumentacją, używanie konwencji nazewnictwa sprawia, że ​​w przyszłości ktoś będzie mógł zrozumieć model. Nie przełączaj się losowo między używaniem „ID” (np. CustomerID ) i „Numer” (AccountNumber ) jako klucze do tabel. Dokonuj wyjątków od konwencji tylko wtedy, gdy są one uzasadnione. Udokumentuj, czym jest wyjątek i dlaczego konwencja nie jest przestrzegana.

To samo dotyczy tajemniczych nazw, takich jak „XRT1” – czy to rozszerzone tabele referencyjne? Twoje przypuszczenia są równie dobre jak moje. Mam nadzieję, że projektant wiedział, dlaczego wybrał tak tajemniczą nazwę, ale wątpię, aby następna osoba, która uzyska dostęp do bazy danych, mogła odgadnąć przyczynę.

Konwencje nazewnictwa to kwestia osobistego wyboru. Upewnij się, że decyzje są spójne i udokumentowane.

Jeśli udało mi się przekonać Cię do zastosowania konwencji nazewnictwa w projekcie bazy danych, zachęcam do przeczytania mojego następnego artykułu w całości poświęconego temu tematowi.

4. Pomyśl uważnie o klawiszach

Klucze często wywołują kontrowersje:klucze podstawowe, klucze obce i klucze sztuczne. Tabele wymagają klucza podstawowego, który identyfikuje każdy wiersz. Sztuką jest zdecydować, które kolumny powinny być częścią klucza podstawowego i jakie wartości należy uwzględnić.

Do prawidłowej normalizacji każda tabela potrzebuje klucza identyfikującego. Należy zagwarantować wyjątkowość. Jednak klucze naturalne i klucze podstawowe nie muszą być takie same. W rzeczywistości mogą nie być, o ile tabela ma naturalny klucz.

Niektórzy twórcy modeli danych wolą sztuczny klucz do unikalności. Jednak niektórzy modelarze wolą naturalny klucz, aby zapewnić integralność danych.

Czy zatem powinniśmy używać klucza naturalnego jako klucza podstawowego? Pojawia się jedno wyzwanie, jeśli trzeba zmienić klucz naturalny. Jeśli klucz naturalny składa się z wielu kolumn, może być konieczne wprowadzenie zmian w wielu miejscach. Kolejnym wyzwaniem jest użycie sztucznego klucza jako jedynego klucza do tabeli.

Jako przykład możesz mieć tabelę przechowującą informacje o produktach. Tabela może być zdefiniowana za pomocą sztucznego klucza, takiego jak sekwencja, kod dla krótkiej nazwy alfabetycznej produktu oraz definicja produktu. Jeżeli unikatowość zapewnia tylko sztuczny klucz, mogą występować dwa wiersze z tym samym kodem produktu. Czy to ten sam produkt, który został wprowadzony dwukrotnie? Być może bardziej odpowiedni będzie klucz z kodem produktu.

5. Używaj kontroli integralności ostrożnie

Aby zapewnić integralność danych, potrzebujemy kluczy obcych i ograniczeń. Uważaj, aby nie nadużywać ani nie wykorzystywać tych kontroli integralności.

Tabele domen skutecznie egzekwują integralność. Tabele domen działają dobrze, gdy istnieje wiele wartości do sprawdzenia lub wartości do sprawdzenia często się zmieniają.

Jednym z problemów może być to, że programiści decydują, że aplikacja będzie sprawdzać integralność. Problem polega na tym, że dostęp do centralnej bazy danych może mieć wiele aplikacji. Ponadto zazwyczaj chcesz chronić dane tam, gdzie się znajdują:w bazie danych.

Jeśli możliwe wartości są ograniczone lub mieszczą się w zakresie, preferowane może być ograniczenie sprawdzania. Załóżmy, że wiadomości są definiowane jako przychodzące lub wychodzące, w którym to przypadku klucz obcy nie jest potrzebny. Ale dla czegoś takiego jak ważne waluty, chociaż mogą wydawać się statyczne, w rzeczywistości zmieniają się od czasu do czasu. Kraje dołączają do unii walutowej, a waluty się zmieniają.

Aplikacje powinny również przeprowadzać kontrole integralności, ale nie polegają tylko na aplikacji do sprawdzania integralności. Zdefiniowanie reguł integralności w bazie danych gwarantuje, że te reguły nigdy nie zostaną naruszone. W ten sposób dane przez cały czas spełniają określone zasady integralności.

6. Nie zapomnij o indeksach w swoim projekcie

Niektóre projekty indeksowania są przydatne podczas modelowania bazy danych, nawet jeśli indeksy mogą ulec zmianie podczas rzeczywistego wdrażania i użytkowania. Oczywiście możliwe jest posiadanie zbyt wielu indeksów, podobnie jak możliwe jest posiadanie zbyt małej.

Indeksowanie jest procesem ciągłym. Podczas projektowania rozpoczynasz proces na swoim modelu. Prace projektowe dotyczą podstawowych kluczy i ograniczeń.

Indeksy są ważne przy rozważaniu zapytań dotyczących danych. Podczas modelowania należy wziąć pod uwagę sposób, w jaki dane będą odpytywane. Uważaj, aby nie przeindeksować. Indeksowanie obraca się wokół optymalizacji zapytań.

7. Unikaj typowych tabel przeglądowych

Często widziałem powszechną tabelę przeglądową dla par atrybutów. Uważa się, że zdefiniowanie jednej, ogólnej tabeli domen upraszcza projekt. Ten styl tabeli domen stanowi abstrakcyjną definicję przechowywania tekstu. Słyszałem, że nazywa się to tabelą „Dozwolona wartość” lub „Właściwe wartości”, ale termin „ZMROCZYĆ” został ukuty dla tego antywzorca w 2006 roku:masowo zunifikowany klucz kodu.

Tabele MUCK zawierają niepowiązane dane.

Na przykład możesz mieć tabelę, która definiuje domenę, wpis i opis. Wracając do powyższego przykładu wiadomości, dwa wpisy mogą być:

Teraz dodaj wpisy dla innej domeny:

To tylko bałagan. Co oznacza tabela?

Dla zabawy wymodelowałem prosty przykład tabeli MUCK (lub OTLT, „Jedna prawdziwa tabela przeglądowa”, jeśli jesteś fanem Tolkiena) i dodałem kilka komentarzy. Pamiętaj, że jest to antywzorzec i nie polecam używania go w swoim modelu danych.

W przypadku tabel MUCK nie można zdefiniować ograniczeń. MUCK może stać się wieloma rzędami bez żadnego znaczenia. Kiedy musisz wysłać zapytanie do innej tabeli, aby zrozumieć znaczenie pola, nie jest to idealne rozwiązanie.

Te tabele „wszystko ujdzie” utrudniają lub nawet uniemożliwiają kontrolę integralności. Jednym z powodów, dla których te tabele mogą być tworzone, jest fakt, że kilka tabel w bazie danych ma podobną definicję. Wtedy kontrola integralności danych staje się niemożliwa. Ponadto ich rozmiar może stać się dość duży.

Normalizacja powinna odejść od tabel MUCK. Pojedyncza tabela powinna reprezentować jedną domenę; zamiast pojedynczej tabeli (MUCK) reprezentującej wszystkie domeny. Bez tabel MUCK możemy wprowadzić ograniczenia kluczy obcych.

Używaj osobnych tabel dla obiektów domeny, zamiast upychać je w jednej tabeli. Pozwala to na prawidłowe typy kolumn, ograniczenia i relacje. Tabela „Dozwolone wartości” to tylko nieczystość i nie ma miejsca w modelu danych.

8. Zdefiniuj strategię archiwizacji

Zbyt często widziałem bazy danych tworzone bez odpowiedniej strategii przechowywania i archiwizacji danych. Jak długo dane będą dostępne online w aktywnych tabelach bazy danych? Większość systemów jest zbudowana tak, aby przechowywać dane w bazie danych „na zawsze”. W przypadku większości systemów nie jest to rozsądna długoterminowa strategia przechowywania danych. W pewnym momencie aktywne dane powinny zostać zarchiwizowane.

Jednym z podejść, które zalecam, jest uwzględnienie przechowywania danych jako części rozważań projektowych. Czy będziesz mieć aktywne i historyczne tabele, aby wstawianie nowych wierszy w aktywnych tabelach było szybkie, a wyszukiwanie danych historycznych można zoptymalizować?

Pozwala to uniknąć konieczności przeprojektowywania archiwizacji w bazie danych na podstawie oryginalnego projektu.

9. Testuj wcześnie, testuj często

Parafrazując Ala Capone (lub Johna Van Burena, syna ósmego prezydenta USA), „testuj wcześnie, testuj często”. W ten sposób podążasz ścieżką Ciągłej Integracji. Testowanie na wczesnym etapie rozwoju oszczędza czas i pieniądze.

Testowanie jest zawsze wyzwaniem w planie rozwoju. Często pod koniec zwinnego sprintu następuje faza testowa, a pod koniec tworzenia oprogramowania – testowanie systemu. Testowanie jest zazwyczaj pierwszą rzeczą, którą należy ściskać, gdy czas się kończy.

Celem testowania bazy danych powinno być zasymulowanie środowiska produkcyjnego:„Dzień z życia bazy danych”. Jakich ilości można się spodziewać? Jakie interakcje użytkownika są prawdopodobne? Czy sprawy graniczne są obsługiwane?

Tak więc plan testowania i właściwe testowanie muszą być integralną częścią modelowania danych i rozwoju bazy danych.

Wniosek

To główne problemy, które zauważyłem podczas pracy z modelarzami danych i przeglądania modeli danych. Zwracając uwagę na te wskazówki, Twoja baza danych będzie lepiej zaprojektowana i bardziej niezawodna. Jednak zwrot z niektórych z tych inwestycji nie zawsze jest oczywisty lub widoczny. Planuj, dokumentuj, używaj standardów, twórz klucze, zapewniaj integralność, wykonuj indeksowanie, unikaj MUCK, rozwijaj strategie i TESTUJ!

Żadna z tych czynności nie zajmie dużo czasu, ale będzie miała ogromny wpływ na jakość Twojego modelu danych.

Jakie masz zdanie na temat tych wskazówek?

Czy masz własne wskazówki?