данных организации и ее бизнес - правил. Бизнес правила описывают основные характеристики данных с точки зрения организации. Например, «Любой сотрудник не может отвечать одновременно более чем за десять сдаваемых в аренду или продаваемых объектов недвижимости».
Для более эффективной работы разработчик логической БД должен как можно раньше вовлечь всех предполагаемых пользователей БД в процесс создания модели данных. Работа
разработчика логической БД делится на два этапа:
Концептуальное проектирование БД, которое совершенно не зависит от таких деталей ее воплощения, как конкретная целевая СУБД, приложения, языки программирования или любые другие физические характеристики.
Логическое проектирование БД, которое проводится с учетом особенностей выбранной модели данных: реляционной, сетевой, иерархической или объектноориентированной.
Разработчик физической БД получает готовую логическую модель данных, занимается ее физической реализацией, в том числе:
преобразование логической модели данных в набор таблиц и ограничений целостности данных;
выбором конкретных структур хранения и методов доступа к данным, обеспечивающих необходимый уровень производительности при работе с БД;
проектированием любых требуемых мер защиты
данных.
Многие этапы физического проектирования БД в значительной степени зависят от выбранной целевой СУБД.
Разработчик физической БД должен уметь выбрать наиболее подходящую стратегию хранения данных с учетом всех существующих особенностей их использования.
Сразу после создания БД следует приступить к разработке приложений. Эту работу выполняют прикладные программисты.
206
Пользователи являются клиентами БД – она проектируется, создается и поддерживается для того, чтобы обслуживать их информационные потребности. Пользователей можно классифицировать по способу использования ими системы.
Наивные пользователи – обычно даже не подозревают о наличии СУБД. Они пользуются разработанными приложениями.
Опытные пользователи – они знакомы со структурой БД и возможностями СУБД. Для выполнения требуемых им операций они могут использовать язык запросов (например,
SQL).
Обзор жизненного цикла информационных систем Информационная система – ресурсы, которые
позволяются выполнять сбор, корректировку и распространение информации внутри организации.
Начиная с 70-х годов системы БД стали постепенно заменять файловые системы. Параллельно с этим росло признание того факта, что данные являются важным корпоративным ресурсом, к которому нужно относиться так же уважительно, как и к другим ресурсам организации. Это привело к тому, что во многих организациях появились функциональные подразделения, занимавшиеся администрированием данных и администрированием БД. Они отвечали за обработку и управление корпоративными данными и корпоративными БД.
Типичная компьютеризированная информационная система включает такие компоненты, как:
o БД
o программное обеспечение БД
o прикладное программное обеспечение
o аппаратное обеспечение, в том числе устройства хранения
o персонал, использующий и разрабатывающий эту систему.
207
Жизненный цикл информационной системы обычно состоит из нескольких этапов: планирование, сбор и анализ требований, проектирование (включая проектирование БД), создание прототипа, реализация, тестирование, преобразование данных и сопровождение.
Нас будет интересовать жизненный цикл приложения БД. Этапы жизненного цикла приложения БД перечислены ниже. Эти этапы не являются строго последовательными, а включают некоторое количество повторов предыдущих шагов в виде циклов обратной связи.
Планирование разработки БД – планирование самого эффективного способа реализации этапов жизненного цикла системы.
Определение требований к системе – определение диапазона действия и границ приложения БД, состава его пользователей и областей применения.
Сбор и анализ требований пользователей – на этом этапе выполняется сбор и анализ требований пользователей из всех возможных областей применения.
Проектирование БД – полный цикл разработки включает концептуальное, логическое и физическое проектирование БД.
Выбор целевой СУБД
Разработка приложений – определение пользовательского интерфейса и прикладных программ, которые используют и обрабатывают базу данных.
Создание прототипов (необязательно) – создается рабочая модель приложения БД, которая позволяет разработчикам или пользователям представить и оценить окончательный вид и способы функционирования системы.
Реализация – создание внешнего, концептуального и внутреннего определений БД и прикладных программ.
Конвертирование и загрузка данных – преобразование и загрузка данных (и прикладных программ) из старой системы в новую.
208
Тестирование.
Эксплуатация и сопровождение – на этом этапе приложение БД считается полностью разработанным и реализованным.
Остановимся подробнее на этих этапах.
Планирование разработки БД – это подготовительные действия, позволяющие с максимально возможной эффективностью реализовать этапы жизненного цикла приложений баз данных.
Этот этап состоит из определения трех основных компонентов: требуемого объема работы, необходимых ресурсов и общей стоимости проекта. Планирование разработки БД должно быть связано с общей стратегией построения информационной системы организации. Суть этой стратегии заключается в решении таких основных задач, как:
определение бизнес-планов и целей организации с последующим выделением ее потребностей в информационных технологиях;
оценка показателей уже существующих информационных систем с целью выявления их сильных и слабых сторон;
оценка возможностей использования информационных технологий для достижения конкурентно способного преимущества.
Для поддержки планирования разработки БД может быть создана корпоративная модель данных, отображающая наиболее важные данные и связи между ними, а также их отношение к различным функциональным сферам организации. Благодаря этому можно будет понять, в каких случаях потребуется совместный доступ к данным. Обычно корпоративная модель данных имеет вид упрощенной ERдиаграммы.
Планирование разработки БД также должно включать разработку стандартов, которые определяют, как будет осуществляться сбор данных, каким будет их формат, какая
потребуется документация и как будет выполняться
209
проектирование и реализация приложений. Например, специальные правила могут определять, как присваиваются имена элементам данных, описываемых в словаре данных, что, в свою очередь, позволит предотвратить их избыточность и противоречивость. Кроме того, необходимо строго документировать любые требования к данным.
Этот этап может также предусматривать выбор наиболее подходящих инструментов автоматизированного проектирования и создания программ, которые принято называть CASE-инструментами. В самом широком смысле слова термин «CASE-инструмент» применим к любым средствам автоматизированного проектирования и создания программ. CASE-инструменты могут включать следующие компоненты:
-словарь данных, предназначенный для хранения информации о данных, используемых в создаваемом приложении;
-инструменты проектирования, обеспечивающие проведение анализа данных;
-инструменты разработки корпоративной модели данных, а также концептуальных и логических моделей данных;
-инструменты, позволяющие создавать прототипы приложений.
CASE-инструменты можно разбить на три категории: CASE-инструменты высокого уровня, CASE-инструменты низкого уровня и интегрированные CASE-инструменты. CASE-
инструменты высокого уровня применяются на начальных стадиях жизненного цикла разработки БД, а CASE-
инструменты низкого уровня – на более поздних, начиная со сдатии реализации, в ходе тестирования и на протяжении всего процесса сопровождения функционирующей системы.
Интегрированные CASE-инструменты применяются на всех стадиях жизненного цикла системы, а поэтому они должны поддерживать все функции CASE-инструментов как высокого, так и низкого уровней.
210