- •1 Основные понятия и определения
- •1.1Информационные системы и банки данных
- •1.2Назначение и основные компоненты банка данных
- •1.3Трех уровневая архитектура абстракций базы данных.
- •1.4Физическая и логическая независимость данных
- •1.5Администратор базы данных
- •1.6Системы управления базами данных
- •1.7Схема обмена данными при работе с базой данных
- •1.8Локальные информационные системы
- •1.9Информационные системы в сетях
- •2Модели данных концептуального уровня
- •2.1Иерархическая модель данных
- •2.2Сетевая модель
- •2.3Реляционная модель
- •2.4Постреляционная модель
- •2.5Многомерная модель
- •2.6Объектно-ориентированная модель
- •3Физические модели баз данных
- •3.1Файловые структуры, используемые в базах данных
- •3.2 Хешированные файлы
- •3.2.1Стратегия разрешения коллизий с областью переполнения
- •3.2.2Организация стратегии свободного замещения
- •3.3Индексные файлы
- •3.3.1Файлы с плотным индексом, или индексно-прямые файлы
- •3.3.2Файлы с неплотным индексом, или индексно-последовательные файлы
- •3.3.3Организация индексов в виде b-tree (в-деревьев)
- •3.4Моделирование отношений «один-ко-многим» на файловых структурах
- •3.5Инвертированные списки
- •3.6Модели бесфайловой организации данных
- •4Реляционная модель данных
- •4.1Основные определения
- •4.2Соглашения об отношениях в реляционных системах
- •4.3Классы отношений
- •4.3.1Классы отношений с точки зрения способов создания и хранения
- •4.3.2Классификация отношений с точки зрения их содержания
- •4.4Операции реляционной алгебры
- •4.4.1Основные понятия
- •4.4.2Базовые теоретико-множественные операции
- •4.4.3Специальные операции реляционной алгебры
- •4.4.4Связи между отношениями (таблицами)
- •4.5Реляционное исчисление
- •4.6Язык запросов по образцу qbe
- •4.7Структурированный язык запросов sql
- •4.7.1История развития sql
- •4.7.2Общая характеристика языка
- •4.7.3Структура sql
- •4.7.4Оператор выбора select
- •4.7.5Применение агрегатных функций и группировки
- •4.7.6Раздел order by и ключевое слово top
- •4.7.7Вложенные запросы
- •4.7.8Внутренние и внешние объединения
- •4.7.9Перекрестные запросы
- •4.7.10Операторы манипулирования данными
- •4.7.11Запросы на создание таблиц
- •4.7.12Использование языка определения данных
- •4.8Правила Кодда (требования к реляционным бд)
- •5Проектирование баз данных
- •5.1Этапы проектирования бд
- •5.2Проблемы проектирования реляционных баз данных
- •5.3Нормализация отношений
- •5.4Метод сущность-связь
- •5.5Средства автоматизации проектирования
- •5.5.1Основные определения
- •5.5.2Модели жизненного цикла
- •5.5.3Модели структурного проектирования
- •5.5.4Объектно-ориентированные модели
- •5.5.5 Классификация case-средств
- •6Защита информации в базах данных
- •6.1Общие подходы к обеспечению безопасности данных
- •6.2Назначение и проверка полномочий, проверка подлинности
- •6.3Средства защиты базы данных
- •7Базы данных в сетях
- •7.1Организация базы данных в локальной сети
- •7.2Модели архитектуры клиент-сервер
- •7.3Управление распределенными данными
- •8История развития баз данных
4.4.4Связи между отношениями (таблицами)
Обычно база данных представляет собой набор связанных таблиц. Связывание таблиц дает следующие преимущества:
многие СУБД при связывании таблиц автоматически выполняют контроль целостности вводимых в базу данных в соответствии с установленными связями, что повышает достоверность хранимой в БД информации;
облегчается доступ к данным. Связывание таблиц при выполнении таких операций, как поиск, просмотр, редактирование, выборка и подготовка отчетов с использованием информации из разных таблиц уменьшает количество явных обращений к таблицам данных и число манипуляций в каждой из них.
Существует несколько разновидностей связей между отношениями. Связанные отношения часто взаимодействуют по принципу главная и подчиненная таблицы. Главную таблицу можно еще называть родительской, а подчиненную – дочерней. Одна и та же таблица может быть главной по отношению к одной таблице базы данных и дочерней по отношению к другой.
Связь «один-ко-многим» означает, что одной записи в родительской таблице может соответствовать несколько записей (в том числе и одна) в дочерней таблице. В родительской таблице могут быть записи, для которых в данный момент нет соответствующих записей в дочерней таблице. Различают также жесткую связь «один-ко-многим», когда каждой записи в родительской таблице должны соответствовать записи в дочерней таблице.
Связь «один-ко-многим» является самой распространенной для реляционных баз данных. Пример связи: таблицы «Студенты» и «Экзамены» могут быть связаны связью «один-ко-многим» по полю «Номер Зачетки». Данная связь будет означать, что одна запись о студенте из таблицы «Студенты» может быть связана с несколькими записями о сдаче экзаменов данным студентом в таблице «Экзамены».
Связь «один-к-одному» имеет место, когда одной записи в родительской таблице соответствует только одна запись в дочерней таблице. Данная связь встречается редко и означает, что информация из двух таблиц могла бы быть объединена в одну. Наличие двух таблиц говорит о желании разделить основную и второстепенную информацию на два отношения. Например, информация о студентах может быть разделена на две таблицы «Студенты» и «Дополнительные сведения», которые будут связаны связью «один-к-одному» по полю «Номер зачетки». Связь «один-к-одному» приводит к тому, что для чтения связанной информации в нескольких таблицах приходится производить несколько операций чтения, что замедляет получение нужной информации. Связь «один-к-одному» может быть жесткой и нежесткой.
Третий вид связи – связь «многие-ко-многим». Данный вид связи означает, что несколько записей одной таблицы связаны с несколькими записями другой таблицы и наоборот. Например: между таблицами «Учебные группы и дисциплины» и «Преподаватели» может существовать связь «многие-ко-многим». Это означает, что каждый преподаватель может вести несколько предметов и, в то же время, один и тот же предмет могут вести несколько преподавателей.
Некоторые СУБД не поддерживают целостность БД при наличии связи «многие-ко-многим», хотя и позволяют реализовывать ее в таблицах неявным образом. Считается, что базу данных всегда можно перестроить так, чтобы любая связь «многие-ко-многим» была заменена на одну или более связей «один-ко-многим».