Universidad Nacional de Ingeniera

Unified Modeling Language

Facultad de Ingeniera Industrial y Sistemas

Ttulo: Modelo Relacional. Teora de Normalizacin.

Objetivos:
Que los estudiantes sean capaces de: Describir las caractersticas fundamentales del modelo relacional. Explicar concepto y caractersticas de normalizacin, Primera Forma Normal y Dependencias Funcionales. Elaborar una propuesta de solucin para ejercicios de normalizacin hasta 1FN.

Sumario: Modelo Relacional Normalizacin Primera Forma Normal Dependencia funcional (DF) Introduccin: En actividades anteriores se estudiaron los distintos modelos de representacin de los datos como el modelo conceptual, el MER y el modelo relacional. Dentro de este ltimo se vio que cada valor dentro de la relacin es un dato elemental, es decir, no descomponible, y una relacin que satisface esto se denomina "Normalizada". En esta actividad se estudiarn las caractersticas principales del modelo relacional, la teora de la Normalizacin, llegando hasta la Primera Forma Normal; as como otros elementos asociados a estos conceptos.

Desarrollo: 2.1.1 Modelo relacional. Uno de los modelos matemticos ms importantes y actuales para la representacin de las bases de datos, es el enfoque relacional. Se basa en la teora matemtica de las relaciones, suministrndose por ello una fundamentacin terica que permite aplicar todos los resultados de dicha teora a problemas tales como el diseo de sub-lenguajes de datos y otros. El trmino relacin se puede definir matemticamente como sigue: Dados los conjuntos D1, D2,...., Dn (no necesariamente distintos), R es una relacin sobre esos n conjuntos si est constituida por un conjunto de n-tuplos ordenados d1, d2,...dn tales que d1 D1, d2 D2,..., dn Dn.

medi@NERO

P gina |1

Universidad Nacional de Ingeniera

Unified Modeling Language
Facultad de Ingeniera Industrial y Sistemas

Los conjuntos D1, D2,..., Dn se llaman dominios de R y n constituye el grado de la relacin. La cantidad de tuplas constituye la cardinalidad. Es conveniente representar una relacin como una tabla bidimensional donde cada fila representa un n-tuplo. En el modelo relacional tanto los objetos o entidades, como las relaciones que se establecen entre ellos, se representan a travs de tablas de doble entrada, que en la terminologa relacional se denominan relaciones.

Cada relacin est compuesta por filas (las ocurrencias de los objetos) y denominadas, en la terminologa relacional como tuplos, tuplas o uplos, uplas (en realidad, n-tuplos, pero en muchos casos se suprime la n cuando no existe posibilidad de confusin). Tambin la relacin est compuesta por columnas (los atributos o campos que toman valores en sus respectivos dominios). Es importante lo siguiente: 1. No hay dos filas (tuplas) iguales. 2. El orden de las filas no es significativo. (1 y 2 se deben a que la relacin es un conjunto). Siendo rigurosos, el orden de las columnas s es significativo, pues representa el orden de los dominios implicados, pero como siempre nos referimos a una columna por su nombre y nunca por su posicin relativa: 1. El orden de las columnas no es significativo. 2. Cada valor dentro de la relacin (cada valor de un atributo) es un dato atmico (o elemental), es decir, no descomponible; por ejemplo: un nmero, una cadena de caracteres. En otras palabras, en cada posicin fila, columna existe un solo valor, nunca un conjunto de valores.

medi@NERO

P gina |2

Universidad Nacional de Ingeniera

Unified Modeling Language
Facultad de Ingeniera Industrial y Sistemas

Una relacin que satisface este ltimo punto se denomina normalizada, aunque veremos ms adelante que, en realidad, lo que ocurre es que est en Primera Forma Normal. La teora de la normalizacin se basa en la necesidad de encontrar una representacin del conjunto de relaciones que en el proceso de actualizacin sea ms adecuada. Llevar una relacin no normalizada a normalizada es muy simple. Existen diferentes niveles de normalizacin que se llaman formas normales que se vern ms adelante.

Ejemplo: Veamos cmo nuestro ejemplo de suministrador y producto se puede representar fcil y claramente mediante el modelo relacional. Los atributos de estas dos entidades son: Suministrador: nmero, que lo identifica, nombre, tipo y municipio donde radica. Producto: nmero, que lo identifica, nombre, precio unitario y peso. Adems, un suministrador puede suministrar muchos productos y un producto puede ser suministrado por varios suministradores. Se conoce la cantidad de un determinado producto que suministra un suministrador dado.

medi@NERO

P gina |3

Universidad Nacional de Ingeniera

Unified Modeling Language
Facultad de Ingeniera Industrial y Sistemas

La representacin en el modelo relacional es ms simple que con el modelo jerrquico y el modelo reticular, ya que con tres tablas se tiene todo el modelo representado. En el modelo relacional el resultado de una demanda es tambin una relacin y las demandas simtricas (en el sentido de ser una la inversa de la otra; por ejemplo, recuperar los nmeros de los suministradores que suministran el producto P4 y recuperar los nmeros de los productos que suministra el suministrador S2) requieren operaciones simtricas.

Ventajas del modelo relacional: 1. Una de las principales ventajas es su simplicidad, pues el usuario formula sus demandas en trminos del contenido informativo de la BD sin tener que atender a las complejidades de la realizacin del sistema, lo que implica gran independencia de los datos. 2. La informacin se maneja en forma de tablas, lo que constituye una manera familiar de representarla. 3. Al igual que en el modelo reticular, si se tienen relaciones normalizadas, no surgen dificultades grandes en la actualizacin. Veamos en el modelo del SUMINISTRADOR-PRODUCTO presentado anteriormente, un ejemplo de cada tipo de operacin de actualizacin: 1. Creacin: aadir un producto P7. Se agrega la nueva ocurrencia en la tabla PRODUCTO. Es posible hacerlo aunque ningn suministrador lo suministre. 2. Supresin: se puede eliminar el suministrador S1 sin perder el producto P6, a pesar de que es el nico suministrador que lo suministra. 3. Modificacin: se puede cambiar el precio del producto P2 sin necesidad de bsquedas adicionales ni posibilidad de inconsistencias. No obstante, veremos que el proceso de normalizacin no es suficiente hasta el punto aqu visto.

2.1.2 Normalizacin. La teora de la normalizacin se ha desarrollado para obtener estructuras de datos eficientes que eviten las anomalas de actualizacin. El concepto de normalizacin fue introducido por E.D. Codd y fue pensado para aplicarse a sistemas relacionales. Sin embargo, tiene aplicaciones ms amplias. La normalizacin es la expresin formal del modo de realizar un buen diseo. Provee los medios necesarios para describir la estructura lgica de los datos en un sistema de informacin.

medi@NERO

P gina |4

Universidad Nacional de Ingeniera

Unified Modeling Language
Facultad de Ingeniera Industrial y Sistemas

Ventajas:

Evita anomalas en la actualizacin. Mejora la independencia de los datos, permitiendo realizar extensiones de la BD, afectando muy poco, o nada, a los programas de aplicacin existentes que acceden a la base de datos.

La normalizacin involucra varias fases que se realizan en orden. La realizacin de la 2da fase supone que se ha concluido la 1ra y as sucesivamente. Tras completar cada fase se dice que la relacin est en: Primera Forma Normal (1FN) Segunda Forma Normal (2FN) Tercera Forma Normal (3FN) Forma Normal de Boyce-Codd (FNBC) Existen, adems, 4FN y 5FN

Las relaciones en 1FN son un subconjunto del universo de todas las relaciones posibles. Las relaciones en 2FN son un subconjunto de las que estn en 1FN y as sucesivamente, como se muestra en la siguiente figura:

medi@NERO

P gina |5

Universidad Nacional de Ingeniera

Unified Modeling Language
Facultad de Ingeniera Industrial y Sistemas

2.1.3 Primera Forma Normal (1FN). Definicin: Primera Forma Normal. Formalmente: Una relacin est en (1FN) si cumple la propiedad de que sus dominios no tienen elementos que, a su vez, sean conjuntos. Toda relacin normalizada, o sea, con valores atmicos de los atributos. La relacin no incluye ningn grupo repetitivo. Desarrollaremos un ejemplo que consiste en el diseo de la base de datos para la automatizacin del control de los pedidos de productos para ilustrar las fases de 1FN hasta 3FN. Supongamos que los modelos para pedir los productos sean como se muestra en la siguiente figura:

El anlisis de este pedido muestra que los siguientes datos son de inters. El nmero de pedido es nico y se utiliza para referirse a un pedido, por tanto, se usar como clave (llave). El anlisis de este pedido muestra que los siguientes datos son de inters. El nmero de pedido es nico y se utiliza para referirse a un pedido, por tanto, se usar como clave (llave). NUPED numPedido FECHA fechaPedido NUPROV numProveedor NOPROV nombreProveedor DIREC direccionProveedor NUPROD numProducto DESC descripcion PRUN precioUnitario CANT cantidad PRPROD importe PRPED totalImporte

medi@NERO

P gina |6

Universidad Nacional de Ingeniera

Unified Modeling Language
Facultad de Ingeniera Industrial y Sistemas

En forma de relacin se escribira:

PEDIDO (NUPED, FECHA, NUPROV, NOPROV, DIREC, NUPROD, DESC, PRUN, CANT, PRPROD, PRPED) Pedido = {numPedido, fechaPedido, numProveedor, nombreProveedor, direccinProveedor, numProducto, descripcin, precioUnitario, cantidad, importe, totalImporte}

Este pedido contiene 5 grupos repetitivos: NUPROD, DESC, PRUN, CANT, PRPROD {numProducto, descripcin, precioUnitario, cantidad, importe }, ya que puede contener ms de una lnea de pedido.

Hay que eliminar esos grupos. Para ello se crea: 1. Una relacin para los campos que sean nicos.
PEDIDO (NUPED, FECHA, NUPROV, NOPROV, DIREC, PRPED). Pedido = {numPedido, fechaPedido, numProveedor, nombreProveedor, direccinProveedor, totalImporte}

2. Una relacin para los grupos repetitivos.

PED-PROD (NUPED, NUPROD, DESC, PRUN, CANT, PRPROD). PedidoProducto = { numPedido, numProducto, descripcin, precioUnitario, cantidad, importe }

Ambos tienen como llave, o parte de la llave, a NUPED numPedido. Pero en la relacin PedidoProducto PED-PROD es necesaria la llave compuesta para identificar los productos individuales.

Anomalas de actualizacin: Insert, Update, Delete. Esta 1FN tiene problemas de actualizacin: Creacin: La informacin sobre un nuevo producto no se puede insertar si no hay un pedido que lo incluya. Supresin: Eliminar una lnea de pedido que sea la nica que pida un producto implica perder la informacin del producto. Modificacin: Cada lnea de pedido en la que se solicite determinado artculo repite la informacin sobre ste. Si cambia algn atributo del artculo, entonces es necesario hacer muchas actualizaciones.

medi@NERO

P gina |7

Universidad Nacional de Ingeniera

Unified Modeling Language
Facultad de Ingeniera Industrial y Sistemas

2.1.4 Dependencias Funcionales (DF) Definicin: Dependencia Funcional (DF): Dada una relacin R, se dice que el atributo Y de R es funcionalmente dependiente del atributo X de R, si y slo si, cada valor X en R tiene asociado a l, precisamente, un valor de Y en R en cualquier momento del tiempo. XY Ejemplo en la relacin SUMINISTRADOR:

SNOM (nomSuministrador), TIPO (tipoSuministro) y MUN municipio son funcionalmente dependientes cada uno de SNUM (nomSuministrador), ya que para un valor de SNUM (numSuministrador) existe un valor correspondiente de SNOM (nombreSuministrador), TIPO (tipoSuministro) y MUN( municipio).

Estas 4 son formas de representar las dependencias funcionales. El reconocimiento de las dependencias funcionales es una parte esencial de la comprensin de la semntica, del significado del dato. El hecho de que MUN dependa funcionalmente de SNUM (numSuministrador) significa que cada suministrador est situado en un municipio. La nocin de dependencia funcional puede ser extendida hasta cubrir el caso en que X, Y o ambos atributos sean compuestos.

medi@NERO

P gina |8

Universidad Nacional de Ingeniera

Unified Modeling Language
Facultad de Ingeniera Industrial y Sistemas

Ejemplo en la relacin SP (Suministro_Producto):

El atributo CANT es funcionalmente dependiente del par de atributos S,P (numSuministrador, numProducto)

2.1.4.1 Dependencia funcional completa El atributo Y es funcionalmente dependiente y completamente del atributo X, si es funcionalmente dependiente de X y no es funcionalmente dependiente de algn subconjunto de X. Se representa: X Y Ejemplo en la relacin SUMINISTRADOR: MUN es funcionalmente dependiente de (SNUM, SNOM), pero no es funcionalmente dependiente y completamente de (SNUM, SNOM), ya que tambin es funcionalmente dependiente de SNUM. Ejemplo en la relacin SP: CANT es funcional y completamente dependiente de (S,P)

2.1.4.2 Determinante. Cualquier atributo del cual depende funcional y completamente cualquier otro atributo. O sea, la parte izquierda de la implicacin cuando la dependencia funcional es completa. Ejemplo en la relacin SUMINISTRADOR: SNUM es un determinante. Al hablar de entidad en el MER, se asumi que existe una llave, un conjunto de atributos que definen de forma nica una entidad. Un concepto anlogo se define para las relaciones. 2.1.4.3 Llave. Si R es una relacin con atributos A1, A2, ....An y X es un subconjunto de A1, A2, ...An, X es una llave de R si: 1- X A1, A2, ...An o sea, todos los atributos de la relacin dependen funcionalmente de X. 2- Formula. (esta condicin de minimalidad no se requera para el concepto de llave en el MER). Una relacin puede tener varias llaves. Una de ellas se nombra "llave primaria" (la que se escoja para trabajar) y las restantes se nombran "llaves candidatas".

medi@NERO

P gina |9

Universidad Nacional de Ingeniera

Unified Modeling Language
Facultad de Ingeniera Industrial y Sistemas

Una supe llave ser cualquier supe conjunto de una llave. Entonces, una llave es un caso especial de supe llave.

2.1.4.4 Procedimiento para hallar la llave: Supongamos una relacin R(A,B,C,D,E) con las siguientes dependencias funcionales: 1. A B 2. BC D 3. AB E Para comenzar, se parte de que no existen ms llaves que dependencias funcionales, pues el concepto de llave incluye la existencia de dependencia funcional. Se analiza, por tanto, cada una de las DF presentes en la relacin, aadiendo los atributos que sean imprescindibles en la parte izquierda para lograr determinar a todos los atributos de la relacin. El conjunto de atributos as formado debe ser mnimo. Luego se analiza cada uno de esos conjuntos mnimos, de forma que, si alguno es un supe conjunto de otro, ya no es llave, sino supe llave. Pueden resultar varias llaves candidatas. En el ejemplo: 1. A B 2. BC D 3. AB E AC A B E C D AC es llave BCA B C D A E BCA es supe llave ABC A B E C D ABC es supe llave

La nica llave es AC. No hay ninguna otra llave candidata, pues en las otras DF se obtiene el mismo conjunto (ABC) y contiene a AC. Ejemplo: Sea la relacin R (ciudad, calle, cdigo postal). Para abreviar, R(C, A, P) donde se tiene que: Una calle en una ciudad tiene un cdigo postal: CA P El cdigo postal tiene una estructura tal que su valor determina la ciudad: P C Pero en una ciudad, varias calles pueden tener el mismo cdigo, por lo que no se cumple P A. Entonces, CA es llave, ya que determina a todos los atributos de R (determina a P y obviamente a s mismo), CA CAP. P determina a C y no a A, pero haciendo: PA CA, es obvio que PA PA tambin, entonces PA CAP, por tanto, PA tambin es llave. PA y CA son llaves candidatas. En ninguno de los casos un subconjunto de ellas es tambin llave. 2.1.4.5 Atributo llave. Un atributo Ai de R es un atributo llave si l es (o es miembro de) una llave (candidata o primaria). 2.1.5.6 Atributo no llave. Un atributo Aj de R es un atributo no llave si l no es miembro de ninguna llave candidata. En el ejemplo, C, A y P son todos atributos llaves.

medi@NERO

Pgina | 10

Universidad Nacional de Ingeniera

Unified Modeling Language
Facultad de Ingeniera Industrial y Sistemas

Resumen: La teora de la normalizacin se ha desarrollado para obtener estructuras de datos eficientes que eviten las anomalas de actualizacin. La normalizacin es la expresin formal del modo de realizar un buen diseo. Provee los medios necesarios para describir la estructura lgica de los datos en un sistema de informacin. La normalizacin involucra varias fases que se realizan en orden (1ra, 2da, 3ra, FNBC, 4ta y 5ta) Formalmente, una relacin est en Primera Forma Normal (1FN) si cumple la propiedad de que sus dominios no tienen elementos que, a su vez, sean conjuntos, o sea, cuando la relacin no incluye ningn grupo repetitivo. Dada una relacin R, se dice que el atributo Y de R es funcionalmente dependiente del atributo X de R, si y slo si, cada valor X en R tiene asociado a l, precisamente, un valor de Y en R en cualquier momento del tiempo. El reconocimiento de las dependencias funcionales es una parte esencial de la comprensin de la semntica, del significado del dato. Una llave es un conjunto de atributos que definen de forma nica una entidad. Una relacin puede tener varias llaves. Una de ellas se nombra "llave primaria" (la que se escoja para trabajar) y las restantes se nombran "llaves candidatas".

Referencia y Bibliografa: Mato Garca, Rosa Mara. Diseo de Bases de Datos. Ciudad de La Habana. 2002 Referencia URL:
http://informatica.cubaeduca.cu/index.php?option=com_content&view=article&id=11212:modelorelacional-teoria-de-normalizacion-1fn&catid=432&Itemid=184

medi@NERO

Pgina | 11