PDF de programación - ERAV: Almacenamiento de Relaciones con Atributos Diversos en Bases de Datos Relacionales

Ninth LACCEI Latin American and Caribbean Conference (LACCEI’2011), Engineering for a Smart Planet, Innovation, Information
Technology and Computational Tools for Sustainable Development, August 3-5, 2011, Medellín, Colombia.



ERAV: Almacenamiento de Relaciones con Atributos Diversos en

Bases de Datos Relacionales



Adolfo Di Mare, Universidad de Costa Rica

[email protected]

RESUMEN

La representación "ERAV" (Entidad Relación Atributo Valor) es un método simple para almacenar en una base
de datos relacional los valores para entidades descritas por atributos diversos o distintos, como los atributos que se
necesitan para describir entidades que no tienen una estructura rígida de tabla relacional. Esta solución permite
manipular los datos almacenados usando SQL tradicional y también mantiene gran coherencia con soluciones
XML.
Palabras clave: Relaciones con atributos diversos, diseño de bases de datos, representación de objetos, esquema
de bases datos.


ABSTRACT

The "ERAV" (Entity Relation Atribute Value) representation is a simple method for storing in a relational
database values for entities described by diverse or different attributes, as those attributes needed to describe
entities that do not have the rigid structure of a relational table. This solution allows the manipulation stored data
using traditional SQL and also maintains great coherence with XML solutions.
Keywords: Relations with divese attributes, data base design, object representation de objetos, data base schema.

1. INTRODUCCIÓN
Ya los sistemas relacionales de bases de datos son de uso común en muchas aplicaciones; por ejemplo, el SQLite
desarrollado por D. Richard Hipp [Hipp-2000] permite utilizar un motor relacional como si fuera una subrutina en
un programa C o C++. Desafortunadamente, las bases de datos relacionales son excesivamente estructuradas y por
eso en muchos casos se utiliza XML para incorporar en los programas de aplicación datos etiquetados y
organizados jerárquicamente. Aunque en muchos contextos esta solución es adecuada, con este trabajo mostramos
que si se usa la representación "ERAV" (Entidad Relación Atributo Valor) se puede lograr representar la misma
información en una base de datos relacional, para luego procesarla usando SQL directamente.
En este trabajo se muestra cómo utilizar un Sistema Relacional de Administración de Bases de Datos (RDBMS:
Relational DataBase Management System) para almacenar valores y relaciones entre entidades que representan
productos y servicios, con el fin de usarlos es contextos en que XML también es otra alternativa de solución. Esto
no quiere decir que se busque suprimir XML, que es una herramienta muy útil en muchos contextos, sino más
bien complementar su utilización al lograr almacenar el contenido XML para ser consultado con SQL.

automotor(toyota) automotor(hyundai)
| |
+--- mecánico +--- dueño
| | |
| +---revisión +--- aceite
|
+--- dueño


9th Latin American and Caribbean Conference for Engineering and Technology

Medellín, Colombia

WE1-1 August 3-5, 2011



automotor( K=1110111 , ID=0000 , SUB=0000 ,"toyota", cantidad puertas , color )
mecánico( K=1110111 , ID=0101 , SUB=0000 , nombre , teléfono , dirección )
revisión( K=1110111 , ID=0201 , SUB=0101 , fecha , monto )
revisión( K=1110111 , ID=0202 , SUB=0101 , fecha , monto , ACEITE )
revisión( K=1110111 , ID=0203 , SUB=0101 , fecha , monto )
mecánico( K=1110111 , ID=0102, SUB=0000 , nombre , teléfono , dirección )
revisión( K=1110111 , ID=0205 , SUB=0102 , fecha , monto )
dueño( K=1110111 , ID=0301 , SUB=0000 , fecha )
dueño( K=1110111 , ID=0302 , SUB=0000 , fecha )

automotor( K=2220222 , ID=0000 , SUB=0000 , "hyundai" )
dueño( K=2220222 , ID=0101 , SUB=0000 , "Pedro Mecánico" , teléfono , dirección )
aceite( K=2220222 , ID=0201 , SUB=0000 , fecha="20051302" )

Figura 1

Como se muestra en la Figura 1, en algunas ocasiones los valores que es necesario almacenar para una entidad no
son simples. En este ejemplo se usan varios registros para almacenar los datos de varios vehículos: para el
"toyota" hay que almacenar las revisiones mecánicas del automotor, agrupadas de acuerdo a la persona que las
realizó; también hay que registrar la lista de dueños, pero en este caso solo hace falta conocer la fecha en que cada
nuevo dueño adquirió el vehículo. Para el "hyundai" hay que registrar la lista que contiene todos los cambios
aceite junto con la lista de los dueños anteriores. Para cada una de estas instancias, la jerarquía de valores a
almacenar es distinta: para el "hyundai" hay un registro padre con 2 registros hijos, mientras que para el "toyota"
la jerarquía es raíz - hijo - nieto. Lo más natural es registrar todos estos detalles usando un identificador único
para cada automotor: en este caso se usa el número "1110111" para el "toyota" y "2220222" para el "hyundai". En
algunos casos se ha usado el nombre del atributo en lugar de su valor específico para hacer el ejemplo más
legible.
La llave de cada registro se ha completado usando 2 identificadores adicionales, "ID" y "SUB" que indican,
dentro de cada automotor, la relación jerárquica: la raíz tiene su marcador "ID" en cero "0000" y el campo "SUB"
indica cuál es el padre inmediato de cada registro; por supuesto, dentro de una misma entidad ("1110111" y
"2220222" en este caso), todos los valores de "ID" deben ser diferentes para cada registro.
También la Figura 1 es muestra de que los valores almacenados pueden ser arbitrariamente diversos. Por ejemplo,
para la "revisión" del vehículo "toyota" marcada con el identificador "ID=0202" existe un valor para el atributo
"aceite", mientras que para las otras 2 revisiones, de identificador "0201" y "0203", ese atributo simplemente no
existe (cuarto renglón). Si se modificaran estos esquemas para que cumplan con la primera forma normal de las
bases de datos relacionales, también cumplirían con la forma normal de Boyce-Codd debido a que la llave de
todas las relaciones sería "[K+ID]" y la dependencia funcional "[K+ID]→SUB" no sería una dependencia
funcional parcial.

2. LA ALTERNATIVA XML PARA REPRESENTAR INFORMACIÓN
Es innegable que la información jerárquica puede representarse con gran sencillez usando XML para el que ya
existe un lenguaje de consulta bien estructurado [XQuery-2007]. Se puede almacenar un documento XML como
un gran BLOB (Binary Large OBject) en la base de datos, para luego hurgar dentro de él con Xquery.

<entity ID_ENT="2220222">
<record REL_TYPE="e" ATTRIB="automotor" VAL="">
<attrib REL_TYPE="s" ATTRIB="marca" VAL="hyundai" />

<record REL_TYPE="e" ATTRIB="dueño" VAL="">
<attrib REL_TYPE="s" ATTRIB="nombre" VAL="Pedro Mecánico" />
<attrib REL_TYPE="i" ATTRIB="phone" VAL="77538888" />
<attrib REL_TYPE="s" ATTRIB="dirección" VAL="3 kms al este del Guayabero" />
</record>

<record REL_TYPE="e" ATTRIB="aceite" VAL="">
<attrib REL_TYPE="d" ATTRIB="fecha" VAL="20051302" />
</record>
</record>
</entity>

Figura 2



Medellín, Colombia

9th Latin American and Caribbean Conference for Engineering and Technology

WE1-2 August 3-5, 2011



Hay muchas formas de representar en XML los datos de la Figura 1 pero el formato usado en la Figura 2 tiene la
ventaja de que sigue la estructura jerárquica que tienen los registros. Para el "hyundai" el valor del campo
"REL_TYPE" indica el tipo del dato: "e" para entidad (o registro), "s" para "string", "i" para "int", etc. La etiqueta
"entity" contiene la identificación única de la entidad (producto o servicio). Cada renglón marcado "ATTRIB" es
un atributo cuyo valor aparece en el parámetro "VAL": como la marca del auto identificado con el número
"2220222" es "hyundai", hay un renglón de atributo que incluye ese valor específico (se usa el inglés para
nombrar los identificadores para facilitar la reutilización de los módulos en otras aplicaciones).
El anidamiento de los registros de la Figura 1 se logra poniendo renglones dentro de un bloque etiquetado
"record", que puede contener tantos atributos como sea necesario para describir a la entidad: esa es la flexibilidad
inherente de XML.
En un ambiente en que el poder de cómputo es amplio, como ocurre con los programas que corren en potentes
servidores de aplicación empresariales o institucionales, tiene mucho sentido usar XML para representar este tipo
de información, pues la mayor parte de los sistemas administradores de bases de datos contemporáneos brindan
apoyo XML adecuado, más si se toma en cuenta que es posible utilizar expresiones "FLWOR" (For Let Where
Order by Return) que extienden la funcionalidad de las expresiones XPath para ponerlas a la par de la
funcionalidad SQL de las bases de datos relacionales [Kay-2006].
Hay otros escenarios en los que XML no está disponible. Por ejemplo, si se construyen programas para
procesadores embebidos o empotrados, puede que ocurrir que no esté disponible procesador XML adecuado. Por
ejemplo, si se escoge para la implementación el motor de bases de datos SQLite, es po