1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen Conditions & Roles These slides are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. For more information on how you may use them, please see

2© Ellis Cohen Overview of Lecture Pre-Conditions Post-Conditions Using Operation Conditions User Roles Roles & Entity Classes

3© Ellis Cohen Pre-Conditions

4© Ellis Cohen Pre-Conditions A Pre-Condition is a condition that should be checked immediately BEFORE a specific operation is permitted to execute. Pre-conditions are used to determine whether an operation should be permitted to execute

5© Ellis Cohen Pre-conditions for Update Job Entry UpdateJobEntry( :jobno, :compid, :loc, :startdate, :enddate, :descr ) –Updates the current user's :jobno'th job entry Pre-Conditions: Current user must be a job candidate with an existing job entry numbered by :jobno :compid must be the id of a company in the database :enddate must be after :startdate

6© Ellis Cohen Enforcing Pre-Conditions Pre-conditions are typically enforced by Adding code at beginning of an operation which checks whether the condition is satisfied (often involving a database query) If an error would be raised (e.g. by the database) if the operation would allowed to proceed, let it, and handle the error appropriately.

7© Ellis Cohen Types of Pre-Conditions Pre-conditions are (in order of weakest to strongest) Soundness Pre-Conditions –determine whether the operation makes sense, strictly based on the parameters to the operation Status Pre-Conditions –determine whether the operation can take place based on the current status of the database or the environment, but not based on the user (or client) User Pre-Conditions –determine whether the current user (or client) is allowed to perform the operation

8© Ellis Cohen Soundness & Status Examples Soundness-Based example –AddJobEntry( :compid, :title, :location, :startDate, :endDate, :details ) :enddate must be after :startdate Status-Based example –AddJobEntry( :compid, :title, :location, :startDate, :endDate, :details ) :compid must be the id of a company in the database

9© Ellis Cohen User Pre-Conditions Determines whether the current user (or client) is authorized to perform the operation, or whether the parameters are appropriate for that user –Always refers to the role or (some DB information tied to the) identity of the current user/client Role-Based User Pre-Conditions –Only requires checking the role of the current user Identity-Based User Pre-Conditions –Requires checking (some DB information tied to the) identity of the current user

10© Ellis Cohen User Pre-Condition Examples Role-Based example –AddJobEntry( :compid, :title, :location, :startDate, :endDate, :details) The current user's role must be a JobCandidate Identity-Based example –UpdateJobEntry( :jobno, :compid, :title, :location, :startDate, :endDate, :details ) The current user must have a jobno'th job entry

11© Ellis Cohen Post-Conditions

12© Ellis Cohen Post-Conditions A Post-Condition is a condition that you expect to be true immediately AFTER a specific operation executes Post-conditions are used to ensure that an operation executed correctly, and to characterize everything that it needs to do

13© Ellis Cohen Post-Conditions for RemoveCandidate RemoveCandidate –Removes the current user as a candidate Post-Conditions: The current user is no longer a candidate There are no remaining job entries for the current user Boring Interesting What makes a post-condition interesting?

14© Ellis Cohen Interesting Post-Conditions Interesting Post-Conditions have one or more of the following characteristics Don't obviously or immediately follow from a simple description of the operation Not a condition that is invariant (i.e. always true); the operation made it true Involve changes to entity classes or relationships other than the one that the operation obviously needs to affect Ensure that redundant data is kept consistent

15© Ellis Cohen Types of Post-Conditions State-Related Post-Conditions –characterizes resulting changes to the database state -- e.g. the candidate's job entries must have all been deleted Output-Related Post-Conditions –characterizes resulting properties of the operation output -- usually situations under which less information than expected was displayed External Post-Conditions –characterizes resulting changes to the external environment -- e.g. a message was sent, etc. Main Focus

16© Ellis Cohen Output-Related Post-Condition for ShowCompaniesWithPostings ShowCompaniesWithPostings –Shows companies which have job postings Output-Related Post-Condition: if current user is not a premium member, only shows companies with postings more than 5 days old

17© Ellis Cohen Using Operation Conditions

18© Ellis Cohen Operation Conditions Pre-Condition: Condition that should be checked before an operation is executed Used to determine if an operation should be allowed to execute Post-Condition: Condition that can be checked after an operation is executed Used to ensure that an operation executed correctly characterize everything it needed to do

19© Ellis Cohen Enforcing Operation Conditions There are two places to enforce operation conditions Application Enforcement: –Enforce constraints through code executed by an operation Database Enforcement: –Use built-in database features to automatically enforce constraints in the data-tier column constraints, table constraints, assertions, views, triggers & access control

20© Ellis Cohen Value of Operation Conditions Why is it important to specify operation conditions? –They often correspond to business rules (in the requirements), perhaps added in a later revision –Clarifies intent and semantics of user operations –Helps discover deficiencies in the conceptual ER model –Enforcing conditions helps ensure that database applications work correctly!

21© Ellis Cohen Operation Conditions & Business Rules Business Rules specify/ determine 1.Conceptual Model 2.User Operation Functionality 3.Behavior Constraints & Operation Conditions constraints and conditions on the behavior of user and database operations 4.State Constraints constraints on the state of the data that's allowed to be stored in the database 5.Performance Requirements Operation Conditions are just part of the business rules of a database application

22© Ellis Cohen User Roles

23© Ellis Cohen User Roles A user role characterizes a kind of user who uses a particular database application Users who take on different roles (are allowed to) use different sets of operations What are the roles (i.e. names for different groups of users) for the Job Board application?

24© Ellis Cohen Job Board User Roles Different users of the system play different roles. The two roles we've discussed are –Job Candidate –Company Representative There are other roles as well (which we won't discuss now) –Administrator (too complicated) –UnknownUser (someone who is not logged in, but perhaps can still get some job board information)

25© Ellis Cohen Organizing User Operations Why use roles?  Organizing operations by role & by operation type helps ensure that the list of operations is complete, and that we really understand what we expect the application to be able to support Roles QueriesActions Job Candidate Show Company Postings Show Company Info … Add Job Entry … Company Representative Show Company Postings Show Company Info … Add Job Posting …

26© Ellis Cohen Common Operations Are there any operations that are common to both roles (i.e. to both groups of users)? YES  Use super-roles so that an operation can be associated with just a single role!

27© Ellis Cohen Super-Roles and Sub-Roles Job Candidate User Means two things (BOTH are important!) A Job Candidate is a kind of User (but not every User is a Job Candidate) Every operation that a User is allowed to perform can also be performed by a Job Candidate User Role Diagram User is a super-role of Job Candidate Job Candidate is a sub-role of User

28© Ellis Cohen Multiple Subroles User Job Candidate Company Representative User is a super-role of Company Representative and Job Candidate User Role Diagrams show the roles used in an application and the relationships among them. They are a simplification of UML Use Case Diagrams in which just the actors are shown User Role Diagram

29© Ellis Cohen Reorganizing User Operations Roles QueriesActions User Show Company Postings Show Company Info … … Job Candidate …Add Job Entry … Company Representative …Add Job Posting … Allows common operations to be associated with the common super-role

30© Ellis Cohen Designing with Role Hierarchies Role hierarchies simplify design. They allow an operation to be associated with just a single role. Suppose an operation can be performed by (1) a Company Representative, (2) a Job Candidate and (3) potentially any other kind of User Instead of having to associate the operation with all 3 roles, we simply note that Job Candidate and Company Representatives are subroles of User, and just associate the operation with the User role. Why use role hierarchies?

31© Ellis Cohen Disjoint Subroles Job Candidate Company Representative User Means that the same user can't play the roles of Job Candidate and Company Representative simultaneously. User is a super-role of Company Representative and Job Candidate User Role Diagram

32© Ellis Cohen Overlapping Subroles User Job Candidate Company Representative User is a super-role of Company Representative and Job Candidate Because Company Representative and Job Candidate are not disjoint, a user can perform operations associated with either role at the same time, without having to explicitly change roles, or log out and log back in. User Role Diagram

33© Ellis Cohen Role Reorganization Problem Suppose there were three groups of users: Job Candidates, Company Representatives & Administrators. Suppose there was a new operation added that Company Representatives & Administrators could do, but not Job Candidates. If so, how would we reorganize this diagram so that an operation is still only assigned to a single role? Job Candidate Company Representative User Administrator User Role Diagram

34© Ellis Cohen Role Reorganization Solution Job Candidate Company Representative User Administrator Privileged User Define new common role & assign operation to this role User Role Diagram Does this meet the "kind-of" requirement?

35© Ellis Cohen Known & Unknown Users Job Candidate Company Representative Known User User Role Diagram User Anyone with access to the system A logged-in user Unknown User A user who is not logged-in

36© Ellis Cohen Logout and Login Why is it important to distinguish –a KnownUser (who is logged in) from –an UnknownUser (who isn't)? We do not know who a user is before she logs in, or after she logs out –The Login operation changes the current user's role from UnknownUser to KnownUser (or a subrole of it) –The Logout operation changes the current user's role back to UnknownUser A user who is already logged in should not be able to log in again –This is enforced automatically if we only allow Login to be performed by a user whose role is UnknownUser A user should not be able to logout if they are already logged out –This is enforced automatically if we only allow Logout to be performed by a user whose role is KnownUser (or a subrole of it) Note: More generally, a result of an action can be a change to the user's role

37© Ellis Cohen Known vs Unknown User Operations Roles QueriesActions Unknown User Login Register Candidate Register Company Known User Show Company Postings Show Company Info … Logout … Job Candidate …Add Job Entry … Company Representative …Add Job Posting …

38© Ellis Cohen Role-Based User Pre-Conditions Assigning an Operation to a Role implicitly defines a role-based user pre-condition –Assigning ShowMatchingCompanies to the JobCandidate role is equivalent to –ShowMatchingCompanies Pre-Condition: The user must be a job candidate

39© Ellis Cohen Roles & Entity Classes

40© Ellis Cohen Entity-Relationship Diagrams Entity-Relationship diagrams –Reflect the static relationships between data persistently stored in the database They do NOT need to reflect –Temporary data structures –Users or roles (unless information is retained about them beyond what is needed for authentication, or if authentication info is stored in the DB) –Operations users might be able to do or have done, unless needed for auditing purposes –Flow of information among tables or between tables and users (i.e. they are not process modeling diagrams)

41© Ellis Cohen Job Board Application: Easy Crow Magnum Diagram Candidate JobPosting job history includes open at postid candid JobEntry Company occurred at compid entryid

42© Ellis Cohen Possibly Expanded ER Diagram Candidate JobPosting job history includes open at postid candid JobEntry Company occurred at compid entryid Company Rep repid has views Is this a better ER model?

43© Ellis Cohen Questionable ER Diagram Expansion Candidate JobPosting job history includes open at postid candid JobEntry Company occurred at compid entryid Company Rep repid has views 1)Adding CompanyRep might make sense, but only so that when a CompanyRep logs in, we can find out their associated company. That's not even necessary if all company reps can login with the same company id, or if authentication & basic user info is managed outside the database (e.g. LDAP, Active Directory, etc.) 2)While company representatives certainly view candidate job entries, nothing suggests that we need to persistently keep track of that information.

44© Ellis Cohen Relationships & Persistence A relationship represents information which needs to be persistently stored in a database! If the information doesn't need to be stored and queried, don't represent it as a relationship Don't include relationships which simply show what a user can do or keep track of what a user has done, unless it is clear that information will be needed later! *