Modelado de datos para la calidad

Figura 3: Datos de tramo de vuelo SQL 

Tenga en cuenta que cada una de estas representaciones permite responder a las preguntas enumeradas anteriormente.

En el resto de este artículo utilizaré la estructura de datos que se muestra en la Figura 3, ya que esto permite las consultas más simples con las que responder esas preguntas. Modelemos esa estructura de datos con las columnas necesarias. Las figuras 4 a 6 muestran tres modelos alternativos: 

Figura 4: Tabla de días de operación separados

 Figura 5: Columnas de día de operación repetidas

Algunas empresas exigen que todas las tablas tengan una clave primaria sustituta. En una empresa de este tipo, el modelo de datos de la Figura 4 debería modificarse como en la Figura 7.

 Figura 6: Columnas de día booleano de operación 

 Figura 7: Modelo alternativo con claves primarias de ID de fila

Los tipos de datos utilizados en estos modelos son los disponibles en SQL Server. Si DB2 fuera el DBMS de destino,

1. el tipo de datos rowid podría usarse en lugar de un entero para cada columna de ID, y
2. las columnas con el tipo de datos tinyint tendrían que usar el tipo de datos smallint .

Si Oracle fuera el DBMS de destino,

1. las columnas con tipo de datos integer o tinyint tendrían que usar el tipo de datos numérico , y
2. las columnas con tipo de datos time tendrían que usar el intervalo del día al segundo tipo de datos.

Las versiones actuales de cada uno de estos DBMS son compatibles con SQL: 2003, por lo que podríamos utilizar alternativamente tipos de datos definidos por el usuario (consulte la Figura 9 más adelante).

¿Cuáles de estos modelos deberían revisar las partes interesadas del negocio?

Con tantos modelos de datos lógicos candidatos, una posibilidad es proporcionar a las partes interesadas del negocio más de uno para revisar. Esta no es una buena idea ya que pocas partes interesadas del negocio están en condiciones de evaluar qué modelo de datos lógicos facilitaría la escritura de consultas y sería apropiado para el DBMS de destino. Tampoco es una buena idea para los desarrolladores (que sonen condiciones de elegir el modelo de datos lógico óptimo) para elegir uno y luego proporcionárselo a las partes interesadas del negocio para que lo revisen. Si esto sucediera, a esas partes interesadas del negocio se les presentaría un modelo más complejo que uno que describa solo los requisitos de información comercial, ya que también contendría datos de implementación como claves primarias (distintas de las claves comerciales), claves externas (así como relaciones) y tablas adicionales (como en la Figura 4).

En lugar de un modelo de datos lógicos, la empresa debe contar con un modelo de información empresarial (como en la Figura 8) que contenga:

1. solo elementos de datos de interés para la empresa, incluidos solo identificadores comerciales (en lugar de claves primarias y externas),
2. una estructura más simple (ya que describe los Días de operación como una matriz en lugar de una lista de columnas o una tabla separada),
3. tipos de datos comerciales (ver más adelante) en lugar de tipos de datos DBMS
4. (cuando sea relevante) elementos de datos derivados como Duración del vuelo.

 Figura 8: Modelo de información empresarial

Dado que los DBMS compatibles con SQL: 2003 admiten tipos de datos definidos por el usuario (incluidos los tipos de datos de matriz), estos se pueden utilizar en un modelo de datos lógicos para su implementación en un DBMS de este tipo (o en un entorno de desarrollo orientado a objetos), como se muestra en la Figura 9. 

 Figura 9: Modelo de datos lógicos SQL: 2003

¿No es solo un modelo de datos conceptual?

El marco de arquitectura empresarial de Zachman hace una distinción entre las perspectivas conceptual, lógica y física de un diseño. Aunque los objetivos originales de estos tres tipos de modelos eran las partes interesadas del negocio, los diseñadores y los constructores, respectivamente, la evolución de los entornos de desarrollo de sistemas ha llevado a los desarrolladores a preocuparse por las estructuras lógicas en lugar de físicas, mientras que los administradores de bases de datos continúan ocupándose de las estructuras físicas. Como resultado, los objetivos de los modelos conceptuales, lógicos y físicos ahora se toman generalmente como partes interesadas del negocio, desarrolladores y administradores de bases de datos, respectivamente.

Sin embargo, la literatura incluye muchos modelos etiquetados como "modelos de datos conceptuales" que varían ampliamente en términos de contenido, desde meras listas de entidades (sin atributos o relaciones) hasta modelos de datos lógicos (a veces incompletos), es decir, muchos tienen información insuficiente o demasiada información para una revisión eficaz por parte de las partes interesadas del negocio. Como resultado, el término "modelo de datos conceptual" ahora es inútil como término formal, por lo que prefiero el término "modelo de información empresarial" para significar modelos que deben ser revisados ​​por las partes interesadas del negocio.

Tipos de datos comerciales

Los modelos de datos para revisión empresarial a menudo incluyen tipos de datos DBMS como 'integer'. Los tipos de datos enteros se pueden usar para muchos propósitos comerciales diferentes, como,

• recuentos, por ejemplo, 'Número de pasajeros'
• ordinales, por ejemplo, 'Número de secuencia'
• días de la semana, por ejemplo, 1 representa el lunes
• identificadores, por ejemplo, ID de aerolínea.

Estos se comportan de manera diferente. Los recuentos se pueden sumar o restar y se pueden usar en comparaciones mayor que / menor que (desigualdad), mientras que los ordinales (y los días de la semana) se pueden restar y usar en comparaciones de desigualdad, pero no sumar. No tiene sentido sumar o restar identificadores, ni usarlos en comparaciones de desigualdad (aunque pueden usarse en comparaciones de igualdad).

Por el contrario, un tipo de datos comerciales (o clase de atributo) especifica la semántica de un atributo, por ejemplo:

1. Código de aerolínea: 2 caracteres alfanuméricos
2. Código de puerto: 3 caracteres alfabéticos
3. Número de vuelo: 1 - 4 caracteres numéricos
4. No de secuencia: un ordinal
5. Hora de salida, Hora de llegada: horas del día como horas y minutos, con el rango [00:00 - 23:59]
6. Duración del vuelo: una duración medida en horas y minutos
7. Días de funcionamiento: un conjunto de 7 elementos, cada uno de los cuales es un día de la semana.
8. Día de la semana: lunes, martes, miércoles, jueves, viernes, sábado o domingo.

Dado que especifica tipos de datos comerciales en lugar de tipos de datos DBMS, el modelo de información comercial de la Figura 8 proporciona más información a las partes interesadas comerciales que cualquiera de los modelos de datos lógicos.

Desde una perspectiva empresarial, cada atributo es uno de los siguientes:

• un identificador , utilizado solo para identificar instancias de entidad y que no implica ninguna propiedad de esas instancias, por ejemplo, Flight No
• una categoría, con uno de un conjunto definido de valores, por ejemplo, Clase de viaje (Primera, Business, Economy)
• un cuantificador: un atributo en el que se pueden realizar algunas operaciones aritméticas (por ejemplo, suma, resta) y en el que se pueden realizar comparaciones distintas de “=” y “¹”, por ejemplo, número de pasajeros, fecha de vuelo, hora de salida del día
• un elemento de texto, que puede contener cualquier cadena de caracteres que el usuario pueda elegir ingresar, por ejemplo, nombre de la aerolínea.

Cada una de estas clases de atributos tiene varias subclases, como se describe en (Witt, 2021).

Las herramientas modernas de modelado de datos proporcionan tipos de datos definidos por el usuario para documentar clases de atributos, incluidos tipos de datos de matriz para atributos de valores múltiples como el atributo Días de operación en la Figura 9.

Desarrollo de un modelo de datos lógicos a partir del modelo de información empresarial

Se puede desarrollar un modelo de datos lógicos a partir del modelo de información empresarial mediante los siguientes pasos:

1. clonar el modelo, para preservar el modelo de información empresarial (ver más adelante)
2. eliminar cualquier elemento de datos derivados, en este caso Duración del vuelo
3. cambiar el nombre de todas las entidades y atributos para ajustarse al estándar de nomenclatura vigente
4. si se implementa en otro lugar que no sea XML, agregue claves primarias y muestre claves externas
5. convertir tipos de datos comerciales a tipos de datos DBMS (o XML)
6. si se implementa en un DBMS que no es SQL: 2003, cree una tabla adicional para cada atributo de valor múltiple, en este caso Días de operación.

Es posible que se requieran otros pasos para manejar atributos compuestos, relaciones n: n ("muchos a muchos"), subtipos, registro de historial y reglas de datos, pero estos están fuera del alcance de este artículo. Las descripciones de estos pasos se pueden encontrar en (Witt, 2021).

Compartir código

Un segmento de vuelo determinado es operado por una sola aerolínea, pero la aerolínea operadora puede tener un acuerdo de código compartido con otras aerolíneas, que utilizan sus propios números de vuelo. Por ejemplo, LOT Polish Airlines opera un vuelo LO381 Varsovia-Frankfurt, en el que los asientos también se pueden vender como vuelo LH5715 de Lufthansa, vuelo SQ2381 de Singapore Airlines o vuelo UA6847 de United Airlines. Los tramos de un vuelo de varios tramos generalmente no tienen los mismos vuelos de código compartido: por ejemplo, los asientos en Qantas QF1 se pueden vender como Emirates EK5003 entre Sydney y Singapur, pero no entre Singapur y Londres.

El modelo de información empresarial se puede modificar para adaptarse a esto como en la Figura 10. Después de revisar el modelo de información empresarial modificado, la modificación correspondiente se puede aplicar al modelo de datos lógicos (es por eso que retenemos el modelo de información empresarial en lugar de convertir a un modelo de datos lógicos):

• Si el DBMS de destino es compatible con SQL: 2003, el modelo de la Figura 9 se puede modificar como en la Figura 11.
• Si se ha producido un modelo de datos lógicos SQL tradicional, se puede agregar una tabla de CodeShareFlight para representar el atributo de vuelos de CodeShare; por ejemplo, el modelo de la Figura 4 se modificaría como en la Figura 12.

 Figura 10: Modelo de información empresarial con vuelos de código compartido 

 Figura 11: SQL: Modelo de datos lógicos 2003 con vuelos de código compartido 

 Figura 12: Modelo de datos lógicos tradicionales con vuelos de CodeShare

Conclusiones

1. Las partes interesadas del negocio deben desarrollar y revisar un modelo de información empresarial antes de desarrollar un modelo de datos lógicos.
2. Los modelos de información empresarial están bien definidos en términos de lo que se incluye y excluye, en contraste con los modelos de datos conceptuales.
3. La representación de un modelo de información empresarial en un modelo de datos lógicos depende del DBMS de destino (u otra plataforma de datos), los requisitos de procesamiento y la facilidad para escribir consultas.
4. Se puede desarrollar un modelo de datos lógicos a partir de un modelo de información empresarial siguiendo una serie de sencillos pasos repetibles.
5. Cualquier cambio en el modelo de información empresarial se puede replicar en el modelo de datos lógicos.

Presentaré una descripción general de este método en la Conferencia de datos empresariales de IRM del Reino Unido el martes 16 de noviembre de 2021 a las 11: 10GMT. Se pueden encontrar más detalles y ejemplos en (Witt, 2021).

Bibliografía

Kent, W. (2015). Datos y realidad. Publicaciones técnicas.

Witt, GC (2021). Modelado de datos para la calidad: entrega de beneficios a través de la atención al detalle. Publicaciones técnicas.

Fuente: https://tdan.com/data-modeling-for-quality/28594