1. Inledande data
Datarensning är en av utmaningarna för dataanalysuppgifter. Detta material återspeglade utvecklingen och lösningarna som uppstod som ett resultat av att lösa ett praktiskt problem med att analysera databasen i bildandet av matrikelvärde. Källor här .
Filen ”Jämförelsemodell total.ods” i ”Bilaga B. Resultat av bestämning av KS 5. Information om metod för att fastställa fastighetsvärde 5.1 Jämförande ansats” övervägdes.
Tabell 1. Statistiska indikatorer för datamängden i filen "Comparative model total.ods"
Totalt antal fält, st. — 44
Totalt antal poster, st. — 365 490
Totalt antal tecken, st. — 101 714 693
Genomsnittligt antal tecken i en post, st. — 278,297
Standardavvikelse för tecken i en post, st. — 15,510
Minsta antal tecken i en post, st. — 198
Maximalt antal tecken i en post, st. — 363
2. Inledande del. Grundläggande standarder
Under analysen av den specificerade databasen bildades en uppgift för att specificera kraven på reningsgraden, eftersom den specificerade databasen, vilket är klart för alla, skapar juridiska och ekonomiska konsekvenser för användarna. Under arbetets gång visade det sig att det inte fanns några specifika krav på graden av rensning av big data. Genom att analysera de juridiska normerna i denna fråga kom jag till slutsatsen att de alla är bildade av möjligheter. Det vill säga att en viss uppgift har dykt upp, informationskällor sammanställs för uppgiften, sedan bildas ett dataset och, baserat på det skapade datasetet, verktyg för att lösa problemet. De resulterande lösningarna är referenspunkter i valet av alternativ. Jag presenterade detta i bild 1.
Eftersom det är att föredra att förlita sig på beprövad teknik när det gäller att fastställa standarder, valde jag de krav som anges i , eftersom jag ansåg det här dokumentet som det mest omfattande för denna fråga. I detta dokument står det särskilt i avsnittet "Det bör noteras att dataintegritetskraven gäller lika för manuella (pappers) som elektroniska data." (översättning: "... krav på dataintegritet gäller lika för manuella (pappers) som elektroniska data"). Denna formulering är helt specifikt förknippad med begreppet "skriftligt bevis", i bestämmelserna i artikel 71 i civilprocesslagen, art. 70 CAS, art 75 APC, "skriftligt" art. 84 civilprocesslagen.
I figur 2 presenteras ett diagram över hur synsätt på informationstyper i rättsvetenskap har utformats.
Ris. 2. Källa .
Figur 3 visar mekanismen i figur 1, för uppgifterna i ovanstående "Vägledning". Det är lätt, genom att göra en jämförelse, att se att de tillvägagångssätt som används för att uppfylla kraven på informationsintegritet i moderna standarder för informationssystem är väsentligt begränsade i jämförelse med det juridiska begreppet information.
Figur 3
I det angivna dokumentet (Guidance) bekräftas kopplingen till den tekniska delen, möjligheter för bearbetning och lagring av data, väl av ett citat från kapitel 18.2. Relationsdatabas: "Denna filstruktur är i sig säkrare, eftersom data lagras i ett stort filformat som bevarar förhållandet mellan data och metadata."
Faktum är att i detta tillvägagångssätt - från befintliga tekniska kapaciteter, finns det inget onormalt och i sig är detta en naturlig process, eftersom expansionen av koncept kommer från den mest studerade aktiviteten - databasdesign. Men å andra sidan dyker det upp juridiska normer som inte ger rabatter på befintliga systems tekniska kapacitet, till exempel: .
Ris. 4. Tratt med teknisk kapacitet ().
I dessa aspekter blir det tydligt att den ursprungliga datamängden (Fig. 1) först och främst måste sparas och för det andra utgöra grunden för att extrahera ytterligare information från den. Tja, som ett exempel: kameror som registrerar trafikregler är allestädes närvarande, informationsbehandlingssystem rensar bort överträdare, men annan information kan också erbjudas till andra konsumenter, till exempel som marknadsföringsövervakning av strukturen i flödet av kunder till ett köpcentrum. Och detta är en källa till ytterligare mervärde när du använder BigDat. Det är mycket möjligt att de datamängder som samlas in nu, någonstans i framtiden, kommer att ha värde enligt en mekanism som liknar värdet av sällsynta upplagor av 1700 för närvarande. När allt kommer omkring, i själva verket är tillfälliga datauppsättningar unika och kommer sannolikt inte att upprepas i framtiden.
3. Inledande del. Evalutionskriterie
Under bearbetningsprocessen utvecklades följande klassificering av fel.
1. Felklass (baserat på GOST R 8.736-2011): a) systematiska fel; b) slumpmässiga fel; c) en blunder.
2. Genom multiplicitet: a) monodistorsion; b) multi-distorsion.
3. Beroende på hur kritiska konsekvenserna är: a) kritiska; b) inte kritisk.
4. Efter källa till händelsen:
A) Tekniskt – fel som uppstår under driften av utrustningen. Ett ganska relevant fel för IoT-system, system med en betydande grad av inflytande på kvaliteten på kommunikation, utrustning (hårdvara).
B) Operatörsfel - fel inom ett brett spektrum från operatörens stavfel vid inmatning till fel i de tekniska specifikationerna för databasdesign.
C) Användarfel - här är användarfel i hela intervallet från "glömde byta layout" till att missa meter för fötter.
5. Uppdelad i en separat klass:
a) "separatorns uppgift", det vill säga utrymmet och ":" (i vårt fall) när det duplicerades;
b) ord skrivna tillsammans;
c) inget mellanslag efter tjänstecken
d) symmetriskt flera symboler: (), "", "...".
Sammantaget, med systematiseringen av databasfel som presenteras i figur 5, bildas ett ganska effektivt koordinatsystem för att söka efter fel och utveckla en datarensningsalgoritm för detta exempel.
Ris. 5. Typiska fel som motsvarar databasens strukturella enheter (Källa: ).
Noggrannhet, domänintegritet, datatyp, konsistens, redundans, fullständighet, dubblering, överensstämmelse med affärsregler, strukturell bestämbarhet, dataavvikelse, tydlighet, lägligt, efterlevnad av dataintegritetsregler. (Sida 334. Grundläggande datalager för IT-proffs / Paulraj Ponniah.—2:a uppl.)
Presenterade engelska formuleringar och rysk maskinöversättning inom parentes.
Noggrannhet. Värdet som lagras i systemet för ett dataelement är det rätta värdet för den förekomsten av dataelementet. Om du har ett kundnamn och en adress lagrade i en post, så är adressen den korrekta adressen för kunden med det namnet. Om du hittar den beställda kvantiteten som 1000 enheter i posten för beställningsnummer 12345678, är den kvantiteten den korrekta kvantiteten för den beställningen.
[Noggrannhet. Värdet som lagras i systemet för ett dataelement är det korrekta värdet för den förekomsten av dataelementet. Om du har ett kundnamn och en adress lagrad i en post, så är adressen den korrekta adressen för kunden med det namnet. Om du hittar den beställda kvantiteten som 1000 enheter i posten för beställningsnummer 12345678, är den kvantiteten den exakta kvantiteten för den beställningen.]
Domänintegritet. Datavärdet för ett attribut faller inom intervallet av tillåtna, definierade värden. Det vanliga exemplet är att de tillåtna värdena är "man" och "kvinna" för könsdataelementet.
[Domänintegritet. Attributdatavärdet faller inom intervallet av giltiga, definierade värden. Ett allmänt exempel är de giltiga värdena "male" och "female" för ett könsdataelement.]
Data typ. Värdet för ett dataattribut lagras faktiskt som den datatyp som definieras för det attributet. När datatypen för butiksnamnfältet definieras som "text" innehåller alla instanser av det fältet butiksnamnet som visas i textformat och inte numeriska koder.
[Data typ. Värdet på ett dataattribut lagras faktiskt som den datatyp som definieras för det attributet. Om datatypen för butiksnamnfältet definieras som "text", innehåller alla instanser av detta fält butiksnamnet som visas i textformat snarare än sifferkoder.]
Konsistens. Formen och innehållet i ett datafält är detsamma i flera källsystem. Om produktkoden för produkt ABC i ett system är 1234, är koden för denna produkt 1234 i varje källsystem.
[Konsistens. Datafältets form och innehåll är desamma i olika källsystem. Om produktkoden för produkt ABC på ett system är 1234, är koden för den produkten 1234 på varje källsystem.]
Redundans. Samma data får inte lagras på mer än en plats i ett system. Om ett dataelement av effektivitetsskäl avsiktligt lagras på mer än en plats i ett system, måste redundansen tydligt identifieras och verifieras.
[Redundans. Samma data bör inte lagras på mer än en plats i systemet. Om ett dataelement av effektivitetsskäl avsiktligt lagras på flera platser i ett system, måste redundansen vara tydligt definierad och verifierad.]
Fullständighet. Det saknas inga värden för ett givet attribut i systemet. Till exempel, i en kundfil måste det finnas ett giltigt värde för "state"-fältet för varje kund. I filen för beställningsdetaljer måste varje detaljpost för en beställning vara helt ifylld.
[Fullständighet. Det saknas inga värden i systemet för detta attribut. Till exempel måste klientfilen ha ett giltigt värde för "status"-fältet för varje klient. I orderdetaljfilen måste varje orderdetaljpost vara fullständigt ifylld.]
Duplicering. Duplicering av poster i ett system är helt löst. Om produktfilen är känd för att ha dubblettposter, identifieras alla dubblettposter för varje produkt och en korsreferens skapas.
[Duplicera. Duplicering av register i systemet har helt eliminerats. Om en produktfil är känd för att innehålla dubblettposter identifieras alla dubblettposter för varje produkt och en korsreferens skapas.]
Överensstämmelse med affärsregler. Värdena för varje datapost följer föreskrivna affärsregler. I ett auktionssystem kan klubbslaget eller försäljningspriset inte vara lägre än reservationspriset. I ett banklånesystem måste lånesaldot alltid vara positivt eller noll.
[Efterlevnad av affärsregler. Värdena för varje dataelement följer etablerade affärsregler. I ett auktionssystem kan klubbslaget eller försäljningspriset inte vara lägre än reservationspriset. I ett bankkreditsystem måste lånesaldot alltid vara positivt eller noll.]
Strukturell bestämhet. Överallt där ett dataobjekt naturligt kan struktureras i individuella komponenter, måste objektet innehålla denna väldefinierade struktur. Till exempel delas en individs namn naturligt in i förnamn, mellaninitial och efternamn. Värden för namn på individer måste lagras som förnamn, mellaninitial och efternamn. Denna egenskap hos datakvalitet förenklar tillämpningen av standarder och minskar saknade värden.
[Strukturell säkerhet. Där ett dataelement naturligt kan struktureras i individuella komponenter, måste elementet innehålla denna väldefinierade struktur. Till exempel är en persons namn naturligt uppdelat i förnamn, mellaninitial och efternamn. Värden för enskilda namn ska lagras som förnamn, mellaninitial och efternamn. Denna datakvalitetsegenskap förenklar tillämpningen av standarder och minskar saknade värden.]
Dataanomali. Ett fält får endast användas för det ändamål för vilket det är definierat. Om fältet Adress-3 är definierat för en eventuell tredje adressrad för långa adresser, måste detta fält endast användas för att registrera den tredje adressraden. Den får inte användas för att ange ett telefon- eller faxnummer för kunden.
[Data Anomali. Ett fält får endast användas för det ändamål för vilket det är definierat. Om fältet Adress-3 är definierat för en eventuell tredje adresslinje för långa adresser, ska detta fält endast användas för att registrera den tredje adressraden. Den ska inte användas för att ange ett telefon- eller faxnummer för en kund.]
Klarhet. Ett dataelement kan ha alla andra egenskaper hos kvalitetsdata, men om användarna inte förstår dess innebörd tydligt, är dataelementet utan värde för användarna. Korrekt namnkonventioner hjälper till att göra dataelementen väl förstådda av användarna.
[Klarhet. Ett dataelement kan ha alla andra egenskaper hos bra data, men om användarna inte tydligt förstår dess innebörd har dataelementet inget värde för användarna. Korrekta namnkonventioner hjälper användarna att förstå dataelementen väl.]
I god tid. Användarna bestämmer aktualiteten för data. Om användarna förväntar sig att kunddimensionsdata inte ska vara äldre än en dag, måste ändringarna av kunddata i källsystemen tillämpas på datalagret dagligen.
[I tid. Användare bestämmer datas aktualitet. Om användare förväntar sig att kunddimensionsdata inte är mer än en dag gammal, bör ändringar av kunddata i källsystemen tillämpas på datalagret dagligen.]
Användbarhet. Varje dataelement i datalagret måste uppfylla vissa krav för insamling av användare. Ett dataelement kan vara korrekt och av hög kvalitet, men om det inte har något värde för användarna är det totalt onödigt att det dataelementet finns i datalagret.
[Verktyg. Varje dataobjekt i datalagret måste uppfylla vissa krav för användarinsamlingen. Ett dataelement kan vara korrekt och av hög kvalitet, men om det inte ger användarna värde, är det inte nödvändigt att det dataelementet finns i datalagret.]
Efterlevnad av dataintegritetsregler. Data som lagras i källsystemens relationsdatabaser måste följa reglerna för entitetsintegritet och referensintegritet. Alla tabeller som tillåter null som primärnyckel har inte entitetsintegritet. Referensintegritet tvingar upprättandet av relationerna mellan föräldrar och barn på ett korrekt sätt. I en kund-till-order relation säkerställer referensintegritet att det finns en kund för varje order i databasen.
[Efterlevnad av dataintegritetsregler. Data som lagras i källsystems relationsdatabaser måste följa reglerna för entitetsintegritet och referensintegritet. Alla tabeller som tillåter null som primärnyckel har inte entitetsintegritet. Referensintegritet tvingar relationen mellan föräldrar och barn att etableras korrekt. I ett kundorderförhållande säkerställer referensintegritet att det finns en kund för varje order i databasen.]
4. Kvalitet på datarensning
Kvaliteten på datarensning är en ganska problematisk fråga i bigdata. Att svara på frågan om vilken grad av datarensning som krävs för att slutföra uppgiften är grundläggande för varje dataanalytiker. I de flesta aktuella problem bestämmer varje analytiker detta själv och det är osannolikt att någon utifrån kan utvärdera denna aspekt i sin lösning. Men för den aktuella uppgiften i det här fallet var denna fråga extremt viktig, eftersom tillförlitligheten av juridiska uppgifter bör tendera till en.
Överväger tekniker för mjukvarutestning för att fastställa drifttillförlitlighet. Idag finns det fler än dessa modeller . Många av modellerna använder en skadeservicemodell:
FIG. 6
Tänker enligt följande: "Om det hittade felet är en händelse som liknar felhändelsen i denna modell, hur hittar man då en analog av parametern t?" Och jag sammanställde följande modell: Låt oss föreställa oss att tiden det tar en testare att kontrollera en post är 1 minut (för databasen i fråga), för att sedan hitta alla fel behöver han 365 494 minuter, vilket är ungefär 3 år och 3 månaders arbetstid. Som vi förstår är detta en mycket stor mängd arbete och kostnaderna för att kontrollera databasen kommer att vara oöverkomliga för kompilatorn av denna databas. I denna reflektion dyker det ekonomiska begreppet kostnader upp och efter analys kom jag fram till att detta är ett ganska effektivt verktyg. Baserat på ekonomins lag: "Den produktionsvolym (i enheter) vid vilken ett företags maximala vinst uppnås ligger vid den punkt där marginalkostnaden för att producera en ny produktionsenhet jämförs med det pris som detta företag kan få för en ny enhet.” Baserat på postulatet att hitta varje efterföljande fel kräver mer och mer kontroll av poster, är detta en kostnadsfaktor. Det vill säga, postulatet som antas i testmodeller får en fysisk betydelse i följande mönster: om det var nödvändigt att kontrollera n poster för att hitta det i:te felet, kommer det att vara nödvändigt för att hitta nästa (i+1) fel att kontrollera m poster och samtidigt n
- När antalet poster som kontrollerats innan ett nytt fel hittas stabiliseras;
- När antalet poster kontrolleras innan nästa fel hittas kommer att öka.
För att fastställa det kritiska värdet vände jag mig till begreppet ekonomisk genomförbarhet, som i detta fall, med hjälp av begreppet sociala kostnader, kan formuleras på följande sätt: ”Kostnaderna för att korrigera felet bör bäras av den ekonomiska aktör som kan göra det till lägsta kostnad." Vi har en agent - en testare som lägger 1 minut på att kontrollera en post. I monetära termer, om du tjänar 6000 12,2 rubel/dag, blir detta 1 rubel. (ungefär idag). Det återstår att fastställa den andra sidan av jämvikten i ekonomisk rätt. Jag resonerade så här. Ett befintligt fel kommer att kräva att den berörda personen lägger ner kraft på att rätta till det, det vill säga fastighetsägaren. Låt oss säga att detta kräver XNUMX dags åtgärd (skicka in en ansökan, få ett korrigerat dokument). Då blir hans kostnader ur social synvinkel lika med den genomsnittliga lönen per dag. Genomsnittlig upplupen lön i Khanty-Mansi autonoma Okrug 73285 gnugga. eller 3053,542 rubel/dag. Följaktligen får vi ett kritiskt värde lika med:
3053,542: 12,2 = 250,4 rekordenheter.
Detta innebär, ur social synvinkel, att om en testare kontrollerade 251 poster och hittade ett fel, så motsvarar det att användaren själv fixar detta fel. Följaktligen, om testaren tillbringade tid lika med att kontrollera 252 poster för att hitta nästa fel, är det i detta fall bättre att flytta kostnaden för korrigering till användaren.
Ett förenklat tillvägagångssätt presenteras här, eftersom det ur social synvinkel är nödvändigt att ta hänsyn till allt mervärde som genereras av varje specialist, det vill säga kostnader inklusive skatter och sociala betalningar, men modellen är tydlig. En konsekvens av detta förhållande är följande krav på specialister: en specialist från IT-branschen ska ha en lön som är högre än riksgenomsnittet. Om hans lön är lägre än genomsnittslönen för potentiella databasanvändare, måste han själv kontrollera hela databasen hand-to-hand.
När du använder det beskrivna kriteriet bildas det första kravet på kvaliteten på databasen:
I(tr). Andelen kritiska fel bör inte överstiga 1/250,4 = 0,39938 %. Lite mindre än guld i industrin. Och rent fysiskt finns det inte mer än 1459 poster med fel.
Ekonomisk reträtt.
I själva verket, genom att göra ett sådant antal fel i register, accepterar samhället ekonomiska förluster i mängden:
1459*3053,542 = 4 rubel.
Detta belopp bestäms av att samhället inte har verktyg för att minska dessa kostnader. Det följer att om någon har en teknik som gör att de kan minska antalet poster med fel till till exempel 259, så kommer detta att tillåta samhället att spara:
1200*3053,542 = 3 rubel.
Men samtidigt kan han be om sin talang och arbete, ja, låt oss säga - 1 miljon rubel.
Det vill säga sociala kostnader minskas med:
3 664 250 – 1 000 000 = 2 664 250 rubel.
I huvudsak är denna effekt mervärdet från användningen av BigDat-teknologier.
Men här bör det beaktas att detta är en social effekt, och ägaren till databasen är kommunala myndigheter, deras inkomst från användningen av egendom som registrerats i denna databas, med en hastighet av 0,3%, är: 2,778 miljarder rubel/ år. Och dessa kostnader (4 455 118 rubel) stör honom inte mycket, eftersom de överförs till fastighetsägarna. Och i den här aspekten måste utvecklaren av mer förfinande teknologier i Bigdata visa förmågan att övertyga ägaren av denna databas, och sådana saker kräver stor talang.
I det här exemplet valdes felbedömningsalgoritmen baserat på Schumann-modellen [2] för mjukvaruverifiering under tillförlitlighetstestning. På grund av dess utbredning på Internet och förmågan att få de nödvändiga statistiska indikatorerna. Metodiken är hämtad från Monakhov Yu.M. "Funktionell stabilitet för informationssystem", se under spoilern i fig. 7-9.
Ris. 7 – 9 Metodik för Schumann-modellen
Den andra delen av detta material presenterar ett exempel på datarensning, där resultaten av att använda Schumann-modellen erhålls.
Låt mig presentera resultaten:
Uppskattat antal fel N = 3167 n.
Parameter C, lambda och tillförlitlighetsfunktion:
Figur 17
I huvudsak är lambda en faktisk indikator på intensiteten med vilken fel detekteras i varje steg. Om du tittar på den andra delen var uppskattningen för denna indikator 42,4 fel per timme, vilket är ganska jämförbart med Schumann-indikatorn. Ovan fastställdes att hastigheten med vilken en utvecklare hittar fel inte bör vara lägre än 1 fel per 250,4 poster, vid kontroll av 1 post per minut. Därav det kritiska värdet av lambda för Schumann-modellen:
60 / 250,4 = 0,239617.
Det vill säga behovet av att utföra feldetekteringsprocedurer måste utföras tills lambda, från den befintliga 38,964, minskar till 0,239617.
Eller tills indikatorn N (potentiellt antal fel) minus n (korrigerat antal fel) sjunker under vårt accepterade tröskelvärde - 1459 st.
Litteratur
- Monakhov, Yu. M. Funktionell stabilitet för informationssystem. På 3 timmar Del 1. Programvarutillförlitlighet: lärobok. bidrag / Yu. M. Monakhov; Vladim. stat univ. – Vladimir: Izvo Vladim. stat Universitetet, 2011. – 60 sid. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman, "Probabilistiska modeller för förutsägelse av programvarans tillförlitlighet."
- Grundläggande datalager för IT-proffs / Paulraj Ponniah.—2nd ed.
Källa: will.com