Learn Well Technocrafts

Business Requirement Document (BRD)

Overview
The Document Gives You A Complete View of Client Business and the Reason Why The Client Has To Go For A Data Warehouse. This Specification Document Gives You A Complete View of Data Warehousing Necessity of The Client and the Dimension Modeling That Should Be Done For Implementing The Data Warehouse. A Bank Service Offers A Breadth of Products, Including: Checking Accounts Savings Accounts Mortgage Loans Personal Loans Credit Cards Safe Deposit Boxes OR Lockers

The Type and Number of Products OR Services Provided By the Bank Can Be Much More and Will Differ From One Bank to the Other Bank. The Current Business Requirements Document (BRD) Starts with a Very Simplistic Schema Which is The First Stage of The System to Be Applied as a Pilot Project to the Client. Then The System Will Be Explored With Several Schema Extensions As The State Of The Requirements From The Client Are Increasing. The Extensional Schemas can include handling of The Bank's Broad Portfolio And A Set of Heterogeneous Products That Vary Significantly By Line of Business The Bank Actually Carries According To The Span of The System. The Current Document Will Guide You with Complete Awareness of Dimension Modeling That Becomes an Essentiality for Kick Starting the System for Analysis and Implementing Data Warehouse.

Note: In this project we will be covering many scenarios which we face in banking domain. As we move ahead with the project we request you to understand properly the Data-warehousing concepts, which will help you understand the actual working of a data-warehousing project using ETL tool.

Learn Well Technocrafts

Case Study
The Bank's Initial Goal is To Build the Capability for a Better Analysis of The Bank Accounts. The Banking User Wants The System With An Ability of Slicing And Dicing on The Individual Accounts, As Well As The Residential Household Groupings To Which The Customers OR Clients Belong. One of The Major Objectives of The Bank is To Market More Effectively by Offering Additional Products to Households That Already Have One OR More Accounts with the Bank. After Conducting Interviews with Managers and Analysts around the Bank Who Have Been Part of the Domain for Years, Following Set of Requirements is gathered: 1. Business Users Want To See Historical Snapshot of Customer Data. 2. Every Account Has A Primary Balance. The Business Wants To Group Different Types of Accounts in the Same Analyses And Compare Primary Balances. 3. Every Type of Account (Known As Products Within The Bank) Has A Set of Custom Dimension Attributes and Numeric Facts That Tend To Be Quite Different From Product To Product. 4. Every Account is deemed to Belong to a Single Household. There is A Surprising Amount of Volatility in Account-Household Relationships Due To Changes in Marital Status and Other Life-Stage Factors. 5. The Client Wants The System With Agent Analyses According To Their Location. 6. The Client Wants The System To Be Designed For Credit Transaction Analysis And Then A System That Can Load With This Data.

Work Environment

Learn Well Technocrafts

The Process
We Will Have Data Sources From Flat Files And Oracle Database. We Follow A Straight Data Loading Process To The Staging Area, Where We Will Be Using The Data Cleansing And Data Scrubbing Process Upon The Data And Then Load The Data into The Staging Area. Taking the Cleansed And Scrubbed Data From The Staging Area We Will Apply Business Logic Based on The Requirement And Then Load That Data into Data Warehousing. Both Repositories For Staging And Data Warehousing Will Be on The Same Oracle Database And Will Be Running on Different Instances. While Loading The Data into The Data Warehouse We Maintain A Common Database And Will Have Different Instances For Staging if Possible.

Dimension Overview
Based on The Business Requirements The Client Has Listed, The Grain And Dimensionality of The Initial Model Begins To Emerge. We Start With A Core Fact Table That Records The Primary Balances of Every Account At The End of Each Month. Clearly, The Grain of The Fact Table is One Row for Each Account at the End of Each Month. Based on This Grain of Declaration and Analysis, We Initially Envision a Design with Only Two Dimensions Month Dimension Account Dimension A Data-Centric Designer Might Argue That All The Other Description Information, Such As Household, Branch, And Product Characteristics, Should Be Embedded As Descriptive Attributes of The Account Dimension Because Each Account Has Only One Household, Branch, And Product Associated With it, All The Descriptive Attributes of The Relational OR Transactional System Will Never Come into The System of Data Warehouse As All The Attributes Do Not Play Key Role in The System For Business Intelligence. While The Current Schema Designed And Developed Accurately Represents Many-To-One And Many-To-Many Relationships in The Concept of Snapshot Data Taken From The Business System, It Does Not Adequately Reflect The Natural Business Dimensions That Are Important To The Core Data Warehouse. Schema Collapses Everything into A Huge Account Dimension Table, and Additional Analytic Dimensions Such As Product And Branch Mirror The Instinctive Way That Banking Users Think About Their Businesses. The Supplemental Dimensions Like Products, Branch Provide Much Smaller Points of Entry To The Fact Table. These Dimensions Address Both The Performance And Usability Objectives of A Dimensional Model. The Master Account Dimension in A Big Bank May Approach 10 Million Members, Then The Management And Maintenance Can Be Out of The Process Hence To Keep The System in Control We Should Follow Type 2 Slowly Changing Dimension (SCD) For Managing The Huge Dimension into Something That Can Look Like A Workable Process. The Product and Branch Attributes Are Convenient Groups of Attributes To Be Removed from Account Dimension in Order To cut Down the Side effects on The Type 2 SCD Implementation. Later well Squeeze the Changing Demographics and Behavioral Attributes Out of The Account Dimension For Managing The System To Be Under Operational Control At Information Management Level.

Learn Well Technocrafts

Account and Branch Dimensions Are Two Separate Dimensions Because There is A Many-To-Many Relationship between Accounts and Branches. They Both Change Slowly As The System of Transactions Get Applied But on Different Rhythms. Most Important, Business Users Think of Account and Branch Dimensions as Basic Fundamental Dimensions and They are Distinct Dimensions in The Banking Business. Based on Further Study of the Bank's Requirements, We Ultimately Choose the Following Dimensions For Our Initial Schema Date Dimension Account Dimension Employee Dimension Customer Dimension Transaction Dimension By Implementing The Process of Data Loading We Design The Intersection of All The Above Five Dimensions To Integrate As An Aggregated Fact Which Contains Monthly Snapshot And Records of The Primary Balance of The Customer Accounts And Any Other Metrics That Make Sense Across All Accounts. The Sensible Metrics That Should Fall Under The Aggregate of The Fact Will Be Considered on The Priority As Per The Issues And Demand of The Requirements Raised By The Client Such As Interest Paid, Interest Charged, And Transaction Count. Remember That Account Balances Are Just Like Inventory Balances in That They Are Non Additive Across Any Measure of Time. Instead, We Must Average The Account Balances By Dividing The Balance SUM By The Number of Months.

Transaction Dimension
The Transaction Dimension Consists of A Simple Transaction Hierarchy, that Describes The Entire Bank's Transactions, Including the Name of The Transaction, Transaction Type, And Transaction Category. The Need to Construct a Generic Transaction Categorization in The Bank is To Promote and Identify the State of Hierarchy in The System. The Bank Develops a Large Number of Customers Transaction Attributes for Each Transaction Type.

Account Dimension
The Account Status Dimension is A Useful Dimension to Record the Condition of The Account at the End of Each Month. The Account Status Dimension Records Whether the Account is Active OR Inactive OR Whether a Status Change Occurred during the Month. The Account Status Change Can Be A New Account Opening OR An Account Closure. Rather Than Whipsawing The Large Account Dimension OR Merely Embedding A Cryptic Status Code OR Abbreviation Directly in The Fact Table, We Treat Status As A Full-Fledged Dimension With Descriptive Status Decode Groupings And Status Reason Descriptions As Appropriate. In Many Ways We Could Consider The Account Status Dimension To Be Another Example of A Mini Dimension.

Learn Well Technocrafts

Customer Dimension
Rather Than Focusing Solely On the Bank's Accounts, Client Also Wants the Ability To Analyze The Bank's Relationship With A Customer. Client is Interested in Understanding The Overall Profile of a Customer The Magnitude of The Existing Relationship with the Customer What Additional Products Should Be Sold to the Customer These Demographic Attributes Can Change Over Time As We Might Suspect, And The Client Wants To Track The Changes. If The Bank Focuses on Accounts For Commercial Entities Rather Than Consumers, It Likely Has Similar Requirements To Identify And Link Corporate Families For Analysis. From The Bank's Perspective, A Customer May Be Comprised of Several Accounts And Individual Account Holders. Illustrative Example Consider John And Mary Smith As A Single Customer Household. John has A Checking Account Mary has A Savings Account. John And Mary Have a Joint Checking Account John And Mary Has a Credit Card John And Mary Has Mortgage with the Bank All Five of These Accounts Are Considered To Be A Part of The Same Smith Household Despite The Fact That Minor Inconsistencies May Exist in The Operational Name And Address Information. The Process of Relating Individual Accounts to Households OR the Commercial Business Equivalent of a Residential Household is Not to Be Taken Lightly. House Holding Requires The Development of Business Rules And Algorithms To Assign Accounts To Households. There Are Specialized Products And Services To Do The Matching Necessary To Determine Household Assignments. It is Very Common for a Large Financial Services Organization To Invest Significant Resources in Specialized Capabilities To Support its House Holding Needs. We Decide To Treat Them Separately Because of The Size of The Account Dimension And The Volatility of The Account Constituents Within A Household Dimension, As Referenced Earlier. In A Large Bank, The Account Dimension is Huge, With Easily Over 10 Million Rows That Group into Several Million Households. The Customer Dimension Provides A Somewhat Smaller Point of Entry into The Fact Table Without Traversing A 10-Million-Row Account Dimension Table. In Addition, Given the Changing Nature of the Relationship between Accounts and Customer, We Elect To Use the Fact Table to Capture the Relationship Rather Than Merely Including The Household Attributes on Each Account Dimension Row. In This Way We Avoid Using The Type 2 SCD Approach With The Large Account Dimension.

Learn Well Technocrafts

Other Dimensions of Concentration
The other Dimensions on Which the Client is Interested in Analysis Are Agent Dimension Loan Dimension Employee Dimension Agent Analyses Has To Be Maintained To Know About The Agent Information History Wise. The Agent Information Has To Be Maintained According To Their Locations. Transaction Information Has To Be Maintained For Credit Account Daily Wise. Transaction Information of Credit Should Be Collected in Complete And Employee Information Should Be Collected According To Their Location of The Bank.

Time Dimension
The Client So Far Has Restricted His Discussions to the Financial Services Chapter To Month-End Balance Snapshots as the Client Thinks This Level of Detail Typically is Sufficient for His Business Analysis. If Required according To Situations the Client is Interested To Supplement The Monthly-Grained Snapshot in Fact Table within A Second Fact Table That Provides Merely The Most Current Snapshot As of The Fort Nightly Update OR Perhaps is Extended To Provide Daily-Balance Snapshots For The Last Week OR Month. Clients Major Area of Concentration is What Will Be The Strategy if We Face The Requirement To Report An Account's Balance At Any Arbitrarily Picked Historical Point in Time? As Raised By The Situation. Creating Daily-Balance Snapshots For A Large Bank Over A Lengthy Historical Time Span Would Be Overwhelming Given The Density of The Snapshot Data. On A Practical Calculation if The Bank Has 10 Million Accounts, Daily Snapshots Translate into Approximately 3.65 Billion Fact Rows Per Year. Assuming That Business Requirements Already Have Driven The Need To Make Transaction Detail Data Available For Analysis, We Could Leverage This Transaction Detail To Determine An Arbitrary Point-in-Time Balance. To Simplify Matters, We Will Analyze the Account Transaction Fact Table Down To An Extremely Simple Design. The Transaction Type Key Joins to A Small Dimension Table of Permissible Transaction Types. The Transaction Sequence Number is A Continuously Increasing Numeric Number Running for Lifetime of the Account. The Final Flag Indicates Whether This is The Last Transaction for an Account on A Given Day. The Transaction Amount is Self-Explanatory. The Balance Fact is The Ending Account Balance Following the Transaction Event. To Manage the Demandable Situation we consider this as a Special Situation and Make it Possible by Integrating with a Surrogate Date Key.

Learn Well Technocrafts

The Date Key is A Set of Integers Running from 1 to N with a Meaningful, Predictable Sequence. We Assign Consecutive Integers To The Date Surrogate Key So That We Can Physically Partition A Large Fact Table Based on The Date. This Neatly Segments The Fact Table So That We Can Perform Discrete Administrative Actions on Certain Date Ranges, Such As Moving Archived Data To Offline Storage OR Dropping And Rebuilding Indexes.

Fact Overview
The Heterogeneous Transaction Technique that is discussed in The Previous Paragraphs is Suitable for Fact Tables in Which A Single Logical Row Contains Many Transaction-Specific Facts. On The Other Hand, Transaction-Grained Fact Tables Often Have A Single Fact That is Generically The Target of A Particular Transaction. In Such Cases The Fact Table Has An Associated Transaction Dimension That Interprets The Amount Column.