1. Overview of Database Design By Nazife Dimililer

2. Database Management System A DBMS is a data storage and retrieval system which permits data to be stored non- redundantly while making it appear to the user as if the data is well-integrated.

3. Database Management System DBMS manages data resources like an operating system manages hardware resources DBMS Database containing centralized shared data Application #1 Application #2 Application #3

4. Advantages of Database Approach Program-Data Independence – Metadata stored in DBMS, so applications don’t need to worry about data formats – Data queries/updates managed by DBMS so programs don’t need to process data access routines – Results in: increased application development and maintenance productivity Minimal Data Redundancy – Leads to increased data integrity/consistency

5. Advantages of Database Approach Improved Data Sharing – Different users get different views of the data Enforcement of Standards – All data access is done in the same way Improved Data Quality – Constraints, data validation rules Better Data Accessibility/ Responsiveness – Use of standard data query language (SQL) Security, Backup/Recovery, Concurrency – Disaster recovery is easier

6. Costs and Risks of the Database Approach Up-front costs: – Installation Management Cost and Complexity – Conversion Costs Ongoing Costs – Requires New, Specialized Personnel – Need for Explicit Backup and Recovery Organizational Conflict – Old habits die hard

7. The Range of Database Applications Personal Database – standalone desktop database Workgroup Database – local area network (<25 users) Department Database – local area network (25-100 users) Enterprise Database – wide-area network (hundreds or thousands of users)

8. Evolution of DB Systems Flat files - 1960s - 1980s Hierarchical – 1970s - 1990s Network – 1970s - 1990s Relational – 1980s - present Object-oriented – 1990s - present Object-relational – 1990s - present Data warehousing – 1980s - present Web-enabled – 1990s - present

9. Database Design Phases Conceptual Design Model the data without any physical considerations for each user view. Logical Design Choose the data model that will be used and modify the conceptual data model to fit the data model without any other physical considerations. Validate the model using normalization and transaction requirements. Physical Design Choose the actual DBMS and implement the data model efficiently. Performance, security and reliability are key issues.

10. Systems Development Life Cycle Project Identification and Selection Project Initiation and Planning Analysis Physical Design Implementation Maintenance Logical Design

11. Systems Development Life Cycle Project Identification and Selection Project Initiation and Planning Analysis Physical Design Implementation Maintenance Logical Design Purpose --preliminary understanding Deliverable –request for project Database activity – enterprise modeling First step in database development Specifies scope and general content Overall picture of organizational data, not specific design Entity-relationship diagram Descriptions of entity types Relationships between entities Business rules

12. Systems Development Life Cycle Project Identification and Selection Project Initiation and Planning Analysis Physical Design Implementation Maintenance Logical Design Purpose – state business situation and solution Deliverable – request for analysis Database activity – conceptual data modeling

13. Systems Development Life Cycle Project Identification and Selection Project Initiation and Planning Analysis Physical Design Implementation Maintenance Logical Design Purpose –thorough analysis Deliverable – functional system specifications Database activity – conceptual data modeling

14. Systems Development Life Cycle Project Identification and Selection Project Initiation and Planning Analysis Physical Design Implementation Maintenance Logical Design Purpose –information requirements structure Deliverable – detailed design specifications Database activity – logical database design

15. Systems Development Life Cycle Project Identification and Selection Project Initiation and Planning Analysis Physical Design Implementation Maintenance Logical Design Purpose –develop technology specs Deliverable – program/data structures, technology purchases, organization redesigns Database activity – physical database design

16. Systems Development Life Cycle Project Identification and Selection Project Initiation and Planning Analysis Physical Design Implementation Maintenance Logical Design Purpose –programming, testing, training, installation, documenting Deliverable – operational programs, documentation, training materials Database activity – database implementation

17. Systems Development Life Cycle Project Identification and Selection Project Initiation and Planning Analysis Physical Design Implementation Maintenance Logical Design Purpose –monitor, repair, enhance Deliverable – periodic audits Database activity – database maintenance

18. Simplified Database Development Procedure Start Draw ERD Convert to Relational Schema Validate using Normalization Validate against user transactions Stop

19. Documentation Entity Document

20. Documentation Relationship Document

21. Documentation Attribute Document

22. Documentation Attribute Document Continued

23. Documentation Attribute Domain Document

24. APPLY NORMALIZATION If you normalized your database design, you can be more confident that there will be no redundancy in the final database. There are three basic checks that most relational database designers carry out. 1NF REMOVE REPEATING GROUPS 2NF REMOVE PARTIAL DEPENDENCIES 3NF REMOVE NON-KEY DEPENDENCIES

25. USEFUL DESIGN PRINCIPLES 1-Faitfulness Entity sets, their attributes and relationships should reflect reality Don’t attach pointless attributes. Employee Number-of-legs Relationships between attributes depend on the policy of organization. employee department works employee department works

26. USEFUL DESIGN PRINCIPLES 2- Avoid Redundancy Student name 3- Simplicity counts Avoid introducing more elements into your design Than is absolutely necessary. advisorname id Advisor name id Student name highschool id kindergarten

27. USEFUL DESIGN PRINCIPLES 4- Choosing the right relationship Adding to our design every possible relationship is not often a good idea. It can cause to redundancy. Resulting database could require more space to store redundant elements. Modifying the database could become more complex.

28. USEFUL DESIGN PRINCIPLES 5- Picking the right kind of element. movie year studioname studioaddress title Repeat studio name and address for each movie If studio doesn't have any movie, we lost the address of the movie movie studio filmedBy title year studioname studioaddress

29. USEFUL DESIGN PRINCIPLES 5- Picking the right kind of element. k k K K F F f f e e K K E E F F f f k k e e K K k k e e E E K K e e k k Example 1: Using Multiway relationship Example 1: If entity set has only one attribute and relationship is 1:N relationship.

30. Helpful pointers Transform “complex” attributes to entities.

31. Helpful pointers Use lookup entities(tables) for frequently used data.

32. Helpful pointers Split compound attributes

33. Helpful pointers Transform weak entities to strong entities

34. Helpful pointers Add History

35. Some helpful pointers Use consistent naming rules for all entities,relationships and attributes Choose primary keys intelligently. Primary keys should NOT change over time. Choose appropriate data types for attributes

36. Intelligent vs Surrogate Keys A surrogate key is an artificial or synthetic key that is used as a substitute for a natural key aka intelligent key. "Surrogate key" may also be known as "System-generated key", "Database Sequence number", "Synthetic key", "Technical key" or an "Arbitrary, unique identifier". primary keys are hard to change. Intelligent keys suffer from this problem because not only are they used as primary and foreign keys but they also have some business meaning associated with them The biggest advantage for intelligent keys is that users understand what they mean whereas surrogate keys don't make any business sense. Data Models that use surrogate keys usually have more normalization errors.

37. Surrogate vs. Intelligent Keys Natural keys: are more logical can sometimes can mean fewer joins help to encourage good modeling are traditional/user friendly make snooping around in the data easier Surrogate keys: are shorter are easier to join take less storage enable natural key fields to be easily changed are what Object Oriented (and object relational) databases use

38. Some helpful pointers : Physical Database Design Purpose- translate the logical description of data into the technical specifications for storing and retrieving data Goal - create a design for storing data that will provide adequate performance and insure database integrity, security and recoverability

39. Some helpful pointers : Physical Design Process Normalized relations Volume estimates Attribute definitions Response time expectations Data security needs Backup/recovery needs Integrity expectations DBMS technology used Inputs Attribute data types Physical record descriptions (doesn’t always match logical design) File organizations Indexes and database architectures Query optimization Leads to Decisions

40. Some helpful pointers : Designing Fields Field: smallest unit of data in database Field design – Choosing data type – Coding, compression, encryption – Controlling data integrity

41. Some helpful pointers : Field Data Integrity Default value - assumed value if no explicit value Range control – allowable value limitations (constraints or validation rules) Null value control – allowing or prohibiting empty fields Referential integrity – range control (and null value allowances) for foreign-key to primary-key match- ups

42. Some Helpful Pointers : Denormalization Transforming normalized relations into unnormalized physical record specifications Benefits: – Can improve performance (speed) be reducing number of table lookups (i.e reduce number of necessary join queries) Costs (due to data duplication) – Wasted storage space – Data integrity/consistency threats Common denormalization opportunities – One-to-one relationship – Many-to-many relationship with attributes – Reference data (1:N relationship where 1-side has data not used in any other relationship)

43. Common Design problems Misplaced relationships Incorrect Cardinalities Missing Relationships Overuse of specialized data modeling tools (ex: Inheritance, multiway relationships) Redundant Relationships

44. Goals of Database Development Develop a Common Vocabulary Define the meaning of Data Ensure Data Quality Find an Efficient Implementation

45. Final Word Remember that the goal of the DB development is to produce a DB that provides an important resource for an organization. The DB should be designed so that it can serve the customers and other team members efficiently.