1. Početni podaci
Čišćenje podataka jedan je od izazova sa kojima se suočavaju zadaci analize podataka. Ovaj materijal odražava razvoj i rješenja koja su nastala kao rezultat rješavanja praktičnog problema analize baze podataka u formiranju katastarske vrijednosti. Izvori ovdje .
Razmatran je fajl “Uporedni model total.ods” u “Prilogu B. Rezultati utvrđivanja KS 5. Podaci o načinu utvrđivanja katastarske vrijednosti 5.1 Uporedni pristup”.
Tabela 1. Statistički pokazatelji skupa podataka u datoteci “Uporedni model total.ods”
Ukupan broj polja, kom. — 44
Ukupan broj zapisa, kom. — 365 490
Ukupan broj karaktera, kom. — 101 714 693
Prosječan broj znakova u zapisu, kom. — 278,297
Standardna devijacija znakova u zapisu, kom. — 15,510
Minimalni broj znakova u unosu, kom. — 198
Maksimalan broj znakova u unosu, kom. — 363
2. Uvodni dio. Osnovni standardi
Prilikom analize navedene baze podataka formiran je zadatak da se preciziraju zahtjevi za stepen prečišćavanja, jer, kao što je svima jasno, navedena baza stvara pravne i ekonomske posljedice za korisnike. Tokom rada pokazalo se da ne postoje posebni zahtjevi za stepen čišćenja velikih podataka. Analizirajući pravne norme u ovoj materiji, došao sam do zaključka da su sve formirane iz mogućnosti. Odnosno, pojavio se određeni zadatak, sastavljaju se izvori informacija za zadatak, zatim se formira skup podataka i na osnovu kreiranog skupa podataka alati za rješavanje problema. Rezultirajuća rješenja su referentne tačke u izboru između alternativa. To sam predstavio na slici 1.
Budući da je pri utvrđivanju bilo kakvih standarda poželjno osloniti se na dokazane tehnologije, izabrao sam zahtjeve navedene u , jer sam ovaj dokument smatrao najsveobuhvatnijim za ovo pitanje. Konkretno, u ovom dokumentu u odeljku stoji „Treba napomenuti da se zahtjevi za integritetom podataka podjednako primjenjuju na ručne (papirne) i elektronske podatke.“ (prevod: “...zahtjevi integriteta podataka jednako se primjenjuju na ručne (papirne) i elektronske podatke”). Ova formulacija je sasvim specifično povezana sa pojmom „pisanih dokaza“, u odredbama člana 71. Zakonika o parničnom postupku, čl. 70 CAS, član 75 APC, „u pisanoj formi” čl. 84 Zakonik o parničnom postupku.
Na slici 2 prikazan je dijagram formiranja pristupa vrstama informacija u jurisprudenciji.
Rice. 2. Izvor .
Slika 3 prikazuje mehanizam sa slike 1, za zadatke gore navedenog „Uputstva“. Lako je, poređenjem, vidjeti da su pristupi koji se koriste u ispunjavanju zahtjeva za integritetom informacija u savremenim standardima za informacione sisteme značajno ograničeni u odnosu na pravni koncept informacije.
Slika 3
U navedenom dokumentu (Uputstvu) povezanost sa tehničkim dijelom, mogućnostima za obradu i pohranjivanje podataka, dobro potvrđuje citat iz poglavlja 18.2. Relaciona baza podataka: "Ova struktura datoteke je sama po sebi sigurnija, jer se podaci drže u velikom formatu datoteke koji čuva odnos između podataka i metapodataka."
Zapravo, u ovom pristupu – od postojećih tehničkih mogućnosti, nema ničeg nenormalnog i, sam po sebi, ovo je prirodan proces, budući da proširenje pojmova dolazi iz najproučavanije aktivnosti – dizajna baze podataka. Ali, s druge strane, pojavljuju se zakonske norme koje ne predviđaju popuste na tehničke mogućnosti postojećih sistema, na primjer: .
Rice. 4. Lijevak tehničkih mogućnosti ().
U ovim aspektima postaje jasno da će originalni skup podataka (slika 1) morati, prije svega, biti sačuvan, a drugo, biti osnova za izdvajanje dodatnih informacija iz njega. Pa, kao primjer: kamere koje snimaju saobraćajna pravila su sveprisutne, sistemi za obradu informacija uklanjaju prekršioce, ali i druge informacije se mogu ponuditi drugim potrošačima, na primjer, kao marketinško praćenje strukture protoka kupaca u trgovački centar. A ovo je izvor dodatne dodane vrijednosti kada se koristi BigDat. Sasvim je moguće da će skupovi podataka koji se sada prikupljaju, negdje u budućnosti, imati vrijednost prema mehanizmu sličnom vrijednosti rijetkih izdanja od 1700. u sadašnje vrijeme. Uostalom, u stvari, privremeni skupovi podataka su jedinstveni i malo je vjerovatno da će se ponoviti u budućnosti.
3. Uvodni dio. Kriterijumi ocjenjivanja
Tokom procesa obrade razvijena je sljedeća klasifikacija grešaka.
1. Klasa greške (na osnovu GOST R 8.736-2011): a) sistematske greške; b) slučajne greške; c) greška.
2. Po višestrukosti: a) mono distorzija; b) višestruko izobličenje.
3. Prema kritičnosti posljedica: a) kritične; b) nije kritičan.
4. Po izvoru pojave:
A) Tehničke – greške koje se javljaju tokom rada opreme. Prilično relevantna greška za IoT sisteme, sisteme sa značajnim stepenom uticaja na kvalitet komunikacije, opremu (hardver).
B) Greške operatera - greške u širokom rasponu od grešaka u kucanju operatera tokom unosa do grešaka u tehničkim specifikacijama za dizajn baze podataka.
C) Korisničke greške - evo korisničkih grešaka u cijelom rasponu od “zaboravio sam promijeniti izgled” do pogrešnog broja metara za noge.
5. Odvojeni u posebnu klasu:
a) “zadatak separatora”, odnosno razmak i “:” (u našem slučaju) kada je dupliran;
b) riječi napisane zajedno;
c) bez razmaka nakon uslužnih znakova
d) simetrično više simbola: (), "", "...".
Zajedno, sa sistematizacijom grešaka baze podataka prikazanom na slici 5, formiran je prilično efikasan koordinatni sistem za traženje grešaka i razvoj algoritma za čišćenje podataka za ovaj primjer.
Rice. 5. Tipične greške koje odgovaraju strukturnim jedinicama baze podataka (Izvor: ).
Preciznost, integritet domena, tip podataka, konzistentnost, redundantnost, kompletnost, dupliciranje, usklađenost sa poslovnim pravilima, strukturna određenost, anomalija podataka, jasnoća, blagovremenost, poštovanje pravila integriteta podataka. (Stranica 334. Osnove skladištenja podataka za IT profesionalce / Paulraj Ponniah.—2. izdanje.)
Predstavljen engleski tekst i ruski mašinski prevod u zagradama.
Preciznost. Vrijednost pohranjena u sistemu za element podataka je prava vrijednost za to pojavljivanje elementa podataka. Ako imate ime kupca i adresu pohranjenu u zapisu, tada je adresa ispravna adresa za kupca s tim imenom. Ako nađete naručenu količinu kao 1000 jedinica u zapisu za broj narudžbe 12345678, tada je ta količina tačna količina za tu narudžbu.
[Preciznost. Vrijednost pohranjena u sistemu za element podataka je ispravna vrijednost za to pojavljivanje elementa podataka. Ako imate ime klijenta i adresu pohranjenu u zapisu, tada je adresa ispravna adresa za kupca s tim imenom. Ako nađete naručenu količinu kao 1000 jedinica u zapisu za broj narudžbe 12345678, tada je ta količina tačna količina za tu narudžbu.]
Integritet domena. Vrijednost podataka atributa spada u raspon dozvoljenih, definiranih vrijednosti. Uobičajeni primjer su dozvoljene vrijednosti „muško“ i „žensko“ za element podataka o spolu.
[Integritet domena. Vrijednost podataka atributa spada u raspon valjanih, definiranih vrijednosti. Opći primjer su važeće vrijednosti "muško" i "žensko" za element podataka o spolu.]
Tip podataka. Vrijednost za atribut podataka je zapravo pohranjena kao tip podataka definiran za taj atribut. Kada je tip podataka polja imena prodavnice definisan kao „tekst“, sve instance tog polja sadrže naziv prodavnice prikazan u tekstualnom formatu, a ne u numeričkim kodovima.
[Tip podataka. Vrijednost atributa podataka je zapravo pohranjena kao tip podataka definiran za taj atribut. Ako je tip podataka polja naziva trgovine definiran kao "tekst", sve instance ovog polja sadrže naziv trgovine prikazan u tekstualnom formatu, a ne u numeričkim kodovima.]
Dosljednost. Oblik i sadržaj polja podataka isti su u višestrukim izvornim sistemima. Ako je kod proizvoda za proizvod ABC u jednom sistemu 1234, tada je kod za ovaj proizvod 1234 u svakom izvornom sistemu.
[Dosljednost. Forma i sadržaj polja podataka su isti u različitim izvornim sistemima. Ako je kod proizvoda za proizvod ABC na jednom sistemu 1234, onda je kod za taj proizvod 1234 na svakom izvornom sistemu.]
Redundantnost. Isti podaci ne smiju biti pohranjeni na više od jednog mjesta u sistemu. Ako je, iz razloga efikasnosti, element podataka namjerno pohranjen na više od jednog mjesta u sistemu, onda se redundantnost mora jasno identificirati i provjeriti.
[Redundancy. Isti podaci ne bi trebali biti pohranjeni na više od jednog mjesta u sistemu. Ako je, iz razloga efikasnosti, element podataka namjerno pohranjen na više lokacija u sistemu, redundantnost mora biti jasno definirana i provjerena.]
Kompletnost. Ne postoje vrijednosti koje nedostaju za dati atribut u sistemu. Na primjer, u datoteci klijenta mora postojati važeća vrijednost za polje „stanje“ za svakog kupca. U datoteci za detalje narudžbe svaki detaljni zapis za narudžbu mora biti u potpunosti popunjen.
[Kompletnost. U sistemu ne postoje vrijednosti koje nedostaju za ovaj atribut. Na primjer, datoteka klijenta mora imati valjanu vrijednost za polje "status" za svakog klijenta. U datoteci detalja narudžbe svaki zapis detalja o narudžbi mora biti u potpunosti popunjen.]
Dupliciranje. Dupliranje zapisa u sistemu je potpuno riješeno. Ako je poznato da datoteka proizvoda ima duple zapise, tada se identificiraju svi duplikati za svaki proizvod i kreira se unakrsna referenca.
[Duplicate. Dupliranje zapisa u sistemu je potpuno eliminisano. Ako je poznato da datoteka proizvoda sadrži duple unose, tada se identificiraju svi duplikati za svaki proizvod i kreira se unakrsna referenca.]
Usklađenost sa poslovnim pravilima. Vrijednosti svake stavke podataka su u skladu sa propisanim poslovnim pravilima. U sistemu aukcije, cijena čekića ili prodajna cijena ne može biti manja od rezervne cijene. U sistemu bankarskih kredita, stanje kredita mora uvijek biti pozitivno ili nula.
[Poštivanje poslovnih pravila. Vrijednosti svakog elementa podataka su u skladu s utvrđenim poslovnim pravilima. U sistemu aukcije, cijena čekića ili prodajna cijena ne može biti manja od rezervne cijene. U bankarskom kreditnom sistemu, saldo zajma mora uvijek biti pozitivan ili nula.]
Strukturalna određenost. Gdje god se stavka podataka može prirodno strukturirati u pojedinačne komponente, stavka mora sadržavati ovu dobro definiranu strukturu. Na primjer, ime pojedinca se prirodno dijeli na ime, srednje slovo i prezime. Vrijednosti za imena pojedinaca moraju biti pohranjene kao ime, srednje slovo i prezime. Ova karakteristika kvaliteta podataka pojednostavljuje primjenu standarda i smanjuje vrijednosti koje nedostaju.
[Structural Certainty. Tamo gdje se element podataka može prirodno strukturirati u pojedinačne komponente, element mora sadržavati ovu dobro definiranu strukturu. Na primjer, ime osobe se prirodno dijeli na ime, srednje slovo i prezime. Vrijednosti za pojedinačna imena trebaju biti pohranjene kao ime, srednje slovo i prezime. Ova karakteristika kvaliteta podataka pojednostavljuje primjenu standarda i smanjuje vrijednosti koje nedostaju.]
Anomalija podataka. Polje se mora koristiti samo u svrhu za koju je definirano. Ako je polje Adresa-3 definisano za bilo koju moguću treću liniju adrese za dugačke adrese, onda se ovo polje mora koristiti samo za zapis treće linije adrese. Ne smije se koristiti za unos broja telefona ili faksa za kupca.
[Data Anomaly. Polje se smije koristiti samo u svrhu za koju je definirano. Ako je polje Adresa-3 definirano za bilo koju moguću treću adresnu liniju za duge adrese, onda će se ovo polje koristiti samo za zapis treće adresne linije. Ne treba ga koristiti za unos broja telefona ili faksa za kupca.]
Jasnoća. Element podataka može posjedovati sve druge karakteristike kvalitetnih podataka, ali ako korisnici ne razumiju jasno njegovo značenje, onda element podataka nema nikakvu vrijednost za korisnike. Pravilne konvencije o imenovanju pomažu da se elementi podataka dobro razumiju od strane korisnika.
[Jasnoća. Element podataka može imati sve ostale karakteristike dobrih podataka, ali ako korisnici ne razumiju jasno njegovo značenje, onda element podataka nema nikakvu vrijednost za korisnike. Ispravne konvencije o imenovanju pomažu da korisnici dobro razumiju elemente podataka.]
Pravovremeno. Korisnici određuju ažurnost podataka. Ako korisnici očekuju da podaci dimenzije korisnika ne budu stariji od jednog dana, promjene podataka o klijentima u izvornim sistemima moraju se svakodnevno primjenjivati na skladište podataka.
[Blagovremeno. Korisnici određuju ažurnost podataka. Ako korisnici očekuju da podaci dimenzije korisnika nisu stariji od jednog dana, promjene podataka o klijentima u izvornim sistemima trebale bi se primjenjivati na skladištu podataka na dnevnoj bazi.]
Korisnost. Svaki element podataka u skladištu podataka mora zadovoljiti neke zahtjeve zbirke korisnika. Element podataka može biti tačan i kvalitetan, ali ako nema nikakvu vrijednost za korisnike, onda je potpuno nepotrebno da se taj element podataka nalazi u skladištu podataka.
[Utility. Svaka stavka podataka u skladištu podataka mora zadovoljiti neke zahtjeve korisničke zbirke. Element podataka može biti tačan i visokog kvaliteta, ali ako ne pruža vrijednost korisnicima, onda nije neophodno da taj element podataka bude u skladištu podataka.]
Poštivanje pravila o integritetu podataka. Podaci pohranjeni u relacijskim bazama podataka izvornih sistema moraju se pridržavati pravila integriteta entiteta i referentnog integriteta. Svaka tabela koja dozvoljava null kao primarni ključ nema integritet entiteta. Referentni integritet forsira pravilno uspostavljanje odnosa roditelj-dijete. U odnosu od kupca do narudžbe, referentni integritet osigurava postojanje kupca za svaku narudžbu u bazi podataka.
[Poštivanje pravila integriteta podataka. Podaci pohranjeni u relacijskim bazama podataka izvornih sistema moraju biti u skladu s pravilima integriteta entiteta i referentnog integriteta. Bilo koja tabela koja dozvoljava null kao primarni ključ nema integritet entiteta. Referentni integritet tjera da se odnos između roditelja i djece uspostavi ispravno. U odnosu kupac-narudžba, referentni integritet osigurava postojanje kupca za svaku narudžbu u bazi podataka.]
4. Kvaliteta čišćenja podataka
Kvaliteta čišćenja podataka prilično je problematično pitanje u velikim podacima. Odgovor na pitanje koji stepen čišćenja podataka je neophodan da bi se izvršio zadatak je fundamentalno za svakog analitičara podataka. U većini aktuelnih problema, svaki analitičar to sam utvrđuje i malo je verovatno da će neko spolja moći da proceni ovaj aspekt u njegovom rešenju. Ali za zadatak koji je u ovom slučaju u pitanju, ovo pitanje je bilo izuzetno važno, jer pouzdanost pravnih podataka treba težiti jednom.
Razmatranje tehnologija testiranja softvera za određivanje operativne pouzdanosti. Danas postoji više od ovih modela . Mnogi modeli koriste model servisiranja zahtjeva:
Fig. 6
Razmišljajući na sljedeći način: "Ako je pronađena greška događaj sličan događaju kvara u ovom modelu, kako onda pronaći analog parametra t?" I sastavio sam sljedeći model: Zamislimo da je vrijeme koje je testeru potrebno da provjeri jedan zapis 1 minut (za dotičnu bazu podataka), a zatim će mu za pronalaženje svih grešaka trebati 365 minuta, što je otprilike 494 godine i 3 mjeseci radnog vremena. Kako razumijemo, radi se o veoma velikom obimu posla i troškovi provjere baze podataka će biti previsoki za kompajlera ove baze podataka. U ovom promišljanju pojavljuje se ekonomski koncept troškova i nakon analize došao sam do zaključka da je ovo prilično efikasan alat. Na osnovu zakona ekonomije: „Obim proizvodnje (u jedinicama) pri kojem se postiže maksimalni profit firme nalazi se na tački gdje se granični trošak proizvodnje nove jedinice proizvoda upoređuje sa cijenom koju ova firma može dobiti za novu jedinicu.” Na osnovu postulata da pronalaženje svake sljedeće greške zahtijeva sve više i više provjeravanja zapisa, ovo je faktor troškova. Odnosno, postulat usvojen u testiranju modela poprima fizičko značenje u sljedećem obrascu: ako je za pronalaženje i-te greške bilo potrebno provjeriti n zapisa, tada će biti potrebno pronaći sljedeću (i+3) grešku provjeriti m zapisa i istovremeno n
- Kada se broj proverenih zapisa pre nego što se pronađe nova greška stabilizuje;
- Kada će se povećati broj zapisa provjerenih prije pronalaženja sljedeće greške.
Da bih odredio kritičnu vrijednost, okrenuo sam se konceptu ekonomske izvodljivosti, koji se u ovom slučaju, koristeći koncept društvenih troškova, može formulirati na sljedeći način: „Troškove ispravljanja greške treba snositi ekonomski subjekt koji može učiniti to po najnižoj cijeni.” Imamo jednog agenta - testera koji provede 1 minut proveravajući jedan zapis. U novčanom smislu, ako zarađujete 6000 rubalja dnevno, to će biti 12,2 rubalja. (otprilike danas). Ostaje da se utvrdi druga strana ravnoteže u ekonomskom pravu. Rezonovao sam ovako. Postojeća greška će zahtijevati od dotične osobe da uloži napore da je ispravi, odnosno od vlasnika nekretnine. Recimo da je za to potreban 1 dan radnje (podnošenje prijave, primanje ispravljenog dokumenta). Tada će, sa socijalne tačke gledišta, njegovi troškovi biti jednaki prosječnoj dnevnoj plati. Prosječna obračunata plata u Khanty-Mansijskom autonomnom okrugu 73285 rub. ili 3053,542 rubalja/dan. U skladu s tim, dobijamo kritičnu vrijednost jednaku:
3053,542: 12,2 = 250,4 jedinice zapisa.
To znači, sa društvene tačke gledišta, ako je tester provjerio 251 zapis i otkrio jednu grešku, to je jednako da korisnik sam ispravi ovu grešku. U skladu s tim, ako je tester potrošio vrijeme jednako provjeri 252 zapisa kako bi pronašao sljedeću grešku, onda je u ovom slučaju bolje prebaciti troškove ispravke na korisnika.
Ovdje je predstavljen pojednostavljen pristup, budući da je sa socijalnog gledišta potrebno uzeti u obzir svu dodatnu vrijednost koju generiše svaki specijalista, odnosno troškove uključujući poreze i socijalna davanja, ali model je jasan. Posljedica ovakvog odnosa je sljedeći zahtjev za specijalistima: specijalista iz IT industrije mora imati platu veću od nacionalnog prosjeka. Ako je njegova plata manja od prosječne plate potencijalnih korisnika baze podataka, onda on sam mora ručno provjeriti cijelu bazu podataka.
Pri korištenju opisanog kriterija formira se prvi zahtjev za kvalitetom baze podataka:
I(tr). Udio kritičnih grešaka ne bi trebao biti veći od 1/250,4 = 0,39938%. Malo manje od zlato u industriji. A u fizičkom smislu nema više od 1459 zapisa sa greškama.
Ekonomsko povlačenje.
U stvari, čineći toliki broj grešaka u evidenciji, društvo pristaje na ekonomske gubitke u iznosu od:
1459*3053,542 = 4 rubalja.
Ovaj iznos je određen činjenicom da društvo nema alate za smanjenje ovih troškova. Iz toga slijedi da ako neko ima tehnologiju koja mu omogućava da smanji broj zapisa s greškama na, na primjer, 259, onda će to omogućiti društvu da uštedi:
1200*3053,542 = 3 rubalja.
Ali u isto vrijeme, on može tražiti svoj talenat i rad, pa, recimo - 1 milion rubalja.
Odnosno, socijalni troškovi se smanjuju za:
3 – 664 = 250 rubalja.
U suštini, ovaj efekat je dodatna vrednost od upotrebe BigDat tehnologija.
Ali ovdje treba uzeti u obzir da se radi o društvenom efektu, a vlasnik baze su općinske vlasti, njihov prihod od korištenja imovine evidentirane u ovoj bazi podataka, po stopi od 0,3%, iznosi: 2,778 milijardi rubalja/ godine. A ovi troškovi (4 rubalja) mu ne smetaju mnogo, jer se prenose na vlasnike imovine. I, u ovom aspektu, programer naprednijih tehnologija u Bigdata moraće pokazati sposobnost da ubijedi vlasnika ove baze podataka, a za takve stvari je potreban znatan talenat.
U ovom primjeru, algoritam za procjenu greške odabran je na osnovu Schumannovog modela [2] verifikacije softvera tokom testiranja pouzdanosti. Zbog svoje rasprostranjenosti na Internetu i mogućnosti dobijanja potrebnih statističkih pokazatelja. Metodologija je preuzeta od Monakhov Yu.M. „Funkcionalna stabilnost informacionih sistema“, vidi ispod spojlera na sl. 7-9.
Rice. 7 – 9 Metodologija Šumanovog modela
Drugi dio ovog materijala predstavlja primjer čišćenja podataka u kojem se dobijaju rezultati primjenom Schumannovog modela.
Dozvolite mi da vam predstavim dobijene rezultate:
Procijenjeni broj grešaka N = 3167 n.
Parametar C, lambda i funkcija pouzdanosti:
Slika 17
U suštini, lambda je stvarni pokazatelj intenziteta s kojim se greške otkrivaju u svakoj fazi. Ako pogledate drugi dio, procjena za ovaj indikator je bila 42,4 greške na sat, što je prilično uporedivo sa Schumanovim indikatorom. Iznad je utvrđeno da stopa po kojoj programer pronalazi greške ne smije biti niža od 1 greške na 250,4 zapisa, kada se provjerava 1 zapis u minuti. Otuda kritična vrijednost lambde za Schumannov model:
60 / 250,4 = 0,239617.
Odnosno, potreba za provođenjem procedura detekcije grešaka mora se provoditi sve dok se lambda, sa postojećih 38,964, ne smanji na 0,239617.
Ili dok indikator N (potencijalni broj grešaka) minus n (ispravljeni broj grešaka) ne padne ispod našeg prihvaćenog praga - 1459 kom.
Literatura
- Monakhov, Yu. M. Funkcionalna stabilnost informacionih sistema. U 3 sata Dio 1. Pouzdanost softvera: udžbenik. dodatak / Yu. M. Monakhov; Vladim. stanje univ. – Vladimir: Izvo Vladim. stanje Univerzitet, 2011. – 60 str. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman, “Probabilistički modeli za predviđanje pouzdanosti softvera.”
- Osnove skladištenja podataka za IT profesionalce / Paulraj Ponniah.—2. izd.
izvor: www.habr.com