- •Введение
- •Глава 1. Проектирование баз данных
- •1.1. История развития баз данных и субд
- •1.2. Введение в субд
- •1.2.1. Основные термины, понятия и определения
- •1.2.2. Классификация субд
- •1) Сетевые, корпоративные, распределенные, клиент-серверные, полнофункциональные, масштабируемые, “большие” субд.
- •2) Локальные, персональные, настольные, файл-серверные, “малые” субд.
- •1.3. Модели данных
- •1.3.1. Типы связей между объектами
- •1.3.2. Формы записи инфологической (концептуальной) модели
- •1.3.3. Уровни представления и независимости данных
- •1.3.4. Порядок взаимодействия пользователя, субд и ос
- •1.3.5. Поддержка целостности базы данных
- •1.3.6. Иерархическая модель
- •1.3.7. Сетевая модель
- •1.3.8. Реляционная модель
- •1.3.8.1. Отношения
- •1.3.8.2. Теоретико-множественные операции с отношениями
- •1.3.8.3. Правила Кодда
- •1.3.8.4. Индексирование таблиц
- •1.3.8.5. Связывание таблиц
- •1.3.9. Постреляционная модель
- •1.3.10. Многомерная модель
- •1.3.11. Объектно‑ориентированная модель
- •1.4. Модели использования баз данных в сети
- •1.4.1. Сеть
- •1.4.2. Модели использования баз данных
- •1.4.2.1. Локальная однопользовательская модель
- •1.4.2.2. Файл-серверная модель
- •1.4.2.3. Клиент-серверная модель
- •В моделях «клиент–сервер»
- •1.4.2.4. Модель удаленного доступа (rda)
- •1.4.2.5. Модель сервера данных
- •1.4.2.6. Трехзвенная распределенная модель
- •1.4.2.7. Модели серверов баз данных
- •1.4.2.8. Клиент-Интернет
- •1.4.2.9. ИнтерфейсOdbc
- •1.4.3. Мониторы обработки транзакций (tpm)
- •1.4.4. Децентрализованное управление базами данных
- •1.4.5. Таблицы в локальных сетях
- •1.5. Проектирование баз данных
- •1.5.1. Принципы и этапы проектирования и создания баз данных
- •1.4.Определение доменов атрибутов.
- •1.5. Определение первичных и вторичных ключей.
- •1.6. Определение суперклассов и подклассов для типов сущностей.
- •1.7. Создание er‑диаграмм для отдельных пользователей.
- •2.6. Создание er‑диаграмм для отдельных пользователей.
- •3.4. Создание er‑диаграммы глобальной логической модели.
- •4. Создание глобальной логической модели в среде целевой субд.
- •6. Разработка механизма защиты.
- •1.5.3. Правила формирования взаимосвязанных таблиц
- •1.5.4. Модели жизненного цикла и проектирование баз данных
- •1.5.4.1. Модели жизненного цикла
- •1.5.4.2. Обследование, системный анализ и постановка задачи
- •1.5.4.3. Инфологическое проектирование
- •1.5.4.4. Датологическое проектирование
- •1.5.4.5. Проектирование физической модели
- •1.5.4.6. Реализация, интеграция и внедрение
- •1.5.5. Выбор субд
- •1.5.5.1. Сравнение Visual FoxPro, Access, sql Server, Oracle и Excel
- •1.5.5.2. Методика балловой оценки программных средств
- •1.5.6. Case‑средства автоматизации проектирования
- •1. Ориентация на этапы жизненного цикла
- •2. Функциональная полнота
- •Пользователя в ms sql Server 7.0
- •1.6.2. Резервирование информации
- •1.6.3. Варианты разработки приложений
- •1.7. Стандартизация баз данных
- •1.8. ЯзыкSql
- •1.8.1. Введение вSql
- •1.8.2. Типы данныхSql
- •1.8.3. Оператор выбора данныхSelect
- •1.8.3.1. Назначение и синтаксис оператора
- •1.8.3.2. Объединение таблиц
- •1.8.3.3. Вложенные и коррелированные запросы
- •1.8.3.4. Запросы, использующиеExist, any, all
- •1.8.3.5. Стандартные функции
- •1.8.3.6. Запрос с группировкой
- •1.8.4. Операторы обновления базы
- •1.8.4.1. Оператор корректировки данныхUpdate
- •1.8.4.2. Оператор удаления записейDelete
- •1.8.4.3. Оператор включения записей insert
- •1.8.5. Представления
- •1.9. Транзакции
- •1.9.1. Определение транзакций
- •1.9.2. Организация транзакций
- •1.9.3. Журнал транзакций
- •1.9.4. Журнализация и буферизация
- •1.9.5. Индивидуальный откат транзакций
- •1.9.6. Восстановление после мягкого сбоя
- •1.9.7. Физическая согласованность базы данных
- •1.9.8. Восстановление после жесткого сбоя
- •1.9.9. Параллельное выполнение транзакций
- •1.9.10. Уровни изолированности пользователей
- •1.9.11. Гранулированные синхронизационные захваты
- •1.9.12. Предикатные синхронизационные захваты
- •1.9.13. Метод временных меток
- •1.10. ВстроенныйSql
- •1.10.1. Особенности встроенногоSql
- •1.10.2. Определение курсора
- •1.10.3. Открытие курсора
- •1.10.4. Чтение очередной строки курсора
- •1.10.5. Закрытие курсора
- •1.10.6. Удаление и обновление данных
- •1.10.7. Хранимые процедуры
- •Хранимой процедуры на сервере
- •1.10.8. Триггеры
- •1.10.9. ДинамическийSql
- •1.11. Архитектура субд и оптимизация запросов
- •1.12. Перспективы развития субд
- •Вопросы для самопроверки и контроля
- •1Оглавление
1.3. Модели данных
1.3.1. Типы связей между объектами
Связь (отношение) между родительским (основным, ведущим) и дочерним (подчиненным, ведомым) объектами (таблицами) производится по равенству значений ключа связи (ключ может состоять из нескольких атрибутов или полей связи) в обеих таблицах.
Совокупность объектов и их взаимосвязей вне зависимости от конкретной СУБД называют инфологическойиликонцептуальной модельюилисхемой. Объекты в такой схеме обычно называют узлами. Родительский объект можно назвать исходным узлом, а дочерний ‑ подчиненным.
При связывании объектов используются следующие понятия:
Корневые узлы‑ узлы без исходных узлов.
Терминальные узлы (листья)‑ узлы без подчиненных узлов.
Подобные узлы‑ подчиненные узлы с одним исходным узлом.
Семейство‑ множество подобных узлов.
Размерность исходного узла‑ число подобных узлов.
Первичный ключ‑ уникальный ключ, используемый для связи с другим дочерним объектом. Такой ключ может быть только один на объект (обычно это родительский объект). В качестве первичного ключа выбирают тот, который имеет наименьший размер и редко меняется.
Вторичный ключ (альтернативный, дополнительный, кандидат)‑ ключ, который может быть первичным, но его место уже занято.
Внешний ключ ‑ атрибут или группа атрибутов дочернего объекта, которые являются первичным ключом в родительском объекте (атрибут “Код подразделения” в дочернем объекте “СОТРУДНИК” является внешним ключом, так как он является первичным ключом в родительском объекте “ПОДРАЗДЕЛЕНИЕ”).
Суррогатный ключ- это дополнительное служебное поле, добавленное к уже имеющимся информационным полям таблицы, единственное предназначение которого - служить первичным ключом. Значение этого поля не образуется на основе каких-либо других данных из БД, а генерируется искусственно, обычно, поле типа счетчик. Такой ключ бывает полезен тем, что он фиксирует хронологию создания записей и также нужен при отсутствии естественного ключа в таблице при переводе базы данных с одной СУБД на другую, например, с СУБДAccessна СУБДSQLServerили при формировании журнала аудита (изменений).
Класс принадлежности объекта(КП) ‑ обязательный (все экземпляры объекта участвуют в рассматриваемой связи) и необязательный.
Типы (степени) связей между объектами
Тип связи “Один-к-одному”, или бинарная связь (1:1). Полями связи являются ключевые поля. Одной записи родительского объекта “A” соответствует только одна запись дочернего объекта “B” и наоборот (A<-->B).
Пример.Связь между объектами “ПРЕПОДАВАТЕЛЬ” и “ПРЕДМЕТ” по полям связи “Табельный номер преподавателя” и “Код предмета”.
Связь типа “Один-ко-многим” (1:М). Полями связи являются ключевое поле родительского объекта и неключевое поле дочернего объекта. Одной записи родительского объекта “A” соответствует несколько записей дочернего объекта “B” (A-->>B). Объект “A” называют односвязанным, а “B” ‑ многосвязанным.
Пример.Связь между объектами “ПРЕПОДАВАТЕЛЬ” и “ПРЕДМЕТ”, если допускается преподавание одним преподавателем нескольких предметов, но один предмет не может преподаваться несколькими преподавателями.
Связь типа “Многие-к-одному” (М:1). Полями связи являются неключевое поле родительского объекта “А” и ключевое поле дочернего объекта ‘B” (A<=B).
Пример.Связь между объектами “ПРЕПОДАВАТЕЛЬ” и “ПРЕДМЕТ”, если допускается преподавание одним преподавателем не более одного предмета, но один предмет может преподаваться несколькими преподавателями.
Связь типа “Многие-ко-многим” (М:М). Полями связи являются неключевые поля родительского и дочернего объектов. Одной записи родительского объекта “A” соответствуют несколько записей дочернего объекта “B” и наоборот (A<=>B). Такие связи не реализуются непосредственно. Для из реализации вводится дополнительный совместный дочерний объект-связка, который связывает эти два родительских объекта двумя связями 1:М.
Пример.Связь между объектами “ПРЕПОДАВАТЕЛЬ” (атрибутами табельный номер преподавателя, фамилия, имя и отчество) и “ПРЕДМЕТ” (код предмета, наименование предмета), если допускается преподавание одним преподавателем нескольких предметов и один предмет может преподаваться несколькими преподавателями.
Введем совместный объект-связку “Учебная нагрузка преподавателя” с атрибутами табельный номер преподавателя, код предмета, количество учебных часов, которые отводятся на изучение данного предмета для данного преподавателя (рисунок 1.3.1.1).
Рисунок 1.3.1.1 – Концептуальная модель
Установим связь между этим дочерним объектом и двумя родительским объектами по атрибутам табельный номер преподавателя и кодом предмета соответственно.
Тип связи обычно указывается над линией связи между объектами символами “1”, “M”. Для наглядности связи типа “M” на схеме она может быть указана в виде линии с двумя стрелочками или “гусиной лапкой” или знаком бесконечности, а отношение 1 ‑ в виде линии с вертикальной чертой.