Файл: Виды связей между таблицами в реляционных базах данных (Основные понятия БД и СУБД).pdf

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

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

Глава 3. Реляционный подход.

3.1 Реляционная структура данных

В конце 60-х годов появились работы, в которых обсуждались возможности применения различных табличных даталогических моделей данных, т.е. возможности использования привычных и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), где, вероятно, впервые был применен термин "реляционная модель данных".

Будучи математиком по образованию Э.Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение – relation (англ.).

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

Доменом называется множество атомарных значений одного и того же типа. Смысл доменов состоит в следующем. Если значения двух атрибутов берутся из одного и того же домена, то, вероятно, имеют смысл сравнения, использующие эти два атрибута (например, для организации транзитного рейса можно дать запрос "Выдать рейсы, в которых время вылета из Москвы в Сочи больше времени прибытия из Архангельска в Москву"). Если же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено смысла: стоит ли сравнивать номер рейса со стоимостью билета? Отношение на доменах D1, D2, ..., Dn (не обязательно, чтобы все они были различны) состоит из заголовка и тела. На рис. 3 приведен пример отношения для расписания движения самолетов.

Заголовок состоит из такого фиксированного множества атрибутов A1, A2, ..., An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2,...,n).

Тело состоит из изменяющегося во времени набора кортежей, где каждый кортеж, в свою очередь, состоит из набора пар атрибут-значение (Ai: Vi), (i = 1,2, ..., n), одна такая пара для каждого атрибута Ai в заголовке. Для любой данной пары атрибут-значение (Ai: Vi) Vi - это значение из одного домена Di, связанного с атрибутом Ai.

Степень связи - это количество ее атрибутов. Отношение первой степени называется унарным, второй степени - двоичным, третьей степени - тернарным, ..., а степени n - n-арным.

Кардинальное число или мощность отношения - это количество его кортежей. Кардинальное число отношения меняется со временем, а не его степень.

Поскольку отношение - это набор, а наборы, по определению, не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольный данный момент времени. Пусть R - отношение с атрибутами A1, A2, ..., An. Набор атрибутов K = (Ai, Aj, ..., Ak) отношения R называется возможным ключом R тогда и только тогда, когда выполняются два независимых от времени условия:

1. Единственность: в произвольный данный момент времени никакие два разных набора R не имеют одинакового значения для Ai, Aj, ..., Ak.

1. Минимальность: ни один из атрибутов Ai, Aj, ..., Ak не может быть исключен из K без нарушения единственности.

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

Вышеупомянутые и некоторые другие математические концепции явились теоретической основой для создания реляционных СУБД, разработки соответствующих языковых инструментов и программных систем, обеспечивающих их высокую производительность, и создания основ теории проектирования баз данных. Однако для обычного пользователя реляционных СУБД неформальные эквиваленты этих концепций могут быть успешно использованы:

Взаимосвязь - таблица (иногда файл),

Кортеж - строка (иногда запись),

Атрибут - Столбец, Поле.

3.2 Реляционная база данных

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

1. Каждая таблица состоит из строк одного типа и имеет уникальное имя.
2. Строки имеют фиксированное количество полей (столбцов) и значений (несколько полей и повторяющиеся группы не допускаются). Другими словами, в каждой позиции ta отличаются друг от друга по крайней мере одним значением: столбцы на пересечении строки и столбца всегда имеют ровно одно значение или ничего.
3. Строки таблицы должны быть уверены, что однозначно идентифицируют любую строку такой таблицы.
4. Имена однозначно присваиваются столбцам таблицы, и в каждый из них помещаются однородные значения данных (даты, фамилии, целые числа или денежные суммы).
5. Полное информационное наполнение базы данных представлено в виде явных значений данных, и этот способ представления является единственным. В частности, нет специальных «ссылок» или указателей, соединяющих одну таблицу с другой. Итак, связь между строкой с BL = 2 таблицы «Блюда» на рис. 4 и строкой с PR = 7 продуктов таблицы (рис нужен для приготовления Харчо) представлена не с помощью указателей, но из-за наличия в таблице «Состав» строки, в которой номер блюда равен 2, а номер продукта - 7.
6. При выполнении операций с таблицей ее строки и столбцы могут обрабатываться в любом порядке независимо от их информативности.

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

3.3 Управление реляционными данными

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

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

Созданы языки манипулирования данными, позволяющие реализовать все операции реляционной алгебры и практически любую их комбинацию. Среди них наиболее распространенными являются SQL (язык структурированных запросов) и QBE (Quere-By-Example). Оба являются языками очень высокого уровня, с помощью которых пользователь указывает, какие данные следует получить, не уточняя процедуру их получения.

Заключение

Сегодня реляционные базы данных остаются наиболее

распространенными из-за их простоты и ясности как в процессе создания, так и на уровне пользователя.

Главное преимущество реляционных баз данных - совместимость с наиболее популярным языком запросов SQL. С помощью одного запроса на этом языке вы можете объединить несколько таблиц во временную таблицу и вырезать из нее необходимые строки и столбцы (выделение и проекция). Поскольку табличная структура реляционной базы данных интуитивно понятна для пользователей, язык SQL прост и легок для изучения. Реляционная модель имеет прочную теоретическую основу, на которой были основаны эволюция и реализация реляционных баз данных. На волне популярности, вызванной успехом реляционной модели, SQL стал основным языком для реляционных баз данных.

В процессе анализа представленной информации были выявлены следующие недостатки рассматриваемой модели базы данных: - поскольку все поля одной таблицы должны содержать постоянное количество полей предопределенных типов, необходимо создавать дополнительные таблицы, учитывающие индивидуальные характеристики элементов с помощью внешних ключей. Такой подход очень затрудняет создание сложных отношений в базе данных;