3. C OMPETENCIA SINDICAL EN LA NEGOCIACIÓN COLECTIVA
3.2. Evidencias empíricas de la competencia sindical sobre diferentes
T H I N G S T O T H I N K A B O U T
What is the benefit of reviewing the entities according to the role they play in design?
Looking over her list, Sharon realizes there is one domain entity that she still hasn’t included. That is the Request entity, which allows students to request tutoring in areas where it is not already provided. Her first instinct is to link the Request entity to the Student entity, but then she has second thoughts. Does she really want to force a student to register to request tutoring for a course where there isn’t tutoring currently?
The student making the request is quite probably not being tutored at the moment. Still she would like to link the table into the rest of the database. As she understands it, the Course table will contain all the courses for a quarter.
Here, then, is her final Entity Relationship Diagram.
Tutor
FIGURE 4-41 Final ERD Before Review
Before taking this diagram to Terry, Sharon decides to have her instructor Bill Collins review it. She emails him, requesting an appointment, and attaches the diagram so he can go over it before they meet. Within minutes, he sends an email back, agreeing to meet the next morning. He said he would look over the design and make sure that it was normalized.
DOCUMENTATION
Diagrams often communicate more clearly than words. It is important to keep ERDs in your database notebook. It is also a good idea to keep a history of diagrams. As your design progresses, you will make changes to the diagrams, adding and removing enti-ties and attributes. Rather than just discarding the older diagrams, it can be valuable to keep dated versions of the ERD along with notes defining what changes were made and why. Coming back later, this can help you or a later developer understand the thought process that culminated in the final database design.
Things We Have Done
In this chapter we have
• worked through the logical design of the database • created entities
• added attributes to entities
• analyzed and created relationships among our entities • identified the roles the entities play in our design
Vocabulary
Match the definitions to the vocabulary words:
1. Cardinality
— d. A set of rules or suggestions that promote consistency in the naming of database objects — e. Notation for relationships that uses lines and circles to depict cardinality
— f. An entity which resolves a many-to-many relationship into two one-to-many relationships — g. Refers to the number of permitted records in a related entity
1. Look up other database-naming conventions. Is there one that makes the most sense to you? Explain why?
2. Look up Entity Relation Diagrams. What other ways of diagramming entities and relations did you find?
3. Look for online tutorials on relational database design.
Make a list of the five best. Share with the class to make a resource list of tutorials.
Practices
1. Create an entity to describe the products in a sandwich shop. These can include sandwiches, of course, but also pas-tries and drinks.
2. Which attributes of the products entity should be required?
3. Which attributes would make a good primary key?
4. Here are two entities. (Only the primary keys are included.) What kind of relationship exists between these entities?
Explain.
5. Create a diagram that shows how you would resolve the relationship in Practice 4.
6. An instructor has decided that he needs a relational data-base to store grades in. He has defined the following three entities: Student , Course , and Assignment . What kind of relationship exists between these entities?
7. Create an entity relation diagram for the instructor’s data-base. Don’t worry about the attributes, but give each entity a primary key attribute. Remember to watch out for many-to-many relationships.
8. A dentist office has three dentists, two hygienists, five dental assistants, and two administrative assistants to maintain the office paper work. They are creating a
database to track appointments and also to track who works with each patient. So far the database developer has defined the following entities: Employee (which includes all categories of employee including the dentists), Customer, and Appointment. Which entities have many-to-many relationships?
9. Create an ERD that shows the relationships among the enti-ties in the dentist office mentioned in Practice 9. Remember several employees (a dentist, an assistant, a hygienist, etc.) can be involved in a single appointment for a customer.
10. Look at the diagram for Practice 8. Identify which entities are domain entities, which are linking entities, which are lookup, and which, if any, are weak entities.
Recipe
The managers at Wild Wood Apartments are anxious to see some progress on their database. They have answered your questions and now want to see some results. They really want the new database to be in place before the beginning of the new fiscal year in July. It is time to design the database.
1. Review all the requirements and business rules.
2. Define your entities and attributes and the relations that exist between them.
3. Create a logical model using crow’s feet notation in Visio or hand draw it on graph paper, if you prefer.
4. Add all the entities and their attributes. You don’t need to worry about data types for now.
5. Identify the key fields for each entity and the foreign keys.
6. Analyze the diagram. Identify which role (i.e., domain, linking, lookup, or weak) each entity plays in your database.
7. Have another student or a group review it for the following:
a. Are all the major components of the Wildwood Apartments business model represented by domain entities?
b. Does each entity contain the appropriate attributes to fully describe it and meet the business rules you have gathered so far?
c. Does every entity have an appropriate primary key defined?
d. Are all many-to-many relationships resolved into one-to-many relationships by linking tables?
e. Are the relationships valid (no cross relationships)?
Isthe appropriate entity defined as the one side of a one-to-many relationship? Do the tables have appro-priate foreign keys? Also check for other such issues.
f. Are lookup tables used for attributes that have a set list of values?
8. Documentation: Be sure to store your ERDS in your da-tabase notebook.
VINCE’S VINYL
Vince is convinced he is losing money on several of his transac-tions. He is anxious to get the new database in place to help him get control over his business. He has been polite but keeps checking on your progress. It is time to show some results.
Create a logical design of Vince’s database. Use the follow-ing steps:
1. Review all the requirements and business rules that you have gathered from your interviews and after reviewing Vince’s records.
2. Define your entities and attributes and the relations that exist between them.
3. Create a logical model using crow’s feet notation in Visio or hand draw it on graph paper, if you prefer.
4. Add all the entities and their attributes. You don’t need to worry about data types for now.
5. Identify the key fields for each entity and the foreign keys.
6. Analyze the diagram. Identify which role (i.e., domain, linking, lookup, or weak) each entity plays in your database.
7. Have another student or a group review it for the following:
a. Are all the major components of the Vince’s business model represented by domain entities?
b. Does each entity contain the appropriate attributes to fully describe it and meet the business rules you have gathered so far?
c. Does every entity have an appropriate primary key defined?
d. Are all many-to-many relationships resolved into one-to-many relationships by linking tables?
e. Are the relationships valid (no cross-relationships)? Is the appropriate entity defined as the one side of a one-to-many relationship? Do the tables have appro-priate foreign keys? Also check for other such issues.
f. Are lookup tables used for attributes that have a set list of values?
8. Documentation: Be sure to store your ERDs in your da-tabase notebook.
GRANDFIELD COLLEGE
A team from the Software Alliance could show up any day. The IT services manager is eager to get the tracking database in place. It is time to show some progress. Create the logical de-sign of the database following these steps:
1. Review all the requirements and business rules.
2. Define your entities and attributes and the relations that exist between them.
3. Create a logical model using crow’s feet notation in Visio or hand draw it on graph paper, if you prefer.
4. Add all the entities and their attributes. You don’t need to worry about data types for now.
5. Identify the key fields for each entity and the foreign keys.
6. Analyze the diagram. Identify which role (i.e., domain, linking, lookup, or weak) each entity plays in your database.
7. Have another student or a group review it for the following:
a. Are all the major components of the software tracking system represented by domain entities?
b. Does each entity contain the appropriate attributes to fully describe it and meet the business rules you have gathered so far?
c. Does every entity have an appropriate primary key defined?
d. Are all many-to-many relationships resolved into one-to-many relationships by linking tables?
e. Are the relationships valid (no cross-relationships)? Is the appropriate entity defined as the one side of a one-to-many relationship? Do the tables have appro-priate foreign keys? Also check for other such issues.
f. Are lookup tabtles used for attributes that have a set list of values?
8. Documentation: Be sure to store your ERDs in your database notebook.
WESTLAKE RESEARCH HOSPITAL
It is imperative that the database be ready before the actual clin-ical trials begin. The staff at Westlake is anxious to see some re-sults. It is time you show them the logical design of their data-base. Follow these steps:
1. Review all the requirements and business rules.
2. Define your entities and attributes and the relations that exist between them.
3. Create a logical model using crow’s feet notation in Visio or hand draw it on graph paper, if you prefer.
4. Add all the entities and their attributes. You don’t need to worry about data types for now.
5. Identify the key fields for each entity and the foreign keys.
6. Analyze the diagram. Identify which role (i.e., domain, linking, lookup, or weak) each entity plays in your database.
7. Have another student or a group review it for the following:
a. Are all the major components of the clinical trial rep-resented by domain entities?
b. Does each entity contain the appropriate attributes to fully describe it and meet the business rules you have gathered so far?
c. Does every entity have an appropriate primary key defined?
d. Are all many-to-many relationships resolved into one-to-many relationships by linking tables?
e. Are the relationships valid (no cross-relationships)?
Is the appropriate entity defined as the one side of a one-to-many relationship? Do the tables have appro-priate foreign keys? Also check for other such issues.
f. Lookup tables are used for attributes that have a set list of values.
8. Documentation: Be sure to store your ERDs in your da-tabase notebook.
SUGGESTION FOR THE SCENARIOS
These scenario exercises are probably the most difficult in the book. The first suggestion is to not panic. Creating ERDs is an iterative process. No one expects you to have a perfect diagram on the first attempt. The trick is to add entities one at a time.
Don’t try to imagine the whole diagram all at once. Look at each entity separately. Does it have the appropriate attributes? Is the primary key defined? After the main entities are on the dia-gram, look at the relationships between two entities at a time.
What kind of relationship do they have? Do you need a linking table? Also check for other such issues. Remember, also, that some entities have no direct relationship between them. Don’t fall into the trap of trying to relate every entity to every other entity.
Discussion helps. Others can see issues and approaches that you might have missed. It is always good to have another pair of eyes looking over your work.