Documentos de Académico
Documentos de Profesional
Documentos de Cultura
FACULTAD DE CIENCIAS E INGENIERIA CARRERA PROFESIONAL DE INGENIERIA DE SISTEMAS E INFORMATICA TRABAJO DE IMPLEMENTACION Y DESARROLLO DE BASE DE DATOS TEMA: NORMALIZACION: REGLAS DE NORMALIZACION PRESENTADO POR: SANDOVAL ACOSTA, SAMMY ROBERT STEPHANO. GARCIA SOSA, SANDRO ADEMIR. CICLO: 7 DOCENTE: ING. PALACIOS CHAVEZ, CESAR IQUITOS PERU 2013
TEMA:
DEDICADO PARA LOS ALUMNOS E INGENIEROS DE LA UNIVERSIDAD CIENTIFICA DEL PERU, DE LA CARRERA PROFESIONAL DE INGENIERIA DE SISTEMAS.
INDICE NORMALIZACION
IntroduccinPgina 3 1) Concepto...Pgina 4
INTRODUCCION
En el mundo de la informtica, y ms precisamente en el mundo de la administracin de bases de datos, la normalizacin es la base fundamental para el desarrollo y el manejo apropiado de grandes masas de informacin. Y es que tras el paso del modelo entidadrelacin al modelo relacional se deben cumplir ciertas reglas que nos ayudan a evitar redundancias y as darle ms consistencia a nuestras bases de datos. Una base de datos es bsicamente una descripcin de algo conocido como contenedor de datos (algo en donde se guarda la informacin), as como de los mtodos para almacenar y recuperar informacin de esos contenedores, el proceso de armado de una base de datos incluye el manejo de grandes masas de informacin, las mismas que son manejadas a travs de modelos de datos. Los modelos de datos no son cosas fsicas: son abstracciones que permiten la implementacin de un sistema eficiente de base de datos; por lo general se refieren a algoritmos, y conceptos matemticos. El diseo de una base de datos es un proceso complejo que abarca decisiones a muy distintos niveles. La complejidad se controla mejor si se descompone el problema en subproblemas y se resuelve cada uno de estos subproblemas independientemente, utilizando tcnicas especficas. As, el diseo de una base de datos se descompone en diseo conceptual, diseo lgico y diseo fsico. Y es precisamente esa complejidad que hace tan difcil la labor de los ingenieros. No obstante, hay reglas que ayudan a controlar dicha complejidad, esas reglas son conocidas como principios de normalizacin que no son ms que estndares y guas que ayudan a evitar redundancias en el manejo de base de datos. En consecuencia el presente trabajo tratar sobre el tema de la normalizacin, y las distintas regla existentes para el manejo apropiado de una base de datos.
NORMALIZACION
1) Concepto: La normalizacin es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos ms pequeas, que adems de ser ms simples y ms estables, son ms fciles de mantener. Tambin se puede entender la normalizacin como una serie de reglas que sirven para ayudar a los diseadores de bases de datos a desarrollar un esquema que minimice los problemas de lgica, cada regla est basada en la que le antecede. La normalizacin nos permite organizar los datos en una base de datos. Esto incluye la creacin de tablas y se establece relaciones entre aquellas tablas segn reglas diseadas para proteger los datos y hacer la base de datos ms flexible al eliminar redundancias y dependencia incoherente. La normalizacin se adopt porque el viejo estilo de poner todos los datos en un solo lugar, como un archivo o una tabla de la base de datos, eran ineficiente y conduca a errores de lgica cuando se trataban de manipular los datos, adems la normalizacin tambin hace las cosas fciles de entender. Los seres humanos tenemos la tendencia de simplificar las cosas al mximo. Lo hacemos con casi todo, desde los animales hasta con los automviles, vemos una imagen de gran tamao y la hacemos ms simple agrupando cosas similares juntas. Las guas que la normalizacin provee crean el marco de referencia para simplificar una estructura de datos compleja. Otra ventaja de la normalizacin de base de datos es el consumo de espacio. Una base de datos normalizada ocupa menos espacio en disco que una no normalizada, hay menos repeticin de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco. Por ejemplo, un cambio de direccin de un cliente es mucho ms fcil de implementar si los datos solo se almacenan en la tabla clientes y en ningn otro lugar de la base de datos. El proceso de normalizacin tiene un nombre y una serie de reglas para cada fase.
Todos los atributos son atmicos, un atributo es atmico si los elementos del dominio son indivisibles, es decir su dominio solo puede abarcar un valor. La tabla contiene una llave primaria nica. La llave primaria no contiene atributos nulos. No debe existir variacin en el nmero de columnas. Los campos no llave deben identificarse por la llave (Dependencia Funcional) Debe existir una independencia del orden tanto de las filas como de las columnas, es decir, si los datos cambian de orden no deben cambiar sus significados Una tabla no puede tener mltiples valores en cada columna
Para solucionar el problema de los atributos no atmicos, los pasos son los siguientes:
Eliminar los grupos repetidos Crear una nueva tabla con la clave de la tabla base y el grupo repetido.
2.1. Ejemplo:
En la tabla anterior el atributo emails puede tener ms de un valor, por lo que viola 1FN ya que segn la primera forma de normalizacin los atributos deben ser atmicos, no obstante esta tabla podra quedar normalizada de acuerdo a la primera forma normal si hiciramos lo siguiente: Crear una nueva tabla llamada Emails y relacionarla con la tabla Empleado, esta tabla heredar el id_empleado e id_email, con lo que queda normalizada de acuerdo a la primera forma normal.
La solucin en base a 2FN sera crear dos tablas separadas, as se evitarn las redundancias que aparecen en la tabla anterior, quedando de la siguiente manera:
Mediante la creacin de tablas separadas, se evitan redundancias, por ejemplo en el modelo original no era posible actualizar datos, basta con mirar el atributo lugar del trabajo de Jones que tiene ms de un dominio, por lo que si actualizaramos en sus registros "Mecanografa" y "Taquigrafa" y no actualizaramos su registro "Tallado", los datos resultantes implicaran respuestas contradictorias a la pregunta "Cul es el lugar actual de trabajo de Jones?". Este problema es solucionado separando las tablas en dos, lo que dara como resultado las siguientes tablas:
La tabla est en la segunda forma normal (2NF) Ningn atributo no-primario de la tabla es dependiente transitivamente de una clave primaria
Los atributos primarios (que son claves o partes de claves) no deben ser funcionalmente dependientes en absoluto; cada uno de ellos representa un hecho sobre la clave en el sentido de proporcionar parte o toda la clave en s misma. Debe ser observado que esta regla se aplica solamente a los atributos funcionalmente dependientes, ya que aplicndola a todos los atributos prohibira implcitamente claves de candidato compuestas, puesto que cada parte de cualquiera de tales claves violara la clusula de clave completa. 4.1. Ejemplo: La siguiente tabla est normalizada de la segunda forma normal:
La violacin de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del ganador es dependiente transitivamente de {Torneo, Ao} va el atributo no primario Ganador. El hecho de que la Fecha de nacimiento del ganador es funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias lgicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas de nacimiento en diversos registros. Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:
10
Del grfico de dependencias deducimos que no se encuentra en FNBC, procedemos a su normalizacin hasta FNBC. Aplicamos la regla de descomposicin sin prdidas a la dependencia que impide la restriccin en FNBC, Asignatura Profesor:
PROFE_ASIG (profesor, asignatura) ESTU_PROFE (estudiante, profesor)
11
Si realizamos los grafos de dependencias de las relaciones obtenidas: PROFE_ASIG (profesor, asignatura)
Podemos ver que las dependencias funcionales de la relacin original no se conservan. Slo podemos asegurar una descomposicin sin prdidas para una normalizacin hasta 3FN, a partir de ella no podemos asegurar que no se pierdan dependencias. Si se llega a FNBC y se pierde una dependencia entonces podemos proceder de dos maneras posibles: 1.-Dejamos la normalizacin hasta 3FN. 2.-Rediseamos el modelo entidad-relacin.
12
Ahora surge la interrogante Cul es la relacin entre SID y especialidad? No es una dependencia funcional porque los estudiantes pueden tener distintas especialidades. Un valor nico de SID puede poseer muchos valores de Especialidad, esto tambin se aplica a la relacin entre SID y Actividad. Tal dependencia por atributos de denomina dependencia de valores mltiples. Las dependencias de valores mltiples conducen a anomalas de modificacin. Basta con observar la redundancia en datos de la figura. 13
La estudiante 100 tiene cuatros registros, cada uno de los cuales muestra una de sus especialidades junto con una de sus actividades. Si los datos se almacenaran con menos hileras: si hubiera slo dos tuplas, uno para msica y natacin y uno para contadura y tenis, las implicaciones seran engaosas. Parecera que la Estudiante 100 slo nad cuando tena msica como especialidad y jug tenis slo cuando tena contadura como especialidad. Esa interpretacin no es lgica. Sus especialidades y sus actividades son independientes entre s, para prevenir tales engaosas conclusiones se almacenan todas las combinaciones de especialidades y actividades. Suponga que, debido a que la Estudiante 100 decide apuntarse en Esqu, se debe agregar la tupla (100, MSICA, ESQU), como en la figura. La afinidad en este punto indica que la Estudiante 100 esqua cuando estudia msica, pero no cuando tiene contadura como especialidad. A fin de mantener la consistencia en los datos, se debe agregar una hilera para cada uno de una de sus actividades ligadas con Esqu. Tambin se debe agregar la hilera) (100, CONTABILIDAD, ESQU), como en la figura. sta es una anomala de actualizacin: hay que hacer demasiadas actualizaciones para realizar un cambio en los datos.
Existe una dependencia de valores mltiples cuando una afinidad tiene al menos tres atributos, dos de los cuales poseen valores mltiples y sus valores dependen slo del tercer atributo. En otras palabras en la afinidad R (A, B, C) existe una dependencia de valores mltiples si A determina valores mltiples de B, A determina valores mltiples de especialidad, y SID determina valores mltiples de Actividad, pero Especialidad y Actividad son independientes entre s. Observe otra vez la figura. Vea cmo estn escritas las dependencias de valores mltiples: SID Especialidad y SID Actividad. Esto se lee "SID multidetermina Especialidad, y SID multiterminal Actividad". Esta afinidad est en BCNF (2NF porque todo es clave; 3NF porque no tiene dependencias transitivas; y BCNF porque no tiene determinantes que no son claves). Hemos visto que posee anomalas: si un estudiante toma otra especialidad, se debe ingresar un tupla para la nueva especialidad, y juntarlo con cada una de las actividades del estudiante. Sucede lo mismo si un estudiante se inscribe en una nueva actividad. Si un estudiante deja una especialidad se deben eliminar cada uno de los registros que contienen tal materia. Si participa en cuatro 14
actividades, habr cuatro tuplas que contengan la especialidad que ha dejado y deber borrarse cada uno. Para evitar tales anomalas, se deben las dependencias de valores mltiples. Esto se hace construyendo dos afinidades, donde cada una almacena datos para solamente uno de los atributos de valores mltiples. Las afinidades resultantes no tienen anomalas. Ellas son ESTU-ESPECIALIDAD (SID, Especialidad) y ESTU-ACT (SID, Actividad). A partir de estas observaciones, se define la cuarta forma normal: Una afinidad est en cuarta forma normal si est en BCNF y no tiene dependencias de valores mltiples. Quedara de la siguiente manera:
15
16
7.1. Ejemplo:
Entidades: AGENTES, COMPANIAS y PRODUCTOS. Si los AGENTES representan COMPAIAS, las COMPAAS fabrican PRODUCTOS, y los AGENTES venden PRODUCTOS, entonces nosotros querramos tener guardado un registro de cules agentes venden cules productos para cul compaa. Esta informacin puede ser guardada en un registro con tres campos:
Esta forma es necesaria en el caso general, ahora bien, aunque el agente PARRA vende autos hechos por FORD y camiones hechos por GENERAL MOTORS; l no vende camiones FORD ni autos GM. Esto es, necesitamos la combinacin de los tres campos para saber cules combinaciones son vlidas y cules no. Ahora bien, supongamos la siguiente regla: si un agente vende cierto producto y l representa la compaa que lo fabrica, entonces l vende un producto para esa compaa.
En este caso, resulta que podemos reconstruir todos los datos reales de una forma normalizada consistente de tres tipos de registros separados, cada uno conteniendo dos campos.
Estos tres registros estn en la Quinta Forma Normal, puesto que el correspondiente registro de tres campos presentado previamente no lo est. 17
ANEXOS DEPENDENCIA FUNCIONAL: Una dependencia funcional son conexiones entre uno o ms atributos, por ejemplo si conocemos el valor de A podemos conocer el valor de B. Las dependencias funcionales se escriben utilizando una flecha, de la siguiente manera: A-> B. En este caso A se llama Determinante y se dice que B depende de A. VALORES ATOMICOS Se dice que una variable es atmica, si y solo si su rango de dominio es nico, es decir que solo puede almacenar un valor, por ejemplo el atributo email: no puede ser considerado como atmico, debido a que una sola persona puede tener ms de una direccin de email por lo que su rango de dominio es extenso. REDUNDANCIAS En bases de datos o en ficheros, la redundancia hace referencia al almacenamiento de los mismos datos varias veces en diferentes lugares. La redundancia de datos puede provocar problemas como: Incremento del trabajo: como un mismo dato est almacenado en dos o ms lugares, esto hace que cuando se graben o actualicen los datos, deban hacerse en todos los lugares a la vez. Desperdicio de espacio de almacenamiento: ya que los mismos datos estn almacenados en varios lugares distintos, ocupando as ms bytes del medio de almacenamiento. Este problema es ms evidente en grandes bases de datos. Inconsistencia de datos: esto sucede cuando los datos redundantes no son iguales entre s. Esto puede suceder, por ejemplo, cuando se actualiza el dato en un lugar, pero el dato duplicado en otro lugar no es actualizado. Si una base de datos est bien diseada, no debera haber redundancia de datos (exceptuando la redundancia de datos controlada, que se emplea para mejorar el rendimiento en las consultas a las bases de datos). DEPENDENCIA TRIVIAL Es aquella dependencia que establece que un atributo depende de s mismo: A -> A
18
CONCLUSION
La normalizacin es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos ms pequeas, que adems de ser ms simples y ms estables, son ms fciles de mantener. La normalizacin nos permite organizar los datos en una base de datos. Esto incluye la creacin de tablas y se establece relaciones entre aquellas tablas segn reglas diseadas para proteger los datos y hacer la base de datos ms flexible al eliminar redundancias y dependencia incoherente. Hay cinco formas de normalizar una base de datos, estas son: La primera forma normal (1FN o forma mnima), es una forma normal usada en normalizacin de bases de datos. Una tabla de base de datos relacional que se adhiere a la 1FN es una que satisface cierto conjunto mnimo de criterios, estos criterios se refieren bsicamente a asegurarse que la tabla es una representacin fiel de una relacin y est libre de grupos repetitivos. Segunda forma normal: una tabla 1NF est en 2NF si y solo si, dada una clave primaria y cualquier atributo que no sea un constituyente de la clave primaria, el atributo no clave depende de toda la clave primaria en vez de solo de una parte de ella. Es decir, una tabla 1NF est en 2NF si y solo si ninguno de sus atributos no-principales son funcionalmente dependientes en una parte (subconjunto propio) de una clave primaria (Un atributo noprincipal es uno que no pertenece a ninguna clave primaria). Tercera forma normal (3NF) es una forma normal usada en la normalizacin de bases de datos, la 3NF fue definida originalmente por E.F. Codd en 1971. La definicin de Codd indica que una tabla est en 3NF si y solo si las dos condiciones siguientes se: La tabla est en la segunda forma normal (2NF) Ningn atributo no-primario de la tabla es dependiente transitivamente de una clave primaria Boyce Codd: se dice que una tabla est en FNBC si y solo si est en 3FN y cada dependencia funcional no trivial tiene una clave candidata como determinante. En trminos menos formales, una tabla est en FNBC si est en 3FN y los nicos determinantes son claves candidatas. Cuarta forma normal: una tabla est en 4NF si y solo si est en Tercera forma normal o en BCNF (Cualquiera de ambas) y no posee dependencias multivaluadas no triviales. La definicin de la 4NF confa en la nocin de una dependencia multivaluada. Una tabla con una dependencia multivaluada es una donde la existencia de dos o ms relaciones independientes muchos a muchos causa redundancia; y es esta redundancia la que es suprimida por la cuarta forma normal.
19
Quinta forma normal: una tabla se dice que est en 5NF si y slo si est en 4NF y cada dependencia de unin en ella es implicada por las claves candidatas. La Quinta Forma Normal (5FN) trata con casos donde la informacin puede ser reconstruida de muchas piezas de informacin las cuales pueden ser mantenidas con poca redundancia. La Segunda, Tercera y Cuarta Formas Normales tambin sirven a este propsito pero la Quinta Forma Normal generaliza los casos no cubiertos por ellas.
20
21