2012-02-14 3 views
5

Для школьного проекта нам необходимо создать собственную базу данных. Я решил создать базу данных для управления запасами электронных компонентов. В качестве требования нам понадобилось создать ER-диаграмму, а затем из этой диаграммы получить схему базы данных. К сожалению для меня, профессор считает, что созданная мной диаграмма может быть упрощена, а сущность «Part» не нужна.Упрощение базы данных ER Диаграмма/схема

This - это диаграмма, с которой я пришел, и here - это производная схема.

Если я удаляю объект Part, то для того, чтобы объект Circuit «использовал» любое количество любой части и имел каждую часть, связанную с возможной схемой, мне пришлось бы иметь отдельный M-to-N отношения от каждого типа компонента к Circuit. Каждое из этих отношений создаст новую таблицу. Это, безусловно, перейдет к строгому максимальному количеству таблиц, которые нам разрешены для проекта.

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

Возможно, вы, ребята, можете понять, что это такое и дать мне подсказку?

EDIT: У Dan W было большое предложение. Я мог бы исключить часть, предоставив каждому типу части (Конденсатор, Резистор и т. Д.) Свои собственные ключи. Затем внутри части использования включают внешние ключи к этим компонентам. Я должен был бы предположить, что каждая запись таблицы будет связана только с одной частью, а остальное - нулевым. Here's результирующая схема. Эта схема должна работать хорошо. Но теперь я должен точно выяснить, какие изменения в диаграмме ER будут соответствовать этой схеме.

EDIT2: Я пришел к выводу, что отношения, которые я ищу, являются n-ary. Согласно нескольким источникам, для преобразования из n-ary в схему вы включаете первичный ключ отношения каждого участвующего объекта в качестве внешнего ключа. Затем добавьте простые атрибуты. This - это то, что я придумал.

+1

Не могли бы вы изменить PartID на ResistorID, CapicatorID и т. Д., А затем добавить эти столбцы в таблицу Uses_Part? –

+0

Хорошее предложение. Я думал об этом раньше, но я не совсем уверен, как представить это на диаграмме ER. Это может быть n-ary отношения, но я должен буду видеть. – Schmidget

+2

Мне очень нравится ваш дизайн. Я ничего не изменил бы. Существуют разные части, с разными атрибутами, и у вас есть отдельные сущности для каждого из них (резистор, конденсатор и т. Д.). Элемент Part необходим как объект супертипа. Как вы говорите (правильно), чтобы использоваться в отношениях M: N. –

ответ

1

У вас есть строгое максимальное количество таблиц (физический дизайн), но ограничено ли вы на диаграмме ER этим количеством объектов (логический дизайн)? Все ваши объекты для частей - резисторы, транзисторы, конденсаторы и общий IC - могут храниться в одной таблице деталей со всеми атрибутами Части, резисторов, транзисторов, конденсаторов и General IC в качестве нулевых столбцов. Если атрибут действителен для всех типов, он не имеет значения NULL. Включите другой столбец в таблицу деталей, который идентифицирует тип детали (резистор, транзистор, конденсатор или микросхема), хотя у вас уже есть столбец типа во всех объектах, которые также могут служить для этого.

таблица частей в вашей схеме сейчас:

PartID (PK) 
Quantity 
Drawer 
Part Type 
Value 
Tolerance 
Subtype 
Power Rating 
Voltage 
Term_Style 
Diam 
Height 
Lead_Space 
Name 
Case 
Polarity 
Use 
V_CE 
P_D 
I_C 
H_FE 
Package 
Pins 
Description 

и вы уронили резистор, конденсатор, транзисторные и General IC таблицы в схеме. Оставьте эти объекты на диаграмме ER, потому что это показывает, какие атрибуты в таблице Parts необходимы (не должны быть пустыми) для каждого типа детали.