El modelado conceptual, o si se quiere el modelado semántico, es una zona nebulosa en la gestión de datos. Parece que tenemos un acuerdo que indica que es necesario un cierto desacuerdo sobre lo que es, y un poco de comprensión de cómo hacerlo. Sin embargo, creo que ahora estamos en un punto en el que nos veremos obligados a tratar con modelado conceptual de una manera mucho más seria que en el pasado.
Problemas de definición
Yo defino un modelo conceptual como «un modelo de información empresarial únicamente como información sin ningún tipo de concepto asociado a la forma en cómo se pueden almacenar esos datos.»
Para mí, un modelo conceptual no es un modelo de datos en ningún sentido, porque no es parte de ningún esfuerzo para diseñar una solución de almacenamiento de datos. Es un modelo que captura la información utilizada en un área particular de la empresa.
Existen otras definiciones de «modelo conceptual». Resulta confusa la definición ANSI / SPARC en la que el «esquema conceptual» es algo que se describe como: «… todos los elementos de datos y relaciones entre ellos, junto con las restricciones de integridad (posteriores). Hay sólo un esquema conceptual por cada base de datos.» Esto es esencialmente lo que comúnmente se llama un «modelo lógico de datos.»
Luego está el «modelo conceptual de datos», definido por Tom Haughey como «un modelo de datos de nivel alto o de datos secundarios que es preliminar en su estructura, posiblemente abstracto en el contenido y escaso en atributos, que está destinado a representar un área de negocio. Es preliminar en la estructura, porque puede contener relaciones de muchos-a-muchos».
Yo creo que un modelo conceptual de datos tiene un lugar en la gestión de datos, como paso previo a un modelo de datos lógico. Sin embargo, carece de la cantidad de detalle que cabría esperar de un modelo conceptual real y sufre de estar orientada a un diseño de almacenamiento de datos en lugar de una descripción completa de una realidad empresarial.
Modelos de datos y el paradigma relacional
Hay una fuerte evidencia de que los modelos conceptuales son cada vez más importantes de lo que fueron en el pasado. En esencia, los modelos conceptuales se están divorciando de los modelos de datos tradicionales, y el divorcio es probable que se torne un gran lío, debido a la forma en que los modelos de datos y los modeladores de datos han crecido desde la década de 1970.
El modelamiento de datos tal y como lo conocemos hoy en día está inextricablemente vinculado con el paradigma de la base de datos relacional, considerando la forma en que las columnas de las tablas de las bases de datos están «relacionadas» entre sí. El paradigma relacional es tan omnipresente que los modeladores de datos no se dan cuenta de cuánto modelado de datos presupone. Y el paradigma relacional ha sido enormemente exitoso. Ha sido la tentación de pensar, por tanto, que un modelo de datos lógicos, puede realmente representar a la empresa, hasta pensar que un modelo lógico de datos es el mismo que un modelo conceptual.
El Big Data
Pero ahora las cosas están cambiando. El éxito de bases de datos basadas en columnas, ha supuesto todo un reto para el paradigma relacional, al utilizar dichas herramientas en ambientes corporativos con enormes cantidades de datos. Por supuesto, hay un enorme despliegue publicitario que infla el concepto de Big Data, pero también es una realidad que demanda atención. Para utilizar las bases de datos basadas en columnas con éxito hay que desaprender el paradigma relacional. He visto esto en un proyecto de petabytes que trabajé, y puede ser algo feo. Una vez que el paradigma relacional se desecha, el modelamiento de datos, tal como lo conocemos sale del esquema también. Sin embargo, la necesidad de comprender qué hacer con los datos en términos de negocio permanece.
El desafío de gestionar la big data, radica en destilar esa información en formas que se ajusten en los modelos que tienen los usuarios de negocios acerca de sus requerimientos de información – para extraer esos datos y derivarlos a modelos conceptuales. Por supuesto, también es cierto que se necesitan modelos de datos para diseñar un espacio de datos de big data, pero éstos son también no relacionales y deben venir después de detallados modelos conceptuales. La razón es que en el big data no hay una aproximación del modelo conceptual y el modelo de datos lógico como podría haber en el paradigma relacional.
Y así fue también en la época anterior a las bases de datos relacionales. ISAM, VSAM, IMS, ADABASE, IDMS y los almacenes de datos pre-relacionales no pudieron ser diseñadas utilizando técnicas de modelamiento de datos de Entidad-Interrelación (ER), construidas sobre los fundamentos del paradigma relacional.
Y, a decir verdad, esto también es válido cuando las bases de datos relacionales utilizan patrones genéricos para almacenar los datos. Por ejemplo, recientemente pasé varias semanas produciendo modelos conceptuales para diferentes tipos de clientes institucionales, alojados en una base de datos genérica bajo un patrón con un diseño de base de datos relacional. Mis modelos conceptuales no guardaban ningún parecido con el diseño del almacén de datos relacional.
Lo que el modelado de datos no puede hacer
Si realmente modelamos información de negocios con todo detalle, y lo comparamos con lo que encontramos en los modelos de datos típicos, existen divergencias significativas. Hay cosas que necesitamos representar en los modelos conceptuales que, o bien no están representados o no pueden ser representados en los modelos de datos tradicionales. Estos incluyen:
– Las relaciones entre los atributos que no son clave en una entidad. Por ejemplo, el «monto total de ventas» se relaciona con la «moneda del monto total de ventas» por la relación «está denominada en», pero la relación no puede ser expresada en un modelo de datos.
– El uso de tablas de código. Dondequiera que se utiliza una tabla de código, los registros físicos que contiene representan conceptos de negocio que no han sido capturados y definidos en el modelo de datos utilizado para diseñar la base de datos en la que están almacenadas las tablas de código.
– Niveles de abstracción. El «Monto total de ventas» como una columna en una base de datos representa una pieza de información empresarial. Sin embargo, Fecha-Hora de última actualización son metadatos de un registro. Si una entidad tiene ambos atributos que son los datos y los atributos que son metadatos, no puedo representarlos como si fueran diferentes niveles de abstracción.
Los modelos conceptuales deben capturar todos los conceptos de negocio y todas las relaciones relevantes. Si las instancias de las cosas también son parte de la realidad empresarial, también deben ser capturadas. Desafortunadamente, no existe una metodología estándar y notación para hacer esto. Los modelos conceptuales que comunican la realidad empresarial de forma eficaz requiere un cierto grado de imaginación artística. Son productos de análisis, no de diseño.
Hoy en día, los entornos de Big Data nos presentan una brecha entre el diseño de almacenamiento de datos y la información comercial que no se puede enlazar utilizando solo un modelo. La realidad es que este problema siempre ha estado presente en algún grado, incluso durante el apogeo del paradigma relacional. ¿Cómo el problema será resuelto? eso es un asunto distinto, pero con el tiempo se resolverá.
Malcolm Chisholm, Ph.D. tiene más de 25 años de experiencia en gestión de información empresarial y gestión de datos y ha trabajado en una amplia gama de sectores. Él escribe numerosos artículos y es un presentador frecuente en estos temas en eventos de la industria. Chisholm administra http://www.bizrulesengine.com y http://www.refdataportal.com y http://www.data-definition.com. Chisholm es el ganador del Premio al Logro Internacional 2011 DAMA.
Fuente:
http://www.information-management.com/newsletters/data-model-conceptual-big-data-Chisholm-10022303-1.html?pg=2