Test de Base de Datos

Descarga la siguiente base de datos y realiza el test propuesto a continuación.

• Raul.xlsx

 

Relaciones

En Access 2003 accedemos mediante el menú: Herramientas, Relaciones.

La relaciones son:

1. Uno a uno
2. Uno a varios
3. Varios a varios

Ejemplos de relaciones:

1. Uno a uno. 1:1 Por ejemplo entre la tabla Ventas y la tabla Detalle_ventas.
2. Uno a varios. 1:∞   
3. Varios a varios. ∞:∞  

Diferencias entre Access y Excel

• Access es multiusuario, Excel no.
• Access es un gestor de bases de datos relacionales, Excel no.
• Access soporta más de 65.536 registros (filas), Excel no.
• Salvo la nueva versión de Excel que salió el 30 de enero del 2007, que ya soporta un millón de filas.
• Por el contrario, Excel es mucho más intuitivo, y para cálculos estadísticos o de carácter general es mucho mejor que Access.
• Además Excel genera gráficos con sencillez.

Componentes de una Base de Datos en Access

En Access, una base de datos no es simplemente una tabla, ni siquiera un conjunto de tablas relacionadas entre si. Cuando hablamos de Base de Datos incluimos:

1. Las Tablas y sus relaciones
2. Las Consultas extraen información de una o varias tablas utilizando filtros en forma de fórmula. Por ejemplo, Ciudad="Sevilla". Además existen otro tipo de consultas que permiten modificar información de las tablas.
3. Los Formularios permiten alimentar de información las tablas, presentando al usuario una forma más adecuada para la introducción de los datos. En un formulario se pueden incluir los datos de más de una tabla de forma simultánea.
4. Los Informes nos permiten obtener presentaciones de los datos contenidos en las tablas con un formato personalizable. Dan lugar a documentos impresos en papel, en PDF o presentaciones en pantalla.
5. Páginas Web. En compañía del lenguaje de programación ASP o ASP.NET de Microsoft permiten crear aplicaciones web dinámicas, que interactúan con el usuario que navega por ellas.
6. Macos y módulos. Permiten la automatización de procedimientos.

Gestión de Base de Datos

1. Añadir información. Introducir nuevos registros en una tabla.
2. Modificar la información de una tabla. Es lo que se conoce como 'Editar'. Por ejemplo, cuando un proveedor cambia de teléfono.
3. Eliminar la información. Por ejemplo, cuando una línea aérea suprime un vuelo.
4. Buscar datos. Por ejemplo, necesitamos localizar la persona de contacto que tiene cierta empresa en la ciudad de Caracas.
5. Ordenar los registros de una tabla por ciertos criterios.
6. Copiar una base de datos en otra, para hacer una copia de seguridad.
7. Consultar. Esta una de las opciones más importantes ya que una base de datos se quiere fundamentalmente para luego poder localizar información. Por ejemplo, necesitamos conocer el teléfono de todos nuestros proveedores que el año pasado facturaron más de cierto importe, y que sean de Valencia.
8. Calcular ciertos valores. Una base de datos no es una hoja de cálculo pero permite efectuar cálculos sobre la información que contiene. Por ejemplo, necesitamos conocer los kilómetros recorridos por nuestra flota de camiones durante los últimos 3 meses.
9. Imprimir los datos de las tablas con cierto formato que nosotros definimos.

Conceptos básicos de Bases de Datos

Una base de datos se puede definir como un conjunto de información organizada. Los datos se han de almacenar guardando cierta estructura que luego nos permita su manejo.

Una tabla es una base de datos simple o base de datos plana.

La tabla de una base de datos tiene su propia terminología. Las filas se denominan registros y las columnas campos. La intersección de una fila y una columna recibe la denominación de dato o elemento de la tabla.

Bases de Datos Relacionales

Si intentamos tener toda la información en una única tabla lo más probable es que estemos repitiendo información, y es síntoma de que necesitamos más de una tabla que se encuentren relacionadas entre si.

El hecho de disponer de una única tabla tiene varios inconvenientes:

1. Repetición de la información
2. Dificultad en actualizar ciertos dato
3. No existe ficha de un elemento sin transacción

Vamos a considerar un ejemplo de una única tabla con información repetida.

Supongamos que somos una librería que anota en un tabla las ventas que realiza. Por cada venta realizada anotamos en una única tabla los siguientes campos:

• ISBN
• Titulo
• Autor
• Editorial
• Dirección editorial
• Código cliente
• Nombre cliente
• Dirección cliente
• Fecha venta

Repetición de la información

El hecho de disponer de una única tabla con estos campos supone que tendremos información repetida de dos tipos:

1. Si un cliente compra varios libros anotaremos un registro (una fila) por cada libro que adquiera, y esto hará que el campo 'Dirección cliente' se encuentre repetido, tantas veces como libros hubiera comprado.
2. Puesto que podemos vender varios títulos distintos de una misma editorial la dirección de la editorial se repetirá tantas veces como se venda un libro de esa editorial.

Esto sugiere que sería conveniente disponer de cuatro tablas:

• Libro. Esta tabla contiene información sobre los diferentes libros que tenemos a la venta: Titulo, Autor, ISBN, Editorial, Precio, ...
• Editorial. Esta tabla contiene información sobre la Editorial: Nombre, Dirección, Teléfono, ....
• Cliente: Esta tabla contiene información sobre los clientes: Nombre, Dirección, ...
• Ventas: Esta tabla contiene información sobre cada libro vendido en la librería: Fecha, ISBN, Cliente, Descuento, ...

Dificultad en actualizar ciertos datos

Por otro lado, existe una gran dificultad al modificar ciertos datos, como por ejemplo, la dirección del cliente,  ya que en una única tabla la dirección figura repetida tantas veces como libros hubiera adquirido ese cliente. Tendríamos que modificar la dirección de ese cliente en todos los registros (filas) donde aparece. Si se nos olvida modificar la dirección en algún registro el cliente en cuestión figurará en la base de datos con dos direcciones distintas, y esto compromete la consistencia de los datos, la fiabilidad de la información que manejamos.

No existe ficha de un elemento sin transacción

No podemos dar de alta los datos de una editorial nueva (nombre, dirección,...) hasta que no realicemos la venta de algún libro de esa editorial.

Extensiones de los ficheros

En Access 2003 y anteriores la extensión de los ficheros de base de datos era .MDB. Ahora con Excel 2007 la nueva extensión es ACCDB, que la identifica como base de datos de la nueva versión de Access.

• MDB (Microsoft Data Base)
• ACCDB (Access Data Base)

Antiguamente, incluso antes de que Access triunfara en el mundo de las bases de datos de oficina, existía una extensión DBF (Data Base File) que se utilizaba en otros programas de base de datos (el histórico dBase) que Access puede leer perfectamente.

Como siempre sucede las versiones nuevas leen todo lo antiguo, pero al contrario no se cumple, las versiones viejas normalmente no leen los nuevos formatos, salvo que exista algún complemento que permita esto. Aunque están disponibles múltiples programas que permiten la conversión entre formatos.

Relaciones entre tablas

Es fundamental diseñar bien la base de datos. Lo más importante es:

1. Definir bien las tablas y sus campos
2. Determinar los campos clave para relacionar las tablas. Pedir integridad relacional.
3. Establecer el tipo de relación entre tablas:
• Uno a uno
• Uno a varios
• Varios a varios

Relación uno a uno

Si la relacion entre dos entidades es uno a uno, en Access generamos dos tablas que tienen que tener las claves principales del mismo tipo y con los mismos datos. Ambas tablas se relacionaran por sus claves principales.

Por ejemplo, imagina que tienes dos entidades que son datos personales y datos profesionales. En una tabla pones los datos personales con el DNI como clave principal. En la otra tabla, con el DNI como clave principal, pones los datos profesionales. Después estableces una relación uno a uno entre ambas claves principales.

En el caso de dos tablas relacionadas mediante una relación uno a uno se podría convertir en una única tabla. Según el ejemplo anterior, podríamos tener en una única tabla los datos personales y profesionales. Por cada DNI podríamos tener en un mismo registro (una misma fila) todos los datos de esa persona. En muchos casos se aconseja separar en dos o más tablas los datos, estableciendo diferentes entidades.

Veamos otro motivo por el que se pueda establecer una relación uno a uno entre dos tablas. Supongamos que el departamento de personal de una compañía observa que aproximadamente el 5% del personal es extranjero. En ese caso nos interesaría ampliar la información personal del trabajador recogiendo por ejemplo, el país de origen, los permisos de que dispone, si su carnet de conducir está convalidado, si su titulación está convalidada, entre otros muchos aspectos. En este caso, si utilizamos una única tabla estaría llena de muchas celdas vacías para el 95% de los empleados, por lo que es aconsejable crear una nueva tabla denominada tabla Extranjeros en la que únicamente figuren ese 5% del personal.

Ambas tablas, la tabla Personal y la tabla Extranjeros, podrían relacionarse por el mismo campo principal, por ejemplo el Id. Personal, que es el número de registro personal que tienen todas las empresas. O bien, podría utilizarse otro sistema al no utilizar en ambas tablas el mismo campo principal. Por ejemplo, en la tabla de Personal utilizamos como campo principal el Id. Personal (que es el número de registro personal), conteniendo esta tabla el campo DNI para los trabajadores nacionales y NIE para los extranjeros. En la tabla Extranjeros podría figurar el NIE como clave principal, y así podríamos establecer la relación uno a uno entre Id. Personal (de la tabla Personal) y NIE (de la tabla Extrajeros).


Relación uno a varios

Si la relación entre dos entidades es uno a varios, por ejemplo clientes y facturas, en Access generamos dos tablas. Además, la clave principal de la tabla del lado uno (clientes) hay que ponerla como clave externa (un campo más) en la tabla del lado varios (facturas). La clave principal de la tabla del lado uno ha de estar relacionada con la clave externa de la tabla del lado varios.

Otro ejemplo, puede ser el de la relación entre las tablas Proveedores y Productos de una base de datos de Pedidos. Un proveedor puede proporcionarnos un gran número de productos, siendo esta una relación uno a varios. Por cada proveedor de la tabla de Proveedores podemos tener varios productos en la tabla de Productos. Para establecer la relación en Access deberíamos arrastrar el campo clave de la tabla de Proveedores [Id. Proveedor] hacía la tabla Productos. Esto es, hemos de llevar la clave principal del lado uno hasta la tabla del lado varios de la relación, convirtiéndola en una columna adicional.

La columna Id. de proveedor de la tabla Productos se denomina clave externa. Una clave externa es la clave principal de otra tabla. La columna Id. de proveedor de la tabla Productos en una clave externa porque también es la clave principal en la tabla Proveedores.


Relación varios a varios

Si la relacion entre dos entidades es varios a varios, en access generamos una tabla para cada entidad, y una nueva tabla en la que como mínimo tenemos que tener dos campos como claves externas, donde pondremos los datos de las claves principales de cada una de las dos tablas primeras. Cada una de las dos tablas primeras estara relacionada con la tercera tabla con una relación uno a varios.

Por ejemplo, la relación entre la tabla Productos y la tabla Pedidos. Un producto puede aparecer en varios pedidos, y por otro lado, un pedido puede componerse de varios productos. En este caso estamos en una relación varios a varios ya que un pedido puede tener varios productos y un producto puede estar en varios pedidos. Para establecer esta relación en Access necesitamos una tercera tabla interpuesta entre las dos anteriores a la que arrastramos la clave principal de cada una de las dos tablas Productos y Pedidos, estableciendo una relación uno a varios entre ellas y esta tercera tabla. Esta tercera tabla la podríamos denominar tabla Detalles de pedido, y en ella figurará el Id. Producto y el Id. Pedido, además de los detalles de cada línea del pedido por ejemplo, precio unitario, cantidad, descuento.

Cuando existe una relación de uno a uno o de uno a varios, las tablas implicadas deben compartir una o varias columnas comunes. Cuando la relación es de varios a varios, se necesita una tercera tabla para establecer la relación.