Bases de datos - ALIPSO.COM: Monografías, resúmenes, biografias y tesis gratis.
Aprende sobre marketing online, desarrollo de sitios web gratis en Youtube
Suscribite para recibir notificaciones de nuevos videos:
Viernes 29 de Marzo de 2024 |
 

Bases de datos

Imprimir Recomendar a un amigo Recordarme el recurso

Objetivos de las “Bases de Datos”. Abstracción de datos. Facilidades del “Sistema de Gestión de Bases de Datos” (SGBD). Estructura general de los SGBD. Algoritmos. Cobertura canónica.

Agregado: 30 de AGOSTO de 2003 (Por Michel Mosse) | Palabras: 7943 | Votar | Sin Votos | Sin comentarios | Agregar Comentario
Categoría: Apuntes y Monografías > Computación > Varios >
Material educativo de Alipso relacionado con Bases datos
  • Oficio con pedido de informes sobre datos sociedad comercial:
  • LMD (Lenguaje de Manipulación de Datos): Programación. Claúsula IN. Claúsula BETWEEN. Claúsula LIKE. Expresiones aritméticas. Funciones de columna.
  • Algoritmos y Estructuras de Datos I: Algoritmos y Estructuras de Datos I Facultad de Ciencias Exactas y Naturales: Universidad de Buenos Aires Primer Cuatrimestre de 2000: Práctica 3 Primera Parte: Tipos Abstractos de Datos. Segunda Parte: Listas.

  • Enlaces externos relacionados con Bases datos

    Bases de datos.

    Tema 1.

    Introducción.

    1.0 Prefacio.

    1.1 Objetivos de las "Bases de Datos".

    1.2 Abstracción de datos.

    1.3 Modelos de datos.

    1.4 Facilidades del "Sistema de Gestión de Bases de Datos" (SGBD).

    1.5 Tipos de usuarios.

    1.6 Estructura general de los SGBD.

    1.0 Prefacio.

           BD: Conjunto de datos interrelacionados que se ajustan a una serie de modelos preestablecidos que recogen información de interés de objetos del mundo real.

           SGBD: (DBMS) Software encargado de gestionar los datos de la BD. Su misión es proporcionar mecanismos de acceso a los datos para almacenar, definir, recuperar,... información de forma eficiente. Existen además una serie de aplicaciones en torno al SGBD que aportan interfaces sencillos para manejar los datos.

    1.1 Objetivos de las "Bases de datos".

           Control centralizado de la información. Los sistemas tradicionales de ficheros nos permiten centralizar la información por medio de varios programas de diseño. Ahora bien, siguiendo las normas estandarizadas de las bases de datos actuales podemos acceder a todos los datos mediante un único programa -administrador de bases de datos-.

           Disminuir la redundancia y evitar la inconsistencia. Son objetivos básicos de una base de datos eficiente. Disminuir la redundancia consiste en agrupar todos los datos en un mismo objeto sin repetir información. Esto no puede realizarse siempre, con lo cual hay ocasiones en las que se duplica información. Es en este punto donde aparece el concepto de inconsistencia. Una base de datos eficiente no puede tener datos contradictorios en aquellos puntos donde se repite la información (No pueden existir dos D.N.I. iguales asociados a nombres de personas diferentes). Cuanta menos redundancia existe, menos posibilidad de inconsistencia existe.

           Posibilidad de compartición de datos. Se consigue disminuyendo la redundancia.

           Mantenimiento de la integridad. Deben existir controles que verifiquen que los datos introducidos son correctos, para lo cual se comparan con otros datos, se crean redundancias de control, se hacen validaciones de rango y se permite al usuario modificar los datos.

           Disponer de un acceso seguro. Imponer controles para acceder o modificar las bases de datos tales como claves de acceso.

           Proporcionar independencia de datos. Establecer una separación entre programas y datos desde una perspectiva física y lógica, de tal forma que cualquier cambio físico o lógico en las estructuras de datos no afecten a los programas de aplicación. Como ejemplo de reestructuración física estaría una división de uno de los ficheros de datos en dos ficheros. Un cambio lógico en la estructura sería añadir un nuevo campo en la base de datos.

    1.2 Abstracción de datos.

    Ha de existir una visión conceptual e integradora de todas las propiedades de un determinado objeto, la cual pertenece al administrador de la base de datos. Por otra parte, cada una de las aplicaciones distintas tienen distintas visiones del objeto cuyos contenidos son un subconjunto de la visión del administrador. De hecho, la visión física del administrador puede tener datos propios (longitud de las cadenas, posibilidad de cadenas nulas,...) que no son usados por las otras visiones o incluso pueden ser reconvertidas para la asignación al resto de las visiones.

    Administrador

    Otra aplicación

    Nivel conceptual

    Nivel interno / físico

    Ejemplo de nivel externo

    Nombre:

    Cadena

    Nombre:

    18 chars

    Nombre:

    Cadena

    Dirección:

    Cadena

    Dirección:

    50 chars

    Dirección:

    Cadena

    DNI:

    Número

    DNI:

    4 bytes

    Salario:

    Número

    Salario:

    4 bytes

    1.3 Modelos de datos.

    Existen modelos de datos que tienen herramientas para relacionar unos datos con otros de la misma forma que ocurre en el mundo real. Dentro de los modelos existentes hoy en día podemos hacer dos clasificaciones:

           Modelos de diseño: Predomina el modelo "Entidad/relación".

           Modelos de representación:

           Primero apareció el modelo jerárquico o de tipo árbol.

           Posteriormente se evolucionó hacia el modelo de red en el que se usan registros unidos por enlaces.

           Actualmente el modelo más usado es el modelo relacional basado en tablas.

    1.4 Facilidades del "Sistema de Gestión de Bases de Datos" (SGBD).

    El SGBD proporciona dos lenguajes:

           Lenguaje de definición de datos (LDD): Conjunto de instrucciones que definen los objetos con sus propiedades, es decir, definen los esquemas o niveles externos, conceptual e interno.

           Lenguaje de manipulación de datos (LMD): Conjunto de instrucciones que permiten realizar consultas y actualizaciones de datos (altas, bajas y modificaciones). Dentro del LMD podemos agrupar un conjunto de instrucciones como "lenguaje de consulta" (LC o también "Query Languaje").

    El SGBD se encarga de interactuar los datos con el "file system". Este permite implantar los controles de integridad definidos para los datos, es decir, se encarga de modificar todas las copias redundantes de la base de datos si una sola de ellas es modificada. El SGBD también se encarga de realizar copias de seguridad y de actualizarlas. Finalmente, otra tarea del SGBD es el control de concurrencia, es decir, permitir o no acceder por varios usuarios a una misma información en un mismo momento.

    1.5 Tipos de usuarios.

           Usuarios ingenuos o accidentales. Interactuan con una base de datos sin saberlo. Normalmente acceden a la base con una aplicación de ventanas y menús con un conjunto de opciones reducidos (Usuario de un cajero automático). Es esta aplicación la que usa la base de datos.

           Usuarios en línea. Tienen acceso a la base de datos a través del lenguaje de consulta (LC o "Query Languaje") e incluso en algunas ocasiones pueden acceder a la base de datos con en lenguaje de manipulación de datos (LMD).

           Programadores de aplicaciones. Han de conocer algún lenguaje de programación de alto nivel denominado "lenguaje anfitrión" tal como el Pascual o el C++ así como el lenguaje de manipulación de datos (LMD) y el lenguaje de definición de datos (LDD). Entonces ha de crear un programa de control en el lenguaje anfitrión insertándole instrucciones del LMD o el LDD. Generalmente las bases de datos ya incluyen compiladores de varios lenguajes preparados para admitir las instrucciones de los LDD y los LMD.

           Administrador de la base de datos (ABD). Se encarga de modificar y mantener los esquemas de la base de datos. Cualquier cambio producido en la base de datos es realizado por el ABD, el cual realiza los cambios de forma transparente para el resto de los usuarios y aplicaciones. El ABD también se encarga de definir las políticas de "backup", controles de integridad y autorizaciones.

    1.6 Estructura general de los SGBD.

    Gestor de ficheros

     


    Datos y diccionario de datos. El DD constituye una pequeña BD con metadatos acerca de la BD.

     

    Una parte del "Gestor de ficheros" está controlada directamente por el SGBD y otra usa el gestor de ficheros del sistema operativo (File system).

    Tema 2.

    Modelo Entidad/Relación.

    2.1 Entidades, atributos y asociaciones.

    2.2 Entidades de datos. Modelación de la variación en el tiempo.

    2.3 Generalización y especialización.

    2.4 Ejemplo de diseño.

    2.1 Entidades, atributos y asociaciones.

    Una entidad representa el conjunto de objetos importantes (objetos tanto tangibles como no) para una organización. Lo primero que hay que hacer en un modelo entidad relación es definir las entidades. Las distintas entidades pueden estar relacionadas o asociadas mediante una definición. Así, una entidad "alumno" interacciona con una entidad "asignatura" mediante la asociación o relación "está matriculado de". Las representaciones tanto de entidades como de relaciones han de tener nombres representativos. Generalmente a las entidades se les asignan sustantivos y a las asociaciones se les asignan verbos.

    Ejemplo:

    Alumno

    Impartir

    Asignatura

    Impartir

    Responsable

    Profesor

    Cada asociación está definida por un nombre y tiene tres propiedades:

           Grado: Es el número de entidades involucradas. Puede ser unario, binario o ternario.

    Alumno

    Alumno

    Asignatura

    Alumno

    Profesor

    Compañero

    Matricularse

    Examinar

    Relación unaria

    Relación binaria

    Relación ternaria

    Asignatura

           Cardinalidad o conectividad: Número de instancias de un conjunto que interactúan con número de instancias de otro conjunto. La cardinalidad puede ser 1:1, 1:N o N:M.

    Relación 1:1 (Marido-Mujer)

    Relación N:1 (Alumno-Clase)

    Relación N:M (Coche-Familia)

           Participación: Determina la opcionalidad u obligatoriedad de una entidad en una relación. Si la participación es obligatoria, todas las instancias de la entidad están asociadas. Por el contrario si existen entidades que pueden no estar relacionadas la participación se denomina opcional.

    Obligatoria hacia la derecha-> (Asignatura-Aula)

    Dirección

    Examinarse

    Alumno

    Asignatura

    DNI

    NExp

    Nombre

    Fecha

    Código

    Nombre

    NCreditos

    Se denominan atributos a unos constructores que nos permiten definir las propiedades de las entidades. Así atributos de la entidad alumno pueden ser su nombre, DNI, dirección o teléfono. En una entidad siempre debe existir algún atributo distinto de todos los elementos del conjunto. Este atributo recibe el nombre de atributo identificador (en el ejemplo del alumno el DNI). En el caso de que un sólo atributo no permita diferenciar totalmente un elemento se pueden tomar varios atributos identificadores. En la representación gráfica, los atributos identificadores se escriben subrayados.

    Los atributos no solo forman parte de la información de las entidades, sino que también pueden referenciar características de las asociaciones (como la fecha del ejemplo). Por otra parte, hay que tener en cuenta que una entidad con un único atributo puede formar por si sola un atributo de otra entidad (no existen entidades con un sólo atributo). Ahora bien, si se pueden dar relaciones con un solo atributo, ya que estas además de dicho atributo contienen los atributos de las entidades a las que relacionan. De forma análoga, un atributo sólo puede tener un valor. En el caso de que un atributo contenga un número variable de valores (sea una lista o conjunto de...) entonces se la puede agrupar en una entidad independiente asociada a la entidad padre (más adelante se verán las entidades dependientes).

    2.2 Entidades de datos. Modelación de la variación en el tiempo.

    Para identificar una asociación entre dos entidades se usan por lo general los dos atributos identificadores de cada entidad. En el caso de una asociación que tenga también atributos, el atributo identificador de la misma también puede ser usado si es requerido. Una forma muy usada de guardar sucesos temporales es asignar a una asociación un atributo de fecha, pero en muchos casos, cuando lo que se quiere es asignar a una sola entidad una lista de acontecimientos sucedidos a lo largo del tiempo se suelen usar unas entidades auxiliares denominadas entidades dependientes.

    Una entidad dependiente no es más que una entidad cuya existencia depende de otra.

    Asignatura

    Oferta de asignatura

    Cuatrimestre ofertado (asignatura)

    En este ejemplo, cuatrimestre ofertado solo existe si existe la asignatura. Cuatrimestre es una entidad dependiente y se representa por una caja con una raya encima. Las entidades dependientes siempre se asocian a otras por medio de una relación 1:N. Los atributos identificadores de una entidad dependiente son dos: El de la entidad fuerte (cod) y otro que permite diferenciar el conjunto de instancias de la entidad débil relacionadas con la entidad fuerte.

    2.3 Generalización y especialización.

    En ciertas ocasiones, varias entidades tienen las mismas características exceptuando algún atributo. En este caso, se puede construir una entidad general que englobe a las anteriores. Esta generalización evita la duplicación de atributos. En este modelo, las entidades del nivel inferior heredan las propiedades de las entidades del nivel superior.

    En el ejemplo, un militar no puede ser a la ver recluta y mando. A este tipo de generalización se la denomina "generalización disjunta". No obstante, existen otros ejemplos en los que si se pueden dar ambos sucesos a la vez. A este nuevo tipo de generalización se le denomina "generalización con solapamiento". En este último tipo de generalización se suele añadir un campo de tipo que nos permita saber si un miembro de la entidad superior pertenece a una u otra entidad inferior (o a ambas).

    Finalmente, existe un tercer tipo de asociación denominada "especialización" que consiste en agrupar dos entidades en principio disjuntas (salvo por algún que otro atributo como el atributo identificativo) para simplificar o aclarar el esquema de la base de datos. Este tipo de asociación se crea de abajo hacia arriba, al contrario que ocurre con las generalizaciones que se forman de arriba hacia abajo. Para distinguir una generalización de una especialización gráficamente estas últimas se representan mediante la letra E.

    Tema 3.

    Modelo relacional.

    3.1 Estructura básica del modelo.

    3.2 Clave y reglas de integridad.

    3.3 Álgebra relacional.

    3.4 Conversión de diagramas E/R a tablas.

    3.5 Ejemplos de aplicación.

    3.1 Estructura básica del modelo.

    Los constructores del modelo son los atributos (también llamados dominio), las tuplas y las relaciones.

           La información de un objeto se registra en términos de atributos. Los atributos tienen que tomar valores de algún tipo, el cual es un conjunto de valores consentido denominado dominio subyacente del atributo. Al definir el dominio aportamos una información substancial al atributo. El concepto de dominio es muy importante en el modelo relacional ya que define muchas propiedades (El problema de la mayoría de los programas gestores de bases de datos que actualmente se venden y que siguen este modelo es que no permiten moldear los dominios). Dentro del modelo relacional sólo se permiten modelos atómicos, es decir, valores que no puedan ser descompuestos en otros más pequeños. Así, por ejemplo, una fecha se considera un tipo de atributo atómico si no se va a operar dentro de la base de datos ni con los días, ni meses, ni años de la misma. En caso contrario, los tipos de atributo serían "tipo día", "tipo mes" y "tipo año". El carácter de atómico por tanto es subjetivo. Para referirnos a atributos simples como un DNI usaremos las letras A,B,C... y para referirnos a atributos compuestos como NOMBRE+APELLIDO1+APELLIDO2 usaremos las letras X,Y,Z...

           Una tupla representa una instancia concreta de un objeto general. Puede ser una instancia entidad o una asociación. La tupla se presenta como un conjunto de valores ordenados para una serie de atributos: t=(a1,a2,a3,...,an) con ai perteneciente a Di=dominio de Ai. (Existen otro tipo de representaciones menos usadas tales como: t=(A1:a1,A2:a2,...,An:an) ).

    El valor que una tupla tiene sobre un atributo concreto se representa con t[Aj]=aj (proyección de la tupla t sobre el atributo j).

    A

    B

    C

    Cabecera de la relación (invariable en el tiempo)

    a1

    b1

    c2

    a1

    b2

    c2

    a1

    b3

    c1

    a2

    b5

    c2

    Cuerpo de la relación (variable en el tiempo)

    a3

    b6

    c3

    a2

    b2

    c3

           Una relación representa al conjunto de todos los atributos j de una instancia concreta. Una relación tiene dos partes: una cabecera que corresponde al esquema de la relación y un cuerpo que corresponde al conjunto de tuplas.

    Una relación se representa por R(R ) donde R es un conjunto de atributos y la relación es un subconjunto del conjunto de todas las combinaciones posibles entre los valores de los dominios subyacentes de los atributos de R.

    3.2 Claves y reglas de integridad.

    En todos los modelos debe de existir una forma de identificar cada tupla de la relación. Para ello se usa un atributo o bien un conjunto de atributos. En muchos casos, varios atributos pueden identificar a una tupla: aparece el concepto de superclave.

           Superclave. Sea R(R) una relación. Un atributo (o conjunto de atributos) X de R es superclave de R(R) si para cualquier elemento t de R, X permite identificar a t de manera unívoca. En el peor de los casos una superclave de una relación coincide con todos los atributos de la misma.

           Clave. K es clave de una relación R(R) si es superclave y no existe un subconjunto de K menor que K que sea superclave. Todos los atributos que participan en una clave candidata se denominan atributos primos.

    Muchas veces se da la situación de que una relación tiene un conjunto de posibles claves (claves candidatas). Entonces, de entre todas estas hay que seleccionar una de ellas como clave de esa relación. A esta clave se la denominará clave primaria. Todos loa atributos que participan en una clave candidata se denominan atributos primos.

           Sea R(R) y S(S ). Suponemos que $KsíR. Si Ks es clave primaria de la relación S, se le denomina clave externa de la relación R para la relación S. Ejemplo:

    EMP(NSS#, Nombre, Ciudad, Departamento#)

    DEP(Departamento#, NombreDep, Otros)

    Departamento# es clave externa de la relación EMP para la relación DEP. Dicho valor sirve para referenciar una tupla de DEP dentro de la relación EMP.

    Las claves externas suponen la herramienta fundamental de conexión entre las relaciones. Nos van a permitir representar las asociaciones que existen entre entidades. Las relaciones R y S no necesariamente tienen que ser disjuntas: EMP(NSS#, Nombre, Ciudad, Dpto#, NSS#_Responsable).

    Reglas de integridad.

    1.   Un valor de clave primaria no puede ser nulo. Ni siquiera uno de los atributos de la clave primaria en particular puede serlo. A esta regla la denominamos regla de integridad de la entidad.

    2.   Si KsíR dadas R(R) y S(S) en una clave externa, entonces "tR, t[Ks]={null|v$t'S/v=t'(Ks)}. Es decir, si sobre una clave externa aparece un valor distinto de nulo, esta regla nos dice que necesariamente tiene que existir una tupla en la relación que de referencia con ese valor de clave primaria (todas las referencias tienen que ser integras y válidas). A esta regla se la denomina regla de integridad referencial.

    La mayoría de las implementaciones obligan a cumplir la 1 regla, pero la 2 no es tan fácil de cumplir por lo que a veces no es obligatoria.

    3.3 Álgebra relacional.

    Es un conjunto de operadores a disposición del usuario para manipular los objetos de la base de datos. Este conjunto es reducido y cerrado (toma como entrada una o dos relaciones y como salida obtiene una nueva relación). Dentro de los operadores del álgebra relacional tenemos:

           Operadores puramente algebraicos. Son los operadores típicos de conjuntos. É (unión), (intersección) y - (diferencia) sólo pueden ser aplicados cuando los esquemas de las relaciones operando sean iguales. x (producto cartesiano) obtiene una relación cuyos atributos son resultado de la concatenación de los atributos de los operandos ( R(A,B,C) x S(B,D,E) = RxS(A,B,C,B,D,E) ).

           Operadores relacionales. Los principales son selección (s), proyección (P), concatenación o "join" () y división ().

           Selección. Dada la relación R se define la relación sp como el conjunto de tuplas de R que satisfacen el predicado p: sp(R)={tR / P(t)}. El esquema de la relación resultante sería R, es decir, el mismo que el de la relación R (Obtenemos un subconjunto horizontal). Ejemplo: Militar(DNI#, Nombre, Rango, Edad). sRango="Cabo"(Militar)={Cabos de la base}

           Proyección. Si xíR se define Px(R) como el conjunto de las proyecciones de las tuplas de R sobre el atributo x: xíR, Px(R)={t[x] / tR}. El esquema obtenido en la relación resultante sería x (Obtenemos un subconjunto vertical de la base de datos). En el caso de obtenerse duplicaciones en el resultado, estas son eliminadas automáticamente.

    Ejemplo: Militar(DNI#, Nombre, Rango, Edad). PRango (Militar)={Rangos distintos}

    Ejemplo: Militar(DNI#, Nombre, Rango, Edad). PRango,DNI# (Militar)={Rangos y DNI's}

           Concatenación. Existen dos tipos de concatenación: Join natural y q_join.

    Join natural: Consideremos R(R) y S(S) tales que RS (tienen algún atributo en común). Se define (RS) como una relación cuyo esquema es la concatenación de los dos esquemas eliminando en uno de ellos los atributos repetidos y cuyos datos son el conjunto resultante de la unión de los datos de las relaciones anteriores.

    Ejemplo:

    R

    (A,

    B)

    S

    (B,

    C)

    RS

    (A,

    B,

    C)

    a1

    b1

    b1

    c1

    a1

    b1

    c1

    a2

    b1

    b2

    c2

    a2

    b1

    c1

    a1

    b2

    b2

    c1

    a1

    b2

    c1

    a1

    b2

    c2

    Se pueden realizar join's sobre un atributo únicamente. En este caso se escribe dicho atributo sobre el símbolo . Generalmente, el join natural se usa para conectar relaciones a través de las claves externas.

    A=D

    R

    (A,

    B)

    S

    (B,

    C,

    D)

    RS

    (A,

    R.B,

    S.B,

    C,

    D)

    a1

    b1

    b1

    c1

    d1

    a1

    b1

    b1

    c1

    d1

    a2

    b1

    b2

    c1

    d1

    a1

    b1

    b2

    c1

    d1

    a1

    b2

    b2

    c1

    d2

    a2

    b1

    b2

    c1

    d2

    a1

    b2

    b1

    c1

    d1

    a1

    b2

    b2

    c1

    d1

    q_join: Es semejante al join natural en su funcionamiento. La diferencia radica en que mientras que el join natural basaba sus relaciones en un atributo común, el join natural la basa en una relación previamente establecida en la que intervienen operadores relacionales {=,<,>,>=,>=,<>}.

           División. Sea R(A1,A2,A3,...,An,B1,B2,...,Bm) y S(B1,B2,...,Bm).El resultado de la división es una nueva relación (RS)(A1,A2,A3,...,An) en la que las tuplas pertenecientes a la misma verifican que "t'=<y>S tiene que existir una tupla t''=<xy>R donde <y>=(B1,...,Bm) y <x>=(A1,...,An).

    Ejemplo: Piloto(DNI#,Avión), Aviones(Avión), PilotoAviones(DNI#)={Pilotos que pilotan todos los tipos de aviones de Aviones}

           Operadores adicionales. Dentro de este tipo de operadores nos encontramos con dos principales: el operador adición () y el operador agrupamiento (S).

           Adición. Sirve para añadir a una relación un determinado atributo en donde el valor que tiene una tupla sobre ese nuevo atributo es el resultado de la expresión que aparece en este formato de la expresión: Expresión Nuevo_atributo (Relación).

    Ejemplo: Productos(Nombre, Precio, Color), Precio*1,15 Precio_IVA(Productos)

    Podemos eliminar el nuevo atributo proyectando la nueva relación sobre el resto de los atributos.

           Agrupamiento. Sirve para reordenar las tuplas de una relación formando grupos. El formato que tiene es el siguiente: SAtributo [Función_agregadaNuevo_Atributo...](R) que produce un ordenamiento de la relación R por el atributo especificado (La parte entre corchetes es opcional). El esquema de la relación resultante es el atributo sobre el que se aplica la misma y los nuevos atributos añadidos si es que los hay.

    Ejemplo: SDNI# (Alumno) crea una lista de DNI's de alumnos ordenados.

    Ejemplo: SNombreMedia(Precio)PrecioMedioCuenta(Ciudad)NumeroCiudades(Producto) con la relación Producto(Nombre, Ciudad, Precio) crea una nueva relación cuyo esquema resultante es (Nombre, PrecioMedio, NumeroCiudades) ordenada por nombres que contiene los precios medios de los productos especificados por el nombre y el número de ciudades que venden dicho producto.

    Las funciones agregadas para este tipo de operación son cuenta, suma, media, máximo y mínimo entre otras.

    3.4 Conversión de diagramas E/R a tablas.

    La regla básica consiste en convertir cada una de las entidades del diagrama en una relación, cuya clave primaria será el identificador de la entidad (En el caso de darnos cuenta de que esto no sucede así es seguramente porque el diagrama del que partimos está mal diseñado). Tenemos los siguientes casos:

           Relación 1:1 de A(A#,otros) con B(B#,otros). En una de las dos relaciones se introduce como clave externa el atributo identificativo de la otra: A(A#,otros,B#) y B(B#,otros) con B# clave externa de A para la relación B. En el caso de opcionalidad a uno de los lados, la clave externa se presentará en la relación correspondiente a la entidad obligatoria.

           Relación 1:N de A(A#,otros) con B(B#,otros) donde A es el lado 1 y B el lado muchos. Se introduce en la relación B el atributo identificativo de la clave A como clave externa quedando A(A#,otros) y B(B#,otros,A#).

           Relación N:M de A(A#,otros) con B(B#,otros). En este caso se crea una nueva relación con el nombre de la asociación que contiene los atributos identificadores de A y B además de los suyos propios en el caso de existir. En el caso de que la clave primaria no coincida con la concatenación de las claves primarias de A y B seguramente es porque hemos realizado un diseño erróneo de la base de datos. Las relaciones resultantes por tanto quedarían: (A#,otros), B(B#,otros), Asociación(A#, B#, otros).

           Asociaciones unarias. El funcionamiento es similar al de las relaciones binarias.

           Asociación ternaria 1:1:1. Además de las relaciones ya existentes se crea una nueva con los atributos de la misma y con las claves externas de dos de las relaciones que participan en la asociación.

           Asociación ternaria 1:1:N. Al igual que en las de tipo 1:1:1 se crea una nueva relación con las claves externas de dos de las relaciones que participan en la asociación, teniendo en cuenta que una de las dos ha de ser la clave primaria de la relación del lado N de la asociación.

           Asociación ternaria 1:N:M. Se crea una nueva asociación cuya clave primaria es resultado de la concatenación de las claves externas para las relaciones del lado N y M.

           Asociación ternaria N:M:Ñ. Se crea una nueva asociación cuya clave primaria corresponde con la concatenación de las tres claves primarias de las relaciones integrantes.

           En las especializaciones y generalizaciones se emplean asociaciones diferentes para supertipos y subtipos siempre y cuando cada uno aparezca en una asociación diferente. En el caso de no aparecer en asociaciones no merece la pera la representación de estas.

    CONVERSIóN DIAGRAMA E/R

    La regla básica consiste en convertir cada una de las entidades del diagrama en una relación, siendo la clave primaria el atributo identificador de la entidad.

    Conversiones:

    A(A#,O_A,B#)

    B# es clave externa para la relación B

    B (B#,O_B)

    La clave externa debe aparecer en la relación correspondiente a la entidad obligatoria.

    A(A#,O_A)

    B(B#,O_B,A#)

    A# clave externa para A

    La relación que se representa en la entidad del lado "muchos" es la que incluye como clave externa el identificador de la entidad del lado "uno" y todos los atributos conectados sobre la asociación.

    A(A#,O_A)

    B(B#,O_B,A#,atr)

    A(A#,O_A)

    B(B#,O_B,A#)

    Las relaciones muchos a muchos generan una nueva relación con el nombre de la asociación, la clave primaria de A, la clave primaria de B y los atributos de la asociación.

    A(A#,O_A)

    B(B#,O_B)

    ASOC(A#,B#, atr) A#B# clave primaria, A# clav. ext. B# clav. ext.

    Si A#B# no forman clave primaria de ASOC debemos pensar que ASOC está mal diseñado y que esa asociación se debe modelar con asociaciones dependientes pues puede estar expresando una variación en el tiempo aunque no siempre ese es el motivo.

    A(A#,O_A,Ref_A#)

    No podemos poner A(A#,O_A,A#) pues habría dos atributos con el mismo nombre. Renombramos el último a Ref_A#.

    Todas las asociaciones ternarias se convierten en una asociación (Excepción: algunas relaciones 1:1:1 no interesan convertirlas en relación y conviene llevar las claves externas a una de las tres relaciones junto con los atributos de la asociación).

    ASOC (A#,B#,C#)

    Las claves, serán:

    -relación 1:1:1 => A#B# ó B#C# ó A#C# ó B#C# (cualquier par entre A#,B#,C#)

    -relación N:1:1 => A#B# ó A#C# (la clave del muchos siempre participa)

    -relación N:M:1 => A#B# (las dos del muchos)

    -relación N:M:L => A#B#C# (las tres)

    Generalizaciones y especializaciones:Se crea una relación para el supertipo si éste aparece en alguna relación y si no, no merece la pena representar el supertipo.

    Borrado de tuplas

    Cuando se borra una tupla, el borrado puede ser:

    - Borrado en cascada (on delete cascade)

    Cuando se borra una tupla referenciada, todas las otras tuplas que la referencian son borradas.

    - Borrado a nulo (on delete null)

    Cuando se elimina una tupla referenciada, aquellos valores que referencian esa tupla, se ponen a nulo.

    - Borrado por defecto (on delete default)

    Cuando se elimina una tupla referenciada, aquellos valores que referencian esa tupla, se ponen a un valor por defecto para ese atributo.

    TEMA 4 - TEORíA DE LA NORMALIZACIóN

    INTRODUCCIóN

    La teoría de la normalización es una teoría sobre el diseño de relaciones que nos proporciona una herramienta que permite definir el nivel de diseño que tiene una relación y herramientas para descomponer una relación y obtener relaciones que estén en el nivel de diseño adecuado.

    Existen dos tipos fundamentales de defectos a la hora de diseñar una relación: redundancia de datos y anomalías de inserción/borrado.

    Supongamos que tenemos la siguiente relación:

    ESTUDIANTE_INFO (Nombre,Cod_Curso,Tfno,Asigantura,Profesor,Nota)

    En este ejemplo hay redundacia de datos, pues un alumno puede estar matriculado en varios cursos. También el nombre de la asignatura o del profesor se repite en todas las tuplas de los alumnos, etc. Estas redundancias pueden producir inconsitencias y poca flexibilidad (p.ej. si un profesor se da de baja hay que cambiar todas las tuplas de los alumnos).

    Las anamolías de inserción se refieren a que no se puede almacenar una información determinada. Por ejemplo, si se crease una nueva asignatura en la que aún no se ha matriculado ningún alumno, cómo representaríamos esa asignatura. No podemos poner (null,null,null,asignutura,profesor,null) pues tendríamos claves primarias con valor null.

    Las anamolías de borrado se refiere a perder información relevante al intentar borrar una información no relevante. Por ejemplo si sólo hay una alumno matriculado en una asignatura y borramos el alumno, tal y como está construida la relación borraríamos también la asignatura.

    La teoría de normalización propone la posibilidad de definir el nivel de diseño y propone herramientas para obtener, a partir de una relación otras relaciones tales que todas esas nuevas relaciones se encuentran en un nivel de diseño mayor que la relación original.

    La descomposición de una relación debe verificar que:

                         sea reversible por concatenación: el join de las relaciones resultantes de la descomposión debe dar como resultado la relación original.

                         toda la información semántica de la relación original debe permanecer en las relaciones resultado, esto es, deben mantenerse las dependencias funcionales.

    DEPENDENCIAS FUNCIONALES

    Son herramientas sencillas que nos permiten formalizar parte de la semántica de la relación.

    Sea R una relación con el esquema R(X,Y,Z), se dice que R satisface la dependencia funcional X->Y (X determina funcionalmente a Y, ó Y depende funcionalmente de X) si cualquiera que sea x valor del dominio de X, la relación Py (sX=x(R)) contiene a la sumo UNA tupla (en otras palabras, asociado a un único valor de x hay un único valor de y). A X se le conoce como antecedente y a Y como consecuente.

    Ejemplo: R( A B C D)

    a1 b2 c1 d1 B->D cierto, todas las tuplas con un valor de B tienen

    a1 b3 c1 d2 asociado un único valor de D (b2->d1,b3->d2)

    a2 b2 c2 d1 A->D falso, pues a1->d1 y a1->d2

    a1 b2 c2 d1 CD->B cierto: c1d1->b2 c1d2->b3 c2d1->b2

    La dependencia funcional es algo virtual, pues si añadimos una nueva tupla las dependencias se pueden romper. Por eso nos fijaremos en las dependencias funcionales asociadas al esquema de la relación, a la parte invariable, para así imponer que cualquier extensión válida de la relación satisfaga esa relación válida.

    P.ej. el código postal, la calle y la ciudad: la calle y la ciudad determinan el mismo código postal. De no ser así, esa tupla será errónea. El sistema de BD debe imponer esa restricción.

    Sea un esquema de relación y sean X,Y í , decimos que X->Y está asociado a si "R(), R satisface necesariamente la dependencia funcional X->Y.

    A partir de ahora, a cada relación le asociaremos un conjunto F de dependencias funcionales.

    AXIOMAS DE AMSTRONG

    Son axiomas que aplicaremos para desarrollar las reglas funcionales. Consideraremos que tenemos una relación y un conjunto de atributos X,Y,Z,W que pueden ser simples o compuestos.

    Axioma 1- Reflexividad: Cualquier relación R() satisface que X->X.

    Axioma 2- Aumentación: Si R satisface X->Y entonces R satisface XZ->Y

    Demostración:

    t1,t2 R / t1(XZ)=t2(XZ) ===(en particular)==> t1(X)=t2(X)

    como por hipótesis R satisface X->Y ==> t1(Y)=t2(Y)

    Axioma 3- Aditividad: Si R satisface X->Y y X->Z entonces R satisface X->YZ.

    Demostración:

    t1,t2 R / t1(X)=t2(X),

    por hipótesis X->Y ==> t1(Y)=t2(Y) |

    X->Z ==> t1(Z)=t2(Z) | ==> t1(YZ)=t2(YZ)

    Axioma 4- Proyectividad: Si R satisface X->YZ ==> R satisface X->Y

    Demostración:

    t1,t2 R / t1(X)=t2(X)

    por hipótesis X->YZ => t1(YZ)=t2(YZ) => t1(Y)=t2(Y) y t1(Z)=t2(Z)

    Axioma 5- Transitividad: Si R satisface X->Y y Y->Z entonces R satisface que X->Z.

    Demostración:

    t1,t2 R / t1(X)=t2(X) y como X->Y => t1(Y)=t2(Y)

    Como R por hipótesis Y->Z t1(Y)=t2(Y) => t1(Z)=t2(Z) => X->Z

    Axioma 6- Pseudotransitividad: Si R satisface X->Y y YW->Z => XW->Z.

    Demostración:

    t1,t2 R / t1(XW)=t2(XW) => t1(X)=t2(X) (1) y t1(W)=t2(W) (2)

    por hipótesis X->Y ==(1)==> t1(Y)=t2(Y) ==(2)==> t1(YW)=t2(YW) =>

    => YW->Z

    Con estas reglas de Armstrong podemos obtener nuevas dependencias funcionales. Un conjunto de dependencias funcionales F infiere una dependencia funcional X->Y (y se representa: F X->Y) si la dependencia funcional X->Y se puede obtener a partir de F por aplicación de los axiomas de Armstrong. Por definición, F infiere a todas las dependencias funcionales de F, esto es, X->Y X->Y.

    CLAUSURAS

    Al conjunto de dependencias funcionales que se infieren a partir de F se lo denomina clausura de F y se denota con F+.

    F+ = {X->Y / F X->Y}

    F+ es un conjunto tal que incluye a F y tal que si aplicamos los axiomas de Armstrong a sus dependencias funcionales no se obtenienen nuevas dependencias funcionales, pues ya incluye a todas las posibles. Por ello (F+)+=(F+).

    Ejemplo: R=(A,B,C) F={A->B,B->C}

    F+= {A->B,B->C,A->A,B->B,C->C,AB->A,ABC->A,AB->C,BC->C....}

    Como F+ es un conjunto muy grande, necesitaremos buscar una herramienta que nos permita saber si una dependencia funcional pertenece a F+ sin tener que calcular F+.

    Definición: Sea un esquema de relación y X un atributo del esquema (X), y sea F un conjunto de dependencias funcionales sobre , se llama clausura de X respecto de F, y se denota con XF+ al atributo más grande de tal que X-> XF+ F+.

    Ejemplo: R(A,B,C) F={A->B,B->C}

    A->A y A->B => A->AB |

    B->C y A->C => A->AC | => A->ABC AF+=ABC

    Proposición

    Sea un esquema de relación, y X,Y , F conjunto DFs sobre , entonces X->Y F+ si y solo si YXF+

    Demostración:

    =>) supongamos que X->Y F+, como X->XF+ F+ y XF+ es el más grande, entonces Y XF+ pues de no ser así XF+ no sería el más grande al faltarle Y.

    <=) X-> XF+ F+ como por hipótesis Y XF+ entonces por el axioma de proyectividad X->Y F+

    ALGORITMO PARA CALCULAR XF+

    Sea R() y F conjunto de DFs sobre , X

    Inicialmente XF+ = X

    Cambio = TRUE

    while (cambio)

    cambio=false

    for (cada DF W->Z F)

    if w XF+ then XF+= XF+ É Z; cambio=true;

    endfor

    endwhile

    END.

    Ejemplo: F={A->G,CD->E,E->C,D->AH,AB->D,DH->BC}

    inicio cd->e d->ah

    (BCD)F+=BCD E AH = BCDEAH (primera pasada)

    a->g

    (BCD)F+ = BCDEAH G Resultado = BCDEAHG

    Supongamos que tenemos R() F={A->B,B->C,A->C} y G={A->B,B->C}. Si observamos G y F notamos que ambos proporcionan la misma información: la dependencia A->C, la podemos conocer con G y los axiomas de Armstrong. G y F recogen en esencia la misma información, y nos interesa más G por ser más manejable.

    Definición: Dos conjuntos de dependencias funcionales F y G se dicen equivalentes y se deonota con FG cuando sus clausuras son iguales: F+=G+. Interesa eliminar las dependencias redundantes (aquellas que pueden obtenerse con el resto de las dependencias) y reducir en lo que podamos el conjunto de Dfs.

    Definición: Sea R() y F un conjunto de Dfs sobre , F se dice redundante si existe un F F tal que F F.

    Ejemplo: F = {A->B,B->A,B->C,A->C} ¿es redundante?. Observemos cada una de las dependencias:

    ¿F-{A->B} A->B? A+F-{A->B}=AC (no está B => esta dependencia no es redundante)

    ¿F-{B->A} B->A? B+F-{B->A}=BC (no está A => esta dependencia no es redundante)

    ¿F-{B->C} B->C? B+F-{B->C}=BAC (está C => esta dependencia es redundante:

    elimina y trabajamos con el resto:)

    F = {A->B, B->A, A->C}

    ¿F-{A->C} A->C? A+F-{A->B}=AB

    Supongamos ahora que F = {A->B, B->C, A->CD}, la dependencia funcional A->CD no es redundante, pero A->CD A->D que no es redundante y A->CD A->C que sí e redundante. Se dice entonces que C es un atributo extraño a la derecha.

    Una dependencia funcional X->Y se dice simple si Y es atributo simple. Todas aquellas dependencias funcionales que no sean simples se pueden descomponer en dependencias simples (por axioma de proyectividad). Así, por ejemplo, si tenemos X->A1A2A3 lo descompondremos en X->A1, X->A2 y X->A3.

    Observemos ahora F = {A->C, BC->D, B->C} , en donde F no redundante pero aquí sus atributos son simples y ocurre que B->C y BC->D B->D (axioma pseudo-transitividad) y B->D BC->D (pero no BC->D B->D). La dependencia B->D aporta más información que BC->D. Se dice que C es un atributo extraño a la izquierda. Nos interesa más trabajar con F = {A->C, B->D, B->C}

    Sea R() y F conjunto de DFs sobre . Sea X->Y F con AC (X es atributo compuesto). Se dice que A es extraño a la dependencia funcional X->Y respecto de F si F-{X->Y}É{X - A->Y} F.

    Consideremos BC->D. Queremos ver si C es extraño en BC->D. Esto sucedería si F{A->C,B->D,B->C} F. Siempre se cumple que F F por el axioma de aumentación, pero lo que puede que no sea cierto es que F F. Eso último sucederá cuando F B->D, pero eso es equivalente a que DB+F. Por consiguiente, C será extraño en BC->D respecto de F si DB+F.

    COBERTURA CANóNICA

    Sea R() y F conjunto de DFs sobre . Se llama cobertura canónica de F a un conjunto Fc tal que Fc es no redundante, todas sus dependencias funcionales son simples y no incluye atributos extraños a la izquierda. La cobertura canónica contiene la esencia de la información que maneja F.

    Método para conseguir una Fc:

    1- desdoblamiento de las dependencias funcionales: si encontramos un dependencia funcional cuyo consecuente sea un atributo doble se transforma en Dfs con consecuentes simples.

    2- eliminación de atributos extraños a la izquierda.

    3- eliminación de redundancias.

    4- agrupacmiento de dependencias funcionales

    Ejemplo:

    Sea R(A,B,C,D,E,F,G,H,I,J) y

    F ={A->B, A->C, B->CD, D->B, ABE->F, E->J, EG->H, H->G}

    Consegir Fc:

    1- Desdoblamiento. Resulta A->B, A->C, B->C, B->D, D->B, ABE->F, E->J, EG->H, H->G}

    2- Eliminación atributos extraños a la izquierda.

    ABE->F

    ¿A extraño? (BE)+F = BECD Como A no pertenece => A no es extraño

    ¿B extraño? (AE)+F = AEBCD... B pertenece => B es extraño

    Quitamos ABE->F y ponemos AE->F

    AE->F

    ¿A extraño? (A)+F = ABCD Como F no pertenece => A no es extraño

    ¿E extraño? (E)+F = EI F no pertenece => E no es extraño

    EG->H

    ¿E extraño? (E)+F = EJ Como H no pertenece => E no es extraño

    ¿G extraño? (G)+F = G H no pertenece => G no es extraño

    3- eliminación redundancias

    ¿A->B? A+F-{A->B}=AC -> no es red.

    ¿B->C? B+F-{B->C}=BD -> no es red.

    ¿D->B? D+F-{D->B}=D -> no es red.

    E->J y H->G no son redundantes

    ¿A->C? A+F-{A->C}=ABCD -> es redundante. Eliminamos A->C

    ¿B->D? B+F-{B->D}=BC -> no es red.

    ¿AE->F? B+F-{B->D}=BC -> no es red.

    ¿EG->H? no es redundante (no hay ningún consecuente H)

    Resulta F={ A->B, B->C, B->D, D->B, AE->F, E->J, EG->H, H->G}

    4- Agrupamientos de Dfs:

    Fc={ A->B, B->CD, D->B, AE->F, E->J, EG->H, H->G}

    RELACION ENTRE DEPENDENCIAS FUNCIONALES Y CLAVES

    Sea R() y F un conjunto de Dfs asociado a , y x . Si encontramos un atributo tal que F X-> (X+F = ) entonces X es una superclave.

    Las dependencias funcionales permiten automatizar el proceso de búsqueda de superclaves.

    Una clave candidata es aquel atributo X tal que no existe X' X tal que (X')+F = , o sea que X-> no contenga atributos extraños a la izquierda.

    Sea R() y Fc, veremos un método que nos permita obtener las claves candidatas de R:

    1- obtener K que contenga aquellos atributos de que no aparecen como consecuente en Fc. Toda clace candidata es un superconjunto de K.

    2- Si K+Fc = => K es la única clave candidata

    3- Si K+Fc => las claces candidatas de R serán de la forma KW, donde W es un atributo simple o compuesto de que no está en -K+Fc (con W -K+Fc).

    Ejemplo:

    Sea R=(ABCDEGH) y F={AC_>DE, B->G, BDE->C, G->H} ya canonizado.

    1- No parecen como consecuente: A B

    2 - (AB)+F=ABGH no es clave candidata. La clave candidata tiene la forma ABX con X{ C,D,E}

    3- Veamos todas las posibles combinaciones:

    (ABC)+F=ABCGHDE = => (ABC) es una clave candidata

    (ABD)+F=ABDGH => (ABD) no es una clave candidata

    (ABE)+F=ABEGH => (ABE) no es una clave candidata

    (ABDE)+F=ABCDEGH => (ABDE) es una clave candidata

    Tenemos dos claves candidatas (ABC) y (ABDE)

    NORMALIZACIóN POR MEDIO DE LAS DFS.

    Existen varios niveles de diseño:

    1FN = 1 forma normal. Es un nivel de diseño que debe existir en toda base de datos relacional. Una entidad está en 1FN cuando todos sus atributos son atómicos, es decir, en sus tuplas no existen grupos repetitivos.

    2FN = Segunda forma normal. Una relación está en 2FN si cada atributo de la relación depende complentamente de una clave candidata. Si una relación ha alcanzado la 2FN, también ha alcanzado la 1FN.

    3FN = Tercera forma normal. Sea R(), Fc, decimos que R está en tercera forma normal si cada dependencia funcional X->Y satisface algunas de estas condiciones:

    1- X es superclave

    2- Y es primo (=participa en una clave candidata -puede no ser simple-)

    Todas las relaciones 3FN son también 2FN.

    FNBC = Forma Normal de Boyce-Codd. Sea R(), Fc, decimos que R está en FNBC si para todo X->Y F, X es una superclave (todas las Dfs deben provenir de claves). Todas las relaciones FNBC son también 3FN.

    Ejemplo:

    R(ABCD) con FR={AB->C,D->C} y S(ABC) FS={AB->C,C->AB}

    ¿Está R en FNBC?

    Primero veremos las claves de R: la única clave que hay es ABD. Todas las Dfs de R no satisfacen la condición de FNBC, por lo tanto no está en FNBC.

    ¿Está S en FNBC?

    Las claves de S son AB y C. Cumple la condición y sí está en FNBC

    Nuestro objetivo es que todas las relaciones estén en FNBC.

    Sea R() una relación con F conjunto de dependencias funcionales y Ri=PX(R), se llama proyección de F a i al conjunto Fi=P F ={X->Y F /X,Y i}

    Si tenemos una relación R() con F conjunto de dependencias funcionales, si R no se encuentra en FNBC realizaremos un proceso de descomposición rR = {R1..Rn} donde Ri es la proyección de R sobre determinados atributos (Ri=PX R)

    Esa descomposición rR debe satisfacer dos propiedades:

    1- rR deber ser "sin pérdida" o reversible por concatenación.

    Es decir, R=R1R2....Rn

    2- rR debe "preservar" las dependencias funcionales, es decir É FiF.

    Ejemplo:

    Sea R(ABC) F={A->B,B->C,C->A}, rR={R1(AB),R2(BC)} ¿preserva rR las Dfs?

    Primero calcularemos las depedendecias sobre cada descomposición

    F1=PAB F = {A->B, B->A} F2=PBC F = {B->C, C->B}

    F1 É F2 F (B->A no apaerece en F pues allí es redundante, pero en F1 no es redundante)

    ALGORITMO DE DESCOMPOSICIóN EN FNBC

    Este algoritmo tiene como entrada R(), Fc y R que no está en FNBC, y obtiene como salida rr / "Ri rR están en FNBC y rR es sin pérdida:

    1- Tomamos una dependencia funcional X->Y F tal que X no es superclave.

    2- Construimos dos relaciones R1=PX,Y(R)=R1(X,Y) y R2=P-Y(R)=R2(-Y). Todos los atributos de R1 menos el consecuente.

    3- Si alguna de las dos relaciones no está en FNBC se vuelve a aplicar el algoritmo.

    El algoritmo garantiza que la descomposición es reversible pero no garantiza que preserve las dependencias funcionales. La salida del algoritmo no es única, y algunas de ellas no preservan las dependencias funcionales.

    Ejemplo:

    R(ABCDE) F={A->B,AC->D,BD->E} que está canonizado.

    Busquemos las claves: sólo hay una AC (AC)+=ABCDE

    1- Tomamos A->B

    2- R1(AB) R2(ACDE)

    3- F1={A->B} clave A => está en FNBC

    F2={AC->D,AD->E} A->B y BD->E => AD->E Clave AC => no está en FNBC

    Aplicamos el algoritmo sobre R2 y F2:

    1- Tomamos AD->E

    2- R3(ADE) y R4(ACD)

    3 F3={AD->E} clave (AD) -> FNBC F4={AC->D} clave (AC) -> FNBC

    Fin del algoritmo: rr={R1(AB),R3(ADE),R4(ACD)}

    Veamos ahora si preserva las dependencias funcionales:

    Tenemos que ver si F1 É F3 É F4 Fc

    Como AC->D Fc y A->B Fc solo hay que ver si F1 É F3 É F4 BD->E

    (BD)+ F1 É F3 É F4 = BD , E no pertenece => no preserva las Dfs

    Como rR no es única y depende del antecedenete tomado, obtendremos otro rR.

    BD->E

    R1(BDE) F1={BD->E} (BD) FNBC

    R'(ABCD) F={A->B,AC->D} (AC) no FNBC

    A->B

    R2(AB) F2={A->B} (A) FNBC

    R3(ACD) F3={AC->D} (AC) no FNBC

    Ahora hay que ver si F1 É F2 É F3 Fc lo cual se ve a simple vista. Mantiene las dependencias funcionales.

    ALGORITMO DE DESCOMPOSICIóN EN 3FN

    Entrada del algoritmo: R, Fc

    Salida del algoritmo: rR sin pérdida, manteniendo Dfs y con relaciones al menos en 3FN.

    Algoritmo:

    Paso1: Obtener todos los atributos de que no aparezcan en Fc (lo llamaremos R1). Construir R1(1) y ponerlo en la salida.

    Paso2: Hacer =-1

    Paso3: Si $ X->Y Fc tal que =XY => construir R2(XY) y ponerlo en la salida

    si no, para cada Df X->Y Fc, construir Ri(XY) y ponerlo en la salida.

    Ejemplo:

    R(ABCDE) Fc={A->B, AC->D, BD->E} (AC)

    No está en 3FN pues A->B no cumple ninguna de las dos condiciones de 3FN

    1 y 2- no hay

    3- R1(AB) F1={A->B} (A) => está en FNBC

    R2(ACD) F2={AC->D} (AC) => está en FNBC

    R3(BDE) F3={BD->E} (BD) => está en FNBC

    Dada una relación R con rR={R1,R2} (descomposición en DOS relaciones), con 1É2=, rR es reversible por JOIN si 12->1-2 F+ ó 12->2-1 F+


    Votar

    Ingresar una calificación para del 1 al 10, siendo 10 el máximo puntaje.

    Para que la votación no tenga fraude, solo se podrá votar una vez este recurso.

    Comentarios de los usuarios


    Agregar un comentario:


    Nombre y apellido:

    E-Mail:

    Asunto:

    Opinión:



    Aún no hay comentarios para este recurso.
     
    Sobre ALIPSO.COM

    Monografias, Exámenes, Universidades, Terciarios, Carreras, Cursos, Donde Estudiar, Que Estudiar y más: Desde 1999 brindamos a los estudiantes y docentes un lugar para publicar contenido educativo y nutrirse del conocimiento.

    Contacto »
    Contacto

    Teléfono: +54 (011) 3535-7242
    Email:

    Formulario de Contacto Online »