Someone please help me Design the database of bill of materials

Question

I want to design the database of bill of materials which contain item and amount.
So the amount of child will depend on amount of parent in term of ratio. For example
A(1)               A(2)
|         ---->     |
B(2)               B(4)
My problem is when i try to add the parent and child . Let A is the parent of B , If i try to add A to be the child of C
I want B to come along with A as well. For example
A                       C
|     C  --->        |           For this I have to store the relation of all item in  my list to check that this item have a child or not if yes
B                             A              The child must come along with its parent , What the Er-diagram
should be for all of my requirement?
                                |
                                B

Answer 1

>I want B to come along with A as well. For example
You can do that, but that is not automatic. You need to do some programming.
It is better to use hierarchyid representation of the tree over traditional FK referencing.
Tree using hierarchyid example:
http://www.sqlusa.com/bestpractices2008/orgchart/
BOL: "Model Your Data Hierarchies With SQL Server 2008
.....The manufacturing system behind automobiles; the organization of a country into states, counties, cities, and postal codes; the description of a home entertainment system—what do these things have in common? The simple answer is that each
describes a hierarchy.
SQL Server 2008 supports a new data type, HierarchyID, that helps solve some of the problems in modeling and querying hier­archical information. I will introduce you to this data type by discussing a pattern commonly used in manufacturing
known as bill of materials (BOM), or bills. Starting with a brief discussion of BOMs, I will illustrate how this kind of data can be modeled. I will also present an implementation of this model in SQL Server 2005. Then I will show you how the HierarchyID data
type can be used to implement the model in SQL Server 2008.
Hierarchical Data
Automobiles are amalgamations of many components, such as engines, drivetrains, electronics, and steering. In the United States, our geographic territories are divided into states and are then sub-divided into jurisdictions called counties.
Counties are then further subdivided in different ways by different agencies. The United States Census Bureau, for example, composes them from Census Tract Areas. The U.S. Postal Service routes mail delivery by Zone Improvement Plan (ZIP) codes. Geographic
information systems (GIS) may aggregate census tracts and ZIP codes together to provide users with a familiar spatial reference for an area.
A recent trip to a local electronics store to evaluate a replacement home entertainment system pointed to a similar sort of hierarchical system—all the combinations of possible components and options left my head spinning! I wondered
how such systems could be modeled and implemented in a database system.
The relationship between an automobile and its engine represents a hierarchy: the automobile contains the engine. The relationship is the same for the drivetrain, the electronics, and the steering. The relationship is containment. A
similar hierarchy can be observed in the relationship between the different groupings of geographic or census data.
Hierarchies exist everywhere, yet implementing them in the context of a relational database frequently proves to be a challenge. A typical approach is to represent the hierarchy using a parent/child relationship with one or more tables.
While this approach certainly works in many cases, it has a few shortcomings. Such solutions must carefully consider how the referential integrity will be maintained. And while querying the depth and breadth of such tables was considerably simplified in SQL
Server 2005 with the introduction of recursive common table expressions, writing queries against these types of tables can still be problematic when joins against many tables are required.
A Bill of Materials Problem
A few years ago I was working on a system being developed by a manufacturing company to help their dealers specify the components needed to build center-pivot irrigation systems. The software produced a list of components needed to custom-build
the desired pivot (the totality of a center-pivot irrigation system is simply referred to as a pivot within the industry). The required components were determined based on geography, soil type, and the intended crops planted in the areas to be covered as well
as the hydrologic and structural considerations of the device itself.
Underpinning the solution would be a SQL Server database. The purpose of the database was to store information about the components available to build the pivot. However, when we generated the specification for manufacturing, we needed
to identify those components as BOMs.
Some bills represented a collection of physical parts that would be assembled into a system component. For example, every pivot needed a pump to draw water from a well into the system. That pump might be electrically powered, meaning
it needed a transformer and fuse box, too. Or the pump might be fuel powered, meaning it needed a tank, a fuel pump, and hoses to connect the pump to the tank. In either case, the required parts for the pump would be listed in a pump bill.
The bill for a complete pivot would include a collection of other bills. For example, a standardized pivot might consist of a tree of bills for the pump, another tree of bills for the spans of pipe used to deliver water, and bills for any other equipment
needed to build that pivot system."
LINK: http://msdn.microsoft.com/en-us/magazine/cc794278.aspx
Kalman Toth Database & OLAP Architect
SELECT Query Video Tutorial 4 Hours
New Book / Kindle: Exam 70-461 Bootcamp: Querying Microsoft SQL Server 2012