- •Введение
- •Глава 1. Проектирование баз данных
- •1.1. История развития баз данных и субд
- •1.2. Введение в субд
- •1.2.1. Основные термины, понятия и определения
- •1.2.2. Классификация субд
- •1) Сетевые, корпоративные, распределенные, клиент-серверные, полнофункциональные, масштабируемые, “большие” субд.
- •2) Локальные, персональные, настольные, файл-серверные, “малые” субд.
- •1.3. Модели данных
- •1.3.1. Типы связей между объектами
- •1.3.2. Формы записи инфологической (концептуальной) модели
- •1.3.3. Уровни представления и независимости данных
- •1.3.4. Порядок взаимодействия пользователя, субд и ос
- •1.3.5. Поддержка целостности базы данных
- •1.3.6. Иерархическая модель
- •1.3.7. Сетевая модель
- •1.3.8. Реляционная модель
- •1.3.8.1. Отношения
- •1.3.8.2. Теоретико-множественные операции с отношениями
- •1.3.8.3. Правила Кодда
- •1.3.8.4. Индексирование таблиц
- •1.3.8.5. Связывание таблиц
- •1.3.9. Постреляционная модель
- •1.3.10. Многомерная модель
- •1.3.11. Объектно‑ориентированная модель
- •1.4. Модели использования баз данных в сети
- •1.4.1. Сеть
- •1.4.2. Модели использования баз данных
- •1.4.2.1. Локальная однопользовательская модель
- •1.4.2.2. Файл-серверная модель
- •1.4.2.3. Клиент-серверная модель
- •В моделях «клиент–сервер»
- •1.4.2.4. Модель удаленного доступа (rda)
- •1.4.2.5. Модель сервера данных
- •1.4.2.6. Трехзвенная распределенная модель
- •1.4.2.7. Модели серверов баз данных
- •1.4.2.8. Клиент-Интернет
- •1.4.2.9. ИнтерфейсOdbc
- •1.4.3. Мониторы обработки транзакций (tpm)
- •1.4.4. Децентрализованное управление базами данных
- •1.4.5. Таблицы в локальных сетях
- •1.5. Проектирование баз данных
- •1.5.1. Принципы и этапы проектирования и создания баз данных
- •1.4.Определение доменов атрибутов.
- •1.5. Определение первичных и вторичных ключей.
- •1.6. Определение суперклассов и подклассов для типов сущностей.
- •1.7. Создание er‑диаграмм для отдельных пользователей.
- •2.6. Создание er‑диаграмм для отдельных пользователей.
- •3.4. Создание er‑диаграммы глобальной логической модели.
- •4. Создание глобальной логической модели в среде целевой субд.
- •6. Разработка механизма защиты.
- •1.5.3. Правила формирования взаимосвязанных таблиц
- •1.5.4. Модели жизненного цикла и проектирование баз данных
- •1.5.4.1. Модели жизненного цикла
- •1.5.4.2. Обследование, системный анализ и постановка задачи
- •1.5.4.3. Инфологическое проектирование
- •1.5.4.4. Датологическое проектирование
- •1.5.4.5. Проектирование физической модели
- •1.5.4.6. Реализация, интеграция и внедрение
- •1.5.5. Выбор субд
- •1.5.5.1. Сравнение Visual FoxPro, Access, sql Server, Oracle и Excel
- •1.5.5.2. Методика балловой оценки программных средств
- •1.5.6. Case‑средства автоматизации проектирования
- •1. Ориентация на этапы жизненного цикла
- •2. Функциональная полнота
- •Пользователя в ms sql Server 7.0
- •1.6.2. Резервирование информации
- •1.6.3. Варианты разработки приложений
- •1.7. Стандартизация баз данных
- •1.8. ЯзыкSql
- •1.8.1. Введение вSql
- •1.8.2. Типы данныхSql
- •1.8.3. Оператор выбора данныхSelect
- •1.8.3.1. Назначение и синтаксис оператора
- •1.8.3.2. Объединение таблиц
- •1.8.3.3. Вложенные и коррелированные запросы
- •1.8.3.4. Запросы, использующиеExist, any, all
- •1.8.3.5. Стандартные функции
- •1.8.3.6. Запрос с группировкой
- •1.8.4. Операторы обновления базы
- •1.8.4.1. Оператор корректировки данныхUpdate
- •1.8.4.2. Оператор удаления записейDelete
- •1.8.4.3. Оператор включения записей insert
- •1.8.5. Представления
- •1.9. Транзакции
- •1.9.1. Определение транзакций
- •1.9.2. Организация транзакций
- •1.9.3. Журнал транзакций
- •1.9.4. Журнализация и буферизация
- •1.9.5. Индивидуальный откат транзакций
- •1.9.6. Восстановление после мягкого сбоя
- •1.9.7. Физическая согласованность базы данных
- •1.9.8. Восстановление после жесткого сбоя
- •1.9.9. Параллельное выполнение транзакций
- •1.9.10. Уровни изолированности пользователей
- •1.9.11. Гранулированные синхронизационные захваты
- •1.9.12. Предикатные синхронизационные захваты
- •1.9.13. Метод временных меток
- •1.10. ВстроенныйSql
- •1.10.1. Особенности встроенногоSql
- •1.10.2. Определение курсора
- •1.10.3. Открытие курсора
- •1.10.4. Чтение очередной строки курсора
- •1.10.5. Закрытие курсора
- •1.10.6. Удаление и обновление данных
- •1.10.7. Хранимые процедуры
- •Хранимой процедуры на сервере
- •1.10.8. Триггеры
- •1.10.9. ДинамическийSql
- •1.11. Архитектура субд и оптимизация запросов
- •1.12. Перспективы развития субд
- •Вопросы для самопроверки и контроля
- •1Оглавление
1.5.4. Модели жизненного цикла и проектирование баз данных
1.5.4.1. Модели жизненного цикла
Жизненный цикл базы данных (ЖЦ БД)представляет собой непрерывный процесс с момента начала разработки базы данных до завершения её эксплуатации.
Модель ЖЦПО‑ структура, задающая последовательность выполнения и взаимосвязи процессов, задач и действий, выполняемых при создании базы данных.
Типы моделей
Каскадная модельпредполагает последовательное выполнение этапов: анализ (определение требований и анализ), проектирование, реализация, внедрение и сопровождение (модификация базы данных при изменении предметной области)*.
Достоинства:формирование на каждом этапе технической документации, возможность планирования сроков и затрат.Недостаток: отсутствие возможности пересмотра отдельных этапов.
Эволюционная модель. Разрабатывается первоначальная версия БД, которая затем сразу же передается на испытание пользователю, затем она дорабатывается с учетом мнения пользователя. Удобно применять, когда заказчик четко не может сформулировать свои требования или меняет их в процессе создания БД. Достоинство - спецификация может разрабатываться постепенно, по мере того, как заказчик осознает, что ему нужно. Недостатки – плохая документированность и структурируемость БД; перепроектирование БД. Используется при разработки небольших БД.
Пошаговая модель занимает промежуточное положение между каскадной и эволюционной моделями. В её рамках разработчик вначале определяет функции БД в самых общих чертах, устанавливают приоритеты и определяют количество этапов (очередей или версий). Каждый этап должен быть результирующим. Достоинства - заказчику не нужно ждать полного завершения разработки; заказчик может использовать компоненты системы, которые получены на первых шагах как прототипы; уменьшение риска общих системных ошибок; наиболее важные подсистемы подвергаются более тщательному тестированию и проверке. Недостатки - сложность отображения системных требований и компонентов больших размеров и распределения общих системных функций по компонентам
Спиральная модельустраняет недостатки предыдущих моделей. На каждом витке ее этапы могут уточняться или дополняться новыми работами (рисунок 1.5.4.1). Каждый виток дает уточненный работоспособный вариант базы данных, который можно предъявлять пользователю для оценки.
Анализ
Определение
Проектирование требований
1 2 3
Реализация Внедрение
и тестирование версий
Интеграция
Рисунок 1.5.4.1. Этапы спиральной модели ЖЦПО
1.5.4.2. Обследование, системный анализ и постановка задачи
Необходимо провести подробное словесное описание объектов предметной области и реальных связей, которые присутствуют между описываемыми объектами (содержание данного пункта скопировано из работы [19]). Желательно, чтобы данное описание позволяло корректно определить все взаимосвязи между объектами предметной области. В общем случае существуют два подхода к выбору состава и структуры предметной области:
Функциональный подход — он реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая БД. В этом случае мы можем четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.
Предметный подход — когда информационные потребности будущих пользователей БД жестко не фиксируются. Они могут быть многоаспектными и весьма динамичными. Мы не можем точно выделить минимальный набор объектов предметной области, которые необходимо описывать. В описание предметной области в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для нее. БД, конструируемая при этом, называется предметной, то есть она может быть использована при решении множества разнообразных, заранее не определенных задач. Конструирование предметной БД в некотором смысле кажется гораздо более заманчивым, однако трудность всеобщего охвата предметной области с невозможностью конкретизации потребностей пользователей может привести к избыточно сложной схеме БД, которая для конкретных задач будет неэффективной.
Чаще всего па практике рекомендуется использовать некоторый компромиссный вариант, который, с одной стороны, ориентирован на конкретные задачи или функциональные потребности пользователей, а с другой стороны, учитывает возможность наращивания новых приложений.
Анализ должен заканчиваться подробным описанием информации об объектах предметной области, которая требуется для решения конкретных задач и которая должна храниться в БД, формулировкой конкретных задач, которые будут решаться с использованием данной БД с кратким описанием алгоритмов их решения, описанием выходных документов, которые должны генерироваться в системе, описанием входных документов, которые служат основанием для заполнения данными БД.
При проектировании баз данных следует учитывать следующие общие требования: многократное использование данных; простота, легкость использования; гибкость; обработка незапланированных запросов; простота корректировки; небольшие затраты на эксплуатацию; минимальная избыточность; производительность; секретность; достоверность; защита от искажений и сбоев; состояние готовности; физическая и логическая независимость; требуемая скорость доступа и поиска; стандартизация данных; наличие словаря базы, интерфейса связи с программным комплексом и языка взаимодействия с конечным пользователем; контроль за целостностью данных в базе; восстановление и реорганизация данных в базе.
Организуется обследование предметной области: оценка объема и цели проекта, определение требований, объектов и функций на высоком уровне.
Сбор информации начинается с изучения существующих форм документов, отчетов, имеющихся файлов, баз данных, программ.
Исходная информация для анализа берется из индивидуальных бесед с заказчиками, на семинарах, при изучении документации, инструкций, анкетировании и др.
Примерное содержание исходной информации (анкет):
имя и описание объекта данных.Назначение и использование объекта в подразделениях;
элементы данных.Для каждого элементарного данного объекта указывается: его имя и описание, источник, формат (тип, диапазоны допустимых значений), использование, ограничения доступа, степень важности, взаимосвязи;
продолжительность хранения и условия перевода в архив.
Результаты фиксируются в документе типа технического задания (ТЗ), который содержит: назначение, требования, ограничения, возможности, бизнес‑процессы (функции), объем, смету затрат, сроки, показатели экономической эффективности, исполнители.
Производится исследование информационных потоков, документооборота (схемы движения данных от источника к пользователю), функций и информации для их выполнения (объектов, атрибутов и таблиц) без учета конкретных программных средств. Формулируются бизнес‑правила (факты, которым должна подчиняться система).
Проектирование –поиск способа удовлетворения функциональных потребностей пользователей средствами имеющихся технологий с учетом заданных ограничений.
Проектирование охватывает три области: таблицы, запросы, представления, хранимые процедуры и функции; формы, отчеты и программы; топологию сети, модели использования таблицы.
Формализация объектов и связей между ними, построение концептуальной модели, формирование набора таблиц с указанием первичных ключей для каждой таблицы, добавление неключевых атрибутов в таблицы, нормализация таблиц.
Изучаются существующие СУБД и выбирается нужная (п. 1.5.6).
Далее разрабатывается логическая и физическая модели БД в терминах выбранной СУБД.
Проектируются программы, хранимые процедуры, триггеры.
В целом можно выделить отдельные этапы инфологического (концептуального), даталогического (логического) и физического проектирования, которые буду рассмотрены ниже.