Атомарность значений атрибутов

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

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

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

Зачислить сотрудника Кузнецова (пропуск номер 3000, зарплата 115,000) в отдел номер 320 и

Зачислить сотрудника Кузнецова (пропуск номер 3000, зарплата 115,000) в отдел номер 310.

1. Отношение имеет имя, которое отличается от имен других отношений.

2. Отношение представляется в виде табличной структуры

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

4. Кортежи не упорядочены.

5. Атрибуты не упорядочены.

Теперь введем понятие нормализации. Единственными отношениями, допустимыми в реляционной модели, являются те, которые удовлетворяют следующему условию:

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

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

Очень просто преобразовать ненормализованное отношение к эквивалентной нормализованной форме. Достаточно одного примера, чтобы проиллюстрировать эту процедуру. Отношение BEFORE определено на доменах S# (номер поставщика) и PQ (количество деталей). Элементы PQ сами являются отношениями, определенными на доменах P# (номер детали) и QTY (количество). Таким образом, отношение BEFORE ненормализованно. Отношение AFTER – эквивалентное нормализованное отношение. (Смысл каждого из этих отношений в том, что указанные поставщики поставляют указанные детали в указанных количествах).

Часто встречается случай, когда внутри данного отношения существует атрибут, значения которого однозначно идентифицируют кортежи отношения. Например, атрибут Р# отношения PART обладает этим свойством: все кортежи отношения PART содержат различные значения Р#, и эти значения могут быть использованы для того, чтобы отличить эти кортежи в отношении один от другого. Назовем атрибут Р# потенциальным (первичным) ключом для отношения PART.

Не каждое отношение будет иметь первичный ключ в виде единственного атрибута. Однако каждое отношение будет иметь некоторую комбинацию атрибутов, которые, взятые вместе, будут однозначно идентифицировать кортеж в отношении. Комбинация, состоящая из единственного атрибута, является просто специальным случаем. Например, в отношении AFTER этим свойством обладает комбинация (MAJOR-P#, MINOR-P#) в отношении COMPONENT. Существование такой комбинации гарантируется тем, что отношение является уникальным для данного отношения. Следовательно, по крайней мере комбинация всех атрибутов обладает свойством однозначно идентифицировать кортежи в отношении. На практике обычно нет необходимости использовать для этого все атрибуты – как правило, достаточно комбинации некоторой их меньшей части. Таким образом, каждое отношение имеет (возможно, составной) первичный ключ. Мы будем предполагать, что первичный ключ неизбыточен в том смысле, что никакие из составляющих его атрибутов не являются излишними для однозначной идентификации кортежа в отношении. Например, комбинация (Р#, COLOR) не является первичным ключом дл отношения PART.

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

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

1. уникальности(нет двух кортежей R с одинаковыми значениями К).

2. неизбыточности т.е. никакое из подмножеств множества К не обладает свойством уникальности (если из S#, P# удалить атрибут S#, то значения P# будут повторяться)

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

1. существует переменная отношения S с потенциальным ключом S.

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

(S, P) – первичный ключ отношения SP, он составной.

Составной ключ содержит два и более атрибутов.

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

Суперключ – надмножество потенциального ключа. Например < S, CITY>– суперключ переменной отношения S.

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

Заключение

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

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

Мы завершаем эту лекцию перечислением основных особенностей реляционных «файлов», которые отличают эти «файлы» от традиционных файлов.

1. каждый «файл» содержит только один тип записи.

2. каждый тип записи имеет фиксированное число типов полей.

3. каждый экземпляр записи имеет уникальный идентификатор.

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

Источник

Атомарность значений атрибутов, первая нормальная форма отношения

Значения всех атрибутов являются атомарными (вернее, скалярными). Это следует из определения домена как потенциального множества значений скалярного типа данных, т. е. среди значений домена не могут содержаться значения с видимой структурой, в том числе множества значений ( отношения ). Заметим, что это не противоречит тому, что говорилось в разделе «Основные понятия реляционных баз данных» о потенциальной возможности использования при спецификации атрибутов типов данных, определяемых пользователями. Например, можно было бы добавить в схему отношения СЛУЖАЩИЕ атрибут СЛУ_ФОТО, определенный на домене (или типе данных ) ФОТОГРАФИИ. Главное в атомарности значений атрибутов состоит в том, что реляционная СУБД не должна обеспечивать пользователям явной видимости внутренней структуры значения. Со всеми значениями можно обращаться только с помощью операций, определенных в соответствующем типе данных.

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

Пример ненормализованного отношения показан на рис. 2.2. Можно сказать, что здесь мы имеем бинарное отношение, в котором значениями атрибута ОТДЕЛЫ являются отношения. Заметим, что исходное отношение СЛУЖАЩИЕ является нормализованным вариантом отношения ОТДЕЛЫ-СЛУЖАЩИЕ. Нормализованный вариант показан на рис. 2.3.

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

зачислить служащего Кузнецова (пропуск номер 3000, зарплата 25000.00) в отдел номер 320;

зачислить служащего Кузнецова (пропуск номер 3000, зарплата 25000.00) в отдел номер 310.

Рис. 2.2. Ненормализованное отношение ОТДЕЛЫ-СЛУЖАЩИЕ

Рис. 2.3. Отношение СЛУЖАЩИЕ: нормализованный вариант отношения ОТДЕЛЫ-СЛУЖАЩИЕ

Если информация о служащих представлена в виде отношения СЛУЖАЩИЕ, оба оператора будут выполняться одинаково (вставить кортеж в отношение СЛУЖАЩИЕ ). Если же работать с ненормализованным отношением ОТДЕЛЫ-СЛУЖАЩИЕ, то первый оператор приведет к простой вставке кортежа, а второй – к добавлению кортежа в значение- отношение атрибута ОТДЕЛ кортежа с первичным ключом 310.

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

Источник

Атомарность значений атрибутов

Значения всех атрибутов являются атомарными. Это свойство является следствием того, что все домены, лежащие в основе отношения, содержат только атомарные значения. Иначе можно сказать, что в каждой позиции пересечения столбца и строки таблицы расположено в точности одно значение, а не набор значений. Отношение, удовлетворяющее этому условию, называется нормализованным (представленным в первой нормальной форме). Т.е. с точки зрения реляционной модели все отношения нормализованы, поэтому в реляционных базах данных допускаются только нормализованные отношения или отношения, представленные в первой нормальной форме. Примером ненормализованного отношения является отношение R1 на Рис.2-16. Чтобы можно было использовать отношение в реляционной БД, его необходимо привести в виду отношения R2 (Рис. 2-16). Процесс получения отношения R2 из R1 называется нормализацией (подробнее процесс нормализации описан в Главе?).

Это свойство также иллюстрирует отличие таблицы от отношения. Строго говоря, на Рис. 2-16 только R2 является отношением, а таблицей можно назвать как R1, так и R2.

Рис. 2-16. Пример нормализации отношения

2.2.2. Ограничения целостности в реляционной модели данных

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

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

В классическом понимании поддержка целостности включает 3 части:

Эти 3 вида целостности определяют допустимую форму представления и обработки информации в реляционных БД.

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

Дата добавления: 2014-11-13 ; просмотров: 130 ; Нарушение авторских прав

Источник

Значения всех атрибутов отношения должны быть атомарными

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

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

В данной главе рассматривается структурная часть реляционной модели.

Типы данных

Любые данные, используемые в программировании, имеют свои типы данных.

Важно! Реляционная модель требует, чтобы типы используемых данных были простыми.

Простые типы данных

Структурированные типы данных

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

называемое множеством индексов. Отображение

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

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

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

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

Ссылочные типы данных

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

Типы данных, используемые в реляционной модели

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

Именно так в некоторых пост-реляционных СУБД реализована работа со сколь угодно сложными типами данных, создаваемых пользователями.

Домены

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

Например, домен , имеющий смысл «возраст сотрудника» можно описать как следующее подмножество множества натуральных чисел:

Если тип данных можно считать множеством всех возможных значений данного типа, то домен напоминает подмножество в этом множестве.

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

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

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

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

Отношения, атрибуты, кортежи отношения

Определения и примеры

Фундаментальным понятием реляционной модели данных является понятие отношения. В определении понятия отношения будем следовать книге К. Дейта [11].

Имена атрибутов должны быть уникальны в пределах отношения. Часто имена атрибутов отношения совпадают с именами соответствующих доменов.

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

Заголовок отношения содержит фиксированное количество атрибутов отношения:

Тело отношения содержит множество кортежей отношения. Каждый кортеж отношения представляет собой множество пар вида :

таких что значение атрибута принадлежит домену

Отношение обычно записывается в виде:

Число атрибутов в отношении называют степенью (или -арностью) отношения.

Мощность множества кортежей отношения называют мощностью отношения.

Возвращаясь к математическому понятию отношения, введенному в предыдущей главе, можно сделать следующие выводы:

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

Пример 1. Рассмотрим отношение «Сотрудники» заданное на доменах «Номер_сотрудника», «Фамилия», «Зарплата», «Номер_отдела». Т.к. все домены различны, то имена атрибутов отношения удобно назвать так же, как и соответствующие домены. Заголовок отношения имеет вид:

Сотрудники (Номер_сотрудника, Фамилия, Зарплата, Номер_отдела)

Пусть в данный момент отношение содержит три кортежа:

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

Таблица 1 Отношение «Сотрудники»

Определение 3. Реляционной базой данных называется набор отношений.

Определение 4. Схемой реляционной базы данных называется набор заголовков отношений, входящих в базу данных.

Хотя любое отношение можно изобразить в виде таблицы, нужно четко понимать, что отношения не являются таблицами. Это близкие, но не совпадающие понятия. Различия между отношениями и таблицами будут рассмотрены ниже.

Термины, которыми оперирует реляционная модель данных, имеют соответствующие «табличные» синонимы:

Свойства отношений

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

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

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

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

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

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

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

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

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

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

Выводы

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

Реляционной базой данных называется набор отношений.

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

Отношение находится в Первой Нормальной Форме (1НФ), если оно содержит только скалярные (атомарные) значения.

Источник