- •Установочный модуль
- •Введение
- •Модуль 1
- •Реляционная алгебра
- •Отсутствующие данные
- •Пустые значения
- •Неопределенные значения
- •Интерпретации
- •Правила вычисления выражений
- •Следствия
- •Проверка условий
- •Реляционные объекты данных
- •Формальные определения
- •Домены и атрибуты
- •Схема отношения
- •Именованное значение атрибута
- •Кортеж
- •Отношение
- •Схема базы данных
- •База данных
- •Операции реляционной алгебры
- •Унарные операции
- •Бинарные операции
- •Варианты операции соединения
- •Производные операции
- •Пример построения выражения реляционной алгебры
- •Понятие базовых и виртуальных отношений
- •Понятие полноты реляционной алгебры
- •Формирование запросов на языке SQL
- •Металингвистические символы
- •Реализация операций реляционной алгебры
- •Пример использования подзапросов
- •Группирующие запросы
- •Упорядочение результатов
- •Вопросы для самоконтроля
- •Упражнения
- •Построение выражений реляционной алгебры
- •Модуль 2
- •Базовые и виртуальные отношения
- •Типы данных
- •Базовые типы данных
- •Типы данных, определяемые пользователем
- •Первичные и кандидатные ключи
- •Создание базовых отношений
- •Индексы
- •Модификация базовых отношений
- •Вставка строк
- •Обновление строк
- •Удаление строк
- •Целостность
- •Декларативная поддержка
- •Пример декларативной поддержки целостности
- •Транзакции и блокировки
- •Триггеры
- •Виртуальные отношения
- •Вопросы для самоконтроля
- •Упражнения
- •Декларативная поддержка целостности
- •Модуль 3
- •Нормальные формы
- •Функциональные зависимости (ФЗ)
- •Правила вывода Армстронга
- •Производные правила вывода
- •Независимость правил Армстронга
- •Полнота системы правил Армстронга
- •Нормальные формы
- •Первая нормальная форма (1NF)
- •Вторая нормальная форма (2NF)
- •Третья нормальная форма (3NF)
- •Нормальная форма Бойса-Кодда (Boyce, Codd; NFBC)
- •Пример построения нормализованных схем отношений
- •Вопросы для самоконтроля
- •Модуль 4
- •Проектирование схем баз данных
- •Уровни логической модели
- •Миграция ключей и виды связей
- •Классификация кластеров
- •Иерархическая рекурсия
- •Абстрактная схема
- •Обобщения
- •Пример реализации иерархической рекурсии
- •Сетевая рекурсия
- •Абстрактная схема
- •Сетевая реализация иерархической рекурсии
- •Обобщения
- •Пример реализации сетевой рекурсии
- •Ассоциация
- •Детализация связей многие-ко-многим
- •Обобщения
- •Пример реализации ассоциации
- •Обобщение
- •Абстрактная схема
- •Пример реализации обобщения
- •Композиция
- •Абстрактная схема
- •Пример реализации композиции
- •Агрегация
- •Абстрактная схема
- •Пример реализации агрегации
- •Унификация атрибутов
- •Вопросы для самоконтроля
- •Упражнения
- •Иерархическая рекурсия
- •Сетевая рекурсия
- •Ассоциация
- •Обобщение
- •Композиция
- •Агрегация
- •Дополнительные главы
- •Технологии баз данных
- •Информационные системы
- •Жизненный цикл ИС
- •СУБД и БД
- •Жизненный цикл БД и средства проектирования
- •Модели данных
- •Иерархическая модель данных
- •Сетевая модель данных
- •Реляционная модель данных
- •Постреляционная модель данных
- •Объектно-ориентированные модели данных
- •XML как модель данных
- •Многомерная модель данных (OLAP)
- •Основные функции СУБД
- •Управление данными во внешней памяти
- •Управление буферами оперативной памяти
- •Управление транзакциями
- •Журнализация и восстановление БД после сбоев
- •Поддержка языков баз данных
- •Типовая организация СУБД
- •Модели взаимодействия с БД
- •Модель с централизованной архитектурой
- •Модель с автономными персональными компьютерами
- •Архитектура «файл-сервер»
- •Архитектура «клиент-сервер»
- •Архитектура «клиент-сервер» трехзвенная
- •Распределенные базы данных
- •Технология тиражирования данных
- •Понятие «фрактал»
- •Геометрические фракталы
- •Алгебраические фракталы
- •Стохастические фракталы
- •Системы итерируемых функций
- •Вопросы для самоконтроля
- •Литература
- •Список иллюстраций
- •Список таблиц
Основная проблема спирального цикла – определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования ИС, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всего проекта.
Главная особенность разработки современных ИС состоит в концентрации усилий на двух начальных этапах ее жизненного цикла - анализе и проектировании, при относительно невысокой сложности и трудозатратах на последующих этапах.
6.1.2. СУБД и БД
Основные потребности, которые при создании информационных систем не покрываются возможностями обычных систем управления файлами – это
1)поддержка логической согласованности данных,
2)поддержка языка манипулирования данными,
3)восстановление данных после различного рода сбоев,
4)обеспечение параллельной работы пользователей.
Если информационная система опирается на некоторую систему управления данными, обладающую этими свойствами, то эта система управления данными является системой управления базами данных (СУБД).
Базы данных (БД) – это наборы данных, находящиеся под контролем СУБД. Они представляют собой совокупность описаний объектов конкретной предметной области и связей между ними.
СУБД относятся к категории наиболее сложных программных продуктов, имеющихся в настоящее время. Они
позволяют пользователям создавать новые базы данных и определять их схемы, то есть описывать логические структуры данных;
позволяют модифицировать хранящиеся данные и извлекать данные в том или ином аспекте с помощью так называемых запросов;
управляют единовременным доступом к данным со стороны многих пользователей.
6.1.3. Жизненный цикл БД и средства проектирования
Средства автоматизированного проектирования концептуальной модели привлекают к себе в настоящее время большой интерес и используются в процессе создания структуры базы данных и интерфейса пользователя для доступа к данным.
Причина применения этих средств состоит в использовании в подавляющем большинстве реальных разработок баз данных спиральной модели жизненного цикла программного обеспечения. Использование спиральной модели предусматривает последовательное создание нескольких версий программного обеспечения. Каждая следующая версия включает в себя предыдущую (возможно не полностью) и является ответом на замечания пользователя, полученные в результате тестирования предыдущей версии.
Альтернативным способом является каскадная схема разработки программного обеспечения. Каскадный подход хорошо подходит для тех задач, для которых в самом начале разработки можно
достаточно полно и точно сформулировать все требования заказчика. В случае построения баз данных каскадный подход является неприемлемым.
При создании баз данных первая версия программного обеспечения, к сожалению, очень редко является удачной. Чаще всего, заказчик отвергает первую версию, так как она недостаточно полно отвечает его требованиям. Причина такой ситуации заключается в том, что заказчик не может сразу, до создания начальной версии программы, четко и полно сформулировать свои требования. Обычно после получения первого варианта программного обеспечения, заказчик выдвигает дополнительные требования, которые нельзя реализовать в рамках созданной базы данных.
Это вынуждает разработчиков вносить изменения в структуру базы данных, а также, соответственно, в интерфейс пользователя для доступа к базе данных. Таких итераций может быть несколько до момента получения решения, адекватного запросам заказчика. Но даже после получения удовлетворительного решения, процесс разработки базы данных не завершается. Жизнь не стоит на месте, и запросы заказчика меняются с течением времени. Часть этих изменений можно реализовать без изменения структуры базы данных, изменяя только интерфейс пользователя, другие же требуют изменения и интерфейса и структуры базы данных. Подобные изменения являются очень болезненными – работа по внесению изменений может оказаться трудоемкой и, что самое неприятное, может потребовать замены большого количества отлаженного программного кода. Иными словами, замененный код был написан впустую, на самом деле его не нужно было писать.
Таким образом, создание работоспособной базы данных можно условно разделить на три этапа
– проектирование базы данных, в процессе которого создаются рабочие прототипы, кодирование – создание структур баз данных и законченного интерфейса пользователя и сопровождение готовой базы данных.
Основная идея применения средств автоматизированного проектирования баз данных заключается в том, что процесс ручного кодирования начинается только после окончания процесса проектирования. На стадии проектирования схема базы данных и интерфейс пользователя для доступа к базе
данных создается автоматически, исходя из описания концептуальной модели, с помощью так называемых CASE средств (Computer Aided Software/System Engineering). Конечно, созданный таким образом интерфейс не является законченным программным продуктом, однако он позволяет заказчику оценить возможности, которые будут в конечном продукте и внести свои коррективы. Только после одобрения заказчиком рабочего прототипа, разработчики приступают к ручному кодированию
–созданию законченного приложения.
При сопровождении все повторяется, за тем исключением, что генерируется не все приложение
целиком, а только часть, которую надо изменять.
На практике, чаще всего, CASE-средства используются для создания схемы базы данных в виде диаграмм «сущность-связь» и генерации структур баз данных для конкретной СУБД. После получения от заказчика изменений, разработчики вносят соответствующие исправления в диаграмму «сущность-связь» и заново генерируют структуры баз данных. Средства автоматической генерации интерфейсов используются реже.
В настоящее время практически каждый производитель СУБД предлагает собственное программный продукт автоматизированного проектирования. Это Oracle Designer (Oracle), Power Designer (Sybase) и другие. Демонстрационные версии данных программных продуктов можно загрузить с соответствующих сайтов (www.oracle.com, www.sybase.com). Кроме того, на рынке представлены решения третьих фирм, не производящих СУБД. Одними из самых распространенных являются программные продукты фирмы AllFusion – AllFusion ERwin Data Modeler (ранее ERwin) и AllFusion Process Modeler (ранее BPwin) и другие. На российском рынке данные программы предлагает фирма Interface Ltd. (www.interface.ru). Программа AllFusion Process Modeler предназначена для моделирования бизнес-процессов. Результатами ее работы могут быть не только диаграммы, но и сгенерированный для различных сред код для доступа к базам данных. Для этого, однако, необходимо еще создать диаграммы «сущность-связь» с помощью AllFusion ERwin Data Modeler.
AllFusion ERwin Data Modeler позволяет проектировать, документировать и сопровождать базы