Skip Ribbon Commands Skip to main content

Posts (Showing 48 Results)

 
3 Aug 2010

Como ya sabéis, en SQL Server, a nivel del motor relacional tenemos dos tipos de autenticación: Windows y Mixta. En cambio en Analysis Services sólo disponemos de autenticación Windows.

Si nos encontramos en una máquina que no está en el dominio, y por tanto no nos hemos logeado en ella con nuestro usuario y password del dominio, no tendríamos a priori acceso a Analysis Services.

Veamos cómo configurar la conexión desde Excel a Analysis Services desde una máquina que no está en el dominio.

En primer lugar, vamos, como es habitual, a crear la nueva conexión

image

Y una vez seleccionada la opción ‘From Analysis Services’ introduciremos los datos solicitados

image

Allí, introduciremos la IP y el puerto por el que está escuchando la instancia a la que nos queremos conectar. Así como el dominio\usuario y su password.

Nota: Tened en cuenta que cuando tenemos un nombre de instancia, cada vez que se inicia el servicio de Analysis Services se asigna un puerto libre que puede ser diferente. Esto se puede cambiar en las propiedades de la instancia, sustituyendo el valor de ‘Port’, en vez de 0, poner un puerto, en nuestro ejemplo el 2800. Para ello, desde Management Studio, pulsamos botón derecho ‘Properties’ sobre la instancia, y nos aparece la siguiente pantalla

image

A continuación se nos muestran las bases de datos, y los cubos y perspectivas de la base de datos seleccionada.

image

Una vez seleccionada, ya por último nos queda indicar que guarde la password en el archivo de conexión, marcando el check correspondiente, y respondiendo ‘yes’ a la advertencia de seguridad

image

Para evitar que la password quede en un futuro almacenada en el archivo .odc, lo que tenemos que hacer es, una vez que hayamos terminado su uso, borrar el archivo .odc o volver a crear una conexión que lo sobreescriba indicando que no se guarde la password.

Y por último, pulsamos en el botón ‘Finish’ y continuamos con los pasos habituales del acceso a Analysis Services desde Excel.

Ni que decir tiene, que el firewall debe estar configurado para permitir el acceso por ese puerto.

 
 
18 May 2010
by Salvador Ramos on 18/5/2010 10:01 AM
Language: Spanish

Como parte de la migración a Sharepoint 2010, este blog cambia de dirección; por lo que en vez de ser http://blogs.solidq.com/ES/BICorner se convertirá en http://blogs.solidq.com/BICorner.

 
 
22 Apr 2010
by Alexandre Bernárdez on 22/4/2010 5:35 PM
Language: Spanish

Objetivo

El objetivo es cargar datos en un SQL Server 2008 utilizando SSIS siendo nuestro origen de datos una BBDD Teradata.

Data Sources

Crearemos dos Data Sources en SSIS, uno que leerá de Teradata y otro que escribirá en SQL Server 2008. Para poder utilizar un origen OLE DB de Teradata, deberemos instalarnos previamente un conector OLE DB para Teradata, se puede descargar desde el centro de descargas de la página Web de Teradata:

http://www.teradata.com/DownloadCenter/

Data Source Teradata:

image

Data Source SQL Server 2008:

image

 

Data Flow

Este objeto de SSIS nos permitrá crear un flujo de datos para realizar la inserción de datos desde Teradata a SQL Server. Con un Data Flow muy sencillo seremos capaces de trasladar los datos.

Como se puede ver en el siguiente Data Flow, tenemos dos orígenes de datos OLE DB (BBDD Teradata y SQL Server 2008) y también tenemos un “Data Conversion” para realizar conversiones de tipos de datos de una plataforma a otra.

image

Comprobamos su ejecución y vemos que lo leído de Teradata y lo escrito en SQL Server 2008 es lo mismo, esto lo podemos comprobar mismamente en la ejecución del Data Flow que nos va indicando (como se muestra en la figura) cuantas filas son afectadas en cada uno de los pasos, y también con un visor podemos ver como son los datos obtenidos desde origen, es una gran ayuda a la hora de utilizar SSIS.

 

image

Comprobamos la integridad de los datos en SQL Server:

image

 

 

Equivalencia Tipos de Datos

A continuación se muestran tres tablas con la correspondencia de los tipos de datos más utilizados:

Tipo Fecha:

TERADATA

SSIS

SQL SERVER

Date

Database date [DT_DBDATE]

Date

Time(0)

Database time [DT_DBTIME]

Time(0)

Timestamp(0)

Database timestamp [DT_DBTIMESTAMP]

Datetime

Tipo Carácter:

TERADATA

SSIS

SQL SERVER

Char(n) - Latin

String [DT_STR]

Char(n)

Char(n) - Unicode

Unicode String [DT_WSTR]

Nchar(n)

Varchar(n) - Latin

String [DT_STR]

Varchar(n)

Varchar(n) - Unicode

Unicode String [DT_WSRT]

Nvarchar(n)

En este tipo de datos vemos por ejemplo que en Teradata a cada uno de los tres tipos de datos se le puede aplicar como un atributo (Latin,Unicode), este atributo es la causa de que luego se transforme en un tipo de datos u otro tanto en SSIS como en SQL Server.

Tipo Numérico:

TERADATA

SSIS

SQL SERVER

Integer

Four-Byte signed integer [DT_I4]

Int

Smallint

Two-Byte signed integer [DT_I2]

Smallint

Byteint

Single-Byte signed integer [DT_I1]

Smallint

Real

Float [DT_R4]

Real

Doubleprecision

Double-precision float [DT_R8]

Float

Float

Double-precision float [DT_R8]

float

Decimal(n,m)

Decimal [DT_DECIMAL]

Decimal(n,m)

Numeric(n,m)

Numeric [DT_NUMERIC]

Numeric(n,m)

Problemas encontrados

Hay que tener cuidado con la correspondencia de los tipos de datos en una y otra plataforma, y asegurarse de no perder datos.

 
 
26 Mar 2010
by Carlos Martínez on 26/3/2010 12:10 PM
Language: Spanish

El Administrador de Informes (Report Manager) nos permite acceder de forma sencilla a los informes que tenemos desplegados en el servidor pero… ¿y si nos conectamos de forma segura al servidor (https)?

El comportamiento del Administrador es exactamente igual, salvo que como usuarios nos habremos autenticado para acceder al propio servidor. Sin embargo, sí nos podemos encontrar algún problema a la hora de guardarnos estos informes. Cuando queremos exportar el informe, por ejemplo a Ms Excel, puede que no lo consigamos, obteniendo un error que nada tiene que ver con el administrador de informes.

clip_image002

Fig. 1. Error que se produce al tratar de exportar.

Resulta que si se trabaja con una conexión segura y las páginas están cifradas, no se guardan por defecto en caché (archivos temporales de Internet) las páginas, y  al hacer el renderizado no se pueden leer los datos al no estar guardados físicamente. De ahí el error. Por tanto, la solución no pasa por ninguna configuración de Reporting, sino del propio Internet Explorer.

Abriremos las Opciones de Internet Explorer, en el menú Herramientas. Una vez allí buscamos la pestaña de propiedades avanzadas, y en ésta el grupo de Seguridad. Entre las diversas opciones configurables para la seguridad, encontraremos un check o cuadro de selección con el rótulo 'No guardar las páginas cifradas en el disco'. Por defecto este valor está seleccionado, y es lo que provoca que no podamos hacer nuestro export.

clip_image004

Fig. 2. Herramientas de Internet > Opciones de Internet > Avanzadas > Seguridad. Si está marcado no guardará datos en caché.

Lo deseleccionamos y aplicamos el cambio.

clip_image006

Fig. 3. Nos interesa que se guarden las páginas en disco.

Si volvemos a probar ya tendremos la funcionalidad de exportar informes funcionando. 

Podemos encontrar el problema en los foros de msdn

 
 
11 Mar 2010
by Pablo A. Ahumada on 11/3/2010 11:34 PM
Language: Spanish

 

Un paseo rápido por Performance Point Services buscando diferencias con la versión 2007

Desde el punto de vista de arquitectura el cambio es grande, no tanto si lo vemos desde el punto de vista de funcionalidad.

clip_image002

Diagrama de despliegue de arquitectura de Performance Point Services. Absolutamente integrado en SharePoint 2010.

Para llegar de forma rápida a lanzar Dashboard Designer me he creado un colección de sitos con la plantilla de Business Intelligence Center, lo que me permite disparar el instalador de Dashboard Designer por primera vez, aun estoy buscando el equivalente a la pagina central donde se podía hacer la distribución de Dashboard Designer y el acceso directo a la página de Preview, no localizo el sitio de Preview, seguirá existiendo?

clip_image004

Look & Feel  muy similares a la versión 2007, la Jerarquía de objetos de la solución también, los orígenes de datos permanecen, excepto AS 2000 y ODBC tal como se anuncia, echo de menos BW SAP 3.x (Fue un sueño que duró poco).

En la cinta home hay una opción nueva para importar elementos de un Dashboard existente, el nuevo formato del Dashboard ahora se almacena en extensión *.ddwx, he localizado bastante ayuda sobre como migrar soluciones y objetos existentes en PPS Monitoring 2007, pero no para las basadas en OWC 2003, lógico ya que estaban marcadas para morir…, tampoco veo el análisis de tendencia, pero si un “KPI details” que no conocía en los informes.

clip_image006

clip_image008

Al crear un nuevo Scorecard, tengo opción de ponerlo en distintas listas de SPS 2010

clip_image010

Por el resto de cosas por donde he pasado tiene un aspecto muy similar a como estaba, claro pero ahora embebido completamente en SPS2010 con todo lo que eso implica a nivel de seguridad y de control de versionado, de seguridad de acceso a orígenes de datos Etc.

Finalmente la opción de despliegue es muy parecida a la versión anterior.

clip_image012

Despliegue realizado y Dashboard listo para consumir desde Webparts.

También he visto algunos cambios en las propiedades de la columna del actual y target en el Scorecard

clip_image014

Las propiedades de conexión al servidor siguen en el mismo sitio, pero ahora ya sin posibilidad de gestionar los roles de seguridad de servidor, estos se han ido a SharePoint.

clip_image016

Seguiremos buscando novedades que contar.

Más información en:

http://technet.microsoft.com/es-es/library/ee661741(office.14).aspx

 
 
5 Mar 2010
by Javier Torrenteras on 5/3/2010 12:22 PM
Language: Spanish

En base a mi experiencia he visto que uno de los tipos de parámetro más utilizado en la mayoría de los informes es el calendario. Es raro encontrar un informe que no tenga un o varios parámetros para identificar un rango o un momento en el tiempo que identifique los datos a mostrar por los informes.

Cuando el informe está atacando al motor relacional, utilizar el valor devuelto por el parámetro calendario es automático, podemos utilizarlo directamente contra las columnas datetime que se utilizan en nuestra consulta relacional, sin embargo, cuando el informe está utilizando una consulta MDX su uso se complica algo más.

En el siguiente ejemplo, vemos como se ha definido a través del asistente un filtro basado en la dimensión tiempo y que se modificará a través de parámetros en el informe.

Ilustración 1 - Identificación de parametros en el asistente

Al marcar los check-boxes que identifican el filtro como parámetro veremos que por cada uno de los parámetros que se definen, se crea automáticamente:

  1. Un dataset oculto en el informe que devuelve el conjunto de miembros de la dimensión utilizada para filtrar por cada uno de los parámetros.
  2. Un parámetro en el informe que utiliza el dataset para mostrar la jerarquía de tiempo al usuario.

Ilustración 2 - Arbol de objetos en el area de datos del informe

Cuando la dimensión es el tiempo dicho dataset devuelve el rango de fechas que tengamos cargados en nuestra dimensión visualizado en el árbol jerárquico que se haya definido. Esta solución, aunque válida desde el punto de vista técnico, presenta varios problemas; Por un lado no suele agradar al usuario final y por otro puede provocar problemas de rendimiento si tenemos un rango de fechas muy grande cargado en la dimensión tiempo. Estos dos problemas se pueden resolver fácilmente si la clave de la dimensión tiempo está basada en una clave inteligente, es decir, la clave de cada registro en la dimensión tiempo identifica de forma visual la fecha del registro y no es un mero índice incremental (la clave del registro es un entero que representa la concatenación del año, el mes y el dia con el formato yyyymmdd).

Si nuestra dimensión sigue esta regla ya estamos preparados para utilizar parámetros datetime en el informe y podremos seguir los siguientes pasos para su correcta implementación:

  1. Eliminar el dataset que ha creado SSRS para evitar que se ejecute y se produzca una demora en la presentación del informe al usuario. (datasets FromDateCalendar y ToDateCalendar que aparecen en la Ilustración 2)
  2. Editar el parámetro para indicar que no utilice ningún dataset como fuente de origen a la vez que indicamos que el parámetro es de tipo datetime.
  3. Editar los parámetros del dataset principal (AsistenciasSanitarias en nuestro ejemplo) para que utilicen una expresión que identifique el miembro de la dimensión tiempo asociado a la fecha seleccionado por el usuario. En nuestro ejemplo las expresión quedan como sigue:

Parameter Value para el Parámetro FromDateCalendar:

="[Date].[Calendar].[Date].&[" + year(Parameters!FromDateCalendar.Value).ToString + month(Parameters!FromDateCalendar.Value).ToString("00") + day(Parameters!FromDateCalendar.Value).ToString("00") + "]"

 

Parameter Value para el Parámetro ToDateCalendar:

="[Date].[Calendar].[Date].&[" + year(Parameters!ToDateCalendar.Value).ToString + month(Parameters!ToDateCalendar.Value).ToString("00") + day(Parameters!ToDateCalendar.Value).ToString("00") + "]"

 

Una vez seguidos estos pasos, la experiencia del usuario se habrá incrementado drásticamente al poder utilizar el control calendario (Ilustración 4) para poder filtrar los datos que desea visualizar en lugar de tener que navegar por una lista de fechas (Ilustración 3).

Ilustración 3 - Navegación por miembros de la dimensión

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 Ilustración 4 - Control calendario

 

Podéis ver un video explicativo (está en inglés) a través de este enlace

mms://solidq.com/Using%20Date%20control%20in%20SSRS%20with%20MDX%20datasets.wmv

 
 

 About this blog

 
About this blog
Your Name