1. RELATIONAL DATA MODELING MIS2502 Data Analytics

2. What is a model? Representation of something in the real world

3. Modeling a database A representation of the structure of the data Describes the data contained in the database Explains how the data interrelates A student is part of a section, which is part of a course

4. Why bother modeling? Creates a blueprint before you start building the database Gets the story straight: easy for non-technical people to understand Minimize having to go back and make changes in the implementation stage

5. The process of analysis and design Systems Analysis Analysis of complex, large-scale systems and the interactions within those systems http://en.wikipedia.org/wiki/Systems_analysis Systems Design The process of defining the hardware and software architectures, components, models, interfaces, and data for a computer system to satisfy specified requirements http://en.wikipedia.org/wiki/Systems_design Notice that they are not the same!

6. Basically… Systems Analysis is the process of modeling the problem Requirements-oriented What should we do? Systems Design is the process of modeling a solution Functionality-oriented How should we do it? This is where we define and understand the business scenario. This is where we implement that scenario as a database. In the context of database development.

7. Start with a problem statement “We want a database to track orders.” That’s too vague to create a useful system, so we then gather requirements to learn more Gather documentation About the business process About existing systems Conduct interviews Employees directly involved in the process Other stakeholders (i.e., customers) Management Why are each of these important? Are there others? Why are each of these important? Are there others?

8. Start with a problem statement Refine the problem statement Getting iterative feedback from the client End up with a scenario like this: The system must track customer orders Multiple products can go into an order A customer is described by their name, address, and a unique Customer ID number An order is described by the date in which it was placed, what was bought, and how much it costs The specification “what was bought” is a little vague, and that will cause us a problem a little later. But let’s leave it for now… The specification “what was bought” is a little vague, and that will cause us a problem a little later. But let’s leave it for now…

9. The Entity Relationship Diagram (ERD) The primary way of modeling a relational database Part of the “analysis” process Implemented as a picture with three key elements Entity Relationship A uniquely identifiable thing (i.e., person, order) Describes how two entities relate to one another (i.e., makes) Attribute A characteristic of an entity or relationship (i.e., first name, order number)

10. A very simple example Customer First name makes Order Last name City State Zip Price Product name Order Date Order number Customer ID

11. The primary key Entities need to be uniquely identifiable So you can tell them apart when you retrieve them Use a primary key An attribute (or a set of attributes) that uniquely identifies an entity Order number Customer ID Uniquely identifies a customer Uniquely identifies an order How about these as primary keys for Customer: First name and/or last name? Social security number? How about these as primary keys for Customer: First name and/or last name? Social security number?

12. Last component: Cardinality Defines the rules of the association between entities Customer makes Order This is a one-to-many relationship: One customer can have many orders One order can only belong to one customer at least – one at most - many at least – one at most - one

13. Crows Feet Notation Customer makes Order There are other ways of denoting cardinality, but this one is pretty standard. So called because this… …looks something like this There are also variations of the crows feet notion!

14. Cardinality is defined by business rules What would the cardinality be in these situations? Order contains Product ? ? Course has Section ? ? Employee has Office ? ?

15. But we have a problem with our ERD This assumes every order contains only one product. So if I want two products, I have to make two orders! The problem: Product is defined as an attribute, not an entity. (Because we didn’t define our requirements clearly enough?)

16. Here’s a solution Now A customer can make multiple orders An order can contain multiple products A product can be part of multiple orders Customer First name makes Order Last name City StateZip Price Product name Order Date Order number Product contains Customer ID Quantity

17. Implementing the ERD As a database schema A map of the tables and fields in the database This is what is implemented in the database management system Part of the “design” process A schema actually looks a lot like the ERD Entities become tables Attributes become fields Relationships can become additional tables

18. Structure of a database Data elementDescription CharacterSingle letter or number (“A”, “Z”, “1”) FieldSet of related characters (first name) RecordSet of related fields (all information about a customer) TableSet of related records (all customers in the company) DatabaseSet of related tables (all information about the company)

19. The Rules Primary key field of “1” table put into “many” table as foreign key field 1:many relationships Create new table 1:many relationships with original tables many:many relationships Primary key field of one table put into other table as foreign key field 1:1 relationships 1. Create a table for every entity 2. Create table fields for every entity’s attributes 3. Implement relationships between the tables

20. Our Order Database schema Order-Product is a decomposed many-to-many relationship Order-Product has a 1:n relatonship with Order and Product Now an order can have multiple products, and a product can be associated with multiple orders Original 1:n relationship Original n:n relationship

21. What the Customer and Order tables look like CustomerIDFirstNameLastNameCityStateZip 1001GregHousePrincetonNJ09120 1002LisaCuddyPlainsboroNJ09123 1003JamesWilsonPittsgroveNJ09121 1004EricForemanWarminsterPA19111 Order Number OrderDateCustomer ID 1013-2-20111001 1023-3-20111002 1033-4-20111001 1043-6-20111004 Note that there are no repeating records Every customer is unique Every order is unique This is an example of normalization. Note that there are no repeating records Every customer is unique Every order is unique This is an example of normalization. Customer Table Order Table

22. Normalization Organizing data to minimize redundancy (repeated data) This is good for two reasons The database takes up less space You have a lower chance of inconsistencies in your data If you want to make a change to a record, you only have to make it in one place The relationships take care of the rest But you will usually need to link the separate tables together in order to retrieve information

23. To figure out who ordered what Match the Customer IDs of the two tables, starting with the table with the foreign key (Order): We now know which order belonged to which customer This is called a join But it’s an inefficient way to store data (redundancies) So we normalize Order Number OrderDateCustomer ID FirstNameLastNameCityStateZip 1013-2-20111001 GregHousePrincetonNJ09120 1023-3-20111002 LisaCuddyPlainsboroNJ09123 1033-4-20111001 GregHousePrincetonNJ09120 1043-6-20111004 EricForemanWarminsterPA19111 Order Table Customer Table

24. Now the many:many relationship Order Number OrderDateCustomer ID 1013-2-20111001 1023-3-20111002 1033-4-20111001 1043-6-20111004 Order Table ProductIDProductNamePrice 2251Cheerios3.99 2282Bananas1.29 2505Eggo Waffles2.99 Product Table Order ProductID Order number Product IDQuantity 110122512 210122823 310125051 410222515 510222822 610325053 710425058 Order-Product Table This table relates Order and Product to each other!

25. To figure out what each order contains Match the Product IDs and Order IDs of the tables, starting with the table with the foreign keys (Order-Product): Order ProductID Order Number Product ID QuantityOrder Number Order Date Customer ID Product ID Product Name Price 1101225121013-2-201110012251Cheerios3.99 2101228231013-2-201110012282Bananas1.29 3101250511013-2-201110012505Eggo Waffles2.99 4102225151023-3-201110022251Cheerios3.99 5102228221023-3-201110022282Bananas1.29 6103250531033-4-201110012505Eggo Waffles2.99 7104250581043-6-201110042505Eggo Waffles2.99 Order-Product TableOrder TableProduct Table Now there is redundant product data as a result of the join!

26. Why redundant data is a big deal The redundant data seems harmless, but: What if the price of “Eggo Waffles” changes? And what if Greg House changes his address? And if there are 1,000,000 records? The redundant data seems harmless, but: What if the price of “Eggo Waffles” changes? And what if Greg House changes his address? And if there are 1,000,000 records?

27. Best practices for normalization Create new entities when there are collections of related attributes, especially when they would repeat For example, consider a modified Product entity Price Product name Product Vendor Name Vendor Address Vendor Phone Price Product name Product Vendor Name Vendor Address Vendor Phone Vendor sells Don’t do this… …do this. Then you won’t have to repeat vendor information for each product. …do this. Then you won’t have to repeat vendor information for each product. Vendor ID ? Why did we introduce VendorID?

28. Best practices for normalization Create new entities to enforce data entry standards Customer First name Last name City StateZip Customer ID Customer First name Last name City ID Zip Customer ID City City Name State ID State State Name This is fine… …but this can be even better. ! The city name is entered only once in the City table; CityID is used in Customer table

29. City and State as “lookup tables” Why this can be a better way of doing it CustomerIDFirstNameLastNameCityIDStateIDZip 1001GregHouse1109120 1002LisaCuddy2109123 1003JamesWilson3109121 1004EricForeman4219111 CityIDCityName 1Princeton 2Plainsboro 3Pittsgrove 4Warminster StateIDStateNameAbbr 1New JerseyNJ 2PennsylvaniaPA This helps prevent inconsistent spellings (Pennsylvania is always entered as “2”) Customer City State Customer First name Last name City ID Zip Customer ID City City Name State ID State State Name

30. The three-way relationship Sometimes three entities are necessary to capture what happens in a transaction This would be modeled as an many-to-many- to-many relationship Mechanic Model Make Salary Description Car Performs Repair date Repair Charge Name Employee ID Repair code VIN

31. The many:many:many table The many-to-many-to-many relationship would still be represented as a separate table Just with three foreign keys, instead of two RepairIDRepairCodeEmployeeIDVINRepair date 11019112101929192012011-3-1 22012313192929192912011-3-2 330212311020100232011-3-3 422321323938483832011-3-4