PDF de programación - Administración de datos

Administración
de datos

Remo Suppi Boldrito

P07/M2103/02287

© FUOC • P07/M2103/02287

2

Administración de datos

© FUOC • P07/M2103/02287

Índex

Administración de datos

Introducció ...............................................................................................

5

1. PostgreSQL ..........................................................................................
7
7
1.1. ¿Cómo se debe crear una DB? ........................................................
8
1.2. ¿Cómo se puede acceder a una DB? ................................................
1.3. El lenguaje SQL ...............................................................................
8
1.4. Instalación PostgreSQL ................................................................... 10
1.4.1. Postinstalación .................................................................... 11
1.4.2. Usuarios de DB .................................................................... 12
1.5. Mantenimiento ............................................................................... 14
1.6. Pgaccess ........................................................................................... 15

2. Mysql .................................................................................................... 17
2.1. Instalación ...................................................................................... 17
2.2. Postinstalación y verificación ......................................................... 18
2.3. El programa monitor (cliente) mysql ............................................. 19
2.4. Administración ............................................................................... 20
2.5. Interfaces gráficas ........................................................................... 21

3. Source code control system (CVS y Subversion) .......................... 23
3.1. Revision control system (RCS) ........................................................... 24
3.2. Concurrent versions system (CVS) ..................................................... 25
3.2.1. Ejemplo de una sesión ........................................................ 28
3.2.2. Múltiples usuarios ............................................................... 29
3.3. Interfaces gráficas ........................................................................... 29

4. Subversion ........................................................................................... 31

Actividades................................................................................................ 35

Otras fuentes de referencia e información ...................................... 35

© FUOC • P07/M2103/02287

Administración de datos

© FUOC • P07/M2103/02287

5

Administración de datos

Introducció

Un aspecto importante de un sistema operativo es dónde y cómo se guardan
los datos. Cuando la disponibilidad de estos datos debe ser eficiente, es nece-
saria la utilización de bases de datos (DB).

Una base de datos es un conjunto estructurado de datos que pueden ser orga-
nizados de manera simple y eficiente por un manejador de dicha base. Las ba-
ses de datos actuales se denominan relacionales, ya que los datos pueden ser
almacenados en diferentes tablas que facilitan su gestión y administración.
Para ello y con el fin de estandarizar el acceso a las bases de datos se utiliza un
lenguaje denominado SQL (structured query language), que permite una interac-
ción flexible, rápida e independiente de las aplicaciones a las bases de datos.

La forma más utilizada en la actualidad consiste en acceder a una base de datos
desde una aplicación que ejecuta código SQL. Por ejemplo, es muy común ac-
ceder a una DB a través de una página web que contiene código PHP o Perl (los
más comunes). Cuando se solicita una página por parte de un cliente, se eje-
cuta el código PHP o Perl incrustado en la página, se accede a la DB y se genera
la página con su contenido estático y el contenido extraído de la DB que pos-
teriormente se envía al cliente. Dos de los ejemplos más actuales de bases de
datos son los aportados por ProstgreSQL y MySQL, que serán objeto de nuestro
análisis.

Sin embargo, cuando se trabaja en el desarrollo de un software, existen otros
aspectos relacionados con los datos, que son su validez y su ámbito (sobre
todo si existe un conjunto de usuarios que trabajan sobre los mismos datos).
Existen diversos paquetes para el control de versiones (revisiones), pero el ob-
jetivo de todos ellos es facilitar la administración de las distintas versiones de
cada producto desarrollado junto con las posibles especializaciones realizadas
para algún cliente específico.

El control de versiones se realiza para controlar las distintas versiones del có-
digo fuente. Sin embargo, los mismos conceptos son aplicables a otros ámbi-
tos y no sólo para código fuente sino para documentos, imágenes, etcétera.
Aunque un sistema de control de versiones puede realizarse de forma manual,
es muy aconsejable disponer de herramientas que faciliten esta gestión (CVS,
Subversion, SourceSafe, Clear Case, Darcs, Plastic SCM, RCS, etc.).

En este capítulo veremos CVS (control version system) y Subversion para contro-
lar y administrar múltiples revisiones de archivos, automatizando el almace-
namiento, lectura, identificación y mezclado de diferentes revisiones. Estos
programas son útiles cuando un texto es revisado frecuentemente e incluye

© FUOC • P07/M2103/02287

6

Administración de datos

código fuente, ejecutables, bibliotecas, documentación, gráficos, artículos y
otros archivos. [Pos03e, Mys, Ced]

La justificación de CVS y Subversion se puede encontrar en que CVS es uno de
los paquetes tradicionales y más utilizados y Subversion es un software de sis-
tema de control de versiones diseñado específicamente para reemplazar al po-
pular CVS y soluciona varias deficiencias de éste. Al Subversion también se lo
conoce como svn por ser ése el nombre de la herramienta de línea de coman-
dos. Una característica importante de Subversion es que, a diferencia de CVS,
los archivos con versiones no tienen cada uno un número de revisión inde-
pendiente. En cambio, todo el repositorio tiene un único número de versión
que identifica un estado común de todos los archivos del repositorio en cierto
punto del tiempo.

© FUOC • P07/M2103/02287

7

Administración de datos

1. PostgreSQL

En el lenguaje de bases de datos (DB), PostgreSQL utiliza un modelo cliente
servidor [Posa]. Una sesión de PostgreSQL consiste en una serie de programas
que cooperan:

• Un proceso servidor que maneja los archivos de la DB acepta conexiones
de los clientes y realiza las acciones solicitadas por éstos sobre la DB. El pro-
grama servidor es llamado en PostgreSQL postmaster.

• La aplicación del cliente (frontend) es la que solicita las operaciones que hay
que realizar en la DB y que pueden ser de lo más variadas; por ejemplo: he-
rramientas en modo texto, gráficas, servidores de web, etc.

Generalmente, el cliente y el servidor se encuentran en diferentes hosts y se
comunican a través de una conexión TCP/IP. El servidor puede aceptar múlti-
ples peticiones de diferentes clientes, activando para cada nueva conexión un
proceso que lo atenderá en exclusiva de un modo transparente para el usuario.
Hay un conjunto de tareas que pueden ser llevadas a cabo por el usuario o por
el administrador, según convenga, y que pasamos a describir a continuación.

1.1. ¿Cómo se debe crear una DB?

La primera acción para verificar si se puede acceder al servidor de DB es crear
una base de datos. El servidor PostgreSQL puede manejar muchas DB y es re-
comendable utilizar una diferente para cada proyecto. Para crear una base de
datos, se utiliza el comando createdb desde la línea de comandos del sistema
operativo. Este comando generará un mensaje CREATE DATABASE si todo es
correcto. Es importante tener en cuenta que para esta acción debe haber un
usuario habilitado para crear una base de datos. Se verá en el apartado de ins-
talación (8.1.4) que existe un usuario, el que instala la base de datos, que ten-
drá permisos para crear bases de datos y crear nuevos usuarios que a su vez
puedan crear bases de datos. Generalmente (y en Debian) este usuario es postgres
por defecto. Por ello, antes de hacer el createdb, se debe hacer un postgres (si
se es root, no es necesaria ninguna palabra clave, pero si se es otro usuario, ne-
cesitaremos la palabra clave de postgres) y luego se podrá realizar el createdb.
Para crear una DB llamada nteumdb:

createdb nteumdb

Si no encontráis el comando, puede ser que no esté bien configurado el ca-
mino o que la DB esté mal instalada. Se puede intentar con todo el camino

© FUOC • P07/M2103/02287

8

Administración de datos

Nota

Para poder acceder a la DB, el
servidor de base de datos de-
berá estar en funcionamiento.
Cuando se instala Postgresql se
crean los enlaces adecuados
para que el servidor se inicie en
el arranque del ordenador.
Para más detalles, consultad el
apartado de instalación
(8.1.4).

(/usr/local/pgsql/bin/createdb nteumdb), que dependerá de la ins-
talación que se haya hecho, o consultar referencias para la solución de pro-
blemas. Otros mensajes de error serían could not connect to server cuando el
servidor no está arrancado o CREATE DATABASE: permission denied cuando
no se tienen privilegios para crear la DB. Para eliminar la base de datos, se
puede utilizar dropdb nteumdb.

1.2. ¿Cómo se puede acceder a una DB?

Una vez creada la DB, se puede acceder a ella de diversas formas:

• Ejecutando un comando interactivo llamado psql, que permite editar y eje-

cutar comandos SQL.(p. ej. psql nteumdb)

• Ejecutando una interfaz gráfica como PgAccess o alguna suite que tenga so-

porte ODBC para crear y manipular DB.

• Escribiendo una aplicación utilizando algunos de los lenguajes soportados,
por ejemplo, PHP, Perl, Java... (ver PostgreSQL 7.3 Programmer’s Guide).

Por simplicidad ut