Sei sulla pagina 1di 77

ADMINISTRACIÓN DE BASE DE DATOS CON POSTGRESQL – LABORATORIOS

LABORATORIO 1. CONTROL DE USUARIO


La serie de laboratorios de Administración de Bases de Datos con PostgreSQL, muestra de forma práctica la
administración de este tipo de sistemas, el cual tiene un amplio uso en la industria de desarrollo de software.
Mientras que las bases de datos son la herramienta que requieren las empresas que necesitan almacenar la
información que generan, es en este tipo de sistemas donde se guarda ésta. De ahí la importancia de entender
y aplicar los conceptos de administración estándar que se usa en la industria. Se usa el sistema PostgreSQL debido
a que ofrece los mecanismos que tienen otros sistemas similares, pero de carácter propietario. PostgreSQL se
ofrece bajo una licencia PostgresSQL, lo que permite desde el punto de vista del propietario de un sistema de
información evitar el pago de costosas licencias por el uso de una base de datos.

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.

Como se ha mencionado previamente la herramienta tiene características y lenguajes de programación estándar


que ofrecen sistemas propietarios, por lo que los ejemplos fácilmente pueden ser aplicados en otros sistemas de
bases de datos del mercado, o pueden ser referencia para aplicar los conceptos en proyectos industriales. Por lo
que puedan servir como consulta a profesionales de las Ciencias de la Computación.
Objetivo
El lector aprenderá a administrar grupos y usuarios que acceden a una base de datos, así como a otorgar y revocar
privilegios para limitar sus actividades usando las herramientas que ofrece 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

Partes que componen este laboratorio:


1. Proyecto a desarrollar
2. Conceptos básicos
3. Preparación del ambiente de trabajo
4. Problemática a resolver
5. Trabajo adicional
6. Referencias

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.

Proyecto Universidad ACME


En UACME, se ofrecen dos tipos de cursos en el periodo especial de verano, en que se imparten cursos de verano
y cursos extracurriculares. Los primeros son materias que un alumno regular que estudia una carrera cursa en
este periodo, se le permite adelantar hasta dos materias; mientras que los segundos son cursos especiales de
capacitación que se ofrecen a alumnos regulares como estudiantes o profesionistas externos.

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.

UACME tiene dos departamentos que intervienen en la administración de los cursos:


A) Departamento de Administración (DA) y B) Departamento de Control Escolar (DCE). Corresponde al DA,
efectuar el pago a los docentes y los cobros a los alumnos. El DA es dirigido por el C.P. Ávila y es auxiliado por el
Sr. Cancino. Mientras que el DCE, es dirigido por el Lic. Barroso y auxiliado por los Sras. Tirado, Martínez, Aquino
y Ramos y es en éste donde se decide qué cursos se imparten en el periodo, quién los imparte, y se aceptan las
solicitudes de los alumnos. Un caso especial, es el de los Profesores, ya que el DA es quién les puede modificar
el sueldo quincenal, mientras que el DCE ni siquiera puede visualizar este. Lo curioso es que el DCE es quien
acepta los docentes y los registra en el sistema, pero es el DA donde se captura el sueldo. Importante es para la
administración de la UACME que esta política se aplique al pie de la letra, y que sea implementado directamente
sobre la DB. A continuación, se describe detalladamente las tablas a las cuales tiene acceso el personal.

Tablas a las que se le permite el acceso al personal de la Secretaría Administrativa:


Cuenta Cheques, Cheque, Tabulador, Profesores, Concepto, Recibo, y Detalle Recibo.
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 en Internet.

Administrando Cuentas de Usuario


Como un administrador de PostgreSQL, quizá sea responsable de crear cuentas de usuarios y grupos. Quizá sea
responsable también de otorgar y revocar privilegios.
En la mayor parte de los ambientes, hay un mapeo uno a uno entre la identidad de los usuarios en el sistema
operativo y la identidad de PostgreSQL. En efecto, tu nombre de usuario en PostgreSQL es frecuentemente
identificado con tu nombre de usuario del sistema operativo.

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.

Privilegios (CREATEDB y CREATEUSR)


Cuando se crea un nuevo usuario, se puede controlar algunas de las actividades que estos realizan en la base de
datos, tal como el permiso de crear nuevas bases de datos. También puede controlar la actividad de crear nuevos
usuarios. Dar al usuario el derecho de crear nuevas bases de datos o crear nuevos usuarios es un riesgo. Cuando
asigna privilegios a un usuario con CREATEUSER, ese usuario llega a ser un súper usuario en el clúster. Se debe
decir que ésta es una forma ligeramente diferente: un usuario que tiene privilegios por CREATEUSER puede
sobrepasar todas las restricciones en el clúster de base de datos. Se puede negar explícitamente los privilegios
con CREATEUSER especificando NOCREATEUSER, NOCREATEUSER es asumido si no se específica otro valor.

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:

CREATE GROUP nombre_grupo [ [WITH] option [...]]

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.

Puede asignarse un miembro a un grupo de tres maneras:


• Usar la opción IN GROUP en el comando CREATE USER
• Lista los nombres de usuarios en el USER opción de CREATE GROUP
• Cambia los miembros del grupo usando el comando ALTER GROUP

Un típico comando es CREATE GROUP con el que quizá se vea algo como esto:

CREATE GROUP desarrolladores USER Bernardo, lety;


[ [WITH] option]...

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.

La sintaxis completa para el comando CREATE USER es:

CREATE USER nombre_usuario


[ [WITH] option]...
option := SYSID user-id-number
| [NO] CREATEDB
| [NO] CREATEUSER
| IN GROUP groupname[, ...]
| [ [UN] ENCRYPTED] PASSWORD ‘password’
| VALID UNTIL ‘expiration’

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:

CREATE RULE name AS ON event


TO object [ WHERE condition]
DO [ INSTEAD] [ action | NOTHING]
- name - El nombre de la regla a crear.
- event - Evento puede ser select, update, delete o insert.
- object - Objeto puede ser table o table.column.
- condition - Cualquier clausula, SQL WHERE, New o Current, pueden aparecer en lugar de una variable de
instancia siempre que una variable de instancia es admisible en SQL.
- action - Cualquier clausula SQL, New o Current pueden aparecer en lugar de una variable de instancia siempre
que una variable de instancia sea admisible en SQL.

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.

ON UPDATE TO emp.salary WHERE emp.name = "Joe"


DO UPDATE emp ( ... ) WHERE ...

ON UPDATE TO emp-1.salary WHERE emp-2.name = "Joe"


DO UPDATE emp-3 ( ... ) WHERE ...

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.

3. Preparación del ambiente de trabajo


Para poder aplicar los conceptos descritos en este laboratorio es necesario tener una base de datos en la cual
aplicar las restricciones que requiere el proyecto de trabajo.

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.

Esquemas para el diagrama E-R de la Universidad ACME:


Los nombres de los campos en algunos casos fueron cambiados, con respecto del diagrama E-R, por motivos de
tamaños del nombre, sin embargo, los conceptos son los mismos.

CuentaCheques (ncuenta, saldo, banco)


Cheque (ncuenta, cns, total, fecha);
Tabulador (idtab, importehora);
Profesores (idprofe, idtab, nombre, maximo, sueldo);
CursosEspeciales (idcurso, idprofe, cns, fini, ffin);
CursosExtracurricular (idextra, decextra, nhorascurso);
Materias (nmat, des, horacurso);
CEVerano (idcurso, nmat);
CEExtracurricula (idcurso, idextra);
Alumnos (matricula, nombre);
Bimestre (matricula, periodo, nmat, calificacion, faltas);
Faltas (matricula, fecha);
Concepto (idconcepto, desconcepto);
Recibo (folio, matricula, fecharec, totalrec);
DetalleRecibo (folio, cns, idconcepto, subtotal);
CalendarioEscolar (fecha, motivo);

Tablas para el diagrama E-R de la Universidad ACME:


Los siguientes comandos de creación de tablas, inserción de datos y creación de privilegios 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. Si durante el proceso de instalación de PostgreSQL, no ha creado un acceso directo para el programa
psql, lo puede encontrar en la siguiente dirección: C:\Program Files\PostgreSQL\9.3\bin y construya el acceso
directo. Ejecute el programa PSQL del postgreSQL (Shell de postgreSQL) y "copie" cada uno de los siguientes
comandos y "péguelo" en el psql.
-- Creando la base de datos UACME

CREATE DATABASE uacme;

-- Cambiarse de la BD por omisión a la ACME (en PSQL)

\c UACME

--Creación de las tablas

CREATE TABLE CuentaCheques (


ncuenta int,
saldo numeric (7,2),
banco varchar,
primary key (ncuenta)
);

CREATE TABLE Cheque (


ncuenta int,
cns int,
total numeric (10,2),
fecha date,
foreign key (ncuenta) references CuentaCheques,
primary key (ncuenta, cns)
);

CREATE TABLE Tabulador (


idtab int,
importehora varchar,
primary key(idtab)
);

CREATE TABLE Profesores (


idprofe int,
idtab int,
nombre varchar,
maximo varchar,
sueldo float, foreign key (idtab) references Tabulador,
primary key (idprofe)
);

CREATE TABLE CursosEspeciales (


idcurso int,
idprofe int,
fini varchar,
ffin varchar,
ncuenta int,
cns int,
foreign key (idprofe) references Profesores,
foreign key (ncuenta, cns) references Cheque,
primary key (idcurso)
);

CREATE TABLE CursosExtracurricular (


idextra int primary key,
decextra text,
nhorascurso int
);

CREATE TABLE Materias (


nmat int,
des varchar,
horacurso int,
primary key(nmat)
);

CREATE TABLE CEVerano (


idcurso int primary key,
nmat int,
foreign key (nmat) references Materias
);

CREATE TABLE CEExtracurricula (


idcurso int primary key,
idextra int,
foreign key (idextra) references CursosExtracurricular
);

CREATE TABLE Alumnos (


matricula int,
nombre varchar,
primary key (matricula)
);

CREATE TABLE Bimestre (


periodo int,
matricula int,
nmat int,
calificacion int,
Faltas float,
foreign key (nmat) references Materias,
foreign key (matricula) references Alumnos,
primary key (matricula, periodo)
);

CREATE TABLE Faltas (


fecha varchar,
matricula int,
foreign key(matricula) references Alumnos,
primary key(matricula, fecha)
);

CREATE TABLE Concepto (


idconcepto int,
desconcepto varchar,
primary key (idconcepto)
);

CREATE TABLE Recibo (


folio int,
matricula int,
fecharec varchar,
totalrec float,
foreign key (matricula) references Alumnos,
primary key (folio)
);

CREATE TABLE DetalleRecibo (


cns int,
idconcepto int,
folio int,
subtotal float,
foreign key (idconcepto) references Concepto,
foreign key (folio) references Recibo,
primary key (folio, cns)
);

CREATE TABLE CalendarioEscolar (


fecha varchar primary key,
motivo varchar
);

Inserción de datos para algunas tablas recién construidas.


Los datos insertados sólo sirven para demostrar el funcionamiento de los privilegios de acceso, queda en manos
del usuario insertar datos en el resto de las tablas para demostrar que las reglas de acceso son funcionales para
cada usuario.

INSERT INTO CuentaCheques VALUES (1,700,'HSBC');


INSERT INTO CuentaCheques VALUES (2,9000,'HSBC');
INSERT INTO CuentaCheques VALUES (3,60,'HSBC');
INSERT INTO CuentaCheques VALUES (4,10,'HSBC');
INSERT INTO CuentaCheques VALUES (5,1000,'HSBC');
INSERT INTO CuentaCheques VALUES (6,200,'HSBC');
INSERT INTO CuentaCheques VALUES (1,10,200,'2008-02-01');
INSERT INTO CuentaCheques VALUES (2,10,575.20,'2008-02-01');
INSERT INTO CuentaCheques VALUES (2,20,20,'2008-02-01');
INSERT INTO CuentaCheques VALUES (3,10,600,'2007-02-01');
INSERT INTO CuentaCheques VALUES (4,10,800,'2007-02-01');
INSERT INTO CuentaCheques VALUES (5,10,100,'2007-02-01');
INSERT INTO CuentaCheques VALUES (6,10,300,'2007-02-01');

INSERT INTO Tabulador VALUES (10,100);


INSERT INTO Tabulador VALUES (20,200);
INSERT INTO Tabulador VALUES (30,300);
INSERT INTO Tabulador VALUES (40,400);
INSERT INTO Tabulador VALUES (50,500);
INSERT INTO Tabulador VALUES (60,600);
INSERT INTO Tabulador VALUES (70,700);

INSERT INTO Profesores VALUES (1,40,'Roberto','Maestria',15000);


INSERT INTO Profesores VALUES (2,70,'Carlos','Doctorado',25000);
INSERT INTO Profesores VALUES (3,20,'Luis','Licenciatura',6000);
INSERT INTO Profesores VALUES (4,30,'Yunuan','Maestria',12000);
INSERT INTO Profesores VALUES (5,10,'Julio','Licenciatura',4500);
INSERT INTO Profesores VALUES (6,20,'Samuel','Licenciatura',5500);

INSERT INTO CursosEspeciales VALUES (1,1,1,20070204,20050204);


INSERT INTO CursosEspeciales VALUES (2,2,2,20070204,20050204);
INSERT INTO CursosEspeciales VALUES (3,3,3,20070204,20050204);
INSERT INTO CursosEspeciales VALUES (4,4,4,20070204,20050204);
INSERT INTO CursosEspeciales VALUES (5,5,5,20070204,20050204);

INSERT INTO CursosExtracurricular VALUES (1,'admin',204);


INSERT INTO CursosExtracurricular VALUES (2,'diseño',204);
INSERT INTO CursosExtracurricular VALUES (3,'bdd',204);
INSERT INTO CursosExtracurricular VALUES (4,'java',204);

INSERT INTO Materias VALUES (1,'admin bdd',204);


INSERT INTO Materias VALUES (2,'redes',204);
INSERT INTO Materias VALUES (3,'redes 2',204);
INSERT INTO Materias VALUES (4,'admin bdd',204);

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

Creación de los grupos de usuarios


Se han elegido los nombres de grupos Admin para la DA y Escolar para el DCE.

-- Creando los grupos de usuarios

CREATE GROUP admin;


CREATE GROUP escolar;

Creación de usuarios del grupo Administración


Se les ha asignado como password el nombre del grupo, pero esto se hace por facilidad, en la práctica cada
usuario debe elegir un password personalizado.

-- Creando los usuarios del grupo administrativo

CREATE USER avila WITH PASSWORD 'admin' IN GROUP admin;


CREATE USER cancino WITH PASSWORD 'admin' IN GROUP admin;

Creación de usuarios del grupo Escolar


Se les ha asignado como password el nombre del grupo, pero esto se hace por facilidad, en la práctica cada
usuario debe elegir un password personalizado.

-- Creando los usuarios del grupo escolar

CREATE USER barroso WITH PASSWORD 'escolar' IN GROUP ESCOLAR;


CREATE USER tirado WITH PASSWORD 'escolar' IN GROUP ESCOLAR;
CREATE USER martinez WITH PASSWORD 'escolar' IN GROUP ESCOLAR;
CREATE USER aquino WITH PASSWORD 'escolar' IN GROUP ESCOLAR;
CREATE USER ramos WITH PASSWORD 'escolar' IN GROUP ESCOLAR;

Otorgamiento de privilegios de acceso sobre las tablas del sistema


Para otorgar privilegios de acceso la junta directiva de UACME ha autorizado el acceso sobre las siguientes tablas
para cada departamento:
Tablas a las que se le permite el acceso al grupo Administración

CuentaCheques (ncuenta, saldo, banco)


Cheque (ncuenta, cns, total, fecha);
Tabulador (idtab, importehora);
Profesores (idprofe, idtab, nombre, maximo, sueldo);
Concepto (idconcepto, desconcepto);
Recibo (folio, matricula, fecharec, totalrec);
DetalleRecibo (folio, cns, idconcepto, subtotal);

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

CursosEspeciales (idcurso, idprofe, cns, fini, ffin);


CursosExtracurricular (idextra, decextra, nhorascurso);
Materias (nmat, des, horacurso);
CEVerano (idcurso, nmat);
CEExtracurricula (idcurso, idextra);
Alumnos (matricula, nombre);
Bimestre (matricula, periodo, nmat, calificacion, faltas);
Faltas (matricula, fecha);
CalendarioEscolar (fecha, motivo);

Caso especial de profesores para el grupo Escolar


La forma en que evitaremos que el grupo escolar vea el sueldo del docente es creando una vista y asignando
privilegios por separado.

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

CREATE VIEW VistaProfesoresEscolar AS SELECT idprofe,idtab,nombre,maximo FROM Profesores;

Otorgando los privilegios en la BD al grupo Administración en el SQL


-- Todos los privilegios para las tablas del sistema administrativo

GRANT all ON table Cheque to group admin;


GRANT all ON table CuentaCheques to group admin;
GRANT all ON table Tabulador to group admin;
GRANT all ON table Concepto to group admin;
GRANT all ON table Recibo to group admin;
GRANT all ON table DetalleRecibo to group admin;

-- Solo puede consultar y actualizar la tabla de profesores a los usuarios del grupo admin.

GRANT select, update ON table Profesores to group admin;


-- Solo se permite consultar estas tablas a los usuarios del grupo admin.

GRANT select ON table CursosExtracurricular to group admin;


GRANT select ON table CEVerano to group admin;
GRANT select ON table CEExtracurricula to group admin;
GRANT select ON table CursosEspeciales to group admin;

Otorgando los privilegios en la BD al grupo Escolar en el SQL


-- Otorgando privilegios sobre las tablas del sistema escolar.

GRANT all ON table Materias to group escolar;


GRANT all ON table CursosExtracurricular to group escolar;
GRANT all ON table CEVerano to group escolar;
GRANT all ON table CEExtracurricula to group escolar;
GRANT all ON table CursosEspeciales to group escolar;
GRANT all ON table Alumnos to group escolar;
GRANT all ON table Faltas to group escolar;
GRANT all ON table Bimestre to group escolar;
GRANT all ON table CalendarioEscolar to group escolar;

-- Otorgando permisos sobre la vista de profesores


GRANT all ON table VistaProfesoresEscolar to group escolar;

Prueba de los privilegios asignados a los usuarios


Para conectarse a la base de datos con un usuario diferente a postgres (ver Figura 2) busque en el directorio
"C:\Program Files\PostgreSQL\9.3\bin" el comando psql e indíquele a cual base de datos se desea conectar (para
nuestro caso -d uacme) y el usuario que va a usar (-U barroso), una vez hecho esto PostgreSQL le solicita el
password para el usuario barroso y en caso de ser correcto se despliega el shell de la BD. El ejemplo está
desarrollado sobre la plataforma Windows. Intente conectarse con los diferentes usuarios que ha creado
previamente.

Conectado a la BD uacme con el usuario barroso


Intente los siguientes comandos:

SELECT * FROM Profesores;


SELECT * FROM VistaProfesoresEscolar;
SELECT * FROM CuentaCheques;
SELECT * FROM Cheque;

INSERT INTO Profesores VALUES (7, 20, 'Jesus', 'Licenciatura', 25000);


INSERT INTO VistaProfesoresEscolar VALUES (7, 20, 'Jesus', 'Licenciatura', 25000);

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:

CREATE or REPLACE RULE insertar_profesores AS ON insert TO VistaProfesoresEscolar DO INSTEAD insert


into profesores values (
new.idprofe,
new.idtab,
new.nombre,
new.maximo, 0
);

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:

INSERT INTO VistaProfesoresEscolar VALUES (7, 20, 'Jesus', 'Licenciatura');

Conectado a la BD uacme con el usuario avila, intente los siguientes comandos:

SELECT * FROM Profesores;


SELECT * FROM VistaProfesoresEscolar;
SELECT * FROM CuentaCheques;
SELECT * FROM Cheque;

UPDATE Profesores set sueldo = 6000 WHERE idprofe = 7;

INSERT INTO Profesores VALUES (8, 30, 'Salvador', 'Maestria', 20000);


INSERT INTO VistaProfesoresEscolar VALUES (8, 30, 'Salvador', 'Maestria');

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.

Como se ha mencionado previamente, la herramienta tiene características y lenguajes de programación estándar


que ofrecen sistemas propietarios, por lo que los ejemplos fácilmente pueden ser aplicados en otros sistemas de
bases de datos del mercado, o pueden ser referencia para aplicar los conceptos en proyectos industriales. Por lo
que puedan servir como consulta a profesionales de las Ciencias de la Computación.

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.

Partes que componen este laboratorio:


1. Proyecto a desarrollar
2. Conceptos básicos
3. Preparación del ambiente de trabajo
4. Problemática a resolver
5. Trabajo adicional
6. Referencias

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.

Proyecto Universidad ACME


En UACME, se ofrecen dos tipos de cursos en el periodo especial de verano, en el cual se imparten cursos de
verano y cursos extracurriculares. Los primeros son materias que un alumno regular que estudia una carrera
cursa en este periodo, se le permite adelantar hasta dos materias; mientras que los segundos son cursos
especiales de capacitación que se ofrecen a alumnos regulares como estudiantes o profesionistas externos.

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.

UACME tiene dos departamentos que intervienen en la administración de los cursos:


A) Departamento de Administración (DA) y B) Departamento de Control Escolar (DCE). Corresponde al DA,
efectuar el pago a los docentes y los cobros a los alumnos. El DA es dirigido por el C.P. Ávila y es auxiliado por el
Sr. Cancino. Mientras que el DCE, es dirigido por el Lic. Barroso y auxiliado por los Sras. Tirado, Martínez, Aquino
y Ramos y es en este dónde se decide cuales cursos se imparten en el periodo, quién los imparte, y se aceptan
las solicitudes de los alumnos. Un caso especial, es el de los Profesores, ya que el DA es quién les puede modificar
el sueldo quincenal, mientras que el DCE ni siquiera puede visualizar éste. Lo curioso radica en que, es el DCE
quién acepta los docentes y los registra en el sistema, pero es el DA donde se captura el sueldo. Importante es
para la administración de la UACME que esta política se aplique al pie de la letra, y que sea implementado
directamente sobre la DB. A continuación, se describe detalladamente las tablas a las cuales tiene acceso el
personal de cada.

Tablas a las que se le permite el acceso al personal de la Secretaría Administrativa:

CuentaCheques, Cheque, Tabulador, Profesores, Concepto, Recibo, y DetalleRecibo.

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.

USO DE NOT NULL


La restricción NOT NULL evita valores NULOS que aparecen en las columnas. La inserción de un valor NULL, o un
INSERT que podría reunir una columna 2 con valor NULL, causarían que el INSERT falle.
UNIQUE (Único)
La restricción UNIQUE previene valores duplicados que se almacenan en la misma en la columna. CREATE TABLE
despliega el nombre del índice único creado. Si una restricción UNIQUE es de múltiples campos, debe separar el
UNIQUE con una línea para especificar las columnas que componen la restricción.
PRIMARY KEY (Llave Primaria)
Una llave primaria indica que una columna o grupo de columnas puede ser usado como un identificar único de
renglones en la tabla. (Esto es una consecuencia directa de la definición de llave primaria. Dese cuenta que una
restricción única por sí misma no provee un identificador único porque no excluye valores nulos).

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.

FOREIGN KEY/REFERENCES (Llave foránea/Referencia)


Una restricción de llave foránea especifica que los valores en una columna (o un grupo de columnas) deben de
coincidir con los valores que aparecen en alguna columna de otra columna. Decimos que esto mantiene la
integridad referencial entre dos tablas relacionadas.

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.

Modificación de la llave primaria


Si la restricción de una llave foránea referencia a una fila como su llave primaria, y la fila de la llave primaria es
actualizada o eliminada, entonces la acción por omisión de la llave foránea es restringir la operación. Las opciones
de llave foránea ON UPDATE y ON DELETE, sin embargo, permiten tomar una acción diferente.

Las opciones ON UPDATE y ON DELETE pueden tener las siguientes acciones:


• CASCADE UPDATE actualiza la llave primaria de todas las columnas referenciadas por ella.
• DELETE de la llave primaria causa la eliminación de todas las filas llaves primarias que son referencias por
ella.
• SET NULL UPDATE y DELETE a la fila de la llave primaria causa que la llave primaria sea colocada a NULL.
• El NO ACTION es la acción por omisión.

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.

Multi-columnas en Llaves Primarias y Llaves Foráneas


Para especificar una llave primaria multi-columna, es necesario escribir por separado el comando PRIMARY KEY
en la sentencia CREATE TABLE. Una clave foránea multi-columna tiene los mismos requerimientos, por lo que es
necesario escribir el comando FOREIGN KEY por separado.

Manejando valores nulos en las claves foráneas


Un valor NULL no puede referenciar a una llave primaria. Una única columna de llave foránea es un NULL o
coincidir con una llave primaria. En una multi-columna de llave foránea, algunas veces solo una parte de la llave
foránea puede ser NULL. El comportamiento por default permite que algunas columnas en una multi-columna
Foreign Key sea NULL y otras no sean NOT NULL.

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.

Checando frecuentemente la clave foránea


Por default, las restricciones de foreign key son comprobadas al finalizar cada consulta de INSERT, UPDATE, y
DELETE. Así, si realiza una modificación compleja, la restricción de la llave foránea debe quedar validada en todo
momento.

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.

Regla de integridad referencial


Cuando se define una columna como clave foránea, las filas de la tabla pueden contener en esa columna o bien
el valor nulo (ningún valor), o bien un valor que existe en la otra tabla, un error sería asignar a un habitante una
población que no está en la tabla de poblaciones. Eso es lo que se denomina integridad referencial y consiste en
que los datos que referencian otros (claves foráneas) deben ser correctos. La integridad referencial hace que el
sistema gestor de la base de datos se asegure de que no haya en las claves foráneas valores que no estén en la
tabla principal. A continuación, se muestra el enunciado:

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

3. Preparación del ambiente de trabajo


Para poder aplicar los conceptos descritos en este laboratorio es necesario tener una base de datos en la cual
aplicar las restricciones que requiere el proyecto de trabajo. Uno de los trabajos adicionales que el lector debe
realizar es el de integrar los conceptos explicados en el Laboratorio 1 y el 2 en una sola base de datos, con el fin
de obtener experiencia práctica. Por lo que en el este laboratorio usaremos una nueva base de datos, distinta a
la usada en el "Laboratorio 1. Control de Usuarios".

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.

Esquemas para el diagrama E-R de la Universidad ACME:


Los nombres de los campos en algunos casos fueron cambiados, con respecto del diagrama E-R, por motivos de
tamaños del nombre, sin embargo, los conceptos son los mismos.

CuentaCheques (ncuenta, saldo, banco)


Cheque (ncuenta, cns, total, fecha);
Tabulador (idtab, importehora);
Profesores (idprofe, idtab, nombre, maximo, sueldo);
CursosEspeciales (idcurso, idprofe,cns,fini,ffin);
CursosExtracurricular (idextra, decextra, nhorascurso);
Materias (nmat, des, horacurso);
CEVerano (idcurso, nmat);
CEExtracurricula (idcurso, idextra);
Alumnos (matricula, nombre);
Bimestre (matricula, periodo, nmat, calificacion, faltas);
Faltas (matricula, fecha);
Concepto (idconcepto, desconcepto);
Recibo (folio,matricula, fecharec, totalrec);
DetalleRecibo (folio, cns, idconcepto, subtotal);
CalendarioEscolar (fecha, motivo);

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

3.2 Solución a los problemas planteados


Ahora pasamos de las políticas a los comandos necesarios en PostgreSQL que dan solución a los problemas
planteados, esta propuesta requiere que la base de datos sea reconfigurada y para visualizar con detalle estos
cambios, se sugiere que compare las que se crearon en el Laboratorio 1 contra aquellas que se modifican en este
laboratorio. Los cambios que usted descubre, son las restricciones que se están aplicando en la base de datos.

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

CREATE DATABASE uacmerest;

-- Cambiarse de la BD por omisión a la ACME (en PSQL)

\c uacmerest

--Creación de las tablas


-- la llave primaria no puede aceptar valores nulos

CREATE TABLE cuentacheques (


ncuenta integer NOT NULL,
saldo numeric(7,2),
banco varchar NOT NULL,
CONSTRAINT cuentacheques_pkey PRIMARY KEY (ncuenta)
);

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

CREATE TABLE cheque (


ncuenta integer NOT NULL,
cns integer NOT NULL,
total numeric(10,2) CONSTRAINT importe_invalido CHECK ( total > 0 ),
fecha date CONSTRAINT fecha_invalida CHECK (fecha < now() ),
CONSTRAINT cheque_pkey PRIMARY KEY (ncuenta, cns),
CONSTRAINT cheque_ncuenta_fkey FOREIGN KEY (ncuenta)
REFERENCES cuentacheques (ncuenta) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE CASCADE
);

-- la llave primaria no puede aceptar valores nulos y El campo importehora debe ser mayor o igual a cero

CREATE TABLE tabulador (


idtab integer NOT NULL,
importehora varchar NOT NULL CONSTRAINT importehora_invalido CHECK ( importehora > 0 ),
CONSTRAINT tabulador_pkey PRIMARY KEY (idtab)
);

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

CREATE TABLE profesores (


idprofe integer NOT NULL,
idtab integer,
nombre varchar NOT NULL,
maximo varchar NOT NULL,
sueldo double precision CONSTRAINT sueldo_invalido CHECK (sueldo > 0 ),
CONSTRAINT profesores_pkey PRIMARY KEY (idprofe),
CONSTRAINT profesores_idtab_fkey FOREIGN KEY (idtab)
REFERENCES tabulador (idtab) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
);

-- la llave primaria no puede aceptar valores nulos

CREATE TABLE cursosespeciales (


idcurso integer NOT NULL,
idprofe integer,
fini varchar,
ffin varchar,
ncuenta integer,
cns integer,
CONSTRAINT cursosespeciales_pkey PRIMARY KEY (idcurso),
CONSTRAINT cursosespeciales_ncuenta_fkey FOREIGN KEY (ncuenta, cns)
REFERENCES cheque (ncuenta, cns) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
);

-- la llave primaria no puede aceptar valores nulos

CREATE TABLE cursosextracurricular (


idextra integer NOT NULL,
decextra text,
nhorascurso integer,
CONSTRAINT cursosextracurricular_pkey PRIMARY KEY (idextra)
);

-- la llave primaria no puede aceptar valores nulos

CREATE TABLE materias (


nmat integer NOT NULL,
des varchar NOT NULL,
horacurso integer NOT NULL,
CONSTRAINT materias_pkey PRIMARY KEY (nmat)
);

CREATE TABLE ceverano (


idcurso integer NOT NULL,
nmat integer,
CONSTRAINT ceverano_pkey PRIMARY KEY (idcurso),
CONSTRAINT ceverano_nmat_fkey FOREIGN KEY (nmat)
REFERENCES materias (nmat) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE CASCADE
);
CREATE TABLE ceextracurricula (
idcurso integer NOT NULL,
idextra integer,
CONSTRAINT ceextracurricula_pkey PRIMARY KEY (idcurso),
CONSTRAINT ceextracurricula_idextra_fkey FOREIGN KEY (idextra)
REFERENCES cursosextracurricular (idextra) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE CASCADE
);

CREATE TABLE alumnos (


matricula integer NOT NULL,
nombre varchar NOT NULL,
CONSTRAINT alumnos_pkey PRIMARY KEY (matricula)
);

CREATE TABLE bimestre (


periodo integer NOT NULL,
matricula integer NOT NULL,
nmat integer,
calificacion integer,
faltas double precision,
CONSTRAINT bimestre_pkey PRIMARY KEY (matricula, periodo),
CONSTRAINT bimestre_matricula_fkey FOREIGN KEY (matricula)
REFERENCES materias (nmat) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT bimestre_matricula_fkey1 FOREIGN KEY (matricula)
REFERENCES alumnos (matricula) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
);

CREATE TABLE faltas (


fecha varchar NOT NULL,
matricula integer,
CONSTRAINT faltas_pkey PRIMARY KEY (fecha),
CONSTRAINT faltas_matricula_fkey FOREIGN KEY (matricula)
REFERENCES alumnos (matricula) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
);

CREATE TABLE concepto (


idconcepto integer NOT NULL,
desconcepto varchar NOT NULL,
CONSTRAINT concepto_pkey PRIMARY KEY (idconcepto)
);

CREATE TABLE recibo (


folio integer NOT NULL,
matricula integer,
fecharec varchar,
totalrec double precision CONSTRAINT totalrec_invalido CHECK ( totalrec > 0 ),
CONSTRAINT recibo_pkey PRIMARY KEY (folio),
CONSTRAINT recibo_matricula_fkey FOREIGN KEY (matricula)
REFERENCES alumnos (matricula) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
);

CREATE TABLE detallerecibo (


cns integer NOT NULL,
idconcepto integer,
folio integer NOT NULL,
subtotal double precision CONSTRAINT subtotal_invalido CHECK (subtotal > 0 ),
CONSTRAINT detallerecibo_pkey PRIMARY KEY (folio, cns),
CONSTRAINT detallerecibo_folio_fkey FOREIGN KEY (folio)
REFERENCES recibo (folio) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT detallerecibo_idconcepto_fkey FOREIGN KEY (idconcepto)
REFERENCES concepto (idconcepto) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE CASCADE
);

CREATE TABLE calendarioescolar (


fecha varchar NOT NULL,
motivo varchar NOT NULL,
CONSTRAINT calendarioescolar_pkey PRIMARY KEY (fecha)
);

Inserción de datos para algunas tablas recién construidas

INSERT INTO CuentaCheques VALUES (1,700,'HSBC');


INSERT INTO CuentaCheques VALUES (2,9000,'HSBC');
INSERT INTO CuentaCheques VALUES (3,60,'HSBC');
INSERT INTO CuentaCheques VALUES (4,10,'HSBC');
INSERT INTO CuentaCheques VALUES (5,1000,'HSBC');

INSERT INTO Cheque VALUES (6,200,'HSBC');


INSERT INTO Cheque VALUES (1,10,200,'2008-02-01');
INSERT INTO Cheque VALUES (2,10,575.20,'2008-02-01');
INSERT INTO Cheque VALUES (2,20,20,'2008-02-01');
INSERT INTO Cheque VALUES (3,10,600,'2007-02-01');
INSERT INTO Cheque VALUES (4,10,800,'2007-02-01');
INSERT INTO Cheque VALUES (5,10,100,'2007-02-01');
INSERT INTO Cheque VALUES (6,10,300,'2007-02-01');

INSERT INTO Tabulador VALUES (10,100);


INSERT INTO Tabulador VALUES (20,200);
INSERT INTO Tabulador VALUES (30,300);
INSERT INTO Tabulador VALUES (40,400);
INSERT INTO Tabulador VALUES (50,500);
INSERT INTO Tabulador VALUES (60,600);
INSERT INTO Tabulador VALUES (70,700);

INSERT INTO Profesores VALUES (1,40,'Roberto','Maestria',15000);


INSERT INTO Profesores VALUES (2,70,'Carlos','Doctorado',25000);
INSERT INTO Profesores VALUES (3,20,'Luis','Licenciatura',6000);
INSERT INTO Profesores VALUES (4,30,'Yunuan','Maestria',12000);
INSERT INTO Profesores VALUES (5,10,'Julio','Licenciatura',4500);
INSERT INTO Profesores VALUES (6,20,'Samuel','Licenciatura',5500);

INSERT INTO CursosEspeciales VALUES (1,1,1,20070204,20050204);


INSERT INTO CursosEspeciales VALUES (2,2,2,20070204,20050204);
INSERT INTO CursosEspeciales VALUES (3,3,3,20070204,20050204);
INSERT INTO CursosEspeciales VALUES (4,4,4,20070204,20050204);
INSERT INTO CursosEspeciales VALUES (5,5,5,20070204,20050204);

INSERT INTO CursosExtracurricular VALUES (1,'admin',204);


INSERT INTO CursosExtracurricular VALUES (2,'diseño',204);
INSERT INTO CursosExtracurricular VALUES (3,'bdd',204);
INSERT INTO CursosExtracurricular VALUES (4,'java',204);

INSERT INTO Materias VALUES (1,'admin bdd',204);


INSERT INTO Materias VALUES (2,'redes',204);
INSERT INTO Materias VALUES (3,'redes 2',204);
INSERT INTO Materias VALUES (4,'admin bdd',204);

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.

Borrado de las tablas


En caso de necesitar borrar las tablas este es el orden en que deben ser borradas, ya que la aplicación estricta
de la integridad referencial puede generar problemas en el proceso de borrado.

DROP TABLE CalendarioEscolar;


DROP TABLE DetalleRecibo;
DROP TABLE RECIBO;
DROP TABLE Concepto;
DROP TABLE Faltas;
DROP TABLE Bimestre;
DROP TABLE Alumnos;
DROP TABLE CEExtracurricula;
DROP TABLE CEVerano;
DROP TABLE Materias;
DROP TABLE CursosExtracurricular;
DROP TABLE CursosEspeciales;
DROP TABLE Profesores;
DROP TABLE Tabulador;
DROP TABLE Cheque;
DROP TABLE CuentaCheques;

Verificando las tablas con restricciones


Después de construir las tablas, hay que validar que nuestras restricciones funcionen adecuadamente. Puesto
que algunas implican fechas, y se desconoce el momento en que el lector practique con este laboratorio, cuando
sea necesario se le indica que fecha debe capturar.
• Intente insertar el siguiente registro en la tabla cheques. insert into Cheque values(6,10,0,'2014-02-01'); ¿Se
le permitió ejecutar la operación? Explique ¿Qué pasó?
• Elimine la cuenta de cheques no. 6 Delete from CuentaCheques where ncuenta = 6; ¿Funcionó? Ahora
verifique que paso con el cheque 10 que inserto en el paso anterior. Explique
• Inserte el siguiente registro en la tabla Concepto: Insert into concepto values(1); ¿Funcionó? Explique
detalladamente.
• Intente insertar el siguiente registro en la tabla cheques insert into Cheque values(6,10,10, <fecha posterior
al día en que se ejecuta>); Ejemplo si hoy es 19 de Febrero del 2008 use como fecha posterior el 21 de
Febrero. ¿Funcionó? Explique detalladamente.

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.

Como se ha mencionado previamente la herramienta tiene características y lenguajes de programación estándar


que ofrecen sistemas propietarios, por lo que los ejemplos fácilmente pueden ser aplicados en otros sistemas de
bases de datos del mercado, o pueden ser referencia para aplicar los conceptos en proyectos industriales. Por lo
que puedan servir como consulta a profesionales de las Ciencias de la Computación.

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

Partes de la que se compone este laboratorio:


1. Proyecto a desarrollar.
2. Conceptos básicos.
3. Preparación del ambiente de trabajo.
4. Problemática a resolver.
5. Trabajo adicional.
6. Referencias.

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.

Proyecto Universidad ACME


En UACME, se ofrecen dos tipos de cursos en el periodo especial de verano, en el cual se imparten cursos de
verano y cursos extracurriculares. Los primeros son materias que un alumno regular que estudia una carrera
cursa en este periodo, se le permite adelantar hasta dos materias; mientras que los segundos son cursos
especiales de capacitación que se ofrecen a alumnos regulares como estudiantes o profesionistas externos.

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.

UACME tiene dos departamentos que intervienen en la administración de los cursos:


A) Departamento de Administración (DA) y B) Departamento de Control Escolar (DCE). Corresponde al DA,
efectuar el pago a los docentes y los cobros a los alumnos. El DA es dirigido por el C.P. Ávila y es auxiliado por el
Sr. Cancino. Mientras que el DCE, es dirigido por el Lic. Barroso y auxiliado por los Sras. Tirado, Martínez, Aquino
y Ramos y es en este dónde se decide cuales cursos se imparten en el periodo, quién los imparte, y se aceptan
las solicitudes de los alumnos. Un caso especial, es el de los Profesores, ya que el DA es quién les puede modificar
el sueldo quincenal, mientras que el DCE ni siquiera puede visualizar éste. Lo curioso radica en que, es el DCE
quién acepta los docentes y los registra en el sistema, pero es el DA donde se captura el sueldo. Importante es
para la administración de la UACME que esta política se aplique al pie de la letra, y que sea implementado
directamente sobre la DB. A continuación, se describen detalladamente las tablas a las cuales tiene acceso el
personal de la Secretaría Administrativa: CuentaCheques, Cheque, Tabulador, Profesores, Concepto, Recibo, y
DetalleRecibo. En 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:
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.

La sintaxis para la creación de disparadores es la siguiente:

CREATE TRIGGER <trigger name> <BEFORE|AFTER> <INSERT|DELETE|UPDATE>


ON <relation name> FOR EACH <ROW|STATEMENT> EXECUTE PROCEDURE <procedure name>
(<function args>);

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

<RELATION NAME> Determinará la tabla afectada por el evento.

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

Consultas, Procedimientos Almacenados y Disparadores


Para aplicar los disparadores a nuestra base de datos tenemos que hacer un ligero cambio en la base de datos.
Este cambio consiste en que al momento de pagar un alumno su inscripción a un curso extracurricular se le debe
preguntar el idcurso al que se va a inscribir, relacionarlo con el folio y consecutivo del detalle del recibo en el que
ha pagado el mismo y automáticamente se debe de incrementar el campo Total Recabado en la tabla Cursos
Especiales, esto con el fin de que el DCE vea el ingreso económico de este curso. La figura 2 muestra solo la
pequeña modificación que debe hacerse al diagrama. Las entidades y relaciones coloreadas en rojo son las únicas
modificaciones de este diagrama, las demás entidades permanecen intactas y solo se han incluido para
referencia.

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:

-- creando la nueva tabla

CREATE TABLE PagoCursoEspecial(


folio int,
cns int,
idcurso int references CursosEspeciales,
primary key(folio, cns),
foreign key(folio, cns) references DetalleRecibo
);

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

DROP TABLE CursosEspeciales CASCADE;

-- redefiniendo la tabla de CursosEspeciales con los cambios requeridos

CREATE TABLE CursosEspeciales(


idcurso int,
idprofe int,
fini varchar,
ffin varchar,
ncuenta int,
cns int,
TotalRecabado numeric(10,2),
CostoCurso numeric(10,2),
foreign key(idprofe) references Profesores,
foreign key(ncuenta, cns) references Cheque,
primary key (idcurso)
);

Ahora, preparamos el entorno para trabajar con los elementos adecuados, ejecute los siguientes comandos con
el usuario postgres:

-- Insertando datos de alumnos

INSERT INTO alumnos VALUES (100, 'Juan Perez');


-- Insertando datos de concepto

INSERT INTO concepto VALUES (50, 'Pago de Cursos Especiales');

-- Insertando datos del CursosEspeciales


INSERT INTO CursosEspeciales VALUES (75, 5, '2008-01-10', '2008-01-30', 3, 10, 0.0, 4500);

-- Insertando datos del CEExtracurricula

INSERT INTO CEExtracurricula VALUES (75, 4);

-- Insertando datos de Recibo

INSERT INTO Recibo VALUES (200, 100, '2008-02-10', 4500);

-- Insertando datos de Detalle de Recibo

INSERT INTO DetalleRecibo VALUES (1, 50, 200, 4500);

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

-- Eliminando el disparador, por si acaso.

DROP TRIGGER TgIncrementaRecabado ON PagoCursoEspecial CASCADE;


-- Creación del disparador, cuyo nombre es TgIncrementaRecabado. Este se dispara después de hacer una
-- inserción en la tabla PagoCursoEspecial, para cada renglón insertado se debe ejecutar la función
-- IncrementadorTotal().

CREATE TRIGGER TgIncrementaRecabado AFTER INSERT ON PagoCursoEspecial FOR EACH ROW EXECUTE
PROCEDURE IncrementadorTotal();

-- Consulte el total recabado para el curso antes del pago

SELECT * FROM CursosEspeciales;

-- Insertando datos en PagoCursoEspecial, ¡el alumno paga su curso!

INSERT INTO PagoCursoEspecial VALUES (200, 1, 75);

-- Consulte el total recabado para el curso después del pago

SELECT * FROM CursosEspeciales;

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

DROP TRIGGER TgDecrementaRecabado ON PagoCursoEspecial CASCADE;


-- Creación del disparador, cuyo nombre es TgDecrementa Recabado. Este se dispara, después de efectuar el
-- borrado de un registro en la tabla PagoCursoEspecial, para cada renglón insertado se debe ejecutar la función
-- DecrementadorTotal().

CREATE TRIGGER TgDecrementaRecabado AFTER DELETE ON PagoCursoEspecial FOR EACH ROW


EXECUTE PROCEDURE DecrementadorTotal();

-- Consulte el total recabado para el curso antes del pago

SELECT * FROM CursosEspeciales;

-- Borrando datos en PagoCursoEspecial, ¡se cancela el recibo!

DELETE FROM PagoCursoEspecial WHERE folio = 200 and cns = 1;

-- -- Consulte el total recabado para el curso después del pago

SELECT * FROM CursosEspeciales;

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.

Como se ha mencionado previamente la herramienta tiene características y lenguajes de programación estándar


que ofrecen sistemas propietarios, por lo que los ejemplos fácilmente pueden ser aplicados en otros sistemas de
bases de datos del mercado, o pueden ser referencia para aplicar los conceptos en proyectos industriales. Por lo
que puedan servir como consulta a profesionales de las Ciencias de la Computación.

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

Partes de la que se compone este laboratorio:


1. Proyecto a desarrollar
2. Conceptos básicos
3. Preparación del ambiente de trabajo
4. Problemática a resolver
5. Trabajo adicional
6. Referencias

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.

Proyecto Universidad ACME


En UACME, se ofrecen dos tipos de cursos en el periodo especial de verano, en el cual se imparten cursos de
verano y cursos extracurriculares. Los primeros son materias que un alumno regular que estudia una carrera
cursa en este periodo, se le permite adelantar hasta dos materias; mientras que los segundos son cursos
especiales de capacitación que se ofrecen a alumnos regulares como estudiantes o profesionistas externos.

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.

UACME tiene dos departamentos que intervienen en la administración de los cursos:


A) Departamento de Administración (DA) y B) Departamento de Control Escolar (DCE). Corresponde al DA,
efectuar el pago a los docentes y los cobros a los alumnos. El DA es dirigido por el C.P. Ávila y es auxiliado por el
Sr. Cancino. Mientras que el DCE, es dirigido por el Lic. Barroso y auxiliado por los Sras. Tirado, Martínez, Aquino
y Ramos y es en este dónde se decide cuales cursos se imparten en el periodo, quién los imparte, y se aceptan
las solicitudes de los alumnos. Un caso especial, es el de los Profesores, ya que el DA es quién les puede modificar
el sueldo quincenal, mientras que el DCE ni siquiera puede visualizar éste. Lo curioso radica en que, es el DCE
quién acepta los docentes y los registra en el sistema, pero es el DA donde se captura el sueldo. Importante es
para la administración de la UACME que esta política se aplique al pie de la letra, y que sea implementado
directamente sobre la DB. A continuación, se describe detalladamente las tablas a las que se le permite el acceso
al personal de la Secretaría Administrativa:
CuentaCheques, Cheque, Tabulador, Profesores, Concepto, Recibo, y DetalleRecibo.

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

Protocolo de candado en dos fases (2PL):


La importancia de los candados de dos fases es que se ha demostrado de manera teórica que todos los
planificadores generados por algoritmos de control de concurrencia que obedecen a los candados de dos fases
son serializables.

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.

Comandos del SQL que se usan en este laboratorio.


BEGIN —Comienza una transacción en modo encadenado

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 [, ...] ) ] ]

expression [ AS name ] [, ...]

[INTO [TEMPORARY | TEMP ] [ TABLE ] new_table ]

[FROM table [alias ] [, ...] ]

[WHERE condition ]

[GROUP BY column [, ...] ]

HAVING condition [, ...] ]

[{ UNION [ ALL ] | INTERSECT | EXCEPT } select ]

[ORDER BY column [ ASC | DESC | USING operator ] [, ...] ]

[FOR UPDATE [ OF class_name [, ...] ] ]

LIMIT { count | ALL } [ { OFFSET | , } start ]

La cláusula FOR UPDATE permite a SELECT realizar un bloqueo exclusivo de los registros seleccionados.

COMMIT — Compromete la transacción actual

Sintaxis

COMMIT [WORK | TRANSACTION ]

Entrada

WORK
TRANSACTION

Salida

COMMIT - Mensaje devuelto si la transacción se realiza con éxito.

NOTICE: COMMIT: "no transaction in progress" - Si no hay transacciones en progreso.

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

Para hacer todos los cambios permanentes:

COMMIT WORK;

ROLLBACK —Interrumpe la transacción en curso

Sintaxis

ROLLBACK [WORK | TRANSACTION ]

Salida

ABORT - Mensaje devuelto si la operación es exitosa.

NOTICE: ROLLBACK: "no transaction in progress" - Si no hay transacciones en progreso actualmente.

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;

Inicialización de parámetros usando el archivo de configuración.

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.

Autenticación de Clientes de PostgreSQL.


La autenticación de los clientes se controla por medio de un archivo de configuración, al cual se le denomina
pg_hba.conf y se almacena en el directorio donde se instala la base de datos (HBA quiere decir Host-based
Authentication). El archivo pg_hba.conf se instala por omisión cuando el directorio de datos es inicializado por
initdb.

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.

Un registro de este archivo puede tener uno de estos siete formatos:

3. Preparación del ambiente de trabajo


Configuración de la red
Instale la red de área local usando el mecanismo de su elección. Asigne a cada equipo una dirección IP estática.

Configuración de PostgreSQL para aceptar conexiones remotas


En cualquier sistema operativo que esté usando busque los archivos Postgresql.conf y Pg_hba.conf y efectúe en
ellos los siguientes cambios.

Postgresql.conf

Busque el renglón con contiene el siguiente comando:

listen_address = 'localhost'

Y modifique con la siguiente configuración

listen_address = '*'
Pg_hba.conf

Busque el renglón donde se encuentra la configuración de IPv4:

# IPv4 local connections:

Elimine el renglón de abajo y ponga la siguiente configuración:

# IPv4 local connections:


host all all 127.0.0.1/32 md5

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.

Nota: Para usuarios de sistemas operativos Windows y Linux

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.

Preparando los datos y procedimientos almacenados para el ejercicio


Debido a que las operaciones de alta de Cursos Especiales y la Expedición de Cheques son dos actividades
separadas y que cuando se efectúa la primera seguramente no se ha efectuado la segunda, es necesario volver
a crear la tabla de Cursos Especiales, eliminando la referencia a Cheques. Esta integridad deberá efectuarse
manualmente. También se crea el procedimiento almacenado que va a controlar la expedición de cheques.
Usando la cuenta del usuario postgres y desde la aplicación psql del PostgreSQL ejecute los siguientes comandos:

--Conectando a la BD uacme

\c uacme

-- Eliminando la tabla CursosEspeciales

DROP TABLE CursosEspeciales CASCADE;

-- Creando la tabla Cursos Especiales

CREATE TABLE CursosEspeciales (


idcurso int,
idprofe int,
fini varchar,
ffin varchar,
ncuenta int,
cns int,
foreign key(idprofe) references Profesores,
primary key (idcurso)
);

-- Creando los cursos que van a impartir los docentes Julio y Samuel

INSERT INTO CursosEspeciales VALUES (10,5,20150204,20150204, 0, 0);


INSERT INTO CursosEspeciales VALUES (20,6,20150204,20150204, 0, 0);

-- Insertando datos en la especialización de Cursos Especiales Extracurriculares

INSERT INTO CEExtracurricula VALUES (10, 3);


INSERT INTO CEExtracurricula VALUES (20, 4);

-- Eliminando la funcion, por si acaso lo necesitan

DROP FUNCTION AltaDeCheque (int, int, numeric, int);

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

SELECT * FROM CuentaCheques;

-- Consulta a los Cursos Especiales

SELECT * FROM CursosEspeciales;

--Probando que la función funcione adecuadamente


-- El curso 10 (diseño) lo imparte el profesor Julio y el pago es de 3000 pesos
-- El curso 20 (java) lo imparte el profesor Samuel y el pago es de 1000 pesos

SELECT AltaDeCheque (2, 21, 3000, 10);


SELECT AltaDeCheque (2, 22, 1000, 20);

-- Consultando el saldo de la cuenta de cheques, verifique que todo está correcto


-- El nuevo saldo de la cuenta 2 debe ser 5000 pesos. ¿Funciona adecuadamente?
SELECT * FROM CuentaCheques;
-- Regresando los datos a los valores originales Y El curso 10 y 20 aún no están pagados

UPDATE CursosEspeciales SET ncuenta=0, cns = 0 WHERE idcurso = 10;


UPDATE CursosEspeciales SET ncuenta=0, cns = 0 WHERE idcurso = 20;

-- Eliminando todos los cheques de la Cuenta de Cheques 2

DELETE FROM Cheques WHERE ncuenta = 2;

-- Devolviendo el saldo a 9000 pesos de la Cuenta de Cheques 2

UPDATE CuentaCheques SET saldo = 9000 WHERE ncuenta = 2;

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.

Como se ha mencionado previamente la herramienta tiene características y lenguajes de programación estándar


que ofrecen sistemas propietarios, por lo que los ejemplos fácilmente pueden ser aplicados en otros sistemas de
bases de datos del mercado, o pueden ser referencia para aplicar los conceptos en proyectos industriales. Por lo
que puedan servir como consulta a profesionales de las Ciencias de la Computación.

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.

Partes de la que se compone este laboratorio:


1. Proyecto a desarrollar.
2. Conceptos básicos.
3. Preparación del ambiente de trabajo.
4. Problemática a resolver.
5. Trabajo adicional.
6. Referencias.

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.

Proyecto Universidad ACME


En UACME, se ofrecen dos tipos de cursos en el periodo especial de verano, en el cual se imparten cursos de
verano y cursos extracurriculares. Los primeros son materias que un alumno regular que estudia una carrera
cursa en este periodo, se le permite adelantar hasta dos materias; mientras que los segundos son cursos
especiales de capacitación que se ofrecen a alumnos regulares como estudiantes o profesionistas externos.

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.

UACME tiene dos departamentos que intervienen en la administración de los cursos:


A) Departamento de Administración (DA) y B) Departamento de Control Escolar (DCE). Corresponde al DA,
efectuar el pago a los docentes y los cobros a los alumnos. El DA es dirigido por el C.P. ávila y es auxiliado por el
Sr. Cancino. Mientras que el DCE, es dirigido por el Lic. Barroso y auxiliado por los Sres. Tirado, Martínez, Aquino
y Ramos y es en este dónde se decide cuales cursos se imparten en el periodo, quién los imparte, y se aceptan
las solicitudes de los alumnos. Un caso especial, es el de los Profesores, ya que el DA es quién les puede modificar
el sueldo quincenal, mientras que el DCE ni siquiera puede visualizar éste. Lo curioso radica en que, es el DCE
quién acepta los docentes y los registra en el sistema, pero es el DA donde se captura el sueldo. Importante es
para la administración de la UACME que esta política se aplique al pie de la letra, y que sea implementado
directamente sobre la DB. A continuación, se describe detalladamente las tablas a las cuales tiene acceso el
personal de cada Tablas a las que se le permite el acceso al personal de la Secretaría Administrativa:
CuentaCheques, Cheque, Tabulador, Profesores, Concepto, Recibo, y DetalleRecibo.

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.
COPY —Copia datos entre archivos y tablas

Sintaxis

COPY [ BINARY ] table [ WITH OIDS ]


FROM { ’filename’ | stdin }
[ [USING] DELIMITERS ’delimiter’ ]
[ WITH NULL AS ’null string’ ]
COPY [ BINARY ] table [ WITH OIDS ]
TO { ’filename’ | stdout }
[ [USING] DELIMITERS ’delimiter’ ]
[ WITH NULL AS ’null string’ ]

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

COPY - La copia se completó satisfactoriamente.


ERROR: reason - La copia falló por la razón indicada en el mensaje de error.

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.

Sugerencia: No confunda COPY con la instrucción \copy de psql.

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.

VACUUM puede usarse para limpiar tras una copia fallida.

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 formato para cada instancia es <attr1><separator><attr2><separator>...<separator><attrn><newline>

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:

COPY country TO stdout USING DELIMITERS’|’;

Para copiar datos de un archivo Unix a la tabla "country":

COPY country FROM’/usr1/proj/bray/sql/country_data’;

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

No existe la sentencia COPY en SQL 92.

pg_dump — Extrae una base de datos Postgres a un archivo de script

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 ]

Entrada. pg_dump acepta los siguientes argumentos de la línea de comando:


Argumento Descripción
Especifica el nombre de la base de datos que se va a
base_de_datos extraer. base_de_datos tiene como estándar el valor de la variable de entorno
USER.

-a Vuelca sólo los datos, no el esquema (las definiciones).

-c Limpia el esquema antes de crearlo.

-d Vuelca los datos como propios insertos de cadenas.

-D Vuelca la data como insertos con nombres de atributos.

Suprime las dobles comillas de los identificadores, a menos que sean


absolutamente necesarias. Esto puede causar problemas al cargar la misma
-n
si esta data volcada contiene palabras reservadas usadas por los
identificadores. Esta era la conducta estándar en pg_dump pre-v6.4.

-N Incluye comillas dobles en los identificadores.

-o Vuelca los identificadores de objetos (OIDs) para cada tabla.

-s Vuelca solo el esquema (las definiciones), no los datos.

-t tabla Vuelca los datos para la tabla únicamente.

Usa autenticación por medio de clave de acceso. Pide un nombre de usuario


-u
y clave de acceso.

-v Epecifica el modo verbose (parlanchín).

Evita el volcado de ACLs (comandos grant/revoke) y la información de


-x
propiedad de la tabla.

Especifica el nombre del huésped de la máquina en la cual se está ejecutando


-h huésped el postmaster. El estándar es usar un socket de dominio local Unix en vez de
una conexión IP.

Especifica el puerto de Internet TCP/IP o extensión de archivo socket de


dominio local Unix en el cual postmaster está esperando que se efectúen
-p puerto
conexiones. En número estándar de puerto es 5432, o el valor de la variable
de ambiente PGPORT (si está establecida).

Usa autenticación con clave de acceso. Pide nombre_de_usuario y


-u
clave_de_acceso.

Salida

pg_dump creará un archivo o escribirá a stdout.


La conexión con la base de datos ’template1’ falló. ConnectDB() falló: ¿Está el postmaster ejecutándose y
aceptando conexiones en el ’Socket de UNIX’ en el puerto ’puerto’? pg_dump no pudo conectarse al proceso
postmaster en el huésped y puerto especificados. Si ve usted este mensaje, verifique que postmaster se esté
ejecutando en el huésped indicado, y que usted especificó el puerto correcto. Si su site usa algún sistema de
autenticación, verifique que usted tiene las credenciales de autenticación requeridas.

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:

% pg_dump > db.out

Para volver a cargar esta base de datos:

% psql -e base_de_datos < db.out

pg_dumpall —Extrae todas las bases de datos Postgres en un archivo de script.


Sintáxis

pg_dumpall [connection-option...] [option...]

Entradas. pg_dumpall acepta los siguientes argumentos de la línea de órdenes:

Argumento Descripción
-a Dump only the data, not the schema (data definitions).

Incluye comandos para limpiar (drop) bases de datos antes de


-c recrearlas. Los comandos DROP para roles y espacios de tablas son
agregados también.

Enviar la salida a un archivo especificado. Si este se omite, la salida


-f filename
estándar es usada.

Vaciar solo objetos globales (roles y espacios de tablas), no las bases


-g
de datos.

-i Una opción obsoleta que ahora es ignorada.

Vacía los identificadores de objetos como parte de los datos de cada


tabla. Use esta opción si su aplicación referencia las columnas OID de
-o
alguna manera (por ejemplo, en una restricción de llave foránea). De
otra manera, esta opción no debe ser usada.

No emite comandos para establecer la propiedad de los objetos para


que coincidan con la base de datos original. Por omisión, pg_dumpall
ejecuta las instrucciones ALTER OWNER o SET SESSION
AUTHORIZATION para establecer la propiedad de los elementos de
-O esquema creados. Estas instrucciones fallarán cuando se ejecute el
script, a menos que sea iniciado por un superusuario (o el mismo
usuario que posee todos los objetos del script). Para hacer un script que
pueda ser restaurado por cualquier usuario, pero que le dará a ese
usuario la propiedad de todos los objetos, especifique -O.

-r Vacía solo roles, no las bases de datos o los espacios de tablas.

-s Vacía solo las definiciones de objetos (esquemas), no los datos.

Especifica el nombre del superusuario a usar cuando se deshabiliten


los disparadores. Esto es relevante solo si –disable-triggers es usado.
-S
(Normalmente, es mejor dejar esto fuera, y en su lugar iniciar el script
resultante como superusuario.)

-t Vacía solo espacios de tablas, no bases de datos ni roles.

Especifica el modo verbose. Esto causará que pg_dumpall muestre las


-v
horas de inicio / parada en el archivo de vaciado, y los mensajes de
progreso a error estándar. También habilitará la salida detallada en
pg_dump.

-V Imprime la versión de pg_dumpall y sale.

-x Evita el vaciado de los privilegios de acceso (comandos grant/revoke).

Esta opción es para uso de utilidades de actualización in situ. Su uso


para otros fines no es recomendable ni está soportado. El
--binary-upgrade
comportamiento de la opción puede cambiar en versiones futuras sin
previo aviso.

Vaciar datos como comandos INSERT con nombres de columna


--column-inserts explícitos (INSERT INTO tabla (columna, ...) VALUES …). Esto hará
--attribute-inserts que la restauración sea muy lenta; Es principalmente útil para hacer
vaciados que se pueden cargar en bases de datos no PostgreSQL.

Esta opción desactiva el uso de expresiones para los cuerpos de


--disable-dollar-
función y obliga a que se expresen utilizando SQL sintaxis de cadena
quoting
estándar.

Esta opción sólo es relevante cuando se crea un vaciado sólo de datos.


Indica a pg_dumpall que incluya comandos para deshabilitar
temporalmente los disparadores en las tablas de destino cuando los
datos se vuelven a cargar. Use esto si tiene comprobaciones de
integridad referencial u otros disparadores en las tablas que no desea
--disable-triggers
invocar durante la recarga de datos.
Actualmente los comandos emitidos para --disable-triggers deben
hacerse como superusuario. Por lo tanto, también debe especificar un
nombre de superusuario con -S, o preferiblemente tenga cuidado de
iniciar el script resultante como superusuario.

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.

No espera para siempre para adquirir los cierres de tablas compartidas


al inicio del vaciado. En su lugar, falla si no puede bloquear una tabla
dentro del tiempo de espera especificado. El tiempo de espera se puede
--lock-wait- especificar en cualquiera de los formatos aceptados por SET
timeout=timeout statement_timeout. Los valores permitidos varían dependiendo de la
versión del servidor de la que se está vaciando, pero un número entero
de milisegundos es aceptado por todas las versiones desde 7.3. Esta
opción se ignora cuándo se descarga desde un servidor anterior al 7.3.

--no-security-labels No vaciar las etiquetas de seguridad.

No produce comandos para crear espacios de tabla ni selecciona


--no-tablespaces
espacios de tabla para objetos. Con esta opción, todos los objetos se
crearán en el espacio de tabla que sea el predeterminado durante la
restauración.

No vuelca el contenido de tablas no registradas. Esta opción no tiene


--no-logged-table-
ningún efecto sobre si o no las definiciones de tabla (esquema) son
data
volcadas; sólo suprime el volcado de los datos de la tabla.

Fuerza el expresar todos los identificadores. Esta opción se recomienda


cuando se descarga una base de datos de un servidor cuya versión
principal de PostgreSQL es diferente de la de pg_dumpall o cuando la
salida está destinada a ser cargada en un servidor de una versión
principal diferente. De forma predeterminada, pg_dumpall expresa sólo
--quote-all-identifiers
los identificadores que son palabras reservadas en su propia versión
principal. Esto a veces resulta en problemas de compatibilidad al tratar
con servidores de versiones que pueden tener conjuntos ligeramente
diferentes de palabras reservadas. El uso de --quote-all-identifiers evita
estos problemas, al precio de un script de volcado más difícil de leer.

Ejecuta los comandos SET SESSION AUTHORIZATION que son


estándar de SQL en lugar de los comandos ALTER OWNER para
--use-set-session-
determinar la propiedad del objeto. Esto hace que el volcado sea más
authorization
compatible con los estándares, pero dependiendo del historial de los
objetos en el volcado, puede no restaurarse correctamente.

Ejecuta los comandos SET SESSION AUTHORIZATION que son


estándar de SQL en lugar de los comandos ALTER OWNER para
-?
determinar la propiedad del objeto. Esto hace que el volcado sea más
--help
compatible con los estándares, pero dependiendo del historial de los
objetos en el volcado, puede no restaurarse correctamente.

Las siguientes opciones de línea de comandos controlan los parámetros de conexión a la


base de datos.
Argumento Descripción
Especifica los parámetros utilizados para conectarse al servidor, como
una cadena de conexión. Consulte la Sección 31.1.1 para obtener más
información. La opción es llamada --dbname por consistencia con otras
-d connstr aplicaciones cliente, pero debido a que pg_dumpall necesita conectarse
--dbname=connstr a muchas bases de datos, el nombre de la base de datos en la cadena
de conexión será ignorado. Utilice la opción -l para especificar el
nombre de la base de datos utilizada para volcar objetos globales y para
descubrir qué otras bases de datos deben volcarse.

Especifica el nombre del anfitrión del equipo en el que se ejecuta el


servidor de base de datos. Si el valor comienza con una barra, se utiliza
-h host
como directorio para el socket de dominio Unix. El valor predeterminado
--host=host
se toma de la variable de entorno PGHOST, si se establece, de lo
contrario se intenta una conexión de socket de dominio Unix.

-l dbname Especifica el nombre de la base de datos a conectarse para volcar


--database=dbname objetos globales y descubrir qué otras bases de datos se deben volcar.
Si no se especifica, se utilizará la base de datos postgres, y si no existe,
se utilizará template1.

Especifica el puerto TCP o la extensión de archivo de socket de dominio


Unix local en la que el servidor está escuchando conexiones. Por
-p port--port=port
omisión a la variable de entorno PGPORT, si está establecida, o a un
valor predeterminado compilado.

U username
-- El nombre del usuario con el que se conecta.
username=username

Nunca ejecute una solicitud de contraseña. Si el servidor requiere


autenticación de contraseña y una contraseña no está disponible por
-w
otros medios, tal como un archivo .pgpass, el intento de conexión
--no-password
fallará. Esta opción puede ser útil en trabajos por lotes y scripts en los
que ningún usuario está presente para ingresar una contraseña.

Forza a pg_dumpall a pedir una contraseña antes de conectarse a una


base de datos. Esta opción nunca es esencial, ya que pg_dumpall
solicitará automáticamente una contraseña si el servidor requiere
autenticación de contraseña. Sin embargo, pg_dumpall desperdiciará
-W un intento de conexión descubriendo que el servidor desea una
--password contraseña. En algunos casos vale la pena escribir -W para evitar el
intento de conexión adicional. Tenga en cuenta que la solicitud de
contraseña volverá a aparecer para cada base de datos que se va a
vaciar. Por lo general, es mejor configurar un archivo ~ / .pgpass que
confiar en la introducción manual de contraseñas.

Especifica un nombre de rol que se utilizará para crear el volcado. Esta


opción hace que pg_dumpall ejecute un comando SET ROLE rolename
después de conectarse a la base de datos. Es útil cuando el usuario
autenticado (especificado por -U) carece de los privilegios necesarios
--role=rolename
para pg_dumpall, pero puede cambiar a un rol con los derechos
necesarios. Algunas instalaciones tienen una política contra iniciar
sesión directamente como un superusuario y el uso de esta opción
permite que se efectúen descargas sin violar la política.

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.

La conexión a la base de datos ’base_de_datos’ falló. FATAL 1: SetUserId: el usuario ’nombre_de_usuario’ no


estú en ’pg_shadow’ Usted no tiene una entrada vúlida en la relación pg_shadow y no le serú permitido el acceso
a Postgres. Contacte con su administrador Postgres.
dumpSequence(tabla): SELECT falló
No tiene permiso para leer la base de datos. Contacte a su administrador Postgres.

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:

% pg_dumpall > db.out

Sugerencia: Puede usar la mayoría de las opciones de pg_dump con pg_dumpall.


Para volver a cargar esta base de datos:
% psql -e template1 < db.out

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)

Formato del archivo crontab


Archivo crontab de ejemplo:

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

El formato de configuración de cron es muy sencillo.


• El símbolo Numeral "#" es un comentario, todo lo que se encuentre después de ese carúcter no serú
ejecutado por cron.
• El momento de ejecución se especifica de acuerdo con la siguiente tabla:

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:

0,30 * * * 1 /usr/bin/who >> /home/quien.tex


Ejecuta la orden who todos los lunes cada media hora y guarda la salida en el archivo quien.tex

Si queremos que se ejecute cada 15 minutos sería


0,15,30,45 * * * * /usr/bin/who >> /home/quien.text
o
*/15 * * * * /usr/bin/who >> /home/quien.tex

En este ejemplo veremos cómo pasarle más de un comando al cron y de paso como puede programarse una
descarga:

30 21 * * * cd /media/sda7/isos;wget http://mipagina.com/archivo a descarga.miarchivo


Este otro es para programar el apagado del equipo. En este caso todos los sábados a las 21.30
30 21 * * 6 /sbin/shutdown -h now

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

Protocolo de Transferencia de Archivos (FTP).


FTP (siglas en inglés de File Transfer Protocol - Protocolo Transferencias Archivos) en informática, es un protocolo
de red para la transferencia de archivos entre sistemas conectados a una red TCP, basado en la arquitectura
cliente-servidor. Desde un equipo cliente se puede conectar a un servidor para descargar archivos desde él o
para enviarle archivos, independientemente del sistema operativo utilizado en cada equipo. El Servicio FTP es
ofrecido por la capa de Aplicación del modelo de capas de red TCP/IP al usuario, utilizando normalmente el
puerto de red 20 y el 21. Un problema básico de FTP es que está pensado para ofrecer la máxima velocidad en
la conexión, pero no la máxima seguridad, ya que todo el intercambio de información, desde el login y password
del usuario en el servidor hasta la transferencia de cualquier archivo, se realiza en texto plano sin ningún tipo de
cifrado, con lo que un posible atacante puede capturar este tráfico, acceder al servidor, o apropiarse de los
archivos transferidos. Para solucionar este problema son de gran utilidad aplicaciones como scp y sftp, incluidas
en el paquete SSH, que permiten transferir archivos, pero cifrando todo el tráfico.

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.

Guía de comandos FTP


Cuando un cliente intenta comunicarse con el servidor FTP, se puede especificar la dirección de este último en
la línea de comandos; pero si no se hace el cliente entra en modo de intérprete de comandos y espera
instrucciones del usuario, a continuación se ofrece un resumen de los comandos que le pueden ser útiles para el
trabajo de este laboratorio y son parte del Manual de usuario que Linux Ubuntu ofrece
(http://manpages.ubuntu.com/manpages/trusty/man1/tnftp.1.html):

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

Finaliza una conexión FTP y la sesión de trabajo con el programa


bye o quit
cliente

cd directorio Cambia el directorio de trabajo en el servidor

delete archivo Borra un archivo en el servidor

Borra múltiples archivos basado en un patrón que se aplica al


mdelete patrón
nombre.

Muestra el contenido del directorio en el que estamos en el


dir
servidor.

get archivo Obtiene un archivo.

mget archivos Obtiene múltiples archivos.

Activa la impresión de caracteres # a medida que se transfieren


hash
archivos, a modo de barra de progreso.

lcd directorio Cambia el directorio de trabajo local.

ls Muestra el contenido del directorio en el servidor.

Activa/desactiva la confirmación por parte del usuario de la


prompt
ejecución de comandos. Por ejemplo al borrar múltiples archivos.

put archivo Envía un archivo al directorio activo del servidor.

mput archivos Envía múltiples archivos.

pwd Muestra el directorio activo en el servidor.

rename archivo Cambia el nombre a un archivo en el servidor.

rmdir directorio Elimina un directorio en el servidor si ese directorio está vacío.

status Muestra el estado actual de la conexión.

bin o binary Activa el modo de transferencia binario.


COMANDO Y
ACCIÓN QUE REALIZA
ARGUMENTOS
ascii Activa el modo de transferencia en modo texto ASCII.

Permite salir a línea de comandos temporalmente sin cortar la


!
conexión.

exit Regresar al Shell del sistema operativo.

? nombre de comando Muestra la información relativa al comando.

? o help Muestra una lista de los comandos disponibles.

append nombre del


Continúa una descarga que se ha cortado previamente.
archivo

Activa/desactiva la reproducción de un sonido cuando ha


bell
terminado cualquier proceso de transferencia de archivos.

Activa/desactiva la visualización de nombres largos de nuestro


glob
PC.

Con esta orden se pueden ejecutar comandos del servidor de


literal
forma remota. Para saber los disponibles se utiliza: literal help

mkdir Crea el directorio indicado de forma remota.

quote Crea el directorio indicado de forma remota.

send nombre del archivo Hace la misma función que literal.

Para cambiar nuestro nombre de usuario y contraseña sin


user
necesidad de salir de la sesión ftp.

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:

loval@OvalBComm: $ Ftp -i 16.20.1.1


# bin
# lcd /usr/local/Respaldos/
# get BDUACME20080810
# quit

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

Procedimiento manual de respaldo de postgres:


Abrir una ventana de Terminal. Una vez abierta la terminal, cambiarse a usuario "root" ingresando el comando
"su" y haciendo clic en la tecla "Enter" para ejecutarlo. Cuando la solicite, ingresar la contraseña de "root" y hacer
clic en la tecla "Enter". Una vez que se encuentra como "superusuario" o "root", hay que detener el servidor
"postgres". Se ingresa la instrucción: /etc/init.d/postgresql stop

Cuando despliegue el siguiente renglón o el "prompt" (representado por un signo de número


"#"), ya habrá detenido el postgres. Después de detenerlo hay que levantarlo con la instrucción:
/etc/init.d/postgresql start. Cuando despliegue el siguiente renglón o el "prompt" (representado por un signo de
número "#"), ya habrá levantado el postgres.

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:

pg_dump -C -u uacme > BDUACME20080810 + "Enter".

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:

"ls -la nombre_del_archivo"


"ls -la primeras_letras_del_nombre_del_archivo asterisco"
Por ejemplo: "ls -la nombre_del_archivo" + "Enter".

Esto listará el archivo recién creado, desplegando además su tamaño y la hora y fecha de creación.

Procedimiento automático de respaldo de postgres:


La idea del respaldo automático es que se ejecute cuando no hay nadie laborando en las oficinas, para lograrlo
es necesario auxiliarse del sistema CRON. La política de la UACME es ejecutar el respaldo a la 23:00 horas de la
noche, por lo cual es necesario apagar y encender el servidor PostgreSQL antes de la ejecución del respaldo,
digamos unos 10 minutos antes se apaga y 5 minutos después lo encendemos.

Pasos a efectuar para el respaldo automático:


Si por casualidad el primer pensamiento es poner las instrucciones para pg_dump en un script, lamento
desilusionarlo. Tendríamos un pequeño problema, y es que el comando se quedará frenado pidiéndonos la
contraseña del usuario que quiere hacer el backup. Como siempre, tenemos una salida. Nuestro nuevo mejor
amigo en este caso será pgpass. Pgpass es una variable de entorno. Este archivo no se crea por defecto, y varía
levemente el procedimiento si lo usamos en Linux o en Windows. En ambos casos, el archivo contendrá la misma
informació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:

pg_dump -i -h 16.20.1.1 -p 5432 -U miuser -F c -b -v -f "/home/oval/backup/uacme.backup" uacme

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

Pasos a efectuar en el cron para ejecución automática en Linux:


Es probable que necesite información adicional del editor vi, consulte su manual de linux.
• Abra una terminal del sistema con el usuario root.
• Ejecute el comando crontab -i
• Agregue los siguientes renglones (teclee la letra i)
• 40 22 * * * /etc/init.d/postgresql stop
• 45 22 * * * /etc/init.d/postgresql start
• 0 23 * * * pg_dump -C -u uacme > /home/loval/backup/BDUACME20080810
• Grabe los cambios: wq
• Modifique la hora de su sistema (cambie la hora a 22:37)
• Espere la hora indicada y verifique si el archivo está generado, usando el comando “ls” que se le explicó en el
procedimiento de respaldo manual.

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

Pasos a efectuar en la aplicación “Tareas Programadas” para ejecución automática en Windows:


Ejecute la aplicación “tareas programadas” siga al asistente de configuración y agregue los siguientes comandos,
en los mismos horarios que se ejecutan en Linux:

c:\postgresql stop
/etc/init.d/postgresql start
pg_dump -C -u uacme > c:\respaldos\BDUACME20080810

Exportación e Importación de datos.


Un nuevo problema aparece cuando los directivos de las empresas u organismos públicos deciden hacer cambios
de plataforma a los sistemas de información, lo cual es un trabajo a lo cual un profesional de la computación se
puede enfrentar en su vida profesional.

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

Asigne dirección IP estática en el equipo destino (Linux)


-- Use el comando IFCONFIG ó en el menú sistema->configuración->red

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>

Verifique la ruta en el equipo destino (Linux), usando una terminal

cd /home/<usuario>
ls –l

Cambiarse al directorio“c:\area_trabajo\” en el equipo origen (Windows)

cd /area_trabajo

Envíe los archivos de texto generados desde el equipo origen (Windows)

$ ftp -i 16.20.10.20
# bin
# put prof.txt
..
-- PUT se repite por cada archivo que se envía
# quit

Instale el servidor MySQL en el sistema destino (Linux)


-- siga los pasos que le indica Ubuntu (gestor de paquetes)

Ejecute el cliente de MySQL en una terminal.

mysql -u root -p

Construya la base de datos en el sistema destino (Linux – MySQL ).

create database uacme;


use uacme;

Construya las tablas en el sistema destino (Linux – MySQL ).

Create Table Profesores (


idprofe int(4) PRIMARY KEY,
idtab int(4),
nombre varchar(40),
maximo varchar(40),
sueldo int(4)
);

Cargue los datos en el sistema destino (Linux-MySQL)


Para leer estructura del comando LOAD DATA INFILE leer las páginas
http://mirror.hostfuss.com/mysql/doc/refman/5.0/es/load-data.html ó
http://dev.mysql.com/doc/refman/5.0/en/load-data.html
mysql> LOAD DATA INFILE '/home/<usuario>/prof.txt' INTO TABLE profesores
FIELDS TERMINATED BY ',';

-- Ejecute la carga de cada archivo a su tabla correspondiente

Verifique que todos los registros estén cargados correctamente.

Select * from profesores;


-- Verifique que cada una de las tablas ha sido cargada correctamente

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.

Pasos a efectuar para Importar datos:


Genere el archivo de datos de texto para la tabla en sistema origen (Linux-MySQL).

SELECT * INTO OUTFILE '/tmp/profesores.txt'


FIELDS TERMINATED BY ',' ENCLOSED BY '' FROM Profesores;

-- Aplique para cada una de las tablas del sistema.


-- verifique que el directorio tmp existe

Envíe los archivos de texto generados al equipo destino (Windows).


-- Usando ftp (siga las mismas instrucciones que en la exportación), solo que esta
-- vez será enviada la información en sentido contrario.

Construya las tablas en el sistema destino (Windows - PostgreSQL).

-- Use las tablas que tenemos ya construidas, limpie la información


-- de cada tabla usando DELETE FROM ...
-- o elimine la BD ( DROP DATABASE UACME;) y vuelva a construir todas las tablas.

Cargue los datos en el sistema destino (Windows - PostgreSQL).


copy profesores from '/area_trabajo/profesores.txt' with delimiter ',';
-- Ejecute este comando una vez por cada tabla.

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

Potrebbero piacerti anche