1. Začetni podatki
Čiščenje podatkov je eden od izzivov, s katerimi se soočajo naloge analize podatkov. To gradivo je odražalo razvoj in rešitve, ki so nastale kot posledica reševanja praktičnega problema analize baze podatkov pri oblikovanju katastrske vrednosti. Viri tukaj .
Obravnavana je bila datoteka “Primerjalni model total.ods” v “Priloga B. Rezultati ugotavljanja KS 5. Podatki o načinu ugotavljanja katastrske vrednosti 5.1 Primerjalni pristop”.
Tabela 1. Statistični indikatorji nabora podatkov v datoteki “Comparative model total.ods”
Skupno število polj, kos. — 44
Skupno število zapisov, kos. — 365 490
Skupno število znakov, kos. — 101 714 693
Povprečno število znakov v zapisu, kos. — 278,297
Standardni odklon znakov v zapisu, kos. — 15,510
Najmanjše število znakov v vnosu, kos. — 198
Največje število znakov v vnosu, kos. — 363
2. Uvodni del. Osnovni standardi
Pri analizi navedene baze je bila oblikovana naloga določitve zahtev glede stopnje očiščenosti, saj, kot je vsem jasno, navedena baza ustvarja pravne in ekonomske posledice za uporabnike. Med delom se je izkazalo, da ni posebnih zahtev glede stopnje čiščenja velikih podatkov. Ob analizi pravnih norm v tej zadevi sem prišel do zaključka, da so vse oblikovane iz možnosti. To pomeni, da se je pojavila določena naloga, za nalogo se zberejo viri informacij, nato se oblikuje nabor podatkov in na podlagi ustvarjenega nabora podatkov orodja za reševanje problema. Dobljene rešitve so referenčne točke pri izbiri alternativ. To sem predstavil na sliki 1.
Ker se je pri določanju kakršnih koli standardov bolje zanašati na preizkušene tehnologije, sem izbral zahteve, določene v , ker se mi zdi ta dokument najobsežnejši za to številko. Zlasti v tem dokumentu razdelek pravi: »Opozoriti je treba, da zahteve glede celovitosti podatkov veljajo enako za ročne (papirne) in elektronske podatke.« (prevod: “... zahteve glede celovitosti podatkov veljajo enako za ročne (papirne) in elektronske podatke”). Ta formulacija je precej natančno povezana s pojmom "pisni dokaz", v določbah 71. člena Zakonika o pravdnem postopku, 70. čl. 75 CAS, člen 84 APC, “pisno” čl. XNUMX Zakonik o civilnem postopku.
Slika 2 prikazuje diagram oblikovanja pristopov k vrstam informacij v sodni praksi.
riž. 2. Vir .
Slika 3 prikazuje mehanizem na sliki 1 za naloge iz zgornjega »Vodenja«. S primerjavo je enostavno ugotoviti, da so pristopi, ki se uporabljajo pri izpolnjevanju zahtev po celovitosti informacij v sodobnih standardih za informacijske sisteme, bistveno omejeni v primerjavi s pravnim konceptom informacije.
sl.3
V navedenem dokumentu (Navodilo) je povezava s tehničnim delom, zmožnostmi obdelave in shranjevanja podatkov dobro potrjena s citatom iz poglavja 18.2. Relacijska baza podatkov: "Ta datotečna struktura je sama po sebi varnejša, saj se podatki hranijo v velikem formatu datoteke, ki ohranja razmerje med podatki in metapodatki."
Pravzaprav v tem pristopu – glede na obstoječe tehnične zmogljivosti – ni nič neobičajnega in je sam po sebi naraven proces, saj širjenje konceptov izhaja iz najbolj proučevane dejavnosti – oblikovanja baze podatkov. Toda po drugi strani se pojavljajo pravne norme, ki ne predvidevajo popustov na tehnične zmogljivosti obstoječih sistemov, na primer: .
riž. 4. Tok tehničnih zmogljivosti ().
S teh vidikov postane jasno, da bo treba prvotni nabor podatkov (slika 1) najprej shraniti in drugič biti osnova za pridobivanje dodatnih informacij iz njega. No, kot primer: kamere, ki snemajo prometna pravila, so vseprisotne, sistemi za obdelavo informacij izločajo kršitelje, lahko pa se drugim potrošnikom ponudijo tudi druge informacije, na primer kot marketinško spremljanje strukture toka kupcev v nakupovalno središče. In to je vir dodatne dodane vrednosti pri uporabi BigDat. Povsem možno je, da bodo nabori podatkov, ki se zbirajo zdaj, nekje v prihodnosti, imeli vrednost v skladu z mehanizmom, podobnim vrednosti redkih izdaj 1700 v tem trenutku. Navsezadnje so začasni nabori podatkov pravzaprav edinstveni in je malo verjetno, da se bodo v prihodnosti ponovili.
3. Uvodni del. Kriteriji ocenjevanja
Med procesom obdelave je bila razvita naslednja klasifikacija napak.
1. Razred napak (na podlagi GOST R 8.736-2011): a) sistematične napake; b) naključne napake; c) napaka.
2. Po večkratnosti: a) mono distorzija; b) večkratno popačenje.
3. Glede na kritičnost posledic: a) kritične; b) ni kritično.
4. Po viru nastanka:
A) Tehnične – napake, ki nastanejo med delovanjem opreme. Dokaj relevantna napaka za sisteme IoT, sisteme s pomembno stopnjo vpliva na kakovost komunikacije, opremo (strojno opremo).
B) Operaterske napake - napake v širokem razponu od operaterskih tipkarskih napak med vnosom do napak v tehničnih specifikacijah za načrtovanje baze podatkov.
C) Uporabniške napake - tukaj so uporabniške napake v celotnem obsegu od »pozabil sem preklopiti postavitev« do zamenjave metrov za noge.
5. Ločeno v ločen razred:
a) »naloga ločila«, to je presledek in »:« (v našem primeru), ko je bil podvojen;
b) besede, pisane skupaj;
c) brez presledka za službenimi znaki
d) simetrično več simbolov: (), "", "...".
Skupaj s sistematizacijo napak baze podatkov, predstavljeno na sliki 5, se oblikuje dokaj učinkovit koordinatni sistem za iskanje napak in razvoj algoritma za čiščenje podatkov za ta primer.
riž. 5. Tipične napake, ki ustrezajo strukturnim enotam baze (Vir: ).
Natančnost, celovitost domene, vrsta podatkov, doslednost, redundanca, popolnost, podvajanje, skladnost s poslovnimi pravili, strukturna določnost, anomalija podatkov, jasnost, pravočasnost, upoštevanje pravil o celovitosti podatkov. (Stran 334. Osnove skladiščenja podatkov za IT strokovnjake / Paulraj Ponniah.—2. izdaja.)
Predstavljeno angleško besedilo in ruski strojni prevod v oklepajih.
Natančnost. Vrednost, shranjena v sistemu za podatkovni element, je prava vrednost za to pojavnost podatkovnega elementa. Če imate v zapisu shranjeno ime stranke in naslov, potem je naslov pravi naslov za stranko s tem imenom. Če najdete naročeno količino kot 1000 enot v zapisu za številko naročila 12345678, potem je ta količina točna količina za to naročilo.
[Natančnost. Vrednost, shranjena v sistemu za podatkovni element, je pravilna vrednost za to pojavnost podatkovnega elementa. Če imate v zapisu shranjeno ime in naslov stranke, potem je naslov pravi naslov za stranko s tem imenom. Če najdete naročeno količino kot 1000 enot v zapisu za številko naročila 12345678, potem je ta količina točna količina za to naročilo.]
Integriteta domene. Podatkovna vrednost atributa spada v obseg dovoljenih, definiranih vrednosti. Pogost primer sta dovoljeni vrednosti »moški« in »ženski« za podatkovni element spola.
[Celovitost domene. Vrednost podatkov atributa spada v obseg veljavnih, definiranih vrednosti. Splošni primer sta veljavni vrednosti "male" in "female" za podatkovni element o spolu.]
Vrsta podatkov. Vrednost za podatkovni atribut je dejansko shranjena kot podatkovni tip, definiran za ta atribut. Ko je podatkovni tip polja z imenom trgovine definiran kot »besedilo«, vsi primerki tega polja vsebujejo ime trgovine, prikazano v besedilni obliki in ne številskih kod.
[Vrsta podatkov. Vrednost podatkovnega atributa je dejansko shranjena kot podatkovni tip, definiran za ta atribut. Če je podatkovni tip polja z imenom trgovine definiran kot "besedilo", vsi primerki tega polja vsebujejo ime trgovine, prikazano v besedilni obliki in ne v številskih kodah.]
Doslednost. Oblika in vsebina podatkovnega polja sta enaki v več izvornih sistemih. Če je koda izdelka za izdelek ABC v enem sistemu 1234, potem je koda za ta izdelek 1234 v vsakem izvornem sistemu.
[Doslednost. Oblika in vsebina podatkovnega polja sta enaki v različnih izvornih sistemih. Če je koda izdelka za izdelek ABC v enem sistemu 1234, potem je koda za ta izdelek 1234 v vsakem izvornem sistemu.]
Redundanca. Isti podatki ne smejo biti shranjeni na več kot enem mestu v sistemu. Če je zaradi učinkovitosti podatkovni element namerno shranjen na več kot enem mestu v sistemu, mora biti redundanca jasno identificirana in preverjena.
[Odvečnost. Isti podatki ne smejo biti shranjeni na več kot enem mestu v sistemu. Če je zaradi učinkovitosti podatkovni element namerno shranjen na več lokacijah v sistemu, mora biti redundanca jasno definirana in preverjena.]
Popolnost. Za dani atribut v sistemu ni manjkajočih vrednosti. Na primer, v datoteki stranke mora obstajati veljavna vrednost za polje »stanje« za vsako stranko. V datoteki za podatke o naročilu mora biti vsak zapis podrobnosti za naročilo v celoti izpolnjen.
[Popolnost. V sistemu za ta atribut ni manjkajočih vrednosti. Na primer, datoteka odjemalca mora imeti veljavno vrednost za polje "status" za vsakega odjemalca. V datoteki s podrobnostmi naročila mora biti vsak zapis podrobnosti o naročilu v celoti izpolnjen.]
Podvajanje. Podvajanje zapisov v sistemu je popolnoma rešeno. Če je znano, da ima datoteka izdelka podvojene zapise, se identificirajo vsi podvojeni zapisi za vsak izdelek in ustvari navzkrižno sklicevanje.
[Dvojnik. Podvajanje zapisov v sistemu je popolnoma odpravljeno. Če je znano, da datoteka izdelka vsebuje podvojene vnose, so prepoznani vsi podvojeni vnosi za vsak izdelek in ustvarjeno je navzkrižno sklicevanje.]
Skladnost s poslovnimi pravili. Vrednosti vsakega podatka so v skladu s predpisanimi poslovnimi pravili. V dražbenem sistemu udarna ali prodajna cena ne more biti nižja od rezervne cene. V sistemu bančnega posojila mora biti stanje posojila vedno pozitivno ali nič.
[Upoštevanje pravil poslovanja. Vrednosti vsakega podatkovnega elementa so v skladu z uveljavljenimi poslovnimi pravili. V dražbenem sistemu udarna ali prodajna cena ne more biti nižja od rezervne cene. V bančnem kreditnem sistemu mora biti stanje posojila vedno pozitivno ali nič.]
Strukturna določenost. Kjerkoli je podatkovno postavko mogoče naravno strukturirati v posamezne komponente, mora vsebovati to natančno definirano strukturo. Na primer, ime posameznika je naravno razdeljeno na ime, srednjo začetnico in priimek. Vrednosti za imena posameznikov morajo biti shranjene kot ime, srednje začetnice in priimek. Ta lastnost kakovosti podatkov poenostavlja uveljavljanje standardov in zmanjšuje manjkajoče vrednosti.
[Strukturna gotovost. Če je podatkovni element mogoče naravno strukturirati v posamezne komponente, mora element vsebovati to natančno definirano strukturo. Na primer, ime osebe je naravno razdeljeno na ime, srednjo začetnico in priimek. Vrednosti za posamezna imena je treba shraniti kot ime, srednjo začetnico in priimek. Ta značilnost kakovosti podatkov poenostavlja uporabo standardov in zmanjšuje manjkajoče vrednosti.]
Podatkovna anomalija. Polje je treba uporabiti samo za namen, za katerega je definirano. Če je polje Address-3 definirano za morebitno tretjo vrstico naslova za dolge naslove, potem je treba to polje uporabiti samo za zapis tretje vrstice naslova. Ne sme se uporabljati za vnos telefonske ali faks številke stranke.
[Podatkovna anomalija. Polje se sme uporabljati samo za namen, za katerega je definirano. Če je polje Address-3 definirano za katero koli možno tretjo naslovno vrstico za dolge naslove, se to polje uporablja samo za zapis tretje naslovne vrstice. Ne sme se uporabljati za vnos telefonske številke ali številke faksa stranke.]
Jasnost. Podatkovni element ima lahko vse druge značilnosti kakovostnih podatkov, vendar če uporabniki ne razumejo jasno njegovega pomena, potem podatkovni element za uporabnike nima vrednosti. Ustrezna pravila poimenovanja pomagajo, da uporabniki podatkovne elemente dobro razumejo.
[Jasnost. Podatkovni element ima lahko vse druge značilnosti dobrih podatkov, vendar če uporabniki ne razumejo jasno njegovega pomena, potem podatkovni element za uporabnike nima vrednosti. Pravilna pravila poimenovanja pomagajo, da uporabniki podatkovne elemente dobro razumejo.]
Pravočasno. Uporabniki določajo ažurnost podatkov. Če uporabniki pričakujejo, da podatki o dimenzijah strank ne bodo starejši od enega dneva, je treba spremembe podatkov o strankah v izvornih sistemih dnevno uveljaviti v podatkovnem skladišču.
[Pravočasno. Uporabniki določajo ažurnost podatkov. Če uporabniki pričakujejo, da podatki o razsežnostih strank niso starejši od enega dneva, je treba spremembe podatkov o strankah v izvornih sistemih dnevno uporabljati v podatkovnem skladišču.]
Uporabnost. Vsak podatkovni element v podatkovnem skladišču mora izpolnjevati nekatere zahteve zbirke uporabnikov. Podatkovni element je lahko natančen in visokokakovosten, a če nima nobene vrednosti za uporabnike, potem je popolnoma nepotrebno, da je ta podatkovni element v podatkovnem skladišču.
[Pripomoček. Vsaka podatkovna postavka v podatkovni shrambi mora izpolnjevati nekatere zahteve uporabniške zbirke. Podatkovni element je lahko natančen in visokokakovosten, vendar če ne zagotavlja vrednosti uporabnikom, potem ni nujno, da je ta podatkovni element v podatkovnem skladišču.]
Upoštevanje pravil o celovitosti podatkov. Podatki, shranjeni v relacijskih zbirkah podatkov izvornih sistemov, morajo upoštevati pravila celovitosti entitet in referenčne integritete. Vsaka tabela, ki dovoljuje null kot primarni ključ, nima celovitosti entitete. Referenčna integriteta sili k pravilni vzpostavitvi odnosov starš-otrok. V razmerju od stranke do naročila referenčna celovitost zagotavlja obstoj stranke za vsako naročilo v bazi podatkov.
[Skladnost s pravili o celovitosti podatkov. Podatki, shranjeni v relacijskih zbirkah podatkov izvornih sistemov, morajo biti skladni s pravili entitetne celovitosti in referenčne celovitosti. Vsaka tabela, ki dovoljuje null kot primarni ključ, nima celovitosti entitete. Referenčna integriteta sili, da je odnos med starši in otroki pravilno vzpostavljen. V razmerju stranka-naročilo referenčna celovitost zagotavlja, da stranka obstaja za vsako naročilo v bazi podatkov.]
4. Kakovost čiščenja podatkov
Kakovost čiščenja podatkov je v bigdata precej problematično vprašanje. Odgovor na vprašanje, kakšna stopnja čiščenja podatkov je potrebna za dokončanje naloge, je temeljnega pomena za vsakega podatkovnega analitika. Pri večini trenutnih problemov to določi vsak analitik sam in malo verjetno je, da bi kdo od zunaj lahko ovrednotil ta vidik v njegovi rešitvi. Toda za opravljeno nalogo v tem primeru je bilo to vprašanje izredno pomembno, saj bi morala biti zanesljivost pravnih podatkov težka k enemu.
Upoštevanje tehnologij testiranja programske opreme za določitev zanesljivosti delovanja. Danes je teh modelov več . Številni modeli uporabljajo model servisiranja zahtevkov:
Sl. 6
Razmišljate takole: "Če je najdena napaka dogodek, podoben dogodku napake v tem modelu, kako potem najti analog parametra t?" Sestavil sem naslednji model: Predstavljajmo si, da je čas, ki ga preizkuševalec potrebuje za preverjanje enega zapisa, 1 minuta (za zadevno bazo podatkov), nato pa bo za iskanje vseh napak potreboval 365 minut, kar je približno 494 leta in 3 mesecev delovnega časa. Kot razumemo, je to zelo veliko dela in stroški preverjanja podatkovne baze bodo previsoki za sestavljalca te podatkovne baze. V tem razmišljanju se pojavi ekonomski koncept stroškov in po analizi sem prišel do zaključka, da je to dokaj učinkovito orodje. Na podlagi zakona ekonomije: »Obseg proizvodnje (v enotah), pri katerem podjetje doseže največji dobiček, se nahaja na točki, kjer se mejni stroški proizvodnje nove proizvodne enote primerjajo s ceno, ki jo to podjetje lahko prejme. za novo enoto." Glede na postulat, da iskanje vsake naslednje napake zahteva vedno več preverjanja evidenc, je to stroškovni dejavnik. To pomeni, da postulat, sprejet v modelih testiranja, dobi fizični pomen v naslednjem vzorcu: če je bilo za iskanje i-te napake potrebno preveriti n zapisov, potem bo za iskanje naslednje (i+3) napake potrebno preveriti m zapisov in hkrati n
- Ko se število preverjenih zapisov pred odkritjem nove napake stabilizira;
- Ko se bo povečalo število zapisov, preverjenih pred iskanjem naslednje napake.
Za določitev kritične vrednosti sem se obrnil na koncept ekonomske izvedljivosti, ki ga v tem primeru z uporabo koncepta družbenih stroškov lahko formuliramo takole: »Stroške odprave napake mora nositi gospodarski subjekt, ki lahko naredi po najnižji ceni." Imamo enega agenta - testerja, ki porabi 1 minuto za preverjanje enega zapisa. Če zaslužite 6000 rubljev na dan, bo to v denarju 12,2 rublja. (približno danes). Treba je še določiti drugo stran ravnovesja v ekonomskem pravu. Razmišljal sem takole. Obstoječa napaka bo zahtevala, da se zadevna oseba potrudi, da jo popravi, to je lastnik nepremičnine. Recimo, da to zahteva 1 dan ukrepanja (oddaja vloge, prejem popravljenega dokumenta). Potem bodo s socialnega vidika njegovi stroški enaki povprečni plači na dan. Povprečna obračunana plača v avtonomnem okrožju Khanty-Mansi 73285 rubljev. ali 3053,542 rubljev/dan. V skladu s tem dobimo kritično vrednost, ki je enaka:
3053,542: 12,2 = 250,4 enot zapisov.
To z družbenega vidika pomeni, da če je tester preveril 251 zapisov in našel eno napako, je to enako, kot da bi uporabnik to napako popravil sam. V skladu s tem, če je tester porabil čas, ki je enak preverjanju 252 zapisov, da bi našel naslednjo napako, potem je v tem primeru bolje preložiti stroške popravka na uporabnika.
Tu je predstavljen poenostavljen pristop, saj je s socialnega vidika treba upoštevati vso dodatno vrednost, ki jo ustvari vsak specialist, torej stroške vključno z davki in socialnimi plačili, vendar je model jasen. Posledica tega razmerja je naslednja zahteva za strokovnjake: specialist iz IT industrije mora imeti plačo, ki je višja od državnega povprečja. Če je njegova plača nižja od povprečne plače potencialnih uporabnikov podatkovne baze, potem mora sam preveriti celotno bazo iz rok v roke.
Pri uporabi opisanega kriterija se oblikuje prva zahteva za kakovost baze podatkov:
I(tr). Delež kritičnih napak ne sme presegati 1/250,4 = 0,39938 %. Malo manj kot zlato v industriji. In fizično ni več kot 1459 zapisov z napakami.
Gospodarski umik.
Pravzaprav družba s tolikšnim številom napak v evidencah privoli v ekonomske izgube v višini:
1459 * 3053,542 = 4 455 118 rubljev.
Ta znesek je določen z dejstvom, da družba nima orodij za zmanjšanje teh stroškov. Iz tega sledi, da če ima nekdo tehnologijo, ki mu omogoča zmanjšanje števila zapisov z napakami na na primer 259, potem bo to družbi omogočilo prihranek:
1200 * 3053,542 = 3 664 250 rubljev.
Toda hkrati lahko za svoj talent in delo zahteva, no, recimo - 1 milijon rubljev.
To pomeni, da se socialni stroški zmanjšajo za:
3 664 250 – 1 000 000 = 2 664 250 rubljev.
V bistvu je ta učinek dodana vrednost uporabe tehnologij BigDat.
Toda tukaj je treba upoštevati, da je to družbeni učinek, lastnik baze podatkov pa so občinske oblasti, njihov dohodek od uporabe premoženja, zabeleženega v tej bazi podatkov, po stopnji 0,3% je: 2,778 milijarde rubljev / leto. In ti stroški (4 rubljev) ga ne motijo veliko, saj so preneseni na lastnike nepremičnin. In s tega vidika bo moral razvijalec bolj izpopolnjenih tehnologij v Bigdata pokazati sposobnost, da prepriča lastnika te baze podatkov, za take stvari pa je potreben precejšen talent.
V tem primeru je bil algoritem za oceno napak izbran na podlagi Schumannovega modela [2] preverjanja programske opreme med testiranjem zanesljivosti. Zaradi svoje razširjenosti na internetu in možnosti pridobivanja potrebnih statističnih kazalcev. Metodologija je vzeta iz Monakhova Yu.M. "Funkcionalna stabilnost informacijskih sistemov", glej pod spojlerjem na sliki. 7-9.
riž. 7 – 9 Metodologija Schumannovega modela
Drugi del tega gradiva predstavlja primer čiščenja podatkov, v katerem so pridobljeni rezultati uporabe Schumannovega modela.
Naj predstavim dobljene rezultate:
Ocenjeno število napak N = 3167 n.
Parameter C, lambda in funkcija zanesljivosti:
sl.17
V bistvu je lambda dejanski indikator intenzivnosti, s katero so napake odkrite na vsaki stopnji. Če pogledate drugi del, je bila ocena za ta kazalnik 42,4 napake na uro, kar je povsem primerljivo s Schumannovim kazalnikom. Zgoraj je bilo ugotovljeno, da hitrost, s katero razvijalec najde napake, ne sme biti nižja od 1 napake na 250,4 zapisa pri preverjanju 1 zapisa na minuto. Od tod kritična vrednost lambda za Schumannov model:
60 / 250,4 = 0,239617.
To pomeni, da je treba izvajati postopke odkrivanja napak, dokler se lambda z obstoječih 38,964 ne zmanjša na 0,239617.
Ali dokler se indikator N (potencialno število napak) minus n (popravljeno število napak) ne zmanjša pod naš sprejeti prag - 1459 kosov.
Literatura
- Monakhov, Yu M. Funkcionalna stabilnost informacijskih sistemov. V 3 urah 1. del Zanesljivost programske opreme: učbenik. dodatek / Yu. M. Monakhov; Vladim. država univ. – Vladimir: Izvo Vladim. država Univerza, 2011. – 60 str. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman, “Probabilistični modeli za napovedovanje zanesljivosti programske opreme.”
- Osnove skladiščenja podatkov za IT strokovnjake / Paulraj Ponniah.—2. izdaja.
Vir: www.habr.com