1. Počiatočné údaje
Čistenie údajov je jednou z výziev, ktorým čelia úlohy analýzy údajov. Tento materiál odrážal vývoj a riešenia, ktoré vznikli v dôsledku riešenia praktického problému analýzy databázy pri tvorbe katastrálnej hodnoty. Zdroje tu .
Uvažovalo sa o súbore „Porovnávací model total.ods“ v „Príloha B. Výsledky stanovenia KS 5. Informácie o spôsobe určenia katastrálnej hodnoty 5.1 Porovnávací prístup“.
Tabuľka 1. Štatistické ukazovatele súboru údajov v súbore „Porovnávací model total.ods“
Celkový počet polí, ks. — 44
Celkový počet záznamov, ks. — 365 490
Celkový počet znakov, ks. — 101 714 693
Priemerný počet znakov v zázname, ks. — 278,297 XNUMX
Smerodajná odchýlka znakov v zázname, ks. — 15,510 XNUMX
Minimálny počet znakov v zázname, ks. — 198
Maximálny počet znakov v zázname, ks. — 363
2. Úvodná časť. Základné štandardy
Pri analýze zadanej databázy bola vytvorená úloha špecifikovať požiadavky na stupeň čistenia, keďže ako je každému jasné, zadaná databáza vytvára pre užívateľov právne a ekonomické dôsledky. Počas prác sa ukázalo, že neexistujú žiadne špecifické požiadavky na mieru čistenia veľkých dát. Pri analýze právnych noriem v tejto veci som dospel k záveru, že všetky sú tvorené z možností. To znamená, že sa objavila určitá úloha, zostavili sa informačné zdroje pre úlohu, potom sa vytvoril súbor údajov a na základe vytvoreného súboru údajov nástroje na riešenie problému. Výsledné riešenia sú referenčnými bodmi pri výbere z alternatív. Uviedol som to na obrázku 1.
Keďže v otázkach určovania akýchkoľvek noriem je vhodnejšie spoliehať sa na osvedčené technológie, zvolil som požiadavky uvedené v , pretože tento dokument som považoval za najkomplexnejší pre túto problematiku. Konkrétne v tomto dokumente sa v časti hovorí: „Je potrebné poznamenať, že požiadavky na integritu údajov platia rovnako pre manuálne (papierové) aj elektronické údaje. (preklad: „...požiadavky na integritu údajov platia rovnako pre manuálne (papierové) aj elektronické údaje“). Táto formulácia je celkom špecificky spojená s pojmom „písomný dôkaz“ v ustanovení § 71 Občianskeho súdneho poriadku, čl. 70 CAS, článok 75 APC, „písomne“ čl. 84 Občianskeho súdneho poriadku.
Obrázok 2 predstavuje diagram formovania prístupov k typom informácií v judikatúre.
Ryža. 2. Zdroj .
Obrázok 3 zobrazuje mechanizmus z obrázku 1 pre úlohy vyššie uvedeného „Poradenia“. Porovnaním možno ľahko zistiť, že prístupy používané pri plnení požiadaviek na integritu informácií v moderných štandardoch pre informačné systémy sú v porovnaní s právnym pojmom informácie výrazne obmedzené.
Obr
V uvedenom dokumente (Pokyno) je prepojenie na technickú časť, možnosti spracovania a ukladania údajov dobre potvrdené citátom z kapitoly 18.2. Relačná databáza: "Táto štruktúra súborov je vo svojej podstate bezpečnejšia, pretože údaje sú uchovávané vo veľkom formáte súboru, ktorý zachováva vzťah medzi údajmi a metaúdajmi."
V skutočnosti v tomto prístupe - z existujúcich technických možností, nie je nič abnormálne a samo osebe je to prirodzený proces, pretože rozširovanie konceptov pochádza z najviac študovanej činnosti - návrhu databázy. Na druhej strane sa však objavujú právne normy, ktoré neposkytujú zľavy na technické možnosti existujúcich systémov, napr. .
Ryža. 4. Lievik technických možností ().
V týchto aspektoch je zrejmé, že pôvodný súbor údajov (obr. 1) bude musieť byť v prvom rade uložený a v druhom rade byť základom pre extrahovanie dodatočných informácií z neho. Napríklad: kamery zaznamenávajúce pravidlá cestnej premávky sú všadeprítomné, systémy na spracovanie informácií odstraňujú porušovateľov, ale ďalšie informácie možno ponúknuť aj iným spotrebiteľom, napríklad ako marketingový monitoring štruktúry toku zákazníkov do obchodného centra. A to je zdrojom ďalšej pridanej hodnoty pri používaní BigDat. Je celkom možné, že súbory údajov, ktoré sa zhromažďujú teraz, niekde v budúcnosti, budú mať hodnotu podľa mechanizmu podobnom hodnote vzácnych edícií 1700 v súčasnosti. Koniec koncov, dočasné súbory údajov sú jedinečné a je nepravdepodobné, že by sa v budúcnosti opakovali.
3. Úvodná časť. Hodnotiace kritériá
Počas procesu spracovania bola vyvinutá nasledujúca klasifikácia chýb.
1. Trieda chýb (na základe GOST R 8.736-2011): a) systematické chyby; b) náhodné chyby; c) omyl.
2. Podľa násobnosti: a) mono skreslenie; b) viacnásobné skreslenie.
3. Podľa kritickosti následkov: a) kritické; b) nie je kritická.
4. Podľa zdroja výskytu:
A) Technické – chyby, ktoré sa vyskytnú počas prevádzky zariadenia. Pomerne relevantná chyba pre IoT systémy, systémy s výraznou mierou vplyvu na kvalitu komunikácie, vybavenie (hardvér).
B) Chyby operátora – chyby v širokom rozsahu od preklepov operátora počas zadávania až po chyby v technických špecifikáciách pre návrh databázy.
C) Chyby používateľa – tu sú chyby používateľa v celom rozsahu od „zabudnutia prepnúť rozloženie“ až po omyly metrov za stopy.
5. Rozdelené do samostatnej triedy:
a) „úloha oddeľovača“, teda medzera a „:“ (v našom prípade), keď bol duplikovaný;
b) slová písané spolu;
c) žiadna medzera za servisnými znakmi
d) symetricky viacnásobné symboly: (), "", "...".
Spolu so systematizáciou databázových chýb zobrazených na obrázku 5 je vytvorený pomerne efektívny súradnicový systém na vyhľadávanie chýb a vývoj algoritmu čistenia dát pre tento príklad.
Ryža. 5. Typické chyby zodpovedajúce štrukturálnym jednotkám databázy (Zdroj: ).
Presnosť, integrita domény, typ údajov, konzistencia, redundancia, úplnosť, duplikácia, súlad s obchodnými pravidlami, štrukturálna jednoznačnosť, anomália údajov, jasnosť, včasnosť, dodržiavanie pravidiel integrity údajov. (Strana 334. Základy dátového skladu pre IT profesionálov / Paulraj Ponniah.—2. vydanie)
Prezentované anglické znenie a ruský strojový preklad v zátvorkách.
Presnosť. Hodnota uložená v systéme pre dátový prvok je správna hodnota pre daný výskyt dátového prvku. Ak máte v zázname uložené meno zákazníka a adresu, potom je adresa správnou adresou zákazníka s týmto menom. Ak v zázname pre číslo objednávky 1000 nájdete objednané množstvo ako 12345678 XNUMX jednotiek, potom je toto množstvo presným množstvom pre danú objednávku.
[Presnosť. Hodnota uložená v systéme pre dátový prvok je správnou hodnotou pre daný výskyt dátového prvku. Ak máte v zázname uložené meno a adresu zákazníka, potom je adresa správnou adresou zákazníka s týmto menom. Ak v zázname pre číslo objednávky 1000 nájdete objednané množstvo ako 12345678 XNUMX jednotiek, potom toto množstvo predstavuje presné množstvo pre danú objednávku.]
Integrita domény. Údajová hodnota atribútu spadá do rozsahu povolených definovaných hodnôt. Bežným príkladom sú povolené hodnoty pre dátový prvok pohlavia „muž“ a „žena“.
[Integrita domény. Údajová hodnota atribútu spadá do rozsahu platných definovaných hodnôt. Všeobecným príkladom sú platné hodnoty „male“ a „female“ pre dátový prvok pohlavia.]
Dátový typ. Hodnota pre dátový atribút je v skutočnosti uložená ako dátový typ definovaný pre daný atribút. Keď je typ údajov poľa názvu obchodu definovaný ako „text“, všetky výskyty tohto poľa obsahujú názov obchodu zobrazený v textovom formáte a nie číselné kódy.
[Dátový typ. Hodnota dátového atribútu je v skutočnosti uložená ako dátový typ definovaný pre daný atribút. Ak je typ údajov poľa názvu obchodu definovaný ako „text“, všetky výskyty tohto poľa obsahujú názov obchodu zobrazený v textovom formáte a nie v číselných kódoch.]
Dôslednosť. Forma a obsah dátového poľa sú rovnaké vo viacerých zdrojových systémoch. Ak je kód produktu pre produkt ABC v jednom systéme 1234, potom kód pre tento produkt je 1234 v každom zdrojovom systéme.
[Konzistentnosť. Forma a obsah dátového poľa sú rovnaké v rôznych zdrojových systémoch. Ak je kód produktu pre produkt ABC v jednom systéme 1234, potom je kód pre tento produkt 1234 v každom zdrojovom systéme.]
Nadbytok. Tie isté údaje nesmú byť v systéme uložené na viac ako jednom mieste. Ak je dátový prvok z dôvodov efektívnosti zámerne uložený na viac ako jednom mieste v systéme, potom je potrebné jasne identifikovať a overiť nadbytočnosť.
[Nadbytok. Rovnaké údaje by nemali byť uložené na viac ako jednom mieste v systéme. Ak je dátový prvok z dôvodov efektívnosti zámerne uložený na viacerých miestach v systéme, potom musí byť redundancia jasne definovaná a overená.]
Úplnosť. V systéme nechýbajú žiadne hodnoty pre daný atribút. Napríklad v súbore zákazníka musí byť pre každého zákazníka platná hodnota pre pole „state“. V súbore podrobností o objednávke musí byť úplne vyplnený každý podrobný záznam objednávky.
[Úplnosť. Pre tento atribút v systéme chýbajú žiadne hodnoty. Napríklad súbor klienta musí mať platnú hodnotu pre pole "stav" pre každého klienta. V súbore podrobností o objednávke musí byť každý podrobný záznam objednávky kompletne vyplnený.]
Duplikácia. Duplikácia záznamov v systéme je úplne vyriešená. Ak je známe, že súbor produktu obsahuje duplicitné záznamy, identifikujú sa všetky duplicitné záznamy pre každý produkt a vytvorí sa krížový odkaz.
[Duplikovať. Duplikácia záznamov v systéme bola úplne odstránená. Ak je známe, že súbor produktu obsahuje duplicitné položky, identifikujú sa všetky duplicitné položky pre každý produkt a vytvorí sa krížový odkaz.]
Súlad s obchodnými pravidlami. Hodnoty každej údajovej položky sa riadia predpísanými obchodnými pravidlami. V aukčnom systéme nesmie byť príklepová alebo predajná cena nižšia ako vyvolávacia cena. V systéme bankových pôžičiek musí byť zostatok úveru vždy kladný alebo nulový.
[Dodržiavanie obchodných pravidiel. Hodnoty každého dátového prvku sú v súlade so zavedenými obchodnými pravidlami. V aukčnom systéme nesmie byť príklepová alebo predajná cena nižšia ako vyvolávacia cena. V bankovom úverovom systéme musí byť zostatok úveru vždy kladný alebo nulový.]
Štrukturálna jednoznačnosť. Všade tam, kde je možné dátovú položku prirodzene štruktúrovať do jednotlivých komponentov, musí položka túto dobre definovanú štruktúru obsahovať. Napríklad meno jednotlivca sa prirodzene delí na krstné meno, stredné iniciály a priezvisko. Hodnoty mien jednotlivcov musia byť uložené ako krstné meno, iniciála stredného písmena a priezvisko. Táto charakteristika kvality údajov zjednodušuje uplatňovanie noriem a znižuje chýbajúce hodnoty.
[Štrukturálna istota. Ak je možné dátový prvok prirodzene štruktúrovať do jednotlivých komponentov, prvok musí obsahovať túto dobre definovanú štruktúru. Napríklad meno osoby sa prirodzene delí na krstné meno, stredné iniciály a priezvisko. Hodnoty pre jednotlivé mená by mali byť uložené ako krstné meno, iniciála stredného písmena a priezvisko. Táto charakteristika kvality údajov zjednodušuje aplikáciu noriem a znižuje chýbajúce hodnoty.]
Dátová anomália. Pole sa musí používať iba na účel, na ktorý je definované. Ak je pole Adresa-3 definované pre akýkoľvek možný tretí riadok adresy pre dlhé adresy, potom sa toto pole musí použiť len na zaznamenanie tretieho riadku adresy. Nesmie sa použiť na zadanie telefónneho alebo faxového čísla zákazníka.
[Anomália údajov. Pole sa musí používať iba na účel, na ktorý je definované. Ak je pole Adresa-3 definované pre akýkoľvek možný tretí riadok adresy pre dlhé adresy, potom sa toto pole použije len na zaznamenanie tretieho riadku adresy. Nemalo by sa používať na zadávanie telefónneho alebo faxového čísla zákazníka.]
Jasnosť. Údajový prvok môže mať všetky ostatné charakteristiky údajov o kvalite, ale ak používatelia jasne nerozumejú jeho významu, potom údajový prvok nemá pre používateľov žiadnu hodnotu. Správne konvencie pomenovania pomáhajú používateľom dobre porozumieť dátovým prvkom.
[Jasnosť. Dátový prvok môže mať všetky ostatné charakteristiky dobrých údajov, ale ak používatelia jasne nerozumejú jeho významu, potom údajový prvok nemá pre používateľov žiadnu hodnotu. Správne konvencie pomenovania pomáhajú používateľom dobre porozumieť dátovým prvkom.]
Včasné. Používatelia určujú aktuálnosť údajov. Ak používatelia očakávajú, že údaje zákazníckej dimenzie nebudú staršie ako jeden deň, zmeny údajov o zákazníkoch v zdrojových systémoch sa musia aplikovať do dátového skladu denne.
[Včas. Používatelia určujú aktuálnosť údajov. Ak používatelia očakávajú, že údaje zákazníckej dimenzie nebudú staršie ako jeden deň, zmeny údajov o zákazníkoch v zdrojových systémoch by sa mali aplikovať na dátový sklad na dennej báze.]
Užitočnosť. Každý dátový prvok v dátovom sklade musí spĺňať určité požiadavky zberu užívateľov. Údajový prvok môže byť presný a má vysokú kvalitu, ale ak nemá pre používateľov žiadnu hodnotu, potom je úplne zbytočné, aby bol v dátovom sklade.
[Úžitok. Každá dátová položka v dátovom sklade musí spĺňať určité požiadavky užívateľskej kolekcie. Údajový prvok môže byť presný a má vysokú kvalitu, ale ak neposkytuje používateľom hodnotu, nie je potrebné, aby bol v dátovom sklade.]
Dodržiavanie pravidiel integrity údajov. Údaje uložené v relačných databázach zdrojových systémov musia dodržiavať pravidlá integrity entity a referenčnej integrity. Každá tabuľka, ktorá povoľuje null ako primárny kľúč, nemá integritu entity. Referenčná integrita núti správne nadviazať vzťahy medzi rodičmi a deťmi. Vo vzťahu zákazník-objednávka referenčná integrita zabezpečuje existenciu zákazníka pre každú objednávku v databáze.
[Dodržiavanie pravidiel integrity údajov. Údaje uložené v relačných databázach zdrojových systémov musia spĺňať pravidlá integrity entity a referenčnej integrity. Každá tabuľka, ktorá povoľuje null ako primárny kľúč, nemá integritu entity. Referenčná integrita núti správne nadviazať vzťah medzi rodičmi a deťmi. Vo vzťahu medzi zákazníkmi a objednávkami referenčná integrita zaisťuje existenciu zákazníka pre každú objednávku v databáze.]
4. Kvalita čistenia dát
Kvalita čistenia dát je v bigdata dosť problematická záležitosť. Odpoveď na otázku, aký stupeň čistenia dát je potrebný na splnenie úlohy, je základom pre každého dátového analytika. Vo väčšine súčasných problémov si to každý analytik určuje sám a je nepravdepodobné, že by niekto zvonku dokázal tento aspekt pri jeho riešení vyhodnotiť. Ale pre danú úlohu v tomto prípade bola táto otázka mimoriadne dôležitá, pretože spoľahlivosť právnych údajov by mala smerovať k jednej.
Zváženie technológií testovania softvéru na určenie prevádzkovej spoľahlivosti. Dnes je ich viac ako týchto modelov . Mnohé z modelov používajú model servisu pohľadávok:
Obr. 6
Myslite takto: "Ak je nájdená chyba udalosťou podobnou udalosti zlyhania v tomto modeli, ako potom nájsť analóg parametra t?" A zostavil som nasledujúci model: Predstavme si, že testerovi trvá kontrola jedného záznamu 1 minútu (pre danú databázu), potom na nájdenie všetkých chýb bude potrebovať 365 494 minút, čo sú približne 3 roky a 3 mesiacov pracovného času. Ako vieme, je to veľmi veľké množstvo práce a náklady na kontrolu databázy budú pre zostavovateľa tejto databázy neúmerné. V tejto úvahe sa objavuje ekonomický koncept nákladov a po analýze som dospel k záveru, že ide o pomerne efektívny nástroj. Na základe zákona ekonómie: „Objem výroby (v jednotkách), pri ktorom sa dosahuje maximálny zisk firmy, sa nachádza v bode, kde sa hraničné náklady na výrobu novej jednotky výstupu porovnávajú s cenou, ktorú môže táto firma dostať. pre novú jednotku." Na základe postulátu, že nájdenie každej ďalšej chyby si vyžaduje čoraz viac kontroly záznamov, ide o nákladový faktor. To znamená, že postulát prijatý v testovacích modeloch nadobúda fyzický význam v nasledujúcom vzore: ak na nájdenie i-tej chyby bolo potrebné skontrolovať n záznamov, potom na nájdenie ďalšej (i+1) chyby bude potrebné kontrolovať m záznamov a zároveň n
- Keď sa počet záznamov kontrolovaných pred zistením novej chyby stabilizuje;
- Keď sa počet záznamov skontrolovaných pred nájdením ďalšej chyby zvýši.
Na určenie kritickej hodnoty som sa obrátil na koncept ekonomickej uskutočniteľnosti, ktorý v tomto prípade s použitím konceptu sociálnych nákladov možno formulovať takto: „Náklady na opravu chyby by mal znášať ekonomický subjekt, ktorý môže za najnižšiu cenu." Máme jedného agenta – testera, ktorý strávi 1 minútu kontrolou jedného záznamu. V peňažnom vyjadrení, ak zarobíte 6000 12,2 rubľov za deň, bude to 1 rubľov. (približne dnes). Zostáva určiť druhú stranu rovnováhy v hospodárskom práve. Zdôvodnil som to takto. Existujúca chyba bude vyžadovať, aby dotknutá osoba vynaložila úsilie na jej nápravu, teda vlastník nehnuteľnosti. Povedzme, že to vyžaduje XNUMX deň akcie (odoslanie žiadosti, prijatie opraveného dokumentu). Potom sa zo sociálneho hľadiska jeho náklady budú rovnať priemernej mzde na deň. Priemerná akumulovaná mzda v autonómnom okruhu Chanty-Mansi 73285 rub. alebo 3053,542 XNUMX rubľov/deň. Podľa toho získame kritickú hodnotu rovnajúcu sa:
3053,542: 12,2 = 250,4 jednotiek záznamov.
To znamená, že zo sociálneho hľadiska, ak tester skontroloval 251 záznamov a našiel jednu chybu, je to ekvivalentné tomu, že používateľ túto chybu sám opraví. Ak teda tester strávil čas rovnajúci sa kontrole 252 záznamov, aby našiel ďalšiu chybu, potom je v tomto prípade lepšie presunúť náklady na opravu na používateľa.
Je tu prezentovaný zjednodušený prístup, keďže zo sociálneho hľadiska je potrebné brať do úvahy všetku dodatočnú hodnotu generovanú každým špecialistom, teda náklady vrátane daní a sociálnych platieb, ale model je jasný. Dôsledkom tohto vzťahu je požiadavka na špecialistov: špecialista z IT priemyslu musí mať plat vyšší ako je celoštátny priemer. Ak je jeho mzda nižšia ako priemerná mzda potenciálnych používateľov databázy, musí si sám skontrolovať celú databázu z ruky do ruky.
Pri použití opísaného kritéria vzniká prvá požiadavka na kvalitu databázy:
I(tr). Podiel kritických chýb by nemal presiahnuť 1/250,4 = 0,39938 %. O niečo menej ako zlato v priemysle. A vo fyzickom vyjadrení neexistuje viac ako 1459 záznamov s chybami.
Ekonomický ústup.
V skutočnosti tým, že spoločnosť urobí takýto počet chýb v záznamoch, súhlasí s ekonomickými stratami vo výške:
1459 * 3053,542 = 4 455 118 rubľov.
Táto suma je daná tým, že spoločnosť nemá nástroje na zníženie týchto nákladov. Z toho vyplýva, že ak má niekto technológiu, ktorá mu umožňuje znížiť počet záznamov s chybami napríklad na 259, potom to spoločnosti umožní ušetriť:
1200 * 3053,542 = 3 664 250 rubľov.
Zároveň však môže požiadať o svoj talent a prácu, povedzme - 1 milión rubľov.
To znamená, že sociálne náklady sa znížia o:
3 664 250 – 1 000 000 = 2 664 250 rubľov.
Tento efekt je v podstate pridanou hodnotou z využívania technológií BigDat.
Tu však treba brať do úvahy, že ide o sociálny efekt a vlastníkom databázy sú obecné úrady, ich príjem z používania majetku evidovaného v tejto databáze pri sadzbe 0,3 % je: 2,778 miliardy rubľov/ rok. A tieto náklady (4 455 118 rubľov) ho veľmi neobťažujú, pretože sa prenášajú na vlastníkov nehnuteľností. A v tomto aspekte bude musieť vývojár rafinovanejších technológií v Bigdata preukázať schopnosť presvedčiť vlastníka tejto databázy, a takéto veci si vyžadujú značný talent.
V tomto príklade bol algoritmus hodnotenia chýb zvolený na základe Schumannovho modelu [2] overovania softvéru počas testovania spoľahlivosti. Vzhľadom na jeho rozšírenosť na internete a možnosť získať potrebné štatistické ukazovatele. Metodika je prevzatá z Monakhova Yu.M. „Funkčná stabilita informačných systémov“, pozri pod spojlerom na obr. 7-9.
Ryža. 7 – 9 Metodika Schumannovho modelu
Druhá časť tohto materiálu predstavuje príklad čistenia dát, pri ktorom sa získajú výsledky použitia Schumannovho modelu.
Dovoľte mi predstaviť získané výsledky:
Odhadovaný počet chýb N = 3167 n.
Parameter C, lambda a funkcia spoľahlivosti:
Obr
V podstate je lambda skutočným indikátorom intenzity, s akou sa zisťujú chyby v každej fáze. Ak sa pozriete na druhú časť, odhad pre tento ukazovateľ bol 42,4 chýb za hodinu, čo je celkom porovnateľné so Schumannovým ukazovateľom. Vyššie bolo stanovené, že miera, pri ktorej vývojár nachádza chyby, by nemala byť nižšia ako 1 chyba na 250,4 záznamov pri kontrole 1 záznamu za minútu. Preto kritická hodnota lambda pre Schumannov model:
60 / 250,4 = 0,239617.
To znamená, že je potrebné vykonať postupy zisťovania chýb, kým lambda z existujúcich 38,964 neklesne na 0,239617.
Alebo kým indikátor N (potenciálny počet chýb) mínus n (opravený počet chýb) neklesne pod našu akceptovanú hranicu - 1459 ks.
Literatúra
- Monakhov, Yu.M. Funkčná stabilita informačných systémov. Za 3 hodiny Časť 1. Spoľahlivosť softvéru: učebnica. príspevok / Yu. M. Monakhov; Vladim. štát univ. – Vladimír: Izvo Vladim. štát Univerzita, 2011. – 60 s. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman, „Pravdepodobnostné modely na predikciu spoľahlivosti softvéru“.
- Základy dátového skladu pre IT profesionálov / Paulraj Ponniah.—2nd ed.
Zdroj: hab.com