Система з виявлення підозрілих даних, Криптографія, Security & Hack, статті

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


Всі ці традиційні і необхідні підходи об’єднує вимога чіткого опису та формалізації всіх правил, на відповідність яким система повинна перевіряти вхідні дані. Однак існують помилки введення, які заздалегідь передбачити дуже важко або неможливо. Наприклад, ми можемо передбачити формальні бізнес-правила, що описують, що знижка на товар не може бути більше 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>

*

*