viernes, 30 de noviembre de 2012

REPLICACIÓN


REPLICACIÓN CON POSTGRESQL Y SLONY-I

En este articulo se abordará la replicación en PostgreSQL 8.4, el objetivo es mostrar las capacidades de replicación de este Sistema Gestor de Bases de Datos auxiliándose de herramientas extras, tales como lo es Slony.

SOBRE POSTGRESQL

PostgreSQL es una potente herramienta de gestión de bases de datos relacional y orientada a objetos (SGBDOO en sus siglas en ingles). PostgreSQL se distribuye bajo licencia BSD (Berkeley Software Distribution). Es una licencia de software libre permisiva, lo que permite su uso, redistribución, modificación  con la única restricción de mantener el copyright del software a sus autores.

SOBRE LA REPLICACIÓN 

La replicación es una técnica que se basa en copiar y mantener objetos de una o mas bases de datos en múltiples ubicaciones  y de esa manera poder tener respaldo de los datos en todo momento.

La replicación es una buena alternativa para tener disponibilidad de información cuando un servidor se cae. La replicación no suplanta los backup’s, sino, simplemente garantiza la operatividad.

SOBRE SLONY-I 

Slony-I es un sistema de replicación asíncrono para PostgreSQL de una base de datos maestra haciamúltiples bases de datos hijas.

CASO PRACTICO DE REPLICACION

A continuación se presenta una descripción general de la demostración practica realizada:
  • Sistema operativo: windows 7
  • base de datos a replicar: 

  • tipo de replicación: maestro/esclavo
  • Herramientas a utilizar: Gestor PostgreSQL 8.4, Pgadmin III, Slony-I


El detalle completo y paso a paso del caso practico de replicación a si como la información de las herramientas utilizadas se muestran en el siguiente documento y video en donde se muestra la implementación de dicha replicación.

Postgre sql y_replicacion_slony_p

Video demostrativo de la implementación del caso practico de replicacion
Parte #1


Parte #2

Documentación


Documentación


La documentación oficial de PostgreSQL es muy completa y actualizada pero está en ingles. Los manuales oficiales son una fuente de información de alta calidad y están siempre actualizados con la última información. Aunque en el pasado han existido iniciativas para traducir el manual, actualmente no existe una traducción al español que este actualizada con todos los cambios que se han producido en los últimos años.
En esta sección teneis información sobre los manuales oficiales en ingles y la FAQ en español.

Manuales oficiales [ENG]

Estos son los manuales oficiales de PostgreSQL desde la versión 7.4 a la 9.2 en version HTML y PDF. Hay que recordar que actualmente solo están soportadas las versiones 8.3, 8.4, 9.0, 9.1 y 9.2. El resto se consideran antiguas.
VersiónVersión HTMLVersión PDF
9.2
9.1
9.0
  • Manual completo: A4 PDF (8 MB)
  • Manual completo: US PDF (8 MB)
8.4
8.3
8.2
  • Manual completo: A4 PDF (14.1 MB)
  • Manual completo: US PDF (14.1 MB)
8.1
  • Manual completo: A4 PDF (12.1 MB)
  • Manual completo: US PDF (12.1 MB)
8.0
  • Manual completo: A4 PDF (9.8 MB)
  • Manual completo: US PDF (9.9 MB)
7.4
  • Manual completo: A4 PDF (9.0 MB)
  • Manual completo: US PDF (9.1 MB)
Si teneis necesidad de consultar la documentación de versiones anteriores a la versión 7.4 de PostgreSQL, os podeis pasar por los archivos oficiales en:http://www.postgresql.org/docs/manuals/archive.html

FAQ (Preguntas frecuentes) en español

Existe una traducción al español de la FAQ oficial. La podeis encontrar en:http://wiki.postgresql.org/wiki/Preguntas_Frecuentes

Primeros pasos


Primeros pasos


Lo necesario para comenzar a utilizar PostgreSQL dependerá mucho de ciertos factores. Estos factores se podrian resumir de la siguiente manera:
  • Experiencia: ¿Tenemos alguna experiencia con otras bases de datos relacionales? ¿Estamos acostumbrados a la terminologia utilizada ó conocemos algo de teoria de bases de datos relacionales?
  • Tipo de uso: ¿Cómo vamos a utilizarla, en sistemas de producción, para desarrollar otros sistemas, para jugar y aprender SQL con ella?
  • Tamaño del sistema: ¿Cual es el tamaño de las bases de datos que quereis administrar, las medis en MB, GB, TB?
  • Carga del sistema: ¿Cuantos usuarios van a utilizar el sistema y que concurrencia podemos esperar?
  • Disponibilidad: ¿Cuales son los requisitos de disponibilidad (uptime) de nuestro sistema?
Como podeis ver, son varios los factores a tener en cuenta para averiguar lo que necesitamos si queremos utilizar PostgreSQL como nuestro sistema de gestion de bases de datos. Dependiendo de nuestra experiencia, el tipo de uso, el tamaño de los datos a gestionar, el numero de usuarios y requisitos de disponibilidad, podremos tardar de solo unos cuantos minutos a varios dias/semanas en instalar un sistema PostgreSQL que cubra nuestras necesidades.
Si simplemente quereis probar y "jugar" un poco con PostgreSQL, existen distribuciones binarias en casi todas las distribuciones de Linux existentes y para sistemas Windows. Con cualquiera de estos paquetes binarios podeis tener una instalación básica y lista para utilizar en cuestión de pocos minutos. Tambien teneis por supuesto el código fuente disponible y listo para ser compilado/instalado, si preferis este tipo de instalación. Pasaros por la sección de descargas para obtener más información sobre los productos disponibles.
Si quereis utilizar PostgreSQL de una manera profesional y con sistemas en producción deberiais planificar vuestro sistema con más detalle y aprender como podeis configurar PostgreSQL para sacarle el máximo provecho. Es importante decir que una de las caracteristicas principales de PostgreSQL es su facilidad de administración comparada con muchos otros sistemas de gestión de bases de datos.
Probablemente tengais muchas preguntas, os aconsejo consultar Sobre PostgreSQL10 razones para utilizar PostgreSQL y la sección de documentación del servidor. Si teneis alguna pregunta podeis utilizar los foros del servidor ó utilizar cualquiera de los servicios disponibles (listas de correos / irc/ etc) en la sección Comunidad / soporte

Sobre PostgreSQL


Sobre PostgreSQL



Introducción
Características
Historia
Ciclo de vida (EOL) y soporte


Introducción


PostgreSQL es un sistema de gestión de bases de datos objeto-relacional, distribuido bajo licencia BSD y con su código fuente disponible libremente. Es el sistema de gestión de bases de datos de código abierto más potente del mercado y en sus últimas versiones no tiene nada que envidiarle a otras bases de datos comerciales.
PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez de multihilospara garantizar la estabilidad del sistema. Un fallo en uno de los procesos no afectará el resto y el sistema continuará funcionando.
A continuación teneis un gráfico que ilustra de manera general los componentes más importantes en un sistema PostgreSQL.
  • Aplicación cliente: Esta es la aplicación cliente que utiliza PostgreSQL como administrador de bases de datos. La conexión puede ocurrir via TCP/IP ó sockets locales.
  • Demonio postmaster: Este es el proceso principal de PostgreSQL. Es el encargado de escuchar por un puerto/socket por conexiones entrantes de clientes. Tambien es el encargado de crear los procesos hijos que se encargaran de autentificar estas peticiones, gestionar las consultas y mandar los resultados a las aplicaciones clientes
  • Ficheros de configuracion: Los 3 ficheros principales de configuración utilizados por PostgreSQL, postgresql.conf, pg_hba.conf y pg_ident.conf
  • Procesos hijos postgres: Procesos hijos que se encargan de autentificar a los clientes, de gestionar las consultas y mandar los resultados a las aplicaciones clientes
  • PostgreSQL share buffer cache: Memoria compartida usada por POstgreSQL para almacenar datos en caché.
  • Write-Ahead Log (WAL): Componente del sistema encargado de asegurar la integridad de los datos (recuperación de tipo REDO)
  • Kernel disk buffer cache: Caché de disco del sistema operativo
  • Disco: Disco físico donde se almacenan los datos y toda la información necesaria para que PostgreSQL funcione

Características


La última serie de producción es la 9.1. Sus características técnicas la hacen una de las bases de datos más potentes y robustas del mercado. Su desarrollo comenzo hace más de 16 años, y durante este tiempo, estabilidad, potencia, robustez, facilidad de administración e implementación de estándares han sido las características que más se han tenido en cuenta durante su desarrollo. PostgreSQL funciona muy bien con grandes cantidades de datos y una alta concurrencia de usuarios accediendo a la vez a el sistema.
A continuación teneis algunas de las características más importantes y soportadas por PostgreSQL:

Generales

  • Es una base de datos 100% ACID
  • Integridad referencial
  • Tablespaces
  • Nested transactions (savepoints)
  • Replicación asincrónica/sincrónica / Streaming replication - Hot Standby
  • Two-phase commit
  • PITR - point in time recovery
  • Copias de seguridad en caliente (Online/hot backups)
  • Unicode
  • Juegos de caracteres internacionales
  • Regionalización por columna
  • Multi-Version Concurrency Control (MVCC)
  • Multiples métodos de autentificación
  • Acceso encriptado via SSL
  • Actualización in-situ integrada (pg_upgrade)
  • SE-postgres
  • Completa documentación
  • Licencia BSD
  • Disponible para Linux y UNIX en todas sus variantes (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64) y Windows 32/64bit.

Programación / Desarrollo

  • Funciones/procedimientos almacenados (stored procedures) en numerosos lenguajes de programacion, entre otros PL/pgSQL (similar al PL/SQL de oracle), PL/Perl, PL/Python y PL/Tcl
  • Bloques anónimos de código de procedimientos (sentencias DO)
  • Numerosos tipos de datos y posibilidad de definir nuevos tipos. Además de los tipos estándares en cualquier base de datos, tenemos disponibles, entre otros, tipos geométricos, de direcciones de red, de cadenas binarias, UUID, XML, matrices, etc
  • Soporta el almacenamiento de objetos binarios grandes (gráficos, videos, sonido, ...)
  • APIs para programar en C/C++, Java, .Net, Perl, Python, Ruby, Tcl, ODBC, PHP, Lisp, Scheme, Qt y muchos otros.

SQL

  • SQL92,SQL99,SQL2003,SQL2008
  • Llaves primarias (primary keys) y foráneas (foreign keys)
  • Check, Unique y Not null constraints
  • Restricciones de unicidad postergables (deferrable constraints)
  • Columnas auto-incrementales
  • Indices compuestos, únicos, parciales y funcionales en cualquiera de los metodos de almacenamiento disponibles, B-tree, R-tree, hash ó GiST
  • Sub-selects
  • Consultas recursivas
  • Funciones 'Windows'
  • Joins
  • Vistas (views)
  • Disparadores (triggers) comunes, por columna, condicionales.
  • Reglas (Rules)
  • Herencia de tablas (Inheritance)
  • Eventos LISTEN/NOTIFY
Podeis consultar la lista completa en ingles de características disponibles en todas las versiones en la dirección http://www.postgresql.org/about/featurematrix
Algunos de los limites de PostgreSQL son:
LímiteValor
Máximo tamaño base de datoIlimitado (Depende de tu sistema de almacenamiento)
Máximo tamaño de tabla32 TB
Máximo tamaño de fila1.6 TB
Máximo tamaño de campo1 GB
Máximo numero de filas por tablaIlimitado
Máximo numero de columnas por tabla250 - 1600 (dependiendo del tipo)
Máximo numero de indices por tablaIlimitado

Historia


El proyecto PostgreSQL tal y como lo conocemos hoy en dia empezó en 1996, aunque las bases y el trabajo en la que se asienta tienen sus comienzos en la decada de los 70. A continuación teneis una corta descripción de la historia de PostgreSQL.

Ingres 1977-1985 - "El comienzo"

La década de los 70 fue una década de desarrollos y pruebas de nuevos conceptos en el nuevo mundo de los gestores de bases de datos.
IBM habia estado trabajando desde 1973 con los primeros conceptos, ideas y teorias sobre bases de datos relacionales. Su proyecto "System R" fue entre otras cosas la primera implementación del lenguaje SQL (Structured Query Language). Este proyecto, sus decisiones de diseño y muchos de los algoritmos usados, influenciaron muchos de los sistemas de bases de datos relacionales que aparecieron posteriormente.
Por aquel entonces un profesor de la Universidad de Berkeley, Michael Stonebraker, leyo unos artículos publicados por IBM sobre "System R" que le hicieron interesarse en el tema. Utilizando el dinero de otro proyecto que ya tenia asignado, Ingres (INteractive Graphics REtrieval System), Stonebraker empezo a desarrollar sus ideas sobre bases de datos relacionales. Durante estos años Ingres mantuvo su código fuente abierto y permanecio en gran medida similar en conceptos a "System R".
A principio de los 80, Ingres estuvo compitiendo con Oracle por el liderazgo en el mundo de bases de datos relacionales y su código e implementación evolucionaron y fueron el origen de otras bases de datos relacionales, entre ellas podemos citar a Informix, NonStop SQL y Sybase (Microsoft SQL Server fue una versión licenciada de Sybase hasta su version 6.0).
Michael Stonebraker dejo la Universidad de Berkeley en 1982 para comercializar Ingres pero volvio a la misma en 1985 con nuevas ideas.

Postgres 1986-1994 - Despues (post) de ingres

Despues de su vuelta a Berkeley en 1985, Michael Stonebraker lideró un nuevo proyecto llamado Postgres (despues de Ingres) patrocinado por la Defense Advanced Research Projects Agency (DARPA), la Army Research Office (ARO), la National Science Foundation (NSF), y ESL, Inc. Con este proyecto y basandose en la experiencia obtenida con Ingres, Stonebraker tenia como meta mejorar lo que habian conseguido y aprendido en el desarrollo de Ingres. Y aunque se baso en muchas ideas de Ingres, no se baso en el código fuente del mismo.
Los objetivos iniciales de este proyecto fueron:
  • Proporcionar un mejor soporte para objetos complejos
  • Proporcionar a los usuarios la posibilidad de extender los tipos de datos, operadores y métodos de acceso.
  • Proporcionar los mecanismos necesarios para crear bases de datos activas (triggers, etc)
  • Simplificar el código encargado de la recuperación del sistema despues de una caída del mismo
  • Hacer cambios mínimos (preferiblemente ninguno) en el modelo relacional.
  • Mejorar el lenguaje de consulta QUEL heredado de Ingres (POSTQUEL).
Para los interesados en el tema, teneis disponibles una serie de artículos originales y completos en ingles relacionados con el proyecto Postgres:
  • "The design of POSTGRES": El diseño de Postgres
  • "The POSTGRES data model": El módelo de datos de Postgres
  • "The design of the POSTGRES storage system": El diseño del sistema de almacenamiento de Postgres
  • "The implementation of POSTGRES": Presentación de la versión 1 de Postgres en la conferencia ACM-SIGMOD de 1988
  • "A commentary on the POSTGRES rules system": Comentarios sobre el sistema de reglas de Postgres
  • "On Rules, Procedures, Caching and Views in Database Systems": Sobre reglas, procedimientos, cache y vistas en sistemas de bases de datos
La última versión de Postgres en este projecto fue la versión 4.2.

Postgres95 1994-1995 - Nueva vida en el mundo opensource

En 1994, dos estudiantes de Berkeley, Andrew Yu y Jolly Chen, empezaron a trabajar con el código de Postgres (versión 4.2) y llamaron al proyecto Postgres95. Hicieron una limpieza general del código, arreglaron errores en el mismo, e implementaron otras mejoras, entre las que destacan:
  • Sustitución de POSTQUEL por un interprete del lenguaje SQL
  • Reimplementación de las funciones agregadas
  • psql fue creado para ejecutar consultas SQL
  • El interface de objetos grandes (large-object) fue revisado
  • Un pequeño tutorial sobre Postgres fue creado
  • Postgres se pudo empezar a compilar con GNU make y GCC sin parchear
La versión 1.0 de Postgre95 vio la luz en 1995, el código era 100% ANSI C, un 25% más corto en relación con la versión 4.2 y un 30-50% más rápido. El código fue publicado en la web y liberado bajo una licencia BSD, y más y más personas empezaron a utilizar y a colaborar en el proyecto.

PostgreSQL 1996-actualidad - Proyecto PostgreSQL

En 1996, Andrew Yu y Jolly Chen ya no tenian tanto tiempo para dirigir y desarrollar Postgres95. Algunos de los usuarios habituales de las listas de correo del proyecto decidieron hacerse cargo del mismo y crearon el llamado "PostgreSQL Global Development Team".
En un principio este equipo de desarrolladores al cargo de la organización del proyecto estuvo formado por Marc Fournier en Ontario, Canada, Thomas Lockhart en Pasadena, California, Vadim Mikheev en Krasnoyarsk, Rusia y Bruce Momjian in Philadelphia, Pennsylvania. El nombre fue cambiado de Postgres95 a PostgreSQL y lanzaron la versión 6.0 en enero de 1997.
Hoy en dia el grupo central (core team) de desarrolladores está formado por 6 personas, existen 38 desarrolladores principales y más 21 desarrolladores habituales. En total alrededor de 65 personas activas, contribuyendo con el desarrollo de PostgreSQL. Podeis encontrar más información sobre este equipo de desarrolladores enhttp://www.postgresql.org/community/contributors/
Existe tambien una gran comunidad de usuarios, programadores y administradores que colaboran actívamente en numerosos aspectos y actividades relacionadas con el proyecto. Informes y soluciones de problemas, tests, comprobación del funcionamiento, aportaciones de nuevas ideas, discusiones sobre características y problemas, documentación y fomento de PostgreSQL son solo algunas de las actividades que la comunidad de usuarios realiza.
No tenemos que olvidar tampoco que existen muchas empresas que tambien colaboran con dinero y/ó con tiempo/personas en mejorar PostgreSQL. Muchos desarrolladores y nuevas características están muchas veces patrocinadas por empresas privadas.
En los últimos años los trabajos de desarrollo se han concentrado mucho en la velocidad de proceso y en características demandadas en el mundo empresarial. En este gráfico podeis ver cuando las diferentes versiones de PostgreSQL han visto la luz y las principales caracteristicas en las que se ha centrado el desarrollo.
Durante los años de existencia del Proyecto PostgreSQL, el tamaño del mismo, tanto en número de desarrolladores, como en números de linea de código, funciones y complejidad del mismo ha ido aumentando año a año. En el siguiente gráfico teneis una gráfica con la evolución del número de lineas de código en cada versión de PostgreSQL.
Los datos de este gráfico estan generados con CLOC. Contabilizamos como lineas de código a todas las lineas de código en diferentes lenguaje, más comentarios, menos lineas en blanco. Los ficheros HTML y CSS no se cuentan como código.
Usando el modelo de estimación de costes de software "COCOMOII" (Constructive COst MOdel) podemos obtener unos datos meramente orientativos pero que nos pueden ayudar a entender la complejidad del proyecto PostgreSQL y los recursos que se necesitarian para desarrollar un producto similar desde cero.
Según COCOMOII, obtendriamos estos números para PostgreSQL 9.0.0:
DescripciónValor
Números de lineas de código (PG-9.0.0)969.562
Habilidad de los programadores (alta)0,6
Complejidad del projecto (alta)1,24
Precio/hora ($100.000/año - 1.875horas/año)$53,3
Programadores-año618,71
Precio por linea de código$65,30
Precio Total$63.316.697
Lineas de código por persona/dia7
Tiempo de desarrollo del proyecto (años)3.6
Número medio de programadores171,4

Ciclo de vida (EOL) y soporte


El Proyecto PostgreSQL tiene como objetivo mantener y soportar cada versión de PostgreSQL durante 5 años desde el momento de su lanzamiento. A continuación teneis un resumen del ciclo de vida de las diferentes versiones de PostgreSQL:
VersiónVersión menorSoportadaLanzamientoSoporte
9.29.2.0SiSep 2012Sep 2017
9.19.1.5SiSep 2011Sep 2016
9.09.0.9SiSep 2010Sep 2015
8.48.4.13SiJul 2009Jul 2014
8.38.3.20SiFeb 2008Feb 2013
8.28.2.23NoDic 2006Dic 2011
8.18.1.23NoNov 2005Nov 2010
8.08.0.26NoEne 2005Oct 2010
7.47.4.30NoNov 2003Oct 2010
7.37.3.21NoNov 2002Nov 2007
7.27.2.8NoFeb 2002Feb 2007
7.17.1.3NoAbr 2001Abr 2006
7.07.0.3NoMay 2000May 2005
6.56.5.3NoJun 1999Jun 2004
6.46.4.2NoOct 1998Oct 2003
6.36.3.2NoMar 1998Mar 2003

jueves, 29 de noviembre de 2012

Acerca de

Soy Luis Eduardo Arocha Coronado, Tecnólogo en Sistemas, amante de las tecnologías (TIC's), Redes y seguridad, Certified Ethical Hacker - CEH, Computer Hacking Forensic Investigator - CHFI, ISO 27000 Sistemas de Gestión de la Seguridad de la Información.

¿QUÉ SON LAS BASES DE DATOS?


¿QUÉ SON LAS BASES DE DATOS?

Una base de datos es un “almacén” que nos permite guardar grandes cantidades de información de forma organizada para que luego podamos encontrar y utilizar fácilmente. A continuación te presentamos una guía que te explicará el concepto y características de las bases de datos.
El término de bases de datos fue escuchado por primera vez en 1963, en un simposio celebrado en California, USA. Una base de datos se puede definir como un conjunto de información relacionada que se encuentra agrupada ó estructurada.
Desde el punto de vista informático, la base de datos es un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un conjunto de programas que manipulen ese conjunto de datos.
Cada base de datos se compone de una o más tablas que guarda un conjunto de datos. Cada tabla tiene una o más columnas y filas. Las columnas guardan una parte de la información sobre cada elemento que queramos guardar en la tabla, cada fila de la tabla conforma un registro.
Existen programas denominados sistemas gestores de bases de datos, abreviado SGBD, que permiten almacenar y posteriormente acceder a los datos de forma rápida y estructurada. Las propiedades de estos SGBD, así como su utilización y administración, se estudian dentro del ámbito de la informática.



DEFINICIÓN DE BASE DE DATOS



Se define una base de datos como una serie de datos organizados y relacionados entre sí, los cuales son recolectados y explotados por los sistemas de información de una empresa o negocio en particular.



CARACTERÍSTICAS



Entre las principales características de los sistemas de base de datos podemos mencionar:


  • Independencia lógica y física de los datos.
  • Redundancia mínima.
  • Acceso concurrente por parte de múltiples usuarios.
  • Integridad de los datos.
  • Consultas complejas optimizadas.
  • Seguridad de acceso y auditoría.
  • Respaldo y recuperación.
  • Acceso a través de lenguajes de programación estándar.



SISTEMA DE GESTIÓN DE BASE DE DATOS (SGBD)



Los Sistemas de Gestión de Base de Datos (en inglés DataBase Management System) son un tipo de software muy específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. Se compone de un lenguaje de definición de datos, de un lenguaje de manipulación de datos y de un lenguaje de consulta.


VENTAJAS DE LAS BASES DE DATOS



CONTROL SOBRE LA REDUNDANCIA DE DATOS: Los sistemas de ficheros almacenan varias copias de los mismos datos en ficheros distintos. Esto hace que se desperdicie espacio de almacenamiento, además de provocar la falta de consistencia de datos.

En los sistemas de bases de datos todos estos ficheros están integrados, por lo que no se almacenan varias copias de los mismos datos. Sin embargo, en una base de datos no se puede eliminar la redundancia completamente, ya que en ocasiones es necesaria para modelar las relaciones entre los datos.


CONSISTENCIA DE DATOS: 
Eliminando o controlando las redundancias de datos se reduce en gran medida el riesgo de que haya inconsistencias. Si un dato está almacenado una sola vez, cualquier actualización se debe realizar sólo una vez, y está disponible para todos los usuarios inmediatamente. Si un dato está duplicado y el sistema conoce esta redundancia, el propio sistema puede encargarse de garantizar que todas las copias se mantienen consistentes.

COMPARTICIÓN DE DATOS: 
En los sistemas de ficheros, los ficheros pertenecen a las personas o a los departamentos que los utilizan. Pero en los sistemas de bases de datos, la base de datos pertenece a la empresa y puede ser compartida por todos los usuarios que estén autorizados.

MANTENIMIENTO DE ESTÁNDARES: 
Gracias a la integración es más fácil respetar los estándares necesarios, tanto los establecidos a nivel de la empresa como los nacionales e internacionales. Estos estándares pueden establecerse sobre el formato de los datos para facilitar su intercambio, pueden ser estándares de documentación, procedimientos de actualización y también reglas de acceso.

MEJORA EN LA INTEGRIDAD DE DATOS: 
La integridad de la base de datos se refiere a la validez y la consistencia de los datos almacenados. Normalmente, la integridad se expresa mediante restricciones o reglas que no se pueden violar. Estas restricciones se pueden aplicar tanto a los datos, como a sus relaciones, y es el SGBD quien se debe encargar de mantenerlas.

MEJORA EN LA SEGURIDAD: 
La seguridad de la base de datos es la protección de la base de datos frente a usuarios no autorizados. Sin unas buenas medidas de seguridad, la integración de datos en los sistemas de bases de datos hace que éstos sean más vulnerables que en los sistemas de ficheros.

MEJORA EN LA ACCESIBILIDAD A LOS DATOS: 
Muchos SGBD proporcionan lenguajes de consultas o generadores de informes que permiten al usuario hacer cualquier tipo de consulta sobre los datos, sin que sea necesario que un programador escriba una aplicación que realice tal tarea.

MEJORA EN LA PRODUCTIVIDAD: 
El SGBD proporciona muchas de las funciones estándar que el programador necesita escribir en un sistema de ficheros. A nivel básico, el SGBD proporciona todas las rutinas de manejo de ficheros típicas de los programas de aplicación.

El hecho de disponer de estas funciones permite al programador centrarse mejor en la función específica requerida por los usuarios, sin tener que preocuparse de los detalles de implementación de bajo nivel.


MEJORA EN EL MANTENIMIENTO
En los sistemas de ficheros, las descripciones de los datos se encuentran inmersas en los programas de aplicación que los manejan.

Esto hace que los programas sean dependientes de los datos, de modo que un cambio en su estructura, o un cambio en el modo en que se almacena en disco, requiere cambios importantes en los programas cuyos datos se ven afectados.


Sin embargo, los SGBD separan las descripciones de los datos de las aplicaciones. Esto es lo que se conoce como independencia de datos, gracias a la cual se simplifica el mantenimiento de las aplicaciones que acceden a la base de datos.


AUMENTO DE LA CONCURRENCIA: 
En algunos sistemas de ficheros, si hay varios usuarios que pueden acceder simultáneamente a un mismo fichero, es posible que el acceso interfiera entre ellos de modo que se pierda información o se pierda la integridad. La mayoría de los SGBD gestionan el acceso concurrente a la base de datos y garantizan que no ocurran problemas de este tipo.

MEJORA EN LOS SERVICIOS DE COPIAS DE SEGURIDAD: 
Muchos sistemas de ficheros dejan que sea el usuario quien proporcione las medidas necesarias para proteger los datos ante fallos en el sistema o en las aplicaciones. Los usuarios tienen que hacer copias de seguridad cada día, y si se produce algún fallo, utilizar estas copias para restaurarlos.

En este caso, todo el trabajo realizado sobre los datos desde que se hizo la última copia de seguridad se pierde y se tiene que volver a realizar. Sin embargo, los SGBD actuales funcionan de modo que se minimiza la cantidad de trabajo perdido cuando se produce un fallo.



DESVENTAJAS DE LAS BASES DE DATOS




  • COMPLEJIDAD: Los SGBD son conjuntos de programas que pueden llegar a ser complejos con una gran funcionalidad. Es preciso comprender muy bien esta funcionalidad para poder realizar un buen uso de ellos.
  • COSTE DEL EQUIPAMIENTO ADICIONAL: Tanto el SGBD, como la propia base de datos, pueden hacer que sea necesario adquirir más espacio de almacenamiento. Además, para alcanzar las prestaciones deseadas, es posible que sea necesario adquirir una máquina más grande o una máquina que se dedique solamente al SGBD. Todo esto hará que la implantación de un sistema de bases de datos sea más cara.
  • VULNERABLE A LOS FALLOS: El hecho de que todo esté centralizado en el SGBD hace que el sistema sea más vulnerable ante los fallos que puedan producirse. Es por ello que deben tenerse copias de seguridad (Backup).



TIPOS DE CAMPOS



Cada Sistema de Base de Datos posee tipos de campos que pueden ser similares o diferentes. Entre los más comunes podemos nombrar:


  • Numérico: entre los diferentes tipos de campos numéricos podemos encontrar enteros “sin decimales” y reales “decimales”.
  • Booleanos: poseen dos estados: Verdadero “Si” y Falso “No”.
  • Memos: son campos alfanuméricos de longitud ilimitada. Presentan el inconveniente de no poder ser indexados.
  • Fechas: almacenan fechas facilitando posteriormente su explotación. Almacenar fechas de esta forma posibilita ordenar los registros por fechas o calcular los días entre una fecha y otra.
  • Alfanuméricos: contienen cifras y letras. Presentan una longitud limitada (255 caracteres).
  • Autoincrementables: son campos numéricos enteros que incrementan en una unidad su valor para cada registro incorporado. Su utilidad resulta: Servir de identificador ya que resultan exclusivos de un registro.



TIPOS DE BASE DE DATOS



Entre los diferentes tipos de base de datos, podemos encontrar los siguientes:


  • MySql: es una base de datos con licencia GPL basada en un servidor. Se caracteriza por su rapidez. No es recomendable usar para grandes volúmenes de datos.
  • PostgreSql y Oracle: Son sistemas de base de datos poderosos. Administra muy bien grandes cantidades de datos, y suelen ser utilizadas en intranets y sistemas de gran calibre.
  • Access: Es una base de datos desarrollada por Microsoft. Esta base de datos, debe ser creada bajo el programa access, el cual crea un archivo .mdb con la estructura ya explicada.
  • Microsoft SQL Server: es una base de datos más potente que access desarrollada por Microsoft. Se utiliza para manejar grandes volúmenes de informaciones.


MODELO ENTIDAD-RELACIÓN



Los diagramas o modelos entidad-relación (denominado por su siglas, ERD “Diagram Entity relationship”) son una herramienta para el modelado de datos de un sistema de información. Estos modelos expresan entidades relevantes para un sistema de información, sus inter-relaciones y propiedades.





CARDINALIDAD DE LAS RELACIONES



El diseño de relaciones entre las tablas de una base de datos puede ser la siguiente:


  • Relaciones de uno a uno: una instancia de la entidad A se relaciona con una y solamente una de la entidad B.
  • Relaciones de uno a muchos: cada instancia de la entidad A se relaciona con varias instancias de la entidad B.
  • Relaciones de muchos a muchos: cualquier instancia de la entidad A se relaciona con cualquier instancia de la entidad B.


ESTRUCTURA DE UNA BASE DE DATOS



Una base de datos, a fin de ordenar la información de manera lógica, posee un orden que debe ser cumplido para acceder a la información de manera coherente. Cada base de datos contiene una o más tablas, que cumplen la función de contener los campos.

En el siguiente ejemplo mostramos una tabla “comentarios” que contiene 4 campos.





Los datos quedarían organizados como mostramos en siguiente ejemplo:





Por consiguiente una base de datos posee el siguiente orden jerárquico:



  • Tablas
  • Campos
  • Registros
  • Lenguaje SQL
El lenguaje SQL es el más universal en los sistemas de base de datos. Este lenguaje nos permite realizar consultas a nuestras bases de datos para mostrar, insertar, actualizar y borrar datos.

A continuación veremos un ejemplo de ellos:



  • Mostrar: para mostrar los registros se utiliza la instrucción Select. Select * From comentarios.
  • Insertar: los registros pueden ser introducidos a partir de sentencias que emplean la instrucción Insert. Insert Into comentarios (titulo, texto, fecha) Values ('saludos', 'como esta', '22-10-2007')
  • Borrar: Para borrar un registro se utiliza la instrucción Delete. En este caso debemos especificar cual o cuales son los registros que queremos borrar. Es por ello necesario establecer una selección que se llevara a cabo mediante la cláusula Where. Delete From comentarios Where id='1'.

Twitter Delicious Facebook Digg Stumbleupon Favorites More

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Affiliate Network Reviews