Pisząc post na blogu o modelowaniu baz danych, musisz być przygotowany na to, że Twój abstrakcyjny model nie spełnia potrzeb większości czytelników. Powód jest prosty. Rzeczywiste modele baz danych są zwykle tworzone w ścisłym związku z określonymi wymaganiami biznesowymi i programistycznymi, podczas gdy modele blogowe nie.
Od kilku tygodni piszę wpisy na blogu o tworzeniu modeli baz danych. Tematy wahały się od ogólnego podejścia do modelowania baz danych poprzez proste forum internetowe do modelu bardziej złożonej ankiety online.
W przypadku każdego modelu bazy danych, który tworzę, staram się jasno zrozumieć domenę biznesową i wypracować w głowie pełny obraz modelu.
Wyzwanie tworzenia abstrakcyjnych baz danych
Zwykle jako rozwiązanie architekt , biorę określone wymagania biznesowe i przekształcam je w szczegóły techniczne tego, co należy stworzyć od strony technicznej:tłumaczenie z języka biznesowego na język techniczny – projektowanie algorytmów na wysokim poziomie i modelowanie wymagań danych dla algorytmów.
Niestety nie mogę blogować o modelach baz danych świata rzeczywistego, które tworzę w pracy. Z jednej strony są one bardzo specyficzne dla domeny biznesowej, a z drugiej ograniczają mnie umowy o zachowaniu poufności. Dla bloga tworzę czysto abstrakcyjny koncepcja bez konkretnych wymagań biznesowych, z wyjątkiem tych, które, jak sobie wyobrażam, istnieją w domenie biznesowej. Teraz w porządku; Mam całkiem niezłą wyobraźnię i często zwracam uwagę, że Twoje wymagania mogą być inne, kiedy opisuję wybory, których dokonuję. Ale ten proces blogowania sprawił, że pomyślałem o tym, jak różni się ten proces od tworzenia modeli w prawdziwym projekcie.
Proces rozwoju w prawdziwym życiu
W rzeczywistej sytuacji po stworzeniu rozwiązania wysokiego poziomu i projektu technicznego w interaktywnym ściśle współpracowałbym z zespołem programistów sposób, aby model odpowiadał potrzebom programistycznym.
Deweloperzy mogą narzekać, że model danych jest zbyt znormalizowany, aby obsługiwać wysoką wydajność, lub mogą poprosić o dodatkową normalizację w niektórych obszarach. Jeśli brakowało jakichkolwiek kluczy alternatywnych, programiści dość szybko narzekaliby, a my zauważylibyśmy to również podczas testowania wydajności bazy danych.
Zastanowilibyśmy się, jakie dokładne długości pól powinny być oparte na maksymalnej długości przechowywanych danych oraz na projektach ekranów do wprowadzania i wyświetlania danych. Oczywiście dokładne długości pól w koncepcyjnym modelu bazy danych nie są ważne.
Opracowalibyśmy przykłady tego, jakie dane będą przechowywane w tabelach i jak będą wykorzystywane przez aplikację, a także stworzymy skrypty do wstępnego wypełniania tabel do testów jednostkowych aplikacji. W ten sposób złapalibyśmy narożne przypadki, aby upewnić się, że model obsługuje ograniczenia aplikacji.
Tak więc, w zasadzie, będziemy masować model, dopóki naprawdę nie będzie wspierał biznesowych i niefunkcjonalnych wymagań systemu, używając procesu iteracyjnego, dopóki nie rozwiniemy modelu w coś, co wszyscy możemy zaakceptować pomimo wbudowanych w niego kompromisów.
Jak powiedziałem, byłby to bardzo powtarzalny proces, który mógłby trwać przez wiele miesięcy, podczas gdy kod aplikacji, interfejsy użytkownika i interfejsy aplikacji są opracowywane.
Ograniczenia opinii wyrażanych w dobrych intencjach
W obecnej sytuacji blogowej, chociaż moja co prawda ograniczona liczba czytelników dostarcza mi informacji zwrotnych na temat problemów i wyzwań, które widzą w modelach, jest to z konieczności powierzchowne. Wątpię, czy którykolwiek z czytelników bezpośrednio używa modeli do tworzenia aplikacji i odkrywania, co naprawdę działa i gdzie występują problemy.
Tak więc komentarze typu „model nie jest dobrze przemyślany” prawie na pewno mają rację. Z drugiej strony słowa „brakuje FK” są dość precyzyjne, ale mam nadzieję, że wyjaśniłem w tekście artykułu, dlaczego dołączam klucz obcy, czy nie.
Wniosek
Teraz proszę nie traktuj tego posta jako skargi lub komentarza na temat opinii, które zgłaszają czytelnicy, raczej zastanawiam się nad trudnością stworzenia modelu bazy danych, gdy nie jesteś w środowisku, które pozwala na interaktywną wymianę z iteracją proces rozwoju.
Prawdopodobnie istnieją inne sytuacje, w których modelarze baz danych są odcięci od procesu rozwoju, ale teraz zdałem sobie sprawę, jak niebezpieczne byłoby to i jak podatne na problemy.
Czy możesz sobie wyobrazić model bazy danych, który nigdy się nie zmienia? Nigdy pojedyncze dostosowanie kolumny, nigdy dodatkowe klucze obce, nigdy nie potrzeba nowej tabeli. Szczerze mówiąc, jedyną taką sytuacją, jaką mogę sobie wyobrazić, jest sytuacja, w której aplikacja korzystająca z bazy danych nie ewoluuje i znalazła się w ślepym zaułku:koniec życia.
