INSTITUTO UNIVERSTARIO DE TECNOLOGIADE ADMINISTRACION INDUSTRIALIUTA SEDE NACIONAL-ANACO EDO. ANZOATEGUI.

MODELO ENTIDAD RELACION Y NORMALIZACION

Bachiller Sarmiento Adolfo 19.983.220

Anaco, Abril del 2014

Introduccin

Desde hace varios aos la presencia y hegemona del manejo computarizado de la informacin en todo tipo de actividades econmicas y sociales en el mbito mundial es un hecho evidente e indetenible. La sociedad actual depende de las tecnologas de la informacin y comunicacin; y esta dependencia se manifiesta en niveles progresivamente crecientes.Derivado de ello se estn produciendo profundos cambios y transformaciones de naturaleza social y cultural, adems de econmicos.Deca nuestro hroe nacional Jos Mart que es criminal el divorcio que se produce entre la poca y la educacin que se recibe en la poca y sabemos que el contexto en el que nuestras instituciones educativas desarrollan su labor docente, es ampliamente tecnolgico.Uno de esos escenarios paralelos a la educacin institucionalizada, lo constituyen las Tecnologas de la Informacin y las Comunicaciones (TIC). Los avances en las TIC, adems de otros impactos, han trado consigo la creciente privatizacin de los medios, la integracin de las industrias mediticas y formas de fragmentacin de las producciones y las audiencias.En este tema conoceremos y realizaremos bases de datos con el modelo entidad-relacin. Primero, hablaremos del creador y sus conceptos bsicos. Despus, veremos ms a fondo las relaciones y los diagramas de estructuras de datos. En tercer lugar, observaremos la cardinalidad y los grados dependiendo de las entidades y las relaciones. A continuacin, las generalizaciones y las jerarquas con su debida consideracin. Finalizando, nos encontraremos con las entidades fuertes y dbiles para fijarnos, con ejemplos, su relacin. Finalmente, vemos la agregacin para conocer la limitacin del modelo entidad-relacin y su solucin.

Undiagrama o modelo entidad-relacin(a veces denominado por sus siglas en ingls,E-R"Entity relationship", o del espaol DER"Diagrama de Entidad Relacin") es una herramienta para elmodelado de datosque permite representar las entidades relevantes de unsistema de informacinas como sus interrelaciones y propiedades.ElModelo Entidad-Relacin.1. Se elabora el diagrama (o diagramas) entidad-relacin.2. Se completa el modelo con listas de atributos y una descripcin de otras restricciones que no se pueden reflejar en el diagrama.El modelado de datos no acaba con el uso de esta tcnica. Son necesarias otras tcnicas para lograr un modelo directamente implementarle en unabase de datos. Brevemente: permite mostrar resultados entre otras entidades pertenecientes a las existentes de manera que se encuentre la normatividad de archivos que se almacenaran Transformacin de relaciones mltiples en binarias. Normalizacin de una base de datosde relaciones (algunas relaciones pueden transformarse en atributos y viceversa). Conversin en tablas (en caso de utilizar unabase de datos relacional).Base terica y conceptualEl modelo de datos entidad-relacin est basado en una percepcin del mundo real que consta de una coleccin de objetos bsicos, llamados entidades, y de relaciones entre esos objetos.EntidadRepresenta una cosa u "objeto" del mundo real con existencia independiente, es decir, se diferencia unvocamente 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 automvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrn atributos diferentes, por ejemplo, el nmero de chasis). Una casa (Aunque sea exactamente igual a otra, an se diferenciar en su direccin).Una entidad puede ser un objeto con existencia fsica 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 caractersticas o atributos. Por ejemplo, la entidadPersonalas caractersticas: Nombre, Apellido, Gnero, Estatura, Peso, Fecha de nacimiento.AtributosLos atributos son las caractersticas que definen o identifican a una entidad. Estas pueden ser muchas, y el diseador solo utiliza o implementa las que considere ms relevantes. Los atributos son las propiedades que describen a cada entidad en un conjunto de entidades.En un conjunto de entidades del mismo tipo, cada entidad tienevaloresespecficos asignados para cada uno de sus atributos, de esta forma, es posible su identificacin unvoca.Ejemplos:A la coleccin de entidades alumnos, con el siguiente conjunto de atributos en comn, (id, nombre, edad, semestre), pertenecen las entidades: (1, Sofa, 38 aos, 2) (2, Josefa, 19 aos, 5) (3, Carlos, 20 aos, 2) ...Cada una de las entidades pertenecientes a este conjunto se diferencia de las dems por el valor de sus atributos. Ntese que dos o ms entidades diferentes pueden tener los mismos valores para algunos de sus atributos, pero nunca para todos.En particular, losatributos identificativosson aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un alumno de otro es su nmero de id.Para cada atributo, existe undominiodel mismo, este hace referencia al tipo de datos que ser almacenado o a restricciones en los valores que el atributo puede tomar (cadenas de caracteres, nmeros, solo dos letras, solo nmeros mayores que cero, solo nmeros enteros...).Cuando algn atributo correspondiente a una entidad no tiene un valor determinado, recibe elvalor nulo, bien sea porque no se conoce, porque no existe o porque no se sabe nada al respecto del mismo.Ejemplo:

Si tenemos dos entidades, "CLIENTE" y "HABITACION", podemos entender la relacin entre ambas al tomar un caso concreto (ocurrencia) de cada una de ellas. Entonces, podriamos tener la ocurrencia "Habitacin 502", de la entidad "HABITACIN" y la ocurrencia "Henry Johnson McFly Bogard", de la entidad "CLIENTE", entre las que es posible relacionar que la habitacin 502 se encuentra ocupada por el husped de nombre Henry Johnson McFly Bogard.Una relacin tiene sentido al expresar las entidades que relaciona. En el ejemplo anterior, podemos decir que un husped (entidad), se aloja (relacin) en una habitacin (entidad).Conjunto de relacionesConsiste en una coleccin, o conjunto, de relaciones de la misma naturaleza.Ejemplo:Dados losconjuntos de entidades"Habitacin" y "Husped", todas las relaciones de la forma habitacin-husped, permiten obtener la informacin de los huspedes y sus respectivas habitaciones.La dependencia o asociacin entre los conjuntos de entidades es llamadaparticipacin. En el ejemplo anterior los conjuntos de entidades "Habitacin" y "Husped"participanen el conjunto de relaciones habitacin-husped.Se llamagradodel conjunto de relaciones a la cantidad de conjuntos de entidades participantes en la relacin.RestriccionesSon reglas que deben mantener los datos almacenados en la base de datos.Correspondencia de cardinalidadesDado un conjunto de relaciones en el que participan dos o ms conjuntos de entidades, la correspondencia de cardinalidad indica el nmero de entidades con las que puede estar relacionada una entidad dada.Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia de cardinalidades puede ser: Uno a Uno:(1:1) Una entidad de A se relaciona nicamente con una entidad en B y viceversa (ejemplo relacin vehculo - matrcula: cada vehculo tiene una nica matrcula, y cada matrcula est asociada a un nico vehculo). Uno a varios:(1:N)Una entidad en A se relaciona con cero o muchas entidades en B. Pero una entidad en B se relaciona con una nica entidad en A (ejemplo vendedor - ventas). Varios a Uno:(N:1)Una entidad en A se relaciona exclusivamente con una entidad en B. Pero una entidad en B se puede relacionar con 0 o muchas entidades en A (ejemplo empleado-centro de trabajo). Varios a Varios:(N:M)Una entidad en A se puede relacionar con 0 o muchas entidades en B y viceversa (ejemplo asociaciones- ciudadanos, donde muchos ciudadanos pueden pertenecer a una misma asociacin, y cada ciudadano puede pertenecer a muchas asociaciones distintas).Restricciones de participacinDado un conjunto de relaciones R en el cual participa un conjunto de entidades A, dicha participacin puede ser de dos tipos: Total:Cuando cada entidad en A participa en al menos una relacin de R. Parcial:Cuando al menos una entidad en A NO participa en alguna relacin de R.ClavesEs un subconjunto del conjunto de atributos comunes en una coleccin de entidades, que permite identificar inequvocamente cada una de las entidades pertenecientes a dicha coleccin. Asimismo, permiten distinguir entre s las relaciones de un conjunto de relaciones.Dentro de los conjuntos de entidades existen los siguientes tipos de claves: Superclave:Es un subconjunto de atributos que permite distinguir unvocamente cada una de las entidades de un conjunto de entidades. Si se aade un atributo al anterior subconjunto, el resultado seguir siendo una superclave. Clave candidata:Dada una superclave, si sta deja de serlo quitando nicamente uno de los atributos que la componen, entonces sta es una clave candidata. Clave primaria:Es una clave candidata, elegida por el diseador de la base de datos, para identificar unvocamente las entidades en un conjunto de entidades.Los valores de los atributos de una clave, no pueden ser todos iguales para dos o ms instancias.Para poder distinguir unvocamente las relaciones en un conjunto de relaciones R, se deben considerar dos casos: R NO tiene atributos asociados:En este caso, se usa como clave primaria de R la unin de las claves primarias de todos los conjuntos de entidades participantes. R tiene atributos asociados:En este caso, se usa como clave primaria de R la unin de los atributos asociados y las claves primarias de todos los conjuntos de entidades participantes.Si el conjunto de relaciones, R, sobre las que se pretende determinar la clave primaria est compuesto de relaciones binarias, con los conjuntos de entidades participantes A y B, se consideran los siguientes casos, segn sus cardinalidades: R es de muchos a uno de A a Bentonces slo se toma la clave primaria de A, como clave primaria de R. R es de uno a muchos de A a Bentonces se toma slo la clave primaria de B, como clave primaria de R. R es de uno a uno de A a Bentonces se toma cualquiera de las dos claves primarias, como clave primaria de R. R es de muchos a muchos de A a Bentonces se toma la unin de los atributos que conforman las claves primarias de A y de B, como clave primaria de R.Diagrama entidad-relacinAnteriormente detallamos los conceptos relacionados al modelo ER, en esta seccin profundizaremos en como representarlos grficamente. Cabe destacar que para todo proceso de modelado, siempre hay que tener en claro los conceptos, estos nos brindan conocimiento necesario y adems fundamentan nuestro modelo al momento de presentarlo a terceros.Formalmente, los diagramas ER son un lenguaje grfico para describir conceptos. Informalmente, son simples dibujos o grficos que describen informacin que trata un sistema de informacin y el software que lo automatiza.

EntidadesLas entidades son el fundamento del modelo entidad relacin. Podemos adoptar como definicin de entidad cualquier cosa o parte del mundo que es distinguible del resto. Por ejemplo, en un sistema bancario, las personas y las cuentas bancarias se podran interpretar como entidades. Las entidades pueden representar entes concretos, como una persona o un avin, o abstractas, como por ejemplo un prstamo o una reserva. Se representan por medio de un rectngulo. que pueden ser de tipo: maestras, transaccionales, histricas y temporalesAtributosSe representan mediante un crculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta.Por motivos de legibilidad, los atributos suelen no aparecer representados en el diagrama entidad-relacin, sino descritos textualmente en otros documentos adjuntos.RelacionesSe representan mediante un rombo etiquetado en su interior con un verbo. Este rombo se debe unir mediante lneas con las entidades (rectngulos) que relaciona, para as saber cul es la relacin que lleva cada uno.Diagramas extendidosLos diagramas Entidad-Relacin no cumplen su propsito con eficacia debido a que tienen limitaciones semnticas. Por ese motivo se suelen utilizar losdiagramas Entidad-Relacin extendidosque incorporan algunos elementos ms al lenguaje:Entidades fuertes y dbilesCuando una entidad participa en una relacin puede adquirir un papelfuerteodbil. Una entidad dbil es aquella que no puede existir sin participar en la relacin; es decir, aquella que no puede ser unvocamente identificada solamente por sus atributos.Una entidad fuerte (tambin conocida como entidad regular) es aquella que s puede ser identificada unvocamente. En los casos en que se requiera, se puede dar que una entidad fuerte "preste" algunos de sus atributos a una entidad dbil para que esta ltima se pueda identificar.Las entidades dbiles se representan- mediante undoble rectngulo; es decir, un rectngulo con doble lnea.

Se puede hablar de la existencia de 2 tipos de dependencias en las entidades dbiles:Dependencia por existenciaLas ocurrencias de la entidad dbil pueden identificarse mediante un atributo identificador clave sin necesidad de identificar la entidad fuerte relacionada.Dependencia por identidadLa entidad dbil no puede ser identificada sin la entidad fuerte relacionada. (Ejemplo: si tenemos una entidad LIBRO y otra relacionada EDICIN, para identificar una edicin necesitamos conocer el identificador del libro).Cardinalidad de las relacionesEl tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relacin, respectivamente: "1:1", "1:N" y "N:M", aunque la notacin depende del lenguaje utilizado, la que ms se usa actualmente es el unificado. Otra forma de expresar la cardinalidad es situando un smbolo cerca de la lnea que conecta una entidad con una relacin: "0"si cada instancia de la entidad no est obligada a participar en la relacin. "1"si toda instancia de la entidad est obligada a participar en la relacin y, adems, solamente participa una vez. "N" , "M", "*"si cada instancia de la entidad no est obligada a participar en la relacin y puede hacerlo cualquier nmero de veces.Ejemplos de relaciones que expresan cardinalidad: Cada esposo (entidad) est casado (relacin) con una nica esposa (entidad) y viceversa. Es una relacin 1:1. Una factura (entidad) se emite (relacin) a una persona (entidad) y slo una, pero una persona puede tener varias facturas emitidas a su nombre. Todas las facturas se emiten a nombre de alguien. Es una relacin 1:N. Un cliente (entidad) puede comprar (relacin) varios servicios (entidad) y un servicio puede ser comprado por varios clientes distintos. Es una relacin N:M.Atributos en relacionesLas relaciones tambin pueden tener atributos asociados. Se representan igual que los atributos de las entidades. Un ejemplo tpico son las relaciones de tipo "histrico" donde debe constar una fecha o una hora. Por ejemplo, supongamos que es necesario hacer constar la fecha de emisin de una factura a un cliente, y que es posible emitir duplicados de la factura (con distinta fecha). En tal caso, el atributo "Fecha de emisin" de la factura debera colocarse en la relacin "se emite".HerenciaLa herencia es un intento de adaptacin de estos diagramas al paradigma orientado a objetos. La herencia es un tipo de relacin entre una entidad "padre" y una entidad "hijo". La entidad "hijo" hereda todos los atributos y relaciones de la entidad "padre". Por tanto, no necesitan ser representadas dos veces en el diagrama. La relacin de herencia se representa mediante un tringulo interconectado por lneas a las entidades. La entidad conectada por el vrtice superior del tringulo es la entidad "padre". Solamente puede existir una entidad "padre" (herencia simple). Las entidades "hijo" se conectan por la base del tringulo.AgregacinEjemplo agregacinEs una abstraccin a travs de la cual las relaciones se tratan como entidades de un nivel ms alto. Se utiliza para expresar relaciones entre relaciones o entre entidades y relaciones. Se representa englobando la relacin abstrada y las entidades que participan en ella en un rectngulo. En la figura se muestra un ejemplo de agregacin en el que se representa la situacin en la que un profesor, cuando est impartiendo una clase, puede poner una incidencia ocurrida a lo largo de sta (se fue la luz, falta la configuracin de un determinado software, etc.).Normalizacin de bases de datosEl proceso de normalizacin de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relacin al modelo relacional.Las bases de datos relacionales se normalizan para:Evitar la redundancia de los datos.Disminuir problemas de actualizacin de los datos en las tablas.Proteger la integridad de los datos.En el modelo relacional es frecuente llamar tabla a una relacin, aunque para que una tabla sea considerada como una relacin 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.Terminologa relacional equivalenteFigura 1.0: Trabajo (Cdigo, Nombre, Posicin, Salario), donde Cdigo es la Clave Primaria.Relacin = tabla o archivoRegistro = registro, fila , rengln o tuplaAtributo = columna o campoClave = llave o cdigo de identificacinClave Candidata = superclave mnimaClave Primaria = clave candidata elegidaClave Ajena (o fornea) = clave externa o clave forneaClave Alternativa = clave secundariaDependencia Multivaluada = dependencia multivalorRDBMS = Del ingls Relational Data Base Manager System que significa, Sistema Gestor de Bases de Datos Relacionales.1FN = Significa, Primera Forma Normal o 1NF del ingls First Normal Form.Los trminos Relacin, Tupla y Atributo derivan del lgebra y clculo relacional, que constituyen la fuente terica 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 verse entonces como un subconjunto del producto cartesiano entre los dominios de los atributos. Sin embargo, suele haber algunas diferencias con la analoga matemtica, ya que algunos RDBMS permiten filas duplicadas, entre otras cosas. Finalmente, una tupla puede razonarse matemticamente como un elemento del producto cartesiano entre los dominios.Dependencia funcionalB es funcionalmente dependiente de A.Una dependencia funcional es una conexin entre uno o ms atributos. Por ejemplo si se conoce el valor de DNI tiene una conexin con Apellido o Nombre .Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:Fecha De Nacimiento EdadDe la normalizacin (lgica) a la implementacin (fsica o real) puede ser sugerible tener stas dependencias funcionales para lograr la eficiencia en las tablas.Propiedades de la Dependencia funcionalExisten 3 axiomas de Armstrong:Dependencia funcional ReflexivaSi "y" est incluido en "x" entonces x yA partir de cualquier atributo o conjunto de atributos siempre puede deducirse l mismo. Si la direccin o el nombre de una persona estn incluidos en el DNI, entonces con el DNI podemos determinar la direccin o su nombre.Dependencia funcional Aumentativa entonces DNI nombreDNI, direccin nombre, direccinSi con el DNI se determina el nombre de una persona, entonces con el DNI ms la direccin tambin se determina el nombre y su direccin.Dependencia funcional transitiva.Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y depende funcionalmente de X y Z de Y, pero X no depende funcionalmente de Y, se dice entonces que Z depende transitivamente de X. Simblicamente sera:X Y Z entonces X ZFecha De Nacimiento EdadEdad ConducirFecha De Nacimiento Edad ConducirEntonces tenemos que Fecha De Nacimiento determina a Edad y la Edad determina a Conducir, indirectamente podemos saber a travs de Fecha De Nacimiento a Conducir (En muchos pases, una persona necesita ser mayor de cierta edad para poder conducir un automvil, por eso se utiliza este ejemplo)."C ser un dato simple (dato no primario), B,ser un otro dato simple (dato no primario), A, es la llave primaria (PK). Decimos que C depender de B y B depender funcionalmente de A."Propiedades deducidasUnin y entonces Pseudo-transitiva y entonces Descomposicin y est incluido en entonces ClavesUna clave primaria es aquella columna (o conjunto de columnas) que identifica nicamente a una fila. La clave primaria es un identificador que va a ser siempre nico para cada fila. Se acostumbra a poner la clave primaria como la primera columna de la tabla pero es ms una conveniencia que una obligacin. Muchas veces la clave primaria es numrica auto-incrementada, es decir, generada mediante una secuencia numrica incrementada automticamente cada vez que se inserta una fila.En una tabla puede que tengamos ms de una columna que puede ser clave primaria por s misma. En ese caso se puede escoger una para ser la clave primaria y las dems claves sern claves candidatas.Una clave ajena (foreign key o clave fornea) es aquella columna que existiendo como dependiente en una tabla, es a su vez clave primaria en otra tabla.Una clave alternativa es aquella clave candidata que no ha sido seleccionada como clave primaria, pero que tambin puede identificar de forma nica a una fila dentro de una tabla. Ejemplo: Si en una tabla clientes definimos el nmero de documento (id_cliente) como clave primaria, el nmero de seguro social de ese cliente podra ser una clave alternativa. En este caso no se us como clave primaria porque es posible que no se conozca ese dato en todos los clientes.Una clave compuesta es una clave que est compuesta por ms de una columna.La visualizacin de todas las posibles claves candidatas en una tabla ayudan a su optimizacin. Por ejemplo, en una tabla PERSONA podemos identificar como claves su DNI, o el conjunto de su nombre, apellidos, fecha de nacimiento y direccin. Podemos usar cualquiera de las dos opciones o incluso todas a la vez como clave primaria, pero es mejor en la mayora de sistemas la eleccin del menor nmero de columnas como clave primaria.

Formas NormalesLas formas normales son aplicadas a las tablas de una base de datos. Decir que una base de datos est en la forma normal N es decir que todas sus tablas estn en la forma normal N.Diagrama de inclusin de todas las formas normales.En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayora de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd.1Primera Forma Normal (1FN)[editar]Artculo principal: Primera forma normalUna tabla est en Primera Forma Normal si:Todos los atributos son atmicos. Un atributo es atmico si los elementos del dominio son indivisibles, mnimos.La tabla contiene una clave primaria nica.La clave primaria no contiene atributos nulos.No debe existir variacin en el nmero de columnas.Los Campos no clave deben identificarse por la clave (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 significadosUna tabla no puede tener mltiples valores en cada columna.Los datos son atmicos (a cada valor de X le pertenece un valor de Y y viceversa).Esta forma normal elimina los valores repetidos dentro de una BDSegunda Forma Normal (2FN)Artculo principal: Segunda forma normalDependencia Funcional. Una relacin est en 2FN si est en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales. (Todos los atributos que no son clave principal deben depender nicamente de la clave principal).En otras palabras podramos decir que la segunda forma normal est basada en el concepto de dependencia completamente funcional. Una dependencia funcional es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que. Una dependencia funcional es una dependencia parcial si hay algunos atributos que pueden ser eliminados de X y la dependencia todava se mantiene, esto es .Por ejemplo {DNI, ID_PROYECTO} HORAS_TRABAJO (con el DNI de un empleado y el ID de un proyecto sabemos cuntas horas de trabajo por semana trabaja un empleado en dicho proyecto) es completamente funcional dado que ni DNI HORAS_TRABAJO ni ID_PROYECTO HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI, ID_PROYECTO} NOMBRE_EMPLEADO es parcialmente dependiente dado que DNI NOMBRE_EMPLEADO mantiene la dependencia.Tercera Forma Normal (3FN)Artculo principal: Tercera forma normalLa tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.Un ejemplo de este concepto sera que, una dependencia funcional X->Y en un esquema de relacin R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva va DNUMBER porque las dependencias SSNDNUMBER y DNUMBERDMGRSSN son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT.Formalmente, un esquema de relacin est en 3 Forma Normal Elmasri-Navathe,2 si para toda dependencia funcional , se cumple al menos una de las siguientes condiciones: es supe llave o clave. es atributo primo de ; esto es, si es miembro de alguna clave en .Adems el esquema debe cumplir necesariamente, con las condiciones de segunda forma normal.Forma normal de Boyce-Codd (FNBC)[editar]Artculo principal: Forma normal de Boyce-CoddLa tabla se encuentra en FNBC si cada determinante, atributo que determina completamente a otro, es clave candidata. Deber registrarse de forma anillada ante la presencia de un intervalo seguido de una formalizacin perpetua, es decir las variantes creadas, en una tabla no se llegaran a mostrar, si las ya planificadas, dejan de existir.Formalmente, un esquema de relacin est en FNBC, si y slo si, para toda dependencia funcional vlida en, se cumple que es supe llave o clave.De esta forma, todo esquema que cumple FNBC, est adems en 3FN; sin embargo, no todo esquema que cumple con 3FN, est en FNBC.Cuarta Forma Normal (4FN)Artculo principal: Cuarta forma normalUna tabla se encuentra en 4FN si, y slo si, para cada una de sus dependencias mltiples no funcionales X->->Y, siendo X una super-clave que, X es o una clave candidata o un conjunto de claves primarias.Quinta Forma Normal (5FN)[editar]Artculo principal: Quinta forma normalUna tabla se encuentra en 5FN si:La tabla est en 4FNNo existen relaciones de dependencias no triviales que no siguen los criterios de las claves. Una tabla que se encuentra en la 4FN se dice que est en la 5FN si, y slo si, cada relacin de dependencia se encuentra definida por claves candidatas.Reglas de CoddCodd se percat de que existan bases de datos en el mercado las cuales decan ser relacionales, pero lo nico que hacan era guardar la informacin en las tablas, sin estar estas tablas literalmente normalizadas; entonces ste public 12 reglas que un verdadero sistema relacional debera tener, en la prctica algunas de ellas son difciles de realizar. Un sistema podr considerarse "ms relacional" cuanto ms siga estas reglas.Regla No. 1 - La Regla de la informacinToda la informacin en un RDBMS est explcitamente representada de una sola manera por valores en una tabla.Cualquier cosa que no exista en una tabla no existe del todo. Toda la informacin, 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 informacin constituyen el Diccionario de Datos. Esto significa que todo tiene que estar almacenado en las tablas.Toda la informacin en una base de datos relacional se representa explcitamente en el nivel lgico exactamente de una manera: con valores en tablas. Por tanto los metadatos (diccionario, catlogo) se representan exactamente igual que los datos de usuario. Y puede usarse el mismo lenguaje (ej. SQL) para acceder a los datos y a los metadatos (regla 4)Regla No. 2 - La regla del acceso garantizadoCada tem de datos debe ser lgicamente accesible al ejecutar una bsqueda 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 razn la definicin de claves primarias para todas las tablas es prcticamente obligatoria.Regla No. 3 - Tratamiento sistemtico de los valores nulosLa informacin inaplicable o faltante puede ser representada a travs de valores nulosUn 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.Regla No. 4 - La regla de la descripcin de la base de datosLa descripcin 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 informacin 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 travs de sentencias de SQL (o similar).Regla No. 5 - La regla del sub-lenguaje IntegralDebe haber al menos un lenguaje que sea integral para soportar la definicin de datos, manipulacin de datos, definicin de vistas, restricciones de integridad, y control de autorizaciones y transacciones.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 actualizacin de vistasTodas las vistas que son tericamente actualizables, deben ser actualizables por el sistema mismo.La mayora de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos de actualizar vistas complejas.Regla No. 7 - La regla de insertar y actualizarLa capacidad de manejar una base de datos con operandos simples aplica no slo para la recuperacin o consulta de datos, sino tambin para la insercin, actualizacin y borrado de datos'.Esto significa que las clusulas para leer, escribir, eliminar y agregar registros (SELECT, UPDATE, DELETE e INSERT en SQL) deben estar disponibles y operables, independientemente del tipo de relaciones y restricciones que haya entre las tablas o no.Regla No. 8 - La regla de independencia fsicaEl acceso de usuarios a la base de datos a travs de terminales o programas de aplicacin, debe permanecer consistente lgicamente cuando quiera que haya cambios en los datos almacenados, o sean cambiados los mtodos de acceso a los datos.El comportamiento de los programas de aplicacin y de la actividad de usuarios va terminales debera ser predecible basados en la definicin lgica de la base de datos, y ste comportamiento debera permanecer inalterado, independientemente de los cambios en la definicin fsica de sta.Regla No. 9 - La regla de independencia lgicaLos programas de aplicacin y las actividades de acceso por terminal deben permanecer lgicamente inalteradas cuando quiera que se hagan cambios (segn los permisos asignados) en las tablas de la base de datos.La independencia lgica de los datos especifica que los programas de aplicacin y las actividades de terminal deben ser independientes de la estructura lgica, por lo tanto los cambios en la estructura lgica no deben alterar o modificar estos programas de aplicacin.Regla No. 10 - La regla de la independencia de la integridadTodas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catalogo, no en el programa de aplicacin.Las reglas de integridadNingn componente de una clave primaria puede tener valores en blanco o nulos (sta es la norma bsica de integridad).Para cada valor de clave fornea deber existir un valor de clave primaria concordante. La combinacin de estas reglas aseguran que haya integridad referencial.Regla No. 11 - La regla de la distribucinEl sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos est distribuida fsicamente en distintos lugares sin que esto afecte o altere a los programas de aplicacin.El soporte para bases de datos distribuidas significa que una coleccin arbitraria de relaciones, bases de datos corriendo en una mezcla de distintas mquinas y distintos sistemas operativos y que est conectada por una variedad de redes, pueda funcionar como si estuviera disponible como en una nica base de datos en una sola mquina.Regla No. 12 - Regla de la no-subversinSi 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 subversin (violacin) de las restricciones de integridad. Esto no debe ser permitido.

ConclusinLas Bases de Datos desempean un papel fundamental en casi todas las reas de aplicaciones de las computadoras, razn est por la cual se incluye el estudio de las mismas en las Universidades de Ciencias Pedaggicas.Los hiperentornos de aprendizaje como mezcla armoniosa de diferentes tipologas de software educativo sustentado en tecnologa hipermedia, contribuyen de forma eficiente al tratamiento de los contenidos del proceso de normalizacin en las bases de datos, impartidos en las asignaturas Sistemas de Gestin de Base de Datos I y II, los cuales deben dotar a los estudiantes de la carrera de Informtica de las universidades pedaggicas, de las habilidades tcnicas y conocimientos necesarios para resolver problemas aplicados a la vida.Para terminar no olvidemos que sta slo es una metfora visual, no slo es cuestin de tirar caos entre cualquier par de entidades. Aqu se acaba la metfora, como dijimos desde un principio es un modelo semntico y para que el cao sea viable debe haber un verbo o accin que lo justifique y le d sentido. Por ejemplo, el empleado tiene un cnyuge, el vendedor realiza varias ventas, etc. En el DER 5 por ejemplo me resultara difcil encontrar un verbo que justifique una relacin entre las entidades Provincia y Profesin.En fin, retomando el primer tema de este artculo, espero que el enfoque de construir el modelo de datos a partir del hecho registrable les sirva de alternativa para facilitar su interpretacin y lograr su realizacin. Aclaro que la nica originalidad de esta propuesta es la de haber tomado el enfoque por hechos, (el cual se usa para detectar posibles tablas de hecho dentro de un DER ya existente, con el objeto de disear diagramas de estrella o copo de nieve para un datawarehouse[3]y usarlo en forma inversa para la construccin de un DER desde el principio.Si no tuve xito, espero que la metfora del agua les ayude a visualizar rpidamente las posibilidades de ejecutar una consulta en un modelo existente o deficiencias de informacin. Es slo un recurso didctico, pero creo que aqu si hay un poco ms de originalidad.