3.3. Define the following terms: entity, attribute, attribute value, relationship instance, composite attribute, multivalued attribute, derived attribute, complex attribute, key attribute, and value set (domain).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 or conceptual existence. attribute： The particular properties that describes the entity. attribute value： The attribute value describe each entity become a major part of the data stored in the database. relationship instance： Each relationship instance ri in R composite attribute：Composite attributes can be divided into smaller subparts, which represent more basic attributes with independent meanings. multivalued attribute： It means that an entity may have different numbers of values for particular attribute. derived attribute： One attribute can be derived from another attribute. For example, a particular person entity, the value of Age can be determined from the current(today’s) date and the value of the that person’s Brith_date. complex attribute： It means that a complex ( composite ) attribute is composed of more than one simple ( atomic ) attribute. key attribute： An entity type usually has an attribute whose values are distinct for each individual entity in the entity set. Such an attribute is called a key attribute, and its values can identify each entity uniquely. value set (domain)：Each simple attribute of an entity type is associated with a value set (or domain of values ), which specifies the set of values that may be assigned to that attribute for each individual entity. 3.7. What is a participation role? When is it necessary to use role names in the description of relationship types?Each entity type that participates in a relationship type plays a particular role in the relationship. It necessary to use role names in the description of relationship types, in some cases the same entity type participates more than once in relationship type in different roles. In such cases the role name become essential for distinguishing the meaning of each participation. Such relationship types are called recursive relationships.3.11. What is meant by a recursive relationship type? Give some examples of recursive relationship types.Recursive relationship is the entity type participates more than once in a relationship type in different role.For example. A department manger is the supervisor of the employee work for the department or a supervisee of a general manger of a company.3.16. Consider the following set of requirements for a UNIVERSITY database that is used to keep track of students’ transcripts. This is similar but not identical to the database shown in Figure 1.2:a. The university keeps track of each students’ name, student number, social security number, current address and phone, permanent address and phone, permanent address and phone, birth data, sex, class ( freshman, sophomore,… graduate), major department, minor department (if any), and degree program (B.A.,B.S.,…, Ph.D.).Some user applications need to refer to the city, state, and ZIP Code of the student’s permanent address and to the stu-dent’s last name. Both social security number and student number have unique values for each student.b. Each department is described by a name, department code, office num-ber, office phone, and college. Both name and code have unique values for each department.c. Each course has a course name, description, course number, number of semester hours, level, and offering department. The value of the course number is unique for each course.d. Each section has an instructor, semester year, course, and section num-ber. The section number distinguishes sections of the same course that are taught during the same semester/year; its values are 1,2,3,…up to the number of sections taught during each semester.e. A grade report has a student, section, letter grade, and numeric grade (0,1,2,3, or ,4).Design an ER schema for this application, and draw an ER diagram for the schema. Specify key attributes of each entity type, and structural constraints on each relationship type. Note any unspecified requirements, and make appropriate assumptions to make the specification complete.3.17. Composite and multivalued attributes can be nested to any number of lev-els. Suppose we want to design an attribute for a STUDENT entity type to keep track of previous college education. Such anattribute will have one entry for each college previously attended, and each such entry will have oneposed of college name, start and end dates, degree entries (degrees awarded at that college, if any), and transcript entries (courses completed at that col - lege, if any). Each degree entry contains the degree name and the month and year the degree was awarded, and each transcript entry contains a course name, semester, year, and grade. Design an attribute to hold this informa-tion. Use the conventions of Figure 3.5.{ PreviousEducation ( CollegeName, StartDate, EndDate,{ Degree (DegreeName, Month, Year) },{ Transcript (CourseName, Semester, Year, Grade) } ) }3.27. Cardinality ratios often dictate the detailed design of a database. The cardi-nality ratio depends on the real-world meaning of the entity types involved and is defined by the specific application. For the binary relationships below, suggest cardinality ratios based on the common-sense meaning of the entity types. Clearly state any assumptions you make. Entity 1 Cardinality Ratio Entity 21. STUDENT SOCLAL_SECURITY_CARD2. STUDENT TEACHER3. CLASSROOM WALL4. COUNTRY CURRENT_PRESIDENT5. COURSE TEXTBOOK6. ITEM (that can be ORDER found in an order)7. STUDENT CLASS8. CLASS INSTRUCTOR9. INSTRUCTOR OFFICE10. EBAY_AUCTION_ EBAY_BIDITEMEntity 1 Cardinality Ratio Entity 21. Student1-manyA student may have morethan one social security card (legally with the same unique
View Full Document
Unlocking...