> For the complete documentation index, see [llms.txt](https://academy.pentaho.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.pentaho.com/schema-workbench/schema-workbench-es/banco-de-trabajo-de-esquemas/extender-modelo.md).

# Extender modelo

{% hint style="info" %}

#### Extender el esquema

A medida que maduran las necesidades analíticas de su organización, los usuarios de negocio inevitablemente solicitarán mejoras en su modelo de datos. Esta evolución es natural y esperada: lo que comienza como un cubo de análisis de ventas simple crecerá para acomodar preguntas comerciales más sofisticadas. 
{% endhint %}

<figure><img src="/files/428bbd15cc9603c2a5227509c49d60a42f87e6a0" alt=""><figcaption><p>Modelos en miniatura - Ampliados</p></figcaption></figure>

{% hint style="info" %}
La evolución del esquema se refiere al perfeccionamiento incremental de las definiciones de cubo de Mondrian para soportar nuevos requisitos analíticos sin interrumpir informes y análisis existentes. El principio clave es **compatibilidad con versiones anteriores -** las nuevas funciones deben mejorar en lugar de romper la funcionalidad existente.
{% endhint %}

***

#### Tabla de referencia rápida

| Tipo de evolución                                         | Usar cuando                          | Impacto en el rendimiento             | Complejidad |
| --------------------------------------------------------- | ------------------------------------ | ------------------------------------- | ----------- |
| [Cambiar título/formato](#change-caption-format)          | Mejorar la usabilidad                | Ninguno                               | Baja        |
| [Agregar jerarquía](#add-hierarchy)                       | Necesidad de navegación alternativa  | Mínimo                                | Media       |
| [Agregar nivel](#add-level)                               | Necesidad de más detalle/aggregación | Baja                                  | Bajo-Medio  |
| [Agregar medida (mismo grano)](#add-measure)              | Necesidad de métricas relacionadas   | Baja                                  | Baja        |
| [Agregar medida (grano distinto)](#add-different-measure) | Necesidad de métricas dimensionales  | Media                                 | Media       |
| [Columna calculada](#calculated-column)                   | Lógica compleja, uso frecuente       | Bajo (calculada una vez)              | Media       |
| [Miembro calculado](#add-cm-to-cube)                      | Ratios, comparaciones, fórmulas      | Medio (cálculo en tiempo de consulta) | Medio-Alto  |
| [Conjunto nombrado](#add-named-set)                       | Grupos reutilizables de miembros     | Mínimo                                | Bajo-Medio  |
| [Múltiples cubos](#multiple-cubes)                        | Casos de uso/seguridad separados     | Positivo (especialización)            | Media       |

{% tabs %}
{% tab title="Cambiar título / formato" %}
{% hint style="info" %}

#### Cambiar el título, la descripción o la cadena de formato de cualquier elemento

**Qué hace:** Modifica cómo aparecen los elementos a los usuarios sin cambiar la estructura de datos subyacente ni la lógica de consultas.

**Por qué importa:** La terminología empresarial evoluciona y su esquema debe reflejar el lenguaje actual. Además, un formato adecuado asegura que los datos se presenten de manera profesional y consistente.
{% endhint %}

**Ejemplo - Estado actual:**

```xml
<Measure name="Sales" 
         aggregator="sum" 
         column="TOTALPRICE"
         formatString="$#,###.00"
         datatype="Numeric"/>
```

**Escenarios de evolución:**

**Escenario A - Actualizar el título para mayor claridad:**

```xml
<Measure name="Sales" 
         caption="Ingresos totales por ventas"
         aggregator="sum" 
         column="TOTALPRICE"
         formatString="$#,###.00"
         datatype="Numeric"/>
```

*Impacto en el negocio:* Los usuarios ahora ven "Ingresos totales por ventas" en Analyzer, lo que aclara que esto representa ingresos brutos, no beneficios.

***

**Escenario B - Cambiar la cadena de formato para moneda internacional:**

```xml
<Measure name="Sales" 
         caption="Ingresos totales por ventas"
         aggregator="sum" 
         column="TOTALPRICE"
         formatString="€#,##0.00;(€#,##0.00)"
         datatype="Numeric"/>
```

*Impacto en el negocio:* Los ingresos ahora se muestran en euros con el formato correcto para números negativos entre paréntesis.

***

**Escenario C - Agregar descripción para documentación:**

```xml
<Measure name="Sales" 
         caption="Ingresos totales por ventas"
         description="Suma de todos los totales de líneas de pedido antes de impuestos y envío. Incluye descuentos aplicados a nivel de pedido."
         aggregator="sum" 
         column="TOTALPRICE"
         formatString="$#,###.00"
         datatype="Numeric"/>
```

*Impacto en el negocio:* Los usuarios que pasan el cursor sobre la medida en Analyzer ven una sugerencia que explica exactamente qué representa esta medida.
{% endtab %}

{% tab title="Agregar jerarquía" %}
{% hint style="info" %}

#### Agregar una jerarquía a una dimensión

**Qué hace:** Proporciona rutas de navegación alternativas a través de la misma dimensión, soportando diferentes perspectivas analíticas.

**Por qué importa:** Diferentes usuarios de negocio necesitan analizar la misma dimensión de formas distintas. Varias jerarquías permiten flexibilidad sin crear dimensiones separadas.

**Ejemplo - Estado actual:** La dimensión Productos tiene una jerarquía: Línea → Proveedor → Nombre del producto
{% endhint %}

**Evolución:** Agregar una segunda jerarquía basada en categorías de producto:

```xml
<Dimension name="PRODUCTS" foreignKey="PRODUCTCODE">
    
    <!-- Jerarquía original -->
    <Hierarchy name="Por proveedor" 
               hasAll="true" 
               allMemberName="Todos los productos"
               primaryKey="PRODUCTCODE">
        <Table name="PRODUCTS" schema="PUBLIC"/>
        <Level name="Línea" column="PRODUCTLINE" type="String"/>
        <Level name="Proveedor" column="PRODUCTVENDOR" type="String"/>
        <Level name="Nombre del producto" column="PRODUCTNAME" type="String"/>
    </Hierarchy>
    
    <!-- Nueva jerarquía -->
    <Hierarchy name="Por categoría" 
               hasAll="true" 
               allMemberName="Todos los productos"
               primaryKey="PRODUCTCODE">
        <Table name="PRODUCTS" schema="PUBLIC"/>
        <Level name="Categoría" column="PRODUCTCATEGORY" type="String"/>
        <Level name="Subcategoría" column="PRODUCTSUBCATEGORY" type="String"/>
        <Level name="Nombre del producto" column="PRODUCTNAME" type="String"/>
    </Hierarchy>
    
</Dimension>
```

{% hint style="info" %}
**Caso de uso empresarial:**

* El departamento de marketing analiza por Categoría → Subcategoría (clasificación orientada al mercado)
* El departamento de operaciones analiza por Línea → Proveedor (clasificación de la cadena de suministro)
* Ambos equipos usan el mismo cubo con diferentes rutas de navegación
* Los usuarios seleccionan su jerarquía preferida en Analyzer sin necesidad de fuentes de datos separadas
  {% endhint %}
  {% endtab %}

{% tab title="Agregar nivel" %}
{% hint style="info" %}

#### Agregar un nivel a una jerarquía

**Qué hace:** Aumenta la granularidad o añade puntos intermedios de agregación en una jerarquía existente.

**Por qué importa:** A medida que maduran los requisitos de informes, los usuarios necesitan capacidades de desglose más detalladas o niveles intermedios de resumen.

**Ejemplo - Estado actual:** La dimensión Clientes tiene: Nombre del cliente (nivel único)
{% endhint %}

**Escenario de evolución A - Agregar niveles geográficos:**

```xml
<Hierarchy name="Customers" 
           hasAll="true" 
           allMemberName="Todos los clientes"
           primaryKey="CUSTOMERNUMBER">
    <Table name="CUSTOMERS" schema="PUBLIC"/>
    
    <!-- Nuevos niveles -->
    <Level name="País" 
           column="COUNTRY" 
           type="String" 
           uniqueMembers="true"/>
    
    <Level name="Estado/Provincia" 
           column="STATE" 
           type="String" 
           uniqueMembers="false"/>
    
    <Level name="Ciudad" 
           column="CITY" 
           type="String" 
           uniqueMembers="false"/>
    
    <Level name="Nombre del cliente" 
           column="CUSTOMERNAME" 
           type="String" 
           uniqueMembers="false"/>
</Hierarchy>
```

**Caso de uso empresarial:**

* **Antes:** Los usuarios solo podían ver ventas por cliente individual (demasiado detallado para ejecutivos)
* **Después:** Los ejecutivos pueden ver ventas por País, los gerentes regionales por Estado/Provincia y los representantes de ventas por Ciudad, con la capacidad de profundizar hasta clientes específicos
* Soporta análisis de mercado geográfico sin crear dimensiones separadas

***

**Escenario de evolución B - Agregar segmentación de clientes:**

```xml
<Level name="Segmento de cliente" 
       column="CUSTOMERSEGMENT" 
       type="String" 
       uniqueMembers="true"
       levelType="Regular">
    <!-- Agregar antes del nivel Nombre del cliente -->
</Level>
```

**Caso de uso empresarial:**

* Segmenta a los clientes como "Empresa", "Mediana empresa", "Pequeña empresa"
* Permite el análisis: "¿Cuál es nuestro tamaño de acuerdo promedio por segmento de cliente?"
* La dirección de ventas puede comparar el rendimiento entre diferentes segmentos de mercado
  {% endtab %}

{% tab title="Agregar medida" %}
{% hint style="info" %}

#### Agregar una medida que tenga la misma granularidad o dimensionalidad que las medidas existentes

**Qué hace:** Añade nuevas métricas que pueden analizarse al mismo nivel dimensional que las medidas existentes.

**Por qué importa:** Las necesidades del negocio se expanden para incluir nuevos KPI sin requerir cambios en la estructura dimensional.

**Ejemplo - Estado actual:** Medida única: Ventas (suma de TOTALPRICE)
{% endhint %}

**Evolución - Agregar métricas de ventas complementarias:**

```xml
<!-- Medida existente -->
<Measure name="Sales" 
         aggregator="sum" 
         column="TOTALPRICE"
         formatString="$#,###.00"/>

<!-- Nuevas medidas con la misma granularidad -->
<Measure name="Quantity Sold" 
         caption="Unidades vendidas"
         aggregator="sum" 
         column="QUANTITYORDERED"
         formatString="#,###"
         datatype="Integer"/>

<Measure name="Order Count" 
         caption="Número de pedidos"
         aggregator="count" 
         column="ORDERNUMBER"
         formatString="#,###"
         datatype="Integer"/>

<Measure name="Discount Amount" 
         caption="Total descuentos"
         aggregator="sum" 
         column="DISCOUNT"
         formatString="$#,###.00"
         datatype="Numeric"/>

<Measure name="Cost of Goods Sold" 
         caption="COGS"
         aggregator="sum" 
         column="BUYPRICE"
         formatString="$#,###.00"
         datatype="Numeric"/>
```

**Caso de uso empresarial:** Todas estas medidas comparten la misma dimensionalidad: todas pueden analizarse por:

* Línea de producto
* Territorio
* Cliente
* Periodo de tiempo

**Ejemplo de análisis:** "Muéstrame Ventas, Unidades Vendidas y Precio Medio por Unidad por Línea de Producto y Territorio"

* Ventas por Territorio y Línea: $X
* Unidades vendidas por Territorio y Línea: Y
* Precio medio por unidad: $X / Y
* Las tres métricas se alinean perfectamente en los mismos ejes dimensionales
  {% endtab %}

{% tab title="Agregar medida diferente" %}
{% hint style="info" %}

#### Agregar una medida de granularidad o dimensionalidad diferente a las medidas existentes

**Qué hace:** Introduce métricas que existen en niveles dimensionales distintos a su tabla de hechos, requiriendo un manejo especial para la agregación.

**Por qué importa:** Algunas métricas de negocio no existen a nivel transaccional. Niveles de inventario, recuentos de empleados y límites de crédito de clientes son atributos dimensionales, no hechos de transacción.

**Ejemplo - Estado actual:** Todas las medidas están en el grano ORDER\_DETAILS (una fila por producto por pedido)
{% endhint %}

**Evolución - Agregar medidas en diferentes granularidades:**

**Escenario A - Medida a nivel de cliente:**

```xml
<Measure name="Customer Credit Limit" 
         caption="Límite de crédito"
         aggregator="max" 
         column="CREDITLIMIT"
         formatString="$#,###.00"
         datatype="Numeric"/>
```

**¿Por qué el agregador "max"?**

* El límite de crédito se almacena una vez por cliente en la tabla de dimensión CUSTOMERS
* Al agregar sobre varios clientes, queremos el límite de crédito máximo en ese grupo
* Esto evita el doble conteo cuando un cliente tiene múltiples pedidos

**Caso de uso empresarial:** "Muéstrame ventas totales frente a crédito disponible por segmento de cliente"

* Las ventas se agregan de forma natural (suma de todos los pedidos)
* Los límites de crédito usan "max" para mostrar el límite más alto en cada segmento sin doble conteo

***

**Escenario B - Medida a nivel de producto:**

```xml
<Measure name="Product Unit Cost" 
         caption="Costo estándar del producto"
         aggregator="avg" 
         column="BUYPRICE"
         formatString="$#,###.00"
         datatype="Numeric"/>
```

**Caso de uso empresarial:** "¿Cuál es el costo promedio del producto por proveedor?"

* Cada producto tiene un costo estándar
* El agregador "avg" proporciona el costo promedio entre productos para cada proveedor
* Diferente del COGS total, que suma los costos reales de las transacciones
  {% endtab %}

{% tab title="Columna calculada" %}
{% hint style="info" %}

#### Crear una columna calculada y usarla en un atributo o medida

**Qué hace:** Define columnas derivadas a nivel de base de datos o ETL, luego las expone en su esquema como dimensiones o medidas.

**Por qué importa:** No toda la lógica de negocio debería estar en cálculos MDX. Algunas transformaciones es mejor realizarlas una vez durante el ETL en lugar de repetidamente en tiempo de consulta.
{% endhint %}

**Columna calculada en la base de datos (creada en su ETL o vista de base de datos):**

```sql
CREATE VIEW ORDER_DETAILS_ENHANCED AS
SELECT 
    *,
    TOTALPRICE - (QUANTITYORDERED * BUYPRICE) AS PROFIT,
    CASE 
        WHEN TOTALPRICE - (QUANTITYORDERED * BUYPRICE) < 0 THEN 'Pérdida'
        WHEN TOTALPRICE - (QUANTITYORDERED * BUYPRICE) < 100 THEN 'Margen bajo'
        WHEN TOTALPRICE - (QUANTITYORDERED * BUYPRICE) < 500 THEN 'Margen medio'
        ELSE 'Margen alto'
    END AS PROFITABILITY_TIER
FROM ORDER_DETAILS;
```

**Usar la columna calculada en una medida:**

```xml
<Measure name="Profit" 
         caption="Beneficio bruto"
         aggregator="sum" 
         column="PROFIT"
         formatString="$#,###.00"
         datatype="Numeric"/>
```

**Usar la columna calculada en una dimensión:**

```xml
<Dimension name="PROFITABILITY" foreignKey="ORDERDETAILID">
    <Hierarchy name="Rentabilidad" 
               hasAll="true" 
               allMemberName="Todas las transacciones"
               primaryKey="ORDERDETAILID">
        <Table name="ORDER_DETAILS_ENHANCED" schema="PUBLIC"/>
        <Level name="Nivel de rentabilidad" 
               column="PROFITABILITY_TIER" 
               type="String"/>
    </Hierarchy>
</Dimension>
```

**Caso de uso empresarial:** "Muéstrame ventas y margen de beneficio por nivel de rentabilidad y línea de producto"

* El cálculo del beneficio ocurre una vez en la base de datos
* Mucho más rápido que calcular (Ventas - Coste) en MDX para cada consulta
* El nivel de rentabilidad permite a los usuarios filtrar y agrupar por rendimiento de beneficios
* Reduce la complejidad de las consultas y mejora el rendimiento

**Beneficio en el rendimiento:**

* Antes: MDX calcula el beneficio para cada celda en cada consulta
* Después: la base de datos calcula una vez; Mondrian solo agrega los valores pre-calculados
  {% endtab %}

{% tab title="Agregar MC al cubo" %}
{% hint style="info" %}

#### Agregar un miembro calculado a un cubo

**Qué hace:** Define fórmulas que combinan medidas existentes para crear nuevas métricas, calculadas en tiempo de consulta.

**Por qué importa:** Muchas métricas comerciales son ratios, porcentajes o fórmulas complejas que no se pueden simplemente sumar o promediar. Los miembros calculados gestionan esta lógica de negocio en MDX.
{% endhint %}

```xml
<CalculatedMember name="Profit Margin %" 
                  dimension="Measures"
                  formula="([Measures].[Profit] / [Measures].[Sales]) * 100"
                  formatString="#,##0.00'%'">
    <CalculatedMemberProperty name="FORMAT_STRING" value="#,##0.00'%'"/>
</CalculatedMember>

<CalculatedMember name="Average Order Value" 
                  dimension="Measures"
                  formula="[Measures].[Sales] / [Measures].[Order Count]"
                  formatString="$#,###.00">
</CalculatedMember>

<CalculatedMember name="Units Per Order" 
                  dimension="Measures"
                  formula="[Measures].[Quantity Sold] / [Measures].[Order Count]"
                  formatString="#,##0.0">
</CalculatedMember>

<CalculatedMember name="Sales Growth vs Prior Year" 
                  dimension="Measures">
    <Formula>
        <![CDATA[
        ([Measures].[Sales] - ([Measures].[Sales], ParallelPeriod([Time].[Year], 1))) /
        ([Measures].[Sales], ParallelPeriod([Time].[Year], 1)) * 100
        ]]>
    </Formula>
    <CalculatedMemberProperty name="FORMAT_STRING" value="#,##0.0'%'"/>
</CalculatedMember>
```

**Casos de uso empresarial:**

**Margen de beneficio %**

* "¿Qué líneas de producto tienen los márgenes de beneficio más altos?"
* "¿Cómo varía el margen de beneficio por segmento de cliente?"
* No se puede calcular como un promedio: debe ser (Beneficio total / Ventas totales) en cada nivel de agregación

**Valor medio del pedido**

* "¿Cuál es el valor medio del pedido por territorio?"
* "¿Está aumentando nuestro tamaño medio de pedido con el tiempo?"
* Diferente de sumar los valores de los pedidos: requiere dividir las ventas totales por el número de pedidos

**Crecimiento de ventas respecto al año anterior**

* "¿Qué territorios están creciendo más rápido año tras año?"
* "¿Cuál es nuestra tasa de crecimiento compuesta?"
* Utiliza la inteligencia temporal MDX para comparar el periodo actual con el mismo periodo del año anterior

**Diferencia clave respecto a las medidas regulares:**

* Las medidas regulares se agregan mediante SUM, COUNT, AVG, etc.
* Los miembros calculados usan fórmulas que operan sobre valores agregados
* Ejemplo: el margen de beneficio debe calcularse DESPUÉS de agregar beneficio y ventas, no antes
  {% endtab %}

{% tab title="Agregar conjunto nombrado" %}
{% hint style="info" %}

#### Agregar un conjunto nombrado a un cubo

**Qué hace:** Define colecciones predefinidas y reutilizables de miembros de dimensión que los usuarios pueden aplicar de forma consistente en los análisis.

**Por qué importa:** Los usuarios de negocio analizan repetidamente los mismos grupos significativos. Los conjuntos nombrados proporcionan consistencia, mejoran la usabilidad y encapsulan lógica MDX compleja.
{% endhint %}

**Ejemplo:**

```xml
<!-- Top 10 Products by Sales -->
<NamedSet name="Top 10 Products">
    <Formula>
        <![CDATA[
        TopCount([PRODUCTS].[By Vendor].[Product Name].Members, 10, [Measures].[Sales])
        ]]>
    </Formula>
</NamedSet>

<!-- Territorios clave (mercados de altos ingresos) -->
<NamedSet name="Strategic Territories">
    <Formula>
        <![CDATA[
        {
            [TERRITORY].[Geographic].[Territory].[EMEA North],
            [TERRITORY].[Geographic].[Territory].[NA East],
            [TERRITORY].[Geographic].[Territory].[NA West],
            [TERRITORY].[Geographic].[Territory].[APAC Central]
        }
        ]]>
    </Formula>
</NamedSet>

<!-- Año actual y anterior para tendencias -->
<NamedSet name="Current and Prior Year">
    <Formula>
        <![CDATA[
        {
            [Time].[Calendar].[Year].CurrentMember,
            [Time].[Calendar].[Year].CurrentMember.Lag(1)
        }
        ]]>
    </Formula>
</NamedSet>

<!-- Clientes de alto valor (>$100K gasto anual) -->
<NamedSet name="High Value Customers" dynamic="true">
    <Formula>
        <![CDATA[
        Filter(
            [CUSTOMERS].[Geographic].[Customer Name].Members,
            [Measures].[Sales] > 100000
        )
        ]]>
    </Formula>
</NamedSet>
```

**Casos de uso empresarial:**

**Top 10 Products**

* Los usuarios pueden analizar de forma consistente los mismos productos de mejor rendimiento
* La definición está centralizada: si el negocio decide que "Top 10" significa Top 15, cámbielo una vez
* Aparece como una opción de filtro preconfigurada en Analyzer

**Territorios estratégicos**

* La dirección de ventas quiere centrar los informes en mercados clave
* En lugar de seleccionar manualmente los territorios cada vez, use el conjunto nombrado
* Garantiza consistencia entre informes y paneles

**Año actual y anterior**

* Cada informe de tendencias necesita esta comparación
* El conjunto nombrado encapsula la lógica MDX para acceder a periodos actuales y anteriores
* Los usuarios no necesitan entender MDX para crear comparaciones año tras año

**Clientes de alto valor (dinámico)**

* El filtro se actualiza automáticamente en función de los datos actuales
* "dynamic=true" significa que el conjunto se recalcula en cada consulta
* Diferentes clientes pueden calificar cada trimestre a medida que cambian los patrones de gasto

**Conjuntos nombrados vs miembros calculados:**

* Los miembros calculados crean nuevas medidas
* Los conjuntos nombrados crean grupos predefinidos de miembros de dimensión
* Ambos mejoran la usabilidad al encapsular la complejidad
  {% endtab %}

{% tab title=" Múltiples cubos" %}
{% hint style="info" %}

#### Múltiples cubos en un esquema

A medida que madura su entorno analítico, descubrirá que diferentes grupos de negocio necesitan perspectivas distintas de sus datos:

* **Cubo de análisis de ventas:** Optmizado para informes diarios de ventas (grano a nivel de pedido)
* **Cubo de analítica de clientes:** Enfocado en el comportamiento del cliente (grano a nivel de cliente con métricas de vida útil)
* **Cubo de gestión de inventarios:** Niveles y movimientos de stock (grano producto/almacén/día)
* **Cubo de informes financieros:** Métricas financieras mensuales (grano a nivel de mes con cuentas del libro mayor)
  {% endhint %}

{% hint style="info" %}

#### **Beneficios clave:**

1. **Optimización del rendimiento**
   * Cada cubo optimizado para patrones de consulta específicos
   * Agregaciones apropiadas para cada caso de uso
   * Cubos más pequeños y enfocados consultan más rápido que un cubo masivo
2. **Seguridad y gobernanza**
   * Conceder al equipo de ventas acceso solo al cubo de análisis de ventas
   * El equipo de finanzas accede al cubo de informes financieros
   * Prevenir la contaminación cruzada de datos sensibles
3. **Diferente granularidad**
   * Cubos de transacciones: detalle de línea de pedido
   * Cubos resumen: instantáneas diarias o mensuales
   * Cubos especializados: rentabilidad por producto, valor de vida del cliente
4. **Experiencia de usuario simplificada**
   * Los usuarios ven solo dimensiones y medidas relevantes
   * Menos abrumador que un cubo con 50 dimensiones
   * Adaptado a flujos de trabajo analíticos específicos
     {% endhint %}

**Ejemplo - Múltiples cubos en el esquema MiniatureModels:**

```xml
<Schema name="MiniatureModels">
    
    <!-- Cubo de transacciones de ventas original -->
    <Cube name="Sales" visible="true">
        <Table name="ORDER_DETAILS" schema="PUBLIC"/>
        <!-- Dimensiones: Territorio, Productos, Clientes, Tiempo -->
        <!-- Medidas: Ventas, Cantidad, Número de pedidos -->
    </Cube>
    
    <!-- Nuevo cubo de analítica de clientes -->
    <Cube name="Customer Analytics" visible="true">
        <Table name="CUSTOMER_SUMMARY" schema="PUBLIC"/>
        <Dimension name="CUSTOMERS" foreignKey="CUSTOMERNUMBER">
            <!-- Jerarquía de clientes con segmentos -->
        </Dimension>
        <Measure name="Lifetime Value" aggregator="sum" column="TOTAL_LTV"/>
        <Measure name="Customer Tenure Days" aggregator="avg" column="TENURE_DAYS"/>
        <Measure name="Number of Customers" aggregator="count" column="CUSTOMERNUMBER"/>
    </Cube>
    
    <!-- Nuevo cubo de rendimiento de producto -->
    <Cube name="Product Performance" visible="true">
        <Table name="PRODUCT_METRICS" schema="PUBLIC"/>
        <Dimension name="PRODUCTS" foreignKey="PRODUCTCODE">
            <!-- Jerarquía de producto -->
        </Dimension>
        <Measure name="Inventory Turns" aggregator="avg" column="INVENTORY_TURNOVER"/>
        <Measure name="Days in Stock" aggregator="avg" column="DAYS_INVENTORY"/>
        <Measure name="Sell-Through Rate" aggregator="avg" column="SELLTHROUGH_PCT"/>
    </Cube>
    
</Schema>
```

**Asignación de usuarios:**

* Representantes de ventas → Cubo de ventas
* Equipo de éxito del cliente → Cubo de analítica de clientes
* Gerentes de producto → Cubo de rendimiento de producto
* Ejecutivos → Todos los cubos (para paneles comprensivos)
  {% endtab %}
  {% endtabs %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://academy.pentaho.com/schema-workbench/schema-workbench-es/banco-de-trabajo-de-esquemas/extender-modelo.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.