Triplestores o almacenando la semántica del conocimiento (II)

¿Cómo podemos imaginar internamente a los triplestores?

Cualquiera que haya estudiando algo de bases de datos conoce los conceptos de normalización y desnormalización y las formas normales asociadas.

La forma quizá más intuitiva de imaginar los triplestores es la de una base de datos, totalmente desnormalizada, en la que tuviéramos una sola tabla con tres columnas, correspondientes a los conceptos de sujeto,predicado y objeto tratados en el post del capítulo anterior.

Para verlo más claramente vamos a comparar que forma irían tomando aproximadamente unos pocos datos en bases de datos relacionales convencionales y en triplestores.

Paso 1. Almacenamos información de personas.

En las BD lo veremos como una tabla individual, en la que definimos unas columas concretas, y en la que insertamos unas filas, considerando cada fila como una persona.

En el Triplestore por contra, tendremos varias filas en el entorno global, cada una de ellas formada por las tres columnas antes mencionadas, en la que iremos haciendo referencia a las distintas propiedades que estamos tratando, entre las que encontraremos: las columnas de la tabla y la pertenencia a la tabla como un hecho en sí mismo.

Este último triple lo podríamos haber obviado escribiendo por ejemplo Persona_1 en lugar de p1 y extrapolando a través de ese “identificador”, pero es un hecho lo bastante importante como para considerarlo independiente y muy relacionado con el modelado de la información que veremos en otra ocasión.

Así mismo, a pesar de que pueda resultar confuso en un primer momento, se ha decidido incluir un espacio de nombres en las columnas que hemos convertido en relación, para que resulte más fácil identificar a qué nos estamos refiriendo.

Paso 2. Ampliamos la BD anterior con información sobre ciudades que están relacionadas de alguna manera con las personas anteriores.

Para su gestión en la base de datos, creamos una tabla adicional. En esta tabla, por simplificación, añadimos una columna que almacenará dicha información, con una estructura de 1…* entre personas y ciudades. Ahondando en dicha estructura, añadiríamos normalmente una clave foránea que exigiera que dicha persona existiera, que impidiera borrados o exigiera su realización en cascada, pero no le daremos importancia a todos esos detalles en esta ocasión.

El triplestore almacenará dicha información a continuación de la anterior (observamos que no le hemos puesto ningún tipo de nombre a la tabla), tratando la relación de la misma forma que el resto de los datos tratados.

Paso 3. Ampliamos la tabla anterior con información sobre el motivo de la relación existente entre la persona y la ciudad.

Al pasar esta nueva columna al triplestore, en lugar de crear nuevas filas para dicha columna se ha decidido transformas las anteriores añadiéndoles ese significado que faltaba en el “relacionadoCon”.

En este último paso empezamos a mostrar cómo enlazamos de forma natural la semántica a la información en los triplestores.

Hay muchas consideraciones a tener en cuenta sobre estas relaciones y habrá ocasiones en las que deberemos darle existencia individual, pero ya veremos esto en otra ocasión.

 

Compartir este artículo