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



Скачать 124.24 Kb.
Дата07.07.2013
Размер124.24 Kb.
ТипДокументы

Разработка АИС л№ 4


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

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

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

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

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

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

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

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

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


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

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

ПРИМЕЧАНИЕ

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

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

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

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

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

  • простые;

  • составные;

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


ПРИМЕЧАНИЕ

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

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

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

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

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

ПРИМЕЧАНИЕ

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

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

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

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

Сформулированные условия оптимальности часто являются противоречивыми, так что между ними следует находить разумный компромисс.
ПРИМЕЧАНИЕ

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

Поэтому обычно не следует индексировать:

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аномалии обновления тесно связаны с избыточностью данных.

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

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

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

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

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

ВЫВОДЫ

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

используется нормализация.

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

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

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

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

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

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

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

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

  • пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF).

Основные свойства нормальных форм:

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

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

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

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

ПРИМЕЧАНИЕ

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

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

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

Вторая нормальная форма

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

ПРИМЕЧАНИЕ

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

Чтобы перейти от первой нормальной формы ко второй, нужно выполнить следующие шаги:

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

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

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

В нашем примере для приведения таблицы СОТРУДНИКИ ко второй нормальной форме ее следует разделить на две таблицы. Первичный ключ исходной таблицы состоит из двух атрибутов — «Код сотрудника» и «Должность». Все личные данные о сотрудниках зависят только от атрибута «Код сотрудника». Атрибуты, соответствующие этим данным, мы и выделим в качестве одной из таблиц, которую назовем ФИЗИЧЕСКИЕ ЛИЦА. Информацию же о должностях и их оплате вынесем в другую таблицу, которой присвоим имя СОТРУДНИКИ. Схема приведения таблицы ко второй нормальной форме приведена на рис. 4.3. Полученные две таблицы связаны между собой по полю «Код физического лица», которое является первичным ключом для таблицы ФИЗИЧЕСКИЕ ЛИЦА и внешним ключом для таблицы СОТРУДНИКИ, Данное поле отсутствовало в исходной таблице и было добавлено при проведении нормализации.

Т
ретья нормальная форма


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

ПРИМЕЧАНИЕ

Функциональная зависимость атрибутов Х и Y отношения R называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости X -> Z & Z -> Y, но отсутствует функциональная зависимость

Y-> Х.

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

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

Чтобы перейти от второй нормальной формы к третьей, нужно выполнить следующие шаги:

1. Определить все поля (или группы полей), от которых зависят другие поля.

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

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

ПРИМЕЧАНИЕ

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

Приведем рассматриваемую в качестве примера базу данных к третьей нормаль- ной форме. Для этого разделим таблицу СОТРУДНИКИ на две — СОТРУДНИКИ и ДОЛЖНОСТИ (рис. 4.4).
На практике третья нормальная форма схем отношений в большинстве случаев достаточна, и приведением к третьей нормальной форме процесс проектирования реляционной базы данных обычно заканчивается. Поэтому мы не будем рассматривать другие нормальные формы, тем более что в работе они используются сравнительно редко.








Похожие:

Реляционная база данных — это совокупность отношений, содержащих всю информацию, которая должна храниться в базе данных iconРазработка реляционной структуры данных. Реляционная база данных
Реляционная база данных – это совокупность двумерных таблиц, содержащих всю информацию, которая должна храниться в бд
Реляционная база данных — это совокупность отношений, содержащих всю информацию, которая должна храниться в базе данных iconБазы данных Реляционная модель данных. Объекты данных, целостность реляционных данных
Реляционная модель данных была предложена Е. Коддом, в 1970 году. Реляционная модель(РМ) данных представляет информацию в виде совокупности...
Реляционная база данных — это совокупность отношений, содержащих всю информацию, которая должна храниться в базе данных iconЧто такое база данных. Реляционная база данных ms access
База данных (БД) — совокупность определенным образом организованной информации на какую-то тему
Реляционная база данных — это совокупность отношений, содержащих всю информацию, которая должна храниться в базе данных iconСистема управления базами данных (субд). Назначение и основные функции. База данных
База данных (БД) это хранящаяся во внешней памяти ЭВМ совокупность взаимосвязанных данных, организованных по определенным правилам,...
Реляционная база данных — это совокупность отношений, содержащих всю информацию, которая должна храниться в базе данных icon«Реляционная модель данных»
В широком смысле слова база данных — это совокупность описаний объектов реального мира и связей между ними, актуальных для конкретной...
Реляционная база данных — это совокупность отношений, содержащих всю информацию, которая должна храниться в базе данных iconБазы данных и информационные системы. Определение: База данных
База данных организованная в соответствии с определёнными правилами совокупность взаимосвязанных данных, совместно используемых пользователями...
Реляционная база данных — это совокупность отношений, содержащих всю информацию, которая должна храниться в базе данных iconОснова Информационных систем, объект ее обработки база данных компьютеров
В широком смысле слова можно сказать, что бд – это совокупность сведений о конкретных объектах реального мира в какой-либо предметной...
Реляционная база данных — это совокупность отношений, содержащих всю информацию, которая должна храниться в базе данных iconБазы данных и системы управления базами данных
База данных — это совокупность специальным образом организованных данных, храненящихся в памяти вычислительной системы и отражающих...
Реляционная база данных — это совокупность отношений, содержащих всю информацию, которая должна храниться в базе данных iconЛекция Базы данных. Что это такое
Гост 20886-85], “база данных – совокупность данных, организованных по определенным правилам, предусматривающим общие принципы описания,...
Реляционная база данных — это совокупность отношений, содержащих всю информацию, которая должна храниться в базе данных iconИнструкция по пользованию электронным каталогом 1 Формирование запроса к базе данных
В левой части форма, позволяющая сформировать запрос и осуществить поиск в активной базе данных ("Формирование запроса"). Активная...
Разместите кнопку на своём сайте:
ru.convdocs.org


База данных защищена авторским правом ©ru.convdocs.org 2016
обратиться к администрации
ru.convdocs.org