Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Краткий_Конспект_Лекций_БД.doc
Скачиваний:
104
Добавлен:
24.02.2016
Размер:
1.12 Mб
Скачать
  1. Формирование из объектов предметной области сущностей и их характеристик

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

Моделирование концептуального уровня БД включает в себя:

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

  • идентификацию объектов, которые осуществляют эту функциональную деятельность, и формирование из их операций последовательности событий, которые помогут Вам идентифицировать все сущности и взаимосвязи между ними. Например, процесс "ведение учета работающих" идентифицирует такие сущности как РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ.

  • идентификацию характеристик этих сущностей. Например, сущность РАБОТНИК может включать такиехарактеристикикакИдентификатор Работника,Фамилия,Имя,Отчество,Профессия,Зарплата.

  • идентификацию взаимосвязей между сущностями. Например, каким образом сущности РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ взаимодействуют друг с другом? Работник имеет одну профессию (для простоты!) и значится в одном отделе, в то время как в одном отделе может находиться много работников.

  1. Установка соответствия между сущностями и таблицами, характеристиками сущностей и столбцами таблиц

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

Получение реляционной схемы из er-диаграммы:

  1. Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы.

  2. Каждый атрибут становится столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут. Если атрибут является множественным, то для него строится отдельное отношение.

  1. Определение первичных ключей

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

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

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

  • суммарной длины атрибутов;

  • минимального количества атрибутов в ключе;

  • наличия гарантий уникальности его значений в текущий момент времени и в обозримом будущем.

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

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

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

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

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

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

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