Universal Data Modeling. A Unified Approach for Intelligent Data Models Jun Shan

Dostępność produktu

Produkt nie został jeszcze oceniony pod kątem ułatwień dostępu lub nie podano żadnych informacji o ułatwieniach dostępu lub są one niewystarczające. Prawdopodobnie Wydawca/Dostawca jeszcze nie umożliwił dokonania walidacji produktu lub nie przekazał odpowiednich informacji na temat jego dostępności.

Spis treści książki

• Preface
  • Why Universal Data Modeling?
  • Data Modeling in the Modern Data Landscape
  • What I Hope You Take Away
  • Conventions Used in This Book
  • OReilly Online Learning
  • How to Contact Us
  • Acknowledgments
• 1. Introduction to Data Modeling
  • What Is Data Modeling?
  • The Process of Data Modeling
    • Conceptual Data Model
    • Logical Data Model
    • Physical Data Model
    • Data Modeling Development Stages
  • The History of Data Modeling
    • Early Days (1960s1970s): File-Based, Hierarchical, and Network Models
    • Relational Revolution (1970s1990s): the Relational Model
    • The Rise of Non-Relational Models (1990s2010s)
      • Challenges to relational modeling
      • NoSQL database and modeling
    • Modern Era (2020s): Challenges from All Fronts
      • The continued evolution of the relational database
      • New challenges beyond traditional modeling
  • The Universal Solution to a Universal Problem
  • Summary
• 2. Conceptual Data Modeling with the EntityRelationship Model
  • EntityRelationship (ER) Model
  • Entity
    • Attribute
    • Defining Attributes
      • Name
      • Value multiplicity
      • Data type
      • Nullable
    • Constraints and Boundaries
    • Shorthand Notation
  • Entity Key
    • The Uniqueness of Each Entity
    • Superkey and Candidate Key
    • Primary Key
      • Surrogate key
      • Primary key definition stage
  • Relationship
    • Cardinality
      • One-to-many relationships
      • One-to-one relationships
      • Many-to-many relationships
      • Min/max cardinality
    • Relationship Attributes
    • Relationship Key
    • Foreign Key
    • Distinguishing Between an Entity and a Relationship
  • EntityRelationship Diagram (ERD)
  • Summary
• 3. Requirements Gathering for Conceptual Model
  • Phases of Conceptual Data Modeling
    • Phase 1: Initiation and Planning
    • Phase 2: Business Requirements Gathering
    • Phase 3: Requirements Analysis and Business Requirements Document Creation
    • Phase 4: Conceptual Model Design
  • Form the Project Team
    • Parties and Roles
      • Business stakeholders
        • Executives
        • Business users/domain experts/domain subject matter experts
        • Data analysts
        • Business analysts
      • Technical stakeholders
        • Data modelers
        • Database administrators
        • Data engineers/extract, transform, load developers
        • Data scientists
        • Application developers
      • Data governance and oversight roles
        • Data governance committee
        • Data stewards
        • Project managers
    • Teams for Conceptual Modeling
      • Leadership team
      • Core team
      • Subject matter expert teams
  • Gather Requirements
    • Information to Collect
      • Business objectives and scope
      • Stakeholder requirements
      • Business processes and rules
      • Data sources and existing systems
      • Non-functional requirements
    • Types of Interactive Sessions
    • Interview Process
      • Preparation before the interview
        • Identify stakeholders
        • Study existing materials
        • Define clear objectives
        • Prepare questions
        • Plan logistics
      • Conducting the interview
        • Build rapport
        • Start broad, then narrow down
        • Encourage storytelling
        • Listen actively and probe
        • Record details carefully
      • After the interview
        • Summarize and validate
        • Consolidate findings
        • Maintain a glossary
      • Best practices
  • Analyze Requirements and Develop a Business Requirements Document
    • Requirements Analysis
      • Step 1: Consolidate the business objectives
      • Step 2: Consolidate business activities
      • Step 3: Define the steps, rules, and data flows
      • Step 4: Review and validate the analysis
    • Structure and Content of the Business Requirements Document
      • Structure of the business requirements document
  • Summary
• 4. Design Patterns in Conceptual Data Modeling
  • Approach 1: Entity-Driven Approach
    • Step 1: Extract Business Terms from Business Requirements
    • Step 2: Identify and Define Entities
      • Identify attributes
      • Determine keys
    • Step 3: Identify and Define Relationships
    • Step 4: Create the Final Documentation
    • Step 5: Review and Validate with Stakeholders
    • Example of Entity-Driven Approach
      • Step 1: Extract business terms from business requirements
      • Step 2: Identify and define entities
      • Step 3: Identify and define relationships
      • Step 4: Create the final documentation
      • Step 5: Review and validate with stakeholders
  • Approach 2: Relationship-Driven Approach
    • Steps in Relationship-Driven Approach
    • Example of Relationship-Driven Approach
  • The Embedding Model
  • Dependent Entity and Weak Entity
    • Weak Entity Versus Dependent Entity
    • Embedding Versus Referencing
    • Decide Between Subentity and Attribute
  • N-ary Relationship
  • Temporal Entities and Relationships
    • Start/End Dates
    • Time RangeEntity Association
    • Versioning
    • Active Flag
  • Supertype and Subtype
    • Overlapping Versus Disjoint Subtypes
    • Supertype Versus Subtype Design
  • Summary
• 5. Logical Modeling and the Document Model
  • Logical Model Overview
    • Logical Data Model Usage
      • The NoSQL challenge
      • The need for abstraction
    • CRUD: Create, Read, Update, and Delete
    • Parties and Roles in Logical Modeling
      • Data modeler/data architect
      • Application developers/data engineers/data scientists
      • Database administrators/technical architects
      • Project managers/product owners
  • The Document Logical Model
    • Collection
    • JSON Schema
    • Implementing the Document Model
    • Usage Scenarios of the Document Model
  • Design Patterns of the Logical Model
    • Dependent Entity
      • Embedding an independent entity
      • Code/value design
    • Supertype, Subtype, and Collection
    • Subset Pattern
    • Derived Design Patterns
      • Compute pattern
      • Time-series cumulative pattern
      • Surrogate key
  • Summary
• 6. Logical Model Types and Key-Based Models
  • Different Types of Logical Models
    • Document Model
    • KeyValue Model
    • Wide-Column/Column Family Model
    • Relational Model
    • Dimensional Model
    • Graph Model
    • Comparison of Logical Model Types
  • The KeyValue Model
    • NameValue Pair Versus KeyValue Pair
    • From Document to KeyValue Pair
    • Amazon DynamoDB
    • The Redis KeyValue Model
  • The Wide-Column Model
    • Google Bigtable
      • Example 1: Time-series metrics (weather sensor Internet of Things monitoring)
      • Example 2: User profile and feature serving (real-time machine learning)
      • Example 3: Clickstream/event tracking (high-volume ingestion)
    • Apache Cassandra
      • Example 1: Time-series sensor data (Internet of Things/monitoring)
      • Example 2: User activity feed (social/events)
      • Example 3: Orders by customer (ecommerce)
    • Bigtable Versus Apache Cassandra
  • Key-Based Models
  • Summary
• 7. Relational Models and Graph Models
  • The Relational Model
  • Generating a Relational Model from an EntityRelationship Model
  • Normalization
    • First Normal Form (1NF)
      • Atomicity
      • First normal form: Nested/combined value
      • First normal form: Repeating group
    • Second Normal Form (2NF)
    • Third Normal Form (3NF)
    • Denormalization
  • Design Flexible Schemas
    • NULL Attribute Pattern
    • Subtype and Subsetting Pattern
    • EntityAttributeValue Pattern
    • JSON Embedding Pattern
  • Graph Model
  • Summary
• 8. Dimensional and Data Vault Models
  • The Dimensional Model
    • Fact and Dimensions
    • Dimensional Model Design Patterns
      • Star schema
        • Identify the main business activities as fact tables
        • Identify supporting context (dimensions)
      • Aggregation table
      • Kimball enterprise bus architecture
      • Snowflake schema
      • One Big Table
    • Roles and Subtypes
    • Schema Evolution
    • Slowly Changing Dimension
  • Data Vault Model
    • Hubs
    • Links
    • Satellites
  • Summary
• 9. Modeling Within Enterprise Data Architecture
  • The Enterprise Data Architecture
    • Enterprise Data Architecture Illustrated
    • Data Generation and Ingestion Layer
    • Data Storage and Transformation Layer
      • Raw data repository
        • Staging area
        • Data lake
      • Operational data storage
      • Central data storage
        • Data warehouse
        • Data lakehouse
      • Data transformation: extract, transform, load/extract, load, transform (ETL/ELT)
    • Data Consumption and Analytics Layer
      • Dimensional datamarts
      • Specialized analytical databases
    • Real-Time Processing Mechanisms
      • Lambda architecture
      • Feedback mechanism
    • Medallion Architecture
  • Enterprise Logical Modeling
    • Universal Modeling Process
    • Selecting a Logical Model Type
    • Logical Model Deliverables
  • Summary
• 10. Physical Modeling
  • The Physical Data Model
    • The Database System Architecture
    • Distributed Compute and Storage
    • Storage Sharing in Distributed System
    • Components of a Database Management System
    • Physical Modeling Considerations
  • Storage Design
    • Storage Mechanism
      • Partition
      • Columnar storage
    • Indexing
    • Index Keyword Search Strategy
      • B-tree index
      • Hash index
      • Bitmap index
      • Index design patterns
  • Transaction Management
    • ACID Properties
    • BASE Properties: Basically Available, Soft State, Eventually Consistent
    • Transaction Management in Data Modeling
  • CAP Theorem: Consistency, Availability, and Partition Tolerance
  • Summary
• 11. Modeling for Data Management
  • Enterprise Data Management
    • Data Governance
      • Components of data governance
      • Importance of data governance
    • Data as a Product (DaaP)
      • Data product framework
      • Data mesh and data fabric
      • Data catalog
      • Data as a product example
  • Modeling for Enterprise Data
    • Data Governance for Data Management
    • Data Modeling Process for Data as a Product
    • Applying Universal Data Modeling Principles to Enterprise Data Management
  • Delivering Final Models
    • Physical Model Process
      • Step 1: Identify the physical requirements of the database
      • Step 2: Pick the right database management system
      • Step 3: Design the database architecture
      • Step 4: Design data structures
    • Teams Involved
    • Physical Model Deliverables
  • Summary
• 12. Universal Data Modeling: A Case Study
  • Introduction to the Case Study
  • Conceptual Model
    • Business Problem Statement and Business Objectives
    • Requirements Analysis
      • Claim intake and receipt
      • Pre-adjudication validation
      • Medical and policy review
      • Claim adjudication
      • Pricing and payment determination
      • Payment and remittance
      • Post-processing and analytics
      • Adjustments, appeals, and reprocessing
    • EntityRelationship Model: Core Claim Processing Entities
    • Data Products
      • Claim intake data product
      • Pre-adjudication validation and eligibility data product
      • Repeat for all your data products
    • Data Mesh and Data Fabric Implementation
  • Logical Models
    • Usage Scenario 1: Claim Intake
    • Usage Scenario 2: Fraud Detection
      • Fraud detection and graph data models
      • Fraud detection: Relationship intelligence products
    • Usage Scenario 3: Analytics and Reporting
      • Dimensional models, analytics, and reporting
      • Claims financial performance data product
  • Physical Model
    • Physical Design 1: Traditional Dimensional Model
      • Fact tables
      • Dimension tables
      • Key rules
    • Physical Design 2: Distributed Lakehouse and Consideration of Consistency, Availability, and Partition Tolerance (CAP)
      • Consistency (C): Strong at the table level
      • Availability (A): Read-optimized, write-conditional
      • Partition tolerance (P): Required and assumed
  • Data Catalog
    • Data Product Overview
    • Business Description
    • Data Product Description
    • Architectural Summary
      • Schema stability & evolution
      • CAP characteristics
      • CAP profile
    • Data Assets Included
      • Tables
      • Key Business Metrics
      • Data Refresh & Latency
      • Data Lineage (High Level)
    • Data Quality and Validation Rules
      • Data Quality Monitoring
      • Historical & Audit Characteristics
      • Data Product SLA
    • Security and Access Control
      • Data Classification
      • Access Control
      • Regulatory Compliance
  • Summary
  • Final Thoughts
• Index

pokaż cały spis treści

ukryj recenzje