Автор работы: Пользователь скрыл имя, 17 Марта 2014 в 10:50, курсовая работа
Объекты реального мира связаны друг с другом множеством сложных зависимостей, которые необходимо учитывать в информационной деятельности. Например, детали на склад поставляются их производителями. Следовательно, в число атрибутов детали необходимо включить атрибут "название фирмы-производителя". Однако этого недостаточно, так как могут понадобиться дополнительные сведения о производителе конкретной детали — его адрес, номер телефона и т.д. Значит, база данных должна содержать не только информацию о деталях и заказах на поставку, но и сведения об их производителях. Более того, база данных должна отражать связи между деталями и производителями (каждая деталь выпускается конкретным производителем) и между заказами и деталями (каждый заказ оформляется на конкретную деталь).
Введение…………………………………………………………………………3
1 Основные понятия реляционных баз данных……………………………….6
2 Ограничительные условия, поддерживающие целостность……………….10
2.1 Целостность категории (сущности) и ссылок……………………………..10
3 Операции над реляционными данными……………………………………..14
3.1 Традиционные операции……………………………………………………14
3.2 Специальные операции……………………………………………………..15
3.3 Первая нормальная форма………………………………………………….17
3.4 Вторая нормальная форма…………………………………………………..18
3.5 Третья нормальная форма…………………………………………………..18
3.6 Другие нормальные формы…………………………………………………19
Заключение………………………………………………………………………20
Глоссарий………………………………………………………………………...21
Список использованных источников…………………………………………..2
a op NULL = NULL
NULL op a = NULL
a lop NULL = unknown
NULL lop a = unknown
Здесь unknown – это третье значение логического, или булевского, типа, обладающее следующими свойствами:
NOT unknown = unknown
true AND unknown = unknown
true OR unknown = true
false AND unknown = false
false OR unknown = unknown
Так вот, первое из требований - требование целостности сущности - означает, что первичный ключ должен полностью идентифицировать каждую сущность, а поэтому в составе любого значения первичного ключа не допускается наличие неопределенных значений. (В классической реляционной модели это требование распространяется и на возможные ключи; в SQL-ориентированных СУБД такое требование для возможных ключей не поддерживается.)
Второе требование, которое называется требованием целостности по ссылкам (referential integrity), является более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности реального мира представляются в реляционной БД в виде нескольких кортежей нескольких отношений. Например, представим, что требуется представить в реляционной базе данных сущность ОТДЕЛ с атрибутами ОТД_НОМЕР (номер отдела), ОТД_РАЗМ (количество служащих) и ОТД_СЛУ (множество сотрудников отдела). Для каждого служащего нужно хранить СЛУ_НОМЕР (номер сотрудника), СЛУ_ИМЯ (имя сотрудника) и СЛУ_ЗАРП (заработная плата сотрудника). Как мы увидим при правильном проектировании соответствующей БД в ней появятся два отношения: ОТДЕЛЫ {ОТД_НОМЕР, ОТД_РАЗМ} (первичный ключ – {ОТД_НОМЕР}) и СОТРУДНИКИ {СЛУ_НОМЕР, СЛУ_ИМЯ, СЛУ_ЗАРП, СЛУ_ОТД_НОМ} (первичный ключ – {СЛУ_НОМЕР}).
Как видно, атрибут СЛУ_ОТД_НОМ вводится в отношение СЛУЖАЩИЕ не потому, что номер отдела является собственным свойством сотрудника, а лишь для того, чтобы иметь возможность при необходимости восстановить полную сущность ОТДЕЛ. Значение атрибута СЛУ_ОТД_НОМ в любом кортеже отношения СЛУЖАЩИЕ должно соответствовать значению атрибута ОТД_НОМ в некотором кортеже отношения ОТДЕЛЫ. Атрибут такого рода (возможно, составной) называется внешним ключом (foreign key), поскольку его значения однозначно характеризуют сущности, представленные кортежами некоторого другого отношения (т. е. задают значения их первичного ключа). Конечно, внешний ключ может быть составным, т. е. состоять из нескольких атрибутов. Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом. Требование целостности по ссылкам, или требование целостности внешнего ключа, состоит в том, что для каждого значения внешнего ключа, появляющегося в кортеже значения-отношения ссылающейся переменной отношения, либо в значении-отношении переменной отношения, на которую указывает ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть полностью неопределенным (т. е. ни на что не указывать) Для нашего примера это означает, что если для сотрудника указан номер отдела, то этот отдел должен существовать. Заметим, что, как и первичный ключ, внешний ключ должен специфицироваться при определении переменной отношения и представляет собой ограничение на допустимые значения-отношения этой переменной. Другими словами, определение внешнего ключа представляет собой определение ограничения целостности базы данных.
Ограничения целостности сущности и по ссылкам должны поддерживаться СУБД. Для соблюдения целостности сущности достаточно гарантировать отсутствие в любой переменной отношения значений-отношений, содержащих кортежи с одним и тем же значением первичного ключа (и запрещать вхождение в значение первичного ключа неопределенных значений). С целостностью по ссылкам дело обстоит несколько сложнее. Понятно, что при обновлении ссылающегося отношения (вставке новых кортежей или модификации значения внешнего ключа в существующих кортежах) достаточно следить за тем, чтобы не появлялись некорректные значения внешнего ключа. Но как быть при удалении кортежа из отношения, на которое ведет ссылка?
Здесь существуют три подхода, каждый из которых поддерживает целостность по ссылкам:
Первый подход заключается в том, что вообще запрещается производить удаление кортежа, для которого существуют ссылки (т. е. сначала нужно либо удалить ссылающиеся кортежи, либо соответствующим образом изменить значения их внешнего ключа).
При втором подходе при удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение внешнего ключа автоматически становится полностью неопределенным.
Наконец, третий подход (каскадное удаление) состоит в том, что при удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи.
В развитых реляционных СУБД обычно можно выбрать способ поддержания целостности по ссылкам для каждого случая определения внешнего ключа. Конечно, для принятия такого решения необходимо анализировать требования конкретной прикладной области.
Множество операций над реляционными данными образуют реляционную алгебру. Каждая операция использует одну или две таблицы. Основных операций восемь, которые разбиты на две группы.
Объединение двух отношений (С1 = А U В) предполагает, что на входе задано два односхемных отношения А и В. Результат объединения есть построенное по той же схеме отношение С, содержащее все кортежи А и все кортежи отношения В.
Пересечение двух отношений (С2=А U В) предполагает на входе два односхемных отношения А и В. На выходе создается отношение по той же схеме, содержащее только те кортежи отношения А, которые есть в отношении В.
Вычитание двух отношений (С3=А-В). Все три отношения строятся по одной схеме. В результирующее отношение С3 включаются только те кортежи из А, которых нет в отношении В.
Декартово произведение (С4=А X В). Ее важное отличие от предшествующих состоит в том, что отношения А и В могут быть построены по разным схемам, а схема отношения С4 включает все атрибуты отношении А и В.
a b c |
|
x y |
= |
a a b b c c |
x y x y x y |
Операция селекция (горизонтальное подмножество) выполняется по строкам. На входе операции используется одно отношение. Результат выборки есть новое отношение, построенное по той же схеме, содержащее подмножество кортежей исходного отношения, удовлетворяющих условию выборки.
Операция проекция (вертикальное подмножество). На входе операции используется одно отношение. Результирующее отношение включает подмножество атрибутов исходного. Каждому кортежу исходного отношения соответствует такой кортеж в результирующем отношении, что значения одинаковых атрибутов этих двух кортежей совпадают. Но при этом в результирующем отношении кортежи-дубликаты устраняются, в связи с чем мощность результирующего отношения может быть меньше мощности исходного.
Операция соединение естественное. На входе операции используется два отношения; обозначим их А и В. В каждом из отношений выделен атрибут, по которому будет осуществляться соединение; предположим, это атрибуты А1 и Б2). Оба атрибута должны быть определены на одном и том же домене. Схема результирующего отношения включает все атрибуты А и все атрибуты отношения В. Допускается, чтобы в схеме результирующего отношения вместо двух атрибутов, по которым выполняется соединение, был представлен только один. Операция соединение похожа на декартово произведение. Отличие состоит в том, что декартово произведение предполагает сцепление, каждого кортежа из А с каждым кортежем из В, а в операции соединения кортеж из отношения А сцепляется только с теми кортежами из В, для которых выполнено условие: В1=А1.
a1 a2 a3 |
b1 b1 b3 |
|
b1 b2 b3 |
c1 c2 c3 |
→ |
a1 a2 a3 |
b1 b1 b3 |
c1 c1 c3 |
Операция деление. На входе операции используется два отношения А и В. Пусть отношение А, называемое делимым, содержит атрибуты (А1,А2, ...,Аn). Отношение В – делитель -содержит подмножество атрибутов А; положим, (А1,А2, ...,Аk), где (k<n). Результирующее отношение С определено на атрибутах отношения А, которых нет и В, т.е. Аk+1, Аk+2 , ..., Аn. Кортеж включается в результирующее отношение только, если его декартово произведение с отношением В содержится в делимом - отношении А.
Операции реляционной модели данных предоставляют возможность произвольно манипулировать отношениями, позволяя обновлять БД, а также выбирать подмножества хранимых данных и представлять их в нужном виде.
Рассмотренные нами операции реляционной алгебры или алгебры отношений, позволяют пошагово описать процесс получения результирующего отношения.
Одна из важнейших проблем проектирования схемы БД заключается в выделении типов записей (отношений), определении состава их атрибутов. Группировка атрибутов должна быть рациональной, т. е. минимизирующей дублирование данных и упрощающей процедуры их обработки и обновления.
Сначала эти вопросы решались интуитивно. Однако интуиция может подвести даже опытного специалиста, поэтому Коддом был разработан в рамках реляционной модели данных аппарат, называемый нормализацией отношений. И хотя идеи нормализации сформулированы в терминологии реляционной модели данных, они в равной степени применимы и для других моделей данных.
Коддом выделено три нормальных формы отношений. Самая совершенная из них - третья. Предложен механизм, позволяющий любое отношение преобразовать к третьей нормальной форме. В процессе таких преобразований могут выделяться новые отношения.
Вначале введем понятие простого и сложного атрибута. Простым назовем атрибут, если значения его атомарны, т. е. неделимы. В противовес ему сложный атрибут может иметь значение, представляющее собой конкатенацию нескольких значений одного или разных доменов. Аналогами сложного атрибута может быть вектор, агрегат данных, повторяющийся агрегат.
Отношение называется нормализованным или приведенным к первой нормальной форме (1НФ), если все его атрибуты простые.
Ненормализованное отношение легко сделать нормализованным. Такое преобразование может привести к увеличению мощности отношения и изменению ключа.
Функциональная зависимость. Пусть Х и Y - два атрибута некоторого отношения, Говорят, что Y функционально зависит от X, если в любой момент времени каждому значению Х соответствует не более чем одно значение атрибута Y. Функциональную зависимость можно обозначить так: Х>Y.
Полная функциональная зависимость. Говорят, что неключевой атрибут функционально полно зависит от составного ключа, если он функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа.
Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме и каждый неключевой атрибут функционально полно зависит от составного ключа.
Чтобы отношение привести ко второй нормальной форме, необходимо:
Транзитивная зависимость. Пусть X, Y, Z - три атрибута некоторого отношения. При этом Х>Y и Y>Z, но обратное соответствие отсутствует, т. е. Z не> или Y не>Х. Тогда говорят, что Z транзитивно зависит от X.
Отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. Рассматриваемая версия третьей нормальной формы часто называется нормальной формой Бойса-Кодда (НФБК).
Первая нормальная форма запрещает таблицам иметь неатомарные, или многозначные атрибуты. Однако существует множество ситуаций моделирования, требующих многозначных атрибутов. Например, преподаватель в вузе отвечает за несколько дисциплин. Существует несколько решений, каждое из которых имеет определенные недостатки. Все они требуют лишней памяти из-за наличия пустых значений, либо из-за необходимости вводить избыточные данные. Те из них, в которых есть пустые значения, нарушают категорийную целостность, поскольку все атрибуты вместе составляют ключ таблицы. Эти кажущиеся связи между независимыми атрибутами можно исключить, потребовав, чтобы каждое значение атрибута сочеталось с каждым значением другого атрибута как минимум в одной строке. Условие, обеспечивающее независимость атрибутов путем обязательного повторения значений, называется многозначной зависимостью. Многозначная зависимость является таким же ограничительным условием, как функциональная зависимость. Очевидно, что поскольку они требуют огромного числа повторений значений данных, важный этап процесса нормализации состоит в избавлении от многозначных зависимостей.
Таблица имеет четвертую нормальную форму (4НФ), если она имеет 3НФ и не содержит многозначных зависимостей.
Для избавления от некоторых других аномалий были предложены еще несколько нормальных форм: пятая нормальная форма (5НФ), нормальная форма область/ключ (НФОК) и т.д. Однако они имеют очень ограниченное практическое использование.
В заголовках элементов вместо «1 глава основной части», «2 глава основной части», «3 глава основной части» должны быть написаны номера и названия соответствующих глав, заголовок «Основная часть» должен оставаться без изменений.