Проектирование БД «Поставки деталей»

В этой базе заказчик хотел бы хранить информацию

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

· о характеристиках каждого поставляемого изделия (вес, металл, диаметр и т.п.)

· о поставщиках деталей

Некоторые условия, существенные для проектирования базы данных:

· каждый поставщик может поставлять несколько различных изделий

· одно и то же изделие может поставляться разными поставщиками

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

Этапы проектирования базы данных:

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

2. определение атрибутов каждой сущности

3. выявление связей между сущностями

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

5. построение ER-диаграмм, отображающих выявленные связи

6. формирование таблиц базы данных по ER-диаграммам:

§ определение нужного количества таблиц

§ определение первичных и вторичных ключей таблиц

1 и 2 этапы: объекты, их атрибуты и первичные ключи

Список объектов (сущностей): типы деталей, детали, поставщики

Сущности изображаются в виде прямоугольника, атрибуты вписываются внутрь прямоугольника, изображающего сущность:

           
     
 
 
 


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

           
   
   
 
 
 


3, 4 и 5 этапы: выявление степени связей и классов принадлежности, их фиксация с помощью диаграмм


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

 
 


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

6 этап: формирование таблиц базы данных по ER-диаграммам

В связи ТИПЫ ДЕТАЛЕЙ --- ДЕТАЛИ степень связи «один-ко-многим», n-связная сущность имеет обязательный класс принадлежности => в соответствии с ER-методом достаточно использовать две таблицы (по одной для каждой сущности); ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы. Кроме того, ключ 1-связной сущности должен быть добавлен как атрибут в таблицу, представляющую n-связную сущность.

Но у нас в таблице ДЕТАЛИ уже есть такой атрибут – Название (он и будет вторичным ключом, соответствующим первичному ключу Наименование).


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: