Зимин Лекция_9 3-Проектирование БД

Лекция 9. Проектирование баз данных
(Лекция 3 по БЛ)
Для проектирования структур данных можно использовать:
 Классический метод нормальных форм.
 ER-модель – модель «сущность-связь».
 CASE-системы – системы автоматизации проектирования и разработки баз
данных и информационных систем.
 Мастер анализа таблиц (в СУБД Access).
Проектирование БД классическим методом нормальных форм
Исторически первым появился классический метод нормальных форм, который, по
мнению автора, является более предпочтительным при проектировании небольших баз
данных с не очень сложными связями между данными.
Кратко суть этого метода можно сформулировать следующим образом: сбор
информации об объектах решаемой задачи в рамках одной таблицы (одного отношения) и
последующая декомпозиция ее на несколько взаимосвязанных таблиц на основе
процедуры нормализации отношений.
Более подробно порядок проектирования баз данных классическим методом можно
представить в виде следующих пяти этапов:
1. Провести анализ предметной области и собрать информацию об объектах
решаемой задачи, т. е. ту информацию, которая должна храниться в БД. Сбор такой
информации может происходить по-разному. Можно получить ее в письменном
виде от заказчика БД в качестве постановки задачи, путем беседы с
представителями заказчика или изучения вопроса самостоятельно исполнителем
работ.
2. Составить единую таблицу (какой бы большой она ни была), включив в нее все
полученные данные. Таблица должна быть в первой нормальной форме, т.е. ее поля
должны быть простыми, неделимыми. Ввести в исходную таблицу несколько
записей с фактическими, а не придуманными данными.
3. Задать ключ для этой таблицы. Как правило, ключ этот будет составным,
состоящим из нескольких полей. Выбирать в качества ключа поле типа счетчика в
исходной таблице нельзя.
4. Провести анализ всех связей между полями, используя весь свой жизненный опыт
и знания в той предметной области, которая является основой для создания БД.
Если таких знаний и опыта недостаточно, необходимо получить их из бесед с
узкими специалистами предметной области. При этом необходимо помнить, что
некоторые связи между полями таблицы будут связями между таблицами, на
которые будет «разбита» исходная таблица.
5. На основе процедуры нормализации отношений последовательно провести
декомпозицию все большой таблицы на несколько взаимосвязанных таблиц. Как
правило, для этого достаточно ограничиться приведением таблиц к первой, второй
и третьей нормальным формам.
Проектирование БД с использованием ER-модели (модель «сущность-связь»),
CASE-систем подробно изложено в работах [1], [2]. Все эти способы проектирования
также предназначены для выделения отдельных информационных объектов (сущностей, а,
следовательно, таблиц) и связей между ними. В этих методах формализованы способы
изображения схем связей между сущностями (объектами, таблицами). Подробно
излагается технология рисования этих схем проектировщиком (ER-модель) или задания
данных для последующего автоматического рисования схем (CASE-системы). А вот
выделение самих сущностей, информационных объектов зависит только от умения и
знаний самого проектировщика. То есть, что заложите в систему, то и получите.
В отличие от этих методов классический способ, кратко изложенный выше,
предлагает метод нормальных форм для выделения информационных объектов, т. е.
некую формализованную процедуру.
Интерес представляет также средство автоматического проектирования БД с
помощью Мастера анализа таблиц СУБД Access. Access, действительно, сам проектирует
базу данных, выделяя из одной исходной таблицы все таблицы, определяя ключи для
каждой из них и изображая все связи между ними. В следующем разделе изложен этот
способ проектирования. Но следует отметить, что нигде такой способ проектирования не
выделяется.
Проектирование структуры базы данных с помощью средств Access
Этот способ проектирования выделил автор этих лекций, который обнаружил, что
анализ таблиц в СУБД Access имеет большое сходство с классическим способом
проектирования баз данных. Но если изложенный выше метод проектирования БД
классический способом предполагает самостоятельный анализ всех связей, то в
предложенном способе такой анализ делает сама система СУБД Access.
Предложенный способ проектирования запускается командой Сервис  Анализ 
Таблица. Перед выполнением этой команды необходимо в любом режиме создать
таблицу, которую можно назвать Исходная. Поля этой таблицы должны соответствовать
всем данным (реквизитам), которые следует хранить в базе данных. (Сравните с
классическим способом проектирования!). Затем в таблицу Исходная ввести несколько
записей, соблюдая следующее основное требование.
Количество введенных записей должно отвечать следующему требованию:
в записях должны быть представлены все возможные варианты данных
каждого поля.
Поясним это на примере заполнения таблицы Исходная для БД «Моя библиотека»,
изображенном на рис. 1.
Во всех полях, данные которых могут повторяться (дублироваться), они
повторяются. Если этого дублирования не будет, то одно из таких полей может быть
назначено в качестве ключевого поля, с нашей точки зрения, без всяких на то оснований.
Если же возможное дублирование отражено в записях, то Access создаст поле со списком
и таблицу – источник данных для этого поля. Таким полем со списком будет определено
поле Издательство, что является совершенно правильным.
Для одного из авторов (Сидорова) приведены книги разного названия.
Действительно, писатель может быть автором нескольких книг, т. е. этот вариант данных
тоже отражен в этих пяти записях. Благодаря этому Access «догадался», что, разбивая
таблицу Исходная
Рис. 1. Исходная таблица БД «Моя библиотека»
на две таблицы, которые пока условно назовем Книги и Авторы, связь между ними будет
М:М и для реализации этой связи создаст таблицу связи.
Анализ таблицы Исходная заканчивается разбиением ее на несколько таблиц,
названных однотипно Таблица1, Таблица2 и т. д., и построением схемы данных. Таблицы
изображены в нотации ER-модели в виде прямоугольников с написанием в них названий
полей. На автоматически построенной схеме данных предусмотрено проведение
следующих исправлений. Во-первых, щелкнув левой кнопкой мыши на заголовке любой
таблицы, можно задать ей содержательное название. Во-вторых, в случае ошибочного
разбиения таблицы Исходная на несколько таблиц некоторые поля помещаются в
таблицы, в которых они не должны быть. Эти поля можно просто перетащить в нужные
таблицы. Дальнейшее уточнение, редактирование структуры таблиц можно сделать в
режиме Конструктора. А подправить схему данных можно в окне с таким же названием,
для чего нажать кнопку с названием Схема данных, или выполнить команду Сервис
Схема данных.