Kamusta! Ang pangalan ko ay Andrey Semenov, ako ay isang senior analyst sa Sportmaster. Sa post na ito gusto kong itaas ang isyu ng denormalization ng mga database ng ERP system. Titingnan natin ang mga pangkalahatang kondisyon, pati na rin ang isang tiyak na halimbawa - sabihin nating ito ay magiging isang kahanga-hangang monopolyong tavern para sa mga pirata at mandaragat. Kung saan ang mga pirata at mga mandaragat ay dapat pagsilbihan sa ibang paraan, dahil ang mga ideya ng kagandahan at mga pattern ng mamimili ng mga mabubuting ginoo ay makabuluhang naiiba.
Paano mapasaya ang lahat? Paano mo maiiwasang mabaliw sa pagdidisenyo at pagpapanatili ng ganitong sistema? Ano ang gagawin kung hindi lamang ang karaniwang mga pirata at mandaragat ay nagsimulang pumunta sa tavern?
Ang lahat ay nasa ilalim ng hiwa. Ngunit pumunta tayo sa pagkakasunud-sunod.
1. Mga limitasyon at pagpapalagay
Ang lahat ng nasa itaas ay nalalapat lamang sa mga relational database. Ang mga kahihinatnan ng denormalization sa anyo ng pagbabago, pagtanggal, at mga anomalya sa pagpapasok, na mahusay na sakop, kabilang ang sa Internet, ay hindi isinasaalang-alang. Sa labas ng saklaw ng publikasyong ito ay may mga kaso kung saan ang denormalization ay isang karaniwang lugar, na may mga klasikong halimbawa: serye ng pasaporte at numero, petsa at oras, atbp.
Gumagamit ang post ng intuitive at praktikal na naaangkop na mga kahulugan ng mga normal na anyo, nang walang pagtukoy sa mga terminong pangmatematika. Sa anyo kung saan maaari silang mailapat sa pagsusuri ng mga tunay na proseso ng negosyo (BP) at ang disenyo ng pang-industriya na software.
Pinagtatalunan na ang disenyo ng mga warehouse ng data, mga tool sa pag-uulat at mga kasunduan sa pagsasama (na gumagamit ng mga tabular na representasyon ng impormasyon) ay naiiba sa disenyo ng mga database ng ERP system sa kadalian ng pagkonsumo at ang paggamit ng conscious denormalization upang makamit ito ay maaaring mauna kaysa sa integridad data ng proteksyon. Ibinabahagi ko ang opinyong ito, at ang inilalarawan sa ibaba ay nalalapat lamang sa master data at mga transactional data model ng mga ERP system.
Ang paliwanag ng mga normal na anyo ay ibinibigay gamit ang isang halimbawa na naiintindihan sa pang-araw-araw na antas para sa karamihan ng mga mambabasa. Gayunpaman, bilang isang visual na paglalarawan, sa mga talata 4-5, isang sadyang "fictional" na gawain ang sadyang ginamit. Kung hindi mo ito gagawin at kumuha ng ilang halimbawa ng aklat-aralin, halimbawa, ang parehong modelo ng imbakan ng pagkakasunud-sunod mula sa punto 2, maaari mong makita ang iyong sarili sa isang sitwasyon kung saan ang pokus ng mambabasa ay maililipat mula sa iminungkahing agnas ng proseso patungo sa isang modelo, sa personal na karanasan at pananaw kung paano dapat buuin ang mga proseso at modelo para sa pag-iimbak ng data sa IS. Sa madaling salita, kumuha ng dalawang kwalipikadong IT analyst, hayaan ang isa na magbigay ng mga serbisyo sa mga logistician na nagdadala ng mga pasahero, ang isa sa mga logistician na nagdadala ng mga makina para sa produksyon ng mga microchips. Hilingin sa kanila, nang hindi tinatalakay nang maaga ang mga awtomatikong BP, na lumikha ng modelo ng data para sa pag-iimbak ng impormasyon tungkol sa isang biyahe sa tren.
Mayroong hindi zero na posibilidad na sa mga iminungkahing modelo ay makikita mo hindi lamang ang isang kapansin-pansing magkakaibang hanay ng mga katangian, kundi pati na rin ang magkakaibang hanay ng mga entidad, dahil ang bawat analyst ay aasa sa mga proseso at gawain na pamilyar sa kanya. At sa ganitong sitwasyon imposibleng sabihin kung aling modelo ang "tama", dahil walang pamantayan sa pagsusuri.
2. Mga normal na anyo
Unang normal na anyo ng database nangangailangan ng atomicity ng lahat ng mga katangian.
Sa partikular, kung ang object A ay may mga hindi pangunahing katangian na a at b, kung gayon ang c=f(a,b) at sa talahanayan na naglalarawan sa object A ay iniimbak mo ang halaga ng katangian c, kung gayon ang unang normal na anyo ay nilabag sa database . Halimbawa, kung ang detalye ng order ay nagpapahiwatig ng isang dami, ang mga yunit ng pagsukat na depende sa uri ng produkto: sa isang kaso maaari itong maging mga piraso, sa isa pang litro, sa isang ikatlong pakete na binubuo ng mga piraso (sa modelo sa itaas Good_count_WR) , pagkatapos ay nilabag ang atomicity ng mga katangian sa database. Sa kasong ito, upang masabi kung ano ang dapat na kumpol ng talahanayan ng detalye ng order, kailangan mo ng naka-target na paglalarawan ng proseso ng trabaho sa IS, at dahil maaaring magkaiba ang mga proseso, maaaring mayroong maraming "tama" na bersyon.
Pangalawang normal na anyo ng database nangangailangan ng pagsunod sa unang anyo at sarili nitong talahanayan para sa bawat entity na nauugnay sa proseso ng trabaho sa IS. Kung sa isang talahanayan ay may mga dependency c=f1(a) at d=f2(b) at walang dependency c=f3(b), kung gayon ang pangalawang normal na anyo ay nilabag sa talahanayan. Sa halimbawa sa itaas, walang dependency sa pagitan ng order at address sa talahanayan ng Order. Baguhin ang pangalan ng kalye o lungsod at wala kang epekto sa mahahalagang katangian ng order.
Pangatlong normal na form na database nangangailangan ng pagsunod sa pangalawang normal na anyo at ang kawalan ng functional dependencies sa pagitan ng mga katangian ng iba't ibang entity. Ang panuntunang ito ay maaaring buuin tulad ng sumusunod: "lahat ng bagay na maaaring kalkulahin ay dapat kalkulahin." Sa madaling salita, kung mayroong dalawang bagay A at B. Sa talahanayan na nag-iimbak ng mga katangian ng bagay A, ipinapakita ang katangiang C, at ang bagay na B ay may katangiang b, kung saan umiiral ang c=f4(b), pagkatapos ay ang pangatlong normal na anyo ay nilabag. Sa halimbawa sa ibaba, ang katangian ng Quantity of Pieces (Total_count_WR) sa talaan ng order ay malinaw na sinasabing lumalabag sa ikatlong normal na anyo
3. Ang aking diskarte sa paglalapat ng normalisasyon
1. Tanging isang target na awtomatikong proseso ng negosyo ang makakapagbigay sa analyst ng pamantayan para sa pagtukoy ng mga entity at katangian kapag gumagawa ng modelo ng pag-iimbak ng data. Ang paglikha ng isang modelo ng proseso ay isang kinakailangan para sa paglikha ng isang normal na modelo ng data.
2. Ang pagkamit ng ikatlong normal na anyo sa mahigpit na kahulugan ay maaaring hindi praktikal sa aktwal na pagsasagawa ng paglikha ng mga ERP system kung ang ilan o lahat ng sumusunod na kundisyon ay natutugunan:
- ang mga awtomatikong proseso ay bihirang napapailalim sa pagbabago,
- ang mga deadline para sa pananaliksik at pag-unlad ay mahigpit,
- ang mga kinakailangan para sa integridad ng data ay medyo mababa (mga potensyal na error sa pang-industriya na software ay hindi humantong sa pagkawala ng pera o mga kliyente ng customer ng software)
- at iba pa
Sa ilalim ng inilarawang mga kundisyon, ang mga gastos sa pagtukoy at paglalarawan sa ikot ng buhay ng ilang mga bagay at ang kanilang mga katangian ay maaaring hindi mabigyang-katwiran mula sa punto ng view ng kahusayan sa ekonomiya.
3. Anumang kahihinatnan ng denormalization ng modelo ng data sa isang nilikha na IS ay maaaring pagaanin ng isang masusing paunang pag-aaral ng code at pagsubok.
4. Ang denormalization ay isang paraan upang ilipat ang mga gastos sa paggawa mula sa yugto ng pagsasaliksik ng mga pinagmumulan ng data at pagdidisenyo ng proseso ng negosyo hanggang sa yugto ng pag-unlad, mula sa panahon ng pagpapatupad hanggang sa panahon ng pagbuo ng system.
5. Maipapayo na magsikap para sa ikatlong normal na anyo ng isang database kung:
- Ang direksyon ng pagbabago sa mga awtomatikong proseso ng negosyo ay mahirap hulaan
- Mayroong mahinang dibisyon ng paggawa sa loob ng pangkat ng pagpapatupad at/o pagpapaunlad
- Ang mga system na kasama sa integration circuit ay bubuo ayon sa kanilang sariling mga plano
- Ang hindi pagkakapare-pareho ng data ay maaaring magresulta sa pagkawala ng mga customer o pera ng isang kumpanya
6. Ang disenyo ng isang modelo ng data ay dapat na isagawa ng isang analyst lamang na may kaugnayan sa mga modelo ng target na proseso ng negosyo at ang proseso sa IS. Kung ang isang developer ay nagdidisenyo ng isang modelo ng data, kailangan niyang isawsaw ang kanyang sarili sa lugar ng paksa sa isang lawak na, sa partikular, naiintindihan niya ang pagkakaiba sa pagitan ng mga halaga ng katangian - isang kinakailangang kondisyon para sa paghihiwalay ng mga atomic na katangian. Kaya, ang pagkuha sa hindi pangkaraniwang mga pag-andar.
4 Problema para sa paglalarawan
Sabihin nating mayroon kang maliit na robotic tavern sa daungan. Ang iyong segment ng merkado: mga mandaragat at pirata na pumapasok sa daungan at nangangailangan ng pahinga. Nagbebenta ka ng tsaa na may thyme sa mga mandaragat, at rum at bone combs para sa pagsusuklay ng balbas sa mga pirata. Ang serbisyo sa mismong tavern ay ibinibigay ng isang robot hostess at isang robot bartender. Salamat sa iyong mataas na kalidad at mababang presyo, naitaboy mo ang iyong mga kakumpitensya, upang ang lahat ng bumababa sa barko ay pumunta sa iyong tavern, na nag-iisa sa daungan.
Ang tavern information systems complex ay binubuo ng sumusunod na software:
- Isang sistema ng maagang babala tungkol sa isang kliyente na kinikilala ang kategorya nito batay sa mga katangiang katangian
- Control system para sa mga robot hostesses at robot bartender
- Warehouse at sistema ng pamamahala ng paghahatid sa punto ng pagbebenta
- Supplier Relationship Management System (SURP)
Proseso:
Kinikilala ng early warning system ang mga taong umaalis sa barko. Kung ang isang tao ay malinis na ahit, kinikilala niya siya bilang isang mandaragat; kung ang isang tao ay natagpuang may balbas, siya ay nakilala bilang isang pirata.
Pagpasok sa tavern, ang panauhin ay nakarinig ng pagbati mula sa robot na babaing punong-abala alinsunod sa kanyang kategorya, halimbawa: "Ho-ho-ho, mahal na pirata, pumunta sa mesa No..."
Ang panauhin ay pumunta sa tinukoy na mesa, kung saan ang robot bartender ay naghanda na ng mga kalakal para sa kanya alinsunod sa kategorya. Ang robot bartender ay nagpapadala ng impormasyon sa warehouse system na ang susunod na bahagi ng paghahatid ay dapat na tumaas; ang warehouse IS, batay sa natitirang mga balanse sa imbakan, ay bumubuo ng isang kahilingan sa pagbili sa sistema ng pamamahala.
Bagama't ang sistema ng maagang babala ay maaaring binuo ng iyong panloob na IT, ang programa sa pamamahala ng bar robot ay maaaring ginawa ng isang panlabas na kontratista na partikular para sa iyong negosyo. At ang mga sistema para sa pamamahala ng mga bodega at pakikipag-ugnayan sa mga supplier ay naka-customize na mga naka-package na solusyon mula sa merkado.
5. Mga halimbawa ng denormalization at epekto nito sa pagbuo ng software
Kapag nagdidisenyo ng isang proseso ng negosyo, ang mga nakapanayam na mga eksperto sa paksa ay nagkakaisa na nagsabi na ang mga pirata sa buong mundo ay umiinom ng rum at nagsusuklay ng kanilang mga balbas gamit ang mga suklay ng buto, at ang mga mandaragat ay umiinom ng tsaa na may thyme at palaging malinis na ahit.
Lumilitaw ang isang direktoryo ng mga uri ng kliyente na may dalawang halaga: 1 - mga pirata, 2 - mga mandaragat, karaniwan para sa buong circuit ng impormasyon ng kumpanya.
Agad na iniimbak ng system ng notification ng kliyente ang resulta ng pagpoproseso ng imahe bilang identifier (ID) ng kinikilalang kliyente at ang uri nito: mandaragat o pirata.
Kinikilalang object ID
Kategorya ng kliyente
100500
Pirata
100501
Pirata
100502
mandaragat
Tandaan nating muli iyon
1. Ang aming mga mandaragat ay talagang ahit na tao
2. Ang ating mga pirata ay talagang may balbas
Anong mga problema sa kasong ito ang kailangang alisin upang ang aming istraktura ay nagsusumikap para sa ikatlong normal na anyo:
- paglabag sa atomicity ng attribute - Kategorya ng Kliyente
- paghahalo ng sinuri na katotohanan at konklusyon sa isang talahanayan
- fixed functional na relasyon sa pagitan ng mga katangian ng iba't ibang entity.
Sa normalized na anyo, makakakuha tayo ng dalawang talahanayan:
- resulta ng pagkilala sa anyo ng isang hanay ng mga itinatag na tampok,
Kinikilalang object ID
buhok sa mukha
100500
Oo
100501
Oo
100502
Hindi
- ang resulta ng pagtukoy sa uri ng kliyente bilang isang aplikasyon ng logic na naka-embed sa IS upang bigyang-kahulugan ang mga naitatag na katangian
Kinikilalang object ID
ID ng pagkakakilanlan
Kategorya ng kliyente
100500
100001
Pirata
100501
100002
Pirata
100502
100003
mandaragat
Paano mapadali ng isang normalized na data storage organization ang pagbuo ng isang IP complex? Sabihin nating bigla kang makakuha ng mga bagong kliyente. Hayaan itong mga pirata ng Hapon na maaaring walang balbas, ngunit naglalakad sila na may parrot sa kanilang balikat, at mga environmentalist na pirata, madali mo silang makikilala sa pamamagitan ng asul na profile ni Greta sa kaliwang dibdib.
Ang mga pirata sa kapaligiran, natural, ay hindi maaaring gumamit ng mga suklay ng buto at humihingi ng analogue na gawa sa recycled sea plastic.
Kailangan mong gawing muli ang mga algorithm ng programa alinsunod sa mga bagong input. Kung sinunod ang mga panuntunan sa normalisasyon, kailangan mo lang dagdagan ang mga input para sa ilang sangay ng proseso sa ilang system at gumawa lang ng mga bagong branch para sa mga kasong iyon at sa mga IS kung saan mahalaga ang buhok sa mukha. Ngunit, dahil hindi sinunod ang mga patakaran, kailangan mong pag-aralan ang buong code, sa buong circuit, kung saan ginagamit ang mga halaga ng direktoryo ng uri ng kliyente at malinaw na itinatag na sa isang kaso ay dapat isaalang-alang ng algorithm ang propesyonal. aktibidad ng kliyente, at sa iba pang pisikal na katangian.
Sa isang anyo na naghahanap upang ma-normalize, makakakuha tayo ng dalawang talahanayan na may data ng pagpapatakbo at dalawang direktoryo:
- resulta ng pagkilala sa anyo ng isang hanay ng mga itinatag na tampok,
Kinikilalang object ID
Greta sa kaliwang dibdib
Ibon sa balikat
buhok sa mukha
100510
1
1
1
100511
0
0
1
100512
1
0
- ang resulta ng pagtukoy sa uri ng kliyente (hayaan itong maging isang pasadyang view kung saan ipinapakita ang mga paglalarawan mula sa mga direktoryo)
Nangangahulugan ba ang natukoy na denormalization na hindi mababago ang mga system upang matugunan ang mga bagong kundisyon? Syempre hindi. Kung akala namin na ang lahat ng mga sistema ng impormasyon ay nilikha ng isang koponan na may zero na paglilipat ng kawani, ang mga pag-unlad ay mahusay na dokumentado at ang impormasyon ay inililipat sa loob ng koponan nang walang pagkawala, kung gayon ang mga kinakailangang pagbabago ay maaaring gawin nang may kaunting pagsisikap. Ngunit kung babalik tayo sa orihinal na mga kondisyon ng problema, 1,5 na keyboard ang mabubura para lamang sa pag-print ng mga protocol ng magkasanib na talakayan at isa pang 0,5 para sa pagproseso ng mga pamamaraan ng pagkuha.
Sa halimbawa sa itaas, lahat ng tatlong normal na anyo ay nilabag, subukan nating labagin ang mga ito nang hiwalay.
Paglabag sa unang normal na anyo:
Sabihin nating ang mga kalakal ay inihahatid sa iyong bodega mula sa mga bodega ng mga supplier sa pamamagitan ng pagkuha gamit ang isang 1.5-toneladang gasela na kabilang sa iyong tavern. Ang laki ng iyong mga order ay napakaliit kumpara sa turnover ng mga supplier na palagi silang nakumpleto nang one-on-one nang hindi naghihintay para sa produksyon. Sa ganitong proseso ng negosyo, kailangan mo ba ng hiwalay na mga talahanayan: mga sasakyan, mga uri ng sasakyan, kailangan bang paghiwalayin ang plano at katotohanan sa iyong mga order sa mga umalis na supplier?
Isipin lamang kung gaano karaming "dagdag" na koneksyon ang kailangang isulat ng iyong mga programmer kung gagamitin mo ang modelo sa ibaba upang bumuo ng isang programa.
Sabihin nating napagpasyahan namin na ang iminungkahing istraktura ay hindi kinakailangang kumplikado; sa aming kaso, ang paghihiwalay sa plano at ang katotohanan sa talaan ng order ay kalabisan na impormasyon, at ang nabuong detalye ng order ay muling isinulat batay sa mga resulta ng pagtanggap ng mga dumating na kalakal, bihirang mis -Ang pagmamarka at pagdating ng mga kalakal na may hindi sapat na kalidad ay inaayos sa labas ng IS.
At pagkatapos ay isang araw makikita mo kung paano ang buong bulwagan ng tavern ay napuno ng mga galit na galit at gusgusin na mga pirata. Anong nangyari?
Lumalabas na habang lumalago ang iyong negosyo, lumaki rin ang iyong pagkonsumo. Noong unang panahon, ang isang desisyon sa pamamahala ay ginawa na kung ang isang gazelle ay na-overload sa dami at/o bigat, na napakabihirang, ang supplier ay uunahin ang pagkarga sa pabor ng mga inumin.
Ang hindi naihatid na mga kalakal ay napunta sa susunod na order at umalis sa isang bagong flight; ang pagkakaroon ng isang minimum na balanse sa bodega sa tavern ay naging posible na hindi mapansin ang mga nawawalang kaso.
Ang huling kakumpitensya ay nagsara sa port, at ang nabutas na kaso ng gazelle overload, na nalampasan ng prioritization batay sa pag-aakala ng sapat na minimum na balanse at pana-panahong underloading ng sasakyan, ay naging karaniwang kasanayan. Ang nilikhang sistema ay perpektong gagana alinsunod sa mga algorithm na naka-embed dito at aalisan ng anumang pagkakataon na subaybayan ang sistematikong pagkabigo upang matupad ang mga nakaplanong order. Tanging isang nasirang reputasyon at hindi nasisiyahang mga customer ang makaka-detect ng problema.
Maaaring napansin ng isang matulungin na mambabasa na ang inorder na dami sa detalye ng order (T_ORDER_SPEC) sa seksyon 2 at seksyon 5 ay maaaring matugunan o hindi ang kinakailangan ng unang normal na anyo. Ang lahat ay nakasalalay sa kung, dahil sa napiling assortment ng mga kalakal, mahalagang iba't ibang mga yunit ng pagsukat ay maaaring mahulog sa parehong larangan.
Paglabag sa pangalawang normal na anyo:
Habang lumalaki ang iyong mga pangangailangan, bibili ka pa ng ilang sasakyan na may iba't ibang laki. Sa konteksto sa itaas, ang paglikha ng isang direktoryo ng sasakyan ay itinuturing na kalabisan; bilang isang resulta, ang lahat ng mga algorithm sa pagproseso ng data na nagsisilbi sa mga pangangailangan ng paghahatid at bodega ay nakikita ang paggalaw ng mga kargamento mula sa supplier patungo sa bodega bilang ang paglipad ng isang eksklusibong 1,5-tonelada. gasela. Kaya, kasama ang pagbili ng mga bagong sasakyan, lumikha ka pa rin ng isang direktoryo ng sasakyan, ngunit kapag tinatapos ito, kakailanganin mong pag-aralan ang lahat ng code na tumutukoy sa paggalaw ng kargamento upang malaman kung sa bawat partikular na lugar ang mga sanggunian ay ipinahiwatig sa mga katangian ng mismong sasakyan kung saan nagsimula ang negosyo.
Paglabag sa ikatlong normal na anyo:
Sa ilang mga punto magsisimula kang lumikha ng isang programa ng katapatan, isang talaan ng isang regular na customer ay lilitaw. Bakit, halimbawa, gumugugol ng oras sa paglikha ng mga materyal na view na nag-iimbak ng pinagsama-samang data sa mga benta sa isang indibidwal na kliyente para magamit sa pag-uulat at paglilipat sa mga sistema ng analytical, kung sa simula ng isang loyalty program lahat ng bagay na interesado sa customer ay mailalagay sa rekord ng kliyente ? At, sa katunayan, sa unang tingin, walang punto. Ngunit sa tuwing kumokonekta ang iyong negosyo, halimbawa, mga bagong channel sa pagbebenta, dapat mayroong isang tao sa iyong mga analyst na makakaalala na may ganoong katangian ng pagsasama-sama.
Kapag nagdidisenyo ng bawat bagong proseso, halimbawa, mga benta sa Internet, mga benta sa pamamagitan ng mga distributor na konektado sa isang karaniwang sistema ng katapatan, dapat isaisip ng isang tao na ang lahat ng mga bagong proseso ay dapat tiyakin ang integridad ng data sa antas ng code. Para sa isang pang-industriyang database na may isang libong mga talahanayan, ito ay tila isang imposibleng gawain.
Ang isang nakaranasang developer, siyempre, ay nakakaalam kung paano ihinto ang lahat ng mga problema na nabanggit sa itaas, ngunit, sa palagay ko, ang gawain ng isang may karanasan na analyst ay hindi upang dalhin ang mga ito sa liwanag.
Nais kong ipahayag ang aking pasasalamat sa nangungunang developer na si Evgeniy Yarukhin para sa kanyang mahalagang puna sa panahon ng paghahanda ng publikasyon.
Panitikan
Connolly Thomas, Begg Caroline. Database. Disenyo, pagpapatupad at suporta. Teorya at kasanayan
Pinagmulan: www.habr.com