Diseño de modelos de datos y mejores prácticas – Parte 2

Diseño de modelos de datos y mejores prácticas – Parte 2

  • Dale Anderson
    Dale Anderson is a Customer Success Architect at Talend. Over a 30 year career, Mr. Anderson has gained extensive experience in a range of disciplines including systems architecture, software development, quality assurance, and product management and honed his skills in database design, modeling, and implementation, as well as data warehousing and business intelligence. A keen advocate for an appropriate temperance of the software workflow process, he has applied his innovations to the often overlooked lifecycle of a database. The Database Development Lifecycle Mr. Anderson has developed incorporates data modeling best practices to address the complexities involved in modeling adaptations, multi-environment fulfilments, fresh installations, schema upgrades, and data migrations for any database implementation.

 

¿En qué consiste un modelo de datos? Como desarrolladores de Talend, los vemos a diario y nos da la impresión de que sabemos qué son:

  • Una definición estructural de los datos de un sistema comercial
  • Una representación gráfica de datos comerciales
  • Unos cimientos de datos sobre los que construir soluciones empresariales

Todas estas frases pueden ser correctas, pero por un momento me atreveré a proponer que son definiciones superfluas; periféricas, puesto que por separado no atacan la raíz, ni el propósito, ni el objetivo de lo que en realidad es un modelo de datos.

De acuerdo, entonces ¿qué es un modelo de datos? Creo que es muchas cosas a la vez, sin ser una sola en concreto. Para mí un modelo de datos es la base estructural, representada como caracterización gráfica definida de un sistema de información empresarial. ¿Qué le parece? Es lo mismo que las definiciones anteriores, ¿verdad? No del todo. Esta definición engloba todos los elementos en una única finalidad; un medio para identificar, estructuralmente, la información relativa a un caso práctico comercial, no tan solo sus datos.

En la primera parte de esta serie condensé la historia de 50 años de modelado de datos en apenas cuatro breves párrafos. Es cierto que me he saltado cosas, pero sigo creyendo que entender cómo llegamos a saber lo que sabemos y hacemos con el modelado de datos es fruto de las lecciones aprendidas y las mejoras logradas gracias a nuestros predecesores. Hoy en día la mayoría de empresas utilizan modelos de datos para ayudar a validar requisitos, lo que supone todo un valor de negocio, pero muchas veces me pregunto si realmente entienden cómo debe procederse correctamente. En muchos casos, se da por sentada la fantasía de un modelo de datos duradero solo porque tengan uno, sin saber ni corroborar si realmente es acertado.

Como profesional de la arquitectura de datos y el diseño de bases de datos, he visto tantos modelos de datos deficientes que me veo obligado a apuntar que seguramente la mayoría de modelos son erróneos hasta cierto punto. También he encontrado muchos buenos, pero ¿cómo se sabe cuando un modelo de datos es bueno o malo? ¿Por qué debería importarnos? Mientras los datos entran y salgan, ¿no basta? La respuesta es un sonoro ¡NO! Los modelos de datos deben ser buenos, o magníficos, para garantizar el éxito de los sistemas de empresa en los que se ejecutan o con los que cooperan. El modelo de datos es la esencia del negocio y, por lo tanto, debe ser exhaustivo, intachable y elástico.

Así pues, la motivación para disponer de un buen modelo de datos queda más que demostrada. Una vez se empiezan a introducir y extraer datos con herramientas de ETL/ELT como Talend Studio, la cosa se entiende mejor (nos pasa a la mayoría). Diría que un modelo de datos es uno de los tres elementos técnicos esenciales de cualquier proyecto de software. Los otros dos son el código de aplicación y la interfaz de usuario.

Muy bien, pues en la primera parte también leyó sobre la metodología del Ciclo de vida de desarrollo de las bases de datos (DDLC, en inglés), que siguen todos los modelos de datos que personalmente diseño. Esta metodología me ha funcionado siempre muy bien y es muy recomendable para cualquier equipo de creación de bases de datos que se tome su trabajo en serio. Entender y adoptar este proceso puede racionalizar, automatizar y mejorar toda aplicación y mantenimiento de un modelo de datos. Sin embargo, este proceso entraña otros aspectos que debemos analizar. A continuación presentaré algunas mejores prácticas más capaces de fomentar un modelo de datos fiable, flexible y preciso para su empresa.

Mejores prácticas en modelado de datos

Muchos modelos de datos se diseñan mediante un proceso en el que el modelador crea un modelo lógico y luego otro físico. Lo habitual es que los modelos lógicos describan entidades y atributos y las relaciones que los unen, proporcionando así una representación clara de la finalidad comercial de los datos. Los modelos físicos luego implementan el modelo lógico como tablas, columnas, tipos de datos e índices junto con concisas reglas de integridad de datos. Estas reglas definen las claves primarias y foráneas y los valores por defecto. Además pueden definirse las vistas, activadores y procedimientos almacenados como soporte a la implementación según las necesidades. Este modelo físico también define la asignación de almacenamiento en disco a partir de las opciones de configuración concretas que proporcionan la mayoría de sistemas anfitriones (como Oracle, MS, SQL Server, MySQL, etc.).

Hasta aquí, correcto, ¿verdad? Pues bien, muchas veces he participado en discusiones acaloradas sobre la diferencia entre un modelo lógico y uno conceptual. Mucha gente me dice que son lo mismo, que ambos presentan entidades y atributos de los datos de empresa. ¡No podría estar más en desacuerdo! El modelo conceptual pretende proporcionar contexto sobre la noción comercial de los datos, no la técnica. Todas las partes son capaces de entender un modelo conceptual, cuando a muchas les cuesta comprender las entidades o los atributos. Considero que el modelo conceptual, si está bien hecho, es la MEJOR herramienta de comunicación sobre los datos de empresa para todos los integrantes del proceso. Yo prefiero utilizar aspectos del Lenguaje unificado de modelado (UML, en inglés) para hacer un diagrama de un modelo conceptual y limitarlo a algo muy sencillo, sin empantanarme en los detalles. Eso prefiero dejarlo para los modelos lógicos y físicos, en los que esos detalles son esenciales y minuciosos.

La gran empresa, que normalmente tiene grandes cantidades de sistemas de aplicaciones, presenta un nivel de preocupación superior al modelar datos. He observado que, sencillamente, ni siquiera los modelos conceptuales, lógicos y físicos son suficientes. Presentamos: El Modelo de datos holístico, ¡o al menos mi propia adaptación!

El objetivo del Modelo de datos holístico es identificar y abstraer compartimentos de datos en toda la empresa, describiendo de esta forma todo lo que existe o lo que se necesita, dónde se relacionan entre sí y cómo organizarlos para lograr el uso más eficaz, al máximo nivel.

Las cuatro capas de proceso del modelado de datos

Dados los posibles cuatro tipos distintos de modelos de datos de una empresa, yo propongo que se siga el siguiente proceso de modelado de datos en concepto de ‘capas’, de arriba abajo, para la definición, el perfeccionamiento de la comprensión y funcionalidades de diseño específicos. Las funciones clave de cada nivel identifican quién ha participado del proceso y dónde.

Modelo de datos holístico:

La Capa holística representa un paisaje abstracto de compartimentos de datos de toda una empresa. Este modelo de datos genera la oportunidad de fijar una gobernanza de datos comerciales generalizada, facultando así una mejor comprensión de todas las relaciones de datos inherentes a la empresa. Está pensado para incorporar datos de cualquier aplicación, ya sea interna o externa. Yo utilizo un gráfico de burbujas para trazar el modelo de datos holístico. Así es como lo hago yo:

Gráficos de burbuja - Compartimentos de datos

El gráfico de burbuja es una composición de sencillas burbujas que representan compartimentos de datos únicos. Las líneas (llamadas enlaces o links) que conectan dos burbujas (dos y solo dos) indican que guardan alguna o varias relaciones. A grandes rasgos, cada agrupación de burbujas (diseñadas muchas veces con un punto central o "hub" que proyecta radios o "spokes") encara un conjunto particular de compartimentos de datos identificado en toda la empresa; nada más ni nada menos. He aquí algunos detalles de la especificación:

Los enlaces de color AZUL liso indican relaciones directas entre dos compartimentos de datos. Los enlaces de color ROJO a rayitas indican relaciones indirectas entre dos compartimentos de datos. Los enlaces de color VERDE con puntitos indican relaciones ampliadas entre dos compartimentos de datos. Utilice estos enlaces de forma subjetiva, puesto que pueden representar múltiples relaciones (que se definirán en la capa conceptual). Lo que definen, sencillamente, es que existe una relación.

A veces una burbuja está rodeada por otra más grande. Estas burbujas más grandes significan que existe una ontología (o que debería) que organiza una taxonomía específica para aquel compartimento de datos. Las ontologías y sus metadatos taxonómicos proporcionan mapeos relevantes respecto al compartimento que envuelven. Es de gran utilidad para que los datos sean susceptibles de búsqueda en gran medida y debería identificar en esta capa.

Las gráficas de burbujas definen compilaciones particulares de información empresarial. El objetivo es identificar, simplificar y consolidar información ausente de cualquier aplicación, implementación o detalles técnicos con los que quizá sea compatible. La ventaja del modelo de datos holístico es que todos los públicos pueden entender el paisaje de datos de la empresa en una sola vista exhaustiva, aunque simplista, que ofrece un punto de inicio flexible para la identificación e inserción de cualquier dato nuevo en el modelo con muy poca o ninguna alteración de los modelos de datos subyacentes (lo analizaremos más abajo).

He aquí un ejemplo del aspecto que puede tener un modelo de datos holístico totalmente definido. Imprímalo en la impresora de GRAN tamaño y cuélguelo en la pared. Observarlo da para muchas conversaciones productivas y pueden generar activos eficaces y valiosos para su empresa.


Modelo conceptual de datos:

La Capa conceptual representa una definición abstracta de los elementos de datos comerciales y sus relaciones. Este modelo de datos define la semántica del paisaje de datos de la empresa desde una perspectiva de aplicación, cosa que posibilita una mejor comprensión de la información comercial subyacente. El UML proporciona la vía gráfica para diseñar este modelo. El modelo conceptual de datos está formado por objetos de elemento y define una categoría de información derivada de un compartimento de datos en el modelo holístico. A grandes rasgos se puede entender como un modelo de información. Así es como lo hago yo:

Arquitectura de información en UML

Cada objeto de elemento encapsula una parte concreta de un compartimento de datos y unas líneas de conexión (también llamadas enlaces) que definen relaciones específicas entre dos elementos (dos y solo dos, también aquí). Los ítems de elemento concretos (llamados características) se definen con el fin de contribuir más a la comprensión y la finalidad del objeto. Pueden ser:
  • Protegidos (cuando los valores están predeterminados)
  • Públicos (cuando los valores son mutables)
  • Privados (cuando los valores tienen un uso restringido)

Se considera que los objetos de elemento conectados directamente entre sí tienen alguna "asociación" indicada con un enlace de color GRIS liso y etiquetas de significado. Estas asociaciones, que utilizan un símbolo de diamante en el elemento Padre, presentan relaciones que pueden ser:

  • Simples (sin diamante)
  • Compartidas (diamante abierto)
  • Compuestas (diamante liso)

Un elemento hijo también puede ser "navegable" cuando está indicado por un símbolo de flecha e identificado también con una cardinalidad relacional (0.* = de cero a muchos, etc.).

Los objetos de elemento también pueden tener "generalizaciones", que significa que una instancia de un objeto puede tener unas características o relaciones determinadas o únicas. En esta representación, el objeto es más bien como una subcategoría de un elemento padre que incluye todas sus características ADEMÁS de las únicas suplementarias que corresponda. El elemento de la subcategoría se perfecciona tanto en su nombre como en su representación para proporcionar un perfeccionamiento comprensible sobre el compartimento de datos holístico abstraído. Las generalizaciones conectadas a objetos de elemento se indican mediante enlaces de color AZUL liso con una flecha cerrada pegada al objeto padre y sin que sea necesaria ninguna etiqueta.

Las conexiones entre subcategorías también definen relaciones que son de utilidad para entender el modelo conceptual de datos que representan. Se considera que las subcategorías generalizadas conectadas a otras subcategorías generalizadas del mismo objeto padre tienen una "asociación" que se indica con los enlaces de color VERDE liso y etiquetas de significado. Estas relaciones pueden ser opcionalmente "navegables" cuando están indicadas con un símbolo de flecha abierta e identificadas también con una cardinalidad relacional (0.* = de cero a muchos, etc.).

Para completar el diagrama de UML, los elementos pueden tener asociaciones de autounión que son características específicas que amplían la definición de un objeto padre, o "asociaciones" entre características concretas. Las ampliaciones concretas no representan una categoría o una generalización, sino que identifican características pertinentes que se invocan para entender mejor el compartimento de datos abstraído. La conexión de características específicas a un elemento se indica con un enlace de color ROJO liso y una etiqueta de significado. Además, las características de los elementos pueden conectarse a otras características de elementos del mismo objeto padre indicadas con enlaces de color VERDE liso parecidos a las generalizaciones relacionadas. Estas relaciones pueden ser "navegables" cuando están indicadas con un símbolo de flecha abierta e identificadas también con una cardinalidad relacional (0.* = de cero a muchos, etc.).

El modelo conceptual de datos describe elementos de datos concretos que utilizan una metáfora por categorías, cuyo mejor diagrama se consigue mediante el UML, que explica además los compartimentos de datos holísticos abstraídos. Este objetivo consiste en definir, perfeccionar y mitigar el riesgo de obtener información comercial inútil, aún agnóstica para cualquier aplicación, reglas de implementación o detalles técnicos, y también para encapsular detalles que hayan quedado fuera del modelo holístico.

Una vez más, imprímalo en GRANDE y fíjese que este modelo representa una interfaz común a partir de la cual puede escribirse el código de aplicación sin los modelos de datos lógicos ni físicos que siguen. Esta ventaja también supone un punto de validación con respecto al cual se crean los siguientes modelos de datos. La validación del modelo por UML tanto con ingeniería de software como por los distintos participantes del proceso supone un momento clave del proceso de modelado de datos. He aquí un ejemplo del aspecto que puede tener una selección de un modelo conceptual de datos.

Fíjese que el modelo tiene "subelementos" que definen aspectos particulares del "elemento principal" para clarificar características únicas y recurrentes.

Modelo lógico de datos:

La Capa lógica representa una estructura abstracta de información semántica organizada por entidades de dominio (objetos de datos lógicos), sus atributos y las relaciones concretas entre sí. Este modelo de datos derivado de objetos de elemento del modelo conceptual define detalles pertinentes (claves/atributos) además de las relaciones entre las entidades sin tener en cuenta ninguna tecnología de almacenado en el host concreta. Las entidades pueden representar un único elemento, una parte o distintos elementos, según sea necesario para encapsular estructuras de datos adecuadas. El modelo lógico de datos encapsula las entidades estructurales y los conjuntos de registros identificados en el modelo conceptual añadiéndoles atributos específicos y ayudando así a entender mejor los datos en cuestión. Así es como lo hago yo:

ERD

Los Diagramas de relaciones de entidades (ERD, en inglés) describen entidades identificables de forma única capaces de una existencia independiente que, a su vez, exigen un conjunto mínimo de atributos de identificación única llamados una clave primaria (PK, en inglés). Cuando una entidad hija esté enlazada a alguna entidad madre, la integridad referencial de los datos puede y debe ejecutarse mediante el uso de un atributo identificador de la entidad hija que se corresponda con el atributo o atributos padre de la Clave primaria, llamados clave foránea (FK, en inglés). Aunque seguro que ya habían oído hablar de ellas.

Según convenga, las entidades pueden enlazarse y demostrar la naturaleza de un conjunto de registros o la relación de cardinalidad entre dos o más entidades. Las entidades con enlaces pueden utilizar la técnica de la Notación de pata de gallo, muy habitual en los diagramas de relaciones de entidades (ERD). Indicada con enlaces de color AZUL liso, la notación por pata de gallo adecuada a ambos lados debería incluir también una etiqueta de significado para describir el conjunto de registros que represente. Estos enlaces de entidad presentan una cardinalidad específica que explica los recuentos de registros permitidos de un conjunto de registros. Estas notaciones pueden especificar: cero, una o muchas filas o una combinación obligatoria.

La cardinalidad tan solo tiene dos reglas: el número mínimo y el máximo de filas para cada entrada que pueden participar de una relación, en la que la notación más cercana a la entidad es el recuento máximo. Especificar la cardinalidad de un conjunto de registros también sugiere que la relación es opcional u obligatoria, cosa que contribuye al diseño del modelo físico de datos.

Un ERD puede integrar enlaces a distintas entidades, como también enlaces de autounión. Además, no deberían confundirse las entidades con tablas por muchos mapeos directos a tablas que puedan generar en un modelo físico de datos (ver más abajo). Las entidades locales en realidad son abstracciones estructurales que se centran en representaciones racionales del modelo conceptual de datos.
El modelo lógico de datos presenta la abstracción semántica del modelo conceptual de datos y proporciona detalles a partir de los cuales puede diseñarse un modelo físico de datos. Esta ventaja también puede ser de ayuda tanto a ingenieros de servicios de aplicación como a ingenieros de bases de datos para comprender no solo la estructura de datos abstraída, sino los requerimientos de las transacciones de datos. He aquí un ejemplo del aspecto que puede tener una selección de un modelo lógico de datos.

Fíjese en varias cosas. He utilizado colores para representar distintas áreas funcionales que pueden mapearse con los modelos conceptual y holístico. También he incorporado una relación "virtual" entre ENTITY_D y ENTITY_C (que aparecen como un enlace de color GRIS CLARO). Esto identifica que existe una relación lógica, aunque la noción entre estas dos entidades más la ENTITY_B representa una "referencia circular", que es algo que debemos evitar completamente en el modelo físico. Observe también que hay varios atributos que definen un vector de valores. En el modelo lógico esto es correcto, ya que simplifica y racionaliza el modelo; basta con asegurarse que los normaliza en el modelo físico.

Modelo físico de datos:

La Capa física representa una composición de artefactos del sistema host (objetos de datos físicos) derivada de un modelo lógico de datos junto con su configuración de almacenamiento deseada. Este modelo de datos incorpora tablas, columnas, tipos de datos, claves, restricciones, permisos, índices, vistas y detalles sobre los parámetros de asignación disponibles en el almacén de datos (eche un vistazo a mi entrada sobre Más allá de la bóveda de datos si desea más información sobre los almacenes de datos). Estos artefactos del host representan el modelo de datos real sobre el que se crean las aplicaciones de software. El modelo de datos físico encapsula todos estos artefactos de las entidades y los atributos definidos en el modelo lógico de datos, permitiendo finalmente un acceso de aplicación al almacén y extrayendo los datos en sí. Así es como lo hago yo:

SDM

Un Modelo de diseño (físico) en esquema (SDM, en inglés) define objetos específicos de un sistema de información de bases de datos. Doy por hecho que la mayoría de mis lectores conoce mejor este modelo de datos que los tres anteriores, de modo que evitaré describir las nociones. Prefiero llamarlo un SDM para no confundirlo con el término más habitual de ERD, que NO es un modelo físico de datos. El SDM proporciona una referencia de ingeniería a menudo registrada tanto en el diagrama gráfico como en un documento de diccionario de datos. Como proporciona una referencia crítica detallada para todos los objetos de base de datos implementados en el SDM, este documento debería incorporar su finalidad, las reglas de integridad referencial, así como otro tipo de información importante sobre su comportamiento previsto. Esta es una estructura útil que yo utilizo:

  • Nombre y definición del objeto (tablas/vistas)
    • Nombre de archivo de creación/modificación del objeto SQL
    • Dominio comercial y uso funcional
    • Versión/Nivel de integridad
    • Columnas/Tipos de datos/Tamaño
    • Capacidad de aceptar valores nulos
    • Valores por defecto
    • Claves primarias
    • Claves foráneas
    • Claves comerciales naturales
    • Restricciones UNIQUE
    • Restricciones CHECK
    • Índices únicos y no únicos (en clúster y sin clúster)
  • Flujos de control (en casos de diseño/uso de complejidad añadida)
  • Comentarios útiles
  • Historial de cambios

Un Diccionario de datos SDM referencia objetos alfabéticamente por nombre para facilitar su uso. Como la mayoría de modelos físicos de datos están muy normalizados (¿ha leído la primera parte de este artículo?), las reglas de integridad referencial deberían invocarse para todas las tablas. En mi experiencia he visto muchas formas de lidiar con estas reglas, en concreto al ejecutar scripts de objeto SQL respecto a un esquema existente. Funciona si simplemente desactivamos las comprobaciones de integridad, ejecutamos los scripts y luego volvemos a activarlas. Es sencillo, pero tampoco soy un gran defensor de este método, porque es fácil equivocarse.

Yo prefiero dedicar tiempo a entender las referencias concretas a todas las tablas y asignarle un nivel de integridad a cada una. Una tabla de "Nivel de integridad" identifica el orden jerárquico de la relación de tablas padre/hijo. En resumen, una tabla "Nivel de integridad" se basa en cualquier referencia de clave foránea a una tabla o tablas madre. Para muestra, un botón:

  • Una tabla sin tablas madre: es un L0 o nivel 0 (el más alto)
  • Una tabla con al menos una tabla madre: es un L1 o nivel 1
  • Una tabla con al menos una tabla madre pero esa tabla madre tiene una tabla madre de L0: es un L2 o nivel 2
  • Una tabla con varias tablas madre que tiene tablas madre de distintos niveles: es el nivel más bajo +1
    • es decir: el padre A es un L0, el padre B es un L1, de modo que la tabla hija es una L2
      o: el padre A es un L1, el padre B es un L4, de modo que la tabla hija es una L5
  • etcétera, etcétera.

AVISO: L0 es el nivel más alto, puesto que no hay tablas madre; el nivel más bajo viene determinado por el modelo físico de datos. Este método también elimina la posibilidad de generación de referencias circulares (que es una práctica de diseño de modelo de datos a evitar, en mi humilde opinión).

El modelo físico de datos es el único que en realidad se implementa. Yo para esta implementación prefiero usar scripts de creación de objetos SQL o SOCS. Con este método descubrí que el DDLC de cualquier modelo físico de datos puede desacoplarse como proceso independiente, lo cual es muy deseable y difícil de conseguir. La idea es crear un archivo SOCS para un objeto primario de la base de datos (tabla, vista, activador o procedimiento almacenado). Estos scripts contienen verificaciones inteligentes para determinar qué declaraciones de SQL deben y pueden aplicarse (eliminar, crear, alterar, etc.) mediante conmutadores y argumentos enviados por el ciclo de vida analizado en mi entrada anterior, que son:

  • Una INSTALACIÓN desde cero: a partir de la versión actual del esquema
  • Aplicación de una ACTUALIZACIÓN: eliminar/crear/modificar objetos de Bd al actualizar de una versión a la siguiente
  • MIGRACIÓN de datos: en la que tenga lugar una "mejora" disruptiva (como la división de tablas o una plataforma)

Estos archivos SOCS también incorporan mejores prácticas, como por ejemplo (las suyas pueden ser distintas):

  • Convenciones de nomenclatura uniformes
    • Nombres de tablas en MAYÚSCULAS siempre
    • Nombres de columnas en MINÚSCULAS siempre
    • Ver todos los nombres sin espacios (Camel case)
    • Los nombres de archivo SOCS incorporan el nombre de objeto
  • Claves primarias de columna única que utilizan enteros de tamaño apropiado
  • Eliminación de datos redundantes/duplicados (tuplas)
  • Eliminación de cualquier referencia clave circular (en las que pueda producirse un Padre > Hijo > Padre)
  • Archivo SOCS único por objeto
  • Los archivos SOCS contienen apartados de cabecera/finalidad/historial que se corresponden con el diccionario de datos
  • El formateo SQL aporta legibilidad y mantenibilidad

Los demás detalles sobre mi implementación del SOCS quedan fuera del alcance de este artículo. A lo mejor alguien me convence de que escriba sobre ello en otra ocasión. Se agradecen comentarios y preguntas.

No es verdad, Modelo de datos, que en esta apartada orilla...

Un breve resumen de estas capas ayuda a entender su finalidad, cómo se sustentan y cómo difieren entre sí durante el proceso de modelado. Eche una ojeada a esta tabla para verlo:

ASPECTO DEL MODELO DE DATOS

HOLÍSTICO

CONCEPTUAL

LÓGICO

FÍSICO

Compartimentos de datos

 

 

 

Relaciones de compartimentos de datos

 

 

 

Nombres de elementos

 

 

 

Relaciones de elementos

 

 

 

Generalizaciones de elementos

 

 

 

Ítems de elementos

 

 

 

Nombres de entidad

 

 

 

Relaciones de entidad

 

 

 

Claves de entidad

 

 

 

Atributos de entidad

 

 

 

Restricciones de entidad

 

 

 

Nombres de tabla/vista

 

 

 

Nombres de columna

 

 

 

Tipos de datos de columna

 

 

 

Valores por defecto de columna

 

 

 

Claves primarias/foráneas

 

 

 

Nombres de índice

 

 

 

Propiedades de índice

 

 

 

Configuraciones de almacenamiento

 

 

 

Conclusión

Bien, le agradezco que haya resistido hasta aquí. Si ha llegado hasta el final del texto, ya sabe de qué pasta está hecho. La buena noticia es... ¡que con esto terminamos! ¡Alegría! Espero que toda esta información le haya resultado útil. Cuando los buenos desarrolladores de Talend conocen bien sus modelos de datos, es cuando surgen los patrones de diseños de tareas y las mejores prácticas. Si no ha leído aún mis entradas sobre este tema, aquí tiene el enlace a la cuarta parte. Encontrará enlaces a la primera, segunda y tercera parte en el interior. A lo mejor también encuentra interesante el artículo sobre Cómo crear un data lake gobernado en cloud, escrito a cuatro manos por servidor y un gran amigo mío. Kent Graziano de Snowflake Computing, socio de Talend muy estimado.

Hasta la próxima... ¡Un buen modelo de datos sí da la felicidad!

Join The Conversation

0 Comments

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *