Hei! Nimeni on Andrey Semenov, olen Sportmasterin vanhempi analyytikko. Tässä viestissä haluan ottaa esille ERP-järjestelmän tietokantojen denormalisoinnin. Tarkastellaan yleisiä ehtoja sekä konkreettista esimerkkiä - oletetaan, että se olisi upea monopolitaverna merirosvoille ja merimiehille. Missä merirosvoja ja merimiehiä tulee palvella eri tavalla, koska näiden hyvien herrojen käsitykset kauneudesta ja kulutusmalleista ovat huomattavasti erilaisia.
Kuinka tehdä kaikki onnelliseksi? Kuinka voit välttää hulluksi suunnitella ja ylläpitää tällaista järjestelmää? Mitä tehdä, jos tavernaan alkaa tulla tavallisia merirosvoja ja merimiehiä?
Kaikki on alaspäin. Mutta mennään järjestyksessä.
1. Rajoitukset ja oletukset
Kaikki yllä oleva koskee vain relaatiotietokantoja. Denormalisoinnin seurauksia muuntamisen, poiston ja lisäyspoikkeavuuksien muodossa, jotka ovat hyvin käsitelty, myös Internetissä, ei oteta huomioon. Tämän julkaisun ulkopuolella on tapauksia, joissa denormalisointi on yleinen paikka, ja klassisia esimerkkejä: passin sarja ja numero, päivämäärä ja aika jne.
Viesti käyttää intuitiivisia ja käytännöllisesti sovellettavia normaalimuotojen määritelmiä, viittaamatta matemaattisiin termeihin. Siinä muodossa, jossa niitä voidaan soveltaa todellisten liiketoimintaprosessien (BP) tutkimiseen ja teollisten ohjelmistojen suunnitteluun.
Väitetään, että tietovarastojen, raportointityökalujen ja integraatiosopimusten suunnittelu (jotka käyttävät tietojen taulukkomuotoisia esityksiä) eroavat ERP-järjestelmän tietokantojen suunnittelusta siinä mielessä, että käytön helppous ja tietoisen denormalisoinnin käyttö sen saavuttamiseksi voi olla eheyden edelle. suojaustiedot. Olen samaa mieltä, ja alla kuvattu koskee vain ERP-järjestelmien perustietoja ja transaktiotietomalleja.
Normaalimuotojen selitys annetaan useimmille lukijoille arkipäivän tasolla ymmärrettävällä esimerkillä. Kuitenkin visuaalisena esimerkkinä kappaleissa 4-5 tarkoituksellisesti "fiktiivistä" tehtävää käytettiin tarkoituksella. Jos et tee tätä ja otat jonkin oppikirjaesimerkin, esimerkiksi saman tilausvarastomallin kohdasta 2, saatat joutua tilanteeseen, jossa lukijan painopiste siirtyy ehdotetusta prosessin hajotuksesta malliksi, henkilökohtaiseen kokemukseen ja käsitykseen siitä, kuinka prosesseja ja malleja tietojen tallentamiseksi IS:ään on rakennettava. Toisin sanoen otetaan kaksi pätevää IT-analyytikkoa, joista toinen palvelee matkustajia kuljettavia logistiikoita, toinen logistiikoita, jotka kuljettavat koneita mikrosirujen valmistukseen. Pyydä heitä, keskustelematta etukäteen automatisoiduista BP:istä, luomaan tietomalli junamatkan tietojen tallentamiseksi.
On nollasta poikkeavaa todennäköisyyttä, että ehdotetuista malleista löydät paitsi huomattavasti erilaisen attribuuttijoukon, myös erilaisia entiteettijoukkoja, koska jokainen analyytikko luottaa hänelle tuttuihin prosesseihin ja tehtäviin. Ja tällaisessa tilanteessa on mahdotonta sanoa, mikä malli on "oikea", koska arviointikriteeriä ei ole.
2. Normaalit muodot
Tietokannan ensimmäinen normaali muoto vaatii kaikkien ominaisuuksien atomisuuden.
Erityisesti, jos objektilla A on ei-avainattribuutit a ja b, niin että c=f(a,b) ja objektia A kuvaavaan taulukkoon tallennat attribuutin c arvon, niin ensimmäinen normaalimuoto rikotaan tietokannassa. . Esimerkiksi jos tilauserittelyssä on ilmoitettu määrä, jonka mittayksiköt riippuvat tuotteen tyypistä: toisessa tapauksessa se voi olla kappaletta, toisessa litraa, kolmannessa kappaleista koostuvia pakkauksia (yllä olevassa mallissa Good_count_WR) , attribuuttien atomiteetti rikotaan tietokannassa. Tässä tapauksessa, jotta voidaan sanoa mikä tilausmäärittelyn taulukkoklusterin tulisi olla, tarvitaan kohdennettu kuvaus työprosessista IS:ssä ja koska prosessit voivat olla erilaisia, "oikeita" versioita voi olla useita.
Tietokannan toinen normaali muoto edellyttää ensimmäisen lomakkeen ja oman taulukon noudattamista jokaiselta IS:n työprosessiin liittyvältä kokonaisuudelta. Jos yhdessä taulukossa on riippuvuuksia c=f1(a) ja d=f2(b) eikä riippuvuutta c=f3(b), niin toinen normaalimuoto rikotaan taulukossa. Yllä olevassa esimerkissä tilaustaulukon tilauksen ja osoitteen välillä ei ole riippuvuutta. Muuta kadun tai kaupungin nimeä, etkä vaikuta tilauksen olennaisiin ominaisuuksiin.
Kolmas normaalimuotoinen tietokanta edellyttää toisen normaalimuodon noudattamista ja toiminnallisten riippuvuuksien puuttumista eri entiteettien attribuuttien välillä. Tämä sääntö voidaan muotoilla seuraavasti: "Kaikki mikä voidaan laskea, on laskettava." Toisin sanoen, jos on kaksi objektia A ja B. Objektin A attribuutteja tallentavassa taulukossa attribuutti C ilmenee ja objektilla B on attribuutti b, niin että c=f4(b) on olemassa, niin kolmas normaalimuoto on rikottu. Alla olevassa esimerkissä tilaustietueen Quantity of Pieces -määrite (Total_count_WR) väittää selvästi rikkovansa kolmatta normaalimuotoa
3. Minun lähestymistapani normalisoinnin soveltamiseen
1. Vain kohdeautomatisoitu liiketoimintaprosessi voi tarjota analyytikolle kriteerit entiteettien ja attribuuttien tunnistamiseksi tiedontallennusmallia luotaessa. Prosessimallin luominen on edellytys normaalin tietomallin luomiselle.
2. Kolmannen normaalimuodon saavuttaminen suppeassa mielessä ei välttämättä ole käytännöllistä käytännössä ERP-järjestelmien luomisessa, jos jotkin tai kaikki seuraavista ehdoista täyttyvät:
- automatisoidut prosessit muuttuvat harvoin,
- tutkimus- ja kehitystyön määräajat ovat tiukat,
- Tietojen eheysvaatimukset ovat suhteellisen alhaiset (mahdolliset virheet teollisissa ohjelmistoissa eivät johda ohjelmistoasiakkaan rahan tai asiakkaiden menettämiseen)
- jne.
Kuvatuissa olosuhteissa joidenkin esineiden ja niiden ominaisuuksien elinkaaren tunnistamisen ja kuvaamisen kustannukset eivät välttämättä ole taloudellisen tehokkuuden kannalta perusteltuja.
3. Tietomallin denormalisoinnin seurauksia jo luodussa IS:ssä voidaan lieventää koodin perusteellisella esitutkimuksella ja testauksella.
4. Denormalisointi on tapa siirtää työvoimakustannuksia tietolähteiden tutkimuksen ja liiketoimintaprosessin suunnitteluvaiheesta kehitysvaiheeseen, toteutusvaiheesta järjestelmän kehitysvaiheeseen.
5. Tietokannan kolmanteen normaalimuotoon kannattaa pyrkiä, jos:
- Muutoksen suuntaa automatisoiduissa liiketoimintaprosesseissa on vaikea ennustaa
- Toteutus- ja/tai kehitystiimin työnjako on heikko
- Integrointipiiriin kuuluvat järjestelmät kehittyvät omien suunnitelmiensa mukaisesti
- Tietojen epäjohdonmukaisuus voi johtaa siihen, että yritys menettää asiakkaita tai rahaa
6. Tietomallin suunnittelun tulee tehdä analyytikko vain kohdeliiketoimintaprosessin mallien ja IS:n prosessin yhteydessä. Jos kehittäjä suunnittelee tietomallia, hänen on uppouduttava aihealueeseen siinä määrin, että hän ymmärtää erityisesti attribuuttiarvojen välisen eron - välttämätön edellytys atomiattribuuttien eristämiselle. Siten ottaa epätavallisia toimintoja.
4 Havainnollistava ongelma
Oletetaan, että sinulla on pieni robottitaverna satamassa. Markkinasegmenttisi: merimiehet ja merirosvot, jotka tulevat satamaan ja tarvitsevat tauon. Myyt merimiehille teetä timjamilla ja merirosvoille rommia ja luukammat parran kampaukseen. Itse tavernassa palvelevat robottiemäntä ja robottibaarimikko. Korkean laatusi ja alhaisten hintojesi ansiosta olet ajanut kilpailijasi syrjään, niin että kaikki laivalta tulevat tulevat tavernaasi, joka on ainoa satamassa.
Tavernan tietojärjestelmäkompleksi koostuu seuraavista ohjelmistoista:
- Varhaisvaroitusjärjestelmä asiakkaasta, joka tunnistaa luokkansa ominaispiirteiden perusteella
- Ohjausjärjestelmä robottiemännille ja robottibaarimiehille
- Varaston ja toimituksen hallintajärjestelmä myyntipisteeseen
- Toimittajasuhteiden hallintajärjestelmä (SURP)
prosessi:
Varhaisvaroitusjärjestelmä tunnistaa aluksesta lähtevät ihmiset. Jos henkilö on puhtaasti ajeltu, hän tunnistaa hänet merimieheksi; jos henkilöllä havaitaan parta, hänet tunnistetaan merirosvoksi.
Tavernaan astuessaan vieras kuulee luokkansa mukaisen robottiemäntä tervehdyksen, esimerkiksi: "Ho-ho-ho, rakas merirosvo, mene pöytään nro..."
Vieras menee määritettyyn pöytään, jossa robottibaarimikko on jo valmistanut hänelle tavarat kategorian mukaisesti. Robottibaarimikko välittää varastojärjestelmään tiedon, että seuraavaa toimitusosuutta tulisi kasvattaa, varasto IS generoi hallintajärjestelmään ostopyynnön varaston jäljellä olevien saldojen perusteella.
Vaikka varhaisvaroitusjärjestelmän on saattanut kehittää sisäinen IT, baarirobotin hallintaohjelma on saattanut luoda ulkopuolinen urakoitsija erityisesti yrityksellesi. Ja varastojen ja tavarantoimittajien välisten suhteiden hallintajärjestelmät ovat räätälöityjä paketoituja ratkaisuja markkinoilta.
5. Esimerkkejä denormalisoinnista ja sen vaikutuksista ohjelmistokehitykseen
Liiketoimintaprosessia suunniteltaessa haastatellut aiheasiantuntijat totesivat yksimielisesti, että kaikkialla maailmassa merirosvot juovat rommia ja kampaavat partansa luukampoilla ja merimiehet juovat teetä timjamilla ja ovat aina puhtaasti ajeltuja.
Näkyviin tulee asiakastyyppihakemisto kahdella arvolla: 1 - merirosvot, 2 - merimiehet, yhteinen koko yrityksen tietopiirille.
Asiakasilmoitusjärjestelmä tallentaa välittömästi kuvankäsittelyn tuloksen tunnistetun asiakkaan tunnisteeksi (ID) ja sen tyypiksi: merimies tai merirosvo.
Tunnistettu objektin tunnus
Asiakaskategoria
100500
merirosvo
100501
merirosvo
100502
merimies
Huomautetaan vielä kerran
1. Merimiehemme ovat itse asiassa ajeltuja ihmisiä
2. Merirosvomme ovat itse asiassa parrakkaita ihmisiä
Mitä ongelmia tässä tapauksessa on poistettava, jotta rakenteemme pyrkii kolmanteen normaalimuotoon:
- attribuutin atomiteettirikkomus - Asiakasluokka
- sekoittamalla analysoitu tosiasia ja johtopäätös yhteen taulukkoon
- kiinteä toiminnallinen suhde eri entiteettien attribuuttien välillä.
Normalisoidussa muodossa saisimme kaksi taulukkoa:
- tunnistustulos vakiintuneiden ominaisuuksien joukon muodossa,
Tunnistettu objektin tunnus
Parta
100500
Kyllä
100501
Kyllä
100502
Ei
- tulos asiakastyypin määrittämisestä IS:ään upotetun logiikan sovelluksena vakiintuneiden ominaisuuksien tulkitsemiseen
Tunnistettu objektin tunnus
Tunnistustunnus
Asiakaskategoria
100500
100001
merirosvo
100501
100002
merirosvo
100502
100003
merimies
Kuinka normalisoitu tiedontallennusorganisaatio voi helpottaa IP-kompleksin kehittämistä? Oletetaan, että saat yhtäkkiä uusia asiakkaita. Olkoon kyseessä japanilaiset merirosvot, joilla ei ehkä ole partaa, mutta he kävelevät papukaija olkapäällään, ja ympäristöystävälliset merirosvot, jotka tunnistat helposti Gretan sinisestä profiilista vasemmassa rinnassa.
Ympäristömerirosvot eivät luonnollisestikaan voi käyttää luukampoja ja vaativat kierrätetystä merimuovista valmistettua analogia.
Sinun on työstettävä ohjelman algoritmit uusien tulojen mukaisesti. Jos normalisointisääntöjä noudatettaisiin, joutuisi vain täydentämään joidenkin prosessihaarojen syötteitä joissakin järjestelmissä ja luomaan uusia haaroja vain niille tapauksille ja niille IS:ille, joissa kasvojen karvat ovat tärkeitä. Mutta koska sääntöjä ei noudatettu, sinun on analysoitava koko koodi koko piirissä, jossa käytetään asiakastyyppihakemiston arvoja, ja osoitettava selvästi, että yhdessä tapauksessa algoritmin tulee ottaa huomioon ammattilainen. asiakkaan aktiivisuus ja muut fyysiset ominaisuudet.
Siinä muodossa etsii normalisoituna, saisimme kaksi taulukkoa toimintatiedoilla ja kaksi hakemistoa:
- tunnistustulos vakiintuneiden ominaisuuksien joukon muodossa,
Tunnistettu objektin tunnus
Greta vasemmassa rinnassa
Lintu olkapäällä
Parta
100510
1
1
1
100511
0
0
1
100512
1
0
- asiakastyypin määrityksen tulos (olkoon se mukautettu näkymä, jossa näytetään kuvaukset hakemistoista)
Tarkoittaako havaittu denormalisaatio, että järjestelmiä ei voida muokata vastaamaan uusia ehtoja? Ei tietenkään. Jos kuvittelemme, että kaikki tietojärjestelmät on luotu yhdeltä tiimiltä ilman vaihtuvuutta, kehitys on dokumentoitu hyvin ja tieto kulkee tiimin sisällä häviöttömästi, niin tarvittavat muutokset voidaan tehdä vähällä vaivalla. Mutta jos palataan ongelman alkuperäisiin olosuhteisiin, 1,5 näppäimistöä tyhjennetään vain yhteisten keskustelujen protokollien tulostamista varten ja toiset 0,5 hankintamenettelyjen käsittelyä varten.
Yllä olevassa esimerkissä kaikkia kolmea normaalimuotoa rikotaan, yritetään rikkoa niitä erikseen.
Ensimmäisen normaalimuodon rikkominen:
Oletetaan, että tavarat toimitetaan varastoosi tavarantoimittajien varastoista noudon kautta yhdellä tavernallesi kuuluvalla 1.5 tonnin gasellilla. Tilaustesi koko on niin pieni suhteessa tavarantoimittajien liikevaihtoon, että ne valmistuvat aina yksitellen ilman tuotantoa. Tarvitsetko tällaisessa liiketoimintaprosessissa erilliset taulukot: ajoneuvot, ajoneuvotyypit, onko lähtevien toimittajien tilauksissa tarpeen erottaa suunnitelma ja tosiasia?
Kuvittele kuinka monta "ylimääräistä" yhteyttä ohjelmoijasi joutuvat kirjoittamaan, jos käytät alla olevaa mallia ohjelman kehittämiseen.
Oletetaan, että päätimme, että ehdotettu rakenne on tarpeettoman monimutkainen, meidän tapauksessamme suunnitelman ja tosiasian erottaminen tilaustietueessa on redundanttia tietoa ja luotu tilausspesifikaatio kirjoitetaan uudelleen saapuneiden tavaroiden vastaanoton tulosten perusteella, harvinainen virhe - Puutteellisen laadun luokittelu ja saapuminen ratkaistaan IS:n ulkopuolella.
Ja sitten eräänä päivänä näet, kuinka koko tavernasali on täynnä suuttuneita ja huolimattomia merirosvoja. Mitä tapahtui?
Osoittautuu, että kun yrityksesi kasvoi, niin myös kulutuksesi kasvoi. Olipa kerran johdon päätös, että jos gaselli on ylikuormitettu tilavuudeltaan ja/tai painoltaan, mikä oli erittäin harvinaista, toimittaja priorisoi kuorman juomien eduksi.
Toimittamatta jääneet tavarat päätyivät seuraavaan tilaukseen ja lähtivät uudelle lennolle, tavernan varastossa oleva vähimmäissaldo mahdollisti puuttuvia laatikoita huomaamatta.
Viimeinen kilpailija sulkeutui satamassa, ja puhjennut gasellin ylikuormitus, joka ohitettiin priorisoinnilla, joka perustui oletukseen ajoneuvon vähimmäistasapainon ja säännöllisen alikuormituksen riittävyydestä, tuli yleiseksi käytännöksi. Luotu järjestelmä toimii ihanteellisesti siihen upotettujen algoritmien mukaisesti, ja siltä viedään kaikki mahdollisuudet seurata suunniteltujen tilausten systemaattista epäonnistumista. Vain vahingoittunut maine ja tyytymättömät asiakkaat voivat havaita ongelman.
Huomaavainen lukija on saattanut huomata, että tilauserittelyssä (T_ORDER_SPEC) osiossa 2 ja 5 oleva tilattu määrä saattaa täyttää tai ei välttämättä täyttää ensimmäisen normaalimuodon vaatimusta. Kaikki riippuu siitä, voivatko valitun tavaralajin perusteella olla samaan kenttään olennaisesti erilaisia mittayksiköitä.
Toisen normaalimuodon rikkominen:
Tarpeesi kasvaessa ostat pari erikokoista ajoneuvoa lisää. Yllä olevassa yhteydessä ajoneuvohakemiston luomista pidettiin tarpeettomana, minkä seurauksena kaikki toimituksen ja varaston tarpeita palvelevat tietojenkäsittelyalgoritmit näkevät lastin liikkumisen toimittajalta varastoon yksinomaan 1,5 tonnin lentona. gaselli. Joten uusien ajoneuvojen oston yhteydessä luot silti ajoneuvohakemiston, mutta viimeistellessään sitä joudut analysoimaan kaikki koodit, jotka viittaavat lastin liikkeeseen selvittääksesi, onko kussakin tietyssä paikassa viittauksia ominaisuuksiin juuri siitä ajoneuvosta, josta liiketoiminta alkoi.
Kolmannen normaalimuodon rikkominen:
Jossain vaiheessa kun aloitat kanta-asiakasohjelman luomisen, näkyviin tulee kanta-asiakkaan tietue. Miksi esimerkiksi viettää aikaa materiaalinäkymien luomiseen, jotka tallentavat koottuja tietoja yksittäiselle asiakkaalle tapahtuneesta myynnistä raportoinnissa käytettäväksi ja siirrettäväksi analyyttisiin järjestelmiin, jos kanta-asiakasohjelman alkaessa kaikki asiakasta kiinnostava voidaan tallentaa asiakkaan tietoihin. ? Ja todellakin ensi silmäyksellä siinä ei ole mitään järkeä. Mutta joka kerta, kun yrityksesi yhdistää esimerkiksi uusia myyntikanavia, analyytikoiden joukossa pitäisi olla joku, joka muistaa, että tällainen aggregointiattribuutti on olemassa.
Jokaista uutta prosessia suunniteltaessa, esimerkiksi myyntiä Internetissä, myyntiä yhteiseen kanta-asiakasjärjestelmään liitettyjen jakelijoiden kautta, tulee jonkun pitää mielessä, että kaikkien uusien prosessien tulee varmistaa tietojen eheys kooditasolla. Teolliselle tietokannalle, jossa on tuhat taulukkoa, tämä näyttää mahdottomalta tehtävältä.
Kokenut kehittäjä tietysti osaa lopettaa kaikki edellä mainitut ongelmat, mutta mielestäni kokeneen analyytikon tehtävä ei ole tuoda niitä esiin.
Haluan ilmaista kiitokseni johtavalle kehittäjälle Evgeniy Yarukhinille arvokkaasta palautteesta julkaisun valmistelun aikana.
Kirjallisuus
Connolly Thomas, Begg Caroline. Tietokanta. Suunnittelu, toteutus ja tuki. Teoria ja käytäntö
Lähde: will.com