Модели данных. Объектно-ориентированная.

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

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

Жизненный цикл БД.

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

1. Исследование и анализ проблемы, для решения которой создаётся база данных.

2. Построение Инфологической и Даталогической модели.

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

4. Проверка целостности БД

5. Выбор физического способа хранения и эксплуатации (тех. средства) базы данных.

6. Проектирование входных и выходных форм.

7. Разработка интерфейса приложения.

8. Функциональное наполнение приложения

9. Отладка: проверка на корректность работы функционального наполнения системы

10. Тестирование: тест на корректность ввода вывода данных, тест на максимальное количество активных сессий и т. д.

11. Ввод в эксплуатацию: отладка ИТ-инфраструктуры, обучение пользователей и ИТ-персонала.

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

13. Вывод из эксплуатации: перенос данных в новую СУБД.

Кратко основные этапы жизненного цикла базы данных:

1. проектирование БД

2. проектирование приложений

3. реализация БД

4. разработка специальных средств администрирования БД

5. эксплуатация

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

Проектирование БД.

• Системный анализ и словесное описание информационных объектов предметной области.

• Концептуальное проектирование

• Даталогическое или логическое проектирование

• Физическое проектирование.

Концептуальное проектирование - сбор, анализ и редактирование требований к данным.

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

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

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

Модель «сущность - связь».

Модель «сущность-связь» является концептуальной моделью, т.е. не учитывает особенности конкретной СУБД. Из модели "сущность-связь" могут быть получены все основные фактографические модели данных (иерархическая, сетевая, реляционная, объектно-ориентированная). Модели "сущность-связь" удобны тем, что процесс создания модели является итерационным. Разработав первый приближенный вариант модели, можно уточнять ее, опрашивая экспертов предметной области. При этом документацией, в которой фиксируются результаты бесед, является сама модель "сущность-связь".

Этапы нормализации.

Первая нормальная форма.

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

Вторая нормальная форма

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

Третья нормальная форма

Согласно определению Кодда, таблица находится в 3НФ тогда и только тогда, когда выполняются следующие условия:

• Отношение R (таблица) находится во второй нормальной форме;

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

Четвёртая нормальная форма

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

Пятая нормальная форма

Таблица находится в 5NF, если она находится в 4NF и любая многозначная зависимость соединения в ней является тривиальной. Пятая нормальная форма в большей степени является теоретическим исследованием и практически не применяется при реальном проектировании баз данных. Это связано со сложностью определения самого наличия зависимостей «проекции — соединения», поскольку утверждение о наличии такой зависимости должно быть сделано для всех возможных состояний БД.