Chapter 10 Fact-Finding Techniques Review Questions

10.1 Briefly describe what the process of fact-finding attempts to achieve for a database developer. Attempts to uncover facts about the business and the users of the database application including the vocabulary, problems, opportunities, constraints, requirements, and priorities. 10.2 Describe how fact-finding is used throughout the stages of the database application lifecycle. See Table 10.1 in Section 10.2. 10.3 For each stage of the database application lifecycle identify examples of the facts captured and the documentation produced. See Table 10.1 in Section 10.2. 10.4 A database developer normally uses several fact-finding techniques during a single database project. The five most commonly used techniques are examining documentation, interviewing, observing the business in operation, conducting research, and using questionnaires. Describe each fact-finding technique and identify the advantages and disadvantages of each. See Section 10.3. 10.5 Describe the purpose of defining a mission statement and mission objectives for a database application. Mission statement defines the major aims of the database application; the mission objectives identify the particular tasks that the database must support. Helps define the scope and boundary of the database application (see Section 10.4.2). 10.6 What is the purpose of identifying the systems boundary for a database application? Ensures that all appropriate areas of the organization are included in the system (see Section 10.4.3). 10.7 How does the contents of a users requirements specification differ from a systems specification? Systems specification describes the any features to be included in the new database application such as networking and shared access requirements, performance requirements, and the levels of security required. On the other hand, the users requirements specification describes in detail the data to be held in the database and how the data is to be used (see Section 10.4.4). 10.8 Describe one method to deciding whether to use either the centralized or view integration approach, or a combination of both when developing a database application for multiple user views. One way is to examine the overlap in the data used between the various user views (see, for example, Table 10.7).

Exercises
10.9 Assume that you are developing a database application for your enterprise whether it is a university (or college) or business (or department). Consider what fact-finding techniques you would use to identify the important facts needed to develop a database application. Identify the techniques that you would use for each stage of the database application lifecycle.

This is a small student project, the result of which is dependent on the enterprise examined. However, generally you would expect the student to use a variety of fact-finding techniques, depending on the size of the enterprise and the scope of the database application. 10.10 Assume that you are developing a database application for the case studies described in Appendix B. Consider what fact-finding techniques you would use to identify the important facts needed to develop a database application. The student could come at this from two directions: first, these are case studies and individuals within the organizations cannot be met or interviewed; second approach is more open, and the student assumes these are real organizations and staff can be interviewed, if necessary. This may involve some form of role play to help the student perform interviews and clarifythe requirements or elicit additional information. 10.11 Produce mission statements and mission objectives for the database applications described in the case studies given in Appendix B. University Accommodation Office Mission statement: The purpose of the University Accommodation Office database application is to maintain the data that we generate and to provide an efficient and effective service for the students on behalf of the University. Mission objectives: To maintain data on students wishing accommodation and their next-of-kin. To maintain data on halls of residence and student flats. To maintain data on leases. To maintain data invoices. To maintain data on student flat inspections. To maintain data on accommodation staff. To maintain data on courses. To support the queries listed in Section B.1.2 EasyDrive School of Motoring Mission statement: The purpose of the EasyDrive School of Motoring database application is to maintain the data that we generate, to provide an efficient and effective service our clients, and to facilitate the cooperation and sharing of information between offices. Mission objectives: To maintain data on offices. To maintain data on staff. To maintain data on vehicles and vehicle inspections. To maintain data on clients and interviews with clients. To maintain data on lessons and driving tests. To support the queries listed in Section B.2.2 Wellmeadows Hospital Mission statement: The purpose of the Wellmeadows Hospital database application is to maintain the data that we generate and to provide an efficient, effective, and friendly health care provision service for our elderly patients. Mission objectives: To maintain data on wards. To maintain data on staff. To maintain data on patients and their next-of-kin. To maintain data on local doctors. To maintain data on patient appointments.

To maintain data on out-patients. To maintain data on in-patients. To maintain data on both surgical and non-surgical supplies, and their suppliers. To maintain data on ward requisitions. To support the queries listed in Section B.3.2 10.12 Produce a diagram to represent the scope and boundaries for the database applications described in the case studies given in Appendix B.

University Accommodation Office Example System Boundary

Maintenance

Accommodation

Room

Lease

Invoicing

Payroll

Staff

Office

Student

Careers Office

HRM

Course EasyDrive School of Motoring Example System Boundary

Modules

Lesson

Vehicle

Maintenance

Invoicing

Client

Staff

Payroll

Driving Test

Wellmeadows Hospital Similar to the above two examples. 10.13

Office

HRM

Identify the major user views for the database applications described in the case studies given in Appendix B. University Accommodation Office Only one user view the Director of the University Accommodation Office. EasyDrive School of Motoring Only one user view the Director of the School. Wellmeadows Hospital Could have two user views one for the Director of the hospital and one for the Charge Nurse.

Chapter 11 Entity-Relationship Modeling Review Questions

11.1 Describe what entity types represent in an ER model and provide examples of entities with a physical or conceptual existence. An entity type represents a group of objects in the real world with the same properties (see Section 11.1). Examples of entities with physical and conceptual existence shown in Figure 11.2. 11.2 Describe what relationship types represent in an ER model and provide examples of unary, binary, ternary, and quaternary relationships. A relationship type is a set of associations between one or more participating entity types (see Section 11.2). Examples: Unary: Binary: Ternary: Quaternary: 11.3 Staff Supervise Staff (also called recursive relationship) Branch Has Staff Staff Registers Client at Branch Solicitor Arranges Bid with a Buyer supported by a Financial Institution.

Describe what attributes represent in an ER model and provide examples of simple, composite, single-value, multi-value, and derived attributes. An attribute represents a property of an entity or a relationship type (see Section 11.3). Examples: Simple: Composite: Single-valued: Multi-valued: Derived: position or salary attribute of Staff address attribute composed of street, city, and postcode attributes branchNo attribute of Branch telNo attribute of Branch duration attribute of Lease, calculated from rentStart and rentFinish attributes.

11.4

Describe what the multiplicity constraint represents for a relationship type. Multiplicity represents the number (or range) of possible occurrences of an entity type that may relate to a single occurrence of an associated entity type through a particular relationship (see Section 11.6).

11.5

What are enterprise constraints and how does multiplicity model these constraints? Enterprise constraints are rules that the data in the database must conform to as specified by users or database administrators of a database (see Section 3.3.4). Multiplicity constrains the way that entities are related it is a representation of the policies (or business rules) established by the user or enterprise.

11.6

How does multiplicity represent both the cardinality and the participation constraints on a relationship type? Multiplicity actually consists of two separate constraints (see Section 11.6.5): Cardinality which describes the maximum number of possible relationship occurrences for an entity participating in a given relationship type. Participation which determines whether all or only some entity occurrences participate in a relationship.

11.7

Provide an example of a relationship type with attributes.

The relationship Newspaper Advertises PropertyForRent consists of two attributes: dateAdvert (representing the date the advert took place) and cost (representing the cost of the advert). 11.8 Describe how strong and weak entity types differ and provide an example of each. A strong entity type is an entity type that is not existence-dependent on some other entity type (see Section 11.4). Examples of strong entity types are Branch, Staff, and PropertyForRent. A weak entity type is an entity type that is existence-dependent on some other entity type. An example of a weak entity type is Preference. 11.9 Describe how fan and chasm traps can occur in an ER model and how they can be resolved. A fan trap occurs where a model represents a relationship between two entity types, but the pathway between certain entity occurrences is ambiguous. Resolve the fan trap by restructuring the original ER diagram to represent the correct association between these entities (see Section 11.7.1). A chasm trap occurs where a model suggests the existence of a relationship between entity types, but the pathway does not exist between certain entity occurrences. A chasm trap may occur where there are one or more relationships with optional participation. Resolve the chasm trap by identifying the missing relationship (see Section 11.7.2).

Exercises
11.10 (a) Create an ER diagram for each of the following descriptions: Each company operates four departments, and each department belongs to one company.

Company
1..1

Operates 4

Department

(b)

Each department in part (a) employs one or more employees, and each employee works for one department.

Department
1..1

Employs 1..*

Employee

(c)

Each of the employees in part (b) may or may not have one or more dependants, and each dependant belongs to one employee.

Employee
1..1

Has 0..*

Dependent

(d)

Each employee in part (c) may or may not have an employment history.

Employee
1..1

Provides 0..*

Employment History

(e)

Represent all the ER diagrams described in (a), (b), (c), and (d) as a single ER diagram.

Company
1..1

Operates 4

Department

1..1 Employs

1..*

Employment History

Provides 0..* 1..1

Employee

1..1 Has

0..*

Dependent

11.11

You are required to create a conceptual data model of the data requirements for a company that specializes in IT training. The Company has 30 instructors and can handle up to 100 trainees per training session. The Company offers five advanced technology courses, each of which is taught by a teaching team of two or more instructors. Each instructor is assigned to a maximum of two teaching teams or may be assigned to do research. Each trainee undertakes one advanced technology course per training session. (a) (b) (c) Identify the main entity types for the company. Identify the main relationship types and specify the multiplicity for each relationship. State any assumptions you make about the data. Using your answers for (a) and (b), draw a single ER diagram to represent the data requirements for the company.

Research
0..*

Assigned 1..1

Instructor

IsPartOf 1..1 0..2

TeachingTeam

1..1 Teaches

1..* Provides Advanced Training 1..* 1..* Course 1..* 1..1 Session Read the following case study, which describes the data requirements for a video rental company. The video rental company has several branches throughout the USA. The data held on each branch is the branch address made up of street, city, state, and zip code, and the telephone number. Each branch is given a branch number, which is unique throughout the company. Each branch is allocated staff, which includes a Manager. The Manager is responsible for the day-to-day running of a given branch. The data held on a member of staff is his or her name, position, and salary. Each member of staff is given a staff number, which is unique throughout the company. Each branch has a stock of videos. The data held on a video is the catalog number, video number, title, category, daily rental, cost, status, and the names of the main actors, and the director. The catalog number uniquely identifies each video. However, in most cases, there are several copies of each video at a branch, and the individual copies are identified using the video number. A video is given a category such as Action, Adult, Children, Drama, Horror, or Sci-Fi. The status indicates whether a specific copy of a video is available for rent. Before hiring a video from the company, a customer must first register as a member of a local branch. The data held on a member is the first and last name, address, and the date that the member registered at a branch. Each member is given a member number, which is unique throughout all branches of the company. Once registered, a member is free to rent videos, up to maximum of ten at any one time. The data held on each video rented is the rental number, the full name and number of the member, the video number, title, and daily rental, and the dates the video is rented out and date returned. The rental number is unique throughout the company. Attends

Trainee 11.12

(a) (b) (c) (d) (e) (f)

Identify the main entity types of the video rental company. Identify the main relationship types between the entity types described in (a) and represent each relationship as an ER diagram. Determine the multiplicity constraints for each relationships described in (b). Represent the multiplicity for each relationship in the ER diagrams created in (b). Identify attributes and associate them with entity or relationship types. Represent each attribute in the ER diagrams created in (c). Determine candidate and primary key attributes for each (strong) entity type. Using your answers (a) to (e) attempt to represent the data requirements of the video rental company as a single ER diagram. State any assumptions necessary to support your design.

Video
catalogNo 1..1 Is

1..*

VideoForRent
videoNo 1..1 1..*

IsAllocated 1..1

Branch
branchNo

Has 1..1 Manages 0..1 1..1 1..*

Staff
staffNo

1..1 Registers

IsPartOf

1..*

Registration

1..* Agrees

1..*

1..1 0..*

RentalAgreement
rentalNo 0..*

Requests 1..1

Member
memberNo

Chapter 12 Enhanced Entity-Relationship Modeling Review Questions

12.1 Describe what a superclass and a subclass represent. A superclass is an entity type that includes one or more distinct subgroupings of its occurrences, which require to be represented in a data model. A subclass is a distinct subgrouping of occurrences of an entity type, which require to be represented in a data model (see Section 12.1.1). 12.2 Describe the relationship between a superclass and its subclass. The relationship between superclass and subclass is 1:1, called a superclass/subclass relationship (see Section 12.1.2). Each member of a subclass is also a member of the superclass. 12.3 Describe and illustrate using an example the process of attribute inheritance. An entity in a subclass represents the same real world object as in the superclass, and may possess subclassspecific attributes, as well as those associated with the superclass. For example, a member of the SalesPersonnel subclass inherits all the attributes of the Staff superclass such as staffNo, name, position, and salary together with those specifically associated with the SalesPersonnel subclass such as salesArea and carAllowance (see Section 12.1.3). 12.4 What are the main reasons for introducing the concepts of superclasses and subclasses into an EER model? There are two important reasons for introducing the concepts of superclasses and subclasses into an ER model. Firstly, it avoids describing similar concepts more than once, thereby saving time for the designer and making the ER diagram more readable. Secondly, it adds more semantic information to the design in a form that is familiar to many people. For example, the assertions that Manager IS-A member of staff and flat IS-A type of property, communicates significant semantic content in a concise form (see Section 12.1.2). 12.5 Describe what a shared subclass represents and how does this concept relate to multiple inheritance. A subclass with more than one superclass is called a shared subclass. The subclass will inherit the attributes of all its superclasses (ie multiple inheritance). 12.6 Describe and contrast the process of specialization with the process of generalization. Specialization is the process of maximizing the differences between members of an entity by identifying their distinguishing features. Generalization is the process of minimizing the differences between entities by identifying their common features. Specialization is a top-down approach whereas generalization is a bottomup approach (see Sections 12.1.4 and 12.1.5). 12.7 Describe the two main constraints that apply to a specialization/generalization relationship. Two main constraints are: participation and disjoint constraints (see Section 12.1.6). 12.8 Describe and contrast the concepts of aggregation and composition and provide an example of each. Aggregation represents a has-a or is-part-of relationship between entity types, where one represents the whole and the other the part. Composition is a specific form of aggregation that represents an association between entities, where there is a strong ownership and coincidental lifetime between the whole and the part (see Sections 12.2 and 12.3).

Exercises
12.9 Consider whether it is appropriate to introduce the enhanced concepts of specialization/generalization, aggregation, and/or composition for the case studies described in Appendix B. Consider whether it is appropriate to introduce the enhanced concepts of specialization/generalization, aggregation, and/or composition into the ER model for the case study described in Exercise 11.12. If appropriate, redraw the ER diagram as an EER diagram with the additional enhanced concepts. Could consider Manager as a specialization of the Staff entity. This would move the Manages relationship from Staff to the Manager subclass. However, the attributes for both entities would be the same and there would, therefore, seem to be no obvious advantage to introducing the Manager specialization.

12.10