Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
12 / 2 семестр / Лекция 4.doc
Скачиваний:
23
Добавлен:
10.06.2015
Размер:
4.28 Mб
Скачать

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

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

Рис.1 Основные компоненты реляционного отношения.

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

Формальное определение основных понятий реляционной модели данных базируется на теории множеств.

Отношение с одной стороны представляется («горизонтали») как множество атрибутов, а с другой - (по «вертикали») – как множество кортежей. Каждому элементу множества атрибутов ставится в соответствие множество значений – домен.

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

Так приведенные на рисунках 1 и 2 структуры СТУДЕНТ и СЕМЕСТР в реляционной модели данных будут отношениями, данные – код студента, Ф.И.О., пол, дата рождения и семестр, оценка рейтинг по дисциплине – атрибутами отношений, а схемой отношения СТУДЕНТ запись вида СТУДЕНТ (код студента, Ф.И.О., пол, дата рождения).

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

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

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

Нормализация отношений

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

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

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

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

СТУДЕНТ

Код

студента

Ф.И.О.

Место рождения

Иностранный язык

Республика

Область

Город (село)

Рисунок 1 Отношение, не удовлетворяющее первой нормальной форме

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

Более значительная специфика связана с атрибутом с множественными значениями.

Соблюдая требования одного размера атрибута во всех кортежах, мы должны бы были представить исходное отношение либо в виде рисунка 2 либо в виде рисунка 3.

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

Код студента

Ф.И.О.

№ группы

Пол

Дата рождения

Иностранный язык

-

-

427101

Гончар Е.Г

ПО-91

М

29.01.1970

немецкий, английский

427102

Ермолова А.Г.

ПО-91

Ж

19.09.1985

немецкий, французский, польский

427103

Курник П.В.

ПО-81

М

28.02.1975

английский

-

-

427106

Авдеев И.Г.

ПО-91

М

12.09.1986

не владеет

Рисунок 2 – Размещение множественных значений атрибутов в одном кортеже

Код студента

Ф.И.О.

№ группы

Пол

Дата рождения

Иностранный язык

-

-

427101

Гончар Е.Г

ПО-91

М

29.01.1970

немецкий

427101

Гончар Е.Г

ПО-91

М

29.01.1970

английский

427102

Ермолова А.Г.

ПО-91

Ж

19.09.1985

французский

427102

Ермолова А.Г.

ПО-91

Ж

19.09.1985

немецкий

427102

Ермолова А.Г.

ПО-91

Ж

19.09.1985

польский

427103

Курник П.В.

ПО-81

М

28.02.1975

английский

-

-

427106

Авдеев И.Г.

ПО-91

М

12.09.1986

не владеет

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

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

Реляционная модель требует нормализации (приведения к 1НФ) путем разбиения исходного отношения на два следующим образом: из исходного отношения СТУДЕНТ исключается атрибут с множественным значением и получается новое отношение СТУДЕНТ 1, а исключенный атрибут вместе с ключом исходного отношения образует новое отношение СТУДЕНТ 2 (рисунок 4) причем оба атрибута являются ключевым).

СТУДЕНТ 1

Код студента

Ф.И.О.

Дата рождения

СТУДЕНТ 2

Код студента

Иностранный язык

Рисунок 4 – Результат нормализации отношения СТУДЕНТ.

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

Отношение удовлетворяет второй нормальной форме (2НФ), если оно удовлетворяет 1НФ и не содержит атрибутов, зависящих от части ключа.

На рисунке 5 приведено отношение СЕМЕСТР, не удовлетворяющее 2НФ по следующей причине. Ключ отношения составляют атрибуты код студента и номер семестра, т.к. комбинация значений именно атрибутов уникальна для любого кортежа отношения. Вместе с тем, если атрибуты тип стипендии в семестре и рейтинг в семестре, зависят от полного ключа, то Ф.И.О. и дата рождения являются характеристиками студента вне зависимости от семестра, т.е. зависят от части ключа – от атрибута код студента.

Схема структуры СТУДЕНТ 3

Код студента

Ф.И.О.

Дата рождения

Номер семестра

Тип стипендии

Рейтинг за семестр

427101

Гончар Е.Г

29.01.1970

1

академическая

110

427101

Гончар Е.Г

29.01.1970

2

академическая

100

427102

Ермолова А.Г.

19.09.1985

1

не получал

60

427102

Ермолова А.Г.

19.09.1985

2

академическая

105

427102

Ермолова А.Г.

19.09.1985

3

повышенная

120

427103

Курник П.В.

28.02.1975

1

академическая

100

Рисунок 5 Отношение, не удовлетворяющее второй нормальной форме.

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

Приведение отношения ко 2НФ и заключается в разбиении исходного отношения на два, одно из которых включает атрибуты ключа исходного отношения и атрибуты, зависящие от полного ключа, а второе – атрибуты зависящего от части ключа вместе с атрибутами этой части. Результат нормализации исходного отношения СТУДЕНТ 3 приведен на рисунке 6.

СТУДЕНТ 4

Код студента

Ф.И.О.

Дата рождения

СТУДЕНТ 5

Код студента

Семестр

Тип стипендии

Рейтинг за семестр

Рисунок 6 – Результат нормализации отношения СЕМЕСТР

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

Отношение удовлетворяет третей нормальной форме (3НФ), если оно удовлетворяет 2НФ, и среди его не ключевых атрибутов нет зависящих от другого не ключевого атрибута (нет атрибутов, транзитивно зависящих от ключа).

На рисунке 7 приведено отношение, не удовлетворяющее 3НФ.

СТУДЕНТ 6

Код студента

Ф.И.О.

Дата рождения

Адрес общежития

Ф.И.О. коменданта общежития

427101

Гончар Е.Г

29.01.1970

Ерошевского 53

Афанасьв А.В

427102

Ермолова А.Г.

19.09.1985

Панова 63

Листьев Л.О

427103

Курник П.В.

28.02.1975

Панова 63

Листьев Л.О

Рисунок 7 Отношение, не удовлетворяющее третьей нормальной форме

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

Приведение отношения к 3НФ заключается в разбиении исходного отношения на два (рисунок 8), одно из которых есть исходное отношение без атрибутов, зависящих от не ключевого атрибута. Второе отношение состоит из атрибута, от которого в исходном отношении зависели исключенные атрибуты (оно станет ключом в новом отношении) плюс атрибуты, исключенные из исходного отношения.

СТУДЕНТ 7

Код студента

Ф.И.О.

Дата рождения

Адрес общежития

СТУДЕНТ 8

Адрес общежития

Ф.И.О. коменданта общежития

Рисунок 8 – Результат нормализации отношения СТУДЕНТ

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

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

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

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

Использование

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

Классификация Простые и составные ключи

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

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

Все остальные ключи отношения называются возможными ключами.

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

База данных о подразделениях и сотрудниках предприятия.

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

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

  1. из таблицы ОТДЕЛ установить значение атрибута "Номер_отдела", соответствующее данному "Наименованию_отдела"

  2. выбрать из таблицы СОТРУДНИК все записи, значение атрибута "Номер_отдела" которых равно полученному на предыдущем шаге.

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

    1. определяем "Номер_отдела" из таблицы СОТРУДНИК

    2. по полученному значению находим запись в таблице ОТДЕЛ.

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

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

    1. Отношение «один-к-одному» означает, что каждая запись в одной таблице соответствует только одной записи в другой таблице.

    2. Отношение «один-ко-многим» означает, что каждой записи в одной таблице соответствует одна или несколько записей в другой таблице.

    3. Отношение «многие-ко-одному» аналогично рассмотренному ранее типу. Тип отношения между объектами зависит от вашей точки зрения.

    4. Отношение «многие-ко-многим» возникает между двумя таблицами в тех случаях, когда:

    • одна запись из первой таблицы может быть связана более чем с одной записью из второй таблицы;

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

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

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

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

  • Соседние файлы в папке 2 семестр