CMS modules by everest poker.

BD Relacional

Imprimir
Valoración del Usuario:  / 13
MaloBueno 
Categoría: Teórico-práctico
Escrito por Neckkito

BDRelacional

Si queréis bajaros este artículo en pdf pulsad aquí

 

Access es un gestor de bases de datos relacionales (GBDR). ¿Y qué significa eso?

 

Voy a intentar explicarlo a través de un ejemplo: imaginemos que he nos ha tocado hacer de monitor de un montón de niños en un campamento de verano, y vamos a organizar una excursión.

 

Para tener controlados los niños vamos a hacer grupos (nuestras tablas), y vamos a nombrar un responsable (nuestra clave principal). Al responsable del grupo 1 (Antonio) le vamos a pintar en la frente una línea amarilla. En este grupo ponemos todos los niños cuyo nombre empiece por “A”.

 

El responsable del grupo 2 (Begoña) tendrá una línea pintada de verde en la cara. En ese grupo están todos los niños cuyo nombre empieza por “B”. Además, cada niño lleva una clase diferente de bebida: uno lleva el agua, otro la cola, otro la naranjada...

 

El responsable Antonio del grupo 1 tiene un hermano (Bernardo) que está en el grupo 2. Para “relacionarlos” al hermano de Antonio le pintamos también una línea amarilla.

 

Hasta aquí creo que es fácil seguir el planteamiento, ¿cierto?

 

Compliquemos la cosa: existe un grupo 3, con la línea de color azul, con nombres empezados por “C”, que sabemos que lleva comida: uno patatilla, otro queso, otro jamón...

 

Y, curiosamente, Begoña tiene un hermano (Carlos) en ese tercer grupo, por lo que le pintamos a Carlos una línea verde.

 

¡Y nos vamos todos de excursión!

 

Pues bien, nosotros, que somos muy mañosos, hemos inventado un robot-transportador, para no tener que caminar demasiado. Y cuando llevamos un buen rato andando nuestro amiguito Alfredo se nos acerca y nos dice: “Tengo sed. Quisiera un poco de limonada”.

 

Y aquí es donde nuestro robot entra en acción. Como hemos establecido bien las relaciones podemos hacer que nuestro robot haga el trabajo por nosotros. ¿Qué hará nuestro robot? Pues lo que hará es seguir esas relaciones. Es decir:

 

Alfredo es del grupo 1 -> Amarillo
Las bebidas están en el grupo 2 -> Verde
El robot buscará un niño que lleve pintadas pues las rayas amarillo y verde (Bernardo).
Bernardo le indicará que Beatriz lleva la limonada
Cogerá la limonada de Beatriz y se la llevará a Alfredo.

 

Más complicado: Ana quiere queso. ¿Qué hará nuestro robot?

 

Ana es del grupo 1 -> Amarillo
Las comidas están en el grupo 3 -> Azul
¡Vaya! No hay ningún niño que lleve la cara pintada con líneas amarillas y azules. Pero... tenemos las relaciones, ¿verdad?
Entonces, el robot se irá al grupo 2 -> Verde. Aquí no están las comidas, sigamos.
El robot se irá al grupo 3 y buscará a Carlos, que tiene pintadas las líneas verde y azul.
Carlos le dirá que Camilo lleva el queso.
Cogerá el queso y lo llevará a Ana.

 

¿Qué pasaría si Asunción quiere un sombrero? Pues que nuestro robot no sabrá a qué grupo tiene que ir, porque no hemos establecido una relación, por lo que nuestro robot no tendrá un “hilo conductor” para “extraer” esa información.

 

Si aplicamos lo anterior a Access podríamos obtener algo así:

 

BDRelacional-01


Situémonos en el mundo real. Si queremos ver un poco de teoría podemos echar un vistazo a estos enlaces:

 

http://es.wikipedia.org/wiki/Base_de_datos_relacional

 

http://es.wikipedia.org/wiki/Modelo_relacional

 

Yendo a lo práctico, una de las ventajas es que sólo necesitamos escribir la información que se duplica una sola vez (aunque podría haber excepciones, ojo). Un ejemplo exagerado: si yo quiero capturar las visitas de un paciente a una consulta podría tener una tabla con los siguientes campos:

 

Nombre Paciente
Teléfono
Dirección
Fecha consulta
Motivo consulta

 

Pero cada vez que viniera a la consulta tendría que introducir su nombre y sus datos personales (con el peligro que ello conlleva, porque podría ser que un día introdujera María, otro día “Maria” -sin acento gráfico- y otro día “Mª”). Con el modelo relacional deberíamos crearnos dos tablas y unirlas por un campo inequívoco (que sea único y no pueda repetirse). Por ejemplo, el DNI. En este caso nuestro modelo relacional podría quedar así:

 

BDRelacional-02


Fijémonos en la imagen. ¿Hay algo en ella que os haga pensar que estaremos escribiendo “varias veces lo mismo”?

 

La respuesta es sí, hay dos cosas (según se mire). La primera es que cada vez tendremos que escribir el código postal, la población y la provincia. ¿Y si descomponemos lo anterior para sólo tener que escribir una vez los datos asociados a un código postal?

 

La segunda es un poco relativa, pero supongamos que los motivos de la cita sean unos motivos estándar. También podríamos escribirlos sólo una vez, ¿no?

 

Pues nuestro nuevo modelo nos quedaría así:

BDRelacional-03

 


De esta manera podríamos sacar una estadística de motivos por códigos postales, por poner un ejemplo, porque las tablas están relacionadas, o una estadística de provincias por meses (gracias al campo [FechaCita]), sin tener que preocuparnos si en un registro hemos escrito Madrid y en otro, por error, hemos escrito Madriz (lo que falsearía los resultados).

 

Bueno... Espero que a través de este artículo hayáis entendido un poco mejor qué es esto de GBDR.

 

Un saludo, y...

 

¡suerte!

 

Saturday the 19th. Joomla 2.5 Templates. Neckkito's baby 2012 --- Hosted by: www.siliconproject.com.ar
Copyright 2012

©