Hablamos mucho sobre que es una etiqueta (un tag), que es una folcsonomía y varios temas relacionados. Ahora bien, si creo mi propia aplicación web 2.0 y quiero generar mi famosa nube de etiquetas (tag cloud), u obtener meta información relativa a dichas etiquetas, ¿cómo hago?

Bien, en el blog tagschema.com de Nitin Borwankar explica bastante bien como hacerlo, y aquí voy a incluir un resumen traducido al castellano de lo que considero más importante de dicho blog.

He tenido la experiencia de hacer aplicaciones web 2.0 utilizando esquema de etiquetas, y es bastante sencillo de implementar si uno tiene los conceptos adecuados para hacerlo.

La Web 2.0 necesita Datos 2.0

Una de las principales características de muchas aplicaciones web 2.0 es que son folcsonomías, clasificando los contenidos por medio de palabras clave o “etiquetas” (tags) mnemotécnicas.

Normalmente estas aplicaciones a diferencia de las aplicaciones “1.0″, por llamarlas de alguna manera, relacionan a los usuarios con lo que denominaremos sus ítems (podrían ser bookmars, fotos, videos, música, o cualquier objeto de una aplicación). En las aplicaciones “2.0″ no solo se relacionan los usuarios con sus ítems, sino que también se relacionan con las etiquetas que les ponen a sus ítems.

Los nuevos modelos de datos, ahora, deberán tener en cuenta una nueva dimensión a la hora de actuar, y esa nueva dimensión son las etiquetas. Para lograr eso de una forma eficiente se debe hacer una especie de datawarehousing. Ese datawarehousing en tiempo real son nuestros Datos 2.0, los datos que utilizaremos por medio de nuestro esquema de etiquetas.

Entonces, el esquema de etiquetas (o tags) representa un datawarehouse de datos etiquetados (o tabeados), y esos serán nuestros Datos 2.0.

Datos 2.0 a fondo

Ahora que sabemos que un esquema de etiquetas (o esquema de tags) no es nada mas ni nada menos que un datawarehouse, para analizar estos esquemas de etiquetas vamos a tener que hacer un análisis de modelos multidimensionales.

Antes de interiorizarnos con profundidad en este tema vamos a darnos cuenta que para cualquier simple aplicación que utilice etiquetas vamos a necesitar tres dimensiones básicas: “Usuario”, “Etiqueta” y “Ítem”. A partir de esas tres dimensiones comenzaremos a hacer el análisis de un esquema de etiquetas.

Con esas tres principales dimensiones se genera lo que en datawarehousing se conoce como “fact table”, y eso es una tabla donde se asocian y convergen las 3 dimensiones. En esa tabla tendremos la información de cada ocurrencia de un evento, como por ejemplo “el usuario X ha puesto la etiqueta Y al ítem Z”. Esta situación se da para todas las etiquetas Y que le incluye el usuario X a todos los objetos Z que posea.

Entonces, si el usuario “pepe” utiliza las etiquetas “cine”, “música”, “literatura” y “ocio” de manera en la que a el le parece con algunos artículos de un sitio web que habla sobre hobbies, en un esquema de etiquetas podríamos llegar a encontrar las siguientes columnas en una “fact table”:

Usuario     Etiqueta        Ítem
----------------------------------------------------------------
'pepe'      'cine'          'http://algohobbies.com/articulo-1'
'pepe'      'cine'          'http://algohobbies.com/articulo-2'
'pepe'      'música'        'http://algohobbies.com/articulo-2'
'pepe'      'cine'          'http://algohobbies.com/articulo-3'
'pepe'      'literatura'    'http://algohobbies.com/articulo-3'
'pepe'      'ocio'          'http://algohobbies.com/articulo-4'

El usuario “juan” tendrá una cantidad similar de campos para todos sus objetos etiquetados, lo mismo para el usuario “laura”.

Las “fact tables” son tablas de asociaciones de múltiple entrada, donde se asocian todas las dimensiones posibles en un solo lugar. Estas tablas permiten una gran cantidad de consultas interesantes para correr, con probablemente, una de las mejores escalabilidades.

Creando un modelo de datos para navegar una folcsonomía

Además de la unión de los Usuarios, Etiquetas e Ítems hay una cantidad de relaciones que, junto con la relación base, forman el modelo de datos 2.0. Exploremos estas relaciones y sus consecuencias para la arquitectura de los datos.

Los Usuarios tienen Ítems (URL’s, fotos, música, etc.), pero un Usuario puede existir en la base de datos sin poseer ningún Ítem, como por ejemplo luego de haberse registrado. Por el lado del Ítem, este terminara siendo incluido en la base de datos solamente si esta relacionado al menos a un usuario (el que lo haya cargado). Entonces, un Usuario tiene quizás-ninguno-pero-posiblemente-muchos Ítems, y un Ítem tiene al-menos-uno-y-posiblemente-muchos Usuarios.

Similarmente, un Ítem puede existir sin ninguna Etiqueta, pero una Etiqueta existe solamente para asignar un valor a un Ítem. Adicionalmente, un Usuario puede no haber etiquetado nada por lo cual no tener ninguna Etiqueta, pero una Etiqueta siempre va a ser asignada por un Usuario.

Teniendo en cuenta esas tres relaciones cíclicas obtenemos lo siguiente:

Usuario  (1-muchos)  <---------> (0-muchos)  Ítems
Etiqueta (0- muchos) <---------> (1- muchos) Ítems
Etiqueta (0- muchos) <---------> (1- muchos) Usuario

Transcribiendo eso para una mejor comprensión podemos obtener este hermoso diagrama:

Aquí podemos ver que hay relaciones muchos-a-muchos entre cada par de entidades. Este modelo que vemos aquí arriba es la representación de un modelo lógico de datos, que al pasarlo a un modelo físico de datos va a requerir algunas modificaciones debido a las relaciones de muchos-a-muchos.

La idea no es dar una clase sobre bases de datos, pero como una breve explicación, la forma estándar de representar las relaciones muchos-a-muchos es crear una tabla de relación en la base de datos, que asocie ambos campos por medio de sus identificadotes.

Por ejemplo si queremos almacenar los Ítems que ha guardado un Usuario, al mismo tiempo que queremos saber los Usuarios que poseen cierto Ítem de una forma eficiente, crearemos una tabla que se podría llamar UsuarioÍtem para resolver la relación de muchos-a-muchos entre esas dos entidades donde cada columna tendrá el identificador del Usuario y el identificador del Ítem. Con la misma lógica tendremos una tabla UsuarioEtiqueta y una tabla ÍtemEtiqueta.

Habiendo creado las tablas de relaciones, el modelo nos quedara similar al siguiente:

Para completar nuestro modelo de datos, como vimos anteriormente, tenemos la famosa “fact table” donde se relacionan los Usuarios, Ítems y Etiquetas en una sola tabla, que puede ser representada de dicha manera:

Ahora bien, seguramente están pensando ¿todo esto para hacer una simple nube de etiquetas?

Bien, si estas pensando en hacer una arquitectura de una folcsonomía a gran escala va a ser necesario algo así, ya que en una primera instancia este modelo resuelve de forma muy simple las preguntas: “¿Cuáles son todos los Ítems de un Usuario?” O “¿Cuáles son todas las Etiquetas de este Ítem?”; pero yendo a un grado mayor de profundidad, nos podemos encontrar con preguntas como: “¿Cuáles son todos los Usuarios que tienen mas Ítems similares entre sí con otro Usuario?”. Usando este modelo, podemos responder muchas consultas sin hacer múltiples JOIN en una base de datos, y cuando hablamos de mas de 250.000.000 de columnas, es algo importante para la performance.

Entonces, como nuestro modelo no puede evitar nunca tener nuestra “fact table” ya que mantiene la coherencia entre los Usuarios, Ítems y Etiquetas, combinando estos dos modelos de datos obtendremos lo que se podría denominar la base de nuestro modelo de datos 2.0, nuestro famoso esquema de etiquetas:

Relacionando datos en una folcsonomía

Si bien SQL es un lenguaje perfectamente adecuado para hacer consultas de datos “tabulares”, no es particularmente elegante para representar las abstracciones que tenemos en mente a la hora de relacionar datos en una folcsonomía, como por ejemplo, relacionar Usuarios, Ítems o Etiquetas entre sí.

Vamos a usar una simple notación para hablar sobre las relaciones entre Usuario-Ítem-Etiqueta, para transformar momentáneamente SQL en un lenguaje un poco más descriptivo. Olvidémonos de SQL por un momento y vamos a seguir esta notación:

Las letras en minúscula “í”, “e” y “u” representaran a un “Ítem”, “Etiqueta” y “Usuario” respectivamente.

Las letras en mayúscula “Í”, “E” y “U” representaran una lista de “Ítems”, “Etiquetas” y “Usuarios”, como una búsqueda.

Veamos algunos ejemplos:

Al pedir U(í), estaremos pidiendo todos los Usuarios de un Ítem í.
(En SQL sería: select u.* from usuarios u, usuarios_ítems ui where u.id = ui.usuario_id and ui.item_id = algun_item_id; )

Al pedir U(e), estaremos pidiendo todos los Usuarios que tengan la Etiqueta e.
(En SQL sería: select u.* from usuarios u, usuarios_etiquetas ue where u.id = ue.usuario_id and ue.etiqueta_id = alguna_etiqueta_id; )

Similarmente obtendremos:

Í(u) serán todos los Ítems de un Usuario u.
Í(e) serán todos los Ítems que tengan una Etiqueta e.
E(í) serán todas las Etiquetas que estén asignadas a un Ítem í.
E(u) serán todas las Etiquetas que haya usado un Usuario u.

Ahora, si buscamos en un segundo grado de profundidad, podremos encontrar consultas un poco mas interesantes que las anteriores.

Por ejemplo, E(U(e)) es una colección de todas las Etiquetas que tienen todos los Usuarios que tienen una Etiqueta e.
(Su SQL sería: select e.* from etiquetas e, usuario_etiquetas ue, where ue.usuario_id in (select usuario_id from usuario_etiquetas where etiqueta_id = alguna_etiqueta_id))

Aquí podemos observar que es mucho mas sencillo decir lo que queremos, “Una colección de todas las Etiquetas que tienen todos los Usuarios que tienen una Etiqueta e”, que su representación en SQL que puede llegar a ser mas compleja de entender sin la explicación previa.

De esta manera, con la notación que hemos utilizado podemos encontrar varias consultas de segundo grado.

Estas consultas las veremos mas adelante en alguna otra publicación, creo que ya es demasiada información por una única entrada.

Compártelo