43

Методические указания к лабораторной работе №4 по дисциплинам «Базы данных и информационные системы» и «Организация баз данных и знаний»

на тему

«Изучение основных принципов проектирования РБД

с помощью инструментального CASE-средства ERWIN.

Операторы создания и модификации структуры БД (DDL)»

4.1 Цель работы

Отработать навыки создания ER-модели с использованием инструментального CASE-средства ERWIN, генерации структуры БД в СУБД MS ACCESS и MS SQL SERVER, формирования запросов DDL.

4.2 Методические указания

4.2.1 Теоретические сведения

4.2.1.1 Этапы концептуального и логического проектирования БД предметной области в классической теории БД

Подготовительный этап включает в себя:

• разработка спецификации требований (описание пользователей, требования к данным, требования к отчетам пользователей)/техническое задание;

• разработка бизнес правил БД и глоссария БД.

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

• определение типов сущностей;

• определение типов связей;

• построение предварительной концептуальной модели (в виде ER-диаграммы);

• определение атрибутов и связывание их с типами сущностей и связей;

• определение доменов атрибутов;

• определение атрибутов, являющихся потенциальными ключами и выбор первичных ключей;

• специализация/генерализация типов сущности (необязательный этап);

• анализ модели на достаточность/избыточность всех связей;

• проверка соответствия концептуальной модели конкретным пользовательским транзакциям

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

– исключение особенностей, несовместимых с РМ:

- преобразование связей типа M:N за счет добавления новой сущности;

- преобразование сложных связей (не бинарных) в сущности;

- анализ и преобразование рекурсивных связей M:N;

- преобразование связей, имеющих атрибуты, в сущности;

- удаление множественных атрибутов за счет добавления новой сущности;

– дополнительный анализ:

- перепроверка связей типа 1:1;

- анализ рекурсивных связей 1:1, 1:M;

- проверка модели с помощью правил нормализации на соответствие требованиям 3-й нормальной формы;

- анализ связей супер класс/подкласс;

- повторная проверка на избыточность (удаление избыточных связей);

- повторная проверка соответствия отношений требованиям пользовательских транзак­ций (проверка на достаточность);

– определение набора отношений исходя из структуры логической модели данных;

– отражение всех требований итоговой ER-диаграммы логической модели в документации;

4.2.1.2 Нормализация данных

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

• первая нормальная форма (1НФ);

• вторая нормальная форма (2НФ);

• третья нормальная форма (3НФ);

• нормальная форма Бойса - Кодда (усиленная 3НФ);

• четвертая нормальная форма (4НФ);

• пятая нормальная форма (5НФ).

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

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

Функциональная зависимость (ФЗ). Атрибут В сущности Е функционально зависит от атрибута А сущности Е тогда и только тогда, когда каждое значение атрибута А однозначно определяет одно значение атрибута В.

Полная функциональная зависимость. Атрибут В сущности Е полностью функционально зависит от ряда атрибутов А сущности Е тогда и только тогда, когда В функционально зависит от А и не зависит ни от какого подряда А.

На рисунке 4.1 в сущности Сотрудник значение атрибутов Фамилия, Имя и Отчество однозначно определяются значением атрибута Табельный номер, т. е. атрибуты Фамилия, Имя и Отчество функционально зависят от атрибута Табельный номер. В обратную сторону функциональная зависимость отсутствует, поскольку сотрудникам с одинаковым значением атрибутов Фамилия, Имя и Отчество соответствуют разные значения атрибута Табельный номер.

Функциональные зависимости определяются бизнес-правилами предметной области. Так, если оклад сотрудника определяется только должностью, то атрибут Оклад зависит от атрибута Должность, если оклад зависит еще, например, от стажа, то такой зависимости нет. В нижеследующих примерах будем считать для определенности, что такая зависимость есть (Оклад зависит от атрибута Должность).

Рисунок 4.1 – Ненормализованная сущность "Сотрудник"

Рассмотрим нормальные формы.

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

На рисунке 4.1 атрибуты Телефон и Хобби являются нарушением первой нормальной формы. Что будет, если у сотрудника несколько рабочих телефонов? Запись значения колонки через разделитель, например "124-56-78, 124-56-79, 124-56-90" или "Аквалангист, мотоциклист, шахматист", приводит к ряду проблем. Размера поля может не хватить для хранения данных (нельзя увеличивать список телефонов до бесконечности), по такой колонке невозможно построить индекс и т. п. Сущность, приведенная на рисунке 4.2, не является решением проблемы. Что будет, если у сотрудника появится четвертый телефон или третье хобби? Эту информацию будет негде хранить.

Рисунок 4.2 – Еще один пример ненормализованной сущности

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

Для приведения сущности к 1НФ следует :

• разделить сложные атрибуты на атомарные;

• создать новую сущность, перенести в нее все "многозначные" атрибуты, установить связь от прежней сущности к новой (РК прежней сущности станет внешним ключом (FK) для новой сущности), выбрать РК из существующих атрибутов (или создать суррогатный);

На рисунке 4.3 показана одна из возможностей приведения сущности Сотрудник к 1НФ

Рисунок 4.3 – Сущность Сотрудник, приведенная к 1НФ

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

Предположим, сущность Проект содержит информацию о проекте, которым руководит несколько сотрудников, причем информация содержится как непо­средственно о Дате начала и Дате завершения руководства проектом, так и о руководителе проекта (рис. 4.4). Атрибуты Фамилия, Имя, Отчество и Должность зависят только от атрибута Табельный номер руководителя, но вовсе не от Наименования проекта. Другими словами, имеется зависимость только от части ключа.

Проект

Рисунок 4.4 – Сущность Проект

Описания предметной области можно оформить в виде таких БП:

- каждым проектом может руководить последовательно несколько сотрудников с фиксированием Даты начала и Даты завершения руководства;

- сотрудник может руководить многими проектами, но каждым проектом - только один раз (один промежуток времени).

Тогда для приведения сущности ко 2НФ следует:

• выделить атрибуты, которые зависят только от части первичного ключа, создать новую сущность;

• поместить атрибуты, зависящие от части ключа, в их собственную (новую) сущность Сотрудник, вместе атрибутом, от которого они зависят;

• использовать атрибут, определяющий эту зависимость, в качестве первичного ключа новой сущности;

• установить идентифицирующую связь от новой сущности Сотрудник к прежней сущности Проект (рис.4.5).

Рисунок 4.5 – Сущность проект, приведенная ко 2НФ

2НФ позволяет избежать следующих аномалий при выполнении операций:

Обновление (UPDATE). Имело бы место дублирование данных о сотрудни­ке, если он руководит несколькими проектами. Если данные о сотруднике изменялись бы, необходимо было менять несколько записей (по числу ведомых проектов).

Вставка (INSERT). Невозможно было бы ввести данные о сотруднике, если он в данный момент не руководил проектами.

Удаление (DELETE). Если сотрудник временно прекращал бы руководство проектами, данные о нем терялись.

Третья нормальная форма (3НФ). Сущность находится в 3НФ форме, если она находится во второй нормальной форме и никакой неключевой атрибут не зависит от другого неключевого атрибута (не должно быть взаимозависимости между неключевыми атрибутами).

На рис.4.3 сущность Сотрудник находится во 2НФ (имеется только один атрибут первичного ключа, поэтому не может быть зависимости неключевых атрибутов от части ключа), но неключевой атрибут Оклад зависит от другого неключевого атрибута - Должности.

Для приведения сущности к 3НФ следует:

• создать новую сущность Должность и перенести в нее атрибуты с одной и той же зависимостью от неключевого атрибута;

• использовать атрибут, определяющий эту зависимость, в качестве первичного ключа новой сущности;

• установить неидентифицирующую связь от новой сущности к старой (рис.4.6).

Рисунок 4.6 – Сущность Сотрудник, приведенная к 3НФ

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

Обновление (UPDATE). Имело бы место дублирование данных об окладе, если одинаковую должность занимают несколько сотрудников. Если оклад соответст­вующей должности менялся, необходимо было бы менять несколько записей (по числу сотрудников на одной должности).

Вставка (INSERT). Невозможно было бы ввести данные об окладе, соответст­вующем должности, если в данный момент нет сотрудника, занимающего эту должность.

Удаление (DELETE). В случае удаления из таблицы сотрудника, зани­мающего уникальную должность, данные об окладе терялись бы.

4.2.1.3 Операторы создания и модификации структуры БД (DDL)

Оператор CREATE TABLE.

Оператор создает таблицу с заданным именем и набором столбцов.

Упрощенная форма (минимальная):

CREATE TABLE имя_таблицы (

имя_столбца тип_данных[(размер)] [,имя_столбца тип_данных [(размер)] …] )

Названия и описание основных типов данных для СУБД MS Access и MS SQL Server приведены в приложении А.

Пример 1 (СУБД Access). Создается таблица с именем «МояТаблица», содержащая три столбца (поля) с именами «Поле1», «Поле2» и «Поле3».

CREATE TABLE МояТаблица

(Поле1 COUNTER, Поле2 INTEGER, Поле3 CHAR );

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

Обощенная форма оператора CREATE TABLE:

CREATE TABLE имя_таблицы

( {<определение столбца>} [, …n]

[ <ограничения таблицы> [, …n] ])

Упрощенная форма оператора CREATE TABLE:

CREATE TABLE имя_таблицы (

имя_столбца тип[(размер)] [ограничение]

[,имя_столбца тип[(размер)] [ограничение] …]

[,PRIMARY KEY (имя_столбца [, имя_столбца …])]

[,FOREIGN KEY (имя_столбца [, имя_столбца …])

REFERENCES имя_таблицы [(имя_столбца [, имя_столбца])]

[ON UPDATE CASCADE | SET NULL] [

ON DELETE CASCADE | SET NULL] ] )

Упрощенная форма оператора CREATE TABLE c CONSTRAINT:

CREATE TABLE имя_таблицы (

имя_столбца тип[(размер)] [CONSTRAINT имя_ограничения ограничение [… ограничение]]

[,имя_столбца тип[(размер) [CONSTRAINT имя_ограничения ограничение] [… ограничение]]

[, CONSTRAINT имя_ограничения PRIMARY KEY (имя_столбца [, имя_столбца …])]

[,CONSTRAINT имя_ограничения FOREIGN KEY (имя_столбца [, имя_столбца …])

REFERENCES имя_таблицы [(имя_столбца [, имя_столбца])]

[ON UPDATE CASCADE | SET NULL] [

ON DELETE CASCADE | SET NULL] ] )

Более полный синтаксис оператора CREATE TABLE рассмотрен на лекции.

Ниже приводятся пояснения относительно ограничений столбцов:

- NULL или NOT NULL (соответственно разрешает или запрещает помещать пустые значения в этот столбец);

- UNIQUE (накладывает требование уникальности значений. Для любых двух строк таблицы значения в этом столбце не могут быть одинаковыми);

- PRIMARY KEY (объявляет столбец первичным ключом таблицы. Имеет тот же смысл, что и задание ключевого поля в конструкторе таблиц в СУБД Access);

- REFERENCES имя_таблицы [(имя_столбца)]

[ON UPDATE CASCADE | SET NULL]

[ON DELETE CASCADE | SET NULL]

Объявляет данный столбец внешним ключом, который связан с заданным полем заданной таблицы. Поле, с которым устанавливается связь, должно быть ключевым, или, по крайней мере, уникальным (являться потенциальным ключом). Необязательные атрибуты ON UPDATE и ON DELETE могут принимать значения CASCADE или SET NULL.

Задание ограничения REFERENCES имеет тот же смысл, что и создание связи между таблицами с использованием схемы данных. Использование атрибутов ON UPDATE и ON DELETE равносильно заданию соответствующих свойств этой связи («Обеспечение целостности данных», «Каскадное обновление связанных полей», «Каскадное удаление связанных записей») в схеме данных (СУБД Access)).

Пример 2. (СУБД Access)

CREATE TABLE МояТаблица (

Поле1 COUNTER PRIMARY KEY,

Поле2 INTEGER UNIQUE NOT NULL,

Поле3 CHAR NOT NULL);

Рассмотрим теперь ограничения на несколько полей (составные ограничения):

- PRIMARY KEY (имя_столбца [, имя_столбца …]) - объявляет первичный ключ таблицы. В скобках перечисляются столбцы, входящие в первичный ключ;

- FOREIGN KEY (имя_столбца [, имя_столбца …])

REFERENCES имя_таблицы [(имя_столбца [, имя_столбца …])]

[ON UPDATE CASCADE | SET NULL]

[ON DELETE CASCADE | SET NULL]

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

Пример 3. (СУБД Access)

Ниже приведены операторы, создающие три связанные таблицы:

CREATE TABLE Клиент

(КодКлиента COUNTER PRIMARY KEY,

Фамилия CHAR NOT NULL,

Имя CHAR NOT NULL,

Отчество CHAR NOT NULL );

CREATE TABLE Журнал

(КодЖурнала COUNTER PRIMARY KEY,

Название CHAR NOT NULL );

CREATE TABLE Подписка

(КодКлиента INTEGER REFERENCES Клиент(КодКлиента),

КодЖурнала INTEGER REFERENCES Клиент(КодЖурнала),

PRIMARY KEY (КодКлиента, КодЖурнала) );

Таблицы соответствуют схеме данных, приведенной ниже (рис.4.7):

Рисунок 4.7

Оператор DROP TABLE

Удаляет таблицу с заданным именем.

DROP TABLE имя_таблицы ;

Оператор ALTER TABLE

Применяется для модификации структуры таблицы.

Пусть существует таблица TestMy, заданная скриптом

CREATE TABLE TestMy

(сol1 INT NOT NULL, сol2 INT);

Ниже приведены примеры использования оператора ALTER TABLE

 Добавление колонки

ALTER TABLE TestMy ADD COLUMN col3 INT; // Access

ALTER TABLE TestMy ADD col3 INT; //SQL Server, Access

ALTER TABLE TestMy ADD col3 INT, col4 INT; //SQL Server, Access

 ALTER TABLE TestMy ADD col3 INT, col4 as col3*0.1; // SQL Server

Замечание! Access вычисляемые поля (col4 as col3*0.1) не поддерживает

Удаление колонки

ALTER TABLE TestMy DROP COLUMN col3; //SQL Server, Access

ALTER TABLE TestMy DROP col3; //Access

Редактирование свойств поля(SQL Server, Access)

ALTER TABLE TestMy ALTER COLUMN col3 VARCHAR(10) NOT NULL; //SQL Server, Access

ALTER TABLE TestMy ALTER col3 VARCHAR(10) NOT NULL; // Access

Добавление ограничения (SQL Server, Access)

ALTER TABLE TestMy ADD CONSTRAINT PK_TestMy PRIMARY KEY (сol1);

// (если сol1 NOT NULL)

ALTER TABLE TestMy ADD CONSTRAINT FK_TestMy_TM FOREIGN KEY (col2) REFERENCES TestMy2(col2);

ALTER TABLE TestMy ADD CONSTRAINT CH_TestMy CHECK (col3 IN(‘первый’, ‘второй’, ‘третий’)); // SQL Server

 Добавление поля вместе с ограничением (SQL Server, Access)

ALTER TABLE TestMy ADD col2 VARCHAR(20) CONSTRAINT c_col2 Unique NOT NULL;

Удаление ограничения (SQL Server, Access)

 ALTER TABLE TestMy DROP CONSTRAINT c_col2;