Database Systems Engineer Examination.pdf

October, 2005 VITEC

Database Systems Engineer

Examination (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

ii

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

- 1 -
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.

Address
Customer
name
Telephone
number
Payment
method
Date
Customer
ID
Order number
Detail row number
Specified delivery date
Specified delivery time period
Primary product

code
Secondary
product code
Quantity
Primary
product name
Secondary
product name
Price
Shipping
charge
Legend
Meaning

- 3 -
Table 3 Examples of Data Values from Product Catalog Information
Product attribute code 200 201 500 501 502 503 …
Primary
product
code
Product
attribute
name
Secondary
product code
Primary
product
name
Secondary
product

name
Color Size Price
Shipping
charge

0101 WM White M 3,000 350
0102 WL White L 5,000 400
0201 BM Black M 3,000 350
0202 BL Black L 5,000 400
0301 RM Red M 3,000 350
2003
0302
Rack
RL Red L 5,000 400
0101 B Brown — 6,000 500
0102 G Gray — 6,000 500
2004
…
Chair
…
…
…
…
…
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

500 Color character string
501 Size character string
502 Price numerical value
503 Shipping charge numerical value
504 Weight numerical value
505 Material character string
…
…
…

Table5 Examples of Allowed Values
Primary product code Product attribute code Allowed value list
200 Rack
201
WM, WL, BM, BL, RM,
RL
500 White, Black, Red
501 M, L
502 3000, 5000
2003
503 350, 400
200 Chair
201 B, G
500 Brown, Gray
502 6000
2004
503 500
…
…
…

- 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.

Product attribute
code
Primary product
code
Secondary
product code

Data type
Product
attribute name
Allowed value
list
Data value


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.