Durante esta rápida introducción sólo hablaré de gestores de base de datos. Existen otras organizaciones de datos, pero hablar de ellas se saldría del objetivo del curso.
Hasta el momento, el acceso a los datos se hacía mediante accesos a entidades que se relacionaban entre sí mediante una ligaduras definidas en el esquema de la base de datos, eso tenía una ventaja, rapidez, pero una gran desventaja, sólo podíamos acceder a los datos mediante una ligadura, ejemplo :
país -> provincias -> municipios
pero nunca :
país -> municipios
Siendo "->" la ligadura.
Si queríamos realizar esa segunda relación, debíamos redefinir el esquema y recompilarlo...
En efecto, en una BD jerarquica, la relación entre las diversas entidades es estática y solo modificable mediante modificación del esquema de la base de datos y recompilacion de este ultimo.
La idea básica de los gestores de bases de datos relacionales es justamente ligar los datos en el momento de la petición de estos, pero sin necesitar una ligadura estática, sino una identificación que permita ligar un registro con otro.
Esto que acabo de escribir necesita una Aspirina :-)
Los gestores de base de datos relacionales no precisan unas ligaduras estáticas para poder descender una jerarquia de entidades, sino que usan un código único que les identifica para realizar una relación temporanea que es el resultado de una pregunta al gestor.
Esta identificación no es más que el código. Ej: mi número de telefono no es el :
1234567
sino el :
34 6 1234567
En efecto mi numero de telefono esta identificado por el código país (34), el código de la provincia (6) y el propio número de aparato (1234567).
- En la entidad paises, el código 34 (España) es único.
- En la entidad provincias, el código 34-6 (España/Valencia) es único.
- En la entidad aparatos, el código 34-6-1234567 (España/Valencia/mi telefono) es único.
Vamos a poner las bases del primer ejemplo que ilustrara lo que acabo de decir.
Todos los municipios tienen un código, pertenecen a una provincia y a un país
Todas las provincias tienen un código y pertenecen a un país
Todos los países tienen un código
Para conocer todos los municipios de una provincia, relaciono el municipio con la provincia por el código de país y provincia; para saber todos los municipio de un país, relaciono el municipio con el país por el código de país. Estas relaciones son temporáneas y sólo existen durante la realización de mi pregunta.
Es un poco duro, pero con los primeros ejemplos comprenderemos un poco mejor este concepto de código y de pertenencia.
Al realizar mi pregunta el gestor me entregara todos los datos que se relacionen entre sí. Pero ¿qué datos me va a dar? Pues la conjunción de los datos de países y municipios, para cada municipio me repetirá los datos del país.
Durante la realización de mi pregunta se ha creado un nueva entidad que no tiene nombre y que contiene una réplica de países y municipios. Esa nueva entidad, y me repito, desaparecerá una vez terminada mi lectura.
Antes llamábamos a los conjuntos de datos, ficheros. Estos se componen de registros y estos últimos se componen de campos. Bien, pues en una base de datos relacional, un "fichero" se llama tabla, una tabla se compone de tuplas y una tupla contiene columnas, no es más que un matiz... ;-)
Hay que destacar que ciertos gestores de BD jerárquicos introducían SQL como lenguaje de acceso, pero esto es anecdótico. El lenguaje SQL es casi una exclusividad de los gestores relacionales.
Para ilustrar el curso utilizaremos el gestor relacional PostgreSQL, aunque no cumple con todas las normas SQL, sí que es más que suficiente para nosotros, y para otros menesteres más duros también.
Voy a explicar muy brevemente el proceso de instalación, dado que el objetivo de este artículo es SQL. Primero bajamos los fuentes de
www.postgresql.org, así como los parches. Los extraemos (tar zxvf) en un directorio,
cd postgresql-6.3
cd src
./configure --prefix=/el/path/deseado
make all >& make.log &
tail -f make.log
export PATH=$PATH:/el/path/deseado/pgsql/bin---export MANPATH=$MANPATH:/el/path/deseado/pgsql/man---export PGLIB=/el/path/deseado/pgsql/lib
export PGDATA=/el/path/deseado/pgsql/data
initdb
createdb prueba
psql prueba
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: postgres
prueba=>
Este es el prompt de postgres, ahora podemos ejecutar comandos.
prueba=>create table prueba (campo1 varchar(10));
CREATE
prueba=>insert into prueba values ('hello');
INSERT numerito 1
prueba=>commit work;
NOTICE:EndTransactionBlock and not inprogress/abort state
END
prueba=>select * from prueba;
campo1
hello
(1 row)
prueba=>drop table prueba;
DROP
prueba=>Ctrl-d
Ya estamos fuera del monitor SQL.
Si no habéis conseguido compilar e instalar Postgres95 correctamente, referiros al fichero INSTALL que está en el directorio de entrada de la distribución.
Como comentario, vamos a ver como esta construido un servidor de bases de datos relacional :
- La capa de acceso a los datos
- La capa gestora SQL
- La capa traductora SQL
- La capa de comunicaciones
Como cliente nos conectaremos a la capa 4, le enviaremos los comandos SQL a esta capa, que los pasará a la capa 3. Ésta hace la traducción del comando y, si no hay errores, envía el comando a la capa 2. La capa 2 hace toda la gestión del comando con la colaboración de la capa 1: recoge los datos y errores para enviarlos al cliente, vía la capa 4; y es capaz de mantener un diálogo con el programa cliente para coordinarse. La capa 1 es la encargada de gestionar correctamente los datos y controlar los bloqueos y transacciones.
