2012-02-14 25 views
5

Per un progetto scolastico, dobbiamo creare il nostro database. Ho deciso di creare un database per gestire il mio inventario di componenti elettronici. Come requisito, dovevamo creare un diagramma ER, quindi da quel diagramma derivare lo schema del database. Sfortunatamente per me, il professore crede che il diagramma che ho creato possa essere semplificato e l'entità "Parte" non sia necessaria.Semplifica Database ER Schema/Schema

This è lo schema che è venuto fuori e here è lo schema derivato.

Se rimuovo l'entità parte, quindi per un'entità circuito per "utilizzare" un numero qualsiasi di una parte e avere ciascuna parte associata a un eventuale circuito, dovrei avere un M-to-N separato relazione da ciascun tipo di componente a Circuito. Ciascuna di queste relazioni genererebbe una nuova tabella. Questo supererebbe sicuramente il numero massimo di tabelle consentite per il progetto.

Se il professore ha menzionato specificamente la parte non era necessario, quindi ci deve essere un modo per rimuoverlo che si traduce in un semplice diagramma e schema ER - ma non riesco a vedere di cosa si tratta.

Forse voi ragazzi potete vedere di cosa si tratta e darmi un suggerimento?

MODIFICA: Dan W ha avuto un grande suggerimento. Potrei eliminare la parte assegnando a ogni tipo di parte (condensatore, resistore, ecc.) Le proprie chiavi. Quindi all'interno della parte usi, includere le chiavi esterne a tali componenti. Dovrei supporre che ogni voce della tabella sia associata a una sola parte, mentre il resto è nullo. Here's lo schema risultante. Questo schema dovrebbe funzionare bene. Ma ora devo capire esattamente quali modifiche al diagramma ER corrisponderebbero a questo schema.

EDIT2: Sono giunto alla conclusione che il rapporto che sto cercando è n-ario. Secondo diverse fonti, per convertire da n-ary a uno schema si include la chiave primaria della relazione del tipo di entità partecipante come chiave esterna. Quindi aggiungi gli attributi semplici. This è quello che mi è venuto in mente.

+1

Non è possibile modificare PartID in ResistorID, CapicatorID, ecc. E quindi aggiungere queste colonne alla tabella Uses_Part? –

+0

Buon suggerimento. Ci avevo pensato prima, ma non sono del tutto sicuro di come interpretarlo in un diagramma ER. Potrebbe essere una relazione n-ario, ma dovrò vedere. – Schmidget

+2

Mi piace molto il tuo design. Non cambierei nulla. Esistono diversi tipi di parti, con attributi diversi e si hanno entità separate per ciascuna (Resistenza, Condensatore, ecc.). L'entità Part è necessaria come entità supertipo di questi. Come dici tu (correttamente) da usare nella relazione M: N. –

risposta

1

Hai un numero massimo limitato di tabelle (design fisico) ma sei limitato nel tuo diagramma ER a quel numero di entità (progettazione logica)? Tutte le entità per le parti - resistori, transistor, condensatori e IC generale - potrebbero essere memorizzate in una tabella di parti con tutti gli attributi di Parte, resistori, transistor, condensatori e IC generale come colonne nullable. Se un attributo è valido per tutti i tipi, allora non è annullabile. Includere un'altra colonna nella tabella delle parti che identifica il tipo di parte (resistore, transistor, condensatore o IC) sebbene sia già presente una colonna di tipo in tutte le entità che potrebbero anche servire per questo.

La tabella Parti nello schema è ora:

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 

e si rilascia il resistore, condensatore, transistor e IC generale le tabelle nello schema. Lasciare quelle entità nel diagramma ER perché mostra quali attributi nella tabella Parti sono richiesti (non dovrebbe essere nulla) per ogni tipo di parte.

Problemi correlati