Правила Джексона для перехода от модели Чена к реляционной модели. Реляционная модель данных. 12 правил Кодда

Вид материалаДокументы

Содержание


Реляционная модель данных.
12 правил Кодда, которым должна удовлетворять реляционная база данных.
Подобный материал:
1   2   3

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



Автор этой модели Тед Кодд, год рождения этой модели 1970. Основа этой модели – математическая теория отношений.

Отношение – это множество кортежей, среди которых нет повторений. Каждый объект описывает отдельный объект предметной области или связь между ними. Отношения в реляционной модели данных представлены в виде таблиц.


Например:


номер

название

вес

1

Гайка

17

2

Болт

13

3

Винт

14

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

Домен = dom содержит множество возможных значений данного атрибута.

Любая таблица есть подмножество деккартового произведения доменов

table

В СУБД обычно реализованы домены стандартные, например, целый, текст, дата/время. Для того чтобы уточнить какие значения могут принимать атрибуты накладываются ограничения на стандартные:

Целый 1-1000;

Вес 1-1000 гр.

А ограничения цвета можно записать в виде списка.

Атрибуты в модели Кодда должны быть атомарными, т.е. неделимыми, из стандартного набора доменов.

При этом возможны следующие ситуации:
  1. Не всегда в предметной области атрибуты бывают атомарными (скалярными)

{13.03.2000}
  1. Атрибуты бывают повторяющимися – множество значений одного типа, которые вместе характеризуют какое-то свойство



Песни, исполняемые в концерте.

номер

автор

1

Державин

2

Пахмутова

2

Добронравов

3

Добрынин



  1. Группа состоит из нескольких атрибутов разного типа:



....

адрес

....

Москва, ул. Ленина 17-18

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


Например,


Ф.И.О.

адрес

Иванов...

Постоянной прописки




Временной прописки


Два адреса нельзя повторить, нужно снова ввести Ф.И.О. и новый адрес.


При этом могут возникнуть следующие аномалии:
  1. аномалия добавления

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

При удалении удаляется вся строка, при этом могут удалиться нужные сведения.
  1. Аномалия изменения

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

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

Название, вес, цвет, номерномер, название, цвет, вес.

Состав базу данных о поставщиках, деталях и поставках:

Создадим таблицу Поставщики (№поставщика, фамилия)



№ поставщика

фамилия

1

Иванов

2

Петров

3

Сидоров


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

Таблица Детали (№, название, цвет, вес) имеет вид:

№детали

Название детали

вес

цвет

1

Гайка

17

серый

2

Болт

13

черный

3

винт

14

красный

Таблица Поставка (№детали, №поставщика, количество):

№детали

№поставщика

количество

1

2

120

1

3

100

2

1

30

3

1

490

3

3

500

В таблице Поставки комбинация №поставщика и №детали является первичным ключом, а по отдельности они являются внешними ключами.

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

12 правил Кодда,

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




  1. Правило информации.

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

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

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

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

Языки могут быть разные, они должны содержать:
  • Описание данных;
  • Описание представлений – части информации, нужной для конкретного представления;
  • Обработка данных – интерактивная и программная. Интерактивная – запрос и тут же ответ, а программная – пишем программу запросов, обрабатываем, получаем результат.
  • Условия целостности. Целостность должна поддерживаться на уровне доменов, на уровне атрибутов, на уровне соответствия атрибутов. Кроме ссылочной целостности еще есть объектная целостность (в объектной таблице должны быть уникальные кортежи). Каскадное удаление означает, что при удалении объекта, удаляются и все его связи.
  • Идентификация прав доступа пользователя к данным. Это необходимо для исключения несанкционированного доступа.
  • Границы транзакции (начало – завершение - отмена). Транзакция – это работа, которая должна быть либо целиком выполнена, либо целиком не выполнена.
  1. правило обновления представлений.
  2. Правило добавления, обновления и удаления.

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

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

Реляционная база данных не должна быть привязана к конкретным потребностям конкретного пользователя.
  1. Правило единственности.

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