1. Chapter 2 Database System Design Based on G. Post, DBMS: Designing & Building Business Applications University of Manitoba Asper School of Business 3500 DBMS Bob Travica Updated 2015

2. DBSYST DDBBSSYYSSTTEMEMSSDDBBSSYYSSTTEMEMSSS DBS Development Specifications for storage & access methods (indexes), and forms & reports Class diagram (classes & relationships) and write business rules. Business & information needs. Pros & cons. System require- ments. Business case. Analysis Create data model. Customer(CID, Name,..) SalesPerson(EID, Name..) Order(OrderID, EID, CID, OrderDate..) Adjust data model to a database technology (e.g., relational). Design storage & input/output. List or diagram of normalized tables (schema). Design ( Logical, Physical ) Construction TASK RESULT 2 of 17

3. DBSYST DDBBSSYYSSTTEMEMSSDDBBSSYYSSTTEMEMSSS Unified Modeling Language (UML) Trendy notation for analyzing systems and often used with the object orientation (OO) approach. Contains specific sorts of diagrams: The class diagram is most important for DB systems. Similar to the old Entity-Relationship diagram (E-R diagram) but more compact. 3 of 17

4. DBSYST DDBBSSYYSSTTEMEMSSDDBBSSYYSSTTEMEMSSS Class Diagram – Concepts Entity:The aspect of reality recorded in the system. Class: Description of an entity, which includes its attributes (properties) and behavior (methods, procedures). Object:One instance of a class with specific data; a record in a database. Attribute:A data property of a class; an aspects of an entity. Behavior:Procedures (methods, processes, functions) performed by the class. Association: A connection between classes or between entities. 4 of 17

5. DBSYST DDBBSSYYSSTTEMEMSSDDBBSSYYSSTTEMEMSSS Entity:Customer Class: Customer, includes attributes and behavior (below) Object:12257, Joe Jones... (a specific customer) Attributes:CustID, Name... Behavior:AddCustomer, DeleteCustomer... (CRUD) Association: Class Customer is related to class Order reflecting relationship between entities Customer and Order. Examples from Pet Store Application 5 of 17

6. DBSYST DDBBSSYYSSTTEMEMSSDDBBSSYYSSTTEMEMSSS Associations  Associations (Relationships) reflect business specified in business rules*  Sometimes common-sense rules (Figure A) NOTE: Assumed way of reading is left-right and top-down. If the relationship is drawn that way, the arrowhead is not necessary. Arrowheads needed when these rules are not followed (Figure B). places  (A) Customer Order  belongs to (B) Customer Product Search Profile  Sometimes rules unique to an organization (Figure B) 6 of 17

7. DBSYST DDBBSSYYSSTTEMEMSSDDBBSSYYSSTTEMEMSSS Association Degree refers to the number of classes involved in an association: 1) Class with itself – unary (below); rare Degree of Association Employee manager worker  manages 2) Between 2 classes – binary (previous slide); most frequent and most important!) 3) Between 3 or more classes – N-ary; rare 7 of 17

8. DBSYST DDBBSSYYSSTTEMEMSSDDBBSSYYSSTTEMEMSSS Example: An employee must work in only one department, and one (each) department has one or more employees. Multiplicity (Cardinality*) of Associations Multiplicity refers to the number of objects participating in a relationship. Department Employee works in 1..1 1..* Just maximum multiplicity is often used, and associations are classified on it as well. Department Employee works in 1 * Example: many-to-one (M:1) relationship 8 of 17

9. DBSYST DDBBSSYYSSTTEMEMSSDDBBSSYYSSTTEMEMSSS  One-to-many (1:M) - examples: Customer—Order, Client—Account  Many-to-many (M:N) - examples: Order—Item, Student—Course  One-to-one (1:1) - example: Customer—BillingAddress, Citizen-- SocaiInsuranceUser (IncomeTaxPayer…) Types of Associations based on Multiplicity 9 of 17

10. DBSYST DDBBSSYYSSTTEMEMSSDDBBSSYYSSTTEMEMSSS Procedure for Determining Multiplicity (Form A question) And…  1.Ask the multiplicity question: One (each) object on the left side of the association is associated with how many objects on the right side? Minimally, maximally? Department Employee works in Department Employee works in 1..1 2. Write the numbers/asterisks on the right side. 10 of 17

11. DBSYST DDBBSSYYSSTTEMEMSSDDBBSSYYSSTTEMEMSSS 3. Ask the same question from the other side of the relationship: One (each) object on the right side of the association is associated with how many objects on the left side? Minimally, maximally? Department Employee <employs 1..1 Department Employee <employs 1..1 1..* 4. Write the numbers/asterisks on the left side. Or  Note: You need to memorize the multiplicity question! 11 of 17

12. DBSYST DDBBSSYYSSTTEMEMSSDDBBSSYYSSTTEMEMSSS 1. How many objects on the left side are associated with one (each) object on the right side? 2. Write the numbers/asterisks of the left side. Procedure for Determining Multiplicity (Form B question) Note: We usually need to ask just about maximum multiplicity. 3. How many objects on the right side are associated with one (each) object on the left side? 4. Write the numbers/asterisks on the right side. Department Employee works in  1..1 1..* 12 of 17

13. DBSYST DDBBSSYYSSTTEMEMSSDDBBSSYYSSTTEMEMSSS NOTE: Some imprecision in Fig. 2.8 p. 49 in 5 th ed. (p. 46 4 th ed.): “Order” is called “Sale” in sentence two. Notation for Multiplicity  Multiplicity options:  0 (zero)  1 (one)  * (many); also labeled as M or N  specific number, if known (3, 10); e.g., in part-whole relationship Customer Order Item 1..1 1..* 0..* 1..*. places contains Order_Item 13 of 17

14. DBSYST DDBBSSYYSSTTEMEMSSDDBBSSYYSSTTEMEMSSS Business Rules for Cardinality - Read/Write  1) One customer can place one or more orders, and each order is placed by one and only one customer.  2) Each order can contain one or more items, and an item can be listed on no (0) order or on many orders. * Business Rules: If min. multiplicity >= 1, association is mandatory; If min. multiplicity = 0, association is optional. Customer Order Item 1..1 1..* 0..* 1..*. places contains Order_Item 14 of 17

15. DBSYST DDBBSSYYSSTTEMEMSSDDBBSSYYSSTTEMEMSSS N-ary Association  Degree of association => 3. The above diagram shows ternary association, not three binary associations.  Components are assembled into Products by Employees. Simultaneous, inter-dependent relationships. Read multiplicity.  Support to inventory scheduling, quality control, performance measurement.  But, the data model is not complete as shown! Employee Component Product * * * * * * NOTE: Some imprecision in Fig. 2.9 on p. 49 in 5 th ed. (p. 46 in 4 th ed.). An association between Employee and Component missing; incorrect way of stating M:M multiplicity. assembled by assembles assembled in 15 of 17

16. DBSYST DDBBSSYYSSTTEMEMSSDDBBSSYYSSTTEMEMSSS N-ary Association with Associative Class  N-ary associative class Assembly introduced. Product ProdID Name Employee EmpID Name Component CompID Type Name Assembly Date Time EmpIDProdIDCompIDDateTime 11A32225632013/01/0207:15 11A32228722013/01/0207:30 11A54115632013/01/0207:45 11A54118722013/01/0207:55 12A32225632013/01/0213:00 12A32228822013/01/0315:30 assembled by assembles assembled in  The key in Assembly combines keys from source associated classes. Its own attributes are Date and Time. Table Assembly: 16 of 17

17. DBSYST DDBBSSYYSSTTEMEMSSDDBBSSYYSSTTEMEMSSS Focus on Keys: Generic vs. Unique  Product: specific model of car (ProdID is a generic key signifying a group of things, many instances)  Component: car door (CompID is a generic key)  Employee: assembly worker (EmpID is a unique key signifying a specific person, one and only one instance)  This design can use unique keys (e.g., serial numbers) for products and components. 17 of 17