estudio de completitud técnica del sgbd postgresql en
TRANSCRIPT
Universidad Central “Marta Abreu” de Las Villas Facultad Matemática, Física y Computación Licenciatura en Ciencia de la Computación
EEssttuuddiioo ddee CCoommpplleettiittuudd TTééccnniiccaa ddeell SSGGBBDD PPoossttggrreeSSQQLL eenn rreellaacciióónn ccoonn oottrrooss ggeessttoorreess ddee bbaasseess ddee ddaattooss..
AUTORA: Beatriz María Méndez Hernández
TUTOR: Dr. Rosendo Moreno Rodríguez
Santa Clara 2010
“Año 52 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 de la Autora
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 Laboratorio
Dedicatoria A mis padres por estar siempre conmigo y confiar en mí todo el tiempo.
Agradecimientos A mi familia por estar siempre a mi lado.
A mi tutor por haberme ayudado, guiado y apoyado durante todo este tiempo.
A Linet por estar siempre que la necesité, en las buenas y las malas.
A Ana Francys, que aunque no esté aquí en este momento, me dio fuerzas para seguir
adelante.
A Javier por darme siempre apoyo y tenerme paciencia.
A mis amigas y amigos que han compartido conmigo todos estos años.
A todos los profesores que durante estos cinco años me educaron como profesional.
A todas las personas que de una forma u otra tuvieron que ver con la realización de este
Trabajo de Diploma.
Resumen
El presente trabajo pretende realizar un estudio de completitud de algunas de las
características técnicas que un Sistema de Gestión de Bases de Datos debe tener, para su
correcto uso en la creación de sistemas de información. La necesidad del mismo parte del
interés nacional de crear herramientas de software –en este caso un SGBD- soberano,
basado en lo mejor existente dentro de lo conocido como software libre, relacionado con
esta línea, en este caso el PostgreSQL. El estudio se realizó por métodos comparativos con
respecto a otros SGBD muy conocidos y utilizados en el mundo.
Se tuvieron en cuenta en este trabajo características tales como las facilidades en la
creación de tablas o clases, las interrelaciones y métodos de indexado, dentro del lenguaje
de definición de datos; así como las facilidades visuales de creación de consultas,
procedimientos almacenados y funciones, y herramientas de interfaz como formularios e
informes, como parte del lenguaje de manipulación de datos de cada gestor analizado.
También se estudiaron otras características típicas de este tipo de software.
Palabras Claves
Bases de Datos, Sistemas de Gestión de Bases de Datos, Características Técnicas de
SGBD, PostgreSQL.
Abstract
The present work seeks to carry out a completed study of some of the technical
characteristics that a Databases Management System should have, for its correct use in the
creation of information systems. The necessity of the same part of the national interest to
create software tools -in this case a DBMS- sovereign, based on the best thing existent
inside that known as free software, related with this line, in this case the PostgreSQL. The
study was carried out for comparative methods with regard to other very well-known and
used in the world DBMS.
They were kept in mind in this such characteristic work as the facilities in the creation of
tables or classes, the relationships and the indexing methods, inside the data definition
language; as well as the visual facilities for creation of queries, stored procedures and
functions, and interface tools like forms and reports, like part of the data manipulation
language each analyzed DBMS. Other typical characteristics of this software type were also
studied.
Key words
Databases, Database Management Systems, DBMS Technical Characteristics, PostgreSQL.
Tabla de Contenidos INTRODUCCION ..................................................................................................................1 CAPÍTULO 1. VISIÓN GENERAL DE CARACTERÍSTICAS TÉCNICAS DE LOS SGBD....................................................................................................................................10
1.1. Lenguajes de los SGBD..............................................................................................10
1.2. Métodos de indexado..................................................................................................12
1.3. Control de concurrencia .............................................................................................17
1.4. Control de la redundancia...........................................................................................20
1.5. Restricciones de los accesos no autorizados...............................................................20
1.6. Almacenamiento persistente de objetos y estructuras de datos de programas ...........20
1.7. Inferencias en la base de datos mediante reglas de reducción....................................21
1.8. Suministro de múltiples interfaces con los usuarios...................................................21
1.9. Cumplimiento de las restricciones de integridad........................................................22
1.10. Respaldo y Recuperación .........................................................................................23
1.11. Conclusiones Parciales .............................................................................................30
CAPÍTULO 2. ANÁLISIS DE CARACTERÍSTICAS TÉCNICAS IMPORTANTES PARA LA COMPLETITUD EN DIFERENTES SGBD. ....................................................31
2.1. Planteamiento del caso de estudio..............................................................................31
2.2. Lenguaje de Definición de Datos (DDL) ...................................................................32
2.2.1. Creación de Tablas...............................................................................................32 2.2.2. Relaciones ............................................................................................................38 2.2.3. Métodos de Indexado ...........................................................................................40
2.3. Lenguaje de Manipulación de Datos (DML)..............................................................46
2.3.1. Consultas ..............................................................................................................46 2.3.2. Procedimientos almacenados y funciones............................................................51 2.3.3. Formularios e Informes ........................................................................................55
2.4. Control de Concurrencia.............................................................................................59
2.5. Respaldo y Recuperación ...........................................................................................64
2.6. Conclusiones Parciales ...............................................................................................68
CAPÍTULO 3. CARACTERIZACIÓN COMPARATIVA DEL SGDB-OR POSTGRESQL. ....................................................................................................................69
3.1. Lenguaje de Definición de Datos del PostgreSQL.....................................................69
3.1.1. Creación de Tablas...............................................................................................69 3.1.2. Relaciones ............................................................................................................72 3.1.3. Métodos de Indexado ...........................................................................................72
3.2. Lenguaje de Manipulación de Datos de PostgreSQL.................................................73
3.2.1. Consultas ..............................................................................................................73 3.2.2. Procedimientos Almacenados y Funciones..........................................................75 3.2.3. Formularios e Informes ........................................................................................76
3.3. Control de Concurrencia.............................................................................................76
3.4. Respaldo y Recuperación ...........................................................................................79
3.5. Conclusiones Parciales ...............................................................................................82
CONCLUSIONES................................................................................................................85 RECOMENDACIONES.......................................................................................................86 REFERENCIAS BIBLIOGRÁFICAS .................................................................................87 BIBLIOGRAFÍA ..................................................................................................................89 ANEXOS ..............................................................................................................................93
Anexo 1. Control de redundancia......................................................................................93
Anexo 2. Restricción de los accesos no autorizados .........................................................93
Anexo 3. Almacenamiento persistente de objetos y estructuras de datos de programas...96
Anexo 4. Inferencias en la base de datos mediante reglas de deducción ..........................97
Anexo 5. Cumplimiento de las restricciones de integridad.............................................100
Lista de Figuras
1. Figura 1. Modelo Entidad-Relación del caso de estudio “Control de Maestrías”. 31
2. Figura 2. Tabla Persona creada mediante la interfaz interactiva SQL*Plus. 37
3. Figura 3. Tabla Persona creada mediante Oracle Enterprise Manager. 37
4. Figura 4. Tabla Persona creada mediante Oracle SQL Developer. 38
5. Figura 5. Diagrama de un índice B*Tree. 41
6. Figura 6. Ventana de diseño de una consulta en Access. 46
7. Figura 7. Ventana de presentación o vista de una consulta en Access. 47
8. Figura 8. Ventana del SQL Query Analyzer, del SQL Server. 48
9. Figura 9. Ventana del View, del SQL Server. 49
10. Figura 10. Ventana de creación de una Vista (View), del Oracle. 50
11. Figura 11. Código SQL generado de una Vista del Oracle. 50
12. Figura 12. Creación de un Procedimiento almacenado en SQL Server. 52
13. Figura 13. Resultado de un Procedimiento almacenado en SQL Server. 52
14. Figura 14. Creación de una Función en SQL Server. 53
15. Figura 15. Creación de un Procedimiento almacenado en Oracle. 54
16. Figura 16. Formulario de Personas en Access. 56
17. Figura 17. Definición de un informe en vista diseño en Access. 57
18. Figura 18. Formulario de Personas en Oracle. 58
19. Figura 19. Ventana de opciones de control de concurrencia en Access. 59
20. Figura 20. Ventana de opciones de respaldo en SQL Server. 66
21. Figura 21. Constructor Gráfico de Consultas en PostgreSQL. 74
22. Figura 22. Código generado de la Consulta en el Editor SQL de PostgreSQL. 74
23. Figura 23. Función generada en PostgreSQL. 75
24. Figura 24. Ventana de diálogo para resguardos en PostgreSQL. 81
25. Figura 25. Ventana de diálogo para restaurar una base de datos en PostgreSQL. 82
Lista de Tablas
1. Tabla 1. Características Generales de algunos SGBD 4
2. Tabla 2. Comparación a partir del Soporte del Sistema Operativo. 5
3. Tabla 3. Clasificación por Ambiente y Modelo de Datos. 5
4. Tabla 4. Clasificación por LDD y LMD. 6
5. Tabla 5. Resumen de las características técnicas de los SGBD Access, SQL
Server y Oracle.
68
6. Tabla 6. Resumen de las características técnicas del SGBDOR PostgreSQL 84
INTRODUCCION
Planteamiento del Problema:
Hasta el momento en nuestro país se utilizan diferentes sistemas gestores de bases de datos
(SGBD), en ocasiones el que mejor resuelva determinado problema -según sus
características-, pero a veces por ser el que conoce el implementador.
Sería de mucha utilidad que existiera un sistema que incluyera lo mejor de cada sistema
gestor de bases de datos y de esta forma se lograra que uno solo resolviera si no todos los
problemas, si la mayoría al menos para los sistemas de información generales. Mucho
mejor aún sería que ese sistema fuese de creación nacional y además basado en las
tecnologías de software libre que permitan tener una independencia tecnológica de nuestro
país no solo en el SGBD en sí, sino además en los sistemas de información o aplicaciones
que se desarrollarían en base al mismo.
Algunos de estos gestores tienen características de ser monousuarios lo que no permite
desarrollar sistemas de información para redes globales e incluso trabajan con problemas en
redes locales, al contrario otros gestores dan amplia posibilidades de trabajo en redes
globales al incluir mejores prestaciones en el trabajo con registros sin embargo adolecen de
no tener un lenguaje de manipulación de información que incluya desarrolladores de
ventanas y de informes con formatos elegantes, así como otras prestaciones generales como
un sistema de menú, centrándose en el diseño de la estructura de la base de datos, las
interrelaciones y las consultas y procedimientos almacenados.
La mayoría de estos gestores trabajan sobre el modelo relacional y aunque se conoce que
existen gestores supuestamente orientados a objetos, estos no son de un amplio uso
comercial.
En los últimos tiempos hay algunos gestores que han tratado de combinar ambos
paradigmas y también tratan de incluir otras formas de almacenamiento o de tratamiento de
la información para dar respuesta a sistemas como los de toma de decisiones. Algunos de
ellos han tomado la denominación de objeto-relacionales (SGBDOR).
1
Introducción
En este caso se quiere hacer una comparación de las principales características técnicas y
otras sugeridas, de los más conocidos sistemas gestores de bases de datos, con las que
posee el PostgreSQL, y a partir de ahí fundamentar criterios de completitud del sistema
gestor de bases de datos que se está desarrollando en nuestro país, basado en aquel, para
que de esta manera se satisfagan la mayoría de nuestras necesidades.
Objetivo General:
Estudiar y revelar las características internas del SGBDOR PostgreSQL, para destacar sus
potencialidades y debilidades en comparación con otros SGBD Relacionales y Objeto-
Relacionales, que sirvan de base para fundamentar criterios de completitud de un futuro
SGBD nacional sobre software libre.
Objetivos Específicos:
1. Formalizar y fundamentar diferentes criterios de completitud de un supuesto SGBD
de factura nacional basado en PostgreSQL.
2. Revelar en detalle algunas características de creación de tablas, índices y otros
elementos de una Base de Datos implementada en Oracle, SQL Server y Access,
sobre la base de una pequeña estructura de un caso de estudio, así como las
características del Lenguaje de Manipulación de Datos, en especial el tipo de SQL
que utiliza, las posibilidades de creación o no de interfaz de usuario, etc.
3. Revelar en detalle las características de creación de tablas, índices y otros elementos
de una Base de Datos implementada en PostgreSQL sobre la base de una pequeña
estructura del mismo caso de estudio, así como las características del Lenguaje de
Manipulación de Datos, en especial el tipo de SQL que utiliza, las posibilidades de
creación o no de interfaz de usuario, etc.
4. Comparar las características obtenidas anteriormente del PostgreSQL con respecto a
las de los otros SGBD, para establecer las potencialidades y las debilidades del
PostgreSQL.
Preguntas de Investigación:
2
Introducción
1. ¿Qué características debe tener un buen SGBD actualmente desde el punto de vista de
su lenguaje de definición de datos (LDD) y su lenguaje de manipulación de datos
(LMD)?
2. ¿Qué otras características de implementación de sistemas de información en ambiente
visual y gráfico son importantes para un buen SGBD?
3. ¿Qué criterios de completitud deberían incluirse en ese Software a desarrollar?
4. ¿Qué potencialidades de carácter de desarrollo de aplicaciones de bases de datos
incluye el SGBD PostgreSQL con respecto a otros gestores comerciales importantes?
5. ¿Qué debilidades de carácter de desarrollo de aplicaciones de bases de datos incluye
el SGBD PostgreSQL con respecto a otros gestores comerciales importantes?
6. ¿Servirá realmente el PostgreSQL como Software Libre, de base para el desarrollo de
un SGBD nacional?
Justificación de la Investigación:
Al establecer esta comparación se pretende hacer más fácil la construcción del nuevo
sistema gestor de bases de datos que nuestro país necesita, ya que se pondrán a la mano de
sus desarrolladores parte de la información técnica necesaria, que serviría como una guía
que permita tomar lo mejor de cada gestor que se utiliza actualmente nuestro país y en el
mundo, y obtener un resultado mucho más rápido, completo y eficiente, lo que estaría
acorde con la máxima actual de la Ingeniería del Software.
Viabilidad de la Investigación:
Se tiene información muy dispersa y generalmente comercial de estos gestores, pero no se
cuenta con información profunda técnicamente de lo que poseen estos y sus potencialidades
para el desarrollo de aplicaciones de tipo sistemas de información. Por tanto hay que
emplear mucho uso de la Bibliografía más relevante tanto clásica en libros como
actualizada en Internet y Revistas especializadas para alcanzar los objetivos. Por otra parte
se cuenta en el Seminario de Bases de Datos con las facilidades de equipamiento,
conectividad y bibliografía en formato impreso para acometer la investigación.
Marco Teórico Preliminar:
3
Introducción
Un Sistema de Gestión de Bases de Datos es esencial para el adecuado funcionamiento y
manipulación de los datos almacenados en soportes computacionales.
Se puede definir como: el conjunto de programas, procedimientos, lenguajes, etc., que
suministra, tanto a los usuarios no informáticos como a los analistas, programadores o al
administrador, los medios necesarios para describir, recuperar y manipular los datos
almacenados en la base, manteniendo su integridad, confidencialidad y seguridad.(Elmarsi
and Navathe, 2007a)
A continuación se muestran algunas características generales de diferentes sistemas
gestores de bases de datos:
Tabla 1. Características Generales de algunos SGBD
SGBD Creador Fecha de la 1ª
versión publicada
Última versión estable
Licencia de Software
DB2 IBM 1982 9 Propietario Informix Informix Software
(actual IBM) 1985 10.0 Propietario
Microsoft SQL Server
Microsoft junto a Sybase
1989 9.00.2047 Propietario
MySQL MySQL AB (después Sun Microsystem,
actual Oracle)
Noviembre de 1996
5.0 GPL o Propietario
Oracle Oracle Corporation 1977 11g Release 1
Propietario
PostgreSQL PostgreSQL Global Development Group
Junio de 1989 8.2.3 Licencia BSD
Microsoft Access
Microsoft 1990 2010 Propietario
Paradox Ansa (después Borland, ahora Corel)
1985 9 Propietario
Visual FoxPro
Fox Software Inc. (actual Microsoft)
FoxBase en 1983
6.0 Propietario
También se puede analizar otra comparación a partir del soporte del sistema operativo.
4
Introducción
Tabla 2. Comparación a partir del Soporte del Sistema Operativo.
SGBD Windows Mac OS X Linux BSD Unix z/OS
DB2 No No Informix No Microsoft SQL Server
No No No No No
MySQL Oracle PostgreSQL No Microsoft Access No No No No No Paradox No No No No No Visual Fox Pro No No No No No
Todos los gestores que aparecen en la tabla anterior tienen implementado la integridad
referencial. En cuanto al ambiente de trabajo y al tipo o modelo de datos se pueden
clasificar así:
Tabla 3. Clasificación por Ambiente y Modelo de Datos.
SGBD Tipo de Base de Datos Ambiente
DB2 Relacional Monousuario, cliente/servidor, permite bases de datos distribuidas
Informix Relacional Monousuario, cliente/servidor Microsoft SQL Server
Relacional Cliente/servidor
MySQL Relacional Cliente/servidor Oracle Relacional* Cliente/servidor PostgreSQL Objeto-relacional Cliente/servidor Microsoft Access Relacional Monousuario, cliente/servidor Paradox Relacional Monousuario, cliente/servidor Visual Fox Pro En su última versión es
orientado a objeto Monousuario, cliente/servidor
Otra característica interesante es determinar el tipo de lenguajes de definición de datos
(LDD) y de manipulación de datos (LMD) que presentan:
5
Introducción
Tabla 4. Clasificación por LDD y LMD.
SGBD LDD LMD
DB2 Una extensión de SQL
Una extensión de SQL y los procedimientos almacenados deben realizarse en un lenguaje externo: C, C++, Java, etc.
Informix SQL SQL Microsoft SQL Server
SQL Transact-SQL
MySQL SQL SQL Oracle PG/SQL PL/SQL PostgreSQL SQL PL/PgSQL Microsoft Access SQL SQL Paradox SQL Lenguaje propietario con cierto SQL local Visual Fox Pro Lenguaje Propietario Lenguaje propietario
A continuación una breve reseña de otras características de los principales sistemas de
gestión de bases de datos que serán tratados en el presente trabajo:
Oracle
Aparte de lo antes expuesto sobre este gestor se puede agregar que soporta el indexado
B*Tree, con lo cual mejora el rendimiento cuando se accede a una tabla, y el bitmap.
Soporta también objetos como cursores, disparadores, funciones, procedimientos y rutinas
externas. Los métodos de particionamiento soportados son rango, hash, compuesto
(rango+hash) y listas.
El PL/SQL es propio de Oracle, la base de datos incluye un compilador de Java y una JVM
(Java Virtual Machine) con la ingeniería de la base de datos. Esto permite a los
desarrolladores escribir procedimientos almacenados, disparadores y funciones en el
estándar de programación Java incluido en el lenguaje PL/SQL. Los desarrolladores
compilan los programas Java directamente en la base de datos o leen de una clase Java
utilizando la utilidad de Oracle llamada LoadJava.
Oracle es utilizado por empresas como: General Motors, General Electric, Intel
Corporation, HP, Philips, Nike, Banco de Crédito de Perú, Alcatel, British Gas, Andinatel
6
Introducción
Ecuador, Mercado Libre, Mastercard Internacional, Boing, Sri Ecuador, Concep,
Superintendencia de Bancos de Ecuador, Toyota Casa Baca, Iess, entre otros.
PostgreSQL
Soporta el indexado full-text a través de un disparador incluido en la distribución además de
muchos otros. Soporta objetos como dominio, cursores, disparadores, funciones,
procedimientos y rutinas externas. No permite métodos de particionamiento.
MySQL
Soporta el estándar B*Tree indexing con el uso de las tablas innodb, soporta objetos como
cursores, funciones, procedimientos y rutinas externas, pero no soporta dominio ni métodos
de particionamiento.
Está escrito en C y C++, tiene procesos multihilos (capacidad de trabajar servidores con
varios procesadores), permite el desarrollo de APIs para C, C++, Eiffel, Java, Perl, PHP,
Pitón, Ruby y TCL.
Empresas que utilizan MySQL: Sony, Suzuki, Lycos, Yahoo, Dell, PortaOne, Nasa,
UNICEF, McAffe, Aizawa Securities, Google, etc.
Microsoft SQL Server
Soporta el indexado full-text aunque su indexado por defecto es B*Tree. Soporta cursores,
disparadores, funciones, procedimientos y rutinas externas. También soporta el rango como
método de particionamiento.
Empresas que lo utilizan: AT&T Business Services, Lexis-Nexis, Chevron Canadá, Smead
Manufacturing, Disco, Ragnorak Systems, Keylime Software, CS HePalth Systems,
Verizon, Ticketmaster.com, entre otras.
DB2
Soporta el indexado reverso y bitmap. Soporta cursores, disparadores, funciones,
procedimientos y rutinas externas. Como métodos de particionamiento soporta rango, hash,
compuesto y lista. Permite a los usuarios tener acceso a una cantidad casi ilimitada de
datos; ejecutar una amplia gama de tareas, desde apoyo de decisiones hasta transacciones
7
Introducción
comerciales; trabajar con distintos tipos de datos de texto, imágenes, sonido y video;
administrar datos de manera rápida y sencilla; ejecutar el mismo software de una terminal a
otra, de un grupo de trabajo a otro y de una empresa a otra. Utilizando este gestor un
negocio minorista puede llegar al mercado global, sin el costo de adquirir y manejar nuevas
franquicias, creando una aplicación para vender sus productos online.
Informix
Soporta indexado tree R-/R+, hash y expresión. Los objetos soportados por él son cursores,
disparadores, funciones, procedimientos y rutinas externas. Permite manejar datos
alfanuméricos, contenidos digitales y multimedia (video, imágenes y audio), contenidos
basados en Web, aplicaciones lógicas y datos abstractos como series financieras. Permite
crear aplicaciones utilizables en la Web. La funcionalidad del SQL paralelo aumenta el
desempeño y permite que todas las operaciones de bases de datos se ejecuten en paralelo,
eliminando potenciales cuellos de botella.
Access
Los informes y formularios pueden hacerse directamente por programación, o de forma
interactiva. Puede guardar documentos con formato HTML y publicarlos en
Internet/Intranet, permite unir múltiples tablas en una única vista interrelacionada, llamada
página de acceso grupal, que agrupa registros que van desde categorías generales hasta
detalles específicos, comprime las bases de datos conservando espacio en computadora y
manipulándolas más rápido. Permite la integración de un servidor SQL para crear bases de
datos empresariales.
Hipótesis de Investigación:
La definición de los criterios de completitud de un buen SGBD debe servir de pauta
para el desarrollo futuro de un software de este tipo de factura nacional, en base al
conocido PostgreSQL considerado software libre. Entre estos criterios de
completitud deben considerarse las potencialidades que demanda un SGBD en su
Lenguaje de Definición de Datos (tablas, interrelaciones, atributos, tipos de
dominios, formas de almacenamiento, de indexado, etc.), así como en su Lenguaje
de Manipulación de Datos, en cuanto al uso de un lenguaje de consulta estándar
8
Introducción
como SQL u otro, las potencialidades de generación de forma visual de consultas,
procedimientos almacenados, y funciones, y la creación de interfaces de usuario
óptimas en ambiente de ventanas o en Web, tanto para la captación (formularios)
como para la presentación formateada de la información resultantes (informes) y
otros objetos de una IGU. También es importante revelar las potencialidades o
debilidades del PostgreSQL en cuanto al Control de Concurrencia y al Respaldo y
Recuperación.
Organización de la tesis
Para un mejor ordenamiento de las ideas y conclusiones de este trabajo se determinó
organizarlo en tres capítulos que incluyen lo siguiente:
1. Capítulo 1: Estudio del Marco Teórico relacionado con los SGBD más utilizados en
la actualidad.
2. Capítulo 2: Implementación de un breve problema en diferentes gestores y estudio a
partir de esto de algunas características seleccionadas de estos gestores.
3. Capítulo 3: Comparación de las posibilidades e insuficiencias del PostgreSQL en
comparación con los gestores estudiados anteriormente y planteamiento de los
requerimientos de completitud técnica del mismo, a fin de ser tomado en
consideración como base para la creación de un SGBD de factura nacional.
9
CAPÍTULO 1. VISIÓN GENERAL DE
CARACTERÍSTICAS TÉCNICAS DE LOS
SISTEMAS DE GESTIÓN DE BASES DE DATOS.
CAPÍTULO 1. VISIÓN GENERAL DE CARACTERÍSTICAS
TÉCNICAS DE LOS SGBD.
En este capítulo se aborda el marco teórico-referencial de las principales características que
se consideran importantes en un SGBD. Según el libro, SISTEMAS DE BASES DE
DATOS. Conceptos fundamentales, las características “deseables” en un SGBD son las
siguientes:(Elmasri and Navathe, 1997)
1. Control de la redundancia.
2. Restricciones de los accesos no autorizados.
3. Almacenamiento persistente de objetos y estructuras de datos de programas.
4. Inferencias en la base de datos mediante reglas de deducción.
5. Suministro de múltiples interfaces con los usuarios.
6. Representación de vínculos complejos entre los datos.
7. Cumplimiento de las restricciones de integridad.
8. Respaldo y recuperación.
Además de estas características consideramos importante agregar los lenguajes de los
SGBD y dentro del lenguaje de definición de datos hacer énfasis en los métodos de
indexado, y como otra característica importante consideramos el control de la concurrencia.
1.1. Lenguajes de los SGBD
En muchos SGBD en los que no se mantiene una separación estricta de niveles, el DBA y
los diseñadores de las bases de datos utilizan un mismo lenguaje, el lenguaje de definición
de datos (DDL: Data Definition Language), para definir ambos esquemas. El SGBD
contará con un compilador de DDL cuya función será procesar enunciados escritos en el
DDL para identificar las descripciones de los elementos de los esquemas y almacenar la
descripción del esquema en el catálogo del SGBD.
Cuando en los SGBD se mantenga una clara separación entre los niveles conceptual e
interno, el DDL servirá solamente para especificar el esquema conceptual. Se utiliza otro
lenguaje, el lenguaje de definición de almacenamiento (SDL: Storage Definition
Language), para especificar el esquema interno. Las correspondencias entre los dos
10
Capítulo 1
esquemas se pueden especificar en cualquiera de los dos lenguajes. Para una verdadera
arquitectura de 3 esquemas, se necesitaría un tercer lenguaje, el lenguaje de definición de
vistas (VDL: View Definition Language), para especificar las vistas del usuario y sus
correspondencias con el esquema conceptual. Una vez que se han compilado los esquemas
de la base de datos y que en esta se han introducido datos, los usuarios requerirán algún
mecanismo para manipularla. Las operaciones de manipulación más comunes son la
obtención, la inserción, la eliminación y la modificación de los datos. El SGBD ofrece un
lenguaje de manipulación de datos (DML: Data Manipulation Language) para estos fines.
En los SGBD actuales no se acostumbra a distinguir entre los tipos de lenguajes antes
mencionados; más bien se utiliza un amplio lenguaje integrado que cuenta con elementos
para definir esquemas conceptuales, definir vistas, manipular datos y definir su
almacenamiento. Un ejemplo de esto es el SQL que representa una combinación de todo
esto.
Son dos los principales tipos de DML, los de alto nivel o no por procedimientos que se
pueden utilizar de manera independiente para especificar las operaciones complejas de base
de datos de forma concisa. En muchos SGBD es posible introducir interactivamente
instrucciones de DML de alto nivel desde una terminal o bien incorporados en un lenguaje
de programación de propósito general. En el segundo caso es preciso identificar los
enunciados de DML dentro del programa para que el SGBD pueda procesarlos. Los DML
de bajo nivel o por procedimientos deben estar incorporados en un lenguaje de
programación de propósito general. Por lo regular, este tipo de DML obtiene registros
individuales de la base de datos y los procesa por separado; por tanto, necesita utilizar
elementos del lenguaje de programación, como la creación de ciclos, para obtener y
procesar cada registro individual de un conjunto de registros. Por esta razón, los DML de
bajo nivel se conocen también como DML de registro por registro (el dBASE era un
ejemplo típico). Los DML de alto nivel, como SQL, pueden especificar y recuperar muchos
registros con una sola instrucción de DML, y es por ello que se les llama DML de conjunto
por conjunto u orientado a conjuntos (en esto se diferenciaba del anterior el FoxBASE). Las
consultas en los DML de alto nivel suelen especificar que datos hay que obtener, y no como
obtenerlos; por ello, tales lenguajes se denominan también declarativos.
11
Capítulo 1
Siempre que las ordenes de un DML, sean de alto o de bajo nivel, se incorporen en un
lenguaje de programación de propósito general, a ese lenguaje se le llamará lenguaje
anfitrión, y al DML sublenguaje de datos. En los SGBD más recientes, como los orientados
a objetos, el lenguaje anfitrión y el DML suelen formar un solo lenguaje integrado. Por otro
lado, los DML de alto nivel empleados de manera interactiva e independiente se denominan
lenguajes de consulta. En general, las órdenes tanto de obtención como de actualización de
datos de un DML de alto nivel se pueden utilizar interactivamente, así que se consideran
parte del lenguaje de consulta.
Por lo regular, los usuarios finales esporádicos emplean un lenguaje de consulta de alto
nivel para especificar sus solicitudes, en tanto que los programadores utilizan el DML en su
forma incorporada. Para los usuarios simples y paramétricos casi siempre se incluyen
interfaces amables con el usuario que permiten interactuar con la base de datos; estas
también pueden aprovecharlas los usuarios esporádicos y otros que no deseen aprender los
detalles de un lenguaje de consulta de alto nivel.
1.2. Métodos de indexado
El índice de una base de datos es una estructura de datos que mejora la velocidad de las
operaciones, permitiendo un rápido acceso a los registros de una tabla. Al aumentar
drásticamente la velocidad de acceso, se suelen usar sobre aquellos campos sobre los cuales
se hagan frecuentes búsquedas.
El índice tiene un funcionamiento similar al índice de un libro, guardando parejas de
elementos: el elemento que se desea indexar y su posición en la base de datos. Para buscar
un elemento que esté indexado, solo hay que buscar en el índice dicho elemento para, una
vez encontrado, devolver el registro que se encuentre en la posición marcada por el índice.
Los índices pueden ser creados usando una o más columnas, proporcionando la base tanto
para las búsquedas rápidas al azar como de un ordenado acceso eficiente a registros.
Los índices son construidos sobre árboles B, B+, B- o sobre una mezcla de ellos, funciones
de cálculo u otros métodos.
El espacio en disco para almacenar el índice e típicamente menor que el espacio de
almacenamiento de la tabla (puesto que los índices generalmente contienen solamente los
12
Capítulo 1
campos claves de acuerdo con los que la tabla será ordenada, y excluyen el resto de los
detalles de la tabla), lo que da la posibilidad de almacenar en memoria los índices de tablas
que no cabrían en ella. En una base de datos relacional un índice es una copia de parte de
una tabla.(Buxton et al., 2009a)
Algunas bases de datos amplían la potencia del indexado al permitir que los índices sean
creados de funciones o expresiones. Otra opción a veces soportada es el uso de índices
filtrados, donde las entradas del índice son creadas solamente para los registros que
satisfagan una cierta expresión condicional. Un aspecto adicional de flexibilidad es permitir
la indexación en funciones definidas por el usuario, también como expresiones formadas de
un surtido de funciones incorporadas.(Buxton et al., 2009b)
Las estructuras de acceso de índice suelen definirse con base en un solo campo del archivo,
el llamado campo de indexación. Por lo regular, el índice contiene todos los valores del
campo de indexación junto con una lista de apuntadores a todos los bloques que contienen
registros con ese valor en ese campo. Los valores del índice están ordenados para que
podamos efectuar búsquedas binarias en el índice. Como el archivo de índices es mucho
más pequeño que el de datos, una búsqueda binaria en un índice es bastante
eficiente.(Buxton et al., 2009c)
Hay varios tipos de índices ordenados:(Sumathi and Esakkirajan, 2007a)
Índices primarios: es un archivo ordenado cuyos registros son de longitud fija y
contienen dos campos. El primero de estos campos tiene el mismo tipo de datos que
el campo clave de ordenamiento del archivo de datos, y el segundo campo es un
apuntador a un bloque de disco: una dirección de bloque. El campo clave de
ordenamiento se denomina clave primaria del archivo de datos. Hay una entrada de
índice (o registro de índice) en el archivo de índice por cada bloque del archivo de
datos. Para cada entrada del índice los valores de sus campos son el campo de clave
primaria del primer registro de un bloque y un apuntador a ese bloque.
Índices de agrupamiento: si los registros de un archivo están ordenados
físicamente según un campo no clave que no tiene un valor distinto para cada
registro, dicho campo se denomina campo de agrupamiento. Podemos crear este
tipo de índice para acelerar la obtención de registros que tienen el mismo valor en
13
Capítulo 1
el campo de agrupamiento. Este tipo de índice también es un archivo ordenado con
dos campos, el primero es del mismo tipo que el campo de agrupamiento del
archivo de datos, y el segundo un apuntador a un bloque. Hay una entrada en el
índice de agrupamiento por cada valor distinto del campo de agrupamiento, y
contiene el valor y un apuntador al primer bloque del archivo de datos que tiene un
registro con ese valor en el campo de agrupamiento.
Índices secundarios: también son archivos ordenados con dos campos. El primero
es del mismo tipo que algún campo no de ordenamiento del archivo de datos, y se
denomina campo de indexación del mismo. El segundo campo es un apuntador a un
bloque o bien un apuntador a un registro. Puede haber muchos índices secundarios
para el mismo archivo. Los índices secundarios según campos claves son índices
densos: contienen una entrada por cada registro del archivo.
El índice de múltiples niveles considera al archivo de índice, al que se le llama primer nivel
o nivel base del índice de múltiples niveles, como un archivo ordenado con un valor
distinto para cada entrada de índice. Por tanto, podemos crear un índice primario para este
primer nivel; este índice del primer nivel es ahora el segundo nivel del índice de múltiples
niveles. Como el segundo nivel es un índice primario podemos usar anclas de bloque para
que el segundo nivel tenga una entrada por cada bloque del primer nivel. Esto proceso se
repite una y otra vez. Este esquema es útil para cualquier tipo de índice, sea primario, de
agrupamiento o secundario, en tanto el índice del primer nivel tenga valores distintos para
las entradas de índice y sean de longitud fija.(Ramakrishnan and Gehrke, 2007a)
Un árbol de búsqueda es un tipo especial de árbol que sirve para guiar la búsqueda de un
registro, dado el valor de uno de sus campos. Los índices de múltiples niveles pueden
considerarse como variaciones de los árboles de búsqueda. Cada nodo del índice de
múltiples niveles puede tener hasta fo apuntadores y fo valores de clave, donde fo es el
abanico (fan-out) del índice. Los valores del campo de índice de cada nodo nos guían al
siguiente nodo, hasta llegar al bloque del archivo de datos que contiene los registros
deseados. Al seguir un apuntador, restringimos nuestra búsqueda en cada nivel a un
subárbol del árbol de búsqueda e ignoramos todos los nodos que no estén en dicho
subárbol.(Ramakrishnan and Gehrke, 2007a)
14
Capítulo 1
El árbol B es un árbol de búsqueda con algunas restricciones adicionales. Dichas
restricciones garantizan que el árbol siempre estará equilibrado y que el espacio
desperdiciado por la eliminación, si lo hay, nunca será excesivo. Los algoritmos para
insertar y eliminar aumentan en complejidad para mantener estas restricciones. No obstante
la mayor parte de las inserciones y eliminaciones son procesos simples; se complican solo
en circunstancias especiales: a saber, cuando intentamos hacer una inserción en un nodo
que ya está lleno o una eliminación en un nodo que después quedará ocupado hasta menos
de la mitad.(Ramakrishnan and Gehrke, 2007a)
A veces se emplean árboles B como organizaciones primarias de los archivos, en cuyo caso
se almacenan registros completos en los nodos del árbol B, no sólo las entradas <clave de
búsqueda, apuntador a registro>. Esto funciona correctamente si el archivo tiene un
número relativamente pequeño de registros y los registros son pequeños. En caso contrario,
el abanico y el número de niveles se incrementan tanto que impiden un acceso
eficiente.(Ramakrishnan and Gehrke, 2007a)
En su mayoría, las implementaciones de índices dinámicos de múltiples niveles emplean
una variación de la estructura de datos del árbol B: el árbol B+. En el árbol B todos los
valores del campo de búsqueda aparecen una vez en algún nivel del árbol, junto con un
apuntador de datos. En un árbol B+ los apuntadores de datos se almacenan sólo en los
nodos hojas del árbol, por lo cual la estructura de los nodos hoja difiere de la de los nodos
internos. Los primeros tienen una entrada por cada valor del árbol de búsqueda, junto con
un apuntador de datos al registro (o al bloque que contiene el registro), si el campo de
búsqueda es un campo clave. Si no lo es, el apuntador apunta a un bloque que contiene
apuntadores a los registros del archivo de datos, creándose así un nivel de in dirección
adicional.(Ramakrishnan and Gehrke, 2007a)
Los nodos hoja del árbol B+ suelen estar enlazados para ofrecer un acceso ordenado a los
registros según el campo de búsqueda. Los nodos internos del árbol B+ corresponden a los
demás niveles del índice. Algunos valores del campo de búsqueda de los nodos hoja se
repiten en los nodos internos del árbol B+ con el fin de guiar la búsqueda.(Sumathi and
Esakkirajan, 2007b)
15
Capítulo 1
En el caso de un árbol B+ construido según un campo clave, los apuntadores de los nodos
internos son apuntadores de árbol a bloques que son nodos del árbol, en tanto que los
apuntadores de los nodos hoja son apuntadores de datos a los registros o bloques del
archivo de datos, con la excepción del apuntador del siguiente nodo hoja. Si partimos del
nodo hoja del extremo izquierdo, podremos recorrer todos los nodos hoja como si fueran
una lista enlazada mediante estos apuntadores. Esto hace posible el acceso ordenado a los
registros de datos según el campo de indexación.(Sumathi and Esakkirajan, 2007c)
Como las entradas en los nodos internos de un árbol B+ contienen valores de búsqueda y
apuntadores de árbol, pero no apuntadores de datos, es posible empaquetar más entradas en
un nodo interno de este tipo de árbol que en un nodo interno de un árbol B. Esto puede
reducir el número de niveles del árbol B+, mejorándose así el tiempo de
búsqueda.(Ramakrishnan and Gehrke, 2007a)
Todos los índices antes mencionados incluyen un apuntador físico que especifica la
dirección del registro físico en el disco en forma de un número de bloque y un
desplazamiento. A esto se le conoce como índice físico y tiene la desventaja de que el
apuntador debe modificarse si el registro se pasa a otro lugar del disco.
Para solucionar este problema podemos usar una estructura llamada índice lógico que
mantiene los dos campos. Cada entrada tiene un valor para el campo de indexación
secundaria apareado con el valor del campo empleado para la organización primaria del
archivo. Si un programa busca el valor del campo de indexación en el índice secundario,
podrá localizar el valor correspondiente del campo empleado para la organización primaria
del archivo y utilizarlo para tener acceso al registro valiéndose de dicha organización. Los
índices lógicos se utilizan cuando se espera que las direcciones físicas de los registros
cambien con frecuencia. El costo es la búsqueda adicional que se basa en la organización
primaria del archivo.(Sumathi and Esakkirajan, 2007c)
En muchos sistemas el índice no es parte integral del archivo de datos, sino que puede
crearse y desecharse dinámicamente; es por ello que se acostumbra a llamarlo estructura de
acceso. Siempre que esperemos requerir acceso frecuente a un archivo según una condición
de búsqueda que implique un campo en particular, se puede solicitar al SGBD la creación
de un índice basado en ese campo. Por lo general se crea un índice secundario con el fin de
16
Capítulo 1
evitar la ordenación física de los registros del archivo de datos.(Ramakrishnan and Gehrke,
2007a)
A menudo se utilizan los índices para imponer una restricción de clave al campo de índice
de un archivo. Cuando se busca en el índice el lugar donde se insertará un registro nuevo
resulta sencillo verificar al mismo tiempo si algún otro registro del archivo tiene el mismo
valor para el campo de indexación. Si es así, la inserción podría rechazarse.
1.3. Control de concurrencia
Existen varias técnicas de control de concurrencia que sirven para garantizar la no
interferencia o el aislamiento de transacciones que se ejecutan de manera concurrente. Casi
todas ellas aseguran que los planes sean establecidos en series, empleando protocolos o
conjuntos de reglas que garantizan esta posibilidad.
Una de las principales técnicas para controlar la ejecución concurrente de transacciones se
basa en el concepto de bloquear elementos de información. Un candado es una variable
asociada a un elemento de información de la base de datos y describe el estado de ese
elemento respecto a las posibles operaciones que se pueden aplicar a él. En general, hay un
candado por cada elemento de información en la base de datos. Usamos los candados como
una forma de sincronizar el acceso a los elementos de la base de datos por parte de
transacciones concurrentes.(Connolly and Begg, 2005a)
Los candados pueden ser:
Candados binarios: pueden tener dos estados o valores, que pueden ser bloqueado o
desbloqueado (1 ó 0). A cada elemento de la base de datos se asocia un candado
distinto. Si el valor del candado sobre un cierto elemento es 1, ninguna operación de
base de datos que solicite el elemento podrá tener acceso a él. Si el valor del candado
sobre el elemento es 0, se podrá tener acceso a él cuando se solicite. Cuando se usa
bloqueo binario se debe incluir en las transacciones dos operaciones, bloquear-elemento
y desbloquear-elemento.
Candados compartidos y exclusivos: el esquema de bloqueo binario es demasiado
estricto en lo general, porque como máximo una transacción puede poseer un candado
sobre un elemento dado. Debemos permitir que varias transacciones tengan acceso al
17
Capítulo 1
mismo elemento si lo hacen exclusivamente para leerlo. Sin embargo, si una
transacción va a escribir un elemento deberá poseer acceso exclusivo a él. Con este fin,
podemos usar un tipo de candado diferente llamado candado múltiple. En este hay tres
operaciones de bloqueo: bloquear-lectura, bloquear-escritura y desbloquear. Además,
un candado asociado a un elemento tiene tres posibles estados: bloqueado para leer,
bloqueado para escribir o desbloqueado. Un elemento bloqueado para leer posee un
candado compartido porque otras transacciones no pueden leerlo; en cambio uno
bloqueado para escribir posee un candado exclusivo, porque una sola transacción posee
de manera exclusiva el candado del elemento.
El orden de las transacciones en el plan en serie equivalente se basa en el orden en que las
transacciones en ejecución bloquean los elementos que requieren. Si una transacción
necesita un elemento que ya está bloqueado, puede verse obligada a esperar hasta que se
libere dicho elemento. Un enfoque distinto que garantiza la ejecución en serie implica el
uso de marcas de tiempo de las transacciones para ordenar la ejecución de transacciones
según un plan en serie equivalente.(Connolly and Begg, 2005b)
Una marca de tiempo es un identificador único que el SGBD crea para identificar una
transacción. Por lo regular, los valores de marca de tiempo se asignan en el orden en que las
transacciones se introducen en el sistema, por lo que una marca de tiempo puede
considerarse como el tiempo de inicio de una transacción. Las técnicas para el control de
concurrencia basadas en marcas de tiempo no usan bloqueos.(Connolly and Begg, 2005b)
Las marcas de tiempo se pueden generar de diversas maneras. Una posibilidad consiste en
usar un contador que se incrementa cada vez que su valor se asigna a una transacción. Las
marcas de tiempo de las transacciones están enumeradas del 1 en adelante. Un contador de
computador tiene un valor máximo finito por lo que el sistema deberá restablecer el
contador a 0 cuando haya un lapso corto en el que ninguna transacción se esté ejecutando.
Otra forma de implementar las marcas de tiempo consiste en emplear el valor actual del
reloj del sistema y asegurar que no se generen dos valores de marca de tiempo antes que el
reloj cambie.(Connolly and Begg, 2005b)
Otros protocolos para controlar la concurrencia conservan los valores antiguos de un
elemento de información cuando este se actualiza. Estos se conocen como técnicas de
18
Capítulo 1
control de concurrencia de multiversión, porque se mantienen varias versiones del
elemento. Cuando una transacción requiere acceso a un elemento, se elige un aversión
apropiada para mantener la ejecución en serie del plan que se está llevando a cabo, si es
posible. La idea consiste en que algunas operaciones de lectura que serían rechazadas si se
usaran otras técnicas, se pueden aceptar leyendo una versión anterior del elemento a fin de
mantener la ejecución en serie. Cuando una transacción escribe un elemento, escribe una
nueva versión y se conserva la versión anterior de dicho elemento. En general, los
algoritmos para el control de concurrencia de multiversión utilizan el concepto de ejecución
en serie por vistas, no el de ejecución en serie por conflictos.(Elmarsi and Navathe, 2007a)
Una desventaja obvia de esta técnica es que se requiere más almacenamiento para mantener
múltiples versiones de los elementos de la base de datos. Sin embargo, es posible que de
todos modos sea necesario mantener versiones anteriores; por ejemplo con fines de
recuperación. Por añadidura, algunas aplicaciones de bases de datos requieren la
conservación de versiones anteriores para mantener una historia de cómo evolucionan los
valores de los elementos de información. El caso extremo es una base de datos temporal,
que sigue la pista a todos los cambios y los momentos en que ocurrieron. En tales casos, no
hay gasto adicional por las técnicas de multiversión, ya que de todos modos se mantienen
versiones anteriores.(Elmarsi and Navathe, 2007a)
En todas las técnicas anteriormente expuestas se realiza una cierta verificación antes de
que pueda ejecutarse una operación de base da datos. Esta verificación representa un gasto
extra durante la ejecución de las transacciones, y su efecto es hacerlas más lentas.
En las técnicas de control de concurrencia optimista, también llamadas técnicas de
validación o de certificación, no se efectúa verificación alguna durante la ejecución de las
transacciones. Mientras se ejecuta la transacción, todas las actualizaciones se aplican a
copias locales de los elementos, que se mantienen para la transacción. Al final de la
ejecución, una fase de validación comprueba si cualquiera de las actualizaciones viola la
serie. El sistema debe mantener cierta información que necesita para la fase de validación.
Si no se viola la serie, la transacción se confirma y la base de datos se actualiza a partir de
copias locales; en caso contrario, la transacción se aborta y se reinicia
posteriormente.(Elmarsi and Navathe, 2007b)
19
Capítulo 1
Este protocolo de control de concurrencia comprende tres fases:(Elmarsi and Navathe,
2007c)
1. Fase de lectura: una transacción puede leer valores de elementos de información a
partir de la base de datos. Sin embargo, las actualizaciones solo se aplican a copias
locales de los elementos, las que se mantienen en el espacio de trabajo de transacción.
2. Fase de validación: se efectúa una verificación para asegurarse de que no se violará la
serie si las actualizaciones de la transacción se aplican a la base de datos.
3. Fase de escritura: si la fase de validación se realiza con éxito, las actualizaciones de
la transacción se aplican a la base de datos; si no, las actualizaciones se desechan y la
transacción se reinicia.
El control de concurrencia optimista se basa en la idea de efectuar todas las actualizaciones
de una vez; así pues, la ejecución de las transacciones se efectúa con un mínimo de gasto
extra hasta llegar a la fase de validación. Si hay poca interferencia entre las transacciones,
casi todas se validarán sin dificultad. Sin embargo, si hay mucha interferencia, se
desecharán los resultados.(Elmarsi and Navathe, 2007b)
1.4. Control de la redundancia
Sobre este tema no se profundizará en los capítulos 2 y 3 para más información ver el
Anexo 1.
1.5. Restricciones de los accesos no autorizados
Sobre este tema no se profundizará en los capítulos 2 y 3 para más información ver el
Anexo 2.
1.6. Almacenamiento persistente de objetos y estructuras de datos de
programas
Sobre este tema no se profundizará en los capítulos 2 y 3 para más información ver el
Anexo 3.
20
Capítulo 1
1.7. Inferencias en la base de datos mediante reglas de reducción
Sobre este tema no se profundizará en los capítulos 2 y 3 para más información ver el
Anexo 4.
1.8. Suministro de múltiples interfaces con los usuarios
En vista de que muchos tipos de usuarios con diversos niveles de conocimiento técnicos
realizan operaciones en las bases de datos, el SGBD debe ofrecer diferentes interfaces.
Entre estas podemos mencionar los lenguajes de consulta para usuarios esporádicos, las
interfaces de lenguaje de programación para programadores de aplicaciones, las formas y
códigos de órdenes para los usuarios paramétricos y las interfaces controladas por menús y
en lenguaje natural para los usuarios autónomos.
Entre las interfaces con el usuario que pueden ofrecer los SGBD están las siguientes:
Interfaces basadas en menús: estas presentan al usuario listas de opciones,
llamadas menús, que lo guían para formular solicitudes. Los menús hacen
innecesario memorizar las órdenes y la sintaxis específica de un lenguaje de
consulta, pues permiten construir la solicitud paso por paso eligiendo las opciones
de los menús que el sistema presenta. Los menús desplegables son una técnica cada
vez más utilizada en las interfaces del usuario basadas en ventanas, y a menudo se
utilizan en las interfaces para hojear, que permiten al usuario examinar el contenido
de una base de datos en una forma no estructurada.
Interfaces gráficas: las interfaces graficas suelen presentar al usuario los esquemas
en forma de diagrama, y este puede entonces especificar una consulta manipulando
el diagrama. En muchos casos, estas interfaces se combinan con menús. Casi todas
las interfaces graficas se valen de un dispositivo apuntador para escoger ciertas
partes del diagrama de esquema que se exhibe.
Interfaces basadas en formas: presentan una forma o formulario a cada usuario.
Este puede entonces llenar todos los espacios de la forma para insertar datos nuevos,
o bien llenar solo ciertos espacios, en este caso el SGBD obtendrá los registros que
coincidan con los datos especificados. Las formas suelen diseñarse y programarse
para los usuarios simples como interfaces de transacciones programadas. Muchos
21
Capítulo 1
SGBD cuentan con lenguajes especiales, los lenguajes de especificación de formas,
con los que los programadores pueden especificar dichas formas. Algunos sistemas
cuentan con utilerías que definen formas al permitir que el usuario construya
interactivamente una forma de muestra en la pantalla.
Interfaces de lenguaje natural: estas interfaces aceptan solicitudes escritas en
inglés o en algún otro idioma e intentan entenderlas. Las interfaces de lenguaje
natural suelen tener su propio esquema, similar al esquema conceptual de la base de
datos. La interfaz consulta las palabras en su esquema, y en un conjunto de palabras
estándar, para interpretar la solicitud. Si la interpretación tiene éxito, la interfaz
genera una consulta de alto nivel que corresponde a la solicitud en lenguaje natural
y la envía al SGBD para su procesamiento; en caso contrario, se inicia un diálogo
con el usuario para esclarecer la solicitud.
Interfaces para usuarios paramétricos: los usuarios paramétricos a menudo
tienen un conjunto pequeño de operaciones que deben realizar repetidamente. Los
analistas de sistemas y los programadores diseñan e implementan una interfaz
especial para una clase conocida de usuarios simples. Casi siempre se incluye un
conjunto reducido de órdenes abreviadas, con el fin de reducir al mínimo el número
de digitaciones requeridas para cada solicitud.
Interfaces para el DBA: generalmente los sistemas de base de datos contienen
órdenes privilegiadas que solo el personal del DBA puede utilizar. Entre ellas están
las órdenes para crear cuentas, establecer los parámetros del sistema, otorgar
autorizaciones a las cuentas, modificar los esquemas y reorganizar la estructura de
almacenamiento de una base de datos.
Para ver como se comporta este aspecto en los diferentes gestores de bases de datos, lo
haremos a través del estudio de los informes y formularios dentro del lenguaje de
manipulación de datos.
1.9. Cumplimiento de las restricciones de integridad
Sobre este tema no se profundizará en los capítulos 2 y 3 para más información ver el
Anexo 5.
22
Capítulo 1
1.10. Respaldo y Recuperación
Todo SGBD debe contar con recursos para recuperarse de fallos de hardware o de software.
Para ello está el subsistema de respaldo y recuperación del SGBD. Por ejemplo, si el
sistema falla mientras se está ejecutando un completo programa de actualización, el
subsistema de recuperación se encargará de asegurarse de que la base de datos se restaure al
estado en que estaba antes que comenzara la ejecución del programa. Como alternativa el
subsistema de recuperación puede asegurarse de que el programa reanude su ejecución en
el punto en que fue interrumpido, de modo que su efecto completo se registre en la base de
datos.
A menudo las técnicas de recuperación de información están imbricadas con los
mecanismos de control de concurrencia. Algunas técnicas funcionan mejor con métodos
específicos de control de concurrencia.
Siempre que se introduce una transacción a un SGBD para ejecutarla, el sistema tiene que
asegurarse de que todas las operaciones de la transacción se completen con éxito y su
efecto quede asentado permanentemente en la base de datos o; la transacción no tenga
efecto alguno sobre la base de datos ni sobre cualquier otra transacción. El SGBD no debe
permitir que se apliquen a la base de datos algunas operaciones de una transacción pero no
otras de la misma transacción. Esto puede suceder si una transacción falla después de
ejecutar algunas de sus operaciones, pero antes de ejecutarlas todas.(Date, 2001a)
Hay varias razones por las que una transacción puede fallar mientras se está ejecutando:
1. Un fallo de la computadora (caída): un error de hardware o software ocurre en el
sistema de cómputo durante la ejecución de la transacción. Si el equipo falla, es
posible que se pierda el contenido de la memoria interna de la computadora.
2. Un error de la transacción o del sistema: alguna operación de una transacción puede
hacer que ésta falle, por ejemplo, un desbordamiento de enteros o una división entre
0. También puede haber un fallo de transacción debido a valores erróneos de los
parámetros o a un error lógico de programación. Por añadidura, puede suceder que
el usuario interrumpa a propósito la transacción durante su ejecución; por ejemplo,
al emitir ctrl.+c en un entorno UNIX.
23
Capítulo 1
3. Errores locales o condiciones de excepción detectadas por la transacción: durante la
ejecución de transacciones pueden presentarse ciertas condiciones que requieran la
cancelación de la transacción. Por ejemplo, es posible que no se encuentren los
datos para la transacción. Una condición, como un saldo insuficiente en una cuenta
en una base de datos bancaria, puede hacer que se cancele una transacción, como un
retiro de fondos de esa cuenta. Esto puede hacerse con una instrucción ABORTAR
programada en la misma transacción.
4. Imposición del control de concurrencia: el método de control de concurrencia puede
decidir que se aborte la transacción, para reiniciarla después, porque viola la
ejecución en serie o porque varias transacciones se encuentran en un estado de
bloqueo mortal.
5. Fallo del disco: algunos bloques de disco pueden perder sus datos por un mal
funcionamiento de lectura o escritura o por un aterrizaje de una cabeza de
lectura/escritura. Esto puede suceder durante una operación de lectura o de escritura
de la transacción.
6. Problemas y catástrofes físicos: esto se refiere a una interminable lista de problemas
que incluyen interrupción del suministro de energía, fallo del acondicionamiento de
aire, incendio, robo, sabotaje, sobre-escritura en discos o cintas por error, y que el
operador haya montado la cinta equivocada, etc.
Los cuatro primeros fallos son más comunes que los dos restantes. Siempre que ocurre un
fallo de los cuatro primeros, el sistema debe mantener suficiente información para
recuperarse del fallo. Los dos últimos no ocurren con tanta frecuencia; si se dan, la
recuperación es una tarea bastante complicada.
Existen técnicas que pueden servir para recuperarse de estos fallos en las transacciones. No
analizaremos las técnicas de cómo un sistema especifico implanta la recuperación. Nuestra
intención es describir conceptualmente varias estrategias distintas para que ocurra
esta.(Date, 2001a)
La recuperación de fallos en las transacciones casi siempre equivale a una restauración de
la base de datos a algún estado anterior de modo que sea posible reconstruir un estado
correcto a partir del estado anterior. Para lograr esto el sistema debe conservar, fuera de la
24
Capítulo 1
base de datos, información sobre las modificaciones hechas a los elementos de información
al ejecutarse las transacciones. Por lo general, esta información se guarda en la bitácora del
sistema. Una estrategia de recuperación podría ser la siguiente:(Elmarsi and Navathe,
2007d)
1. Si hay daños extensos en una porción considerable de la base de datos por algún
fallo catastrófico, como un aterrizaje de las cabezas del disco, el método de
recuperación restaurará una copia anterior de la base de datos que se habría vaciado
en almacenamiento secundario y reconstruiría un estado más actualizado, volviendo
a aplicar o rehaciendo las operaciones de las transacciones confirmadas asentadas en
la bitácora hasta el momento del fallo.
2. Cuando la base de datos no presenta daños físicos pero se ha vuelto inconsistente
debido a fallos no catastróficos de los primeros cuatro tipos antes mencionados, la
estrategia consiste en invertir los cambios que provocaron la inconsistencia,
deshaciendo algunas operaciones a fin de restaurar un estado consistente de la base
de datos. En este caso no necesitamos una copia completa de la base de datos, ya
que durante la recuperación solo se consultan las entradas asentadas en la bitácora
del sistema.
Se pueden distinguir dos técnicas para recuperarse de fallos no catastróficos en las
transacciones. Las técnicas de actualización diferida no actualizan en realidad la base de
datos sino hasta después de que una transacción llega a su punto de confirmación; en ese
momento es que se graban en la base de datos. Antes de ser confirmadas, todas las
actualizaciones se asientan en el espacio de trabajo local de la transacción. Durante la
confirmación, las actualizaciones se graban primero definitivamente en la bitácora y luego
se escriben en la base de datos. Si una transacción falla antes de llegar a su punto de
confirmación, no habrá modificado en absoluto la base de datos, por lo que no se necesita
DESHACER. Puede ser necesario REHACER, a partir de la bitácora, el efecto de las
operaciones de una transacción confirmada, ya que es posible que su efecto no se haya
registrado todavía en la base de datos. Por esto la actualización diferida es conocida
también como algoritmo de NO DESHACER/REHACER.(Elmarsi and Navathe, 2007d)
Se puede expresar un protocolo de actualización diferida como el siguiente:
25
Capítulo 1
1. Una transacción no puede modificar la base de datos antes de llegar a su punto de
confirmación.
2. Una transacción no llega a su punto de confirmación antes de asentar todas sus
operaciones de actualización en la bitácora y forzar la escritura de la bitácora en el
disco.
En las técnicas de actualización inmediata, es posible que algunas operaciones de una
transacción actualicen la base de datos antes de que la transacción llegue a su punto de
confirmación. Sin embargo, estas operaciones casi siempre se asientan en la bitácora en
disco mediante escritura forzada antes de aplicarse a la base de datos, lo que hace posible la
recuperación. Si una transacción falla después de asentar algunos cambios en la base de
datos pero antes de llegar al punto de confirmación, será preciso anular el efecto de sus
operaciones sobre la base de datos; esto es, la transacción deberá revertirse. En este caso es
preciso DESHACER y REHACER durante la recuperación, y es por ello que se denomina
algoritmo de DESHACER/REHACER. Existe una variación de este algoritmo en la que
todas las actualizaciones se asientan en la base de datos antes de que la transacción se
confirme por lo que solo requiere la operación DESHACER, por lo cual se le conoce a ésta
variación como algoritmo de DESHACER/NO REHACER.(Elmarsi and Navathe, 2007d)
El proceso de recuperación está a menudo íntimamente ligado con las funciones del sistema
operativo, en particular con el almacenamiento intermedio y en memoria caché de páginas
del disco en la memoria principal. Por lo regular, una o más páginas del disco que
contienen el elemento de información que ha de actualizarse se colocan en un
almacenamiento intermedio (caché) en la memoria principal, donde se actualizan antes de
escribirse otra vez en el disco. Este almacenamiento es tradicionalmente una función del
sistema operativo, pero debido a su importancia para que los procedimientos de
recuperación sean eficientes, puede ser que esto lo maneje el SGBD llamando a rutinas de
bajo nivel del sistema operativo. Por esto para fines de recuperación conviene suponer que
cada elemento de información corresponde a una página de disco.(Sumathi and
Esakkirajan, 2007d)
Por lo general, un grupo de buffer dentro de la memoria, llamados caché del SGBD, está
bajo el control del SGBD y sirve para almacenar elementos de la base de datos. Se utiliza
26
Capítulo 1
un directorio del caché para seguir la pista a los elementos que están en los buffer. Este
directorio puede ser una tabla de entradas <nombre del elemento, ubicación del buffer>.
Cuando el SGBD necesita hacer algo con un elemento, primero examina el directorio para
determinar si el elemento está en el caché. Si no es así, será preciso localizarlo en el disco y
copiar las páginas de disco apropiadas en el caché. Puede ser necesario desalojar algunos
de los buffer de caché para disponer de espacio para el nuevo elemento. Se puede usar
alguna estrategia de reemplazo de paginas del sistema operativo, como el menos usado
recientemente (LRU: Least Recently Used) o el primero que entra primero que sale (FIFO:
First In, First Out) para seleccionar el almacenamiento intermedio que se
desalojará.(Sumathi and Esakkirajan, 2007d)
Cada elemento en el caché tiene asignado un bit de modificación que se puede incluir en la
entrada del directorio y que indica si el elemento ha sido modificado o no (0, cuando se lee
inicialmente y se coloca en almacenamiento intermedio, y 1, cuando se modifica dicho
elemento). Cuando se desaloja un elemento, se escribirá en el disco solo si su bit de
modificación es 1.(Sumathi and Esakkirajan, 2007d)
Son dos las principales estrategias que se utilizan para desalojar hacia el disco un elemento
de información modificado. La primera es denominada actualización en el lugar, escribe el
elemento en la misma ubicación en el disco, sobrescribiendo así el valor anterior del
elemento. Con ello, se mantiene una copia de cada elemento en el disco. La otra estrategia
se denomina creación de sombras y escribe el nuevo elemento en un lugar diferente del
disco, lo que hace posible mantener múltiples copias de un elemento de información. En
general, el valor antiguo del elemento antes de la actualización se denomina BFIM (Before
Image) y el nuevo valor después de la actualización se denomina AFIM (After Image). Con
la creación de sombras la BFIM y la AFIM se conservan en disco; por tanto no es
realmente necesario mantener una bitácora para la recuperación.(Ramakrishnan and
Gehrke, 2007b)
Cuando se utiliza la actualización en el lugar es necesario utilizar una bitácora para la
recuperación. En este caso, el mecanismo de recuperación debe cuidar que la BFIM del
elemento de información se asiente en la entrada de la bitácora apropiada, y que dicha
27
Capítulo 1
entrada se desaloje al disco antes que la BFIM se sobrescriba con la AFIM. A este proceso
se le conoce como escritura anticipada en la bitácora.(Ramakrishnan and Gehrke, 2007b)
Para que sea posible la recuperación con la actualización en el lugar, las entradas
apropiadas necesarias para la recuperación se deben asentar permanentemente en la
bitácora en disco antes de aplicar modificaciones a la base de datos.
Para facilitar el proceso de recuperación, el subsistema de recuperación del SGBD
mantiene varias listas relacionadas con las transacciones que se están procesando en el
sistema. Estas incluyen una lista de transacciones activas que se han iniciado pero que
todavía no se han confirmado, una lista de transacciones confirmadas desde el último punto
de control y una lista de transacciones abortadas desde el último punto de control. Mantener
estas listas hace más eficiente el proceso de recuperación.(Ramakrishnan and Gehrke,
2007b)
En algunos casos, una sola transacción puede requerir acceso a varias bases de datos, a este
tipo de transacción se le llama transacción de multibases de datos. Estas podrían estar
almacenadas hasta en SGBD diferentes. En este caso, cada uno de los SGBD implicados
tendrá su propia técnica de recuperación y un gestor de transacciones independiente de los
de los otros gestores.(Ramakrishnan and Gehrke, 2007b)
Para mantener la atomicidad de una transacción de multibases de datos, es necesario contar
con un mecanismo de recuperación de dos niveles. Se requiere un gestor de recuperación
global, o también llamado coordinador; además de los gestores de recuperación locales. El
coordinador suele seguir un protocolo llamado protocolo de confirmación de dos fases.
Estas serían las siguientes:(Ramakrishnan and Gehrke, 2007b)
FASE 1: Cuando todas las bases de datos participantes le indican al coordinador que la
parte de la transacción en la que interviene cada cual ha concluido, este envía el mensaje
prepárense para confirmar a todos los participantes para que confirmen la transacción. Cada
una de las bases de datos que reciba este mensaje forzará la escritura de todos los registros
de la bitácora en disco y después enviará una señal de correcto o lista para confirmar al
coordinador. Si falla la escritura forzada a disco o la transacción local no puede
confirmarse, la base de datos envía una señal de incorrecto o imposible confirmar. Si el
28
Capítulo 1
coordinador no recibe respuesta en un determinado espacio de tiempo supone que es
incorrecto.
FASE 2: Si todas las bases de datos participantes contestan correcto, la transacción tiene
éxito y el coordinador les envía una señal de confirmar para esa transacción. Como todos
los efectos locales de la transacción se han asentado en las bitácoras de las bases de datos,
ya es posible recuperarse del fallo. Las bases de datos completan la confirmación de la
transacción escribiendo en la bitácora una entrada [confirmar] para esa transacción y
actualizando permanentemente la base de datos si es necesario. Si no todas envían la señal
de correcto, la transacción habrá fallado y el coordinador enviará a cada base de datos
participante un mensaje a fin de revertir el efecto local de la transacción. Se usa la bitácora
para la anulación.
El efecto neto del protocolo de confirmación de dos fases es que o bien todas las bases de
datos participantes confirman el efecto de la transacción o ninguna de ellas lo hace. Si
fallara algunas de las participantes o el coordinador, siempre será posible recuperarse hasta
el estado en el que la transacción se haya confirmado o revertido. Un fallo en la primera
fase o antes casi siempre obliga a revertir la transacción, pero uno en la segunda significa
que una transacción exitosa puede recuperarse y confirmarse.(Elmarsi and Navathe, 2007d)
El gestor de recuperación de un SGBD debe estar preparado también para manejar fallos
catastróficos como las caídas del soporte de almacenamiento principal (generalmente discos
magnéticos). La técnica principal para esto es el respaldo de la base de datos. La base de
datos y la bitácora se copian periódicamente en un medio de almacenamiento económico
(como las cintas magnéticas, u otros). Así en el caso de un fallo catastrófico del sistema la
copia de respaldo más reciente se carga del almacenamiento de resguardo al
almacenamiento principal, y el sistema se reiniciará.
Para evitar la pérdida de todos los efectos de las transacciones que se han ejecutado desde
el último respaldo, se acostumbra respaldar la bitácora del sistema copiándola
periódicamente en soporte magnético secundario. La bitácora suele ser mucho más pequeña
que la base de datos y por tanto se puede respaldar con mayor frecuencia. Si se respalda la
bitácora, no se pierden todas las transacciones que se hayan efectuado desde el último
respaldo de la base de datos. Es posible reconstruir el efecto sobre la base de datos de todas
29
Capítulo 1
las transacciones confirmadas asentadas en la parte de la bitácora que se respaldó. Se inicia
una nueva bitácora después de cada operación de respaldo de la base de datos. Así, para
recuperarse de un fallo de disco, lo primero que se hace es recrear la base de datos en disco
a partir de su última copia de seguridad en soporte magnético adicional. Después, se
reconstruyen los efectos de todas las transacciones confirmadas cuyas operaciones se hayan
asentado en la copia de respaldo de la bitácora del sistema.
1.11. Conclusiones Parciales
Ha sido posible hacer un estudio de las diferentes características enunciadas en la
Introducción a fin de medir la completitud de un SGBD, destacando la necesaria existencia
de los Lenguajes de Definición y de Manipulación de Datos, las posibilidades de uso de
varios métodos de indexado, el control de concurrencia, la seguridad ante accesos no
autorizados, las herramientas de desarrollo de interfaces de usuario adecuadas, el
cumplimiento de las restricciones de integridad y las posibilidades técnicas de respaldo y
recuperación ante diferentes tipos de fallos.
30
CAPÍTULO 2. ANALÍSIS DE CARACTERÍSTICAS
TÉCNICAS IMPORTANTES PARA LA
COMPLETITUD EN DIFERENTES SGBD.
CAPÍTULO 2. ANÁLISIS DE CARACTERÍSTICAS
TÉCNICAS IMPORTANTES PARA LA COMPLETITUD EN
DIFERENTES SGBD.
En este capítulo se analizarán algunas de las características técnicas antes mencionadas
como de importancia para medir la completitud de un SGBD, en diferentes gestores de
datos, tales como MS Access, MS SQL Server y Oracle. Para analizar estas características
se utilizó como base un caso de estudio aplicado, implementado en los tres sistemas
gestores anteriores.
2.1. Planteamiento del caso de estudio
Como caso de estudio para el análisis de estos gestores de bases de datos se utilizó el
módulo Control de Maestrías del Sistema de Postgrado versión 4.4 de nuestra universidad.
Esta base de datos cuenta con 20 tablas, algunas de las cuales funcionan como tablas
auxiliares. A continuación se muestra el modelo entidad-relación de nuestro caso de estudio
modelado con la herramienta ERECase.
Figura 1. Modelo Entidad-Relación del caso de estudio “Control de Maestrías”
31
Capítulo 2
Esta base de datos estaba implementada originalmente en MS Access, pero para poder
establecer nuestro análisis fue implementada también en MS SQL Server, en Oracle y por
supuesto en PostgreSQL. El porqué se escogen estos gestores es el siguiente:
Primeramente PostgreSQL porque el objetivo de esta tesis es evaluar su completitud,
pues se ha decidido crear un gestor de factura nacional supuestamente basado en el
mismo por ser un software libre.
MS Access (de Microsoft Corporation) por ser muy factible y usado por todos los
implementadores de sistemas de información monousuarios, que incluye poderosas
herramientas de desarrollo de una interfaz gráfica adecuada para este tipo de sistemas.
MS SQL Server (de Microsoft Corporation) porque actualmente es muy usado a nivel
mundial en ambientes cliente-servidor fundamentalmente y es considerado un
magnífico gestor de bases de datos, además de la cierta compatibilidad que tiene con
MS Access.
Finalmente se incluye a Oracle (de Oracle Corporation), el cual es considerado el
mejor SGBD del mundo por su completitud respecto a los demás SGBD, que puede
usarse en todo tipo de sistemas de información, o como medio de almacenamiento de
datos a gran escala. Además es bien reconocido por ser el gestor más seguro que
existe.
2.2. Lenguaje de Definición de Datos (DDL)
2.2.1. Creación de Tablas
Access
MS Access proporciona cuatro formas de crear una tabla:
Introducir los datos directamente en una tabla en blanco, denominada hoja de datos.
Cuando se guarda la nueva hoja de datos, Access analiza los datos y asigna
automáticamente el tipo de datos y el formato apropiados para cada campo.
Utilizar la vista de diseño (Design View) para especificar todos los detalles de la tabla
partiendo de cero.
Utilizar la instrucción CREATE TABLE en la vista SQL (SQL View).
32
Capítulo 2
Importar una tabla desde algún tipo de documento, por ejemplo MS Excel. En este
caso MS Access otorga los tipos de datos automáticamente.
Access no es completamente compatible con el estándar SQL. Sin embargo, se pueden
especificar valores predeterminados y ciertas restricciones de negocio desde fuera de SQL.
Los tipos de datos también son un poco distintos de los de SQL. A continuación se
muestran los diferentes tipos de datos que existen en Access:(Groh et al., 2007)
Texto: puede ser texto o texto/numero. También pueden ser números que no
requieren cálculos como el carné de identidad o un teléfono. Se corresponde con el
tipo de datos carácter en SQL. Desde 0 hasta 255 caracteres.
Memo: texto o números de gran longitud, como por ejemplo notas y descripciones.
Desde 0 hasta 65,536 bytes.
Número: datos numéricos que hay que utilizar en cálculos matemáticos, excepto los
de tipo monetario. Se corresponde con los tipos de datos numéricos exactos y
numéricos aproximados de SQL. Puede almacenar 1, 2, 4 ó 8 bytes.
Fecha/hora: fechas y horas. Corresponde con el mismo tipo de datos de SQL. Es de
8 bytes.
Monetario: los valores monetarios, con este tipo de datos podemos evitar
redondeos durante los cálculos. Es de 8 bytes.
Autonumérico: números secuenciales unívocos (incrementan de 1 en 1) o
aleatorios y se insertan automáticamente cuando se añade un registro. Tiene 4 bytes.
Sí/No: campos que solo pueden contener uno de dos valores, como Sí/No,
Verdadero/Falso o Masculino/Femenino. Se corresponde con el tipo de datos bit de
SQL. Solo puede tener 1 bit.
Objetos OLE: son objetos (documentos Word, hojas de calculo Excel, imágenes,
sonidos u otros datos binarios) creados en otros programas utilizando el protocolo
OLE y que pueden enlazarse con una tabla de Access. Desde 0 hasta 1 GB.
Hipervínculo: texto o una combinación de textos y números, almacenado como
texto y usado como una dirección WEB o un camino. De 0 a 2048 bytes para cada
una de las tres partes que componen la dirección. Puede alcanzar un tamaño de
hasta 64000 bytes.
33
Capítulo 2
Adjunto (Attachment): imágenes, archivos de hojas de cálculo, documentos,
cuadros. El tamaño varia dependiendo de que es lo que se encuentra almacenado
dentro del campo.
Asistente de búsqueda: crea un campo que permite al usuario seleccionar de un
valor de otra tabla o de entre una lista de valores utilizando un cuadro de diálogo
combinado. Si se selecciona esta opción en la lista de tipos de datos, se iniciará un
asistente para proceder a la definición. Por lo general solo requiere de 4 bytes,
necesita la misma capacidad de almacenamiento que la llave principal del campo de
búsqueda.
Después de creadas las tablas, Access no permite ver el código que genera dicha tabla. Es
decir en Access no hay forma de ver la compatibilidad que pueda tener con el SQL
Estándar porque para las tablas no permite esa opción.
Este gestor solo muestra los campos de la tabla y las diferentes características de cada
campo en una especie de documento Word.
SQL Server
En SQL Server las tablas pueden ser creadas mediante cuadros de diálogo que se van
llenando con el nombre de la tabla, el de los campos y algunas otras características, pero no
permite que se le agreguen los índices durante la creación, deben ser agregados después.
Una base de datos individual puede contener hasta dos millones de tablas, y cada tabla
hasta 1024 columnas. La longitud máxima de una fila es de 8092 bytes. La longitud
máxima de una columna es de 8000 bytes y puede haber hasta 1024 columnas en una fila;
sin embargo una fila no puede exceder una página de datos (8192 bytes). A continuación se
muestran los tipos de datos de SQL Server:(Waymire and Sawtell)
Char, varchar: almacenan cadenas de caracteres.
Binary: almacena información binaria.
Varbinary: almacena información binaria también pero en pares de dos bytes.
Int, smallint, tnyint: almacenan valores enteros.
Float, real: almacenan información numérica aproximada.
34
Capítulo 2
Decimal, numeric: almacenan información numérica exacta.
Bit: almacena información de un solo bit.
Text: almacena información de caracteres mayor a 8000 bytes.
Image: almacena datos de imágenes.
Datetime, smalltime: almacenan fechas y horas.
Timestamp: almacena valores que se incrementan automáticamente o son
asignados por SQL Server (aleatorios).
Nchar, ntext, nvarchar: almacenan datos en formato Unicode (doble byte por
carácter almacenado).
Money, smallmoney: almacenan cuatro dígitos a la derecha del punto decimal. El
primero puede almacenar hasta ±922,337,203,685,447.580,8 y el segundo hasta
±2,147,483,647.
Después de hecho todo esto se puede generar un script (guión) con extensión sql que brinda
el código de la tabla o tablas seleccionadas.
Este es el contenido del script generado por SQL Server para la tabla Persona:
CREATE TABLE [dbo].[Persona] (
[ci] [nvarchar] (11) COLLATE Modern_Spanish_CI_AS NOT NULL ,
[nombre] [text] COLLATE Modern_Spanish_CI_AS NULL ,
[apellido1] [text] COLLATE Modern_Spanish_CI_AS NULL ,
[apellido2] [text] COLLATE Modern_Spanish_CI_AS NULL ,
[nacionalidad] [int] NULL ,
[email] [nvarchar] (50) COLLATE Modern_Spanish_CI_AS NULL ,
[sexo] [int] NULL ,
[Fecha_de_Nacimiento] [smalldatetime] NULL ,
[telefono] [text] COLLATE Modern_Spanish_CI_AS NULL ,
[Direccion] [nvarchar] (50) COLLATE Modern_Spanish_CI_AS NULL ,
[Est_Civil] [int] NULL ,
[Año_Graduacion] [int] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
35
Capítulo 2
En SQL Server las tablas se pueden crear también mediante código con la herramienta
Query Analyzer.
Oracle
En Oracle una tabla puede tener hasta 254 columnas. Sus tipos de datos son los
siguientes:(Zeis et al., 2009)
Char(n): string de largo n. El valor máximo de n es 2000 bytes y el tamaño
predeterminado es 1.
Nchar(n): tipos de datos Unicode que almacena caracteres Unicode. Es igual al
char pero la longitud máxima esta dada por el conjunto de caracteres de la base de
datos. Puede ser hasta 4000.
Varchar2(n): datos de carácter de longitud variable.
Nvarchar2(n): igual que el varchar2 pero con la misma observación que para el
tipo de datos nchar.
Number (I, d): números con punto fijo o punto flotante, donde I representa la
longitud del número y d los lugares de la parte decimal.
Integer: están por la compatibilidad con SQL, es lo mismo que number (38).
Date: fechas desde el 1 de enero del 4712 AC hasta el 31 de diciembre de 4712 DC.
Blob: objeto binario cuya longitud puede alcanzar los 4 GB.
Clob: objeto de caracteres de hasta 2000 bytes.
Raw(n): datos binarios en bruto, como por ejemplo una secuencia de caracteres
gráficos o una imagen digitalizada.
Long: datos de tipo carácter de hasta 2 GB, solo se permite una columna de este
tipo por tabla.
Las tablas se pueden crear de tres formas:
1. Mediante el SQL*Plus que es una interfaz interactiva controlada mediante líneas de
comando. La tabla Persona creada mediante esta vía aparecen la figura 2.
2. Mediante Oracle Enterprise Manager. En la vista Schema encontramos diferentes
tipos de objetos entre los que se encuentran las tablas. Punteando con el ratón sobre
36
Capítulo 2
ellas y posteriormente en Create podemos crear tablas en Oracle. Aquí se pueden
crear de tres formas: con comandos SQL, con comandos XML y el método más
sencillo columnas específicas. El diseño de la tabla aparece en la Figura 3.
Figura 2. Tabla Persona creada mediante la interfaz interactiva SQL*Plus.
Figura 3. Tabla Persona creada mediante Oracle Enterprise Manager.
37
Capítulo 2
Oracle solo muestra 10 columnas por vista. Las columnas restantes se encuentran en otra
vista. Después de diseñar la tabla se le agregan las llaves principales y los índices.
3. Mediante SQL Developer, que es la forma más sencilla y práctica de crear una tabla
en Oracle. Desde aquí se le pueden agregar llaves primarias y foráneas, índices y
cualquier otra restricción que se desee tenga ésta. También Oracle genera a medida
que se va implementando la tabla un código que contiene la creación de la misma.
Figura 4. Tabla Persona creada mediante Oracle SQL Developer.
2.2.2. Relaciones
Para establecer relaciones entre las tablas ningún gestor sigue un único patrón. No obstante
lo más utilizado es la presentación de una ventana visual donde se pueden establecer los
enlaces o interrelaciones entre las diferentes tablas, generalmente las entidades fuertes,
débiles, tipos, subtipos, etc.
38
Capítulo 2
En MS Access no es necesario representar todas las tablas en el diagrama debido a que las
tablas auxiliares se pueden relacionar durante la creación de las mismas en la vista de
diseño a través de las características de búsqueda de valores de listas o codificadores, pero
es muy sencillo establecer las interrelaciones entre las demás tablas, a través de campos
comunes, previamente declarados, que tienen que tener el mismo tipo de datos. Es bueno
destacar que se pueden establecer tres tipos de interrelaciones, las que representan una
intersección entre dos entidades, y las que representan a una de las entidades completas
junto al conjunto que se intercepta de la otra. En el ejemplo no se dan situaciones extremas,
pero hay experiencias de que el Access tiene límites en la creación de relaciones en un
sistema de información, que puede ser un problema en sistemas complejos.
MS SQL Server también cuenta con un diagrama al igual que en Access, pero en este caso
es necesario establecer todas las relaciones mediante el diagrama. Pero normalmente se
opta por hacer un diagrama que en cierta medida representa un modelo entidad-relación
pero con cierta transformación al modelo relacional (se muestran los atributos de las tablas,
y no se permiten las interrelaciones muchos a muchos), ya que esto nos permite una mejor
visibilidad del problema y de su solución. En MS SQL Server se puede hacer cumplir la
integridad referencial de dos formas: mediante la integridad referencial declarativa (DRI) o
usando desencadenadores y controlando mediante programas esta funcionalidad. Solo
proporciona lo que se conoce como “restricción de borrado”, pero para lograr el borrado en
cascada tendría que programarlo uno mismo con desencadenadores, procedimientos
almacenados o consultas.
En Oracle no existen diagramas. Cuando creamos las tablas en la parte de los índices
podemos agregar las llaves foráneas para establecer las relaciones entre las tablas. Esto
supuestamente es debido a que las últimas versiones de Oracle son consideradas objeto-
relacional, y se entiende que se están definiendo clases de objetos. No obstante, creemos
que en este caso deberían haber implementado algún módulo gráfico de diseño de un
modelo lógico parecido a un diagrama de clases de UML, y otro de modelo físico, similar a
un diagrama de artefactos de UML. No obstante Oracle nos brinda tres opciones para la
eliminación: en cascada, restringida y poner a nulo. Sin embargo, para la actualización no
cuenta con ninguna acción, por lo que para esta parte necesitamos los desencadenadores y
procedimientos almacenados.
39
Capítulo 2
2.2.3. Métodos de Indexado
Access
En MS Access la propiedad del Índice de un atributo o campo de una tabla, puede tomar
tres valores diferentes:
No. Cuando el campo marcado no tiene índice
Si (Sin Duplicados). Cuando el campo esta indexado y no permite que la columna
sea duplicada. Esta característica es usada para datos que deben ser únicos dentro de
la tabla, es decir que no pueden repetirse como por ejemplo los campos claves (en el
ejemplo, CI o carné de identidad, o el ID de un trabajador).
Si (Con Duplicados). Este campo está indexado y permite que haya valores
duplicados en la columna. Este tipo de índices se utiliza para campos como por
ejemplo el nombre ya que dos personas pueden tener el mismo nombre sin que esto
signifique que sean los mismos. También son característicos cuando la clave de la
tabla es la unión de más de un campo y cada uno de los mismos puede repetirse y la
unicidad es dada por la concatenación de todos los campos de la clave.
MS Access también cuenta con la opción de Autoindexar al importar o crear una tabla a la
que se le pasan palabras claves que por lo general tienen los nombres de la llave principal
de la misma (id, código, folio) y automáticamente la propiedad de Indexado de ese campo
de la tabla toma el valor Si (Sin Duplicados).
MS Access acepta 32 índices por tabla, además actualiza la información de los índices cada
vez que se inserta un nuevo dato. Se pueden crear además índices con múltiples campos a
través del menú Índices. Es posible incluir hasta 10 campos en un índice de varios
campos.(Balter, 2007)
Los índices en Access tienen las siguientes propiedades:
Primario. Cuando en la propiedad Indexado dice Si, Access usa este índice como la
llave primaria de la tabla. Más de un campo puede ser llave primaria, pero siempre
cumpliendo con las reglas de que el valor de la llave primaria debe ser único y no
puede ser vacío. El valor predeterminado para la propiedad Primario es No.
40
Capítulo 2
Único. Cuando en la propiedad Indexado dice Si, el índice debe ser único dentro de la
tabla. Cuando existen llaves compuestas, la combinación de los valores de los campos
debe ser única – cada campo dentro de la llave compuesta puede duplicar campos
encontrados dentro de la tabla. El CI es un buen candidato para un índice único, pero
un nombre o un apellido no son buenos candidatos para índices únicos.
Ignorar los valores nulos. A menos que un índice contenga algún tipo de valor,
Access no sabe donde insertarlo en la lista de índices de la tabla. Por consiguiente,
podemos querer que Access ignore un dato si el valor del índice es nulo. Por defecto,
Ignorar los valores nulos tiene como valor predeterminado No, lo cual significa que
Access inserta datos con valores de índices nulos dentro del esquema de índices junto
con otro dato que contenga nulo también.
SQL Server
MS SQL Server utiliza el indexado a través de B*Tree. Un índice consiste en un conjunto
de páginas que son a las que se le llama B*Tree. Un B*Tree luce más o menos de la
siguiente manera:
Figura 5. Diagrama de un índice B*Tree.
Para localizar una fila individual de datos, se navega por el árbol binario hasta encontrar esa
fila y después se mueve a la fila de datos individual. Comienza con el nodo raíz. En la tabla
sysindexes se encuentra un puntero a la página raíz. El nodo raíz contiene entradas de
índices, así como punteros a cada página bajo el nodo raíz. Cada índice podría tener uno o
más niveles intermedios. Cada entrada podría tener un valor de índice o un puntero a una
siguiente página.(Turley et al., 2009)
41
Capítulo 2
En las páginas hoja, lo que encuentre depende de si la tabla tiene o no un índice agrupado.
Es decir, encontraría una entrada para cada fila que se esta indexando, así como un
localizador que apunta a la página de datos y número de fila que tiene la fila de datos real.
Si la tabla tiene además un índice agrupado, cualquier índice no agrupado contendrá valores
clave del índice agrupado, en vez de la información del número de página y fila.(Turley et
al., 2009)
Cada nivel del índice es una lista doblemente vinculada. Cada página sabe acerca de la que
le precede y de la que esta lógicamente después de ella. En los niveles raíz e intermedio,
cada valor de índice es el primer valor de la página del siguiente nivel bajo ella. En el nivel
fila índice, encontrará una entrada para cada fila de la tabla. Observe que el índice esta
clasificado con base en la columna o columnas que eligió como su clave de índice. Esto no
cambia el orden físico de clasificación de los datos.(Turley et al., 2009)
Al modificar datos en al tabla también se modifican sus índices. El Agente SQL garantiza
la consistencia entre los datos de su tabla y sus índices. Esto es bueno en el sentido de que
se desea una excelente integridad de los datos. Sin embargo, también significa que las
operaciones INSERT, UPDATE y DELETE que antes habrían sido más bien rápidas, ahora
podrían tener un poco más de trabajo por hacer y podrían ejecutarse un poco más lento. Si
desea agregar una nueva fila con la instrucción INSERT, normalmente tomaría dos
operaciones de entrada/salida; una para los datos y otra para el registro de transacciones. Si
se tienen dos índices en la tabla, tomará por lo menos otras dos o tal vez más. Debe
balancear sus necesidades entre modificaciones de datos y consultas más rápidas.
En SQL Server hay dos opciones para el almacenamiento físico de sus índices. El primero
se conoce como agrupado. Un índice agrupado (clustered) reclasifica físicamente los
datos. Acceder a datos por medio de un índice agrupado por lo general es más rápido que
utilizar un índice no agrupado debido a que no es necesaria la búsqueda adicional de la
página/fila de datos desde el nivel nodo de hoja del índice.
Debido a que los datos están clasificados físicamente en el orden de la clave del índice, una
tabla solo puede tener un índice agrupado. Ya que solo hay disponible un índice agrupado,
se debe elegir con mucho cuidado.
42
Capítulo 2
Un aspecto importante que surge con los índices agrupados es el espacio libre. Crear un
índice agrupado requiere que por lo menos haya disponible un 120 por ciento del tamaño de
la tabla como espacio temporal de trabajo. Este espacio debe existir en la base de datos en
la cual se esta creando el índice. Para crear el índice SQL Server copia la tabla y la clasifica
en el orden de los valores del índice, construye las estructuras del índice y luego elimina la
tabla original. Cuando termina esta operación, el índice agrupado tomará solo alrededor de
un 5 por ciento más de espacio que la misma tabla. La sobrecarga de este tipo de índice es
relativamente pequeña, aunque depende del tamaño de los valores que se estén
indexando.(Turley et al., 2009)
Otro aspecto de importancia es que los valores claves (columnas indexadas) que se eligen
para el índice agrupado son arrastrados dentro de los índices no agrupados. Por tanto si
elige un índice agrupado ancho, no solo tomará más tiempo examinar el propio índice
agrupado, sino que todos sus índices no agrupados tendrán que llevar el valor de la clave de
su índice agrupado en cada fila de los índices no agrupados. Esta es una sobrecarga
importante, por lo que se recomienda mantener sus claves de índice agrupado tan reducidas
como sea posible. También es bueno asegurarse que la clave agrupada que se seleccione no
se actualice con frecuencia ya que necesitaría actualizar todos sus índices no agrupados al
cambiar los valores del índice agrupado.
Algo que también se debe tomar en cuenta es en el orden en que se crean los índices.
Debido a que el índice agrupado forma parte de cada uno de los valores clave de los índices
no agrupados. Por lo tanto siempre se debe crear primero los índices agrupados.
Un índice no agrupado (nonclustered) es básicamente lo mismo que un índice de árbol
binario estándar. Cada índice tendrá un nodo raíz, uno o más niveles de páginas
intermedias, y un nivel de nodo de hoja, el cual contendrá una fila para cada fila de la tabla.
Los índices no agrupados requieren por lo general más espacio que los índices agrupados,
pero ocupan mucho menos durante el proceso de creación.
Puede haber hasta 249 índices no agrupados en una sola tabla. El orden en que se crean no
es importante. Al crear un índice no agrupado, este no cambia el orden de los datos como
sucede con un índice agrupado. Las filas del nivel de nodo de hoja del índice se clasifican
en el orden de las columnas seleccionadas como parte del índice. Cada fila contiene un
43
Capítulo 2
puntero a la combinación número de página/número de fila de los datos de la tabla si no
existe un índice agrupado, o el valor de la clave del índice de agrupamiento si este
existe.(Turley et al., 2009)
Índices únicos/no únicos
La identificación única determina si se permiten o no valores duplicados en su índice. Esto
es lo mismo que en Access el Si (sin duplicados) / Si (con duplicados). De manera
predeterminada en SQL Server los índices no son únicos, lo que significa que si permiten
duplicados.
Si los datos lo permiten hacer un índice único puede mejorar significativamente el
desempeño cuando los utilice. Cuando localiza el valor el valor que esta buscando, no es
necesaria una búsqueda subsecuente del índice (debido a que sabe que será la única
entrada), cuando lo encuentre puede dejar de seguir buscando.
Los índices agrupados son buenos candidatos para ser únicos ya que de manera interna
SQL Server obliga a que sean únicos. Si no crea un índice agrupado único, SQL Server
genera un valor de clave adicional oculto para forzar la identificación única del índice.
Índices de una columna/varias columnas
Muchos índices tendrán solo una columna; sin embargo, es fácil crear un índice de varias
columnas. Los índices de varias columnas pueden ser bastante útiles debido a que permiten
reducir el número de estos que utiliza SQL Server y obtener un desempeño más rápido. Si
durante las consultas especifica con frecuencia estas columnas juntas, estas son un
excelente candidato para lo que se conoce como un índice compuesto. Estos pueden ser
agrupados o no agrupados.
SQL Server crea un índice agrupado y único para la llave primaria de la tabla
automáticamente.
Oracle
Oracle también crea un índice para la llave primaria automáticamente al igual que MS SQL
Server. Los índices en Oracle pueden ser de tres tipos:
44
Capítulo 2
B*Tree. Este índice contiene una entrada para cada valor de la llave del índice junto
con una dirección en el disco de la fila donde el valor es almacenado. El índice
B*Tree es el que trae Oracle por defecto y es el más común en una base de datos
Oracle.
Bitmap. Usa cadenas de bits para encapsular valores y direcciones de filas
potenciales, almacena en cada clave una estructura en la que a cada fila corresponde
un bit: si está en cero, la fila no pertenece a la clave, si está en uno, sí pertenece.
Son más compactos que los B*Tree y pueden realizar algunos tipos de recuperación
eficazmente. Pero para uso general, sin embargo, un índice Bitmap requiere más
espacio durante las operaciones con las filas de una tabla y debe ser usado
principalmente para ambientes de almacenes de datos.
Function-Based. El valor del índice es derivado de los datos de la tabla. Por
ejemplo, para encontrar datos que sean de tipo carácter y puedan estar mixtos
(mayúsculas y minúsculas), podemos usar este tipo de índice basado en la función
UPPER() para buscar los valores donde todo esté en mayúsculas.
Oracle permite crear también índices para una sola columna o para múltiples columnas. A
estos últimos se les llama índices concatenados. Los índices concatenados son útiles cuando
todas las columnas del índice probablemente estarán incluidas en la cláusula WHERE de
una consulta frecuentemente ejecutada.
También permite definir índices con clave invertida. Si los postgrados estuvieran ordenados
por la fecha de inicio y por ejemplo, los usuarios consultaran los postgrados más recientes
solamente, solo se estarían manipulando en un mismo rango de fechas, lo cual quiere decir
que en el índice de fechas existirán un par de bloques que están siendo modificados
constantemente. Cuando usamos la opción reverse las claves se invierten físicamente, al
nivel de bytes. Como resultado, fechas que antes eran consecutivas se distribuyen ahora de
forma aleatoria. La desventaja de esto es que ahora no se puede aprovechar el índice para
recuperar rápidamente los apuntes situados entre dos días cualesquiera.
Los índices pueden ser particionados. En la mayoría de las situaciones, es útil particionar
un índice cuando la tabla asociada está particionada, y para particionar el índice se usa el
mismo esquema de particionamiento de la tabla.
45
Capítulo 2
2.3. Lenguaje de Manipulación de Datos (DML)
2.3.1. Consultas
Access
Las consultas en Access se pueden implementar de forma visual o mediante código SQL.
En cualquiera de las dos formas que se implemente se genera la otra. Por ejemplo, la
consulta MaestríaPG, en la cual se obtiene como resultado una tabla con el folio, el título y
la versión de todas las maestrías impartidas en la UCLV; se implementaría de la siguiente
manera:
Figura 6. Ventana de diseño de una consulta en Access.
La salida de esta consulta es una tabla como la que se muestra a continuación:
46
Capítulo 2
Figura 7. Ventana de presentación o vista de una consulta en Access.
El código SQL que genera Access para esta consulta es el siguiente:
SELECT Maestria.Folio, [PostGrado]![titulo]+" "+[Maestria]![version]+" Edición"+" Grupo:
"+[Maestria]![grupo] AS titulo, Maestria.version
FROM PostGrado INNER JOIN Maestria ON PostGrado.Folio = Maestria.Folio;
MS Access cuenta con diferentes tipos de funciones, algunas de la cuales se mencionan a
continuación:
Funciones para matrices
Funciones de conversión.
Funciones de fecha y hora
Funciones agregadas de dominio
Funciones para el tratamiento de errores
Funciones financieras
Funciones matemáticas
Funciones agregadas de SQL
Funciones de cadenas
47
Capítulo 2
SQL Server
En SQL Server existe una herramienta que se lama SQL Query Analyzer donde se pueden
implementar consultas mediante código. También existen las vistas (Views) que se
asemejan bastante a las consultas de Access porque pueden implementarse visualmente y
también pueden hacerse por código. Si se hacen por código cuando se ejecutan las vistas se
genera la parte visual, y si se hacen en la parte visual se va generando el código a medida
que escogemos lo que queremos mostrar.
A continuación se muestra como se genera la consulta vista anteriormente en el SQL Query
Analyzer y mediante una View respectivamente.
Figura 8. Ventana del SQL Query Analyzer, del SQL Server.
48
Capítulo 2
Figura 9. Ventana del View, del SQL Server.
Oracle
Las consultas en Oracle se hacen mediante las vistas (Views) al igual que en SQL Server.
Pero en el caso de Oracle para crear una View se puede hacer mediante código o mediante
una forma visual, pero esta última nada tiene que ver con las formas visuales vistas
anteriormente en Access y SQL Server. La forma visual para crear una vista en Oracle sería
como se muestra a continuación.
49
Capítulo 2
Figura 10. Ventana de creación de una Vista (View), del Oracle.
EL código generado por esa consulta es el siguiente:
Figura 11. Código SQL generado de una Vista del Oracle.
50
Capítulo 2
2.3.2. Procedimientos almacenados y funciones
MS Access no cuenta con ninguna de estas dos opciones. En Access todo se tiene que hacer
a través de las consultas.
SQL Server
En SQL Server los procedimientos almacenados son instrucciones precompiladas de
Transact-SQL almacenadas en una base de datos. Debido a que son precompilado, por lo
regular ofrecen mejor desempeño que cualquier tipo de consulta.
Los procedimientos almacenados de SQL Server pueden tener hasta 1024 parámetros y
pueden hacer referencia a tablas temporales, las temporales locales desaparecerán al
terminar el procedimiento. Se pueden anidar procedimientos dentro de otros
procedimientos con una profundidad de 32 niveles. Los procedimientos se ejecutan desde el
SQL Query Analyzer con la instrucción:(Waymire and Sawtell)
exec <nombre del procedimiento> [parámetros]
Un beneficio aún mayor de los procedimientos almacenados es que puede asignar permisos
a un usuario para que ejecute un procedimiento almacenado incluso si dicho usuario no
tiene permisos sobre las tablas que usa dicho procedimiento.
Por ejemplo, si necesitamos saber la cantidad de maestrías que existen podemos saberlo
mediante un procedimiento almacenado. Un procedimiento almacenado con el siguiente
código devuelve dicha información.
51
Capítulo 2
Figura 12. Creación de un Procedimiento almacenado en SQL Server.
La ejecución de esta consulta y su resultado se muestran a continuación:
Figura 13. Resultado de un Procedimiento almacenado en SQL Server.
La diferencia entre un procedimiento almacenado y una función es que una función siempre
devolverá un único valor a quien haya hecho la invocación mientras que un procedimiento
almacenado no. Usualmente se emplean procedimientos almacenados a menos que nos
haga falta un valor de retorno. El ejemplo visto anteriormente se puede hacer como una
función solo cambia un poco el código pero el resultado es el mismo.
52
Capítulo 2
Figura 14. Creación de una Función en SQL Server.
En SQL Server existen diferentes tipos de funciones que están agrupadas en las siguientes
categorías:(Hotek, 2008)
Funciones de agregado. Realizan operaciones que combinan varios valores en uno
(COUNT, SUM, MIN, MAX).
Funciones de configuración. Son funciones escalares que devuelven información
acerca de la configuración.
Funciones del cursor. Devuelven información acerca del estado del cursor.
Funciones de fecha y hora. Tratan con los valores de tipo datatime y smalltime.
Funciones matemáticas. Realizan operaciones trigonométricas, geométricas y demás
operaciones numéricas.
Funciones de metadatos. Devuelven información acerca de los atributos de las bases
de datos y de los objetos de base de datos.
Funciones de conjuntos de filas. Devuelven conjuntos de filas que se pueden usar en
el lugar de una referencia de tabla de una instrucción de Transact-SQL.
Funciones de seguridad. Devuelven información acerca de usuarios y funciones.
Funciones de cadena. Tratan con valores char, varchar, nchar, nvarchar, binary y
varbinary.
53
Capítulo 2
Funciones del sistema. Funcionan e informan acerca de varias opciones y objetos
del sistema.
Funciones estadísticas del sistema. Devuelven información relacionada con el
rendimiento del SQL Server.
Funciones de texto e imagen. Tratan valores text e image.
Oracle
En Oracle también existen procedimientos almacenados y funciones que son bloques
PL/SQL que pueden tomar parámetros y ser invocados a voluntad del programador.
Mediante el SQL Developer un procedimiento almacenado se hace de la siguiente manera:
Figura 15. Creación de un Procedimiento almacenado en Oracle.
Los procedimientos almacenados se pueden ejecutar desde el SQL*Plus mediante los
siguientes comandos:
SQL> SET SERVEROUTPUT ON;
SQL> EXECUTE <nombre del procedimiento> [(parámetros)];
Oracle cuenta con varios tipos de funciones tales como:
54
Capítulo 2
Funciones agregadas de SQL
Funciones de cadenas
Funciones de conversión
Funciones de fecha y hora
Funciones matemáticas
Otras funciones con las que cuenta el PL/SQL.
2.3.3. Formularios e Informes
Access
Los formularios de Access permiten al usuario visualizar y editar los datos almacenados en
las tablas base subyacentes, presentando los datos de una forma organizada y personalizada.
Los formularios se construyen como una colección de elementos de diseño individuales
denominados controles u objetos de control.(Connolly and Begg, 2005a)
Los formularios están divididos en una serie de secciones; las tres principales son las
siguientes:
Cabecera del formulario. Determina lo que se visualizará en la parte superior de
cada formulario. El título por ejemplo.
Detalle. Muestra usualmente una serie de campos de un registro.
Pie del formulario. Determina lo que se mostrará en la parte inferior de cada
formulario.
Access permite al usuario experimentado crear formularios partiendo de cero a partir de
una ventana de Vista de Diseño. Pero también proporciona un asistente de formularios
(Form Wizard) que guía al usuario a través de una serie de páginas interactivas que
solicitan las tablas, sus atributos, los estilos del formulario, el tipo (si de resumen o de
detalle), etc., y al final es posible editar en la propia Vista de Diseño.
El que sigue es un ejemplo de un formulario en Access, para capturar los datos de las
Personas que intervienen en el Sistema propuesto como Caso de Estudio:
55
Capítulo 2
Figura 16. Formulario de Personas en Access.
Estos formularios permiten diferentes tipos de objetos: botones, radios butom y check
butoms, cuadro combinado y cuadro de lista, imágenes y subformularios, entre otros.
Los informes de Access son un tipo especial de formulario continuo diseñado
específicamente para impresión, en lugar de para su visualización en una ventana. Como
tal, un informe solo tiene acceso de lectura a las subyacentes tablas base. Los informes
permiten al usuario:(Connolly and Begg, 2005a)
Ordenar registros
Agrupar registros
Calcular información de resumen
Controlar la disposición y apariencia globales del informe.
Los informes pueden crearse partiendo de cero en una vista diseño. Sin embargo, también
proporciona un asistente de informes (Report Wizard) que lleva al usuario a través de una
serie de páginas interactivas. A continuación un ejemplo de definición de informe en vista
diseño.
56
Capítulo 2
Figura 17. Definición de un informe en vista diseño en Access.
SQL Server
SQL Server cuenta para hacer informes con una herramienta muy poderosa SQL Server
Reporting Services (SSRS) que ofrece funcionalidad empresarial de informes habilitados
para Web con el fin de poder crear informes que extraigan contenido a partir de una
variedad de orígenes de datos, publicar informes con distintos formatos. Provee servicios,
herramientas e interfaces de programación (API).(Turley et al., 2009)
Cuenta con un lenguaje de especificación estándar denominado Report Definition
Language (RDL), el cual es un lenguaje de formato en lenguaje XML que se encarga de
definir el informe. Puede hacer informes en distintos formatos como hojas de cálculo Excel,
documentos PDF, XML, DOC.(2010)
La arquitectura de Reporting Services permite a los desarrolladores preparar aplicaciones
personalizadas que accedan a los reportes a través de una API que está expuesta como un
servicio Web.
Por otra parte el SQL Server como parte integrante de la plataforma de desarrollo .NET de
Microsoft, posibilita la creación de informes con herramientas de apoyo a diferentes
lenguajes profesionales de esta como el Crystal Report.
57
Capítulo 2
Oracle
Para la creación de formularios e informes Oracle cuenta con Oracle Developer, este
software no está incluido en la instalación, pero si se tiene licencia de Oracle es gratuito
descargarlo. Existe el Forms Developer y el Reports Developer para la construcción de
formularios e informes respectivamente.
La herramienta para construir formularios se llama Forms Builder, la cual a través de
diversas páginas interactivas nos guía para la creación de un formulario. Por ejemplo, el
formulario para agregar a una nueva Persona podría ser el siguiente:
Figura 18. Formulario de Personas en Oracle.
Los informes se harían con la herramienta Reports Builder y se crearían de manera similar
a la de los formularios.
Todo lo anterior demuestra que los gestores de datos, tanto los orientados a usuarios
finales, como los orientados a profesionales del desarrollo de sistemas de información sobre
bases de datos, dan una importancia grande a la creación asistida y visual de las partes
componentes de una interfaz de usuario de dichos sistemas.
Es por ello que comúnmente se les señala como ejemplos de tecnologías de cuarta
generación (T4G).
58
Capítulo 2
Por otra parte debe destacarse que estos módulos visuales, generalmente generan en
lenguajes propietarios de dichos SGBD, o en lenguajes afines a sus plataformas de
desarrollo.
2.4. Control de Concurrencia
La aplicación de bloqueos aparece generalmente en contextos negativos para ayudar a
proporcionar concurrencia a la base de datos. Frecuentemente se oye decir a las personas
que tienen problemas por la aplicación de bloqueos, pero rara vez se oye hablar acerca de
los beneficios positivos, que son muchos.
Access
En Access el control de concurrencia puede ser Compartido (Shared) o Exclusivo
(Exclusive) y se pueden bloquear todos los registros o solo el registro modificado. También
brinda la opción de no bloquear que es la que trae por defecto al igual que el bloqueo
Compartido. La ventana que se muestra a continuación muestra lo antes expuesto.
Figura 19. Ventana de opciones de control de concurrencia en Access.
Cuando se edita un registro, Access puede automáticamente bloquear ese registro para
evitar que otros usuarios lo cambien antes que la persona que lo está editando termine. Esta
propiedad de bloquear registros (RecordLock) solo se aplica a formularios, informes y
consultas. Como se expuso anteriormente ese campo puede tomar tres valores:
59
Capítulo 2
Sin bloquear. Este es el valor que trae por defecto. Es denominado también bloqueo
optimista. En los formularios dos o más usuarios pueden editar simultáneamente el
mismo registro. Si dos usuarios desean guardar cambios en el mismo registro aparecerá
un mensaje de error al que lo intentó en segundo lugar. Este usuario puede entonces
descartar el registro, copiarlo al Portapapeles o reemplazar los cambios hechos por el
otro usuario. En informes, los registros no se bloquean cuando se hace la vista
preliminar o se imprime el informe; y en las consultas, los registros no se bloquean
cuando se ejecuta la consulta.
Todos los registros. Se bloquean todos en la tabla o consulta base mientras el
formulario está abierto en la vista Formulario o la vista Hoja de datos, mientras se hace
vista preliminar o se imprime el informe, o mientras se ejecuta la consulta. Aunque los
usuarios pueden leer los registros, ninguno de ellos puede editar, agregar o eliminar
ningún registro hasta que se cierre el formulario, se finalice la impresión del informe, o
haya finalizado la ejecución de la consulta.
Registro Modificado. Este solo funciona en formularios y consultas. Una página de
registros se bloquea en cuanto cualquier usuario comienza a editar cualquier campo en
el registro y permanece bloqueada hasta que el usuario se mueve a otro registro.
Consecuentemente, un registro solo puede ser editado a la vez por un usuario. Esto se
denomina también bloqueo pesimista.
SQL Server
Sin la aplicación de bloqueos SQL Server no tendría un mecanismo para impedir que varios
usuarios actualizaran datos al mismo tiempo. Existen cuatro tipos o modos de bloqueo en
SQL Server:
Compartidos. Se puede poner un bloqueo compartido, también llamado de solo lectura
sobre datos que se están leyendo. Un bloqueo compartido permite que otros usuarios
lean sus datos pero impide que los modifiquen. Los bloqueos compartidos son
compatibles con otros bloqueos compartidos.
Exclusivos. Se puede usar un bloqueo exclusivo cuando se quiere modificar datos. Esto
impide que otros usuarios lean o modifiquen los datos sobre los que esté usted
trabajando hasta que libere el bloqueo. Estos no son compatibles con otros bloqueos.
60
Capítulo 2
De actualización. Un bloqueo de actualización se emplea de forma muy similar al
bloqueo exclusivo. Los bloqueos de actualización impiden interbloqueos; es decir, que
otros usuarios modifiquen los datos mientras se esté en el proceso de cambiar los datos.
De intención. Este tipo de bloqueo se utiliza sobre un objeto de nivel superior para
indicar que se va a poner un bloqueo (de los descritos anteriormente) dentro de ese
objeto.
Los bloqueos de actualización son necesarios cuando una consulta realiza dos fases para
modificar datos: una de búsqueda y otra de modificación, porque puede ocurrir que si se
usa un bloqueo compartido durante la fase de búsqueda, otro usuario también pueda
adquirir un bloqueo compartido sobre el mismo objeto. Cuando la transacción de búsqueda
pasa a modificar los datos, necesita un bloqueo exclusivo. Puede ser que la otra transacción
ya haya intentado u obtenido un bloqueo exclusivo por lo que SQL Server no nos permitirá
un bloqueo exclusivo. Por tanto, puede existir una situación de bloqueo o interbloqueo.
Para impedir esta situación se utiliza un bloqueo de actualización, el cual impide que otras
transacciones obtengan bloqueos exclusivos sobre el objeto al que se le esta aplicando un
bloqueo de actualización.(Waymire and Sawtell)
También hay diferentes niveles o tipos de objetos a los que se les pueden aplicar bloqueos:
RID. Un RID es un término para un bloqueo a nivel de fila. RID significa
identificador de fila. Cuando se aplica un bloqueo de este tipo se aplica solo a la
fila.
Clave. Es a nivel de fila pero se aplica dentro de un índice. El bloqueo de clave
bloqueará uno solo o varios valores de clave. Este tipo de bloqueo puede ayudar a
serializar transacciones dentro de un índice.
Página. Una página es una unidad de 8KB estándar en SQL Server. Un bloqueo de
página bloquea todo el contenido de una página, sin importar cuantas filas contenga.
Extensión. Este se adquiere cuando ya no hay más páginas disponibles para un
objeto particular y se deben añadir más datos. Indica que se está adquiriendo un
nuevo conjunto de ocho páginas para ese objeto.
61
Capítulo 2
Tabla. Se puede adquirir un bloqueo de tabla automáticamente por medio del
proceso de escalamiento o se puede solicitar explícitamente. Todas las páginas de la
tabla se bloquean como una unidad.
De intención. Un bloqueo de intención es una forma para indicar a nivel de tabla
que hay bloqueos de página o de fila o hacia una página que tiene bloqueos de fila.
A partir de SQL Server 7.0 el bloqueo es completamente dinámico. En versiones anteriores
lo predeterminado era la aplicación de bloqueos a nivel de página. Sin embargo, a partir de
la versión SQL Server 7.0 se decide cual tipo de bloqueo hay que aplicar cuando se
optimiza una consulta. Para selecciones que acceden una cantidad muy pequeña de datos,
inserciones, actualizaciones o eliminaciones, probablemente se aplicarán bloqueos a nivel
de fila y/o bloqueos de rango de claves. Para selecciones muy grandes puede ser más
eficiente usar bloqueos a nivel página o incluso a nivel tabla.(Waymire and Sawtell)
Oracle
Oracle se caracteriza por la lectura consistente lo cual lo demuestra de la siguiente forma.
Durante la ejecución de toda la transacción, las otras transacciones ven el contenido de la
base de datos congelado, con los valores que tenía al comienzo de la transacción, para
evitar el problema de resumen incorrecto.(Gómez, 2007)
La consistencia de lectura puede verse de tres maneras:
Lectura consistente implícita (nivel de instrucción): se mantiene dentro de la
instrucción SELECT…
Sin lectura consistente: SELECT… (se ve y modifica entre las dos consultas)
SELECT…
Lectura consistente explícita:
COMMIT; (inicia la transacción)
SET TRANSACTION READ ONLY; (debe ser la 1ª instrucción en la transacción)
SELECT count (*) from Persona;
SELECT count (*) from Maestría;
COMMIT; (termina la transacción de solo lectura)
62
Capítulo 2
Oracle posee aislamiento automático, es decir maneja las actualizaciones evitando
interferencias entre las transacciones. Existen dos modos de aislamiento:(Zeis et al., 2009)
Serializable: las transacciones no pierden actualizaciones, se garantizan las lecturas
repetibles, no hay registros fantasmas ni tampoco resumen incorrecto. Todo esto se
debe a que las modificaciones hechas por una transacción solo las puede ver dicha
transacción. En este modo si una transacción Ti actualiza algún recurso que actualizó
Tj y está sin confirmar, entonces Ti aborta.
Lectura consistente (Read Commited): La transacción no tiene lecturas repetibles.
Las modificaciones hechas por una transacción son visibles a todas las demás, solo si
se ha hecho COMMIT. Si una transacción necesita bloquear filas que tiene otra
transacción debe esperar.
Esto puede ralentizar las transacciones, por eso se usan bloqueos explícitos.
El bloqueo de datos garantiza la consistencia de estos (no permite cambios por otras
transacciones mientras se lee o actualiza), garantiza la integridad y se mantiene hasta un
commit o rollback o un desbloqueo explícito.(Gómez, 2007)
Este bloqueo se utiliza para controlar los accesos y actualizaciones concurrentes, reservar
una tabla para toda la transacción y las lecturas repetidas en bucles.
Los bloqueos de datos pueden ser automáticos (los pone el SGBD a nivel de fila) o
explícitos (los pone el programador) mediante la instrucción:
LOCK TABLE [TABLA] IN [TIPO] MODE [NOWAIT];
El tipo puede ser:
SHARE (S): lectura concurrente. Permite otros bloqueos de este tipo.
EXCLUSIVE (X): no permite ningún otro bloqueo.
Para la atomicidad Oracle usa un protocolo en dos fases.
63
Capítulo 2
2.5. Respaldo y Recuperación
Access
MS Access no cuenta con un respaldo y una recuperación adecuados. Solo es necesario
para hacer una copia de seguridad en Access que la base de datos esté cerrada y después
simplemente se copia el archivo hacia otra dirección con el mismo sistema que usa
Windows. La recuperación es igual solo necesitas abrir el archivo que se había guardado
pero teniendo en cuenta que si se utiliza la seguridad de nivel de usuario se recomienda
haber creado también una copia de seguridad del archivo de información de grupo de
trabajo. Si este archivo se daña o se pierde, no se podrá iniciar MS Access hasta que se
establezca o se reconstruya dicho archivo.
SQL Server
El componente para la realización de copias de seguridad y restauración de MS SQL Server
proporciona una importante protección para los datos decisivos almacenados en bases de
datos de SQL Server.
Con una planificación adecuada, se pueden recuperar muchos errores, incluidos:
Errores de medios.
Errores de usuarios.
Pérdida permanente de un servidor.
Además, la realización de copias de seguridad y la restauración de bases de datos resulta
útil para otros fines, como copiar una base de datos de un servidor a otro.
Se deben identificar los requisitos de disponibilidad de sus datos para poder elegir la
estrategia de copia de seguridad y restauración apropiada. La estrategia general de copia de
seguridad define el tipo y frecuencia de copias de seguridad y la naturaleza y velocidad del
hardware que requieren.
Para realizar una copia de seguridad es necesario realizar la copia de seguridad en un
medio, por ejemplo, cintas o discos. Se recomienda que el plan de copias de seguridad
incluya provisiones para administrar los medios.
64
Capítulo 2
Los tipos de copia de seguridad que admite SQL Server son:
Copia de seguridad completa de base de datos. Realiza una copia de seguridad de
toda la base de datos e incluye el registro de transacciones.
Copia de seguridad diferencial de base de datos. Se realiza entre las copias de
seguridad completas de base de datos. Ésta solo copia los cambios a partir de la
última copia completa realizada.
Copia de seguridad del registro de transacciones. Una secuencia de copias de
seguridad del registro proporciona una cadena continua de información acerca de
las transacciones para permitir la recuperación a partir de copias de seguridad de
bases de datos, de archivos o diferenciales.
Copia de seguridad de archivos y grupos de archivos. Utilice BACKUP para
realizar copias de seguridad de archivos de base de datos y grupos de archivos en
lugar de la base de datos completa cuando las restricciones de tiempo no permitan
realizar una copia de seguridad completa. Para realizar la copia de seguridad de un
archivo en lugar de la base de datos completa coloque, donde corresponda, los
procedimientos para asegurarse de que se realiza regularmente la copia de seguridad
de todos los archivos de la base de datos. Asimismo, se deben realizar copias de
seguridad separadas del registro de transacciones.
A continuación mostramos un ejemplo de cómo realizar una copia de seguridad completa
mediante código de la base de datos Maestría.
USE master
EXEC sp_adddumpdevice ´disk´ , ´Maestria_1´ , DISK = ´C:\Archivos de Programa\Microsoft
SQL Server\MSSQL\Backup\Maestria_1.dat´
BACKUP DATABASE Maestria TO Maestria_1
Ahora mostraremos una copia de seguridad del registro. USE master
EXEC sp_adddumpdevice ´disk´ , ´Maestria_1´ , DISK = ´C:\Archivos de Programa\Microsoft
SQL Server\MSSQL\Backup\Maestria_1.dat´
BACKUP LOG Maestria TO Maestria_1
Esto se puede hacer también desde el Enterprise Manager dando clic derecho sobre la base
de datos lo cual muestra el siguiente cuadro de diálogo:
65
Capítulo 2
Figura 20. Ventana de opciones de respaldo en SQL Server.
Se escoge el tipo de copia de seguridad más apropiado y se adiciona el camino donde se
quiere guardar. De esta forma es mucho más fácil.
Oracle
Oracle ofrece varios tipos de respaldo para la información; entre ellos no podemos escoger
el que sea más óptimo para todas las organizaciones, debido a que son muchos los factores
que inciden y se deben evaluar para determinar cual es el mejor procedimiento para
determinado escenario de recuperación. Cada método de respaldo cumple funciones
definidas, es por ello que se debe conocer muy bien la base de datos para determinar el
respaldo que se necesita.
Los métodos de Oracle son los siguientes:(Manriquez, 2007)
EXPORT/IMPORT: es de los más usados por su flexibilidad y portabilidad y solo se
puede hacer si la base de datos está abierta. Tiene una selectividad muy alta, se puede
respaldar desde una tabla de la base de datos hasta toda la información almacenada en
ella. Esta misma selectividad funciona al restaurar la información posteriormente. Un
archivo puede ser exportado de y desde cualquier SO que soporte Oracle 7 o superior y
66
Capítulo 2
ser importado en y desde cualquier SO con la ayuda de SQL*Net. Una vez hecha una
copia, al restaurar los datos se pueden relocalizar los objetos en otros tablespaces o si se
quiere se pueden cambiar sus parámetros de almacenamiento; también permite crear los
índices por separado acelerando el tiempo de la recuperación y cambiar de esquema los
objetos si quien los importa posee privilegios suficientes. Además permite recuperar
información perdida por errores de usuario o del servidor. Es imposible predecir el
tamaño que tendrá una copia de seguridad al igual que el tiempo que durará la misma,
lo mismo sucede para la recuperación.
Respaldos en frío (Cold Backup). Es muy restrictivo, y debe hacerse únicamente cuando
la base de datos esté cerrada. La consistencia de los datos está garantizada, incluye
todos los archivos necesarios, el espacio que ocupa es conocido, además el tiempo de
respaldo y recuperación es predecible. La desventaja de todo esto es que
obligatoriamente tienes que recuperar la base de datos entera aunque solo necesites o
hayas perdido una parte de ella.
Respaldos en caliente (Hot Backup). Son una consecuencia de una funcionalidad de
Oracle llamada el modo ARCHIVE. Este modo consiste en configurar algunos
parámetros de la base de datos para que se registren todos los cambios en unos archivos
llamados REDO LOGS. Oracle lleva un histórico del orden de los redo logs y por lo
tanto una secuencia de las transacciones realizadas a la base de datos y cuando hay
necesidad de restaurar información, lo hace consistentemente y deja la base de datos
como estaba hasta el momento en el cual las fallas ocurrieron o hasta el punto en el
tiempo que el cliente lo desee; esto se hace restaurando un cold backup y aplicando los
redo logs ocurridos a partir de ese backup hasta una fecha y hora determinada que se
necesite. Este tipo de respaldo no interfiere con la operación normal de la base de datos,
no hay necesidad de cerrarla y los usuarios pueden estar trabajando. Se puede recuperar
hasta cualquier punto en el tiempo y siempre recupera de manera consistente. Lo malo
de esta consistencia es que no permite hacer modificaciones, selecciones o
adecuaciones. Además es necesario mantener todos los redo logs archivados y para esto
se necesita espacio en disco y una administración cuidadosa.
67
Capítulo 2
2.6. Conclusiones Parciales
De todo lo analizado anteriormente sobre ciertas características de los gestores de datos
Access, SQL Server y Oracle se puede concluir con la siguiente tabla:
Tabla 5. Resumen de las características técnicas de los SGBD Access, SQL Server y Oracle
Característica analizada Access SQL Server Oracle
Lenguaje de Definición de Datos (DDL)
Creación de Tablas Bueno Bueno Bueno
Relaciones Muy Bueno Regular Bueno
Métodos de Indexado Bueno Bueno Bueno
Lenguaje de Manipulación de Datos (DML)
Consultas Muy Bueno Muy Bueno Muy Bueno
Procedimientos almacenados y Funciones No tiene Muy Bueno Muy Bueno
Informes y Formularios Muy Bueno Muy Bueno Bueno
Control de Concurrencia Bueno Muy Bueno Bueno
Respaldo y Recuperación Malo Bueno Muy Bueno
68
CAPÍTULO 3. CARACTERIZACIÓN
COMPARATIVA DEL SGDB-OR POSTGRESQL.
CAPÍTULO 3. CARACTERIZACIÓN COMPARATIVA DEL
SGDB-OR POSTGRESQL.
En este capítulo se analizarán las características vistas en el capítulo anterior en el
SGBDOR PostgreSQL y se dirán las ventajas y desventajas que este posee para así lograr el
principal objetivo de esta tesis, haber estudiado su completitud.
3.1. Lenguaje de Definición de Datos del PostgreSQL
3.1.1. Creación de Tablas
PostgreSQL normalmente almacena los datos de la tabla en bloques de 8KB. El número de
estos bloques es limitado a 32-bit dando esto un máximo a la tabla de 16TB. El tamaño del
bloque básico puede ser incrementado hasta 32KB, esto daría un límite teórico a la tabla de
64TB.
Algunos sistemas operativos imponen límites para evitar que archivos tan grandes sean
creados, entonces PostgreSQL almacena los datos de la tabla en múltiples archivos de 1GB
cada uno. Para tablas muy grandes el resultado será muchos archivos y una degradación
potencial del desempeño del sistema operativo.
PostgreSQL no impone un límite para el número de filas de una tabla ni para el número de
índices por tabla, aunque esto no evita que se degrade el desempeño si se crean muchos
índices en una tabla.
Además, PostgreSQL tiene un límite de 1GB para cada campo de la tabla. El máximo de
columnas depende del tamaño del bloque y del tipo de dato de la columna. Por defecto es
8KB, con esto pueden guardarse como máximo 250 columnas. Este número puede
aumentarse a 1600 columnas si todas tienen un tipo de dato simple, como un entero, por
ejemplo. Incrementando el tamaño del bloque se incrementan estos límites.
A continuación se muestran los tipos de datos que existen en PostgreSQL:
Boolean. Espera un valor verdadero. Puede ser TRUE, 't', 'true', 'y', 'yes' o '1'. Usa solo
un 1 byte de almacenamiento, puede ser NULL.
69
Capítulo 3
Smallint. Almacena números enteros, asigna solo 2 bytes para esto, puede almacenar
valores desde -32768 hasta 32767.
Integer. Almacena números enteros pero tiene capacidad para almacenar hasta 4 bytes,
tiene un rango de almacenamiento entre -2147483648 hasta 2147483647.
Bigint. Almacena también números enteros pero de hasta 8 bytes, da aproximadamente
18 dígitos de precisión.
Bit. Almacena solo 0 ó 1.
Bit varying. Almacena una cadena de bits.
Numeric (p, e). Almacena números de cualquier tipo, se le pasan como parámetros la
precisión y la escala. No hay límite para la precisión.
Real. Almacena 4 bytes, almacena datos aproximados.
Double precision. Almacena exactamente igual al real pero con una capacidad de
almacenamiento de 8 byte.
Money. Almacena solo datos monetarios, 4 bytes. No hace conversiones de monedas.
Timestamp. Almacena fechas y horas desde 4713 AC hasta 1465001 DC.
Interval. Almacena un intervalo de aproximadamente ±178000000 años.
Date. Almacena fechas desde 4713 AC hasta 32767 DC
Time. Almacena una hora del día, desde 0 hasta 23:59:59.99.
Char, character. Almacena un solo carácter.
Char (n). Almacena exactamente n caracteres, los cuales pueden ser rellenados con
espacios en blanco si los que hay almacenados son menos que el tamaño actual (n).
Character varying (n). Almacena un número variable de caracteres, como máximo n.
Text. Es una variante de character varying, en la que no se requiere especificar el
número máximo de caracteres.
Point. Almacena un valor de la forma (x, y).
Line. Almacena una línea (pto1, pto2).
Lseg. Almacena un segmento (pto1, pto2).
Path. Almacena una secuencia de puntos que pueden ser cerrados o abiertos.
Polygon. Almacena una secuencia de puntos que sean cerrados.
Circle. Almacena un punto y una longitud.
Serial. Es un autonumérico que se incrementa cada vez que se agrega una fila a la tabla.
70
Capítulo 3
Oid. Es un identificador de objeto. Internamente PostgreSQL adiciona por defecto un
oid para cada fila. No es recomendable usar este tipo de datos.
Cidr. Almacena una dirección de red de la forma x.x.x.x/y, donde y es la máscara de la
red.
Inet. Almacena una dirección de red, similar al cidr excepto que parte del host puede
ser cero.
Macaddr. Almacena una dirección MAC de la forma XX:XX:XX:XX:XX:XX.
También existen tipos de datos que son arreglos. De acuerdo a estos tipos de datos que no
proporciona PostgreSQL nos damos cuenta de que puede ser utilizado para crear sistemas
de información geográficos.
En el PostgreSQL se pueden generar las tablas a través de diferentes páginas interactivas
que te van guiando para la creación de las tablas. También da la oportunidad de generar un
archivo que puede tener extensión XML o XHTML 1.0 Transitional con el código SQL que
genera la creación de estas tablas mediante los formularios.
Por ejemplo este sería el contenido del archivo que genera la tabla Persona con extensión
XHTML (también admite salvarlo con extensión XML):
Table Reporte DDL - Persona
Generado: 05/05/2010 21:02:28 Servidor: PostgreSQL Database Server 8.2 (localhost: 5432) Base de Datos: Maestria Esquema: public
TableDDL -- Table: "Persona" -- DROP TABLE "Persona"; CREATE TABLE "Persona" (
ci text NOT NULL, nombre text, apellido1 text, apellido2 text, nacionalidad integer, email path, sexo integer, "fecha_Nac" date, telefono text,
71
Capítulo 3
"Direccion" text, "Est_Civil" integer, "año_Graduacion" integer, CONSTRAINT "Persona_pkey" PRIMARY KEY (ci), CONSTRAINT "Persona_Est_Civil_fkey" FOREIGN KEY ("Est_Civil") REFERENCES "Est_Civil" ("Id_EstCivil") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT "Persona_nacionalidad_fkey" FOREIGN KEY (nacionalidad) REFERENCES "Nacionalidad" ("IdNacionalidad") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT "Persona_sexo_fkey" FOREIGN KEY (sexo) REFERENCES "Sexo" ("IdSexo") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION
) WITHOUT OIDS; ALTER TABLE "Persona" OWNER TO postgres; Reporte generado por: pgAdmin
3.1.2. Relaciones
PostgreSQL no cuenta con un diagrama de relaciones por lo que para establecerlas se crean
las llaves foráneas a medida que se van creando las tablas, al igual que Oracle. Se puede
destacar que ofrece la eliminación y actualización en cascada, además de ofrecer
actualizaciones y eliminaciones restringidas. Estas dos son las más usadas. La opción
RESTRICT previene la eliminación de una fila referenciada. PostgreSQL trae por defecto
la opción NO ACTION, pero cuenta con dos opciones más, SET NULL y SET DEFAULT,
estas opciones significan poner a null o a un valor por defecto respectivamente las
columnas referenciadas cuando la fila referenciada es eliminada.
3.1.3. Métodos de Indexado
PostgreSQL crea automáticamente un índice para la llave primaria. Se pueden crear índices
adicionales para las tablas usando el comando SQL CREATE INDEX o a través de
diferentes páginas interactivas.
La opción UNIQUE especifica que el índice no tenga duplicados. Los índices en
PostgreSQL son por defecto del tipo B*Tree aunque además tiene otros tipos de
indexamiento como: hash, gist y gin. Cada índice usa un algoritmo diferente que es el más
apropiado a diferentes tipos de consultas.
72
Capítulo 3
Los índices hash pueden solo hacer comparaciones de igualdad simple. El Query Planner
considerara usar un índice hash siempre que la columna esté involucrada en una
comparación usando el operador =.
Pruebas realizadas por varios expertos han demostrado que los índices hash de PostgreSQL
no son mejores que los índices B*Tree, y el tamaño del índice y el tiempo de construcción
para estos es mucho peor que para los índices B*Tree. Además, los índices hash pueden
necesitar ser reconstruidos con el comando REINDEX después de una caída de la base de
datos. Por estas razones, el uso de los índices hash esta desahuciado.
Los índices gist no son un tipo simple de índice, sino una infraestructura dentro de la cual
diferentes estrategias de indexado pueden ser implementadas. De acuerdo con esto, los
operadores particulares de los índices gist pueden ser usados dependiendo de la estrategia
de indexado.
Los índices gin son índices invertidos los cuales pueden tener valores que contengan más
de una llave, arreglos por ejemplo. Al igual que los gist, los índices gin pueden soportar
diferentes estrategias de indexado definidas por los usuarios.
3.2. Lenguaje de Manipulación de Datos de PostgreSQL
3.2.1. Consultas
Para hacer una consulta en PostgreSQL lo hacemos creando un Script. El Script permite
realizar la consulta mediante un Editor SQL o mediante un Constructor Gráfico de
Consultas. A continuación se muestra como se ve el constructor gráfico de consultas con la
consulta utilizada anteriormente:
73
Capítulo 3
Figura 21. Constructor Gráfico de Consultas en PostgreSQL.
Ahora se puede ver el código SQL generado por el Constructor, este código se muestra en
el Editor SQL:
Figura 22. Código generado de la Consulta en el Editor SQL de PostgreSQL.
Si se crea la consulta mediante el Editor SQL no se logra que se genere la misma en el
Constructor Gráfico.
74
Capítulo 3
3.2.2. Procedimientos Almacenados y Funciones
Los procedimientos almacenados y funciones en PostgreSQL se pueden implementar en
tres lenguajes: PLPGSQL, C y un lenguaje interno de PostgreSQL. Al final de cada
procedimiento o función se debe poner en que lenguaje se implementó. El procedimiento
almacenado visto anteriormente en los otros gestores quedaría de la siguiente manera
utilizando el lenguaje propio de PostgreSQL, en este caso es una función puesto que
PostgreSQL no permite crear procedimientos almacenados sino son dentro de funciones o
disparadores (triggers).
Figura 23. Función generada en PostgreSQL.
PostgreSQL cuenta con diferentes tipos de funciones que a continuación se menciona:
Funciones agregadas de SQL
Funciones matemáticas
Funciones de cadena
Funciones trigonométricas
75
Capítulo 3
3.2.3. Formularios e Informes
Para crear formularios e informes en PostgreSQL se pueden utilizar varias herramientas. A
continuación se hablará sobre algunas de ellas.
Postgres Forms (PFM) es una aplicación cliente con una interfaz gráfica. Esta
implementada en Tcl/Tk, pero no es necesario tener conocimiento alguno de este lenguaje
para usar pfm, todo se hace con SQL. Necesita un paquete pgtcl o pgintcl para comunicarse
con el servidor de PostgreSQL, este paquete viene incluido en el paquete de instalación de
pfm. Esta aplicación es comerciada bajo licencia GPL.(Environment, 2010)
Rekall es una herramienta para extraer, mostrar y actualizar datos desde diferentes tipos de
gestores incluyendo PostgreSQL. Contiene un constructor visual de consultas y un
constructor de formularios para crear aplicaciones. Además usa el lenguaje de
programación Python para scripting, permitiendo que sean construidas aplicaciones muy
sofisticadas para las bases de datos. Tiene doble licencia, comercial y GPL. Para conectarse
al gestor usa un asistente. Crear formularios es muy fácil ya que se hace mediante un
asistente para formularios.(Matthew and Stones, 2005)
También existe una interfaz gráfica de usuario llamada Navicat que incluye un constructor
visual de consultas, un elaborador de informes, entre otras herramientas. Se dice que es el
producto número 1 en administración de bases de datos PostgreSQL, y es usado por varias
universidades y empresas importantes. Su licencia es comercial.(Dacosta, 2009)
No obstante es bueno destacar que las experiencias de uso de todas las herramientas antes
mencionadas no son muy bien acogidas en la bibliografía ni en foros de Internet, por lo que
aún es usual usar phpMyAdmin para la creación de formularios e informes para
PostgreSQL.
3.3. Control de Concurrencia
Las estrategias y mecanismos actuales requeridos para los bloqueos son muy complejos,
además son usados distintos tipos de bloqueos, dependiendo las circunstancias. PostgreSQL
cuenta con 8 tipos de permutaciones diferentes de bloqueos. También implementa un
mecanismo inusual para aislar transacciones mediante un modelo multiversión, el cual
76
Capítulo 3
reduce los conflictos entre bloqueos y mejora significativamente su desempeño comparado
con otros esquemas.
Afortunadamente, los usuarios de la base de datos generalmente necesitan preocuparse por
los bloqueos solo en dos circunstancias: para evitarlos y de los bloqueos explícitos para una
aplicación.
Cuando dos aplicaciones diferentes tratan de cambiar los mismos datos a la vez, ambas
sesiones se bloquean, y entonces ambas se quedan esperando una por la otra. Esta conducta
da una idea de cómo PostgreSQL tiene como valor predefinido un modo de Read
Commited que aísla la transacción. Existe un trade-off entre concurrencia, desempeño y
minimizar el número de bloqueos sostenidos de un lado, y consistencia y conducta ideal de
otro. Cuando se incrementa el nivel de aislamiento, el desempeño multiusuario de la base
de datos se degradará.
Como la conducta de la base de datos será mejor, el número de bloqueos requeridos se
incrementa, la concurrencia entre los distintos usuarios disminuye y entonces el desempeño
se degrada a través del nivel de aislamiento. Esto es muy desafortunado pero inevitable.
En general, si dos usuarios tratan de acceder a la misma fila, no hay un impacto real para
los usuarios, exceptuando que el segundo usuario debe esperar que termine el primer
usuario para poder completar su operación. Existe una concurrencia mucho más seria
cuando dos sesiones se bloquean una a la otra.
Por ejemplo, en nuestro caso de estudio cuando se conecten dos sesiones a la base de datos
y traten de ejecutar los siguientes comandos:
Sesión 1 Sesión 2
UPDATE Persona SET nombre = ´B´ WHERE folio = ´123456789´
UPDATE Persona SET nombre = ´C´ WHERE folio = ´234567891´
UPDATE Persona SET nombre = ´Beatriz´ WHERE folio = ´234567891´
UPDATE Persona SET nombre = ´Carlos´ WHERE folio = ´123456789´
77
Capítulo 3
Cuando algo como esto sucede ambas sesiones se bloquean y después de una pausa, en una
de las sesiones se encuentra un mensaje como este:
ERROR: deadlock detected
DETAIL: Process 2018 waits for ShareLock on transaction 2788; blocked by process 2017.
Process 2017 waits for ShareLock on transaction 2789; blocked by process 2018.
beatriz=>
La sesión en la que se muestre el error la actualización será cancelada y la otra continuará.
Es decir a la sesión en la cual apareció el mensaje del bloqueo se le hará un ROLLBACK y
los cambios se perderán. La otra sesión podrá continuar y ejecutar un COMMIT para hacer
los cambios en la base de datos permanentes (o un ROLLBACK para no guardar los
cambios).
A veces, nos podemos encontrar que el candado automático que PostgreSQL brinda no es
suficiente para nuestras necesidades. Quizás nosotros necesitemos un candado explícito
sobre algunas filas o a lo mejor sobre toda la tabla. Debemos evitar el bloqueo explícito
siempre que sea posible. El SQL estándar no define una manera de bloquear una tabla
completa. Esta opción es una extensión de PostgreSQL.
Es posible bloquear filas o tablas dentro de una transacción. Una vez que la transacción sea
completada, o con el comando COMMIT o con ROLLBACK, todos los bloqueos hechos
durante a transacción son liberados. No hay manera de liberar de forma explícita un
candado durante una transacción, por la simple razón de que si liberamos el candado sobre
una columna que está siendo cambiada durante la transacción, permitimos a otra aplicación
cambiarla, lo cual prevendría un ROLLBACK que deshace el cambio inicial.
La necesidad más común es bloquear varias filas antes de hacer cambios en ellas. Ésta
también puede ser una forma de evitar bloqueos. Para bloquear de antemano todas las filas
que el usuario sepa que va a cambiar, el usuario puede asegurar otras aplicaciones y así no
crear conflictos por los cambios.
Aunque en PostgreSQL se puedan bloquear tablas es recomendable evitarlo siempre que
sea posible. La sintaxis para bloquear tablas es la siguiente:
LOCK [TABLE] table-name
LOCK [TABLE] table-name IN [ ROW | ACCESS ] { SHARE | EXCLUSIVE } MODE
78
Capítulo 3
LOCK [TABLE] table-name IN SHARE ROW EXCLUSIVE MODE
Generalmente se utiliza la primera sentencia para bloquear una tabla que es lo mismo que si
pusiéramos:
LOCK TABLE table-name ACCESS EXCLUSIVE MODE
Esto impide a cualquier aplicación acceder a la tabla de forma alguna. Aunque es bastante
estricto, esta es probablemente la conducta que se desea en circunstancias difíciles como
cuando un bloqueo a nivel de tabla es requerido.
3.4. Respaldo y Recuperación
Aunque PostgreSQL acostumbra usar archivos ordinarios en su sistema de archivos para
almacenar sus datos, no es aconsejable confiar en los procedimientos de respaldo. Si la base
de datos está activa cuando las copias de los archivos de PostgreSQL fueron hechas, no se
puede asegurar que el estado interno de la base de datos será consistente con lo
almacenado. En teoría, podríamos apagar el servidor de la base de datos antes de copiar los
archivos, pero hay una mejor manera. PostgreSQL proporciona sus propios mecanismos de
respaldo y recuperación: pg_dump, pg_dumpall y pg_restore. Además, es posible hacer
backups directamente desde pgAdmin III.
Afortunadamente no son muchas las circunstancias en que podemos perder datos en
PostgreSQL. A continuación mostramos cuales son estas:
Caída del Cliente: PostgreSQL hará roll back a cualquier transacción que esté
ejecutándose para ese cliente.
Falla en la red del Cliente: PostgreSQL hará roll back a cualquier transacción que
esté ejecutándose para ese cliente.
Caída del servidor: PostgreSQL hará roll back a las transacciones incompletas
cuando el servidor se reinicie.
Caída del sistema operativo sin pérdida de datos: PostgreSQL hará roll back a las
transacciones incompletas cuando el servidor se reinicie.
Borrado accidental de la base de datos o de tablas: recuperación manual desde un
respaldo.
79
Capítulo 3
Borrado accidental de los archivos de PostgreSQL del sistema operativo:
recuperación manual desde un respaldo.
Fallo del disco u otro problema que corrompa los archivos de PostgreSQL:
recuperación manual desde un respaldo.
La forma más fácil de respaldar una base de datos es corriendo el comando pg_dump y
redireccionando su salida a un archivo. La sintaxis de este comando es muy simple:
pg_dump [nombre de la base de datos] [opciones]
Este comando produce como salida un largo script SQL que si se ejecuta vuelve a crear la
base de datos completamente. Por defecto, la salida del comando es un archivo texto que
contiene sentencias de la base de datos que fue respaldada.
Para poder recuperar la base de datos desde un backup se necesita correr el script. El script
contiene comandos para crear y llenar las tablas pero no contiene la creación de la base de
datos. Primero debemos crear la base de datos y entonces ejecutar el script. Asumiendo que
tenemos creada una base de datos vacía, podemos restaurar los datos desde la original
usando psql para ejecutar el script:
$ createdb postgres npostgres
$ psql postgres –d npostgres < postgres.bak
También podemos efectuar respaldos y recuperaciones desde pgAdmin III. Se puede hacer
esto de una manera muy simple. Para hacer un respaldo solo se necesita dar clic derecho
sobre la base de datos y seleccionar Resguardo (Backup) y aparece el siguiente cuadro de
diálogo.
80
Capítulo 3
Figura 24. Ventana de diálogo para resguardos en PostgreSQL.
Una vez que se haya seleccionado el nombre y el camino del archivo donde se va a
almacenar la base de datos, damos clic en OK y se nos crea un archivo con los datos de
nuestra base de datos.
A la hora de recuperar una base de datos desde pgAdmin III primero tenemos que crear una
nueva base de datos. Después de crearla simplemente volvemos a dar clic derecho sobre
ella y seleccionamos la opción Restaurar (Restore). A continuación aparece un cuadro de
diálogo como el que se muestra:
81
Capítulo 3
Figura 25. Ventana de diálogo para restaurar una base de datos en PostgreSQL.
Se le indica la dirección de donde se encuentra el archivo backup y se da clic en OK y con
esto ya se obtiene la base de datos recuperada.
3.5. Conclusiones Parciales
a) Sobre el Lenguaje de Definición de Datos del PostgreSQL
Al comparar el código que generan MS SQL Server y Oracle con el que genera
PostgreSQL nos damos cuenta de la gran similitud que existe entre ellos. Las diferencias
más notables se encuentran en que aunque nos referimos a la misma tabla no tienen los
mismos tipos de datos. Esto se debe a que no en todos los SGBD los tipos de datos tienen el
mismo nombre para el mismo tipo. Por ejemplo, al que en MS Access llamamos text, en
MS SQL Server concuerda con nvarchar, en Oracle con nvarchar2 y en PostgreSQL con el
character varying, que es el único que permite un número máximo de caracteres.
Además aunque no se vea en la tabla tomada como muestra se mencionó que PostgreSQL
tiene tipos de datos que son arreglos, es el único que cuenta con esta opción. Pero sin
embargo, en Oracle, aunque esto no define que sea un gestor objeto-relacional, se pueden
crear tipos de datos que sean objetos.
82
Capítulo 3
PostgreSQL no cuenta con la comodidad que brindan los diagramas de relaciones pero
Oracle tampoco lo hace, lo cual nos lleva a decir que no existe un diagrama de relaciones
debido a que estos dos gestores cuentan con tipos de datos que pueden ser objetos.
Mediante llaves foráneas se permite establecer dichas relaciones. No obstante, esto puede
considerarse como una debilidad, que pudiera quizá solucionarse con la definición de
diagramas de clases del tipo UML.
En cuanto a los métodos de indexado es, de los gestores que hemos analizado, el más
completo. Cuenta con un indexado automático para la llave principal y con diferentes tipos
de indexado, además al igual que Oracle tiene indexado invertido. Trae por defecto el
indexado B*Tree al igual que MS SQL Server y Oracle.
b) Sobre el Lenguaje de Manipulación de Datos de PostgreSQL
A la hora de crear consultas PostgreSQL tiene una pequeña deficiencia. Una característica
importante de los SGBD es que tanto si creamos las consultas de forma visual o si las
creamos mediante código, una genere a la otra. PostgreSQL no cuenta con esta
correspondencia, ya que la visual si genera el código pero el código no genera la forma
visual. Todos los demás gestores cumplían con esta característica, lo que en este aspecto los
hace mejores que el PostgreSQL.
En la creación de formularios e informes podemos destacar a Access que los permite crear
de forma fácil, pero también ya SQL Server trae una herramienta incluida a partir del SQL
Server 2005, aunque a SQL Server 2000 se le puede incluir ya que por la única razón que
no viene con la instalación es porque esta herramienta fue creada después. Oracle también
cuenta con módulos aparte para crear formularios e informes, la licencia de estos módulos
viene incluida con la instalación del Oracle aunque ellos se instalan aparte. Sin embargo,
PostgreSQL no cuenta con ninguna herramienta suya para la creación de los informes y
formularios, lo que más se acerca es la ya mencionada Navicat, por tanto esto es
considerado una deficiencia porque nos obliga a implementar los formularios e informes a
través de súper lenguajes o de herramientas que ni siquiera están en el mismo sitio que su
instalación, aunque al menos la mayoría de ellas tienen licencia GPL.
c) Sobre el Control de Concurrencia
83
Capítulo 3
MS Access cuenta con dos tipos de bloqueo, Exclusivo y Compartido, y puede no bloquear
absolutamente nada, bloquear todos los registros o solamente el registro que está siendo
modificado. MS SQL Server cuenta con cuatro tipos de bloqueo, los dos que tiene MS
Access y los bloqueos de intención y de actualización y permite bloquear una gran variedad
de objetos. Oracle, al igual que MS Access solo cuenta con los tipos de bloqueo
Compartido y Exclusivo. PostgreSQL también cuenta solo con estos dos tipos de bloqueo.
d) Sobre el Respaldo y Recuperación
Después de haber analizado como se comportan estos gestores a la hora de hacer un
respaldo y luego a la hora de recuperarse nos podemos dar cuenta que excluyendo a MS
Access, que en verdad no posee ninguna estrategia para copias de seguridad, todos los
demás gestores cuentan con buenas estrategias, sin dudas las mejores estrategias las posee
Oracle pero esto no significa que MS SQL Server y PostgreSQL no puedan recuperarse de
una falla. Las estrategias de los dos últimos antes mencionados pueden ser mejoradas pero
en ningún caso constituyen una deficiencia.
Tabla 6. Resumen de las características técnicas del SGBDOR PostgreSQL
Característica analizada PostgreSQL
Lenguaje de Definición de Datos (DDL)
Creación de tablas Muy Buena
Relaciones Muy Buena
Métodos de Indexado Muy Buena
Lenguaje de Manipulación de Datos (DML)
Consultas Buena
Procedimientos almacenados y funciones Muy Buena
Informes y Formularios No Tiene
Control de la Concurrencia Bueno
Respaldo y Recuperación Muy Buena
84
CONCLUSIONES Y RECOMENDACIONES
CONCLUSIONES
1. Se formalizaron y fundamentaron diferentes criterios de completitud para un
supuesto SGBD de factura nacional basado en PostgreSQL de acuerdo a la
investigación realizada en la literatura científica y criterios de expertos.
2. Se estudiaron en detalle los criterios de completitud en distintos gestores de bases
de datos (Access, SQL Server y Oracle), mediante un caso de estudio basado en el
Control de Maestrías, y se revelaron cuáles de estas características están mejor
implementadas o no, o ausentes en ellos, lo cual aparece resumido en la Tabla 5.
3. Se estudiaron en detalle estas características en el SGBDOR PostgreSQL, mediante
el mismo caso de estudio, y se revelaron cuáles de estas características están bien
implementadas o con cierta deficiencia en este gestor, lo cual se resume en la Tabla
6.
4. Se compararon estos gestores de acuerdo a las características consideradas
importantes, y se resaltaron las debilidades y potencialidades del PostgreSQL, entre
las que destaca una muy buena definición de tablas, índices, etc., pero ausencia de
posibilidades en cuanto a herramientas propias de desarrollo de formularios e
informes de forma amigable a un usuario final.
85
RECOMENDACIONES
1. Divulgar el estudio realizado con la presente investigación, sobre todo entre la
entidad encargada del desarrollo de un nuevo SGBD de factura nacional basada en
el PostgreSQL, para que se tome en consideración el mismo a fin de obtener un
buen producto que satisfaga las demandas de este tipo de software.
2. Desarrollar en el futuro otro estudio investigativo para revelar nuevas
características necesarias para un SGBD, dirigidas a dar solución a aplicaciones de
almacenes de datos, bases de datos deductivas, bases de datos geográficas o
espaciales, entre otras.
3. Proponer ampliar el estudio realizado a otros SGBD comercialmente reconocidos o
de estudio, sobre todo los que se mencionan en la literatura, como orientados a
objetos puros.
86
REFERENCIAS BIBLIOGRÁFICAS
REFERENCIAS BIBLIOGRÁFICAS
(2010) SQL Server Reporting Services.
BALTER, A. (2007) Mastering Microsoft Office Access 2007 development.
BUXTON, S., NADEAU, T. P., FRYMAN, L., O´NEIL, B., HARTMUT, R., O´NEIL, E.,
HALPIN, T., O´NEIL, P., HARRINGTON, J. L., SCHNEIDER, M., INMON, W.
H., SIMSION, G., LIGHTSTONE, S. S., TEOREY, T. J., MELTON, J., WITT, G.
& MORGAN, T. (2009a) Database Design Know It All.
BUXTON, S., NADEAU, T. P., FRYMAN, L., O´NEIL, B., HARTMUT, R., O´NEIL, E.,
HALPIN, T., O´NEIL, P., HARRINGTON, J. L., SCHNEIDER, M., INMON, W.
H., SIMSION, G., LIGHTSTONE, S. S., TEOREY, T. J., MELTON, J., WITT, G.
& MORGAN, T. (2009b) Database Design Know It All.
BUXTON, S., NADEAU, T. P., FRYMAN, L., O´NEIL, B., HARTMUT, R., O´NEIL, E.,
HALPIN, T., O´NEIL, P., HARRINGTON, J. L., SCHNEIDER, M., INMON, W.
H., SIMSION, G., LIGHTSTONE, S. S., TEOREY, T. J., MELTON, J., WITT, G.
& MORGAN, T. (2009c) Database Design Know It All.
CONNOLLY, T. M. & BEGG, C. E. (2005a) Sistemas de Bases de Datos, Madrid,
Pearson.
CONNOLLY, T. M. & BEGG, C. E. (2005b) Sistemas de Bases de Datos.
DACOSTA, M. (2009) Navicat - Cliente MySQL, PostgreSQL y Oracle.
DATE, C. J. (2001a) Introducción a los sistemas de bases de datos.
ELMARSI, R. & NAVATHE, S. B. (2007a) Fundamentals of Database Systems
ELMARSI, R. & NAVATHE, S. B. (2007b) Fundamentals Database.
ELMARSI, R. & NAVATHE, S. B. (2007c) Fundamentals of Database.
ELMARSI, R. & NAVATHE, S. B. (2007d) Fundamentals of Database.
ELMASRI, R. & NAVATHE, S. B. (1997) Fundamentals of Database Systems, Delaware,
Addison-Wesley Iberoamericana.
ENVIRONMENT, G. C. D. (2010) Welcome to the Postgres Forms (pfm) Project Home
Page.
87
GÓMEZ, H. (2007) Transacciones y Control de Concurrencia. Bases de Datos.
GROH, M. R., STOCKMAN, J. C., POWELL, G., PRAGUE, C. N., IRWIN, M. R. &
REARDON, J. (2007) Access 2007 Bible, Indianapolis.
HOTEK, M. (2008) Microsoft SQL Server 2008 Step by Step. Microsoft Press.
MANRIQUEZ, F. (2007) ORACLE: Backup and Recovery. PC Actual. Barcelona.
MATTHEW, N. & STONES, R. (2005) Beginning Databases with PostgreSQL: From
Novice to Professional, .
RAMAKRISHNAN, R. & GEHRKE, J. (2007a) Database Management Systems.
RAMAKRISHNAN, R. & GEHRKE, J. (2007b) Database Management Systems.
SUMATHI, S. & ESAKKIRAJAN, S. (2007a) Fundamentals of Relational Database
Management Systems.
SUMATHI, S. & ESAKKIRAJAN, S. (2007b) Fundamentals of RDBMS.
SUMATHI, S. & ESAKKIRAJAN, S. (2007c) Fundamentals of RDBMS.
SUMATHI, S. & ESAKKIRAJAN, S. (2007d) Fundamentals of RDBMS.
TURLEY, P., SILVA, T., SSMITH, B. C. & WITHEE, K. (2009) Professional Microsoft
SQL Server 2008
Reporting Services, Indianapolis.
WAYMIRE, R. & SAWTELL, R. Aprendiendo Microsoft SQL Server 7.0 en 21 días.
ZEIS, C., RUEL, C. & WESSLER, M. (2009) Oracle 11g For Dummies, Indianapolis.
88
BIBLIOGRAFÍA
BIBLIOGRAFÍA
1. Balter’s, A. “Mastering Microsoft Office Access 2007 Development”. Sams Publishing.
USA. 2007.
2. Bagui, S. & Earp, R. “Database Design Using Entity-Relationship Diagrams”.
Auerbach Publications. An Ebook Library. 2003.
3. Ben Natan, R. “How To Secure and Audit Oracle 10g and 11g”. CRC Press. Auerbach
Publications. USA. 2009.
4. Buxton, S., et al. “Database Design. Know It All”. Morgan Kaufmann Publishers.
USA.2009.
5. Carpenter, L. et al. “Oracle Data Guard 11g Handbook”. Oracle Press-McGraw-Hill.
USA. 2009.
6. Chaudhri, A. “Java & Databases”. Hermes Penton Ltd. Great Britain. 2002.
7. Connolly, T. M.; Begg, C. E. “Sistemas de bases de datos. Un enfoque práctico para
diseño, implementación y gestión”. Addison Wesley. Cuarta edición. España. 2005.
8. Dacosta, M. (2009) Navicat - Cliente MySQL, PostgreSQL y Oracle.
www.dacostabalboa.com/es/navicat-cliente-mysql-postgresql-y-oracle/4722.
9. Date, C.J. “An introduction to database systems”. Addison Wesley. Eighth Edition.
USA. 2004.
10. Date, C.J. “SQL and Relational Theory”. O'Reilly Media, Inc. USA. 2009.
11. DuBois, P. “MySQL”. Addison-Wesley. Pearson Education, Inc. Fourth Edition. USA.
2009.
12. Elmasri, R. & Navathe, Sh. B. “Fundamentals of Database Systems. Addison Wesley.
5th Edition. USA. 2007.
13. Environment, G. C. D. (2010) Welcome to the Postgres Forms (pfm) Project Home
Page. http://pfm.projects.postgresql.org.
14. Gómez, H. (2007) Transacciones y Control de Concurrencia. Bases de Datos.
89
15. Goodson, J. & Steward, R.A. “The Data Access Handbook. Achieving Optimal
Database Application Performance and Scalability”. Prentice Hall. Pearson Education,
Inc. USA. 2009.
16. Groh, M., et al. “Access 2007 Bible”. Wiley Publishing, Inc. USA. 2007.
17. Hansen G.W., y Hansen J.V. “Diseño y Administración de Bases de Datos”. Prentice
Hall. 2ª edición. España. 1997.
18. Harrington, J.L. “Relational database design and implementation”. Morgan Kaufmann
Publishers. 3rd ed. USA. 2009.
19. Hotek, M. “Microsoft® SQL Server 2008 Step by Step”. Microsoft Press. USA. 2008.
20. Johnson, E. & Jones, J. “A Developer’s Guide to Data Modeling for SQL Server.
Covering SQL Server 2005 and 2008”. Addison-Wesley. USA. 2008.
21. Korol, J. “Access 2007 Programming by Example with VBA, XML, and ASP”.
Wordware Publishing, Inc. USA. 2008.
22. Lambert, S., et al. “Office Access 2007 Step by Step”. Microsoft Press. USA. 2007.
23. Larson, B. “Delivering Business intelligence with Microsoft SQL Server 2008”.
McGraw-Hill. USA. 2009.
24. Mageeand, J. & Kramer, J. “Concurrency: State Models & Java Programs”. John Wiley
& Sons. 2nd Edition. USA. 2006.
25. Manriquez, F. (2007) ORACLE: Backup and Recovery. PC Actual. Barcelona.
26. Matthew, N. & Stones, R. “Beginning Databases with PostgreSQL”. Apress. Second
Edition. USA. 2005.
27. McFedries, P. “Microsoft Office Access 2007 Forms, Reports, and Queries”. QUE.
USA. 2007.
28. Piattini, M. & Díaz, O. “Advanced Database Technology and Design”. Artech House.
Great Britain. 2000.
29. Powell, G. “Beginning Database Design”. Wiley Publishing, Inc. USA. 2006.
30. Ramakrishnan, R. & Gehrke, J. “Database Management Systems”. McGraw Hill.
Second Edition. USA. 2007.
90
31. Revesz, P. “Introduction to Databases. From Biological to Spatio-Temporal”. Springer-
Verlag. Great Britain. 2010.
32. Riordan, R. M., “Diseño de bases de datos relacionales con Access y SQL Server”.
McGraw-Hill. España. 2000.
33. Rosenzweig, B. & Rakhimov, E. S. “Oracle PL/SQL by example“. Addison-Wesley.
Pearson Education, Inc. Fourth Edition. USA. 2009.
34. Rowe, Jeff. “Creación de Servidores de Bases de Datos para Internet con CGI”.
Prentice Hall. 1ª edición. México. 1996.
35. Siau, K. & Ericsson, J. “Advanced Principles for Improving Database Design, Systems
Modeling, and Software Development”. Information Science Referente. USA. 2009.
36. Simsion, G.C. & UIT, G.C. “Data Modeling Essentials”. Morgan Kaufmann Publishers.
Third Edition. USA. 2005.
37. Sumathi, S. & Esakkirajan, S. “Fundamentals of Relational Database Management
Systems”. Springer. USA. 2007.
38. Teorey, T. et al. “Database Modeling & Design: Logical Design”. Morgan Kaufmann
Publishers. Fourth Edition. USA. 2006.
39. Turley, P., et al. “Microsoft SQL Server 2008 Reporting Services”. Wiley Publishing,
Inc. USA. 2008.
40. van der Lans, R. F. “SQL for MySQL developers : a comprehensive tutorial and
reference”. Addison-Wesley. Pearson Education, Inc. USA. 2007.
41. Waymire, R. & Sawtell, R. Aprendiendo Microsoft SQL Server 7.0 en 21 días
42. Zeis, Ch., et al. “Oracle 11g For Dummies”. Wiley Publishing, Inc. USA. 2009.
43. (2010) SQL Server Reporting Services. http://msdn.microsoft.com/en-
us/library/ms159253(SQL.90).aspx.
91
ANEXOS
ANEXOS
Anexo 1. Control de redundancia
En la creación tradicional de programas con procesamiento de archivos, cada grupo de
usuarios mantiene sus propios archivos para manejar sus aplicaciones de procesamiento de
datos. Por ejemplo, en nuestro caso de estudio un profesor puede ser al mismo tiempo un
estudiante. Con esto una buena parte de los datos se almacenaría dos veces: una vez como
estudiante y otra como profesor. La redundancia en el almacenamiento de los datos provoca
varios problemas. En primer lugar, es necesario realizar una misma actualización lógica
varias veces, esto implica una duplicación del trabajo. En segundo lugar, se desperdicia
espacio de almacenamiento al guardar los mismos datos en varios lugares, y este problema
puede ser grave si las bases de datos son grandes. En tercer lugar es posible que los
archivos que representan los mismos datos se tornen inconsistentes, quizás porque una
actualización se haya aplicado a ciertos archivos y a otros no.
Para conservar la consistencia, debe crearse un diseño que almacene cada dato lógico-como
el nombre o la fecha de nacimiento de un estudiante que al mismo tiempo sea profesor-en
un solo lugar de la base de datos. Ello evita la inconsistencia y ahorra espacio de
almacenamiento. En algunos casos puede convenir la redundancia controlada.
Anexo 2. Restricción de los accesos no autorizados
Cuando muchos usuarios comparten una misma base de datos es probable que no todos
tengan la autorización para tener acceso a toda la información que contiene. Por ejemplo,
por lo general los datos financieros son confidenciales y solo ciertas personas pueden tener
acceso a ellos. Además, es posible que solo algunos usuarios tengan permitido recuperar
datos, en tanto que a otros se les permita obtenerlos y actualizarlos. Por tanto, también es
preciso controlar el tipo de las operaciones de acceso (obtención o actualización). Por lo
regular, a los usuarios o grupos de usuarios se les asignan números de cuenta protegidos
con contraseñas, mismos que sirven para tener acceso a la base de datos. El SGBD debe
contar con un subsistema de seguridad y autorización que permita al DBA crear cuentas y
especificar restricciones para ellas. El SGBD deberá entonces obligar automáticamente al
cumplimiento de dichas restricciones. Este mismo tipo de controles se puede aplicar al
software del SGBD. Por ejemplo, solo el personal del DBA (Administrador de la Base de
Datos) tendrá autorización para utilizar cierto software privilegiado, como el que sirve para
crear cuentas nuevas. De manera similar, podemos hacer que los usuarios paramétricos solo
puedan tener acceso a la base de datos a través de las transacciones programadas que
expresamente fueron creadas para ellos.
La seguridad de las bases de datos es un área muy amplia que abarca varios temas, entre
ellos los siguientes:
Cuestiones éticas y legales relativas al derecho a tener acceso a cierta información.
Es posible que parte de esta se considere privada y que las personas no autorizadas
no puedan tener acceso a ella legalmente. En algunos países existen leyes sobre la
seguridad confidencial de la información.
Cuestiones políticas en el nivel gubernamental, institucional o corporativo,
relacionadas con las clases de información que no deben estar disponibles para el
público; por ejemplo, clasificaciones de créditos y expedientes médicos personales.
Cuestiones sistémicas, como los niveles del sistema en los que deben manejarse las
diversas funciones de seguridad; por ejemplo, el nivel del hardware físico, el nivel
del sistema operativo o el nivel del SGBD.
La necesidad en algunas organizaciones de identificar múltiples niveles de
seguridad y de clasificar los datos y los usuarios según estos niveles; por ejemplo,
secreto máximo, secreto confidencial y no clasificado. La política de seguridad de la
organización relacionada con el permiso para tener acceso a las diversas
clasificaciones de los datos que se debe hacer cumplir.
Por lo regular, un SGBD cuenta con un subsistema de seguridad y autorización de la base
de datos que se encarga de garantizar la seguridad de porciones de la base de datos contra el
acceso no autorizado. Se habla de dos tipos de mecanismos de seguridad en la base de
datos:
Los mecanismos de seguridad discrecionales se usan para otorgar privilegios a los
usuarios, incluida la capacidad de tener acceso a archivos, registros o campos de
datos específicos en un determinado modo (lectura, escritura o actualización).
Los mecanismos de seguridad obligatorios sirven para imponer seguridad de
múltiples niveles clasificando los datos y los usuarios en varias clases de seguridad
e implementando después la política de seguridad apropiada de la organización. Por
ejemplo, una política seguridad común consiste en permitir a los usuarios de un
cierto nivel de clasificación ver solo los elementos de información clasificados en el
mismo nivel que el usuario (o en un nivel inferior).
Otro problema de seguridad es el de evitar que personas no autorizadas tengan acceso al
sistema, ya sea para obtener información o para efectuar cambios mal intencionados en una
porción de la base de datos. El mecanismo de seguridad de un SGBD debe incluir formas
de restringir el acceso al sistema como un todo. Esta función se denomina control de acceso
y se pone en práctica creando cuentas de usuarios y contraseñas para que el SGBD controle
el proceso de entrada al sistema.
También es necesario controlar el acceso a una base de datos estadística, la cual sirve para
proporcionar información estadística o resúmenes de valores a partir de diversos criterios.
Los usuarios de las bases de datos estadísticas, como los de gubernamentales o de
investigación de mercado, están autorizados para usarlas para obtener información
estadística sobre la población, pero no para tener acceso a información confidencial
detallada sobre individuos específicos. La seguridad en las bases de datos estadísticas debe
cuidar que la información sobre individuos no sea accesible. En ocasiones es posible
deducir ciertos hechos relativos a los individuos a partir de consultas en las que intervienen
solo datos sinópticos de grupos, así que tampoco esto debe permitirse.
Otra técnica de seguridad es el cifrado de datos, que sirve para proteger datos
confidenciales que se transmiten por satélite o por algún otro tipo de red de
comunicaciones. Así mismo, el cifrado puede proveer protección adicional a secciones
confidenciales de una base de datos. Los datos se codifican mediante algún algoritmo de
codificación. Un usuario no autorizado que tenga acceso a datos codificados tendrá
problemas para descifrarlos, pero un usuario autorizado contará con los algoritmos de
descodificación o descifrado para descifrarlos. Se han creado técnicas de cifrado que son
muy difíciles de descifrar sin la clave, éstas se utilizan en aplicaciones militares.
Anexo 3. Almacenamiento persistente de objetos y estructuras de datos de programas
Esta es una de las principales razones de que se hayan creado los SGBD orientados a
objetos. Es común que los lenguajes de programación cuenten con estructuras de datos
complejas. Los valores de las variables de un programa se desechan una vez que este
termina, a menos que el programador explícitamente los almacene en archivos
permanentes; para ello, suele requerirse la conversión de esas estructuras complejas a un
formato adecuado para su almacenamiento en archivos. Cuando hay que leer otra vez estos
datos, el programador debe convertirlos del formato de archivos a la estructura de variables
del programa. Los sistemas de bases de datos orientados a objetos son compatibles con
lenguajes de programación del tipo C++ y el software del SGBD realiza automáticamente
las conversiones necesarias. Se dice que los objetos de este tipo son persistentes porque
sobreviven cuando termina la ejecución del programa y después se pueden recuperar
directamente mediante otro programa en C++.
Anexo 4. Inferencias en la base de datos mediante reglas de deducción
Otra aplicación consiste en ofrecer recursos para definir reglas de deducción que permitan
deducir o inferir información nueva a partir de los datos almacenados. A estos sistemas se
les conoce como bases de datos deductivas.
En un sistema de bases de datos deductivas por lo general se usa un lenguaje declarativo
para especificar reglas. Como lenguaje declarativo entendemos un lenguaje que define lo
que un programa desea lograr, en vez de especificar los detalles de cómo lograrlo. Una
máquina de inferencia o mecanismo de deducción dentro del sistema puede deducir hechos
nuevos a partir de la base de datos interpretando dichas reglas.
Una base de datos deductiva utiliza principalmente dos tipos de especificaciones: hechos y
reglas. Los hechos especifican de manera similar a como se especifican las relaciones,
excepto que no es necesario incluir los nombres de los atributos. Las reglas se parecen un
poco a las vistas relacionales. Especifican relaciones virtuales que no están almacenadas
realmente, pero que se pueden formar a partir de los hechos aplicando mecanismos de
inferencia basado en las especificaciones de las reglas. La principal diferencia entre las
reglas y las vistas es que en las primeras puede haber recursión y por tanto pueden producir
vistas que no es posible definir en términos de las vistas relacionales estándar.
Existen dos alternativas para interpretar el significado teórico de las reglas: por la teoría de
demostraciones y por la teoría de modelos. En los sistemas prácticos, el mecanismo de
inferencia que tiene el sistema define la interpretación exacta, que pudiera no coincidir con
ninguna de las dos interpretaciones teóricas. El mecanismo de inferencia es un
procedimiento computacional y por tanto provee una interpretación computacional del
significado de las reglas.
En la interpretación por la teoría de la demostración se consideran los hechos y las reglas
como enunciados verdaderos, o axiomas. Los axiomas base no contienen variables. Los
hechos son axiomas base que se dan por ciertos. Las reglas se denominan axiomas
deductivos, ya que pueden servir para deducir nuevos hechos. Con los axiomas deductivos
podemos construir demostraciones que deriven hechos nuevos a partir de los ya existentes.
La interpretación por la teoría de demostraciones nos ofrece un enfoque por procedimientos
o computacional para calcular una respuesta a una consulta. Al proceso de demostrar si un
determinado hecho (teorema) se cumple se le conoce también como demostración de
teoremas.
La interpretación por la teoría de modelos consiste en dado un dominio finito o infinito
(suele escogerse finito y es llamado universo de Herbrand) de valores constantes,
asignamos a un predicado todas las combinaciones posibles de valores como argumentos.
Después debemos determinar si el predicado es verdadero o falso. En general, basta con
especificar las combinaciones de argumentos que hacen que el predicado sea verdadero, y
decir que todas las demás combinaciones hacen que sea falso. Si esto se hace con todos los
predicados, hablamos entonces de una interpretación del conjunto de predicados.
A una interpretación se le llama modelo para un conjunto especifico de reglas si esas reglas
siempre se cumplen en esa interpretación; es decir, para cualquiera valores que se asignen a
las variables de las reglas, la cabeza de las reglas es verdadera cuando sustituimos los
valores de verdad asignados a los predicados en el cuerpo de la regla según esa
interpretación. De esta forma, siempre que se aplica una sustitución (enlace) a las variables
de las reglas, si todos los predicados del cuerpo de una regla son verdaderos en esa
interpretación, el predicado de la cabeza de la regla también debe ser verdadero.
En el enfoque según la teoría de modelos, el significado de las reglas se establece
proporcionando un modelo para dichas reglas. Podemos considerar que la cabeza de una
regla es una consulta definida en su cuerpo (predicados de RHS). El resultado de la
consulta es el conjunto de valores (enlazados para los argumentos de los predicados) que
por definición hacen que el predicado sea verdadero.
Se dice que un modelo es un modelo mínimo para un conjunto de reglas si no es posible
cambiar ningún hecho de verdadero a falso y seguir teniendo un modelo para esas reglas.
En general, el modelo mínimo que corresponde a un conjunto dado de hechos en la
interpretación por la teoría de modelos debe ser lo mismo que los hechos generados por la
interpretación según la teoría de demostraciones para el mismo conjunto original de
axiomas base y deductivos. Sin embargo, esto solo es cierto para reglas con una estructura
simple. Si permitimos la negación en la especificación de las reglas, la correspondencia
entre las interpretaciones deja de cumplirse. De hecho, con la negación son posibles
muchos modelos mínimos para un conjunto dado de hechos.
Un tercer enfoque para interpretar el significado de las reglas implica definir un mecanismo
de inferencia que el sistema utilice para deducir hechos a partir de las reglas. Este
mecanismo definiría una interpretación computacional del significado de las reglas.
Existen diferentes tipos de mecanismos de inferencia computacional, aquí solo hablaremos
de los dos principales que se basan en la interpretación de reglas por la teoría de las
demostraciones. Estos son los mecanismos de inferencia ascendente y de inferencia
descendente.
En la inferencia ascendente, también conocida como encadenamiento hacia delante y
resolución ascendente, la máquina de inferencia parte de los hechos y aplica las reglas para
generar hechos nuevos. Al generarse estos, se comparan con el predicado que es el objetivo
de la consulta para ver si coinciden. El término encadenamiento hacia delante indica que la
inferencia avanza de los hechos hacia el objetivo.
En el enfoque ascendente conviene usar una estrategia de búsqueda para generar solo los
hechos que sean pertinentes a una consulta; de lo contrario, se generarán todos los hechos
posibles en algún orden que nada tiene que ver con la consulta en cuestión, cosa que puede
ser muy ineficiente si los conjuntos de reglas y hechos son grandes.
La inferencia descendente, también conocida como encadenamiento hacia atrás y
resolución descendente, parte del predicado que es el objetivo de la consulta e intenta
encontrar coincidencias con las variables que conduzcan a hechos validos de la base de
datos. El término encadenamiento hacia atrás indica que la inferencia retrocede desde el
objetivo buscado para determinar hechos que lo satisfagan. En este enfoque no se genera
explícitamente los hechos, como en el encadenamiento hacia delante.
El mecanismo descendente de primero en profundidad da pie a ciertos problemas debido a
su dependencia respecto al orden en que se escriben las reglas para definir un predicado de
manera recursiva en donde hay que escribir los subobjetivos en el orden en que se muestran
para que no haya una recursividad infinita durante el proceso de inferencia.
Anexo 5. Cumplimiento de las restricciones de integridad
La mayor parte de las aplicaciones de base de datos tienen ciertas restricciones de
integridad que deben cumplir los datos. El SGBD debe ofrecer recursos para definir tales
restricciones y hacer que se cumplan. La forma más simple de restringir la integridad
consiste en especificar un tipo de datos para cada elemento de información. Otro tipo de
restricción que encontramos a menudo implica especificar que un registro de un archivo
debe relacionarse con registros de otros archivos. Otra restricción especifica que los valores
de los elementos de información sean únicos. Estas restricciones se derivan de la semántica
de los datos y del mini-mundo que representa. Es responsabilidad de los diseñadores de la
base de datos identificar las restricciones de integridad durante el diseño. Algunas
restricciones se pueden especificar en el SGBD, el cual hará que se cumplan
automáticamente; otras pueden requerir verificación mediante programas de actualización o
en el momento en que se introducen los datos.
Es posible introducir erróneamente un dato sin violar las restricciones de integridad. Este
tipo de errores solo puede descubrirse manualmente y corregirse después actualizando la
base de datos.