of University 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. Entities that are Tangible Objects Following are examples of entities that are tangible objects: * ORDER, of which one entity might be a request on 6 November for 50 footballs from Poly Leisure Products * VEHICLE, with an entity Ford Model T, Registration Number 135 AXU * ROOM, with entities kitchen at 14 Conway Road, boardroom at James Martin & Co. Entities that are Activities or Events of Interest to the Business Following are examples of entities that are activities or events: * LECTURE ATTENDANCE (e.g., John Davis attends the lecture on Entity Relationship Modeling on 3 May 1997) * EQUIPMENT MALFUNCTION (e.g., the lighting dimmer in lecture room 2 fails at 3 PM. on 4 June 1995) Entities that are Intangible Following are examples of entities that are intangible: * GEOGRAPHICAL SALES AREA (e.g., Europe, Asia, Australia) * MARKET SECTOR (e.g., consumer, electronics, instrumentation) * CUSTOMER TYPE (e.g., distributor, retail store) * BUSINESS ROLE (e.g., principal, guarantor, legal advisor, broker)
Entity Type
The collection of all the entities important to the business, to which a specific definition and common predicates apply. 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. Tangible Entity Type An entity type whose entities are physical objects or particular views of physical objects. Conceptual Entity Type An entity type whose entities are intangible objects without physical form. Associative Entity Type An entity type whose entities relate to two or more entities. Associative entity types are used to resolve many-to-many relationship types in an entity relationship diagram. For example, each entity of the entity type CLUB MEMBERSHIP relates one entity of CLUB with one entity of MEMBERSHIP. Collective Entity Type An entity type whose entities gather together or consist of entities from one or more other types. In some cases, a collective entity type may be helpful in improving the performance of a system. Component Entity Type An entity type whose entities form part of a larger collective entity type. Overlapping Entity Types Two or more entity types with entities in common. Overlapping entity types are to be avoided. Isolated Entity Type An entity type that does not participate in any relationship. Transient Entity Type An entity type whose entities are of only short-term interest to the enterprise.
Entity Type Horizon
A context within which an entity type is identifiable by a specific identifier, but beyond which the entity type is not uniquely identifiable. Each entity type has a logical horizon. This is the collection of other entity types (possibly none) that can be uniquely selected by following chains of many-to-one relationships away from it. Example of a Logical Horizon Each entity type has a logical horizon. This is the collection of other entity types [possibly none] that can be uniquely selected by following chains of many to one relationships away from it. For example, the logical horizon for an ATTENDANCE is: COURSE, SESSION and ITEM will form an initial grouping, as will STUDENT and BOOKING, because of their mandatory association with the COURSE grouping, both directly to SESSION and indirectly through COURSE PRESENTATION, it is more strongly associated with the COURSE grouping than with the STUDENT grouping, to which it has but a single association. At a further level of summarization, it is therefore merged into the COURSE grouping. Entity Type Horizon for Unique Identification For an ORDER ITEM, there is a "horizon of identifiability" which is called the entity type horizon. Within this horizon, the ORDER ITEM can uniquely identify singly related entity types, but anything outside of the horizon cannot be identified. For example, if a CUSTOMER makes many PAYMENTs, there is no way of distinguishing individual PAYMENTs from the viewpoint of an ORDER ITEM or even an ORDER. For each PAYMENT entity, there is a horizon that encompasses its CUSTOMER but that does not include any ORDERs. You will find horizons useful when you analyze the structure of entity relationship models. For example, you may know that you want to be able to determine, uniquely, which ORDER a DELIVERY was for. So you know that ORDER must be within the horizon of a DELIVERY. You can also consider the optionality of relationships when analyzing horizons. For example, if the plural end of a one-to-many relationship is optional, you cannot assume that the single entity type is identifiable, because there may be no pairing.
External Object
A source or destination of information, materials or resources outside the immediate scope of analysis.
Because some producers or receivers of data are outside the system or business area under investigation, you cannot tell what procedures produce or accept the data, or what happens to those data. There must be procedures to or from which the data are flowing, but because you cannot formally identify them, you identify the producers or receivers as external objects. Such external objects are typically named by using the name of an entity type that represents the procedures, people or organizations receiving or producing the data flow. Imports and Exports It is useful to describe not only the imports and exports, but where they come from and go to. Imports and exports link an activity in the business with its corresponding sources and destinations. The external sources and destinations of information, materials or resources are represented as external objects (e.g., CUSTOMER, SUPPLIER, GOVERNMENT AGENCY). They carry out their own activities, which create or use the imports or exports through which they interact with your enterprise. They are therefore of interest to the business, and they usually also appear as entity types in the information model.
Function
The highest, most aggregated level of business activities that together completely support one aspect of the enterprise's mission considered in analysis. A function may consist of other functions or processes, both being business activities. Examples of Possible Functions * PURCHASING * DISTRIBUTION * SALES * PERSONNEL * RESEARCH Component Activities Necessary to Ensure Stock is Available
A function called STORING has as its purpose to ensure that stock is available for delivery to customers. In order to do this, it must perform several of the following activities. * Receive Deliveries from Suppliers * Store Books * Issue Books for Delivery to Customers * Monitor Stock Levels * Request Publishing of Replacement Stock Characteristics of the Component Activities For each of the component activities above, questions of the following type may be asked: * How often does it take place? * What are the inputs and outputs for each occurrence of the activity? * How long does an occurrence of the activity take? Difference Between Function and Process Applying the same questions to STORING as a whole is, however, meaningless. It is meaningless to think of an occurrence or execution of STORING, although this can be done for one of its components. This is what distinguishes functions from processes. Difference Between Function and Organizational Unit At first sight, functions may seem like organizational units, and there may, in some organizations, be a close correspondence. Although this correspondence is not coincidental, a function is not an organizational unit. A function is independent of present or future organizational structures, because it represents the "what" of the business as opposed to the organizational unit's "how." Functions Found During the ISP Identification of functions is a principal goal of Information Strategy Planning (ISP). A group of these functions forms part of the definition of the scope for the Business Area Analysis project. The project is not normally expected to look for
new functions unless better information suggests that improvements should be made to the function decomposition.
Identifier
A predicate or set of predicates whose values distinguish each entity of a specific type from others of the same type. Primary Identifier The preferred means of distinguishing each entity of a type from others of the same type. When alternative identifiers are found, designate the identifier likely to be the most useful as the primary identifier. Ways of Distinguishing Entities There must be at least one way of distinguishing entities of a type, or you do not have a valid entity type. It is, however, possible to have more than one way of identifying entities. Distinguish between entities of the same entity type by: * An attribute whose value distinguishes the entities * The existence of a relationship to another entity * A combination of attributes and relationships Single Attribute Value Identifier Attribute values may be used to identify entities uniquely. A single value may suffice (e.g., "JM & Co. 1" identifies a vehicle). Alternative attribute values may also be employed. For example, if JM & Co. 1 is owned by James Martin & Co., it may also be identifiable by a unique asset number. An asset number as the identifying attribute of the entity type VEHICLE, however, is useful only for company-owned vehicles. Note also that asset number is a designed attribute. Composite Identifier Two or more predicated (attributes or relationships) whose values, taken in combination, uniquely identify the entities of one type. When the values of more than one attribute are needed in combination, the identifier is composite. For example, SUPPLIER might be identified by Name and Location, as in James Martin & Co., Reston. VA.
It is possible to identify entities with relationship memberships or with a combination of relationship memberships and attributes. Relationship memberships are used when the identifying value will be found in a related entity type. In short, an entity can be identified by any combination of predicates. For example, an ORDER ITEM may be identified by its relationship with a particular order and Item Number (an attribute of ORDER ITEM). Item Numbers may be duplicated across a set of ORDER ITEMS for different ORDERs, so the occurrences must be distinguished by finding the ORDER that they belong to. Order Number is associated with an ORDER ITEM by virtue of the relationship between the two entity types. It is in part the existence of a relationship membership that identifies the ORDER ITEM. An entity may be identified purely by relationships. For example, the entity type PRODUCT STOCK is identified uniquely by its relationship with the PRODUCT and WAREHOUSE LOCATION entity types.
Location
A physical place at which activities of interest to the enterprise may be performed or hardware may be installed. A location is a physical place at which activities of interest to the enterprise may be performed by the enterprise itself or by external organizational units. For example, a warehouse would be of interest, either if owned by the enterprise or if used by the enterprise but managed by a specialist supplier. A location is not always equivalent to a physical address (e.g., headquarters and a regional sales office may share a postal address). A location need not even be fixed geographically (e.g., a ship or a salesperson's car, especially given adequate radio links, may be an acceptable location). A location is not an organizational unit, although it may sometimes share a name with a unit. Location Type A classification of locations based on the similarity of their role or purpose and of their level of activity. There may be many locations that perform the same role (e.g., sales offices, factories or warehouses). Location type groups the locations that perform similar roles and that share broadly similar frequencies of activities and volumes of data.
Location number is the number of locations of each type in which activities of the enterprise are performed. It, together with any anticipated growth factor, is documented as a property of the location type.
Normalization
The decomposition of a data structure, to remove any implicit dependencies between objects within the structure. Normalization is a staged procedure that reduces any given collection of attributes to several, more basic collections called "normalized relations." A fully normalized relation is a group of attributes in which the existence of values for the non-identifying attributes is entirely dependent upon the existence of values for the identifying attributes of the group. Normalization is used within correctness checking to help decide whether an attribute has been assigned to the correct entity type, and whether further entity types are needed in the model. Normal Form The results of the stages of normalization are attribute groups in some normal form: First Normal Form (1NF), Second Normal Form (2NF), Third Normal Form (3NF), Fourth Normal Form (4NF) and Fifth Normal Form (5NF). Each normal form serves to remove ambiguities from the database. In an unnormalized collection of attributes, the values can be organized in repeating groups (e.g., multivalued attributes) with many dependencies between them. In a 5NF collection of attributes, you will have separated out all multivalued attributes and eliminated all but the most direct dependencies and provided the most flexible access to unambiguous data. First Normal Form 1NF achieves the separating of multivalued attributes by constructing a distinct separate collection of entity types to contain the multiple values. In 1NF, no entity type has repeating groups. Second Normal Form 2NF achieves the separation of entity types that are not dependent on the complete identifier of the group. In 2NF, no entity types are only partially dependent on their identifiers. Third Normal Form
3NF achieves the separation of entity types that are dependent on attributes other than the complete identifier. In 3NF, no entity types are indirectly dependent on their identifiers. A well designed entity relationship diagram is a third normal form schema. Fourth Normal Form 4NF achieves the separation of entity types that are conditionally dependent on other attributes. In 4NF, every entity type is directly dependent on its identifier under all circumstances. Using entity subtypes in an entity relationship diagram places the schema into the fourth normal form. Fifth Normal Form 5NF achieves the separation of large composite identifiers into independent tables, each with only a pair of identifying attributes. This can achieve a reduction in the level of redundancy among the total set of attribute values, but because it adds little to the meaningfulness of the model, it is generally not employed.
Optionality
A type of predicate condition that places constraints on whether a dependency, relationship or attribute must exist. Optional Attribute Type An attribute type that need not have a value for every entity of the type it describes. Optional Relationship Membership Membership of an entity type in a relationship, such that entities of the type may exist without participating in a pairing under the relationship. Optional Dependency A process dependency under which execution of one of the participating processes may execute without resulting in or following from the execution of the other. See also: Attribute Type, Relationship Type, Dependency.
Attribute Type
A descriptor of an entity type. Attribute types are the names of the things the business must store about entity types. For example, the entity type EMPLOYEE may be described by attribute types Employee Name, Employee Number, Birth Date, Sex, Height and Eye Color. An individual entity of the type EMPLOYEE may be described as J. Frost, 3142, 5 April 1959, Male, 72, Blue. This description consists of values of the above attributes. Entity types, therefore, are described by attribute types, and entities are described by attribute values. Attribute Type Source The categorization of an attribute type according to whether its values are basic, derived or designed. Attribute Type Source Categories It is useful for the verification and selection of attributes, and for later program and data design, to record the source category of an attribute. There are three possible source categories: * Basic Attribute: An attribute type whose values cannot be calculated. Its values must be entered into the database (e.g., Employee Name, Birth Date) * Derived Attribute: An attribute type whose values can be calculated from attribute values available in the database (e.g., Invoice Value, Account Balance, Pension Contribution) * Designed Attribute: An attribute type whose value is calculated to serve a particular purpose and has no specific meaning to the enterprise (e.g., Abbreviated Customer Name, Employee Number) Designed attributes types are not business objects and so are generally best avoided during Business Area Analysis. You may need them occasionally, when there is no other way of identifying the entities of an entity type (e.g., Employee Number), or when they are imposed by an external authority (e.g., Postal Code/Zip Code). Fixed Attribute Type
An attribute whose values, once established for any given entity, remain unchanged for the life of that entity. Composite Attribute Type A named collection of attribute types of one entity type in which each group of values may be treated as if it were a single value. An attribute type may consist of a meaningful collection of other attribute types. For example, the attributes Birth Month, Birth Day and Birth Year comprise the attribute type Birth Date, which is meaningful to the business and may be handled as a single attribute type. Birth Date is therefore described as a composite attribute type. Optional Attribute Type An attribute type that need not have a value for every entity of the type it describes. When an entity need not have a value for a particular attribute, that attribute is optional. For example, the entity type LOCATION has an attribute of Telephone Number, but not every LOCATION has a telephone. Any such LOCATION will have no value for the Telephone Number attribute. The optionality of an attribute may depend on a defined condition (e.g., BOOK has a Price only if it is still in print). Optionality may depend on the existence of a relationship membership (e.g., EMPLOYEE has Pension Contribution only if EMPLOYEE participates in a PENSION SCHEME). The conditions and condition logic for attributes are basically the same as for relationships. They are a type of predicate condition and have predicate condition logic. Transient Attribute Type An attribute type whose values may change several times during the life of the entity that each value describes.
Relationship Type
A reason of relevance to the enterprise why entities from one or from two entity types are considered as a logical unit. A relationship type is often referred to simply as a relationship. Relationship and Relationship Membership
Relationship membership is the participation of an entity type in a relationship. The associations between its entity types are as important to a business as the entities, themselves. These are analyzed as relationship types. The occurrence of a pairing is a relevant association between two entities. For example, Ian Palmer "writes" Database Management, where "writes" associates an AUTHOR entity type with a BOOK entity type. The relationship type is named with the verb (e.g., "writes") that states the reason why entities of the two types may be associated. A relationship type can be seen from the point of view of each of the two participating entity types. The name is different, depending on which entity type is being considered. For example, the "writes" relationship is seen from: * The Author's viewpoint as: AUTHOR "writes" BOOK (active name) * The Book's viewpoint as: BOOK "is written by" AUTHOR (passive name) These two views are called the relationship memberships. Each relationship pairing always has two memberships. Relationship Viewpoints In the above example, you have taken the viewpoint of each entity type and considered whether it is an active or passive participant in the relationship. Each of these viewpoints is a relationship membership, and each relationship pairing has two of them. A relationship type often comes about because there is some process that associates the entity types (e.g., WRITE BOOK). If there is such a process, the name of the relationship type will come from it. In this case, the active participant is the entity type that carries out the process (e.g., it is the AUTHOR who writes the BOOK). Similarly, the passive participant is the entity type that is the object of the process (e.g., the BOOK that is written). Relationship Action or Pairing Action A type of action on one or more pairings of a given relationship by an elementary process following an action on an entity. Relationships Reflect Business Rules Relationship Cardinality
The number of times an entity may participate in a membership pairing with another entity or entities. For instance a person may be the "parent of" zero, one or many other persons. Membership or Relationship Optionality Membership of an entity type in a relationship, such that entities of the type may exist without participating in a pairing under the relationship. When describing a business, determine whether or not an entity of a given type always participates in a pairing of a given relationship. For example, an EDITION is always of a BOOK and cannot exist unless it is associated with a BOOK. The relationship membership "EDITION is printing of BOOK" is therefore said to be mandatory. You may, however, find that at some time there are BOOKs that have not yet been printed as an EDITION. The relationship membership "BOOK printed as EDITION" is therefore said to be optional. Optionality of Each Relationship Membership The state being of mandatory or optional is a property not of the whole relationship, but of each of the two relationship memberships. Optionality of a relationship considers whether entities of a given entity type can exist without participating in any pairing under that relationship. Mandatory membership implies a cardinality of at least one. Optional membership implies that the cardinality may be zero. Fully Optional Relationship Membership A relationship under which entities of both entity types can exist without participating in some pairing. When both relationship memberships are optional (e.g., PUBLISHER commissions BOOK, where PUBLISHERs exist who do not commission any BOOKs, and BOOKs are written that have not been commissioned by a PUBLISHER), the relationship is called fully optional. Most relationships are partly optional (i.e., only one of the relationship memberships has the property of optional). Transient Relationship Membership The membership of an entity of a specific type that may change between groupings under a specific relationship several times during that entity's life.
Exclusive Relationships Two or more relationship memberships in which each entity may participate in any one, but not more than one, grouping under these relationships. Exclusive Relationships and Integrity Conditions If, at any time, a pairing holds between two entity types, it occasionally excludes the possibility of one or both of the entity types having pairings with other entity types at that time. In other words, the possibility of pairing between two entity types may depend on the lack of a pairing between one or the other or both of them and some other entity types. For example, a PAYMENT may pay for one or more BOOKs or one or more MACHINEs but not for a mixture of both. Thus, the "PAYMENT pays for BOOKs" relationship membership and the "PAYMENT pays for MACHINEs" relationship membership are mutually exclusive. We call these exclusive relationship memberships. Integrity Conditions Exclusive relationships must be implemented through data integrity conditions. Exclusivity can be affected by an integrity condition, which can be complex. A simple condition for the above example may be: * If Payment Method = cash, the PAYMENT must be for BOOKs (because the company will never pay for machinery by cash) A more complex condition may be: * If Payment Method = cash and PAYMENT is sent to AUTHOR, PAYMENT pays for one or more BOOKs
Pairing
Two entities of one or two types associated by virtue of a defined relationship. Relationship, Pairing and Grouping
Entities are the occurrences of an entity type, but what is an occurrence of a relationship? It can be thought of as an association between two entities. This is known as a pairing. For example, "Hamlet written by Shakespeare" is an occurrence of the relationship "written by." When you want to consider an AUTHOR and all the BOOKs the author has written, use the term grouping. Given joint authorship, a grouping could consist of a book and all the authors who helped write it; conversely, there would be a grouping for each author and all the books the author had written. In effect, a grouping is a set of pairings. Example to Help Distinguish Between Pairing and Grouping
This example has 2 entity types, 7 entities, 5 pairings and 2 groupings. Pairing Action An action on one or more pairings of a given relationship by an elementary process following an action on an entity. Pairing Membership The participation of an entity in a pairing.
Predicate
A predicate is an attribute type or a relationship membership. A predicate value is an attribute value or a pairing.
Predicate and Predicate Value You will need to know many things about discovered entity types. Some of these things will be other entity types (e.g., SALEs to each CUSTOMER). You describe this by defining the other entity types and associating them by relationships. The other things you need to know about entity types are particular to the entity type and describe it (e.g., a Customer Name and Address). These are the attributes that describe an entity type. Attributes and relationships have a similar effect on entity types; they also have similar properties. Because of this, you can use the generic term "predicate" to describe them, and "predicate value" to describe their occurrences. Predicate Condition A condition that affects the values of predicates and their properties. You often need to define conditions that affect the values of predicates and their properties. These are called predicate conditions. There are a number of different types of predicate conditions. Conditional Membership A common cause of optionality is conditional membership, where the participation of an entity in a pairing depends upon predicate values (e.g., BOOK can be used for TEACHING if the condition "Book Type = textbook" is true). Condition Logic The logic "Book Type = textbook" is known as the condition logic for the condition. The attribute values in the condition logic need not belong to the entity types affected by the condition. Also, the condition logic may include participation in a relationship membership (e.g., BOOK sent to DISTRIBUTOR if the condition logic "book is published" is true). A condition can be expressed through a number of varying condition logic statements, but it can still have the same meaning (e.g., the condition logic "A nor B" is the same as the logic "NOT (A or B)," both of which can apply to a single condition). Integrity Conditions Membership conditions may be compound. For example, the previous condition might be made more restrictive by adding the condition that the "distributor type is not a book club." Membership conditions are one way to ensure the integrity of your models and are thus one type of integrity condition. Integrity conditions in their turn are one type of predicate condition. Cardinality Conditions
It is also possible to define conditions to ensure the integrity of cardinality of a relationship membership where a maximum or minimum cardinality can be defined. Cardinality conditions are rarely used.
Procedure
A method by which one or more elementary processes may be carried out. A procedure is a method by which a specific process may be carried out. It defines how the activity is carried out as well as what the activity is. The method used to perform a process is referred to as a technique (e.g., on-line technique, batch technique, clerical technique). Procedures in Current Systems Analysis A procedure in current systems analysis is a named package of computer software or manual activities. The lowest level of concern in BAA Procedure Analysis of Current Systems is the one actually named in procedure manuals, system documentation or user discussions. There may be abstractions of procedures, such as subsystems or systems. Procedure Definition Having identified the procedures required to implement the elementary processes, you define each procedure in turn. This definition translates the business logic of a process into a specific method of supporting the process. This provides a starting point for the subsequent detailed procedure design. Classification of Procedures A policy is adopted in which the division into modules and the choice of languages follow the same approach for each type of program function. This creates consistency throughout the system, providing easier programmer interchange, easier debugging and higher productivity. Procedures or subsets of procedures can generally be described as having one of the following functions: * Query * On-line update * Batch update * Extract
* Report Procedure Condition A rule expressed in terms of logical data constructs, layouts and constants, that constrains the behavior of the business system. Procedure Decomposition The breakdown of the designed procedures of a current system into progressively increasing detail. Identify systems, decompose the systems into subsystems and the subsystems into procedures.
Process
A defined business activity, executions of which may be identified in terms of the input and output of entities of specific types, or in terms of data about entities of specific types. Processes are the specific activities of the enterprise. The process is described in terms of the entity types involved, such as CUSTOMER, ORDER or PRODUCT. The definition draws attention to the distinction between a process and an execution of it. Execution of a Process An execution of a process is concerned with the specific entity occurrences involved (e.g., Acme Company, Order 106359, 2-cm Screw) and the values of associated attributes (e.g., Quantity Ordered and Unit Price). Each execution of a process is uniquely identified by the states of the entities involved, the values of their attributes and the time of execution. Furthermore, the outcome of an execution of a process or its completion criteria are well known (e.g., an ORDER is either accepted or rejected). The same cannot be said for a broader business activity, such as SELLING, where the idea of an execution is meaningless. An execution of SELLING might involve taking an ORDER, setting a salesperson's revenue objectives, or analyzing last year's sales. In other words, an execution could mean different things at different times. It is therefore not useful to speak of an execution of SELLING. SELLING can instead be defined as a function. Examples of Processes * SCHEDULE DELIVERY * PAY AUTHOR
* INVOICE CUSTOMER * PAY EMPLOYEE * CHECK CUSTOMER CREDIT * COMMISSION BOOK Processes Describe WHAT, Not HOW Because processes describe what the business does and not how it is done, it is not necessary to consider: * What techniques are used * When it is done * Where it is done In practice, many techniques may be employable for implementing a process. A set of steps for implementing a process with a chosen technique is called a procedure. Procedures are not described during Business Area Analysis; instead, they are designed during the Business System Design phase of the Analysis Stage, because they are system activities rather than business activities. Scope of Process Analysis During BAA The identification of processes is a principal goal for a Business Area Analysis project. Functions in the project scope are analyzed to reveal every process.
Reusability
This is the ability of an existing component to be incorporated or modified to fit into multiple models or applications. Reusable Component An object or defined collection of objects in any stage of the development life cycle that may be used in multiple applications. Reusable components may be of the following types: * Application: an entire system, that may be reused as is or modified to fit the user requirements.
* Building Block: a part of a system that may or may not be able to stand on its own, such as an algorithm, a structure, a library module, a help system or knowledge of great complexity. * Application Shell: an outline of the generic components of an application, that may include comprehensive features common to applications, such as security, auditability, checkpoint-restart, protection from failures, human factoring, cooperative processing, etc., where the developer fills in the shell with the specific application details. The resultant product is less likely to have errors, instability, omissions and misunderstandings. * Template: a pattern that can be copied to create a component with the same or similar characteristics as the template. Examples include structures to indicate choices such as dialog box, action bar, pull-down menus; transaction processing dialogs; data entry screens; HELP screens; error messages; environments, such as windowing. * Generic Data Model: a generalized data model for an industry or line of business. * Data Structure: a record structure or a portion of a database. * Communication Standards: standard communication formats for exchanging information. Examples of standard formats include ANSI X.12, X.400 (electronic mail), ISO EDIFACT. * Documentation Standards: standards for the kind and format of information to include in technical and user documentation. Examples include standard table of contents for each type of manual, diagramming standards, reusable templates and text for a "Getting Started" manual. Building Block This is an existing component that may be used to build a system. Reusable Construct This is a system component that may be used without change in more than one application. Common examples are library modules and help screens. Generic Reusable Construct A component that implements a feature or features common to most computer applications. Examples of generic constructs are start module, command
processor, menu module, security module, work module, transaction processor, query module, user dialog module, error processor and stop module. Application-Specific Reusable Construct A component that implements a feature or features used by a particular kind of application and is applicable to a number of situations in the application. Reusable Object This is an object that may be useful in implementing more than one application. Reusable Object Library A repository specifically defined to contain reusable objects for an enterprise. Reusable Structure This is an application-specific or generic component or a skeleton that may be used in more than one application.
Subject Area
An area of interest to an enterprise, centered on a major resource, product or activity of the enterprise and about which the enterprise may wish to hold data. A subject area is a major subdivision of the data objects (e.g., entity types and attribute types) that the business uses. It is defined initially during an Information Strategy Planning (ISP) study to aid in the finding of entity types, or as part of the definition of a Business Area Analysis (BAA) project. Once the entity types are found, the areas are then useful as broad groupings of entity types. It is best to keep the subject areas simple, so that they consist of only those entity types and interrelationships that pertain to a particular subject entity type. An analysis project may involve several subject areas. For example, a sales analysis project may consider the Sales, Personnel, Customer and Product subject areas. As the analysis progresses, you will find that a subject area consists of a collection of entity types and the relationships between them. Hierarchy of Subject Areas in the BAA In Business Area Analysis, complexity is added, so it may be useful to form a hierarchy of subject areas either for presentation, or for the management of effort and the understanding of the model.
Example of Lowest-Level Subject Area
Example of the Customer Subject Area
Subtype
A category of entities of an entity type that either: * Has different attributes than the remaining entities * Shares in different relationships than the remaining entities * Shares different processes than the remaining entities A collection of entities to which a specific definition and common predicates apply.
Subdivisions of the Entity Type EMPLOYEE An entity subtype is a subdivision or further specialization of an entity type. For example, the entity type EMPLOYEE might be subdivided into: * ADMINISTRATOR, EDITORIAL STAFFER and PRINT ROOM STAFFER * POTENTIAL, CURRENT and FORMER EMPLOYEE * TRAINEE, PERMANENT and FREELANCE EMPLOYEE * MALE, FEMALE EMPLOYEE Making a Subset into a Subtype If these are useful subsets of the population of EMPLOYEE entities, it is worth recording them as subtypes of EMPLOYEE, defining what is special about the subtypes and analyzing their additional attributes and relationships. For example, of all EMPLOYEEs, only EDITORIAL STAFFERs can edit and proofread BOOKs and commission AUTHORs, so there are additional relationships to the subtype EDITORIAL STAFFER. Only EDITORIAL STAFFERs have Subject Experience and relevant Qualifications. These are additional attributes of the subtype. Note that EDITORIAL STAFFER still has all the attributes and relationships of EMPLOYEE. Optional Subtype Classification You may find that VICE PRESIDENT is a useful subtype of EMPLOYEE. Some EMPLOYEEs are VICE PRESIDENTs; most are not. Therefore, membership of this partitioning, which happens to have only one useful subtype, is optional. In the case of ADMINISTRATORs, EDITORIAL STAFFERs and PRINT ROOM STAFFERs, an EMPLOYEE has to be classified into one (and only one) of the subtypes. In this case, membership of the partitioning is mandatory. Describe this classification as fully enumerated. An optional classification is the equivalent of defining an "other" subtype in a partitioning. For example, you could define a mandatory classification for EMPLOYEE to be VICE PRESIDENT or OTHER EMPLOYEE (i.e., an employee must be either a vice president or another type of employee that you have not specified).
When participation in a partitioning is optional, describe the partitioning as not fully enumerated. This implies that the population of entities existing for the entity type is not completely covered by the subtypes defined within the partitioning (i.e., some lie outside and are not counted within it). The parent entity type must contain an attribute or combination of attributes from which one can determine which subtype applies to each entity. These attributes are called 'classifying' attributes. For instance, if EMPLOYEEs are either 'hourly' or 'salaried' then an attribute type called 'employee type' that takes on a value of 'H' or 'S' would be a classifying attribute.
Techniques
Entity Relationship Modeling Technique
Rules
Diagram Conventions for Entity Types Diagram Conventions for Relationship Types Summary of Entity Relationship Diagram Conventions Rules About Entity Types Rules About Relationship Types General Rules for Entity Analysis Objects
Rules: Diagram Conventions for Entity Types An entity type is depicted by a rectangle known as the entity type box. This distinguishes it from processes and other activity object types which are represented as "cushions" [rectangles with rounded corners]. The entity type box may be colored or shaded to distinguish it from a subject area or design object. The rectangle always contains the entity type name. In addition, in manually produced diagrams, it may contain some attribute type names [in smaller letters], and entity partitionings and subtypes (in smaller rectangles).
Rules: Diagram Conventions for Relationship Types A relationship type is depicted by a line (link) connecting the related entity types. One relationship membership name is included alongside the line. The other relationship membership name is documented but not shown along the line [normally one name gives the diagram sufficient meaning]. The name is chosen to make the diagram readable. Cardinality of one is symbolized by a bar -- | --written across the relationship line. The symbol for cardinality of many is a crow's foot (in preference to an arrow, which connotes direction) adjacent to the plural entity. A one-to-one relationship has no crow's feet, a one-to-many (1:M) has a crow's foot at one end only, and a many-to-many (M:M) has a crow's foot at each end.
Crossing Lines When two lines cross, one may be broken, as in the relationship type between A and B.
Optionality and Annotated Conditions
The symbol for optional relationship membership is a small circle across the relationship line next to the crow's foot or bar (adjacent to the entity type whose entities optionally participate in the relationship). Thus, a fully optional relationship has an optionality symbol at each end of the line, and a partly optional relationship has this symbol at one end only. When relationship membership is conditional, the optionality circle may have, as a manual annotation, a condition number or, alternatively, the condition logic written alongside. We do not describe cardinality conditions on the diagram except in exceptional circumstances where the condition is very important to the business. If it is shown, the logic is written beside the cardinality symbol. However the condition should always be fully documented in the relationship membership description,
Exclusive and Inclusive Relationships with a Condition The symbol for exclusive relationship membership is a circle intersecting all the relationship lines involved and adjacent to the entity type whose participation in the relationship is constrained. An exclusive relationship may have a determining condition in which case it may be indicated by an annotation beside the circle; inclusive relationships, if employed, are the same but without the circle. These notations for exclusivity and inclusivity are employed only in manual use of the methodology.
Parallel Relationship Types A parallel relationship is shown by it following a path beside the relationship it is parallel to. For example:
Rules: Summary of Entity Relationship Diagram Conventions
Rules About Entity Types * An entity type can be defined only if each of its entities is uniquely identifiable. * An entity type must have at least one relevant attribute type. * An entity type participates in relationship types (i.e., it is not isolated). * An entity type is classified as being in only one subject area. * An entity type should not normally be solitary (i.e., have only one entity). Following is a related discussion about entity types with only one attribute type. Example of Entity Type with Only One Attribute Type An entity type with a "solitary" attribute type is usually not useful. If that attribute type is the only identifier, then it is describing itself. If there is one foreign identifier, assign the attribute type to the identifier's entity type. In this new position, the attribute type may now be multi-valued. For example, the entity type EDITOR QUALIFICATION has only one attribute type (i.e., Item, whose value might be master's degree) and a many-to-one relationship with EDITOR. To resolve this condition, the entity type EDITOR QUALIFICATION may be
discarded and a multi-valued attribute type (i.e., Editor Qualification Item) is established for the entity type EDITOR.
When there is more than one entit...