INSTITUTO TECNOLGICO DE TLALPAN ARREGUIN BOLAOS VICTOR HUGO ALEJANDRO VILLEGAS FUNDAMENTOS DE BASES DE DATOS SEMESTRE TICS DISEOS

DE BASES DE DATOS RELACIONALES

DISEO DE BASES DE DATOS RELACIONALES CARACTERISTICAS Una base de datos relacional se compone de varias tablas o relaciones. No pueden existir dos tablas con el mismo nombre ni registro. Cada tabla es a su vez un conjunto de registros (filas y columnas). La relacin entre una tabla padre y un hijo se lleva a cabo por medio de las claves primarias y ajenas (o forneas). Las claves primarias son la clave principal de un registro dentro de una tabla y stas deben cumplir con la integridad de datos. Las claves ajenas se colocan en la tabla hija, contienen el mismo valor que la clave primaria del registro padre; por medio de stas se hacen las relaciones. PRIMERA FORMA NORMAL Un atributo es atmico si sus elementos se pueden considerar como unidades indivisibles: Ejemplos de dominios no atmicos: Nombre (atributo compuesto) Telfonos (Atributos multivaluados) Un esquema R satisface la primera forma normal si los dominios de todos los atributos son atmicos Los valores no atmicos complican el almacenamiento y pueden probocar redundancias: Por ejemplo, cuentas bancarias almacenadas con sus Propietarios Respetar la atomicidad y no intentis soluciones inteligentes Por ejemplo una cadena de caracteres debe tener un significado indivisible. Supongamos que en la base de datos de la universidad a los

profesores se les asigna identificadores del tipo: LAN013 Donde los tres primeros caracteres se refieren al departamento en el que se encuentran. Hacer esto es una idea muy mala puesto que la informacin se codifica a nivel de programa y no de base de datos.

SEGUNDA FORMA NORMAL Cada atributo que no sea una clave primaria debe depender nicamente de esa Para normalizar divide la tabla Por ejemplo registro(estudiante_id, estudiante_nombre, curso_id, curso_nombre) Satisface los requerimiento de 1FN con clave primaria (estudiante_id, curso_id) nombre_estudiante depende de estudiante_id pero no de la pareja (estudiante_id, curso_id) Dibidir en tablas tres tablas estudiante(estudiante_id, estudiante_nombre) asignatura(asignatura_id,asignatura_nombre) registro(estudiante_id, asignatura_id) Ahora podemos tener datos de estudiantes que no estan matriculados en ninguna asignatura, asignaturas que no tienen ningn estudiante y no necesitamos repetir los datos de estudiante/asignatura para cada registro ASEGURAROS DE NO PERDER INFORMACION AL

PARTIR LA RELACION EN VARIAS TABLAS

TERCERA FORMA NORMAL Un atributo depende transitivamente de la clave primaria si depende en otro atributo que a su vez depende en la clave La tercera forma normal elimina estas dependencias Por ejemplo pedido(pedido_id, fecha, cliente_id, cliente_nombre) satisface 1FN y 2FN con clave primaria pedido_id pero cliente_nombre cambia si cambia cliente_id As que debemos dividir la tabla en: pedido(pedido_id, fecha, cliente_id) cliente(cliente_id,cliente_nombre) FORMA NORMAL DE BOYCE-CODD La Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en la normalizacin de bases de datos. Es una versin ligeramente ms fuerte de la Tercera forma normal (3FN). La forma normal de Boyce-Codd requiere que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave candidata. En una tabla en 3FN, todos los atributos dependen de una clave, de la clave completa y de ninguna otra cosa excepto de la clave (excluyendo dependencias triviales, como ). 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 terminos menos formales, una tabla est en FNBC si est en 3FN y los nicos determinantes son claves candidatas. Consideremos una empresa donde un trabajador puede trabajar en varios departamentos. En cada departamento hay varios responsables, pero cada trabajador slo tiene asignado uno. Tendramos una tabla con las columnas: IDTrabajador, IDDepartamento, IDResponsable La nica clave candidata es IDTrabajador (que ser por tanto la clave primaria).

Si aadimos la limitacin de que el responsable slo puede serlo de un departamento, este detalle produce una dependencia funcional ya que: Responsable Departamento Por lo tanto hemos encontrado un determinante (IDResponsable) que sin embargo no es clave candidata. Por ello, esta tabla no est en FNBC. En este caso la redundancia ocurre por mala seleccin de clave. La repeticin del par [IDDepartamento + IDResponsable] es innecesaria y evitable. Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la FNBC. Un ejemplo de tal tabla es (teniendo en cuenta que cada estudiante puede tener ms de un tutor): Referencia cruzada de Tutor/Estudiante ID Tutor Nmero de seguro social del tutor ID Estudiante 1078 1078 1293 1480 088-51-0074 088-51-0074 096-77-4146 072-21-2223 31850 37921 46224 31850

El propsito de la tabla es mostrar qu tutores estn asignados a qu estudiantes. Las claves candidatas de la tabla son:

{ID Tutor, ID Estudiante} {Nmero de seguro social del tutor, ID Estudiante}

ALGORITMOS DE DESCOMPOSICIN EN FNBC CON LA PROPIEDAD LJ No preservan dependencias. Sea R(T,m) donde `m' es un recubrimiento no redundante, si existe una dependencia X ! A que pertenece a m donde X no es clave primaria, proyectamos R en R1 y R2 donde T1 = X " {A} (atributos de la dependencia) y T2 = T - {A} (atributos de la dependencia excepto la parte derecha que hemos escogido) y cumpliendo (T1 " T2) ! (T1 - T2).

El ejercicio acabar siempre: Si " k ! A ; Si " k ! A EJERCICIO: Sea R(T,m) donde: T = curso, profesor, hora, aula, estudiante y grado.

FORMAS NORMALES SUPERIORES Puede que en algunos casos el empleo de las dependencias funcionales para la descomposicion de los esquemas no sea suficiente para avitar la repeticion innecesaria de informacion. Considerese una ligera variacion de la definicion del conjunto de entidades empleado en la que se permite que los empleados tengan varios numeros de telefono, alguno de los cuales puede ser compartido entre varios empleados. Entonces, numero_telefono sera un atributo multivalorado y, de acuerdo con las reglas para la generacion de esquema a partir de los diseos E-R, habra dos esquemas, uno por cada uno de los atributos multivalorados numero_telefono y nombre_subordinado: (id_empleado,nombre_subordinado)(id_empleado,numero_telefono) Si se combinan estos esquemas para obtener (id_empleado,nombre_subordinado,numero_telefono) Se descubre que el resultado se halla en la FNBC, ya que solo se cumplen dependencias funcionales no triviales. En consecuencia, se puede pensar que ese tipo de combinacion es una buena idea. Sin embargo se trata de una mala idea, como puede verse si se considera el ejemplo de un empleado con dos subordinados y dos numeros de telefono. Por ejemplo, sea el empleado con id_empleado 9999999999 que tiene dos subordinados llamados David y Guillermo y dos numeros de telefono, 512555123 y 512555432. En el esquema combinado hay que repetir los numeros de telefono una vez por cada subordinado: (9999999999, David, 512555123) (9999999999, David, 512555432) (9999999999, Andres, 512555123) (9999999999, Andres, 512555432) Si no se repitieran los numeros de telefonos y solo se almacenaran la primera y la ultima tupla, se habrian guardado el nombre de los subordinados y los numeros de telefono, pero las tuplas resultantes implicarian que David corresponderia al 512555123 y que Andres corresponderia al 512555432. Como sabemos, esto es incorecto.

Debido a qu e las formas normales basadas en las dependencias funcionales no son suficientes para tratar con sustituciones como esta, se han definido otras dependencias y formas normales . INTEGRIDAD DE BASE DE DATOS Regla de integridad de unicidad de la clave primaria La regla de integridad de unicidad est relacionada con la definicin de clave primaria que establece que toda clave primaria que se elija para una relacin no debe tener valores repetidos por lo que el conjunto de atributos CP es la clave primaria de una relacin R, entonces la extensin de R no puede tener en ningn momento dos tuplas con la misma combinacin de valores para los atributos de CP. Regla de integridad de entidad de la clave primaria La regla de integridad de entidad de la clave primaria dispone que los atributos de la clave primaria de una relacin no pueden tener valores nulos. Esta regla es necesaria para que los valores de las claves primarias puedan identificar las tuplas individuales de las relaciones. Si las claves primarias tuviesen valores nulos, es posible que algunas tuplas no se pudieran distinguir. Un SGBD relacional tendr que garantizar el cumplimiento de esta regla de integridad en todas las inserciones y en todas las modificaciones que afecten a atributos que pertenecen a la clave primaria de la relacin. Regla de integridad referencial La regla de integridad referencial est relacionada con el concepto de clave fornea, lo que determina que todos los valores que toma una clave fornea deben ser valores nulos o valores que existen en la clave primaria que referencia. La necesidad de esta regla es debido a que las claves forneas tienen por objetivo establecer una conexin con la clave primaria que referencian. Si un valor de una clave fornea no estuviese presente. Restriccin La restriccin en caso de borrado, consiste en no permitir borrar una tupla si tiene una clave primaria referenciada por alguna clave fornea y la restriccin en caso de modificacin consiste en no permitir modificar ningn atributo de la clave primaria de una tupla si tiene una clave primaria referenciada por alguna clave fornea. Actualizacin en cascada La actualizacin en cascada consiste en permitir la operacin de actualizacin de la tupla, y en efectuar operaciones compensatorias que propaguen en cascada la actualizacin a las tuplas que la referenciaban; se acta de este modo para mantener la integridad referencial. La actualizacin en cascada en caso de borrado consiste en permitir el borrado de una tupla t que tiene una clave primaria referenciada, y borrar tambin todas las tuplas que referencian t y la actualizacin en cascada en caso de modificacin consiste en permitir la modificacin de

atributos de la clave primaria de una tupla t que tiene una clave primaria referenciada, y modificar del mismo modo todas las tuplas que referencian t. Anulacin La anulacin consiste en permitir la operacin de actualizacin de la tupla y en efectuar operaciones compensatorias que pongan valores nulos a los atributos de la clave fornea de las tuplas que la referencian; esta accin se lleva a cabo para mantener la integridad referencial. Los SGBD relacionales permiten establecer que un determinado atributo de una relacin no admite valores nulos, slo se puede aplicar la poltica de anulacin si los atributos de la clave fornea s los admiten. Ms concretamente, la anulacin en caso de borrado consiste en permitir el borrado de una tupla t que tiene una clave referenciada y, adems, modificar todas las tuplas que referencian t, de modo que los atributos de la clave fornea correspondiente tomen valores nulos y la anulacin en caso de modificacin consiste en permitir la modificacin de atributos de la clave primaria de una tupla t que tiene una clave referenciada y, adems, modificar todas las tuplas que referencian t, de modo que los atributos de la clave fornea correspondiente tomen valores nulos. Regla de integridad de dominio La regla de integridad de dominio est relacionada con la nocin de dominio. Esta regla establece dos condiciones. La primera condicin consiste en que un valor no nulo de un atributo Ai debe pertenecer al dominio del atributo Ai; es decir, debe pertenecer a dominio(Ai). Esta condicin implica que todos los valores no nulos que contiene la base de datos para un determinado atributo deben ser del dominio declarado para dicho atributo. La segunda condicin sirve para establecer que los operadores que pueden aplicarse sobre los valores dependen de los dominios de estos valores; es decir, un operador determinado slo se puede aplicar sobre valores que tengan dominios que le sean adecuados.