=======================================================================
     BILL OF MATERIALS IN FORMS
     =======================================================================
     PRODUCT:  R:BASE       VERSION :  3.1D & 4.0
     =======================================================================
     AREA   :  FORMS        CATEGORY:  APPLICATION           DOCUMENT#: 666
     =======================================================================
 
 
     Bill of materials (BOM) applications are normally regarded as
     business and industry related; but they also extend their logic to
     agricultural and biological applications (tracking animal blood
     lines, for example) and to a variety of management applications.  All
     require a method for managing what's called the exploding parts
     (population) problem.
 
     Products are made up of components made up of other parts, materials,
     or components.  An animal produces offspring that produces their own
     offspring.  In an office, employees are both employees and managers
     of other employees.  All these situations can create explosion
     diagrams similar to the one below.
 
     The January 1989 R:BASE EXCHANGE showed you how to design a
     database and write an R:BASE for DOS program--using SET POINTER in a
     WHILE loop--to explode the parts in a bill of materials report.
 
     The January/February 1991 R:BASE EXCHANGE showed you how to do the
     same thing using SQL with the same database design. You see a single
     complex SELECT command do in R:BASE 3.1 what it took an entire
     program to do in R:BASE for DOS.
 
     Now, this article shows you how to do use an R:BASE 4.0 form to do
     what it took a long program to do in R:BASE for DOS and a complex
     SELECT command in R:BASE 3.1.  The same database design is used.
     This technique is possible because R:BASE 4.0 allows forms to work on
     views.
 
     Diagram of an Explosion
     -----------------------
     The diagram below shows a parts explosion. This example has four
     levels. The product (PROD1) explodes into its components, and each
     component explodes into the materials that comprise it, and one of the
     materials (M1) is made up of submaterials.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
     Level One: Product
       │            Level Two: Component
       │                │      Level Three: Material
       │                │          │       Level Four: Submaterial
       │                │          │           │
       │                │          │           │
       │                │          │           │
       │                │          │    ┌───- Sub1
       │                │   ┌───── M1 ──┤
       │                │   │           └──── Sub2
       │        ┌─────- A ──┼────- M2
       │        │           ├────- M3
       │        │           └────- M4
       │        │
       │        │                       ┌───- Sub1
     Prod1 ─────┘           ├────- M1 ──┤
        │           │           ├───- Sub2
        ├─────- B ──┼────- M2
        │           └────- M3
        │
        │
        └────── C ──────── M5
 
 
     The Database Design
     -------------------
     To produce an explosion diagram, you need a database design that
     accommodates any number of levels. The database needs to be flexible
     enough to adapt to many different kinds of explosions that use
     various components, materials, and submaterials.  Microrim recommends
     that you use the parent-child concept to build the database.
 
     For example, look at the explosion diagram shown above. Think of each
     element in the diagram as being both a parent of zero, one, or more
     elements (children); and as a child of one or more parents.
 
     Design and Create the BOM
     -------------------------
     To represent these relationships in your database, create a table
     (BOM) with two columns: PARENT (TEXT 10), and CHILD (TEXT 10).
 
      CREATE TABLE bom (parent TEXT 10 +
        NOT NULL, child TEXT 10 NOT NULL)
 
     This database design works with an unlimited number of levels.  By
     having all the BOM relationships are in one table, it's easier to
     track a path through the explosion--relationship by relationship.
     Each path through the diagram is unique. There's only one PROD1-B-M3
     path and only one PROD1-B-M1-SUB2 path.
 
     Load the BOM
     ------------
     Load BOM with a row for every relationship. For example, enter the
     following lines at the R> prompt to load rows for the four-level BOM
     diagram shown above.
 
 
 
 
 
 
 
 
 
 
 
      LOAD bom USING parent, child
      PROD1  A
      PROD1  B
      PROD1  C
      A      M1
      A      M2
      A      M3
      A      M4
      B      M1
      B      M2
      B      M3
      C      M5
      M1     SUB1
      M1     SUB2
      M2     'The End'
      M3     'The End'
      M4     'The End'
      M5     'The End'
      SUB1   'The End'
      SUB2   'The End'
      END
 
     You need a row for every possible path, including the parents that
     have no children.
 
     The Form Explosion
     ------------------
     Now with the database built and loaded, you can use a form to weave a
     path through the explosion.  Two R:BASE 4.0 features allow the
     various levels of the parts explosion to display on a form:  common
     columns and column names in views.
 
     R:BASE Forms automatically link tables based on common columns,
     columns that have the same name in two or more tables.  When you add
     a table or view to a form, R:BASE looks to see which columns in the
     new table or view have the same name as columns in the preceeding tables
     on the form.  Those columns are then used by the form to link the
     tables.  When you edit data with the form, R:BASE then brings up rows
     in the lower tables where the common columns have matching data
     values.
 
     Naming the view columns with CREATE VIEW collist syntax allows you to
     specify the form's linking columns.   The column names specified for
     the view do not need to match the column names in the SELECT part of
     the CREATE VIEW.  It becomes easy to link child to parent, i.e.  the
     form finds the rows where the child on the current level is a parent
     on the next level.
 
     Use the form with the Edit data option only.  R:BASE displays up to
     five levels of exploding parts.
 
     Creating the views
     ------------------
     Define the following views for the BOM database:
 
     CREATE VIEW bom1 (child,child2) AS SELECT parent,child FROM bom
     CREATE VIEW bom2 (child2,child3) AS SELECT parent,child FROM bom
     CREATE VIEW bom3 (child3,child4) AS SELECT parent,child FROM bom
 
 
 
 
 
 
 
 
     Creating the Form
     -----------------
     A form can have up to five tables or views.  Locate the table BOM as
     the first table, view BOM1 as the second table and so on.  Make each
     of the views a region.  As you scroll through the parent rows in the
     table, you'll see how the related parts change in the views.  The
     form might look like this:
 
 
     ┌──────────────────────────────────────────────────────────────────────┐
     │  BOM: parent      child          BOM1: parent      child             │
     │                                ╔════════════════════════╗            │
     │ ██████████   ██████████        ║ ██████████  ██████████ ║            │
     │                                ║ ██████████  ██████████ ║            │
     │                                ║ ██████████  ██████████ ║            │
     │                                ║ ██████████  ██████████ ║            │
     │                                ║ ██████████  ██████████ ║            │
     │                                ║ ██████████  ██████████ ║            │
     │                                ║ ██████████  ██████████ ║            │
     │                                ╚════════════════════════╝            │
     │                                                                      │
     │  BOM2: parent      child         BOM3: parent      child             │
     │   ╔═════════════════════════╗      ╔═════════════════════════╗       │
     │   ║ ██████████  ██████████  ║      ║ ██████████  ██████████  ║       │
     │   ║ ██████████  ██████████  ║      ║ ██████████  ██████████  ║       │
     │   ║ ██████████  ██████████  ║      ║ ██████████  ██████████  ║       │
     │   ║ ██████████  ██████████  ║      ║ ██████████  ██████████  ║       │
     │   ║ ██████████  ██████████  ║      ║ ██████████  ██████████  ║       │
     │   ║ ██████████  ██████████  ║      ║ ██████████  ██████████  ║       │
     │   ║ ██████████  ██████████  ║      ║ ██████████  ██████████  ║       │
     │   ╚═════════════════════════╝      ╚═════════════════════════╝       │
     └──────────────────────────────────────────────────────────────────────┘
 
 
     How Does the form Work?
     -----------------------
     To be able to customize your own application, you need to understand
     how the table and views interact on the form.
 
     Here's how the linking works between the table and the views:
 
      Table           View           View            View
       BOM            BOM1           BOM2            BOM3
       common  data   common  data   common  data    common  data
       column  from   column  from   column  from    column  from
       ------------   ------------   ------------    ------------
       parent  parent
       child   child
         │
         └──────────-> child  parent
                      child2 child
                        │
                        └─────────-> child2 parent
                                     child3 child
                                       │
                                       └──────────-> child3  parent
                                                     child4  child
 
 
 
 
 
 
 
 
 
     Notice that there is no linking column throughout all the table/views
     on the form.  Each is linked only to the immediately preceeding
     table/view.
 
     The form displays the data from the first row, the parent part is
     PROD1, the child is A.  View BOM1 is linked to the table BOM through
     the common column CHILD.  Rows are displayed from the view BOM1 where
     the data in this column matches that in the table BOM.  In other
     words "A" is a value in the CHILD column in the table BOM and a value
     in the PARENT column (named CHILD) in the view BOM1.  Remember that
     when we loaded the data, all parts are loaded into the PARENT
     column.  The parts may or may not have child parts entered.  If "A" is
     not a parent to other parts, the explosion ends - there are no
     more levels for the PROD1,A path through the data.
 
     But A is a parent to other parts so there are more levels to
     traverse.   View BOM1 displays parent "A" and children "M1", "M2",
     "M3", "M4".  Then view BOM2 is linked to the view BOM1 through the
     common column CHILD2 (data from CHILD in view BOM1 matching data from
     PARENT in view BOM2).   Rows are displayed where any of "M1", "M2", "M3"
     or "M4" are parents to other parts.  Each succeeding level is finding
     rows where the child on the previous level is also a parent.  When a
     child part is no longer a parent part, the explosion ends.
 
     ┌───────────────────────────────────────────────────────────────────┐
     │ Edit  Go to  Exit                                                 │
     ├───────────────────────────────────────────────────────────────────┤
     │   BOM: parent      child          BOM1: parent      child         │
     │                                   ╔════════════════════════╗      │
     │      PROD1         A              ║ A           M1         ║      │
     │                                   ║ A           M2         ║      │
     │                                   ║ A           M3         ║      │
     │                                   ║ A           M4         ║      │
     │                                   ║                        ║      │
     │                                   ║                        ║      │
     │                                   ║                        ║      │
     │                                   ╚════════════════════════╝      │
     │                                                                   │
     │    BOM2: parent      child          BOM3: parent      child       │
     │    ╔═════════════════════════╗      ╔═════════════════════════╗   │
     │    ║ M1          SUB1        ║      ║ SUB1        THE END     ║   │
     │    ║ M1          SUB2        ║      ║                         ║   │
     │    ║                         ║      ║                         ║   │
     │    ║                         ║      ║                         ║   │
     │    ║                         ║      ║                         ║   │
     │    ║                         ║      ║                         ║   │
     │    ║                         ║      ║                         ║   │
     │    ╚═════════════════════════╝      ╚═════════════════════════╝   │
     └───────────────────────────────────────────────────────────────────┘
 
     This diagram shows the linking through PROD1, A, M1 and SUB1.  If we
     move to the view BOM1 and scroll through the rows there we can see
     the paths through PROD1, A and M2, PROD1, A and M3 and PROD1, A and
     M4. Because we have located regions, we only see the rows in the
     lower tables that are linked to the current row.
 
     This method assumes that for every parent part entered there is
     an entry in the child column. In other words, it assumes that there
     are no null values in either column.
 
 
 
 
 
 
 
     This is only the beginning.  You have seen how to design a database
     and create views; and a demonstration of the basics of a form
     exploding a product into its component parts and materials.  But
     remember that the exploding parts problem is complex.  This database
     design and views on forms solution do not solve every exploding parts
     problem.
 
     Another example
     ---------------
     Consider an employee table with the following columns: employee name,
     department the employee works in, name of the employee's manager and
     other employee information.  An employee can be both a manager and an
     employee.  The goal to easily see each manager's employees.  In this
     example, you are comparing the department the employee is in with the
     department the employee manages (if any).
 
     There is another column, employee_name, that will also be displayed.
     When you create the views you need to verify that this column has
     unique names to avoid being used as a linking column.
 
     The table: employee
 
      employee_name        TEXT   20
      department_in        TEXT   10
      dept_manages         TEXT   20
           .
           .
           .
 
     The views:
 
     CREATE VIEW level1 (empname1,depman,manage) AS +
       SELECT employee_name,department_in,dept_manages FROM employee
 
     CREATE VIEW level2 (empname2,manage,mngr) AS +
       SELECT employee_name,department_in,dept_manages FROM employee
 
     CREATE VIEW level3 (empname3,mngr,report) AS +
       SELECT employee_name,department_in,dept_manages FROM employee
 
     When using the form, you'll see data as shown below.  Note that the
     tables display data and link based on the first row in each region.
     The Main level displays all employees.  Level1 shows Lynn and Paul
     who are managed by David (first row in Main level).  Level2 shows the
     employees Lynn manages, Roger and Mike R.  Level3 shows the employees
     Roger manages.  To see the employees that Paul manages, you would
     move to Level1 and position the cursor on the second row where Paul
     is the manager.  Level2 and Level3 then display the rows that link
     back to Paul as a manager.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
      Main                              Level 1
     ╔═employee══department══manages═╗   ╔═employee══department══manages═╗
     ║ David     Exec        Sales   ║   ║ Lynn      Sales       Region1 ║─>┐
     ║ Fred      Exec        Acctng  ║   ║ Paul      Sales       Region2 ║  │
     ║ John      Acctng      -0-     ║   ║                               ║  │
     ║ Roger     Region1     Area1   ║   ║                               ║  │
     ║ Mike L.   Persnl      -0-     ║   ║                               ║  │
     ╚═══════════════════════════════╝   ╚═══════════════════════════════╝  │
                    ┌───────────────────────────────────────────────────────┘
                    │          ┌──────────────────────┐
      Level 2       │          │        Level 3       │
     ╔═employee══department══manages═╗   ╔═employee══department══manages═╗
     ║ Roger     Region1     Area1   ║   ║ Frank     Area1       -0-     ║
     ║ Mike R.   Region1     Area2   ║   ║ Mike D.   Area1       -0-     ║
     ║                               ║   ║ Patsy     Area1       -0-     ║
     ║                               ║   ║                               ║
     ║                               ║   ║                               ║
     ║                               ║   ║                               ║
     ╚═══════════════════════════════╝   ╚═══════════════════════════════╝