CHAPTER 9
Creating Business Domain
Components
1
Creating Business Domain Components
In this chapter we will learn how to:
• Create entity object definitions from tables
• Edit entity object definitions to delete entity attributes
representing database columns you do not need
• Add transient entity attributes to represent calculated fields
• Represent PRIMARY KEY and NOT NULL constraints.
You will create, modify, and test business domain
components to the HR schema in the hands-on exercise
2
Creating Default Business Domain Components
The first step in building a database application is representing the data
itself. This chapter covers the use of entity objects as representations of
units of data.
As we already know:
• An entity object is the representation of a database table or view.
• An entity object has one or more entity attributes representing
columns in a table or view.
• The Java types of the entity attributes are classes corresponding to
the SQL types of the columns, and some entity attributes are
mapped to a particular Java class called "domains".
• Associated with each entity object is a Java file with code logic and
an XML file with the definition of the entity, including its
attributes.
3
Adding and Deleting Entity Attributes
Usually there will be a one-to-one mapping between the columns in a
table and the attributes in the corresponding entity object. There are
some exceptions however where attributes may need to be deleted or
added:
• The table may have columns that you know your business logic will
never use. The entity attributes corresponding to these columns are
just wasting memory, so you may want to delete them.
• You may want to have transient attributes. These are attributes
you calculate or set on a particular row that are needed for the
duration of the transaction, but are not stored in the database (must
be added).
• You may want to add or delete attributes if the database table
changes to include a new column or to drop an old column.
4
Changing Datatypes
Each database column (with its datatype) is mapped to an entity attribute
(with Java type). There are some restrictions on which Java types can
correspond to particular SQL datatypes, but there is also some flexibility
(see table below).
JDeveloper will select the default Java type appropriate to the database
column datatype, but you can change it to any acceptable Java types
below.
5
Changing Datatypes (continued)
Common Type Mappings:
SQL Datatypes
Acceptable Java Types
NUMBER
Number, Boolean, Integer,
BigDecimal, String
TINYINT, SMALLINT, INTEGER,
BIGINT, INT, REAL, DOUBLE,
FLOAT, DECIMAL, NUMERIC, BIT
Number, String
VARCHAR2, NVARCHAR2, CHAR,
VARCHAR, LONG
String, Char, Character
TIMESTAMP
Date
RAW, LONG RAW
Date, Timestamp
CLOB
ClobDomain
BLOB
BlobDomain
BFILE
BFileDomain
STRUCT
Object
ARRAY, VARRAY
Array
REF
Ref
ROWID
Object
6
Changing Datatypes (continued)
The Entity Object Editor can be used to change attribute settings:
Java
Type
Database
Data Type
Database
Column Name
7
Changing Datatypes (continued)
If you want to create ADF BC objects that use a nonOracle database, you will have to use a separate type
map to associate datatypes with Java types – either
JDeveloper's "Java" type map or a type map you create
(more on this in the online help system).
8
Representing Column Constraints
Databases like Oracle have five constraints that can be applied to
columns:
• PRIMARY KEY
• NOT NULL
• UNIQUE
(discussed in a later chapter)
• FOREIGN KEY
(represented by associations)
• CHECK
(discussed in a later chapter)
The constraints are represented in the XML for an attribute.
9
NOT NULL constraints
When an entity object from a table is created, JDeveloper determines
whether any of the columns in the table has a primary key or NOT
NULL constraint. If either is has been defined, JDeveloper automatically
generates the corresponding XML code.
The reason ADF BC allows NOT NULL constraints in entity objects is
performance. ADF BC saves up user changes until a post or commit is
requested. By representing the NOT NULL constraints in the entity
objects (instead of the database) ADF BC can verify the constraints are
satisfied without making a round trip to the database.
10
PRIMARY KEY constraints
The reason ADF BC represents the PRIMAY KEY constraint in entity
objects is different. ADF BC uses entity attributes tagged as part of the
primary key to look up particular instances of the entity object class.
Without primary key attributes, ADF BC has no way of distinguishing
between different entity instances.
If the table has no primary key, JDeveloper creates a RowId entity
attribute, based on the pseudo-column ROW_ID, of the type
oracle.jbo.domain.RowId, and use it as a primary key.
If you want to use ADF BC to access a
non-Oracle database, you must ensure
that all of your tables have primary keys.
11
Additional constraints
You may want to define constraints in an entity that do not correspond
to any database constraint, if the following conditions hold:
• You do not change your database tables, and new a new constraint.
• You need a constraint but you do not have permission to perform
DDL operations to change the table.
• The constraint applies only to your applications; other applications
using the same tables do not need it.
12
Additional constraints (continued)
You also might want to represent a column constraint that has been
added to a database table since you created the corresponding entity
object. This is done as follows:
• On the entity object node select Edit from the right-click menu.
• Select the Attribute Settings node.
• Choose an attribute from the Select Attribute dropdown.
• To make the attribute NOT NULL, check the Mandatory
checkbox.
• To make the attribute part of the primary key, check the Primary
Key checkbox. If this is checked for multiple attributes, they will
function as a multi-part key.
13
Synchronizing Entity Objects with the Database
In addition to manually adding and dropping attributes or constraints,
JDeveloper can be used to automatically synchronize some or all of the
entity objects with the Database.
On the ADF BC package node in the Navigator, select Synchronize
with Database from the right-click menu and use this dialog to select
any desired updates to the ADF BC tier.
14
Representing Relationships Between Tables
Foreign key relationships between tables are represented by associations
between entity objects. JD will create an association corresponding to
each foreign key constraint that occurs between tables you select. You
may want to define associations that do not correspond to any foreign
key constraint, if one of the following conditions hold:
• You need a relationship but do not have permission to perform
DDL operations to change the table
• The relationship applies only to your applications; other
applications using the same tables do not need it
• The relationship involves transient entity attributes
• The relationship is a many-to-many relationship (explained next)
Associations will be created in the hands-on practice
15
Association Cardinality
The most common kind of relationship between tables is the one
represented by a foreign key: a row in the master table corresponds to
any number of rows from a detail table. This is a one-to-many
relationship illustrated below:
16
Association Cardinality (continued)
Another is a one-to-one relationship illustrated below:
17
Association Cardinality (continued)
The most complex is a many-to-many relationship where any number of
rows from one table can be related to any number of rows from the
detail table. This relationship is illustrated below:
JDeveloper lets you create one-to-many, one-to-one, and many-to-many
associations.
18
Association Cardinality (continued)
Creating a many-to-many association is more complex because it makes
use of a third table called an intersection table. An intersection table
contains two foreign keys. One matches up with the primary key of one
table and the other with the primary key of the other table as illustrated
below:
19
Association Cardinality (continued)
Two 1-to-many relationships are created. You can think as these two
one-to-many relationships as representing a single many-to-many
relationship, which relates one row from EMPLOYEES and JOBS if
they share a JOB_HISTORY detail as shown below:
20
Compositions
Consider two different sorts of foreign key relationships:
1. The relationship between employees and the departments that
employ them.
2. The relationship between line items in a purchase order and the
order itself.
Most employees are in a department, but an employee is not, strictly
speaking, part of a department. Employees exist independently of their
departments; a company can eliminate a department without eliminating
its members. By contrast, it makes no sense to delete a purchase order
without deleting its line items.
An association is like the one between line items and purchase orders,
where the detail is part of the master, is called a composition. You
cannot delete a master in a composition without deleting all its details.
21
Compositions (continued)
If the Business Components Package Wizard detects that a database
foreign key has ON DELETE CLAUSE set, it automatically creates
the association as a composition. This can also be done on the
Association Properties page of the Association Wizard when you
create or edit an association checking the Composition Associations
checkbox as shown next.
22
Compositions (continued)
23
Compositions (continued)
• Optimize for Database Cascade Delete – prevents the application
from issuing explicit DML commands to delete detail rows when the
master row is deleted. If the database is doing this automatically
(because ON DELETE CASCADE is set), efficiency is improved.
• Implement Cascade Delete - deletes detail entity object instances
when the master is deleted. This checkbox is checked automatically.
If it is unchecked, deleting a master that still has details with throw
an exception.
• Cascade Update Key Attributes – makes destination attributes stay
synchronized with source attributes.
24
Representing Oracle Data Types
ADF BC automatically associates standard column types with Java
classes (like java.lang.String) or built-in domains (such as
oracle.jbo.domain.Number). Some columns many be custom Oracle
object types. Custom Oracle object types are represented as domains.
When you create an entity object based on a table with an Oracle object
type column, JDeveloper automatically creates a custom domain and
maps the column to an entity attribute with that domain as its Java type.
25
Representing Oracle Data Types
Consider an Oracle object type called ADDRESS_TYP with the
following definition:
CREATE TYPE ADDRESS_TYP AS OBJECT
(STREET_ADDRESS VARCHAR2(20),
POSTAL_CODE VARCHAR2(12),
CITY VARCHAR2(30).
STATE_PROVINCE VARCHAR2(25),
COUNTRY_ID VARCHAR2(2) );
You could create a table called CUSTOMERS that uses this object
type as follows:
CREATE TABLE CUSTOMERS
( CUSTOMER_ID NUMBER(6),
CUST_FIRST_NAME VARCHAR2(20),
CUST_LAST_NAME VARCHAR2(20),
CUST_ADDRESS ADDRESS_TYP );
26
Representing Oracle Data Types
If you create an entity object from the table, it will have attributes called
CustomerId, CustFirstName, CustLastName, and CustAddress,
and automatically a domain, AddressTyp, with attributes
StreetAddress, PostalCode, City, StateProvince, and CountryId.
On the other hand, a table called ADDRESSES can be created as
follows:
CREATE TABLE ADDRESSES OF ADDRESS_TYP;
If you then create an entity object from ADDRESSES, it will have
attributes called StreetAddress, PostalCode, City, StateProvince,
and CountryId, and NO domain will be created.
27
Business Components and Database Object Generation
If you create an entity object from the table, it will have attributes called
CustomerId, CustFirstName, CustLastName, and CustAddress,
and automatically a domain, AddressTyp, with attributes
StreetAddress, PostalCode, City, StateProvince, and CountryId.
On the other hand, a table called ADDRESSES can be created as
follows:
CREATE TABLE ADDRESSES OF ADDRESS_TYP;
If you then create an entity object from ADDRESSES, it will have
attributes called StreetAddress, PostalCode, City, StateProvince,
and CountryId, and NO domain will be created.
28
Business Components and Database Object Generation
If you create an entity object from the table, it will have attributes called
CustomerId, CustFirstName, CustLastName, and CustAddress,
and automatically a domain, AddressTyp, with attributes
StreetAddress, PostalCode, City, StateProvince, and CountryId.
On the other hand, a table called ADDRESSES can be created as
follows:
CREATE TABLE ADDRESSES OF ADDRESS_TYP;
If you then create an entity object from ADDRESSES, it will have
attributes called StreetAddress, PostalCode, City, StateProvince,
and CountryId, and NO domain will be created.
29
Creating Entity Object Definitions for Table Generation
When you create an ADF BC diagram, the Component Palette displays
a list of business components (next slide).
You can create a new entity object definition by clicking the Entity
Object icon, and then clicking your diagram. You can name the entity
and list its attributes directly in the diagram.
You will do this in the hands-on practice.
30
Creating Entity Object Definitions for Table Generation
31
Creating Entity Object Definitions for Table Generation
The table names generated by JD follow these conventions:
• An entity object definition name EmployeeBonuses will
correspond to a table named EMPLOYEE_BONUSES.
• An entity attribute named EmployeeId will correspond to a table
column named EMPLOYEE_ID.
32
Creating Entity Object Definitions for Table Generation
To change the name of the table, you can use the Name page of the
Entity Object Editor shown below:
33
Creating Table Constraints for Generarion
You can create the following types of database constraints by editing the
entity object definition:
• Primary Key – By default, JD will make the first attribute you
type in the diagram the sole component of the primary key, but
you can add other attributes to the primary key.
• Not Null
• Unique – If the constraint applies to a single column.
34