DISEÑO DE PROTOTIPO DE CONTROL DE ASISTENCIA PARA EL COLEGIO NUESTRA SEÑORA DE GUADALUPE JORGE LUIS ORREGO GARCÍA FABIÁN STEVENS TORRES FORERO

Transcripción

1 DISEÑO DE PROTOTIPO DE CONTROL DE ASISTENCIA PARA EL COLEGIO NUESTRA SEÑORA DE GUADALUPE JORGE LUIS ORREGO GARCÍA FABIÁN STEVENS TORRES FORERO UNIVERSIDAD CATÓLICA DE PEREIRA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES PEREIRA

2 DISEÑO DE PROTOTIPO DE CONTROL DE ASISTENCIA PARA EL COLEGIO NUESTRA SEÑORA DE GUADALUPE JORGE LUIS ORREGO GARCÍA FABIÁN STEVENS TORRES FORERO Documento presentado en la Asignatura de Proyecto de Grado como nota final al Ingeniero Andrés Vargas García UNIVERSIDAD CATÓLICA DE PEREIRA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES PEREIRA

3 NOTA DE ACEPTACIÓN Firma del Presidente del Jurado Firma del Jurado Firma del Jurado Pereira, mayo de

4 DECLARACIÓN DE DERECHOS DEL AUTOR Los autores del diseño de prototipo de control de asistencia para el Colegio Nuestra Señora de Guadalupe, se autoriza su libre utilización, mencionando explícitamente la fuente así como el nombre de los autores únicamente con fines no comerciales. Por lo anterior este Software puede ser modificado o complementado. 4

5 AGRADECIMIENTOS Agradecemos especialmente a nuestro asesor el Ingeniero ANDRÉS VARGAS GARCÍA por su apoyo y su dedicación hacia nosotros, pudimos lograr nuestros objetivos. A la Institución Educativa NUESTRA SEÑORA DE GUADALUPE, por su colaboración y especial atención al dar respuesta a todos nuestros interrogantes. A la UNIVERSIDAD CATÓLICA DE PEREIRA por ser la institución que nos formó como profesionales dispuestos a servirle a la comunidad, comprometidos con el bien común y actuar siempre en conformidad con los valores de justicia, equidad, honestidad, libertad, solidaridad, verdad y responsabilidad; manifestando rectitud y compromiso con el bien. 5

6 DEDICATORIA A Dios y mi familia por su amor, motivación y apoyo incondicional los cuales han sido ejemplares. Jorge Luis Orrego García Dedico este proyecto de grado a mi familia, en especial a mi mamá, con su paciencia e incondicional apoyo. A mi tía Lilia que siempre ha creído en mí. Al asesor Andrés Vargas, este trabajo también es gracias a él Fabián Stevens Torres Forero 6

7 RESUMEN Teniendo en cuenta las necesidades de la Institución Educativa respecto al control de asistencia, el grupo ha desarrollado un proyecto el cual sistematiza este proceso, usando como identificador un lector de código de barras, pues ofrece beneficios en su rapidez de utilización y es económico para adquirir; también mediante el software creado, los directivos de la Institución podrán establecer la fecha y hora exacta en la que un estudiante llega a la institución o si presenta inasistencias, otorgándole información al interesado, en este caso el coordinador disciplinario. La aplicación ha sido desarrollada teniendo en cuenta la ingeniería de software que es necesaria para la programación y documentación; se ha escogido la metodología Métrica V3, que es una guía aceptada internacionalmente. Descriptores Ingeniería del software, control de asistencia, código de barras, JAVA, dispositivos de identificación, MySQL, métrica V3, base de datos. 7

8 ABSTRACT This paper summarizes the process of adopting technology-supported attendance control service in Nuestra Señora de Guadalupe School making easer the attendance monitoring. The team has been developing an attendance control system that was implemented using networked technology (barcode scanner) this system offers many benefits including maneuverability, economy, installation ease, and versatility. The Software Generates a single student report showing, student name, days present, days absent, days tardy. Summary shows total attendance and attendance percentages. Vice principal usually has oversight in monitoring student attendance, so the system permit to maintain a daily record of a student s arrival and departure time from school, helping to improved school attendance and punctuality. This app has been developed using software engineering an important tool in the practices to the creation, operation, and maintenance of software systems applying metrica v3 methodology an international standard guide. Descriptors Engineering software, bar code, JAVA, identification devices, MySQL, metrica V3, attendance control, database. 8

9 CONTENIDO pág. INTRODUCCIÓN PLANTEAMIENTO DEL PROBLEMA DESCRIPCIÓN DEL PROBLEMA FORMULACIÓN DEL PROBLEMA JUSTIFICACIÓN OBJETIVO OBJETIVO GENERAL OBJETIVOS ESPECÍFICOS MARCO REFERENCIAL MARCO TEÓRICO Bases De Datos Relacionales Definición de Sistema Gestor de Base de Datos El proceso de diseño de una base de datos Lenguaje SQL MySQL Qué es Open Source? Ciclo de Vida del Software Proceso del Software Tecnología orientada a objetos Java Biometría Dispositivos biométricos MARCO CONCEPTUAL TCP/IP USB Telnet FSF Localhost Cable UTP MARCO CONTEXTUAL Reseña histórica de la Institución Educativa Nuestra Señora de Guadalupe Institución Educativa Nuestra Señora de Guadalupe Misión Institución Educativa Nuestra Señora de Guadalupe Visión Institución Educativa Nuestra Señora de Guadalupe Software Similar MARCO LEGAL 52 9

10 4.4.1 Manual de Convivencia Institución Educativa Nuestra Señora de Guadalupe Ley del Habeas Data Licencias ESTUDIO TÉCNICO/METODOLOGÍA El modelo de ciclo de vida en Cascada Metodología Métrica v DESARROLLO DE SISTEMAS DE INFORMACIÓN ESTUDIO DE VIABILIDAD DEL SISTEMA Estudio de la Solicitud Identificación del Alcance del Sistema ANÁLISIS DEL SISTEMA DE INFORMACIÓN Determinación del Alcance del Sistema Identificación del Entorno Tecnológico Especificación de Estándares y Normas Especificación de Casos de Uso Diagrama de paquetes Diagramas de Interacción de Objetos Especificación de Formatos Individuales de la Interfaz de Pantalla DISEÑO SISTEMA DE INFORMACIÓN Definición de Niveles de Arquitectura Código de Clases Código Base de Datos Especificación Técnica del Plan de Pruebas CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN Generación del Código de los Componentes Ejecución De Las Pruebas Elaboración de los Manuales de Usuario CONCLUSIONES 135 BIBLIOGRAFÍA 136 ANEXOS

11 LISTA DE FIGURAS pág. Figura 1. Macro procesos de la metodología métrica V3. 58 Figura 2. Estructura Organizativa de la Institución Educativa Nuestra Señora de Guadalupe. 62 Figura 3. Diagrama de caso de usos. 66 Figura 4. Clases 67 Figura 5. MySQL Server 68 Figura 6 Diagrama de paquetes 77 Figura 7. Clases En Paquete Matricula 78 Figura 8. Clases en Paquete Reglas 79 Figura 9. Clases en Paquete Asistencia 80 Figura 10. Clases En Paquete Entrada 81 Figura 11. Clases en Paquete Consultas 82 Figura 12. Clases en Paquete Hora 83 Figura 13. Diagrama de secuencia crear nuevo estudiante 84 Figura 14. Diagrama de secuencia captura entrada estudiante. 85 Figura 15. Diagrama de secuencia modificar registro estudiante. 86 Figura 16. Diagrama de secuencia configurar hora 87 Figura 17. Diagrama de secuencia guardar falta estudiante. 88 Figura 18. Diagrama de secuencia consultar faltas estudiante. 89 Figura 19. Diagrama de colaboración crear nuevo estudiante. 90 Figura 20. Diagrama de colaboración capturar entrada estudiante. 90 Figura 21. Diagrama de colaboración modificar registro estudiante. 91 Figura 22. Diagrama de colaboración configurar hora. 91 Figura 23. Diagrama de colaboración guardar falta estudiante. 92 Figura 24. Diagrama de colaboración consultar faltas estudiante 92 Figura 25. Interfaz Módulo Entrada 93 Figura 26. Interfaz Pantalla Principal Módulo Coordinador 94 Figura 27. Menú Acciones del Módulo Coordinador 94 Figura 28. Interfaz Matricula 95 Figura 29. Interfaz Configurar Hora 96 Figura 30. Opciones del Menú Consultas-Retardo 96 Figura 31. Interfaz estudiantes que llegaron tarde en el día. 97 Figura 32. Interfaz lista de retardos por semana. 98 Figura 33. Interfaz estudiantes que llegaron tarde en el periodo. 99 Figura 34. Interfaz Opciones del Menú Consultas-Inasistencias 100 Figura 35. Interfaz Estudiantes Que No Asistieron A La Institución 100 Figura 36. Interfaz estudiantes que presentan Inasistencia en la semana. 101 Figura 37. Interfaz estudiantes que presentan Inasistencia en el periodo. 102 Figura 38. Interfaz Ingresar motivo de Inasistencia. 103 Figura 39. Interfaz ingresar motivo de retardo. 104 Figura 40. Menú faltas del Módulo Coordinador

12 Figura 41. Interfaz estudiantes que requieren llamado de atención 105 Figura 42. Interfaz estudiantes que requieren firmar compromiso. 106 Figura 43. Interfaz estudiantes que requieren llamado de Acudiente. 107 Figura 44 Menú Ayuda 108 Figura 45 Interfaz Acerca De 108 Figura 46. Diagrama de navegación por niveles 109 Figura 47. Arquitectura del sistema 110 Figura 48. Modelo Relacional

13 LISTA DE TABLAS pág. Tabla 1. Estudio de la solicitud 61 Tabla 2. Catálogo de requisitos: Sistematizar el Control de Asistencia. 63 Tabla 3. Catálogo de requisitos: Ingresar los datos del estudiante a la Base de Datos. 63 Tabla 4. Catálogo de requisitos: Reporte de inasistencias. 64 Tabla 5. Catálogo de requisitos: Reporte de retardo de los estudiantes. 64 Tabla 6. Catálogo de requisitos: Modificar registro de estudiantes. 64 Tabla 7. Catálogo de requisitos: Eliminar registro de estudiantes. 65 Tabla 8. Catálogo de requisitos: Dispositivo para validar la asistencia de los estudiantes al plantel. 65 Tabla 9. Catálogo de requisitos: Arquitectura tecnológica que soporte el dispositivo de identificación. 65 Tabla 10. Especificación de casos de uso: Actor Administrador 69 Tabla 11. Especificación de casos de uso: Actor dispositivo de identificación. 70 Tabla 12. Especificación de casos de uso: Actor base de Datos. 70 Tabla 13. Especificación de casos de uso: Actor Estudiante 70 Tabla 14. Especificación de casos de uso: crear nuevo estudiante. 71 Tabla 15. Especificación de casos de uso: capturar entrada estudiante. 72 Tabla 16. Especificación de casos de uso: modificar registro. 73 Tabla 17. Especificación de casos de uso: configurar hora 74 Tabla 18. Especificación de casos de uso: guardar falta estudiante. 75 Tabla 19. Especificación de casos de uso consultar faltas 76 Tabla 20. Especificación de casos de uso Salir del sistema 77 Tabla 21. Diseño Prueba Formulario Matricula 114 Tabla 22. Diseño Prueba Formulario Configurar Hora 115 Tabla 23. Diseño Prueba Formulario Control Retardos 116 Tabla 24. Diseño Prueba Formulario Control Inasistencia. 117 Tabla 25. Diseño Prueba Formulario Capturas

14 LISTA DE ANEXOS pág. Anexo A. Métrica v3 Desarrollo del sistema de información 139 Métrica v3 Estudio de Viabilidad Del Sistema (EVS) 139 Métrica v3 Análisis Del Sistema De Información (ASI) 139 Métrica v3 Diseño Del Sistema De Información (DSI) 139 Métrica v3 Construcción Del Sistema De Información (CSI) 139 Métrica v3 Implantación Aceptación Del Sistema (IAS) 139 Anexo B. Código de Barras 139 Anexo C. Código de las Clases 139 Anexo D. Generación del código de Componentes 139 Anexo E. Tablas pruebas 139 Anexo F. Valoración software 139 Anexo G. Entrega y aprobación software 139 Anexo H. Manual de instalación

15 0. INTRODUCCIÓN Las instituciones educativas, las empresas del sector público y privado se ven en la necesidad de implementar sistemas que controlen el ingreso del personal, los visitantes y tener un registro del cumplimiento del horario de sus empleados, pero desafortunadamente en las instituciones indagadas las llevan de forma manual, es por eso que se debe aprovechar las tecnologías de la información y la comunicación que están alcanzado un dinamismo y formando un fenómeno social de gran trascendencia que está transformado la vida, donde se ha reconocido que su impacto dista de sus potencialidades y está penetrado en las escuelas, las universidades y las empresas con procesos de incorporación en primera instancia. En consecuencia surge la idea de crear un sistema computarizado que verifique e ingrese los datos, con el cual se podrá obtener posteriormente la información que se necesite (si se está cumpliendo el horario, o ver las inasistencias) sobre cualquier empleado o estudiante con una simple búsqueda, así no se tendrá un período muy largo para ingresar los datos del personal y se evitará la demora para buscar los registros que están incumpliendo con el horario establecido, como lo indica el Coordinador Disciplinario de la jornada de la mañana. 15

16 1.1 DESCRIPCIÓN DEL PROBLEMA 1. PLANTEAMIENTO DEL PROBLEMA Para los colegios es de suma importancia llevar un registro donde se muestre la asistencia de un alumno. Sin embargo algunos colegios no han logrado sistematizar este sistema. Se detectó en el caso particular, que el colegio Nuestra Señora de Guadalupe, ubicado en Dosquebradas Risaralda tiene este problema. La institución educativa en estos momentos tiene como control de asistencia una carpeta donde está el listado de todos los estudiantes del colegio, en ella está la información concerniente al alumno, el nombre, el grado y están los doce meses del año. En los salones no existe por parte de los maestros una revisión de qué estudiantes faltaron, excepto para sus notas académicas, es decir el listado que ellos llevan no tiene nada que ver con el listado que tiene el Coordinador. Lo que se hace es que el Coordinador a cierta hora de la jornada estudiantil emprende la tarea de llevar el registro. Entonces lleva la carpeta consigo y se va a cada salón donde los alumnos de la clase informan que compañeros faltaron, lo que implica obsolescencia evidente y de no tener certeza si los datos son correctos, pues los alumnos no pueden afirmar quien entre 30 ó 40 no está; lo siguiente que hace el Coordinador es poner un punto negro al nombre de la persona que faltó (con tres faltas se llamará al acudiente). Ese mismo procedimiento se debe realizar a todos los grados que van desde 6º bachillerato hasta 11º, cada grado con 2 grupos. La dificultad con este procedimiento es que quita tiempo para desempeñar otras labores, como el mismo Coordinador y docentes de la institución aseveran, el tiempo en promedio según los Directivos es entre 1 a 2 horas. Básicamente el problema es el tiempo y la ausencia de un procedimiento que solucione este inconveniente de forma efectiva. Por ejemplo para tener un registro general de los alumnos que faltaron a lo largo de un bimestre con el medio actual es muy complejo, ya que tendrían que buscar en los documentos y contar las inasistencias de forma manual. 1.2 FORMULACIÓN DEL PROBLEMA Implementar un sistema que controle la entrada de estudiantes, con unos terminales de captura de datos, al colegio Nuestra Señora de Guadalupe, que se encuentra ubicado en Dosquebradas Risaralda, permitirá tener un control de asistencia adecuado? 16

17 2. JUSTIFICACIÓN La idea consiste básicamente en implementar un sistema que controle la entrada de estudiantes, con unos terminales de captura de datos, al colegio Nuestra Señora de Guadalupe, que se encuentra ubicado en Dosquebradas Risaralda. Los terminales de captura de datos junto a la base de datos y software a desarrollar permitirán gestionar el control de la asistencia de los estudiantes en un área determinada. En este centro de formación serán utilizados para detectar las faltas o retardos y poder actuar en consecuencia de manera rápida. Este sistema guarda un registro del histórico de accesos (con información del estudiante, hora y día del acceso, etc.). La autenticación de cada usuario puede realizarse mediante tecnología biométrica de huella dactilar, proximidad, tarjeta inteligente, banda magnética, o código de barras. 17

18 3. OBJETIVO 3.1 OBJETIVO GENERAL Diseñar un sistema de control de asistencia por medio de un sistema de identificación para estudiantes del colegio Nuestra Señora De Guadalupe. 3.2 OBJETIVOS ESPECÍFICOS Levantar información relacionada con los procesos del control de asistencia. Establecer la tecnología que permita identificar a los estudiantes de forma sistematizada. Elegir el ciclo de vida del software que se ajuste al proyecto. Seleccionar el sistema gestor de base de datos para el control de asistencia. Aplicar la Ingeniería del software para el desarrollo de la aplicación. 18

19 4. MARCO REFERENCIAL 4.1 MARCO TEÓRICO Bases De Datos Relacionales. Al definir el modelo relacional se distingue dos conceptos. El primero hace referencia a la relación como elemento constructivo de la Teoría Relacional, que se corresponde con la idea de tabla o entidad. El segundo se aplica a la relación (asociación) entre dos tablas. Al existir siempre relaciones entre campos, no puede distinguirse cuando un campo es de una tabla o de otra, por lo que emplea indistintamente ambos conceptos, a los que posteriormente añade los conceptos de clave primaria y ajena, de modo que sean distinguibles las tablas y los campos que pertenecen a cada una de ellas. El concepto interrelación conserva la relación para expresar el contenedor de relaciones (tabla), se denomina tupla a los elementos (registros) que forman las relaciones (tabla) y cada tupla está formada por diversos dominios (campos). Las ventajas del modelo relacional son la independencia de datos, en cuanto independencia de las aplicaciones y del dispositivo de almacenamiento (no importa si crece mucho o poco la base de datos) y la eliminación de la inconsistencia de los datos. Además, el modelo relacional permite describir los datos empleando estructuras naturales, sin adiciones debidas al lenguaje, representación de datos o máquina que los procese. Otra ventaja es la posibilidad de emplear programas de alto nivel que maximicen el rendimiento de la independencia entre programas, su representación de los mismos en lenguaje máquina y la organización de los datos. Quizás, el problema fundamental que suele plantearse al realizar una base de datos real, formada por varias tablas, es la repetición de datos, es decir, campos repetidos en diferentes tablas (redundancia), lo cual va a dificultar su gestión, es decir, la actualización, inserción, modificación, eliminación, consulta, etc. Para resolver estos problemas es necesario que exista integración entre las distintas tablas y que esté controlada la repetición de datos. Así surgen los llamados Sistemas de gestión de Bases de Datos relacionales (SGBD) que están concebidos como un grupo de programas de propósito general que permiten controlar el acceso y la utilización de las bases de datos de forma que satisfagan las necesidades del usuario (programas de usuario) y que actúen con independencia de los datos, y con ellos las llamadas Bases de Datos Relacionales que pueden resolver, mejor que en otras organizaciones, las dificultades de redundancia y no integración de los datos. En este tipo de datos se suprimen las jerarquías entre campos, pudiéndose utilizar cualquiera de ellos como clave de acceso. 19

20 Características de las Bases de Datos Relacionales Para que la estructura de las tablas cumpla las leyes de la teoría relacional deben satisfacerse las siguientes condiciones: Todos los registros de la tabla deben tener el mismo número de campos, aunque alguno de ellos este vacío, deben ser registros de longitud fija. Cada campo tiene un nombre o etiqueta que hay que definir previamente a su utilización. No obstante, una vez creado el fichero se podrá ampliar o disminuir el número de campos, mediante el Sistema Gestor de la Base de Datos. La base de datos estará formada por muchas tablas, una por cada tipo de registro. Los registros de una misma tabla tienen que diferenciarse, al menos, en el contenido de alguno de sus campos, no puede haber dos registros idénticos, los registros de una tabla pueden estar dispuestos en cualquier orden. El contenido de cada campo está delimitado por un rango de valores posibles, permite la creación de nuevas tablas a partir de las ya existentes, relacionando campos de distintas tablas anteriores. Esta condición es la esencia de las bases de datos relacionales, formando lo que se llama un fichero virtual. (Date, 2001) Definición de Sistema Gestor de Base de Datos. De un modo simplificado, un SGBD es una plataforma de software que almacena los datos que se le introduzcan, debiendo garantizar principalmente su disponibilidad, su seguridad y su integridad. Esto significa que es un conjunto de programas que permiten el almacenamiento de información, velando porque se pueda disponer de ella en cualquier momento, que la información sea correcta desde un punto de vista lógico y que sólo pueda ser accedida por las personas adecuadas. Y de un modo más directo, el Sistema Gestor de la Base de Datos es el guardián de los datos de la empresa. Ni más ni menos. De ahí que sea trascendental su correcta elección. El SQL (Structured Query Language), proveniente del SE-QUEL (Structured English Query Language). Este último fue desarrollado durante la década de los 70 e implementado experimentalmente, ya que las máquinas comerciales de la época no tenían la suficiente potencia de cálculo como para ejecutar con rendimiento aceptable las operaciones del lenguaje. El lenguaje SQL se divide en tres sublenguajes: Lenguaje de definición de datos (DDL), que permite crear y alterar las estructuras en las que la información se almacena. Lenguaje de manipulación de datos (DML), que permite insertar, modificar, consultar y eliminar contenidos de la base de datos. 20

21 Lenguaje de control de datos (DCL), que gestiona el acceso a los datos desde el punto de vista de la seguridad (usuarios), como desde el punto de vista de la integridad (concurrencia) El proceso de diseño de una base de datos. El problema de diseñar bases de datos consiste en diseñar la estructura lógica y física de una o más bases de datos para atender las necesidades de información de los usuarios de un conjunto definido de aplicaciones. Estos usuarios pueden pertenecer todos a una organización concreta (como sucede con los trabajadores de una empresa o los funcionarios de un organismo público), o bien formar parte de un colectivo con intereses comunes (tal es el caso de los usuarios de multitud de aplicaciones web, desde un buscador como Google hasta un servicio de información geográfica tipo Páginas Amarillas). Hay que recordar que el diseño de bases de datos es sólo uno de los procesos involucrados en la construcción de un sistema de información. Generalmente, para construir un sistema de información se llevarán a cabo distintas actividades paralelas: Por un lado, será necesario diseñar el contenido y la estructura de la base de datos que dará soporte al sistema de información. Por otro, también será imprescindible diseñar el conjunto de aplicaciones que le permitirán al usuario sacar partido del sistema de información. Tanto en las actividades relacionadas con los datos del sistema (todo lo relativo a la base de datos) como en aquéllas relacionadas con los procesos del mundo real que el sistema trata de mejorar (mediante un conjunto de aplicaciones), resulta recomendable el uso de una metodología apropiada. En esencia, la metodología utilizada en un proyecto no es más que el conjunto de convenciones que los integrantes de un equipo de trabajo acuerden emplear. Sin embargo, por metodología usualmente se entiende algo más. Si se acude a un diccionario, se encuentra que una metodología es un conjunto de métodos, aplicados de forma sistemática. Una buena metodología de diseño ha de incluir todo lo que normalmente resulte necesario para obtener un buen diseño. Generalmente, una metodología, que implicará el uso de métodos y técnicas adecuadas a nuestro problema, se centrará en la coordinación de las actividades que han de realizarse. De acuerdo con las etapas del ciclo de vida de un sistema de información, una metodología de diseño descompone el proceso de diseño en una serie de etapas. Para cada una de las etapas, propondrá el uso de determinadas técnicas y herramientas de diseño, así como la generación de una serie de documentos que facilitarán la transición de una etapa a la siguiente. (Berzal, 2010) 21

22 4.1.4 Lenguaje SQL. SQL es un lenguaje estructurado de interrogación y administración de bases de datos relacionales. Numerosas firmas comerciales han introducido en el mercado productos de bases de datos relacionales orientados al SQL, entre ellos Transact-SQL, que es el lenguaje de SQL Server 2000 y de Microsoft Yet, que es el lenguaje SQL de Microsoft Access. Ambos lenguajes pueden utilizarse para el desarrollo de aplicaciones Web junto con el lenguaje SQL de MySQL. No obstante, el Instituto de Normalización Americano ANSI (American National Standards Institute) ha establecido una normativa oficial para la estandarización de los distintos lenguajes SQL. Esta normalización ha permitido que la mayoría de los productos actuales de bases de datos relacionales acepten un lenguaje SQL prácticamente único. Cuando se necesita recuperar datos de la base de datos, se utiliza el lenguaje SQL para efectuar la petición. El sistema gestor de base de datos procesa la petición SQL, recupera los datos solicitados de la base de datos y los devuelve. Este proceso de solicitar datos y de recibir los resultados se denomina consulta (Query) a la base de datos; de ahí el nombre Structured Query Language. Pero SQL no es solo un lenguaje de consulta. Se trata de un lenguaje completo de control e interacción con un sistema de gestión de base de datos. A pesar de la impresión de su nombre, SQL ha emergido con el lenguaje estándar para la utilización de bases de datos relacionales. SQL es a la vez un potente lenguaje estructurado y un lenguaje relativamente fácil de aprender. El nombre Structured Query Language es realmente y en cierta medida inapropiado. En primer lugar, SQL es mucho más que una herramienta de consulta, aunque ese fue su propósito original y recuperar datos sigue siendo una de sus funciones más importantes. SQL se utiliza para controlar todas las funciones que un SGDB proporciona a sus usuarios, incluyendo: Definición de datos: SQL permite a un usuario definir la estructura y organización de los datos almacenados y de las relaciones entre ellos. Recuperación de datos: SQL permite a un usuario o a un programa de aplicación recuperar los datos almacenados de la base a utilizar. Manipulación de datos: SQL permite a un usuario o a un programa de aplicación actualizar la base de datos añadiendo nuevos datos, suprimiendo datos antiguos y modificando datos previamente almacenados. Control de acceso: SQL puede ser utilizado para restringir la capacidad de un usuario para recuperar, añadir y modificar datos, protegiendo así los datos almacenados frente a accesos no autorizados. (Perez, 2004) 22

23 Es un lenguaje que permite a los usuarios realizar consultas de modo interactivo, ya que fue desarrollado como lenguaje de usuario final, aunque en la actualidad las herramientas visuales de desarrollo permiten interrogar a una base de datos sin necesidad de conocer el lenguaje SQL. Puede emplearse como lenguaje de programación de bases de datos, incrustado en otros lenguajes o directamente mediante su empleo como lenguaje de programación PL/SQL de Oracle o Transact-SQL, aunque necesite complementarse con otros, al menos para el desarrollo de las interfaces de usuario, la gestión de entrada/salida y de dispositivos. El hecho de poseer gestión de transacciones, de integridad, seguridad y validación de datos facilita la protección de los mismos en redes, tanto Intranet como Extranet. (Date, 2001) En un principio, SQL fue diseñado para ser específicamente un "sub-lenguaje de datos". Sin embargo, con la incorporación en 1996 de la característica de PSM (Módulos Almacenados Persistentes) al estándar, SQL se convirtió, en términos computacionales, en un lenguaje completo (ahora incluye instrucciones como CALL, RETURN, SET, CASE. IF, LOOP, LEAVE, WHILE y REPEAT, así como diversas características relacionadas como las variables y los manejadores de excepciones). Hay necesidad de combinar SQL con algún lenguaje "anfitrión" distinto para desarrollar una aplicación completa. SQL incluye operaciones tanto de definición como de manipulación de datos. Se considerará primero las operaciones de definición. La definición incluye una instrucción CREATE TABLE para cada una de las tres tablas base. Cada una de estas instrucciones CREATE TABLE especifica el nombre de la tabla base que va a ser creada, los nombres y tipos de datos de las columnas de la tabla y las claves primaria y externa de esa tabla. Surgen un par de cuestiones de sintaxis: A menudo se utiliza el carácter "#" (por ejemplo) en nombres de columnas, aunque de hecho ese carácter no es válido en SQL/92. Se utiliza el punto y coma ";" como terminador de una instrucción. El hecho que SQL/92 use en realidad dicho terminador depende del contexto. Soporta diversos valores predeterminados, abreviaturas y escrituras alternas por ejemplo, CHAR por CHARACTER También, los corchetes "[" y "]" en CHARACTER y BIT significan que el material que encierran es opcional (como es normal, por supuesto, en la BNF [Forma Backus-Naur]). Por último, observe que SQL requiere que se especifiquen ciertas longitudes o precisiones para determinados tipos de datos (por ejemplo, CHAR). De hecho, aparentemente SQL considera esas longitudes y precisiones como parte del tipo (lo que implica que, por 23

24 ejemplo, CHAR(3) y CHAR(4) sean tipos diferentes); se piensa que es mejor considerarlas como restricciones de integridad. Una vez definida la base de datos, se puede ahora comenzar a operar en ella por medio de las operaciones SQL de manipulación SELECT, INSERT, UPDATE y DELETE. En particular, se puede realizar operaciones relacionales de restringir, proyectar y juntar sobre los datos empleando en cada caso la instrucción de manipulación de datos SELECT de SQL. El Catálogo El estándar de SQL incluye especificaciones para un catálogo estándar denominado Esquema de información. De hecho, los términos convencionales "catálogo" y "esquema" son usados en SQL, aunque con un significado muy específico de ese lenguaje; hablando en términos generales, un catálogo de SQL consiste en los descriptores de una base de datos individual, mientras que un esquema de SQL consiste en los descriptores de esa parte de la base de datos que pertenece a un usuario individual. En otras palabras, puede haber cualquier cantidad de catálogos (uno por base de datos), cada uno dividido en cualquier número de esquemas. Sin embargo, es necesario que cada catálogo incluya exactamente un esquema denominado INFORMATION_SCHEMA y, desde la perspectiva del usuario, es ese esquema el que realiza la función normal de catálogo. El Esquema de información consiste entonces en un conjunto de tablas de SQL cuyo contenido en efecto refleja con precisión todas las definiciones de los demás esquemas del catálogo en cuestión. Para ser más exactos, el Esquema de información está definido para contener un conjunto de vistas de un "Esquema de definición" hipotético. No es necesario que la implementación soporte el Esquema de definición como tal, pero sí requiere: Soporte algún tipo de "Esquema de definición". Soporte vistas de ese "Esquema de definición" que luzcan como las del Esquema de información. SQL Incrustado La mayoría de los productos SQL permiten la ejecución de instrucciones SQL de manera directa (es decir, en forma interactiva desde una terminal en línea) y también como parte de un programa de aplicación (es decir, las instrucciones SQL pueden estar incrustadas, lo que significa que pueden estar entremezcladas con las instrucciones del lenguaje de programación de dicho programa). 24