2 Insurancedata: formulating policies transactions, claims processing transactionsgoals: which coverages are profitablemeasure profit/time/covered item type, location, demography, sales rep, eventefficiency of claims handlingTODOMain schemas for policy creation and claims processingMonthly snapshotsHeterogeneous productsAnd demographic dimensions
3 Policy creationpolicy represents a set of coverages, possibly of specific itemsCoverages are the real products such as fire, flood, theft, car coverages, and policy is HEADER for set of coverages sol to the insured partytransactions:create/alter/cancel (with reason) policycreate/alter/cancel (with reason) coverage on covered itemrate/decline to rate coverageunderwrite/decline to underwrite policy
4 Dimensions dimensions: transaction date (TA entered into system), effective date (when TA legally effective), insured party (customer with multiple values is Big and dirty Dim), employee (agent, broker, rater, underwriter), coverage (deductibles or limits as facts), covered item (car, house,etc.), policy, transactioninsured party probably dirty dimension -- big dimensionpossible other facts, like deductible amountcovered item is also bigonly other fact is amount (variable meaning) (Fig 9.1, p 129)Grain is individual transaction
5 Claims processingClaims against a specific coverage and coverage item.Claimant may be new party for the insuranceFirst of all, open claimreserve set/adjusted to anticipate likely claim payoutsloss parties -- those involved in a claim, such as claimant, witnessesfor each claim, payments to “experts” (doctors, lawyers, inspectors) as well as claimantneed to identify responsible employee for each payment against an open claimtransactions: open/reopen/close claim, set/reset/close reserveadjuster inspection/interviewopen/close lawsuitmake/receive paymentsubrogate claim, …new dimensions: claimant, claim, third party (Fig 9.2, p 132)Employee is responsible here for authorizing paymentsclaimant and third party are dirty dimensions.
6 Policy and ClaimsTimings and counts of Tas of various types can be answered.And all other questions about the insurance companyBut, bcs of numerous Tas it is difficult to get the status of policy or claim at any given time point (Recall Subscription Business case)Same approach as in Cable TV example: monthly snapshot
7 Monthly snapshots for policies and claims snapshot view would require rolling all transactions forward from beginning of history...Remove dimensions: employee, claimant, third party, transactionnew dimension: status (just opened/reopened, claim pending, just closed)Policy schema has grain by coverage by covered item by month(Fig 9.3, p 134, 9.4 p 135)
8 Transaction schemas with heterogeneous products different coverages have very different sets of attributes (Fig 9.5, 9.6, p 136)custom covered item dimension able, custom coverage dim table for each typeNo custom fact table, only extending dimensions records.4-25 different sets of tablesSnapshot schemas with heterogeneous productsmany additional specific numeric facts --> a custom snapshot table for each coverage typeMinidimensions in insured party and covered itemneed accurate description of insured party and covered item both at creation time and current split changeable attributes in one or more minidimensions, directl linked to the fact table.minidimensions with all possibilities of changeable attributes efficiency of retrieving these attributes
9 Design summary Design summary “An appropriate design for a property and casualty insurance data warehouse is a short value chain consisting of policy creation and claims processing, where these two major processes are represented both by transaction fact tables and monthly snapshot fact tables. This data warehouse will almost certainly need to represent a number of heterogeneous products (coverage types) with appropriate combinations of core and custom dimension tables and fact tables. Finally, the large insured party and covered item dimensions will need to be decomposed into one or more minidimensions in order to provide reasonable browsing performance and in order to accurately track these slowly changing dimensions.”
11 Intro Previous examples: fact table with characteristic structure Key values: administrative elementsFacts as measurements taken at the intersection of key valuesDoes fact table always contain facts?
12 Factless Fact Tables no measured facts in some business processes Two Variation of Factless fact tableEvent tracking tables (events)Coverage tablesEg. course attendance. (Fig 10.1, p 144) "Which courses were the most heavily attended?“applications perform mostly counts, but no measured facts.Any one of the five keys can be used fort COUNT. (select Professor, count (date_key) …. Group by professor)
13 More event examples hospital patient treatment (Fig 10.2, p. 146) parties involved in an accident (Fig 10.3, p. 146)The Accident schema is able to represent complex accident with all involved partiesDP: “Events are often modeled by a fact table containing a number of keys, each representing a participating dimension in the event. Such event tables often have no obvious numerical facts associated with them, and hence are called factless fact tables.”
14 Coverage tables What about events that did not happen? Solution for the promotion questions building a coverage table which records which items are on promotion in which store at which time. (Fig 10.4, p 148)Coverage table is an inventory snapshot table for a chosen subset of the inventory (e.g. only promoted items need to be stored in coverage table)
15 Coverage tables cont.What about the question promoted items which did not sell? Movement Fact table is also required.2 behavioral group -- eg, items that sold on promotion from movement table and items on promotion from coverage tableSet difference between both groups is the answer modeling events that didn't happenPD: “Coverage tables are often tables of events that didn't happen. Coverage tables are usually factless in the same way as event tracking tables.”