Present A

Implementan do soluciones Cliente/Servid or con PostgreSQL Hernán Alonso Lotero R Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Contenido PostgreSQL Antecedentes, Introducción y Caracteristicas Tecnologias de BD. Cliente/Servidor Conectividad Abierta a bases de datos Implementacion de un esquema de tres capas Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

PRIMERA PARTE

POSTGRESQL INTRODUCCION Y CARACTERISTICAS Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

PostgreSQL ¿Donde obtener información? • En el Sitio oficial www.postgresql.org/docs: – – – – –

Tutorial (información para nuevos usuarios) User’s Guide (sql, tipos de datos, funciones, tuning) Administrator’s Guide (Instalación y mantenimiento) Programer’s Guide (extensión de funciones, librerias, diseño) Reference Manual (sintaxis SQL, programas cliente y servidor)

– Developers Guide (Información para desarrolladores, PL)

• Hispalinux (Español)

• PostgreSQL: Introduction and Concepts.Bruce Momjian

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Antecedentes •

•

La implementación del DBMS POSTGRES empezó en 1996 en la Universidad de Berkeley en California por el profesor Michael Stonebraker PostgreSQL es código abierto descendiente del original Berkeley

•

La creciente comunidad de usuarios demando gran cantidad de esfuerzo en soporte y mantenimiento, que debería ser invertido en Investigación. Por lo cual Berkeley terminó oficialmente el proyecto en 1993.

•

En 1994 Andrew Yu and Jolly Chen le adicionaron un interprete SQL. Postgres95 fue lanzado en la Web para que encontrara su propio camino. Fue escrito en C ANSI y se le realizaron algunas mejoras (funciones agregadas, group by, libpg, psql, libpgtcl, objetos grandes).

•

En 1996, Se cambio el nombre a PostgreSQL y se empezó a numerar desde la versión 6.0

,

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Características • •

Proporciona soporte a SQL92/SQL99. POSTGRES fue pionero de muchos de los conceptos objeto-relacional ahora disponibles en algunos DBMS comerciales.

•

PostgreSQL ofrece poder adicional incorporando los siguientes conceptos que representan una manera para que los usuarios extiendan el sistema: (HERENCIA, TIPOS DE DATOS, FUNCIONES), además de (CONSTRAINS, TRIGGERS, RULES, TRANSACTIONS).

•

Proporciona soporte e interfaces para diversos lenguajes incluyendo C, C++, Java, Perl, Tcl, PHP and Python.

•

Estas características lo califican como Objeto-Relacional (Ultima versión 7.3).

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Introducción Arquitectura del sistema basada en Procesos cooperativos: • Un proceso servidor: Maneja los archivos de base de datos, acepta conecciones a la base de datos y permite acciones sobre las B.D. El proceso servidor es llamado postmaster. • Las aplicaciones de usuario final (frontEnd): Desean realizar operaciones sobre la base de datos. Pueden ser de diversa natrualeza: Una herramienta de texto o consola, una aplicación gráfica, una interface Web.

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Arquitectura Servidor Postmaster

Cliente APLICACION

DATOS

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Iniciando la Base de Datos Creación de la base de datos

$ createdb mydb Eliminación de la Base de datos

$ dropdb mydb Accesando la base de datos mediante la consola interactiva de SQL (psql)

$ psql mydb Una vez conectdo puedo ejecutar instrucciones sql. Ejemplo:

mydb=> SELECT version(); ---------------------------------version -------------------------------------------PostgreSQL 7.3devel on i586-pc-linux-gnu, compiled by GCC 2.96 (1 row)

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Iniciando la Base de Datos Operaciones Matemáticas

mydb=> SELECT 2 + 2; ?column? ---------4 (1 row) Comandos SQL

mydb=> SELECT * from city; city | temp_avg | date ---------------+----------+-----------San Francisco | 48 | 1994-11-27 San Francisco | 50 | 1994-11-29 Hayward | 45 | 1994-11-29 (3 rows)

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Otras características:Vectores Uno de los principios del modelo relacional es que los atributos de una relación son atómicos Postgres no posee esta restricción. Postgres permite que los atributos de una instancia sean definidos como vectores multidimensionales de longitud fija o variable. Ej: CREATE TABLE SAL_EMP ( nombre text, pago_trimestre int4[], agenda text[][] ); INSERT INTO SAL_EMP VALUES ('Carol', '{20000, 25000, 25000, 25000}', '{{"talk", "consult"}, {"meeting"}}'); Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Vectores SELECT SAL_EMP.pago_trimestre[3] FROM SAL_EMP; +---------------+ |pago_trimestre | +---------------+ |10000 | +---------------+ |25000 | +---------------+ SELECT name FROM SAL_EMP WHERE SAL_EMP.pago_trimestre[1] <> SAL_EMP.pago_trimestre[2]; +------+ |name | +------+ |Carol | +------+

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Otra característica: Herencia CREATE TABLE cities name population altitude );

( text, float, int

-- (in ft)

CREATE TABLE capitals ( state char(2) ) INHERITS (cities); una instancia de capitals hereda (inherits) todos los atributos (name, population, altitude) de la clase cities. Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Herencia Por ejemplo, la siguiente consulta encuentra todas las ciudades situadas a una altitud de 500 pies o más: SELECT name, altitude FROM cities WHERE altitude > 500; +----------+----------+ |name | altitude | +----------+----------+ |Las Vegas | 2174 | +----------+----------+ |Mariposa | 1953 | +----------+----------+ Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Herencia SELECT c.name, c.altitude FROM cities* c WHERE c.altitude > 500; +----------+----------+ |name | altitude | +----------+----------+ |Las Vegas | 2174 | +----------+----------+ |Mariposa | 1953 | +----------+----------+ |Madison | 845 | +----------+----------+

Aquí, el "*" después de cities indica que la consulta debe realizarse sobre cities y todas las clases que estén por debajo de ella en la jerarquía de herencia Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Control de Concurrencia • A diferencia de la mayoría de otros sistemas de bases de datos que usan bloqueos para el control de concurrencia, Postgres mantiene la consistencia de los datos un modelo multiversión. • Mientras se consulta una base de datos, cada transacción ve una imagen de los datos (una versión de la base de datos) como si fuera tiempo atrás, sin tener en cuenta el estado actual de los datos que hay por debajo. Esto evita que la transacción vea datos inconsistentes que pueden ser causados por la actualización de otra transacción concurrente en la misma fila de datos, proporcionando aislamiento transaccional para cada sesión de la base de datos. Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Aislamiento transaccional El estándar ANSI/ISO SQL define cuatro niveles de aislamiento transaccional en función de tres hechos que deben ser tenidos en cuenta entre transacciones concurrentes. Estos hechos no deseados son: •

•

•

lecturas "sucias" – Una transacción lee datos escritos por una transacción no esperada, no confirmada (commited). lecturas no repetibles – Una transacción vuelve a leer datos que previamente había leído y encuentra que han sido modificados por una transacción confirmada. lectura "fantasma" – Una transacción vuelve a ejecutar una consulta, devolviendo un conjuto de filas que satisfacen una condición de búsqueda y encuentra que otras filas que satisfacen la condición han sido insertadas por otra transacción confirmada.

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Aislamiento transaccional Niveles de aislamiento de Postgres NIVEL

Lectura "sucia" Lectura no confirm. Posible

Lectura no Lectura repetible "fantasma" Posible Posible

Lectura confirmada No posible

Posible

Posible

Lectura repetible

No posible

No posible

Posible

Serializable

No posible

No posible

No posible

Postgres ofrece lectura confirmada y niveles de aislamiento serializables.

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Aislamiento transaccional NIVEL DE LECTURA CONFIRMADA (read committed) Lectura confirmada es el nivel de aislamiento por defecto en Postgres. Cuando una transacción se ejecuta en este nivel, la consulta sólo ve datos antes de que la consulta comenzara y nunca ve datos "sucios" pero si cambios en transacciones concurrentes confirmadas durante la ejecución de la consulta Los resultados de la ejecución de SELECT o INSERT (con una consulta) no se verán afectados por transacciones concurrentes.

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Aislamiento transaccional NIVEL DE LECTURA CONFIRMADA (READ COMMITTED) test=> BEGIN WORK; BEGIN test=> SELECT COUNT(*) FROM trans_test; count ------5 (1 row) test=> -test=> -- someone commits INSERT INTO trans_test test=> -test=> SELECT COUNT(*) FROM trans_test; count ------6 (1 row) test=> COMMIT WORK; COMMIT Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Aislamiento transaccional NIVEL DE AISLAMIENTO SERIALIZABLE •

La serialización proporciona el nivel más alto de aislamiento transaccional. Cuando una transacción está en el nivel serializable, la consulta sólo ve los datos cursados antes de que la transacción comience y nunca ve ni datos sucios ni los cambios de transacciones concurrentes confirmados durante la ejecución de la transacción.

•

Por lo tanto, este nivel emula la ejecución de transacciones en serie, como si las transacciones fueran ejecutadas un detrás de otra, en serie, en lugar de concurrentemente

•

una transacción serializable no puede modificar filas cambiadas por otras transacciones después de que la transacción serializable haya empezado

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Aislamiento serializable test=> BEGIN WORK; BEGIN test=> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET VARIABLE test=> SELECT COUNT(*) FROM trans_test; count ------5 (1 row) test=> -test=> -- someone commits INSERT INTO trans_test test=> -test=> SELECT COUNT(*) FROM trans_test; count ------5 (1 row) test=> COMMIT WORK; COMMIT Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Bloqueos y Tablas Postgres ofrece varios modos de bloqueo para controlar el acceso concurrente a los datos en tablas. Algunos de estos modos de bloqueo los adquiere Postgres automáticamente antes de la ejecución de una declaración, mientras que otros son proporcionados para ser usados por las aplicaciones. Todos los modos de bloqueo (excepto para AccessShareLock) adquiridos en un transacción se mantienen hasta la duración de la transacción.

Existen dos tipos de bloqueos: • Bloqueos a nivel de tabla • Bloqueos a nivel de registro Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Bloqueos a Nivel de tabla AccessShareLock Un modo de bloqueo adquirido automáticamente sobre tablas que están siendo consultadas. Postgres libera estos bloqueos después de que se haya ejecutado una declaración. RowShareLock Adquirido por SELECT FOR UPDATE y LOCK TABLE para declaraciones IN ROW SHARE MODE. RowExclusiveLock Lo adquieren UPDATE, DELETE, INSERT y LOCK TABLE para declaraciones IN ROW EXCLUSIVE MODE. ShareLock Lo adquieren CREATE INDEX y LOCK TABLE para declaraciones IN SHARE MODE. ShareRowExclusiveLock Lo toma LOCK TABLE para declaraciones IN SHARE ROW EXCLUSIVE MODE. ExclusiveLock Lo toma LOCK TABLE para declaraciones IN EXCLUSIVE MODE. AccessExclusiveLock Lo toman ALTER TABLE, DROP TABLE, VACUUM y LOCK TABLE. Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Bloqueos a Nivel de Fila • Este tipo de bloqueos se producen cuando campos internos de una fila son actualizados (o borrados o marcados para ser actualizados). Postgres no retiene en memoria ninguna información sobre filas modificadas y de este modo no tiene límites para el número de filas bloqueadas sin incremento de bloqueo. • Sin embargo, tenga en cuenta que SELECT FOR UPDATE modificará las filas seleccionadas marcándolas, de tal modo que se escribirán en el disco. • Los bloqueos a nivel de fila no afecta a los datos consultados. Estos son usados para bloquear escrituras a la misma fila únicamente. Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Bloqueos Ejemplo de Bloqueos Transaction 1 BEGIN WORK UPDATE

Transaction 2 BEGIN WORK

row 64 UPDATE

row 64

COMMIT WORK COMMIT WORK

Description start both transactions transaction 1 exclusively locks row 64 transaction 2 must wait to see if transaction 1 commits transaction 1 commits; transaction 2 returns from UPDATE transaction 2 commits

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Deadlock (Abrazo mortal) Transaction 1 Transaction 2 BEGIN WORK

start both transactions

row 83 independent rows write-locked holds waiting for transaction 2 to release write lock UPDATE row 83 attempt to get write lock held by UPDATE row 64 transaction 1 auto-ROLLBACK deadlock detected--transaction 2 is rolled back WORK transaction 1 returns from UPDATE and commits COMMIT WORK UPDATE

row 64

BEGIN WORK

Description

UPDATE

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Chequeos de consistencia •

Ya que las lecturas en Postgres no bloquean los datos, sin tener en cuenta el nivel de aislamiento de la transacción, los datos leídos por una transacción pueden ser sobreescritos por otra. En otras palabras, si una fila es devuelta por SELECT esto no significa que esta fila realmente exista en el momento en que se devolvió (un tiempo después de que la declaración o la transacción comenzaran, por ejemplo) ni que la fila esté protegida de borrados o actualizaciones por la transacción concurrente antes de que ésta se lleve a cabo o se pare.

•

Para asegurarse de la existencia de una fila y protegerla contra actualizaciones concurrentes, debería usar SELECT FOR UPDATE o una declaración de tipo LOCK TABLE más apropiada. Esto debe tenerse en cuenta cuando desde otros entornos se estén portando aplicaciones hacia Postgres utilizando el modo serializable.

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Chequos de consistencia test=> BEGIN WORK; BEGIN test=> SELECT * test-> FROM lock_test test-> WHERE name = 'James'; id | name -----+-------------------------------521 | James (1 row) test=> test=> test=> test=> test-> test-> UPDATE test=> COMMIT

-- (AQUÍ SE PUDE METER OTRA TRANSACCION) -- the SELECTed row is not locked -UPDATE lock_test SET name = 'Jim' WHERE name = 'James'; 1 COMMIT WORK;

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Chequos de consistencia test=> BEGIN WORK; BEGIN test=> SELECT * test-> FROM lock_test test-> WHERE name = 'James‘ FOR UPDATE; id | name -----+-------------------------------521 | James (1 row) test=> test=> test=> test=> test-> test-> UPDATE test=> COMMIT

-- (NO SE PUDE METER OTRA TRANSACCION) -- the SELECTed row is locked -UPDATE lock_test SET name = 'Jim' WHERE name = 'James'; 1 COMMIT WORK;

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Catalogo Principal Nombre del Catalogo pg_database pg_class pg_attribute pg_index pg_proc pg_type pg_operator pg_aggregate pg_am pg_amop pg_amproc pg_opclass

Descripcion base de datos clases atributos de clases indices secundarios procedimientos (ambos C y SQL) tipos (ambos base y complejo) operadores conjunto y conjunto de funciones metodo de acceso operador de metodo de acceso soporte de operador de metodo de acceso operador de clases de metodo de acceso

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Extendiendo SQL: Funciones Es posible extender el sistema mediante la creación de funciones. PostgresSQL proporciona tres tipos de funciones: • Funciones de lenguaje de consultas (funciones escritas en SQL) • Funciones de lenguaje procedural (funciones escritas en, por ejemplo, PLTCL o PLSQL) • Funciones de lenguaje de programación (funciones escritas en un lenguaje de programación compilado tales como C). Cada clase de función puede tomar un tipo base, un tipo compuesto o alguna combinación como argumentos (parámetros). Además, cada clase de función puede devolver un tipo base o un tipo compuesto

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Funciones del Lenguaje SQL Para ilustrar una función SQL sencilla, considere lo siguiente, que se podría usar para cargar en una cuenta bancaria: create function TP1 (int4, float8) returns int4 as 'update BANK set balance = BANK.balance + $2 where BANK.acctountno = $1 select(x = 1)' language 'sql'; Un usuario podría ejecutar esta función para cargar $100.00 en la cuenta 17 de la siguiente forma: select (x = TP1( 17,100.0)); Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Funciones del Lenguaje SQL Funciones SQL sobre tipos base: La función SQL más simple posible no tiene argumentos y sencillamente devuelve un tipo base, tal como int4: CREATE FUNCTION one() RETURNS int4 AS 'SELECT 1 as RESULT' LANGUAGE 'sql'; SELECT one() AS answer; +-------+ |answer | +-------+ |1 | +-------+ Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Funciones del Lenguaje SQL En este ejemplo, note cómo nos referimos a los argumentos dentro de la función como $1 y $2: CREATE FUNCTION add_em(int4, int4) RETURNS int4 AS 'SELECT $1 + $2;' LANGUAGE 'sql'; SELECT add_em(1, 2) AS answer; +-------+ |answer | +-------+ |3 | +-------+ Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Funciones del Lenguaje Procedural PL/pgSQL: Es un lenguaje procedural cargable para el sistema de bases de datos Postgres.Este paquete fue escrito originalmente por Jan Wieck con los siguientes objetivos: •

Pueda usarse para crear funciones y procedimientos disparados por eventos,

•

Añada estructuras de control al lenguaje SQL,

•

Pueda realizar cálculos complejos,

•

Herede todos los tipos definidos por el usuario, las funciones y los operadores,

•

Pueda ser definido para ser fiable para el servidor,

•

Sea fácil de usar

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Estructura del PL-pgSQL PL/pgSQL es un lenguaje orientado a bloques. Un bloque se define como: [<>] [DECLARE declarations] BEGIN statements END;

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Estructura del PL-pgSQL Ejemplo: CREATE FUNCTION logfunc2 (text) RETURNS datetime AS ' DECLARE logtxt ALIAS FOR $1; curtime datetime; BEGIN curtime := ''now''; INSERT INTO logtable VALUES (logtxt, curtime); RETURN curtime; END; ' LANGUAGE 'plpgsql'; Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Funciones Internas Las funciones escritas en C se pueden compilar en objetos que se pueden cargar de forma dinámica, y usar para implementar funciones SQL definidas por el usuario. Suponga que funcs.c es así: #include <string.h> #include "postgres.h" int add_one(int arg) { return(arg + 1); } Podriamos escribir: CREATE FUNCTION add_one(int4) RETURNS int4 AS 'PGROOT/tutorial/funcs.so' LANGUAGE 'c'; Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Triggers Si un evento trigger ocurre, el administrador de triggers (llamado Ejecutor) inicializa la estructura global TriggerData *CurrentTriggerData y llama a la función trigger para procesar el evento. La función trigger debe ser creada antes que el trigger, y debe hacerse como una función sin argumentos, y códigos de retorno opacos. La sintaxis para la creación de triggers es la siguiente: CREATE TRIGGER ON FOR EACH EXECUTE PROCEDURE <procedure name> (); Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

EJEMPLO DE UN TRIGGER: CREATE FUNCTION emp_stamp () RETURNS OPAQUE AS BEGIN -- Check that empname and salary are given IF NEW.empname ISNULL THEN RAISE EXCEPTION ''empname cannot be NULL value''; END IF; IF NEW.salary ISNULL THEN RAISE EXCEPTION ''% cannot have NULL salary'', NEW.empname; END IF; -- Who works for us when she must pay for? IF NEW.salary < 0 THEN RAISE EXCEPTION ''% cannot have a negative salary'',NEW.empname; END IF; -- Remember who changed the payroll when NEW.last_date := ''now''; NEW.last_user := getpgusername(); RETURN NEW; END; ' LANGUAGE 'plpgsql'; CREATE TRIGGER emp_stamp BEFORE INSERT OR UPDATE ON emp FOR EACH ROW EXECUTE PROCEDURE emp_stamp();

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Mejorando el Desempeño Existen diversas formas de mejorar el desempeño de la Base de datos. Entre ellas podemos destacar:

• • • • • •

Indexes Unique Indexes CLUSTER VACUUM VACUUM ANALYZE EXPLAIN

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Indices • •

• •

Internamente Postgres almacena los datos en archivos del sistema operativo. Cada tabla tiene su propio archivo. Un indice es un archivo separado ordenado por una o más columnas. Contiene apuntadores al archivo de datos permitiento rapido acceso a la tabla. Use indices sobre las columnas que aparecen en el Where y order by. Puede crear tantos indices como deseee, pero recuerde que tienen un costo de espacio en disco.

Ejemplo de creación de un indice simple: CREATE INDEX customer_custid_idx ON customer (customer_id);

Ejemplo de creación de un indice compuesto: CREATE INDEX customer_custid_idx ON customer (age , size); Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

CLUSTER • •

El comando cluster reordena fisicamente una tabla para que coincida con el orden del indice Este comando es de gran valor cuando el desempeño es critico y cuando existen muchos valores ducplicados.

Sintaxis:

CLUSTER indexname ON table

La tabla es realmente copiada a una tabla temporal en el orden indicado, luego renombra la nueva con el nombre de la original. Por esta razon, todos los persisos sobre la tabla se pierden.

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

VACUUM •

• • •

Cuando Postgres actualiza un registro, mantiene una copia del original y agrega uno nuevo. El registro original es marcado como borrados. De manera similar los registros eliminados con marcados como borrados. El comando VACUUM remueve los registros marcados como borrados del archivo. Se deberia correr VACCUM con cierta frecuencia sobre tablas que tienen gran movimiento. Puede correr el comando sobre una tabla o sobre toda la Base de datos

VACUUM VACUUM tablename VACUUM ANALYZE

(Toda la base de datos) (Una tabla) (Almacena además inf. Estadística de duplicados)

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

EXPLAIN Causa que postgres muestre como va a ejecutar un comando (plan de ejecución) test=> EXPLAIN SELECT customer_id FROM customer; NOTICE: QUERY PLAN: Seq Scan on customer (cost=0.00..15.00 rows=1000 width=4) EXPLAIN test=> CREATE UNIQUE INDEX custid_idx ON customer (customer_id); CREATE test=> EXPLAIN SELECT customer_id FROM customer WHERE customer_id = 55; NOTICE: QUERY PLAN: Index Scan using customer_custid_idx on customer (cost=0.00..2.01 rows=1 width=4)

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Informaciòn Adicional •Plataformas soportadas •Comparacion entre PostgreSQL y MySQL

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

SEGUNDA PARTE

TECNOLOGIAS DE BASES DE DATOS CLIENTE-SERVIDOR Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

CONCEPTO • La arquitectura cliente/servidor es un modelo para el desarrollo de sistemas de información, en el que las transacciones se dividen en procesos independientes que cooperan entre sí para intercambiar información, servicios o recursos. • Se denomina cliente al proceso que inicia el diálogo o solicita los recursos y servidor, al proceso que responde a las solicitudes. Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

FUNCIONES Los clientes realizan generalmente funciones como:  Manejo de la interface del usuario.  Captura y validación de los datos de entrada.  Generación de consultas e informes sobre las bases de datos Por su parte los servidores realizan, entre otras, las siguientes funciones:  Gestión de periféricos compartidos.  Control de accesos concurrentes a bases de datos compartidas.  Enlaces de comunicaciones con otras redes de área local o extensa.  Siempre que un cliente requiere un servicio lo solicita al servidor correspondiente y éste, le responde proporcionándolo. Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Características Generales • El servidor presenta a todos sus clientes una interface única y bien definida. • El cliente no necesita conocer la lógica del servidor, sólo su interface externa. • El cliente no depende de la ubicación física del servidor, ni del tipo de equipo físico en el que se encuentra, ni de su sistema operativo. • Los cambios en el servidor implican pocos o ningún cambio en el cliente.

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Caracteristicas Funcionales • • •

• •

Presentación distribuida o embellecimiento:El cliente asume parte de las funciones de presentación de la aplicación, ya que siguen existiendo programas en el servidor, dedicados a esta tarea. Presentación remota: la aplicación está soportada directamente por el servidor, excepto la presentación que es totalmente remota y reside en el cliente. Proceso distribuido o cooperativo :la lógica de los procesos se divide entre los distintos componentes del cliente y del servidor. El diseñador de la aplicación debe definir los servicios y las interfaces del sistema de información, de forma que los papeles de cliente y servidor sean intercambiables, excepto en el control de los datos, que es responsabilidad exclusiva del servidor. Gestión de datos remota :El cliente realiza tanto las funciones de presentación como los procesos. Por su parte, el servidor almacena y gestiona los datos que permanecen en una base de datos centralizada. Bases de datos distribuidas :El reparto de tareas es como en el anterior y además el gestor de base de datos divide sus componentes entre el cliente y el servidor.

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Caracteristicas Funcionales

Presentacion Remota Triggers y Procedimientos almacenados "Triggers": son eventos que se disparan cuando se detectan ciertos estados en la base de datos. Su función es permitir la implementación de reglas corporativas y permanentes, y su uso más típico ha sido el de proteger la integridad referencial de la base de datos (esa función hoy es cumplida por las capacidades declarativas de definir dicha integridad referencial que tienen actualmente todos los servidores importantes). El "trigger" llama "stored procedures" que se han programado previamente para atender a cada uno de dichos eventos. "Stored Procedures": son procedimientos que se programan para cumplir la parte de la lógica de la aplicación que se desea se ejecute en el servidor. Un "stored procedure" puede ser llamado por otro de ellos, por un "trigger" o, directamente desde el cliente, mediante un Call remoto (llamada remota). Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Presentacion Remota "Three Tiered Architecture" (Tres capas) •En este caso, se tiene la libertad de organizar cada aplicación en tres partes (administración de la base de datos, lógica de la aplicación y lógica de la presentación). También se tiene total libertad para la elección del lenguaje a utilizar. •Los programas serán óptimos desde el punto de vista de la performance. •También deberá implementarse especialmente el Call remoto, lo que seguramente se hará de una forma más libre que los Remote Procedure Call actualmente disponibles. •No existe compromiso alguno con el uso de lenguajes propietarios, por lo que las aplicaciones serán totalmente portables sin cambio alguno. •El problema de esta arquitectura es ¿cómo se implementa?. Parece ilusorio tratar de programar manualmente estos procedimientos, mientras que, si se dispone de una herramienta que lo hace automáticamente, presenta ventajas claras sobre la alternativa anterior. Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

TERCERA PARTE

CONECTIVIDAD ABIERTA DE BASES DE DATOS Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

ODBC ODBC (Open Database Connectivity) es un programa de interface de aplicaciones (API) para acceder a datos en sistemas manejadores de bases de datos tanto relacionales como no relacional, utilizando para ello SQL (lenguaje de consulta estructurado). ODBC es un intermediario entre bases de datos y aplicaciones, cuya tarea es sostener una conversación de preguntas y respuestas entre dos "sujetos" que no hablan el mismo idioma y que gestionan sus recursos de forma diferente

DATOS

ODBC

DBMS APLICACION

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

ODBC Para Realizar la coneccion a traves de ODBC entre un cliente Windows y el servidor de Bases de datos Postgres, es necesario realizar lo siguiente: • Instalar y configurar el servidor ODBC en Linux. Existen dos drivers ODBC para este propósito: UnixODBC (www.unixodbc.org) y PsqlODBC (www.psqlodbc.org). Recientes distribuciones de Linux ya traen el controlador ODBC. • Instalar y configurar el driver ODBC en windows. puede obtener un driver en: ftp://ftp.us.postgresql.org/odbc/versions /full/  Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R Para una información detallada consulte el articulo anexo.

ODBC

Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

CUARTA PARTE

IMPLANTACION DE UN MODELO DE TRES CAPAS Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R

Implantación de un Modelo 3-Tier Cuando se pretende realizar la implantación de un esquema cliente servidor de tres capas, se plantean preguntas como estas: •¿El sistema requiere caracteriscas de disponibilidad y seguridad? •¿Donde se almacenarán los datos? •¿Quien ejercera el control de los mismos? •¿Donde estará la logica del negocio? En el cliente? En el servidor? En ambos? •¿Donde estará la interface? •¿El motor de base de datos soporta transacciones y triggers? •¿Cual será una herramienta frontEnd Adecuada? Las respuestas a estas y otras preguntas, por supuesto están supeditas al entorno especifico del sistema que se pretende implantar y normalmente obedecen a decisiones de la fase de diseño. Lo importante aqui es destacar como en postgres puede aportar para algunos esquemas comunes de cliente servidor. Implementando Soluciones cliente/servidor con PostgreSQL / Hernán Alonso Lotero R