El documento aborda la importancia del manejo de metadatos en sistemas de gestión documental (ECM) y su impacto en el rendimiento y la búsqueda de documentos. Se destacan preguntas clave sobre la definición de tipos documentales y la gestión de metadatos, así como diversas estrategias para estructurar estos metadatos. Finalmente, se analizan varias opciones para el modelado de datos en bases de datos y sus ventajas e inconvenientes.

1. understanding documents
¿Ofrece tu sistema soporte
para tipos documentales en bases de datos?
¿Por qué debería importarte?
Marzo, 2013
Basado en:
Manejo de metadatos en plataformas ECM
de Joaquín Hierro.
Conoce openprodoc, ECM Open Source Java.
Metadatos
en Plataformas
ECM

2. understanding documents
Cuando se registran metadatos para un documento en un sistema ECM,
estos metadatos se almacenan como registros en una base de datos sin
que el usuario se de cuenta.
Al buscar un documento, en la mayoría de los casos, lo que hacen los
gestores documentales o software ECM es realizar un conjunto de
consultas SQL relacionadas con dichos metadatos. Por esta razón,
la diferencia en tiempos de búsquedas entre un sistema y otro, en buena
mediada, está determinado por esa estructura interna de almacena-
miento de metadatos que elijen los fabricantes de software ECM.
Metadatos:
son datos que describen
un documento o contenido
y que son utilizados para
facilitar el acceso a dicho
contenido.
Tipo documental
Clase de documento
s que se distingue
por la semejanza de
sus características
físicas y/o intelectuales.
Fuente: Norma ISAD
Es posible que quienes se encuentran en la búsqueda de un sistema de gestión de documentos o
contenidos, no se detenga a este nivel; pero es importante que se tenga en mente que la lentitud de
un sistema es una de las principales causas por la que los usuarios dejan de usarlo.
A continuación, repasamos las preguntas fundamentales que debemos hacernos sobre manejo de
metadatos a la hora de adquirir software ECM y algunas de las estrategias que pueden seguir los
fabricantes en esta materia y que delimitan las posibilidades que sus productos pueden ofrecernos.
Pregunta 1: ¿Permite este sistema la definición de tipos documentales?
Existen sistemas para los que no es posible definir tipos documen-
tales.
Estos sistemas traen por defecto una serie de metadatos que son
bastante comunes para todos los documentos y contenidos, por
ejemplo, nombre, fecha de creación o autor. Estos sistemas resul-
tan demasiado limitados y no nos dejarían contar con un cuadro de
clasificación (clasificación documental) medianamente complejo.
Por fortuna, la mayoría de ECMs modernos nos permiten la defini-
ción de tipos documentales, en ese caso, tendremos que hacernos
la segunda pregunta importante.
Pregunta 2: ¿Cómo se manejan los metadatos en los tipos documentales?
Una definición de un tipo documental trae aparejado la estipulación de unos metadatos que descri-
ban cualquier documento que se pueda incluir dentro de esa tipología. Por ejemplo, si definimos un
tipo documental “DNI -Documento Nacional de Identificación español”, sabemos que debemos incluir
metadatos mínimos como “nombre, primer apellido, segundo apellido, número DNI”. No incluiríamos
nunca dentro de este tipo documental un metadato “número de factura” porque dicho metadato no
es una característica que describa al tipo documental DNI.
Como se explicó al comienzo de este white paper, los fabricantes de software de gestión documental
y ECM van a definir la manera en que almacenan dichos metadatos en una base de datos y esta
decisión va a afectar el rendimiento de la herramienta.

3. understanding documents
Orientación a Objetos
Entender los tipos
documentales como objetos
de la vida real, con unos
atributos que les identifican
y con la capacidad de
agrupar conceptos
relacionados que comparten
atributos comunes.
El manejo de metadatos de un gestor puede estar o no orientado
a objetos.
Decimos que un sistema de gestión documental es orientado a
objetos cuando trata a los tipos documentales creados en él como
objetos con capacidades de herencia y polimorfismo.
Herencia: se considera la existencia de herencia cuando
tipos documentales definidos a partir de otros, heredan dinámica-
mente de ellos sus metadatos, seguridad, ciclo de vida, y restric-
ciones. Por ejemplo, si se define un tipo de documento “Informe”
(documento padre), que contenga como atributos Titulo, Autores,
Fecha, Resumen y Palabras Clave, y un subtipo “Informe Médico”,
Aunque los sistemas gestores de bases de datos cuentan con mecanismos de optimización de con-
sultas, el rendimiento de la base de datos no será comparable nunca entre un sistema con una
estructura adecuada y otro con una inadecuada.
¿cuáles son pues las posibilidades de estructurar los metadatos que tienen los fabricantes?
Opción A. Metadatos normalizados que se reutilizan (Diccionario de metadatos)
Definición de
Metadatos
Creación de
tipos
Asociación de
Metadatos a tipos
Esta estructuración de los metadatos permite que se creen tablas por cada metadato y ofrece un alto
nivel de normalización. Su defecto es que nos limita a la hora de modificar las características de un
metadato en un tipo documental concreto, ya que ese metadato es compartido por otros. Por ejem-
plo, tenemos varios tipos documentales que llevan el campo “documento de identificación” y este
metadato se ha definido en la base de datos con una características pensadas para un DNI (sólo
admite 9 dígitos); pero de repente, necesitamos que uno de esos tipos documentales acepte en su
metadato “documento de identificación” 10 dígitos. ¿Cómo podremos hacerlo?
Opción B. Metadatos que se definen para cada tipo
Definición de
tipo X
Definición de
Metadatos para
tipo X
Cuando un gestor trabaja con este sistema, se definen metadatos individualizados para cada tipo. Ni
se reutilizan ni se normalizan. Aunque este sistema produce una proliferación de definiciones des-
normalizadas, ofrece mayor flexibilidad y junto con Orientación a Objetos y una normalización por
procedimientos o equipo centralizador puede permitir un funcionamiento más ágil.
Orientación a Objetos

4. understanding documents
Polimorfismo: Hablamos de polimorfismo en un gestor documental si para cualquier operación o
proceso en que se espera un tipo de documento (padre), puede aceptarse un documento de cualquiera
de sus subtipos (hijos). Por ejemplo, si busco un tipo documental “Documento de Identificación”, el
gestor me devuelve también DNIs y Pasaportes.
Modelado de metadatos
Ya hemos visto a nivel teórico cómo podemos entender la estrategia de estructuración de metadatos y
tipos documentales en un sistema de gestión documental o ECM. Ahora vamos a considerar cómo ese
modelo puede ser plasmado en tablas del sistema de gestión de bases de datos.
Opción A. Tabla única con columnas mixtas
En esta opción agruparíamos bajo la misma tabla todos los tipos documentales y sus metadatos. Cada
fila de la tabla constituiría un documento de cierto tipo documental y sus respectivos metadatos. Las
columnas son metadatos de clases no necesariamente coincidentes. Para el Documento de tipo 1, el
Atributo 1 puede ser un DNI, para el Documento de tipo 2 el atributo 1 puede ser una matricula de un
coche.
Tipo documental Atributo 1 Atributo 2
Documento de tipo 1 Metadato1 para tipo 1 Metadato2 para tipo 1
Metadato2 para tipo 2Metadato1 para tipo 2Documento de tipo 2
Cada entrada de la tabla contiene los metadatos por orden, y un atributo adicional que es
el tipo documental.
Las limitaciones de este opción son las siguientes:
- No se puede añadir más columnas/metadatos que las definidas.
- No se puede superar la longitud máxima definida para cada columna.
- Los tipos de datos que deben utilizarse no reflejan fielmente los datos contenidos en la
tabla.
- La comprobación y formato de los tipos la hace el gestor documental, no la base de datos.
- No es posible crear índices en la base de datos para optimizar las búsquedas o limitar valores,
ya que la misma columna comparte tipos de metadatos diferentes con restricciones distintas.
- Esta tabla única crecerá de forma indefinida, limitando el rendimiento del sistema.
este heredaría automáticamente los metadatos del tipo padre. La ventaja de esta estrategia es que en
los documentos hijos sólo tendríamos que definir unos pocos metadatos que los hacen especiales y
difrentes del padre y de sus hermanos. En el caso del “Informe Médico” podemos pensar en nuevos
atributos, distintos de los del padre, como Especialidad Médica.

5. understanding documents
Opción B. Tabla única con columnas homogéneas
Tipo documental Atributo 1 Atributo 2
Documento de tipo 1 Metadato 1
Metadato 1Documento de tipo 2
En esta opción sólo existe una tabla que resulta de la unión de los metadatos de todos los tipos, pero
en cada registro o fila sólo se rellenan los matadatos pertenecientes a ese tipo. Esto implica la presen-
cia de filas con atributos vacíos en la tabla. Por ejemplo, si el Documento de tipo 1 es un DNI y el
Atributo 1 es un número de DNI, en el registro de Documento tipo 2 que es una receta médica, el
atributo 1 quedaría vacío, pero no el atributo 2, que es el número de la Seguridad Social.
Las ventajas que esta opción nos ofrece son:
- Los tipos de datos reflejan realmente los datos contenidos
- Puede crearse índices de BBDD para optimizar el acceso a la información
- Hace posible implementar un modelo orientado a objetos que permita buscar en varios tipos
documentales simultáneamente.
Esta opción también tiene algunas limitaciones:
Documento Atributo 1 Atributo 2
Documento 1 Metadato 1 Metadato 2
- Crecimiento imparable de la tabla, tanto en número de columnas (metadatos) como en
número de registros (documentos).
- En esta tabla los datos deben marcarse como NULL (ninguno metadato puede ser obligato-
rio), ya que en todas los registros se cumplirá que queden atributos sin rellenar.
Opción C. Una tabla por tipo documental
En esta opción se define una tabla por cada tipo documental existente. Los registros la tabla (filas) se
corresponden con documentos de esa tipología y las columnas con los metadatos que corresponden
a ese documento en particular.
Tabla tipo 1

6. understanding documents
Documento Atributo 1 Atributo 2
Documento 1 Metadato 1 Metadato 2
Atributo 3
Metadato 3
Tabla Padre
Documento
Documento 1
Atributo 4
Tabla Hijo
Las principales ventajas de este modelo son:
- Refleja fielmente el modelo relacional.
- Permite la creación de índices en la base de datos para optimizar el acceso y asegurar unici-
dad de valores.
- La información se encuentra en distintas tablas, lo que hace a las búsquedas bastante
eficientes.
Los principales inconvenientes son:
- Si desconocemos el tipo documental buscado, la búsqueda debe hacerse en múltiples tablas,
lo que implica una operación de UNION entre muchas tablas. Esto puede consumir grandes
recursos y sacrificar el rendimiento del sistema, e incluso, superar los límites impuestos por el
sistema de gestión de bases de datos.
Opción D. Tabla parcial por cada tipo documental
En esta opción, cada tipo documental genera una tabla, pero esta tabla sólo contiene los metadatos o
atributos que no están contenidos en la tipología padre. Volviendo al ejemplo de las tablas “Informe” e
“Informe Médico”, la tabla “Informe” tendría los campos Titulo, Autores, Fecha, Resumen y Palabras
Clave; y la tabla “Informe Médico” sólo contendría el metadato Especialidad Médica. Las tablas
tendrían que estar relacionadas mediante un identificador de cada documento.
Entre las ventajas de esta opción encontramos:
- La creación de índices
- Las tablas compactas y con pocas columnas.
- Puede hacerse búsquedas y operaciones con herencia fácilmente, ya que en cualquier tabla
está la información de un Tipo Documental y todos sus subtipos.

7. understanding documents
Los principales inconvenientes son:
Metadato 1
Documento Valor Metadato
Valor Metadato 1 en Documento 1
Valor Metadato 1 en Documento 2
Documento 1
Documento 2
- Debe hacerse un acceso a multiples tablas para mostrar todos los metadatos de un docu-
mento.
Opción E. Una Tabla Por Metadato
Para cada metadato se crea una tabla que se relaciona con el documento que contiene dicho meta-
dato.
Las ventajas de esta opción son:
Los principales inconvenientes son:
- Las tablas creadas son relativamente compactas y con pocas columnas, aunque tendrán
muchos registros.
- Siempre que se desea recuperar los metadatos de un elemento, debe accederse a varias
tablas.
- Las búsquedas son siempre complejas y sobre varias tablas.
- No puede imponerse condiciones de unicidad ni índices de base de datos.
Opción F. Esquemas de metadatos
Un esquema de metadatos es un conjunto de metadatos que incluye unas reglas de uso y una sinta-
xis. Los esquemas se desarrollan para un propósito concreto. Un ejemplo de esquema de metadados
es el famoso Dublin Core que incluye 15 metadatos distintos (Por ejemplo: Autor. Título y Tema).
Un tipo documental puede contener los metadatos incluidos en varios esquemas, por ejemplo, el
Dublin Core más otro esquema específico.
Los sistemas modernos ECM tienden a usar el concepto de esquemas para el manejo de tipos,
además de la herencia.
Por ejemplo, en Athento, todos los documentos son del tipo documento (tipo padre), pero a su vez,
tienen un subtipo: pueden ser una nota o una carpeta. Y cada uno de estos subtipos es definido por
la combinación de un número de esquemas.

8. understanding documents
La ventaja del uso de esquemas es que nos permite normalizar y reutilizar metadatos. Así, un tipo
documental nota y un tipo carpeta pueden usar el esquema Dublin Core.
Este sistema tiene como ventajas todas las de los anteriores modelos:
Reutilización y normalización
Rapidez en las consultas
Tablas compactas
Capacidad para usar índices.
Como desventajas, las bases de datos de los sistemas que usan esquemas y tipos documentales con
herencia suelen tener un gran tamaño y una gran complejidad.
documento pertenece contiene Esquemas
tipo
documental
Las relaciones entre las tablas de esquemas y de tipos documentales, pueden ser gestionadas por la
base de datos, o por el sistema de gestión documental en orden de obtener mayor flexibilidad.
Esperamos que este white paper os haya resultado de utilidad. Para cualquier duda, no dudéis
en preguntarnos.
(1:N) (N:M)
askourteam@athento.com
@athento
www.athento.com
2013