МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ

Централизованное управление на всех этапах существования БД реализует администратор БД со своей группой специалистов, осуществляя эффективную взаимосвязь со всеми группами, участвующими в использовании, эксплуатации и обеспечении БД.

Рис.1

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

1. По способу хранения информации:

· интегрированные;

· распределенные.

2. По типу пользователя:

· монопользовательские;

· многопользовательские.

3. По характеру использования данных:

· прикладные;

· предметные.

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

Для работы с БД используется специальный обобщенный инструментарий в виде СУБД (МБД), предназначенный для управления БД и обеспечения интерфейса пользователя.

Основные стандарты СУБД:

· независимость данных на концептуальном, логическом, физическом уровнях;

· универсальность (по отношению к концептуальному и логическому уровню, типу ЭВМ);

· совместимость, неизбыточность;

· безопасность и целостность данных;

· актуальность и управляемость.

Существует два основных направления реализации СУБД: программное и аппаратное. Программная реализация (в дальнейшем СУБД) представляет собой набор программных модулей, работает под управлением конкретной ОС и выполняет следующие функции:

· описание данных на концептуальном и логическом уровнях;

· загрузку данных;

· хранение данных;

· поиск и ответ на запрос (транзакцию);

· внесение изменений;

· обеспечение безопасности и целостности.

Обеспечивает пользователя следующими языковыми средствами:

· язык описания данных (ЯОД);

· язык манипулирования данными (ЯМД);

· прикладной (встроенный язык данных (ПЯД, ВЯД).

Аппаратная реализация предусматривает использование так называемых машин баз данных (МБД). Их появление вызвано возросшими объемами информации и требованиями к скорости доступа. Слово “машина” в термине МБД означает вспомогательный периферийный процессор. Термин “компьютер БД” - автономный процессор баз данных или процессор, поддерживающий СУБД. Основные направления МБД:

· параллельная обработка;

· распределенная логика;

· ассоциативные ЗУ;

· конвейерные ЗУ;

· фильтры данных и др.

Использование при обработке информации технологии БД требует централизованного управления на каждом этапе их жизненного цикла (рис.2).

 

Рис.2

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

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

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

Другим важным аспектом проектирования БД является проблема интеграции и распределения данных. Господствовавшая до недавнего времени концепция интеграции данных при резком увеличении их объема, оказалась несостоятельной. Этот факт, а также увеличение объемов памяти внешних запоминающих устройств при ее удешевлении, широкое внедрение сетей передачи данных способствовало внедрению распределенных БД. Распределение данных может осуществляться различными способами:

1. Копируемые данные. Одинаковые копии данных хранятся в различных местах использования, так как это дешевле передачи данных. Модификация данных контролируется централизованно.

2. Подмножество данных. Группы данных, совместимые с исходной базой данных хранятся отдельно для местной обработкой.

3. Реорганизованные данные. Данные в системе интегрируются при передаче на более высокий уровень.

4. Секционированные данные. На различных объектах используются одинаковые структуры, но хранятся разные данные.

5. Данные с отдельной подсхемой. На различных объектах используются различные структуры данных, объединяемые в интегрированную систему.

6. Несовместимые данные. Независимые базы данных, спроектированные без координации, требующие объединения.

Важное значение на процесс создания БД оказывает внутреннее содержание информации. Существует два направления:

· прикладные БД, ориентированные на конкретные приложения, например, может быть создана БД для учета и контроля поступления материалов;

· предметные БД, ориентированные на конкретный класс данных, например, предметная БД “Материалы”, которая может быть использована для различных приложений.

В теории БД методология проектирования рассматривается как совокупность человеко-машинных инструментов и средств, применяемых для последовательной разработки проекта структуры баз данных. Целью методологии проектирования является:

· создание БД, соответствующей целям пользователей (т.е. высокоэффективная и адаптируемая к возникающим нуждам обработки, обладающая свойствами целостности, безопасности и т.д.);

· наличие свойств гибкости и общности, обеспечивающими доступность разработчикам с различным опытом проектирования, использующим различные модели данных и СУБД;

· обеспечение воспроизводимости, т.е. получение одинаковых или примерно одинаковых результатов различными разработчиками.

Для достижения указанных целей методология проектирования БД должна включать следующие компоненты:

1. Процесс проектирования, состоящий из серии этапов, на каждом из которых осуществляется выбор из нескольких альтернативных решений.

2. Методики выполнения требуемых в процессе проектирования расчетов и моделирования, критерии оценки альтернативных решений на каждом этапе.

3. Информационные требования в качестве исходных данных на каждом этапе и для всего процесса проектирования в целом.

4. Средства описания исходных данных и результатов выполнения каждого этапа проектирования.

Рассмотрим каждый компонент более подробно.

Процесс проектирования является длительным и трудоемким и обычно длится несколько месяцев, а в некоторых случаях и лет. Основными ресурсами проектировщика БД являются его собственная интуиция и опыт, поэтому качество решения во многих случаях остается низким. В этих условиях важное значение приобретают вопросы автоматизации разработки.

Основными причинами низкой эффективности проектируемых БД являются:

· недостаточно глубокий анализ требований к данным, включая их семантику и взаимосвязь;

· большая длительность процесса структурирования, делающая этот процесс утомительным и трудно выполняемым при ручной обработке;

· трудности, связанные с учетом производительности проектируемой системы и ресурсных ограничений используемых технических средств.

На рис.3 представлена совокупность процедур проектирования централизованной БД, которые можно объединить в четыре этапа. На этапе формулирования и анализа требований устанавливаются цели организации, определяются требования к БД. Эти требования документируются в форме доступной конечному пользователю и проектировщику БД. Обычно при этом используется методика интервьюирования персонала различных уровней управления.

 

 

Рис.3

 

Рис. 3

 

Этап концептуального проектирования заключается в описании и синтезе информационных требований пользователей в первоначальный проект БД. Результатом этого этапа является высокоуровневое представление информационных требований пользователей на основе различных подходов.

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

На этапе физического проектирования решаются вопросы, связанные с производительностью системы, определяются структуры хранения данных и методы доступа.

Весь процесс проектирования БД характеризуется как итеративный, при этом каждый этап рассматривается как совокупность итеративных процедур, в результате выполнения которых получают соответствующую модель.

Взаимодействие между этапами проектирования и словарной системой необходимо рассматривать отдельно. Процедуры проектирования могут использоваться независимо в случае отсутствия словарной системы. Сама словарная система может рассматриваться как элемент автоматизации проектирования.

Основные этапы последовательности проектирования распределенной БД показаны на рис.4, при этом этапы 1, 2, 3, и 6 подобны этапам 1-4 при проектировании централизованной БД. Предполагается, что распределенная СУБД (СУРБД) позволяет осуществить определение всей структуры БД, ее расчленение и размещение.