Реляционные базы данных.
В реляционных БД все данные структурированы (т.е. хранятся) в виде двумерных таблиц, между которыми установлены связи. Каждая таблица представляет собой (т.е. моделирует) информационный объект, называемый сущностью.
Сущность, а следовательно и таблица, моделируют множество предметов реального мира (предметной области), которые описываются одним и тем же набором характеристик и следуют одним и тем же правилам и линиям поведения.
Пример сущности – стол. Это понятие описывает множество столов, существующих в реальной предметной области, причем каждый из столов может быть описан одним и тем же набором характеристик (инвентарный номер, высота, ширина, длина, назначение) и каждый стол следует одним и тем же правилам и линиям поведения (ни один экземпляр из этого множества не может летать). А вот стол с инвентарным номером 91235 и конкретными другими характеристиками (высота=0.8 м, ширина=1.2м и т.д.) является экземпляром данной сущности.
Таким образом, каждая таблица в БД моделирует сущность из описываемой предметной области.
Каждая строка таблицы (называемая записью) описывает экземпляр этой сущности.
Каждый столбец таблицы (называемый полем) моделирует одну характеристику сущности. Каждый столбец таблицы предназначен для хранения данных определенного типа: текстовых, числовых, дат, времени, денежных и т.д.
Несмотря на то, что сущностей в реальном мире существует бесконечное множество, большинство сущностей можно отнести к одной из следующих категорий:
― Реальные сущности– это объекты реального мира, существующие физически. Например: стол, самолет, человек, насос и т.д.
― Ролевые сущности (роли)– это термины, определяющие назначение отдельного человека, организации, оборудования и т.д. Например: мастер цеха, студент, бухгалтерия и т.п.
― Инциденты– это события, случающиеся в реальной жизни. Например: заказ товара, оплата счета, отгрузка товара, получение путевки и т.д.
― Взаимодействия– это сущности, возникающие из отношений (связей) сущностей друг с другом.
― Спецификации– это сущности, используемые для представления правил, стандартов или критериев качества.
Поля в таблицах могут относиться к одному из следующих видов:
― Идентифицирующие (или первичные ключи) – это поле или набор полей, однозначно идентифицирующий запись таблицы (экземпляр сущности). Значение первичного ключа в таблице БД должно быть уникальным, т.е. в таблице не должно существовать двух или более записей с одинаковым значением первичного ключа. Каждая таблица обязательно должна иметь первичный ключ. Первичные ключи обеспечивают установление связи между таблицами.
― Описательные– это поля, содержащие значения, присущие отдельным экземплярам сущности.
― Вспомогательные (или внешние ключи) – это поля, добавляемые в таблицу для организации её связи с другой таблицей. Эти поля добавляют к таблице только на этапе организации связей между таблицами.
Для любого поля таблицы (или группы полей) может быть назначен индекс, облегчающий поиск нужных строк (записей) таблицы. При индексировании полей таблицы СУБД создает дополнительную служебную таблицу, которая содержит упорядоченные значения индексированных полей и физические адреса записей. Поэтому поиск значений по индексированным полям таблицы осуществляется значительно быстрее, чем по неиндексированным полям. Однако избыточное количество индексов в таблице существенно замедляет процессы записи и модификации такой таблицы, т.к. СУБД вынуждена модифицировать не только саму таблицу, но и соответствующие ей индексные таблицы. Поэтому злоупотреблять индексами при создании таблиц базы данных не следует.
Лекция 2
Реляционные отношения между таблицами базы данных.
Записи различных таблиц могут быть связанными друг с другом логически, т.е. одной записи из первой таблицы могут соответствовать одна или несколько записей из другой таблицы.
На этапе построения реляционной модели данных какой-либо предметной области в целях более компактного представления вместо реальных таблиц будем пользоваться их макетами. На рис.1 представлена таблица с данными (а) и макет (б). Название таблицы указывается в заголовочной области макета, а первичный ключ в макете таблицы выделяется жирным шрифтом.
а)
б)
Рис.1. Пример таблицы с данными и ёё макета.
Всё многообразие логических отношений между таблицами в реляционных базах данных моделируется тремя видами связей:
– Один-к-одному (1:1).
– Один-ко-многим (1:∞).
– Многие-ко-многим (∞:∞).
Одна из связанных таблиц (на стороне «один») называется главнойтаблицей, а вторая называется подчиненной таблицей. Для реализации связей между таблицами используются их поля: первичный ключ в главной таблице и внешний ключ в подчиненной таблице.
Связь Один-к-одному (1:1)означает, что одной записи из главной таблицы соответствует одна запись из подчиненной таблицы. Эта связьмежду таблицами на практике встречается чрезвычайно редко, т.к. этой связи можно избежать простым слиянием двух таблиц. Однако, если таблица будет содержать слишком много столбцов (например, свыше 15-20 столбцов), то в этом случае целесообразно создать две таблицы, связав их отношением 1:1. Для реализации связи 1:1 в подчиненной таблице в качестве внешнего ключа необходимо использовать первичный ключ. Например, в информационных системах кадрового состава организаций для учета личных сведений о сотруднике используется около 100 показателей. Поэтому личные сведения о сотруднике целесообразно разнести по нескольким таблицам, связав их затем отношением 1:1. Для связи можно использовать поле «Табельный номер», которое однозначно идентифицирует каждого сотрудника организации. Пример такой связи приведен на рис.2.
Рис.2. Пример связи 1:1 между таблицами
Связь Один-ко-многим (1:∞)означает, что одной записи из главной таблицы соответствует много записей из подчиненной таблицы. На практике это наиболее распространенный вид связи. Для реализации этой связи необходимо первичный ключ из главной таблицы добавить в качестве внешнего ключа к подчиненной таблице. При этом добавленное поле в качестве внешнего ключа к подчиненной таблице обязательно надо индексировать (совпадения допускаются) при создании таблицы в выбранной СУБД. Кроме того, необходимо отслеживать, чтобы тип поля первичного ключа главной таблицы совпадал с типом поля внешнего ключа подчиненной таблицы.Например, таблицы «Континенты» и «Страны» связаны отношением 1:∞, т.к. одной записи из таблицы «Континенты» соответствует несколько записей из таблицы «Страны» (рис.3).
Рис.3. Пример связи 1:∞ между таблицами
Для реализации связи 1:∞ на рис.3 к таблице «Страны» (подчиненная таблица) добавлено поле «Код_континента» в качестве внешнего ключа, являющегося первичным ключём в таблице «Континенты» (главная таблица).
Связь Многие-ко-многим (∞:∞)означает, что одной записи из первой таблицы соответствует много записей из второй таблицы, и в то же время одной записи из второй таблицы соответствует много записей из первой. Такой вариант логической связи между сущностями (таблицами) на практике встречается довольно часто. Однако, ни одна из современных реляционных СУБД не имеет средств реализации такого рода связи. Для реализации связи ∞:∞ её надо разбить на две связи 1:∞, добавив в базу данных дополнительную таблицу. Эта дополнительная таблица называется ассоциативнойи относится к категории сущностей – «Взаимодействия». Несмотря на то, что ассоциативная таблица добавляется в базу данных исключительно для реализации связи ∞:∞, она в базе данных обладает равными правами с другими таблицами, т.е. должна обязательно иметь первичный ключ и может участвовать в свою очередь в других связях с таблицами базы данных, т.е. может иметь и внешние ключи.
Например, к рассмотренным выше таблицам «Континенты» и «Страны» добавим таблицу «Полезные ископаемые». Как установлено выше, таблицы «Континенты» и «Страны» связаны отношением 1:∞. Определим связь между добавленной таблицей «Полезные ископаемые» и таблицей «Страны»: каждая страна может иметь множество полезных ископаемых в своих недрах, в то же время одно и то же полезное ископаемое может добываться в различных странах. Следовательно, таблицы «Страны» и «Полезные ископаемые» связаны отношением ∞:∞. Для реализации этой связи в базу данных следует добавить дополнительную (ассоциативную) таблицу. Назовем эту таблицу «Полезные ископаемые в странах». Добавленная таблица связана отношением 1:∞ с таблицей «Страны» и отношением 1:∞ с таблицей «Полезные ископаемые». Из таблицы «Страны» добавим в ассоциативную таблицу в качестве внешнего ключа поле «Код страны», а из таблицы «Полезные ископаемые» добавим поле «Код полезного ископаемого» также в качестве внешнего ключа. Кроме этих полей, включим в ассоциативную таблицу «Полезные ископаемые в странах» еще описательное поле «Разведанные запасы».
Поскольку в ассоциативной таблице поля «Код страны» и «Код полезного ископаемого» будут повторяться, но их сочетание будет уникальным, то в качестве первичного ключа в ассоциативной таблице выберем эти два поля, т.е. первичный ключ в ассоциативной таблице будет составным. Полученная реляционная модель данных для этого примера представлена на рис.4, где связь ∞:∞ между таблицами «Страны» и «Полезные ископаемые») разбита на две связи 1:∞ через ассоциативную таблицу «Полезные ископаемые в странах».
Рис.4. Пример связи ∞:∞ между таблицами «Страны» и
«Полезные ископаемые»
Дата добавления: 2016-04-06; просмотров: 1583;