- •Реляционные базы данных
- •Цели проектирования баз данных
- •Универсальные отношения
- •Проблемы, связанные с использованием единственного отношения
- •Проблема вставки.
- •Проблема обновления.
- •Проблема удаления.
- •Функциональные зависимости
- •Нормальные формы отношений Первая нормальная форма
- •Вторая нормальная форма
- •Третья нормальная форма
- •Третья усиленная форма или нормальная форма Бойса–Кодда (нфбк)
- •Декомпозиция отношений
- •Избыточные функциональные зависимости. Правила вывода
- •Правило 1. Транзитивные зависимости
- •Пример удаления избыточных зависимостей с помощью правил вывода
- •Общая схема проектирования баз данных методом декомпозиции
- •Построение отношений для базы данных “Начальник отдела”.
- •Выявление функциональных зависимостей
- •Декомпозиция универсального отношения
- •Семантическое моделирование или проектирования баз данных методом “Сущность-связь”
- •Сущности и связи
- •Диаграмма еr–экземпляров:
- •Диаграмма er–типа:
- •Терминология метода “Сущность-связь”
- •Степень связи
- •Класс принадлежности сущности
- •Примеры диаграмм er-типа связей степени 1:1.
- •Примеры диаграмм er-типа связей степени 1:n и n:1
- •Примеры диаграмм er-типа связей степени m:n
- •Порядок или мерность связи
- •Бинарные связи со степенью связи 1: 1
- •Правило 1.
- •Правило 2.
- •Правило 3.
- •Бинарные связи со степенью связи 1: n
- •Правило 4.
- •Правило 5.
- •Бинарные связи степени m:n.
- •Правило 6.
- •Пример проектирования с использованием связей степенью м:n
- •Связи более высокого порядка
- •Правило 7
- •Пример проектирования с использованием связей более высокого порядка
- •Использование ролей
- •Правило 8
- •Пример проектирования с использованием ролей
Реляционные базы данных
Реляционная модель предложена сотрудником компании IBM Е.Ф.Коддом в 1970 г. В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.
В реляционной модели достигается гораздо более высокий уровень абстракции данных, чем в иерархической или сетевой. Представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название “реляционная” происходит от английского relation – “отношение”).
Домен - это семантическое понятие, которое можно рассматривать как подмножество значений некоторого типа данных имеющих определенный смысл. Домен характеризуется следующими свойствами:
Домен имеет уникальное имя (в пределах базы данных).
Домен определен на некотором простом типе данных или на другом домене.
Домен может иметь некоторое логическое условие, позволяющее описать подмножество данных, допустимых для данного домена.
Домен несет определенную смысловую нагрузку.
Например, домен D, имеющий смысл “возраст сотрудника” можно описать как следующее подмножество множества натуральных чисел:
D={nєN: n≥18 and n≤60}
Основное значение доменов состоит в том, что домены ограничивают сравнения. Некорректно, с логической точки зрения, сравнивать значения из различных доменов, даже если они имеют одинаковый тип. В этом проявляется смысловое ограничение доменов.
Кортежи – это упорядоченная совокупность элементов доменов.
Математическое описание отношения :
пусть даны множества D1,D2,…,Dn – домены и существует ряд кортежей вида <d1, d2,…,dn>; di D, тогда декартовым произведением
D = D1•D2•D3•…•Dn называется множество всех возможных кортежей.
Пример:
D1 = { красный, синий }
D2 = { карандаш, фломастер, ручка }
D3 = { +, – }
D = D1•D2•D3 = { |
<красный, |
карандаш, |
+> |
|
<… |
… |
…> |
|
<синий, |
ручка, |
–>} |
Отношением R на доменах D1, D2,… ,D3 называется подмножество декартового произведения R D.
С точки зрения организации данных отношения удобно изображать в виде таблиц (таблица 6.1):
Таблица 6.1 |
||
Цвет |
Предмет |
Наличие |
Красный |
Карандаш |
+ |
Красный |
Карандаш |
– |
… |
… |
… |
Синий |
Ручка |
– |
Термины, которыми оперирует реляционная модель данных, имеют соответствующие “табличные” синонимы:
Таблица 6.2 |
|
Реляционный термин |
Соответствующий “табличный” термин |
База данных |
Набор таблиц |
Отношение |
Таблица (файл) |
Атрибут отношения |
Наименование столбца таблицы (поле) |
Кортеж отношения |
Строка таблицы (запись) |
Степень (-арность) отношения |
Количество столбцов таблицы |
Мощность отношения |
Количество строк таблицы |
Реляционная база данных есть совокупность отношений содержащих информацию о предметной области.
Степень отношения – это количество доменов (столбцов) образующих данное отношение, как правило, степень отношения в процессе жизненного цикла не меняется.
Мощность отношения – это количество кортежей отношения (количество строк в таблице). В общем случае она изменяется с течением времени.
Замечание.
По определению в отношении не может содержаться два идентичных кортежа. Многие реляционные СУБД допускают хранение файлов данных идентичных записей. Если в каком-либо приложении хранение идентичных записей недопустимо, программист должен позаботься об этом лично.
Расмотрим простую реляционную базы данных состоящую из трех таблиц (Таб. 6.3-6.5).
Таблица 6.3 “Поставщик”. |
||
№ поставщика |
Название поставщика |
Город |
2 |
Нормаль |
Н.Новгород |
1 |
Красная Этна |
Н.Новгород |
3 |
Уралмаш |
Екатеринбург |
4 |
Нормаль |
Москва |
Таблица 6.4 “Деталь”. |
|
№ детали |
Название детали |
4 |
Болт 17 |
8 |
Шпильки |
1 |
Гайка 22 |
2 |
Гайка 10 |
Таблица 6.5 “Поставщик – Деталь”. |
||
№ поставщика |
№ детали |
Количество |
1 |
1 |
20 |
1 |
2 |
10 |
2 |
1 |
7 |
3 |
8 |
20 |
БД содержит три типа информации.
Информация о поставщиках деталей на предприятие (таблица 6.3):
номер поставщика;
наименование детали;
название города.
Информация о деталях, используемых на предприятии (таблица 6.4):
номер детали;
наименование детали.
Информация о номере и количестве поступления деталей от каждого поставщика (таблица 6.5)
Каждое отношение храниться в отдельном файле. Структура файла, хранящего отношение проста, то есть все записи имеют одинаковый формат.
Первичный ключ - это атрибут или набор атрибутов, значение которых однозначно указывают на конкретный кортеж отношения. Первичный ключ должен быть минимальным набором атрибутов.
Число отношений в БД и конкретные атрибуты, приписываемые каждому отношению определяются в процессе проектирования БД, который может быть довольно продолжительным. После проектирования создание БД средствами СУБД может пойти достаточно быстро.
В таблице 6.6 описаны типы данных для атрибутов БД “Поставщики и детали”.
Таблица 6.6 Типы Атрибутов. |
|
Название атрибута |
Тип атрибута |
Пном |
Числовой (3) |
Пназ |
Символьный(16) |
Гор |
Символьный(15) |
Дназ |
Символьный(10) |
Штук |
Числовой (5) |
Дном |
Числовой (5) |
Отношения с указанными первичными ключами для данной БД:
Поставщик |
(Пном, Пназ, Гор) |
Деталь |
(Дном, Дназ) |
Поставщик-Деталь |
(Пном, Дном, Штук) |
Результатом проектирования является концептуальная модель БД.