2012-02-14 15 views
5

Para un proyecto escolar, tenemos que crear nuestra propia base de datos. Decidí crear una base de datos para administrar mi inventario de componentes electrónicos. Como requisito, necesitábamos crear un diagrama ER, luego de ese diagrama derivamos el esquema de la base de datos. Desafortunadamente para mí, el profesor cree que el diagrama que creé se puede simplificar y la entidad "Parte" es innecesaria.Simplifique el diagrama/esquema ER de la base de datos

This es el diagrama que se me ocurrió, y here es el esquema derivado.

Si elimino la entidad Part, entonces para que una entidad de Circuito "use" cualquier número de cualquier parte, y tenga cada parte asociada con posiblemente cualquier circuito, tendría que tener un M-to-N separado relación de cada tipo de componente a Circuito. Cada una de esas relaciones generaría una nueva tabla. Esto definitivamente superaría el número máximo estricto de tablas que estamos autorizados para el proyecto.

Si el profesor mencionó específicamente que la parte era innecesaria, entonces debe haber alguna forma de eliminarla que resulte en un diagrama y esquema ER más simple, pero no puedo ver qué es.

Tal vez ustedes pueden ver lo que es y darme una pista?

EDIT: Dan W tenía una gran sugerencia. Podría eliminar la parte dando a cada tipo de parte (condensador, resistencia, etc.) sus propias claves. Luego, dentro de la parte de usos, incluya claves externas a esos componentes. Tendría que suponer que cada entrada de la tabla solo estaría asociada con una sola parte, el resto sería nulo. Here's el esquema resultante. Este esquema debería funcionar bien. Pero ahora tengo que descubrir exactamente qué modificaciones al diagrama ER corresponderían a este esquema.

EDIT2: He llegado a la conclusión de que la relación que estoy buscando es n-aria. Según varias fuentes, para convertir del n-ario a un esquema, se incluye la clave primaria de la relación de cada tipo de entidad participante como clave externa. Luego agrega los atributos simples. This es lo que se me ocurrió.

+1

¿No podría cambiar PartID a ResistorID, CapicatorID, etc. y luego agregar estas columnas a la tabla Uses_Part? –

+0

Buena sugerencia. He pensado en esto antes, pero no estoy del todo seguro de cómo representar eso en un diagrama ER. Puede ser una relación n-aria, pero tendré que ver. – Schmidget

+2

Me gusta mucho su diseño. Yo no cambiaría nada. Hay diferentes tipos de partes, con diferentes atributos y usted tiene entidades separadas para cada una (Resistencia, Condensador, etc.). La entidad Part es necesaria como la entidad de supertipo de estos. Como dices (correctamente) para ser usado en la relación M: N. –

Respuesta

1

Tiene un número máximo estricto de tablas (diseño físico) pero, ¿está restringido en su diagrama ER a ese número de entidades (diseño lógico)? Todas sus entidades para partes (resistores, transistores, condensadores e IC general) podrían almacenarse en una tabla de partes con todos los atributos de Parte, resistencias, transistores, condensadores y General IC como columnas con nulo. Si un atributo es válido para todos los tipos, no puede contener nulos. Incluya otra columna en la tabla de partes que identifique el tipo de parte (resistor, transistor, capacitor o IC) aunque ya tiene una columna de tipo en todas las entidades que también podría servir para esto.

La mesa de piezas en su esquema es ahora:

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 

y se le cae la resistencia, el condensador, el transistor y el general IC tablas en el esquema. Deje esas entidades en su diagrama de RE porque eso muestra qué atributos en la tabla de Partes es necesario (no debería ser nulo) para cada tipo de parte.

Cuestiones relacionadas