Najlepsze praktyki w zakresie przeprojektowywania bazy danych

Zdaję sobie sprawę z kilku ogólnych dobrych praktyk przy projektowaniu bazy danych aplikacji, ale co z przeprojektowaniem?

Jestem w zespole, którego zadaniem jest przeprojektowanie wewnętrznej aplikacji biznesowej, chociaż pomimo tego, że mówię „wewnętrzny”, niestety jestem wielu, wielu warstwami ludzi poza kontaktem z rzeczywistymi użytkownikami systemu.

Obecny program znajduje się w formularzach Oracle Forms, rozproszonych po wielu nienormalizowanych tabelach, czasem z wieloma niemal zduplikowanymi tabelami zawierającymi niewielkie warianty danych innych użytkowników. Ograniczenia często mają postać źle egzekwowanych procedur przechowywanych. Nawet typy nie wydają się być przechowywane poprawnie. Napotkałem wszelkiego rodzaju złe dane, które Oracle wydaje się ignorować, ale dało się je dopasować (i słusznie) do Kreatora importu / eksportu programu SQL Server. (Na przykład dwucyfrowe liczby całkowite nie stanowią pełnej daty i godziny!)

Pierwotny program prawdopodobnie cofnął się o dwadzieścia lat, a wszyscy pierwotni programiści przeszli na emeryturę tak dawno temu, że nawet starsi ludzie nie mają pojęcia, kim byli. W rezultacie nie ma też żadnych czystych wymagań do spełnienia - mamy po prostu powielić funkcjonalność istniejącej aplikacji i zachować istniejące dane.

Końcowym rezultatem przepisywania będzie wersja internetowa działająca na ASP.NET z MS SQL Server dla zaplecza.

Moi pozostali dwaj koledzy z zespołu programistów są o wiele, dużo starsi ode mnie, oboje mają doświadczenie biznesowe / MIS, podczas gdy ja mam CS. Doświadczenie starszego członka dotyczyło prawie wyłącznie formularzy Oracle, a drugi członek wykonywał głównie aplikacje biznesowe w języku Visual Basic. Chociaż moje zaplecze baz danych ogranicza się do projektowania nowych baz danych dla projektów w MySQL lub SQLite, głównie dla moich klas licencjackich, wydaje mi się, że jestem jedyną osobą z doświadczeniem w projektowaniu baz danych.

Napisałem już mały program w języku C #, który wczytuje wszystkie istniejące dane do neutralnego formatu, gotowy do ponownego przesłania i umieszczenia w nowej bazie danych. Planuję napisać kod ładowania po zaprojektowaniu docelowej bazy danych, aby dane mogły zostać odpowiednio podzielone na nowe znormalizowane tabele, dodane w odpowiedniej kolejności, aby przestrzegać nowych ograniczeń itp. Ten sam program można następnie uruchomić ponownie później aby skopiować dane produkcyjne do rzeczywiście nowo wdrożonego zakończonego przeprojektowania. Pozostawia to faktyczne przeprojektowanie bazy danych jako najważniejszą rzecz do ustalenia.

Tak więc sedno mojego pytania: jakie są najlepsze praktyki przeprowadzania przeprojektowania z poziomu bazy danych w górę istniejącej aplikacji?

Myślę, że już wiesz, jak znormalizować bazę danych.

Potrzebne są strategie minimalizacji ryzyka przy przenoszeniu całego oprogramowania do nowej bazy danych.

To, co sugeruję, to więcej pracy w zamian za mniejsze ryzyko.

Normalizuj bazę danych i utwórz proces wypełniania znormalizowanej bazy danych danymi z oryginalnej bazy danych. Oryginalna baza danych będzie bazą danych do wstawiania, aktualizacji i usuwania. Znormalizowana baza danych będzie bazą danych zapytań tylko podczas konwersji.

Twój wypełniony proces będzie musiał działać tak często, jak potrzeba danych zapytania. Jeśli starsze dane są dopuszczalne, możesz uruchomić proces wypełniania nocnego. Jeśli potrzebujesz więcej aktualnych danych, musisz uruchomić ciągły proces wypełniania.

Zbuduj część zapytania nowego systemu ASP.NET, wskazując na nową znormalizowaną bazę danych.

Wyniki zapytania z nowego systemu powinny się porównać z wynikami zapytania z oryginalnego systemu.

Możesz zatrzymać się w tym momencie. To decyzja biznesowa, a nie decyzja techniczna.

W wolnym czasie tworzysz nowe funkcje wstawiania / aktualizacji / usuwania w nowym systemie ASP.NET. Tworząc nową funkcjonalność, wyłączasz odpowiadające sobie części oryginalnego systemu. W pewnym momencie nic z oryginalnego systemu nie pozostaje.

Zaletą konwersji w ten sposób jest zmniejszenie ryzyka poprzez zbudowanie części zapytania w pierwszej kolejności. Zasadniczo funkcje zapytań są proste w porównaniu z logiką biznesową wbudowaną w funkcje wstawiania / aktualizacji / usuwania.

Konwertujesz funkcję wstawiania / aktualizacji / usuwania pojedynczo. Jeśli występuje problem z niezrozumieniem logiki biznesowej, można to naprawić, gdy użytkownicy korzystają z oryginalnego systemu.

Powinno być oczywiste, że twój proces wypełniania powinien być absolutnie spójny.

Spróbuj przekonać ich do zawarcia umowy na opracowanie nowego systemu z firmą zewnętrzną, istnieje wiele dobrych firm programistycznych, które dysponują zasobami umożliwiającymi poprawne tworzenie aplikacji szybciej i lepiej niż ograniczony zespół. Dobra firma deweloperska będzie również w stanie zmusić przełożonych do robienia rzeczy, których mogą nie zrobić, jeśli poprosisz o to, premier firmy zarabiający dużo pieniędzy na opracowanie aplikacji ma znacznie większy wpływ na zaangażowanie użytkowników niż informatyk wiele poziomów poniżej władzy zarządzającej, aby zorganizować takie rzeczy.

To kosztuje dużo pieniędzy z góry, ale spłaci się dużo czasu, aby mieć odpowiednie zasoby do opracowania i wdrożenia. Jeśli uda ci się wydać zapytanie ofertowe, postawiłbym, że otrzymane oferty wskazują, że to, co próbujesz zrobić, jest o wiele bardziej skomplikowane, niż zdają sobie sprawę twoi menedżerowie.

Zaprojektuj znormalizowaną bazę danych z potrzebnymi typami danych. Najtrudniejszą częścią jest migracja danych. Najpierw musisz mieć plan, w jaki sposób zamapujesz ze starego na nowy i co zrobisz z danymi, które nie spełniają nowej struktury. Na przykład możesz mieć dane, których nie można obecnie zidentyfikować, jeśli nie masz odpowiednich ograniczeń integralności. Możesz po prostu nie przenosić tych danych lub przenieść je, ale dołączyć do nowego rekordu nadrzędnego o nazwie „Nieznany”. Jeśli data nie jest prawdziwą datą, czy możesz wprowadzić wartość NULL w polu podczas migracji? Będziesz potrzebował odpowiedzi na tego rodzaju pytania. Sugeruję, że niektórzy programiści pracują nad zmianą interfejsu GUI, aby używać nowej struktury bazy danych, a inni pracują ściśle nad migracją. Migracja to ogromne zadanie, będzie dużo umiejętności i dużo czasu. Nie zostawiaj tego jako refleksji.

Ponieważ używasz programu SQL Server, możesz przeprowadzić faktyczną migrację za pośrednictwem SSIS.

Utwórz dobry solidny zestaw przypadków testowych, aby można było porównać, że wyniki ze starym systemem są takie same z nowym systemem.

Ponieważ masz tyle lat danych, możesz chcieć migrować w dwóch częściach. Najpierw migruj większość danych, a następnie, gdy nadejdzie czas na uruchomienie, migruj tylko zmienione dane. Oczywiście musisz wprowadzić kontrolę w bazie danych, aby znaleźć zmienione dane, których możesz jeszcze nie mieć. W tym momencie możesz również poprosić o pomoc, jeśli chcesz zarchiwizować niektóre dane.

Prawie codziennie spotykam się z ponownym projektowaniem schematu bazy danych ze względu na obsługę i dalszy rozwój kilku starszych aplikacji, które urodziły się jako pliki MS Access (.mdb), a następnie wyrosły na duże bazy danych z setkami tabel znajdujących się obecnie w MS SQL Serwer, ale wciąż ma „niemowlęta zwariowane” z pierwotnego projektu. Oto kilka praktyk, które uznałem za przydatne:

Spróbuj zminimalizować publicznie dostępną powierzchnię schematu bazy danych.

Oznacza to, że powinieneś spróbować zaprojektować publiczny interfejs API, który udostępniasz aplikacjom zewnętrznym. Zwykle próbuję zaimplementować dane statyczne jako widoki (nawet jeśli są one oparte tylko na jednej tabeli), a dane dynamiczne jako sparametryzowane widoki lub jako procedury składowane. W przypadku zapytań o dane, w których wystarczy tylko jedna wartość, można również użyć funkcji skalarnych.

Tylko te (widoki, procedury składowane i funkcje skalarne) są widoczne dla aplikacji zewnętrznych (poprzez ORM lub bezpośrednio) i wykorzystywane do wszystkich operacji CRUD. Ten schemat jest następnie całkowicie zamrożony, podczas gdy wewnętrznie możesz zmienić bazowe tabele, ulepszyć swoje procedury itp. - to nie zepsuje kompatybilności z twoją aplikacją.

Spróbuj zoptymalizować pod kątem rzeczywistych kryteriów, a nie tych z książek.

Normalizacja jest ważnym tematem w każdej książce na temat projektowania baz danych. Ale w prawdziwym życiu zdarzają się przypadki, gdy normalizacja nie przyniesie wiele, a nawet nie spowolni bazy danych, na przykład, jeśli masz pewne dane, które się powtarzają, ale odsetek powtórzeń jest bardzo niski itp. Nie jestem przeciwny normalizacji, próbuję tu powiedzieć, że musisz sobie z tym poradzić z pewnym sceptycyzmem i rozwagą.

Nagrywaj sesje profilowania i analizuj je.

Ponowne projektowanie bazy danych oparte wyłącznie na schemacie bazy danych nie jest kompletne. Spójrz na swoją bazę danych pod kątem jej dynamiki, spróbuj znaleźć wąskie gardła podczas testów obciążenia i rozwiązać je. W przypadku MS SQL Server istnieje specjalny Doradca dostrajania, który może wygenerować pewne rekomendacje na podstawie zarejestrowanego śledzenia aktywności.

Oto moja odpowiedź:

1. Najpierw najlepiej zrozum aktualny system baz danych. Musisz znać wszystkie zastosowania tego systemu, a także użytkowników. Musisz znać wszystkie źródła systemu, a także systemy, które mogą służyć jako ich system źródłowy.

2. Musisz zidentyfikować wszystkie różne zastosowania systemu, bez względu na to, czy jest to system operacyjny, raportowanie, czy oba. Zidentyfikuj aplikacje i system nadrzędny, które mogą korzystać z bazy danych. Dzięki temu poznasz elementy bieżącej bazy danych, które są przestarzałe i nie są już potrzebne.

3. Przeanalizuj i zrozum także bieżący proces ETL, który ładuje dane do bazy danych i wyodrębnia dane z bazy danych.

4. Poznaj wszystkie elementy danych w bazie danych i czy możesz zbudować macierz pudełkową, która pomoże ci zidentyfikować duplikaty elementów.

5. Po uzyskaniu wszystkich informacji możesz przystąpić do przeprojektowania tak, jakbyś projektował bazę danych po raz pierwszy z informacjami zebranymi w ramach zbierania wymagań.

6. Powodzenia!