University of California, Davis
Application Development Methodology
Techniques
Entity-Relationship Modeling Technique
Overview
This section describes the definition of entity types and their relationships. It defines entity and relationship concepts, their documentation and various guidelines and rules concerning the development of an entity relationship model.
Entity relationship modeling enables us to describe data and its inherent structure. The entity relationship model is represented as a diagram, known as the entity relationship diagram. This diagram is used to show our understanding of data and is used in later stages of the Application Development Methodology as a basis for data structure design.
Concepts
Cardinality
A business rule indicating the number of times a particular object or activity may occur.
Object Cardinality
Cardinality of a Dependency
The number of executions of each process that may occur before or after each execution of the other process.
Cardinality of a Subprocess
The number of times a subprocess is executed during each execution of the process of which it forms a part.
Cardinality of a Relationship Type
The number of pairings in which an entity may participate in the relationship membership.
In the example on relationship pairing and grouping, many persons may live at one address. This multiplicity is an important property of a relationship and is known as cardinality.
Example of One-To-Many Cardinality
The example on relationship pairing includes a cardinality based on the observation that "each PERSON lives at one and only one ADDRESS," and the inverse, "each ADDRESS has many PERSONs." One-to-many is the most common form of cardinality. It may be written as 1:M.
Forms of Cardinality
There are three forms of cardinality:
* One-to-one (1:1): For example, PERSON married to PERSON, where a PERSON may be married to one and only one other PERSON and vice versa.
* One-to-many (1:M): For example, BOOK printed as EDITION, where each BOOK may be printed in several EDITIONs, but each EDITION is a printing of a single BOOK.
* Many-to-many (M:N): For example, AUTHOR writes BOOK, where any AUTHOR can write many BOOKs, and any BOOK can be written by many AUTHORs.
One-to-Many Relationship
Given any grouping under a one-to-many relationship, there will be one entity paired with one or more entities of the same or another type. For the entities with a "one" membership (e.g., ORDER placed by one CUSTOMER), there is a single, identifiable, related entity (e.g., the customer who placed the order). For entities with a "many" membership, however, there are no easily identifiable related entities.
Example of one to many relationship
Consider the relationship "CUSTOMER may place one or more ORDERs." From the viewpoint of an order, the customer who placed it is easily distinguished because there is only one of them. It is not so simple to distinguish a particular ORDER for a given CUSTOMER, however. You need to use some method for distinguishing any one ORDER from all other ORDERs for that CUSTOMER, because there may be many orders. Similarly, if ORDER has a one-to-many relationship to ORDER ITEM, for each ORDER ITEM there is a single ORDER and a single CUSTOMER. For each CUSTOMER, however, there is no one uniquely identifiable ORDER or ORDER ITEM.
Cardinality Restrictions
Fixed Cardinality
A type of cardinality condition in which a cardinality of a dependency, relationship or subprocess is always the same number.
A relationship may have fixed cardinality (e.g., BUDGET consists of twelve PERIODs, or CHILD is born to two PARENTs). With fixed cardinality, the number of entities participating in each grouping is known for at least one of the entity types.
Cardinality Condition
A type of predicate condition that places constraints on the cardinality of a dependency, relationship or subprocess.
Condition
A rule expressed in terms of predicates or constants that describes an aspect of the business that causes the business to decide to do some activity or to stop some activity.
Process conditions test the states of the business at the time of execution and change the business process depending on the results of the test.
Procedure conditions test the states of the attributes or fields or the actions of the operator at the time of execution and change the computer procedure depending on the result.
Condition Logic
The condition logic is an expression of a predicate condition that may be expressed in the form "If P then Q".
Conditional Statement
A unit of activity in an action diagram wherein a condition is expressed that controls a subsequent process, procedure or step execution.
Selection Condition
A rule expressed in terms of predicates and constants, used to select one or more entities of a given type for involvement during the execution of a process or a procedure step.
Selection conditions are used to describe which entity occurrences are to be acted on during an execution of a process or procedure. They consist of the criteria that are needed to select the required entities unambiguously.
Selection can occur by two methods:
* Selection by the existence of a grouping under a named relationship
* Selection by the range of values of a named attribute
That is, entities can be selected because they participate in a given relationship membership, and entities can be selected because some or all of their attribute values meet given criteria.
It is possible to combine both methods in a single selection condition. It is also possible to act on all entities of an entity type.
Conditional Membership
The membership of an entity in a pairing where that membership depends upon some predicate values.
Example of Selection Conditions
READ existing customer WITH name = "Smith"
READ account WHICH is owned by existing customer
Execution Condition
A rule expressed in terms of predicates or constants that states when an activity (process or action group) may or may not be executed.
Execution conditions are used to determine the combination of actions that will enable each execution of a process or procedure. Not all actions occur every time a process or procedure occurs; execution conditions specify the circumstances in which an action does occur.
Example of Execution Conditions
IF existing customer status IS EQUAL TO "priority" USE priority dispatch
Execution Preconditions and Post-conditions
Optionality, cardinality and exclusivity can all be affected by conditions that detail constraints on the execution of a process (i.e., preconditions) or on the possible outcomes of execution. Optionality conditions specify when a dependency may enable execution of a process, but its absence may not prevent execution.
Conditional Subprocess
A process whose execution depends on predicate values established by prior processes.
What Conditions Are and Are Not
Conditions are expressed in terms of entity states or time events. These conditions constrain the execution of the process and are defined for the process, but they are not part of the logic of the business process. They are part of the control logic, and can be documented within the process description. To define the conditions accurately, you must have analyzed the entity type life cycles and have been through some iteration between dependency and life cycle analysis.
Cardinality Conditions
Cardinality conditions determine the number of executions of a dependent process or the number of times a preceding process may execute for each execution of a dependent process.
Exclusivity Conditions
Exclusivity conditions determine which one of a number of possible alternative dependencies may either enable a process or be established by a process.
Compound Conditions
Simple conditions can be combined into a single, compound condition that defines all constraints upon executions or outcomes of a process. The constraints may be the presence or absence of dependencies associated with the process. They can be combined using logical operations. For example, the precondition of PAY SUPPLIER could be WHEN month ends AND received supplier invoice OR part-paid supplier invoice AND IF scheduled payment
Preconditions and Results
The set of conditions that constrain the execution of a process is known as its precondition; the set that constrains the outcome is known as its result.
Decomposition
The breakdown of the activities of an enterprise into progressively increasing detail.
The principal technique for describing the functions of an enterprise is function decomposition. An activity can be decomposed when two or more other activities can be defined that together are equivalent to it.
Example of Function Decomposition
As an example, the process TAKE ORDER may be decomposed into the following processes:
* RECEIVE ORDER
* ALLOCATE STOCK OF BOOKS
* CHECK CUSTOMER CREDIT
Domain
The collection of values from which each of the values of one or more attributes or fields must be taken.
Domains to Group Attributes
An attribute describes only one entity type and has only one meaning; Employee Start Date is not the same attribute as Seminar Presentation Start Date and Employee Start Date is distinct from Employee Birth Date. These are, however, all dates. They share the same formats, and take their values from the set of all valid dates.
Sharing a domain has a further implication for attributes that can be compared or that may participate in the same computations. For example, it is permissible to add money values together, but not to add money to weight values.
Domains are useful for classifying similar attributes so that modules developed by separate teams can share data easily. The time spent in considering them will usually pay off in an increased understanding of attributes and a reduction in the complexity of the business description and significantly foster system integration..
Hierarchy of Domains
It may be useful to develop a hierarchy of domains so that conversion of values is evenly applied among all applications. For instance a domain of volume may include "cubic centimeter" and "gallon" and the algorithm used to convert from one to the other. A second example, important to international business is the domain "money" which contains Dollars, Francs and other currency.
Elementary Process
The smallest unit of business activity of meaning to a user. When it is complete, the elementary process leaves the business area in a self-consistent state. That is, the business person has come to closure on the process and all the business information is in a static and complete condition.
Criteria for Elementary Processes
To limit the decomposition, find a level of business activity that has meaning to the business as an activity, has enough detail to be useful, and is not so detailed that an execution of it would not imply that something useful and complete had been done. The elementary process is a business job, usually done by one person, that cannot be stopped in the middle without missing some information needed for the next elementary process. For example, to make a telephone sale, the elementary process must gather both what the customer wants and where the customer needs the material delivered.
It is always possible to find elementary processes, but their content and level are dependent on the business area context. What is elementary in the context of one enterprise, or even one business area, could be too high level or too low level in the context of another enterprise or business area. For example, in some enterprises, TAKE ORDER may be elementary, whereas in other environments, ALLOCATE STOCK OF BOOKS and CHECK CUSTOMER CREDIT may be elementary.
Self-Consistent Business Area
A process that leaves the business area in a self-consistent state is one whose output is complete and meaningful in itself. For example, a process may be defined that calculates the value of an order by calculating and summing the value of its items. As long as the values of individual items are not required by other processes, a process CALCULATE ITEM VALUE does not leave the business area in a self-consistent state. It provides partial or intermediate results that are of no interest to the user until they are all calculated and summed to give the final order value.
Level
Self-consistency alone, however, is not enough to define an elementary process. Any process at a level higher than elementary must also leave the business area self-consistent. For example, a process TAKE ORDER might have ALLOCATE STOCK OF BOOKS and CHECK CUSTOMER CREDIT as elementary processes. The process TAKE ORDER would, therefore, not be elementary even though it leaves the business area in a self-consistent state. It is possible that a user would see TAKE ORDER as a complete, self-contained unit with no useful subprocesses. In this case, the process TAKE ORDER would be elementary. Note that the level is defined in the context of the business user.
Implementation Factors
The identification of elementary processes may involve considering how processes have been implemented, because the user's perception is in terms of current procedures that support the process. Such implementation aspects should be set aside, and the business requirements should concentrate on defining the elementary process. The BAA should define the business as it should be, not as it is.
Unit of Work
When you define an elementary process, you are saying that there is a user activity that must be completely carried out for the business area to be satisfied. This often corresponds to a unit of work within an organization. It is a task, often assigned to a single person, with measurable outputs and one that achieves some recognizable benefits for the enterprise.
Although an elementary process ideally corresponds to a single unit of work, it contains no consideration of how it will be achieved. The completion of the process could take an appreciable period of time. One aim of Business System Design will be to minimize this time. During the execution of the process, the business area may be inconsistent (i.e., certain business rules may be broken), and some entities may not be in recognizable states. When the process is completed, all business rules must be satisfied and all entities must be in recognized states.
Entity
A fundamental thing of relevance to the enterprise, about which the enterprise needs to keep information.
Entity and Entity Type
Most businesses have suppliers, deal with products, and sell them to customers. There are thus likely to be data about individual suppliers (e.g., Poly Leisure Products of Hong Kong). Poly Leisure Products is an entity; the collection of all suppliers is the SUPPLIER entity type. The collection of all customers is the CUSTOMER entity type. A sample customer entity may be Harrods Department Store. Similarly, there is a PRODUCT entity type.