UNIVERSIDAD TÉCNICA ESTATAL DE QUEVEDO UNIDAD DE ESTUDIOS A DISTANCIA U.E.D.
MODALIDAD SEMIPRESENCIAL
QUINTO SEMESTRE CARRERA ING. EN SISTEMAS PARALELO V
TEMA: RESUMEN DE ACCESS
AUTOR: MONTOYA NAVARRETE CESAR ANTONIO
TUTOR: ING. RICARDO AGUIRRE PEREZ
AÑO LECTIVO: 2014 – 2015
BASES DE DATOS NORMALIZACIÓN
Elección del software
de gestión de bases de datos: Es elegir el
software que vamos a utilizar para la creación de nuestra Base de Datos.
SGBD Sistema de Gestión de Base de Datos
Sistemas de gestión de bases de datos (en inglés database management system, abreviado DBMS) o SGBD son un tipo de software muy específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. Permiten describir los elementos de datos con su estructura, sus interrelaciones y sus validaciones. Propósito El propósito general de los sistemas de gestión de bases de datos es el de manejar de manera clara, sencilla y ordenada un conjunto de datos que posteriormente
se
convertirán
en
información
relevante
para
una
organización.
Objetivos
Existen distintos objetivos que deben cumplir los SGBD: Abstracción de la información. Los SGBD ahorran a los usuarios detalles acerca del almacenamiento físico de los datos. Da lo mismo si una base de datos ocupa uno o cientos de archivos, este hecho se hace transparente al usuario. Así, se definen varios niveles de abstracción. Independencia. La independencia de los datos consiste en la capacidad de modificar el esquema (físico o lógico) de una base de datos sin tener que realizar cambios en las aplicaciones que se sirven de ella. Consistencia. En aquellos casos en los que no se ha logrado eliminar la redundancia, será necesario vigilar que aquella información que
aparece repetida se actualice de forma coherente, es decir, que todos los datos repetidos se actualicen de forma simultánea. Por otra parte, la base de datos representa una realidad determinada que tiene determinadas condiciones, por ejemplo que los menores de edad no pueden tener licencia de conducir. El sistema no debería aceptar datos de un conductor menor de edad. En los SGBD existen herramientas que facilitan la programación de este tipo de condiciones. Seguridad. La información almacenada en una base de datos puede llegar a tener un gran valor. Los SGBD deben garantizar que esta información se encuentra segura de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categorías de permisos. Manejo de transacciones. Una transacción es un programa que se ejecuta como una sola operación. Esto quiere decir que luego de una ejecución en la que se produce una falla es el mismo que se obtendría si el programa no se hubiera ejecutado. Los SGBD proveen mecanismos para programar las modificaciones de los datos de una forma mucho más simple que si no se dispusiera de ellos. Tiempo de respuesta. Lógicamente, es deseable minimizar el tiempo que el SGBD demora en proporcionar la información solicitada y en almacenar los cambios realizados.
Ventajas
Proveen facilidades para la manipulación de grandes volúmenes de datos (ver objetivos). Entre éstas: Simplifican la programación de equipos de consistencia. Manejando las políticas de respaldo adecuadas, garantizan que los cambios de la base serán siempre consistentes sin importar si hay errores correctamente, etc. Organizan los datos con un impacto mínimo en el código de los programas.
Autor César Montoya
Página 3
Disminuyen drásticamente los tiempos de desarrollo y aumentan la calidad del sistema desarrollado si son bien explotados por los desarrolladores. Usualmente, proveen interfaces y lenguajes de consulta que simplifican la recuperación de los datos.
Debemos tener en cuenta los siguientes factores de base de datos:
Factores técnicos de una base de datos:
Fiabilidad: Que tanta garantía cuenta es decir que tal funciona, que tal les ha parecido a las personas que han hecho uso de la base de datos. Recuperación – fallos: El sistema debe estar preparado para recuperarse no sólo de fallas puramente locales, como la aparición de una condición de desborde dentro de una transacción, sino también de fallas globales, como podría ser la interrupción del suministro eléctrico al CPU.
Las fallas locales son las que afectan sólo a la transacción en donde ocurrió. Por el contrario las fallas globales, afectan a varias -y casi siempre a todas- las transacciones que se estaban efectuando en el momento de la falla, por lo cual tienen implicación es importante en el sistema.
Seguridad: que tanta seguridad brinda, en cuanto al acceso de terceras personas al sistema.
Capacidad: Que capacidad de almacenamiento tiene la base de datos.
Herramientas: Son con la que cuenta en software donde se va a desarrollar la Base de Datos. Como sabemos en Access contamos con muchas herramientas y fáciles de usar al momento de crea nuestra Base de Datos.
Factores no técnicos de una base de datos:
Autor César Montoya
Página 4
Costo del software (licencias): Hay que tener en cuenta este factor ya que se pone en riesgo el estado financiero de la empresa, siendo asi que tienen que tomar en cuenta si mejor sale comprar el software o pago de licencias cada cierto tiempo.
Costo del hardware: Como todos conocemos si contamos con un software de alto costo se supone que es de alta calidad, siendo así que habría que comprar un equipo de alta velocidad y capacidad, porque de nada vale que tengamos un buen software si no contamos con el equipo adecuado donde se implantara.
Costo de mantenimiento: Esto es cuando no la administramos nosotros mismos y tenemos que contratar a una persona especializada en el tema, tomando en cuenta que aquella persona tiene un alto costo por su servicio.
Diseño lógico: es el que te va hacer una Resultados: Resultados son los que adquirimos de nuestro software.
MODELO RELACIONAL
RELACIONES
Es común que informaciones de una tabla estén asociadas con informaciones de otras tablas. En este caso podemos establecer una relación entre las dos tablas. Es a través de la relación que el Access consigue, a partir de informaciones en una tabla, obtener informaciones registradas en la otra tabla. Existen tres tipos de relaciones entre dos tablas A y B: uno – a – uno, uno – a – varios, varios – a – varios.
Autor César Montoya
Página 5
1. - Relaciones uno a uno. La relación uno a uno ocurre cuando un registro de la tabla A posee como máximo un registro asociado en la tabla B y un registro de la tabla B posee como máximo un registro asociado en la tabla A.
Esta relación está presente en el número de gerente/número de empleado, entre el PADRÓN DE DEPARTAMENTOS y el PADRÓN DE EMPLEADOS. Para cada número de gerente identificamos apenas un registro en el PADRÓN DE EMPLEADOS y cada funcionario es eventualmente gerente de apenas un departamento.
Opción 1
Opción 2
Autor César Montoya
Página 6
2.2 - Relaciones uno a varios. La relación uno a varios ocurre cuando un registro de la tabla A puede tener mas de un registro asociado en la tabla B, mientras que, un registro de la tabla B posee como máximo un registro asociado en la tabla A. Esta relación está presente en la sigla del departamento entre el PADRÓN DE DEPARTAMENTO y el PADRÓN DE EMPLEADOS. Para cada sigla del PADRÓN DE DEPARTAMENTOS identificamos varios registros con esta sigla en el PADRÓN DE EMPLEADOS, mientras que, para cada sigla en el PADRÓN DE EMPLEADOS identificamos como máximo un registro en el PADRÓN DE DEPARTAMENTOS. También debe quedar claro que, en principio, podemos tener departamentos sin funcionarios y funcionarios que momentáneamente no están asignados a ningún departamento.
2.3. - Relaciones varios a varios. La relación varios a varios ocurre cuando un registro de la tabla A puede tener más de un registro asociado en la tabla B y, análogamente, un registro en la tabla B puede tener más de un registro asociado en la tabla A. Los cargos ocupados por un empleado a lo largo del tiempo constituyen una relación de esta naturaleza. Cada empleado ocupó varios cargos y un cargo fue
ocupado
por
diversos
empleados.
En
esta
relación
queda
inmediatamente aparente que al par empleado/cargo probablemente estarán asociadas otras informaciones, por ejemplo, la fecha en que el empleado asumió el cargo en cuestión.
Autor César Montoya
Página 7
Relaciones de este tipo varios a varios no pueden ser especificadas directamente en Access. Es necesario la creación de una tabla intermediaria que en nuestro caso podría tener el nombre: cargos ocupados. Cada registro en esta tabla sería compuesto de tres campos: Número de empleado, Código del cargo y Fecha de admisión a este cargo. Como se observa, se creó una relación uno a varios entre el PADRÓN DE EMPLEADOS y el PADRÓN DE CARGOS OCUPADOS y, análogamente, otra relación uno a mucho entre el PADRÓN DE CARGOS Y SALARIOS y el PADRÓN DE CARGOS OCUPADOS. Por lo tanto una relación varios a varios es convertida en dos relaciones una a varios cuando hubiera informaciones asociadas a los pares relacionados.
Autor César Montoya
Página 8
Terminar con la revisión de relaciones…
Revisión de relaciones con atributos
Autor César Montoya
Página 9
NORMALIZACIÓN DE BASES DE DATOS
El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional. Las bases de datos relacionales se normalizan para: Evitar la redundancia de los datos. Disminuir problemas de actualización de los datos en las tablas. Proteger la integridad de los datos. En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones: Cada tabla debe tener su nombre único. No puede haber dos filas iguales. No se permiten los duplicados. Todos los datos en una columna deben ser del mismo tipo. Terminología relacional equivalente Relación = tabla o archivo Registro = registro, fila , renglón o tupla Atributo = columna o campo Clave = llave o código de identificación Clave Candidata = superclave mínima Clave Primaria = clave candidata elegida Clave Ajena (o foránea) = clave externa o clave foránea Clave Alternativa = clave secundaria Dependencia Multivaluada = dependencia multivalor RDBMS = Del inglés Relational Data Base Manager System que significa, Sistema Gestor de Bases de Datos Relacionales. 1FN = Significa, Primera Forma Normal o 1NF del inglés First Normal Form. Los términos Relación, Tupla y Atributo derivan del álgebra y cálculo relacional, que constituyen la fuente teórica del modelo de base de datos relacional. Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de valores que el mismo puede tomar. Una instancia de una tabla puede
Autor César Montoya
Página 10
verse entonces como un subconjunto del producto cartesiano entre los dominios de los atributos. Sin embargo, suele haber algunas diferencias con la analogía matemática, ya que algunos RDBMS permiten filas duplicadas, entre otras cosas. Finalmente, una tupla puede razonarse matemáticamente como un elemento del producto cartesiano entre los dominios.
Formas Normales
Las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd, éste introdujo la normalización en un artículo llamado A Relational Model of Data for Large Shared Data Banks.
Primera Forma Normal (1FN) Sea α un conjunto de atributo perteneciente (Є) a la relación R, en donde R está en la Primera Forma Normal si todos los atibutos α[n] son atómicos, es decir no pueden seguir dividiéndose. Por ejemplo:
La Relación: Cursos: nombre, código, vacantes, horario, bibliografía Queda después de aplicar la Forma Normal 1 de la siguiente manera: cursos1:
nombre,
código,
vacantes
horario1:
código,
día,
módulo
bibliografia1: código, nombre, autor.
Segunda Forma Normal (2FN) Dependencia completa. Está en 2FN si esta en 1FN y si sus atributos no principales dependen de forma completa de la clave principal.
Tercera Forma Normal (3FN) Está en segunda forma normal y todo atributo no primo es implicado por la clave primaria en una secuencia no transitiva. Se eliminan las dependencias transitivas.
Autor César Montoya
Página 11
Forma normal de Boyce-Codd (FNBC) Una tabla está en FNBC sí y sólo sí las únicas dependencias funcionales elementales son aquellas en las que la clave primaria determinan un atributo.
Cuarta Forma Normal (4FN) Está en forma normal de Boyce-Codd y se eliminan las dependencias multivaluadas y se generan todas las relaciones externas con otras tablas u otras bases de datos.
Quinta Forma Normal (5FN) Está en cuarta forma normal y toda dependencia-join viene implicada por claves candidatas.
Reglas de Codd Codd se dio de cuenta que existían bases de datos en el mercado las cuales decían ser relacionales, pero lo único que hacían era guardar la información en las tablas, sin estas tablas estar literalmente normalizadas; entonces éste publicó 12 reglas que un verdadero sistema relacional debería de tener, en la práctica algunas de ellas son difíciles de realizar. Un sistema podrá considerarse "más relacional" cuanto más siga estas reglas.
Regla No. 1 - La Regla de la información Toda la información en un RDBMS está explícitamente representada de una sola manera por valores en una tabla. Cualquier cosa que no exista en una tabla no existe del todo. Toda la información, incluyendo nombres de tablas, nombres de vistas, nombres de columnas, y los datos de las columnas deben estar almacenados en tablas dentro de las bases de datos. Las tablas que contienen tal información constituyen el Diccionario de Datos.
Autor César Montoya
Página 12
Regla No. 2 - La regla del acceso garantizado Cada ítem de datos debe ser lógicamente accesible al ejecutar una búsqueda que combine el nombre de la tabla, su clave primaria, y el nombre de la columna.
Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y dado el nombre de la columna requerida, deberá encontrarse uno y solamente un valor. Por esta razón la definición de claves primarias para todas las tablas es prácticamente obligatoria.
Regla No. 3 - Tratamiento sistemático de los valores nulos La información inaplicable o faltante puede ser representada a través de valores nulos. Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de soportar el uso de valores nulos en el lugar de columnas cuyos valores sean desconocidos o inaplicables.
Regla No. 4 - La regla de la descripción de la base de datos La descripción de la base de datos es almacenada de la misma manera que los datos ordinarios, esto es, en tablas y columnas, y debe ser accesible a los usuarios autorizados.
La información de tablas, vistas, permisos de acceso de usuarios autorizados, etc, debe ser almacenada exactamente de la misma manera: En tablas. Estas tablas deben ser accesibles igual que todas las tablas, a través de sentencias de SQL.
Regla No. 5 - La regla del sub-lenguaje Integral Debe haber al menos un lenguaje que sea integral para soportar la definición de datos, manipulación de datos, definición de vistas, restricciones de integridad, y control de autorizaciones y transacciones.
Autor César Montoya
Página 13
Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien definida que pueda ser usado para administrar completamente la base de datos.
Regla No. 6 - La regla de la actualización de vistas Todas las vistas que son teóricamente actualizables, deben ser actualizables por el sistema mismo. La mayoría de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos de actualizar vistas complejas.
Regla No. 7 - La regla de insertar y actualizar La capacidad de manejar una base de datos con operandos simples aplica no solo para la recuperación o consulta de datos, sino también para la inserción, actualización y borrado de datos.
Esto significa que las cláusulas SELECT, UPDATE, DELETE e INSERT deben estar disponibles y operables sobre los registros, independientemente del tipo de relaciones y restricciones que haya entre las tablas. Regla No. 8 - La regla de independencia física El acceso de usuarios a la base de datos a través de terminales o programas de aplicación, debe permanecer consistente lógicamente cuando quiera que haya cambios en los datos almacenados, o sean cambiados los métodos de acceso a los datos.
El comportamiento de los programas de aplicación y de la actividad de usuarios vía terminales debería ser predecible basados en la definición lógica de la base de datos, y éste comportamiento debería permanecer inalterado, independientemente de los cambios en la definición física de ésta.
Autor César Montoya
Página 14
Regla No. 9 - La regla de independencia lógica Los programas de aplicación y las actividades de acceso por terminal deben permanecer lógicamente inalterados cuando quiera que se hagan cambios (según los permisos asignados) en las tablas de la base de datos. La independencia lógica de los datos especifica que los programas de aplicación y las actividades de terminal deben ser independientes de la estructura lógica, por lo tanto los cambios en la estructura lógica no deben alterar o modificar estos programas de aplicación.
Regla No. 10 - La regla de la independencia de la integridad Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catálogo, no en el programa de aplicación. Las reglas de integridad son: Ningún componente de una clave primaria puede tener valores en blanco o nulos. (esta es la norma básica de integridad). Para cada valor de clave foránea deberá existir un valor de clave primaria concordante. La combinación de estas reglas aseguran que haya Integridad referencial.
Regla No. 11 - La regla de la distribución El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos esté distribuida físicamente en distintos lugares sin que esto afecte o altere a los programas de aplicación.
El soporte para bases de datos distribuidas significa que una colección arbitraria de relaciones, bases de datos corriendo en una mezcla de distintas máquinas y distintos sistemas operativos y que este conectada por una variedad de redes, pueda funcionar como si estuviera disponible como una única base de datos en una sola máquina.
Autor César Montoya
Página 15
Regla No. 12 - Regla de la no-subversión Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser usados para violar la integridad de las reglas y restricciones expresadas en un lenguaje de alto nivel (como SQL). Algunos productos solamente construyen una interfaz relacional para sus bases de datos No relacionales, lo que hace posible la subversión (violación) de las restricciones de integridad. Esto no debe ser permitido.
Normalizar una tabla de ejemplo Estos pasos demuestran el proceso de normalización de una tabla de alumnos ficticia. Tabla sin normalizar:
Nº alumno
Tutor
1022
García 412
101-07 143-01 159-02
4123
Díaz
201-01 211-02 214-01
Primera
forma
Despacho-Tut
216
normal:
no
Clase1 Clase2 Clase3
hay
grupos
repetidos
Las tablas sólo deben tener dos dimensiones. Puesto que un alumno tiene varias clases, estas clases deben aparecer en una tabla independiente. Los campos Clase1, Clase2 y Clase3 de los registros anteriores son indicativos de un problema de diseño.
Las hojas de cálculo suelen usar la tercera dimensión, pero las tablas no deberían hacerlo. Otra forma de considerar ese problema es con una relación de uno a varios y poner el lado de uno y el lado de varios en tablas distintas. En su lugar, cree otra tabla en la primera forma normal eliminando el grupo repetido (Nº clase), según se muestra a continuación:
Autor César Montoya
Página 16
Nº alumno
Tutor
Despacho-Tut
Nº clase
1022
García
412
101-07
1022
García
412
143-01
1022
García
412
159-02
4123
Díaz
216
201-01
4123
Díaz
216
211-02
4123
Díaz
216
214-01
normal:
eliminar
Segunda
forma
los
datos
redundantes
Observe los diversos valores de Nº clase para cada valor de Nº alumno en la tabla anterior. Nº clase no depende funcionalmente de Nº alumno (la clave principal), de modo que la relación no cumple la segunda forma normal.
Las
dos
tablas
siguientes
demuestran
la
segunda
forma
normal:
Alumnos: Nº alumno
Tutor
Despacho-Tut
1022
García
412
4123
Díaz
216
Registro: Nº alumno
Nº clase
1022
101-07
1022
143-01
1022
159-02
4123
201-01
4123
211-02
Autor César Montoya
Página 17
Tercera forma normal: eliminar los datos no dependientes de la clave En el último ejemplo, Despacho-Tut (el número de despacho del tutor) es funcionalmente dependiente del atributo Tutor. La solución es pasar ese atributo de la tabla Alumnos a la tabla Personal, según se muestra a continuación:
Alumnos: Nº alumno
Tutor
1022
García
4123
Díaz
Personal: Nombre
Habitación
Dept
García
412
42
Díaz
216
42
Glosario de términos Terminología equivalente relación = tabla o archivo tupla = registro, fila o renglón atributo = campo o columna base de datos = banco de datos dependencia multivaluada = dependencia multivalor clave = llave clave primaria = superclave clave ajena = clave extranjera o clave foránea RDBMS = del inglés Relational Data Base Manager System que significa, Sistema Gestor de Base de Datos Relacionales
Autor César Montoya
Página 18