1. Startdata
Datarydding er en av utfordringene for dataanalyseoppgaver. Dette materialet reflekterte utviklingen og løsningene som oppsto som et resultat av å løse et praktisk problem med å analysere databasen i dannelsen av matrikkelverdi. Kilder her .
Filen «Sammenlignende modell total.ods» i «Vedlegg B. Resultater av fastsettelse av KS 5. Informasjon om metode for fastsettelse av matrikkelverdi 5.1 Sammenlignende tilnærming» ble vurdert.
Tabell 1. Statistiske indikatorer for datasettet i filen «Comparative model total.ods»
Totalt antall felt, stk. – 44
Totalt antall poster, stk. — 365 490
Totalt antall tegn, stk. — 101 714 693
Gjennomsnittlig antall tegn i en post, stk. — 278,297
Standardavvik for tegn i en post, stk. — 15,510
Minimum antall tegn i en oppføring, stk. – 198
Maks antall tegn i en oppføring, stk. – 363
2. Innledende del. Grunnleggende standarder
Mens man analyserte den spesifiserte databasen, ble det dannet en oppgave for å spesifisere kravene til rensegraden, siden, som det er klart for alle, den spesifiserte databasen skaper juridiske og økonomiske konsekvenser for brukerne. Under arbeidet viste det seg at det ikke var spesifikke krav til graden av rensing av big data. Ved å analysere de juridiske normene i denne saken, kom jeg til den konklusjon at de alle er dannet av muligheter. Det vil si at en bestemt oppgave har dukket opp, informasjonskilder kompileres for oppgaven, deretter dannes et datasett og, basert på det opprettede datasettet, verktøy for å løse problemet. De resulterende løsningene er referansepunkter ved valg av alternativer. Jeg presenterte dette i figur 1.
Siden det i spørsmål om å fastsette eventuelle standarder er å foretrekke å stole på utprøvde teknologier, valgte jeg kravene angitt i , fordi jeg anså dette dokumentet som det mest omfattende for dette problemet. Spesielt i dette dokumentet står det "Det bør bemerkes at dataintegritetskrav gjelder like for manuelle (papir) og elektroniske data." (oversettelse: "... krav til dataintegritet gjelder like for manuelle (papir) og elektroniske data"). Denne formuleringen er ganske spesifikt knyttet til konseptet "skriftlig bevis", i bestemmelsene i artikkel 71 i loven om sivil prosess, art. 70 CAS, Art.75 APC, «skriftlig» Art. 84 lov om sivilprosess.
Figur 2 presenterer et diagram over dannelsen av tilnærminger til typer informasjon i rettsvitenskap.
Ris. 2. Kilde .
Figur 3 viser mekanismen i figur 1, for oppgavene til "Veiledning" ovenfor. Det er lett, ved å foreta en sammenligning, å se at tilnærmingene som brukes for å oppfylle kravene til informasjonsintegritet i moderne standarder for informasjonssystemer er vesentlig begrenset i forhold til det juridiske informasjonsbegrepet.
Figur 3
I det spesifiserte dokumentet (Veiledning) er koblingen til den tekniske delen, muligheter for behandling og lagring av data, godt bekreftet av et sitat fra kapittel 18.2. Relasjonsdatabase: "Denne filstrukturen er iboende sikrere, ettersom dataene holdes i et stort filformat som bevarer forholdet mellom data og metadata."
Faktisk, i denne tilnærmingen - fra eksisterende tekniske evner, er det ingenting unormalt, og i seg selv er dette en naturlig prosess, siden utvidelsen av konsepter kommer fra den mest studerte aktiviteten - databasedesign. Men på den annen side dukker det opp juridiske normer som ikke gir rabatter på de tekniske egenskapene til eksisterende systemer, for eksempel: .
Ris. 4. Trakt for tekniske evner ().
I disse aspektene blir det klart at det opprinnelige datasettet (fig. 1) først og fremst må lagres, og for det andre være grunnlaget for å trekke ut tilleggsinformasjon fra det. Vel, som et eksempel: kameraer som registrerer trafikkregler er allestedsnærværende, informasjonsbehandlingssystemer luker ut overtredere, men annen informasjon kan også tilbys til andre forbrukere, for eksempel som markedsføringsovervåking av strukturen i strømmen av kunder til et kjøpesenter. Og dette er en kilde til ekstra verdi ved bruk av BigDat. Det er godt mulig at datasettene som samles inn nå, et sted i fremtiden, vil ha verdi i henhold til en mekanisme som ligner verdien av sjeldne utgaver av 1700 på nåværende tidspunkt. Tross alt, faktisk, er midlertidige datasett unike og vil neppe bli gjentatt i fremtiden.
3. Innledende del. Evalueringskriterier
Under behandlingsprosessen ble følgende klassifisering av feil utviklet.
1. Feilklasse (basert på GOST R 8.736-2011): a) systematiske feil; b) tilfeldige feil; c) en tabbe.
2. Ved multiplisitet: a) mono forvrengning; b) multi-forvrengning.
3. I henhold til kritikken av konsekvensene: a) kritisk; b) ikke kritisk.
4. Etter kilde til hendelsen:
A) Teknisk – feil som oppstår under driften av utstyret. En ganske relevant feil for IoT-systemer, systemer med betydelig grad av innflytelse på kvaliteten på kommunikasjon, utstyr (maskinvare).
B) Operatørfeil - feil i et vidt spekter fra operatørtastefeil ved inntasting til feil i de tekniske spesifikasjonene for databasedesign.
C) Brukerfeil - her er brukerfeil i hele området fra "glemte å bytte layout" til å ta feil av meter for fot.
5. Delt inn i en egen klasse:
a) "separatorens oppgave", det vil si mellomrommet og ":" (i vårt tilfelle) når det ble duplisert;
b) ord skrevet sammen;
c) ingen mellomrom etter tjenestetegn
d) symmetrisk flere symboler: (), "", "...".
Samlet sett, med systematiseringen av databasefeil presentert i figur 5, dannes et ganske effektivt koordinatsystem for å søke etter feil og utvikle en datarensealgoritme for dette eksemplet.
Ris. 5. Typiske feil som tilsvarer de strukturelle enhetene i databasen (Kilde: ).
Nøyaktighet, domeneintegritet, datatype, konsistens, redundans, fullstendighet, duplisering, samsvar med forretningsregler, strukturell bestemthet, dataavvik, klarhet, rettidig, overholdelse av dataintegritetsregler. (Side 334. Grunnleggende datavarehus for IT-fagfolk / Paulraj Ponniah.—2. utg.)
Presentert engelsk ordlyd og russisk maskinoversettelse i parentes.
Nøyaktighet. Verdien som er lagret i systemet for et dataelement, er den riktige verdien for den forekomsten av dataelementet. Hvis du har et kundenavn og en adresse lagret i en post, er adressen den riktige adressen til kunden med det navnet. Hvis du finner antallet bestilt som 1000 enheter i posten for bestillingsnummer 12345678, er dette antallet det nøyaktige antallet for den bestillingen.
[Nøyaktighet. Verdien som er lagret i systemet for et dataelement er den riktige verdien for den forekomsten av dataelementet. Hvis du har et kundenavn og en adresse lagret i en post, er adressen den riktige adressen til kunden med det navnet. Hvis du finner antallet som er bestilt som 1000 enheter i posten for ordrenummer 12345678, er det antallet det nøyaktige antallet for den ordren.]
Domeneintegritet. Dataverdien til et attributt faller innenfor rekkevidden av tillatte, definerte verdier. Det vanlige eksemplet er at de tillatte verdiene er "mann" og "kvinnelig" for kjønnsdataelementet.
[Domeneintegritet. Attributtdataverdien faller innenfor rekkevidden av gyldige, definerte verdier. Et generelt eksempel er de gyldige verdiene "male" og "female" for et kjønnsdataelement.]
Data-type. Verdien for et dataattributt lagres faktisk som datatypen som er definert for det attributtet. Når datatypen til butikknavnfeltet er definert som "tekst", inneholder alle forekomster av det feltet butikknavnet vist i tekstformat og ikke numeriske koder.
[Data-type. Verdien til et dataattributt lagres faktisk som datatypen som er definert for det attributtet. Hvis datatypen for butikknavnfeltet er definert som "tekst", inneholder alle forekomster av dette feltet butikknavnet vist i tekstformat i stedet for numeriske koder.]
Konsistens. Formen og innholdet til et datafelt er det samme på tvers av flere kildesystemer. Hvis produktkoden for produkt ABC i ett system er 1234, er koden for dette produktet 1234 i hvert kildesystem.
[Konsistens. Formen og innholdet i datafeltet er likt i ulike kildesystemer. Hvis produktkoden for produkt ABC på ett system er 1234, er koden for det produktet 1234 på hvert kildesystem.]
Overflødighet. De samme dataene skal ikke lagres mer enn ett sted i et system. Hvis et dataelement av effektivitetshensyn med hensikt er lagret på mer enn ett sted i et system, må redundansen tydelig identifiseres og verifiseres.
[Overflødighet. De samme dataene skal ikke lagres mer enn ett sted i systemet. Hvis et dataelement av effektivitetshensyn med hensikt er lagret på flere steder i et system, må redundans være klart definert og verifisert.]
Fullstendighet. Det mangler ingen verdier for et gitt attributt i systemet. For eksempel, i en kundefil må det være en gyldig verdi for "state"-feltet for hver kunde. I filen for bestillingsdetaljer må hver detaljpost for en bestilling være fullstendig utfylt.
[Fullstendighet. Det mangler ingen verdier i systemet for dette attributtet. For eksempel må klientfilen ha en gyldig verdi for "status"-feltet for hver klient. I ordredetaljfilen må hver ordredetaljpost være fullstendig utfylt.]
Duplisering. Duplisering av poster i et system er fullstendig løst. Hvis produktfilen er kjent for å ha dupliserte poster, identifiseres alle duplikatpostene for hvert produkt og en kryssreferanse opprettes.
[Duplisere. Duplisering av poster i systemet er fullstendig eliminert. Hvis en produktfil er kjent for å inneholde dupliserte oppføringer, identifiseres alle dupliserte oppføringer for hvert produkt og en kryssreferanse opprettes.]
Overholdelse av forretningsregler. Verdiene til hvert dataelement overholder foreskrevne forretningsregler. I et auksjonssystem kan ikke hammerslags- eller salgssummen være mindre enn reserveprisen. I et banklånsystem må lånesaldoen alltid være positiv eller null.
[Overholdelse av forretningsregler. Verdiene til hvert dataelement samsvarer med etablerte forretningsregler. I et auksjonssystem kan ikke hammerslags- eller salgssummen være mindre enn reserveprisen. I et bankkredittsystem må lånesaldoen alltid være positiv eller null.]
Strukturell bestemthet. Der hvor et dataelement naturlig kan struktureres i individuelle komponenter, må elementet inneholde denne veldefinerte strukturen. For eksempel deler en persons navn naturlig inn i fornavn, mellominitial og etternavn. Verdier for navn på individer må lagres som fornavn, mellombokstav og etternavn. Denne egenskapen til datakvalitet forenkler håndheving av standarder og reduserer manglende verdier.
[Strukturell sikkerhet. Der et dataelement naturlig kan struktureres i individuelle komponenter, må elementet inneholde denne veldefinerte strukturen. For eksempel er en persons navn naturlig delt inn i fornavn, mellombokstav og etternavn. Verdier for individuelle navn skal lagres som fornavn, mellombokstav og etternavn. Denne datakvalitetsegenskapen forenkler bruken av standarder og reduserer manglende verdier.]
Dataanomali. Et felt må kun brukes til det formålet det er definert for. Hvis feltet Adresse-3 er definert for en eventuell tredje adresselinje for lange adresser, må dette feltet kun brukes til å registrere den tredje adresselinjen. Den må ikke brukes til å legge inn telefon- eller faksnummer for kunden.
[Data Anomali. Et felt må kun brukes til det formålet det er definert for. Hvis Adresse-3-feltet er definert for en mulig tredje adresselinje for lange adresser, skal dette feltet kun brukes til å registrere den tredje adresselinjen. Den skal ikke brukes til å angi telefon- eller faksnummer for en kunde.]
Klarhet. Et dataelement kan ha alle de andre egenskapene til kvalitetsdata, men hvis brukerne ikke forstår betydningen klart, er dataelementet uten verdi for brukerne. Riktige navnekonvensjoner bidrar til å gjøre dataelementene godt forstått av brukerne.
[Klarhet. Et dataelement kan ha alle de andre egenskapene til gode data, men hvis brukerne ikke tydelig forstår betydningen, er dataelementet uten verdi for brukerne. Riktige navnekonvensjoner bidrar til å gjøre dataelementer godt forstått av brukere.]
Betimelig. Brukerne bestemmer aktualiteten til dataene. Hvis brukerne forventer at kundedimensjonsdata ikke er eldre enn én dag, må endringene i kundedata i kildesystemene påføres datavarehuset daglig.
[På en riktig måte. Brukere bestemmer aktualiteten til data. Hvis brukere forventer at kundedimensjonsdata ikke er mer enn én dag gamle, bør endringer i kundedata i kildesystemene brukes på datavarehuset på daglig basis.]
Nytteverdi. Hvert dataelement i datavarehuset må tilfredsstille noen krav til innsamling av brukere. Et dataelement kan være nøyaktig og av høy kvalitet, men hvis det ikke har noen verdi for brukerne, er det totalt unødvendig at det dataelementet er i datavarehuset.
[Nytte. Hvert dataelement i datalageret må tilfredsstille noen krav til brukerinnsamlingen. Et dataelement kan være nøyaktig og av høy kvalitet, men hvis det ikke gir verdi for brukerne, er det ikke nødvendig at det dataelementet er i datavarehuset.]
Overholdelse av dataintegritetsregler. Dataene som er lagret i relasjonsdatabasene til kildesystemene, må overholde regler for enhetsintegritet og referanseintegritet. Enhver tabell som tillater null som primærnøkkel, har ikke enhetsintegritet. Referensiell integritet tvinger etableringen av foreldre-barn-relasjonene riktig. I et kunde-til-ordre-forhold sikrer referanseintegritet eksistensen av en kunde for hver ordre i databasen.
[Overholdelse av regler for dataintegritet. Data lagret i relasjonsdatabaser til kildesystemer må overholde reglene for enhetsintegritet og referanseintegritet. Enhver tabell som tillater null som primærnøkkel, har ikke enhetsintegritet. Referensiell integritet tvinger forholdet mellom foreldre og barn til å etableres riktig. I et kundeordreforhold sikrer referanseintegritet at det eksisterer en kunde for hver ordre i databasen.]
4. Kvalitet på datarensing
Kvaliteten på datarensing er et ganske problematisk problem i bigdata. Å svare på spørsmålet om hvilken grad av datarensing som er nødvendig for å fullføre oppgaven er grunnleggende for enhver dataanalytiker. I de fleste aktuelle problemer bestemmer hver analytiker dette selv, og det er usannsynlig at noen fra utsiden er i stand til å vurdere dette aspektet i løsningen hans. Men for oppgaven for hånden i dette tilfellet, var dette problemet ekstremt viktig, siden påliteligheten til juridiske data bør ha en tendens til en.
Vurderer teknologier for testing av programvare for å bestemme driftspålitelighet. I dag er det flere enn disse modellene . Mange av modellene bruker en skadeservicemodell:
Fig. 6
Tenker som følger: "Hvis feilen som ble funnet er en hendelse som ligner på feilhendelsen i denne modellen, hvordan finner man en analog av parameteren t?" Og jeg kompilerte følgende modell: La oss forestille oss at tiden det tar en tester å sjekke en post er 1 minutt (for den aktuelle databasen), og for å finne alle feilene trenger han 365 494 minutter, som er omtrent 3 år og 3 måneders arbeidstid. Som vi forstår er dette en veldig stor mengde arbeid og kostnadene ved å sjekke databasen vil være uoverkommelige for kompilatoren av denne databasen. I denne refleksjonen dukker det økonomiske kostnadsbegrepet opp og etter analyse kom jeg til at dette er et ganske effektivt verktøy. Basert på økonomiloven: "Produksjonsvolumet (i enheter) som et firmas maksimale fortjeneste oppnås ved, er lokalisert på det punktet hvor marginalkostnaden ved å produsere en ny produksjonsenhet sammenlignes med prisen som denne bedriften kan motta. for en ny enhet." Basert på postulatet om at det å finne hver påfølgende feil krever mer og mer kontroll av poster, er dette en kostnadsfaktor. Det vil si at postulatet som ble tatt i bruk i testing av modeller, får en fysisk betydning i følgende mønster: hvis for å finne den i-te feilen var det nødvendig å sjekke n poster, så vil det være nødvendig for å finne den neste (i+1) feilen å kontrollere m poster og samtidig n
- Når antall poster kontrollert før en ny feil blir funnet stabiliseres;
- Når antall poster kontrollert før du finner neste feil vil øke.
For å bestemme den kritiske verdien, vendte jeg meg til begrepet økonomisk gjennomførbarhet, som i dette tilfellet, ved å bruke begrepet sosiale kostnader, kan formuleres som følger: «Kostnadene ved å rette feilen bør bæres av den økonomiske aktøren som kan gjøre det til lavest mulig pris." Vi har én agent – en tester som bruker 1 minutt på å sjekke én post. I monetære termer, hvis du tjener 6000 rubler per dag, vil dette være 12,2 rubler. (omtrent i dag). Det gjenstår å bestemme den andre siden av likevekten i økonomisk lov. Jeg resonnerte slik. En eksisterende feil vil kreve at vedkommende bruker krefter på å rette den, det vil si eiendomsbesitter. La oss si at dette krever 1 dag med handling (send inn en søknad, motta et korrigert dokument). Da vil kostnadene hans fra et sosialt synspunkt være lik gjennomsnittslønnen per dag. Gjennomsnittlig påløpt lønn i Khanty-Mansi autonome okrug 73285 gni. eller 3053,542 rubler/dag. Følgelig får vi en kritisk verdi lik:
3053,542: 12,2 = 250,4 enheter med poster.
Dette betyr, fra et sosialt synspunkt, at hvis en tester sjekket 251 poster og fant én feil, tilsvarer det at brukeren fikser denne feilen selv. Følgelig, hvis testeren brukte tid lik å sjekke 252 poster for å finne den neste feilen, er det i dette tilfellet bedre å flytte kostnadene for korrigering til brukeren.
En forenklet tilnærming presenteres her, siden det fra et sosialt synspunkt er nødvendig å ta hensyn til all tilleggsverdien som genereres av hver spesialist, det vil si kostnader inkludert skatter og sosiale betalinger, men modellen er klar. En konsekvens av dette forholdet er følgende krav til spesialister: en spesialist fra IT-bransjen skal ha høyere lønn enn landsgjennomsnittet. Hvis lønnen hans er mindre enn gjennomsnittslønnen til potensielle databasebrukere, må han selv sjekke hele databasen hånd-til-hånd.
Når du bruker det beskrevne kriteriet, dannes det første kravet til kvaliteten på databasen:
I(tr). Andelen kritiske feil bør ikke overstige 1/250,4 = 0,39938 %. Litt mindre enn gull i industrien. Og fysisk sett er det ikke mer enn 1459 poster med feil.
Økonomisk retrett.
Faktisk, ved å gjøre et slikt antall feil i registre, godtar samfunnet økonomiske tap i mengden av:
1459*3053,542 = 4 rubler.
Dette beløpet bestemmes av at samfunnet ikke har verktøy for å redusere disse kostnadene. Det følger at hvis noen har en teknologi som lar dem redusere antall poster med feil til for eksempel 259, så vil dette tillate samfunnet å spare:
1200*3053,542 = 3 rubler.
Men samtidig kan han be om talentet og arbeidet sitt, vel, la oss si - 1 million rubler.
Det vil si at sosiale kostnader reduseres med:
3 – 664 = 250 rubler.
I hovedsak er denne effekten merverdien fra bruken av BigDat-teknologier.
Men her bør det tas i betraktning at dette er en sosial effekt, og eieren av databasen er kommunale myndigheter, deres inntekt fra bruk av eiendom registrert i denne databasen, med en hastighet på 0,3%, er: 2,778 milliarder rubler/ år. Og disse kostnadene (4 455 118 rubler) plager ham ikke mye, siden de overføres til eiendomseierne. Og i dette aspektet vil utvikleren av mer raffineringsteknologier i Bigdata måtte vise evnen til å overbevise eieren av denne databasen, og slike ting krever betydelig talent.
I dette eksemplet ble feilvurderingsalgoritmen valgt basert på Schumann-modellen [2] for programvareverifisering under pålitelighetstesting. På grunn av utbredelsen på Internett og evnen til å få de nødvendige statistiske indikatorene. Metodikken er hentet fra Monakhov Yu.M. "Funksjonell stabilitet av informasjonssystemer", se under spoileren i fig. 7-9.
Ris. 7 – 9 Metodikk for Schumann-modellen
Den andre delen av dette materialet presenterer et eksempel på datarensing, der resultatene av bruk av Schumann-modellen er oppnådd.
La meg presentere resultatene som er oppnådd:
Estimert antall feil N = 3167 n.
Parameter C, lambda og pålitelighetsfunksjon:
Figur 17
I hovedsak er lambda en faktisk indikator på intensiteten som feil oppdages i hvert trinn. Hvis du ser på den andre delen, var estimatet for denne indikatoren 42,4 feil per time, noe som er ganske sammenlignbart med Schumann-indikatoren. Ovenfor ble det bestemt at hastigheten som en utvikler finner feil med, ikke skal være lavere enn 1 feil per 250,4 poster, når man sjekker 1 post per minutt. Derfor den kritiske verdien av lambda for Schumann-modellen:
60 / 250,4 = 0,239617.
Det vil si at behovet for å utføre feildeteksjonsprosedyrer må utføres til lambda, fra eksisterende 38,964, reduseres til 0,239617.
Eller til indikatoren N (potensielt antall feil) minus n (korrigert antall feil) synker under vår aksepterte terskel - 1459 stk.
Litteratur
- Monakhov, Yu. M. Funksjonell stabilitet av informasjonssystemer. På 3 timer Del 1. Programvarepålitelighet: lærebok. godtgjørelse / Yu. M. Monakhov; Vladim. stat univ. – Vladimir: Izvo Vladim. stat Universitetet, 2011. – 60 s. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman, "Sannsynlighetsmodeller for prediksjon av programvarepålitelighet."
- Grunnleggende datavarehus for IT-fagfolk / Paulraj Ponniah.—2. utg.
Kilde: www.habr.com