sas detail data store for banking 2 - dartmouth...

SAS® Detail Data Store for Banking 2.3 Implementation and Administration Guide

SAS® Documentation

1

The correct bibliographic citation for this manual is as follows: SAS Institute Inc. 2006. SAS® Detail Data Store for Banking 2.3: Implementation and Administration Guide. Cary, NC: SAS Institute Inc. SAS® Detail Data Store for Banking 2.3: Implementation and Administration Guide Copyright © 2006, SAS Institute Inc., Cary, NC, USA All rights reserved. Produced in the United States of America. For a Web download or e-book: Your use of this publication shall be governed by the terms established by the vendor at the time you acquire this publication. U.S. Government Restricted Rights Notice: Use, duplication, or disclosure of this software and related documentation by the U.S. government is subject to the Agreement with SAS Institute and the restrictions set forth in FAR 52.227-19, Commercial Computer Software-Restricted Rights (June 1987). SAS Institute Inc., SAS Campus Drive, Cary, North Carolina 27513. 1st printing, June 2006 SAS Publishing provides a complete selection of books and electronic products to help customers use SAS software to its fullest potential. For more information about our e-books, e-learning products, CDs, and hard-copy books, visit the SAS Publishing Web site at support.sas.com/pubs or call 1-800-727-3228. SAS® and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. ® indicates USA registration. Other brand and product names are registered trademarks or trademarks of their respective companies.

Contents

Chapter 1 Introduction to the SAS Detail Data Store for Banking 1 Introduction to This Guide 1 What’s New in the SAS Detail Data Store for Banking 2.3 2 What is the SAS Detail Data Store for Banking? 3 Industry Versions of the Banking DDS 4 Customizing the Banking DDS 6

Chapter 2 Physical Design of the SAS Detail Data Store for Banking 7 Overview 7 Populating the Retained Key 7 Tracking Historical Data over Time/Point in Time Data 8 Using Effective and Expiration Dates 8 Using Processed Date/Time 9 Using Natural/Business Keys 9

Chapter 3 Organization of Tables in the SAS Detail Data Store for Banking 11 Overview 11 More Information 14

Chapter 4 Defining Role-Based Users and Groups for the SAS Detail Data Store for Banking 15 Overview 15 Planning User Groups and Roles 15 Sample User Groups and Roles 16

Chapter 5 Creating and Registering the SAS Detail Data Store for Banking Tables 19 Overview 19 Prerequisites 19 Installing the Metadata Import-Export Tool 20 Verification of Installation 20 Creating the Banking DDS 20 Registering the Metadata 21 Editing the Library Path 26 Creating a Subset Version of the Banking DDS Physical Model 28 Verifying the Metadata Registration 29

Chapter 6 Loading the SAS Detail Data Store for Banking 31 Identifying Data Sources 31 Guidelines for Loading Data into the Banking DDS 32 Understanding Initial and Periodic Data Loads 35 Archiving Data 35

iv Contents Chapter Error! No text of specified style in document.

Chapter 7 Customizing the SAS Detail Data Store for Banking 37 Overview 37 Modifying the Banking DDS 38 Using Caution 38 Avoiding Trouble 38 Things to Keep in Mind 39

Chapter 8 Support Resources 41

Appendix 1 Table Loading Sequence 43

Appendix 2 SAS Detail Data Store for Banking Table Types 59 Transactional Tables 59 Master Tables 59 Reference Tables 60 Intersection Tables 60 Association Tables 60

Appendix 3 Standard Data Types and Naming Conventions 61

Appendix 4 Data Model Notation 63 Reading the Relationship Notation 63 Understanding a One-to-One Relationship 64 Understanding a One-to-Many Relationship 64

Appendix 5 Table and Column Changes 67 Overview 67 New Tables 67 New Columns 68 Other Changes 74

Appendix 6 Banking DDS Deployment FAQ 77 Other Issues 77

Appendix 7 Deploying the Banking DDS on Oracle 79 Overview 79 Creating the Banking DDS Tables in Oracle 80 Registering Metadata 81 Using the Oracle Bulk Loader 81

Glossary 83

1

1 Introduction to the SAS Detail Data Store for Banking

Introduction to This Guide ............................................................................................................................... 1 Prerequisite Knowledge ............................................................................................................................. 1

What’s New in the SAS Detail Data Store for Banking 2.3 ............................................................................ 2 Data Model Coverage................................................................................................................................. 2 ETL Coverage............................................................................................................................................. 2

What is the SAS Detail Data Store for Banking?............................................................................................ 3 Industry Versions of the Banking DDS............................................................................................................ 4 Customizing the Banking DDS ........................................................................................................................ 6

Introduction to This Guide

This guide provides information to help the on-site SAS support personnel and customer system administrator install, configure, and administer the SAS Detail Data Store for Banking. The guide contains:

a high-level introduction to the banking detail data store (DDS) a description of the physical design and table structure of the banking DDS information about defining metadata user roles and their role-based setup information about deploying and loading the banking DDS information about maintaining the banking DDS information about using the banking DDS with various SAS solutions

Prerequisite Knowledge

Users of this guide should be familiar with general database technology, data warehousing, and data modeling concepts. Users should have administrative and programming experience with Base SAS software and SAS Data Integration Studio (formerly named SAS ETL Studio).

Note: To implement the SAS Detail Data Store for Banking, SAS 9.1.3 or later is required.

C H A P T E R

2 What’s New in the SAS Detail Data Store for Banking 2.3 Chapter 1

What’s New in the SAS Detail Data Store for Banking 2.3

The SAS Detail Data Store for Banking 2.3 contains several new features and enhancements. Release 2.3 expands the data model coverage by providing additional tables and fields.

See Appendix 5, “Table and Column Changes,” for specific changes made to the tables and columns within the banking DDS.

Data Model Coverage The enhanced data model has been expanded to include data elements for the following SAS solution:

SAS Credit Risk Management for Banking 4.2

The SAS Detail Data Store for Banking 2.3 continues to include coverage for data elements used by the following SAS solutions:

SAS Anti-Money Laundering SAS OpRisk VaR SAS Credit Scoring for Banking SAS Campaign Management for Banking SAS Cross-Sell and Up-Sell for Banking SAS Customer Segmentation for Banking SAS Customer Retention for Banking

ETL Coverage The ETL coverage for the data model enhancements in this version of the banking DDS varies. Contact your on-site SAS support personnel for more information.

Introduction to the SAS Detail Data Store for Banking What is the SAS Detail Data Store for Banking? 3

What is the SAS Detail Data Store for Banking? The banking DDS is a data store that serves as the “single version of the truth” for the SAS banking solutions. As such, it contains the atomic-level data and historical information that is needed to populate the solution data marts. Figure 1.1 illustrates the high-level role of the SAS Detail Data Store for Banking within the Integrated Solutions Data Architecture.

Figure 1.1 Integrated Solutions Data Architecture

Implementing the banking DDS at a customer site provides several benefits:

The banking DDS provides a single data target for loading data. For example, a customer first implements SAS Credit Risk Management for Banking 4.2 and during the implementation, the customer populates the Financial_Account_Application table. After the SAS Credit Risk Management for Banking 4.2 implementation, the customer implements SAS Credit Scoring for Banking 3.2. Because the Financial_Account_Application table has been populated with cleansed data, the customer can use this same table when loading the SAS Credit Scoring for Banking data mart. Moreover, because the definition of the banking DDS table is known, the extract, transform, and load (ETL) process from the banking DDS to the solution data marts will be pre-built.

Solution Data MartsTransformations

Enterprise Operational

Systems

Solutions

(not all depicted)

SAS Campaign Management for Banking

SAS Credit Scoring for Banking

SAS Detail Data Store

for Banking

SAS Credit RiskManagement for

Banking

4 Industry Versions of the Banking DDS Chapter 1

SAS solutions can more easily share system data with each other. For example, the definition of a customer table is the same for SAS Marketing Automation for Banking as it is for SAS Credit Risk Management for Banking. Therefore, populating a single definition of a customer table ensures that both of these solutions have a single version of the truth.

Data that is created from SAS solutions can be stored in a central location and shared with other solutions. For example, the credit scores from SAS Credit Scoring for Banking 3.2 are written back to the banking DDS and shared with SAS Credit Risk Management for Banking 4.2.

Industry Versions of the Banking DDS The banking DDS is part of a larger group of industry data models. Although it would be convenient to have a single data model that covers all industries, in reality, different industries have different data needs. However, as shown in Figure 1.2, there is much commonality in data across industries. For example, customer, supplier, product, and segment tables share similar data attributes across industries.

Figure 1.2 Common Tables Across Industries

Data more likely to differ considerably across industries is the customer-facing or front-office data. For example, in banking, there are accounts; in retail, there are sales orders; and in insurance, there are premiums and claims. Because of this difference in data, the industry versions of the banking DDS contain tables that are part of the base, cross-industry data model, and contain tables that are part of the industry-specific data model.

Introduction to the SAS Detail Data Store for Banking Industry Versions of the Banking DDS 5

To further illustrate the concept of sharing data, Figure 1.3 shows a simplified, table-level view of a small section of the banking data model. One set of common tables is in yellow (or light gray) and one set is in dark gray. The base data model (yellow set) was extended by adding some banking-specific tables (dark gray set). This same concept applies to other industry data models, such as insurance, telecommunications, and retail. Having common data allows data models to be easily integrated across industries and functional areas as needed, which is important because companies often operate in multiple industries.

Figure 1.3 Sample of a Base Data Model with Industry-Specific Tables

INTERNAL_ORG

EMPLOYEE

CUSTOMER

EXTERNAL_ORG

SUPPLIER

INTERNAL_ORG_ASSOC

INTERNAL_ORG_ASSOC_TYPE

FINANCIAL_ACCOUNT

INVESTMENT_ACCOUNT

SUPPLIER

6 Customizing the Banking DDS Chapter 1

Customizing the Banking DDS No predesigned data model will meet all of an organization’s needs. Customizations need to be applied to the banking DDS in almost every implementation. For example, Figure 1.4 shows how the Competitors table was added to customize the banking DDS. Chapter 8, “Customizing the SAS Detail Data Store for Banking,” provides more information about customizing the banking DDS.

Figure 1.4 Customization of the Banking DDS

CUSTOMER

EXTERNAL_ORG

SUPPLIER

INTERNAL_ORG

INTERNAL_ORG_ASSOC

INTERNAL_ORG_ASSOC_TYPE

COMPETITORS

2 Physical Design of the SAS Detail Data Store for Banking

Overview............................................................................................................................................................. 7 Populating the Retained Key ............................................................................................................................ 7 Tracking Historical Data over Time/Point in Time Data .............................................................................. 8 Using Effective and Expiration Dates.............................................................................................................. 8 Using Processed Date/Time ............................................................................................................................. 9 Using Natural/Business Keys .......................................................................................................................... 9

Overview The banking DDS is designed as an integration and storage layer for operational (or source) systems. As such, the banking DDS is a lightly denormalized, relational data model that is flexible for storage. A key difference between a source system and the banking DDS is that the banking DDS captures current and historical data. Capturing historical data includes temporal data history (event data that occurs at a particular date/time, such as an account inquiry) and non-temporal data history (non-event data, such as a customer account or a financial account). Many of the banking DDS design decisions are based on the need for this historical data.

Populating the Retained Key You should populate the retained key (_RK) field, which is part of the primary key, with a retained surrogate (generated) key. This numeric key does not change for the different versions of the record. For example, in the INTERNAL_ORG table that is shown in Figure 2.1, the ORGANIZATION_NM column changes from Marketing to World Wide Marketing, but the retained key (shown in the first column) stays as 100. The only change in the old record is in the VALID_TO_DTTM column, which now correctly shows the changed date.

Figure 2.1 Example of Using a Retained Key

Old record

INTERNAL_ORG_RK VALID_FROM_DTTM VALID_TO_DTTM ORGANIZATION_NM 100 01-JAN-1999 12:00:00 01-JAN-5999 00:00:00 Marketing

Old record updated, and new record populated with retained key

INTERNAL_ORG_RK VALID_FROM_DTTM VALID_TO_DTTM ORGANIZATION_NM 100 01-JAN-1999 12:00:00 31-DEC-2000 23:59:59 Marketing 100 01-JAN-2001 00:00:00 01-JAN-5999 00:00:00 World Wide Marketing

C H A P T E R

8 Using Effective and Expiration Dates Chapter 2

SAS Data Integration Studio has a Slowly Changing Dimension transformation, SCD Type2 Loader, which can be used for generating a retained key when the value of an attribute changes in a record.

Tracking Historical Data over Time/Point in Time Data In Figure 2.1, the VALID_FROM_DTTM and VALID_TO_DTTM values are used with the _RK value to track historical data over time. These values define the time period during which the contents of the row are valid. You should set the VALID_TO_DTTM value to a date far into the future for ease of joins. If the source system does not track historical data for records, the VALID_FROM_DTTM and VALID_TO_DTTM values would correspond to the date and time that the DDS was loaded. However, if the source system does track historical data, for example, multiple changes of a row between load times of the DDS, there could be more than one row for the same retained key for a given load of the DDS. The design decision about how the date and time values are managed is related to the deployment of the source system. The date and time values can be tied to business system dates if they are provided by the business system, and if they do not conflict with their primary purpose in tracking the different versions of the system. VALID_FROM values can be created from the following:

banking DDS load date and time ETL date and time business system record timestamps

The primary purpose of the VALID_FROM and VALID_TO values is tracking versions, which is the only use of these values that is guaranteed. If the dates are used for another purpose (such as data extract date or business system entry date), then it must not compromise the primary purpose.

Using Effective and Expiration Dates Some types of data have effective and expiration dates that indicate when a business contract or policy is in effect. These date values are different from the date values that are used to track versions. For example, a physical asset’s value remains effective for a certain period of time - the period for which the bank has estimated this value. This estimation changes for future effective and expiration dates for the new versions of the physical asset’s value rows. In Figure 2.2, a bank evaluates the physical asset value of a property on 01-MAR-2003 that takes effect 01-APR-2003 (as seen in the EFFECTIVE_FROM date, which is the business date). On April 1, 2004, the bank re-evaluates the physical asset value and increases the value, which now supersedes the original value. In Figure 2.2, there are two distinct and valid coverage periods, and a changing business effective period.

Physical Design of the SAS Detail Data Store for Banking Using Natural/Business Keys 9

Figure 2.2 Example of Effective and Expiration Dates

Before the increase in coverage

PHYSICAL_ASSET_RK VALID_FROM_DTTM VALID_TO_DTTM ASSET_VALUE_AMT EFFECTIVE_FROM EFFECTIVE_TO 1001 01-MAR-2003

00:00:00 01-JAN-5999 00:00:00

$100,000 01-APR-2003 00:00:00

31-MAR-2004 00:00:00

After the increase in coverage

PHYSICAL_ASSET_RK VALID_FROM_DTTM VALID_TO_DTTM ASSET_VALUE_AMT EFFECTIVE_FROM EFFECTIVE_TO 1001 01-MAR-2003

00:00:00 31-JAN-2003 23:59:59

$100,000 01-APR-2003 00:00:00

31-MAR-2004 00:00:00

1001 01-APR-2004 00:00:00

01-JAN-5999 00:00:00

$110,000 01-APR-2004 00:00:00

31-MAR-2005 00:00:00

The EFFECTIVE_FROM date value and the EFFECTIVE_TO date value provide business effective periods for the data in this version of the row. If these date values do not provide enough historical data in conjunction with the VALID_FROM and VALID_TO date values, then you can add business-system-related dates, which are subject to naming standards and other standards.

Using Processed Date/Time Knowing the last time that a row was processed in the banking DDS is useful. Processing can be initially creating a row, or updating a row, such as adding the VALID_TO_DTTM value to an existing row. The PROCESSED_DTTM value concludes which rows have changed since they were loaded into the data mart by determining the last time that the row was touched by an ETL process or by the data administrator, which includes unusual updates that do not change the row (such as error-correction data-patching). You can populate the PROCESSED_DDTM value by using the Load Time column that is available in the SCD Type2 Loader transformation of SAS Data Integration Studio.

Using Natural/Business Keys In the banking DDS, capturing the primary source system identifier (also known as the natural key or business key) and the retained keys in the rows of the tables is useful. The standard for capturing the natural/business key in the banking DDS is <TABLE_NAME>_ID. Figure 2.3 shows the retained key and natural/business key for a financial account. These natural/business keys originate from the source systems and typically contain long alphanumeric strings. Capturing all keys is useful if you need to go back to the source systems to investigate data.

Figure 2.3 Retaining the Natural/Business Key

FINANCIAL_ACCOUNT_RK VALID_FROM_DTTM VALID_TO_DTTM FINANCIAL_ACCOUNT_ID 1001 01-JAN-2002

00:00:00 01-JAN-5999 00:00:00

23086549C

10 Using Natural/Business Keys Chapter 2

3 Organization of Tables in the SAS Detail Data Store for Banking

Overview........................................................................................................................................................... 11 More Information ............................................................................................................................................ 14

Overview At a high level, the banking DDS can be grouped into subject areas. As shown in Figure 3.1, the data model consists of the following subject areas:

Party

This subject area includes the parties that are involved in banking, such as the supertype Customer table, the Individual_Customer table, the Corporate_Customer table, and the associated reference tables. The Counterparty table and related tables are more examples. Customer information can include details of individual and corporate customers, associated addresses and contact information, household information for individuals, organization information for corporate customers, and information about the segments to which a household or customer belongs. Customer information is obtained from the customer management systems and the marketing or customer intelligence systems.

Service Entities

This subject area includes tables that relate to the servicing of customers and employees of the bank. The Financial_Unit table (branch and ATM), the Internal_Org table (departments and divisions within the bank), and the sales agent table are examples of service entities.

Marketing Automation

This subject area includes information from SAS Marketing Automation, including:

campaigns and communications storage (available from marketing or customer intelligence systems, and loaded into the banking DDS if SAS Campaign Management is implemented)

customer contacts and responses surveys that are conducted by the bank or financial institution

(available from proprietary systems or data feeds) customer-segmentation information

C H A P T E R

12 Overview Chapter 3

event information (such as address changes, marriages, job changes) that is actively tracked for a customer (available from account management and transactional systems)

Loss Events

This subject area includes internal loss events and related entities. A loss event is an occurrence of an operational failure, for example, a power blackout, tsunami disaster, financial audit, and so on. The consequence of a loss event is a financial impact. Loss events are categorized into general risk categories and fall within certain business lines.

Analytical Model and Scoring Information

This subject area includes analytical results that are written back to the banking DDS and shared among applications. Analytical results include cross-sell, up-sell, and customer-retention scores, as well as details about analytical models that are built by the bank or financial institution and scores that are generated by the analytical models.

Analytical intelligence systems are one source of analytical information. If a banking analytical solution is implemented, the resulting information is loaded into the banking DDS.

Financial and Banking Accounts

This subject area includes information about accounts, including:

traditional banking accounts (such as investment, savings, checking, and loan accounts) and their related transactions (collateral information is available from collateral management systems)

account and account transaction information (available from account management and transactional systems)

communication information (available from customer intelligence systems)

application and applicant information (available from application management systems)

The banking DDS stores information for core banking accounts (such as savings and checking accounts), loan accounts, mortgage accounts, credit card accounts, investment accounts, retirement accounts, and insurance (such as life, property, travel, motor, protection) accounts.

Banking Account and Insurance-Related Transactions

This subject area includes transactions that are related to traditional banking accounts, such as withdrawals and deposits. In addition, for the insurance-related information, tables that are related to premium collections and claims transactions are included.

Organization of Tables in the SAS Detail Data Store for Banking Overview 13

Financial Products and Instruments

This subject area includes retail banking products (such as investment account products) and instruments that are used in credit risk (such as currency swaps). It includes product details (such as product categories and types). This subject area is the product master for a bank or financial institution. Product information is obtained from product and pricing management systems.

Risk Mitigant

This subject area includes the various types of credit risk mitigants (entities such as physical and financial collateral and receivables).

Exposure

This subject area includes the financial exposure of a counterparty through an account, financial position holding, or credit facility.

Figure 3.1 High-Level View of the SAS Detail Data Store for Banking

14 More Information Chapter 3

More Information

The following appendices include more information about banking DDS table organization:

Appendix 1, “Table Loading Sequence,” describes the proper sequence of loading the banking DDS tables.

Appendix 2, “SAS Detail Data Store for Banking Table Types,” describes the five types of tables that are used in the banking DDS.

Appendix 3, “Standard Data Types and Naming Conventions,” describes the standard data types and naming conventions that are used in the banking DDS.

Appendix 4, “Data Model Notation,” describes the special notations that are used in the banking DDS model.

Appendix 5, “Table and Column Changes,” lists new banking DDS tables and new columns that have been added to existing banking DDS tables.

Appendix 6, “Banking DDS Deployment FAQ,” lists frequently asked questions, problems, answers, and solutions that are related to banking DDS deployment.

Appendix 7, “Deploying Banking DDS on Oracle,” describes creating and registering the banking DDS in an Oracle environment.

15

4 Defining Role-Based Users and Groups for the SAS Detail Data Store for Banking

Overview........................................................................................................................................................... 15 Planning User Groups and Roles ................................................................................................................... 15 Sample User Groups and Roles ...................................................................................................................... 16

Metadata Administrator ......................................................................................................................... 17 DDS Administrator ................................................................................................................................. 17 ETL Administrator.................................................................................................................................. 17 Information Architect .............................................................................................................................. 18 Power Users.............................................................................................................................................. 18

Overview

The tasks in this chapter describe how to define metadata user roles, set up appropriate user IDs, and assign user IDs to groups. This chapter provides a recommended role-based setup guide for banking DDS metadata users. Although the chapter provides recommendations on potential roles, each business should define its own roles that are based on the specialized functions that are required by the business.

Planning User Groups and Roles The steps in planning user roles and groups are the following:

1. Define user roles that are based on business and functional needs. 2. Determine which user accounts you must establish in the metadata for the

business and functional needs. 3. Decide how to organize users into groups.

When setting up user roles, analyze the business and functional needs that pertain to the banking DDS setup and usage. User roles should be robust for the administrative roles, and limited, but not limiting, for the power user roles. User roles should have the correct balance between deployability, usability, and maintainability for your metadata.

C H A P T E R

16 Sample User Groups and Roles Chapter 4

Consider the various business and functional tasks that need to be accomplished to set up the proper user environment for the banking DDS. For example, some required business and functional tasks are:

setting up the SAS Metadata Server environment registering and administering the metadata maintaining, scheduling, and running the ETL jobs creating information maps creating, running, and viewing reports

After defining the business and functional tasks, create the user IDs and permissions that are necessary to perform the tasks. It is a best practice to organize users into groups because it simplifies the process of establishing and managing the users. Assigning permissions to users on an individual basis can be cumbersome. After defining the groups, assign permissions to the groups rather than to individual users. Note: Two user groups are automatically created in the Foundation repository:

PUBLIC and SASUSERS. Membership in the PUBLIC and SASUSERS groups is implicit. If you can access the SAS Metadata Server, then you are automatically a member of the PUBLIC group. If you can access the SAS Metadata Server and you have your own metadata identity, then you are automatically a member of both the PUBLIC group and the SASUSERS group.

Finally, define the user roles and create the groups that are necessary to assist with the administration of the banking DDS.

Sample User Groups and Roles This section suggests user roles and groups. (Note that there are various other ways to establish metadata user IDs. There could be a developer group and many types of power users, for example.) The sample user roles are derived from the perspective of a production environment.

Metadata Administrator This role is the unrestricted user. It acts as overall administrator for the metadata repository. It is not given access to the directories that contain data.

DDS Administrator This role is the administrator for the banking DDS. It is responsible for managing the metadata for the banking DDS and owns directories that contain banking DDS and any other critical customer data.

ETL Administrator This role updates and runs ETL jobs and provides production support.

Information Architect This role creates information maps using the banking DDS data files. It coordinates with the DDS Administrator to set up privileges for Power Users.

Power Users This role queries the information maps that have been set up. Access to the information maps is assigned by the DDS Administrator in consultation with the Information Architect.

Defining Role-Based Users and Groups for the SAS Detail Data Store for Banking Sample User Groups and Roles 17

Users and groups are defined around these functional tasks and user roles.

Metadata Administrator The Metadata Administrator is the unrestricted user for your SAS installation (for a default SAS installation, this is sasadm). This user has unrestricted privilege to the Foundation repository and can make changes to the SAS installation. The Metadata Administrator is responsible for the following:

installing the SAS Metadata Server and other SAS software setting up scripts and services to start and stop the servers creating the Foundation repository setting up and registering the servers within the Foundation repository creating administrative users, for example, the DDS Administrator

DDS Administrator

The DDS Administrator deploys the banking DDS and ETL jobs. The DDS Administrator is created by the Metadata Administrator. The DDS Administrator is responsible for the following:

creating the banking DDS physical data files creating the library and registering the banking DDS metadata creating other libraries that are needed by the deployment importing ETL jobs and EFI (External File Interface) objects creating other users and groups, such as the ETL Administrator and Power

Users assigning permissions to the user accounts creating deployment directories

ETL Administrator The ETL Administrator develops, schedules, manages, and deploys ETL jobs. The ETL Administrator is responsible for the following:

verifying that production deployment has worked properly deploying ETL jobs making changes to ETL jobs using SAS Data Integration Studio scheduling ETL jobs using LSF Scheduler or any other third-party scheduler providing production support to resolve any problems in the data reporting on job status by directly accessing the data sets created for this

purpose

18 Sample User Groups and Roles Chapter 4

Information Architect

The Information Architect designs, creates, and deploys information maps for Power Users using SAS Information Map Studio.

The Information Architect is responsible for the following: creating and maintaining information maps working with DDS Administrators to set up privileges for Power Users

Power Users The Power Users consume the information maps that are generated by the Information Architects. Power Users query the banking DDS based on the information maps. There can be many types of power users. You might need different groups of power users to focus on different business areas. For example, you might set up a credit card power user to focus on credit card accounts, and an investment power user to focus on investment information. Access for power users is restricted to the information maps that they need. The Power User is responsible for the following:

running information maps that have been assigned to the Power User working with the Information Architect to update or request information

maps

5 Creating and Registering the SAS Detail Data Store for Banking Tables

Overview........................................................................................................................................................... 19 Prerequisites .................................................................................................................................................... 19 Installing the Metadata Import-Export Tool ................................................................................................. 20 Verification of Installation.............................................................................................................................. 20 Creating the Banking DDS............................................................................................................................. 20 Registering the Metadata................................................................................................................................ 21 Editing the Library Path ................................................................................................................................ 26 Creating a Subset Version of the Banking DDS Physical Model ................................................................. 28

Modifying the %DDLDDS Macro ........................................................................................................... 28 Selective Registration .............................................................................................................................. 28

Verifying the Metadata Registration.............................................................................................................. 29

Overview

The following chapter details how to instantiate the banking DDS, release 2.3. The instantiation process includes the steps to create the physical tables and the steps to register the metadata in the metadata repository.

Prerequisites

Complete the following steps before creating and registering the banking DDS tables:

1. All SAS products and solutions must be correctly installed by following the installation instructions that are shipped with the products and solutions.

2. SAS Data Integration Studio must be set up and functional. “Setup Tasks for Administrators” in the SAS Data Integration Studio User’s Guide outlines all of the required tasks prior to using SAS Data Integration Studio. These same tasks are required prior to loading some of the components of the banking DDS.

3. A SAS Metadata Server and a metadata repository must be operational.

C H A P T E R

20 Creating the Banking DDS Chapter 5

Installing the Metadata Import-Export Tool

The Metadata Import-Export Tool (MIET) - a plug-in for SAS Data Integration Studio - must be installed to register metadata. If the MIET plug-in is not available as part of the solution’s installation package, please contact your SAS Support Consultant to gain access to this tool.

To install the MIET:

1. Download the MIET and save it to your local directory. 2. Extract the .jar file to the SAS Data Integration Studio plug-ins directory. On a

Windows-based computer, the plug-ins directory is usually located at C:\Program Files\SAS\SASETLStudio\9.1\plugins.

Note: Metadata_Import_913_V1.2.jar works with SAS 9.1.2 ETL Studio (renamed SAS Data Integration Studio) and Metadata_Import_914_V1.2.jar works with SAS 9.1.3 Data Integration Studio 3.2, and later.

Verification of Installation

After you install the MIET, SAS Data Integration Studio must be restarted (closed and opened again). The MIET installation can be verified by the following methods.

The following shortcut is in the SAS Data Integration Studio shortcut bar.

The following menu option is in the SAS Data Integration Studio Tools menu.

Creating the Banking DDS DDL CREATE TABLE statements instantiate the banking DDS physical model structure. The %DDLDDS macro creates the table definitions and has %INCLUDE statements that reference <tablename>.sas files that contain the CREATE TABLE statements to instantiate the physical model structure.

Creating and Registering the SAS Detail Data Store for Banking Tables Registering the Metadata 21

A default DATE9 informat/format is applied to date fields in the supplied DDL. For customer sites with different date requirements, the macro variable DTFMT can be changed to represent the locale (such as, EURDFDEw.). The macro variable is referenced in the invocation string for the %DDLDDS macro, which is detailed next. To create the physical tables, do the following:

1. Modify and submit the following %DDLDDS macro code (available as part of the banking DDS installation): /* Macro variables to be assigned: Fileloc: Assign fileloc macro parameter to point to the directory which contains the DDL create table statements contained in <tablename>.sas files. DTFMT: (Optional: Defaults to DATE9.) If international date values are needed, assign a new DTFMT= value, such as dtfmt=EURDFDEw. */

%include "<location_of_provided_macro>/ddldds.sas"; LIBNAME DDS “<location_to_store_tables>”; %ddldds(fileloc=<location_of_SAS_DDL>, dtfmt=<International_Date Value>);

2. Verify that the tables were created properly by submitting the following code: proc datasets lib=DDS; quit;

The DATASETS procedure output can be compared against the banking DDS physical model structure.

The full set of physical tables that make up the banking DDS data model is now instantiated.

Registering the Metadata One file per table is registered in the metadata. The tables, library, and pre-created custom folders are available in the installation package and must be imported to the customer’s production repository using the MIET, which is available under the Tools menu in the main menu of SAS Data Integration Studio.

22 Registering the Metadata Chapter 5

1. In SAS Data Integration Studio, select Tools Components Import Wizard.

Figure 5.1 Accessing the Components Import Wizard

When you select the Components Import Wizard, a Welcome page opens.

Figure 5.2 Welcome Page

2. Click Next to move to the Solution Folder Choice Page.


Figure 5.3 Solution Folder Choice Page

3. Click Browse and select the objects from the folder where the banking DDS is installed. The default installation directory is C:\Program Files\SAS \SASBankingDDS\2.3\Metadata. Choose the repository from the menu and click Next. The following message appears:

Figure 5.4 Confirmation Message

4. Click Yes to move to the Component Choice Page. If you have not selected the right repository, click No to go back and change the repository selection. On the Component Choice Page, a tree view of the objects is shown. Select the objects to import and click the Add button ( ).

24 Registering the Metadata Chapter 5

Select only those objects that are required for the metadata registration process – Groups (known as custom folders in SAS Data Integration Studio), Libraries, and Tables – and import them to the Foundation repository. The following figure shows that the required groups, library, and some tables have been added.

Figure 5.5 Component Choice Page

5. Click Next to move to the Comparison Between Environment page.

Figure 5.6 Comparison Between Environment Page


Each object, such as a table or a library, appears under its respective tab. Groups does not have a tab. You can deselect the tables and libraries that you do not need. 6. Click Next to move to the Wizard Finish page.

Figure 5.7 Wizard Finish Page

The Wizard Finish page gives information on the metadata that is being created. If you would like to make changes, click Back. If the information is correct, click Finish. The selected objects will be added to the Foundation repository. 7. Select View Refresh from the SAS Data Integration Studio main menu to see

the updated Foundation repository that contains the created objects.

26 Editing the Library Path Chapter 5

Editing the Library Path

After you register the metadata, you need to edit the path of the imported library to point to the physical location of the banking DDS. In SAS Data Integration Studio, expand the DETAIL_DATA_STORE library. Right-click Detail Data Store and select Properties, as shown in the following figure.

Figure 5.8 SAS Data Integration Studio Window

1. Click the Options tab to display the Detail Data Store properties dialog box.

Creating and Registering the SAS Detail Data Store for Banking Tables Editing the Library Path 27

Figure 5.9 Detail Data Store Properties Dialog Box

2. Select the path under Selected items (which is <Location of Your Banking DDS>) and click Edit.

3. Click Yes when the Warning dialog box appears.

Figure 5.10 Warning Dialog Box

28 Creating a Subset Version of the Banking DDS Physical Model Chapter 5

This opens the Edit Path Specification dialog box. Replace the existing path with the path where the banking DDS is located, for example Data/bisdata/DDS as shown in the following figure.

Figure 5.11 Edit Path Specification Dialog Box

4. Click OK in the Edit Path Specification dialog box and click OK in the Detail Data Store Properties dialog box.

5. Highlight the original path - <Location of Your Banking DDS>. Using the left arrow, remove this path from the Selected items panel.

Creating a Subset Version of the Banking DDS Physical Model If the entire banking DDS model is not instantiated, you can modify the %DDLDDS macro and select only the tables in the MIET that are needed to create and register the tables that are required for the solution that is being installed.

Modifying the %DDLDDS Macro For example, if the Analytical_Model and Bond_Instrument tables are not required for the current banking DDS implementation, you can remove the %INCLUDE statements for these tables from the %DDLDDS macro (as shown in the italicized bold lines in the following code):

%macro ddldds(LIBREF=DDS,DTTMFMT=NLDATM21., DTFMT=DATE9., FMTRK=12., fileloc=); PROC SQL; %include "&fileloc./account_credit_risk_mitigant.sas"; %include "&fileloc./analytical_model.sas"; Remove %include "&fileloc./application_score.sas"; %include "&fileloc./assessment_rating_grade.sas"; %include "&fileloc./assessment_values.sas"; %include "&fileloc./asset_x_physical_collateral.sas"; %include "&fileloc./bond_instrument.sas"; Remove . . %include "&fileloc./specific_provision.sas"; %include "&fileloc./swap_irs_ccs_instrument.sas"; QUIT; %MEND;

If you want to import only the tables that are needed for a specific solution, then follow the instructions in the next section.

Selective Registration 1. On the Component Choice Page (shown in Figure 5.5), select only the tables that are

needed for your specific solution and click the Add button.

Creating and Registering the SAS Detail Data Store for Banking Tables Verifying the Metadata Registration 29

Figure 5.12 Component Choice Page

2. Follow the steps in the “Registering the Metadata” section.

Verifying the Metadata Registration

You can use the following methods to verify that the metadata was registered properly:

1. Review the log file that was produced by the MIET. The log file documents whether the import was successful and reports any errors that were found during the process.

2. Connect to the SAS Metadata Server and metadata repository as the DDS Administrator, using either SAS Management Console or SAS Data Integration Studio, and visually verify that the proper table metadata was created in the library.

30 Verifying the Metadata Registration Chapter 5

31

6 Loading the SAS Detail Data Store for Banking

Identifying Data Sources ................................................................................................................................ 31 Expected Data Source Systems ............................................................................................................... 31

Guidelines for Loading Data into the Banking DDS .................................................................................... 32 Recommended Process ............................................................................................................................. 32

Understanding Initial and Periodic Data Loads .......................................................................................... 35 Archiving Data ................................................................................................................................................ 35

Identifying Data Sources Because banks and financial institutions are among the oldest and most mature users of information technology, the number, variety, and application of IT systems are extremely diverse. Quality data must be loaded into the banking DDS to benefit from a SAS banking solution. Therefore, it is critical to identify correct data source systems. Customers with an existing data warehouse can obtain all of the required data from the data warehouse itself. However, other customers might need to obtain data from diverse source systems, external data stores, and multiple data feeds.

Expected Data Source Systems The following categories of data and IT systems are typical in banks and financial institutions:

customer and account management systems account and application management systems collateral management systems marketing and customer intelligence systems product and pricing management systems transactional systems, such as teller systems, ATMs, credit card transaction feeds external data feeds, such as bureau information business and analytical intelligence systems other systems, such as human resources and general ledger

C H A P T E R

32 Guidelines for Loading Data into the Banking DDS Chapter 6

These categories could be available from a single IT system or from multiple IT systems. Historical information could be available from data archival systems. Or, all of the data could be available in an existing data warehouse.

Guidelines for Loading Data into the Banking DDS After you have identified the banking DDS data sources, you have to load the data into the banking DDS. Both the bank or financial institution and the data warehouse consultants need to choose the method to load data into the banking DDS. This choice depends largely on the structure and diversity of the data source systems. For example, if the number of data source systems is large and the data source systems are uncoordinated, then consolidating and cleaning data are major considerations. However, if the data source systems are coordinated or if there is an existing data warehouse, then consolidating and cleaning data are already an integral part of the existing system.

Recommended Process The recommended process for loading data into the banking DDS (shown in Figure 6.1) includes five steps.

1. Identify data structures in the banking DDS that need to be loaded to meet the business needs of the bank or financial institution.

2. Identify data source systems by mapping banking DDS data and data source system data. Then, extract data from the data source systems into extract files.

3. Clean the extract files and consolidate them into extract files that are designed to load data into the banking DDS. The data is validated so that all interdependencies and relationships in the banking DDS are defined.

4. Load reference tables that store code values that are required in the banking DDS. 5. Load data into the banking DDS and validate the data.

Loading the SAS Detail Data Store for Banking Guidelines for Loading Data into the Banking DDS 33

Figure 6.1 Loading Data into the Banking DDS

Step 1: Define the precise data to be loaded into the banking DDS. The banking DDS is designed to support multiple solutions, although not all of the solutions are implemented simultaneously. Therefore, you must identify the precise data that needs to be loaded into the banking DDS to support the solutions that are to be implemented, which is often an iterative process. A detailed list of the banking DDS tables and columns that are needed to support specific banking solutions is provided in SAS Detail Data Store for Banking 2.3: Matrix of Fields. It can be downloaded from the SAS Customer Support Center at: http://support.sas.com. From this page, select Documentation Products &

34 Guidelines for Loading Data into the Banking DDS Chapter 6

Solutions and then select SAS Detail Data Store for Banking from the Select a Product menu. The document is available under the Documentation: SAS Detail Data Store for Banking 2.3 section. The detailed list identifies data that needs to be loaded into the banking DDS for a particular SAS solution. The list might need to be customized based on the specific requirements of the bank or financial institution or based on the availability of data in the data source systems.

Step 2: Identify and extract the data from the data source systems. Identify the data source systems and the data structures within the data source systems. To accomplish this step, map the banking DDS data to data from the data source systems. For each data source system, a format is defined for the data extract. This format represents how the data is stored in the data source system and optimizes extracting data. Data is extracted from the data source system into an extract file of a defined format.

Step 3: Clean and consolidate the data from the data source systems. Data that has been extracted from the data source systems and into different formats is cleaned and consolidated into the formats that are suitable for loading the banking DDS. The time needed to clean and consolidate the data depends on the condition of the data and the number of data source systems.

Step 4: Load the reference tables. Reference tables that store code values that are required in the banking DDS must be loaded before the banking DDS is loaded because of the following reasons:

Different data source systems might use different codes to represent the same code value.

Codes that are required by the banking DDS might not be defined. The column widths of existing code columns might not match the column widths

that are defined in the banking DDS. You should ensure that code values are stored correctly and available to the solutions that use the banking DDS. As you carefully check the code values for accuracy and availability, include business users, IT staff of the bank or financial institution, and banking solution consultants. After this check is performed, load code manually into the banking DDS reference tables or extract code from the existing data source systems and load it into the banking DDS reference tables.

Step 5: Load data into the banking DDS and validate. Ensure that data is loaded in the correct sequence. For example, an account transaction cannot be loaded unless the account in which the transaction occurred is first loaded into the banking DDS. Appendix 1, “Table Loading Sequence,” contains the correct sequence for the banking DDS, release 2.3. Because the banking DDS can have data from multiple data source systems, you need to generate the primary key for data in the banking DDS. The column name of the banking DDS primary source identifier has a _RK suffix. The online data dictionary includes

Loading the SAS Detail Data Store for Banking Archiving Data 35

details of the primary source identifier (also known as the natural key or business key) for each banking DDS table. When loading data into the banking DDS, the natural key or business key of the source data is matched with data that is available in the banking DDS. If the natural key or business key exists in the banking DDS, the existing banking DDS record is expired, and a new record is inserted with the updated information. The natural key or business key in the banking DDS retains the same value, but the validity dates are changed. If the natural key or business key does not exist in the banking DDS, a new record with a new natural key or business key (calculated as maximum + 1) is inserted.

Note: The business key is typically the primary key from the data source system table and the data source system code.

The time that is needed to load the banking DDS depends on the volume of data and the number of necessary transformations.

Understanding Initial and Periodic Data Loads The initial data load loads all of the available cleansed and validated data from the data source systems and the associated data archives into the banking DDS. The required history to be loaded depends on the following factors:

the amount of historical data that is available the historical data that is required by the solutions that will be implemented

After the initial data load, the banking DDS and solutions are designed to support any periodic load frequency (daily, weekly, or monthly). The banking DDS and solutions support ad hoc loads and partial loads, provided that consistency of the data is maintained. For example, an account transaction cannot be loaded unless the account in which the transaction occurred is first loaded into the banking DDS. The actual load frequency depends on a solution’s requirements and the business processes of the bank or financial institution. Periodic loads are generally incremental, and only new or changed data is extracted from the data source systems for loading.

Archiving Data Whether to archive data is based on the answers to the following questions.

How much data can you keep online? When is data no longer needed? What category of data can be archived (for example, transactions or aggregates

only, old customers, old reference data, any data that is older than a certain date)?

Is the archived data expected to be re-integrated on short notice? Do you have DBMS-level archival mechanisms, such as partition-level archival

or rollout? What drives archival decisions (for example, space management, regulatory

constraints)?

36 Archiving Data Chapter 6

The simplest archival approach with the largest benefit is to archive transactions and aggregates as they age beyond a site-defined threshold. However, you should consider the following facts when you make decisions about archiving:

Associated reference data of a relatively low data volume might be too unimportant.

Age should not be the only factor. For instance, an active customer’s record might have been created years ago and have never changed; in this case, you would want to archive the data.

Note: Archiving transactions or aggregates might have an effect on calculated data within the banking DDS, which means you will have to recalculate the data.

Archival should be a simple and regularly scheduled task. You should test the archival process in a test environment before archiving data from a production environment. In addition, you should consider the archival-process window, archival tape or disk allocation and storage, recovery procedures, and user notification.

37

7 Customizing the SAS Detail Data Store for Banking

Overview........................................................................................................................................................... 37 Modifying the Banking DDS .......................................................................................................................... 38 Using Caution.................................................................................................................................................. 38 Avoiding Trouble ............................................................................................................................................. 38 Things to Keep in Mind................................................................................................................................... 39

Overview Initially, the scope of the banking DDS can be larger than the scope of the data that is to be subsequently loaded. New data might be required, or a new SAS solution might be needed that requires data that was not previously loaded into the banking DDS. You might need to populate tables and fields in the banking DDS that exist, but were not previously required. An issue to consider is time consistency. If new data will not be loaded to the same historical point in time as the current banking DDS, then that fact must be “known” to the application that is accessing the data. New data table- or field-level requirements mean the following:

a change to data source system extract files a change to SAS Data Integration Studio jobs a possible change to dependencies, DDS tables, and indices the need for new SAS Data Integration Studio jobs for downstream applications (for example, the solution’s applications that created the new data requirements)

Understanding the data flow from the data source to the banking DDS means understanding the impact of adding new data requirements. Identify each impacted component, starting with data source system extract files, and modify each component accordingly in a test environment. All customizations should be identified by following the customization guidelines, and all additions should have a defined prefix (for example, X_). This ensures that the upgraded version of the banking DDS does not have a table or column of the same name. Additions should contain a meaningful and accurate description.

Note: Contact your SAS Support Consultant to obtain a copy of the banking DDS Computer Associates AllFusion ERwin Data Modeler source if it is needed for implementation.

C H A P T E R

38 Avoiding Trouble Chapter 7

Modifying the Banking DDS

Typically, you can expect to make the following modifications when implementing a banking DDS:

adding local language or value format requirements adding fields in the tables because of business requirements adding an entity or a table because of a new area of business adding new data formats customizing the language code (LANGUAGE_CD) to be specific to the country customizing most of the amount values that use currencies (CURRENCY_CD) to be specific to the country

changing column labels (which can be done with no impact)

Using Caution

You can add fields to tables; however, if you use these new fields in downstream applications that have already been implemented, you will need to customize the downstream applications. When adding a field, use a prefix (for example, X_) to indicate that it is a user-added field.

You cannot reduce the length of the fields because doing so might impact downstream processing.

You can expand the length of fields; however, do so carefully because this can lead to truncation at the solution level.

You can add tables; however, if you use these new tables in downstream applications that have already been implemented, you will need to customize the downstream applications. If you add a new business area, you should add new processes instead of modifying existing processes. When adding a table, use a prefix (for example, X_) to indicate that it is a user-added table.

Avoiding Trouble

Do not change column names because doing so can significantly impact downstream applications that have already been implemented.

Do not change data types for columns because doing so can significantly impact downstream applications that have already been implemented.

Do not delete columns. Columns that are not required by the client can hold missing values.

Customizing the SAS Detail Data Store for Banking Things to Keep in Mind 39

Things to Keep in Mind

Develop and test modifications to the banking DDS in a controlled development or test environment before you migrate the modifications to a production environment.

You can add tables or columns or modify the length of a column within the SAS Data Integration Studio environment. See “Modifying SAS Data Integration Studio Jobs for Banking DDS Changes” for more information.

If you change the supplied DDL files, back up or copy the original DDL files in case you need to get back to a known starting point.

Identify the job dependencies and job order for new jobs and schedule the jobs accordingly.

When creating user-defined tables and fields, they should contain meaningful and accurate descriptions. To provide meaningful and accurate descriptions, all descriptions should be clear and concise without circular reasoning.

40 Things to Keep in Mind Chapter 7

41

8 Support Resources

For solution-specific technical support, see the SAS Technical Support Web site at http://support.sas.com/. In addition to documentation and technical support, SAS Professional Services supports the following areas:

a change to data source system extract files consulting services solution assessment, including feasibility and methodology for implementing Banking solutions

training DDS customization and implementation project management

The data model for the banking DDS in the Computer Associates AllFusion ERwin Data Modeler format is available by request from the SAS Customer Support Center at http://support.sas.com. From this page, select Documentation Products & Solutions and select SAS Detail Data Store for Banking from the Select a Product menu. The data model file can be requested by submitting the ERwin Model Request Form under the Request Forms section of the SAS Detail Data Store for Banking Resource Center.

C H A P T E R

42 Error! No text of specified style in document. Chapter 8

1 Table Loading Sequence

The banking DDS table loading sequence is listed in the following table. Tables in Wave 1 should be loaded before tables in Wave 2 and so forth, using the wave number numerical order that is shown in the following table.

Tables Loaded in Wave 1 ACCOUNT_BLOCKING_REASON ACCOUNT_CLOSE_REASON ACCOUNT_LIFECYCLE_STAGE ACCOUNT_REGISTRATION_TYPE ACCOUNT_RENEWAL_TYPE ACCOUNT_RESTRICTION_TYPE ACCOUNT_STATUS ACCOUNT_USAGE_TYPE ADDL_BORROWING_PURPOSE ADDRESS_QUALITY ADDRESS_TYPE ADD_ON_SET_TYPE AGENCY_TYPE ALARMED ANALYTICAL_MODEL_TYPE ANNUAL_INCREASE ANTI_LOCK_BRAKING APPENDED_DATA_MEASURE APPENDED_DATA_SOURCE APPROACH_TYPE APR_TYPE AREA_COVERED ASSESSMENT_CHANGE_REASON ASSESSMENT_RESULT_TYPE ASSESSMENT_TYPE ASSESSMENT_VALUE_TYPE ASSET_CLLTRL_RLN_TYPE ASSET_TYPE ASSOCIATE_ACCOUNT_ROLE ASSOCIATE_STATUS AUTO_DEBIT_ACCOUNT_TYPE BANKRUPTCY_STATUS BANK_CARD_TYPE

A P P E N D I X

44 Appendix 1

Tables Loaded in Wave 1 BARRIER_TYPE BENEFICIARY_RELATIONSHIP BLDG_VOLUNTARY_EXCESS BOND_INSTRUMENT_TYPE BRANCH_FREQUENCY_REASON BREAKDOWN_COVER BROKERAGE_ACCOUNT_STATUS BUILDING_STATUS_TYPE BUILD_ERA BUREAU BUREAU_CLASS BURGLAR_ALARM_TYPE BUSINESS_LINE_ASSOC_TYPE CAL_DATE CARD_CANCEL_REASON CARD_OTHER_TERMS CARD_PAYMENT_ACCOUNT_TYPE CARD_PAYMENT_TYPE CARD_PROTECTION_INS CARD_PROTECTION_STATUS CARD_PROTECTION_TYPE CASHFLOW_INSTRUMENT_TYPE CASH_FLOW_TYPE CENTRALIZATION_OF_DECISIONS CHANNEL CLAIM_REASON CLAIM_STATUS CLASS_OF_BUSINESS CLEAN_UP_CALL_TYPE CLIENT_TYPE CODE_LANGUAGE COLLATERAL COLLECTIONS_STATUS COLOR COMMISSION_EXCL_REASON COMMITMENT_TYPE COMMODITY_INSTRUMENT_TYPE COMMODITY_TYPE COMMUNICATION_STATUS COMPOUNDING CONSTRUCTION CONTACT_ACTION CONTACT_REASON_TYPE CONTACT_TYPE CONTENTS_VOLUNTARY_EXCESS CONTRIBUTION_TYPE CONVICTIONS

Table Loading Sequence 45

Tables Loaded in Wave 1 CORE_ACCOUNT_STATUS CORE_ACCOUNT_TYPE CORE_ACCT_REGULAR_DIRECTION CORE_ACCT_REGULAR_METHOD CORE_ACCT_REGULAR_STATUS CORE_BANKING_ACCOUNT_TYPE CORE_PRODUCT_TYPE COUNTERPARTY_ASSOC_TYPE COUNTERPARTY_LEGAL_TYPE COUNTERPARTY_RLN_TYPE COUNTERPARTY_TYPE COUNTRY COVERAGE CREDIT_CARD_ACCOUNT_TYPE CREDIT_CARD_PRODUCT_TYPE CREDIT_DERIVATIVE_TYPE CREDIT_FACILITY_TYPE CREDIT_LINE_USED_RANGE CREDIT_PAYMENT_PROTECTION CREDIT_RATING CREDIT_RISK_MITIGANT_TYPE CREDIT_STATUS CR_MITIGANT_REL_TYPE CURRENCY CURRENT_CARD_ORGANIZATION CUSTOMER_ACTIVE CUSTOMER_CLASS CUSTOMER_LIFECYCLE CUSTOMER_RISK_FACTOR CUSTOMER_TYPE DAY_BASIS DECISION DEFAULT_REASON DEFAULT_STATUS DEFAULT_TYPE DELIVERY_POINT_SUFFIX DIVIDEND_PAYMENT DIVISION_TYPE DOCUMENTATION_TYPE DRIVE_SIDE EARLY_AMORTIZATION_TYPE ECONOMIC_ENTITY_TYPE ECONOMIC_SECTOR EDUCATION_LEVEL ELIGIBLE_CR_MITIGANT_TYPE EMPLOYEE_INVOLVEMENT_TYPE EMPLOYEE_UNION

46 Appendix 1

Tables Loaded in Wave 1 EMPLOYMENT_STATUS EQUITY_INSTRUMENT_TYPE EQUITY_POSITION_TYPE ETHNICITY EVENT_CATEGORY EVENT_STATUS EVENT_TYPE EXCESS_SPREAD_BAND EXPENSE EXTERNAL_CREDIT_RATING EXTERNAL_ORG_ASSOC_TYPE FEE_REASON FINANCIAL_ACCOUNT_TYPE FINANCIAL_ASSOCIATE_TYPE FINANCIAL_BOOK_TYPE FINANCIAL_EXCHANGE FINANCIAL_INSTRUMENT_CLASS FINANCIAL_POSITION_STATUS FINANCIAL_POSITION_TYPE FINANCIAL_PRODUCT_TYPE FINANCIAL_UNIT_TYPE FIN_COLLATERAL_SUBTYPE FLOAT_RATE_INDEX FRA_INSTRUMENT_TYPE FUND_INSTRUMENT_TYPE FX_INSTRUMENT_TYPE GENDER GENERAL_LEDGER GEO_DEMOGRAPHIC GL_ACCOUNT_TYPE GUARANTEE_CODE GUARANTEE_TYPE HHOLD_TYPE HOME_INSURANCE_TYPE HOME_REASON_LAST_CLAIM HOME_STATUS HOME_TYPE ID_VERIFICATION_TYPE IMMOBILIZER INCENTIVE_TYPE INCOME INCOME_CATEGORY INCOME_TYPE INCORPORATION_TYPE INDIVIDUAL_ORGANIZATION INDUSTRY INDUSTRY_CODE_TYPE


Tables Loaded in Wave 1 INFORMATION_SOURCE INQUIRY_STATUS INQUIRY_TYPE INSURANCE_COVER INSURANCE_TYPE INSURED_ITEM_TYPE INTEREST INTERNAL_CREDIT_RATING INTERNAL_ORG_ASSOC_TYPE INTERNAL_PRODUCT_CATEGORY INTRODUCER INVESTMENT_METHOD INVESTMENT_OBJECTIVE INVESTMENT_PRODUCT_TYPE IRB_ALT_TREAT_ELIGIBLE_TYPE ISSUE_TYPE LAST_CLAIM_REASON LAST_CLAIM_STATUS LATE_PAYMENT_STATUS LEASE_TYPE LEGAL_ENTITY_TYPE LICENSE_STATUS LIFESTAGE LIFE_INSURANCE_STATUS LIFE_INSURANCE_TYPE LIFE_OF_LOAN_CAP LIMIT_TYPE LINE_OF_BUSINESS LOAN_PAYMENT_TYPE LOAN_PRODUCT_TYPE LOAN_SECURITY_TYPE LOAN_STATUS LOAN_TRANS_STATUS LOAN_TYPE LOCATED LOSS_EVENT_FIN_STATUS MARITAL_STATUS MARKET MARKETING_CAMPAIGN MARKET_INDEX MARKET_SEGMENT MATURITY_BAND MEDIUM MEDIUM_TYPE MED_EXPENSES MERCHANT_CATEGORY_TYPE MODEL_DEPLOYMENT

48 Appendix 1

Tables Loaded in Wave 1 MODEL_RANK MORTGAGE_ADDITIONAL_STATUS MORTGAGE_PRODUCT_TYPE MORTGAGE_STATUS MORTGAGE_TYPE MOTOR_INS_COVERAGE_TYPE MOTOR_MANUFACTURER MOTOR_REASON_LAST_CLAIM MOTOR_STATUS MOTOR_TYPE NET_WORTH OFF_BALANCE_NETTING_TYPE OFF_BALANCE_SHEET_TYPE OPTION_TYPE OP_RISK_CAUSE ORG_TYPE OUTBOUND_COMMUNICATION_TYPE OUTCOME OVERRIDE_REASON OWNERSHIP OWNER_TYPE PAYMENT_INTERVAL PAYMENT_LEG PAYMENT_METHOD PAYMENT_PROTECT_STATUS PHONE_TYPE PHYSICAL_ASSET_TYPE PHYSICAL_COLLATERAL_SUBTYPE PPI_REASON_LAST_CLAIM PPI_STATUS_LAST_CLAIM PPI_TERMS_CONDITIONS PREMIUM_PAYMENT_STATUS PREMIUM_PAYMENT_TYPE PRE_CREDIT PRIMARY_ECONOMIC_ACTIVITY PROCESS PROCESS_ASSOC_TYPE PRODUCT_CATEGORY_ASSOC_TYPE PROJECTION_METHOD PROPERTY_CONSTRUCTION_TYPE PROPERTY_INS_STATUS PROPERTY_OWNERSHIP PROPERTY_TYPE PROPOSER PROPOSER_RLNSHP PROTECTION_CLAIM PROTECTION_CONDITION


Tables Loaded in Wave 1 PROTECTION_INS_STATUS PROTECTION_SPECIAL_TERMS PROTECTION_STATUS PROTECTION_TYPE PROT_TERM_CONDITION PROVISION_TYPE PURPOSE PUT_CALL_TYPE RADIO_REGION RECEIVABLES_INSTRUMENT_TYPE RECEIVABLES_TYPE RECOVERY_FROM_TYPE REDEMPTION_CHARGES REGLTRY_COUNTERPARTY_TYPE REGULATORY_LGD_SET REGULATORY_PD_SET REGULATORY_PRODUCT RELATIONSHIP RELATIONSHIP_TO_ACCOUNT REPO_INSTRUMENT_TYPE RESIDENT_STATUS RESPONSE_RULE RETIREMENT_PLAN_TYPE RETIREMENT_STATUS RIGHTS_TYPE RISK_CATEGORY_ASSOC_TYPE RISK_CLASS RISK_FACTOR_MEASURE_TYPE RISK_FACTOR_ROLE RISK_FACTOR_VARIABLE RISK_PROFILE ROOF_CONSTRUCTION SALARY_RANGE SCALE_FACTOR SCALE_FACTOR_TYPE SCORE_RANK SCORE_SEGMENT SECURITIZ_INSTRUMENT_TYPE SECURITIZ_PRIM_BANK_ROLE SECURITIZ_STRUC_SUBTYPE SECURITIZ_STRUC_TYPE SECURITY SEGMENT_STATUS SEGMENT_TYPE SENIORITY SERVICE_COST SERVICING_ARRANGEMENT

50 Appendix 1

Tables Loaded in Wave 1 SHARED_LOSS_GROUP SHAREHOLDER_PATTERN SOCIAL_AIM SOURCE SOURCE_SYSTEM SPECIALIZED_LENDING SPECIAL_NEEDS SPECIAL_TERMS SPOUSE_BENEFIT STATE_REGION STATISTICAL_AREA STATUS_LAST_CLAIM STD_OCCUPATION STRUCTURE_TYPE SURVEY_SOURCE SUSPENSIONS SWAP_INSTRUMENT_TYPE TAX_BRACKET TAX_DEFERRED_TYPE TAX_ID_TYPE TAX_STATUS TAX_WITHHOLDING TERMINATION_PROVISION TIME_FREQUENCY TIME_OF_DAY_TO_CONTACT TIME_UNIT_OF_MEASURE TRANSACTION_METHOD TRANSACTION_STATUS TRANSACTION_STATUS_REASON TRANSACTION_TYPE TRANSFER_TYPE TRAVEL_REASON TRAVEL_STATUS TV_REGION UNDERLYING_TERM UNDERWRITING_AREA UNIT_OF_MEASURE USED_TO_COVER_RISK_TYPE VALUATION_TYPE VARIABLE_RATE_PLAN_TYPE VOLUNTARY_EXCESS WINTER_SPORTS WITHDRAWAL_RESTRICTION


Tables Loaded in Wave 2 ADD_ON_SET ANALYTICAL_MODEL ASSESSMENT_AGENCY BUSINESS_LINE CAMPAIGN_COMMUNICATION COMMODITY_CODE COUNTRY_EXTERNAL_DATA COUNTY CREDIT_FACILITY_GROUP CR_MITIGANT_VALUATION_TYPE DEBIT_CREDIT_CODE ECONOMIC_ENTITY EVENT EXTERNAL_FINANCIAL_ACCOUNT EXTERNAL_ORG FINANCIAL_BOOK FINANCIAL_CALENDAR FINANCIAL_INSTRUMENT_TYPE FINANCIAL_PRODUCT_CATEGORY FIRM_RISK_FACTOR_VALUE FIRM_SCALE_FACTOR_VALUE HOUSEHOLD ISSUE_CODE MINIMUM_LGD_IRB_COLLATERAL PHYSICAL_COLLATERAL POSTAL_CD_EXTERNAL_DATA PROCESS_ASSOC RECEIVABLES_POOL REGULATORY_LGD REGULATORY_OPTION_SET REGULATORY_PARAMETER_SET REGULATORY_PD REGULATORY_RISK_WEIGHT_SET RISK_CATEGORY RISK_FACTOR SECURITIZATION_POOL SEGMENT SOURCE_MEASURE SURVEY TERM TRADE

52 Appendix 1

Tables Loaded in Wave 3 ADD_ON ANALYTICAL_MODEL_TRGT_PROD ASSESSMENT_RATING_GRADE BL_RISK_FACTOR_VALUE BL_SCALE_FACTOR_VALUE BOND_QUOTE BUSINESS_LINE_ASSOC CCF_AMORTIZATION_SET CCF_SET COMMODITY_QUOTE EMPLOYEE EQUITY_QUOTE EQUITY_VOLATILITY_QUOTE EXTERNAL_INDIVIDUAL EXTERNAL_ORG_ADDRESS EXTERNAL_ORG_ASSOC EXTERNAL_ORG_CONTACT EXTERNAL_ORG_FINANCIAL_DATA EXTERNAL_ORG_INDUSTRY FINANCIAL_CAL_DATE FINANCIAL_INSTITUTION FINANCIAL_PRODUCT FX_FORWARD_QUOTE FX_QUOTE FX_VOLATILITY_QUOTE HAIRCUT_SET HOUSEHOLD_MEASURE HOUSEHOLD_X_SEGMENT INSURANCE_COVERAGE INTEREST_RATE_QUOTE INTERNAL_LOSS_EVENT INT_RATE_VOLATILITY_QUOTE PRODUCT_CATEGORY_ASSOC PROPERTY REGULATORY_OPTION REGULATORY_PARAMETER REGULATORY_RISK_WEIGHT RISK_CATEGORY_ASSOC SOURCE_MEASURE_ARGUMENT STD_INTERNAL_BL_ASSOC STD_INTERNAL_RISK_CAT_ASSOC SURVEY_QUESTION


Tables Loaded in Wave 4 ASSESSMENT_VALUES CCF CCF_AMORTIZATION CONFIGURATION CORE_PRODUCT COST_CENTER CREDIT_CARD_PRODUCT CREDIT_SPREAD_QUOTE EXTERNAL_INDIVIDUAL_ADDRESS FINANCIAL_PRODUCT_X_BL HAIRCUT_FX INT_LOSS_EVENT_X_CAUSE INT_LOSS_EVENT_X_INSURANCE LOAN_PRODUCT MORTGAGE_PRODUCT PHYSICAL_ASSET PROFIT_CENTER RATING_GRADE_BAND

Tables Loaded in Wave 5 ASSET_X_PHYSICAL_COLLATERAL HAIRCUT INTERNAL_ORG PHYSICAL_ASSET_CREDIT_ASSESS

Tables Loaded in Wave 6 BUSINESS_ENTITY BUSINESS_LINE_X_INTERNAL_ORG CONFIGURATION_X_INTERNAL_ORG EMPLOYEE_X_INTERNAL_ORG FINANCIAL_REPORTING_DATA FINANCIAL_UNIT GENERAL_PROVISION GL_ACCOUNT INTERNAL_ORG_ADDRESS INTERNAL_ORG_ASSOC INTERNAL_ORG_FINANCIAL_DATA REGULATORY_CAPITAL RISK_LIMITS

Tables Loaded in Wave 7 FINANCIAL_ASSOCIATE GL_ACCOUNT_ASSOC_TYPE

Tables Loaded in Wave 8 CUSTOMER

54 Appendix 1

Tables Loaded in Wave 9 CAMPAIGN_COMM_SUPPRESSED CORPORATE_CUSTOMER COUNTERPARTY CUSTOMER_MODEL_SCORE CUSTOMER_SURVEY CUSTOMER_X_EVENT CUSTOMER_X_SEGMENT HOUSEHOLD_MODEL_SCORE INDIVIDUAL_CUSTOMER SURVEY_ANSWER

Tables Loaded in Wave 10 CONTACT CORPORATE_CUSTOMER_OWNER CORPORATE_CUST_MEASURE COUNTERPARTY_ASSOC COUNTERPARTY_CREDIT_ASSESSMENT COUNTERPARTY_CREDIT_BEHAVIOR COUNTERPARTY_INSURANCE COUNTERPARTY_X_SEGMENT FINANCIAL_INSTRUMENT INDIVIDUAL_CUSTOMER_ADDRESS INDIVIDUAL_CUST_MEASURE INDIVIDUAL_CUST_X_INTEREST IND_CUSTOMER_CASH_FLOW


Tables Loaded in Wave 11 BOND_INSTRUMENT CASHFLOW_INSTRUMENT COMMODITY_INSTRUMENT CONTACT_HISTORY CREDIT_DERIVATIVE_INSTRUMENT CREDIT_FACILITY EQUITY_INSTRUMENT FINANCIAL_INSTRUMENT_ISSUE FINANCIAL_INST_CREDIT_ASSESS FRA_INSTRUMENT FUND_INSTRUMENT FX_INSTRUMENT GUARANTEE INVESTMENT_PRODUCT OPTION_INSTRUMENT RECEIVABLES_INSTRUMENT REPO_INSTRUMENT RESPONSE RISK_FACTOR_X_FINANCIAL_INST SECURITIZATION_INSTRUMENT SWAP_IRS_CCS_INSTRUMENT

Tables Loaded in Wave 12 CASHFLOW_PAYMENT CASHFLOW_RESETS CREDIT_FACILITY_CREDIT_ASSESS FINANCIAL_POSITION RECEIVABLES RECEIVABLES_ASSET

Tables Loaded in Wave 13 NETTING_SET

Tables Loaded in Wave 14 FINANCIAL_ACCOUNT FINANCIAL_INSTRUMENT_VAR

56 Appendix 1

Tables Loaded in Wave 15 ACCOUNT_CREDIT_ASSESSMENT ACCOUNT_EVENT CORE_BANKING_ACCOUNT CREDIT_CARD_ACCOUNT CUSTOMER_ACCOUNT_SCORE CUSTOMER_X_FINANCIAL_ACCOUNT FINANCIAL_ACCOUNT_ADDRESS FINANCIAL_ACCOUNT_CHNG FINANCIAL_ACCOUNT_INQUIRY FINANCIAL_ACCOUNT_PAYMENTS FINANCIAL_ACCOUNT_RESETS FINANCIAL_ACCOUNT_RESTRICTION FINANCIAL_ACCOUNT_ROLE FINANCIAL_ASSOCIATE_X_ACCOUNT FINANCIAL_COLLATERAL FINANCIAL_PRODUCT_ACCOUNT GL_ACCOUNT_ASSOC HEDGE INVESTMENT_ACCOUNT LEASE_ACCOUNT LOAN_ACCOUNT MORTGAGE_ACCOUNT PROTECTION_INSURANCE_ACCOUNT RETIREMENT_ACCOUNT SPECIFIC_PROVISION TRAVEL_INSURANCE_ACCOUNT

Tables Loaded in Wave 16 BANK_CARD CORE_ACCT_REGULAR_PAYMENT CORE_ACCT_TRANSACTION CORE_BANKING_ACCOUNT_CHNG CREDIT_CARD_ACCOUNT_CHNG CREDIT_CARD_PROTECTION CREDIT_CARD_STMT CREDIT_CARD_TRANSACTIONS CREDIT_RISK_MITIGANT FINANCIAL_ACCOUNT_ROLE_ADDRESS INVESTMENT_TRANSACTION LIFE_INSURANCE_ACCOUNT LOAN_ACCOUNT_CHNG LOAN_TRANSACTION MORTGAGE_ACCOUNT_CHNG MORTGAGE_ADDITIONAL_BORROWING MORTGAGE_TRANSACTION MOTOR_INSURANCE_ACCOUNT


Tables Loaded in Wave 16 PROPERTY_INSURANCE_ACCOUNT PROTECTION_INSURANCE_ACCT_CHNG PROTECTION_INSURANCE_CLAIM PROTECTION_PREMIUM_PAYMENT RETIREMENT_ACCOUNT_TRANSACTION TRAVEL_CLAIM TRAVEL_INSURANCE_ACCOUNT_CHNG TRAVEL_PREMIUM_PAYMENT WIRE_TRANSFER

Tables Loaded in Wave 17 ACCOUNT_CREDIT_RISK_MITIGANT COUNTERPARTY_X_CR_MITIGANT CREDIT_DERIV_CR_MITIGANT CREDIT_FACILITY_CR_MITIGANT DEFAULT_EVENT EXPOSURE_CR_MITIGANT_RANK FINANCIAL_ACCOUNT_APPLICATION FINANCIAL_POSITION_CR_MITIGANT LIFE_CLAIM LIFE_PREMIUM_PAYMENT MOTOR_CLAIM MOTOR_INSURANCE_ACCOUNT_CHNG MOTOR_INSURANCE_COVERAGE MOTOR_PREMIUM_PAYMENT MOTOR_VEHICLE PROPERTY_CLAIM PROPERTY_INSURANCE_ACCT_CHNG PROPERTY_INSURED_ITEM PROPERTY_PREMIUM_PAYMENT

58 Appendix 1

Tables Loaded in Wave 18 APPLICATION_SCORE FINANCIAL_ACCOUNT_APPLICANT OUTBOUND_COMMUNICATION RECOVERY

Tables Loaded in Wave 19 APPLICANT_CASH_FLOW CREDIT_BUREAU_INFO

2 SAS Detail Data Store for Banking Table Types

Transactional Tables ...................................................................................................................................... 59 Master Tables .................................................................................................................................................. 59 Reference Tables .............................................................................................................................................. 60 Intersection Tables .......................................................................................................................................... 60 Association Tables ........................................................................................................................................... 60

Transactional Tables Transactional tables capture events that occur at a particular point in time, or that have a beginning and an ending time. Examples of transactional tables include:

LOAN_ACCOUNT_TRANSACTION COMMODITY_QUOTE CUSTOMER_ACCOUNT_SCORE

Master Tables Master tables are reference tables that contain a significant number of rows (for example, over 100 rows) and are frequently updated. Master tables differ from reference tables, which contain a limited number of rows and are relatively static. Master tables typically include the following columns:

an _RK column for a retained key that remains the same for different versions of the same instance of an entity

a VALID_FROM_DTTM column and a VALID_TO_DTTM column that distinguish different versions of the same instance

an _ID column that identifies the source ID a SOURCE_SYSTEM_CD column for the source system code that identifies where the _ID column comes from

Examples of master tables include:

FINANCIAL_PRODUCT CUSTOMER COUNTERPARTY

A P P E N D I X

60 Association Tables Appendix 2

Reference Tables Reference tables contain code value definitions. Reference tables are non-volatile and have a restricted set of values. Reference tables include the following columns:

a _CD column for the code a _DESC column for the code description a VALID_FROM_DTTM column and a VALID_TO_DTTM column to track changes

Examples of reference tables include:

ACCOUNT_STATUS ASSET_TYPE

Intersection Tables Intersection tables resolve many-to-many relationships between tables. For example, an employee might be associated with more than one internal organization, and an internal organization contains multiple employees. Examples of intersection tables include:

EMPLOYEE_X_INTERNAL_ORG CUSTOMER_X_ACCOUNT

Association Tables Association tables establish hierarchy relationships or other relationships between rows in a table. Association tables have an _ASSOC suffix. Association tables include a column that refers to the base rows and a column that refers to the parent row. For example, the INTERNAL_ORG table includes the INTERNAL_ORG_RK column and the PARENT_INTERNAL_ORG_RK column. The INTERNAL_ORG_ASSOC_TYPE_CD column indicates the kind of hierarchy that this row represents. For example, the TYPE code could indicate that the hierarchy is an employee-reporting relationship, such as departments rolling up into divisions. Or, the TYPE code could indicate departments rolling up into different divisions for financial reporting purposes. All association tables have an ASSOC_TYPE table that defines the relationships between parent and child rows in the table. Examples of association tables include:

INTERNAL_ORG_ASSOC PRODUCT_CATEGORY_ASSOC

61

3 Standard Data Types and Naming Conventions

The banking DDS data models use a consistent naming convention that includes an abbreviation formula and the use of class codes on the columns. Class codes indicate the type of data that is contained in the field (such as code, indicator flag, and so on). The banking DDS data models use a set of domains to define consistency in data types and lengths.

Table 3.1 Standard Data Types

Domain Data Type

Length Applicable Class Codes

Comment/Example

Identifier Character 32 ID identifier from the data source system

Small Code Character 3 CD short length codes, such as ADDRESS_TYPE_CD

Medium Code Character 10 CD medium length codes, such as EXCHANGE_SYMBOL_CD

Large Code Character 20 CD long length codes, such as POSTAL_CD

Standard Count Code Numeric 6 CNT standard counts, such as AUTHORIZED_USERS_CNT

Name Character 40 NM proper name, such as LAST_NM, FIRST_NM

Short Length Text Character 20 TXT short, free-form text

Medium Length Text Character 100 TXT, DESClong, free-form text and descriptions that are associated with code tables

Indicator Field Character 1 FLG binary indicatory flag (Y or N)

Surrogate Key Numeric 10 RK, SK generated surrogate keys

Currency Amount Numeric 18,5 AMT standard currency amount

Rates and Percentages Numeric 9,4 PCT, RT for example, exchange rates

DateTime Date DT, DTTM accommodate dates and date/time

A P P E N D I X

62 Error! No text of specified style in document. Chapter 3

4 Data Model Notation

Reading the Relationship Notation ................................................................................................................ 63 Things to Keep in Mind ........................................................................................................................... 63

Understanding a One-to-One Relationship ................................................................................................... 64 Understanding a One-to-Many Relationship................................................................................................. 64

Reading the Relationship Notation Two tables can have different types of relationships between them. The notation between the tables in the displayed or printed data model describes how they are related. This appendix describes how to read this notation. Note: The entire banking DDS data dictionary for the SAS Detail Data Store for

Banking is available in the solution’s installation package.

Things to Keep in Mind The banking DDS data model uses Information Engineering notation as it

is represented in the Computer Associates AllFusion ERwin Data Modeler. The ellipses in the columns indicate that additional columns exist, but are

not necessary to explain the notation. A key sign in the column indicates that the column represents the primary

key of the table. These columns are needed to uniquely identify rows in the table. For example, in Figure 4.2, EMPLOYEE_ID is the primary key of the table.

The letters “FK” indicate that the column serves as the foreign key. A foreign key is a column or a combination of columns that refers to a primary key in another table. However, in the case of a recursive relationship, a foreign key could refer to a primary key in the same table. In Figure 4.3, DEPARTMENT_ID in the EMPLOYEE table serves as a foreign key in the DEPARTMENT table.

A P P E N D I X

64 Understanding a One-to-Many Relationship Appendix 4

Understanding a One-to-One Relationship In a one-to-one relationship between two tables, the relationship is a non-identifying relationship, which means that it is optional in both directions. The same notation is used when you specify an optional relationship and when you identify relationships in a one-to-one relationship.

Figure 4.1 One-to-One Relationship

Understanding a One-to-Many Relationship Figures 4.2, 4.3, 4.4, and 4.5 illustrate a one-to-many relationship between a department and an employee. Each department can contain multiple employees; however, subtle differences exist in these one-to-many relationships. In Figure 4.2, an optional relationship exists between a department and employee in both directions. An EMPLOYEE table does not have to have a DEPARTMENT_ID and a DEPARTMENT table does not have to have an EMPLOYEE_ID. This optional relationship is indicated by the circles on both sides of the relationship.

Figure 4.2 Optional Relationship between the EMPLOYEE Table and the DEPARTMENT Table

In Figure 4.3, a DEPARTMENT table must contain one or more EMPLOYEE tables. This requirement is indicated by the hash mark on the EMPLOYEE side of the relationship.

Data Model Notation Understanding a One-to-Many Relationship 65

Figure 4.3 DEPARTMENT Table Must Contain an EMPLOYEE Table

In Figure 4.4, the relationship is the same as in Figure 4.2, except that an EMPLOYEE table must contain a DEPARTMENT_ID. This requirement is indicated by the hash mark on the DEPARTMENT side of the relationship.

Figure 4.4 EMPLOYEE Table Must Contain a DEPARTMENT_ID

In Figure 4.5, an identifying relationship exists between the tables, which is indicated by the solid line between the DEPARTMENT table and the EMPLOYEE table. This identifying relationship means that an EMPLOYEE table cannot exist outside the context of a DEPARTMENT table. In identifying relationships, the primary key of the parent table becomes part of the primary key of the child table.

Figure 4.5 Identifying Relationship between Tables

66 Understanding a One-to-Many Relationship Chapter 4

5 Table and Column Changes

Overview........................................................................................................................................................... 67 New Tables....................................................................................................................................................... 67 New Columns................................................................................................................................................... 68 Other Changes ................................................................................................................................................. 74

Overview

This appendix lists the changes that were made to the previous release (release 2.2) of the banking DDS to create the current release (release 2.3). New tables were added to the banking DDS, new columns were added to many of the tables, several changes were made to keys, and other miscellaneous changes were made.

New Tables

The following list contains the new tables that were added. All columns in these tables are new.

BUSINESS_ENTITY

CONFIGURATION_X_INTERNAL_ORG

DEBIT_CREDIT_CODE

GL_ACCOUNT_ASSOC

GL_ACCOUNT_ASSOC_TYPE

INTERNAL_ORG_ADDRESS

INTERNAL_ORG_FINANCIAL_DATA

REGULATORY_PD

REGULATORY_PD_SET

A P P E N D I X

68 New Columns Appendix 5

New Columns

The following list contains the new columns that were added to existing tables.

Table Column ANALYTICAL_MODEL CR_MITIGANT_ADJUSTED_FLG BUSINESS_ENTITY BUSINESS_ENTITY_ID VALID_FROM_DTTM BUSINESS_ENTITY_DESC VALID_TO_DTTM EFFECTIVE_FROM_DTTM EFFECTIVE_TO_DTTM INTERNAL_ORG_RK PROCESSED_DTTM CONFIGURATION CURRENCY_CD REGULATORY_PD_SET_ID CONFIGURATION_X_INTERNAL_ORG CONFIGURATION_ID INTERNAL_ORG_RK EFFECTIVE_FROM_DTTM EFFECTIVE_TO_DTTM VALID_FROM_DTTM VALID_TO_DTTM PROCESSED_DTTM COUNTERPARTY DOMESTIC_CURRENCY_CD CREDIT_FACILITY ADJUSTMENT_TO_EXPOSURE_AMT EXPOSURE_AT_DEFAULT_AMT CREDIT_FACILITY_GROUP PARENT_CREDIT_FACLTY_GROUP_RK ADJUSTMENT_TO_EXPOSURE_AMT DEBIT_CREDIT_CODE DEBIT_CREDIT_CD VALID_FROM_DTTM LANGUAGE_CD VALID_TO_DTTM DEBIT_CREDIT_DESC PROCESSED_DTTM FINANCIAL_ACCOUNT COUNTERPARTY_RK FINANCIAL_POSITION EXPOSURE_AT_DEFAULT_AMT ADJUSTMENT_TO_EXPOSURE_AMT MARGIN_BALANCE_AMT FINANCIAL_ACCOUNT_APPLICANT SOURCE_SYSTEM_CD FINANCIAL_ACCOUNT_CHNG EXPOSURE_AT_DEFAULT_AMT ADJUSTMENT_TO_EXPOSURE_AMT

Table and Column Changes New Columns 69

Table Column FINANCIAL_REPORTING_DATA ELIGC_INSTR_NONINN_LIMIT_AMT ELIGC_INSTR_INN_LIMIT_AMT ELIGC_PAID_UP_CAPITAL_AMT ELIGC_SHARE_VALUE_AMT ELIGC_SHARE_PREMIUM_AMT ELIGC_INSTR_OTHER_AMT ER_RESERVES_AMT ER_MINORITY_INTEREST_AMT ER_INSTR_NONINN_LIMIT_AMT ER_INSTR_INN_LIMIT_AMT ER_IP_CURR_YEAR_AMT ER_IP_CURR_YEAR_VAL_AMT ER_ML_INCOME_CURR_YEAR_AMT ER_ML_INCOME_CURR_YEAR_VAL_AMT ER_ML_IP_CURR_YEAR_AMT ER_ML_IP_CURR_YEAR_VAL_AMT ER_ML_IP_INC_SEC_AMT ER_VD_AFS_EQUITY_AMT ER_VD_AFS_EQUITY_ADJ_AMT ER_VD_AFS_RECEIVABLES_AMT ER_VD_AFS_RECEIVABLES_ADJ_AMT ER_VD_AFS_AMT ER_VD_AFS_ADJ_AMT ER_VD_FVO_FIN_LIAB_AMT ER_VD_FVO_FIN_LIAB_ADJ_AMT ER_VD_NONAFS_AMT ER_VD_NONAFS_ADJ_AMT ER_VD_PROPERTY_AMT ER_VD_PROPERTY_ADJ_AMT ER_VD_PPE_AMT ER_VD_PPE_ADJ_AMT ER_VD_ER_AMT ER_VD_OTHER_ADJ_AMT BR_FUND_AMT CSF_INSTR_NONINN_LIMIT_AMT CSF_INSTR_INN_LIMIT_AMT CSF_INSTR_IAS_AMT CSF_OTHER_AMT ODF_INTNGBL_ASSETS_AMT ODF_INSTR_NONINN_LIMIT_AMT ODF_INSTR_INN_LIMIT_AMT ODF_CSF_IAS_OTHER_AMT ODF_CSF_OTHER_AMT AOF_VD_AFS_ADJ_AMT AOF_VD_AFS_OTHER_ADJ_AMT AOF_VD_INVS_ADJ_AMT AOF_VD_PPE_ADJ_AMT AOF_VD_OTHER_ADJ_AMT AOF_REVAL_RESERVES_AMT


Table Column FINANCIAL_REPORTING_DATA AOF_VCR_STD_ADJ_AMT AOF_OTHER_AMT AOF_SID_INSTR_OTHER_AMT AOF_IRBP_EXCESS_AMT AOF_CSF_FUND_AMT AOF_COMMIT_CREDIT_INST_AMT AOF_FIX_TERM_SHARES_AMT AOF_LOAN_CAPITAL_AMT AOF_SUPPL_AMT AOF_EXCESS_LIMIT_SUPPL_AMT AOF_EXCESS_LIMIT_FUND_AMT AOF_CSF_DED_OTHER_AMT DOF_FUND_AMT DOF_ADDL_FUND_AMT DOF_HOLDINGS_10_CAPITAL_AMT DOF_SUBORD_CLAIM_AMT DOF_EXCESS_LIMIT_10_CAP_AMT DOF_INSTR_AMT DOF_INSTR_OTHER_AMT DOF_CSF_ORIGINAL_AMT DOF_SECU_EXPO_RWA_AMT DOF_IRB_PROV_SF_AMT DOF_QUAL_INTEREST_NONFIN_AMT DOF_FREE_DELIV_AMT DOF_CSF_OTHER_AMT TOF_EXCESS_LIMIT_ADDL_AMT TOF_PROFITS_AMT TOF_ST_SUBORD_CAPITAL_AMT TOF_ILLIQUID_ASSEST_AMT TOF_EXCESS_LIMIT_SPCFC_AMT TOF_CSF_DED_AMT DTF_CSF_TOTAL_AMT DTF_INSURANCE_AMT M_IRBP_AMT M_IRBP_GEN_COLL_IMP_AMT M_IRBP_SPCFC_INDV_IMP_AMT M_IRBP_REVAL_RESERVES_AMT M_IRBP_EXPEC_LOSS_AMT M_LOAN_CAPITAL_AMT M_INITIAL_CAPITAL_REQM_AMT SETTLEMENT_RISK_AMT TCR_TRD_DEBT_INSTR_AMT TCR_EQUITY_AMT TCR_FOREIGN_EXCHANGE_AMT TCR_COMMODITIES_AMT CAPITAL_REQM_FIXED_AMT OCR_FLOOR_AMT OCR_INVESTMENT_45B_AMT OCR_CSF_OTHER_AMT


Table Column FINANCIAL_REPORTING_DATA M_SURPLUS_FUND_AMT M_SURPLUS_SOLV_IDX_RATIO_AMT IA_CAPITAL_AMT IA_CAPITAL_NEEDS_AMT GL_ACCOUNT_ASSOC GL_ACCOUNT_RK PARENT_GL_ACCOUNT_RK GL_ACCOUNT_ASSOC_TYPE_CD VALID_FROM_DTTM VALID_TO_DTTM ORDER_NO PROCESSED_DTTM GL_ACCOUNT_ASSOC_TYPE GL_ACCOUNT_ASSOC_TYPE_CD LANGUAGE_CD VALID_FROM_DTTM GL_ACCOUNT_ASSOC_TYPE_DESC VALID_TO_DTTM DEFAULT_GL_ACCOUNT_RK PROCESSED_DTTM INTERNAL_ORG_ADDRESS INT_ORG_ADDRESS_RK VALID_FROM_DTTM VALID_TO_DTTM INT_ORG_ADDRESS_ID INTERNAL_ORG_RK ADDRESS_TYPE_CD ADDRESS_LINE_1_TXT ADDRESS_LINE_2_TXT ADDRESS_LINE_3_TXT ADDRESS_LINE_4_TXT CITY_NM STATE_REGION_CD POSTAL_CD COUNTRY_CD NON_PHYSICAL_ADDRESS_FLG ADDRESS_QUALITY_CD DELIVERY_POINT_SUFFIX_CD PROCESSED_DTTM INTERNAL_ORG_FINANCIAL_DATA INTERNAL_ORG_RK VALID_FROM_DTTM VALID_TO_DTTM ANNUAL_REVENUE_AMT REVENUE_GROWTH_AMT GROSS_ANNUAL_SALES_AMT NET_SALES_REVENUE_AMT ANNUAL_OPERATING_REVENUE_AMT CAGR_OPERATING_REVENUE_AMT NON_OPERATING_REVENUE_AMT COST_OF_GOODS_SOLD_AMT COST_OF_SALES_AMT OPBDIT_AMT


Table Column INTERNAL_ORG_FINANCIAL_DATA ANNUAL_INTEREST_CHARGES_AMT INTEREST_FINANCE_CHARGES_AMT TOTAL_TERM_DEBT_P_AND_I_AMT LONG_TERM_DEBT_INT_EXPENSE_AMT DEPREC_NON_CASH_CHARGES_AMT OWNER_COMP_DRAWING_AMT GENERAL_OTHER_EXPENSE_AMT EBIT_AMT PRIOR_PERIOD_ADJUSTMENTS_NO EXTRA_ORDINARY_INCOME_AMT EXTRA_ORDINARY_EXPENSES_AMT GROSS_PROFIT_AMT PBT_AMT PAT_AMT ACCRETION_TO_RESERVES_AMT NET_CASH_ACCRUALS_AMT FREE_CASH_FLOW_AMT GROSS_OPERATING_MARGINS_AMT NET_INCOME_AMT GROSS_MARGIN_AMT NET_MARGIN_AMT RETURN_ON_CAPITAL_EMPLOYED_AMT RETURN_ON_EQUITY_AMT DEBT_SERVICE_COVERAGE_RT AVG_DEBT_SERVICE_COVERAGE_RT INTEREST_COVERAGE_RT AVERAGE_INTEREST_COVERAGE_RT RENT_AMT TOTAL_ASSETS_AMT FIXED_ASSETS_AMT CURRENT_ASSETS_AMT NET_TRADE_REC_AMT INVENTORY_AMT OTHER_CURRENT_ASSETS_AMT MARKETABLE_SECURITIES_AMT ASSETS_SECURITIZED_AMT CASH_AND_BANK_BALANCES_AMT INTANGIBLE_ASSETS_AMT REVALUATION_RESERVES_AMT OTHER_ASSETS_AMT TOTAL_LIABILITY_AMT TOTAL_DEBT_AMT LONG_TERM_DEBT_AMT LONG_TERM_DEBT_EXPO_AMT SHORT_TERM_DEBT_AMT SHORT_TERM_DEBT_EXPO_AMT SECURED_DEBT_AMT UNSECURED_DEBT_AMT NOTES_PAYABLE_AMT


Table Column INTERNAL_ORG_FINANCIAL_DATA TRADE_PAYABLE_AMT SHORT_TERM_PAYABLES_AMT CURRENT_LTD_AMT OTHER_CURRENT_LIABILITY_AMT TOTAL_CURRENT_LIABILITY_AMT OTHER_LIABILITY_AMT CONTINGENT_LIABILITIES_AMT TRADE_CREDITORS_AMT FOREIGN_CURR_EXPOS_TRANS_AMT FOREIGN_CURR_TRANS_EXPOS_AMT FOREIGN_OTHER_EXPOS_AMT CHARGED_OFF_AMT CURRENT_VALUE_SECURITY_AMT NET_WORTH_AMT ADJUSTED_NET_WORTH_AMT LIQUIDITY_RT CURRENT_RT TOTAL_EQUITY_NET_WORTH_AMT RETAINED_EARNINGS_AMT ASSET_BETA_NO MARKET_CAPITALIZATION_AMT MARKET_CAPITALIZATION_DT DIVIDEND_PAYOUT_AMT DIVIDEND_PAYOUT_RATIO_PCT EARNINGS_PER_SHARE_AMT PRICE_EARNINGS_RATIO_RT DEBT_EQUITY_RT LT_DEBT_EQUITY_RT ST_DEBT_EQUITY_RT DAYS_PAYABLE_RT DAYS_RECEIVABLE_RT DAYS_FINISHED_GOODS_INV_RT DAYS_WORK_IN_PROG_GOODS_RT KNOWN_BANK_RELATIONS_CNT CURRENCY_CD EQUITY_CAPITAL_AMT CREDIT_BUREAU_SCORE_NO CREDIT_BUREAU_SCORE_DT TAX_BRACKET_CD LIQUID_NET_WORTH_AMT BANKRUPTCY_FILED_DT BANKRUPTCY_STATUS_CD REPORTED_ON_DT EFFECTIVE_FROM_DTTM EFFECTIVE_TO_DTTM PROCESSED_DTTM LOAN_TRANSACTION VALID_FROM_DTTM REGULATORY_LGD_SET REGULATOR_ID

74 Other Changes Appendix 5

Table Column REGULATORY_PD REGULATORY_PD_SET_ID REGULATORY_PD_NM PD_PCT REGULATORY_PD_DESC EFFECTIVE_FROM_DTTM EFFECTIVE_TO_DTTM PROCESSED_DTTM VALID_FROM_DTTM VALID_TO_DTTM REGULATORY_PD_SET REGULATORY_PD_SET_ID REGULATORY_DOC_TXT REGULATOR_ID EFFECTIVE_FROM_DTTM EFFECTIVE_TO_DTTM REGULATORY_PD_SET PROCESSED_DTTM VALID_FROM_DTTM VALID_TO_DTTM SECURITIZATION_POOL K_IRB_RT WEIGHTED_AVG_LGD_PCT WEIGHTED_AVG_COUPON_RT MAX_RISK_WEIGHT_PCT MIN_RISK_WEIGHT_PCT AVG_RISK_WEIGHT_PCT CRDT_ENHNC_INT_ONLY_STRIP_AMT INVESTORS_INTEREST_PCT

Other Changes The ACCOUNT_CREDIT_ASSESSMENT table was added to the Credit Risk subject area. The CAMPCODE column has been renamed CAMPAIGN_CD and the COMMCODE column

has been renamed COMMUNICATION_CD in the CAMPAIGN_COMMUNICATION table, CONTACT table, and RESPONSE table.

The CAMPAIGN_CD column length and the COMMUNICATION_CD column length were widened from 25 to 30 in the CAMPAIGN_COMMUNICATION table and CONTACT table.

The CAMPCODE column has been renamed CAMPAIGN_CD in the MARKETING_CAMPAIGN table.

The CAMPAIGN_CD column length was widened from 25 to 30 in the MARKETING_CAMPAIGN table.

The CAMPAIGN_CD column length was widened from 25 to 30 in the FINANCIAL_ACCOUNT table.

The COMMUNICATION_CD column length was widened from 25 to 31 in the FINANCIAL_ACCOUNT table.

The CHG_DIRECT_DEPOSIT_MTH_NO column length was changed to the Numeric(2) data type from the Integer data type in the CORE_BANKING_ACCOUNT table.

The BEST_DAY_OF_WK_TO_CNTCT_NO column length was changed to the Numeric(2) data type from the Integer data type in the INDIVIDUAL_CUSTOMER table.

Table and Column Changes Other Changes 75

The FIN_YEAR_NO column length was changed to the Numeric(6) data type from the VARCHAR(3) data type in the FINANCIAL_CAL_DATE table.

The INDUSTRY_CD column length was increased to VARCHAR(10) in the INDUSTRY table and the EXTERNAL_ORG table.

The EMPLOYER_INDUSTRY_CD column length was increased to VARCHAR(10) in the FINANCIAL_ACCOUNT_APPLICANT table and the INDIVIDUAL_CUSTOMER table.

The LANGUAGE table has been renamed CODE_LANGUAGE. The LIMIT table has been renamed RISK_LIMITS.

76 Other Changes Appendix 5

6 Banking DDS Deployment FAQ

Other Issues Question: Why does the banking DDS, release 2.3 specify Numeric(18,5) for currency amounts? Answer: The banking DDS, release 2.3 typically uses Numeric(18,5) as the specification for currency amounts. However, if the banking DDS is implemented in SAS, the upper limit on the floating-point precision is 15 decimal places. Although this could lead to a loss of decimal-place precision, the likelihood of this issue being encountered at a customer site is low. Should this issue occur, you could limit the input to a width of 15 with a precision of 3 decimal places – Informat(15,3). Because you would lose decimal-place precision, this solution should be weighed against the likelihood of encountering a problem with the data that is being loaded into the banking DDS.

A P P E N D I X

78 Other Issues Chapter 6

7 Deploying the Banking DDS on Oracle

Overview........................................................................................................................................................... 79 Prerequisites............................................................................................................................................. 79

Creating the Banking DDS Tables in Oracle ................................................................................................ 80 Registering Metadata ...................................................................................................................................... 81

Things to Keep in Mind ........................................................................................................................... 81 Using the Oracle Bulk Loader ........................................................................................................................ 81

The Object Spawner Setting for the Oracle Bulk Loader ...................................................................... 82

Overview

This appendix describes how to set up the banking DDS in an Oracle environment. To set up the banking DDS, you need the Oracle DDL and XML files for metadata registration. These files are available by request from SAS. Note: The instructions in this appendix have been tested on a Windows XP Service

Pack 2 machine with an Oracle (9.2.0.1.0) client and on a Windows 2000 Service Pack 4 server machine with an Oracle9i Database Enterprise Edition, Release 2 (9.2.0.1.0) server.

Prerequisites Complete the following before installing the banking DDS in Oracle:

To implement the banking DDS in Oracle, you need the Oracle DDL and XML files for metadata registration. These files are available by request from the SAS Customer Support Center at: http://support.sas.com. From this page, select Documentation Products & Solutions and select SAS Detail Data Store for Banking from the Select a Product menu. The files can be requested by submitting the DBMS Implementation Request Form under the Request Forms section of the SAS Detail Data Store for Banking Resource Center.

SAS/ACCESS Interface to ORACLE must be installed and running on the server and on all of the clients from where the banking DDS will be accessed directly. For more information, refer to documentation for SAS/ACCESS Interface to ORACLE.

The Oracle client has to be installed and the Oracle server name has to be added to the tnsnames.ora file. The Oracle client installation should have the SQL*Loader set up and the SQL*Loader client directory —C:\Oracle\orax\bin\ (where x is the Oracle version number) —should be on the command path.

A P P E N D I X

80 Creating the Banking DDS Tables in Oracle Appendix 7

SAS Data Integration Studio must be set up and functional. “Main Tasks for Installation and Setup” in the SAS Data Integration Studio User’s Guide outlines all of the required tasks prior to using SAS Data Integration Studio. These same tasks are required prior to loading some of the components of the banking DDS.

A SAS Metadata Server and a metadata repository must be operational. The Metadata Import-Export Tool (MIET) - a plug-in for SAS Data Integration

Studio - must be installed to register metadata. If the MIET plug-in is not available as part of the the solution’s installation package, please contact your SAS Support Consultant to gain access to this tool.

Creating the Banking DDS Tables in Oracle To create the banking DDS tables in Oracle, run the DDL, which instantiates the banking DDS physical model structure. The %ORDDLDDS macro creates the table definitions and has %INCLUDE statements that reference <tablename>.sas files that contain the CREATE TABLE statements required to instantiate the physical model structure. To create the Oracle DDS tables, do the following:

1. Set up the DDS LIBNAME using the Oracle library engine.

LIBNAME DDS ORACLE PATH=”Oracle Tns Entry” USER=”user name” PASSWORD=”Password” SCHEMA=”Banking DDS Schema”;

Suppose your Oracle schema name is bankdds, the user is scott, the password is tiger, and the Oracle TNS Entry machine is bankdb.acme.com. Your LIBNAME statement would look like the following:

LIBNAME DDS ORACLE PATH=”bankdb.acme.com” USER=”scott” PASSWORD=”tiger” SCHEMA=”BANKDDS”;

Note: In the example, the schema name is in uppercase. This is a SAS/ACCESS requirement.

2. Modify and submit the following %ORDDLDDS macro code:

/* Macro variables to be assigned: Fileloc: Assign fileloc macro parameter to point to the directory which contains the DDL create table statements contained in <tablename>.sas files. DTFMT: (Optional: Defaults to DATE9.) If international date values are needed, assign a new DTFMT= value, such as dtfmt=EURDFDEw. */

%include "<location_of_provided_macro>/orddldds.sas"; %orddldds(USER=,PASS=,PATH=,fileloc=<location_of_Oracle_DDL_folder>);

Note: When invoking the %ORDDLDDS macro, the FILELOC macro variable has to be assigned the folder where the Oracle DDL files are located. For example, if the Oracle DDL files are located under C:\BankingDDS\DDL\Oracle, then FILELOC has to be set to C:\BankingDDS\DDL.

Deploying the Banking DDS on Oracle Using the Oracle Bulk Loader 81

For the specific example in step 1, the macro code would look like the following:

%include “C:\BankingDDS\DDL\Oracle\orddldds.sas”;

%orddldds(USER=”scott”,PASSWORD=”tiger”,PATH=”bankdb.acme.com”,fileloc= C:\BankingDDS\DDL);

3. Verify that the tables were created properly by submitting the following SAS code:

proc datasets lib=DDS; quit;

The DATASETS procedure output can be compared with the banking DDS physical model structure.

The full set of banking DDS tables in Oracle that make up the banking DDS data model is now instantiated.

Registering Metadata Metadata registration information is stored as XML files and one file per table is registered in the metadata. The tables, library, and pre-created custom folders are available from the SAS Customer Support Center at http://support.sas.com and must be imported to the customer’s production repository using the MIET. The steps for importing are similar to the steps that are described in the “Registering Metadata” section of Chapter 5, “Creating and Registering the SAS Detail Data Store for Banking Tables.”

Things to Keep in Mind When creating the schema for the Oracle library engine, make sure that the schema name is in uppercase. The SAS/ACCESS engine reports an error for lowercase schema names.

Using the Oracle Bulk Loader When loading the banking DDS on Oracle, you can use the Oracle command SQLLDR for optimal loading. To bulk load tables using this command, set the BULKLOAD option to YES by performing the following steps in SAS Data Integration Studio:

1. Right-click on the table and select Properties.

2. Select the Physical Storage tab.

3. Click Table Options.

4. In the Table Options dialog box, enter BULKLOAD=YES under Option Value.

5. Click OK.

82 Using the Oracle Bulk Loader Appendix 7

Figure 7.1 Setting the BULKLOAD Option for a Table

Once the option has been set, the code that is generated by SAS Data integration Studio adds the BULKLOAD=YES option to the generated code for this table. This new code causes the Oracle bulk loader to be invoked when the job is run.

The Object Spawner Setting for the Oracle Bulk Loader The default configuration of the object spawner does not allow X commands from within a SAS session to be executed, which means that calls to the Oracle bulk loader (invoked by the SQLLDR command) are blocked by the object spawner. Blocking only happens if the ETL job is being run from within SAS Data Integration Studio. For development and test environments, you typically run ETL jobs from within SAS Data Integration Studio. As a result, the object spawner Startup script or service needs to be modified to add –ALLOWXCMD to the SET DEPENDS= line. For more information on invoking the object spawner and other options that you can add to its Startup script or service, refer to SAS Integration Technologies: Server Administrator's Guide. Note: For security reasons, do not add –ALLOWXCMD to the Startup script or service

in a production environment. Setting this option allows any host commands to be executed from application servers using the object spawner.

Glossary

AllFusion ERwin Data Modeler a visual data modeling tool that is used to create and maintain databases, data warehouses, and enterprise data models. The AllFusion ERwin Data Modeler helps to visually determine the proper data structure, key elements, and optimal design for the database.

analytical result a calculation that is a result of applying an analytic process. In the context of the banking DDS, an analytic result can be a cross-sell, up-sell, or customer-retention score, and can relate to an account, customer, or household.

attribute in entity-relationship modeling, an attribute is a property or a characteristic of an entity that can be stored as a data fact. In subject modeling, an attribute represents any characteristic that the modeler might choose to capture about a subject.

banking solution a SAS analytic solution that addresses banking-specific issues, including segmentation, customer retention, cross-sell, up-sell, credit scoring, campaign management, and strategic performance management.

business key also referred to as the natural key, the business key is the primary identifying data from the source system. A business key often goes back to the transactional system to investigate the source data.

data mart a subset of the data in a data warehouse. Typically, a data mart is designed to meet the needs of a particular department or set of users. A data mart can also be used to store the results of ad hoc queries or cross-subject analyses. A data mart is more limited in scope than a data warehouse, which typically contains information that is used by more than one department.

data source information that a user will extract, transform, and summarize in a detail data store. A data source can be in any format that SAS can read and on any supported hardware platform.

DDL (Data Definition Language) a language for describing and defining data and its relationships in a database. The banking DDS includes DDL to create the data objects that are part of the DDS architecture. DDL syntax is specific to the target environment, but largely governed by a set of SQL standards published by ANSI.

84 Glossary

DDLDDS a macro that includes the SAS files that are necessary to create tables that are used to instantiate the model.

denormalized a data object structure that has intentional data redundancy, most often done to improve query performance.

detail data (1) for multidimensional data sources, nonaggregated data. (2) for relational data sources, every record in a selected data source. Duplicate records can be either excluded or included.

detail data store (DDS) a set of tables, views, or files that contains factual information with minimal summarization. The DDS serves as a single version of the truth for the solution data marts and is the integration layer for SAS solutions.

dimension an aspect or perspective by which data can be accessed, selected, sequenced, grouped, filtered, and presented. Dimensions offer an intuitive way of organizing and selecting data for retrieval, exploration, and analysis.

entity a topic about which the business stores or plans to store data. An entity is a person, place, thing, concept, or event that represents a subject of business information.

ETL (extract, transform, and load) the process of (1) obtaining data from operational sources (the extract step), (2) cleansing and preparing data for import into the data warehouse (the transform step), and (3) importing the transformed data into the data warehouse (the load step).

ETL job a set of instructions that is used to specify ETL processes that are needed to create output.

external data data taken from sources outside the business, such as purchased mailing lists, customer profiles, competitor profiles, and marketing data. External data is also referred to as third-party data.

foreign key the primary key of one data structure that is placed into a related data structure to represent a relationship between those data structures. A foreign key resolves relationships and supports navigation among data structures.

information engineering (IE) a methodology that is used in entity-relationship modeling that uses its own notation for model diagrams.

intersection table a table that describes the relationships between two or more tables. For example, an intersection table could describe the many-to-many relationships between a table of users and a table of groups.

master table a reference table that usually contains a significant number of rows and is frequently updated.

Glossary 85

metadata a description or definition of data or information.

metadata repository a collection of related metadata objects, such as the metadata for a set of tables and columns that are maintained by an application. A SAS Metadata Repository is an example.

model an abstract representation of a real thing. A model provides a structured mechanism to present information in an explicit and non-ambiguous manner.

natural key See business key.

non-temporal data non-time-sensitive or non-event data, such as a customer or financial account. Master data and reference data are examples of non-temporal data. Non-temporal data can become temporal data if a process starts to capture and date or time-stamp how then underlying data changes over time, such as an account name change.

normalize to transform similar data to the same, or equivalent, units so that the data values can be compared.

physical model represents the detailed specification of what is physically implemented.

primary key a set of one or more attributes that uniquely identifies a single occurrence in a data structure, such as a row in a table. In a logical model, every entity (or meter) has a primary key.

reference data provides the context of business events. Reference data values are not determined by the same business events for which they provide context.

reference table contains the code value definitions. A reference table is non-volatile (rarely updated) and has a restricted set of values.

relationship an important, real-world association among entities that has meaning as business information. In a subject model, relationships illustrate the most visible business associations among subjects. In a physical data model, relationships are implemented via foreign keys. For example, the relationship "a customer can open one or more accounts" is implemented by placing the customer primary key as a foreign key on all financial account records for that customer.

retained key a numeric column in a dimension table that is combined with a begin-date column to make up the primary key. During the update of a dimensional target table, source rows that contain a new business key are added to the target. A key value is generated and added to the retained key column and a date is added to the begin-date column. When a source row has the same business key as a row in the target, the source row is added to the target, including a new begin-date value. The retained key of the new column is copied from the target row.

86 Glossary

slowly changing dimension (SCD) a technique for tracking changes to dimension table values in order to analyze trends. For example, a dimension table named Customers might have columns for Customer ID, Home Address, Age, and Income. Each time the address or income changes for a customer, a new row could be created for that customer in the dimension table, and the old row could be retained. This historical record of changes could be combined with purchasing information to forecast buying trends and to direct customer marketing campaigns.

source an input to an operation. Source is often referred to as source data.

source system identifier See business key or natural key.

subject a high-level view of a topic of business interest that is equivalent to both a global data class and a class of data entities.

surrogate key a single-part, artificially established identifier for an entity. A surrogate key is a special case of derived data - one where the primary key is derived. A common way of deriving surrogate key values is to assign integer values sequentially.

target an output location of an operation.

temporal data event data that occurs at a particular date and time, such as an account inquiry. Temporal data is often referred to as time-sensitive data.

transactional table a table that captures events or occurrences that occur at a particular date and time or have a beginning time and an ending time.

transformation a metadata object that specifies how to extract data, transform data, or load data into data stores. Each transformation that is specified in a process flow diagram generates or retrieves SAS code. User-written code can be specified in the metadata for any transformation in the process flow diagram.

Your Turn

We welcome your feedback.

• If you have comments about this book, please send them to [email protected]. Include the full title and page numbers (if applicable).

• If you have comments about the software, please send them to [email protected].

SAS® Publishing delivers!Whether you are new to the workforce or an experienced professional, you need to distinguish yourself in this rapidly changing and competitive job market. SAS® Publishing provides you with a wide range of resources to help you set yourself apart.

SAS® Press Series Need to learn the basics? Struggling with a programming problem? You’ll find the expert answers that you need in example-rich books from the SAS Press Series. Written by experienced SAS professionals from around the world, these books deliver real-world insights on a broad range of topics for all skill levels.

s u p p o r t . s a s . c o m / s a s p r e s sSAS® Documentation To successfully implement applications using SAS software, companies in every industry and on every continent all turn to the one source for accurate, timely, and reliable information—SAS documentation. We currently produce the following types of reference documentation: online help that is built into the software, tutorials that are integrated into the product, reference documentation delivered in HTML and PDF—free on the Web, and hard-copy books.

s u p p o r t . s a s . c o m / p u b l i s h i n gSAS® Learning Edition 4.1 Get a workplace advantage, perform analytics in less time, and prepare for the SAS Base Programming exam and SAS Advanced Programming exam with SAS® Learning Edition 4.1. This inexpensive, intuitive personal learning version of SAS includes Base SAS® 9.1.3, SAS/STAT®, SAS/GRAPH®, SAS/QC®, SAS/ETS®, and SAS® Enterprise Guide® 4.1. Whether you are a professor, student, or business professional, this is a great way to learn SAS.

s u p p o r t . s a s . c o m / L E

SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. ® indicates USA registration. Other brand and product names are trademarks of their respective companies. © 2008 SAS Institute Inc. All rights reserved. 474059_1US.0108

http://support.sas.com/saspress

http://support.sas.com/publishing

http://support.sas.com/LE

sas detail data store for banking 2 - dartmouth...

Documents