Las estructuras de datos dimensionales son el objetivo de los procesos ETL, y estas tablas se sit\u00faan en el l\u00edmite entre los procesos de transformaci\u00f3n de datos y su volcado al sistema de datos de explotaci\u00f3n. En muchos casos, las tablas dimensionales ser\u00e1n el \u00faltimo paso f\u00edsico de preparaci\u00f3n antes de transferir las tablas a los entornos de los usuarios finales.<\/p>\n\n\n\n
Los modelos de datos dimensionales son, con diferencia, las estructuras de datos m\u00e1s populares para las consultas y an\u00e1lisis de los usuarios finales. Son sencillos de crear, son extremadamente estables en presencia de entornos de datos cambiantes, son intuitivamente comprensibles por los usuarios finales y son la estructura de datos m\u00e1s r\u00e1pida para consultas generales en bases de datos relacionales. Los modelos dimensionales tambi\u00e9n son la base para construir todas las formas de cubos OLAP, ya que un cubo OLAP no es m\u00e1s que un modelo dimensional de alto rendimiento implementado en software de prop\u00f3sito especial<\/p>\n\n\n\n
Los modelos dimensionales se construyen alrededor de procesos de medici\u00f3n. Una medici\u00f3n es una observaci\u00f3n en el mundo real de un valor previamente desconocido. Las mediciones son predominantemente num\u00e9ricas y la mayor\u00eda de ellas pueden repetirse a lo largo del tiempo, creando una serie temporal.<\/p>\n\n\n\n
Una sola medici\u00f3n crea un \u00fanico registro en la tabla de hechos. Inversamente, un \u00fanico registro en la tabla de hechos corresponde a un evento de medici\u00f3n espec\u00edfico. Obviamente, la medici\u00f3n observada se almacena en el registro de la tabla de hechos. Pero tambi\u00e9n almacenamos el contexto de la medici\u00f3n en el mismo registro. Aunque podr\u00edamos sentirnos tentados a almacenar este contexto en muchos campos detallados directamente en el registro de la tabla de hechos, normalizamos sistem\u00e1ticamente los atributos contextuales fuera de la tabla de hechos creando una serie de tablas de dimensiones que pueden verse informalmente como agrupaciones de contexto.<\/p>\n\n\n\n
Por ejemplo, si la medici\u00f3n es la cantidad de una prima de seguro registrada por una compa\u00f1\u00eda de seguros en una p\u00f3liza particular, un cliente particular, un agente particular, una cobertura espec\u00edfica (como da\u00f1os por colisi\u00f3n), un art\u00edculo asegurado (quiz\u00e1s un autom\u00f3vil), un tipo de transacci\u00f3n espec\u00edfico (como establecer prima), en una fecha efectiva determinada, las dimensiones t\u00edpicas adjuntas al registro de hechos ser\u00edan P\u00f3liza, Cliente, Agente, Cobertura, Art\u00edculo, Tipo de Transacci\u00f3n y Fecha Efectiva. <\/p>\n\n\n\n
El grano de una tabla de hechos es la definici\u00f3n de lo que constituye un registro \u00fanico en la tabla de hechos. En el mundo del modelado dimensional, el grano siempre se declara al principio del dise\u00f1o en t\u00e9rminos de negocio, no en t\u00e9rminos de base de datos. El grano de nuestro ejemplo de seguro podr\u00eda ser la transacci\u00f3n de p\u00f3liza de seguro. Luego, m\u00e1s adelante en el proceso de dise\u00f1o, cuando se comprenden las dimensiones disponibles, el grano puede declararse formalmente en t\u00e9rminos de la clave de la tabla de hechos. Esta declaraci\u00f3n de clave incluir\u00e1 algunas, pero generalmente no todas, las referencias de clave for\u00e1nea a las dimensiones adjuntas a la tabla de hechos. Asumimos que la clave para nuestra tabla de hechos de seguros es P\u00f3liza X Tipo de Transacci\u00f3n X Tiempo.<\/p>\n\n\n\n
La estructura y el contenido de un modelo dimensional dependen \u00fanicamente de la f\u00edsica del proceso de medici\u00f3n en s\u00ed.<\/p>\n\n\n\n
El modelo dimensional no anticipa ni depende de los usos de consulta previstos. Es un marco sim\u00e9trico extremadamente flexible, adecuado para todas las clases de consultas. Sin embargo, a\u00fan hay cierto margen para la discreci\u00f3n del dise\u00f1ador. Muchas de las dimensiones para una tabla de hechos particular se referenciar\u00e1n directamente en la fuente de datos original. Pero el equipo del almac\u00e9n de datos puede agregar dimensiones que provienen de otras fuentes, siempre que sean de valor \u00fanico en el momento del evento de medici\u00f3n. Por ejemplo, en nuestro caso de seguros, se podr\u00eda agregar una dimensi\u00f3n de promoci\u00f3n orientada al marketing si esos datos estuvieran disponibles. Una de las grandes fortalezas de los modelos dimensionales es su capacidad para agregar gr\u00e1cilmente contexto dimensional que es v\u00e1lido en el contexto del evento de medici\u00f3n.<\/p>\n\n\n\n
De manera similar, las mejores dimensiones son descripciones detalladas de las entidades dimensionales. As\u00ed que la dimensi\u00f3n Cliente en nuestro ejemplo deber\u00eda tener muchos campos descriptivos. A estos campos descriptivos los llamamos atributos dimensionales. Afortunadamente, todos los dise\u00f1os dimensionales permiten que se a\u00f1adan atributos a las dimensiones de forma incremental a lo largo de la vida del almac\u00e9n. La responsabilidad del arquitecto del almac\u00e9n de datos es identificar estas oportunidades para atributos adicionales y solicitar que el equipo de ETL los a\u00f1ada al esquema f\u00edsico. Los atributos dimensionales son principalmente textuales o son n\u00fameros que adoptan valores discretos. Las tablas dimensionales siempre deben construirse con un \u00fanico campo de clave primaria que es un entero simple sin significado asignado por el proceso de ETL. Estas claves se llaman claves sustitutas. <\/p>\n\n\n\n
Las claves sustitutas primarias en cada dimensi\u00f3n se emparejan con claves for\u00e1neas correspondientes en la tabla de hechos. Cuando se respeta esta relaci\u00f3n clave primaria-a-for\u00e1nea, decimos que las tablas obedecen la integridad referencial<\/strong>. La integridad referencial es un requisito constante en todos los modelos dimensionales. No mantener la integridad referencial significa que algunos registros de la tabla de hechos son hu\u00e9rfanos que no pueden recuperarse mediante restricciones en las dimensiones afectadas.<\/p>\n\n\n\n Sabes que un modelo de datos dimensional es el mejor formato para los datos que respaldan las consultas de los usuarios. En ocasiones, podr\u00edas necesitar utilizar ciertos elementos a nivel at\u00f3mico para que los datos se puedan presentar a un nivel superior. Sin embargo, necesitas almacenar los hechos a nivel at\u00f3mico para producir las solicitudes precisamente restringidas requeridas por los usuarios. A menudo, los usuarios de negocios no quieren analizar hechos a nivel de transacci\u00f3n porque la cardinalidad de cada dimensi\u00f3n es tan extensa que cualquier informe a nivel at\u00f3mico ser\u00eda de p\u00e1ginas y p\u00e1ginas, lo que lo hace humanamente imposible de examinar. Sin embargo, necesitas almacenar los hechos a nivel at\u00f3mico para producir los hechos de instant\u00e1neas peri\u00f3dicas requeridos por los usuarios. Cuando llega el momento en que los usuarios solicitan datos a nivel at\u00f3mico, simplemente puedes migrarlos del \u00e1rea de preparaci\u00f3n a la capa de presentaci\u00f3n.<\/p>\n\n\n\n Es una buena pr\u00e1ctica particionar las tablas de hechos almacenadas en el \u00e1rea de preparaci\u00f3n porque los agregados resultantes probablemente se basar\u00e1n en un per\u00edodo espec\u00edfico, tal vez mensual o trimestral. Crear particiones alivia a la base de datos de tener que escanear toda la tabla y le permite ir directamente a la subsecci\u00f3n que contiene los datos que necesita para ese per\u00edodo para crear el agregado. La partici\u00f3n tambi\u00e9n reduce la carga de podar o archivar datos antiguos. Las tablas particionadas simplemente pueden eliminar la parte de una tabla que contiene los datos antiguos.<\/p>\n\n\n\n Las tablas dise\u00f1adas dimensionalmente en el \u00e1rea de preparaci\u00f3n son en muchos casos necesarias para poblar cubos de procesamiento anal\u00edtico en l\u00ednea (OLAP). O puedes implementar una estructura h\u00edbrida donde tienes la gran capa de datos at\u00f3micos en un esquema RDBMS dimensional, con estructuras cada vez m\u00e1s agregadas por encima de la capa at\u00f3mica en forma de cubos OLAP. Algunos de los sistemas OLAP pueden explorar a trav\u00e9s de los cubos OLAP y acceder a los datos at\u00f3micos de nivel m\u00e1s bajo en una sola aplicaci\u00f3n.<\/p>\n\n\n\n Las tablas de mapeo de claves sustitutas est\u00e1n dise\u00f1adas para mapear claves naturales de los sistemas fuente dispares a su clave sustituta maestra del almac\u00e9n de datos. Las tablas de mapeo son una forma eficiente de mantener claves sustitutas en tu almac\u00e9n de datos. Estas tablas compactas est\u00e1n dise\u00f1adas para un procesamiento de alta velocidad. Las tablas de mapeo contienen solo el valor m\u00e1s actual de una clave sustituta, utilizado para poblar una dimensi\u00f3n, y la clave natural del sistema fuente. Dado que la misma dimensi\u00f3n puede tener muchas fuentes, una tabla de mapeo contiene una columna de clave natural para cada una de sus fuentes.<\/p>\n\n\n\n Las tablas de mapeo pueden ser igualmente efectivas si se almacenan en una base de datos o en el sistema de archivos. La ventaja de usar una base de datos para las tablas de mapeo es que puedes utilizar el generador de secuencias de la base de datos para crear nuevas claves sustitutas. Y tambi\u00e9n, cuando se indexan correctamente, las tablas de mapeo en una base de datos son muy eficientes durante las b\u00fasquedas de valores de clave.<\/p>\n\n\n\n Dado que las tablas de mapeo de claves no tienen valor anal\u00edtico, nunca deben residir en la capa de presentaci\u00f3n del almac\u00e9n de datos ni ser expuestas a los usuarios finales.<\/p>\n","protected":false},"excerpt":{"rendered":" Las estructuras de datos dimensionales son el objetivo de los procesos ETL, y estas tablas se sit\u00faan en el l\u00edmite entre los procesos de transformaci\u00f3n de datos y su volcado al sistema de datos de explotaci\u00f3n. En muchos casos, las tablas dimensionales ser\u00e1n el \u00faltimo paso f\u00edsico de preparaci\u00f3n antes de transferir las tablas a […]<\/p>\n","protected":false},"author":1,"featured_media":39009,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[430],"tags":[],"class_list":{"0":"post-39008","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-automatizacion"},"_links":{"self":[{"href":"https:\/\/www.conectasoftware.com\/magazine\/wp-json\/wp\/v2\/posts\/39008","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.conectasoftware.com\/magazine\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.conectasoftware.com\/magazine\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.conectasoftware.com\/magazine\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.conectasoftware.com\/magazine\/wp-json\/wp\/v2\/comments?post=39008"}],"version-history":[{"count":2,"href":"https:\/\/www.conectasoftware.com\/magazine\/wp-json\/wp\/v2\/posts\/39008\/revisions"}],"predecessor-version":[{"id":39323,"href":"https:\/\/www.conectasoftware.com\/magazine\/wp-json\/wp\/v2\/posts\/39008\/revisions\/39323"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.conectasoftware.com\/magazine\/wp-json\/wp\/v2\/media\/39009"}],"wp:attachment":[{"href":"https:\/\/www.conectasoftware.com\/magazine\/wp-json\/wp\/v2\/media?parent=39008"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.conectasoftware.com\/magazine\/wp-json\/wp\/v2\/categories?post=39008"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.conectasoftware.com\/magazine\/wp-json\/wp\/v2\/tags?post=39008"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Tablas de Hechos At\u00f3micas y Agregadas<\/h2>\n\n\n\n
Tablas de Mapeo de Claves Sustitutas<\/h2>\n\n\n\n