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

Составной ключ состоит из нескольких атрибутов. У объектов может быть несколько кандидатов на ключ.

Любому атрибуту может быть присвоено любой тип данных.

Домен это набор значений, которые удовлетворяют заданному условию.

Три вида связи между объектами:

1. 1:1 – это такая связь, в которой каждому экземпляру объекта А соответствует только один экземпляр объекта B и наоборот.

2. 1:N – это такой вид связи, при котором каждому экземпляру объекта A может соответствовать ноль, один или N экземпляров объекта B, но им соответствует только один экземпляр объекта A.

3. M:N - каждому экземпляру объекта А может соответствовать N экземпляров объектов B, и каждому экземпляру объекта B может соответствовать M экземпляров из объекта А.

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

КМД не зависит от типа структуры БД.

Логическая модель зависит от типа СУБД.

Физическая модель данных

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

Проектирование концептуальной модели данных.

В зависимости от информации положенного в основу проектирования, различают :

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

• Системное отображение предметной области

• Устойчивость информационной модели.

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

Недостаток:

• Сложность отбора информации, которая должна попасть в БД.

2. Подход от запроса – основная информация о предметной области представлена в виде запросов.

Недостаток:

• Не учитывает перспективы развития системы, а учитывает только текущие.

Целесообразно использовать оба подхода, с ведущим первым подходом.

Модель “сущность -> связь”

Базируется на трех понятиях:

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

2. Атрибут.

3. Связь:

• Может существовать связь между объектом и им самим.

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

Связь может быть обязательная и необязательная. Если связь обязательная, то каждый объект из этой связи должен участвовать в этой связи. Обязательные связи определяются для каждой стороны.

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

Пример:

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

20.09.2012

Служащий

Таблица №

ФИО

Адрес

Дата

ВУЗ

Адрес ВУЗА

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

Пример:

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

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

Составные объекты – связь между объектами, рассматриваемая как сущности.

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

Например:

Моделирование концептуальных и физических объектов.

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

27.09.2012.

Объединение локальных представлений

При объединении представлений используется три концепции:

1. Идентичность – два элемента модели идентичны, если имеют одинаковое смысловое значение.

2. Агрегация – позволяет рассматривать связь, между элементами моделей, как новый элемент. Может встречаться в трёх формах:

   1. В одном представлении агрегатный объект определен как единое целое. Во втором представлении определены его составные части, но сам объект не определен.

   2. Агрегатный объект, как единое целое не определен ни в одном из представлений, но в первом и во втором представлении, определенны его составные части.

   3. Агрегатный объект определен в обоих представлениях, но его составные части отличаются.

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

….

….

Так как стол, стул, шкаф, полка являются подобными объектами, к ним можно применить обобщение, введя объект-компонент с дополнительным атрибутом «тип».

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

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

Строка отношения называется кортежем.

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

…

…

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

Свойства отношений:

1. Отсутствуют одинаковые строки – это следуют из того, что отношение рассматривается как множество строк.

2. Порядок строк не существенен.

3. Порядок столбцов не существенен.

4. Все значения в таблице носят атомарный характер – то-есть нельзя разбить на части не потеряв информацию.

Не всякая таблица является отношением. Чтобы таблица была отношением:

1. Все строки в ней должны иметь одинаковую структуру.

2. Все значение одного атрибута должны относится к одному домену.

3. Названия атрибутов, должны быть различными.

Достоинство реляционной модели данных:

1. Простота – пользователь формулирует запросы с точки зрения информационного содержания.

В основе модели лежит давно и хорошо проработанная теория множеств.

Преобразование концептуальной модели данных в реляционную

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

2. Чтобы задать связь 1:1, внешний ключ включается либо в первый объект, либо во второй.

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

4. Чтобы отобразить связь N:N создается дополнительная таблица в которую помещается внешний ключ, соответствующий первичному ключу первой таблицы и ключ соответствующий первичному ключу второй таблицы. Если на основе этой связи существует составной объект с собственными атрибутами, то этот атрибут помещается в дополнительную таблицу.

В реляционной не может быть связи многие ко многим!!!

4.10.2012

Кодд опубликовал 12 правил соответствия произвольной СУБД, реляционной модели:

1. Подразумеваемое правило.

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

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

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

   1. Имени таблицы

   2. Имени столбца

   3. Значение табличного ключа

4. Правило наличия значения. В реляционной СУБД должны быть специальные указатели, отличные от пустой строки, от строки состоящей только из пробелов, от нуля и любого другого значения, для выражения не зависимо от типа данных, того факта, что данных в ячейке таблицы действительно нет (NULL).

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

6. Правило полноты языка работы с данными. Сколько бы языков не поддерживало СУБД, должен существовать, по крайней мере, один язык, выразимый в виде командных строк, который позволял бы формулировать следующее:

   1. Определение данных и задание самой структуры данных.

   2. Определение правил целостности.

   3. Манипулирование данными.

   4. Определение представлений. В том числе возможности их модификации.

   5. Определение правил авторизации

   6. Границы транзакции.

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

8. Правило множественности операций. Возможность работать с таблицей, как с одним операндом, должна существовать не только при чтении, но и при модификации:

   1. Добавление

   2. Удаление.

   3. Обновление.

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

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

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

12. Правило независимости от распределённости. Прикладные программы на логическом уровне не должны страдать от физического разнесения данных (если первоначальна база данных была нераспределенной или перераспределения данных).

13. Правило не нарушения реляционного языка. Если в реляционной СУБД имеется язык низкого уровня, для работы с отдельными строками, он не должен позволять обходить или нарушать правила сформулированные на языке высокого уровня и занесенные в системный каталог.