Содержание

Введение        

Глава 1. Анализ классического метода и CASE-средств проектирования логической структуры реляционной БД        

1.1 Классический метод проектирования логической структуры реляционной БД, основанный на ER-модели        

1.2 Анализ классического метода        

Глава 2. Метод проектирования логической структуры реляционной  БД.        

2.1. Описание метода        

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

2.3. Следствие 1. О добавлении новых атрибутов        

2.4. Следствие 2. Проводить нормализацию таблиц не требуется        

2.5. О денормализации в контексте предлагаемого метода проектирования        

2.6. Предложенный метод и пятая нормальная форма        

2.7. Сравнение классического метода с предложенным        

2.8 Проверка имеющейся структуры БД на соответствие предметной области        

2.9. Результаты        

Заключение        

Список использованной литературы        

Введение

Дисциплины по проектированию реляционных баз данных читаются во многих российских ВУЗах, которые готовят специалистов в области информационных технологий. Однако, подавляющее большинство веб-разработчиков либо не знакомы с классической теорией проектирования баз данных, либо не используют строго метод нормализации таблиц. Отчасти это связано с тем, что большинство веб-сайтов с динамическими веб-страницами и программной частью являются достаточно простыми приложениями и не являются тиражированным программным продуктом. Ф. Брукс объясняет существенную разницу между программой и полноценным программным продуктом, который полностью оттестирован, документирован, легко переносим с одного компьютера на другой и т.д. Гради Буч в качестве примера простого и сложного проектов приводит строительство собачьей конуры и небоскреба. Аналогично дело обстоит и с веб-сайтами, но с тем исключением, что небоскребы все-таки строят специалисты с высшим образованием и соответствующим опытом работы, а веб-сайты разрабатываются часто неквалифицированными специалистами. Примеров, когда веб-сайты не выдерживают нагрузки, подвергаются взлому или функционально плохо соответствуют своим задачам достаточно много. Такая ситуация, во-первых, обусловлена рынком, где заказчики, не являясь специалистами, ищут наиболее дешевые предложения по разработке информационных систем. Во-вторых, присутствует и техническая составляющая. В процессе проектирования структуры реляционной СУБД у проектировщика есть только один объективный критерий оценки проекта – это соответствие всех таблиц в БД пятой нормальной форме (5НФ). Но если все таблицы находятся в 5НФ, то количество таблиц в базе данных максимально возможное. А в этом случае, падает производительность ИС, т.к. выборка данных из нескольких таблиц происходит медленнее, чем из одной. И растет стоимость разработки ИС.

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

Проектирование логической структуры реляционной базы данных осуществляется на основе модели «сущность-связь» П. Чена  или расширенной реляционной модели Э. Кодда. Методы проектирования описаны в работах П. Чена, Э. Кодда, К. Дж. Дейта, Р. Фагина, Д. Кренке, Г. Гарсиа-Молина  и др.  Данные модели «сущность-связь» не имеют формальных определений сущности и атрибута сущности, а также не учитывают функциональных требований к ИС на стадии проектирования. Для каких-то приложений, возможно, такой подход и является правильным, когда мы абстрагируемся от операций над данными и моделируем только сами данные. Например, когда функциональные требования заранее не известны, и ИС постоянно пополняется новыми функциональными требованиями. Но для веб-приложений основой являются функциональные требования к ним, описанные в техническом задании (ТЗ). На основе технического задания происходит оценка стоимости проекта. И если делать структуру БД на все случаи жизни без учета конкретных функциональных требований, то будет расти и стоимость проекта.

Глава 1. Анализ классического метода и CASE-средств проектирования логической структуры реляционной БД

1.1 Классический метод проектирования логической структуры реляционной БД, основанный на ER-модели

В настоящее время классический метод проектирования логической структуры реляционной БД основывается на модели «сущность-связь» П. Чена, или расширенной модели «сущность-связь» Э. Кодда, нормальных формах таблиц, процессе нормализации таблиц. Определения нормальных форм таблиц основываются на функциональных зависимостях (ФЗ) и многозначных функциональных зависимостях (МФЗ).  

Прежде чем привести определения ФЗ и МФЗ необходимо ввести следующие определения.

Определение №1.1 допустимой записи в таблице с точки зрения предметной области. Запись r является допустимой для таблицы R* с точки зрения предметной области, если данная запись соответствует некоторому допустимому объекту или факту предметной области. Например, компьютер стоимостью 10 000 рублей – допустимый факт предметной области, а компьютер стоимостью -100 (минус сто) рублей или сотрудник фирмы в возрасте 200 лет не являются допустимыми объектами и фактами предметной области.

Определение №1.2 допустимой записи в таблице с точки зрения структуры БД. Запись r является допустимой для таблицы R* с точки зрения структуры БД, если операция вставки (INSERT) записи r в R* выполнится успешно, т.е. данная операция не нарушает ограничений целостности БД, которые заданы в виде типов данных таблицы R, ссылочной целостности по внешним ключам, триггеров, транзакций и любых других ограничений целостности БД, которые поддерживает СУБД.

Определение №1.3 допустимой записи в таблице. Запись r является допустимой для таблицы R*, если она допустима для R согласно определениям 1.1 и 1.2.

Определение функциональной зависимости 

Подмножество Y множества атрибутов отношения (таблицы) R реляционной БД функционально зависит от подмножества атрибутов X таблицы R тогда и только тогда, когда для любых допустимых кортежей (записей)  в R верно следующее утверждение: если эти кортежи совпадают по значениям атрибутов X, то они также совпадают по значениям атрибутов Y. В символическом виде записывается как X → Y (читается как "X функционально определяет Y").

Определение многозначной функциональной зависимости

Пусть R – переменная отношения, а А, В и С являются произвольными подмножествами множества атрибутов переменной отношения R. Тогда подмножество В многозначно зависит от подмножества А, что выражается следующей записью

А→→В

(читается как «А многозначно определяет В» или «А двойная стрелка В»),  тогда и только тогда, когда в каждом допустимом значение R множество значений В, соответствующее заданной паре А, С, зависит только от значения А и не зависит от значения С.

В работе Рональда Фагина  показано, что многозначная зависимость А→→В выполняется тогда и только тогда, когда выполняется А→→С, поэтому многозначные зависимости также обозначают А→→В | C.

Определения нормальных форм (НФ)

Первая нормальная форма: любая таблица в реляционной БД находится в 1НФ.

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

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

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

Рональд Фагин, ввел  понятия 4й и 5й нормальных форм, которые основываются на многозначной зависимости и зависимости соединения.

Определение 4НФ. Переменная отношения R находится в четвертой нормальной форме (4НФ) тогда и только тогда, когда в случае существования таких подмножеств А и В атрибутов этой переменной отношения R, для которых выполняется нетривиальная многозначная зависимость А→→В, все атрибуты переменной отношения R также функционально зависят от атрибута А.

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

Декомпозиция таблицы на две таблицы осуществляется на основании теорем Хита и Р. Фагина.

Теорема Хита (Heath I. J.). Пусть R{A, B,  C} является переменной отношения, где A, B и C – множества атрибутов этой переменной отношения. Если R удовлетворяет функциональной зависимости A → B, то R равна соединению ее проекций по атрибутам {A, B} и {A, C}.

Теорема Рональда Фагина (R. Fagin).  Пусть A, B и C являются множествами атрибутов переменной отношения R{A, B,  C}. В таком случае переменная отношения R будет равна соединению ее проекций по атрибутам {A, B} и {A, C} тогда и только тогда, когда для переменной отношения R выполняется многозначная зависимость А→→В | C.

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

1.2 Анализ классического метода

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

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

Рассмотрим пример системы учета посетителей веб-сайта, где имеются следующие данные предметной области:

1. it_date — дата посещения;
2. referer — веб-страница с  которой пришли на сайт;
3. url — веб-страница сайта, которую загрузили;
4. visitor_id — идентификатор посетителя;
5. http_user_agent — информация, которую передает браузер о себе;
6. os — операционная система (ОС) посетителя;
7. browser — браузер посетителя;
8. browser_ver — версия браузера;
9. screen_w — разрешение экрана по горизонтали посетителя;
10. screen_h  — разрешение экрана по вертикали;
11. depth — глубина цвета;
12. cookie — наличие Cookie;
13. java — наличие java;
14. js — версия js;
15. lang — язык браузера;
16. ip посетителя — один и тот же посетитель может зайти с разных IP-адресов, например, у него ноутбук;
17. ip_country — страна (определяется на основании IP-адреса);
18. ip_city  — город (определяется на основании IP-адреса);

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

Один из n элементов → один из n-1 элементов, n-1 права, т.к. функциональная зависимость А→А является тривиальной. Количество таких выборок будет =n*(n-1)

Далее мы должны рассмотреть выборки, где в левой части будет уже два элемента из n, а в правой будем выбирать любой элемент из n-2. Количество таких выборок будет  

и т.д. до

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

1. visitor_id → cookie (причем cookie есть, т.к. иначе не будет определен visitor_id)

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

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

2. {it_data, referer, url} → visitor_id (В один и тот-же момент времени с сайта yandex.ru/search... на сайт itsoft.ru может придти два разных посетителя, например, Иванов и Петров. Хотя, на практике маловероятно, что они зайдут в одну и ту же секунду.)
3. visitor_id → {os, browser, browser_ver, screen_w, screen_h, ip, java, javascript} (Пользователь может обновить ОС с сохранением всех параметров. Пользователь также может обновить браузер и импортировать Cookie, если обладает навыками. Рядовой пользователь этого не сделает. Еще пользователь может поменять разрешение экрана в случае покупки нового монитора. Пользователь может сменить IP-адрес, особенно, если у него мобильный персональный компьютер или провайдер меняет ему IP раз в сутки. Он может отключить поддержку javascript, java и т.д.)
   Возникает вопрос: что делать в данной ситуации? Строго говоря, согласно канонической теории проектирования реляционных БД — ничего. Процесс нормализации закончился. Интуитивно понятно, что имеется большая избыточность данных. Зато можно получить отчет по посетителям, которые меняли разрешения экрана, ОС, заходили с разных IP-адресов. Другой вопрос, что нужны ли эти отчеты? Несут ли они полезную информацию для пользователей системы учета посетителей сайта? Что важнее иметь данные отчеты и избыточность данных, или же перепроектировать структуру БД?

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

В рассмотренном примере со счетчиком посетителей в зависимости от того примет проектировщик функциональную зависимость  visitor_id → ip или нет, качественным образом меняется структура БД и функциональность системы статистики.

Глава 2. Метод проектирования логической структуры реляционной БД.

2.1. Описание метода

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

1. Анализ;

1. Определение образа, границ проекта;
2. Выявление классов пользователей (действующих лиц);
3. Выявление нефункциональных требований;
4. Идентификация функциональных требований;
5. Идентификация бизнес-правил;
6. Построение отдельных диаграмм анализа требований, дополняющих предыдущие пункты: потоков данных, перехода состояний, диаграммы деятельности, блок-схемы высокого уровня, карты диалогов;
7. Тестирование требований. Согласование технического задания.
8. Идентификация классов сущностей;
9. Идентификация связей (отношений) между классами сущностей;
10. Обобщение классов сущностей (идентификация базовых классов);
11. Построение концептуальной схемы БД;

2. Проектирование;

1. Проектирование таблиц;
2. Проектирование ограничений целостности:

1. пользователей БД;
2. виртуальных таблиц;
3. индексов;
4. диапазонов доступных значений;
5. ссылочной целостности;
6. триггеров;
7. транзакций.

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

Классы пользователей играют очень важную роль в разграничении полномочий и в безопасности программного обеспечения.

Функциональные требования и описание данных очень удобно записывать в виде ненумерованных иерархических списков. Хотя можно и в виде нумерованных, но тогда нумерация должна быть кратна 100, чтобы можно было всегда вставить новое функциональное требование между двумя функциональными требованиями без изменения их нумерации.  На первом уровне иерархического списка функциональных требований располагаются действующие лица системы. На втором уровне желательно располагать модули или сущности системы. Модуль, как правило, включает в себя несколько сущностей. На третьем уровне внутри модуля располагаем сущности. Если функциональное требование относится к нескольким сущностям, например, экспорт данных, то смысла перечислять на третьем уровне все сущности нет и, поэтому на третьем уровне расположим функциональные требования. На четвертом уровне внутри сущности должны быть сформулированы функциональные требования.  Если модуль содержит ровно одну сущность, например, меню или новости (в этом случае имя модуля и имя сущности, как правило, совпадают), то их можно совместить на втором уровне, т.е. на третьем уровне будут указаны функциональные требования. Цветом в иерархическом списке функциональных требований можно делать наглядные отметки характеризующие статус требования: черновик, утверждено, спроектировано, реализовано, протестировано, отображено в документации пользователя, внедрено, сдано заказчику. Тем не менее, записывать функциональные требования можно и в виде линейного списка. Но это уже дело вкуса и удобства каждого проектировщика.

Функциональные требования с более высоким приоритетом располагаем в начале (вверху) списка. С более низким – в конце.

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

Важным моментом является окончание сбора функциональных требований и понимание, что уже выявлены почти все требования. Совсем все требования выявить не удастся никогда, в ходе проектирования, реализации, тестирования, внедрения и эксплуатации продукта будут появляться невыявленные требования. Критерием того, что следует остановиться является низкое соотношение количества вновь выявляемых требований со средним и высоким приоритетом в единицу времени.  За единицу времени можно взять 1-5 дней или промежуток времени между плановыми встречами с заказчиком. Низким порогом  или хорошей точностью при измерениях является стабильность и уверенность в первых двух значимых (ненулевых) знаках. Тем самым можно предложить следующую формулу:

(Nfnew / Nf) < 0.01,                        (2.1)

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

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

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

Следующим этапом будет выявление связей между классами сущностей. Это довольно рутинный процесс. Самое главное мы уже сделали – это идентифицировали классы сущностей, теперь даже если пропустить какую-либо связь, то ее всегда можно будет безболезненно добавить, т.к. добавление новой связи − это добавление внешнего ключа в таблицу. Напомним, что от связей «многие ко многим» мы избавились превратив их в сущности, и они уже все идентифицированы. Можно рутинно пройти по каждому классу сущности и установить все его связи. Большинство связей определяются интуитивно. Но для того, чтобы процесс был формальным и, чтобы не пропустить каких-либо связей, определим строгий алгоритм идентификации связей. Для каждого функционального требования типа SELECT нужно установить список классов сущностей, с которым оно работает. Затем отобрать функциональные требования, которые связаны более чем с одним классом сущностей. Каждое такое требование порождает n-1 связей между двумя классами сущностей типа «один ко многим», где n – это количество классов сущностей приписанных функциональному требованию.

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

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

Полученная концептуальная схема БД очень близка к логической схеме реляционной БД. Во многих учебных пособиях такая концептуальная схема в точности переходит в логическую – сущности переходят в таблицы, а связи во внешние ключи. Идя таким коротким путем, мы рискуем получить не самый оптимальный вариант логической структуры реляционной БД с точки зрения принципа повторного использования кода. Для того, чтобы можно было обобщить и параметризовать код с одинаковым поведением, этот код должен работать с одинаковыми структурами данных. Для этого нужно провести процесс обобщения классов сущностей. Классы сущностей, которые находятся в отношении «родитель-потомок» перейдут в одну и туже таблицу при проектировании логической структуры реляционной БД.

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

Исключения составляют случаи, связанные с производительностью или безопасностью. Если классы сущностей r1 и r2 являются дочерними классами r0, но при этом в таблице для r2 будет храниться записей на порядки больше, чем в таблице для r1 и количество обращений разное или же разный уровень безопасности требуется соблюсти, то уместно создавать для r1 и r2 разные таблицы в БД. В Стив Макконел отмечает, что: «Наследование повышает сложность программы и в этом смысле оно может быть опасным». Наследование в первую очередь служит для удобства разработчиков за счет повторного использования кода. Но, как известно, удобство обратно пропорционально безопасности – это, так сказать, обратная сторона медали. В реляционной СУБД MySQL разграничение доступа к данным происходит на уровне таблиц и если базовая сущность и дочерняя хранятся в одной таблице, то нет возможности стандартными средствами СУБД настроить к ним разный уровень доступа. Можно, конечно, воспользоваться триггерами, но это кривое решение, которое может сказаться на производительности. В проектах с повышенной безопасностью  придется каждую сущность хранить в отдельной таблице. Буч в четвертой главе  описывает методы классификации, но там же говорится о том, что нет каких либо четких правил и алгоритмов по выявлению базовых классов.

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

В заключении данного параграфа изложим предложенный метод по шагам.

1. На основании ТЗ составляем список ФТ в виде: подлежащее сказуемое определение. Где подлежащее соответствует классу пользователя (отвечает на вопрос кто или что). Сказуемое соответствует действию выполняемому в рамках ФТ (отвечает на вопрос что делает). Определение соответствует объекту над которым выполняется действие.
2. На этапе анализа преобразуем список ФТ к виду ft{userclass, time, cost, status, prior, executive, type, tables, text}. В ходе данного преобразования выполняется декомпозиция каждого ФТ до атомарного состояния. Сложное ФТ не возможно привести к заданному виду, т.к. невозможно определить его тип. Массив tables содержит ровно один элемент (имя таблицы) для требований типа INSERT, UPDATE, DELETE, ALTER1. Для типа SELECT может быть более одной таблицы в массиве tables.
3. Основной цикл алгоритма.
   //Для каждого ФТ типа INSERT создать таблицу, если только соответствующая таблица не была создана ранее на основе другого ФТ типа INSERT.

for(i=0;i if(ft[i].type==INSERT && ft[i].tables[0] отсутствует  в списке dbtables[])
 dbtables[]=ft[i].tables[0];
Алгоритм определения наличия таблицы ft[i].tables[0] в списке dbtables[] можно записать в следующем виде:

bool isTableinDB(t, dbtables)

{for(k=0;k

 if(структура t совпадает с dbtables[k] &&

набор ФТ заданных для t совпадает c набором ФТ заданных для dbtables[k])  return TRUE; //таблица присутствует в списке return FALSE; //таблица в списке отсутствует}

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

4. Для каждого ФТ прочих типов установить связь с полученными таблицами, к которым они относятся. Если какое-то ФТ осталось не связанным ни с одной таблицей, то вернуться на этап анализа и выявить отсутствующие ФТ типа INSERT и перейти к пункту №3.

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

SELECT * FROM it_entity LEFT JOIN it_fr_entity ON id=entity_id WHERE fr_id IS NULL AND project_id=$project_id

Функциональные требования типа Insert несвязанные ни с одной сущностью получаем при помощи следующего запроса:

SELECT * FROM it_fr LEFT JOIN it_fr_entity ON id=fr_id WHERE type='Insert' AND entity_id IS NULL AND module_id IN (SELECT id FROM it_module WHERE project_id=$project_id)

5. Для каждой таблицы установить набор атрибутов и первичный ключ.

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

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

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

Пусть A, B, K, X атрибуты таблицы R*. Аномалия модификации данных возникает в следующих случаях:

1. В R* нет первичного ключа. Аномалия редактирования и удаления данных в случае наличия двух кортежей с одинаковыми значениями, но описывающими разные объекты предметной области (Таблица не находится в 2НФ.).
2. A U B образуют первичный ключ R* и есть функциональное требование, которое реализуется операцией INSERT R* (A, X) VALUES(a0, x0). (Таблица либо не находится в 2НФ, либо находится в 3НФ, но не в НФБК.).
3. K — первичный ключ R*, A и B неключевыe атрибуты и есть функциональное требование, которое реализуется операцией INSERT R* (A, B) VALUES(a0, b0). (Таблица находится в 2НФ, но не находится в 3НФ.)
4. A U B U K образуют первичный ключ R* и есть функциональное требование, которое реализуется операцией INSERT R* (A, B) VALUES(a0, b0).

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

 Утверждение 1. Аномалии модификации данных в логической структуре реляционной БД спроектированной на основе предложенной усовершенствованной модели  «сущность-связь» предметной области отсутствуют.

 Доказательство. Согласно выявленным случаям аномалий модификации данных  следует рассмотреть четыре случая.

Первый случай (таблица не находится в 2НФ) отпадает ввиду обязательности наличия первичного ключа.

Второй, третий и четвертый случаи невозможны для структуры реляционной БД полученной на основе усовершенствованной модели «сущность-связь» согласно определениям сущности, класса сущности и предложенному методу проектирования.

Рассмотрим второй случай (таблица либо не находится в 2НФ, либо находится в 3НФ, но не в НФБК.) —  A U B образуют первичный ключ в R* и есть функциональное требование, которое реализуется операцией INSERT R* (A, X) VALUES(a0, x0). Но если у нас имеется ФТ, которое реализуется данной операцией, то на четвертом шаге нашего метода будет создана соответствующая таблица. Следовательно выполнение данной операции станет возможным и аномалии модификации данных не возникнет.  

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

2.3. Следствие 1. О добавлении новых атрибутов

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

Доказательство. При доказательстве утверждения 1 рассматривались произвольные атрибуты A, B, K, X некоторого класса сущности. Следовательно, при добавлении некоторого атрибута N  к классу сущности, реализацией которого является R* и замене в доказательстве утверждения №1 любого атрибута A, B, K, X на N доказательство  остается справедливым.

2.4. Следствие 2. Проводить нормализацию таблиц не требуется

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

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

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

В главе не описан процесс проектирования ограничений целостности, но он ничем не отличается от существующего в классическом методе проектирования.

2.5. О денормализации в контексте предлагаемого метода проектирования

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

2.6. Предложенный метод и пятая нормальная форма

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

1. либо две бинарные связи;

2. либо три бинарные связи;

3. либо одну тернарную связь.

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

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

2.7. Сравнение классического метода с предложенным

Таблица 2.1.

Сравнение классического метода с предложенным

2.8 Проверка имеющейся структуры БД на соответствие предметной области

1. В каждой таблице должен быть задан первичный ключ.
2. На основании этапа анализа отобрать список функциональных требований к ИС, которые работают с БД.
3. Провести декомпозицию каждого функционального требования до атомарного состояния.
4. Определить тип каждого функционального требования (SELECT, INSERT, UPDATE, DELETE, ALTER1, ALTER2, ALTER3).
5. Для каждого ФТ типа INSERT установить связь с соответствующей таблицей в БД. Если такой таблицы нет, то нужно создать таблицу и связать ее  с данным ФТ.
6. Для каждого ФТ прочих типов установить связь с таблицами, к которым они относятся. Если какое-то ФТ осталось не связанным ни с одной таблицей, то вернуться на этап анализа и выявить отсутствующие ФТ типа INSERT и перейти к пункту №5.

2.9. Результаты

1. Метод проектирования реляционной структуры БД на основе усовершенствованной модели «сущность-связь» является более формализованным по сравнению с классическим методом на базе моделей «сущность-связь» П. Чена и расширенной моделью «сущность-связь» Э. Кодда, т.к. позволяет формально четко разграничить классы сущностей и их атрибуты, что позволяет избежать аномалий модификации данных.
2. Два проектировщика БД используя предложенный метод получат практически одинаковые структуры БД на основе выявленных на стадии анализа функциональных требований и бизнес-правил.
3. Метод на основе усовершенствованной модели «сущность-связь» является менее трудоемким, чем классический метод, т.к. проводить процесс нормализации таблиц больше не требуется.
4. Таблицы полученные на основе усовершенствованной модели «сущность-связь» в контексте заданных функциональных требований не имеют аномалий модификации данных. Другими словами таблицы обладают необходимым уровнем нормализации в контексте заданных функциональных требований. На основе полученных результатов необходимо разработать CASE-средство DBDesigner для автоматизации процесса проектирования логической структуры реляционной БД.

Заключение

При проектировании базы данных решаются две основных проблемы:

1. Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области и было по возможности лучшим (эффективным, удобным и т.д.)? Часто эту проблему называют проблемой логического проектирования баз данных.

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

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

Список использованной литературы

1. Дейт К. Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом "Вильямс", 2006. — 1328 с.
2. Д. Кренке Теория и практика построения баз данных. 9е изд. — СПб.: Питер, 2005  — 859 с.
3. Г. Гарсиа-Молина и др. Системы баз данных. Полный курс. — М.: Издательский дом "Вильямс", 2004. — 1088 с.
4. Джен Л. Харрингтон Проектирование реляционных баз данных — М.: Издательство «Лори», 2006 — 230 с.
5. Тарасов И. А., Проблемы качественного проектирования БД на базе классического метода: Качество Инновации Образование. М: Номер 3 (34), март 2008, с. 51-56.
6. Вигерс Карл Разработка требований к программному обеспечению — М.: Издательско-торговый дом «Русская редакция», 2004 — 576 с.
7. Тарасов И. А., Усовершенствованная ERT-модель сущность-связь: Качество Инновации Образование. М: Номер 6 (37), июнь 2008, с. 47-50.
8. Джексон Г. Проектирование реляционнных баз данных для использования с ЭВМ: Перевод с английского. М.: Мир, 1991.
9. Тарасов И. А., Метод проектирования логической структуры реляционной БД на основе ERT-модели: Качество Инновации Образование. М: Номер 4 (35), апрель 2008, с. 47-50.
10. Тарасов И. А., Проблемы качественного проектирования БД на базе классического метода: Качество Инновации Образование. М: Номер 3 (34), март 2008, с. 51-56.