Diseo BBDD --> BBDD DatawareHousing y Business Intelligence

Pgina 1 de 12

12th September 2012

Diseo BBDD --> BBDD DatawareHousing y Business Intelligence

[http://4.bp.blogspot.com/-39hfO7Jfj2o/UFBUFsR_GhI/AAAAAAAAC -A/UZZQASIUoN0/s1600/BusinessIntelligence_II.gif]

Dificultad: Alta. Hasta ahora hemos visto, como modelo de datos, el ms extendido de todos, que es el modelo relacional. Este modelo resulta claro, intuitivo, evita duplicidad de datos, mantiene la consistencia de estos y deja clara las relaciones entre las distintas entidades, haciendo las aplicaciones mucho ms sencillas, escalables y mantenibles. Pero entre tanta virtud adolece de un defecto, y es que cuando aumentamos enormemente el volumen de datos, se vuelve desesperadamente lento. Y tenemos algn ejemplo de bases de datos que tengan un volumen de datos tan amplio como para que se de este caso?. Si: el Business Intelligence.

Que es el Business Intelligence?

Se trata de aplicaciones denominadas de "Decisin Ejecutiva". De forma resumida, son aplicaciones de carcter analtico que se utilizan a nivel de alta jerarqua de grandes empresas y a partir de las cuales toman decisiones. De hecho se las llama, tambin, aplicaciones de "Ayuda a la toma de decisiones".

http://ora-flashes.blogspot.com.br/2012/09/optimizacion-creacion-de-indices-en_4.html

17/07/2013

Diseo BBDD --> BBDD DatawareHousing y Business Intelligence

Pgina 2 de 12

[http://4.bp.blogspot.com/ZD2jB3Yg3Ww/UFBRCp1zqsI/AAAAAAAAC9Y/KWOU4K1JcA4/s1600/BI_Esquema_Basico.jpg]

Porque motivo tienen tanto volumen de datos?

Dado su caracter analtico, estas bases de datos reciben gran cantidad de informacin. El funcionamiento de una base de datos de Business Intelligence es, bsicamente, el siguiente: el sistema recibe, mediante ficheros de texto plano (o hexadecimales, en algunos casos), los datos correspondientes de cada uno de los sistemas de la empresa, se cargan en base de datos, se procesan los datos, y se dejan segn el diseo para anlisis que ms convenga, para ser explotados por herrameintas que generen los "Cuadros de mando" y que transforme esos datos obtenidos en algo analizable por una persona. Lo entenderemos mejor con un ejemplo: imaginemos que trabajamos para un banco y este quiere tener todas las transacciones que se realicen desde los cajeros automticos (del propio banco) de toda Espaa. Se enviar al sistema de BI (Business Intelligence) mediante fichero de texto plano (uno o, lo ms normal, muchos) todas estas transacciones (imaginaros el nmero de estas transacciones que un banco, como el Santander o Bankia, pudieran tener). Estos datos son cargados en base de datos y, posteriormente tratados para dejarlos manejables, en las tablas finales, que tendrn un diseo adecuado para ser accedidas por herramientas de "Decisin Ejecutiva".

Como los tratamos?

Como es de suponer, de forma intuitiva, un volumen tan alto de datos (podemos hablar, en muchos casos, de millones de registros diarios), dar grandes problemas de tiempos a la hora de realizar las consultas. Por eso la forma de trabajar con ellas nada tiene que ver con las tpicas bases de datos relacionales, para

http://ora-flashes.blogspot.com.br/2012/09/optimizacion-creacion-de-indices-en_4.html

17/07/2013

Diseo BBDD --> BBDD DatawareHousing y Business Intelligence

Pgina 3 de 12

sistemas transacionales. Esto es algo totalmente diferente. Veamos por partes las formas ms convenientes para trabajar con estas bases de datos.

[http://2.bp.blogspot.com/AVZLILW_9Zg/UFBRGA86uhI/AAAAAAAAC9g/Dhp1CRkXFmo/s1600/arquitectura_DW.jpg]

Primero: la carga de datos

La primera parte, siempre, ser la carga de los datos desde los ficheros administrados por los diferentes sistemas. Por lo general estos ficheros se reciben diariamente, bien por la noche con la informacin correspondiente a ese da, o bien durante el da con informacin correspondiente con el da anterior. Al no tratarse de un sistema transacional, no tendr nunca datos en tiempo real de los sistemas, sino que tendremos una foto de un momento dado, segn como se decida enviar la informacin. Oracle nos ofrece varios sistemas para cargar los datos provinientes desde un fichero de texto plano, pero dos son las ms extendidas: el Oracle SQL Loader y las External Tables. En realidad se trata de dos maneras diferentes de hacer lo mismo. Sql Loader Por una parte el SQL Loader es una herramienta de Oracle, externa, que se ejecuta desde el sistema operativo, y que cargar los datos en la tablas tablas que le definamos en un fichero de control. Har falta crear un fichero de control por tabla a cargar, y este fichero de control cargar un archivo en cada ejecucin, siguiendo el siguiente esquema:

http://ora-flashes.blogspot.com.br/2012/09/optimizacion-creacion-de-indices-en_4.html

17/07/2013

Diseo BBDD --> BBDD DatawareHousing y Business Intelligence

Pgina 4 de 12

El fichero de control, dar la siguiente informacin a Oracle: Nombre y localizacin del fichero de entrada de datos. Formato de los registros del fichero de entrada de datos. El nombre de la tabla a cargar. La correspondencia entre los campos de la tabla y los datos recibidos en el fichero a cargar. Criterio de seleccin definiendo que registros del fichero de entrada contienen datos que deben ser insertados en la base de datos. Los nombres y localizacin del fichero de errores (bad file) y el fichero de registros descartados (discard file) Para ver, a nivel tcnico como funciona el fichero de control (control file), ver la documentacin oficial de Oracle (http://docs.oracle.com/cd/B10500_01/server.920/a96652/ch05.htm [http://docs.oracle.com/cd/B10500_01/server.920/a96652/ch05.htm] ). Una vez que tengamos el fichero de control, y el fichero de datos, simplemente ser necesario invocar la sentencia del SQL Loader:

sqlldr

NOMBREUSUARIO/CONTRASEA@NOMBRESERVICIO

[mailto:NOMBREUSUARIO/CONTRASEA@NOMBRESERVICIO]

control=RUTAARCHIVOCONTROL log=RUTAARCHIVOLOG data=RUTAORIGENDATOS. Donde: sqlldr es la aplicacin de sql Loader. NOMBREUSUARIO/CONTRASEA@NOMBRESERVICIO

[mailto:NOMBREUSUARIO/CONTRASEA@NOMBRESERVICIO] son los datos bsicos de conexin a la

base de datos. control=RUTAARCHIVOCONTROL es donde indicamos la ruta y nombre del fichero de control que hayamos creado. log=RUTAARCHIVOLOG es donde indicamos la ruta y nombre del fichero de log que queramos crear. data=RUTAORIGENDATOS es donde indicamos la ruta y el nombre del fichero que contiene los datos que vamos a cargar. Para ms informacin, aqu teneis la documentacin (http://docs.oracle.com/cd/B19306_01/server.102/b14215/ldr_concepts.htm [http://docs.oracle.com/cd/B19306_01/server.102/b14215/ldr_concepts.htm] ). External tables Otra forma ms eficiente de cargar los datos en Oracle, es mediante external tables. Desde el punto de vista conceptual consiste, bsicamente, en crear una tabla en base de datos que lea directamente la informacin del archivo recibido. oficial de Oracle

http://ora-flashes.blogspot.com.br/2012/09/optimizacion-creacion-de-indices-en_4.html

17/07/2013

Diseo BBDD --> BBDD DatawareHousing y Business Intelligence

Pgina 5 de 12

El mtodo que utiliza Oracle para cargar los datos es el mismo que para el SQL Loader, pero lo mantiene a nivel de tabla, de tal manera que es la tabla la que lee directamente los datos. Es un sistema que resulta ms sencillo de usar que el SQL Loader, ya que no es necesario invocar al sistema operativo para cargar los datos, y permite hacer todas las operaciones directamente desde el SQL. La sintxis bsica la podemos ver con este ejemplo: SQL> CREATE TABLE emp_load 2 (employee_number CHAR(5), 3 employee_dob CHAR(20), 4 employee_last_name CHAR(20), 5 employee_first_name CHAR(15), 6 employee_middle_name CHAR(15), 7 employee_hire_date DATE) 8 ORGANIZATION EXTERNAL 9 (TYPE ORACLE_LOADER 10 DEFAULT DIRECTORY def_dir1 11 ACCESS PARAMETERS 12 (RECORDS DELIMITED BY NEWLINE 13 FIELDS (employee_number CHAR(2), 14 employee_dob CHAR(20), 15 employee_last_name CHAR(18), 16 employee_first_name CHAR(11), 17 employee_middle_name CHAR(11), 18 employee_hire_date CHAR(10) date_format DATE mask "mm/dd/yyyy" 19 ) 20 ) 21 LOCATION ('info.dat') 22 ); Table created. Donde podemos ver 3 partes claramente diferenciadas: Create table: definimos la tabla como cualquier otra tabla de base de datos. Organization external: aqu es donde definimos todos los datos, tal y como haramos en un fichero de control de SQL Loader, donde podramos incluir incluso el fichero de errores y el fichero de descartados (tal y como haramos desde el SQL Loader). Location: damos la localizacin del fichero de datos que vamos a cargar. Este sistema tiene la ventaja de que leer los datos directamente desde el fichero, sin cargarlos en base de datos. Con lo cual, cambiando el fichero (con el mismo nombre siempre, el especificado en Location) cambiarn los datos.

http://ora-flashes.blogspot.com.br/2012/09/optimizacion-creacion-de-indices-en_4.html

17/07/2013

Diseo BBDD --> BBDD DatawareHousing y Business Intelligence

Pgina 6 de 12

Para ms informacin, aqu os dejo la documentacin (http://docs.oracle.com/cd/B19306_01/server.102/b14215/et_concepts.htm [http://docs.oracle.com/cd/B19306_01/server.102/b14215/et_concepts.htm] ).

oficial

de

Oracle.

Existe otro sistema en oracle de carga de datos, que es el Data Dump, menos extendido y sobre el que podreis obtener informacin aqu. (http://www.oracle-base.com/articles/10g/oracle-data-pump-10g.php [http://www.oracle-base.com/articles/10g/oracle-data-pump-10g.php] )

SEGUNDO: TRATAMIENTO DE DATOS

Desde el punto de vista procedimental, no existe una manera fija de tratar los datos, ya que dependen de los datos que se reciban, y del diseo final de las tablas que hayamos decidido. Pero si podemos dar algunas pautas generales, a tener en cuenta. Cuando tengamos cargadas las tablas (mediante SQL Loader) o una vez creadas las tablas externas, lo ms habitual es hacer procesos de Data Cleaning, es decir, procesos en los que hagamos una "limpieza de datos" eliminando datos duplicados, y registros que no cumplan con la calidad de datos que tengamos definida. Este Data Cleanin generar dos tablas, una de Ok, donde estn todos los registros que hayan pasado el proceso, y una de ERR (de error) donde tendremos todos los registros que no cumplan los requisitos. Una vez limpiados los datos los procesaremos tal y como necesitemos teniendo en cuenta que al tratarse de sistemas con volmenes grandes de datos, tendremos especial cuidado con los tiempos. Por ese motivo debera restringirse el uso de cursores. En su lugar, siempre que sea posible, usaremos tablas temporales que sera recomendable crear y eliminar en tiempo de ejecucin. Esto es importante, ya que si mantenemos las tablas, cargaremos la base de datos con datos innecesarios, que podran llenar en poco tiempo el tablespace y generar un problema aadido. El uso de hints debera ser el mnimo imprescindible. Y deberamos abordar las consultas que utilicemos de la forma ms eficiente posible, haciendo un Explain Plan o un TKPROF (preferiblemente utilizar esta ltima herramienta. Ver post - http://ora-flashes.blogspot.com.es/2012/09/optimizacion-creacion-de-indicesen_4.html [http://ora-flashes.blogspot.com.es/2012/09/optimizacion-creacion-de-indices-en_4.html] ). A la hora de optimizar consultas tendremos en cuenta: OPTIMIZACIN DE CONSULTAS Para la optimizacin de consultas, hay que tener en cuenta la manera en la que Oracle interpreta las ordenes, y realiza las consultas. Oracle tiene dos formas de interpretar las consultas para acceder a la informacin: acceso por costes, y acceso por reglas. Acceso por costes: Una de las formas que tiene Oracle de acceder a la informacin y la que, adems, usa por defecto, es el acceso por costes, o lo que es lo mismo, por estadsticas. Este acceso est basado en

http://ora-flashes.blogspot.com.br/2012/09/optimizacion-creacion-de-indices-en_4.html

17/07/2013

Diseo BBDD --> BBDD DatawareHousing y Business Intelligence

Pgina 7 de 12

que Oracle va a sus estadsticas (resultantes de ejecutar el comando Analyze) y decide cual es la mejor forma de acceder a la informacin: a travs de clave primaria, a travs de ndices, a travs de RowId etc.. Acceso por reglas: La otra forma que tiene oracle de acceder a la informacin es interpretando literalmente lo que la consulta dice, si acceder a ningn tipo de estadstica. Como ya hemos comentado, Oracle, por defecto, accede a la informacin por costes. Para que acceda a la informacin por reglas, hay que indicrselo mediante un Hint, o tambin accedera a la informacin por reglas en el caso de que no existan estadsticas. La mejor manera de acceder a la informacin es, habitualmente por costes. Esto nos vendr bien a la hora de utilizar los Hints (que veremos ms adelante), o a la hora de crear los ndices de una tabla. Otros aspectos a tener en cuenta en cualquier consulta SQL: Siempre va a tardar menos la SELECT si se especifican en esta los campos a los que se debe acceder. El uso del * supone un mayor gasto de recursos, ya que debe de ser Oracle quien busque cuales son los campos y mostrarlos en pantalla. En la sentencia FROM, hay que tener en cuenta que Oracle va a acceder a las tablas en la direccin desde el FROM hacia el exterior. De esta manera, es conveniente, siempre, poner la tabla ms grande, al lado del FROM, y la ms pequea, lo ms alejada de dicha sentencia. Es importante intentar evitar el uso de subselects dentro de las sentencias FROM, ya que estas tienden a crear neested loops, que sern unos de los grandes enemigos de la optimizacin. Es preferible tener ms tablas en la sentencia FROM, y hacer un WHERE mucho ms complejo. En la sentencia WHERE, hay que tener en cuenta varias cosas: Hay que intentar siempre acceder a la informacin a travs de la primary key o, en su defecto, de alguno de los ndices creados en la tabla. Si no existe ningn tipo de ndice ni llave( primary key, Foreign Key), y si es posible, acceder a la informacin a travs del ROWID. Este mtodo de acceso a la informacin en Oracle es, siempre, el ms rpido. Hay que evitar las subquerys en la sentencia WHERE crean neested loops, que harn que la aplicacin vaya muchsimo ms lenta de lo debido. En caso de usarse una subquery, utilizar la sentencia exists o not exists en vez de in o not in. Esta sentencia esta muchsimo ms optimizada a nivel interno de Oracle, y hace menos accesos a la tabla. La clusula Order By, es mejor evitarla, ya que el ordenamiento de la tabla consume mucho tiempo (principalmente, debido a que una vez obtenido el resultado de la consulta, ha de ordenarlo). Las cusulas Group By y Having, se usan en casos muy especficos, y es difcil evitar su uso. An as, es recomendable evitarlas. OPTIMIZACIN DE PL/SQL

http://ora-flashes.blogspot.com.br/2012/09/optimizacion-creacion-de-indices-en_4.html

17/07/2013

Diseo BBDD --> BBDD DatawareHousing y Business Intelligence

Pgina 8 de 12

La optimizacin del cdigo en pl/sql, sigue las mismas reglas que la de cualquier otro lenguaje de programacin. Intentar evitar el exceso de variables, o el uso de bucles es importante para que el cdigo no se vuelva lento. Pero, a parte hay que tener en cuenta otros factores: El primer factor a tener en cuenta es el tiempo de acceso a disco, que se incrementa cada vez que se accede a base de datos. Una forma de evitar estos accesos, es evitar el uso de cursores, siempre que sea posible, y sustituirlo por selects simples. Esto sera posible utilizando la sentencia BULK COLLECT INTO, en vez de INTO, que introduce los registros resultantes de la consulta, en cualquier array de datos que sea del mismo tipo que la, o las, columna seleccionada. Esta sentencia accede menos veces a base de datos, y el uso de un array, a nivel de memoria, resulta mucho ms ligero para la aplicacin. Otro factor a tener en cuenta a la hora de optimizar es el uso de tipos (types). Al ser una nueva implementacin de Oracle, est mucho ms optimizada. A lo dems permite caractersticas de programacin orientada a objetos (de hecho es un sistema de programacin orientada a objetos completo dentro de Oracle), con todos los beneficios que ello conlleva, a traves del uso de los procedimientos miembros. De esta manera, Oracle, puede trabajar a nivel de memoria, sin crear nuevas reservas de esta (con variables declaradas como in u out en un procedure, etc), y de una manera muchsimo ms optimizada. Otra caracterstica interesante de los tipos, es que sobre los tipos de tabla (type nombre_tipo is table of tipo_dato) declarados a nivel de base de datos (con un create or replace) se pueden aplicar sentencias SQL igual que si de tablas de base de datos se trataran, haciendo ms sencillas las consultas, y haciendo que ciertas operaciones, como ordenaciones, sean mucho ms rpidas. La consulta quedara de la siguiente manera: Select * Bulk collect into variable_array From table(variable_tipo_tabla) Where condicin Para utilizar esta caracterstica, es recomendable basar el tipo tabla, en otro tipo anterior, que sea del mismo tipo que la consulta que vamos a extraer, es decir, que contenga los mismos campos y del mismo tipo. Si no se hace as podra dar problemas a la hora de trabajar con los campos de dicha tabla. En Oracle 9i puede ocurrir que as diga que la variable de tipo tabla declarada no sea de tipo tabla. En ese caso, con hacer un cast valdra (para reconvertirla al tipo en el que se ha declarado inicialmente. Evidentemente, se trata de un bug). Quedara la consulta, de la siguiente manera:

Select * Bulk collect into variable_array From table(cast(variable_tipo_tabla as tipo_tabla)) Where condicin

http://ora-flashes.blogspot.com.br/2012/09/optimizacion-creacion-de-indices-en_4.html

17/07/2013

Diseo BBDD --> BBDD DatawareHousing y Business Intelligence

Pgina 9 de 12

Aunque no pertenecen realmente al mbito del cdigo en PL/SQL, merece que se haga mencin a las vistas en este apartado. Estas lo que hacen es ejecutar la consulta que las define cada vez que se accede a ellas (es un poco como tener las consultas guardadas), por lo cual es preferible el uso de tablas temporales o, en su defecto, de vistas materializadas. Estas ltimas son vistas que generan tabla fsica y que, por tanto, se comportan como estas. Para que esta tabla fsica tenga los datos actualizados hay que utilizar el procedimiento dmbs_refresh.refresh(vista_materializada) con cierta periodicidad (al menos la misma con la que se actualizan las tablas de las que tira). HINTS Los HINTS, son pistas que se le dan al optimizador SQL de Oracle para que elabore un plan de ejecucin de una sentencia DML (sentencias de manipulacin de datos como select, insert, update, delete, etc). Los HINTS se incorporan a una sentencia DML en forma de comentario y deben ir justo detrs del comando principal. Por ejemplo, si se tratara de una sentencia SELECT el formato sera el siguiente: SELECT /*+ COMANDO-HINT */ En caso de que el HINT est mal escrito, Oracle no transmitir ningn error. Simplemente lo ignorar, y har la consulta en su modo por defecto. Estos son algunos de los HINTS ms interesantes:

/*+ CHOOSE */ : Este hint obliga a Oracle a hacer la consulta por costes (tal y como comentamos en el apartado de optimizacin de consultas). /*+ RULES */ : Este hint obliga a Oracle a hacer la consulta por reglas. /*+ FULL(nombre_tabla)*/ : Este hint obliga a Oracle a ejecutar un full table scan en la tabla especificada. /*+ INDEX(nombre_tabla indice) */: Este hint obliga a Oracle a realizar la consulta siguiendo el ndice indicado. /*+NO_INDEX(nombre_tabla indice) */: Este hint deshabilita el ndice indicado. Para saber ms sobre los hints de oracle, consultar: http://www.psoug.org/reference/hints.html [http://www.psoug.org/reference/hints.html] .

TECERO: MODELOS MULTIDIMENSIONALES

Como ya hemos comentado, las bases de datos para DatawareHouse y Business Inteligence, tienen unos modelos propios, lejos del modelo relacional, en los cuales lo que prima son los tiempos de ejecucin. Bsicamente se usan dos modelos: en estrella y en copo de nieve, no muy diferentes entre si. De hecho podramos considerar el copo de nieve como una variante de la estrella. Modelo en estrella:

http://ora-flashes.blogspot.com.br/2012/09/optimizacion-creacion-de-indices-en_4.html

17/07/2013

Diseo BBDD --> BBDD DatawareHousing y Business Intelligence

Pgina 10 de 12

En este modelo tendremos una tabla de hechos (o tambin denominada de grano), que tendr los datos detallados que queramos analizar, y a partir de la cual estableceremos las dimensiones, que son las perspectivas o entidades respecto a las cuales una organizacin quiere mantener sus datos organizados. Un ejemplo sera:

[http://4.bp.blogspot.com/-sA_tCTuMdJ0/UFBRKkLQ08I/AAAAAAAAC9w/8rRDAQ57AE/s1600/esquema_en_estrella.jpg]

Modelo en copo de nieve: Este modelo se diferencia del modelo en estrella en que aadimos dimensiones a las propias dimensiones. Digamos que es un modelo con modelos de estrella anidados. Un ejemplo:

http://ora-flashes.blogspot.com.br/2012/09/optimizacion-creacion-de-indices-en_4.html

17/07/2013

Diseo BBDD --> BBDD DatawareHousing y Business Intelligence

Pgina 11 de 12

[http://2.bp.blogspot.com/-461ZwRqbpo/UFBRIYELCDI/AAAAAAAAC9o/Jb3hX30Wn8M/s1600/esquema_en_copo_de_nieve.jpg]

Existe el concepto de "Constelaciones de Hechos", en los cuales los esquemas en estrella y copo de nieve pueden generalizarse con la inclusin de distintas tablas de hechos que comparten todas o algunas de las dimensiones.

CONCLUSIN
Con lo visto en el post de hoy ya podramos comenzar a disear nuestro propio sistema de Business Inteligence. Hay que tener en cuenta que suelen ser sistemas complejos y que hay que tratar con especial cuidado dada su importancia. Hay que cuidar la calidad de los datos, y validar que la informacin es correcta, proceses como proceses el sistema. Las decisiones ms importantes de la empresa estarn en tus manos.

Publicado 12th September 2012 por Jose Enrique Carrera Portillo Etiquetas: Dataware House, SQL Loader, Business Inteligence, Bases de datos Multidimensionales, Modelo Multidimensional, Optimizacin, External Tables, Modelo en copo de nieve, Modelo en estrella
0

Add a comment

http://ora-flashes.blogspot.com.br/2012/09/optimizacion-creacion-de-indices-en_4.html

17/07/2013

Diseo BBDD --> BBDD DatawareHousing y Business Intelligence

Pgina 12 de 12

Comentar como: Seleccionar perfil...

Publicar

Vista previa

http://ora-flashes.blogspot.com.br/2012/09/optimizacion-creacion-de-indices-en_4.html

17/07/2013