Una base de datos o banco de datos es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso. En este sentido, una biblioteca puede considerarse una base de datos compuesta en su mayoría por documentos y textos impresos en papel e indexados para su consulta. Actualmente, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital (electrónico), y por ende se ha desarrollado y se ofrece un amplio rango de soluciones al problema del almacenamiento de datos.
En el contexto de una tabla de base de datos relacional, una columna es un conjunto de valores de datos de un simple tipo particular, uno por cada fila de la tabla. Las columnas proporcionan la estructura según la cual se componen las filas. El término campo es frecuentemente intercambiable con el de columna, aunque muchos consideran más correcto usar el término campo (o valor de campo) para referirse específicamente al simple elemento que existe en la intersección entre una fila y una columna.
un registro (también llamado fila) representa un ítem único de datos implícitamente estructurados en una tabla. En términos simples, una tabla de una base de datos puede imaginarse formada de filas y columnas o campos. Cada fila de una tabla representa un conjunto de datos relacionados, y todas las filas de la misma tabla tienen la misma estructura.Un registro es un conjunto de campos que contienen los datos que pertenecen a una misma repetición de entidad. Se le asigna automáticamente un número consecutivo (número de registro) que en ocasiones es usado como índice aunque lo normal y práctico es asignarle a cada registro un campo clave para su búsqueda.
1:como se abrebia base de datos en ingles?
DBMS
2:cual es un ejemplo de base de datos?
R;un directorio
3:para q som las tablas?
R;son abjetos q pueden almasenar datos
4:q son las consultas?
R;son pantallas o limitasiones q jeneran cn instrucsiones
5:que son los formularios?los formularios son formatos diseñados
6:q es un imforme?
R:permiten crear base cn datos interactivos
7:paguinas son?
R;datos interactivos
8:q es un macro?
R;son un conjunto de macro intrucsiones
9:q es un modulo?
R;son partes del programa escritos
10:como se representan los renglones?
R;con columnas es decir en forma tubular como imformacion financiera
11:q integra la base de datos?
R;solo los q tienen relacion entre sii
12:que resivela imformacin?
R;un nombre de campo
13:cuantos puede guaradar un rejistro?
R;siempre arriba de 2
14:que es memo?
R;son datos numericos que se utilizan para acer reseñas
15:en donde se ocupa access?
R;son usuales en pequeñas empresas
llaves clave es 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.
normalizacion de datos
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.
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.
¿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.
La tercera forma normal
- Elimine los campos que no dependen de la clave.
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.Normalización de una tabla de ejemplo
Estos pasos muestran el proceso de normalización de una tabla de alumnos ficticia.- Tabla sin normalizar: Contraer esta tabla
Nº alumno Asesor Despacho-tut Class1 Clase 2 Clase3 1022 Jones 412 101-07 143-01 159-02 4123 Smith 216 201-01 211-02 214-01 - Primera forma Normal: No hay grupos de repetición
Las tablas deben tener sólo dos dimensiones. Debido a que un alumno tiene varias clases, estas clases deben aparecer en una tabla independiente. Campos Clase1, clase2 y Clase3 de los registros anteriores son indicaciones de problemas de diseño.
Las hojas de cálculo suelen utilizan la tercera dimensión, pero las tablas no se deben. Otra forma de considerar ese problema es con una relación uno a varios, no coloque el uno lado y el lado varios de la misma tabla. En su lugar, cree otra tabla en la primera forma normal eliminando el grupo de repetición (Nº clase), tal como se muestra a continuación:Contraer esta tablaNº alumno Asesor Despacho-tut Nº clase 1022 Jones 412 101-07 1022 Jones 412 143-01 1022 Jones 412 159-02 4123 Smith 216 201-01 4123 Smith 216 211-02 4123 Smith 216 214-01 - La segunda forma Normal: Eliminar datos redundantes
Tenga en cuenta los diversos valores para cada valor de Nº alumno en la tabla anterior. Nº clase no es funcionalmente dependiente de Nº alumno (clave principal), por lo que esta relación no está en la segunda forma normal.
Las dos tablas siguientes muestran la segunda forma normal:A los alumnos
Contraer esta tablaNº alumno Asesor Despacho-tut 1022 Jones 412 4123 Smith 216 Registro
Contraer esta tablaNº alumno Nº clase 1022 101-07 1022 143-01 1022 159-02 4123 201-01 4123 211-02 4123 214-01 - La tercera forma Normal: Eliminar los datos no depende de la clave
En el último ejemplo, despacho-tut (número de la oficina del Asesor) es funcionalmente dependiente del atributo Tutor. La solución es pasar ese atributo de la tabla alumnos a la tabla personal, tal como se muestra a continuación:A los alumnos
Contraer esta tablaNº alumno Asesor 1022 Jones 4123 Smith Profesores
Contraer esta tablaNombre Sala Depart. Jones 412 42 Smith 216 42
No hay comentarios:
Publicar un comentario