Физическая структура бд

Рис.3. Этапы проектирования интегрированной БД

Этап 1 является подготовительным и слабо поддается формализации. Состоит из следующих подэтапов:

• определение сферы применения БД как в настоящем, так и в будущем;

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

• преобразование собранной информации в форму, удобную для проведения ее анализа и дальнейшего использования (диаграммы, таблицы, матрицы связей и т.д.).

На этапах 2 и 3 выполняется проектирование БД на логическом уровне (логическое проектирование).

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

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

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

2.2. Проектирование субд - независимого концептуального представления данных

Как было изложено в разделе 2.1, на данном этапе необходимо:

• осуществить предварительный выбор сущностей предметной области;

• определить множества возможных запросов к данным для каждого конечного пользователя, на основе которых описать локальные представления пользователей;

• выполнить интеграцию локальных представлений в единое концептуальное представление;

• окончательно определить сущности и их атрибуты.

При выполнении этого этапа проектирования могут возникнуть проблемы, например при выделении сущностей. Так сущности не всегда явным образом выделяются среди других конструктивных элементов таких, как атрибуты и связи. Например, для представления факта назначения могут быть использованы, по крайней мере, три различные структуры [5],[7]. В зависимости от точки зрения пользователя НАЗНАЧЕНИЕ может быть представлено как связь:

ПРОЕКТ ^{НАЗНАЧЕНИЕ} СЛУЖАЩИЙ

сущность: НАЗНАЧЕНИЕ (ПРОЕКТ, СЛУЖАЩИЙ)

или атрибут:

ПРОЕКТ (НАЗНАЧЕННЫЕ_СЛУЖАЩИЕ)

СЛУЖАЩИЙ (НАЗНАЧЕННЫЙ_НА_ПРОЕКТ)

В процессе выделения сущностей рекомендуется руководствоваться следующими правилами [7].

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

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

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

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

Большие неприятности могут причинить связи типа М:М из-за сложности их реализации. Эту связь рекомендуется заменить связью 1:М или М:1 .

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

Идентичность - самая простая из них. Два или более элементов считаются идентичными, если они имеют одинаковое семантическое (смысловое) значение. В частности, синонимы являются идентичными, например, ОБЩАЯ_ЦЕНА_ТОВАРА и СТОИМОСТЬ_ТОВАРА.

Агрегация позволяет рассматривать связь между элементами как новый элемент более высокого уровня. Например, элемент СЛУЖАЩИЙ может являться агрегацией элементов: ФИО, АДРЕС, МЕСТО_РАБОТЫ.

Обобщение является наиболее трудным для восприятия и может быть спутано с агрегацией. Разница между этими понятиями состоит в том, что агрегация может быть представлена в виде составных частей, образующих некоторое целое, а обобщение связано только с целыми. Например, целое СЛУЖАЩИЙ может рассматриваться как обобщение следующих целых: ФАБРИЧНЫЙ_СЛУЖАЩИЙ, КОНТОРСКИЙ_СЛУЖАЩИЙ, АДМИНИСТРАТОР.

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

Интеграция идентичностью. Если один пользователь определил в своем представлении сущность B_x , а другой - сущность C_x , и они идентичны, то в качестве глобальной сущности G (BC) может выступать или B_x или C_x , т.е.

G(BC) = B_x = C_x (рис.4, а).

Интеграция агрегацией может быть двух типов.

Тип 1 (рис.4, б). Глобальная сущность в явном виде присутствует в представлении одного пользователя. Например, пусть в предметной области ВЕЛОСИПЕДЫ один пользователь определил несколько не связанных между собой сущностей:

B₁ = КОЛЕСА , B₂ = РАМЫ , B₃ = СИДЕНИЯ , B₄ = РУЛИ ,

а второй пользователь - C₁ = ВЕЛОСИПЕД . В этом случае глобальной сущностью может быть G(BC) = C₁ = ВЕЛОСИПЕД и B₁  B₂  B₃  B₄  C₁ .

Тип 2 (рис.4,в). Глобальная сущность в явном виде не присутствует ни в одном пользовательском представлении, т.е. является виртуальной сущностью. Например, первый пользователь определил сущности: B₁ = КОЛЕСА , B ₂ = РАМЫ, а второй - сущности: C₁ = СИДЕНИЯ , C₂ = РУЛИ . В этом случае в качестве глобальной можно использовать виртуальную сущность G(BC) = ВЕЛОСИПЕД и

B₁  B₂  C ₁  C₂  G(BC) .

Интеграция обобщением также существует двух типов.

Тип 1 (рис.4, г). Пусть первый пользователь определил сущности:

B₁ = ДВУХКОЛЕСНЫЕ_ВЕЛОСИПЕДЫ, B₂ = ТРЕХКОЛЕСНЫЕ_ВЕЛОСИПЕДЫ,

B₃ = ТАНДЕМЫ , а второй - одну сущность C₁ = ВЕЛОСИПЕД .

В этом случае глобальная сущность G(BC) = C_{1 ,} но связь ее с сущностями первого пользователя удобно задать через виртуальную сущность, например, ТИП. Очевидно, B₁  B₂  B₃ = C₁ .

Тип 2 (рис.4,д). Пусть первый пользователь определил сущности:

B₁ = ДВУХКОЛЕСНЫЕ_ВЕЛОСИПЕДЫ , B₂ = ТАНДЕМЫ , а второй - сущность

C₁ = ТРЕХКОЛЕСНЫЕ_ВЕЛОСИПЕДЫ .

В этом случае в качестве глобальной сущности можно использовать виртуальную сущность G(BC) = ВЕЛОСИПЕД , которую с сущностями пользователей лучше также связать через виртуальную сущность ТИП : G(BC) = B₁  B₂  C_{1 .}

На рис.5 приведен пример интеграции двух локальных пользовательских представлений из предметной области ВЕЛОСИПЕДЫ в единое концептуальное представление.

Пример 2. Выделим предварительно в предметной области ПРОИЗВОДСТВО два объекта ПОСТАВЩИК и ДЕТАЛЬ, для которых определим связь типа М:М по имени ПОСТАВКА :

ПОСТАВЩИК ^{ПОСТАВКА} ДЕТАЛЬ

Спроектируем концептуальную схему данных на основе трех локальных пользовательских представлений (подсхем).

Для первого пользователя определим следующее множество запросов.

1. Найти номера деталей, поставляемые поставщиком с заданным номером, например, П1.

Ключом доступа в этом запросе является атрибут НОМЕР_ПОСТАВЩИКА (обозначим PN). Ответом на запрос будут значения атрибута НОМЕР_ДЕТАЛИ (DN). В дальнейшем будем использовать краткую форму записи запроса в виде

DN ?  PN = “П1”

2. Найти город и статус (важность, значимость) поставщика с заданным номером, например, П2.

Ключом доступа в этом запросе является атрибут НОМЕР_ПОСТАВЩИКА (PN).

Ответом на запрос будут значения атрибутов ГОРОД (GOROD), в котором размещается поставщик, и СТАТУС (ST) поставщика. Краткая форма записи запроса:

GOROD, ST ?  PN = “П2” .

Подсхема пользователя 1 может быть определена в виде

п/сх-1 = (PN, GOROD, ST, DN).

Для второго пользователя определим следующее множество запросов.

1. Найти номера деталей, поставляемых в заданном количестве, например, 20. Ключом доступа здесь является атрибут КОЛИЧЕСТВО (KOL), а ответом на запрос будут значения атрибута НОМЕР_ДЕТАЛИ (DN).

Краткая форма записи запроса: DN ?  KOL = 20.

2. Найти цвет детали, номер которой задан, например, D1.

Ключом доступа здесь является атрибут НОМЕР_ДЕТАЛИ (DN), а ответом на запрос будут значения атрибута ЦВЕТ (ZVET).

Краткая форма записи запроса: ZVET ?  DN = “Д1”.

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

Ключом доступа здесь является атрибут ЦВЕТ (ZVET), а ответом на запрос будут значения атрибута ИМЯ_ДЕТАЛИ (DIM).

Краткая форма записи запроса: DIM ?  ZVET = “красный”.

Подсхема пользователя 2 может быть определена в виде

п/сх-2 = (DN, DIM, ZVET, KOL).

Для третьего пользователя определим следующее множество запросов.

1. Найти имена поставщиков, размещенных в заданном городе, например, Москве.

Ключом доступа здесь является атрибут ГОРОД (GOROD), а ответом на запрос будут значения атрибута ИМЯ_ПОСТАВЩИКА (PIM).

Краткая форма записи запроса: PIM ?  GOROD = “Москва”.

2. Найти значимость поставщиков, размещенных в заданном городе, например Самаре, и поставляющих деталь с заданным именем, например, “гайка”.

Ключами доступа здесь являются атрибуты ГОРОД (GOROD) и ИМЯ_ДЕТАЛИ (DIM), а ответом на запрос будут значения атрибута ЗНАЧИМОСТЬ_ПОСТАВЩИКА (ZN).

Краткая форма записи запроса: ZN ?  GOROD = “Самара” AND DIM = “гайка”. Такой запрос называется булевским (присутствует логическая операция И (AND) ).

Подсхема пользователя 3 может быть определена в виде

п/сх-3 = (PIM, ZN, GOROD, DIM).

При интеграции подсхем необходимо использовать концепцию идентичности, так как ЗНАЧИМОСТЬ_ПОСТАВЩИКА (ZN) и его СТАТУС (ST) по смыслу являются синонимами. Поэтому в концептуальной схеме их будем обозначать одним именем, например ST. Тогда концептуальная схема может быть представлена перечислением атрибутов:

Схема =  п/сх-i = (PN, PIM, ST, GOROD, DN, DIM, ZVET, KOL)

ⁱ

или графически в виде диаграммы (рис.6)

ГОРОД (GOROD)

СТАТУС (ST)

ПОСТАВЩИК ИМЯ (PIM)

НОМЕР_ПОСТАВЩИКА (PN)

ПОСТАВКА КОЛИЧЕСТВО (KOL)

НОМЕР_ДЕТАЛИ (DN)

ДЕТАЛЬ ИМЯ (DIM)

ЦВЕТ (ZVET)

Рис.6. Концептуальная схема для данных примера 2

Из диаграммы видно, что в предметной области ПРОИЗВОДСТВО окончательно выделены три сущности, и определены их атрибуты:

ПОСТАВЩИК (PN, PIM, ST, GOROD)

ДЕТАЛЬ (DN, DIM, ZVET)

ПОСТАВКА (PN, DN, KOL)