“Año De La Consolidacion Del Mar De Grau”

Escuela De Ingeniería De Sistemas

Alumno

:

Curso

: Inteligencia De Negocios

Tema

:

Modelo Dimensional

Profesor

:

Garay Mendoza

Ciclo

Romero Aguirre Cesar Antonio

:

Jose

VIII

Sullana-2016

Diagrama de base de datos relacional
El Diseñador de diagramas de base de datos es una herramienta visual que le permite
diseñar y visualizar una base de datos a la que está conectado. Cuando diseña una base de
datos, puede utilizar el Diseñador de bases de datos para crear, editar o eliminar tablas,
columnas, claves, índices, relaciones y restricciones. Para ver una base de datos, puede
crear uno o varios diagramas que muestren algunas o todas las tablas, columnas, claves y
relaciones de la base de datos.
Cuando diseña una base de datos, puede utilizar el Diseñador de bases de datos para crear,
editar o eliminar tablas, columnas, claves, índices, relaciones y restricciones. Para ver una
base de datos, puede crear uno o varios diagramas que muestren algunas o todas las tablas,
columnas, claves y relaciones de la base de datos.
El esquema de una base de datos (en inglés, database schema) describe la estructura de
una base de datos, en un lenguaje formal soportado por un sistema de gestión de base de
datos (DBMS). En una base de datos relacional, el esquema define sus tablas, sus campos
en cada tabla y las relaciones entre cada campo y cada tabla.
El Diseñador de bases de datos es una herramienta visual que permite diseñar y ver una
base de datos a la que está conectado. Cuando diseña una base de datos, puede utilizar el
diseñador de bases de datos para crear, editar o eliminar tablas, columnas, claves, índices,
relaciones y restricciones. Para ver una base de datos, puede crear uno o varios diagramas
que muestren algunas o todas las tablas, columnas, claves y relaciones de la base de datos.

Requerimiento de Usuario
Por consiguiente, los requerimientos del usuario no se deben definir utilizando un modelo
de implementación. Deben redactarse utilizando el lenguaje natural, representaciones y
diagramas intuitivos sencillos.Sin embargo, pueden surgir diversos problemas cuando se
redactan en lenguaje natural: falta de claridad, confusión de requerimientos y conjunción
de requerimientos.
Son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que
el sistema provea y de las restricciones bajo las cuales debe operar. Describen los
requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los
usuarios del sistema que no posean un conocimiento técnico detallado. Únicamente
especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las
características de diseño del sistema.

Granuralidad
El concepto de granularidad parte del principio que es más fácil reutilizar unidades más
pequeñas dado, que de este modo, es posible seleccionar aquellas partes que nos interesan
y descartar aquellas que no son adecuadas en el contexto donde nos encontramos. Además
la granularidad describe el nivel de detalle de la base de datos en datawarehouse. La
determinación del nivel de granularidad es uno de los puntos más importantes del
modelado lo cual impacta directamente en el tamaño de la base de datos.

Hechos y dimenciones
Este tipo de modelo de datos consta principalmente de dos tipos de elementos:
HECHOS: Son el objeto de los análisis y están relacionados con las dimensiones. Son
tablas muy grandes y suelen estar desnormalizadas. Se a menudo incluyen diferentes
agregaciones como máximo, mínimo, media.

Los hechos contiene los datos de estudio y las dimensiones contienen los metadatos sobre
dichos hechos. Si la información necesita disponer de varios niveles de granularidad se
crean jerarquías con las dimensiones. Por ejemplo la jerarquía fecha podría ser “día –
semana – mes – trimestre – año”. Las jerarquías de las dimensiones presentan relaciones
n-1 de manera que un valor de un nivel sólo puede ser agrupado por un único valor de
cada nivel inmediatamente superior en la jerarquía. Esto facilita de manera rápida y
sencilla el profundizar en el nivel de detalle (drill-down), disminuir el detalle(roll-up),
selección (dice), proyección (slice) o pivotaje en las dimensiones (pivot), que son propios
de los informes obtenidos a partir de data warehouse.
En una empresa de grandes dimensiones y sobre todo cuando hay múltiples data marts,
es muy importante analizar las dimensiones previamente con las personas claves de las
fuentes de datos, las personas claves de los datos finales y los diseñadores de otras
personas involucradas en diseños corporativos de aplicaciones (data mart, generadores de
informes, …), ya que las fuentes condicionarán los datos a proporcionar y las dimensiones
se debería reutilizar en las distintas tablas de hechos de distintos data mart. Una dimensión
tiempo debería de tener el mismo diseño en todos los data marts, porque si no cuando se
integren será mucho más complejo. Es una decisión tanto técnica como política.

DIMENSIONES: Representan factores por lo que se analiza un determinado área del
negocio. Son pequeñas y usualmente están desnormalizadas.
Tabla de Hechos
Las tablas de hechos almacenan los datos utilizados para calcular las medidas en informes de
medidas. Las tablas de hechos se llenan solo a través de transformaciones de ETL. Para identificar

un objeto de negocio como una tabla de hechos, en el Modelador de datos, establezca el indicador
Gestionado externamente en la definición de objeto de negocio de tabla de hechos.

Denominamos “hechos” a los indicadores de negocio. Por ejemplo, son “hechos” las
ventas, los pedidos, los envíos, las reclamaciones, las compras, etc. Es decir, son todas
aquellas medidas numéricas que incluiremos en nuestro sistema Business Intelligence.
Técnicamente, una tabla de hecho es la tabla central de un modelo en estrella. En el
siguiente diagrama, la tabla de ventas es la tabla de hechos:
Definiendo Medidas y Dimensiones
Bien ahora si definiremos lo que es una Medida y lo que es una Dimensión. Un DWH
responde a la solución de un problema, algo que permite medir gestión: ¿Qué necesito
ver, medir o evaluar y Cómo necesito analizarlo?
El Qué lo constituyen un sin número de cosas como; por ejemplo en el caso de un Control
de Calidad: la cantidad de unidades producidas, la cantidad de unidades defectuosas, el
costo de producción entre otras. Estas últimas mencionadas lo constituyen las medidas o
hechos (facts en Inglés). En un Data WareHouse son llamados hechos.
Una vez identificado lo que el usuario desea medir la siguiente pregunta corresponde a
Como analizará esta medida. Volviendo al Control de Calidad, las respuesta podrían
corresponder a analizar la data: en un periodo de tiempo determinado, para un producto
especifico.