1. PROGRAMAS O GESTORES DE BASES DE DATOS
1.1. Un sistema gestor de base de datos (SGBD) es un conjunto de programas que permiten el almacenamiento, modificación y extracción de la información en una base de datos, además de proporcionar herramientas para añadir, borrar, modificar y analizar los datos. Los usuarios pueden acceder a la información usando herramientas específicas de interrogación y de generación de informes, o bien mediante aplicaciones al efecto Tereta Hueco Estos sistemas también proporcionan métodos para mantener la integridad de los datos, para administrar el acceso de usuarios a los datos y para recuperar la información si el sistema se corrompe. Permiten presentar la información de la base de datos en variados formatos. La mayoría incluyen un generador de informes. También pueden incluir un módulo gráfico que permita presentar la información con gráficos y tablas.
2. Relación de varios a varios (n,m). En este caso, ninguno de los campos relacionados son claves principales. Cada registro de la primera tabla puede estar enlazado con varios registros de la segunda y viceversa. Este tipo de relación implica la repetición de los campos de cada tabla; esto es lo que Access pretende evitar. Para establecer relaciones de este tipo, es necesario crear una tabla intermedia que esté relacionada con las dos de uno a varios.
3. DIAGRAMA ENTIDAD RELACION
3.1. Destinations
3.2. Un diagrama o modelo entidad-relació es una herramienta para el modelado de datos que permite representar las entidades relevantes de un sistema de información así como sus interrelaciones y propiedades.
3.2.1. ENTIDADES: Representa una “cosa” u "objeto" del mundo real con existencia independiente, es decir, se diferencia únicamente de otro objeto o cosa, incluso siendo del mismo tipo, o una misma entidad. Algunos Ejemplos: Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos). Un automóvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrán atributos diferentes, por ejemplo, el número de chasis). Una casa (Aunque sea exactamente igual a otra, aún se diferenciará en su dirección). Una entidad puede ser un objeto con existencia física como: una persona, un animal, una casa, etc. (entidad concreta); o un objeto con existencia conceptual como: un puesto de trabajo, una asignatura de clases, un nombre, etc. (entidad abstracta). Una entidad está descrita y se representa por sus características o atributos. Por ejemplo, la entidad Persona las características: Nombre, Apellido, Género, Estatura, Peso, Fecha de nacimiento
3.2.2. ATRIBUTOS :Los atributos son las características que definen o identifican a una entidad. Estas pueden ser muchas, y el diseñador solo utiliza o implementa las que considere más relevantes. En un conjunto de entidades del mismo tipo, cada entidad tiene valores específicos asignados para cada uno de sus atributos, de esta forma, es posible su identificación unívoca. Ejemplos: A la colección de entidades «alumnos», con el siguiente conjunto de atributos en común, (id, nombre, edad, semestre), pertenecen las entidades: (1, Sofía, 38 años, 2) (2, Josefa, 19 años, 5) (3, Carlos, 20 años, 2)
3.2.3. RELACIONES Describe cierta dependencia entre entidades o permite la asociación de las mismas. Por ejemplo: Si tenemos dos entidades, CLIENTE y HABITACIÓN, podemos entender la relación entre ambas al tomar un caso concreto (ocurrencia) de cada una de ellas. Entonces, podríamos tener la ocurrencia Habitación 502, de la entidad HABITACIÓN y la ocurrencia Henry Johnson McFly Bogard, de la entidad CLIENTE, entre las que es posible relacionar que la habitación 502 se encuentra ocupada por el huésped de nombre Henry Johnson McFly Bogar
4. se icnifica una coleccion organizada de datos de los sistemas como un componente son cruciales para el funcionamiento diario
4.1. 1* datos cientificos 2* datos comerciales
5. REGLAS DE NORMALIZACION
5.1. Existen 3 niveles de Normalización que deben respetarse para poder decir que nuestra Base de Datos, se encuentra NORMALIZADA, es decir, que cumple con los requisitos naturales para funcionar optimamente y no perjudicar las Performance por mala arquitectura.Estas 3 reglas de Normalización se las conoce como las 3 FORMAS NORMALES.
5.1.1. La Primera Forma Normal Esta primera Forma Normal, nos lleva a no repetir datos en nuestras tablas. Los famosos maestro – detalle, deben aplicarse a la estructura de la tabla.Si nuestra tabla de ventas repite una y otra vez (por cada venta) , el nombre, el domicilio y otros datos del Cliente, es que no hemos aplicado esta Normalizaciòn.Si tenemos una tabla clientes, en la tabla ventas, solo deberia figurar el codigo del cliente, para que el resto de los datos se puedan referenciar automaticamente sin problemas y sin duplicar información.Lo mismo ocurriria en una tabla de detalle de ventas, si por cada item vendido colocamos el detalle del producto, con su descripción , medidas, etc…Tendriamos un desaprovechamiento de espacio y recursos muy grande. Para ello, tendremos nuestra tabla maestra de Productos y con solo grabar el código de dicho producto en nuestra tabla de ventas, será suficiente.
5.1.2. La Segunda Forma Normal (Si o si debe estar previamente aplicada la Primera Forma Normal) La Segunda Forma Normal nos habla de que cada columna de la tabla debe depender de la clave.Esto significa que todo un registro debe depender únicamente de la clave principal, si tuvieramos alguna columna que se repite a lo largo de todos los registros, dichos datos deberian atomizarse en una nueva tabla.Veamos un ejemplo VentaID ItemID FechaVenta ClienteVenta ProductoId Cantidad 1 1 01/12/2007 2 2334 10 1 2 01/12/2007 2 3333 2 1 3 01/12/2007 2 66643 34 1 4 01/12/2007 2 21 3 2 1 02/12/2007 5 3566 6
5.1.3. La Segunda Forma Normal (Si o si debe estar previamente aplicada la Primera Forma Normal) La Segunda Forma Normal nos habla de que cada columna de la tabla debe depender de la clave.Esto significa que todo un registro debe depender únicamente de la clave principal, si tuvieramos alguna columna que se repite a lo largo de todos los registros, dichos datos deberian atomizarse en una nueva tabla.Veamos un ejemplo VentaID ItemID FechaVenta ClienteVenta ProductoId Cantidad 1 1 01/12/2007 2 2334 10 1 2 01/12/2007 2 3333 2 1 3 01/12/2007 2 66643 34 1 4 01/12/2007 2 21 3 2 1 02/12/2007 5 3566 6
6. TIPO DE RELACIONES
6.1. Existen relaciones de diferentes tipos. El tipo de relación que utiliza Access al unir dos tablas dependerá de cómo estén definidos los campos relacionados.
6.1.1. Relación de uno a varios (1,n). Se crea una relación de uno a varios si uno de los campos relacionados es una clave principal. Esta relación es la más común. Cada registro de una tabla puede estar enlazado con varios registros de una segunda tabla, pero cada registro de la segunda sólo puede estar enlazado con un único registro de la primera.
6.1.2. Relación de uno a uno (1,1). Se creará una relación de este tipo si ambos campos relacionados son claves principales. En este tipo de relación, un registro de la tabla uno sólo puede estar relacionado con un único registro de la tabla dos y viceversa. No es muy usada.