/sap-datasphere

SAP Datasphere MCP Server - Illustrative Use Cases

Overview

This document provides 8 illustrative use cases for SAP Datasphere MCP-assisted workflows. Time and value numbers are examples from source material or planning assumptions only; they are not repository-verified productivity, ROI, tenant, or customer outcome claims.

Source: SAP Datasphere MCP Server Release Blog (Dec 14, 2025) Author: Mario Defelipe MCP Server: @mariodefe/sap-datasphere-mcp

Operation Safety

• Classification: read-only tenant, mutating tenant, destructive
• These examples may involve live SAP Datasphere tenant APIs when MCP credentials are configured in environment variables.
• Treat read/list/search/query examples as read-only tenant operations. Require explicit user approval before create, update, delete, reset, deploy, publish, trigger, or destructive actions.
• Keep live tenant verification pending unless matching evidence is recorded in the source verification ledger.

Common Patterns

Conversational Discovery

Ask exploratory questions to discover data assets, understand structures, and find relevant information without navigating complex UIs.

Context Building

Build context through a series of questions, allowing you to progressively understand the data landscape before taking action.

Iterative Refinement

Refine queries and analysis through natural conversation, adjusting filters, aggregations, and perspectives based on initial results.

Explanation + Action

Get explanations of data structures, relationships, and business logic, then immediately act on that understanding.

Cross-Domain Knowledge

Bridge technical and business domains by translating between database structures and business concepts in a single conversation.

Use Case 1: The Monday Morning Health Check

Persona

Data Operations Manager

Time Saved

45 minutes daily (225 minutes per week, ~15 hours per month)

Scenario

Every Monday morning, Sarah (Data Operations Manager) needs to verify that all critical data pipelines are running smoothly. Previously, this involved:

• Logging into Datasphere UI
• Manually checking each space
• Reviewing data flow statuses
• Checking connection health
• Verifying catalog integrity
• Spot-checking data quality

MCP Tools Used

• test_connection - Verify Datasphere connectivity
• list_spaces - Discover all spaces
• get_space_details - Get space configuration
• list_data_flows - List all data flows
• get_data_flow_status - Check flow execution status
• list_connections - List all connections
• get_tenant_info - Retrieve tenant configuration
• search_catalog - Discover catalog objects
• analyze_column_distribution - Profile data distributions

Conversational Workflow

Sarah's Monday Morning Conversation:

Sarah: "Good morning! Can you give me a health check on our Datasphere tenant?"

Agent: "I'll run a comprehensive health check. Let me verify connectivity and gather status information..."
[Uses test_connection, get_tenant_info]

Agent: "Tenant is online and responsive (102ms latency). Version 2025.24, 8 active spaces, 250GB total storage used. Let me check data flows..."
[Uses list_data_flows, get_data_flow_status]

Agent: "Found 24 data flows:
- ✅ 22 completed successfully in last 24h
- ⚠️ 2 flows need attention:
  - SALES_DAILY_REFRESH: Failed at 6:23 AM (connection timeout)
  - INVENTORY_SYNC: Running 3x slower than normal (45 min vs 15 min avg)"

Sarah: "What's wrong with SALES_DAILY_REFRESH?"

Agent: "Investigating the failure..."
[Uses get_data_flow_details, list_connections, test_connection]

Agent: "The S4HANA_PROD connection is timing out. Connection configuration shows:
- Last successful connection: 6:15 AM
- Last attempt: 6:23 AM (timeout after 300s)
- Current status: Testing connection...

Connection test failed: HTTP 503 Service Unavailable. This appears to be a source system issue, not Datasphere."

Sarah: "Got it, I'll check with the S/4HANA team. What about the slow INVENTORY_SYNC flow?"

Agent: "Analyzing INVENTORY_SYNC performance..."
[Uses get_data_flow_details, analyze_column_distribution, preview_data]

Agent: "The flow is processing 3.2M rows vs the usual 1.1M. The source table MARA has significantly more data today. Let me check the data distribution...

Analysis shows: 2.1M new rows added yesterday with ERSDA (creation date) = 2025-12-27. This appears to be a legitimate data load, not a data quality issue. The flow is working correctly but processing the larger dataset."

Sarah: "Perfect. Can you check our catalog for any orphaned or unused objects?"

Agent: "Scanning catalog for unused objects..."
[Uses search_catalog, list_space_objects]

Agent: "Found 12 views not accessed in 90+ days:
- LEGACY_CUSTOMER_VIEW (last access: 2025-09-15)
- OLD_SALES_REPORT (last access: 2025-08-22)
- TEMP_ANALYSIS_2024 (last access: 2025-07-10)
...

All are in the ANALYTICS_SANDBOX space. Would you like me to generate a cleanup report?"

Sarah: "Yes, please export that list to a CSV for review."

Expected Results

Health Check Report Generated:

• Tenant status: ✅ Online (102ms)
• Data flows: ⚠️ 2 require attention
• Connections: ⚠️ 1 failed (S4HANA_PROD - source system issue)
• Performance: ⚠️ 1 flow slower (legitimate data volume increase)
• Catalog: ℹ️ 12 unused views identified for cleanup

Total Time: 8 minutes (vs 45 minutes manually)

ROI Analysis

• Daily savings: 37 minutes
• Weekly savings: 185 minutes (3 hours)
• Monthly savings: ~14 hours
• Annual value: ~168 hours ($25,000+ at $150/hr)

Use Case 2: Data Lineage Inspection

Persona

Data Engineer

Time Saved

3 hours per investigation (typical lineage analysis)

Scenario

Marcus (Data Engineer) needs to understand the impact of deprecating a legacy field LEGACY_CUSTOMER_ID that appears in multiple views. He needs to trace where this field is used and what downstream dependencies exist.

MCP Tools Used

• find_assets_by_column - Find all assets using a specific column
• get_view_definition - Get view SQL definition
• list_data_flows - List data flows
• get_data_flow_details - Get flow transformation logic
• get_table_metadata - Inspect table structures
• search_catalog - Find related objects

Conversational Workflow

Marcus's Investigation:

Marcus: "I need to find everywhere LEGACY_CUSTOMER_ID is being used in our Datasphere tenant."

Agent: "Searching for LEGACY_CUSTOMER_ID across all assets..."
[Uses find_assets_by_column]

Agent: "Found LEGACY_CUSTOMER_ID in 8 objects:

Tables (2):
- DIM_CUSTOMER (source field)
- CUSTOMER_MASTER_COPY (copied from DIM_CUSTOMER)

Views (4):
- V_CUSTOMER_360
- V_SALES_BY_CUSTOMER
- V_MARKETING_SEGMENTS
- V_CUSTOMER_HISTORY

Data Flows (2):
- CUSTOMER_ENRICHMENT_FLOW
- SALES_AGGREGATION_FLOW

Would you like me to analyze the dependencies?"

Marcus: "Yes, show me the complete lineage tree."

Agent: "Building lineage tree..."
[Uses get_view_definition, get_data_flow_details for each object]

Agent: "Complete lineage:

DIM_CUSTOMER.LEGACY_CUSTOMER_ID
├─→ CUSTOMER_ENRICHMENT_FLOW (transformation)
│   └─→ CUSTOMER_MASTER_COPY.LEGACY_CUSTOMER_ID
│       └─→ V_CUSTOMER_360.OLD_CUST_REF (renamed)
│           └─→ V_MARKETING_SEGMENTS.CUSTOMER_REF
│               └─→ (used in join condition only)
│
└─→ SALES_AGGREGATION_FLOW
    └─→ V_SALES_BY_CUSTOMER.CUST_ID_LEGACY
        └─→ V_CUSTOMER_HISTORY.HIST_CUSTOMER_ID

Impact: 4 views, 2 data flows, 2 tables"

Marcus: "Can you show me the exact SQL for V_MARKETING_SEGMENTS to see how it's used?"

Agent: "Retrieving view definition..."
[Uses get_view_definition]

Agent: "Here's the relevant SQL from V_MARKETING_SEGMENTS:

```sql
SELECT
    c.CUSTOMER_REF,  -- This is LEGACY_CUSTOMER_ID from upstream
    c.SEGMENT_CODE,
    s.SEGMENT_NAME
FROM V_CUSTOMER_360 c
LEFT JOIN DIM_SEGMENTS s
    ON c.CUSTOMER_REF = s.CUSTOMER_ID  -- Join condition
WHERE c.STATUS = 'ACTIVE'

The field is used in:

1. SELECT clause (output column)
2. JOIN condition with DIM_SEGMENTS

Note: DIM_SEGMENTS.CUSTOMER_ID is the NEW customer ID format. This join will fail if LEGACY_CUSTOMER_ID is removed unless we also update the join logic."

Marcus: "Are there any analytic models consuming V_MARKETING_SEGMENTS?"

Agent: "Searching for analytic models..." [Uses search_catalog, get_model_metadata]

Agent: "Found 2 analytic models:

1. AM_MARKETING_PERFORMANCE

   • Uses V_MARKETING_SEGMENTS as fact source
   • CUSTOMER_REF is a dimension attribute
   • Used in 3 SAC stories
   • Last accessed: 2 hours ago (actively used)

2. AM_SEGMENT_ANALYSIS

   • Uses V_MARKETING_SEGMENTS
   • CUSTOMER_REF not exposed to consumers
   • Last accessed: 45 days ago (rarely used)

Recommendation: AM_MARKETING_PERFORMANCE is actively used. Removing LEGACY_CUSTOMER_ID requires updating the join logic and potentially the analytic model."

Marcus: "What's the migration path?"

Agent: "Based on the lineage analysis, here's the migration plan:

Phase 1: Add NEW_CUSTOMER_ID alongside LEGACY_CUSTOMER_ID

• Update DIM_CUSTOMER to include both fields
• Update CUSTOMER_ENRICHMENT_FLOW to map both fields
• Add NEW_CUSTOMER_ID to all 4 dependent views

Phase 2: Update join logic

• Modify V_MARKETING_SEGMENTS join to use NEW_CUSTOMER_ID
• Test AM_MARKETING_PERFORMANCE with new join
• Validate SAC stories still work

Phase 3: Deprecation

• Mark LEGACY_CUSTOMER_ID as deprecated (add to column description)
• Monitor usage for 30 days
• Remove LEGACY_CUSTOMER_ID if zero usage

Objects requiring changes: 4 views, 2 flows, 2 analytic models Estimated effort: 3-4 hours (vs several days of manual investigation)"

### Expected Results

**Lineage Report Generated:**
- Complete dependency tree from source to all consumers
- SQL definitions showing exact usage
- Impact analysis: 4 views, 2 flows, 2 models, 3 SAC stories
- Migration path with 3 phases
- Risk assessment: High (actively used in production SAC stories)

**Total Time**: 25 minutes (vs 3+ hours manually)

### ROI Analysis
- **Per investigation**: 2.5+ hours saved
- **Monthly savings**: ~10 hours (4 lineage analyses)
- **Annual value**: ~120 hours ($18,000+ at $150/hr)
- **Risk reduction**: Prevents breaking changes to production dashboards

---

## Use Case 3: The Pre-Analytics Data Quality Audit

### Persona
**Data Analyst**

### Time Saved
**2 hours per analysis project**

### Scenario
Lisa (Data Analyst) needs to build a Power BI dashboard using sales data from Datasphere. Before starting, she needs to validate:
- Data completeness
- Data freshness
- Data quality (nulls, outliers, distributions)
- Understanding of business logic

### MCP Tools Used
- `preview_data` - Sample data from tables
- `get_table_metadata` - Inspect table structure
- `analyze_column_distribution` - Profile data distributions
- `execute_smart_query` - Run aggregation queries
- `get_view_definition` - Understand view logic

### Conversational Workflow

**Lisa's Pre-Dashboard Audit:**

Lisa: "I'm building a sales dashboard. Can you help me understand the SALES_FACT table?"

Agent: "Analyzing SALES_FACT table..." [Uses get_table_metadata, preview_data]

Agent: "SALES_FACT structure:

Columns (12):

• SALES_ID (KEY, VARCHAR 10) - Primary key
• ORDER_DATE (DATE) - Order date
• CUSTOMER_ID (VARCHAR 10) - FK to DIM_CUSTOMER
• PRODUCT_ID (VARCHAR 10) - FK to DIM_PRODUCT
• REGION_ID (VARCHAR 5) - FK to DIM_REGION
• QUANTITY (DECIMAL 15,2) - Units sold
• REVENUE (DECIMAL 15,2) - Revenue amount
• COST (DECIMAL 15,2) - Cost amount
• DISCOUNT (DECIMAL 15,2) - Discount applied
• SALES_REP_ID (VARCHAR 10) - Sales representative
• STATUS (VARCHAR 20) - Order status
• CREATED_AT (TIMESTAMP) - Record creation time

Rows: 2,847,394 Storage: 487 MB Last modified: 2 hours ago

Would you like me to check data quality?"

Lisa: "Yes, please. I'm particularly concerned about completeness and outliers."

Agent: "Running data quality analysis..." [Uses analyze_column_distribution, execute_smart_query]

Agent: "Data Quality Report for SALES_FACT:

Completeness:

• SALES_ID: 100% populated ✅
• ORDER_DATE: 100% populated ✅
• CUSTOMER_ID: 99.8% populated ⚠️ (5,694 nulls)
• PRODUCT_ID: 100% populated ✅
• QUANTITY: 100% populated ✅
• REVENUE: 99.9% populated ⚠️ (2,847 nulls)
• COST: 97.2% populated ⚠️ (79,727 nulls)
• DISCOUNT: 88.5% populated ℹ️ (327,550 nulls - expected for non-discounted orders)
• STATUS: 100% populated ✅

Date Range:

• Earliest: 2022-01-01
• Latest: 2025-12-27 (today)
• Coverage: Complete (no gaps)

Outliers: Revenue Distribution:

• Min: $0.01
• Q1: $125.50
• Median: $487.25
• Q3: $1,243.75
• Max: $1,247,895.00 ⚠️

Found 127 orders with REVENUE > $100,000:

• 89 are B2B enterprise orders (normal)
• 38 are suspicious (investigating...)

Suspicious pattern: 38 orders from CUSTOMER_ID = 'CUST_TEST' with REVENUE > $100,000 but QUANTITY = 1. These appear to be test data that should be filtered."

Lisa: "How should I filter out test data?"

Agent: "Checking for test data patterns..." [Uses execute_smart_query]

Agent: "Recommended filters for production dashboard:

WHERE
    STATUS != 'TEST'
    AND CUSTOMER_ID NOT LIKE 'CUST_TEST%'
    AND CUSTOMER_ID NOT LIKE '%_TEST'
    AND ORDER_DATE >= '2024-01-01'  -- Focus on recent data
    AND REVENUE IS NOT NULL
    AND QUANTITY > 0

This filters:

• 412 test orders
• 2,847 null revenue rows
• 134 quantity=0 rows (returns)
• Pre-2024 historical data (unless needed)

Clean dataset: 2,691,478 rows (94.5% of total)"

Lisa: "What about the missing COST values? Will that affect my margin analysis?"

Agent: "Analyzing COST coverage..." [Uses execute_smart_query]

Agent: "COST field analysis:

Missing COST by category:

• Services: 78,234 rows (98% of missing) - Expected: services don't have COST
• Physical Products: 1,493 rows (2% of missing) - Data quality issue

For margin analysis:

• Filter to PRODUCT_TYPE = 'PHYSICAL' only
• COST coverage for physical products: 99.94%
• Remaining 1,493 rows: Contact data team for backfill

SQL for margin analysis:

SELECT
    REGION_ID,
    SUM(REVENUE) as TOTAL_REVENUE,
    SUM(COST) as TOTAL_COST,
    SUM(REVENUE - COST) as GROSS_MARGIN,
    (SUM(REVENUE - COST) / SUM(REVENUE)) * 100 as MARGIN_PCT
FROM SALES_FACT
WHERE
    STATUS NOT IN ('TEST', 'CANCELLED')
    AND PRODUCT_TYPE = 'PHYSICAL'
    AND COST IS NOT NULL
    AND ORDER_DATE >= '2024-01-01'
GROUP BY REGION_ID
```"

Lisa: "Perfect! Last question: how fresh is this data?"

Agent: "Checking data freshness..."
[Uses execute_smart_query, get_view_definition]

Agent: "Data Freshness:

SALES_FACT updates:
- Update frequency: Every 4 hours
- Last update: 2 hours ago (10:15 AM)
- Next update: 12:15 PM (in 2 hours)
- Data lag: ~30 minutes from source system

Freshness by date:
- Today (2025-12-27): 3,847 rows ✅
- Yesterday: 12,394 rows ✅
- Last 7 days: 87,234 rows ✅

Recommendation: Data is fresh and suitable for near real-time dashboards with 30-minute lag disclaimer."

Expected Results

Data Quality Audit Complete:

• Completeness: 5 warnings identified, 2 critical (CUSTOMER_ID, COST)
• Outliers: 127 high-value orders analyzed, 38 test records flagged
• Filters: Production-ready SQL filter provided
• Freshness: 30-minute lag confirmed, suitable for dashboards
• Coverage: 2.7M clean records ready for analysis

Total Time: 18 minutes (vs 2+ hours manually)

ROI Analysis

• Per project: 1.75 hours saved
• Monthly savings: ~14 hours (8 dashboard projects)
• Annual value: ~168 hours ($25,000+ at $150/hr)
• Quality improvement: Prevents dashboard errors from bad data

Use Case 4: The Onboarding Speedrun

Persona

New Data Engineer

Time Saved

2 days of exploration (initial onboarding)

Scenario

Alex (New Data Engineer) joins the team and needs to quickly understand the Datasphere landscape: what spaces exist, what data is available, key data flows, naming conventions, and where to find documentation.

MCP Tools Used

• list_spaces - Discover all spaces
• get_space_details - Understand space purpose
• list_space_objects - See what's in each space
• get_table_metadata - Understand key tables
• get_view_definition - See how views work
• list_data_flows - Understand ETL processes
• get_data_flow_details - Learn transformation logic
• search_catalog - Find specific objects
• get_tenant_info - Understand environment
• list_connections - See external systems
• get_analytic_model_structure - Understand analytics setup
• preview_data - See sample data

Conversational Workflow

Alex's First Day:

Alex: "Hi! I'm new to the team. Can you give me an overview of our Datasphere setup?"

Agent: "Welcome to the team! Let me give you a comprehensive tour..."
[Uses get_tenant_info, list_spaces]

Agent: "Datasphere Environment Overview:

Tenant: datasphere-prod.eu10.hcs.cloud.sap
Version: 2025.24
Storage: 250 GB used / 500 GB allocated
Active Spaces: 8

Spaces organized by function:

1. **DATA_INTEGRATION** (Production ETL)
   - Purpose: Landing zone for external data
   - Size: 87 GB
   - Objects: 45 tables, 12 data flows
   - Owner: Data Engineering team

2. **ANALYTICS** (Production Analytics)
   - Purpose: Consumption layer for reporting
   - Size: 123 GB
   - Objects: 78 views, 15 analytic models
   - Owner: Analytics team

3. **MASTER_DATA** (Reference Data)
   - Purpose: Dimensions and reference tables
   - Size: 12 GB
   - Objects: 23 tables, 8 views
   - Owner: Data Governance

4. **SALES** (Sales Domain)
   - Purpose: Sales-specific data marts
   - Size: 45 GB
   - Objects: 34 tables, 56 views, 8 models
   - Owner: Sales Analytics

5. **FINANCE** (Finance Domain)
   - Purpose: Financial reporting data
   - Size: 34 GB
   - Objects: 28 tables, 45 views, 6 models
   - Owner: Finance team

6. **MARKETING** (Marketing Domain)
   - Purpose: Marketing analytics
   - Size: 19 GB
   - Objects: 15 tables, 32 views, 4 models
   - Owner: Marketing Analytics

7. **SANDBOX** (Development)
   - Purpose: Experimentation and testing
   - Size: 8 GB
   - Objects: 67 mixed objects
   - Owner: All developers

8. **ARCHIVE** (Historical Data)
   - Purpose: Long-term storage
   - Size: 22 GB
   - Objects: 12 tables
   - Owner: Data Engineering

Would you like to explore any specific space?"

Alex: "Yes, tell me about the ANALYTICS space since I'll be working there."

Agent: "Diving into ANALYTICS space..."
[Uses get_space_details, list_space_objects]

Agent: "ANALYTICS Space Details:

**Purpose**: Production consumption layer for all reporting and dashboards

**Objects** (93 total):
Views (78):
- Prefix 'V_': Business views (54)
- Prefix 'V_RPT_': Report views (24)

Analytic Models (15):
- Prefix 'AM_': All analytic models
- Types: 8 fact models, 7 dimension models

**Key Views**:
- V_SALES_360: Comprehensive sales view (most accessed)
- V_CUSTOMER_MASTER: Customer dimension
- V_PRODUCT_CATALOG: Product dimension
- V_FINANCIAL_SUMMARY: Finance KPIs
- V_RPT_EXECUTIVE_DASHBOARD: Executive reporting

**Data Freshness**:
- Refreshed every 4 hours via ANALYTICS_REFRESH_FLOW
- Last refresh: 2 hours ago
- Average refresh time: 23 minutes

**Naming Conventions**:
- Views: V_[DOMAIN]_[ENTITY]
- Reports: V_RPT_[REPORT_NAME]
- Models: AM_[DOMAIN]_[SUBJECT]
- Staging: STG_[SOURCE]_[TABLE]

**Dependencies**:
- Sources: DATA_INTEGRATION, MASTER_DATA, SALES, FINANCE spaces
- Consumers: 47 SAC stories, 23 Power BI reports
- SLA: 99.5% uptime (measured monthly)"

Alex: "How does data flow from source systems into ANALYTICS?"

Agent: "Let me trace the data pipeline..."
[Uses list_data_flows, get_data_flow_details, list_connections]

Agent: "Data Pipeline Architecture:

**External Sources** (10 connections):
1. S4HANA_PROD (SAP S/4HANA) - ERP data
2. BW4_PROD (SAP BW/4HANA) - Historical warehouse
3. SNOWFLAKE_EXTERNAL (Snowflake) - Marketing data
4. SALESFORCE_API (Salesforce) - CRM data
5. AWS_S3_BUCKET (AWS S3) - File uploads
6. AZURE_SYNAPSE (Azure) - External analytics
7. SAP_CONCUR (Concur) - Expense data
8. WORKDAY_HR (Workday) - HR data
9. KAFKA_STREAMING (Kafka) - Real-time events
10. GENERIC_HTTP_API (HTTP) - REST APIs

**Data Flow Pipeline**:

Stage 1: INGESTION (DATA_INTEGRATION space)
├─ S4HANA_PROD → REPLICATION_FLOW_S4 (every 4h)
│  └─ Tables: RAW_SALES, RAW_ORDERS, RAW_CUSTOMERS
├─ BW4_PROD → HISTORICAL_SYNC_FLOW (daily)
│  └─ Tables: HIST_SALES, HIST_FINANCIALS
└─ SALESFORCE_API → CRM_INTEGRATION_FLOW (hourly)
   └─ Tables: CRM_ACCOUNTS, CRM_OPPORTUNITIES

Stage 2: TRANSFORMATION (MASTER_DATA space)
├─ CUSTOMER_MDM_FLOW
│  └─ Merges RAW_CUSTOMERS + CRM_ACCOUNTS → DIM_CUSTOMER
├─ PRODUCT_MDM_FLOW
│  └─ Standardizes product data → DIM_PRODUCT
└─ CALENDAR_GENERATION_FLOW
   └─ Generates fiscal calendar → DIM_DATE

Stage 3: BUSINESS LOGIC (SALES/FINANCE spaces)
├─ SALES_ENRICHMENT_FLOW
│  └─ Joins facts + dimensions → SALES_FACT
└─ FINANCE_AGGREGATION_FLOW
   └─ Calculates KPIs → FINANCE_FACT

Stage 4: CONSUMPTION (ANALYTICS space)
├─ ANALYTICS_REFRESH_FLOW (orchestrator)
│  ├─ Refreshes V_SALES_360
│  ├─ Refreshes V_CUSTOMER_MASTER
│  └─ Refreshes all V_RPT_* views
└─ MODEL_REFRESH_FLOW
   └─ Updates all AM_* analytic models

**Orchestration**:
- Triggered by: Task Chain 'DAILY_FULL_REFRESH'
- Schedule: Every 4 hours (6 AM, 10 AM, 2 PM, 6 PM, 10 PM, 2 AM)
- Duration: ~45 minutes end-to-end
- Monitoring: Automated alerts via Cloud Logging"

Alex: "Can you show me a concrete example of how V_SALES_360 is built?"

Agent: "Showing V_SALES_360 definition..."
[Uses get_view_definition]

Agent: "V_SALES_360 View Structure:

```sql
CREATE VIEW V_SALES_360 AS
SELECT
    -- Keys
    s.SALES_ID,
    s.ORDER_DATE,

    -- Customer dimension
    c.CUSTOMER_ID,
    c.CUSTOMER_NAME,
    c.CUSTOMER_SEGMENT,
    c.COUNTRY,
    c.REGION,

    -- Product dimension
    p.PRODUCT_ID,
    p.PRODUCT_NAME,
    p.CATEGORY,
    p.BRAND,

    -- Sales measures
    s.QUANTITY,
    s.REVENUE,
    s.COST,
    s.REVENUE - s.COST AS GROSS_MARGIN,
    (s.REVENUE - s.COST) / s.REVENUE * 100 AS MARGIN_PCT,
    s.DISCOUNT,

    -- Time attributes
    d.FISCAL_YEAR,
    d.FISCAL_QUARTER,
    d.FISCAL_PERIOD,
    d.YEAR_MONTH,

    -- Sales rep
    sr.REP_NAME,
    sr.TEAM,
    sr.MANAGER

FROM SALES.SALES_FACT s
LEFT JOIN MASTER_DATA.DIM_CUSTOMER c ON s.CUSTOMER_ID = c.CUSTOMER_ID
LEFT JOIN MASTER_DATA.DIM_PRODUCT p ON s.PRODUCT_ID = p.PRODUCT_ID
LEFT JOIN MASTER_DATA.DIM_DATE d ON s.ORDER_DATE = d.DATE_KEY
LEFT JOIN MASTER_DATA.DIM_SALES_REP sr ON s.SALES_REP_ID = sr.REP_ID

WHERE s.STATUS = 'COMPLETED'
  AND s.ORDER_DATE >= '2024-01-01'

View Characteristics:

• Type: SQL View (not materialized)
• Performance: ~2-3 seconds for ad-hoc queries
• Data volume: 2.7M rows after filters
• Used by: 12 SAC stories, 8 Power BI reports
• Update frequency: Real-time (based on underlying tables)

Best Practices for querying:

• Always filter on ORDER_DATE (indexed)
• Limit results for exploratory queries
• Use CUSTOMER_ID or PRODUCT_ID filters for better performance
• Analytic models (AM_SALES_ANALYSIS) provide faster aggregations"

Alex: "This is incredibly helpful! Can you give me a sample data preview?"

Agent: "Fetching sample data..." [Uses preview_data]

Agent: "Sample data from V_SALES_360 (5 rows):

Data looks clean and production-ready!"

### Expected Results

**Onboarding Knowledge Acquired:**
- Complete tenant architecture understood (8 spaces, 300+ objects)
- Data pipeline flow mapped (4 stages, 10 source systems)
- Naming conventions learned (V_, AM_, STG_ prefixes)
- Key views and models identified (V_SALES_360, AM_SALES_ANALYSIS)
- Sample data previewed
- Best practices documented (filtering, performance tips)

**Total Time**: 45 minutes (vs 2 days of UI exploration)

### ROI Analysis
- **Per new hire**: 15+ hours saved (2 days → 45 minutes)
- **Annual savings**: ~60 hours (4 new hires per year)
- **Value**: $9,000+ at $150/hr
- **Productivity**: New hires productive on day 1 vs week 2

---

## Use Case 5: The Marketplace Shopping Spree

### Persona
**Analytics Team Lead**

### Time Saved
**1 hour per evaluation** (pre-built content discovery)

### Scenario
Jennifer (Analytics Team Lead) needs to find pre-built analytics content for retail use cases. She wants to explore the Datasphere Marketplace for ready-made analytic models, dashboards, and best-practice templates before building from scratch.

### MCP Tools Used
- `search_marketplace` - Search Data Marketplace
- `get_marketplace_product_details` - Get product information
- `list_marketplace_categories` - Browse categories

### Conversational Workflow

**Jennifer's Marketplace Exploration:**

Jennifer: "I need retail analytics for our new e-commerce project. What's available in the Datasphere Marketplace?"

Agent: "Searching Datasphere Marketplace for retail analytics..." [Uses search_marketplace, list_marketplace_categories]

Agent: "Found 12 retail analytics products in the Marketplace:

Featured Products:

1. SAP Retail Analytics Accelerator by SAP

   • Category: Pre-built Analytics
   • Price: Free (SAP content)
   • Rating: 4.8/5 (127 reviews)
   • Includes:
     • 8 analytic models (Sales, Inventory, Customer Behavior)
     • 15 pre-configured KPIs
     • 6 SAC dashboard templates
     • Best practice data models
   • Last updated: 2025-11-15
   • Downloads: 2,340

2. E-Commerce Performance Suite by DataSphere Partners

   • Category: Commercial Content
   • Price: $499/month (subscription)
   • Rating: 4.6/5 (89 reviews)
   • Includes:
     • 12 analytic models
     • Real-time conversion tracking
     • Customer journey analysis
     • A/B testing framework
   • Last updated: 2025-12-10
   • Downloads: 876

3. Retail Inventory Optimization by SAP Community

   • Category: Community Content
   • Price: Free
   • Rating: 4.4/5 (54 reviews)
   • Includes:
     • Inventory turnover models
     • Stock-out prediction
     • Reorder point optimization
   • Last updated: 2025-10-22
   • Downloads: 1,234

Would you like details on any of these?"

Jennifer: "Tell me more about the SAP Retail Analytics Accelerator."

Agent: "Fetching detailed information..." [Uses get_marketplace_product_details]

Agent: "SAP Retail Analytics Accelerator - Full Details:

Overview: Pre-built analytics package designed for retail businesses. Provides industry best practices and accelerates time-to-insight from weeks to days.

What's Included:

Analytic Models (8):

• AM_RETAIL_SALES: Daily/weekly/monthly sales analysis
• AM_INVENTORY_ANALYSIS: Stock levels, turnover, aging
• AM_CUSTOMER_SEGMENTS: RFM segmentation, customer value
• AM_PRODUCT_PERFORMANCE: SKU analysis, top/bottom products
• AM_STORE_COMPARISON: Multi-store benchmarking
• AM_PROMOTION_EFFECTIVENESS: Campaign ROI analysis
• AM_SEASONAL_TRENDS: Seasonality patterns
• AM_FORECAST_BASELINE: Sales forecasting foundation

Views (24):

• Dimension views: Customer, Product, Store, Time
• Fact views: Sales, Inventory, Promotions
• Aggregated views: Daily summaries, weekly KPIs

SAC Dashboards (6):

• Executive Overview
• Sales Performance
• Inventory Health
• Customer Insights
• Store Operations
• Promotion Analytics

Data Requirements: Tables you need:

• SALES_TRANSACTION (fact)
• DIM_CUSTOMER (dimension)
• DIM_PRODUCT (dimension)
• DIM_STORE (dimension)
• DIM_DATE (dimension)
• INVENTORY_SNAPSHOT (periodic fact)

Mapping Assistant: The package includes a data mapping tool to connect your existing tables to the pre-built models.

Installation:

• Estimated time: 30 minutes (with mapping)
• Space required: ~2 GB
• Prerequisites: Datasphere 2025.20+

Support:

• Documentation: Complete implementation guide
• Video tutorials: 8 walkthrough videos
• Community: Active discussion forum
• SAP Support: Included (for SAP customers)

Reviews Highlight:

• 'Saved us 3 weeks of development time' ⭐⭐⭐⭐⭐
• 'Best practice models are exactly what we needed' ⭐⭐⭐⭐⭐
• 'Data mapping tool made integration painless' ⭐⭐⭐⭐⭐
• 'Some customization needed for our business' ⭐⭐⭐⭐

Download Count: 2,340 (trending) Success Rate: 94% (users who left reviews marked as successful)

Would you like to see the installation process?"

Jennifer: "Yes, and how does it compare to the E-Commerce Performance Suite?"

Agent: "Comparing the two products..."

Agent: "Comparison: SAP Retail Analytics vs E-Commerce Performance Suite

Recommendation:

• Start with SAP Retail Analytics (free)
• Evaluate for 30 days
• Upgrade to E-Commerce Suite if you need:
  • Real-time streaming data
  • Advanced ML/AI predictions
  • A/B testing framework
  • Premium support

Many customers use SAP Retail as foundation and add E-Commerce Suite for specific advanced features (hybrid approach)."

Jennifer: "Perfect! How do I install the SAP Retail Analytics Accelerator?"

Agent: "I'll guide you through installation. First, let me check if your data meets requirements..."

Agent: "Installation Plan for SAP Retail Analytics Accelerator:

Step 1: Pre-Installation Check ✅

• Datasphere version: 2025.24 (compatible)
• Available storage: 250 GB free (only need 2 GB)
• User permissions: Space administrator (you have this)
• Prerequisites met: Ready to install

Step 2: Download & Import (5 minutes)

1. Download package from Marketplace
2. Import CSN bundle into your ANALYTICS space
3. Package includes: 8 models, 24 views, 6 dashboards

Step 3: Data Mapping (20 minutes) Map your existing tables to required structures:

Your Table → Required Table:

• SALES.SALES_FACT → SALES_TRANSACTION ✅ Compatible
• MASTER_DATA.DIM_CUSTOMER → DIM_CUSTOMER ✅ Compatible
• MASTER_DATA.DIM_PRODUCT → DIM_PRODUCT ✅ Compatible
• SALES.STORE_MASTER → DIM_STORE ⚠️ Missing 3 fields (will add)
• MASTER_DATA.DIM_DATE → DIM_DATE ✅ Compatible
• DATA_INTEGRATION.INVENTORY_DAILY → INVENTORY_SNAPSHOT ✅ Compatible

Missing Fields to Add:

• DIM_STORE.STORE_SIZE_SQFT (add or map from existing)
• DIM_STORE.STORE_FORMAT (e.g., 'Mall', 'Standalone')
• DIM_STORE.MANAGER_NAME (optional)

Step 4: Validation (5 minutes)

• Run validation script (included)
• Preview sample data in each model
• Test one dashboard

Total Time: ~30 minutes Complexity: Low (mostly automated)

Ready to proceed?"

### Expected Results

**Marketplace Discovery Complete:**
- 12 retail analytics products found and evaluated
- Detailed comparison: SAP Retail (free) vs E-Commerce Suite (paid)
- Installation plan: 30 minutes, low complexity
- Data mapping: 90% compatible with existing data
- Decision: Start with free SAP content, evaluate for 30 days

**Total Time**: 22 minutes (vs 1+ hour manually browsing Marketplace UI)

### ROI Analysis
- **Per evaluation**: 40 minutes saved
- **Monthly savings**: ~5 hours (8 marketplace evaluations)
- **Annual value**: ~60 hours ($9,000+ at $150/hr)
- **Development savings**: 3 weeks avoided by using pre-built content

---

## Use Case 6: The Security Audit

### Persona
**Data Governance Manager**

### Time Saved
**4 hours per audit** (quarterly compliance review)

### Scenario
Robert (Data Governance Manager) conducts quarterly security audits to ensure compliance with data privacy regulations (GDPR, CCPA). He needs to identify:
- Personally Identifiable Information (PII) in tables
- Who has access to PII data
- Data retention compliance
- Unused database users

### MCP Tools Used
- `search_catalog` - Find tables with PII
- `get_table_metadata` - Inspect sensitive columns
- `list_database_users` - List all DB users
- `get_space_permissions` - Audit space access
- `get_user_permissions` - Check individual user rights
- `execute_query` - Check data retention compliance
- `analyze_column_distribution` - Detect data classification

### Conversational Workflow

**Robert's Quarterly Security Audit:**

Robert: "I need to run our Q4 security audit. Can you help identify all tables containing PII data?"

Agent: "Starting PII discovery across all spaces..." [Uses search_catalog, get_table_metadata]

Agent: "PII Data Discovery Report:

High Risk - Direct PII (Tables containing sensitive personal data):

1. MASTER_DATA.DIM_CUSTOMER

   • PII Columns:
     • EMAIL_ADDRESS (2,847,394 rows)
     • PHONE_NUMBER (2,845,120 rows)
     • DATE_OF_BIRTH (2,234,567 rows)
     • SSN (encrypted) (1,234,890 rows)
     • HOME_ADDRESS (2,789,456 rows)
   • Classification: RESTRICTED
   • Retention Policy: 7 years after last transaction
   • Encryption: SSN encrypted at rest

2. DATA_INTEGRATION.RAW_CUSTOMER_DATA

   • PII Columns:
     • FULL_NAME, EMAIL, PHONE, ADDRESS, DOB, CREDIT_CARD (last 4 digits)
   • Classification: RESTRICTED
   • Retention Policy: 90 days (staging only)
   • ⚠️ WARNING: 127 rows older than 90 days (should be deleted)

3. SALES.EMPLOYEE_INFO

   • PII Columns:
     • EMPLOYEE_EMAIL, EMPLOYEE_PHONE, SALARY, BANK_ACCOUNT
   • Classification: CONFIDENTIAL
   • Retention Policy: Active employees + 3 years
   • ⚠️ WARNING: Found 12 terminated employees from 4+ years ago

4. MARKETING.CUSTOMER_PROFILES

   • PII Columns:
     • EMAIL, LOCATION_DATA, BROWSING_HISTORY, IP_ADDRESS
   • Classification: RESTRICTED
   • Retention Policy: User consent-based
   • ⚠️ WARNING: Missing consent tracking

Medium Risk - Indirect PII:

• SALES.SALES_FACT (CUSTOMER_ID - pseudonymized)
• FINANCE.INVOICE_DETAILS (CUSTOMER_ID - pseudonymized)

Low Risk - Aggregated Only:

• ANALYTICS.V_CUSTOMER_SEGMENTS (no direct identifiers)
• ANALYTICS.AM_SALES_ANALYSIS (aggregated only)

Compliance Issues Found: 3 critical, 5 warnings"

Robert: "Show me who has access to these PII tables."

Agent: "Auditing access permissions..." [Uses get_space_permissions, list_database_users]

Agent: "Access Audit Report:

MASTER_DATA.DIM_CUSTOMER (RESTRICTED):

Space-Level Access:

• MASTER_DATA space: 23 users with READ access
• Breakdown:
  • Data Engineers (8 users): Full access ✅ (required for ETL)
  • Analytics Team (12 users): Read-only ✅ (required for reports)
  • External Contractors (3 users): Read access ⚠️ (requires review)

Database Users with Direct Access:

• ETL_SERVICE_ACCOUNT: Full access ✅
• ANALYTICS_SERVICE_ACCOUNT: Read-only ✅
• JOHN_DOE_TEMP: Full access ⚠️ (created 6 months ago, never used)
• MIGRATION_USER_2024: Full access ⚠️ (migration completed, should be deleted)

Issues Identified:

1. ⚠️ 3 External Contractors with PII Access:

   • contractor_smith@vendor.com (last login: 3 months ago)
   • contractor_jones@vendor.com (last login: 6 months ago)
   • contractor_wilson@vendor.com (active)

   Recommendation:

   • Revoke access for Smith (inactive)
   • Revoke access for Jones (inactive)
   • Review Wilson's access necessity

2. ⚠️ 2 Unused Database Users:

   • JOHN_DOE_TEMP (created 2025-06-15, never logged in)
   • MIGRATION_USER_2024 (last login: 2025-03-10)

   Recommendation: Delete both users

3. ⚠️ 5 Users with Excessive Permissions:

   • analyst_sarah has SPACE ADMIN (only needs READ)
   • analyst_mike has FULL ACCESS (only needs READ on views)
   • [3 more users...]

   Recommendation: Apply principle of least privilege

GDPR Compliance:

• Right to Access: ✅ Implemented (query by CUSTOMER_ID)
• Right to Erasure: ⚠️ Missing automated deletion workflow
• Right to Portability: ✅ Implemented (export functionality)
• Data Breach Notification: ⚠️ No monitoring alerts configured

CCPA Compliance:

• Consumer Data Rights: ✅ Implemented
• Opt-Out Mechanisms: ✅ Implemented
• Data Sale Tracking: N/A (not selling data)"

Robert: "Check data retention compliance. Are we keeping data longer than policy allows?"

Agent: "Running data retention audit..." [Uses execute_query]

Agent: "Data Retention Compliance Report:

Policy Violations:

1. DATA_INTEGRATION.RAW_CUSTOMER_DATA

   • Policy: 90 days retention (staging)
   • Violations: 127 rows from 95-180 days ago
   • Oldest record: 2025-06-15 (180 days ago)
   • Action: DELETE 127 rows
   • SQL:

   DELETE FROM DATA_INTEGRATION.RAW_CUSTOMER_DATA
   WHERE CREATED_AT < CURRENT_DATE - 90

2. SALES.EMPLOYEE_INFO

   • Policy: Active + 3 years
   • Violations: 12 terminated employees from 2020-2021
   • Records:
     • EMPLOYEE_ID: E123456 (terminated: 2020-04-15, 4.6 years ago)
     • EMPLOYEE_ID: E234567 (terminated: 2021-02-10, 3.9 years ago)
     • [10 more...]
   • Action: ANONYMIZE or DELETE 12 records
   • SQL:

   UPDATE SALES.EMPLOYEE_INFO
   SET
     FULL_NAME = 'REDACTED',
     EMAIL = NULL,
     PHONE = NULL,
     SALARY = NULL,
     BANK_ACCOUNT = NULL
   WHERE
     TERMINATION_DATE < CURRENT_DATE - INTERVAL '3 YEARS'
     AND DATA_RETENTION_STATUS != 'ANONYMIZED'

3. MARKETING.CUSTOMER_PROFILES

   • Policy: Consent-based (no consent = 1 year max)
   • Violations: 3,456 rows without consent older than 1 year
   • Action: DELETE or obtain consent
   • Estimated cleanup: 3,456 rows

Compliant Tables:

• ✅ MASTER_DATA.DIM_CUSTOMER (all within 7-year policy)
• ✅ SALES.SALES_FACT (all within retention)
• ✅ FINANCE.INVOICE_DETAILS (all within legal retention)

Recommendations:

1. Implement automated retention policies (Datasphere lifecycle management)
2. Schedule monthly retention checks
3. Add retention warnings to data flows
4. Create audit trail for deletions"

Robert: "Generate a summary report for the compliance team."

Agent: "Generating Executive Summary..."

Agent: "Q4 2025 Data Security & Compliance Audit - Executive Summary

Audit Date: 2025-12-27 Auditor: Robert Chen (Data Governance Manager) Scope: All Datasphere spaces, 8 spaces, 300+ objects

Overall Status: ⚠️ REQUIRES ACTION

1. PII Data Inventory

• High-risk tables: 4 (containing direct PII)
• Medium-risk tables: 2 (pseudonymized identifiers)
• Low-risk tables: 15 (aggregated only)
• Total PII records: ~8.5M rows across 4 tables

2. Access Control

• Total users with PII access: 23 (space-level) + 4 (database users)
• ⚠️ Issues:
  • 3 external contractors (2 inactive, requires revocation)
  • 2 unused database users (requires deletion)
  • 5 users with excessive permissions (requires downgrade)
• ✅ Compliant: 13 users (proper access levels)

3. Data Retention Compliance

• ⚠️ Policy violations: 3 tables
  • RAW_CUSTOMER_DATA: 127 rows overdue
  • EMPLOYEE_INFO: 12 records overdue
  • CUSTOMER_PROFILES: 3,456 records overdue
• Total records requiring action: 3,595

4. Encryption & Security

• ✅ SSN encrypted at rest
• ✅ HTTPS for data in transit
• ⚠️ Missing: Encryption for CREDIT_CARD field (last 4 digits)

5. GDPR Compliance

• ✅ Right to Access
• ⚠️ Right to Erasure (no automated workflow)
• ✅ Right to Portability
• ⚠️ Data Breach Monitoring (not configured)

6. CCPA Compliance

• ✅ Consumer Data Rights
• ✅ Opt-Out Mechanisms
• ✅ Data Sale Tracking (N/A)

Action Items (Priority Order):

Immediate (This Week):

1. Revoke access for 2 inactive contractors
2. Delete 2 unused database users
3. Delete 127 overdue staging records (RAW_CUSTOMER_DATA)

Short-term (This Month): 4. Anonymize 12 terminated employee records 5. Downgrade 5 users with excessive permissions 6. Obtain consent or delete 3,456 marketing profile records 7. Implement automated retention policies

Long-term (Next Quarter): 8. Configure data breach monitoring alerts 9. Automate Right to Erasure workflow 10. Add encryption for CREDIT_CARD field 11. Schedule monthly retention audits

Risk Assessment:

• Current Risk Level: MEDIUM
• Post-Remediation Risk: LOW
• Estimated Remediation Time: 2-3 weeks
• Compliance Status: 85% compliant (target: 98%+)

Prepared by: SAP Datasphere MCP Agent Report Date: 2025-12-27 Next Audit Due: 2026-03-27 (Q1 2026)"

### Expected Results

**Security Audit Complete:**
- PII inventory: 4 high-risk tables, 8.5M PII records identified
- Access violations: 10 issues (2 critical, 8 warnings)
- Retention violations: 3,595 records overdue for deletion/anonymization
- Compliance score: 85% (target: 98%+)
- Action plan: 11 tasks prioritized (3 immediate, 4 short-term, 4 long-term)

**Total Time**: 35 minutes (vs 4+ hours manually)

### ROI Analysis
- **Per audit**: 3.5 hours saved
- **Annual savings**: ~14 hours (4 quarterly audits)
- **Value**: $2,100+ at $150/hr
- **Risk reduction**: Prevents GDPR/CCPA violations (penalties up to 4% revenue)

---

## Use Case 7: The Performance Troubleshooter

### Persona
**Data Platform Engineer**

### Time Saved
**1.5 hours per incident** (performance troubleshooting)

### Scenario
David (Data Platform Engineer) receives alerts that the SALES_ANALYTICS dashboard is slow. Users report 30+ second load times (vs 3-5 seconds normally). He needs to quickly identify the root cause and fix it.

### MCP Tools Used
- `get_analytic_model_structure` - Inspect model structure
- `execute_smart_query` - Test query performance
- `get_view_definition` - Analyze view logic
- `analyze_column_distribution` - Check data skew
- `get_data_flow_status` - Check ETL performance
- `get_table_metadata` - Inspect table structures
- `list_space_objects` - Find related objects
- `preview_data` - Sample data for testing
- `get_query_statistics` - Analyze query execution

### Conversational Workflow

**David's Performance Investigation:**

David: "Users are reporting the SALES_ANALYTICS dashboard is extremely slow. Can you help diagnose the issue?"

Agent: "Starting performance investigation for SALES_ANALYTICS..." [Uses get_analytic_model_structure, get_query_statistics]

Agent: "Initial Performance Analysis:

Dashboard: SALES_ANALYTICS (SAC Story ID: ST_12847) Data Source: AM_SALES_ANALYSIS (Analytic Model) Current Performance:

• Query time: 34.7 seconds ⚠️ (baseline: 3.2 seconds)
• Data volume: 2.7M rows (normal)
• Last successful refresh: 2 hours ago

Performance Degradation: 10x slower than baseline

Let me analyze the analytic model structure..." [Uses get_analytic_model_structure]

Agent: "AM_SALES_ANALYSIS Model Structure:

Fact Source: V_SALES_360 (view) Dimensions (8):

• DIM_CUSTOMER (2.8M members)
• DIM_PRODUCT (45K members)
• DIM_DATE (1,095 days = 3 years)
• DIM_REGION (127 members)
• DIM_SALES_REP (234 members)
• DIM_STORE (89 members)
• DIM_PROMOTION (456 members)
• DIM_CHANNEL (6 members)

Measures (12):

• REVENUE, COST, GROSS_MARGIN (base)
• QTY_SOLD, AVG_PRICE, MARGIN_PCT (calculated)
• REVENUE_YOY, REVENUE_MOM (time calculations)
• CUSTOMER_COUNT, ORDER_COUNT (distinct counts)
• TOP_10_PRODUCTS, BOTTOM_10_PRODUCTS (rank functions)

Recent Changes: ⚠️ DIM_CUSTOMER grew from 2.3M → 2.8M members (500K new customers in 2 days) ⚠️ BOTTOM_10_PRODUCTS measure added yesterday (complex rank calculation)

Let me check V_SALES_360 performance..." [Uses execute_smart_query, get_view_definition]

Agent: "V_SALES_360 Performance Test:

Simple Query (10 seconds):

SELECT TOP 100 * FROM V_SALES_360

Result: 0.8 seconds ✅ (normal)

Aggregation Query (like dashboard):

SELECT
    CUSTOMER_NAME,
    SUM(REVENUE) as TOTAL_REVENUE
FROM V_SALES_360
WHERE ORDER_DATE >= '2024-01-01'
GROUP BY CUSTOMER_NAME

Result: 32.4 seconds ⚠️ (was 2.8 seconds last week)

Root Cause Identified: V_SALES_360 view joins with DIM_CUSTOMER (2.8M rows). The DIM_CUSTOMER table is now too large for efficient joins.

Let me inspect DIM_CUSTOMER..." [Uses get_table_metadata, analyze_column_distribution]

Agent: "DIM_CUSTOMER Analysis:

Table Stats:

• Rows: 2,847,394 (was 2,300,000 last week)
• Size: 487 MB (was 392 MB)
• Growth: +547,394 rows (+23.8%) in 2 days ⚠️

Data Distribution:

• Customer Type:
  • B2B: 45,234 rows (2%)
  • B2C: 2,802,160 rows (98%)
• Status:
  • ACTIVE: 1,234,567 rows (43%)
  • INACTIVE: 1,612,827 rows (57%) ⚠️
• Country: 127 countries

Problem: The table includes 1.6M INACTIVE customers. The dashboard only needs ACTIVE customers, but V_SALES_360 joins ALL customers, causing massive join overhead.

V_SALES_360 Definition:

SELECT ...
FROM SALES.SALES_FACT s
LEFT JOIN MASTER_DATA.DIM_CUSTOMER c ON s.CUSTOMER_ID = c.CUSTOMER_ID

The LEFT JOIN pulls ALL 2.8M customers, even though only 1.2M are active.

Recommendation 1: Add WHERE filter to V_SALES_360

LEFT JOIN MASTER_DATA.DIM_CUSTOMER c
    ON s.CUSTOMER_ID = c.CUSTOMER_ID
    AND c.STATUS = 'ACTIVE'  -- Add filter to join

Recommendation 2: Create filtered view DIM_CUSTOMER_ACTIVE

CREATE VIEW DIM_CUSTOMER_ACTIVE AS
SELECT * FROM DIM_CUSTOMER WHERE STATUS = 'ACTIVE'

Then change V_SALES_360 to use DIM_CUSTOMER_ACTIVE.

Which approach would you prefer?"

David: "Let's go with Recommendation 2 - creating DIM_CUSTOMER_ACTIVE view. That way other views can benefit too."

Agent: "Good choice! Let me also check for other performance issues while we're here..." [Uses execute_smart_query, get_analytic_model_structure]

Agent: "Additional Performance Issues Found:

Issue 2: BOTTOM_10_PRODUCTS measure The measure added yesterday uses RANK() function across ALL products (45K) for EVERY query execution.

Current logic:

RANK() OVER (ORDER BY SUM(REVENUE) ASC)

This calculates ranks for 45K products on every dashboard load, even if user only requests top/bottom 10.

Recommendation: Pre-calculate ranks in a materialized view or change analytic model to use TOP/BOTTOM filters instead of RANK().

Issue 3: Missing Indexes DIM_CUSTOMER.CUSTOMER_ID is not indexed (primary key only) V_SALES_360 joins on CUSTOMER_ID causing full table scan.

Recommendation: Add index:

CREATE INDEX IDX_DIM_CUSTOMER_ID ON DIM_CUSTOMER(CUSTOMER_ID, STATUS)

Issue 4: Data Skew 98% of customers are B2C, causing skewed joins. Consider partitioning by CUSTOMER_TYPE.

Summary of Fixes:

1. Create DIM_CUSTOMER_ACTIVE view (immediate: -80% join size)
2. Add index on CUSTOMER_ID (immediate: faster lookups)
3. Remove BOTTOM_10_PRODUCTS or materialize (short-term)
4. Consider partitioning DIM_CUSTOMER (long-term)

Expected Performance After Fixes:

• Current: 34.7 seconds
• After Fix 1+2: ~4-5 seconds (90% improvement)
• After Fix 3: ~3 seconds (baseline restored)

Shall I generate the SQL scripts for Fix 1 and 2?"

David: "Yes, generate the scripts and estimate the impact."

Agent: "Generating implementation scripts..."

Agent: "Performance Fix Scripts:

Fix 1: Create Filtered Customer View (5 minutes to implement)

-- Create active customer view
CREATE VIEW MASTER_DATA.DIM_CUSTOMER_ACTIVE AS
SELECT
    CUSTOMER_ID,
    CUSTOMER_NAME,
    CUSTOMER_SEGMENT,
    COUNTRY,
    REGION,
    EMAIL_ADDRESS,
    PHONE_NUMBER,
    DATE_OF_BIRTH,
    CUSTOMER_TYPE,
    CREATED_DATE,
    LAST_ORDER_DATE
FROM MASTER_DATA.DIM_CUSTOMER
WHERE STATUS = 'ACTIVE';

-- Grant permissions (copy from DIM_CUSTOMER)
GRANT SELECT ON MASTER_DATA.DIM_CUSTOMER_ACTIVE TO ANALYTICS_ROLE;

Fix 2: Update V_SALES_360 (2 minutes to implement)

-- Update V_SALES_360 to use filtered view
CREATE OR REPLACE VIEW ANALYTICS.V_SALES_360 AS
SELECT
    s.SALES_ID,
    s.ORDER_DATE,
    c.CUSTOMER_ID,
    c.CUSTOMER_NAME,
    c.CUSTOMER_SEGMENT,
    c.COUNTRY,
    c.REGION,
    p.PRODUCT_ID,
    p.PRODUCT_NAME,
    p.CATEGORY,
    p.BRAND,
    s.QUANTITY,
    s.REVENUE,
    s.COST,
    s.REVENUE - s.COST AS GROSS_MARGIN,
    (s.REVENUE - s.COST) / s.REVENUE * 100 AS MARGIN_PCT,
    s.DISCOUNT,
    d.FISCAL_YEAR,
    d.FISCAL_QUARTER,
    d.FISCAL_PERIOD,
    sr.REP_NAME,
    sr.TEAM
FROM SALES.SALES_FACT s
LEFT JOIN MASTER_DATA.DIM_CUSTOMER_ACTIVE c  -- Changed to _ACTIVE
    ON s.CUSTOMER_ID = c.CUSTOMER_ID
LEFT JOIN MASTER_DATA.DIM_PRODUCT p
    ON s.PRODUCT_ID = p.PRODUCT_ID
LEFT JOIN MASTER_DATA.DIM_DATE d
    ON s.ORDER_DATE = d.DATE_KEY
LEFT JOIN MASTER_DATA.DIM_SALES_REP sr
    ON s.SALES_REP_ID = sr.REP_ID
WHERE s.STATUS = 'COMPLETED'
  AND s.ORDER_DATE >= '2024-01-01';

Fix 3: Add Index (1 minute to implement)

-- Add composite index for fast lookups
CREATE INDEX IDX_DIM_CUSTOMER_STATUS_ID
ON MASTER_DATA.DIM_CUSTOMER(STATUS, CUSTOMER_ID);

-- Gather statistics for query optimizer
ANALYZE TABLE MASTER_DATA.DIM_CUSTOMER;

Impact Analysis:

Rollout Plan:

1. Test in SANDBOX (10 minutes):

   • Create DIM_CUSTOMER_ACTIVE
   • Update copy of V_SALES_360
   • Run test queries
   • Validate results match production

2. Deploy to PRODUCTION (5 minutes):

   • Create DIM_CUSTOMER_ACTIVE
   • Update V_SALES_360
   • Add index
   • Clear analytic model cache

3. Validate (5 minutes):

   • Test SALES_ANALYTICS dashboard
   • Verify load time < 5 seconds
   • Check data accuracy

4. Monitor (ongoing):

   • Track dashboard performance daily
   • Alert if load time > 10 seconds
   • Review DIM_CUSTOMER growth weekly

Total Implementation Time: 20 minutes (vs 4+ hours of trial-and-error)"

### Expected Results

**Performance Issue Resolved:**
- Root cause: 57% inactive customers causing slow joins
- Fix: Create filtered view (1.2M active vs 2.8M total)
- Performance improvement: 34.7s → 3.2s (90% faster)
- Implementation time: 20 minutes
- User impact: Dashboard back to normal performance

**Total Time**: 28 minutes (vs 1.5+ hours trial-and-error)

### ROI Analysis
- **Per incident**: 1 hour saved
- **Monthly savings**: ~8 hours (8 performance incidents)
- **Annual value**: ~96 hours ($14,000+ at $150/hr)
- **Downtime reduction**: 20 minutes vs 2+ hours (90% faster resolution)

---

## Use Case 8: The Cross-Functional Collaboration

### Persona
**Business Analyst + Data Engineer**

### Time Saved
**3 hours of back-and-forth** (collaborative problem-solving)

### Scenario
Lisa (Business Analyst) needs to understand why the "Sales by Region" report shows unexpected results. Marcus (Data Engineer) needs to explain the data logic. Traditionally, this requires multiple meetings, screenshots, and email chains. With MCP, they collaborate in a shared conversation.

### MCP Tools Used
- `get_view_definition` - Show business analyst the SQL
- `preview_data` - Show sample results
- `execute_smart_query` - Test hypotheses
- `get_table_metadata` - Explain data structures
- `analyze_column_distribution` - Validate data quality
- `get_analytic_model_structure` - Explain analytic model logic

### Conversational Workflow

**Shared Conversation Between Lisa and Marcus:**

Lisa: "Hi Marcus! The 'Sales by Region' report is showing Europe with higher sales than North America, but that doesn't match our expectations. Can you help me understand what's happening?"

Agent (assisting Marcus): "Let me pull up the report definition..." [Uses get_analytic_model_structure, get_view_definition]

Agent: "The 'Sales by Region' report uses AM_REGIONAL_SALES analytic model, which sources from V_SALES_360 view.

Here's the view definition:

SELECT
    c.REGION,
    SUM(s.REVENUE) as TOTAL_REVENUE
FROM SALES.SALES_FACT s
LEFT JOIN MASTER_DATA.DIM_CUSTOMER c
    ON s.CUSTOMER_ID = c.CUSTOMER_ID
WHERE s.ORDER_DATE >= '2024-01-01'
GROUP BY c.REGION

Let me show you the current results..." [Uses execute_smart_query]

Agent: "Current Results:

Lisa, you mentioned Europe higher than North America is unexpected. What were you expecting?"

Lisa: "Based on our quarterly business review, North America should be around $55M and Europe around $35M. These numbers are flipped!"

Marcus: "Interesting! Let me check if there's a data quality issue..."

Agent (assisting Marcus): "Checking data quality..." [Uses analyze_column_distribution]

Agent: "REGION distribution in DIM_CUSTOMER:

Customer distribution looks reasonable. Let me check for NULL regions..." [Uses execute_smart_query]

Agent: "Found 134,892 sales records with NULL REGION (no customer match).

Total NULL revenue: $18.3M ⚠️

These are unassigned sales! Let me investigate..." [Uses get_table_metadata]

Agent: "The NULL regions are caused by:

1. New customers not yet added to DIM_CUSTOMER
2. B2B customers with no region assignment
3. Online sales with no customer profile

But this doesn't explain the flip. Let me check if there's a region mapping issue..."

Marcus: "Good catch! Can you show me the REGION values in both tables?"

Agent: "Comparing REGION values..." [Uses analyze_column_distribution]

Agent: "⚠️ FOUND THE ISSUE!

DIM_CUSTOMER.REGION values:

• 'North America'
• 'Europe'
• 'Asia Pacific'
• 'Latin America'

SALES_FACT.REGION values (direct field, not joined):

• 'NA' (North America)
• 'EU' (Europe)
• 'APAC' (Asia Pacific)
• 'LATAM' (Latin America)

PROBLEM: The view joins on CUSTOMER_ID to get REGION from DIM_CUSTOMER, but some sales have direct REGION codes ('NA', 'EU') that don't match!

Let me trace where this is happening..." [Uses get_view_definition, preview_data]

Agent: "Here's what's happening:

Scenario 1 - Matched Customers (85%):

SALES_FACT.CUSTOMER_ID = 'CUST123456'
DIM_CUSTOMER.CUSTOMER_ID = 'CUST123456'
DIM_CUSTOMER.REGION = 'North America'
→ Result: 'North America' ✅

Scenario 2 - Unmatched Customers (15%):

SALES_FACT.CUSTOMER_ID = 'CUST999888'
DIM_CUSTOMER.CUSTOMER_ID = NULL (not found)
DIM_CUSTOMER.REGION = NULL
→ Result: NULL ⚠️

But wait... Let me check if there's a REGION field directly in SALES_FACT..." [Uses get_table_metadata]

Agent: "ROOT CAUSE FOUND!

SALES_FACT has TWO region fields:

1. CUSTOMER_ID (FK to DIM_CUSTOMER) → joins to get 'Europe', 'North America'
2. SALES_REGION (direct field) → contains 'EU', 'NA', 'APAC', 'LATAM'

The report is using CUSTOMER_ID join, but the SALES_REGION field has more accurate/complete data.

Impact:

• Using DIM_CUSTOMER.REGION: 85% coverage, 15% NULL
• Using SALES_FACT.SALES_REGION: 98% coverage, 2% NULL

Let me re-run the query with SALES_REGION..." [Uses execute_smart_query]

Agent: "Results with SALES_REGION field:

These match Lisa's expectations!

The issue is that V_SALES_360 is using the wrong REGION source. It should use SALES_FACT.SALES_REGION instead of DIM_CUSTOMER.REGION."

Lisa: "That makes total sense! Our sales team enters the region directly during order creation. So how do we fix the report?"

Marcus: "We need to update V_SALES_360. Let me draft the fix..."

Agent (assisting Marcus): "Recommended fix:

CREATE OR REPLACE VIEW ANALYTICS.V_SALES_360 AS
SELECT
    s.SALES_ID,
    s.ORDER_DATE,
    c.CUSTOMER_ID,
    c.CUSTOMER_NAME,
    c.CUSTOMER_SEGMENT,

    -- Use SALES_REGION from SALES_FACT (more accurate)
    CASE s.SALES_REGION
        WHEN 'NA' THEN 'North America'
        WHEN 'EU' THEN 'Europe'
        WHEN 'APAC' THEN 'Asia Pacific'
        WHEN 'LATAM' THEN 'Latin America'
        ELSE s.SALES_REGION
    END AS REGION,

    -- Keep customer region for reference
    c.REGION AS CUSTOMER_REGION,

    ... rest of columns
FROM SALES.SALES_FACT s
LEFT JOIN MASTER_DATA.DIM_CUSTOMER c
    ON s.CUSTOMER_ID = c.CUSTOMER_ID
WHERE s.STATUS = 'COMPLETED'
  AND s.ORDER_DATE >= '2024-01-01';

Changes:

1. Use SALES_FACT.SALES_REGION as primary REGION
2. Map codes ('NA', 'EU') to full names ('North America', 'Europe')
3. Keep DIM_CUSTOMER.REGION as CUSTOMER_REGION for reference

Impact:

• NULL regions: 15% → 2% (13% improvement)
• Data accuracy: Fixed (matches business expectations)
• Report changes: Regional totals will shift to correct values

Lisa, does this approach make sense?"

Lisa: "Perfect! One more question: will this affect other reports that use V_SALES_360?"

Agent (assisting Marcus): "Checking downstream dependencies..." [Uses search_catalog]

Agent: "V_SALES_360 is used by:

Analytic Models (4):

• AM_REGIONAL_SALES (your report) ✅ Will fix
• AM_SALES_PERFORMANCE ✅ Will improve
• AM_CUSTOMER_ANALYSIS ⚠️ Needs review (uses REGION for customer segmentation)
• AM_TERRITORY_PLANNING ⚠️ Needs review (might need CUSTOMER_REGION instead)

SAC Stories (12):

• 8 regional reports ✅ Will show correct data
• 4 customer reports ⚠️ May need adjustment

Power BI Reports (5):

• 3 regional dashboards ✅ Will fix
• 2 customer segmentation reports ⚠️ May need CUSTOMER_REGION

Recommendation:

1. Update V_SALES_360 with both REGION (from SALES_FACT) and CUSTOMER_REGION (from DIM_CUSTOMER)
2. Test AM_CUSTOMER_ANALYSIS and AM_TERRITORY_PLANNING after update
3. Notify report owners of 6 reports that might need adjustment
4. Provide migration guide for switching to CUSTOMER_REGION if needed

Would you like me to generate the migration guide and notification email?"

Lisa: "Yes please! And can you estimate how long this will take to implement?"

Agent: "Implementation Plan:

Phase 1: Testing (30 minutes)

• Update V_SALES_360 in SANDBOX space
• Test with sample data
• Validate results match expected totals
• Marcus's task

Phase 2: Validation (20 minutes)

• Test AM_REGIONAL_SALES with updated view
• Compare old vs new results
• Document differences
• Marcus + Lisa collaboration

Phase 3: Communication (10 minutes)

• Send notification to 6 report owners
• Provide migration guide
• Schedule review meeting if needed
• Lisa's task

Phase 4: Deployment (10 minutes)

• Update V_SALES_360 in PRODUCTION
• Refresh analytic models
• Test reports
• Marcus's task

Phase 5: Monitoring (ongoing)

• Monitor for unexpected issues
• Address feedback from report owners
• Document lessons learned
• Both

Total Time: 70 minutes (vs 6+ hours of back-and-forth emails/meetings)

Traditional Approach (estimated):

• Initial meeting: 30 min
• Marcus investigation: 2 hours
• Follow-up meeting: 30 min
• Fix + testing: 1 hour
• Communication: 30 min
• Deployment: 30 min
• Follow-up issues: 1.5 hours Total: 6+ hours over 2-3 days

MCP Approach:

• Single conversation: 25 minutes (diagnosis + planning)
• Implementation: 70 minutes Total: 95 minutes, same day

Savings: 4+ hours, completed same day vs 2-3 days"

### Expected Results

**Collaboration Success:**
- Problem diagnosed: Wrong REGION source (DIM_CUSTOMER vs SALES_FACT)
- Root cause found: 15% NULL regions from unmatched customers
- Solution designed: Use SALES_FACT.SALES_REGION with code mapping
- Impact analyzed: 17 dependent objects reviewed
- Implementation planned: 70 minutes, phased rollout
- Communication prepared: Email and migration guide generated

**Total Time**: 95 minutes (vs 6+ hours over 2-3 days)

### ROI Analysis
- **Per collaboration**: 4+ hours saved
- **Time-to-resolution**: Same day vs 2-3 days (10x faster)
- **Monthly savings**: ~32 hours (8 collaborative issues)
- **Annual value**: ~384 hours ($57,000+ at $150/hr)
- **Quality improvement**: Fewer misunderstandings, faster iterations

---

## ROI Summary Across All Use Cases

| Use Case | Persona | Time Saved | Frequency | Monthly Value | Annual Value |
|----------|---------|------------|-----------|---------------|--------------|
| 1. Monday Health Check | Ops Manager | 37 min/day | Daily | 14h | $25,000 |
| 2. Data Lineage | Data Engineer | 2.5h/investigation | 4x/month | 10h | $18,000 |
| 3. Pre-Analytics Audit | Data Analyst | 1.75h/project | 8x/month | 14h | $25,000 |
| 4. Onboarding | New Engineer | 15h (one-time) | 4x/year | 5h | $9,000 |
| 5. Marketplace Discovery | Analytics Lead | 40 min/eval | 8x/month | 5h | $9,000 |
| 6. Security Audit | Governance Mgr | 3.5h/audit | 4x/year | 1h | $2,100 |
| 7. Performance Troubleshooting | Platform Engineer | 1h/incident | 8x/month | 8h | $14,000 |
| 8. Cross-Functional Collab | Analyst + Engineer | 4h/issue | 8x/month | 32h | $57,000 |
| **TOTAL** | | | | **~89h/month** | **$159,100/year** |

**Assumptions:**
- Blended hourly rate: $150/hr
- Mid-sized Datasphere deployment (8 spaces, 300+ objects)
- 5-person data team
- 100+ report consumers

**Payback Period**: Immediate (MCP server is free, open source)

---

## Best Practices for Using MCP Tools

### 1. Start with Discovery
Ask exploratory questions before diving into details:
- "What spaces do we have?"
- "Show me the structure of this table"
- "List all data flows in the SALES space"

### 2. Build Context Progressively
Use a series of questions to build understanding:
1. High-level overview → Specific object details
2. Structure → Sample data → Analysis
3. Current state → Historical trends → Predictions

### 3. Combine Multiple Tools
Chain tools together for comprehensive analysis:
- `search_catalog` → `get_table_metadata` → `preview_data`
- `list_data_flows` → `get_data_flow_details` → `execute_query`
- `find_assets_by_column` → `get_view_definition` → `analyze_column_distribution`

### 4. Validate Assumptions
Always verify data before making decisions:
- Preview data samples
- Check data quality (nulls, distributions)
- Validate row counts and totals
- Test queries before deploying

### 5. Document in Conversation
Use the MCP conversation as living documentation:
- Ask agent to explain logic
- Request SQL examples
- Generate implementation plans
- Create migration guides

### 6. Iterate Quickly
Refine analysis through conversation:
- Test hypothesis → Adjust filters → Re-run query
- Compare results → Identify differences → Drill down
- Find issue → Test fix → Validate solution

### 7. Share Conversations
Collaborate by sharing MCP conversations:
- Copy conversation transcript for documentation
- Share insights with team members
- Use as training material for new hires
- Reference for future similar issues

---

## Common Patterns

### Pattern 1: The Investigative Loop

1. Ask broad question
2. Get high-level overview
3. Drill into specifics
4. Preview sample data
5. Test hypothesis
6. Repeat until satisfied

**Example**: "What tables contain customer data?" → "Show me DIM_CUSTOMER structure" → "Preview sample data" → "Check for duplicates"

### Pattern 2: The Validation Chain

1. Get current state
2. Check data quality
3. Validate business logic
4. Test edge cases
5. Generate report

**Example**: Health Check, Security Audit, Pre-Analytics Audit

### Pattern 3: The Collaborative Debug

1. Share problem statement
2. Investigate together
3. Test hypotheses
4. Design solution collaboratively
5. Plan implementation

**Example**: Cross-Functional Collaboration

### Pattern 4: The Discovery Sprint

1. Define goal
2. Explore available tools/data
3. Identify matches
4. Evaluate options
5. Make decision

**Example**: Marketplace Shopping Spree, Onboarding Speedrun

---

## Conclusion

The SAP Datasphere MCP Server transforms data workflows by enabling **conversational data interaction**. These 8 use cases demonstrate:

1. **Massive Time Savings**: 37 minutes to 15 hours per task
2. **Faster Problem Resolution**: Minutes instead of hours
3. **Better Collaboration**: Single conversation vs multiple meetings
4. **Reduced Errors**: Validate before deploying
5. **Knowledge Transfer**: Conversations become documentation

**Total ROI**: $159,100+ per year for a mid-sized team

**Key Enabler**: Natural language interaction with live Datasphere data, combining the power of:
- Direct MCP tool access
- Claude's reasoning and analysis
- Real-time data validation
- Collaborative workflows

**Next Steps**:
1. Install SAP Datasphere MCP Server
2. Configure OAuth credentials
3. Try Use Case 1 (Monday Health Check)
4. Expand to other use cases
5. Share with team and measure ROI

---

**Document Version**: 1.0
**Last Updated**: 2025-12-28
**Source**: SAP Datasphere MCP Server Release Blog
**MCP Server**: @mariodefe/sap-datasphere-mcp
**GitHub**: https://github.com/MarioDeFelipe/sap-datasphere-mcp