1. Daniel AdinugrohoDatabase Programming 1 DATABASE PROGRAMMING Lecture on 29 – 04 – 2005

2. Daniel AdinugrohoDatabase Programming 2 PREVIOUS LECTURE 1. Review of Introduction to Database – History of database 2. Review of Database Design – Table, Primary and Foreign Key – Simple database design 3. Introduction to Normalization – Why we need normalization – Applying normalization

3. Daniel AdinugrohoDatabase Programming 3 OVERVIEW OF DB DESIGN The database design can be divided into 6 steps: 1. Requirement Analysis 2. Conceptual Database Design 3. Logical Database Design 4. Schema Refinement 5. Physical Database Design 6. Security Design

4. Daniel AdinugrohoDatabase Programming 4 1. REQUIREMENT ANALYSIS This is a very first step in designing database application to understand: ● what data is stored in the database, ● what applications is built on top of it, ● what operations are most frequent and ● subject to performance requirements Usually informal meeting process that includes discussions with prospecting users and managements.

5. Daniel AdinugrohoDatabase Programming 5 2. CONCEPTUAL DB DESIGN The information gathered from the previous step is used to developed a high level description of data to be stored in the database, along with constraint that are known to hold over this data. Usually we use high level data model, such as ER (Entity Relationship) model. ER Diagram will be discussed further in RDBMS subject.

6. Daniel AdinugrohoDatabase Programming 6 3. LOGICAL DB DESIGN We choose DBMS (Database Management System) to implement our database design, and convert the conceptual database design into a database schema in the data model of chosen DBMS. Basically, in this step we convert an ER schema into a relational database schema. We should use Relational Database Management System (RDBMS) to make it easier in converting process.

7. Daniel AdinugrohoDatabase Programming 7 4. SCHEMA REFINEMENT Analyze the collections of relations in relational database schema to identify potential problems, and to refine it. One of the well-known concept is Normalization. We will discuss Normalization today.

8. Daniel AdinugrohoDatabase Programming 8 5. PHYSICAL DB DESIGN We must consider typical expected workloads that our database must support and further refine the database design to ensure that it meets desired performance criteria. It may involve building indexes on some tables and clustering some tables.

9. Daniel AdinugrohoDatabase Programming 9 6. SECURITY DESIGN Identify different users and roles and which part of database (in this case tables) allowed or denied to be accessed by a particular users/roles. Example in a supermarket: Operator only able to input data. Supervisor can input, modify and delete data. Manager can do everything supervisor can do plus can see the pricing.

10. Daniel AdinugrohoDatabase Programming 10 SCHEMA REFINEMENT Main problem in designing a database: REDUNDANCY! REDUNDANCY Cause: ● Redundant storage: information is stored repeatedly ● Update anomalies: inconsistency aroused if one of similar data is updated ● Insertion anomalies: inconsistency aroused if only some information is stored ● Deletion anomalies: inconsistency aroused if only delete some information Redundancy can be eliminated by decomposition. However, it should be used with caution.

11. Daniel AdinugrohoDatabase Programming 11 DECOMPOSITIONS Decomposition: a process to replace a relation with a collection of smaller relations. Example: Hourly_Emps(ssn,name,lot,rating,hourly_wages,hours_worked) It can be decomposed to Hourly_Emps2(ssn,name,lot,rating,hours_worked) Wages(rating,hourly_wages)

12. Daniel AdinugrohoDatabase Programming 12 DECOMPOSITION(2) Decomposition can lead to more problems, if we are not careful. Two important questions when decomposing relations: 1. Do we need to decompose a relation? -> Normal Forms 2. What problem (if any) does a given decomposition cause? -> lossless-join property, dependency preservation property

13. Daniel AdinugrohoDatabase Programming 13 NORMAL FORMS Normal forms: is a formal definition about the way data is stored in the database. In total, we have: ● First Normal Form (1NF) ● Second Normal Form (2NF) ● Third Normal Form (3NF) ● Boyce-Codd Normal Form (BCNF) ● Fourth Normal Form (4NF) ● Five Normal Form (5NF) Only the first three is commonly used.

14. Daniel AdinugrohoDatabase Programming 14 NORMAL FORMS CASE STUDY Case study: Project number Project name 1-n Employee numbers (1-n indicates that there are many occurrences of this field - it is a repeating group) 1-n Employee names 1-n Rate categories 1-n Hourly rates

15. Daniel AdinugrohoDatabase Programming 15 FIRST NORMAL FORM (1NF) 1NF -> eliminate repeating attributes 1. Identify repeating attributes. 2. All the key attributes are defined. 3. All attributes are dependent on the primary key. Employee project table Project number - primary key Project name Employee number - primary key Employee name Rate category Hourly rate This table is in 1st normal form.

16. Daniel AdinugrohoDatabase Programming 16 SECOND NORMAL FORM (2NF) 1. It's in first normal form (1NF) 2. It includes no partial dependencies (where an attribute is dependent on only a part of a primary key). Employee project table Project number - primary key Employee number - primary key Employee table Employee number - primary key Employee name Rate category Hourly rate Project table Project number - primary key Project name The table is now in 2nd normal form

17. Daniel AdinugrohoDatabase Programming 17 THIRD NORMAL FORM (3NF) 1. It's in second normal form (2NF) 2. It contains no transitive dependencies (where a non-key attribute is dependent on another non-key attribute Employee project table Project number - primary key Employee number - primary key Employee table Employee number - primary key Employee name Rate Category Project table Project number - primary key Project name These tables are all now in 3rd normal form, and ready to be implemented. Rate table Rate category - primary key Hourly rate

18. Daniel AdinugrohoDatabase Programming 18 OTHER NORMAL FORMS Boyce-Codd Normal Form (BCNF) R = relation schema X = a subset of the attributes of R A = attribute of R R is in BNF if for every Functional Dependencies, FD X -> A that holds over R, one of the following statements is true: ● A is an element of X, that is, it is a trivial FD, or ● X is a superkey BCNF, 4NF and 5NF are not discussed in Database Programming.

19. Daniel AdinugrohoDatabase Programming 19 EXERCISE Apply normal forms (1NF, 2NF, 3NF) and create the sample table for: Number - primary key Name Address Zip Code Town Hint: look for the answer in http://www.databasejournal.com/sqletc/article.php/1428511 http://www.databasejournal.com/sqletc/article.php/1428511

20. Daniel AdinugrohoDatabase Programming 20 REFERENCES ● R. Ramakrishnan, J. Gehrke, Database Management System Chapter 2 and 15, McGraw Hill International Editions ● N. Matthew, R. Stones, Beginning Database with MySQL Chapter 11, Wrox ● Ian Gilfillan, Database Normalization, http://www.databasejournal.com/sqletc/article.php/1428511 http://www.databasejournal.com/sqletc/article.php/1428511 ● Mike Hillyer, An Introduction to Database Normalization, http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html ● David Faour, Database Normalization, http://www.serverwatch.com/tutorials/article.php/1549781