La historia de PostgreSQL se inicia en 1986 con un proyecto del profesor Michael Stonebraker y un equipo de desarrolladores de la Universidad Berkeley (California), cuyo nombre original era POSTGRES. En su diseño se incluyeron algunos conceptos avanzados en bases de datos y soporte parcial a la orientación a objetos.

POSTGRES fue comercializado por Illustra, una empresa que posteriormente formó parte de Informix (que comercializaba el conocido SGBD del mismo nombre, recientemente absorbida por IBM y su DB/2). Llegó un momento en que mantener el proyecto absorbía demasiado tiempo a los investigadores y académicos, por lo que en 1993 se liberó la versión 4.5 y oficialmente se dio por terminado el proyecto.

En 1994, Andrew Yu y Jolly Chen incluyeron SQL en Postgres para posteriormente liberar su código en la web con el nombre de Postgres95. El proyecto incluía múltiples cambios al código original que mejoraban su rendimiento y legibilidad.

En 1996 el nombre cambió a PostgreSQL retomando la secuencia original de versiones, por lo que se liberó la versión 6.0. En el año 2004 la última versión estable oficial es la 7.4.6, mientras que la versión 8.0 está ya en fase final de estabilización.

Los desarrolladores de proyectos     basados en software libre tienen       muy en cuenta PostgreSQL cuando  los requerimientos de un proyecto    exigen prestaciones de alto nivel.

PostgreSQL destaca por su amplísima lista de prestaciones que lo hacen capaz de competir con cualquier SGBD comercial:

•    Está desarrollado en C, con herramientas como Yacc y Lex.

•    La API de acceso al SGBD se encuentra disponible en C, C++, Java, Perl, PHP, Python y TCL, entre otros.

•    Cuenta con un rico conjunto de tipos de datos, permitiendo además su extensión mediante tipos y operadores definidos y programados por el usuario.

•    Su administración se basa en usuarios y privilegios.

•    Sus opciones de conectividad abarcan TCP/IP, sockets Unix y sockets NT, además de soportar completamente ODBC.

•    Los mensajes de error pueden estar en español y hacer ordenaciones correctas con palabras acentuadas o con la letra ‘ñ’.

•    Es altamente confiable en cuanto a estabilidad se refiere.

•    Puede extenderse con librerías externas para soportar encriptación,  búsquedas por similitud fonética (soundex), etc.

•    Control de concurrencia multiversión, lo que  mejora sensiblemente las operaciones de bloqueo y transacciones en sistemas multiusuario.

•    Soporte  para  vistas,  claves  foráneas,  integridad  referencial,  disparadores, procedimientos almacenados, subconsultas y casi todos los tipos y operadores soportados en SQL92 y SQL99.

•    Implementación de algunas extensiones de orientación a objetos. En PostgreSQL es posible definir un nuevo tipo de tabla a partir de otra previamente definida.

Las limitaciones de este tipo de gestores de bases de datos suelen identificarse muy fácilmente analizando las prestaciones que tienen previstas para las próximas versiones. Encontramos lo siguiente:

•    Puntos de recuperación dentro de transacciones. Actualmente, las transacciones abortan completamente si se encuentra un fallo durante su ejecución. La definición de puntos de recuperación permitirá                     recuperar  mejor transacciones complejas.

•    No soporta tablespaces para definir dónde almacenar la base de datos, el esquema, los índices, etc.

•    El soporte a orientación a objetos es una simple extensión que ofrece prestaciones como la herencia, no un soporte completo.

En 1967, el lenguaje de programación Simula aplicaba algunas ideas para modelar aspectos de la realidad de forma mucho más directa que los métodos tradicionales. Desde entonces, la orientación a objetos (OO) ha adquirido cada vez mayor popularidad al demostrar sus ventajas, entre las cuales:

•    Permite un modelado más “natural” de la realidad.

•    Facilita la reutilización de componentes de software.

•    Ofrece mecanismos de abstracción para mantener controlable la construcción de sistemas complejos.

En el mercado aparecen constantemente herramientas y lenguajes de programación autodenominados orientados a objetos y los ya existentes evolucionan  rápidamente  incluyendo  nuevas  características  de  OO.  De  la  misma manera, se han desarrollado múltiples métodos y metodologías bajo este enfoque, cada una con aportaciones propias que llegan, en ocasiones, a resultar contradictorias entre sí. Se ha logrado la creación de un lenguaje unificado para el modelado, llamado precisamente UML (unified modeling language). La intención de UML es ser independiente de cualquier metodología y es precisamente esta independencia la que lo hace importante para la comunicación entre desarrolladores, ya que las metodologías son muchas y están en constante evolución.

Lamentablemente, a pesar de los muchos esfuerzos y de importantes avances, las ciencias de la computación no han creado aún una definición de modelo de objetos como tal. En un panorama como éste, es indispensable, al menos, la existencia de un modelo informal de objetos que oriente la evolución de la tecnología y que tenga la aprobación de los expertos en la materia. Un modelo así permitiría su estudio consistente por parte de los profesionales de las tecnologías de la información, facilitaría la creación de mejores lenguajes y herramientas  y,  lo  que  es  más  importante,  definiría  los  estándares  para  una metodología de desarrollo consistente y aplicable.

Sin embargo, este modelo no existe, lo que provoca inconsistencias incluso en el tratamiento de los principios y conceptos básicos de la OO. Por eso, es frecuente encontrar errores graves en el desarrollo de sistemas OO y, lo que es aún peor, se implementan soluciones de dudosa validez en herramientas de desarrollo que se dicen orientadas a objetos.

Aun sin haber alcanzado la madurez, la orientación a objetos es el paradigma que mejor permite solucionar los muchos y variados problemas que existen en el desarrollo de software. En los próximos apartados analizaremos los conceptos básicos de este modelo para identificar algunos de los problemas que aún debe resolver, lo que facilitará la comprensión y evaluación de métodos y herramientas OO.

Los objetos son abstracciones que realizamos del mundo que nos rodea y que identificamos por sus propiedades. Para la OO todo es un objeto.

Cada objeto tiene una existencia un tanto independiente de los demás objetos; es decir, tiene identidad propia. Aunque dos objetos tengan exactamente los mismos valores, no por eso serán el mismo objeto, seguirán siendo entidades diferentes. En los modelos OO, la identidad se representa con el identificador de objeto, IDO (OID en inglés, de object identifier). Teóricamente, el IDO de un objeto es único e irrepetible en el tiempo y el espacio.
 

Función del IDO

El IDO permite que dos objetos idénticos puedan diferenciarse, no es importante que el usuario conozca los IDO, lo importante es que los diferencie el sistema.

Los IDO son el mecanismo que permite hacer referencia a un objeto desde otro. De esta manera las referencias tejen las relaciones entre objetos.

Todos los objetos que comparten las mismas propiedades se dice que pertenecen a la misma clase. En los modelos OO, las clases le roban el papel central a los objetos, ya que es a través de ellas como se definen las propiedades de éstos y además se utilizan como plantillas para crear objetos.

 

 

Al crear un objeto utilizando la definición dada por una clase, obtenemos un valor para él, es lo que se llama una instancia del objeto. Durante la ejecución de los programas se trabaja con instancias. Como concepto, la instancia es equivalente a una tupla (fila) concreta en una tabla de una base de datos.

Las propiedades de los objetos pueden ser de dos tipos, dinámicas y estáticas. Un  atributo  representa  una  propiedad  estática  de  un  objeto  (color,  coste, edad, etc.). Una operación representa una propiedad dinámica; es decir, una transformación sobre un atributo o una acción que puede realizar.

El conjunto de valores de los atributos en un momento dado se conoce como estado del objeto. Los operadores actúan sobre el objeto cambiando su estado. La secuencia de estados por la que pasa un objeto al ejecutar operaciones definen su comportamiento.

La posibilidad de definir comportamientos complejos es lo que hace diferente la OO.

 

 

La estructura interna de los objetos debe estar oculta al usuario de un objeto, no necesita conocerla para interactuar con él. Los objetos se conciben como una cápsula cuyo interior está oculto y no puede ser alterado directamente desde el exterior.

Los tipos de datos abstractos

Los tipos de datos abstractos (TDA) obedecen al mismo principio de independencia de la implementación. La diferencia respecto a los objetos es que éstos incluyen los datos y las peraciones en la misma cápsula.

A la estructura interna de un objeto se la denomina implementación y a la parte visible, la que se presenta al exterior, interfaz. La interfaz se define por sus atributos y operaciones.

La implementación de una operación se conoce como método. La implementación de un atributo se realiza generalmente con variables de instancia.

El encapsulamiento comporta las siguientes ventajas:

•    La modificación interna (de la implementación) de un objeto para corregirlo o mejorarlo no afecta a sus usuarios.

•    La dificultad inherente a la modificación de la implementación de un objeto sea independiente del tamaño total del sistema. Esto permite que los sistemas evolucionen con mayor facilidad.

•    La simplificación en el uso del objeto al ocultar los detalles de su funcionamiento y presentarlo en términos de sus propiedades. Al elevar el nivel de abstracción se disminuye el nivel de complejidad de un            sistema. Es posible modelar sistemas de mayor tamaño con menor esfuerzo.

•    Constituye un mecanismo de integridad. La dispersión de un fallo a través de todo el sistema es menor, puesto que al presentar una división entre interfaz e implementación, los fallos internos de un objeto              encuentran una barrera en el encapsulamiento antes de propagarse al resto del sistema.

•    Permite la sustitución de objetos con la misma interfaz y diferente implementación. Esto permite modelar sistemas de mayor tamaño con menor esfuerzo.

 

Paradójicamente, el encapsulamiento, a pesar de ser uno de los conceptos básicos en la OO, no siempre se interpreta y se aplica correctamente. Especialmente en lo referente a encapsulamiento de atributos.

 

 

Diferenciemos operación y método a través de un ejemplo.

Consideremos tres objetos: polígono, círculo y punto.

A los tres se les solicita la operación de imprimir. En esta situación, tenemos que:

•  La operación solicitada es la misma, porque el significado del resultado es el mismo.

•  Cada objeto ejecuta la operación de forma diferente; es decir, con un método diferente.

•  Cada objeto, internamente, puede tener más de un método y selecciona el más apropiado según las circunstancias.

 

Veamos ahora la diferencia entre atributos y variables de instancia, que puede parecer más sutil.

Un atributo es la vista externa de una propiedad estática de un objeto. La representación interna puede variar, los atributos pueden implementarse también con métodos. Tomemos como ejemplo el objeto punto con los atributos que se muestran a continuación:
 

 

Punto

+ x: float + y: float + radio: float + ángulo: float

Los atributos de un punto pueden definirse en coordenadas angulares o rectangulares; en este caso, es posible conocer ambas representaciones. En la implementación de estos atributos, dos pueden ser variables de instancia y los otros dos se implementan como métodos, que se calculan a través de los primeros.

Desde el exterior no debe ser posible conocer la representación elegida internamente. Puede cambiarse la implementación de los atributos sin alterar la interfaz. En algunos casos puede incluso permitirse al sistema la elección de la representación interna de un atributo del mismo modo que una operación elige entre varios métodos disponibles.

La herencia se define como el mecanismo mediante el cual se utiliza la definición de una clase llamada “padre”, para definir una nueva clase llamada “hija” que puede heredar sus atributos y operaciones.
A las clases “hijo” también se les conoce como subclases, y a las clases “padre” como superclases. La relación de herencia entre clases genera lo que se llama jerarquía de clases.

La herencia de tipo

En la herencia de tipo lo que hereda la subclase son los atributos de la superclase, pero no necesariamente su implementación, puesto que puede volver a implementarlos.

Hablamos de herencia de tipo cuando la subclase hereda la interfaz de una superclase; es decir, los atributos y las operaciones. Hablamos de herencia estructural cuando la subclase hereda la implementación de la superclase; es decir, las variables de instancia y los métodos.

La herencia de tipo define relaciones es-un entre clases, donde la clase “hijo” tiene todas las propiedades del “padre”, pero el “padre” no tiene todas las propiedades del “hijo”.

Consideremos una referencia mascota que es de tipo animal, en algún lenguaje de programación.

Ejemplo

Un gato es-un animal. Todas las propiedades de la clase “animal” las tiene la clase “ga to”. Pero un animal no-es necesariamente un gato. Todas las propiedades de gato no las tienen todos los animales.

mimascota: Animal;

Puede  hacer  referencia  a  objetos  de  tipo  animal,  o  tipos derivados  de  éste, como perro, gato o canario, por ejemplo.

mimascota = new Canario;

Se construye un nuevo canario y se hace referencia a él como mascota.

La propiedad de sustituir objetos que descienden del mismo padre se conoce como polimorfismo, y es un mecanismo muy importante de reutilización en la OO.

La referencia al tipo animal es una referencia polimorfa, ya que puede referirse a tipos derivados de animal. A través de una referencia polimorfa se pueden solicitar operaciones sin conocer el tipo exacto.

mimascota.comer();

La operación comer tiene el mismo significado para todos los animales. Como ya hemos comentado, cada uno utilizará un método distinto para ejecutar la operación.

Para conocer el tipo exacto del objeto en cuestión, se utiliza el operador de información de tipo. De este modo puede accederse a las propiedades específicas de un tipo de objeto que no están en los demás tipos.

En este ejemplo llamamos al operador información de tipo, instancia-de.
if (mimascota instancia-de Canario)
   mimascota.cantar();
Si la mascota es una instancia del tipo Canario entonces se le solicitará cantar, que es una propiedad que no tienen todas las mascotas.
 

Una clase puede heredar las propiedades de dos superclases mediante lo que se conoce como herencia múltiple.

En una herencia múltiple, puede ocurrir que en ambas superclases existan propiedades con los mismos nombres, situación  que  se  denomina colisión  de nombres. A continuación, se relacionan los posibles casos de colisión de nombres en la herencia de tipo:

• Los nombres son iguales porque se refieren a la misma propiedad (ya hemos visto ejemplos de ello: la operación imprimir y el atributo tamaño). En este caso no hay conflicto porque el significado está claro: es la misma propiedad, sólo hay que definir una implementación adecuada.
• Los nombres son iguales pero tienen significados diferentes. Esta situación es posible porque el modelado es una tarea subjetiva y se soluciona cambiando los nombres de las propiedades heredadas que tengan conflicto.

La herencia múltiple no comporta problemas para la herencia de tipo, puesto que no pretende la reutilización de código, sino el control conceptual de la complejidad de los sistemas mediante esquemas de clasificación.

Por lo que respecta a la herencia estructural, que, recordemos, consiste en que la subclase hereda las variables de instancia y los métodos de la superclase –es decir, la implementación–, la cosa cambia.

Para entender mejor la herencia estructural, diremos informalmente que representa una relación funciona-como. Por ejemplo, se puede utilizar para definir un avión tomando como superclase ave, de esta manera la capacidad de volar del ave queda implementada en el avión. Un avión no es-un ave, pero podemos decir que funciona-como ave.

Al aplicar la herencia de esta manera se dificulta la utilización del polimorfismo: aunque un objeto funcione internamente como otro, no se garantiza que externamente pueda tomar su lugar porque funciona-como.

El objetivo de la herencia estructural es la reutilización de código, aunque en algunos casos, como el ejemplo anterior, pueda hacer conceptualmente más complejos los sistemas.

Ejemplo

Si un canario es-un animal, entonces un canario funciona-como animal, más otras propiedades especificas de canario

Siempre que es posible aplicar la herencia de tipo, puede aplicarse la herencia estructural, por lo que la mayoría de los lenguajes de programación no hacen distinción entre los dos tipos de herencia.

 

Los lenguajes de programación comúnmente no hacen distinción entre la herencia estructural y la herencia de tipo.

La herencia estructural múltiple permite heredar variables y métodos de va rias superclases, pero surgen problemas que no son fáciles de resolver, especialmente con las variables de instancia.

Para resolver el conflicto de una variable de instancia duplicada, se puede optar por las siguientes soluciones:

• Cambiar los nombres, lo que puede provocar conflictos en los métodos que las utilizan.
• Eliminar una de las variables. Pero puede pasar que realicen alguna función independiente, en cuyo caso, sería un error eliminar una.
• No permitir herencia múltiple cuando hay variables duplicadas.

Como se puede observar, no es fácil solucionar conflictos entre variables de instancia, por ello muchos lenguajes optan por diversos mecanismos incluyendo la prohibición de la herencia múltiple.

 

Ejemplo

Un automóvil está compuesto de carrocería, motor, ruedas, etc.

Los objetos son, por naturaleza, complejos; es decir, están compuestos de objetos más pequeños. Un sistema de información debe reflejar esta propiedad de los objetos de forma natural. En una base de datos relacional, un objeto complejo debe ser descompuesto en sus partes más simples para ser almacenado. Al extraerlo, es necesario ensamblar cada una de sus partes.

Por este motivo el modelo relacional comporta problemas cuando se utiliza en aplicaciones como el CAD, donde los objetos que se procesan son muy complejos.

Las bases de datos de objetos deben proporcionar la facilidad de obtener un objeto complejo en una sola consulta de forma transparente. En este caso, los apuntadores son un mecanismo excelente para representar composición, ya que permiten acceder rápidamente a las partes componentes de un objeto, sin importar su lugar de almacenamiento.

Las bases de datos requieren independencia de la aplicación, lo que provoca un conflicto conceptual cuando se trabaja con objetos compuestos: las bases de datos deben almacenar información independiente de la aplicación para que nuevas aplicaciones puedan hacer diferentes interpretaciones de la información original; pero con los objetos compuestos esto no es tan sencillo, puesto que suelen tener una sola interpretación, o mejor dicho, una sola manera de ser consultado en una base de datos.

La persistencia se define como la capacidad de un objeto para sobrevivir al tiempo de ejecución de un programa. Para implementarla, se utiliza el almacenamiento secundario.

Se han propuesto varios mecanismos para implementar la persistencia en los lenguajes de programación, entre los que podemos destacar los siguientes:

•    Archivos planos. Se crean archivos para almacenar los objetos en el formato deseado por el programador. Los objetos se cargan al abrir el programa y se guardan al finalizar. Ésta es la opción más accesible para   todos los lenguajes de programación.

•    Bases de datos relacionales. Los objetos son mapeados a tablas, un módulo del programa se encarga de hacer las transformaciones objeto-relacionales. Este enfoque consume mucho tiempo al realizar el mapeo. Existen algunas herramientas que realizan mapeos semiautomáticos.

•    Bases de objetos. Los objetos son almacenados de forma natural en una base de objetos, y la consulta y recuperación es administrada por el gestor, de esta forma las aplicaciones no necesitan saber nada sobre los detalles de implementación.

•    Persistencia transparente. Los objetos son almacenados y recuperados por el sistema cuando éste lo cree conveniente, sin que el usuario  deba hacer ninguna solicitud explícita de consulta, actualización o  recuperación de información a una base de objetos. No se requiere, por lo tanto, otro lenguaje para interactuar con las bases de datos.

El argumento a favor de las bases de datos objeto-relacionales sostiene que permite realizar una migración gradual de sistemas relacionales a los orientados a objetos y, en algunas circunstancias, coexistir ambos tipos de aplicaciones durante algún tiempo.

El problema de este enfoque es que no es fácil lograr la coexistencia de dos modelos de datos diferentes como son la orientación a objetos y el modelo relacional. Es necesario equilibrar de alguna manera los conceptos de uno y otro modelo sin que entren en conflicto.

Uno de los conceptos fundamentales en la orientación a objetos es el concepto de clase. Existen dos enfoques para asociar el concepto de clase con el modelo relacional:

1^.er enfoque: las clases definen tipos de tablas
2.º enfoque: las clases definen tipos de columnas

Dado que en el modelo relacional las columnas están definidas por tipos de datos, lo más natural es hacer corresponder las columnas con las clases.

	1.er enfoque	2.o enfoque
Los objetos son	valores	tuplas
Las clases son	dominios	tablas

Los mecanismos de extensión

No es habitual que el usuario utilice los mecanismos de extensión pues se consideran mecanismos avanzados.

PostgreSQL implementa los objetos como tuplas y las clases como tablas. Aunque también es posible definir nuevos tipos de datos mediante los mecanismos de extensión.

Dado que las tablas son clases, pueden definirse como herencia de otras. Las tablas derivadas son polimorfas y heredan todos los atributos (columnas) de la tabla padre (incluida su clave primaria). Si no se manejan con precaución, las tablas polimorfas pueden conducir a errores de integridad al duplicar claves primarias.

Veremos estos conceptos más en detalle en el subapartado 4.2 de esta unidad didáctica.

PostgreSQL soporta algunas extensiones del lenguaje SQL para crear y gestionar este tipo de tablas.

 

* Distintos tipos de credenciales     permiten distintos niveles de            acceso.

Antes de intentar conectarse con el servidor, debemos asegurarnos de que está funcionando y que admite conexiones, locales (el SGBD se está ejecutando en la misma máquina que intenta la conexión) o remotas.
 

En el apartado que concierne a la administración de PostgreSQL se comenta detalladamente los aspectos relacionados con el istema de usuarios, contraseñas y privilegios del SGBD.

Una vez comprobado el correcto funcionamiento del servidor, debemos disponer de las credenciales necesarias para la conexión. Para simplificar, supondremos que disponemos de las credenciales* del administrador de la base de datos (normalmente, usuario PostgreSQL y su contraseña).

Para conectarse con un servidor, se requiere, obviamente, un programa cliente. Con la distribución de PostgreSQL se incluye un cliente, psql, fácil de utilizar, que permite la introducción interactiva de comandos en modo texto.

El siguiente paso es conocer el nombre de una base de datos residente en el servidor. El siguiente comando permite conocer las bases de datos residentes en el servidor:

Para realizar una conexión, se requieren los siguientes datos:

•    Servidor. Si no se especifica, se utiliza localhost.

•    Usuario. Si no se especifica, se utiliza el nombre de usuario Unix que ejecuta psql.

•    Base de datos.

Ejemplos del uso de psql para conectarse con un servidor de bases de datos

Las dos formas anteriores ejecutan psql con la base de datos demo.

A partir del fragmento anterior, el cliente psql mostrará algo similar a lo siguiente:

El símbolo ‘#’, que significa que psql está listo para leer la entrada del usuario.

Notación

Hemos utilizado los dos comandos de ayuda que ofrece el lenguaje: •   \h Explica la sintaxis de entencias SQL. •   \? Muestra los comandos nternos disponibles. Para salir de ayuda, se presiona la tecla ‘q’.

Las sentencias SQL se envían directamente al servidor para su interpretación, los comandos internos tienen la forma \comando y ofrecen opciones que no están incluidas en SQL y son interpretadas internamente por psql.

Para terminar la sesión con psql, utilizamos el comando \q o podemos presionar Ctrl-D.

Las sentencias SQL que escribamos en el cliente deberán terminar con ‘;’ o bien con ‘\g’:

Cuando un comando ocupa más de una línea, el indicador cambia de forma y va señalando el elemento que aún no se ha completado.

 

 

 

Indicadores de PostgreSQL
Indicador	Significado
=#	Espera una nueva sentencia
-#	La sentencia aún no se ha terminado con “;” o \g
“#	Una cadena en comillas dobles no se ha cerrado
‘#	Una cadena en comillas simples no se ha cerrado
(#	Un paréntesis no se ha cerrado

 

El cliente psql almacena la sentencia hasta que se le da la orden de enviarla al SGBD. Para visualizar el contenido del buffer donde ha almacenado la sentencia, disponemos de la orden ‘\p’:

El cliente también dispone de una orden que permite borrar completamente
el buffer para empezar de nuevo con la sentencia:

Además de ser interactivo, psql puede procesar comandos por lotes almacenados en un archivo del sistema operativo mediante la siguiente sintaxis:

 

Aunque el siguiente comando también funciona en el mismo sentido, no es recomendable usarlo porque de este modo, psql no muestra información de depuración importante, como los números de línea donde se localizan los errores, en caso de haberlos:

 

El propio intérprete psql nos proporciona mecanismos para almacenar en fichero el resultado de las sentencias:

* Hemos almacenado el resultado     en el fichero ‘/tmp/a.txt’.

•    Especificando el fichero destino* directamente al finalizar una sentencia:

 

•    Mediante una pipe enviamos la salida a un comando Unix:

Notación

A la orden ‘\o’ se le debe espe- cificar un fichero o bien un co- mando que irá recibiendo los resultados mediante una pipe. Cuando se desee volver a la salida estándar STDOUT, simplemente se dará la orden ‘\o’ sin ningún parámetro.

•    Mediante la orden ‘\o’ se puede indicar dónde debe ir la salida de las sentencias SQL que se ejecuten en adelante:

•    Se puede solicitar la ejecución de un solo comando y terminar inmediatamente mediante la siguiente forma:

La salida del fichero

Al haber especificado que se quiere la salida en html, la podríamos redirigir a un fichero (ya hemos visto cómo hacerlo) y generar un archivo html que permitiese ver el resultado de la consulta mediante un navegador web convencional

•    Se puede especificar el formato de salida de los resultados de una sentencia.
Por defecto, psql los muestra en forma tabular mediante texto. Para cambiarlo, se debe modificar el valor de la variable interna ‘format’ mediante la orden

Para poder realizar los ejemplos del resto del presente apartado, se debe procesar el contenido del fichero demo.sql tal como se transcribe a continuación.

Contenido del fichero demo.psql

La siguiente orden informa sobre las bases de datos actualmente en el SGBD.

La orden ‘\c’ permite conectarse a una base de datos:

La consulta de la tabla que contiene la base de datos demo se realiza mediante la orden ‘\d’:

 

Consulta de las columnas de cada una de las tablas:

Para crear una nueva base de datos, usaremos la sentencia create database:

Para eliminar una base de datos, usaremos la sentencia dropdatabase:

Una vez conectados a una base de datos, la sentencia SQL create table permite crear las tablas que necesitemos:

El comando drop table permite eliminar tablas:

La tabla recién creada aparece ahora en la lista de tablas de la base de datos en uso:

Podemos consultar su descripción mediante el comando \d tabla:

 

La tabla está lista para insertar en ella algunos registros.

 

Este aspecto se explicará en detalle más adelante.

El número con el que responde el comando insert se refiere al OID del registro insertado.

Las consultas se realizan con la sentencia SQL select. En este caso solicitamos que nos muestre todas las columnas de los registros en la tabla persona:

Las tablas creadas en PostgreSQL incluyen, por defecto, varias columnas ocultas que almacenan información acerca del identificador de transacción en que pueden estar implicadas, la localización física del registro dentro de la tabla (para localizarla muy rápidamente) y, los más importantes, el OID y el TABLE OID. Estas últimas columnas están definidas con un tipo de datos especial llamado  identificador  de  objeto  (OID)  que  se  implementa  como  un  entero positivo de 32 bits. Cuando se inserta un nuevo registro en una tabla se le asigna un número consecutivo como OID, y el TABLEOID de la tabla que le corresponde.

Para observar las columnas ocultas, debemos hacer referencia a ellas específicamente en el comando select:

Ejemplo de la utilización de OID para enlazar dos tablas

Retomamos la tabla persona y construimos una nueva tabla para almacenar los teléfonos.

La tabla teléfono incluye la columna propietario de tipo OID, que almacenará la referencia a los registros de la tabla persona. Agreguemos dos teléfonos a ‘Alejandro Magno’, para ello utilizamos su OID que es 17242:

Las dos tablas están vinculadas por el OID de persona.

La operación que nos permite unir las dos tablas es join, que en este caso une teléfono y persona, utilizando para ello la igualdad de las columnas telefono.propietario y persona.oid:

Los OID de PostgreSQL presentan algunas deficiencias:

•    Todos los OID de una base de datos se generan a partir de una única secuencia centralizada, lo que provoca que en bases de datos con mucha actividad de inserción y eliminación de registros, el contador de 4 bytes se desborde y pueda entregar OID ya entregados. Esto sucede, por supuesto, con bases de datos muy grandes.

•    Las tablas enlazadas mediante OID no tienen ninguna ventaja al utilizar operadores de composición en términos de eficiencia respecto a una clave primaria convencional.

•    Los OID no mejoran el rendimiento. Son, en realidad, una columna con un número entero como valor.

Los desarrolladores de PostgreSQL proponen la siguiente alternativa para usar OID de forma absolutamente segura:

•    Crear una restricción de tabla para que el OID sea único, al menos en cada tabla. El SGBD irá incrementando secuencialmente el OID hasta encontrar uno sin usar.

•    Usar la combinación OID - TABLEOID si se necesita un identificador único para un registro válido en toda la base de datos.

Por los motivos anteriores, no es recomendable el uso de OID hasta que nuevas versiones de PostgreSQL los corrijan. En caso de usarlos, conviene seguir las recomendaciones anteriores.

 

Es posible crear tablas que no incluyan la columna OID mediante la siguiente notación:

 

PostgreSQL ofrece como característica particular la herencia entre tablas, que permite definir una tabla que herede de otra previamente definida, según la definición de herencia que hemos visto en capítulos anteriores.

Retomemos la tabla persona definida como sigue:

A partir de  esta  definición, creamos la tabla estudiante  como derivada de persona:

 

En la tabla estudiante se definen las columnas carrera, grupo y grado, pero al so- licitar información de la estructura de la tabla observamos que también inclu- ye las columnas definidas en persona:

En este caso, a la tabla persona la llamamos padre y a la tabla estudiante, hija.

Cada registro de la tabla estudiante contiene 5 valores porque tiene 5 columnas:

La consulta del contenido de la tabla estudiante mostrará, por supuesto, un solo registro. Es decir, no se heredan los datos, únicamente los campos (atributos) del objeto:

Además, la consulta de la tabla persona mostrará un nuevo registro:

 

El último registro mostrado es el que fue insertado en tabla estudiante, sin embargo la herencia define una relación conceptual en la que un estudiante es-una persona. Por lo tanto, al consultar cuántas personas están registradas en la base de datos, se incluye en el resultado a todos los estudiantes. Para consultar sólo a las personas que no son estudiantes, podemos utilizar el modificador ONLY:

Como es lógico, al borrar la fila del nuevo estudiante que hemos insertado, se borra de las dos tablas. Tanto si lo borramos desde la tabla persona, como si lo borramos desde la tabla estudiante.

Los OID permiten que se diferencien los registros de todas las tablas, aunque sean heredadas: nuestro estudiante tendrá el mismo OID en las dos tablas, ya que se trata de única instancia de la clase estudiante:

 

Dado que no se recomienda el uso de OID en bases muy grandes, y debe incluirse explícitamente en las consultas para examinar su valor, es conveniente utilizar una secuencia compartida para padres y todos sus descendientes si se requiere un identificador.

En PostgreSQL, una alternativa para no utilizar los OID es crear una columna de tipo serial en la tabla padre, así será heredada en la hija. El tipo serial define una secuencia de valores que se irá incrementando de forma automática, y por lo tanto constituye una buena forma de crear claves primarias, al igual que el tipo AUTO_INCREMENT en MySQL.

La columna id se define como un entero y se incrementará  utilizando la función nextval() tal como nos indica la información de la columna:

 

Al definir un tipo serial, hemos creado implícitamente una secuencia independiente de la tabla. Podemos consultar las secuencias de nuestra base de datos mediante el comando ‘\ds’:

Creamos nuevamente la tabla estudiante heredando de persona:

El estudiante heredará la columna id y se incrementará utilizando la misma secuencia:

Insertaremos en la tabla algunos registros de ejemplo, omitiendo el valor para la columna id:

 

La tabla estudiante contendrá un  solo registro, pero su identificador es el número 3.

Todos los registros de persona siguen una misma secuencia sin importar si son padres o hijos:

La herencia es útil para definir tablas que conceptualmente mantienen elementos en común, pero también requieren  datos que los hacen diferentes. Uno de los elementos que conviene definir como comunes son los identificadores de registro.

Como ya sabemos, las restricciones permiten especificar condiciones que deberán cumplir tablas o columnas para mantener la integridad de sus datos. Algunas de las restricciones vendrán impuestas por el modelo concreto que se esté implementando, mientras que otras tendrán su origen en las reglas de negocio del cliente, los valores que pueden tomar algunos campos, etc.

 

Ejemplo

Una columna definida como integer no puede contener cadenas de         caracteres.

Los valores que puede contener una columna están restringidos en primer lugar por el tipo de datos. Ésta no es la única restricción que se puede definir para los valores en una columna, PostgreSQL ofrece las restricciones siguientes:

•    null y not null. En múltiples ocasiones el valor de una columna es desconocido, no es aplicable o no existe. En estos casos, los valores cero, cadena vacía o falso son inadecuados, por lo que utilizamos null para especificar la ausencia de valor. Al definir una tabla podemos indicar qué columnas podrán contener valores nulos y cuáles no.

 

El nombre de una persona no puede ser nulo, y es posible que la persona no tenga trabajo. También es posible que no tenga correo, al no especificar una restricción not null, se asume que la columna puede contener valores nulos.

 

•    unique. Esta restricción se utiliza cuando no queremos que los valores contenidos en una columna puedan duplicarse.

 

cónyuge no puede contener valores duplicados, no permitiremos que dos personas tengan simultáneamente el mismo cónyuge.

 

•    primary key. Esta restricción especifica la columna o columnas que elegimos como clave primaria. Puede haber múltiples columnas unique, pero sólo debe haber una clave primaria. Los valores que son únicos pueden servir para identificar una fila de la tabla de forma unívoca, por lo que se les denomina claves candidatas.

 

create table Persona (
nss varchar(10) primary key, conyuge varchar(40) unique,
);

 

Al definir una columna como primary key, se define implícitamente con unique. El nss (número de la seguridad social) no sólo es único, sino que lo utilizamos para identificar a las personas.

 

•    references y foreign key. En el modelo relacional, establecemos las relaciones entre entidades mediante la inclusión de claves foráneas en otras relaciones. PostgreSQL y SQL ofrecen mecanismos para expresar y mantener esta  integridad  referencial.  En  el  siguiente  ejemplo,  las  Mascotas  tienen como dueño a una Persona:

 

Una referencia por defecto es a una clave primaria, por lo que dueño se refiere implícitamente al nss de Persona. Cuando se capturen los datos de una nueva mascota, PostgreSQL verificará que el valor de dueño haga referencia a un nss que exista en Persona, en caso contrario emitirá un mensaje de error. En otras palabras, no se permite asignar a una mascota un dueño que no exista.

También es posible especificar a qué columna de la tabla hace referencia:

o su equivalente:

Podría darse el caso de que la clave primaria de la tabla referenciada tuviera más de una columna, en ese caso, la clave foránea también tendría que estar formada por el mismo número de columnas:

Si no se especifica otra acción, por omisión la persona que tenga una mascota no puede ser eliminada, porque la mascota se quedaría sin dueño. Para poder eliminar una persona, antes se deben eliminar las mascotas que tenga. Este comportamiento no parece ser el más adecuado para el caso.

Para modificar este comportamiento disponemos de las reglas de integridad referencial del lenguaje SQL, que PostgreSQL también soporta. En el siguiente ejemplo se permite que al eliminar una persona, las mascotas simplemente se queden sin dueño.

 

En cláusula on delete se pueden especificar las siguientes acciones:

–    set null. La referencia toma el valor NULL: si se elimina Persona su Mascota se quedará sin dueño.

–    set default. La referencia toma el valor por omisión.

–    cascade. La acción se efectúa en cascada: si se elimina Persona automáticamente se elimina su Mascota.

–    restrict. No permite el borrado del registro: no se puede eliminar una Persona que tenga Mascota. Ésta es la acción que se toma por omisión.

Si se modifica la clave primaria de la tabla referenciada, se dispone de las mismas acciones que en el caso anterior, que especificaremos con la cláusula ON UPDATE.

•    check. Esta restricción realiza la evaluación previa de una expresión lógica cuando  se  intenta  realizar  una  asignación.  Si  el  resultado  es  verdadero, acepta el valor para la columna, en caso contrario, emitirá un mensaje de error y rechazará el valor.

Comparación                                         de expresiones regulares

El operador ~ realiza compara- ciones de cadenas con expre- siones regulares. Las expresiones regulares son patrones de búsqueda muy flexibles desarrollados en el mundo Unix.

 

Se han restringido los valores que se aceptarán en la columna de la manera siguiente.

•  Edad debe estar entre 11 y 79 años.
•  Ciudad no debe una cadena vacía.
•  Correo debe tener una arroba.

 

Cualquiera de esas restricciones puede tener nombre, de manera que se facilita la  referencia  a  las  restricciones  específicas  para  borrarlas,  modificarlas,  etc. pues puede hacerse por nombres. Para dar nombre a una restricción, utilizamos la sintaxis siguiente:

PostgreSQL crea índices para las llaves primarias de todas las tablas. Cuando se necesite crear índices adicionales, utilizaremos la expresión del ejemplo siguiente:

 

Como ya sabemos, el cliente psql ofrece varias alternativas para obtener información sobre la estructura de nuestra base de datos. En la siguiente tabla se muestran algunos comandos de mucha utilidad.

Comando	Descripción
\1	Lista las bases de datos
\d	Describe las tablas de la base de datos en uso
\ds	Lista las secuencias
\di	Lista los índices
\dv	Lista las vistas
\dp \z	Lista los privilegios sobre las tablas
\da	Lista las funciones de agregados
\df	Lista las funciones
\g archivo	Ejecuta los comandos de archivo
\H	Cambia el modo de salida HTML
\! comando	Ejecuta un comando del sistema operativo

Para obtener la lista de tablas de la base de datos demo hacemos lo siguiente:

 

 

La estructura de la tabla productos se solicita de la siguiente manera.

 

 

En el ejemplo anterior podemos observar que la columna clave contiene dos modificadores:

•    El primero especifica que no pueden asignarse valores nulos.

•    El segundo especifica el valor por omisión que deberá asignarse a la columna.
 

* Una secuencia es un nombre          especial que permite la producción   de series numéricas.

En este caso, el valor será automáticamente calculado por la función nextval(), que toma como argumento la secuencia* productos_clave_seq.

El siguiente comando muestra las secuencias creadas en una base de datos:

Las  secuencias  se  crean  automáticamente  cuando  se  declaran  columnas  de tipo serial.

 

En la estructura de la tabla productos encontramos también una clave primaria. PostgreSQL generará siempre un índice para cada tabla utilizando la clave primaria. La lista de los índices de la base de datos se obtiene de la siguiente forma:

El  conjunto  de  comandos  proporcionados  por  psql  que  hemos  presentado permite obtener información sobre la estructura de nuestra base de datos de una manera directa y sencilla y, también, es útil para explorar bases de datos que no conozcamos.

Para modificar la estructura de una tabla una vez construida, disponemos de la sentencia SQL alter table.

Mediante esta sentencia, podemos llevar a cabo las operaciones siguientes:

•    Agregar una columna.

•    Eliminar una columna.

•    Fijar el valor por omisión de una columna.

•    Eliminar el valor por omisión de una columna.

•    Renombrar una columna.

•    Renombrar una tabla.

Las consultas a la base de datos se realizan con el comando select, que se implementa en PostgreSQL cumpliendo en gran parte con el estándar SQL:

 

Notación

Omitiremos las referencias comunes a SQL y sólo se mostrarán algunas de las posibilidades de consulta con PostgreSQL. Por lo que res- pecta a las funciones auxiliares, se han visto algunas en el apartado de tipos de datos y, en todo caso, se recomienda la consulta de la documentación del producto para las  operaciones más avanzadas.

 

Al igual que MySQL, PostgreSQL admite la sentencia explain delante de select para examinar qué está ocurriendo durante una consulta:

Al igual que en el módulo de MySQL, vemos que no aprovecha los índices (básicamente porque no tenemos ninguno definido).

 

Veamos como mejorar el rendimiento de este select:

 

PostgreSQL cumple con el estándar SQL en todos los sentidos para las sentencias de actualización, inserción y borrado. No define modificadores ni otros mecanismos para estas sentencias.

En determinadas cláusulas, y para tablas heredadas, es posible limitar el borrado o la actualización a la tabla padre (sin que se propague a los registros de las tablas hijas) con la cláusula only:

Ejemplo

Una compra puede ser una transacción que conste de dos operaciones: •   Insertar un registro del pago del producto •   Insertar el producto en el inventario. No se debe insertar un producto que no se haya pagado, ni pagar un producto que no esté en el inventario, por lo tanto, las dos operaciones forman una transacción.

Definimos transacción como un conjunto de operaciones que tienen significado solamente al actuar juntas.

PostgreSQL ofrece soporte a transacciones, garantizando que ambas operaciones se realicen o que no se realice ninguna. Para iniciar una transacción, se utiliza el comando begin y para finalizarla, commit.

El nuevo registro tiene como clave el 13 y, de momento, hasta que finalice la transacción, sólo puede verlo el usuario que lo ha insertado.

 

Insertamos un registro con el precio del proveedor Patito para el producto con clave 13.

Al cerrar la transacción, los registros insertados ya son visibles para todos los usuarios. Si por alguna razón, por ejemplo una caída del sistema, no se ejecuta el commit, la transacción se cancela. La forma explícita de cancelar una transacción es con el comando rollback.

 

Veamos el programa HolaMundo en PL/pgSQL:

La función tiene tres partes:

•    El encabezado que define el nombre de la función y el tipo de retorno.

•    El cuerpo de la función, que es una cadena de texto (por lo tanto, siempre va entre comillas dobles).

•    La especificación del lenguaje utilizado.

La función recien creada tiene las mismas características que las integradas.

 

Puede solicitarse mediante el comando select:

Puede eliminarse mediante el comando drop function.

La sentencia alias crea un nuevo       nombre para una variable.                   La sentencia rename cambia el           nombre de una variable.

Las funciones pueden recibir parámetros, sólo es necesario especificar los tipos de  datos. PostgreSQL asigna los nombres  a los  parámetros utilizando la secuencia $1, $2, $3...

En este ejemplo veremos todas las posibles maneras de declarar variables en una función.

 

La estructura básica de una función es el bloque, que incluye dos partes, la declaración de variables y la sección de sentencias:

declare
sección de variables
begin
sección de sentencias
end;

Sentencia	Descripción
declare begin end	Bloque
:=	Asignación
select into	Asignación desde un select
Sentencias sql	Cualquier sentencia sql
perform	Realiza una llamada a comando sql
execute	Interpreta una cadena como comando sql
exit	Termina la ejecución de un bloque
return	Termina la ejecución de una función
if	Ejecuta sentencias condicionalmente
loop	Repite la ejecución de un conjunto de sentencias
while	Repite un conjunto de sentencias mientras
for	Repite un conjunto de sentencias utilizando una variable de control
raise	Despliega un mensaje de error a advertencia

La sentencia de asignación utiliza el operador ‘:=‘ para almacenar los resultados de expresiones en variables. PostgreSQL proporciona otra sentencia para hacer asignaciones, select. Esta sentencia debe obtener como resultado un solo valor para que pueda ser almacenado en la variable:

La ejecución de comandos sql como create, drop, insert o update pueden hacerse sin ninguna sintaxis especial. La excepción es el comando select, que requiere  ejecutarse  con  el  comando  perform  a  fin  de  que  el  resultado  de  la consulta sea descartado.

 

La sentencia execute también ejecuta un comando sql pero a partir de una cadena de texto. Esta sentencia comporta el problema de que su sintaxis no se verifica hasta la ejecución. Se puede utilizar, por ejemplo, para procesar parámetros como comandos sql:

El comando exit termina la ejecución de un bloque. Se utiliza principalmente para romper ciclos.

La bifurcación, o ejecución condicional, se realiza mediante la sentencia if:

 

También puede utilizarse if con más de dos ramas:

Con referencia a los bucles, PL/pgSQL ofrece tres opciones:

•    El bucle loop es infinito, por lo que tiene una estructura muy simple. Por lo general se utiliza con alguna sentencia if para terminarlo:

   cont := 0;
   loop
   if ( cont = 10 )
   then exit;
   end if;
   -- alguna acción
  cont := cont + 1;
  end loop;

 

•    El bucle while incluye la condición al inicio del mismo, por lo que el control de su terminación es más claro:

   cont := 0;
   while cont != 10 loop
   -- alguna acción
  cont := cont + 1;
  end loop;

•    El bucle for permite realizar un número de iteraciones controladas por la variable del ciclo:

   for cont in 1 .. 10 loop
  -- alguna acción
   end loop;

La sentencia raise permite enviar mensajes de tres niveles de severidad:

•    debug. El mensaje se escribe en la bitácora del sistema (logs).
•    notice. El mensaje se escribe en la bitácora y en el cliente psql.
•    exception . El mensaje se escribe en la bitácora y aborta la transacción.

 

El mensaje puede incluir valores de variables mediante el carácter ‘ %’:

•    raise debug ‘funcion(): ejecutada con éxito;
•    raise notice ‘El valor % se tomo por omisión’, variable;
•    raise excepción ‘El valor % está fuera del rango permitido’, variable;

 

 

Las funciones deben llamarse explícitamente para su ejecución o para incluirlas en consultas. Sin embargo, se puede definir que algunas funciones se ejecuten automáticamente cuando cierto evento tenga lugar en cierta tabla. Estas funciones se conocen como disparadores o triggers y se ejecutan mediante los comandos insert, delete y uptade.

Agregamos la tabla historial que almacena los productos descontinuados cuando se eliminan de la tabla productos.

create table historial (fecha date, parte varchar(20),  tipo varchar(20), especificacion varchar(20),  precio float(6));

Para poder utilizar una función como disparador, no debe recibir argumentos y debe retornar el tipo especial trigger:

La variable old está predefinida por   PostgreSQL y se refiere al registro    con sus antiguos valores. Para          referirse a los nuevos valores,           se dispone de la variable new.

La función está lista para ser utilizada como disparador, sólo es necesario definirlo y asociarlo a la tabla y al evento deseado:

 

Acabamos de crear un disparador de nombre archivar que se activará cuando se ejecute el comando delete en la tabla productos. El usuario no necesita saber que se debe hacer una copia de seguridad de los registros borrados, se hace automáticamente.

Al crear el disparador, hemos especificado “before delete” al indicar la operación. PostgreSQL nos permite lanzar el disparador antes o después (before, after) que se efectúen las operaciones. Este matiz es importante, ya que, si este mismo disparador lo ejecutamos después de la operación, no veremos ninguna fila en la tabla. Es posible definir el mismo disparador para varias operaciones:

for each row execute procedure respaldar_borrados();

 

PostgreSQL está disponible para la mayoría de distribuciones de GNU/Linux. Su instalación es tan sencilla como ejecutar el instalador de paquetes correspondiente.

En Debian, el siguiente procedimiento instala el servidor y el cliente respectivamente:

En distribuciones basadas en RPM, los nombres de los paquetes son un poco diferentes:

 

Notación
Además del start también po- dremos utilizar los parámetros restart, stop, reload que permiten reiniciar, detener y recargar el servidor (releyendo su configuración), respectivamente.

Una vez instalado, se escribirá un script de inicio que permite lanzar y apagar el servicio PostgreSQL; de este modo, para iniciar el servicio, deberemos ejecutar el siguiente comando:

 

 

 

 

 

 

 

Si se desea realizar una instalación a partir del código fuente, puede obtenerse del sitio oficial www.postgresql.org. A continuación, se describe el proceso de instalación de forma muy simplificada. En la práctica podrán encontrarse algunas diferencias;  lo  más  recomendable  es  leer  cuidadosamente  la  documentación incluida en los archivos INSTALL y README. Cualquier duda no resuelta por la documentación, puede consultarse en la lista de distribución.

 

Con este proceso se instala la versión 7.4.6. El archivo se descomprime utilizando tar. Dentro del directorio recién creado se ejecuta configure, que realiza una comprobación de las dependencias de la aplicación. Antes de ejecutar configure, debemos instalar todos los paquetes que vamos a necesitar.

La compilación se realiza con make y, finalmente, los binarios producidos se copian en el sistema en los lugares convenientes con make install.

 

Después de instalados los binarios, se debe crear el usuario postgres (responsable de ejecutar el proceso postmaster) y el directorio donde se almacenarán los archivos de las bases de datos.

 

initdb
El ejecutable initdb realiza el procedimiento necesario para inicializar la base de datos de postgres, en este caso, en el directorio /usr/local/pgsql/data.

Una vez creado el usuario postgres, éste debe inicializar la base de datos:

 

 

Bibliografía
El proceso de compilación tiene múltiples opciones que se explican en la documentación incluida con las fuentes.

El postmaster ya está listo para ejecutarse manualmente:

 

El siguiente gráfico muestra de forma esquemática las entidades involucradas en el funcionamiento normal del gestor de bases de datos:

 

                                                                       

  

PostgreSQL está basado en una arquitectura cliente-servidor. El programa servidor se llama postgres y entre los muchos programas cliente tenemos, por ejemplo, pgaccess (un cliente gráfico) y psql (un cliente en modo texto).

Un proceso servidor postgres puede atender exclusivamente a un solo cliente; es decir, hacen falta tantos procesos servidor postgres como clientes haya. El proceso postmaster es el encargado de ejecutar un nuevo servidor para cada cliente que solicite una conexión.

Se llama sitio al equipo anfitrión (host) que almacena un conjunto de bases de datos PostgreSQL. En un sitio se ejecuta solamente un proceso postmaster y múltiples procesos postgres. Los clientes pueden ejecutarse en el mismo sitio o en equipos remotos conectados por TCP/IP.

Es posible restringir el acceso a usuarios o a direcciones IP modificando las opciones del archivo pg_hba.conf, que se encuentra en /etc/postgresql/pg_hba.conf.

Este  archivo,  junto  con  /etc/postgresql/postgresql.conf son  particularmente importantes, porque algunos de sus parámetros de configuración por defecto provocan multitud de problemas al conectar inicialmente y porque en ellos se especifican los mecanismos de autenticación que usará PostgreSQL para verificar las credenciales de los usuarios.

Para habilitar la conexión a PostgreSQL desde clientes remotos, debemos verificar el parámetro tcpip_socket = true en el fichero /etc/postgresql/postgresql.conf.

A continuación, para examinar los métodos de autenticación y las posibilidades de conexión de clientes externos, debemos mirar el fichero /etc/postgresql/ pg_hba.conf, donde se explicita la acción que hay que emprender para cada conexión proveniente de cada host externo, o grupo de hosts.

Al terminar la instalación, en el sistema operativo se habrá creado el usuario postgres, y en PostgreSQL se habrá creado un usuario con el mismo nombre.

Él es el único usuario existente en la base de datos y será el único que podrá crear nuevas bases de datos y nuevos usuarios.

Normalmente, al usuario postgres del sistema operativo no se le permitirá el acceso desde un shell ni tendrá contraseña asignada, por lo que deberemos convertirnos en el usuario root, para después convertirnos en el usuario postgres y realizar tareas en su nombre:

El usuario postgres puede crear nuevas bases de datos utilizando el comando createdb. En este caso, le indicamos que el usuario propietario de la misma será el usuario postgres:

 

Se ha creado el usuario yo con          permisos para crear bases de datos   y sin permisos para crear usuarios.

El  usuario  postgres  puede  crear  nuevos  usuarios  utilizando  el  comando createuser:

 

Los siguientes comandos eliminan bases de datos y usuarios, respectivamente:

Es recomendable que se agreguen los usuarios necesarios para operar la instalación de PostgreSQL, y recurrir, así, lo menos posible al ingreso con postgres.

También disponemos de sentencias SQL para la creación de usuarios, grupos y privilegios:

Los grupos permiten asignar privilegios a varios usuarios y su gestión es sencilla:

Para añadir o quitar usuarios de un grupo, debemos usar:

Entre las múltiples opciones para extender PostgreSQL, nos queda aún por ver la creación de tipos o dominios (según la nomenclatura del estándar SQL). PostgreSQL prevé dos tipos de datos definidos por el administrador:

•    Un tipo de datos compuesto, para utilizar como tipo de retorno en las funciones definidas por el usuario.

•    Un tipo de datos simple, para utilizar en las definiciones de columnas de las tablas.

A modo de ejemplo, veamos un tipo compuesto y la función que lo devuelve:

Para el tipo de datos simple, la definición es más compleja, pues se debe indicar a PostgreSQL funciones que tratan con este tipo que le permitirán usarlo en operaciones, asignaciones, etc.
 

Tratar con el tipo de datos simple
Habitualmente, las funciones que tratarán con este tipo de datos se escribirán en C.

A modo de ejemplo, vamos a crear el tipo “numero complejo”, tal como lo hace la documentación de PostgreSQL. En primer lugar, debemos definir la estructura donde almacenaremos el tipo:

Después, las funciones que lo recibirán o devolverán:

Ahora estamos en condiciones de definir las funciones, y el tipo:

 

El proceso es un poco farragoso, pero compensa por la gran flexibilidad que aporta al SGBD. A continuación, podríamos crear algunos operadores para trabajar con este tipo (suma, resta, etc.), mediante los pasos que ya conocemos.

La creación de un dominio en PostgreSQL consiste en un tipo (definido por el usuario o incluido en el SGBD), más un conjunto de restricciones. La sintaxis es la siguiente:

 

Se ha creado un dominio basado en un tipo definido por el sistema donde la única restricción es su longitud.

Evidentemente, deberíamos haber definido el operador complejo_mayor que recibiera dos números complejos e indicara si el primero es mayor que el segundo.

PostgreSQL tiene definidas dos bases de datos de sistema, template0 y template1(que habremos visto en los ejemplos al listar las bases de datos del gestor), con un conjunto de objetos tales como los tipos de datos que soporta o los lenguajes de procedimiento instalados.

La base de datos template0 se crea al instalar el servidor, con los objetos por defecto del mismo, y la base de datos template1 se crea a continuación de la anterior con algunos objetos más particulares del entorno o sistema operativo donde se ha instalado PostgreSQL. Esto hace que sea muy recomendable heredar siempre de template1 (que es el comportamiento por defecto).

Estas bases de datos se utilizan como “padres” del resto de bases de datos que se crean, de modo que, al crear una nueva base de datos, se copian todos los objetos de template1.

 

Ventajas de esta situación

Si queremos añadir algún objeto (una tabla, un tipo de datos, etc.) a todas las bases de datos, sólo tenemos que añadirlo a template1, y el resto de bases de datos que se hayan creado a partir de ésta lo tendrán disponible.

Si se instala un lenguaje sobre la base de datos template1, automáticamente todas las bases de datos también usarán el lenguaje. En las distribuciones de Linux es frecuente que se haya realizado de este modo, por lo que no hay necesidad de instalarlo.

 

 

Por supuesto, podemos escoger otra plantilla para crear bases de datos, especificándola en la sentencia:

Hacer periódicamente copias de seguridad de la base de datos es una de las tareas principales del administrador de cualquier base de datos. En PostgreSQL, estas copias de seguridad se pueden hacer de dos maneras distintas:

•    Volcando a fichero las sentencias SQL necesarias para recrear las bases de datos.

•    Haciendo copia a nivel de fichero de la base de datos.

En el primer caso, disponemos de la utilidad pg_dump, que realiza un volcado de la base de datos solicitada de la siguiente manera:

pg_dump es un programa cliente de la base de datos (como psql), lo que significa que podemos utilizarlo para hacer copias de bases de  datos remotas, siempre que tengamos privilegios para acceder a todas sus tablas. En la práctica, esto significa que debemos ser el usuario administrador de la base de datos para hacerlo.

Si nuestra base de datos usa los OID para referencias entre tablas, debemos indicárselo a pg_dump para que los vuelque también (pg_dump -o) en lugar de volver a crearlos cuando inserte los datos en el proceso de recuperación. Asimismo, si tenemos BLOB en alguna de nuestras tablas, también debemos indicárselo con el parámetro correspondiente (pg_dump -b) para que los incluya en el volcado.

Para restaurar un volcado realizado con pg_dump, podemos utilizar directamente el cliente psql:

 

pg_dump
pg_dump realiza la copia a partir de la base de datos de sistema template0, por lo que también se volcarán los tipos definidos, funciones, etc. de la base de datos. Cuando recuperemos esta base de datos, debemos crearla a partir de template0 si hemos perso-nalizado template1 (y no de template1 como lo haría por defecto la sentencia create database) para evitar duplicidades.

Una vez recuperada una base de datos de este modo, se recomienda ejecutar la sentencia analyze para que el optimizador interno de consultas de PostgreSQL vuelva a calcular los índices, la densidad de las claves, etc.

Las facilidades del sistema operativo Unix, permiten copiar una base de datos a otra en otro servidor de la siguiente manera:

 

 

 

 

 

Para hacer la copia de seguridad a nivel de fichero, simplemente copiamos los ficheros binarios donde PostgreSQL almacena la base de datos (especificado en tiempo de compilación, o en paquetes binarios, suele ser /var/lib/postgres/data), o bien hacemos un archivo comprimido con ellos:

El servicio PostgreSQL debe estar parado antes de realizar la copia.

A menudo, en bases de datos grandes, este tipo de volcados origina ficheros que pueden exceder los límites del sistema operativo. En estos casos tendremos que utilizar técnicas de creación de volúmenes de tamaño fijo en los comandos tar u otros con los que estemos familiarizados.

 

Hay una serie de actividades que el administrador de un sistema gestor de bases de datos debe tener presentes constantemente, y que deberá realizar periódicamente. En el caso de PostgreSQL, éstas se limitan a un mantenimiento y limpieza de los identificadores internos y de las estadísticas de planificación de las consultas, a una reindexación periódica de las tablas, y al tratamiento de los ficheros de registro.