1. What are the main building modules of the Entity Relationship model? Discuss each one.

Transcription

1 1. What are the main building modules of the Entity Relationship model? Discuss each one. Let s begin by reviewing that working within a RDBMS model, using entity relationship modeling (ERM) forms the basic underpinnings of an entity relationship diagram (ERD). The ERD represents the database in a conceptual graphical representation for the end-user, but the ERD cannot be created until all the entities, attributes and relationship have been identified. This step is performed in the initial stages of evaluation, using the entity relationship modeling (ERM) process before the (proper) entity relationship diagram (ERD) can be created. The basic building modules that construct an entity relationship model include: entities, attributes, and relationships. In previous chapters we learned there basic functions, here we will expand on the many characteristics each building module can take within ERM modeling. I. Entities: Review: An entity represents an object. It can be anything (a person, a place, a thing, or event). Basically an entity can be defined as the object of interest for the end-user that collects and stores data. Entities are distinguishable, that is, they are unique. Within ERM processes, an entity will refer to an entity set, rather than a single occurrence. In other words an entity within an ERM corresponds to a table and not the row in a relational environment. The ERM will refer to a table row as an entity occurrence. Entities can take on many characteristics within ERM modeling which we will discuss below: A. Existence Dependence a. An entity is said to be existence-dependent if it can exist in the database only when it is associated with another related entity occurrence. In other words both entities have to exist and rely on one another to perform a function. b. An entity is said to be existence-independent if it does not rely on another entity to exist. B. Strong and Weak Entities a. An entity that is strong will be an entity that is existencedependent. b. An entity that is weak will be an entity that is existenceindependent. II. Attributes:

2 Review: Attributes are the characteristics of entities. Using ERM modeling, attributes can take on many characteristics, which we will discuss below: A. Required and Optional Attributes: 1. A required attribute is an attribute that must have a value. It cannot be empty. In other words that attribute requires a data entry. 2. A optional attribute is an attribute that does not require a value, and can therefore be left empty. B. Attribute Domains 1. All attributes have a domain. A domain is a set of possible values for a given attribute. For example, the attribute for the entity G.P.A would simply imply that the G.P.A. entity has an attribute domain that specifies data to be entered into a particular format, based on a numerical 0-4 set. In other words no alphabetical information can be entered in this attributes domain because the domain is set to represent numerical data, i.e. 3.2, 4.0 or any other possible combination, but only using the numbers 0-4. An entity such as telephone number would have a domain set for numerical values as well, or another example, the entity address would have an attribute domain to include a combination of alphanumeric data values. It is also possible for attributes to share a domain. Note the example entity address. In an ERM two different attributes like doctor and patient may share a domain attribute such as address. C. Attribute Identifiers: 1. Attributes Primary Keys: The ERM system uses identifiers, which are one or more attributes that uniquely identify an entity instance. These identifiers are mapped to the relational models primary key (PK) which we have overviewed in past chapters. Identifiers are essentially an attributes primary key. Identifiers are underlined in an ERD as well as within an ERM. For example; CAR (CAR_VIN, CAR_MODEL, CAR_YEAR, CAR_COLOR) This example states that the entity car includes the identifier CAR_VIN as its Primary key, with all the other attributes of that entity. 2. Composite Identifiers: It is possible to use a composite identifier that is composed of the attributes primary key, which can be composed of many attributes. Basically a composite key is a combination of key attributes. For example:

3 *NOTE: assume car year would uniquely identify, in the real-world this would not be the case CAR (CAR_VIN, CAR_YE AR, CAR _MODEL, CAR_COLOR) D. Composite and Simple Attributes: Attributes are classified as either composite or simple. 1.) Composite attribute is an attribute that can be subdivided to yield additional attributes. For example, an attribute like Address can be subdivided into additional attributes such as, street, city, state, and zip code. 2.) Simple attribute is an attribute that cannot be subdivided. For example, the attribute Age cannot be subdivided. *NOTE: Composite attribute should not be confused with composite identifiers. E. Single-Valued Attributes vs. Multi-Valued Attributes: 1.) A single-valued attribute can only have one value. That does not mean it is a simple attribute, but rather an attribute that has a single value that cannot be subdivided. For example, a car s VIN number may look something like: nfgo9u99jj. This number in its entirety is a single valued attribute. It cannot be subdivided into more attributes. 2.) A multi-valued attribute is an entity attribute that can have more than one value. Using our car entity analogy, the car entity has an attribute CAR_COLOR this particular attribute, can be further subdivided into other attributes for various car color s i.e. red, blue, black, etc. F. Derived Attributes In the chapter 3, a discussion about using set operators to perform computations/algorithms were explained under an ERD framework. Within ERM, derived attributes work in a similar way. An attribute may be classified as a derived attribute if the attributes value can be calculated (derived) from other attributes through the use of an algorithm. A derived attribute can be as simple as adding two attribute values located within the same row, or it can be a result by aggregating the sum of attribute values located on many rows (either within the same table or different tables). The decision to store such data from derived attributes depends on the level of processing requirements needed by the overall design of the database, and is left up to the designer to decided the balance between the advantages and disadvantages in storing this particular set of data values.

4 III. Relationships Review: A relationship between entities is the association being made. A. Cardinality in relationships: Cardinality is achieved by expressing the minimum and maximum number of entity occurrences associated with a related entity. Cardinality is expressed in a (x,y) format, that is numerically indicated. These numerical values will be placed accordingly besides the entities. The first value x represents the minimum number of associated entities, and the y value represents the maximum number of associated entities. Cardinalities can be established by core business rules that give precise and detailed descriptions of the overall data environment. B. Relationship Strengths: Relationship strength is also dependant on the strength of an entity. A relationship s strength is based on how the primary key (PK) of a related entity is defined. Remember in chapters 2 and 3, that with an ERD a relationship was implemented by the use of the primary key of one entity appearing as the foreign key in another entity. Relationship strength can be determined by identifying the decisions that affect the primary key s arrangement within the database. 1.) Weak (Non-identifying) Relationships: A weak relationship exists if the primary key of the related entity does not contain a primary key from the parent entity. In other words if a primary key of one table is not part of the primary key in another table you have a weak relationship. You can also experience a weak relationship if an entity has a primary key that is partially or totally derived from a parent entity in the relationship. A weak entity will inherit part of the primary key from its strong counterpart. 2.) Strong (identifying ) Relationships: A strong relationship is just the opposite of a weak one. If the primary key of one table is a part of the primary key in another table, you have a strong relationship, because it is contained within both tables. 3.) Relationship Participation: Participation in an entity relationship can be mandatory or optional. Optional participation requires that one entity occurrence does not require a corresponding entity occurrence in a relationship. Optionality is a condition in which one or more optional relationships exist.

5 Mandatory relationships mean that one entity occurrence requires a corresponding entity occurrence in a relationship. 4.) Relationship Degrees: A relationship degree indicates the number of entities or participants associated with a relationship. A degree indicates how many tables are directly interrelated in a relation. Within the framework of an ERD we have mostly seen binary relationships, as you ll remember in 1:1, 1:M, and M:N. A unary relationship exists when an association is maintained within a single entity. Such a relationship is also known as a recursive relationship. A recursive relationship is one in which a relationship can exist between occurrences of the same entity set. Such a condition is found within a unary relationship. Binary relationships are the most common. They exist when two entities are associated, and a Ternary relationship exists when three entities are associated. 2. What is a composite entity, and when is it used? Let s begin by reviewing what we learned about many-to-many relationships within a relational model. They are generally not supported!!! Which required programmers to create a composite entity or bridge, between the M:N relationship to reflect one or more, 1:M relationships. A composite entity is the (associative or bridge) entity that is composed of the primary keys of each of the entities to be connected in order to implement manyto-many relationships. Let s re-visit an old example used in previous work, showcasing composite entities. In the past we used this example to create new one-to-many relationship between these entities. Within the context of ERM we want to support the many-to-many relationship by not so much changing them into 1:M, but by implementing a composite entity to support the M:N relationship through their attributes, which before were not included in the relationship. Now we have relationships between entities with many attributes attached. So for example, let s say the attributes for Drivers, included DRIVER_NAME, DRIVER_ID, AND DRIVER_LIN_NUM. And the entity Trucks had the attributes that included, TRUCK_ID, TRUCK_VIN_NUM. Knowing the primary key for the Driver entity = (PK: Driver_ID)is driver id, and knowing the primary key for the entity Trucks = (PK: TRUCK_VIN) number. We know that we can create a new composite entity Driving by creating the composite key for this new entity. We know the (PK) from both original

6 entities, so we know that to create the key for the new composite entity, we must have a combination of the two original (PK s). Here s what the original relationship look liked in an ERD below, displaying the composite entity with no attributes, and establishing two new 1:M relationships: The E-R Model would be displayed below, showing the new composite entity, composed of the original entities attributes and primary keys. 3. The Hudson Engineering Group (HEG) has contacted you to create a conceptual model whose application will meet the expected database requirements for its training program. The HEG administrator gives you the following description of the training group's operating environment: "The HEG has 12 instructors and can handle up to 30 trainees per class. HEG offers five 'advanced technology' courses, each of which may generate several classes. If a class has fewer than 10 trainees in it, it will be canceled. It is, therefore, possible for a course not to generate any classes during a session. Each class is taught by one instructor.

7 Each instructor may teach up to two classes or may be assigned to do research. Each trainee may take up to two classes per session." Given this information, do the following: a. Draw the E-R diagram for HEG. b. Describe the relationship between instructor and class in terms of connectivity, cardinality, and existence dependence. The relationship between instructor and class, tells us that the relationship operates both ways, a binary relationship. An instructor teaches students, and students are instructed by an instructor. Because we know both directions of the relationship, we also know we have a classified 1:M relationship. Now, by establishing this relationship we can also determine that this is their primary connectivity. The connectivity between these two entities, is the relationship we have just classified the 1:M. Cardinality expresses the minimum and maximum number of entity occurrences associated with one occurrence of the related entity. Using our example in part a) of question 3, the instructor entity has an occurrence of twelve, because we know that there are 12 instructors in our problem. The

8 value would be written in the (x,y) format for expressing cardinality, so we have a value = (1,12)for instructor. The related entity class has an entity occurrence that is not known because we know that there are 5 core courses, but these courses can generate many classes. The value for classes is not known because it is not given, so we must give the entity occurrence for class a (0,0) value. Also we can determine that the relationship between instructor and class is existence dependent because their existence is dependent on one another. We have also learned that existence-dependant relationships that exist are also considered strong relationships because the relationship relies on part of the primary key. In other words, the instructor entity is a known primary key, therefore class depends on part of this primary key and the entity class is also a child entity, of the parent entity instructor. 4. What is a derived attribute? Give an example. A derived attribute is an attributes value that can be calculated or (derived) from other attributes values, to perform a function. A derived attribute computation can be as simple as adding two attribute values located on the same row, or by aggregating the sum of values located on many table rows (from the same table or from a different table). For example, say we want to find out an employee s age by calculating the employees date-of-birth attribute with the current date. This subtraction algorithm that was just created by these two values, the date-of-birth and the current date, can be used to create the new derived attribute that we ll be the employee s age. If an employee was given the attribute DOB that contained a year value of 1981, and we know the current year is 2009, we can use the subtraction algorithm to produce an age (the new value that was determined by using the original attribute and deriving a new value from the old). This would mean that when a subtraction of year of birth and the current year are used, we know that this person s age would be 28 years old. 5. What three (often conflicting) database requirements must be addressed in database design? A database designer often experiences conflicting goals for the database, and design compromises often have to be performed in order for the database to be in the best possible shape. Design standards, processing speeds, and information requirements are the most compelling requirements a designer needs to be aware of in addressing the approach and design of a database.

9 Design standards provide a framework for the designer to work within, and a database must conform to these standards. These standards will in essence guide the designer in developing logical structures that minimize data redundancies and anomalies. Such standards will assist in formulating a proper design process, and allow one to work with well defined components that can be further evaluated to understand those components and their interaction. Processing speeds are another requirement. High processing speeds are often a top-priority for database designers because most want efficient and fast access to their information. Yet sometimes if relationship structures within the database are very complex this may lead to slower processing speeds because the database is using many components to perform a function. This would require the database designer to re-work some of those structures to make the relationships more streamlined and efficient, therefore leading to faster processing. And finally, we have information requirements to be aware of. Sometimes a database may have to sacrifice some of its clean and easy design structures or change the transaction speeds, to ensure maximum information generation. Complex information requirements may dictate transformations within the database structure because additional entities and attributes have been identified, therefore other requirements may need to be tweaked in order for proper information storage and retrieval is being performed. A designer has many responsibilities, while they are concerned with the actual structures of the database, and their technical definitions, a designer must also be thinking about the end-user, and their ability to access the data, the data s historical integrity, the performance (speed), as well as the security of that information. 6. Answer the following questions about Normalization. a. What is normalization? Normalization is the process that a designer works through, in order to evaluate and correct information structures within the database. The process of normalization is performed in effect, to minimize data redundancies and reducing data anomalies within the table structures inherit in relational modeling. This process will assist a designer in creating the perfect database design, because imperfections in logic can be identified. Normalizations works through a series of stages called normal forms, which will be discussed in further detail below. In essence the process of normalization is used to normalize the tables within the structure in order to store the data that will be used to generate required information. The objective of normalization is to

10 ensure that each table conforms to well-designed relations. These tables must have the following characteristics to have a well-designed relation, including: that each table must represent a single subject, no data item will be unnecessarily stored in more than one table (data redundancies), all attributes within a table are dependent on the primary key, and finally, that each table is void of insertion, update, or deletion anomalies. Again the normalization process goes through stages that at every turn will produce higher and higher normal forms, and for most, the goal is to normalize a database design to achieve the 3NF (3 rd normal form). Now, determination and functional dependency are important to understand within the context of understanding normalization. These require a brief explanation in order to understand the required relation within the overall structure. Functional dependencies in effect identify a particular dependency within a relation, and normalizing that particular relation will assist the designer in possibly identifying new relations and their dependencies. In effect, this is the overall goal for the designer identifying all possible structures and their relations to create a good relational database. An example of a fully functional dependency would be the composite key because more than one attribute can be defined to inhibit dependence. But functional dependence at its most simplistic definition can be described as such; if attribute A determines attribute B (that is B is functionally dependant on A). If all the rows within a table agree in value for attribute A they must also agree in value for attribute B. In other words the normalization process starts by identifying the dependencies of a given relation and progressively breaking up the relation (table) into a set of new relations (tables) based on the identified dependencies. Now, the objective is to express fully functional dependencies but other dependencies are such types. Transitive dependencies are important to review, because sometimes both attributes used in a relation may not be a part of the primary key. In other words a transitive dependency is a dependency of one nonprime attribute on another nonprime attribute. Transitive dependencies do lead to data anomalies. Normalization focuses on the characteristics of specific entities; that is, normalizations represent a micro view of the entities within an ERD. Now remember the ERD gives us the macro view or big picture, while the E-R modeling gives us the micro view of the entities contained within the ERD. The normalization process involved with relational

11 modeling helps with distinguishing between these important differences. b. When is a table in 1NF? To begin, a table under evaluation in normalization begins with a three-step process. First, evaluate the table and make sure each cell has a single value and there are no repeating groups (i.e. eliminate repeating groups by making sure that each row defines a single entity). Second, identify the primary key. A proper primary key will uniquely identify any attribute value; therefore if the primary key does not maintain uniqueness, a new key must be created that is composed of a combination of attributes that will become the new (composite) primary key. The third step will be to identify all the dependencies within the relationship. The designer would ask questions about the dependencies, such as, are they fully functional, are there partial dependencies or transitive dependencies? Now remember all attributes must be dependent on the primary key. Overall, a table within a relational model database is in normal form 1 (1NF) when all the key attributes are defined and when all the remaining attributes are dependent on the primary key. 1NF can contain partial and transitive dependencies, but a table with a single attribute primary key cannot exhibit partial dependencies, therefore the composite primary key must be created. A designer using this normalization process can only continue when the table used in a relation has properly complied to all 1NF functions. c. When is a table in 2NF? Normalization is a process, one could think of it in terms of building blocks. If a table met the 1NF characteristics, you may proceed in establishing that table to meet 2NF characteristics. A table that is in 2NF is done only when the 1NF table has a composite primary key. Now remember if one is working at the 1NF stage, and the table has a single primary attribute key, the table is automatically in 2NF, but working in the 1NF stage with a composite key that was created, transforming the 1NF table into 2NF would proceed as follows: Using table one (1NF), write each key component (all the composite keys) out, that were identified, along with the original key listed on the last line. These components will all become the new key in a new table. Now step two in this conversion would be to identify all the corresponding attributes that are dependant. We can identify these dependant attributes by showing the relational schemas for each new key component. Once this stage has been achieved, a designer may notice that some transitive dependencies still exist, but NO partial

12 dependencies exist (that being a dependencies that is based on only a part of a composite primary key). In essence, at the 2NF stage a table will be in that state if it has achieved 1NF and no partial dependencies exist. d. When is a table in 3NF? Notice how transitive dependencies were found in the 2NF stage. To start the conversion from 2NF to 3NF, every transitive dependency identified write it new determinant as a primary key for a new table (NOTE* a determinate is described as any attributes whose value determines other values within a row). For example, if two transitive dependencies were found, two different determinants will need to be created. Next identify the dependant attributes. Write out the dependant attributes based on the new determinant that was created and identify what the dependency is. Once this stage has been done, remove all the dependant attributes from the original transitive dependency. That is, simply remove the dependant attribute and draw a new dependency diagram to show all the tables you have identified in the previous 3 steps within the procedure for 3NF. Make sure to check each table for its determinant, and make sure each table contains no inappropriate dependencies. Once this has been achieved a new table has been created. Now remember, this normalization process is about cleaning up the structures within the database. Each stage of normalization (1NF, 2NF, & 3NF) all are working as building blocks to eliminate the partial and transitive dependencies. Overall the process of normalization assists the designer in eliminating data redundancies that can lead to major problems if not address in the initial stages of creation. So, a table that has been properly conversed into 3NF has met 2NF status, and it now contains no transitive dependencies. e. When is a table in BCNF? Boyce-Codd Normal Form or BCNF, is a higher-level form within the 3NF normalization process that typically is used in special cases. A table will be in BCNF when every determinant in the table is a candidate key. Remember from chapter 3 that a candidate key has the same characteristics as a primary key, but it was not chosen yet it still exists. Now when a table contains only one candidate key, the 3NF and the BCNF are equivalent, in other words it is possible for a table to conform to 3NF standards but not be BCNF. In order for a table to be both 3NF and BCNF, requires that the primary key for the original 3NF form needs to be changed in order for the dependency to work. Now changing the primary key will take a designer back to the beginning

13 steps of 1NF because a new partial dependency has been identified. Which means we are back to the initial stages of 1NF, meaning that now we have to work up again through the normalization process. Once the table has been through 1NF, 2NF, and 3NF, can we then determine the table being in a state of both 3NF and BCNF. 7. Using the following INVOICE table structure, draw its dependency diagram and identify all dependencies (including all partial and transitive dependencies). You can assume that the table does not contain repeating groups and that any invoice number may reference more than one product. Attribute name Sample value INV_NUM PROD_NUM AA_E3422QW SALE_DATE 06/25/1999 PROD_DESCRIPTION BJRotary sander, 6 in. disk VEND_CODE 211 VEND_NAME NeverFail, Inc. NUMBER_SOLD 2 PROD_PRICE $49.95 The dependency diagram above shows thus: Identification of the composite primary keys: INV_NUM & PROD_NUM Desirable dependencies show above the diagram with arrows, show all the desirable dependencies based of the combination of both primary keys. The schema as follows: 1NF (INV_NUM, PROD_NUM = SALE_DATE, PROD_DESCRIPTION, VEND_CODE, VEND_NAME, NUM_SOLD, PROD_PRICE)

14 Partial dependencies are show below the diagram attributes with lines/arrows, and show the dependencies that are based on part of the composite PK, in other words, dependencies using one of the two PK s. They include the schemas: PROD_NUM = (PROD_DESCRIPTION, VEND_CODE, PROD_PRICE) INV_NUM = (SALE_DATE) Transitive dependencies have been identified as well. They are: (VEND_CODE = VEND_NAME) 8. Using the initial dependency diagram drawn in problem 7, remove all partial dependencies, draw the new dependency diagrams, and identify the normal forms for each table structure you created. The diagrams below represent the new dependencies we have identified in problem 7. We have identified the three new tables: the INVOICE, PRODUCT, and the SALES. Because we have identified new dependencies using the composite key, we need to give this new table a name. It seems appropriate due to the contents of this schema that it should be called Sales (this is where we got the name for the table left to the designers discretion). The relational schemas would be followed as such: INVOICE (INV_NUM, SALE_DATE) PRODUCT (PROD_NUM, PROD_DESCRIPTION, VEND_CODE, VEND_NAME, PROD_PRICE,) SALES (INV_NUM, PROD_NUM, NUM_SOLD)

15 *Note that a transitive dependency still exist in the PRODUCT table. Take a look at the diagram: (this will be dealt with in problem 9 to conform to 3NF)

16 9. Using the table structures you have created in problem 8, remove all transitive dependencies, draw the new dependency diagrams, and identify the normal forms for each table structure you created. Now we are working toward the 3NF Normalization. We know we have a transitive dependency in the Product identified as VEND_CODE & VEND_NAME. Earlier we learned that a determinant is an attribute whose value determines another attributes value in a transitive dependency. Therefore, we know that the determinant in our example is VEND_CODE. Take a look at the schema: VEND_CODE = VEND_NAME VENDOR *NOTE: We will call this new table We will then eliminate the dependant attributes from the transitive dependencies by taking out VEND_NAME from the PRODUCT table. The PRODUCT table schema will change, although it could be left to be used as a foreign key. Here is what all the new table relational schemas will look like after we have completed the 1NF, 2NF, and 3NF normalization process. Schemas: INVOICE TABLE (INV_NUM, SALE_DATE) PRODUCT TABLE (PROD-NUM, PROD_DESCRIPTION, PROD_PRICE, VEND_CODE) SALES TABLE (INV_NUM, PROD_NUM, NUM_SOLD)

17 VENDOR TABLE (VEND_CODE, VEND_NAME) Now the dependency diagrams would appear as follows: We should have four new tables now:

18 10. Using the results of problem 9, draw the ERD. Below: