Modelo de datos de Drupal 5.7 y Content Construction Kit

Autor:

Marc Bria Ramírez [email protected]

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 Entidad­Relació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

Modelo de datos “Drupal 5.7” con CCK

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.

Modelo de datos “Drupal 5.7” con CCK

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

Modelo de datos “Drupal 5.7” con CCK

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

Modelo de datos “Drupal 5.7” con CCK

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

Modelo de datos “Drupal 5.7” con CCK

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.

Modelo de datos “Drupal 5.7” con CCK

Página 8

Diagrama Entidad­Relació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

Modelo de datos “Drupal 5.7” con CCK

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.

Modelo de datos “Drupal 5.7” con CCK

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.

Modelo de datos “Drupal 5.7” con CCK

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.

Modelo de datos “Drupal 5.7” con CCK

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

Modelo de datos “Drupal 5.7” con CCK

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]

Modelo de datos “Drupal 5.7” con CCK

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]. Fuente: Documentación oficial de Drupal.

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.

Modelo de datos “Drupal 5.7” con CCK

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

Modelo de datos “Drupal 5.7” con CCK

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.

Modelo de datos “Drupal 5.7” con CCK

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]. Fuente: Documentación oficial de Drupal.

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.

Modelo de datos “Drupal 5.7” con CCK

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.

Modelo de datos “Drupal 5.7” con CCK

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.

Modelo de datos “Drupal 5.7” con CCK

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. Fuente: Documentación oficial de Drupal.

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.

Modelo de datos “Drupal 5.7” con CCK

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.

Página 22 Modelo de datos “Drupal 5.7” con CCK

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

Modelo de datos “Drupal 5.7” con CCK

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

Modelo de datos “Drupal 5.7” con CCK

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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.

Modelo de datos “Drupal 5.7” con CCK

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, 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

No Nulo DefaultComentarios

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

No Nulo Default Comentarios

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.

Modelo de datos “Drupal 5.7” con CCK

Página 26

Campo

Tipo

No Nulo DefaultComentarios

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

No Nulo Default Comentarios

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_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

No Nulo Default Comentarios

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_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

No Nulo Default Comentarios

Modelo de datos “Drupal 5.7” con CCK

Página 27

cid

varchar(255) Sí

Primary Key: Unique cache ID.

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.

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

Tipo

No Nulo DefaultComentarios

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_views Cache table to store computed views. Campo

Tipo

No Nulo DefaultComentarios

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 comments Stores comments and associated data. Campo

Tipo

No Nulo DefaultComentarios

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.

Modelo de datos “Drupal 5.7” con CCK

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

No Nulo DefaultComentarios

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}

Modelo de datos “Drupal 5.7” con CCK

Página 29

• {term_data}

Relaciones lejanas: • {content_type_actuacion}

Campo

Tipo

No Nulo DefaultComentarios

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”. Tablas relacionadas: • {node} • {node_revisions} • {term_data}

Relaciones lejanas: • {content_type_actuacion}

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

El {node_revisions}.vid identificador de versión. 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. Identificador del término en {term_data}.tid

etivo_value

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

Relaciones lejanas: • {content_type_actuacion}

Modelo de datos “Drupal 5.7” con CCK

Página 30

Campo

Tipo

No Nulo Default Comentarios

vid delta

int(10) int(10)

Sí Sí

nid int(10) field_actuacion_so int(11)

Sí Sí

0 0

El {node_revisions}.vid identificador de versión. 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. Identificador del término en {term_data}.tid

porte_value

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

Relaciones lejanas: • {content_type_actuacion}

Campo

Tipo

No Nulo Default Comentarios

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 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

Identificador del término en {term_data}.tid

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. Tablas relacionadas: • • • •

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

Relaciones lejanas: • {content_type_actuacion}

Modelo de datos “Drupal 5.7” con CCK

Página 31

• {files} • {file_revisions}

Campo

Tipo

No Nulo Default Comentarios

vid

int(10)

Sí

0

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

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 Formato: aaaa-mm-ddThh:mm:ss

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. Formato: aaaa-mm-ddThh:mm:ss

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). Tablas relacionadas:

Modelo de datos “Drupal 5.7” con CCK • • • •

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

No Nulo Default Comentarios

vid

int(10)

Sí

0

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

nid

int(10)

Sí

0

El {node_revisions}.nid identificador de nodo.

field_fecha_actuacio varchar(20) n_value

No

NULL

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

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). 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. Tablas relacionadas: • • • •

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

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

Modelo de datos “Drupal 5.7” con CCK

Página 33

Campo

Tipo

No Nulo DefaultComentarios

vid

int(10)

Sí

0

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

nid

int(10)

Sí

0

El {node_revisions}.nid identificador de nodo.

field_fecha_solicitud_ varchar(20) acuerdo_value

No

NULL Marca de tiempo con la fecha de la solicitud. Formato: aaaa-mm-ddThh:mm:ss

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. Formato: aaaa-mm-ddThh:mm:ss

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. Formato: aaaa-mm-ddThh:mm:ss

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”. Tablas relacionadas: • {node} • {node_revisions}

Relaciones lejanas: • {files} • {file_revisions}

Campo

Tipo

No Nulo DefaultComentarios

vid

int(10)

Sí

0

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

nid

int(10)

Sí

0

El {node_revisions}.nid identificador de nodo.

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

Modelo de datos “Drupal 5.7” con CCK

Página 34

Tablas relacionadas: • {node} • {node_revisions}

Relaciones lejanas: • • • •

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

Campo

Tipo

No Nulo DefaultComentarios

vid

int(10)

Sí

0

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

nid

int(10)

Sí

0

El {node_revisions}.nid identificador de nodo.

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). Tablas relacionadas: • {node} • {node_revisions}

Relaciones lejanas: • {files} • {file_revisions}

Campo

Tipo

No Nulo DefaultComentarios

vid

int(10)

Sí

0

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

nid

int(10)

Sí

0

El {node_revisions}.nid identificador de nodo.

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

Relaciones lejanas: • {term_data} • {files} • {file_revisions}

Modelo de datos “Drupal 5.7” con CCK

Página 35

• {content_type_documentos}

Campo

Tipo

No Nulo Default Comentarios

vid

int(10)

Sí

0

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

nid

int(10)

Sí

0

El {node_revisions}.nid identificador de nodo.

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

Relaciones lejanas: • {files} • {file_revisions}

Campo

Tipo

No Nulo DefaultComentarios

vid

int(10)

Sí

0

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

nid

int(10)

Sí

0

El {node_revisions}.nid identificador de nodo.

Estructura de la tabla content_type_medio_comunicacion Relación entre nodos y versiones de nodo para el contenido “Medio” (medio-comunicación). 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. Tablas relacionadas: • {node} • {node_revisions}

Relaciones lejanas: • {content_type_acuerdo_patrocinio}

Campo

Tipo

No NuloDefaultComentarios

vid

int(10)

Sí

0

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

nid

int(10)

Sí

0

El {node_revisions}.nid identificador de nodo.

Modelo de datos “Drupal 5.7” con CCK

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). Tablas relacionadas: • {node} • {node_revisions}

Relaciones lejanas: • {files} • {file_revisions}

Campo

Tipo

No Nulo DefaultComentarios

vid

int(10)

Sí

0

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

nid

int(10)

Sí

0

El {node_revisions}.nid identificador de nodo.

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. Tablas relacionadas: • {node} • {node_revisions}

Relaciones lejanas: • {files} • {file_revisions}

Campo

Tipo

No Nulo Default Comentarios

vid

int(10)

Sí

0

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

nid

int(10)

Sí

0

El {node_revisions}.nid identificador de nodo.

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

Tipo

No Nulo DefaultComentarios

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.

Modelo de datos “Drupal 5.7” con CCK 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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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.

Modelo de datos “Drupal 5.7” con CCK

Página 38

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

Tipo

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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

No NuloDefault Comentarios

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

No NuloDefault Comentarios

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.

Modelo de datos “Drupal 5.7” con CCK

Página 39

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

Tipo

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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.

Modelo de datos “Drupal 5.7” con CCK

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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.

Modelo de datos “Drupal 5.7” con CCK

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

No NuloDefault Comentarios

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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.

Modelo de datos “Drupal 5.7” con CCK

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

No NuloDefault Comentarios

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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.

Modelo de datos “Drupal 5.7” con CCK

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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.

Modelo de datos “Drupal 5.7” con CCK

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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í

Modelo de datos “Drupal 5.7” con CCK

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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.

Modelo de datos “Drupal 5.7” con CCK

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

No Nulo Default Comentarios

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

No Nulo DefaultComentarios

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

No Nulo DefaultComentarios

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.

Modelo de datos “Drupal 5.7” con CCK

Página 47

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

Tipo

No Nulo Default Comentarios

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

No Nulo DefaultComentarios

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

No Nulo DefaultComentarios

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

No Nulo Default Comentarios

tid

int(10)

Sí

Primary Key: Unique term ID.

Modelo de datos “Drupal 5.7” con CCK 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

No Nulo Default Comentarios

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

No Nulo DefaultComentarios

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

No Nulo DefaultComentarios

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

No Nulo DefaultComentarios

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.

Modelo de datos “Drupal 5.7” con CCK

Página 49

Campo

Tipo

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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.

Modelo de datos “Drupal 5.7” con CCK

Página 50

Estructura de la tabla users_roles Maps users to roles. Campo

Tipo

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

vid

int(10)

Sí

field

0

Primary Key: Unique view ID.

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

Modelo de datos “Drupal 5.7” con CCK

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

No Nulo Default Comentarios

vid

int(10)

Sí

tablename

0

Primary Key: Unique view ID.

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. Syntax: CONCAT ({view_tablefield}.tablename, “.”, {view_tablefield}.field)

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

No Nulo Default Comentarios

vid

int(10)

Sí

0

Primary Key: Unique view ID.

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. Syntax: CONCAT ({view_tablefield}.tablename, “.”, {view_tablefield}.field)

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

No Nulo Default Comentarios

vid

int(10)

Sí

0

Primary Key: Unique view ID.

Modelo de datos “Drupal 5.7” con CCK

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

No Nulo Default Comentarios

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)

Sí

page_empty

No

longtext

page_empty_format int(4)

Sí

page_footer

No

longtext

page_footer_format int(4)

0

Primary Key: Unique view ID. The name.

Format for the page's header. NULL

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

Modelo de datos “Drupal 5.7” con CCK

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

No Nulo Default Comentarios

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 vocabulary. (0 = disabled, 1 = enabled)

tags

tinyint(3)

Sí

0

Whether or not free tagging is enabled for the vocabulary. (0 = disabled, 1 = enabled)

No

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

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

Modelo de datos “Drupal 5.7” con CCK module

varchar(255) Sí

weight

tinyint(4)

Sí

Página 54 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

No Nulo Default Comentarios

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

No Nulo Default Comentarios

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*

Modelo de datos “Drupal 5.7” con CCK

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.

Modelo de datos “Drupal 5.7” con CCK

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:

Modelo de datos “Drupal 5.7” con CCK ●

●

Página 57

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

coyote_exportacion3.csv

○

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.