Организация Баз Данных 4 страница

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

При объединении представлений используются три основополагающие концепции: идентичность, агрегация и обобщение.

Два или более элементов модели идентичны, если имеют одинаковое семантическое (смысловое) значение.

Агрегация позволяет рассматривать связь между элементами модели как новый элемент.

....

Рис. 2.19. Схема процесса объединения локальных представлений

Пример. Связь между сущностями СТУДЕНТ, ДИСЦИПЛИНА, ПРЕПОДВАТЕЛЬ, ОЦЕНКА, имеющая смысловое описание "Студент по фамилии ________________ получил на экзамене по дисциплине _______________

у преподавателя ______________ оценку _______________", может быть представлена агрегированным элементом ЭКЗАМЕН (рис. 2.20).

ЭКЗАМЕН

ФАМИЛИЯ-СТУДЕНТА

НАЗВАНИЕ-ДИСЦИПЛИНЫ ФАМИЛИЯ-ПРЕПОДАВАТЕЛЯ

КОД-ОЦЕНКИ

Рис. 2.20. Структура агрегированного элемента ЭЛЕМЕНТА

Эта связь представлена сущностью ЭКЗАМЕН с атрибутами ФАМИЛИЯ-СТУДЕНТА, НАЗВАНИЕ-ДИСЦИПЛИНЫ, ФАМИЛИЯ-ПРЕПОДАВАТЕЛЯ, КОД-ОЦЕНКИ.

При объединении представлений агрегация встречается в следующих трех формах.

1. В одном представлении агрегатный объект определен как единое целое, а во втором рассматриваются его составные части.

Например, в одном представлении определен только один объект - объект А (некоторое изделие), а в другом - объекты В1, В2, В3 (некоторые детали), являющиеся составными частями объекта А (но сам объект А не определен).

Если выполнить простое объединение, т.е. рассматривать четыре самостоятельных объекта (А, В1, В2, В3), то это будет означать, что в объединенное представление не включена информация о том, что объекты В1, В2, В3 - составные части объекта А. Чтобы включить эту информацию в модель объединенного представления, необходимо выполнить объединение с использованием агрегации, что повышает возможности совместного использования данных (рис. 2.21).

А

В1 В2 В3

Рис. 2.21. Пример объединения при помощи агрегации

2. Агрегатный объект как единое целое не определен ни в одном из представлений, но в обоих представлениях рассматриваются его различные составные части.

Например, в одном объекте определены объекты В1, В2, а в другом - объекты В3, В4, В5, являющиеся составными частями объекта А, который не назван ни в одном представлении, но о существовании которого знает проектировщик.

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

А

В1 В2 В3 В4 В5

Рис. 2.22. Пример внедрения агрегатного объекта

3. Один и тот же агрегатный объект рассматривается в обоих представлениях, но составляющие различаются.

Например, в одном представлении рассматривается агрегат, представленный на рис. 2.23а,а в другом - (на рис. 2.23б). При объединении представлений агрегаты объединяются (рис. 2.23в).

Пример: Объединению подлежат два представления (рис. 2.24, а, б). С использованием агрегации можно объединить эти представления (рис. 2.24, в).

А) А

В1 В2 В3 В4

Б)

А

В1 В2 В3 В4 В5

В)

А

В1 В2 В3 В4 В5 В6

Рис. 2.23. Примеры рассматриваемых агрегатов (А, Б) и результат их объединения (В)

Обобщением называется абстракция данных, позволяющая трактовать класс различных подобных типов объектов как один поименованный обобщенный тип объекта. В обобщении подчеркивается общая природа объекта.

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

Возвращаясь к предыдущему примеру (рис. 2.24), процесс объединения обоих представлений следует продолжить, используя обобщение, поскольку сущности СТУЛ, СТОЛ, ШКАФ, ПОЛКА представляют собой различные категории типов, отражающих смысловое содержание некоторого обобщенного понятия - "компонент гарнитура". Присвоим этому обобщенному понятию наименование КОМПОНЕНТ и введем его в модель представления, используя конструктивный элемент "сущность". Чтобы представить в модели информацию о категориях, добавим к сущности КОМПОНЕНТ описательный атрибут НАИМЕНОВАНИЕ, который будет принимать значения из множества: {СТУЛ, СТОЛ, ШКАФ,

А)

Б)

В)

Рис. 2.24. Пример объединения локальных представлений с использованием агрегации.

ПОЛКА}. Значения этого множества соответствуют категориям, на которые разбивается введенное обобщение.

Таким образом, окончательный вид объединенного представления показан на рис. 2.25.

Рис. 2.25. Пример использования обобщения

Рассмотрим еще один пример.

Пример. В объединяемых исходных представлениях присутствуют следующие сущности: ДЕТАЛИ-СОБСТВЕННОГО-ПРОИЗВОДСТВА, ДЕТАЛИ-ПОКУПНЫЕ, СБОРОЧНЫЕ-ЕДЕНИЦЫ-ПОКУПНЫЕ, СБОРОЧНЫЕ-ЕДЕНИЦЫ-СОБСТВЕННОГО-ПРОИЗ-ВОДСТВА.

В объединенном представлении можно использовать обобщения, приведенные на рис. 2.26.

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

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

Рис. 2.26. Пример использования обобщений

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

Часть противоречий вызвана обычно некорректностью требований, неполнотой спецификаций, наличием возможных ошибок. Например, в результате объединения представлений выявились несогласованные ассоциации, которые по приведенным спецификациям следует считать идентичными, но характеристики этих ассоциаций различны (рис. 2.27,а). В результате анализа причин данного противоречия выяснено, например, что в одном локальном представлении под сущностью ПОЗИЦИЯ понималась позиция игрока в конкретной игре, поэтому используемая ассоциация типа "1", а в другом - все возможные игровые позиции для игрока (ассоциация типа "М"). Следовательно данное противоречие вызвано наличием омонимов и его можно устранить (рис. 2.27,б). Чтобы устранить последствия этого противоречия, необходимо возвратиться к тому месту процесса объединения, где рассматриваемые конструктивные элементы включались в проектирование, и выполнить все последующие соответствующие коррекции.

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

А)

М

Б)

Рис. 2.27. Пример устранения выявленных противоречий

рассматриваемые конструктивные элементы, и выполнить все последующие необходимые коррекции.

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

Ниже приведен вариант возможного оформления спецификаций для примера, представленного на рис. 2.11:

Типы сущностей: ПОСТАВЩИК, ПОСТАВКА, ТОВАР.

ПОСТАВЩИК: идентифицирующий атрибут ИНДЕКС-ПОСТАВЩИКА,

описательный атрибут - АДРЕС-ПОСТАВЩИКА.

ПОСТАВКА: идентифицирующий атрибут ИНДЕКС-ПОСТАВКИ, описательные

атрибуты - КОЛИЧЕСТВО-ПОСТАВЛЕННОГО-ТОВАРА, ШИФР-СКЛАДА, ДАТА-ПОСТАВКИ.

ТОВАР: идентифицирующий атрибут ИНДЕКС-ТОВАРА, описательные

атрибуты - НАЗВАНИЕ-ТОВАРА, ЦЕНА-ЕДИНИЦЫ-ТОВАРА.

Типы связей: ПОСТАВЛЯЕТ, МОЖЕТ-ПОСТАВЛЯТЬ, МОЖЕТ-БЫТЬ-ПОСТАВЛЕН,ПОСТАВЛЕН.

ПОСТАВЛЕН: отображение 1:М от ПОСТАВЩИК к ПОСТАВКА.

МОЖЕТ-ПОСТАВЛЯТЬ: многозначная однонаправленная связь от ПОСТАВЩИК к ТОВАР. и т.д.

Спецификация атрибутов:

ИНДЕКС-ПОСТАВКИ: алфавитно-цифровой, 6 символов

АДРЕС-ПОСТАВЩИКА: алфавитно-цифровой, 80 символов

и т.д.

ЦЕНА-ЕДИНИЦЫ-ТОВАРА: числовой от 00000.00 до 9999.99.

Спецификация связей атрибут-атрибут:

ИНДЕКС-ПОСТАВЩИКА -> АДРЕС-ПОСТАВЩИКА

ИНДЕКС-ТОВАРА -> НАЗВАНИЕ-ТОВАРА

ИНДЕКС-ТОВАРА -> ЦЕНА-ЕДИНИЦЫ-ТОВАРА

ИНДЕКС-ПОСТАВКИ -> КОЛИЧЕСТВО-ПОСТАВЛЕННОГО-ТОВАРА

ИНДЕКС-ПОСТАВКИ -> ШИФР-СКЛАДА

ИНДЕКС-ПОСТАВКИ -> ДАТА-ПОСТАВКИ

ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

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

Практически используются базы данных, имеющие одну из трех логических моделей: реляционную, сетевую или древовидную.

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

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

Процесс проектирования каждой из трех (реляционной, сетевой, древовидной) моделей имеет свои особенности и характерные приемы. Общим можно считать лишь перечень основных действий, выполняемых проектировщиком, а именно:

- отображение исходной концептуальной инфологической модели на конкретную логическую модель;

- преобразование модели с учетом ограничений конкретной СУБД;

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

Такая модель является основой для физического проектирования и реализации базы данных.

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

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

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

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

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

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

Для реляционной модели - это совместное (в одном отношении) представление ключей взаимосвязанных записей.

Для сетевой модели - указатели связей.

Для древовидной модели - это физически смежное размещение экземпляров взаимосвязанных записей на физических носителях по левосписковому принципу.

Пример: концептуальная инфологическая модель БД "Эксперимент".

	Справочник испытаний		Паспорт двигателя		Справочник параметров

Рис. А. Инфологическая модель базы данных «Эксперимент»

Справочник испытаний

Номер испытания

Наименование испытания

Статус испытания

Паспорт двигателя

Номер двигателя

Дата Изготовления

Место Изготовления

Наработка двигателя

Справочник параметров

Наименование параметра

Размерность параметра

План испытаний

Номер двигателя

Номер испытания

Шифр методики испытания

Состав двигателя

Номер двигателя

Номер узла

Номер разрешающего документа

Наработка узла в составе двигателя

Параметры двигателя

Номер двигателя

Наименование параметра

Действующая величина Параметра

Изделие

Номер изделия

Обозначение Изделия

Наименование изделия

Доводка изделия

Номер изделия

Наименование Дефекта

Шифр отчета по дефекту

Рис. 1

Основные данные о предметной области:

- состав задач, решаемых пользователем, приведен в таблице 1;

- состав объектов предметной области, действий между ними или над объектами, функций управления и функциональных областей приведен в таб. 2.

Таблица 1.

Справочник задач

Задача	Наименование задач	Цель решения задачи
	Планирование испытаний двигателей и узлов	Разработка ежедневного графика поведения испытаний узлов конкретных двигателей
	Анализ изменения параметров двигателей	Сбор статистики и анализ зависимости значений параметров двигателя от наработки согласно плану испытаний
	Учет доводки изделий	Учет наличия и устранения дефектов по изделиям
	Расчет значений параметров двигателя	Расчет параметров двигателя по значениям параметров составляющих его узлов

Таблица 2.

Состав функциональных областей

Объект, действие	Функция управления	Функциональная зависимость
Двигатель Узел Испытание	Планирование	Планирование испытаний двигателей Планирование испытаний Узлов
Изделие Дефект Параметр Двигатель Узел	Учет	Учет дефектов изделий Учет параметров узлов Учет параметров двигателей
Двигатель Параметр Испытание	Анализ	Анализ динамики параметров Двигателей по испытаниям

Еще раз обратимся к примеру проектирования базы данных "Эксперимент". Концептуальная инфологическая модель этой базы приведена на рис. А. Данные о частоте решения задач и используемых при этом сущностях приведены в таб. 1.1. Данные получены при обследовании предметной области.

Таблица 1.1. – Справочник задач пользователя

Номер Задачи	Сущности, используемые при решении задачи	Частота решения задачи
	Справочник испытаний План испытаний Состав двигателя	Ежедневно (300 раз в год)
	Паспорт двигателя План испытаний Параметры двигателя	Раз в неделю (48 раз в году)
	Изделие Доводка изделия	Ежедневно
	Справочник параметров Параметры двигателя Состав двигателя	Ежедневно

Проектирование реляционной логической модели

базы данных.

1.1. Общие положения

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

Для получения такой модели необходимо:

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

2) сделать отображение полученной на предыдущем этапе модели на реляционную модель путем совместного представления в ее отношениях ключевых элементов взаимосвязанных записей;

3) выполнить анализ полученных отношений с точки зрения соответствия их требованиям четвертой нормальной формы(IVНФ);

4) преобразовать полученные отношения с учетом требований конкретной системы управления базой данных (СУБД).

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

1.2. Установление дополнительных логических связей

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