Financial Services Jhe financial services industry encompasses a wide variety of businesses, including credit card companies, brokerage firms, and mortgage providers, This chapter will focus primarily on retail banks given that most readers have some degree of personal familiarity with this type of financial institution. A full-service bank offers a breadth of products, including checking accounts, savings accounts, mortgage loans, personal loans, credit cards, and safe deposit boxes. This chapter begins with a very simplistic schema. We then explore several schema extensions, including handling of the bank’s broad portfolio of heterogeneous products that vary significantly by line of business. ‘As we embark on a series of industry-focused chapters, we want to remind you that they are not intended to provide full-scale industry solutions. While Various dimensional modeling techniques will be discussed in the context of a given industry, the techniques certainly are applicable to other businesses. If you don’t work in financial services, you still need to read this chapter. If you ‘do work in financial services, remember that the schemas in this chapter should not be viewed as complete. Oe Chapter 9 discusses the following concepts: ‘= Dimension triage to avoid the “too few dimensions” trap 1m Household dimensions ‘Associating individual customers with accounts using a bridge table ‘= Multiple minidimensions in a single fact table 199200 banding of facts for reporting purposes. ‘m Point-in-time balances using transaction data 1m Handling heterogeneous products, each with unique metrics and dimension attributes, across lines of business Banking Case Study ‘The bank's initial goal is to build the capability to better analyze the bank’s accounts. Users want the ability to slice and dice individual accounts, as well as the residential household groupings to which they belong. One of the bank’s major objectives 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, we develop the following set of requirements: 1. Business users want to see 5 years of historical monthly snapshot data on every account. 2. Every account has a primary balance. The business wants to group differ- ent 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 dif- ferent from product to product. 4, Every account is deemed to belong to a single household. There is a sur- prising amount of volatility in account-household relationships due to changes in marital status and other life-stage factors. 5. In addition to the household identification, users are interested in demo graphic information as it pertains to both individual customers and households. In addition, the bank captures and stores behavior scores relating to the activity or characteristics of each account and household. Dimension Triage Based on the business requirements just listed, the grain and dimensionality of the initial model begin 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 declaration, we initially envision a design with only twodimensions—month and account. These two foreign keys form the fact table primary key, as shown in Figure 9.1. 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, While this schema accurately represents the many-to-one and many-to-many relationships in the snapshot data, it does not adequately reflect the natural business dimensions. Rather than collapsing everything into the huge account dimension table, additional analytic dimensions such as product and branch mirror the instinctive way that banking users think about their busi- nesses. These supplemental dimensions provide much smaller points of entry to the fact table. Thus they address both the performance and usability objec- tives of a dimensional model. Finally, given that the master account dimen- sion ina big bank may approach 10 million members, we worry about type 2 slowly changing dimension (SCD) effects mushrooming this huge dimension into something unworkable. The product and branch attributes are conve- nient groups of attributes to remove from the account dimension in order to cut down on the type 2 SCD effects. Later in this chapter we'll squeeze the changing demographics and behavioral attributes out of the account dimen- sion for the same reasons. ‘The product and branch dimensions are two separate dimensions because there is a many-to-many relationship between products and branches. They both change slowly but on different rhythms. Most important, business users think of them as basic, distinct dimensions of the banking business. In general, most dimensional models end up with between 5 and 15 or so dimensions. If we find ourselves at or below the low end of this range, we should be suspicious that dimensions may have been left out of the design inadvertently. In this case we should consider carefully whether any of the fol- lowing kinds of dimensions are appropriate supplements to a draft dimen- sional mode: ‘Month Dimension | [Monthly Account Snapshot Fact] [Account Dimension ‘Month End Date Key (PK) Month End Date Key (FX) 11 account Key (PK) Month Attributes ‘Account Key (FR) ‘Account Attributes Primary Month Ending Balance | | Product Attrbutes Household attsbutes Status Attributes Branch Altnbutes Figure 9.1 Balance snapshot with too few dimensions.