1. T81-490b Systems Analysis and Development Project Database Design – Creating the Physical Data Model – Part 1

2. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 Announcements Change to the Schedule Where we're going: Assignment #6: Process Modeling - due next week Talk about Physical Database tonight and next week Exam #2 Assignment #7: Data Dictionary - will be assigned tonight Assignment #8: Report and Screen Design 5 more class nights Tonight's Topic: Going from the Conceptual/Logical Model to the Physical Model Make Assignment #7 tonight

3. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 Take Quiz on Reading Assignment #6.

4. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 Make Assignment #7 now.

5. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 Making the transition from Conceptual data design to physical data design. In assignment #5, you created a model that was partly conceptual and partly logical. Here are some specific definitions.

6. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 Conceptual Data Model: - high-level, business-oriented view - non-critical details left out - emphasize the most important entities, attributes, and relationships Goal: clarity at a high level

7. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 Logical Data Model: - fully normalized - all attributes defined - all candidate keys specified - primary key identified - foreign key definitions clearly defined or implied - any remaining many-to-many are translated into associative entities - cardinality has been specified - optionality has been specified Goal: a complete document from which a physical database can be developed

8. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 Physical Data Model: - dependent on your physical DBMS - specified by DDL statements which will actually be used to create the database objects - may not be fully normalized Goal: creation of a physical database

9. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 Normalization -- a quick review Before we begin to create the Physical Model, we must make sure that our Logical Model is normalized. Normalization is essentially the process of identifying the one best place where each fact belongs. It is important for data integrity, and for ease of loading data into our database.

10. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 The Normal Forms - 1NF 1. Eliminate repeating groups 2. Eliminate/resolve non-atomic data 2NF 1. All attributes are dependent on the primary key 3NF 1. No relationships between the attributes This is corny and over-worn, but I'll say it anyway. In 3NF, "Every attribute depends upon the key, the whole key, and nothing but the key...... so help me Codd."

11. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 To ensure a working knowledge of Normalization, Do the Soccer exercise.

12. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 Break

13. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 The Physical Data Model The physical data model is created by transforming the logical data model into a physical implementation based on the DBMS to be used for deployment. It is very vendor-specific. You will need a good working knowledge of the DBMS. The term "model" is a little misleading. It is not a diagram, like ERD or DFD. It is basically a set of DDL to create the database objects. (Please note: this whole discussion assumes you will be using a Relational Database Management System.)

14. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 Basic Transformations 1. Transform Entities to Tables 2. Transform Attributes to Columns The naming rules of the DBMS may not let you keep the same names you had you had in the logical model. --> Look at handout on abbrev's. 3. Transform Domains to Data Types Each column must have a data type and size. Maybe decimals too. More about data types later. Maybe constraints on the columns. NOT NULL constraints Uniqueness constraints "Check" constraints: specific or range of values 4. Transform Relationships into Referential Contstraints Primary Keys and Foreign Keys A good CASE tool will generate DDL from your data model. Handout and discuss: ERD to DDL

15. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 Handout and discuss: ERD to DDL

16. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 Other physical model structures to be discussed later (next week) include: Physical data structures: - tablespaces, datafiles, extents, blocks, rows Performance structures: - indexes Security features: -- grants, views

17. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 Performance -- preliminary introduction What are the performance issues? - Essentially: How fast does it run? (Does it run fast enough?) - Possibly also: How well does it scale? (well enough?) Scalability - It worked in test with small amounts of data. - Results were correct. - It ran fast. - Why wouldn't it be the same in production? - You will soon scale up. Maybe data is gradually added to the system. - The results (hopefully) will still be correct. - As volume increases, things start to slow down. Why? What's the solution to these issues? Performance Tuning / Design for Performance

18. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 Denormalization Why denormalize? One reason only: performance. Don't denormalize because you think it might be helpful. Try your best to tune the performance first. Do it as a last resort in a long performance tuning effort. It is disruptive. It takes time (maybe downtime to the end users). It could be interpreted as you fixing an implementation mistake. Document what you did, why you did it, and when.

19. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 The downside: redundant data. Now, when you load that data, you must load it in more than one place. How to handle that fact? If you do it in programs - you might forget, in a new program. - it's a lot of work that way - adhoc user adds a row of data – then suddenly you're off You might use Triggers - at the database level - independent of programs or adhoc users

20. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 Examples of reasons you might denormalize: (NOT an exhaustive list) 1. Prejoined Tables If the join must done often, and is prohibitively expensive. Advantage: you do the join only once. Must be periodically refreshed or rebuilt (which will do the join again). In Oracle, this is called a Materialized View. 2. Report Tables Often a report cannot be generated using SQL only. You can create a Prejoined Table with just the information needed for the report. Then write a program to do a simple SELECT from the report table and then do the remainder of the formatting. 3. Derivable Data If the cost (in cpu cycles) is prohibitive, you might physically store such calculated data instead of calculating it on the fly each time.

21. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 Handout the Soccer "partially denormalized" solution -- discuss.

22. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 A note about Disk Utilization In the olden days, disk was very expensive. Now, it is "cheap". But don't be wasteful due to 1) incomptence, or 2) apathy Another Triple constraint triangle (no, this is not on the Exam) - Storage -- don't squander disk - Performance -- don't spend time packing/unpacking, compress/decompress, decoding - Maintainability -- don't be so cryptic that nobody can understand your code Watch out for the ever expanding data store where no data is ever deleted. Design a plan to archive and delete old data that is no longer actively used See chart on next slide…

23. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12

24. x

25. T81-490b -- Database Design – Creating the Physical Data Model – Part 1 -- Class #12 x