DataModel Session ELTP

8/8/2019 DataModel Session ELTP

http://slidepdf.com/reader/full/datamodel-session-eltp 1/128

© Mahindra Satyam 2009

Data Modeling



© Mahindra Satyam 2009 2

AGENDA

Time Topics to be Covered

9.30am to 11.00am

Over view of Data ModelNeed of Data ModelTypes of Data Model

Overview of Normalized Data Model and Case Study discussion

11.00am to 11.15 Tea Break

1.00pm to 2.00pm Lunch Break

2.00pm 3.30pm Dimensional Data Model (Cont…)

3.30 pm to 3.45pm Tea Break

3.45pm 5.15pm Dimension model with ERWin Demo

5.30pm to 6.30pm ERWin Demo with Q & A Session






What happens if you don’t have one?

Individual Data Store




What happens if you don’t have one?

Corporate Data Store




Where Data Models are used

Operational SystemsTraditional Applications designed to run the day-to-day business of the Enterprise

External Systems ***Data used within an Enterprise that is obtained from outside sources

Staging Areas ***Created to aid in the collection and transformation of data that is targeted for a DataWarehouse

Operational Data Store ***W. H. Inmon and Claudia Imhoff definition: ―A subject -oriented, integrated, volatile, currentvalued data store containing only corporate detailed data‖.

Data Warehouse (DW)W. H. Inmon definition: ―A subject -oriented, integrated, non-volatile, time-variant collection of dataorganized to support management needs‖.

Data Mart (DM)TDWI definition: ―A data structure that is optimized for access. It is designed to facilitate end -user analysisof data. It typically supports a single analytic application used by a distinct set of workers.‖

*** - Not discussed here


http://slidepdf.com/reader/full/datamodel-session-eltp 7/128 © Mahindra Satyam 2009 7

DATA MODELING TECHNIQUES

Entity Relationship Model (ERM)

Dimensional Data Model (DDM)



Where to use what?

Stages Types of Model

OLTP Normalized Data Model

StagingArea

Flat Table withoutconstraints

ODS Normalized model

Data marts Dimensional model



DW and role of E/R Modeling

Ralph Kimball says…….ER Models are too complicated for

end users to understandER Modeling/ normalizing only

suitable for OLTP or in data stagingarea since it eliminates redundancyResults in too many tables to be

easy to queryER models are optimized for update

activity not high performancequerying

Who is right?

Bill Inman says…….ER Model is suitable for datawarehouses because it isstable, and supports

consistency and flexibilityNormalized data is idealbasis for the design of theData Warehouse and theODS

May not be suitable for thedata mart, which dealsheavily with regular queryactivity and time-variant

analysis



Normalized Data Model



TOPICS TO BE COVERED…

ER Model Concepts☻ ER Diagrams - Notation

☻ Entities and Attributes☻ Weak Entity Types☻ Entity Types, Value Sets, and Key Attributes☻ Relationships and Relationship Types☻ Roles and Attributes in Relationship Types

ER Diagram for COMPANY Schema



DATABASE DESIGN STEPS



ENTITIES

Entities principal data object about which information is to becollected.

Recognizable concepts, either concrete or abstract, such asperson, places, things, or events which have relevance to thedatabase.

Examples of entities are EMPLOYEES, PROJECTS, INVOICES.

An entity is analogous to a table in the relational model.

Student is an entity.

Student



WEAK ENTITY TYPES

An entity that does not have a key attribute

A weak entity must participate in an identifying relationship type withan owner or identifying entity type.

Entities are identified by the combination of:• A partial key of the weak entity type•The particular entity they are related to in the identifying entity type



Attributes are data objects that eitheridentify or describe entities.

Attributes that identify entities are keyattributes.

Attributes that describe an entity are

non-key attributes.

Student

•Name•Last Name•First Name•Address•Street Address•City

•State or Province

City

First Name

AddressAttributes

ATTRIBUTES



ATTRIBUTES

Attributes are properties used todescribe an entity.

E.g.: An EMPLOYEE entity may have aName, SSN, Address, Sex, Birthdates

A specific entity will have a valuefor each of its attributes

E.g.: A specific employee entity may haveName='John Smith', SSN='123456789',

Each attribute has a value set (ordata type) associated with it

E.g.: integer, string, date , enumerated type,…



TYPES OF ATTRIBUTES

Simple Attributes

•Each entity has a single atomic value forthe attribute.

E.g. SSN or Sex

Composite Attributes

•The attribute may be composed of severalcomponents.

•Composition may form a hierarchy wheresome components are themselvescomposite

E.g.: Address (Apt#, House#, Street,City, State, Zip_Code, Country)orName (First_Name, Middle_Name,Last_Name).

Multi-valued Attributes

•An entity may have multiple values for theattribute.

E.g.: Color of a CAR orPrevious Degrees of a STUDENT.

Nested Attributes

In general, composite and multi-valuedattributes may be nested arbitrarily to anynumber of levels although this is rare.

E.g.: Previous Degrees of a STUDENT is acomposite multi-valued attribute denoted by{Previous Degrees (College, Year, Degree,Field)}.





RELATIONSHIP

BUILDING 1:N

01

APARTMENT

Weak EntityStrong Entity



CLASSIFYING RELATIONSHIPS

Classified by theirDegreeConnectivityCardinalityDirectionExistence.



DEGREE OF A RELATIONSHIP

The number of entities associated with the relationship.

Binary relationships, the most common type in the real world.

Ternary relationship when a binary relationship is inadequate.




DEGREE OF RELATIONSHIP

One entityrelated to

another of thesame entitytype

Entities of twodifferent typesrelated to eachother

Entities of threedifferent typesrelated to eachother




CONNECTIVITY AND CARDINALITY

Connectivity describes the mapping of associatedentity instances in the relationship.

The values of connectivity are "one" or "many".

Cardinality is the actual number of related

occurrences for each of the two entities.one-to-one,one-to-many,many-to-many.

CA A




CARDINALITY…



CARDINALITY




CARDINALITY…

Many-to-many relationships cannot be directly translated torelational tables but instead must be transformed into two or

more one-to-many relationships using associative entities.

Employee Emp_Proj Projects

DIRECTION




DIRECTION

The direction of a relationship indicates the originating entity of a binary relationship.

The entity from which a relationship originates is the parent entity.

The entity where the relationship terminates is the child entity .

Patient Patient History

Parent Entity Child Entity

EXISTENCE




EXISTENCE

Denotes whether the existence of an entity instance isdependent upon the existence of another, related, entity

instance.

Either mandatory or optional .

Mandatory - “Every project must be managed by a single

department".Optional - "employees may be assigned to a BU".

CONSTRAINTS ON RELATIONSHIPS




CONSTRAINTS ON RELATIONSHIPS

Constraints on Relationship Types( Also known as ratio constraints )

•Cardinality Constraints - the number of instances of oneentity that can or must be associated with each instance of another entity.

•Minimum Cardinality(also called participationconstraint or existence dependency constraints)

If zero, then optional participation, not existence-dependentIf one or more, then mandatory, existence-dependent

•Maximum CardinalityThe maximum numberOne-to-one (1:1)One-to-many (1:N) or Many-to-one (N:1)Many-to-many

CONCEPTUAL MODELING




CONCEPTUAL MODELING

A conceptual model shows data through business eyes.

Identify entities which have business meaning.

Identify important relationships

Identify significant attributes in the entities.

CONCEPTUAL MODELING




CONCEPTUAL MODELING

Next step is to build the ER Diagram from the entities and dataitems identified in the requirements.

Determine if there are any relationships between the entities.

An entity that does not relate to any other entity may end upas a “stand alone” table with no defined relationships.

ER DIAGRAM NOTATIONS




ER – DIAGRAM NOTATIONS

CASE STUDY




CASE STUDY

The XYZ Company wants Satyam to design and develop a database system forits regular operations.

The database should record information about the departments, projects,employees and their dependant. The company is organized into departments.Employees work for a department and may work on many projects. Departmentscontrol the project which are being operated from that location. Department hasto be managed by someone.

There are managers who manages and monitors the work done by theemployees. Suppose an employee is assigned to a project, the hours arecalculated based on number of hours the employee is scheduled to work on aproject.

Although most employees have managers, senior staff. The date on which amanager started managing the department could be stored as an attribute of department.

A department may be spread over many locations. The department name andnumber are unique for the department. Employee may have number of dependants.

IDENTIFYING ENTITIES




IDENTIFYING ENTITIES

Dependant

Project

Department

Sex Salary

Address

Name

Fname Mname Lname

SSNO

Bdate

Number ofemployees

Dname

Dnumber

Dlocation

Pname Pnumber Plocation

Name Sex Bdate Relationship

Employee

1

N

DEPENDANTS_OF

N 1WORKS_FOR

supervisor supervisee

1 NSUPERVISION

1

N

CONTROLS1 1

MANAGES

Startdate

NM

WORKS_ON

Hours



ONE-TO-MANY (1:N) RELATIONSHIP




ONE-TO-MANY (1:N) RELATIONSHIP

EmployeesDepartment WORKFOR

The relationship between these two entities is 1 toMany because there can be 1 or more employees ineach department.

Every department is required to have at least oneemployee, and no employee can belong to more thanone department.

What kind of table design does this suggest?

A single table for each entity: the Department Tableand Employee Table.

N1

MANY-TO-ONE (N:1) RELATIONSHIP




MANY-TO-ONE (N:1) RELATIONSHIP

The relationship between these two entities is Manyto 1 because there can be 1 or more dependants foreach employee.

What kind of table design does this suggest?

A single table for each entity: the Dependants Tableand Employee Table.

EmployeesDependants DEPENDANT_OF 1N

MANY- TO – MANY (N:M) RELATIONSHIP




MANY TO MANY (N:M) RELATIONSHIP

Employee Project

Works On

Have

These 2 entities have 2 relationships - 1 to many ineach direction - resulting in a many-manyrelationship.

Employees are optionally assigned to one or moreProjects, as appropriate. A Project must have at

least 1 employee.What kind of table design does this suggest?

2 Tables plus a table with a column for each entity.(Employee, Project, Employee_Project)

RECURSIVE RELATIONSHIPS




RECURSIVE RELATIONSHIPS

We can also have a recursive relationship type.

Both participations are same entity type in different roles.

E.g.: SUPERVISION (MANAGES) relationships betweenEMPLOYEE (in role of supervisor or boss) and (another)EMPLOYEE (in role of subordinate or worker).

In ER diagram, need to display role names to distinguishParticipations.

EMPLOYEE

MANAGES

ATTRIBUTES OF RELATIONSHIP TYPES




ATTRIBUTES OF RELATIONSHIP TYPES

Here, the date completed attribute pertains specificallyto the employee’s completion of a course…it is anattribute of the relationship

NOTATION




NOTATION

(1,1)(0,1)

(1,1)(1,N)

The (min, max) notationrelationship constraints

PROBLEM WITH ER




PROBLEM WITH ER

The Entity Relationship Model In Its OriginalForm Did Not Support

The SpecializationGeneralization




Rationale forDimensional Modeling




Dimensional Model

Definition

Logical data model used to represent the measures and dimensions thatpertain to one or more business subject areasDimensional Model = Star Schema

Serves as basis for the design of a relational database schema

Can easily translate into multi-dimensional database design if required

Overcomes OLTP design shortcomings

Di i l M d l Ad t




Dimensional Model Advantages

UnderstandableSystematically represents history

Reliable join paths

High performance query

Enterprise scalability




Subject areadimensional

models

Subject Area Models

Manufacturing andProcess Control

Sales Order Entryand CampaignManagement

Customer Supportand RelationshipManagement

Shipping andInventoryManagement

Subjectarea E/R

models

OperationsSales andMarketing

CustomerServices

ProductDevelopment




Enterprise Models

EnterpriseScope E/R model

Enterprisescopedimensionalmodel



Star Schema Dimension Tables




Dimension

Dimension

Dimension

Star Schema Dimension Tables

Dimension tables

Store dimension valuesTextual contentDimension tables usuallyreferred to simply as

'dimensions'Spend extra effort to adddimensional attributes

Dimension Keys




key

key

key

Dimension

Dimension

Dimension

Dimension Keys

Synthetic keysEach table assigned aunique primary key,specifically generated for

the data warehousePrimary keys from sourcesystems may be presentin the dimension, but arenot used as primary keysin the star schema

Dimension Columns




Key

attribute

attributeattribute

Key

attribute

attribute

attribute

Key

attribute

attribute

attribute

Dimension

Dimension

Dimension

Dimension Columns

Dimension attributesSpecify the way in whichmeasures are viewed:rolled up, broken out or

summarizedOften follow the word ―by‖as in ―Show me Sales byRegion and Quarter‖Frequently referred to as'Dimensions'

Star Schema Fact Table




Fact Table

fact1

fact2

fact3

Star Schema Fact Table

Process measures

Start by assigning one facttable per business subjectareaFact tables store the

process measures (akaFacts)Compared to dimensiontables, fact tables usuallyhave a very large numberof rows

Fact Table Primary Key




Fact Table

fact1

fact2

fact3

keykeykey

Fact Table Primary Key

Every fact tableMulti-part primary keyaddedMade up of foreign keysreferencing dimensions




Fact Table

Fact Table Grain

Grain

The level of detail represented by arow in the fact tableMust be identified earlyCause of greatest confusion duringdesign process

Example

Each row in the fact table representsthe daily item sales total




Designing a Star Schema

Five initial design stepsBased on Kimball's six stepsStart designing in orderRe-visit and adjust over project life

Five initial design stepsIdentify fact tableIdentify fact table grainIdentify dimensionsSelect factsIdentify dimensional attributes

EXERCISE 1




Scenario

Industry: Automobile manufacturingCompany: Millennium Motors

Value chain focus: Sales

Sample business questions:

What are the top 10 selling car models this month?How do this months top 10 selling models compare to the top 10 over

the last six months?

Show me dealer sales by region by model by day

What is the total number of cars sold by month by dealer by state?List facts and dimensions

56



Example Fact Table




Example Fact Table

Sales Factsmodel_keydealer_keytime_key

revenuequantity

Example Fact Table Records




p

time_key model_key dealer_key revenue quantity

1 1 1 75840.27 2

1 2 1 152260.37 3

1 3 1 28360.15 1

1 4 1 132675.22 4

1 5 1 43789.45 1

1 1 2 35678.98 1

1 3 2 57864.78 2

1 5 2 92876.67 2Primary Key Facts

Sales Facts

F




Facts

Fully additive

Can be summed across any and all dimensionsStored in fact tableExamples: revenue, quantity

Modelmodel_key

brandcategorylinemodel

Sales Facts

model_keydealer_keytime_key

revenuequantity

Timetime_key

yearquartermonthdate

Dealerdealer_key

regionstatecitydealer




Facts

Semi-additive

Can be summed across most dimensions but not allExamples: Inventory quantities, account balances, or personnel countsAnything that measures a ―level‖Must be careful with ad-hoc reportingOften aggregated across the ―forbidden dimension‖ by averaging

Sales Factsmodel_keydealer_keytime_key

inventory

Modelmodel_key

brand

categorylinemodel

Timetime_key

yearquartermonthdate

Dealerdealer_key

regionstatecity

dealer






Unit Amounts

Unit price, Unit cost, etc.Are numeric, but not measuresStore the extended amounts which are additiveUnit amounts may be useful as dimensions for ―price point analysis‖May store unit values to save space

Factless Fact TableA fact table with no measures in itNothing to measure...

except the convergence of dimensional attributesSometimes store a ―1‖ for convenienceExamples: Attendance, Customer Assignments, Coverage








Slowly Changing Dimension Example

Example: A woman gets marriedPossible changes to customer dimension

– Last Name – Marriage Status – Address

– Household IncomeExisting facts need to remain associated with her singleprofileNew facts need to be associated with her married profile




Slowly Changing Dimension Types

Three types of slowly changing dimensionsType 1

– Updates existing record with modifications – Does not maintain historyType 2

– Adds new record – Does maintain history – Maintains old recordType 3:

– Keep old and new values in the existing row – Requires a design change




Designing Loads to Handle SCD

Design and implementation guidelines

Gather SCD requirements when designing data mappingand loading

SCD needs to be defined and implemented at thedimensional attribute level

Each column in a dimension table needs to be identified as aType 1 or a Type 2 SCD

If one Type 1 column changes, then all Type 1 columns willbe updated

If one Type 2 column changes, then a new record will be

inserted into the dimension table

Type 1 Example




yp p

CustID Name

MaritalStatus

123 Sue Jones S $30K

HomeIncome

CustID Name

MaritalStatus

1 123 Sue Jones S $30K 0

HomeIncome

CustKey

CustKey

DayKey Sales

1 1 $40

Day DimDayKey

BusinessDate

1 1/31/01

Sales FactsCustomer DimCustomer OLTP

Day

KeyBusinessDate

1 1/31/01

2 2/01/01

Day DimCustKey

DayKey Sales

1 1 $40

1 2 $50

Sales FactsCustID Name

MaritalStatus

123 Sue Smith M $60K

HomeIncome

Customer OLTP

Status

Customer Dim

CustID Name

MaritalStatus

1 123 Sue Smith M $60K 0

HomeIncome

CustKey Status

OLTP Star Schema

Sue Gets Married 2/1/01

Type 2 Example




CustID Name

MaritalStatus

123 Sue Jones S 30K

Day Dim

HomeIncome

CustID Name

MaritalStatus


HomeIncome

CustKey

CustKey

DayKey Sales

1 1 $40

DayKey

BusinessDate

1 1/31/01

Sales FactsCustomer DimCustomer OLTP

CustKey

DayKey Sales

1 1 $40

2 2 $50

Sales Facts

CustID Name

MaritalStatus


HomeIncome

CustKey Status

2 123 Sue Smith M $60K 0

Customer Dim

CustID Name

MaritalStatus

123 Sue Smith M $60K

HomeIncome

Customer OLTP

Status

OLTP Star Schema

Sue Gets Married 2/1/01Day Dim

DayKey

BusinessDate

1 1/31/01

2 2/01/01





A T




Aggregate Types

Separate Tables

Separate fact table for every aggregateSeparate dimension table for every aggregate dimensionSame number of fact records as level field tables

Advantage

Removes possibility of double countingSchema clarity

Separate Tables




One Way Aggregate month_key

product_keymarket_keyQuantity

Amount

Mthly SalesFacts Agg

time_keyproduct_keymarket_key

Quantity Amount

Sales Factsproduct_keyCategoryBrandProductDiet Indicator

Product

month_key YearFiscal PeriodMonth

Month

market_keyRegion DistrictStateCity

Market

time_key YearFiscal PeriodMonthDayDay of Week

Time









CONFORMED DIMENSIONS




Definition

Dimensions are conformed when they are the same-or-When one dimension is a strict rollup of another

79





Same dimensions must:

1. ... have exactly the same set of primary keysand

2. ... have the same number of records





Rolled up dimension

When one dimension is a strict rollup of another

Which meansTwo conformed dimensions can be combined into a single

logical dimension by creating a union of the attributes







Advantages

Enables an incremental development approachEasier and cheaper to maintainDrastically reduces extraction and loading complexityAnswers business questions that cross data marts

Supports both centralized and distributed architectures



© Mahindra Satyam 2009

Erwin

ERWIN




All Fusion Erwin Data Modeler commonly known as

Erwin , is a powerful and leading data modeling toolfrom Computer Associates.Has many powerful features that you can use todesign entity relation data models and dimensionalmodelsCurrently used Version : 4.1.4CA has recently released version Erwin Data Modelerr7Has many powerful features that you can use to

design entity relation data models and dimensionalmodels

ERWIN BASIC FEATURES




Creating a ModelTemplates - To save time, you can also start working from atemplate that you or others in your workgroup have created. Whenyou create a model from a template, all the objects and displaysettings in the template are automatically applied to the newmodel.Subject Areas - For each new model, ERwin also automatically

creates a subject area (Main Subject Area). You can createadditional subject areas.Stored Displays – Represent a different view of a subject areawithout the need to change setting repeatedly.Model Types – Logical, Physical , Logical/Physical orLogical/Dimensional

Modeling Preferences - You can customize your workingenvironment using ERwin's many display options and modelpreferences. You can also choose to create your model usingIDEF1X or IE notation.



ERWIN FILE FORMATS




ER1 - Standard ERwin file format. ERwin version 3.5.2 and later aresupported.

XML - ERwin metamodel saved as an Extensible Markup Language file.When you open an ERwin model saved in XML format, ERwin reads thedata structure specified in the XML file and automatically reverseengineers the database and creates a matching data model diagram.

ERS,SQL DDL (Data Definition Language) - schema script text file.When you open a text file with this extension, ERwin reads the datastructure specified in the text file and automatically reverse engineersthe database and creates a matching data model.

DBF- A file name with this extension is a database file in dBASEformat. When you open a DBF file, ERwin automatically reverseengineers the database and creates a matching data model.

MDB - A file name with this extension is a database file in MicrosoftAccess format. When you open an *.mdb file, ERwin automaticallyreverse engineers the database and creates a matching data model.

ERWIN WORKPLACE




Model Explorer & Toolbars

MODEL EXPLORER




LOGICAL AND PHYSICAL MODELS




NOTATIONS




DIMENSIONAL MODEL NOTATION






RELATIONSHIPS




DOMAINS




RELATIONSHIP




RELATIONSHIP




ROLENAMES




DISPLAY LEVEL






TRANSFORMS




NAMING STANDARDS




NAMING STANDARDS




FORWARD ENGINEERING






REPORTS






Are the expected benefits being realized?




There is no magic solution!

Are the expected benefits being realised?




The data model is required for good data management but it is only one of the elements.

Today's systems are tomorrow's legacy systems!

Barriers to good data management








Data problems

– lack of resources, data hoarding, lack of data knowledge

System users – not committed, not convinced, lack of time

Legacy systems and data stores

Different business interests

Cost







CASE STUDY - 1




PURPOSE:-The aim of the case study is to introduce you to the concepts

and principles involved in dimensional modeling design anddevelopment.

ou are expected to produce a small dimensional model based onthe scenario given in following slides.

CASE STUDY - 1PROBLEM STATEMENT




PROBLEM STATEMENTTelecom Sales Assignment (Star Schema) : -

telecom company wants to develop a data warehouse system to computerize its salesmanagement. Here are the details:-

The company is tracking the sales of its products (made in different manufacturing plants) todifferent customers.The company is basically comprised of two broad operations :

– Manufacturing products in its manufacturing plants – Sales of these products by its sales outlets to customers

The customers of the company are either big corporate companies or retailers who buy directlyover the counter.Each customer purchases one or more products through an order.There are two types of seller outlets:

– Corporate sales office – Retail stores

The products can be bought in the following two ways: – In the case of retail (non-corporate) customers, the products are

purchased over the counter from retail outlets.

– In the case of corporate customers, orders can be placed over the phoneand goods are delivered directly from plant to the particular corporate office.

CASE STUDY - 1




Business Questions to be answered : -1 What are the total cost and revenue for each model sold today, summarized by outlet,

outlet type, region?2 What are the total cost and revenue for each model sold today, summarized bymanufacturing plant and region?3 For each month how much was the ordered revenue by customer region? How much

as delivered?4 What are the top five models sold last month by total revenue? By quantity sold? By total

cost?

CASE STUDY - 2




PURPOSE:-The aim of the case study is to introduce you to the concepts

and principles involved in dimensional modeling design anddevelopment.


CASE STUDY - 2




PROBLEM STATEMENTCompany Payroll Assignment (Star Schema) : -

software company wants to develop a data warehouse system to computerize its payrollmanagement. Here are the details:-

The company has 10000 employees on payroll out of which 9000 arepermanent employees and 1000 are contract employees.The company has 20 divisions.The company offices and development centers are in 50 locations (offshoreand onsite both included)The payroll cycle is monthly and payment is made on first of every monthThe paychecks are made in local currency (depending upon the assignment of employee)The salary of the employee depends upon his grade. For every grade there isa lower and higher salary bandwidth.

CASE STUDY - 2Business Questions to be answered :




Business Questions to be answered : -1 What is the total payroll cost for each division for each pay cycle?

2 What is the payroll cost employee grade wise as a percentage of total payroll cost per cycle?3 What is location wise payroll cost every month?4 Which are the top 5 divisions that have incurred maximum payrollcost?5 What is the ratio of supporting divisions payroll cost to the totalpayroll cost?6 What is the payroll cost of temporary employees as a ratio of totalpayroll cost?



CASE STUDY - 3PROBLEM STATEMENT




PROBLEM STATEMENTutomobile Finance Assignment (Star Schema) : -

n automobile company wants to develop a data warehouse system to computerize its financemanagement. Here are the details:-

The company has 1000 dealers (i.e. customers).The company has 10 profit centers.The revenue is accrued in local currency

The company has 5 product groups. Each product group has several modelsThe region for the sales person and customer is same as that of profit center

CASE STUDY - 3




Business Questions to be answered : -

1 What is the total revenue for each profit center for each month?2 How is the revenue growth for each profit center on year-on-year basis?3 Which are top 10 customers by revenue?4 Which are top 10 products by revenue?5 Which regions are not doing well revenue wise?6 Who are the 5 best sales representatives by revenue accrualsfor this year?

CASE STUDY - 4




PURPOSE:-

The aim of the case study is to introduce you to the conceptsand principles involved in dimensional modeling design anddevelopment.


CASE STUDY - 4




PROBLEM STATEMENT

utomobile Inventory Assignment (Star Schema) : -n automobile company (say Tata Motors) wants to develop a data warehouse system tocomputerize its inventory management. Here are the details:-

The company has 3 manufacturing plant units (Pune, Lucknow and JSR)The company has 5 cost centers. (cost centers categorized by product group)

(HCV,MCV,LCV, Tata Indica and Tata Safari)Each plant has several store locationsThe company has 5 product groups. Each product group has several models

CASE STUDY - 4




Business Questions to be answered : -1 What is the total inventory quantity and amount for each plant location at opening of each month?2 How much is the inventory cost for each cost center for each quarter end?3 Which are the top 10 products that has maximum inventory cost at opening of eachmonth?4 What is the total inventory quantity and amount for each store location at opening of

each month?




Q & A



Thank you

Documents

DataModel Session ELTP