Design Phases Initial phase--characterize fully the data needs of the prospective database users. Second phase--choosing a data model Applying the concepts of the chosen data model Translating these requirements into a conceptual schema of the database. A fully developed conceptual schema indicates the functional requirements of the enterprise. Describe the kinds of operations (or transactions)that will be performed on the data. Database System Concepts-7th Edition 6.4 @Silberschatz,Korth and Sudarshan
Database System Concepts - 7 6.4 ©Silberschatz, Korth and Sudarshan th Edition Design Phases ▪ Initial phase -- characterize fully the data needs of the prospective database users. ▪ Second phase -- choosing a data model • Applying the concepts of the chosen data model • Translating these requirements into a conceptual schema of the database. • A fully developed conceptual schema indicates the functional requirements of the enterprise. ▪ Describe the kinds of operations (or transactions) that will be performed on the data
Design Phases(Cont.) Final Phase--Moving from an abstract data model to the implementation of the database Logical Design-Deciding on the database schema. Database design requires that we find a "good"collection of relation schemas. Business decision-What attributes should we record in the database? Computer Science decision-What relation schemas should we have and how should the attributes be distributed among the various relation schemas? Physical Design-Deciding on the physical layout of the database Database System Concepts-7th Edition 6.5 ©Silberscha乜，Korth and Sudarshan
Database System Concepts - 7 6.5 ©Silberschatz, Korth and Sudarshan th Edition Design Phases (Cont.) ▪ Final Phase -- Moving from an abstract data model to the implementation of the database • Logical Design – Deciding on the database schema. ▪ Database design requires that we find a “good” collection of relation schemas. ▪ Business decision – What attributes should we record in the database? ▪ Computer Science decision – What relation schemas should we have and how should the attributes be distributed among the various relation schemas? • Physical Design – Deciding on the physical layout of the database
Design Alternatives In designing a database schema,we must ensure that we avoid two major pitfalls: Redundancy:a bad design may result in repeat information. Redundant representation of information may lead to data inconsistency among the various copies of information 。 Incompleteness:a bad design may make certain aspects of the enterprise difficult or impossible to model. Avoiding bad designs is not enough.There may be a large number of good designs from which we must choose. Database System Concepts-7th Edition 6.6 ©Silberscha乜，Korth and Sudarshan
Database System Concepts - 7 6.6 ©Silberschatz, Korth and Sudarshan th Edition Design Alternatives ▪ In designing a database schema, we must ensure that we avoid two major pitfalls: • Redundancy: a bad design may result in repeat information. ▪ Redundant representation of information may lead to data inconsistency among the various copies of information • Incompleteness: a bad design may make certain aspects of the enterprise difficult or impossible to model. ▪ Avoiding bad designs is not enough. There may be a large number of good designs from which we must choose
Design Approaches Entity Relationship Model(covered in this chapter) Models an enterprise as a collection of entities and relationships Entity:a "thing"or"object"in the enterprise that is distinguishable from other objects Described by a set of attributes Relationship:an association among several entities Represented diagrammatically by an entity-relationship diagram: Normalization Theory (Chapter 7) Formalize what designs are bad,and test for them Database System Concepts-7th Edition 6.7 ©Silberscha乜，Korth and Sudarshan
Database System Concepts - 7 6.7 ©Silberschatz, Korth and Sudarshan th Edition Design Approaches ▪ Entity Relationship Model (covered in this chapter) • Models an enterprise as a collection of entities and relationships ▪ Entity: a “thing” or “object” in the enterprise that is distinguishable from other objects • Described by a set of attributes ▪ Relationship: an association among several entities • Represented diagrammatically by an entity-relationship diagram: ▪ Normalization Theory (Chapter 7) • Formalize what designs are bad, and test for them
Entity Sets An entity is an object that exists and is distinguishable from other objects Example:specific person,company,event,plant An entity set is a set of entities of the same type that share the same properties. Example:set of all persons,companies,trees,holidays An entity is represented by a set of attributes;i.e.,descriptive properties possessed by all members of an entity set. ·Example: instructor=(ID,name,salary) course=(course_id,title,credits) A subset of the attributes form a primary key of the entity set;i.e., uniquely identifying each member of the set. Database System Concepts-7th Edition 6.10 ©Silberscha乜，Korth and Sudarshan
Database System Concepts - 7 6.10 ©Silberschatz, Korth and Sudarshan th Edition Entity Sets ▪ An entity is an object that exists and is distinguishable from other objects. • Example: specific person, company, event, plant ▪ An entity set is a set of entities of the same type that share the same properties. • Example: set of all persons, companies, trees, holidays ▪ An entity is represented by a set of attributes; i.e., descriptive properties possessed by all members of an entity set. • Example: instructor = (ID, name, salary ) course= (course_id, title, credits) ▪ A subset of the attributes form a primary key of the entity set; i.e., uniquely identifying each member of the set