Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Лекция 2
Реляционная модель данных
В лекции рассматривается наиболее распространенная реляционная модель представления данных; дается определение реляционной модели и характеристика ее элементов; связывание таблиц и контроль целостности связей, описываются индексирование.
Часть 1. Определение реляционной модели
Реляционная модель данных (РМД) некоторой предметной области представляет собой набор отношений, изменяющихся во времени.
При создании информационной системы совокупность отношений позволяет хранить данные об объектах предметной области и моделировать связи между ними.
Элементы РМД и формы их представления приведены в табл.1.
Таблица 1.
|
Элемент реляционной модели |
Форма представления |
|
Отношение |
Таблица |
|
Схема отношения |
Строка заголовков столбцов таблицы (заголовок таблицы) |
|
Кортеж |
Строка таблицы |
|
Сущность |
Описание свойств объекта |
|
Атрибут |
Заголовок столбца таблицы |
|
Домен |
Множество допустимых значений атрибута |
|
Значение атрибута |
Значение поля в записи |
|
Первичный ключ |
Один или несколько атрибутов |
|
Тип данных |
Тип значений элементов таблицы |
Сущность есть объект любой природы, данные о котором хранятся в базе данных. Данные о сущности хранятся в отношении.
Отношение является важнейшим понятием и представляет собой двумерную таблицу, содержащую некоторые данные.
Атрибуты представляют собой свойства, характеризующие сущность. В структуре таблицы каждый атрибут именуется и ему соответствует заголовок некоторого столбца таблицы.
Математически отношение можно описать следующим образом.
Пусть даны n множеств Dl, D2, D3,..., Dn, тогда отношение R есть множество упорядоченных кортежей <dl, d2, d3 ,..., dn>, где dk Dk,
dk - атрибут, a Dk - домен отношения R.
На рис. 1 приведен пример представления отношения СОТРУДНИК.
В общем случае порядок кортежей в отношении, как и в любом множестве, не определен. Однако в реляционных СУБД для удобства кортежи все же упорядочивают. Чаще всего для этого выбирают некоторый атрибут, по которому система автоматически сортирует кортежи по возрастанию или убыванию.
Если пользователь не назначает атрибута упорядочения, система автоматически присваивает номер кортежам в порядке их ввода.
Рис. 1. Представление отношения СОТРУДНИК
Формально, если переставить атрибуты в отношении, то получается новое отношение. Однако в реляционных БД перестановка атрибутов не приводит к образованию нового отношения.
Домен представляет собой множество всех возможных значений определенного атрибута отношения.
Отношение СОТРУДНИК включает 4 домена:
Каждый домен образует значения одного типа данных, например, числовые или символьные.
Отношение СОТРУДНИК содержит 3 кортежа. Кортеж рассматриваемого отношения состоит из 4 элементов, каждый из которых выбирается из соответствующего домена. Каждому кортежу соответствует строка таблицы.
Схема отношения (заголовок отношения) представляет собой список имен атрибутов.
Например, для приведенного примера схема отношения имеет вид СОТРУДНИК (ФИО, Отдел, Должность, Д_Рождения).
Множество кортежей отношения часто называют содержимым или телом отношения.
Первичным ключом (ключом отношения, ключевым атрибутом) называется атрибут отношения (либо комбинация атрибутов), однозначно идентифицирующий каждый из его кортежей.
Ключ может быть составным (сложным), то есть состоять из нескольких атрибутов.
Каждое отношение обязательно имеет комбинацию атрибутов, которая может служить ключом. Ее существование гарантируется тем, что отношение - это множество, которое не содержит одинаковых элементов - кортежей. То есть в отношении нет повторяющихся кортежей, а это значит, что, по крайней мере, вся совокупность атрибутов обладает свойством однозначной идентификации кортежей отношения.
Например, в отношении СОТРУДНИК (ФИО, Отдел, Должность, Д_Рождения) не удается найти такую комбинацию атрибутов, которая могла бы служить первичным ключом отношения.
Возможны случаи, когда отношение имеет несколько комбинаций атрибутов, каждая из которых однозначно определяет все кортежи отношения. Все эти комбинации атрибутов являются возможными ключами отношения. Любой из возможных ключей может быть выбран как первичный.
Если выбранный первичный ключ состоит из минимально необходимого набора атрибутов, говорят, что он является не избыточным.
Во многих СУБД допускается создавать отношения, не определяя ключи.
Ключи обычно используют для достижения следующих целей:
Понятие внешнего ключа :
Пусть в отношении R1 имеется не ключевой атрибут А, значения которого являются значениями ключевого атрибута В другого отношения R2. Тогда говорят, что атрибут А отнощения R1 есть внешний ключ.
С помощью внешних ключей устанавливаются связи между отношениями.
Например, имеются два отношения
СТУДЕНТ (ID_студента, Фамилия, Группа, Специальность) и
ПРЕДМЕТ (Назв_предмета, Часы),
которые связаны отношением
СТУДЕНТ_ ПРЕДМЕТ(ID_студента, Назв_предмета, Оценка).
Изобразите самостоятельно графически связь этих отношений.
В связующем отношении атрибуты ID_студента и Назв_предмета образуют составной ключ. Эти атрибуты представляют собой внешние ключи, являющиеся первичными ключами других отношений.
Реляционная модель накладывает на внешние ключи ограничение для обеспечения целостности данных, называемое ссылочной целостностью.
Это означает, что каждому значению внешнего ключа должны соответствовать строки в связываемых отношениях.
Поскольку не всякой таблице можно поставить в соответствие отношение, приведем условия, выполнение которых позволяет таблицу считать отношением:
Наиболее часто таблица с отношением размещается в отдельном файле.
В некоторых СУБД одна отдельная таблица (отношение) считается базой данных. В других СУБД база данных может содержать несколько таблиц.
В общем случае можно считать, что БД включает одну или несколько таблиц, объединенных смысловым содержанием, а также процедурами контроля целостности и обработки информации в интересах решения некоторой прикладной задачи.
Например, при использовании СУБД Microsoft Access в файле БД наряду с таблицами хранятся и другие объекты базы: запросы, отчеты, формы, макросы и модули.
Таблица данных обычно хранится на магнитном диске в отдельном файле операционной системы, поэтому по ее именованию могут существовать ограничения. Имена полей хранятся внутри таблиц. Правила их формирования определяются СУБД, которые, как правило, на длину полей и используемый алфавит серьезных ограничений не накладывают.
Если задаваемое таблицей отношение имеет ключ, то считается, что таблица тоже имеет ключ, и ее называют ключевой или таблицей с ключевыми полями.
У большинства СУБД файл таблицы включает управляющую часть (описание типов полей, имена полей и другая информация) и область размещения записей.
К отношениям можно применять систему операций, позволяющую получать одни отношения из других. Например, результатом запроса к реляционной БД может быть новое отношение, вычисленное на основе имеющихся отношений. Поэтому можно разделить обрабатываемые данные на хранимую и вычисляемую части.
Основной единицей обработки данных в реляционных БД является отношение, а не отдельные его кортежи (записи).
Часть 2. Индексирование
Как отмечалось выше, определение ключа для таблицы означает автоматическую сортировку записей, контроль отсутствия повторений значений в ключевых полях записей и повышение скорости выполнения операций поиска в таблице.
Для реализации этих функций в СУБД применяют индексирование.
Термин «индекс» тесно связан с понятием «ключ», хотя между ними есть и некоторое отличие.
Под индексом понимают средство ускорения операции поиска записей в таблице, а следовательно, и других операций, использующих поиск: извлечение, модификация, сортировка и т. д.
Таблицу, для которой используется индекс, называют индексированной.
Можно сказать, что индекс выполняет роль оглавления таблицы, просмотр которого предшествует обращению к записям таблицы.
В некоторых системах, например, Paradox, индексы хранятся в индексных файлах, хранимых отдельно от табличных файлов.
Варианты решения проблемы организации физического доступа к информации зависят в основном от следующих факторов:
В поле ключа индексного файла можно хранить значения ключевых полей индексируемой таблицы либо свертку ключа (так называемый хеш-код).
Преимущество хранения хеш-кода вместо значения состоит в том, что длина свертки независимо от длины исходного значения ключевого поля всегда имеет некоторую постоянную и достаточно малую величину (например, 4 байта), что существенно снижает время поисковых операций.
Недостатком хеширования является необходимость выполнения операции свертки (требует определенного времени), а также борьба с возникновением коллизий (свертка различных значений может дать одинаковый хеш-код).
Для организации ссылки на запись таблицы могут использоваться три типа адресов: абсолютный (действительный), относительный и символический (идентификатор).
На практике чаще всего используются два метода поиска: последовательный и бинарный (основан на делении интервала поиска пополам).
Проиллюстрируем организацию индексирования таблиц двумя схемами: одноуровневой и двухуровневой. При этом примем ряд предположений, обычно выполняемых в современных вычислительных системах. Пусть ОС поддерживает прямую организацию данных на магнитных дисках, основные таблицы и индексные файлы хранятся в отдельных файлах. Информация файлов хранится в виде совокупности блоков фиксированного размера, например целого числа кластеров.
При одноуровневой схеме в индексном файле хранятся короткие записи, имеющие два поля: поле содержимого старшего ключа (хеш-кода ключа) адресуемого блока и поле адреса (физического адреса) начала этого блока (рис. 3).
Рис. 3. Одноуровневая схема индексации
В каждом блоке записи располагаются в порядке возрастания значения ключа или свертки. Старшим ключом каждого блока является ключ его последней записи.
Если в индексном файле хранятся хеш-коды ключевых полей индексированной таблицы, то алгоритм поиска нужной записи (с указанным ключом) в таблице включает в себя следующие три этапа:
Основным недостатком одноуровневой схемы является то, что ключи (свертки) записей хранятся вместе с записями. Это приводит к увеличению времени поиска записей из-за большой длины просмотра (значения данных в записях приходится пропускать).
Двухуровневая схема в ряде случаев оказывается более рациональной, в ней ключи (свертки) записей отделены от содержимого записей (рис. 4).
Рис. 4. Двухуровневая схема индексации
В этой схеме индекс основной таблицы распределен по совокупности файлов: одному файлу главного индекса и множеству файлов с блоками ключей.
Ключевые поля таблицы во многих СУБД, как правило, индексируются автоматически. На практике для создания индекса для некоторой таблицы БД пользователь указывает поле таблицы, которое требует индексации.
Индексные файлы, создаваемые по ключевым полям таблицы, часто называются файлами первичных индексов.
Индексы, создаваемые пользователем для не ключевых полей, иногда называют вторичными (пользовательскими) индексами.
Введение таких индексов не изменяет физического расположения записей таблицы, но влияет на последовательность просмотра записей. Индексные файлы, создаваемые для поддержания вторичных индексов таблицы, обычно называются файлами вторичных индексов.
Связь вторичного индекса с элементами данных базы может быть установлена различными способами. Один из них - использование вторичного индекса как входа для получения первичного ключа, по которому затем с использованием первичного индекса производится поиск необходимых записей (рис. 5).
Рис. 5. Способ использования вторичных индексов
Некоторыми СУБД, например Access, деление индексов на первичные и вторичные не производится. В этом случае используются автоматически создаваемые индексы и индексы, определяемые пользователем по любому из не ключевых полей.
Главная причина повышения скорости выполнения различных операций в индексированных таблицах состоит в том, что основная часть работы про изводится с небольшими индексными файлами, а не с самими таблицами. Наибольший эффект повышения производительности работы с индексированными таблицами достигается для значительных по объему таблиц.
Индексирование требует небольшого дополнительного места на диске и незначительных затрат процессора на изменение индексов в процессе работы. Индексы в общем случае могут изменяться перед выполнением запросов к БД, после выполнения запросов к БД, по специальным командам пользователя или программным вызовам приложений.
Часть 3. Связывание таблиц
При проектировании реальных БД информацию обычно размещают в нескольких таблицах. Таблицы при этом связаны семантикой информации. В реляционных СУБД для указания связей таблиц производят операцию их связывания.
Укажем выигрыш, обеспечиваемый в результате связывания таблиц. Многие СУБД при связывании таблиц автоматически выполняют контроль целостности вводимых в базу данных в соответствии с установленными связями. В конечном итоге это повышает достоверность хранимой в БД информации.
Кроме того, установление связи между таблицами облегчает доступ к данным. Связывание таблиц при выполнении таких операций, как поиск, просмотр, редактирование, выборка и подготовка отчетов, обычно обеспечивает возможность обращения к произвольным полям связанных записей. Это уменьшает количество явных обращений к таблицам данных и число манипуляций в каждой из них.
Основные виды связей между таблицами
Между таблицами могут устанавливаться бинарные (между двумя таблицами), тернарные (между тремя таблицами) и, в общем случае, n-арные связи. Рассмотрим наиболее часто встречающиеся бинарные связи.
При связывании двух таблиц выделяют основную и дополнительную (подчиненную) таблицы. Логическое связывание таблиц производится с помощью ключа связи.
Ключ связи, по аналогии с обычным ключом таблицы, состоит из одного или нескольких полей, которые в данном случае называют полями связи (ПС).
Суть связывания состоит в установлении соответствия полей связи основной и дополнительной таблиц. Поля связи основной таблицы могут быть обычными и ключевыми. В качестве полей связи подчиненной таблицы чаще всего используют ключевые поля.
В зависимости от того, как определены поля связи основной и дополнительной таблиц (как соотносятся ключевые поля с полями связи), между двумя таблицами в общем случае могут устанавливаться следующие четыре основных вида связи:
Характеристика видов связей таблиц приведена в табл. 2.
Таблица 2.
Дадим характеристику названным видам связи между двумя таблицами и приведем примеры их использования.
Связь вида 1:1
Связь вида 1:1 образуется в случае, когда все поля связи основной и дополнительной таблиц являются ключевыми. Поскольку значения в ключевых полях обеих таблиц не повторяются, обеспечивается взаимно-однозначное соответствие записей из этих таблиц. Сами таблицы, по сути, здесь становятся равноправными и могут быть объединены в одну таблицу.
Самостоятельно приведите примеры таких связей.
Связь вида 1:М
Связь 1:М имеет место в случае, когда одной записи основной таблицы соответствует несколько записей вспомогательной таблицы.
Самостоятельно приведите примеры таких связей.
Связь вида М:1
Связь М:1 имеет место в случае, когда одной или нескольким записям основной таблицы ставится в соответствие одна запись дополнительной таблицы.
Пример. Рассмотрим связь таблиц А и B.
В основной таблице А содержится информация о названиях деталей (Название), видах материалов, из которого детали можно изготовить (Материал), и марках материала (Марка).
В дополнительной таблице B содержатся сведения о названиях деталей (Название), планируемых сроках изготовления (Срок_изготовления) и стоимости заказов (Стоимость_заказа).
Таблица А
+
|
Название |
Материал |
Марка |
|
деталь 1 |
чугун |
марка1 |
|
деталь 1 |
чугун |
марка2 |
|
деталь2 |
сталь |
марка1 |
|
деталь2 |
сталь |
марка2 |
|
деталь2 |
сталь |
маркаЗ |
|
детальЗ |
алюминий |
- |
|
деталь4 |
чугун |
марка2 |
Таблица B
* +
|
Название |
Срок_изготовления |
Стоимость_заказа |
|
деталь 1 |
4.03.98 |
90 |
|
деталь2 |
3.01.98 |
35 |
|
детальЗ |
17.02.98 |
90 |
|
деталь4 |
6.05.98 |
240 |
В таком случае, поменяв таблицы местами, можно получить связь вида 1:М.
Отсюда следует, что вид связи (1: М или М: 1) зависит от того, какая таблица является главной, а какая дополнительной.
Связь вида М:М
Самый общий вид связи М:М возникает в случаях, когда нескольким записям основной таблицы соответствует несколько записей дополнительной таблицы.
Пример.
Пусть в основной таблице А содержится информация о том, на каких станках могут работать рабочие некоторой бригады. Таблица B содержит сведения о том, кто из бригады ремонтников какие станки обслуживает.
Таблица A
* +
|
Работает |
На станке |
|
Иванов А.В. |
станок1 |
|
Иванов А.В. |
станок2 |
|
Петров Н.Г. |
станок1 |
|
Петров Н.Г. |
станокЗ |
|
Сидоров В.К. |
станок2 |
Таблица B.
|
Обслуживает |
Станок |
|
Голубев А.М. |
станок1 |
|
Голубев А.М. |
Станок3 |
|
Зыков Н.Г. |
Станок2 |
|
Зыков Н.Г. |
Станок3 |
|
Зыков Н.Г. |
Станок1 |
Очевидно, аналогично связи 1:1, связь М:М не устанавливает подчиненности таблиц. Для проверки этого можно основную и дополнительную таблицу поменять местами и выполнить объединение информации путем связывания. Результирующие таблицы А+B» и B+А будут отличаться лишь порядком следования отдельных полей, а также порядком расположения записей.
Такую структуру необходимо переделать и привести итоговые таблицы к связи 1:М.
Замечание
На практике в связь обычно вовлекается сразу несколько таблиц. При этом одна из таблиц может иметь различного рода связи с несколькими таблицами. В случаях, когда связанные таблицы, в свою очередь, имеют связи с другими таблицами, образуется иерархия или дерево связей.
Часть 4. Контроль целостности связей
Из перечисленных видов связи чаще используется связь вида 1:М. Связь вида 1:1 можно считать частным случаем связи 1:М, когда одной записи главной таблицы соответствует одна запись вспомогательной таблицы. Связь М:1, по сути, является «зеркальным отображением» связи 1:М. Оставшийся вид связи М:М характеризуется как слабый вид связи или даже как отсутствие связи. Поэтому в дальнейшем рассматривается связь вида 1:М.
Напомним, что при образовании связи вида 1:М одна запись главной таблицы (главная, родительская запись) оказывается связанной с несколькими записями дополнительной (дополнительные, подчиненные записи) и имеет место схема, показанная на рис. 6.
Рис. 6. Связь 1:М записей двух таблиц
Контроль целостности связей обычно означает анализ содержимого двух таблиц на соблюдение следующих правил:
Опишем действие контроля целостности при манипулировании данными в таблицах. Рассмотрим три основные операции над данными двух таблиц:
При рассмотрении попытаемся охватить все возможные методы организации контроля целостности. В реальных СУБД могут применяться собственные методы, подобные описываемым.
При вводе новых записей возникает вопрос определения последовательности ввода записей в таблицы такой, чтобы не допустить нарушение целостности. Исходя из приведенных правил, логичной является схема, при которой данные сначала вводятся в основную таблицу, а потом — в дополнительную. Очередность ввода может быть установлена на уровне целых таблиц или отдельных записей (случай одновременного ввода в несколько открытых таблиц).
В процессе заполнения основной таблицы контроль значений полей связи ведется как контроль обычного ключа (на совпадение со значениями тех же полей других записей). Заполнение полей связи дополнительной таблицы контролируется на предмет совпадения со значениями полей связи основной таблицы. Если вновь вводимое значение в поле связи дополнительной таблицы не совпадет ни с одним соответствующим значением в записях основной таблицы, то ввод такого значения должен блокироваться.
Модификация записей. Изменение содержимого полей связанных записей, не относящихся к полям связи, очевидно, должно происходить обычным образом. Нас будет интересовать механизм изменения полей связи.
При редактировании полей связи дополнительной таблицы очевидным требованием является то, чтобы новое значение поля связи совпадало с соответствующим значением какой-либо записи основной таблицы. То есть дополнительная запись может сменить родителя, но остаться без него не должна.
Редактирование поля связи основной таблицы разумно подчинить одному из следующих правил:
В операциях удаления записей связанных таблиц большую свободу, очевидно, имеют записи дополнительной таблицы. Удаление их должно происходить практически бесконтрольно.
Удаление записей основной таблицы логично подчинить одному из следующих правил: