Design and Development Methodology
Identifying the Applications and the Database Schema
Dr. Awad Khalil
A developer usually follows a methodology when designing and building a computer system. Without a methodology; the
developer can flounder and produce an incomplete system. If, by chance, the developer finishes a product without using a
methodology; the product might not meet user requirements.
This part briefly reviews the system development life cycle and explains how Oracle’s Forms Builder tool set fits within this life
cycle. Before you begin learning how to use Forms Builder, it is important that you become aware of powerful tools that can
help you develop effective forms. This chapter discusses several of the tools that you can use to identify the information you
need to begin developing forms.
In the Case Project , you are presented with the Great State Budgeting System, which comprises a series of applications that you
build piece by piece throughout the book for practice with Forms Builder. At the end of this part, you are asked to identify the
forms needed for the system and the data processed by each form. To develop an Oracle Forms system, a wide range of skills is
needed, and each part of this tutorial builds up your skills.
INTEGRATION OF ORACLE FORMS BUILDER INTO THE SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)
System development projects go through a series of phases, starting with project identification and ending with
implementation and system use.These phases are called the system development life cycle and are outlined below:







Project identification and selection
Project initiation and planning
Analysis
Logical design
Physical design
Implementation
Maintenance
This list of phases represents the traditional approach to system development. A subset of the SDLC, called rapid application
development (RAD), is often used to eliminate some traditional tasks and thereby speed up the implementation of the system.
Forms Builder can be used to support both the traditional SDLC methodology and RAD. For example, during the physical design
phase of a project, the analyst confirms user requirements. One part of these requirements is the design of the forms used
within the system. Forms are the mechanisms that allow a user to interact with the database. A form enables the user to add
records to the database, modify existing records, delete records, retrieve records from the database, and view records.
Using a RAD approach, the developer can confirm requirements by showing the user a prototype, which is an early facsimile of
the final product. The purpose of the prototype is to give users a sample of the physical characteristics of the application they
will use when the system is implemented. Prototypes are especially important in the RAD approach. With the RAD approach,
developers and users create, analyze, and modify prototypes in a series of iterations until the design is approved. With the
refinement of the prototype in each iteration, the prototype moves closer to its final form. The RAD approach allows the
physical design and implementation phases to be combined to reduce the overall implementation time.
Oracle’s Forms Builder is a RAD tool that supports the iterative prototyping of forms. Forms Builder contains a wizard that allows
you to easily and quickly identify attributes that are to appear on the form. Forms Builder has another wizard that allows you to
give the form a basic format. The Forms Builder Layout Editor can then be used to refine the form. Another important feature of
Forms Builder is that the wizard generates the code needed to retrieve records to the form, and it inserts, updates, and deletes
1
records as well. In essence, a developer can easily create and give the user a basic working prototype within thirty minutes and
thereby significantly help the analyst during the physical design phase of the project.
Forms Builder also supports the use of Oracle’s Designer 91 computer-aided software engineering (CASE) tools. The CASE tools
offer the developer a formal methodology of design and development. They also offer the developer a wide array of tools used
to document requirements and design the final application. Several of these tools are discussed in this chapter.
Designer 91 is a code generator and creates a Forms Builder design module as the last step of the design process. Forms Builder
is then used to finalize the application behavior and generate the executable code. The executable code is then tested and
placed into production. The following Figure illustrates the various SDLC phases and shows when Designer 91 and Forms Builder
91 are used.
If developers choose a methodology that does not use the CASE design tools, they can still use Forms Builder. To work
with Forms Builder without CASE, developers simply create and implement the Oracle database schema, which
comprises the tables that model the system entities. Then developing Forms Builder modules begins. Regardless of the
approach, developers need to gather the following information before creating the forms:





Database schema or design
List of forms to be created
Guidelines on how the forms are to be used to add, update, delete, and view data
Database schema attributes to be used on the form
Form - processing logic
It is possible for the developer to determine these requirements intuitively, but this approach is not reliable. It is safest
to use several traditional tools to determine the design. These tools are:



Data flow diagram (DFD): displays the flow of data through a system
Entity relationship diagram (ERD): groups and relates sets of attributes that were identified on the
data flow diagram
Database schema diagram (DSD): depicts the final database schema
The following sections of this part give you a brief overview of these tools. The tools help you identify the information
needed to set up the Oracle database and begin developing forms. At the completion of this chapter, you may not be an
expert with the tools, but you will have an idea of the information and tasks that must be completed before using Forms
Builder effectively. You are then presented with the analysis materials that help you understand the requirements for
the Case Project: the Great State Budgeting System.
2
Using Data Flow Diagrams to Identify Applications, Processes, and Data USING DATA FLOW DIAGRAMS TO
IDENTIFY APPLICATIONS, PROCESSES, AND DATA
A data flow diagram is the first tool that an analyst uses to document the results of the information-gathering effort
completed during the analysis phase of the SDLC. This section describes the following:
 What a data flow diagram depicts
 How data flow diagrams support the identification of forms
 How graphic symbols are used in data flow diagrams
Scoping Out the Big Picture
Data flow diagrams are useful at the start of a project to pose and answer basic questions about the system to be developed.
Before outlining the questions that data flow diagrams answer, it is useful to define a few key terms: Data is a fact with meaning
and is stored and created in a system. For example, the name John is a fact. When combined with the fact Palinski, it gains
pecific meaning—the name of a person. Systems and databases store sets of related facts. An entity is an item about which data
is kept. The entity consists of a variety of facts that describe it. A process creates, transforms, or uses data.
Data flow diagrams answer these questions:








How is data brought into the target system?
What are the system’s processes?
What data is needed by a process?
Where does the process data come from?
Where does the data transformed by the process go?
Where does data rest within the system?
What entities supply data to the system?
What entities receive data from the system?
Identifying Forms Needed
Data flow diagrams help the form developer identif,r the forms to be developed and the data needed by each form. Any process
on the data flow diagram that requires interaction with the user requires a form. Other processes will probably require a PL/SQL
(Oracle’s proprietary programming language) code block or stored procedures. A code block is a series of PL/SQL statements.
Stored procedures are code blocks that have names and are stored in the database. The data flow diagram also identifies the
data needed for the process and the data that leaves the process.
Identifying the Applications and the Database Schema
Data flow diagrams are one of the tools that can be developed in Oracle’s Designer 9i. However, the data flow diagram
can be developed by a variety of other tools, or even drawn by hand. For large and complex systems, it is most effective,
however, to use a CASE tool such as Designer 9i. Each automated tool and textbook has a slightly different version of the
diagram, but each employs the same concepts and is basically the same.
Diagram Symbols
The following figure shows the four symbols that are used in data flow diagrams, as listed here:

External entity (EEl): This symbol represents something outside the system that sends data into the system or
receives data from the system. External entities are called sources and sinks, depending on whether they send
or receive data from the system.
3



Process (EP1): This symbol represents work done by the system to store, modify, or move data. All forms are
associated to one or more processes.
Flow (Data Flow): This symbol represents the data that flows into or out of a process.
Data store (DS): This symbol represents data at rest. The attributes associated with these stores will be the basis
of the data model used in the system.
Example data flow diagram displaying four symbols
The Figure illustrates the four data flow diagram symbols.The depicted symbols are based on Oracle Designer 91. The following
points may help you understand the diagram:





The scope of the overall system is represented by the symbol labeled EP. Designer 91 calls this symbol a function, which
is really another name for a process. All functions or processes have a unique number. This function is number 2.
Systems are generally decomposed into subprocesses. Decomposition allows the developer to concentrate and
understand more granual parts of the system. The symbols EP1 and EP2 are also function (or process) symbols.
They represent the decomposition of function EP or 2. The sum of EPI and EP2 functionality is the same as the
functionality for EP. These function symbols are numbered 2.1 and 2.2.The numbers indicate that the functions are
subfunctions 1 and 2 of function 2. Function 2.1 and 2.2 may also be decomposed to a finer granularity. Decomposing
function 2.1 into three subfunctions would result in functions with numbers 2.1.1, 2.1.2, and 2.1.3. The number of the
latter function indicates that it is subfunction 3 for sub- function I of function 2. This numbering scheme allows a
developer to break down system functionality and retain easy-to-understand linkages between functions that are
represented on numerous diagrams.
External entities are represented by ovals or circles with the symbols EEl and EE2.The symbols are outside function 2,
because they are external to the system. Symbol EEl can also be called a source, because it is sending data into the
system. Symbol EE2 receives data from the system. Another name for this object is sink.
Data stores are represented by an open rectangle with a rounded end and the symbol DS.
Arrows represent data flows. Data flows represent attributes that are going
into or leaving a process, data store, or external entity. All data going into or leaving a process must be associated to a
4
data flow.
The previous figure does not represent an actual system but does illustrate how to read a data flow diagram. The following list
describes the actions represented in the diagram:
 External entity EE 1 sends data, represented by flow Data Flow 1, into the system.
 Function 2.1 receives the data represented by Data Flow 1. The function performs work on the incoming data and sends
a set of data represented by Data Flow 2 to data store DS.
 Function 2.2 retrieves data from data store DS. This data is represented by Data Flow 3.
 Function 2.2 performs work on the data and sends data out of the system to external entity EE2. This data is represented
by Data Flow 4.
Among other functions, data flow diagrams identify the forms and the data used or produced by the form. Analyzing a data flow
diagram’s processes provides this information, because a form is always associated to a process. Any process that requires
human interaction requires a form. Processes receiving or sending data to external entities probably require a form, especially if
the process records the incoming data in the database. The majority of the data enters a system through some type of online
transaction. This transaction could be a bar scan, a sale logged by a supermarket scanner, a form operated on a workstation, a
form on the Web, or a form on a personal digital assistant. When you
Identifying the Applications and the Database Schema
review the data flow diagram to determine the processes that require human interaction, the forms that are needed
become evident. Processes that do not require a form are either a PL/SQL procedure or a process that creates a report
using a tool, such as Oracle Reports Builder.
In the case of the data flow diagram shown in Figure 1-3, process 2.1 probably requires a form, because it receives data
from external entity EEl. Process 2.2 may also require a form. This depends on several things:



Is the external entity EE2 a human or is it another system or external data store?
If external entity EE2 is a human, does Data Flow 4 represent a report?
If external entity EE2 is a human and Data Flow 4 is not a report, a form is needed.
The next task is to identify the data needed by he form. Data needs are determined by analyzing the data flows of the
process. When analyzing the data flows, you can use the following principles to determine the data:
 Forms used to receive data from an external entity must contain input areas for each of the data elements
represented by an incoming data flow.
 Data received from a data store is displayed on the form if it is used for supplemental information or is to be
modified. A description of a code value is an example of this type of data.
Data received from a data store that is used only for processing or calculations may not appear on the form.
 Data sent from a process that did not come into the process through a data flow is a calculated value. This data
may or may not be displayed, but the form needs to have processes that create this data for the outgoing flows.
Through analyzing the data flow diagram, you have identified the forms and the data needed by the forms.The next task
is to design or identify the database schema that stores the data while it is in the system. This is done using entity
relationship diagrams, which are covered in the next part.
USING ENTITY RELATIONSHIP DIAGRAMS TO INITIATE THE DESIGN OF THE DATABASE
SCHEMA
An entity relationship diagram is an analysis tool that is used to group related data. In the previous section, you saw
that data flows in data flow diagrams identify the data needed or produced by a process. The data flow only indicates
5
the needed elements and does not indicate how data is stored in the database.
Data flow diagrams also contain data stores that represent data at rest. A data store can be used to identify the stored
data elements, but it does not identify the database structure or how the data is grouped. The database schema
specifications are initially determined by the preparation of an entity relationship diagram.The developer can then use
this tool to understand and begin the database design. It is important to have a good database design, because the
database is the foundation of any system. This section describes the following:




Symbols used in entity relationship diagrams
Properties of identifiers and primary keys
Relationships between entities
Documenting the attributes that describe an entity
Understanding the Entity Relationship Diagram Symbology
Entity relationship diagrams identify entitie and their relationships to each other. An entity is something about which data is
kept. Entities are real—world objects, such as cars, the moon, students, or courses. Each occurrence of an entity is called an
instance. An example of an instance of the entity “STUDENT” is my son, Matthew. Databases store entity attributes. These
attributes describe or model the entity. Examples of attributes for my son, Matthew, are his name, social security number,
enrollment date, GPA, and courses taken.
Database design begins with the process of associating the data flow elements to the entity they model. A typical system
database is composed of the following three types of entities:
 Regular entities (such as a university, student, or course): A regular entity can exist without the existence of another
entity. The existence of a student or course does not rely on any other entity.
 Weak entities (such as a student parking ticket):Weak entities require the existence of another entity A parking ticket
cannot be issued to a student unless the student instance exists.
 Associative entities or gerunds (such as the courses taken by a student):
These types of entities associate instances of several entities. They may also have data elements associated to them. The
COURSES TAKEN entity is an example of an associative entity. It is a linkage between a student and the courses offered.
The COURSES TAKEN entity is related to both the STUDENT and COURSES TAKEN entities. Examples of attributes
associated to the associative entity, COURSES TAKEN, include STUDENT_ID, COURSE_ID, and GRADE.
A form often contains a mixture of data from regular, weak, and associative entities. The regular entities display data attributes
that are unique to the entity instance. The weak and associative entities supply repeating sets of data for every occurrence of
the regular entity Forms Builder displays the regular entities in a form component called master data block. Forms Builder
displays the weak and associative entities in a component called detail data block. By analyzing the entity relationship diagram,
developers determine which entities to display on the form and the type of data block to use.
Determining Identifiers and Primary Keys
Each entity must have one or more attributes whose values make that entity instance unique from any Other entity instance.
These attributes are called identifiers. Examples of identifiers are student IDs, social security numbers, or vehicle, identification
numbers. Identifiers are also called primary keys. An attribute is an identifier if it has these properties:
 The identifier or primary key value is unique across all entity instances.
 The identifier value or primary key does not change throughout the life of the entity.
 The instance identifier or primary key always contains a value. This property is called NOT NULL, which means not blank.
Regular entities should have an identifier or primary key composed of a single attribute. Weak entities normally have primary
keys composed of two attributes. One of these attributes is the identifier attribute of the parent entity. This attribute is called a
foreign key and is needed to associate the weak entity instance to an instance of its regular entity parent. Associative entities
6
require the primary key attribute from each of the entities that it associates as part of its own primary key. Primary keys that
comprise two or more attributes are called composite keys.
As a form developer, you must be able to identify the primary and foreign keys. Forms Builder creates code using these values to
ensure that the records in detail data blocks pertain to the same master data block instance. Analyzing an entity relationship
diagram enables you to identify the primary and foreign keys before creating master and detail data blocks in Forms Builder.
Understanding Entity Relationships
Entities can be related to each other and even to themselves, and these relationships are important, because they are the paths
to the database attributes. Relational databases, such as Oracle, are composed of related tables. Entities become tables as the
design moves from logical to physical stages. Desired attributes are almost always contained in multiple tables. As a developer,
you will have to locate and access these attributes from the various tables. You will need to know if entities are related and the
keys that relate the attributes.
STUDENT
STUDENT_ID
NAME
ENROLLMENT_DATE
COURSES TAKEN
STUDENT_ID
OFFERING_ID
GRADE
COURSES OFFERED
OFFERI NC_ID
COURSE_ID
LOCATION
The previous figure illustrates the importance of relationships. Assume that your database has the three entities depicted in the
figure: STUDENT, COURSES TAKEN, and COURSES OFFERED. A student can and probably does take courses. There is a
relationship between the entities STUDENT and COURSES TAKEN. The regular entity, COURSES OFFERED, is also related to the
associative entity, COURSES TAKEN.The three entities are related through the COURSES TAKEN entity.
If the information needed by the developer consists of the student name, course location, and the grade, the information must
come from all three entities. An entity relationship diagram depicting the entities and relationships confiuins that it is possible to
retrieve this information. A line is displayed between the related entities. The developer can also determine the primary and
foreign keys. Looking at Figure 1-4, you should be able to see that a STUDENT instance can be related to the COURSES TAKEN
entity by common STUDENT_ID values. The COURSES OFFERED entity is related to the COURSES TAKEN entity by common
OFFERING_IDs. Thus, all of the desired attributes can be accessed by relating an instance in the STUDENT entity to instances in
the COURSES TAKEN entity and these related instances to instances in the COURSES OFFERED entity.
Understanding entity relationships also helps you to design more effective applications. Databases often contain descriptive
tables. These tables are used to describe codes or other nondescriptive values, such as a course number. These kinds of tables
support the list of values or pick lists that you create on your forms. For example, the COURSES TAKEN data requires the user to
enter an OFFERING_ID. It is much easier to enter this value if the user can pick out the OFFERING_ID from a list that contains the
course name and course number. Related entities can always be used as the source of values for the list of values and pick lists
on a form, and following the relationships in an entity relationship drawing helps you to identify these opportunities.
Relationship Types
Entity relationship diagrams show three basic types of relationships:


Unary: The entity is related to itself. An instance of a course that requires a prerequisite is an example of this
relationship. Because the prerequisite is another COURSE instance, the entity’s relationship is to itself. This type of
relationship means that one of the attributes is a foreign key related to a primary key value in another instance.
Binary: The entity is related to one other entity. This most common type of relationship means one of the entities
contains a foreign key that relates it to the other entity.
7

N—ary: Multiple entities are related to each other.
A line drawn between the entities symbolizes the relationship. In addition, text is placed at either end of the relationship to
describe how the entities are related. The following figure 1—5 illustrates several entities in unary and binary relationships. The
figure was created in Designer 91 and is representative of this tool’s symbols.
Oracle Designer depictions of unary and binary relationships
Cardinality and Ordinality
Relationships contain two important properties called cardinality and ordinality. Cardinality identifies the number of instances
that a related entity can have. For example, a student can take many different courses. The cardinality of the STUDENT entity to
the COURSES TAKEN entity is many. Cardinality is a property that exists on both sides of the relationship. You have seen the
cardinality identified from the STUDENT to the COURSES TAKEN entities. The cardinality from the COURSES TAKEN (by a student)
entity to the STUDENT is one. A specific course can only be taken once by a student; the student cannot enroll in the same
course twice.
Understanding the cardinality of a relationship is important to the form developer, because cardinality determines which of the
entities will be used in a master data block and which will be in the detail data block. Master data block is a Forms Builder term
that indicates the parent or controlling set of records. The entity with a cardinality of one, such as STUDENT, is the master data
block in a form. The entity with a cardinality of many is the detail data block. Detail data blocks normally display multiple
instances of a related entity for each occurrence of the parent entity in the master data block. The COURSES TAKEN entity is in
the detail data block, and multiple instances of the entity are likely to be displayed for each STUDENT instance.
The second relationship property, ordinality, describes whether the related instance is mandatory. For example, can a COURSES
TAKEN entity instance exist without a related STUDENT instance? The answer is no. You must have a STUDENT instance before
you can have a COURSES TAKEN instance. Thus the ordinality property is mandatory. Ordinality also exists on both sides of the
relationship. A STUDENT entity instance can exist without a COURSES TAKEN instance, as is the case if the student hasn’t
registered yet. Thus the ordinality of this relationship is optional.
Cardinality and ordinality can be represented in the entity relationship diagram by several methods of textual and graphical
notation. The following figure illustrates the various graphical notations used by Designer 9i and described as follows:
8
Oracle Designer relationship symbols
Entity Attributes and Properties
An entity relationship diagram is the first tool to use when designing a database, because the entity relationship drawing groups
attributes. The attributes describe or model an entity. As part of the process, the developer must document these attributes and
their characteristics. The following figure depicts a Designer 9i dialog box that contains attributes for an entity in a typical
system, a transformer. A transformer is an electrical device that changes electrical voltage. The figure illustrates the Designer 91
dialog box that is used to record the attributes. Properties that are identified in this dialog box are representative of those that
you would document in any entity relationship diagram.
9
Oracle Designer relationship diagram dialog box used for entry of attributes and
properties
The properties depicted in the figure 1-7 are:
 Name: This is the name of the entity attribute.
 Optional (Opt):This property indicates whether a value must always exist in the attribute. Attributes
that must always contain a value are considered NOT NULL. As a form developer, you must ensure that
this property is respected and enforced.
 Format:This property describes how the attribute is stored in the database. Example formats are
CHAR,VARCHAR2, DATE, or NUMBER.
 MaxLen: This property sets the size of the attribute.
Dec: This is the number of decimal positions.
 Primary: This attribute is part of the primary key.
Properties that pertain to domains are also important to form developers. These properties specify the types of values
that can be placed into the form data item. The following figure displays a second panel of the dialog box for the KVA
transformer item. It is used to record the following properties:




Value: the lowest value that can be placed in this attribute
High Value: the maximum value that can be placed in this attribute
Abbreviation: a shortened version of the attribute name
Meaning: a description of the attribute

10
Designer entity relationship diagram dialog box used for entry of range values
To create a form, you must know the entity characteristics shown in two previous figures. Forms contain text items that
display the entity attributes. The developer must know the data type and length of the attribute, because the text item
must have the same properties. The developer must also ensure that proper values are entered into the text item. This
requires information about the range, which can be determined from the entity relationship diagram. If you are using
Designer 9i to create these items, this information is transferred to the database schema and to the Forms Builder form.
If you are not using Designer 9i, this information must be identified, incorporated into the database schema, and then
transferred to Forms Builder.
The following figure depicts a completed entity relationship diagram for TRANSFORMER and TRANSFORMER_TEST
entities. The diagram was prepared in Designer 9i. The entities are related in a one-to-many relationship that is either
mandatory or optional. The following are descriptions of the symbols that are shown in the diagram and are associated
with the attributes:
 #: an attribute that is the identifier (or primary key)
 *: a value that is mandatory for the attribute
 0: a value that is optional for the attribute
11
Entity relationship diagram of the TRANSFORMER and
TRANSFORMER_TEST entities
You may have noticed that the foreign key (SERIAL_NUMBER) attribute is not shown in the TRANSFORMER_TEST entity
Foreign keys are not shown on entity relationship diagrams, and this is one of the reasons why this is not the preferred
tool. The preferred tool is the data schema diagram discussed later in this part.
Associating Entities and Attributes to a Data Flow
The processes of a data flow diagram identify a system form, and the data flows identify the data that is needed by that
form. The form’s data attributes are stored in an Oracle table. This table is related to an entity in the entity relationship
diagram. You should associate data flows with entities in the analysis phase, so that you can identify the proper tables to
use when in Forms Builder. Designer 9i has a data flow diagram dialog box that associates entities (and attribute4s) to a
particular data flow. This dialog is illustrated in the following Figure.
Oracle Designer dialog box used to associate entities and attributes to a data flow
12
Designer 91 Entity Relationship Diagram Dialog Box Used for Entry of Attributes and Properties
Some entity relationship diagrams may not correspond exactly to the database schema, because the entities
have not been normalized. Normalization is a process used to design an efficient and flexible database. If you
develop the entity relationship diagram in Designer 9i, it will conform fairly closely to the database schema,
because Designer 9i pushes the developer to normalize the entities. If you are using a different tool or
preparing the entity relationship drawing on paper, exercises called relational modeling and normalization
may need to be applied to the entities before the database objects can be created. The result of this pplication
is an efficient relational database schema that can be used to create the Oracle database. The developer or
database administrator can then create the database objects from the schema.
Because Designer 91 entity relationship diagrams are closely related to the database schema, it is important to
perform the normalization during the creation of the entity relationship drawing, since Designer 91 takes the
entities and relationships and designs the schema. It also writes the data definition language (DDL)
commands used to create the database objects. After Designer 91 creates the database schema, a data
schema diagram is available to the developer. It turns the entities and attributes into tables and columns.
Tables are the objects that physically store data in the database. Columns identify the particular values stored
in the table. The data schema diagram is the best tool available for understanding the tables in a database and
is more valuable than the entity relationship diagram in the following ways:



The data schema diagram shows foreign keys; entity relationship drawings do not. Foreign keys are implied by
the relationships. The primary key of the parent entity is a foreign key in the child entity.
The relationship description contains the name of the foreign key constraint placed on the parent table. A
foreign key constraint is a database feature that ensures weak entity instances, such as TRANSFORMER_TEST,
will not exist without a related TRANSFORMER entity instance.
The data schema diagram displays the actual database colunm names. The names used in the entity relationship
diagram may not relate exactly to the column name.
The data schema diagram displays the attribute format.
The following figure illustrates a data schema diagram based on the TRANSFORMER and TRANSFORMER_TEST entities.
This diagram was generated using Designer 9i and can be used to create the tables that compose the database. It is also
the most effective tool available for understanding the database for which you will create forms.
13
How FORMS BUILDER USES ORACLE 91 DATABASE
After understanding, designing, and creating the Oracle database, you are ready to begin using Forms Builder. Forms
Builder is tightly integrated with the Oracle database. You have seen that data flow diagrams identify the forms, entities,
and attributes that appe.ar on the form. The entity relationship diagram or the data schema diagram indicates the
relationships between entities. The relationship and data characteristic information is passed to Forms Builder through
its wizards. This means that the form developer does not have to specify the data properties. Forms Builder determines
this information from the database by performing the following tasks:
 Gives all form items their names based upon the database table
 Sets the data type and length of all data items based on the database table
 Ensures any text item related to a NOT NULL constrained column always contains a value by setting a form text
item property to “Required”
 Identifies matching primary and foreign key columns when creating master and detail data blocks
As you will see in the next chapter, simply by specifying the tables and columns that appear on the form, you give the
form a great deal of functionality.This gives the developer a significant head start on the development of a system.
WHERE You ARE AND WHERE YOU’RE GOING
This chapter briefly reviewed the system development life cycle and explained how Oracle’s Forms Builder tool set fits
within this life cycle. It also showed you how data flow diagrams are used to identify applications, processes, and the
data. You were introduced to entity relationship diagrams and to the data schema diagrams. You finish this chapter
understanding generally how Forms Builder uses the Oracle9i database.
The next chapter begins the coverage of Forms Builder itself by introducing you to the Forms Builder products that are
used to build and execute a form.You also learn how to use wizards to create a simple form. The last part of the chapter
shows you how to retrieve records into the form and perform data manipulation language (DML) operations.
PART SUMMARY


Forms Builder supports the system development life cycle and allows the developer to prototype forms during
the analysis phase. Forms Builder also creates the final system forms during the implementation phase.
Forms Builder is used to complete and implement the design produced in Oracle’s Designer 91 CASE tools.
14