base de datos

¿QUE ES UNA CLAVE O LLAVE EN ACCESS?

QUE ES LA CLAVE PRINCIPAL O LLAVE PRINCIPAL EN ACCES
Al ser los registros información sobre los atributos de algo o alguien, para no confundirse entre sí se acostumbra a elegir uno de los campos (o a un conjunto de campos) como la clave primaria. Esta clave primaria es la que permite identificar de manera única e inequívoca un registro. La clave principal no puede contener valores duplicados, ni valores nulos (o en blanco).
Establecer la clave principal o llave principal de una tabla
La clave o llave principal de una tabla, está compuesta por uno o varios campos que identifican en forma única cada registro almacenado.
Se utiliza como clave principal un campo que contenga valores que no se repitan para cada registro, por ejemplo, en la tabla Empleados el campo Núm. de Empleado, es la clave principal de esta tabla.
El uso de clave principal en una tabla trae las siguientes ventajas:
  • Access crea automática mente un índice para el campo clave principal, esto permite acelerar las búsquedas sobre la tabla.
  • Cuando se observen los datos ya sea a través de la Hoja de datos o de un formulario, los registros se mostrarán ordenados según la clave principal.
  • Cuando se adicionen registros, Access no permitirá introducir valores repetidos ni nulos en el campo clave principal, asegurando de esta forma que cada registro sea identificado en forma única.
Se deben ejecutar los siguientes pasos para establecer la clave principal:
1. Hacer click en el campo que se va a establecer como clave principal. Si se va a crear una clave principal de varios campos, se oprime la tecla <CTRL> y haciendo click sobre cada campo se van seleccionando los campos.
2. Por el menú edición, elegir Establecer clave principal (o desde la barra de herramientas hacer click en el botón Establecer clave principal).
Access colocará un indicador de clave, a la izquierda del campo o campos señalados como clave principal.
Cambiar la clave principal
Para cambiar la clave principal de una tabla, se debe:
1. Dar click sobre el campo que se desee establecer como nueva clave principal.
2. Dar click sobre el botón en la barra de herramientas llamado Establecer clave principal.
Automáticamente, Access cambia la marca de clave principal hacia el nuevo campo. Todo este proceso debe ser realizado estando en el modo Presentación Diseño de la tabla.
Eliminar la clave principal
Para eliminar la clave principal, se debe:
1. Estando abierta la tabla en el modo Presentación Diseño, elegir del menú Ver, la opción índices (o en la barra de herramientas, hacer click en el botón índices).
Access mostrará la ventana índices. Si la tabla tiene clave principal, aparecerá en la columna Nombre del índice, el nombre de Clave principal (Primary key).
2. Dar click sobre el selector de fila a la izquierda del nombre del índice, y luego oprimir la tecla <SUPR>.
3. Cerrar la ventana índices, oprimiendo click sobre el botón índices en la barra de herramientas.
Cuando se guarda una tabla, si no se ha definido una clave principal, Access advertirá esta situación y sugerirá que se cree una. Si Access la crea, lo que hará será crear un campo tipo Contador, al cual se le asignará la clave principal. Una tabla puede almacenarse sin clave principal, pero si luego va a ser parte de una relación, ésta no podrá establecerse por la falta de ella.

¿QUE ES UNA NORMALIZACION EN ACCESS?

La normalización es el proceso de organizar los datos en una base de datos. Esto incluye la creación de tablas y el establecimiento de relaciones entre ellas según reglas diseñadas para proteger los datos y hacer que la base de datos más flexible mediante la eliminación de redundancias y dependencias incoherentes. 

Los datos redundantes desperdician espacio en disco y crean problemas de mantenimiento. Si es necesario cambiar los datos que existen en más de un lugar, deben cambiarse los datos exactamente igual en todas las ubicaciones. Un cambio de dirección de cliente es mucho más fácil de implementar si los datos se almacenan únicamente en la tabla de clientes y en ningún otro en la base de datos. 

¿Qué es una "dependencia incoherente"? Aunque es intuitivo para un usuario que busque en la tabla Customers de la dirección de un cliente en particular, no sentido mirar allí el salario del empleado que atiende a dicho cliente. El sueldo del empleado está relacionado con, o es dependiente del empleado y por lo tanto, se debe mover a la tabla Employees. Las dependencias incoherentes pueden dificultar datos a access ya que puede ser la ruta de acceso para encontrar los datos que faltan o están dañados. 

Hay unas cuantas reglas para la normalización de bases de datos. Cada regla se denomina "forma normal". Si se observa la primera regla, la base de datos se dice que en la "primera forma normal". Si se observan las tres primeras reglas, se considera que la base de datos está en la "tercera forma normal". Aunque son posibles otros niveles de normalización, la tercera forma normal se considera el máximo nivel necesario para la mayoría de las aplicaciones. 

Al igual que con muchas reglas y especificaciones formales, situaciones del mundo real no siempre permiten cumplir a la perfección. En general, la normalización requiere tablas adicionales y algunos clientes consideran éste engorroso. Si decide no cumplir alguna de las tres primeras reglas de normalización, asegúrese de que su aplicación anticipa a los problemas que podrían ocurrir, por ejemplo, los datos redundantes y dependencias incoherentes. 

Las descripciones siguientes incluyen ejemplos.

Primera forma normal

  • Eliminar grupos repetidos en tablas individuales.
  • Crear una tabla independiente para cada conjunto de datos relacionados.
  • Identifique cada conjunto de datos relacionados con una clave principal.
No utilice varios campos en una sola tabla para almacenar datos similares. Por ejemplo, para realizar un seguimiento de inventario que puede provenir de dos orígenes posibles, un registro del inventario puede contener campos para el proveedor de código nº 1 y 2 del código de proveedor. 

¿Qué sucede cuando se agrega un tercer proveedor? Agregar un campo no es la respuesta; requiere modificaciones de programa y la tabla y se adapta fácilmente a un número de proveedores dinámico. En su lugar, coloque toda la información de proveedor en una tabla independiente denominada proveedores y, a continuación, vincule el inventario a los proveedores con una clave de número de artículos o proveedores con el inventario con una clave de código de proveedor.

La segunda forma normal

  • Crear tablas independientes para conjuntos de valores que se aplican a varios registros.
  • Relacionar dichas tablas mediante una clave externa.
Registros no deben depender nada que no sea la clave principal de la tabla (una clave compuesta, si es necesario). Por ejemplo, considere la posibilidad de dirección de un cliente en un sistema de contabilidad. Se necesita la dirección de la tabla de clientes, sino también por las tablas pedidos, envíos, facturas, cuentas por cobrar y colecciones. En lugar de almacenar la dirección del cliente como una entrada independiente en cada una de estas tablas, almacénela en un lugar, ya sea en la tabla de clientes o en una tabla de direcciones independiente.

La tercera forma normal

  • Elimine los campos que no dependen de la clave.
Valores de un registro que no forman parte de la clave de ese registro no pertenecen a la tabla. En general, siempre que el contenido de un grupo de campos puede aplicarse a más de un único registro en la tabla, considere la posibilidad de incluir dichos campos en una tabla independiente. 

Por ejemplo, en una tabla de la contratación del empleado, nombre de la universidad y la dirección de un candidato pueden incluirse. Pero necesita una lista completa de universidades para realizar envíos de correo. Si la información de las universidades se almacena en la tabla de candidatos, no existe forma de enumerar las universidades no tengan candidatos.Crear una tabla Universidades separada y vincúlela a la tabla candidatos con una clave de código de universidad. 

EXCEPCIÓN: Adhesión a la tercera forma normal, aunque teóricamente es deseable, no siempre resulta práctico. Si tiene una tabla clientes y desea eliminar todas las posibles dependencias entre los campos, debe crear tablas independientes para ciudades, códigos postales, representantes de ventas, las clases de clientes y cualquier otro factor que se pueden duplicar en varios registros. En teoría, normalización merece la pena. Sin embargo, muchas tablas pequeñas pueden degradar el rendimiento o superar abrir el archivo y capacidades de memoria. 

Puede ser más factible aplicar la tercera forma normal únicamente a los datos que cambian con frecuencia. Si quedan algunos campos dependientes, diseñe la aplicación para solicitar al usuario comprobar que todos los campos relacionados cuando se produzca un cambio.

Otras formas de normalización

Cuarta forma normal, también llamada forma Normal de Boyce Codd (BCNF) y la quinta forma normal existen, pero rara vez se consideran en un diseño. Omisión de estas reglas puede resultar en el diseño de base de datos menos perfecto, pero no debe afectar a la funcionalidad.

No hay comentarios:

Publicar un comentario