VITEC Database Systems Engineer Examination (Afternoon, Part 1)

Chia sẻ: Tran Le Kim Yen Tran Le Kim Yen | Ngày: | Loại File: PDF | Số trang:23

Thêm vào BST

Báo xấu

42
lượt xem 5
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

1. Examination Time-12:30-14:00 (90 minutes). 2. Questions must be answered in accordance with the following: Question Nos. Question Selection Q1-Q4 Select 3 from Q1 through Q4

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: VITEC Database Systems Engineer Examination (Afternoon, Part 1)

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: Q1-Q4 Question Nos. Select 3 from Q1 through Q4. Question Selection 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.
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 1 to 1 Entity type name Entity type name 1 to many Entity type name Entity type name Many to many Entity type name Entity type name 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. Supertype name Subtype name Subtype name 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. i
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. ii
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 Table name 2 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. iii
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 Code that uniquely distinguishes each individual product category (i.e., rack, Primary product chair, etc.). In product catalogs, some primary product codes differ even code though the primary product names may be the same. 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 secondary product code. For the same {Customer ID, Order number}, there code 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. -1-
Address Specified delivery date Customer ID Customer Specified delivery time period name Primary product Primary Telephone code product name Order number number Secondary Secondary p roduct code product name Payment method Price Date Shipping charge Detail row number Quantity Fig. 2 Major Functional Dependencies in Catalog Sales Legend Meaning 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 Range of values available for product attributes. For example, “M, L, etc.” Allowed value list for the size attribute. The list is expressed in character strings. Attribute value of a product attribute code. For example, “M, etc.” would Data value be the data value for the size attribute of a given product. -2-
Table 3 Examples of Data Values from Product Catalog Information Product attribute code 200 201 500 501 502 503 … Product Primary Primary Secondary attribute Shipping name Color Size Price product product product charge Secondary code name name product code 0101 WM White M 3,000 350 0102 WL White L 5,000 400 0201 BM Black M 3,000 350 2003 Rack 0202 BL Black L 5,000 400 0301 RM Red M 3,000 350 0302 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 2003 200 Rack WM, WL, BM, BL, RM, 201 RL 500 White, Black, Red 501 M, L 502 3000, 5000 503 350, 400 2004 200 Chair 201 B, G 500 Brown, Gray 502 6000 503 500 … … … -3-
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. Data type P roduct attribute code Product attribute name Primary product code Allowed value list Secondary product code 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. -4-
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 -5-
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 Figure 1. Department Department code Department name Role Role code Role name Employee Department code Role code 1 Role code 2 Employee ID Name Number of annual Number of carry-over participation points points from last year Course Standard Standard Number of Course code Course name participation time participation period participation points Achievement test minimum required score Required training course Role code Course code Participation Participation start Achievement test Course code Employee ID Completion date date 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 -6-
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 Apr. 1, 2005-Sep. 30, 2005 Number of Department Number of employees Total points Total points Department name code employees taking available consumed courses Marketing 106 62 37 3,200 1,860 Public Sector Sales 107 130 80 7,000 4,030 Technical Development 108 35 10 1,750 525 IT Sales 110 250 100 11,000 5,000 Network Development 111 180 135 9,000 6,750 Public Sector Systems 112 50 26 2,500 1,325 Development Testing 113 8 0 400 0 Distribution Systems 114 333 149 16,650 7,492 Development … … … … … … 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. -7-
Subquestion 1 Answer the following questions regarding SQL statements pertaining to the training- course participation management system prior to the changes made in employee management provisions. A I (1) Fill in the blanks through in the following SQL statements so that the departmental participation status management table (Fig. 2) from April 1, 2005 through September 30, 2005, can be printed out. Table headers and item names can be ignored. SELECT department.department_code, department.department_name, COUNT (employee.employee_ID), COUNT (total_participation_points.employee_ID), SUM (number_of_annual_participation_points + number_of_carryover_points_from_last_year), SUM (number_of_participation_points_consumed) FROM department, employee LEFT JOIN A B (SELECT AS number_of_participation_points_consumed , C FROM D WHERE E F AND participation_start_date ‘2005-04-01’ ‘2005-09-30’ G GROUP BY ) total_participation_points H employee.employee_ID = total_participation_points.employee_ID WHERE department.department_code = employee.department_code GROUP BY department.department_code, department.department_name I department.department_code (2) The company wishes to display all the course codes and course names of any required training courses that the employee with ID No. 123456 has yet to take. Complete the following SQL statements so as to retrieve that data for display. SELECT course.course_code, course.course_name FROM course, required_training_course, employee WHERE employee_ID = 123456 AND required_training_course.course_code = course.course_code J AND AND course.course_code NOT IN K ( ) -8-
Subquestion 2 Answer the following questions concerning the application of changes made to the employee management provisions of the training-course participation management system. (1) To respond to the changes made in employee management provisions, it was decided to add “Affiliation” and “Employee role” tables to the table structures in Fig. 1, and to modify the “Employee” table. If the “Affiliation” table is structured as follows, how will the “Employee role” and “Employee” tables be structured? In determining those table structures, follow the rules stipulated in the “Notation for Relational Database Table Structures” section of the preface to this exam. Primary keys must be indicated, but there is no need to indicate foreign keys. Affiliation Employee ID Department code Concurrent ratio (2) Because of the changes made in table structures, it also became necessary to change the SQL statements in the answer to Subquestion 1-(1). Fill in the blanks L O through below to complete the SQL statements in their new form. Here, the number of personnel and the number of personnel taking courses are indicated as the total number of personnel in a given department. If an employee works in multiple departments, he/she is counted in each of those departments. SELECT department.department_code, department.department_name, COUNT (employee.employee_ID), COUNT (total_participation_points.employee_ID), L AS total_participation_points_available, M AS total_participation_points_consumed N FROM LEFT JOIN A B (SELECT AS number_of_participation_points_consumed , C FROM D WHERE E F AND participation_start_date ‘2005-04-01’ ‘2005-09-30’ G GROUP BY ) total_participation_points H employee.employee_ID = total_participation_points.employee_ID O WHERE GROUP BY department.depertment_code, department.department_name I department.department_code -9-
Q3. Read the following description of an order management system for a restaurant chain, and then answer the Subquestions 1 through 3. A system integrator was hired by a Company to develop an order management system that the Company would use at its 20 restaurants. Mr. F of the SI was placed in charge of database design. Specifications for the order management system at the restaurants are as follows. [Restaurants and Employees] (1) A unique restaurant code is assigned to each restaurant. (2) Each employee is assigned a unique employee ID for each restaurant. [Food] (1) The price of menu items are the same at all the restaurants. However, the types of menu items served vary from restaurant to restaurant. Each item must be assigned a unique menu item code common to all the restaurants. (2) Ordering “sets” of side order is less expensive than ordering those side orders individually (à la carte). A side-order “set” consists of two or more individual side orders, and a “meal set” consists of a main dish combined with a set of two or more side orders. (3) A main dish can be combined with any of various side-order sets. Likewise, a side-order set can be combined with any of various main dishes. For example, a Hamburger (main dish) can be ordered with a Salad Set, a Soup & Salad Set and/or a Drink Set; or, a Beef Steak (main dish) can be ordered with any of four kinds of side-order sets (Salad Set, Soup & Salad Set, Soup Set or Drink Set). A Salad Set comes with a salad and bread, a Soup & Salad Set with soup, salad and bread, a Soup Set with soup and bread, and a Drink Set with a soft drink and bread. (4) Side-order sets are assigned “set codes” that are different from the codes assigned to the individual side orders that make up the sets. [Taking initial orders] (1) The waiter/waitress takes orders by table. Each table must be assigned a unique table ID for each restaurant. (2) The waiter/waitress inputs the customer’s order on a handheld terminal and sends the contents (order category that indicates a initial order, table ID, number of persons, his/her employee ID, handheld terminal ID, menu item codes and - 10 -
quantities of menu item ordered items) to an order management server. There is no duplication of codes in this transmission. (3) The order management server of each restaurant assigns a unique order number for each initial order received and registers it in a database. (4) The order management server sends the assigned order number to the handheld terminal. (5) After confirming that the order number has been received, the waiter/waitress prints out the initial order slip (Figure 1) and places it on the customer’s table. Additional Order Slip Initial Order Slip Restaurant code 012 (Main St.) Restaurant code 012 (Main St.) Date/Time order received Oct. 1, 2005/18:45 Date/Time order received Oct. 1, 2005/18:15 Order number 01234 Order number 01234 Table code 001 Persons 3 Table code 001 Persons 3 Waiter/Waitress 012 (Jill) Waiter/Waitress 010 (Mary) Handheld terminal number 02 Handheld terminal number 01 Item Qty Unit price Price Item Qty Unit price Price Ice cream Hamburger Strawberry Short Cake Salad Set Beverage subtotal Beef Curry Subtotal Drink Set VAT Beef Steak Total Soup & Salad Set Subtotal VAT Total Fig. 2 Example of Additional Order Slip Fig. 1 Example of Initial Order Slip [Taking additional orders] (1) The waiter/waitress inputs the order number of the order slip on the customer’s table and the additional order of the customer in the handheld terminal and sends the contents (order category that indicates an additional order, order number assigned to the initial order, table ID, number of persons, his/her employee ID, handheld terminal ID, menu item codes and quantities of ordered items) to the order management server. No duplicated menu item codes are sent. (2) The order management server records the additional order in the database. However, multiple orders received by the server, indicating the same order number with the same time, will not be taken. (3) The order management server sends the total price of the original order prior to the additional order to the handheld terminal of the waiter/waitress. (4) After confirming reception from the order management server, the waiter/waitress prints out the additional order slip (Figure 2) and places it on the customer’s table next to the initial order slip that is already there. - 11 -
[Handling of orders by the kitchen] (1) When an order is received, the order management server prints out a slip (Figure 3) that indicates the menu item code, item name, table ID and time of order on a printer located in the kitchen. If two or more of the same menu item were ordered in a single order, a separate slip is printed out for each orders of that item. (2) When the preparation of an order is complete, the chef attaches the slip to the order and sets the order on the out counter. The waiter/waitress carries the order from the out counter to the customer’s table and places a check in the box next to that item on the order slip kept on the customer’s table. 2200 Hamburger Table ID: 001 18:15 Fig. 3 Example of Kitchen Slip [Payment] (1) The customer gives the order slip to the cashier and pays for the order. The cashier inputs the order number printed on the order slip into the cash register and requests the customer to pay the amount that appears on the cash register display. (2) The receipt that is handed to the customer contains the restaurant code, receipt number (same as the order number), number of persons and table ID at the time of the initial order, date/time of the receipt, name of the cashier, menu item names, quantity, unit price and total price per menu item, subtotal, VAT, total price, amount of money received and change returned (Figure 4). Receipt Restaurant code 012 (Main St.) Date/Time of receipt Oct. 1, 2005/19:20 Receipt number 01234 Table code 001 Persons 3 Cashier 008 (Bill) Dish Qty Unit price Price Hamburger Salad Set Beef Curry Drink Set Beef Steak Soup & Salad Set Ice cream Strawberry Short Cake Subtotal VAT Total Amount paid Change Fig. 4 Example of Receipt - 12 -
Restaurant Restaurant code Restaurant name Address Number of tables Employee Restaurant code Employee ID Employee name Menu item Menu item code Menu item name Unit price Order Order Waiter/Waitress Restaurant code Date/time of order Order category Table ID Number of persons number employee ID Handheld terminal Menu item code Quantity number Receipt Restaurant Receipt Number of Date/Time of receipt Table ID Cashier employee ID Subtotal price code number persons VAT Total price Amount paid Figure 5 Table Structures Mr. F designed the table structures in Figure 5 based on the given conditions and requirements. After seeing these table structures, his superior, Mr. G, pointed out a few problems. Problem No primary keys or foreign keys are indicated. Problem The “Order” table has a redundant table structure. Problem There are no provisions for the variations in menu items available from one restaurant to another. Problem There were no provisions for the ordering of side-order sets and meal sets. Subquestion 1 Answer the following questions in regard to problems and cited by Mr. G. (1) Indicate the primary keys in the “Employee”, “Menu item” and “Receipt” tables in Fig. 5. (2) Change the table structure of the “Order” table so as to eliminate the redundancy cited by Mr. G in problem and indicate the primary key. In doing so, if you add a column name not already appearing in Fig. 5, what values will you set for that column? - 13 -
Subquestion 2 Answer the following questions in regard to problems and cited by Mr. G. (1) Draw up the structure of the newly added table that resolves problem . (2) Draw up the structure of the newly added table that resolves problem . Subquestion 3 It has occurred when multiple customers in the same party at the same table order different sets when placing an initial order that someone’s order is delayed and, in some cases, doesn’t arrive until others have completely finished their meal. As a means of improving customer satisfaction, a way to make sure that food is not served to some customers in the same party before others, was added as a new requirement. To achieve this, it was decided that kitchen slips will be printed with consideration to standard time required to prepare each dish. To enable this, the following requirements were placed on table structures. (i) Classify food into the four categories of appetizer, soup, main dish and dessert. (ii) Set a standard preparation time for each dish. (iii) Set a sequence for preparing food based on food categories. Change the table structures in Fig. 5 and add any new tables so as to meet these new requirements. In providing an answer, include the tables added in Subquestion 2. (1) Indicate the table name of any table to which a column was added in Fig. 5 and the name of that column. (2) Draw the structure of the newly added table. - 14 -
Q4. Read the following description of database design, and then answer the Subquestions 1 through 3. Company X is a wholesaler that takes small-lot orders for various industrial goods and materials from small businesses. It became time for the company to improve its order and inventory management system. This order and inventory management system supports handling orders, shipping, placing orders, inventory management and sales analysis operations. [Program and Table Relations] The reference and update relations of major programs and tables in the order and inventory management system are as shown in the table below. In the case of “Customer management” and “Product information management” in the online program, any request to add or update a supplier, buyer or product master data is registered in the “Master update registration” table. The actual updating is done by a “Master update application” batch program based on the request. Table 1 Reference and Update Relations of Major Programs and Tables Master update registration Data for placing orders Monthly sales records Table name Daily sales records Demand forecast Orders-received Analytical data Shipping order Inventory Suppliers Shipping Products Buyers Program name a. Orders-received management R RU CU RU b. Orders-placed processing R R CU R Online c. Shipping processing R R C d. Customer management C R R e. Product information management C R f. Sales analysis R R R g. Order slip faxing R R R h. Shipping log R C R U i. Demand forecasting R R CRU R R j. Orders-placed data creation R C R Batch k. Sales records daily tabulation R R R C l. Sales records monthly tabulation R C m. Analytical data creation R R C n. Master update application R CU CU CU Note C: Add, R: Reference, U: Update - 15 -