1 / 21

Logical Data Models for Agile BI

Logical Data Models for Agile BI. David D. Schoeff Teradata - EDW Data Architect & Principal Consultant. Not Designing a Data Architecture is a …. Why do we need an LDM?. Data Warehouse with LDM Data Warehouse Without LDM. What is the Purpose of a Data Model?.

gershom
Download Presentation

Logical Data Models for Agile BI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Logical Data Models for Agile BI David D. Schoeff Teradata - EDW Data Architect & Principal Consultant

  2. Not Designing a Data Architecture is a …

  3. Why do we need an LDM? Data Warehouse with LDM Data Warehouse Without LDM

  4. What is the Purpose of a Data Model? • A visual business representation of how data is organized in the enterprise • It provides discipline and structure to the complexities inherent in data management • Can you imagine building a house without a blueprint? • Or driving across the country without a map? • It facilitates communication within the business (e.g. within IT and between IT and the business) • It facilitates arriving at a common understanding of important business concepts (e.g what is a customer?)

  5. Logical Data Model Components … • LDM graphically represents the data requirements and data organization of the business • Identifies those things about which it is important to track information (entities) • Facts about those things (attributes) • Associations between those things (relationships) • Subject-oriented, designed in Third Normal Form – one fact in one place in the right place

  6. Reference ModelsLots of Detail / Expertise Behind Models

  7. Reference Model Sources • Data Warehousing Vendors • IBM • Oracle • Teradata • … • Tool Vendors • Embarcadero • … • Service Vendors • EWSolutions • … • Industry/Standards Associations • ARTS (Association for Retail Technology Standards) • …

  8. Teradata Industry Logical Data Models - iLDMs • Communications • Wireline, Wireless, • Cable, Satellite Financial Services - Banking, Investments • Travel • Travel, Hospitality, • Gaming Financial Services - Insurance • Transportation • 3PL, 4PL, • Air, Truck, Rail, Sea • Retail • Retail Store, • Food Service Healthcare - Payor, HIPAA • Manufacturing • CPG, High Tech • Automotive

  9. Data Management ContextThree Layer Structure Source Semantic (Usage/Presentation) Core (Enterprise) BIOs & User Types drive requirements iLDM EDW-LDM Semantic Layer Models Analyze & Design (Logical) Used for customization EDW-PDM Views Implement (Physical) Data Integration Marts Source Operational Images Use Many Load Once

  10. Enterprise Information Management Requires A Shared VOCABULARY Experts estimate that the 500 most commonly used words in the English language have an average of 28 definitions each.

  11. Enterprise Data Management Objectivesthat are enabled by Enterprise Logical Data Modeling : • Build a Common Business Vocabulary for the enterprise. • Develop an EDW Data Structure that isNeutral from All the Sources that populate it. • Develop an EDW Data Structure that will Support All Business Requirements While Not Being Constrained by any specific requirement. • i.e. Neutral from use by multiple functional areas • Supports operational and analytical uses

  12. Data Modeling Structure Data Modeling SUBJECT Model A model of the high level data concepts that define the scope of the Data Architecture. An entity-relationship model that identifies the elements of the Business Vocabulary and Business Rules. CONCEPTUAL Model A refinement of the Conceptual Model that identifies the natural and surrogate keys for all entitles and relationships. This the foundation of the Enterprise Business Vocabulary. KEY-BASED Model A detailed model that identifies the non-key attributes for the entitles. Attribution also leads to refining the Key-Based Model ATTRIBUTED Model A model that is the design for a database. The Attributed Model is transformed for Sourcing and Accessing performance. PHYSICAL Model

  13. Data Modeling Structure Purposes Data Modeling Architecture SUBJECT Model • Information Requirements • Business Improvement Opportunities • Business Questions • Key Performance Indicators • Legacy Reporting/Analysis CONCEPTUAL Model Reference Model KEY-BASED Model ATTRIBUTED Model Implementation PHYSICAL Model

  14. Data/Information Management Data Modeling Data Warehousing APPLICATION Layer SUBJECT Model Access Layer SEMANTIC Layer CONCEPTUAL Model KEY-BASED Model CORE Layer Master Data Transaction Data Teradata Enabled STAGING Layer ATTRIBUTED Model Source Layer DDL Sources PHYSICAL Model Sources Sources Data Source Layer

  15. Data Management ContextAgile Development Environment User External Data Sandbox

  16. Data Management ContextPerceived Value from Medium to Large Scale Projects 80-95% 0-5% 0-1% User External Data Sandbox 5-15%

  17. Data Management ContextDevelopment Time for Medium to Large Scale Projects 4-8 weeks 2-4 Months 3-6 months User External Data Sandbox 1-5 days

  18. Data Integration 1st Sandbox Application 2nd Sandbox Application Local Shared Local Common Shared Shared 3rd Sandbox Application Local

  19. Data Management ContextIntegration in anAgile Development Environment Conceptual Data Architecture Governance-driven Integration User External Data Sandbox

  20. Pros and Cons of Using a Vendor Provided Analytical Data Model in Your BI ImplementationBoris Evelson, Information Management Blogs, January 29, 2010 Let’s discuss. Pros: • Leverage vendor knowledge from prior experience and other customers • May fill in the gaps in enterprise domain knowledge • Best if your IT dept does not have experienced data modelers   • May sometimes serve as a project, initiative, solution accelerator • May sometimes break through a stalemate between stakeholders failing to agree on metrics, definitions Cons: • May sometimes require more customization effort, than building a model from scratch • May create difference of opinion arguments and potential road blocks from your own experienced data modelers • May reduce competitive advantage of business intelligence and analytics (since competitors may be using the same model) • Goes against “agile” BI principles that call for small, quick, tangible deliverables • Goes against top down performance management design and modeling best practices, where one does not start with a logical data model but rather • Defines departmental, line of business strategies    • Links goals and objectives needed to fulfill these strategies    • Defines metrics needed to measure the progress against goals and objectives    • Defines strategic, tactical and operational decisions that need to be made based on metrics • Then, and only then defines logical model needed to support the metrics and decisions  

  21. Cooking Something New ... If Only We Knew What We Know Carla O’Dell & C. Jackson Grayson The Free Press, 1998 “Change without a recipe is a recipe for chaos.” “The transformation model must describe not only the steps in the process, but also the enabling context that is critical to its success.”

More Related