1. Что должно случиться при попытке удалить объект ссылки внешнего ключа (например, отдел, в котором числятся сотрудники)?

2. Что должно случиться при попытке обновить потенциальный ключ, на который ссылается внешний ключ (например, изменить номер отдела)?

В общем случае существует по меньшей мере две возможности:

- ограничение - "ограничить" операции до момента появления первой ссылки;

- каскадирование - "каскадировать" операции, удаляя или обновляя все соответствующие атрибуты.

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

Реляционная модель допускает появление Null-значений среди атрибутов внешних ключей. Например, в некоторых организациях допускается, чтобы отдельные сотрудники не числились ни в одном отделе. В таком случае в соответствующем кортеже отношения "Сотрудники" будет отсутствовать код отдела, который должен быть значением для внешнего ключа. Поэтому значение внешнего ключа должно либо быть равным значению первичного ключа цели, либо быть полностью неопределенным. В связи с этим, более строгое определение внешнего ключа может быть таким: Внешний ключ FK в отношении R2 - это подмножество множества атрибутов R2 такое, что существует базовое отношение R1 с потенциальным ключом CK, для которого каждое значение FK в текущем значении R2 или является Null-значением, или совпадает со значением CK некоторого кортежа в текущем значении R1.

В дополнении к целостности отношений и целостности по ссылкам существует целостность, определяемая пользователем. Для любой конкретной базы данных существует ряд дополнительных специфических правил, которые относятся к ней одной и определяются разработчиком. Чаще всего контролируется уникальность тех или иных атрибутов, диапазон значений (экзаменационная оценка от 1 до 10), принадлежность набору значений (пол "М" или "Ж"). В этом случае средством обеспечения целостности являются домены. С ними связано такое понятие, как целостность атрибута: Значение каждого атрибута берется из соответствующего домена. Это более фундаментальное правило, чем первые два.

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

Рассмотрим основные элементы метода концептуального моделирования "сущность-связь" на следующем примере. Некоторая банковская компания хранит информацию о своих счетах (№счета, баланс), клиентах (№клиента, имя, адрес, статус) и филиалах банка (название, адрес, директор). Счета могут быть двух типов - депозитные и текущие. Клиенты могут иметь произвольное число счетов. Несколько клиентов могут совместно использовать общий счет. Каждый счет обрабатывается одним филиалом.

Можно выделить три сущности - ФИЛИАЛЫ, КЛИЕНТЫ, СЧЕТА. На ER-диаграмме сущности обозначаются прямоугольником (рис 11).

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

Связи представляют взаимодействие между сущностями и на диаграмме изображаются ромбом, который соединяет сущности. В нашем примере существуют бинарные связи между клиентами и счетами и между счетами и филиалами. Мы предположили, что каждый счет обрабатывается одним филиалом и каждый филиал обрабатывает произвольное количество счетов, поэтому тип связи между филиалом и счетами будет "один-ко-многим" Поскольку счет может совместно использоваться несколькими клиентами и клиент может иметь несколько счетов, то между ними связь имеет кардинальность "многие-ко-многим". ER-диаграмма нашего примера представлена на рис. 12.

Рис. 12. Модель данных «сущность-связь»

Связь типа "многие-ко-многим" может быть заменена двумя связями типа "один-ко-многим": каждый счет может иметь множество регистраций для каждого клиента, использующего данный счет, и каждый клиент может иметь множество регистраций для каждого используемого счета. Такой вид связи называется слабой сущностью. Она не существует самостоятельно, а только при наличии связей, в которых участвует. Для создания ключа слабой сущности желательно использовать атрибуты связываемых сущностей. В нашем примере ключом может быть комбинация атрибутов ID_клиента и Номер_счета. Слабая сущность может иметь и собственные атрибуты, например, Дата_регистрации, Поручитель и т.п. На рис.13 слабая сущность изображена двойной линией.

Такая диаграмма не отражает одно условие нашего примера - разделение счетов на текущие и депозитные. Для реализации этого условия создается расширенная ER-модель. Наиболее важным расширением инфологической модели является введение понятия подтип (рис.13).



Рис. 1.8.4. Создание подтипов

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

Создание подтипов позволяет отразить в ER-диаграмме генерализацию (когда набор типов объектов объединяются в генерализованный тип) и специализацию (противоположный процесс) данных. Примером специализации является упомянутые подтипы "Депозиты" и "Текущие", а примером генерализации - объединение специальностей "Системный администратор" и "Программист" в тип "Технический персонал".

Рассмотрим пример моделирования простой базы данных. Необходимо хранить и обрабатывать информацию о выполняемых фирмой проектах, используемых деталях (или оборудовании) и их поставщиках. Проекты, детали и поставщики составляют основные объекты (или сущности), о которых фирме необходимо хранить информацию. На их основе создаются базовые отношения базы данных. Кроме сущностей имеются и связывающие их отношения. Например, существует отношение ДП между поставщиками и деталями: каждый поставщик поставляет определенные детали и, наоборот, каждая деталь поставляется определенным поставщиком; также существует отношение между проектами и деталями (отношение ПрД). Эти отношения двусторонние - их можно рассматривать в обоих направлениях. Следует помнить, что такие отношения, подобно сущностям, являются частью базы данных и называются слабыми сущностями. Мы будем рассматривать их как специальный тип объектов. ER-диаграмма, показывающая сущности и связи в рассматриваемом примере, представлена на рис. 15.

Рис. 14. ER-диаграмма

В базе данных предлагается следующая семантика:

Таблица Проекты представляет уникальный номер проекта Пр№, его наименование Имя_Пр, руководителя проекта Имя_Рук.

Таблица Детали представляет уникальный номер детали Д№, название детали Имя_Д, цвет Цв, вес Вес (в граммах), город Гор, где производится деталь. Предполагается, что каждый вид детали одного цвета и производится в одном городе.

Таблица Поставщики представляет уникальный номер поставщика П№, имя Имя_П (не обязательно уникальное), значение рейтинга Статус, место расположения Гор.

Таблица ДП представляет поставки. Одно из ее назначений - соединение таблиц Детали и Поставщики. Она может состоять из полей П№, Д№ и поля количества поставок Кол.

Таблица ПрД представляет потребность проектов в деталях и соединяет таблицы Проекты и Детали. Она может состоять из полей Пр№, Д№ и, возможно, Кол.

Таким образом, можно считать, что один из возможных вариантов инфологической модели построен. Однако очевидно, что данные, содержащиеся в таблицах ДП и ПрД, можно представить более рационально, разместив их в одной таблице с именем, например, Поставки, включающей поля Д№, П№, Пр№ и Кол. Эта таблица будет является слабой сущностью и будет выполнять функцию отношений (связей) между сущностями Проекты, Детали и Поставщики конструируемой базы данных. На этом примере мы видим, что отношения, как и сущности, могут быть наглядно представлены таблицами.

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

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



Определение базы данных на языке SQL может быть представлено так:

CREATE DOMAINПр№CHAR (5) CREATE DOMAINИмяCHAR (30) CREATE DOMAINД№CHAR (5) CREATE DOMAINЦвCHAR (10) CREATE DOMAINВесNUMERIC (5) CREATE DOMAINГорCHAR (15) CREATE DOMAINКолNUMERIC (5) CREATE DOMAINП№CHAR (5) CREATE DOMAINСтатусNUMERIC (3)

CREATE BASE RELATION Проекты (Пр№DOMAIN (Пр№), Имя_ПрDOMAIN (Имя), Имя_РукDOMAIN (Имя), PRIMARY KEY (Пр№);

CREATE BASE RELATION Детали (Д№DOMAIN (Д№), Имя_ДDOMAIN (Имя), ЦвDOMAIN (Цв), ВесDOMAIN (Вес), ГорDOMAIN (Гор), PRIMARY KEY (Д№);

CREATE BASE RELATION Поставщики (П№DOMAIN (П№), Имя_ПDOMAIN (Имя), СтатусDOMAIN (Статус), ГорDOMAIN (Гор), PRIMARY KEY (П№);

CREATE BASE RELATION Поставки (П№DOMAIN (П№), Д№DOMAIN (Д№), (Пр№DOMAIN (Пр№), КолDOMAIN (Кол), PRIMARY KEY (П№, Д№, Пр№);

FOREIGN KEY (П№) REFERENCES Поставщики FOREIGN KEY (Пр№) REFERENCES Проекты FOREIGN KEY (Д№) REFERENCES Детали;

Представленная на рис.1.8.6 - 1.8.7 модель базы данных будет использована нами в дальнейшем для иллюстраций различных реляционных операций.

Литература

1. MySQL руководство администратора; М.: Вильямс, 2009. - 621 c.

2. Oracle 8. Администрирование баз данных. Учебное пособие; Oracle, 2012. - 649 c.

3. Александров, В. В.; Вишняков, Ю. С.; Горская, Л.М. и др. Информационное обеспечение интегрированных производственных комплексов; Л.: Машиностроение, 2009. - 511 c.

4. Аткинсон, Леон MySQL. Библиотека профессионала; М.: Вильямс, 2010. - 624 c.

5. Бек, Кент Шаблоны реализации корпоративных приложений; М.: Вильямс, 2008. - 369 c.

6. Веймаер, Р.; Сотел, Р. Освой самостоятельно Microsoft SQL Server 2000 за 21 день (+ CD-ROM); М.: Вильямс, 2013. - 549 c.

7. Гандерлой, Майк; Харкинз, Сьюзан Сейлз Автоматизация Microsoft Access с помощью VBA; М.: Вильямс, 2013. - 416 c.

8. Гетц, Кен; Джинберт, Майкл; Литвин, Пол Access 2000. Руководство разработчика. Том 1. Настольные приложения. том 1; Киев: BHV, 2008. - 576 c.

9. Голицына, О.Л. и др. Базы данных; Форум; Инфра-М, 2013. - 399 c.

10. Гринченко, Н.Н. и др. Проектирование баз данных. СУБД Microsoft Access; Горячая Линия Телеком, 2012. - 613 c.

11. Дейт, К. Дж. Введение в системы баз данных; К.: Диалектика; Издание 6-е, 2012. - 360 c.

12. Дэвидсон, Луис проектирование баз данных на SQL Server 2000; Бином, 2009. - 631 c.

13. Дюваль, Поль М. Непрерывная интеграция. Улучшение качества программного обеспечения и снижение риска; М.: Вильямс, 2008. - 497 c.

14. Каратыгин, С.; Тихонов, А. Работа в Paradox для Windows 5.0 на примерах; М.: Бином, 2011. - 512 c.

15. Каратыгин, Сергей Access 2000 на примерах. Руководство пользователя с примерами; М.: Лаборатория Базовых Знаний, 2012. - 376 c.

16. Кауфельд, Джон Microsoft Office Access 2003 для "чайников"; М.: Диалектика, 2013. - 439 c.

17. Каучмэн, Джейсон; Швинн, Ульрике Oracle 8i CertifiedProfessionaql DBA Подготовка администраторов баз данных; ЛОРИ, 2009. - 510 c.

18. Луни, Кевин; Брила, Боб Oracle 10g. Настольная книга администратора баз данных; М.: Лори, 2008. - 365 c.

Размещено на Allbest.ru