The Data Organization Yosemite Way Hayward, CA (510) The Data Warehouse Conceptual Data Model

Transcription

1 C V I T F E P A O TM The Data Organization 1251 Yosemite Way Hayward, CA (510) rschoenrank@computer.org The Data Warehouse Conceptual Data Model By Rainer Schoenrank Data Warehouse Consultant April 2013

2 Copyright Rainer Schoenrank. All rights reserved. No part of this document may be reproduced in whole or in part, in any form or by any means, electronic or manual, without express written consent of the copyright owner. The logo is a trademark of The Data Organization in the United States and/or in other countries. Biography Rainer Schoenrank is the senior data warehouse consultant for The Data Organization. He has degrees in physics from the University of Victoria and computer science from the University of Victoria and California State University Hayward. He has built data warehouses for clients such as Pacific Bell, Genentech, GE Leasing, SGI, PPFA, Brobeck, Clorox and Leapfrog. He can be reached at rschoenrank@computer.org. 4/26/2018 Copyright Rainer Schoenrank Page 2

3 TABLE OF CONTENTS 1. INTRODUCTION PURPOSE OF THE DOCUMENT SCOPE OF THE DOCUMENT ORGANIZATION OF THE DOCUMENT OVERVIEW BUSINESS MODEL DATA WAREHOUSE CONCEPTUAL MODEL PROCESS INTRODUCTION MARKETING TO REVENUE PROCESS DIAGRAM PROCESS STATES CONCEPTUAL MODEL OVERVIEW CONCEPTUAL MODEL DIAGRAM BUSINESS PROCESS MEASUREMENTS SALES MEASUREMENT BUY MEASUREMENT TIME MEASUREMENT OPERATIONAL ENTITIES CUSTOMER EMPLOYEE (AGENT) INVENTORY SUPPLIER (VENDOR) ORGANIZATIONAL ENTITIES POSITION PRODUCT ACTIVITY (TASK) DATE (CALENDAR) CONCEPTUAL MODEL VALIDATION APPLICATION MAPPING BUSINESS INTELLIGENCE MAPPING /26/2018 Copyright Rainer Schoenrank Page 3

4 1. INTRODUCTION The Conceptual Data Model document describes the data warehouse conceptual data model, its organizing principles and analysis. This document will specifically deal with the requirements surrounding the organization and completeness of the data warehouse. A conceptual data model consists of a data model diagram and metadata that describe the symbols and lines on the data model diagram. The data model diagram shows boxes and lines. The boxes represent the master data entities and the lines show the relationships between the master data entities. (Data Modeling Essentials, 3rd Edition, G. Simsion and G. Witt, Morgan Kaufman, San Francisco, 2005) 1.1 Purpose of the Document The Conceptual Data Model describes the data warehouse conceptual data model, its organizing principles and analysis. The goals of document are: To enable the conceptual model to be the framework for business intelligence To provide a framework for consistent business measurement To create a common framework for mapping the data definitions. To simplify the data stored in the data warehouse This document will specifically deal with the requirements surrounding the organization and completeness of the data warehouse. This document describes the results of the policy decisions that created the data model, the decomposition and organization of the business data. The document represents the end of the first phase of creating an enterprise data warehouse. The development phases are: Conceptual Data model this document Logical Enterprise data model Physical data model Implemented database 4/26/2018 Copyright Rainer Schoenrank Page 4

5 1.2 Scope of the Document The scope of the document is limited to the conceptual data model for the data warehouse required for business intelligence reporting. The level of detail is at the entity level and the relationships between the entities and the business process measurements. The resulting conceptual data model consists of boxes (entities) and arrows (relationships) with descriptions of the contents of the boxes. Detail below this level is given in the logical data model document and the physical database engineering document. 1.3 Organization of the Document INTRODUCTION specifies the purpose, scope and organization of this document. OVERVIEW describes the background of the conceptual data model and the organization of the data collected by the business processes. CONCEPTUAL MODEL PROCESS describes the business processes that the data warehouse supports. BUSINESS MEASUREMENTS describes the types of process measurements (facts) that are in the conceptual data model. OPERATIONAL ENTITIES describes the entities that are part of the day to day business operational processes. ORGANIZATIONAL ENTITIES describes the entities that are used by the business to organize the operational processes. CONCEPTUAL MODEL VALIDATION describes mappings required to ensure that the conceptual model is complete as an enterprise data model. 4/26/2018 Copyright Rainer Schoenrank Page 5

6 2. OVERVIEW The conceptual model for the data warehouse describes a model of the business. This model of the business yields insights for managing change. The model also gives the preconditions for the effective and efficient storage of the business data. 2.1 Business Model Introduction A conceptual data model shows how the business sees its information. A conceptual data model represents the semantics of an organization s data. The meaning of the data comes from the set of business processes that create and use the data. The views of these business processes are consolidated into a single conceptual schema that is the superset of all of those external views of the data by generalizing and aggregating the underlying data entities. A data model is provable in the mathematics of data science. Given the current predominance of relational database management servers, logical data models must conform to relational theory Business Processes If the data warehouse is to collect all of the business data, what are the processes that generate the data? The data model is based on a global view of the three fundamental operational processes of a business. In general, these processes are: 1. The sales process that brings money into the business. 2. The purchasing process that removes money from the business. 3. The time tracking process that measures the time spent creating products. 4/26/2018 Copyright Rainer Schoenrank Page 6

7 For each of these processes, the business measures the process and records the data. When describing a business process measurement, the questions that need to be answered are who, what, when, where, why and how. The answers to these questions identify the entities of the business process but each of the three processes may identify different entities Each measurement will have different states depending on where in the business process the measurement is taken. Describing the different states for each of the business processes: 1. Sales Order Process (Marketing to Sales to Revenue Process) the process that markets, sells, delivers and accepts payment for products (goods, services and/or information) received by customers. This measurement is the money received by the business (sales measurement). 2. Purchase Order Process this measures the money spent by the business. The process that selects, buys, receives and pays for the equipment and supplies needed to create the products that are offered for sale. This measurement is the money spent by the business (buy measurement). 3. Time Tracking Process this measures the time used to complete the tasks in the processes to create the product specification, realize the product in inventory, deliver the product to the customer, etc. Business intelligence (BI) reporting compares, contrasts and analyzes these process measurements to gain insights into process efficiencies. This requires consistent measurement of each process and that the same process properties are measured at each stage of a process. 4/26/2018 Copyright Rainer Schoenrank Page 7

8 2.1.3 Benefits The benefits of creating a conceptual data model (data architecture) are realized in business process improvements in three areas. In the business performance area the benefits are: Alignment of IT business case with business strategy Consistency and integrity of information Improved cross application business intelligence reporting In the area of OLTP application development, the benefits are: Improved technical adaptability and scalability Improved interoperability of OLTP applications Detailed models provide a common frame of reference across major business areas Improved ability to address critical enterprise-wide issues like security Easier upgrade and exchange of architecture platform components (plug and play) In the area of cost avoidance, the benefits are: Reduced risk because architectural issues have been identified earlier More reuse lowers software development and support costs Reduced rework lowers software maintenance costs 4/26/2018 Copyright Rainer Schoenrank Page 8

9 2.1.4 Risks There are risks associated with not having, creating and using data architecture, but data architecture is too strategically important to follow a sporadic development process. The business has to pay up-front for the right to exercise options in the future. In the past, the business has often settled for cheaper, less permanent solutions, rather than focusing on options that provide increased future maneuverability. Data architecture requires new technical expertise, understanding and viewpoints. It may be difficult to reach agreement on common, business-wide models and standards, which are necessary to ensure interoperability. Independent-minded business units may not wish to participate in collaborative efforts, particularly since long-term realignment of business functions and responsibilities could be a result. Data architecture requires commitment from the application development teams. Business process automation projects have often sacrificed planning and engineering rigor to show progress quickly. This approach has avoided architectural issues, sacrificed the repeatable development process and deemphasized as-built documentation completeness. Application development must keep its eyes on the future and its basic principles rather than nearterm objectives and achievements. Without the data architecture, the multiple OLTP application will probably never become interoperable or establish and adhere to open and flexible standards. Continuing negative consequences will impact application support's ability to provide flexible services and responses to the business, and respond to unknown and endemic systems integration problems and needs. 4/26/2018 Copyright Rainer Schoenrank Page 9

10 2.2 Data Warehouse Purpose The objective of the data warehouse is to consolidate all of the measurements of the business processes of a company so that the data is of high quality and consistent. In this way, reports of the company s status from different points of view can be compared without having to resolve inconsistencies in the data Data Warehouse Goals The goals of the data model are: Completeness the logical data model should include all the Visa relevant enterprise data. The model should identify all the synonyms that the business uses for the same data concept and the homonyms that are used for different data concepts. Non-Redundancy recording the same data more than once requires extra processing to keep the various copies in step and leads to consistency problems if the copies get out of step. Conceptually, the logical data model is a minimum cover set of the business data. Data Integrity the rules in the data model should accurately reflect the rules that apply to the business data. The resulting data model is a powerful tool in enforcing correct practice and maintaining data quality. Data Reusability This requirement is often expressed in terms of its solution: as far as possible, data should be organized independently of any specific application. Stability and Flexibility Limit data model changes because of changes in data sources, processing and company policy (data independence). DBMS Query Optimization every DBMS uses an optimizer to restructure complex SQL queries for faster execution. This optimizer assumes that the database is a relational algebra and that the relational calculus applies. If this assumption is not true, then the results returned by the optimizer will be invalid. 4/26/2018 Copyright Rainer Schoenrank Page 10

11 2.2.3 Data Model Design Principles The principles of the data analysis for a conceptual data model design are: 1. Non overlapping business process measurements (i.e., buy, sell, time) 2. Non overlapping master data entities 3. Separate the data from its organizations (for example, customer from market segmentation, line item from invoice, etc.) Assumptions The following assumptions were made during the creation of the data model: All of the business data can be stored in a data warehouse All of the application business objects can be created by projecting (sub setting) and joining (composition) the logical/conceptual data model entities The data model does not include data required for database auditing, database authorization, application security, application configuration, application processing, workflow processing, batch processing control, messaging control, etc. 4/26/2018 Copyright Rainer Schoenrank Page 11

12 3. CONCEPTUAL MODEL PROCESS 3.1 Introduction When discussing process measurements with business users, it is common for them to describe process states as entities in business applications. Business users are quite used to filling out a new form when the sales process enters a new state. Business users expect these forms to become entities in the database. These forms ( sales opportunity, price inquiry, proposal, quote, order, delivery, invoice, payment, return, and refund ) are all measured states of the sales order process. A better solution is to have an entity for the sales order process measurements that is related the sales process states. Then, the valid values of the sales process state are sales opportunity, price inquiry, proposal, quote, etc. 4/26/2018 Copyright Rainer Schoenrank Page 12

13 3.2 Marketing to Revenue Process Diagram The Sales Order Process for a service (for example, telephony) is shown in Figure 1. The circles are the sales process states recognized by the business. The names of the online transaction processing (OLTP) applications used to implement the states are in red. The OLTP applications store the current state of the process. Reject START Market Services Sell Services Offer to sell Service Sale Price <> List Price Deal And Contract Mgmt MarketFirst SalesForce.com Sale Price = List Price Artemis Accept Order status = pending Place Order For Service BRM Cancel Cancel END Order status = inactive Provision Order Order status = active Bill Invoice Receive Payment payment Provisioning BRM Monthly Usage EBS R12 Measure Service Usage Mediation Figure 1: Sales Order Process 4/26/2018 Copyright Rainer Schoenrank Page 13

14 3.3 Process States The problem of consistent measurement occurs because every task in the Sales Order Process uses a separate application as shown in Table 1. Sales to Revenue Activity Data Creation Application Business Process State Data Warehouse Element Market Services MarketFirst lead account Sell Services SFDC opportunity sales order Offer to Sell SFDC booking sales order Place Order BRM and Artemis order (pending) sales order Provision Order Provisioning order (active) sales order Measure premium Usage Mediation usage sales order Bill BRM billing sales order Receive Payment EBS R12 revenue sales order Table 1: Sales to Revenue Process Tasks Each application considers its output business object as its data and the output business object does not necessarily contain all of the data elements of a consistent sales process measurement. The data creation applications do not keep a history of their business process measurements and they do not keep a history of the state transitions of the business process measurement. 4/26/2018 Copyright Rainer Schoenrank Page 14

15 4. CONCEPTUAL MODEL OVERVIEW 4.1 Conceptual Model Diagram To create the conceptual data model, the universe of business data (very top level) needs to be divided into non overlapping entities that are the supertypes of the nouns identified in the business processes. The key requirements of this decomposition are that all the business data fit into one and only one of the master data entities that all the business data views and subtypes are included, for example, Client, Merchant, etc. are all types of Customer that the organization of the data entity is separated from its descriptive data, for example, the company org chart exists even though there are no positions or company business units The supertype entities are business process measurements (sales, purchases, process events) and master data entities. The business process measurements are the data recorded while executing business processes. The master data entities are the things that each business process measurement is related to: External entities o Employee that completed the activity that resulted in the business process measurement o Customer that bought the goods, service or information o The Inventory item that fulfilled the customer s sales order o Supplier that created the inventory item Enterprise internal entities o Position (business unit) that is credited with the sales o Product is the list of goods, services, or information that the Customer may order o Activity completed in the business process o Date of the business process measurement taken 4/26/2018 Copyright Rainer Schoenrank Page 15

16 The data model in Figure 2 shows the three business process measurements (in yellow), all the business master data and the master area organizations that are required for business intelligence reporting. Each business process measurement is related to each entity. The relationships between entities are not shown. Customer Position Sales Measurement Employee Product Buy Measurement Inventory Activity Time Measurement Supplier Date Figure 2: Conceptual Data Model 4/26/2018 Copyright Rainer Schoenrank Page 16

17 The data model is organized into three columns: The operational business data are in the left column The business process measurements (facts) are in the center column The organizational business data are in the right column. Each line represents a relationship between the entities. One arrowhead represents one item and two arrowheads represent many items. A restriction of the data model diagram is that redundant relationships have been removed. A redundant relationship is a relationship that can be deduced from two or more other relationships. When redundant relationships have been removed from the data model diagram, there are no relationship loops in the data model diagram. If this conceptual model is agreed to, then data capture applications, data processing applications, data marts and subject areas are all subsets of the conceptual model and can be expressed as views on the data model. 4/26/2018 Copyright Rainer Schoenrank Page 17

18 5. BUSINESS PROCESS MEASUREMENTS The business measurements describe the facts that the company records as it creates, sells and delivers its products and services. These facts are the company s view of its transactions with its customers, suppliers, and employees. 5.1 Sales Measurement Definition The Sales Measurement items are the measurements of money and quantity that the business makes during the sales order process. The sales order process is a sequence of events (documents, states, etc.) that records the quantity and price of a product, from the initial sales opportunity until the product is paid for and available to the customer. The business chooses the points in the sales order process at which the measurements are made Aliases and Subtypes The Sales Measurement is also known by other names (synonyms that use all the attributes of sales measurement) and subtypes (subset of the attributes of sales measurement when all the data are not known) that describe the state of the Sales Measurement during the different stages of the sales order process. For example: Billing Booking Invoice One Time Service Order Payment Revenue Sales Measurement Usage Quote 4/26/2018 Copyright Rainer Schoenrank Page 18

19 5.1.3 Attributes The attributes of Sales Measurement are the data values that describe an item in the entity: Sales Date Description Sold quantity Sold price Cost price Shipping Address Source document the accounting document involved (e.g., Invoice Number) Reference document the customer s document involved (e.g., Customer s Purchase Order) Relationships A single Sales Measurement item is related to each subject area: Customer who purchased the Service Employee who sold the Service Inventory which inventory item was used Supplier who provided the product Position which department made the sale Product which product was purchased Activity how the task was completed for the sales measurement 4/26/2018 Copyright Rainer Schoenrank Page 19

20 5.2 Buy Measurement Definition The Buy Measurement items are process measurements that the business makes during the purchase process. The purchase process is a sequence of events (documents, states, etc.) that records the quantity and price of an inventory item, from the initial purchase request until the inventory item is paid for and used by the business. The business chooses the locations in the purchasing process at which the measurements are made Aliases and Subtypes The Buy Measurement is also known by other names (synonyms that use all the attributes of buy measurement and subtypes that use a subset of the attributes of buy measurement) that describe the state of the buy measurement item during the purchase process. For example: Buy Transaction Purchase Order Purchase Requisition. Received Inventory Attributes The attributes of the Buy Measurement are the data values that describe a line item in the entity: Purchase Date Description Purchase quantity Purchase price Shipping address Source document the business accounting document involved Reference document the supplier s document involved. 4/26/2018 Copyright Rainer Schoenrank Page 20

21 5.2.4 Relationships A single Buy Measurement item is related to each entity: Customer who purchased the Service Employee who ordered the Service Inventory which inventory item is the Service Supplier who provided the Service Position which department authorized the purchase Product which product was purchased Activity what task was completed for the purchase order. 4/26/2018 Copyright Rainer Schoenrank Page 21

22 5.3 Time Measurement Definition The Time Measurements are measurements of the time an employee spends doing an activity during the course of buying, creating and selling products. A set of time measurement events is a time card that records the tasks (state changes) as the employee navigates the business processes Aliases and Subtypes The time measurement entity is also known by other names (synonyms that use all the attributes of time measurement and subtypes that use a subset of the attributes of time measurement) that describe the state of the process events during the different stages of the business process. For example: Employee time card Process time card Provisioning Order Work Order Attributes The attributes of time measurement are the data values that describe an event in the entity: Event Date Start Time End Time Time interval Description Used quantity Source document the business accounting document involved Reference document the customer s document involved. 4/26/2018 Copyright Rainer Schoenrank Page 22

23 5.3.4 Relationships A single Time Measurement item is related to each entity: Customer who was the work done for Employee who did the work Inventory which inventory item was used Supplier who was the supplier involved Position which department authorized the work Product which product was created Activity what task was completed for the event 4/26/2018 Copyright Rainer Schoenrank Page 23

24 6. OPERATIONAL ENTITIES The operational entities the entities that the company uses in its day to day operations that create, market, sell and deliver its products and services. These entities are the company s view of the external entities customers, suppliers, labor, and equipment. 6.1 Customer Definition The Customer entity identifies and describes of all those entity occurrences that pay for or are expected to pay for our products. Customers are our view of the entities that send us money for goods, services, or information. Or they sent us money in the past. Or we expect them to send money in the future. These Customers can be individuals, other businesses, governments, the business itself, its subsidiaries, etc., In fact, anyone that pays for our products. If you don t expect to get money from them, they are not customers. In healthcare, the insurance companies and the government are the customers. To facilitate processing and record keeping, there are special Customers that represent classes of entities. Examples of these occurrences are: The default Customer the Customer used when the customer identifier is not provided to the data warehouse by the OLTP application The unknown Customer the Customer used when the customer identifier is not known by the person entering the data The cash Customer the Customer used when the customer contact person sends cash but refuses to identify himself or the Customer. The self-customer the Customer used when our inventory is used by our business. 4/26/2018 Copyright Rainer Schoenrank Page 24

25 6.1.2 Aliases and Subtypes The Sales Measurement is also known by other names (synonyms that use all the attributes of sales measurement) and subtypes (subset of the attributes of sales measurement when all the data are not known) that describe the state of the Sales Measurement during the different stages of the sales order process. For example: Invoice Billing Booking One Time Service Order Payment Quote Revenue Sales Measurement Usage 4/26/2018 Copyright Rainer Schoenrank Page 25

26 6.1.3 Attributes The attributes of Customer are the data values that describe an item in the Customer entity: Customer Address the postal address for the Customer Customer Authorization the data used to access the Customer Customer Balance History the free minutes and storage quota for the Customer Customer Bill Info the billing cycle and payment method for the Customer Customer Contact the people who can be contacted about the state of the Customer Customer Contact the Customer contact s addresses Customer Contact Phone the Customer contact s phone numbers Customer Contract History the history of the customer s contracts/subscriptions Customer Identification the numbers that identify the Customer, i.e., IRS number, bank account number, credit card number, export permit number, etc. Customer Location History the geographic location of the Customer Customer Marketing Profile History the demographic properties of the Customer Customer Status History the history of the Customer s status in the sales process Customer Relationship the relationships that exist between different Customers Relationships A single Customer item can be related to many business measurement items in: Sales Measurement Time Measurement Buy Measurement. 4/26/2018 Copyright Rainer Schoenrank Page 26

27 6.2 Employee (Agent) Definition Employee is a business object that contains the identification and description of all the people who provide labor during the business processes. They can be full time employees, part time employees, contractors, temporaries, etc. To facilitate processing and record keeping, there are special Employees that represent classes of employees. Examples of these classes are: The default employee the employee used when the employee identifier is not provided to the data warehouse by the OLTP application The unknown employee the employee used when the employee identifier is not known by the person entering the data Aliases and Subtypes The employee is also known by other names (synonyms) that describe the state of the employee during the sales process. For example: Agent Associate Customer Account Rep Provider Sales Person Worker. 4/26/2018 Copyright Rainer Schoenrank Page 27

28 6.2.3 Attributes The attributes of employee are the data values that describe a person in the employee entity: Employee Name Employee Address Employee Employee Identification Employee Phone Employee Relationship Employee Status History Relationships A single employee can be related to many business measurement items in: Sales Measurement Time Measurement Buy Measurement. 4/26/2018 Copyright Rainer Schoenrank Page 28

29 6.3 Inventory Definition Inventory is a business object that contains the identification and description of all the goods and information purchased, used, or created by the business during the product creation process. Inventory items are things that we have spent money to acquire and may be offered for sale during the lifetime of our company. In healthcare, inventory consists of the people that receive the services. To facilitate processing and record keeping, there are special Inventory identifiers that represent classes of entities. Examples of these classes are: The default Inventory item the identifier used when the Inventory item is not provided to the data warehouse by the OLTP application The unknown Inventory item the identifier used when the Inventory item is not known by the person entering the data Aliases and Subtypes The Inventory entity is also known by other names (synonyms) that describe the Inventory items as seen by different business units. For example: Asset Inventory Provisioning Target Network Equipment Attributes The attributes of Inventory are the data values that describe an Inventory item in the entity: Inventory Name Inventory Identification Inventory Status History. 4/26/2018 Copyright Rainer Schoenrank Page 29

30 6.3.4 Relationships A single Inventory item can be related to many business measurement items in: Sales Measurement Time Measurement Buy Measurement. A single Inventory item can be related to many items in: Inventory organization. 4/26/2018 Copyright Rainer Schoenrank Page 30

31 6.4 Supplier (Vendor) Definition The Supplier is a business object that contains the identification and description of all the suppliers that interact with us at the start of the product creation process. Suppliers are the entities that we send money to for goods, services or information. Or we sent them money in the past. Or we expect to send them money in the future. These suppliers can be individuals, other businesses, governments, the business itself, subsidiaries, etc. In banking, the suppliers are the deposit accounts. To facilitate processing and record keeping, there are special Suppliers that represent classes of entities. Examples of these classes are: The default supplier the supplier used when the supplier identifier is not provided to the data warehouse by the OLTP application The unknown supplier the supplier used when the supplier identifier is not known by the person entering the data The cash supplier the supplier used when the supplier contact person accepts cash but refuses to identify himself or the supplier The self-supplier the supplier used when product are provided by our company to us, for example during a charge back process Aliases and Subtypes The supplier entity is also known by other names (synonyms) that describe the state of the supplier during the purchasing process. For example: Alternate Source. Prospective Supplier Vendor. 4/26/2018 Copyright Rainer Schoenrank Page 31

32 6.4.3 Attributes The attributes of supplier are the data values that describe a supplier in the supplier entity: Supplier Name Supplier Identification Supplier Address Supplier Contact Supplier Contact Supplier Contact Phone Supplier Contract History Supplier Status History Supplier Performance History Supplier Profile Supplier Relationship the relationships that exist between different suppliers Relationships A single supplier can be related to many business measurement items in: Sales Measurement Time Measurement Buy Measurement. 4/26/2018 Copyright Rainer Schoenrank Page 32

33 7. ORGANIZATIONAL ENTITIES The organizational entities are the entities that the company creates and organizes to facilitate the operational processes. These areas are the business organization, the products or services, the processing tasks and the financial calendar. 7.1 Position Definition Position is a business object that contains the identification and description of all the functional divisions of the company. The fundamental or indivisible level of a business unit is position within the company (e.g., Chief Operating Officer, Knowledge Manager, etc.). To facilitate processing and record keeping, there are special position that represent classes of entities. Examples of these classes are: The default Position the Position used when the Position identifier is not provided to the data warehouse by the OLTP application The unknown Position the Position used when the Position identifier is not known by the person entering the data Aliases and Subtypes The Position entity is also known by other names (synonyms) that describe the organization of the business. The synonyms usually describe the Position at a different level of abstraction. For example: Business Unit Division Department. 4/26/2018 Copyright Rainer Schoenrank Page 33

34 7.1.3 Attributes The attributes of business unit are the data values that describe a business unit in the entity: Business Unit Name Business Unit Identification Business Unit Status History. Business Unit Address Business Relationship Relationships A single Position can be related to many business measurement items in: Sales Measurement Time Measurement Buy Measurement. 4/26/2018 Copyright Rainer Schoenrank Page 34

35 7.2 Product Definition Product is a business object that contains the identification, description, specification and prices of all the products that we have sold in the past, are currently selling, or plan to sell in the future. There is always a price for a product even if the price is zero. These products can be goods, services, or information. The products include shipping services, handling services, and third party services such as taxes that are resold for government suppliers. To facilitate processing and record keeping, there are special products that represent classes of Product. Examples of these classes are: The default product the product identifier used when a product identifier is not provided to the data warehouse by the OLTP application The unknown product the product identifier used when the product identifier is not known by the person entering the data Aliases and Subtypes The Product entity is also known by other names (synonyms) that describe the products for various business units and processes within the company. For example: Bundle Deal Item Offer Package Promotion Shipping Tax. 4/26/2018 Copyright Rainer Schoenrank Page 35

36 7.2.3 Attributes The attributes of Product are the data values that describe an item in the entity: Product Name Product Identification such as SKU, part number, etc. Product Owner Product List Price Product Specification Product Status History Product Bill of Materials the relationship between products Relationships A single product can be related to many business measurement items in: Sales Measurement Time Measurement Buy Measurement. 4/26/2018 Copyright Rainer Schoenrank Page 36

37 7.3 Activity (Task) Definition Activity is a business object that contains the identification and description of all the processes (activities or tasks) that are have been used by the business in the past, are currently used by the business or are planned to be used by the business. These processes can be processes, functions, tasks, activities, etc. An example of business tasks is the documentation provided for the ISO 9000 certification. To facilitate processing and record keeping, there are special tasks that represent classes of activities. Examples of these classes are: The default activity the activity used when the activity identifier is not provided to the data warehouse by the OLTP application The unknown activity the activity used when the activity identifier is not known by the person entering the data Aliases and Subtypes The Activity entity is also known by other names (synonyms) that describe the activity for various business units within the company. For example: Function Sales Process Task Task Transaction Status. 4/26/2018 Copyright Rainer Schoenrank Page 37

38 7.3.3 Attributes The attributes of activity are the data values that describe an item in the entity: Activity Name Activity Identification Activity Relationship Activity Status History Relationships A single Activity can be related to many business measurement items in: Sales Measurement Time Measurement Buy Measurement. A single Activity can be related to many items in: Process Organization. 4/26/2018 Copyright Rainer Schoenrank Page 38

39 7.4 Date (Calendar) Definition The Date is a business object that contains the identification and description of all the days on which the business plans to perform product. These days are the list of all the dates in the calendar Aliases and Subtypes The Date entity is also known by other names (synonyms) that describe the portions of the calendar during the business process. For example: Calendar Date Fiscal Quarter Quarter Attributes The attributes of Date are the data values that describe the business cycle in the calendar entity: Date Day Week Month Quarter Year. 4/26/2018 Copyright Rainer Schoenrank Page 39

40 7.4.4 Relationships A single date can be related to many business measurement items in: Sales Measurement Time Measurement Buy Measurement. 4/26/2018 Copyright Rainer Schoenrank Page 40

41 8. CONCEPTUAL MODEL VALIDATION This chapter is used to validate the conceptual data model against the terms and definitions used in the business intelligence reporting process. 8.1 Application Mapping To check the completeness of the conceptual data model, the applications that automate the business record keeping should be mapped onto the model. An example of such a mapping is shown in Table 2 below. Application Conceptual Data Model Sales Measurement Buy Measurement Time Measurement Customer Accounts Receivable X X X X X X Accounts Payable X X X X X HR X X X X X CRM X X X X X X PDM X X X X X Chart of Accounts X X Etc. Employee Inventory Supplier Position Product Activity Date Table 2: Application to Conceptual Data Model Mapping The columns in the table are the master data entities from the conceptual data model. The rows of the table are the applications that the business uses to create and capture business process measurements. The large X s indicate which master data entities are used by the application. 4/26/2018 Copyright Rainer Schoenrank Page 41

42 For example: Accounts Payable consists of Suppliers, Employees (purchasing agents). Business Units and buy business process measurements. Accounts Receivable consists of Customers, Employees (salesmen), Products, Business Units and sales business process measurements. CRM consists of Customers, sales process measurements and status changes to Customers. Etc. 8.2 Business Intelligence Mapping The bus matrix shows how the business, application and data architecture layers of the enterprise architecture model are related. On the left side of the matrix, the details of the business architecture layer are labeled as rows in the matrix. The components of the business architecture are shown as individual business processes. These business processes are from the APQC Process Classification Framework, available at The details of the data architecture are labeled as columns in the matrix. The data architecture components are the entities and business measurements described in the conceptual data model. The individual OLTP applications of the application architecture reside in one or more cells at the intersections of the rows (processes) and columns (data). Table 3 shows a matrix for a generic business, a generic data model and general OLTP applications. 4/26/2018 Copyright Rainer Schoenrank Page 42

43 Support Processes Operating Processes Management Processes Data Warehouse Conceptual Model Operational Data Master Data Dimensions Organizational Data Business Measurements Company Organization ( APQC's Process Classification Framework) C u s t o m e r E m p l o y e e I n v e n t o r y S u p p l i e r P o s i t i o n P r o d u c t A c t i v i t y D a t e S a l e s T i m e B u y Develop Vision and Strategy Manage Knowledge, Improvements and Change Manage External Relationships Develop and Manage Products and Services Market and Sell Products and Services Deliver Products and Services Manage Customer Service Develop and Manage Human Capital Manage Information Technology Marketing Analytics Sales Force Automation Sales Force Automation Receiving Sales Force Automation Capital Mngmt Supplier Mngmt Marketing Analytics Sales Force Automation Marketing Analytics Product Design Mngmt Sales Force Automation Product Design Mngmt Sales Force Automation Fulfillment Fulfillment Fulfillment Fulfillment Fulfillment Fulfillment CRM CRM CRM Product Design Mngmt HRIS HRIS Time Capture Fixed Assets Manage Financial Resources A / R Payroll A / P G / L G / L Acquire and Manage Property Manage Environmental Health and Safety (EHS) Real Estate Business Intelligence Reporting (OLAP) G / L A / R Payroll Purchasing G / L A / P Table 3: Generic Business Matrix 4/26/2018 Copyright Rainer Schoenrank Page 43