Ameriprise Auto & Home Insurance
Client STAR - Reporting
System Design Document
Version 1.0
Ameriprise Financial, Inc., 707 Second Ave South, Minneapolis, MN - 55474
Sep 2007
CSP Reporting
SDD - SSAD ver. 1.0
Warning
This is a hard copy of a document maintained on electronic media. It may not be the latest
version. Kindly ascertain the latest version from the Document Master List available with the
Project Manager.
Internal Use Only
Page 2 of 26
CSP Reporting
SDD - SSAD ver. 1.0
DOCUMENT RELEASE NOTICE
Document Details:
Name
Version No.
Description
Release Date
System Design
Document
1.0
SDD document for CSP
Reporting
Revision Details
Action taken
(Add / Del / Chg)
Section No.
Page No.
Revision
description
This document and any revised pages are subject to document control. Please keep them upto-date using the release notices from the distributor of the document.
Approved by:
Date:
Authorized by:
Date:
Internal Use Only
Page 3 of 26
CSP Reporting
SDD - SSAD ver. 1.0
DOCUMENT REVISION LIST
Customer Name & Dept.
: AAH & Financial Dept
Project
: CSP Reporting
Document Name
: Low Level Design – Source to Staging
Release Notice Reference (for release):
Revision
No.
Revision
Date
(mm/dd/yyyy)
Section
No.
Page
No.
Revision
Description
Internal Use Only
Change type
(add/modify/
delete)
Rationale
for
change
Release
Notice
Reference
Page 4 of 26
CSP Reporting
SDD - SSAD ver. 1.0
PREFACE
Purpose of this Document
The purpose of this document is to provide complete design arrangement from Source to Staging.
This document will help in meeting the following needs:
 To translate the data from Phoenix databases into staging design specifications
which will be used to develop the mappings.
 To serve as the basis for mutual understanding between the designer and the
developer.
Intended Audience
The designers and developers of the system intend this document for use.
This document intends its use for the following audience.



Ameriprise Reporting Management
CSP Reporting Developers
Client Star Business Analysts and DBAs
Related Documents / References
The following documents have been referred for preparation of this LLD document.
Sr. No
1.
2.
3.
4.
5.
6.
7.
8.
Document Title and Version No.
CSP_Reporting_System
Requirements Specification
CSP_Reporting_ETL_User
Requirements Specification
CSP_Reporting_ETL_User
Requirements Specification
CSP - Reporting - Architecture V1
0
CSP - Reporting - Conceptual
Data Model V1.0
CSP - Reporting - Logical Data
Model V1.0
CSP_Reporting_System Design
Document
Phoenix NBQ data model
Description
This is the System Requirements
Specifications Document
This is the ETL User requirements
Specifications Document
This is the Reports User requirements
Specifications Document
The High Level Architecture Document
Conceptual Data Model
Logical Data Model
High Level Document
Data Model – Phoenix
Acronyms and Abbreviations
The following acronyms and abbreviations have been used in this document.
Acronym/ Abbreviation
AAH
CSP
DBA
ETL
Description
Ameriprise Auto & Home Insurance
Client Star Program
Database Administrator
Extraction Transformation and Load
Internal Use Only
Page 5 of 26
CSP Reporting
Acronym/ Abbreviation
HLD
LLD
NA
NRD
NRE
RRS
SME
SDD - SSAD ver. 1.0
Description
High Level Design
Low Level Design
Not Applicable
New reporting Database
New Reporting Environment
Report Requirements Specification
Subject Matter Expert
Organization of this Document
The document is organized into sections, which are applicable for design of an application. The
document is structured to contain






Section 1 – Contains overview of the design, including scope, assumptions and
dependencies
Section 2 – Details on this section is covered as part of the High Level design document
Section 3 – Details on this section is covered as part of the High Level design document
Section 5 – Contains the detailed Database design and the entities involved. This
contains the mapping rules and the transformations applied on the data from source
before loading it on the staging layer.
Section 6 – Details on this section is covered as part of the High Level design document
Section 9 – Details on this section is covered as part of the High Level design document
Sections 4, 7 and 8 from the AQMS template are not relevant for design of the system in scope.
Internal Use Only
Page 6 of 26
CSP Reporting
SDD - SSAD ver. 1.0
CONTENTS
1.
INTRODUCTION .................................................................................................................. 9
1.1
1.2
1.3
1.4
1.5
1.6
1.7
2.
SCOPE OF THE LOGICAL DESIGN .......................................................................................... 9
DESIGN OBJECTIVES AND PRINCIPLES ................................................................................... 9
SYSTEM ARCHITECTURE ...................................................................................................... 9
HARDWARE ENVIRONMENT ................................................................................................ 10
SOFTWARE ENVIRONMENT ................................................................................................. 10
NETWORK ENVIRONMENT .................................................................................................. 10
ASSUMPTIONS, CONSTRAINTS AND DEPENDENCIES ............................................................. 10
OVERVIEW - APPLICATION ARCHITECTURE ............................................................... 12
2.1
2.2
3.
APPLICATION ARCHITECTURE ............................................................................................. 12
HIGH-LEVEL PHYSICAL DATABASE MODEL .......................................................................... 12
KEY DESIGN CONCEPTS................................................................................................. 13
3.1
3.2
3.3
3.4
4.
FUNCTIONAL DESIGN ......................................................................................................... 13
INFRASTRUCTURE DESIGN ................................................................................................. 13
PERFORMANCE EXPECTATIONS .......................................................................................... 13
APPLICATION SECURITY ..................................................................................................... 13
MODULE OVERVIEW ........................................................................................................ 14
4.1
MODULE NAME .................................................................................................................. 14
4.1.1
Purpose and Functionality ....................................................................................... 14
4.1.2
Main Functions ......................................................................................................... 14
4.1.3
Module Context Diagram ......................................................................................... 14
4.1.4
High-level Entity Model (Intra-module) .................................................................... 14
4.1.5
Menu Design ............................................................................................................ 14
4.1.6
Screen Design ......................................................................................................... 15
4.1.7
Reports/ Queries ...................................................................................................... 15
4.1.8
Procedures / Batch Processes Overview ................................................................ 15
4.1.9
System / External Interfaces .................................................................................... 15
5.
DATABASE DESIGN ......................................................................................................... 16
5.1
5.2
5.3
5.4
5.5
5.6
6.
ENTITY TYPES ................................................................................................................... 16
DATA EXTRACTION ............................................................................................................ 16
TRANSFORM AND LOAD...................................................................................................... 16
CARDINALITY RULES .......................................................................................................... 19
ERROR VALIDATION ........................................................................................................... 19
TYPES OF TRANSFORMATIONS ........................................................................................... 19
DATA MIGRATION STRATEGY........................................................................................ 21
6.1
6.2
7.
STRATEGY ........................................................................................................................ 21
DATA MIGRATION PROCESS FLOW ..................................................................................... 21
INPUT- OUTPUT SPECIFICATIONS ................................................................................. 22
7.1
7.2
7.3
7.4
7.5
8.
INPUT DESCRIPTIONS ........................................................................................................ 22
OUTPUT DESCRIPTIONS ..................................................................................................... 22
HELP FACILITIES................................................................................................................ 22
PROGRAM DEFINITIONS ..................................................................................................... 22
INTERNAL INTERFACES....................................................................................................... 22
COMPONENT INTEGRATION STRATEGY ...................................................................... 23
8.1
COMPONENT LIST .............................................................................................................. 23
Internal Use Only
Page 7 of 26
CSP Reporting
8.2
8.3
9.
SDD - SSAD ver. 1.0
COMPONENT INTEGRATION SEQUENCE ............................................................................... 23
COMPONENT INTEGRATION PROCEDURE ............................................................................ 23
OPERATIONAL CONTROLS ............................................................................................ 24
THIS SECTION IS COVERED AS PART OF THE HLD. .......................................................................... 24
9.1
STARTUP AND SHUTDOWN ................................................................................................. 24
9.2
AUDIT AND RECOVERY ....................................................................................................... 24
9.3
RESTART .......................................................................................................................... 24
9.4
BACKUP STRATEGY ........................................................................................................... 24
9.5
FALLBACK STRATEGY ........................................................................................................ 24
9.6
MANUAL PROCEDURES ...................................................................................................... 24
9.7
SERVICE MANAGEMENT DISCIPLINES .................................................................................. 24
10.
GLOSSARY OF TERMS .................................................................................................... 25
APPENDIX A: ................................................................................................................................ 26
Internal Use Only
Page 8 of 26
CSP Reporting
SDD - SSAD ver. 1.0
1. Introduction
Ameriprise Auto & Home Insurance is in the process of moving from the Phoenix Policy
Administration system to the Fiserv system to sustain the aggressive growth, support future
business and improve the overall client experience. The current reporting process reports data
from a copy of the Phoenix production database. Phoenix system will be decommissioned but the
existing reports must be produced from FiServ system without the loss of any quality.
For a period of time both Phoenix and FiServ will be operational, the report must be produced
using the data from both the systems.
A New Reporting Environment will be implemented to capture data from different source system
(Phoenix, FiServ) and store in a repository. The repository will then act as a single source of data
to meet the reporting needs.
This document captures the design of the staging layer for the Reporting Environment.
1.1 Scope of the Logical Design
The scope involves the design of the Staging Layer for the Reporting Environment and is
inclusive of:


Data Mapping - Mapping rules and logic for transformation of data from Phoenix system to
the New Reporting Environment,
Designing overall ETL process - Design of the staging ETL process including type of
transformations needed, audit process, error handling within the staging layer and the
identification of the source elements for each of the elements on the staging layer.
1.2 Design objectives and principles
The following design objectives and principles have been considered for the reporting design



The new system will be designed in such a manner that it can support the reporting needs
from both the existing Phoenix system and the Fiserv system until the existing Phoenix
system is decommisioned.
The new reporting database will be designed for optimal performance and the pain areas
withing current reporting system will be addressed as far as possible.
The design is such that most of the transformations will be taken care of in the staging layer
and the data model in staging will be close to the business needs.
1.3 System Architecture
Refer to the HLD for the details.
Internal Use Only
Page 9 of 26
CSP Reporting
SDD - SSAD ver. 1.0
1.4 Hardware Environment
Refer to the HLD for the details.
1.5 Software Environment
Refer to the HLD for the details.
1.6 Network Environment
The pre-existing AAH network will be utilized for this project.
1.7 Assumptions, Constraints and Dependencies
Assumptions
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
The Staging layer will be updated based on a truncate and load strategy.
Data Mapping sheet has been taken as the base for data source identification in this
document. All mappings are based on this.
For the lookup values: In case of similar values between Phoenix and Fiserv, a union
will be taken for the set of values from both. But for most lookups, Fiserv values are
configurable and it is assumed that the set of values as used in Phoenix will be
configured in Fiserv too.
The scope of the verification and validation rules is limited to the existing rules being
handled in Phoenix reporting processes.
PRDR Data extraction and data loading between the source and staging will be
batch process.
database is assumed to be the only source for Phoenix data for staging.
Claims data will not be available in the staging layer.
Source data received from Fiserv and Phoenix are assumed to be correct. No
additional data validation will be required.
History data migration to NRE will be limited to the data available in current PRDR
database.
Initially the load process for phoenix source is full data refresh and for FiServ source
is increment load. Once the Phoenix system is decommissioned the FiServ source
load process will change to full data refresh.
The Operational controls are assumed to mimic the existing procedures as far as
possible.
Dependencies
1.
2.
3.
4.
The extraction strategy for a small percentage of Auto elements (8%) is not yet
defined as it will depend on the Auto design decision of where to keep these data
and how it can be accessed. Based on this the Fiserv to staging mappings are not
covered as part of this document and will be covered when Auto configuration is
complete.
A high-level SLA for the load window has been defined in this design document but
it may undergo changes based on the decision of scheduling of the Fiserv SPL jobs
and the back-up creation process in the RE.
Prompt sign off and feedback from End-users and SME on the documents and
design related clarifications.
Reporting Design and development will be complete way ahead of the completion of
Auto and Home development, this will lead to reconsideration of design based on
design changes that impact the reporting design.
Internal Use Only
Page 10 of 26
CSP Reporting
5.
SDD - SSAD ver. 1.0
Data Elements for RE from Fiserv and Phoenix should be finalized by AAH during
the ETL design phase, since this is still in progress Cognizant will proceed with the
data inventory that is currently available after RQA analysis.
Internal Use Only
Page 11 of 26
CSP Reporting
SDD - SSAD ver. 1.0
2. Overview - Application Architecture
2.1 Application Architecture
Refer HLD for the details.
2.2 High-level Physical Database Model
The elements on the staging data base model are based on the Phoneix sources and their entilty
relationships The PDM naming convention is dervied from the standard naming convention which
is attached in the Appendix A.
Internal Use Only
Page 12 of 26
CSP Reporting
SDD - SSAD ver. 1.0
3. Key Design Concepts
The key design concepts involves the design of the staging database from the existing Phoenix and
Fiserv Data to generate reports. There will be a unified reporting environment from where reports for
business users can be generated. The document focuses on the mapping details and data flow from
source to staging layer on the NRE.
3.1 Functional Design
The key functional design concepts covered includes:




Design of the database model for Staging
Design of the ETL process
Design of Operational Controls
Design of support processes like Load Auditing and Error Handling on the staging layer
3.2 Infrastructure Design
This section is covered as part of HLD.
3.3 Performance Expectations
This section is covered as part of the HLD.
3.4 Application Security



Validate input data by developing input checks to counter out of range, invalid chracters
in datafield etc.
Use certified encryption algorthims coming from trusted sources for encrypting data
Include error-handling and show user-friendly messages instead of system-generated
message
Internal Use Only
Page 13 of 26
CSP Reporting
SDD - SSAD ver. 1.0
4. Module Overview
This section is more relevant for an online application project and does not have relevance to
the design of New reporting Environment as this will be a consolidated data repository and will
not consist of modules or online screens.
4.1 Module Name
4.1.1
Purpose and Functionality
NA
4.1.2
Main Functions
NA
4.1.3
Module Context Diagram
NA
4.1.4
High-level Entity Model (Intra-module)
NA
Table Name/Description
Field Name
Field
Length
Null / Not Allowed Values
Null
Field
Length
Asc / Desc
Primary Key /
Foreign Key
Remarks
Index Name/Description
Field Name
Remarks
Storage Requirements
Table / Index
Name
Present VolumeGrowth per
annum
Record Size
Storage Required
4.1.5 Menu Design
NA
Internal Use Only
Page 14 of 26
CSP Reporting
SDD - SSAD ver. 1.0
4.1.5.1
Screen Navigation and Main Menus
NA
4.1.5.2 Functionality Matrix
Menu Option
Function
4.1.6 Screen Design
4.1.6.1 Screen Name / ID and Description
NA
Field
Prompt
Field name
Table Name
Mandatory /
Optional
Type
Input
/Output
ValidationsRemarks
& Error
Messages
4.1.6.2 Screen Layout
NA
4.1.7 Reports/ Queries
NA
4.1.7.1 Report Name / ID and Description
NA
4.1.7.2 Report Layout
NA
4.1.8 Procedures / Batch Processes Overview
NA
4.1.9 System / External Interfaces
NA
4.1.9.1 Interface / Flat File Structure and Description
NA
Internal Use Only
Page 15 of 26
CSP Reporting
SDD - SSAD ver. 1.0
5. Database Design
The database design consists of both the Auto and Home related data elements modeled as to be
present in the staging layer. The staging layer has been designed to mimic the target New Reporting
Database so that both the sources can be synced up in the same layer before further processing.
The ER diagram is attached below. This document must be opened through ER Studio.
<Pls attach the latest version after review>
The key design features of the Logical Data Model are:
1) The data type has been designed keeping in consideration the value expected in each of the
attributes as against the source datatypes as there are two different source systems involved
with different datatypes in most cases.
2) For most attribute of code type, the data type has been assigned as Integer, assuming a
lookup table will be created for each and the lookup on Integers will be faster than on
Varchars.
3) For each category of attributes, a consistent datatype has been assumed throughout entities.
5.1 Entity Types
The attached spreadsheet captures the details for all the entities to be present in this database
design, their attributes, data types, nullability and the primary and foreign keys defined.
Attachment
<Let us attach this sheet just before delivery so that we give the latest sheet in here>
5.2 Data Extraction
The proposed application architecture framework consists of data flowing from two sources.
The production database used for reporting is taken as the base for RE from the Phoenix side.
The oracle database PRDR - loaded with data is one of the sources to the staging layer. The data
pull from fiserv is still in discusion and we are going with the data extract from Phoenix and not
FiServ as of now.
<Reshu/Jasdeep please let us know what is the extraction rules for extracting the incremental
load from PRDP for PHXADM and INTADM schema>
5.3 Transform and Load
Data from the Phoenix sources will be mapped to the target tables defined in section 5 above.
Load to each target table will be a mapping. Each session will have only one mapping. Each
mapping has 3 pipelines.
1. The first pipleline values the table level audit details on to the LOAD_AUDIT table. The
pipleine values
Internal Use Only
Page 16 of 26
CSP Reporting
SDD - SSAD ver. 1.0
a. Session ID; a string of mapping name and the date example: <mapping
name_date>
b. Target Table name
c. Session start date and time
2. The second pipeline values the target tables in the staging layer after applying the
transformations on the source data.
3. The last pipeline values the closing values of the load audit table LOAD_AUDIT on the
staging schema. The details updated are
a. The Session End Date and Time
b. Number of records inserted from source to target
c. Status
The status is updated from “Started” to "Completed with Success" and "Completed with
Failure" based on the status of session completion.
The mapping, session and workflow naming convention followed will be:
For Phoenix to staging jobs:
Mapping - m_phx_stg_<target table name>_<version number>
Session - s_m_phx_stg _<target table name>_<version number>
WorkFlow - wf_phx_stg _<target table name>_<version number>
For Fiserv to staging jobs:
Mapping - m_fis_stg_<target table name>_<version number>
Session - s_m_fis_stg _<target table name>_<version number>
WorkFlow - wf_fis_stg _<target table name>_<version number>
The version number is the current date in the format YYYYMMDD. The mapping and
session names and the target tables that are valued by these mappings are available in
the table below.
Target Table on
Staging
ACCIDENT VIOLATION
Mapping Name
m_phx_stg_accd_violation_<version
number>
Session Name
s_m_phx_stg_accd_violation_<version
number>
ADVISOR
m_phx_stg_advisor_<version number>
s_m_phx_stg_advisor_<version number>
AGENCY
m_phx_stg_agency_<version number>
m_phx_stg_area_office_<version
number>
s_m_phx_stg_agency_<version number>
s_m_phx_stg_area_office_<version
number>
m_phx_stg_auto_<version number>
m_phx_stg_call_history_<version
number>
m_phx_stg_communication_info_<version
number>
s_m_phx_stg_auto_<version number>
s_m_phx_stg_call_history_<version
number>
s_m_phx_stg_communication_info_<version
number>
DISCOUNT SURCHARGE
m_phx_stg_coverage_<version number>
m_phx_stg_disc_surcharge_<version
number>
s_m_phx_stg_coverage_<version number>
s_m_phx_stg_disc_surcharge_<version
number>
DRIVER
m_phx_stg_driver_<version number>
s_m_phx_stg_driver_<version number>
EMPLOYEE
m_phx_stg_employee_<version number>
m_phx_stg_form_history_<version
number>
m_phx_stg_general_acct_info_<version
number>
s_m_phx_stg_employee_<version number>
s_m_phx_stg_form_history_<version
number>
s_m_phx_stg_general_acct_info_<version
number>
m_phx_stg_home_<version number>
m_phx_stg_home_endorse_<version
number>
s_m_phx_stg_home_<version number>
s_m_phx_stg_home_endorse_<version
number>
AREA OFFICE
AUTO
CALL HISTORY
COMMUNICATION INFO
COVERAGE
FORM HISTORY
GENERAL ACCOUNT
INFO
HOME
HOME ENDORSEMENT
Internal Use Only
Page 17 of 26
CSP Reporting
SDD - SSAD ver. 1.0
m_phx_stg_instlmnt_dtl_<version
number>
m_phx_stg_instlmnt_info_<version
number>
s_m_phx_stg_instlmnt_dtl_<version
number>
s_m_phx_stg_instlmnt_info_<version
number>
MUNICIPALITY ADDRESS
m_phx_stg_mortgage_<version number>
m_phx_stg_municipality_<version
number>
m_phx_stg_municipality_addr_<version
number>
s_m_phx_stg_mortgage_<version number>
s_m_phx_stg_municipality_<version
number>
s_m_phx_stg_municipality_addr_<version
number>
PERSON
m_phx_stg_person_<version number>
s_m_phx_stg_person_<version number>
POLICY
m_phx_stg_policy_<version number>
m_phx_stg_pol_comments_<version
number>
m_phx_stg_pol_prem_term_grp_<version
number>
s_m_phx_stg_policy_<version number>
s_m_phx_stg_pol_comments_<version
number>
s_m_phx_stg_pol_prem_term_grp_<version
number>
m_phx_stg_prem_dtl_<version number>
m_phx_stg_prem_item_dtl_<version
number>
m_phx_stg_recreation_veh_<version
number>
m_phx_stg_rep_lisence_info_<version
number>
m_phx_stg_response_track_<version
number>
m_phx_stg_term_acct_smry_<version
number>
m_phx_stg_transaction_info_<version
number>
s_m_phx_stg_prem_dtl_<version number>
s_m_phx_stg_prem_item_dtl_<version
number>
s_m_phx_stg_recreation_veh_<version
number>
s_m_phx_stg_rep_lisence_info_<version
number>
s_m_phx_stg_response_track_<version
number>
s_m_phx_stg_term_acct_smry_<version
number>
s_m_phx_stg_transaction_info_<version
number>
INSTALMENT DETAIL
INSTALMENT INFO
MORTGAGE
MUNICIPALITY
POLICY COMMENTS
POLICY PREMIUM TERM
GROUP
PREMIUM DETAIL
PREMIUM ITEM DETAIL
RECREATION VEHICLE
REPRESENTATIVE
LISENCE INFO
RESPONSE TRACKING
TERM ACCOUNT
SUMMARY
TRANSACTION INFO
The number of records inserted on the tables will be calculated using a mapping variable.
This mapping variable must be initalised to zeroes on the parameter file so that the audit
tables reflect the correct values of load on the session.
There will be 1 sessions per workflow. This will help in streamline loading of data on the
staging tables and also from a error handling and recovery perspective.
All staging tables will be loaded from sources before the loading onto the NRD
commences.
The loading by workflow will be as indicated below.
<I have no account for the Lookups and their loading pls include these here>
Session Name
s_m_phx_stg_accd_violation_<version
number>
Workflow
wf_phx_stg_accd_violation_<version
number>
s_m_phx_stg_advisor_<version number>
wf_phx_stg_advisor_<version number>
s_m_phx_stg_agency_<version number>
s_m_phx_stg_area_office_<version
number>
wf_phx_stg_agency_<version number>
s_m_phx_stg_auto_<version number>
s_m_phx_stg_call_history_<version
number>
s_m_phx_stg_communication_info_<version
number>
wf_phx_stg_auto_<version number>
s_m_phx_stg_coverage_<version number>
s_m_phx_stg_disc_surcharge_<version
number>
wf_phx_stg_coverage_<version number>
wf_phx_stg_disc_surcharge_<version
number>
s_m_phx_stg_driver_<version number>
wf_phx_stg_driver_<version number>
s_m_phx_stg_employee_<version number>
wf_phx_stg_employee_<version number>
wf_phx_stg_area_office_<version number>
wf_phx_stg_call_history_<version number>
wf_phx_stg_communication_info_<version
number>
Internal Use Only
Page 18 of 26
CSP Reporting
SDD - SSAD ver. 1.0
s_m_phx_stg_form_history_<version
number>
s_m_phx_stg_general_acct_info_<version
number>
wf_phx_stg_form_history_<version
number>
wf_phx_stg_general_acct_info_<version
number>
s_m_phx_stg_home_<version number>
s_m_phx_stg_home_endorse_<version
number>
s_m_phx_stg_instlmnt_dtl_<version
number>
s_m_phx_stg_instlmnt_info_<version
number>
wf_phx_stg_home_<version number>
wf_phx_stg_home_endorse_<version
number>
s_m_phx_stg_mortgage_<version number>
s_m_phx_stg_municipality_<version
number>
s_m_phx_stg_municipality_addr_<version
number>
wf_phx_stg_mortgage_<version number>
s_m_phx_stg_person_<version number>
wf_phx_stg_person_<version number>
s_m_phx_stg_policy_<version number>
s_m_phx_stg_pol_comments_<version
number>
s_m_phx_stg_pol_prem_term_grp_<version
number>
wf_phx_stg_policy_<version number>
wf_phx_stg_pol_comments_<version
number>
wf_phx_stg_pol_prem_term_grp_<version
number>
s_m_phx_stg_prem_dtl_<version number>
s_m_phx_stg_prem_item_dtl_<version
number>
s_m_phx_stg_recreation_veh_<version
number>
s_m_phx_stg_rep_lisence_info_<version
number>
s_m_phx_stg_response_track_<version
number>
s_m_phx_stg_term_acct_smry_<version
number>
s_m_phx_stg_transaction_info_<version
number>
wf_phx_stg_prem_dtl_<version number>
wf_phx_stg_prem_item_dtl_<version
number>
wf_phx_stg_recreation_veh_<version
number>
wf_phx_stg_rep_lisence_info_<version
number>
wf_phx_stg_response_track_<version
number>
wf_phx_stg_term_acct_smry_<version
number>
wf_phx_stg_transaction_info_<version
number>
wf_phx_stg_instlmnt_dtl_<version number>
wf_phx_stg_instlmnt_info_<version
number>
wf_phx_stg_municipality_<version number>
wf_phx_stg_municipality_addr_<version
number>
The system flag is an attribute on all tables.
5.4 Cardinality Rules
This section is applicable to the Staging to NRD and will be covered as part of the Staging
to NRD document.
5.5 Error Validation
The Unix Script Name to log the occurrence of errors for each job through the Workflow
process is <script name>
< this is yet to be filled>
5.6 Types of Transformations
As we are assuming the source will be only phoenix untill the auto desgin complete, the
Transformations applied in Source to Stage layer as mentioned below:
Internal Use Only
Page 19 of 26
CSP Reporting
1
Expression Transformation
2
Source Qualifier
Transformation
3
Joiner Transformation
SDD - SSAD ver. 1.0
This transofrmation is used to calculate the values in
a single row which performs the non-aggregate
calculations and tests the conditional statements.
The default transformation which is imported once
the source defintion is pulled in the work space and
used to join the homogenous source if necessary.
This transformation is used to join from two
heterogenous sources.
Internal Use Only
Page 20 of 26
CSP Reporting
SDD - SSAD ver. 1.0
6. Data Migration Strategy
6.1 Strategy
This is covered as part of the HLD.
6.2 Data Migration Process Flow
This is covered as part of the HLD.
Internal Use Only
Page 21 of 26
CSP Reporting
SDD - SSAD ver. 1.0
7. Input- Output specifications
The below section is more relevant to online type of applications and not for the Data repository
design which is the scope of this document. Some of the specific sub-sections in here can be argued
to be applicable, but it will be addressed as part of the low level design document with detailed
description of individual sources and targets.
7.1 Input Descriptions
NA
7.2 Output Descriptions
NA
7.3 Help Facilities
NA
7.4 Program Definitions
NA
7.5 Internal Interfaces
NA
Internal Use Only
Page 22 of 26
CSP Reporting
SDD - SSAD ver. 1.0
8. COMPONENT INTEGRATION STRATEGY
This section of the document is not relavent to the application developed. This will not be integrated
with any of the other componets developed as part of the CSP project instead will received data from
upstream systems such as Phoenix and Fiserv.
8.1 Component List
NA
8.2 Component Integration Sequence
NA
8.3 Component Integration Procedure
NA
Internal Use Only
Page 23 of 26
CSP Reporting
SDD - SSAD ver. 1.0
9. OPERATIONAL CONTROLS
This section is covered as part of the HLD.
9.1 Startup and Shutdown
9.2 Audit and Recovery
9.3 Restart
9.4 Backup Strategy
9.5 Fallback Strategy
9.6 Manual Procedures
9.7 Service Management Disciplines
Internal Use Only
Page 24 of 26
CSP Reporting
SDD - SSAD ver. 1.0
10. Glossary of Terms
Internal Use Only
Page 25 of 26
CSP Reporting
SDD - SSAD ver. 1.0
Appendix A:
Naming Convention Standards:
DA002 Data Naming
Standards And Guidelines.doc
Internal Use Only
Page 26 of 26