1. Изходни данни
Почистването на данни е едно от предизвикателствата пред задачите за анализ на данни. Този материал отразява разработките и решенията, възникнали в резултат на решаването на практически проблем за анализ на базата данни при формирането на кадастралната стойност. Източници тук .
Разгледан е файлът „Сравнителен модел total.ods” в „Приложение Б. Резултати от определяне на KS 5. Информация за метода за определяне на кадастралната стойност 5.1 Сравнителен подход”.
Таблица 1. Статистически показатели на набора от данни във файла „Сравнителен модел total.ods“
Общ брой полета, бр. — 44
Общ брой записи, бр. — 365 490
Общ брой знаци, бр. — 101 714 693
Среден брой знаци в запис, бр. — 278,297 XNUMX
Стандартно отклонение на знаците в запис, бр. — 15,510 XNUMX
Минимален брой символи в запис, бр. — 198
Максимален брой знаци в един запис, бр. — 363
2. Уводна част. Основни стандарти
При анализа на посочената база данни е поставена задача за уточняване на изискванията за степен на пречистване, тъй като, както е ясно на всички, посочената база данни създава правни и икономически последици за потребителите. По време на работата се оказа, че няма специфични изисквания за степента на почистване на големи данни. Анализирайки правните норми по този въпрос, стигнах до извода, че всички те са формирани от възможности. Тоест, появи се определена задача, източниците на информация се компилират за задачата, след това се формира набор от данни и въз основа на създадения набор от данни, инструменти за решаване на проблема. Получените решения са отправна точка при избора от алтернативи. Представих това на фигура 1.
Тъй като по отношение на определянето на каквито и да било стандарти е за предпочитане да се разчита на доказани технологии, избрах изискванията, посочени в , защото смятах, че този документ е най-изчерпателният за този брой. По-конкретно, в този документ разделът казва „Трябва да се отбележи, че изискванията за цялост на данните се прилагат еднакво за ръчни (хартиени) и електронни данни.“ (превод: „...изискванията за цялост на данните се прилагат еднакво за ръчни (хартиени) и електронни данни“). Тази постановка съвсем конкретно се свързва с понятието „писмено доказателство”, в разпоредбите на чл.71 от Гражданския процесуален кодекс, чл. 70 КАС, чл.75 АПК, „писмено” чл. 84 Граждански процесуален кодекс.
Фигура 2 представя диаграма на формирането на подходи към видовете информация в юриспруденцията.
Ориз. 2. Източник .
Фигура 3 показва механизма от Фигура 1 за задачите от горното „Ръководство“. Лесно е, като се направи сравнение, да се види, че използваните подходи при изпълнение на изискванията за цялост на информацията в съвременните стандарти за информационни системи са значително ограничени в сравнение с правното понятие за информация.
Фиг. 3
В посочения документ (Ръководство), връзката с техническата част, възможностите за обработка и съхранение на данни, е добре потвърдена с цитат от глава 18.2. Релационна база данни: „Тази файлова структура по своята същност е по-сигурна, тъй като данните се съхраняват в голям файлов формат, който запазва връзката между данни и метаданни.“
Всъщност в този подход - от съществуващите технически възможности, няма нищо необичайно и само по себе си това е естествен процес, тъй като разширяването на понятията идва от най-изучаваната дейност - проектирането на бази данни. Но, от друга страна, се появяват правни норми, които не предвиждат отстъпки от техническите възможности на съществуващите системи, например: .
Ориз. 4. Фуния на техническите възможности ().
В тези аспекти става ясно, че оригиналният набор от данни (фиг. 1) ще трябва, на първо място, да бъде запазен и второ, да бъде основа за извличане на допълнителна информация от него. Е, като пример: камерите, записващи правилата за движение, са повсеместни, системите за обработка на информация отсяват нарушителите, но друга информация може да бъде предложена и на други потребители, например като маркетингов мониторинг на структурата на потока от клиенти към търговски център. И това е източник на допълнителна добавена стойност при използване на BigDat. Напълно възможно е наборите от данни, които се събират сега, някъде в бъдещето, да имат стойност според механизъм, подобен на стойността на редки издания от 1700 г. в момента. В края на краищата всъщност временните набори от данни са уникални и е малко вероятно да се повторят в бъдеще.
3. Уводна част. Критерии за оценяване
По време на процеса на обработка беше разработена следната класификация на грешките.
1. Клас на грешка (въз основа на GOST R 8.736-2011): а) систематични грешки; б) случайни грешки; в) гаф.
2. По множественост: а) моно изкривяване; б) многоизкривяване.
3. Според критичността на последствията: а) критични; б) не критично.
4. По източник на възникване:
А) Технически – грешки, възникнали по време на работа на оборудването. Доста уместна грешка за IoT системи, системи със значителна степен на влияние върху качеството на комуникацията, оборудване (хардуер).
Б) Операторски грешки - грешки в широк диапазон от операторски правописни грешки при въвеждане до грешки в техническите спецификации за проектиране на база данни.
C) Потребителски грешки - тук са потребителските грешки в целия диапазон от „забравих да превключа оформлението“ до объркани метри за футове.
5. Отделени в отделен клас:
а) „задачата на разделителя“, тоест интервалът и „:“ (в нашия случай), когато е дублиран;
б) слято написани думи;
в) без интервал след служебните знаци
г) симетрично множество символи: (), "", "...".
Взети заедно, със систематизирането на грешките в базата данни, представени на фигура 5, се формира доста ефективна координатна система за търсене на грешки и разработване на алгоритъм за почистване на данни за този пример.
Ориз. 5. Типични грешки, съответстващи на структурните единици на базата данни (Източник: ).
Точност, интегритет на домейна, тип данни, последователност, излишък, пълнота, дублиране, съответствие с бизнес правилата, структурна определеност, аномалия на данните, яснота, навременност, спазване на правилата за интегритет на данните. (Страница 334. Основи на съхранението на данни за ИТ специалисти / Paulraj Ponniah.—2-ро изд.)
Представена е английска формулировка и руски машинен превод в скоби.
точност. Стойността, съхранена в системата за елемент от данни, е правилната стойност за това появяване на елемента от данни. Ако имате име на клиент и адрес, съхранени в запис, тогава адресът е правилният адрес за клиента с това име. Ако намерите количеството, поръчано като 1000 единици в записа за номер на поръчка 12345678, тогава това количество е точното количество за тази поръчка.
[Точност. Стойността, съхранена в системата за елемент от данни, е правилната стойност за това появяване на елемента от данни. Ако имате име и адрес на клиент, съхранени в запис, тогава адресът е правилният адрес за клиента с това име. Ако намерите количеството, поръчано като 1000 единици в записа за номер на поръчка 12345678, тогава това количество е точното количество за тази поръчка.]
Целостта на домейна. Стойността на данните на атрибут попада в обхвата на допустимите, дефинирани стойности. Често срещаният пример са допустимите стойности като „мъжки“ и „женски“ за елемента с данни за пола.
[Целостта на домейна. Стойността на атрибутните данни попада в обхвата на валидни, дефинирани стойности. Общ пример са валидните стойности "male" и "female" за елемент от данни за пол.]
Тип данни. Стойността за атрибут на данни всъщност се съхранява като тип данни, дефиниран за този атрибут. Когато типът данни на полето за име на магазина е дефиниран като „текст“, всички екземпляри на това поле съдържат името на магазина, показано в текстов формат, а не цифрови кодове.
[Тип данни. Стойността на атрибут на данни всъщност се съхранява като тип данни, дефиниран за този атрибут. Ако типът данни на полето за име на магазин е дефиниран като „текст“, всички екземпляри на това поле съдържат името на магазина, показано в текстов формат, а не в цифрови кодове.]
Последователност. Формата и съдържанието на едно поле с данни е едно и също в множество системи източници. Ако продуктовият код за продукт ABC в една система е 1234, тогава кодът за този продукт е 1234 във всяка изходна система.
[Постоянство. Формата и съдържанието на полето за данни са еднакви в различните системи източници. Ако продуктовият код за продукт ABC на една система е 1234, тогава кодът за този продукт е 1234 на всяка изходна система.]
Съкращаване. Едни и същи данни не трябва да се съхраняват на повече от едно място в една система. Ако, от съображения за ефективност, елемент от данни се съхранява умишлено на повече от едно място в системата, тогава излишъкът трябва да бъде ясно идентифициран и проверен.
[Съкращаване. Едни и същи данни не трябва да се съхраняват на повече от едно място в системата. Ако, от съображения за ефективност, елемент от данни се съхранява умишлено на множество места в една система, тогава излишъкът трябва да бъде ясно дефиниран и проверен.]
Пълнота. Няма липсващи стойности за даден атрибут в системата. Например във файл на клиента трябва да има валидна стойност за полето „състояние“ за всеки клиент. Във файла за подробности за поръчката всеки детайлен запис за поръчка трябва да бъде напълно попълнен.
[Пълнота. Няма липсващи стойности в системата за този атрибут. Например клиентският файл трябва да има валидна стойност за полето "статус" за всеки клиент. Във файла с подробности за поръчката всеки запис с подробности за поръчката трябва да бъде напълно попълнен.]
Дублиране. Дублирането на записи в системата е напълно разрешено. Ако е известно, че файлът на продукта има дублиращи се записи, тогава всички дублирани записи за всеки продукт се идентифицират и се създава кръстосана препратка.
[Дубликат. Дублирането на записи в системата е напълно елиминирано. Ако е известно, че файл с продукт съдържа дублиращи се записи, тогава всички дублирани записи за всеки продукт се идентифицират и се създава кръстосана препратка.]
Съответствие с бизнес правилата. Стойностите на всеки елемент от данни се придържат към предписаните бизнес правила. В аукционна система цената на чука или продажната цена не може да бъде по-ниска от резервната цена. В системата за банкови кредити салдото по кредита винаги трябва да бъде положително или нула.
[Спазване на бизнес правилата. Стойностите на всеки елемент от данни отговарят на установените бизнес правила. В аукционна система цената на чука или продажната цена не може да бъде по-ниска от резервната цена. В банковата кредитна система салдото по кредита винаги трябва да е положително или нула.]
Структурна определеност. Където даден елемент от данни може естествено да бъде структуриран в отделни компоненти, елементът трябва да съдържа тази добре дефинирана структура. Например, името на индивида естествено се разделя на собствено име, бащино име и фамилия. Стойностите за имената на лицата трябва да се съхраняват като собствено име, средно начално име и фамилия. Тази характеристика на качеството на данните опростява налагането на стандарти и намалява липсващите стойности.
[Структурна сигурност. Когато даден елемент от данни може да бъде естествено структуриран в отделни компоненти, елементът трябва да съдържа тази добре дефинирана структура. Например, името на човек е естествено разделено на собствено име, бащино име и фамилия. Стойностите за отделни имена трябва да се съхраняват като собствено име, средно начално и фамилно име. Тази характеристика на качеството на данните опростява прилагането на стандарти и намалява липсващите стойности.]
Аномалия в данните. Полето трябва да се използва само за целта, за която е дефинирано. Ако полето Address-3 е дефинирано за всеки възможен трети адресен ред за дълги адреси, тогава това поле трябва да се използва само за записване на третия адресен ред. Не трябва да се използва за въвеждане на телефонен или факс номер на клиента.
[Аномалия на данните. Едно поле трябва да се използва само за целта, за която е дефинирано. Ако полето Address-3 е дефинирано за всеки възможен трети адресен ред за дълги адреси, тогава това поле трябва да се използва само за запис на третия адресен ред. Не трябва да се използва за въвеждане на телефонен или факс номер на клиент.]
Яснота. Един елемент от данни може да притежава всички други характеристики на качествени данни, но ако потребителите не разбират ясно значението му, тогава елементът от данни няма стойност за потребителите. Правилните конвенции за именуване помагат елементите на данните да бъдат добре разбрани от потребителите.
[Яснота. Един елемент от данни може да има всички други характеристики на добрите данни, но ако потребителите не разбират ясно значението му, тогава елементът от данни няма стойност за потребителите. Правилните конвенции за именуване помагат елементите на данните да бъдат добре разбрани от потребителите.]
Навременно. Потребителите определят актуалността на данните. Ако потребителите очакват данните за клиентското измерение да не са по-стари от един ден, промените в клиентските данни в изходните системи трябва да се прилагат ежедневно към хранилището на данни.
[Своевременно. Потребителите определят актуалността на данните. Ако потребителите очакват данните за клиентските измерения да не са по-стари от един ден, промените в клиентските данни в изходните системи трябва да се прилагат към хранилището на данни ежедневно.]
Полезност. Всеки елемент от данни в хранилището на данни трябва да отговаря на някои изисквания на колекцията от потребители. Един елемент от данни може да е точен и с високо качество, но ако няма стойност за потребителите, тогава е напълно ненужно този елемент от данни да бъде в хранилището на данни.
[Помощна програма. Всеки елемент от данни в хранилището на данни трябва да отговаря на някои изисквания на потребителската колекция. Един елемент от данни може да е точен и с високо качество, но ако не предоставя стойност на потребителите, тогава не е необходимо този елемент от данни да бъде в хранилището на данни.]
Спазване на правилата за интегритет на данните. Данните, съхранявани в релационните бази данни на изходните системи, трябва да се придържат към правилата за цялост на обекта и референтна цялост. Всяка таблица, която позволява null като първичен ключ, няма цялост на обекта. Референтната цялост налага правилното установяване на връзките родител-дете. При връзката клиент към поръчка референтната цялост гарантира съществуването на клиент за всяка поръчка в базата данни.
[Спазване на правилата за цялост на данните. Данните, съхранявани в релационни бази данни на системи източници, трябва да отговарят на правилата за цялост на обекта и референтна цялост. Всяка таблица, която позволява null като първичен ключ, няма цялост на обекта. Референтната почтеност принуждава връзката между родители и деца да бъде установена правилно. При връзка клиент-поръчка референтната цялост гарантира, че съществува клиент за всяка поръчка в базата данни.]
4. Качество на почистване на данните
Качеството на почистването на данните е доста проблематичен въпрос в bigdata. Отговорът на въпроса каква степен на почистване на данните е необходима за изпълнение на задачата е фундаментален за всеки анализатор на данни. В повечето текущи проблеми всеки анализатор определя това сам и е малко вероятно някой отвън да може да оцени този аспект в неговото решение. Но за поставената задача в този случай този въпрос беше изключително важен, тъй като надеждността на правните данни трябва да клони към едно.
Разглеждане на технологии за тестване на софтуер за определяне на оперативната надеждност. Днес има повече от тези модели . Много от моделите използват модел за обслужване на искове:
Фиг. 6
Мислейки по следния начин: „Ако намерената грешка е събитие, подобно на събитието за повреда в този модел, тогава как да намерим аналог на параметъра t?“ И компилирах следния модел: Нека си представим, че времето, необходимо на тестер да провери един запис, е 1 минута (за въпросната база данни), след което, за да открие всички грешки, ще му трябват 365 494 минути, което е приблизително 3 години и 3 месеца работно време. Както разбираме, това е много голям обем работа и разходите за проверка на базата данни ще бъдат непосилни за компилатора на тази база данни. В това размишление се появява икономическата концепция за разходите и след анализ стигнах до извода, че това е доста ефективен инструмент. Въз основа на закона на икономиката: „Обемът на производството (в единици), при който се постига максималната печалба на фирмата, се намира в точката, където пределните разходи за производство на нова единица продукция се сравняват с цената, която тази фирма може да получи за нова единица." Въз основа на постулата, че намирането на всяка следваща грешка изисква все повече и повече проверки на записите, това е разходен фактор. Тоест, постулатът, възприет в моделите за тестване, придобива физическо значение по следния модел: ако за намиране на i-тата грешка е необходимо да се проверят n записа, тогава за намиране на следващата (i+1) грешка ще е необходимо за проверка на m записа и в същото време n
- Когато броят на проверените записи, преди да бъде открита нова грешка, се стабилизира;
- Когато броят на проверените записи преди намирането на следващата грешка ще се увеличи.
За да определя критичната стойност, се обърнах към концепцията за икономическа осъществимост, която в този случай, използвайки концепцията за социални разходи, може да се формулира по следния начин: „Разходите за коригиране на грешката трябва да се поемат от икономическия агент, който може да направи на най-ниската цена.“ Имаме един агент - тестер, който отделя 1 минута за проверка на един запис. В парично изражение, ако печелите 6000 рубли на ден, това ще бъде 12,2 рубли. (приблизително днес). Остава да се определи втората страна на равновесието в икономическото право. Разсъждавах така. Съществуваща грешка ще изисква от съответното лице да положи усилия, за да я коригира, тоест собственикът на имота. Да кажем, че това изисква 1 ден действие (подаване на заявление, получаване на коригиран документ). Тогава от социална гледна точка разходите му ще са равни на средната заплата на ден. Средна начислена заплата в Ханти-Мансийски автономен окръг 73285 рубли. или 3053,542 рубли/ден. Съответно получаваме критична стойност, равна на:
3053,542: 12,2 = 250,4 единици записи.
Това означава, от социална гледна точка, че ако тестер е проверил 251 записа и е намерил една грешка, това е еквивалентно на потребителя да поправи тази грешка сам. Съответно, ако тестерът е прекарал време, равно на проверка на 252 записа, за да намери следващата грешка, тогава в този случай е по-добре да прехвърлите разходите за корекция на потребителя.
Тук е представен опростен подход, тъй като от социална гледна точка е необходимо да се вземе предвид цялата допълнителна стойност, генерирана от всеки специалист, тоест разходите, включително данъци и социални плащания, но моделът е ясен. Следствие от тази връзка е следното изискване към специалистите: специалистът от ИТ индустрията трябва да има заплата, по-висока от средната за страната. Ако заплатата му е по-малка от средната заплата на потенциалните потребители на база данни, тогава той сам трябва да провери цялата база данни на ръка.
При използване на описания критерий се формира първото изискване за качеството на базата данни:
I(tr). Делът на критичните грешки не трябва да надвишава 1/250,4 = 0,39938%. Малко по-малко от злато в индустрията. И във физическо отношение има не повече от 1459 записа с грешки.
Икономическо отстъпление.
Всъщност, като прави такъв брой грешки в записите, обществото се съгласява с икономически загуби в размер на:
1459*3053,542 = 4 455 118 рубли.
Тази сума се определя от факта, че обществото не разполага с инструменти за намаляване на тези разходи. От това следва, че ако някой разполага с технология, която му позволява да намали броя на записите с грешки до например 259, тогава това ще позволи на обществото да спести:
1200*3053,542 = 3 664 250 рубли.
Но в същото време той може да поиска таланта и работата си, добре, да кажем - 1 милион рубли.
Тоест социалните разходи се намаляват с:
3 664 250 – 1 000 000 = 2 664 250 рубли.
По същество този ефект е добавената стойност от използването на BigDat технологиите.
Но тук трябва да се има предвид, че това е социален ефект, а собственик на базата данни са общинските власти, техните приходи от използването на имущество, регистрирано в тази база данни, в размер на 0,3%, са: 2,778 милиарда рубли / година. И тези разходи (4 455 118 рубли) не го притесняват много, тъй като те се прехвърлят на собствениците на имота. И в този аспект разработчикът на по-прецизни технологии в Bigdata ще трябва да покаже способността да убеди собственика на тази база данни, а такива неща изискват значителен талант.
В този пример алгоритъмът за оценка на грешката е избран въз основа на модела на Шуман [2] за проверка на софтуера по време на тестване за надеждност. Поради разпространението си в интернет и възможността за получаване на необходимите статистически показатели. Методологията е взета от Монахов Ю.М. „Функционална стабилност на информационните системи“, вижте под спойлера на фиг. 7-9.
Ориз. 7 – 9 Методология на модела на Шуман
Втората част на този материал представя пример за почистване на данни, в който се получават резултатите от използването на модела на Шуман.
Позволете ми да представя получените резултати:
Приблизителен брой грешки N = 3167 n.
Параметър C, ламбда и функция за надеждност:
Фиг. 17
По същество ламбда е действителен индикатор за интензивността, с която се откриват грешки на всеки етап. Ако погледнете втората част, оценката за този показател е 42,4 грешки на час, което е доста сравнимо с индикатора на Шуман. По-горе беше определено, че скоростта, с която програмист открива грешки, не трябва да бъде по-ниска от 1 грешка на 250,4 записа, когато се проверява 1 запис на минута. Оттук и критичната стойност на ламбда за модела на Шуман:
60 / 250,4 = 0,239617.
Тоест необходимостта от извършване на процедурите за намиране на грешки трябва да се извършва, докато ламбдата от наличните 38,964 падне до 0,239617.
Или докато показателят N (потенциален брой грешки) минус n (коригиран брой грешки) спадне под приетия от нас праг - 1459 бр.
Литература
- Монахов, Ю. М. Функционална стабилност на информационните системи. В 3 ч. Част 1. Надеждност на софтуера: учебник. помощ / Ю. М. Монахов; Владим. състояние унив. – Владимир: Изво Владим. състояние университет, 2011. – 60 с. – ISBN 978-5-9984-0189-3.
- Мартин Л. Шуман, „Вероятностни модели за прогнозиране на надеждността на софтуера.“
- Основи на съхранението на данни за ИТ специалисти / Paulraj Ponniah.—2-ро изд.
Източник: www.habr.com