Database design
- 1. Data Modeling Entity Relationship Model ( ER ) Prepared By : Bashir Rezaie 17/14/2015
- 2. Database Design Process 1. Requirements Collection And Analysis 2. Conceptual Design 3. Logical Design (Data Model Mapping) 4. Physical Design Prepared By : Bashir Rezaie 27/14/2015
- 3. Requirements Collection And Analysis • During this step, the database designers interview prospective database users to understand and document their data requirements. • These requirements should be specified in as detailed and complete a form as possible. • In parallel with specifying the data requirements, it is useful to specify the known functional requirements of the application. • These consist of the user-defined operations (or transactions) that will be applied to the database, including both retrievals and updates. Prepared By : Bashir Rezaie 37/14/2015
- 4. Conceptual Design • create a conceptual schema for the database, using a high-level conceptual data model. • The conceptual schema is a concise description of the data requirements of the users and includes detailed descriptions of the entity types, relationships, and constraints; these are expressed using the concepts provided by the high-level data model. • This approach enables database designers to concentrate on specifying the properties of the data, without being concerned with storage and implementation details. • During or after the conceptual schema design, the basic data model operations can be used to specify the high-level user queries and operations identified during functional analysis. Prepared By : Bashir Rezaie 47/14/2015
- 5. Logical Design (Data Model Mapping) • is the actual implementation of the database, using a commercial DBMS. • Most current commercial DBMSs use an implementation data model, such as the relational or the object-relational database model. • The conceptual schema is transformed from the high-level data model into the implementation data model. • Its result is a database schema in the implementation data model of the DBMS. Prepared By : Bashir Rezaie 57/14/2015
- 6. Physical Design • during this phase the internal storage structures, file organizations, indexes, access paths, and physical design parameters for the database files are specified. • In parallel with these activities, application programs are designed and implemented as database transactions corresponding to the high-level transaction specifications. Prepared By : Bashir Rezaie 67/14/2015
- 7. ER Model • The ER Model is used for Conceptual Design of database. • The ER model describes data as entities, relationships, and attributes. • We use the COMPANY DATABASE(Shown on the next page). Prepared By : Bashir Rezaie 77/14/2015
- 8. Prepared By : Bashir Rezaie 87/14/2015
- 9. Entity • The basic object that the ER model represents is an entity, which is a thing in the real world with an independent existence. • An entity may be an object with a physical existence (for example, a particular person, car, house, or employee). • Or it may be an object with a conceptual existence (for instance, a company, a job, or a university course). Prepared By : Bashir Rezaie 97/14/2015
- 10. Attribute • Each entity has attributes—the particular properties that describe it. • For example, an EMPLOYEE entity may be described by the employee’s name, age, address, salary, and job attributes. • A particular entity will have a value for each of its attributes. • The attribute values that describe each entity become a major part of the data stored in the database. Prepared By : Bashir Rezaie 107/14/2015
- 11. Types Of Attributes • simple versus composite • Single-valued versus multivalued • stored versus derived Prepared By : Bashir Rezaie 117/14/2015
- 12. Composite versus Simple (Atomic) Attributes • Composite attributes can be divided into smaller subparts, which represent more basic attributes with independent meanings. • For example, the Address attribute of the EMPLOYEE entity can be subdivided into Street_address, City, State, and Zip. • Attributes that are not divisible are called simple or atomic attributes. • Composite attributes are useful to model situations in which a user sometimes refers to the composite attribute as a unit but at other times refers specifically to its components. Prepared By : Bashir Rezaie 127/14/2015
- 13. Single-Valued versus Multivalued Attributes • Most attributes have a single value for a particular entity; such attributes are called single-valued. • For example , Age is a single-valued attribute of a person. • In some cases an attribute can have a set of values for the same entity that is called multivalued. • for instance, a Colors attribute for a car, or a College_degrees attribute for a person. one person may not have a college degree, another person may have one, and a third person may have two or more degrees; therefore, different people can have different numbers of values for the College_degrees attribute. Prepared By : Bashir Rezaie 137/14/2015
- 14. Stored versus Derived Attributes • Some attribute values can be derived from related entities, it’s called derived attributes. • The Age attribute is called a derived attribute and is said to be derivable from the Birth_date attribute, which is called a stored attribute. Prepared By : Bashir Rezaie 147/14/2015
- 15. NULL Values • In some cases, a particular entity may not have an applicable value for an attribute. For such situations, a special value called NULL is created. • For example, the Apartment_number attribute of an address applies only to addresses that are in apartment buildings and not to other types of residences, such as single-family homes. An address of a single-family home would have NULL for its Apartment_number attribute. • NULL can also be used if we do not know the value of an attribute for a particular entity. (unknown) Prepared By : Bashir Rezaie 157/14/2015
- 16. Complex Attributes • in general, composite and multivalued attributes can be nested arbitrarily. • We can represent arbitrary nesting by grouping components of a composite attribute between parentheses () and separating the components with commas, and by displaying multivalued attributes between braces { }. • Such attributes are called complex attributes. • For example, if a person can have more than one residence and each residence can have a single address and multiple phones, an attribute Address_phone for a person can be specified. Prepared By : Bashir Rezaie 167/14/2015
- 17. Entity Types • An entity type defines a collection (or set) of entities that have the same attributes. • Each entity type in the database is described by its name and attributes. • For example, a company employing hundreds of employees may want to store similar information concerning each of the employees. These employee entities share the same attributes, but each entity has its own value(s) for each attribute. • An entity type is represented in ER diagrams as a rectangular box enclosing the entity type name. Prepared By : Bashir Rezaie 177/14/2015
- 18. Entity Sets • The collection of all entities of a particular entity type in the database at any point in time is called an entity set. • the entity set is usually referred to using the same name as the entity type. • For example, EMPLOYEE refers to both a type of entity as well as the current set of all employee entities in the database. • An entity type describes the schema or intension for a set of entities that share the same structure. The collection of entities of a particular entity type is grouped into an entity set, which is also called the extension of the entity type. Prepared By : Bashir Rezaie 187/14/2015
- 19. Prepared By : Bashir Rezaie 197/14/2015
- 20. Key Attributes of an Entity Type • An entity type usually has one or more attributes whose values are distinct for each individual entity in the entity set. Such an attribute is called a key attribute, and its values can be used to identify each entity uniquely. • For example, the Name attribute is a key of the COMPANY entity type because no two companies are allowed to have the same name. • Sometimes several attributes together form a key, meaning that the combination of the attribute values must be distinct for each entity. • Some entity types have more than one key attribute. • An entity type may also have no key, in which case it is called a weak entity type Prepared By : Bashir Rezaie 207/14/2015
- 21. Initial Conceptual Design of the COMPANY Database 7/14/2015 Prepared By : Bashir Rezaie 21
- 22. Relationship Types, Sets, and Instances • A relationship type R among n entity types E1, E2, ..., En defines a set of associations—or a relationship set—among entities from these entity types. • Mathematically, the relationship set R is a set of relationship instances ri, where each ri associates n individual entities (e1, e2, ..., en), and each entity ej in ri is a member of entity set Ej. • Each of the entity types E1, E 2, ..., En is said to participate in the relationship type R; similarly, each of the individual entities e1, e2, ..., en is said to participate in the relationship instance ri = (e1, e2, ..., en). 7/14/2015 Prepared By : Bashir Rezaie 22
- 23. • For example, consider a relationship type WORKS_FOR between the two entity types EMPLOYEE and DEPARTMENT, which associates each employee with the department for which the employee works in the corresponding entity set. Each relationship instance in the relationship set WORKS_FOR associates one EMPLOYEE entity and one DEPARTMENT entity. • In ER diagrams, relationship types are displayed as diamond-shaped boxes. 7/14/2015 Prepared By : Bashir Rezaie 23
- 24. Degree of a Relationship Type • The degree of a relationship type is the number of participating entity types. • Hence, the WORKS_FOR relationship is of degree two. • A relationship type of degree two is called binary, and one of degree three is called ternary. • Relationships can generally be of any degree, but the ones most common are binary relationships. 7/14/2015 Prepared By : Bashir Rezaie 24
- 25. Role Names and Recursive Relationships • Each entity type that participates in a relationship type plays a particular role in the relationship. The role name signifies the role that a participating entity from the entity type plays in each relationship instance, and helps to explain what the relationship means. • Role names are not technically necessary in relationship types where all the participating entity types are distinct, since each participating entity type name can be used as the role name. • However, in some cases the same entity type participates more than once in a relationship type in different roles. In such cases the role name becomes essential for distinguishing the meaning of the role that each participating entity plays. Such relationship types are called recursive relationships. 7/14/2015 Prepared By : Bashir Rezaie 25
- 26. • The SUPERVISION relationship type relates an employee to a supervisor, where both employee and supervisor entities are members of the same EMPLOYEE entity set. • Hence, the EMPLOYEE entity type participates twice in SUPERVISION: once in the role of supervisor (or boss), and once in the role of supervisee (or subordinate). • the lines marked ‘1’ represent the supervisor role, and those marked ‘2’ represent the supervisee role 7/14/2015 Prepared By : Bashir Rezaie 26
- 27. Constraints on Binary Relationship Types • Relationship types usually have certain constraints that limit the possible combinations of entities that may participate in the corresponding relationship set. • These constraints are determined from the miniworld situation that the relationships represent. • For example, if the company has a rule that each employee must work for exactly one department, then we would like to describe this constraint in the schema. • We can distinguish two main types of binary relationship constraints: cardinality ratio and participation. 7/14/2015 Prepared By : Bashir Rezaie 27
- 28. Cardinality Ratios for Binary Relationships • The cardinality ratio for a binary relationship specifies the maximum number of relationship instances that an entity can participate in. • For example, in the WORKS_FOR binary relationship type, DEPARTMENT:EMPLOYEE is of cardinality ratio 1:N. • This means that for this particular relationship WORKS_FOR, a particular department entity can be related to any number of employees. On the other hand, an employee can be related to a maximum of one department. • The possible cardinality ratios for binary relationship types are 1:1, 1:N, N:1, and M:N. 7/14/2015 Prepared By : Bashir Rezaie 28
- 29. An employee can manage one department only and a department can have one manager only.( 1:1 ) An employee can work on several projects and a project can have several employees.( N:M ) 7/14/2015 Prepared By : Bashir Rezaie 29
- 30. Participation Constraints • The participation constraint specifies whether the existence of an entity depends on its being related to another entity via the relationship type. • If a company policy states that every employee must work for a department, then an employee entity can exist only if it participates in at least one WORKS_FOR relationship instance. • There are two types of participation constraints: 1. total 2. partial 7/14/2015 Prepared By : Bashir Rezaie 30
- 31. There are two types of participation constraints—total and partial—that we illustrate by example. Total Participation • the participation of EMPLOYEE in WORKS_FOR is called total participation, meaning that every entity in the total set of employee entities must be related to a department entity via WORKS_FOR. • Total participation is also called existence dependency. • In ER diagrams, total participation (or existence dependency) is displayed as a double line connecting the participating entity type to the relationship Partial Participation • we do not expect every employee to manage a department, so the participation of EMPLOYEE in the MANAGES relationship type is partial. • meaning that some or part of the set of employee entities are related to some department entity via MANAGES, but not necessarily all • Partial participation is represented by a single line 7/14/2015 Prepared By : Bashir Rezaie 31
- 32. Attributes of Relationship Types • Relationship types can also have attributes, similar to those of entity types. • For example, to record the number of hours per week that an employee works on a particular project, we can include an attribute Hours for the WORKS_ON relationship type. • Notice that attributes of 1:1 or 1:N relationship types can be migrated to one of the participating entity types. • For M:N relationship types, some attributes may be determined by the combination of participating entities in a relationship instance, not by any single entity. Such attributes must be specified as relationship attributes. 7/14/2015 Prepared By : Bashir Rezaie 32
- 33. Notice that attributes of 1:1 or 1:N relationship types can be migrated to one of the participating entity types. 1:1 relationship • the Start_date attribute for the MANAGES relationship can be an attribute of either EMPLOYEE or DEPARTMENT, although conceptually it belongs to MANAG • This is because MANAGES is a 1:1 relationship, so every department or employee entity participates in at most one relationship instance. 1:N relationship • For a 1:N relationship type, a relationship attribute can be migrated only to the entity type on the N-side of the relationship. • For example, in Figure 7.9, if the WORKS_FOR relationship also has an attribute Start_date that indicates when an employee started working for a department, this attribute can be included as an attribute of EMPLOYEE. 7/14/2015 Prepared By : Bashir Rezaie 33
- 34. 7/14/2015 Prepared By : Bashir Rezaie 34 MANAGES ( 1:1) WORKS_FOR ( 1:N )
- 35. Weak Entity Types • Entity types that do not have key attributes of their own are called weak entity types. • Entities belonging to a weak entity type are identified by being related to specific entities from another entity type in combination with one of their attribute values. • We call this other entity type the identifying or owner entity type, and we call the relationship type that relates a weak entity type to its owner, the identifying relationship of the weak entity type. • A weak entity type normally has a partial key, which is the attribute that can uniquely identify weak entities that are related to the same owner entity. 7/14/2015 Prepared By : Bashir Rezaie 35
- 36. Summary of Notation for ER Diagrams 7/14/2015 Prepared By : Bashir Rezaie 36
- 37. Refinements • It is occasionally difficult to decide whether a particular concept in the miniworld should be modeled as an entity type, an attribute, or a relationship type. • In general, the schema design process should be considered an iterative refinement process, where an initial design is created and then iteratively refined until the most suitable design is reached. • Some of the refinements that are often used include the following: 1. A concept may be first modeled as an attribute and then refined into a relationship because it is determined that the attribute is a reference to another entity type. 7/14/2015 Prepared By : Bashir Rezaie 37
- 38. 1. Similarly, an attribute that exists in several entity types may be elevated or promoted to an independent entity type. • For example, suppose that several entity types in a UNIVERSITY database, such as STUDENT, INSTRUCTOR, and COURSE, each has an attribute Department in the initial design; the designer may then choose to create an entity type DEPARTMENT with a single attribute Dept_name and relate it to the three entity types (STUDENT, INSTRUCTOR, and COURSE) via appropriate relationships 2. An inverse refinement to the previous case may be applied—for example, if an entity type DEPARTMENT exists in the initial design with a single attribute Dept_name and is related to only one other entity type, STUDENT. In this case, DEPARTMENT may be reduced or demoted to an attribute of STUDENT. 7/14/2015 Prepared By : Bashir Rezaie 38