Metodología y Estándares BI

8/17/2019 Metodología y Estándares BI

1/21

y Estándares de Desarrollo

Página :1


2/21

Metodología y Estándares OBIEE

1. INTRODUCCIÓN.......................................................................

!. "roto#olo genera#$%n &odelo de datos en DWH........................'

2.1 Entrega de documentación................................................................4

2.2 Creación del modelo..........................................................................4

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

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

2.5 Entregas entorno de Producción........................................................4

. Re()er$&$entos de d$se*o del &odelo DWH..............................+

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

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

3.3 Claes primarias e !ndices de tablas................................................."

3.4 #ablas particionadas.........................................................................."

3.5 $olumetr!a de las tablas...................................................................."'. Metodología desarrollo OBIEE..................................................,

4.1 Estándares de %esarrollo &epository '()EE ......................................*

4.2 %iisión capas de desarrollo............................................................1+

4.3 ,etodolog!a y estándares del modelo -!sico....................................11

4.4 ,etodolog!a y estándares de la capa lógica....................................14

4.5 ,etodolog!a y estándares de la capa de presentación....................1*

4. Estilos estándares de Presentación/catálogo0..................................2+

+. "ases entre d$erentes entornos............................................!1

Página :2


3/21


1. )N#&'%CC)N

El obetio del presente documento es detallar los estándares deisualiación para los cuadros de mandocentros de in-ormación 6ue sedesarrollen dentro de con el 7n del desarrollo óptimo de la 8erramienta de'racle (usiness )ntelligence Enterprise Edition /'()EE0.

9e recomienda 6ue este documento sira como gu!a para cual6uier personainolucrada en el desarrollo con '()EE. Este documento se debe manteneractualiado incorporando nueos estándares 6ue se ayan de7niendo as!como con detalles de cual6uier cambio en el proceso de desarrollo.

Página :3


4/21


2. Protocol generation DWH datamodel

;u!a a la 8ora de desarrollar modelos de datos 6ue deban ser implantadosen el %ataplotación intentando 8acer lomás ?uido posible el ?uo de trabao.

!.1Documentation Delivery

Entrega de la documentación necesaria para consensuar el modelo dedatos a generar al grupo usuario %@#@ con el 7n de adecuar dic8o modelode datos al modelo de datos de la entidad en cuanto a nomenclatura denombres de tablas campos tipos de datos claes primarias !ndices origen

de los datos procesos a seguir para la carga y la e>plotación del modeloetc.

!.!Model deelo/&ent

na e el modelo de datos está consensuado y alidado por las partesimplicadas se recomienda la creación del modelo por los desarrolladores enlas má6uinas de %esarrollo o Pruebas /'&@()A)N#0 para lo cual se les 8an8abilitado los correspondientes permisos

!.Model tests

&ealiación de pruebas con el modelo generado con la generación enpruebas de los correspondientes procesos de carga y e>plotación de losdatos del modelo.

!.'0#r$/ts Test del$er$es

#ras las pruebas anteriores si el modelo no 8a su-rido cambios respecto alalido por las partes implicadas en el primer paso se entregar!an los scriptsde creación del modelo al grupo de %@#@ unto con la olumetr!a de lastablas incluidas en el modelo.

&ealiación de nueas pruebas con el modelo ya en el entorno real dePruebas. Para la realiación de pruebas durante el desarrollo de losprocesos cuando el modelo está en el es6uema del usuario se recomienda6ue las pruebas se 8agan con una muestra reducida de datos /unos cientos0de -orma 6ue estos datos pueden ser obtenidos a traBs de las di-erentes8erramientas de sentencias 9D. #ras alidar correctamente el modelo laspruebas pueden re6uerir la baada de una mayor cantidad de datos desde elentorno de Producción siempre 6ue las pruebas lo usti76uen.

!.+Production deliveries environment

Por ltimo una e alidados el modelo de datos y los procesos de carga ye>plotación del mismo en las -ec8as acordadas se llearan todos ellos alentorno de Producción a traBs de los medios establecidos.

Página :4


5/21


3. Design requirements DWHmodelEn este apartado se describen las normas básicas de nomenclatura ytratamiento de los obetos 6ue se integren en el modelo %ata imaambigFedad posible.

E>isten 2 tipos básicos de tablas di-erentes para el desarrollo '()EE.

#ablas de 8ec8os3

El nombre de estas tablas tendr!a la siguiente estructura: 456No&2re de ta2la7.En ocasiones se utilian part!culas 6ue an despuBs de las anterioresy 6ue se utilian para agrupar a un conunto de tablas 6ueconceptualmente pertenecen al mismo delo de datos mismoaplicatio etc. n eemplo de esto ser!a 45RI56no&2re5de5ta2la7 para agrupar a las tablas riesgos.

#ablas de looGup o dimensiones:

Estas tablas contendrán la traducción de los campos codi7cados delas tablas de 8ec8os. Cada campo codi7cado se nombrará comoID5Ca&/o y la tabla de looGup se nombrará como D5Ca&/o.

.! Tables naming attributes and data types.

%entro de un entorno de %ata istente 8asta el momento 7ándose en losatributos y tipos de datos utiliados en dic8o modelo antes de emprender eldiseHo de nueas tablas a aHadir al modelo de datos.

Como en el caso de los nombres de las tablas los nombres de los atributostienen 6ue tener una e>tensión má>ima de treinta caracteres.

Página :5


6/21

Metodología y Estándares OBIEE9iempre 6ue se aya a utiliar un atributo 6ue ya e>ista en el modelo dedatos de la entidad se respetará el nombre del atributo y su tipo de datosalo 6ue por necesidades usti7cadas deban de ser ariados alguno oambos.

En el caso de nueos atributos el nombre del atributo debe de ser autoe>plicatio respecto de la naturalea del dato 6ue a a contener.

Para -acilitar esta comprensión se suelen usar una serie de part!culas 6ueayudan en esta tarea como son:

ID5 : En el caso de 6ue la naturalea del dato sea un identi7cador deuna entidad. Dos identi7cadores usados en las tablas deben tener sutabla de looGup en el modelo de datos.

DE0C5 : En el caso de 6ue la naturalea del dato sea una descripciónde algn identi7cador e>istente. Normalmente este tipo de atributosse encuentra en las tablas de looGup o dimensiones de losidenti7cadores usados en el modelo de datos.

IND5 : En el caso de 6ue la naturalea del dato sea la de indicar unestado s!no encendidoapagado etc.

IM"5 : En el caso de 6ue la naturalea del dato sea la de un importe.

089DO5 : En el caso en 6ue la naturalea del dato sea la de un saldo.NUM5 : En el caso en 6ue la naturalea del dato sea un cardinal.

@ parte de las anteriores pueden e>istir otras part!culas utiliadas poratributos del modelo de datos de la entidad 6ue pueden y deben ser usadasen los nueos atributos siempre 6ue sea necesario. Es decir no todos losatributos deben llear estas part!culas si no e>isten ya en el modelo dedatos de la entidad y su nombre es su7cientemente auto e>plicatio de sunaturalea.

@demás tanto la tabla como cada uno de los atributos debe tener sudescripción o comentario lo su7cientemente e>plicatio de su naturaleapudiendo incluir obseraciones posibles alores etc.

&especto de los tipos de datos utiliados es necesario respetar los yae>istentes en el modelo de datos de la entidad y tenerlos como re-erencia ala 8ora de crear nueos atributos con naturalea análoga. Eemplos de loanterior son:

A El tipo de dato de atributos con re-erencia a )% $@&C=@&2/5+0.A El tipo de dato de importes y saldos N,(E&/2150.A El tipo de dato de los indicadores es $@&C=@&2/10 y los alores

serán siempre + ó 1.

Página :


7/21

Metodología y Estándares OBIEEComo comentábamos anteriormente la meor -orma de no e6uiocarse a la8ora de asignar el tipo de dato a un nueo atributo es buscar un atributoanálogo dentro del modelo de datos e>istente y asignarle el mismo tipo dedato.

. "r$&ary :eys and ta2les $nde;es.

Das claes primarias y los !ndices son elementos muy importantes para unacorrecta e>plotación de las tablas por lo 6ue es -undamental su correctade7nición en cuanto a su composición y nmero.

Es importante tener claro e indicar 6ue campos y en 6uB orden a a estarlos campos 6ue -ormen parte de una clae primaria o de un !ndice as! comoel nmero de !ndices 6ue realmente son necesarios ya 6ue los !ndicespueden llegar a ocupar muc8o espacio.

'tra cosa a indicar es si los !ndices an a ser nicos o no.

#ambiBn 8ay 6ue tener en cuenta 6ue los campos 6ue -ormen parte de unaclae primaria no pueden contener alores nulos.

.' "art$t$oned ta2les.

@ la 8ora de realiar el diseHo de una tabla 8ay 6ue tener en cuenta si porel olumen de datos 6ue a a tener dic8a tabla o por necesidades de8istori7cación de los datos es necesario 6ue la tabla se encuentreparticionada por uno o arios campos para -acilitar el acceso a los datos.

En este caso es necesario indicar 6ue la tabla a a estar particionadaademás del campo o campos por el cual se a a realiar el particionamientoy la -recuencia de borrado de las particiones obsoletas.

.+ Ta2les


8/21

Metodología y Estándares OBIEEun periodo de tiempo a ser posible anualmente para austar meor lasestimaciones de espacio dentro del modelo de datos.

Por lo anterior es totalmente necesario indicar la olumetr!a de una tabla ala 8ora de presentar el diseHo para su implantación ya 6ue sin esta

olumetr!a no se crearán las tablas.

4. ,et8odology %eelopment

'()EE'.1 OBIEE Re/os$tory Deelo/&ent 0tandards

%entro de un entorno de desarrollo '()EE es -undamental mantener unaco8erencia en cuanto a los nombres de las mBtricas y dimensiones por los6ue se e>plotará la in-ormación.

Como primera norma todo desarrollador trabaará en su local pudiendo as!

trabaar independientemente un desarrollador de otro sin tener 6ueinter-erir entre los desarrollos de di-erentes proyectos.

Para realiar estos desarrollos independientemente abriremos un &P%nueo.

Este repositorio será limpio es decir sin las ariables de sesión ni)nitialitation blocGs aportados por el repositorio de desarrollo solamente seincluirán las ariables nueas necesitadas para este proyecto/puesto 6uepodr!amos tener problemas entre el merge de los repositorios0. #odorepositorio nueo deberá contener la contraseHa implantada en el &P% delentorno de desarrollo para al @dministrador para realiar las subidas yprocesos merge sin ningn problema aHadido.

Página :*


9/21


na e realiado y alidado el repositorio construido por el desarrolladorse probará 6ue el proceso merge -unciona correctamente.

Para ello abriremos una copia del repositorio de desarrollo

=e incluiremos el nueo desarrollo en el repositorio de desarrollo.

Página :I


10/21


na e realiado el proceso merge de los dos repositorios el desarrolladordeberá probar el resultado en el seridor local para comprobar 6ue no 8ayningn problema en la unión de estos dos repositorios y -uncionacorrectamente.

'.!Deelo/&ent D$$s$on layers.

Physical Layer

Para la generación del repositorio desde el inicio siempre se realiará lacreación de un nueo pool de cone>iones

Página :1+


11/21


El desarrollador deberá de abrir esas cone>iones con el nombre del proyectoal 6ue re-erencia su cone>ión.

#odos los pools tendrán la misma cadena de cone>ión a '&@() integración yutiliaremos el mismo usuario para todas estas nueas cone>iones /DJ'()0.

Página :11


12/21


'.Methodology and standards physical model

na e realiado el nueo pool de cone>ión para el proyecto deseado eldesarrollador deberá tomar un estándar a la 8ora de desarrollar.

El orden y la limpiea del desarrollo será clae en la creación del proyectosiendo más accesible para cual6uier desarrollador y cual6uier posiblemodi7cación.

Para ello podemos di-erenciar la siguiente normatia:

Physical relationships

Normas de relación:

Podemos di-erenciar las bases de las relaciones -!sicas dentro delrepositorio

1. Creating aliases

;eneración de alias para todas las tablas de mBtricas ydimensiones dentro de cada proyecto.

!. Physical relationship.

#odas las tablas serán relacionadas a traBs de sus alias nuncairán relacionadas por las tablas -!sicas.

Página :12


13/21


. 0tar Model.

9iempre contendrá la tabla de 8ec8os como la central del modelomultidimensional se intentará realiar una a#t =n$#a.

El desarrollador realiará tablas agregadas si es necesario para poderrealiar una meora en el rendimiento y optimiación de las consultas.

'. Nomenclature

Das normas de nomenclatura dentro del modelo -!sico son:

No modi7car el nombre de ninguna de las tablas -!sicas ya seandimensiones o -acts.

9e renombrarán todos los alias e>istentes con el siguiente -ormato:

D$&ens$ons

%imensión Nombre de la dimensión a utiliar en la capa depresentación y el nombre de la tabla -!sica ((.%%

4a#t Ta2le

,Btricas Nombre del Proyecto niel de la tabla y el nombre de la tabla-!sica ((.%%

Página :13


14/21

Metodología y Estándares OBIEE+. 0>ort$ng

Da ordenación es un -actor importante a la 8ora del desarrollo paratener una claridad y de7nición de trabao.

Por regla general seguiremos la siguiente estructura:A %imensiones/alias0A Kacts/alias0A %imensiones -!sicasA Kacts -!sicas

El repositorio se ordena al-abBticamente por lo cual el desarrollador deberáponer un guión para cumplir el orden pertinente.

Página :14


15/21


'.'Met>odology and standars ro& log$# layer

Podemos diidir la creación del modelo de negocio en 3 partes

-undamentales.- Hierarchies

9e di-erencian de las dimensiones por el icono.

9olamente generaremos la erar6u!a cuando realmente seanecesaria la pro-undiación.

#odas las erar6u!as comenarán con una agrupación total delindicador.

Página :15


16/21


Cada uno de los nieles estará compuesto del identi7cador y sudescripción 8aciendo as! 6ue las erar6u!as sean más óptimas8aciendo la pro-undiación solamente la descripción.

- D$&ens$ons

Das dimensiones contendrán todos los identi7cadores descripcionesy atributos necesarios para cada uno de los ees de e>plotación.

Da ordenación se realiará en el orden de agrupación de los nielessuperiores a los nieles in-eriores /si la dimensión contiene nieles0en la parte superior el desarrollador ordenará las descripcionesseguidamente sus identi7cadores y los atributos 6ue puedanencontrarse.

Página :1


17/21

Metodología y Estándares OBIEE- Metr$#s

Das tablas de mBtricas solamente contendrán los aloresrelacionados por cada uno de los indicadores de negocio.

E>clusiamente introduciremos en la capa lógica alores en lamedida de lo posible numBricos y no incorporando todos lascolumnas encontradas en las tablas -!sicas.Dos identi7cadores y atributos 6uedar!an -uera de esta parte /si noson e>clusiamente necesarios0 para dar una claridad a lasmBtricas de negocio aportadas.

9i es necesario se generarán columnas lógicas para 8aceragrupación de di-erentes tBrminos con una e6uialencia comn.

No&en#lat)ra3

I&/. 3 )mporte seguido del nombre del importe al 6ue pertenece.)mp. Contratación.0aldo3 9aldo seguido del nombre del saldo al 6ue pertenece. [email protected]?. 3 Nmero unto a la procedencia de ese nmero. NL Clientes.Ind. 3 )ndicadores necesarios para la e>plotación de la in-ormación6ue no e>istan en las dimensiones comunes.Id. 3 )denti7cadores necesarios para la e>plotación de lain-ormación 6ue no e>istan en las dimensiones comunes.

Página :1"


18/21


En el caso 6ue necesitemos mBtricas utiliadas e>clusiamente por eldesarrollador y no como isión de negocio se realiará una columna lógicacon la siguiente estructura:

Da cual agrupará todas esas mBtricas necesarias para el desarrollo de loscuadros de mando.

Da ordenación de la capa lógica será con el mismo -ormato 6ue la capa-!sica ordenando las erar6u!as dimensiones y tablas de mBtricas.

Podemos di-erenciar dos ordenaciones di-erentes dependiento del tipo detabla lógica:

D$&ens$%n

%eberán ordenarse por %escripciones /siguiendo los nieles depro-undidad0 y sus identi7cadores por cada uno de esos nieles.

Página :1*


19/21

Metodología y Estándares OBIEEM@tr$#as

#odas las mBtricas irán ordenadas y agrupadas por tipolog!a de mBtrica:

I&/.

0aldo

Id.

A

Dos nombres de las tablas de dimensiones y mBtricas serán e>actamenteigual 6ue en la capa -!sica e>ceptuando el guión y el nombre de la tabla-!sica.

'.+Metodología y estándares de la #a/a de /resenta#$%n

9e denomina capa de usuario es la inter-a grá7ca del usuario por lo cualesta capa deberá estar bien de7nida con anterioridad /nombresordenación0 puesto 6ue es la capa de negocio 6ue el usuario aanadopodrá utiliar para generar el reporting segn sus necesidades.

Página :1I


20/21


El desarrollador deberá ordenar lo má>imo posible las dimensiones ymBtricas en la capa de presentación.

'rden de presentación- D$&ens$ones

Das dimensiones a su e deberán ir ordenadas de arriba abao conorden de pre-erencia de esas dimensiones:

4e#>asEstr)#t)ra Organ$at$aA

Dos nombres de cada una de las dimensiones serán e>actamente

igual 6ue en la capa lógica e>cepto la descripción del tipo de tabla.

- Ta2las de M@tr$#as

Para di-erenciar las tablas de mBtricas de las dimensiones eldesarrollador realiará un cambio de icono para estas tablas demBtricas.

Por regla general y para mantener una concordancia con el resto deproyectos el icono será igual para todas las tablas de mBtricase>istentes de7niendo como tal el icono estándar.

Página :2+


21/21

Metodología y Estándares OBIEE'.Est$los estándares de "resenta#$%n#atálogo

Da presentación del catálogo estará construida con -ormato propio recogido con las 8oas de estilo de7nidas. Nunca 8abrá 6ue retocar elestado predeterminado del in-orme y en el caso 6ue esto sea necesario se

realiar!a la consulta al e6uipo %@#@.

9e realiará una carpeta compartida para 6ue todo desarrollador puedasimular el entorno de desarrollo as! poder er el resultado 7nal en su propiolocal.

El estilo a con7gurar como predeterminado será el estilo . Para elloutiliaremos todos los arc8ios en local tanto de &P% como de catálogo paracon7gurarlo de la misma manera.

Nos re-erimos a las siguientes carpetas de con7guración:

M'racle()MsererMCon7g

M'racle()%ataMebMcon7g

Cambiando las rutas de los arc8ios de con7guración para poder leer de lamá6uina local.

Página :21

Metodología y Estándares BI

Documents

Transcript of Metodología y Estándares BI