Какими свойствами обладает реляционная таблица

В реляционных БД при формировании реляционных таблиц необходимо выполнение следующих условий, определяемых свойствами этих таблиц:

 домены, должны иметь индивидуальные уникальные имена;

 каждое значение поля таблицы должно представляет собой один элемент данных;

 в каждом домене все значения полей однородны;

 недопустимы идентичные кортежи;

 каждый кортеж должен иметь первичный ключ.

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

Концепции реляционной модели данных связаны с именем известного специалиста в области систем баз данных Е. Кодда. Именно поэтому реляционную модель данных часто называют моделью Кодда.

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

Тип данных – эквивалентно понятию типа данных в алгоритмических языках. Существуют:

Ø целочисленные типы;

Ø вещественные типы;

Ø строковые типы;

Ø типы данных для денежных величин;

Ø типы данных для временных величин;

Ø типы двоичных объектов (не имеет аналогов в языках программирования, и обозначаются Blob)

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

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

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

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

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

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

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

Так как таблицы в реляционной СУБД являются отношениями реляционной мо­дели данных, то и свойства этих таблиц являются свойствами отношений, кото­рые мы уже рассмотрели выше. Кратко сформулируем эти свойства еще раз:

— каждая таблица состоит из однотипных строк и имеет уникальное имя;

— строки имеют фиксированное число полей (столбцов) и значений (множествен­ные поля и повторяющиеся группы недопустимы). Иначе говоря, в каждой по­зиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или NULL;

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

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

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

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

Индексы

Выше мы рассмотрели понятие ключей таблиц базы данных. В большинстве ре­ляционных СУБД ключи реализуются с помощью объектов, называемых индек­сами. Индекс представляет собой указатель на данные, размещенные в реляционной таб­лице. Можно провести аналогию индекса таблицы базы данных с указателем, обыч­но помещаемым в конце книги. Чтобы найти в книге страницы, относящиеся к некоторой теме, проще всего обратиться к указателю, в котором устанавливается соответствие между перечисленными в алфавитном порядке темами и номерами страниц, и сразу определить страницы, которые следует просмотреть. Чтобы без указателя найти все страницы, относящиеся к нужной теме, пришлось бы просмат­ривать всю книгу. Индекс базы данных предназначен для аналогичных целей – чтобы ускорить поиск информации в таблице базы данных. Индекс предоставляет информацию о точном физическом расположении данных в таблице.

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

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

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

Рассмотрим пример индекса. На рис. 4.1 показан фрагмент таблицы СТУДЕНТЫ и индекса, построенного по полю «Имя» данной таблицы. При выполнении поиска по имени студента, просматривая индекс, можно сразу определить порядковый Номер записи, содержащей необходимую информацию, и затем быстро найти в таблице сами данные. Если бы у таблицы отсутствовал индекс по полю «Имя», то выполнение поиска по имени студента потребовало бы просмотра всей таблицы.

Таким образом, использование индексов снижает время выборки данных.

Рисунок 4.1 – Поиск информации в таблице с помощью индекса

Различают несколько типов индексов. Наиболее часто выделяют три типа:

— простые;

— составные;

— уникальные.

Ускорение поиска информации при использовании индекса может показаться неоче­видным – ведь количество записей в индексе совпадает с количеством записей в таблице. Однако следует учитывать два обстоятельства:

— обращение к индексу выполняется быстрее, чем к таблице;

— в индексе записи хранятся в упорядоченном виде (в рассматриваемом примере – в алфавитном порядке) и поэтому при поиске информации в индексе нет необхо­димости просматривать все данные до конца индекса.

Простые индексыпредставляют собой простейший и вместе с тем наиболее рас­пространенный тип индекса. Простой индекс строится на основе только одного столбца реляционной таблицы (индекс, приведенный на рис. 4.1, является про­стым).

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

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

Можно назвать два условия оптимальности следования столбцов в составном ин­дексе:

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

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

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

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

– столбцы, данные в которых подвержены частому изменению;

– столбцы, содержащие большое количество пустых значений;

– столбцы, содержащие небольшое количество уникальных значений;

– небольшие таблицы;

– поля большого размера.

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

Нормализация данных

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

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

Цели нормализации

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

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

— избыточность данных;

— аномалии обновления;

— аномалии удаления;

— аномалии ввода.

Чтобы проиллюстрировать проблемы, возникающие при работе с ненормализо­ванными базами данных, рассмотрим в качестве примера таблицу СОТРУДНИКИ, содержащую информа­цию о сотрудниках некой организации. Структура этой таблицы приведена на рис. 4.2.

Избыточность данных

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

Аномалии обновления

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

Аномалии удаления

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

Аномалии ввода

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

Вывод

Очевидно, что аномалии обновления, удаления и ввода крайне нежелательны. Что­бы свести к минимуму возможность появления такого рода аномалий, и использу­ется нормализация.

Нормальные формы

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

В теории реляционных баз данных обычно выделяется следующая последователь­ность нормальных форм:

— первая нормальная форма (1NF);

— вторая нормальная форма (2NF);

— третья нормальная форма (3NF);

— нормальная форма Бойса–Кодда (BCNF);

— четвертая нормальная форма (4NF);

— пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF). Основные свойства нормальных форм:

— каждая следующая нормальная форма в некотором смысле лучше предыду­щей;

— при переходе к следующей нормальной форме свойства предыдущих нормаль­ных свойств сохраняются.

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

Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости. Функционально зависимым считается такой атрибут, значение ко­торого однозначно определяется значением другого атрибута. Функционально за­висимые атрибуты обозначаются следующим образом: X –> Y. Эта запись означа­ет, что если два кортежа в таблице имеют одно и то же значение атрибута X, то они имеют одно и то же значение атрибута Y. Атрибут, указываемый в левой части, называется детерминантом.

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

Date: 2016-05-25; view: 1654; Нарушение авторских прав