Business Intelligence

What’s New in PerformancePoint Dashboards

The latest release of PerformancePoint Services in Microsoft SharePoint Server 2010 provides you with several new and improved features to help you monitor and analyze performance in your organization. You can use dashboards that include more sophisticated key performance indicators (KPIs) in scorecards. You can use new reports, such as a KPI Details report. And, you can open a Decomposition Tree from a value in an analytic report or a scorecard. You can also apply value filters, such as a “Top 10” filter, to view more specific information in some kinds of scorecards and reports.

Enhancements in KPIs and scorecards

PerformancePoint scorecards new include more sophisticated KPIs and other advanced functionality to make it easier to monitor and analyze organizational performance. For example, you can use Drill Down and Drill Up to view lower or higher levels of detail in your scorecards. And, you can use scorecards that have KPIs on columns. You can also use more advanced scorecards that use Time Intelligence, calculated metrics, and multiple actuals to measure performance.


Depending on how your scorecard is configured, you can expand or collapse rows in your scorecard to see lower or higher levels of detail.

For example, if you have a scorecard that measures product sales profitability across different products in a retail organization, your scorecard might resemble the following image:

If you want to see the next level of detail for a particular category, such as GAMES & TOYS you can click the plus sign (+) next to that category and the scorecard will automatically expand to show the next level of detail. Then, your scorecard might resemble the following image:

You can continue expanding the scorecard until you get to the lowest level of detail. The following image shows the Download Games subcategory expanded to list individual products, which is the lowest level of detail for this particular scorecard.

In the preceding example, the categories, subcategories, and individual products are dynamically populated. That is, as the data changes, the scorecard remains up to date to show the current data.

In addition to clicking the plus sign (+) or minus sign () next to an item in the scorecard, you can also use Drill Down and Drill Up commands, as shown in the following image:

To use the Drill Up or Drill Down commands, right-click an item, and then click Drill Up or Drill Down.

Use Drill Up to view a higher level of detail.

Use Drill Down to view a lower level of detail.


You can now have scorecards that include multiple KPIs on columns, enabling you to view more than one set of metrics for each row in your scorecard. A scorecard with KPIs on columns might resemble the following image:

In the preceding example, the scorecard contains two KPIs on columns: Sales Performance and Sales Margins.


You can now use scorecards that contain more advanced KPIs. For example, you might have KPIs that use formulas and calculations to measure performance (such KPIs are said to use calculated metrics). Or, you might have KPIs that compare multiple values to an overall target (such KPIs are said to use multiple actuals). You can even have KPIs that use special formulas to show information for dynamic time periods, such as “Last Six Months” or “Year to Date” (such KPIs are said to use Time Intelligence). And, you can now have KPIs that show how far off performance is from a goal (such KPIs are said to display Variance).

Although you can have advanced KPIs in your scorecards, your scorecards can remain simple and easy to use. For example, a scorecard that includes such sophisticated KPIs might resemble the following image:

Calculated Metrics

In the following image, the Sales Margins KPI is highlighted. This KPI uses calculated metrics to determine whether performance is on or off target.

When calculated metrics are used in KPIs, SharePoint Server applies one or more formulas to the data as it is retrieved from the underlying database(s). This capability also enables the use of multiple data sources in a single KPI.

New report types and views

You can now use three new PerformancePoint view types in your dashboards: the KPI Details report, analytic pie charts, and the Decomposition Tree.


You can use a KPI Details report in your dashboard to view additional information about scorecard KPIs. For example, you can view the following information in a KPI Details report:

  • The kinds of metrics that are used for KPIs
  • How performance scores are calculated and what the thresholds are for individual scores
  • Comments that were posted by other scorecard users

A KPI Details report might resemble the following image:

A KPI Details report is always accompanied by a scorecard in a dashboard page. This is because all the information that you view in the KPI Details report is determined by what you click in the scorecard. To view information in a KPI Details report, you click any value in a scorecard. To see how scores are calculated in a scorecard, click a cell in a Target value column.


You can now use analytic pie charts in your dashboards. Similar to an analytic line or bar chart, you can use an analytic pie chart to view higher or lower levels of detail. You can also drill into the data to view a different dimension in the underlying SQL Server Analysis Services data cube.

An analytic pie chart might resemble the following image:


You can open a Decomposition Tree to explore data in some kinds of scorecards and reports. The Decomposition Tree is available as an action that you can apply to PerformancePoint analytic reports and scorecards that use Analysis Services data.

You would typically use a Decomposition Tree to see how an individual value in a report or a scorecard can be broken down into its contributing members. The Decomposition Tree automatically sorts results and applies an inline Pareto chart to the data, so you can quickly see the highest contributors to a particular report value. You can also see trends across individual members that contribute to an overall value.

 NOTE    In order to open and use the Decomposition Tree, you must have Microsoft Silverlight 2 or Silverlight 3 installed on your computer. In addition, depending on how a scorecard or an analytic view is configured, you might not be able to open the Decomposition Tree.

To open the Decomposition Tree, right-click an individual value, such as a point in a line chart, a bar in a bar chart, a wedge in a pie chart, or a cell in a grid or a scorecard. Then, you can select Decomposition Tree. The Decomposition Tree opens in a new window, where you can either drill down to the next level of detail, or drill into the data to view a different dimension in the data cube.

A Decomposition Tree might resemble the following image:

Using the Decomposition Tree, you can also view member properties for a particular dimension member, as shown in the following image:

Business Intelligence

Data Mining

Nested tables
En Microsoft SQL Server 2005 Analysis Services (SSAS), los datos se deben incluir en un algoritmo de minería de datos como una serie de escenarios contenidos dentro de una tabla de escenarios (Case Table). No todos los escenarios pueden describirse mediante una sola fila de datos. Por ejemplo, un escenario se puede derivar de dos tablas, una que contenga la información del cliente y otra las compras de ese cliente. Un solo cliente de la tabla de clientes puede tener varias compras en la tabla de compras. Esto dificulta la descripción de los datos usando una sola fila. Analysis Services proporciona un método exclusivo para controlar estos escenarios mediante el uso de tablas anidadas. El concepto de una tabla anidada se muestra en la siguiente ilustración.

nested tables

En este diagrama, la primera tabla, que es la tabla primaria, contiene información sobre los clientes y asocia cada cliente con un único identificador. La segunda tabla, la tabla secundaria, contiene las compras de cada cliente. Las compras de la tabla secundaria se relacionan con la tabla primaria mediante el identificador único, la columna CustomerKey. La tercera tabla del diagrama muestra cómo se combinan ambas tablas.

Una tabla anidada se representa en la tabla de escenarios como una columna especial que tiene un tipo de datos TABLE. En las filas específicas de escenario, esta clase de columna contiene filas seleccionadas de la tabla secundaria que forman parte de la tabla primaria

A fin de crear una tabla anidada, las dos tablas de origen deben contener una relación definida, de forma que los elementos de una tabla puedan relacionarse con los de la otra. En Business Intelligence Development Studio, puede definir esta relación dentro de la vista de origen de datos

Estructuras de minería de datos (Mining Structures)

Son varios los objetos que intervienen en la minería de datos en Microsoft SQL Server 2005 Analysis Services (SSAS). Los dos objetos principales que se utilizan son:

Data Mining Structure

La estructura de minería de datos es una estructura de datos que define el dominio de datos a partir del cual se generan los modelos de minería de datos. Una única estructura de minería de datos puede contener varios modelos de minería de datos que comparten el mismo dominio.

Las unidades de creación de la estructura de minería de datos son las columnas de la estructura de minería de datos, que describen los datos que contiene el origen de datos. Estas columnas contienen información como el tipo de datos, el tipo de contenido y el modo en que se distribuyen los datos.

Una estructura de minería de datos también puede contener tablas anidadas (nested tables). Una tabla anidada representa una relación de uno a varios entre la entidad de un escenario y sus atributos relacionados. Por ejemplo, si la información que describe al cliente se encuentra en una tabla y las compras del cliente en otra, puede utilizar tablas anidadas (nested tables) para combinar la información en un único escenario. El identificador del cliente es la entidad (Entity) y las compras son los atributos relacionados (related attributes).

La estructura de minería de datos no contiene información sobre el modo en que las columnas se utilizan para un modelo de minería de datos concreto, ni sobre el tipo de algoritmo que se utiliza para generarlo; esta información se define en el propio modelo de minería de datos.

Data Mining Model

Un modelo de minería de datos aplica un algoritmo de modelo de minería de datos a los datos que representa una estructura de minería de datos. Al igual que la estructura de minería de datos, el modelo de minería de datos contiene columnas. Un modelo de minería de datos está contenido en la estructura de minería de datos y hereda todos los valores de las propiedades definidas por la estructura de minería de datos. El modelo puede utilizar todas las columnas de la estructura de minería de datos o un subconjunto de las mismas.

Además de los parámetros que se definen en la estructura de minería de datos, el modelo de minería de datos contiene dos propiedades: Algorithm y Usage. El parámetro algorithm se define en el modelo de minería de datos y el parámetro usage en la columna del modelo de minería de datos. Estos parámetros se describen en la siguiente tabla.

algorithm  :Propiedad del modelo que define el algoritmo que se utiliza para crearlo.

usage :Propiedad de la columna del modelo que define el modo en que el modelo utiliza una columna. Puede definir las columnas de modo que sean columnas de entrada (Input), de clave (Key) o de predicción (Predict).

Un modelo de minería de datos es simplemente un objeto vacío hasta que se procesa. Al procesar un modelo, los datos que define la estructura se pasan por el algoritmo. El algoritmo identifica las reglas y los patrones en los datos y, después, utiliza dichas reglas y patrones para rellenar el modelo..

Una vez procesado un modelo, puede explorarlo utilizando los visores personalizados que se incluyen en Business Intelligence Development Studio y SQL Server Management Studio, o realizando consultas al modelo para llevar a cabo predicciones.

Puede crear varios modelos basados en la misma estructura. Todos los modelos generados a partir de la misma estructura deben proceder del mismo origen de datos. No obstante, los modelos puede diferir en lo que respecta a qué columnas de la estructura se van a usar, el modo en que se van a usar, el tipo de algoritmo que se emplea para crear cada modelo y la configuración de los parámetros de cada algoritmo. Por ejemplo, puede generar modelos de árbol de decisión o de clústeres independientes, cada uno con columnas diferentes de la estructura y utilizado para llevar a cabo diferentes tareas empresariales.

Mining Structure Columns

Las columnas de la estructura de minería de datos definen el modo en que un modelo de minería de datos utiliza las columnas de un origen de datos en Microsoft SQL Server 2005 Analysis Services (SSAS). Las columnas de la estructura se agregan a la estructura de minería de datos cuando se crea. Cada columna de la estructura de minería de datos contiene la siguiente información:

  • Id.
  • Nombre
  • Contenido
  • Tipo
  • Distribución (se incluye una distribución si la columna es continua).
  • Indicadores de modelado (los indicadores de modelado también se pueden definir en el modelo de minería de datos).
  • Enlace

Los algoritmos de terceros también pueden incluir propiedades personalizadas que se pueden definir en la columna de la estructura de minería de datos.

Las columnas de la estructura de minería de datos se diseñan para ser flexibles y extensibles, porque cada algoritmo que se utilice para generar un modelo de minería de datos puede utilizar diferentes columnas de la estructura para interpretar los datos.

Los tipos de datos y los tipos de contenido que definen las columnas de la estructura se derivan del origen de datos que se utiliza para crear la estructura. Puede cambiar esta configuración en la estructura de minería de datos; también puede establecer indicadores de modelado y establecer la distribución de columnas continuas.

Los temas siguientes describen las diferentes formas de definición de columnas de la estructura de minería de datos.



Tipos de datos (Data Mining)

Describe los tipos de datos que se pueden utilizar para definir una columna de la estructura de minería de datos.

Tipos de contenido (Data Mining)

Describe los tipos de contenido que se pueden utilizar para definir una columna de la estructura de minería de datos.

Columnas clasificadas
(Classified Columns)

Describe los tipos de columnas clasificadas que se pueden utilizar para relacionar una columna de la estructura de minería de datos con otra.

Distribuciones de columnas

(Column Distributions)

Describe las distribuciones que se pueden utilizar para definir los datos de una columna de la estructura de minería de datos.

Métodos de discretización (Discretization Methods)

Describe los diferentes métodos que se pueden utilizar para discretizar datos en columnas continuas de la estructura de minería de datos.

Indicadores de modelado (Data Mining)

Describe los indicadores de modelado que se pueden utilizar para definir una columna de la estructura de minería de datos.

Data Types – Data Mining

Antes de procesar un modelo de minería de datos en Microsoft SQL Server 2005 Analysis Services (SSAS), puede definir los tipos de datos de las columnas de la estructura de minería de datos en la que se basa el modelo. Analysis Services es compatible con los siguientes tipos de datos para las columnas de la estructura de minería de datos:

  • Text
  • Long
  • Boolean
  • Double
  • Date

Cada uno de estos tipos de datos es compatible con uno o más tipos de contenido, que puede utilizar para delimitar más los datos de columna. En la siguiente tabla se identifican los tipos de contenido que admite cada tipo de datos. Para obtener más información acerca de los tipos de contenido.

Tipo de datos

Tipos de contenido admitidos


Discrete, Discretized, Sequence


Continuous, Cyclical, Discrete, Discretized, Key Sequence, Key Time, Ordered, Sequence, Time




Continuous, Cyclical, Discrete, Discretized, Key Sequence, Key Time, Ordered, Sequence, Time


Continuous, Discrete, Discretized, Key Time

Los tipos de contenido Time y Sequence sólo son compatibles con algoritmos de terceros

Content Types – Data Mining

En Microsoft SQL Server 2005 Analysis Services (SSAS), puede definir los tipos de datos de las columnas de una estructura de minería de datos para influir en el modo en que los algoritmos procesan sus datos al crear modelos de minería de datos. No obstante, definir los tipos de datos de columnas proporciona a los algoritmos información únicamente sobre el tipo de datos de las columnas, pero no acerca del comportamiento de esos datos. Por este motivo, cada tipo de datos de la minería de datos en Analysis Services admite uno o más tipos de contenido, que puede utilizar para describir el comportamiento de los datos que contiene la columna. Por ejemplo, si el contenido de una columna se repite en un intervalo concreto, como los días de la semana, puede especificar el tipo de contenido de esa columna como cíclico.

La siguiente lista describe los tipos de contenido de Analysis Services e identifica los tipos de datos que admite cada uno. Además de los tipos de contenido que aquí se enumeran, puede utilizar columnas clasificadas para definir tipos de contenido para algunos tipos de datos.

DISCRETE: La columna contiene valores discretos. Por ejemplo, una columna de género es una columna de atributos discreta muy habitual, en la que los datos representan un número contado, finito, de categorías de género. Los valores de una columna de atributos discreta no implican que los datos estén ordenados, aunque los valores sean numéricos; los valores están claramente separados y no existe ninguna posibilidad de que se den valores fraccionales. Los códigos telefónicos de cada zona son un buen ejemplo de datos numéricos discretos. Este tipo de contenido es compatible con todos los tipos de datos de Data Mining en Analysis Services.

CONTINUOUS: La columna contiene valores que representan un conjunto continuo de datos numéricos. A diferencia de una columna discreta, que representa datos contados, finitos, una columna continua representa datos de medidas; además, es posible que los datos contengan un número infinito de valores fraccionales. Una columna de ingresos es un ejemplo de una columna de atributos continua. Este tipo de contenido es compatible con los siguientes tipos de datos: Date, Double y Long.

DISCRETIZED: La columna contiene valores que representan grupos o depósitos de valores que se derivan de una columna continua. Los depósitos se tratan como si fueran valores ordenados y discretos. Este tipo de contenido es compatible con los siguientes tipos de datos: Date, Double, Long y Text.

KEY: La columna identifica una fila de forma única. Este tipo de contenido es compatible con los siguientes tipos de datos: Date, Double, Long y Text.

KEY SEQUENCE: La columna es un tipo específico de clave donde los valores representan una secuencia de eventos. Los valores están ordenados y no tienen que estar separados por una distancia equivalente. Este tipo de contenido es compatible con los siguientes tipos de datos: Double, Long, Text y Date.

KEY TIME: La columna es un tipo específico de clave donde los valores representan valores que están ordenados y que ocurren en una escala de tiempo. Este tipo de contenido es compatible con los siguientes tipos de datos: Double, Long y Date.

ORDERED: La columna contiene valores que definen un conjunto ordenado. No obstante, el conjunto ordenado no implica ninguna relación de distancia o magnitud entre los valores del conjunto. Por ejemplo, si una columna de atributos ordenados contiene información acerca de una lista de niveles de especialización que vayan del uno al cinco, no existe información implícita entre los niveles de especialización; un nivel cinco de especialización no es necesariamente cinco veces mejor que un nivel uno de especialización.  Las columnas de atributos ordenados se consideran discretas en términos de tipo de contenido. Este tipo de contenido es compatible con todos los tipos de datos de Data Mining en Analysis Services.

CYCLICAL: La columna contiene valores que representan un conjunto ordenado cíclico. Por ejemplo, los días numerados de la semana es un conjunto ordenado cíclico, ya que el día número uno sigue al día número siete. Las columnas cíclicas se consideran ordenadas y discretas en términos de tipo de contenido. Este tipo de contenido es compatible con todos los tipos de datos de minería de datos en Analysis Services.

Jonnathan De La Barra Acalorado

Business Intelligence

Microsoft SQL Server 2005 Reporting Services – Part II

Implementación y administración 

Configuración de Reporting Services. Se debe implementar y mantener un Report Server existente mediante una interfaz gráfica de usuario para configurar service accounts, virtual directories, report server database, claves de cifrado e implementación de conjuntos de Web Servers.

Administrador de reportes. Se debe configurar seguridad basada en Roles y administrar el contenido del Report Server mediante el establecimiento de propiedades en orígenes de datos, reportes, carpetas, recursos y modelos de informe. Se puede configurar la ejecución de reportes y el historial del informe, y establecer límites sobre el tiempo de procesamiento (Report Execution Timeout); supervisar y cancelar reportes pendientes o en curso; y crear y administrar conexiones de orígenes de datos y programaciones independientemente de los reportes a los que están asociadas.

Integración con las tools SQL Server Management Studio, SQL Server Configuration Manager y SQL Server Surface Area Configuration. Los administradores del Report Server pueden utilizar las herramientas que se suministran con SQL Server 2005 para administrar una instalación de Reporting Services. Pueden registrar secuencias de comandos en Management Studio para reproducir tareas de mantenimiento de rutina en otros servidores de reportes.

Seguridad basada en roles. Se debe utilizar la seguridad basada en roles para controlar el acceso a carpetas, reportes y recursos. La configuración de seguridad sigue un patrón de herencia en la estructura de carpetas. Puede modificar la seguridad en cualquier rama para cambiar la definición de acceso al nivel de elemento de los usuarios.


Características de acceso y entrega de reportes


Acceso a petición mediante conexiones Web. Se puede utilizar un browser para desplazarse por una jerarquía de carpetas a fin de buscar y trabajar con reportes y otros elementos. Se puede hacer referencia a los reportes desde la lista Favoritos del Web Browser crear un vínculo desde un portal Web.

SharePoint Web Part. Reporting Services proporciona dos Web Parts para ver reportes y desplazarse por carpetas del Report Server. Se puede incrustar las Web Parts en el sitio Microsoft SharePoint Portal para integrarlas fácilmente con una implementación del Report Server.

Mis reportes y Mis suscripciones. En el Report Manager, se pueden almacenar y administrar reportes y suscripciones en un área de trabajo personal.

Suscripciones para entrega por e-mail o a recursos compartidos de archivos. Se puede entregar reportes automáticamente mediante una suscripción estándar y establecer preferencias de presentación de reportes. Los usuarios que deseen ver un informe en Microsoft Excel, por ejemplo, pueden especificar este formato en una suscripción. Se puede entregar un informe representado en una bandeja de entrada de e-mail. Para ello se deben establecer las opciones de entrega que controlan si el informe se entrega como vínculo o como datos adjuntos. Se debe entregar un informe representado en una carpeta compartida, estableciendo las opciones de entrega que controlan si el informe se sobrescribe o se agrega a una carpeta existente.

Suscripciones controladas por datos. La distribución de reportes se automatiza mediante suscripciones controladas por datos, que generan una lista de destinatarios e instrucciones de entrega en tiempo de ejecución desde un origen de datos externo. Utilizando una consulta e información de asignación de columnas para personalizar la salida del informe para un número elevado de usuarios.


Programación y extensibilidad 


Lenguaje RDL (Report Definition Language). RDL describe todos los elementos posibles de un informe mediante una gramática XML que se valida con un esquema XML. La definición de un informe concreto se basa en el lenguaje RDL y contiene instrucciones para representar el diseño en tiempo de ejecución. RDL es extensible. Puede agregar compatibilidad con elementos o características que no se encuentren en el esquema RDL existente y, a continuación, generar herramientas personalizadas y extensiones de representación de reportes para controlar las características que cree.

API de SOAP. Los métodos del Web Service del Report Server se pueden utilizar para obtener acceso mediante programación a un servidor de reportes y al servicio Web del servidor de reportes.

Acceso mediante direcciones URL. Se puede tener acceso a elementos del Report Server mediante cadenas de direcciones URL con parámetros. Todos los reportes y los elementos almacenados en un Report Server pueden tener direcciones del espacio de nombres del Report Server.

Proveedor WMI. Reporting Services incluye un proveedor de Instrumental de administración de Windows (WMI) que se puede utilizar para administrar el servicio de Windows del Report Server.

Entrega extensible, procesamiento de datos, representación, seguridad y procesamiento de reportes. Se pueden crear extensiones de entrega personalizadas para enrutar reportes a recursos compartidos de archivos, almacenes de archivo internos o aplicaciones internas. Se puede ampliar el procesamiento de datos para consultar, convertir o transformar datos procedentes de nuevos tipos de orígenes de datos. Se puede crear extensiones de representación personalizadas para admitir la representación de reportes con formatos de aplicación o formatos orientados a Web que no se proporcionan con el producto. Se puede generar o integrar una extensión de seguridad que proporcione una alternativa al modelo de autenticación de Windows.

Arquitectura del SQL Server Reporting Server

SQL Server Reporting Services es un conjunto de componentes de procesamiento, herramientas e interfaces de programación que permiten el desarrollo y la utilización de reportes completos en un entorno administrado. El conjunto de herramientas incluye herramientas de desarrollo, de configuración y de administración así como herramientas de visualización de reportes. Las interfaces de programación incluyen el protocolo simple de acceso a objetos (SOAP), los extremos de direcciones URL e Instrumental de administración de Windows (WMI), para permitir una fácil integración con aplicaciones y portales nuevos o existentes. 

El procesamiento se distribuye en múltiples componentes. Para recuperar datos, procesar el diseño de los reportes, representar los formatos de presentación y entregar en destinos específicos se utilizan procesadores centralizados y especializados. El procesamiento de una presentación tiene lugar después de recuperar los datos y es independiente del procesamiento de los datos, lo que permite a diversos usuarios consultar el mismo informe simultáneamente en formatos diseñados para distintos servicios o cambiar inmediatamente el formato de visualización del informe, de HTML a PDF, a Microsoft Excel o a XML, con un solo clic. La arquitectura modular se ha diseñado para permitir ampliaciones. Los programadores pueden incluir funciones de reportes en aplicaciones personalizadas o ampliar la funcionalidad para hacerla compatible con características personalizadas.

El diagrama siguiente muestra los componentes y las herramientas de Reporting Services. El diagrama también muestra cómo se adaptan las herramientas personalizadas al diseño global. Presenta el flujo de solicitudes y datos entre componentes del servidor y los componentes que envían y recuperan contenido de un almacén de datos.

Diagrama de la arquitectura de Reporting Services


El Report Server se implementa como un servicio de Microsoft Windows y como un servicio Web que proporciona una infraestructura de procesamiento optimizada y en paralelo para el procesamiento y la representación de reportes. El servicio Web presenta un conjunto de interfaces de programación que las aplicaciones cliente pueden utilizar para obtener acceso a servidores de reportes. El servicio de Windows proporciona servicios de inicialización, programación y entrega, así como mantenimiento del servidor. Los servicios funcionan conjuntamente y constituyen una única instancia del servidor de reportes.

A través de sus subcomponentes, el Report Server procesa solicitudes de reportes y permite que los reportes estén disponibles para el acceso a petición o la distribución programada. Los subcomponentes del Report Server incluyen procesadores y extensiones. Los procesadores son el concentrador del Report Server. Los procesadores admiten la integridad del sistema de reportes y no se pueden modificar ni ampliar. Las extensiones también son procesadores, pero realizan funciones muy específicas. Reporting Services incluye una o varias extensiones predeterminadas para cada tipo de extensión que se admite. Los programadores de otros fabricantes pueden crear extensiones adicionales para reemplazar o ampliar la capacidad de procesamiento del Report Server.


El Report Server incluye dos procesadores que realizan el procesamiento de reportes previo e intermedio, así como operaciones programadas y de entrega. El Procesador de reportes recupera la definición o el modelo de informe, combina información de diseño con datos de la extensión de procesamiento de datos y representa el informe en el formato solicitado. El Procesador de entrega y programación procesa reportes desencadenados a partir de una programación y los entrega a destinos.

Almacenamiento de datos

El Report Server es un servidor sin estado que almacena todas las propiedades, los objetos y los metadatos en una base de datos de SQL Server. Los datos almacenados incluyen reportes publicados, modelos de informe y la jerarquía de carpetas que proporciona el direccionamiento de todos los elementos que administra el servidor de reportes. Una base de datos del servidor de reportes puede proporcionar almacenamiento interno para una única instalación de Reporting Services o para varios servidores de reportes que formen parte de la implementación escalada.


Un Report Server requiere al menos una extensión de autenticación, una extensión de procesamiento de datos y una extensión de representación. Las extensiones de procesamiento de reportes personalizadas y de entregas son opcionales, pero necesarias si desea admitir controles personalizados o de distribución de reportes

Ø  Extensiones de seguridad

Las extensiones de seguridad se utilizan para autenticar y autorizar usuarios y grupos para un Report Server. La extensión de seguridad predeterminada se basa en la autenticación de Windows. También se puede crear una extensión de seguridad personalizada para reemplazar la seguridad predeterminada si el modelo de implementación requiere un enfoque de autenticación diferente (por ejemplo, si se requiere autenticación basada en formularios para la implementación de Internet o extranet). Sólo puede utilizarse una extensión de seguridad en una única instalación de Reporting Services. Se puede reemplazar la extensión de seguridad de autenticación predeterminada de Windows, pero no utilizarla junto con una extensión de seguridad personalizada.

Ø  Extensiones de procesamiento de datos

Las extensiones de procesamiento de datos se utilizan para consultar un origen de datos. Y cuando esto sucede, devuelven un conjunto de filas planas. Reporting Services utiliza diferentes extensiones para interactuar con distintos tipos de orígenes de datos. Se puede utilizar las extensiones que se incluyen en Reporting Services o desarrollar extensiones propias. Se proporcionan extensiones de procesamiento de datos para orígenes de datos ODBC, SQL Server, Analysis Services, Oracle y OLE DB. Reporting Services puede utilizar también cualquier proveedor de datos de ADO.NET. Las extensiones de procesamiento de datos procesan las solicitudes de consulta del Procesador de reportes.

Ø  Extensiones de representación

Las extensiones de representación convierten los datos y la información de diseño del Procesador de reportes en el formato específico de un dispositivo. Reporting Services incluye seis extensiones de representación: HTML, Excel, CSV, XML, imagen y PDF.

Ø  Extensiones de procesamiento de reportes

Se pueden agregar extensiones de procesamiento de reportes para proporcionar un procesamiento de reportes personalizado para los elementos de informe que no se incluyen en Reporting Services. De forma predeterminada, un servidor de reportes puede procesar tablas, gráficos, matrices, listas, cuadros de texto, imágenes. Si desea agregar características especiales a un informe que requiere un procesamiento personalizado durante la ejecución de informe (por ejemplo, si desea incrustar una asignación de Microsoft MapPoint), puede crear una extensión de procesamiento de reportes para hacerlo.

Ø  Extensiones de entrega

Reporting Services contiene una extensión de entrega por E-mail y una extensión de entrega a recursos compartidos de archivos. La extensión de entrega por e-mail envía un mensaje mediante el Protocolo simple de transferencia de correo (SMTP) que contenga el informe o un vínculo de dirección URL al informe. La extensión de entrega a recursos compartidos de archivos guarda reportes en una carpeta compartida en la red. Se puede especificar la ubicación, el formato de representación, el nombre de archivo y las opciones de sobrescritura del archivo que se crea. También puede utilizar la entrega a recursos compartidos de archivos para archivar reportes representados y como parte de una estrategia de trabajo con reportes de gran tamaño. Las extensiones de entrega funcionan conjuntamente con las suscripciones. Cuando un usuario crea una suscripción, elige una de las extensiones de entrega disponibles para determinar cómo se entrega el informe.

Integración con SQL Server 2005

SQL Server 2005 Reporting Services ofrece dos modelos de implementación:

ü  Una implementación estándar consiste en una instancia de Report Server que utiliza un motor de base de datos de SQL Server local o remoto para alojar la base de datos del Report Server. Se puede utilizar SQL Server 2000 o SQL Server 2005 para alojar la base de datos del Report Server.

ü  Una implementación escalada consiste en varios Report Servers que comparten una sola base de datos del servidor de reportes. La base de datos se puede instalar en una instancia remota de SQL Server o localmente en uno de los Report Servers. La instancia de SQL Server que aloja la base de datos del Report Server puede ser parte de un clúster de conmutación por error.



Implementación estándar

El siguiente diagrama muestra el modelo de implementación estándar, con la base de datos de servidor de reportes ubicada en un servidor remoto. También puede instalarla localmente para que todos los componentes de servidor estén en el mismo equipo.


Las principales consideraciones al elegir dónde alojar la base de datos del servidor de reportes son:

ü  Recursos de procesamiento

ü  Disponibilidad de espacio en disco


El servidor de reportes y el motor de base de datos compiten por recursos de procesamiento como el tiempo de CPU, la memoria y el acceso al disco. Algunas operaciones de servidor de reportes consumen gran cantidad de recursos. Por ejemplo, un servidor de reportes intenta utilizar toda la memoria disponible para operaciones de representación de reportes. La competición por los recursos de procesamiento se puede reducir si el servidor de reportes se ejecuta en un equipo independiente.

Los requisitos de espacio en disco del servidor de reportes son la segunda razón por la que se debe utilizar un motor de base de datos de SQL Server remoto para almacenar datos del servidor de reportes. Aunque el volumen de una base de datos de servidor de reportes puede ser reducido al principio, los requisitos de espacio en disco pueden aumentar notablemente en tiempo de ejecución en función de cómo ejecute los reportes y del número de usuarios que tengan acceso al servidor de reportes. 


Implementación escalada

Se puede implementar Reporting Services de forma escalada para crear una instalación de Report Server altamente disponible y escalable. Configurar una implementación escalada también puede ser de utilidad si se desea mejorar el rendimiento de las operaciones programadas y la entrega de suscripciones. Una implementación escalada de Report Server consta de varios servidores de reportes que comparten una sola base de datos de servidor de reportes. Cada Report Server de la implementación se denomina nodo. Los nodos participan en la implementación escalada si el Report Server se configura para utilizar la misma base de datos que otro Report Server.

Es posible equilibrar la carga de los nodos de servidor para admitir un gran volumen de reportes. Asimismo, la base de datos del servidor de reportes se puede crear en un clúster de conmutación por error si es necesario cumplir requisitos de alta disponibilidad.

Entre las configuraciones de clúster que no se admiten se encuentra la implementación de una instalación de servidor de reportes completa, es decir, un servidor de reportes y su base de datos, en cada nodo de un clúster de varios nodos. Concretamente, no se puede implementar Reporting Services en un clúster de dos nodos formado por un nodo activo y un nodo pasivo que se utiliza cuando se produce un error en el nodo activo

El siguiente diagrama muestra varios servidores de reportes y bases de datos de servidor de reportes implementados en clústeres de servidores distintos.


Crear una base de datos de servidor de reportes

Reporting Services utiliza dos bases de datos relacionales de SQL Server para almacenar metadatos y objetos de servidor de reportes. Una base de datos se utiliza para el almacenamiento principal y la otra para almacenar datos temporales. Las bases de datos se crean juntas y se enlazan mediante el nombre. De manera predeterminada, las bases de datos se denominan reportserver y reportservertempdb. Colectivamente, ambas se conocen como "base de datos del servidor de reportes" o "catálogo del servidor de reportes". Para alojar las bases de datos se puede utilizar SQL Server 2000 o SQL Server 2005.

Para crear la base de datos de servidor de reportes en un equipo remoto es preciso que se configure la conexión para utilizar una cuenta de usuario de dominio o una cuenta de servicio que tenga acceso a la red. Si se decide utilizar una instancia de SQL Server remota, considérese detenidamente qué credenciales debe utilizar el servidor de reportes para conectarse a dicha instancia.

No debe escribir aplicaciones que ejecuten consultas en la base de datos del servidor de reportes. La base de datos del servidor de reportes no es un esquema público. La estructura de tablas puede cambiar de una versión a la siguiente. Si se escribe una aplicación que necesita acceso a la base de datos del servidor de reportes, se debe utilizar las API de Reporting Services para obtener acceso.

El servidor de reportes y la instancia de SQL Server que aloja la base de datos del servidor de reportes pueden estar en dominios diferentes. Para la implementación en Internet, la práctica más común es utilizar un servidor que esté detrás de un firewall. Si se va a configurar un servidor de reportes para acceso a Internet, se debe utilizar credenciales de SQL Server para conectarse a la instancia de SQL Server que esté detrás del firewall y utilizar IPSEC para proteger la conexión.

Jonnathan De La Barra Hot

Business Intelligence

Introducción al Data Mining

Hoy en día es muy frecuente, sobre todo en las grandes empresas, la disponibilidad de grandes volúmenes de datos y el uso generalizado de herramientas informáticas para la extracción adecuada del conocimiento que encierra la información. Este hecho ha transformado el análisis de datos orientándolo hacia determinadas técnicas especializadas englobadas bajo el nombre de Minería de datos o Data Mining.

De modo resumido puede considerarse el Data Mining como un proceso de descubrimiento de nuevas y significativas relaciones, patrones y tendencias al examinar grandes cantidades de datos.

Las técnicas de Data Mining, persiguen el descubrimiento automático del conocimiento contenido en la información de modo ordenado en grandes Bases de Datos. Estas técnicas tienen como objetivo descubrir patrones, perfiles y tendencias a través del análisis de los datos utilizando tecnologías de reconocimiento de patrones, redes neuronales, clustering,  clasificación, predicción y otras técnicas avanzadas de análisis multivariante de datos.

El Concepto de Data Mining

Los recientes avances tecnológicos hacen que las capacidades para generar y almacenar datos se incrementen día a día. Entre los factores que influyen en esta realidad podemos destacar el uso extendido de los códigos de barras, la automatización de todo tipo de transacciones (comerciales, negocios, económicos, gubernamentales o científicos) y los avances en la recopilación de datos. Además Internet ha favorecido el rápido acceso a la información, tanto de datos como de los resultados obtenidos por otros teams.  Por otro lado, ha supuesto la puesta en contacto de workgroups de Organizaciones que, aunque  lejanos en el espacio, están muy cercanos en el ciberespacio, lo que ha dado lugar a fuertes economías de escala a través de la puesta en común de Base de datos, conocimientos y resultados exitosos.

Por otra parte, la evolución de los storage devices (en relación precio-Capacidad de almacenamiento), tales como los discos duros que pueden almacenar gigabytes de información a un precio reducido, ha dado lugar a que empresas y organizaciones almacenen todo tipo de información, desde los datos de sus clientes y sus transacciones, hasta los datos de telemetría, monitorización de pacientes, evolución de los precios en los mercados, etc. Con el tiempo la cantidad de datos que se fue almacenando empezó a crecer y, si bien, el soporte de las herramientas para realizar la gestión de los datos era el adecuado, las relaciones significativas existentes entre ellos, empezaron a sobrepasar las capacidades humanas para el análisis.

Todo este explosivo crecimiento de datos generó, a finales de los 80 la aparición de un nuevo campo de investigación que se denomino KDD (Knowledge Discovery in Databases). Bajo estas siglas se esconde: “el proceso no trivial de descubrimiento de patrones válidos, nuevos, potencialmente útiles y comprensibles en grandes volúmenes de datos”. El proceso de KDD ha servido para unir investigadores de áreas en principio dispersas como Inteligencia Artificial, Estadística, Técnicas de Visualización, Matemáticas en la búsqueda de técnicas eficientes y eficaces que ayuden a encontrar el potencial conocimiento que se encuentra inmerso en los grandes volúmenes de datos almacenados por las organizaciones diariamente.

Si bien el nombre con el que se apareció esta área de investigación fue el de KDD, otros nombres han sido usados para este mismo concepto. Algunos de ellos son Knowledge Discovery, Data Discovery, Information Discovery, Knowledge Extraction, Data Extraction, Information Extraction, Pattern Discovery, Knowledge Mining. En la actualidad es Data Mining, por el que es conocido mundialmente. Este término proviene de la analogía entre enfrentarnos a una gran cantidad de datos para descubrir patrones útiles y en la explotación de una montaña para encontrar una veta de mineral precioso. Ambos procesos necesitan de métodos inteligentes de exploración para optimizar los resultados. En un principio Data Mining fue tan sólo usado para referirse a la etapa del proceso en la que se aplican las técnicas y algoritmos de descubrimiento de patrones. No obstante, en la actualidad, se usa para referirse al conjunto del proceso global de descubrimiento de conocimiento a partir de los datos, mientras que el concepto de herramientas de Data Mining se refiere a los algoritmos de análisis de los datos.

El gran aumento de datos que tienen que analizar las organizaciones no solo dio lugar a la aparición de Data Mining, sino que al mismo tiempo y de manera paralela surge el concepto de Data Warehouse. Uno de los grandes problemas del Data Mining es que los datos nunca fueron guardados pensando en que posteriormente serian analizados, como consecuencia, de forma previa al análisis es necesario un proceso de integración y limpieza de datos que en muchos casos resulta más costoso que el propio análisis. Sin embargo, la aparición de los Data Warehouses como repositorios de información centralizada permite que los procesos de Data Mining se puedan realizar sobre conjuntos de datos que han sido previamente integrados y sometidos a Data Cleansing (procesos de limpieza)

Jonnathan De La Barra Acalorado
Business Intelligence

Microsoft SQL Server 2005 Reporting Services – Part I

Microsoft SQL Server 2005 Reporting Services es una solución basada en el servidor que se utiliza para generar reportes empresariales.

Dichos reportes extraen contenido de una variedad de orígenes de datos relacionales y multidimensionales, para ser publicados y vistos en diversos formatos. También administra la seguridad y las suscripciones de manera centralizada. Los reportes creados se pueden ver mediante una conexión Web o como parte de una aplicación de Microsoft Windows o un portal de SharePoint.  

Reporting Services incluye:

ü  Herramientas y asistentes gráficos para crear y publicar reportes y modelos de reportes

ü  herramientas de administración del servidor de reportes para administrar Reporting Services

ü  Interfaces de programación de aplicaciones (API) para programar y extender el modelo de objetos de Reporting Services.


SQL Server 2005 Reporting Services ofrece funcionalidad empresarial y de reportes habilitados para Web de modo que se puedan crear reportes que extraigan el contenido de una gran variedad de orígenes de datos, publicar reportes en distintos formatos, y administrar de manera centralizada la seguridad y las suscripciones.

Los reportes que se generan pueden basarse en datos relacionales o multidimensionales de SQL Server, Analysis Services, Oracle o cualquier proveedor de datos de Microsoft .NET, como ODBC u OLE DB. Puede crear reportes tabulares, matriciales o de formato libre. También puede crear reportes adaptados a una circunstancia determinada, que utilicen modelos y orígenes de datos predefinidos.  

Visual y funcionalmente, los reportes que se generan en Reporting Services van más allá de los reportes tradicionales, puesto que incluyen características interactivas y basadas en Web. Algunos ejemplos de estas características son los reportes de varios niveles de detalle, que permiten la navegación por distintas capas de datos, los reportes con parámetros, que admiten el filtro de contenido en tiempo de ejecución, o los reportes de formato libre, que admiten contenido con diseños verticales, anidados o adyacentes, vínculos a contenido o recursos basados en Web y acceso seguro y centralizado a reportes mediante conexiones Web locales o remotas.  

Aunque Reporting Services se integra con otras tecnologías de Microsoft sin necesidad de adaptación, los programadores y otros proveedores pueden generar componentes compatibles con otros formatos de salida de reportes, formatos de entrega, modelos de autenticación y tipos de orígenes de datos. La arquitectura de desarrollo y tiempo de ejecución se ha creado con un diseño modular para admitir extensiones de terceros y posibilidades de integración.

Reportes empresariales 

Muchas compañías utilizan software de elaboración de reportes para distribuir información a los usuarios que utilizan reportes para tomar decisiones, identificar oportunidades o analizar amenazas. Reporting Services incluye una amplia gama de herramientas y servicios listos para usar que le permitirán crear, implementar y administrar reportes para la organización. Si bien se puede manipular reportes mediante programación, ésta no es necesaria si desea utilizar Reporting Services tal como se distribuye. Las herramientas de creación y administración incluyen el Report Designer, SQL Server Management Studio, el Report Manager y la herramienta de Reporting Services Configuration Manager. Los usuarios de empresas pueden utilizar el Report Manager, elementos Web de SharePoint o un Web browser para ver reportes a petición o suscribirse a reportes que se entregan por e-mail.

Elaborar reportes ad hoc  

Los usuarios que trabajen con datos empresariales precisan con frecuencia la capacidad de crear y ajustar reportes ad-hoc. Reporting Services incluye el Report Builder, una tool que permite seleccionar un template y un report model del Report Server, arrastrar campos de datos y elementos gráficos a una superficie de diseño para crear reportes básicos, guardar archivos de definición de reportes en el servidor y modificar los reportes. Los reportes ad hoc requieren Report Models predefinidos que se creen con un Report Designer y se publiquen después en el Report Server para usarlos en la organización.

El Generador de Reportes proporciona reportes ad hoc sobre datos relacionales y multidimensionales mediante el Data Source model. Está destinado a usuarios que desean crear reportes básicos fácilmente sin escribir consultas. El Report Builder utiliza modelos y plantillas de informe predefinidos que administran conexiones de datos, consultas y relaciones de datos de modo que los usuarios sólo deban arrastrar y colocar campos de datos en una plantilla para crear reportes tabulares o de matriz

Elaboración de reportes incrustados

 Un desarrollador, puede utilizar Reporting Services para proporcionar características de elaboración de reportes a su aplicación. Para algunas aplicaciones, la adición de reportes, completa un conjunto de características proporcionando un modo de presentar datos de los que la aplicación mantiene un seguimiento, crea o supervisa. Se puede utilizar el Report Designer para crear reportes basados en un Data Source de su aplicación o que esté disponible públicamente.

Se puede utilizar la API para definir el acceso y agregar compatibilidad con las características integradas del Report Server que se desee incluir en una aplicación 

Como parte de la implementación de la aplicación, se debe incluir un Report Server y Report Server ’s Database que contenga reportes y otros metadatos. En tiempo de ejecución, cuando el usuario solicita un informe, el código de la aplicación llama al Web Service del Report Server, que después recupera la definición de informe de la Report Server ‘s Database y procesa el informe con los datos más recientes.

Como alternativa, si la aplicación no requiere todas las características proporcionadas en el Report Server, puede utilizar los controles ReportViewer que incluye Microsoft Visual Studio 2005. A diferencia de Reporting Services, los controles ReportViewer se distribuyen gratuitamente con la aplicación.

Se puede utilizar el Report Designer para crear reportes simples o reportes complejos que incluyan expresiones y ensamblados personalizados para hacerlos compatibles con una funcionalidad personalizada.

Integración de portales  

Puesto que los reportes pueden acomodar y presentar datos de una gran variedad de orígenes, muchas organizaciones utilizan las características de elaboración de reportes interactivas de Reporting Services para distribuir datos tabulares o gráficos en aplicaciones de portal. Se puede alojar reportes en una página de portal o crear un informe que refleje una aplicación Web con estilo de panel incrustando varios reportes, imágenes y gráficos controlados por datos en un solo diseño de informe de forma libre

Elaborar reportes para Internet

Puede crear reportes que estén disponibles para aquellos empleados que trabajen fuera o en oficinas regionales implementando un servidor de reportes en un servidor Web para Internet. Tenga en cuenta que la implementación de reportes en Internet suele requerir la creación de una extensión de seguridad personalizada que permita autenticación basada en formularios. Se requieren conocimientos en seguridad para Web, implementación en Internet y programación para escribir las extensiones necesarias.  

Generar herramientas personalizadas de diseño y administración de reportes

Las herramientas y aplicaciones de que dispone Reporting Services se basan en interfaces de programación disponibles para todos los usuarios. Esto significa que es posible reemplazar las aplicaciones y herramientas incluidas en Reporting Services por un conjunto de herramientas personalizadas que se cree ad hoc. Por ejemplo, si se desea una alternativa al entorno de creación de Visual Studio utilizado por el Diseñador de reportes, se puede desarrollar una herramienta de elaboración de reportes personalizada para reemplazarlo. Para generar una herramienta de administración de reportes o un portal Web personalizado, se debe revisar la API para conocer las funciones de administración del servidor de reportes que debe permitir. Reporting Services incluye un proveedor WMI (Instrumental de administración de Windows) que se puede usar para desarrollar herramientas basadas en Windows utilizadas para la administración de servidores.

Ampliar la funcionalidad de Reporting Services

Reporting Services está diseñado para poderse ampliar. Se pueden crear extensiones personalizadas para admitir otros tipos de orígenes de datos, métodos de entrega, modelos de seguridad y elementos de informe. Cuando se crean extensiones personalizadas, el grado de dificultad puede variar considerablemente dependiendo del tipo de extensión que se cree y de la funcionalidad que debe proporcionar. Las extensiones de procesamiento de datos suelen ser las más fáciles de crear, mientras que las extensiones de representación pueden resultar muy difíciles si se crean para admitir todo el esquema del informe.

Para crear un informe, se debe crear una Report Definition mediante el Report Designer o el Report Builder. La tool de creación que se utilice depende de los requisitos del informe y del nivel de conocimiento del usuario sobre técnicas de creación de reportes.

Administrar reportes y otros elementos  

Una de las principales ventajas de utilizar Reporting Services es la posibilidad de administrar reportes y elementos relacionados, como carpetas, conexiones de orígenes de datos y recursos, desde una ubicación centralizada. Se puede definir la seguridad, establecer propiedades y programar operaciones. También se puede crear programaciones compartidas y orígenes de datos compartidos, y ponerlos a disposición de todos los usuarios. Para administrar reportes y el entorno de reportes, se debe utilizar SQL Server Management Studio o el Report Manager. La administración de reportes comprende las siguientes tareas:

  Organizar el entorno de reportes agregando nuevas carpetas para almacenar colecciones de reportes.

  Habilitar características como Mis reportes, el historial del informe y la entrega de reportes por e-mail (Push).

  Proteger el acceso a carpetas y reportes mediante la asignación de usuarios y grupos a Roles..

  Generar las programaciones compartidas y los orígenes de datos compartidos que desea poner a disposición de todos los usuarios.

Tanto los usuarios como los administradores del Report Server pueden administrar reportes, pero no del mismo modo. Los usuarios pueden publicar y administrar reportes en un área de trabajo personal denominado Mis reportes. Los administradores del Report Server pueden administrar el espacio de nombres completo de carpetas del servidor de reportes. La posibilidad de realizar tareas de administración depende de los permisos de usuario.  

Obtener acceso a reportes y entregarlos  

Reporting Services ofrece dos métodos para obtener acceso a los reportes y entregarlos:

ü  Pull: El acceso a petición permite a los usuarios seleccionar los reportes desde una tool de visualización de reportes. Se puede utilizar el Report Manager, un WebPart de Microsoft SharePoint o un Browser.

ü  Push: El acceso basado en suscripciones genera y entrega reportes automáticamente a un destino. Puede entregar reportes a una bandeja de entrada de e-mail o a un recurso compartido de archivos.  

Para ver un informe a petición, se puede buscar o seleccionar un informe de una jerarquía de carpetas, denominada espacio de nombres de carpetas del Report Server. Para recibir reportes automáticamente, puede suscribirse a un informe específico. Cuando se ejecuta el informe, el usuario recibe una notificación que le indica que el informe está disponible o recibe una copia del mismo en un mensaje de e-mail.(Push Delivery of reports by Using e-mail)

Los administradores del Report Server pueden generar Data-Driven Subscriptions que proporcionan datos a un grupo numeroso de personas. Las Data-Driven Subscriptions generan una lista de destinatarios en tiempo de ejecución. En las Data-Driven Subscriptions, la configuración de entrega se genera a partir de los datos almacenados (por ejemplo, los de una base de datos de empleados) cuando se desencadena la suscripción.

Reporting Services es compatible con varios formatos de visualización. Al principio los reportes se muestran en formato HTML, pero, una vez representado un informe, se puede volver a mostrar en un formato diferente como Excel o PDF.

Puede instalar servidores de reportes en configuraciones de servidor único (Single Server), distribuidas (Remote Database Server)  y agrupadas (Web Farm).

Jonnathan De La Barra Acalorado

Business Intelligence

Nuevo Hyperion ya disponible

Desde la compra de Hyperion por parte de Oracle, se ha venido sucediendo una auténtica revolución en el campo del Business Intelligence, en donde parecía que lo más importante eran los movimientos empresariales y el ajuste de licencias, precios, plantillas, cargos, etc….

Pero poco a poco, van apareciendo nuevas versiones de cada uno de los productos. El mas reciente es Hyperion:

Hyperion Essbase

Se acaba de presentar la nueva version de Oracle EPM System 11.1 (antiguo Hyperion Systems 9.5), y ya esta disponible para descargar.

Esta versión es inicialmente sólo para Windows y tiene mejoras en el IDE de Essbase con Essbase Studio. Ahora la cuestión es como unimos esto con el antiguo OLAP de Oracle (Express Server, ahora AW) y con la version Enterprise basada en los componentes de Siebel. Un puzzle, todavía dificil de encajar.

Ahora bien… la pregunta es: Cómo se integrará Hyperion Essbase con Oracle Business Intelligence Enterprise Edition (OBIEE)?

Una de las preguntas que mas se hacen los clientes actuales de Hyperion es como se integrarán sus soluciones en el nuevo OBIEE. Si funcíonará correctamente, si habrá que hacer algún tipo de migración, etc…
La respuesta parece ser que habrá dos formas de posible integración:

– Essbase será una fuente mas para OBIEE, permitiendo combinar análisis MOLAP y ROLAP.
– Y al revés, sobre todo para los cubos financieros, que OBIEE sea una fuente para Essbase y de ahí se carguen lso datos.

Muy abiertas las posibilidades como veis, lo que puede inducir a ciertas dudas sobre su concrección o mejor opción para abordar la integración.
Se trata de encontrarle un hueco a la potente tecnología y base instalada de Essbase (planning), y el lanzamiento de la nueva aplicación de desarrollo y la posibilidad de hacer ‘drill to detail’ van en la buena linea.

En cualquier caso, un tema esta claro. En BI, con la variedad de tecnologías y aplicaciones existentes es muy dificil esperar una integración completa y habrá que analizar herramienta a herramienta que es lo mas conveniente para cada cliente.
Por nuestra parte (que seguimos añorando el viejo MOLAP Express Server, ahora AW… lo seguimos viendo como perdedor en este proceso de integración), pero puede ser una buena oportunidad para conocer el peso que tendrán las antiguas Siebel e Hyperion en la nueva linea BI de Oracle.

Business Intelligence

SQL Server Integration Services (SSIS) 10 Quick Best Practices

1.      La característica más deseada en el desarrollo de paquetes SSIS es la reusabilidad. En otros aspectos, podemos llamarles como los paquetes estándar que pueden ser reutilizados durante el desarrollo de diferentes componentes ETL. En SSIS, esto puede fácilmente lograrse mediante características de template. SSIS template packages son paquetes reutilizables que se pueden usar en cualquier proyecto SSIS en cualquier número de veces.

Nota: Por default  son almacenados en:

Drive:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\ProjectItems\DataTransformationProject\DataTransformationItems

2.      Evite utilizar el punto (.) en la Convención de nomenclatura para sus nombres de paquete. El Punto (.) en la  Convención de la nomenclatura  a veces se confunde con el Convenio de  nombres de objeto de SQL Server y por lo tanto debe evitarse. Buen enfoque sería utilizar subrayado (_) en lugar de utilizar el punto. También asegúrese de que los nombres de paquete no debe exceder  más de 100 caracteres. Durante la implementación del paquete en SQL Server, es notificado que  cualquier carácter más de 100 es eliminado automáticamente del nombre del paquete. Esto podría resultar que el paquete SSIS falle durante el tiempo de ejecución, especialmente cuando se utiliza “Execute Package Tasks” en el paquete.

3.      El flujo de datos desde upstream a downstream en un paquete es una tarea intensiva de memoria, en la mayoría de los pasos y nivel de componente tenemos que  comprobar cuidadosamente y estar seguros de que las columnas innecesarias no sean pasadas al downstream. Esto ayuda a evitar la sobrecarga de tiempo de ejecución adicional del paquete y a su vez mejora el rendimiento general de la ejecución del paquete.

4.      Al configurar cualquier administrador de conexión OLEDB como una fuente de datos, evitar el uso de  tabla o vista como modo de acceso de datos, esto es similar a “SELECT * FROM <TABLE_NAME>”, y como la mayoría de nosotros sabe, SELECT * es nuestro enemigo, esto toma todas las columnas en cuenta, incluidos aquellos que no son incluso necesarios. Siempre intentar usar  SQL Command para el modo de acceso a datos e incluir solamente nombres de las columnas necesarias en su sentencia T-SQL SELECT. De esta manera puede bloquear el paso de columnas innecesarias al downstream.

5.      En sus tareas de flujo de datos, utilice el administrador de conexión de archivos planos cuidadosamente, crear el Flat File connection manager con configuración predeterminada utilizará tipo de datos String [DT_STR] por defecto para todos los valores de columna. Esto siempre podría no ser una opción correcta porque puede tener algunas columnas de origen de tipo numérico, entero o booleanas, pasarlos como String a downstream tomaría espacio en memoria innecesaria y puede causar algún error en las etapas posteriores de la ejecución del paquete.

6.      La ordenación de datos es una operación de mucho tiempo, en SSIS puedes ordenar los datos procedentes de upstream utilizando Sort transformation, sin embargo se trata de una tarea intensiva de memoria y en varias ocasiones el resultado es degradante en el rendimiento general de la ejecución del paquete. Una buena práctica, sabemos que los datos vienen en la mayoría de las tablas de base de datos de SQL Server, es mejor realizar la operación de ordenación a nivel de base de datos donde se puede realizar la ordenación dentro de la consulta. Esto es en efecto bueno, porque el ordenamiento en la base de datos de SQL Server es mucho más refinado y ocurre a nivel de SQL Server. A su vez el resultado general mejora el rendimiento en la ejecución del paquete.

7.      Durante el desarrollo de paquetes SSIS, la mayor parte del tiempo uno tiene que compartir su paquete con otros miembros del equipo o uno tiene que implementar el mismo paquete en cualquier otro sistema de desarrollo, UAT o producción. Algo que un desarrollador debe asegurarse es de utilizar el nivel de protección del paquete correcto. Si alguien va con el nivel de protección del paquete predeterminado EncryptSenstiveWithUserKey entonces el mismo paquete podría no ser ejecutado como se esperaba en otros entornos porque  el paquete fue cifrado con una clave personal de usuario. Para hacer que la ejecución del paquete sea suave a través de otros entornos, uno debe primero comprender el comportamiento de propiedad de nivel de protección del paquete.

                DTSProtectionLevel Enumeration

                Namespace: Microsoft.SqlServer.Dts.Runtime
                Assembly: Microsoft.SqlServer.ManagedDTS (in microsoft.sqlserver.manageddts.dll)

                DontSaveSensitive: La Información sensible no es guardada en el paquete

                EncryptAllWithPassword: Cifra el paquete entero utilizando una contraseña

                EncryptAllWithUserKey: Cifra el paquete entero utilizando claves basados en el perfil del usuario. Sólo el mismo usuario utilizando el mismo perfil puede cargar el paquete.

                EncryptSensitiveWithPassword: Cifra sólo la información sensible que contiene en el paquete con una contraseña. DPAPI se utiliza para este cifrado

                EncryptSensitiveWithUserKey: Cifra todo el paquete con claves basados en el usuario actual.  Sólo el mismo usuario utilizando el mismo perfil puede cargar el paquete. Si un usuario diferente abre el paquete, la información confidencial se sustituye por los espacios en blanco. DPAPI se utiliza para este cifrado.

                ServerStorage: Cifra el paquete en una base de datos de MSDB de SQL Server. Esta opción es compatible sólo cuando un paquete se guarda en SQL Server. No es compatible cuando se guarda un paquete al sistema de archivos. El control de acceso de que quien puede descifrar el    paquete está controlado por los roles de base de datos SQL Server.

                En general, para evitar el error de implementación del paquete de un sistema a otro sistema, establezca nivel de protección de paquete en DontSaveSenstive.

8.      Esto es una buena práctica,  Utilizar Sequence Containers en paquetes SSIS para agrupar los distintos componentes en el nivel de Control Flow. Esto ofrece un conjunto rico de Facilidades

          Proporciona un alcance para las variables que puede utilizar un grupo de tareas relacionadas y contenedores

          Proporciona la facilidad para administrar propiedades de múltiples tareas estableciendo la propiedad a nivel de Sequence container

          Proporcionar facilidad para establecer el nivel de aislamiento de transacción en nivel de Sequence container

9.      Si diseña una solución ETL para una necesidad de negocio para una empresa pequeña, mediana o grande, siempre es bueno tener una característica de reinicio de los paquetes con errores desde el punto del error. SSIS tiene una característica llamada Checkpoint para soportar el reinicio de paquetes con errores desde el punto del error. Sin embargo, tiene que configurar la característica de Checkpoint a nivel del package.

                Las siguientes propiedades de paquete se debe establece para implementar el punto de control  (Checkpoint)

          CheckpointFileName: Especifica el nombre del archivo de punto de control

          CheckpointUsage: Especifica si se utilizan los puntos de control.

          SaveCheckpoints: Indica si el paquete guarda los puntos de control. Esta propiedad debe establecerse en True para reiniciar un paquete desde un punto de error.

10.  Execute SQL Task es nuestro mejor amigo en SSIS; podemos ejecutar uno o múltiples instrucciones de SQL a la vez, todos los stored procedures que contenga nuestra DB, volver a crear nuestras tablas de hecho y de dimensiones antes de cargar datos en ellos . La belleza de este componente es que puede devolver resultados en diferentes maneras por ejemplo, una fila individual, conjunto de resultados y XML. Puede crear diferente tipo de conexión utilizando este componente como OLEDB, ODBC, ADO, ADO.NET y el tipo de SQL Mobile, etc.. Yo prefiero usar este componente la mayor parte del tiempo con mi ForEach Loop container para definir el bucle de iteración sobre la base de resultado retornado por el Execute SQL Task.

Jonnathan De La Barra Sonrisa