a y Estndares de Desarrollo D

Pgina :1

Metodologa y Estndares OBIEE

1. INTRODUCCIN.......................................................................3
2. Protocolo generacin modelo de datos en DWH........................4
2.1

Entrega de documentacin................................................................4

2.2

Creacin del modelo..........................................................................4

2.3

Pruebas del modelo...........................................................................4

2.4

Entrega scripts y pruebas..................................................................4

2.5

Entregas entorno de Produccin........................................................4

3. Requerimientos de diseo del modelo DWH..............................5

3.1

Nomenclatura de tablas.....................................................................5

3.2

Nomenclatura de atributos tablas y tipos de datos...........................5

3.3

Claves primarias e ndices de tablas.................................................7

3.4

Tablas particionadas..........................................................................7

3.5

Volumetra de las tablas....................................................................7

4. Metodologa desarrollo OBIEE..................................................8

4.1

Estndares de Desarrollo Repository OBIEE ......................................8

4.2

Divisin capas de desarrollo............................................................10

4.3

Metodologa y estndares del modelo fsico....................................11

4.4

Metodologa y estndares de la capa lgica....................................14

4.5

Metodologa y estndares de la capa de presentacin....................18

4.6

Estilos estndares de Presentacin(catlogo)..................................20

5. Pases entre diferentes entornos............................................21

Pgina :2

Metodologa y Estndares OBIEE

1. INTRODUCCIN
El objetivo del presente documento es detallar los estndares de
visualizacin para los cuadros de mando/centros de informacin que se
desarrollen dentro de con el fin del desarrollo ptimo de la herramienta de
Oracle Business Intelligence Enterprise Edition (OBIEE).
Se recomienda que este documento sirva como gua para cualquier persona
involucrada en el desarrollo con OBIEE. Este documento se debe mantener
actualizado, incorporando nuevos estndares que se vayan definiendo as
como con detalles de cualquier cambio en el proceso de desarrollo.

Pgina :3

Metodologa y Estndares OBIEE

2. Protocol generation DWH data

model
Gua a la hora de desarrollar modelos de datos que deban ser implantados
en el DataWareHouse de la entidad para su explotacin, intentando hacer lo
ms fluido posible el flujo de trabajo.
2.1 Documentation Delivery
Entrega de la documentacin necesaria, para consensuar el modelo de
datos a generar, al grupo usuario DATA, con el fin de adecuar dicho modelo
de datos al modelo de datos de la entidad en cuanto a nomenclatura de
nombres de tablas, campos, tipos de datos, claves primarias, ndices, origen
de los datos, procesos a seguir para la carga y la explotacin del modelo,
etc.
2.2 Model development
Una vez el modelo de datos est consensuado y validado por las partes
implicadas, se recomienda la creacin del modelo por los desarrolladores en
las mquinas de Desarrollo o Pruebas (ORABI-INT), para lo cual se les han
habilitado los correspondientes permisos
2.3 Model tests
Realizacin de pruebas con el modelo generado, con la generacin en
pruebas de los correspondientes procesos de carga y explotacin de los
datos del modelo.
2.4 Scripts & Test deliveries
Tras las pruebas anteriores, si el modelo no ha sufrido cambios respecto al
valido por las partes implicadas en el primer paso, se entregaran los scripts
de creacin del modelo al grupo de DATA, junto con la volumetra de las
tablas incluidas en el modelo.
Realizacin de nuevas pruebas con el modelo ya en el entorno real de
Pruebas. Para la realizacin de pruebas durante el desarrollo de los
procesos, cuando el modelo est en el esquema del usuario, se recomienda
que las pruebas se hagan con una muestra reducida de datos (unos cientos)
de forma que estos datos pueden ser obtenidos a travs de las diferentes
herramientas de sentencias SQL. Tras validar correctamente el modelo, las
pruebas pueden requerir la bajada de una mayor cantidad de datos desde el
entorno de Produccin, siempre que las pruebas lo justifiquen.
2.5 Production deliveries environment
Por ltimo, una vez validados el modelo de datos y los procesos de carga y
explotacin del mismo, en las fechas acordadas se llevaran todos ellos al
entorno de Produccin a travs de los medios establecidos.
Pgina :4

Metodologa y Estndares OBIEE

3. Design requirements DWH

model
En este apartado se describen las normas bsicas de nomenclatura y
tratamiento de los objetos que se integren en el modelo Data Warehouse de
la entidad.

3.1

Table naming.

Es bsico para el desarrollo adecuado de cualquier tarea de desarrollo el

tener una nomenclatura de trminos normalizada que elimine la mxima
ambigedad posible.
Existen 2 tipos bsicos de tablas diferentes para el desarrollo OBIEE.
Tablas de hechos:
El nombre de estas tablas tendra la siguiente estructura:
F_<Nombre de tabla>.
En ocasiones, se utilizan partculas que van despus de las anteriores,
y que se utilizan para agrupar a un conjunto de tablas que
conceptualmente pertenecen al mismo delo de datos, mismo
aplicativo, etc. Un ejemplo de esto sera F_RI_<nombre_de_tabla>
para agrupar a las tablas riesgos.
Tablas de lookup o dimensiones:
Estas tablas contendrn la traduccin de los campos codificados de
las tablas de hechos. Cada campo codificado se nombrar como
ID_Campo y la tabla de lookup se nombrar como D_Campo.

3.2

Tables naming attributes and data types.

Dentro de un entorno de Data WareHouse, es fundamental mantener una

coherencia en cuanto a los nombres de los atributos y a los tipos de datos
utilizados dentro del modelo o modelos de datos.
La mejor forma de mantener esta coherencia, es llegar a tener una visin
general de modelo de datos existente hasta el momento, fijndose en los
atributos y tipos de datos utilizados en dicho modelo, antes de emprender el
diseo de nuevas tablas a aadir al modelo de datos.
Como en el caso de los nombres de las tablas, los nombres de los atributos
tienen que tener una extensin mxima de treinta caracteres.
Pgina :5

Metodologa y Estndares OBIEE

Siempre que se vaya a utilizar un atributo que ya exista en el modelo de
datos de la entidad, se respetar el nombre del atributo y su tipo de dato,
salvo que por necesidades justificadas deban de ser variados alguno o
ambos.
En el caso de nuevos atributos, el nombre del atributo debe de ser auto
explicativo respecto de la naturaleza del dato que va a contener.
Para facilitar esta comprensin, se suelen usar una serie de partculas que
ayudan en esta tarea, como son:

ID_ : En el caso de que la naturaleza del dato sea un identificador de

una entidad. Los identificadores usados en las tablas deben tener su
tabla de lookup en el modelo de datos.
DESC_ : En el caso de que la naturaleza del dato sea una descripcin
de algn identificador existente. Normalmente, este tipo de atributos
se encuentra en las tablas de lookup o dimensiones de los
identificadores usados en el modelo de datos.
IND_ : En el caso de que la naturaleza del dato sea la de indicar un
estado s/no, encendido/apagado, etc.
IMP_ : En el caso de que la naturaleza del dato sea la de un importe.
SALDO_ : En el caso en que la naturaleza del dato sea la de un saldo.
NUM_ : En el caso en que la naturaleza del dato sea un cardinal.
A parte de las anteriores, pueden existir otras partculas utilizadas por
atributos del modelo de datos de la entidad que pueden y deben ser usadas
en los nuevos atributos siempre que sea necesario. Es decir, no todos los
atributos deben llevar estas partculas si no existen ya en el modelo de
datos de la entidad y su nombre es suficientemente auto explicativo de su
naturaleza.
Adems, tanto la tabla como cada uno de los atributos, debe tener su
descripcin o comentario lo suficientemente explicativo de su naturaleza,
pudiendo incluir observaciones, posibles valores, etc.
Respecto de los tipos de datos utilizados, es necesario respetar los ya
existentes en el modelo de datos de la entidad y tenerlos como referencia a
la hora de crear nuevos atributos con naturaleza anloga. Ejemplos de lo
anterior son:
-

El tipo de dato de atributos con referencia a ID VARCHAR2(50).

El tipo de dato de importes y saldos NUMBER(21,5).
El tipo de dato de los indicadores es VARCHAR2(1), y los valores
sern siempre 0 1.
Pgina :6

Metodologa y Estndares OBIEE

Como comentbamos anteriormente, la mejor forma de no equivocarse a la
hora de asignar el tipo de dato a un nuevo atributo es buscar un atributo
anlogo dentro del modelo de datos existente y asignarle el mismo tipo de
dato.

3.3

Primary Keys and tables indexes.

Las claves primarias y los ndices son elementos muy importantes para una
correcta explotacin de las tablas, por lo que es fundamental su correcta
definicin en cuanto a su composicin y nmero.
Es importante tener claro e indicar que campos y en qu orden va a estar
los campos que formen parte de una clave primaria o de un ndice, as como
el nmero de ndices que realmente son necesarios, ya que los ndices
pueden llegar a ocupar mucho espacio.
Otra cosa a indicar es si los ndices van a ser nicos o no.
Tambin hay que tener en cuenta que los campos que formen parte de una
clave primaria no pueden contener valores nulos.

3.4

Partitioned tables.

A la hora de realizar el diseo de una tabla, hay que tener en cuenta si por
el volumen de datos que va a tener dicha tabla o por necesidades de
historificacin de los datos, es necesario que la tabla se encuentre
particionada por uno o varios campos para facilitar el acceso a los datos.
En este caso, es necesario indicar que la tabla va a estar particionada,
adems del campo o campos por el cual se va a realizar el particionamiento
y la frecuencia de borrado de las particiones obsoletas.

3.5

Tables Volumetry.

Un dato muy importante, y que suele obviarse, es la volumetra de una

tabla, ya que el alojamiento de una tabla en un tablespace determinado de
la Base de Datos vendr determinado por el tipo de la tabla as como por el
tamao futuro de la tabla, adems de tener en cuenta si la tabla debe ser
particionada o no.
As, a la hora de indicar el tamao de una tabla, hay que indicar el tamao
que inicialmente pueda tener as como el incremento que vaya a tener en
Pgina :7

Metodologa y Estndares OBIEE

un periodo de tiempo, a ser posible anualmente, para ajustar mejor las
estimaciones de espacio dentro del modelo de datos.
Por lo anterior, es totalmente necesario indicar la volumetra de una tabla a
la hora de presentar el diseo para su implantacin, ya que sin esta
volumetra no se crearn las tablas.

4. Methodology Development
OBIEE
4.1

OBIEE Repository Development Standards

Dentro de un entorno de desarrollo OBIEE, es fundamental mantener una

coherencia en cuanto a los nombres de las mtricas y dimensiones por los
que se explotar la informacin.
Como primera norma, todo desarrollador trabajar en su local, pudiendo as
trabajar independientemente un desarrollador de otro, sin tener que
interferir entre los desarrollos de diferentes proyectos.
Para realizar estos desarrollos independientemente abriremos un RPD
nuevo.
Este repositorio ser limpio, es decir, sin las variables de sesin ni
Initialitation blocks aportados por el repositorio de desarrollo, solamente se
incluirn las variables nuevas necesitadas para este proyecto(puesto que
podramos tener problemas entre el merge de los repositorios). Todo
repositorio nuevo deber contener la contrasea implantada en el RPD del
entorno de desarrollo para al Administrador, para realizar las subidas y
procesos merge sin ningn problema aadido.

Pgina :8

Metodologa y Estndares OBIEE

Una vez realizado y validado el repositorio construido por el desarrollador,

se probar que el proceso merge funciona correctamente.
Para ello abriremos una copia del repositorio de desarrollo

He incluiremos el nuevo desarrollo en el repositorio de desarrollo.

Pgina :9

Metodologa y Estndares OBIEE

Una vez realizado el proceso merge de los dos repositorios, el desarrollador

deber probar el resultado en el servidor local, para comprobar que no hay
ningn problema en la unin de estos dos repositorios y funciona
correctamente.

4.2 Development Division layers.

Physical Layer

Para la generacin del repositorio desde el inicio, siempre se realizar la

creacin de un nuevo pool de conexiones

Pgina :10

Metodologa y Estndares OBIEE

El desarrollador deber de abrir esas conexiones con el nombre del proyecto

al que referencia su conexin.

Todos los pools tendrn la misma cadena de conexin a ORABI integracin, y

utilizaremos el mismo usuario para todas estas nuevas conexiones (L_OBI).

Pgina :11

Metodologa y Estndares OBIEE

4.3 Methodology and standards physical model

Una vez realizado el nuevo pool de conexin para el proyecto deseado, el
desarrollador deber tomar un estndar a la hora de desarrollar.
El orden y la limpieza del desarrollo ser clave en la creacin del proyecto,
siendo ms accesible para cualquier desarrollador y cualquier posible
modificacin.
Para ello podemos diferenciar la siguiente normativa:

Physical relationships

Normas de relacin:
Podemos diferenciar las bases de las relaciones fsicas dentro del
repositorio
1. Creating aliases
Generacin de alias para todas las tablas de mtricas y
dimensiones dentro de cada proyecto.
2. Physical relationship.
Todas las tablas sern relacionadas a travs de sus alias, nunca
irn relacionadas por las tablas fsicas.
Pgina :12

Metodologa y Estndares OBIEE

3. Star Model.
Siempre contendr la tabla de hechos como la central del modelo
multidimensional, se intentar realizar una fact nica.
El desarrollador realizar tablas agregadas si es necesario para poder
realizar una mejora en el rendimiento y optimizacin de las consultas.

4. Nomenclature
Las normas de nomenclatura dentro del modelo fsico son:
No modificar el nombre de ninguna de las tablas fsicas, ya sean
dimensiones o facts.
Se renombrarn todos los alias existentes, con el siguiente formato:
Dimensions
Dimensin Nombre de la dimensin a utilizar en la capa de
presentacin y el nombre de la tabla fsica BB.DD

Fact Table
Mtricas Nombre del Proyecto nivel de la tabla y el nombre de la tabla
fsica BB.DD

Pgina :13

Metodologa y Estndares OBIEE

5. Shorting
La ordenacin es un factor importante a la hora del desarrollo, para
tener una claridad y definicin de trabajo.
Por regla general seguiremos la siguiente estructura:
-

Dimensiones(alias)
Facts(alias)
Dimensiones fsicas
Facts fsicas

El repositorio se ordena alfabticamente por lo cual el desarrollador deber

poner un guin para cumplir el orden pertinente.

Pgina :14

Metodologa y Estndares OBIEE

4.4 Methodology and standars from logic layer
Podemos dividir la creacin del modelo de negocio en 3 partes
fundamentales.
-

Hierarchies
Se diferencian de las dimensiones por el icono.
Solamente generaremos la jerarqua cuando realmente sea
necesaria la profundizacin.
Todas las jerarquas comenzarn con una agrupacin total del
indicador.

Pgina :15

Metodologa y Estndares OBIEE

Cada uno de los niveles estar compuesto del identificador y su
descripcin haciendo as que las jerarquas sean ms ptimas,
haciendo la profundizacin solamente la descripcin.

Dimensions
Las dimensiones contendrn todos los identificadores, descripciones
y atributos necesarios, para cada uno de los ejes de explotacin.
La ordenacin se realizar en el orden de agrupacin de los niveles
superiores a los niveles inferiores (si la dimensin contiene niveles),
en la parte superior el desarrollador ordenar las descripciones
seguidamente sus identificadores, y los atributos que puedan
encontrarse.

Pgina :16

Metodologa y Estndares OBIEE

-

Metrics
Las tablas de mtricas solamente contendrn los valores
relacionados por cada uno de los indicadores de negocio.
Exclusivamente introduciremos en la capa lgica valores en la
medida de lo posible numricos y no incorporando todos las
columnas encontradas en las tablas fsicas.
Los identificadores y atributos quedaran fuera de esta parte (si no
son exclusivamente necesarios), para dar una claridad a las
mtricas de negocio aportadas.
Si es necesario se generarn columnas lgicas para hacer
agrupacin de diferentes trminos con una equivalencia comn.
Nomenclatura:
Imp. : Importe seguido del nombre del importe al que pertenece.
Imp. Contratacin.
Saldo: Saldo seguido del nombre del saldo al que pertenece. Saldo
Activo.
N. : Nmero junto a la procedencia de ese nmero. N Clientes.
Ind. : Indicadores necesarios para la explotacin de la informacin
que no existan en las dimensiones comunes.
Id. : Identificadores necesarios para la explotacin de la
informacin que no existan en las dimensiones comunes.

Pgina :17

Metodologa y Estndares OBIEE

En el caso que necesitemos mtricas utilizadas exclusivamente por el

desarrollador y no como visin de negocio, se realizar una columna lgica
con la siguiente estructura:

La cual agrupar todas esas mtricas necesarias para el desarrollo de los

cuadros de mando.
La ordenacin de la capa lgica ser con el mismo formato que la capa
fsica, ordenando las jerarquas, dimensiones y tablas de mtricas.
Podemos diferenciar dos ordenaciones diferentes dependiento del tipo de
tabla lgica:
Dimensin
Debern ordenarse por Descripciones (siguiendo los niveles de
profundidad), y sus identificadores por cada uno de esos niveles.

Pgina :18

Metodologa y Estndares OBIEE

Mtricas
Todas las mtricas irn ordenadas y agrupadas por tipologa de mtrica:
Imp.
Saldo
Id.

Los nombres de las tablas de dimensiones y mtricas sern exactamente

igual que en la capa fsica exceptuando el guin y el nombre de la tabla
fsica.

4.5 Metodologa y estndares de la capa de presentacin

Se denomina capa de usuario, es la interfaz grfica del usuario, por lo cual
esta capa deber estar bien definida con anterioridad (nombres,
ordenacin), puesto que es la capa de negocio que el usuario avanzado
podr utilizar, para generar el reporting segn sus necesidades.

Pgina :19

Metodologa y Estndares OBIEE

El desarrollador deber ordenar lo mximo posible las dimensiones y
mtricas en la capa de presentacin.
Orden de presentacin
-

Dimensiones
Las dimensiones a su vez debern ir ordenadas de arriba abajo con
orden de preferencia de esas dimensiones:
Fechas
Estructura Organizativa

Los nombres de cada una de las dimensiones sern exactamente

igual que en la capa lgica excepto la descripcin del tipo de tabla.

Tablas de Mtricas
Para diferenciar las tablas de mtricas de las dimensiones el
desarrollador realizar un cambio de icono para estas tablas de
mtricas.
Por regla general y para mantener una concordancia con el resto de
proyectos el icono ser igual para todas las tablas de mtricas
existentes, definiendo como tal el icono estndar.

Pgina :20

Metodologa y Estndares OBIEE

4.6 Estilos estndares de Presentacin(catlogo)
La presentacin del catlogo estar construida con formato propio ,
recogido con las hojas de estilo definidas. Nunca habr que retocar el
estado predeterminado del informe, y en el caso que esto sea necesario, se
realizara la consulta al equipo DATA.
Se realizar una carpeta compartida, para que todo desarrollador pueda
simular el entorno de desarrollo, as poder ver el resultado final en su propio
local.
El estilo a configurar como predeterminado ser el estilo . Para ello
utilizaremos todos los archivos en local tanto de RPD como de catlogo para
configurarlo de la misma manera.
Nos referimos a las siguientes carpetas de configuracin:
\OracleBI\server\Config
\OracleBIData\web\config
Cambiando las rutas de los archivos de configuracin para poder leer de la
mquina local.

Pgina :21