MARCO TEORICO

HISTORIA DE LAS BASES DE DATOS

“El término bases de datos fue escuchado por primera vez en un simposio

celebrado en California en 1963.

En una primera aproximación, se puede decir que una base de datos es un

conjunto de información relacionada que se encuentra agrupada o estructurada.

Desde el punto de vista informático, una 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.

Por su parte, un sistema de Gestión de Bases de datos es 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; o lo que es lo mismo, una agrupación de

programas que sirven para definir, construir y manipular una base de datos,

permitiendo así almacenar y posteriormente acceder a los datos de forma rápida

y estructurada.

Actualmente, las bases de datos están teniendo un impacto decisivo sobre el

creciente uso de las computadoras.

Pero para poder entender más profundamente una base de datos cabe entender

su historia.

ORÍGENES Y EVOLUCIÓ

Los orígenes de las bases de datos se remontan a la Antigüedad donde ya

existían bibliotecas y toda clase de registros. Además, también se utilizaban para

recoger información sobre las cosechas y censos. Sin embargo, su búsqueda

era lenta y poco eficaz y no se contaba con la ayuda de máquinas que pudiesen

reemplazar el trabajo manual.

Posteriormente, el uso de las bases de datos se desarrolló a partir de las

necesidades de almacenar grandes cantidades de información o datos. Sobre

todo, desde la aparición de las primeras computadoras, el concepto de bases de

datos ha estado siempre ligado a la informática.

En 1884 Herman Hollerith creó la máquina automática de tarjetas perforadas,

siendo nombrado así el primer ingeniero estadístico de la historia. En esta época,

los censos se realizaban de forma manual.

Ante esta situación, Hollerith comenzó a trabajar en el diseño de una maquina

tabuladora o censadora, basada en tarjetas perforadas.

Posteriormente, en la década de los cincuenta se da origen a las cintas

magnéticas, para automatizar la información y hacer respaldos. Esto sirvió para

suplir las necesidades de información de las nuevas industrias. Y a través de

este mecanismo se empezaron a automatizar información, con la desventaja de

que solo se podía hacer de forma secuencial.

DÉCADA DE 1960

Posteriormente en la época de los sesenta, las computadoras bajaron los precios

para que las compañías privadas las pudiesen adquirir; dando paso a que se

popularizara el uso de los discos, cosa que fue un adelanto muy efectivo en la

época, debido a que a partir de este soporte se podía consultar la información

directamente, sin tener que saber la ubicación exacta de los datos.

En esta misma época se dio inicio a las primeras generaciones de bases de

datos de red y las bases de datos jerárquicas, ya que era posible guardar

estructuras de datos en listas y árboles.

Otro de los principales logros de los años sesenta fue la alianza de IBM y

American Airlines para desarrollar SABRE, un sistema operativo que manejaba

las reservas de vuelos, transacciones e informaciones sobre los pasajeros de la

compañía American Airlines.

Y, posteriormente, en esta misma década, se llevó a cabo el desarrollo del IDS

desarrollado por Charles Bachman (que formaba parte de la CODASYL) supuso

la creación de un nuevo tipo de sistema de bases de datos conocido como

modelo en red que permitió la creación de un standard en los sistemas de bases

de datos gracias a la creación de nuevos lenguajes de sistemas de información.

CODASYL (Conference on Data Systems Languages) era un consorcio de

industrias informáticas que tenían como objetivo la regularización de un lenguaje

de programación estándar que pudiera ser utilizado en multitud de ordenadores.

Los miembros de este consorcio pertenecían a industrias e instituciones

gubernamentales relacionadas con el proceso de datos, cuya principal meta era

promover un análisis, diseño e implementación de los sistemas de datos más

efectivos; y aunque trabajaron en varios lenguajes de programación como

COBOL, nunca llegaron a establecer un estándar fijo, proceso que se llevó a

cabo por ANSI.

DÉCADA DE 1970

Por lo que respecta a la década de los setenta, Edgar Frank Codd, científico

informático ingles conocido por sus aportaciones a la teoría de bases de datos

relacionales, definió el modelo relacional a la par que publicó una serie de reglas

para los sistemas de datos relacionales a través de su artículo “Un modelo

relacional de datos para grandes bancos de datos compartidos.

Este hecho dio paso al nacimiento de la segunda generación de los Sistemas

Gestores de Bases de Datos.

Como consecuencia de esto, durante la década de 1970, Lawrence J. Ellison,

más conocido como Larry Ellison, a partir del trabajo de Edgar F. Codd sobre los

sistemas de bases de datos relacionales, desarrolló el Relational Software

System, o lo que es lo mismo, lo que actualmente se conoce como Oracle

Corporación, desarrollando así un sistema de gestión de bases de datos

relacional con el mismo nombre que dicha compañía.

Posteriormente en la época de los ochenta también se desarrollará el SQL

(Structured Query Language) o lo que es lo mismo un lenguaje de consultas o

lenguaje declarativo de acceso a bases de datos relacionales que permite

efectuar consultas con el fin de recuperar información de interés de una base de

datos y hacer cambios sobre la base de datos de forma sencilla; además de

analiza grandes cantidades de información y permitir especificar diversos tipos

de operaciones frente a la misma información, a diferencia de las bases de datos

de los años ochenta que se diseñaron para aplicaciones de procesamiento de

transacciones.

Pero cabe destacar que ORACLE es considerado como uno de los sistemas de

bases de datos más completos que existen en el mundo, y aunque su dominio

en el mercado de servidores empresariales ha sido casi total hasta hace

relativamente poco, actualmente sufre la competencia del SQL Server de la

compañía Microsoft y de la oferta de otros Sistemas Administradores de Bases

de Datos Relacionales con licencia libre como es el caso de PostgreSQL, MySQL

o Firebird que aparecerían posteriormente en la década de 1990.

DÉCADA DE 1980

Por su parte, a principios de los años ochenta comenzó el auge de la

comercialización de los sistemas relacionales, y SQL comenzó a ser el estándar

de la industria, ya que las bases de datos relacionales con su sistema de tablas

(compuesta por filas y columnas) pudieron competir con las bases jerárquicas y

de red, como consecuencia de que su nivel de programación era sencillo y su

nivel de programación era relativamente bajo.

DÉCADA AÑOS 1990

En la década de 1990 la investigación en bases de datos giró en torno a las

bases de datos orientadas a objetos. Las cuales han tenido bastante éxito a la

hora de gestionar datos complejos en los campos donde las bases de datos

relacionales no han podido desarrollarse de forma eficiente. Así se desarrollaron

herramientas como Excel y Access del paquete de Microsoft Office que marcan

el inicio de las bases de datos orientadas a objetos.

Así se creó la tercera generación de sistemas gestores de bases de datos.

Fue también en esta época cuando se empezó a modificar la primera publicación

hecha por ANSI del lenguaje SQL y se empezó a agregar nuevas expresiones
regulares, consultas recursivas, triggers y algunas características orientadas a

objetos, que posteriormente en el siglo XXI volverá a sufrir modificaciones

introduciendo características de XML, cambios en sus funciones,

estandarización del objeto sequence y de las columnas autonuméricas. Y,

además, se creará la posibilidad de que SQL se pueda utilizar conjuntamente

con XML, y se definirá las maneras de cómo importar y guardar datos XML en

una base de datos SQL. Dando así, la posibilidad de proporcionar facilidades

que permiten a las aplicaciones integrar el uso de XQuery (lenguaje de consulta

XML) para acceso concurrente a datos ordinarios SQL y documentos XML. Y

posteriormente, se dará la posibilidad de usar la cláusula orden by.

Aunque el boom de la década de los noventa será es el nacimiento del Word

Wide Web a finales de la década, ya que a través de este se facilitará la consulta

a bases de datos.

SIGLO XXI

En la actualidad, las tres grandes compañías que dominan el mercado de las

bases de datos son IBM, Microsoft y Oracle. Por su parte, en el campo de

internet, la compañía que genera gran cantidad de información es Google.

Aunque existe una gran variedad de software que permiten crear y manejar

bases de datos con gran facilidad, como por ejemplo LINQ, que es un proyecto
de Microsoft que agrega consultas nativas semejantes a las de SQL a los

lenguajes de la plataforma .NET. El objetivo de este proyecto es permitir que

todo el código hecho en Visual Studio sea también orientado a objetos; ya que

antes de LINQ la manipulación de datos externos tenía un concepto más

estructurado que orientado a objetos; y es por eso que trata de facilitar y

estandarizar el acceso a dichos objetos.

Cabe destacar que Visual Studio es un entorno de desarrollo integrado para

sistemas operativos Windows que soporta varios lenguajes de programación

tales como Visual C++, Visual#, Visual J#, ASP.NET y Visual Basic.NET, aunque

se están desarrollando las extensiones necesarias para otros, cuyo objetivo es

permitir crear aplicaciones, sitios y aplicaciones web, así como servicios web a

cualquier entorno que soporte la plataforma .Net, creando así aplicaciones que

intercomuniquen entre estaciones de trabajo, páginas web y dispositivos

móviles”.

http://histinf.blogs.upv.es/2011/01/04/historia-de-las-bases-de-datos/
 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.

 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.

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.

Compartir 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).

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”.

http://www.maestrosdelweb.com/que-son-las-bases-de-datos/

PARTES DE LA BASE DE DATOS

TABLAS

“Una tabla de base de datos es parecida a una hoja de cálculo debido a que los

datos son almacenados en un formato de columnas y filas. Por lo tanto, es

sumamente fácil llevar una hoja de cálculo a una tabla de base de datos. La

diferencia principal entre almacenar la información en una hoja de cálculo y en

guardarla en una base de datos es la manera en la que esos datos estarán

organizados. Cada fila de una tabla es conocida con el nombre de registro, en

esta parte la información es almacenada. Cada registro está compuesto por uno

o más de un campo, los campos son las columnas que tiene la tabla. A esto se
les designa un tipo de datos determinado el cual puede ser fecha u hora, texto,

número o cualquier otro tipo de información.

FORMULARIOS

Los formularios posibilitan la creación de una interfaz de usuario en la cual los

datos pueden ser modificados y redactados. Normalmente los formularios están

compuestos por botones de comando y otros controles que permiten la

realización de diferentes tareas.

Una base de datos puede ser creada sin utilizar los formularios, sólo es necesario

modificar los datos que están en las hojas de datos de la tabla. Aunque la gran

mayoría de los usuarios de bases de datos escogen utilizar los formularios para

escribir, modificar y visualizar la información en las tablas. Es posible programar

botones de comando para definir cuales informaciones aparecerán en el

formulario, llevar a cabo diferentes tareas y abrir otros informes o formularios.

INFORMES

Los informes se utilizan para establecer un formato a las informaciones, poder

resumirlas para luego finalmente presentarlas. Es posible otorgarle un formato a

cada informe con la finalidad de que la información sea presentada de la forma

más legible posible. Se puede llevar a cabo un informe a la vez y que los datos

actuales de la base de datos estén siempre reflejados en el mismo. Normalmente

a los informes se les proporciona un formato para cuando se impriman, sin

embargo, también los informes se pueden visualizar en una pantalla, pueden

exportarse a otro programa distinto o enviarse como datos adjuntos a través del

correo electrónico.
CONSULTAS

Las consultas pueden llevar a cabo funciones diversas dentro de una base de

datos. Una de sus funciones más comunes es recuperar datos específicos

importantes de las tablas. Los datos que normalmente se desea visualizar se

encuentran distribuidos en distintas tablas y las consultas tienen la función de

otorgar visualización de estas informaciones en una sola hoja de datos. También,

a causa de que la mayoría de las ocasiones no se necesita la visualización de

todos los registros al mismo tiempo, las consultas permiten el poder añadir

criterios con el propósito de filtrar las informaciones y conseguir únicamente los

registros deseados. Algunas consultas se pueden actualizar, esto quiere decir

que el dato de las tablas subyacentes se puede modificar a través de la hoja de

datos de la consulta. Si se trabaja en una consulta actualizable, los cambios se

efectuarán en las tablas y no únicamente en la hoja de datos de la consulta”.

https://www.partesdel.com/partes_de_la_base_de_datos.html

SISTEMAS GESTORES DE BASES DE DATOS

“Junto con las bases de datos, el elemento fundamental para el

aprovechamiento de estas son los Sistemas Gestores de Bases de

Datos (SGDB o DBMS, del inglés Data Base Management System). Estos

sistemas representan un elemento intermedio entre los propios datos y los

programas que van a hacer uso de ellos, facilitando las operaciones a realizar

sobre aquellos. En nuestro caso, son el componente que permite unir el SIG con

la base de datos en la que se almacenan los datos espaciales con los que este

va a trabajar.
Un SGBD es una pieza de software compleja, ya que las situaciones a las que

debe responder son diversas y en muchas ocasiones con requerimientos

elevados, por ejemplo, en lo que a eficiencia y volumen de datos respecta.

Piénsese que una base de datos actual puede tener millones de registros y ser

utilizada simultáneamente por miles de usuarios, que a su vez pueden utilizar

diversos programas, no todos ellos del mismo tipo. Por ejemplo, una base de

datos que contenga números de teléfono, nombres de usuarios, direcciones y

coordenadas asociadas a cada línea telefónica, puede ser empleada desde un

SIG para crear un mapa que muestre la densidad de usuarios o también desde

una aplicación que genere un listín telefónico, o bien desde una aplicación en

una página Web que permita localizar el número de teléfono de una persona

concreta. Cada una de estas aplicaciones realiza un trabajo distinto, pero todas

ellas utilizan la misma base de datos. El SGBD debe proporcionar a todos ellos

la metodología adecuada para extraer del conjunto de datos completo cuanto

sea necesario en cada caso.

Además, el SGBD es la herramienta utilizada no solo por quienes aprovechan

los datos, sino también por aquellos que se han de encargar de la propia gestión

y mantenimiento de la base de datos. Administrar una base de datos puede

suponer una tarea altamente compleja, por lo que el SGBD debe proveer los

útiles necesarios para llevar a cabo ese mantenimiento.

Para ser de verdadera utilidad y responder a todas las necesidades que pueden

plantearse en relación con la base de datos, un SGBD debe perseguir los

siguientes objetivos:

Acceso transparente a los datos: La base de datos ha de poder accederse de

forma transparente, sin que sea necesario para el usuario del SGBD preocuparse
por aspectos internos relativos a la estructura de esta u otras características.

Esto significa que, por ejemplo, si queremos recuperar un registro de la base de

datos, debemos poder hacerlo sin necesidad de saber si dicha base de datos

está almacenada en un único archivo o varios, o si el registro que pretendemos

recuperar está almacenado a su vez de uno u otro modo. Así, el SGBD debe

crear una abstracción de los datos que haga el trabajo con estos más sencillo,

ocultando aspectos que no sean relevantes para dicho trabajo. Procedimientos

como las consultas que veremos en el capítulo Consultas se realizan a través

del SGBD, que es quien se encarga de interpretar dichas consultas, aplicarlas

sobre la base de datos y devolver el resultado correspondiente. El SIG no accede

a los datos, sino que se comunica con el SGBD y deja en manos de este el

proceso de consulta en sí.

Protección de los datos: Si la base de datos almacena información sensible, el

SGBD debe controlar el acceso a esta, restringiendo el acceso cuando

corresponda (por ejemplo, estableciendo distintos permisos de acceso para

distintos tipos de usuarios) e implementando los mecanismos de protección

necesarios.

Eficiencia: Acceder a los datos no es suficiente en la mayoría de los casos, sino

que se requiere un acceso eficiente. El SGBD debe ser capaz de gestionar de

forma fluida grandes volúmenes de datos o de operaciones (por ejemplo, muchos

usuarios accediendo simultáneamente), de modo que dé una respuesta rápida a

las peticiones de los usuarios de la base de datos.

Gestión de transacciones: Las operaciones sobre la base de datos tales como

la adición o borrado de un registro se realizan mediante transacciones. Una

transacción es un conjunto de operaciones realizadas por un usuario sobre la

base de datos como una única unidad de trabajo, de forma indivisible. El SGBD

ha de encargarse de gestionarlas de manera eficiente y segura para que todos

los usuarios de la base de datos puedan hacer su trabajo de forma transparente.

Aspectos como el acceso concurrente a la base de datos (varias transacciones

simultaneas) resultan especialmente importantes, y en su buena gestión se pone

gran esfuerzo en el diseño de los SGBD. Se denomina transaccional al SGBD

capaz de garantizar la integridad de los datos, no permitiendo que las

transacciones puedan quedar en un estado intermedio. Esto implica la capacidad

de poder volver a un estado anterior en caso de que por cualquier causa (error

en el sistema, fallo eléctrico, etc.) no haya podido completarse la transacción.

DISEÑO Y CREACIÓN DE UNA BASE DE DATOS

Una vez se toma la decisión de emplear una base de datos, el siguiente paso es

el diseño y creación de esta. El diseño implica la definición de la estructura que

va a tener la base de datos, que se deberá realizar teniendo en cuenta

principalmente el tipo de datos que van a almacenarse y el modelo de base de

datos elegido. El diseño debe adecuarse al uso previsto de la base de datos, de

tal modo que acomode los datos de la mejor forma posible para cumplir los

objetivos enunciados anteriormente en este mismo capítulo. Para ello debe

conocerse la naturaleza de los datos que van a almacenarse (no necesariamente

datos de los que se dispone en el momento de la creación, sino los que se espera
pasen a formar parte de la base de datos a lo largo de su ciclo de vida), así como

la de los algoritmos y procesos que van a emplearse sobre ellos.

Posteriormente al diseño, debe procederse a la implementación de la base de

datos, esto es, a la creación propiamente dicha, incorporando los datos según

los esquemas escogidos en la fase de diseño. Por último, y una vez creada la

base de datos, debe procurarse un mantenimiento para que esté continuamente

en condiciones de ser utilizada.

Más concretamente, pueden distinguirse las siguientes fases en el proceso

global de desarrollo de una base de datos:

Diseño lógico. Independiente del SGBD empleado, es un diseño conceptual

que pretende modelizar el contenido de la base de datos.

 Diseño físico. Es la adaptación del diseño conceptual a las

particularidades del SGBD escogido.

 Implementación. Introducción de los datos en la base de datos.

 Mantenimiento. Monitorización de la actividad sobre la base de datos.

La primera fase en el diseño de una base de datos implica un análisis de los

datos que se van a recoger. Como resultado de ese análisis debe surgir un

modelo conceptual que exprese la estructura de la información, siendo dicha

estructura susceptible de ser empleada como esquema base para la base de

datos en cuestión. El modelo conceptual ha de definir básicamente los tipos de

datos a tratar y las relaciones existentes entre ellos, elementos que serán luego

expresados en términos del modelo de base de datos elegido (relacional,

orientado a objetos, etc.) una vez se pase a la fase de diseño físico.

El modelo conceptual debe estructurar la información de forma que el usuario de

la base de datos comprenda de forma sencilla el contenido y forma de esta. Por

tanto, debe desarrollarse teniendo presentes las necesidades de los usuarios y

el hecho de que estos no necesariamente han de ser especialistas en bases de

datos, sino especialistas en los propios datos en sí. Por otra parte, el modelo

debe intentar capturar del mejor modo posible la realidad que se pretende

modelizar, por lo que el conjunto de tipos de datos y relaciones debe elaborarse

de modo similar a dicha realidad para recoger toda la complejidad del sistema.

Y, por supuesto, el modelo debe poder ser implementado posteriormente y

utilizado en conjunto con el SGBD escogido, ya que de otro modo no presenta

utilidad práctica.

Existen diversas metodologías para desarrollar un modelo conceptual. Una de

las más extendidas por su sencillez y potencia es la del modelo entidad--

relación (abreviadamente, modelo E--R).

Denominamos entidad a un objeto o concepto del mundo real acerca del cual se

recoge información, y que puede diferenciarse de otros objetos, incluso si son de

su misma clase (un ordenador, por ejemplo, es un objeto, y puede diferenciarse

de otros ordenadores, incluso si son de idénticas características, ya que no son

todo el mismo objeto y ese en particular tendrá alguna propiedad distinta, como

puede ser el número de serie). La entidad puede tener sentido físico o bien ser

una idea abstracta, como un tipo de deporte, una clase de música o una palabra.

Por su parte, una relación expresa la dependencia existente entre entidades y

permite la asociación de estas. No resulta difícil ver que estos conceptos —

entidad, atributos y relación— guardan un notable paralelismo con las ideas del

modelo relacional que ya conocemos. Así, y aunque no resulte por completo

inmediato, es sencillo traducir un modelo entidad-relación (conceptual) a un

modelo relacional, que constituye ya un modelo aplicado a un tipo particular de

base de datos. Por ello, el modelo E--R es una herramienta potente para el

diseño lógico de la base de datos, especialmente si esta utiliza el modelo

relacional.

Para desarrollar el diseño conceptual de una base de datos siguiendo el modelo

E--R, estos son los pasos principales:

 Partimos de una descripción textual del problema o sistema que

queremos recoger. Esta descripción contiene los requisitos necesarios y

ha de formular la pregunta a la que queremos que la base de datos dé

respuesta. Para nuestro ejemplo con datos sobre personas y ciudades, el

problema podríamos formularlo como «¿qué personas han nacido en

cada ciudad?».

 Se toman los verbos y los sustantivos de la descripción textual. Los

sustantivos son posibles entidades o atributos, mientras que los verbos

son posibles relaciones. En nuestro caso, «persona» y «ciudad» serán

entidades y «nacido en» una relación.

 Se analizan las frases y determina la cardinalidad de las relaciones y otros

detalles.

BASES DE DATOS ESPACIALES

Todo cuanto hemos visto en los puntos anteriores constituye el conjunto de ideas

fundamentales sobre las que se asienta la creación y uso de bases de datos de

cualquier índole. No obstante, no hemos mencionado a lo largo de los ejemplos

presentados ningún dato de carácter espacial, a pesar de que sabemos bien que

la información geográfica contiene tanto una componente temática como una

espacial. Más aún, algunos de los atributos en los sencillos casos mostrados,

como puede ser el atributo CIUDAD, son fácilmente asociables a elementos

geográficos (por ejemplo, un punto que señale el centro de la ciudad o un

polígono que recoja su contorno).

Aunque las ideas anteriores no pierden su validez al incorporar datos espaciales,

la inclusión de estos no es en absoluto obvia, y presenta una complejidad

adicional que requiere de nuevos planteamientos para poder seguir trabajando

con la base de datos de una forma similar a como sucede cuando se trabaja con

los tipos de datos habituales. Mantener las características propias del SGBD en

el contexto de los datos espaciales no es sencillo, y tampoco lo es integrar esa

base de datos dentro de un SIG y permitir que este aproveche la potencia de

dicha base de datos de la mejor manera posible.

Las bases de datos espaciales representan una de las áreas dentro del manejo

de datos donde se ha desarrollado últimamente una mayor evolución,

especialmente debido a la gran importancia que los SIG, usuarios primordiales

de este tipo de bases de datos, han cobrado recientemente. Esta evolución ha

ido paralela a la forma en que los SIG han trabajado con esas bases de datos y

cómo se han integrado en ellos las operaciones y funcionalidades que ofrecen.

En lugar de adentrarnos en la complejidad de las bases de datos espaciales

(aunque en el capítulo Consultas veremos bastante más en lo que a las

operaciones y posibilidades de estas respecta), veremos las distintas etapas que

podemos encontrar a lo largo de la historia de los SIG en lo referente a su

integración con bases de datos, para de este modo comprender los diversas

soluciones que han ido apareciendo.

EVOLUCIÓN DEL USO DE BASES DE DATOS EN LOS SIG

Como acabamos de decir, los conceptos que hemos visto en las anteriores

secciones representan una gran parte de la realidad actual en cuanto al manejo

de datos (espaciales o no) dentro de un SIG. No obstante, el problema del

acceso a los datos se ha solucionado de diversas formas a lo largo de la historia

de los SIG, y encontramos en las aplicaciones SIG distintos enfoques a lo largo

del tiempo. Para concluir este capítulo veremos con algo más de detalle la

evolución que ha seguido esta importante faceta de los SIG.

PRIMERA GENERACIÓN. FICHEROS

Los primeros programas, entre los cuales se han de incluir los primeros SIG, se

caracterizaban en lo que al almacenamiento de datos respecta por una ausencia

completa de cualquier tipo de almacenamiento estructurado. En estas

aplicaciones, los datos no se veían como un elemento más dentro de un sistema,

sino como una parte del propio software o, al menos, como algo asociado

únicamente a un producto particular. Así, encontramos en esta época como

práctica habitual el uso de ficheros con formatos cerrados, pensados para ser

leídos y escritos casi de forma exclusiva por la aplicación particular que ha de

consumirlos, limitando así el uso compartido y el alcance de los datos a otros

ámbitos distintos.

Integrar en el SIG otros datos distintos a aquellos para los que la aplicación se

había diseñado no era sencillo, ya que existía una vinculación muy directa entre

software y datos. Asimismo, las funcionalidades del software eran también

específicas para esos datos, y todas ellas se implementaban directamente en la

aplicación. Al no existir un SGBD que se encargara de gestionar las operaciones,

era el propio SIG quien debía ser responsable de las funcionalidades de acceso

o edición. Otras funcionalidades típicas de un SGBD, sin embargo, no aparecían

en estos primeros SIG, ya que no eran necesarias. Por ejemplo, velar por la

integridad de los datos en operaciones concurrentes de varios usuarios no era

necesario si la aplicación en sí no estaba diseñada para permitir este acceso

múltiple.

Las únicas ventajas que pueden encontrarse en este enfoque son las

relacionadas con el rendimiento, que podía en ciertos casos ser mayor que el

esperable en caso de utilizar un SGBD para canalizar el trabajo con los datos.

Esto es así debido a que la propia especificidad de la aplicación permitía una

optimización «a medida», aunque todo ello a cambio de sacrificar la flexibilidad

de la aplicación, su escalabilidad, o la posibilidad de que los datos empleados

pudieran ser utilizados de forma sencilla para alimentar otras aplicaciones.

SEGUNDA GENERACIÓN. BASES DE DATOS RELACIONALES

Una vez que las bases de datos comienzan a tomar su papel en el panorama del

software, no tardan en encontrar su camino dentro de las aplicaciones SIG. Las

bases de datos relacionales, que como ya sabemos son las más empleadas,

comienzan a ser utilizadas también para gestionar los datos espaciales con los

que se trabaja en un SIG. A partir de esta segunda generación, se empiezan a

adaptar las características del modelo relacional y de las bases de datos que lo

implementan a las particularidades de los datos espaciales. Las dificultades que

aparecen debido a la inherente complejidad de la componente espacial hacen

que surjan diversas alternativas para su manejo. Las más reseñables de entre

ellas son el uso de una arquitectura dual en la que únicamente la componente

temática se gestiona mediante una base de datos y el uso de una arquitectura

en capas en el que se da un pleno almacenamiento de la información espacial

en la base de datos.

ARQUITECTURA DUAL

El primer intento de incorporar las bases de datos lo encontramos en el uso de

una arquitectura dual en la cual el SGBD se hace cargo únicamente de la

componente temática de los datos. Puesto que la dificultad estriba en el manejo

de la componente espacial, esta no se incorpora por el momento a la base de

datos, que trabajará únicamente con los datos temáticos. Esto permite el uso de

sistemas gestores de bases de datos estándar, sin adaptación alguna, ya que

estos se encuentran perfectamente preparados para el manejo de esos datos no

espaciales, y no requieren elementos adicionales para trabajar sobre ellos.

La componente espacial, por su parte, es gestionada por el propio SIG, en el que

se implementan las funcionalidades necesarias. Al igual que sucedía

anteriormente con los SIG de primera generación, no todas las funcionalidades

de un SGBD han de aparecer necesariamente, ya que el sistema encargado de

permitir el trabajo con los datos no es como tal un SGBD. La única diferencia

reside en que en este caso esta circunstancia afecta tan solo a la componente

espacial de los datos, mientras que la componente temática queda en manos de

un verdadero SGBD.

ARQUITECTURA EN CAPAS

La otra forma de aprovechar una base de datos relacional para su uso dentro

de un SIG consiste en incorporar toda la información dentro de la base de

datos, incluyendo la de corte espacial, buscando la manera más adecuada

de llevar esto a cabo pese a las limitaciones que la propia base de datos

presenta en este caso. Asumiendo que una base de datos relacional en su

concepto tradicional no está diseñada para contener objetos complejos tales

como geometrías o imágenes, y que, especialmente, el SGBD

correspondiente no presenta las mismas funcionalidades y la misma potencia

en el manejo de este tipo de datos que en el de tipos de dato estándar (valores

numéricos, cadenas de texto, fechas, etc.), es posible, sin embargo, plantear

soluciones que permitan llevar toda la información de un SIG a una base de

datos y poder gestionarla por completo a través de un SGBD, con las ventajas

que ello conlleva, y que ya conocemos.

Dos son las alternativas existentes: un almacenamiento transparente y un

almacenamiento opaco. Ambos se distinguen en la forma de almacenar la

información y también las operaciones sobre los datos, que vienen

condicionadas por la estrategia empleada para el almacenamiento de estos.

En el almacenamiento transparente se emplean los propios tipos de datos del

SGBD, y las operaciones se implementan en el lenguaje de consulta de este.

Es decir, se intenta implementar toda la funcionalidad deseada empleando

los elementos básicos del SGBD de la misma forma que haríamos si los datos

a almacenar no fueran de tipo espacial. La componente espacial de los datos

se almacena empleando tuplas, variando según la implementación la manera

en que esto se lleva a cabo. Una geometría como tal no se ajusta a ningún

tipo básico de datos, pero en realidad esa geometría no es sino un conjunto

de coordenadas que definen una serie de puntos, y dichas coordenadas sí

que son un tipo básico susceptible de almacenarse en un SGBD común.

En el almacenamiento opaco se emplean objetos binarios para almacenar la

información y las operaciones se implementan externamente en la

herramienta SIG. Al no utilizar los tipos de datos del SGBD, tampoco pueden

emplearse las operaciones de consulta de este, y es necesario implementar

los algoritmos correspondientes en el SIG.

La ventaja más directa de utilizar una arquitectura en capas, ya sea mediante

un almacenamiento transparente o uno opaco, es la facilidad para reutilizar

un SGBD existente. Con poco esfuerzo pueden incorporarse los datos

espaciales a un SGBD estándar, existiendo en la actualidad numerosas

alternativas sobradamente probadas y con una amplia gama de

funcionalidades. Esta es la opción más empleada hoy en día en los SIG,

principalmente por esa sencillez, que permite una conexión sin muchas

dificultades de una aplicación SIG con la mayoría de los SGBD de uso

habitual fuera del ámbito SIG.

Existen, no obstante, inconvenientes y aspectos mejorables, achacables a la

nula especialización de los SGBD para el manejo de información espacial. En

el caso del almacenamiento opaco, no poder emplear el lenguaje de consulta

del SGBD constituye un grave inconveniente. Por su parte, en el

almacenamiento transparente sí que puede emplearse, pero no todas las

operaciones necesarias para el trabajo con datos espaciales pueden

implementarse con un lenguaje de consulta no adaptado a las

particularidades de los datos espacial, por lo que la funcionalidad es limitada.

Asimismo, la eficacia es limitada, ya que en un caso los algoritmos son

externos al SGBD y en el otro las consultas suelen ser complejas y operan

sobre un elevado número de tuplas, necesario para recoger la información

espacial.
TERCERA GENERACIÓN. BASES DE DATOS EXTENSIBLES

En la actualidad, las bases de datos presentan arquitecturas extensibles que

permiten ser adaptadas a la naturaleza de los datos con los que trabajan, de tal

forma que enfocan sus funcionalidades hacia la tipología particular que se

manejen. Los tipos de datos clásicos que ya se han citado conviven con nuevos

tipos de datos que pueden ser definidos, y con operaciones específicas para

estos.

Un caso particular de estas bases de datos extensibles son las bases de datos

orientadas a objetos, que ya fueron comentadas al presentar los distintos

modelos de bases de datos. A pesar de que este tipo de bases de datos no

ocupan una porción significativa en el mercado global de las bases de datos y

son las de tipo relacional las más extendidas, existen algunos sectores en los

que han logrado una mayor penetración, entre ellos el del SIG. Por sus

características, las bases de datos orientadas a objetos resultan ventajosas para

el manejo de datos complejos que no puedan recogerse con facilidad utilizando

los tipos de datos clásicos de una base de datos relacional. En este grupo

pueden incluirse las primitivas geométricas que utilizamos en un SIG para

recoger la componente espacial de un dato espacial, las cuales resulta más

adecuado considerar como objetos de un tipo dado (punto, línea o polígono),

aprovechando así las ventajas que un enfoque orientado a objetos proporciona.

La principal ventaja de una base de datos orientada a objetos es su mayor

eficiencia en el acceso a datos, lo que se traduce en consultas más rápidas en

comparación con una base de datos relacional (veremos más sobre consultas

en bases de datos espaciales en el capítulo Consultas). Por el contrario, carece

de la base matemática de esta, por lo que el soporte para esas consultas es

menos robusto. Para saber más sobre bases de datos orientadas a objetos,

puede consultarse [Marques2002BBDD].

Los SGBD actuales presentan en su gran mayoría extensiones dedicadas al

manejo de datos espaciales, los cuales contienen todo lo necesario para el

manejo óptimo de estos, la realización de ciertas operaciones fundamentales y

la optimización de las consultas y operaciones. Esta optimización es posible ya

que el tipo de datos espacial está plenamente integrado en la base de datos y

es considerado de la misma manera que cualquiera de los tipos de datos

estándar como puede ser una cadena de texto o un valor numérico. La eficiencia

que se obtiene de este modo es muy elevada”.

http://volaya.github.io/libro-sig/chapters/Bases_datos.html

MODELOS DE BASES DE DATOS

“Además de la clasificación por la función de las bases de datos, estas también

se pueden clasificar de acuerdo a su modelo de administración de datos.

Un modelo de datos es básicamente una "descripción" de algo conocido

como contenedor de datos (algo en donde se guardan los datos), así como de

los métodos para almacenar y recuperar datos de esos contenedores. Los

modelos de datos no son cosas físicas: son abstracciones que permiten la

implementación de un sistema eficiente de base de datos; por lo general se

refieren a algoritmos, y conceptos matemáticos.

Algunos modelos con frecuencia utilizados en las bases de datos:

BASES DE DATOS JERÁRQUICAS

En este modelo los datos se organizan en forma de árbol invertido (algunos dicen

raíz), en donde un nodo padre de información puede tener varios hijos. El nodo

que no tiene padres es llamado raíz, y a los nodos que no tienen hijos se los

conoce como hojas.

Las bases de datos jerárquicas son especialmente útiles en el caso de

aplicaciones que manejan un gran volumen de información y datos muy

compartidos permitiendo crear estructuras estables y de gran rendimiento.

Una de las principales limitaciones de este modelo es su incapacidad de

representar eficientemente la redundancia de datos.

BASE DE DATOS DE RED

Este es un modelo ligeramente distinto del jerárquico; su diferencia fundamental

es la modificación del concepto de nodo: se permite que un mismo nodo tenga

varios padres (posibilidad no permitida en el modelo jerárquico).

Fue una gran mejora con respecto al modelo jerárquico, ya que ofrecía una

solución eficiente al problema de redundancia de datos; pero, aun así, la

dificultad que significa administrar la información en una base de datos de red ha

significado que sea un modelo utilizado en su mayoría por programadores más

que por usuarios finales.

BASES DE DATOS TRANSACCIONALES

Son bases de datos cuyo único fin es el envío y recepción de datos a grandes

velocidades, estas bases son muy poco comunes y están dirigidas por lo general

al entorno de análisis de calidad, datos de producción e industrial, es importante

entender que su fin único es recolectar y recuperar los datos a la mayor velocidad

posible, por lo tanto la redundancia y duplicación de información no es un

problema como con las demás bases de datos, por lo general para poderlas

aprovechar al máximo permiten algún tipo de conectividad a bases de datos

relacionales.

Un ejemplo habitual de transacción es el traspaso de una cantidad de dinero

entre cuentas bancarias. Normalmente se realiza mediante dos operaciones

distintas, una en la que se debita el saldo de la cuenta origen y otra en la que

acreditamos el saldo de la cuenta destino. Para garantizar la atomicidad del

sistema (es decir, para que no aparezca o desaparezca dinero), las dos

operaciones deben ser atómicas, es decir, el sistema debe garantizar que, bajo

cualquier circunstancia (incluso una caída del sistema), el resultado final es que,

o bien se han realizado las dos operaciones, o bien no se ha realizado ninguna.

Bases de datos relacionales

Este es el modelo utilizado en la actualidad para representar problemas reales y

administrar datos dinámicamente. Tras ser postulados sus fundamentos

en 1970 por Edgar Frank Codd,de los laboratorios IBM en San José (California),

no tardó en consolidarse como un nuevo paradigma en los modelos de base de

datos. Su idea fundamental es el uso de "relaciones". Estas relaciones podrían

considerarse en forma lógica como conjuntos de datos llamados "tuplas". Pese

a que esta es la teoría de las bases de datos relacionales creadas por Codd, la
mayoría de las veces se conceptualiza de una manera más fácil de imaginar.

Esto es pensando en cada relación como si fuese una tabla que está compuesta

por registros (las filas de una tabla), que representarían las tuplas, y campos (las

columnas de una tabla).

En este modelo, el lugar y la forma en que se almacenen los datos no tienen

relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto

tiene la considerable ventaja de que es más fácil de entender y de utilizar para

un usuario esporádico de la base de datos. La información puede ser recuperada

o almacenada mediante "consultas" que ofrecen una amplia flexibilidad y poder

para administrar la información.

El lenguaje más habitual para construir las consultas a bases de datos

relacionales es SQL, Structured Query Language o Lenguaje Estructurado de

Consultas, un estándar implementado por los principales motores o sistemas de

gestión de bases de datos relacionales.

Durante su diseño, una base de datos relacional pasa por un proceso al que se

le conoce como normalización de una base de datos.

BASES DE DATOS MULTIDIMENSIONALES

Son bases de datos ideadas para desarrollar aplicaciones muy concretas, como

creación de Cubos OLAP. Básicamente no se diferencian demasiado de las

bases de datos relacionales (una tabla en una base de datos relacional podría

serlo también en una base de datos multidimensional), la diferencia está más

bien a nivel conceptual; en las bases de datos multidimensionales los campos o

atributos de una tabla pueden ser de dos tipos, o bien representan dimensiones

de la tabla, o bien representan métricas que se desean aprender.

BASES DE DATOS ORIENTADAS A OBJETOS

Este modelo, bastante reciente, y propio de los modelos informáticos orientados

a objetos, trata de almacenar en la base de datos los objetos completos (estado

y comportamiento).

Una base de datos orientada a objetos es una base de datos que incorpora todos

los conceptos importantes del paradigma de objetos:

 Encapsulación - Propiedad que permite ocultar la información al resto de

los objetos, impidiendo así accesos incorrectos o conflictos.

 Herencia - Propiedad a través de la cual los objetos heredan

comportamiento dentro de una jerarquía de clases.

 Polimorfismo - Propiedad de una operación mediante la cual puede ser

aplicada a distintos tipos de objetos.

En bases de datos orientadas a objetos, los usuarios pueden definir operaciones

sobre los datos como parte de la definición de la base de datos. Una operación

(llamada función) se especifica en dos partes. La interfaz (o signatura) de una

operación incluye el nombre de la operación y los tipos de datos de sus

argumentos (o parámetros). La implementación (o método) de la operación se

especifica separadamente y puede modificarse sin afectar la interfaz. Los

programas de aplicación de los usuarios pueden operar sobre los datos

invocando a dichas operaciones a través de sus nombres y argumentos, sea cual

sea la forma en la que se han implementado. Esto podría denominarse

independencia entre programas y operaciones.

BASES DE DATOS DOCUMENTALES

Permiten la indexación a texto completo, y en líneas generales realizar

búsquedas más potentes, sirven para almacenar grandes volúmenes de

información de antecedentes históricos. Tesaurus es un sistema de índices

optimizado para este tipo de bases de datos.

BASES DE DATOS DEDUCTIVAS

Un sistema de base de datos deductiva, es un sistema de base de datos pero

con la diferencia de que permite hacer deducciones a través de inferencias. Se

basa principalmente en reglas y hechos que son almacenados en la base de

datos. Las bases de datos deductivas son también llamadas bases de datos

lógicas, a raíz de que se basa en lógica matemática. Este tipo de base de datos

surge debido a las limitaciones de la Base de Datos Relacional de responder a

consultas recursivas y de deducir relaciones indirectas de los datos almacenados

en la base de datos”.

https://es.wikipedia.org/wiki/Base_de_datos#Modelos_de_bases_de_datos
PROCEDIMIENTO
CONCLUSIÓN
BIBLIOGRAFÍA
WEBGRAFIA