En cualquier proyecto de este tipo debemos tener una o varias fuentes de datos (Data Sources), que nos sirvan para obtener la información que vamos a utilizar en los cubos y dimensiones posteriormente. Analysis Services nos permite la posibilidad de tener varios orígenes de datos y consolidarlos.Una vez que nos conectamos de forma independiente a cada uno de los orígenes de datos, creando un Data Source (DS) para cada uno de ellos, como hemos indicado antes, podemos consolidar la información, construyendo un esquema lógico, basado en uno o varios Data Sources, a través del Data Source View (DSV).

Un DataSource View es un esquema lógico en el que podemos incluir:

  • Cálculos con Nombre (Named Calculations), son columnas calculadas en base a otras columnas, a las que asigno un nombre. Estos cálculos deben ser escritos en el dialecto SQL del origen de datos, es decir, si estoy accediendo a Oracle, tendré que usar el dialecto SQL de Oracle, si estoy accediendo a SQL Server tendré que utilizar Transact-SQL, y así sucesivamente según el origen. También lo podemos utilizar simplemente para renombrar columnas con nombres más amigables.
  • Consultas con Nombre (Named Queries), son vistas sobre una o varias tablas. Nos pueden servir, por ejemplo, en el caso de que no tengamos un Data Warehouse, para hacer un modelado en estrella o en copo de nieve a partir de un origen normalizado. Nos ofrecen todas las posibilidades de la instrucción SELECT del dialecto SQL que estemos utilizando. Ejemplos de tareas que podemos hacer con ellas serían: desnormalizar, obtener un subconjunto de datos, poner alias para obtener nombres amigables, combinar datos de varias tablas, etc.
  • Relaciones a nivel lógico, es una validación de integridad referencial a nivel lógico. Nos permiten crear Foreign Keys lógicas si éstas no existiesen en el origen. Aunque en los sistemas transaccionales no es habitual, además de ser una mala práctica, el que nos encontremos con la ausencia de Foreign Keys, en los Data Marts o Data Warehouses es más habitual, y no es considerado una mala práctica, sino que tiene sus pros y sus contras, y en unos casos se opta por la creación de FKs y en otros no. En caso de no disponer de Foreign Keys las podremos crear a nivel lógico.
  • Claves primarias lógicas, aun cuando no hay una primary key, podemos crearla a nivel lógico. Con las Primary Keys ocurre lo mismo, en caso de no existir en el origen, podríamos crearlas a nivel lógico en el Data Source View. Esto ya es algo menos habitual, porque tener tablas sin Primary Key no es una buena práctica, ni en sistemas transaccionales, ni en Data Marts o Data Warehouses. Aun así, si nos encontrásemos un origen sin Primary Keys, siempre nos queda la posibilidad de crearlas a nivel lógico. Analysis Services requiere una Primary Key por cada tabla para construir los queries, bien sea física o lógica.

El Data Source View, realmente nos será de poca utilidad en el caso de tener un solo origen de datos y que además sea un Data Mart o Data Warehouse, ya modelado en estrella (o incluso si es un snowflake). Pero si no lo tuviésemos y quisiéramos consolidar información de diferentes fuentes e incluso modelar en base a vistas nuestra base de datos normalizada, para obtener un modelo en estrella, nos será de gran utilidad.

Imaginemos, por ejemplo, que nuestro cubo va a tener como origen de datos dos bases de datos diferentes. No habrá ningún problema en integrar en esta vista de origen de datos (DSV) que las dimensiones Geografía y Tiempo vengan de un Data Source, y las dimensiones Producto y Cliente vengan de otro Data Source. Como hemos comentado antes, podemos definir relaciones lógicas. Para establecer una relación, que será siempre del tipo 1:M, necesitamos tener Primary Key, y en el caso de no tenerlas, podemos crear Primary Keys lógicas. También podemos crear campos calculados; imaginaos que tenemos la cantidad, el descuento y el precio, pero no tenemos el importe, que es: (cantidad – decuento) * precio. En ese caso podemos crear en el DSV una columna calculada con dicha fórmula. Así como renombrar columnas con nombres más amigables.

Con un Data Source View podemos también hacer justo lo contrario, es decir, crear una vista que nos simplifique el origen de datos. Imaginemos que nuestro Data Source es una base de datos con 500 tablas con un complejo modelo de datos, y que para el problema que estamos resolviendo actualmente, sólo necesitamos acceder a 15 tablas. Podemos utilizar el DSV para mostrar sólo las tablas que vamos a utilizar en nuestro proyecto.

Un cubo o una dimensión, siempre tendrá como origen un Data Source View, y éste tendrá, a su vez, como origen uno o varios Data Sources.

Figura 1 – Data Sources, Data Source View y Cubo

Figura 1 – Data Sources, Data Source View y Cubo

 

Demo incluida en el curso online

Si estás siguiendo el curso, del cual este eBook es material complementario, accede al video de la ‘Demo SSAS 01B‘, en el que se muestra con detalle la creación de Data Sources y Data Source Views.

 

Salvador Ramos

Consultor, Formador y Mentor en Business Intelligence. SQL Server MVP.
Director de Formación en SolidQ.
Microsoft MCSE 2012: Business Intelligence.

Latest posts by Salvador Ramos (see all)