Построение информационно-логической модели данных
Инфологическая модель применяется на втором этапе проектирования БД, то есть после словесного описания предметной области. Процесс проектирования длительный, он требует обсуждений с заказчиком, со специалистами в предметной области. Инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет «читаться» не только специалистами по базам данных. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД, и конечно, как говорилось раньше, оно не должно быть привязано к конкретной СУБД.
Инфологическое проектирование, прежде всего, связано с попыткой представления семантики предметной области в модели БД. Реляционная модель данных в силу своей простоты и лаконичности не позволяет отобразить смысл предметной области.
Рассмотрим проектирование БД на примере предметной области «Оргтехника».
Пусть необходимо построить базу данных, содержащую информацию о системе учета сборки изделий:
· перечень поставщиков;
· список служащих;
· сведения о движении товаров.
На основании анализа предметной области мы выделили следующие сущности модели «сущность-связь» («Entity Relationship» - ER-модели): «Поставщики», «Служащие», «Товар», «Движение товара».
На основании внимательного анализа предметной области можно выделить следующие сущности модели “сущность-связь”: «Движение товара», «Поставщик», «Служащие», «Товар», «Поставка фирме», «Поставщик», «Служба доставки», «Счет», «Товары» (рисунок 2).
| Движение товара Код товара Код служащего Код движения товара Код поставщика Вид движения товара Оптовая цена закупки Розничная цена продажи | Поставщик Код поставщика Код товара Фамилия Имя Отчество Телефон Адрес | Товар Код товара Вид Цена Количество | Служащие Код служащего Фамилия Имя Отчество Адрес Телефон Должность Зарплата Образование |
Рис.2 - Сущности модели
Между выделенными сущностями можно выделить, например, следующие связи:
. Поставщики поставляют товар.
. Служащие принимают товар.
Если понимать язык условных обозначений, которые соответствуют категориям ER-модели, то ее можно легко «читать», следовательно, она доступна для анализа программистам-разработчикам, которые будут разрабатывать отдельные приложения. Она имеет однозначную интерпретацию, в отличие от некоторых предположений естественного языка, и поэтому здесь не может быть никакого недопонимания со стороны разработчиков. Общий подход к построению базы данных с использованием ER-метода состоит, прежде всего, в построении инфологической модели, включающей в себя все важные сущности и связи. Следующим шагом в процессе проектирования базы данных является построение набора предварительных таблиц и указание предполагаемого первичного ключа для каждой таблицы.
Рис. 3 - Приведение инфологической модели системы учета сборки изделий
Разработка логической структуры БД
В реляционных БД дата логическое или логическое проектирование приводит к разработке схемы БД, т.е. совокупности схем отношений, которые адекватно моделируют абстрактные объекты предметной области и семантические связи между этими объектами. Основой анализ корректности схемы являются так называемый функциональные зависимости между атрибутами БД. Некоторые зависимости между атрибутами отношений являются нежелательными из-за побочных эффектов и аномалий, которые они вызывают при модификации БД. При этом под процессом модификации БД понимается внесение новых данных в БД или удаление некоторых данных из БД, а также обновление значений некоторых атрибутов.
Классическая технология проектирования реляционных баз данных связана с теорией нормализации, которая основана на анализе функциональных зависимостей между атрибутами отношений. Понятие функциональной зависимости является фундаментальным в теории нормализации реляционных баз данных. Функциональные зависимости определяют устойчивые отношения между объектами и их свойствами в рассматриваемой предметной области. Именно поэтому процесс поддержки функциональных зависимостей, характерных для данной предметной области, является базовым для процесса проектирования.
Процесс проектирования с использованием декомпозиции представляет собой процесс последовательной нормализации схем отношений, при этом каждая последующая итерация соответствует нормальной форме более высокого уровня и обладает лучшими свойствами по сравнению с предыдущей.
Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений.
Рис. 4 - Приведение инфологической модели «Система учёта сборки изделий» к третьей нормальной форме
Таким образом, мы уже имеем схему базы данных «Система учёта сборки изделий», которую получили, воспользовавшись общими правилами перехода к реляционной модели данных. Она является корректной, поскольку в ней уже отсутствуют нежелательные отношения. Теперь необходимо решить вопрос о том, какую СУБД будем использовать и, затем, описать концептуальную схему в терминах выбранной СУБД. Необходимо также произвести описание внешних моделей в терминах выбранной СУБД. Воспользуемся для простоты СУБД MS Access. Для начала необходимо решить вопрос о назначении типа данных для каждого атрибута каждой сущности.