Система виявлення підозрілих даних

При проектуванні облікових систем велика увага приділяється розробці процедур контролю коректності введених даних. Причина цілком зрозуміла: неправильні дані при заповненні замовлення на купівлю, помилки при введенні інформації до страхового контракт, суперечлива інформація про одне й те ж клієнта з різних систем можуть служити причиною прийняття неправильних рішень і, як наслідок, вести до фінансових і репутаційним втрат компанії. Традиційно, контроль правильності введення інформації лягає на СУБД і на бізнес-логіку додатка. На рівні бази даних контролюється заповненість полів, посилальна цілісність, дотримання простих бізнес-правил (наприклад, кількість придбаних товарів має бути позитивним). Дотримання більш складних бізнес-правил (наприклад, ліміт заборгованості покупця при формуванні нового замовлення не повинен перевищувати певну суму) часто контролюється на рівні додатку, хоча іноді цим також займається база даних на рівні тригерів. Контроль несуперечності даних з різних систем, у процесі якого дані перевіряються на відповідність різними правилами, часто здійснюється на рівні імпорту їх в загальне аналітичне сховище. Це дозволяє, уникаючи явних колізій, будувати зведені аналітичні звіти по всіх процесів в компанії зі всіх облікових систем.


Всі ці традиційні і необхідні підходи об'єднує вимога чіткого опису та формалізації всіх правил, на відповідність яким система повинна перевіряти вхідні дані. Однак існують помилки введення, які заздалегідь передбачити дуже важко або неможливо. Наприклад, ми можемо передбачити формальні бізнес-правила, що описують, що знижка на товар не може бути більше 100%; людина, яка бере кредит, повинен бути повнолітнім; а в чеку всі покупки повинні бути з позитивними величинами. У цьому випадку надана знижка в розмірі 98% при купівлі автомобіля; дев'ятнадцятирічний вік людини, оформляє кредит на покупку будинку; 5 кілограм петрушки в чеку в супермаркеті теоретично не виключені, але вкрай підозрілі. Існують декілька підходів щодо виявлення таких підозрілих даних і сигналізації про них.


Перший підхід грунтується на принципах нечіткої логіки, тобто коли обмеження на розмір знижки, вік або обсяг закупівлі формулюються в кілька розмитих термінах приналежності до допустимого безлічі. Тобто функція належності до категорії "молода людина" приймає значення 1 ("точно" молодий) в діапазоні віку від 0 до 25 років, значення 0 ("точно" не молодий) в діапазоні більше 45 років і проміжне значення від 0 до 1 між 25 і 45 роками. Алгебра з нечіткими множинами цілком описується операціями з нечіткими функціями належності, так, наприклад, чи є людина одночасно молодим і багатим описується твором функції його приналежності до безлічі молодих і функції приналежності до безлічі багатих. Цей підхід досить поширений, але має недоліком, що полягає в довільності опису нечітких кордонів, форми функції приналежності і вибором порогових значень для прийняття рішень. Внаслідок цього потрібний великий час для адаптації таких правил до реальних вимог, а також велика залежність від експертних оцінок.


Другий і більш ефективний, на наш погляд, підхід полягає в статистичному аналізі вводиться запису та оцінці її імовірності у вже накопиченої історії записів того ж типу. Так як сукупність історичних записів може бути неоднорідною, то ми повинні враховувати вже сформовану структуру в накопиченої інформації. Тобто спочатку ми повинні виділити в накопиченої історії групи схожих за статистичними характеристиками записів (кластерів) і оцінити ймовірність перевіряється на підозріливість інформації на приналежність до однієї з вже виділених груп. Якщо інформація, що вводиться не вписується в сформовану структуру, тобто ймовірність її приналежності до всіх виділених груп мала (нижче певного порогу), то система сигналізує про наявність підозрілого введення та необхідності проведення додаткової перевірки цієї інформації на правильність.


Ми пропонуємо реалізацію описаного підходу на платформі Microsoft SQL Server Analysis Services 2005/2008 з використанням алгоритму кластеризації Expectation Maximization. В якості клієнтської програми візуального аналізу підозрілих даних можна використовувати Microsoft Excel 2007.








 

Рис. 1 – Виявлені виключення виділені кольором. У рядках також виділена найбільш "підозріла" осередок.


Проілюструємо цей підхід на демонстраційних даних про клієнтів компанії Adventure Works. У нас є таблиця з наступною інформацією про клієнтів:



  1. Створимо структуру даних у Analysis Services для здійснення кластерного аналізу за допомогою наступного DMX-Запиту:

    CREATE MINING STRUCTURE [Input Cluster Structure]
    (
       [CustomerKey] LONG KEY,
    [Сімейний стан] TEXT DISCRETE,
    [Пол] TEXT DISCRETE,
    [Річний дохід] Long Continuous,
    [Число дітей] Long DISCRETE,
    [Освіта] TEXT DISCRETE,
    [Рід занять] TEXT DISCRETE,
    [Власник будинку] TEXT DISCRETE,
    [Число машин] Long DISCRETE,
    [Відстань до роботи] TEXT DISCRETE,
    [Регіон] TEXT DISCRETE,
    [Вік] LONG CONTINUOUS
    )

  2. Створимо модель кластерного аналізу у вже створеній структурі даних за допомогою наступного DMX-Запиту:

    ALTER MINING STRUCTURE [Input Cluster Structure]
    ADD MINING MODEL [Input Cluster Model]
    (
       [CustomerKey],
    [Сімейний стан] PREDICT,
    [Пол] PREDICT,
    [Річний дохід] PREDICT,
    [Число дітей] PREDICT,
    [Освіта] PREDICT,
    [Рід занять] PREDICT,
    [Власник будинку] PREDICT,
    [Число машин] PREDICT,
    [Відстань до роботи] PREDICT,
    [Регіон] PREDICT,
    [Вік] PREDICT
    ) USING Microsoft_Clustering (CLUSTER_COUNT = 0) WITH DRILLTHROUGH

  3. Навчимо модель на накопичених даних з таблиці SQL за допомогою наступного DMX-Вирази:

    INSERT INTO MINING STRUCTURE [Input Cluster Structure]
    (
       [CustomerKey],
    [Сімейний стан],
    [Пол],
    [Річний дохід],
    [Число дітей],
    [Освіта],
    [Рід занять],
    [Власник будинку],
    [Число машин],
    [Відстань до роботи],
    [Регіон],
    [Вік]
    )
    OPENROWSET
    (
       “SQLNCLI”,
    "Server =.; Database = AdventureWorksDW; Trusted_Connection = yes;",
       ”
           SELECT
                 [CustomerKey],
    [Сімейний стан],
    [Пол],
    [Річний дохід],
    [Число дітей],
    [Освіта],
    [Рід занять],
    [Власник будинку],
    [Число машин],
    [Відстань до роботи],
    [Регіон],
    [Вік]
           FROM
           dbo.InputErrors
       ”
    )

  4. Тепер ми можемо написати запит на отримання ймовірності кожного рядка даних, що вводяться, а також на розподіл ймовірностей для всіх стовпців для оцінки ймовірності значень в кожному стовпці за допомогою наступного DMX-Вирази:

    SELECT
    T. [Сімейний стан],
    PredictHistogram ([Сімейний стан]) AS [Розподіл на "Сімейний стан"],
    T. [Пол],
    PredictHistogram ([Пол]) AS [Розподіл на "Пол"],
    T. [Річний дохід],
    Predict ([Річний дохід]) AS [Середня для "Річний дохід"],
    PredictVariance ([Річний дохід]) AS [Дисперсія для "Річний дохід"],
    T. [Число дітей],
    PredictHistogram ([Число дітей]) AS [Розподіл на "Число дітей"],
    T. [Освіта],
    PredictHistogram ([Освіта]) AS [Розподіл на "Освіта"],
    T. [Рід занять],
    PredictHistogram ([Рід занять]) AS [Розподіл на "Рід занять"],
    T. [Власник будинку],
    PredictHistogram ([Власник будинку]) AS [Розподіл на "Власник будинку"],
    T. [Кількість машин],
    PredictHistogram ([Кількість машин]) AS [Розподіл на "Кількість машин"],
    T. [Відстань до роботи],
    PredictHistogram ([Відстань до роботи]) AS [Розподіл на "Відстань до роботи"],
    T. [Регіон],
    PredictHistogram ([Регіон]) AS [Розподіл на "Регіон"],
    T. [Вік],
    Predict ([Вік]) AS [Середня для "Вік"],
    PredictVariance ([Вік]) AS [Дисперсія для "Вік"],
    PredictCaseLikelihood () AS [Імовірність всього рядка]
    FROM
       [Input Cluster Model]
       PREDICTION JOIN
       OPENROWSET
       (
            “SQLNCLI”,
    "Server =.; Database = AdventureWorksDW; Trusted_Connection = yes;",
            ”
                SELECT
                    [CustomerKey],
    [Сімейний стан],
    [Пол],
    [Річний дохід],
    [Число дітей],
    [Освіта],
    [Рід занять],
    [Власник будинку],
    [Число машин],
    [Відстань до роботи],
    [Регіон],
    [Вік]
                FROM
                dbo.InputErrors
            ”
       ) AS T
       ON
    T. [Сімейний стан] = [Input Cluster Model]. [Сімейний стан]
    AND T. [Пол] = [Input Cluster Model]. [Пол]
    AND T. [Річний дохід] = [Input Cluster Model]. [Річний дохід]
    AND T. [Число дітей] = [Input Cluster Model]. [Число дітей]
    AND T. [Освіта] = [Input Cluster Model]. [Освіта]
    AND T. [Рід занять] = [Input Cluster Model]. [Рід занять]
    AND T. [Власник будинку] = [Input Cluster Model]. [Власник будинку]
    AND T. [Число машин] = [Input Cluster Model]. [Число машин]
    AND T. [Відстань до роботи] = [Input Cluster Model]. [Відстань до роботи]
    AND T. [Регіон] = [Input Cluster Model]. [Регіон]
    AND T. [Вік] = [Input Cluster Model]. [Вік]
    ORDER BY PredictCaseLikelihood()

  5. За результатами виконання цього запиту можна виділити найменш ймовірні запису. Такими в нашому прикладі є:

    • Одружений 30-річний чоловік з Північної Америки з двома дітьми з бакалаврськими освітою, але працюючий робочим і отримує 10 000 доларів на рік.
    • 80-річний чоловік з Європи з річним доходом 130 000 доларів на рік з вченим ступенем без машини і без будинку.

Таким чином, використання коштів Data Mining дозволяє швидко і ефективно виявляти підозрілі і, можливо, помилкові дані, що підвищує контроль цілісності і несуперечності інформації в облікових і аналітичних системах компанії.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*