Главная Разное Реляционная информационная модель. Основные понятия реляционной модели данных. Элементы реляционной модели

Реляционная информационная модель. Основные понятия реляционной модели данных. Элементы реляционной модели

Реляционная модель базируется на теоретико-множественном понятии отношения. В математических дисциплинах существует понятие «отношение » (relation), физическим представлением которого является таблица . Отсюда и произошло название модели - реляционная .

Применительно к БД понятия «реляционная БД» и «табличная БД» являются синонимами. Реляционные базы получили наибольшее распространение в мире. Почти все продукты БД, созданные с конца 70-х годов, являются реляционными.

В 1970 году появились работы, в которых обсуждались возможности применения различных табличных моделей данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э. Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks (Реляционная модель данных для больших совместно используемых банков данных). CACM 13: 6, June 1970), где впервые был применен термин "реляционная модель данных" . Проект System R был разработан в исследовательской лаборатории корпорации IBM. Этот проект был задуман с целью доказать практичность реляционной модели. Реляционные СУБД относятся к СУБД второго поколения.

Цели создания реляционной модели данных:

1. Обеспечение более высокой степени независимости от данных.

2. Создание прочного фундамента для решения проблем непротиворечивости и избыточности данных.

3. Расширение языков управления данными за счет включения операций над множествами.

Коммерческие системы на основе реляционной модели данных начали появляться в конце 70-х - начале 80-х годов. В настоящее время существует несколько сотен типов различных реляционных СУБД.

Реляционная модель является удобной и наиболее привычной формой представления данных в виде таблицы (отношения ). Каждое отношение имеет имя и состоит из поименованных атрибутов (столбцов) данных. Одним из основных преимуществ реляционной модели является ее однородность . Все данные хранятся в таблицах, в которых каждая строка имеет один и тот же формат. Каждая строка в таблице представляет некоторый объект реального мира или соотношение между объектами.

Основными понятиями, с помощью которых определяется реляционная модель, являются следующие:

- реляционная БД - набор нормализованных отношений;

- отношение - файл, плоская таблица, состоящая из столбцов и строк; таблица, в которой каждое поле является атомарным;

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

- универсум - совокупность значений всех полей или совокупность доменов;

- кортеж - запись, строка таблицы;

- кардинальность - количество строк в таблице;

- атрибуты - поименованныеполя, столбцы таблицы;

- степень отношения - количество полей (столбцов);

- схема отношения - упорядоченный список имен атрибутов;

- схема реляционной БД - совокупность схем отношений;

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

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

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

Соотношение этих понятий иллюстрируется на рис. 4.5.

№	ФИО	Год рожд.	Должность	Кафедра
1.	Иванов И. И.		Зав. каф.	22
2.	Сидоров С. С.		Проф.	22
3.	Андреева Г. Г.		Проф.	22
4.	Цветкова С. С.		Доцент
5.	Козлов К. К.		Доцент	22
6.	Петров П. П.		Ст. преп.	22

Атрибуты

рис. 4.5. Основные понятия реляционной модели данных.

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

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

Внешние ключи реализуют связи между таблицами БД.

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

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

Каждая реляционная таблица обладает следующими свойствами :

Имеет имя, которое отличается от имен всех других таблиц;

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

Все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;

Каждый столбец имеет уникальное имя;

Одинаковые строки в таблице отсутствуют;

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

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

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

Эти отношения обладают следующими характеристиками:

отношение имеет имя, которое отличается от имен всех других отношений в реляционной схеме;

каждая ячейка отношения содержит только одно элементарное (неделимое) значение;

каждый атрибут имеет уникальное имя;

значения атрибута берутся из одного и того же домена;

каждый кортеж является уникальным, т.е. дубликатов кортежей быть не может;

порядок следования атрибутов не имеет значения;

теоретически порядок следования кортежей в отношении не имеет значения; (Но практически этот порядок может существенно повлиять на эффективность доступа к ним)

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

во множестве нет повторяющихся элементов. Аналогично, отношение не может содержать кортежей-дубликатов;

поскольку отношение является множеством, то порядок элементов не имеет значения. Следовательно, порядок кортежей в отношении несуществен.

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

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

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

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

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

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

Связь - это функциональная зависимость между сущностями. Например, "служащий" совершает "продажи".

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

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

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

Базовые отношения - это реально существующие модели отношения, которые соответствуют реальному объекту предметной области.

Пусть даны отношения R1 и R2. Пусть k1, - это первичный ключ отношения R1.

Если в отношении R2 присутствуют атрибуты k1, то для отношения R2, k1 - это внешний ключ. Если базовое отношение R2 содержит внешний ключ k1, то каждое значение k1 в R2 должно быть либо равным какому-либо значению R1, либо полностью неопределенным.

Достоинствами реляционного подхода являются:

1. Наличие простого, и в тоже время мощного математического аппарата

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

Чтобы база данных была надежной, необходимо чтобы существовала нормализация. Существуют три нормальных формы.

Итак, условия первой нормальной формы:

Определить требуемые элементы данных, потому что они становятся столбцами в таблице. Поместить связанные элементы данных в таблицу.

Гарантировать отсутствие повторяющихся групп данных.

Гарантировать наличие первичного ключа.

Значение всех атрибутов атомарны.

Информационная система находится в первой нормальной форме.

Условия второй нормальной формы:

Отношение в первой нормальной форме.

Независимость первичных ключей и столбцов

Информационная система находится во второй нормальной форме.

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

Условия третьей нормальной формы:

Отношение во второй нормальной форме.

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

Информационная система находится в третьей нормальной форме.

Таким образом, нормализация отношений успешно достигнута.

После нормализации отношений было создано 7 таблиц. Проиллюстрируем эти таблицы в режиме конструктора:

Рисунок 2.2 - Главная таблица в режиме конструктора

Рисунок 2.3 - Таблица "Инструкторы" в режиме конструктора

Рисунок 2.4 - Таблица "Клиенты" в режиме конструктора

Рисунок 2.5 - Таблица "Код операции" в режиме конструктора

Рисунок 2.6 - Таблица "Подъемник" в режиме конструктора

Рисунок 2.7 - Таблица "Прокат (прокат)" в режиме конструктора

Рисунок 2.8 - Таблица "Прокат (экипировка)" в режиме конструктора

Рисунок 2.9 - Таблица "Склон - Трансфер" в режиме конструктора

Рисунок 2.10 - Таблица "Склоны" в режиме конструктора

Рисунок 2.11 - Таблица "Услуга (трансфер)" в режиме конструктора

Реляционная модель данных (РМД) некоторой предметной области представляет собой набор отношений, изменяющихся во времени. При создании информационной системы совокупность отношений позволяет хранить данные об объектах предметной области и моделировать связи между ними. Элементы РМД и формы их представления приведены в табл. 3.1.

Таблица 3.1 Элементы реляционной модели

Отношение является важнейшим понятием и представляет собой двумерную таблицу, содержащую некоторые данные.

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

Атрибуты представляют собой свойства, характеризующие сущность. В структуре таблицы каждый атрибут именуется и ему соответствует заголовок некоторого столбца таблицы.
Математически отношение можно описать следующим образом. Пусть даны n множеств Dl, D2, D3,..., Dn, тогда отношение R есть множество упорядоченных кортежей , где dk ? Dk, dk - атрибут , a Dk - домен отношения R.

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

Домен представляет собой множество всех возможных значений определенного атрибута отношения. Отношение СОТРУДНИК включает 4 домена. Домен 1 содержит фамилии всех сотрудников, домен 2 - номера всех отделов фирмы, домен 3 - названия всех должностей, домен 4 - даты рождения всех сотрудников. Каждый домен образует значения одного типа данных, например, числовые или символьные.

Отношение СОТРУДНИК содержит 3 кортежа. Кортеж рассматриваемого отношения состоит из 4-х элементов, каждый из которых выбирается из соответствующего домена. Каждому кортежу соответствует строка таблицы.

Схема отношения (заголовок отношения) представляет собой список имен атрибутов. Например, для приведенного примера схема отношения имеет вид СОТРУДНИК (ФИО, Отдел, Должность, Д_Рождения). Множество собственно кортежей отношения часто называют содержимым (телом) отношения .

Первичным ключом (ключом отношения, ключевым атрибутом) называется атрибут отношения, однозначно идентифицирующий каждый из его кортежей. Например, в отношении СОТРУДНИК (ФИО, Отдел, Должность, Д_Рождения) ключевым является атрибут "ФИО". Ключ может быть составным (сложным) , т. е. состоять из нескольких атрибутов.

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

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

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

Ключи обычно используют для достижения следующих целей:

1) исключения дублирования значений в ключевых атрибутах (остальные атрибуты в расчет не принимаются);

2) упорядочения кортежей. Возможно упорядочение по, возрастанию или убыванию значений всех ключевых атрибутов, а также смешанное упорядочение (по одним - возрастание, а по другим - убывание);

3) ускорения работы к кортежами отношения (подраздел 3.2);

4) организации связывания таблиц (подраздел 3.3).

Пусть в отношении R1 имеется не ключевой атрибут А, значения которого являются значениями ключевого атрибута В другого отношения R2. Тогда говорят, что атрибут А отношения R1 есть внешний ключ .

С помощью внешних ключей устанавливаются связи между отношениями. Например, имеются два отношения СТУДЕНТ (ФИО, Группа, Специальность) и ПРЕДМЕТ (Назв.Пр., Часы), которые связаны отношением СТУДЕНТ_ПРЕДМЕТ (ФИО, . Назв.Пр. Оценка) (рис. 3.2). В связующем отношении атрибуты ФИО и Назв.Пр образуют составной ключ. Эти атрибуты представляют собой внешние ключи, являющиеся первичными ключами других отношений.

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

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

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

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

3. Все строки одной таблицы должны иметь одну структуру, соответствующую именам и типам столбцов.

4. Порядок размещения строк в таблице может быть произвольным.

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

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

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

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

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

К отношениям можно применять систему операций, позволяющую получать одни отношения из других. Например, результатом запроса к реляционной БД может быть новое отношение, вычисленное на основе имеющихся отношений. Поэтому можно разделить обрабатываемые данные на хранимую и вычисляемую части. Основной единицей обработки данных в реляционных БД является отношение, а не отдельные его кортежи (записи).

Индексирование

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

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

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

Варианты решения проблемы организации физического доступа к информации зависят в основном от следующих факторов:

Вида содержимого в поле ключа записей индексного файла;

Типа используемых ссылок (указателей) на запись основной таблицы;

Метода поиска нужных записей.

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

Абсолютный (действительный)

Относительный

Символический (идентификатор).

На практике чаще всего используются два метода поиска :

Последовательный

Бинарный (основан на делении интервала поиска пополам).

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

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

Если в индексном файле хранятся хеш-коды ключевых полей индексированной таблицы, то алгоритм поиска нужной записи (с указанным ключом) в таблице включает в себя следующие три этапа.

1. Образование свертки значения ключевого поля искомой записи.

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

3. Последовательный просмотр записей блока до совпадения сверток искомой записи и записи блока файла. В случае коллизий сверток ищется запись, значение ключа которой совпадает со значением ключа искомой записи.

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

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

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

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

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

Некоторыми СУБД, например Access, деление индексов на первичные и вторичные не производится. В этом случае используются автоматически создаваемые индексы и индексы, определяемые пользователем по любому из не ключевых полей.

Главная причина повышения скорости выполнения различных операций в индексированных таблицах состоит в том, что основная часть работы производится с небольшими индексными файлами, а не с самими таблицами. Наибольший эффект повышения производительности работы с индексированными таблицами достигается для значительных по объему таблиц. Индексирование требует небольшого дополнительного места на диске и незначительных затрат процессора на изменение индексов в процессе работы. Индексы в общем случае могут изменяться перед выполнением запросов к БД, после выполнения запросов к БД, по специальным командам пользователя или программным вызовам приложений.

Связывание таблиц

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

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

Локальная модель

Файл-серверная модель

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

Количество клиентов ограничено десятками.

Плюсы:

1. Многопользовательский режим работы с данными;

2. Удобство централизованного управления доступом;

3. Низкая стоимость разработки;

Минусы:

1. Низкая производительность;

2. Низкая надежность;

3. Слабые возможности расширения;

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

надежность приложения.

Модель удаленного доступа

Модель сервера данных

Модель телеобработки

Модель сервера приложений

2. Архитектура базы данных. Физическая и логическая независимость

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

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД , предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД , изображенная на рис. 2:

Рис. 2. Трехуровневая модель системы управления базой данных, предложенная ANSI

1. Уровень внешних моделей - самый верхний уровень, где каждая модель имеет свое "видение" данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению. Например, система распределения работ использует сведения о квалификации сотрудника, но ее не интересуют сведения об окладе, домашнем адресе и телефоне сотрудника, и наоборот, именно эти сведения используются в подсистеме отдела кадров.

2. Концептуальный уровень - центральное управляющее звено, здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов реального мира.

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

Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных. Физическая независимость предполагает возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных. Это именно то, чего не хватало при использовании файловых систем.

Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных.

3. Модели данных.

Основа информационной системы, объект ее обработки - база данных (БД). База данных - это совокупность сведений о конкретных объектах реального мира в какой-либо предметной области или разделе предметной области. Например, база данных по вузам (высшее образование), база данных по лекарственным препаратам (медицина), база данных по автомобилям (автомагазин), база данных по стройматериалам (склад) и т.п. Синоним термина «база данных» - «банк данных».

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

Различают три основных типа моделей данных: иерархическую, сетевую и реляционную .

Иерархическая структура представляет собой совокупность элементов, в которой данные одного уровня подчинены данным другого уровня, а связи между элементами образуют древовидную структуру. В такой структуре исходные элементы порождают другие элементы, причем эти элементы в свою очередь порождают следующие элементы и т.д. Существенно то, что каждый порожденный элемент имеет только одного «родителя». Обратите внимание, что в иерархической структуре порождающим элементом может быть не объект сам по себе, а только конкретный экземпляр объекта. Примером иерархической базы данных может служить генеалогическое древо вашей семьи.

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

4. Основные определения реляционной модели данных

Реляционная модель данных – логическая модель данных. Впервые была предложена британским учёным сотрудником компании IBM Эдгаром Франком Коддом (E. F. Codd). В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.

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

§ структурная

§ манипуляционная

§ целостная

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

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

Целостная часть модели определяет требования целостности сущностей и целостности ссылок . Первое требование состоит в том, что любой кортеж любого отношения отличим от любого другого кортежа этого отношения, т.е. другими словами, любое отношение должно обладать первичным ключом. Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в отношении, на которое ведет ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать).

Структура реляционной модели данных

Можно провести аналогию между элементами реляционной модели данных и элементами модели "сущность-связь". Реляционные отношения соответствуют наборам сущностей, а кортежи – сущностям. Поэтому, также как и в модели "сущность-связь" столбцы в таблице, представляющей реляционное отношение, называют атрибутами.

Основные компоненты реляционного отношения

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

В примере, показанном на рисунке, атрибуты "Оклад" и "Премия" определены на домене "Деньги". Поэтому, понятие домена имеет семантическую нагрузку: данные можно считать сравнимыми только тогда, когда они относятся к одному домену. Таким образом, в рассматриваемом нами примере сравнение атрибутов "Табельный номер" и "Оклад" является семантически некорректным, хотя они и содержат данные одного типа.

Именованное множество пар "имя атрибута – имя домена" называется схемой отношения . Мощность этого множества - называют степенью или "арностью" отношения. Набор именованных схем отношений представляет из себя схему базы данных .

Атрибут, значение которого однозначно идентифицирует кортежи, называется ключевым (или просто ключом ). В нашем случае ключом является атрибут "Табельный номер", поскольку его значение уникально для каждого работника предприятия. Если кортежи идентифицируются только сцеплением значений нескольких атрибутов, то говорят, что отношение имеет составной ключ. Отношение может содержать несколько ключей. Всегда один из ключей объявляется первичным, его значения не могут обновляться. Все остальные ключи отношения называются возможными ключами .

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

5. Жизненный цикл базы данных. Этапы ЖЦ БД.

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

Исследование и анализ проблемы, для решения которой создаётся база данных.
Построение Инфологической и Даталогической модели.
Нормализация полученных Инфологических и Даталогических моделей. По окончании этого этапа, как правило получают заготовки таблицы БД и набор связей между ними (первичные и вторичные ключи)
Проверка целостности БД (Целостность базы данных)
Выбор физического способа хранения и эксплуатации (тех. средства) базы данных.
Проектирование входных и выходных форм.
Разработка интерфейса приложения.
Функциональное наполнение приложения
Отладка: проверка на корректность работы функционального наполнения системы
Тестирование: тест на корректность ввода вывода данных, тест на максимальное количество активных сессий и т. д.
Ввод в эксплуатацию: отладка ИТ-инфраструктуры, обучение пользователей и ИТ-персонала.
При необходимости добавления выходных форм и дополнительной функциональности. В случае если необходимы более серьёзные изменения, следует повторить все шаги с первого.
Вывод из эксплуатации: перенос данных в новую СУБД.

6. Основные свойства единиц информации. Составная единица информации. Описание структуры СЕИ. Показатели

Составная единица информации (СЕИ) – это набор из атрибутов и, возможно других СЕИ. Определение СЕИ рекурсивно. База данных тоже ЕИ. Множество атрибутов объединяются в одну СЕИ по следующим признакам:

Соответствующие атрибуты описывают один и тот же факт или экономический процесс

Значения атрибутов, входящих в СЕИ, возникают одновременно, связаны арифметическими или логическими отношениями.

Простейшая характеристика СЕИ представлена именем, структурой и значением.

Имя – обозначение СЕИ в процессах обработки информации

Структура – вхождение одних единиц информации в состав других единиц

информации.

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

Описание структуры СЕИ

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

Показатель

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

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

В состав показателя должны входить один атрибут- основание и несколько атрибутов-признаков, однозначно характеризующих условия существования основания. Как единица информации показатель является разновидностью СЕИ.

Структура показателя:

П.(Р1, Р2,...,Рк, Q),

где Q - атрибут-основание, Р1, Р2,...,Рк - атрибуты- признаки. Таким образом, в показателях отражаются количественные свойства объектов и процессов.

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

1. Атрибуты отображающие идентификаторы объектов

2. Атрибуты, отображающие признак времени

3. Атрибут, отображающий некоторое количественное свойство объекта или взаимодействия.

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

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

2. Если значение атрибута текстовое, то это признак

3. Если атрибут обозначает предмет, это признак

4. Если атрибут в некотором показателе является признаком, то он будет играть эту роль и в других показателях.

5. Если показатели описывают сходные процессы, то их призначные части совпадают.

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

7. Операции над СЕИ: нормализация, свертка, декомпозиции, композиция, выборка, корректировка.

Нормализация – операция перехода от СЕИ с произвольной структурой к СЕИ с двухуровневой структурой. Одновременно происходит перекомпоновка значений СЕИ. Общее число значений в нормализованной СЕИ равно произведению размерностей всех СЕИ в исходном описании структуры.

Свёртка – это преобразование составной единицы информации с двухуровневой структурой в составную единицу информации с произвольной многоуровневой структурой. Свёртка нормализованной структуры может быть произведена в исходную в это смысле нормализация и свёртка взаимно-обратные операции.

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

Композиция – это операция преобразования нескольких составных единиц информации с различными структурами в одну СЕИ. Операция композиции обратна декомпозиции и точно определяется только для нормализованных исходных составных единиц информации. Условие выполнения операции композиции двух СЕИ – это наличие атрибутов, по которым они связаны.

Выборка – это операция выделения подмножества значений составной единицы информации, которая удовлетворяет заранее поставленным условиям выборки.

Корректировка – это выполнение одной из следующих операций:

1. Добавление нового значения

2. Исключение существующего значения

3. Замена некоторого значения на новое

Возможны более сложные режимы корректировки, например, внесение изменений в

несколько СЕИ одновременно.

8. Два класса отношений: объектное и связное. Ключи отношений. Индексы.

Операции над отношениями:

1. Традиционные операции (объединение, пересечение, разность, декартово произведение, деление)

2. Специальные реляционные операции (проекция, соединение, выбор) Эти операции реализуются с помощью специальных языков, которые делятся на два класса:

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

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

Различают 2 класса отношений в зависимости от содержания:

1. Объектное отношение

2. Связное отношение

Объектное отношение хранит данные об объектах, или экземплярах сущности. Один из атрибутов однозначно идентифицирует каждый объект. Это первичный ключ, который может состоять из нескольких атрибутов (составной ключ) или может быть частью значения атрибута (частичный ключ). Первичный ключ должен обладать двумя свойствами:

1. Запись должна однозначно определяться значением ключа

2. Никакое поле нельзя удалить из ключа, не нарушая при этом свойства однозначной идентификации

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

Ключи в связных отношениях называются внешними, т.к. они являются первичными ключами других отношений. Реляционная модель накладывает на внешние ключи ограничение для обеспечения целостности, называемые ссылочной целостностью. Это значит, что каждому внешнему ключу должна соответствовать строка какого-либо объектного отношения, иначе окажется, что внешний ключ ссылается на неизвестный объект. Ещё одно ограничение на отношения в реляционной БД говорит о том, что каждое отношение должно иметь простые атрибуты, т.е. содержать атомарные, неделимые значения.

Отношение, у которого все атрибуты простые, называется приведённым к первой нормальной форме.

9. Нормализация отношений. Требования при группировке атрибутов в отношения в реляционной БД.

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

Центральная задача проектирования базы данных ИС - определение количества отношений (или иных составных единиц информации) и их атрибутного состава.

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

· множество отношений должно обеспечивать минимальную избыточность представления информации,

· корректировка отношений не должна приводить к двусмысленности или потере информации,

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

Удовлетворение этих требований достигается нормализацией отношений БД.

10. Функциональные зависимости. Нормальные формы.

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

Например, пусть в отношении R1 имеются 2 атрибута А и В. Атрибут В функционально зависит от атрибута А, если в любой момент времени каждое значение атрибута А соответствует единственному значению атрибута В. Обозначается А→В (если нет зависимости, то А В).

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

Если не ключевой атрибут зависит только от части ключа, то говорят о частичной зависимости .

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

Каждая НФ ограничена определенным типом функциональной зависимости и устраняет аномалии при выполнении Оп при рассмотрении БД.

Такие частичные зависимости приводят, например, к следующим аномалиям :

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

2) проблема контроля избыточности данных, т.к. изменение, например, расценки влечет за собой

необходимость поиска и изменения значений расценки во всех кортежах;

3) проблема с рабочими, которые в данное время не работают (их нельзя включить в отношение, поскольку все атрибуты кортежа должны иметь определенные значения), т.е. данные о рабочем без данных о детали нельзя включить в отношение; если рабочий увольняется, то данные о нем должны быть удалены из отношения, при этом удаляются и данные о детали, а этого не должно быть.

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

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

2) построить проекцию на часть составного ключа и атрибуты, зависящие от этой части.

Если для атрибутов A, B,C выполняются условия A→B и B→C, но обратная зависимость отсутствует, то С зависит от А транзитивно, т.е. можно говорить о транзитивной зависимости. Наличие транзитивных зависимостей порождает неудобства и аномалии следующего характера:

1) Дублирование информации о телефоне для нескольких рабочих

2) Проблема поиска и контроля при изменении номера телефона.

Таким образом, 2НФ также может требовать дальнейших преобразований.

Отношение находится в 3НФ, если оно находится во 2НФ и нем отсутствуют транзитивные зависимости не ключевых атрибутов от ключа. БД находится в 3НФ, если все ее отношения имеют 3НФ.

Алгоритм получения 3НФ:

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

Алгоритм получения отношений в ЗНФ обладает следующими свойствами:

Сохраняет все первоначальные функциональные зависимости, т.е. зависимость, справедливая в R, справедлива и в одном из производных отношений. Это гарантирует получение осмысленных отношений с легко интерпретируемой структурой,

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

Результат декомпозиции в ЗНФ обычно содержит меньше значений атрибутов, чем исходное отношение R (происходит уменьшение избыточности

Алгоритм состоит из следующий шагов:

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

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

3) Для каждой функциональной зависимости, полученной на 2 шаге создать проекцию исходных отношений, R[X], где X – объединение атрибутов из левой и правой частей функциональной зависимостей.

4) Если первичный ключ исходного отношения не вошел полностью ни в одну проекцию, то создаем отношение из атрибутов ключа.

БКНФ (Бойса-Кодда)

Считается, что отношение находится в нормальной форме БК, если оно находится в 3НФ и в нем отсутствуют зависимости ключевых атрибутов от неключевых.

Отношение находится в 4НФ, если оно находится в НФБК и в нем отсутствуют многозначные зависимости не являющиеся функциональными.

5НФ . Отношение R находится в пятой нормальной форме (5НФ ) тогда и только тогда, когда любая имеющаяся зависимость соединения является тривиальной .

Зависимость соединения называется нетривиальной зависимостью соединения , если выполняется два условия:

11. Операции над отношениями: объединение, пересечение, разность, декартово произведение.

Отношения

В реляционной алгебре в качестве операндов выступают отношения, а основными операциями, выполняемыми над отношениями, являются:

· объединение

· пересечение

· разность

· декартово произведение

· деление

· проекция

· соединение

Введем некоторые понятия.

Степенью отношения называется число входящих в него атрибутов.

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

ОБЪЕДИНЕНИЕ (R U S) отношений R и S представляет собой множество кортежей, которые принадлежат R или S, либо им обоим. Операция объединения выполняется над двумя совместимыми отношениями.

ПЕРЕСЕЧЕНИЕ. Результат пересечения R и S содержит только те кортежи первого отношения R, которое есть во втором S.

РАЗНОСТЬ. Результат вычитания (R-S) включает только те кортежи первого отношения R, которых нет во втором S.

ДЕКАРТОВО ПРОИЗВЕДЕНИЕ (R x T). Здесь операнды-отношения R и T могут иметь разные схемы: Степень результирующего отношения (R x T) равна сумме степеней отношений операндов (R и T), а мощность - произведение их мощностей.

12. Операции над отношениями: деление.

ДЕЛЕНИЕ (R / T). Операция в некотором смысле обратна операции "декартово произведение". Отношение "делимое" (R) должно содержать подмножество атрибутов отношения "делитель" (T). Результирующее отношение (R / T) содержит только те атрибуты делимого, которых нет в делителе. В него включают только те кортежи, декартово произведение которых с делителем содержатся в делимом.

13. Операции над отношениями: проекция, выборка, соединение.

ПРОЕКЦИЯ. Эта операция в отличие от всех предыдущих является унарной, т.е. выполняется над одним отношением (R). Результирующее отношение П (R) включает часть атрибутов исходного, на которые выполняется проекция. Кортежи-дубликаты отсутствуют.

Где X – список атрибутов в схеме отношения.

СОЕДИНЕНИЕ. Операция соединения выполняется над двумя отношениями (R и S). В каждом отношении выделяется атрибут, по которому будет производиться соединение. В качестве атрибута для соединения выберем атрибут B. Результирующее отношение включает все атрибуты первого отношения (R) и второго отношения (S):

ВЫБОР. Операция выполняется над одним отношением (R). Результирующее отношение (OB=b(R)) содержит подмножества кортежей, выбранных по некоторому условию (B = b).

14. Проектирование БД (архитектура ANSI / SPARC)

Архитектура ANSI-SPARC (также 3х-уровневая архитектура ) определяет принцип, согласно которому рекомендуется строить системы управления базами данных(СУБД).

Проект архитектуры был выдвинут в 1975 году подкомитетом SPARC ANSI.

3 уровня СУБД:

внешний (пользовательский)
промежуточный (концептуальный )
внутренний (физический)

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

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

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

15. Инфологическое моделирование. Модель «сущность-связь» (ER-модель)

Инфологическая модель (ИМ) - это формализованное описание естественной структуры информации предметной области, не зависящее от последующей реализации ее хранения.

ER-модель (Entity-Relationship Model – модель «сущность-связь») - представление ИМ, основывающееся на структурных элементах «сущность», «свойство», «связь».

Сущности и свойства

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

Простой объект - характеризуется набором простых единичных, безусловных свойств.

Идентификатор ‐ одно или несколько свойств, по значениям которых однозначно различаются все экземпляры сущности (объекта).

Простое свойство - состоит из одного компонента с независимым существованием.

Составное свойство - состоит из нескольких компонентов, каждый из которых характеризуется независимым существованием.

Единичное свойство - может содержать только одно значение определенного типа для любого экземпляра сущности.

Множественное свойство - может содержать несколько значений определенного типа для любого экземпляра сущности.

Связь - описание связанности двух сущностей и их экземпляров.

Множественность (кардинальность) указывает для каждой стороны количество экземпляров сущности, которое может быть одновременно связано с одним экземпляром другой сущности. Варианты связи по множественности: 1:1, 1:М, М:М.

1. отношение “один к одному” (1:1) означает, что каждая запись одной таблицы соответствует только одной записи в другой таблице;

2. отношение “один ко многим” (1:М) возникает, когда одна запись взаимосвязана со многими другими;

3. отношение “многие к одному” означает, что многие записи связаны с одной (М:1);

4. отношение “многие ко многим” (M:N) возникает между двумя таблицами в тех случаях, когда:

· одна запись из первой таблицы может быть связана более чем с одной записью из второй таблицы;

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

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

Обязательность (степень участия) - указывает для каждой стороны обязательность вхождения экземпляров сущности в связь экземплярами другой сущности.

Ассоциация может использоваться для:

· Реализации связи М:М

· Связывания трех и более сущностей

· Хранения дополнительной информации о связи

· Последовательность инфологического проектирования:

· Определение сущностей

· Установление подчиненности сущностей и формирование сложных

объектов

· Установление связей и определение ассоциаций

· Определение свойств сущностей

· Определение идентификаторов

16. Критерии оценки качества логической модели данных. Переход к реляционной модели данных (6 правил)

Критерии оценки качества логической модели данных

Адекватность базы данных предметной области
База данных должна адекватно отражать предметную область. Это означает, что должны выполняться следующие условия:
1. Состояние базы данных в каждый момент времени должно соответствовать состоянию предметной области.
2. Изменение состояния предметной области должно приводить к соответствующему изменению состояния базы данных
3. Ограничения предметной области, отраженные в модели предметной области, должны некоторым образом отражаться и учитываться базе данных.
Легкость разработки и сопровождения базы данных
Практически любая база данных, за исключением совершенно элементарных, содержит некоторое количество программного кода в виде триггеров и хранимых процедур.
Хранимые процедуры - это процедуры и функции, хранящиеся непосредственно в базе данных в откомпилированном виде и которые могут запускаться пользователями или приложения-ми, работающими с базой данных.
Триггеры - это хранимые процедуры, связанные с некоторыми событиями, происходящими во время работы базы данных. В качестве таких событий выступают операции вставки, обновления и удаления строк таблиц. Если в базе данных определен некоторый триггер, то он запускается автоматически всегда при возникновении события, с которым этот триггер связан.
Скорость операций обновления данных (вставка, обновление, удаление)
На уровне логического моделирования мы определяем реляционные отношения и атрибуты этих отношений. На этом уровне мы не можем определять какие-либо физические структуры хранения (индексы, хеширование и т.п.). Единственное, чем мы можем управлять - это распределением атрибутов по различным отношениям. Можно описать мало отношений с большим количеством атрибутов, или много отношений, каждое из которых содержит мало атрибутов. Таким образом, необходимо попытаться ответить на вопрос - влияет ли количество отношений и количество атрибутов в отношениях на скорость выполнения операций обновления данных. Такой вопрос, конечно, не является достаточно корректным, т.к. скорость выполнения операций с базой данных сильно зависит от физической реализации базы данных. Тем не менее, попытаемся качественно оценить это влияние при одинаковых подходах к физическому моделированию.
Таким образом, можно принять допущение, что чем больше атрибутов имеют отношения, разработанные в ходе логического моделирования, тем медленнее будут выполняться операции обновления данных, за счет затраты времени на перестройку большего количества индексов.
Скорость операций выборки данных
Одно из назначений базы данных - предоставление информации пользователям. Информация извлекается из реляционной базы данных при помощи оператора SQL - SELECT. Одной из наиболее дорогостоящих операций при выполнении оператора SELECT является операция соединение таблиц. Таким образом, чем больше взаимосвязанных отношений было создано в ходе логического моделирования, тем больше вероятность того, что при выполнении запросов эти отношения будут соединяться, и, следовательно, тем медленнее будут выполняться запросы. Таким образом, увеличение количества отношений приводит к замедлению выполнения операций выборки данных, особенно, если запросы заранее неизвестны.

Т.к. в реляционной модели данных между отношениями поддерживаются только связи типа «один ко многим», а в ER-модели допустимы связи «многие ко многим», то необходим специальный механизм преобразования, который позволит отразить множественные связи, неспецифические для реляционной модели, с помощью недопустимых для неё категорий. Для построения логических моделей, реляционных баз данных, методом декомпозиции, сформулирован ряд правил, получивших название «правила преобразования ER-диаграмм в отношениях БД». Правила позволяют привести схемы отношений БД к нормальным формам. Если степень связи между сущностями определена, то предварительное отношения могут быть получены путём просмотра нескольких альтернатив и выбора варианта, наиболее подходящего с точки зрения правил предметной области. Определяющими признаками выбора одного из альтернативных вариантов представления отношения и класс принадлежности сущности.

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

Правило 2 . Если степень бинарной связи 1:1 и класс принадлежности одной сущности является обязательным, а другой сущности - не обязательным, то требуется построение двух отношений - по одному на каждую сущность. При этом первичным ключом каждого отношения является ключ его сущности, а ключ сущности с необязательным классом принадлежности добавляется в отношение для сущности с обязательным классом принадлежности в качестве атрибута (миграция ключа).

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

Правило 4 . Если степень бинарной связи 1:N, и класс принадлежности n-связной сущности является обязательным, то достаточно построить два отношения - по одному на каждую сущность. При этом ключ каждой сущности является первичным ключом соответствующего отношения, а ключ 1-связной сущности добавляется в отношение для n -связной сущности в качестве атрибута.

Правило 5. Если степень бинарной связи 1:N и класс принадлежности n-связной сущности не является обязательным, то необходимо построить три отношения - по одному на каждую сущность. При этом ключ каждой сущности является первичным ключом соответствующего отношения и одного отношения для связи. Ключи сущностей должны быть атрибутами последнего отношения.

Отметим, что если степень бинарной связи 1:N, то фактором, определяющим выбор одного из правил (правила 4, 5), является класс принадлежности n-связной сущности. Класс принадлежности 1-связной сущности не влияет на конечный результат декомпозиции. В ситуации правила 4 имеет место проблема нуль-значений по атрибуту Предмет, в ситуации правила 5 имеет место проблема нуль-значений по атрибутам Предмет и Преподаватель. Поэтому во избежание дублирования и нуль-значений в ситуации правил 4 и 5 необходимо строить два и три результирующих отношения соответственно. Миграция ключа 1-связной сущности выполняется для восстановления исходного отношения при соединении.

Если степень бинарной связи N:M, то во избежание дублирования и нуль-значений необходимо всегда строить три отношения. Сформулируем шестое правило.

Правило 6 . Если степень бинарной связи M:N, то необходимо построить три отношения - по одному для каждой сущности и одно отношение для связи. При этом ключ каждой сущности является первичным ключом соответствующего отношения, и входит в составной первичный ключ отношения для связи.

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

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

Поддержка целостности в реляционной модели данных в ее классическом понимании включает в себя 3 аспекта.

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

<имя атрибута>IS NULL и <имя атрибута> IS NOT NULL.

Если в данном кортеже (в данной строке) указанный атрибут имеет неопределенное значение, то предикат IS NULL принимает значение TRUE (Истина), а предикат IS NOT NULL - FALSE(Ложь), в противном случае предикат IS NULL принимает значение FALSE, а предикат IS NOT NULL принимает значение TRUE. Ведение Null значений вызвало необходимость модификации классической двузначной логики и превращения ее в трехзначную. Все логические операции, производимые с неопределенными значениями, подчиняются этой логике в соответствии с заданной таблицей истинности.

Таблица 8.1.Таблица истинности для логических операций с неопределенными значениями

А	В	Not A	A & B	А v B
TRUE	TRUE	FALSE	TRUE	TRUE
TRUE	FALSE	FALSE	FALSE	TRUE
TRUE	Null	FALSE	Null	TRUE
FALSE	TRUE	TRUE	FALSE	TRUE
FALSE	FALSE	TRUE	FALSE	FALSE
FALSE	Null	TRUE	FALSE	Null
Null	TRUE	Null	Null	TRUE
Null	FALSE	Null	FALSE	Null
Null	Null	Null	Null	Null

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

Логическое выражение > IS {TRUE | FALSE | UNKNOWN}

18. Принципы поддержки целостности в реляционных моделях данных. Языковая целостность. Ссылочная целостность. (продолжение 17 вопроса)

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

В-третьих , это поддержка ссылочной целостности (Declarative Referential Integrity, DRI), означает обеспечение одного из заданных принципов взаимосвязи между экземплярами кортежей взаимосвязанных отношений:

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

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

19. Семантическая поддержка целостности. Виды декларативных ограничений целостности

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

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

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

Выделяются следующие виды декларативных ограничений целостности:

§ Ограничения целостности атрибута: значение по умолчанию, задание обязательности или необязательности значений (Null), задание условий на значения атрибутов.

§ Ограничения целостности, задаваемые на уровне доменов, при поддержке доменной структуры.

§ Ограничения целостности, задаваемые на уровне отношения. Некоторые семантические правила невозможно преобразовать в выражения, которые будут применимы только к одному столбцу.

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

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

20. Транзакции. Триггеры и хранимые процедуры.

Транзакция - это последовательность операторов манипулирования данными, выполняющаяся как единое целое (все или ничего) и переводящая базу данных из одного целостного состояния в другое целостное состояние.

Транзакция обладает четырьмя важными свойствами, известными как свойства А СИД:

(А) Атомарность. Транзакция выполняется как атомарная операция - либо выполняется вся транзакция целиком, либо она целиком не выполняется.

(С) Согласованность. Транзакция переводит базу данных из одного согласованного (целостного) состояния в другое согласованное (целостное) состояние. Внутри транзакции согласованность базы данных может нарушаться.

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

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

Набор примитивов

- BEGIN_TRANSACTION ; границы

- END_TRANSACTION ; транзакции

- ABORT_TRANSACTION;

- WRITE.

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

Подана команда BEGIN TRANSACTION;

Подана команда ABORT_TRANSACTION (откатить транзакцию);

Произошло отсоединение пользователя от СУБД;

Произошел сбой системы.

Триггер - это отдельная хранимая в БД подпрограмма, связанная с таблицей или представлением, которая автоматически включается, когда в таблицу или представление вставляется (триггер добавления), модифицируется (триггер модификации) или удаляется (триггер удаления) строка.

Триггеры позволяют:

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

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

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

Автоматически уведомлять об изменениях в БД, используя события, создаваемые триггерами.

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

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

SQL для триггеров и хранимых процедур содержит множество операторов императивного программирования:

Конкатенацию строк,

Арифметические операции,

Операции сравнения,

Логические (not, and, or),

Операторы структурного программирования (IF, FOR, WHILE),

Объявление переменных (DECLARE),

Эти операторы используются совместно с операторами декларативного программирования INSERT, UPDATE, DELETE и SELECT.

В современных СУБД код хранимых процедур и триггеров может писаться на смеси диалектов SQL и языков высокого уровня, например, в Oracle – на PL/SQL или Java. Фактически запросы, написанные на декларативном языке, вкладываются в процедуры, написанные на императивном языке

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

Элементы реляционной модели

Таблица 19.1

Элементы реляционной модели

Важнейшим является понятие отношения, которое представляет собой двумерную таблицу, содержащую некоторые данные.

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

Атрибуты представляют собой свойства, характеризующие сущность.

Математически отношение можно описать следующим образом. Пусть даны n множеств D1, D2, D3, ... Dn, тогда отношение R есть множество упорядоченных кортежей ,гдеdk ∈ Dk, a D1, D2, D3,... Dn - домены отношения R.

На рис. 19.2 приведен пример представления отношения СОТРУДНИК.

Множество всех значений каждого атрибута отношения образует домен. Отношение СОТРУДНИК включает 4 домена. Домен 1 содержит фамилии всех сотрудников,домен 2 - номера всех отделов фирмы,домен 3 - название всех должностей,домен 4 - даты рождения всех сотрудников. Каждый домен образует значения одного типа, например, числовые или символьные.

Схема отношения представляет собой список имен атрибутов. Например, для приведенного примера схема отношения имеет вид СОТРУДНИК(ФИО, Отдел, Должность, Д_Рождения).

Рис. 19.2. Представление отношения СОТРУДНИК

Ключом отношения, илипервичным ключом, называется атрибут отношения, однозначно идентифицирующий каждый из его кортежей. Например, в отношении СОТРУДНИК(ФИО, Отдел, Должность, Д_Рождения) ключевым является атрибут ФИО.Ключ может бытьсоставным, т.е. состоять из нескольких атрибутов.

Существует также понятие внешнего ключа. С помощью внешних ключей устанавливаются связи между отношениями. Например, имеются два отношения СТУДЕНТ (ФИО. Группа, Специальность) и ПРЕДМЕТ(Назв.Пр. Часы), которые связаны отношением СТУДЕНТ_ПРЕДМЕТ(ФИО. Назв.Пр. Оценка) (рис. 19.3). В связующем отношении атрибуты ФИО и Назв.пр образуют составной ключ. Эти атрибуты представляют собойвнешние ключи, являющиеся первичными ключами других отношений.

Рис. 19.3. Связь отношений

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

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

Ограничения и операции над отношениями

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

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

В таблице не должно быть столбцов с повторяющимися именами.

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

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

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

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

Основной единицей обработки данных в реляционных БД является отношение, а не отдельные его кортежи (записи), как это принято в традиционных языках программирования.

Операции, выполняемые над отношениями, можно разделить на две группы.

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

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

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

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

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

Языки реляционного исчисления являются непроцедурными. Запрос к БД, выполненный с использованием подобного языка, содержит лишь информацию о желаемом результате. Для этих языков характерно наличие наборов правил для записи запросов. В частности, к языкам этой группы относится SQL.

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