1. Indledende data
Datarensning er en af de udfordringer, som dataanalyse står over for. I dette materiale afspejlede han udviklingen, løsninger, der opstod som følge af at løse det praktiske problem med at analysere databasen i dannelsen af matrikelværdien. Kilder her .
Filen "Komparativ model total.ods" blev behandlet i "Bilag B. Resultater af fastsættelse af COP 5. Oplysninger om metoden til bestemmelse af matrikelværdien 5.1 Sammenlignende tilgang".
Tabel 1. Statistiske indikatorer for datasættet i filen "Komparativ model total.ods"
Samlet antal felter, stk. - 44
Samlet antal poster, stk. — 365 490
Samlet antal tegn, stk. — 101 714 693
Gennemsnitligt antal tegn i en post, stk. — 278,297
Standardafvigelse af tegn i posten, stk. — 15,510
Minimum antal tegn i en post, stk. — 198
Maksimalt antal tegn i en post, stk. — 363
2. Introduktion. Grundlæggende normer
Under analyse af denne database blev der dannet en opgave for at specificere kravene til oprensningsgraden, da det er klart for enhver, at den specificerede database genererer juridiske og økonomiske konsekvenser for brugerne. Under arbejdet viste det sig, at der ikke var særlige krav til graden af oprensning af big data. Ved at analysere de juridiske normer i denne sag kom jeg til den konklusion, at de alle er dannet ud fra muligheder. Det vil sige, at en bestemt opgave er dukket op, informationskilder udfyldes til opgaven, derefter dannes et datasæt og ud fra det oprettede datasæt værktøjer til at løse opgaven. De resulterende løsninger er referencepunkter i valget af alternativer. Repræsenteret dette i figur 1.
Da det i spørgsmål om fastlæggelse af eventuelle normer er at foretrække at stole på gennemprøvede teknologier, valgte jeg som grundlag for analysekriterierne de krav, der er opstillet i , fordi jeg betragtede dette dokument som det mest komplette til dette problem. Især i dette dokument står der i afsnittet "Det skal bemærkes, at dataintegritetskrav gælder både for manuelle (papir) og elektroniske data." (oversættelse "...krav til dataintegritet gælder både for manuelle (papir) og elektroniske data"). En sådan formulering er helt specifikt forbundet med begrebet "skriftligt bevis", i normerne i artikel 71 i den civile retsplejelov, art. 70 CAS, art 75 APC, "skriftligt" Art. 84 den civile retsplejelov.
I figur 2 præsenterede han et skema for dannelsen af tilgange til informationstyperne i retspraksis.
Ris. 2. Kilde .
Figur 3 viser mekanismen i figur 1 til opgaverne i ovenstående "vejledning". Det er ikke svært at foretage en sammenligning og se, at de tilgange, der anvendes, når kravene til informationsintegritet opfyldes, i moderne standarder for informationssystemer, er væsentligt begrænsede i forhold til det juridiske informationsbegreb.
Fig. 3
I det angivne dokument (Vejledning) bekræftes bindingen til den tekniske del, mulighederne for behandling og lagring af data, godt af et citat fra kapitel 18.2. Relationel database: "Denne filstruktur er i sagens natur mere sikker, da data opbevares i et stort filformat, som bevarer forholdet mellem data og metadata."
Faktisk er der i denne tilgang - fra eksisterende tekniske muligheder, intet unormalt, og i sig selv er dette en naturlig proces, da udvidelsen af koncepter kommer fra den mest undersøgte aktivitet - databasedesign. Men på den anden side dukker der juridiske normer op, som ikke giver mulighed for rabatter på eksisterende systemers tekniske muligheder, for eksempel: .
Ris. 4. Tragt med tekniske muligheder ().
I disse aspekter bliver det klart, at det oprindelige datasæt (fig. 1) først og fremmest skal bevares, og for det andet skal være grundlaget for at udtrække yderligere information fra det. Tja, som et eksempel: kameraer til fastsættelse af trafikregler er allestedsnærværende, informationsbehandlingssystemer luger fra overtrædere, men resten af informationen kan også tilbydes andre forbrugere, for eksempel som markedsføringsovervågning af strukturen i kundestrømmen til et indkøbscenter. Og dette er en kilde til yderligere merværdi ved brug af Bigdata. Det er ganske muligt at antage, at de datasæt, der i øjeblikket indsamles, et sted i fremtiden, vil have en værdi svarende til værdien af sjældne publikationer fra 1700-tallet på nuværende tidspunkt. Når alt kommer til alt, er midlertidige datasæt faktisk unikke og vil næppe blive gentaget i fremtiden.
3. Introduktion. Evalueringskriterie
Under behandlingen blev følgende klassifikation af fejl udviklet.
1. Fejlklasse (GOST R 8.736-2011 tages som grundlag): a) systematiske fejl; b) tilfældige fejl; c) en stor fejl.
2. Ved multiplicitet: a) monoforvrængning; b) multiforvrængning.
3. Alt efter hvor kritiske konsekvenserne er: a) kritiske; b) ikke kritisk.
4. Ifølge kilden til hændelsen:
A) Teknisk - fejl, der opstår under driften af udstyret. En ret relevant fejl for IoT-systemer, systemer med en betydelig grad af indflydelse på kvaliteten af kommunikation, udstyr (hardware).
B) Operatørfejl - fejl i en bred vifte fra en operatørs tastefejl ved indtastning til fejl i kommissoriet for design af databasen.
C) Brugerdefineret - der er brugerfejl i hele området fra "glemte at skifte layout" til at tage fejl af meter for fødder.
5. Opdelt i en separat klasse:
a) "afgrænseropgave", det vil sige et mellemrum og ":" (i vores tilfælde), når den blev duplikeret;
b) fællesskrevne ord;
c) intet mellemrum efter servicetegn
d) symmetrisk flertalssymboler: (), "", "...".
Sammen med systematiseringen af databasefejl præsenteret i figur 5, dannes et ret effektivt koordinatsystem til at søge efter fejl og udvikle en algoritme til at rense data, til dette eksempel.
Ris. 5. Typiske fejl svarende til databasens strukturelle enheder (Kilde: ).
Nøjagtighed, domæneintegritet, datatype, konsistens, redundans, fuldstændighed, duplikering, overensstemmelse med forretningsregler, strukturel bestemthed (strukturel sikkerhed), dataanomali (dataanomali), klarhed (klarhed), rettidig (rettidig), overholdelse af dataintegritetsregler (Overholdelse af dataintegritetsregler). (S. 334. Grundlæggende data warehousing for IT-professionelle / Paulraj Ponniah.-2. udg.)
Indført engelsk formulering og russisk maskinoversættelse i parentes.
Nøjagtighed. Værdien gemt i systemet for et dataelement er den rigtige værdi for den forekomst af dataelementet. Hvis du har et kundenavn og en adresse gemt i en post, så er adressen den korrekte adresse for kunden med det navn. Hvis du finder den bestilte mængde som 1000 enheder i posten for ordrenummer 12345678, så er denne mængde den nøjagtige mængde for den ordre.
[Nøjagtighed. Den værdi, der er lagret i systemet for dataelementet, er den korrekte værdi for den forekomst af dataelementet. Hvis du har et kundenavn og en adresse gemt i en post, så er adressen den korrekte adresse for kunden med det navn. Hvis du finder den bestilte mængde som 1000 enheder i posten for ordrenummer 12345678, så er den mængde den nøjagtige mængde for den ordre.]
domæneintegritet. Dataværdien for en attribut falder inden for intervallet af tilladte, definerede værdier. Det almindelige eksempel er, at de tilladte værdier er "mand" og "kvinde" for kønsdataelementet.
[Domæneintegritet. Attributtens dataværdi falder inden for intervallet af gyldige, definerede værdier. Et almindeligt eksempel er de gyldige værdier "male" og "female" for et kønsdataelement.]
datatype. Værdien for en dataattribut gemmes faktisk som den datatype, der er defineret for den pågældende attribut. Når datatypen for butiksnavnsfeltet er defineret som "tekst", indeholder alle forekomster af dette felt butiksnavnet vist i tekstformat og ikke numeriske koder.
[Datatype. Værdien af en dataattribut gemmes faktisk som den datatype, der er defineret for den pågældende attribut. Hvis datatypen butiksnavnsfelt er defineret som 'tekst', indeholder alle forekomster af dette felt butiksnavnet vist i tekstformat i stedet for numeriske koder.]
Konsistens. Formen og indholdet af et datafelt er den samme på tværs af flere kildesystemer. Hvis produktkoden for produkt ABC i et system er 1234, så er koden for dette produkt 1234 i hvert kildesystem.
[Konsistens. Formen og indholdet af datafeltet er det samme i forskellige kildesystemer. Hvis produktkoden for produkt ABC på ét system er 1234, så er koden for det pågældende produkt 1234 på hvert kildesystem.]
redundans. De samme data må ikke opbevares mere end ét sted i et system. Hvis et dataelement af effektivitetshensyn bevidst lagres mere end ét sted i et system, skal redundansen tydeligt identificeres og verificeres.
[Redundans. De samme data bør ikke opbevares mere end ét sted i systemet. Hvis et dataelement af effektivitetshensyn bevidst lagres på mere end ét sted i systemet, skal redundans defineres klart og verificeres.]
fuldstændighed. Der mangler ingen værdier for en given attribut i systemet. For eksempel skal der i en kundefil være en gyldig værdi for "state"-feltet for hver kunde. I filen for ordredetaljer skal hver detaljepost for en ordre være fuldstændigt udfyldt.
[Fuldstændighed. Der mangler ingen værdier i systemet for denne attribut. For eksempel skal der i en klientfil være en gyldig værdi for "state"-feltet for hver klient. I ordredetaljer-filen skal hver ordreoplysninger udfyldes fuldstændigt.]
duplikering. Duplikering af poster i et system er fuldstændig løst. Hvis produktfilen vides at have duplikerede poster, identificeres alle dubletposter for hvert produkt, og der oprettes en krydsreference.
[Duplikere. Duplikering af registreringer i systemet er fuldstændig elimineret. Hvis en produktfil vides at indeholde duplikerede poster, identificeres alle duplikerede poster for hvert produkt, og der oprettes en krydsreference.]
Overholdelse af forretningsregler. Værdierne for hvert dataelement overholder foreskrevne forretningsregler. I et auktionssystem må hammerslags- eller salgsprisen ikke være mindre end minimumsprisen. I et banklånssystem skal lånesaldoen altid være positiv eller nul.
[Overholdelse af forretningsregler. Værdierne af hvert dataelement svarer til de etablerede forretningsregler. I et auktionssystem må hammerslags- eller salgsprisen ikke være mindre end minimumsprisen. I et bankkreditsystem skal kreditsaldoen altid være positiv eller nul.]
Strukturel bestemthed. Hvor et dataelement naturligt kan struktureres i individuelle komponenter, skal elementet indeholde denne veldefinerede struktur. For eksempel opdeles en persons navn naturligt i fornavn, mellemforbogstav og efternavn. Værdier for navne på personer skal gemmes som fornavn, mellembogstav og efternavn. Denne egenskab ved datakvalitet forenkler håndhævelsen af standarder og reducerer manglende værdier.
[Strukturel sikkerhed. Hvor et dataelement naturligt kan struktureres i individuelle komponenter, bør elementet indeholde denne veldefinerede struktur. For eksempel er en persons fornavn naturligt opdelt i fornavn, mellembogstav og efternavn. Værdier for individuelle navne skal gemmes som fornavn, mellembogstav og efternavn. Denne datakvalitetsfunktion forenkler anvendelsen af standarder og reducerer manglende værdier.]
data anomali. Et felt må kun bruges til det formål, det er defineret til. Hvis feltet Adresse-3 er defineret for en eventuel tredje adresselinje for lange adresser, skal dette felt kun bruges til registrering af den tredje adresselinje. Den må ikke bruges til at indtaste et telefon- eller faxnummer for kunden.
[Data-anomali. Feltet bør kun bruges til det formål, det er defineret til. Hvis feltet Adresse-3 er defineret for en eventuel tredje adresselinje for lange adresser, skal dette felt kun bruges til at registrere den tredje adresselinje. Det bør ikke bruges til at indtaste et telefon- eller faxnummer for en kunde.]
Klarhed. Et dataelement kan have alle de andre karakteristika ved kvalitetsdata, men hvis brugerne ikke forstår dets betydning klart, så er dataelementet uden værdi for brugerne. Korrekte navnekonventioner er med til at gøre dataelementerne godt forståede af brugerne.
[Klarhed. Et dataelement kan have alle de andre karakteristika af kvalitative data, men hvis brugerne ikke klart forstår dets betydning, så er dataelementet uden værdi for brugerne. Korrekte navngivningskonventioner hjælper med at gøre dataelementer nemme at forstå for brugerne.]
rettidigt. Brugerne bestemmer tidslinjerne for dataene. Hvis brugerne forventer, at kundedimensionsdata ikke er ældre end én dag, skal ændringerne af kundedata i kildesystemerne påføres datavarehuset dagligt.
[I rette tid. Brugerne bestemmer dataens aktualitet. hvis brugere forventer, at kundemålingsdata ikke er ældre end én dag, bør ændringer af kundedata i kildesystemer anvendes på datavarehuset på daglig basis.]
Nytte. Hvert dataelement i datavarehuset skal opfylde nogle krav til indsamling af brugere. Et dataelement kan være nøjagtigt og af høj kvalitet, men hvis det ikke har nogen værdi for brugerne, så er det totalt unødvendigt, at det dataelement er i datavarehuset.
[Utility. Hvert dataelement i datalageret skal opfylde nogle krav til brugerindsamlingen. Et dataelement kan være nøjagtigt og af høj kvalitet, men hvis det ikke har nogen værdi for brugerne, er det ikke nødvendigt, at dataelementet er i datalageret.]
Overholdelse af dataintegritetsregler. De data, der er lagret i kildesystemernes relationelle databaser, skal overholde reglerne for entitetsintegritet og referenceintegritet. Enhver tabel, der tillader null som den primære nøgle, har ikke entitetsintegritet. Referentiel integritet fremtvinger etableringen af forældre-barn-relationerne korrekt. I et kunde-til-ordre forhold sikrer referentiel integritet eksistensen af en kunde for hver ordre i databasen.
[Overholdelse af regler for dataintegritet. Data lagret i relationelle databaser for kildesystemer skal overholde reglerne for enhedsintegritet og referenceintegritet. Enhver tabel, der tillader null som en primær nøgle, har ikke entitetsintegritet. Referenceintegritet håndhæver det korrekte forhold mellem forældre og børn. I et kundeordreforhold sikrer referenceintegritet, at der findes en kunde for hver ordre i databasen.]
4. Kvalitet af datarensning
Kvaliteten af datarensning er et ret problematisk problem i bigdata. For at besvare spørgsmålet, hvilken grad af datarensning er nødvendig for at fuldføre opgaven, er den vigtigste for hver dataanalytiker. I de fleste aktuelle opgaver sætter hver analytiker dette selv, og det er usandsynligt, at nogen udefra er i stand til at vurdere dette aspekt i sin løsning. Men for opgaven i dette tilfælde var dette spørgsmål ekstremt vigtigt, da pålideligheden af juridiske data burde have en tendens til enhed.
Overvejelse af softwaretestteknologier til bestemmelse af driftssikkerhed. Disse modeller er i øjeblikket flere . Mange af modellerne bruger kravservicemodellen:
Fig. 6
Tænker sådan: "Hvis den fundne fejl er en hændelse, der ligner fejlhændelsen i denne model, hvordan finder man så en analog af parameteren t?" Og jeg lavede følgende model: Forestil dig, at den tid, det tager for en tester at tjekke en post, er 1 minut (for den pågældende database), så vil det tage ham 365 minutter at finde alle fejlene, hvilket er cirka 494 år og 3 måneders arbejdstid. Som vi forstår, er dette ikke en meget lille mængde arbejde, og omkostningerne ved at kontrollere databasen vil være uudholdelige for compileren af denne database. I denne refleksion dukker det økonomiske begreb om omkostninger op, og efter analyse kom jeg til den konklusion, at dette er et ret effektivt værktøj. Baseret på loven om økonomi: "Mængden af produktion (i enheder), hvor virksomhedens maksimale profit opnås, er på det punkt, hvor marginalomkostningerne ved at producere en ny outputenhed sammenlignes med den pris, som denne virksomhed kan modtage for en ny enhed.” Baseret på postulatet om, at det at finde hver efterfølgende fejl kræver mere og mere kontrol af registreringer, så er dette omkostningsfaktoren. Det vil sige, at postulatet, der er accepteret i testmodellerne, har en fysisk betydning i følgende mønster: hvis det for at finde den i-te fejl var nødvendigt at kontrollere n poster, så for at finde den næste (i + 3) fejl, vil det allerede være nødvendigt at kontrollere m poster og samtidig n
- Når antallet af kontrollerede poster, før man finder en ny fejl, stabiliserer sig;
- Når antallet af kontrollerede poster, før den næste fejl findes, vil stige.
For at bestemme den kritiske værdi vendte han sig mod begrebet økonomisk gennemførlighed, som i dette tilfælde ved hjælp af begrebet sociale omkostninger kan formuleres som følger: "Omkostningerne ved at rette en fejl bør bæres af den økonomiske aktør, der kan gøre det til den laveste pris." Vi har én agent - dette er en tester, der bruger 1 minut på at tjekke en registrering. I monetære termer, med en indtjening på 6000 rubler om dagen, vil dette beløbe sig til 12,2 rubler. (cirka i dag). Det er tilbage at bestemme den anden side af ligevægten i den økonomiske lov. Jeg ræsonnerede sådan. En eksisterende fejl vil kræve, at den, det drejer sig om, gør en indsats for at rette den, det vil sige ejeren af ejendommen. Antag, at dette kræver 1 dags handling (indsend ansøgningen, modtag det rettede dokument). Så vil hans omkostninger ud fra et socialt synspunkt svare til den gennemsnitlige løn pr. dag. Gennemsnitlig optjent løn i Khanty-Mansi Autonomous Okrug 73285 rub. eller 3053,542 rubler / dag. Derfor opnår vi en kritisk værdi svarende til:
3053,542: 12,2 = 250,4 poster.
Det betyder, fra et offentligt synspunkt, at hvis testeren tjekkede 251 poster og fandt én fejl, svarer det til, at brugeren selv har rettet denne fejl. Derfor, hvis testeren brugte tid svarende til at kontrollere 252 poster for at finde den næste fejl, så er det i dette tilfælde bedre at flytte omkostningerne ved korrektion til brugeren.
En forenklet tilgang præsenteres her, da det fra et socialt synspunkt er nødvendigt at tage højde for al den ekstra værdi, der genereres af hver specialist, det vil sige omkostninger inklusive skatter og sociale betalinger, men modellen er klar. Konsekvensen af dette forhold er følgende krav til specialister: en specialist fra IT-branchen skal have en højere løn end landsgennemsnittet. Hvis hans løn er mindre end gennemsnitslønnen for potentielle databasebrugere, så skal han selv tjekke hele databasen i hånd-til-hånd kamp.
Ved brug af det beskrevne kriterium dannes det første krav til kvaliteten af databasen:
I(tr). Andelen af kritiske fejl bør ikke overstige 1/250,4 = 0,39938%. Lidt mindre end guld i industrien. Og rent fysisk er der ikke mere end 1459 indtastninger med fejl.
Økonomisk tilbagetog.
Faktisk, ved at tillade så mange fejl i optegnelserne, accepterer virksomheden økonomiske tab i størrelsesordenen:
1459 * 3053,542 \u4d 455 rubler.
Dette beløb er bestemt af, at samfundet ikke har redskaberne til at reducere disse omkostninger. Det følger heraf, at hvis nogen har en teknologi, der giver dig mulighed for at reducere antallet af poster med fejl til for eksempel 259, så giver det samfundet mulighed for at spare:
1200 * 3053,542 \u3d 664 rubler.
Men på samme tid kan han bede om sit talent og arbejde, ja, lad os sige - 1 million rubler.
Det vil sige, at sociale omkostninger reduceres med:
3 - 664 \u250d 1 rubler.
Faktisk er denne effekt en merværdi fra brugen af Bigdata-teknologier.
Men her skal det tages i betragtning, at dette er en social effekt, og ejeren af databasen er de kommunale myndigheder, deres indkomst fra brugen af ejendom registreret i denne database, med en sats på 0,3%, er: 2,778 milliarder rubler / år. Og disse omkostninger (4 rubler) generer ham ikke meget, da de flyttes til ejerne af ejendommen. Og i dette aspekt vil udvikleren af flere raffineringsteknologier i Bigdata vise evnen til at overbevise ejeren af denne database, og der er brug for et betydeligt talent til sådanne ting.
I dette eksempel blev fejlestimeringsalgoritmen valgt baseret på Schuman-modellen [2] for softwareverifikation under test for pålidelighed. På grund af dens udbredelse i netværket og evnen til at opnå de nødvendige statistiske indikatorer. Metoden er taget fra Yu.M. Monakhov. "Funktionel stabilitet af informationssystemer", se under spoileren i fig. 7-9.
Ris. 7 – 9 Schuman Model Metodologi
I anden del af dette materiale præsenteres et eksempel på datarensning, hvor resultaterne af brugen af Schuman-modellen opnås.
Jeg præsenterer resultaterne:
Estimeret antal fejl N = 3167 shN.
Parameter C, lambda og pålidelighedsfunktion:
Fig. 17
I det væsentlige er lambda den faktiske hastighed, hvormed fejl opdages på hvert trin. Hvis du ser på den anden del, var estimatet af denne indikator 42,4 fejl i timen, hvilket er ret sammenligneligt med Schuman-indikatoren. Ovenfor blev det bestemt, at hastigheden for at finde fejl af udvikleren ikke skulle være lavere end 1 fejl pr. 250,4 poster, når der kontrolleres 1 post pr. minut. Derfor den kritiske lambda-værdi for Schumann-modellen:
60 / 250,4 = 0,239617.
Det vil sige, at behovet for at udføre procedurerne for at finde fejl skal udføres, indtil lambdaen, fra de tilgængelige 38,964, falder til 0,239617.
Eller indtil indikatoren N (potentielt antal fejl) minus n (korrigeret antal fejl) falder under den tærskel, vi vedtog - 1459 stk.
Litteratur
- Monakhov, Yu. M. Funktionel stabilitet af informationssystemer. Ved 3 timer Del 1. Softwarepålidelighed: lærebog. godtgørelse / Yu. M. Monakhov; Vladim. stat un-t. - Vladimir: Izdvo Vladimir. stat un-ta, 2011. - 60 s. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman, "Probabilistiske modeller til forudsigelse af softwarepålidelighed."
- Grundlæggende data warehousing for IT-professionelle / Paulraj Ponniah.-2. udg.
Kilde: www.habr.com