Data modeling. Presentation by – Anupama Vudaru, Phani Kondapalli Content by – Prathibha Madineni, Subrahmanyam Kolluri October 2010

Preface Agenda – Basics of Data Modeling, Insurance industry and Erwin Duration and timings – 4 days x 2 hrs Expectations – In-class, hands on and post session work Course contents – Divided into slides, videos and print outs Legends used – Post-session work – Attendees are expected to do hands-on home work assigned for the day

Contents Day 1 A.Data Modeling overview B.Data Modeling development life cycle C.Components of Data Modeling D.Data Modeling notations and design standards E.Case study – CDM overview Day 2 A.Conceptual data model B.Types of Data modeling C.Various tools available D.Developing CDM using Erwin E.Case study – LDM overview Day 3 A.Logical data model B.Developing LDM using Erwin C.Meta Data preservation for Design Considerations D.Dimensional Data Modeling E.Case study – PDM overview Day 4 A.Physical data model B.Logical Data Model vs Physical Data Model C.Developing PDM using Erwin D.Advanced Features of Erwin

A.Logical data model B.Developing LDM using Erwin C.Meta Data preservation D.Dimensional Data Modeling E.Case study – PDM overview Day 3

A. Logical Data Modeling 1.LDM is a more formal representation of the CMD. 2.Relational / dimensional theory is applied as per design decisions. 3.Normalization / de-normalization of data is taken care. 4.Like objects may be grouped into super and sub types. 5.Many-to-many relationships are resolved using associative entities. 6.Greater complexity is usually added as decisions about history maintained, logically unique keys, etc. 7.LDM can and should be, ‘proven’ by playing business transactions against it. 8.Need to concentrate on meta data preservation and documentation too. Example of Logical Data Model

B. Developing LDM using Erwin 1. Case study 1.Industry knowledge 2.Business requirements 3.Convert the subjects to entities 4.Convert the business verbs into relations 5.Identify the type of design – relational or dimensional 6.Identify the acceptable redundancy – normalization or de-normalization 7.Identify the techniques – star or snow flake 8.Identify the entity types – master:detail or fact:dimension 9.Identify the type of relationship 10.Indentify the attributes 11.Identify the keys

C. Meta data preservation around design consideration Entity level Definition: Properly define the entity using full English. Examples: —Give examples in full English, jus like the way a business analyst would talk. —Examples should contain information about a record. Excludes: Make a note of any excludes in terms of business. Business Purpose: Business purpose explanation for the existence and usage of the entity. Notes: Additional notes and descriptions. Attribute level Definition: Properly define the attribute using full English. Atomic attribute: Whether the values for this attribute will be a single word or multi word. Examples: Examples of kind of data that is stored in this attribute. Excludes: Situations where exceptions are allowed. Business Purpose: Business purpose explanation for the existence and usage of the attribute. Allowable Values: Type or count of values allowed for this attribute. Range: Range of values allowed for this attribute Other static rules: Any rules governing the data, consistency for the attribute. Notes: Additional notes and descriptions. 1.As a repository to revisit the design considerations. 2.As documentation to store and preserve the knowledge for future generations. 3.To use it to ship in the meta integration package to / from other applications as part of meta data management and lineage. Why? How?

D. Dimensional Data Modeling Star 1.De-Normalized with one fact table and multiple dimensions 2.Great performance with less joins 3.Can be used for analysis - OLAP Snow Flake 1.Partially normalized tables 2.Not optimized for performance due to increased joins 3.Not meant for OLAP, Instead works as source for Data Marts 4.We may build Data Marts Design Dimension 1.Details (Ex. City) 2.Levels 3.Hierarchical Relations 4.Each row may have multiple lines from fact table 5.More Columns (50 – 100) 6.Granular Design 7.Critical Column 8.Non-Transactional 9.Surrogate Key Fact 1.Less Columns 2.More Rows (Millions) 3.Numbers (No Text) 4.Added up (Summations) 5.Every row has corresponding dimension table relation 6.Measures (Ex: Qty_Sold / Amt_Sold) Components Dimensional Data Modeling

D. Dimensional Data Modeling FACTS Additive Facts: Facts that can be summed up through all of the dimensions in the fact table Semi-Additive Facts: Facts that can be summed up for some of the dimensions in the fact table, but not the others Non-Additive Facts: Facts that cannot be summed up for any of the dimensions present in the fact table Conformed Facts: A shared fact that is designed to be used in the same way across multiple data marts DIMENSIONS Slowly changing dimensions: Dimensions with data that changes slowly SCD Type 1 SCD Type 2 SCD Type 3 Rapidly changing dimensions: Dimensions with one or more attributes changing frequently Degenerate Dimensions: Derived from a fact Does not have its own dimension table Conformed Dimensions: Dimensions that are exactly the same or perfect subset of the other Role playing Dimensions: A dimension which is expressed differently in a fact table using views

D. Dimensional Data Modeling 4. Slowly changing dimensions Dimensions that change over time Categorized into three types: Type 1, Type 2 and Type 3 SCD Type2 Creating an another additional record Very useful for reporting purposes Creating new fields SCD Type3 Overwriting the old values SCD Type1

B. Developing LDM using Erwin 1. Case study 05. LDM