System Analysis And Design (Chap 7-9)

First Normal Form (1NF)

• An attribute value in a relation's row must be a single value from the domain • Each relation must be able to be identified by a primary key • Each row is unique (no 2 rows can be identical) • All relations are in 1NF

Types of BPMN Gateways

• XOR: Exclusive OR gateway; only one of the paths that exit the gateway can be followed • AND: All of the paths that follow the gateway can be followed in parallel • OR: At least one path out of the gateway must be followed, but all paths that leave the gateway can be followed

Specialized Notation

•Specialized event notation (such as from message, or at particular time) • Specialized flow notation (sequence, default, or message flow) (The picture shows this one)

View Integration Problems pt.2

Transitive dependency: Functional dependency between non- primary attributes Example: Two 3NF relations are merged - STUDENT1 (Student_ID, Major) - STUDENT2 (Student_ID, Adviser) - STUDENT (Student_ID, Major, Adviser) But what if each major has exactly 1 adviser, MajoràAdviser? Neither Major or Adviser are Primary Keys To resolve: Create 2 relations with Major as a foreign key • STUDENT (Student_ID, Major) • MAJOR ADVISER (Major, Adviser)

Attributes

• Attribute: Property or characteristic of an entity that is of interest to the organization Examples for EMPLOYEE entity: Employee_ID, Employee_Name, Payroll_Address, Skill Attribute names should be >Nouns >Unique >Standard format >Distinguishable from similar attributes of different entity types

Business Rules

• Business rules: Specifications that preserve the integrity of the logical data model • Captured during requirements determination • Stored in CASE repository as they are documented • Implemented when creating the physical databases

Physical Database Design Decisions

1. Data type: Storage format for each attribute from the logical data model • Minimize storage• •Maximize data quality 2. Stored data structure: Grouping logical database model attributes into physical records 3. File organization: Arranging related records in secondary memory for storage, retrieval, and updates 4. Storage media: Selecting media and structures for data storage to make access more efficient

Logical Database Modeling and Design

1. Develop a logical data model for each known user interface for the application 2. Combine data requirements from all user interfaces into a single consolidated logical data model (view integration) 3. Translate the conceptual data model into normalized data requirements 4. Compare the consolidated logical data model with the translated model to produce a final logical data model

Properties of Relations

1. Entries in cells are simple (single value) 2. Entries in columns are from the same set of values 3. Each row is unique 4. The sequence of columns can be interchanged without changing the meaning/use of the relation 5. The rows may be interchanged/stored in any sequence

Attribute Types

• Candidate key: Attribute (or combination of attributes) that uniquely identifies each instance of an entity type >Some entities may have multiple candidate keys >Identifier: Candidate key that has been selected as the unique, identifying characteristic for an entity type >Identifiers are symbolized by a solid underline (Employee_ID) >Choose a candidate key that will not change its value >Choose a candidate key that will never be null • Multivalued attribute: May take on more than one value for each entity instance (example: {Skill})

Denormalization Tradeoffs

*Can increase the chance of errors and inconsistencies that normalization avoided *Optimizes certain data processing activities at the expense of others *If the frequencies of different processing activities change, the benefits of denormalization may no longer exist

Abstract and Concrete Classes

*Concrete class: Class that can have direct instances *Abstract class: Class that has no direct instances but whose descendants may have direct instances (similar to total specialization) *Abstract operation: Defines the form/protocol of the operation, but not its implementation *Polymorphism: Same operation may apply to two or more classes in different ways *<<dynamic>>: Indicates an object may change subtypes *Discriminator: Shows which property of an object class is being abstracted (Ex: residency)

1. Represent Entities

*Each regular entity is transformed into a relation *The identifier of the entity type becomes the primary key of the corresponding relation *The value of the primary key must uniquely identify each row in the relation *The primary key should be non-redundant - i.e., no attribute in the primary key can be deleted without destroying its unique identification

Representing M:N Relationships

*Given a binary M:N relationship between two entities (A and B) *Create a separate relation C *The primary key of C is a composite key consisting of the primary keys of A and B *Include any non primary key attributes associated with the M:N relationship in relation C

Partitioning Tables

*Partitioning: Capability to split a table into separate sections • Types of table partitioning (Oracle) - Range partitioning - Hash partitioning - Composite partitioning • Each partition is stored in a separate contiguous section of disk space (tablespace)

Example: Relation that violates 2NF

*Primary Key (PK): Emp_ID, Course *EMPLOYEE2 functional dependencies *Emp_ID, Course > Date_Completed EmpID >Name, Dept, Salary *Are Name, Dept, and Salary functionally dependent on the entire PK of Emp_ID and Course, or only part of the PK?

Representing a Unary 1:N Relationship

*The entity type is modeled as a relation *The primary key of that relation is the same as that of the entity type *A foreign key is added to the relation that references the primary key values *Recursive foreign key: Foreign key in a relation that references the primary key values of the same relation

Data Flow Diagramming Rules

-

Common File Organizations

- Sequential: Rows in a file are stored in sequence according to a primary key value - Indexed: Rows are stored either sequentially or non- sequentially, and an index is created that allows software to locate individual rows - Hashed: Address for each row is determined using an algorithm

Guidelines for Defining Entity Types

>Include a statement of the unique characteristic(s) for each instance of the entity type >Clarify what entity instances are included and not included in the entity type >Often includes a description of when an instance of the entity type is created and deleted >Some definitions must specify when an instance might change into an instance of another entity type >Some definitions must specify what history is to be kept about entity instances

Level-0 Diagram

>Represents a system's major processes (functions), data flows, and data stores at a high level of detail >Processes are labeled 1.0, 2.0, etc. >Processes will be decomposed into more primitive (lower-level) DFDs

Guidelines for Defining Attributes

>States what the attribute is and possibly why it is important >Should make it clear what is included and what is not included >Contains any aliases or alternative names >States the source of values for the attribute Indicate: • If a value for the attribute is required or optional • If a value for the attribute may change • Any relationships that attribute has with other attributes

Data Flow Splitting

A composite data flow at a higher level is split and different parts go to different processes in the lower level DFD. The DFD remains balanced because the same data is involved, but split into two parts.

The Entity: Strong vs. Weak (Strong)

A strong entity always exists • Professors (Dr. Skinner) always exist • Subjects (SAD) always exist

The Entity: Strong vs. Weak (Weak)

A weak entity only exists when based on a strong entity • A course - Section 1/3 of MIS 3360 - ONLY exists when a subject is taught by a professor • Represented by a double box

Naming and Defining Entity Types

An entity type name should be: • A singular noun (STUDENT, not STUDENTS) • Descriptive and specific to the organization (PURCHASE ORDER or CUSTOMER ORDER, not ORDER for both) • Concise Event entity type should be named for the result of the event, not the activity or process of the event (ASSIGNMENT for the event of a manager assigning an employee to a project)

Functional Dependencies to Relations

Dependencies• Product_ID > Description, Room• Order_Number > Order_Date, Promised_Date • Product_ID + Order_Number > Quantity_Ordered • Relations • PRODUCT (Product_ID, Description, Room) • ORDER (Order_Number, Order_Date, Promised_Date) • LINE ITEM (Product_ID, Order_Number, Quantity_Ordered)

Use Cases

Depiction of a system's behavior/functionality under various conditions as the system responds to requests from users

Data Flow Diagrams

Depicts the movement of data between external entities and the processes and data stores within a system

Entity Relationship Modeling

Detailed, logical representation of the entities, associations and data elements for an organization or business area

Can we represent Weak Entities? Yes!

Composite primary key is composed of the primary key of the entity on which the weak entity depends and the identifier of the weak entity E.g., I have an Employee relation and a Dependent relation •DEPENDENT(Employee_ID, Dep_Name, Dep_Age, Dep_Relation)

Supertype/subtype hierarchy

Double line =total specialization O= Overlap Single line=partial specialization D=Disjoint

Data Model

Entity Type (The whole class) Attributes (Name, Color etc.) Entity Instances (Name=Sam, Amy,Dave) Entity Class ( Animal = these attributes can be used to describe any animal) Relationships ( Horses are associated with an owner) Domains (Spots {Yes,No} Weight {800-2200}) Values ( all the attributes in the table)

Normal Forms: In simple terms

For a relation to be in "*NF", it must satisfy the following conditions: • First Normal Form (1NF) • An attribute value in a relation's row must be a single value from the domain • Each relation must be able to be identified by a primary key • Each row is unique (no 2 rows can be identical) • All relations are in 1NF • Second Normal Form (2NF): • The relation is in 1NF • There are no Partial Dependencies. • A Partial Dependency exists: • a) If the relation has a composite primary key and • b) If attributes in the relation depend only on part of the primary key and not the entire primary key. • Third Normal Form (3NF): • The relation is in 2NF • There are no Transitive Dependencies. • A transitive dependency exists when a non-primary key attribute depends on other non-primary key attributes rather than depending upon the primary key.

DFD Decomposition

Functional decomposition: Iterative process of breaking a system description down into finer and finer detail • Creates a set of charts in which one process on a given chart is explained in greater detail on another chart • Continues until no sub-process can logically be broken down any further • Primitive DFD is the lowest (most specific) level of a DFD • Level-1 diagram: Results from decomposition of Level-0 diagram • Level-n diagram: DFD that is the result of n nested decompositions from a process on a level-0 diagram • Rule of thumb: No DFD should have more than about 7 processes

DFDs as Analysis Tools

Gap analysis: Process of discovering discrepancies between two or more sets of DFDs or within a single DFD Involves examining DFDs for • Redundant data flows • Data that are captured but not used • Data updated identically in more than one location • Inefficiencies DFDs of current logical system compared with DFDs of new logical system can show which processes need to be added or revised DFDs in BPR: Help show inefficiencies in the existing system

Basic Types of Business Rules

• Entity integrity: unique, non-null identifiers • Referential integrity constraints: rules governing relationships between entity types • Domains: constraints on valid values for attributes • Triggering operations: other business rules that protect the validity of attribute values

Reduced Decision Table

Indifferent condition: A condition whose value does not affect which actions are taken for two or more rules. E.g. Hours worked for Salaried Employees

Context Diagram

Overview of an organizational system >system boundaries >external entities that interact with the system >major information flows between the entities and the system • Always contain 1 process and no data stores

Entities

Person, place, object, event, or concept in the user environment about which the organization wishes to maintain data Examples: EMPLOYEE, PRODUCT, REGISTRATION, ACCOUNT, COURSE, WAREHOUSE • Entity type (entity): Collection of entities that share common properties/characteristics (see examples above) • Entity instance (instance): Single occurrence of an entity type

Primary Key

• Primary Key: Attribute whose value is unique across all occurrences of a relation • All relations have a primary key • Ensures that rows are unique • May involve a single attribute or be composed of multiple attributes

DFD Symbols (Gane and Sarson Symbols)

Process, data store, source/sink, data flow

Entity-Relationship Diagram

Slide 47 Proff Skinner (Must Memorise because on test)

Representing Supertypes and Subtypes

Subtype: Subgrouping of the entities in an entity type • Meaningful to the organization • Shares common attributes or relationships distinct from other subgroupings • Supertype: Generic entity type that has a relationship with one or more subtypes

Elements of Activity Diagrams: Customer Ordering Process

Swimlanes: Columns representing different organizational units of the system (vertical lines) Start: The beginning of a process (filled in circle) Activity: Behavior that an object carries out while in a particular state (rounded rectangle) Fork: Beginning of parallel activities (horizontal line with 2 arrows coming out of it) Branch: A condition whose results provide transitions to different activity paths (diamond) Merge: Where different paths converge (diamond)Join: End of parallel activities (horizontal line with 2 arrows coming into it) End: The end of a process (a filled in circle that has another circle around it)

Unbalanced DFDs

This is unbalanced because the process of the context diagram has only one input but the Level-0 diagram has two inputs.

Common Situations for Denormalization

• Two entities with a one-to-one relationship • Associative entity (many-to-many relationship with non-key attributes) • Reference data

Business Process Modeling

modeling the standard methods for accomplishing a particular task necessary for an organization to function

Controlling Data Integrity

• Accurate data are essential for compliance with national and international regulations • Data integrity controls: Preventive measures that improve data quality - Default value: Value that a field will assume unless an explicit value is entered for that field - Range control: Limits the range of values that can be entered into a field - Referential integrity: Constraint that specifies that the value/existence of an attribute in one relation depends on the value/existence of the same attribute in another relation - Null value: Special field value that indicates that the value for the field is missing or otherwise unknown (distinct from 0, blank, or any other value)

Activity Diagrams

shows the conditional logic for the sequence of system activities needed to accomplish a business process

Sequence Diagrams

used to show interactions among objects for a particular use case

Representing a Binary 1:N Relationship

• Add the primary key attribute(s) of the entity on the 1 side of the relationship as a foreign key in the relation that is on the many (N) side of the relationship • Example: •CUSTOMER(Customer_ID,Name,Address,City_State_Zip,Discount •ORDER(Order_Number,Order_Date,Promised_Date,Customer_ID)

Naming and Defining Relationships

• A relationship name is a descriptive verb phrase • Avoid vague names• Ex: Assigned_to, not Assignment • A relationship definition: • Explains what action is to be taken and possibly why it is important • Gives examples to clarify the action

Cardinality of Relationships

• Cardinality: the number of entity instances associated with another entity Optional participation: Minimum cardinality = 0 Mandatory participation: Minimum cardinality > 0 Many: Maximum cardinality > 1 Fixed number n (e.g., 1): Maximum cardinality = n Professor Skinner teaches 0 to 1 classes - Optional participation with a maximum cardinality of 1. Optional One ("Prof Skinner teaches a minimum of zero classes and a maximum of 1 class") SAD is taught by 1 to many professors - Mandatory participation with a maximum cardinality of many. Mandatory Many ("SAD is taught by a minimum of one professor and by a maximum of many professors")

View Integration Problems pt.3

• Class/Subclass relationships may be hidden • Example: 2 different types of patients exist- PATIENT1 (Patient_ID, Name, Address, Date_Treated) - PATIENT2 (Patient_ID, Room_Number) - PATIENT (Patient_ID, Name, Address, Date_Treated, Room_Number) • To resolve: Create class/subclass relations • PATIENT (Patient_ID, Name, Address) • INPATIENT (Patient_ID, Room_Number) • OUTPATIENT (Patient_ID, Date_Treated)

Modeling Logic with Decision Tables

• Condition Stubs: The conditions relevant to a decision• Action Stubs: The actions that result for a set of conditions• Rules: Specifies which actions are to be followed for a set of conditions

Types of Operations

• Constructor: Creates a new instance of a class• Available to all classes• Not explicitly shown in a class diagram • Ex: create-student( ) creates a new instance of student and initializes its state • Query: Accesses (but does not alter) the state of an object • Has no side effects• Ex: calc-age( ), get-year( ) • Update: Alters the state of an object Ex: promote-student( ) would change the Student object's state (value of the year attribute increases) Ex: register-for(course) establishes a connection from a Student object to a specific Course object

Choosing Data Types

• Data type: Coding scheme recognized by system software for representing organizational data - Influences the available space to store data and the speed to access data - Database management software determines which options are available (example: char, varchar2, and long in Oracle 10i) • Objectives for data type selection 1. Minimize storage space 2. Represent all possible values of the field 3. Improve data integrity of the field 4. Support all data manipulations desired

Converting a Relation into 2NF

• Decompose the original relation into new relations using determinants • Determinant: Attribute that determines other attributes • The determinants are the primary keys of the new relations Expressed as A > B A is called the determinant B is called the dependent

Converting a Relation into 3NF

• Decompose the relation into new relations using determinants • Foreign Key (FK) • An FK is an attribute that appears as a non-primary key attribute in one relation and as a primary key attribute (or part of a primary key) in another relation • Must satisfy the Referential Integrity Constraint. • Referential Integrity Constraint: Each foreign key value must match a primary key value in another relation, OR the foreign key value must be null Expressed as A >B A is called the determinant B is called the dependent

2. Represent Relationships

• Degree of the relationship • Unary • Binary • Ternary • Cardinalities of the relationship (outer E-R diagram symbols) • 1:1 • 1:N • M:N

Degrees of Relationships

• Degree: the number of entity types that participate in a relationship • Unary relationship: a relationship between the instances of one entity type • Also called a recursive relationship • Binary relationship: a relationship between instances of two entity types • Most common type of relationship encountered in data modeling • Ternary relationship: a simultaneous relationship among instances of three entity types

Domains

• Domain: Set of all data types and values that an attribute can assume • Advantages • Verify that the values for an attribute are valid • Ensure that various data manipulation operations are logical • Help conserve effort in describing attribute characteristics

Representing a Binary/Unary 1:1 Relationship

• Either add the primary key of A as a foreign key of B, • Or add the primary key of B as a foreign key of A, • Or do both of the above.

Elements of Entity-Relationship Modeling

• Entity-Relationship data model (E-R model) >Detailed, logical representation of the entities, associations and data elements for an organization or business area >E-R Model is expressed in terms of: • Data entities in the business environment • Relationships or associations among those entities • Attributes or properties of both the entities and their relationships • Entity-relationship diagram (E-R diagram) • Graphical representation of an E-R model • Purpose: To capture the richest possible understanding of the meaning of the data necessary for an information system or organization

Basic Notation - Event, Activity, Gateway, Flow

• Event: Trigger that initiates the start of a process ( Oval) • Activity: Action that must take place for a process to be completed (Rectangle) • Gateway: Decision point (Sideways diamond) • Flow: Shows the sequence of action in a process (Arrow)

Use Case Relationships

• Extend relationship: Association between two use cases where one adds new behaviors/actions to the other Extends use case by adding new behavior/actions Specialized use case extends the generalized use case Arrow from use case X to use case Y indicates that X is a special case behavior of the more general process Y • Include relationship: Association between two use cases where one uses the functionality contained in the other • Indicates a use case that is invoked by another • Links to general purpose functions, used by many other use cases • Arrow from use case X to use case Y indicates that X always involves at least one Y (X has a subtask Y)

Designing Fields

• Field: Smallest unit of named application data recognized by system software • Attributes from relations are represented as one or more fields • Example: student name might be represented as 3 fields: Last_Name, First_Name, Middle_Init • Basic decisions: - Choosing data types - Controlling data integrity

Functional Dependencies (FDs)

• Functional Dependencies (FDs) specify a relationship between attributes in a relation • An attribute A in a relation functionally determines another attribute B if for a given value of A, there is a single, specific value of B. • Said another way: B is functionally dependent on A • Example: Emp_IDàName • Expressed as AàB • A is called the determinant • B is called the dependent

Generalization

• Implemented via superclass/subclasses • Analogous to supertypes/subtypes in E-R diagrams • Overlapping: Descendant may be from more than one of the subclasses • Disjoint: Descendant may not be from more than one subclass • Complete: All subclasses have been specified (not the same as total specialization) • Incomplete: Some additional subclasses are not in the model

Designing Controls for Files

• Implementing controls on each file enables: - Protection from failure/data loss - Security from unauthorized use • File backup controls - Periodically make a backup copy of a file - Store a copy of each change to a file in a transaction log or audit trail - Store a copy of each row before or after it is changed • Security controls - Code (encrypt) the file's data - Require data file users to login with user names and passwords, and impose limitations on file activities/users/data - Prohibit users from directly manipulating data, forcing programs and users to work with a copy of the data they need (original version will change only after updates have been checked for validity)

Multiplicity (See slide 61)

• Indicates how many objects participate in a given relationship • 0..10 means minimum 0, maximum 10 • 1,2means either 1 or 2 • * means infinite upper bound • Analogous to cardinality in E-R diagrams

Database Design Deliverables/Outcomes

• Logical database design: Normalized relations • Relation: Named, 2-dimensional table of data (≠ computer files) • Accounts for every data element on a system input/output • Physical database design: Database tables • Results from conversion of relations • Represents coding the definitions of the database • Written in Structured Query Language (SQL) • Normalization: Process of converting complex data structures into data structures characterized by simplicity, non-redundancy, and minimal maintenance

Shorthand Notation for a Relation's Structure

• Name of the relation (all caps) followed by the names of the attributes in the relation • Primary key underlined

Normalization

• Normalization: The process of converting complex data structures into simple, stable data structures • Normalization provides a stepwise approach to designing a relation that is guaranteed to be free of data redundancies using Normal Forms • Rules of Normalization: • Properties of relations 1. Entries in cells are simple (single value) 2. Entries in a given column are from the same set of values 3. Each row is unique (non-null primary key) 4. Columns can be interchanged/stored in any sequence 5. Rows can be interchanged/stored in any sequence • Normal forms (1NF, 2NF, 3NF)

Representing Objects and Classes (Check slide 59)

• Object: Entity with a well-defined role in an application domain with state, behavior, and identity characteristics (single occurrence of a class) • Object class (class): Logical grouping of objects that have the same (or similar) attributes, relationships, and behaviors (methods) • Class diagram: Shows the static structure of object classes, their internal structure, and the relationships in which they participate

Sequence Diagram (Instance)

• Objects: Represented by boxes at top of diagram • Lifeline: Time during which an object exists • Activation: Time period during which an object performs an operation • Message: Means by which objects communicate with each other

Example: M:N Relationship

• PRODUCT (Product_ID, Description, Room, City_State_Zip) • ORDER (Order_Number, Order_Date, Promised_Date) • ORDER LINE (Product_ID, Order_Number, Ordered_Quantity)

Arranging Table Rows

• Physical file: Named set of table rows stored in a contiguous section of secondary memory • Pointer: Field of data that can be used to locate a related field/row of data - Used when it isn't possible to store related data next to each other - Mostly hidden from programmers

Merging Relations (View Integration)

• Purpose: Remove redundant relations • Last step in logical database design • Occurs prior to physical file and database design • Example: Modeling user interfaces results in a set of 3NF relations - EMPLOYEE1 (Emp_ID, Name, Address, Phone) - EMPLOYEE2 (Emp_ID, Name, Address, Jobcode, Tenure) • Because the two relations have the same primary key and describe the same entity, they should be merged: - EMPLOYEE (Emp_ID, Name, Address, Phone, Jobcode, Tenure)

Levels

• Refers to degree of detail in the use case description • Suggested levels 1.White - as seen from clouds Summary 2.Kite - "birds-eye view" 3.Blue - sea-level view 4.Fish - below sea-level 5.Black - bottom of the sea Detail

Designing Physical Tables

• Relational database: Set of tables that are related by foreign keys referencing primary keys • Physical table: Named set of rows and columns that specifies the fields in each row of the table - May or may not correspond to one relation - Design of physical tables aims for efficient use of secondary storage and data processing speed (example: data stored close to one another in secondary memory are processed faster) • Denormalization: Process of splitting/combining normalized relations into physical tables • Based on affinity of use of rows and fields • Optimizes certain data processing activities at the expense of others

Relational Database Model

• Represents data as a set of related tables (relations) • Relation: Named, 2-dimensional table of data • Set of named columns (attributes) • Arbitrary number of unnamed rows (records) • Primary key (identifier)

Other Attribute Types

• Required attribute: an attribute that must have a value for every entity instance (symbolized by bold text) • Optional attribute: an attribute that does not have to have a value for every entity instance (symbolized by normal text) • Composite attribute: an attribute that has meaningful component parts (e.g. address(street, city, state, zip)) • Derived attribute: an attribute whose value can be computed from related attribute values (e.g. [age] calculated from DOB)

Types of Messages

• Synchronous message: Caller has to wait for the receiving object to finish executing the called operation before it can resume execution itself • Simple message: Transfers control from the sender to the recipient without describing the details of the communication • Asynchronous message: Sender does not have to wait for the recipient to handle the message

View Integration Problems pt.1

• Synonyms: Two different names used for the same attribute • Example: Employee_Number and Emp_ID describe the same characteristic • To resolve: Obtain agreement from users on a single standardized name • Homonyms: Single attribute name is used for 2+ different attributes • Example: Address is used to refer to a campus address in one relation and a home address in another relation • To resolve: Create new attribute names (ex: campus_address and home_address)

Second Normal Form (2NF)

• The Second Normal Form (2NF) is based on a concept known as full functional dependency: ▫ Full functional dependency: Each non-primary key attribute is identified by the whole Primary key • For a table to be 2NF: ▫ Must be 1NF ▫A relation is in 2NF if every non-prime key attribute is fully functionally dependent on the whole primary key • A relation is in 2NF if it meets any of the following: ▫Primary key consists of only 1 attribute ▫ There are no non-primary key attributes in the relation ▫ Every non-primary key attribute is functionally dependent on the full set of primary key attributes

Third Normal Form (3NF)

• The relation is in 2NF • There are no Transitive Dependencies. • A transitive dependency exists when a non-primary key attribute depends on other non-primary key attributes rather than depending upon the primary key.

Types of Business Rules

• Total specialization (double line): Each entity instance of the supertype must be a member of some subtype in the relationship. • Partial specialization (single line): An entity instance of the supertype does not have to belong to any subtype, and may or may not be an instance of one of the subtypes. • Disjoint rule (letter d): If an entity instance of the supertype is a member of one subtype, it cannot simultaneously be a member of any other subtype. • Overlap rule (letter o): An entity instance can simultaneously be a member of two (or more) subtypes.

Triggering Operations (Check Slide 56)

• Trigger: Assertion/rule that governs the validity of data manipulation operations such as insert, update and delete • Includes the following components: • User rule: statement of the business rule to be enforced by the trigger • Event: data manipulation operation that initiates the operation • Entity Name: name of entity being accessed or modified • Condition: condition that causes the operation to be triggered • Action: action taken when the operation is triggered

Use Case Diagram

•Use Case diagram: Depicts system behavior along with the key actors that interact with the system • Actor: External entity that interacts with the system • Represents a single role, not a specific user • May represent many users • Most actors represent user roles, but some actors can be external systems • Use case: Depiction of a system's behavior/functionality under various conditions as the system responds to requests from users • Abstract use case: Type of use case that is initiated by another use case instead of by an actor