4. Логическая структура субд.

5. Трёхуровневая архитектура бд.

В соот со стандартом ANSI–SPARC ис БД следует рассм–ть как единую, но 3х уровневую структуру сост–ую из след эл–ов:

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

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

3) уровень представлений(внешний) служит для представления данных БД и результатов обработки данных БД на внешних устройствах (дисплеях, принтерах, плоттерах) => внешний уровень– интерфейсная часть БД, клиентская часть бД, причем для удобства пользователя внешнее представление может отличаться от структуры внутреннего хранения

6. Жизненный цикл базы данных.

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

Часто встречаемые этапы

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

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

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

4. Проверка целостности БД (Целостность базы данных)

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

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

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

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

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

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

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

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

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

7. Архитектура субд, как комплекса программ.

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

1. Двузвенный

Классическая схема. На SQL большая большая нагрузка

2. трехзвенный

Среднее звено одновременно и клиент и сервер.