UNIDAD 4.

DISEO DE BASES DE DATOS RELACIONALES

4.1 CARACTERSTICAS DEL DISEO RELACIONAL
Entre las metas ms importantes que se persiguen al disear un modelo de bases de datos, se encuentran las siguientes que pueden observarse en esta figura.

4.2 DOMINIOS ATMICOS Y LA NORMALIZACIN

Una vez creadas las tablas hay que verificarlas y revisar si an se puede reducir u optimizar de alguna manera. Los problemas tales como la redundancia que ocurren cuando se abarrotan demasiados datos en una sola relacin son llamados anomalas. Los principales tipos son: 1. Redundancia: la informacin se repite innecesariamente en muchas tuplas. En la relacin siguiente, length y filmType. 2. Anomalas de actualizacin: cuando al cambiar la informacin en una tupla se descuida el actualizarla en otra. 3. Anomalas de eliminacin: si un conjunto de valores llegan a estar vacos y se llega a perder informacin relacionada como un efecto de la eliminacin. Si eliminamos al actor Emilio Estevez, perdemos tambin la tupla de la pelcula MightyDucks. title Star Wars Star Wars year length 1977 124 1977 124 filmType color color studioName Fox Fox starName Carrie Fisher Mark Hamill

Star Wars Mighty Ducks Wayne's World Wayne's World

1977 1991 1992 1992

124 104 95 95

color color color color

Fox Disney Paramount Paramount

Harrison Ford Emilio Estevez Dana Carvey Mike Meyers

4.3 DEPENDENCIAS FUNCIONALES

Las dependencias funcionales son restricciones de integridad sobre los datos. Conocer las dependencias funcionales en el momento del diseo de la base de datos permite crear mecanismos para evitar la redundancia (y los potenciales problemas de integridad que eso conlleva) y mejorar la eficiencia ANOMALAS DE DATOS Comportamientos anmalos que se pueden presentar al insertar, borrar y actualizar datos en una base de datos relacional, producidos por un diseo deficiente. ANOMALA DE INSERCIN La existencia de un objeto requiere la existencia de otro objeto independiente. Ej: Factura (nfact, ncliente, nombre, direccion, total) Para aadir un cliente nuevo obligatoriamente necesito crear una factura para ese cliente. ANOMALA DE BORRADO El borrado (rutinario) de un registro puede hacer que se pierda (borre) informacin que no se quera eliminar. Si se elimina una factura y es la ltima de un cliente, se pierde la informacin de ese cliente. (Prdida de datos) ANOMALA DE ACTUALIZACIN Para cambiar el valor de un atributo, se necesita cambiarlo simultneamente en varios sitios, en lugar de en uno. Para cambiar la direccin de un cliente, hay que hacerlo en todas las facturas que tenga, aunque el cliente slo tiene una direccin. (por la redundancia) COMO OBTENER LAS DEPENDENCIAS FUNCIONALES? La mejor manera de obtenerlas es a travs del conocimiento del problema. Es lo ms disponible en la fase de diseo de una base de datos. Sin embargo, esto puede tornarse bastante difcil, como en el caso del vehculo (honestamente, esto puede 2

ocurrir cuando la base de datos modela conocimiento tcnico, que escapa al sentido comn). Otra manera, relacionada con el ejemplo anterior, es comprobar dependencias funcionales sobre una gran poblacin de datos usando la definicin. EJEMPLO Una dependencia funcional es una relacin de dependencia entre uno o ms atributos. Por ejemplo si conocemos el valor FechaDeNacimiento podemos conocer el valor de Edad. Las dependencias funcionales se escriben utilizando una flecha, de la siguiente manera: FechaDeNacimiento -> Edad Aqu a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de FechaDeNacimiento. De la normalizacin (lgica) a la implementacin (fsica o real) puede ser sugerible tener stas dependencias funcionales para lograr mayor eficiencia en las tablas. VEAMOS OTRO EJEMPLO: Tenemos la entidad Entidad Auto (CodigoAuto, Modelo, NroPlaca, Color, Capacidad, Ao)

DEPENDENCIA FUNCIONAL TRANSITIVA Supongamos que en una relacin en la que los estudiantes solo pueden estar matriculados en un solo curso y supongamos que los profesores solo pueden dar un curso. ID_Estudiante -> Curso_Tomando Curso_Tomando -> Profesor_Asignado ID_Estudiante -> Curso_Tomando -> Profesor_Asignado Entonces tenemos que ID_Estudiante determina a Curso_Tomando y el Curso_Tomando determina a Profesor_Asignado, indirectamente podemos saber a travs del ID_estudiante el Profesor_Asignado. Entonces en la relacin tenemos una dependencia transitiva entre alumno y profesor.

VEAMOS OTRO EJEMPLO: IdCliente -> Venta realizada Venta realizada -> Vendedor encargado IdCliente -> Venta realizada -> Vendedor encargado Entonces tenemos que el IdCliente determina a quin se le hizo la venta, y la venta realizada determina qu vendedor llev a cabo la venta. Entonces en la relacin tenemos una dependencia transitiva entre el cliente y el vendedor.

NORMALIZACIN DE DATOS
La normalizacin de datos es el proceso de transformacin de las entidades complejas en entidades simples, siempre que se normaliza se crean por lo menos dos entidades nuevas. Esta es otra forma de encontrar las entidades del proceso de negocio, por medio de los documentos que son los que se puede normalizar, podemos disear los modelos de datos. CUL ES EL OBJETIVO DE LA NORMALIZACIN? El objetivo principal es el de evitar la redundancia de los datos en las tablas, mejorar u optimizar el diseo del sistema para brindar una mejor performance de los procesos. Solo un diseo normalizado puede garantizar que nuestro sistema cumple con los requisitos de los usuarios. Adems Evitar problemas de actualizacin de los datos en las tablas. Proteger la integridad de los datos.

EVITAR LA REDUNDANCIA!

1 FORMA NORMAL (1FN)

Una relacin se encuentra en primera forma normal si y slo si sus atributos son atmicos, es decir son no descomponibles. El objetivo de la 1FN es hallar aquellos atributos que tienen dependencia funcional directamente con la PK. DEPENDENCIA FUNCIONAL (DF) Es la relacin que existe entre los atributos no primos (no claves) y la clave primaria de la entidad. Ejemplo:

Diremos entonces: El campo Nombre y Apellido tienen DF con la clave Cdigo.Nota1, Nota2 y Promedio no tienen DF con la clave Cdigo. Slo aquellos atributos que pertenezcan a las caractersticas propias de la entidad, tienen dependencia funcional con la PK, sino dependen funcionalmente de la clave principal, entonces no pertenecen a la entidad. PASOS DE LA 1FN: 1. Identificar los grupos repetitivos y no repetitivos (GR, GNR). 2. Remover los GR y crear una nueva entidad con ellos. 3. Llevar la clave a la nueva entidad. Para explicar las formas normales, utilizaremos una factura de venta la cual iremos descomponiendo paso a paso. Tenemos una factura cuyo modelo es simple, una tpica factura de una bodega o una farmacia por ejemplo, debemos ubicar todos aquellos datos que representan informacin importante para el negocio, las listamos para luego proceder a normalizarlo. Aqu la lista de atributos encontrados

4.4. SEGUNDA FORMA NORMAL 2FN

Una relacin estar en 2FN si y slo si est en 1FN y adems se cumple que los atributos no primos tienen dependencia funcional completa con respecto a la clave concatenada o compuesta. DEPENDENCIA FUNCIONAL COMPUESTA (DFC) Es la relacin que existe entre los atributos no primos (no claves) y la clave concatenada, una clave concatenada es aquella que est compuesta por dos o ms atributos claves, la tienen las entidades asociadas y las entidades con relacin identificada. Ejemplo: Una entidad que tiene una clave compuesta

Diremos: Atributo 1 tiene DFC con ambas claves, Atributo 2 no tiene DFC con ambas claves, entonces remover Atributo 2. PASOS DE LA 2FN 1. Identificar los atributos con dependencia funcional incompleta. 2. Remover los atributos con DF incompleta y crear una nueva entidad. 3. Llevar la clave a la nueva entidad.

4.5 3 FORMA NORMAL (3FN)

Una relacin estar en 3FN si y slo si est en 2FN y adems existen atributos no claves que dependen de otros atributos no claves de la entidad compleja. Estos atributos no claves tienen relacin transitiva con la entidad principal. DEPENDENCIA TRANSITIVA Se refiere a la relacin indirecta entre dos o ms entidades, esta relacin indirecta se da por medio de otra entidad que funge de puente entre ambas

Diremos entonces que: La entidad A es transitiva a la entidad C, relacin indirecta por medio dela entidad B PASOS DE LA 3FN 1. Identificar los atributos no claves con DF con otros atributos no claves. 2. Remover los atributos transitivos y crear una nueva entidad. 3. Llevar la clave a la nueva entidad. 4.

Para que un diseo de datos tenga credibilidad y de suficiente soporte al cumplimiento de requerimiento de los usuarios, se acepta hasta la 3FN, es decir, si el diseo se encuentra normalizado hasta la 3FN entonces cumple con los requisitos del sistema, este ejemplo quedara as:

4 FORMA NORMAL (4FN)

Una relacin est en 4FN si y solo si se encuentra en 3FN y se cumple que no existan dependencias multivaluadas en alguno de los atributos no claves. Un atributo multivaluado es aquel que tiene varios posibles valores para una sola instancia de la entidad. Por ejemplo: tenemos una entidad Cliente, cada uno de los clientes registrados puede tener varios telfonos y correos alternativos, entonces estamos ante una dependencia multivaluada entre ambos atributos y el atributo no clave Nombreclie

Debemos resolver creando dos nuevas entidades con los atributos multivaluados para evitar as la redundancia de datos.

4.6 FORMA NORMAL BOYCE-CODD

Una de las formas normales ms deseables que podemos obtener es la forma normal Boycecodd (BCNF). ELIMINA TODAS LAS REDUNDANCIAS que se pueden descubrir a partir de las dependencias funcionales.

Reglas de Codd
Codd 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 informacin Toda la informacin en un RDBMS est explcitamente representada de una sola manera por valores en una tabla. Regla No. 2 - La regla del acceso garantizado Cada 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 nulos La informacin inaplicable o faltante puede ser representada a travs de valores nulos Regla No. 4 - La regla de la descripcin de la base de datos La 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. Regla No. 5 - La regla del sub-lenguaje Integral Debe 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 vistas Todas 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 actualizar La 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.

10

Regla No. 8 - La regla de independencia fsica El 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. Regla No. 9 - La regla de independencia lgica 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 integridad Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catlogo, no en el programa de aplicacin. Regla No. 11 - La regla de la distribucin 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-subversin 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 subversin (violacin) de las restricciones de integridad. Esto no debe ser permitido.

4.9 INTEGRIDAD DE LA BASE DE DATOS QU TAN LEJOS SE DEBE LLEVAR LA NORMALIZACIN?

La siguiente decisin es qu tan lejos debe llevar la normalizacin? La normalizacin es una ciencia subjetiva. Determinar las necesidades de simplificacin depende de nosotros. Si nuestra base de datos va a proveer informacin a un solo usuario para un propsito simple y existen pocas posibilidades de expansin, normalizar los datos hasta la 3FN quiz sea algo exagerado. Las reglas de normalizacin existen como guas para crear tablas que sean fciles de manejar, as como flexibles y eficientes. A veces puede ocurrir que normalizar los datos hasta el nivel ms alto no tenga sentido. Se estn dividiendo tablas slo para seguir las reglas o estas divisiones son en verdad prcticas?. stas son el tipo de cosas que nosotros como diseadores de la base de datos, necesitamos decidir, y la experiencia y el sentido comn nos pueden auxiliar para tomar la decisin correcta. La normalizacin no es una ciencia exacta, ms bien subjetiva. Existen seis niveles ms de normalizacin que no se han discutido aqu. Ellos son Forma Normal Boyce-Codd, Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o Forma Normal de Proyeccin-Unin, Forma Normal de Proyeccin-Unin Fuerte, Forma Normal de

11

Proyeccin-Unin Extra Fuerte y Forma Normal de Clave de Dominio. Estas formas de normalizacin pueden llevar las cosas ms all de lo que necesitamos. stas existen para hacer una base de datos realmente relacional. Tienen que ver principalmente con dependencias mltiples y claves relacionales.

EN RESUMEN
La normalizacin es una tcnica que se utiliza para crear relaciones lgicas apropiadas entre tablas de una base de datos. Ayuda a prevenir errores lgicos en la manipulacin de datos. La normalizacin facilita tambin agregar nuevas columnas sin romper el esquema actual ni las relaciones. Existen varios niveles de normalizacin: Primera Forma Normal, Segunda Forma Normal, Tercera Forma Normal, Forma Normal Boyce-Codd y Cuarta Forma Normal. Cada nuevo nivel o forma nos acerca ms a hacer una base de datos verdaderamente relacional. Las primeras tres formas proveen suficiente nivel de normalizacin para cumplir con las necesidades de la mayora de las bases de datos. Normalizar demasiado puede conducir a tener una base de datos ineficiente y hacer a su esquema demasiado complejo para trabajar. Un balance apropiado de sentido comn y prctico puede ayudarnos a decidir cundo normalizar.

12