Relationship actions appear as clauses in CREATE or UPDATE action statements. Specifically, ASSOCIATE can appear as a clause in either CREATE or UPDATE action statements. ASSOCIATE can also appear as a stand-alone relationship action. ASSOCIATE has no exception conditions, but its stand-alone form may have database exception conditions.
When you CREATE an entity, you must build its identifying relationship memberships using an ASSOCIATE. The entity being associated must be one the action diagram recognizes through a CREATE or READ. ASSOCIATE establishes a pairing along a relationship between two entities. You may ASSOCIATE entities when the relationship is optional, and you must ASSOCIATE them (before the end of the elementary process) when the relationship is mandatory.
ex. emp table and emp_dept table.
wheneve you create a row in emp table, you need to associate it with emp_dept table for some department.
Relationship actions appear as clauses in CREATE or UPDATE action statements. DISASSOCIATE can also appear as:
Clauses in UPDATE action statements
Stand-alone relationship action
DISASSOCIATE has no exception conditions, but its stand-alone form may have database exception conditions.
You can DISASSOCIATE entities whose relationships have been designated as optional. The DISASSOCIATE action breaks a specific pairing along a specific relationship.
DISASSOCIATE can appear as a clause in an UPDATE action statement or as a stand-alone relationship action like ASSOCIATE. It operates exactly the same as the relationship clauses in the CREATE and UPDATE, with one exception. In relationship clauses, the subject of the clause is always the subject of the entity action. In a stand-alone relationship action, you must explicitly specify the subject of the action.
An example of a stand-alone DISASSOCIATE relationship action is shown below. In this example, received product will be deleted if its relationship to order_line is mandatory and has a cardinality of one. In addition, any product components dependent on that occurrence of PRODUCT will be deleted.
--DISASSOCIATE received product
| FROM order_line WHICH contains IT
In the example below, the relationship between PRODUCT and WAREHOUSE in the data model still exists. The pairing between the two specific entities does not. DISASSOCIATE can appear as a clause in an UPDATE action statement (as shown here).
--UPDATE received product
| SET number_delivered TO input product number_delivered
Relationship actions appear as clauses in CREATE or UPDATE action statements. TRANSFER can also appear as a stand-alone relationship action. TRANSFER has no exception conditions, but its stand-alone form may have database exception conditions.
You can TRANSFER relationships defined as transferable in the data model. The TRANSFER action transfers the relationship between specific entity occurrences. You are changing the pairing from one entity to another. This action does not affect the relationship between entities in the data model. You must READ or CREATE the entity before you TRANSFER the relationship.
For example, consider a warehouse that holds products. Products can be moved from one warehouse to another. In the example below, PRODUCT has been moved from one PROCESSING WAREHOUSE to NEW WAREHOUSE. The relationship between WAREHOUSE and PRODUCT is represented in the data model as PRODUCT always is held in one WAREHOUSE and WAREHOUSE sometimes holds one or more PRODUCT. The relationship is defined as transferable and is not changed in the data model.
-- TRANSFER received product
| FROM processing warehouse WHICH holds IT
| TO new warehouse WHICH holds IT