This chapter discusses how to develop entity-to-entity relationships. As a developer, you can approach entity relationships from either the EJB development or database development viewpoint. Show
This chapter starts by discussing entity relationships from the EJB development viewpoint. Next, it demonstrates how the deployment descriptor maps to database tables. If you want to design with the database development viewpoint, skip to "Mapping Relationship Fields to the Database". This chapter covers the following topics:
Defining Entity-To-Entity RelationshipsThe following sections describe what an entity bean relationship can be and how to define them.
Choosing Cardinality and DirectionCardinality refers to the number of entity objects on each side of the relationship. Thus, you can define the following types of relationship between EJBs:
In addition, each relationship can be one-way or two-way. This is referred to as the direction of the relationship. The one-way relationship is unidirectional; the two-way relationship is bidirectional. For example, a unidirectional relationship can be from an employee to an address. With the employee information, you can retrieve an address. However, with an address, you cannot retrieve the employee. An example of a bidirectional relationship is with a employee/projects example. Given a project number, you can retrieve the employees working on the project. Given an employee number, you can retrieve all projects that the employee is working on. Thus, the relationship is valid in both directions. Normally, you use a unidirectional relationship when you want to reuse the target from multiple entities. You define the cardinality and direction of the relationship between two beans in the deployment descriptor. One-To-One Relationship OverviewA one-to-one relationship is the simplest relationship between two beans. One entity bean relates only to one other entity bean. If our company office contains only cubicles, and only a single employee can sit in each cubicle, then you have a one-to-one relationship: one employee in one designated cubicle. You define a unidirectional definition for this relationship as follows: employee --> cubicle However, if you have a cubicle number and want to determine who is assigned to it, you can assign a bidirectional relationship. This would enable you to retrieve the employee and find what cubicle he/she sits in. In addition, you could retrieve the cubicle number and determine who sits there. You define this bidirectional one-to-one relationship as follows: employee <--> cubicle One-To-Many or Many-To-One Relationship OverviewIn a one-to-many relationship, one object can reference several instances of another. A many-to-one relationship is when many objects reference a single object. For example, an employee can have multiple addresses: a home address and an office address. If you define these relationships as unidirectional from the perspective of the employee, then you can look up the employee and see all of his/her addresses, but you cannot look up an address to see who lives there. However, if you define this relationship as bidirectional, then you can look up any address and see who lives there. Many-To-Many Relationship OverviewA many-to-many relationship is complex. For example, each employee can be working on several projects. And each projects has multiple employees working on it. Thus, you have a many-to-many cardinality. The direction does not matter in this instance. You have the following cardinality: employees <--> projects In a many-to-many relationship, many objects can reference many objects. This cardinality is the most difficult to manage. Defining RelationshipsHere are the restrictions imposed on defining your relationships:
The following are the requirements to define each cardinality type and its direction:
Define the Get/Set Methods for Each Relationship Field Each relationship field must have the abstract accessor methods defined for it. In a relationship that sets or retrieves only a single entity, the object type passed back and forth must be the local
interface of the target entity bean. In a relationship that sets or retrieves multiple objects, the object type passed back and forth is a Example 4-1 Definition of Abstract Accessor Methods for the Employee ExampleIn this example, the employee can have only a single address, and you can retrieve the address only through the employee. This defines a one-to-one relationship that is unidirectional from the perspective of the employee. Then the abstract accessor methods for the employee bean are as follows: public AddressLocal getAddress(); public void setAddress(AddressLocal address); Because the cardinality is one-to-one, the local interface of the address entity bean is the object type that is passed back and forth in the abstract accessor methods. The cardinality and direction of the relationship are defined in the deployment descriptor. Example 4-2 Definition of One-To-Many Abstract Accessor Methods If the employee example included a one-to-many relationship, the abstract accessor methods would pass back and forth a A department contains many employees. In this one-to-many example, the abstract accessor methods for the department
retrieves multiple employees. Thus, the abstract accessor methods pass a public Collection getDeptEmployees(); public void setDeptEmployees(Collection deptEmpl); Declare the Relationships in the Deployment Descriptor You define the relationships between entity beans in the same deployment descriptor the entity beans are declared. All entity-to-entity relationships are defined within the <relationships>
<ejb-relation>
...
</ejb-relation>
<ejb-relation>
...
</ejb-relation>
</relationships>
The following XML shows the full element structure for relationships: <relationships>
<ejb-relation>
<ejb-relation-name> </ejb-relation-name>
<ejb-relationship-role>
<ejb-relationship-role-name> </ejb-relationship-role-name>
<multiplicity> </multiplicity>
<relationship-role-source>
<ejb-name> </ejb-name>
</relationship-role-source>
<cmr-field>
<cmr-field-name> </cmr-field-name>
<cmr-field-type> </cmr-field-type>
</cmr-field>
</ejb-relationship-role>
</ejb-relation>
</relationships>
Table 4-1 describes the usage for each of these elements. Table 4-1 Description of Relationship Elements of the Deployment Descriptor These relationships can be one-to-one, one-to-many, or many-to-many. The cardinality is defined within the
The direction of the relationship is defined by the presence of the The following demonstrates how to declare direction in the one-to-one employee and address example:
Once you understand how to declare the cardinality and direction of the entity relationships, configuring the deployment descriptor for each relationship is simple. Example 4-3 One-To-One Relationship ExampleThe employee example defines a one-to-one unidirectional relationship in which each employee has only one address. This relationship is unidirectional because you can retrieve the address from the employee, but you cannot retrieve the employee from the address. Thus, the employee object has a relationship to the address object. In the deployment descriptor, you configure the following:
Decide Whether to Use the Cascade Delete OptionWhen you have relationships between entity beans and the master entity bean is deleted, what happens to the slave beans? This question is answered by the cascade delete option. If you specify cascade delete to happen, the deletion of a master entity causes the deletion of all its slave relationship entity beans. The cascade delete is defined in the object that is deleted automatically. For example, an employee has a relationship with an address object. The employee object specifies cascade delete. When the employee, as master in this relationship, is deleted, the address, the slave, is also deleted. In some instances, you do not want a cascade delete to occur. If you have a department that has a relationship with multiple employees within the department, you do not want all employees to be deleted when you delete the department. You can only specify a cascade delete on a relationship if the master entity bean has a The cascade delete is specified in the slave entity bean of the one-to-one or one-to-many relationship. Thus, when the master entity bean is deleted, the slave entity beans are deleted. Example 4-4 Cascade Delete Requested in the Employee Example The following deployment descriptor shows the definition of a one-to-one relationship with the employee and his/her address. When the employee is deleted, the slave entity bean--the address--is automatically deleted. You ensure the deletion by specifying the <relationships>
<ejb-relation>
<ejb-relation-name>Emp-Address</ejb-relation-name>
<ejb-relationship-role>
<ejb-Mapping Relationship Fields to the DatabaseEach entity bean maps to a table in the database. Each of its persistent and relationship fields are saved within a database table in columns. For these fields to be mapped to a database, do one of the following:
Default Mapping of Relationship Fields to the DatabaseNote: This section discusses how OC4J maps relationship fields to the database. Chapter 3, "CMP Entity Beans" discusses persistent field mapping. If you declare relationship fields only in the Note: For all future redeployments, copy the generated In summary, these defaults include:
Default Mapping of the One-To-One RelationshipThe one-to-one entity relationship is managed between the entity tables with a foreign key. Figure 4-1 demonstrates a one-to-one unidirectional relationship between the employee and address bean. Note: Normally, you use a unidirectional relationship when you want to reuse the target for multiple entities. To reuse a table in the database, the target table must have the same definition for all tables using it. The target table does not normally have a foreign key pointing back to any of the source tables. For this reason, when you reuse a table, it is normally the target of a unidirectional relationship.
Figure 4-1 One-To-One Employee Relationship Example Text description of the illustration ormapa.gif Default Mapping of One-To-Many and Many-To-Many RelationshipsYou cannot facilitate the one-to-many and many-to-many relationships using only a primary key and foreign key in the entity tables. To facilitate these relationships, the container creates an association table. The association table contains two columns, where each contains a foreign key to each of the entity tables in the relationship. Figure 4-2 shows the tables that are created for the employee/project relationship. Each project can have multiple employees, and each employee can belong to several projects. Thus, the employee and project relationship is a many-to-many relationship. The container creates three tables to manage this relationship: the employee table, the project table, and the association table for both of these tables. Figure 4-2 Many-To-Many Employee Relationship ExampleText description of the illustration ormap4.gif The association table contains a foreign key column that points to the employee table and a foreign key column that points to the project table. The column names of the association
table are a concatenation of the entity bean name in The following is a demonstration of the association table for the employee/projects relationship. Employee 1 is assigned to projects a, b, and c. Project a involves employees 1, 2, and 3. The association table contains the following:
The association table details all relationships between the two entity beans. Example 4-5 Deployment Descriptor for a Many-To-Many Relationship To configure the employee/project many-to-many relationship in the deployment description, create an <enterprise-beans>
<entity>
...
<ejb-name>The container maps this definition to the following:
Example 4-6 Deployment Descriptor for One-To-Many Bidirectional RelationshipThe following XML demonstrates how to configure a single employee who can have multiple phone numbers. You can add another source of the phone numbers table, such as department phone numbers, so that the department entity bean has a one-to-many relationship with the phone number entity bean. This is why the employee to phone numbers relationship is unidirectional. The employee entity bean, <relationships>
<ejb-relation>
<ejb-relation-name>Emp-Phone</ejb-relation-name>
<ejb-relationship-role>
<ejb-relationship-role-name>Emp-PhoneNumbers</ejb-relationship-role-name>
<multiplicity>The container maps this definition to the following:
Figure 4-3 One-To-Many Relationship Employee ExampleText description of the illustration ormap5.gif Explicit Mapping of Relationship Fields to the Database As "Default Mapping of Relationship Fields to the Database" discusses, your relationship fields can be automatically mapped
to the database tables by the container. However, if you do not want to accept the defaults that OC4J provides for you, then you can map the relationships between entity beans within an existing database table and its columns in the For explicit mapping, Oracle recommends that you perform the following steps:
How you map relationship fields is dependent on the type of relationship:
Modify elements and attributes of the The following XML shows the relevant elements and attributes for explicit mapping of a one-to-one relationship: <entity-deployment name=" " location=" " table=" " data-source=" "> The following XML illustrates the relevant elements and attributes for explicitly identifying the association table for one-to-many or many-to-many: <entity-deployment name=" " location=" " table=" " data-source=" "> Note: This section first describes in detail how logical names defined in the One-To-One Relationship Explicit MappingFigure 4-1 shows a one-to-one unidirectional relationship between an employee and an address. The employee table has a foreign key that points to the primary key of the employee. A one-to-one bidirectional relationship would add a foreign key to the address table that points to the employee. <enterprise-beans>
<entity>
...
<ejb-name> The <entity-deployment name="EmpBean" location="emp/EmpBean"wrapper="EmpHome_EntityHomeWrapper2" max-tx-retries="3" table="emp" data-source="jdbc/OracleDS"><primkey-mapping> <cmp-field-mapping name="empNo" persistence-name="empno" /> </primkey-mapping> <cmp-field-mapping name="empName" persistence-name="ename" /> <cmp-field-mapping name="salary" persistence-name="sal" /> This mapping specifies:
Figure 4-4 displays the relationship mapping of the Figure 4-4 Demonstration of Explicit Mapping for a One-To-One RelationshipText description of the illustration ormap3.gif In summary, an One-To-Many and Many-To-Many Relationship Explicit MappingFigure 4-3 shows a one-to-many unidirectional relationship between an employee and his/her phone numbers. Because this involves a "many" in the relationship, an association table is created. The association table is the same whether this is a unidirectional or bidirectional, or one-to-many or many-to-many relationship. In the
In the
Figure 4-5 Demonstration of Explicit Mapping for a One-To-Many RelationshipText description of the illustration ormap6.gif Option for the One-To-Many Explicit Bidirectional RelationshipYou can bypass an association table in the one-to-many bidirectional entity relationship. The "one" relationship has a primary key that points to the "many"; the "many" has a foreign key that points back. With both tables maintaining primary keys, and the "many" table maintaining a foreign key back to the "one" table, there is no need for an association table. Figure 4-6 shows the department<->employee example, where each employee belongs to only one department and each department can contain multiple employees. The department table has a primary key. The employee table has a primary key to identify each employee and a foreign key to point back to the employee's department. If you want to find the department for a single employee, a simple SQL statement retrieves the department information from the foreign key. To find all employees in a department, the container performs a JOIN statement on both the department and employee tables and retrieves all employees with the designated department number. Figure 4-6 One-To-Many Bidirectional Relationship OptionText description of the illustration ormap2.gif This is not the default behavior. To have this type of relationship, do one of the following:
To manipulate the
Figure 4-7 demonstrates how the department/employee one-to-many bidirectional example is mapped without the use of an association table. Figure 4-7 Explicit Mapping for One-To-Many Bidirectional Relationship ExampleText description of the illustration ormap7.gif What is a relationship between two entities?A relationship can be defined for only one entity type. . For example, to define a relationship between different employees in an organization, you might combine different data occurrences from the EMPLOYEE entity. For example, you might express the relationships among employees as MANAGES and REPORTS TO.
Can two entities have two relationships?There can be a number of different relationships between the same two entities.
What is it called when one entity is related with another entity?Unary relationship (recursive)
In this relationship, the primary and foreign keys are the same, but they represent two entities with different roles. See Figure 8.9 for an example. For some entities in a unary relationship, a separate column can be created that refers to the primary key of the same entity set.
What do you call to the set of relationships of similar type?A set of relationships of similar type is called a relationship set. Like entities, a relationship too can have attributes. These attributes are called descriptive attributes.
|
When there is a relationship between two entities of the same type can be referred as?
zusammenhängende Posts
Urheberrechte © © 2024 berikutyang Inc.
