Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Introducción
Esta serie de seis laboratorios de Administración de Base de Datos (ABD) son un punto de partida para conocer
a detalle las prestaciones ofrecidas por el sistema PostgreSQL, este es un sistema de base de datos objeto-
relacional que tiene las características de los sistemas de base de datos propietarios tradicionales. PostgreSQL
es libre y el código fuente completo está disponible. Esta última característica es la más atractiva para desarrollar
aplicaciones empresariales para el mercado latinoamericano, ya que evita el pago de costosas licencias. El
software y la documentación se ofrecen bajo la licencia PostgreSQL (http://www.postgresql.org/about/licence/),
la cual es similar a las licencias BSD o MIT. Los laboratorios se han diseñado para proporcionar los conceptos y la
experiencia necesarios para conocer detalladamente el sistema, se aprovecha la función de "copiar y pegar" que
nos ofrece el sistema operativo Windows para disminuir el esfuerzo del lector en la preparación del ambiente de
trabajo y en la solución de los problemas.
En la sección denominada "trabajo adicional" se requiere que el lector aplique la experiencia obtenida en la
solución de problemas relacionados con el tema central del laboratorio. La sección de conceptos básicos muestra
la sintaxis de los comandos y da algunas explicaciones del uso de los mismos. Este material ha sido tomado del
Manual de usuario del sistema PostgreSQL el cual está disponible en la página oficial de la herramienta, en
algunos casos se ha tomado del sitio oficial en Español. Los conceptos básicos se aplican en torno a un proyecto
que se denomina "Universidad ACME", el cual es producto de la imaginación del autor, así como la solución
práctica de los problemas planteados. Los libros que se ofrecen en la sección de referencias, sirven como consulta
para apoyar algunos de los conceptos que se aplican en la solución práctica de problemas de administración de
base de datos.
Estos laboratorios se han preparado para procurar una experiencia práctica a los estudiantes de la materia
Administración de Base de Datos de la Licenciatura en Sistemas Computacionales que se ofrece en la Facultad
de Contaduría Pública (FCP) del Campus IV de la Universidad Autónoma de Chiapas (UNACH). En la FCP tenemos
al menos 14 años de experiencia en el uso de PostgreSQL en las aulas, proyectos de investigación y en sistemas
que se han implementado para la automatización de las actividades cotidianas de la FCP. Como producto de esa
experiencia académica e industrial se han obtenido estos laboratorios que se usan en las aulas para capacitar a
nuestros estudiantes. Hemos encontrado que los estudiantes se motivan al estudio cuando se concretan en estos
ejercicios las ideas abstractas que se explican en las aulas, aunque ese será tema de otro artículo. También se
tiene noticia de que son una fuente de consulta para egresados que laboran en el sector empresarial.
Prerrequisitos
Se espera que el lector tenga experiencia previa en el uso y conversión de diagramas Entidad-Relación (E-R), los
temas asociados al Diseño de Base de Datos no se cubren en este documento. También se espera que el usuario
tenga conocimientos básicos del lenguaje de programación denominado SQL.
Es necesario instalar la base de datos PostgreSQL versión 9.3 sobre el sistema operativo Windows, verifique los
requerimientos para instalación en la página oficial de la herramienta: www. postgresql.org. El sistema puede
descargarse del sitio Web:
http://www.enterprisedb.com/products-services-training/pgdownload#windows
1. Proyecto a desarrollar
El ejercicio consiste en un proyecto que describe el problema de una empresa dedicada a la prestación de
servicios educativos: después de leer el texto se genera el diagrama E-R con la solución a este problema, se
continúa con la creación de las tablas y población de las tablas, para finalmente trabajar con los permisos de
grupos y usuarios.
Los docentes de la UACME, son los únicos a los que se les permite impartir estos cursos, por los cuales reciben
un pago adicional, se les paga de acuerdo con un tabulador que indica el costo de la hora de estos cursos de
acuerdo al nivel académico del docente. El pago se genera a partir del alta del curso y sólo se permite expedir un
cheque por cada curso. Además, los estudiantes deben acudir a pagar adicionalmente al costo del semestre por
asistir a ellos.
2. Conceptos básicos
Aquí encontrará una versión modificada del manual de usuario de PostgreSQL que da una explicación del uso y
la sintaxis de los comandos usados en el presente laboratorio. Para consultar el manual oficial en idioma inglés
visite el sitio en Internet.
En algunos casos otras configuraciones son útiles. Por ejemplo, quizá quiera que la mayoría de los usuarios se
identifique por ellos mismos de manera única mientras les proporciona una cuenta con privilegios de invitado.
Quizá también tiene una aplicación cliente que se identifica por sí misma pero rara vez identifica al usuario (esto
es útil para las aplicaciones que son ejecutadas por algún usuario dentro de algún proveedor de autentificación).
Una cuenta de usuario es compartida entre todas las bases de datos dentro de clúster dado. Los grupos de
usuarios son también almacenados entre todas las bases de datos dentro de un clúster.
Las opciones de CREATEDB dan al usuario el derecho de crear nuevas bases de datos (dentro del clúster). Se
puede especificar NOCREATEDB para prohibir al usuario crear nuevas bases de datos. Si especifica CREATEDB no
NOCREATEDB, CREATE USER asumirá NOCREATEDB.
Administración de Grupos
Se pueden definir grupos de usuarios para hacer la administración mucho más fácil. Cada grupo puede incluir
usuarios. Cada usuario puede llegar a pertenecer a uno o más grupos. Cuando se otorga o revocan privilegios
para un objeto, se puede identificar un usuario específico o un grupo de usuarios.
Cada usuario es automáticamente miembro de un grupo PUBLIC. PUBLIC es realmente un grupo virtual, no puede
agregar o remover miembros y no puede borrar este grupo, pero se permite asociar privilegios con PUBLIC.
Los grupos son mucho más fáciles de manejar, si ellos coinciden con los roles en la organización. Por ejemplo,
quizá construya grupos nombrados como: desarrolladores, invitados, cajeros y administradores. Los grupos se
deben ordenar de forma que reflejen el mundo real, los grupos hacen que sea mucho más fácil asignar privilegios
en los objetos de la base de datos. Un objeto dado puede pertenecer a muchos grupos. Por ejemplo, un miembro
del grupo de los desarrolladores quizá también pertenezca al de los administradores.
Las definiciones de los grupos son almacenadas en las tablas del sistema. Como los usuarios de la base de datos,
las definiciones del grupo son almacenadas para toda la base de datos dentro de un clúster.
CREATE GROUP
Un súper usuario PostgreSQL puede crear un nuevo grupo usando el comando CREATE GROUP:
El nombre de grupo debe reunir las reglas para los identificadores de PostgreSQL (31 caracteres o menos,
comillas o iniciar con una letra o subrayado). Puedes incluir un valor SYSID si quiere asignar un identificador
numérico para el nuevo grupo. Nosotros conocemos cada grupo de usuarios por su nombre, pero alguna tabla
que se refiera al grupo se referirá al valor numérico. Quizá asigne un identificador numérico específico para un
grupo por las mismas razones que se asigna un identificador específico para un usuario.
Un típico comando es CREATE GROUP con el que quizá se vea algo como esto:
Este comando crea un nuevo grupo nombrado desarrolladores que inicialmente tiene dos miembros Bernardo y
Lety.
Crear Usuarios
Hay dos formas de crear un nuevo usuario: ejecutando el comando CREATE USER desde una aplicación cliente
(tal como un psql), o con el createuser del shell script.
Un nombre-usuario debe conformar las reglas usuales para los identificadores PostgreSQL: esto debe iniciar con
una letra (o un subrayado) y debe tener 31 caracteres de extensión. Si necesitas iniciar un nombre de usuario
con un número, sólo encierra el nombre con comillas dobles.
Vistas
Las vistas son pseudo-tablas, esto es, que no son tablas reales, sin embargo, aparecen como tablas ordinarias
para seleccionar. Una vista puede representar un subconjunto de una tabla real, seleccionando ciertas columnas
o ciertas filas de una tabla ordinaria. Incluso, una vista puede representar a varias tablas unidas. Debido a que a
las vistas se les asignan permisos por separado, se les puede usar para restringir acceso a una tabla. Las vistas
son creadas utilizando el comando CREATE VIEW.
Creación de reglas
Sintaxis:
Descripción
El sistema de reglas de PostgreSQL permite que una acción alternativa sea realizada en updates, inserts o deletes
en tablas o clases. Actualmente se utilizan reglas para implementar vistas de tablas.
El significado de una regla es que cuando una instancia individual es accedida, actualizada, insertada o borrada,
existe una instancia actual (para consultas, actualizaciones y borrados) y una nueva instancia (para
actualizaciones y añadidos). Si el event especificado en la cláusula ON y la condition especificada en la cláusula
WHERE son verdaderas para la instancia actual, la parte action de la regla es ejecutada. Antes, sin embargo, los
valores de los campos de la instancia actual y/o la nueva instancia son sustituidos por current.attribute-name y
new.attribute-name.
La parte action de la regla se ejecuta con el mismo identificador de comando y transacción que el comando de
usuario que causó la activación.
Notas
Es pertinente la precaución con reglas de SQL. Si el mismo nombre de clase o variable de instancia aparece en el
event, la condition y la parte action de la regla, son considerados todos diferentes tuplas. De forma más precisa,
new y current son las únicas tuplas que son compartidas entre cláusulas. Por ejemplo, las siguientes dos reglas
tienen la misma semántica.
Cada regla puede tener la etiqueta opcional INSTEAD. Sin esta etiqueta, la action será realizada en adición al
comando de usuario cuando el event en la parte condition de la regla aparezcan. Alternativamente, la parte
action será realizada en lugar del comando del usuario. En este último caso, la action puede ser la palabra clave
NOTHING.
Cuando se elige entre los sistemas de reescritura y reglas de instancia para una aplicación particular de una regla,
recuérdese que, en el sistema de reescritura, current se refiere a la relación y algunos calificadores mientras que
en el sistema de instancias se refiere a una instancia (tupla). Es muy importante notar que el sistema de
reescritura nunca detectará ni procesará reglas circulares.
Es necesario tener permiso de definición de reglas en una clase para poder definir una regla en él. Se debe utilizar
el comando GRANT y REVOKE para modificar estos permisos.
El objeto en una regla SQL no puede ser una referencia a un arreglo y no puede tener parámetros.
Aparte del campo "oid", los atributos del sistema no pueden ser referenciados en ningún lugar de la regla. Entre
otras cosas esto significa que las funciones de instancias (por ejemplo, foo(emp) donde emp es una clase) no
pueden ser llamadas en ningún lugar dentro de una regla.
El sistema almacena el texto de la regla y los planes de consulta como atributos de texto. Esto implica que la
creación de reglas puede fallar si la regla más sus varias internas representaciones exceden algún valor que es
del orden de una página.
Creación de tablas
Las tablas que en esta sección encuentra se crearon aplicando las reglas de conversión del modelo E-R al
relacional al diagrama E-R de la sección 1. Este laboratorio no intenta explicar esas reglas.
\c UACME
4. Problemática a resolver
En esta sección ponemos manos a la obra resolviendo el problema plateado inicialmente. En este momento ya
tenemos la base de datos creada, hemos insertado datos en algunas tablas y es hora de implementar los
conceptos que hemos estudiado en la sección conceptos básicos. Los problemas aquí planteados se han resuelto,
por lo que debe de "copiar" el comando SQL y "pegarlo" en el psql.
Administración de usuarios
Resolviendo el problema de la administración de UACME. Se han identificado dos grupos de usuarios en este
sistema: Administración y Escolar. Dentro de cada uno de estos grupos encontramos a los usuarios, los que se
clasifican así:
Administración:
- Jefe del departamento: C. P. Ávila
- Auxiliar de Administración: Sr. Cancino
Escolar:
- Jefe del departamento: Lic. Barroso
- Auxiliar Escolar: Sra. Tirado
- Auxiliar Escolar: Sra. Martínez
- Auxiliar Escolar: Sra. Aquino
- Auxiliar Escolar: Sra. Ramos
Como casos especiales este departamento podrá acceder a consultar las tablas de Cursos Especiales, Cursos
Especiales Verano, Cursos Especiales Extracurriculares, Cursos Extracurriculares y Materias. Explícitamente no se
les permite modificar ningún campo o registro.
-- Creando la vista, note que no se proyecta el campo sueldo, por lo tanto, se esconde de la mirada de los usuarios
del grupo escolar.
-- Solo puede consultar y actualizar la tabla de profesores a los usuarios del grupo admin.
Esto nos obliga a atacar el problema con una nueva perspectiva, la creación de reglas, usando la cuenta del
usuario postgres ejecute el siguiente comando:
Este problema aparece debido a que no se permite insertar registros sobre vistas, entonces lo que tenemos que
hacer es redirigir la operación a la tabla profesores usando una regla (la cual es una especie de interrupción) que
se dispara cada vez que se intenta ejecutar una inserción de datos sobre la tabla.
Con la cuenta del usuario Barroso intente nuevamente la ejecución del comando:
5. Trabajo adicional
Los siguientes problemas no están resueltos, por lo que es necesario aplicar su experiencia adquirida para
resolver estos.
1. Usando a los distintos usuarios verifique que se le permitan efectuar los movimientos acordes al privilegio
de acceso asignado sobre cada una de las tablas.
2. Construya la regla faltante para el grupo escolar sobre la vista VistaProfesoresEscolar, construya la regla para
cuando el usuario barroso desea eliminar el registro del docente Luis.
3. Agregue restricciones adicionales. Use la siguiente política: El encargado de capturar los cursos especiales
será el departamento administrativo (cualquier usuario), pero quién asignará el docente será el
departamento escolar. Construya la vista y la regla que va a reglamentar esta inserción de datos.
• La inserción de datos a la tabla CursosEspeciales y las tablas especializadas la efectuará el DA, con el campo
profesor en nulos o referenciando a un registro especial (por ejemplo, un profesor no válido) de la tabla
Profesores.
• La modificación de las tablas CursosEspeciales para asignar al Profesor la efectuará el DCE.
4. Finalmente, explique las causas por las que las instrucciones para los usuarios: barroso y ávila, marcan
errores o funcionan adecuadamente.
6. Referencias
• PostgreSQL Introduction and Concepts by Bruce Momjiam
• PostgreSQL by Susan Douglas and Korry Douglas.
• Manual de postgreSQL: www.postgresql.org
• Fundamentos de Base de Datos. 5a. Edición de Abraham Silberschatz. Ed. McGraw-Hill
• Elmasri y Navathe: Fundamentos de Sistemas de Bases de Datos - 3ª edición, 2002.
• Garcia-Molina, Ullman y Widom: "Database systems: the complete book". Prentice-Hall.
LABORATORIO 2. APLICACIÓN DE RESTRICCIONES
Introducción
En esta segunda entrega de la serie de laboratorios de Administración de Base de Datos (ABD) se enseña la forma
en que se aplican restricciones a los campos en una tabla de la base de datos. Los laboratorios se han diseñado
para proporcionar los conceptos y la experiencia necesarios para conocer detalladamente el sistema, se
aprovecha la función de "copiar y pegar" que nos ofrece el sistema operativo Windows para disminuir el esfuerzo
del lector en la preparación del ambiente de trabajo y en la solución de los problemas. En la sección denominada
"trabajo adicional" se requiere que el lector aplique la experiencia obtenida en la solución de problemas
relacionados al tema central del laboratorio. La sección de conceptos básicos muestra la sintaxis de los comandos
y da algunas explicaciones del uso de los mismos, este material ha sido tomado del manual de usuario del sistema
PostgreSQL el cual está disponible en la página oficial de la herramienta, en algunos casos se ha tomado del sitio
oficial en Español. Los conceptos básicos se aplican en torno a un proyecto que se denomina "Universidad
ACME", el cual es producto de la imaginación del autor, así como la solución práctica de los problemas
planteados. Los libros que se ofrecen en la sección de referencias, sirven como consulta para apoyar algunos de
los conceptos que se aplican en la solución práctica de problemas de administración de base de datos.
Estos laboratorios se han preparado para procurar experiencia práctica a los estudiantes de la materia
Administración de Base de Datos de la Licenciatura en Sistemas Computacionales que se ofrece en la Facultad
de Contaduría Pública (FCP) del Campus IV de la Universidad Autónoma de Chiapas (UNACH). En la FCP se tienen
al menos 14 años de experiencia en el uso de PostgreSQL en las aulas, proyectos de investigación y en sistemas
que se han implementado para la automatización de las actividades cotidianas de la FCP. Como producto de esa
experiencia académica e industrial se han obtenido estos laboratorios que se usan en las aulas para capacitar a
nuestros estudiantes. Hemos encontrado que los estudiantes se motivan al estudio cuando se concretan en estos
ejercicios las ideas abstractas que se explican en las aulas, aunque ese será tema de otro artículo que será
publicado en esta revista. También se tiene noticia de que son una fuente de consulta para egresados que
laboran en el sector empresarial.
Objetivo
El lector aprenderá a restringir los campos de una Base de Datos usando los comandos que el SQL tiene para este
fin en el sistema de administración de base de datos PostgreSQL.
Prerrequisitos
Se espera que el lector tenga experiencia previa en el uso y conversión de diagramas Entidad-Relación (E-R), los
temas asociados al Diseño de Base de Datos no se cubren en este documento. También se espera que el usuario
tenga conocimientos básicos del lenguaje de programación denominado SQL.
Es necesario instalar la base de datos PostgreSQL versión 9.3 sobre el sistema operativo Windows, verifique los
requerimientos para instalación en la página oficial de la herramienta: www.postgresql.org. El sistema puede
descargarse del sitio Web:
http://www.enterprisedb.com/products-services-training/pgdownload#windows
Si tiene alguna duda con respecto a PostgreSQL, le recomiendo visitar el sitio oficial con información publicada
en idioma español: http://www.postgresql.org.es/primeros_pasos.
1. Proyecto a desarrollar
El ejercicio que se va a realizar consiste en un proyecto que describe el problema de una empresa dedicada a la
prestación de servicios educativos: después de leer el texto se genera el diagrama E-R con la solución a éste
problema, se continúa con la creación de las tablas y población de las tablas, para finalmente trabajar con los
permisos de grupos y usuarios.
Los docentes de la UACME, son los únicos a los que se les permite impartir estos cursos, por los cuales recibe un
pago adicional, se les paga de acuerdo a un tabulador que indica el costo de la hora de estos cursos de acuerdo
al nivel académico del docente. El pago se genera a partir del alta del curso y solo se permite expedir un cheque
por cada curso. Además, los estudiantes deben acudir a pagar adicionalmente al costo del semestre por asistir a
ellos.
Como casos especiales este departamento podrá acceder a consultar las tablas de Cursos Especiales, Cursos
Especiales Verano, Cursos Especiales Extracurriculares, Cursos Extracurriculares y Materias. Explícitamente no se
les permite modificar ningún campo o registro.
Tablas a las que se le permite el acceso al personal de la Secretaría Escolar:
CursosEspeciales, CursosExtracurricular, Materias, CEVerano, CEExtracurricula, Alumnos, Bimestre, Faltas,
CalendarioEscolar.
2. Conceptos Básicos
Aquí encontrará una versión modificada del manual de usuario de PostgreSQL que da una explicación del uso y
la sintaxis de los comandos usados en el presente laboratorio. Para consultar el manual oficial en idioma inglés
visite el sitio oficial de la misma en Internet: www.postgresql.org
Restricciones (CONSTRAINTS)
Éstas permiten usar restringir los datos, de tal modo que ayudan a prevenir que datos inválidos entren a la base
de datos. El definir un tipo de datos para una columna es una restricción. Por ejemplo, una columna que tiene
una restricción de tipo DATE, la columna valida las fechas.
Al agregar una llave primaria automáticamente se crea un índice btree único sobre la columna o grupo de
columnas usadas en la llave primaria.
Una tabla puede tener cuando mucho una llave primaria. (Puede haber cualquier cantidad de restricciones únicas
y no-nulas, las cuales funcionalmente son lo mismo, pero solo una puede ser identificada como llave primaria).
La teoría de las bases de datos relacionales dicta que cada tabla debe tener una llave primaria. Esta regla no es
impuesta por Postgresql, pero es mejor seguirla.
RESTRICT y CASCADING DELETES son dos de las opciones más comunes. RESTRICT evita el borrado de un renglón
referenciado. NO ACTION significa que si todavía existen filas de referenciadas cuando se comprueba la
restricción, se produce un error; este es el comportamiento por omisión si no se especifica nada. (La diferencia
en esencia entre estas dos opciones es que NO ACTION permite que la validación sea diferida hasta más tarde
en la transacción, mientras que RESTICT no). CASCADE especifica que cuando un renglón referenciado es
borrado, los renglones referenciados deben ser borrados automáticamente también. Hay otras dos opciones:
SET NULL y SET DEFAULT. Éstas causan que las columnas referenciadas en los renglones referenciados sean
inicializadas con nulos o sus valores por omisión, respectivamente, cuando el renglón referenciado es borrado.
Note que éstas no lo excusan de observar cualquier restricción. Por ejemplo, si una acción específica SET
DEFAULT pero el valor por omisión no satisface la restricción de llave foránea, la operación fallará.
De forma análoga a ON DELETE hay también ON UPDATE la cual es invocada cuando una columna referenciada
es cambiada (actualizada). Las acciones posibles son las mismas. En este caso CASCADE significa que los valores
actualizados de las columnas referenciadas deben ser copiados en los renglones referenciados.
Normalmente, un registro referenciado no necesita satisfacer la restricción de llave foránea si cualquiera de sus
columnas referenciadas es nula. Si la coincidencia de nulos es agregada a la declaración de llave foránea, un
renglón de referencia escapa satisfaciendo la restricción solo si todas las columnas referenciadas son nulas (por
lo que una mezcla de valores nulos y no-nulos se garantiza que falle una restricción MATCH FULL). Si no quiere
referencias renglones para poder evitar el satisfacer la restricción de llave foránea, declare las columnas
referenciadas como no-nulas.
Una llave foránea de columnas referenciadas que ya sean una llave primaria o formen una restricción única. Esto
significa que las columnas referenciadas siempre tienen un índice (la que subyace a la llave primaria o una
restricción única); para así controlar si un renglón referenciado que tiene una coincidencia sea eficiente. Puesto
que el borrado de un renglón de una tabla referenciada o la actualización de un renglón de una tabla referenciada
requiere de la búsqueda en la tabla referenciada por renglones coincidentes con el viejo valor, también casi
siempre es buena idea indexar las columnas referenciadas. Puesto que esto no siempre es necesario hay muchas
opciones disponibles en como indexar, la declaración de una restricción de llave foránea no crea
automáticamente un índice de las columnas referenciadas.
La acción de llave foránea te ofrece una gran flexibilidad en cómo controlar los cambios de la llave primaria
afectan las filas de las llaves foráneas.
Usando un MATCH FULL en una multi-columna con restricción de foreign key requiere que todas las columnas
de en la llave sean NULAS o que todas las columnas de no sean NULAS.
Primero, las tablas son usadas para mostrar que el default permite una columna de una foreign key debe ser
colocada a NULL. A continuación, la tabla matchtest es creada con la opción de la restricción del foreign key
MATCH FULL. MATCH FULL; permite que todas las llaves sean colocadas a NULL, pero requiere que establecer a
NULL solamente algunos valores claves multi-columna.
CHECK
La restricción CHECK hace cumplir los valores de las columnas restringidas. Así la restricción puede restringir una
columna, por ejemplo; para un conjunto de valores, solo números positivos o datos razonables. Por default,
CHECK permite valores NULOS.
«Si una tupla de una tabla A posee atributos (a1...an) que hacen referencia a la clave primaria de otra tupla de
una tabla B, dichos atributos poseen, o bien valores nulos, o bien valores (v1 ... vn) que se corresponden con la
clave de una tupla concreta de B».
Se implementa en SQL usando el comando references, cuando se trata de una clave primaria de un solo atributo
o Foreign Key cuando se trata de una clave primaria de más de un atributo.
Creación de tablas
Las tablas que en esta sección encuentra se crearon aplicando las reglas de conversión del modelo E-R al
relacional al diagrama E-R de la sección 1. Este laboratorio no intenta explicar esas reglas.
3.1 Políticas a implementar en las tablas para el diagrama E-R de la Universidad ACME
A continuación, hacemos un resumen de las políticas que se van a implementar y las tablas que se verán
afectadas, la finalidad de este resumen es la de tener una panorámica completa de las restricciones que se
aplican a la base de datos.
Los siguientes comandos de creación de tablas e inserción de datos deben ser ejecutados usando el usuario
postgres (el usuario por omisión) y se debe de cambiar de usuario hasta que explícitamente se le indique. Note
que, a diferencia del primer laboratorio, en este la creación de tablas usando restricciones contiene más código,
y se debe a que con el uso de restricciones la declaración de las tablas es más detallada. Los lineamientos para
la creación de estas restricciones están desarrollados a partir de las políticas descritas por la empresa.
• Ningún atributo que sea por sí mismo llave primaria o sea parte de la llave primaria puede aceptar valores
nulos.
• Cuando un registro del maestro de recibos sea borrado, automáticamente deben ser borrados todos los
registros relacionados en la tabla detalle del recibo.
• Cuando una cuenta de cheques sea borrada, automáticamente deben ser borrados todos los registros
relacionados en la tabla cheques.
• Cuando se elimine un registro de la tabla CursosEspeciales, automáticamente debe ser borrado cualquier
registro relacionado en las tablas especializadas de ceextracurricula y ceverano.
• NO SE PERMITEN VALORES NULOS sobre los siguientes campos de cada tabla (las llaves primarias se
restringen en el primer lineamiento)
CuentaCheques (banco)
Tabulador (importehora);
Profesores (nombre, maximo);
Materias (des, horacurso);
Alumnos (nombre);
Concepto (desconcepto);
CalendarioEscolar (motivo);
• NO SE PERMITEN VALORES IGUALES O MENORES A CERO sobre los siguientes campos en las siguientes tablas:
Cheque (total);
Tabulador (importehora);
Profesores (sueldo);
Recibo (totalrec);
DetalleRecibo (subtotal);
• La fecha de emisión del cheque solo puede ser la de hoy o anterior pero nunca posterior a la fecha del sistema
Para cumplir con las políticas de la empresa, se reconstruyen las tablas en una nueva base de datos a la que
llamamos UACMEREST. Copie y pegue las tablas que se muestran a continuación en la nueva base de datos,
recuerde usar al usuario postgres en todos los casos. Finalmente, inserte los datos que se proporcionan para
poder verificar que las restricciones planteadas son cubiertas por la nueva definición de las tablas.
-- Creando la base de datos UACMEREST
\c uacmerest
-- la llave primaria no puede aceptar valores nulos, El campo total debe ser mayor o igual a cero, Cuando se
-- elimina el registro de la Cuenta de Cheques y todos los cheques de esa cuenta se borran
-- la llave primaria no puede aceptar valores nulos y El campo importehora debe ser mayor o igual a cero
-- la llave primaria no puede aceptar valores nulos y El campo sueldo debe ser mayor o igual a cero, Cuando se
-- borra un registro de la tabla tabulador se borran los registros asociados en la tabla profesores
Los datos insertados solo sirven para demostrar el funcionamiento de los privilegios de acceso, queda del usuario
insertar datos en el resto de las tablas para demostrar que las reglas de acceso son funcionales para cada usuario.
5. Trabajo adicional
Los siguientes problemas no están resueltos, por lo que es necesario aplicar su experiencia adquirida para
resolver estos.
1. Usando a los distintos usuarios verifique que se le permitan efectuar los movimientos acordes al
privilegio de acceso asignado sobre cada una de las tablas.
2. Construya la regla faltante para el grupo escolar sobre la vista VistaProfesoresEscolar, construya la regla
para cuando el usuario barroso desea eliminar el registro del docente Luis.
3. Agregue restricciones adicionales. Use la siguiente política: El encargado de capturar los cursos
especiales será el departamento administrativo (cualquier usuario), pero quién asignará el docente será
el departamento escolar. Construya la vista y la regla que va a reglamentar esta inserción de datos.
1. La inserción de datos a la tabla CursosEspeciales y las tablas especializadas la efectuará el DA, con el
campo profesor en nulos o referenciando a un registro especial (por ejemplo, un profesor no válido) de
la tabla Profesores.
2. La modificación de las tablas CursosEspeciales para asignar al Profesor la efectuará el DCE.
4. Explique las causas por las que las instrucciones para los usuarios: barroso y ávila, marcan errores o
funcionan adecuadamente.
5. Integre los conceptos explicados en los Laboratorios 1 y 2 de esta serie en una sola base de datos. Pistas:
Destruya la base de datos UACME, aplique los conceptos del Laboratorio 2 y luego aplique los privilegios
de acceso de los usuarios.
6. Referencias
PostgreSQL Introduction and Concepts by Bruce Momjiam
PostgreSQL by Susan Douglas and Korry Douglas.
Manual de postgreSQL: www.postgresql.org
Fundamentos de Base de Datos. 5a. Edición de Abraham Silberschatz. Ed. McGraw-Hill
Elmasri y Navathe: Fundamentos de Sistemas de Bases de Datos - 3ª edición, 2002.
Garcia-Molina, Ullman y Widom: Database systems: the complete book. Prentice-Hall.
LABORATORIO 3. PROCEDIMIENTOS ALMACENADOS Y DISPARADORES
Introducción
Esta tercera entrega de una serie de laboratorios de Administración de Base de Datos (ABD) enseña el uso de los
procedimientos almacenados asociados a los disparadores (triggers) en una tabla de la base de datos. Este
trabajo no pretende enseñar a programar procedimientos almacenados en la base de datos, por lo que el lector
debe de investigar el tema denominado Lenguaje de Procedimientos de SQL para PostgreSQL (SQL Procedural
Language, mejor conocido como PLPGSQL), aunque probablemente en una segunda serie de laboratorios se
explique este tipo de programación.
Los laboratorios se han diseñado para proporcionar los conceptos y la experiencia necesarios para conocer
detalladamente el sistema, se aprovecha la función de "copiar y pegar" que nos ofrece el sistema operativo
Windows para disminuir el esfuerzo del lector en la preparación del ambiente de trabajo y en la solución de los
problemas. En la sección denominada "trabajo adicional" se requiere que el lector aplique la experiencia
obtenida en la solución de problemas relacionados al tema central del laboratorio. La sección de conceptos
básicos muestra la sintaxis de los comandos y da algunas explicaciones del uso de los mismos, este material ha
sido tomado del manual de usuario del sistema PostgreSQL el cual está disponible en la página oficial de la
herramienta, en algunos casos se ha tomado del sitio oficial en español. Los conceptos básicos se aplican en
torno al mismo proyecto que usaremos en esta serie: "Universidad ACME", el cual es producto de la imaginación
del autor, así como la solución práctica de los problemas planteados. Los libros que se ofrecen en la sección de
referencias, sirven como consulta para apoyar algunos de los conceptos que se aplican en la solución práctica de
problemas de administración de base de datos.
Estos laboratorios se han preparado para procurar experiencia práctica a los estudiantes de la materia
Administración de Base de Datos de la Licenciatura en Sistemas Computacionales que se ofrece en la Facultad
de Contaduría Pública (FCP) del Campus IV de la Universidad Autónoma de Chiapas (UNACH). En la FCP se tienen
por lo menos 14 años de experiencia en el uso de PostgreSQL en las aulas, proyectos de investigación y en
sistemas que se han implementado para la automatización de las actividades cotidianas de la FCP. Como
producto de esa experiencia académica e industrial se han obtenido estos laboratorios que se usan en las aulas
para capacitar a nuestros estudiantes. También se tiene noticia de que son una fuente de consulta para
egresados que laboran en el sector empresarial.
Objetivo
El lector aprenderá a usar Procedimientos Almacenados y su relación con los Disparadores en la Base de Datos.
Prerrequisitos
Se espera que el lector tenga experiencia previa en el uso y conversión de diagramas Entidad-Relación (E-R), los
temas asociados al Diseño de Base de Datos no se cubren en este documento. También se espera que el lector
tenga conocimientos de programación en cualquier lenguaje de programación y si necesita información adicional
del PLPGSQL, se sugiere que visite el sitio: http://www.postgresql.org/docs/9.3/static/plpgsql.html, o busque
esta información en el libro "PostgreSQL" de los autores Susan y Korry Dougles (2005).
Finalmente, es necesario instalar la base de datos PostgreSQL versión 9.3 sobre el sistema operativo Windows,
verifique los requerimientos para instalación en la página oficial de la herramienta: www. postgresql.org. El
sistema puede descargarse del sitio Web:
http://www.enterprisedb.com/products-services-training/pgdownload#windows
Si tiene alguna duda con respecto a PostgreSQL, se recomienda visitar el sitio oficial con información publicada
en idioma español: http://www.postgresql.org.es/primeros_pasos
1. Proyecto a desarrollar
El ejercicio que se va a realizar consiste en un proyecto que describe el problema de una empresa dedicada a la
prestación de servicios educativos: después de leer el texto se genera el diagrama E-R con la solución a este
problema, se continúa con la creación de las tablas y población de las tablas, para finalmente trabajar con los
permisos de grupos y usuarios.
Los docentes de la UACME, son los únicos a los que se les permite impartir estos cursos, por los cuales recibe un
pago adicional, se les paga de acuerdo a un tabulador que indica el costo de la hora de estos cursos de acuerdo
al nivel académico del docente. El pago se genera a partir del alta del curso y solo se permite expedir un cheque
por cada curso.
Además, los estudiantes deben acudir a pagar adicionalmente al costo del semestre por asistir a ellos.
2. Conceptos Básicos:
Disparadores
Postgres tiene algunas interfaces cliente como Perl, Tcl, Python y C, así como dos lenguajes Procedimentales (PL).
También es posible llamar a funciones C como acciones disparador. Actualmente es posible especificar BEFORE
o AFTER en los INSERT, DELETE o UPDATE de un registro como un evento de disparo.
Creación de Disparadores
Si un evento disparo ocurre, el administrador de disparos (llamado Ejecutor) inicializa la estructura global
TriggerData •CurrentTriggerData y llama a la función de disparo para procesar el evento. La función de disparo
debe ser creada antes que el disparador, y debe hacerse como una función sin argumentos de entrada, y códigos
de retorno opacos.
<TRIGGER NAME> Se usa para identificar al disparador y también se usa como argumento del comando DROP
TRIGGER si se desea eliminarlo.
<BEFORE|AFTER> Determina si la función debe ser llamada antes (BEFORE) o después(AFTER) del evento.
<INSERT|DELETE|UPDATE> determina en que evento/s será llamada la función. Es posible especificar múltiples
eventos utilizado el operador OR.
<FOR EACH> Determina si el disparador se ejecutará para cada fila afectada o bien antes (o después) de que la
secuencia se haya completado.
<PROCEDURE NAME> Es la función invocada cuando se ejecute el disparador. Esta función puede ser escrita en
cualquier de los lenguajes procedimentales o las interfaces cliente que maneja PostgreSQL.
<FUNCTION ARGS> Son los argumentos pasados a la función en la estructura CurrentTriggerData. El propósito
de pasar los argumentos a la función es permitir que disparadores diferentes con requisitos similares invoquen
a la misma función. Además, la función puede ser utilizada para disparar distintas relaciones (estas funciones son
llamadas "general trigger functions").
Como ejemplo de utilización de lo antes descrito, se puede hacer una función general que toma como
argumentos dos nombres de campo e inserta el nombre del usuario y la fecha (timestamp) actuales en ellos. Esto
permite, por ejemplo, utilizar los disparadores en los eventos INSERT para realizar un seguimiento automático
de la creación de registros en una tabla de transacciones. Se podría utilizar también para registrar actualizaciones
si es utilizado en un evento UPDATE.
Las funciones de disparo retornan un área de tuplas (HeapTuple) al ejecutor. Esto es ignorado para disparadores
lanzados después (AFTER) de una operación INSERT, DELETE o UPDATE, pero permite lo siguiente a los
disparadores:
BEFORE: retornar NULL e ignorar la operación para la tupla actual (y de este modo la tupla no será
insertada/actualizada/borrada); o devolver un puntero a otra tupla (solo en eventos INSERT y UPDATE) que serán
insertados (como la nueva versión de la tupla actualizada en caso de UPDATE) en lugar de la tupla original.
Note que no hay inicialización por parte del manejador CREATE TRIGGER. Además, si más de un disparador es
definido para el mismo evento en la misma relación, el orden de su ejecución es impredecible. Si una función de
disparo ejecuta consultas SQL, entonces estas funciones pueden disparar a otros disparadores. Esto es conocido
como disparos en cascada. No hay ninguna limitación explicita en cuanto al número de niveles de cascada.
Si un disparador es lanzado por un INSERT e inserta una nueva tupla en la misma relación, el disparador será
llamado de nuevo (por el nuevo INSERT). Actualmente, no se proporciona ningún mecanismo de sincronización
para estos casos.
Los disparadores son parte de lo que se conoce como "elementos activos" de una base de datos. Así como lo son
las restricciones tales como NOT NULL, FOREIGN KEY, PRIMARY KEY, CHECK. Una vez definidas ellas "se activarán"
solo al ocurrir un evento que las viole, un valor nulo en un campo con NOT NULL, etc.
Con los disparadores se intenta dar más control al programador sobre los eventos que desencadenan un
elemento activo, se les conoce en inglés como reglas ECA (event-condition-action). Es por ello que los
disparadores tienen una clausula BEFORE, AFTER o INSTEAD y bajo que evento (INSERT, UPDATE, DELETE) pero
de esta forma el disparador se ejecutará para cada tupla (o fila) sometido al evento (clausula FOR EACH ROW)
pero el estándar dicta que puede ser también FOR EACH SENTENCE. Esto provoca que se ejecute el disparador
para toda la relación (o tabla) para la cual se define (clausula ON).
La diferencia para los que lo han programado, por ejemplo, en plpgsql, queda clara entonces: cuando es FOR
EACH ROW en la función pgsql que implementa el disparador se tiene un objeto NEW y uno OLD que se refiere
a la tupla completa, en el disparador de oraciones (statement) tiene un objeto NEW y OLD que son la relación
completa. Está claro entonces que es un poco más difícil implementar un disparador para oraciones que para
una fila.
El problema consiste que cuando se detecte que el alumno Juan Pérez ha pagado el concepto 50 (pago de cursos
especiales) por el Curso 75, el cual es un curso extracurricular de Java Básico y que será impartido del 10 al 30 de
enero del 2008 y por el cual va a pagar $4,500 pesos. En el momento en el que el Recibo y el Detalle del Recibo
se actualicen, también se actualizará la tabla PagoCursoEspecial, entonces automáticamente se debe de
incrementar el importe recabado para el curso que se ha pagado en la tabla CursosEspeciales. Asimismo, si el
recibo es cancelado, entonces el importe recabado en la tabla CursosEspeciales debe ser disminuido. Los cambios
efectuados se ven reflejados en las siguientes definiciones de tablas:
-- borrando la tabla de CursosEspeciales para después redefinirla, cuidado con el cascade, ya que si tiene datos
-- relacionados con ella puede llegar a borrar varias tablas y puede tener que volver a crearlas a partir del
-- laboratorio 1.
Ahora, preparamos el entorno para trabajar con los elementos adecuados, ejecute los siguientes comandos con
el usuario postgres:
Ésta es la función denominada ActualizadorTotal, cuya tarea es la de hacer el incremento del total recabado. Está
escrita con el lenguaje denominado PLPGSQL, y debe copiarse usando la cuenta del usuario postgres. Recuerde
que para poder copiar este programa debe de tener instalado el plpgsql en su base de datos. Si aún no tiene
instalado el lenguaje PLPGSQL, use el comando create language, para mayor información visite la página:
http://www.postgresql.org/docs/9.3/static/sql-createlanguage.html
A continuación, tenemos los comandos necesarios para la creación del disparador, en la definición de este se
hace referencia a la función definida antes.
CREATE TRIGGER TgIncrementaRecabado AFTER INSERT ON PagoCursoEspecial FOR EACH ROW EXECUTE
PROCEDURE IncrementadorTotal();
Ésta es la función DecrementadorTotal(), cuya tarea es la de decrementar el total recabado. Está escrita con el
lenguaje denominado PLPGSQL, y debe copiarse usando la cuenta del usuario postgres.
Finalmente, ahora construimos un disparador para cuando alguien que había pagado un curso y decide
cancelarlo, ante esta situación el total recaudado debe de disminuir.
-- Eliminando el disparador, por si acaso.
5. Trabajo adicional
Modifique el disparador para que cumpla con la siguiente condición: El alumno Juan Pérez ha decidido de última
hora que va a asistir a dos cursos extracurriculares, "Java Básico" que es el curso 75 y "Programación Avanzada
de Procedimientos Almacenados" que es el curso 100. Así que va a efectuar el pago y la cajera en el mismo recibo
(el folio 600) le cobra los dos cursos. ¿Qué modificaciones debe hacer en el programa que incrementa el total
recabado? Y ¿En el qué lo disminuye?
• En apariencia las dos funciones hacen casi lo mismo, ¿Puede optimizar el trabajo? Es decir, hacer una sola
función que sea capaz de controlar tanto el incremento como el decremento del total recabado.
6. Referencias
Douglas Korry y Susan Douglas. (2005) PostgreSQL A comprehensive guide to building, programming and
administering Postgre SQL databases. (2nd. Edition). Sams
Elmasri, R.; Navathe, S.B. (2002) Fundamentos de Sistemas de Bases de Datos. 3ª Edición. Addison-Wesley
Garcia-Molina, Jeffrey Ullman y Jennifer Widom. (2008) Database systems: the complete book. Prentice-Hall.
Momjiam Bruce (2001) PostgreSQL Introduction and Concepts. Boston: Addison-Wesley Logman Publishing Co.
Inc.
Silberschatz Abraham, Henry Korth y S. Sudarshan. (2006) Fundamentos de Base de Datos (5a. Edición). España:
McGraw-Hill
The PostgreSQL Global Development Group. (2015) Manual de postgreSQL. Disponible en www.postgresql.org
LABORATORIO 4. TRANSACCIONES Y PROCEDIMIENTOS ALMACENADOS
Introducción
Esta cuarta entrega de una serie de seis laboratorios de Administración de Base de Datos (ABD) enseña el uso de
los procedimientos almacenados asociados a las transacciones en la base de datos. Este trabajo no pretende
enseñar a programar procedimientos almacenados en la base de datos, por lo que el lector debe de investigar el
tema denominado Lenguaje de Procedimientos de SQL para PostgreSQL (SQL Procedural Language, mejor
conocido como PLPGSQL). Con relación a este tema, debo de comentar que ya estamos trabajando con algunos
docentes en el desarrollo de tres laboratorios en los que enseñaremos la programación de procedimientos
almacenados, así que estén pendientes. Para implementar la experiencia de las transacciones se hace uso de
programas desarrollados en lenguaje de programación Java, además se requiere, que los equipos usados para
desarrollar este experimento se encuentren conectados en una red local. Sin embargo, no es del alcance de este
trabajo el enseñar la conexión y configuración de una red, ni se pretende enseñar conceptos de programación
orientada a objetos con Java.
Los laboratorios se han diseñado para proporcionar los conceptos y la experiencia necesarios para conocer
detalladamente el sistema, se aprovecha la función de "copiar y pegar" que nos ofrece el sistema operativo para
disminuir el esfuerzo del lector en la preparación del ambiente de trabajo y en la solución de los problemas. En
la sección denominada "trabajo adicional" se requiere que el lector aplique la experiencia obtenida en la solución
de problemas relacionados al tema central del laboratorio. La sección de conceptos básicos se muestra la sintaxis
de los comandos y da algunas explicaciones del uso de los mismos, este material ha sido tomado del manual de
usuario del sistema PostgreSQL el cual está disponible en la página oficial de la herramienta, en algunos casos se
ha tomado del sitio oficial en español. Los conceptos básicos se aplican en torno al mismo proyecto que usaremos
en esta serie: "Universidad ACME", el cual es producto de la imaginación del autor, así como la solución práctica
de los problemas planteados. Los libros que se ofrecen en la sección de referencias, sirven como consulta para
apoyar algunos de los conceptos que se aplican en la solución práctica de problemas de administración de base
de datos.
Estos laboratorios se han preparado para procurar experiencia práctica a los estudiantes de la materia
Administración de Base de Datos de la Licenciatura en Sistemas Computacionales que se ofrece en la Facultad
de Contaduría Pública (FCP) del Campus IV de la Universidad Autónoma de Chiapas (UNACH). En la FCP tenemos
al menos 14 años de experiencia en el uso de PostgreSQL en las aulas, proyectos de investigación y en sistemas
que se han implementado para la automatización de las actividades cotidianas de la FCP. Como producto de esa
experiencia académica e industrial se han obtenido estos laboratorios que se usan en las aulas para capacitar a
nuestros estudiantes. También se tiene noticia de que son una fuente de consulta para egresados que laboran
en el sector empresarial.
Objetivo
El lector aprenderá a usar Procedimiento Almacenados y su relación con las transacciones en la Base de Datos.
Prerrequisitos
Se espera que el lector tenga experiencia previa en el uso y conversión de diagramas Entidad-Relación (E-R), los
temas asociados al Diseño de Base de Datos no se cubren en este documento. También se espera que el lector
tenga conocimientos de programación en cualquier lenguaje de programación y si necesita información adicional
del PLPGSQL, se sugiere que visite el sitio: http://www.postgresql.org/docs/9.3/static/plpgsql.html, o busque
esta información en el libro "PostgreSQL" de los autores Susan y Korry Douglas (ISBN: 0672327562).
También se espera que el lector tenga experiencia en la conexión de redes locales y en la instalación y
programación del lenguaje de programación Java. Oracle, la empresa que es propietaria de Java, ofrece una guía
para instalar este lenguaje:
https://www.java.com/es/download/help/download_options.xml
Finalmente, es necesario instalar la base de datos PostgreSQL versión 9.3 sobre el sistema operativo Windows o
Linux, verifique los requerimientos para instalación en la página oficial de la herramienta: www. postgresql.org.
El sistema puede descargarse del sitio Web:
http://www.enterprisedb.com/products-services-training/pgdownload#windows
Si tiene alguna duda con respecto a PostgreSQL, se recomiendo visitar el sitio oficial con información publicada
en idioma español: http://www.postgresql.org.es/primeros_pasos
1. Proyecto a desarrollar
El ejercicio que se va a realizar consiste en un proyecto que describe el problema de una empresa dedicada a la
prestación de servicios educativos: después de leer el texto se genera el diagrama E-R con la solución a este
problema, se continúa con la creación de las tablas y población de las tablas, para finalmente trabajar con los
permisos de grupos y usuarios.
Los docentes de la UACME, son los únicos a los que se les permite impartir estos cursos, por los cuales recibe un
pago adicional, se les paga de acuerdo a un tabulador que indica el costo de la hora de estos cursos de acuerdo
al nivel académico del docente. El pago se genera a partir del alta del curso y solo se permite expedir un cheque
por cada curso. Además, los estudiantes deben acudir a pagar adicionalmente al costo del semestre por asistir a
ellos.
Como casos especiales, este departamento podrá acceder a consultar las tablas de Cursos Especiales, Cursos
Especiales Verano, Cursos Especiales Extracurriculares, Cursos Extracurriculares y Materias. Explícitamente no se
les permite modificar ningún campo o registro.
2. Conceptos Básicos
Transacción
Una transacción es una ejecución de un programa de usuario, visto por el DBMS como una serie de operaciones
lecturas y escrituras, la cual accede a la base de datos que es compartida por varios usuarios en forma simultánea.
Es una colección de acciones que hacen transformaciones de los estados de un sistema preservando la
consistencia del mismo. Una base de datos está en un estado consistente si obedece todas las restricciones de
integridad definidas sobre ella. Los cambios de estado ocurren debido a actualizaciones, inserciones, y
supresiones de información. Por supuesto, se quiere asegurar que la base de datos nunca entra en un estado de
inconsistencia. Sin embargo, durante la ejecución de una transacción, la base de datos puede estar
temporalmente en un estado inconsistente. El punto importante aquí es asegurar que la base de datos regresa
a un estado consistente al fin de la ejecución de una transacción.
Lo que se persigue con el uso de transacciones es por un lado contar con una transparencia adecuada de las
acciones concurrentes a una base de datos y por el otro tener una transparencia adecuada en el manejo de las
fallas que se pueden presentar en una base de datos.
Consistencia: una transacción es un programa correcto que lleva la base de datos de un estado consistente a
otro con la misma característica. Gracias a esto, las transacciones no violan las reglas de integridad de una base
de datos.
Aislamiento: una transacción en ejecución no puede revelar sus resultados a otras transacciones concurrentes
antes de su compromiso (commit). Más aún, si varias transacciones se ejecutan concurrentemente, los
resultados deben ser los mismos que si ellas se hubieran ejecutado de manera secuencial (seriabilidad). La
seriabilidad consiste en asegurarse que los cambios siguen un orden adecuado.
Atomicidad: una transacción es tratada como una unidad de operación. Por lo tanto, todas las acciones de la
transacción se llevan a cabo o ninguna de ellas se realiza. La atomicidad requiere que, si una transacción se
interrumpe por una falla, sus resultados parciales deben ser deshechos. Se efectúan todas las transacciones,
pero en caso de fallas no se realiza ninguna. Una transacción debe concluir comprometida o abortada. En el caso
del compromiso se instalan todas las actualizaciones y en el aborto se descartan todas las actualizaciones.
Durabilidad: es la propiedad de las transacciones que asegura que una vez que una transacción realiza su
compromiso, sus resultados son permanentes y no pueden ser borrados de la base de datos, se asegura que los
resultados de una transacción sobrevivirán a fallas del sistema. Una transacción siempre termina, aun en la
presencia de fallas. Si una transacción termina de manera exitosa se dice que la transacción hace un compromiso.
Si la transacción se detiene sin terminar su tarea, se dice que la transacción aborta. Cuando la transacción es
abortada, puede ser por distintas razones relacionadas con la naturaleza de la transacción misma, o por conflicto
con otras transacciones o por fallo de un proceso o computador, entonces su ejecución es detenida y todas las
acciones ejecutadas hasta el momento son deshechas regresando a la base de datos al estado antes de su
ejecución. A esta operación también se la conoce como restauración (rollback).
Un candado es un mecanismo de control de acceso concurrente a un dato. Los datos pueden tener candados en
dos modos:
• Modo exclusivo (X). El dato puede ser leído y escrito. Un candado en este modo se solicita con la instrucción
lock-X
• Modo compartido (S). El dato solo puede ser leído. Un candado en este modo se solicita con la instrucción
lock-S.
Las peticiones por candados se hacen al administrador de control de concurrencia. La transacción puede
proceder solo después de que una solicitud es otorgada.
• Un candado es un mecanismo de control de acceso concurrente a un dato
• Los datos pueden tener candados en dos modos:
• Modo exclusivo (X). El dato puede ser leído y escrito. Un candado en este modo se solicita con la instrucción
lock-X
• Modo compartido (S). El dato solo puede ser leído. Un candado en este modo se solicita con la instrucción
lock-S.
• Las peticiones por candados se hacen al administrador de control de concurrencia. La transacción puede
proceder solo después de que una solicitud es otorgada.
• Un candado es otorgado si el candado solicitado es compatible con otros candados previamente otorgados.
• Se pueden tener varios candados compartidos sobre un dato, pero sólo un candado exclusivo
• Si un candado no puede ser concedido, la transacción que lo solicita debe esperar a que todos los candados
incompatibles sean liberados.
• El poner candados no es suficiente para garantizar seriabilidad.
• Ejemplo: si A se actualiza después de la lectura de B, la suma será incorrecta
• Un protocolo basado en candados es un conjunto de reglas seguidas por todas las transacciones para solicitar
y liberar candados.
Abortos en Cascada: Puede suceder si una transacción aborta después de liberar un candado, otras transacciones
que hayan accedido el mismo elemento de datos aborten también. Para evitar lo anterior, los despachadores
para candados de dos fases implementan lo que se conoce como los candados estrictos de dos fases en los cuales
se liberan todos los candados cuando la transacción termina.
Sintaxis
BEGIN [ WORK | TRANSACTION]
Entradas
WORK
TRANSACTION
Palabras clave opcionales. No tienen efecto.
Salidas
BEGIN - Esto significa que una nueva transacción ha sido comenzada.
NOTICE: BEGIN: "already a transaction in progress" - Esto indica que una transacción ya está en progreso. La
transacción en curso no se ve afectada.
Descripción
Por omisión, PostgreSQL ejecuta las transacciones en modo no encadenado (también conocido como
"autocommit" en otros sistemas de base de datos). En otras palabras, cada estado de usuario es ejecutado en su
propia transacción y un compromiso se ejecuta implícitamente al final de cada comando (si la ejecución fue
exitosa, de otro modo se ejecuta una restauración). BEGIN inicia una transacción de usuario en modo
encadenado, i.e. Todos los estados de usuarios después de un comando BEGIN se ejecutaran en una transacción
única hasta un explícito COMMIT, ROLLBACK, o aborte la ejecución. Los estados en modo encadenado se
ejecutan mucho más rápido, porque la transacción arranque/compromiso (start/commit) requiere una actividad
significativa de CPU y de disco. La ejecución de múltiples estados dentro de una transacción también es requerida
para la consistencia cuando se cambian muchas tablas relacionadas. El nivel de aislamiento por omisión de las
transacciones en PostgreSQL es READ COMMITTED, donde las consultas dentro de la transacción solo tienen en
cuenta los cambios consolidados antes de la ejecución de la consulta. Así pues, debe utilizar SET TRANSACTION
ISOLATION LEVEL SERIALIZABLE justo después de BEGIN si necesita aislamiento de transacciones más riguroso.
Las consultas del tipo SERIALIZABLE solo tendrán en cuenta los cambios consolidados antes de que la transacción
entera comience (realmente, antes de la ejecución del primer estado DML en una transacción serializable).
Si la transacción está consolidada, PostgreSQL asegurará que todas las actualizaciones sean hechas o si no que
ninguna de ellas lo sea. Las transacciones tienen la propiedad estándar ACID (atómica, consistente, aislada y
durable).
SELECT - Recupera registros desde una tabla o vista. Este comando es el mismo que usa para efectuar consultas.
Sintaxis
SELECT [ALL | DISTINCT [ON (expression [, ...] ) ] ]
[WHERE condition ]
La cláusula FOR UPDATE permite a SELECT realizar un bloqueo exclusivo de los registros seleccionados.
Sintaxis
Entrada
WORK
TRANSACTION
Salida
Descripción
COMMIT realiza la transacción actual. Todos los cambios realizados por la transacción son visibles a las otras
transacciones, y se garantiza que se conservan si se produce una falla en la máquina.
Notas
Las palabras clave WORK y TRANSACTION son demasiado informativas, y pueden ser omitidas. Use ROLLBACK
para abortar una transacción.
Uso
COMMIT WORK;
Sintaxis
Salida
Descripción
ROLLBACK deshace la transacción actual y provoca que todas las modificaciones originadas por la misma sean
descartadas, es decir, restaura el estado anterior a la modificación.
Notas
Utilice COMMIT para terminar una transacción de forma exitosa. ABORT es un sinónimo de ROLLBACK.
Uso
Para cancelar todos los cambios:
ROLLBACK WORK;
Una manera de inicializar estos parámetros es editar el archivo postgresql.conf, el cual normalmente se
encuentra en el directorio de datos (una copia se instala por omisión cuando el directorio de la base de datos es
inicializado). Un ejemplo de como se ve este archivo es el siguiente:
Un parámetro es especificado por cada línea. El signo igual entre el nombre y el valor es opcional. El espacio en
blanco es insignificante y las líneas en blanco son ignoradas. Un símbolo #, indica que el resto de la línea es un
comentario. Los valores de parámetros que no son identificadores simples o nombres deben estar entre
apostrofes.
El archivo de configuración es re-leído cuando el proceso servidor principal recibe una señal SIGHUB; esto se
hace ejecutando el comando pg_ctl reload desde la línea de comando o invocando la función de SQL
pg_reload_conf(). El servidor principal también propaga esta señal a todos los procesos servidores en ejecución
por lo que las sesiones existentes también obtienen el nuevo valor. Alternativamente, se puede enviar la señal a
un solo proceso servidor directamente. Algunos parámetros solo pueden ser configurados en el arranque del
servidor; cualquier cambio a esas entradas en el archivo de configuración serán ignoradas hasta que este sea
reiniciado. Las configuraciones inválidas en este archivo de son ignoradas durante el proceso de SIGHUB.
El formato general del archivo pg_hba.conf es un conjunto de registros, uno por línea. Las líneas en blanco son
ignoradas, como lo es cualquier texto después del carácter de comentarios #, Los registros no pueden continuar
en múltiples líneas. Un registro se compone de un cierto número de campos los cuales se separan por espacios
y/o tabuladores. Los campos pueden contener espacios en blanco si el valor del campo es entrecomillado.
Cada registro especifica un tipo de conexión, un rango de direcciones IP de clientes (si es relevante para el tipo
de conexión), un nombre de base de datos, un nombre de usuario, y el método de autenticación a ser usado para
las conexiones que coincidan con estos parámetros. El primer registro que coincida con: un tipo conexión,
dirección de cliente, base de datos solicitada, y el nombre del usuario es usado para efectuar la autenticación.
No hay una lectura adicional o respaldo: si un registro es elegido y la autenticación falla, los registros
subsecuentes no se consideran. Si ningún registro coincide, se niega el acceso.
Postgresql.conf
listen_address = 'localhost'
listen_address = '*'
Pg_hba.conf
Es importante reiniciar el equipo que ejecuta el proceso servidor de PostgreSQL, para que desde el arranque este
proceso adquiera los valores recién configurados.
Windows.
Los archivos de configuración se encuentran en la ruta "C:\Program Files\PostgreSQL\9.3\data".
Linux
Regularmente se encuentra en el directorio /usr/local/pgsql/data/, pero seguramente cada sabor tiene su propia
ruta de instalación.
Programas en Java
Para este laboratorio se requiere que se conecten al menos dos computadoras en red, con direcciones IP fijas, y
que solo una de ellas esté ejecutando la base de datos. Descargue el proyecto en Java que se proporciona en la
página de la revista e instale en cada una de las computadoras que forman parte de la red, abrir en cada caso
con el IDE Netbeans o Eclipse. La clase conexión (donde se configura el JDBC) debe ser modificada en cada
equipo. El comando localhost deberá ser cambiado por la dirección IP del equipo con ejecuta la base de datos,
tal y como se muestra en el programa de abajo.
Clase CONEXIÓN.java.
--Conectando a la BD uacme
\c uacme
-- Creando los cursos que van a impartir los docentes Julio y Samuel
-- Función que inserta el registro del cheque, actualiza el saldo de la cuenta de cheques y referencia el cheque
-- contra la tabla CursosEspeciales. Solo se permite pagar un curso con un cheque.
-- Parámetros: Número de Cuenta de Cheques, Número de cheque, Importe del Cheque, Curso que se está
-- pagando.
-- Consulta de saldos en las Cuentas de Cheques, saldo actual de 9000 pesos
Una vez configurado PostgreSQL para recibir conexiones remotas y nuestro entorno en la base de datos, estamos
listos para probar las transacciones y resolver el problema que nos plantea este laboratorio.
4. Problemática a resolver
Para nuestro ejercicio debemos hacer algunas suposiciones. Resulta que los dos empleados del DA están
generando cheques para pagar cursos de la cuenta 2 (con un saldo de 9000 pesos), uno para el profesor Julio por
3000 pesos y otro para el profesor Samuel por 1000 pesos, lo curioso es que al momento de generarlos y debido
a que el sistema está funcionando en red con una base de datos centralizada, lo hacen al mismo tiempo, como
consecuencia el saldo quedó en 6000 pesos (o podría quedar en 8000 dependiendo de cuál cheque afecta el
saldo primero). Así que efectuaremos primero las transacciones con un procedimiento almacenado, pero sin usar
transacciones y después incorporamos su uso para demostrar la utilidad de las mismas.
1er. Caso:
Efectuaremos la expedición de dos cheques de manera simultánea desde los programas escritos en Java, uno
para el profesor Julio y el otro para el profesor Samuel. Ejecute el programa index.java en el IDE de su elección,
en cada equipo. Estos programas se deben ejecutar en equipos distintos para obligar a la base de datos a tratar
datos en forma concurrente. La figura 2 muestra los datos que se deben capturar en el programa index.java,
desmarque el CheckBox de Transacciones de la pantalla. Se intenta forzar al PostgreSQL a cometer un error, por
lo que después de capturar los datos se debe dar clic sobre el botón Enviar de manera simultánea en los dos
equipos que forman parte de la red. La figura 3 muestra el detalle del programa Index.Java que invoca la función
AltaDeCheque cuando no se selecciona el CheckBox indicado, debe notar que no se ha incorporado el uso de
transacciones.
Finalmente consulte el saldo de la Cuenta de Cheques 2, ¿Cuál es el saldo? ¿Es correcto? De estar correcto el
saldo, devuelva los valores a su estado previo y vuelva a intentarlo hasta que encuentre un resultado erróneo.
Explique la razón por la cual fallan los procesos o explique la razón por la cual falla si la invocamos desde Java.
2do. Caso:
Ejecute la sección Regresando los datos a los valores originales de la sección 3. Preparación del Ambiente de
Trabajo. Ejecute los programas de Java en cada equipo y capture los mismos datos del caso 1 (Figura 2), solo que
ahora seleccione el CheckBox de Transacciones de la pantalla. Estos programas se deben ejecutar en equipos
distintos para obligar a la base de datos a tratar datos en forma concurrente. La figura 4 muestra el detalle del
programa Index.Java que invoca la función AltaDeCheque cuando es seleccionado el CheckBox indicado, debe
notar que se ha incorporado el uso de transacciones. Se intenta forzar al PostgreSQL a cometer un error, por lo
que después de capturar los datos se debe dar clic sobre el botón Aceptar de manera simultánea en los dos
equipos que forman parte de la red. Note que se ha agregado el comando "for update" al cuerpo de la llamada
a la AltaDeCheque, y que previamente se ha invocado el comando "Begin Transaction" posteriormente se ha
agregado el comando "Commit Transaction".
Finalmente consulte el saldo de la Cuenta de Cheques 2, ¿Cuál es el saldo? ¿Es correcto? De estar correcto el
saldo vuelva a intentarlo. Explique la razón por la cual ahora no falla.
5. Trabajo Adicional
• Modifique la función AltaDeCheque para que en caso de que no se tenga saldo en la cuenta de cheques no
se permita ejecutar la inserción del cheque y devuelva un valor de 0. Además modifique la invocación desde
Java para que en caso de que la función AltaDeCheque devuelva un cero se ejecute un Rollback Transaction
y en caso de un 1 se ejecute un Commit Transaction;
• El mismo problema aparece con el total recabado por cada curso al momento de que dos cajeros cobren el
mismo curso al mismo tiempo a dos alumnos distintos. Construya las funciones pertinentes en PL y adecúe
el programa en Java que desarrolló en el laboratorio 3. Haga los cambios que considere necesarios.
• Para el sistema de inventarios, actualice el inventario en un procedimiento de transacciones.
6. Referencias
Douglas Korry y Susan Douglas. (2005) PostgreSQL A comprehensive guide to building, programming and
administering Postgre SQL databases. (2nd. Edition). Sams
Elmasri, R.; Navathe, S.B. (2002). Fundamentos de Sistemas de Bases de Datos. 3ª Edición. Addison-Wesley
Garcia-Molina, Jeffrey Ullman y Jennifer Widom. (2008). Database systems: the complete book. Prentice-Hall.
Momjiam Bruce. (2001). PostgreSQL Introduction and Concepts. Boston: Addison-Wesley Logman Publishing Co.
Inc.
Silberschatz Abraham, Henry Korth y S. Sudarshan. (2006). Fundamentos de Base de Datos (5a. Ed.). España:
McGraw-Hill.
The PostgreSQL Global Development Group. (2015). Manual de postgreSQL. Disponible enwww.postgresql.org.
LABORATORIO 5. RESPALDO DE LA BD Y EXPORTACIÓN DE DATOS ENTRE DIFERENTES DBMS
Introducción
Esta quinta entrega de una serie de seis laboratorios de Administración de Base de Datos (ABD) enseña el
respaldo de una base de datos y la exportación de datos entre diferentes sistemas de administración de base de
datos relacionales (DBMS). Para este laboratorio es necesario que el lector disponga de dos computadoras, una
de ellas ejecutando el sistema operativo Windows y la otra con Linux. Para la transferencia de archivos entre
ambos sistemas operativos estaremos usando el protocolo de transferencia de archivos (FTP), por lo que será
necesario instalar el servidor FTP en el equipo que usa Linux.
Los laboratorios se han diseñado para proporcionar los conceptos y la experiencia necesarios para conocer
detalladamente el sistema, se aprovecha la función de “copiar y pegar” que ofrece el sistema operativo para
disminuir el esfuerzo del lector en la preparación del ambiente de trabajo y en la solución de los problemas. En
la sección denominada “trabajo adicional” se requiere que el lector aplique la experiencia obtenida en la solución
de problemas relacionados con el tema central del laboratorio. La sección de conceptos básicos muestra la
sintaxis de los comandos y da algunas explicaciones del uso de los mismos, este material ha sido tomado del
Manual de usuario del sistema PostgreSQL el cual está disponible en la página oficial
(https://www.postgresql.org/docs/9.3/static/) de la herramienta, en algunos casos se ha tomado del sitio oficial
en Español. En esta misma sección se describen algunos comandos y aplicaciones del sistema operativo Linux
cuyas descripciones de uso y/o sintaxis se han tomado de los manuales de usuario del sistema y se han
complementado con publicaciones del sitio Wikipedia (es.wikipedia.org). Los conceptos básicos se aplican en
torno al mismo proyecto que usaremos en esta serie: “Universidad ACME”, el cual es producto de la imaginación
del autor, así como la solución práctica de los problemas planteados. Los libros que se ofrecen en la sección de
referencias, sirven como consulta para apoyar algunos de los conceptos que se aplican en la solución práctica de
problemas de administración de base de datos.
Estos laboratorios se han preparado para procurar experiencia práctica a los estudiantes de la materia
Administración de Base de Datos de la Licenciatura en Sistemas Computacionales que se ofrece en la Facultad
de Contaduría Pública (FCP) del Campus IV de la Universidad Autónoma de Chiapas (UNACH). En la FCP tenemos
al menos 14 años de experiencia en el uso de PostgreSQL en las aulas, proyectos de investigación y en sistemas
que se han implementado para la automatización de las actividades cotidianas de la FCP. Como producto de esa
experiencia académica e industrial se han obtenido estos laboratorios que se usan en las aulas para capacitar a
nuestros estudiantes. También se tiene noticia de que son una fuente de consulta para egresados que laboran
en el sector empresarial.
Objetivo
El lector aprenderá a usar los procedimientos de respaldo, además de cómo migrar datos entre diferentes
Sistemas de Administración de Bases de Datos.
Prerrequisitos
Se espera que el lector tenga experiencia previa en el uso y conversión de diagramas Entidad-Relación (E-R), los
temas asociados al Diseño de Base de Datos no se cubren en este documento. También se espera que el lector
tenga conocimientos de programación en cualquier lenguaje de programación y si necesita información adicional
del PLPGSQL, se sugiere que visite el sitio: http://www.postgresql.org/docs/9.3/static/plpgsql.html, o busque
esta información en el libro PostgreSQL (2003) 1 de los autores Susan y Korry Douglas.
Asimismo, se espera que el lector tenga experiencia en la conexión de redes locales, es necesario que se
configuren el sistema de transferencia de archivos (FTP), el cliente en Windows y el servidor en Linux. Finalmente,
es necesario instalar la base de datos PostgreSQL versión 9.3 sobre el sistema operativo Windows o Linux,
verifique los requerimientos para instalación en la página oficial de la herramienta: www. postgresql.org El
sistema puede descargarse del sitio Web:
http://www.enterprisedb.com/products-services-training/pgdownload#windows
Si tiene alguna duda con respecto a PostgreSQL, le recomiendo visitar el sitio oficial con información publicada
en idioma español: http://www.postgresql.org.es/primeros_pasos.
1. Proyecto a desarrollar
El ejercicio que se va a realizar consiste en un proyecto que describe el problema de una empresa dedicada a la
prestación de servicios educativos: después de leer el texto se genera el diagrama E-R con la solución a este
problema, se continúa con la creación de las tablas y población de las tablas, para finalmente trabajar con los
permisos de grupos y usuarios.
Los docentes de la UACME, son los únicos a los que se les permite impartir estos cursos, por los cuales recibe un
pago adicional, se les paga de acuerdo a un tabulador que indica el costo de la hora de estos cursos de acuerdo
al nivel académico del docente. El pago se genera a partir del alta del curso y solo se permite expedir un cheque
por cada curso. Además, los estudiantes deben acudir a pagar adicionalmente al costo del semestre por asistir a
ellos.
Como casos especiales este departamento podrá acceder a consultar las tablas de Cursos Especiales, Cursos
Especiales Verano, Cursos Especiales Extracurriculares, Cursos Extracurriculares y Materias. Explícitamente no se
les permite modificar ningún campo o registro.
2. Conceptos Básicos.
COPY —Copia datos entre archivos y tablas
Sintaxis
Entradas
•BINARY - Cambia el comportamiento del formato de campos, forzando a todos los datos a almacenarse o leerse
como objetos binarios, en lugar de como texto.
Table - El nombre de una tabla existente.
WITH OIDS - Copia el identificador de objeto interno único (OID) para cada fila.
Filename - La ruta absoluta en formato Unix del archivo de entrada o salida.
Stdin - Específica que la entrada viene de un conducto o terminal.
Stdout - Específica que la salida va a un conducto o terminal.
Delimiter - Un carácter que delimita los campos de entrada o salida.
null print - Una cadena para representar valores NULL. El valor por defecto es “\N” (backslash-N), por razones
históricas. Puede preferir, por ejemplo, una cadena vacía.
Nota: En una copia de entrada, cualquier dato que coincida con esta cadena será almacenado como un valor
NULL, por lo que debería asegurarse de usar la misma cadena que usó para la copia de salida.
Salidas
Descripción
COPY mueve datos entre tablas de Postgres y archivos del sistema de archivos estándar.
COPY indica al servidor Postgres que lea o escriba de o a un archivo. El archivo ha de ser directamente visible
para el servidor, y el nombre completo ha de especificarse desde el punto de vista del servidor. Si se especifica
stdin o stdout, los datos van de la aplicación cliente al servidor (o viceversa).
Notas
La palabra clave BINARY obliga a que todos los datos se almacenen o lean como objetos binarios en lugar de
como texto. Esto es algo más rápido que el comportamiento normal de COPY pero el resultado no es
generalmente portable, y los archivos generados son algo más grandes aunque este es un factor que depende
de los datos en sí. Por defecto, cuando se copia un texto se usa un tabulador ("\t") como delimitador. El
delimitador puede cambiarse por cualquier otro carácter empleando la palabra clave USING DELIMITERS. Los
caracteres dentro de los campos de datos que resulten coincidir con el delimitador serán encerrados entre
comillas. Ha de hacerse primero un select access en cualquier tabla cuyos valores sean leídos por COPY, e insert
or update access en la tabla en la que se vayan a insertar los valores. El servidor necesita los permisos Unix
adecuados sobre cualquier archivo que vaya a leerse o escribirse con este comando. La palabra clave USING
DELIMITERS especifica un carácter que se usará para delimitar entre columnas. Si se especifican varios caracteres
en la cadena delimitadora, solo se usará el primer caracter.
COPY no invoca regla ni acciones por defecto en las columnas. Sin embargo, puede invocar procedimientos
disparados.
COPY detiene las operaciones en el primer error. Esto no produce problemas en el caso de
COPY FROM, pero el destino, por supuesto, será parcialmente modificado en el caso de un COPY TO.
Debido a que el directorio de trabajo del servidor de Postgres no es normalmente el mismo que el directorio de
trabajo del usuario, el resultado de copiar el archivo "foo" (sin añadir información de la ruta) puede dar lugar a
resultados inesperados para el usuario inadvertido.
En este caso, en lugar de foo, acabamos con $PGDATA/foo. Por lo general, debería usarse la ruta completa tal
como se vería desde el servidor, al especificar los archivos a copiar.
Los archivos usados como argumentos para COPY deben residir o ser accesible por parte de la máquina servidor
de base de datos, en los discos locales o en un sistema de archivos de red. Cuando se emplea una conexión
TCP/IP, y se especifica un archivo objetivo, dicho archivo se escribirá en la máquina donde se esté ejecutando el
servidor, no en la máquina del usuario.
FORMATOS DE ARCHIVO
Formato de Texto
Cuando se usa COPY TO sin la opción BINARY, el archivo generado tendrá cada fila (instancia) en una sola línea,
con cada una de las columnas (atributo) separada por el carácter delimitador. Los caracteres delimitadores
internos (los caracteres internos que coincidan con el delimitador) se precederán del carácter barra atrás ("\").
Los valores de atributo son cadenas de texto generados por la función de salida asociada con cada uno de los
tipos de atributo. La función de salida para un tipo no debería tratar de generar el carácter barra atrás; éste será
generado por el comando COPY.
El identificador se sitúa en el principio de la línea, cuando se especifica WITH OID, si COPY envía su salida a la
salida estándar en lugar de a un archivo, enviará una barra invertida ("\") y un punto, seguidos de un carácter de
salto de línea en una línea separada, cuando termina su salida. Similarmente, si COPY está leyendo de una salida
estándar, esperará una barra invertida y un punto; seguidos por un fin de línea, como los tres primeros caracteres
de una línea para indicar el fin del archivo. Sin embargo, COPY terminará (y a continuación terminará la aplicación
servidor) si se encuentra un EOF antes de que se encuentre esta cadena que indica el fin de archivo. El carácter
barra invertida tiene otros significados especiales. Un carácter barra invertida literal se representa como dos
barras consecutivas ("\\". El carácter tabulador se representa con una barra invertida y un tabulador. El carácter
fin de línea se representa como una barra invertida y un fin de línea. Cuando se cargan datos de test no generados
por PostgreSQL necesitará convertir el carácter barra invertida en un par de barras para asegurar que se carguen
adecuadamente. (La secuencia "\N" siempre se interpretará como una barra invertida y un carácter "N", por
compatibilidad. La solución más general es "\\N".)
Binary Format
En el caso de COPY BINARY, los primeros cuatro bytes del archivo será el número de instancias en el archivo. Si
el número es cero, el comando COPY BINARY leerá hasta que se encuentre el fin del archivo. En otro caso, dejará
de leer cuando se lean ese número de instancias. Los restantes datos en el archivo se ignorarán.
Contenidos de un archivo binario de copy Alineación de datos binarios
Sobre equipos Sun-3s, los atributos de 2 bytes se alinean en grupos de cuatro bytes. Los atributos de caracteres
se alinean en grupos de un solo byte. En la mayoría de las otras máquinas, todos los atributos mayores de un
byte se alinean en grupos de cuatro bytes. Nótese que los atributos de longitud variable vienen precedidos de la
longitud del atributo; las matrices son simplemente cadenas continuas del elemento tipo de la matriz.
Uso
El siguiente ejemplo copia una tabla a la salida estándar, usando una barra vertical como delimitador de campo:
Aquí un ejemplo de datos adecuados para ser copiados a una tabla desde stdin (dado que tienen la secuencia de
terminación en la última línea):
AF AFGHANISTAN
AL ALBANIA
AL ALBANIA
DZ ALGERIA
...
ZM ZAMBIA
ZW ZIMBABWE
\.
Compatibilidad SQL92
Sintáxis
pg_dump [ base_de_datos ]
pg_dump [ -h huésped ] [ -p puerto ]
[ -t tabla ]
[ -a ] [ -c ] [ -d ] [ -D ] [ -n ] [ -N ]
[ -o ] [ -s ] [ -u ] [ -v ] [ -x ]
[ base_de_datos ]
Salida
La conexión con la base de datos ’base_de_datos’ falló. FATAL 1: SetUserId: el usuario ’nombre_de_usuario’ no
estú en ’pg_shadow’ Usted no posee una entrada vúlida en la relación pg_shadow y no le serú permitido tener
acceso a Postgres. Contacte a su administrador de Postgres.
dumpSequence(tabla): SELECT falló Usted carece del permiso para leer la base de datos. Contacte a su
administrador de site Postgres.
Nota: pg_dump ejecuta internamente las directivas SELECT. Si tiene problemas ejecutando pg_dump, verifique
que puede seleccionar la información de la base de datos mediante el uso de, por ejemplo, psql.
Descripción
pg_dump es un utilitario para volcar una base de datos Postgres en un archivo de script conteniendo comandos
de consulta. Los archivos de script son en formato de texto y pueden ser usados para reconstruir la base de datos,
incluso en otras múquinas y con otras arquitecturas. pg_dump producirú las consultas necesarias para regenerar
todos los tipos definidos por el usuario, funciones, tablas, índices, agregados, y operadores. Adicionalmente,
todos los datos son copiados en formato de texto el cual puede ser nuevamente copiado, también puede ser
importado a herramientas para su edición.
pg_dump es útil para verter el contenido de una base de datos que se vaya a mudar de una instalación de
Postgres a otra. Después de ejecutar pg_dump, se debe examinar el script de salida a ver si contiene alguna
advertencia, especialmente a la luz de las limitaciones citadas en la parte inferior.
Notas
pg_dump tiene pocas limitaciones. Las limitaciones surgen principalmente de la dificultad para extraer ciertas
meta-informaciones de los catúlogos del sistema.
• pg_dump no entiende los índices parciales. La razón es la misma citada anteriormente; los predicados de los
índices parciales se almacenan como planos.
• pg_dump no maneja objetos grandes. Los objetos grandes son ignorados y se debe lidiar con ellos de forma
manual.
Uso
Para volcar una base de datos del mismo nombre que el usuario:
Argumento Descripción
-a Dump only the data, not the schema (data definitions).
Vaciar datos como comandos INSERT (en lugar de COPY). Esto hará
que la restauración sea muy lenta; Es principalmente útil para hacer
vaciados que se pueden cargar en bases de datos no PostgreSQL.
--inserts
Tenga en cuenta que la restauración puede fallar completamente si ha
alterado el orden de las columnas. La opción --column-inserts es más
segura, aunque aún más lenta.
U username
-- El nombre del usuario con el que se conecta.
username=username
Salida
pg_dumpall creará un archivo o escribirá a stdout.
La conexión a la base de datos ’template1’ falló. ConnectDB() falló: ¿Estú postmaster ejecutúndose y aceptando
conexiones en el ’Socket UNIX’ en el puerto ’puerto’? pg_dumpall no pudo conectarse al proceso postmaster en
la múquina y puerto especificados. Si ve usted este mensaje, verifique que postmaster esté ejecutúndose
correctamente en el huésped y puerto que usted especificó. Si su lugar de trabajo usa algún sistema de
autenticación verifique que usted ha obtenido las credenciales de autenticación.
Nota:pg_dumpall ejecuta internamente directivas SELECT. Si tiene problemas ejecutando pg_dumpall, asegúrese
de que puede consultar información de la base de datos usando, por ejemplo, psql.
Descripción
pg_dumpall se diseñó para volcar todas las bases de datos Postgres en un archivo. También vuelca la tabla
pg_shadow, la cual es global para todas las bases de datos. pg_dumpall incluye en este archivo las órdenes
correctas para crear automúticamente cada una de las bases de datos volcadas antes de cargar los datos.
pg_dumpall toma todas las opciones de pg_dump pero -f, -t y base_de_datos deberían ser omitidos. Refiérase a
pg_dump para mús información con respecto a esta otra utilidad.
Uso
Para volcar todas las bases de datos:
Sugerencia: Puede usar la mayoría de las opciones de psql cuando vuelva a cargarlas.
Cron
En el sistema operativo Unix, cron es un administrador regular de procesos en segundo plano (demonio) que
ejecuta procesos o scripts a intervalos regulares (por ejemplo, cada minuto, día, semana o mes). Los procesos
que deben ejecutarse y la hora en la que deben hacerlo se especifican en el archivo crontab. Cron se podría
definir como el "equivalente" a Tareas Programadas de Windows. Los usuarios habilitados para crear su archivo
crontab se especifican en el archivo cron.allow. De manera anúloga, los que no lo tienen permitido figuran en
/etc/cron.d/cron.deny, o /etc/cron.deny, dependiendo de la versión de Unix. Esta sección puede consultarse en
el sitio: https://es.wikipedia.org/wiki/Cron_(Unix)
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# run-parts
01 * * * * root nice -n 19 run-parts /etc/cron.hourly
50 0 * * * root nice -n 19 run-parts /etc/cron.daily
22 4 * * 0 root nice -n 19 run-parts /etc/cron.weekly
42 4 1 * * root nice -n 19 run-parts /etc/cron.monthly
Para agregar, quitar o modificar tareas, hay que editar el crontab. Esto se hace con la orden crontab -e, que
abrirú el editor definido en la variable de entorno EDITOR y cargarú el archivo crontab correspondiente al usuario
que estú logueado. Cada vez que se ejecuta el crontab, se envía un mensaje al usuario que aparece en la variable
de entorno MAILTO, si estú habilitado, indicúndole la tarea realizada.
Sintaxis
1. Minutos: (0-59)
2. Horas: (0-23)
3. Días: (1-31)
4. Mes: (1-12)
5. Día de la semana: (0-6), siendo 1=Lunes, 2=Martes,... 6=súbado y 0=Domingo
Para especificar todos los valores posibles de una variable se utiliza un asterisco (*).
• La última columna corresponde al path absoluto del binario o script que se quiere ejecutar.
Ejemplos
30 10 * * 1 /usr/bin/who >> /home/quien.tex
Ejecuta la orden who todos los lunes a las 10:30 y guarda la salida en el archivo quien.tex Para especificar dos o
más valores en cada variable, estas deben estar separadas por comas, siguiendo con el ejemplo anterior:
En este ejemplo veremos cómo pasarle más de un comando al cron y de paso como puede programarse una
descarga:
A continuación, se listan protocolos que se encuentran incrustados en el sistema operativo Linux y que sirven
para dar solución a la problemática presentada en este documento, la información vertida se ha tomado del sitio:
es.wikipedia.org/wiki
El Modelo FTP
El intérprete de protocolo (PI) de usuario, inicia la conexión de control en el puerto 21. Las órdenes FTP estándar
las genera el PI de usuario y se transmiten al proceso servidor a través de la conexión de control. Las respuestas
estándar se envían desde el PI del servidor al PI de usuario por la conexión de control como respuesta a las
órdenes. Estas órdenes FTP especifican parámetros para la conexión de datos (puerto de datos, modo de
transferencia, tipo de representación y estructura) y la naturaleza de la operación sobre el sistema de archivos
(almacenar, recuperar, añadir, borrar, etc.). El proceso de transferencia de datos (DTP) de usuario u otro proceso
en su lugar, debe esperar a que el servidor inicie la conexión al puerto de datos especificado (puerto 20 en modo
activo o estándar) y transferir los datos en función de los parámetros que se hayan especificado.
La comunicación entre cliente y servidor es independiente del sistema de archivos utilizado en cada ordenador,
de manera que no importa que sus sistemas operativos sean distintos, porque las entidades que se comunican
entre sí son los PI y los DTP, que usan el mismo protocolo estandarizado: el FTP.
También hay que destacar que la conexión de datos es bidireccional, es decir, se puede usar simultáneamente
para enviar y para recibir, y no tiene por qué existir todo el tiempo que dura la conexión FTP.
Servidor FTP
Un servidor FTP es un programa especial que se ejecuta en un equipo servidor normalmente conectado a Internet
(aunque puede estar conectado a otros tipos de redes, LAN, MAN, etc.). Su función es permitir el intercambio de
datos entre diferentes servidores/ordenadores. Por lo general, los programas servidores FTP no suelen
encontrarse en los ordenadores personales, por lo que un usuario normalmente utilizará el FTP para conectarse
remotamente a uno y así intercambiar información con él.
Cliente FTP
Cuando un navegador no está equipado con la función FTP, o si se quiere cargar archivos en un ordenador
remoto, se necesitará utilizar un programa cliente FTP. Un cliente FTP es un programa que se instala en el
ordenador del usuario, y que emplea el protocolo FTP para conectarse a un servidor FTP y transferir archivos, ya
sea para descargarlos o para subirlos. Para utilizar un cliente FTP, se necesita conocer el nombre del archivo, el
ordenador en que reside (servidor, en el caso de descarga de archivos), el ordenador al que se quiere transferir
el archivo (en caso de querer subirlo nosotros al servidor), y la carpeta en la que se encuentra.
Algunos clientes de FTP básicos en modo consola vienen integrados en los sistemas operativos, incluyendo
Windows, DOS, Linux y Unix. Sin embargo, hay disponibles clientes con opciones añadidas e interfaz gráfica.
Aunque muchos navegadores tienen ya integrado FTP, es más confiable a la hora de conectarse con servidores
FTP no anónimos utilizar un programa cliente.
COMANDO Y
ACCIÓN QUE REALIZA
ARGUMENTOS
open servidor Inicia una conexión con un servidor FTP
close o disconnect Finaliza una conexión FTP sin cerrar el programa cliente
Ejemplo de uso:
Ejecución (desde mi equipo) de un proceso de descarga de archivos del equipo 16.20.1.1 (servidor) a mi equipo
local:
Respaldo de la BD.
Las bases de datos de PostgreSQL deben ser respaldadas de forma regular, ya que esta contiene datos valiosos.
El procedimiento es esencialmente simple, y es importante tener una comprensión básica de las técnicas
subyacentes. Existen tres enfoques fundamentales para respaldar una base de datos en PostgreSQL, cada una
tiene fortalezas y debilidades:
• Pg_dump de SQL.
• Respaldo a nivel de sistema de archivos.
• Respaldos en línea.
En el presente documento nos enfocamos el uso del comando pg_dump para efectuar dicho respaldo.
Microsoft propone una estrategia para asegurar la disponibilidad de los datos (https://msdn.microsoft.com/es-
es/library/bb972245.aspx) cuando se usa la herramienta que ellos fabrican: SQL Server, esta misma estrategia
aplica para todas las bases de datos. Esta se presenta a continuación:
Los elementos básicos de una estrategia de disponibilidad de datos son los siguientes:
• Planear el futuro.
• Comprender los registros de transacciones y saber cómo utilizarlos para restaurar datos.
• Realizar copias de seguridad de la base de datos.
• Restaurar los datos.
Creación de una estrategia de copia de seguridad de base de datos Las copias de seguridad de la base de datos
son una parte fundamental en la creación de esta estrategia; sin una estrategia de copias de seguridad efectiva
podríamos encontrarnos en una situación en la que tengamos una base de datos corrupta pero no las suficientes
copias de seguridad para restaurarla.
Los tipos de fallas que podrían ocurrir son las siguientes, entre otras:
• Datos inválidos del usuario.
• Fallo en el disco duro.
• Fallo en el servidor.
Para evitar perderlo todo a causa de un fallo, sigue las siguientes recomendaciones:
• Realiza copias de seguridad con frecuencia (esto depende del uso de la base de datos).
• Mantén copias de seguridad completas fuera del sitio.
• Realiza comprobaciones de consistencia con cierta frecuencia.
• Administra tus copias de seguridad con efectividad.
Modelos de recuperación
SQL soporta los siguientes 3 modelos de recuperación:
A) Recuperación completa: Es el modelo más completo; si se produce un fallo en el disco duro, te permite
recuperar la base hasta el momento justo del fallo o en cualquier momento en el tiempo. Para poder lograr esto
se registran todas las operaciones, lo que hace que el registro crezca demasiado ya que las operaciones masivas
también se registran. Esta es una característica muy poderosa cuando se tiene una base de datos 24 x 7; nos
permite asegurar que se pierda la menor cantidad de modificaciones posible.
B) Registro masivo: Es una copia de seguridad completa. No obstante, si falla el disco duro, puede recuperarse
con el modelo de copia masiva pero no te permite recuperar la base hasta cualquier momento en el tiempo.
C) Recuperación Simple: Es el modelo más sencillo de todos, ocupa el menor espacio en disco y es el que ocupa
menos recursos del sistema, pero también lo expone a mayores pérdidas de datos; este modelo no nos permite
recuperar hasta cualquier momento en el tiempo ni hasta el momento del fallo.
Todos estos modelos tienen ventajas y desventajas; determinar cuál es el mejor de ellos depende de sus
requerimientos individuales. Por ejemplo, una base de datos que tenga muchas transacciones y necesite
recuperarse completamente lo más pronto posible se beneficiaría con el modelo de recuperación completa; por
el contrario, una base de datos que haya tenido muchas actualizaciones masivas y no necesite recuperar las
transacciones individuales de los usuarios podría utilizar el modelo de registro masivo; por último, el modelo
simple se utiliza en aplicaciones que no sean cruciales o en aplicaciones en desarrollo.
El respaldo de las bases de datos se hace fácilmente, antes de realizarlo hay que tomar en cuenta lo siguiente:
• Para respaldar toda la base de datos, sin que no haya nadie trabajando en ella, es necesario detener postgres.
• Para asegurarse de que no hay nadie trabajando es necesario apagar el servicio postgres o hacerlo fuera del
horario laboral. El procedimiento de abajo describe los pasos para realizar el respaldo con la consola del
servidor, es decir desde el equipo en el que está el sistema.
Nota: Para realizarlo desde una estación de trabajo, es necesario conectarse al servidor con aplicaciones como
"VNC", "Rdesktop" o "Secure Shell".
Ahora, levantado el postgres, se puede ejecutar la instrucción para respaldar la base de datos. Si no existe,
conviene crear un directorio donde colocar los archivos con los respaldos. Si existe, se puede ir a ese directorio
con la instrucción: cd nombre_y_ruta_del _directorio, Por ejemplo: cd /usr/local/Respaldos/ más "Enter".
Una forma de saber en qué directorio se encuentra, es ingresando la instrucción "pwd" más "Enter"; esto
desplegará el nombre y la ruta del directorio.
Después de colocarse en el directorio donde se va a generar el respaldo, se ingresa la instrucción para realizarlo.
Esta instrucción es la siguiente:
El sistema la solicita que ingrese la contraseña. Al ingresarla, los caracteres escritos no se despliegan. Después
de ingresar la contraseña, se hace clic en la tecla "Enter". El cursor se coloca en el siguiente renglón y comienza
a producirse el archivo de respaldo de la base de datos. Mientras el cursor no pase al siguiente renglón, no se
debe ingresar nada, pues está generando el respaldo. El tiempo que demora en hacerlo depende del tamaño de
la base de datos. Cuando termine, el cursor se coloca en el siguiente renglón. Si se desea verificar que haya
producido el archivo, se puede ingresar una de las siguientes instrucciones:
Esto listará el archivo recién creado, desplegando además su tamaño y la hora y fecha de creación.
host:puerto:basededatos:usuario:contraseña
Caso Linux
En el ejemplo, el encargado de realizar el backup es el usuario root. Para que funcione, siempre y cuando
tengamos los privilegios, vamos dentro de la carpeta /root y creamos el archivo .pgpass. Una forma rápida, y
presuponiendo que estamos firmados como root, sería la siguiente.
Echo"16.20.1.1:5432:mibase:miusuario:micontraseña" >> ~/.pgpass
Ya resuelto el detalle de la contraseña. Ahora, simplemente, creamos un archivo que será el que vamos a
programar para que se ejecute automáticamente y nos realice el backup. Dentro de nuestro script pondremos
el comando:
-- Modifique los directorios apropiados a su equipo, asegurese de tener todos los derechos
-- sobre los directorios a usar
Ahora cuando el script necesite la contraseña para conectarse, la tomará del Pgpass… y asunto resuelto.
Caso Windows
Para usarlo, debemos crear la carpeta postgresql dentro de c:\documents and settings\(usuario que correrá la
tarea)\datos de programa. Dentro de esa nueva carpeta, pondremos el archivo pgpass.conf. Ahora sí, dentro del
archivo, podríamos tener los siguientes parámetros:
16.20.1.1:5432:mibase:miusuario:micontraseña
c:\postgresql stop
/etc/init.d/postgresql start
pg_dump -C -u uacme > c:\respaldos\BDUACME20080810
Exportación de Datos.
Suponga que el rector de UACME ha decidido cambiar la base de datos PostgreSQL por la que se denomina
MySQL (www.sun.com/software/products/mysql/getit.jsp), por lo que ha solicitado al departamento de
Tecnologías de Información que se ponga en marcha el proyecto pertinente. La base de datos MySQL, va a
funcionar sobre un equipo al que se la ha instalado un sistema operativo Linux. Sin embargo, el rector ha sugerido
que no está dispuesto a pagar personal adicional para que capture la información del sistema viejo (sobre
PostgreSQL) al nuevo (sobre MySQL), por lo que solicita que se busque la forma de hacer un traspaso de
información de un sistema a otro.
Pasos a efectuar para Exportar datos (PostgreSQL -> MySQL): Genere el archivo de datos de texto para las tablas
en equipo origen (Windows).
-- Cuidado con la ruta donde se almacena el archivo de texto -- “/area_trabajo/ es equivalente a decir
“c:\area_trabajo\” -- el directorio area_trabajo ya debe de existir copy profesores to '/area_trabajo/prof.txt' with
delimiter ','; -- replique el comando para cada una de las tablas, cambiando nombre de tabla -- y el nombre del
archivo de texto
Verifique que esté instalado el servidor FTP en el equipo destino (Linux-Ubuntu ver7.10)
-- Instale el archivo vsftpd (servidor FTP)
-- verifique los pasos en la página:
-- guia-ubuntu.org/index.php?title=Servidor_de_FTP
Cree una cuenta de usuario con privilegios de administrador en el equipo destino (Linux)
-- Menú sistema->administración->Usuarios y grupos
-- Indique como directorio raíz de esta cuenta /home/<usuario>
cd /home/<usuario>
ls –l
cd /area_trabajo
$ ftp -i 16.20.10.20
# bin
# put prof.txt
..
-- PUT se repite por cada archivo que se envía
# quit
mysql -u root -p
Importación de datos.
Después de tres años de trabajar con MySQL, el rector ha decidido que el pago de mantenimiento del equipo
SunFire es demasiado caro y nuevamente decide a que se regrese a trabajar con PostgreSQL sobre un equipo
Linux. Como ya se hizo anteriormente solicita que la información del sistema de información se ejecute de forma
automatizada.
Trabajo Adicional
• Restaure los archivos generados con el respaldo, usando el comando pg_restore.
• Respalde la tabla de Profesores de la BD uacme.
• Averigüe si los comandos de Importación y Exportación de datos existen en las bases de datos: DB2, Informix,
Oracle, y Sybase. De ser posible, consiga los DBMS vía descarga en línea y efectúe las pruebas necesarias.
• Inserte los datos de la tabla Profesores en una hoja de cálculo (Excel de MS Office, Calc de OpenOffice, etc),
y busque una estrategia para convertir el formato propietario a un formato de archivo de texto delimitado
por comas, el resultado de esta conversión debe de ser transferido a la tabla Profesores de PostgreSQL o
MySQL usando los comandos que ya ha practicado.
6. Referencias
Douglas Korry y Susan Douglas. (2003) PostgreSQL A comprehensive guide to building, programming and
administering Postgre SQL databases. (2nd. Edition). Sams
Elmasri, R.; Navathe, S.B. (2002). Fundamentos de Sistemas de Bases de Datos. 3ª Edición. Addison-Wesley
Garcia-Molina, Jeffrey Ullman y Jennifer Widom. (2008). Database systems: the complete book. Prentice-Hall.
Momjiam Bruce. (2001). PostgreSQL Introduction and Concepts. Boston: Addison-Wesley Logman Publishing Co.
Inc.
Silberschatz Abraham, Henry Korth y S. Sudarshan. (2006). Fundamentos de Base de Datos (5a. Edición). España:
McGraw-Hill
The PostgreSQL Global Development Group. (2015). Manual de postgreSQL. Disponible en www.postgresql.org