Bună! Mă numesc Andrei Semenov, sunt analist senior la Sportmaster. În această postare vreau să aduc în discuție problema denormalizării bazelor de date din sistemele ERP. Vom examina condițiile generale, precum și un exemplu concret — să spunem, va fi o tavernă minunată-monopol pentru pirați și marinari. În care pirații și marinarii trebuie deserviți diferit, deoarece viziunea asupra frumosului și comportamentele de consum ale acestor buni domni se deosebesc semnificativ.
Cum să facem astfel încât toată lumea să fie mulțumită? Cum să nu o luam razna, proiectând și întreținând un astfel de sistem? Ce să facem dacă la tavernă încep să vină nu doar pirați și marinari obișnuiți?
Totul este sub cat. Dar să luăm lucrurile pe rând.
1. Restricții și presupuneri
Tot ce este prezentat se referă doar la bazele de date relaționale. Consecințele bine cunoscute, inclusiv pe internet, ale denormalizării sub formă de anomalii ale modificării, ștergerii și inserării nu sunt luate în considerare. Cazurile în care denormalizarea este un loc comun, cu exemple clasice: seria și numărul pașaportului, data și ora etc. rămân în afara publicației.
În postare sunt folosite definiții intuitive și practic aplicabile ale formelor normale, fără referiri la termeni matematici. În forma în care pot fi aplicate la examinarea proceselor de afaceri reale (BPA) și proiectarea software-ului industrial.
Există o opinie că proiectarea depozitelor de date, a instrumentelor de generare a rapoartelor și a acordurilor de integrare (în care se utilizează o prezentare tabelară a informațiilor), se deosebește de proiectarea bazelor de date ERP prin faptul că confortul consumului și aplicarea denormalizării conștiente pentru atingerea acestuia poate avea prioritate față de protecția integrității datelor. Împărtășesc această opinie, iar ceea ce este descris mai jos se referă exclusiv la modelele de date de bază și datele tranzacționale ale sistemelor ERP.
Explicația formelor normale este prezentată printr-un exemplu pe care majoritatea cititorilor îl pot înțelege la nivel de bază. Totuși, ca ilustrație vizuală, în punctele 4-5 a fost folosit în mod conștient un exemplu „inventat”. Dacă nu se face acest lucru și se ia un exemplu clasic, cum ar fi modelul de stocare a unei comenzi din pct. 2, s-ar putea ajunge în situația în care atenția cititorului este deturnată de propunerea de descompunere a procesului într-un model, către experiența personală și percepția modului în care ar trebui să fie construite procesele și modelele de stocare a datelor în SIS. Cu alte cuvinte, luați doi analiști IT calificați, lăsați-l pe unul să ofere servicii logisticienilor care transportă pasageri, iar pe celălalt logisticienilor care transportă mașini pentru producția de microcipuri. Rugați-i, fără a discuta în prealabil despre procesele de afaceri automatizabile, să elaboreze un model de date pentru stocarea informațiilor despre cursele feroviare.
Există o probabilitate non-zero că în modelele propuse veți găsi nu doar un set de atribute semnificativ diferit, ci și seturi de entități necorelate, deoarece fiecare analist se va baza pe procesele și sarcinile cunoscute de el. Și este imposibil să se declare, în această situație, care model este „corect”, deoarece nu există un criteriu de evaluare.
2. Forme normale
Prima formă normală a unei baze de date cere atomicitatea tuturor atributelor.
În special, dacă un obiect A are atribute ne-cheie a și b, astfel încât c=f(a,b) și în tabelul care descrie obiectul A stocați valoarea atributului c, atunci baza de date încalcă prima formă normală. De exemplu, dacă în specificația comenzii se indică o cantitate, unitățile de măsură ale căror valori depind de tipul de produs: într-un caz pot fi bucăți, în altul litri, iar în al treilea ambalaje formate din bucăți (în modelul de mai sus Good_count_WR), atunci baza de date încalcă atomicitatea atributelor. În acest caz, pentru a spune cum ar trebui să fie structura tabelelor din specificația comenzii, este necesară o descriere țintă a procesului de lucru în SIS, și cum procesele pot fi diferite, atunci și versiunile „corecte” pot fi numeroase.
A doua formă normală a unei baze de date necesită respectarea primei forme și o tabelă proprie pentru fiecare entitate legată de procesul de lucru în SI. Dacă într-o tabelă există dependențe cu=f1(a) și d=f2(b) și nu există o dependență cu=f3(b), atunci în tabelă este încălcată a doua formă normală. În exemplul de mai sus, în tabela „Comandă” nu există o dependență între comandă și adresă. Schimbați numele străzii sau orașului și nu veți avea niciun impact asupra atributelor esențiale ale comenzii.
A treia formă normală a BD necesită respectarea celei de-a doua forme normale și absența dependențelor funcționale între atributele diferitelor entități. Această regulă poate fi formulată astfel: „tot ceea ce poate fi calculat, trebuie să fie calculat”. Cu alte cuvinte, dacă există două obiecte A și B. În tabela care stochează atributele obiectului A, este prezent atributul C, iar obiectul B are un atribut b, astfel încât există c=f4(b), atunci a treia formă normală este încălcată. În exemplul de mai jos, atributul „Număr de articole” (Total_count_WR) din înregistrarea comenzii pretinde în mod evident că încalcă a treia formă normală.
3. Abordarea mea pentru aplicarea normalizării
1. Numai procesul de afaceri țintă care poate fi automatizat poate oferi analistului criteriile pentru identificarea entităților și atributelor în timpul creării modelului de stocare a datelor. Crearea modelului de proces este o condiție esențială pentru crearea modelului normal de date.
2. Atingerea celei de-a treia forme normale în sens strict poate să nu fie justificate în practica reală a creării sistemelor ERP în cazul în care se îndeplinesc parțial sau total următoarele condiții:
- procesele automatizate sunt rareori supuse schimbărilor,
- termenii pentru cercetare și dezvoltare sunt strânși,
- cerințele de integritate a datelor sunt relativ scăzute (erorile potențiale în software-ul industrial nu duc la pierderi financiare sau la clienți pentru furnizorul de software)
- etc.
În condițiile descrise, cheltuielile pentru identificarea, descrierea ciclului de viață al anumitor obiecte și al atributelor lor pot fi nejustificate din punct de vedere al eficienței economice.
3. Orice consecințe ale denormalizării modelului de date în SI deja creat pot fi mitigate printr-o cercetare și testare atentă a codului.
4. Denormalizarea este o metodă de a transfera efortul de muncă de la faza de cercetare a surselor de date și proiectare a procesului de afaceri la faza de dezvoltare, de la perioada de implementare la perioada de dezvoltare a sistemului.
5. Este recomandat să se aspire la a treia formă normală a Bazei de Date, dacă:
- Direcția modificării proceselor de afaceri automatizate este dificil de prevăzut.
- Între echipa de implementare și/sau dezvoltare există o separare slabă a muncii.
- Sistemele incluse în conturul de integrare se dezvoltă conform propriilor planuri.
- Incoerența datelor poate duce la pierderi de clienți sau bani pentru companie.
6. Proiectarea modelului de date trebuie să fie realizată de analist doar în legătură cu modelele procesului de afaceri vizat și procesul din IS. Dacă proiectarea modelului de date este realizată de un dezvoltator, acesta va trebui să se aprofundeze în domeniul de aplicare până la un punct în care să înțeleagă, în special, diferența dintre valorile atributelor - o condiție necesară pentru evidențierea atributelor atomice. Astfel, își asumă funcții care nu îi sunt caracteristice.
4 Sarcină pentru ilustrare
Să presupunem că aveți o mică tavernă robotizată în port. Segmentul dumneavoastră de piață: marinarii și pirații care vin în port și au nevoie de relaxare. Marinarii cumpără ceai cu cimbru, iar pirații rom și piepteni din os pentru pieptănatul barbii. Serviciul din tavernă este asigurat de un robot-hostess și un robot-barman. Datorită calității înalte și prețurilor mici, ați eliminat toți competitorii, astfel încât fiecare sosind din navă vine la taverna dumneavoastră, care este singura din port.
Complexul de sisteme informaționale ale tavernei constă în următoarele software-uri:
- Sistem de avertizare timpurie despre clienți, care recunoaște categoria acestora în funcție de caracteristici specifice.
- Sistem de gestionare a roboților-hostess și roboților-barman.
- Sistem de gestionare a stocurilor și livrărilor în punctul de vânzare.
- Sistem de gestionare a relațiilor cu furnizorii (SRF).
Proces:
Sistemul de avertizare timpurie recunoaște persoanele care debarcă din navă. Dacă o persoană este bine întârziată, aceasta este identificată ca marinar, iar dacă are barbă, este recunoscută ca pirat.
Intrând în tavernă, oaspetul aude de la robotul-hostess o urare conform categoriei sale, de exemplu: «Ho-ho-ho, stimate pirat, treceți la masa nr.…»
Oaspetele se îndreaptă spre masa specificată, unde robotul-barman a pregătit deja produsele pentru el, conform categoriei. Robotul-barman transmite informația către sistemul de stocare că următoarea livrare trebuie să fie crescută, iar sistemul de management al stocurilor formează o solicitare de achiziție în baza stocului disponibil.
Sistemul de avertizare timpurie a fost dezvoltat de IT-ul vostru intern, iar programul de gestionare a roboților de bar a fost creat de un contractor extern special pentru afacerea voastră. Sistemele de gestionare a stocurilor și a relațiilor cu furnizorii sunt soluții standard personalizate de pe piață.
5. Exemple de denormalizare și influența sa asupra dezvoltării software-ului
În proiectarea procesului de afaceri, experții din domeniu au afirmat în unanimitate că, în întreaga lume, pirații beau rom și își perie bărbile cu piepteni din os, în timp ce marinarii beau ceai cu cimbru și sunt întotdeauna bine bărbieriți.
Se introduce un ghid al tipurilor de clienți cu două valori: 1 - pirați, 2 - marinari, comun pentru întreaga rețea informațională a companiei.
Sistemul de alertă pentru clienți salvează imediat rezultatul procesării imaginii ca identificator (ID) al clientului recunoscut și tipul său: marinar sau pirat.
ID-ul obiectului recunoscut
Categoria clientului
100500
Pirate
100501
Pirate
100502
Marinar
Să subliniem din nou că
1. Marinarii noștri sunt de fapt bărbați tăiați
2. Pirații noștri sunt de fapt bărbați cu barbă
Ce probleme trebuie să rezolvăm pentru ca structura noastră să tindă spre a treia formă normalizată:
- încălcarea atomicității a atributului - Categoria clientului
- amestecarea faptului analizat și a concluziei într-un singur tabel
- dependența funcțională fixată între atributele diferitelor entități.
În formă normalizată, am obține două tabele:
- rezultatul recunoașterii sub formă de set de caracteristici stabilite,
ID-ul obiectului recunoscut
Părul facial
100500
Da
100501
Da
100502
Nu
- rezultatul determinării tipului de client ca aplicație a logicii încorporate în sistem pentru interpretarea caracteristicilor stabilite
ID-ul obiectului recunoscut
ID-ul identificării
Categoria clientului
100500
100001
Pirate
100501
100002
Pirate
100502
100003
Marinar
Cum poate normalizarea organizării datelor să faciliteze dezvoltarea sistemelor informaționale? Să presupunem că, dintr-o dată, aveți clienți noi. Să fie pirați japonezi care poate nu au barbă, dar vin cu un papagal pe umăr, și pirați-ecologi, pe care îi veți recunoaște după profilul albastru al Gretei de pe pieptul stâng.
Pirații-ecologi, desigur, nu pot folosi piepteni din os și solicită un analog din plastic reciclat din mare.
Trebuie să vă adaptați algoritmii programelor la noile date. Dacă regulile de normalizare ar fi fost respectate, atunci ar fi fost suficient să completați intrările pentru unele ramuri ale proceselor în anumite sisteme și să creați ramuri noi doar pentru acele cazuri și în acele sisteme informaționale unde contează aspectul părului facial. Dar, având în vedere că regulile nu au fost respectate, va trebui să analizați întregul cod, în întreaga schemă, unde sunt utilizate valorile din catalogul tipurilor de clienți și să stabiliți cu certitudine că, în un caz, algoritmul trebuie să țină cont de activitatea profesională a clientului, iar în altul de caracteristicile fizice.
Sub forma în care tinde spre normalizare, am obține două tabele cu date operaționale și două cataloage:
- rezultatul recunoașterii sub formă de set de caracteristici stabilite,
ID-ul obiectului recunoscut
Greta de pe pieptul stâng
Papagalul de pe umăr
Părul facial
100510
1
1
1
100511
0
0
1
100512
1
0
- rezultatul determinării tipului de client (să fie o reprezentație utilizator, în care sunt afișate descrierile din cataloage)
Înseamnă că denormalizarea descoperită face imposibilă adaptarea sistemelor la noile condiții? Desigur, nu. Dacă ne imaginăm că toate sistemele informaționale au fost create de o singură echipă fără fluctuații de personal, că dezvoltarea este bine documentată și informațiile circulă în echipă fără pierderi, modificările necesare pot fi realizate cu un efort neglijabil. Dar dacă ne întoarcem la condițiile inițiale ale problemei, doar pentru tipărirea protocoalelor discuțiilor comune s-ar consuma 1,5 tastaturi și încă 0,5 pentru formalizarea procedurilor de achiziții.
În exemplul dat mai sus, toate cele trei forme normale sunt încălcate, hai să încercăm să le încălcăm pe rând.
Încălcarea primei forme normale:
Să presupunem că produsele sunt livrate în depozitul dvs. de către furnizori prin autoturisme de 1,5 tone care aparțin tavernei dvs. Dimensiunea comenzilor dvs. este atât de mică în raport cu volumele furnizorilor, încât acestea sunt întotdeauna executate exact, fără a aștepta producerea. Este necesar, în această situație, să există tabele separate: vehicule, tipuri de vehicule, trebuie să separați planul și realitatea în comenzile dvs. înaintate furnizorilor?
Imaginați-vă câte „conexiuni suplimentare” va trebui să scrieți programatorilor dvs. dacă vor folosi modelul de mai jos pentru dezvoltarea programului.
Să spunem că am decis că structura propusă este excesiv de complicată, în cazul nostru separarea planului și realității în înregistrarea comenzii reprezintă o informație redundantă, iar specificația comenzii create se rescrie pe baza rezultatelor acceptării produselor primite, iar cazurile rare de sortare greșită și sosirea produselor de calitate nesatisfăcătoare sunt gestionate în afara sistemului informațional.
Și iată că într-o zi observați cum întreaga sală a tavernei este plină de pirați furioși și neîngrijiți. Ce s-a întâmplat?
Se pare că, odată cu creșterea afacerii dvs., a crescut și consumul. Cândva s-a luat decizia de management că, dacă autoturismul era suprasolicitat în volum și/sau greutate, ceea ce se întâmpla extrem de rar, furnizorul prioritiza încărcătura în favoarea băuturilor.
Produsele nedeliverate erau incluse în următoarea comandă și plecau în noua cursă, disponibilitatea unui stoc minim în depozitul de lângă tavernă permitea ignorarea cazurilor lipsă.
În port, ultimul concurent s-a închis, iar cazul de suprasolicitare a autoturismului, ocolit prin prioritizarea bazată pe presupunerea că există un stoc minim suficient și o încărcătură periodică insuficientă a vehiculului, a devenit o practică obișnuită. Sistemul creat va funcționa perfect conform algoritmilor integrați și va fi lipsit de orice posibilitate de a urmări neîndeplinirea sistematică a comenzilor planificate. Doar reputația deteriorată și clienții nemulțumiți vor putea descoperi problema.
Cititorul atent a observat, fără îndoială, că cantitatea comandată în specificația comenzii (T_ORDER_SPEC) din secțiunea 2 și din secțiunea 5 poate corespunde sau nu cerinței primei forme normale. Totul depinde de faptul dacă, având sortimentul de produse ales, pot fi incluse în același câmp unități de măsură diferite prin natura lor.
Încălcarea celei de-a doua forme normale:
Pe măsură ce cerințele dumneavoastră cresc, achiziționați încă câteva vehicule de transport de dimensiuni diferite. În contextul prezentat mai sus, crearea unui ghid al vehiculelor a fost considerată redundantă, rezultând că toate algoritmii de lucru cu datele, care sprijină nevoile de livrare și de depozitare, percep mișcarea mărfurilor de la furnizor la depozit ca o cursă exclusiv de 1,5 tone. Așadar, împreună cu achiziția de noi vehicule de transport, totuși creați un ghid al vehiculelor, dar în cursul adaptării va trebui să analizați tot codul care se referă la mișcarea mărfurilor pentru a determina dacă, în fiecare loc specific, se fac referiri la caracteristicile vehiculului cu care a început afacerea.
Încălcarea celei de-a treia forme normale:
Într-un anumit moment, începeți să creați un program de loialitate, apare înregistrarea unui client fidel. De ce, de exemplu, să pierdeți timpul creând reprezentări materiale care stochează date agregate despre vânzările unui client pentru utilizarea în raportare și transmiterea în sisteme analitice, dacă în etapa de start a programului de loialitate tot ce îi interesează clientului poate fi plasat în înregistrarea clientului însuși? Și, într-adevăr, la prima vedere, nu există sens. Dar de fiecare dată când afacerea dumneavoastră va conecta, de exemplu, noi canale de vânzare, printre analiștii dumneavoastră ar trebui să fie cineva care să-și aducă aminte că există un astfel de atribut de agregare.
Proiectând fiecare nou proces, de exemplu, vânzările pe Internet, vânzările prin distribuitori conectați la sistemul comun de loialitate, cineva trebuie să aibă în vedere că toate noile procese trebuie să asigure, la nivel de cod, integritatea datelor. Pentru o bază de date industrială cu o mie de tabele, aceasta pare o sarcină puțin plauzibilă.
Un dezvoltator experimentat știe, desigur, cum să gestioneze toate problemele menționate mai sus, dar, în opinia mea, sarcina unui analist experimentat este de a evita ajungerea la acestea.
Vreau să exprim recunoștința mea pentru feedback-ul valoros oferit în timpul pregătirii publicației de către principalul dezvoltator Evgheni Iaruhin.
Literatură
Connolly Thomas, Begg Carolyn. Baze de date. Proiectare, implementare și întreținere. Teorie și practică
Sursa: habr.com
