WWW.DISS.SELUK.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА
(Авторефераты, диссертации, методички, учебные программы, монографии)

 

Pages:     || 2 | 3 | 4 |

«Оглавление Оглавление Введение Глава1. Методы исследования моделей и алгоритмов представления структур данных для предметных областей с ранжируемыми атрибутами 1.1. Тенденции развития методологии проектирования ...»

-- [ Страница 1 ] --

Оглавление

Оглавление

Введение

Глава1. Методы исследования моделей и алгоритмов представления структур

данных для предметных областей с ранжируемыми атрибутами

1.1. Тенденции развития методологии проектирования информационных

структур хранения данных

1.2. Обзор исследований в области реинжиниринга

1.3. Проектирование схем РБД

1.4. Методика проектирования схем РБД на основе анализа актуальных структур хранения и данных

1.5. Основные результаты

Глава 2. Методы и алгоритмы извлечения из актуальных данных структурных закономерностей в даталогии предметной области

2.2 Разработка алгоритмов ключевых этапов реинжиниринга

2.3 Поиск идентичных атрибутов

2.4 Алгоритмы объединения и корректировки схем различных БД

2.5 Разработка алгоритмов определения семантических зависимостей............ 2.6 Реинжиниринг при мандатной модели доступа

2.7 Реинжиниринг при дискреционной модели доступа

2.8 Основные результаты

Глава 3. Верификация и сравнительный анализ информационных структур хранения данны, полученных в результате экспертного анализа и извлечения информации из актуальных данных

3.1. Проблема эквивалентности схем баз данных

3.2. Нормализация

3.3. Алгоритм проверки на эквивалентность по данным схем РБД

3.4. Исследование алгоритма

3.5. Проверка структуры базы данных на правильность логического построения с использованием табло

3.6. Алгоритм поиска ошибок и избыточности в структуре баз данных........... 3.7. Построение схемы реляционной БД

3.8. Выводы

Глава 4. Разработка алгоритмов построения схем РБД с ранжируемыми атрибутами

4.1 Разработка алгоритмов построения схем РБД с учетом ранжируемых атрибутов, основанных на нормализации отношений

4.2 Разработка алгоритмов построения схем РБД, основанных на синтезе отношений

4.3 Основные результаты

Глава 5. Модификация структур хранения данных для обеспечения дополнительной защиты данных на структурном уровне

5.1 Разграничение пользовательского доступа к отдельным кортежам............. 5.2 Проблема дублирования ключей в различных отношениях

5.3 Разграничение предоставления доступа при кластеризационной модели

5.4 Разграничение предоставления доступа при мандатной модели

5.5 Использование дискреционно-ролевой модели для реализации доступа... 5.6 Организация разграничения с использованием функциональной модели

5.7 Маскировка данных

5.8 Организация хранения информации при маскировании данных

5.9 Метод реализации маскирования при мандатной модели доступа

5.10 Маскирование данных при функциональном доступе

5.11 Синхронизация маскируемых и маскирующих данных

5.12 Основные результаты

Глава 6. Практическая реализации результатов работы и экспериментальное исследавание разработанных алгоритмов

6.1 Специализированный программный инструментарий для проведения экспериментальных исследований

6.2 Экспериментальные исследования разработанных алгоритмов

6.3 Сбор и обработка данных экспериментов

6.4 Примеры использования полученных результатов для практических нужд

6.5 Основные результаты

Заключение

Список литературы

Приложение

Введение Актуальность темы. Проектирование схем реляционных баз данных является одним из наиболее важных и ответственных этапов в процессе разработки информационных систем, систем автоматизированного управления и других компьютерных систем, информационная поддержка которых основана на использовании баз данных. В основе проектирования баз данных лежит требование адекватности базы данных предметной области. Адекватность предполагает, что модель данных без искажений передает взаимосвязи информации в той части реального мира, которая подлежит информатизации. Причем совершенно ясно, что речь может идти только об определенном подмножестве как информации, так и информационных связей, которые необходимы для решения поставленной задачи. Здесь можно говорить о том, что отступление от требования адекватности грозит тем, что попытки записать реальную информацию в базу данных, неверно интерпретирующую реальные семантические взаимосвязи между данными, приводят к нарушению правильности хранения, обработки и интерпретации данных.

Наиболее силиьно эти принципы проявляются при перепроектировании существующих информационных систем, а так же при переходе на новые СУБД и объединении разрозненных баз данных.

Ошибки, допущенные при этом этапе, отличаются следующими особенностями: их достаточно легко допустить, их можно не заметить на начальном этапе, они не очевидны, они не препятствуют процессу разработки программного обеспечения.

Однако они рано или поздно себя проявляют на этапе эксплуатации уже разработанной системы. При этом требуются значительно большие усилия для их ликвидации, поскольку неверная схема реляционной базы данных уже послужила основой для накопления в системе информации и отражена в алгоритмах и реализующих их программах накопления, обработки и хранения информации. Разработчикам приходится принимать решение — либо проводить проектирование заново, практически перечеркнув почти всю проделанную работу, либо за счет разработки дополнительных обработчиков пытаться нивелировать эту проблему.



Первый вариант требует больших материальных и людских ресурсов, которые часто разработчику просто недоступны, поскольку они уже были израсходованы на проект. С другой стороны, это оказывает отрицательное влияние на престиж разработчика, что также сулит в будущем материальные потери. По этим соображениям разработчики крайне неохотно идут на использование первого варианта.

Второй вариант кажется разработчику наиболее приемлемым, поскольку не влечет больших одноразовых затрат, зато потом придется постоянно затрачивать значительные усилия на поддержку системы в работоспособном состоянии, что будет требовать постоянных отвлечений материальных, финансовых и человеческих ресурсов. Дополнительным негативным результатом следования по этому пути будет снижение технических характеристик системы по сравнению с ее конкурентами на рынке программного обеспечения.

Таким образом, очевидно, что любое улучшение качества проектирования схемы реляционной базы данных, под которым мы понимаем ее адекватность семантике предметной области информационной системы, невозможно без решения следующих проблем: восстановления зависимостей, на основе которых осуществляется переход от инфологичиской модели предметной области к даталогической модели базы данных; снятия проблемы консолидации актуальных данных и добавления новых при обеспечении возможности автоматизации данных процессов на основе объединения структур данных; учета процедур разграничения доступа к данным на этапе проектирования логической модели данных.

К сожалению современные СУБД и CASE-системы не позволяют решать эти проблемы полностью, а могут быть полезны только при решении частных задач.

Актуальность работы вызвана необходимостью снижения времени разработки информационных структур, увеличения их верности и безопасности путем создания методологии разработки информационных структур хранения, позволяющей достигнуть этого за счет использования информации о предметной области посредством извлечения закономерностей из существующих данных, структура которых содержит информацию о семантике предметной области, формального сравнения полученных моделей с результатами системного анализа предметной области с последующим выявлением ошибок моделирования и учета аспектов, связанных с безопасностью информации.

Степень разработанности темы. Разработке подходов и алгоритмов построения схем РБД, а также всем аспектам данных процессов посвящено достаточно большое количество трудов. Основные теоретические положения данного направления были заложены в 70-80-е годы 20-го века. Наиболее известными авторами данной тематики являются Э. Кодд, К. Дейт, Д. Мейер, Х. Дарвен, Д. Ульман, Д. Уидом, А. Ахо, И. Хит, Р. Фейгин, Ф. Бернштейн, Ж. Риссанен, М. Стоунбрейкер и другие.

Из отечественных авторов можно выделить Брешенкова А.В.,Кузнецова С.Д., Пушникова А.Ю, Грушо А.А., Новосельского В.Б.

В работах Брешенкова А.В. предлагается методика проектирования реляционных баз данных для данных табличного вида. В работе Грушо А.А. приведен метод декомпозиции отношений БД в стандартные базовые отношения реляционной модели с использованием классификационных ограничений. В работах Новосельского В.Б. рассматривается генетический подход к проектированию распределённых БД.

В работах Ф. Бернштейна предложен алгоритм синтеза схем РБД. В работах Д. Мейера решаются недостатки алгоритма синтеза, касающиеся необходимости наличия отношения в результирующей схеме РБД R, содержащего универсальный ключ отношений, а также учета атрибутов, не использующихся в семантических зависимостях UiU предметной области. В работах И. Хита и Р. Фейгина рассмотрены вопросы, связанные с декомпозицией отношений без потерь информации. Ж. Риссанен в своих трудах рассматривает проблемы, связанные с потерей зависимостей при декомпозиции без потерь отношений Rk, и предлагает вариант решения данной задачи. К. Дейт на основе результатов Риссанена приводит методику декомпозиции отношений на независимые проекции.

Под методологией проектирования схем РБД будем понимать совокупность концепций, методов и приемов, основанных на математическом аппарате реляционной алгебры, направленных на получение качественной схемы РБД.

Под методологией применения будем понимать совокупность концепций, методов и приемов, основанных на математическом аппарате реляционной алгебры, направленных на получение практического эффекта.

Целью диссертационной работы является снижение времени разработки информационных структур, увеличение их верности и безопасности путем создание теоретической и методологической основы для разработки информационных структур хранения, методов и алгоритмов извлечения закономерностей из данных предметных областей с учетом дополнительных ограничений на доступ к информационным ресурсам пользователей различного уровня.

Основными задачами диссертационной работы являются:

1. Проведение анализа и классификация используемых в настоящее время методов и алгоритмов разработки информационных структур хранения данных.

2. Создание методики восстановления по актуальным данным инфологических закономерностей предметной области в виде функциональных зависимостей, многозначных зависимостей и зависимостей соединения на основе эвристических алгоритмов анализа актуальных данных, обеспечивающей процесс корректного и эффективного (по времени) перепроектирования информационных систем.

3. Разработка методики объединения структур данных, созданных независимо по различным методикам для представления различных фрагментов одной и той же предметной области, способствующих уменьшению количества ошибок в процессе перепроектирования баз данных.

4. Разработка методов модернизации структур хранения данных, учитывающих ранжируемость данных, и эвристических методов генерации правдоподобных данных, подлежащих маскированию, для усиления механизмов защиты информации.

5. Разработка методов и алгоритмов верификации даталогической модели хранимых актуальных данных для оценки её соответствия инфологическим закономерностям предметной области.

6. Разработка эвристических методов генерации реляционных баз данных с заданными инфологическими закономерностями, предназначенных для исследования эффективности алгоритмов распознавания этих закономерностей.

7. Разработка методов и алгоритмов сравнительного анализа даталогических моделей данных, полученных на основе экспертного анализа предметной области и математических моделей закономерностей, извлеченных из существующих актуальных баз данных, для исключения ошибок в этих моделях.

Научная новизна. В диссертации разработана новая теоретическая и методологическая база для построения информационных структур хранения данных, отличающаяся использованием созданных автором оригинальных методов и методик:

• восстановления инфологических закономерностей – функциональных зависимостей, многозначных зависимостей и зависимостей соединения – по актуальным данным предметной области;

• объединения структур данных, созданных по различным методикам;

• генерации дополнительных атрибутов и/или записей данных, предназначенных для использования стандартными механизмами разграничения доступа на основе кластеризационной, мандатной, функциональной и дискреционно-ролевой моделей;

• генерации модельных баз данных с заданными инфологическими закономерностями, предназначенных для проверки способности предложенных алгоритмов выявлять имеющиеся в данных инфологические закономерности.

Результаты работы создают теоретическую и методологическую базу для построения информационных структур хранения данных на основе математических моделей, отражающих существующие структуры данных предметных областей с учетом их дополнительных свойств. Решение указанной проблемы имеет важное значение для вычислительной техники, систем баз данных, реляционной алгебры и других смежных областей.

На защиту выносятся следующие новые результаты:

1. Результаты анализа и классификация используемых в настоящее время методов и алгоритмов разработки информационных структур хранения данных, показывающие, что используемые в настоящее время системы автоматизации проектирования баз данных не поддерживают процессы восстановления инфологических зависимостей предметных областей в виде функциональных, многозначных зависимостей и зависимостей соединения.

2. Методика восстановления по актуальным данным инфологических закономерностей предметной области в виде функциональных зависимостей, многозначных зависимостей и зависимостей соединения на основе эвристических алгоритмов анализа актуальных данных, обеспечивающей процесс корректного и эффективного (по времени) перепроектирования информационных систем.

3. Методика объединения структур данных, созданных независимо по различным методикам для представления различных фрагментов одной и той же предметной области, способствующих уменьшению количества ошибок в процессе перепроектирования баз данных.

4. Методы модернизации структур хранения данных, учитывающие ранжируемость данных и эвристические методы генерации правдоподобных данных, подлежащих маскированию, которые позволили усилить механизмы защиты информации на уровне структуры хранения данных.

5. Методы и алгоритмов верификации даталогической модели хранимых актуальных данных для оценки её соответствия инфологическим закономерностям предметной области.

6. Эвристические методы генерации реляционных баз данных с заданными инфологическими закономерностями, предназначенных для исследования эффективности алгоритмов распознавания этих закономерностей.

7. Методы и алгоритмы сравнительного анализа даталогических моделей данных, полученных на основе экспертного анализа предметной области и математических моделей закономерностей, извлеченных из существующих актуальных баз данных, для исключения ошибок в этих моделях.

Теоретическая и практическая значимость результатов. Теоретическая значимость работы заключается в разработке теоретической и методологической базы для создания эффективных алгоритмов проектирования схем реляционных баз данных.

Практическая значимость работы заключается в реализации методов и алгоритмов проектирования схем реляционных баз данных для создания адекватных баз данных в более короткие сроки и имеющих дополнительные структурные средства для защиты данных.

Диссертация выполнена в Рязанском государственном радиотехническом университете на кафедре электронных вычислительных машин. Теоретические и практические результаты работы были использованы при реализации 3 научно-исследовательских и опытно-конструкторских работ, проводимых в Рязанском государственном радиотехническом университете:

НИР 4-11Г «Разработка методов и информационных технологий мониторинга потенциально-опасных объектов и ландшафтных образований», НИР 10-12Г «Разработка методов и информационных технологий обработки многоспектральных изображений для мониторинга ландшафтных образований», НИР 36-09 «Информационная система предупреждения и прогнозирования развития чрезвычайных ситуаций на техногенных комплексах хранения горюче-смазочных материалов», выполненной по Государственному контракту №П2390 от 18.11.2009 г. в рамках Федеральной целевой программы «Научные и научно-педагогические кадры инновационной России» на 2009-2013 гг., реализация мероприятия № 1.2.2 «Проведение научных исследований под руководством кандидатов наук», руководитель проекта Б.В. Костров.

Результаты диссертационной работы внедрены: в ОАО «Алеатис» (партнер копорации Dell, занимающийся профессиональной разработкой программного и информационного обеспечения для правительственных и частных организаций и компаний), ООО «ЭПАМ Системз», ОАО «Системный оператор единой энергетической системы», филиал РДУ энергосистемы Рязанской области, ООО «РУСОФТ-РИТЕЙЛ», Государственном бюджетном учреждении здравоохранения города Москвы "Городская поликлиника №166 департамента здравоохранения города Москвы".

Теоретические и практические результаты работы используются в учебном процессе Рязанского государственного радиотехнического университета при проведении занятий со студентами направления 010500 «Математическое обеспечение и администрирование информационных систем», направления 230100 «Информатика и вычислительная техника» в курсах «Теория проектирования реляционных баз данных», «Администрирование баз данных», «Базы данных» и в виде программного комплекса «SynthesisFR» (Свидетельство о государственной регистрации программы для ЭВМ №2012614219).

Соответствие паспорту специальности. Содержание диссертации соответствует п.2 «Исследование информационных структур, разработка и анализ моделей информационных процессов и структур» и п.5 «Разработка и исследование моделей и алгоритмов анализа данных, обнаружения закономерностей в данных и их извлечениях, разработка и исследование методов и алгоритмов анализа текста, устной речи и изображений» паспорта специальности 05.13.17 – Теоретические основы информатики.

Апробация работы. Основные результаты диссертационной работы докладывались и обсуждались:

- на МНТС «Проблемы передачи и обработки информации в информационно-вычислительных сетях» (Москва, 1997, 1 доклад).

- МНТК «К.Э. Циолковский - 140 лет со дня рождения. Космонавтика. Радиоэлектроника. Геоинформатика» (Рязань, 1997, 1 доклад).

2-й МНТК «Космонавтика. Радиоэлектроника. Геоинформатика» (Рязань, - МНТК «Системные проблемы качества, математического моделирования и информационных технологий» (Ковров: КГТА, 1999, 1 доклад).

МНТС «Проблемы передачи и обработки информации в сетях и системах телекоммуникаций» (Москва, 1999, 2 доклада).

- ВНТК «Новые информационные технологии в научных исследованиях и образовании» (г. Рязань, 2008, 1 доклад).

- 15-й международной научно-технической конференции «Проблемы передачи и обработки информации в сетях и системах телекоммуникаций» (Рязань, 2008, доклад).

- 34-й всероссийской научно-технической конференции «Информационные и телекоммуникационные технологии» (Рязань, 2009, 1 доклад).

- 15-й НТК «Новые информационные технологии в научных исследованиях и образовании» (Рязань, 2010, 1 доклад).

- II международной научно-технической конференции "Технологии разработки информационных систем ТРИС-2011" (Таганрог, 2011, 1 доклад).

- Всероссийской научно-технической конференции с международным участием «Компьютерные и информационные технологии в науке, инженерии и управлении» (КомТех- 2011) (Таганрог, ТТИ ЮФУ, 2011, 1 доклад).

- VII МНПК «Перспективы развития информационных технологий» (Новосибирск, 2012, 1 доклад).

Публикации. Автором опубликовано 67 научных (в том числе две монографии и 4 авторские свидетельства) и 14 учебно-методических печатных работ, из них работ при подготовке данной диссертации, в том числе 2 монографии, 14 статей в журналах, рекомендованных ВАК, и 12 тезисов докладов на международных и всероссийских научных конференциях, получено свидетельство о регистрации электронного ресурса программы для ЭВМ «SynthesisFR» №2012614219 в Федеральной службе по интеллектуальной собственности, патентам и товарным маркам. Зарегистрировано в Реестре программ для ЭВМ 12 мая 2012 г.

Структура и объем работы. Диссертация состоит из введения, шести глав, заключения, списка использованной литературы из 261 наименованиz и приложения.

Изложена на 389 страницах основного текста, содержит 77 таблиц и 62 рисунка.

Глава1. Методы исследования моделей и алгоритмов представления структур данных для предметных областей с ранжируемыми атрибутами 1.1. Тенденции развития методологии проектирования информационных структур хранения данных Сегодня в мире существует большое количество подходов, методов и технологических решений, напрямую или косвенно соотносимых с деятельностью по реинжинирингу информационных систем (ИС). Однако они не интегрированы на уровне методологий (процессов разработки). Как результат, можно наблюдать наличие огромного количества методологий, где основной акцент сделан на разработку ИС «с нуля», и практическое отсутствие «стройных» методологий, целью создания которых являлось бы комплексное, целостное решение задач реинжиниринга ИС. [5, 128, 110, 130, 133, 140, 142, 149, 155, 156, 178, 181, 183-186, 195-205, 211, 215, 216, 218, 237, 244, 245] По сути, сегодня можно говорить, что эра, когда разработчики ИС приходили в организацию и начинали проекты информатизации «с нуля», прошла. Наступает время проектов по систематической трансформации существующих ИС или эра реинжиниринга ИС.

Методология создания информационных систем заключается в организации процесса построения ИС и обеспечении управления этим процессом для того, чтобы гарантировать выполнение требований как к самой ИС, так и к характеристикам процесса разработки. Основными задачами, решение которых должна обеспечивать методология создания и модернизации ИС (вместе с соответствующим набором инструментальных средств) являются следующие задачи: [140] • обеспечивать создание и модернизацию ИС, отвечающих предъявляемым к ним требованиям по автоматизации процессов и отвечающих целям и задачам организации;

• гарантировать создание системы с заданным качеством в заданные сроки и в рамках бюджета;

• поддерживать удобную дисциплину сопровождения, модификации и наращивания системы, чтобы ИС могла отвечать быстро изменяющимся требованиям работы компании;

• обеспечивать создание ИС, отвечающих требованиям открытости, переносимости и масштабируемости;

• обеспечивать использование в разрабатываемой ИС резерва в области информационных технологий, существующего в организации (программного обеспечения, баз данных, средств вычислительной техники, телекоммуникаций, технологий).

Методология должна обеспечивать снижение сложности процесса создания ИС за счет полного и точного описания этого процесса и применения современных методов и технологий создания ИС на всем жизненном цикле ИС – от замысла до реализации, включая при необходимости и модернизацию.

В 90-ые годы в мире произошли кардинальные изменения как на рынках товаров и услуг, так и в информационных технологиях (ИТ). Современные ИС становятся основным фактором успешной работы компаний на рынке. Для выполнения своего назначения они должны решать значительно более сложные задачи, чем раньше. В соответствии с высокой динамикой изменения ситуации на рынке становятся очень жесткими требования как к функциям, выполняемым ИС, так и к процессам создания и модернизации ИС. Резко ужесточились требования ко времени разработки отдельных приложений и системы в целом. Появилась необходимость в изменении требований в процессе разработки с тем, чтобы система отвечала требованиям организации на момент конца разработки, а не на момент начала. [140] Достижения в области ИТ позволили преодолеть принципиальные технические и программно-инструментальные проблемы создания и модернизации ИС.

Мощные импульсы развитию методологий дало появление двух принципиально новых подходов к созданию и модернизации ИС: информационного инжиниринга и реинжиниринга бизнес-процессов. Предлагаемые в них методы позволили описывать, анализировать и проектировать структуру и деятельность компаний подобно техническим системам. Каждый из этих подходов породил свой класс методологий, обладающих общими характеристиками. В настоящее время продолжается активный процесс развития и совершенствования методологий создания и модернизации ИС. В этой области работают многие ведущие специалисты во всем мире. В 1994г в Великобритании был создан международный консорциум DSDM (Dynamic Systems Development Method), объединяющий более 100 ведущих фирм мира, который на постоянной основе разрабатывает проекты стандартов, методы и методологию быстрого создания приложений (ИС). В консорциуме участвуют и российские компании.

Таким образом, с появлением инструментальных средств нового поколения роль методологии при создании ИС не только не снизилась, - она возросла.

Отметим, что создание и поддержание информационной системы (ИС), в частности базы данных всегда предполагает решение вопросов дублирования, актуализации и верификации информации [67, 79, 94, 95, 96, 98, 99, 105, 115, 127, 148, 158, 166-169, 182, 206, 213, 219, 248]. Решение кроется в стандартизации информации в рамках базы данных. В противном случае сама идея базы данных бессмысленна.

При внесении данных из разрозненных источников в базу, даже при соблюдении технологии, заложенной в каждую из них, трудоемкость отслеживания повторов достаточно высока. При увеличении объема базы свыше 100 000 записей эта проблема существенно тормозит дальнейшее развитие такой базы данных [4, 63, 80, 89-92, 100, 111, 116, 134, 138, 146, 154, 161, 208, 221, 224, 229, 249, 252, 253, 261].

1.2. Обзор исследований в области реинжиниринга 1.2.1. Возможности современных CASE-средств для извлечения структурной информации из данных Обратное проектирование (реинжиниринг) это полное и точное восстановление исходной концептуальной схемы по файлам DDL или непосредственно из словаря целевой СУБД [232].

Проводить реинжиниринг – значит построить исходную модель БД путем исследования ее программных кодов [180, 195, 210]. Эта функция очень удобна в случае, если необходимо разобраться уже существующей базе данных.

Извлечение структурной информации из уже существующих баз данных является достаточно актуальной задачей [244], которую необходимо решать в процессе перепроектирования баз данных, вызванного необходимостью, связанной с изменением потребностей в информационном обеспечении.

Чаще всего это вызвано следующими причинами:

необходимостью изменения информационной платформы (например, переход на другую СУБД);

значительным расширением функционала информационной системы, требующим соответственно и расширения концептуальной модели базы данных;

внесения принципиальных изменений в концептуальную модель, вызванных значительными изменениями в бизнес-процессах [251].

Данная задача может быть решена путем анализа словаря данных БД, с помощью средств реинжиниринга, присутствующих в большинстве распространенных средств автоматизации проектирования баз данных.

В процессе реинжиниринга (обратного проектирования) порядок использования CASE-средства становится обратным – от базы данных на диске к логической или концептуальной модели [137, 201]. Помимо построения модели, CASEсредства позволяют быстро интегрировать полученные таким образом модели в проект, а также с меньшими потерями переходить от одной физической реализации к другой (например, в случае ухода «старых» разработчиков, плохо документирующих программное обеспечение, или появления новых, более перспективных языков программирования и СУБД) [202].

Средства реинжиниринга, обеспечивающие анализ схем баз данных и формирование на их основе концептуальных моделей и проектных спецификаций.

Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor и др.

Таким образом с помощью существующих средств реинжиниринга решается задача формального восстановления концептуальной модели предметной области по существующей базе данных.

Однако возникает ряд проблем, которые невозможно решить путем применения стандарнтых средств реинжиниринга [1, 2, 18].

1. Невозможность автоматического обнаружения и соответственно исправления ошибок, допущенных разработчиками при создании концептуальной модели данных, что неизбежно приводит к репродукции этих ошибок в новой базе данных.

2. Невозможность автоматического объединения концептуальных моделей нескольких баз данных, существующих отдельно, но принадлежащих к одной предметной области. Такая задача обычно возникает при укрупнении информационных систем, за счет объединения ранее разрозненных баз данных, функционирующих на одном предприятии, учреждении и так далее.

Таким образом возможности современных CASE-средств (Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, Erwin, S-Designor и др.) для решения задачи реинжиниринга целесообразно использовать только на начальном этапе для получения информации о структурах отдельных баз данных.

1.2.2. Современные методы и подходы извлечения зависимостей из актуальных данных Существует ряд работ [176, 149, 156, 196, 223, 188], в которых в различной степени определяется соотносимая с реинжинирингом ИС деятельность, выявляется и исследуется место реинжиниринга в жизненном цикле (ЖЦ) ИС.

Следует признать, что в настоящий момент понятие «реинжиниринг ИС» не является повсеместно устоявшимся. Как следствие довольно часто возникает определенная терминологическая путаница. Авторами исследуются одни и те же проблемы, подходы, методы и технологии их решения, однако в качестве базовых понятий, наряду с «реинжинирингом ИС» [176, 149, 156] употребляются «эволюция ИС» [155, 223], «миграция ИС» [245], «модернизация ИС» [149], «реструктуризация ИС» [156].

Нельзя отрицать, что деятельность по миграции ИС имеет определенную специфику (окраску) по отношению к деятельности по модернизации ИС. Однако, принимая во внимание определение реинжиниринга ИС, приводимое в [176]:

«Реинжиниринг представляет собой систематическую трансформацию существующей системы с целью улучшения ее характеристик качества, поддерживаемой ею функциональности, понижения стоимости ее сопровождения, вероятности возникновения значимых для заказчика рисков, уменьшения сроков работ по сопровождению системы», становится очевидным, что и миграция, и модернизация ИС являются частью деятельности по реинжинирингу ИС. Как результат, подходы, методы и технологии миграции, модернизации, эволюции ИС, следует считать частью методологического и инструментально-технологического обеспечения процесса реинжиниринга ИС. [5] Такой взгляд на реинжиниринг ИС согласуется с таксономией, вводимой в ряде работ [176, 149, 156, 196, 223]. В этих работах авторами делается попытка выстроить систему понятий, соотносимых с данным видом деятельности. Так, в [202] реинжиниринг ИС определяется как «исследование (изучение, обследование) и перестройка исходной системы с целью ее воссоздания в новой форме с последующей реализацией этой новой формы. Далее, в контексте деятельности по реинжинирингу вводятся и определяются такие важные понятия, как • прямой инжиниринг (Forward engineering);

• редокументирование (Redocumentation);

• рефакторинг (Refactoring);

• реструктуризация (R тоestructuring);

• переориентация (Retargeting);

• обратный инжиниринг (обратное проектирование) (Reverse engineering);

• сопровождение программных продуктов (Software maintenance);

• трансляция исходного кода (Source Code Translation);

Прямой инжиниринг (Forward engineering).

Традиционный процесс перехода от высокоуровневых абстракций и логического, независящего от реализации проектирования к физической реализации системы [202].

Представляет собой переход от требований к высокоуровневому проектированию, и далее к низкоуровневому проектированию и реализации [213].

Представляет собой множество видов деятельности по инжинирингу системы, на вход которым для производства новой целевой системы поступают продукты и артефакты, производные от унаследованных программных средств, и новые требования [200].

Основное отличие прямого инжиниринга от реинжиниринга заключается в том, что в случае реинжиниринга «стартуют» от существующей реализации (существующей системы).

Основное отличие прямого инжиниринга от инжиниринга в целом заключается в том, что на вход прямого инжиниринга поступают результаты реинжиниринга [200].

Редокументирование (Redocumentation).

Форма реструктуризации, где результирующее семантически эквивалентное представление системы является альтернативным взглядом, предназначенным для его восприятия человеком [202].

Процесс анализа системы с целью создания различного рода сопровождающей ее документации. Включает в себя как создание руководств пользователя, так и переформатирование листинга исходного кода [200].

Рефакторинг (Refactoring).

Специальный вид реструктуризации, а именно реструктуризации на уровне программного кода, имеющей объектно-ориентированный контекст. Является процессом изменения программной системы, направленным на улучшение внутренней структуры программного кода, но не изменяющим внешнего поведения программы [203, 213].

Реструктуризация (Restructuring).

Трансформация системы из одной формы представления в другую на одном и том же уровне абстракции. Новое представление сохраняет семантику и внешнее поведение (функциональность) оригинала [202, 200].

Переориентация (Retargeting).

Процесс трансформации и перевода (переноса) существующей системы в новую конфигурацию [200].

Например, перенос на новую аппаратную платформу, под новую операционную систему, под новое CASE-средство.

Обратный инжиниринг (обратное проектирование) (Reverse engineering).

Процесс анализа исходной системы, преследующий 2 цели – выявить компоненты системы и отношения между ними, и создать представление системы в другой форме или на более высоком уровне абстракции [202].

Процесс достижения понимания системы, ее анализа и абстрагирования по направлению к новой форме представления, соответствующей более высокому уровню абстракции [200].

Процесс извлечения информации из существующей программной системы [213]. В общем случае обратное проектирование применяют для извлечения информации на высоком уровне абстракции, например информации уровня проектированию на основе программного кода.

Сопровождение программных продуктов (Software maintenance).

Модификация программного продукта после его поставки в целях исправления ошибок, улучшения производительности и других атрибутов качества, или адаптации продукта к изменениям окружения (внешней среды) [196].

Трансляция исходного кода (Source Code Translation).

Трансляция исходного кода с одного языка программирования на другой или с одной версии в другую на том же самом языке программирования [200].

Инжиниринг систем (Systems Engineering).

Высокоуровневый процесс инжинирии систем, направленный на достижение соответствия системы всем выдвигаемым к ней требованиям [200].

Перечисленные понятия раскрывают понятие «реинжиниринг ИС», а соотносимая с ними деятельность рассматривается либо как одна из форм реинжиниринга ИС, либо как подпроцесс процесса реинжиниринга.

В [176] авторы придерживаются следующей позиции при определении границ деятельности по реинжинирингу, и, как следствие, места реинжиниринга в ЖЦ ИС.

Утверждается, что реинжиниринг ИС занимает промежуточное местоположение по отношению к разработке и сопровождению ИС. При этом сопровождение ИС рассматривается как деятельность, предусматривающая выполнение изменений, направленных на коррекцию, усовершенствование и адаптацию ИС, а разработка ИС как деятельность, включающая реализацию новых возможностей, добавление новой функциональности, осуществление таких существенных улучшений, как переход на использование новых компьютеров, внедрение новых информационных технологий. Авторами правомерно утверждается, что реинжиниринг характеризуется деятельностью, как по сопровождению, так и по разработке ИС.

При этом эти два вида деятельности в контексте реинжиниринга ИС могут существенно перекрываться.

В отличие от [176], работа [149] посвящена вопросам модернизации унаследованных информационных систем. В ней делается обзор различных методик модернизации унаследованных систем, определяется роль модернизации систем в процессе управлениях их эволюцией. Утверждается, что коммерческий рынок предлагает разнообразные решения проблемы модернизации унаследованных систем, которая становится все более актуальной. В сложившейся ситуации понимание преимуществ и слабых мест каждой такой методики является чрезвычайно важным, поскольку обуславливает выбор правильного решения, и как следствие успех деятельности по модернизации системы.

В контексте исследований, связанных с эволюцией ИС, авторами выделяются деятельности по сопровождению, модернизации и замещению ИС.

Определяется, что сопровождение представляет собой инкрементальный итеративный процесс, в рамках которого выполняются малые изменения в системе, не затрагивающие структурной организации системы (архитектуры системы).

В отличие от сопровождения модернизация характеризуется как деятельность, которая предусматривает значительные изменения существующей системы (в том числе в ее структуре), но не ее утилизацию или замещение новой системой.

И, наконец, замещение рассматривается как процесс, который заключается во внедрении новой системы, способной полностью заменить существующую ИС.

Замещение обычно применяется к системам, которые недокументированны, устарели или не расширяемы, расходятся с требованиями бизнеса и для которых модернизация невозможна или экономически не выгодна.

Приводимые в [149] виды деятельности основаны на таксономии, вводимой в [188]. В отличие от предыдущей работы, в [188] в качестве базового понятия используется именно «реинжиниринг», а вводимая таксономия рассматривается как множество видов деятельности, соотносимых с реинжинирингом ИС. При этом применительно к унаследованным ИС выделяются соответственно деятельности по их оценке, сопровождению, трансформации, замещению, а так же смешанные стратегии, предусматривающие совместное выполнение перечисленных ранее видов деятельности.

Обеспечивая концептуальное понимание процесса реинжиниринга ИС, в ряде работ [176, 205] определяются основные виды деятельности (фазы) соотносимые с этим процессом.

Так, в [176] рассматриваются следующие основные фазы:

• оценки показателей проекта по реинжинирингу, в том числе характеристик унаследованной информационной системы (фаза оценки);

• анализа решений по реинжинирингу, в том числе принятие решения о необходимости проведения работ по реинжинирингу или сопровождению/разработке ИС;

• осуществления реинжиниринга (выполнения работ по реинжинирингу);

• внедрения системы, трансформированной в результате проведения реинжиниринга.

Другой подход к определению деятельности по реинжинирингу базируется на так называемой модели «подковы» [205, 197].

Подход, предложенный в [198], очень близок к подходу, основанному на модели «подкова». Характеризуя жизненный цикл реинжиниринга ИС, авторы определяют следующие шаги процесса реинжиниринга:

• анализ требований для выявления конкретных целей реинжиниринга унаследованной системы;

• восстановление модели, в том числе документирование и понимание структуры унаследованной системы;

• выявление проблем, связанных с унаследованной системой;

• анализ проблем, включающий выбор архитектуры, позволяющий устранить обнаруженные в унаследованной системе дефекты;

• реорганизация, включающая выбор и применение оптимального подхода трансформации унаследованной системы;

• распространение изменений.

В отличие от предыдущих работ, в [155] деятельность по реинжинирингу рассматривается в качестве одной из форм деятельности по эволюции унаследованных ИС, когда, требуется более сильнодействующее «лекарство» для «лечения» ИС, нежели серия локальных инкрементальных изменений.

Так, в [233] описывается каркас (enterprise framework), характеризующий:

• глобальную среду, в которой осуществляется эволюция системы;

• действия, процессы и рабочие продукты (артефакты), которые сопровождают деятельность по эволюции системы.

Авторами подчеркивается, что помимо технических вопросов, связанных с эволюцией унаследованных ИС, существует так же множество организационных вопросов. Например, «Как планировать эволюцию большой сложной системы, включая ее реинжиниринг?», «Какие существуют критичные факторы успеха эволюции системы?», «Как оценить, что люди, осуществляющие эволюцию системы, на правильном пути?». Кроме этого, важным является необходимость учета стратегических, организационных, и других аспектов бизнеса, влияющих на эволюцию унаследованной ИС.

В [155] авторами предлагается комплексный, основанный на рассмотренном ранее каркасе, подход к эволюции систем, который определяется в контексте унаследованных систем и современных программных технологий.

В основу подхода положены следующие положения (принципы):

• различие между эволюцией систем и сопровождением программных средств;

• использование описанного ранее каркаса (enterprise framework) при поддержке принятия решений в процессе эволюции системы;

• достижение технического понимания систем на высоком уровне абстракции;

• применение технологий распределенных объектов, технологии «wrapping» для эволюции системы;

• применение «net-centric» [155] вычислений для эволюции системы.

Определяя различие между сопровождением программных средств и эволюцией систем в части реинжиниринга ИС, авторы рассматривают сопровождение как «мелкозернистую», «краткосрочную» деятельность, направленную на планирование и внесение локализованных изменений. При сопровождении структура (архитектура) системы остается относительно неизменной, а требуемая «порция»

вносимых за определенный промежуток изменений, как правило, связана с изменением какого-либо одного требования к системе. Такие изменения, обычно, не сопровождаются существенным изменением значений характеристик и атрибутов качества программных средств.

В отличие от сопровождения, эволюция систем рассматривается как «крупнозернистая», «высокоуровневая», форма изменений на уровне структуры (архитектуры) системы. Вносимые в процессе эволюции изменения, приводят к изменениям значений атрибутов качества, что, как правило, существенно упрощает сопровождение систем. Для этого при внесении изменений в структуру системы могут использоваться стратегии «снизу вверх» и «сверху вниз», применение которых основано на ревизии программного кода, восстановлении описания архитектуры унаследованной системы, проектировании новой структуры, новой формы документации и т.д.

Авторами подчеркивается, что эволюция позволяет адаптировать систему сразу с учетом большого количества выдвигаемых к ней требований (включая приобретение новых возможностей), что в конечном итоге увеличивает стратегическую и экономическую значимость программных средств. При этом акцент смещается от понимания программ к пониманию систем, от сопровождения к эволюции и миграции, от стратегий «снизу вверх» к стратегиям «сверху вниз».

В отличие от рассмотренных ранее работ, в [245] основное внимание уделяется исследованию и решению технических проблем, связанных с миграцией унаследованных систем. Характеризуя понятие «миграция ИС» в данной работе выделяются отдельно эволюция, сопровождение и миграция ИС. Основываясь на том факте, что объектом эволюции и сопровождения является унаследованная ИС, а объектом миграции как унаследованная, так и новая (целевая) системы, авторы разделяют миграцию и другие процессы ЖЦ ИС. При этом миграция рассматривается как деятельность, которая начинается с унаследованной ИС и заканчивается сопоставимой целевой ИС.

В основу предлагаемого авторами подхода положена декомпозиция структуры системы на компоненты пользовательского интерфейса, компоненты – приложения и компоненты управления базами данных. При этом в качестве основных инкрементально выполняемых шагов миграции выступают:

• декомпозиция структуры унаследованной ИС;

• проектирование интерфейсов (пользовательских и системных) целевой системы;

• проектирование приложений (функциональной логики) целевой системы;

• проектирование базы данных целевой системы;

• развертывание среды, требуемой для эксплуатации и сопровождения целевой системы;

• создание и развертывание необходимых шлюзов;

• миграция унаследованных данных;

• миграция унаследованных приложений (компонентов, реализующих функциональную логику);

• миграция унаследованных интерфейсов (пользовательских и системных);

• переход к использованию целевой системы.

В [203] детально исследуются вопросы классификации, определяющей структуризацию на множестве существующих подходов, методов и технологий реинжиниринга ИС, в меньшей степени в [201]. Так, в [176] выделяются основные фазы процесса реинжиниринга ИС, а для каждой фазы определяются действия (деятельности) и соотносимые с ними потоки управления. Процесс дается в самом общем виде и не зависит от каких-либо ограничений, например используемых программных технологий. В [203] авторами так же определяется выполняемый в рамках процесса реинжиниринга поток работ. Однако, здесь основное внимание уделяется вопросам технического характера, а выполняемые при реинжиниринге шаги предусматривают декомпозицию структур, соответственно, унаследованной и целевой системы на компоненты пользовательского интерфейса, компоненты – приложения и компоненты управления базами данных. В отличие от предыдущих работ в [203] авторами основной акцент сделан на решение задач оценки унаследованных систем и поддержки принятия решений при реинжиниринге ИС.

Следует признать, в процессе проводимых исследований не было обнаружено целостных методологий и технологий реинжиниринга ИС, соответствующих уровню проработки и области охвата Rational Unified Process (RUP) [199]. В наибольшей степени эта проблема исследуется в [201]. В тоже время, в [176] предлагается лишь каркас, определяющий основной ход работ, в [201] даются рекомендации по выполнению основных видов деятельности по реинжинирингу. В [204] определяются лишь процессы оценки унаследованных систем, а в [245] основное внимание уделяется вопросам технического характера, при этом основной акцент сделан на решение проблем интеграции систем, в то время как методы анализа унаследованной системы практически не рассматриваются.

Проблемы реинжиниринга Опыт показывает, что восстановление концептуальных структур данных может быть гораздо сложнее, чем процесс анализа кода DDL БД. Непереведенные структуры данных и ограничения, нестандартные подходы и методы реализации и плохо разработанные схемы – это лишь некоторые из трудностей, с которыми аналитики встречаются при попытке изучения существующей БД по компонентам существующей системы. Так как код DDL больше не является уникальным источником информации, аналитики вынуждены ссылаться на другие документы и системные компоненты, что может оказаться более сложным и менее надежным. Самые частые источники проблем [18, 19, 46] могут быть классифицированы следующим образом.

Недостаточность документации. Каждая часть программного обеспечения должна сопровождаться современной документацией. Однако трудно скрыть факт, что большинство из них остается недокументированное, или, в лучшем случае, сопровождается плохой, частичной, неоднородной, непоследовательной и устаревшей документацией, обычно на бумаге.

Недостатки моделей СУБД. Техническая модель систем управления данными (таких как системы подобные CODASYL, стандартные файловые менеджеры и СУБД IMS) может выразить только небольшое подмножество структур и ограничений намеченной концептуальной схемы. В лучшем случае такие отброшенные конструкции управляются в процедурных компонентах приложения: программы, диалоговые процедуры, триггеры и т.д., и могут быть восстановлены посредством процедурного анализа.

Неявные структуры. Такие конструкции не были преднамеренно явно объявлены в спецификации DDL БД. Они были реализованы таким же образом, как упомянутые выше отброшенные конструкции.

Оптимизированные структуры. По техническим причинам, таким как время и/или оптимизация пространства, многие структуры БД включают не семантические конструкции. Кроме того, добавляются избыточные и ненормализованные конструкции в целях уменьшения времени отклика.

Грубое проектирование. Не все БД были созданы опытными разработчиками. Неопытные разработчики, как правило, не знающие теорию и методологию БД, часто определяют плохие или даже неправильные структуры.

Устаревшие конструкции. Некоторые части БД могли быть заброшены и проигнорированы текущей программой.

Влияние перекрестной модели. Профессиональная подготовка разработчиков может привести к очень специфическим результатам. Например, некоторые РБД фактически являются результатом прямых преобразований IMS БД, файлов COBOL или электронных таблиц [153].

1.3. Проектирование схем РБД Процесс проектирования БД принято разделять на следующие этапы[103, 100]:

концептуальное проектирование баз данных — создание модели информации, не зависящей от любых аспектов её физической реализации, на основе предметной области;

логическое проектирование баз данных, заключающееся в отображении объектов предметной области в абстрактные объекты модели данных не зависящие от любых аспектов их физической реализации;

физическое проектирование баз данных, решающее вопрос размещения во внешней памяти данных, хранимых в БД, с учетом специфики используемой СУБД для её эффективного использования.

Концептуальное и логическое проектирование можно рассматривать в виде одного шага, определяющего качество будущей базы данных. К критериям качества разрабатываемой логической модели относятся[113, 114]:

адекватность базы данных предметной области;

легкость разработки и сопровождения базы данных;

скорость выполнения операций обновления данных (вставка, обновление, скорость выполнения операций выборки данных.

К. Дейт формулирует задачу проектирования в виде выбора логической структуры для заданного набора данных, которые требуется поместить в проектируемую РБД. Под логической структурой здесь понимаются базовые переменные отношения и набор атрибутов.

Таким образом методом последовательных приближений к набору схем отношений удовлетворяющих исходным требованиям к проектируемой системе, в том числе требованиям целостности, безопасности и др. происходит проектирование базы данных. Первым приближением является представление исходной предметной области в виде отношений (одного или нескольких). Затем происходит постепенное совершенствование набора отношений с точки зрения их использования. Под совершенствованием здесь подразумевается избавление от избыточности информации, аномалий изменения и аномалий удаления, которые более подробно будут рассмотрены в разделе 2.1.1. С точки зрения физической реализации, такое совершенствование позволяет сократить объем используемой для хранения данных памяти и временные затраты на многократные операции обновления избыточных копий[96].

На данный момент можно выделить следующие способы проектирования РБД:

на основе принципов нормализации;

на основе семантических моделей, с использованием ER-диаграмм;

на основе семантических моделей, с использованием диаграмм классов языка UML.

Восходящее и нисходящее проектирование.[79] Проектирование РБД с помощью алгоритма нормализации Процесс проектирования представляет собой процесс нормализации схем отношений, причем каждая следующая нормальная форма обладает свойствами, в некотором смысле, лучшими, чем предыдущая. [103] Цель нормализации сводится к получению проекта базы данных, в котором «каждый факт появляется лишь в одном месте». Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных [96].

1.3.1. Аномалии Избыточность хранимой в БД информации приводит к проблемам, проявляющимся при попытках изменить состояние БД, например при изменении предметной области для которой эта БД и была спроектирована. Эти проблемы получили название аномалий.

Причины возникновения аномалий, по мнению разных авторов не всегда совпадают. В [113, 114] под причинами аномалий понимаются:

неадекватность модели данных предметной области;

дополнительные трудности в реализации ограничений предметной области средствами СУБД.

То есть аномалии, в большинстве своем, возникают либо из-за неверно спроектированной логической модели БД, либо из-за неправильного использования средств СУБД при физической реализации логической модели(верной). Именно поэтому процесс создания логической модели проектируемой БД часто называют искусством.

К. Дейт [92] обращает внимание на то, что «...решения, принятые в процессе физической реализации проекта, могут оказывать существенное обратное влияние на его логический уровень.» Автор объясняет это относительно простыми средствами отображения между логическим и физическим уровнями. Таким образом может потребоваться пересмотр спроектированной логической модели, более того, такой возврат может быть не одиночным.

Принято различать три вида аномалий:

аномалии обновления;

аномалии вставки;

аномалии удаления.

В основном все они возникают из-за хранения в одном отношении разнородной информации. Это приводит негативным последствиям разного рода:

неадекватность логической модели данных модели предметной области;

увеличение сложности разработки базы данных;

необходимость дополнительного программного кода в виде триггеров.

1.3.2. Нормализация Для корректного проектирования логической модели БД применяется метод нормализации отношений, позволяющий устранить указанные аномалии. Нормализация основана на понятиях функциональной зависимости атрибутов отношения и декомпозиции [95].

При проектировании БД, для повышения адекватности логической модели БД модели предметной области разработчики пользуются определенными типами ограничений. Наиболее важным из них является ограничение уникальности, называемое функциональной зависимостью. Данный тип ограничений необходим для избавления БД от избыточной информации.

В [95] понятие функциональной зависимости звучит следующим образом:

Пусть R - отношение. Множество атрибутов Y функционально зависимо от множества атрибутов X (символически X Y) тогда и только тогда, когда для любого состояния отношения R для любых кортежей r1,r2R из того, что r1.X=r2.X следует что r1.Y=r2.Y.

Автор подчеркивает, что функциональная зависимость - семантическое понятие. Она возникает, когда по значениям одних данных в предметной области можно определить значения других данных. Другими словами функциональная зависимость это некоторое предположение относительно структуры схемы отношения, не связанное с конкретным экземпляром данного отношения. К. Дейт в своей книге [92] уделяет особое внимание различению отношения и экземпляра отношения, именно для этого он использует понятие переменной отношения.

Угрозы информационной безопасности С переходом к постиндустриальному, или информационному, обществу, цена информации сильно возросла. Так, предприятие может иметь большой финансовый ущерб от потери данных по своим клиентам и финансовым отчетам по работе. Часто используется резервирование информации, предназначенное для минимизации такого ущерба. Однако, в динамично работающие ИС могут быть внесено очень много изменения между моментами резервирования. Таким образом, резервирование позволяет минимизировать финансовые потери от утраты информации, но не свести их к нолю [34, 35, 36, 81-87]].

Предприятие может иметь большой ущерб от хищения информации. Например, данные по клиентам предприятия могут быть похищены конкурентами, что может привести к заключению договоров клиентов с конкурентами. Также, при хищении информации могут быть раскрыты персональные данные работников или клиентов предприятия, что может привести к судебным искам против предприятия, так как персональные данные защищены законодательством.

В информационную систему могут быть внедрены ложные данные, что может привести к неверному трактованию ситуации и принятию неадекватных решений. Существуют исторические факты, когда в результате изменения информации в процессе прохождению по каналу передачи данных, были совершены крупные финансовые махинации с поглощением конкурентов [27].

Все вышеперечисленные угрозы стали появляться, как было описано ранее, с переходом к информационному обществу. Уже давно используются различные методы защиты информации, которые позволяют уменьшить вероятность реализации вышеперечисленных угроз. Среди них используются как организационные методы, так и методы технического характера. Производственный процесс должен быть организован так, чтобы утрата, хищение или повреждение информации не могли быть совершены работниками [55, 56, 57].

Не смотря на то, что организационные методы защиты информации оказывают существенное влияние на вероятность повреждения, хищения или утери информации, технические средства защиты информации, со своей стороны не должны давать работникам совершать тех действий, которые им запрещены по регламенту работы с ИС.

БД стали разрабатываться довольно масштабно. Часто, безопасности и стабильности разработок не придавалось значение. Это породило ряд программных уязвимостей, которые также распространяются и на БД.

Переполнение стека (выполнение произвольного кода, повышение привилегий) Переполнение буфера (Вuffer Overflow) — явление, возникающее, когда компьютерная программа записывает данные за пределами выделенного в памяти буфера.

Переполнение буфера обычно возникает из-за неправильной работы с данными, полученными извне, и памятью, при отсутствии жесткой защиты со стороны подсистемы программирования (компилятор или интерпретатор) и операционной системы. В результате переполнения могут быть испорчены данные, расположенные следом за буфером (или перед ним).

Переполнение буфера является наиболее популярным способом взлома компьютерных систем, так как большинство языков высокого уровня используют технологию стекового кадра — размещение данных в стеке процесса, смешивая данные программы с управляющими данными (в том числе адреса начала стекового кадра и адреса возврата из исполняемой функции).

Переполнение буфера может вызывать аварийное завершение или зависание программы, ведущее к отказу обслуживания (denial of service, DoS). Отдельные виды переполнений, например переполнение в стековом кадре, позволяют злоумышленнику загрузить и выполнить произвольный машинный код от имени программы и с правами учетной записи, от которой она выполняется.

Иногда, переполнение буфера намеренно используется системными программами для обхода ограничений в существующих программных или программно-аппаратных средствах. Например, операционная система iS-DOS (для компьютеров ZX Spectrum) использует возможность переполнения буфера встроенной TR-DOS для запуска своего загрузчика в машинных кодах (что штатными средствами в TR-DOS сделать невозможно).

Защита пространства исполняемого кода для UNIX-подобных систем Защита пространства исполняемого кода может смягчить последствия переполнений буфера, делая большинство действий злоумышленников невозможными.

Это достигается рандомизацией адресного пространства (ASLR) и/или запрещением одновременного доступа к памяти на запись и исполнение. Не исполняемый стек предотвращает большинство эксплойтов кода оболочки.[175] Существует два исправления для ядра Linux, которые обеспечивают эту защиту — PaX и exec-shield. Ни один из них ещё не включен в основную поставку ядра. OpenBSD с версии 3.3 включает систему, называемую W^X, которая также обеспечивает контроль исполняемого пространства.

Заметим, что этот способ защиты не предотвращает повреждение стека. Однако он часто предотвращает успешное выполнение «полезной нагрузки» эксплойта. Программа не будет способна вставить код оболочки в защищённую от записи память, такую как существующие сегменты исполняемого кода. Также будет невозможно выполнение инструкций в не исполняемой памяти, такой как стек или куча.

ASLR затрудняет для взломщика определение адресов функций в коде программы, с помощью которых он мог бы осуществить успешную атаку, и делает атаки типа ret2libc очень трудной задачей, хотя они всё ещё возможны в контролируемом окружении, или если атакующий правильно угадает нужный адрес.

Некоторые процессоры, такие как Sparc фирмы Sun, Efficeon фирмы Transmeta, и новейшие 64-битные процессоры фирм AMD и Intel предотвращают выполнение кода, расположенного в областях памяти, помеченных специальным битом NX. AMD называет своё решение NX (от англ. No eXecute), а Intel свое — XD (от англ. eXecute Disabled).

Угрозы, характерные для web-приложений Развитие языка SQL [120] привело к тому, что его стали знать многие специалисты. Появились уязвимости, связанные с неверным использованием SQL, что часто связано с небрежностью написания программного обеспечения [146].

Внедрение SQL-кода (англ. SQL injection) — один из распространённых способов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL-кода.

Внедрение SQL, в зависимости от типа используемой СУБД и условий внедрения, может дать возможность атакующему выполнить произвольный запрос к базе данных (например, прочитать содержимое любых таблиц, удалить, изменить или добавить данные), получить возможность чтения и/или записи локальных файлов и выполнения произвольных команд на атакуемом сервере.

Атака типа внедрения SQL может быть возможна из-за некорректной обработки входящих данных, используемых в SQL-запросах.

Разработчик прикладных программ, работающих с базами данных, должен знать о таких уязвимостях и принимать меры противодействия внедрению SQL.

Угрозы базам данных на сетевом уровне С разлитием и широким применением сетей в 90-е годы архитектура «клиент-сервер» стала занимать доминирующую роль, так как появилась возможность подключения к серверу с клиентов, удаленных от сервера географически. Это позволяет получить доступ к данным организации, находясь вне нее. Однако, такое подключение влечет за собой риски, связанные с передачей информации по вычислительным сетям других огранизаций. Возможны следующие атаки через сеть:

Возможны такие действия:

1. перехват трафика на маршрутизаторах;

2. перехват трафика с помощью спуфинг-атак (spoofing);

3. прослушивание трафика при использовании топологии с общей шиной (устаревшее).

Многие современные сети используют сетевой менеджер и некоторый вид SNMP протокола или CMIP для управления сетью. Наряду с управленческими задачами сетевой менеджер автоматически контролирует за состоянием устройств на сети. Обычно SNMP-управляемое (или CMIP-управляемое) устройство сохраняет в своей памяти Базу Управленческой Информации (MIB), набор объектов или переменных, представляющих различные аспекты устройства (напр., по конфигурации, статистике, состоянию, управлению).

В таких условиях, важно предотвратить несанкционированный доступ лиц к управленческим информационным объектам в сети. Иначе, не только м. б. получена конфиденциальная информация несанкционированными лицами, но также существует риск раскрытия сети для действий саботажа. Новый предлагаемый в пат.

метод исключает такие проблемы, обеспечивая ограниченный доступ к БД к управляемой объектной информации с помощью таблицы разрешений, которая устанавливает права доступа к управляемым объектам. Такой метод обеспечивает прямой доступ типа SQL к БД управляемых объектов в целях генерирования отчетов, в отличие от других доступов к объектам. Механизм передачи информации посылает управленческую информацию из сети в СУБД систему, где информация сохраняется в виде наборов таблиц БД.

Стоит отметить, что такие атаки возможны и внутри ЛВС, однако в ГВС их вероятность значительно выше.

Администрирование БД Администрирование БД стало сложной комплексной задачей, что связано с постоянно растущими функциональными возможностями СУБД. В середине годов разработаны определенные подходы к администрированию, чему были посвящены научные публикации [64-66, 68, 112].

Упомянутая задача стала достаточно сложной, чтобы ее можно было автоматизировать. На это был ориентирован ряд опубликованных статей [64, 249]. Такие системы выполняют часть рутинной работы администрирования, в которой процессе которой допускается множество ошибок. В широкое употребление вошел механизм пользовательских ролей — Role-based acccess control, с помощью которого решается множество задач автоматизации администрирования доступа к объектам, в том числе и в БД [190].

Были разработаны интеллектуальные технологии работы с БД. Например, использование интеллектуальных агентов, как частей распределенной информационной системы, в задачах динамического администрирования БД в реальном времени с помощью анализа действий пользователя, а также групповых свойств БД, включая автономность, реактивность, рефлективность, а также регистрацию нажатия всех функциональных клавиш интерфейса пользователя [112].

Многопользовательский доступ Одним из основным преимуществом клиент-серверной архитектуры является возможность организации многопользовательского доступа. Изначально, во времена разработки Ingress и System R, сервер выделялся на отдельную аппаратную платформу для того, чтобы избежать излишних затрат на оборудование и при этом обеспечить возможность работы с нескольких рабочих мест.

С развитием многопользовательского доступа возникла проблема ограничения доступа к информации в БД: идентификации, аутентификации и авторизации.

В 1992 году в России уже были сформулированы требования к безопасности ИС [119]. Для 6-го класса защищенности уже обязательно предусматривалось идентификация, аутентификация и авторизация пользователей. Для 5-го класса защищенности обязательной была возможность журнализация доступа к защищенным объектам и регистрации в система. Таким образом, предоставление этих возможностей стало необходимым для создания защищенных ИС.

Идентификация — процесс определения пользователя. В результате идентификации система однозначно определяет пользователя по соответствующим параметрам: идентификатору пользователя, имени пользователя и т.д. Аутентификация — процесс проверки, является ли пользователь, идентифицированный системой этим пользователем с использованием различных паролей, биометрических данных и прочее. Авторизация — процесс определения, имеет ли пользователь доступ к запрошенному им ресурсу (операции). Для надежной идентификации и аутентификации пользователей в последнее время предложено множество технических решений:

1. биометрическая идентификация/аутентификация 2. проведение идентификации/аутентификации централизованно на сервере аутентификации 3. использование смарт-карт [148] 4. использование RSA-ключей для доступа к ИС [72] Авторизации пользователей тоже уделяется много внимания. Например, используется многоступенчатая авторизация: например, в веб-приложениях производится проверка, имеет ли право пользователь на просмотр данной страницы или должен ли он видеть определенный элемент интерфейса на странице, а затем производится проверка на наличие прав пользователя на доступ к информации, которая отображается на этой странице.

Однако, развитие систем идентификации и аутентификации привело к существованию библиотек, используемые многими приложениями. Например, в Linux существует библиотека PAM (Pluggable Authentication Module), которая позволяет настроить систему аутентификации для конкретного приложения так, как это требуется задачей. Приложение, например, есди поддерживает аутентификацию только через PAM, уже используя PAM, может косвенно производить аутентификацию через 1. теневые пароли Unix 6. домены Windows и прочее Таким образом, для идентификации/аутентификации пользователя достаточно реализовать доступ к PAM. Более конкретную настройку надо будет делать уже в PAM. Но это будет уже не задача разработчика, а задача администратора.

Авторизация доступа к записям Авторизация же остается для реализации на задачу разработчика. При этом ему необходимо сделать выбор о том, какие конкретно методы авторизации он будет использовать. Например, в пакете RSBAC (Rule Set Based Access Control, англ.

— контроль доступа, базирующийся на наборе правил) в Linux предлагается настроить до 12 методов авторизации. Только пользователь, прошедший авторизацию по всем настроенным методам, допускается к запрашиваемой операции.

Однако, RSBAC написан для доступа к файловой системе и не перекрывает всех возможных ограничений доступа, которые могут возникнуть в требованиях к ИС.

Большая часть ИС базируется на БД. В современных БД существуют различные методы ограничения доступа. В основном, это ограничение доступа к конкретным базам данных, таблицам, столбцам, пакетам, процедурам и функциям. Не все СУБД поддерживают перечисленное здесь. Есть, однако, и СУБД, которые поддерживают также систему мандатным меток записей (Linter), которые позволяют предоставлять пользователю доступ лишь к определенным записям защищенных таблиц. В широкой эксплуатации находится только одна такая СУБД — Linter..

С точки зрения проектирования схемы БД, описанного Д. Мейером [106], где в одну таблицу должны попасть все записи об однотипных сущностях. Например, если есть таблица с данными по работникам ВУЗа, в которой перечислены все работники, включая их места прописки и проживания, то в эту таблицу должны быть включены записи как по рядовым работникам, так и по работникам, деятельность которых засекречена, следовательно, информация по ним имеет более высокую степень секретности.

Однако, в классической теории реляционных БД не говорится ничего об предоставлении различного доступа к записям — основное требование заключается в том, чтобы записи отражали одну сущность, что в данном примере не нарушается.

Современные разработки по ограничению доступа в БД К начале 2000-ых годов информатизация общества развилась на столько, что стала неотъемлемой частью производства, проникая во все сколь угодно малые организации. Работоспособность ИС теперь стала критически важной для всех сфер производства, а ее отсутствие может привести к крупным финансовым потерям.

Такая зависимость от ЭВМ стала очень часто эксплуатироваться недоброжелателями в виде различных атак.

Использование ИС практически всеми сотрудниками предприятия привело к появлению внутренних угроз для ИС — внутренних атак. Так, саботаж в информационной сфере внутри одного предприятия может вывести предприятие из производства на несколько дней. Информационные атаки отличаются сложностью обнаружения и расследования, что привело к их широкому распространению.

Большое внимание стало уделяться распределению доступа, чтобы обезопасить информацию, хранящуюся в системе, от пользователей этой же ИС, не нуждающихся в доступе к такой информации. Если в 90=х годах такое распределение доступа организовывалось на основе ограничения доступа к объектам БД: таблицам, процедурам и представлениям — то теперь этого стало недостаточно. К одному и тому же объекту БД может иметь доступа множество пользователей, имеющим потребности к доступу к различным записям этих объектов БД. Этому вопросу стало уделяться много внимания в научных исследованиях [72, 187].

Администраторы БД стремились сбалансировать требования по конфиденциальности в соответствии с потребностями законных пользователей для облегчения доступа и анализа организационных данных. Используя статистические БД, администраторы БД предоставляют пользователям доступ для сбора статистической информации, но не информации, касающейся конкретного объекта Гибкий доступ к БД В своей работе Min-A Jeong, Jung-Ja Kim и Yonggwan Won «Организация гибкой системы доступа к БД с использованием различных политик» («A flexible database security system using multiple access control policies») рассмотрели создание расширенного механизма доступа, позвволяющего управлять доступом пользователей к группам данных различной величины и позволенного при частом изменении прав доступа пользователей к защищаемым объектам.[230] Группы данных d определяются по именам таблиц, атрибутов и/или записей таблиц и подвергаются политике, определенной уровнем секретности, полями и прочими политиками доступа. Предлагаемая система доступа реализуется в 2 этапа. На первом этапе, производится контроль по модифицированному мандатному контролю доступа и ролевому доступу. Пользователь может получить доступ только к данным, имеющим более низкий уровень секретности и разрешенным одной из пользовательских ролей. Все режимы контроля доступа осуществлены на этом этапе.

На втором этапе используется модифицированная дискреционная модель доступа для перепроверки режима чтения с помощью фильтрации (отбрасывания) недоступных данных из результатов, полученных в результате прохождения первого этапа контроля доступа. Для этих целей создается группа пользователей s, которая характеризуется уровнем секретности, ролями и наборами пользователей.

Эта политика доступа представляется в виде кортежей (s,d,r), определенных заранее и используемых для определения предоставления пользователю доступа к данных или группе данных, которые недоступны в режиме чтения.

С предложенный системой безопасности более сложный доступ на чтение различных объемов данных для индивидуальный пользователей может быть гибко настроен, в то время, как другие методы доступа могут быть реализованы как обычно.

В статье «Поддержка множества различных политика доступа в БД»

Bertino, E., Jajodia, S. и Samarati, P. рассматривают проблему того, что все модели доступа к данным в СУБД на данный момент четко «вшиты» в программный код СУБД, и это, постепенно, становится проблемой с учетом многообразия моделей доступа, реализованных в файловых системах [143, 144]. Они рассматривают возможность создания некоторой дополнительной политики предоставления доступа (авторизации) [238].

Есть некоторые работы, посвященные ограничению доступа к записям в таблицах: [78]. Однако, они ориентированы на конкретное применение к конкретной области.

Есть разработки, посвященные расширению реляционной модели с целью внесения в нее дополнительной защищенности [257].

Пути решения На данный момент, практически «штатным» в СУБД стало ограничение доступа на объекты БД. В понятие объектов БД, обычно входят триггеры, представления пользователя, хранимые процедуры (включая пакеты и функции), последовательности, таблицы и столбцы. Запись в таблице не является объектом с точки зрения СУБД. В лучшем случае, в некоторых СУБД (Oracle, Postgres) реализованы идентификаторы записей (rowid). Ограничение доступа к записям не реализовано в силу того, что запись не является объектом БД.

Фактически, реализовать доступ к записям является довольно сложной задачей В связи с тем, что большинство приведенных выше способов ограничения доступа к записям таблиц БД основаны на выборках данных на языке SLQ, самым эффективным является использование реляционной алгебры для разграничения доступа. В качестве механизмов реализации следует взять представления пользователей, триггеры и хранимые процедуры в СУБД.

На современном рынке продуктов, основанных на БД, можно найти продукты, осуществляющие в той или иной мере ограничение доступа на уровне записей таблиц БД. Однако, нигде нет алгоритмов и формального описания проектирования таких систем защиты данных. Алгоритмы помогли бы разработчикам не «изобретая велосипеда», использовать опробованный, протестированные методы организации защиты записей в таблицах. Было бы также хорошо иметь сравнительных анализ методов, предложенных в этих алгоритмах, чтобы разработчик мог самостоятельно и осознанно выбирать то или иное решение, не производя громоздких построений и тестирования производительности. Такие алгоритмы, были, например, представлены Мейером [106].

Формализация таких методов позволит во-первых, обосновать их с научной точки зрения, выразив с помощью аппарата реляционной алгебры. Во-вторых, сильно формализованные методы могут использоваться при автоматизированной разработки схемы БД, когда разработчик выбирает необходимые или желаемые критерии, а реализация метода сразу предоставляет ему готовый код для генерации или изменения схемы БД.

Таким образом, формализация и алгоритмизация процесса разработки схемы БД является необходимой для условий развития современных информационных технологий.

1.4. Методика проектирования схем РБД на основе анализа актуальных структур хранения и данных Рассматривается подход к проектированию схем реляционных баз данных (РБД), основанный на получении дополнительной семантической информации о предметной области, получаемой на основе анализа (реинжиниринга) существовавших на момент исследования информационных систем (в части баз данных), являющихся отображением семантики предметной области, и проектировании схем новых баз данных с учетом полученной информации и дополнительных ограничений в виде ранжируемости атрибутов схемы базы данных, учитывающей распределенность данных и уровень их [11, 17].

Традиционный классический подход к проектированию схем РБД основан на следующих этапах (рассматривается упрощенная модель):

1. Анализ предметной области с определением семантических зависимостей между данными и объектами предметной области информационной системы.

2. Формализация полученных знаний.

3. Синтез схемы реляционной базы данных.

Однако на современном этапе информатизации общества крайне редко проектируемая база данных не имеет одного, либо нескольких предшественников в виде баз данных, разработанных либо для всей предметной области новой информационной системы, либо для нескольких отдельных или пересекающихся частей. Другой аспект может быть связан с изменением самой предметной области, которая могла быть модифицирована в связи с изменением законодательства, правил бизнеса, наращиванием или сокращение функционала и другое.

Любая грамотно построенная база данных должна адекватно отображать предметную область за счет корректной схемы базы данных, отражающей семантические зависимости данных в предметной области, и корректных данных, отражающих ее атрибутику.

Таким образом, проведя анализ существующих баз данных, а именно ее схемы и данных, можно получить семантические зависимости предметной области, которые позволят решить две важнейшие задачи:

1. Ускорение важнейшего этапа проектирования — анализа предметной области.

2. Верификация результатов анализа предметной области, который позволит повысить качество проектирования.

1. Предлагаемая методика проектирования схем реляционных баз данных [17] (см. рисунок 1.1) представлена набором следующих методов:

Рисунок 1.1. Диаграмма F-зависимостей исходного дочернего отношения 1. Реинжиниринг схем РБД, который на основе схемы существующей или схем существующих РБД позволяет получить формальное описание предметной области в виде множества семантических зависимостей (функциональных, многозначных и зависимостей соединения) [18-21].

2. Верификация полученного множества семантических зависимостей, которая позволит оценить соответствие схем РБД и хранящейся в ней атрибутивной информации [37, 48, 49].

3. Сравнительный анализ моделей данных, полученных в результате экспертного анализа предметной области и реинжиниринга баз данных, в результате которого получается корректное описание предметной области на формальном языке реляционной алгебры [52,53].

4. Определение дополнительных ограничений, связанных с разделением доступа к информации и традиционными методами ее защиты на уровне отношений базы данных [54, 55].

5. Проектирование схем РБД посредством алгоритмов, позволяющих учитывать дополнительные свойства атрибутов (конфиденциальность, ранжируемость и другие) [12, 13, 40, 43].

6. Модификация схем РБД для обеспечения дополнительной защиты данных на структурном уровне (например маскирование реальных данных правдоподобными, но не правильными) [22, 23, 28, 29, 30].

7. Верификация полученных схем РБД.

8. Построение окончательных схем РБД.

Рассмотрим подробнее основные этапы.

Реинжиниринг схем РБД.

Под реинжинирингом в нашем случае следует понимать получение информации о семантике предметной области на основе анализа структуры базы данных и содержащихся в ней данных. При этом информация должна быть представлена в формальном виде, в котором ее можно впоследствии использовать для проектирования схемы новой РБД.

В простейшем виде база данных r=(r1(K1,S1), r2(K2,S2), … ri(Ki,Si),..., rk(Kk,Sk), задается множеством отношений ri, характеризуемое множеством ключей Ki и множеством атрибутов Si, представляет множество функциональных зависимостей Однако в процессе реинжиниринга реальных схем РБД следует учитывать несколько аспектов, которые требуют дополнительного внимания:

- адекватность схемы РБД семантике хранящихся в ней данных;

- количество БД, необходимых для проведения реинжиниринга;

- при исследовании нескольких баз данных следует анализировать существование в них разноименных атрибутов, соответствующих одним доменам;

- правильность определения ключей в отношениях баз данных;

- возможность «отставания» структуры базы данных от текущего состояния предметной области;

- возможность выявления атрибутов, обладающих дополнительными признаками (ранжируемых атрибутов), такими как конфиденциальность, признак территориальной принадлежности для распределенных систем и другое.

Результатом реинжиниринга должна быть обобщенная модель предметной области описанная формально в терминах реляционной алгебры, что позволит в дальнейшем использовать эту модель для решения задачи проектирования новой базы данных.

Пусть дано отношение r со схемой R={A 1,A 2,...,A n }, a ij=t j (A i ), j=1,2,..., m.

Тогда заданное отношение r будет удовлетворять некоторой функциональной зависимости A i Ak, если A ( A =a ( r )) содержит не более чем один кортеж для кажk i ij дого A i -значения a, т.е.

Пусть дано отношение r со схемой R={A 1,A 2,...,A n }, a ij=t j (A i ), j=1,2,..., m.

Тогда заданное отношение r будет удовлетворять некоторой функциональной зависимости A i Ak, если A ( A =a ( r )) содержит не более чем один кортеж для кажk i ij дого A i -значения a, т.е.

Алгоритмы, реализующие реинжиниринг предложены в работах [1,2, 45-47, 51].

Алгоритмы, целью которых является выявление ограничений, связанных с ранжируемостью атрибутов, частным случаем которой может являться территориальная распределенность данных, их конфиденциальность или секретность предложены в работах [31, 32, 33, 39, 40, 42, 44].

Верификация полученного множества семантических зависимостей.

На этапе верификации полученная в терминах реляционной алгебры модель анализируется на предмет наличия аномалий, которые искажают представление моделью предметной области и делают модель не адекватной. Здесь необходимо осуществить следующие проверки:

- правильность первичных ключей имеющихся отношений;

- выявить по возможности другие ключи, присущие отношениям базы данных;

- проверить приложимость ключевых зависимостей к отношениям баз данных из которых они получены на этапе реинжиниринга;

При верификации используются два основные метода: проверка модели по множеству ограничений и проверка по данным.

С помощью прогонки табло проверяется на эквивалентность по множеству ограничений C.

В терминах эквивалентности табло для успешной проверки выводимости зависимостей соединения необходимо выполнение условия TRcTI, где TI – табло, состоящее из одной строки выделенных переменных. Буква с говорит о наличии множества всевозможных ограничений, применимых к табло. Эквивалентность T1cT2 справедлива тогда и только тогда, когда chase c(T1) chase c(T2), т.е. когда финальное табло Т1 по алгоритму прогонки chase эквивалентно финальному табло Т2.

Значит, достаточно выполнения условия chase c(TR) chase c(TI).

Но так как chase c(TI)=TI, то chase c(TR) TI.

Следовательно, необходимым и достаточным условием проверки является наличие строки выделенных элементов в chase c(TR) Алгоритмы, реализующие верификацию модели приведены в работах [48, 49, 52].

Сравнительный анализ моделей данных.

В том случае, когда одновременно ведется как системный анализ предметной области, так и реинжиниринг старых баз данных, очередной задачей становится сравнение двух полученных моделей данных. Для их успешного сравнения требуется, что бы они были формально описаны одним и тем же способом. Только тогда можно использовать алгоритмы сравнения этих моделей. Из известных способов формального описания наиболее подходящим является описание в терминах реляционной алгебры.

Перед алгоритмами сравнения стоят следующие задачи:

- выявление различий в формальном описании предметной области;

- представление различий в формальном виде, понятном для системного аналитика;

- анализ возможных причин возникновения различий;

- представление предложений по ликвидации этих различий.

В процессе сравнительного анализа следует определить причины возникновения различий, которые могут требовать различной реакции разработчика.

Не вдаваясь в подробности можно выделить основные группы причин:

1. Старые базы данных не адекватно отображали состояние предметной области.

2. Старые базы данных не учитывают динамику изменения предметной области.

3. На этапе вновь проводимого системного анализа предметной области были допущены ошибки.

Алгоритм верификации не способен однозначно выявить к какой группе причин относятся выявленные различия, однако он должен их четко и однозначно описать на своем выходе. Далее эксперт на основании своего опыта определят принадлежность ошибок к одной из групп и в соответствие с этим выполняет корректировку схемы РБД.

Относительно степени трудоемкости устранения ошибок их можно разделить на:

- легко устранимые, когда полученные при сравнении различия устраняются путем элементарных действий:

использование дополнительной декомпозиции отношений;

- отмена лишней декомпозиции;

- согласование имен атрибутов;

- трудно устранимые, когда полученные различия требуют дополнительного анализа и формальными методами практически не устраняются.

В последнем случае следует прийти к решению, связанному с определением «виновника» полученных расхождений и выбрать правильное решение.

В результате выполнения алгоритмов [53] этого этапа будет получено уточненное формальное описание предметной области, которое является основой для проектирования схемы РБД.

Определение дополнительных ограничений, связанных с разделением доступа к информации и традиционными методами ее защиты на уровне отношений базы данных.

Современные информационные системы очень чувствительны к проблеме информационной безопасности и распределенности данных. Несмотря на это существующие методики проектирования схем РБД не учитывают этот аспект и традиционно трактуют атрибуты БД как некоторую сущность не обладающую определенными свойствами, которые в процессе проектирования появляются только на этапе физического проектирования базы данных, когда атрибуту присваивается тип, размерность и так далее.

Однако уже на этапе логического проектирования возникает необходимость добавления признаков атрибутов, по которым можно будет детализировать их принадлежность к определенным отношениям, которые обособляются в отдельные отношения в силу требований к распределению доступа, либо территориальной распределенности. Такие признаки можно определить как ранжируемость атрибутов. Наличие признаков ранжируемости позволяет сформулировать дополнительные требования к проектируемой схеме РБД. Например: в одном отношении могут содержаться ранжируемые атрибуты только одного ранга или в конкретном отношении могут содержаться атрибуты не выше (ниже) определенного ранга.

Проектирование схем РБД посредством алгоритмов, позволяющих учитывать дополнительные свойства атрибутов (конфиденциальность, ранжируемость и другие).

Теперь перед проектировщиком базы данных встает задача — каким образом можно учесть дополнительные свойства атрибутов, которые позволят получить корректную базу данных, адаптированную к этим свойствам. Этого можно добиться путем модификации классических алгоритмов проектирования схем РБД. Наиболее распространенными из них являются алгоритм синтеза и алгоритм декомпозиции. На входе как одного так и другого алгоритма имеется множество семантических зависимостей, представленных в терминах реляционной алгебры, а на выходе — схемы РБД, в виде множества нормализованных отношений и множества ключей для каждого отношения. Дополнительные ограничения вводятся в виде рангов атрибутов, под которыми мы в данном случае понимаем свойства атрибутов, которое требуется отнесения атрибутов различного ранга к различным отношениям базы данных в одном случае, либо запрет размещения атрибутов более высокого ранга в отношения, содержащие ранжируемые атрибуты.

Для каждого входного ключевого атрибута Ki схемы R вводится избыточность в виде атрибутов Ki', таких что KiKi' и Ki'Ki, то есть KiKi'; KiK, Ki'K', где K – множество входных ключевых атрибутов, K' - множество атрибутов, введённых для однозначного определения ключевых входных атрибутов.

На выходе модернизированных алгоритмов буду получены схемы РБД удовлетворяющие ограничениям, накладываемым введенным дополнительным свойствам атрибутов.

Алгоритмы приведены в работе [7-9, 39-44].

Модификация схем РБД для обеспечения дополнительной защиты данных на структурном уровне (например маскирование реальных данных правдоподобными, но не правильными).

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

Если разбить субъектов маскировки на группы, которым доступ предоставлен одинаково, то, учитывая человеческий фактор, можно предположить обмен данными между такими пользователями. Пусть существуют пользователи a и b, имеющие одинаковые настройки доступа к данным:

Если данные ra и rb будут отличаться, то в производственном процессе этот факт может быть обнаружен, в результате чего пользователи смогут понять, что существует система маскировки данных, важной задачей которой является необнаружимость для пользователей.



Pages:     || 2 | 3 | 4 |


Похожие работы:

«Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования РОССИЙСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ТУРИЗМА И СЕРВИСА Ереванский филиал Кафедра Туризма и сервиса ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА на тему: Проект мероприятий по повышению эффективности стратегического управления страховой организации (на примере СЗАО “ИНГО АРМЕНИЯ”). по направлению подготовки: Экономика Студентка Манукян Татевик...»

«С.К. Дороганич, д.т.н., Ю.В. Никифоров, к.т.н. Открытое акционерное общество Научно-исследовательский и проектный институт цементной промышленности Гипроцемент РАЗВИТИЕ СУХОГО СПОСОБА ПРОИЗВОДСТВА ЦЕМЕНТА В РОССИИ. РАБОТЫ ОАО ГИПРОЦЕМЕНТ ПРОИЗВОДСТВО ЦЕМЕНТА И ПРОГНОЗ ЕГО ПОТРЕБЛЕНИЯ В МИРЕ Начало ХХI века характеризовалось значительным ростом производства цемента и его потребления. С 2001 г по 2009 г объем производства цемента возрос с 1740 млн. тонн до 2960 млн. тонн. Лидером производства...»

«ИНВЕСТИЦИОННЫЙ ПАСПОРТ ПЕРВОМАЙСКОГО РАЙОНА Николаев -2014 Стратегической целью развития Первомайского района является повышение уровня жизни населения и выход на качественно новые социальные стандарты путем широкомасштабного эконимического возрастания и действенной инвестицинной политики. 1. Название района: Первомайский. Административное устройство: 1 споселок и 20 сельских советов. 2. Органы власти в компетенцию которых входит внедрение инвестиционных проектов: Первомайская районная...»

«Euronest Parliamentary Assembly Assemble parlementaire Euronest Parlamentarische Versammlung Euronest Парламентская Aссамблея Евронест Комитет по социальным делам, образованию, культуре и гражданскому обществу Протокол заседания 2 апреля 2012 г. Баку Заседание открыли в 15:30 сопредседатели Лайма Люция Андрикене и Артак Закарян. 1. Утверждение проекта повестки дня Проект повестки дня утверждён. 2. Утверждение протокола заседания Комитета по социальным делам, образованию, культуре и гражданскому...»

«2014 г. Инвестиционный паспорт Шекснинского муниципального района Дорогие дамы и господа! Шекснинский муниципальный район - один из перспективных муниципальных образований Вологодской области. По территории Шексны и района проходят автомагистраль Вологда-Новая Ладога, Северная железная дорога и Волго-Балтийский путь. Выгодное географическое расположение, красивейшая природа, благоприятный климат помогает нам сохранять статус привлекательного для инвесторов района. Этому способствует активная...»

«2 3 1. Цели освоения дисциплины Целями освоения дисциплины Основы проектирования являются: изучение основ организации и выполнения проектирования химических производств, обоснования района размещения проектируемого производства, порядка формирования и содержание задания на проектирование, основных этапов проектирования; получение навыков в выполнении технико-экономического обоснования площадки для строительства и технологической схемы производства целевого продукта; ознакомление с методикой...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ ДАЛЬНЕВОСТОЧНЫЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ИНСТИТУТ ХИМИИ И ПРИКЛАДНОЙ ЭКОЛОГИИ В.А. Реутов Требования к оформлению письменных работ, выполняемых студентами Института химии и прикладной экологии ДВГУ Владивосток Издательство Дальневосточного университета 2010 ББК 74.58 Р31 Реутов, В. А. Р31 Требования к оформлению письменных работ, выполняемых студентами Института химии и...»

«2 1. Цели освоения дисциплины В соответствии с учебным планом подготовки специалистов по направлению 130400 Горное дело учебная дисциплина Горнопромышленная экология изучается в 10-м семестре. Предметом изучения данной дисциплины является экологическая стратегия и политика развития производства, а также характерные экологические проблемы производства и пути их решения. Целью изучения дисциплины является: - формирование у студентов способности действовать в соответствии с принципами научного...»

«1 2 1. Цели освоения дисциплины. Целями освоения дисциплины Буровые станки и бурение скважин являются расширение, углубление знаний, определяемых базовыми дисциплинами, подготовка специалиста к успешной производственно-технологической профессиональной деятельности (ПТД). Специалист должен на основе отечественной и зарубежной научно-технической информации знать технические и конструктивные особенности современных горных машин и оборудования для механизации операций технологических процессов...»

«658.382.3:621.31.004.2 ПРАВИЛА ТЕХНИЧЕСКОЙ ЭКСПЛУАТАЦИИ ЭЛЕКТРОУСТАНОВОК ПОТРЕБИТЕЛЕЙ И ПРАВИЛА ТЕХНИКИ БЕЗОПАСНОСТИ ПРИ ЭКСПЛУАТАЦИИ ЭЛЕКТРОУСТАНОВОК ПОТРЕБИТЕЛЕЙ РЕСПУБЛИКИ КАЗАХСТАН (издание переработанное и дополненное с учетом опыта эксплуатации действующих электроустановок потребителей) РАЗРАБОТАНЫ: ТОО Фирма Казэнергоналадка и Союзом инженеров-энергетиков при участии научно-исследовательских, проектных, эксплуатационных, ремонтных и наладочных организаций Республики Казахстан....»

«Общество детских врачей – Союз педиатров России 19 2 7– 2 0 0 9 Москва 2009 Buklet_SPR_120-polos_BLOK_coll.i1 1 10.02.2009 21:45:13 Союз педиатров России – одно из старейших профессиональных объединений медиков страны. Его история восходит к далекому 1912 году, когда состоялся I Съезд детских врачей России, а в 1927 году произошло юридическое оформление – было создано общество детских врачей Советского Союза. Вся история нашего Союза – это пример беззаветного служения благороднейшему делу –...»

«В этом номере: 1 Решение Городской Думы города Таганрога от 31.05.2012 № 431 стр. 2 Об утверждении результатов публичных слушаний по проекту отчета об исполнении бюджета муниципального образования Город Таганрог за 2011 год 2 Решение Городской Думы города Таганрога от 31.05.2012 № 432 стр. 7 Об утверждении отчета об исполнении бюджета муниципального образования Город Таганрог за 2011 год 3 Решение Городской Думы города Таганрога от 31.05.2012 № 433 стр. 71 Об информации о ходе исполнения...»

«М ИНИ СТЕРСТВО ЭН ЕРГЕТИ КИ РО ССИ ЙСКОЙ Ф ЕДЕРАЦИИ РОССИ ЙСКАЯ АКАДЕМ ИЯ НАУК Н А У Ч Н О -И С С Л Е Д О В А Т Е Л Ь С К И Й И Н С Т И Т У Т Г О РН О Й Г Е О М Е Х А Н И К И И М А Р К Ш Е Й Д Е Р С К О Г О Д ЕЛ А М Е Ж О Т РА С Л Е В О Й Н А У Ч Н Ы Й Ц Е Н Т Р - ВНИМИ ГОРНАЯ ГЕОМЕХАНИКА И МАРКШЕЙДЕРСКОЕ ДЕЛО Сборник научных трудов С анкт-П етербург 2009 Горная геомеханика и маркшейдерское дело : сборник научных трудов. - С П б.: ВН И М И, 2009. - 252 с. В статьях настоящего юбилейного...»

«Тюменская областная Дума Проблемы и перспективы развития пчеловодства в Тюменской области Материалы совещания 29 сентября 2010 года Тюмень, 2010 Проблемы и перспективы развития пчеловодства в Тюменской области. Материалы совещания, 29 сентября 2010 года / под ред. А.Н. Борисова. – Тюмень : Тюменская областная Дума, 2010. – 48 с. Составитель: Збанацкий О.В. Фото обложки: Збанацкий О.В. В сборник включены стенограмма совещания, а также информационные материалы, посвящённые актуальным вопросам...»

«Проект по технологии Одежда для отдыха Выполнили: Васильченко Татьяна Оненко Екатерина. 8 А класс Руководитель: Крицкая Елена Николаевна. МОУ гимназия №7 Хабаровск 2008 Обоснование возникшей проблемы и потребности Скоро наступит лето, мы поедем на море и хочется надеть что-то новое. Мы просмотрели журналы мод, походили по магазинам, но не нашли ничего, что бы нам понравилось, и мы решили сшить себе одежду для отдыха сами. Определение конкретной задачи и её формулировка Когда мы обосновали...»

«1 В.А.Воинов ЭФФЕРЕНТНАЯ ТЕРАПИЯ МЕМБРАННЫЙ ПЛАЗМАФЕРЕЗ Издание пятое переработанное и дополненное МОСКВА 2009 2 ББК 53.53 В 65 УДК 616-085.23/.27+615.382 Рецензент: М.М.Илькович, д-р мед. наук, профессор, директор НИИ пульмонологии СПбГМУ имени акад. И.П.Павлова. Утверждена решением Проблемной комиссии Минздрава России “Пульмонология” Воинов В.А. В 65 Эфферентная терапия. Мембранный плазмаферез. Издание пятое, переработанное и дополненное. – М., Новости, - 2009. – 304 с., илл. ISBN...»

«Проект Tacis ENVRUS 9704 План развития национального парка Паанаярви Арто Ахокумпу, Йоуко Хогмандер, Матти Мяятта, Тату Оликайнен Консорциум Metshallitus Consulting Oy, Kampsax International, Indufor Oy, Finnish Environmental Institute Петрозаводск 2001 2 Содержание Реферат 4 Введение 6 1. Описание НП Паанаярви 7 Природа парка 7 Населенные пункты вокруг оз. Паанаярви 9 Развитие туризма в районе Паанаярви 10 2. Общий обзор деятельности НП Паанаярви Планы и положения Основные направления...»

«ЗАКОНОДАТЕЛЬСТВО ЗАК ОН БРЯНСКОЙ ОБЛАСТИ О ВНЕСЕНИИ ИЗМЕНЕНИЙ В ЗАКОН БРЯНСКОЙ ОБЛАСТИ О ПОРЯДКЕ НАЗНАЧЕНИЯ ПРЕДСТАВИТЕЛЕЙ ОБЩЕСТВЕННОСТИ В КВАЛИФИКАЦИОННУЮ КОЛЛЕГИЮ СУДЕЙ БРЯНСКОЙ ОБЛАСТИ ПРИНЯТ БРЯНСКОЙ ОБЛАСТНОЙ ДУМОЙ 31 ЯНВАРЯ 2013 ГОДА Статья 1. Внести в Закон Брянской области от 5 августа 2002 года № 53-З О порядке назначения представителей общественности в квалификационную коллегию судей Брянской области (в редакции законов Брянской области от 6 марта 2009 года № 16-З, от 9 ноября 2009...»

«Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования РОССИЙСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ТУРИЗМА И СЕРВИСА факультет Управления и дизайна Кафедра управления персоналом и государственного и муниципального управления ДИПЛОМНЫЙ ПРОЕКТ на тему: Совершенствование деятельности органов муниципального управления по формированию и реализации молодежной политики (на примере г. о. Балашиха Московской...»

«1 История кафедры КиПРА – ИТПУ: как это было. УДК 387 (091) ББК 74.58 г Б 90 Б 90 Булкин, В.В. История кафедры КиПРА – ИТПУ: как это было.: моногр. / В.В. Булкин.– Муром: Изд.-полиграфический центр МИ ВлГУ, 2009.– 92 с.: ил. (6 цв. вкл.).– Библиогр.: 43 назв.– (Страницы летописи Муромского института). ISBN 978-5-8439-0182-0 Представлено жизнеописание кафедры конструирования и производства радиоаппаратуры (КиПРА) – информационных технологий в проектировании и управлении (ИТПУ) Муромского...»






 
2014 www.av.disus.ru - «Бесплатная электронная библиотека - Авторефераты, Диссертации, Монографии, Программы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.