1. Alkutiedot
Tietojen puhdistaminen on yksi tiedon analysointitehtävien haasteista. Tämä materiaali heijasti kehitystä ja ratkaisuja, jotka syntyivät kiinteistöarvon muodostuksen tietokannan analysoinnin käytännön ongelman ratkaisemisen seurauksena. Lähteet täältä .
Tarkasteltiin tiedostoa ”Vertailumalli total.ods” kohdassa ”Liite B. KS:n määrittämisen tulokset 5. Tietoja kiinteistöarvon määritysmenetelmästä 5.1 Vertaileva lähestymistapa”.
Taulukko 1. Aineiston tilastolliset indikaattorit tiedostossa “Comparative model total.ods”
Kenttien kokonaismäärä, kpl. – 44
Tietueiden kokonaismäärä, kpl. — 365 490
Merkkien kokonaismäärä, kpl. — 101 714 693
Keskimääräinen merkkien määrä tietueessa, kpl. — 278,297 XNUMX
Tietueen merkkien keskihajonta, kpl. — 15,510
Merkkien vähimmäismäärä merkinnässä, kpl. – 198
Merkkien enimmäismäärä merkinnässä, kpl. – 363
2. Johdanto. Perusstandardit
Määritettyä tietokantaa analysoitaessa muodostettiin tehtävä täsmentää puhdistusasteen vaatimukset, koska, kuten kaikille on selvää, määritetty tietokanta aiheuttaa käyttäjille oikeudellisia ja taloudellisia seurauksia. Työn aikana kävi ilmi, että big datan puhdistusasteelle ei ollut erityisiä vaatimuksia. Analysoidessani tämän asian oikeudellisia normeja tulin siihen tulokseen, että ne kaikki muodostuvat mahdollisuuksista. Eli tietty tehtävä on ilmestynyt, tehtävää varten kootaan tietolähteet, sitten muodostetaan tietojoukko ja luodun tietojoukon perusteella työkalut ongelman ratkaisemiseen. Tuloksena olevat ratkaisut ovat vertailukohtia valittaessa vaihtoehtoja. Esitin tämän kuvassa 1.
Koska mahdollisten standardien määrittelyssä on parempi luottaa hyväksi havaittuihin teknologioihin, valitsin kohdassa esitetyt vaatimukset. , koska pidin tätä asiakirjaa kattavimpana tässä numerossa. Erityisesti tässä asiakirjassa osiossa sanotaan "On huomattava, että tietojen eheysvaatimukset koskevat yhtä lailla manuaalista (paperista) että sähköistä dataa." (käännös: "...tietojen eheysvaatimukset koskevat yhtä lailla manuaalisia (paperi-) että sähköisiä tietoja". Tämä sanamuoto liittyy aivan erityisesti käsitteeseen "kirjallinen todiste" siviiliprosessilain 71 §:n säännöksissä. 70 CAS, Art. 75 APC, "kirjallisesti" Art. 84 Siviiliprosessilaki.
Kuva 2 esittää kaavion lähestymistapojen muodostumisesta oikeustieteen tietotyyppeihin.
Riisi. 2. Lähde .
Kuva 3 esittää kuvan 1 mekanismia yllä olevan "Ohjauksen" tehtäviin. Vertailun avulla on helppo todeta, että nykyaikaisten tietojärjestelmien standardien tiedon eheysvaatimusten täyttämisessä käytetyt lähestymistavat ovat merkittävästi rajallisia verrattuna oikeudelliseen tiedon käsitteeseen.
Kuva 3
Määritellyssä asiakirjassa (Ohjeissa) yhteys tekniseen osaan, tietojen käsittely- ja tallennusmahdollisuudet vahvistetaan hyvin lainauksella luvusta 18.2. Relaatiotietokanta: "Tämä tiedostorakenne on luonnostaan turvallisempi, koska tiedot säilytetään suuressa tiedostomuodossa, joka säilyttää tietojen ja metatietojen välisen suhteen."
Itse asiassa tässä lähestymistavassa - olemassa olevista teknisistä ominaisuuksista - ei ole mitään epänormaalia, ja sinänsä tämä on luonnollinen prosessi, koska käsitteiden laajentaminen tulee tutkituimmasta toiminnasta - tietokannan suunnittelusta. Mutta toisaalta, esiintyy oikeudellisia normeja, jotka eivät sisällä alennuksia olemassa olevien järjestelmien teknisistä ominaisuuksista, esimerkiksi: .
Riisi. 4. Teknisten valmiuksien suppilo ().
Näissä näkökohdissa käy selväksi, että alkuperäinen tietojoukko (kuva 1) on ensinnäkin tallennettava, ja toiseksi sen on oltava perusta lisätietojen poimimiselle siitä. No esimerkkinä: liikennesääntöjä tallentavat kamerat ovat läsnä kaikkialla, tiedonkäsittelyjärjestelmät karsivat rikkojia, mutta muuta tietoa voidaan tarjota myös muille kuluttajille, esimerkiksi markkinointiseurantana kauppakeskuksen asiakasvirtojen rakenteesta. Ja tämä on lisäarvon lähde BigDatia käytettäessä. On täysin mahdollista, että nyt, jossain tulevaisuudessa kerättävät aineistot ovat arvoltaan samanlaisia kuin harvinaisten 1700 painosten nykyinen arvo. Itse asiassa väliaikaiset tietojoukot ovat ainutlaatuisia, eikä niitä todennäköisesti toisteta tulevaisuudessa.
3. Johdanto. Arviointikriteeri
Käsittelyprosessin aikana kehitettiin seuraava virheluokitus.
1. Virheluokka (GOST R 8.736-2011:n perusteella): a) systemaattiset virheet; b) satunnaiset virheet; c) virhe.
2. Moninkertaisuudella: a) monosärö; b) monisärö.
3. Seurausten kriittisyyden mukaan: a) kriittinen; b) ei kriittinen.
4. Esiintymislähteen mukaan:
A) Tekniset – virheet, jotka tapahtuvat laitteen käytön aikana. Melko relevantti virhe IoT-järjestelmille, järjestelmille, jotka vaikuttavat merkittävästi viestinnän laatuun, laitteistoihin (laitteistoihin).
B) Operaattorivirheet - virheet laajalla alueella käyttäjän kirjoitusvirheistä syötteen aikana virheisiin tietokannan suunnittelun teknisissä eritelmissä.
C) Käyttäjän virheet - tässä on käyttäjävirheitä koko alueella "unohdin vaihtaa asettelua" mittarien sekoittamiseen jalkoihin.
5. Erotettu erilliseen luokkaan:
a) "erottimen tehtävä", eli välilyönti ja ":" (meidän tapauksessamme), kun se kopioitiin;
b) yhteen kirjoitetut sanat;
c) ei välilyöntiä palvelumerkkien jälkeen
d) symmetrisesti useita symboleja: (), "", "...".
Yhdessä kuvassa 5 esitetyn tietokantavirheiden systematisoinnin kanssa muodostuu varsin tehokas koordinaattijärjestelmä virheiden etsimiseen ja tiedonpuhdistusalgoritmin kehittämiseen tätä esimerkkiä varten.
Riisi. 5. Tyypilliset tietokannan rakenneyksiköitä vastaavat virheet (Lähde: ).
Tarkkuus, verkkotunnuksen eheys, tietotyyppi, johdonmukaisuus, redundanssi, täydellisyys, päällekkäisyys, liiketoimintasääntöjen noudattaminen, rakenteellinen määrittely, tietojen poikkeavuus, selkeys, oikea-aikaisuus, tietojen eheyssääntöjen noudattaminen. (Sivu 334. Tietovarastoinnin perusteet IT-ammattilaisille / Paulraj Ponniah – 2. painos)
Esitetty englanninkielinen sanamuoto ja venäjänkielinen konekäännös suluissa.
Tarkkuus. Tietoelementille järjestelmään tallennettu arvo on oikea arvo kyseiselle tietoelementin esiintymiselle. Jos sinulla on asiakkaan nimi ja osoite tallennettuna tietueeseen, osoite on oikea osoite kyseiselle asiakkaalle. Jos löydät tilatun määrän 1000 yksikkönä tilausnumeron 12345678 tietueesta, tämä määrä on oikea määrä kyseiselle tilaukselle.
[Tarkkuus. Tietoelementille järjestelmään tallennettu arvo on oikea arvo kyseiselle tietoelementin esiintymiselle. Jos sinulla on asiakkaan nimi ja osoite tallennettuna tietueeseen, osoite on oikea osoite kyseiselle asiakkaalle. Jos löydät tilatun määrän 1000 yksikkönä tilausnumeron 12345678 tietueesta, tämä määrä on tilauksen tarkka määrä.]
Verkkotunnuksen eheys. Attribuutin data-arvo on sallittujen, määriteltyjen arvojen alueella. Yleinen esimerkki on sukupuolitietoelementin sallitut arvot "mies" ja "nais".
[Domainin eheys. Attribuuttitietojen arvo on kelvollisten, määriteltyjen arvojen alueella. Yleinen esimerkki ovat kelvolliset arvot "male" ja "female" sukupuolitietoelementille.]
Tietotyyppi. Data-attribuutin arvo tallennetaan itse asiassa kyseiselle attribuutille määritettynä tietotyyppinä. Kun myymälän nimikentän tietotyypiksi on määritetty "teksti", kaikki kentän esiintymät sisältävät kaupan nimen tekstimuodossa, ei numerokoodeja.
[Tietotyyppi. Data-attribuutin arvo tallennetaan itse asiassa kyseiselle attribuutille määritettynä tietotyyppinä. Jos kaupan nimikentän tietotyypiksi on määritetty "teksti", kaikki tämän kentän esiintymät sisältävät kaupan nimen, joka näytetään tekstimuodossa numerokoodien sijaan.]
Johdonmukaisuus. Tietokentän muoto ja sisältö ovat samat useissa lähdejärjestelmissä. Jos tuotteen ABC tuotekoodi yhdessä järjestelmässä on 1234, tämän tuotteen koodi on 1234 jokaisessa lähdejärjestelmässä.
[Johdonmukaisuus. Tietokentän muoto ja sisältö ovat samat eri lähdejärjestelmissä. Jos tuotteen ABC tuotekoodi yhdessä järjestelmässä on 1234, kyseisen tuotteen koodi on 1234 jokaisessa lähdejärjestelmässä.]
Redundanssi. Samoja tietoja ei saa tallentaa useampaan kuin yhteen paikkaan järjestelmässä. Jos tietoelementti on tehokkuussyistä tallennettu tarkoituksella useampaan kuin yhteen paikkaan järjestelmässä, redundanssi on tunnistettava selvästi ja todennettava.
[Redundanssi. Samoja tietoja ei saa tallentaa useampaan kuin yhteen paikkaan järjestelmässä. Jos tietoelementti on tehokkuussyistä tallennettu tarkoituksella useisiin paikkoihin järjestelmässä, redundanssi on määriteltävä ja tarkistettava selvästi.]
Täydellisyys. Järjestelmässä ei ole puuttuvia arvoja tietylle määritteelle. Esimerkiksi asiakastiedostossa jokaisen asiakkaan tila-kentässä on oltava kelvollinen arvo. Tilaustietojen tiedostossa jokainen tilauksen tietotietue on täytettävä kokonaan.
[Täydellisyys. Järjestelmästä ei ole puuttuvia arvoja tälle määritteelle. Esimerkiksi asiakastiedostossa on oltava kelvollinen arvo "status"-kentässä jokaiselle asiakkaalle. Tilaustietotiedostossa jokainen tilaustietotietue on täytettävä kokonaan.]
Monistaminen. Tietueiden päällekkäisyys järjestelmässä on täysin ratkaistu. Jos tuotetiedostossa tiedetään olevan päällekkäisiä tietueita, jokaisen tuotteen kaikki tietueiden kaksoiskappaleet tunnistetaan ja luodaan ristiviittaus.
[Kaksoiskappale. Päällekkäiset tietueet järjestelmässä on eliminoitu kokonaan. Jos tuotetiedoston tiedetään sisältävän päällekkäisiä merkintöjä, jokaisen tuotteen kaikki kaksoismerkinnät tunnistetaan ja luodaan ristiviittaus.]
Liiketoimintasääntöjen noudattaminen. Kunkin tietokohteen arvot noudattavat määrättyjä liiketoimintasääntöjä. Huutokauppajärjestelmässä vasara- tai myyntihinta ei voi olla pienempi kuin pohjahinta. Pankkilainajärjestelmässä lainasaldon tulee aina olla positiivinen tai nolla.
[Yrityssääntöjen noudattaminen. Kunkin tietoelementin arvot noudattavat vakiintuneita liiketoimintasääntöjä. Huutokauppajärjestelmässä vasara- tai myyntihinta ei voi olla pienempi kuin pohjahinta. Pankkiluottojärjestelmässä lainasaldon tulee aina olla positiivinen tai nolla.]
Rakenteellinen määrätietoisuus. Aina kun tietoyksikkö voidaan luonnollisesti jäsentää yksittäisiksi komponenteiksi, alkion tulee sisältää tämä hyvin määritelty rakenne. Esimerkiksi henkilön nimi jakaantuu luonnollisesti etunimeen, keskimmäiseen alkukirjaimeen ja sukunimeen. Henkilöiden nimien arvot on tallennettava etunimenä, keskimmäisenä alkukirjaimena ja sukunimenä. Tämä tietojen laadun ominaisuus yksinkertaistaa standardien täytäntöönpanoa ja vähentää puuttuvia arvoja.
[Rakennevarmuus. Jos tietoelementti voidaan luonnollisesti jäsentää yksittäisiksi komponenteiksi, elementin tulee sisältää tämä hyvin määritelty rakenne. Esimerkiksi henkilön nimi on luonnollisesti jaettu etunimeen, keskimmäiseen alkukirjaimeen ja sukunimeen. Yksittäisten nimien arvot tulee tallentaa etunimenä, keskimmäisenä alkukirjaimena ja sukunimenä. Tämä tietojen laatuominaisuus yksinkertaistaa standardien soveltamista ja vähentää puuttuvia arvoja.]
Data Anomalia. Kenttää saa käyttää vain siihen tarkoitukseen, jota varten se on määritelty. Jos kenttä Osoite-3 on määritetty jollekin mahdolliselle kolmannelle osoiteriville pitkille osoitteille, tätä kenttää tulee käyttää vain kolmannen osoiterivin tallentamiseen. Sitä ei saa käyttää asiakkaan puhelinnumeron tai faksinumeron syöttämiseen.
[Tietojen poikkeama. Kenttää saa käyttää vain siihen tarkoitukseen, jota varten se on määritelty. Jos Address-3-kenttä on määritetty jollekin mahdolliselle kolmannelle osoiteriville pitkille osoitteille, tätä kenttää käytetään vain kolmannen osoiterivin tallentamiseen. Sitä ei saa käyttää asiakkaan puhelinnumeron tai faksinumeron syöttämiseen.]
Selkeys. Tietoelementillä voi olla kaikki muut laatutiedon ominaisuudet, mutta jos käyttäjät eivät ymmärrä sen merkitystä selvästi, tietoelementillä ei ole käyttäjille mitään arvoa. Oikeat nimeämiskäytännöt auttavat tekemään tietoelementeistä hyvin ymmärrettäviä käyttäjille.
[Selkeys. Tietoelementillä voi olla kaikki muut hyvän datan ominaisuudet, mutta jos käyttäjät eivät selvästi ymmärrä sen merkitystä, tietoelementillä ei ole käyttäjille mitään arvoa. Oikeat nimeämiskäytännöt auttavat tekemään tietoelementeistä hyvin ymmärrettäviä käyttäjille.]
ajankohtaista. Käyttäjät päättävät tietojen oikea-aikaisuuden. Jos käyttäjät odottavat, että asiakasdimensioiden tiedot eivät ole yhtä päivää vanhempia, lähdejärjestelmien asiakastietojen muutokset tulee ottaa tietovarastoon päivittäin.
[Ajallaan. Käyttäjät päättävät tietojen ajantasaisuuden. Jos käyttäjät odottavat asiakasulottuvuustietojen olevan korkeintaan yhden päivän ikäisiä, lähdejärjestelmien asiakastietoihin tehtyjä muutoksia tulee soveltaa tietovarastoon päivittäin.]
Hyödyllisyys. Jokaisen tietovaraston tietoelementin on täytettävä joitain käyttäjien keräämisen vaatimuksia. Tietoelementti voi olla tarkka ja laadukas, mutta jos sillä ei ole käyttäjille mitään arvoa, on täysin tarpeetonta, että tietoelementti on tietovarastossa.
[Apuohjelma. Jokaisen tietovaraston tietokohteen on täytettävä joitain käyttäjäkokoelman vaatimuksia. Tietoelementti voi olla tarkka ja laadukas, mutta jos se ei tuota arvoa käyttäjille, sen tietoelementin ei tarvitse olla tietovarastossa.]
Tietojen eheyssääntöjen noudattaminen. Lähdejärjestelmien relaatiotietokantoihin tallennettujen tietojen on noudatettava kokonaisuuden eheys- ja viiteeheyssääntöjä. Millään taulukolla, joka sallii nullin ensisijaisena avaimena, ei ole entiteetin eheyttä. Viittaus eheys pakottaa vanhemman ja lapsen väliset suhteet luomaan oikein. Asiakastilaussuhteessa referenssieheys varmistaa asiakkaan olemassaolon jokaiselle tietokannan tilaukselle.
[Tietojen eheyssääntöjen noudattaminen. Lähdejärjestelmien relaatiotietokantoihin tallennettujen tietojen on oltava kokonaisuuden eheyden ja viiteeheyden sääntöjen mukaisia. Millään taulukolla, joka sallii nollan ensisijaisena avaimena, ei ole entiteetin eheyttä. Referenssieheys pakottaa vanhempien ja lasten välisen suhteen luomaan oikein. Asiakas-tilaussuhteessa viitteellinen eheys varmistaa, että jokaiselle tietokannan tilaukselle on olemassa asiakas.]
4. Tietojen puhdistuksen laatu
Datan puhdistuksen laatu on bigdatassa melko ongelmallinen kysymys. Jokaiselle data-analyytikolle on tärkeää vastata kysymykseen, minkä asteista tietojen puhdistusta tarvitaan tehtävän suorittamiseksi. Useimmissa ajankohtaisissa ongelmissa jokainen analyytikko määrittää tämän itse, ja on epätodennäköistä, että kukaan ulkopuolinen pystyisi arvioimaan tätä näkökohtaa ratkaisussaan. Mutta tässä tapauksessa käsiteltävän tehtävän kannalta tämä kysymys oli erittäin tärkeä, koska oikeudellisten tietojen luotettavuuden pitäisi olla yhtä suuri.
Ohjelmistojen testaustekniikoiden huomioon ottaminen toiminnan luotettavuuden määrittämiseksi. Nykyään on enemmän kuin näitä malleja . Monissa malleissa käytetään korvausvaatimusten käsittelymallia:
Kuva 6
Ajatellaan seuraavasti: "Jos löydetty virhe on samanlainen tapahtuma kuin tämän mallin vikatapahtuma, niin kuinka löytää analogi parametrille t?" Ja laadin seuraavan mallin: Oletetaan, että aika, joka testaajalta kuluu yhden tietueen tarkistamiseen, on 1 minuutti (kyseiselle tietokannalle), sitten kaikkien virheiden löytämiseen hän tarvitsee 365 494 minuuttia, mikä on noin 3 vuotta ja 3 kuukausia työaikaa. Kuten ymmärrämme, tämä on erittäin suuri työmäärä ja tietokannan tarkistamisesta aiheutuvat kustannukset ovat tämän tietokannan kääntäjälle kohtuuttomat. Tässä pohdinnassa näkyy kustannusten taloudellinen käsite ja analyysin jälkeen tulin siihen tulokseen, että tämä on melko tehokas työkalu. Perustuu taloustieteen lakiin: "Tuotantomäärä (yksiköissä), jolla yrityksen suurin voitto saavutetaan, sijaitsee kohdassa, jossa uuden tuotantoyksikön tuotannon rajakustannuksia verrataan hintaan, jonka tämä yritys voi saada. uudelle yksikölle." Perustuen oletukseen, että jokaisen myöhemmän virheen löytäminen vaatii yhä enemmän tietueiden tarkistamista, tämä on kustannustekijä. Eli testausmalleissa omaksuttu postulaatti saa fyysisen merkityksen seuraavassa kaavassa: jos i:nnen virheen löytämiseksi piti tarkistaa n tietuetta, niin seuraavan (i+1) virheen löytämiseksi on välttämätöntä tarkistaa m tietueet ja samalla n
- Kun ennen uuden virheen löytymistä tarkistettujen tietueiden määrä vakiintuu;
- Kun ennen seuraavan virheen löytämistä tarkistettujen tietueiden määrä kasvaa.
Kriittisen arvon määrittämiseksi käännyin taloudellisen toteutettavuuden käsitteeseen, joka tässä tapauksessa sosiaalisten kustannusten käsitettä käyttäen voidaan muotoilla seuraavasti: ”Virheen korjaamisesta aiheutuvat kustannukset tulee maksaa sen talouden toimijan, joka voi tehdä. se halvimmalla hinnalla." Meillä on yksi agentti - testaaja, joka käyttää minuutin yhden tietueen tarkistamiseen. Rahallisesti mitattuna, jos ansaitset 1 6000 ruplaa päivässä, tämä on 12,2 ruplaa. (noin tänään). On vielä määritettävä talousoikeuden tasapainon toinen puoli. Minä perustelin näin. Olemassa oleva virhe edellyttää asianomaisen henkilön, toisin sanoen kiinteistön omistajan, vaivaa sen korjaamiseksi. Oletetaan, että tämä vaatii yhden päivän toimenpiteitä (lähetä hakemus, vastaanota korjattu asiakirja). Silloin hänen kustannukset ovat sosiaaliselta kannalta yhtä suuria kuin keskimääräinen päiväpalkka. Keskimääräinen kertynyt palkka Hanti-Mansin autonomisessa piirikunnassa 73285 hieroa. tai 3053,542 ruplaa/päivä. Vastaavasti saamme kriittisen arvon, joka on yhtä suuri:
3053,542: 12,2 = 250,4 tietueyksikköä.
Tämä tarkoittaa sosiaalisesti, että jos testaaja on tarkistanut 251 tietuetta ja löytänyt yhden virheen, se vastaa sitä, että käyttäjä korjaa tämän virheen itse. Vastaavasti, jos testaaja käytti aikaa, joka vastaa 252 tietueen tarkistamista seuraavan virheen löytämiseksi, tässä tapauksessa on parempi siirtää korjauskustannukset käyttäjälle.
Tässä esitetään yksinkertaistettu lähestymistapa, koska sosiaalisesta näkökulmasta on otettava huomioon kaikki kunkin asiantuntijan tuottama lisäarvo, eli kustannukset, mukaan lukien verot ja sosiaalimaksut, mutta malli on selkeä. Tämän suhteen seurauksena on seuraava vaatimus asiantuntijoille: IT-alan asiantuntijan palkan tulee olla kansallista keskiarvoa suurempi. Jos hänen palkkansa on pienempi kuin mahdollisten tietokannan käyttäjien keskipalkka, hänen on itse tarkastettava koko tietokanta käsin.
Kuvattua kriteeriä käytettäessä muodostuu ensimmäinen tietokannan laatuvaatimus:
I(tr). Kriittisten virheiden osuus ei saa ylittää 1/250,4 = 0,39938 %. Hieman vähemmän kuin kultaa teollisuudessa. Ja fyysisesti tarkasteltuna virheitä sisältäviä tietueita ei ole enempää kuin 1459.
Taloudellinen perääntyminen.
Itse asiassa tekemällä niin monta virhettä tietueissa yhteiskunta suostuu taloudellisiin menetyksiin, joiden määrä on:
1459*3053,542 = 4 455 118 ruplaa.
Tämän määrän määrää se, että yhteiskunnalla ei ole välineitä näiden kustannusten alentamiseksi. Tästä seuraa, että jos jollain on tekniikka, jonka avulla hän voi vähentää virheellisten tietueiden määrän esimerkiksi 259:ään, niin tämä antaa yhteiskunnalle mahdollisuuden säästää:
1200*3053,542 = 3 664 250 ruplaa.
Mutta samalla hän voi pyytää lahjakkuuttaan ja työtään, sanotaanpa - miljoona ruplaa.
Toisin sanoen sosiaalikuluja alennetaan:
3 664 250 – 1 000 000 = 2 664 250 ruplaa.
Pohjimmiltaan tämä vaikutus on BigDat-tekniikoiden käytön lisäarvo.
Mutta tässä on otettava huomioon, että tämä on sosiaalinen vaikutus, ja tietokannan omistaja on kunnalliset viranomaiset, heidän tulonsa tähän tietokantaan kirjatun omaisuuden käytöstä 0,3 prosentin korolla: 2,778 miljardia ruplaa / vuosi. Ja nämä kustannukset (4 455 118 ruplaa) eivät häiritse häntä paljon, koska ne siirretään kiinteistönomistajille. Ja tässä suhteessa Bigdatan hienostuneempien teknologioiden kehittäjän on osoitettava kykynsä vakuuttaa tämän tietokannan omistaja, ja tällaiset asiat vaativat huomattavaa lahjakkuutta.
Tässä esimerkissä virheenarviointialgoritmi valittiin Schumannin mallin [2] pohjalta ohjelmiston todentamisesta luotettavuustestauksen aikana. Johtuen sen yleisyydestä Internetissä ja mahdollisuudesta saada tarvittavat tilastolliset indikaattorit. Metodologia on otettu Monakhov Yu.M. "Tietojärjestelmien toiminnallinen vakaus", katso spoilerin alla kuvassa. 7-9.
Riisi. 7 – 9 Schumannin mallin metodologia
Tämän materiaalin toisessa osassa on esimerkki tietojen puhdistuksesta, jossa saadaan tuloksia Schumannin mallin käytöstä.
Esittelen saadut tulokset:
Virheiden arvioitu määrä N = 3167 n.
Parametri C, lambda ja luotettavuusfunktio:
Kuva 17
Pohjimmiltaan lambda on todellinen indikaattori intensiteetistä, jolla virheet havaitaan kussakin vaiheessa. Jos katsot toista osaa, tämän indikaattorin arvio oli 42,4 virhettä tunnissa, mikä on melko verrattavissa Schumannin indikaattoriin. Yllä määritettiin, että nopeuden, jolla kehittäjä löytää virheitä, ei pitäisi olla pienempi kuin 1 virhe 250,4 tietuetta kohden, kun tarkistetaan 1 tietue minuutissa. Tästä johtuu lambdan kriittinen arvo Schumannin mallille:
60 / 250,4 = 0,239617.
Toisin sanoen virheiden havaitsemismenettelyjä on suoritettava, kunnes lambda, nykyisestä 38,964:stä, laskee arvoon 0,239617.
Tai kunnes indikaattori N (potentiaalinen virheiden määrä) miinus n (korjattu virheiden määrä) laskee alle hyväksytyn kynnysarvomme - 1459 kpl.
Kirjallisuus
- Monakhov, Yu. M. Tietojärjestelmien toiminnallinen vakaus. 3 tunnissa Osa 1. Ohjelmiston luotettavuus: oppikirja. korvaus / Yu. M. Monakhov; Vladim. osavaltio univ. – Vladimir: Izvo Vladim. osavaltio Yliopisto, 2011. – 60 s. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman, "Todennäköisyysmallit ohjelmiston luotettavuuden ennustamiseen."
- Tietovarastoinnin perusteet IT-ammattilaisille / Paulraj Ponniah – 2. painos.
Lähde: will.com