ķ
 Dale W. Harrison, Copyright 1991 
 3815 Richmond Ave.  Box 111      
 Houston, Texas 77027             
 Phone: (713) 888-1479            
ͼ


             ķ
                A Few Additional Notes on M:M Relationships  
             ͼ



                            ķ
                              INTRODUCTION  
                            ͼ

 There are four possible types of Many-to-Many (M:M) relationships.  These
 four can be reduced to three general classes.  They are as follows:

       Ŀ                Ŀ
         A  >OO<  B           Optional-to-Optional
                       

       Ŀ                Ŀ
         A  >||<  B           Mandatory-to-Mandatory
                       
                                      Ŀ
       Ŀ                Ŀ     
         A  >O|<  B       
                            
                                           Optional-to-Mandatory
       Ŀ                Ŀ     
         A  >|O<  B       
                            
                                      

͵


Optional-to-Optional:
    Ŀ                Ŀ
      SENATOR  >OO<  BILL  
                    
    Each SENATOR can "vote for" zero or more BILL's.
    Each BILL may "be voted on by" zero or more SENATOR's.

 This is a very common relationship.  Here, a BILL can exist without ever
 having received a single vote.  Likewise, a SENATOR may never place a
 vote on a single BILL.  However, a BILL will normally receive votes from
 many SENATOR's, and each SENATOR will normally place votes for many dif-
 ferent BILL's.


͵


Mandatory-to-Mandatory:
    Ŀ                Ŀ
      BOOK  >||<  AUTHOR  
                    
    Each BOOK must "be written by" one or more AUTHOR's.
    Each AUTHOR must "have written" one or more BOOK's.

 This is a relatively rare relationship.  Here, every BOOK absolutely must
 have an AUTHOR, and a person cannot be an AUTHOR unless they have written
 a BOOK.  Likewise, each AUTHOR can have written multiple BOOK's and each
 BOOK can have multiple AUTHOR's.


͵


Optional-to-Mandatory:
           Ŀ                Ŀ
             INVOICE  >O|<  INVENTORY  
                           
           Each INVOICE must "contain" one or more INVENTORY items.
           Each INVENTORY item can be "placed on" zero or more INVOICES.

 This is a more common relationship.  Here, every INVOICE must contain at
 least one INVENTORY item (otherwise it would have no reason to exist), and
 it may contain more than one INVENTORY item.  Each INVENTORY item can
 appear on multiple INVOICES, but a given INVENTORY item might not appear
 on any current INVOICE.


͵


 All of these examples can be dealt with by placing a correlation table
 between each of two M:M tables.  The solution for the above examples
 would be:

 Optional-to-Optional:
    Ŀ            Ŀ            Ŀ
      SENATOR  |O<  VOTING RECORD  >O|ĳ  BILL  
                            

 Mandatory-to-Mandatory:
    Ŀ             Ŀ             Ŀ
      BOOK  ||<  BIBLIOGRAPHY  >||ĳ  AUTHOR  
                              

 Optional-to-Mandatory:
    Ŀ           Ŀ           Ŀ
      INVOICE  ||<  LINE ITEMS  >O|ĳ  INVENTORY  
                          

;






                       ķ
                         Optional-to-Optional  
                       ͼ


   To expand on the 1st example above, we would have tables with the
   following structures:
   Ŀ          Ŀ
      SENATOR                VOTING RECORD         Ŀ
   ͵          ͵            BILL     
    Senate Seat* > Senator*               ͵
    Name                    Bill*  < HR Number*   
    Party                   Vote                    Sponsor      
                    

   The PK of the VOTING RECORD table is [Senator]/[Bill].  Neither key
   segment will ever be blank.  However, there may be some SENATOR's
   that aren't represented in the VOTING RECORD table (the lazy one's
   that have never voted on anything) and there may be some BILL's that
   aren't represented in the VOTING RECORD table (those BILL's that have
   not yet come up for a vote).

   The one flaw with this design is that a BILL may come up for vote and
   no SENATOR votes on it.  There would then be no way of differentiating
   a BILL that had not yet come up for a vote, and a BILL that had come up
   for a vote, but no SENATOR chose to vote on it.  To overcome this limit-
   ation we could replace the Composite-PK used in the VOTING RECORD table
   with a single Surrogate-PK.  We would then have the following structure:

   Ŀ        Ŀ
      SENATOR              SENATE VOTES            Ŀ
   ͵        ͵               BILL     
    Senate Seat* Ŀ   Senate Vote*             ͵
    Name                Bill < HR Number*   
    Party                         Sponsor      
                                     
                         Ŀ
                           VOTING RECORD  
                         ͵
                       > Senate Vote*    
                           Vote Number*    
                     > Senator         
                            Vote            
                           

   Each [Senate Vote] would be on a single BILL, and would involve the
   votes of zero or more SENATOR's.  Notice how this structure exactly
   mirrors the structure of our previous CUSTOMER/INVOICE/INVENTORY
   example.  The same type of M:M E-R Diagram structure will almost al-
   ways decompose in exactly the same way regardless of the details of
   the data stored in the tables.  This illustrates the power of E-R
   Diagrams; they capture the universal features of a particular system.

;






                      ķ
                        Mandatory-to-Mandatory  
                      ͼ


   To expand on the 2nd example above, we would have tables with the
   following structures:
   Ŀ        Ŀ
        BOOK               BIBLIOGRAPHY           Ŀ
   ͵        ͵             AUTHOR    
    ISBN Number* > ISBN Number*            ͵
    Book Title            Author ID* < Author ID*   
    Date Publ.                     Name         
                                       Address      
                                                      

   The PK of the BIBLIOGRAPHY table is [ISBN Number]/[Author ID].  Neither
   key segment will ever be blank.  Furthermore, every single BOOK and
   every single AUTHOR absolutely must be represented in the BIBLIOGRAPHY
   table at least once.  This is because of the Mandatory-to-Mandatory
   relationship between BOOK's and their AUTHOR's.  If a BOOK has more than
   one AUTHOR, then its [ISBN Number] will appear multiple times in the
   BIBLIOGRAPHY table (once for each AUTHOR).  Likewise, if an AUTHOR has
   written more than one book, then his or her [Author ID] will appear in
   the BIBLIOGRAPHY table multiple times (once for each BOOK written).

   There is no compelling need to introduce a Surrogate-PK for the BIBLIO-
   GRAPHY table, however if we chose to we would then have the following
   structure:
                           Ŀ
   Ŀ          BIBLIOGRAPHY  
        BOOK             ͵         Ŀ
   ͵         Entry Number*               AUTHOR    
    ISBN Number* < ISBN Number             ͵
    Book Title            Author ID  < Author ID*   
    Date Publ.                     Name         
                                       Address      
                                                      
   Since we are dealing with a Mandatory-to-Mandatory relationship, and we
   don't have to account for the possibility of a BIBLIOGRAPHY record that
   doesn't always contain BOTH an [ISBN Number] and an [Author ID], then
   the final structure is much simpler than the Optional-to-Optional struc-
   ture.

;






                      ķ
                        Optional-to-Mandatory  
                      ͼ


   To expand on the 3rd example above, we would have tables with the
   following structures:
   Ŀ          Ŀ
      INVOICE                LINE ITEM            Ŀ
   ͵          ͵            INVENTORY  
    Invoice No* > Invoice No*           ͵
    Date                    Part No* < Part No*    
    Customer ID             Unit Price             Description 
                        Unit Cost   
                                                      

   The PK of the LINE ITEMS table is [Invoice No]/[Part No].  Neither key
   segment will ever be blank.  There can never be an INVOICE that isn't
   represented in the LINE ITEM table; it makes no sense for an INVOICE to
   exist unless INVENTORY items are being sold.  However, there may be many
   INVENTORY items that aren't represented in the LINE ITEM table; not
   every part is always being ordered by some CUSTOMER at any given moment
   in time.

   The one flaw with this design is that a given INVOICE could possibly
   contain the same INVENTORY item more once.  To overcome this limitation
   we could replace the Composite-PK used in the LINE ITEM table with a
   single Surrogate-PK.  We would then have the following structure:

   Ŀ          Ŀ
      INVOICE                LINE ITEM  
   ͵          ͵          Ŀ
    Invoice No* > Invoice No*             INVENTORY  
    Date                    Line Number*          ͵
    Customer ID             Part No  < Part No*    
              Unit Price             Description 
                                        Unit Cost   
                                                      

   Again, this represents a universal decomposition of an Optional-to-
   Mandatory M:M type relation.

;






                           ķ
                             A Final Note  
                           ͼ


   One final note.  Notice that in ALL of the above examples, we NEVER had an
   instance where a blank key-segment was needed or allowed.  As a general
   rule, blank key-segments should never be permitted.  If the business rules
   being modeled seem to require it, then that's a strong indication for the
   need to convert to a Surrogate Primary-Key.  An example of such a system
   would be an EMPLOYEE/DEPARTMENT database with the following structure:

                Ŀ            Ŀ
                  EMPLOYEE  >|O|ĳ  DEPARTMENT  
                            

   Here, a DEPARTMENT must have at least one EMPLOYEE assigned to it, however
   an EMPLOYEE could conceivably be in a position where he or she is assigned
   to no particular DEPARTMENT.  This would result in a decomposition into
   the following structure:

     Ŀ            Ŀ           Ŀ
       EMPLOYEE  >||ĳ  ASSIGNMENT  >|O|ĳ  DEPARTMENT  
                            

   The ASSIGNMENT table could have a Composite-PK of [Employee ID]/[Dept #].
   However, the business rules would require that the [Dept #] segment of
   the PK might sometimes have to be blank.  There are two possible ways to
   eliminate the need for a blank key-segment.  We could create a Composite-
   PK for the ASSIGNMENT table, leading to the following structure for the
   ASSIGNMENT table:

     Ŀ
       ASSIGNMENT     where the FK [Employee ID] is never allowed to be
     ͵   blank, but the FK [Department ID] is allowed to
      Assignment#*    be blank.
      Employee ID  
      Dept. ID     
     

   However, a cleaner solution, that would still eliminate the blank PK-
   segment problem, would be the following:

     Ŀ
        EMPLOYEE                              Where the FK [Dept. ID] in
     ͵                           the EMPLOYEE table is allowed
      Employee ID*       Ŀ   to be blank in the case of an
      Name                  DEPARTMENT      employee not being assigned
      SS#                ͵   to a particular Department.
      Dept. ID < Department ID* 
            Dept Name      
                            Manager        
                           



                            ͵ The End 
