facultad de matemática, física y computación trabajo de
TRANSCRIPT
Ministerio de Educación Superior
Universidad Central “Marta Abreu”
de las V illas
F acultad de M atem ática, F ís ica y
Com putación
Trabajo de Diploma
Título: “Sistema de Base de Datos para la Gestión del Trabajo Científico en el grupo
CAMD-BIR”.
A utora: Elizabeth Martínez Pérez
T utores: Msc. Alain Pérez Alonso Dr. Yovany Marrero Ponce
Consultantes: Dr. Ricardo Grau Ábalo Dr. Luisa González González
Curso 2012-2013 “Año 55 de la Revolución”
Dictamen
Hago constar que el presente trabajo fue realizado en la Universidad Central
“Marta Abreu” de Las Villas como parte de la culminación de los estudios de la
especialidad de Ciencia de la Computación, autorizando a que el mismo sea
utilizado por la institución, para los fines que estime conveniente, tanto de forma
parcial como total y que además no podrá ser presentado en eventos ni
publicado sin la autorización de la Universidad.
_____________________
Firma del autor
Los abajo firmantes, certificamos que el presente trabajo ha sido realizado
según acuerdos de la dirección de nuestro centro y el mismo cumple con los
requisitos que debe tener un trabajo de esta envergadura referido a la temática
señalada.
_____________________ _____________________
Firma del tutor Firma del jefe del
Jefe del Laboratorio
Resumen
El grupo de investigación CAMD-BIR ubicado en la UCLV tiene la necesidad de
gestionar sus trabajos científicos para contribuir a mejor la visibilidad de sus
investigaciones. Para resolver la problemática anterior se decidió implementar
una Sistema de Base de Datos con interfaz web. Uno de los aspectos
fundamentales que tiene que cumplir un buen diseño de base de datos son las
restricciones de integridad (RI) asociadas a los datos, porque su objetivo
principal es mantener la integridad de la información lo cual depende de la
validez y la completitud de los mismos. Al ser las RI una parte fundamental de
cualquier aplicación de bases de datos, se decidió realizar un trabajo
independiente con las RI tanto en el diseño como en la implementación del
sistema. Se implementa una aplicación que gestiona los datos científicos, los
exporta a diferentes formatos digitales, genera el “currículo Vitae” de los
miembros del grupo de forma automática y dinámica, además mantiene la
integridad, tanto en la interfaz (con PHP y JavaScript) como en la Base de
Datos (a través de los recursos estándares de SQL), siendo en esta última
donde se encuentran implementadas la mayoría de las RI. Este proyecto ha
sido probado por los usuarios finales, para corregir cualquier imperfección.
Palabras Claves: base de datos, restricciones de integridad, trabajo científico.
Abstract
The research group CAMD-BIR, located in the UCLV, has the need to manage
their scientific work to contribute to better visibility of their research. To solve the
previous problem it was decided to implement a database system with web
interface. One of the key issues that has to meet a good database design are
the integrity constraints (IC) associated with the data, because its main purpose
is to maintain the integrity of the information which depends on the concepts
validity and completeness of thereof. As it the IC a fundamental part of any
application database, it was decided to realize an independent job with IC for
design and implementation of the system. It implements an application that
manages the scientific data, the export to different digital formats, generates the
"Curriculum Vitae" of the group members automatically and dynamically, and
maintains the integrity, of both the interface (PHP and JavaScript) and Database
(SQL standard resources), being in the latter which are implemented most IC.
This project has been tested by the end users, to correct any imperfections.
Keywords: data base, integrity constraint, scientific work.
Contenidos
Introducción. ..................................................................................................................1
1. Consideraciones Generales. ...............................................................................5
1.1 Grupo CAMD-BIR ......................................................................................6
1.2 Concepto de Restricción de Integridad (RI) ..........................................7
1.3 Clasificación de las Restricciones de Integridad ..................................8
1.3.1 Fuente ..................................................................................................8
1.3.2 Alcance.................................................................................................9
1.3.3 Causa de Violación ......................................................................... 10
1.4 Niveles de Expresión ............................................................................. 11
1.5 Lenguajes de Especificación ................................................................ 11
1.5.1 OCL.................................................................................................... 12
1.5.2 Alloy ................................................................................................... 14
1.5.3 Comparación entre OCL y Alloy.................................................... 16
1.6 Restricciones de Integridad en el Modelo Entidad/Relación ........... 17
1.6.1 Atributo llave..................................................................................... 17
1.6.2 Restricciones en los Tipos de Relaciones................................... 18
1.6.3 Restricciones en Generalización/ Especificación....................... 19
1.6.4 Restricciones en jerarquías y mallas............................................ 21
1.7 Restricciones de Integridad en el Modelo Relacional....................... 21
1.7.1 Tipo o Dominio ................................................................................. 22
1.7.2 Atributo .............................................................................................. 23
1.7.3 Entidad .............................................................................................. 23
1.7.4 Base de Datos.................................................................................. 24
1.7.5 Transición ......................................................................................... 24
1.7.6 Integridad de la Entidad.................................................................. 25
1.7.7 Integridad Referencial..................................................................... 25
1.8 Implementación de las Restricciones.................................................. 26
1.9 Recursos de Bases de Datos ............................................................... 27
1.10 Gestores de bases de datos relacionales. ......................................... 30
Contenidos
1.11 Facilidades de los entornos Web ......................................................... 31
1.12 Conclusiones del Capítulo .................................................................... 32
2. Análisis y Diseño del Sistema......................................................................... 33
2.1 Proceso de Análisis y Diseño del Sistema ......................................... 34
2.2 Análisis de los Requisitos. .................................................................... 35
2.2.1 RI en lenguaje Natural .................................................................... 36
2.3 Esquema Entidad Relación (E/R) ........................................................ 37
2.3.1 Herramienta de diseño ERECASE. .............................................. 38
2.3.2 Esquema E/R asociado al Sistema. ............................................. 39
2.3.3 Representación de las RI obtenidas en el Esquema E/R ......... 41
2.4 Esquema Relacional .............................................................................. 42
2.4.1 Implementación de las RI obtenidas en MySQL. ....................... 42
2.5 Actores y Casos de Uso ........................................................................ 46
2.6 Diagramas de Transición de Estado. .................................................. 51
2.7 Conclusiones del Capítulo. ................................................................... 56
3. Interfaz de Usuario. ........................................................................................... 57
3.1 Tecnología Utilizada............................................................................... 58
3.1.1 HTML ................................................................................................. 59
3.1.2 Java Script ........................................................................................ 59
3.1.3 CSS.................................................................................................... 60
3.1.4 JQuery ............................................................................................... 61
3.1.5 PHP.................................................................................................... 62
3.2 Componentes y Módulos del Sistema. ............................................... 62
3.3 Interfaz Web ............................................................................................ 64
3.3.1 Sitio de información pública. .......................................................... 64
3.3.2 Sitio de Gestión de Datos. ............................................................. 68
3.4 Manejo de las RI ..................................................................................... 77
3.5 Requerimientos del Software. .............................................................. 80
3.6 Pasos de Instalación. ............................................................................. 80
3.7 Conclusiones del Capítulo .................................................................... 81
Conclusiones.............................................................................................................. 82
Contenidos
Recomendaciones..................................................................................................... 84
Referencias Bibliográficas. ...................................................................................... 86
Anexos. ....................................................................................................................... 89
Anexo 1: Requisitos del sistema. ..................................................................... 90
Anexo 2:Restricciones de Integridad en Lenguaje Natural. ........................ 93
Anexo 3: Esquema Entidad /Relación............................................................. 95
Anexo 3.1: Sub-esquema de Personas ..................................................... 95
Anexo 3.2: Sub-esquema de Publicaciones.............................................. 95
Anexo 3.3: Sub-esquema de Cursos.......................................................... 96
Anexo 3.4: Sub-esquema de Eventos ........................................................ 96
Anexo 3.5: Sub-esquema de Tesis............................................................. 97
Anexo 3.6: Sub-esquema de Ficheros para Descargas.......................... 97
Anexo 4: Script SQL para implementar las RI complejas en MySQL. ....... 98
Figuras
Figura 1: Proceso de Análisis y Diseño. ...................................................................35
Figura 2: Proceso de Integridad.................................................................................43
Figura 3: Casos de Uso del Invitado. ........................................................................47
Figura 4: Casos de Uso del Actor tipo Usuario. ......................................................47
Figura 5: Casos de Uso del Administrador de Usuarios. .......................................48
Figura 6: Casos de Uso del Administrador de datos de la Aplicación. ................49
Figura 7: Casos de Uso del Administrador de los datos Científicos. ...................50
Figura 8: Casos de Uso del Usuario Especial, Miembro Activo. ..........................51
Figura 9: Diagrama de Transición de Estados para Registrar un Usuario. ........52
Figura 10: Diagrama de Transición de Estados para Loquearse un Invitado. ...53
Figura 11: Diagrama de Transición de Estados para Insertar una Publicación. 54
Figura 12: Diagrama de Transición de Estados para Exportar Publicaciones. ..55
Figura 13: Componentes y Módulos del Sistema. ..................................................63
Figura 14: Página principal del Sistema. ..................................................................65
Figura 15: Página pública de Publicaciones. ...........................................................66
Figura 16: Página específica de Publicación. ..........................................................67
Figura 17: Página específica de Documento. ..........................................................67
Figura 18: Mensaje de descarga denegada. ...........................................................68
Figura 19: Menús Generales de Administración. ....................................................68
Figura 20: Menú de Administración con todos los privilegios. ..............................68
Figura 21: Menú Adicional para el Administrador de Usuarios.............................69
Figura 22: Menús Adicionales para el Administrador de la Aplicación. ...............69
Figura 23: Menús Adicionales para el Administrador de datos Científicos.........70
Figura 24: Menús Adicionales para el Usuario Especial........................................70
Figura 25: Página de Gestión de Publicaciones. ....................................................71
Figura 26: Formulario de Insertar/Actualizar Publicación. .....................................72
Figura 27: Error sobre que no hay datos seleccionados. ......................................72
Figura 28: Confirmación para Eliminar .....................................................................73
Figura 29: Formulario de Exportar tabla. ..................................................................73
Figuras
Figura 30: Ventana de acción para descargas. .......................................................74
Figura 31: Formulario de búsqueda de Publicaciones. ..........................................74
Figura 32: Configuración General del Currículo Vitae............................................76
Figura 33: Configuración de los Aspectos de los Artículos (Publicaciones). ......76
Figura 34: Error de campo requerido. .......................................................................77
Figura 35: Error al subir un documento. ...................................................................78
Figura 36: Error de dependencias. ............................................................................79
Figura 37: Error al insertar una Publicación.............................................................79
Figura 38: Error de nombre de usuario incorrecto. .................................................79
Figura 39: Error de nombre de usuario ya existente. .............................................79
~ 1 ~
Introducción.
Introducción
~ 2 ~
El grupo de investigación: “Unit of Computer-Aided Molecular “Biosilico”
Discovery and Bio-Informatic Research”, por sus ciclas CAMD-BIR, fue fundado
por el Prof. Dr. Yovani Marrero Ponce como centro de investigación del
Departamento de Farmacia (Facultad de Química y Farmacia) de la Universidad
Central de Las Villas (UCLV). Las investigaciones que realizan están dedicadas
al desarrollo de nuevos métodos computacionales, a la manipulación de la
información química, a la minería de bases de datos para la búsqueda de
compuestos líderes, a la generación de modelos de farmacólogos para el
diseño de nuevos compuestos bioactivos. El grupo de investigación ofrece sus
productos y servicios a varios equipos de investigación, departamentos y
empresas del mundo.
El objetivo principal del CAMD-BIR es el desarrollo y aplicación de métodos de
quimio-bio-informáticas integrales para apoyar este ciclo húmedo-seco, y
combinaciones de métodos bio-informáticos y quimio-informáticos para apoyar
el descubrimiento de fármacos modernos.
Este grupo de investigación necesita divulgar sus avances científicos, tanto
teóricos como prácticos con el objetivo de mejorar la visibi lidad de sus
investigaciones.
Por ello se define el siguiente problema científico:
¿Cómo contribuir con el grupo CAMD-BIR a la mejora de la visibilidad de las
investigaciones, el almacenamiento y distribución de los datos científico–
técnicos de sus investigadores, la obtención de los “currículos Vitae” y la
distribución de los softwares que han producido?
Para darle solución al problema científico se plantea la siguiente hipótesis de
Investigación:
El diseño e implementación de una aplicación informática que tenga en cuenta
las restricciones de integridad, como solución para la Gestión del Trabajo
Científico, le permitirá al grupo mejorar la visibilidad de las investigaciones, la
gestión de los datos científicos-técnicos de sus investigadores, la obtención de
los “currículos Vitae” y la distribución de los softwares que han producido.
Introducción
~ 3 ~
En correspondencia con la hipótesis planteada y para darle solución al
problema científico formulado, esta investigación tiene como objetivo general:
Desarrollar una aplicación informática para la gestión del trabajo científico
desarrollado a partir del año 2007en el grupo CAMD-BIR de la UCLV, teniendo
en cuenta las restricciones de integridad (RI) en cada fase del proceso, para
facilitar su visibilidad consecuente a nivel nacional e internacional.
Para cumplir con el objetivo general se definen los objetivos específicos:
Captar las RI asociadas a los datos de los trabajos científicos.
Diseñar e implementar una BD para la gestión del trabajo científico que
incorpore las RI en cada fase del proceso.
Implementar una interfaz cliente vía web que sea amigable, senci lla y
tenga en cuenta las RI para el manejo y visualización de la información.
Para resolver los objetivos generales y específicos se plantean las siguientes
preguntas científicas:
¿Qué RI están asociadas a los datos de los trabajos científicos?
¿Cómo diseñar e implementar una BD para la gestión del trabajo
científico que incorpore las RI?
¿Cómo implementar una interfaz cliente vía web que sea amigable,
sencilla y maneje las RI tanto en la visualización como gestión de los
datos?
Como justificación del proyecto tenemos que:
Al grupo CAMD-BIRl e es necesario la creación de este proyecto para mejorar
la visibilidad de las investigaciones, la comunicación con especialistas y
personas interesadas sobre los temas que investigan, el almacenamiento y
distribución de los datos científicos – técnicos de sus investigadores, la
obtención de los “currículos Vitae” y la distribución de los softwares que han
producido.
El proyecto tiene un aporte práctico-social porque al almacenar los datos de los
trabajos científicos se podrá obtener el “currículo Vitae” de los miembros del
grupo y estos datos se mostrarán en la web de forma actualizada.
Introducción
~ 4 ~
Aunque este proyecto está pensado para el grupo de i nvestigación CAMD-BIR
tiene una utilidad futura y generalizadora porque se puede utilizar en los
distintos grupos de investigación para llevar el control de los trabajos científicos
siendo estos de vital importancia para los grupos investigativos y sus miembros.
Como viabilidad de la investigación tenemos que:
El grupo de investigación apoya el trabajo y está dispuesto a cooperar y
participar en la investigación, pues está consciente de que se puede mejorar la
visibilidad de las investigaciones, además de obtener el “currículo Vitae” si se
diseña una aplicación informática que gestione los trabajos científicos.
La estructura de la tesis es la siguiente:
En el Capítulo 1, llamado Consideraciones Generales, se describe el grupo de
investigación que presenta la necesidad a dar solución, se abordan aspectos de
las RI en las bases de datos y de la tecnología web. El Capítulo 2, llamado
Análisis y Diseño del Sistema, recoge todo el proceso de análisis y diseño,
pasando por: la especificación de los requisitos, el modelado de la base de
datos (Modelo E/R y Modelo Relacional) a la par del proceso de RI, muestra los
casos de uso y algunos diagramas de transición de estados, además describe
la implementación que se utilizará para las RI en el gestor de bases de datos. El
Capítulo 3, llamado Interfaz de Usuario, recoge los aspectos relevantes de la
aplicación web y los requerimientos de software e instalación.
~ 5 ~
1. Consideraciones
Generales.
Capítulo 1: Consideraciones Generales
~ 6 ~
El presente capítulo aborda los temas relacionados con el grupo de
investigación que presentó la necesidad a solucionar, las restricciones de
integridad como componente esencial de una aplicación de bases de datos, los
recursos de bases de datos para implementar las RI y las facilidades que
brindan los entornos web como interfaz para aplicaciones informáticas.
En la revisión bibliográfica asociada a las restricciones de integridad (RI) se
obtuvo el concepto de RI, las clasificaciones por diferentes autores y los
lenguajes de especificación para restricciones y recursos estándares del SQL.
La importancia de este capítulo radica en tomar las decisiones para el análisis,
diseño e implementación del sistema en cuestión.
1.1 Grupo CAMD-BIR
El grupo de investigación: “Unit of Computer-Aided Molecular “Biosilico”
Discovery and Bio-Informatic Research”, por sus ciclas CAMD-BIR, fue fundado
en el 2007 por el Prof. Dr. Yovani Marrero Ponce como centro de investigación
del Departamento de Farmacia (Facultad de Química y Farmacia) de la
Universidad Central “Marta Abreu” de Las Villas (UCLV). Ofrece una
infraestructura informática a las investigaciones químicas, biotecnológicas y
farmacéuticas. La colección de aplicaciones quimio-bio-informáticas del grupo
de investigación cubre muchas áreas diferentes, que utilizan métodos modernos
de diseño molecular (de fármacos).
Las investigaciones que realiza están dedicadas al desarrollo de nuevos
métodos computacionales, a la manipulación de la información química, a la
minería de bases de datos para la búsqueda de compuestos líderes, a la
generación de modelos de farmacólogos para el diseño de nuevos compuestos
bioactivos. Algunos software que han realizado atienden a las necesidades de
las disciplinas de investigación de hoy en día, incluyendo los estudios de
QSAR / QSPR, modelación de proteínas, el diseño de estructuras basado en
ligandos, el modelado molecular y simulaciones, cribado virtual de moléculas.
En la actualidad, una de las mayores fortalezas del CAMD-BIR radica en la
definición de nuevos descriptores moleculares y macromoleculares y el
Capítulo 1: Consideraciones Generales
~ 7 ~
descubrimiento biosílico de nuevas entidades químicas (NCE, según sus siglas
en el inglés), así como estudios farmacocinéticas preliminares, la predicción de
propiedades fisicoquímicas y toxicológicas. Además, CAMD-BIR aprovecha el
conocimiento y tecnología propia para ampliar sus actividades de investigación
en el área de docking y scoring functions (principalmente los nuevos enfoques
de diseño de fármacos basados en la estructura), la homología de proteínas, las
interacciones proteína-proteína, diseño y síntesis asistido por computadoras, la
planificación de las reacciones orgánicas, la síntesis impulsado por el diseño y
la predicción de la accesibilidad sintética de compuestos en la biblioteca
combinatoria. El grupo de investigación ofrece sus productos y servicios a
varios equipos de investigación, departamentos y empresas del mundo.
El objetivo principal del CAMD-BIR es el desarrollo y aplicación de métodos de
quimio-bio-informáticas integrales para apoyar este ciclo húmedo-seco, y
combinaciones de métodos bio-informáticos y quimio-informáticos para apoyar
el descubrimiento de fármacos modernos.
1.2 Concepto de Restricción de Integridad (RI)
Una base de información contiene una representación del conocimiento que un
sistema de información tiene sobre el estado de un dominio. El sistema de
información obtiene este conocimiento de mensajes recibidos a través de una
interfaz de la entrada. En un mundo perfecto, la base de información sería una
representación exacta del dominio. Los mensajes de la entrada siempre serían
correctos, y el sistema recibiría todos los mensajes importantes. En este mundo
perfecto, la base de información contendría siempre sólo hechos verdaderos
(sería válido) y todos los hechos importantes (estaría completo).
La validez y completitud son los dos componentes de la integridad de una base
de información. Una base de información mantiene la integridad cuando los
hechos que contiene son válidos y contiene todos los hechos relevantes.
Normalmente la falta de integridad tiene consecuencias negativas que en
algunos casos pueden ser serios (Olivé, 2007).
Capítulo 1: Consideraciones Generales
~ 8 ~
En la mayoría de los sistemas, la integridad puede ser lograda sólo por la
intervención humana. Para asegurar la integridad, se debe verificar los hechos
sistemáticamente en la base de información contra el dominio.
Es posible construir mecanismos en un sistema de información que garantice
automáticamente algún nivel de integridad. Se definen las condiciones en la
base de información para lograr algún nivel de confianza en la integridad de la
base de información. Estas condiciones se definen en el modelo conceptual.
Una restricción de integridad es una condición que no podría satisfacerse en
algunos estados de la base de información o por algunos eventos, pero se
entiende que el sistema de información incluirá los mecanismos para garantizar
su satisfacción en cualquier momento (Olivé, 2007).
1.3 Clasificación de las Restricciones de Integridad
Un modelo conceptual incluye las RI, las cuales se clasifican atendiendo a:
La razón por la que debe sostenerse (la fuente);
Los hechos involucrados (el alcance);
La causa de la violación.
1.3.1 Fuente
Según Olivé las restricciones atendiendo a la fuente se clasifican en analítico, el
deóntico y empírico (Olivé, 2007).
Una restricción es analítica si su verdad sigue de la definición o
significando de los hechos involucraron en él. Las violaciones de
restricciones analíticas son debidas a los errores en la representación de
hechos. Por ejemplo:
Una puerta no puede ser abierta y cerrada al mismo tiempo.
Una restricción es deóntica si expresa una condición que contiene el
dominio debido a la imposición por algún agente autorizado. Este agente
es la fuente de la restricción. Las violaciones de restricciones deónticas
pueden ser causadas por los errores en la representación de hechos o
Capítulo 1: Consideraciones Generales
~ 9 ~
porque la conducta del dominio se desvía de la condición declarada. Por
ejemplo:
El salario de un empleado no puede disminuir.
Una restricción es empírica si expresa una condición que contiene el
dominio empíricamente. Nadie ha declarado que la condición debe
satisfacerse, pero el dominio se comporta y en cierto modo eso lo
satisface. Las violaciones de restricciones empíricas pueden ser causadas
por los errores en la representación de hechos o porque alguna excepción
se ha levantado en el dominio. Por ejemplo:
Un cliente no compra más de 999 unidades de cualquier artículo.
1.3.2 Alcance
Las restricciones son condiciones que deben satisfacerse por la base de
información y los eventos. Normalmente, una restricción involucra sólo un juego
limitado de hechos en la base de información y/o un juego limitado de eventos,
esto permite clasificarlo según los hechos que involucra o el alcance de los
mismos. Olivé (Olivé, 2007) distingue seis tipos los cuales son:
Una restricción estática involucra los hechos de un solo estado de la base
de información, y debe satisfacerse en cada estado. Todos los lenguajes
de modelado conceptual permiten definir las restricciones estáticas. Por
ejemplo:
Todos los empleados siempre se asignan a algún proyecto.
Una restricción de transición involucra los hechos de dos o más estados
de la base de información. Normalmente, una restricción involucra hechos
de sólo dos estados consecutivos, reprimiendo la transición entre ellos,
pero en general la restricción puede referirse a cualquier número de
estados. Por la extensión, se usa también el término de "restricciones de
la transición" para esas restricciones que sólo deben satisfacerse en
algunos estados de la base de información. Por ejemplo:
Un empleado no puede asignarse el mismo proyecto por más de un año.
Capítulo 1: Consideraciones Generales
~ 10 ~
Una restricción de evento involucra sólo un evento. Por ejemplo:
El depósito inicial de una nueva cuenta bancaria debe ser por lo menos
de 50 pesos cubanos.
Una restricción de historia de evento involucra dos o más eventos que
ocurren en los mismos o diferentes momentos. Las restricciones de este
tipo son a menudo usadas para definir las clasificaciones temporales
permitidas de ocurrencias de evento. Por ejemplo:
Un cliente no puede abrir dos cuentas en el mismo día.
Una restricción global involucra los hechos de uno o más estados de la
base de información y uno o más eventos. Por ejemplo:
Un cliente no puede abrir una nueva cuenta si es un poseedor de alguna
cuenta que se ha sobregirado para más de 30 días durante el último año.
Una restricción de condición previa de evento (es un tipo particular de
restricción global), involucra sólo un evento y el estado de la base de
información cuando el evento ocurre. Hay muchas restricciones de
condición previa de evento, y los lenguajes de modelado más
conceptuales permiten su definición. Por ejemplo:
Un miembro de la biblioteca no puede reservar un libro para un período
de préstamo futuro si él ya tiene ese libro en un préstamo.
1.3.3 Causa de Violación
Una restricción puede violarse por la llegada de un mensaje de la entrada o por
la ausencia de mensajes durante un intervalo de tiempo (Olivé, 2007). En el
primer caso, se dice que la causa de la violación es el evento informado por el
mensaje, y que la restricción es evento – violable. Por ejemplo:
El sueldo de un empleado no puede disminuir.
En el segundo caso, se dice que la causa de la violación es el paso de tiempo, y
entonces la restricción es tiempo – violable. Por ejemplo:
Todos los empleados deben reportar sus labores por lo menos una vez al mes.
Capítulo 1: Consideraciones Generales
~ 11 ~
1.4 Niveles de Expresión
Las restricciones pueden expresarse de diversas formas, principalmente, según
su depuración a lo largo del sistema o incluso en la manera en que se
introduzcan a este. Es necesario señalar que existen varios modos a
considerar, pero fundamentalmente, se definen tres niveles (Morgan, 2002):
Informal: este nivel proporciona una sentencia en lenguaje natural, sin un
rango limitado de parámetros. Por ejemplo:
Un cliente de cuenta de crédito debe tener por lo menos 18 años.
Técnico: este nivel combina referencias a datos estructurados,
operadores y restricciones con el lenguaje natural. Por ejemplo:
CreditAccountself.customer.age >= 18
Formal: este nivel proporciona sentencias conforme a una sintaxis
definida, más cercana a propiedades matemáticas específicas. Por
ejemplo:
{X, Y, (cliente X) (cuenta_de_credito Y) (poseedor X Y)}
==>(ed (edad X) 18)
1.5 Lenguajes de Especificación
Los lenguajes de programación, son lenguajes interpretables o traducibles por
una computadora hacia una representación ejecutable. A diferencia de estos
lenguajes, los lenguajes de especificación por lo general no son utilizados para
implementar el sistema, sino para especificarlo, conceptualizarlo o incluso
validarlo.
Algunos lenguajes de especificación:
OCL es un lenguaje para la descripción formal de expresiones en los
modelos UML.
Alloy, lenguaje de especificaciones que utiliza la lógica de primer orden
y se basa en el uso de relaciones.
Autómatas es un formalismo utilizado para modelar sistemas discretos
en general.
Capítulo 1: Consideraciones Generales
~ 12 ~
B, lenguaje de descripción formal basado en la lógica de predicados.
Redes de Petri formalismo equivalente a los autómatas, utilizado para la
especificación de sistemas discretos paralelos o distribuidos.
VHDL, lenguaje de descripción (e implantación) de circuitos
electrónicos.
Z, lenguaje de descripción formal basada en la prueba automática de
teoremas usando la lógica.
Z.120, estándar semiformal de la ITU-T para diagramas de flujo.
Vale la pena aclarar que OCL y Alloy son los más utilizados para especificar las
RI en los modelos conceptuales, ya que estos modelos se brindan entidades y
relaciones, las cuales son aprovechadas por estos lenguajes para referirse a los
datos e imponer las restricciones.
1.5.1 OCL
OCL (Object Constraint Language, lenguaje de restricciones de objetos) es un
lenguaje notacional, subconjunto del UML estándar industrial, que permite a los
desarrolladores de software escribir restricciones sobre modelos de objetos (pre
y postcondiciones, guardas, invariantes, valores derivados, restricciones sobre
operaciones, etc.). Estas restricciones son particularmente útiles, en la medida
en que permiten a los desarrolladores crear un amplio conjunto de reglas que
rigen el aspecto de un objeto individual (Cuevas and Fernández, 2000).
OCL ha sido parte de UML desde la versión 1.3 de UML. Como parte del
proceso de estandarización de UML 2.0, la versión revisada 1.6 de OCL 2.0 fue
aceptado por el Grupo de Dirección de Objeto (OMG) en marzo del 2003 y ha
sido disponible al público (Yujing He, 2006).
OCL tiene las características de un lenguaje de expresiones, un lenguaje de
modelos y un lenguaje formal:
OCL es un lenguaje de expresiones puro. Esto significa que un estado del
sistema nunca cambiará debido a una expresión OCL, incluso una
expresión OCL podría usarse para describir tal cambio de estado (por
Capítulo 1: Consideraciones Generales
~ 13 ~
ejemplo en una post-condición). Todos los valores de todos los objetos,
incluidos los enlaces, no cambiarán. En cualquier momento en que se
evalúa una expresión OCL, simplemente devuelve un valor.
OCL es un lenguaje de modelos y no un lenguaje de programación. No se
puede escribir un programa lógico o un flujo de control en OCL.
Especialmente, no se puede invocar procesos o activar operaciones no de
consulta en OCL. Debido a que OCL es en primer lugar un lenguaje de
modelos, no se puede asegurar que todo sea directamente ejecutable.
Como lenguaje de modelos, todos los aspectos de implementación están
fuera de alcance y no pueden expresarse en OCL. Cada expresión OCL
es conceptualmente atómica. El estado de los objetos en el sistema no
puede cambiar durante la evaluación.
OCL es un lenguaje técnico donde todos los constructores tienen un
significado formal definido. La especificación de OCL es parte de la
especificación de UML. OCL no tiene la intención de reemplazar los
lenguajes formales existentes. Los lenguajes formales tradicionales se
usaban por personas con conocimientos matemáticos, pero dificulta su
uso para la mitad de empresas y modeladores de sistemas. OCL ha sido
desarrollado para llenar este hueco.
Puesto que en un proyecto hay muchas personas involucradas (usuario,
expertos, encargados del mantenimiento, etc.) los modelos deben ser
entendidos por una amplia y variada audiencia. OCL es fácil de aprender y usar
por los desarrolladores sin amplios conocimientos matemáticos. OCL tiene
ciertas características que permiten a los desarrolladores adoptarlo a su ritmo y
sólo donde lo necesiten. Hace accesibles las especificaciones formales con un
trasfondo matemático limitado.
Otro aspecto importante es que OCL no es un lenguaje completo en sí mismo.
Muchos lenguajes formales mandan (o al menos se supone) que la
especificación completa se escriba en el mismo lenguaje. Con OCL, no se
necesita, incluso se tiene la posibilidad de escribir las especificaciones
Capítulo 1: Consideraciones Generales
~ 14 ~
completas en OCL. La intención de OCL es la de utilizarlo en combinación con
los modelos visuales UML. Muchos aspectos de modelaje pueden expresarse
mucho mejor usando diagramas visuales y OCL no intenta reemplazarlos por
sus propios mecanismos. Por el contrario, toma la información expresada en los
modelos visuales y permite al desarrollador acceder a esta información en las
expresiones OCL.
OCL es un lenguaje tipado, por lo que cada expresión OCL tiene un tipo. Para
ser bien formada, una expresión debe concordar con los tipos de las reglas del
lenguaje. Por ejemplo, no puede comparar un dato de tipo Integer con uno
String. Cada clasificador definido en un modelo UML representa un tipo distinto
en OCL. Además, OCL incluye un conjunto de tipos adicionales predefinidos
(Cuevas and Fernández, 2000).
OCL usa operaciones para describir las restricciones, estas despiertan algunos
problemas en OCL. Por ejemplo, una operación puede entrar en un ciclo infinito
o puede ser indefinido, y esto hace a OCL menos preciso. Otro problema es
que las operaciones aplicadas a varias clases que tienen la relación de
herencia, y entonces las operaciones pueden ser redefinidas por los objetos de
esas clases. Por consiguiente, el significado de la expresión que contiene las
operaciones puede ser ambiguo para decidir (Yujing He, 2006).
1.5.2 Alloy
Alloy es un lenguaje del modelado estructural basado en la lógica de primer
orden, por expresar complejas estructuras de restricciones y funcionamiento. El
analizador de Alloy es un solucionador de restricciones que proporciona la
simulación totalmente automática y chequeo. Alloy se ha desarrollado por el
Grupo de Diseño de Software en MIT. El primer prototipo de Alloy salió en 1997,
y era un lenguaje de modelado de objeto bastante limitado.
Al contrario de un lenguaje de la programación, un modelo Alloy es declarativo:
puede describir el efecto de un funcionamiento sin dar su mecanismo. Es similar
en el espíritu a los lenguajes de la especificación formales como Z, VDM, Larch,
Capítulo 1: Consideraciones Generales
~ 15 ~
B, OBJ, etc., pero, al contrario de todos éstos, es dócil al análisis totalmente
automático en el estilo de chequeo de un modelo.
El lenguaje Z fue una influencia grande sobre Alloy. Muy aproximadamente,
Alloy puede verse como un subconjunto de Z. A diferencia de Z, Alloy es de
primer orden, que lo hace analizable (pero también menos expresivo). Los
mecanismos de la composición de Alloy se diseñan para tener la flexibilidad del
esquema de cálculo de Z, pero es basado en los diferentes lenguajes: la
extensión por la suma de campos, similar a la herencia en un lenguaje
orientado a objeto, y reutilizado de fórmulas por la parametrización explícita,
similar a las funciones en un lenguaje de la programación funcional. Alloy es
una pura anotación de ASCII (Jackson, 2011).
Una meta del lenguaje Alloy es ser extraordinariamente pequeña y simple; tiene
menos conceptos que los otros lenguajes (OCL, Z, VDM), y está en algunos
respetos más flexible. Estos beneficios no son sin algún costo. Alloy es menos
expresiva que los otros lenguajes. Considerando que las estructuras de Alloy
son estrictamente de primero orden, B, VDM y Z todas las estructuras son de
orden superior y tienen cuantificaciones de apoyo.
El análisis del analizador de Alloy es totalmente automático, y cuando una
afirmación se encuentra para ser falsa, el analizador Alloy genera un
contraejemplo. Es un "refutador" en lugar de un "probador". Cuando un
probador de teorema falla al demostrar un teorema, puede ser difícil decir lo que
se ha salido mal: si el teorema es no válido, o si la estrategia de la prueba falló.
Si el analizador de Alloy no encuentra ningún contraejemplo, la afirmación
todavía puede ser no válida (Michael et al., 2011).
La estructura de modelos de Alloy sólo se construirá de los átomos y relaciones.
Se usan las relaciones para relacionar los átomos. Una relación puede ser
vacía, unaria, binaria, ternaria, etc. Alloy sólo considera las relaciones finitas.
Los conjuntos son representados con las relaciones unarias. Los escalares son
representados con las relaciones de unarias de semifallo. Cada expresión
denota una relación. Esto le permite al modelo de Alloy ser más sucinto.
Capítulo 1: Consideraciones Generales
~ 16 ~
Una función es simplemente una relación binaria que mapea los átomos en el
lado izquierdo a lo sumo con un artículo en el lado derecho. Las expresiones en
Alloy son construidas anidando operadores a la variable. Todas las expresiones
son relaciones, y cada operador toma a uno o más operadores y devuelve
también una relación. Para los operadores de conjuntos (por ejemplo la unión,
la intersección, la diferencia), el orden de los elementos dentro de la estructura
de tupla de una relación no es importante. Para operadores que indican
relaciones (por ejemplo transponer, reflexivo, etc.),el orden de los elementos
importa (Yujing He, 2006).
1.5.3 Comparación entre OCL y Alloy
Alloy y OCL pueden usarse para especificar los requerimientos de diseño los
sistemas de software complejos. Ellos pueden describir los estados de un
sistema y las transiciones entre los estados. La sintaxis de Alloy es
principalmente compatible con OCL, y los dos Alloy y OCL tienen sintaxis formal
y semántica. OCL puede especificar las invariantes, condiciones previas,
postcondiciones, y transiciones de estados en modelos de UML. Alloy es similar
a OCL. La sintaxis y semántica de Alloy son más simples. Alloy es totalmente
declaratorio, mientras OCL es declaratorio y operacional.
La descripción en OCL se más orientada a objetos, y su sistema de tipo
también está cerca al lenguaje orientado a objetos. El estilo de las expresiones
de Alloy es más declaratorio, para que pueda especificar el cálculo en términos
de los datos de entrada sin una secuencia paso a paso de comandos.
Aunque las notaciones de OCL son similares a las de Alloy, es más complicado
para ser usado porque es aplicado en el contexto que incluye subclases,
polimorfismo paramétrico, operadores de sobrecarga, herencia múltiple, etc. La
sintaxis, semántica y gramática de OCL hace la descripción en OCL más
verboso que la de Alloy.
Alloy es un lenguaje modelado más simple comparado con OCL. Es más
preciso, y es más dócil qué permite el análisis automático. Puede describir un
sistema más precisamente que OCL. El analizador de Alloy puede verificar la
Capítulo 1: Consideraciones Generales
~ 17 ~
consistencia en el modelo. OCL es generalmente más expresivo que Alloy.
Tiene más tipos de datos que Alloy. OCL tiene mucho más maneras de
describir la arquitectura del sistema, sin embargo, las expresiones para
especificar la relación son bastante poderosas en Alloy (Yujing He, 2006).
Al comparar los rasgos y las diferencias entre los lenguajes de especificación
OCL y Alloy se concluye que: OCL es más complicado, mientras que Alloy es
más concisa. OCL es más ambiguo, mientras que Alloy es más exacta. OCL es
más expresivo, mientras que Alloy es más abstracta.
1.6 Restricciones de Integridad en el Modelo Entidad/Relación
Elmasri y Navathe definen para el modelo Entidad/Relación los siguientes tipos
de restricciones:
Atributo llave (o clave): obtener un atributo identificador de cada objeto
de la entidad.
Restricciones en los tipos de relaciones que pueden ser de cardinalidad y
de participación (o cardinalidad mínima): para determinar la cantidad
mínima y máxima de objetos de las entidades que intervienen en la
relación.
Restricciones en generalización/especialización que pueden ser de
disjunción (disjunto o solapada) y de completitud (total o parcial): para
determinar el tipo de generalización/especialización según a la relación
entre las subclases.
Restricciones en jerarquías y mallas: para definir el tipo de estructura.
1.6.1 Atributo llave
Una restricción importante en las entidades de un tipo de la entidad es la llave o
restricción de unicidad en los atributos. Un tipo de la entidad normalmente tiene
un atributo cuyos valores son distintos para cada entidad individual en el
conjunto de la entidad. Tal atributo se llama un atributo llave, y sus valores
pueden usarse para identificar cada entidad de forma única.
Capítulo 1: Consideraciones Generales
~ 18 ~
Especificando que un atributo es la llave de un tipo de entidad significa que la
propiedad de singularidad precedente debe sostenerse para cada conjunto de
entidad de un tipo de entidad. De ahí que, es una restricción que prohíbe a
cualquiera de dos entidades tener el mismo valor al mismo tiempo en el atributo
llave (Elmasri and Navathe, 2007). Por ejemplo:
Un departamento se identifica unívocamente con un ID_Departamento.
Otras consideraciones:
Algunos tipos de la entidad tienen más de un atributo llave.
Un tipo de la entidad también puede no tener ningún atributo llave en ese
caso se llama entidad débil.
1.6.2 Restricciones en los Tipos de Relaciones
Los tipos de relación normalmente tienen ciertas restricciones que limitan las
posibles combinaciones de entidades que pueden participar en el
correspondiente conjunto de relaciones. Se pueden distinguir dos tipos
principales de restricciones de relación: proporción de cardinalidad y
participación.
La restricción de proporción de cardinalidad para una relación binaria especifica
el número máximo de casos de la relación en que una entidad puede participar.
Las posibles proporciones de cardinalidad para los tipos de la relación binarios
son 1:1, 1: N, N: 1, y M: N.
La restricción de participación especifica si la existencia de una entidad
depende de estar relacionado a otra entidad a través del tipo de la relación.
Esta restricción especifica el número mínimo de relación de casos en que cada
entidad puede participar, y a veces se llama restricción de cardinalidad mínima.
Hay dos tipos de restricción de participación: total y parcial.
La participación total también se llama la dependencia de existencia. Por
ejemplo:
Todo empleado trabaja para un departamento.
Capítulo 1: Consideraciones Generales
~ 19 ~
La participación es parcial, cuando alguno de los casos de una entidad se
relaciona con alguno de los casos de otra entidad, lo que significa que la
relación no es necesariamente con todos los casos. Por ejemplo:
Uno de los empleados es el director de un departamento. (No significa que
todos los empleados sean directores)
En los diagramas de ER, la participación total (o dependencia de existencia) se
despliega como una línea doble que conecta el tipo de la entidad participando a
la relación, considerando que la participación parcial se representa por una sola
línea (Elmasri and Navathe, 2007).
1.6.3 Restricciones en Generalización/ Especificación
En general, se puede tener una o varias especializaciones definidas en el
mismo tipo de entidad (o superclase).
En algunas especializaciones se puede determinar las entidades que se
volverán exactamente los miembros de cada subclase poniendo una condición
en el valor de algún atributo de la superclase. Se llaman a tales subclases
atributo-definido o condición-definida. Por ejemplo:
Superclase: empleado
Subclases: secretario, técnico, ingeniero
Responden la condición: tipo de trabajo
Este tipo de condición es una restricción que específica para qué atributo de la
superclase (en el ejemplo: tipo de trabajo) se obtienen las subclases.
La restricción de disjunción especifica que las subclases de la especialización
deben ser disjuntas. Esto significa que una entidad puede ser un miembro a lo
sumo de una las subclases de la especialización.
Una especialización de atributo-definido implica que la restricción es de
disjunción. Por ejemplo:
Superclase: estudiante
Subclases: externo y becado
Un estudiante puede ser externo o becado, pero no de los dos tipos.
Capítulo 1: Consideraciones Generales
~ 20 ~
Si las subclases no se restringen para ser disjuntas, sus conjunto de entidades
se pueden solapar; es decir, la entidad puede ser miembro de más de una de
las subclases de la especialización. Por ejemplo:
Superclase: estudiante
Subclases: artista y atleta
Un estudiante puede ser artista y también atleta.
La restricción de completitud en la especialización, puede ser total o parcial.
Un restricción de especialización total especifica que cada entidad de la
superclase debe ser un miembro de por lo menos una subclase , en la
especialización. Por ejemplo:
Superclase: trabajador_de_escuela
Subclases: docente y no_docente
Los trabajadores docentes unidos con los no docentes forman todos los
trabajadores de una escuela.
Una restricción de especialización parcial permite que la entidad superclase
pueda no pertenecer a cualquiera de las subclases. Por ejemplo:
Superclase: empleado
Subclases: gerente
Hay algunos empleados que son gerentes.
Las restricciones de disjunción y completitud son independientes. De ahí se
obtienen las siguientes cuatro posibles restricciones en la especialización:
Disjunción total
Disjunción parcial
Solapamiento total
Solapamiento parcial
Las reglas de inserción y eliminación que se aplican a la especialización y
generalización son consecuencia de las restricciones especificadas
anteriormente. Según Elmasri y Navarthe (Elmasri and Navathe, 2007) algunas
de estas reglas son como sigue:
Eliminar una entidad de una superclase implica que se elimina
automáticamente de todas las subclases a la que pertenece.
Capítulo 1: Consideraciones Generales
~ 21 ~
Insertar una entidad en una superclase implica que si la superclase es
atributo-definido se inserta obligatoriamente en las subclases para que la
entidad satisfaga el predicado definiendo.
Insertar una entidad en una superclase de una especialización total
implica que la entidad se inserta obligatoriamente en por lo menos una
de las subclases de la especialización.
1.6.4 Restricciones en jerarquías y mallas
Una jerarquía de especialización tiene la restricción que cada subclase participa
como una subclase en sólo una relación de clase/subclase; es decir, cada
subclase tiene sólo un padre, es decir, produce una estructura del árbol. Por
ejemplo:
Superclase: Empleado
Subclase1_empleado: secretario, técnico e ingeniero
Subclase2_empleado: gerente
Un empleado tiene un tipo de trabajo, pero además puede ser gerente.
Para una malla de especialización, una subclase puede ser una subclase en
más de una relación clase/subclase (Elmasri and Navathe, 2007).
1.7 Restricciones de Integridad en el Modelo Relacional
Según Date (Date, 2001) las restricciones de integridad que se clasifican para el
Modelo Relacional son de tres tipos: de estado, de transición y meta-
restricciones. Las de estado se clasifican en cuatro grandes categorías: de tipo
(dominio), de atributo, de entidad y de base de datos. Las meta-restricciones,
son inherentes al modelo, se clasifican en integridad referencial y en integridad
de la entidad.
En esencia:
Una restricción de tipo especifica los valores válidos para un tipo dado.
Por supuesto, los tipos de relación también están sujetos a las
restricciones de tipo, pero dichas restricciones son básicamente solo una
Capítulo 1: Consideraciones Generales
~ 22 ~
consecuencia lógica de las restricciones de tipo que se aplican a los tipos
escalares en términos de los cuales esos tipos de relación están (en
última instancia) definidos.
Una restricción de atributo especifica el valor correcto de un atributo
dado.
Una restricción de entidad especifica los valores válidos de una entidad
determinada.
Una restricción de base de datos especifica el valor válido de una base
de datos dada.
Una restricción de transición son transiciones válidas de un estado
correcto a otro.
La integridad referencial promueve que la base de datos no contenga un
valor de clave externa (foránea) sin correspondencia.
La integridad de la entidad no permite que ningún componente de la
clave primaria de cualquier entidad base acepte nulos.
1.7.1 Tipo o Dominio
Una restricción de tipo es una sola enumeración de los valores válidos del tipo,
aunque algunas veces se expresan con rangos de valores, expresiones
regulares o tipos de datos. Por ejemplo el peso de un objeto tiene que ser un
valor positivo:
TYPE PESO POSSREP ( RATIONAL)
CONSTRAINT THE_PESO( PESO) > 0.0 ;
Siempre se puede pensar, por lo menos conceptualmente, que las restricciones
de tipo son verificadas durante la ejecución de alguna invocación al selector.
Como consecuencia, se dice que las restricciones de tipo son verificadas de
inmediato y por lo tanto, que ninguna entidad puede adquirir nunca un valor
para ningún atributo de cualquier tupla si este no es del tipo apropiado (por
supuesto, en un sistema que maneja las restricciones de tipo) (Date, 2001).
Capítulo 1: Consideraciones Generales
~ 23 ~
1.7.2 Atributo
Una restricción de atributo es básicamente solo una declaración para que un
atributo especificado sea de un tipo en particular. Por ejemplo, considere la
definición de la entidad de proveedores:
VAR V BASE RELATION{
V# V#,
PROVEEDOR NOMBRE,
STATUS INTEGER,
CIUDAD CHAR }
En esta entidad, los valores de los atributos V#, PROVEEDOR, STATUS y
CIUDAD están restringidos a los tipos V#, NOMBRE, INTEGER y CHAR,
respectivamente. En otras palabras, las restricciones de atributo son parte de la
definición del atributo en cuestión y pueden ser identificadas por medio del
nombre de atributo correspondiente. De aquí que una restricción de atributo
solo pueda ser eliminada mediante la eliminación del propio atributo (lo cual, en
la práctica significa generalmente eliminar la entidad que lo contiene). En
principio, cualquier intento de introducir un valor de atributo que no sea un valor
del tipo relevante dentro de la base de datos, será simplemente rechazado. Sin
embargo, en la práctica esta situación nunca deberá presentarse en tanto el
sistema haga cumplir las restricciones de tipo (Date, 2001).
1.7.3 Entidad
Una restricción de entidad es la que es impuesta a una entidad individual (esta
se expresa solamente en términos de la entidad en cuestión, aunque en otros
aspectos puede ser compleja). Por ejemplo, los proveedores en Londres deben
tener un status de 20:
CONSTRAINT R5V
IS-EMPTY( V WHERE CIUDAD = 'Londres' AND STATUS = 20) ;
Las restricciones de entidades siempre son verificadas de inmediato (en
realidad, como parte de la ejecución de cualquier instrucción que pudiera
ocasionar que fueran violadas). Por lo tanto, cualquier instrucción que intente
Capítulo 1: Consideraciones Generales
~ 24 ~
asignar un valor a una entidad dada que viole cualquier restricción para esa
entidad, será en efecto rechazada (Date, 2001).
1.7.4 Base de Datos
Una restricción de base de datos es aquella que relaciona dos o más entidades
distintas. Por ejemplo, ningún proveedor con status menor que 20 puede
suministrar parte alguna en una cantidad superior a 500:
CONSTRAINRT1 BD
IS-EMPTY((V JOIN VP)WHERE STATUS<20 ANDCANT> CANT(500))
La verificación de restricciones de base de datos no puede hacerse de
inmediato, sino que debe diferirse hasta el final de la transacción; es decir, al
momento del COMMIT. Si se viola una restricción de base de datos al momento
del COMMIT, la transacción será deshecha (Date, 2001).
1.7.5 Transición
Las restricciones de transición sobre transiciones válidas de un estado correcto
a otro. Por ejemplo, en una base de datos que hiciera referencia a personas,
podría haber una serie de restricciones de transición para los cambios en el
estado civil. Por ejemplo las siguientes transiciones son válidas (Date, 2001):
De soltero a casado
De casado a viudo
De casado a divorciado
De viudo a casado
(etcétera), en tanto que las siguientes no lo son:
De soltero a viudo
De soltero a divorciado
De viudo a divorciado
De divorciado a viudo
La verificación es diferida al momento del COMMIT
Capítulo 1: Consideraciones Generales
~ 25 ~
1.7.6 Integridad de la Entidad
El modelo relacional ha requerido históricamente que (al menos en el caso de
las entidades base) se elija una sola clave candidata como clave primaria para
la entidad en cuestión. Se dice entonces que las claves candidatas restantes,
en caso de haberlas, son claves alternas, y luego, junto con el concepto de
clave primaria, el modelo ha incluido la siguiente "meta-restricción" o regla:
No está permitido que ningún componente de la clave primaria de cualquier
entidad base acepte nulos.
Según Date (Date, 2001) las razones para esta regla son las siguientes:
Las tuplas en las relaciones base representan entidades en la realidad;
Las entidades en la realidad son identificables por definición;
Por lo tanto, sus contrapartes en la base de datos también deben ser
identificables;
Los valores de la clave primaria sirven como esos identificadores en la
base de datos;
Por lo tanto, los valores de clave primaria no pueden estar "faltantes".
1.7.7 Integridad Referencial
La integridad referencial es una propiedad deseable en las bases de datos.
Gracias a la integridad referencial se garantiza que una entidad (fila o registro)
siempre se relaciona con otras entidades válidas, es decir, que existen en la
base de datos. Implica que en todo momento dichos datos sean correctos, sin
repeticiones innecesarias, datos perdidos y relaciones mal resueltas.
La integridad referencial se define como:
La base de datos no debe contener ningún valor de clave externa que no
concuerde.
Queda claro que la regla de integridad referencial necesita cierto refinamiento,
ya que las claves externas deben, en apariencia, permitir nulos y obviamente
los valores nulos de la clave externa violan la regla tal como se establece. De
hecho, se puede mantener la regla como está establecida, siempre y cuando se
Capítulo 1: Consideraciones Generales
~ 26 ~
entienda adecuadamente la definición del término "valor de clave externa que
no concuerde". Para ser específicos, se define un "valor de clave externa que
no concuerde" como un "valor de clave externa no nulo", en alguna entidad
referente, para la cual no exista un valor que concuerde en la clave candidata
relevante en la entidad relevante a la que se hace referencia (Date, 2001).
1.8 Implementación de las Restricciones.
Las restricciones se pueden representar formalmente de disímiles maneras e
incluso pueden existir diferentes técnicas para una misma. Morgan
(Morgan, 2002) plantea que fundamentalmente es posible implementar las RI a
través de: los lenguajes de programación, los script y en la base de datos, tal
que en un sistema se pueden utilizar algunos o todos de ellos.
Lenguajes de Programación:
Las restricciones incorporadas en el código del programa, probablemente, son
la vía de aplicación más común. Es posible utilizar sentencias normales de un
lenguaje de programación para implementar una restricción. El requisito mínimo
es tener una forma de seleccionar, entre las ramas del código, una alternativa
basada en una condición dada. Esto es bastante fácil de satisfacer en cualquier
lenguaje de programación, aunque los detalles pueden variar de uno a otro.
Scripts:
La principal ventaja de los scripts es que al encontrarse en la aplicación cliente
son muy veloces, aunque tienen algunos puntos negativos. De estos el
fundamental es la dificultad en su manejo y modificación.
Bases de Datos:
Es probable que las restricciones encajen más naturalmente dentro de la base
de datos, donde pueden tener un contacto más directo con los datos según
aclara Morgan (Morgan, 2002). Lo más habitual es utilizar las restricciones
respecto a palabras funcionales que estén alrededor de lo básico (CREATE,
READ, UPDATE y DELETE). Estos mecanismos son comunes a todos los
servicios de datos.
Capítulo 1: Consideraciones Generales
~ 27 ~
1.9 Recursos de Bases de Datos
El lenguaje estructurado de consultas (Structured Query Language, SQL)
estándar en sus múltiples revisiones ofrece varios recursos de manejo de datos
que se analizan en este epígrafe para seleccionar a la postre los más
convenientes en la implementación de las RI.
Restricciones (Constraints) CHECK:
Las restricciones CHECK exigen la integridad del dominio mediante la limitación
de los valores que puede aceptar una columna. Se puede crear una restricción
CHECK con cualquier expresión lógica (booleana) que devuelva verdadero o
falso basándose en operadores lógicos (Oppel and Sheldon, 2008).
Es posible aplicar varias restricciones CHECK a una sola columna y a varias
columnas si se crea a nivel de la tabla. Así se pueden comprobar varias
condiciones en un mismo sitio. Una restricción CHECK devuelve TRUE cuando
la condición que está comprobando no es FALSE para ninguna fila de la tabla.
Si una tabla recién creada no tiene filas, cualquier restricción CHECK en esta
tabla se considerará válida. Esta situación puede generar resultados
inesperados al igual que en las instrucciones DELETE dado que las
restricciones CHECK no se validan en ellas (MSDN, 2008).
Desencadenadores (Triggers):
Los desencadenadores son una clase especial definida para la ejecución
automática al emitirse una instrucción UPDATE, INSERT o DELETE en una
tabla o una vista. Son una herramienta eficaz que pueden utilizar los sitios para
exigir automáticamente las reglas comerciales cuando se modifican los datos.
Amplían la lógica de comprobación de integridad, valores predeterminados y
reglas del estándar SQL, aunque se deben utilizar las restricciones y los valores
predeterminados siempre que estos aporten toda la funcionalidad necesaria
(Melton and Simon, 2002).
Los desencadenadores pueden consultar otras tablas e incluir instrucciones
SQL complejas. Son especialmente útiles para exigir reglas o requisitos
complejos. También son útiles para exigir la integridad referencial, que conserva
las relaciones definidas entre tablas.
Capítulo 1: Consideraciones Generales
~ 28 ~
CREATE TRIGGER debe ser la primera instrucción en el proceso por lotes y
solo se puede aplicar a una tabla. Un desencadenador se crea solamente en la
base de datos actual; sin embargo, un desencadenador puede hacer referencia
a objetos que están fuera de la base de datos actual (MSDN, 2008).
Vistas (Views):
Una vista es una tabla virtual cuyo contenido está definido por una consulta. Al
igual que una tabla real, una vista consta de un conjunto de columnas y filas de
datos con un nombre. Suelen utilizarse para centrar, simplificar y personalizar la
percepción de la base de datos para cada usuario (Melton and Simon, 2002).
Las vistas se pueden utilizar para realizar particiones de datos y para mejorar el
rendimiento cuando estos se copian. Además, permiten a los usuarios centrarse
en datos de su interés y en tareas específicas de las que son responsables. Los
datos innecesarios pueden quedar fuera de la vista; de ese modo, también es
mayor su seguridad, dado que los usuarios solo pueden ver los definidos en la
vista y no los que hay en la tabla subyacente (MSDN, 2008).
Funciones definidas por el usuario (Functions):
Al igual que las funciones en los lenguajes de programación, las funciones
definidas por el usuario (MSDN, 2008) son rutinas que aceptan parámetros,
realizan una acción, como un cálculo complejo, y devuelven el resultado de esa
acción como un valor. Son múltiples las ventajas de las funciones definidas por
el usuario entre las cuales se tienen:
Permiten una programación modular.
Permiten una ejecución más rápida.
Pueden reducir el tráfico de red.
Procedimientos Almacenados (Stored Procedure):
Los procedimientos almacenados pueden facilitar en gran medida la
administración de la base de datos y la visualización de información sobre esta
y sus usuarios. Son una colección pre-compilada de instrucciones SQL e
instrucciones de control de flujo opcionales, almacenadas bajo un solo nombre
Capítulo 1: Consideraciones Generales
~ 29 ~
y procesadas como una unidad. Estos se guardan en una base de datos,
permitiendo ser ejecutados desde una aplicación.
Los procedimientos almacenados pueden contener flujo de programas, lógica y
consultas a la base de datos; aceptar parámetros y proporcionar sus resultados,
devolver conjuntos individuales o múltiples y retornar valores.
Se pueden utilizar procedimientos almacenados para cualquier finalidad que
requiera la utilización de instrucciones SQL, con estas ventajas (MSDN, 2008):
Ejecución de una serie de instrucciones SQL en un único
procedimiento almacenado.
Referenciar a otros procedimientos almacenados desde el propio
procedimiento almacenado, con lo que se puede simplificar una serie
de instrucciones complejas.
El procedimiento almacenado se compila en el servidor cuando se
crea, por tanto, se ejecuta con mayor rapidez que las instrucciones
SQL individuales.
Aserciones (Assertions):
Las aserciones son un tipo de restricción especial que se puede especificar en
SQL sin que deba estar asociada a una tabla en particular, como es el caso de
las restricciones (Mota, 2005). Generalmente son utilizados para describir
restricciones que afectan a más de una tabla. Como las restricciones solo
pueden establecerse sobre tuplas de una tabla, las aserciones son úti les
cuando es necesario especificar una condición general de la base de datos que
no se puede asociar a una tabla específica. Por esta característica de poder
especificar una aserción para toda la base de datos y no para una tabla en
particular, se le llama restricción autónoma. Esto tiene grandes ventajas a nivel
conceptual, pero las hace difíciles de implementar.
Transacciones (Transactions):
Una transacción es una unidad única de trabajo. Si una transacción tiene éxito,
todas las modificaciones de los datos realizadas durante la transacción se
confirman y se convierten en una parte permanente de la base de datos. Si una
Capítulo 1: Consideraciones Generales
~ 30 ~
transacción encuentra errores y debe cancelarse o revertirse, se borran todas
las modificaciones de los datos (Gennick, 2006).
Cuando finaliza, una transacción debe dejar todos los datos en un estado
coherente. En una base de datos relacional, se deben aplicar todas las reglas a
las modificaciones de la transacción para mantener la integridad de todos los
datos.
Las modificaciones realizadas por transacciones simultáneas se deben aislar
unas de otras. Una transacción reconoce los datos en el estado en que estaban
antes de que otra transacción simultánea los modificara o después de que la
segunda transacción haya concluido, pero no reconoce un estado intermedio.
Esto se conoce como seriabilidad, ya que deriva en la capacidad de volver a
cargar los datos iniciales y reproducir una serie de transacciones para finalizar
con los datos en el mismo estado en que estaban después de realizar las
transacciones originales (MSDN, 2008).
Una vez concluida una transacción, sus efectos son permanentes en el sistema.
Las modificaciones persisten aún en el caso de producirse un error del sistema.
1.10 Gestores de bases de datos relacionales.
Los sistemas de gestión de bases de datos (en inglés database management
system, abreviado DBMS) son un tipo de software muy específico, dedicado a
servir de interfaz entre la base de datos, el usuario y las aplicaciones que la
utilizan. El objetivo principal de los SGBD es el de manejar de manera clara,
sencilla y ordenada un conjunto de datos que posteriormente se convertirán en
información relevante para una organización.
Algunas de las ventajas de los SGBD son:
Proveen facilidades para la manipulación de grandes volúmenes de datos:
o Simplifican la programación de equipos de consistencia.
o Manejando las políticas de respaldo adecuadas, garantizan que los
cambios de la base serán siempre consistentes sin importar si hay
errores correctamente, etc.
Capítulo 1: Consideraciones Generales
~ 31 ~
o Organizan los datos con un impacto mínimo en el código de los
programas.
o Bajan drásticamente los tiempos de desarrollo y aumentan la calidad
del sistema desarrollado si son bien explotados por los
desarrolladores.
Usualmente, proveen interfaces y lenguajes de consulta que simplifican la
recuperación de los datos.
Algunos de los SGBD que existen son:
Oracle
SQL Server
Posgre
MySql
De los gestores anteriormente mencionados uno de los más populares es el
Mysql ya que es multihi lo y multiusuario con más de seis millones de
instalaciones. MySQL AB, desde enero de 2008 una subsidiaria de Sun
Microsystems y ésta a su vez de Oracle Corporation desde abril de 2009,
desarrolla MySQL como software libre en un esquema de licenciamiento dual.
MySQL es software de fuente abierta. Fuente abierta significa que es posible
para cualquier persona usarlo y modificarlo. Cualquier persona puede bajar el
código fuente de MySQL y usarlo sin pagar. Cualquier interesado puede
estudiar el código fuente y ajustarlo a sus necesidades. MySQL usa el GPL
(GNU General Public License) para definir qué puede hacer y que no puede
hacer con el software en diferentes situaciones (Axmark and Widenius, 2009).
1.11 Facilidades de los entornos Web
Los entornos Web ofrecen muchas facilidades para la implementación de un
sistema (Keeker, 2006):
Almacenamiento: Un entorno Web brinda posibilidades ilimitadas de
almacenamiento y no depende de un lugar específico para guardar los
datos y la información pues esta se almacena de forma electrónica.
Capítulo 1: Consideraciones Generales
~ 32 ~
Accesibilidad: Al tener la posibilidad de estar conectado a Internet, puede
accederse desde cualquier parte del mundo.
Seguridad: Las posibilidades de seguridad de un ambiente Web permiten
establecer niveles de privilegio para acceder a la información.
Transmisión de la información: La información codificada puede ser
trasmitida de manera rápida y segura por la red.
Análisis: Un entorno Web puede trabajar conjuntamente con sistemas de
cómputo y análisis de datos y de información para mostrar los resultados
de manera que se facilite su visualización e interpretación.
Despliegue: La información se muestra en páginas Web, sin tener que
disponer de nuevos medios para mostrarla.
1.12 Conclusiones del Capítulo
Se puede concluir que las RI son parte incidente de modelos conceptuales, son
intensivamente usadas durante el análisis y diseño de sistemas de información.
Ellas son esenciales para asegurar la exactitud del modelo de información y su
habilidad para representar la semántica adecuada del dominio del problema.
Las RI pueden ser expresadas en diferentes niveles pero siempre para cumplir
su objetivo principal: velar por la integridad de los datos a las cuales están
asociadas.
~ 33 ~
2. Análisis y Diseño
del Sistema.
Capítulo 2: Análisis y Diseño del Sistema
~ 34 ~
En todo sistema de bases de datos se cuenta con dos componentes la BD y
una aplicación cliente que gestiona la información. Siempre se necesita analizar
y diseñar ambos componentes.
En el presente capítulo se abordarán los temas referentes al análisis y diseño
del sistema. Se especifican los requisitos obtenidos del análisis, el diseño del
esquema entidad relación (E/R) y del esquema relacional (R). Las restricciones
de integridad se analizarán de forma paralela a las fases de diseño de la
aplicación.
Se presenta una descripción del proceso de integridad a implementar en
lenguaje estándar SQL para garantizar el cumplimiento de las RI. Ilustran las RI
en cada fase del proceso de análisis y diseño con un ejemplo.
Se presentan los casos de uso para cada tipo de usuario del sistema y algunos
diagramas de transición de estado para ejemplificar acciones que se pueden
realizar.
2.1 Proceso de Análisis y Diseño del Sistema
El esquema que utilizaremos para el análisis y diseño difiere del que se utiliza
generalmente, ya que en el esquema propuesto se contempla una
paralelización entre el proceso de crear una aplicación de bases de datos y las
RI. En la Figura 1se presenta el esquema propuesto, donde la parte sombreada
es la representación del generalmente utilizado.
El esquema generalmente utilizado consta de cinco niveles donde el primero es
el cliente y el ultimo la aplicación de bases de datos necesitada por el cliente.
Los niveles intermedios son los requisitos, modelo Entidad/Relación (E/R),
modelo relacional (R) en ese orden. El paso entre los niveles se realiza en la
dirección de las flechas.
En el esquema utilizado se mantienen los mismos pasos que en el esquema
expresado anteriormente pero se le incorpora u proceso paralelo que manejaría
las RI en vinculación con cada uno de los pasos, por consecuencia: las RI en
lenguaje natural se vinculan al cliente y al análisis de los requisitos
proporcionado por el mismo; las RI en lenguaje técnico se expresarán en Alloy,
Capítulo 2: Análisis y Diseño del Sistema
~ 35 ~
y se vinculan al modelo Entidad/Relación; las RI en lenguaje formal se
expresarán en SQL y se vinculan con el Modelo Relacional; y la aplicación
interactuaría tanto con la base de datos como con las restricciones.
2.2 Análisis de los Requisitos.
El grupo CAMD-BIR necesita una aplicación informática con la que pueda
mejorar la visualización de sus investigaciones, esta aplicación debe ser capaz
de gestionar la información referente a los trabajos científicos que se realizan
en el grupo, exportar los datos, generar el “currículo Vitae” y mostrar la
información a través de la web.
Se realizaron entrevistas con los investigadores del grupo CAMD-BIR para
obtener la información que se consideraría de importancia para mejorar la
visualización del grupo. De la entrevista se obtuvo que para mejorar la
visualización del grupo hacía falta, tener almacenada la información contenida
Aplicación
RI en LT (Alloy)
RI en LF (SQL)
Cliente
Requisitos
Datos Aplicación RI en LN
Modelo E/R
Modelo R
Figura 1: Proceso de Análisis y Diseño.
Capítulo 2: Análisis y Diseño del Sistema
~ 36 ~
en el “currículo Vitae” de cada miembro, ya que en ese currículo se evidencia
tanto los aportes científicos, como la capacitación de la persona y a otras
personas, los eventos en que ha participado, además de estos datos, llamados
en su conjunto como trabajo científico, el currículo también cuenta con los datos
personales. Además de almacenar los datos involucrados con el “currículo
Vitae” también es de interés tener otras informaciones sobre el grupo para que
las personas que visiten la aplicación conozcan sobre lo que se realiza en el
grupo, cuáles son sus miembros y colaboradores, vean una galería temática y
otras informaciones de interés.
Como resultado de la entrevista se obtuvo que:
Se desea una base de datos para almacenar la información sobre: los
datos científicos (publicaciones y sus documentos suplementarios,
cursos, eventos y tesis), experiencias de los miembros del grupo,
colaboraciones que realizan los colaboradores, descargas de los
usuarios que visitarán el sistema y los datos personales (nombre,
apellidos, e-mail, etc.) de las personas involucradas.
La aplicación debe tener una galería de imágenes y noticias importantes
que quieren dar a conocer.
Se desea una aplicación web para gestionar los datos contenidos en la
base de datos, que los datos sean consistentes y vá lidos y esto solo se
puede lograr haciendo un fuerte uso de las restricciones de integridad.
Se desea una aplicación web que muestre los datos almacenados y otras
informaciones de forma amena y sencilla.
La aplicación informática requerida está compuesta por dos componentes: la
base de datos y la aplicación web. Cada de estas ellas están compuestas por
requisitos para poder expresar los datos y las restricciones asociadas. La unión
de los dos tipos de requisitos (de la aplicación y de los datos) conforman los
requisitos del sistema (Ver Anexo 1).
2.2.1 RI en lenguaje Natural
Capítulo 2: Análisis y Diseño del Sistema
~ 37 ~
De los requisitos del sistema y el cliente se derivan las RI en lenguaje natural,
estas se encuentran expresadas en el Anexo 2. De este anexo se excluyen las
restricciones inherentes a los modelos de bases de datos como son las que
representan las relaciones entre los datos.
Las restricciones se tratan en paralelo con el diseño y análisis del sistema, para
ir expresándolas en cada modelo con mayor nivel de detalle, haciendo más fácil
su comprensión y futura implementación en la base de datos y en la aplicación
web.
En lo adelante se uti lizará como ejemplo la R11 (ver Anexo 2) para ilustrar las
RI en cada nivel, esta restricción en lenguaje natural plantea que:
Al menos uno de los realizadores de una publicación tiene
que ser miembro.
2.3 Esquema Entidad Relación (E/R)
El modelo Entidad-Relación (ER) es el modelo de datos más usado para el
diseño conceptual de Bases de Datos. Fue presentado por Peter Chen en 1976
y se ha hecho muy popular; muchas conferencias han sido organizadas sobre
las aplicaciones del modelo ER en el diseño de Bases de Batos y en el de
software en general. En 1988 fue elegido como modelo estándar para los
Information Resource Dictionary Systems (IRDS) y debido a su gran utilidad,
muchas herramientas de diseño de Bases de Datos utilizan sus conceptos.
El esquema conceptual es una descripción concisa de los requisitos de los
datos e incluye descripciones detalladas de los tipos de entidad, relaciones, y
restricciones; éstos se expresan usando los conceptos proporcionados por el
modelo de datos de alto nivel. Estos conceptos no incluyen una implementación
detalla, ellos son normalmente más fáciles entender y pueden usarse para
comunicarse con los usuarios no-técnicos. El esquema conceptual de alto nivel
también puede usarse como una referencia para asegurar que los requisitos de
los datos de todos los usuarios se reúnen y que los requisitos no chocan. Este
acercamiento les permite a diseñadores de la base de datos concentrarse en
especificar las propiedades de los datos, sin preocuparse por los detalles del
Capítulo 2: Análisis y Diseño del Sistema
~ 38 ~
almacenamiento. Por consiguiente, es más fácil para ellos crear buenos diseños
conceptuales de la base de datos (Elmasri and Navathe, 2007).
Para realizar el diseño conceptual se necesita de herramientas que posibiliten
generar esquemas con las funcionalidades presentes en los modelos
conceptuales.
2.3.1 Herramienta de diseño ERECASE.
La utilización del modelo E/R ha sido la base de varias metodologías de diseño
para el desarrollo de sistemas de información y de bases de datos relacionales.
Un criterio para medir el éxito en el diseño de estos modelos es el nivel de
precisión del problema en la vida real. Un modelo puede ser una estructura
abstracta y compleja, y los diseñadores están propensos a cometer errores que
incorporan inconsistencia al modelo. Los errores e inconsistencias cometidas en
las etapas iniciales de diseño del ciclo de vida del software son muy costosos
de corregir.
Para los diseñadores de bases de datos se convierte en un problema difícil el
decidir cuándo un diagrama ER es válido o no. A esto se agrega que la mayoría
de las herramientas que diseñan esquemas conceptuales ER no hacen una
validación estructural ni semántica del diagrama. En los últimos años han
persistido múltiples intentos de dar un enfoque más sistemático a la resolución
de problemas de modelación. Uno de tales intentos ha sido la automatización
mediante el empleo de herramientas CASE (Álvarez et al., 2006).
ERECASE es una herramienta CASE para el diseño de bases de datos
relacionales que utiliza como modelo conceptual el modelo Entidad/Relación
Extendido (ERE). El grupo de investigación de Bases de Datos ubicado en el
Centro de Estudios Informáticos (CEI), de la Universidad Central de las Villas
(UCLV), posee una versión (v.3.0) creada el por ellos, de la herramienta.
Esta herramienta permite la validación estructural del diagrama ER basándose
en la cardinalidad máxima y mínima de las relaciones. Esta herramienta CASE
fue creada para el diseño de bases de datos con el objetivo que permita la
validación estructural de los diagramas (ERE) (Álvarez et al., 2006).
Capítulo 2: Análisis y Diseño del Sistema
~ 39 ~
2.3.2 Esquema E/R asociado al Sistema.
Los diagramas E/R facilitan las representaciones a partir de las cuales, el
desarrollador podrá trabajar. Además, permiten al analista hablarles a los
clientes en su propia terminología estableciendo un puente comunicativo de
suma importancia que se traducirá en beneficios mutuos; así los clientes
pueden indicar con mayor claridad que es lo que desean (Schmuller, 2000).
A partir de los requisitos obtenidos se diseña un esquema E/R (ver Anexo 3)
con la herramienta para el diseño y validación de bases de datos relacionales
ERECASE a través del modelo conceptuar ER.
El esquema precedente se divide en sub-esquemas para atender a una
actividad específica del sistema en cada porción del esquema. Con esta
subdivisión se enfatiza fácilmente algunos aspectos relevantes de cada
actividad en particular.
Sub-esquema de Personas:
Este sub-esquema (ver Anexo 3.1) contempla las entidades relacionadas con
las personas involucradas en la base de datos (usuarios, miembros y
colaboradores), las relaciones entre ellos y con algunas otras entidades. Es
necesario tener en cuenta algunas consideraciones:
Las personas que pueden tener datos científicos en la base de datos son
las que pertenecen al grupo (miembros, colaboradores o asociados).
Toda persona del grupo tienen un identificador científico que es el
utilizado para identificarse en las publicaciones.
Se almacenan las experiencias, temas de investigación y honores de los
miembros.
Los miembros que no tienen fecha de fin se consideran activos en el
grupo y los que la tienen se consideran baja.
Los miembros pueden tener o no una categoría docente.
De los colaboradores se registran las colaboraciones.
Todo miembro del grupo es un usuario.
Capítulo 2: Análisis y Diseño del Sistema
~ 40 ~
Sub-esquema de Publicaciones:
Este sub-esquema (ver Anexo 3.2) contempla las entidades relacionadas con
las publicaciones, su clasificación y las relaciones con otras entidades. Es
necesario tener en cuenta algunas consideraciones:
Las publicaciones tienen que tener al menos un realizador, el cual se
considera como autor.
Los realizadores de una publicación tienen orden.
Una publicación puede ser de tipo libro, artículo, conferencia, u otro.
De cada tipo de publicación se almacenan datos específicos.
El DOI de las publicaciones es único.
Sub-esquema de Cursos:
Este sub-esquema (ver Anexo 3.3) contempla las entidades relacionadas con
los cursos y las relaciones con otras entidades. Es necesario tener en cuenta
algunas consideraciones:
En cada curso al menos una de las personas involucradas (los que
imparten y reciben) tiene que ser miembro del grupo.
Sub-esquema de Eventos:
Este sub-esquema (ver Anexo 3.4) contempla las entidades relacionadas con
los eventos y las ponencias y las relaciones con otras entidades. Es necesario
tener en cuenta algunas consideraciones:
En un evento al menos una de las personas involucradas (participantes y
ponentes) tiene que ser miembro del grupo.
Una ponencia se exponen en un único evento.
Las personas pueden participar en un evento con o sin ponencias.
Las ponencias pueden recibir premios.
Una ponencia tiene que tener al menos un realizador.
En cada ponencia al menos una de las personas involucradas tiene que
ser miembro del grupo.
Sub-esquema de Tesis:
Capítulo 2: Análisis y Diseño del Sistema
~ 41 ~
Este sub-esquema (ver Anexo 3.5) contempla las entidades relacionadas con
las tesis y las relaciones con otras entidades. Es necesario tener en cuenta
algunas consideraciones:
Las tesis tienen que tener al menos un autor.
En cada tesis al menos una de las personas involucradas tiene que ser
miembro del grupo.
Sub-esquema de Ficheros de Descarga:
Este sub-esquema (ver Anexo 3.6) contempla las entidades relacionadas con
los ficheros que se pueden descargar, su clasificación y las relaciones con otras
entidades. Es necesario tener en cuenta algunas consideraciones:
Los ficheros se clasifican en: software, documento y base de dato.
Las publicaciones tienen ficheros suplementarios.
Se tiene un fichero por cada versión de software.
Para realizar una descarga es necesario que se sea usuario de la
aplicación.
Sub-esquema de Aplicación:
Este sub-esquema (ver Anexo 3.7) contempla las entidades relacionadas con
los datos específicos de la aplicación. Es necesario tener en cuenta que
Las entidades de este sub-esquema no se relacionan con ninguna
entidad de otro sub-esquema.
2.3.3 Representación de las RI obtenidas en el Esquema E/R
Algunas de las RI se representan en el esquema de forma explícita ya que
forman parte del Modelo E/R, como son el tipo de dato, la cardinalidad mínima y
máxima y las restricciones de generalización/especialización.
Las restricciones que son más complejas no se pueden representar con los
elementos definidos para el modelo E/R por lo que se hace necesario
expresarla en un lenguaje semi-natural, que sea pequeño, consistente con el
modelo y fácil de entender. Uno de los lenguajes de especificación que cumple
las características expresadas anteriormente es Alloy.
Capítulo 2: Análisis y Diseño del Sistema
~ 42 ~
Por ejemplo la R11 (ver Anexo 2) se expresa en Alloy como el hecho:
Fact PublicacionMiembro
{all p:Publicacion |all m:Miembro |some p.realizador in m}
2.4 Esquema Relacional
El modelo relacional representa la base de datos como una colección de
relaciones. En este modelo, cada fila en la tabla representa un hecho que
típicamente corresponde a una entidad del mundo real o relación. Se usan el
nombre de la tabla y nombres de la columna para ayudar a interpretar el
significado de los valores en cada fila (Elmasri and Navathe, 2007).
El esquema relacional en lenguaje estándar SQL se obtuvo a partir del
esquema E/R con la herramienta ERECASE, la cual brinda esta posibilidad,
aplicando las reglas generales de transformación. Al esquema relacional
obtenido se le realizaron algunos cambios como fueron los nombres de las
relaciones y de algunas variables y en las relaciones de
generalización/especialización. Los cambios que se le realizaron siempre fueron
consecuentes con las reglas de trasformación del modelo E/R al modelo R.
2.4.1 Implementación de las RI obtenidas en MySQL.
Al importar el esquema relacional al gestor MySQL se modelan algunas de las
restricciones de integridad como son: llaves primarias, llaves candidatas
(restricciones de unicidad) y las llaves foráneas (integridad referencial). Las
demás RI tienen que ser comprobadas con recursos de bases de datos al
realizar una acción (Insert, Update, Delete) o al finalizar una transacción (para
poder definir Rollback o Commit de dicha transacción).
Para implementar las RI en cada gestor hay que tener en cuenta los recursos
de SQL con los que cuenta. En particular MySQL 5.2.0 no posee algunos de los
recursos estándares del SQL como son:
Restricciones (Constraints) CHECK
Aserciones (Assertions).
Capítulo 2: Análisis y Diseño del Sistema
~ 43 ~
Atendiendo a las características particulares del gestor a utilizar (MySQL 5.2.0)
se puede decir que:
Las restricciones sobre columnas solo se pueden implementar mediante
Triggers ya que MySQL no cuenta con restricciones CHECK.
Las demás restricciones a implementar utilizando Triggers son
restricciones semi-complejasque se asocian con una tabla y se definen
para que se active al ocurrir una operación (insert, update o delete) sobre
dicha tabla. Puede también establecerse que se active antes o después
de la sentencia en cuestión (Axmark and Widenius, 2009). Estas
restricciones son las que se pueden chequear inmediatamente después
de realizar una operación.
Para implementar RI más complejas se necesita un mecanismo adicional
de apoyo en la base de datos, que haga uso de los recursos que brinda
el gestor (Alonso, 2010).
El proceso de integridad (Figura 2) que se implementa como mecanismo de
apoyo para la comprobación de las RI está dirigido al utilizado por Alonso
(Alonso, 2010).
La idea central es bien sencilla, el cliente realiza una petición al servidor, el cual
la transforma en una transacción, se comprueban las RI con los recursos
(trigger, funciones, vistas y procedimientos almacenados), el servidor decide la
acción a realizar (COMMIT o ROLLBACK) en dependencia de la lista de
BD Cliente Formulario Transacción
LRV T + F + P + V
Informar Resultados
T + F+ P + V = Trigger + Funciones + Procedimientos Almacenados + Vistas
Figura 2: Proceso de Integridad.
Decidir Acción
Capítulo 2: Análisis y Diseño del Sistema
~ 44 ~
restricciones violadas (LRV) y le informa al cliente lo que ha pasado. Si la LRV
no está vacía el servidor siempre escogerá como acción hacer un ROLLBACK y
le informará al cliente los mensajes contenidos en la LRV. En caso de que la
LRV esté vacía le toca al servidor decidir la acción respecto a otras operaciones
que tenga que realizar.
Para el mecanismo analizado anteriormente es necesario crear una tabla que
manejará los datos de las restricciones. Esta tabla contiene el código de la
restricción, el mensaje a mostrar, el estado en que se encuentra, el orden en
que se generó y el nombre del procedimiento almacenado con el cual se
comprueba (en el caso de las restricciones complejas). Además se necesita
otra tabla donde se almacenan los identificadores a los que hay que
comprobarle la integridad con el procedimiento almacenado y el código del error
al cual está involucrado. Ver el código script SQL relacionado en Anexo 4.
Para la comprobación de estas restricciones complejas haciendo uso de lo
mencionado anteriormente se necesita crear un Trigger en cada tabla a la cual
se le asocia una de las RI, este trigger es el encargado de insertar en la tabla
a_riid (tabla de los identificadores a los que hay que comprobarle las RI) el
identificador involucrado en la sentencia que dispara el Trigger y de modificar
en la tabla a_ri (tabla de restricciones) el estado de la restricción como posible
error que hay que comprobar (status = 1) y el orden en que se generó. Ejemplo
genérico del trigger comentado:
CREATE TRIGGER nombre_trigger BEFORE INSERT ON
nombre_tabla FOR EACH ROW BEGIN
CALL a_ri_addconsultar(codigo_error,NEW.ìd`);
END
Hasta aquí solo se han creado los recursos necesarios en la BD para procesar
una RI. Para realizar un conjunto de sentencias se hace uso de transacciones
enfocadas a la utilizada por Alonso (Alonso, 2010). En esta transacción, primero
se difiere el momento del COMMIT hasta que se especifique explícitamente,
luego se limpian los datos almacenados en otras transacciones (limpiar las
tablas a_ri y a_riid), se ejecutan las sentencias, para finalizar se invoca el
Capítulo 2: Análisis y Diseño del Sistema
~ 45 ~
procedimiento almacenado encargado de comprobar las RI que se hayan
obtenido, si existe alguna violación se realiza ROLLBACK sino se realiza
COMMIT. Un ejemplo genérico de transacción tendría la forma siguiente:
START TRANSACTION
BEGIN
SET AUTOCOMMIT = 0;
CALL a_ri_clean();
/* Ejecutar las sentencias SQL*/
CALL a_ri_executeconsultar();
IF (EXISTS(SELECT status FROM a_ri WHERE status = 2 LIMIT
1)) THEN
ROLLBACK;
ELSE
COMMIT;
END IF;
END;
Como ejemplo concreto, para la R11 se crean los triggers para insertar y
actualizar publicación, y eliminar realizador de publicación. Atendiendo al gestor
utilizado se necesita crear un trigger independiente para cada acción aunque
sean en el mismo tiempo y tabla. Todos los trigger contendrían el mismo la
misma llamada aunque cambiaría la forma de obtener el id de la publicación.
Para los triggers insertar y actualizar sería:
CREATE TRIGGER i_publicacion BEFORE INSERT ON publicacion
FOR EACH ROW BEGIN
CALL a_ri_addconsultar(1006,NEW.ìd`);
END
CREATE TRIGGER u_publicacion BEFORE INSERT ON publicacion
FOR EACH ROW BEGIN
CALL a_ri_addconsultar(1006,NEW.ìd`);
END
Capítulo 2: Análisis y Diseño del Sistema
~ 46 ~
Y para el trigger de eliminar realizador de publicación sería:
CREATE TRIGGER d_publicacion BEFORE INSERT ON
publicacionrealizador FOR EACH ROW BEGIN
CALL a_ri_addconsultar(1006,NEW.ìdpublicacion`);
END
Para verificar al finalizar la transacción se ejecuta el procedimiento almacenado
siguiente, el cual actualiza el status del error:
CREATE PROCEDURE `a_r_p_realizador_publicacion_miembro`()
BEGIN
IF (1 = (SELECT `status` FROM `a_ri` WHERE `status`=2 OR
`codigo`=1006 LIMIT 1)) THEN
IF 0 < (SELECT count(*) FROM `a_riid` WHERE
`a_riid`.`idcodigo`=1006 AND 0 = (SELECT count(*) FROM
`a_r_v_realizador_publicacion` WHERE
`idpublicacion`=`a_riid`.`idpinteger` LIMIT 1) LIMIT 1)
THEN
CALL `a_ri_updateconsultar_error`(1006);
ELSE
CALL `a_ri_updateconsultar`(1006);
END IF;
END IF;
END;
2.5 Actores y Casos de Uso
Un caso de uso es una técnica cuyo objetivo es obtener los requisitos
potenciales de un sistema. Cada caso de uso proporciona uno o más
escenarios que indican cómo debería interactuar el sistema con el usuario o con
otro sistema para conseguir un objetivo específico (Arboláez, 2011).
Atendiendo a los requisitos del sistema (ver Anexo 1), se cuenta con dos tipos
de actores, los invitados (Figura 3) y los usuarios (Figura 4). El actor de tipo
invitado (Figura 3) puede navegar por el sitio y consultar la información pública,
Capítulo 2: Análisis y Diseño del Sistema
~ 47 ~
es decir puede acceder a las publicaciones, cursos, noticias, galería, etc.
Además puede ver los documentos activos para descargar, pero para realizar
esta acción, tiene que estar autenticado.
Figura 3: Casos de Uso del Invitado.
Al autentificarse este tipo de actor (invitado) se convierte en un usuario, el cual
siempre va a depender de poner sus credenciales en el sistema. Un Usuario
(Figura 4) puede consultar la información pública del sistema (publicaciones,
cursos, noticias, galería, etc.), realizar descargas, cambiar a su perfil y la
contraseña, cerrar sesión y dejar comentarios.
Figura 4: Casos de Uso del Actor tipo Usuario.
Capítulo 2: Análisis y Diseño del Sistema
~ 48 ~
Los usuarios pueden tener privilegios, por lo que se subdivide en:
administradores de usuarios (Figura 5), administradores de aplicación (Figura 6)
y administradores de datos científicos (Figura 7). Además existe un tipo
especial de usuarios que son los miembros activos del grupo (Figura 8), es
decir los miembros actuales.
Vale la pena destacar que un usuario puede tener uno o más de los privilegios,
los cuales serían otorgados por el administrador de usuarios y además puede
ser usuario especial si es miembro del grupo.
Un actor que tiene el privilegio de administrar usuarios (Figura 5), pude hacer lo
mismo que un usuario, además de otras acciones específicas al privilegio.
Figura 5: Casos de Uso del Administrador de Usuarios.
Un actor que tiene el privilegio de administrar datos de la aplicación (Figura 6),
pude hacer lo mismo que un usuario, además de otras acciones específicas al
privilegio.
Entiéndase como datos de la aplicación, como los obtenidos por los requisitos
de la aplicación (Ver Anexo 1), entre los que se encuentran las noticias, galería
de imágenes y ficheros para descarga.
Este actor también puede consultar información sobre las descargas, para
saber fechas, usuarios y documentos de las mismas.
Capítulo 2: Análisis y Diseño del Sistema
~ 49 ~
Figura 6: Casos de Uso del Administrador de datos de la Aplicación.
Un actor que tiene el privilegio de administrar los datos científicos (Figura 7), es
un usuario y además puede realizar otras acciones específicas al privilegio.
Este actor tiene privilegios en la BD para gestionar todos los datos científicos;
Entiéndase como datos científicos las publicaciones, cursos, tesis, eventos,
experiencias, honores y temas de investigación de los miembros,
colaboraciones de los colaboradores.
Este actor también gestiona los datos de los miembros, colaboradores y
asociados. Además gestiona los datos auxiliares (tablas pequeñas, pero que
garantizar a disminuir los errores de tipografía) relacionados a los datos
científicos mencionados anteriormente.
Capítulo 2: Análisis y Diseño del Sistema
~ 50 ~
Figura 7: Casos de Uso del Administrador de los datos Científicos.
El usuario especial (Figura 8), miembro activo, es como un actor que tiene el
privilegio de administrar datos científicos (Figura 7), pero su principal
característica es que solo puede gestionar los datos científicos de los cuales el
forme parte.
Un miembro activo, es un miembro del grupo que no ha sido baja. Este tipo de
usuario especial fue creado atendiendo a uno de los requisitos del sistema
(Ver Anexo 1) el cual plantea que cada miembro pueda administrar sus datos
científicos, por ejemplo puede administrar una publicación donde él esté
presente entre los realizadores, ya sea como autor o coautor.
Además de un miembro activo se puede obtener sus “currículo Vitae”, por lo
que cada miembro puede configurar como desea mostrar la información en su
currículo. Se puede configurar el orden general en que se mostrará y que
características y en qué orden se desea mostrar de cada dato científico.
Capítulo 2: Análisis y Diseño del Sistema
~ 51 ~
Figura 8: Casos de Uso del Usuario Especial, Miembro Activo.
2.6 Diagramas de Transición de Estado.
Una máquina de estados es un comportamiento que especifica las secuencias
de estados por las que pasa un objeto, en respuesta a eventos, a lo largo de su
vida. Un diagrama de transición de estados muestra una máquina de estados,
destacando el flujo de control entre ellos. Captura, a partir de un punto inicial, la
secuencia de cambios que ocurren en un sistema, o sea, los estados en que
puede encontrarse un objeto en respuesta a algún suceso, así como las
transiciones entre esos estados (Arboláez, 2011).
En este epígrafe se muestran algunos de los diagramas de transición de
estados para el sistema. Algunos de los considerados más importantes son los
relacionados a los casos de uso: registrar un usuario (Figura 9), loguearse un
invitado (Figura 10), insertar una publicación (Figura 11) y exportar una tabla de
publicación (Figura 12).
Capítulo 2: Análisis y Diseño del Sistema
~ 52 ~
En el diagrama de transición de estados para el caso de uso: registrar a un
usuario (Figura 9), al encontrar algún error en cualquier estado, se le informaría
al usuario, para que lo corrigiera en el formulario y volver a realizar el proceso
de validación de las RI.
Figura 9: Diagrama de Transición de Estados para Registrar un Usuario.
En el diagrama de transición de estados para el caso de uso: loguearse un
invitado (Figura 10), cuando se llenan las credenciales se verifica que
concuerden con alguna de la BD, de ser así se cargan sus datos a la aplicación
Capítulo 2: Análisis y Diseño del Sistema
~ 53 ~
y le permite ver el menú de Administración, en caso contrario se permite volver
a llenar las credenciales.
Figura 10: Diagrama de Transición de Estados para Loquearse un Invitado.
En el diagrama de transición de estados para el caso de uso: insertar una
publicación (Figura 11), se muestra que para realizarlo tiene que ser un usuario
que tenga este privilegio (administrador de datos científicos (Figura 7) o
miembro especial (Figura 8)). En este diagrama al igual que el de la Figura 9 se
evidencia la validación de las RI, de manera que el proceso no termina mientras
haya errores.
Capítulo 2: Análisis y Diseño del Sistema
~ 54 ~
Figura 11: Diagrama de Transición de Estados para Insertar una
Publicación.
Capítulo 2: Análisis y Diseño del Sistema
~ 55 ~
El diagrama de transición de estados para el caso de uso: exportar tabla de
publicaciones (Figura 12), se muestra el camino para llevar a cabo este
proceso.
Figura 12: Diagrama de Transición de Estados para Exportar
Publicaciones.
Para este exportar la información sobre las publicaciones contenida en la
página se necesita del privilegio para gestionar las publicaciones. Se puede
configurar en el formulario, el formato de salida del documento digital
(Excel2007, pagina web, documento portable, etc.), el nombre del documento a
Capítulo 2: Análisis y Diseño del Sistema
~ 56 ~
obtener y el título que tendrá la tabla. Al mostrar el documento en el navegador
se podrá escoger abrir, guardar o cancelar la descarga mostrada.
2.7 Conclusiones del Capítulo.
Para la realización del capítulo se tuvo en cuenta los pasos del proceso
propuesto en el epígrafe 2.1. Se realizó el análisis y diseño por cada paso del
proceso de forma descendente comenzando por el análisis de los requisitos,
pasando por los modelos y las RI expresadas en cada uno de ellos y
terminando con los casos de uso y diagramas de transición de estado para la
aplicación que se conectará a la base de datos.
~ 57 ~
3. Interfaz de Usuario.
Capítulo 3: Interfaz de Usuario
~ 58 ~
En este capítulo se abordan los temas relacionados a la implementación de la
interfaz de usuario. Se utilizó la bibliografía para seleccionar las tecnologías a
utilizar. Se definen los componentes del sistema y la interacción entre ellos.
Además hace una descripción detallada de la interfaz desde el punto de vista
de la visualización de la información y de la gestión de la misma.
3.1 Tecnología Utilizada.
Una página Web es un sistema de documentos enlazados y accesibles a través
de Internet, que pueden contener texto, imágenes, vídeos, etc. Un sitio Web es
un grupo de páginas Web, generalmente comunes a un dominio de Internet.
Estas son accedidas desde una URL (del inglés Uniform Resource Locutor) raíz
común llamada portada (index), que es una secuencia de caracteres, de
acuerdo a un formato estándar, usada para nombrar recursos, como
documentos e imágenes, por su localización. Esa dirección es única para cada
uno de los recursos de información disponibles en Internet.
Las tecnologías Web poseen una significación preponderante por el papel que
está jugando internet en el mundo moderno. Esta plataforma WWW ha ido
evolucionando paulatinamente para convertirse en un ambiente donde se
implementan potentes aplicaciones cliente/servidor o arquitecturas de n capas,
unido a ello han ido surgiendo nuevas tecnologías que se relacionan con el
desarrollo Web lo que hacen a este más interactivo e interesante. Entre las
tecnologías utilizadas para la creación y mantenimientos de sitios Web, están
las que funcionan del lado del cliente y las del lado del servidor.
Tecnologías del lado del cliente (TC):
HTML
CSS
XML y sus derivados
JavaScrip/DOM.
Tecnologías del lado del servidor (TS):
CGI y Perl.
Capítulo 3: Interfaz de Usuario
~ 59 ~
PHP.
ASP.
3.1.1 HTML
HTML, no es un lenguaje de programación, es un lenguaje de especificación de
contenidos para un tipo específico de documentos. Es decir, mediante HTML se
puede especificar, usando un conjunto de etiquetas o tags, cómo va a
representarse la información en un navegador o browser. Se centra en la
representación en la pantalla de la información.
HTML es un lenguaje muy sencillo que permite describir hipertexto, es decir,
texto presentado de forma estructurada y agradable, con enlaces (hyperlinks)
que conducen a otros documentos o fuentes de información relacionadas, y con
inserciones multimedia como gráficos y sonidos. Además este lenguaje, permite
a los desarrolladores crear documentos que pueden ser interpretados en
ordenadores que tengan diferentes sistemas operativos (Teague, 2005).
3.1.2 Java Script
Java Script es un lenguaje de scripts desarrollado por Netscape para
incrementar las funcionalidades del lenguaje HTML. Se utiliza embebido en el
código HTML.
Zakas (Zakas, 2005) considera que algunas de las características más
importantes del lenguaje son:
Es un lenguaje interpretado por lo que no requiere de un compilador. El
navegador del usuario se encarga de interpretar el código Java Script
(que se encuentra en las páginas HTML) y ejecutarlo correctamente.
Java Script permite controlar las ventanas del navegador y el cliente que
muestran.
Permite controlar contenido dinámico y efectos especiales.
Capítulo 3: Interfaz de Usuario
~ 60 ~
Evita depender del servidor Web para la validación de datos que un
usuario entra por el formulario antes de enviarlo, para cálculos sencillos y
para responder eventos generados por el usuario.
Es un lenguaje orientado a eventos. Cuando un usuario hace click sobre
un enlace o mueve el puntero sobre una imagen, está ocurriendo un
evento y a través del Java Script se pueden desarrollar acciones que den
respuesta a estos eventos.
Es un lenguaje orientado a objetos. El modelo de objetos de Java Script
está reducido y simplificado, pero incluye los elementos necesarios para
que los Scripts puedan acceder a la información de una página y puedan
actuar sobre la interfaz del navegador.
3.1.3 CSS
Las hojas de esti lo en cascada o CSS (del inglés Cascading Style Sheets),
constituyen un lenguaje sencillo que complementa el HTML, suponiendo un
apoyo fundamental a la hora de diseñar páginas Web, porque permiten una
mayor precisión en el ajuste de los elementos de diseño. El W3C (World Wide
Web Consortium) es el encargado de formular la especificación de las hojas de
estilo que servirán de estándar para los agentes de usuario o navegadores.
Esta técnica consiste en separar el diseño del contenido, de manera que las
indicaciones para conformar el diseño se agrupan en una hoja de estilo o
archivo fuera del contenido del documento de la página HTML. Lo que hace
fundamentalmente el código de las hojas de estilos es transformar las etiquetas
del lenguaje HTML y conformarlas a las características que se quiera darle;
pero también, y esto es lo importante, con este código se pueden crear
etiquetas nuevas, que se introducen dentro del documento. Una de las ventajas
de las hojas de estilos es que se puede modificar algunas características de
todos los documentos de un sitio Web desde un archivo, sin tener que
modificarlas en cada uno de los documentos (Pérez, 2009).
Capítulo 3: Interfaz de Usuario
~ 61 ~
3.1.4 JQuery
jQuery es una biblioteca o framework de Javascript, creada inicialmente por
John Resig, que permite simplificar la manera de interactuar con los
documentos HTML, manipular el árbol DOM, manejar eventos, desarrollar
animaciones y agregar interacción con la tecnología AJAX a páginas web. Fue
presentada el 14 de enero de 2006 en el BarCamp NYC.
jQuery es software libre y de código abierto, posee un doble licenciamiento bajo
la licencia MIT y de la GNU General Public License, jQuery, al igual que otras
bibliotecas, ofrece una serie de funcionalidades basadas en Javascript que de
otra manera requerirían de mucho más código. Es decir, con las funciones
propias de esta biblioteca se logran grandes resultados en menos tiempo y
espacio.
Características:
Selección de elementos DOM.
Eventos.
Manipulación de la hoja de estilos CSS.
Efectos y animaciones.
AJAX.
Soporta extensiones.
Utilidades varias como obtener información del navegador, operar con
Objetos y Arrays, etc.
Compatible con los navegadores Firefox 2.0+, Internet Explorer 6+,
Safari 2.0.2+ y Opera 9+.
jQuery consiste en un único fichero JavaScript que contiene las funcionalidades
comunes de DOM, eventos, efectos y AJAX. La característica principal de la
biblioteca es que permite cambiar el contenido de una página web sin
necesidad de recargarla, mediante la manipulación del árbol DOM y peticiones
AJAX. Para ello utiliza la función $() o jQuery() (Chaffer and Swedberg, 2011).
Capítulo 3: Interfaz de Usuario
~ 62 ~
3.1.5 PHP
El PHP, es un lenguaje interpretado de alto nivel embebido en páginas HTML y
ejecutado en el servidor. El PHP originalmente diseñado en Perl, seguidos por
la escritura de un grupo de CGI binarios escritos en el lenguaje C por el
programador Danés-Canadiense Rasmus Lerdorf en el año 1994 para mantener
un control sobre quien visitaba su currículum y guardar ciertos datos, como la
cantidad de tráfico que su página Web recibía (Castagnetto et al., 1999 ).
Es software libre, lo que implica menos costes y servidores más baratos que
otras alternativas. Es muy rápido y su integración con la base de datos MySQL
y el servidor Apache, le permite constituirse como una de las alternativas más
atractivas del mercado.
Es multiplataforma, funciona tanto para Unix (con Apache) como para Windows
(con Microsoft Internet Information Server) de forma que el código que se haya
creado para una de ellas no tiene porqué modificarse al pasar a la otra
(Mandrake, 2008).
Todas las operaciones en php que tiene una página web se realizan
transparentes al usuario, el código PHP es ejecutado en el servidor y el
resultado enviado al navegador. El resultado es normalmente una página
HTML. Por lo que al usuario le parecerá que está visitando una página HTML
que cualquier navegador puede interpretar (Castagnetto et al., 1999 ).
3.2 Componentes y Módulos del Sistema.
El sistema consta de 3 componentes:
Interfaz Cliente.
Aplicación Servidora.
Base de datos.
Capítulo 3: Interfaz de Usuario
~ 63 ~
Figura 13: Componentes y Módulos del Sistema.
Como se puede observar en la Figura 13cada componente se subdivide en
módulos. El módulo de las RI está presentes en cada componente aunque no
se programan igual y en la base de datos se encuentran todas.
En la Interfaz Cliente las RI fueron programadas con Javascript para minimizar
los accesos a la Aplicación Servidora y por ende a no realizar consultas que
pueden generar errores que son fáciles de detectar como son los datos
requeridos u obligatorios y los tipos de dichos datos.
En la Aplicación Servidora las RI se realizaron con el lenguaje PHP, para
minimizar los errores de datos únicos y de entidades existentes en la base de
datos. Otras de las RI implementadas en este componente fueron restricciones
específicas de aplicación como son que al subir un fichero se haya realizado
correctamente y que si eres administrador de usuario no te puedes eliminar o
cambiarte los privilegios, estas RI no son sobre los datos en específico por lo
que no se implementan en la BD.
Base de
Datos
RI
RI
RI
Interfaz Cliente
Páginas públicas
RI
Administración
Usuarios
Aplicación
Datos Científicos
Miembro Activo
Aplicación Servidora
Visualización de
datos
Gestión
de datos
Exportar datos
Currículo Vitae
RI
Capítulo 3: Interfaz de Usuario
~ 64 ~
La mayoría de las RI asociadas a los datos fueron implementadas en la BD, las
inherentes al modelo con restricciones de llave primaria, unicidad, llaves
foráneas y nulidad. Las semi-complejas, es decir referentes a una acción en
específico (insert, update, delete) con triggers y las complejas como se expresó
en el epígrafe 2.4.1.
3.3 Interfaz Web
Las tecnologías Web poseen una significación preponderante por el papel que
está jugando internet en el mundo moderno. Esta plataforma WWW ha ido
evolucionando paulatinamente para convertirse en un ambiente donde se
implementan potentes aplicaciones cliente/servidor o arquitecturas de n capas,
unido a ello han ido surgiendo nuevas tecnologías que se relacionan con el
desarrollo Web lo que hacen a este más interactivo e interesante. Entre las
tecnologías utilizadas para la creación y mantenimientos de sitios Web, están
las que funcionan del lado del cliente y las del lado del servidor.
Cuando los usuarios exploran una aplicación, sobre todo Web, miran y sienten.
La apariencia del sistema constituye el modo en que este se muestra y la
personalidad que le transmite al usuario, lo cual conducirá, sobre todo en una
aplicación como la propuesta, al éxito o al fracaso. Es por ello que, para lograr
la apariencia adecuada y que el usuario se sienta confortable, se tienen en
cuenta varios aspectos, sobre todo relacionados con tipografía, colores,
gráficos, navegación, composición del sitio, etc., que a continuación se exponen
(Gallo, 2011).
En este proyecto se utilizaron de las tecnologías del lado servidor el PHP y de
las del lado cliente el HTML, CSS, Javascript, la librería JQuery y objetos Json.
3.3.1 Sitio de información pública.
La aplicación consta de un sitio web a la cual cualquier persona que la visite
podrá consultar la información pública del sistema. La Figura 14muestra la
página principal o de inicio del Sistema.
Capítulo 3: Interfaz de Usuario
~ 65 ~
Figura 14: Página principal del Sistema.
A través del menú de Contenidos (Contents) se pueden acceder a las Noticias
(New), Actividades (Activities), Enlaces de Interés (links), Publicaciones
(Publications), Cursos (Couses), Eventos (Conferences), Tesis (Thesis),
Premios y reconocimientos (Awards), Descargas (Downloads) y a la Galería
(Gallery). En estos vínculos la información se encuentra escrita en forma de
texto y organizada por fecha. Además en estas páginas se brinda la posibilidad
de realizar búsquedas sobre el contenido mostrado.
A través del menú de inicio de sesión (Log In), se puede iniciar la sección
llenado los datos de usuario y contraseña o registrase un nuevo usuario en el
vínculo registrarse (Register). Al autenticarse un usuario este menú desaparece
ya que pierde funcionabilidad.
A través del menú Comentario (Comments) se puede dejar comentarios, los
cuales si son aprobados se visualizan.
Si un usuario está logueado se puede ver el menú de administración el cual
tiene los vínculos de cambiar contraseña (Change Password), perfil (Profile),
Capítulo 3: Interfaz de Usuario
~ 66 ~
cerrar sesión (Log Out) y en caso de que el usuario tenga algún tipo de
privilegio se le mostrará un vínculo al sitio de gestión de datos (Data
Administrations).
A modo de ejemplo se tiene que la página de publicaciones (Figura 15) muestra
una información de forma breve sobre todas las publicaciones existentes en la
base de datos, ordenadas por fecha comenzando con la más actual (es decir,
en orden descendente). Muestra el total de publicaciones. Todas las
publicaciones pueden ser vistas a través de los vínculos anterior y siguiente
mostrado cada vez20 publicaciones.
Figura 15: Página pública de Publicaciones.
Además en esta página se permite realizar búsquedas atendiendo al contenido,
titulo, fecha de publicación y tipo de publicación.
Si se quiere obtener una información más detallada sobre una publicación en
específico se da click en Más Información (More Information) y se accede a una
página que contiene todos los datos almacenados referentes a dicha
publicación (Figura 16).
Capítulo 3: Interfaz de Usuario
~ 67 ~
Figura 16: Página específica de Publicación.
En esta página se brinda la posibilidad de contactar con los realizadores ; si la
publicación tiene DOI se brinda un vínculo para acceder a ella. Además si la
publicación utilizó documentos suplementarios (Support Informations) y se
encuentran disponibles para descargar se brinda un vínculo para ir a la página
específica del documento (Figura 17).
Figura 17: Página específica de Documento.
Capítulo 3: Interfaz de Usuario
~ 68 ~
En esta página se muestra toda la información referente al documento, y un link
para su descarga, si el usuario se encuentra autenticado podrá realizar la
descarga sino no podrá y se le mostrará un mensaje como el de la Figura 18.
Figura 18: Mensaje de descarga denegada.
3.3.2 Sitio de Gestión de Datos.
El módulo de gestión de los datos del sistema, también es una interfaz web que
maneja los datos a través de Ajax y Json. Permite realizar las sentencias de
selección, búsqueda, inserción, actualización y eliminación de datos, además
permite exportar los resultados a Excel5, Excel 2007, CSV, HTML y PDF.
Para entrar al sitio de administración los usuarios necesitan tener al menos un
privilegio o ser usuario especial.
Todos los usuarios poseen los siguientes 3 menús generales (Figura 19), junto
con los especificados a los privilegios que poseen. El menú home permite
regresar a la página principal del sistema, el menú profile permite realizar las
configuraciones del perfil y el menú Log Out, cierra la sesión del usuario.
Figura 19: Menús Generales de Administración.
En la Figura 20se muestran todos los menús que tendrían los usuarios que
poseen todos los privilegios y son miembros activos.
Figura 20: Menú de Administración con todos los privilegios.
El menú adicional para el usuario con privilegio de Administrar Usuarios sería
como se muestra en la Figura 21. En este menú se encuentran los vínculos
Capítulo 3: Interfaz de Usuario
~ 69 ~
para gestionar los usuarios y los países. A los usuarios se les puede realizar
acciones específicas como son cambiar la contraseña y cambiar los privilegios.
Figura 21: Menú Adicional para el Administrador de Usuarios.
El menú para el usuario con privilegio de Administrar los datos de la Aplicación
sería como se muestra en la Figura 22. En este menú se encuentran los
vínculos para la gestión de noticias, galería y documentos para descarga. De
los documentos se pueden ver todos o por las clasificaciones (software, base
de datos y otros tipos de documentos). El usuario que tenga este privilegio
también podrá consultar las descargas que se han realizado.
Figura 22: Menús Adicionales para el Administrador de la Aplicación.
Los menús adicionales para los usuarios con privilegio de Administrar Datos
Científicos serían los que se muestran en la Figura 23. Estos menús son grupo,
publicaciones, cursos, eventos, tesis. A través del menú grupo se gestionan los
datos de los miembros, colaboradores y asociados.
Capítulo 3: Interfaz de Usuario
~ 70 ~
Figura 23: Menús Adicionales para el Administrador de datos Científicos.
Los menús adicionales para el usuario que es miembro activo serían los de la
Figura 24. Los vínculos presentes en el menú profile son los utilizados para
gestionar los datos científicos y las configuraciones del “currículo vitae”.
Figura 24: Menús Adicionales para el Usuario Especial
Capítulo 3: Interfaz de Usuario
~ 71 ~
A través del menú other data (Figura 24) se gestionan los datos auxiliares
organizados por temáticas; por en el vínculo persona se puede insertar y
actualizar colaboradores y asociados.
En cada uno de los vínculos proporcionados por el menú y sub-menús a
excepción de los vínculos página principal (Home) y cerrar sesión (log Out) se
muestra una página con la información en forma de tabla (Figura 25) donde se
permite realizar sobre los datos las acciones de inserción (insert), actualización
(update), eliminación (delete), búsqueda (search), cargar nuevamente los datos
(refresh) y exportar (export). Algunas páginas tienen más acciones pero en
general todas tienen las expresadas anteriormente.
Figura 25: Página de Gestión de Publicaciones.
Todos los formularios que se muestran se hacen a través de diálogos modales
que se realizaron con una biblioteca basada en JQuery llamada JDialog, la cual
genera un estilo apropiado para el manejo de formularios. Esta librería permite
utilizar el ajax para procesar los datos antes de subirlos al servidor (verificar las
Capítulo 3: Interfaz de Usuario
~ 72 ~
RI más sencillas con javascript y si están correctos los sube al servidor ) y el
resultado del servidor (si se generó algún error lo muestra en el formulario y si
no refresca la página para mostrar los resultados realizados con el formulario).
Los formularios de insertar y actualizar (Figura 26) se dividen en 4 parte: el
título (donde se muestra la acción a realizar), mensaje (donde se muestran los
mensajes de error y notas), el formulario (donde cada campo tiene una etiqueta)
y los botones de acción (Submit y Cancel).
Figura 26: Formulario de Insertar/Actualizar Publicación.
Si se da click en los botones de update o delete en alguna de las páginas de
administración (Figura 25) y no se ha marcado la casilla correspondiente a lo
que se quiere editar o eliminar, se visualizará un mensaje (Figura 27) donde se
informa que no se ha seleccionada ninguna entidad para la acción.
Figura 27: Error sobre que no hay datos seleccionados.
Capítulo 3: Interfaz de Usuario
~ 73 ~
Al haber seleccionado los elementos (marcando las casillas correspondientes)
para eliminar, siempre se mostrará un mensaje con el objetivo de confirmar que
se quieren eliminar los elementos (Figura 28), en el cual se puede aceptar la
eliminación o cancelarla.
Figura 28: Confirmación para Eliminar
Para exportar las entidades de las páginas de administración, se da click en el
vínculo Export y aparecerá un formulario como el de la Figura 29 para
configurar el documento que se generará con la información. Para exportar los
datos a los formatos Excel, CSV y HTML se utiliza la librería PHPExcel y para
exportarlos a PDF se utilizan las librerías PHPExcel y TCPDF.
Se exportarán todos los datos atendiendo al formulario de búsqueda
correspondiente (Figura 31), aunque los datos estén separados en varias
páginas. Si no está activado el formulario de búsqueda entonces se quieren
exportar todos los datos que puede mostrar la tabla entre todas sus páginas.
Figura 29: Formulario de Exportar tabla.
Capítulo 3: Interfaz de Usuario
~ 74 ~
Al dar click en el botón Submit en el formulario de exportar, se generará el
documento atendiendo a las propiedades especificadas. Cuando el servidor
termine de construir el documento lo enviará al navegador a través de la
ventana de descarga (Figura 30), para que el usuario seleccione la acción
(abrir, guardar o cerrar) a realizar con el documento.
Figura 30: Ventana de acción para descargas.
Si se desea realizar búsquedas se da click en el botón Search y aparecerá en la
página un formulario como el de la Figura 31.
Figura 31: Formulario de búsqueda de Publicaciones.
Capítulo 3: Interfaz de Usuario
~ 75 ~
En el formulario de búsqueda se introducen los datos y al dar click en el botón
Find se realizará una consulta al servidor a través de Ajax para obtener los
datos que coinciden con la búsqueda, se le muestran al usuario y se le
actualizan los números del total de datos encontrados y la cantidad de páginas
que significa esto.
Cada miembro activo puede configurar como desea que se vea su “currículo
Vitae”, cuando algún usuario, inclusive él lo descargue. Para realizar estas
configuraciones en el menú Profile (Figura 24) a cada miembro le aparece el
vínculo Configurations a través del cual pueden acceder a la página que a
través de vínculos le muestra los formularios para realizar algunas
configuraciones.
Las configuraciones que pueden realizar a través de esta página son:
Características Generales del Currículo (Figura 32).
o Orden que tiene los tipos de datos científicos en el currículo.
o Formato en que desean mostrar la fecha (y/m/d o d/m/y).
o Orden de los elementos a través de la fecha (ascendente o
descendente)
Características particulares para cada tipo de dato científico (Figura 33).
Cada configuración es específica para cada tipo de dato científico y si el
miembro desea que todas sus publicaciones se vean con el mismo
formato tiene que configurarlo para los Artículos, Conferencias, Libros y
Otras Publicaciones.
o Datos a mostrar en el Currículo.
o Orden en que se mostrarán los datos.
Capítulo 3: Interfaz de Usuario
~ 76 ~
Figura 32: Configuración General del Currículo Vitae.
Figura 33: Configuración de los Aspectos de los Artículos (Publicaciones).
Capítulo 3: Interfaz de Usuario
~ 77 ~
3.4 Manejo de las RI
Con el objetivo de mantener la integridad al gestionar los datos, si no se cumple
alguna restricción se le informa al cliente cual es para que pueda solucionarla.
Las RI en esta aplicación se comprueban utilizando varias vías , aunque todas
después de dar click en el botón Submit.
La comprobación de las restricciones más sencillas como son los campos
requeridos, o que los campos tengan un dominio específico (entero, real o
cadena), se realizan con javascript en el lado cliente, antes de enviar los datos
al servidor. Si en el formulario falta algún dato requerido, o algún dato incumple
con el dominio que debe tener se le informa al cliente, con un texto en el área
de mensaje del Dialog. El texto mostrado se destaca con un reborde de color
amarillo y si el error es referente a un campo en específico se señala este con
un reborde rojo, para resaltar donde es el error. Para ver un ejemplo de un
campo requerido al actualizar los datos de un miembro ver la Figura 34.
Figura 34: Error de campo requerido.
Otro tipo de error posible es que al adjuntar un documento no se cargue en el
servidor correctamente, ya sea porque el documento no existe, no se pudo
cargar, era muy grande, o se cargó parcialmente. Las comprobaciones
referentes a los documentos subidos se realizan en el servidor con P HP. Si
ocurrió algún error en el documento que se trataba de subir por problemas de la
conexión u otro, se le envía un mensaje al cliente, como el de la Figura 35,
donde se muestra la naturaleza del error encontrado.
Capítulo 3: Interfaz de Usuario
~ 78 ~
Figura 35: Error al subir un documento.
Las restricciones asociadas a los datos se verifican directamente en la base de
datos utilizando los recursos que posee el MySQL y la implementación de RI en
la BD que se muestra en el epígrafe 2.4.1. Todas las RI se verifican en la BD
con el objetivo de garantizar el cumplimiento de todas las restricciones captadas
en el análisis de los requisitos.
Algunas de las restricciones serían:
No se puede eliminar un dato que contiene dependencias especificadas
en la BD (como acción de restricción en actualización/eliminación en
alguna relación), por lo que el mensaje proporcionado sería como la
Figura 36.
Al insertar o actualizar una publicación al menos uno de los realizadores
tiene que ser miembro del grupo, si se incumple se mostraría un mensaje
en el formulario como el de laFigura 37.
Al insertar o actualizar un usuario se verifica que el nombre de usuario
sea válido, si se incumple esta restricción se mostraría un mensaje en el
formulario como el de laFigura 38.
Al insertar o actualizar un usuario se verifica que el nombre de usuario
sea único, si se incumple esta restricción se mostraría un mensaje en el
formulario como el de laFigura 39.
Capítulo 3: Interfaz de Usuario
~ 79 ~
Figura 36: Error de dependencias.
Figura 37: Error al insertar una Publicación.
Figura 38: Error de nombre de usuario incorrecto.
Figura 39: Error de nombre de usuario ya existente.
Capítulo 3: Interfaz de Usuario
~ 80 ~
3.5 Requerimientos del Software.
Se necesita de:
Un Servidor que tenga instalado Apache2, PHP5, MySQL 5.0.2 o superior,
módulo de conexión entre PHP y MySQL, modulos zlib y xml.
Computadora cliente que se conectará al servidor a través del protocolo
de conexión HTTP con un navegador, preferentemente Mozilla.
Ficheros necesarios para montar la base de datos, los permisos de
usuarios y la aplicación en el Servidor y ejecutar los pasos para la
instalación correctamente.
3.6 Pasos de Instalación.
Este software está diseñado para ejecutarse en sistemas Linux,
específicamente en Ubuntu; aunque también puede se puede en Windows ya
que MySQL y PHP son multiplataforma. Los pasos de instalación se mostrarán
para Ubuntu, aunque para Windows son similares.
1. Copiar los ficheros ncamdbir.sql y privilegios.sql para el escritorio.
2. Copiar la carpeta ncamdbir para el escritorio.
3. Abrir la terminal.
4. Movernos para el escritorio:
cd Escritorio
5. Copiar la carpeta ncamdbir para el lugar donde el servidor busca se los
sitios (var/www/):
cp -R ncamdbir /var/www/
6. Dar privilegio de ejecución a los ficheros:
chmod 777 -R /var/www/ncamdbir/
7. Para montar la base de datos se tiene el backup (ncamdbir.sql) y los
privilegios de usuario (privilegios.sql). Conectarse al mysql con usuario
y contraseña que tenga privilegios de crear tablas, vistas,
procedimientos almacenados, funciones, usuarios, etc, es decir
administrador (ej, root), ejecutando el comando:
Capítulo 3: Interfaz de Usuario
~ 81 ~
mysql --user=nombre_usuario --password=contraseña_usuario
8. Correr el script SQL que contiene el backup:
source /home/nombre_usuario_sistema/Escritorio/ncamdbir.sql;
9. Correr el script SQL que contiene los usuarios y sus privilegios:
source /home/nombre_usuario_sistema/Escritorio/privilegios.sql;
10. Cerrar la terminal.
11. Desde una máquina cliente abrir el navegador, preferentemente Mozilla.
12. Poner en la dirección del navegador
http://ip_maquina_servidor/ncamdbir.
13. Para que puedan conectarse como usuario con todos los privilegios, el
usuario es administrador y su contraseña es Asd 123456789
14. Para la gestión de los datos acceder al menú Administration y dentro de
él dar click en el vínculo Data Administration.
3.7 Conclusiones del Capítulo
Con este capítulo se documenta la interfaz de usuario con lo cual se brinda una
ayuda a los mismo sobre cómo trabajar con el sistema. Con este capítulo se
culmina el proceso de creación (análisis, diseño e implementación) del sistema
de aplicación de base de datos propuesto para resolver la necesidad del grupo
CAMD-BIR.
~ 82 ~
Conclusiones.
Conclusiones
~ 83 ~
Con el análisis de los requisitos realizado a partir de las entrevistas a los
usuarios se captaron todas las RI asociadas a los datos de los trabajos
científicos.
Se diseñó e implementó una BD que utiliza los recursos estándares del
SQL para elaborar un mecanismo de comprobación de RI que garantice
la integridad en la gestión del trabajo científico.
Se implementó una interfaz web amigable y sencilla para los clientes
teniendo en cuenta las RI, donde cada vez que se viole alguna
restricción se le informa al cliente a través de mensajes.
~ 84 ~
Recomendaciones.
Recomendaciones
~ 85 ~
Extender el proyecto a otros grupos de investigación que presenten
problemáticas similares a las del grupo CAMD-BIR.
Utilizar la automatización de las restricciones de integridad según se
utilizó en el desarrollo de aplicaciones de bases de datos.
Adicionar otras informaciones de los miembros como son las
expectativas y temas de interés.
~ 86 ~
Referencias
Bibliográficas.
Referencias Bibliográficas
~ 87 ~
ALONSO, A. P. 2010. Reglas de Negocio en Bases de Datos
Relacionales.
ÁLVAREZ, W., RODRÍGUEZ, A. & GARCÍA, C. 2006. ERECASE v.2.0
Una herramienta para el diseño conceptual de bases de datos con
validación estructural. Tesis de Grado, Universidad Central de Las Villas.
ARBOLÁEZ, S. G. 2011. Sistema Automatizado para la Gestión y Control
de Licencias Ambientales. Pregrado, Universidad Central Marta Abreu de
Las Villas.
AXMARK, D. & WIDENIUS, M. M. 2009. MySQL 5.0 Reference Manual.
CASTAGNETTO, J., RAWAT, H., SCHUMANN, S., SCOLLO, C. &
VELIATH, D. 1999 Professional PHP Programming, USA, Wrox Press.
CUEVAS, J. C. & FERNÁNDEZ, M. A. 2000. OCL (Object Constraint
Language).
CHAFFER, J. & SWEDBERG, K. 2011. Learning Jquery [Online].
Available: http://api.jquery.com [Accessed].
DATE, C. J. 2001. Introducción a los sistemas de bases de datos, México,
Pearson Educación.
ELMASRI, R. & NAVATHE, S. B. 2007. Fundamentals of DataBase
Systems.
GALLO, Y. R. 2011. Sistema Automatizado para el Control de Gestión
(GECAS) en la Empresa de Suministros y Transporte Agropecuario de
Sancti Spíritus. Universidad Central Marta Abreu de las Villas.
GENNICK, J. 2006. SQL pocket guide, O'Reilly Media.
JACKSON, D. 2011. Software Abstractions: Logic, Language, and Analysis
[Online]. Available: http://alloy.mit.edu [Accessed].
KEEKER, K. 2006. Calidad del contenido en el Diseño de sitios Web
atractivos.
MANDRAKE 2008. Revisión Rápida de PHP5 integrado con Zend.
MELTON, J. & SIMON, A. R. 2002. SQL1999: underestanding relational
languaje components, Morgab Kaufmann.
Referencias Bibliográficas
~ 88 ~
MICHAEL, B., JOHN, F., MARTIN, G. & GORM, L. P. 2011. Appendix E:
Alternative Approaches.
MORGAN, T. 2002. Business Rules and Information Systems: Aligning IT
with Business Goals. Addison Wesley.
MOTA, S. A. 2005. Bases de Datos Activas. Available:
http://www.bd.cesma.usb.ve/ci5311/sd05/apuntesParadigmasB.pdf.
MSDN 2008. MSDN LIBRARY VisualStudio 2008. Microsoft Corporation.
OLIVÉ, A. 2007. Conceptual Modeling of Information Systems, Catalonia,
Spain, Universitat Politècnica de Catalunya.
OPPEL, A. & SHELDON, R. 2008. SQL: a biginner's guide, McGraw-Hill
Profesional.
PÉREZ, J. E. 2009. CSS Avanzado.
SCHMULLER, J. 2000. Aprendiendo UML en 24 horas. México: Pearson
Educación.
TEAGUE, J. C. 2005. DHTML and CSS Advanced.
YUJING HE. 2006. Comparison of the Modeling Languages Alloy and
UML. Available:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.89.2147&rep=re
p1&type=pdf.
ZAKAS, N. C. 2005. web prog - Professional Javascript For Web
Developers, Indianapolis, Indiana, USA, Wiley Publishing,Inc.
~ 89 ~
Anexos.
Anexos
~ 90 ~
Anexo 1: Requisitos del sistema.
Requisitos de los datos
Las personas involucradas en los datos pueden ser usuarios, miembros
del grupo, colaboradores y asociados, de este últimos solo se tienen sus
datos personales.
Los datos personales que se desean almacenar son el nombre, los
apellidos, fecha nacimiento, país, e-mail y foto.
De los usuarios se desea llevar un control de las descargas que realizan
(lo que descargan y en la fecha en que se realizan).
Los documentos a descargar pueden ser software, bases de datos u otro
tipo.
Los datos generales que se desean sobre los documentos son el
documento digital, título, una descripción, tipo de documento y el nombre
que mostrará al descargarlo.
De las bases de datos se desean la cantidad de casos, la cantidad de
variables, descripción, nombre, requerimientos.
De los softwares se desea el nombre, la versión, requerimientos y
sistema operativo.
Mediante las publicaciones que tienen el identificador DOI, se pueda
acceder a un enlace exterior al sitio para su descarga.
Los miembros del grupo son el conjunto de las personas que son o han
sido miembros del grupo en algún momento.
De los miembros de desean sitio de trabajo, título académico, fecha de
comienzo en el grupo (en caso de ya no pertenecer al grupo la fecha en
que dejó de serlo), la categoría docente (asistente, instructor, etc.) y los
temas de investigación; además los miembros realizan publicaciones,
participan en eventos, imparten y reciben cursos, reciben honores,
cuentan con experiencias y participan en tesis como autores o tutores.
Anexos
~ 91 ~
Los colaboradores son personas que realizan colaboraciones al grupo,
ellos pueden ser categorizados como: nacionales, internacionales, de la
UCLV, etc. De los colaboradores se desean sus colaboraciones; además
las publicaciones, cursos, eventos y tesis que se relacionan con algún
miembro del grupo.
Los asociados son personas que no son ni miembros, ni colaboradores
pero están involucrados en los datos de los trabajos científicos del grupo.
De una publicación se desean los datos generales siguientes: el título,
año, resume, palabras claves, DOI, ISBN, ISSN, autor, coautores.
Las publicaciones pueden ser libros, artículos, conferencias, softwares y
otros.
De los libros se desean los datos generales de las publicaciones, la
editorial que lo publica y la cantidad de páginas que presenta.
La editorial tiene un nombre y un país.
Los artículos se publican en un número y volumen de una revista, donde
tiene una página inicial, una final y un total de páginas.
De las conferencias además de los datos generales de una publicación
tiene una cantidad total de páginas.
De los softwares se desea su versión y requerimientos.
De las publicaciones que no son libros, conferencias, artículos y softwa re
solo se almacenan los datos generales.
Los cursos son impartidos y recibidos por personas, tienen un
identificador y una descripción, se realizan en un lugar en una fecha (año
y semestre), se clasifican en: postgrado, adiestramientos, cursos de
entrenamiento, etc.
Los eventos tienen un nombre, una fecha, DOI, ISBN, ISSN, presentan
una relevancia (nacional, internacional, UCLV, etc.), se realizan en un
lugar en una fecha y se les puede especificar una descripción.
En los eventos las personas que participan pueden o no ser ponentes.
En el caso de que lo sean pueden presentar una o varias ponencias.
Anexos
~ 92 ~
De una ponencia se desea el título, paginas, resumen, el evento, los
premios y las personas que lo presentan.
Las experiencias laborales de los miembros del grupo tienen una
descripción, se reciben en un lugar con una fecha de inicio y una fecha
de culminación.
De las tesis se desean los realizadores, tutores, título, resumen, fecha de
exposición y el tipo de tesis (pregrado, maestría, etc.).
Los lugares tienen un nombre, país, ciudad y estado (o provincia)
Requisitos de la aplicación
La galería mostrará imágenes relacionadas con el grupo agrupadas en
álbumes.
De cada álbum se necesita su nombre, descripción, fotos y el orden que
presenta este álbum respecto a otro y de
A cada foto se le puede especificar una descripción.
Las noticias son informaciones importantes que quiere mostrar el grupo
por lo que de ellas se necesita un título, texto inicial y en texto secundario
que se desplegaría cuando se quiera leer más sobre ella, además se
necesita la fecha en que se publica la noticia.
De los usuarios se desean sus datos personales, usuario, contraseña,
palabras claves, configuraciones del sitio y los privilegios de usuario.
Todos los usuarios pueden consultar la información no restringida
(información restringida: contraseñas, datos de configuración de otros
usuarios, etc.).
Los usuarios tienen distintos privilegios para poder administrar los datos
de la base de datos.
Los usuarios que son miembros actuales del grupo pueden administrar
su información personal y sus datos científicos.
De los comentarios se desea el comentario, el usuario que lo realiza y la
fecha.
Anexos
~ 93 ~
Anexo 2:Restricciones de Integridad en Lenguaje Natural.
Identificador Restricción
R1 El e-mail de una persona tiene que estar bien formado, es decir
cumplir con la expresión regular siguiente:
[\w\.\d]+@( ([\w\d])+\.){1,5}([\w\d])+
R2 El nombre de usuario tiene que cumplir con la expresión
regular siguiente: [a-z]*[a-z0-9_\.]*){3,30}
R3 Las personas involucradas en los datos científicos son
miembros, colaboradores o asociados, pero no dos a la vez.
R4 La edad de los miembros colaboradores y asociados tiene que
ser mayor o igual a 17.
R5 Las publicaciones tienen que tener al menos un realizador
(que sería el autor).
R6 Las tesis tienen que tener al menos un estudiante.
R7 Las tesis tienen que tener al menos un tutor.
R8 No puede existir una persona que imparta y reciba el mismo
curso.
R9 No puede existir una persona que sea autor y coautor de una
misma publicación.
R10 No puede existir una persona que sea autor y tutor de la
misma tesis.
R11 Al menos uno de los realizadores (autor + coautores) de una
publicación tiene que ser miembro.
R12 Al menos una de las personas (imparten + reciben) de un
curso tiene que ser miembro.
Anexos
~ 94 ~
R13 Al menos una de las personas (autores + tutores) de una tesis
tiene que ser miembro.
R14 Si a un miembro del grupo se le da baja la fecha de la baja
tiene que ser mayor a la fecha de inicio.
R15 En las experiencias laborales, la fecha de inicio tiene que ser
menor que la fecha fin.
R16 En una experiencia la fecha de inicio tiene que menores o
iguales a la fecha actual.
R17 En una experiencia si las fechas de fin existen entonces tiene
que ser menor o igual a la fecha actual.
R18 Las publicaciones que tienen DOI, este las identifica
unívocamente.
R19 Los eventos que tienen DOI, este los identifica unívocamente.
R20 Un artículo no puede presentarse en dos o más revistas.
R21 Un libro no puede ser editado en dos o más editoriales.
R22 La versión de un software no puede disminuir.
R23 Todos los miembros investigan al menos en un tema.
R24 Al menos un usuario tiene que tener privilegio de
administración usuarios.
R25 Al menos un usuario tiene que tener privilegio de
administración de datos de la aplicación.
R27 Al menos un usuario tiene que tener privilegio de
administración de datos científicos.
Anexos
~ 95 ~
Anexo 3: Esquema Entidad /Relación
Anexo 3.1: Sub-esquema de Personas
Anexo 3.2: Sub-esquema de Publicaciones
Anexos
~ 96 ~
Anexo 3.3: Sub-esquema de Cursos
Anexo 3.4: Sub-esquema de Eventos
Anexos
~ 97 ~
Anexo 3.5: Sub-esquema de Tesis
Anexo 3.6: Sub-esquema de Ficheros para Descargas
Anexo 3.7: Sub-esquema de Aplicación
Anexos
~ 98 ~
Anexo 4: Script SQL para implementar las RI complejas en MySQL.
CREATE TABLE `a_ri` (
`codigo` int(11) NOT NULL,
`status` int(11) NOT NULL DEFAULT '0',
`mensage` varchar(200) NOT NULL,
`orden` int(11) NOT NULL DEFAULT '0',
`procedimiento` varchar(50) DEFAULT NULL,
PRIMARY KEY (`codigo`) USING BTREE,
KEY `i_status` (`status`),
KEY `i_orden` (`orden`),
KEY `i_codigo` (`codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `a_riid` (
`idpinteger` int(11) NOT NULL DEFAULT '0',
`idpvarchar` varchar(50) NOT NULL DEFAULT '',
`idsinteger` int(11) NOT NULL DEFAULT '0',
`idsvarchar` varchar(50) NOT NULL DEFAULT '',
`idcodigo` int(11) NOT NULL,
PRIMARY KEY
(`idpinteger`,`idpvarchar`,`idsinteger`,`idsvarchar`,`idcod
igo`) USING BTREE,
KEY `fk_riid_codigo` (`idcodigo`),
CONSTRAINT `fk_riid_codigo` FOREIGN KEY (`idcodigo`)
REFERENCES `a_ri` (`codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE PROCEDURE `a_ri_addconsultar`(codigo INTEGER, idpint
INTEGER, idpvar VARCHAR(50) CHARSET utf8, idsint INTEGER,
idsvar VARCHAR(50) CHARSET utf8)
Anexos
~ 99 ~
BEGIN
DECLARE tpi INTEGER DEFAULT idpint;
DECLARE tsi INTEGER DEFAULT idsint;
DECLARE tpsVARCHAR(50) CHARSET utf8DEFAULT idpvar;
DECLARE tssVARCHAR(50) CHARSET utf8DEFAULT idsvar;
IF (codigo> 1000) THEN
IF (idpvar IS NULL) THEN
SET tps = '';
ELSE
SET tpi = 0;
END IF;
IF (idsvar IS NULL) THEN
SET tss = '';
END IF;
IF (idsint IS NULL) THEN
SET tsi = 0;
END IF;
INSERT INTO a_riid (`idcodigo`,`idpinteger`, `idpvarchar`,
`idsinteger`, `idsvarchar`) VALUES
(codigo,tpi,tps,tsi,tss);
CALL a_ri_consultar(codigo);
END IF;
END;
CREATE PROCEDURE `a_ri_consultar`(cod INTEGER)
BEGIN
DECLARE tmp INTEGER DEFAULT 0;
SET tmp = (SELECT `orden` FROM `a_ri` ORDER BY `orden` DESC
LIMIT 1) + 1;
UPDATE `a_ri` SET `status`=1,`orden`=tmp WHERE
`codigo`=cod;
Anexos
~ 100 ~
END
CREATE PROCEDURE `a_ri_clean`()
BEGIN
UPDATE a_ri SET status=0, orden=0;
TRUNCATE a_riid;
END;
CREATE PROCEDURE `a_ri_executeconsultar`()
BEGIN
DECLARE tcantidad INTEGER DEFAULT 0;
DECLARE tcomprobar INTEGER DEFAULT 0;
DECLARE tprocedimientoVARCHAR(100) CHARSET utf8;
SET tcantidad = (SELECT count(*) FROM a_ri WHERE status =
1);
WHILE tcantidad> 0 DO
SELECT status, procedimiento INTO tcomprobar,
tprocedimiento FROM a_ri WHERE status <> 0 ORDER BY status
DESC, orden ASC LIMIT 1;
IF tcomprobar = 2 THEN
SET tcantidad = 0;
ELSE
SET @ejecutarproc = CONCAT('CALL ',tprocedimiento,'()');
PREPARE s FROM @ejecutarproc;
EXECUTE s;
DROP PREPARE s;
SET tcantidad = tcantidad - 1;
END IF;
END WHILE;
END;