Modelo relacional de datos es la representación del modelo de datos destinado a un Sistema Gestor de base de datos relacional. En este modelo de datos se define la lógica de negocio respecto a la relación de los datos. Vimos la estructura de datos de COBie en otra entrada de este blog. Una estructura que puede ser utilizada con distintos tipos de formatos de datos. Uno de ellos como hojas Excel en que cada hoja es una tabla. Además viene con una leyenda en la que con colores se identifica algo muy importante del modelo relacional de datos: las Foreign Keys (Claves ajenas/Claves foráneas). Las Foreign Keys sirven para relacionar las distintas tablas de datos.
Por ejemplo, si vemos la tabla Component podemos deducir que se relaciona con Contact, Type, Space porque tienen campos que se corresponden con el campo principal o identificativo de la tabla con la que se relacionan. Así es CreatedBy (Contact – Email), TypeName (Type – Name), Space (Space – Name). Esto surge por cómo es el modelo de datos COBie. Sin embargo, nuestro modelo de datos no tiene por qué ser igual.
¿Por qué nuestro modelo de datos es diferente?
Nuestro modelo de datos puede necesitar todos o solo unos campos del modelo de datos relacional de COBie. Así como, muy probable, necesitemos tener muchos otros datos para nuestro servicio o aplicación. No hay que olvidar que COBie sirve como un formato de intercambio de información. Por lo que, los datos deben adaptarse a este formato para ser exportados. Así como, luego deben ser adaptados a nuestro modelo cuando sean importados.
Para la tarea de migración de datos podemos hacer uso de herramientas ETL (Extract, Transform, Load). ETL es un proceso que se automatiza con aplicaciones específicas destinadas a ello.
- Primero, se encargan de leer o extraer los datos desde distintas fuentes de datos.
- Segundo, se programa la lógica de transformación de datos para adaptarlos al interés del negocio u objetivo.
- Y finalmente, se cargan, guardan o envían al destino deseado.
Algunos software utilizados para ETL:
- Microsoft SQL Server Integration Services
- Oracle Data Integrator
- Pentaho Data Integration
Repito: el modelo de datos representa la lógica de negocio respecto a la relación de los datos. Cada servicio tienen sus particularidades y eso define en el modelo de datos. Así que nuestro modelo de datos va a ser diferente.
¿Se debe cambiar el modelo de datos COBie? Puede. Lo que hay que tener claro es que es un modelo genérico para servir de intercambio entre distintos modelos. No se va a adaptar a uno en particular. Y de esto ya se encargan las instituciones de estandarización.
Si tomamos exacto el modelo de datos relacional de COBie deben existir campos que son Primary Key (clave primaria). Y son a los que las Foreign Key hacen referencia. Los campos de clave primaria sirven para identificar de manera unívoca a la fila dentro de la tabla. Y por ello, este campo no admite valores nulos, ni repetidos.
Por ejemplo, si tenemos al componente: «Mesa-3000». Su nombre debe ser único para poder identificar al elemento. Y si esa «Mesa-3000» está en el espacio «Aula-30» debe existir un solo espacio con ese nombre. Caso contrario no podría ubicar a los elementos en un espacio de forma unívoca. ¡Obvio?
¿Por qué el nombre relaciona? porque se está utilizando los nombres como identificativos y por ellos se relaciona en el modelo de datos COBie. Y por eso se especifica que un libro Excel (cuando se usa este formato) debe corresponderse con los datos de una sola instalación (Facility). Además, se entiende que en dicha instalación los nombres son únicos. Sin embargo, si en mi servicio gestiono los datos de varias instalaciones, o pueden llamarse los elementos igual, el nombre no debe ser identificativo. Entonces, lo mejor es utilizar otro campo como identificativo. Por ejemplo, spaceid identifica el espacio. Entonces, en el modelo relacional el campo que se utiliza como clave ajena en Component es spaceid y no el nombre.
Ejemplo de modelo relacional
A continuación una leve modificación en la que se cambian las claves primarias de las tablas (Solo se utiliza unas pocas tablas). Y se agrega cuatro campos más como ejemplo de nuevos datos que por la supuesta lógica de negocio se necesitan. Por ejemplo, porque se quiere identificar quién y cuándo crea un elemento. Así como quién y cuando realizó la última modificación.
El porqué del campo clave ajena y clave primaria es por reglas de modelado de datos. Con ellas se evita redundancia de datos, problemas de gestión de datos. No es algo nuevo. Y es el principal modelo de datos utilizado por décadas.
¿Se puede utilizar el GUID como clave principal? Sí, se puede. Pero se debe mantener las reglas de integridad referencial. Si tenemos una base de datos mal diseñada tendremos los problemas que debería evitar.
Si estáis interesados en aprender sobre esto, aprended sobre Modelo Entidad/Relación, Modelo Relacional como parte de tener una base sobre gestión de datos. Y es por ello que en los Master BIM de IDESIE se introduce en estas bases.
