ıllı Internet y Tecnologías de la Información (2018)

internet, Hosting, dominios, seo, antivirus, banco de imágenes, páginas web, tiendas online

[Enciclopedia Online Gratuita] Diccionario de Internet y Tecnologías de la Información y la Comunicación (TIC):

ıllı Tabla de dimensión wiki: info, historia y vídeos


La información contenida en esta web debe ser considerada como información general, de carácter formativo, educativo o divulgativo, y no puede ser utilizada o interpretada como consejo o diagnótico médico, psicológico o de ningún otro tipo. Es posible que algunos datos mostrados no esten actualizados. Por ello, en caso de duda lo recomentable es consultar a un experto cualificado.


 


 

videos internet

salud  Tabla de dimensión 


Cada dimensión puede referirse a conceptos como 'tiempo', 'productos', 'clientes', 'zona geográfica', etcétera Ahora bien, cada dimensión puede estar medida de diferentes formas conforme la granularidad deseada, por poner un ejemplo, para la dimensión "zona geográfica" podríamos estimar 'localidades', 'provincias', 'regiones', 'países' o bien 'continentes'.

Granularidad de la dimensión Zona geográfica, con una jerarquía de 5 niveles.Detalle de una tabla de dimensión de un cubo OLAP con un esquema en estrella.Detalle de una tabla de dimensión de un cubo OLAP con un esquema en copo de nieve.

La unidad de medida (por localidades, provincias, etcétera) determinará esa granularidad, cuanto más pequeña sea esta unidad de medida más fina va a ser esta granularidad (grano fino); si las unidades de medida son mayores, entonces vamos a hablar de granularidad gruesa (grano grueso).


En muchas ocasiones interesa contar con de los datos a múltiples niveles de granularidad, esto es, es esencial para el negocio poder preguntar los datos (siguiendo el ejemplo de las zonas) por localidades, provincias, etcétera, en estos casos se crea una jerarquía con la dimensión, puesto que tenemos múltiples niveles de asociación de los datos (con otras dimensiones como el tiempo, se podrían crear niveles jerárquicos del tipo 'días', 'semanas', 'meses', ...).


Cuando las tablas de dimensión asociadas a una tabla de hechos no reflejan ninguna jerarquía (por ejemplo: Las zonas siempre y en toda circunstancia son 'provincias' y solo provincias, el tiempo se mide en 'días' y solo en días, etcétera) el cubo resultante va a tener forma de estrella, esto es, una tabla de hechos central rodeada de tantas tablas como dimensiones, y solo va a haber, aparte de la tabla de hechos, una tabla por cada dimensión.


Cuando una o bien múltiples de las dimensiones del cubo refleja algún género de jerarquía existen 2 planteamientos respecto a la manera que han de ser diseñadas las tablas de dimensión. El primero consiste en reflejar todos y cada uno de los niveles jerárquicos de una dimensión en una única tabla, en un caso así asimismo tendríamos un esquema en estrella como el que se ha descrito previamente.




El otro planteamiento consiste en aplicar a las dimensiones las reglas de normalización de las bases de datos relacionales. Estas reglas están concebidas para eludir redundancias en los datos incrementando el número de tablas, de esta manera se logra guardar la información en menos espacio. Este diseño da como resultado en esquema en copo de nieve. Este modo de organizar las dimensiones de un cubo OLAP tiene un inconveniente con respecto al modelo en estrella que no compensa el ahorro de espacio de almacenaje. En las aplicaciones OLAP el recurso crítico, no es tanto el espacio para almacenaje como el tiempo de contestación del sistema ante consultas del usuario, y está constatado que los modelos en copo de nieve tienen un tiempo de contestación mayor que los modelos en estrella.


En cualquier Dataware house se pueden hallar múltiples cubos con sus tablas de hechos llenas de registros sobre alguna variable de interés para el negocio que ha de ser estudiada. Como ya se ha comentado, cada tabla de hechos va a estar rodeada de múltiples tablas de dimensiones, conforme que factores sirvan mejor para efectuar el análisis de los hechos que se quieren estudiar. Un factor que prácticamente con toda probabilidad va a ser común a todos y cada uno de los cubos es el tiempo, puesto que lo frecuente es guardar los hechos conforme van ocurriendo a lo largo del tiempo, obteniéndose de esta manera una serie temporal de la variable a estudiar.

Tabla de tiempos (1)Fecha (PK)datetimeAñochar(cuatro)Trimestrechar(seis)Meschar(diez)Tabla de tiempos (dos)TiempoID (PK)integerFechadatetimeAñochar(cuatro)Trimestrechar(seis)Meschar(diez)

Dado que el tiempo es una dimensión presente en prácticamente cualquier cubo de un sistema OLAP merece una atención singular. Al diseñar la dimensión tiempo (tanto para un esquema en estrella para un esquema en copo de nieve) hay que prestar singular cuidado, puesto que puede hacerse de múltiples formas y no todas y cada una son del mismo modo eficaces. La manera más habitual de diseñar esta tabla es poniendo como clave primordial (PK) de la tabla la data o bien fecha/hora (tabla de tiempos 1). Este diseño no es de los más convenientes, puesto que a la mayor parte de los sistemas de administración de bases de datos les resulta más costoso hacer buscas sobre campos de tipo "date" o bien "datetime", estos costos dismuyen si el campo clave es de tipo entero, además de esto, un dato entero siempre y en toda circunstancia ocupa menos espacio que un dato de tipo data (el campo clave se va a repetir en millones de registros en la tabla de hechos y eso puede ser mucho espacio), con lo que se va a mejorar el diseño de la tabla de tiempos si se emplea un campo "TiempoID" de tipo entero como clave primordial (tabla de tiempos dos).


A la hora de rellenar la tabla de tiempos, si se ha optado por un campo de tipo entero para la clave, hay 2 opciones, la que quizás sea más inmediata consiste en asignar valores numéricos sucesivos (1, dos, tres, cuatro, ...) para los diferentes valores de datas. La otra alternativa consistiría en asignar valores numéricos del tipo "yyyymmdd", esto es que los 4 primeros dígitos del valor del campo señalan el año de la data, los 2 siguientes el mes y los 2 últimos el día. Este segundo modo aporta una cierta ventaja sobre el precedente, en tanto que así se logra que el dato numérico en sí, aporte por sí mismo la información de a que data se refiere, o sea, si en la tabla de hechos hallamos el valor veinte cuarenta setecientos veintitres, vamos a saber que se refiere al veintitres de julio de 2004; en cambio, con el primer procedimiento, podríamos hallar valores como ocho millones cuatrocientos cincuenta y seis mil cuatrocientos cincuenta y seis, para saber a que data se refiere este valor deberíamos hacer una consulta sobre la tabla de tiempos.


Además del campo clave TiempoID, la tabla de hechos debe contener otros campos que asimismo es esencial estudiar. Estos campos serían:

Tabla de tiempos (tres)TiempoID (PK)integerFechadatetimeAñochar(cuatro)Trimestrechar(seis)TrimestreIDintMeschar(diez)MesIDintQuincenachar(diez)QuincenaIDintSemanachar(diez)SemanaIDintDíachar(diez)DíaIDintDíaSemanachar(diez)DíaSemanaIDint

  • Un campo "año".- Para contener valores como '2002', dos mil tres, '2004', ...


  • Un campo "mes".- Acá se pueden poner los valores 'Enero', 'Febrero', ... (o bien de forma abreviada: 'Ene', 'Feb', ...), esto no está mal, mas se puede progresar si el nombre del mes va acompañado con el año al que pertenece, esto es '2004 Enero', '2004 Febrero', ... de este modo se optima la busca de los valores de un mes específicamente, puesto que con el primer procedimiento, si se procuran los valores pertenecientes por mes de "Enero de dos mil tres", toda esa información está contenida en un solo campo, el "mes", no haría falta preguntar asimismo el campo año.


  • Un campo "mesID".- Este campo debería ser de tipo entero y serviría para guardar valores del tipo doscientos seiscientos uno (para '2006 Enero') o bien doscientos seiscientos dos (para '2006 Febrero'), de esta manera es posible efectuar ordenaciones y agrupaciones por meses.

De forma equivalente a como se ha hecho con el campo mes, se podrían incorporar más campos como "Temporada del año", "Trimestre", "Quincena", "Semana" de tipo texto para poder visualizarlos, y sus equivalentes de tipo entero "Temporada del año_ID", "TrimestreID", "QuincenaID", "SemanaID" para poder efectuar agrupaciones y ordenaciones. Por lo general se puede agregar un campo por cada nivel de granularidad deseado.


Otro campo singular que se puede agregar es el "Día de la semana" ('lunes', 'martes', ...), este campo se acostumbra a agregar para poder hacer estudios sobre el comportamiento de los días de la semana por lo general (no del primer lunes del mes de enero de un año específico, este género de estudio no acostumbra a tener interés), por tal razón, este campo no precisa ir acompañado del mes o bien del año como los campos precedentes. Asimismo se puede incorporar su campo dual "ID" de tipo entero para poder ordenar y reunir si fuera preciso.


Con los añadidos descritos podríamos tener una tabla de tiempos como la de la figura "Tabla de tiempos (tres)". Esta sería válida para un diseño en estrella, para un diseño en copo de nieve habría que separar la tabla de tiempos en tantas tablas como niveles jerárquicos contenga. Obsérvese que los campos de tipo "ID" son todos de tipo entero, en tanto que va a ser sobre estos campos sobre los que se efectuarán la mayor parte de las operaciones y estas se efectuarán más eficazmente sobre datos enteros.


  ELIGE TU TEMA DE INTERÉS: 


autoayuda.es   Internet y Tecnologias 





Está aquí: Inicio > [ INTERNET ] > ıllı Tabla de dimensión wiki: info, historia y vídeos

Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Ver políticas