1. Database Development Supertype, Subtype, and Business Rules Powered by DeSiaMore 1

2. Supertype/Subtype relationships Most important new modelling construct in the ER model Allows us to model a general entity type (the supertype) and then subdivide it into several specialised entity types (called subtypes) Each subtype inherits from its supertype and may have special attributes of its own Powered by DeSiaMore 2

3. Representing supertypes and subtypes The supertype is connected with a line to a circle, which in turn is connected by a line to each subtype that has been defined (see Fig.) The ‘U’ shaped symbol on each line connecting a subtype to the circle indicates that the subtype is a subset of the supertype, and also indicates the direction of the relationship Attributes shared by all the entities are associated with the supertype, whilst attributes that are unique to a particular subtype are associated with that subtype Powered by DeSiaMore 3

4. Basic notation for supertype/subtype relationships Powered by DeSiaMore 4

5. An example: the EMPLOYEE supertype Suppose that an organisation has 3 basic types of employees: Hourly: Employee_Number, Employee_Name, Address, Date_Hired, Hourly_Rate Salaried: Employee_Number, Employee_Name, Address, Date_Hired, Annual_Salary, Stock_Option Contract consultants: Employee_Number, Employee_Name, Address, Date_Hired, Contract_Number, Billing_Rate Powered by DeSiaMore 5

6. Employee supertype Many attributes the same across 3 types, so we could define a supertype called EMPLOYEE, with subtypes for HOURLY_EMPLOYEE, SALARIED_EMPLOYEE and CONSULTANT (see Fig) Powered by DeSiaMore 6

7. Employee supertype with three subtypes All employee subtypes will have emp_no., name, address, and date-hired Each employee subtype will also have its own attributes Powered by DeSiaMore 7

8. When to use supertype/subtype relations Should consider using subtypes when either (or both) of the following conditions are present: 1. There are attributes that apply to some (but not all) of the instances of an entity type 2. The instances of a subtype participate in a relationship unique to that subtype Both are true in the following Fig., where PATIENT has two subtypes: OUTPATIENT and RESIDENT PATIENT (the primary key is PATIENT_ID) All patients have an Admit_Date and a Patient_Name Powered by DeSiaMore 8

9. Patient example Every patient is cared for by a RESPONSIBLE_PHYSICIAN who develops a treatment plan for the patient Each subtype also has unique attributes. Outpatients have a Checkback_Date, whilst residents have a Date_Discharged and a unique relationship that assigns each patient to a bed (this is a mandatory relationship, and each bed may or may not be assigned to a patient) Powered by DeSiaMore 9

10. Supertype/subtype relationships of patients Both outpatients and resident patients are cared for by a responsible physician Only resident patients are assigned to a bed Powered by DeSiaMore 10

11. Generalization and specialization BOTTOM-UP Generalization: = the process of defining a more general entity type from a set of more specialized entity types. BOTTOM-UP TOP-DOWN Specialization = the process of defining one or more subtypes of the supertype, and forming supertype/subtype relationships. TOP-DOWN Following Figs. Shows Generalisation in a situation where we have 3 different entity types: CAR, TRUCK and MOTORCYCLE Following Figs. Shows Generalisation in a situation where we have 3 different entity types: CAR, TRUCK and MOTORCYCLE In second Fig. The more general entity type VEHICLE is shown In second Fig. The more general entity type VEHICLE is shown Powered by DeSiaMore 11

12. Generalisation MOTORCYCLE is not shown as it does not satisfy conditions for a subtype discussed earlier – the only attributes of MOTORCYCLE are those that are common to all vehicles, there are no attributes specific to motorcycles. Further, MOTORCYCLE does not have a relationship to another entity type MOTORCYCLE is not shown as it does not satisfy conditions for a subtype discussed earlier – the only attributes of MOTORCYCLE are those that are common to all vehicles, there are no attributes specific to motorcycles. Further, MOTORCYCLE does not have a relationship to another entity type Powered by DeSiaMore 12

13. Example of generalization Three entity types: CAR, TRUCK, and MOTORCYCLE All these types of vehicles have common attributes Powered by DeSiaMore 13

14. Generalization to VEHICLE supertype So we put the shared attributes in a supertype Note: no subtype for motorcycle, since it has no unique attributes Powered by DeSiaMore 14

15. Specialisation In an example of specialisation, an entity type PART has identifier Part_No and other attributes Description, Unit_price, Location, Qty_On_Hand, Routing_Number and Supplier (a multivalued attribute as there may be more than one supplier) Some parts are internally Manufactured Parts whilst others are externally Purchased Parts (some parts are obtained from both sources – when the choice depends on factors such as manufacturing capacity, unit price of the parts etc.) Powered by DeSiaMore 15

16. Specialisation Some attributes apply to all parts regardless of source, others such as Routing_Number depend on the source as they apply only to Manufactured Parts. This suggests that PART should be specialised by defining the subtypes MANUFACTURED_PART and PURCHASED_PART A new relationship ‘Supplies’ has been created between PURCHASED_PART and SUPPLIER that allows users to more easily associate purchased parts with their suppliers The attribute Unit_Price is now associated with the relationship ‘Supplies’ so that the price may vary between suppliers Powered by DeSiaMore 16

17. Example of specialization Entity type PART Only applies to manufactured parts Applies only to purchased parts Powered by DeSiaMore 17

18. Specialization to MANUFACTURED PART and PURCHASED PART Note: multivalued attribute was replaced by a relationship to another entity Created 2 subtypes Powered by DeSiaMore 18

19. Business Rule Business rule: a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. EX1: A student may register for a section of a course only only if he/she has successfully completed the prerequisites for the course. EX2: A preferred customer qualifies for a 10% discount, unless he has an overdue account balance Powered by DeSiaMore 19

20. Business rules The major business rule for study is called action assertion:  rule expressing constraints/control of organizational actions Powered by DeSiaMore 20

21. Stating an action assertion Action assertions deal with the dynamic aspects of the organisation and impose “must/must not” and “should/should not” constraints on handling data An action assertion is the property of some business rule (called the anchor object) for a data handling action (such as create, update, delete etc.) and it states how the other business rules (called corresponding objects) act on the anchor object Powered by DeSiaMore 21

22. Stating an action assertion Examples of action assertions are: A course (anchor object) must have a course name (corresponding object). Here the action is updating the course name property of a course Powered by DeSiaMore 22

23. Previously the term “integrity constraint” was used. Now the term “business rules” encompasses more than just constraints, it is a new paradigm for specifying information systems requirements Business Rules Paradigm Powered by DeSiaMore 23

24. Paradigm Shift based on: Business rules are a core concept in an enterprise since they are an expression of business policy and guide individuals and aggregate behavior. Business rules can be expressed in term that are familiar to end users, allowing users to define and maintain their own rules. Business rules are highly maintainable. They are stored in a central repository, and each rule is expressed only once, then shared throughout the organization. Enforcement of business rules can be automated, through the use of software that can interpret the rules and enforce them using the integrity mechanisms of the DBMS Powered by DeSiaMore 24

25. Classification of Business Rules Structural constraints - business rules that define the static structure of the organization definitions domains relationships Operational constraints - business rules that constrain the ongoing operations of the organization. procedural declarative Powered by DeSiaMore 25

26. Classification of Business Rules Business Rules Structural Constraints Operational Constraints DeclarativeProceduralRelationships Domain Constraints Definitions Supertype/ Subtype Constraints FactsTerms Derived Base E-R Diagram Powered by DeSiaMore 26

27. Business Rules: Defining Structural Constraints Definitions Term - a word or phrase that has a specific meaning for the business. Fact - an association between two or more terms. Derived Fact - a fact that is derived from other facts or rules, using an algorithm or inference Powered by DeSiaMore 27

28. Domain Constraints A specification of the characteristics of the data values that can be associated with one or more attributes. ATTRIBUTE Attribute_nameDefinitionDomain_name Data_type Range Length DOMAIN Is_assigned_to Powered by DeSiaMore 28

29. Business Rules: Defining Operational Constraints Constraint base - is an organized collection of rules (or constraints), usually stored in a repository. Constraint language simple so that end users can understand them structured to be convertible to computer code Powered by DeSiaMore 29

30. Business Rules: Defining Operational Constraints Constrained object - an entity, attribute, or relationship on which operations are limited. Constraining object - an entity, attribute, or relationship that influences the ability to perform an operation or read another object. Powered by DeSiaMore 30