- •1. Основы построения баз данных 11
- •2. Модели представления данных 22
- •3. ДатАлогические модели данных 38
- •4. Семантическое моделирование 101
- •5. Базы данных в сетях 155
- •6.Современное состояние и 177
- •1. Основы построения баз данных
- •1.1. Архитектура системы баз данных
- •1.2. Жизненный цикл базы данных
- •Контрольные вопросы и задания
- •2. Модели представления данных
- •2.1. Классификация моделей данных
- •2.2. Разновидности инфологических моделей данных
- •Контрольные вопросы и задания
- •3. ДатАлогические модели данных
- •3.1. Иерархические модели
- •Между предками и потомками автоматически поддерживается целостность ссылок. Основное правило: никакой потомок не может существовать без своего родителя, у некоторых родителей не может быть потомков.
- •3.2. Сетевые модели
- •3.3. Реляционные модели
- •3.3.1. Основные понятия реляционной модели
- •3.3.2. Реляционная алгебра
- •3.3.3. Язык запросов по образцу qbe
- •3.3.4. Структурированный язык запросов sql
- •Основные инструкции языка sql
- •Values ("3110", "чп Иванов п.Т.", null)
- •3.4. Проектирование реляционных баз данных
- •Контрольные вопросы и задания
- •4. Семантическое моделирование
- •4.1. Объектно-ориентированное проектирование
- •4.1.1. Представление объектов
- •4.1.2. Описания классов
- •4.1.3. Атрибуты в odl
- •4.1.4. Связи в odl
- •4.1.5. Обратные связи
- •4.1.6. Множественность связей
- •4.1.7. Типы в odl
- •4.1.8. Проектирование с использованием odl
- •Правильность
- •Устранение избыточности
- •4.1.9. Подклассы
- •4.1.10. Множественное наследование в odl
- •4.1.11. Моделирование ограничений
- •Ссылочная целостность
- •Прочие ограничения
- •4.1.12. Переход от объектно-ориентированной модели к реляционной
- •4.2. Диаграммы "сущность-связь"
- •4.2.1. Компоненты диаграмм "сущность-связь"
- •4.2.2. Множественность e/r-связей
- •Многосторонние связи
- •4.2.3. Роли в связях
- •4.2.4. Атрибуты связей
- •4.2.5. Конвертирование многосторонних связей в бинарные
- •4.2.6. Проектирование e/r моделей
- •Простота
- •Типы элементов проекта
- •Определения подклассов
- •Наследование в e/r-модели
- •Моделирование ограничений
- •Ссылочная целостность
- •Слабые множества сущностей
- •Переход от e/r-диаграмм к реляционным проектам
- •Контрольные вопросы и задания
- •5. Базы данных в сетях
- •5.1. Архитектура "клиент-сервер"
- •5.2. Распределенные базы данных
- •5.3. Базы данных в Интернет
- •Контрольные вопросы и задания
- •Контрольные вопросы и задания
- •Информационные ресурсы Internet
- •Словарь терминов
- •Список сокращений
- •Темы рефератов
Переход от e/r-диаграмм к реляционным проектам
Переход от диаграммы "сущность-связь" к реляционной схеме БД принципиально аналогичен переходу к ней от проекта ODL. Данный переход достаточно хорошо формализуем.
Все простые сущности преобразуется в таблицу. Простая сущность – сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.
Атрибуты становится возможными столбцами с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, – не могут.
Ключи ER-модели преобразуются в первичный ключ таблицы. Если имеется несколько возможных ER-ключей, выбирается наиболее используемый ключ. Если в состав ключа ER-модели входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.
Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи – столбцам, не допускающим неопределенные значения.
Индексы создаются для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.
Если в концептуальной схеме присутствовали слабые сущности, то возможны два способа:
все слабые сущности в одной таблице (а);
для каждой слабые сущности – отдельная таблица (б).
При применении способа (а) таблица создается для наиболее внешнего супертипа, а для подтипов могут создаваться представления.
При использовании метода (б) для каждого подтипа первого уровня (для более нижних используются представления) супертип воссоздается с помощью представления UNION (из всех таблиц подтипов выбираются общие столбцы – столбцы супертипа).
При наличии исключающих связей (сущность может быть расщеплена на два или более взаимно исключающих подтипа, каждый из которых включает общие атрибуты и/или связи) имеется два способа работы.
общий домен (а);
явные внешние ключи (б).
Если остающиеся внешние ключи находятся все в одном домене, т.е. имеют общий формат (способ (а)), то создаются два столбца: идентификатор связи и идентификатор сущности. Столбец идентификатора связи используется для различения связей, покрываемых дугой исключения. Столбец идентификатора сущности используется для хранения значений уникального идентификатора сущности на дальнем конце соответствующей связи.
Если результирующие внешние ключи не относятся к одному домену, то для каждой связи, покрываемой дугой исключения, создаются явные столбцы внешних ключей; все эти столбцы могут содержать неопределенные значения.
Преимущества перехода к схеме БД от E/R-моделей по сравнению с ODL-проектом заключаются в следующем:
Отношения часто можно "нормализовать", избегая избыточности, присутствующей в проекте, полученном непосредственно из описания ODL.
Двухсторонние связи ODL заменяются единственным отношением, представляющим связи в обоих направлениях.
В заключение раздела необходимо отметить, что приведенная графическая нотация диаграмм “сущность-связь" не является единственно допустимой. Существуют и другие способы изображения, например, сущности могут изображаться прямоугольниками, содержащими имя и список атрибутов; в соответствии с изображением сущностей, связи также могут быть представлены определенным образом.