Лабораторная работа №2
Логическое проектирование и реализация реляционных баз данных. Основы Transact-SQL
1. Изучить методику логического проектирования реляционных баз данных.
2. Изучить основные возможности реализации БД в системе Microsoft SQL Server 2005 с использованием операторов определения данных языка Transact-SQL.
3. Изучить операторы манипулирования данными языка Transact-SQL в части добавления, удаления, модификации, выборки.
2.1. Логическое проектирование БД
Задача логического проектирования реляционной БД – отобразить имеющуюся концептуальную модель на реляционную схему. Последняя есть не что иное, как набор именованных схем отношений, или, проще говоря, набор взаимосвязанных реляционных таблиц.
Все манипуляции с данными в реляционных СУБД сводятся к обработке прямоугольных таблиц, которые разбиваются на столбцы (атрибуты) и строки (записи, кортежи). Ячейка, находящаяся на пересечении строки и столбца, называется полем записи. В реляционных таблицах каждый столбец соответствует атрибуту сущности или связи. При этом в любой таблице может быть выбран один простой или составной атрибут, значения которого будут однозначно идентифицировать каждую запись. Такой атрибут называется первичным ключом. Для первичных ключей баз данных Microsoft SQL Server автоматически создаются так называемые первичные индексы – структуры, при помощи которых производится физическая сортировка строк по возрастанию значения первичного ключа и, как следствие, появляется возможность ускоренного (бинарного) поиска.
Однако роль первичного ключа не сводится исключительно к сортировке и ускорению поиска. Если в таблице определён первичный ключ, можно определять в других таблицах специальные атрибуты – внешние ключи – для добавления ссылок на таблицу, содержащую первичный ключ. Сказанное можно проиллюстрировать на следующем примере (рис. 1). Пусть имеются две таблицы: trains (поезда) и coaches (вагоны). Каждый поезд состоит из множества вагонов, при этом один вагон включается в состав одного определенного поезда. Как описать эту связь между сущностями с помощью таблиц БД? В таблице trains определяется первичный ключ id_train – уникальный идентификационный номер поезда. Из рис. 1 видно, что в таблице coaches также присутствует столбец id_train. Это внешний ключ. Для каждого вагона он показывает номер поезда, в состав которого включен данный вагон. Следует заметить, что на таблицу coaches также могут вести ссылки по внешнему ключу, из других таблиц, - эти ссылки должны вести на столбец id_coach, являющийся первичным ключом таблицы coaches.
Рисунок 1 – Пример использования первичного и внешнего ключей в таблицах
Внешние ключи, строго говоря, создаются не просто для связи столбцов – они создаются для связи между строками разных таблиц. На рис. 2 показан конкретный случай привязки записей таблицы coaches к записям таблицы trains. Используются ссылки по значению, роль которого в приводимом примере играют идентификационные номера поездов. Первая запись таблицы coaches описывает первый вагон поезда «Автора» (на это указывает ссылка в id_train, равная 2). Вторая запись описывает первый вагон поезда «Смена», третья – второй вагон «Авторы», четвертая – второй вагон «Смены».
Рисунок 2 – Пример использования ссылок по внешнему ключу
Построение реляционной схемы заключается, по сути дела, в группировании всего множества атрибутов по таблицам, которое сопровождается выделением первичных и внешних ключей. Выполняется эта процедура в соответствии со следующими правилами.
1. Пусть между двумя сущностями имеется связь (1,1):(1,1). Если других связей между этими сущностями нет, то можно отобразить этот фрагмент диаграммы на одну таблицу (рис. 3). Данная таблица будет включать атрибуты обеих сущностей, а также атрибуты связи (если они есть). Первичным ключом таблицы может стать ключ любой из сущностей.
Рисунок 3 – Отображение связи (1, 1):(1, 1) на реляционную схему
2. Две сущности, связанные ассоциацией (1,1):(0,1) отображаются на реляционную схему в виде двух таблиц. Обратимся к рис. 4. Две сущности – E1 и E2 – отображены на две таблицы, по одной таблице для каждой сущности. Однако вторая таблица (с атрибутами сущности E2) содержит также атрибуты связи R1 и ключ сущности E1: последний является внешним ключом. Дополнительно на внешний ключ наложены два ограничения целостности: UNIQUE и NOT NULL. Ограничение UNIQUE гарантирует уникальность значений атрибута. Так как в данном случае реализуется связь 1:1, ни одно значение внешнего ключа не должно дублироваться, чтобы с каждым экземпляром сущности E1 мог быть ассоциирован только один экземпляр сущности E2. Ограничение NOT NULL гарантирует, что все значения атрибута будут определенными. Поскольку сущность E1 имеет обязательный класс принадлежности к связи, каждый экземпляр E2, регистрируемый во второй таблице, должен «знать» свой экземпляр сущности E1.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.
