We can ask, for example, what areĪll the items that make up this part? If we look upward, from the view of any given child, it is called implosion. The quantity of parts needed to form an assembly can be identified. If an assembly is navigated downward from any given parent, it is commonly called explosion. They are then used as parents with their own children to extend the structure, as is illustrated below To break the item down further, the children of each parent may have child parts of their own. There are parts in the entire bill of materials. There will be as many rows in the ITEM BOM as However, once chosen, the role of the attribute is fixed. The parent does not have to be the first one and the child the second one. It does not matter which attribute is chosen to play which role – In this case, the occurrences would be different because one points to the parent occurrence, the other to the child occurrence. Multiple relationships are valid when any of the following conditions exists: There are multiple relationships between the two entities. Consequently, the two ITEM NOs play different roles. The combination of the two represents the One ITEM NO represents the parent occurrence and the second ITEM NO represents the child occurrence. In ITEM BOM, the two ITEM NOs are required. Why the multiple relationships between the two entities? Is this legitimate? Here is a typical bill of materials structure. The ITEMīOM specifies the relationships that exist between any item and its components. All items, regardless of their role or associations, are first represented in ITEM. The ITEM represents the part out of context. The structure requires a primary entity, such as ITEM, and anĪssociative entity, such as ITEM BOM (BILL OF MATERIAL).
The Bill of Materials represents what component parts comprise a superior part and into what superior parts a component part goes. The term BOM was originally coined in manufacturing and some of the earliest manufacturing data base systems were called BOMP (Bill of Material Processor) andĭBOMP (Data Base Bill of Material Processor). Although it can be applied to many other recursive situations, an actual bill of material makes a goodĮxample for explaining the concept. It is also very descriptive of an actual manufacturing bill of materials. This structure is also called the “adjacency model”. The many-to-many recursive relationship, sometimes called a bill of material (BOM), is more complex. In relational, this is called a self-join. Manager – who of course is also an employee. An example is a simple corporate employee hierarchy. The one-to-many relationship represents a simple hierarchy, which explodes in size as we look down in the hierarchy. Where these relationships are between occurrences of the same entity, as above, they are termed “recursive relationships”. many-to-many relationships, such as a product and all its parts.one-to-many relationships, such as manager and employees and.one-to-one relationships, such as husband and wife.Relationships can fall into three general categories as follows: Tables, snowflaked hierarchies, flattened hierarchies, self-joins, and nested sets.Ī reader completely familiar with recursion might choose to scan the Logical Model section and proceed to the Physical Implementation section. In this article, we will talk about the basic concepts of recursion in a logical model, and will discuss several practical physical implementations, namely, current DBMS implementations, descendent The SQL community complains that you’d have to be Houdini to get the data out. The database community rightfully revolts because that solution has serious There are three issues with hierarchical data:Īs so often happens, the data modeling community praises the logical purity of its solution, which is recursion. A hierarchy according to Webster is a “group of persons or things arranged in order to rank grade,Ĭlass, etc.” Examples are organization structures, product reporting structures, employee-manager relations, and customer-to-customer relationships. Possibly, the most difficult problem to support in the relational model is hierarchical data. June 14-16, 2005 – Long Branch, New Jersey Published in Association with the Meta-Data and Data Modeling Summit