Проектирование баз данных

Автор работы: Пользователь скрыл имя, 18 Октября 2014 в 22:52, лекция

Краткое описание

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

Вложенные файлы: 1 файл

04_ПроектированиеБД.doc

— 279.00 Кб (Скачать файл)

 

Первичным ключом этой таблицы может быть и первичный ключ сущности МЕНЕДЖЕР  – НМ.

Правило 2

 

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


 

Представим, что на ER-диаграмме связи 1:1, изображенной на рис. 4.5, класс принадлежности сущности МЕНЕДЖЕР будет обязательный, а сущности ФИЛИАЛ – необязательный. Тогда согласно правилу 2 должны быть сгенерированы две таблицы следующей структуры:

 

 

 

МЕНЕДЖЕР – ФИЛИАЛ                       ФИЛИАЛ

 

НМ

СТАЖ

СПЕЦ

НФ


НФ

АДР_Ф




                                                                        

Сущность с необязательным классом принадлежности (ФИЛИАЛ) именуется родительской, а с обязательным (МЕНЕДЖЕР) – дочерней. Первичный ключ родительской сущности (НФ), помещаемый в таблицу, представляющую дочернюю сущность, называется внешним ключом родительской сущности.  Связь между указанными таблицами устанавливается путем связи первичного и внешнего ключа и  имеет вид:

 

ФИЛИАЛ        МЕНЕДЖЕР – ФИЛИАЛ


НФ

АДР_Ф


НМ

СТАЖ

СПЕЦ

НФ




 

 

 

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

 

 Правило 3

 

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


 

Представим, что на ER-диаграмме связи 1:1, изображенной на рис. 4.5, класс принадлежности сущностей МЕНЕДЖЕР, ФИЛИАЛ будет необязательный. Тогда согласно правилу 3 должны быть сгенерированы три таблицы следующей структуры:

 

МЕНЕДЖЕР         ФИЛИАЛ      МЕНЕДЖЕР–ФИЛИАЛ

 

НМ

СТАЖ

СПЕЦ




НФ

АДР_Ф




НМ

НФ




 

 

 

 

При этом осуществляется декомпозиция связи 1:1 на две связи 1:1 следующим образом:

 

МЕНЕДЖЕР         МЕНЕДЖЕР–ФИЛИАЛ                 ФИЛИАЛ



НМ

СТАЖ

СПЕЦ




НМ

НФ




НФ

АДР_Ф




 

 

 

 

Итак, для связи типа 1:1 существуют три отдельных правила формирования предварительных таблиц из ER-диаграмм.

Для связи типа 1:М существуют только два правила. Выбор одного из них зависит от класса принадлежности сущности на стороне M. Класс принадлежности сущности на стороне 1 не влияет на выбор.

 

Правило 4

 

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


 

На ER-диаграмме связи 1:М, представленной на рис.4.5, класс принадлежности сущности СЧЕТ является обязательным. Тогда согласно правилу 4 должны быть сгенерированы две таблицы следующей структуры:

ФИЛИАЛ       ФИЛИАЛ- ЗАКАЗ

 

НФ

АДР_Ф


НЗ

ДЗ

ВЗ

НФ




 

 

 

Связь между указанными таблицами будет иметь вид

 

 

ФИЛИАЛ              ФИЛИАЛ-ЗАКАЗ    


 

НФ

АДР_Ф


 

Н3

ДЗ

ВЗ

НФ




 

 

 

 

 

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

 

Правило 5

 

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


 

Представим, что на ER-диаграмме связи 1:М, изображенной на рис. 4.5, класс принадлежности сущности ЗАКАЗ является необязательным. Тогда согласно правилу 5 должны быть сгенерированы три таблицы следующей структуры:

 

 

 

  ФИЛИАЛ      ЗАКАЗ     ФИЛИАЛ-ЗАКАЗ

 

НФ

АДР_Ф




НЗ

ДЗ

ВЗ




НФ

НЗ




 

 

 

 

 

При этом осуществляется декомпозиция связи 1:М на две связи – 1:М и 1:1 – следующим образом:

 

ФИЛИАЛ            ФИЛИАЛ-ЗАКАЗ                     ЗАКАЗ


НФ

АДР_Ф




НФ

НЗ




 

НЗ

ДЗ

ВЗ




 

 

 

 

 

Правило 6

 

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


 

ER-диаграмма связи М:N имеется на рис. 4.5. Согласно правилу 6 на основе этой ER-диаграммы должны быть сгенерированы три таблицы следующей структуры:

 

КЛИЕНТ           ЗАКАЗ                КЛИЕНТ– ЗАКАЗ

 

НК

ФИО_К

СОЦ_П

АДР_К




НЗ

ДЗ

ВЗ




НК

НЗ




 

 

 

 

 

 

 

При этом осуществляется декомпозиция связи М:N на две связи 1:М следующим образом:

 

КЛИЕНТ           КЛИЕНТ– ЗАКАЗ                   ЗАКАЗ

 



НК

ФИО_К

СОЦ_П

АДР_К




НК

НЗ




НЗ

ДЗ

ВЗ




 

 

 

 

 

 

 

 

В таблице КЛИЕНТ–ЗАКАЗ клиенту, сделавшему, например, три заказа будут соответствовать три строки с одним и тем же номером заказа. А заказ, у которого, например, два владельца, представляется двумя строками с различными номерами клиентов, сделавшими этот  заказ.

 

К ER-модели предметной области ФИРМА, представленной на рис. 4.5, применимы правила 1, 4, 6. Связь МЕНЕДЖЕР – ФИЛИАЛ представляется (согласно правилу 1) одной таблицей

 

МЕНЕДЖЕР–ФИЛИАЛ

 

НМ

СТАЖ

СПЕЦ

НФ

АДР_Ф


 

Связь ФИЛИАЛ – ЗАКАЗ   представляется (согласно правилу 4) связью

 

 

ФИЛИАЛ              ФИЛИАЛ-ЗАКАЗ    


 

НФ

АДР_Ф


 

Н3

ДЗ

ВЗ

НФ




 

 

 

 

Связь КЛИЕНТ – ЗАКАЗ  представляется (согласно правилу 6) связью

 

 

КЛИЕНТ           КЛИЕНТ– ЗАКАЗ                   ЗАКАЗ

 



НК

ФИО_К

СОЦ_П

АДР_К




НК

НЗ




НЗ

ДЗ

ВЗ




 

 

 

 

 

 

 

Анализ состава атрибутов полученных таблиц МЕНЕДЖЕР–ФИЛИАЛ, ФИЛИАЛ, ФИЛИАЛ-ЗАКАЗ, КЛИЕНТ, ЗАКАЗ, КЛИЕНТ–ЗАКАЗ показывает, что таблица ФИЛИАЛ является составной частью таблицы МЕНЕДЖЕР–ФИЛИАЛ, таблица ЗАКАЗ – составной частью таблицы ФИЛИАЛ-ЗАКАЗ. Поэтому таблицы ФИЛИАЛ и ЗАКАЗ можно исключить из рассмотрения. Оставшиеся таблицы МЕНЕДЖЕР–ФИЛИАЛ, ФИЛИАЛ-ЗАКАЗ, КЛИЕНТ, КЛИЕНТ–ЗАКАЗ можно связать посредством связи первичных и внешних ключей как на рис. 4.7.

 

 

 

 

 

В результате получим реляционную  модель для ER-модели предметной области ФИРМА.

 

МЕНЕДЖЕР–ФИЛИАЛ                          ФИЛИАЛ-ЗАКАЗ            


НМ

 СТАЖ

СПЕЦ

НФ

АДР_Ф

Информация о работе Проектирование баз данных