Design and Development MethodologyIdentifying 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.

4

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 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

5

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 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.

6

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 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 COURSES TAKEN COURSES OFFERED STUDENT_ID STUDENT_ID OFFERI NC_ID NAME OFFERING_ID COURSE_ID ENROLLMENT_DATE GRADE 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:

7

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.

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.

8

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:

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

15