www.monografias.

com

Data Warehouse, Modelo, Conceptos e Implementacin orientada a SQL Server

Erith Eduardo Prez Gallardo - [email protected] 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Resumen Introduccin Data Warehouse, Conceptos Fundamentales El Modelo de Hechos Dimensionales (DFM-Dimention Fact Model) Diagrama en Estrella Obtencin y Transformacin de los Datos Tcnicas de desarrollo del soporte de Hardware Datos distribuidos Consultas distribuidas Salva y restaura de datos Conclusiones Bibliografa

Resumen Este trabajo intenta dar una idea bastante acertada sobre el trabajo con sistemas Data Warehouse, presentando la teora fundamental que sustenta este tipo de representacin y procesamiento de los datos en la actualidad: El Modelo Dimensional (DFM: Dimention Fact Model). Adems brinda ejemplos prcticos de cmo llevar a cabo tareas primordiales de un Data Warehouse, como son: La extraccin de los datos desde otros sistemas o formatos. Mostrando as las facilidades que brinda la herramienta de transformacin de datos de Microsoft SQL Server 2000 (DTS: Data Transformation Service). En otros apartados posteriores trata de resumir el tema de la programacin distribuida, las diferentes tcnicas de distribucin de los datos orientado principalmente a Microsoft SQL Server 2000, las diferentes estrategias para mejorar el hardware de un Data Warehouse y finalmente se aborda el tema de la salva de los datos, mostrando como ejemplo un script de salva incremental. Introduccin Data Warehouse no es un trmino nuevo si no una vieja rutina con un nombre nuevo. El almacenamiento de datos histricos y anlisis de estos para tomar decisiones futuras ya era practicado por los aztecas y mallas en su increble calendario solar. Incluso los egipcios atesoraban registros de las primaveras con amplios desbordamientos del Nilo, que les permita saber si el ao sera de una buena cosecha o no. El estudio de datos relacionados con la gestin empresarial, empez cuando todava la computacin no llegaba a dar respuesta a estos problemas. Los directivos estudiaban enormes informes elaborados por comerciales y econmicos compuestos de varias pginas de datos escrupulosamente resumidos. El avance de la computacin ha hecho el trabajo un poco ms fcil. El uso de aplicaciones OLTP (Online Transaction Proccesing) ha trado consigo la recopilacin muy rpida de datos que antes era casi imposible obtener, aunque haciendo uso en muchos casos de mltiples sistemas que usan SGBDR(Sistemas Gestores de Bases de Datos Relacionales) diferentes e incompatibles. Esto hace difcil el correlacionar los datos obtenidos desde estos diversos sistemas teniendo que volver al anlisis impreso. As esta nueva teora viene a resolver un problema viejo usando una nueva tcnica: OLAP (Online Analitical Proccesing) Procesamiento Anltico En Lnea. Existen diversas variantes sobre esta teora, que definen el futuro desarrollo de este tipo de aplicaciones, pero una de las ms aceptadas hasta ahora es el Modelo de Hechos Dimensionales (DFM: Dimention Fact Model), que veremos a continuacin para dar comienzo a nuestro estudio. Data Warehouse, Conceptos Fundamentales Para empezar vamos a enunciar una serie de conceptos bsicos que nos permitirn entender toda la teora que seguir en los restantes apartados de este documento: Data Warehouse: Es la integracin de datos consolidados, almacenados en un dispositivo de memoria no voltil, proveniente de mltiples y posiblemente diferentes fuentes de datos. Con el propsito del anlisis y a partir de este tomar decisiones en funcin de mejorar la gestin del negocio. Contiene un conjunto de cubos de datos que permiten a travs de tcnicas de OLAP consolidar, ver y resumir los datos acorde a diferentes dimensiones de estos. (Chaudhuri & Dayal, 1997) Data Marts: Es un subconjunto del Data Warehouse, usado normalmente para el anlisis parcial de los datos. Ej: El Data Mart de los datos del departamento ventas y el Data Mart de Inventarios. El

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

objetivo de subdividir est dado por la complejidad computacional del anlisis global de todas las dimensiones del Data Warehouse y por la necesidad de rapidez. (Microsft Data Warehouse Training, 2000) Data Mining: Es el descubrimiento de conocimiento oculto en las bases de datos. Relaciones entre estos y tendencias que permiten una toma de decisiones acertada. Incluye Asociacin, Caracterizacin, Clasificacin, Anlisis de Series Cronolgicas, etc. (Chaudhuri & Dayal, 1997). OLTP (Online Transaction Proccesing): Se les llama as a las aplicaciones orientadas principalmente a la insercin, actualizacin y eliminacin de datos, diseada casi siempre usando el modelo Relacional. Estos sistemas estn optimizados para realizar estas operaciones en un tiempo corto. (Microsoft Books Online, 2000) OLAP (Online Analitical Proccesing): Son los sistemas que se usan para analizar los datos que las OLTP introducen en la Base de Datos. A diferencia de los primeros estos casi siempre usan el modelo multidimensional para organizar los datos en la Base de Datos ya que brindan mejores resultados a la hora del anlisis de estos. (Microsoft Books Online, 2000)

El Modelo de Hechos Dimensionales (DFM) El anlisis de los datos en un tiempo finito, ha trado consigo estudios sobre la mejor forma de almacenar y representar estos datos para que puedan ser consultados de una forma ms rpida. El uso del Modelo Multidimensional es una de las aproximaciones ms acertadas y seguidas por los especialistas en estos das. Este se basa en el estudio de los eventos del negocio analizados desde sus distintas dimensiones. As: Definicin 1: Llamamos evento o Hecho a una operacin que se realiza en el negocio en un tiempo determinado. Son objeto de anlisis para la toma de decisiones. Se Representan en una caja con su nombre y las medidas que lo caracterizan. (Robert Wrembel & Christian Concilia, 2007) Ej: Figura 1: Representacin grfica de un Hecho y sus dimensiones

Los Hechos estn estrechamente relacionados con el tiempo. Los eventos que son estticos no tiene objetivo de anlisis para este modelo, aunque son muy pocos los hechos que no ocurren con determinada periodicidad en un negocio. Los hechos estn caracterizados por medidas numricas como se muestra en el ejemplo de la figura 1: la cantidad, el precio unitario, el descuento, etc, son las medidas del Hecho (VENTA). Nota: Fjese que el producto que se vende, su costo y la fecha de la venta no son caractersticas de esta como lo podran ser en cualquier diseo relacional. En este caso, esos seran dimensiones de ese Hecho, por las que, puede ser analizado ms adelante.

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

Definicin 2: Una Medida es una propiedad de un Hecho (casi siempre numrica), que es usada para su anlisis. (Robert Wrembel & Christian Concilia, 2007) Nota: Un hecho puede no poseer ninguna medida. En ese caso se dice que el Hecho es vaco y solo se usa para contar la aparicin de este en el tiempo. Definicin3: Una Dimensin es una caracterstica de un hecho que permite su anlisis posterior, en el proceso de toma de decisiones. (Robert Wrembel & Christian Concilia, 2007) Nota: Un hecho debe estar relacionado al menos con una dimensin: El tiempo. Es un inters del negocio tomar decisiones sobre los hechos que ocurren en este, pero para esto se necesita su anlisis. Por ejemplo Las ventas en la semana antes del 14 de Febrero, puede ser un objeto de anlisis para un negocio comercial. Para esto se necesita tener el Hecho Ventas analizado en la dimensin Tiempo. En este caso en los Das: 7 <= d <= 14. Si se quisiera saber que productos fueron los ms vendidos en esos das entonces tendramos que adicionar una nueva dimensin de anlisis, Producto. As adicionando dimensiones a nuestro estudio se pudieran llegar a conclusiones sobre si el siguiente ao en esa poca debera comprarse ms objetos de un producto o menos de otro. Elemento este muy importante para la futura estrategia de la empresa. Definicin 4: En una empresa pueden existir varios hechos que sean analizados por dimensiones iguales. En este caso se les llama a estas dimensiones: Dimensiones Compartidas. (Robert Wrembel & Christian Concilia, 2007). Un ejemplo de esto es El Hecho Ventas puede ser analizado en las dimensiones Tiempo y Producto. Lo mismo ocurre con el Hecho Compras. Las dimensiones deben ser atmicas y las relaciones entre estas crean jerarquas que permiten un anlisis jerrquico de los datos. Un ejemplo de esto es el Tiempo, que es dividido en tres dimensiones. Da, Mes y Ao. Cada uno es una dimensin distinta, pero relacionadas jerrquicamente en una relacin de 1 a muchos, que permite el anlisis del Hecho, por das, meses o aos, o la combinacin de ellos. Esto da al traste con las acostumbradas (OLTP) que manejan el Tiempo como una propiedad de una entidad, y lo tratan como un todo. Por lo que, como podemos inferir de aqu: en muchos casos har falta convertir las bases de datos de estos sistemas a la nueva filosofa. SQL Server tiene facilidades para esto llamadas DTS (Data Transformation Services) que permite leer datos desde cualquier SGBDR que posea un driver ODBC o implemente la nueva tecnologa OLE DB de Microsoft. Diagrama en Estrella Uno de los tipos de consultas ms usadas en las OLAP es la llamada Estrella. Su nombre lo adquiere debido a que su implementacin en un ambiente relacional (MOLAP Multidimentional Online Analitical Processing) est dado por varias tablas que almacenan las jerarquas dimensionales y una tabla que contiene el hecho con una relacin 1:m con estas tablas de dimensiones. Veamos un ejemplo grfico: Figura 2: Diagrama en estrella del Hecho, Ventas. (Microsoft Data Warehouse Training Kit, 2000)

Como podemos ver en la figura las tablas de dimensiones estn ligadas a la tabla Hecho, por relaciones. La integridad referencial es llevada a cabo por la creacin de llaves forneas en la tabla Hecho, que a su ves forman parte de la llave principal de la esta tabla. Es importante destacar que las jerarquas completas son

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

guardadas en una sola tabla dimensin. Este es el formato no normalizado, existe otro formato que intenta normalizar estas tablas dimensin. Ejemplo (Time_Dim). Cada tabla dimensin tiene su propia llave que es mantenida por el sistema Data Warehouse. A estas llaves se les llama Surrogate Key. Las llaves Surrogate Jerrquicas, no son ms que una codificacin de cada elemento de la jerarqua almacenado en la tabla dimensin. Veamos la figura 3 de cmo se logran estas llaves. Figura 3: Formacin de una llave Surrogate Jerrquica (Robert Wrembel & Christian Concilia, 2007)

Vamos a ver ahora como sera una consulta sobre este tipo de diagrama en estrella: Figura 3: Plantilla de consulta para una consulta en estrella (ad hoc star query) (Robert Wrembel & Christian Concilia, 2007)

Nota: En la figura las D1, D2, .. , Dk significan tablas de dimensin y los LP1, LP2, ,LPk son los predicados usados para simplificar la consulta. El ejemplo siguiente muestra mejor como sera esta consulta: (Robert Wrembel & Christian Concilia, 2007)

En este tipo de procesamiento el mayor de los problemas es el super join que se crea al procesar las tablas de dimensiones con los datos de la tabla Hecho, para esto se han hecho varios estudios sobre la mejor forma de hacer este tipo de consultas de forma que sean lo ms ptimas posibles, una de las tcnicas mejores probadas es la de reescribir la consulta como lo muestra el siguiente ejemplo que mostramos: Ejemplo: Optimizar la consulta en el Data Warehouse (Robert Wrembel & Christian Concilia, 2007)

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

Para cerrar con broche dorado este tema es necesario hacer alusin a los llamados Cubos de datos: Estos no son ms que el conjunto formado por todas las tablas Dimensin y la tabla Hecho que al final dan una vista en forma de Cubo cuyas celdas estn compuestas por las medidas de la tabla Hecho. Esta es la base de las aplicaciones OLAP. El cubo de datos es lo que hace que los reportes sean obtenidos con un bajo tiempo de respuesta y que el anlisis de los datos pueda ser tan diverso, pues cada cara del cubo se refiere a un anlisis distinto de las medidas almacenadas. Veamos el ejemplo grfico del cubo: Figura 4: Cubo de datos (Microsoft Books Online, 2000)

Como podemos ver en el ejemplo la cantidad de produccin puede ser analizada por producto, teniendo en cuenta la dimensin Producto, Por Tiempo, por Localizacin de las Industrias o en su conjunto por todas ellas a la vez o cualquier combinacin de estas. Esto le da al analista o al sistema experto una amplia gama de posibilidades de las cuales puede tomar ventaja. En nuestro caso de estudio de las ventas. El cubo de datos formado por la Tabla Sales_Fac en conjunto con las restantes tablas de Dimensin nos permite analizar las ventas por Empleado, por Consumidor, por Tiempo, Etc. Extraccin y Transformacin de los Datos SQL puede conectarse a cualquiera de los formatos creados por Microsoft Office, archivos texto y a bases de datos como FOXPRO y ACCESS muy usadas por mltiples sistemas de escritorio que resuelven problemas importantes en muchas empresas. Adems puede conectarse a cualquier SGBD (Sistema

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

Gestor de Bases de Datos) que posea un driver ODBC compatible con Microsoft o implemente la tecnologa OLE DB. El poder obtener datos de pginas de Excel con datos resumidos o exportarlas a este, para que los usuarios ms avanzados puedan crear grficos y otros. Es algo que convierte a SQL en la herramienta perfecta para crear sistemas Data Warehouse. Para realizar estas tareas Microsoft cuenta con una rama dentro del rbol de administracin del SQL Enterprise Manager, que contiene un rea de diseo con los elementos que se necesitan para disear un paquete de transformacin de datos (DTS Package). Para crear un paquete solo se hace clic derecho sobre el rea vaca de esa rama y se selecciona la opcin New Package, inmediatamente se abre una ventana con un rea de diseo que permite empezar a disear el paquete en cuestin. Hay tres elementos fundamentales a la hora de disear un paquete: 1. Las conexiones: que permiten conectarse a cualquier fuente de datos como las que relacionamos anteriormente. 2. Las tareas: que permiten transformar los datos de cada conexin antes de que sean copiados a otra conexin. Estas tareas pueden ejecutar Scripts de ActiveX, pueden transferir otros archivos desde o hacia un sitio FTP, pueden enviar un mensaje a un operador de SQL. Adems de poder filtrar datos, crear nuevas tablas en la BD resultante, etc. 3. Los flujos de trabajo: que permiten definir hacia donde irn los datos luego de que se le apliquen las respectivas acciones que los transformarn a la nueva forma deseada. As usando estos tres elementos fundamentales se crea una especie de script grfico que sigue una secuencia lgica para dar como resultado la transformacin de los datos almacenados de un formato a otro como SQL Server desde donde podrn ser analizados con el Data Warehouse. Aunque desde el Enterprise Manager de SQL Server se puede ejecutar los paquetes que se crean haciendo clic derecho sobre ellos y seleccionando Execute o en un Schedule. Existen varias herramientas adicionales que pueden usarse desde la ventana de comandos del sistema operativo. De ellas, la ms interesante para el uso de scripts es dtsrun. Para obtener la ayuda completa de esta podemos ejecutar dtsrun /? En una pc (Computadora Personal) con SQL Server instalado. Ejemplo: Uso de la herramienta dtsrun desde un script de windows @echo off Copy \\srvaplics\aplics\*.mdb d:\convertsql /Y if (%ERRORLEVEL% NEQ 0) echo Error al copiar la base de datos else dtsrun /S SASSQL /U sa /P Pepe2006 /N loadaccessdb Como podemos ver a dtsrun se le pasan como parmetros el nombre del servidor el usuario con derechos para ejecutar el paquete, el password de este y el nombre del paquete a ejecutar. Existen otra serie de opciones que pueden ser consultadas en la ayuda de la herramienta. El uso de esta herramienta puede estar relacionado como vemos en el ejemplo con la copia de bases de datos hacia lugares desde donde es ms seguro la obtencin de sus datos. A continuacin mostraremos un ejemplo prctico de cmo disear un paquete para obtener el balance de comprobacin desde un fichero TXT exportado por el sistema contable SENTAI. Ejemplo: Obtencin de Balance de SENTAI 1. Creacin de un nuevo paquete desde el SQL Enterprise Manager 2. Arrastrar hacia el rea de diseo la conexin hacia un archivo TXT 3. Configurar la conexin especificando el archivo y su formato 4. Arrastrar hacia el rea de diseo una conexin al servidor SQL al que se va a importar el estado de las cuentas. 5. Configura esta conexin especificando la base de datos a usar 6. Hacer clic sobre la conexin al archivo texto para seleccionarlo. 7. Hacer clic sobre la accin (trasform data task) y seguido se hace clic sobre la conexin al Server SQL del rea de diseo. 8. Hacemos clic derecho sobre la lnea que une a ambos ahora y editamos las propiedades de la transformacin para asegurarnos de que estn de acuerdo a nuestros objetivos. 9. Presionamos el botn de salvar para guardar el paquete. 10. Escriba el nombre del paquete y cierre la ventana de diseo. Ahora podr ver el nombre del paquete y si desea ejecutarlo solo debe hacer clic derecho sobre este y seleccionar Execute. As las cuentas y sus saldos sern insertados en la nueva base de datos de contabilidad de la empresa. Ejemplo: Vista grfica del paquete creado

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

Tcnicas de desarrollo del soporte de Hardware Antes de definir una estrategia en la cual se desarrollar el hardware que soporta el Data Warehouse, es necesario hacer un estudio del tiempo, que pueden estar detenidas las aplicaciones que usan este. En nuestros das muchas empresas necesitan que estos sistemas ejecuten 24 horas los 365 das del ao, por lo que no hay mucho margen de error. La desconexin de estas aplicaciones por solo una hora puede hacer que la compaa pierda miles de usuarios que nunca ms visitarn el sitio Web pensando que est fuera de servicio o porque se buscaron otro proveedor al no poder contactar con el acostumbrado, para que esto no ocurra antes de echar a andar un sistema de tanta importancia hay que prever con tiempo el desarrollo futuro de su soporte. Una de las tcnicas clsicas para desarrollar hardware siempre ha sido aumentar memoria, capacidad de procesamiento y capacidad de almacenamiento, al servidor que soporta el sistema. Esta tcnica es comnmente llamada Scalling Up. En este tipo de desarrollo si usted necesita subir su capacidad de procesamiento (Adicionar otro Procesador o cambiar el existente por uno ms rpido) en servidores como: Acer Altos 600, 1200, 500; o HP Proliant ML350 y ML370; tiene que apagar el sistema para hacerlo, al igual que si desea aumentar la cantidad de memoria. Tenga en cuenta que muchos de estos servidores pueden durar aos en fallar y por tanto otra de las situaciones muy comunes es que a la hora de repararlos o que se necesita aumentar sus capacidades tcnicas es muy difcil encontrar piezas compatibles en el mercado por el continuo desarrollo de los sistemas de hardware, por esto es muy necesario comprar piezas con vista a estas situaciones a tiempo, cosa esta muy difcil de lograr estando el sistema funcionando correctamente. Muchos de los directivos de estas grandes empresas no ven con muy buenos ojos la compra de piezas para un sistema que todava no suea con fallar o que resuelve los problemas en la actualidad con una buena calidad de respuesta computacional. El obtener un presupuesto para esto es una gran responsabilidad del Administrador de Sistemas, gestin que el futuro cuando ocurran los problemas obtendr su merecido reconocimiento por parte de la directiva de la empresa. En el caso de la capacidad de almacenamiento, si tenemos un arreglo (RAID) de discos SCSI no hace falta apagar el sistema. Estos se pueden conectar en caliente sin necesidad de formatear siquiera, el hardware RAID se encarga del resto. A pesar de que los discos SCSI siguen siendo muy fiables y rpidos. En estos das alternativas muy buenas pueden hacer que un Administrador de Sistemas tome otra decisin. Existe en el mercado tarjetas RAID de discos Serial ATA, que permiten hacer arreglos de discos Serial ATA con gran facilidad. Estos discos son menos fiables que los SCSI, pero tiene un menor precio y su relacin precio/capacidad disminuye cada ao. Por solo mostrar un ejemplo: Un disco de 72 GB SCSI, la empresa Tecun lo comercializa en Cuba con un costo de: $370.00, mientas que un Serial ATA de 80 GB pude costar $75.00. Si decimos que el disco solo durar un ao de explotacin lo que es muy raro en ambientes climatizados y con sistemas elctricos protegidos por bateras. Al ao siguiente se podr comprar un disco Serial ATA por el mismo precio, pero de 160 GB. El doble de la capacidad del anterior. Si sumamos los costos de los dos discos en los dos aos, no llegar a ser igual al costo del SCSI, que por supuesto durar funcionando sin problemas otros 4 aos. Sin

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

embargo habrs aumentado tu capacidad de almacenamiento al doble cosa esta que es un dato importante en ambientes que aumentan su coleccin de datos exponencialmente, como es el caso de un Data Warehouse. Es importante destacar que aunque hablo de un solo disco estoy asumiendo que al menos existe otro que est configurado como espejo que pude ser usado en caso de que falle el principal. No es concebible un sistema tan importante que no tenga este tipo de respaldo. Aunque los discos sean SCSI, debe haber respaldo, lo que incrementa los costos. En caso de que no se posea hardware RAID se pueden usar las facilidades del Sistema Operativo Windows 2k3 que permite crear arreglos desde el administrador de discos. Este tipo de arreglos a pesar de ser menos rpido que el manejado va hardware. Es una solucin muy buena en esos casos. Ejemplo de crear una particin espejo para el sistema: 1- Abra el administrador de discos luego de haber instalado fsicamente los dos discos. 2- Haga clic derecho sobre el cuadro que dice disco 0 y haga clic en convertir a disco dinmico. 3- Le aparece una ventana que le indica marcar los discos que desea convertir. Marque los dos discos el 0 y el 1 y haga clic en aceptar. 4- El sistema le preguntara si desea continuar con la operacin a pesar que el disco 0 tiene el sistema operativo. Acepte y el sistema le avisar que se va areiniciar para completar la operacin. Acepte y espere a que el sistema se reinice. 5- Abra el administrador de discos y ya con los discos siendo dinmicos haga clic derecho sobre la particin del sistema y presione sobre la opcin adicionar espejo. 6- En la ventana que aparece seleccione el disco 1 para usar como espejo y acepte. 7- El sistema crear una particin idntica en el segundo disco y empezar a duplicar la informacin existente en la primaria. Nota: Para que un disco pueda ser espejo total del primero deben ser de capacidades idnticas. No puede haber diferencias. Este error puede ocurrir al usar discos de varias marcar como Ejemplo: Maxtor y Segate en el mismo sistema. A pesar de que los servidores profesionales son muy fiables, en empresas medianas y pequeas usarlos, puede implicar un gasto demasiado elevado. Una alternativa puede ser usar una PC Moderna con una memoria bastante grande 4 GB pudriera ser suficiente. Actualmente los procesadores Pentium D que poseen procesamiento en paralelo y una velocidad de ms de 3 GHz que lo hacen muy competentes. Esto trae consigo otra caracterstica importante y es que este tipo de configuracin puede hacer uso de otra tcnica de desarrollo llamada Scalling Out. As, si en el futuro hace falta mejorar la capacidad de este servidor porque el negocio se ha desarrollado y ahora se procesa una mayor cantidad de datos, se puede comprar otro servidor o varios iguales o mejores en dependencia de la disponibilidad del mercado y del presupuesto permitiendo, conectarlos en forma de Cluster distribuyendo as la carga de trabajo. Windows 2k3 permite la configuracin de este tipo de soporte con gran facilidad, dando la posibilidad de ir aumentado en cantidad de servidores y mejorando en prestaciones, capacidad de procesamiento y tolerancia a fallos. En mi opinin personal en estos das este tipo de configuraciones son mucho ms fiables y econmicas. El uso de varios servidores en forma de cluster puede hacer uso de una caracterstica de SQL Server 2000 que permite la actualizacin de los datos de todos estos servidores segn las necesidades del negocio. La replicacin de SQL Server 2000 no solo se puede aplicar sobre servidores configurados como cluster tambin puede usarse para replicar una de las bases de datos o un subconjunto del Data Warehouse a un servidor de una entidad de la empresa. Estaramos hablando de un posible Data Mart. En nuestro ejemplo clsico de empresa comercial estaramos hablando de replicar el Data Mart de las ventas de Ciego, al servidor de la Sucursal Ciego de vila. All se podran sacar reportes muy provechosos por parte de los comerciales sin necesidad de congestionar la Red WAN con los datos de estos reportes. Teniendo en cuenta que los enlaces WAN entre provincias son bastante costosos y lentos en comparacin con los 100 Mbps de la Red LAN. Datos distribuidos La distribucin de los Datos a travs de varios servidores es toda una teora de la que nosotros solo vamos a mencionar sus ms relevantes rasgos, haciendo nfasis en la replicacin de SQL Server. Para comenzar debemos decir que existen dos tcnicas fundamentales apara usar datos distribuidos. 1- Transacciones Distribuidas 2- Replicacin La primera necesita que todos los servidores involucrados estn funcionando correctamente y en red (online). Este tipo de transacciones mantiene actualizadas todas las bases de datos involucradas en todo momento. Todos los servidores tienen que estar sincronizados y si falla un solo elemento de la transaccin

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

falla completa. Teniendo que revertir el proceso en todos los servidores con su correspondiente consumo de procesamiento. La segunda por su parte puede mantener un margen de tiempo que permite a los servidores no tener que estar sincronizados en todo momento. As como podemos ver el uso de una u otra tcnica est dado principalmente por dos factores: Latencia entre servidores y Autonoma de cada servidor. Este ltimo tiene que ver por ejemplo: Si el Data Mart ubicado en Ciego es actualizado a partir de la informacin recolectada del sistema de inventario de todos los centros comerciales de esta provincia. Entonces este Servidor posee una autonoma. Estos datos no tienen por qu ser replicados al servidor de la Provincia Santiago de Cuba o Matanzas. En este caso esa informacin solo sera necesaria en El servidor central de la Empresa donde se encuentra el Data Warehouse central. As mismo estos pueden ser replicados en el horario nocturno evitando que los enlaces de comunicacin WAN se congestionen por el da que hay un mayor trfico de correo, Messenger, sistemas contables y otros. Es decir en nuestro ejemplo la replicacin sera la va ms ptima de implementacin para poder mantener los datos distribuidos con autonoma a travs de todas las sucursales del pas. Estas dos tcnicas de trabajo poseen una serie de variantes para su implementacin que mostramos en forma de grfico: Figura 5: Formas de implementacin de datos distribuidos (Microsoft Training, 2000)

SQL Server 2000 tiene tres formas bsicas para implementar la distribucin de datos: 1- Snapshot Replication 2- Transactional Replication 3- Merge Replication SanapShot Replication: Replica todos los datos en la publicacin hacia el o los subscriptores. En el tiempo especificado en el Agente. Este tipo de mtodo es muy usado en ambientes con una gran autonoma y donde se necesitan los datos publicados con una latencia no muy baja. Transactional Replication: En este tipo de replicacin solo se replican los cambios incrementales. Este tipo de replicacin es usada en ambientes donde la latencia de actualizacin debe ser baja, puede ser muy til adems en ambientes conectados por enlaces de poco ancho de banda pues el tamao de los datos replicados es muy bajo. El agente que permite realizar este trabajo tiene adems la opcin de replicar los datos inmediatamente. Merge Replication: En este tipo de replicacin se analizan los artculos publicados y se crea uno solo con la informacin resultante de la comparacin de estos en cada servidor. Al final cada servidor se actualiza con el artculo resultante. En este tipo de replicacin pueden ocurrir colisiones si se usan las mismas bases de datos con un nivel de autonoma alto. Estas colisiones pueden ser resultas programando reglas en la publicacin. SQL Server usa una filosofa llamada Publicador-Distribuidor-Subscriptor. Anlogamente a la vida real el Publicador crea una a varias publicaciones, que no son ms que objetos de una base datos como: Tablas, Vistas, Procedimientos almacenados; o Porciones de estos como una proyeccin de una tabla determinada o una seleccin de una o varias tablas relacionadas y a partir de esa publicacin es que un subscriptor puede suscribirse para recibir las actualizaciones de esta publicacin que le llega a travs del distribuidor. Tenga en cuenta que el distribuidor puede estar en el propio servidor que publica o puede estar en otro diferente para eliminar carga al publicador y buscar un balance en el procesamiento. Atendiendo a esta filosofa existen tres tipos bsicos de implementacin fsica de los servidores: 1- Publicador Central y Muchos Suscriptores 2- Muchos Publicadores y un solo suscriptor 3- Muchos Publicadores y muchos suscriptores

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

En nuestro caso particular necesitaramos publicadores en todas las sucursales del pas y un subscriptor central en la Habana, con una replicacin transaccional (Tansactional Replication) que se ejecutara en el horario de la noche. Es importante destacar que bases de datos de otros sistemas como Lotus Notes. Implementan este sistema de bases de datos distribuidas con replicacin con muy buena calidad, prestaciones y poco uso de ancho de banda en los enlaces WAN lo que las hace muy competitivas en el mundo empresarial. Consultas distribuidas Existen dos formas fundamentales de hacer una consulta distribuida usando SQL Server. La primera consiste en la funcin OPENROWSET u OPENDATASOURCE, que permite ejecutar una consulta sobre cualquier SGBDR que soporte OLE DB o tenga un driver ODBC compatible con Microsoft. Este tipo de procesamiento es llamado en la literatura como: ad hoc query. La otra va es usando servidores enlazados (linked servers) que soporten tambin la tecnologa OLE DB de Microsoft. Esta ltima es usada para hacer consultas frecuentes a diferencia de la primera que se usa para consultas con perodos de tiempo largos. (Microsoft Training, 2000) Sintaxis de OPENROWSET: OPENROWSET('provider_name' {'data -source'; 'user_id' ; 'password' | 'provider_string'}, {[catalog.][schema.]object | 'query'}) Descripcin de Parmetros: Provider_name: Nombre del proveedor OLEDB. Ejemplo MSDASQL(Para ODBC) Data-source: Fuente de donde se obtendrn los datos. Como veremos ms adelante no es ms que el nombre del servidor que contiene la BD. User_id: nombre de usuario de acceso a la BD Passord: Contrasea de acceso a la BD Provider_string: En caso de ser necesaria una cadena de coneccin a la fuente de datos. Catalog: No es ms que el nombre de la base de datos. Schema: Nombre del usuario dueo de los objetos de la BD. Ejemplo en SQL dbo. Object: Tabla, procediemiento, funcin, u otro objeto de la base de datos. Query: Consulta en cuestin. Para poder entender mejor la sintaxis vamos a ver un ejemplo de cmo podemos hacer una consulta sobre un servidor SQL, otro sobre como hacerlo sobre una base de datos Access y uno sobre como integrar una consulta de este tipo en una normal. (Microsoft Training, 2000) Ejemplo 1: Encuesta a un Servidor SQL SELECT a.* FROM OPENROWSET('SQLOLEDB', 'LONDON1'; 'newcustomer';'mypassword', 'SELECT ProductID, UnitPrice FROM Northwind.dbo.Products ORDER BY UnitPrice') AS a Ejemplo 2: Encuesta a un servidor Aceess SELECT a.* FROM OPENROWSET('Microsoft.Jet.OLEDB.4.0' 'C:\MSOffice\Access\Samples\Northwind.mdb'; 'newcustomer'; 'mypassword', Orders) AS a Ejemplo 3: USE Northwind SELECT cust.* ord.* FROM Customers as cust JOIN OPENROWSET('Microsoft.Jet.OLEDB.4.0' 'C:\MSOffice\Access\Samples\Northwind.mdb''; 'newcustomer'; 'mypassword',

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

Orders) AS ord On cust.customerid = ord.customerid Como vemos este tipo de consultas puede ayudarnos mucho a la hora de extraer datos desde los sistemas que nutren al Data Warehouse. Aunque ya hemos visto que SQL tiene servicios (DTS) y otras herramientas grficas que pueden extraer datos y transformarlos muy fcilmente. Esta variante nos permite controlar el trabajo usando sentencias de programacin que fcilmente pueden ser combinadas con otras para obtener resultados muy profesionales. Otra de las ventajas que nos ofrece esta filosofa de trabajo es que no tenemos que importar los datos a SQL para analizarlos. Hay ocasiones en que no queremos importar esa base de datos porque solo se consulta una sola vez al ao o por otras cuestiones diferentes y de esta forma podemos consultarla sin mucho esfuerzo. Existen varios tipos de proveedores de OLE DB que pueden ser consultados en la ayuda de SQL. Aqu queremos mostrar solo los ejemplos ms usados: (Microsoft Training, 2000) 1. SQL Server: N'SQLOLEDB' 2. Microsoft OLE DB Provider for Access (Jet): 'Microsoft.Jet.OLEDB.4.0' 3. Microsoft OLE DB Provider for Oracle: 'MSDAORA' data_source is the SQL*Net alias name for the Oracle database to be added as a linked server 4. OLE DB Provider for ODBC (Using data_source parameter): provider_name is 'MSDASQL' data_source is 'LocalServer' 5. OLE DB Provider for ODBC (Using provider_string parameter): provider_name is 'MSDASQL' provider_string is 'DRIVER={SQL Server} SERVER=servername UID=login;PWD=password;' Nota: Para hacer consultas distribuidas es necesario que estn activadas las siguientes opciones. ANSI_NULLS y ANSI_WARNIGS. En clientes como Query Analyzer ya estn activadas por defecto, pero en otros como osql no. Por otra parte el uso de servidores en lazados permite que las consultas sean ejecutadas con el previo conocimiento de los servidores disponibles para hacer esta. Este tipo de consultas es usada cuando su periodo de ejecucin es relativamente bajo. En el caso nuestro de estudio podramos estar hablando de una consulta hecha para obtener datos de las ventas de los Data Mart de cada servidor SQL de cada sucursal. As el servidor central de la empresa podra estar enlazado con los restantes servidores y desde este se podran crear este tipo de consultas o transacciones distribuidas como veremos ms adelante. Para enlazar un servidor con otro se usa el procedimiento almacenado sp_addlinkedserver. Vamos a ver su uso con algunos ejemplos: Ejemplo 4: Uso de sp_addlinkedserver (Microsoft Training, 2000) -- USando SQL Server EXEC sp_addlinkedserver @server = 'AccountingServer', @svrproduct = 'SQL Server' -- Usando Oracle EXEC sp_addlinkedserver @server = 'OracleFinance', @svrproduct = 'Oracle', @provider = 'MSDAORA', @datasrc = 'OracleDB' Sintaxis de ejecucin del procedimiento: (Microsoft Training, 2000) sp_addlinkedserver [ @server = ] 'server' [ , [ @srvproduct = ] 'product_name' ] [ , [ @provider = ] 'provider_name' ] [ , [ @datasrc = ] 'data_source' ] [ , [ @location = ] 'location' ] [ , [ @provstr = ] 'provider_string' ] [ , [ @catalog = ] 'catalog' ]

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

@server Name of the linked server to create @svrproduct Product name of the OLE DB data source @provider The unique, friendly name for the OLE DB provider corresponding to this data source @datasrc Name of the data source as interpreted by the OLE DB provider @location Location of the database as interpreted by the OLE DB provider @server Name of the linked server to create @svrproduct Product name of the OLE DB data source @provider The unique, friendly name for the OLE DB provider corresponding to this data source @datasrc Name of the data source as interpreted by the OLE DB provider @location Location of the database as interpreted by the OLE DB provider En el caso de servidores como SQL Server que necesitan de un usuario y una contrasea para poder conectarse a ellos es necesario que ocurra una de las dos condiciones: 1. El usuario con que se ejecuta la consulta est definido en los dos servidores y tenga derechos para ejecutar las tareas deseadas. 2. Se ejecute previamente un mapeo de usuarios usando el procediemiento: sp_addlinkedsrvlogin. Sintaxis del procedimiento sp_addlinkedsrvlogin: (Microsoft Training, 2000) sp_addlinkedsrvlogin [ @rmtsrvname = ] 'rmtsrvname' [ , [ @useself = ] 'useself' ] [ , [ @locallogin = ] 'locallogin' ] [ , [ @rmtuser = ] 'rmtuser' ] [ , [ @rmtpassword = ] 'rmtpassword' @rmtsrvname Name of a linked server to which the login mapping applies. @useself Determines whether SQL Server login accounts use their own credentials or the values of the @rmtuser and @rmtpassword arguments to connect to the server specified by the @rmtsrvname argument. A value of TRUE for @useself is invalid for a Windows Authenticated login account. @locallogin An optional login account on the local server. If used, @locallogin must already exist on the local server. If this value is null, then all login accounts on the local SQL Server will be mapped to the account on the remote server specified by @rmtuser. @rmtuser The optional user name for connection to @rmtsrvname when @useself is FALSE. @rmtpassword The optional password associated with @rmtuser. Ejemplo 5: Uso de mapeo de usarios: (Microsoft Training, 2000) EXEC sp_addlinkedsrvlogin @rmtsrvname = 'AccountingServer', @useself = 'false', @locallogin = 'Accountwriter', @rmtuser = 'rmtAccountWriter', @rmtpassword = 'financepass' EXEC sp_addlinkedsrvlogin @rmtsrvname = 'AccountingServer', @useself = 'false', @rmtuser= 'allcustomers' Como podemos ver aqu el procedimiento enlaza el usuario que ejecuta la consulta localmente con el que tiene los derechos para hacer el trabajo en el servidor remoto. As cuando se ejecute la consulta, el servidor usar el usuario adecuado para ejecutar la parte que corresponde al servidor remoto con credenciales diferentes. En nuestro caso de estudio, el servidor de la Sucursal Ciego no tiene que tener la misma contrasea para el usuario sa que los restantes servidores de las dems sucursales, para que nuestro Data Warehouse funcione. As en el servidor central puede existir un mapeo para cada servidor de cada sucursal.

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

Esto aumenta la seguridad, pues si un hacker se hace de una de las contraseas de algunos de los servidores de las sucursales no podr acceder a las restantes ni al servidor central. Incluso sin pensar en hacker. En el caso de que algn administrador quiera consultar los datos de una sucursal diferente a la que administra esto le sera imposible debido a esta tcnica, lo que dara la posibilidad de que solo los usuarios de la directiva de la empresa tuvieran acceso a reportes que incluyan varios territorios. Hasta aqu ya sabemos como enlazar los servidores, pero no sabemos como hacer la consulta sobre estos. La nica cosa que diferencia una consulta distribuida sobre servidores enlazados, de una consulta sobre un solo servidor es que la primera tiene que usar nombrado de cuatro partes completo. El nombrado de cuatro partes completo incluye adems de los elementos que ya estamos acostumbrados a usar como: Catalogo.Squema.Objeto, el nombre del servidor que se va a encuestar. As, si el Server de Ciego se llama sassql el nombre de cuatro partes completo de la tabla de ventas sera: sassql.datamartventas.dbo.ventasfact. Ahora mostraremos un ejemplo de cmo se aplica esto en la consulta. Ejemplo 6: Consulta sobre servidores enlazados (Microsoft Training, 2000) SELECT CompanyName, Phone INTO PhoneList FROM AccountingServer.NorthwindRemote.dbo.Suppliers SELECT CompanyName FROM AccountingServer.NorthwindRemote.dbo.Suppliers SELECT ProductName, CompanyName FROM Products p JOIN AccountingServer.NorthwindRemote.dbo.Suppliers ON p.supplierid = s.supplierid Existen algunas restricciones a la hora de hacer consultas sobre servidores distribuidos. Estas son: 1. No se pueden usar sentencias create, alter, drop. 2. No sepuede usar goup by cuando las tablas contienen objetos largos como TEXT, NTEXT, etc. 3. No se pueden usar las sentencias: readtext, writetext, updatetext Otra de las cosas ms importantes que posee esta tcnica es que normalmente las consultas son ejecutadas en el servidor local, pero el cdigo puede ser modificado para que se hagan en el servidor remoto. Esto puede mejorar en gran medida el rendimiento del servidor, pues la carga de procesamiento se hace en el otro extremo. Imagine que necesita una consulta sobre las ventas de todas las sucursales. Esta puede ser una consulta que consuma mucho tiempo, dado la cantidad de datos a procesar. Si se divide el trabajo entre los servidores de cada sucursal el tiempo de respuesta puede mejorar en gran medida, para usar esta tcnica se hace uso de la sentencia openquery, que veremos con un ejemplo: (Microsoft Training, 2000) Sintaxis: OPENQUERY (linked_server, 'query') Ejemplo 7: Uso de la sentencia OPENQUERY SELECT * FROM OPENQUERY (AsiaServer, 'SELECT ProductID, Royalty FROM Northwind.dbo.ProductInfo') Como podemos ver solo debemos especificar el servidor que va a ejecutar la consulta y luego la consulta en cuestin. As ese servidor la ejecutar y retornar los resultados: Existen dos elementos ms de alta importancia a la hora de trabajar con servidores enlazados. El primero de ellos es la ejecucin de procedimientos almacenados en servidores remotos. Para esto se usa la misma forma de nombrado de cuatro partes ejemplo: sassql.datamartventas.dbo.sp_listarVetas. El otro elemento importante es el uso de transacciones distribuidas. Esta caracterstica de miscrosoft nos permite hacer tareas que necesitan ejecutarse como un todo en servidores distribuidos como una nica transaccin. Para usar esta caracterstica se usa la sentencia BEGIN DITRIBUTED TRANSACTION <NAME>, vamos a ver esto con un ejemplo: Ejemplo 8: Uso de transacciones distribuidas

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

SET XACT_ABORT ON BEGIN DISTRIBUTED TRANSACTION EXEC Savingsdb.dbo.withdraw 1234, 100 EXEC Centralserver.Checkingdb.dbo.deposit 1234, 100 COMMIT TRAN Nota: Recuerde que un rollback de la transaccin puede llevar este proceso a cabo en todos los servidores involucrados disminuyendo mucho el rendimiento de los mismos. Adems si no est la primera sentencia del ejemplo no se hace un rollback completo. Por lo que siempre es recomendado activar esa opcin (XACT_ABORT) para en ltima instancia hacer un rollback completo y que la BD no quede inconsistente. Salva y restaura de datos Una de las cosas ms importantes cuando usted ya posee un Data Warehouse es mantenerlo y para esto salvar sus bases de datos es algo fundamental. Para ilustrarlos con un ejemplo les puedo decir que el Data Warehouse que administro generaba todos los das 87 GB de salvas. Salvar este volumen de datos se hace engorroso computacionalmente y tambin a la hora guardar estos datos en un lugar con espacio disponible. Si por ejemplo usa DLT que pueden almacenar hasta 80 GB en cinta el proceso de salvar un casete de este tipo diario puede ocupar gran parte del procesamiento del servidor en horario nocturno y requiere de 365 casetes para todo el ao lo que es un gasto considerable. Si por el contrario decide usar DVD cuya implementacin es ms barata, necesitara nada ms que la suma aproximada de 23 DVD diarios para hacer la salva de estos datos, sin mencionar que necesitara una persona solo para cambiar los CD cuando se llenen. Todo esto sin tener en cuenta que alguno de estos pueda tener defectos de fbrica. La posibilidad de usar compactadores hace posible que este gasto disminuya en una gran medida pues usando la mxima compresin de compactadores como WINRAR el tamao se reduce aproximadamente a solo 3 GB lo que hara posible salvar todo esta informacin en solo un DVD, pero el uso de esta compresin hace que el procesamiento de un servidor profesional (Hacer Altos 600 de dos procesadores 900 MHz, 750 MB de RAM y arreglo de discos SCSI) se agote al punto de demorar ms de 14 horas para compactar toda esa informacin. Disminuyendo as el procesamiento en horario laboral, lo que hace este proceso inviable. Sin embargo si usamos una compresin menor en este compactador podemos lograr una razn cantidad datos/ costo computacional muy buena. Por ejemplo usando un modo de compresin menor podemos lograr un tamao de solo 5 GB en un tiempo de solo 2 horas lo que comparado con los 3 GB en 14 horas es realmente un gran avance. Otra de las tcnicas ms usadas y necesarias en nuestro caso para salvar servidores Data Warehouse es la salva incremental, que puede generar el servidor SQL Server. Esta salva incremental necesita ante todo que ya se tenga una salva completa de la BD, pero en las restantes salvas se hace solo salva de los datos que han sido modificados o adicionados, lo que disminuye en gran medida este volumen de salva. Por su parte la restaura de los datos salvados con una salva incremental es mucho ms rpida y fiable que restaurar una salva completa de la BD. Esta sin duda es la mejor de las opciones cuando se habla de Data Warehouse, ya que los datos de un sistema as no cambian con tanta frecuencia como los de las aplicaciones OLTP, por lo que el volumen de la salva incremental es muy pequeo y por otra parte las adiciones de datos se hace en muchos casos con una diferencia de tiempo bastante grande. Nota: Recuerde siempre que los datos salvados deben ser llevados a un dispositivo externo y guardados fuera del local de servidores con una seguridad fsica buena, pues si son obtenidos por otras personas estas podrn saber muchos datos de la empresa. A continuacin vamos a ver un ejemplo de cmo usar el WINRAR en un script para salvar los datos de un servidor Data Warehouse. Ejemplo 9: Salva de datos de un servidor Data Warehouse. rem Script para las salvas diarias de los servidores @echo off echo "salva del dia:" >> F:\Tareas\Backup\log.txt date /T >> F:\Tareas\Backup\log.txt time /T >> F:\Tareas\Backup\log.txt del /f /q E:\Shared\Backup\bk*.rar FOR /F "usebackq tokens=2,3,4 delims=/ " %%i IN (`date /t`) DO @SET datebackup=%%k%%i%%j FOR /F "usebackq tokens=1,2 delims=: " %%i IN (`time /t`) DO @SET timebackup=%%i%%j FOR /F "usebackq tokens=1 delims= " %%i IN (`date /t`) DO @SET dayname=%%i SET DAYTIME=%datebackup%%timebackup%00

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

if EXIST daytimelastbackup.txt goto NoFirstTime rem primera vez que se salvan los datos rem Salvar SQL dir E:\SqlData\MSSQL\BACKUP\*.bak /B /L /S /A:-D dir E:\SqlData\MSSQL\BACKUP\*.trn /B /L /S /A:-D

> F:\Tareas\Backup\filelistaplics2.lst >> F:\Tareas\Backup\filelistaplics2.lst

"C:\Program Files\WinRAR\rar.exe" a E:\Shared\Backup\bkaplics1.rar @F:\Tareas\Backup\filelistaplics1.lst "C:\Program Files\WinRAR\rar.exe" a -m1 E:\Shared\Backup\bkaplics2.rar @F:\Tareas\Backup\filelistaplics2.lst rem recopilar toda la salva bajo un solo nombre "C:\Program Files\WinRAR\rar.exe" a E:\Shared\Backup\bk*.rar goto eof :NoFirstTime rem ################################ Empieza la salva incremental for /F "tokens=1" %%i in (daytimelastbackup.TXT) do @SET LastBackup=%%i rem Salvar SQL dir E:\SqlData\MSSQL\BACKUP\*.bak /B /L /S /A:-D dir E:\SqlData\MSSQL\BACKUP\*.trn /B /L /S /A:-D "C:\Program Files\WinRAR\rar.exe" @F:\Tareas\Backup\filelistaplics1.lst "C:\Program Files\WinRAR\rar.exe" a @F:\Tareas\Backup\filelistaplics2.lst a > F:\Tareas\Backup\filelistaplics2.lst >> F:\Tareas\Backup\filelistaplics2.lst -ta%LastBackup% -m1 E:\Shared\Backup\bkaplics1.rar E:\Shared\Backup\bkaplics2.rar

-m0

E:\Shared\Backup\sas9%datebackup%.rar

-ta%LastBackup%

rem recopilar toda la salva bajo un solo nombre "C:\Program Files\WinRAR\rar.exe" a E:\Shared\Backup\bk*.rar :eof rem Fin del Script de Salva echo %DAYTIME% > daytimelastbackup.TXT net use x: \\sas2\salvasdia /user:xxxx "xxxxxxx"

-m0

E:\Shared\Backup\sas9%datebackup%.rar

if %ERRORLEVEL% EQU 0 (copy /Y E:\Shared\Backup\sas9*.rar x:\%dayname%\) else (echo "Error al Conectarse al servidor" >> F:\Tareas\Backup\log.txt) if %ERRORLEVEL% EQU 0 (del /F /Q E:\Shared\Backup\sas9*.rar) else (echo "Error al copiar el archivo al servidor" >> F:\Tareas\Backup\log.txt) if %ERRORLEVEL% EQU 0 (echo "Salva Exitosa" >> F:\Tareas\Backup\log.txt) net use x: /d del /f /Q E:\Shared\Backup\bk*.rar time /T >> F:\Tareas\Backup\log.txt Conclusiones 1. El uso de sistemas Data Warehouse es una poderosa estrategia para administrar empresas. 2. Los resultados que arrojan los anlisis de los datos obtenidos y consolidados en el Data Warehouse pueden hacer que la directiva de la empresa corrija las estrataegias hasta ahora trazadas y mejore as las ganancias. 3. El mantenimiento de un Sistema Data Warehouse es algo complejo, que requiere de recursos monetarios y estrategia.

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com

www.monografias.com

4. El modelo dimensional brinda una forma muy sencilla de representacin de los datos y mejora as el tiempo de consultas a la base de datos. 5. Los sistemas de transformacin de datos de SQL Server brindan una poderosa herramienta a quienes se inicien en la confeccin de un Data Warehouse sobre este gestor de Bases de datos. Bibliografa 1. Robert Wrembel & Christian Concilia, DATA WAREHOUSES AND OLAP Concepts, Architectures and Solutions, 2007. 2. Microsoft, Microsoft SQL Server 7.0 Data Warehousing Training Kit, Microsoft Press, 2000. 3. Microsoft, Microsoft Training and Certification, Course 2073A, Programing a Microsoft SQL Server 2000 Database, Microsoft Press, 2000. 4. Microsoft, Microsoft Training and Certification, Course 2072A, Administering a Microsoft SQL Server 2000 Database, Microsoft Press, 2000. 5. Microsoft, SQL Server 2000 Books Online, Microsoft Press, 2000

Autor Erith Eduardo Prez Gallardo Administrador Red Sucursal Cimex Ciego de vila Ing. Informtica y Aspirante Master en Informtica Aplicada [email protected]

Para ver trabajos similares o recibir informacin semanal sobre nuevas publicaciones, visite www.monografias.com