Saluton! Mi nomiĝas Andrey Semenov, mi estas altranga analizisto ĉe Sportmaster. En ĉi tiu afiŝo mi volas levi la temon de malnormaligo de ERP-sistemaj datumbazoj. Ni rigardos ĝeneralajn kondiĉojn, kaj ankaŭ specifan ekzemplon - ni diru, ke ĝi estus mirinda monopola taverno por piratoj kaj maristoj. En kiu piratoj kaj maristoj devas esti servitaj malsame, ĉar la ideoj pri beleco kaj konsumantaj ŝablonoj de ĉi tiuj bonaj sinjoroj estas signife malsamaj.
Kiel feliĉigi ĉiujn? Kiel vi povas eviti freneziĝi projektante kaj konservi tian sistemon? Kion fari, se ne nur la kutimaj piratoj kaj maristoj komencas veni al la taverno?
Ĉio estas sub la tranĉo. Sed ni iru en ordo.
1. Limoj kaj supozoj
Ĉio ĉi-supra validas nur por interrilataj datumbazoj. La konsekvencoj de malnormaligo en formo de modifo, forigo kaj enmeta anomalioj, kiuj estas bone kovritaj, inkluzive de interreto, ne estas konsiderataj. Ekster la amplekso de ĉi tiu publikigo ekzistas kazoj kie malnormaligo estas ofta loko, kun klasikaj ekzemploj: pasporta serio kaj nombro, dato kaj horo, ktp.
La afiŝo uzas intuiciajn kaj praktike aplikeblajn difinojn de normalaj formoj, sen referenco al matematikaj terminoj. En la formo en kiu ili povas esti aplikitaj al la ekzameno de realaj komercaj procezoj (BP) kaj la dezajno de industria programaro.
Estas argumentite ke la dezajno de datumstokejoj, raportaj iloj kaj integriĝinterkonsentoj (kiuj uzas tabelajn reprezentadojn de informoj) devias de la dezajno de ERP-sistemdatumbazoj en tiu facileco de konsumo kaj la uzo de konscia malnormaligo por atingi ĝin povas preni prioritaton super integreco. protekto datumoj. Mi dividas ĉi tiun opinion, kaj kio estas priskribita sube validas nur por la majstraj datumoj kaj transakciaj datummodeloj de ERP-sistemoj.
Klarigo de normalaj formoj estas donita uzante ekzemplon kiu estas komprenebla je la ĉiutaga nivelo por la plej multaj legantoj. Tamen, kiel vida ilustraĵo, en paragrafoj 4-5, intence "fikcia" tasko estis intence uzita. Se vi ne faras tion kaj prenas iun lernolibron ekzemplon, ekzemple, la sama ordo-stoka modelo de punkto 2, vi eble trovos vin en situacio kie la fokuso de la leganto estos ŝanĝita de la proponita putriĝo de la procezo en modelon, al persona sperto kaj percepto de kiel procezoj kaj modeloj por stoki datumojn en IS devas esti konstruitaj. Alivorte, prenu du kvalifikitajn IT-analizistojn, lasu unu provizi servojn al loĝististoj transportantaj pasaĝerojn, la alia al loĝististoj transportantaj maŝinojn por la produktado de mikroĉipoj. Petu ilin, sen diskuti aŭtomatigitajn BP-ojn anticipe, krei datummodelon por stoki informojn pri fervoja vojaĝo.
Estas ne-nula probablo, ke en la proponitaj modeloj vi trovos ne nur rimarkinde malsaman aron de atributoj, sed ankaŭ diverĝajn arojn de estaĵoj, ĉar ĉiu analizisto fidos al la procezoj kaj taskoj konataj al li. Kaj en tia situacio estas neeble diri, kiu modelo estas "ĝusta", ĉar ne ekzistas taksa kriterio.
2. Normalaj formoj
Unua normala formo de la datumbazo postulas atomecon de ĉiuj atributoj.
Aparte, se objekto A havas ne-ŝlosilajn atributojn a kaj b, tia ke c=f(a,b) kaj en la tabelo priskribanta objekton A vi stokas la valoron de atributo c, tiam la unua normala formo estas malobservita en la datumbazo. . Ekzemple, se la mendospecifo indikas kvanton, kies mezurunuoj dependas de la speco de produkto: en unu kazo ĝi povas esti pecoj, en alia litroj, en tria pakoj konsistantaj el pecoj (en la modelo supre Good_count_WR) , tiam la atomeco de atributoj estas malobservita en la datumbazo. En ĉi tiu kazo, por diri kia devus esti la tabelgrupo de la ordospecifo, vi bezonas celitan priskribon de la laborprocezo en la IS, kaj ĉar la procezoj povas esti malsamaj, povas esti multaj "ĝustaj" versioj.
Dua normala formo de la datumbazo postulas plenumon de la unua formo kaj de sia propra tabelo por ĉiu ento rilata al la laborprocezo en la IS. Se en unu tabelo estas dependecoj c=f1(a) kaj d=f2(b) kaj ne ekzistas dependeco c=f3(b), tiam la dua normala formo estas malobservita en la tabelo. En la supra ekzemplo, ne ekzistas dependeco inter ordo kaj adreso en la Ordotabelo. Ŝanĝu la straton aŭ urbonomon kaj vi ne efikos al la esencaj atributoj de la ordo.
Tria normalforma datumbazo postulas observon kun dua normala formo kaj la foreston de funkciaj dependecoj inter atributoj de malsamaj unuoj. Ĉi tiu regulo povas esti formulita jene: "ĉio kalkulebla devas esti kalkulita." Alivorte, se estas du objektoj A kaj B. En la tabelo konservanta la atributojn de objekto A, atributo C manifestiĝas, kaj objekto B havas atributon b, tia ke c=f4(b) ekzistas, tiam la tria normala formo. estas malobservita. En la malsupra ekzemplo, la atributo Kvanto da Pecoj (Total_count_WR) en la mendo-rekordo klare asertas malobservi trian normalan formon
3. Mia alproksimiĝo al aplikado de normaligo
1. Nur celo aŭtomatigita komerca procezo povas provizi la analiziston per kriterioj por identigi entojn kaj atributojn dum kreado de datuma stokado-modelo. Krei procezmodelon estas antaŭkondiĉo por krei normalan datummodelon.
2. Atingi trian normalan formon en strikta signifo eble ne estas praktika en efektiva praktiko krei ERP-sistemojn se iuj aŭ ĉiuj el la sekvaj kondiĉoj estas plenumitaj:
- aŭtomatigitaj procezoj malofte ŝanĝiĝas,
- limdatoj por esplorado kaj evoluo estas streĉaj,
- postuloj por datumintegreco estas relative malaltaj (eblaj eraroj en industria softvaro ne kaŭzas la perdon de mono aŭ klientoj de la softvarkliento)
- ktp
Sub la priskribitaj kondiĉoj, la kostoj de identigado kaj priskribado de la vivociklo de iuj objektoj kaj iliaj atributoj eble ne estas pravigitaj de la vidpunkto de ekonomia efikeco.
3. Ajnaj sekvoj de malnormaligo de la datummodelo en jam kreita IS povas esti mildigitaj per profunda antaŭstudo de la kodo kaj testado.
4. Malnormaligo estas maniero translokigi laborkostojn de la stadio de esplorado de datumfontoj kaj desegnado de komerca procezo al la disvolva etapo, de la efektiviga periodo ĝis la periodo de sistema evoluo.
5. Estas konsilinde strebi al la tria normala formo de datumbazo se:
- La direkto de ŝanĝo en aŭtomatigitaj komercaj procezoj malfacilas antaŭdiri
- Estas malforta labordivido ene de la efektivigo kaj/aŭ evoluiga teamo
- Sistemoj inkluzivitaj en la integriĝcirkvito evoluas laŭ siaj propraj planoj
- Nekongrueco de datumoj povas rezultigi kompanion perdi klientojn aŭ monon
6. La dezajno de datummodelo devas esti efektivigita de analizisto nur lige kun la modeloj de la cela komerca procezo kaj la procezo en la IS. Se programisto desegnas datummodelon, li devos mergi sin en la temon tiomgrade, ke li precipe komprenas la diferencon inter atributaj valoroj - necesa kondiĉo por izoli atomajn atributojn. Tiel, alprenante nekutimajn funkciojn.
4 Problemo por ilustraĵo
Ni diru, ke vi havas malgrandan robotan tavernon en la haveno. Via merkatsegmento: maristoj kaj piratoj, kiuj venas en havenon kaj bezonas ripozon. Vi vendas teon kun timiano al maristoj, kaj rumon kaj ostajn kombilojn por kombi barbojn al piratoj. La servo en la taverno mem estas disponigita fare de robotgastigantino kaj robotdrinkejisto. Dank' al via altkvalita kaj malaltaj prezoj, vi forpelis viajn konkurantojn, por ke ĉiuj elirantaj de la ŝipo venu al via taverno, kiu estas la sola en la haveno.
La taverna informsistemo-komplekso konsistas el la sekva programaro:
- Frua averta sistemo pri kliento, kiu rekonas sian kategorion surbaze de karakterizaj trajtoj
- Kontrolsistemo por robotaj gastigantoj kaj robotaj trinkejistoj
- Stokejo kaj livera administra sistemo al vendejo
- Sistemo pri Provizanta Rilata Administrado (SURP)
Procezo:
La frua averta sistemo rekonas homojn forlasantajn la ŝipon. Se persono estas pura razita, ŝi identigas lin kiel maristo; se persono estas trovita havi barbon, tiam li estas identigita kiel pirato.
Enirante la tavernon, la gasto aŭdas saluton de la robota gastigantino laŭ lia kategorio, ekzemple: "Ho-ho-ho, kara pirato, iru al tablo No..."
La gasto iras al la specifita tablo, kie la roboto drinkejisto jam preparis varojn por li konforme al la kategorio. La robotdrinkejisto transdonas informojn al la stoksistemo ke la venonta parto de liveraĵo devus esti pliigita; la stokejo ESTAS, surbaze de la ceteraj ekvilibroj en stokado, generas aĉetpeton en la administradsistemo.
Dum la frua averta sistemo eble estis evoluigita de via interna IT, la trinkeja robota administra programo eble estis kreita de ekstera kontraktisto specife por via komerco. Kaj sistemoj por administri magazenojn kaj rilatojn kun provizantoj estas personigitaj pakitaj solvoj de la merkato.
5. Ekzemploj de malnormaligo kaj ĝia efiko al programaro-disvolviĝo
Projektante komercan procezon, la intervjuitaj fakuloj unuanime konstatis, ke en la tuta mondo piratoj trinkas rumon kaj kombas siajn barbojn per ostaj kombiloj, kaj maristoj trinkas teon kun timiano kaj estas ĉiam pure razitaj.
Dosierujo de klienttipoj aperas kun du valoroj: 1 - piratoj, 2 - maristoj, komunaj por la tuta informa cirkvito de la kompanio.
La klienta sciiga sistemo tuj stokas la rezulton de bildprilaborado kiel la identigilo (ID) de la agnoskita kliento kaj ĝia tipo: maristo aŭ pirato.
Rekonita objekto-ID
Kliento kategorio
100500
Pirato
100501
Pirato
100502
Maristo
Ni rimarku denove tion
1. Niaj maristoj estas efektive razitaj homoj
2. Niaj piratoj estas fakte barbuloj
Kiaj problemoj en ĉi tiu kazo devas esti eliminitaj, por ke nia strukturo strebu al la tria normala formo:
- atribua atomeco malobservo - Kliento Kategorio
- miksante la analizitan fakton kaj la konkludon en unu tabelo
- fiksita funkcia rilato inter atributoj de malsamaj estaĵoj.
En normaligita formo, ni ricevus du tabelojn:
- rekonrezulto en la formo de aro de establitaj trajtoj,
Rekonita objekto-ID
Vizaĝa hararo
100500
Jes
100501
Jes
100502
Neniu
- la rezulto de determinado de la speco de kliento kiel apliko de la logiko enigita en la IS por interpreti la establitajn karakterizaĵojn
Rekonita objekto-ID
Identiga ID
Kliento kategorio
100500
100001
Pirato
100501
100002
Pirato
100502
100003
Maristo
Kiel normaligita datumstokado-organizo povas faciligi la evoluon de IP-komplekso? Ni diru, ke vi subite ricevas novajn klientojn. Estu japanaj piratoj, kiuj eble ne havas barbon, sed ili marŝas kun papago sur la ŝultro, kaj ekologiistaj piratoj, vi povas facile rekoni ilin per la blua profilo de Greta ĉe la maldekstra brusto.
Ekologiaj piratoj, nature, ne povas uzi ostajn kombilojn kaj postulas analogon faritan el reciklita mara plasto.
Vi devas reverki la programalgoritmojn konforme al la novaj enigaĵoj. Se la normaligaj reguloj estus sekvitaj, tiam vi nur devus kompletigi la enigaĵojn por iuj procezbranĉoj en iuj sistemoj kaj krei novajn branĉojn nur por tiuj kazoj kaj en tiuj IS-oj kie vizaĝa hararo gravas. Sed, ĉar la reguloj ne estis sekvitaj, vi devos analizi la tutan kodon tra la tuta cirkvito, kie la valoroj de la klienttipa dosierujo estas uzataj kaj klare konstati, ke en unu kazo la algoritmo devas konsideri la profesian. aktiveco de la kliento, kaj en la aliaj fizikaj trajtoj.
En formo kiu serĉas normaligite, ni ricevus du tabelojn kun operaciaj datumoj kaj du dosierujoj:
- rekonrezulto en la formo de aro de establitaj trajtoj,
Rekonita objekto-ID
Greta sur maldekstra brusto
Birdo sur la ŝultro
Vizaĝa hararo
100510
1
1
1
100511
0
0
1
100512
1
0
- la rezulto de determini la klientspecon (estu laŭmenda vido en kiu priskriboj de dosierujoj estas montrataj)
Ĉu la detektita malnormaligo signifas, ke la sistemoj ne povas esti modifitaj por renkonti novajn kondiĉojn? Kompreneble ne. Se ni imagas, ke ĉiuj informsistemoj estis kreitaj de unu teamo kun nula dungitaro, la evoluoj estas bone dokumentitaj kaj informoj estas transdonitaj ene de la teamo sen perdo, tiam la postulataj ŝanĝoj povas esti faritaj kun neglekte malmulta peno. Sed se ni revenos al la originalaj kondiĉoj de la problemo, 1,5 klavaroj estos forviŝitaj nur por presado de protokoloj de komunaj diskutoj kaj aliaj 0,5 por prilaborado de akirproceduroj.
En la supra ekzemplo, ĉiuj tri normalaj formoj estas malobservitaj, ni provu malobservi ilin aparte.
Malobservo de unua normala formo:
Ni diru, ke varoj estas liveritaj al via magazeno de provizantoj de provizantoj per reprenado per unu 1.5-tuna gazelo kiu apartenas al via taverno. La grandeco de viaj mendoj estas tiel malgranda rilate al la spezo de la provizantoj, ke ili ĉiam estas kompletigitaj unu-kontraŭ-unu sen atendi produktadon. Kun tia komerca procezo, ĉu vi bezonas apartajn tablojn: veturiloj, specoj de veturiloj, ĉu necesas apartigi planon kaj fakton en viaj mendoj al foririntaj provizantoj?
Nur imagu kiom da "krom" konektoj viaj programistoj devos skribi se vi uzas la modelon sube por disvolvi programon.
Ni diru, ke ni decidis, ke la proponita strukturo estas nenecese kompleksa; en nia kazo, apartigi la planon kaj la fakton en la ordo-registro estas redunda informo, kaj la generita ordospecifo estas reverkita surbaze de la rezultoj de akcepto de la alvenintaj varoj, malofta miso. -gradado kaj alveno de varoj de neadekvata kvalito estas aranĝitaj ekster la IS.
Kaj tiam iun tagon vi vidas, kiel la tuta tavernejo pleniĝas de indignaj kaj neprizorgitaj piratoj. Kio okazis?
Rezultas, ke dum via komerco kreskis, ankaŭ via konsumado. Iam, administraddecido estis farita ke se gazelo estus troŝarĝita en volumeno kaj/aŭ pezo, kio estis ekstreme malofta, la provizanto prioritatus la ŝarĝon en favoro de trinkaĵoj.
La neliveritaj varoj finiĝis en la sekva ordo kaj foriris al nova flugo; la ĉeesto de minimuma saldo en la magazeno ĉe la taverno ebligis ne rimarki mankantajn kazojn.
La lasta konkuranto fermiĝis ĉe la haveno, kaj la trapikita kazo de gazela troŝarĝo, preteririta per prioritato bazita sur la supozo de la sufiĉo de la minimuma ekvilibro kaj perioda subŝarĝo de la veturilo, iĝis ofta praktiko. La kreita sistemo ideale funkcios laŭ la algoritmoj enigitaj en ĝi kaj estos senigita de ajna ŝanco spuri la sisteman malsukceson plenumi planitajn ordonojn. Nur difektita reputacio kaj malkontentaj klientoj povos detekti la problemon.
Atenta leganto eble rimarkis, ke la ordigita kvanto en la ordospecifo (T_ORDER_SPEC) en sekcio 2 kaj sekcio 5 povas aŭ eble ne renkonti la postulon de unua normala formo. Ĉio dependas de ĉu, konsiderante la elektitan sortimenton de varoj, esence malsamaj mezurunuoj povas fali en la saman kampon.
Malobservo de dua normala formo:
Dum viaj bezonoj kreskas, vi aĉetas kelkajn pliajn veturilojn de malsamaj grandecoj. En ĉi-supra kunteksto, la kreado de veturila dosierujo estis konsiderata superflua; kiel rezulto, ĉiuj datumtraktadalgoritmoj servantaj la bezonojn de liveraĵo kaj stokejo perceptas la movadon de kargo de la provizanto al la stokejo kiel la flugo de ekskluzive 1,5-tuna. gazelo. Do, kune kun la aĉeto de novaj veturiloj, vi ankoraŭ kreas veturilo-dosierujon, sed kiam vi finpretigos ĝin, vi devos analizi la tutan kodon, kiu referencas al la movado de ŝarĝo, por ekscii ĉu en ĉiu specifa loko referencoj estas implicitaj al la karakterizaĵoj. de la veturilo mem de kiu komerco komenciĝis.
Malobservo de la tria normala formo:
En iu momento vi komencas krei lojalecan programon, aperas registro de kutima kliento. Kial, ekzemple, pasigi tempon kreante materialajn vidojn, kiuj stokas agregitajn datumojn pri vendo al individua kliento por uzo en raportado kaj translokigo al analizaj sistemoj, se ĉe la komenco de lojaleca programo ĉio, kio interesas la kliento, povas esti metita en la rekordon de la kliento. ? Kaj, efektive, unuavide, ne utilas. Sed ĉiufoje kiam via komerco ligas, ekzemple, novajn vendajn kanalojn, devus esti iu inter viaj analizistoj, kiu memoros, ke tia agregacia atributo ekzistas.
Kiam vi desegnas ĉiun novan procezon, ekzemple, vendon en la Interreto, vendon per distribuistoj konektitaj al komuna lojaleca sistemo, iu devas memori, ke ĉiuj novaj procezoj devas certigi datuman integrecon ĉe la koda nivelo. Por industria datumbazo kun mil tabeloj, ĉi tio ŝajnas neebla tasko.
Sperta programisto, kompreneble, scias kiel ĉesigi ĉiujn problemojn menciitajn supre, sed, laŭ mi, la tasko de sperta analizisto ne estas elmeti ilin al la lumo.
Mi ŝatus esprimi mian dankemon al la ĉefa programisto Evgeniy Yarukhin pro liaj valoraj rimarkoj dum la preparado de la publikigo.
Literaturo
Connolly Thomas, Begg Caroline. Datumbazo. Dezajno, efektivigo kaj subteno. Teorio kaj praktiko
fonto: www.habr.com