1. Počáteční údaje
Čištění dat je jednou z výzev, kterým čelí úkoly analýzy dat. Tento materiál odrážel vývoj a řešení, která vznikla v důsledku řešení praktického problému analýzy databáze při tvorbě katastrální hodnoty. Zdroje zde .
Byl uvažován soubor „Srovnávací model total.ods“ v „Příloze B. Výsledky stanovení KS 5. Informace o způsobu stanovení katastrální hodnoty 5.1 Srovnávací přístup“.
Tabulka 1. Statistické ukazatele datového souboru v souboru „Srovnávací model total.ods“
Celkový počet polí, ks. — 44
Celkový počet záznamů, ks. — 365 490
Celkový počet znaků, ks. — 101 714 693
Průměrný počet znaků v záznamu, ks. — 278,297 XNUMX
Směrodatná odchylka znaků v záznamu, ks. — 15,510 XNUMX
Minimální počet znaků v záznamu, ks. — 198
Maximální počet znaků v záznamu, ks. — 363
2. Úvodní část. Základní standardy
Při analýze zadané databáze byl vytvořen úkol specifikovat požadavky na stupeň čištění, neboť jak je každému jasné, zadaná databáze vytváří pro uživatele právní a ekonomické důsledky. V průběhu práce se ukázalo, že neexistují žádné specifické požadavky na míru čištění velkých dat. Rozborem právních norem v této věci jsem došel k závěru, že všechny jsou tvořeny z možností. To znamená, že se objevila určitá úloha, sestaví se informační zdroje pro úlohu, následně se vytvoří datová sada a na základě vytvořené datové sady nástroje pro řešení problému. Výsledná řešení jsou referenčními body při výběru z alternativ. Představil jsem to na obrázku 1.
Protože v otázkách stanovení jakýchkoli norem je vhodnější spoléhat se na osvědčené technologie, zvolil jsem požadavky uvedené v , protože jsem tento dokument považoval za nejobsáhlejší pro tuto problematiku. V tomto dokumentu se konkrétně uvádí: „Je třeba poznamenat, že požadavky na integritu dat platí stejně pro manuální (papírová) i elektronická data. (překlad: „...požadavky na integritu dat platí stejně pro manuální (papírová) i elektronická data“). Tato formulace je zcela specificky spojena s pojmem „písemný důkaz“ v ustanovení § 71 občanského soudního řádu, čl. 70 CAS, čl. 75 APC, „písemně“ Čl. 84 Občanský soudní řád.
Obrázek 2 představuje schéma utváření přístupů k typům informací v judikatuře.
Rýže. 2. Zdroj .
Obrázek 3 ukazuje mechanismus z obrázku 1 pro úkoly výše uvedeného „Pokyny“. Srovnáním lze snadno zjistit, že přístupy používané při plnění požadavků na integritu informací v moderních standardech pro informační systémy jsou ve srovnání s právním pojetím informace výrazně omezené.
Obr
V uvedeném dokumentu (Guidance) je vazba na technickou část, možnosti zpracování a ukládání dat dobře potvrzena citací z kapitoly 18.2. Relační databáze: "Tato struktura souborů je ze své podstaty bezpečnější, protože data jsou uchovávána ve formátu velkého souboru, který zachovává vztah mezi daty a metadaty."
Ve skutečnosti v tomto přístupu - ze stávajících technických možností, není nic abnormálního a samo o sobě je to přirozený proces, protože expanze konceptů pochází z nejvíce studované činnosti - návrhu databáze. Ale na druhou stranu se objevují právní normy, které neposkytují slevy na technické možnosti stávajících systémů, např. .
Rýže. 4. Nálevka technických možností ().
V těchto aspektech je zřejmé, že původní datový soubor (obr. 1) bude muset být za prvé uložen a za druhé být základem pro extrakci dalších informací z něj. No, jako příklad: kamery zaznamenávající dopravní předpisy jsou všudypřítomné, systémy pro zpracování informací odstraňují porušovatele, ale další informace lze nabídnout i dalším spotřebitelům, například jako marketingový monitoring struktury toku zákazníků do nákupního centra. A to je zdrojem další přidané hodnoty při používání BigDat. Je docela možné, že soubory dat, které se shromažďují nyní, někde v budoucnu, budou mít hodnotu podle mechanismu podobnou hodnotě vzácných edic 1700 v současnosti. Ve skutečnosti jsou dočasné datové sady jedinečné a je nepravděpodobné, že by se v budoucnu opakovaly.
3. Úvodní část. Kritéria hodnocení
Během procesu zpracování byla vyvinuta následující klasifikace chyb.
1. Třída chyb (na základě GOST R 8.736-2011): a) systematické chyby; b) náhodné chyby; c) omyl.
2. Násobností: a) mono zkreslení; b) vícenásobné zkreslení.
3. Podle kritičnosti následků: a) kritické; b) není kritická.
4. Podle zdroje výskytu:
A) Technické – chyby, ke kterým dochází při provozu zařízení. Docela relevantní chyba pro systémy IoT, systémy s významnou mírou vlivu na kvalitu komunikace, vybavení (hardware).
B) Chyby operátora – chyby v širokém rozsahu od překlepů operátora při zadávání až po chyby v technických specifikacích pro návrh databáze.
C) Uživatelské chyby – zde jsou uživatelské chyby v celém rozsahu od „zapomněli přepnout rozložení“ až po záměnu metrů za stopy.
5. Odděleno do samostatné třídy:
a) „úloha oddělovače“, tedy mezera a „:“ (v našem případě), kdy byl duplikován;
b) slova psaná společně;
c) žádná mezera za servisními znaky
d) symetricky více symbolů: (), "", "...".
Společně se systematizací chyb databáze zobrazenou na obrázku 5 je vytvořen poměrně účinný souřadnicový systém pro vyhledávání chyb a vývoj algoritmu čištění dat pro tento příklad.
Rýže. 5. Typické chyby odpovídající strukturním jednotkám databáze (Zdroj: ).
Přesnost, integrita domény, typ dat, konzistence, redundance, úplnost, duplikace, soulad s obchodními pravidly, strukturální jednoznačnost, datová anomálie, srozumitelnost, včasnost, dodržování pravidel integrity dat. (Strana 334. Základy datového skladu pro IT profesionály / Paulraj Ponniah.—2nd ed.)
Prezentované anglické znění a ruský strojový překlad v závorkách.
Přesnost. Hodnota uložená v systému pro datový prvek je správná hodnota pro tento výskyt datového prvku. Pokud máte v záznamu uložené jméno zákazníka a adresu, pak je adresa správnou adresou zákazníka s tímto jménem. Pokud v záznamu pro číslo objednávky 1000 najdete objednané množství jako 12345678 jednotek, je toto množství přesným množstvím pro danou objednávku.
[Přesnost. Hodnota uložená v systému pro datový prvek je správná hodnota pro tento výskyt datového prvku. Pokud máte jméno a adresu zákazníka uložené v záznamu, pak je adresa správnou adresou zákazníka s tímto jménem. Pokud v záznamu pro číslo objednávky 1000 najdete objednané množství jako 12345678 jednotek, pak toto množství je přesné množství pro danou objednávku.]
Integrita domény. Datová hodnota atributu spadá do rozsahu povolených definovaných hodnot. Běžným příkladem jsou povolené hodnoty „muž“ a „žena“ pro datový prvek pohlaví.
[Integrita domény. Hodnota dat atributu spadá do rozsahu platných, definovaných hodnot. Obecným příkladem jsou platné hodnoty „male“ a „female“ pro datový prvek pohlaví.]
Datový typ. Hodnota pro datový atribut je ve skutečnosti uložena jako datový typ definovaný pro daný atribut. Když je datový typ pole názvu obchodu definován jako „text“, všechny výskyty tohoto pole obsahují název obchodu zobrazený v textovém formátu a nikoli číselné kódy.
[Datový typ. Hodnota datového atributu je ve skutečnosti uložena jako datový typ definovaný pro daný atribut. Pokud je datový typ pole názvu obchodu definován jako „text“, všechny výskyty tohoto pole obsahují název obchodu zobrazený v textovém formátu, nikoli v číselných kódech.]
Konzistence. Forma a obsah datového pole jsou ve více zdrojových systémech stejné. Pokud je kód produktu pro produkt ABC v jednom systému 1234, pak je kód pro tento produkt 1234 v každém zdrojovém systému.
[Konzistence. Forma a obsah datového pole jsou v různých zdrojových systémech stejné. Pokud je kód produktu pro produkt ABC na jednom systému 1234, pak je kód pro tento produkt 1234 na každém zdrojovém systému.]
Nadbytek. Stejná data nesmí být v systému uložena na více než jednom místě. Pokud je datový prvek z důvodu účinnosti záměrně uložen na více než jednom místě v systému, musí být redundance jasně identifikována a ověřena.
[Nadbytek. Stejná data by neměla být uložena na více než jednom místě v systému. Pokud je z důvodu efektivity datový prvek záměrně uložen na více místech v systému, musí být redundance jasně definována a ověřena.]
Úplnost. V systému nechybí žádné hodnoty pro daný atribut. Například v souboru zákazníka musí být pro každého zákazníka platná hodnota pole „stav“. V souboru pro detaily objednávky musí být každý záznam detailu objednávky kompletně vyplněn.
[Úplnost. V systému pro tento atribut nechybí žádné hodnoty. Například soubor klienta musí mít platnou hodnotu pro pole "stav" pro každého klienta. V souboru podrobností objednávky musí být každý záznam podrobností objednávky kompletně vyplněn.]
Zdvojení. Duplikace záznamů v systému je zcela vyřešena. Pokud je známo, že soubor produktu obsahuje duplicitní záznamy, jsou identifikovány všechny duplicitní záznamy pro každý produkt a je vytvořen křížový odkaz.
[Duplikát. Duplikace záznamů v systému byla zcela odstraněna. Pokud je známo, že soubor produktu obsahuje duplicitní položky, jsou identifikovány všechny duplicitní položky pro každý produkt a je vytvořen křížový odkaz.]
Soulad s obchodními pravidly. Hodnoty každé datové položky se řídí předepsanými obchodními pravidly. V aukčním systému nesmí být příklepová nebo prodejní cena nižší než vyvolávací cena. V systému bankovních úvěrů musí být zůstatek úvěru vždy kladný nebo nulový.
[Dodržování obchodních pravidel. Hodnoty každého datového prvku jsou v souladu se zavedenými obchodními pravidly. V aukčním systému nesmí být příklepová nebo prodejní cena nižší než vyvolávací cena. V bankovním úvěrovém systému musí být zůstatek úvěru vždy kladný nebo nulový.]
Strukturální jednoznačnost. Všude tam, kde lze datovou položku přirozeně strukturovat do jednotlivých složek, musí položka tuto dobře definovanou strukturu obsahovat. Například jméno jednotlivce se přirozeně dělí na křestní jméno, prostřední iniciála a příjmení. Hodnoty jmen jednotlivců musí být uloženy jako křestní jméno, prostřední iniciála a příjmení. Tato vlastnost kvality dat zjednodušuje prosazování standardů a snižuje chybějící hodnoty.
[Strukturální jistota. Tam, kde lze datový prvek přirozeně strukturovat do jednotlivých komponent, musí prvek obsahovat tuto dobře definovanou strukturu. Například jméno osoby se přirozeně dělí na křestní jméno, střední iniciály a příjmení. Hodnoty pro jednotlivá jména by měly být uloženy jako křestní jméno, prostřední iniciála a příjmení. Tato charakteristika kvality dat zjednodušuje aplikaci norem a snižuje chybějící hodnoty.]
Datová anomálie. Pole musí být použito pouze k účelu, pro který je definováno. Pokud je pole Adresa-3 definováno pro libovolný třetí řádek adresy pro dlouhé adresy, pak toto pole musí být použito pouze pro záznam třetího řádku adresy. Nesmí se používat pro zadání telefonního nebo faxového čísla zákazníka.
[Datová anomálie. Pole musí být použito pouze k účelu, pro který je definováno. Pokud je pole Adresa-3 definováno pro jakýkoli možný třetí řádek adresy pro dlouhé adresy, pak se toto pole použije pouze pro záznam třetího řádku adresy. Nemělo by se používat k zadání telefonního nebo faxového čísla zákazníka.]
Jasnost. Datový prvek může mít všechny ostatní charakteristiky kvalitních dat, ale pokud uživatelé jeho významu jasně nerozumí, pak nemá datový prvek pro uživatele žádnou hodnotu. Správné konvence pojmenování pomáhají uživatelům dobře rozumět datovým prvkům.
[Jasnost. Datový prvek může mít všechny ostatní vlastnosti dobrých dat, ale pokud uživatelé jasně nerozumí jeho významu, pak datový prvek nemá pro uživatele žádnou hodnotu. Správné konvence pojmenování pomáhají uživatelům dobře rozumět datovým prvkům.]
Včasné. Uživatelé určují aktuálnost dat. Pokud uživatelé očekávají, že data zákaznické dimenze nebudou starší než jeden den, musí být změny zákaznických dat ve zdrojových systémech aplikovány na datový sklad denně.
[Včas. Uživatelé určují aktuálnost dat. Pokud uživatelé očekávají, že data zákaznické dimenze nebudou starší než jeden den, měly by být změny zákaznických dat ve zdrojových systémech aplikovány na datový sklad na denní bázi.]
Účelnost. Každý datový prvek v datovém skladu musí splňovat určité požadavky sběru uživatelů. Datový prvek může být přesný a vysoce kvalitní, ale pokud nemá pro uživatele žádnou hodnotu, pak je zcela zbytečné, aby byl tento datový prvek v datovém skladu.
[Utility. Každá datová položka v datovém úložišti musí splňovat určité požadavky uživatelské kolekce. Datový prvek může být přesný a vysoce kvalitní, ale pokud nepřináší uživatelům hodnotu, pak není nutné, aby byl tento datový prvek v datovém skladu.]
Dodržování pravidel integrity dat. Data uložená v relačních databázích zdrojových systémů musí dodržovat pravidla integrity entity a referenční integrity. Jakákoli tabulka, která povoluje null jako primární klíč, nemá integritu entity. Referenční integrita vynucuje správné vytvoření vztahů rodič–dítě. Ve vztahu zákazník-objednávka zajišťuje referenční integrita existenci zákazníka pro každou objednávku v databázi.
[Dodržování pravidel integrity dat. Data uložená v relačních databázích zdrojových systémů musí splňovat pravidla integrity entity a referenční integrity. Jakákoli tabulka, která umožňuje null jako primární klíč, nemá integritu entity. Referenční integrita nutí ke správnému navázání vztahu mezi rodiči a dětmi. Ve vztahu zákazník-objednávka zajišťuje referenční integrita, že zákazník existuje pro každou objednávku v databázi.]
4. Kvalita čištění dat
Kvalita čištění dat je v bigdatech poměrně problematická záležitost. Pro každého datového analytika je zásadní zodpovědět otázku, jaký stupeň čištění dat je nutný k dokončení úkolu. U většiny současných problémů si to každý analytik určuje sám a je nepravděpodobné, že by někdo zvenčí byl schopen tento aspekt ve svém řešení vyhodnotit. Ale pro daný úkol v tomto případě byla tato otázka mimořádně důležitá, protože spolehlivost právních údajů by měla mít tendenci k jedné.
Zvažování technologií testování softwaru pro stanovení provozní spolehlivosti. Dnes existuje více než tyto modely . Mnoho modelů používá model servisu reklamací:
Obr. 6
Uvažujte následovně: "Pokud je nalezená chyba událost podobná události selhání v tomto modelu, jak pak najít analog parametru t?" A sestavil jsem následující model: Představme si, že čas, který testerovi zabere kontrola jednoho záznamu, je 1 minuta (pro danou databázi), pak k nalezení všech chyb bude potřebovat 365 494 minut, což jsou přibližně 3 roky a 3 měsíce pracovní doby. Jak víme, je to velmi velké množství práce a náklady na kontrolu databáze budou pro kompilátora této databáze neúnosné. V této úvaze se objevuje ekonomický koncept nákladů a po analýze jsem došel k závěru, že se jedná o poměrně účinný nástroj. Na základě ekonomického zákona: „Objem výroby (v jednotkách), při kterém je dosaženo maximálního zisku firmy, se nachází v bodě, kde jsou mezní náklady na výrobu nové jednotky výstupu porovnány s cenou, kterou může tato firma obdržet. pro novou jednotku." Na základě postulátu, že nalezení každé následující chyby vyžaduje stále větší kontrolu záznamů, jde o nákladový faktor. To znamená, že postulát přijatý v testovacích modelech nabývá fyzického významu v následujícím vzoru: pokud k nalezení i-té chyby bylo nutné zkontrolovat n záznamů, pak k nalezení další (i+1) chyby bude nutné kontrolovat m záznamů a zároveň n
- Když se počet záznamů kontrolovaných před nalezením nové chyby ustálí;
- Když se počet záznamů zkontrolovaných před nalezením další chyby zvýší.
Pro stanovení kritické hodnoty jsem se obrátil na koncept ekonomické proveditelnosti, který lze v tomto případě s využitím konceptu sociálních nákladů formulovat následovně: „Náklady na opravu chyby by měl nést ekonomický subjekt, který může za nejnižší cenu." Máme jednoho agenta – testera, který stráví 1 minutu kontrolou jednoho záznamu. V peněžním vyjádření, pokud vyděláte 6000 12,2 rublů/den, bude to 1 rublů. (přibližně dnes). Zbývá určit druhou stranu rovnováhy v hospodářském právu. Uvažoval jsem takto. Existující chyba bude vyžadovat, aby dotyčná osoba vynaložila úsilí na její nápravu, tedy vlastník nemovitosti. Řekněme, že to vyžaduje XNUMX den akce (odešlete žádost, obdržíte opravený dokument). Pak se ze sociálního hlediska jeho náklady budou rovnat průměrnému platu za den. Průměrná naběhlá mzda v Khanty-Mansi Autonomous Okrug 73285 rublů. nebo 3053,542 XNUMX rublů/den. Podle toho získáme kritickou hodnotu rovnou:
3053,542: 12,2 = 250,4 jednotek záznamů.
To znamená, že ze sociálního hlediska, pokud tester zkontroloval 251 záznamů a našel jednu chybu, je to ekvivalentní tomu, že uživatel tuto chybu sám opraví. Pokud tedy tester strávil čas rovnající se kontrole 252 záznamů, aby našel další chybu, pak je v tomto případě lepší přesunout náklady na opravu na uživatele.
Je zde uveden zjednodušený přístup, protože ze sociálního hlediska je nutné vzít v úvahu veškerou přidanou hodnotu generovanou každým specialistou, tedy náklady včetně daní a sociálních plateb, ale model je jasný. Důsledkem tohoto vztahu je následující požadavek na specialisty: specialista z IT branže musí mít plat vyšší, než je celostátní průměr. Pokud je jeho mzda nižší než průměrná mzda potenciálních uživatelů databáze, musí si sám zkontrolovat celou databázi z ruky do ruky.
Při použití popsaného kritéria vzniká první požadavek na kvalitu databáze:
Já(tr). Podíl kritických chyb by neměl překročit 1/250,4 = 0,39938 %. O něco méně než zlato v průmyslu. A ve fyzickém vyjádření neexistuje více než 1459 záznamů s chybami.
Ekonomický ústup.
Ve skutečnosti tím, že společnost udělá takový počet chyb v záznamech, souhlasí s ekonomickými ztrátami ve výši:
1459*3053,542 = 4 455 118 rublů.
Tato částka je dána tím, že společnost nemá nástroje, jak tyto náklady snížit. Z toho vyplývá, že pokud má někdo technologii, která mu umožňuje snížit počet záznamů s chybami například na 259, pak to společnosti umožní ušetřit:
1200*3053,542 = 3 664 250 rublů.
Ale zároveň může požádat o svůj talent a práci, řekněme - 1 milion rublů.
To znamená, že sociální náklady se snižují o:
3 664 250 – 1 000 000 = 2 664 250 rublů.
Tento efekt je v podstatě přidanou hodnotou z používání technologií BigDat.
Zde je ale třeba vzít v úvahu, že se jedná o sociální efekt a vlastníkem databáze jsou obecní úřady, jejich příjem z užívání majetku evidovaného v této databázi, ve výši 0,3 %, je: 2,778 miliardy rublů/ rok. A tyto náklady (4 455 118 rublů) ho příliš neobtěžují, protože jsou převedeny na vlastníky nemovitostí. A v tomto ohledu bude muset vývojář vylepšujících technologií v Bigdata prokázat schopnost přesvědčit vlastníka této databáze, a takové věci vyžadují značný talent.
V tomto příkladu byl algoritmus hodnocení chyb zvolen na základě Schumannova modelu [2] ověřování softwaru během testování spolehlivosti. Vzhledem k jeho rozšířenosti na internetu a možnosti získat potřebné statistické ukazatele. Metodika je převzata z Monakhova Yu.M. „Funkční stabilita informačních systémů“, viz pod spoilerem na obr. 7-9.
Rýže. 7 – 9 Metodologie Schumannova modelu
Druhá část tohoto materiálu představuje příklad čištění dat, při kterém jsou získány výsledky použití Schumannova modelu.
Dovolte mi představit získané výsledky:
Odhadovaný počet chyb N = 3167 n.
Parametr C, lambda a funkce spolehlivosti:
Obr
V podstatě je lambda skutečným indikátorem intenzity, s jakou jsou chyby detekovány v každé fázi. Pokud se podíváte na druhou část, odhad pro tento ukazatel byl 42,4 chyb za hodinu, což je docela srovnatelné se Schumannovým ukazatelem. Výše bylo stanoveno, že rychlost, s jakou vývojář nachází chyby, by při kontrole 1 záznamu za minutu neměla být nižší než 250,4 chyba na 1 záznamů. Z toho vyplývá kritická hodnota lambda pro Schumannův model:
60 / 250,4 = 0,239617.
To znamená, že potřeba provádět procedury detekce chyb musí být prováděna, dokud lambda ze stávajících 38,964 neklesne na 0,239617.
Nebo dokud indikátor N (potenciální počet chyb) mínus n (opravený počet chyb) neklesne pod námi přijatou hranici - 1459 ks.
Literatura
- Monakhov, Yu.M. Funkční stabilita informačních systémů. Za 3 hodiny Část 1. Spolehlivost softwaru: učebnice. příspěvek / Yu. M. Monakhov; Vladim. Stát univ. – Vladimír: Izvo Vladim. Stát Univerzita, 2011. – 60 s. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman, "Pravděpodobnostní modely pro predikci spolehlivosti softwaru."
- Základy datového skladu pro IT profesionály / Paulraj Ponniah.—2nd ed.
Zdroj: www.habr.com