Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

Avda.Valhondo, s/n
Edificio III Milenio
Módulo 2, 3ª Planta
06800 – Mérida

ORACLE ANALYTIC SERVER (OAS)

BUENAS PRÁCTICAS PARA EL DESARROLLO

DATOS IDENTIFICATIVOS DEL DOCUMENTO

Servicio Desarrollo de Servicios Digitales Sectoriales Clasificación Público
(Público,
Restringido,
Confidencial)

Autor Servicio de Desarrollo de Servicios Digitales Sectoriales

Nombre fichero OAS – Buenas prácticas Fecha creación 10/03/2021

Control de Cambios
Versión Fecha Autor Motivo
1.0 10/03/2021 Servicio de Desarrollos Sectoriales Versión inicial

Pag. 1 de 15
Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

Avda.Valhondo, s/n
Edificio III Milenio
Módulo 2, 3ª Planta
06800 – Mérida

ORACLE ANALYTIC SERVER (OAS)

BUENAS PRÁCTICAS PARA EL DESARROLLO

INDICE

INTRODUCCIÓN ............................................................................................................................... 3
CONSTRUCCIÓN DEL REPOSITORIO DE DATOS ....................................................................... 3
DISEÑO DEL REPOSITORIO DE DATOS ....................................................................................... 3
Capa Fisíca ....................................................................................................................................... 3
Capa Lógica ..................................................................................................................................... 5
Capa de Presentación ....................................................................................................................... 9
DISEÑO DE PANEL DE CONTROL E INFORMES ...................................................................... 13

Pag. 2 de 15
Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

Avda.Valhondo, s/n
Edificio III Milenio
Módulo 2, 3ª Planta
06800 – Mérida

ORACLE ANALYTIC SERVER (OAS)

BUENAS PRÁCTICAS PARA EL DESARROLLO

INTRODUCCIÓN

El objetivo de este documento es ofrecer una guía para el desarrollo en el entorno de Oracle Analytics
Server. Se trata por tanto de un conjunto de buenas prácticas para facilitar la gestión y el desarrollo
ordenado, ellas no constituyen todas las posibles buenas prácticas, y son adaptables a otras buenas
prácticas que los equipos de desarrollo ya tengan implantadas.

Algunas de estas buenas prácticas afectan al orden y la gestión del desarrollo y otras pueden tener un
efecto directo en el rendimiento de los análisis, paneles de control e informes que se desarrollen. Estas
buenas prácticas se van a dividir en dos partes, en una primera parte veremos las buenas prácticas
para el diseño del repositorio, y en una segunda parte veremos buenas prácticas para el diseño de
paneles de control e informes

CONSTRUCCIÓN DEL REPOSITORIO DE DATOS

La construcción del archivo RPD (Repository Metadata), que contiene el modelo de datos a explotar
en OAS, se lleva a cabo con la herramienta “OBI Client Administration”. La versión a utilizar de este
cliente debe ser compatible con la versión OAS, en nuestro caso disponemos de OAS 5.5.0. El cliente
compatible con esta versión puede descargarse de:

https://download.oracle.com/otn/java/cloud-service/OAS-5.5.0-bi_client-win64.zip

Para descargarlo es necesario disponer de una cuenta Oracle. La creación de esta cuenta es gratuita
y se realiza accediendo a la url: www.oracle.com, opción “ver cuentas.

Una vez construido el RPD, se le facilitará al administrador OAS, que se encargará de la carga del
fichero a RPD a OAS, creación del catálogo del proyecto y aplicar la seguridad de accesos a usuarios
del dominio gobex, según perfiles.

DISEÑO DEL REPOSITORIO DE DATOS

Capa Fisíca

• Nombres de Pools significativos. Definir una convención de Nombres para las Areas Temáti-
cas y los pooles de Conexiones que sean significativos. Por ejemplo:

Pag. 3 de 15
Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

Avda.Valhondo, s/n
Edificio III Milenio
Módulo 2, 3ª Planta
06800 – Mérida

ORACLE ANALYTIC SERVER (OAS)

BUENAS PRÁCTICAS PARA EL DESARROLLO

• Pools diferenciados. Utilice pool de conexiones separados para bloques de inicialización. Al

separar los pools de conexiones se permite mejorar el rendimiento de los informes.

• Minimice el número de bloques de inicialización. Es una buena práctica usar una única query
para publicar varias variables en vez de varias queries simples.

• Use Alias significativos. Cree alias para todas las tablas añadiendo prefijos que reflejen que
tipo de tabla son
Dim_,Fact o Fact_Agg-

• Trabaje con alias. Todos los Joins y operaciones se deben crear a partir de las tablas alias y
no desde las originales.

• Evite circular Joins. Los circular Joins tienen un gran impacto en el rendimiento ya que Oracle
Analytics Server no siempre podrá seleccionar correctamente las tablas que son necesarias
para realizar las consultas SQL. Las circular Joins siempre puede evitarse creando alias.

• Keys numéricas. Defina las primary keys y las foreign keys con valores numéricos, esto me-
jorar el rendimiento de los informes.

• Diseño en Estrella. Desnormalice los datos para mantener solo una tabla por dimensión con
el fin de acercarse lo más posible a un esquema en estrella. Las consultas físicas no deben leer
más de 7 tablas.

• Evite las relaciones snowflakes. Si hay una gran cantidad de consultas que probablemente se
realizarán en función de las medidas de dimensión dentro de la fuente de hechos, entonces
Pag. 4 de 15
Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

Avda.Valhondo, s/n
Edificio III Milenio
Módulo 2, 3ª Planta
06800 – Mérida

ORACLE ANALYTIC SERVER (OAS)

BUENAS PRÁCTICAS PARA EL DESARROLLO

siempre requerirá que se realice una combinación a través de la dimensión del sitio, lo que
generará un peor rendimiento.
Los snowflakes eliminan los atributos textuales de baja cardinalidad de las tablas de
dimensiones y los colocan en tablas de dimensiones "secundarias". Las siguientes son algunas
preguntas de diseño que deben revisarse antes de desarrollar relaciones de copos de nieve:

o Cuantificar la relación entre la tabla de dimensiones y la dimensión del snowflake

o Cuantificar la relación entre la tabla de dimensiones y la dimensión del snowflake. Si
el snowflake es un conjunto finito de 10 o 12 valores con redundancia incorporada y
sin atributos dependientes adicionales, considere usar el esquema de estrella con la
dimensión del snowflake aplanada o desnormalizada.

o Si la dimensión del snowflake es dinámica y está orientada al alto crecimiento durante

el período de tiempo, considere el esquema del snowflake.

o También revise la granularidad de las medidas en el hecho y verifique si hay hechos

adicionales o requisitos agregados basados en el snowflake.

o Considere la posibilidad de contraer la tabla de dimensiones del snowflake en la tabla

de hechos central. El uso de este método permitirá utilizar la relación entre el hecho y
la tabla de dimensiones del tipo de sitio, eliminando así la necesidad de realizar con-
sultas a través de la dimensión del sitio cada vez que se requiera el snowflake. Si la
mayoría de las consultas siempre requieren que se incluya la tabla de unión en la con-
sulta, se puede mantener el diseño actual (también teniendo en cuenta los puntos ante-
riores).

o Además, asegúrese de que los niveles de contenido estén configurados correctamente

para cada Logical Table Source.

Capa Lógica

• No Datos de Hechos en Tablas dimension. Revise que las tablas de dimensión no tienen datos
de hechos.

• Use tablas de dimensión lógicas para cada dimensión. No combine o las mezcle en una sola
tabla.

• Use tablas de Hechos lógicas para cada hecho. No queremos una tabla de hechos lógica lla-
mada “Cosas de hechos”
Pag. 5 de 15
Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

Avda.Valhondo, s/n
Edificio III Milenio
Módulo 2, 3ª Planta
06800 – Mérida

ORACLE ANALYTIC SERVER (OAS)

BUENAS PRÁCTICAS PARA EL DESARROLLO

• Tenga tablas lógicas separadas para componentes de hechos. Son los que combinan métri-
cas de varios hechos.

• Añada prefijos significativos a las tablas como

o Dim
o Fact
o FactCompound

• Columnas de tablas lógicas:

o Intente asignar las columnas con significado de negocio como claves primarias de Di-
mensión.

o Renombre las columnas a nombre más claros.

o Mantenga solo las columnas necesarias.

o No se deberían asignar claves primarias lógicas en tablas de hechos lógicos.

o Cree “falsas medidas” como separadores entre grupos de hechos para agruparlos co-
rrectamente

o Asegurese que cada columna* lógica de hechos tiene una regla de agregación confi-
gurada.

Pag. 6 de 15
Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

Avda.Valhondo, s/n
Edificio III Milenio
Módulo 2, 3ª Planta
06800 – Mérida

ORACLE ANALYTIC SERVER (OAS)

BUENAS PRÁCTICAS PARA EL DESARROLLO

• Siempre cree una jerarquía de dimensión para todas las dimensiones. Incluso si solo hay
un solo nivel de dimensión.
o El servidor puede necesitarla para seleccionar la fuente de tabla lógica más optimizada.
o Puede ser útil cuando se realiza un join entre dos resultados, cuando 2 tablas de hechos
han sido utilizadas en un informe.
o Es necesario para las medidas basadas en niveles.
o Es necesario establecer el nivel de contenido de las fuentes de tablas lógicas.

• Configure siempre el drill-down. Incluso si solo hay una dimensión. Puede resultar útil, por
ejemplo, profundizar desde el tipo de contacto hasta el nombre de un contacto. Intente espe-
cificar el número de elementos por nivel. El servidor lo utilizará para identificar tablas agre-
gadas y minidimensiones. No es necesario que sea preciso, una estimación aproximada está
bien.

Pag. 7 de 15
Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

Avda.Valhondo, s/n
Edificio III Milenio
Módulo 2, 3ª Planta
06800 – Mérida

ORACLE ANALYTIC SERVER (OAS)

BUENAS PRÁCTICAS PARA EL DESARROLLO

• Claves de nivel. La clave primaria de cada nivel debe ser única y la clave primaria del nivel
mas bajo debe ser siempre la clave primaria de la tabla lógica.

• Nivel de Contenidos. Especifique siempre el nivel de contenidos en todas las fuentes de tablas
lógicas, tanto en las de hechos como en las lógicas.
o Esto permite al servidor seleccionar las fuentes de tablas lógicas más optimizadas en
las queries.

o Esto ayuda a la herramienta que revisa la consistencia del repositorio a encontras in-
cidencias en la configuración previniendo errores en tiempo de ejecución.

Pag. 8 de 15
Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

Avda.Valhondo, s/n
Edificio III Milenio
Módulo 2, 3ª Planta
06800 – Mérida

ORACLE ANALYTIC SERVER (OAS)

BUENAS PRÁCTICAS PARA EL DESARROLLO

Capa de Presentación

• Hechos Implícitos. Configure una columna de hechos implícitos para cada carpeta de presen-
tación. Evita que los usuarios obtengan resultados inesperados si crean un informe sin ninguna
métrica.

• Dimensión Genérica de Tiempo. Cada modelo de negocio debe incluir una dimensión de
tiempo principal conectada a casi todas las tablas de hechos. Esto es necesario para informes
que incluyen varios hechos. También es mucho más fácil para los usuarios finales que tener
una dimensión de tiempo por tabla de hechos.

• Secuencias de Dimensión de Tiempo.

o Los niveles de dimensión de tiempo ahora tienen una propiedad Sequence Numbers.

o Son opcionales y por motivos de rendimiento.

Pag. 9 de 15
Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

Avda.Valhondo, s/n
Edificio III Milenio
Módulo 2, 3ª Planta
06800 – Mérida

ORACLE ANALYTIC SERVER (OAS)

BUENAS PRÁCTICAS PARA EL DESARROLLO

o Las consultas de series de tiempo (Ago, Todate, ...) son complejas y, en ocasiones, el
optimizador de consultas de base de datos elige un orden de combinación subóptimo.
Es más probable que las consultas que utilizan números de secuencia eviten este pro-
blema.

o Las claves cronológicas también deben definirse.

o Existen 2 tipos de secuencias:

▪ Absolutas: claves cronológicas enteras cuyos valores aumentan en 1 y van de

N a M. Por ejemplo, Año de 4 dígitos

▪ Secuencia relativa: valores enteros cuyos valores aumentan en 1 y oscilan entre

1 y N. Los valores representan el orden cronológico dentro de un nivel superior,
p. Ej. Número de mes (1 - 12)

o Las secuencias absolutas y relativas cubren diferentes casos de uso, así que defina
ambos tipos.

• Áreas temáticas simples

o Las carpetas de presentación pequeñas son más fáciles de entender y manipular.

o Intente limitar el número de tablas de hechos, mantenga las que tienen muchas dimen-
siones comunes y están "vinculadas" desde una perspectiva de negocio.

o Configure carpetas de presentación específicas para cada tipo de usuario.

• Dimensiones de Tiempo

o La dimensión de tiempo genérica siempre debe ser la primera tabla de presentación

Pag. 10 de 15
Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

Avda.Valhondo, s/n
Edificio III Milenio
Módulo 2, 3ª Planta
06800 – Mérida

ORACLE ANALYTIC SERVER (OAS)

BUENAS PRÁCTICAS PARA EL DESARROLLO

o Las dimensiones de tiempo "secundarias" pueden tener sus propias tablas de presenta-
ción más abajo

• Áreas temáticas Homogéneas

o Organice primero las tablas de dimensiones empezando con la dimensión de tiempo

genérica.

o Coloque las medidas y los hechos al final, no mezcle las columas de dimensiones y
hechos en la misma tabla de presentación.

o Los nombres de tablas y columnas deben ser coherentes en todas las carpetas. Esto es
muy importante, ya que en caso de no hacerse puede impedir que se recuperen correc-
tamente valores navegando de un informe a otro de otra areá temática.

o Facilite la distinción entre dimensiones y hechos.

• Descripciones de Objetos

o Añada descripciones a las áreas temáticas para explicar el propósito de cada una de
ellas.

o Agregue descripciones a las tablas y columnas de la presentación para que aparezcan

en los informes cuando los usuarios pasen el puntero sobre ellas. Para columnas com-
plejas, explique el contenido de los datos con, por ejemplo, fórmulas de cálculo ...

• Prerrequisitos de navegación

Para satisfacer todos sus requisitos de drill-down, no necesita tener todos sus objetos en una
Pag. 11 de 15
Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

Avda.Valhondo, s/n
Edificio III Milenio
Módulo 2, 3ª Planta
06800 – Mérida

ORACLE ANALYTIC SERVER (OAS)

BUENAS PRÁCTICAS PARA EL DESARROLLO

sola área temática. Por ejemplo, si desea profundizar desde un informe de resumen de
"Pedidos" hasta el nivel de "Artículo de pedido", no es necesario que cree un área temática
única que contenga objetos de pedido y artículo de pedido.

Puede comenzar creando un informe en el área temática de "Pedidos" y luego puede

profundizar en otro informe definido en el área temática "Artículos de pedido".

Solo necesita asegurarse de que los nombres de la tabla / columna de presentación que se le
“solicitan” tengan los mismos nombres en ambas áreas temáticas.

Si los nombres de la tabla / columna de presentación no son los mismos, utilice alias para
hacerlos iguales.

Pag. 12 de 15
Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

Avda.Valhondo, s/n
Edificio III Milenio
Módulo 2, 3ª Planta
06800 – Mérida

ORACLE ANALYTIC SERVER (OAS)

BUENAS PRÁCTICAS PARA EL DESARROLLO

DISEÑO DE PANEL DE CONTROL E INFORMES

• Borre vistas no usadas. Cada vista tiene un coste en rendimiento, actualización y manteni-
miento incluso so no esta inlcuida en los compound layout. Borre todas las vistas no usadas,
incluidas las vistas de tabla.

• Filtros por Defecto de panel de control. Nunca lance un panel de control sin seleccionar va-
lores en los prompts.

o Si sabe valores que son usados más frecuentemente, selecciónelos como valores por
defecto.

o Si no conoce los valores frecuentes, seleccione la opción de prompt antes de abrir. Esto
evitará que el informe se ejecute sin filtros.

• Jerarquías y columnas de atributos

Pag. 13 de 15
Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

Avda.Valhondo, s/n
Edificio III Milenio
Módulo 2, 3ª Planta
06800 – Mérida

ORACLE ANALYTIC SERVER (OAS)

BUENAS PRÁCTICAS PARA EL DESARROLLO

Nunca mezcle jerarquías y columnas de atributos de la misma dimensión en un informe. Esto

conduce a malentendidos y comportamientos inesperados. En particular, cuando se utilizan
solicitudes jerárquicas o cuando hay expresiones que incluyen columna de atributo.

Tenga en cuenta que los pasos de selección generados por solicitudes jerárquicas se aplican
solo a las jerarquías, no a las columnas de atributos.

Sin embargo, agregar filtros en las columnas de atributos funciona bien, incluso si usa la
jerarquía en el informe. Pero no incluya la columna de atributos en las columnas
seleccionadas.

• Grupos y elementos calculados

Es importante comprender las diferencias entre dos tipos de pasos de selección: grupos y
elementos calculados.
o Desde el punto de vista de rendimiento:

▪ Los elementos calculados (en columnas de atributos, no en columnas jerárqui-

cas) se calculan en el servidor de presentación. Se ejecutan en el “result set”
(normalmente pequeño) recuperado de BI Server. Por lo general, no tienen nin-
gún impacto en el rendimiento. En las columnas jerárquicas, sin embargo, ge-
neran consultas físicas y lógicas adicionales y, por lo tanto, afectan el rendi-
miento.
▪ Los grupos se calculan en la base de datos. Generan consultas físicas y lógicas
adicionales. Tienen un impacto significativo en los recursos necesarios en la
base de datos y, por tanto, en el rendimiento global.

o Desde la perspectiva Funcional

▪ En los elementos calculados las reglas de agregación se aplican exactamente

como se definen en la formula. No se consideran las reglas de agregación uti-
lizadas para calcular métricas del Servidor.
▪ Los grupos generan una consulta con un filtro basado en los miembros selec-
cionados. Las reglas de agregación se aplican como de costumbre.

Pag. 14 de 15
Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

Avda.Valhondo, s/n
Edificio III Milenio
Módulo 2, 3ª Planta
06800 – Mérida

ORACLE ANALYTIC SERVER (OAS)

BUENAS PRÁCTICAS PARA EL DESARROLLO

• Buenas prácticas generales para informes

o No coloque demasiadas páginas por panel, todas las páginas deben ser visibles.

o El panel de control debe ser lo más interactivo posible: selectores de columnas, des-
glose, navegación guiada ... La interactividad es uno de los mejores activos de Oracle
Analytics Server. Úselo.

o No abuse de las jerarquías basadas en niveles expandibles, ya que tienden a generar

muchas consultas físicas. A menudo, es necesaria una consulta para cada nivel mos-
trado, más si se utilizan múltiples LTS de hechos.

Pag. 15 de 15