1. INTRODUCCIÓN
l análisis es la etapa fundamental y más difícil en la confección de una buena base de datos.
Un buen análisis asegura disponer de una buena base de datos, pero desgraciadamente también ocurre al contrario y un pobre análisis es garantía de tener muchos problemas con la base de datos que finalmente se diseñe.
Sin embargo, una vez realizado el análisis, el resto es más sencillo, ya que simplemente tendremos que aplicar una serie de reglas que nos permita "trasladar" el modelo Entidad-Relación que hemos conseguido a una estructura de base de datos.
Es por ello que ahora empieza la etapa de diseño de la base de datos. En ella vamos a generar el conjunto de tablas y relaciones que después crearemos en Access.
2. LAS TABLAS
ccess es una base de datos relacional, lo que quiere decir que toda la información se representa únicamente con dos tipos de objetos: tablas y relaciones.
De forma adicional, sabemos que en Access podremos crear consultas, formularios, informes, etc., pero esos objetos no representan la información de la base de datos, sino que sirven para determinados objetivos: obtener resultados, introducir información, visualizar o imprimir información...
E
Pues bien, una vez tenemos el modelo Entidad - Relación, debemos convertir cada una de las entidades que allí aparecen en una tabla de la base de datos de Access. Así de directo: una tabla por cada entidad.
Además, sabemos que las tablas se constituyen como conjuntos de
campos, que representan las categorías de la información que queremos almacenar. Pues esos campos son los atributos que hemos establecido en el modelo Entidad - Relación, más alguno que podamos añadir durante esta fase de diseño.
Así pues, tendremos por ahora las siguientes tablas: Proveedores.
Libros. Temas. Ventas.
Y cada una de ellas tendrá los campos que hemos establecido en el
modelo Entidad - Relación. El nombre no tiene por qué coincidir. Proveedores: CódigoEditorial, NombreEditorial, PersonaContacto,
Dirección, Ciudad, Provincia, NúmTeléfono y NúmFax. Libros: CódigoLibro, Título, Precio y Existencias. Temas: CódigoTema y NombreTema.
Ventas: CódigoVenta, Fecha y Precio.
Observa que aparece un campo Precio tanto en la tabla Libros
Esto nos permite tener en la tabla Libros el precio de cada libro y cambiarlo cuando así lo deseemos. Por otra parte, al hacer una venta, se asigna el precio actual del libro, con lo que tendremos cada venta, aunque sea del mismo libro, con el precio real al que se vendió.
En las tablas se almacenará la información en forma de registros. Por ejemplo, en el caso de la tabla Proveedores, tendremos un registro por cada proveedor. Lo mismo para la tabla Libros, Temas y Ventas.
Por ello es muy importante que podamos distinguir claramente entre uno y otro registro; es decir, que no pueda haber dos iguales.
Para ello se utiliza un determinado campo o conjunto de campos, cuyo valor no puede repetirse en los registros. En nuestra base de datos todas las tablas disponen de un campo que tiene esta función:
CódigoEditorial, CódigoLibro, CódigoTema, CódigoVenta. Estos campos se conocen como clave principal de la tabla.
Como puedes ver, el conjunto de tablas aparece de forma inmediata si tenemos el modelo Entidad - Relación.
3. LAS RELACIONES
e forma parecida conseguiremos las relaciones en la base de datos a partir del modelo Entidad - Relación, aunque ahora veremos que el proceso será distinto si se trata de relaciones 1 a muchos o muchos a muchos.
En una relación 1 a muchos entre las entidades A y B tenemos que un elemento de A se puede relacionar con muchos (incluso con ninguno) elementos de B, pero que un elemento de B sólo se puede relacionar con uno de A.
¿Esto qué quiere decir realmente? Pongámonos en el caso de la relación entre los proveedores y los libros.
En este caso, un proveedor puede suministrar muchos libros, pero un libro sólo puede haber sido suministrado por un determinado proveedor.
Esto se representa en la base de datos añadiendo un campo más en la tabla de la parte muchos de la relación. Este campo se corresponderá con el campo clave principal de la tabla de la parte 1.
Por lo tanto, añadiremos el campo CódigoEditorial en la tabla
Libros.
D
Una relación 1 a muchos también se suele represen-tar como 1:N. En ocasiones, entre losatribu-tos que hemos establecido durante la fase de análisis no encontramos ninguno que nos sirva como clave principal. No pasa nada, simplemente añadiremos uno para ello, que, normal-mente, tiene el nombre Código.
Así, en un registro de la tabla Libros, tendremos todos sus detalles, pero además, el código del proveedor que lo ha suministrado, que deberá existir en la tabla Proveedores.
En el caso de la relación entre Libros y Ventas haremos lo mismo, añadiendo el campo CódigoLibro en la tabla Ventas.
En una relación muchos a muchos entre las entidades A y B
tenemos que un elemento de A se puede relacionar con muchos (incluso con ninguno) elementos de B y viceversa.
En el caso de la relación entre Libros y Temas lo vemos claramente, ya que un libro puede tratar muchos temas y, desde luego, un mismo tema puede ser estudiado en varios libros.
Pues bien, este tipo de relación no se puede trasladar directamente a la base de datos relacional, sino que hay que seguir estos pasos:
1. Crear una tabla adicional que represente la relación. Entre los campos de la nueva tabla estarán los campos clave de cada una de las tablas relacionadas.
2. Añadir cualquier otro campo adicional que aparezca como atributo de la relación en el modelo Entidad - Relación.
3. Establecer como clave de la nueva tabla el conjunto de campos clave de las tablas relacionadas más, si es necesario, algún campo adicional.
4. Crear una relación 1 a muchos entre la nueva tabla (parte muchos) y cada una de las tablas relacionadas (parte 1).
En nuestro ejemplo, crearemos una tabla llamada Libros/Temas, con los campos CódigoLibro y CódigoTema y cuya clave sea justamente el conjunto de estos dos campos.
Con esto habremos finalizado el diseño de la base de datos.
Observa el conjunto de tablas y relaciones que conformarán nuestra base de datos de Access. Aquí el símbolo (infinito) representa la parte muchos de una relación.
Fíjate que la incorporación de las relaciones que identificamos durante el análisis ha hecho que aparezcan nuevos campos en las tablas de la base de datos e incluso que hayamos tenido que añadir una tabla nueva.
La cuestión es que a partir del modelo Entidad - Relación
obtenido durante la etapa del análisis hemos conseguido el conjunto de tablas necesario sin más que aplicar unas cuantas reglas que no tienen ninguna dificultad con un poco de experiencia, aunque ahora te pueda parecer un poco difícil.
4. CONCLUSIÓN
omo conclusión a estas dos lecciones, que son muy diferentes a las del resto del curso porque no hemos visto para nada Access, tenemos que es realmente importante la fase de análisis de la base de datos, ya que determina el resto.
Durante el análisis, se identifica lo que después va a diseñarse como un conjunto de tablas y relaciones que crearemos en Access.
Vemos que el diseño es casi inmediato: sólo hay que aplicar unas cuantas reglas y partir de un buen modelo Entidad - Relación.
Ten en cuenta que todo esto sólo te servirá si eres tú el responsable de crear la base de datos. En otros casos eso no será así, sino que sólo necesitarás conocer Access para trabajar correctamente con él.
Si este último es tu caso, estas lecciones también serán de utilidad para ti porque ahora puedes entender mejor el conjunto de tablas y relaciones que otros han diseñado en la base de datos con la que trabajarás.
