Bases de datos

1. Prlogo a las bases de datos

Las bases de datos relacionales, se empezaron a usar cuando existi la necesidad de crear un
enlace entre datos de distintas bases, ya fuere por la necesidad de disminuir el espacio que
ocupasen dos bases de datos con relacin entre ellas o bien por la necesaria relacin de datos
entre dichas bases.
Para hacerlo ms fcil , haremos una comparacin muy sencilla, supongamos una tienda de
productos de alimentacin , como las que tenemos junto a nuestras casas o un gran
supermercado, en el momento en que los ordenadores entraron a formar parte de dichos
comercios, toda la informacin se fue guardando en dichos ordenadores, y entonces tenemos
por ejemplo productos que vendemos al pblico y a su vez tenemos proveedores que nos
venden a nosotros.
Dado lo anterior tenemos por ejemplo 40 o 50 o incluso ms productos que vienen de un mismo
proveedor, por lo que en realidad ya existe una clara relacin entre los productos y el proveedor
que nos los vende, pero como hacemos sta relacin efectiva en el ordenador, pues tenemos que
tener en cuenta que las bases de datos de los productos y de los proveedores son distintas, y si
por necesidad quisieramos saber todos los productos de un mismo proveedor, tendriamos que ir
mirando ficha a ficha cada producto para ver quien es el proveedor, en ste supuesto es donde
entran las bases de datos relacionales.
Aunque el campo principal de actuacin y utilidad de la bases de datos relacionales es la
gestin , tambin podramos si fuera necesario adaptarlo a nuetras propias necesidades.
En los siguientes captulos usted aprender como son y que son las bases de datos y las posibles
relaciones entre ellas.
Le aconsejo que preste atencin a los primeros captulos, pues son la base de todo el curso y por
lo tanto, necesarios para comprender los detalles tcnicos que posteriormente se le iran
detallando.

2. Cmo son las bases de datos

Podemos definir a una base de datos , como un fichero en el cual se almacena informacin de
cualquier tipo.

En dicho fichero la informacin se almacena en campos o delimitadores, osea, podemos

almacenar El nombre y el Apellido de las personas de modo separado , de sta forma podemos
sacar del fichero todos los nombres o todos los apellidos , tanto de forma separada como de
forma conjunta.
Normalmente el nmero de campos que podemos tener en una base vara segn las necesidades
que tengamos en cuanto a separacin de datos, de forma que despus podamos sacar la
informacin de forma ordenada y separada, aunque el resto de la informacin sigue almacenada
y guardada en la base de datos.
Aunque en realidad hemos de tener en cuenta, que una base de datos , tal y como la
conocemos, no es solo el fichero en donde guardamos los datos, si no que en dicho fichero se
encuentra la estructura de los datos, osea, para saber que longitud tiene cada campo, debemos
saber como se llama el campo y que longitud en caracteres tiene, asi como el tipo de datos que
almacenamos en dicho campo, por que podemos guardar desde letras a nmeros o incluso otros
datos ms sofisticados, dependiendo de la estructura de la base y del sistema que tengamos
para saber cual es dicha estructura.
En realidad aparte de los datos en si mismo que son almacenados en el archivo , tambin
tenemos una serie de datos, en los cuales se informa del tipo de campo, los campos y la longitud
de cada campo, es lo que podremos llamar Gestor de datos, dicho gestor nos permite saber que
cada registro (un registro es una suma de campos, por ejemplo Tenemos a Jose Antonio LOPEZ
LOPEZ, Jose antonio lo guardamos en el campo Nombre y LOPEZ LOPEZ en el campo Apellidos,
cada registro es cada persona que almacenamos en la base , osea una persona es un registro y
cada regitro est constituido por los campos Nombre y Apellido.
Con el gestor sabemos la longitud de cada campo y el tipo de dato que contiene.
Normalmente cuando hablemos de base de datos, el fichero que contiene los datos y el gestor,
actualmente se les denomina Tabla, lo unico que cambia es que en un mismo fichero podremos
almacenar varias tablas, osea podremos tener un solo fichero y dentro de ste podremos tener
varias bases de datos (proveedores, productos, clientes, etc..) separados en tablas, est es la
ventaja que actualmente hay con respecto al sistema antiguo, que obligaba a tener un fichero
por cada base de datos, osea que tendriamos que tener un fichero para los proveedores, otro
para los productos y asi tantos como bases teniamos.

Aunque pudiera dar a pensar que se pueden alterar los datos teniendo en un mismo fichero
varias tablas , en realidad estn separadas, aunque estn en un mismo fichero, cada tabla est
delimitada y no existe la posibilidad que se pudieran mezclar, este es un problema por el cual no
hay que preocuparse.
Actualmente hay varios tipos de bases de datos, las dbf , paradox, interbase y otras de distinto
tipo, pero en realidad , para ste curso eso no es relevante, dado que a nosotros nos interesa
relacionar dato de diferentes tablas , an siendo el tipo de base elegida de cualquier forma o
relacin.

Las tablas

El diseo de las bases de datos para relacionar datos, es muy importante, pero debemos tener
en cuenta que quizs est posibilidad no siempre la tengamos a mano, osea , es posible que se
nos encarge realizar un programa para un comercio que ya ha tenido un programa , por lo que
vamos a trabajar con datos de bases ya creadas y por lo tanto tendremos que usar bases de
otras personas que quizs no hayan pensado en relacionar dichas bases.
Tanto si tenemos la oportunidad de crear las bases como si no la tenemos, para realizar
relaciones entre bases de datos (tablas, acostumbrese a usar el nombre de tabla, memorizelo,
de momento se lo ir recordando, pero en los prximos captulos solo usar el trmino Tabla en
vez de base de datos), tendremos que realizar un campo que enlace las bases de dato.
Por ejemplo, usando los comercios, para relacionar los proveedores con lo productos tendremos
que tener en la base de datos de proveedores un campo que coincida con otro campo con el
mismo nombre en la base de dato de productos.
De sta forma cuando sacamos un producto de la base de datos(tabla) de los productos,
buscamos en el campo de la base donde guardamos el codigo del proveedor y luego buscamos
en la base de datos(tabla) de proveedores dicho cdigo, con sto realizamos el enlace entre
bases de datos de distinto tipo y de distinto formato.
Recuerde siempre que tanto si dispone de la posibilidad de crear las bases de datos(tablas)
nuevas o debe usar unas ya existentes, deber crear la relacin entre dichas bases(tablas)
mediante un campo que las relacione.

4. Los campos clave

En el captulo anterior vimos la necesidad de crear la relacin entre distintas bases de datos.
Para dicha relacin hemos creado un campo comn en ambas bases de datos(tablas) , dicho
campo es en realidad el campo clave, osea el campo que relaciona una base con otra.

Pero debemos tener en cuenta que podremos tener tantos campos claves como querramos, osea
que podremos tener relacin entre distintas bases(tablas).
Un ejemplo claro es un producto que adems de tener el campo clave para identificar al
proveedor que lo suministra, adems tendremos otro campo clave que identifique las
caracteristicas tcnicas de dicho producto.
Ahora surge la principal pregunta por que tener distintas bases(tablas), podemos poner muchos
campos y almacenar en ellos los datos, y asi ahorrarnos trabajo y enlace entre bases(tabla).
Para esto hay una sencilla respuesta , observe atentamente ste ejemplo.
Tenemos unos productos:
001 del proveedor DIAZ LOPEZ IGLESIAS S.A. y caracteristicas X109, Y898, Z9289, V9989
002 del proveedor DIAZ LOPEZ IGLESIAS S.A. y caracteristicas X109, Y898, Z9289, V9989
003 del proveedor LOPEZ LOPE IGLESIAS S.A. y caracteristicas A109, B898, C9289, D9989
con esto vemos que en dos productos tenemo repetidos al proveedor y las caractersticas del
producto, osea que desperdiciamos memoria , supongamos que en vez de 2 tenemos 400
productos que se repiten en el provedor y las caracteristicas del producto, como el ancho de la
caja en que estn embalados, para esto hacemos la relacin y entonces tenemos:
001 del proveedor PR01 y caracteristicas CA01
002 del proveedor PR01 y caracteristicas CA01
003 del proveedor PR02 y caracteristicas CA02
y tendriamos las bases de datos de los proveedores:
PR01 DIAZ LOPEZ IGLESIAS S.A.
PR02 LOPEZ LOPE IGLESIAS S.A.
y tendriamos la base de caracteriticas:

CA01 X109, Y898, Z9289, V9989

CA02 A109, B898, C9289, D9989
Con esto hemos conseguido un importante ahorro en espacio del fichero por que en vez de tener
que escribir todo el nombre del proveedor, solo ponemos el codigo osea PR01 o PR02 y el codigo
de las caractersticas CA01 o CA02 , el ahorro est en el espacio, mientras que para poner el
codigo solo hemos necesita 4 caracteres para poner PR01 o PR02, si usamos el nombre
necesitariamos por lo menos 30 caracteres para poder poner todo el nombre del proveedor y lo
mismo sucede con las caractersticas, el ahorro est en dicho espacio desperdiciado en el fichero
y por lo tanto el fichero ser ms grande y por lo tanto su uso ms lento.
Es entonces cuando vemos la necesidad de usar bases de datos(tablas) relacionales.

Creacin de una base de datos

Aunque tipos de datos hay de varias clases y formas de clasificarlos hay muchas , a la hora de
crear una tabla , la mayoria de lo sistemas utilizan la misma forma, aunque no podemos
asegurar que sea as, daremos por afirmativo que as es.
En consecuencia el sistema de creacin de una base de datos(tabla), suele ser:
Se nos pedir el nombre del campo que queremos crear.
Se nos pedir el tipo de dato que almacenar dicho campo, normalmente puede ser String,
Numrico, Boolean, Decimal y otros, que depender del gestor con el cual creamos la tabla,
asi mismo tambin se nos dar la posibilidad de definir los decimales para los campos nmericos
y decidir el indice.
El ndice: esto es un punto muy importante a la hora de crear una base de datos (tabla) con
ndices, un ndice no es ms que el orden que establecemos para dicho campo, con esto
conseguimos aumentar la velocidad de bsqueda a la hora de encontrar a un determinado
registro, supongamos que hemos hecho una base de datos(tabla) para almacenar direcciones de
amigos, entonces supogamos que tenemos la direccin de 300 amigos y queremos buscar a
Pepe TOLO TOLO, si no tenermos indices en la base de datos , tendramos que ir registro a
registro y comprobar cada apellido si coincide con el que buscamos, pero si est
ordenada(indexada) para buscar a TOLO solo tendremos que ir a los que empiezan por T y
saltando las dems letras A,B,C,... hasta la T, osea que no hemos tenido que comprobar los

apellidos que hay entre la A y la T, imaginaos la velocidad que hemos ahorrado en 300 amigos
que tenemos, pues imaginaros una empresa con 50.000 clientes, la velocidad que se ahorran en
buscar a un cliente, imaginaros por un momento que pedis el telfono de un cliente que
necesitais urgentemente y que al solicitarlo a vuestra secretaria, sta os dice, la semana que
viene se lo doy.
Pues en realidad el ejemplo que os he dado es el ahorro de velocidad que conseguimos, cuantos
mas datos tengamos , ms efectivo ser el sistema de ahorro en tiempo.
En la actualidad , como ya hemos mencionado en captulos anteriores, podremos tener varias
tablas en un mismo fichero y como consecuencia podremos crear tantas tablas como querramos.
Recuerde que si va a relacionar las tablas, deber crear los campos claves para establecer la
relacin entre dichas tablas.

. Las relacioens entre los datos

La dependencia funcional en una base de datos, es aquella que determina la relacin que hay
entre las bases de datos que usan de modo conjunto una relacin de datos.
Para averiguar la dependencia existente entre bases de datos, debemos analizar las propiedades
de los campos, para as averiguar cual es la relacin existente entre las bases y que tipo de
relacin hay entre ellas.
Debemos tener en cuenta que cuando vayamos a realizar una relacin entre bases, aquellos
campos que hemos seleccionado para que sean los campos clave, que sern los que realizen el
enlace entre bases, deben ser del mismos tipo, por ejemplo que usemos tipos nmericos, los dos
campos en las bases deben ser nmericos, de te modo no tendremos que realizar funciones
que conviertan los tipos.
EJEMPLO:
Creamos dos bases de datos, en las cuale vamos a guardar en una de ellas los datos de los
clientes , el nombre, la direccin y el dni, y en otra guardaremos a la hora que nos han hecho el
pedido.
En enlace entre ellas, ser evidentemente por el nmero del dni.

Al crear las bases ser as:

Clientes.dbf:
Campo
Nombre
Direccion
DN

Tipo
Caracter
Caracter
Numrico

Longitud
40
40
10

Pedidos.dbf:
Campo
Hora
DN

Tipo
Caracter
Numrico

Longitud
5
10

Como se puede observar , el camplo clave es DNI, y en ambas bases de datos debe ser del
mismo tipo , en ste caso es nmerico.
Si por cualquier motivo, el tipo debiera de ser caracter u otro distinto, en la otra base deber de
ser del mismo tipo.

. Los modelos de bases de datos

En el mercado podemos encontrar una gran variedad de bases de datos, de distintos formatos,
tipos, usos, gusto, etc.. pero evidentemente existen en dicho mercado una tendencia de uso
hacia ciertas marcas, por asi decirlo, de productos que integran totalmente o en parte a un
determinado tipo de base de datos, lo que nos obliga de forma indirecta a conocer el
funcionamiento de dichas bases de datos, o mejor dicho de la forma de usarla o la gestion de
dichas bases.

La dbf, de DBASE, que practicamente todos conoceremos.

La Mdb de Microsoft, que es la que utiliza el Access y otros productos de dicha

compaia.

La Oracle, que aunque aqui en Espaa no sea muy usada o conocida, si es una de las
mas usadas mundialmente.

Y actualmente esta haciendo aparicion la denominada Interbase y la DB2, que aunque

actualmente no sean muy usadas, se podrian convertir en otro estandar en la gestion de datos.

Hemos de tener en cuenta que el uso de uno u otro tipo esta directamente ligado con las
tendencias del mercado, y es el mismo mercado con su demanda quien determina cual es el que
ostenta la supremacia durante un tiempo.
Aunque su esquema tecnico no hace falta conocer, si es necesario reconocer el tipo de base por
si nos fuera necesaria su gestion.
Existe otro tipo que es la db, conocida como paradox pero es igual a la dbf, no presenta ningun
incoveniente.
Para usar la DBF es necesario tener una de las versiones de DBASE, no es imprescindible pero
si aconsejable tener algun gestor de datos que os permita manejar este tipo de bases, en el
mercado hay muchos y gratuitos.
La MDB , Microsoft, suele ofrecer productos que las manejan.
La mas dificil es la Oracle, este tipo de base de datos, es dificil de manejar a no ser que se
adquieran productos especializados, pero si se busca es posible encontrar algo.

El uso de las relaciones intertabla

Aunque a simple vista podamos creer que no es necesario o funcional para una empresa, un tipo
u otro de base de datos, la eleccion esta directamente relacionado con la productividad que
vamos a tener usando la gestion de la base que hayamos escogido.
El motivo en que se fundamenta una eleccion es el siguiente:
Supongamos que nuestras bases no son relacionales, entonces tenemos una base para clientes,
otra proveedores, otra factura, etc.. para la gestion de cada una de las areas de la empresa y
seria de forma independiente y no relacionada, esto traeria las siguientes consecuencias:
Si un cliente viene a comprar a la tienda, y le tenemos que hacer la factura, conforme metamos
los productos que ha comprado y las cantidades que se ha llevado, tambien en un papel aparte
tendriamos que apuntar cuales son esos productos y las cantidades, pues al no estar
relacionadas las facturas con los stocks de los productos en el almacen, tendriamos que ir
depues a la base de productos y dar de baja lo que hemos vendido para poder controlar las
cantidades que hay en el almacen.

Al estar relacionadas las facturas con los productos, cuando realizaramos la factura, el programa
de forma automatica daria de baja las cantidades de cada producto del almacen , sin
percatarnos de ello.
Como este ejemplo, se puede aplicar al resto de areas de la empresa, los pedidos, las llegadas
de la mercancia, etc.
Esto conlleva a un aumento de la productividad, superior al 50%, en el tiempo y en la fiabilidad,
no tenemos que acordarnos ni de apuntar, imaginemos que hacemos 10 facturas por minuto,
Como podriamos controlar eso ?
Para la eleccion de uno u otro tipo, hemos visto que es mas que evidente que debe ser
necesariamente una base de datos relacional, indistintamente de que las necesidades de nuestra
empresa actualmente no las necesite, por que es mas facil convertir las bases de datos
simplemente con un campo nuevo que sea el relacional, que tener que cambiar el sistema
completo por que el que compramos no nos lo permite.
Antes de seleccionar uno u otro tipo no piense en el tiempo actual , ni para el proximo ao,
piense en una vida util de esa gestion de datos de como minimo 3 aos y de la explosion
comercial que puede tener la empresa en dicho tiempo, no mire el precio que tenga uno u otro
sistema, a veces lo mas barato no siempre es lo mejor , tampoco es que se compre la mejor y
que dentro de un ao no cumpla las espectativas que se tenian pensadas.
Antes de realizar una compra o contratacion de servicios, vea tipos y caracteristicas que le
ofrecen y sobre todo el soporte tecnico que le ofrezcan, pues a pesar de tener personal
especializado, nosotros incluso, a veces hay errores de fabrica que solo el fabricante o sus
distribuidores podrian solucionar y entonces entraria en efecto el servicio que tuviera el
distribuidor que nos suministro el producto, no podemos tener la empresa parada 5 o 6 dias por
que no hay nadie en el proveedor que sepa arreglar nuestro problema.
Solicite Ofertas de servicios posventa y del producto en si mismo, si es necesario llame al
fabricante del producto y expongale cuales son sus necesidades y si las va a cubrir sus
productos, practicamente todos los fabricantes tienen una estupenda atencion al publico, tanto
como compradores potenciales, usted mismo, como ya clientes una vez comprado el producto.

Ejemplo de caso prctico

En las empresas
Un ejemplo prctico del uso de bases de datos relacionales en las empresas es el uso ms
comn.
En las empresas estn lo que se le denomina cartera de clientes, en dicha cartera se encuentran
los datos personales de los clientes ms habituales y sobre todo los que compran a crdito,
dichos datos personales se encuentran centrados/almacenados en las bases de datos de la
empresa.
Lo normal es que cada dato personal (nombre, apellidos, direccin, etc,,) se encuentran en
campos, un campo es una zona reservada en la base de datos, en la cual solo se almacenan la
parte a la que corresponda, por esto en el campo de nombre, solo se hayaran nombres de los
clientes y no apellidos ni otra cosa, la unin de los campos de cada dato de cada cliente forma el
registro, osea el campo de nombre , apellidos, etc.. de cada cliente forma el registro, osea un
cliente es un registro en la base de datos.
Visto lo anterior supongamos una empresa A con una cartera de clientes y cuya base de datos
contiene los siguientes campos:
Campo

Tamao

Nombre

30

Apellidos

30

Direccin

50

Como puede observar en la tabla puede comprobar que adems del campo se le dan otros
parmetros entre ellos el tamao, para poder saber ms relacionado con el tema, repase el
captulo dedicado a la creacin de tablas, el tamao hace referencia a la cantidad de letras que
permite le sean guardados, osea que si el nombre solo permite 30 de tamao, solo se podrn
guardar nombres de tamao mximo de 30 letras.
Al mismo tiempo la empresa tendr otra base de datos en la cual se almacenarn las facturas de
compra de los clientes en una base de datos que se llame albaranes, en la cual se almacenaran
los datos de los productos que se compren a la vez que se almacena al cliente que haya
comprado dichos productos, dicha referencia sirve para unir de alguna forma los datos de dos
bases de datos distintas y dicha unin se realiza a travs del campo clave.

En la base de datos de albaranes solo estar el cdigo del cliente que ha comprado y no el
nombre, apellidos, etc.. de forma que cuando se busque ese albarn, el cdigo del cliente lo
sacamos de la base de datos del albarn y despus sacamos los dems datos de la base de
datos de los clientes.