
- •Сикха Багуи и Ричард Ирп
- •Контрольные вопросы 1.1
- •Модели данных
- •Иерархическая Модель
- •Сетевая модель
- •Реляционная модель
- •Контрольные вопросы 1.2
- •Функциональные зависимости
- •Правило декомпозиции (разложения)
- •Правило объединения
- •Контрольные вопросы 1.3
- •Краткий обзор метода нормальных форм
- •Примеры 1нф, 2нф и 3нф
- •Упражнение 1.3
- •Глава 2: Базовая er-диаграмма – схема
- •Некоторые определения баз данных: Сущность, Связь, Атрибут
- •Начальная Методология
- •Еще об атрибутах
- •Простые или атомарные атрибуты
- •Многозначные атрибуты
- •Производный атрибуты
- •Описание Сущности на структурном английском языке
- •Сущность
- •Атрибуты
- •Методология er-проектирования
- •Примеры
- •Сущность
- •Атрибуты
- •Методология er проектирования
- •Итоги главы
- •Упражнения Главы
- •Упражнение 2.1
- •Упражнение 2.2
- •Проработка примера
- •Сущность
- •Глава 3: После первой диаграммы сущности
- •Проверка Сущности — замена атрибута сущностью
- •Методология er-проектирования
- •Определение вторичной сущности
- •Существует ли связь?
- •Атрибут или Связь?
- •Глава 4: Расширение связей/ Структурные
- •1(Полное участие):1:
- •Глава 5: Слабая Сущность
- •Грамматика Слабой Сущности
- •Контрольные вопросы 5.3
- •Упражнения Главы 5. Упражнение 5.1
- •Список литературы
- •Сущность
- •Атрибуты для отдела
- •Сущность
- •Атрибуты для служащего
- •Глава 6: Дальнейшее Расширение
- •Сущность
- •Атрибуты
- •Более двух Сущностей
- •С указанием всех атрибутов
- •Развитие базы данных
- •Глава 7: Троичные и er-диаграммы более высокого порядка
- •Глава 8: Обобщения и специализации.
- •Глава 9: Реляционные преобразования и
- •Глава 10: Краткий обзор модели Баркера
- •Глава 10. Упражнения.
Глава 3: После первой диаграммы сущности
Теперь, когда мы предложили методику изображения, интерпретации и уточнения одной первичной сущности, можно перейти к более сложным базам данных. Для дальнейшего развития базы данных, продолжим рассмотрение нашей первичной сущности и поищем другую информацию, которая могла бы стать отдельной сущностью.
Первый прием, применяемый в этой главе, имеет методологический характер. Мы проверяем нашу первичную сущность для того, чтобы выяснить, являются или нет наши «атрибуты» сами по себе отдельными сущностями. Далее мы ищем в описании другие части информации и: (1) добавляем их к существующей сущности в качестве атрибутов и проверяем существующую ER-диаграмму, или (2) создаем непосредственно новую сущность. После создания новой сущности следует определить тип связи между двумя сущностями. В данной главе описываются 3, 4, 5 шаги методологииER-проектирования. Шаг 3 проверяет атрибуты первичной сущности, шаг 4 определяет действия при необходимости добавления еще одной сущности, шаг 5 устанавливает связи между двумя сущностями.
Хотя в этой главе рассматривается понятие связи, мы не включаем в нее никаких новых правил преобразования, в силу того, что эти правила лучше усвоятся после наложения структурных ограничений на связи, которые обсуждаются в Главе 4. В конце этой главы, мы продолжаем изучение примера, которое начали в Главе 2.
Проверка Сущности — замена атрибута сущностью
Рассмотрим Рисунок 3.1. На этом рисунке, изображена сущность студент со следующими атрибутами: имя (составной атрибут), студенческий номер (атомарный атрибут и ключ), школы (многозначный атрибут). Предположим, что во время нашего первого общения с пользователем, мы показываем диаграмму, структурное описание и примеры данных, и пользователь говорит: "Подождите, я хочу записать все школы, которые посещал студент и я хочу записать не только название школы, но также местонахождение (город и штат) и тип школы (колледж, университет, средняя школа и т.п.)".
Рисунок 3.1: Сущность СТУДЕНТ с многозначным атрибутом
Пользователь хочет нам сказать, что атрибут Школа должен в действительности быть сущностью. Вспомните, что определение сущности таково - что-то, о чем мы хотим записать информацию. Изначально мы записывали посещенные школы, а теперь говорим, что хотим записать информацию о школах. Первый признак того, что атрибут должен считаться сущностью - необходимость ввода информации об атрибуте.
Следовательно, преобразуем Рисунок 3.1 в Рисунок 3.2. На Рисунке 3.2 ШКОЛА является теперь самостоятельным объектом, итак, теперь у нас есть две различные сущности: ШКОЛА и СТУДЕНТ. Следующий шаг должен определить связь между двумя сущностями. Предположим, что название школы – уникально и выберем название_школы в качестве ключа для сущности ШКОЛА.
Рисунок 3.2: Две ER Диаграммы: СТУДЕНТ и ШКОЛА
Определение связи для новой сущности
Базы данных предназначены для хранения связанных данных. Например, нет ничего необычного в том, чтобы записывать данные о студентах и иностранной валюте или о полетах авиакомпании и рабочих на заводе по производству теннисных мячей в одной и той же базе данных. Эти понятия не связаны. В базе данных необходимо создавать совокупность связанных данных. Следуя нашему методу, мы прояснили ситуацию, в которой атрибут был частью сущности (школа считалась "частью" студента), но теперь школа стала самостоятельной сущностью. Теперь необходимо связать сущность ШКОЛА и сущность СТУДЕНТ.
На Рисунке 3.2 - две сущности, но они кажутся независимыми. Чтобы преобразовать сущность ШКОЛА и сущность СТУДЕНТ в базу данных, надо что-то добавить — связь сущности ШКОЛА и сущности СТУДЕНТ.
Связь в ER диаграмме – это соединение между собой двух и более сущностей или с самим собой. Последний тип связи, сам с собой, известен как рекурсивная связь, которую мы обсудим позже (в Главе 6). Название связи – обычно глагол или глагольная форма, которая обозначает связь между сущностями. Как только мы поймем, как обозначаются связи, у нас появится "инструмент" представления базы данных в форме ER диаграммы.
В Chen модели, связь изображена ромбом и линиями, соединяющими две сущности, как изображено на Рисунке 3.3.
Рисунок 3.3: Сущность СТУДЕНТ со связью к сущности ШКОЛА
На Рисунке 3.3, отношение изображено как «посещает». Значение связи является глаголом, соединяющим оба существительных (обе сущности). Связь является двухсторонней. Как видно, необходимо указывать все связи в обоих направлениях. Например, в Chen моделях, мы можем неформально сказать, "СТУДЕНТЫ посещают ШКОЛЫ" или "ШКОЛЫ посещаются СТУДЕНТАМИ".
Степень связи зависит от количества сущностей, которые участвуют в отношении. На Рисунке 3.3 две сущности участвуют в отношении «посещает», такая связь называется двоичной.
Теперь мы имеем средство, чтобы "изобразить" описание базы данных в виде ER диаграммы. Назначение наших диаграмм – в том, что мы записываем информацию об x и об y (x и y - сущности) и затем сообщаем, какова связь между x и y.
Наша дополненная и скорректированная методология теперь выглядит так