1. Date inițiale
Curățarea datelor este una dintre provocările cu care se confruntă sarcinile de analiză a datelor. Acest material a reflectat evoluțiile și soluțiile apărute ca urmare a soluționării unei probleme practice de analiză a bazei de date în formarea valorii cadastrale. Surse aici .
S-a luat în considerare dosarul „Model comparativ total.ods” din „Anexa B. Rezultatele determinării KS 5. Informații privind metoda de determinare a valorii cadastrale 5.1 Abordare comparativă”.
Tabelul 1. Indicatori statistici ai setului de date din fișierul „Model comparat total.ods”
Număr total de câmpuri, buc. — 44
Număr total de înregistrări, buc. — 365 490
Numărul total de caractere, buc. — 101 714 693
Numărul mediu de caractere dintr-o înregistrare, buc. — 278,297
Abaterea standard a caracterelor dintr-o înregistrare, buc. — 15,510
Număr minim de caractere într-o intrare, buc. — 198
Numărul maxim de caractere într-o intrare, buc. — 363
2. Partea introductivă. Standarde de bază
În timpul analizării bazei de date specificate, s-a format o sarcină pentru a specifica cerințele pentru gradul de purificare, deoarece, așa cum este clar pentru toată lumea, baza de date specificată creează consecințe juridice și economice pentru utilizatori. În timpul lucrărilor, s-a dovedit că nu existau cerințe specifice pentru gradul de curățare a datelor mari. Analizând normele juridice în această materie, am ajuns la concluzia că toate sunt formate din posibilități. Adică a apărut o anumită sarcină, sunt compilate surse de informații pentru sarcină, apoi se formează un set de date și, pe baza setului de date creat, instrumente pentru rezolvarea problemei. Soluțiile rezultate sunt puncte de referință în alegerea dintre alternative. Am prezentat acest lucru în figura 1.
Întrucât, în materie de stabilire a oricăror standarde, este de preferat să mă bazez pe tehnologii dovedite, am ales cerințele stabilite în , deoarece am considerat acest document cel mai cuprinzător pentru această problemă. În special, în acest document, secțiunea spune „Trebuie remarcat că cerințele de integritate a datelor se aplică în mod egal datelor manuale (de hârtie) și electronice.” (traducere: „...cerințele de integritate a datelor se aplică în mod egal datelor manuale (de hârtie) și electronice”). Această formulare este asociată destul de specific cu conceptul de „probă scrisă”, în dispozițiile art. 71 din Codul de procedură civilă, art. 70 CAS, Art. 75 CPA, „în scris” Art. 84 Cod procedură civilă.
Figura 2 prezintă o diagramă a formării abordărilor tipurilor de informații din jurisprudență.
Orez. 2. Sursa .
Figura 3 prezintă mecanismul din Figura 1, pentru sarcinile „Ghidului” de mai sus. Este ușor, făcând o comparație, să vedem că abordările utilizate la îndeplinirea cerințelor de integritate a informațiilor în standardele moderne pentru sistemele informaționale sunt semnificativ limitate în comparație cu conceptul legal de informație.
Fig. 3
În documentul specificat (Orientări), conexiunea la partea tehnică, capabilitățile de prelucrare și stocare a datelor, este bine confirmată de un citat din capitolul 18.2. Baza de date relațională: „Această structură de fișiere este în mod inerent mai sigură, deoarece datele sunt păstrate într-un format de fișier mare care păstrează relația dintre date și metadate”.
De fapt, în această abordare - din capacitățile tehnice existente, nu există nimic anormal și, în sine, acesta este un proces firesc, întrucât extinderea conceptelor provine din activitatea cea mai studiată - proiectarea bazelor de date. Dar, pe de altă parte, apar norme legale care nu prevăd reduceri la capacitățile tehnice ale sistemelor existente, de exemplu: .
Orez. 4. Pâlnie de capabilități tehnice ().
În aceste aspecte, devine clar că setul de date original (Fig. 1) va trebui, în primul rând, să fie salvat și, în al doilea rând, să fie baza pentru extragerea de informații suplimentare din acesta. Ei bine, de exemplu: camerele care înregistrează regulile de circulație sunt omniprezente, sistemele de procesare a informațiilor îndepărtează infractorii, dar alte informații pot fi oferite și altor consumatori, de exemplu, ca monitorizarea de marketing a structurii fluxului de clienți către un centru comercial. Și aceasta este o sursă de valoare adăugată suplimentară atunci când utilizați BigDat. Este foarte posibil ca seturile de date colectate acum, undeva în viitor, să aibă valoare conform unui mecanism similar cu valoarea edițiilor rare din 1700 în prezent. La urma urmei, de fapt, seturile de date temporare sunt unice și este puțin probabil să se repete în viitor.
3. Partea introductivă. Criteriu de evaluare
În timpul procesului de prelucrare, a fost elaborată următoarea clasificare a erorilor.
1. Clasa de eroare (pe baza GOST R 8.736-2011): a) erori sistematice; b) erori aleatorii; c) o gafă.
2. Prin multiplicitate: a) distorsiune mono; b) multidistorsiune.
3. După criticitatea consecinţelor: a) critic; b) nu este critic.
4. După sursa apariției:
A) Tehnic – erori care apar în timpul funcționării echipamentului. O eroare destul de relevantă pentru sistemele IoT, sisteme cu un grad semnificativ de influență asupra calității comunicațiilor, echipamente (hardware).
B) Erori ale operatorului - erori într-o gamă largă de la greșeli de scriere a operatorului în timpul introducerii până la erori în specificațiile tehnice pentru proiectarea bazei de date.
C) Erori ale utilizatorului - aici sunt erori ale utilizatorului în întreaga gamă de la „am uitat să schimb aspectul” până la confundarea contorului cu picioarele.
5. Separat într-o clasă separată:
a) „sarcina separatorului”, adică spațiul și „:” (în cazul nostru) când a fost duplicat;
b) cuvinte scrise împreună;
c) fără spațiu după caracterele de serviciu
d) simboluri multiple simetric: (), "", "...".
Luat împreună, cu sistematizarea erorilor bazei de date prezentată în Figura 5, se formează un sistem de coordonate destul de eficient pentru căutarea erorilor și dezvoltarea unui algoritm de curățare a datelor pentru acest exemplu.
Orez. 5. Erori tipice corespunzătoare unităților structurale ale bazei de date (Sursa: ).
Acuratețe, Integritate domeniului, Tip de date, Consecvență, Redundanță, Completitudine, Duplicare, Conformitate cu regulile de afaceri, Definiție structurală, Anomalie a datelor, Claritate, Punct de vedere, Respectarea regulilor de integritate a datelor. (Pagina 334. Fundamentele depozitării de date pentru profesioniștii IT / Paulraj Ponniah.—ed. a 2-a)
A fost prezentată formularea în engleză și traducerea automată rusă între paranteze.
Precizie. Valoarea stocată în sistem pentru un element de date este valoarea corectă pentru acea apariție a elementului de date. Dacă aveți un nume de client și o adresă stocate într-o înregistrare, atunci adresa este adresa corectă pentru clientul cu acel nume. Dacă găsiți cantitatea comandată ca 1000 de unități în înregistrarea pentru numărul de comandă 12345678, atunci cantitatea respectivă este cantitatea exactă pentru acea comandă.
[Precizie. Valoarea stocată în sistem pentru un element de date este valoarea corectă pentru acea apariție a elementului de date. Dacă aveți un nume de client și o adresă stocate într-o înregistrare, atunci adresa este adresa corectă pentru clientul cu acel nume. Dacă găsiți cantitatea comandată ca 1000 de unități în înregistrarea pentru numărul de comandă 12345678, atunci acea cantitate este cantitatea exactă pentru acea comandă.]
Integritatea domeniului. Valoarea datelor unui atribut se încadrează în intervalul de valori permise, definite. Exemplul comun este valorile permise fiind „masculin” și „femei” pentru elementul de date de gen.
[Integritatea domeniului. Valoarea datelor de atribut se încadrează în intervalul de valori valide, definite. Un exemplu general sunt valorile valide „masculin” și „femei” pentru un element de date de gen.]
Tip de date. Valoarea pentru un atribut de date este de fapt stocată ca tip de date definit pentru acel atribut. Când tipul de date al câmpului numele magazinului este definit ca „text”, toate instanțele acelui câmp conțin numele magazinului afișat în format textual și nu coduri numerice.
[Tipul de date. Valoarea unui atribut de date este de fapt stocată ca tip de date definit pentru acel atribut. Dacă tipul de date din câmpul numelui magazinului este definit ca „text”, toate instanțele acestui câmp conțin numele magazinului afișat în format text și nu în coduri numerice.]
Consecvență. Forma și conținutul unui câmp de date sunt aceleași în mai multe sisteme surse. Dacă codul de produs pentru produsul ABC într-un sistem este 1234, atunci codul pentru acest produs este 1234 în fiecare sistem sursă.
[Consecvența. Forma și conținutul câmpului de date sunt aceleași în diferite sisteme sursă. Dacă codul de produs pentru produsul ABC pe un sistem este 1234, atunci codul pentru acel produs este 1234 pe fiecare sistem sursă.]
Redundanţă. Aceleași date nu trebuie să fie stocate în mai mult de un loc dintr-un sistem. Dacă, din motive de eficiență, un element de date este stocat în mod intenționat în mai multe locuri dintr-un sistem, atunci redundanța trebuie să fie clar identificată și verificată.
[Redundanţă. Aceleași date nu trebuie stocate în mai mult de un loc din sistem. Dacă, din motive de eficiență, un element de date este stocat în mod intenționat în mai multe locații dintr-un sistem, atunci redundanța trebuie să fie clar definită și verificată.]
Completitudine. Nu există valori lipsă pentru un anumit atribut în sistem. De exemplu, într-un fișier de client, trebuie să existe o valoare validă pentru câmpul „stare” pentru fiecare client. În fișierul pentru detaliile comenzii, fiecare înregistrare de detaliu pentru o comandă trebuie să fie complet completată.
[Completitudine. Nu există valori lipsă în sistem pentru acest atribut. De exemplu, fișierul client trebuie să aibă o valoare validă pentru câmpul „stare” pentru fiecare client. În fișierul cu detaliile comenzii, fiecare înregistrare a detaliilor comenzii trebuie să fie complet completată.]
Dublare. Dublarea înregistrărilor într-un sistem este complet rezolvată. Dacă se știe că fișierul de produs are înregistrări duplicate, atunci toate înregistrările duplicate pentru fiecare produs sunt identificate și se creează o referință încrucișată.
[Duplicat. Dublarea înregistrărilor din sistem a fost complet eliminată. Dacă se știe că un fișier de produs conține intrări duplicate, atunci toate intrările duplicate pentru fiecare produs sunt identificate și se creează o referință încrucișată.]
Conformitatea cu regulile de afaceri. Valorile fiecărui element de date respectă regulile comerciale prescrise. Într-un sistem de licitație, prețul de ciocan sau de vânzare nu poate fi mai mic decât prețul de rezervă. Într-un sistem de credit bancar, soldul creditului trebuie să fie întotdeauna pozitiv sau zero.
[Respectarea regulilor de afaceri. Valorile fiecărui element de date respectă regulile de afaceri stabilite. Într-un sistem de licitație, prețul de ciocan sau de vânzare nu poate fi mai mic decât prețul de rezervă. Într-un sistem de credit bancar, soldul creditului trebuie să fie întotdeauna pozitiv sau zero.]
Definiție structurală. Oriunde un element de date poate fi structurat în mod natural în componente individuale, elementul trebuie să conțină această structură bine definită. De exemplu, numele unei persoane se împarte în mod natural în prenume, inițială de mijloc și nume de familie. Valorile pentru numele persoanelor trebuie să fie stocate ca prenume, inițială de mijloc și nume de familie. Această caracteristică a calității datelor simplifică aplicarea standardelor și reduce valorile lipsă.
[Certitudine structurală. Acolo unde un element de date poate fi structurat în mod natural în componente individuale, elementul trebuie să conțină această structură bine definită. De exemplu, numele unei persoane este împărțit în mod natural în prenume, inițială de mijloc și nume de familie. Valorile pentru nume individuale ar trebui să fie stocate ca prenume, inițială de mijloc și nume de familie. Această caracteristică de calitate a datelor simplifică aplicarea standardelor și reduce valorile lipsă.]
Anomalie de date. Un câmp trebuie utilizat numai în scopul pentru care este definit. Dacă câmpul Adresă-3 este definit pentru orice posibilă a treia linie de adresă pentru adrese lungi, atunci acest câmp trebuie utilizat numai pentru înregistrarea a treia linie de adresă. Nu trebuie utilizat pentru introducerea unui număr de telefon sau de fax pentru client.
[Anomalie de date. Un câmp trebuie utilizat numai în scopul pentru care este definit. Dacă câmpul Adresă-3 este definit pentru orice a treia linie de adresă posibilă pentru adrese lungi, atunci acest câmp va fi utilizat numai pentru a înregistra a treia linie de adresă. Nu trebuie folosit pentru a introduce un număr de telefon sau de fax pentru un client.]
Claritate. Un element de date poate avea toate celelalte caracteristici ale datelor de calitate, dar dacă utilizatorii nu înțeleg în mod clar sensul acestuia, atunci elementul de date nu are nicio valoare pentru utilizatori. Convențiile de denumire adecvate ajută la ca elementele de date să fie bine înțelese de către utilizatori.
[Claritate. Un element de date poate avea toate celelalte caracteristici ale unor date bune, dar dacă utilizatorii nu înțeleg clar semnificația acestuia, atunci elementul de date nu are nicio valoare pentru utilizatori. Convențiile corecte de denumire ajută la ca elementele de date să fie bine înțelese de utilizatori.]
în timp util. Utilizatorii determină actualitatea datelor. Dacă utilizatorii se așteaptă ca datele despre dimensiunea clientului să nu fie mai vechi de o zi, modificările aduse datelor clienților în sistemele sursă trebuie aplicate zilnic depozitului de date.
[În timp util. Utilizatorii determină actualitatea datelor. Dacă utilizatorii se așteaptă ca datele despre dimensiunea clienților să aibă o vechime de cel mult o zi, modificările aduse datelor clienților din sistemele sursă ar trebui aplicate în depozitul de date zilnic.]
Utilitate. Fiecare element de date din depozitul de date trebuie să satisfacă anumite cerințe ale colecției de utilizatori. Un element de date poate fi precis și de înaltă calitate, dar dacă nu are nicio valoare pentru utilizatori, atunci este complet inutil ca acel element de date să fie în depozitul de date.
[Utilitate. Fiecare element de date din depozitul de date trebuie să îndeplinească anumite cerințe ale colecției utilizatorilor. Un element de date poate fi precis și de înaltă calitate, dar dacă nu oferă valoare utilizatorilor, atunci nu este necesar ca acel element de date să fie în depozitul de date.]
Respectarea regulilor de integritate a datelor. Datele stocate în bazele de date relaționale ale sistemelor sursă trebuie să respecte regulile de integritate a entității și de integritate referențială. Orice tabel care permite null ca cheie primară nu are integritate de entitate. Integritatea referenţială forţează stabilirea corectă a relaţiilor părinte-copil. Într-o relație client-la-comandă, integritatea referențială asigură existența unui client pentru fiecare comandă din baza de date.
[Respectarea regulilor de integritate a datelor. Datele stocate în bazele de date relaționale ale sistemelor sursă trebuie să respecte regulile de integritate a entității și de integritate referențială. Orice tabel care permite null ca cheie primară nu are integritate de entitate. Integritatea referenţială obligă relaţia dintre părinţi şi copii să fie stabilită corect. Într-o relație client-comandă, integritatea referențială asigură existența unui client pentru fiecare comandă din baza de date.]
4. Calitatea curățării datelor
Calitatea curățării datelor este o problemă destul de problematică în bigdata. Răspunsul la întrebarea ce grad de curățare a datelor este necesar pentru a finaliza sarcina este fundamental pentru fiecare analist de date. În majoritatea problemelor actuale, fiecare analist determină singur acest lucru și este puțin probabil ca cineva din exterior să poată evalua acest aspect în soluția sa. Dar pentru sarcina în cauză în acest caz, această problemă a fost extrem de importantă, deoarece fiabilitatea datelor juridice ar trebui să tindă la una.
Luând în considerare tehnologiile de testare a software-ului pentru a determina fiabilitatea operațională. Astăzi există mai multe decât aceste modele . Multe dintre modele folosesc un model de gestionare a reclamațiilor:
Fig. 6
Gândindu-vă după cum urmează: „Dacă eroarea găsită este un eveniment similar cu evenimentul de eșec din acest model, atunci cum să găsiți un analog al parametrului t?” Și am compilat următorul model: Să ne imaginăm că timpul necesar unui tester pentru a verifica o înregistrare este de 1 minut (pentru baza de date în cauză), apoi pentru a găsi toate erorile va avea nevoie de 365 de minute, adică aproximativ 494 ani și 3 luni de timp de lucru. După cum înțelegem, aceasta este o cantitate foarte mare de muncă și costurile de verificare a bazei de date vor fi prohibitive pentru compilatorul acestei baze de date. În această reflecție apare conceptul economic al costurilor și în urma analizei am ajuns la concluzia că acesta este un instrument destul de eficient. Pe baza legii economiei: „Volumul de producție (în unități) la care se realizează profitul maxim al unei firme este situat în punctul în care costul marginal al producerii unei noi unități de producție este comparat cu prețul pe care îl poate primi această firmă. pentru o unitate nouă.” Pe baza postulatului că găsirea fiecărei erori ulterioare necesită din ce în ce mai multă verificare a înregistrărilor, acesta este un factor de cost. Adică, postulatul adoptat în testarea modelelor capătă o semnificație fizică în următorul model: dacă pentru a găsi eroarea i-a a fost necesar să se verifice n înregistrări, atunci pentru a găsi următoarea eroare (i+3) va fi necesar. pentru a verifica m înregistrări și în același timp n
- Când numărul de înregistrări verificate înainte de a fi găsită o nouă eroare se stabilizează;
- Când numărul de înregistrări verificate înainte de a găsi următoarea eroare va crește.
Pentru a determina valoarea critică, am apelat la conceptul de fezabilitate economică, care în acest caz, folosind conceptul de costuri sociale, poate fi formulat astfel: „Costurile de corectare a erorii trebuie suportate de agentul economic care poate face la cel mai mic cost.” Avem un agent - un tester care petrece 1 minut verificând o înregistrare. În termeni monetari, dacă câștigi 6000 de ruble/zi, aceasta va fi de 12,2 ruble. (aproximativ astăzi). Rămâne de determinat a doua latură a echilibrului în dreptul economic. Am raționat așa. O eroare existentă va cere persoanei în cauză să depună eforturi pentru a o corecta, adică proprietarul proprietății. Să presupunem că acest lucru necesită 1 zi de acțiune (trimiteți o cerere, primiți un document corectat). Apoi, din punct de vedere social, costurile lui vor fi egale cu salariul mediu pe zi. Salariul mediu acumulat în Khanty-Mansi Autonomous Okrug 73285 rub. sau 3053,542 ruble/zi. În consecință, obținem o valoare critică egală cu:
3053,542: 12,2 = 250,4 unități de înregistrări.
Aceasta înseamnă, din punct de vedere social, dacă un tester a verificat 251 de înregistrări și a găsit o eroare, echivalează cu faptul că utilizatorul remedia singur această eroare. În consecință, dacă testerul a petrecut timp egal cu verificarea a 252 de înregistrări pentru a găsi următoarea eroare, atunci în acest caz este mai bine să transferați costul corecției către utilizator.
O abordare simplificată este prezentată aici, întrucât din punct de vedere social este necesar să se țină cont de toată valoarea suplimentară generată de fiecare specialist, adică de costuri inclusiv taxe și plăți sociale, dar modelul este clar. O consecință a acestei relații este următoarea cerință pentru specialiști: un specialist din industria IT trebuie să aibă un salariu mai mare decât media națională. Dacă salariul său este mai mic decât salariul mediu al potențialilor utilizatori ai bazei de date, atunci el însuși trebuie să verifice întreaga bază de date corp la corp.
Atunci când se utilizează criteriul descris, se formează prima cerință pentru calitatea bazei de date:
eu (tr). Ponderea erorilor critice nu trebuie să depășească 1/250,4 = 0,39938%. Puțin mai puțin decât aur în industrie. Și în termeni fizici nu există mai mult de 1459 de înregistrări cu erori.
Retragere economică.
De fapt, făcând un astfel de număr de erori în înregistrări, societatea este de acord cu pierderi economice în valoare de:
1459*3053,542 = 4 ruble.
Această sumă este determinată de faptul că societatea nu dispune de instrumentele necesare pentru a reduce aceste costuri. Rezultă că, dacă cineva are o tehnologie care îi permite să reducă numărul de înregistrări cu erori la, de exemplu, 259, atunci aceasta va permite societății să salveze:
1200*3053,542 = 3 ruble.
Dar, în același timp, își poate cere talentul și munca, ei bine, să spunem - 1 milion de ruble.
Adică, costurile sociale sunt reduse prin:
3 – 664 = 250 de ruble.
În esență, acest efect este valoarea adăugată din utilizarea tehnologiilor BigDat.
Dar aici trebuie luat în considerare faptul că acesta este un efect social, iar proprietarul bazei de date sunt autoritățile municipale, venitul acestora din utilizarea proprietății înregistrate în această bază de date, la o rată de 0,3%, este de: 2,778 miliarde ruble/ an. Și aceste costuri (4 ruble) nu-l deranjează prea mult, deoarece sunt transferate proprietarilor de proprietăți. Și, sub acest aspect, dezvoltatorul mai multor tehnologii de rafinare în Bigdata va trebui să demonstreze capacitatea de a convinge proprietarul acestei baze de date, iar astfel de lucruri necesită un talent considerabil.
În acest exemplu, algoritmul de evaluare a erorilor a fost ales pe baza modelului Schumann [2] de verificare a software-ului în timpul testării de fiabilitate. Datorită prevalenței sale pe Internet și a capacității de a obține indicatorii statistici necesari. Metodologia este preluată de la Monakhov Yu.M. „Stabilitatea funcțională a sistemelor informaționale”, vezi sub spoilerul din Fig. 7-9.
Orez. 7 – 9 Metodologia modelului Schumann
A doua parte a acestui material prezintă un exemplu de curățare a datelor, în care se obțin rezultatele utilizării modelului Schumann.
Permiteți-mi să vă prezint rezultatele obținute:
Număr estimat de erori N = 3167 n.
Parametrul C, lambda și funcție de fiabilitate:
Fig. 17
În esență, lambda este un indicator real al intensității cu care erorile sunt detectate în fiecare etapă. Dacă te uiți la a doua parte, estimarea pentru acest indicator a fost de 42,4 erori pe oră, ceea ce este destul de comparabil cu indicatorul Schumann. Mai sus, s-a stabilit că rata la care un dezvoltator găsește erori nu trebuie să fie mai mică de 1 eroare la 250,4 înregistrări, atunci când verifică 1 înregistrare pe minut. De aici valoarea critică a lambda pentru modelul Schumann:
60 / 250,4 = 0,239617.
Adică, necesitatea efectuării procedurilor de detectare a erorilor trebuie efectuată până când lambda, de la 38,964 existent, scade la 0,239617.
Sau până când indicatorul N (numărul potențial de erori) minus n (numărul corectat de erori) scade sub pragul nostru acceptat - 1459 buc.
Literatură
- Monakhov, Yu. M. Stabilitatea funcțională a sistemelor informaționale. În 3 ore.Partea 1. Fiabilitatea software: manual. indemnizație / Yu. M. Monahov; Vladim. stat univ. – Vladimir: Izvo Vladim. stat Universitatea, 2011. – 60 p. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman, „Modele probabilistice pentru predicția fiabilității software”.
- Fundamentele depozitării de date pentru profesioniștii IT / Paulraj Ponniah.—ed. a II-a.
Sursa: www.habr.com