Hola! Em dic Andrey Semenov, sóc analista sènior a Sportmaster. En aquest post vull plantejar el tema de la desnormalització de les bases de dades del sistema ERP. Mirarem les condicions generals, així com un exemple concret: diguem que seria una meravellosa taverna de monopoli per a pirates i mariners. En què els pirates i els mariners han de ser atès de manera diferent, perquè les idees de bellesa i els patrons de consum d'aquests bons senyors són molt diferents.
Com fer feliç a tothom? Com pots evitar tornar-te boig dissenyant i mantenint aquest sistema? Què fer si no només comencen a venir a la taverna els pirates i mariners habituals?
Tot està sota el tall. Però anem en ordre.
1. Limitacions i supòsits
Tot l'anterior només s'aplica a les bases de dades relacionals. No es tenen en compte les conseqüències de la desnormalització en forma de modificació, supressió i anomalies d'inserció, que estan ben cobertes, fins i tot a Internet. Fora de l'àmbit d'aquesta publicació hi ha casos on la desnormalització és un lloc habitual, amb exemples clàssics: sèrie i número de passaport, data i hora, etc.
La publicació utilitza definicions intuïtives i pràcticament aplicables de formes normals, sense fer referència a termes matemàtics. En la forma en què es poden aplicar a l'examen de processos empresarials reals (BP) i al disseny de programari industrial.
S'argumenta que el disseny dels magatzems de dades, les eines de presentació d'informes i els acords d'integració (que utilitzen representacions tabulars de la informació) difereix del disseny de les bases de dades del sistema ERP en què la facilitat de consum i l'ús de la desnormalització conscient per aconseguir-ho poden tenir prioritat sobre la integritat. dades de protecció. Comparteixo aquesta opinió, i el que es descriu a continuació s'aplica únicament a les dades mestres i als models de dades transaccionals dels sistemes ERP.
Es dóna una explicació de les formes normals utilitzant un exemple que és comprensible a nivell quotidià per a la majoria dels lectors. Tanmateix, com a il·lustració visual, als paràgrafs 4-5, es va utilitzar deliberadament una tasca deliberadament "fictícia". Si no feu això i preneu algun exemple de llibre de text, per exemple, el mateix model d'emmagatzematge d'ordres del punt 2, és possible que us trobeu en una situació en què l'atenció del lector es desplaçarà de la descomposició proposada del procés a un model, a l'experiència personal i la percepció de com s'han de construir processos i models per emmagatzemar dades en SI. En altres paraules, prengui dos analistes informàtics qualificats, que un presti serveis als logístics que transporten passatgers, l'altre als logístics que transporten màquines per a la producció de microxips. Demaneu-los, sense parlar de les BP automatitzades per endavant, que creïn un model de dades per emmagatzemar informació sobre un viatge en tren.
Hi ha una probabilitat diferent de nul·la que als models proposats trobeu no només un conjunt d'atributs notablement diferent, sinó també conjunts d'entitats divergents, perquè cada analista es basarà en els processos i les tasques que li són familiars. I en aquesta situació és impossible dir quin model és "correcte", perquè no hi ha cap criteri d'avaluació.
2. Formes normals
Primera forma normal de la base de dades requereix atomicitat de tots els atributs.
En particular, si l'objecte A té atributs no clau a i b, de manera que c=f(a,b) i a la taula que descriu l'objecte A emmagatzemeu el valor de l'atribut c, aleshores es viola la primera forma normal a la base de dades. . Per exemple, si l'especificació de la comanda indica una quantitat, les unitats de mesura de la qual depenen del tipus de producte: en un cas poden ser peces, en un altre litres, en un tercer paquets formats per peces (en el model anterior Good_count_WR) , llavors l'atomicitat dels atributs es viola a la base de dades. En aquest cas, per dir quin ha de ser el clúster de taula de l'especificació de la comanda, necessiteu una descripció específica del procés de treball a l'IS, i com que els processos poden ser diferents, hi pot haver moltes versions "correctes".
Segona forma normal de la base de dades exigeix el compliment del primer formulari i d'un quadre propi per a cada entitat relacionada amb el procés de treball a l'IS. Si en una taula hi ha dependències c=f1(a) i d=f2(b) i no hi ha cap dependència c=f3(b), aleshores es viola la segona forma normal a la taula. A l'exemple anterior, no hi ha cap dependència entre l'ordre i l'adreça a la taula de comanda. Canvia el nom del carrer o de la ciutat i no tindràs cap efecte sobre els atributs essencials de la comanda.
Tercera base de dades de forma normal requereix el compliment de la segona forma normal i l'absència de dependències funcionals entre atributs de diferents entitats. Aquesta regla es pot formular de la següent manera: "tot el que es pugui calcular s'ha de calcular". En altres paraules, si hi ha dos objectes A i B. A la taula que emmagatzema els atributs de l'objecte A, es manifesta l'atribut C i l'objecte B té l'atribut b, de manera que existeix c=f4(b), llavors la tercera forma normal. es viola. A l'exemple següent, l'atribut Quantity of Pieces (Total_count_WR) al registre de la comanda afirma clarament que infringeix la tercera forma normal
3. El meu enfocament per aplicar la normalització
1. Només un procés de negoci automatitzat objectiu pot proporcionar a l'analista criteris per identificar entitats i atributs quan es crea un model d'emmagatzematge de dades. La creació d'un model de procés és un requisit previ per crear un model de dades normal.
2. Aconseguir la tercera forma normal en sentit estricte pot no ser pràctic en la pràctica real de crear sistemes ERP si es compleixen algunes o totes les condicions següents:
- els processos automatitzats rarament estan subjectes a canvis,
- els terminis per a la recerca i el desenvolupament són ajustats,
- Els requisits per a la integritat de les dades són relativament baixos (els possibles errors en el programari industrial no comporten la pèrdua de diners o de clients per part del client del programari)
- etcètera
En les condicions descrites, els costos d'identificar i descriure el cicle de vida d'alguns objectes i els seus atributs poden no estar justificats des del punt de vista de l'eficiència econòmica.
3. Qualsevol conseqüència de la desnormalització del model de dades en un SI ja creat es pot mitigar mitjançant un estudi preliminar exhaustiu del codi i proves.
4. La desnormalització és una manera de transferir els costos laborals des de l'etapa d'investigació de fonts de dades i disseny d'un procés empresarial fins a l'etapa de desenvolupament, des del període d'implementació fins al període de desenvolupament del sistema.
5. És recomanable buscar la tercera forma normal d'una base de dades si:
- La direcció del canvi en els processos de negoci automatitzats és difícil de predir
- Hi ha una feble divisió del treball dins de l'equip d'implementació i/o desenvolupament
- Els sistemes inclosos en el circuit d'integració es desenvolupen segons els seus propis plans
- La inconsistència de les dades pot fer que una empresa perdi clients o diners
6. El disseny d'un model de dades l'ha de dur a terme un analista només en relació amb els models del procés de negoci objectiu i el procés al SI. Si un desenvolupador està dissenyant un model de dades, haurà de submergir-se en l'àrea temàtica fins a tal punt que, en particular, entengui la diferència entre els valors dels atributs, una condició necessària per aïllar els atributs atòmics. Per tant, assumint funcions inusuals.
4 Problema per il·lustració
Suposem que tens una petita taverna robòtica al port. El teu segment de mercat: mariners i pirates que entren al port i necessiten un descans. Vens te amb farigola als mariners, i pintes de rom i ossos per pentinar les barbes als pirates. El servei a la pròpia taverna és prestat per una hostessa robot i un barman robot. Gràcies a la teva gran qualitat i preus baixos, has expulsat als teus competidors, de manera que tots els que surten del vaixell arriben a la teva taverna, que és l'única del port.
El complex de sistemes d'informació de la taverna consta del programari següent:
- Un sistema d'alerta primerenca sobre un client que reconeix la seva categoria en funció dels trets característics
- Sistema de control per a hostesses robot i cambrers robot
- Sistema de gestió de magatzem i lliurament al punt de venda
- Sistema de gestió de relacions amb proveïdors (SURP)
Procés:
El sistema d'alerta primerenca reconeix les persones que surten del vaixell. Si una persona està ben afaitada, l'identifica com a mariner; si es descobreix que una persona té barba, s'identifica com a pirata.
Entrant a la taverna, el convidat escolta una salutació de l'hostessa robot d'acord amb la seva categoria, per exemple: "Ho-ho-ho, estimat pirata, vés a la taula No..."
El convidat va a la taula especificada, on el cambrer robot ja li ha preparat productes d'acord amb la categoria. El cambrer robot transmet informació al sistema de magatzem que s'ha d'augmentar la següent part de lliurament; el magatzem IS, en funció dels saldos restants en emmagatzematge, genera una sol·licitud de compra al sistema de gestió.
Tot i que el sistema d'alerta primerenca pot haver estat desenvolupat per la vostra TI interna, el programa de gestió de robots de barra pot haver estat creat per un contractista extern específicament per al vostre negoci. I els sistemes de gestió de magatzems i de relació amb proveïdors són solucions empaquetades personalitzades del mercat.
5. Exemples de desnormalització i el seu impacte en el desenvolupament de programari
A l'hora de dissenyar un procés empresarial, els experts en la matèria entrevistats van afirmar per unanimitat que a tot el món els pirates beuen rom i es pentinen la barba amb pintes d'os, i els mariners beuen te amb farigola i sempre estan ben afaitats.
Apareix un directori de tipus de clients amb dos valors: 1 - pirates, 2 - mariners, comuns a tot el circuit informatiu de l'empresa.
El sistema de notificació del client emmagatzema immediatament el resultat del tractament d'imatges com a identificador (ID) del client reconegut i el seu tipus: mariner o pirata.
Identificador d'objecte reconegut
Categoria de client
100500
Pirata
100501
Pirata
100502
Mariner
Recordem-ho una vegada més
1. Els nostres mariners són realment gent afaitat
2. Els nostres pirates són en realitat gent barbuda
Quins problemes s'han d'eliminar en aquest cas perquè la nostra estructura s'esforci per la tercera forma normal:
- infracció d'atomicitat de l'atribut - Categoria de client
- barrejant el fet analitzat i la conclusió en una taula
- relació funcional fixa entre atributs de diferents entitats.
En forma normalitzada, obtindríem dues taules:
- resultat del reconeixement en forma d'un conjunt de característiques establertes,
Identificador d'objecte reconegut
Pèl facial
100500
Sí
100501
Sí
100502
No
- el resultat de determinar el tipus de client com a aplicació de la lògica incrustada en el SI per interpretar les característiques establertes
Identificador d'objecte reconegut
DNI d'identificació
Categoria de client
100500
100001
Pirata
100501
100002
Pirata
100502
100003
Mariner
Com pot una organització normalitzada d'emmagatzematge de dades facilitar el desenvolupament d'un complex IP? Suposem que de sobte tens nous clients. Que siguin pirates japonesos que potser no tenen barba, però caminen amb un lloro a l'espatlla, i pirates ecologistes, els podeu reconèixer fàcilment pel perfil blau de la Greta al pit esquerre.
Els pirates ambientals, naturalment, no poden utilitzar pintes d'os i exigeixen un anàleg fet de plàstic marin reciclat.
Cal reelaborar els algorismes del programa d'acord amb les noves entrades. Si es seguissin les regles de normalització, només hauríeu de complementar les entrades d'algunes branques del procés en alguns sistemes i crear noves branques només per a aquells casos i en aquells IS on el pèl facial importa. Però, com que no es van seguir les regles, hauràs d'analitzar tot el codi, al llarg de tot el circuit, on s'utilitzen els valors del directori tipus de client i establir clarament que en un cas l'algorisme hauria de tenir en compte el professional. l'activitat del client, i en les altres característiques físiques.
En una forma que busca per normalitzar, obtindríem dues taules amb dades operatives i dos directoris:
- resultat del reconeixement en forma d'un conjunt de característiques establertes,
Identificador d'objecte reconegut
Greta al pit esquerre
Ocell a l'espatlla
Pèl facial
100510
1
1
1
100511
0
0
1
100512
1
0
- el resultat de determinar el tipus de client (que sigui una vista personalitzada en la qual es mostren les descripcions dels directoris)
La desnormalització detectada significa que els sistemes no es poden modificar per complir noves condicions? És clar que no. Si ens imaginem que tots els sistemes d'informació van ser creats per un equip amb zero rotació de personal, els desenvolupaments estan ben documentats i la informació es transfereix dins de l'equip sense pèrdues, aleshores els canvis requerits es poden fer amb un esforç insignificant. Però si tornem a les condicions originals del problema, s'esborraran 1,5 teclats només per a la impressió de protocols de discussions conjuntes i un altre 0,5 per tramitar els procediments de contractació.
A l'exemple anterior, es violen les tres formes normals, intentem violar-les per separat.
Incompliment de la primera forma normal:
Suposem que la mercaderia s'entrega al vostre magatzem des dels magatzems dels proveïdors mitjançant la recollida mitjançant una gasela d'1.5 tones que pertany a la vostra taverna. La mida de les vostres comandes és tan petita en relació amb la facturació dels proveïdors que sempre es completen un a un sense esperar la producció. Necessiteu taules separades amb aquest procés de negoci: vehicles, tipus de vehicles, és necessari separar el pla i els fets en les vostres comandes als proveïdors abandonats?
Imagineu quantes connexions "extra" hauran d'escriure els vostres programadors si feu servir el model següent per desenvolupar un programa.
Suposem que hem decidit que l'estructura proposada és innecessàriament complexa; en el nostre cas, separar el pla i el fet al registre de la comanda és informació redundant, i l'especificació de la comanda generada es reescriu en funció dels resultats de l'acceptació de la mercaderia arribada, rarament error. -La classificació i l'arribada de béns de qualitat inadequada es resolen fora de l'IS.
I aleshores un dia veus com tota la sala de la taverna s'omple de pirates indignats i descuidats. Què va passar?
Resulta que a mesura que el teu negoci creixia, el teu consum també. Hi havia una vegada la decisió de la direcció que si una gasela estava sobrecarregada en volum i/o pes, cosa que era extremadament rara, el proveïdor prioritzava la càrrega a favor de les begudes.
La mercaderia no lliurada va acabar en la següent comanda i va marxar en un nou vol; la presència d'un saldo mínim al magatzem de la taverna va permetre no notar caixes desaparegudes.
L'últim competidor va tancar al port, i el cas punxat de sobrecàrrega de gasela, obviat per la priorització basada en el supòsit de la suficiència de l'equilibri mínim i la subcàrrega periòdica del vehicle, es va convertir en pràctica habitual. El sistema creat funcionarà idealment d'acord amb els algorismes integrats en ell i es veurà privat de qualsevol oportunitat de fer un seguiment del fracàs sistemàtic per complir les comandes planificades. Només una reputació danyada i clients insatisfets podran detectar el problema.
Un lector atent pot haver notat que la quantitat demanada a l'especificació de la comanda (T_ORDER_SPEC) a la secció 2 i la secció 5 pot complir o no el requisit de la primera forma normal. Tot depèn de si, donat l'assortiment de mercaderies seleccionat, poden caure en el mateix camp unitats de mesura essencialment diferents.
Incompliment de la segona forma normal:
A mesura que creixen les vostres necessitats, compreu un parell de vehicles més de diferents mides. En el context anterior, es va considerar redundant la creació d'un directori de vehicles; com a resultat, tots els algorismes de processament de dades que atenen les necessitats de lliurament i magatzem perceben el moviment de la càrrega del proveïdor al magatzem com el vol d'una tonelada exclusivament d'1,5 tones. gasela. Així doncs, juntament amb la compra de vehicles nous, continues creant un directori de vehicles, però en finalitzar-lo hauràs d'analitzar tot el codi que fa referència al moviment de càrrega per saber si en cada lloc concret hi ha referències a les característiques. del mateix vehicle des del qual va començar el negoci.
Incompliment de la tercera forma normal:
En algun moment es comença a crear un programa de fidelització, apareix un registre d'un client habitual. Per què, per exemple, dedicar temps a crear vistes materials que emmagatzemen dades agregades sobre les vendes a un client individual per utilitzar-les en informes i transferir-les a sistemes analítics, si a l'inici d'un programa de fidelització tot el que interessa al client es pot posar al registre del client? ? I, efectivament, a primera vista, no té sentit. Però cada vegada que la vostra empresa connecti, per exemple, nous canals de venda, hi hauria d'haver algú entre els vostres analistes que recordi que aquest atribut d'agregació existeix.
A l'hora de dissenyar cada nou procés, per exemple, vendes a Internet, vendes a través de distribuïdors connectats a un sistema de fidelització comú, algú ha de tenir en compte que tots els nous processos han de garantir la integritat de les dades a nivell de codi. Per a una base de dades industrial amb mil taules, sembla una tasca impossible.
Un desenvolupador experimentat, és clar, sap com aturar tots els problemes esmentats anteriorment, però, al meu entendre, la tasca d'un analista experimentat no és treure'ls a la llum.
M'agradaria expressar el meu agraïment al desenvolupador líder Evgeniy Yarukhin pels seus valuosos comentaris durant la preparació de la publicació.
Literatura
Connolly Thomas, Begg Caroline. Base de dades. Disseny, implementació i suport. Teoria i pràctica
Font: www.habr.com