Buna ziua! Numele meu este Andrey Semenov, sunt analist senior la Sportmaster. În această postare vreau să ridic problema denormalizării bazelor de date ale sistemului ERP. Ne vom uita la condițiile generale, precum și la un exemplu specific - să spunem că ar fi o minunată tavernă de monopol pentru pirați și marinari. În care pirații și marinarii trebuie serviți diferit, deoarece ideile de frumusețe și modelele de consum ale acestor domni buni sunt semnificativ diferite.
Cum să-i faci pe toți fericiți? Cum poți evita să înnebunești proiectând și întreținând un astfel de sistem? Ce să faci dacă nu numai pirații și marinarii obișnuiți încep să vină la tavernă?
Totul este sub tăietură. Dar să mergem în ordine.
1. Limitări și ipoteze
Toate cele de mai sus se aplică numai bazelor de date relaționale. Consecințele denormalizării sub formă de anomalii de modificare, ștergere și inserare, care sunt bine acoperite, inclusiv pe Internet, nu sunt luate în considerare. În afara domeniului de aplicare al acestei publicații există cazuri în care denormalizarea este un loc comun, cu exemple clasice: seria și numărul pașapoartelor, data și ora etc.
Postarea folosește definiții intuitive și aplicabile practic ale formelor normale, fără referire la termeni matematici. În forma în care pot fi aplicate la examinarea proceselor reale de afaceri (BP) și proiectarea de software industrial.
Se susține că proiectarea depozitelor de date, a instrumentelor de raportare și a acordurilor de integrare (care utilizează reprezentări tabelare ale informațiilor) diferă de proiectarea bazelor de date ale sistemului ERP prin aceea că ușurința de consum și utilizarea denormalizării conștiente pentru a o realiza poate avea prioritate față de integritate. date de protectie. Împărtășesc această opinie, iar ceea ce este descris mai jos se aplică numai datelor de bază și modelelor de date tranzacționale ale sistemelor ERP.
O explicație a formelor normale este dată folosind un exemplu care este de înțeles la nivel de zi cu zi pentru majoritatea cititorilor. Cu toate acestea, ca o ilustrare vizuală, în paragrafele 4-5, a fost folosită în mod deliberat o sarcină „fictivă”. Dacă nu faceți acest lucru și luați un exemplu de manual, de exemplu, același model de stocare a comenzii de la punctul 2, vă puteți găsi într-o situație în care atenția cititorului va fi mutată de la descompunerea propusă a procesului într-un model, la experiența personală și la percepția asupra modului în care trebuie construite procesele și modelele de stocare a datelor în IS. Cu alte cuvinte, luați doi analiști IT calificați, unul să ofere servicii logisticienilor care transportă pasageri, celălalt logisticienilor care transportă utilaje pentru producția de microcipuri. Cereți-le, fără a discuta în avans despre BP automatizate, să creeze un model de date pentru stocarea informațiilor despre o călătorie pe calea ferată.
Există o probabilitate diferită de zero ca în modelele propuse să găsiți nu numai un set semnificativ diferit de atribute, ci și seturi divergente de entități, deoarece fiecare analist se va baza pe procesele și sarcinile care îi sunt familiare. Și într-o astfel de situație este imposibil să spunem care model este „corect”, deoarece nu există un criteriu de evaluare.
2. Forme normale
Prima formă normală a bazei de date necesită atomicitatea tuturor atributelor.
În special, dacă obiectul A are atribute non-cheie a și b, astfel încât c=f(a,b) și în tabelul care descrie obiectul A stocați valoarea atributului c, atunci prima formă normală este încălcată în baza de date. . De exemplu, dacă specificația de comandă indică o cantitate, ale cărei unități de măsură depind de tipul de produs: într-un caz poate fi bucăți, în altul litri, în al treilea pachete formate din bucăți (în modelul de mai sus Good_count_WR) , atunci atomicitatea atributelor este încălcată în baza de date. În acest caz, pentru a spune care ar trebui să fie clusterul de tabel al specificației comenzii, aveți nevoie de o descriere țintită a procesului de lucru în IS și, deoarece procesele pot fi diferite, pot exista multe versiuni „corecte”.
A doua formă normală a bazei de date necesită respectarea primului formular și a unui tabel propriu pentru fiecare entitate legată de procesul de lucru din IS. Dacă într-un tabel există dependențe c=f1(a) și d=f2(b) și nu există dependență c=f3(b), atunci a doua formă normală este încălcată în tabel. În exemplul de mai sus, nu există nicio dependență între comandă și adresă în tabelul Comanda. Schimbați numele străzii sau orașului și nu veți avea niciun efect asupra atributelor esențiale ale comenzii.
A treia bază de date cu formă normală 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ă după cum urmează: „tot ce poate fi calculat trebuie calculat”. Cu alte cuvinte, dacă există două obiecte A și B. În tabelul care stochează atributele obiectului A, se manifestă atributul C, iar obiectul B are atributul b, astfel încât c=f4(b) există, atunci a treia formă normală este încălcat. În exemplul de mai jos, atributul Cantitate de piese (Total_count_WR) din înregistrarea comenzii pretinde clar că încalcă a treia formă normală
3. Abordarea mea în aplicarea normalizării
1. Numai un proces de afaceri automatizat țintă poate oferi analistului criterii de identificare a entităților și atributelor atunci când creează un model de stocare a datelor. Crearea unui model de proces este o condiție prealabilă pentru crearea unui model de date normal.
2. Realizarea celei de-a treia forme normale în sens strict poate să nu fie practică în practica reală a creării de sisteme ERP dacă sunt îndeplinite unele sau toate următoarele condiții:
- procesele automatizate sunt rareori supuse modificării,
- termenele limită pentru cercetare și dezvoltare sunt strânse,
- cerințele pentru integritatea datelor sunt relativ scăzute (potenţialele erori în software-ul industrial nu duc la pierderea de bani sau de clienți de către clientul de software)
- etc
În condițiile descrise, costurile de identificare și descriere a ciclului de viață al unor obiecte și a atributelor acestora pot să nu fie justificate din punct de vedere al eficienței economice.
3. Orice consecințe ale denormalizării modelului de date într-un IS deja creat pot fi atenuate printr-un studiu preliminar aprofundat al codului și testare.
4. Denormalizarea este o modalitate de a transfera costurile forței de muncă din etapa de cercetare a surselor de date și proiectarea unui proces de afaceri până la etapa de dezvoltare, din perioada de implementare până în perioada de dezvoltare a sistemului.
5. Este recomandabil să depuneți eforturi pentru a treia formă normală a unei baze de date dacă:
- Direcția schimbării în procesele automate de afaceri este greu de prezis
- Există o diviziune slabă a muncii în cadrul echipei de implementare și/sau dezvoltare
- Sistemele incluse în circuitul de integrare se dezvoltă după propriile planuri
- Incoerența datelor poate duce la pierderea clienților sau a banilor unei companii
6. Proiectarea unui model de date ar trebui să fie realizată de un analist numai în legătură cu modelele procesului de afaceri țintă și procesul din SI. Dacă un dezvoltator proiectează un model de date, va trebui să se cufunde în domeniul subiectului într-o asemenea măsură încât, în special, să înțeleagă diferența dintre valorile atributelor - o condiție necesară pentru izolarea atributelor atomice. Astfel, asumând funcții neobișnuite.
4 Problemă pentru ilustrare
Să presupunem că aveți o mică tavernă robotică în port. Segmentul dvs. de piață: marinari și pirați care vin în port și au nevoie de o pauză. Vindeți ceai cu cimbru marinarilor și rom și piepteni de oase pentru a pieptăna bărbii piraților. Serviciul în tavernă în sine este asigurat de o gazdă robot și un barman robot. Datorită calității tale înalte și prețurilor mici, ți-ai alungat concurenții, astfel încât toți cei care ies de pe navă vin la taverna ta, care este singura din port.
Complexul de sisteme informatice de tavernă este format din următorul software:
- Un sistem de avertizare timpurie despre un client care își recunoaște categoria pe baza trăsăturilor caracteristice
- Sistem de control pentru robot hostess și robot barmani
- Sistem de management al depozitului și livrărilor la punctul de vânzare
- Sistemul de management al relațiilor cu furnizorii (SURP)
proces:
Sistemul de avertizare timpurie recunoaște persoanele care părăsesc nava. Dacă o persoană este bărbierită, ea îl identifică ca marinar; dacă se găsește că o persoană are barbă, atunci este identificat ca un pirat.
Intrând în tavernă, oaspetele aude un salut din partea gazdei robot conform categoriei sale, de exemplu: „Ho-ho-ho, dragă pirat, du-te la masa nr...”
Oaspetele merge la masa specificată, unde barmanul robot i-a pregătit deja mărfuri în conformitate cu categoria. Barmanul robot transmite sistemului de depozit informatie ca urmatoarea portiune de livrare ar trebui marita; depozitul IS, pe baza soldurilor ramase in depozit, genereaza o cerere de cumparare in sistemul de management.
În timp ce este posibil ca sistemul de avertizare timpurie să fi fost dezvoltat de IT-ul dumneavoastră intern, programul de management al roboților de bar poate fi creat de un contractant extern special pentru afacerea dumneavoastră. Iar sistemele de gestionare a depozitelor și relațiile cu furnizorii sunt soluții ambalate personalizate de pe piață.
5. Exemple de denormalizare și impactul acesteia asupra dezvoltării software
La proiectarea unui proces de afaceri, experții în materie intervievați au declarat în unanimitate că pirații din întreaga lume beau rom și își pieptănează barba cu piepteni de oase, iar marinarii beau ceai cu cimbru și sunt mereu bărbieriți.
Apare un director de tipuri de clienți cu două valori: 1 - pirați, 2 - marinari, comune întregului circuit informațional al companiei.
Sistemul de notificare client stochează imediat rezultatul procesării imaginii ca identificator (ID) al clientului recunoscut și tipul acestuia: marinar sau pirat.
ID-ul obiectului recunoscut
Categoria clientului
100500
pirat
100501
pirat
100502
marinar
Să remarcăm încă o dată că
1. Marinarii noștri sunt de fapt oameni bărbieriți
2. Piratii nostri sunt de fapt oameni cu barba
Ce probleme în acest caz trebuie eliminate, astfel încât structura noastră să se străduiască pentru a treia formă normală:
- încălcarea atomicității atributului - Categoria de client
- amestecând faptul analizat și concluzia într-un singur tabel
- relație funcțională fixă între atributele diferitelor entități.
În formă normalizată, vom obține două tabele:
- rezultatul recunoașterii sub forma unui set de caracteristici stabilite,
ID-ul obiectului recunoscut
Păr facial
100500
Da
100501
Da
100502
Nu
- rezultatul determinării tipului de client ca aplicare a logicii încorporate în SI pentru a interpreta caracteristicile stabilite
ID-ul obiectului recunoscut
ID de identificare
Categoria clientului
100500
100001
pirat
100501
100002
pirat
100502
100003
marinar
Cum poate o organizație normalizată de stocare a datelor să faciliteze dezvoltarea unui complex IP? Să presupunem că ai brusc clienți noi. Să fie pirații japonezi care poate nu au barbă, dar merg cu un papagal pe umăr, iar pirații ecologisti, îi poți recunoaște cu ușurință după profilul albastru al Gretei de pe pieptul stâng.
Pirații de mediu, desigur, nu pot folosi piepteni de os și cer un analog fabricat din plastic de mare reciclat.
Trebuie să reluați algoritmii programului în conformitate cu noile intrări. Dacă s-ar respecta regulile de normalizare, atunci ar trebui doar să suplimentați intrările pentru unele ramuri de proces în unele sisteme și să creați ramuri noi doar pentru acele cazuri și în acele IS-uri în care părul facial contează. Dar, din moment ce regulile nu au fost respectate, va trebui să analizați întregul cod, de-a lungul întregului circuit, unde sunt utilizate valorile directorului de tip client și să stabiliți clar că într-un caz algoritmul ar trebui să țină cont de profesioniști. activitatea clientului și în celelalte trăsături fizice.
Într-o formă care caută la normalizare, vom obține două tabele cu date operaționale și două directoare:
- rezultatul recunoașterii sub forma unui set de caracteristici stabilite,
ID-ul obiectului recunoscut
Greta pe piept stâng
Pasăre pe umăr
Păr facial
100510
1
1
1
100511
0
0
1
100512
1
0
- rezultatul determinării tipului de client (să fie o vizualizare personalizată în care sunt afișate descrierile din directoare)
Denormalizarea detectată înseamnă că sistemele nu pot fi modificate pentru a îndeplini condiții noi? Desigur că nu. Dacă ne imaginăm că toate sistemele informaționale au fost create de o echipă cu zero rotație de personal, evoluțiile sunt bine documentate și informațiile sunt transferate în cadrul echipei fără pierderi, atunci modificările necesare pot fi făcute cu un efort neglijabil. Dar dacă revenim la condițiile inițiale ale problemei, 1,5 tastaturi vor fi șterse doar pentru tipărirea protocoalelor de discuții comune și alte 0,5 pentru procesarea procedurilor de achiziție.
În exemplul de mai sus, toate cele trei forme normale sunt încălcate, să încercăm să le încălcăm separat.
Încălcarea primei forme normale:
Să presupunem că mărfurile sunt livrate în depozitul dumneavoastră de la depozitele furnizorilor prin ridicare folosind o gazelă de 1.5 tone care aparține tavernei dumneavoastră. Dimensiunea comenzilor dumneavoastră este atât de mică în raport cu cifra de afaceri a furnizorilor, încât acestea sunt întotdeauna finalizate unul la unu, fără a aștepta producția. Aveți nevoie de tabele separate cu un astfel de proces de afaceri: vehicule, tipuri de vehicule, este necesar să separați planul și fapta în comenzile dumneavoastră către furnizorii plecați?
Imaginează-ți doar câte conexiuni „în plus” vor trebui să scrie programatorii tăi dacă folosești modelul de mai jos pentru a dezvolta un program.
Să presupunem că am decis că structura propusă este inutil de complexă; în cazul nostru, separarea planului și a faptului în înregistrarea comenzii este o informație redundantă, iar specificația de comandă generată este rescrisă pe baza rezultatelor acceptării mărfurilor sosite, rareori. -clasarea și sosirea mărfurilor de calitate necorespunzătoare se decontează în afara SI.
Și apoi într-o zi vezi cum toată sala tavernei este plină de pirați indignați și neîngrijiți. Ce s-a întâmplat?
Se pare că pe măsură ce afacerea dvs. a crescut, la fel și consumul dvs. Pe vremuri, s-a luat o decizie a managementului că dacă o gazelă era supraîncărcată în volum și/sau greutate, ceea ce era extrem de rar, furnizorul ar acorda prioritate încărcăturii în favoarea băuturilor.
Marfa nelivrată a ajuns la următoarea comandă și a plecat pe un nou zbor; prezența unui sold minim în depozitul de la tavernă a făcut posibil să nu sesizeze cazuri lipsă.
Ultimul concurent s-a închis în port, iar cazul perforat de supraîncărcare gazele, ocolit prin prioritizare bazată pe presupunerea suficienței echilibrului minim și a subîncărcării periodice a vehiculului, a devenit o practică obișnuită. Sistemul creat va funcționa în mod ideal în conformitate cu algoritmii încorporați în el și va fi lipsit de orice oportunitate de a urmări eșecul sistematic de a îndeplini comenzile planificate. Doar o reputație deteriorată și clienții nemulțumiți vor putea detecta problema.
Este posibil ca un cititor atent să fi observat că cantitatea comandată din specificația comenzii (T_ORDER_SPEC) din secțiunea 2 și secțiunea 5 poate îndeplini sau nu cerințele primei forme normale. Totul depinde dacă, având în vedere sortimentul de mărfuri selectat, unități de măsură diferite pot intra în același domeniu.
Încălcarea celei de-a doua forme normale:
Pe măsură ce nevoile dvs. cresc, mai cumpărați câteva vehicule de diferite dimensiuni. În contextul de mai sus, crearea unui director de vehicule a fost considerată redundantă; ca urmare, toți algoritmii de prelucrare a datelor care servesc nevoilor de livrare și depozit percep mișcarea mărfurilor de la furnizor la depozit ca zborul unui vehicul exclusiv de 1,5 tone. gazelă. Așadar, odată cu achiziționarea de vehicule noi, tot creați un director de vehicule, dar la finalizarea acestuia va trebui să analizați tot codul care face referire la mișcarea mărfii pentru a afla dacă în fiecare loc specific sunt implicate referințe la caracteristici. chiar a vehiculului de la care a început afacerea.
Încălcarea celei de-a treia forme normale:
La un moment dat începi să creezi un program de loialitate, apare o înregistrare a unui client obișnuit. De ce, de exemplu, să petreceți timp creând vizualizări materiale care stochează date agregate despre vânzările către un client individual pentru a fi utilizate în raportare și transferul către sisteme analitice, dacă la începutul unui program de loialitate tot ceea ce interesează clientul poate fi trecut în evidența clientului ? Și, într-adevăr, la prima vedere, nu are rost. Dar de fiecare dată când afacerea ta conectează, de exemplu, noi canale de vânzare, ar trebui să existe cineva printre analiștii tăi care își va aminti că există un astfel de atribut de agregare.
La proiectarea fiecărui proces nou, de exemplu, vânzări pe Internet, vânzări prin distribuitori conectați la un sistem comun de loialitate, cineva trebuie să țină cont de faptul că toate procesele noi trebuie să asigure integritatea datelor la nivel de cod. Pentru o bază de date industrială cu o mie de tabele, aceasta pare o sarcină imposibilă.
Un dezvoltator cu experiență, desigur, știe să oprească toate problemele menționate mai sus, dar, în opinia mea, sarcina unui analist experimentat nu este să le scoată la lumină.
Aș dori să-mi exprim recunoștința față de dezvoltatorul principal Evgeniy Yarukhin pentru feedback-ul său valoros în timpul pregătirii publicației.
Literatură
Connolly Thomas, Begg Caroline. Bază de date. Proiectare, implementare și suport. Teorie și practică
Sursa: www.habr.com