Vvmebel.com

Новости с мира ПК
2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Для данного отношения укажите домен атрибута количество

Для данного отношения укажите домен атрибута количество

Реляционная модель данных – логическая модель данных. Впервые была предложена британским учёным сотрудником компании IBM Эдгаром Франком Коддом (E. F. Codd) в 1970 году в статье «A Relational Model of Data for Large Shared Data Banks» (русский перевод статьи, в которой она впервые описана, опубликован в журнале «СУБД» N 1 за 1995 г.). В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.

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

В состав реляционной модели данных обычно включают теорию нормализации.

Состав реляционной модели данных

Кристофер Дейт определил три составные части реляционной модели данных:

  • структурная
  • манипуляционная
  • целостная

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

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

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

Структура реляционной модели данных

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

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

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

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

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

Домен — это набор всех допустимых значений, которые может содержать данный атрибут.

Понятие «домен» часто путают с понятием «тип данных». Необходимо четко различать эти два понятия.

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

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

Кортеж – это строка отношения.

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

Степень отношения определяется количеством атрибутов, которое оно содержит. Отношение Группа (рисунок 6.1) имеет пять атрибутов, и, следовательно, его степень равна пяти. Это значит, что каждая строка таблицы является пятиэлементным кортежем, т.е. кортежем, содержащим пять значения.

Отношение только с одним атрибутом имеет степень 1 и называется унарным (unary) отношением (или одноэлементным кортежем). Отношение с двумя атрибутами называется бинарным (binary), отношение с тремя атрибутами — тернарным (ternary), а для отношений с большим количеством атрибутов используется термин п-арное (n-агу). Определение степени отношения является частью заголовка отношения.

Кардинальность – это количество кортежей, которое содержится в отношении.

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

Существует еще одна терминология: отношение в нем называется файлом (file), кортежи — записями (records), а атрибуты — полями (fields). Эта терминология основана на том факте, что физически реляционная СУБД может хранить каждое отношение в отдельном файле. В табл. 6.2 показаны соответствия, существующие между тремя группами терминов.

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

В примере, показанном на рисунке, атрибуты «Оклад» и «Премия» определены на домене «Деньги». Поэтому, понятие домена имеет семантическую нагрузку: данные можно считать сравнимыми только тогда, когда они относятся к одному домену. Таким образом, в рассматриваемом нами примере сравнение атрибутов «Табельный номер» и «Оклад» является семантически некорректным, хотя они и содержат данные одного типа.

Именованное множество пар «имя атрибута – имя домена» называется схемой отношения. Мощность этого множества — называют степенью или «арностью» отношения. Набор именованных схем отношений представляет из себя схему базы данных.

Атрибут, значение которого однозначно идентифицирует кортежи, называется ключевым (или просто ключом). В нашем случае ключом является атрибут «Табельный номер», поскольку его значение уникально для каждого работника предприятия. Если кортежи идентифицируются только сцеплением значений нескольких атрибутов, то говорят, что отношение имеет составной ключ. Отношение может содержать несколько ключей. Всегда один из ключей объявляется первичным, его значения не могут обновляться. Все остальные ключи отношения называются возможными ключами.

Читать еще:  Dns имя хоста

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

Применение реляционной модели данных

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

Например, связь между отношениями ОТДЕЛ и СОТРУДНИК создается путем копирования первичного ключа «Номер_отдела» из первого отношения во второе. Таким образом:

  • для того, чтобы получить список работников данного подразделения, необходимо:
    1. из таблицы ОТДЕЛ установить значение атрибута «Номер_отдела», соответствующее данному «Наименованию_отдела»
    2. выбрать из таблицы СОТРУДНИК все записи, значение атрибута «Номер_отдела» которых равно полученному на предыдущем шаге
  • для того, чтобы узнать в каком отделе работает сотрудник, нужно выполнить обратную операцию:
    1. определяем «Номер_отдела» из таблицы СОТРУДНИК
    2. по полученному значению находим запись в таблице ОТДЕЛ

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

Достоинства и недостатки реляционной модели данных

Достоинства реляционной модели:

  • простота и доступность для понимания пользователем. Единственной используемой информационной конструкцией является «таблица»;
  • строгие правила проектирования, базирующиеся на математическом аппарате;
  • полная независимость данных. Изменения в прикладной программе при изменении реляционной БД минимальны;
  • для организации запросов и написания прикладного ПО нет необходимости знать конкретную организацию БД во внешней памяти.

Недостатки реляционной модели:

  • далеко не всегда предметная область может быть представлена в виде «таблиц»;
  • в результате логического проектирования появляется множество «таблиц». Это приводит к трудности понимания структуры данных;
  • БД занимает относительно много внешней памяти;
  • относительно низкая скорость доступа к данным.

Домены, атрибуты и отношения

Базовые структурные компоненты реляционной модели данных

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

Реляционная модель данных (РМД) была разработана сотрудником IBM Коддом (Codd) еще в 1969-70 г.г. на основе математической теории отношений. В настоящее время это наиболее распространенная модель данных, используемая коммерческими СУБД. Имеет свои достоинства и недостатки.

наличие небольшого набора абстракций

наличие простого и в то же время мощного математического аппарата

возможность ненавигационного манипулирования данными

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

— невозможность адекватного отображения семантики предметной области.

Как и любая другая, реляционная модель данных определяет

Соответственно, для описания структуры используется язык описания данных (ЯОД), для манипуляций с данными используется язык манипулирования данными (ЯМД). Особенности реляционной модели данных, отличающие ее от моделей сущность-связь:

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

— имеются конкретные языки описания данных и манипулирования данными,

— современные реляционные СУБД используют единый язык – SQL, в котором объединены и ЯОД, и ЯМД.

Базовыми структурными компонентами РМД являются:

— домены и атрибуты

Определение

Домен – множество элементов одного типа.

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

Примеры простых доменов: ГОД = <1985, 2003, 2000>; ДЕНЬГИ =

Пример составного домена, построенного на простых доменах ГОД и ДЕНЬГИ:

В данном примере значением одного элемента составного домена является множество пар вида

Отношение реляционной модели определяется в соответствии с его определением в теории множеств:

Определение

Пусть дана совокупность множеств D1, D2, …, Dn, не обязательно различных. Тогда отношение R, определенное на этих множествах, есть множество упорядоченных кортежей таких, что di Î Di для каждого i из [1:n].

В реляционной модели данных множества Di представляют собой домены.

кортежи отношения не упорядочены,

домены внутри кортежей упорядочены.

Определение

Атрибуты задают способ использования домена внутри отношения.

В связи с введением понятия атрибута в реляционной модели данных вводится понятие схемы отношения:

Определение

Схема отношения – это именованная совокупность пар .

Схема отношения представляет собой интенсионал отношения.

Рассмотрим пример. Пусть даны два домена: ЧИСЛО и СТРОКА. В отношении ОТДЕЛ домен ЧИСЛО используется для задания номера отдела – вводим атрибут Номер отдела, а домен СТРОКА используется для задания названия отдела – атрибут Название. Тогда отношению ОТДЕЛ соответствует следующая схема отношения:

ОТДЕЛ ( Номер отдела: ЧИСЛО, Название: СТРОКА )

В РМД, как упоминалось выше, может существовать составной домен. В соответствии со своим определением, составной домен представляет собой отношение, построенное также на простых доменах. Но в таком отношении не появляются атрибуты. Вернемся к домену ИСТОРИЯ ЗАРПЛАТЫ. Он построен на простых доменах ГОД и ДЕНЬГИ и может быть задан следующим образом:

ИСТОРИЯ ЗАРПЛАТЫ ( ГОД, ДЕНЬГИ )

В задании схемы отношения могут использоваться и составные домены. Рассмотрим отношение СОТРУДНИК. Его атрибутами могут быть Номер сотрудника (определен на домене ЧИСЛО), Имя (на домене СТРОКА) и Зарплата, определенный на домене ИСТОРИЯ ЗАРПЛАТЫ:

СОТРУДНИК ( Номер сотрудника: ЧИСЛО, Имя: СТРОКА, Зарплата: ИСТОРИЯ ЗАРПЛАТЫ )

Конкретная реализация (экстенсионал) данного отношения может иметь следующий вид:

Для данного отношения укажите домен атрибута количество

Типы данные в ячейках таблицы

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

  1. В отношении нет одинаковых кортежей . Действительно, тело отношения есть множество кортежей и, как всякое множество, не может содержать неразличимые элементы (см. понятие множества в гл.1.). Таблицы в отличие от отношений могут содержать одинаковые строки.
  2. Кортежи не упорядочены (сверху вниз) . Действительно, несмотря на то, что мы изобразили отношение «Сотрудники» в виде таблицы, нельзя сказать, что сотрудник Иванов «предшествует» сотруднику Петрову. Причина та же — тело отношения есть множество, а множество не упорядочено. Это вторая причина, по которой нельзя отождествить отношения и таблицы — строки в таблицах упорядочены. Одно и то же отношение может быть изображено разными таблицами, в которых строки идут в различном порядке.
  3. Атрибуты не упорядочены (слева направо) . Т.к. каждый атрибут имеет уникальное имя в пределах отношения, то порядок атрибутов не имеет значения. Это свойство несколько отличает отношение от математического определения отношения (см. гл.1 — компоненты кортежей там упорядочены). Это также третья причина, по которой нельзя отождествить отношения и таблицы — столбцы в таблице упорядочены. Одно и то же отношение может быть изображено разными таблицами, в которых столбцы идут в различном порядке.
  4. Все значения атрибутов атомарны . Это следует из того, что лежащие в их основе атрибуты имеют атомарные значения. Это четвертое отличие отношений от таблиц — в ячейки таблиц можно поместить что угодно — массивы, структуры, и даже другие таблицы.
Читать еще:  Разметка страницы в word 2020

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

Замечание . Каждое отношение можно считать классом эквивалентности таблиц, для которых выполняются следующие условия:

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

Все такие таблицы есть различные изображения одного и того же отношения.

Первая нормальная форма

Труднее всего дать определение вещей, которые всем понятны. Если давать не строгое, описательное определение, то всегда остается возможность неправильной его трактовки. Если дать строгое формальное определение, то оно, как правило, или тривиально, или слишком громоздко. Именно такая ситуация с определением отношения в Первой Нормальной Форме (1НФ). Совсем не говорить об этом нельзя, т.к. на основе 1НФ строятся более высокие нормальные формы, которые рассматриваются далее в гл. 6 и 7. Дать определение 1НФ сложно ввиду его тривиальности. Поэтому, дадим просто несколько объяснений.

Объяснение 1 . Говорят, что отношение находится в 1НФ, если оно удовлетворяет определению 2.

Это, собственно, тавтология, ведь из определения 2 следует, что других отношений не бывает. Действительно, определение 2 описывает, что является отношением, а что — нет, следовательно, отношений в непервой нормальной форме просто нет.

Объяснение 2 . Говорят, что отношение находится в 1НФ, если его атрибуты содержат только скалярные (атомарные) значения.

Опять же, определение 2 опирается на понятие домена, а домены определены на простых типах данных.

Непервую нормальную форму можно получить, если допустить, что атрибуты отношения могут быть определены на сложных типах данных — массивах, структурах, или даже на других отношениях. Легко себе представить таблицу, у которой в некоторых ячейках содержатся массивы, в других ячейках — определенные пользователями сложные структуры, а в третьих ячейках — целые реляционные таблицы, которые в свою очередь могут содержать такие же сложные объекты. Именно такие возможности предоставляются некоторыми современными пост-реляционными и объектными СУБД.

Требование, что отношения должны содержать только данные простых типов, объясняет, почему отношения иногда называют плоскими таблицами (plain table). Действительно, таблицы, задающие отношения двумерны. Одно измерение задается списком столбцов, второе измерение задается списком строк. Пара координат (Номер строки, Номер столбца) однозначно идентифицирует ячейку таблицы и содержащееся в ней значение. Если же допустить, что в ячейке таблицы могут содержаться данные сложных типов (массивы, структуры, другие таблицы), то такая таблица будет уже не плоской. Например, если в ячейке таблицы содержится массив, то для обращения к элементу массива нужно знать три параметра (Номер строки, Номер столбца, номер элемента в массиве).

Таким образом появляется третье объяснение Первой Нормальной Формы:

Объяснение 3 . Отношение находится в 1НФ, если оно является плоской таблицей.

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

Для данного отношения укажите домен атрибута количество

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

Для начала покажем смысл этих понятий на примере отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторой организации:

4.1.1. Тип данных

Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как «деньги»), а также специальных «темпоральных» данных (дата, время, временной интервал). Достаточно активно развивается подход к расширению возможностей реляционных систем абстрактными типами данных (соответствующими возможностями обладают, например, системы семейства Ingres/Postgres). В нашем примере мы имеем дело с данными трех типов: строки символов, целые числа и «деньги».

4.1.2. Домен

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

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

Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов «Номера пропусков» и «Номера групп» относятся к типу целых чисел, но не являются сравнимыми. Заметим, что в большинстве реляционных СУБД понятие домена не используется, хотя в Oracle V.7 оно уже поддерживается.

4.1.3. Схема отношения, схема базы данных

Схема отношения — это именованное множество пар <имя атрибута, имя домена (или типа, если понятие домена не поддерживается)>. Степень или «арность» схемы отношения — мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута).

Схема БД (в структурном смысле) — это набор именованных схем отношений.

4.1.4. Кортеж, отношение

Кортеж, соответствующий данной схеме отношения, — это множество пар <имя атрибута, значение>, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. «Значение» является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или «арность» кортежа, т.е. число элементов в нем, совпадает с «арностью» соответствующей схемы отношения. Попросту говоря, кортеж — это набор именованных значений заданного типа.

Отношение — это множество кортежей, соответствующих одной схеме отношения. Иногда, чтобы не путаться, говорят «отношение-схема» и «отношение-экземпляр», иногда схему отношения называют заголовком отношения, а отношение как набор кортежей — телом отношения. На самом деле, понятие схемы отношения ближе всего к понятию структурного типа данных в языках программирования. Было бы вполне логично разрешать отдельно определять схему отношения, а затем одно или несколько отношений с данной схемой.

Читать еще:  Развертывание домена на windows server 2020 r2

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

Обычным житейским представлением отношения является таблица, заголовком которой является схема отношения, а строками — кортежи отношения-экземпляра; в этом случае имена атрибутов именуют столбцы этой таблицы. Поэтому иногда говорят «столбец таблицы», имея в виду «атрибут отношения». Когда мы перейдем к рассмотрению практических вопросов организации реляционных баз данных и средств управления, мы будем использовать эту житейскую терминологию. Этой терминологии придерживаются в большинстве коммерческих реляционных СУБД.

Реляционная база данных — это набор отношений, имена которых совпадают с именами схем отношений в схеме БД.

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

Для данного отношения укажите домен атрибута количество

Типы данные в ячейках таблицы

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

  1. В отношении нет одинаковых кортежей . Действительно, тело отношения есть множество кортежей и, как всякое множество, не может содержать неразличимые элементы (см. понятие множества в гл.1.). Таблицы в отличие от отношений могут содержать одинаковые строки.
  2. Кортежи не упорядочены (сверху вниз) . Действительно, несмотря на то, что мы изобразили отношение «Сотрудники» в виде таблицы, нельзя сказать, что сотрудник Иванов «предшествует» сотруднику Петрову. Причина та же — тело отношения есть множество, а множество не упорядочено. Это вторая причина, по которой нельзя отождествить отношения и таблицы — строки в таблицах упорядочены. Одно и то же отношение может быть изображено разными таблицами, в которых строки идут в различном порядке.
  3. Атрибуты не упорядочены (слева направо) . Т.к. каждый атрибут имеет уникальное имя в пределах отношения, то порядок атрибутов не имеет значения. Это свойство несколько отличает отношение от математического определения отношения (см. гл.1 — компоненты кортежей там упорядочены). Это также третья причина, по которой нельзя отождествить отношения и таблицы — столбцы в таблице упорядочены. Одно и то же отношение может быть изображено разными таблицами, в которых столбцы идут в различном порядке.
  4. Все значения атрибутов атомарны . Это следует из того, что лежащие в их основе атрибуты имеют атомарные значения. Это четвертое отличие отношений от таблиц — в ячейки таблиц можно поместить что угодно — массивы, структуры, и даже другие таблицы.

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

Замечание . Каждое отношение можно считать классом эквивалентности таблиц, для которых выполняются следующие условия:

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

Все такие таблицы есть различные изображения одного и того же отношения.

Первая нормальная форма

Труднее всего дать определение вещей, которые всем понятны. Если давать не строгое, описательное определение, то всегда остается возможность неправильной его трактовки. Если дать строгое формальное определение, то оно, как правило, или тривиально, или слишком громоздко. Именно такая ситуация с определением отношения в Первой Нормальной Форме (1НФ). Совсем не говорить об этом нельзя, т.к. на основе 1НФ строятся более высокие нормальные формы, которые рассматриваются далее в гл. 6 и 7. Дать определение 1НФ сложно ввиду его тривиальности. Поэтому, дадим просто несколько объяснений.

Объяснение 1 . Говорят, что отношение находится в 1НФ, если оно удовлетворяет определению 2.

Это, собственно, тавтология, ведь из определения 2 следует, что других отношений не бывает. Действительно, определение 2 описывает, что является отношением, а что — нет, следовательно, отношений в непервой нормальной форме просто нет.

Объяснение 2 . Говорят, что отношение находится в 1НФ, если его атрибуты содержат только скалярные (атомарные) значения.

Опять же, определение 2 опирается на понятие домена, а домены определены на простых типах данных.

Непервую нормальную форму можно получить, если допустить, что атрибуты отношения могут быть определены на сложных типах данных — массивах, структурах, или даже на других отношениях. Легко себе представить таблицу, у которой в некоторых ячейках содержатся массивы, в других ячейках — определенные пользователями сложные структуры, а в третьих ячейках — целые реляционные таблицы, которые в свою очередь могут содержать такие же сложные объекты. Именно такие возможности предоставляются некоторыми современными пост-реляционными и объектными СУБД.

Требование, что отношения должны содержать только данные простых типов, объясняет, почему отношения иногда называют плоскими таблицами (plain table). Действительно, таблицы, задающие отношения двумерны. Одно измерение задается списком столбцов, второе измерение задается списком строк. Пара координат (Номер строки, Номер столбца) однозначно идентифицирует ячейку таблицы и содержащееся в ней значение. Если же допустить, что в ячейке таблицы могут содержаться данные сложных типов (массивы, структуры, другие таблицы), то такая таблица будет уже не плоской. Например, если в ячейке таблицы содержится массив, то для обращения к элементу массива нужно знать три параметра (Номер строки, Номер столбца, номер элемента в массиве).

Таким образом появляется третье объяснение Первой Нормальной Формы:

Объяснение 3 . Отношение находится в 1НФ, если оно является плоской таблицей.

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

Ссылка на основную публикацию
Adblock
detector