- •Базы данных
- •Введение
- •Часть 1. Проектирование баз данных
- •1.1. Некоторые понятия и определения
- •1. 2. Модели данных
- •1.2.1. Иерархическая модель данных
- •1.2.2. Сетевая модель данных
- •1.2.3. Реляционная модель данных Основные определения
- •Типы связей между отношениями
- •1.3. Классификация баз данных
- •1.4. Цели проектирования баз данных
- •1.5. Проектирование баз данных с использованием универсального отношения
- •1.5.1. Универсальное отношение
- •1.5.2. Проблемы, вызываемые использованием универсального отношения
- •Проблема вставки
- •Проблемы обновления
- •Проблемы удаления
- •1.5.3. Нормальная форма Бойса -Кодда
- •Функциональные зависимости
- •Возможный ключ и детерминант
- •Общий подход к декомпозиции
- •Анализ исходных аномалий
- •1.5.4. Возможные потери фз при декомпозиции
- •1.5.5. Избыточные функциональные зависимости
- •Приемы удаления избыточных фз
- •Минимальное покрытие
- •Модернизированный алгоритм проектирования бд
- •1.5. Метод er - проектирования
- •1.5.1. Сущности и связи
- •1.5.2. Степень связи
- •1.5.3. Переход от диаграмм er – типа к отношениям
- •Предварительные отношения для бинарных связей степени 1:1
- •Предварительные отношения для бинарных связей степени 1:n.
- •Предварительные отношения для бинарных связей степени n:m
- •1.5.4. Дополнительные конструкции, используемые в er - методе
- •Необходимость связей более высокого порядка
- •Предварительные отношения для трехсторонних связей
- •Использование ролей
- •1.5.5. Последовательность проектирования бд при использовании er- метода
- •1.5.5. Проверка отношений на завершающейся фазе проектирования
- •1.7. Другие нормальные формы
- •Часть 2. Специальные аспекты работы с базами данных
- •2.1. Защита данных в базе
- •2.2.1. Общие вопросы защиты данных
- •2.2.2. Реализация защиты данных в различных системах
- •Управление доступом в sql
- •Реализация системы защиты в ms sql Server
- •2.2. Обеспечение целостности данных
- •2.3. Организация параллельных процессов обработки данных
- •2.4. Восстановление бд
- •2.4.1. Уровни восстановления.
- •2.4.2. Восстановление и логический элемент работы
- •Требования к лэр
- •2.4.3. Промежуточное восстановление
- •2.4.4. Длительное восстановление
- •2.5. Математический аппарат, используемый при работе с реляционной базой данных
- •2.5.1. Теоретико-множественные операции реляционной алгебры
- •2.5.2. Специальные операции реляционной алгебры
- •Часть 3. Разработка приложений для работы с базами данных
- •3.1. Краткий обзор субд
- •3.2. Субд Access
- •3.2.1. Вводные замечания
- •3.2.2. Создание базы данных
- •3.2.3. Создание и работа с таблицами
- •3.2.4. Работа с запросами
- •3.2.5. Создание форм
- •3.2.5. Отчеты в Access
- •3.2.7. Макросы в Access
- •Преобразование макросов в программы на Visual Basic
- •3.2.8. Работа с внешними данными
- •3.3. Программирование в Access
- •3.3.1. Вводные замечания
- •3.3.2. Объявление переменных
- •3.3.3. Константы
- •3.3.4. Тип данных Variant
- •3.3.5. Пользовательские типы данных
- •3.3.5.Операторы, команды и выражения в vba
- •3.3.7. Процедуры vba
- •3.3.8. Управляющие структуры в vba
- •Работа с управляющими структурами
- •3.3.9. Объекты в Access
- •3.3.10. Классы в Access
- •3.3.11. Работа с ошибками в vba
- •3.4.Работа в ms sql –Server
- •3.4.1. Основные количественные показатели системы sql-сервер
- •3.4.2. Создание баз данных
- •3.4.3. Создание таблицы
- •3.4.4. Извлечение данных
- •3.4.5. Добавление данных
- •3.4.5. Изменение данных
- •3.4.7. Удаление данных
- •Цитированная литература
- •Оглавление
- •Часть 1. Проектирование баз данных 3
- •Часть 2. Специальные аспекты работы с базами данных 70
- •Часть 3. Разработка приложений для работы с базами данных 113
Предварительные отношения для трехсторонних связей
В случае трехсторонних связей предварительные отношения генерируются на основании следующего правила.
ПРАВИЛО 7. В случае трехсторонней связи необходимо использовать четыре предварительных отношения, по одному для каждой сущности, причем ключ каждой сущности должен служить в качестве первого ключа для соответствующего отношения, и одного для связи. Отношение, порождаемое связью, будет иметь среди своих атрибутов ключи сущности от каждой сущности.
(Аналогично, когда связь n-сторонняя, требуется n + 1 предварительное отношение).
Если применять это правило к данным, приведенным на рис. 6.18, то будут получены предварительные отношения:
РАБОЧИЙ (рфам .,......),
СТАНОК (сном .,.....),
ДЕТАЛЬ ( дтип .,......),
Р_С_Д (рфам, сном, дтип,...).
Первичный ключ для Р_С_Д не может быть определен до тех пор, пока не будут распределены все другие атрибуты. Если воспользоваться всеми теми атрибутами, которые приведены на рис.6.15,то атрибуты будут распределены следующим образом: отношению РАБОЧИЙ назначаются атрибуты нцех, и тстав; отношению СТАНОК будет назначен атрибут стип; отношению ДЕТАЛЬ назначается атрибут мдет. Отношению Р_С_Д не получит никаких "других" атрибутов. Первичный ключ для Р_С_Д будет составным < рфам,сном> в том случае, если каждый рабочий предпочитает изготавливать на станке только один тип детали. Если число предпочитаемых рабочим типов детали равно двум или более для какого-либо станка, тогда все три атрибута отношения Р_С_Д будут составлять ключ.
На рис. 6.19 приведены экземпляры четырех отношений в предположении, что каждый рабочий предпочитает изготавливать один тип детали на каждом станке, которое им обслуживается. Нетрудно показать, что каждое из рассмотренных отношений находится в НФБК.
Р_С_Д СТАНОК
рфам |
стип |
дтип |
|
сном |
стип |
Р1 |
С1 |
1Т |
С1 |
1Т | |
Р1 |
С2 |
2Т |
С1 |
2Т | |
Р2 |
С2 |
2Т |
С2 |
1Т | |
Р3 |
С3 |
1Т |
С3 |
1Т | |
Р4 |
С4 |
3Т |
С4 |
3Т |
РАБОЧИЙ ДЕТАЛЬ
рфам |
нцех |
тстав |
|
дтип |
мдит |
Р1 |
3 |
500 |
1Т |
М1 | |
Р2 |
3 |
400 |
2Т |
М2 | |
Р3 |
3 |
300 |
3Т |
М3 | |
Р4 |
3 |
250 |
|
Рис. 6.19. Экземпляры отношений, полученные на основании диаграмм, приведенных на рис.6.18.
Использование ролей
В некоторых случаях одних сущностей и связей может оказаться недостаточно для полноценного моделирования организации.
Одна из таких ситуаций возникает тогда, когда экземпляры некоторой сущности должны играть разные роли в деятельности организации. В качестве примера положим, что для небольшого предприятия поставщика автомобилей необходимо хранить информацию о производственном персонале: двух категориях служащих – мастерах и сборщиках. Мастера получают финансированный оклад, в то время как у сборщиков почасовая оплата.
Диаграмма ER - типа для этого случая показана на рис.6.20. Ключом сущности для каждой сущности является табельный номер каждого служащего.
1 n
РУКОВОДИТ
мастер# .... сборщик# ....
Рис. 6.20. Возможный вариант ER - модели предприятия.
Предполагается, что ни один мастер не руководит другим мастером, ни один мастер не является сборщиком и ни один сборщик не является мастером.
Поскольку связь РУКОВОДИТ имеет степень 1:n и класс принадлежности каждой сущности является обязательным, то в соответствии с общим правилом будут построены два предварительных отношения:
МАСТЕР (мастер#,......),
СБОРЩИК (сборщик#,....., мастер#).
С этой моделью связана одна проблема, проявляющаяся при добавлении не ключевых атрибутов в предварительные отношения.
Предположим, что другими, представляющими интерес атрибутами являются:
слфам - фамилия (и имя) служащего,
ртел - номер служебного телефона мастера (сборщик служебного телефона не имеет),
дтел - номер домашнего телефона служащего,
сладрес - домашний адрес служащего,
тстав - почасовая тарифная ставка сборщика,
оклад - месячный оклад мастера.
Не возникает особых проблем при размещении в одном из двух отношений следующих атрибутов: ртел, тстав и оклад. После того как каждый из этих атрибутов будет логичным образом помещен в одно из двух отношений, предварительные отношения примут вид:
МАСТЕР (мастер#,оклад,ртел,...),
СБОРЩИК (сборщик#, тстав,...мастер#).
Не размещенными остались только атрибуты слфам, дтел и сладрес. Для полноты следовало бы эти три атрибута поместить в оба отношения. Однако в соответствии с общим правилом каждый не ключевой атрибут следует размещать только в одном отношении.
Может возникнуть необходимость переопределить три оставшихся атрибута с целью получения из них следующих шести атрибутов:
мфам - фамилия (и имя) мастера,
сбфам - фамилия (и имя)сборщика,
мдтел - номер домашнего телефона мастера,
сбдтел - номер домашнего телефона сборщика,
мадрес - домашний адрес мастера,
сбадрес - домашний адрес сборщика.
В этом случае атрибуты мфам, мдтел и мадрес могут быть помещены в отношение МАСТЕР, а атрибуты сбфам, сбдтел и сбадрес - в отношении СБОРЩИК. Однако такое решение неудачное, ибо здесь возникает следующая проблема. Предположим, что требуется найти номер домашнего телефона, например служащего Уткина Николая. Поскольку неизвестно, является Уткин Николай мастером или сборщиком, то необходимо просмотреть сначала одно отношение, затем другое с целью нахождения фамилии Уткина Николая. Если существует два служащих Уткин Николай - один мастер, а другой - сборщик, результатом поиска, если выбрать не то отношение, будет не правильный номер телефона.
Лучшее решение достигается путем рассмотрения всей проблемы с иной точки зрения. Все мастера и сборщики рассматриваются в качестве служащих, а мастер и сборщик - это те роли, которые данный служащий может играть: некоторые служащие являются мастерами, в то время как другие являются сборщиками. Графически это показано на рис.6.21.
СЛУЖАЩИЙ
служ#,….
1 n
_мастер# .,... РУКОВОДИТ
мастер#,….. сборщик#,….
Рис. 6.21. Использование ролей в ER - модели.
На рисунке СЛУЖАЩИЙ представляет собой сущность, ключом которой является табельный номер. Объекты данной сущности могут играть роль либо мастера, либо сборщика. Два ролевых набора МАСТЕР и СБОРЩИК - соединяются связью РУКОВОДИТ. Стрелки, идущие от СЛУЖАЩИЙ как к сущности МАСТЕР, так и к сущности СБОРЩИК, указывают на то, что сущность СЛУЖАЩИЙ является исходной, а сущности МАСТЕР и СБОРЩИК - ролями.
При генерации предварительных отношений, исходя из диаграммы, представленной на рис. 6.21, необходимо руководствоваться следующим правилом.
Исходная сущность служит источником генерации одного отношения, причем ключ сущности служит в качестве ключа отношения.
Ролевые элемент и связи, их соединяющие, порождают такое число отношений, которое определяется ранее описанными правилами, причем каждая роль трактуется как обычная сущность.
В рассматриваемом случае получены следующие три предварительных отношения:
СЛУЖАЩИЙ (служ#,.....),
МАСТЕР (мастер#,.......),
СБОРЩИК (сборщик#,.....,мастер#).
При распределении всех других атрибутов между отношениями, входящими в данной набор, выясняется, что каждому атрибуту находится естественное место. Получаемый в результате окончательный набор отношений имеет вид:
СЛУЖАЩИЙ (служ#, слфам, дтел, сладрес),
МАСТЕР (мастер#, оклад, ртел),
СБОРЩИК (сборщик#, тставка, мастер#).
Отношение, полученное из исходной сущности СЛУЖАЩИЙ, содержит информацию общую для всех служащих. Отношения, полученные из ролей, содержат специфическую для исполняемой роли информацию. Каждое, порождаемое ролью отношение связано с отношением, источником порождения которого послужила исходная сущность, через атрибут из общего домена (в данном примере - табельный номер).
При рассмотрении диаграммы, показанной на рис.6.21 видно, что связь РУКОВОДИТ соединяет две роли одной исходной сущности.
Такой тип связи показывает рекурсивным. Эта связь рекурсивна в том смысле, что с точки зрения исходной сущности служащие руководят служащими. Если роли одной исходной сущности соединяются связью с ролями других исходных сущностей, то связь уже не будет рекурсивной.