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