Data Modeling ISYS 464

Database Design Process Conceptual database design: The process of creating a data model independent of implementation details such as the target database model and physical considerations. Logical database design: The process of designing database logical structure based on a specific database model (such as relational model), but independent of a particular DBMS and physical considerations. Physical database design: The process of implementing the database on a secondary storage.

Requirements Collection and Analysis The process of collecting and analyzing information about the organization that is to be supported by the database system, and use this information to identify the requirements for the new system.

User Views A user view defines what is required of a database system in terms of the data to be held and transactions to be performed on the data from the perspective of a particular job role or enterprise application area. Identifying user views helps to ensure that no major users of the database are forgotten when developing the requirements for the new database system.

Example of User’s View Shopping cart Bottom-Up approach

Fact-Finding Techniques Examining documentation Defining problem and need for database: Internal memos, minutes of meetings, documents that describe the problem, organizational chart Describe the current system: Various types of flowcharts and diagrams, data dictionary, database system design, program documentation Interviewing Observing the enterprise in operation Questionnaires

Conceptual Database Design Methodology Identify entity types. Identity relationship types between the entity types. Identify and associate attributes with entity or relationship types. Determine attribute domains. Determine candidate keys and primary key. Validate conceptual model: Check for redundancy, support required transactions, review the model with user

Entity-Relationship Diagram ER modeling is a top-down approach to database design that begins by identifying the entities and relationships between entities that must be represented in the model. Relative ease of use. Widespread CASE tool support. The belief that entities and relationships are natural modeling concepts in the real world.

ERD Models Entities and Business Rules Example: A customer may submit any number of orders. However, each order must be submitted by exactly one customer. A student may register for a section of a course only if he or she has successfully completed the prerequisites for that course.

Entities An entity is a person, place, object, event, or concept in the user environment about which the organization wishes to maintain data. Person: Employee, Student, patient Place: Warehouse, Store Object: Product, Machine. Event: Registration, Sale, Renewal Concept: Account, Course Physical existence: Customer, student, product, etc. Conceptual existence: Bank accounts, sale

Entity Type A collection of entities that share common properties or characteristics. An entity type represents a collection of entities. In an ERD, it is given a singular name. Diagrammatic representation: A rectangle labeled with the name of the entity

Entity Instance An entity instance is a single occurrence of an entity type: Student entity: SID, Sname, Major Two instances of Student entity type: S1, Peter, Bus S5, Paul, Sci

Relationship Type Relationship: Interaction between entity types. It is an association representing an interaction among the instances of one or more entity types that is interest to the organization. It has a verb phrase name: Faculty teach Course, Faculty advise Student Customer open Account, Customer purchase Product.

Figure 3-10 Relationship types and instances a) Relationship type b) Relationship instances 17

Degree of a Relationship The number of participating entity types in a relationship. Unary (recursive) Binary Ternary

Three kinds of Binary Relationship 1:1 1:M M:M

M:M Relationship Peter Paul John Woody Alan Mary Linda Nancy Mia Pia Girl Boy A boy may date 0, 1, or many girls. A girl may date 0, 1, or many boys.

1:1 Relationship Husband Peter Paul John Woody Alan Mary Linda Nancy Mia Pia Wife A man may marry 0 or 1 woman. A woman may marry 0 or 1 man.

1:M Relationship Father Child Peter Mary Brian Paul Linda Aron John Woody Alan Mary Brian Linda Aron Nancy Ronald Mia Pia Child A father has 1 or many children. A child has 1 father.

Cardinality Constraint A cardinality constraint specifies the number of instances of entity A that can (or must) be associated with each instance of entity A. Participation constraint Full participation (Mandatory) Partial participation (Optional)

Notations

Other Notations UML Notations: Traditional: 0..1, 1..1 0..*, 1..* 3..5 Has Student Account 1..1 1..1 1 1 Student Has Account

1:1 Relationship Examples: Husband, Wife State, State Governor Order, Invoice

1:M Relationship Examples: Father, Child Department, Employee Customer, Order

M:M Relationship Examples: Boy friend, Girl friend Bank customer, Bank account Student, Student organization

Traditional ERD Notations 1 1 Student Has Account M M M Enroll Advise 1 M Faculty 1 Teach Course

UML ERD Notations Has Student Account 0..* 0..* 0..* Faculty Course 1..1 1..1 0..* Enroll Advise 0..* 0..* 1..1 Faculty Teach Course 1..1 1..*

Book Notations Has Student Account 0..* Faculty Course Enroll Advise Teach Course

Other Examples A database to record visitors and web pages they view. An online shopping website database to record customers, orders (shopping carts) and products purchased by customers. An auction database to record sellers and the items they sell, buyers and the items they purchase. University email account database to record students, email accounts and email messages.

Recursive Relationship A relationship type where the same entity type participates more than once in different roles. Examples: Employee – Supervise -- Employee Student -- Tutor– Student Faculty – Evaluate -- Faculty

Supervise Supervisor Employee Superviswee Employee Supervise

Attributes Properties of an entity or a relationship. Simple and composite attributes Address:Street address, City, State, ZipCode Street Address: Number, Street, Apt# Single-valued and multi-valued attributes Student’s Major attribute Faculty’s DegreeEarned attribute Vehicle’s Color attribute Others: PhoneNumber, EmailAddress Derived attributes Keys Candidate key, primary key, composite key

UML otations Student SID {PK} Sname Fname Lname Address Street City State Zip Phone[1..3] Sex DateOfBirth /Age

SID {PK} Sname( Fname, Lname) Address( Street, City, State, Zip) {Phone} Sex DateOfBirth [Age]

Fname Lname Phone DateOfBirth SID Sname Age Student

Domains of Attributes The set of allowable values for one or more attributes. Input validation Examples: Sex: F, M EmpHourlyWage: Between 6 and 300 EmpName: 50 charcters

Time-Dependent Attributes Auditing Reconstructing the database state at a point in time: Database snapshot Regulations: Sarbanes-Oxley Public Company Accounting Reform and Investor Protection Act of 2002 and commonly called SOX or SarbOx; July 30, 2002) Example: ProductPrice: PID, {PriceHistory(Price, TimeStamp)}

Attributes on Relationship Online Shopping Cart Addr CartID Date CID Cname Has M ShoppingCart Customer 1 M Has M Product Price PID Pname

Online Shopping Cart Addr CartID Date CID Cname Has M ShoppingCart Customer 1 M Qty Has M Product Price PID Pname

Attributes on Relationship Examples: Student/Course: Grade Order/Product: Quantity Product/Country: Date, Quantity

Enroll 0..* 0..* Student Course Student Course SID CID Grade Enroll M M Course Grade

N-ary Relationship Doctor – Patient – Ailment Police – Crimal – Crime AirCraft – Bomb - Target

Figure 3-12 Examples of relationships of different degrees (cont.) c) Ternary relationship Note1: a relationship can have attributes of its own. Note2: This ternary relationship exists only if there is no binary relationship between these three entities. 22

Problems with ER Models Connection Traps Fan traps: Where a model represents a relationship between entity types, but the pathway between certain entity occurrences is ambiguous Has Oversees Branch Staff Division 1..* 1..1 1..1 1..* Which branch does Peter work? Has Oversees Branch Staff Division 1..* 1..1 1..* 1..1

Chasm Traps Where a model suggests the existence of a relationship between entity types, but the pathway does not exist between certain entity occurrences. Has Oversees Branch Staff PropertyFor Rent 1..* 1..1 0..1 0..* Which properties are available at each branch?

Entity Type not System User or Organizational Unit Report Me SendTo MyCompany Department Has Note: An entity type represents a collection of entities.

Figure 3-21 Examples of multiple relationships a) Employees and departments Entities can be related to one another in more than one way 40

Online Shopping Cart Addr CartID Date CID Cname Has M ShoppingCart Customer 1 M Query database: How many carts generated for customer “Peter” Products ordered in a cart. Total amount of a cart. Today’s total sales. Total sales by products. Qty Has M Product Price PID Pname