Chapter 8 Systems analysis design

4. Triggering operations

. Other business rules that protect the validity of attribute values.

Entity type:

A collection of entities that share common properties or characteristics.

Repeating group

A set of two or more multivalued attributes that are logically related.

Entity instance

A single occurrence of an entity type. Also known as an instance.

Triggering operation (trigger

An assertion or rule that governs the validity of data manipulation operations such as insert, update, and delete; also called a trigger.

Relationship

An association between the instance of one or more entity types that is of interest to the organization.

Composite attribute

An attribute that has meaningful component parts.

Optional attribute

An attribute that may not have a value for every entity instance.

Multivalued attribute

An attribute that may take on more than one value for each entity instance.

Required attribute

An attribute that must have a value for every entity instance.

Associative entity:

An entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity Instances; also called a gerund.

3. Domains.

Constraints on valid values for attributes.

What is the other name for an associative entry

Gerund

Business rules

Specifications that preserve the integrity of the logical data model

Total specialization rule

Specifies that each entity instance of the supertype must be a member of some subtype of the relationship

Degree

The number of entity types that participate in a relationship.

Cardinality:

The number of instances of entity B that can (or must) be associated with each instance of entity A.

Domain

The set of all data types and values that an attribute can assume.

What is an associative entry

a bridge between two

Identifier:

a candidate key that has been selected as the unique, identifying characteristic for an entity type

Reqruied attribute:

an attribute that must have a value for every entity instance

candidate key:

an attribute that uniquely identifies each instant of an entity type

Industry-specific data models

are generic data models that are designed to be used by organizations within specific industries.

2. Referential integrity

constraints. Rules concerning the relationships between entity types

• analysis

o Conceptual data models (E-R with attributes)

• maintenance

o Data model evolution

implantation

o Database and file definitions (DBMS- specific code)

• design

o Logical data model (relational) and physical file and database design (file organizations)

• planning:

o enterprise wide data model o conceptual data model

Systems development life cycle with analysis phase highlighted

o enterprise wide data model o conceptual data model • analysis o Conceptual data models (E-R with attributes) • design o Logical data model (relational) and physical file and database design (file organizations) • implantation o Database and file definitions (DBMS- specific code) • maintenance o Data model evolution

Examples of relationships of different degrees:

• Unary relationships: is when both participants in the relationship are the same entity. • Binary relationships: is when two entities participate and is the most common relationship degree. • Ternary relationship: is when three entities participate in the relationship.

1. Entity integrity

Each instance of an entity type must have a unique identifier that is not null.

optional attribute

an attribute that may not have a value for every entity instance

Entity Relationship data model (ER model

is a detailed, logical representation of the data for an organization or for a business area

• Unary relationships

is when both participants in the relationship are the same entity.

Specific guidelines for defining relationships follow:

• A relationship definition explains what action is being taken and possibly why it is important. It may be important to state who or what does the action, but it is not important to explain how the action is taken. • It may be important to give examples to clarify the action. For example, for a relationship Registered_for between student and course, it may be useful to explain that this covers both on-site and online registration and registrations made during the drop/add period. • The definition should explain any optional participation. You should explain what conditions lead to zero associated instances, whether this can happen only when an entity instance is first created or whether this can happen at any time. • A relationship definition should also explain the reason for any explicit maximum cardinality other than many. • A relationship definition should explain any restrictions on participation in the relationship. For example, "Supervised_by links an employee with the other employees he or she supervises and links an employee with the other employee who supervises him or her. An employee cannot supervise him- or herself, and an employee cannot supervise other employees if his or her job classification level is below 4." • A relationship definition should explain the extent of history that is kept in the relationship. • A relationship definition should explain whether an entity instance involved in a relationship instance can transfer participation to another relationship instance. For example, "Places links a customer with the orders they have placed with our company. An order is not transferable to another customer."

it is important to carefully name attributes using the following guidelines:

• An attribute name is a noun (such as Customer_ID, Age, or Product_Minimum_Price). • An attribute name should be unique. No two attributes of the same entity type may have the same name, and it is desirable, for clarity, that no two attributes across all entity types have the same name. • To make an attribute name unique and for clarity, each attribute name should follow a standard format. For example, your university may establish Student_GPA, as opposed to GPA_of_Student, as an example of the standard format for attribute naming. • Similar attributes of different entity types should use similar but distinguishing names; for example, the city of residence for faculty and students should be, respectively, Faculty_Residence_City_Name and Student_Residence_City_Name.

Situation requiring an associative entity

• Many-to-many relationship with attributes: type of cardinality that refers to the relationship between two entities A and B in which A may contain a parent instance for which there are many children in B and vice versa. • Associative entity with separate relationship

A triggering operation normally includes the following components:

(a) User rule. A concise statement of the business rule to be enforced by the triggering operation (b) Event. The data manipulation operation (insert, delete, or update) that initiates the operation (c) Entity name. The name of the entity being accessed and/or modified (d) Condition. The condition that causes the operation to be triggered (e) Action. The action taken when the operation is triggered

Four business rules:

1. Entity integrity. Each instance of an entity type must have a unique identifier that is not null. 2. Referential integrity constraints. Rules concerning the relationships between entity types. 3. Domains. Constraints on valid values for attributes. 4. Triggering operations. Other business rules that protect the validity of attribute values.

Ternary relationship

: A simultaneous relationship among instance of three entity types.

Overlap rule

: Specifies that an entity instance can simultaneously be a member of two (or more) subtypes.

Partial specialization rule:

: Specifies that an entity instance of the supertype does not have to belong to any subtype.

Disjoint rule

: Specifies that if an entity instance of the supertype is a member of one subtype, it cannot simultaneously be a member of any other subtype

• Ternary relationship

: is when three entities participate in the relationship.

• Binary relationships

: is when two entities participate and is the most common relationship degree.

Candidate key:

An attribute (or combination of attributes) that uniquely identifies each instance of an entity type.

Requirements determination questions for data modeling:

1. What are the subjects/objects of the business? 2. What unique characteristic (or characteristics) distinguishes each object from other objects of the same type? 3. What characteristics describe each object? 4. How do you use these data? 5. Over what period of time are you interested in these data? 6. Are all instances of each object the same? 7. What events occur that imply associations among various objects? 8. Is each activity or event always handled the same way or are there special circumstances?

Identifier:

: A candidate key that has been selected as the unique, identifying characteristic for an entity type.

Supertype

: A generic entity type that has a relationship with one or more subtypes

Attribute

: A named property or characteristic of an entity that is of interest to the organization

Conceptual data model

A detailed model that captures the overall structure of organizational data that is independent of any database management system or other implementation considerations.

Entity relationship diagram

A graphical representation of an E-R model.

• Many-to-many relationship with attributes

type of cardinality that refers to the relationship between two entities A and B in which A may contain a parent instance for which there are many children in B and vice versa.

guidelines for naming relationships:

• A relationship name is a verb phrase (such as Assigned_to, Supplies, or Teaches). Relationships represent actions, usually in the present tense. A relationship name states the action taken, not the result of the action (e.g., use Assigned_to, not Assignment). • You should avoid vague names, such as Has or Is_related_to. Use descriptive verb phrases taken from the action verbs found in the definition of the relationship.

An associative entity

• Attribute on a relationship • (b) An associative entity (CERTIFICATE) • (c) An associative entity using Microsoft Visio®

The use of domains offers several advantages:

• Domains verify that the values for an attribute (stored by insert or update operations) are valid. • Domains ensure that various data manipulation operations (such as joins or unions in a relational database system) are logical. • Domains help conserve effort in describing attribute characteristics.

Examples of business rules

• Simple banking relationship • Typical domain definitions • Typical triggering operation

benefits of starting with and then tailoring a purchased data model

• Validated Purchased models are proven from extensive experience. • Cost reduction Projects with purchased models take less time and cost less because the initial discovery steps are no longer necessary, leaving only iterative tailoring and refinement to the local situation. • Anticipate the future, not just initial requirements. Purchased models anticipate future needs, not just those recognized during the first version of an application. Thus, their benefits are recurring, not one-time, because the database design does not require structural change, which can have costly ramifications for reprogramming the applications using the database. • Facilitates systems analysis. The purchased model actually facilitates database planning and analysis by providing a first data model, which you can use to generate specific analysis questions and concrete, not hypothetical or abstract examples of what might be in the appropriate database. • Consistent and complete. The purchased data models are very general, covering almost all options employed by the associated functional area or industry. Thus, they provide a structure that, when tailored, will be consistent and complete.

Cardinality constraints

• basic relationship • relationship with cardinality constraints

Important links:

• data elements included in data flows also appear in the data model and vice versa • Each data store in a process model must relate to business objects represented in the data model

Representing a bill of materials structure:

• many to many relationships • two items bill of materials structured instances

incorporating business rules in the repository

1. Provides for faster application development with fewer errors because these rules can be generated into programs or enforced by the database management system 2. Reduces maintenance effort and expenditures 3. Provides for faster response to business changes 4. Facilitates end-user involvement in developing new systems and manipulating data 5. Provides for consistent application of integrity constraints 6. Reduces the time and effort required to train application programmers 7. Promotes ease of use of a database

Unary relationship

A relationship between instances of one entity type; also called recursive relationship.

Subtype:

A subgrouping of the entities in an entity type that is meaningful to the organization and that shares common attributes or relationships distinct from other subgroupings.

Derived attribute

An attribute whose value can be computed from related attribute values.