Database Systems Engineer Examination.pdf

Database Systems Engineer Examination

October, 2005 VITEC

Database Systems EngineerExamination (Afternoon, Part 1)

1 Examination Time-12:30-14:00 (90 minutes)

2 Questions must be answered in accordance with the following:

Question Nos Q1-Q4

Question Selection Select 3 from Q1 through Q4

3 Mark your examinee information and test answers in accordance with the instructions below

In the space provided on the answer sheet, write your examinee number If this item is not marked correctly, your test cannot be scored

(1) In the space provided on the answer sheet, write your date of birth exactly as they are printed on your examination admission card

(2) In the question selection column, circle the numbers of the three questions you select to answer If the question is not circled correctly, your test cannot be scored If you circle four numbers, only the first three questions will be graded

(3) Write each answer in the space specified for that question

(4) Write your answers clearly and neatly Answers that are difficult to read will receive a lower score

4 After the test, you may take this question booklet home with you

5 Observe the rules for describing conceptual data models, relation schemas, and relational database tables provided at the beginning of the booklet

Do not open the exam booklet until instructed to do so Inquiries about the exam questions will not be answered

Company names and product names appearing in the test questions are trademarks or registered trademarks of their respective companies Note that the ® and ™ symbols are not used within

i

Notation Used in the Questions

The notation for conceptual data models, relation schemas, and relational database table structures is given below This notation applies unless otherwise noted in the text of a question

1 Notation for Conceptual Data Models

Fig 1 Notation for Entity Types and Relationships

(1) Entity types are indicated using rectangles

(2) The entity type name is written inside the rectangle

(3) The relationship between entity types is indicated using a line (4) For a “1-to-1 relationship,” neither end of the line is an arrow

For a “1-to-many relationship,” one end of the line is an arrow For a “many-to-many relationship,” both ends of the line are arrows

Fig 2 Notation for Supertypes and Subtypes

(5) When representing supertypes and subtypes, lines are drawn between the supertype and the subtypes, and a “ ” is used at the branch point

1 to 1

1 to many

Many to many Entity type name

Entity type name

Entity type name

Entity type name Entity type name

Entity type name

Supertype name

Subtype name Subtype name

entity type name

attribute name 1, attribute name 2, ⋅⋅⋅ ⋅⋅⋅, attribute name n

Fig 3 Notation for the Attributes of Entity Types

(6) When representing the attributes of an entity type, the rectangle is divided into two sections, upper and lower The entity name is written in the upper section, while the attribute names are listed in the lower section

(7) When representing a primary key, a solid underline is used for the attribute name or group of attribute names that make up the primary key

(8) When representing a foreign key, a dotted underline is used for the attribute name or group of attribute names that make up the foreign key Note, however, that a dotted underline is not used when some of the attributes that make up the primary key are used to make up the foreign key

2 Notation for Relation Schemas

relation name (attribute name 1, attribute name 2, ⋅⋅⋅, attribute name n)

Fig 4 Notation for Relation Schemas

(1) A relation is represented by a relation name and a list of attribute names surrounded by parentheses to the right of the relation name This is called a relation schema (2) When representing a primary key, a solid underline is used for the attribute name or

group of attribute names that make up the primary key

(3) When representing a foreign key, a dotted underline is used for the attribute name or group of attribute names that make up the foreign key Note, however, that a dotted underline is not used when some of the attributes that make up the primary key are used to make up the foreign key

iii

3 Notation for Relational Database Table Structures

Table Name 1

Column name 1 Column name 2 Column name 3 Column name 4 Column name 5

Fig 5 Notation for Table Structures, Primary Keys, Foreign Keys and Reference Relationships

(1) A table name is entered followed underneath by the column names that make up the table Each column name is written inside a rectangle

(2) When representing a primary key, a solid underline is used for the column name or group of column names that make up the primary key

(3) When representing a foreign key, a dotted underline is used for the column name or group of column names that make up the foreign key Note, however, that a dotted underline is not used when some of the attributes that make up the primary key are used to make up the foreign key

(4) When representing a table to be referenced by the foreign key, a line is drawn either above or below the column name or group of column names that make up the foreign key A rectangle is drawn at the end and the name of the table to be referenced is entered inside The end of the line on the foreign key side is an arrow

Table name 2

Q1 Read the following description of a database, and then answer the Subquestions 1 through 3

Company M investigated relation schemas as part of its efforts to build a database for managing its catalog sales Figure 1 lists the relation schema that resulted from this work The meanings of major attributes in this relation schema are given in Table 1; the major functional dependencies between those attributes are shown in Figure 2; and the notations for the functional dependencies are given in Figure 3

Product information carried in the catalog was managed by defining product attributes as shown in Tables 2 through 5 As can be seen in the example in Table 3, the attributes and the data values vary from product to product

Purchase order (Customer ID, Order number, Date, Payment method, Address, Customer name, Telephone number)

Purchase details (Customer ID, Order number, Detail row number, Primary product code, Secondary product code, Primary product name, Secondary product name, Price, Shipping charge, Quantity)

Delivery (Customer ID, Order number, Specified delivery week day, Specified delivery time period)

Fig 1 Relation Schema for Catalog Sales

Table 1 Major Attributes and Their Meanings

Attribute Meaning Customer ID Number that uniquely identifies the customer who placed an order

Order number Number that uniquely identifies an order by a customer Payment method Money transfer from post office or COD

Detail row number Number of a row containing details of a purchase order

Primary product code

Code that uniquely distinguishes each individual product category (i.e., rack, chair, etc.) In product catalogs, some primary product codes differ even though the primary product names may be the same

Secondary product code

Code that further categorizes products by attributes (i.e., color, size, etc.) and is attached to each primary product code Ordering also requires this

secondary product code For the same {Customer ID, Order number}, there are no multiple detail rows which have the same {Primary product code, Secondary product code} In product catalogs, some secondary product codes differ even though the secondary product names may be the same

- 2 -

Fig 2 Major Functional Dependencies in Catalog Sales

Fig 3 Notations for Functional Dependencies

Table 2 Attributes and Meaning of Product Information in Catalogs

Attribute Meaning Product attribute code Code that clearly identifies a product attribute

Allowed value list Range of values available for product attributes For example, “M, L, etc.” for the size attribute The list is expressed in character strings

Data value Attribute value of a product attribute code For example, “M, etc.” would be the data value for the size attribute of a given product

Detail row number

Specified delivery date

Specified delivery time period

Table 3 Examples of Data Values from Product Catalog Information

Product attribute code 200 201 500 501 502 503 …

Note: A “—” appears in a data value cell when that attribute does not apply to the product

Table 4 Examples of Product Attributes

Product attribute code Product attribute name Data type

200 Primary product name character string 201 Secondary product name character string

Table5 Examples of Allowed Values

Primary product code Product attribute code Allowed value list

- 4 -

Subquestion 1

Answer the following questions concerning the relation “purchase order”

(1) List all candidate keys of the relation “purchase order” If a candidate key consists of multiple attributes, write them as {A, B}

(2) When updating data, a problem occurs with the relation “purchase order” Explain this situation specifically in as few words as possible

(3) In the same relation schema format as shown in Fig 1, describe the relations created by dividing the relation “purchase order” in the 3rd normal form

Subquestion 2

Answer the following questions concerning the relation “purchase details”

(1) List all non-key attributes that do not belong to any candidate key in the relation “purchase details”

(2) There are transitional functional dependencies in the relation “purchase details” Give one example of such a transitional functional dependency

(3) The relation “purchase details” is a 1st normal form and not a 2nd normal form Explain the reason for this in as few words as possible

Subquestion 3

Answer the following questions concerning notations in product catalog information and Tables 2 through 5:

(1) Add the functional dependencies regarding product catalog information to the dotted area in Figure 4 below, then complete the figure

Fig 4 Functional Dependencies of Product Catalog Information

(2) The conceptual levels of objects (attributes, relations, and functional dependencies) showing functional dependencies differ in Figures 2 and 4 Describe how they differ from one another in as few words as possible

Q2 Read the following description of SQL statements and database design, and then answer

the Subquestions 1 and 2

Company K, which provides information processing services, started online training courses for employees as part of its skills training programs These courses allow employees to study at any time using their own PCs The company also built a training-course participation management system

[Employee Management by the Participation Management System]

(1) Every employee in the company has a uniquely assigned employee ID

(2) Under participation management system, each employee belongs to a single department

(3) Each employee has an assigned role code according to his/her role (i.e., system engineer, database engineer or network engineer in the systems development department) The participation management system manages up to two role codes per employee There are cases where role codes are not assigned for newly hired or recently transferred employees

[Participation Management by the Participation Management System]

(1) The participation management system assigns one course code to each course (2) A standard participation time, standard participation period, and participation

points with which employees are awarded for attendance are assigned to each course

(3) An employee selects a course and starts taking it The participation management system creates a record of the employee’s attendance from the moment the employee starts taking the selected course

(4) There are one or more required training courses per role Whenever an employee logs onto the participation management system, a window appears to remind him/her of any required training course(s) the employee has yet to take as a way of encouraging the employee to enroll in the course(s)

(5) Each employee is assigned a maximum number of annual participation points that he/she can accumulate in a year When an employee starts a course, the number of participation points for that course is deducted from the employee’s annual participation points Any annual participation points remaining at the end of the year are carried over to the next year

(6) An achievement test is given at the end of every course If the employee scores at or higher than the required level set for each course, he/she passes the course

- 6 -

and the date of completion is recorded An employee is able to take a course and its achievement test multiple times until reaching the required “pass” level (7) An employee can re-enroll in a course that he/she has already completed

Participation points are deducted each time, regardless of the number of times the employee takes the course

(Table Structures of the Participation Management System)

The structures of major tables used to manage employee participation are shown in

minimum required score Required training course

Role code Course code Participation

Course code Employee ID Participation start

date Completion date

Achievement test score

Fig 1 Structures of Major Tables

[Creation of Departmental Participation Status Management Tables]

(1) For every department, the training-course participation status of its employees in a single year is tabulated and a departmental participation status management table (Figure 2) is outputted Departments with low levels of participation are to encourage their employees to take more courses

(2) The departmental participation status management table lists the number of personnel in that particular department, the number of persons who started one or more courses in a given year, the total number of participation points available (total of annual participation points and carry-over points) and the total number of participation points consumed in the year, by department code

(3) The output shows the status of participation up to the point that the table is printed out and, in the event that an employee was transferred during the period

covered by the table, his/her participation points are added to the department to which he or she now belongs

Departmental participation status management table Output date: Sep 30, 2005

Fig 2 Departmental Participation Status Management Table

[Changes to Employee Management Requirements in the Participation Management System]

After starting up the participation management system, Company K laid out guidelines on flexible personnel utilization which caused many employees to start working in multiple departments As a result, it became necessary for training-course the participation management system to accommodate the following provisions: (1) There is no restriction on the number of departments an employee can work in

The percentage of time that an employee is engaged concurrently in work in each of the departments is called the “concurrent ratio”, which is expressed in decimals, with “1” representing 100% For example, if a particular employee works in two (2) departments A and B, his/her concurrent ratio might be set at 0.7 for department A and 0.3 for department B

(2) When an employee who holds concurrent roles takes a course, the number of participation points is multiplied by the concurrent ratio and then divided up amongst the departments concerned

(3) An employee who works in multiple departments is assigned a role in each of those departments There is no restriction on the number of roles that an employee can hold in a given department