2. Pròlogo

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 relaciòn entre ellas o bien por la necesaria relaciòn de datos entre dichas bases.

Para hacerlo más fàcil , haremos una comparaciòn muy sencilla, supongamos una tienda de productos de alimentaciòn , 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 informaciòn se fue guardando en dichos ordenadores, y entonces tenemos por ejemplo productos que vendemos al público y a su vez tenemos proveedores que nos venden a nosotros.

Dado lo anterior tenemos por ejemplo 40 o 50 o incluso màs productos que vienen de un mismo proveedor, por lo que en realidad ya existe una clara relación entre los productos y el proveedor que nos los vende, pero como hacemos èsta relaciòn 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 actuación y utilidad de la bases de datos relacionales es la gestiòn , tambièn podrìamos si fuera necesario adaptarlo a nuetras propias necesidades.

En los siguientes capìtulos usted aprenderà como son y que son las bases de datos y las posibles relaciones entre ellas.

Le aconsejo que preste atenciòn a los primeros capìtulos, pues son la base de todo el curso y por lo tanto, necesarios para comprender los detalles tècnicos que posteriormente se le iran detallando.

3. Las Bases de Datos

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

En dicho fichero la informaciòn 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 nùmero de campos que podemos tener en una base varía según las necesidades que tengamos en cuanto a separación de datos, de forma que despuès podamos sacar la informaciòn de forma ordenada y separada, aunque el resto de la informaciòn 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 nùmeros o incluso otros datos màs 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 , tambièn 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 estàn separadas, aunque estèn 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 , aùn siendo el tipo de base elegida de cualquier forma o relaciòn.

4. El diseño

El diseño de las bases de datos para relacionar datos, es muy importante, pero debemos tener en cuenta que quizàs 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 quizàs 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 pròximos capìtulos solo usarè el tèrmino 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 còdigo, 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 relaciòn entre dichas bases(tablas) mediante un campo que las relacione.

5. Los Campos Clave

En el capìtulo anterior vimos la necesidad de crear la relaciòn entre distintas bases de datos. Para dicha relaciòn hemos creado un campo comùn 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 relación entre distintas bases(tablas).

Un ejemplo claro es un producto que ademàs de tener el campo clave para identificar al proveedor que lo suministra, ademàs tendremos otro campo clave que identifique las caracteristicas tècnicas 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 caracterìsticas 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 estàn embalados, para esto hacemos la relaciòn 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 caracterìsticas 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 caracterìsticas, el ahorro està en dicho espacio desperdiciado en el fichero y por lo tanto el fichero serà màs grande y por lo tanto su uso màs lento.

Es entonces cuando vemos la necesidad de usar bases de datos(tablas) relacionales.

6. Creación de Tablas

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 creaciòn 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, Numèrico, Boolean, Decimal y otros, que dependerà del gestor con el cual creamos la tabla, asi mismo tambièn se nos darà la posibilidad de definir los decimales para los campos nùmericos 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 màs que el orden que establecemos para dicho campo, con esto conseguimos aumentar la velocidad de bùsqueda 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 direcciòn de 300 amigos y queremos buscar a Pepe TOLO TOLO, si no tenermos indices en la base de datos , tendrìamos 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 demàs 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 teléfono 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 , màs efectivo serà el sistema de ahorro en tiempo.

En la actualidad , como ya hemos mencionado en capìtulos 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 relaciòn entre dichas tablas.

7. La Relación Funcional

La dependencia funcional en una base de datos, es aquella que determina la relación que hay entre las bases de datos que usan de modo conjunto una relación de datos.

Para averiguar la dependencia existente entre bases de datos, debemos analizar las propiedades de los campos, para así averiguar cual es la relación existente entre las bases y que tipo de relación hay entre ellas.

Debemos tener en cuenta que cuando vayamos a realizar una relación entre bases, aquellos campos que hemos seleccionado para que sean los campos clave, que serán los que realizen el enlace entre bases, deben ser del mismos tipo, por ejemplo que usemos tipos númericos, los dos campos en las bases deben ser númericos, 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 dirección y el dni, y en otra guardaremos a la hora que nos han hecho el pedido.

En enlace entre ellas, será evidentemente por el número del dni.

Al crear las bases será así:

Clientes.dbf

Campo Tipo Longuitud

Nombre Caracter 40

Dirección Caracter 40

DNI Númerico 10

Pedidos.dbf

Hora Caracter 5

DNI Numerico 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 númerico.

Si por cualquier motivo, el tipo debiera de ser caracter u otro distinto, en la otra base deberá de ser del mismo tipo.

8. Las Bases mas Usadas

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.

El mercado encontraremos 3 tendecias mas acuciadas, aunque como he dicho existen muchos tipos,

- La dbf , de DBASE(c) , que practicamente todos conoceremos.

- La Mdb de Microsoft(c) , que es la que utiliza el Access(c) y otros productos de dicha compañia.

- La Oracle, que aunque aqui en España 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(c) pero es igual a la dbf, no presenta ningun incoveniente.

Para usar la DBF es necesario tener una de las versiones de DBASE(c), 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(c), 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.

8. El uso para la empresa

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 año, piense en una vida util de esa gestion de datos de como minimo 3 años 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 año 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.