- Целостность
- Вопросы безопасности баз данных
- Представления базы данных
- Многоэкземплярность
- Обработка транзакций в режиме реального времени
- Хранилища и интеллектуальный анализ данных
Как и другие сетевые ресурсы, базы данных могут столкнуться с проблемами конкуренции. Проблемы конкуренции возникают, когда определенные ресурсы или данные должны быть доступны одновременно нескольким пользователям и/или приложениям. Рассмотрим следующий пример. Две группы пользователей используют один и тот же файл, содержащий таблицу товаров с ценами, чтобы знать, какой объем поставок нужен на следующей неделе, а также рассчитать ожидаемую прибыль. Если Дэн и Элизабет копируют этой файл с файлового сервера, на свои рабочие станции, у каждого из них есть копия оригинального файла. Предположим, что Дэн измененил объем складского запаса книг о компьютерах от 120 до 5, поскольку их компания продала 115 книг в течение последних трех дней. Затем он на основе текущих цен, указанных в файле, рассчитывает ожидаемую прибыль на следующую неделю. Элизабет снижает цены на ряд программных пакетов в своей копии файла и видит, что объем складских запасов книг о компьютерах еще более 100 единиц, поэтому она решает не заказывать их на следующую неделю. Дэн и Элизабет не сообщают эту информацию друг другу, а просто загружают свои копии исправленного файла на сервер для общего просмотра и использования.
Сначала Дэн копирует свои изменения на файл-сервер, а затем, через 30 секунд после Дэна, Элизабет копирует свои изменения. Как вы понимаете, теперь на файловом сервере хранится файл, в котором указаны только изменения, произведенные Элизабет, т.к. она записала свой файл поверх файла Дэна. Они не синхронизировали свои изменения и оба воспользовались неверными данными. Расчеты прибыли Дэна неверны, т.к. он не знал, что Элизабет снизила цены на следующую неделю, а у Элизабет не будет компьютерных книг, потому что она не знала, что их остаток упал до пяти единиц.
То же самое происходит и в базах данных. Если в ней не реализован соответствующий контроль, два пользователя могут одновременно использовать и изменять одни и те же данные, что может иметь пагубные последствия для динамичной среды. Чтобы исключить проблемы конкуренции, процессы могут блокировать таблицы в базе данных, вносить изменения, а затем снимать программную блокировку. При этом когда следующий процесс будет обращаться к таблице, он получит обновленную информацию. Применение блокировки гарантирует, что два процесса не получат одновременный доступ к одной и той же таблице, а обновления будут выполняться по одному за раз. Блокировка может быть выполнена для отдельных страниц, таблиц, строк и полей, что обеспечит возможность предоставления каждому процессу и пользователю правильной и точной информации.
Программное обеспечение базы данных реализует три основных типа механизмов обеспечения целостности: семантический, ссылочный и логический. Механизм семантической целостности (semantic integrity) обеспечивает реализацию структурных и семантических правил. Эти правила относятся к типам данных, логическим значениям, требованиям уникальности, а также операциям, которые могут оказать негативное воздействие на структуру базы данных. Данные в базе данных должны изменяться таким образом, чтобы не нарушалась установленная между ними смысловая (семантическая) связь. В базе данных обеспечивается ссылочная целостность (referential integrity), если все внешние ключи ссылаются на существующие первичные ключи. Должен быть реализован механизм, который обеспечивает отсутствие внешних ключей, содержих ссылку на первичный ключ несуществующей записи или на пустое значение. Логическая целостность (entity integrity) гарантирует, что записи уникально идентифицируются по значениям первичного ключа. В рассмотренном ранее примере первичными ключами являются клички собак. Для обеспечения логической целостности, в базе данных не должно существовать двух собак с одинаковыми кличками. Каждая запись должна содержать один первичный ключ, т.к. если запись не имеет первичного ключа, на нее не может ссылаться база данных.
База данных не должна содержать несогласованных значений внешних ключей, т.е. не должна иметь внешних ключей, ссылающихся на несуществующие первичные ключи. Возвращаясь к тому же примеру с собаками, если внешний ключ в Таблице В – «Шарик», то Таблица А должна содержать запись для собаки по кличке «Шарик». Если эти значения не совпадают, то нарушается их связь и база данных не может правильно ссылаться на информацию.
Существуют и другие настраиваемые операции, обеспечивающие защиту целостности данных в базе данных. Такими операциями являются функции отката, фиксации, точек сохранения, а также контрольных точек.
Откат (rollback) – это операция, которая прерывает текущую транзакцию и отменяет все произведенные в рамках этой транзакции изменения в базе данных. Эти изменения могут касаться самих данных или схемы. При выполнении операции отката, отмененяются все изменения и база данных возвращается в свое предыдущее состояние (точку сохранения). Откат может потребоваться в случае, если в базе данных произошел неожиданный сбой или внешний субъект нарушил последовательность обработки. Вместо того чтобы передавать и сохранять частичную или поврежденную информацию, база данных просто возвращается в исходное состояние, а в журнал регистрации событий записывается сообщение об ошибке и выполненных действиях, чтобы они могли быть проанализированы позднее.
Операция фиксации (commit) завершает транзакцию и применяет все изменения, сделанные пользователем, т.е. эта операция реально записывает все изменения в базу данных. Эти изменения могут относиться к данным или к схеме. После фиксации этих изменений, обновленные данные будут доступны для всех других приложений и пользователей. Если пользователь попытается выполнить операцию фиксации изменений, но эта операция не сможет завершиться правильно, выполняется откат. Это гарантирует отсутствие в базе данных частичных изменений и поврежденных данных.
Точки сохранения (savepoints) используются для того, чтобы обеспечить восстановление целостности базы данных в случае сбоев и ошибок. При возникновении сбоя или ошибки, база данных пытается вернуться к точке (состоянию), в которой она находилась непосредственно перед возникновением этого сбоя или ошибки. Чтобы понять основной принцип, рассмотрим следующий пример. Дэйв ввел текст «В 2010 году компанией получена прибыль в размере 1 млн.руб. Планы <точка сохранения> по прибыли выполнены на 115%». Сразу после этого произошел сбой электропитания, который привел к перезагрузке системы. Когда Дэйв снова запустил клиентское приложение базы данных, он увидел следующий текст: «В 2010 году компанией получена прибыль в размере 1 млн.руб. Планы », но дальше текст был потерян. Таким образом, точка сохранения обеспечила сохранность некоторой части его работы. Базы данных и другие приложения используют эту технологию, чтобы попытаться восстановить работу пользователей и состояние базы данных после сбоя, однако иногда происходят крупные сбои, которые невозможно исправить с помощью этой технологии.
Реализовать точки сохранения в базе данных или другом приложении легко, однако необходимо обеспечить баланс между слишком большим и слишком малым количеством точек сохранения. Использование слишком большого их количества может ухудшить производительность, тогда как недостаточное количество повышает риск потери данных и тем самым снижает продуктивность работы пользователей, т.к. потерянные данные им придется вводить заново. Точки сохранения могут создаваться через определенные промежутки времени, определенными действиями пользователя, либо при достижении определенного числа транзакций или изменений, внесенных в базу данных. Например, база данных может быть настроена на создание точки сохранения каждые 15 минут, после ввода каждых 20 операций, а также каждый раз, когда пользователь доходит до последней записи.
Точки сохранения позволяют восстанавить данные, давая пользователю возможность вернуться назад во времени до момента, когда система вышла из строя или произошла ошибка. Это может уменьшить количество проблем и помогает нам работать более эффективно.
ПРИМЕЧАНИЕ. Контрольные точки (checkpoint) очень похожи на точки сохранения. Создание контрольной точки инициируется, когда программное обеспечение базы данных заполняет определенный объем памяти. При этом все данные из сегмента памяти записываются во временный файл. При возникновении сбоя, программное обеспечение пытается использовать эту информацию, чтобы восстановить рабочую среду пользователя в состоянии, предшествующем сбою.Механизм двухэтапной фиксации (two-phase commit) – это еще одна защитная мера, которая применяется для обеспечения целостности данных в базе данных. Базы данных обычно работают в транзакционном режиме, что означает взаимодействие пользователя и базы данных в режиме реального времени. Противоположностью является режим пакетной обработки, при котором запросы на изменение базы данных ставятся в очередь и активируются все сразу, но не в тот же момент времени, когда пользователь делает каждый запрос. При выполнении транзакций, часто возникает потребность в обновлении более чем одной базы данных в рамках транзакции. Программное обеспечение должно убедиться, что в каждой базе данных выполнены необходимые изменения, либо не произошло никаких изменений ни в одной из баз данных. После подтверждения пользователем необходимости изменения базы данных, базы данных сначала выполняют временное сохранение этих изменений. Затем монитор транзакций отправляет команду «предфиксации» (pre-commit) каждой базе данных. Если все базы данных ответили подтверждением, монитор посылает каждой базе данных команду «фиксации» (commit). Это обеспечивает корректное и своевременное сохранение всех необходимых данных.
Ссылки по теме:
Двумя основными вопросами безопасности баз данных, которые рассмотрены в этом разделе, являются агрегирование и предположения. Агрегирование (aggregation) может выполняться, когда пользователь не имеет допуска или разрешения на доступ к определенной информации, но у него есть разрешение на доступ к частям этой информации. Ознакомившись со всеми частями, к которым у него есть доступ, он может догадаться об остальной информации и получить, таким образом, сведения ограниченного доступа. Также он может получить информацию из различных источников и объединить ее, чтобы узнать что-то, к чему у него нет допуска.
ПРИМЕЧАНИЕ. Агрегирование – это действие по объединению информации из различных источников. Полученное в результате сочетание данных формирует новую информацию, к которой у субъекта нет прав доступа. Совокупная информация имеет большую критичность, чем отдельные ее части.Для предотвращения агрегирования, нужно предотвратить возможность доступа субъекта (и любого приложения или процесса, действующего от имени субъекта) ко всему набору, состоящему из независимых компонентов. Для этого объекты могут быть помещены в контейнеры, которым присвоены более высокие уровни классификации, что позволит исключить доступ к ним субъектов с менее высоким уровнем допуска. Также можно отслеживать запросы субъекта и применять системы контекстно-зависимого управления доступом. Для этого нужно сохранять историю доступа субъекта и на основании нее динамически ограничивать попытки доступа, если обнаружены признаки проведения атаки агрегирования.
Другая проблема безопасности заключается в предположениях (inference), являющихся результатом агрегирования. Субъект догадывается (предполагает, делает выводы) о полной истории на основе отдельных ее частей, которые он узнал в процессе агрегирования. Это может проявиться, когда данные на более низком уровне безопасности, косвенно отражают данные более высокого уровня безопасности.
ПРИМЕЧАНИЕ. Предположения позволяют получить информацию, не доступную в явном виде.Рассмотрим следующий пример. Доступ военнослужащего к сведениям о планах передвижения войск, базирующихся в определенной стране, был ограничен. Но он имел доступ к документам с требованиями по поставкам продовольствия и распределению палаток. На основании информации, к которой у него был доступ, он мог догадаться о перемещении войск в конкретное место, зная, что туда направлено продовольствие и палатки. В рассматриваемом примере, документы, касающиеся продовольствия и палаток были отнесены к категории «конфиденциально», а сведения о перемещении войск имели гриф «совершенно секретно». Таким образом, этот военнослужащий мог получить доступ к сверхсекретной информации, которую он не должен знать.
Предотвратить подобный косвенный доступ субъекта (либо любого приложения или процесса, действующего от имени субъекта) к информации, которая позволяет сделать подобные умозаключения, является крайне сложной задачей. Обычно эта проблема учитывается на этапе разработки базы данных с помощью реализации контентно- и контекстно-зависимых правил управления доступом. Контентно-зависимое управление доступом основано на критичности данных. Чем более критичны данные, тем меньше группа лиц, которые могут получить доступ к ним.
Система контекстно-зависимого управления доступом «понимает», какие действия должны быть разрешены, основываясь на состоянии и последовательности запросов. Для этого она отслеживает все предыдущие попытки доступа пользователя, и принимает решение, какая последовательность шагов доступа может быть разрешена. Чтобы лучше понять процесс принятия решения о доступе системой контекстно-зависимого управления доступом, а также различие между системами контекстно- и контентно-зависимого управления доступом, предположим, что Хулио запрашивает доступ к файлу А. Если используется система контентно-зависимого управления доступом, она проверяет список контроля доступа этого файла, видит, что у Хулио есть доступ к этому файлу на чтение, и на основании этого предоставляет ему доступ. При использовании контекстно-зависимого управления доступом сначала также проверяется список контроля доступа файла А, но затем система анализирует дополнительную информацию: какие другие попытки доступа делал Хулио перед этим, удовлетворяет ли последовательность его запросов требованиям к безопасной последовательности запросов, попадает ли время запроса разрешенный интервал (с 8 утра до 5 вечера) и т.п. Если ответы на все эти вопросы положительны, Хулио получает доступ к файлу.
Как вы видите, контентно-зависимое управление доступом существенно проще контекстно-зависимого, поскольку системой выполняется меньшее количество действий.
Обычно для предотвращения атак на основе предположений (inference attack) применяется скрытие ячеек, разделение базы данных, добавление шума и пертурбация. Скрытие ячейки (cell suppression) – это технология сокрытия конкретной ячейки, содержащей информацию, которая может быть использована для проведения атаки на основе предположений. Разделение (partitioning) базы данных на отдельные части значительно затрудняет для неуполномоченных лиц поиск связанных элементов данных, при объединении которых может быть угадана и раскрыта новая информация. Шум (noise) и пертурбация (perturbation) – это способ вставки в базу данных фиктивной информации, чтобы ввести злоумышленника в заблуждение или запутать его, что не позволит провести успешную атаку на основе предположений.
Если для защиты от атак на основе предположений используется контекстно-зависимое управление доступом, программное обеспечение базы данных должно отслеживать, что пользователь запрашивает. К примеру, когда Хулио делает запрос на просмотр поля 1, затем поля 5, а затем поля 20 – система разрешает ему этот доступ. Но когда после этого он запрашивает поле 15, система блокирует эту попытку доступа. Программное обеспечение, реализующее контекстно-зависимое управление доступом, должно быть предварительно запрограммировано (обычно на основе настройки правил), в какой последовательности и какой объем данных разрешается просмотреть Хулио. Если ему будет разрешен просмотр дополнительной информации, он сможет получить достаточно данных, чтобы догадаться о том, что он не должен знать.
Зачастую в процесс планирования и разработки базы данных безопасность не интегрируется. О безопасности вспоминают в самом конце, и для реализации защиты данных разрабатывают доверенный фронтальный интерфейс, позволяющий использовать базу данных. Такой подход ограничивает степень детализации настроек безопасности и функционал защитных механизмов.
При реализации защитных мер часто возникает сложность обеспечения эффективного баланса между безопасностью и функциональностью. В большинстве случаях, чем лучше вы что-то защищаете, тем меньше функциональных возможностей у вас остается. Хотя это позволяет достичь желаемого уровня безопасности, важно не мешать эффективной работе пользователей.
База данных может позволить одной группе или конкретному пользователю видеть определенную информацию, тогда как другой группе доступ к этой информации будет полностью ограничен. Это реализуется с помощью представлений базы данных (database view), показанных на Рисунке 9-9. Если администратор базы данных хочет разрешить руководителям среднего звена видеть показатели по прибылям и убыткам в разрезе их подразделений, но не показывать им данные по прибыли и убыткам всей компании, он может создать представление. Высшему руководству будет дан доступ ко всему представлению, содержащему информацию по прибыли и убыткам всех подразделений и компании в целом, тогда как каждый руководитель подразделения сможет видеть только информацию, относящуюся к его подразделению.
Рисунок 9-9. Представления баз данных являются логическим видом управления доступом
Подобно операционным системам, базы данных также могут использовать дискреционное (DAC) и мандатное (MAC) управление доступом, подробно рассмотренные в Домене 02. Доступ к представлениям может предоставляться на основе членства в группе, прав пользователя или меток безопасности. Если используется дискреционное управление доступом, группы и пользователи получают доступ к представлениям по результатам их идентификации, аутентификации и авторизации. Если внедрена система мандатного управления доступом, группам и пользователям доступ предоставляется на основе их допуска и уровня классификации данных.
Иногда компании не хотят, чтобы пользователи, находящиеся на низком уровне безопасности, имели доступ и изменяли данные на более высоком уровне. Это может реализовываться различными способами. Одним из подходов является отказ в доступе, если пользователь на более низком уровне пытается получить доступ к данным на более высоком уровне. Однако такой подход может давать этому пользователю косвенную информацию о том, что на том уровне, к которому он попытался получить доступ, есть что-то важное.
Другим подходом для реализации такого ограничения является многоэкземплярность (polyinstantiation), которая позволяет хранить в таблице несколько экземпляров записи, имеющих одинаковый первичный ключ, при этом каждому экземпляру будет присвоен свой уровень безопасности. После вставки информации в базу данных, доступ субъектов с низкого уровня должен быть ограничен. Однако вместо того, чтобы просто ограничить доступ, создается другой набор данных, целью которого является обман субъектов с нижнего уровня, которые в случае подобного запроса получат специально подготовленную недостоверную информацию. Например, если военно-морская база осуществляет поставки оружия из штата Делавер на Украину на судне Оклахома, сведения об этом могут быть классифицированы как «совершенно секретные». Только субъекты, имеющие допуск к «совершенно секретной» информации и выше должны иметь возможность ознакомиться с этой информацией. Для организации ограничения, создаются поддельные записи базы данных, в которых указано, что судно Оклахома осуществляет перевозку из Делавера в Африку продуктов питания, и этой информации присвается класс «неклассифицировано», как показано в Таблице 9-1. Поскольку судно Оклахома стоит у берега и на него грузят какие-то контейнеры, всем понятно что оно будет осуществлять некие перевозки, однако люди с более низким уровнем допуска будут думать, что оно поплывет с продуктами в Африку, а не с оружием на Украину. Это также исключит какие-либо домыслы людей с низким уровнем допуска в отношении миссии этого судна. Все будут знать, что судно Оклахома занято, и при планировании своих перевозок будут рассматривать другие суда.
Таблица 9-1. Пример многоэкземплярности, дающий полную, но недостоверную информацию субъектам с низким уровнем допуска
В рассмотренном примере многоэкземплярность была использована для создания двух версий одного и того же объекта, с целью скрытия от субъектов на низком уровне безопасности истинной информации, а также предотвращения их попыток использования и изменения этих данные тем или иным способом. Это способ предоставления альтернативной истории субъектам, не имеющим необходимого уровня допуска, чтобы знать правду. Но это лишь один из примеров применения многоэкземплярности. Напрямую это не связано с безопасностью, однако чаще всего это используется именно в целях обеспечения безопасности критичной информации. В любом случае, если создается копия объекта, которая заполняется измененными данными, т.е. в базе данных хранятся два экземпляра одного и того же объекта, имеющие различные атрибуты, это означает применение многоэкземплярности.
Обработка транзакций в режиме реального времени (OLTP – online transaction processing) обычно используется при кластеризации баз данных для обеспечения отказоустойчивости и высокой производительности. OLTP предоставляет механизмы, которые отслеживают возникновение проблем и надлежащим образом решают их. Например, если в программном процессе происходит сбой, и он прекращает функционирование, механизмы мониторинга OLTP могут обнаружить это и попытаться перезапустить этот процесс. Если перезапустить процесс не удается, производится откат транзакции, для предотвращения повреждения данных или выполнения только части транзакции. Любая выявленная ошибочная или некорректная транзакция должна быть записана в журнал транзакций. В этом журнале также сохраняются сведения об успешно выполненных транзакциях. Информация записывается в журнал до и после выполнения транзакции, создавая таким образом отчет о событиях.
Основной целью использование OLTP является обеспечение того, что транзакция либо выполняется правильно, либо не выполняется совсем. Транзакция обычно является неделимым набором связанных операций. Если не выполнена хотя бы одна операция из этого набора, должен быть произведен откат всей транзакции, что гарантирует сохранение целостности и правильности информации в базе данных.
Набор систем, участвующих в выполнении транзакции, управляется и контролируется программным обеспечением OLTP, которое отслеживает, чтобы все проходило гладко и корректно.
OLTP может, при необходимости, выполнять балансировку нагрузки и распределять входящие запросы по системам, входящим в кластер. Если число запросов к базе данных возрастет и приведет к снижению производительности одной из систем, OLTP может перенаправить некоторые из этих запросов на другие системы. Это гарантирует обработку всех запросов, при этом пользователям не нужно будет долго ждать завершения транзакции.
При использовании нескольких экземпляров базы данных, важно обеспечить наличие в них одинаковой информации. Рассмотрим следующий пример: Кэти идет в банк и снимает со своего счета 65 000 руб. из имеющихся 100 000 руб. База данных А получает запрос на изменение данных и сохраняет новый остаток по ее счету, составляющий 35 000 руб., но база данных Б не обновляется. В ней по-прежнему остается информация об остатке на счете Кэти в размере 100 000 руб. На следующий день Кэти обращается в банк с просьбой предоставить ей информацию об остатке на ее счете, и этот запрос направляется в базу Б, содержащую некорректную информацию, поскольку транзакция не была перенесена в эту базу данных. Чтобы избежать подобной ситуации, OLTP гарантирует, что транзакция не будет завершена до тех пор, пока все базы данных не получат и не сохранят все необходимые изменения.
OLTP записывает транзакции по мере их осуществления (т.е. в режиме реального времени), а в распределенной среде транзакции обычно затрагивают несколько баз данных. Это ведет к сложностям, которые, в свою очередь, могут стать причиной нарушения целостности данных, поэтому программное обеспечение базы данных должно соответствовать требованиям ACID:
- Атомарность (Atomicity). Разделяет транзакции на единицы выполнения и обеспечивает, что никакая транзакция не будет зафиксирована в базе данных частично. Либо изменения фиксируются в полном объеме, либо производится откат базы данных к предыдущему состоянию.
- Согласованность (Consistency). Транзакция должна следовать политике целостности, разработанной в отношении этой конкретной базы данных, и обеспечивать, что все данные в различных базах данных согласованы друг с другом.
- Изоляция (Isolation). Транзакции выполняются изолированно до момента их завершения, без взаимодействия с другими транзакциями. Результаты выполняемых транзакцией изменений недоступны, пока она не будет полностью завершена.
- Надежность (Durability). Только после того, как точность сохранения транзакции проверена во всех системах, она фиксируется, после чего откат базы данных к предыдущему состоянию становится невозможен.
Хранилища данных (data warehousing) объединяют данные из нескольких баз данных или источников данных в большие базы данных, что позволяет осуществлять исчерпывающий поиск данных и их всесторонний анализ. Данные извлекаются из различных баз данных и передаются в централизованное хранилище. При этом производится нормализация данных, т.е. из них удаляется избыточная информация и они преобразуются в необходимый для хранилища формат. Это позволяет пользователям работать только с одной системой, а не отправлять запросы в различные базы данных.
Базы данных, являющиеся источниками данных для хранилища, используются для ведения обычной операционной деятельности. А хранилище данных используется для анализа данных, выполняющегося с целью подготовки прогнозов, необходимых для принятия бизнес-решений, оценки эффективности маркетинга, рыночных тенденций и даже для выявления мошеннической деятельности.
Хранилище данных не является простой зеркальной копией данных, собранных из различных баз данных и сохраненных в одном месте. Хранилище – это база данных, информация в которой прошла предварительную обработку, в ходе которой связанные данные обобщаются и коррелируются. В результате данные представляются пользователю в более удобном, понятном и сокращенном виде.
Централизованное хранение данных обеспечивает более легкий доступ к ним и упрощает управление ими, однако нужно учитывать, что это требует повышенных мер безопасности. Если злоумышленник получил доступ к хранилищу данных, он может получить все данные компании сразу.
Интеллектуальный анализ данных (data mining) – это процесс выявления в данных, содержащихся в хранилище данных, новой, полезной, неизвестной ранее информации. Инструменты интеллектуального анализа данных применяются для поиска связанных данных, проведения корреляции данных с целью создания метаданных. Метаданные могут позволить увидеть ранее неизвестные связи и зависимости между отдельными наборами информации. Они могут помочь при выявлении необычных последовательностей действий, новых шаблонов поведения. В качестве простого примера эффективного применения интеллектуального анализа данных можно рассмотреть пример процесса выявления мошенничества при страховании. Предположим, что в хранилище данных содержится информация о страховых случаях миллионов клиентов различных страховых компаний. Для выявления закономерностей в этой информации применяются средства интеллектуального анализа данных. При этом может быть выявлено, что через несколько месяцев после каждого переезда клиента Джона Смита, он обращался в страховую компанию для получения компенсации в связи со страховым случаем. Так, он переехал в 1967 году и спустя два месяца в его новом доме произошел подозрительный пожар, затем он переехал в 1973 году и через три месяца у него украли мотоцикл, он снова переехал в 1984 году и в через два месяца у него обворовали квартиру. Такие взаимосвязи очень сложно выявить вручную, особенно если клиент пользовался услугами различных страховых компаний, которые просто обновляли свои данные, но не организовывали их централизованное хранение и глубокий анализ.
При интеллектуальном анализе данных выполняется упрощение сложных данных с использованием математических функций, основанных на нечеткой логике (fuzzy logic) и теории множеств (set theory), а также экспертных систем. Именно такие методы позволяют найти незаметные ранее закономерности. Часто происходит так, что ценность полученных таким образом метаданных, значительно превышает ценность самих данных, из которых они были получены, поэтому они должны быть очень хорошо защищены.
Целью создания хранилищ данных и проведения интеллектуального анализа данных является извлечение информации и получение знаний о деятельности компании, происходящих в ней тенденциях, как это показано на Рисунке 9-10. Эти знания могут помочь руководству компаниии выявить недостатки и найти пути для оптимизации деятельности. Например, если наша компания работает в розничной торговле, нам хотелось бы, чтобы клиенты тратили в наших магазинах как можно больше денег. Чтобы улучшить бизнес нашей компании, нам нужно лучше понимать привычки, поведение и психологию клиентов при совершении покупок. Если конфеты и другие мелкие товары поместить на полку рядом с кассой, объем покупки этих товаров возрастает на 65% по сравнению объемом покупки тех же товаров, если они находятся в другом месте магазина. Если один из наших магазинов находится в местности, где проживают более обеспеченные люди, и мы видим, что в этом магазине есть постоянный (или даже растущий) спрос на дорогие вина, мы можем сделать вывод, что это самое подходящее место для продажи дорогих сортов сыра и продуктов для гурманов. Продавать эти продукты в других магазинах, где обслуживаются в основном менее обеспеченные клиенты, большого смысла не имеет.
Рисунок 9-10. Инструменты интеллектуального анализа данных используются для выявления связей между данными в хранилище
ПРИМЕЧАНИЕ. Интеллектуальный анализ данных – это процесс анализа содержимого хранилища данных с помощью инструментов, которые пытаются выявить тенденции, провести корреляцию, найти взаимосвязи и аномалии, не зная смысла данных. Метаданные – это результат обработки данных из хранилища данных с помощью специальных инструментов. На вход хранилища данных поступают данные, а на выходе из него формируются метаданные.Компания должна выполнять эту работу, если она хочет иметь подобные данные для принятия более эффективных решений и получения конкурентных преимуществ. Это не просто агрегирование информации, это позволит руководству лучше понять различные аспекты деятельности компании, выбрать пути для повышения рентабельности бизнеса, повышения продуктивности работы персонала.
Интеллектуальный анализ данных также называют обнаружением знаний в базе данных (KDD – knowledge discovery in database), он представляет собой комбинацию методов, позволяющих выявить реальные и полезные закономерности. Различные типы данных могут иметь различные взаимосвязи, поэтому метод анализа выбирается в зависимости от типа данных и от искомых закономерностей. Ниже приведены три подхода, используемые в системах KDD для выявления этих закономерностей:
- Классификационный (Classification). Выполняется группировка данных, имеющих те или иные сходства.
- Вероятносный (Probabilistic). Выявляет взаимозависимости данных и определяет вероятности их взаимосвязи.
- Статистический (Statistical). Выявляет взаимоотношения между элементами данных и пытается найти закономерности.
Таблица 9-2. Различные типы систем, используемых в зависимости от потребностей
Комментариев нет:
Отправить комментарий