1. Chapter 16. Insurance 서울시립대학교 인공지능 연구실 G201549028 조찬연 https://github.com/lovebube/ The Data Warehouse Toolkit 1 /35

2. Contents Insurance Case Study Policy Transactions Premium Periodic Snapshot More Insurance Case Study Claim Transactions/Snapshot Factless Accident Events Common Dimensional Modeling Mistakes 2 /35

3. Insurance Case Study Insurance has a complicated relation to its policyholder. Industry grow up very fast. Internal systems and processes already capture the bulk of the data required. But data is not integrated. So, integrated data need. 3 /35

4. Value Chain Issue policies, collect premium payments, and process claims. Organization is interested in better understanding the metrics spawned by each of these events. Value chain begins with a variety of policy transactions. And, also need to better understand the premium revenue associated with each policy on a monthly basis. This is key input into the overall profit picture. 4 /35

5. Draft Bus Matrix There are two core columns. Policy, Premium. Initial draft bus matrix 5 /35

6. Policy Transactions Coverages can be considered the insurance company’s products. Homeowner coverages include fire, flood, theft and personal liability. Agents sell policies to policyholders. There are two dates associated with each policy transaction. When the transaction was entered into the operational system. The policy transaction effective date(Legally takes effect). 6 /35

7. Policy Transactions There are three basic techniques for handling SCD. Simply overwrite the dimension attribute’s value. Make new surrogate key, and use it. Do not delete past value. Labeled historical for differentiation, to retain the old calssifications. Slowly Changing Dimensions 7 /35

8. Mini-dimensions for Large or Rapidly Changing Demnsions The policyholder dimension qualifies as a large dimension with more than 1 million rows. It is often important to accurately track content values for a subset of attributes. To split the closely monitored, more rapidly changing attributes in to one or more type 4 mini-dimensions directly linked to the fact table with a separate surrogate key. 8 /35

9. Policy Transaction Fact Table Policy transaction schema 9 /35

10. Heterogeneous Supertype and Subtype Products Insurance companies typically are involved in multiple, very different lines of business. The detailed parameters of homeowners’ coverages differ significantly from automobile coverages. And these both differ substantially from personal property coverage, general liability coverage, and other types of insurance. So, generalize the initial schema. 10 /35

11. Policy transaction schema with subtype automobile dimension tables. Policy transaction schema with subtype automobile dimension tables 11 /35

12. Premium Periodic Snapshot When designing the premium periodic snapshot table, you should strive to reuse as many dimensions from the policy transaction table as possible. Business management wants to know how much premium revenue was written each month, as well as how much revenue was earned. Two premium revenue metrics, written versus earned premium. 12 /35

13. Periodic premium snapshot schema 13 /35

14. Multiple Dimensions Bridge table for multiple drivers on a policy 14 /35

15. Policyholder reserve /p ɑ :ləsiho ʊ ldə(r) r ɪ z ɜ : r v/ noun. With respect to an insurance company, an amount representing the estimated payments to policyholders (as determined by actuaries) based on the types and terms of the various insurance policies issued by the company. 15 /35

16. More Insurance Case Study Background Before the insurance company pays any claim, there is usually an investigative phase. Examine the covered item and interview the claimant, policyholder, or other individuals involved. After the investigative phase, the insurance company issues a number of payments. 16 /35

17. Updated Insurance Bus Matrix Updated insurance bus matrix 17 /35

18. Claim Transactions The operational claim processing system generates a slew of transactions, including the following transaction task types: Open claim, reopen claim, close claim Set reserve, reset reserve, close reserve Adjuster inspection, adjuster interview Open lawsuit, close lawsuit Make payment, receive payment 18 /35

19. Detailed implementation bus matrix 19 /35

20. Claim transaction schema 20 /35

21. Claim Accumulating Snapshot Even with a robust transaction schema, there is a whole class of urgent business questions that can’t be answered using only transaction detail. Deliver time lags be the raw difference between two dates. 21 /35

22. Claim Accumulating Snapshot Schema 22 /35

23. Policy/Claim Consolidated Periodic Snapshot Policy/claim consolidated fact table 23 /35

24. Common Dimensional Modeling Mistakes to Avoid 24 /35

25. 10. Place Text Attributes in a Fact Table The descriptive textual attributes comprising the context of the measurements go in dimension tables You need to get text attributes off the main runway of the data warehouse and into dimension tables 25 /35

26. 9. Limit Verbose Descriptors to Save Space Our job as designers of easy-to-use dimensional models is to supply as much verbose descriptive context in each dimension as possible Make sure every code is augmented with readable descriptive text 26 /35

27. 8. Split Hierarchies into Multiple Dimensions A hierarchy is a cascaded series of many-to-one relationships. Business users understand hierarchies. Our job is to present the hierarchies in the most natural and efficient manner in the eyes of the users, not in the eyes of a data modeler 27 /35

28. 7. Ignore the Need to Track Dimension Changes Business users often want to understand the impact of changes on at least a subset of the dimension tables’ attributes. Likewise, if a group of attributes changes rapidly, you can split a dimension to capture the more volatile attributes in a mini-dimension 28 /35

29. 6. Solve All Performance Problems with More Hardware Aggregates, or derived summary tables, are a cost-effective way to improve query performance Choosing query-efficient DBMS software, increasing real memory size 29 /35

30. 5. Use Operational Keys to Join Dimensions and Facts Novice designers are sometimes too literal minded when designing the dimension Operational or intelligent key should be replaced with a simple integer surrogate key 30 /35

31. 4. Neglect to Declare and Comply with the Fact Grain All dimensional designs should begin by articulating the business process that generates the numeric performance measurements Exact granularity of that data must be specified Staying true to the grain is a crucial step in the design of a dimensional model 31 /35

32. 3. Use a Report to Design the Dimensional Model A dimensional model has nothing to do with an intended report The team should have focused on the measurement processes. The user’s requirements could have been handled with a well-designed schema for the atomic data 32 /35

33. 2. Expect Users to Query Normalized Atomic Data Data that has been aggregated in any way has been deprived of some of its dimensions Do not build a dimensional model with aggregated data and expect users and their BI tools to seamlessly drill down to third normal form data for the atomic details 33 /35

34. 1. Failed to Conform Facts and Dimensions The single most important design technique in the dimensional modeling arsenal is conforming dimensions Conformed dimensions allow teams to be more agile because they’re not re- creating the wheel repeatedly 34 /35

35. 35 /35