Migración a Analysis Services 2005
Artículo técnico sobre SQL Server
Este artículo se aplica a: SQL Server 2005
Resumen: en este artículo se describe el proceso de migración a Analysis Services en SQL Server 2005. El modelo dimensional unificado (UDM) ofrece nuevas oportunidades de diseño para los desarrolladores de cubos. El modelo UDM ha combinado el ámbito de los informes relacionales y OLAP con el fin de proporcionar un foro unificado para ambos entornos de solicitud de datos. Comprender las nuevas opciones de diseño y el modo en que éstas repercuten en la organización optimizará el proceso de migración. El asistente para migración es una herramienta que permite el traslado rápido y eficaz de la estructura de cubos existente a Analysis Services 2005. En este artículo se ofrece información general sobre dicho asistente y se proporcionan varias sugerencias que le ayudarán a determinar si debe o no utilizarlo. En determinadas ocasiones, la mejor opción consiste en volver a diseñar la estructura de cubos desde cero con el fin de garantizar el uso adecuado de las nuevas características de Analysis Services 2005.
En esta página
 | El proyecto REAL |
| Introducción |
| Problemas relativos al diseño de cubos que repercuten en la migración |
| Herramientas de migración |
| Migración en el proyecto REAL |
| Migrar o volver a diseñar |
| Conclusión |
El proyecto REAL
El objetivo del proyecto REAL es descubrir las prácticas más adecuadas para la creación de aplicaciones de inteligencia empresarial basadas en Microsoft® SQL Server™ 2005 mediante implementaciones de referencia basadas en escenarios de clientes reales. De este modo, los datos de los clientes se analizan en la empresa para hacer frente a los mismos problemas que estos se encuentran durante la implementación. Estos problemas incluyen:
| • | El diseño de esquemas. |
| • | La implementación de los procesos de extracción, transformación y carga (ETL) de datos. |
| • | La determinación del tamaño de los sistemas para la producción. |
| • | La administración y el mantenimiento continuos de los sistemas. |
Al trabajar en escenarios de implementación reales, se logra una comprensión total del funcionamiento de las herramientas. Nuestro objetivo es intentar abordar toda la gama de inquietudes a las que hace frente una gran empresa durante su propia implementación en el mundo real. En este artículo se describe la función que desempeña la migración en el proyecto REAL. Este proyecto utiliza datos de dos clientes de inteligencia empresarial de Microsoft. La fase 1 del proyecto se diseñó en un importante distribuidor de electrónica que conserva los datos de las ventas y del inventario en un almacenamiento de datos de Microsoft SQL Server 2000. Los Servicios de transformación de datos (DTS) de SQL Server 2000 se utilizan para administrar el flujo de datos entrante en la base de datos relacional, así como el flujo que sale de ésta hacia los cubos de Analysis Services de SQL Server 2000 para la creación de informes y consultas interactivas. Este cliente mantiene aproximadamente 200 GB de datos en su almacén relacional. Todos estos datos se procesan posteriormente en los cubos de Analysis Services. La implementación de la fase 1 se centra principalmente en las inquietudes que podría tener un cliente de SQL Server 2000 al migrar a SQL Server 2005. Nuestros resultados representan, en gran parte, la migración de la funcionalidad existente, con el uso de algunas nuevas funciones donde se considera necesario. En cuanto a la migración a Analysis Services, los datos de los cubos se desplazaron a Analysis Services 2005 a través, principalmente, del asistente para migración. Se agregaron características adicionales a los cubos una vez que estos se migraron a la nueva versión.
La fase 2 del proyecto REAL se basa en un conjunto mayor de datos de un cliente distinto y se trabaja más con las nuevas funciones de SQL Server 2005 que en la fase 1, debido a que la fase 2 es, principalmente, la implementación nueva de una solución SQL Server 2005. El objetivo de la fase 2 era mostrar gran parte de las nuevas características que ofrece Analysis Services. Se determinó que en la fase 2 era necesario volver a diseñar la estructura de cubos y no se utilizó el asistente para migración. Consulte más artículos sobre el proyecto REAL en el futuro.
Introducción
Analysis Services 2005 proporciona un enfoque nuevo para el uso de los sistemas OLAP y permite integrar totalmente los requisitos de dichos sistemas con los de los informes relacionales. El uso de Analysis Services 2005 permite reducir el esfuerzo invertido en la administración general de la estructura de cubos, al tiempo que mejora la experiencia del usuario final. El diseño a través del modelo dimensional unificado (UDM) crea un vínculo perfecto entre los ámbitos de los informes OLAP y relacionales. Se trata de un modelo que ha cambiado la estructura básica de los cubos.
Las nuevas características de Analysis Services 2005 permiten afrontar de forma más eficaz los modelos habituales de exploración, satisfacer con creces los requisitos de informes relacionales y OLAP, hacer uso de tipos exclusivos de datos y reducir los gastos de memoria relativos al uso de la analítica.
En este artículo técnico se proporcionan las directrices necesarias para llevar a cabo el proceso de migración y determinar la ruta de migración óptima para su organización. La migración se puede realizar a través de las herramientas integradas, o bien, volviendo a diseñar los cubos existentes. En este artículo se describen también los cambios de diseño de Analysis Services 2005 y el modo en que dichos cambios afectarán a la estructura de cubos actual.
En este documento se explican los pasos principales del asistente para migración y se formulan varias preguntas que le ayudarán a determinar si el uso del asistente es o no la mejor opción de la que dispone.
Este artículo le ayudará a determinar también si deberá o no utilizar el asistente para migración como punto de inicio, o si debería volver a diseñar la estructura de cubos desde cero.
Problemas relativos al diseño de cubos que repercuten en la migración
Los cubos de Analysis Services 2005 son muy diferentes a los de las versiones anteriores del producto. Al utilizar el asistente para migración, Analysis Services intenta duplicar los cubos existentes en el nuevo entorno. Aunque de este modo se pasa rápidamente a la nueva plataforma, no se permiten utilizar todas las nuevas características de diseño que ofrece Analysis Services 2005.
Analysis Services 2005 introduce el modelo dimensional unificado (UDM). La función del modelo UDM es unificar los ámbitos de los informes relacionales y OLAP. Tradicionalmente, los entornos OLAP destacan por su capacidad de proporcionar rutas de exploración para la búsqueda de datos. Los datos se almacenan en niveles. La creación de informes relacionales destaca por generar informes en los que se puede situar un campo determinado en cualquier punto del mismo.
Uno de los problemas con los informes OLAP se produce cuando a los usuarios les interesa utilizar campos, pero estos no se ajustan a las jerarquías definidas por el administrador de los cubos. Cuando estos campos clave no se ajustan a una jerarquía natural con los demás campos ¿cómo se incluyen en el análisis? Para tratar de resolver este problema, la organización puede, por ejemplo, adoptar dos enfoques diferentes: utilizar una herramienta OLAP y una herramienta relacional.
El modelo UDM soluciona este problema de analítica e integración de informes relacionales desde cero, ya que permite tratar todos los campos de interés como atributos de primera clase. El modelo UDM aporta un grado de flexibilidad no alcanzado hasta ahora. Este modelo está formado por varios componentes de alto nivel que permiten un diseño flexible. Estas características son las siguientes:
| • | Jerarquías de atributos y definidas por el usuario |
| • | Atributos relacionados |
| • | Vistas de orígenes de datos |
| • | Grupos de medidas |
| • | Perspectivas |
En las secciones siguientes se describe el modo en que cada una de estas características influye en el diseño de los cubos en Analysis Services 2005. De este modo, le resultará más sencillo determinar la ruta de migración más adecuada.
Jerarquías de atributos
Con Analysis Services 2005, podrá crear atributos a partir de cualquier campo que desee incluir en el análisis. Los atributos se podrán utilizar posteriormente en el análisis o en un informe relacional. Además, los atributos se pueden organizar en jerarquías para proporcionar una ruta de exploración. Desde el punto de vista de la exploración, las jerarquías de atributos y definidas por el usuario sustituyen a las dimensiones de Analysis Services 2000. Por tanto, será habitual que los cubos presenten un gran número de jerarquías de atributos. De hecho, los cubos complejos de gran tamaño podrían contener cientos de atributos. En Analysis Services 2000, solía ser una práctica recomendable utilizar un conjunto pequeño de dimensiones. Había dos razones para ello:
| • | Facilitar el uso efectivo de la memoria. Todas las dimensiones se guardaban de forma predeterminada en el almacén MOLAP y cada miembro se cargaba en la memoria. El uso de un número pequeño de dimensiones compartidas permitía un procesamiento rápido y tiempos de respuesta de consultas cortos. |
| • | Proporcionar contexto al usuario. Resulta difícil para el usuario conceptualizar más de seis u ocho dimensiones y mantener el contexto al tiempo que corta, divide y busca datos. El modelo UDM ha cambiado todo esto. Cada campo que se desea ver en el análisis se puede, en la mayoría de los casos, agregar al cubo como atributo. A continuación, se pueden tomar varios atributos y colocarlos en las jerarquías definidas por el usuario. Este tipo de jerarquías pueden ser tradicionales o seguras, en las que un elemento principal puede contener numerosos elementos secundarios. Se puede tratar también de jerarquías de exploración, en las que los atributos se pueden situar en diferentes rutas de exploración independientemente de la cardinalidad entre el elemento principal y el secundario. Este método de diseño conlleva las ventajas siguientes: |
| • | Cualquier campo se puede situar en cualquier parte del informe o vista de datos. Resulta muy sencillo tomar un solo campo y situarlo en columnas y filas independientes del resto de los campos de la jerarquía. |
| • | Los cubos pueden ser más representativos del almacenamiento o el almacén de datos. El cubo de Analysis Services 2005 puede contener numerosos atributos, jerarquías definidas por el usuario y medidas (de varias tablas de hechos). Esto permite que el cubo constituya una representación más cercana del origen de datos. |
| • | Los cubos pueden contener datos de varias tablas de dimensiones y tablas de hechos. La variedad de tipos de diseño con los que se puede encontrar es prácticamente ilimitada. |
| • | Las rutas de exploración se pueden definir para todos los tipos de datos. Ya no existen restricciones en cuanto al tipo de jerarquías que se pueden crear. |
| • | Las propiedades de los miembros y las dimensiones virtuales ya no son necesarias para la creación de informes. Los administradores de cubos de Analysis Services 2000 a menudo se veían obligados a agregar propiedades de miembro y después dimensiones virtuales para poder agregar columnas a los informes. Esto ya no es necesario, ya que los atributos son la base de la analítica y los informes y, en la mayoría de los casos, un atributo representa una sola columna. |
Atributos relacionados
En Analysis Services 2005, el concepto de propiedades de miembro se amplía aún más. Las propiedades de miembro tradicionales están ahora disponibles como relaciones de atributos. Al realizar consultas sobre propiedades de miembro, no sólo verá las propiedades de miembro tradicionales, sino todas las relaciones de atributos. El asistente para agregación utiliza las relaciones de atributos para determinar el punto en el que se pueden realizar agregaciones. Por tanto, será necesario disponer de relaciones entre atributos organizadas en niveles. Por ejemplo, una jerarquía de cliente habitual podría incluir los niveles País, Región, Provincia, Ciudad y Cliente. Para utilizar agregaciones, Ciudad tendría una relación de atributo con Provincia. El asistente para fórmulas también utiliza relaciones de atributos para determinar el mecanismo más adecuado para llevar a cabo un cálculo determinado.
Las propiedades de miembro se utilizan a menudo para facilitar la creación de informes en Analysis Services 2000. Para mostrar una columna que no formaba parte de la jerarquía, se podía hacer uso de una propiedad de miembro a fin de mostrar el valor de la columna. Esta propiedad se podía mostrar como miembro calculado, dimensión virtual o a través de una herramienta de terceros que lo expusiera de forma nativa. Con el modelo UDM, ya no es necesaria la creación de propiedades de miembro para crear informes, ya que todas las columnas de interés se pueden agregar fácilmente como atributos. Los atributos se pueden colocar posteriormente en columnas y filas para facilitar los requisitos de análisis.
Nota: Analysis Services 2005 utiliza relaciones de atributos para determinar los cálculos necesarios para los resúmenes en las jerarquías definidas por el usuario. Sin este tipo de relaciones en las jerarquías, no se crearán las agregaciones. En el caso de las jerarquías seguras, el nivel principal de un elemento secundario tendría la forma de una relación de atributos. El proceso de agregación en las jerarquías de atributos depende de esta relación. |
Vistas de orígenes de datos
Analysis Services 2005 agrega una capa de abstracción adicional entre el cubo y el origen de datos. La vista de origen de datos permite separar de forma lógica el cubo de sus orígenes de datos. Se pueden combinar uno o varios orígenes en una vista de origen de datos para proporcionar una representación lógica de los datos. La vista de origen de datos puede ser una selección de tablas de los orígenes de datos, o bien, una consulta con nombre. La consulta con nombre es una instrucción SQL que se escribe con el fin de poder cargar los datos del modo deseado (como una vista relacional, salvo que una consulta con nombre se almacena en la DSV). A continuación, el cubo se genera a partir de la vista de origen de datos.
Las vistas de orígenes de datos:
| • | Proporcionan una capa de abstracción de los orígenes de datos |
| • | Pueden incluir varios orígenes de datos, que podrían ser varias bases de datos en el mismo servidor o bases de datos de servidores diferentes. |
| • | Proporcionan consultas con nombre para que el usuario escriba la consulta que Analysis Services utiliza para cargar los datos. Esta característica se puede utilizar para filtrar, limitar u optimizar la carga de datos del origen. |
| • | Se pueden utilizar para cambiar el nombre de los datos con el fin de proporcionar una capa de asignación de nombres independiente del origen de datos real. |
| • | Permiten representar claves lógicas para definir la relación entre el hecho y las tablas de dimensiones. |
| • | Admiten cálculos con nombre. Cada cálculo con nombre almacena una expresión que se utiliza para generar la definición de columnas. |
| • | Proporcionan la base para la creación del cubo. |
Grupos de medidas
Uno de los principales aspectos de inquietud con respecto a los nuevos cubos debería ser el contexto en el que el usuario visualiza los datos. En primer lugar, es necesario tener en cuenta que es posible crear un cubo a partir de varias tablas de hechos. Cada una de estas tablas puede contener varias medidas y un nivel de granularidad diferente. Por tanto, el cubo no sólo tendrá cientos de atributos, sino que también dispondrá de medidas de diferentes tablas de hechos y distinta granularidad.
Imaginemos que disponemos de un cubo que contiene el grupo de medidas Ventas reales en el nivel Producto, Tienda, Cliente y Día (quién compró qué, dónde y cuándo). Asimismo, el cubo dispone de un grupo de medidas Previsión en el nivel Clase de producto, Tienda y Mes (qué se vende y dónde se venderá en los próximos meses). También presenta el grupo de medidas Inventario en el nivel Producto, Tienda y Semana (de cuánto disponemos en este momento, dónde y cuándo). Si combinamos estos tres grupos de medidas en el mismo cubo, dispondremos de información relativa a la tendencia de ventas. De este modo, por ejemplo, podremos responder a preguntas del tipo ¿el hecho de que se agotaran las existencias de ciertos productos influyó en el volumen de ventas?, ¿cómo afecta este hecho al modo de realizar previsiones? Esto es factible gracias a que todos los hechos se pueden combinar en el mismo cubo. En Analysis Services 2000, se debían crear dos cubos para posteriormente combinarlos en un cubo virtual. Por el contrario, en Analysis Services 2005, es posible disponer de un único cubo con varios grupos de medidas (uno para cada tabla de hechos).
Aunque este hecho aporta una mayor flexibilidad para el creador de los cubos, no siempre proporciona el contexto necesario para el usuario final. La mayor parte de los usuarios finales no están familiarizados con el diseño de almacenamientos o almacenes de datos. En ocasiones, se pueden crear grupos de medidas para separar medidas diferentes entre sí, lo que facilita la aportación de contexto para el usuario. Por otro lado, las medidas con niveles similares de granularidad se pueden agrupar y tratar (desde una perspectiva administrativa) como una sola unidad. De forma predeterminada, los grupos de medidas se organizan según la tabla de hechos de la que se recuperan. Todas las medidas de una sola tabla de hechos deberían tener un nivel de granularidad similar y pertenecerán al mismo grupo. Los grupos de medidas ofrecen las ventajas siguientes:
| • | Las medidas pueden proceder de varias tablas de hechos. |
| • | Las medidas se pueden agrupar por granularidad. |
| • | Se pueden incluir varios niveles de granularidad en un único cubo base. |
| • | Se puede aplicar seguridad a grupos de medidas específicos. |
| • | Los grupos de medidas se pueden exponer a través de una o varias perspectivas, agruparse con las dimensiones adecuadas para el usuario final y pueden ayudar a proporcionar contexto para éste. |
Perspectivas
En Analysis Services 2000, los cubos a menudo se definían con una cantidad menor de dimensiones y un número establecido de medidas de una sola tabla de hechos. Para agregar medidas con distintas granularidades o ver numerosas dimensiones de diferentes cubos, podía crear un cubo virtual en el que combinar varios cubos base, lo que daba la impresión de un tamaño considerablemente mayor. De este modo, se podía alcanzar el resultado final. No sólo permitía hacer frente a los problemas de granularidad, sino que también reducía el consumo de memoria en Analysis Services 2000.
El modelo UDM ha cambiado este escenario. Ahora el cubo puede contener cientos de jerarquías de atributos, jerarquías definidas por el usuario y varios grupos de medidas (de tablas de hechos diferentes). Gracias a esto, el diseño de cubos es ahora muy flexible. No obstante, permanece el problema del contexto del usuario. Llegado un punto determinado, es necesario reducir la vista de los datos para que ésta se adecue al usuario final. La vista de los datos debe permitir que el usuario satisfaga fácilmente los requisitos de su proyecto.
Lasperspectivas proporcionan contexto para el usuario final. Una perspectiva es un conjunto de atributos, jerarquías definidas por el usuario, acciones y grupos de medidas que se agrupan como una colección lógica. La perspectiva constituye la base de la analítica y proporciona contexto para el usuario. Será muy habitual disponer de un cubo de gran tamaño con cientos de atributos y numerosas medidas. A continuación, se crearán muchas perspectivas para que los usuarios interactúen con la colección de datos más adecuada para su tarea. Mientras que el modelo UDM se ha diseñado para los administradores de cubos, las perspectivas se han creado para el usuario final. Las perspectivas no se pueden utilizar para implementar seguridad.
Sugerencia: las perspectivas se exponen en herramientas de aplicaciones para usuario de modo similar al que se presentaban los cubos en Analysis Services 2000. Si los usuarios están habituados a consultar un conjunto de cubos al que se conectan y en el que exploran, se puede recrear este escenario mediante la implementación de perspectivas que incluyan las mismas dimensiones y medidas que se incluían en los cubos de Analysis Services 2000. Supongamos que disponemos de un cubo físico Ventas con distintas perspectivas en función de los diferentes usos empresariales de los datos, como Director de marca, Director de tienda o Director regional. Cada una de las perspectivas se expone en realidad al usuario final como un cubo (como lo hace el cubo base más complejo y de mayor tamaño), pero las dimensiones, los cálculos, los grupos de medidas y otras entidades se han adaptado específicamente para ese uso empresarial determinado. |
Resumen de los problemas de diseño
En Analysis Services 2005, los cubos pueden contener numerosos atributos, jerarquías definidas por el usuario y medidas. El modelo UDM combina las mejores características del ámbito OLAP con las mejores características del ámbito de los informes relacionales con el fin de proporcionar oportunidades ilimitadas para el diseño de cubos. El resultado final del diseño de cubos puede abarcar mucho más de lo que necesita el usuario. Los grupos de medidas y las perspectivas se pueden utilizar para proporcionar contexto al usuario. En la mayoría de los casos, la perspectiva será la base de la experiencia del usuario.
Herramientas de migración
Analysis Services 2005 ofrece una serie de herramientas que facilitan la realización del proceso de migración. Al instalar Analysis Services 2005 en un equipo con Analysis Services 2000 y elegir la instalación en la instancia predeterminada, se le solicitará que ejecute el asistente para migración. Si decide no utilizar el asistente durante la instalación, podrá hacerlo más adelante como herramienta independiente.
El asistente para migración permite migrar un cubo de Analysis Services 2000 a la nueva versión del programa o crear una secuencia de comandos XMLA (XML para Analysis) para realizar la migración posteriormente. Los asistentes son rápidos y efectivos. Deberá determinar si el resultado final se ajusta o no a sus necesidades. En algunos casos, el asistente para migración constituye un punto de inicio excelente, aunque en otros es mejor volver a diseñar la estructura de cubos. Incluso si pretende volver a diseñar su estructura, ejecutar el asistente para migración es una buena opción. Al menos resulta una experiencia útil y educativa observar cómo el asistente convierte los objetos. Puede que en última instancia decida hacer caso omiso de las recomendaciones del asistente y vuelva a diseñar el esquema a través de asistentes de diseño normales. Sin embargo, se recomienda observar cómo el asistente para migración realiza una actividad similar, aunque no se esté de acuerdo con sus decisiones finales.
Analysis Services 2005 incluye dos herramientas de migración integradas. La primera de ellas es la opción de migración que se proporciona durante la instalación de Analysis Services 2005.
La segunda es el asistente para migración iniciado como proceso independiente como una de las herramientas principales del grupo de programas de SQL Server 2005.
Asistente para migración
El asistente para migración lleva a cabo de la mejor forma posible la duplicación de los cubos de Analysis Services 2000. El objetivo del asistente no es proporcionar una práctica adecuada para el cubo de Analysis Services 2005. Teniendo esto en cuenta, resulta fácil comprender por qué el asistente realiza las selecciones que realiza. Tras completar el asistente, es preciso determinar los pasos adicionales necesarios para hacer un mejor uso de todas las características de Analysis Services 2005.
El asistente solicita que se seleccionen las bases de datos OLAP que se desean migrar. Tras seleccionar las bases de datos OLAP adecuadas, se debe determinar si se desea moverlas directamente a Analysis Services 2005 o si se prefiere generar una secuencia de comandos XMLA. La secuencia de comandos se puede ejecutar posteriormente en SQL Server Management Studio.
Para ejecutar el asistente para migración
1. | En el grupo de programas de SQL Server 2005, abra el asistente para migración. El asistente es una de las herramientas de Analysis Services. El asistente aparecerá como se muestra en la figura 1.  Figura 1: el asistente para migración de Analysis Services 2005 puede migrar los cubos de Analysis Services 2000 | |
2. | Haga clic en Next (Siguiente) para mostrar la sección de la página de origen y destino del asistente. | |
3. | Proporcione el origen y destino de los datos como se muestra en la figura 2. El origen de datos debería ser la instancia de Analysis Services 2000. El destino debería ser la nueva instancia de Analysis Services 2005. Puede seleccionar un archivo de secuencia de comandos en lugar de un destino. En este caso, el asistente generará una secuencia de comandos XMLA que se puede ejecutar posteriormente para generar los cubos.  Figura 2: se deben proporcionar el origen y el destino de los datos como base para la migración | |
4. | Tras proporcionar el origen y el destino, haga clic en Next (Siguiente). El asistente leerá los metadatos del origen de datos y, a continuación, mostrará la pantalla Select Databases to Migrate (Seleccionar las bases de datos para migrar). | |
5. | Seleccione las bases de datos que desea migrar. De forma predeterminada, se genera el nombre de la base de datos de destino. El asistente intenta crear una base de datos con el mismo nombre. Si ya existe una base de datos con este nombre, el asistente genera un nombre que agrega un valor incremental al final del mismo que comienza por 1. Para proporcionar un nombre, haga clic en la celda Destination Database (Base de datos de destino) y proporcione un nombre, como se muestra en la figura 3.  Figura 3: se puede cambiar el nombre de la base de datos de destino por el que se desea utilizar en Analysis Services 2005 | |
6. | Tras proporcionar los nombres de las bases de datos que desea migrar y las bases de datos de destino, haga clic en Next (Siguiente). | |
7. | Comienza la fase de validación de objetos del asistente. Esta fase tarda cierto tiempo (en función de la cantidad de metadatos de los orígenes de datos). A medida que los objetos se validan, el asistente muestra mensajes de advertencia y error cuando se encuentra con datos que pueden suponer un problema. Puede ver los detalles de los cambios realizados por el asistente en los datos. Por ejemplo, si se cambia el nombre de una dimensión, recibirá un mensaje de advertencia que informa de dicho cambio. Más adelante en este artículo se describirán algunos de los posibles problemas que se pueden encontrar al utilizar el asistente para migración. Las características de registro de vista y registro de almacenamiento se pueden utilizar para ver y filtrar los detalles, y guardarlos a continuación en un archivo para su posterior revisión. Una vez revisados los detalles del objeto, haga clic en Next (Siguiente). | |
8. | Aparecerá la pantalla de migración de base de datos, que indica que el asistente está realizando la migración y que se están generando los metadatos. Sin embargo, los datos no se transfieren. Para que se puedan rellenar con datos, los nuevos cubos se deben procesar. | |
9. | Tras migrar las bases de datos, haga clic en Next (Siguiente) para completar el asistente.
|
El asistente no migra los elementos siguientes:
| • | Particiones remotas |
| • | Cubos vinculados |
| • | Opciones de obtención de detalles |
El asistente realiza varias selecciones durante la migración con el fin de asignar las características antiguas a las nuevas. En necesario tener en cuenta los elementos siguientes:
| • | Las propiedades de miembro se migran a relaciones de atributos. Observará que el término relación de atributos se utiliza principalmente en Business Intelligence Development Studio. Si consulta en la API las propiedades de miembro, ésta devolverá todas las relaciones de atributos. Además del conjunto de propiedades de miembro originales, cada nivel de la jerarquía incluirá una relación de atributos adicional para el nivel principal. El motor de agregación utiliza la relación de atributos para proporcionar la relación entre los puntos de datos. Estas relaciones son necesarias para los cálculos de resúmenes. No se recomienda eliminar estos atributos relacionados. Si se han agregado otras propiedades de miembro para satisfacer requisitos de informe específicos, los atributos de informe relacionados se pueden eliminar, ya que las columnas se deberían definir también como dimensiones de atributo. |
| • | Se pueden crear varios cálculos con nombre en la vista de origen de datos. Estos cálculos almacenan la expresión que se utiliza para crear la columna. El nombre de los cálculos será columnx comenzando por column1 en cada tabla. Esto ocurre cuando se dispone de un nombre o Id. de miembro de un nivel basado en una expresión en Analysis Services 2000. En este programa, los cuadros de las propiedades de nombre e Id. de miembro permitían utilizar instrucciones de tipo SQL para tratar problemas como la concatenación. Ahora se almacenan como expresiones. El cubo Foodmart, por ejemplo, presenta un caso de este tipo en la dimensión Clientes. Al realizar la migración, se observará la presencia de una columna nueva en la tabla Clientes (en la vista de origen de datos y también agregada como atributo) con el nombre Column1. Al revisar las propiedades, se observa que el origen es una concatenación de las columnas Nombre y Apellidos. |
| • | Prácticamente todas las columnas de las tablas de los orígenes de datos se agregan como dimensiones de atributo. Las columnas excluidas son aquellas que contienen tipos de datos que Analysis Services excluye al no considerarlas de interés. Entre estas se encuentran: timestamp, uniqueidentifier y table. Todas las columnas numéricas, de fecha y basadas en caracteres son atributos agregados. |
| • | Los cubos virtuales se migran como cubos. Los grupos de medidas no se agregan al cubo. Se migran como grupos de medidas vinculados que apuntan al cubo base. Por cada cubo base al que hace referencia el cubo virtual original, dispondrá de un cubo de medida vinculado que apunta a la base. |
| • | Las dimensiones virtuales están sujetas a las reglas de combinación de dimensiones. Las dimensiones virtuales se basaban en las propiedades de miembro y podían incluir uno o varios niveles. Si la dimensión virtual disponía de un único nivel, se combinaba con la dimensión en la que estaba basada. Por el contrario, si la dimensión virtual presentaba varios niveles, se convertía a una dimensión real. Por ejemplo, en la base de datos Foodmart disponemos de tres dimensiones virtuales. Para ilustrar esto, veremos Posición (que presenta varios niveles) y Tamaño de tienda en metros cuadrados (que presenta un solo nivel). En la migración, se crea Posición como una nueva dimensión. Tamaño de tienda en metros cuadrados se combina con la dimensión de tienda. Se agrega a la dimensión Metros cuadrados como atributo. |
| • | Recibirá un mensaje por cada acción en el que se informa de que se va a migrar como un comando. En la interfaz de usuario de Analysis Services 2005, advertirá que aún se hace referencia a éstas como acciones. |
| • | Las vistas de orígenes de datos se crean automáticamente y crearán consultas con nombre para representar un conjunto de columnas de una tabla. La vista de origen de datos que se crea incluye todas las tablas de hechos y dimensiones que se emplearon en la base de datos OLAP de Analysis Services 2000. |
| • | Las particiones se migran, aunque las secuencias de comandos utilizadas para crearlas automáticamente se migrarán a secuencias de comandos XMLA. Las particiones utilizan un enlace de consulta a través de la misma instrucción SQL que Analysis Service 2000 generaba para procesar la partición. |
| • | Las funciones se migran con seguridad de cubo y dimensión. Analysis Services 2005 permite utilizar más tipos de implementaciones de seguridad. Si se desea implementar alguna de las nuevas opciones de seguridad, deberá hacerlo después de la migración. |
| • | Se migran varias dimensiones de jerarquía pero no siempre se nombran del modo deseado. Por ejemplo, las dimensiones Time.Fiscal y Time.Calendar en Analysis Services 2000 migrarán probablemente a Time y Time 1. Si ya dispone de una jerarquía con nombre Time, migrará a Time TimeDim y TimeDim 1, lo que puede resultar un tanto confuso. Aunque no se trate del resultado que desee, es muy sencillo cambiar el nombre de las dimensiones. |
Una vez finalizado el asistente para migración, puede que desee ir a Business Intelligence Development Studio para revisar los resultados y realizar las modificaciones necesarias. Las tareas que se deben realizar después de la migración incluyen:
| • | Cambiar el nombre de las dimensiones para que se adapten a su convención de nomenclatura. |
| • | Determinar si todas las jerarquías definidas por el usuario se encuentran en las dimensiones adecuadas. En determinados casos, el asistente para migración creará más dimensiones de las necesarias. Tal vez pueda consolidar algunas de las jerarquías definidas por el usuario y eliminar las dimensiones adicionales. Esto ayudará a garantizar que los nuevos nombres de las dimensiones no afecten a las consultas MDX existentes y que éstas den error. |
| • | Nombrar los cálculos con nombre. Columnx es el nombre que se asigna a cada cálculo con nombre que se agrega a la vista de origen de datos. Deseará asignar a éstos un nombre adecuado para la columna. |
| • | Configurar los valores de obtención de detalles como una acción de obtención de detalles. La obtención de detalles se realiza ahora como una acción y, por tanto, se debe configurar. |
Para cambiar el nombre de una dimensión en Business Intelligence Development Studio, siga este procedimiento.
Para ver el cubo nuevo y cambiar el nombre de una dimensión
1. | En el grupo de programas de SQL Server 2005, abra Business Intelligence Development Studio. |
2. | Al abrir la herramienta, lo más probable es que aparezca la página de inicio de Visual Studio. |
3. | Para abrir el cubo, haga clic en Open (Abrir) en el menú File (Archivo). Haga clic en Analysis Services Database (Base de datos de Analysis Services), como se muestra en la figura 4.  Figura 4: En Business Intelligence Development Studio, puede abrir una base de datos de Analysis Services existente |
1. | Se le presentará la opción de Create a Database (Crear una base de datos) o Open an Existing Database (Abrir una base de datos existente). Seleccione Open an Existing Database (Abrir una base de datos existente) y proporcione la información relativa a la instancia y la base de datos. |
2. | En Solution Explorer (Explorador de soluciones), aparecerá la base de datos y una lista con los cubos y las dimensiones generados. |
3. | Para cambiar el nombre de una dimensión, haga clic con el botón secundario del mouse (ratón) y elija Rename (Cambiar nombre). A continuación, puede escribir un nombre nuevo, como se muestra en la figura 5.  Figura 5: Resulta fácil cambiar el nombre de los objetos en Analysis Services 2005 |
El asistente para migración no implementa una serie de características nuevas, ya que éstas no cuentan con una función equivalente en Analysis Services 2000. A estas características se obtiene acceso a través de las fichas y los cuadros de propiedad disponibles en las herramientas administrativas de Analysis Services. Entre las características de alto nivel que no se implementan se incluyen, aunque sin carácter restrictivo:
| • | Indicadores clave del rendimiento (KPI) |
| • | Traducciones |
| • | Dimensiones de varios a varios |
| • | Dimensiones de función |
| • | Medidas semiaditivas |
Migración en el proyecto REAL
Las bases de datos y los cubos OLAP que se utilizaron en el proyecto REAL se generaron al volver a diseñar la estructura. Las asistentes de Analysis Services 2005 se utilizaron como base para el diseño de los cubos. Como proceso secundario, cuyo objetivo era obtener una comparativa de resultados, se utilizó el asistente para migración con un conjunto de datos de ejemplo de la librería Barnes and Noble. Los datos utilizados compartían un gran número de dimensiones, gran parte de las cuales eran dimensiones virtuales. Tras ejecutar el asistente para migración, se realizaron las observaciones siguientes:
| • | Cada dimensión virtual se basaba en propiedades de miembro de una tabla de elementos. En la migración, cada dimensión se combinaba con la dimensión del elemento (o se le cambiaba el nombre). Cada dimensión virtual se agregó como una jerarquía definida por el usuario de la dimensión de elemento. Cada una de ellas se hacía visible de forma predeterminada y se le puede hacer referencia del mismo modo que antes de la migración. De este modo, aumentan las posibilidades de que las consultas anteriores continúen funcionando al utilizar simplemente el nuevo proveedor. |
| • | Se creó una única vista de origen de datos a partir del único origen de datos utilizado en Analysis Services 2000. La vista de origen de datos representaba todas las tablas que utilizaba el origen de datos existente. |
| • | El único cubo virtual se migró a un cubo en Analysis Services 2005. Cada cubo base migró como un grupo de medidas independiente: uno para Ventas de tienda; uno para Inventario de tienda y otro para Inventario de centro de distribución. |
| • | Toda la información de seguridad, incluidas las funciones y la seguridad de los datos, se migró correctamente. |
| • | Con la excepción de la dimensión Time, cuyo nombre cambió a Time.Fiscal y Time.Calendar (como se describió anteriormente al tratar varias jerarquías), no se produjeron conflictos de nomenclatura en las dimensiones. Por tanto, en Analysis Services 2005 tenían el mismo nombre que en Analysis Services 2000. |
| • | En general, el proceso fue rápido y se desarrolló sin problemas. Asimismo, se crearon con éxito en Analysis Services 2005 los mismos cubos que ya existían en Analysis Services 2000. |
| • | En los datos de inventario, se utilizaron las nuevas medidas semiaditivas para definir LastNonEmptyChild para todas las medidas disponibles y en petición. Debido a que se trata de una nueva funcionalidad en Analysis Services 2005, se eliminaron los cálculos complejos que se utilizaban para los resúmenes de tiempo semiaditivos. |
Migrar o volver a diseñar
El asistente para migración permite obtener una primera vista general de los datos de los cubos de Analysis Services 2005. No obstante, es necesario tener en cuenta que los cubos creados con el asistente para migración serán duplicados de los cubos generados en Analysis Services 2000, un resultado que quizá no sea el deseado. En determinados casos, podrá simplemente utilizar el asistente para migrar y, a continuación, agregar las características deseadas. En otros, sin embargo, la mejor opción será volver a diseñar la estructura de cubos en la nueva arquitectura. Las preguntas siguientes le ayudarán a determinar si el uso del asistente para migración constituye o no un buen punto de inicio, o bien debería volver a diseñar la estructura de cubos.
| • | ¿Dispone de un gran número de cubos pequeños con limitaciones en cuanto a dimensiones y medidas? En Analysis Services 2000, los administradores de cubos solían crear numerosos cubos de tamaño más pequeño. En Analysis Services 2005, si utiliza el asistente, cada uno de estos cubos migrará a cubos individuales. Debido a que en Analysis Services 2005 no se está limitado por cuestiones como el uso de memoria, las medidas de tablas de un solo hecho, los recuentos distintivos y las propiedades de miembro, puede que no desee utilizar numerosos cubos pequeños. Dadas las circunstancias, es preferible tener los datos en un número pequeño de cubos de mayor tamaño con perspectivas que proporcionen el contexto para el usuario. Si se ha utilizado un gran número de cubos a fin de proporcionar el contexto para el usuario, la mejor opción es volver a diseñar los cubos en Analysis Services 2005. |
| • | ¿Dispone de un gran número de propiedades de miembro agregadas a las dimensiones para la creación de informes? Las columnas se pueden ahora agregar como dimensiones de atributo para facilitar el diseño de informes y la exploración. No es necesario tener todas las propiedades de miembro como atributos relacionados. Esto podría precisar una gran cantidad de limpieza manual después de la migración y en este caso lo mejor es volver a diseñar los cubos. |
| • | ¿Utilizó dimensiones privadas para gran parte de los cubos? Las dimensiones privadas se migrarán como dimensiones. Si utilizaba un gran número de dimensiones privadas y el mismo tipo de dimensión para cubos diferentes, observará que el sistema duplicará estas dimensiones como dimensiones en Analysis Services 2005, lo que requerirá limpiar los nombres de las dimensiones y editar los cubos. En este caso, es probable que desee volver a diseñar la estructura de cubos. |
| • | ¿Dispone de un gran número de miembros calculados que ahora se admiten como medidas? Ahora las medidas disponen de más funciones de agregación de las que pueden utilizar. La lista de funciones de agregación se ha ampliado de la lista original: Sum, Count, Distinct Count, Min y Max a esta otra: Average of Children, None, First Child, Last Child, First Non Empty Child y Last Non Empty Child. Si ha creado miembros calculados que ahora se podrían utilizar como medidas, puede que desee considerar volver a diseñar o, al menos, evaluar la extensión de la limpieza que será necesaria después de la migración. |
| • | ¿Ha modificado considerablemente el proceso ETL o ha creado vistas en la base de datos relacional para crear un único origen de datos para el cubo? Si desea que los datos procedan de forma natural de varios orígenes de datos, es preferible volver a diseñar la estructura de cubos y crear las consultas con nombre en las vistas de orígenes de datos para cargar los datos. |
| • | ¿Ha tenido que solucionar recuentos distintivos? En Analysis Services 2000, los recuentos distintivos requerían un alto grado de atención. El número de recuentos estaba limitado a uno por cubo. Asimismo, se sugería que el recuento distintivo estuviera ubicado en su propio cubo y combinado con otras medidas en un cubo virtual. Esta restricción ya no existe, pero tal vez no le guste demasiado la solución que tiene que aplicar. |
| • | ¿Utiliza un gran número de dimensiones y cubos virtuales? Estos se migrarán a dimensiones y cubos reales. Con las dimensiones virtuales, esta no es probablemente la mejor opción, ya que la columna se puede crear fácilmente como una dimensión de atributo. Con los cubos virtuales, en cambio, probablemente necesite limpiar el cubo virtual o los cubos base, ya que, en este caso, los datos se han duplicado. Si la limpieza va a ser extensa, la mejor opción es volver a diseñar el cubo. |
| • | ¿Desea mantener su diseño de cubos pero quiere utilizar las nuevas características de Analysis Services 2005? Si le gusta su estructura de cubos y considera que su funcionamiento se vería mejorado con los nuevos requisitos de diseño de Analysis Services 2005, utilice el asistente para migración para mover los datos a la versión nueva. A continuación, puede agregar las características nuevas que desee. Para obtener una lista completa de las características nuevas, consulte la documentación del producto. |
Conclusión
El modelo dimensional unificado (UDM) establece definitivamente un vínculo sólido entre los informes relacionales y OLAP. Las nuevas opciones de diseño disponibles en Analysis Services 2005 abren un abanico ilimitado de oportunidades de diseño y mejoran considerablemente la experiencia de análisis y creación de informes del usuario final. Por otra parte, el asistente para migración es una herramienta excelente que puede utilizar como punto de partida. El uso de este asistente permite migrar fácilmente las bases de datos OLAP a la nueva versión a fin de que pueda comenzar a utilizar las nuevas características. El asistente para migración hará todo lo posible por recrear su estructura de cubos actual en Analysis Services 2005. Al final, tal vez considere que los cambios de diseño son demasiado importantes y decida comenzar desde cero en lugar de utilizar el asistente. Antes de decidirse por una u otra opción, valore su situación actual y determine hasta qué punto desea que ésta cambie en Analysis Services 2005.
Para obtener más información:
http://www.microsoft.com/spain/sql/