Oracle Master-Details forms for beginners

Creating a Master/Detail Form

In this section, the basic steps for creating a Master/Detail form are introduced. A Master/Detail form is a form that has two blocks arranged in a master/detail relationship.

The Master/Detail Relationship

The Master/Detail relationship is a common relationship between entities in a business. In an Entity-Relationship diagram, these are shown as “One to Many” relationships. In a physical database design, a single Master record references one or more detail records in another table. A record in the detail table will relate to exactly one master record in the master table. Another name for this relationship is called parent-child. Examples of this relationship include:

1. A Customer Order with many OrderItems.
2. A Department with many Employees.
3. An Employee with many Dependents.
4. A Company with many Branch Offices.
5. A Recipe with many Recipe Steps.
6. An Inventory location with many Inventory Items.

Oracle Forms implements the master/detail relationship using two data blocks. The first block corresponds to the master table and the second block corresponds to the detail table. There are two major functions in a Master/Detail form:

· Oracle Forms coordinates values between the two blocks through a series of form and block level triggers.

· Oracle Forms guarantees that the detail block will display only records that are associated with the current record in the master block.

Note that a Master/Detail form is simply one way of viewing the data in two related tables. Forms do not affect the schema in terms of creating, dropping or enforcing database level referential integrity constraints.

Steps to Create a Master/Detail Form

In this section, a set of step by step instructions for creating a Master/Detail form are given. The form will allow a user to query a given department in the company and then will display all of the employees in that company.

The schema used is the same one suggested in the Prerequisites section at the beginning of this tutorial. Notice that the DNO column in the EMPLOYEE table gets its values from the DNUMBER column in the DEPARTMENT table. In other words, to join the two tables in a query, one might specify a WHERE clause such that: EMPLOYEE.DNO = DEPARTMENT.DNUMBER.

Create the Master Block

In the Object Navigator, click on the Forms branch at the very top. Create a new form by pulling down the File menu and choosing the New menu item. Then choose Form from the flyout menu.

Using the same steps given in the prior section on 6. Creating a Form with a Single Block, create a new block named DEPARTMENT that contains all of the columns in the DEPARTMENT table. Briefly:

1. Pull down the Tools menu and choose the Data Block wizard.

2. Create a data block for a table/view.

3. Specify the DEPARTMENT table and select all of the columns (DNAME, DNUMBER, MGRSSN and MGRSARTDATE).

4. Create the data block and then go on to the Layout wizard.

5. Apply the Department data block to a new canvas.

6. Add all of the columns as Displayed Items.

7. Change the labels to:
Dept. Name
Dept. Number
Mgr. Ssn
Mgr. Start Date

8. Choose a Form layout.

9. Specify a frame title of “Departments” and select only 1 record to be displayed.

10. Save the form as deptemp.fmb and then compile and run it to make sure it is working properly.

11. Use the QBE features to retrieve only those departments with DNUMBER greater than 2. Then, do another QBE query to retrieve only those departments with the letter H in their name (try %H%).

After this first step, the deptemp form should look like the following:

Create the Detail Block

Now that we have the master block DEPARTMENT created, we can now create the detail block EMPLOYEE and associate it with the master block. Perform the following steps:

1. Return to the Object Navigator (pull down the Tools menu and choose Object Navigator).

2. In the Object Navigator, click on the Data Blocks branch of the DEPTEMP form (do not click on the department data block, however).

3. Pull down the Tools menu and choose the Data Block wizard.
Note: If the DEPARTMENT data block (or any of its items) is still selected, activating the Data Block wizard will cause the existing block to be edited instead of creating a new block (which is what is required in this part of the tutorial).

4. Select the EMPLOYEE table and include the FNAME, LNAME, SSN, BDATE, SALARY and DNO columns.

5. Because at least one data block already exists in the form, the next step in the wizard will be to create a relationship between the existing data block (DEPARTMENT in this case) and the new block being created.

The wizard can construct the relationship based on table level constraints it learns from the database schema. For example, in the CREATE TABLE and ALTER TABLE statements given at the start of this tutorial, foreign key constraints were specified between DEPARTMENT and EMPLOYEE, and between EMPLOYEE and DEPENDENT. However, such relationships are not always implemented in table level constraints.
The developer can also specify the relationship manually. In this case, the relationship will be specified manually.

De-select the Auto-join data blocks option.
Click on the Create Relationship button to list the available data blocks.
In the next dialog box Relation Type, choose Based on a join condition and click the OK button.

When the list of blocks appears, choose the DEPARTMENT data block.
Arrange the Detail Item (DNO) and Master Item (DNUMBER) such as that the join condition becomes: EMPLOYEE.DNO = DEPARTMENT.DNUMBER

6. Name the data block EMPLOYEE.

7. Create the data block and then call the Layout wizard.

8. Be sure to choose the existing canvas (CANVAS4 in this example) and include all of the items except the DNO as displayed.
The DNO column (item) will still be a part of the EMPLOYEE data block, however, it will not be displayed to the user.

9. Touch up the labels for the fields and choose the Tabular layout.

10. Give the Frame Title as “Employees” and select 5 Records displayed with 0 distance between records.

11. Save the form (it should already have the name deptemp.fmb) and then compile and run it. Note that after compilation, any errors encountered will be displayed.

The following figure shows the master/detail form running:

Notice that by scrolling the master block DEPARTMENT to a new department number (using the up and down arrow keys), the employees for that department are automatically queried and displayed.

To navigate between the Master and Detail blocks, use:

· To go to the next block: Press CTRL-PageDown or pull down the Block menu and choose Next

· To go to the previous block: Press CTRL-PageUp or pull down the Block menu and choose Previous

 Relation Properties of a Master/Detail Form

There are a number of properties in a master/detail form that can be changed to suit particular behavior of the form. In the figure below, the Object Navigator has several new objects on it including Relations.

To view the properties for the DEPARTMENT_EMPLOYEE relation, open up the DEPARTMENT block and then open the Relations block by clicking on the + symbols. Then click on the DEPARTMENT_EMPLOYEE relation with the right mouse button and select Properties.

There are several interesting properties in the relations property sheet:

1. Name – The name of the Relation. This is typically made up of the names of the blocks.

2. Relation Type – The type of the relation: Join or Ref.
A Join relation uses the typical SQL join (in the Where clause) to bring the two tables (data blocks) together. The Ref relation type is used for abstract data types and object references.

 3. Detail Data Block – The name of the detail data block specified when the detail data block was created.

 4. Join Condition – This is the join condition in effect for queries to the database. This was specified when the detail data block was created.

 5. Delete Record Behavior – Used to specify how the deletion of a record in the master block affects records in the detail block. It supports the following settings:

o Non-isolated: Prevents the deletion of a master record if associated detail records exist in the database.

o Isolated: Deleting the master record will not affect the associated detail records in the database.

o Cascading: Deletes the master record and automatically deletes any associated detail records.

6. Coordination – Deferred – Indicates when detail records should be queried when a master record is queried.

o Yes: Form does not query the detail records until the user navigates to the detail block.

o No: Detail records are fetched immediately when a user queries the master record.

Deferred is sometimes set to Yes in cases where there are a lot of detail records for each master record. In such cases, a lot of data must be queried and delivered to the client each time a new record is displayed in the master block. When Deferred is set to Yes, the user can scroll down to the master record of interest and then navigate to the detail block (CTRL-PageDown) to query the related detail records.

7. Coordination – Auto-query – Applied to deferred queries only

o Yes: the query is automatically executed when the user navigates to the detail block.

o No: the query must be executed manually by the user after they navigate to the detail block.

8. Prevent Masterless operation – Specifies whether users are allowed to query or insert records in a detail block when no master record is in place.

o Yes: Users may not query or insert when no master record is in place.

o No: Users may query or insert when no master record is in place.

These settings are used to “tune” the overall performance of a master/detail form. As mentioned above, in cases where a large number of detail records are associated with each master record, it is a good idea to set coordination-Deferred to Yes to avoid unnecessary transfers of data between the server and client. This will also speed up the display of master records as the user can freely scroll through them without a pause to query and deliver the detail records.