1. Вихідні дані
Очищення даних – це одна з проблем, що стоять перед завданнями аналізу даних. У цьому матеріалі відобразив напрацювання, рішення, що виникли в результаті вирішення практичного завдання щодо аналізу БД при формуванні кадастрової вартості. Вихідники тут .
Розглядався файл «Порівняльний модель результат.ods» в «Додаток Б. Результати визначення КС 5. Відомості про метод визначення кадастрової вартості 5.1 Порівняльний підхід».
Таблиця 1. Статпоказники датасета у файлі «Порівняльний модель результат.ods»
Загальна кількість полів, прим. - 44
Загальна кількість записів, прим. - 365 490
Загальна кількість символів, прим. - 101 714 693
Середня кількість символів у записі, прим. - 278,297
Стандартне відхилення символів запису, шт. - 15,510
Мінімальна кількість символів у записі, шт. - 198
Максимальна кількість символів запису, шт. - 363
2. Вступна частина. Базові норми
Займаючись аналізом зазначеної БД сформувалася завдання щодо конкретизації вимог до ступеня очищення, оскільки, це зрозуміло всім, зазначена БД формує правові та економічні наслідки для користувачів. У процесі роботи виявилося, що жодних вимог до ступеня очищення великих даних не сформовано. Аналізуючи правові норми у цьому питанні дійшов висновку, що вони сформовані від можливостей. Тобто з'явилося певне завдання, під завдання комплектуються джерела інформації, далі формується датасет і, на основі датасету, що створюється, інструменти для вирішення задачі. Отримані рішення є реперними точками у виборі альтернатив. Представив це малюнку 1.
Так як, у питаннях визначення будь-яких норм, переважно спиратися на перевірені технології, то вибрав за основу критеріїв аналізу вимоги викладені в , тому що вважав цей документ найбільш цілісним для цього питання. Зокрема в цьому документі розділ написано «It should be noted that data integrity requirements apply equally to manual (paper) and electronic data.» (Пер. «… вимоги до цілісності даних поширюються однаково на ручні (паперові) та електронні дані»). Таке формулювання досить безпосередньо пов'язують із поняттям «письмовий доказ», у нормах ст.71 ЦПК, ст. 70 КАС, ст.75 АПК, «письменному вигляді» ст. 84 ЦПК.
На малюнку 2 представив схему формування підходів до видів інформації у юриспруденції.
Мал. 2. Джерело .
На малюнку 3 представлений механізм малюнка 1, для задач вищезгаданого «Guidance». Нескладно, проводячи зіставлення, побачити, що підходи, що використовуються, при виконанні вимог до цілісності інформації, в сучасних нормах до інформаційних систем, істотно обмежені, в порівнянні з правовим поняттям інформації.
Ріс.3
У зазначеному документі (Guidance) прив'язка до технічної частини, можливостей обробки та зберігання даних, добре підтверджується цитатою з глави 18.2. Relational database: «Ця файлова структура є вважаючи більшою мірою захистом, як цей файл є в значній частині файлу формату, який продовжує співвідносити між даними і metadata».
По суті, у такому підході – від існуючих технічних можливостей немає нічого нормального і, сам по собі, це природний процес, оскільки розширення понять походить від найбільш вивченої діяльності – проектування баз даних. Але, з іншого боку, з'являються правові норми, у яких не передбачено знижки на технічні можливості систем, наприклад: .
Мал. 4. Вирва технічних можливостей ().
У зазначених аспектах стає зрозумілим, що початковий датасет (рис. 1) повинен, насамперед, зберігатися, а друге чергу бути базою для вилучення з нього додаткової інформації. Ну як приклад: повсюдно поширені камери фіксації ПДР, системи інформаційної обробки відсівають порушників, але решта інформації також може бути запропонована іншим споживачам, допустимо як маркетинговий моніторинг структури потоку покупців до торгового центру. А це джерело додаткової доданої вартості під час використання Бігдата. Цілком можна припустити, що датасети, що збираються зараз, десь у майбутньому, матимуть цінність за механізмом аналогічним цінності раритетних видань 1700 років в даний час. Адже, по суті, тимчасові датасети є унікальними і малоймовірними, що повторюватися в майбутньому.
3. Вступна частина. Критерії оцінок
У процесі обробки було вироблено таку класифікацію помилок.
1. Клас помилки (за основу взято ГОСТ Р 8.736-2011): а) систематичні помилки; б) випадкові помилки; в) груба помилка.
2. За множинністю: а) моноспотворення; б) мультиспотворення.
3. За критичністю наслідків: а) критична; б) не критична.
4. За джерелом виникнення:
А) Технічна – помилки що виникають у процесі роботи устаткування. Досить актуальна помилка для IoT-систем, систем із значним ступенем впливу якості зв'язку, обладнання (заліза).
Б) Операторські – помилки в широкому діапазоні від друкарської помилки оператора при введенні до помилок у техзавданні на проектування БД.
В) Користувальницькі – тут помилки користувача у всьому діапазоні від «забув переключити розкладку» до того, що метри прийняв за фути.
5. Виділив в окремий клас:
а) «завдання роздільника», тобто пропуску та «:» (у нашому випадку) коли його продублювали;
б) разом написаних слів;
в) відсутності пропуску після службових символів
г) симетрично-множинні символи: (), «», «…».
У сукупності, з систематизацією помилок БД представлених малюнку 5, складається досить ефективна система координат пошуку помилок і вироблення алгоритму очищення даних, цього прикладу.
Мал. 5. Типові помилки, що відповідають структурним одиницям БД (Джерело: ).
Accuracy (Точність), Domain Integrity (Цілісність), Data Type (Тип даних), Consistency (Консистенція), Redundancy (Надмірність), Completeness (Повнота), Duplication (Дублювання), Conformance to Business Rules (Дотримання бізнес-правил), Structure Definiteness (Структурна Визначеність), Data Anomaly (Аномалія Даних), Clarity (Ясність), Timely (Своєчасність), Adherence to Data Integrity Rules (Дотримання правил цілісності даних). (Стор. 334. Data warehousing fundamentals for IT professionals / Paulraj Ponniah.-2nd ed.)
Представив англійські формулювання та у дужках російський машинний переклад.
Accuracy. Значення встановлене в системі для елемента даних є правом значення для того, що випливає з цього елемента. Якщо ви маєте custommer name і address stored in a record, the address is the correct address for the customer with that name. Якщо ви з'ясували, що вартість встановлена як 1000 одиниць в записі для числа 12345678, то, що вартість є принаймні вартості для того, щоб.
[Точність. Значення, збережене в системі елемента даних, є правильним значенням для цього входження елемента даних. Якщо у вас є ім'я клієнта та адреса, збережені в записі, адреса є правильною адресою для клієнта з цим ім'ям. Якщо ви знайдете кількість, замовлену як 1000 одиниць у записі для замовлення номер 12345678, то ця кількість є точною кількістю для цього замовлення.]
Domain Integrity. Значення значення даних про atribut falls in the range of allowable, defined values. Цей загальний випадок є відповідними значеннями, що становлять “mal” та “female” для gender data element.
[Цілісність Домена. Значення даних атрибута потрапляє до діапазону допустимих, певних значень. Загальний приклад-допустимі значення «чоловічий» та «жіночий» для елемента гендерних даних.]
Data Type. Value for data attribute є фактично stored as the data type defined for that attribute. У той час, як тип вікна name field is defined as “text,” all instances of that field contain the store name shown in textual format and not numeric codes.
[Тип даних. Значення атрибуту даних фактично зберігається як тип даних, визначений цього атрибута. Якщо тип даних поля ім'я магазину визначено як „текст“, усі екземпляри цього поля містять ім'я магазину, яке відображається у текстовому форматі, а не у числових кодах.]
Консистенція. Форма і вміст земної сторінки є тим самим шляхом множинних системних систем. Якщо продукт коду для виробу ABC в одному системі є 1234, то код для цього продукту є 1234 в одному source system.
[Консистенція. Форма та зміст поля даних однакові у різних системах-джерелах. Якщо код продукту для продукту ABC в одній системі дорівнює 1234, код для цього продукту дорівнює 1234 в кожній вихідній системі.]
Redundancy. Ті ж самі дані не повинні бути запозичені в більш ніж одного місця в системі. Якщо, на підставі ефективності, цей елемент є неодноразово переміщений в більше, ніж одне місце в системі, то в глибині необхідно бути чітко identified і verified.
[Надмірність. Одні й самі дані не повинні зберігатися більш ніж в одному місці системи. Якщо з міркувань ефективності елемент даних навмисно зберігається у кількох місцях системи, то надмірність має бути чітко визначено і перевірено.]
Completeness. Вони не мають значення для господаря atribut в системі. Для прикладу, в customer file, вони повинні бути вірними значенням для “держава” field for every customer. У файлі для ордерних details, every detail record for order must be completely filled.
[Повнота. У системі немає пропущених значень даного атрибута. Наприклад, у файлі клієнта має бути допустиме значення поля стан для кожного клієнта. У файлі відомостей про замовлення кожен запис відомостей про замовлення має бути повністю заповнений.]
Duplication. Duplication of records in system is completely resolved. Якщо продукт файлу є відомим, що має duplicate records, то всі duplicate records для кожного продукту є identified і cross-reference created.
[Дублювання. Дублювання записів у системі повністю усунуто. Якщо відомо, що файл продукту містить записи, що повторюються, то всі повторювані записи для кожного продукту ідентифікуються і створюється перехресне посилання.]
Conformance to Business Rules. Ціни на всі дані адреси входять до висловлених business rules. У акційній системі, гаманець або продаж цін не може бути невідповідним ціною. У банківській системі, баланс балансу повинні бути позитивними або cero.
[Дотримання бізнес-правил. Значення кожного елемента даних відповідають встановленим бізнес-правилам. В аукціонній системі ціна молотка або продажу не може бути меншою за резервну ціну. У банківській кредитній системі баланс кредиту завжди має бути позитивним або нульовим.
Structural Definiteness. Wherever data item can naturally be structured into individual components, the item must contain this well-defined structure. Для прикладу, індивідуальні назви природно відокремлюються в першу назву, середній початковий, і останній назви. Values for names of individuals повинні бути отримані як перші назви, середній початковий, і останній назви. Це характерне значення для даної якості загрожує встановленню стандартів і змінюється зменшення цін.
[Структурна Визначеність. Там, де елемент даних може бути природно структурований на окремі компоненти, елемент повинен містити цю чітко визначену структуру. Наприклад, ім'я людини природним чином ділиться на ім'я, середній ініціал та прізвище. Значення для імен фізичних осіб повинні зберігатися у вигляді імені, середнього ініціалу та прізвища. Ця характеристика якості даних спрощує застосування стандартів і зменшує недостатні значення.]
Data Anomaly. A field must be used тільки для purpose for which it is defined. Якщо поле Address-3 є визначеним для будь-якої третьої лінії адреси для довгих адрес, то ця область повинна бути використана тільки для відображення третьої лінії адреси. Це не потрібно використовувати для вводу телефону або faxу номер для customers.
[Аномалія даних. Поле має використовуватися тільки для тієї мети, на яку воно визначено. Якщо поле Address-3 визначено для будь-якого третього рядка адреси для довгих адрес, то це поле має використовуватися тільки для запису третього рядка адреси. Він не повинен використовуватися для введення номера телефону або факсу для клієнта.]
Clarity. A element element може визначати всі інші характеристики якості даних, але якщо користувачі не підтримують його clearly, тоді елемент element не є значенням для користувачів. Власне назви сприяють придбання даних елементів добре підтверджено користувачами.
[Ясність. Елемент даних може мати всі інші характеристики якісних даних, але якщо користувачі не розуміють його значення ясно, то елемент даних не представляє цінності для користувачів. Правильні угоди про назву допомагають зробити елементи даних добре зрозумілими користувачам.]
Timely. Users визначить timeliness the data. lf the users expect customer dimension data не буде одержувати протягом одного дня, зміни до customer data в source systems повинні бути applied to data warehouse daily.
[Своєчасно. Користувачі визначають своєчасність даних. якщо користувачі очікують, що дані вимірювання клієнта не будуть старшими за один день, зміни даних клієнта у вихідних системах повинні застосовуватися до сховища даних щодня.]
Usefulness. Усі дані елемента в data warehouse повинні бути надійними для деяких потреб collection of users. A data element може бути виявлений і високої якості, але якщо це не значення для користувачів, то це повністю необхідне для цього елемента для be data warehouse.
[Корисність. Кожен елемент даних у сховищі даних повинен відповідати деяким вимогам колекції користувачів. Елемент даних може бути точним і мати високу якість, але якщо він не представляє цінності для користувачів, то необов'язково, щоб цей елемент даних знаходився в сховищі даних.]
Adherence to Data Integrity Rules. Data data stored in relative databases of the source systems повинна поєднуватися з entity integrity and referential integrity rules. Any table that permits null as the primary key does not have entity integrity. Referential integrity forces establishment of the parent-child relationships correctly. В customer-to-order relationship, referential integrity ensures the existention of a customer for every order in the database.
[Дотримання правил цілісності даних. Дані, що зберігаються в реляційних базах даних вихідних систем, повинні відповідати правилам цілісності сутностей та цілісності посилань. Будь-яка таблиця, яка допускає null як первинний ключ, не має цілісності сутності. Посилочна цілісність змушує правильно встановлювати стосунки між батьками та дітьми. У відносинах клієнт-замовлення посилання цілісність забезпечує існування клієнта для кожного замовлення в базі даних.]
4. Якість очищення даних
Якість очищення даних досить проблематичне питання у бігдата. Відповісти на питання, який ступінь очищення даних необхідний при виконанні поставленого завдання, є основним для кожного датаанлітика. У більшості поточних завдань кожен аналітик встановлює це сам і навряд чи хтось із боку здатний оцінити цей аспект у його вирішенні. Але для поставленого завдання в цьому випадку це питання було дуже важливим, оскільки достовірність правових даних повинна прагнути одиниці.
Розглядаючи технології тестування програмного забезпечення щодо визначення надійності в роботі. Цих моделей на сьогоднішній день більше . Багато моделей використовують модель обслуговування заявок:
Рис. 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 записів, то в цьому випадку витрати на виправлення краще перекласти на користувача.
Тут представлений спрощений підхід, оскільки з суспільної точки зору необхідно враховувати всю додаткову вартість, яку генерує кожен спеціаліст, тобто витрати з урахуванням податків і соцплатежів, але модель зрозуміла. Наслідком із цього взаємозв'язку стає вимога до фахівців така: спеціаліст з IT галузі повинен мати зарплатню більшу, ніж у середньому по країні. Якщо його з/п менше, ніж у середнє значення з/п потенційних користувачів БД, він сам повинен перевірити всю БД в рукопашну.
При використанні описаного критерію формується перша вимога до якості БД:
I(тр). Частка критичних помилок має перевищувати величини 1/250,4 = 0,39938%. Трохи менше ніж золота у промисловості. І в натуральному вимірі не більше 1459 записів із помилками.
Економічний відступ.
По суті, припускаючи таку кількість помилок у записах, суспільство погоджується на економічні втрати в обсязі:
1459 * 3053,542 = 4 руб.
Ця сума визначається тим фактом, що у суспільства відсутні інструменти, що дозволяють знизити ці витрати. Звідси випливає, якщо в когось з'явиться технологія, яка дозволяє знизити кількість записів з помилками, наприклад, до 259, то це дозволяє суспільству економити:
1200 * 3053,542 = 3 руб.
Але при цьому він може попросити за свій талант і працю, припустімо - 1 млн. руб.
Тобто суспільні витрати скорочуються на:
3 - 664 = 250 руб.
По суті, цей ефект є доданою вартістю від використання технологій Бігдата.
Але тут слід враховувати, що це суспільний ефект, а власником БД є державні органи влади, їхній дохід від використання майна, зафіксованого в цій БД, при ставці 0,3% становить: 2,778 млрд. руб./рік. А ці витрати (4 руб.) Його сильно не хвилюють, так як перекладені на власників майна. І, в цьому аспекті, розробник, більш афінажних технологій у Бігдаті, повинен буде виявити вміння переконати власника цієї БД, а на такі речі потрібен чималий талант.
В даному прикладі алгоритм оцінки помилок був обраний на основі моделі Шумана [2] перевірки ПЗ при тестуванні на безвідмовність. Через її поширеність у мережі та можливості отримати необхідні статистичні показники. Методологію взято з Монахів Ю.М. «Функціональна стійкість інформаційних систем» дивіться під спойлером на рис. 7-9.
Мал. 7 – 9 Методологія моделі Шумана
У другій частині даного матеріалу наведено приклад очищення даних, в якому отримані результати використання моделі Шумана.
Представлю отримані результати:
Ймовірна кількість помилок N = 3167 шN.
Параметр С, лямбда та функція надійності:
Ріс.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.
- Martin L. Shooman, "Probabilistic models for software reliability prediction".
- Data warehousing fundamentals for IT professionals / Paulraj Ponniah.-2nd ed.
Джерело: habr.com