1. Lähtötiedot
Tietojen puhdistaminen on yksi data-analyysitehtävien haasteista. Tässä artikkelissa esitetään löydökset ja ratkaisut, jotka syntyivät ratkaistessamme käytännön ongelman, joka liittyi kiinteistörekisteriarvon laskemiseen liittyvään tietokanta-analyysiin. Lähdetiedostot ovat saatavilla täältä. .
Tiedostoa ”Comparative model result.ods” tarkasteltiin liitteessä B. KS 5:n määrittämisen tulokset. Tietoja kiinteistörekisteriarvon määritysmenetelmästä 5.1 Vertaileva lähestymistapa.
Taulukko 1. Tiedoston "Comparative model result.ods" tietojoukon tilastolliset indikaattorit
Kenttien kokonaismäärä, kpl — 44
Tietueiden kokonaismäärä, kpl — 365 490
Merkkien kokonaismäärä: 101 714 693
Keskimääräinen merkkimäärä viestiä kohden: 278 297
Tietueen merkkien keskihajonta, kpl — 15,510
Merkkien vähimmäismäärä merkintää kohden: 198
Merkkien enimmäismäärä merkintää kohden: 363
2. Johdanto. Perusstandardit
Tämän tietokannan analysoinnin aikana nousi esiin tehtävänä määritellä puhdistustasoa koskevat vaatimukset, sillä kuten kaikille on selvää, tällä tietokannalla on käyttäjille oikeudellisia ja taloudellisia seurauksia. Prosessin aikana kävi selväksi, ettei suurten tietomäärien puhdistustasolle ollut asetettu erityisiä vaatimuksia. Analysoidessani asiaa koskevaa lainsäädäntöä päädyin siihen, että ne kaikki perustuvat kykyihin. Toisin sanoen, syntyi tietty tehtävä, jota varten koottiin tietolähteet, luotiin tietojoukko ja luodun tietojoukon perusteella kehitettiin työkaluja tehtävän ratkaisemiseksi. Tuloksena olevat ratkaisut toimivat referensseinä vaihtoehtojen valinnalle. Tämä on esitetty kuvassa 1.
Koska standardien määrittelyssä on parempi nojata hyväksi havaittuihin teknologioihin, valitsin analyysikriteerien pohjaksi kohdassa esitetyt vaatimukset , koska pidin tätä asiakirjaa kattavimpana tässä asiassa. Tarkemmin sanottuna tämän asiakirjan kohdassa todetaan: "On huomattava, että tietojen eheysvaatimukset koskevat sekä manuaalista (paperista) että sähköistä dataa." Tämä sanamuoto liittyy varsin erityisesti siviiliprosessilain 71 §:ssä, hallintomenettelylain 70 §:ssä, välimiesmenettelylain 75 §:ssä ja siviiliprosessilain 84 §:ssä käytettyyn "kirjallisen muodon" käsitteeseen.
Kuvio 2 esittää kaavion oikeustieteen tietotyyppien lähestymistapojen muodostumisesta.
Kuva 2. Lähde .
Kuvio 3 esittää kuviossa 1 esitetyn mekanismin edellä mainituille "ohjeistustehtäville". Näitä vertailemalla on helppo nähdä, että nykyaikaisissa tietojärjestelmäsäännöksissä käytetyt lähestymistavat tiedon eheysvaatimusten täyttämiseen ovat merkittävästi rajallisempia verrattuna tiedon oikeudelliseen käsitteeseen.
Kuva 3
Asiakirjassa (ohjeistus) yhteys tekniseen osaan, eli tiedonkäsittely- ja tallennusvalmiuksiin, vahvistetaan hyvin lainauksella luvusta 18.2. Relaatiotietokanta: ”Tämä tiedostorakenne on luonnostaan turvallisempi, koska tiedot tallennetaan suureen tiedostomuotoon, joka säilyttää tiedon ja metatiedon välisen suhteen.”
Tässä lähestymistavassa ei ole pohjimmiltaan mitään epätavallista – se riippuu olemassa olevista teknisistä ominaisuuksista – ja se on luonnollinen prosessi, sillä käsitteiden laajeneminen johtuu eniten tutkitusta toiminnasta: tietokantasuunnittelusta. Toisaalta on kuitenkin syntymässä oikeudellisia normeja, jotka eivät salli olemassa olevien järjestelmien teknisten ominaisuuksien huomioimista, esimerkiksi: .
Kuva 4. Teknisten ominaisuuksien suppilo ().
Näistä syistä käy selväksi, että alkuperäinen tietojoukko (kuva 1) on ensisijaisesti säilytettävä ja toissijaisesti toimittava pohjana lisätietojen poimimiselle siitä. Esimerkiksi liikennekamerat ovat kaikkialla läsnä, ja tietojenkäsittelyjärjestelmät suodattavat pois rikkojat. Jäljelle jäävää tietoa voidaan kuitenkin tarjota myös muille kuluttajille, esimerkiksi ostoskeskuksen asiakasvirtojen markkinoinnin seurantaan. Tämä on lisäarvon lähde Big Dataa käytettäessä. On täysin mahdollista, että nyt kerättävillä tietojoukoilla on tulevaisuudessa samanlainen arvo kuin harvinaisilla 1700-luvun painoksilla nykyään. Loppujen lopuksi väliaikaiset tietojoukot ovat pohjimmiltaan ainutlaatuisia, eikä niitä todennäköisesti toisteta tulevaisuudessa.
3. Johdanto. Arviointikriteerit
Käsittelyn aikana kehitettiin seuraava virheluokittelu.
1. Virheluokka (perustuu GOST R 8.736-2011 -standardiin): a) systemaattiset virheet; b) satunnaiset virheet; c) karkeat virheet.
2. Moninaisuuden perusteella: a) monodistortio; b) multidistortio.
3. Seurausten kriittisyyden mukaan: a) kriittinen; b) ei-kriittinen.
4. Alkuperän mukaan:
A) Tekniset – laitteiden käytön aikana esiintyvät virheet. Tämä on melko yleinen virhe IoT-järjestelmissä, joihin yhteyden laatu ja laitteisto vaikuttavat merkittävästi.
B) Operaattorivirheet – virheet, jotka vaihtelevat syöttövirheistä operaattorien kirjoitusvirheistä tietokannan suunnittelun teknisten eritelmien virheisiin.
B) Käyttäjävirheet – tässä käyttäjävirheet vaihtelevat "asettelun vaihtamisen unohtamisesta" metrien sekoittamiseen jalkoihin.
5. Erotettu omaan luokkaan:
a) ”erotintehtävä”, eli välilyönti ja piste (meidän tapauksessamme), kun se kopioitiin;
b) yhteen kirjoitetut sanat;
c) välilyönnin puuttuminen palvelumerkkien jälkeen
d) symmetriset monisymbolit: (), "", "...".
Yhdessä kuvassa 5 esitetyn tietokantavirheiden systematisoinnin kanssa muodostuu melko tehokas koordinaatisto virheiden etsimiseen ja tiedonpuhdistusalgoritmin kehittämiseen tätä esimerkkiä varten.
Kuva 5. Tyypillisiä virheitä, jotka vastaavat tietokannan rakenneyksiköitä (Lähde: ).
Tarkkuus, toimialueen eheys, tietotyyppi, johdonmukaisuus, redundanssi, täydellisyys, päällekkäisyys, liiketoimintasääntöjen noudattaminen, rakenteellinen määritettävyys, datan poikkeamat, selkeys, ajantasaisuus, datan eheyssääntöjen noudattaminen. (Sivu 334. Tietovarastoinnin perusteet IT-ammattilaisille / Paulraj Ponniah.—2. painos)
Sulkeissa englanninkielinen sanamuoto ja venäjänkielinen konekäännös.
Tarkkuus. Järjestelmään tallennettu tietoelementin arvo on kyseisen tietoelementin esiintymän oikea arvo. Jos asiakkaan nimi ja osoite on tallennettuna tietueeseen, osoite on kyseisen nimen omaavan asiakkaan oikea osoite. Jos tilausnumeron 12345678 tietueesta löytyy tilattu määrä 1000 yksikköä, tämä määrä on kyseisen tilauksen tarkka määrä.
[Tarkkuus. Järjestelmään tallennettu tietokohteen arvo on kyseisen tietokohteen esiintymän oikea arvo. Jos asiakkaan nimi ja osoite on tallennettuna tietueeseen, osoite on kyseisen nimen omaavan asiakkaan oikea osoite. Jos löydät tilausnumeron 12345678 tietueesta tilausmääräksi 1 000 yksikköä, tämä määrä on kyseisen tilauksen tarkka määrä.]
Verkkotunnuksen eheys. Attribuutin data-arvo on sallittujen, määriteltyjen arvojen rajoissa. Yleinen esimerkki on, että sukupuoli-tietoelementin sallitut arvot ovat ”mies” ja ”nainen”.
[Verkkotunnuksen eheys. Attribuutin data-arvo on hyväksyttävien, määriteltyjen arvojen sisällä. Yleinen esimerkki ovat sukupuoli-tietoelementin hyväksyttävät arvot "mies" ja "nainen".]
Tietotyyppi. Tietoattribuutin arvo tallennetaan itse asiassa kyseiselle attribuutille määritellyn tietotyypin mukaisesti. Kun tallennusnimikentän tietotyypiksi on määritetty ”teksti”, kaikki kentän esiintymät sisältävät tallennusnimen tekstimuodossa, eivätkä numeerisina koodeina.
[Tietotyyppi. Tietoattribuutin arvo tallennetaan itse asiassa kyseiselle attribuutille määritettynä tietotyyppinä. Jos tallennusnimikentän tietotyyppi on määritelty "tekstiksi", kaikki kyseisen kentän esiintymät sisältävät tallennusnimen tekstinä numerokoodien sijaan.]
Johdonmukaisuus. Tietokentän muoto ja sisältö ovat samat useissa eri lähdejärjestelmissä. Jos tuotteen ABC tuotekoodi yhdessä järjestelmässä on 1234, niin tämän tuotteen koodi on 1234 kaikissa lähdejärjestelmissä.
[Johdonmukaisuus. Tietokentän muoto ja sisältö ovat samat kaikissa lähdejärjestelmissä. Jos tuotteen ABC tuotekoodi yhdessä järjestelmässä on 1234, niin kyseisen tuotteen koodi on 1234 kaikissa lähdejärjestelmissä.]
Redundanssi. Samoja tietoja ei saa tallentaa useampaan kuin yhteen paikkaan järjestelmässä. Jos tehokkuussyistä tietoalkio tallennetaan tarkoituksella useampaan kuin yhteen paikkaan järjestelmässä, redundanssi on selvästi tunnistettava ja todennettava.
[Redundanssi. Samoja tietoja ei tule tallentaa useampaan kuin yhteen paikkaan järjestelmässä. Jos tehokkuussyistä tietoalkio tallennetaan tarkoituksella useisiin paikkoihin järjestelmässä, redundanssi on määriteltävä ja varmennettava selkeästi.]
Täydellisyys. Järjestelmässä ei ole puuttuvia arvoja tietylle attribuutille. Esimerkiksi asiakastiedostossa jokaisen asiakkaan "osavaltio"-kentässä on oltava kelvollinen arvo. Tilaustietojen tiedostossa jokaisen tilauksen tietotietueen on oltava kokonaan täytetty.
[Täydellisyys. Järjestelmässä ei ole puuttuvia arvoja tälle attribuutille. Esimerkiksi asiakastiedostossa jokaisen asiakkaan "tila"-kentässä on oltava kelvollinen arvo. Tilaustietotiedostossa jokaisen tilaustietotietueen on oltava kokonaan täytetty.]
Kaksinkertainen kopiointi. Järjestelmässä olevien tietueiden kaksoiskappaleet on täysin ratkaistu. Jos tuotetiedostossa tiedetään olevan kaksoiskappaleita, kaikki kunkin tuotteen kaksoiskappaleet tunnistetaan ja luodaan ristiviittaus.
[Kaksoiskappaleet. Järjestelmän kaksoiskappaleet poistetaan kokonaan. Jos tuotetiedoston tiedetään sisältävän kaksoiskappaleita, kaikki kunkin tuotteen kaksoiskappaleet tunnistetaan ja niihin tehdään ristiviittaukset.]
Liiketoimintasääntöjen noudattaminen. Kunkin tiedon arvot noudattavat ennalta määrättyjä liiketoimintasääntöjä. Huutokauppajärjestelmässä vasara- tai myyntihinta ei voi olla pienempi kuin pohjahinta. Pankkilainajärjestelmässä lainasaldon on aina oltava positiivinen tai nolla.
[Liiketoimintasääntöjen noudattaminen. Kunkin dataelementin arvot ovat vakiintuneiden liiketoimintasääntöjen mukaisia. Huutokauppajärjestelmässä vasara- tai myyntihinta ei voi olla pienempi kuin pohjahinta. Pankkien luottojärjestelmässä luottosaldon on aina oltava positiivinen tai nolla.]
Rakenteellinen määritettävyys. Aina kun tietoalkio voidaan luonnollisesti jäsentää yksittäisiksi komponenteiksi, alkion on sisällettävä tämä hyvin määritelty rakenne. Esimerkiksi yksilön nimi jakautuu luonnostaan etunimeen, toisen nimen alkukirjaimeen ja sukunimeen. Yksilöiden nimien arvot on tallennettava muodossa etunimi, toisen nimen alkukirjain ja sukunimi. Tämä tiedon laadun ominaisuus yksinkertaistaa standardien noudattamisen valvontaa ja vähentää puuttuvia arvoja.
[Rakenteellinen määritelmä. Jos dataelementti voidaan luonnollisesti jäsentää erillisiksi komponenteiksi, elementin tulisi sisältää tämä selkeästi määritelty rakenne. Esimerkiksi henkilön nimi on luonnollisesti jaettu etunimeen, toisen nimen alkukirjaimeen ja sukunimeen. Yksilöiden nimien arvot tulisi tallentaa etuniminä, toisen nimen alkukirjaimina ja sukuniminä. Tämä datan laatuominaisuus yksinkertaistaa standardien soveltamista ja vähentää puuttuvia arvoja.]
Datapoikkeama. Kenttää saa käyttää vain siihen tarkoitukseen, johon se on määritelty. Jos kenttä Osoite-3 on määritelty pitkien osoitteiden mahdolliselle kolmannelle osoiteriville, tätä kenttää saa käyttää vain kolmannen osoiterivin tallentamiseen. Sitä ei saa käyttää asiakkaan puhelin- tai faksinumeron syöttämiseen.
[Tietojen poikkeama: Tätä kenttää saa käyttää vain siihen tarkoitukseen, johon se on määritelty. Jos Osoite-3-kenttä on määritelty pitkien osoitteiden mahdollista kolmatta osoiteriviä varten, tätä kenttää saa käyttää vain kolmannen osoiterivin tallentamiseen. Sitä ei saa käyttää asiakkaan puhelin- 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, tietoelementistä ei ole käyttäjille mitään hyötyä. 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 ymmärrä sen merkitystä selvästi, tietoelementistä ei ole heille mitään hyötyä. Oikeat nimeämiskäytännöt auttavat tekemään tietoelementeistä helposti ymmärrettäviä käyttäjille.]
Ajantasainen. Käyttäjät määrittävät tietojen ajantasaisuuden. Jos käyttäjät odottavat asiakasdimensiotietojen olevan enintään yhden päivän vanhoja, lähdejärjestelmien asiakastietojen muutokset on otettava käyttöön tietovarastossa päivittäin.
[Ajankohtainen. Käyttäjät määrittävät datan ajantasaisuuden. Jos käyttäjät odottavat asiakasmittausdatan olevan enintään yhden päivän vanhoja, lähdejärjestelmien asiakasdataan tehdyt muutokset tulisi ottaa käyttöön tietovarastossa päivittäin.]
Hyödyllisyys. Jokaisen tietovaraston dataelementin on täytettävä joitakin käyttäjätietojen keräämisen vaatimuksia. Dataelementti voi olla tarkka ja korkealaatuinen, mutta jos siitä ei ole käyttäjille mitään hyötyä, on täysin tarpeetonta, että kyseinen dataelementti on tietovarastossa.
[Hyödyllisyys. Jokaisen tietovaraston dataelementin on täytettävä tietyt käyttäjien tiedonkeruuvaatimukset. Dataelementti voi olla tarkka ja korkealaatuinen, mutta jos se ei tarjoa käyttäjille mitään arvoa, ei ole mitään syytä, miksi kyseistä dataelementtiä olisi tietovarastossa.]
Tietojen eheyssääntöjen noudattaminen. Lähdejärjestelmien relaatiotietokantoihin tallennettujen tietojen on noudatettava entiteettien eheys- ja viite-eheyssääntöjä. Millään taulukolla, joka sallii null-arvon ensisijaisena avaimena, ei ole entiteettien eheyttä. Viite-eheys pakottaa ylä- ja alatason suhteiden muodostamisen oikein. Asiakas-tilaus-suhteessa viite-eheys varmistaa, että jokaiselle tietokannassa olevalle tilaukselle on asiakas.
Tietojen eheyden ylläpitäminen. Lähdejärjestelmien relaatiotietokantoihin tallennettujen tietojen on noudatettava entiteetti- ja viite-eheyden sääntöjä. Kaikilla taulukoilla, jotka sallivat null-pääavaimen, puuttuu entiteetti-eheys. Viite-eheys varmistaa, että ylä- ja alatason suhteet muodostetaan oikein. Asiakas-tilaus-suhteissa viite-eheys varmistaa asiakkaan olemassaolon jokaiselle tietokannan tilaukselle.
4. Tiedonpuhdistuksen laatu
Datanpuhdistuksen laatu on melko haastava kysymys big datassa. Tietyn tehtävän edellyttämän datanpuhdistuksen asteen määrittäminen on keskeinen kysymys jokaiselle data-analyytikolle. Useimmissa nykyisissä tehtävissä jokainen analyytikko määrittää tämän itse, eikä ulkopuolinen todennäköisesti pysty arvioimaan ratkaisunsa tätä puolta. Käsillä olevan tehtävän kannalta tämä kysymys oli kuitenkin ratkaisevan tärkeä, koska oikeudellisten tietojen luotettavuuden on lähestyttävä sitä.
Ohjelmistojen testaustekniikoiden käyttövarmuuden määrittämiseksi. Näitä malleja on nykyään yli 100. Monet mallit käyttävät pyyntöpohjaista mallia:
Kuva 6
Perustelin asiaa seuraavasti: "Jos havaittu virhe on tässä mallissa vikaan analoginen tapahtuma, niin miten voin löytää t-parametrin analogin?" Kehitin seuraavan mallin: Kuvitellaan, että testaajalta yhden tietueen tarkistamiseen kuluu 1 minuutti (kyseisessä tietokannassa). Sitten kaikkien virheiden löytämiseen tarvitaan 365 494 minuuttia, mikä on noin 3 vuotta ja 3 kuukautta työtä. Ymmärtääksemme tämä on erittäin merkittävä työmäärä, ja tietokannan tarkistamisen kustannukset ovat kohtuuttomat tietokannan luojalle. Tässä pohdinnassa tulee esiin kustannusten taloudellinen käsite, ja analyysin jälkeen päädyin siihen, että se on melko tehokas työkalu. Taloustieteen lain perusteella: "Tuotantomäärä (yksiköissä), jolla yritys saavuttaa maksimaalisen voiton, sijaitsee pisteessä, jossa uuden tuotantoyksikön tuotannon rajakustannukset ovat yhtä suuret kuin hinta, jonka yritys voi saada jokaisesta uudesta yksiköstä." Postulaatin perusteella, että jokaisen seuraavan virheen löytäminen vaatii yhä useampien tietueiden tarkistamista, tämä on kustannustekijä. Eli testausmalleissa omaksuttu postulaatti saa fysikaalisen merkityksen seuraavassa kaavassa: jos i:nnen virheen löytämiseksi piti tarkistaa n tietuetta, niin seuraavan (i+1) virheen löytämiseksi on jo tarpeen tarkistaa m tietuetta ja samanaikaisesti n
- Kun ennen uuden virheen löytymistä tarkistettavien tietueiden määrä vakiintuu;
- Kun seuraavan virheen löytämistä edeltävien tarkastettujen tietueiden määrä kasvaa.
Kriittisen arvon määrittämiseksi käytin taloudellisen toteutettavuuden käsitettä, joka tässä tapauksessa voidaan yhteiskunnallisten kustannusten käsitettä käyttäen muotoilla seuraavasti: "Virheen korjaamisen kustannukset tulisi kantaa sillä taloudellisella toimijalla, joka pystyy tekemään sen alhaisimmilla kustannuksilla." Meillä on yksi toimija - testaaja, joka käyttää yhden minuutin yhden tietueen tarkistamiseen. Rahassa mitattuna 6 000 ruplan päivätuloilla tämä on 12,2 ruplaa (noin tänään). Jäljellä on vielä määritettävä talouslain tasapainon toinen puoli. Perustelin seuraavasti. Olemassa oleva virhe vaatii siltä, johon se vaikuttaa, eli kiinteistön omistajalta, ponnisteluja sen korjaamiseksi. Oletetaan, että tämä vaatii yhden toimintapäivän (hakemuksen jättäminen, korjatun asiakirjan vastaanottaminen). Tällöin yhteiskunnallisesta näkökulmasta hänen kustannuksensa ovat yhtä suuret kuin keskimääräinen päiväpalkka. Hanti-Mansin autonomisessa piirikunnassa kertynyt keskimääräinen palkka on 73 285 ruplaa tai 3 053 542 ruplaa päivässä. Näin ollen saamme kriittisen arvon, joka on yhtä suuri kuin:
3053,542: 12,2 = 250,4 tietueyksikköä.
Yhteiskunnan näkökulmasta tämä tarkoittaa, että jos testaaja tarkisti 251 tietuetta ja löysi yhden virheen, se vastaa sitä, että käyttäjä korjaisi virheen itse. Vastaavasti, jos testaaja käytti saman verran aikaa 252 tietueen tarkistamiseen seuraavan virheen löytämiseksi, sen korjaamisen kustannukset tulisi siirtää käyttäjälle.
Tämä lähestymistapa on yksinkertaistettu, koska yhteiskunnallisesta näkökulmasta on tarpeen ottaa huomioon jokaisen asiantuntijan aiheuttamat kaikki lisäkustannukset, eli verot ja sosiaaliturvamaksut sisältävät kulut. Malli on kuitenkin selkeä. Tämä suhde johtaa seuraavaan vaatimukseen asiantuntijoille: IT-asiantuntijan palkan tulisi olla korkeampi kuin maan keskipalkka. Jos heidän palkkansa on alhaisempi kuin potentiaalisten tietokannan käyttäjien keskipalkka, heidän on henkilökohtaisesti auditoitava koko tietokanta.
Kuvattua kriteeriä käytettäessä muodostuu ensimmäinen vaatimus tietokannan laadulle:
I(tr). Kriittisten virheiden osuuden ei tulisi ylittää arvoa 1/250,4 = 0,39938 %. Hieman vähemmän kuin kultaa teollisuudessa. Ja fyysisesti virheellisiä merkintöjä on enintään 1 459.
Taloudellinen perääntyminen.
Pohjimmiltaan sallimalla tällaisen määrän virheitä tietueissa yhteiskunta hyväksyy taloudellisia tappioita, jotka ovat seuraavan suuruisia:
1459 * 3053,542 = 4 455 118 ruplaa.
Tämä määrä määräytyy sen perusteella, että yhteiskunnalla ei ole työkaluja näiden kustannusten vähentämiseksi. Jos joku siis kehittää teknologian, joka vähentää virheellisten tietueiden määrän esimerkiksi 259:ään, se antaa yhteiskunnalle mahdollisuuden säästää:
1200 * 3053,542 = 3 664 250 ruplaa.
Mutta samaan aikaan hän voi pyytää esimerkiksi miljoona ruplaa lahjakkuudestaan ja työstään.
Eli yhteiskunnalliset kustannukset pienenevät:
3 664 250 – 1 000 000 = 2 664 250 ruplaa.
Pohjimmiltaan tämä vaikutus on BigData-teknologioiden käytön lisäarvo.
Mutta on tärkeää ottaa huomioon, että kyseessä on sosiaalinen vaikutus ja tietokannan omistaja on kunta. Heidän tulonsa tietokantaan tallennetun omaisuuden käytöstä 0,3 prosentin korolla ovat 2,778 miljardia ruplaa vuodessa. Nämä kustannukset (4 455 118 ruplaa) eivät erityisesti kosketa heitä, koska ne siirtyvät kiinteistönomistajille. Siksi hienostuneempien BigData-teknologioiden kehittäjän on osoitettava kykynsä vakuuttaa tietokannan omistaja, ja tällaiset asiat vaativat huomattavaa lahjakkuutta.
Tässä esimerkissä virheenarviointialgoritmi valittiin ohjelmistojen luotettavuustestaukseen tarkoitetun Schumannin mallin [2] perusteella. Tämä tehtiin sen laajan käytön verkossa ja tarvittavien tilastollisten indikaattoreiden hankkimiskyvyn vuoksi. Menetelmä otettiin Yu. M. Monakhovin teoksesta "Tietojärjestelmien toiminnallinen stabiilius" (katso spoileri kuvissa 7-9).
Kuva 7–9 Schumannin mallin metodologia
Tämän materiaalin toisessa osassa esitetään esimerkki datan puhdistuksesta, jossa saatiin Schumannin mallin käytön tuloksia.
Esittelenpä saavutetut tulokset:
Arvioitu virheiden lukumäärä N = 3167 shN.
Parametri C, lambda ja luotettavuusfunktio:
Kuva 17
Pohjimmiltaan lambda on todellinen indikaattori siitä, kuinka nopeasti virheitä havaitaan kussakin vaiheessa. Toisessa osassa arvioitu lambda oli 42,4 virhettä tunnissa, mikä on melko verrattavissa Schumannin indikaattoriin. Edellä määritettiin, että kehittäjän virheiden havaitsemisnopeuden tulisi olla vähintään 1 virhe 250,4 tietuetta kohden, ja yksi tietue tarkistetaan minuutissa. Näin ollen Schumannin mallin kriittinen lambda-arvo on:
60/250,4 = 0,239617.
Toisin sanoen virheentunnistustoimenpiteiden suorittaminen on tarpeen, kunnes lambda nykyisestä 38,964:stä laskee arvoon 0,239617.
Tai kunnes indikaattori N (virheiden mahdollinen määrä) miinus n (korjattu virheiden määrä) laskee alle käyttämämme kynnysarvon – 1459 kpl.
Kirjallisuus
- Monakhov, Yu. M. Tietojärjestelmien toiminnallinen vakaus. 3 osassa. Osa 1. Ohjelmiston luotettavuus: oppikirja / Yu. M. Monakhov; Vladimirin osavaltion yliopisto. – Vladimir: Izdvo Vladimirin valtionyliopisto, 2011. – 60 s. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman, ”Todennäköisyyspohjaiset mallit ohjelmistojen luotettavuuden ennustamiseen.”
- Tietovarastoinnin perusteet IT-ammattilaisille / Paulraj Ponniah.—2. painos.
Lähde: will.com
