|
| table and relationship design - ERD - Newbie |
 |
Fri, 21 Mar 2008 16:39:42 -050 |
I haven't had much experience with databases since my one class in
college. Now I need one, or at least a prototype for my application
that I can make into a real database later.
At any rate. I cranked it up Access and made my first table:
Table: Goods
Description: Something to represent all goods that may exist in my
application's universe
Name - Text Primary Key
Base Value - Number
Now my second table is giving me trouble.
I need something to represent requirements to manufacture a good. For each
good that exists, its manufacture requires many <Good Name, Number
Required>
'sets'
For example
Maufacture of 1 Laser requires: 2 units of Energy, 2 units of chips, 1 unit
of computers, 1 unit of machinery...or something like that.
I want to store those requirements in the DB
The table is related to itself :( So I figure a new table is needed, but I
have no idea how to represent this in my database! I remember my instructor
teaching us how to resolve one to many or many to many relationships and
finally wanting to end up with one to one... I think.
Anyway, can anyone help me out with some advice?
Also some good reference materiel resources are appreciated if free and
unbloated. I just want the basics to get things up quickly. Not 700 pages on
DB administration, stored procedures, triggers, etc.
Thanks!
|
| Post Reply
|
| Re: table and relationship design - ERD - Newbie |
 |
Sat, 22 Mar 2008 12:30:54 -070 |
Christopher,
could recommend the following:
1) Search the web for "Bill of Materials"
2) Check out Joe Celko's book "Trees and Hierarchies in SQL for
Smarties". It is not free, but certainly worth its money (abt. 225
pages). There are several ways presented how to model trees in SQL.
3) this is a link for a nested set BOM in MS Access:
http://www.mvps.org/access/queries/qry0023.htm - Also the SQL Server
sample database AdventureWorks contains such example.
I am certainly not an expert for this type of things, but I could say
that this will most likely not be "quick and easy" but requires some
reading and weighting of advantages and disadvantages of the different
ways to model a tree in SQL.
Brgds
|
| Post Reply
|
|
|
|
|
|
|
|
|
|