Реляционная модель данных. Отношения и таблицы.

РМД основана на математическом понятии отношения.

Пусть заданы два множества и , имеющие своими элементами: , . Декартовым произведением этих множеств называется множество всех возможных попарных комбинаций элементов и , в которых на первом месте стоит элемент , а на втором – :

Любое подмножество этого декартова произведения называется отношением. Например, такое:

Физическим аналогом математического отношения является таблица:

	1	3	5
2	(2,1)	(2,3)	(2,5)
4	(4,1)	(4,3)	(4,5)

В теории баз данных отношение – это плоская (двумерная) таблица, состоящая из строк и столбцов. Таблицы в БД используются для хранения информации об определенного типа объектах или процессах реального мира. При этом каждому отдельно взятому объекту или процессу соответствует отдельная строка таблицы. А столбцы таблицы соответствуют отдельным свойствам объектов (процессов).

Например, таблица «Предметы» используется для хранения информации о предметах. При этом каждому наименованию предметов (с учетом цены) соответствует отдельная строка, а столбцы соответствуют свойствам предметов: наименование, ед. измерения, цена.

Поименованный столбец отношения называется атрибутом.

Замечание. Здесь имеет место одно из отличий теории БД от чистой математики. Для математики элементы (2,1) и (1,2) различны. А в базах данных порядок следования столбцов не имеет значения, поскольку они поименованы.

Множество допустимых значений атрибута называется доменом атрибута.

Например, для атрибутов типа «Наименование» домен может быть задан, как символьная строка длиной 50 символов. Для атрибутов типа «Условный номер» – как целое положительное число. И т.п.

Каждый атрибут должен быть определен на некотором домене (т.е. для каждого атрибута следует ограничить область допустимых значений с тем, чтобы уменьшить вероятность возникновения ошибок). На одном домене может быть определено несколько атрибутов, но каждый отдельный атрибут может быть определен только на одном домене.

Строка отношения называется кортежем.

Количество атрибутов (столбцов) в отношении (таблице) называется степенью отношения. Степень отношения обычно величина постоянная и задается в момент создания отношения. Конечно, количество столбцов в таблице может меняться, но это происходит достаточно редко и свидетельствует, как правило, о недоработках допущенных на этапе проектирования БД.

Количество кортежей (строк) в отношении (таблице) называется кардинальностью отношения. Кардинальность отношения обычно величина переменная и изменяется по мере добавления или удаления строк в таблице. При этом существуют так называемые справочные таблицы, которые изменяются редко или вообще не изменяются после начального заполнения (например, таблица типов лиц).

Реляционная модель данных – это совокупность связанных отношений.

Замечание. Обратите внимание, что термину «отношение» в англоязычной среде соответствует термин «relation», а с другой стороны «связь» по-английски также «relation». Поэтому название «реляционная» как нельзя лучше соответствует этой модели данных.

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

Таблица 10. Терминология

Реальный мир	Математика	Модель данных	Локальные БД	Серверные БД
Тип объектов (процессов)	отношение	тип сущности	файл	таблица
Экземпляр объекта (процесса)	кортеж	экземпляр сущности	запись	строка
Свойство объекта (процесса)	атрибут	атрибут	поле	столбец

Реляционные ключи.

Каждой строке в таблице наличия соответствует единственная строка в таблице лиц и единственная строка в таблице предметов. По этим строкам мы можем судить: о наличии какого предмета и у какого лица идет речь в конкретной строке таблице наличия. Очевидно, что для реализации указанной связи необходим механизм, который позволит найти те самые единственно нужные строки в таблицах лиц и предметов, то есть механизм уникальной идентификации строк в таблицах. Этот механизм получил название реляционных ключей. Попытаемся разобраться – как он устроен.

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

Например, для таблицы предметов суперключом является условный номер предмета. Также суперключом является набор атрибутов «наименование» + «цена». Суперключ, который не содержит подмножества атрибутов, также являющегося суперключом, называется потенциальным ключом.

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

Потенциальный ключ, который выбран для уникальной идентификации кортежей некоторого отношения, называется первичным ключом этого отношения (ПК, Primary Key, PK). При этом все остальные потенциальные ключи становятся альтернативными ключами.

Например, если первичный ключ таблицы предметов определить по атрибуту условного номера, то совокупность атрибутов «наименование» + «цена» следует считать альтернативным ключом.

Замечание. Одна и та же таблица в разных своих связях может выступать и как родительская и как дочерняя. Например, таблица лиц в своих связях с таблицами типов лиц и подразделений является дочерней, а в связях с таблицами наличия и проводок – родительской.

Атрибуты первичного ключа родительского отношения, включаемые в дочернее для реализации его связи с родительским отношением, называются внешним ключом (ВК, Foreign Key, FK).

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

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

Первичный ключ должен обеспечивать уникальную идентификацию строк не только при текущем состоянии таблицы, но и с учетом всех возможных изменений в будущем.
Первичный ключ должен иметь минимально возможный размер, поскольку он импортируется во все дочерние отношения в качестве внешних ключей. Соответственно, большой размер первичного ключа приведет к неоправданному росту объема дочерних отношений.
Атрибуты первичного ключа должны изменяться как можно реже. Дело в том, что всякое изменение атрибутов первичного ключа влечет за собой соответствующие изменения атрибутов внешних ключей. Например, если условный номер лица изменился с 5 на 25, то во всех соответствующих строках таблиц наличия и проводок значение 5 необходимо заменить значением 25.

5. Отношение "один ко многим". Родительские и дочерние таблицы.

В каждой паре связанных таблиц можно указать родительскую (главную, Master) и дочернюю (подчиненную, Detail) таблицу. При этом каждая запись дочерней таблицы должна ссылаться на единственную соответствующую ей запись родительской таблицы. А любая запись родительской таблицы может быть связана с несколькими записями дочерней. Например, для связи таблиц предметов и наличия имеем следующую схему:

Предметы Наличие

Усл. №	Наимен.	Ед. изм.	Цена	Лицо	Предмет	Кол-во
. . .				. . .
12	Стул	шт	800.00	3	7	2
23	Кресло	шт	2000.00	3	12	8
7	Стол	шт	1600.00	17	12	3
. . .				9	7	5
				9	12	20
				. . .

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

Связи типа один-ко-многим – это основной вид связей в реляционных базах данных. Гораздо реже встречаются связи типа один-к-одному, при которых одной родительской записи соответствует одна дочерняя и наоборот. Такого рода связи возникают, например, в тех случаях, когда отношение делится на две таблицы с тем, чтобы вынести в отдельную таблицу редко используемые атрибуты или атрибуты, к которым необходимо ограничить доступ (фото, пароли и т.п.).

При проектировании БД часто приходится иметь дело со связями типа многие-ко-многим. Например, подотчетные лица отвечают за хранение предметов (у одного п/о лица хранится множество предметов и один и тот же предмет может быть у нескольких лиц). Однако такого рода связи не могут быть реализованы в рамках реляционной модели данных и на этапе логического проектирования заменяются парами связей типа один-ко-многим.

Итак, основной вид связей в РБД это связи типа один-ко-многим. Очевидно, что для их реализации необходимо иметь возможность найти в родительской таблице ту единственную запись, которая соответствует текущей дочерней записи. То есть, в родительском отношении обязательно должен присутствовать механизм уникальной идентификации. Отсюда следует вывод.

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

Первичные и внешние ключи.

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

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

3. Атрибуты первичного ключа должны изменяться как можно реже. Дело в том, что всякое изменение атрибутов первичного ключа влечет за собой соответствующие изменения атрибутов внешних ключей. Например, если условный номер лица изменился с 5 на 25, то во всех соответствующих строках таблиц наличия и проводок значение 5 необходимо заменить значением 25.

Индексы и ключи.

Такая таблица называется индексом таблицы «Наличие» по полю «Лицо».

Такой подход позволяет значительно ускорить поиск нужных строк, поскольку:

1. Таблица индекса имеет меньший объем, чем исходная таблица, т.к. содержит только индексируемые поля.

2. Записи в индексе упорядочены по значениям полей поиска.

3. Поиск в таблице индекса ведется не прямым перебором записей, а с использованием специальных алгоритмов, ускоряющих эту процедуру (например, делением пополам области поиска).

Таким образом, индексы позволяют существенно ускорить операции поиска, а также операции сортировки. С другой стороны, реализация связей между дочерними и родительскими таблицами сводится к выполнению операций поиска (поиск нужной родительской записи или всех соответствующих дочерних записей). Здесь возникает очевидная идея использовать для ускорения операций поиска соответствующие индексы. Именно по этой причине во всех СУБД по определениям первичных и внешних ключей всегда строятся индексы. Причем делается это независимо от желания пользователя.

Такая взаимосвязь между ключами и индексами породила некоторую путаницу при использовании этих понятий. Нередко можно встретить использование термина «ключ» в отношении индекса и наоборот. Во избежание проблем следует запомнить:

1. Ключи – это, по существу, логическая конструкция, определяющая принципы взаимосвязи между родительскими и дочерними отношениями.

2. Индексы – это физический механизм, позволяющий значительно ускорить выполнение операций поиска и сортировки и используемый, в частности, для реализации ключевых взаимодействий.

Индексы, создаваемые по определениям ключей, принято называть первичными. Помимо них для ускорения поиска и сортировки могут создаваться индексы и по неключевым полям. Их называют вторичными. При создании таких индексов следует иметь в виду, что индексы, с одной стороны, ускоряя поиск и сортировку, с другой стороны, замедляют выполнение операций по изменению содержимого индексируемых таблиц. Дело в том, что всякое изменение значений индексных полей требует соответствующих изменений в таблицах индексов. При этом полная перестройка индексных таблиц невозможна из-за неприемлемых временных затрат. Приходится достраивать индексы по определенным правилам, но накопление такого рода достроек приводит к падению эффективности индексного поиска. Рано или поздно наступает ситуация, при которой прямой перебор содержимого таблицы оказывается более выгодным, чем использование «плохого» индекса.

Таким образом, индексы не являются универсальным средством, которое можно использовать везде и всюду для повышения производительности. Кроме того, они требуют специальных мероприятий по поддержанию своей полезности. Необдуманное применение индексов может не только оказаться неэффективным, но и замедлит работу всей БД.

В заключение рассмотрим некоторые разновидности индексов.

Составной индекс – это индекс, построенный по нескольким полям. При этом порядок следования полей в индексе суть важен. Например, индекс таблицы наличия по полям «Лицо» + «Предмет»:может быть использован как для поиска по паре полей «Лицо» + «Предмет», так и для поиска по полю «Лицо», но не может быть использован для поиска по полю «Предмет», поскольку по этому полю он не упорядочен.

Уникальный (Unique) индекс – это индекс, в котором каждому набору значений индексных полей может соответствовать только одна запись. Такого рода индексы строятся, например, по определениям первичных и альтернативных ключей. В нашем примере имеет смысл построить уникальный индекс в таблице предметов по полям «Наименование» + «Цена» с тем, чтобы сделать невозможным добавление одного и того же предмета дважды.

Регистрочувствительный (Case Sensitive) индекс – это индекс, учитывающий регистр букв при сортировке.

Индекс в обратном порядке (Descending) – это индекс, построенный в порядке убывания значений индексных полей (обычный индекс строится в порядке возрастания). Такие индексы часто используются для упорядочения по датам с тем, чтобы вначале располагались более поздние даты. Например, таблицу проводок имеет смысл сортировать в порядке убывания их дат, чтобы в первую очередь видеть более поздние проводки.

Дата добавления: 2018-05-31; просмотров: 1184; Мы поможем в написании вашей работы!

Поделиться с друзьями:

⇐ Предыдущая 1 234 5 6 7 8 9 10 Следующая ⇒

Мы поможем в написании ваших работ!