1. Počáteční údaje
Čištění dat je jednou z výzev, kterým čelí úkoly analýzy dat. Tento článek představuje zjištění a řešení, která vyplynula z řešení praktického problému analýzy databáze pro výpočet katastrální hodnoty. Zdrojové soubory jsou k dispozici zde. .
Soubor „Výsledek srovnávacího modelu.ods“ byl recenzován v „Dodatku B. Výsledky stanovení KS 5. Informace o metodě stanovení katastrální hodnoty 5.1 Srovnávací přístup“.
Tabulka 1. Statistické ukazatele datové sady v souboru „Comparative model result.ods“
Celkový počet polí, ks — 44
Celkový počet záznamů, ks — 365 490
Celkový počet znaků: 101 714 693
Průměrný počet znaků na příspěvek: 278 297
Směrodatná odchylka znaků v záznamu, ks — 15 510
Minimální počet znaků na položku: 198
Maximální počet znaků na položku: 363
2. Úvodní část. Základní standardy
Při analýze této databáze vyvstal úkol specifikovat požadavky na úroveň čištění, jelikož, jak je všem jasné, tato databáze vytváří právní a ekonomické důsledky pro uživatele. V průběhu procesu se ukázalo, že nebyly stanoveny žádné specifické požadavky na úroveň čištění velkých dat. Analýzou právních předpisů k této problematice jsem dospěl k závěru, že všechny jsou založeny na možnostech. To znamená, že se objevil konkrétní úkol, pro tento úkol byly sestaveny informační zdroje, následně byl vytvořen datový soubor a na základě vytvořeného datového souboru byly vyvinuty nástroje pro řešení úkolu. Výsledná řešení slouží jako referenční body pro výběr mezi alternativami. To je znázorněno na obrázku 1.
Protože je při definování jakýchkoli standardů vhodnější spoléhat se na osvědčené technologie, zvolil jsem jako základ pro analytická kritéria požadavky stanovené v , protože jsem tento dokument považoval za nejkomplexnější v této otázce. Konkrétně se v části tohoto dokumentu uvádí: „Je třeba poznamenat, že požadavky na integritu dat se vztahují stejnou měrou na manuální (papírová) i elektronická data.“ Toto znění je poměrně konkrétně spojeno s pojmem „písemný důkaz“ v článku 71 občanského soudního řádu, článku 70 správního řádu, článku 75 rozhodčího řádu a „písemná forma“ v článku 84 občanského soudního řádu.
Obrázek 2 představuje diagram formování přístupů k typům informací v judikatuře.
Obr. 2. Zdroj .
Obrázek 3 znázorňuje mechanismus z obrázku 1 pro výše uvedené úkoly „Pokynů“. Porovnáním těchto mechanismů je snadné vidět, že přístupy používané ke splnění požadavků na integritu informací v moderních předpisech pro informační systémy jsou ve srovnání s právním pojetím informace výrazně omezené.
Obr
V dokumentu (Pokyny) je vazba na technickou část, tedy možnosti zpracování a ukládání dat, dobře potvrzena citací z kapitoly 18.2. Relační databáze: „Tato souborová struktura je ze své podstaty bezpečnější, protože data jsou uložena ve velkém formátu souboru, který zachovává vztah mezi daty a metadaty.“
V podstatě na tomto přístupu – v závislosti na stávajících technických možnostech – není nic neobvyklého a je to přirozený proces, jelikož rozšiřování konceptů pramení z nejvíce studované činnosti: návrhu databází. Na druhou stranu se však objevují právní normy, které neumožňují žádný příspěvek k technickým možnostem stávajících systémů, například: .
Obr. 4. Trychtýř technických schopností ().
V těchto ohledech je zřejmé, že počáteční datový soubor (obr. 1) bude nutné v první řadě zachovat a za druhé, aby sloužil jako základ pro extrakci dalších informací z něj. Například dopravní kamery jsou všudypřítomné a systémy pro zpracování informací filtrují narušitele. Zbývající informace však lze nabídnout i jiným spotřebitelům, například pro marketingové sledování toku zákazníků v nákupním centru. To je zdroj dodatečné přidané hodnoty při používání velkých dat. Je zcela možné, že datové soubory shromažďované nyní budou v budoucnu mít podobnou hodnotu, jakou mají dnes vzácná vydání ze 1700. století. Koneckonců, dočasné datové soubory jsou v podstatě jedinečné a je nepravděpodobné, že by se v budoucnu opakovaly.
3. Úvodní část. Hodnotící kritéria
Během zpracování byla vyvinuta následující klasifikace chyb.
1. Třída chyby (podle GOST R 8.736-2011): a) systematické chyby; b) náhodné chyby; c) hrubá chyba.
2. Podle multiplicity: a) monodistorze; b) multidistorze.
3. Podle kritičnosti důsledků: a) kritické; b) nekritické.
4. Podle zdroje původu:
A) Technické – chyby, ke kterým dochází během provozu zařízení. Jedná se o poměrně běžnou chybu u systémů IoT, systémů výrazně ovlivněných kvalitou připojení a hardwarem.
B) Chyby operátora – chyby, které sahají od překlepů operátora během zadávání až po chyby v technických specifikacích pro návrh databáze.
B) Chyby uživatelů – zde se chyby uživatelů pohybují od „zapomenutí přepnout rozvržení“ až po záměnu metrů za stopy.
5. Odděleno do samostatné třídy:
a) „úloha oddělovače“, tj. mezera a „:“ (v našem případě) při duplikaci;
b) slova psaná dohromady;
c) absence mezery za servisními znaky
d) symetrické vícenásobné symboly: (), "", "...".
Souhrnně řečeno, se systematizací chyb databáze prezentovanou na obrázku 5 je vytvořen poměrně efektivní souřadnicový systém pro vyhledávání chyb a vývoj algoritmu pro čištění dat pro tento příklad.
Obr. 5. Typické chyby odpovídající strukturálním jednotkám databáze (Zdroj: ).
Přesnost, integrita domény, datový typ, konzistence, redundance, úplnost, duplikace, shoda s obchodními pravidly, strukturální definičnost, datová anomálie, srozumitelnost, včasnost, dodržování pravidel integrity dat. (Strana 334. Základy datových skladů pro IT profesionály / Paulraj Ponniah. – 2. vydání)
V závorkách je uvedeno anglické znění a ruský strojový překlad.
Přesnost. Hodnota uložená v systému pro datový prvek je správná hodnota pro daný 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 pro zákazníka s tímto jménem. Pokud v záznamu pro číslo objednávky 12345678 najdete objednané množství 1000 kusů, pak je toto množství pro danou objednávku přesné množství.
[Přesnost. Hodnota uložená v systému pro datovou položku je správná hodnota pro daný výskyt datové položky. Pokud máte v záznamu uloženo jméno a adresu zákazníka, pak je adresa správnou adresou pro zákazníka s tímto jménem. Pokud v záznamu pro číslo objednávky 12345678 najdete objednané množství 1 000 kusů, pak je toto množství přesným množstvím 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 přijatelných, definovaných hodnot. Běžným příkladem jsou přijatelné hodnoty „muž“ a „žena“ pro datový prvek pohlaví.]
Datový typ. Hodnota datového atributu je ve skutečnosti uložena jako datový typ definovaný pro daný atribut. Pokud je datový typ pole s názvem obchodu definován jako „text“, všechny instance daného pole obsahují název obchodu zobrazený v textovém formátu a nikoli v číselných kódech.
[Datový typ. Hodnota datového atributu je ve skutečnosti uložena jako datový typ definovaný pro daný atribut. Pokud je datový typ pole s názvem obchodu definován jako „text“, všechny instance daného pole obsahují název obchodu zobrazený jako text, nikoli jako číselné kódy.]
Konzistence. Forma a obsah datového pole je stejný ve více zdrojových systémech. Pokud je kód produktu ABC v jednom systému 1234, pak je kód tohoto produktu 1234 i v každém zdrojovém systému.
[Konzistence. Forma a obsah datového pole jsou ve všech zdrojových systémech stejné. Pokud je kód produktu ABC v jednom systému 1234, pak je kód pro tento produkt 1234 i v každém zdrojovém systému.]
Redundance. Stejná data nesmí být v systému uložena na více než jednom místě. Pokud je z důvodu efektivity datový prvek 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.
[Redundance. Stejná data by neměla být v systému uložena na více než jednom místě. Pokud je z důvodů efektivity datová položka záměrně uložena 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 v poli „stav“. V souboru s podrobnostmi o objednávce musí být každý záznam s podrobnostmi o objednávce kompletně vyplněn.
[Úplnost. Systém pro tento atribut nemá žádné chybějící hodnoty. Například v souboru zákazníka musí být pro každého zákazníka platná hodnota pole „stav“. V souboru s podrobnostmi objednávky musí být každý záznam s podrobnostmi objednávky kompletně vyplněn.]
Duplikace. Duplikace záznamů v systému je kompletně 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 vytvořen křížový odkaz.
[Duplikáty. Duplicitní záznamy v systému jsou zcela eliminovány. Pokud je známo, že soubor produktu obsahuje duplicitní záznamy, jsou všechny duplicitní záznamy pro každý produkt identifikovány a porovnány.]
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 nemůže být sázková 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ý.
[Soulad s obchodními pravidly. Hodnoty každého datového prvku splňují zavedená obchodní pravidla. V aukčním systému nemůže být sázková nebo prodejní cena nižší než vyvolávací cena. V bankovním úvěrovém systému musí být zůstatek na účtu vždy kladný nebo nulový.]
Strukturální konkrétnost. Všude, kde lze datovou položku přirozeně strukturovat do jednotlivých komponent, musí tato položka obsahovat tuto dobře definovanou strukturu. Například jméno osoby se přirozeně dělí na křestní jméno, prostřední iniciálu a příjmení. Hodnoty pro jména osob musí být uloženy jako křestní jméno, prostřední iniciála a příjmení. Tato charakteristika kvality dat zjednodušuje vymáhání standardů a snižuje počet chybějících hodnot.
[Strukturální definice. Pokud lze datový prvek přirozeně strukturovat do samostatných komponent, měl by prvek tuto jasně definovanou strukturu obsahovat. Například jméno osoby se přirozeně dělí na křestní jméno, prostřední iniciálu a příjmení. Hodnoty jmen jednotlivců by měly být uloženy jako křestní jména, prostřední iniciály a příjmení. Tato charakteristika kvality dat zjednodušuje aplikaci standardů a snižuje počet chybějících hodnot.]
Anomálie dat. 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 toto pole musí být použito pouze pro zaznamenání třetího řádku adresy. Nesmí být použito pro zadání telefonního nebo faxového čísla zákazníka.
[Anomálie v datech: Toto pole musí být použito pouze pro účel, 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 toto pole musí být použito pouze k zaznamenání třetího řádku adresy. Nesmí být použito k zadání telefonního nebo faxového čísla zákazníka.]
Srozumitelnost. Datový prvek může mít všechny ostatní vlastnosti kvalitních dat, ale pokud uživatelé jasně nerozumí jeho významu, pak pro ně nemá žádnou hodnotu. Správné konvence pojmenování pomáhají uživatelům datovým prvkům dobře porozumět.
[Srozumitelnost. Datový prvek může mít všechny ostatní vlastnosti dobrých dat, ale pokud uživatelé jasně nechápou jeho význam, nemá pro ně žádnou hodnotu. Správné konvence pojmenování pomáhají uživatelům datovým prvkům snadno porozumět.]
Včasné. Uživatelé určují aktuálnost dat. Pokud uživatelé očekávají, že data o zákaznických dimenzích nebudou starší než jeden den, musí se změny zákaznických dat ve zdrojových systémech do datového skladu denně aplikovat.
[Včasné. Aktuálnost dat určují uživatelé. Pokud uživatelé očekávají, že data měření zákazníků nebudou starší než jeden den, měly by se změny zákaznických dat ve zdrojových systémech do datového skladu aplikovat denně.]
Užitečnost. Každý datový prvek v datovém skladu musí splňovat určité požadavky na kolekci uživatelů. Datový prvek může být přesný a vysoce kvalitní, ale pokud pro uživatele nemá žádnou hodnotu, pak je zcela zbytečné, aby byl v datovém skladu.
[Užitečnost. Každá datová položka v datovém skladu musí splňovat určité požadavky uživatelů na sběr dat. Datová položka může být přesná a vysoce kvalitní, ale pokud uživatelům neposkytuje žádnou hodnotu, pak není důvod, aby byla 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í splňovat pravidla integrity entit a referenční integrity. Jakákoli tabulka, která povoluje primární klíč null, nemá integritu entit. Referenční integrita vynucuje správné navázání vztahů rodič-potomek. Ve vztahu zákazník-objednávka referenční integrita zajišťuje existenci zákazníka pro každou objednávku v databázi.
Zachování integrity dat. Data uložená v relačních databázích zdrojových systémů musí dodržovat pravidla entitní a referenční integrity. Jakákoli tabulka, která umožňuje nulový primární klíč, postrádá entitní integritu. Referenční integrita zajišťuje, že vztahy rodič-potomek jsou správně navázány. Ve vztazích zákazník-objednávka referenční integrita zajišťuje existenci zákazníka pro každou objednávku v databázi.
4. Kvalita čištění dat
Kvalita čištění dat je v oblasti velkých dat poměrně náročná. Určení stupně čištění dat potřebného pro daný úkol je klíčovou otázkou pro každého datového analytika. Ve většině současných úkolů si to každý analytik určuje sám a je nepravděpodobné, že by externí analytik mohl tento aspekt jeho řešení posoudit. Pro daný úkol však byla tato otázka klíčová, protože spolehlivost právních dat se musí blížit jedné úrovni.
Zvažování technologií testování softwaru pro určení provozní spolehlivosti. V současné době existuje více než 100 těchto modelů. Mnoho modelů používá model založený na požadavcích:
Obr. 6
Uvažoval jsem takto: „Pokud je zjištěná chyba událostí analogickou selhání v tomto modelu, jak pak mohu najít analogii parametru t?“ Vyvinul jsem následující model: Představme si, že doba, kterou tester potřebuje ke kontrole 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 práce. Jak chápeme, jedná se o velmi značné množství práce a náklady na kontrolu databáze budou pro tvůrce této databáze neúnosné. V této úvaze se objevuje ekonomický koncept nákladů a po analýze jsem dospěl k závěru, že se jedná o poměrně účinný nástroj. Na základě ekonomického zákona: „Objem produkce (v jednotkách), při kterém společnost dosahuje maximálního zisku, se nachází v bodě, kde se mezní náklady na výrobu nové jednotky výstupu rovnají ceně, kterou může společnost za každou novou jednotku získat.“ Na základě postulátu, že nalezení každé další chyby vyžaduje kontrolu stále více záznamů, se jedná o faktor nákladů. To znamená, že postulát přijatý při testování modelů nabývá fyzikálního významu v následujícím vzorci: pokud k nalezení i-té chyby bylo nutné zkontrolovat n záznamů, pak k nalezení další (i+1) chyby bude již nutné zkontrolovat m záznamů a zároveň n
- Když se počet záznamů zkontrolovaných před nalezením nové chyby stabilizuje;
- Jakmile se zvýší počet záznamů zkontrolovaných před nalezením další chyby.
Pro určení kritické hodnoty jsem se obrátil na koncept ekonomické proveditelnosti, který lze v tomto případě s využitím konceptu společenských nákladů formulovat takto: „Náklady na opravu chyby by měl nést ekonomický agent, který tak může učinit s nejnižšími náklady.“ Máme jednoho agenta – testera, který stráví 1 minutu kontrolou jednoho záznamu. V peněžním vyjádření to s příjmem 6 000 rublů denně bude činit 12,2 rublů (přibližně dnes). Zbývá určit druhou stranu rovnováhy v ekonomickém zákoně. Uvažoval jsem následovně. Existující chyba bude vyžadovat, aby ten, koho se dotýká, tedy vlastník nemovitosti, vynaložil úsilí na její opravu. Předpokládejme, že to vyžaduje 1 den akce (podání žádosti, obdržení opraveného dokumentu). Pak se ze společenského hlediska jeho náklady budou rovnat průměrné denní mzdě. Průměrná nashromážděná mzda v Chanty-Mansijském autonomním okruhu k... 73 285 rublů neboli 3 053 542 rublů za den. Z toho vyplývá kritická hodnota rovnající se:
3053,542: 12,2 = 250,4 jednotek záznamů.
Z pohledu společnosti to znamená, že pokud tester zkontroluje 251 záznamů a najde jednu chybu, je to ekvivalentní tomu, jako by si uživatel chybu opravil sám. Pokud tedy tester strávil stejné množství času kontrolou 252 záznamů, aby našel další chybu, pak by náklady na její opravu měly být přeneseny na uživatele.
Tento přístup je zjednodušený, protože z pohledu společnosti je nutné zohlednit všechny dodatečné náklady generované každým specialistou, tj. výdaje včetně daní a odvodů na sociální zabezpečení. Model je však jasný. Z tohoto vztahu vyplývá následující požadavek na specialisty: IT specialista by měl mít plat vyšší než celostátní průměr. Pokud je jeho plat nižší než průměrný plat potenciálních uživatelů databáze, musí osobně auditovat celou databázi.
Při použití popsaného kritéria se vytvoří první požadavek na kvalitu databáze:
I(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í existuje maximálně 1 459 chybných záznamů.
Ekonomický ústup.
V podstatě tím, že společnost povolí 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 skutečností, že společnost postrádá nástroje, jak tyto náklady snížit. Pokud tedy někdo vyvine technologii, která sníží počet záznamů s chybami například na 259, umožní to společnosti ušetřit:
1200*3053,542 = 3 664 250 rublů.
Ale zároveň si může za svůj talent a práci požádat řekněme milion rublů.
To znamená, že sociální náklady se snižují o:
3 664 250 – 1 000 000 = 2 664 250 rublů.
V podstatě je tento efekt přidanou hodnotou plynoucí z využití technologií BigData.
Je však důležité vzít v úvahu, že se jedná o sociální efekt a vlastníkem databáze je obec. Jejich příjem z užívání nemovitostí evidovaných v této databázi s úrokovou sazbou 0,3 % činí 2,778 miliardy rublů ročně. Tyto náklady (4 455 118 rublů) se jich nijak zvlášť netýkají, protože se přenášejí na vlastníky nemovitostí. Vývojář sofistikovanějších technologií v oblasti BigData proto bude muset prokázat svou schopnost přesvědčit vlastníka databáze, a takové věci vyžadují značný talent.
V tomto příkladu byl pro testování spolehlivosti softwaru zvolen algoritmus pro hodnocení chyb na základě Schumannova modelu [2]. To bylo provedeno z důvodu jeho širokého použití v síti a schopnosti získat potřebné statistické ukazatele. Metodika byla převzata z knihy Ju. M. Monachova „Funkční stabilita informačních systémů“ (viz spoiler na obr. 7–9).
Obr. 7–9 Metodologie Schumannova modelu
Druhá část tohoto materiálu představuje příklad čištění dat, ve kterém byly získány výsledky s využitím Schumannova modelu.
Dovolte mi, abych představil dosažené výsledky:
Odhadovaný počet chyb N = 3167 shN.
Parametr C, lambda a funkce spolehlivosti:
Obr
V podstatě je lambda skutečným ukazatelem rychlosti, s jakou jsou chyby detekovány v každé fázi. Ve druhé části byla odhadovaná lambda 42,4 chyb za hodinu, což je docela srovnatelné se Schumannovým ukazatelem. Výše bylo stanoveno, že míra detekce chyb vývojáře by neměla být nižší než 1 chyba na 250,4 záznamů, přičemž by se měl kontrolovat jeden záznam za minutu. Kritická hodnota lambda pro Schumannův model je tedy:
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 ukazatel N (potenciální počet chyb) mínus n (opravený počet chyb) neklesne pod prahovou hodnotu, kterou jsme přijali – 1459 ks.
Literatura
- Monachov, Yu. M. Funkční stabilita informačních systémů. Ve 3 dílech. Část 1. Spolehlivost softwaru: učebnice / Yu. M. Monachov; Vladimir státní univerzita. – Vladimír: Státní univerzita Izdvo Vladimir, 2011. – 60 s. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman, „Pravděpodobnostní modely pro predikci spolehlivosti softwaru.“
- Základy datových skladů pro IT profesionály / Paulraj Ponniah. – 2. vydání.
Zdroj: www.habr.com
