чем опасно избыточное дублирование информации в интеллектуальных системах
Способ решения задачи исключения дублирования персональных данных в информационных системах
Технические науки
Похожие материалы
В процессе функционирования информационной системы возможна ситуация, когда одна и та же информация в базе данных встречается несколько раз, то есть дублируется. Иногда такая избыточность обоснована и реализована искусственно, например, для повышения надёжности. Однако в большинстве случаев дублирование информации недопустимо и приводит к фатальным ошибкам. Также большое количество дубликатов ведёт к нерациональному использованию вычислительных ресурсов. Наиболее остро проблема поиска дублирующихся записей стоит в системах хранения и обработки персональных данных, где возможно частичное совпадение сведений о клиентах [3].
Решить проблему дублирования персональных данных средствами СУБД (системы управления базой данных) не представляется возможным. Все известные методы идентификации объектов в базах данных оперируют точным равенством сравниваемых полей и бессильны при наличии ошибок и пропусков данных [1, 2]. В связи с этим данные нельзя непосредственно сравнивать между собой, а нужно применять более сложные алгоритмы нечёткого сопоставления и поиска по сходству.
Под записью будем понимать совокупность сведений о клиенте (реквизитов), достаточных для функционирования информационной системы. Под субъектом (клиентом) будем понимать физическое или юридическое лицо, сведения о котором хранятся в информационной системе. Термин «дублирование субъектов» будем использовать для описания ситуации, когда один и тот же субъект присутствует в справочнике субъектов два и более раз.
Для разработки и реализации алгоритмов поиска дублирующихся субъектов предлагается:
Здесь вводим понятие «процент совпадения» реквизитов субъектов. Процент совпадения — это процент, которые задается пользователем и определяет, какая точность требуется при сравнении одного реквизита у разных субъектов для того, чтобы полагать эти реквизиты совпадающими (а клиентов, соответственно, дублирующими друг друга). Степень совпадения позволит учесть, что возможны различия (ошибки) в одном и том же реквизите для разных субъектов, например, если оператор при вводе информации о субъекте допустил ошибку.
Разрабатываемые алгоритмы нечеткого сопоставления записей могут применяться в различных системах, где организованы хранение и обработка персональных данных субъектов, для исключения дублирования. Мотивом для разработки послужила необходимость модернизации процедуры проверки справочника субъектов АБС «RS-Bank/Pervasive».
Ключевой частью разрабатываемых алгоритмов будут являться алгоритмы нечёткого сопоставления строк или, иначе говоря, анализа строк. Термин анализ строк (string matching) здесь будем использовать для описания класса задач, связанных с вычислением расстояния между двумя строками, то есть с вычислением метрики. Существуют несколько метрик, основные — это расстояние Хемминга и расстояние Левенштейна. Расстояние Хемминга (Hamming) между двумя строками одинаковой длины определяется как число позиций, в которых символы не совпадают. Если допускается сравнение строк разной длины, то минимальная общая цена преобразования будет равна одной из метрик, предложенных Левенштейном (Levenstein).
Функция Левенштейна играет роль фильтра, заведомо отбрасывающего неприемлемые варианты (у которых значение функции больше некоторой заданной константы).
С точки зрения приложений определение расстояния между словами или текстовыми полями по Левенштейну обладает следующими недостатками:
В настоящее время имеются программные продукты, такие как ispell, aspell, agrep и glimpse, которые позволяют проверять орфографию или определять схожесть двух строк. Однако их использование для решения проблемы дублирования персональных данных практически невозможно.
Одним из наиболее распространенных орфографических алгоритмов нечёткого сопоставления строк является метод динамического программирования Вагнера-Фишера, идея которого состоит в последовательной оценке расстояния между всё более длинными префиксами строк с помощью матрицы весов замен. Затраты времени и памяти можно оцениваются как O(mn), однако, этот метод прост в реализации и эффективен для строк небольшой длины.
Вычислив расстояние Левенштейна, можно найти процент совпадения строк по следующей формуле:
где P — процент совпадения; m — длина наибольшей строки; d — расстояние Левенштейна.
Отсюда видим одно из ограничений данного подхода: для коротких строк различие даже в одном символе будет приводить к низкому проценту совпадения.
Для реализации процедуры проверки субъектов на дублирование будем объединять реквизиты субъектов в группы. При этом в одной группе может быть несколько категорий реквизитов: обязательные (О), условные (У) и информационные (И). Информационные реквизиты не проверяются и необходимы для формирования протокола выполнения процедуры. Условные реквизиты являются дополнительными и проверяются только в том случае, если обязательные реквизиты не заданы или совпали не полностью. Например, задана группа реквизитов (табл. 1).
| Форма | Реквизиты | Уровень | % |
| ЮЛ | (1) Документ: ИНН, рег.номер | О | 100 |
| (2) + Документ: КПП, рег.номер | О | 100 | |
| (3) Документ: ОГРН, рег.номер | У | 90 | |
| (4) Наименование | У | 90 |
Группа может использоваться для проверки при вводе и редактировании субъектов — юридических лиц. Сначала проверяем по «ИНН+КПП» (проверяем вместе, причем по строгому совпадению на 100%), если вдруг они не совпадают (или не заданы), то проверяем по «ОГРН» и «Названию». При этом возможны следующие ситуации.
Для проверки справочника субъектов на дублирование необходимо каждую запись последовательно сравнить со всеми другими записями справочника. При этом одновременно сравниваются только две записи. Поскольку может быть задано несколько групп реквизитов, то проверку выполняем по реквизитам каждой из групп. В случае обнаружения дублёров информация о них выводится в протокол процедуры и фиксируется в справочнике субъектов посредством механизма категорий.
Данный подход позволяет достаточно эффективно отыскивать потенциальных дублёров и поддерживать справочник субъектов в актуальном состоянии. Однако в связи с тем, что размеры сравниваемых реквизитов невелики (в среднем 5-15 символов), временные затраты на анализ строк также получаются достаточно малыми, и здесь на первое место выходит стоимость дисковых операций. На поиск и считывание необходимых сведений о субъекте расходуется времени гораздо больше, чем непосредственно на сравнение. По результатам тестирования для больших справочников субъектов (50000–150000 записей) процедура проверки нуждается в оптимизации, так как время проверки в таких случаях получается неприемлемо большим.
Список литературы
Завершение формирования электронного архива по направлению «Науки о Земле и энергетика»
Создание электронного архива по направлению «Науки о Земле и энергетика»
Электронное периодическое издание зарегистрировано в Федеральной службе по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор), свидетельство о регистрации СМИ — ЭЛ № ФС77-41429 от 23.07.2010 г.
Соучредители СМИ: Долганов А.А., Майоров Е.В.
IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов.
Проектирование баз данных. Информационная избыточность. Избыточность данных в базе данных. Проблемы возникающие из-за информационной избыточности
Здравствуйте, уважаемые посетители моего скромного блога для начинающих вебразработчиков и web мастеров ZametkiNaPolyah.ru. Продолжаем сегодня рубрику Заметки о MySQL, в которой я успел описать установку MySQL сервера, настройку MySQL сервера и файл my.ini, а также поговорил о видах и типах баз данных. Сегодня я хотел бы поговорить об аномалиях в базе данных и проблеме избыточности данных в базе данных, то есть о избыточности информации.
Как и обещал, эта статья и следующая тоже будут посвящены проектированию баз данных, моделированию баз данных или созданию баз данных, как хотите, так и называйте. Данная публикация посвящена проблемам, которые могут возникнуть при проектирование базы данных, точнее одной из проблем.
Попытаюсь рассказать, как обычно на пальцах, что такое информационная избыточность и избыточность данных в базе данных. Также попытаюсь рассказать о проблемах обработки данных, которые могут возникнуть из-за избыточности информации, затрону тему целостности данных в базе данных. Немного затрону тему нормализации базы данных и нормальных форм, нормальные формы – это тема следующей публикации. Какие нормальные формы бывают и как привести базу данных к нормальной форме. Всё это вы найдете в следующей публикации.
Избавиться от избыточности данных, а следовательно и от аномалий баз данных – это вопрос проектирования баз данных. И решать вопрос устранения избыточности в базе данных следует до того, как вы начали ее реализовывать программно, то есть, до того как начали создавать базу данных в той или иной СУБД, в нашем случае СУБД MySQL.
Чтобы избавиться от информационной избыточности, а вместе с тем решить проблему модификации, удаления и добавления данных вам не потребуется каких-либо специальных программ, достаточно будет представлять структуру проектируемого объекта(заметьте, пока еще не структуру базы данных), иметь под рукой несколько чистых листов бумаги, карандаш или ручку. Но, чтобы начать от чего-то избавляться, нужно знать суть самой проблемы, из-за чего эта проблема возникает и так ли она для вас критична.
Из-за избыточности информации в базе данных возникают не только проблемы модификации, добавления и удаления данных из базы данных, но и остро встает вопрос экономии места на диске, согласитесь глупо хранить одну и ту же информацию в разных местах. Избыточность баз данных тесно связана с нормальными формами. Точнее, информационная избыточность – это отрицательный фактор, влияющий на целостность базы данных, вынуждающий нас приводить свои базы данных к нормальной форме.
Данная публикации как раз и предназначена для тех, кто хочет быстро разобраться с тем, что такое информационная избыточность и избыточность данных в базе данных, а так же тем, кто хочет разобраться с вопросом, как избавиться от избыточности данных.
Информационная избыточность. Избыточность базы данных. Что такое избыточность.
Начнем мы с информационной избыточности и избыточности реляционных баз данных в частности. Поскольку, эта самая избыточность и заставляет нас нормализовывать базы данных.
Для начала напишу умное определение избыточности, а затем постараюсь объяснить его по-русски.
Информационная избыточность – термин из теории информации, означающий превышение количества информации, используемой для передачи или хранения сообщения, над его информационной энтропией.
Давайте начнем разбираться с определением избыточности и начнем с термина информационная энтропия.
Информационная энтропия – это мера неопределенности информации, неопределенность появления какого-либо символа. Данное определение появилось в теории электросвязи. Для администратора баз данных информационную энтропию следует интерпретировать немного по-другому: информационная энтропия всё также мера неопределенности информации, но, какая информационная неопределенность может возникнуть в базе данных?
Например, у нас есть база данных, в которой хранится библиотека и есть писатель Иванов И.И., сколько книг написал Иванов И.И.? Бог его знает. Может одну, а может и сто. И сколько раз появится этот Иванов И.И. в нашей таблице, мы не знаем. Такая вот неопределенность информации.
Любая база данных предназначена для хранения информации. И при проектирование базы данных следует учесть то, что какая-то информация может повторяться несколько раз. А каждая повторяющаяся запись – это занятое место на диске. То есть превышение количества информации необходимого для хранения данных.
Конечно, можно сказать, что сейчас, с появлением терабайтных накопителей отпала необходимость экономить место на диске. Но информационная избыточность ведет не только к увеличению требуемого объема памяти для хранения информации содержащейся в базе данных.
Избыточность данных в базе данных – это нежелательное явление еще и потому, что при работе с таблицами базы данных (которые еще называют отношениями), содержащими избыточные данные возникают проблемы связанные с обработкой информации, эти проблемы называются аномалии. Про аномалии баз данных читайте в следующем разделе.
Последствия информационной избыточности в базе данных. Избыточность данных. Аномалии (проблемы) в базе данных.
Как мы уже выяснили, избыточность информации ведет не только к тому, что требуется увеличение объема накопителей, но и приводит к аномалиям в базе данных.
Аномалии в базе данных – это проблемы связанные с обработкой информации, а точнее с удаление данных из базы данных, с модификацией данных в таблице базы данных и аномалия добавления данных в базу данных.
Как вы поняли, в базе данных есть три аномалии:
Все эти проблемы связаны с целостностью баз данных, а именно с избыточностью данных в базе данных. Давайте остановимся подробней на каждой аномалии.
Давайте посмотрим на примере приближенном к реальности, что такое избыточность данных. Допустим, у нас есть таблица, в которой хранятся данные список преподавателей и список предметов, которые они ведут. Естественно, в это таблице присутствует информационная избыточность.
Таблица с информационной избыточностью
Избыточность данных в этой таблице заключается в том, что любой преподаватель может вести несколько предметов, как преподаватель Иванов и для каждого нового предмета приходится добавлять новые записи в таблицу.
Один преподаватель может вести разные предметы, а разные предметы могут вести разные преподаватели. Давайте посмотрим, какие аномалии могут произойти в данном конкретном случае и как можно избавиться от аномалий в конкретном случае.
Аномалия включения. Проблема добавления данных в базу данных.
Избыточность данных очевидна, поскольку произошло дублирование информации, преподаватель Иванов ведет два предмета и его пришлось вписать дважды в таблицу. Но это еще не всё. Допустим, в нашей школе появился новый предмет и мы хотим его добавить в существующую таблицу базы данных, но мы еще не нашли преподавателя для этого предмета. А вписать в таблицу предмет нужно уже сейчас.
В этом случае мы должны присвоить значение NULL каждому атрибуту преподавателя, но делать это никак нельзя, так как атрибут «Код преподавателя» является первичным ключом отношения (первичным ключом таблицы). Результатом попытки создания такой записи будет нарушение целостности данных базы данных, а любая СУБД, в том числе и СУБД MySQL отклонит подобную попытку создания такой записи.
Все вышеописанное является аномалией включения. Чтобы избавиться от аномалии включения нужно разбить таблицу на две: таблица преподавателей и таблица предметов. Примерно это будет выглядеть так:
Избавляемся от избыточности данных в базе данных.
Здесь мы разделили общую таблицу, тем самым избавились от аномалии включения и от возникшей информационной избыточности, то есть от дублирования в базе данных. В принципе то, что мы сделали в данный момент – привели базу данных ко второй нормальной форме.
Вторая нормальная форма позволяет нам избавиться от аномалии включения, а также от дублирования информации в базе данных, то есть мы избавляемся от избыточности информации.
Аномалия модификации. Проблема изменения базы данных.
Следующая проблема, которая может возникнуть из-за избыточности базы данных – это проблема внесения изменений в таблицы базы данных или как ее еще называют – аномалия модификации.
В нашем примере проблема модификации могла бы возникнуть при попытке изменения фамилий преподавателей, например, если бы в этом списке была незамужняя женщина с фамилией Сидорова, то возможно, когда-нибудь она вышла бы замуж и поменяла фамилию, а оператору пришлось бы для каждой записи, в которой имелась фамилия Сидорова заменить на новую фамилию. Это довольно нудная работа. Каждая такая запись или строка таблицы базы данных называется кортежем.
Чтобы избавиться от аномалии модификаций и все связанные с ней проблемы мы можем прибегнуть к предыдущему способу, просто разбиваем одну большую таблицу на две маленьких. То есть, приводим базу данных ко второй нормальной форме или просто нормализуем.
И опять же, таким образом мы избавляемся от дублирования данных в базе данных. Все довольно просто.
Аномалия удаления. Проблема удаления данных из базы данных.
Проблема удаления данных из базы данных – это еще одна проблема, которая появляется, если данные в базе избыточны ее еще называют аномалия удаления. Проблема удаления данных из базы данных заключается в том, что при удаление одной записи или кортежа из таблицы, относящейся к какому-либо из преподавателю, вместе с записью о преподавателе, из базы данных удалится вся информация о предмете, который вел этот преподаватель.
Решается проблема удаления данных из базы данных очень просто, нормализуем базу данных до второй нормальной формы, то есть разделяем таблицу на две, как это показано в разделе посвященном аномалии включения.
Обратите внимание: типы данных у различных СУБД могут быть разными, у MySQL типы данных одни, у какой-либо другой СУБД могут быть другие типы данных, как и у языков программирования. У JavaScript типы данных одни, а у PHP типы данных другие.
Угрозы информационной безопасности в эпоху цифровой трансформации
Введение
Цифровая трансформация (ЦТ) — это прежде всего инновационный процесс, требующий внесения коренных изменений в промышленные технологии, социум и культуру, финансовые транзакции и принципы создания новых продуктов и услуг. Фактически, это не просто набор подлежащих развертыванию ИТ-продуктов и решений в компаниях и на производстве, а глобальный пересмотр подходов и стратегий в бизнесе, выполняемый с помощью информационных технологий. Цифровая трансформация является переходным периодом к шестому технологическому укладу в ходе четвертой промышленной революции (Industry 4.0).
Рис 1. Цифровая трансформация — переход к 6-му технологическому укладу
Не все компании готовы к новым и достаточно жестким требованиям, которые им предъявляет ЦТ, а именно, к полной модернизации методов ведения бизнеса, пересмотру внутренних бизнес-процессов и новой культуре взаимоотношений внутри компании. Мало того, менеджмент должен быть подготовлен, как к позитивным, так и к негативным последствиям цифровой трансформации.
Цифровая трансформация — это не просто автоматизация и цифровизация отдельных производственных процессов «на местах», это интеграция обычных офисных и промышленных технологий, которые мы используем ежедневно, с совершенно новыми ИТ-направлениями, специфичными для ЦТ, (облачные вычисления, искусственный интеллект и машинное обучение, IoT и т.д.).
Негативные последствия цифровой трансформации
Однако у процессов, которые вызывает цифровая трансформация, есть и негативная сторона. Революционные изменения, которые привносит в бизнес ЦТ, породили определенные проблемы для служб информационной безопасности (ИБ), а именно, возникли новые вектора угроз ИБ и расширился спектр уязвимостей для потенциальных кибератак.
«Модная технология» DevOps является предметом особой настороженности специалистов ИБ, так как она принципиально изменила взаимоотношения между разработчиками софта, системными администраторами, службами тех. поддержки и конечными пользователями. (Методология DevOps означает интеграцию деятельности разработчиков и специалистов по обслуживанию ПО, сетей и оборудования в командах и компаниях).
Рис 2. Что такое DevOps
Также хочется отметить, что одним из серьезных препятствий для быстрого внедрения ЦТ в компаниях являются старые (унаследованные) технологии, которые обслуживают производственные и офисные процессы уже много лет. С одной стороны, их невозможно заменить быстро (без остановки бизнес-процессов), а с другой стороны они плохо вписываются в процессы цифровой трансформации и несут в себе множественные угрозы ИБ.
Ниже остановимся на основных проблемах ИБ, а также обозначим пути разрешения этих проблем в ходе ЦТ.
Проблемы информационной безопасности в условиях ЦТ
1. Непрозрачность событий ИБ в корпоративной инфраструктуре предприятий
В крупных компаниях повсеместно используются различные технологические локации, развернутые в облачных сервисах, причем оснащенные собственными инструментами ИБ и разными внутренними сервисами. Однако, пока еще есть проблемы, как с интеграцией таких решений, так и с прозрачностью и фиксацией всех инцидентов и событий ИБ в такой сложной ИТ-инфраструктуре. Мало того, цифровая трансформация предполагает значительный рост, как облачных решений, так и усложнение корпоративной инфраструктуры за счет внедрения IoT, блокчейна, ИИ и т.д.
2.Трудности с вопросом автоматизации всех процессов ИБ
В обычной средней или даже крупной компании многие процессы информационной безопасности остаются неавтоматизированными, при этом не выработан даже общий подход к их автоматизации. Однако у сотрудников департаментов ИБ таких компаний есть уверенность в том, что защита работает по всем возможным векторам атак, как внутри периметра, так и в облаках, на мобильных устройствах, веб-серверах и т. д. Возможно, отдельные решения ИБ (антивирусы, межсетевые экраны, системы обнаружения вторжений и т.д.) пока еще обеспечивают определенный уровень безопасности на отдельных участках и снижают количество инцидентов ИБ, но без выработки общей стратегии и политики безопасности в такой организации обязательно будут проблемы с ИБ в будущем, в ходе внедрения ЦТ.
Хочется отметить, что в большинстве организаций до сих пор плохо с интеграцией различных ИБ-решений, нет сквозной видимости всех угроз, плохо с контролем соответствия требованиям регуляторов (compliance).
По результатам опросов и исследований в области информационной безопасности экспертами выяснено, что на многих предприятиях, четверть корпоративной инфраструктуры так и остаётся незащищенной. По мере роста ИТ-инфраструктуры, вызванного цифровой трансформацией, а также в связи с усложнением кибератак, появляется потребность в масштабируемости ИБ-решений. И даже если в компании есть эффективно работающие решения, защищающие отдельные компоненты инфраструктуры ИТ (например, антивирусы, межсетевые экраны и т.д.), то в целом это не повышает общий уровень безопасности в организации, по причине плохой интеграции и масштабируемости этих отдельных решений.
На данный момент наибольшую проблему у специалистов по кибербезопасности вызывают сложные для блокировки полиморфные кибератаки, целевые кибератаки (APT, advanced persistent threat, «развитая устойчивая угроза»), а также рост использования методологии DevOps, которая повышает риски несвоевременного обнаружения новых уязвимостей.
Рис 3. Фазы целевой кибератаки (APT, advanced persistent threat).
5.Последствия обновлений ПО
До сих пор остаются опасными угрозы, связанные с обновлением софта, так как зачастую вместе с «патчами» и «апдейтами» может быть инсталлировано и вредоносное ПО.
Стратегия обеспечения безопасности в условиях ЦТ или меры противодействия угрозам
В будущем, ЦТ может быть использована как для позитивных изменений в социуме, так и для реализации угрозы для мировой стабильности и безопасности. Таким негативным примером является, так называемое, «кибероружие». Для того, чтобы в условиях постоянно нарастающей нестабильности, обозначить стратегию безопасности своего бизнеса и систем государственного управления, необходимо уяснить для себя в целом, что такое «безопасность» и какая она бывает.
Таким образом, само понятие «безопасность» подразделяется на 3 большие группы: личную, общественную и государственную.
Личная безопасность — это такое состояние, когда человек защищён от любого вида насилия (например, психологического, физического или др.)
Общественная безопасность — способность социальных институтов государства защитить личность и общество от различного вида угроз (в основном, внутренних).
Государственная безопасность — система защиты государства от внешних и внутренних угроз.
Еще одним важным направлением в области безопасности, является информационная безопасность и защита информации. Цель работы специалистов по защите информации — это обеспечение её конфиденциальности, доступности и целостности. В общем, эти три ключевых принципа ИБ называют триадой CIA, ниже раскроем смысл этих понятий.
Основная цель информационной безопасности в контексте ЦТ — это обеспечить защищенность как информации, так и ИТ-инфраструктуры от случайных или преднамеренных воздействий (атак и т.д.), которые могут нанести неприемлемый ущерб владельцам информационных активов.
Особое внимание необходимо уделить инцидентам ИБ на объектах критической информационной инфраструктуры (КИИ), это могут быть, как таргетированные атаки (APT), так и техногенные катастрофы, физическое похищение активов и др. угрозы. По мере усложнения атак наращиваются и «средства обороны» (т.е. инфраструктура ИБ).
На этом фоне все большую популярность набирают системы SIEM (Security information and event management), основная задача которых — это мониторинг корпоративных систем и анализ событий безопасности в режиме реального времени, в том числе с широким использованием систем ИИ и глубокого машинного обучения (Deep learning).
Крупные технологические компании, которые лидируют в области ЦТ, намного чаще других интегрируют свои продукты и средства ИБ в единую архитектуру корпоративной безопасности. Надо отметить, что в таких компаниях отдают предпочтению стратегическому подходу и формированию политики безопасности, что позволяет:
Рис 5. Внедрение SOC (Security Operations Center) в компании
Одной из особенностей ИБ в эпоху цифровой трансформации является процесс внедрения в корпоративную систему средств централизованного контроля соответствия как промышленным стандартам, так и стандартам ИТ и ИБ, что повышает эффективность работы такого направления ИБ, как compliance.
Заключение
Одним из серьезных препятствий на пути компаний к ЦТ является необходимость обеспечения высокого уровня информационной безопасности, что не всегда посильно большинству компаний, особенно фирмам из сектора SMB. При этом необходимо учитывать факторы нарастания, как внутренних, так и внешних угроз ИБ, связанные со значительным ростом сектора киберпреступности, а также рисками, возникающими естественным путем в ходе реализации методологии DevOps, облачных технологий, IoT и т.д.
Один из достаточно новых, но эффективных подходов в области обеспечения безопасности информационных активов — это применение методов проактивной защиты, способных не просто защитить, но и предотвратить кибератаки. Здесь хочется отметить такие технологии, как «ханипоты» (honeypots и honeynets), а также более продвинутые системы по развертыванию распределенной инфраструктуры ложных целей (Distributed Deception Platform, DDP).
В итоге, можно выделить лучшие практики ИБ, которые мы можем порекомендовать компаниям и бизнесу в ходе процесса цифровой трансформации:
Рис 6. Стратегический подход к ИБ — разработка политики безопасности компании