13.Реляционная модель данных. Свойства отношений

(различия между отношениями реляционной модели данных и простыми таблицами):

-Уникальность имени отношения. Имя одного отношения должно отличаться от имен других отношений.

-Уникальность кортежей. В отношении нет одинаковых кортежей. -Действительно, тело отношения есть множество кортежей и, как всякое множество, не может содержать неразличимые элементы. Таблицы в отличие от отношений могут содержать одинаковые строки. Каждая ячейка отношения содержит только атомарное (неделимое) значение.

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

-Неупорядоченность атрибутов. Атрибуты не упорядочены (слева направо).

-Уникальность имени атрибута в пределах отношения. Каждый атрибут имеет уникальное имя в пределах отношения, значит, порядок атрибутов не имеет значения (для сравнения — столбцы в таблице упорядочены). Это свойство несколько отличает отношение от математического определения отношения. Одно и то же отношение может быть изображено разными таблицами, в которых столбцы идут в различном порядке.

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

 

14.Реляционная модель данных. Виды отношений.

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

• "Промежуточные результаты вычисления выражений.

• Локальные переменные в вызове процедур.

• Собственные переменные (как в ALGOL-60), глобальные переменные и динамически создаваемые данные.

• Данные, сохраняющиеся между сеансами выполнения программы.

• Данные, сохраняемые при переходе на новую версию программы.

• Данные, которые вообще переживают программу" .

Традиционно, первыми тремя уровнями занимаются языки программирования, а последними - базы данных. Этот конфликт культур приводит к неожиданным решениям: программисты разрабатывают специальные схемы для сохранения объектов в период между запусками программы, а конструкторы баз данных переиначивают свою технологию под короткоживущие объекты. Введение сохраняемости, как нормальной составной части объектного подхода приводит нас к объектно-ориентированным базам данных (OODB, object-oriented databases). На практике подобные базы данных строятся на основе проверенных временем моделей - последовательных, индексированных, иерархических, сетевых или реляционных, но программист может ввести абстракцию объектно-ориентированного интерфейса, через который запросы к базе данных и другие операции выполняются в терминах объектов, время жизни которых превосходит время жизни отдельной программы. Языки программирования, как правило, не поддерживают понятия сохраняемости; примечательным исключением является Smalltalk. Как правило, сохраняемость достигается применением (немногочисленных) коммерческих OODB. Другой вариант - создать объектно-ориентированную оболочку для реляционных СУБД; это лучше, в частности, для тех, кто уже вложил средства в реляционную систему. Сохраняемость - это не только проблема сохранения данных. В OODB имеет смысл сохранять и классы, так, чтобы программы могли правильно интерпретировать данные. Это создает большие трудности по мере увеличения объема данных, особенно, если класс объекта вдруг потребовалось изменить. До сих пор мы говорили о сохранении объектов во времени. В большинстве систем объектам при их создании отводится место в памяти, которое не изменяется и в котором объект находится всю свою жизнь. Однако для распределенных систем желательно обеспечивать возможность перенесения объектов в пространстве, так, чтобы их можно было переносить с машины на машину и даже при необходимости изменять форму представления объекта в памяти. Сохраняемость - способность объекта существовать во времени, переживая породивший его процесс, и (или) в пространстве, перемещаясь из своего первоначального адресного пространства.