Descripción Modelo Entidad Relación Drupal Autora Marc Bria Ramírez

Modelo de datos de Drupal 5.7
y Content Construction Kit

Autor:

Marc Bria Ramírez
marc.bria@uab.cat

Fecha:

15 Junio 2008

Revisión:

1.2

Licencia:

CC-by-nc-sa

Modelo de datos “Drupal 5.7” con CCK

Página 2

Índice de contenido
Introducción......................................................................................................................................................3
Modelo de Datos de Drupal..............................................................................................................................5
Diagrama EntidadRelación.........................................................................................................................7
Las tablas de Nodos................................................................................................................................7
Las tablas de Vocabulario.....................................................................................................................13
Las tablas de Usuario y permisos..........................................................................................................16
Otras tablas de interés...........................................................................................................................19
Diccionario de Datos.................................................................................................................................22
Estrategias de migración.................................................................................................................................54
Migración “directa” y post procesado en Oracle........................................................................................54
Scripts “al uso”..........................................................................................................................................55
Módulos de Drupal (Views + CSV export)................................................................................................55


Página 3

Prefacio
El siguiente texto es una revisión de un documento previo, escrito a petición de la empresa
“ACME Inc.” para facilitar la migración de un desarrollo Drupal la plataforma .NET/Oracle de la
corporación.
Como el suspicaz lector sospechará, mantenemos confidencialidad sobre la identidad y datos de
dicha empresa, pero se ofrece a la comunidad el estudio al considerar que el análisis realizado
puede ser de ayuda en:
1. Futuras migraciones: En aquellos casos en los que se topen con un equipo de IT miope,
(incapaz de apreciar la belleza de el mencionado CMS), asustadizo (por el hecho de
trabajar con desarrollos libres), perezoso (al no querer aprender nada nuevo),
perjuicioso (convencidos de que los desarrollos libres carecen de calidad, son
inseguros...) y/o rígido (al ser incapaces de emplear desarrollos más allá de lo
dictaminado por la coorporación).
2. Comprensión de la herramienta: En aquellos casos en los que sea necesario formar a
nuevos desarrolladores o se busque ahondar en la manera en que la herramienta trata sus
datos.
Como reza su título, este documento versa sobre Drupal 5.7, por lo que la validez de lo descrito
está sujeta a futuros cambios.
Este texto se ha escrito bajo una licencia Creative Commons 2.5 en la que se obliga al
Reconocimiento de la obra, no se permite su uso Comercial y admite obras derivadas siempre y
cuando se compartan bajo la misma licencia.
Así mismo, agradeceríamos que informen al autor si emplean o mejoran esta obra.
Esperamos disfruten con estas líneas, tanto como hemos disfrutado nosotros al escribirlas.


Página 4

Introducción
Drupal es un CMF (Content Management Framework) explotado en este proyecto en su faceta de
RAD (Rapid Application Development).
Drupal y sus módulos garantizan un rendimiento eficaz, ofreciendo un entorno seguro y
escalable, como lo constatan importantes desarrollos internacionales en distintas áreas1.
La enorme versatilidad de este Framework de Gestión de Contenidos (CMF) se sustenta sobre
dos pilares esenciales: El primero de ellos es que ha sido concebido desde sus más tiernos inicios
como una herramienta modular, en la que añadir nuevas funcionalidades puede resultar tan
simple como añadir nuevos módulos. El otro motivo consiste en abstraer las unidades básicas de
contenido que gestiona en lo que denomina “Nodos”. Los Nodos pueden “instanciarse” en forma
de páginas web, eventos de calendario, noticias o cualquier conjunto de datos y metadatos que
agrupados entendemos como la información a administrar.
Esta versatilidad es la principal virtud de Drupal y en el contexto de análisis que nos ocupa,
también presenta un ligero inconveniente, pues si bien es cierto que el desarrollador puede
prestar mayor atención a los requisitos funcionales del cliente, el modelo de datos suele perder su
tradicional relevancia y –al menos inicialmente– queda “oculto” tras el sistema. Un posterior
estudio de la base de datos en la que reside Drupal, muestra que la generación automática de
tablas y atributos que realiza el sistema no es sólo efectiva, sino que se asemeja a la que
realizaría un buen analista de bases de datos.
Como hemos dicho, al trabajar sobre Drupal, el desarrollo se eleva a un nivel más cercano al
usuario ya que el desarrollador puede implementar nuevas funcionalidades mediante la activación
de módulos (existentes o creados para la ocasión), que permiten “prototipar” o adaptar
rápidamente la aplicación a necesidades específicas o incluso cambiantes.

1

Warner Bros Site: http://www.warnerbrosrecords.com/
FedEx News: http://news.van.fedex.com/
Sony BGM Myplay: http://myplay.com/
The NewYork Observer: http://www.observer.com/
MTV UK: http://www.mtv.co.uk/
Flixya Sharing Site: http://www.flixya.com/
Universal Music: http://www.universalmusic.com/
Moto GP: http://www.motogp.com
Nike Media: http://nikemedia.com


Página 5

Uno de estos módulos, posiblemente el más famoso de ellos, responde a las siglas de “CCK”
(Content Construction Kit2) y resulta de suma importancia para este estudio, pues es el encargado
de crear las entidades dónde almacenaremos los nuevos tipos de Nodos. Este módulo normaliza
las tablas, creando múltiples entidades cuando el atributo puede tomar varios valores o cuando se
asignan campos del mismo tipo semántico en distintos nodos (semantic meaning) y unifica los
atributos en una sola tabla cuando las propiedades del nodo son únicas.
Conscientes de que toda migración de una aplicación a un nuevo contexto obliga a hacer explícito
su modelo de datos, para su comprensión y sobre todo para permitir que la nueva plataforma
conserve la información ya almacenada, el siguiente informe:
1. Detalla el modelo de datos de Drupal 5.7 en el contexto concreto de la aplicación “Coyote
Application” de ACME Inc.
2. Y plantea varias propuestas de migración a Oracle, el gestor de base de datos institucional
de ACME Inc.
Cabe comentar que la versión de Drupal empleada hace uso de una base de datos no relacional.
Si bien es cierto que MySQL 5 ha incorporado recientemente estas capacidades, Drupal 5.7 no
hace uso de ellas.
Así pues, las relaciones entre entidades las establece la lógica de la aplicación y no la base
de datos que actúa como mero repositorio, consultado y actualizado en base a los índices y las
restricciones en los atributos de las entidades.
Este informe describe de manera general estas relaciones entre tablas, mediante Diagramas
Entidad-Relación y presenta los atributos de estas exhibiendo el Diccionario de Datos de
Drupal. Dado el propósito de este documento, en todo momento se hace especial hincapié en los
datos y estructuras de “Coyote Application” que deben ser trasladados al nuevo sistema.
Para este análisis se han empleado herramientas de ingeniería inversa como DBDesigner (de
Fabforce) que facilitan la extracción de relaciones entre índices primarios y foráneos en base a
sus nomenclaturas y datos.
Esta primera extracción ha sido profundamente estudiada y contrastada por nuestros expertos y
enriquecida con la documentación previamente suministrada por algunos desarrolladores de la
comunidad de Drupal.
2

El artículo de difusión de Robert Duglas en “What is the Content Construction Kit? A View from the Database” permite una primera
aproximación a los CCK y su efecto en la base de datos.
Fuente on-line: http://www.lullabot.com/articles/an_introduction_to_the_content_construction_kit


Página 6

Modelo de Datos de Drupal
Ryan Constantine, desarrollador y consultor de Drupal, realizó en el 2007 un estudio similar al que
se plantea en este documento, ofreciendo el siguiente diagrama entidad-relación para la versión
5.7 del aplicativo3.

Fig 1: Diagrama ER de Drupal 5.7 por Rayan Constantine.
Fuente original: http://drupal.org/files/issues/Drupal5RC1_Database_0.png

Rayan acompañaba este diagrama con la siguiente leyenda:
●

Gris: Tablas sin relaciones.

●

Púrpura: Tablas con archivos de instalación independientes que no enlazan con la tabla NODE.

●

Azul cían: Tablas relacionadas con la gestión de términos.

●

Rosa claro/Púrpura: Tablas para la gestión de vocabularios.

●

Rosa brillante: Tablas para la gestión de filtros.

●

Azul: Tablas para el control de permisos.

●

Marrón claro: Tablas con archivos de instalación independientes que no enlazan con al tabla NODE.

●

Verde: Tablas del núcleo que originan claves primarias (autoincrementadas en esta tabla y usadas
como claves foráneas en otras)

●

3

Amarillo: Tablas del núcleo que usan claves foráneas como sus claves primarias.

Discusión de Rayan Constantine con la comunidad Drupal: http://drupal.org/node/79874


Página 7

La agrupación de Rayan4 desvela los cinco grupos de tablas sobre las trabaja Drupal que ofrecen
una buena primera aproximación al modelo:

●

Nodos: Que mantienen datos sobre el contenido a gestionar.

●

Vocabularios: Que permite asociar taxonomías a los contenidos (nodos).

●

Usuarios y permisos: Con datos sobre los usuarios del sistema, sus roles y sus permisos.

●

Cache: Para agilizar la creación de contenidos dinámicos mediante su reutilización.

●

Otros: Con datos de distinta índole sobre y para el correcto funcionamiento del sistema.

Para mayor claridad, en las siguientes páginas analizamos cada uno de estos bloques por
separado.

4

Hasta la versión 6 han surgido varios esfuerzos por mantener documentado el modelo de datos de Drupal, como por ejemplo:
http://cvs.drupal.org/viewvc.py/drupal/contributions/docs/developer/database/
http://webdevgeeks.com/schemaspy/tables/node.html
http://drupal.org/node/22754
Pero históricamente han resultado un fracaso porque Drupal, para no depender de ningún gestor en concreto, abstrae la base de
datos y el modelo se debía mantener de forma independiente.
A partir de Drupal 6, se incluye la función “hook_schema” (y el módulo schema) obligando a los programadores del núcleo y de los
módulos de terceros a definir y describir sus tablas con el mismo rigor con el que deben describir sus APIs.
Este cambio garantiza un futuro prometedor con un modelo de datos completamente documentado y siempre actualizado.


Página 8

Diagrama EntidadRelación
En este apartado se expone del diagrama ER de la aplicación de manera fraccionada para ofrecer
así una visión didáctica y detallada. La primera sección describe la tabla Nodo y sus relaciones,
para continuar con el grupo de tablas de Vocabularios, seguir con la gestión de Usuarios y concluir
con Otras tablas que consideramos meritorias de mención. Se obvia intencionadamente el grupo
de tablas de Cache, dado el nulo interés hacia estas en un proceso de migración.

Las tablas de Nodos
Tal y como hemos comentado en la introducción, Drupal se podría describir como un “Gestor de
Nodos”. Así pues, la tabla “node” es de vital importancia para este CMF ya que contiene la
información básica y común a todo contenido, siendo el origen y destino de la mayoría de
operaciones que el CMF realiza.

Fig 2: La entidad [node]

Como vemos en este primer diagrama nodos contienen un identificador único (nid) y un
identificador de versión (vid) que constituyen la clave primaria de la tabla. Esta tabla sólo
almacena la versión vigente del nodo, mientras que vid (en aquellos casos en los que el nodo
requiere de gestión de versiones) nos permitirá acceder al histórico de revisiones (node_revisions)
y a los atributos específicos (content_xx) del nodo.
Describiremos ambas relaciones en puntos posteriores, para centrarnos ahora en los atributos de


Página 9

esta entidad que contiene datos y metadatos sobre el trato que hay que dar a un nodo, siendo:
●

Título: El título que deseamos para el nodo. Pe: “Bienvenidos a esta página web”.

●

Status: El estado en el que se encuentra un nodo. Pe: “1” equivale a publicado.

●

Created: La fecha de creación en formato “timestamp”. Pe: “1185656627”

●

Changed: Fecha de modificación en formato “timestamp”. Pe: “1188946434”

●

Comment: Número de comentarios. Pe: “3”

●

Promote: Si debe ser “destacado en portada” (/frontpage). Pe: “1” indica promocionado.

●

Moderate: Si debe ser moderado antes de publicarse. Pe: “0” equivale a no moderado.

●

Sticky: Si debe destacarse en los listados. Pe: “1” muestra el nodo con mayor relevancia.

La documentación oficial de Drupal ofrece un incompleto, pero didáctico diagrama genérico,
dónde observamos las principales relaciones entre la entidad nodo y las tablas vinculadas:

Fig 3: Las principales relaciones de la entidad [node]
Fuente: Documentación oficial de Drupal.

En el diagrama podemos observar relaciones 1:n entre “node” y “node_revisions” o “node” y
“comments”. La primera relación permite (como hemos comentado) almacenar las distintas
revisiones de un nodo, mientras que en el segundo caso, se define un vínculo de “uno-amuchos” entre los nodos y los comentarios que sobre ese nodo se realicen.
El resto de relaciones son 1:1 y ofrecen información estadística (contador de visitas, estadísticas
sobre los comentarios) o de control de acceso (node_access).
Para completar este diagrama debemos volver a la tabla “node” dónde podemos ver que los
atributos “uid” y “type” son claves foráneas (FK) que mantienen, en el primer caso, una relación
1:n entre los usuarios y los nodos creados (uid) y nos permiten conocer al autor del nodo.


Página 10

El atributo “type” por otro lado, establece otra relación 1:n entre la entidad “node_type” y “node”
(type), siendo “node_type” la encargada de ampliar el elemento nodo con nuevos atributos
compartidos entre todos los nodos del mismo tipo.

Fig 4: La entidad [node_type] y su relación con [node]

Como vemos en esta sección ampliada del diagrama, la tabla “node_type” define una clave
primaria en “type” y contiene información adicional del nodo que nos permite conocer “si el nodo
ha sido creado por algún módulo” (module), “si el nodo debe incorporar un título y/o un cuerpo de
texto” (has_title y has_body, respectivamente), “si el nodo ha sido creado a medida mediante
CCK” (custom), una breve descripción para uso administrativo (description), un texto de ayuda que
se mostrará al usuario para que se asegure de si ese es el tipo de contenido que desea crear, etc.
(ver Diccionario de Datos para detalles).
La combinación de estas dos entidades nos permite gestionar elementos de contenido simple,
pero los datos que esta unidad abstracta de contenido seria capaz de contener se limita a un título
y un cuerpo de texto.
Aunque eficaz para mantener nodos como las “páginas web” (page), “noticias o blogs” (story) o
otras sencillas unidades de contenido, resulta claramente insuficiente si el nodo exige estructurar
más información que la mencionada.


Página 11

Tal y como hemos comentado en la introducción, el módulo CCK (Content Construction Kit) nos
permite ampliar los campos asociados a un nodo y genera las tablas necesarias para mantener
nuevos datos.
Veamos entonces los efectos que produce en la base de datos de Drupal el crear mediante CCK
un nuevo nodo (o “tipo de contenido”) como podría ser el nodo “actuación” (propio de “Coyote
Application”).

Fig 5: La entidad [content_type_actuacion] y su relación con [node]

Como vemos, CCK genera una nueva entidad (content_type_actuacion) para contener aquellos
atributos específicos del nuevo nodo, definiendo desde la tabla “node” una relación 1:n, que
mantiene el modelo de base de datos normalizado.
Para el caso de Coyote Application, “content_type_actuacion” incluye todos los atributos que se
muestran en el formulario de entrada de actuación como de selección simple, a excepción por
supuesto del título y el cuerpo de texto que se almacenan en “node_revisions”.
El resto de atributos, para garantizar que los datos se conservan segmentados y que la base de
datos mantiene su normalización, se almacenan en tablas externas que llevan por nombre
“content_field_xx” (dónde “xx” coincide con el nombre del campo creado) y que definen una
relación 1:n con “content_type_actuacion”.
La excepción a esta regla, la encontramos en el atributo “field_actuacion_accion_social_e_nid”
que establece una relación, ya no entre el nodo y uno de sus valores, sino entre dos nodos,
conservando en los nodos “actuación” el “nid” del nodo “acción social” con el que se relaciona.


Página 12

Ampliemos una vez más el anterior diagrama y veamos un ejemplo en el caso de las actuaciones
de Coyote Application, incluyendo esta vez las tablas de campo múltiple “content_field_xx” y su
vínculo con “content_type_accion_social_externa”:

Fig 6: La entidad [content_type_actuacion] y su relación con [content_type_actuacion_social_externa] y [content_field_xx]

Pese a las capacidades que ha adquirido el nodo “actuacion”, todavía no sería suficiente como
para cumplir con nuestros requisitos, ya que las actuaciones deben admitir documentos adjuntos
y el modelo descrito hasta el momento no sería capaz de albergarlos.
Para ello, el core de Drupal incorpora un módulo llamado “upload” que se encarga de las tareas
de administración de archivos y permite asociarlos a un nodo.
Los documentos cargados, se almacenan externos a la base de datos (habitualmente en el
directorio /files del servidor) y la tabla “files” conserva metadatos sobre el documento asociado
(nombre de archivo, tipo mime y tamaño), así como el path relativo al archivo físico.
La entidad “nodes” establece con “files” una nueva relación 1:n mediante el atributo nid, lo que nos
permite asociar varios documentos a un nodo.
Finalmente, para conservar un histórico de los documentos cargados, “files” establece una nueva


Página 13

relación “uno-a-muchos” contra la tabla “file_revisions” mediante los atributos “fid” y “nid”, que son
claves foráneas en “file_revisions”.
Esta última tabla, conserva la descripción del documento cargado y el atributo “list” que indica si el
adjunto debe mostrarse junto a la presentación del nodo o permanecer oculto.
Obsérvese el diagrama de la sección que hemos comentado, para continuar con el análisis de las
tablas de Vocabulario.

Fig 7: Las entidades [files] y [file_revisions] su relación con [node]


Página 14

Las tablas de Vocabulario
Otra funcionalidad sumamente interesante de Drupal reside en su capacidad por categorizar el
contenido empleando taxonomías simples o incluso jerarquizadas.
Cualquier contenido (que en adelante y tras lo expuesto llamaremos “nodo”) puede asociarse a un
vocabulario que incluye un conjunto de términos, lo que nos permite desarrollar mecanismos para
clasificar los contenidos de forma rápida y extremadamente flexible.
Esta capacidad lo distingue de otros CMS dónde las taxonomías no se contemplan como parte del
núcleo o son de carácter rígido y simple.
A modo de ejemplo podemos ver como mediante la gestión de taxonomías, asociamos al nodo
“actuación” un término del vocabulario “territorio” (por ejemplo: “Red Canyon”), una “fuente” (pe:
“Garganta profunda”), un “público objetivo” (pe: “Correcaminos”), etc.
La documentación oficial de Drupal nos ofrece de nuevo una primera aproximación a esta sección
de la base de datos:

Fig 8: Las principales relaciones de la entidad [vocabulary].

En el diagrama vemos como la entidad “node” se relaciona 1:n con “term_node” para definir las
asociaciones entre un nodo y los términos de un vocabulario. A su vez, la tabla “term_data”
contiene una lista de los términos posibles y también mantiene un vínculo “uno-a-muchos” con
“term_node”, constituyéndose esta última como una simple tabla de relación con claves foráneas
hacia las tablas de nodos y términos.
Cada término contenido en “term_data” pertenece a un vocabulario de la tabla “vocabulary”, que a
su vez se relaciona 1:n con “vocabulary_node_types” y establece que vocabularios se pueden
emplear en cada tipo de nodo.


Página 15

Finalmente, “term_hierarchy” almacena la jerarquía entre los términos de un vocabulario, dotando
al CMS de la base de datos necesaria para construir jerarquías simples (cada término sólo puede
tener un padre) o múltiples (un término puede tener más de un padre).
Aunque efectivo a cierta escala, este diseño puede resultar costoso en el momento en el que se
requiere de consultas que ahondan en la jerarquía de términos (como sucede con los listados de
actuaciones). Por ese motivo, en este desarrollo se ha añadido un módulo adicional (Lineage) que
implementa “nested trees”5 y reduce la complejidad del algoritmo de búsqueda.
Completamos la descripción de este grupo de tablas con una nueva sección del anterior diagrama
en el que se observan las relaciones entre ambos grupos, mediadas por las tablas de relación
“term_node” y “vocabulary_node_types”:

Fig 9: El grupo de entidades Vocabulario y sus relaciones con el grupo Nodos.

5

El módulo Lineage: http://drupal.org/project/lineage
Nested Trees: http://www.sitepoint.com/article/hierarchical-data-database


Página 16

Aunque no empleados en este proyecto, cabe comentar que Drupal permite establecer relaciones
entre términos (mediante “term_relation”) o incluso definir términos sinónimos o alias
(“term_synonym”).
Para finalizar, es necesario comentar que debido al carácter de prototipo de este desarrollo se ha
sido permisivo con la duplicidad de algunos datos.
El uso del módulo Content Taxonomy (empleado en actuaciones entre otros nodos) permite
asociar taxonomías a un nuevo nodo de forma paralela a la lógica interna de Drupal. Al asociar
una taxonomía a un nodo mediante este módulo, se nos plantean 3 posibilidades:
●

Save as tag: Los términos asociados al nodo se almacenan en las tablas internas de
Drupal (term_data).

●

Save in cck table: Los términos se almacenan en nuevas tablas (content_field_xx)

●

Both: Los términos se almacenan en ambas tablas.

El uso de “Save in cck table” permite a su vez mantener revisiones de las asociaciones entre los
nodos y sus taxonomías, mientras que “Save as tag” sólo mantiene la relación actual.
En previsión de futuras migraciones y para mantener un histórico de taxonomías asociadas al
nodo, cuando se ha empleado el módulo Content Taxonomy, se ha optado por la tercera vía,
permitiendo así que los datos sean extraídos como mejor convenga.
Llegados a este punto se completa el análisis de los elementos que permiten almacenar contenido
(Nodos y Vocabulario) y presentamos las tablas que hacen posible la gestión de Usuarios y que
contienen información sobre su perfil y posibilidades de acceso.


Página 17

Las tablas de Usuario y permisos
La gestión de usuarios de Drupal se define, en la versión 5.7, de forma independiente a los nodos.
Este hecho siempre ha provocado cierta controversia en la comunidad de Drupal, pues los datos
propios de un usuario (nombre, dirección, teléfono...) son tratados de manera muy distinta a como
se procesan los nodos y eso no permite explotar los módulos diseñados para nodos para tratar los
datos del perfil de usuario.
Es probable que en futuras versiones se rectifique esta estrategia y módulos como “usernode” ya
apuntan en esa dirección, implementando el perfil de usuario como si de un nodo más se tratara.
En cualquier caso, lejos de todas estas discusiones, Drupal ofrece una buena gestión de usuarios,
facilitando, “out-of-the-box” la ampliación del perfil mediante el módulo “profile” y sobre todo,
estableciendo una excelente gestión de roles y permisos de acceso.
La documentación oficial de Drupal aporta el siguiente diagrama:

Fig 10: Las principales relaciones de la entidad [user].

En el gráfico se destaca la tabla “users”, dónde podemos obtener el “uid” (user ID) como
identificador único de la persona en la plataforma. Esta tabla también almacena importante
información del usuario como su login (“username”), correo (“mail”), estado de bloqueo (“status”),
idioma preferido (“language”) y clave de acceso (“password”), entre muchos otros.
Para garantizar la confidencialidad de las claves, estas se mantienen en la base de datos en un
hash encriptado mediante un algoritmo de camino único (SHA1), por lo que si bien es posible
comparar una cadena de texto con la clave existente en la base de datos (y certificar las
credenciales de un usuario), no es posible desvelar el valor real del mismo.


Página 18

Fig 11: El grupo de entidades Usuarios y sus relaciones con el grupo Nodos.

Relacionada con la entidad “user” vemos, en 1:n a “profile_fields” con los valores concretos para
cada usuario de los tipos de campo del perfil (nombre, teléfono, dirección, etc.) que se definen en
profile_field.
Esta tabla permite establecer para cada tipo de campo que asociamos al perfil de usuario un título
(title), un texto explicativo (explanation), el grupo (o pestaña) en la que se mostrará (category), si
se debe crear una nueva página listando todos los usuarios con ese mismo valor en ese campo
(page), el tipo de campo a crear (type), si es un campo requerido (required), etc.


Página 19

La gestión de usuarios se mantiene mediante las tablas “role” y “user_roles” (relacionadas 1:n
entre si), siendo “role” un simple listado de identificadores (rid) y nombres (name) de rol y
recayendo en “user_roles” la tarea de mantener la relación entre usuarios y sus roles disponibles.
Finalmente, el comportamiento general del control de acceso a los contenidos y las
funcionalidades de los distintos módulos, lo establece la tabla “permission” que permite o bloquea
según el rol del usuario activo. Esta tabla, relacionada 1:1 con “role”, también contiene un
enumerado de las capacidades disponibles para todos los usuarios con ese rol.
Como en la sección anterior, aunque no han resultado necesarias para en este proyecto, cabe
comentar la existencia de las entidades “authmap”, dónde se mapean los usuarios que obtenemos
de bases de datos externas (ya sean simples BD o fuentes LDAP, OpenID, etc.) y “access” con
reglas que condicionan la creación de usuarios.


Página 20

Otras tablas de interés
Completamos el análisis comentando superficialmente algunas tablas de sistema que pese a no
establecer relaciones directas con los contenidos y los usuarios, pueden resultar de interés en un
proceso de migración.

Fig 12: Las tablas del sistema.

La documentación oficial de Drupal destaca 5 tablas en las que no se muestra relación alguna con
otras entidades. En el diagrama encontramos tablas muy especializadas, como “client” y
“client_system” (que contiene información sobre clientes remotos cuando se habilita Drupal como
servidor XML-RPC) y que no incumben al ámbito de este documento, pero también muestra las
tablas “sequences”, “system” y “variable”, que si pueden resultar de utilidad en una migración
completa.
La primera de estas tablas incluye un listado de contadores para garantizar la compatibilidad con
muy antiguas versiones de MySQL dónde el autoincremento de los identificadores no era posible.
Pese a su carácter residual, esta tabla sigue siendo consultada cada vez que se crea un nuevo
nodo, se escribe un comentario o se construye un nuevo menú y debe mantenerse actualizada
con el último ID creado para cada entidad.
La tabla “system” almacena toda aquella información que es de utilidad para el control del
sistema, con un listado de los módulos disponibles o los temas. Las tuplas de de “system”
incluyen el path completo al elemento del sistema, el nombre interno, el tipo de elemento, el
estado en el que se encuentra (activo o inactivo), cuando debe ser cargado (bootstrap), su orden
de aplicación (weight), una breve descripción y la versión de esquema de base de datos
(schema_version).
Finalmente, la tabla “variable” mantiene información sobre la configuración del sistema, incluyendo
variables que Drupal o cualquiera de sus módulos necesita conocer en todo momento.


Página 21

Fig 13: Las tablas del sistema.

Para finalizar ofrecemos el diagrama ER completo en notación EER, mostrando los atributos de
las entidades e incluyendo relaciones lógicas entre tablas.
En el diagrama se agrupan:
●

En verde las entidades que constituyen el grupo Nodos.

●

En azul las entidades del grupo Vocabulario.

●

En amarillo para las tablas de Usuarios y permisos.

●

En rojo, otras tablas que no contienen datos de nodos pero que pueden afectar a su
visualización o comportamiento.


Fig 14: Diagrama ER completo. En verde el grupo Nodos.


Página 23

Diccionario de Datos
A continuación se incluye el Diccionario de datos de Drupal 5.7, extendido con las tablas y
atributos específicos para la aplicación ficticia “Coyote Application” de ACME Inc.
Para no perder los matices de la documentación original, en el documento describe en Inglés las
entidades generales (compartidas por todo Drupal 5.76) y se usa el Español para las
peculiaridades de ACME Inc.
Para las tablas propias de “Coyote Application” y con la finalidad de facilitar la comprensión del
modelo, se amplía el formato clásico del diccionario de datos, añadiendo comentarios adicionales
y referencias a las tablas vinculadas ya sea de forma directa o lejana.
Este diccionario parte y se basa mayoritariamente en los patches creados colaborativamente por
la comunidad de Drupal7 para documentar el CMS mediante el módulo schema8.

6
7

También se documentan en Inglés las tablas de módulos de terceros que no son específicos del desarrollo “Coyote Application”.
Documento de partida:http://drupal.org/files/issues/drupal-document-schema-164983-75.patch
Discusión sobre el proceso de documentación: http://drupal.org/node/164983

8

Más información en: http://jaspan.com/schema-project-database-abstraction-reflection-and-migration


Página 24

Estructura de la tabla access
Stores site access rules.
Campo

Tipo

No Nulo Default Comentarios

aid

int(11)

Sí

mask

varchar(255) Sí

Text mask used for filtering access.

type

varchar(255) Sí

Type of access rule: name, mail or host.

status

tinyint(4)

Sí

NULL

0

Primary Key: Unique access ID.

Whether rule is to allow(1) or deny(0) access.

Estructura de la tabla accesslog
Stores site access information for statistics.
Campo

Tipo


aid

int(11)

Sí

Primary Key: Unique accesslog ID.

sld

varchar(64)

Sí

Browser session ID of user that visited page.

title

varchar(255) No

NULL

Title of page visited.

path

varchar(255) No

NULL

Internal path to page visited (relative to Drupal root.

url

varchar(255) No

NULL

Referrer URI.

hostname

varchar(128) No

NULL

Hostname of user that visited the page.

uid

int(10)

No

0

User {user}.uid that visited the page.

timer

int(10)

Sí

0

Time in milliseconds that the page took to load.

timestamp

int(10)

Sí

0

Timestamp of when the page was visited.

Estructura de la tabla authmap
Stores distributed authentication mapping.
Campo

Tipo


aid

int(10)

Sí

uid

int(11)

Sí

authname

varchar(128) Sí

Unique authentication name.

module

varchar(128) Sí

Module which is controlling the authentication.

Primary Key: Unique authmap ID.
0

User's {user}.uid.

Estructura de la tabla blocks
Stores block settings, such as region and visibility settings.
Campo

Tipo

No Nulo DefaultComentarios

module

varchar(64)

Sí

delta

varchar(32)

Sí

The module from which the block originates; for
example, 'user' for the Who's Online block, and 'block'
for any custom blocks.
0

Unique ID for block within a module.


Página 25

theme

varchar(255) Sí

The theme under which the block settings apply.

status

tinyint(4)

Sí

0

Block enabled status. (1 = enabled, 0 = disabled).

weight

tinyint(4)

Sí

0

Block weight within region.

region

varchar(64)

Sí

left

Theme region within which the block is set.

custom

tinyint(4)

Sí

0

Flag to indicate how users may control visibility of the
block. (0 = Users cannot control, 1 = On by default, but
can be hidden, 2 = Hidden by default, but can be
shown)

throttle

tinyint(4)

Sí

0

Flag to indicate whether or not to remove block when
website traffic is high. (1 = throttle, 0 = do not throttle)

visibility

tinyint(4)

Sí

0

Flag to indicate how to show blocks on pages. (0 =
Show on all pages except listed pages, 1 = Show only
on listed pages, 2 = Use custom PHP code to
determine visibility)

pages

text

Sí

Contents of the "Pages" block; contain either a list of
paths on which to include/exlclude the block or PHP
code, depending on "visibility" setting.

title

varchar(64)

Sí

Custom title for the block. (Empty string will use block
default title, <none> will remove the title, text will cause
block to use specified title.)

Estructura de la tabla blocks_roles
Sets up access permissions for blocks based on user roles
Campo

Tipo


module

varchar(64)

Sí

The block's origin module, from {blocks}.module.

delta

varchar(32)

Sí

The block's unique delta within module, from
{blocks}.delta.

rid

int(10)

Sí

The user's role ID from {user_roles}.rid.

Estructura de la tabla boxes
Stores contents of custom-made blocks.
Campo

Tipo


bid

int(11)

Sí

body

longtext

No

info

varchar(128) Sí

format

int(11)

Sí

The block's {block}.bid.
NULL Block contents.
Block description.
0

Block body's {filter_formats}.format; for example, 1 =
Filtered HTML.

Estructura de la tabla cache
Generic cache table for caching things not separated out into their own tables. Contributed
modules may also use this to store cached items.


Página 26

Campo

Tipo


cid

varchar(255) Sí

data

longblob

No

NULL A collection of data to cache.

expire

int(11)

Sí

0

A Unix timestamp indicating when the cache entry
should expire, or 0 for never.

created

int(11)

Sí

0

A Unix timestamp indicating when the cache entry was
created.

headers

text

No

NULL Any custom HTTP headers to be added to cached
data.

Primary Key: Unique cache ID.

Estructura de la tabla cache_content
Cache table to store cck content already parsed.
Campo

Tipo


cid

varchar(255) Sí

data

longblob

No


expire

int(11)

Sí

0


created

int(11)

Sí

0

created.

headers

text

No

data.


Estructura de la tabla cache_filter
Cache table for the Filter module to store already filtered pieces of text, identified by input format
and md5 hash of the text.
Campo

Tipo


cid

varchar(255) Sí

data

longblob

No


expire

int(11)

Sí

0


created

int(11)

Sí

0

created.

headers

text

No

data.


Estructura de la tabla cache_menu
Cache table for the menu system to store router information as well as generated link trees for
various menu/page/user combinations.
Campo

Tipo



Página 27

cid

varchar(255) Sí


data

longblob

No


expire

int(11)

Sí

0


created

int(11)

Sí

0

created.

headers

text

No

data.

Estructura de la tabla cache_page
Cache table used to store compressed pages for anonymous users, if page caching is enabled.
Campo

Tipo


cid

varchar(255) Sí

data

longblob

No


expire

int(11)

Sí

0


created

int(11)

Sí

0

created.

headers

text

No

data.


Estructura de la tabla cache_views
Cache table to store computed views.
Campo

Tipo


cid

varchar(255) Sí

data

longblob

No


expire

int(11)

Sí

0


created

int(11)

Sí

0

created.

headers

text

No

data.


Estructura de la tabla comments
Stores comments and associated data.
Campo

Tipo


cid

int(11)

Sí

pid

int(11)

Sí

Primary Key: Unique comment ID.
0

The {comment}.cid to which this comment is a reply. If
set to 0, this comment is not a reply to an existing
comment.


Página 28

nid

int(11)

Sí

0

The {node}.nid to which this comment is a reply.

uid

int(11)

Sí

0

The {user}.uid who authored the comment. If set to 0,
this comment was created by an anonymous user.

subject

varchar(64)

Sí

The comment title.

comment

longtext

Sí

The comment body.

hostname

varchar(128) Sí

timestamp

int(11)

Sí

0

The time that the comment was created, or last edited
by its author, as a Unix timestamp.

score

mediumint(9)Sí

0

To rate comments

status

tinyint(3)

Sí

0

The published status of a comment. (0 = Published, 1 =
Not Published)

format

int(11)

Sí

0

The {filter_formats}.format of the comment body.

thread

varchar(255) Sí

users

longtext

No

NULL Serialized user i-variables

name

varchar(60)

No

NULL The comment author's name. Uses {user}.name if the
user is logged in, otherwise uses the value typed into
the comment form.

mail

varchar(64)

No

NULL The comment author's e-mail address from the
comment form, if user is anonymous, and the
'Anonymous users may/must leave their contact
information' setting is turned on.

homepage

varchar(255) No

The author's host name.

The vancode representation of the comment's place in
a thread.

NULL The comment author's home page address from the
comment form, if user is anonymous, and the
'Anonymous users may/must leave their contact
information' setting is turned on.

Estructura de la tabla contact
Contact form category settings.
Campo

Tipo


cid

int(10)

Sí

category

varchar(255) Sí

Category name.

recipients

longtext

Sí

Comma-separated list of recipient e-mail addresses.

reply

longtext

Sí

Text of the auto-reply message.

weight

tinyint(4)

Sí

0

The category's weight.

selected

tinyint(4)

Sí

0

Flag to indicate whether or not category is selected by
default. (1 = Yes, 0 = No)

Primary Key: Unique category ID.

Estructura de la tabla content_field_actuacion_fuente
Términos del vocabulario “Fuente” vinculados a los nodos “actuación”.
Tablas relacionadas:
• {node}
• {node_revisions}


Página 29

• {term_data}

Relaciones lejanas:
• {content_type_actuacion}

Campo

Tipo


vid

int(10)

Sí

0

El {node_revisions}.vid identificador de versión.

delta

int(10)

Sí

0

Indica el orden de aparición si hay varias tuplas para la
fuente en un mismo {node_revisions}.vid

nid

int(10)

Sí

0

El {node}.nid al que hace referencia esta fuente.

field_actuacion_fuent int(11)
e_value

Sí

0

Identificador del término en {term_data}.tid

Estructura de la tabla content_field_actuacion_objetivo
Términos del vocabulario “Público Objetivo” vinculados a los nodos “actuación”.
• {node}
• {term_data}

Relaciones lejanas:

Campo

Tipo

No NuloDefault Comentarios

vid
delta

int(10)
int(10)

Sí
Sí

nid
int(10)
field_actuacion_obj int(11)

Sí
Sí

0
0

Indica el orden de aparición si hay varias tuplas

0
0

para el objetivo en un mismo {node_revisions}.vid
El {node}.nid al que hace referencia este objetivo.

etivo_value

Estructura de la tabla content_field_actuacion_soporte
Términos del vocabulario “Soporte” vinculados a los nodos “actuación”.
• {node}
• {term_data}

Relaciones lejanas:


Página 30

Campo

Tipo


vid
delta

int(10)
int(10)

Sí
Sí

nid
int(10)
field_actuacion_so int(11)

Sí
Sí

0
0

Indica el orden de aparición si hay varias tuplas

0
0

para el soporte en un mismo {node_revisions}.vid
El {node}.nid al que hace referencia este soporte.

porte_value

Estructura de la tabla content_field_actuacion_tema
Términos del vocabulario “Tema” vinculados a los nodos “actuación”.
• {node}
• {term_data}

Relaciones lejanas:

Campo

Tipo


vid

int(10)

Sí

0


delta

int(10)

Sí

0

Indica el orden de aparición si hay varias tuplas para
el tema en un mismo {node_revisions}.vid

nid

int(10)

Sí

0

El {node}.nid al que hace referencia este tema.

field_actuacion_tema int(11)
_value

Sí

0


Estructura de la tabla content_type_accion_social_externa
Atributos adicionales para los nodos de tipo “Acción social externa (ASE)” (accion-social-externa).
Nota: Este contenido no solicita control de versiones, ni emplea el “body” del nodo, por lo que sus
relaciones con la tabla “node_revisions” se pueden obviar.
•
•
•
•

{node}
{node_revisions}
{term_data}
{users}

Relaciones lejanas:


Página 31

• {files}
• {file_revisions}

Campo

Tipo


vid

int(10)

Sí

0


nid

int(10)

Sí

0

El {node_revisions}.nid identificador de nodo.

field_fecha_solicitud_ varchar(20)
value

No

NULL

Marca de tiempo con la fecha de la solicitud de acción.
Formato: aaaa-mm-ddThh:mm:ss

field_institucion_valu longtext
e

No

NULL

Institución solicitante de la acción.

field_beneficiarios_di longtext
rectos_value

No

NULL

Beneficiarios directos de la acción.

field_beneficiarios_in longtext
directos_value

No

NULL

Beneficiarios indirectos de la acción.

field_estado_proyect longtext
o_value

No

NULL

Estado del proyecto, admitiendo los literales:
En solicitud, Aprobado, Rechazado.

field_lugar_patrocinio longtext
_value

No

NULL

Topónimo del lugar de patrocinio.

field_fecha_inicio_val varchar(20)
ue

No

NULL

Marca de tiempo con la fecha de inicio de la acción

field_descripcion_val longtext
ue

No

NULL

Finalidad del proyecto y descripción de sus
características.

field_contraprestacio longtext
nes_value

No

NULL

Descripción de las contraprestaciones.

field_importancia_val longtext
ue

No

NULL

Importancia del proyecto, admitiendo los literales:
Alta, Media, Baja

field_observaciones_ longtext
value

No

NULL

Observaciones sobre la acción.

field_presupuesto_va int(11)
lue

No

NULL

Presupuesto del proyecto.

field_responsable_ac int(11)
cion_uid

No

NULL

El {user}.uid del usuario responsable de la acción.

field_fecha_termino_ varchar(20)
ase_value

No

NULL

Marca de tiempo con la fecha de finalización de la
acción.

field_eje_de_agrupac int(11)
in_value

Sí

0

El {term_data}.tid del término del vocabulario “Eje de
agrupación” asociado a esta acción.

field_accion_social_t int(11)
erritorio

Sí

0

El {term_data}.tid del término del vocabulario “Territorio
(ASE)” asociado a esta acción.

field_accion_social_p int(11)
resu_total_value

No

NULL

Presupuesto global de las actuaciones de este tipo.

Estructura de la tabla content_type_actuacion
Atributos adicionales para los nodos de tipo “Registro de actuación” (actuación).

•
•
•
•

Página 32

{node}
{node_revisions}
{term_data}
{content_type_accion_social_externa}

Relaciones lejanas:
•
•
•
•
•
•

{content_field_actuacion_fuente}
content_field_actuacion_objetivo}
{content_field_actuacion_soporte}
{content_field_actuacion_tema}
{files}
{file_revisions}

Campo

Tipo


vid

int(10)

Sí

0


nid

int(10)

Sí

0


field_fecha_actuacio varchar(20)
n_value

No

NULL

Marca de tiempo con la fecha de la actuación.

field_dudas_registro_ longtext
actuacion_value

No

NULL

Indicador de entrada con dudas, admitiendo el literal
“Sí” en caso afirmativo.

field_dudas_actuacio longtext
n_value

No

NULL

Comentarios sobre la duda que ha surgido.

field_actuacion_territ int(11)
orio_value

Sí

0

El {term_data}.tid del término del vocabulario
“Territorio” asociado a esta actuación.

field_actuacion_marc int(11)
a_value

Sí

0

El {term_data}.tid del término del vocabulario “Marca”
asociado a esta actuación.

field_actuacion_accio int(11)
n_social_e_nid

Sí

0

El {node}.nid del nodo de tipo “accion-social-externa”.

Estructura de la tabla content_type_acuerdo_patrocinio
Atributos adicionales para los nodos de tipo “Acuerdos con Medios (ACM)” (acuerdo_patrocinio).
•
•
•
•

{node}
{node_revisions}
{term_data}
{users}

Relaciones lejanas:
• {content_type_medio_comunicación}
• {files}


Página 33

Campo

Tipo


vid

int(10)

Sí

0


nid

int(10)

Sí

0


field_fecha_solicitud_ varchar(20)
acuerdo_value

No

NULL Marca de tiempo con la fecha de la solicitud.

field_importe_acuerd int(11)
o_value

No

NULL Presupuesto del acuerdo_patrocinio.

field_estado_acuerdo longtext
_value

No

NULL Estado del acuerdo_patrocinio, admitiendo los literales:
En solicitud, Aprobado, Rechazado.

field_fecha_inicio_ac varchar(20)
uerdo_value

No

NULL Marca de tiempo con la fecha de inicio del
acuerdo_patrocinio.

field_descripcion_aculongtext
erdo_value

No

NULL Finalidad del acuerdo_patrocinio y descripción de sus
características.

field_contraprestacio longtext
nes_acuerd_value

No

NULL Descripción de las contraprestaciones.

field_territorio_acuer int(11)
do_patroc_value

Sí

0

El {term_data}.tid del término del vocabulario
“Territorio” asociado a este acuerdo_patrocinio.

field_medio_acuerdo int(11)
_patrocinio_nid

Sí

0

El {node}.nid del “Medio” asociado a este
acuerdo_patrocinio.

field_fecha_termino_ varchar(20)
acuerdo_value

No

NULL Marca de tiempo con la fecha de finalización del
acuerdo_patrocinio.

field_acuerdo_responint(11)
sable_uid

No

NULL El {user}.uid del responsable de este
acuerdo_patrocinio.

Estructura de la tabla content_type_avisos
Relación entre nodos y versiones de nodo para el contenido “Aviso”.
• {node}

Relaciones lejanas:
• {files}

Campo

Tipo


vid

int(10)

Sí

0


nid

int(10)

Sí

0


Estructura de la tabla content_type_documentos
Relación entre nodos y versiones de nodo para el contenido “Documentos”.


Página 34

• {node}

Relaciones lejanas:
•
•
•
•

{term_data}
{content_type_images}
{files}
{file_revisions}

Campo

Tipo


vid

int(10)

Sí

0


nid

int(10)

Sí

0


Estructura de la tabla content_type_comite_ejecutivo
Relación entre nodos y versiones de nodo para el contenido “Documento del Comité Ejecutivo”
(docu_comite_ejecutivo).
• {node}

Relaciones lejanas:
• {files}

Campo

Tipo


vid

int(10)

Sí

0


nid

int(10)

Sí

0


Estructura de la tabla content_type_image
Relación entre nodos y versiones de nodo para el contenido “Image” (image).
• {node}

Relaciones lejanas:
• {term_data}
• {files}


Página 35

• {content_type_documentos}

Campo

Tipo


vid

int(10)

Sí

0


nid

int(10)

Sí

0


Estructura de la tabla content_type_interno
Relación entre nodos y versiones de nodo para el contenido “Documento Interno” (interno).
• {node}

Relaciones lejanas:
• {files}

Campo

Tipo


vid

int(10)

Sí

0


nid

int(10)

Sí

0


Estructura de la tabla content_type_medio_comunicacion
Relación entre nodos y versiones de nodo para el contenido “Medio” (medio-comunicación).
• {node}

Relaciones lejanas:
• {content_type_acuerdo_patrocinio}

Campo

Tipo

No NuloDefaultComentarios

vid

int(10)

Sí

0


nid

int(10)

Sí

0



Página 36

Estructura de la tabla content_type_page
Relación entre nodos y versiones de nodo para el contenido “Página web” (page).
• {node}

Relaciones lejanas:
• {files}

Campo

Tipo


vid

int(10)

Sí

0


nid

int(10)

Sí

0


Estructura de la tabla content_type_usernode
Relación entre nodos y versiones de nodo para el contenido “Usernode” (usernode).
Nota: El contenido de esta tabla carece de utilidad para futuros sistemas.
• {node}

Relaciones lejanas:
• {files}

Campo

Tipo


vid

int(10)

Sí

0


nid

int(10)

Sí

0


Estructura de la tabla files
Stores information for uploaded files.
Campo

Tipo


fid

int(10)

Sí

0

Primary Key: Unique files ID.

nid

int(10)

Sí

0

Unique node ID.

filename

varchar(255) Sí

Name of the file.

filepath

varchar(255) Sí

Path of the file relative to Drupal root.

filemime

varchar(255) Sí

The file MIME type.

filesize

int(10)

Sí

Página 37
0

The size of the file in bytes.

Estructura de la tabla file_revisions
Stores changes in the metadata related with the uploaded files.
Campo

Tipo


fid

int(10)

Sí

0

Primary Key: Unique files ID.

vid

int(10)

Sí

0

Primary Key: Unique node version ID.

description

varchar(255) Sí

list

tinyint(3)

Sí

A brief description of this file.
0

File must be listed. Possible values are:
0: Not shown.
1: Listed.

Estructura de la tabla filters
Table that maps filters (HTML corrector) to input formats (Filtered HTML).
Campo

Tipo


format

int(11)

Sí

module

varchar(64) Sí

delta

tinyint(4)

Sí

0

ID to identify which filter within module is being
referenced.

weight

tinyint(4)

Sí

0

Weight of filter within format.

0

Foreign Key: The {filter_formats}.fid to which this filter is
assigned
The origin module of the filter.

Estructura de la tabla filter_formats
Stores input formats: custom groupings of filters, such as Filtered HTML.
Campo

Tipo


format

int(11)

Sí

name

varchar(255) Sí

Name of the input format (Filtered HTML).

roles

varchar(255) Sí

A comma-separated string of roles; references {role}.rid.

cache

tinyint(4)

Sí

Primary Key: Unique ID for format.

0

Flag to indicate whether format is cachable. (1 =
cachable, 0 = not cachable)

Estructura de la tabla flood
Flood controls the threshold of events, such as the number of contact attempts.
Campo

Tipo


event

varchar(64) Sí

Name of event (e.g. contact)

hostname

varchar(128) Sí

Hostname of the visitor.

timestamp

int(11)

Sí

0

Timestamp of the event.


Página 38

Estructura de la tabla history
A record of which {users} have read which {node}s.
Campo

Tipo


uid

int(11)

Sí

0

The {users}.uid that read the {node} nid.

nid

int(11)

Sí

0

The {node}.nid that was read.

timestamp

int(11)

Sí

0

The Unix timestamp at which the read occurred.

Estructura de la tabla image_attach
A record of wich {nodes} includes attached {image}s
Campo

Tipo


nid

int(10)

Sí

0

Primary Key: The {node}.nid that was read.

iid

int(10)

Sí

0

Unique ID for image.

Estructura de la tabla locales_meta
List of available languages for locale module.
Campo

Tipo


locale

varchar(12)

Sí

Primary Key: Unique ID for locale.

name

varchar(64)

Sí

English language name.

enabled

int(11)

Sí

0

Status of the locale:
0: disabled
1: enabled

isdefault

int(11)

Sí

0

Default locale is set to 1.

plurals

int(11)

Sí

0

Language with plural forms.

formula

varchar(128) Sí

Estructura de la tabla locales_source
List of English source strings.
Campo

Tipo


lid

int(11)

Sí

location

varchar(255) Sí

Drupal path in case of online discovered translations or
file path in case of imported strings.

source

blob

The original string in English.

Sí

Unique identifier of this string.


Página 39

Estructura de la tabla locales_target
Stores translated versions of strings.
Campo

Tipo


lid

int(11)

Sí

translation

blob

Sí

locale

varchar(12) Sí

plid

int(11)

Sí

0

References {locales_target}.lid and defines the plural
form of this translation.

plural

int(11)

Sí

0

Plural index number in case of plural strings.

0

Source string ID. References {locales_source}.lid.
Translation string value in this language.
References {locales_meta}.locale and defines the
language of this translation.

Estructura de la tabla menu
Hierarchical list of menu items.
Campo

Tipo


mid

int(10)

Sí

0

Primary Key: menu item ID

pid

int(10)

Sí

0

References parent's {menu}.mid*

path

varchar(255) Sí

Path to the URL the menu item links to.

title

varchar(255) Sí

Menu item title to show.

description

varchar(255) Sí

Alternative link's text shown as ALT tooltip.

weight

tinyint(4)

Sí

0

Position of menu item in relation to other menu items.

type

int(10)

Sí

0

Menu type (or group this menu item belongs to)*

Estructura de la tabla node
The base table for nodes.
Campo

Tipo


nid

int(10)

Sí

vid

int(10)

Sí

type

varchar(32) Sí

The {node_type} of this node.

title

varchar(128) Sí

The title of this node, always treated a non-markup plain
text.

uid

int(11)

Sí

0

The {users}.uid that owns this node; initially, this is the
user that created it.

status

int(11)

Sí

1

Boolean indicating whether the node is published
(visible to non-administrators).

created

int(11)

Sí

0

The Unix timestamp when the node was created.

changed

int(11)

Sí

0

The Unix timestamp when the node was most recently
saved.

comment

int(11)

Sí

0

Whether comments are allowed on this node:
0 = no, 1 = read only, 2 = read/write.

The primary identifier for a node.
0

The current {node_revisions}.vid version identifier.


Página 40

promote

int(11)

Sí

0

Boolean indicating whether the node should displayed
on the front page.

moderate

int(11)

Sí

0

Previously, a boolean indicating whether the node was
"in moderation"; mostly no longer used.

sticky

int(11)

Sí

0

Boolean indicating whether the node should be
displayed at the top of lists in which it appears.

Estructura de la tabla node_access
Identifies which realm/grant pairs a user must possess in order to view, update, or delete specific
nodes.
Campo

Tipo


nid

int(10)

Sí

0

The {node}.nid this record affects.

gid

int(10)

Sí

0

The grant ID a user must possess in the specified realm
to gain this row's privileges on the node.

realm

varchar(255) Sí

grant_view

tinyint(3)

Sí

0

Boolean indicating whether a user with the realm/grant
pair can view this node.

grant_update

tinyint(3)

Sí

0

oolean indicating whether a user with the realm/grant
pair can edit this node.

grant_delete

tinyint(3)

Sí

0

Boolean indicating whether a user with the realm/grant
pair can delete this node

The realm in which the user must possess the grant ID.
Each node access node can define one or more realms.

Estructura de la tabla node_comment_statistics
Maintains statistics of node and comments posts to show "new" and "updated" flags.
Campo

Tipo


nid

int(10)

Sí

last_comment_timest int(11)
amp

Sí

The {node}.nid for which the statistics are compiled.
0

The Unix timestamp of the last comment that was
posted within this node, from {comment}.timestamp.

last_comment_name varchar(60) No

NULL

The name of the latest author to post a comment on this
node, from {comment}.author.

last_comment_uid

int(11)

Sí

0

The user ID of the latest author to post a comment on
this node, from {comment}.uid.

comment_count

int(10)

Sí

0

The total number of comments on this node.

Estructura de la tabla node_counter
Access statistics for {node}s.
Campo

Tipo


nid

int(11)

Sí

0

The {node}.nid for these statistics.

totalcount

bigint(20)

Sí

0

The total number of times the {node} has been viewed.


Página 41

daycount

mediumint(8) Sí

0

The total number of times the {node} has been viewed
today.

timestamp

int(10)

0

The most recent time the {node} has been viewed.

Sí

Estructura de la tabla node_field
Node field types for core nodes and CCK.
Campo

Tipo


field_name

varchar(32)

Sí

type

varchar(127) Sí

Type of field. For example: text, number_integer, date,
content_taxonomy, userreference, nodereference...

global_settings

mediumtext

Sí

Serialized settings of a field type.

required

int(11)

Sí

0

Required field. “1” means field is required.

multiple

int(11)

Sí

0

Multiple field. “1” means multiple values allowed.

db_storage

int(11)

Sí

0

Indicates if the value need to be stored at drupal's core
tables or CCK specific ones.

Primary Key: Field's name ID

Estructura de la tabla node_field_instance
List describing how a field type is instantiated when is related to a core or a CCK node type.
Campo

Tipo


field_name

varchar(32)

Sí

Primary Key: Field's name ID

type_name

varchar(32)

Sí

Primary Key: Relation to {node_type}.type

weight

int(11)

Sí

label

varchar(255) Sí

Label of the field (shown at html)

widget_type

varchar(32)

Sí

Widgets that creates or stands the field.

widget_settings

mediumtext

Sí

Serialized settings of this instance of a field_type.

display_settings

mediumtext

Sí

Serialized display setting of this instance of a field_type.

description

mediumtext

Sí

Description of the field, normally shown as help text.

0

Position of field in relation to other fields of the same
node type.

Estructura de la tabla node_group
List how to display a group of {node_field}s depending on {node_type}s.
Campo

Tipo


type_name

varchar(32)

Sí

Primary Key: {node_type}.type

group_name

varchar(32)

Sí

Primary Key: Group unique ID.

label

varchar(255) Sí

The html fieldgroup label.

settings

mediumtext

Sí

Serialized group settings

weight

tinyint(4)

Sí

Position of group in relation to other groups displayed
in the same node type.


Página 42

Estructura de la tabla node_group_fields
List of {node_field}s for each {node_group}s and {node_type}s.
Campo

Tipo


type_name

varchar(32)

Sí

Primary Key: {node_type}.type

group_name

varchar(32)

Sí

Primary Key: {node_group}.group_name

field_name

varchar(32)

Sí

Primary Key: {node_field}.field_name

Estructura de la tabla node_revisions
Stores information about each saved version of a {node}.
Comment: Note that body content is included here instead in {node} table.
Campo

Tipo


nid

int(10)

Sí

0

The {node} this version belongs to.

vid

int(10)

Sí

0

The primary identifier for this version.

uid

int(11)

Sí

0

The {users}.uid that created this version.

title

varchar(128) Sí

The title of this version.

body

longtext

Sí

The body of this version.

teaser

longtext

Sí

The teaser of this version.

log

longtext

Sí

The log entry explaining the changes in this version.

timestamp

int(11)

Sí

A Unix timestamp indicating when this version was
created.

format

int(11)

Sí

0

The input format used by this version's body.

Estructura de la tabla node_type
Stores information about all defined {node} types.
Campo

Tipo


type

varchar(32)

Sí

name

varchar(255) Sí

The human-readable name of this type

module

varchar(255) Sí

The module that implements this type.

description

mediumtext

Sí

A brief description of this type.

help

mediumtext

Sí

Help information shown to the user when creating a
{node} of this type.

has_title

tinyint(3)

Sí

Boolean indicating whether this type uses the
{node}.title field.

title_label

varchar(255) Sí

has_body

tinyint(3)

Sí

The machine-readable name of this type.

0

The label displayed for the title field on the edit form.
Boolean indicating whether this type uses the
{node}.body field.


Página 43

body_label

varchar(255) Sí

0

The label displayed for the body field on the edit form.

min_word_count

smallint(5)

Sí

custom

tinyint(4)

Sí

0

A boolean indicating whether this type is defined by a
module (FALSE) or by a user via a module like the
Content Construction Kit (TRUE).

modified

tinyint(4)

Sí

0

A boolean indicating whether this type has been
modified by an administrator; currently not used in any
way.

locked

tinyint(4)

Sí

0

A boolean indicating whether the administrator can
change the machine name of this type.

orig_type

varchar(255) Sí

The minimum number of words the body must contain.

The original machine-readable name of this node type.
This may be different from the current type name if the
locked field is 0.

Estructura de la tabla permission
Stores permissions for users.
Campo

Tipo


rid

int(10)

Sí

0

Primary Key: Unique permission ID

perm

longtext

No

NULL

List of permissions being assigned.

tid

int(10)

Sí

0

Originally intended for taxonomy-based permissions,
but never used.

Estructura de la tabla profile_fields
Stores profile field information.
Campo

Tipo


fid

int(11)

Sí

title

varchar(255) No

NULL Title of the field shown to the end user.

name

varchar(128) No

NULL Internal name of the field used in the form HTML and
URLs.

explanation

text

NULL Explanation of the field to end users.

category

varchar(255) No

NULL Profile category that the field will be grouped under.

page

varchar(255) No

NULL Title of page used for browsing by the field's value.

type

varchar(128) No

NULL Type of form field.

weight

tinyint(4)

Sí

0

Weight of field in relation to other profile fields.

required

tinyint(4)

Sí

0

Whether the user is required to enter a value. (0 = no, 1
= yes).

register

tinyint(4)

Sí

0

Whether the field is visible in the user registration form.
(1 = yes, 0 = no).

visibility

tinyint(4)

Sí

0

The level of visibility for the field. (0 = hidden, 1 =

No

Primary Key: Unique profile field ID.


Página 44
private, 2 = public on profile but not member list pages,
3 = public on profile and list pages)

autocomplete

tinyint(4)

Sí

0

Whether form auto-completion is enabled. (0 =
disabled, 1 = enabled).

options

text

No

NULL List of options to be used in a list selection field.

Estructura de la tabla profile_values
Stores values for profile fields.
Campo

Tipo


fid

int(10)

Sí

0

The {profile_fields}.fid of the field.

uid

int(10)

Sí

0

The {users}.uid of the profile user.

value

text

No

NULL The value for the field.

Estructura de la tabla role
Stores user roles.
Campo

Tipo


rid

int(10)

Sí

name

varchar(64) Sí

Primary Key: Unique role id.
Unique role name.

Estructura de la tabla search_dataset
Stores items that will be searched.
Campo

Tipo


sid

int(10)

Sí

type

varchar(16) No

data

longtext

0

Search item ID, e.g. node ID for nodes.

NULL

Type of item, e.g. node.

Sí

List of space-separated words from the item.

Estructura de la tabla search_index
Stores the search index, associating words, items and scores.
Campo

Tipo


word

varchar(50) Sí

sid

int(10)

type
fromsid

Sí

The {search_total}.word that is associated with the
search item.
0

The {search_dataset}.sid of the searchable item to
which the word belongs.

varchar(16) No

NULL

The {search_dataset}.type of the searchable item to
which the word belongs.

int(10)

0

The {search_dataset}.sid of the referring link to this
item.

Sí


Página 45

fromtype

varchar(16) No

NULL

The {search_dataset}.type of the referring link to this
item.

score

float

NULL

The numeric score of the word, higher being more
important.

No

Estructura de la tabla search_total
Stores search totals for words.
Campo

Tipo


word

varchar(50) Sí

count

float

No

Primary Key: Unique word in the search index.
NULL

The count of the word in the index using Zipf's law to
equalize the probability distribution.

Estructura de la tabla sequences
Record of the latest ID for various tables. (For compatibility with older MySQL versions.)
Campo

Tipo


name

varchar(255) Sí

id

int(10)

Sí

Table name.
0

Last ID for this table.

Estructura de la tabla sessions
Drupal's session handlers read and write into the sessions table. Each record represents a user
session, either anonymous or authenticated.
Campo

Tipo


uid

int(10)

Sí

sid

varchar(64) Sí

Primary key: A session ID. The value is generated by
PHP's Session API

hostname

varchar(128) Sí

The IP address that last used this session ID (sid).

timestamp

int(11)

Sí

0

The Unix timestamp when this session last requested a
page. Old records are purged by PHP automatically.

cache

int(11)

Sí

0

The time of this user's last post. This is used when the
site has specified a minimum_cache_lifetime. See
cache_get().

session

longtext

No

NULL

The serialized contents of $_SESSION, an array of
name/value pairs that persists across page requests by
this session ID. Drupal loads $_SESSION from here at
the start of each request and saves it at the end.

0

The {users}.uid corresponding to a session, or 0 for
anonymous user.


Página 46

Estructura de la tabla system
A list of all modules, themes, and theme engines that are or have been installed in Drupal's file
system.
Campo

Tipo


filename

varchar(255) Sí

The path of the primary file for this item, relative to the
Drupal root; e.g. modules/node/node.module.

name

varchar(255) Sí

The name of the item; e.g. node.

type

varchar(255) Sí

The type of the item, either module, theme, or
theme_engine.

description

varchar(255) Sí

Extra information for this system's item.
On modules include the module description.
On themes, the themeengine path or page.tpl path.

status

int(11)

Sí

0

Boolean indicating whether or not this item is enabled

throttle

tinyint(4)

Sí

0

Boolean indicating whether this item is disabled when
the throttle.module disables throttlable items.

bootstrap

int(11)

Sí

0

Boolean indicating whether this module is loaded
during Drupal's early bootstrapping phase (e.g. even
before the page cache is consulted).

schema_version

smallint(6)

Sí

-1

The module's database schema version number. -1 if
the module is not installed (its tables do not exist); 0 or
the largest N of the module's hook_update_N() function
that has either been run or existed when the module
was first installed.

weight

int(11)

Sí

0

The order in which this module's hooks should be
invoked relative to other modules. Equal-weighted
modules are ordered by name.

Estructura de la tabla taxonomy_manager_merge
Taxonomy_manager's table to establish how {term_data}s (taxonomies) are merged.
Campo

Tipo


main_tid

int(10)

Sí

0

Primary Key: Main {term_data}.tid

merged_tid

int(10)

Sí

0

The {term_data}.tid that need to be merged.

Estructura de la tabla tax_settings_temas
Establece el nombre del CSS y la entidad html empleados para renderizar un taxonomía.
Campo

Tipo


tema

int(10)

Sí

name

varchar(255) No

estilo

varchar(255) Sí

Identificador único de tema.
NULL Nombre del estilo CSS (coincide con color).
Entidad html mediante la que rederizar un tema. Toma
los valores: div, span.


Página 47

Estructura de la tabla tax_tema
Establece el nombre del CSS empleado para renderizar un término del vocabulario.
Campo

Tipo


id_relaciones

varchar(255) Sí

vid

int(10)

term_name

varchar(255) Sí

El {term_data}.term_name del término a mostrar.

color

varchar(255) Sí

Nombre del color a emplear para el renderizado.

Sí

Clave primaria: ID único de la relación.
0

El {vacabulary}.vid

Estructura de la tabla term_access
Defines access based on {term_data} and {role}s.
Campo

Tipo


tid

int(10)

Sí

0

Primary Key: The {term_data}.tid witch access will be
set.

rid

int(10)

Sí

0

Primary Key: The {roles}.rid witch access will be set.

grant_view

tinyint(1)

Sí

0

View access. “1” means granted.

grant_update

tinyint(1)

Sí

0

Update access. “1” means granted.

grant_delete

tinyint(1)

Sí

0

Delete access. “1” means granted.

grant_create

tinyint(1)

Sí

0

Create access. “1” means granted.

grant_list

tinyint(1)

Sí

0

List access. “1” means granted.

Estructura de la tabla term_access_defaults
Defines default access based on {vocabulary} and {role}s.
Campo

Tipo


vid

int(10)

Sí

0

Primary Key: The {vocabulary}.vid witch access will be
set.

rid

int(10)

Sí

0

Primary Key: The {roles}.rid witch access will be set.

grant_view

tinyint(1)

Sí

0

View access. “1” means granted.

grant_update

tinyint(1)

Sí

0

Update access. “1” means granted.

grant_delete

tinyint(1)

Sí

0

Delete access. “1” means granted.

grant_create

tinyint(1)

Sí

0

Create access. “1” means granted.

grant_list

tinyint(1)

Sí

0

List access. “1” means granted.

Estructura de la tabla term_data
Stores term information.
Campo

Tipo


tid

int(10)

Sí

Primary Key: Unique term ID.

Sí

Página 48

vid

int(10)

0

The {vocabulary}.vid of the vocabulary to which the term
is assigned.

name

varchar(255) Sí

description

longtext

No

NULL A description of the term.

weight

tinyint(4)

Sí

0

The term name.
The weight of this term in relation to other terms.

Estructura de la tabla term_hierarchy
Stores the hierarchical relationship between terms.
Campo

Tipo


tid

int(10)

Sí

0

Primary Key: The {term_data}.tid of the term.

parent

int(10)

Sí

0

Primary Key: The {term_data}.tid of the term's parent. 0
indicates no parent.

Estructura de la tabla term_lineage
List of nodes sorted by hierarchy depth (nested trees) to speed up searching.
Campo

Tipo


tid

int(10)

Sí

lineage

varchar(255) Sí

depth

Int(10)

No

0

Primary Key: The {term_data}.tid of the term.
Term names of this deep with order prefix.

NULL Deep hierarchy of the term.

Estructura de la tabla term_node
Stores the relationship of terms to nodes.
Campo

Tipo


nid

int(10)

Sí

0

Primary Key: The {node}.nid of the node.

tid

int(10)

Sí

0

rimary Key: The {term_data}.tid of a term assigned to
the node.

Estructura de la tabla term_relation
Stores non-hierarchical relationships between terms.
Campo

Tipo


tid1

int(10)

Sí

0

The {term_data}.tid of the first term in a relationship.

tid2

int(10)

Sí

0

The {term_data}.tid of the second term in a relationship.

Estructura de la tabla term_synonym
Stores term synonyms.


Página 49

Campo

Tipo


tid

int(10)

Sí

name

varchar(255) Sí

0

The {term_data}.tid of the term.
The name of the synonym.

Estructura de la tabla url_alias
A list of URL aliases for Drupal paths; a user may visit either the source or destination path.
Campo

Tipo


pid

int(10)

Sí

src

varchar(128) Sí

The Drupal path this alias is for; e.g. node/12.

dst

varchar(128) Sí

The alias for this path; e.g. title-of-the-story.

A unique path alias identifier.

Estructura de la tabla users
Stores user data.
Campo

Tipo


uid

int(10)

Sí

name

varchar(60) Sí

Unique user name.

pass

varchar(32) Sí

User's password (md5 hash).

mail

varchar(64) No

User's email address.

mode

tinyint(4)

Sí

0

Per-user comment display mode (threaded vs. flat),
used by the {comment} module.

sort

tinyint(4)

No

0

Per-user comment sort order (newest vs. oldest first),
used by the {comment} module.

threshold

tinyint(4)

No

0

Previously used by the {comment} module for per-user
preferences; no longer used.

theme

varchar(255) Sí

User's default theme.

signature

varchar(255) Sí

User's signature

created

int(11)

Sí

0

Timestamp for when user was created.

access

int(11)

Sí

0

Timestamp for previous time user accessed the site.

login

int(11)

Sí

0

Timestamp for user's last login.

status

tinyint(4)

Sí

0

Whether the user is active(1) or blocked(0).

timezone

varchar(8)

No

NULL

User's timezone.

language

varchar(12) Sí

User's default language.

picture

varchar(255) Sí

Path to the user's uploaded picture.

init

varchar(64) No

Email address used for initial account creation.

data

longtext

No

0

NULL

Primary Key: Unique user ID.

A serialized array of name value pairs that are related to
the user. Any form values posted during user edit are
stored and are loaded into the $user object during
user_load(). Use of this field is discouraged and it will
likely disappear in a future version of Drupal.


Página 50

Estructura de la tabla users_roles
Maps users to roles.
Campo

Tipo


uid

int(10)

Sí

0

Primary Key: {user}.uid for user.

rid

int(10)

Sí

0

Primary Key: {role}.rid for role.

Estructura de la tabla variable
Named variable/value pairs created by Drupal core or any other module or theme. All variables are
cached in memory at the start of every Drupal request so developers should not be careless about
what is stored here.
Campo

Tipo


name

varchar(48) Sí

The name of the variable.

value

longtext

The value of the variable.

Sí

Estructura de la tabla view_argument
Stores view's arguments (normally passed to views via url).
Campo

Tipo


vid

int(10)

Sí

type

0

Primary Key: Unique view ID.

varchar(255) No

NULL

Type of view argument.

argdefault

varchar(255) No

NULL

Argument's default value.

title

varchar(255) No

NULL

View's title when argument is set.

options

varchar(255) No

NULL

Options string.

position

int(2)

No

NULL

Argument position in the url.

wildcard

varchar(32) No

NULL

Argument's wildcard string.

wildcard_substitution varchar(32) No

NULL

Wildcard replacement.

Estructura de la tabla view_exposed_filter
Stores view's exposed filters (that will be shown to the final users)
Campo

Tipo


vid

int(10)

Sí

field

0


varchar(255) No

NULL

Formated string to indicate what field need to be
exposed as a filter for the final user.
Syntax: CONCAT ({view_tablefield}.tablename, “.”,
{view_tablefield}.field)

label

varchar(255) No

NULL

The html label of the exposed field.

optional

int(1)

NULL

Indicates if the field-filter need to be set by the user:

No


Página 51
Optional (1) or mandatory (0).

is_default

int(1)

No

NULL

The field-filter if is active by default as was set as a filter.
Enabled (1) or disabled (0).

operator

int(1)

No

NULL

The field-filter operator is locked or could be changed.

single

int(1)

No

NULL

The field-filter accepts multiple values.
Single (1) or multiple (0).

position

int(2)

No

NULL

The order how this exposed filter will be shown.

Estructura de la tabla view_filter
Stores view's filters (that shrinks the available data).
Campo

Tipo


vid

int(10)

Sí

tablename

0


varchar(255) No

NULL

Table name this filter refers to.

field

varchar(255) No

NULL

Formated string to indicate what field need to be applied
as a filter.

value

longtext

No

NULL

Value to filter.

operator

varchar(20) No

NULL

Logical operator to apply in the filter.

options

varchar(255) No

NULL

Additional options.

position

int(2)

NULL

The order how this filter will be applied.

No

Estructura de la tabla view_sort
Stores view's sort conditions.
Campo

Tipo


vid

int(10)

Sí

0


position

int(2)

No

NULL

The order how this sort condition will be applied.

field

varchar(255) No

NULL

Formated string to indicate what field this sort refers to.

sortorder

varchar(5)

No

NULL

Type of sorting.
Ascendent (ASC) or descendent (DESC).

options

varchar(255) No

NULL

Additional options.

tablename

varchar(255) No

NULL

Table this sort condition refers to.

Estructura de la tabla view_tablefield
Stores available view's fields and their default settings.
Campo

Tipo


vid

int(10)

Sí

0



Página 52

tablename

varchar(255) No

NULL

Table name.

field

varchar(255) No

NULL

Field name

label

varchar(255) No

NULL

Field label to be shown.

handler

varchar(255) No

NULL

Name of the handler.

sortable

int(1)

No

NULL

Indicates if the filed is sortable:
Sortable (1) or Not sortable (0).

defaultsort

varchar(5)

No

NULL

Default sorting.
Not sortable (0), ascendent (ASC), descentent (DESC)

options

varchar(255) No

NULL

Additional options.

position

int(2)

NULL

Global position where this field will be shown in lists.

No

Estructura de la tabla view_view
Stores view's settings.
Campo

Tipo


vid

int(10)

Sí

name

varchar(32) Sí

description

varchar(255) No

NULL

An administrative description of the view.

access

varchar(255) No

NULL

Coma separated list of roles that could access this view.

page

int(1)

No

NULL

View will be provided as a page if is set to “1”.

page_title

varchar(255) No

NULL

Page's title.

page_header

longtext

NULL

Text to be shown on page's header.

No

page_header_format int(4)

No

longtext

page_empty_format int(4)

No

Format for the page's header.
NULL

Sí

page_footer

longtext

page_footer_format int(4)

The name.

Sí

page_empty

0

Text to show if view offers no results.
Format for the empty text.

NULL

Sí

Text to be shown on page's footer.
Format for the page's footer.

page_type

varchar(20) No

NULL

Kind of view. Examples: node, teaser, list, table,
calendar, calc_table...

use_pager

int(1)

No

NULL

Include a pager to cut the results of this view.

nodes_per_page

int(5)

No

NULL

Number of nodes to be shown on each page.

url

varchar(255) No

NULL

URL of this view.

menu

int(1)

No

NULL

Provide a menu entry in the Drupal menu system.

menu_tab

int(1)

No

NULL

Shown as tab rather than in the main menu system.

menu_tab_weight

int(4)

No

NULL

Tab order.

menu_title

varchar(255) No

NULL

Menu/Tab title.

menu_tab_default

int(1)

No

NULL

Default tab.

menu_tab_default_p varchar(10) No
arent_type

NULL

Parent of this menu/tab item.

menu_parent_title

NULL

A title for the menu/tab parent.

NULL

Weight of the menu/tab parent.

varchar(255) No

menu_parent_tab_w int(4)
eight

No


Página 53

block

int(1)

No

NULL

View will be provided as a block if is set to “1”.

block_title

varchar(255) No

NULL

Block's title.

block_use_page_hea int(1)
der

No

NULL

Include page's header as block header.

block_header

No

NULL

Text to be shown on block's header.

longtext

block_header_format int(4)

Sí

block_use_page_foot int(1)
er

No

NULL

Include page's footer as block footer.

block_footer

No

NULL

Text to be shown on block's footer.

longtext

Format for the block's header.

block_footer_format int(4)

Sí

block_use_page_em int(1)
pty

No

NULL

Include page's “empty text” as block's one.

block_empty

No

NULL

Text to show if view offers no results.

longtext

block_empty_format int(4)

Format for the block's footer.

Sí

Format for the empty text.

block_type

varchar(20) No

NULL

Kind of view for this block. Examples: node, teaser, list,
table, calendar, calc_table...

nodes_per_block

int(5)

No

NULL

Number of nodes to be shown on this block.

block_more

int(1)

No

NULL

Display a more link in the block that links to the view
URL (if page view is also avaliable).

breadcrumb_no_hom int(1)
e

No

NULL

If is set to “1”, the breadcrumb trail for this page will
discard "Home".

changed

int(11)

No

NULL

Timestamp for view last change.

view_args_php

longtext

No

NULL

PHP code to process view's arguments.

is_cacheable

int(1)

No

NULL

The view is cachable by Drupal catching system.
Cachable (1) or Not cachable (0).

Estructura de la tabla vocabulary
Stores vocabulary information.
Campo

Tipo


vid

int(10)

Sí

name

varchar(255) Sí

description

longtext

help

varchar(255) Sí

relations

tinyint(3)

Sí

0

Whether or not related terms are enabled within the
vocabulary. (0 = disabled, 1 = enabled)

hierarchy

tinyint(3)

Sí

0

The type of hierarchy allowed within the vocabulary. (0
= disabled, 1 = single, 2 = multiple)

multiple

tinyint(3)

Sí

0

Whether or not multiple terms from this vocablulary may
be assigned to a node. (0 = disabled, 1 = enabled)

required

tinyint(3)

Sí

0

Whether or not terms are required for nodes using this

tags

tinyint(3)

Sí

0

Whether or not free tagging is enabled for the

No

Primary Key: Unique vocabulary ID.
Name of the vocabulary.
NULL

Description of the vocabulary.
Help text to display for the vocabulary.

module

varchar(255) Sí

weight

tinyint(4)

Página 54

Sí

The module which created the vocabulary.
0

The weight of the vocabulary in relation to other
vocabularies.

Estructura de la tabla vocabulary_node_types
Stores which node types vocabularies may be used with.
Campo

Tipo


vid

int(10)

Sí

type

varchar(32) Sí

0

Primary Key: the {vocabulary}.vid of the vocabulary.
The {node}.type of the node type for which the
vocabulary may be used.

Estructura de la tabla watchdog
Table that contains logs of all system events.
Campo

Tipo


wid

int(11)

Sí

uid

int(11)

Sí

type

varchar(16) Sí

Type of log message, for example "user" or "page not
found.

message

longtext

Sí

Text of log message to be passed into the t() function.

severity

tinyint(3)

Sí

link

varchar(255) Sí

Link to view the result of the event.

location

text

URL of the origin of the event.

referer

varchar(128) Sí

URL of referring page.

hostname

varchar(128) Sí

Hostname of the user who triggered the event.

timestamp

int(11)

Primary Key: Unique watchdog event ID.
0

0

Sí

Sí

0

The {user}.uid of the user who triggered the event.

The severity level of the event; ranges from 0
(Emergency) to 7 (Debug)

Unix timestamp of when event occurred.

Al no resultar de interés para la migración del sistema y dada la falta de documentación de los
respectivos módulos, se excluyen del diccionario de datos las tablas:
●

panels*

●

content_type_panel

●

case_tracker*

●

devel*

●

privatemsg*

●

tinymce*


Página 55

Estrategias de migración
De forma adicional al análisis planteamos, muy brevemente, diversas estrategias y materiales
para facilitar la ejecución del proceso de migración.
Desconocedores de los entresijos del nuevo proyecto Coyote Aplication, pero conscientes del
RDBS destino y sobretodo de todos los detalles del sistema origen, se planean (sin ser nada
exhaustivos) las siguientes propuestas de migración de los datos MySQL al Oracle corporativo:
1) Migración “Directa” y post procesado en Oracle.
2) Scripts PHP al uso.
3) Módulos de Drupal (views + csv export).

Migración “directa” y post procesado en Oracle
El gestor de base de datos MySQL (de forma nativa mediante mysqldump o con la ayuda de
herramientas como phpMyAdmin) permite realizar volcados de la base de datos en distintos
formatos. Uno de estos formatos es un estándard ISO vigente llamado SQL92 que Oracle puede
interpretar y cargar correctamente.
PhpMyAdmin a su vez, ofrece un amplio abanico de formatos de exportación en el caso de que la
versión de Oracle destino no fuese compatible con SQL92. Los formatos disponibles son:
●

Datos CSV

●

CSV para datos de MS Excel

●

Microsoft Excel 2000

●

Microsoft Word 2000

●

LaTeX

●

Hoja de cálculo Open Document

●

Texto Open Document

●

PDF

●

SQL92

●

XML

●

YAML

En Oracle y con la ayuda de la documentación aportada, el administrador de la base de datos
puede procesar las tablas (por ejemplo, creando vistas) de la forma que se considere pertinente la
nueva aplicación.


Página 56

Para confirmar la viabilidad de esta alternativa, se incluye:
●

El volcado completo de la base de datos a SQL92 (con compatibilidad para Oracle).
○

coyote_exportacion1.sql.zip (140 MB / 7MB)

Comentario: Se recomienda encarecidamente esta opción, dada su simplicidad y versatilidad.

Scripts “al uso”
A modo de ejemplo se ha desarrollado un breve script PHP que permite la exportación de las
tablas existentes a Microsoft Excel.
El script incluye un fichero de configuración que permite decidir que tablas van a ser exportadas e
incluso, que tipo de query se lanza para realizar la exportación.
La simple modificación del fichero de configuración permitiría ejecutar consultas cruzadas,
incluyendo los operadores SQL necesarios (JOINS, queries anidadas, etc.) para que la extracción
se ajuste a la demanda.
El script aportado no pretende ser una solución definitiva, sino un ejemplo que puede ser
modificado por los programadores de ACME, Inc (al margen de las opciones previstas en el
archivo de configuración) para que se ajuste a las necesidades específicas de la migración.
Se incluye:
●

El código fuente del script:
○

●

tironi/export.php

Los documentos Excel resultado de una exportación directa completa.
○

tironi/tablas/tablas2excel.zip

Módulos de Drupal (Views + CSV export).
Drupal incorpora el módulo views que básicamente es un generador de consultas contra la base
de datos. En combinación con el módulo “Views bonus pack”, cualquier consulta realizada puede
exportarse a CSV (Coma Separated Values) lo que permitiría su posterior carga en Oracle.
Se incluye:

●

Un ejemplo de exportación parcial de la vista “acutaciones” a CSV y Excel.
○

coyote_exportacion3.csv

○
●

Página 57

coyote_exportacion3.xls

URL de ejemplo (si se instala table-export): http://yoursite.com/table-export/format/export_csv/1

Comentario: Existen problemas de compatibilidad entre el módulo de y Excel. Las herramientas
de Microsoft trabajan con ISO-8859-1 mientras que el módulo lo hace en UTF-8. La exportación
incluida se ha realizado desde un gnu/Linux con OpenOffice con UTF-8 como charset nativo, por
lo que no se ve afectado por este problema de compatiblidad, pero seria posible adaptar el
módulo para trabajar con el charset de Excel corrigiendo así los problemas de compatibilidad.

Descripción Modelo Entidad Relación Drupal Autora Marc Bria Ramírez

Recomendados

Recomendados

Más contenido relacionado

Similar a Descripción Modelo Entidad Relación Drupal Autora Marc Bria Ramírez

Similar a Descripción Modelo Entidad Relación Drupal Autora Marc Bria Ramírez (20)

Último

Último (20)

Descripción Modelo Entidad Relación Drupal Autora Marc Bria Ramírez