Cześć! Nazywam się Andriej Sienionow, jestem starszym analitykiem w Sportmaster. W tym poście chciałbym poruszyć kwestię denormalizacji baz danych systemów ERP. Rozważymy ogólne warunki oraz konkretny przykład — powiedzmy, że będzie to wspaniała tawerna-monopolista dla piratów i marynarzy. W której piratów i marynarzy należy obsługiwać w różny sposób, bowiem ich wyobrażenia o pięknie i wzorce konsumpcyjne różnią się znacznie.
Jak sprawić, aby wszyscy byli zadowoleni? Jak nie zwariować projektując i utrzymując taki system? Co zrobić, gdy do tawerny zaczynają przychodzić nie tylko znani piraci i marynarze?
Wszystko pod kontrolą. Ale zacznijmy od początku.
1. Ograniczenia i założenia
Wszystko, co przedstawiono, dotyczy tylko relacyjnych baz danych. Dobrze opisane, również w Internecie, skutki denormalizacji w postaci anomalii modyfikacji, usuwania i wstawiania nie są rozważane. Poza publikacją pozostają przypadki, w których denormalizacja jest czymś powszechnym, z klasycznymi przykładami: seria i numer paszportu, data i czas i tak dalej.
W poście używane są intuicyjne i praktyczne definicje normalnych form, bez odniesień do terminów matematycznych. Tak, jak mogą być stosowane do badania rzeczywistych procesów biznesowych (BP) i projektowania oprogramowania przemysłowego.
Istnieje opinia, że projektowanie hurtowni danych, narzędzi do tworzenia raportów i umów integracyjnych (w których używane jest tabelaryczne przedstawienie informacji), różni się od projektowania baz danych systemów ERP tym, że wygoda konsumpcji i zastosowanie świadomej denormalizacji mogą mieć priorytet nad ochroną integralności danych. Zgadzam się z tą opinią, a to, co będzie opisane poniżej, odnosi się wyłącznie do modeli danych głównych i danych transakcyjnych systemów ERP.
Wyjaśnienie norm normalnych zostało przedstawione na przykładzie zrozumiałym dla większości czytelników w codziennym życiu. Jednak jako ilustrację w punktach 4-5 celowo użyto wyraźnie „wymyślonego” zadania. Jeśli tego nie zrobimy i weźmiemy jakiś podręcznikowy przykład, na przykład tę samą model dotyczącą przechowywania zamówienia z p. 2, możemy znaleźć się w sytuacji, w której uwaga czytelnika zostanie odwrócona od proponowanego rozkładu procesu w model, na jego osobiste doświadczenie i postrzeganie tego, jak powinny być budowane procesy i modele przechowywania danych w IS. Innymi słowy, weźmy dwóch wykwalifikowanych analityków IT, niech jeden świadczy usługi logistyków przewożących pasażerów, a drugi — logistyków przewożących maszyny do produkcji mikrochipów. Poproście ich, aby bez wcześniejszego omówienia automatyzowanych BPs, stworzyli model danych do przechowywania informacji o przylotach kolejowych.
Istnieje niezerowe prawdopodobieństwo, że w przedstawionych modelach znajdziecie nie tylko zauważalnie różny zestaw atrybutów, ale także niezgodne zestawy encji, ponieważ każdy analityk będzie opierał się na znanych mu procesach i zadaniach. I w takiej sytuacji nie można powiedzieć, który model jest „prawidłowy”, ponieważ nie ma kryterium oceny.
2. Normy normalne
Pierwsza norma normalna bazy danych wymaga atomowości wszystkich atrybutów.
W szczególności, jeśli obiekt A posiada atrybuty niekluczowe a i b, takie że c=f(a,b) i w tabeli opisującej obiekt A przechowujesz wartość atrybutu c, to w bazie danych naruszona jest pierwsza norma normalna. Na przykład, jeśli w specyfikacji zamówienia wskazano ilość, której jednostki miary zależą od typu produktu: w jednym przypadku mogą to być sztuki, w innym litry, w trzecim pakiety składające się ze sztuk (w modelu powyżej Good_count_WR), to w bazie danych naruszona jest atomowość atrybutów. W tym przypadku, aby określić, jak powinien wyglądać zestaw tabel w specyfikacji zamówienia, potrzebne jest docelowe opisanie procesu pracy w IS, a ponieważ procesy mogą być różne, to i „prawidłowych” wersji może być wiele.
Druga norma normalna bazy danych wymaga przestrzegania pierwszej formy oraz osobnej tabeli dla każdej encji odnoszącej się do procesu pracy w IS. Jeśli w jednej tabeli istnieją zależności z=f1(a) i d=f2(b) oraz brak zależności z=f3(b), to w tabeli naruszona jest druga normalna forma. W powyższym przykładzie w tabeli „Zamówienie” nie istnieje zależność między zamówieniem a adresem. Zmień nazwisko ulicy lub miasta, a nie wpłynie to na istotne atrybuty zamówienia.
Trzecia normalna forma bazy danych wymaga przestrzegania drugiej normalnej formy i braku zależności funkcyjnych między atrybutami różnych encji. To zasada może być sformułowana tak: „wszystko, co może być obliczone, powinno być obliczone”. Innymi słowy, jeśli istnieją dwa obiekty A i B. W tabeli przechowującej atrybuty obiektu A występuje atrybut C, obiekt B ma atrybut b, taki, że istnieje c=f4(b), to narusza to trzecią normalną formę. W poniższym przykładzie atrybut „Ilość sztuk” (Total_count_WR) w rekordzie zamówienia wyraźnie może naruszać trzecią normalną formę.
3. Moje podejście do stosowania normalizacji
1. Tylko celowy, automatyzowany proces biznesowy może dostarczyć analitykowi kryteria do identyfikacji encji i atrybutów przy tworzeniu modelu przechowywania danych. Stworzenie modelu procesu jest warunkiem koniecznym do stworzenia normalnego modelu danych.
2. Osiągnięcie trzeciej normalnej formy w ścisłym sensie może nie być zasadne w praktyce tworzenia systemów ERP przy spełnieniu części lub wszystkich następujących warunków:
- procesy automatyzowane rzadko ulegają zmianom,
- terminy na badania i rozwój są napięte,
- wymagania dotyczące integralności danych są relatywnie niskie (potencjalne błędy w oprogramowaniu przemysłowym nie prowadzą do utraty pieniędzy ani klientów przez zamawiającego oprogramowanie)
- itp.
W opisanych warunkach koszty identyfikacji, opisu cyklu życia niektórych obiektów i ich atrybutów mogą być nieuzasadnione z punktu widzenia efektywności ekonomicznej.
3. Jakiekolwiek konsekwencje denormalizacji modelu danych w już stworzonym IS mogą być zminimalizowane poprzez dokładne badanie kodu i testowanie.
4. Denormalizacja to sposób przenoszenia nakładów pracy z etapu badania źródeł danych i projektowania procesów biznesowych na etap rozwoju, z okresu wdrożenia na okres rozwoju systemu.
5. Do trzeciej postaci normalnej bazy danych warto dążyć, jeśli:
- Kierunek zmian automatyzowanych procesów biznesowych jest trudny do przewidzenia.
- W zespole wdrożeniowym i/lub rozwojowym występuje słabo przenikalny podział pracy.
- Systemy wchodzące w krąg integracyjny rozwijają się według własnych planów.
- Niespójność danych może prowadzić do utraty klientów lub pieniędzy przez firmę.
6. Projektowanie modelu danych powinno być realizowane przez analityka wyłącznie w kontekście modeli docelowego procesu biznesowego i procesu w systemie informacyjnym. Jeśli projektowaniem modelu danych zajmuje się programista, musi on głęboko zgłębić dziedzinę, aby w szczególności rozumieć różnicę między wartościami atrybutów — jest to niezbędny warunek wydzielenia atomowych atrybutów. W ten sposób przejmuje na siebie funkcje, które nie są mu przypisane.
4 Zadanie ilustrujące
Załóżmy, że masz małą zrobotyzowaną tawernę w porcie. Twój segment rynku to marynarze i piraci, którzy przybywają do portu i potrzebują odpoczynku. Marynarzom sprzedajesz herbatę z tymiankiem, a piratom rum i kostne grzebienie do czesania brody. Obsługą w tawernie zajmuje się robot-hostess i robot-barman. Dzięki wysokiej jakości i niskim cenom wyparłeś wszystkich konkurentów, więc każdy, kto schodzi z okrętu, przychodzi do twojej tawerny, która jest jedyną w porcie.
Zestaw systemów informacyjnych tawerny składa się z następującego oprogramowania:
- System wczesnego ostrzegania o kliencie, rozpoznający jego kategorię na podstawie charakterystycznych cech.
- System zarządzania robotami-hostess i robotami-barmanami.
- System zarządzania magazynem i dostawą do punktu sprzedaży.
- System zarządzania relacjami z dostawcami.
Proces:
System wczesnego ostrzegania rozpoznaje osoby schodzące z okrętu. Jeśli osoba jest gładko ogolona, system uznaje ją za marynarza, jeśli u osoby stwierdzono brodę, uznaje ją za pirata.
Wchodząc do tawerny, gość słyszy od robot-hostess powitanie zgodne z jego kategorią, na przykład: "Ho-ho-ho, szanowny piracie, proszę przejść do stolika nr…"
Gość podchodzi do stołu, gdzie robot barman już przygotował dla niego produkty zgodnie z kategorią. Robot barman przekazuje informacje do systemu magazynowego, że kolejna partia dostawy powinna zostać zwiększona, a system zarządzania magazynem na podstawie pozostałych zapasów tworzy zamówienie na zakupy.
Niech system wczesnego ostrzegania został opracowany przez wasze wewnętrzne IT, program zarządzania robotami barowymi stworzył zewnętrzny wykonawca specjalnie dla waszego biznesu. A systemy do zarządzania magazynem i relacjami z dostawcami są dostosowanymi rozwiązaniami pudełkowymi z rynku.
5. Przykłady denormalizacji i jej wpływ na rozwój oprogramowania
Projektując proces biznesowy, ankietowani eksperci z branży jednogłośnie stwierdzili, że na całym świecie piraci piją rum i czeszą swoje brody kościanymi grzebieniami, a marynarze piją herbatę z tymiankiem i zawsze są dobrze ogoleni.
Pojawia się słownik typów klientów z dwoma wartościami: 1 - piraci, 2 - marynarze, wspólny dla całego kontekstu informacyjnego firmy.
System powiadamiania o kliencie natychmiast zapisuje wynik przetwarzania obrazu jako identyfikator (ID) rozpoznanego klienta i jego typ: marynarza lub pirata.
ID rozpoznanego obiektu
Kategoria klienta
100500
Pirata
100501
Pirata
100502
Marynarza
Jeszcze raz zwróćmy uwagę, że
1. Nasi marynarze to w rzeczywistości ogoleni ludzie
2. Nasi piraci to w rzeczywistości brodaci ludzie
Jakie w tym przypadku problemy należy rozwiązać, aby nasza struktura dążyła do trzeciej postaci normalnej:
- naruszenie atomowości atrybutu - Kategoria klienta
- mieszanie analizowanego faktu i wniosków w jednej tabeli
- zarejestrowana zależność funkcjonalna między atrybutami różnych encji.
W znormalizowanej wersji uzyskalibyśmy dwie tabele:
- wynik rozpoznawania w postaci zestawu ustalonych cech,
ID rozpoznanego obiektu
Owłosienie na twarzy
100500
Tak
100501
Tak
100502
Nie
- wynik określenia typu klienta jako aplikacja wbudowanej w system logiki do interpretacji ustalonych cech
ID rozpoznanego obiektu
ID identyfikacji
Kategoria klienta
100500
100001
Pirata
100501
100002
Pirata
100502
100003
Marynarza
Jak znormalizowana organizacja przechowywania danych może ułatwić rozwój kompleksu systemów informacyjnych? Załóżmy, że nagle pojawiają się nowi klienci. Niech to będą japońscy piraci, którzy mogą nie mieć brody, ale chodzą z papugą na ramieniu, oraz piraci-ekolodzy, których łatwo rozpoznać po niebieskim profilu Grety na lewej piersi.
Piraci-ekolodzy, naturalnie, nie mogą korzystać z kościanych grzebieni i wymagają odpowiednika wykonanego z przetworzonego plastikowego materiału morskiego.
Musisz dostosować algorytmy działania programów zgodnie z nowymi danymi wejściowymi. Gdyby zasady normalizacji zostały zastosowane, musiałbyś tylko w niektórych systemach uzupełnić dane wejściowe dla niektórych gałęzi procesów oraz stworzyć nowe gałęzie tylko w tych przypadkach i w tych systemach informacyjnych, gdzie ma znaczenie owłosienie na twarzy. Jednak, ponieważ zasady nie zostały zastosowane, musisz przeanalizować cały kod, w całym zakresie, gdzie używane są wartości słownika typów klientów i jednoznacznie ustalić, że w jednym przypadku algorytm powinien uwzględnić działalność zawodową klienta, a w innym cechy fizyczne.
W formie, która dąży do znormalizowanej, otrzymalibyśmy dwie tabele z danymi operacyjnymi oraz dwa słowniki:
- wynik rozpoznawania w postaci zestawu ustalonych cech,
ID rozpoznanego obiektu
Greta na lewej piersi
Ptak na ramieniu
Owłosienie na twarzy
100510
1
1
1
100511
0
0
1
100512
1
0
- wynik określenia typu klienta (niech to będzie widok użytkownika, w którym wyświetlane są opisy z słowników)
Czy odkryta denormalizacja oznacza, że systemy nie będą mogły być dostosowane do nowych warunków? Oczywiście, że nie. Gdyby wszystkie systemy informacyjne były tworzone przez jeden zespół z zerową rotacją kadrową, rozwój byłby dobrze udokumentowany, a informacje w zespole przekazywane bez strat, wymagane zmiany mogłyby być wprowadzone z nieznacznymi nakładami wysiłku. Ale jeśli wrócimy do pierwotnych założeń problemu, tylko na wydruk protokołów wspólnych dyskusji zetrze się 1,5 klawiatury, a jeszcze 0,5 na opracowanie procedur zakupu.
W podanym powyżej przykładzie naruszone są wszystkie trzy normalne formy, spróbujmy naruszać je oddzielnie.
Naruszenie pierwszej normalnej formy:
Załóżmy, że towary na twój magazyn są dostarczane przez dostawców osobiście, przy użyciu jednej 1,5-tonowej furgonetki, która należy do twojej tawerny. Rozmiar twoich zamówień jest na tyle mały w porównaniu do obrotów dostawców, że są one zawsze realizowane jeden do jednego, bez oczekiwania na wykonanie. Czy w takim przypadku konieczne są osobne tabele: pojazdy, typy pojazdów, czy trzeba rozdzielać plan i rzeczywistość w twoich zamówieniach realizowanych przez dostawców?
Tylko wyobraź sobie, ile „zbędnych” połączeń będą musieli napisać twoi programiści, jeśli do opracowania programu wykorzystają poniższy model.
Załóżmy, że podjęliśmy decyzję, iż proponowana struktura jest zbyt skomplikowana, dla naszego przypadku rozdzielanie planu i rzeczywistości w zapisie zamówienia to zbędna informacja, a stworzona specyfikacja zamówienia jest przerysowywana na podstawie wyników przyjęcia dostarczonego towaru, sporadyczne błędy i dostarczenie towaru złej jakości są rozwiązywane poza systemem informatycznym.
I pewnego dnia widzisz, jak cały hall tawerny wypełnia się oburzonymi i zaniedbanymi piratami. Co się stało?
Okazało się, że wraz z rozwojem twojego biznesu rosło również spożycie. Kiedyś podjęto decyzję zarządczą, że jeśli furgonetka była przeciążona pod względem objętości i/lub wagi, co zdarzało się bardzo rzadko, dostawca priorytetowo traktował załadunek na rzecz napojów.
Niedostarczony towar trafiał do następnego zamówienia i odchodził w nowym kursie, a posiadanie minimalnego stanu magazynowego w tawernie pozwalało nie zauważać przypadków przekroczenia normy.
W porcie zamknął się ostatni konkurent, a przypadek przeładowania furgonetki, ominięty przez priorytetyzację opartą na założeniu o wystarczalności minimalnego stanu magazynowego i okresowym niedoładowaniu środka transportu, stał się powszechną praktyką. Stworzony system będzie idealnie działał zgodnie z wbudowanymi w niego algorytmami i będzie pozbawiony jakiejkolwiek możliwości śledzenia systematycznego niewykonywania zamówień planowych. Tylko zepsuta reputacja i niezadowoleni klienci mogą odkryć problem.
Uważny czytelnik z pewnością zauważył, że zamówiona ilość w specyfikacji zamówienia (T_ORDER_SPEC) w sekcji 2 i w sekcji 5 może odpowiadać lub nie odpowiadać wymaganiu pierwszej formy normalnej. Wszystko zależy od tego, czy przy wybranym asortymencie towarów różne jednostki miary mogą znajdować się w tym samym polu.
Naruszenie drugiej formy normalnej:
W miarę jak rosną twoje potrzeby, nabywasz inne środki transportu różnych rozmiarów. W opisanym powyżej kontekście stworzenie katalogu środków transportu zostało uznane za nadmiarowe, w rezultacie wszystkie algorytmy obsługujące potrzeby dostaw i magazynów traktują transport ładunku od dostawcy do magazynu jako wyjazd wyłącznie 1,5-tonowej furgonetki. Tak więc, wraz z zakupem nowych środków transportu i tak tworzysz katalog środków transportu, ale przy modyfikacji będziesz musiał przeanalizować cały kod, który odnosi się do transportu ładunku, aby ustalić, czy w każdym konkretnym miejscu nie zakładano odniesień do charakterystyk tego konkretnego samochodu, z którego zaczynał się biznes.
Naruszenie trzeciej formy normalnej:
W pewnym momencie zaczynasz tworzyć program lojalnościowy, pojawia się zapis stałego klienta. Po co na przykład tracić czas na tworzenie materialnych prezentacji, które przechowują zsumowane dane dotyczące sprzedaży dla pojedynczego klienta, które można wykorzystać w raportowaniu i przesyłaniu do systemów analitycznych, skoro na etapie uruchamiania programu lojalnościowego wszystko, co interesuje klienta, można umieścić w samym zapisie klienta? I rzeczywiście, na pierwszy rzut oka, nie ma ku temu sensu. Ale za każdym razem, gdy twój biznes będzie łączył, na przykład, nowe kanały sprzedaży, wśród twoich analityków musi być ktoś, kto przypomni sobie, że istnieje taki atrybut agregacyjny.
Projektując każdy nowy proces, powiedzmy sprzedaż w internecie, sprzedaż poprzez dystrybutorów połączonych z ogólnym systemem lojalnościowym, ktoś musi mieć na uwadze, że wszystkie nowe procesy powinny na poziomie kodu zapewniać integralność danych. Dla przemysłowej bazy danych z tysiącem tabel wydaje się to mało wykonalnym zadaniem.
Doświadczony programista wie, jak rozwiązać wszystkie wymienione powyżej problemy, ale moim zdaniem zadaniem doświadczonego analityka jest zapobieganie im.
Chcę podziękować za cenne uwagi przy przygotowywaniu publikacji dla głównego programisty Jewgienija Jaruchina.
Literatura
Connolly Thomas, Begg Caroline. Bazy danych. Projektowanie, wdrażanie i utrzymanie. Teoria i praktyka.
Źródło: habr.com
