1. Entering Data in Tables in a Supertype/Subtype Relationship*
Super-SubForm
4/14/2017
Entering Data in Tables in a Supertype/Subtype Relationship*
If you came to this presentation via a web browser,
right-click and choose “Full Screen” before proceeding.
Click mouse or press space bar to continue.
This presentation was prepared by Professor Steve Ross, with the advice of other MIS Faculty, for use in MIS Classes at Western Washington University. Please contact Dr. Ross for permission to use in other settings..

2. The Challenge
Create a form for the entry of building data in the supertype and subtype tables
Most database programs implement a supertype/subtype structure as a series of 1:1 relationships

3. Step 1 – Source Data
To enter data into tables that are in a supertype/ subtype relationship, we must create a form for the “supertype” table and subforms for the “subtype” tables
Create a view for each table the form affects
vueFrmBuilding, vueSfrManuBuilding, and vueSfrRetailBuilding contain all fields of their respective tables

4. Step 1a – Source Data
Determine field and control characteristics for vueFrmBuilding – the “supertype” view
Field
Editable
Control format
Constraints
BuildingID No
Read only text
Address
Yes
Text box
City
State
Zip
Description
Status
ManagerID
Combo box
FK to tblWorker
BuildingType
values “Manufacturing” and “Retail”

5. Step 1b – Source Data
Determine field and control characteristics for vueSfrManuBuilding – a “subtype” view
* In Microsoft Access, when a record is added in the subform, the value of the parent form linking field (vueFrmBuilding.BuildingID) is automatically entered into the child form linking field (vueSfrManuBuilding.BuildingID); therefore an editable or visible control is not needed
Field
Editable
Control format
Constraints
BuildingID No
Not visible*
FK to tblBuilding
OfficeArea
Yes
Text box
ManuArea
StorageArea
RailDock
Check box
Boolean field
TruckDock

6. Step 1c – Source Data
Determine field and control characteristics for vueSfrRetailBuilding – a “subtype” view
* In Microsoft Access, when a record is added in the subform, the value of the parent form linking field (vueFrmBuilding.BuildingID) is automatically entered into the child form linking field (vueSfrRetailBuilding.BuildingID); therefore an editable or visible control is not needed
Field
Editable
Control format
Constraints
BuildingID No
Not visible*
FK to tblBuilding
TotalArea
Yes
Text box
RetailArea
CommonArea
FoodCourt
Check box
Boolean field
ParkingArea

7. Designing for Usability: Subtypes in Subforms
The primary key of the supertype table is both a primary key and foreign key in the subtype table
A foreign key that relates the subform table to the parent form table is entered automatically by Access when data are entered in the subform
If there is a possibility that users will not enter data in the subform, then steps must be taken to ensure a record is created – see Step 6

8. Designing for Usability: Subtypes in Subforms (cont’d)
The subtype discriminator (either a single field or set of Boolean attributes) can be used to control which subform(s) are visible or enabled.
If disjoint, then only the relevant subform should be visible
If overlapping, then all relevant subforms might be visible, depending on the values of the Boolean fields
The remainder of this example illustrates the technique for a “disjoint” situation

9. Step 2 – Layout
Create a draft view of the form – in this case I chose to modify an existing form
This will be a combo box, bound to the BuildingType field, that allows the user to choose one type
This area contains data entry controls for the selected subtype entity; visible only when the matching subtype is chosen
Subtype table field
Subtype table field
Subtype table field
Subtype table field
Subtype table field

10. Step 3a – Create Version 1 of the Main Form
Use the “supertype” view created in Step 1 (vueFrmBuilding) as the record source

11. Step 3b – Add First Subform
Use a “subtype” view as the record source

12. Step 3c – Add Other Subforms
Add subforms for the other views. At this point, I usually stagger their positions for ease of editing.

13. Step 4a – Fine Tuning, Main Form
Convert the “subtype discriminator” controls to combo boxes or check boxes as appropriate
In this example, a combo box is required
Control name changed on “Other” tab
The Row Source property contains the allowable values
An alternative would be to link to a table or view of building types
Important
settings

14. Step 4b – Fine Tuning, Subforms
Open subform in design view
Convert any “foreign key” controls to combo boxes
Change the default view to Single Form
Disable settings that pertain to multiple records (because there’s only one instance of a subtype related to an instance of the supertype)
Important
settings

15. Step 5 – Subform Visibility Control
Use VBA Code and the value of the subtype discriminator combo box to control the visibility of the subforms [code samples on following slide]
Subroutine that sets visible property to True or False based on value of combo box – called by the following
For the parent form, an On Current event that will execute the subroutine each time a new record is displayed
For the combo box, an After Update event that will execute the subroutine each time the value of the combo box changes

16. Step 5 (cont’d) Executes with each new record, including the first
Private Sub Form_Current()
'make all subforms invisible at first
sfrManuBuilding.Visible = False
sfrRetailBuilding.Visible = False
'turn on a subform if building type is known
subShowSubform
End Sub
Private Sub cboBuildingType_AfterUpdate()
'Subroutine displays subform based on value of combo box
Private Sub subShowSubform()
Select Case cboBuildingType
Case "Manufacturing"
sfrManuBuilding.Visible = True
Case "Retail"
sfrRetailBuilding.Visible = True
End Select
Executes with each new record, including the first
Executes after the value of the combo box is changed
Subroutine called by the two event handlers

17. Step 6 – Subtype Record Creation
Making the subform visible does not create a record in the subtype table. Only when data are entered into one of the subtype table fields is a record created.
In some circumstances, you must ensure that a record is created in the subtype table
e.g., when the table is part of another relationship
VBA Code can be used to
Determine whether a record already exists
If not, create one

18. Step 6 (cont’d) Before you enter code ...
Check the table structure of the subtype tables
Access often sets the default value of numeric fields to 0 (zero)
The primary/foreign key field should not have a default value ... if a default value is present, erase it
Each form for the subtype tables should have a control for the primary/foreign key field
I usually set visibility to “No” because it duplicates information on the main form … If you leave it visible, ensure that it cannot be edited by the user
Recommended name: txtSubBuildingID
Recommendation: name the PK control on the main form: txtSubBuildingID

19. Step 6 (cont’d) NOTE: This Slide applies to Access 2010 and later
Previously-existing subroutine has been edited to add new logic
Private Sub cboBuildingType_AfterUpdate()
subShowSubform
'save the record to ensure the identity field is populated
DoCmd.RunCommand (acCmdSaveRecord)
'force the subform to create a new record if none exists
Dim SuperBuildingID As Integer 'create and populate a variable
SuperBuildingID = txtSuperBuildingID 'containing the supertype table PK value
Select Case cboBuildingType
Case "Manufacturing"
sfrManuBuilding.SetFocus
If ([Forms]![frmBuilding]![sfrManuBuilding]![txtSubBuildingID].Value) = "" Then
[Forms]![frmBuilding]![sfrManuBuilding]![txtSubBuildingID].Value = SuperBuildingID
End If
Case "Retail"
sfrRetailBuilding.SetFocus
If ([Forms]![frmBuilding]![sfrRetailBuilding]![txtSubBuildingID].Value) = "" Then
[Forms]![frmBuilding]![sfrRetailBuilding]![txtSubBuildingID].Value = SuperBuildingID
End Select
End Sub
Executes once the subform is visible

20. Step 6 (cont’d) NOTE: This Slide applies to Access 2007 and earlier
Previously-existing subroutine has been edited to add new logic
Private Sub cboBuildingType_AfterUpdate()
subShowSubform
'save the record to ensure the identity field is populated
DoCmd.RunCommand (acCmdSaveRecord)
'force the subform to create a new record if none exists
Dim SuperBuildingID As Integer 'create and populate a variable
SuperBuildingID = txtSuperBuildingID 'containing the supertype table PK value
Select Case cboBuildingType
Case "Manufacturing"
sfrManuBuilding.SetFocus
If IsNull([Forms]![frmBuilding]![sfrManuBuilding]![txtSubBuildingID].Value) Then
[Forms]![frmBuilding]![sfrManuBuilding]![txtSubBuildingID].Value = SuperBuildingID
End If
Case "Retail"
sfrRetailBuilding.SetFocus
If IsNull([Forms]![frmBuilding]![sfrRetailBuilding]![txtSubBuildingID].Value) Then
[Forms]![frmBuilding]![sfrRetailBuilding]![txtSubBuildingID].Value = SuperBuildingID
End Select
End Sub
Executes once the subform is visible

21. Step 7 – Finish the Forms
Apply check constraints and other properties to controls.
Once controls are set, apply other design standards.*
* The form illustrated here met all MIS 421 design standards when it was created. Subsequent changes to the standards may have occurred.

22. Step 8 – Quality Assurance
Can the user change data in an existing record
in the “supertype” view?
in the “subtype” views?
Can the user enter new records
Does switching from one subtype to another cause the appropriate subform to be visible?
Is a record created in the subtype table when that type is chosen on the main form?
Are all constraints working properly? (Test the limits.)
Have all Design Standards been met?

23. Points to Ponder The form created in this example
Partial, not full specialization
Disjoint, not overlap
Allows the subtype to change
Retains old subtype data after change
What changes would be required if …
Full specialization were to be enforced?
Overlap were permissible?
The subtype was fixed, not changeable?
Prior subtype data were to be deleted on change?