gEDA » Development » Parts Manager » Design Document
This page serves as a working document for the design of a parts manager for gEDA. Please submit feedback to the geda-dev or geda-user mailing lists.
For implementation details, see gparts_id.
Or, return to the part manager top level page.
The part manager uses a relational database to store parts used in the development of electronic assemblies. The part manager also stores attributes for these parts and can place these attributes into a component or symbol for placement into schematics.
The part manager provides a GUI that allows the user to browse and edit the data in the part database. The user can select parts in the GUI, then cut and paste them into their schematic.
The following figure shows the relationship between the parts manager and other applications in the gEDA suite.
The part database can be configured as either local or remote. In the remote configuration, many users can access the part database concurrently.
The following figure shows the entity relationships for a part in the resistor category. The category does not reference any tables in the resistor category, but only contains the view name and stored procedures to manipulate a part within the resistor category. This mechanism allows the tables and relationships to vary by category.
The database always contains tables to store the following entities. The database contains additional tables to store specific categories of parts (e.g. a capacitor table, a diode table, a resistor table, etc…). This list excludes junction tables and metadata tables.
A class of parts (e.g. capacitors, diodes, resistors, transistors, etc…). A category can contain sub-categories (e.g. small-signal diodes, TVS diodes, zener diodes, etc…) Sub-categories can include additional sub-categories. All parts within a category or sub-category share the same set of attributes (e.g. forward voltage, maximum current, power dissipation, etc…). Sub-categories do not need to inherit the attributes of their parent.
The category stores metadata for mapping the part’s database columns to the component attributes. For numeric attributes, the category stores the column’s unit of measure (e.g. amps, farads, ohms, volts, etc…).
The category also stores the names of database views and stored procedures to access and manipulate the tables of parts within the category.
| Field | Type | Description |
|---|---|---|
| CategoryID | Surrogate key | |
| CategoryName | String | The unique name of the category |
| ParentID | Foreign key to Category |
Currently, a company represents a part’s manufacturer.
| Field | Type | Description |
|---|---|---|
| CompanyID | Surrogate key | |
| CompanyName | String | The unique name of the company |
A type of part. The device name only provides a mechanism to map parts to symbols. A part in the library of device resistor can use all the symbols in the library where device is resistor. Similarly, a symbol where device is resistor can represent any part of device resistor. When importing a symbol, the database uses the value of the symbol attribute DEVICE as the initial value for the device field. The user can change the device field after import using the part manager GUI.
| Field | Type | Description |
|---|---|---|
| DeviceID | Surrogate key | |
| DeviceName | String | The unique name of the device |
Any file associated with a part. Documents can include datasheets, erata, user manuals, etc… This entity stores a path to the actual document file. The path could either be local or network. The path stored in the database is relative to the base path stored in the configuration file.
| Field | Type | Description |
|---|---|---|
| DocumentID | Surrogate key | |
| Category | String | The document's category (e.g. “Datasheet”, “Erata”, “User Manual”) |
| Title | String | The document's title |
| SourceURL | String | The URL where the document can be obtained on the Internet |
| FileLocation | String | The location of the locally stored document |
The PCB artwork associated with a package. This entity stores a path to the actual PCB footprint file. The path could either be local or network. The path stored in the database is relative to the base path stored in the configuration file.
| Field | Type | Description |
|---|---|---|
| FootprintID | Surrogate key | |
| FootprintName | String | The unique name of the footprint |
| Field | Type | Description |
|---|---|---|
| ModelID | Surrogate key | |
| ModelName | String | The name of the MODEL within the model file. |
| ModelPath | String | Absolute path to the model file. |
| ModelType | String | The model type: IBIS, PSPICE, etc… |
When instantiating a component or creating a heavy symbol that uses a Spice model, the following database columns map to the following attributes.
| Column | Attribute | Notes |
|---|---|---|
| Model.ModelName | MODEL-NAME | |
| Model.ModelPath | FILE | Should use absolute path. |
A part represents a class of components. The database uses this version of the part table when configured to use a flat part table. The flat and hierarchical parts tables are mutually exclusive. The database uses one or the other.
| Field | Type | Description |
|---|---|---|
| PartID | Surrogate key | |
| CompanyID | Foreign key to company specifies manufacturer | |
| PartNumber | String | The manufacturers's part number |
| DeviceID | Foreign key to Device |
Other columns TBD.
A part represents a class of components. The database uses this version of the part table when configured to use hierarchical part tables. The flat and hierarchical parts tables are mutually exclusive. The database uses one or the other.
| Field | Type | Description |
|---|---|---|
| PartID | Surrogate key | |
| CompanyID | Foreign key to company specifies manufacturer | |
| PartNumber | String | The manufacturers's part number |
| DeviceID | Foreign key to Device |
The physical structure, or form-factor, of a part (i.e. 0603, SOT-23, PDIP16). Each package can associate with zero or more footprints. Also, each footprint could represent zero or more packages.
| Field | Type | Description |
|---|---|---|
| PackageID | Surrogate key | |
| PackageName | String | The unique name of the package |
| Technology | String | The type of package. Either “SMT” or “TH” |
The graphical representation of a part. This entity uses the symbol base filename as the unique name of the symbol. This base filename is relative to one of the component libraries found in the configuration files. The component library paths can either be local or network.
| Field | Type | Description |
|---|---|---|
| SymbolID | Surrogate key | |
| SymbolName | String | The unique name of the symbol. This field contains the base filename of the symbol. |
| DeviceID | Foreign key to Device |
Part categories break down classes of parts hierarchically. The category hierarchy exists separately than the part hierarchy. The category hierarchy only provides the user with a system to locate parts quickly. A child in the category hierarchy does not need to inherit the attributes of a parent.
The parts manager uses categories to keep the lists of parts manageable. If the list of parts in a particular category grows large, the category can be subdivided into sub-categories.
It may be difficult to change the categories, using a GUI, because of the part table abstraction through database views and stored procedures. It may be better to distribute the parts manager with a default configuration that works for most.
The default hierarchy of parts follow:
The part hierarchy allows the database to attach additional attributes to a class of parts. These attributes provide a faster means to locate and select parts, especially commodity parts. The database only provides these additional attributes when configured to use hierarchical part tables.
These additional attributes, stored in numeric format, allow SQL to select parts. For example, to locate diodes with reverse voltage greater than 60 volts, use the following SQL statement.
SELECT * FROM DiodeV WHERE VR > 60;
The intent of the part hierarchy does not include exhaustively classifying all electronic parts or fully parameterizing any class of electronic part. The part hierarchy simply intends to allow the user to quickly locate a part, such as a 4.75 kΩ 1% 0603.
TODO: Develop guidelines for subclassing part.
Proposed guidelines for including attributes:
These attributes may not work for everyone, so the database allows the user to customize these part tables.
Bipolar Junction Transistors (BJTs) extend part with one additional table of attributes.
Table name: BJT
View name: BJTV
| Field | Type | Units | Description |
|---|---|---|---|
| PartID | < |