20.09.2012
Служащий
Таблица №
ФИО
Адрес
Дата
ВУЗ
Адрес ВУЗА
Возможны случаи, когда экземпляры сущностей отличаются не по атрибутам, а по их связям с экземплярами других сущностей.
Пример:
Создается информационная система, для некоторого производства, в состав которого входит предприятие. У каждого предприятия своя независимая система введения табельных номеров сотрудников. Причем структура номеров у каждого предприятия одинакова.
В базе данных, которая будет хранить информацию о всех сотрудников объединения табельный номер потеряет свою уникальность. Теперь для однозначной идентификации сотрудника нужно вместе использовать и табельный номер и идентификатор предприятие. То-есть использовать связь между сотрудником и предприятием.
Составные объекты – связь между объектами, рассматриваемая как сущности.
Составной объект может иметь собственные атрибуты и участвовать в других связях.
Например:
Моделирование концептуальных и физических объектов.
При создании концептуальной модели данных могут возникать проблемы связанные с двусмысленностью естественного языка. Часто нужно различать концептуальные сущности, экземплярами, который являются абстрактные понятия и физические сущности, экземплярами которых являются физические объекты. А физические сущности соответствуют концептуальным сущностям.
27.09.2012.
Объединение локальных представлений
При объединении представлений используется три концепции:
1. Идентичность – два элемента модели идентичны, если имеют одинаковое смысловое значение.
2. Агрегация – позволяет рассматривать связь, между элементами моделей, как новый элемент. Может встречаться в трёх формах:
|
|
a. В одном представлении агрегатный объект определен как единое целое. Во втором представлении определены его составные части, но сам объект не определен.
b. Агрегатный объект, как единое целое не определен ни в одном из представлений, но в первом и во втором представлении, определенны его составные части.
c. Агрегатный объект определен в обоих представлениях, но его составные части отличаются.
3. Обобщение – это абстракция данных, позволяющая рассматривать класс различных, подобных объектов, как один общий пронумерованный объект.
….
….
Так как стол, стул, шкаф, полка являются подобными объектами, к ним можно применить обобщение, введя объект-компонент с дополнительным атрибутом «тип».
Реляционная модель данных
Реляционная модель данных представляет данные в виде таблицы. В реляционной теории, таблицы называются отношениями.
Строка отношения называется кортежем.
Реляционная модель представляет базу данных в виде взаимосвязанных таблиц. Между таблицами могут присутствовать иерархические связи. То-есть в каждой связи, одна таблица выступает в роли основной, а вторая как подчинённая. Это означает, что одна строка основной таблицы, может быть связанной с несколькими строками подчинёнными таблицами. Для поддержки этой связи обе таблицы должны иметь набор атрибутов, по которым они связанны (ключи). В основной таблице это первичный ключ, который однозначно определяет строку таблицы. А в подчиненной таблице для моделирования связи должен присутствовать набор атрибутов, соответствующий первичному ключу основной таблицы. Этот набор атрибутов называется внешним ключом.
|
|
…
…
Атрибуты внешнего ключа не обязательно должны иметь те же названия, что и атрибуты ключа, на который они ссылаются.
Свойства отношений:
1. Отсутствуют одинаковые строки – это следуют из того, что отношение рассматривается как множество строк.
2. Порядок строк не существенен.
3. Порядок столбцов не существенен.
4. Все значения в таблице носят атомарный характер – то-есть нельзя разбить на части не потеряв информацию.
Не всякая таблица является отношением. Чтобы таблица была отношением:
1. Все строки в ней должны иметь одинаковую структуру.
2. Все значение одного атрибута должны относится к одному домену.
3. Названия атрибутов, должны быть различными.
Достоинство реляционной модели данных:
1. Простота – пользователь формулирует запросы с точки зрения информационного содержания.
2.
В основе модели лежит давно и хорошо проработанная теория множеств.
Преобразование концептуальной модели данных в реляционную
1. Каждый объект концептуальной модели данных становится таблицей. Если объект имел ключевой продукт, то он становится ключевым атрибутом.
2. Чтобы задать связь 1:1, внешний ключ включается либо в первый объект, либо во второй.
3. Чтобы отобразить связь 1:N нужно в таблицу со стороны многие добавляется внешний ключ, соответствующий первичному ключу таблицы со стороны 1.
4. Чтобы отобразить связь N:N создается дополнительная таблица в которую помещается внешний ключ, соответствующий первичному ключу первой таблицы и ключ соответствующий первичному ключу второй таблицы. Если на основе этой связи существует составной объект с собственными атрибутами, то этот атрибут помещается в дополнительную таблицу.
|
|
В реляционной не может быть связи многие ко многим!!!
4.10.2012
Кодд опубликовал 12 правил соответствия произвольной СУБД, реляционной модели:
0. Подразумеваемое правило.
Система провозглашаемая поставщиком, как реляционная СУБД, должна управлять базой данных исключительными способами, соответствующими реляционной модели.
1. Информационное правило.
Вся информация, хранимая в базе данных, должна быть явна на логическом уровне, представлена единственным образом в виде реляционных таблиц.
2. Правило гарантированного логического доступа.
К каждому имеющемуся в базе данных атомарному значения в ячейке таблицы должен быть гарантирован доступ с указанием троих составляющих:
a. Имени таблицы
b. Имени столбца
c. Значение табличного ключа
3. Правило наличия значения.
В реляционной СУБД должны быть специальные указатели, отличные от пустой строки, от строки состоящей только из пробелов, от нуля и любого другого значения, для выражения не зависимо от типа данных, того факта, что данных в ячейке таблицы действительно нет (NULL).
4. Правило системного каталога
Описание базы данных логически выглядит, как обычные данные, то есть база данных должна содержать набор системных таблиц, описывающих структуру самой базы данных. Пользователи имеющие права на доступ к информации, могут работать с такими системными таблицами, с помощью того же реляционного языка, что и обычными таблицами.
5. Правило полноты языка работы с данными.
Сколько бы языков не поддерживало СУБД, должен существовать, по крайней мере, один язык, выразимый в виде командных строк, который позволял бы формулировать следующее:
a. Определение данных и задание самой структуры данных.
b. Определение правил целостности.
c. Манипулирование данными.
d. Определение представлений. В том числе возможности их модификации.
e. Определение правил авторизации
f. Границы транзакции.
6. Правило модификации представлений.
В СУБД должен существовать корректный алгоритм, позволяющий автоматически для каждого представления, в момент его создания, может ли оно использоваться для изменения данных в базовой таблице.
7. Правило множественности операций.
Возможность работать с таблицей, как с одним операндом, должна существовать не только при чтении, но и при модификации:
a. Добавление
b. Удаление.
c. Обновление.
8. Правило физической независимости.
Прикладные программы на логическом уровне не должны страдать при любых изменениях, во внутреннем хранении данных или методах доступа к ним.
9. Правило логической независимости.
Прикладные программы на логическом уровне не должны страдать от изменения в структуре в базовых таблиц, если теоретически неизменность в программ допускается.
10. Правило сохранение целостности.
Прикладные программы не должны изменяться при изменении правил целостности задаваемых в системном каталоге.
11. Правило независимости от распределённости.
Прикладные программы на логическом уровне не должны страдать от физического разнесения данных (если первоначальна база данных была нераспределенной или перераспределения данных).
12. Правило не нарушения реляционного языка.
Если в реляционной СУБД имеется язык низкого уровня, для работы с отдельными строками, он не должен позволять обходить или нарушать правила сформулированные на языке высокого уровня и занесенные в системный каталог.