Методы логического проектирования

Общая схема логического проектирования баз данных

Из-за отсутствия установившейся терминологии точную границу между концептуальным и физическим проектированием баз данных провести достаточно трудно. Тем не менее принято считать, что на этапе концептуального проектирования данные рассматриваются без учета специфики используемой СУБД, а особенности физического хранения базы данных в памяти ЭВМ включаются в описание ее структуры на этапе физического проектирования. Этап между концептуальным и физическим проектированием, в результате выполнения которого получается СУБД, – ориентированная схема базы данных, называют логическим проектированием. Изменения, которые вносятся в структуру базы данных на этом этапе, определяются стремлением удовлетворить требованиям конкретной СУБД начиная с требований целостности и непротиворечивости проектируемой базы данных и кончая показателями эффективности функционирования при ее расширении и усложнении. Так как одновременно с проектированием базы данных проводится работа по составлению прикладных программ, то между разработчиками этих подсистем должно быть налажено постоянное взаимодействие. При этом проводится анализ программных спецификаций высокого уровня и разрабатывается руководство по проектированию программ с учетом предложенной структуры базы данных.

Исходные данные к логическому проектированию:

· СУБД-независимая схема. Основной результат фазы концептуального проектирования; исходная схема, которая в дальнейшем будет преобразовываться на фазе проектирования реализации.

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

· Количественная оценка объема и частоты выполнения приложений. Размер базы данных, который оценивается исходя из количества экземпляров данных и частоты выполнения приложений.

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

· Программные спецификации высокого уровня. Результаты анализа требований к программам.

· Характеристики СУБД. Правила задания СУБД-ориентированных логических схем и подсхем, а также синтаксиса программ.

· Вычислительные средства. Ограничения на конфигурацию и объем аппаратного и математического обеспечения.

Результаты логического проектирования:

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

§ Подсхемы. Структура СУБД-ориентированной базы данных, совместимая с представлениями отдельных пользователей и ограничениями безопасности.

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

§ Руководство по проектированию программ. Советы прикладным программистам по выбору путей доступа, основанные на анализе характеристик предложенной структуры данных.

§ Руководство для группы сопровождения базы данных. Краткие требования, ограничения и данные об имеющихся в наличии технических средствах и математическом обеспечении для администратора базы данных и обслуживающего персонала.

Процесс проектирования можно представить следующими шагами.

Анализ требований обработки

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

Задание исходных структур СУБД

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

Проектирование подсхемы

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

Проектирование прикладных программ

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

Оценка схемы

На данном шаге проектирования проводится количественная оценка логической БД. Определим понятие «объем обработки» как сочетание двух параметров: частота обработки и объем данных. Частота обработки — частота, с которой нужно проводить обработку отдельного приложения. Объем данных — количество хранимых в данный момент в базе данных экземпляров каждой таблицы. Рост базы данных проявляется через возрастание частоты обработки (иногда называемой частотой выполнения приложений) и увеличение объема данных.

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

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

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

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

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

· прагматический (ручной) подход;

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

· оптимизация связей;

· метод доказательства теорем.

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

Иногда более эффективным может оказаться разбиение атрибутов сущностей на некоторые группы, или наоборот, объединение атрибутов нескольких объектов в одну таблицу. Обычно создается матрица N · N, где N – количество элементов в информационной структуре, а элемент матрицы (i, j) соответствует частоте, с которой атрибуты i и j будут обрабатываться вместе. Большие частоты совместного использования указывают пары атрибутов, которые следовало бы поместить в один набор.

Дата добавления: 2014-01-07