Реляционная модель данных

Темы: реляционная модель, типы взаимосвязей в модели, обеспечение непротиворечивости и целостности данных в базе.

1. Реляционная модель.

Реляционная модель (от англ. relation — отношение) была разработана в начале 70-х годов Коддом. Простота и гибкость модели привлекли к ней внимание разработчиков. В 80-х годах она получила широкое распространение, и реляционные СУБД оказались промышленным стандартом.

Модель опирается на систему понятий реляционной алгебры, важнейшие из которых: таблица, строка, столбец, отношение и первичный ключ, а все операции сводятся к манипуляциям с таблицами.

В реляционной модели информация представляется в виде прямоугольных таблиц. Каждая таблица состоит из строк и столбцов и имеет имя, уникальное внутри базы данных.

Таблица отражает объект реального мира — сущность, а каждая ее строка (запись) отражает один конкретный экземпляр объекта — экземпляр сущности. Каждый столбец таблицы имеет уникальное для своей таблицы имя. Столбцы расположены в таблице в соответствии с порядком следования их имен при ее создании. Таблица не может иметь менее одного столбца.

В отличие от столбцов строки не имеют имен, порядок их следования в таблице не определен, а количество логически не ограничено. Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции. Хотя в файле у каждой строки имеется номер, он не характеризует строку. Его значение изменяется при удалении строк из таблицы. Логически среди строк не существует «первой» и «последней»

Реляционные системы исключили необходимость сложной навигации, поскольку данные представлены в них не в виде одного файла, а независимыми наборами, и для отбора данных используются операции реляционной алгебры — прикладной теории множеств.

В каждой таблице реляционной модели должен быть столбец или совокупность столбцов, значения которых однозначно идентифицируют каждую строку таблицы. Этот столбец или их совокупность и называется первичным ключом таблицы (рис 1).

Если таблица удовлетворяет требованию уникальности первичного ключа, она называется отношением. В реляционной модели все таблицы должны быть преобразованы в отношения. Отношения реляционной модели связаны между собой. Связи поддерживаются внешними ключами. Внешний ключ — это столбец (совокупность столбцов), значение которого однозначно характеризует значение первичного ключа другого отношения (таблицы).

Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором та же совокупность столбцов является первичным ключом

В приведенном примере на рис. 1. отношение «СОТРУДНИК» ссылается на отношение «ОТДЕЛ» через название отдела.

Схема реляционной таблицы (отношения) представляет собой совокупность имен полей, образующих запись таблицы:

НАЗВАНИЕ ТАБЛИЦЫ (Поле 1, Поле 2,…, Поле п)

Например, для таблиц на рис. 1 имеем следующие схемы таблиц:

СОТРУДНИК (№ пропуска, Фамилия, Должность, Название отдела, Телефон),

ОТДЕЛ (Название отдела, Расположение отдела, Назначение отдела).

Курсивом в схемах таблиц показаны первичные ключи.

Объектно-ориентированная модель баз данных начала разрабатываться в связи с появлением объектно-ориентированных языков программирования. Появление таких баз приходится на 90-е годы прошлого века. Такого рода базы хранят методы классов, а иногда и постоянные объекты классов, что позволяет осуществлять беспрепятственную интеграцию межу данными и их обработкой в приложениях.

Доминирование реляционной модели в современных СУБД определяется:

1) наличием развитой теории (реляционной алгебры);

2) наличием аппарата сведения других моделей данных к реляционной модели;

3) наличием специальных средств ускоренного доступа к информации;

4) наличием стандартизированного высокоуровневого языка запросов к БД, позволяющего манипулировать ими без знания конкретной физической организации БД во внешней памяти.

2. Типы взаимосвязей в модели: «один к одному», «один ко многим», «многие ко многим»

На практике часто используются связи, устанавливающие различные виды соответствия между объектами «связанных» типов, — «один к одному» (1:1), «один ко многим» (1:М), «многие ко многим» (М:М).

Связь «один к одному» означает, что каждому экземпляру первого объекта (А) соответствует только один экземпляр второго объекта (В) и наоборот, каждому экземпляру второго объекта (В) соответствует только один экземпляр первого объекта (А).

Связь «один ко многим» характеризуется тем, что каждому экземпляру одного объекта (А) может соответствовать несколько экземпляров другого объекта (В), а каждому экземпляру второго объекта (В) может соответствовать только один экземпляр первого объекта (А).

Связь «многие ко многим» означает, что каждому экземпляру одного объекта (А) могут соответствовать несколько экземпляров второго объекта (В) и наоборот, каждому экземпляру второго объекта (В) могут соответствовать тоже несколько экземпляров первого объекта (А).

Пример 1. Рассмотрим совокупность следующих информационных объектов:

СТУДЕНТ (Номер студента. Фамилия И. О., Дата рождения, Номер группы),

СТИПЕНДИЯ (Номер студента, Размер стипендии);

ГРУППА (Номер группы, Специальность);

ПРЕПОДАВАТЕЛЬ (Код преподавателя, Фамилия И.О., Должность)

Информационные объекты СТУДЕНТ и СТИПЕНДИЯ связаны отношением «один к одному», так как каждый студент может иметь только одну стипендию, и каждая стипендия может быть назначена только одному студенту.

Информационные объекты ГРУППА и СТУДЕНТ связаны отношением «один ко многим», так как одна группа может включать много студентов, и в то же время каждый студент может обучаться только в одной группе.

Информационные объекты СТУДЕНТ и ПРЕПОДАВАТЕЛЬ связаны отношением «многие ко многим», так как один студент может обучаться у многих преподавателей, и один преподаватель может обучать многих студентов.

3. Обеспечение непротиворечивости и целостности данных в базе.

Для пользователей АИС важно, чтобы база данных отображала предметную область однозначно и непротиворечиво, т. е. чтобы она удовлетворяла условию целостности.

Выделяют два основных типа ограничений по условию целостности:

1. Каждая строка таблицы должна отличаться от остальных ее строк значением хотя бы одного столбца.

Пример 2. Сотрудники отдела могут оказаться полными тезками, родившимися в один и тот же день. Чтобы не нарушить условия целостности, добавляем в таблицу новый столбец — «№ пропуска», превращая ее в отношение (см. рис. 1). Таким образом, первое ограничение обеспечивается наличием в таблице — отношении первичного ключа.

2. Внешний ключ не может быть указателем на несуществующую строку той таблицы, на которую он ссылается. Это ограничение называется ограничением целостности по ссылкам.

Пример 3. В столбце Название отдела таблицы «СОТРУДНИК» (см. рис. 1) хранятся сведения о принадлежности сотрудников к отделу. Здесь Название отдела является внешним ключом для ссылки на таблицу «ОТДЕЛ». Для обеспечения ограничения целостности по ссылкам каждое Название отдела из таблицы «СОТРУДНИК» должно принадлежать конкретному отделу из таблицы «ОТДЕЛ».

В реальных базах данных названия не делают ключевыми из-за их длины (замедление процесса поиска), а также из-за того, что они могут изменяться (сложности с сопровождением системы).

Лекция 7 (Базы данных)