UNIVERSIDAD CENTRAL DEL ECUADOR

FACULTAD DE CIENCIAS ECONÓMICASINGENIERÍA EN FINANZAS

CAPÍTULO 9 y CAPÍTULO 10

Lugmaña ChristianLuzuriaga David

Madrid Alex

Capítulo Nueve

Introducción a las técnicasde programación SQL

9.1 Programación de base de datos: problemas y técnicas

La mayoría de los sistemas de bases de datos tienen una interfaz interactiva donde se pueden escribir directamente estos comandos SQL para entrar en el sistema de bases de datos. La interfaz interactiva es muy adecuada para la creación del esquema y las restricciones o para las consultas temporales ocasionales. No obstante, en la práctica, la mayoría de las interacciones con una base de datos se ejecutan a través de programas que se han diseñado y probado cuidadosamente (programas de aplicación o aplicaciones de bases de datos).

Metodologías de programación de bases de datos:1. Incrustación de comandos de bases de datos en un lenguaje de programación de propósito general.2. Uso de una biblioteca de funciones de bases de datos.3. Diseño de un lenguaje completamente nuevo.

Desajuste de impedancia: es el término que se utiliza para referirse a los problemas derivados de las diferenciasentre el modelo de base de datos y el modelo del lenguaje de programación.

Secuencia típica de inteacción en la programación de base de datos: Cuando el programa cliente requiere acceso a una base de datos particular, el programa primero debe establecer o abrir una conexión con el servidor de bases de datos.Una vez establecida la conexión, el programa puede interactuar con la base de datos emitiendo consultas, actualizaciones y otros comandos de bases de datos.Cuando el programa ya no necesita acceso a una base de datos en particular, debe terminar o cerrar la conexión con la base de datos.

Un programa puede acceder a varias bases de datos. En algunas metodologías de programación de bases de datos, sólo una conexión puede estar activa en cada momento, mientras que en las otras metodologías se pueden establecer varias conexiones simultáneas.

sdfasdf

9.2 SQL incrustado, SQL dinámico y SQLJ

Recuperación de tuplas

sencillas con SQL

incrustado

El lenguaje de programación se denomina lenguaje host. La mayoría de las sentencias SQL (incluyendo las definiciones de datos o restricciones, consultas, actualizaciones o definiciones de vistas) pueden incrustarse en un programa de lenguaje host. Una sentencia de SQL incrustado se distingue de las sentencias del lenguaje de programación porque se le añaden como prefijo las palabras clave EXEC SQL para que un preprocesador (o precompilador) pueda separarlas del código escrito en el lenguaje host. Las sentencias SQL se pueden finalizar con un punto y coma (;) o con el ENDEXEC correspondiente.

Observe que los únicos comandos SQL incrustados de la Figura 9.1 son las líneas 1 a 7, que le indican al precompilador que tome nota de los nombres de variable C entre BEGIN DECLARE Y END DECLARE porque se pueden incluir en las sentencias SQL incrustadas, con tal de que vayan precedidas por los dos puntos (:). Las líneas 2 a 5 son declaraciones de programa C normales. Las variables de programa C declaradas en las líneas 2 a 5 corresponden a los atributos de las tablas EMPLEADO y DEPARTAMENTO de la base de datos EMPRESA de la Figura 5.5 que se declaró en el DDL de SQL de la Figura 8.1. Las variables declaradas en la línea 6 (SQLCODE y SQLSTATE) se utilizan para comunicar errores y condiciones de excepción entre el sistema de bases de datos y el programa. La línea 0 muestra la variable de programa loop que no se utilizará en ninguna sentencia SQL incrustada, por lo que se declara fuera de la sección declare de SQL.

sdfasdf

Recuperación de varias tuplas con SQL incrustadoy utilizando cursores

Podemos pensar en un cursor como en un puntero que apunta a una sola tupla (fila) del resultado de una consulta que recupera varias tuplas. El cursor se declara cuando se declara el comando de consulta SQL en el programa. Más tarde en el programa, un comando OPEN CURSOR toma el resultado de la consulta de la base de datos y establece el cursor a una posición anterior a la primera fila de dicho resultado. Ésta se convierte en la fila actual para el cursor.

En la Figura 9.3 puede ver un ejemplo del uso de los cursores; en la línea 4 se declara un cursor denominado EMP. Este cursor está asociado con la consulta SQL declarada en las líneas 5 a 6, pero la consulta no se ejecuta hasta haberse procesado el comando OPEN EMP (línea 8). El comando OPEN <nombre de cursor> ejecuta la consulta y toma su resultado como una tabla en el espacio de trabajo del programa, donde el programapuede efectuar un bucle por las filas (tuplas) individuales mediante subsiguientes comandos FETCH <nombre de cursor> (línea 9). Asumimos que se han declarado las variables de programa C adecuadas, como en la Figura 9.1. El fragmento de programa E2 lee el nombre de un departamento (línea O), recupera su número de departamento (líneas 1 a 3) y, después, recupera los empleados que trabajan en ese departamento a través de un cursor. Un bucle (líneas lOa 18) itera por cada registro de empleado, uno a la vez, e imprime el nombre del empleado. El programa lee después un

sdfasdf

sdfasdf

Especificación de consultas en tiempo deejecución con SQL dinámico

Cuando queremos escribir una consulta diferente, debemos escribir Un programa nuevo, y pasar por todos los pasos peliinentes (compilación, depuración, prueba, etcétera). En algunos casos, es connveniente escribir un programa que pueda ejecutar diferentes consultas o actualizaciones SQL (u otras operaciones) dinámicamente en tiempo de ejecución.

Por ejemplo, queremos escribir un programa que acepte una consulta SQL escrita desde el monitor, la ejecute y muestre su resultado, como si se tratara de las interfaces interactivas disponibles en la mayoría de los DBMSs.

la Figura 9.4 lee Una cadena introducida por el usuario (debe tratarse de Un comando de actualización SQL) en la variable de cadena sqlupdatestring de la línea 3. Después, se prepara esto en la línea 4 como un comando SQL asociándolo COn la variable SQL sqlcommand. La línea 5 ejecuta el comando. En este caso, como estamos en tiempo de compilación, nO es posible comprobar la sintaxisni hacer otras comprobaciones, pues el comando no está disponible hasta el momento de la ejecución. Estocontrasta COn los ejemplos anteriores de SQL incrustado, en los que la consulta se comprueba en tiempo decompilación porque su texto está en el código fuente del programa.

sdfasdf

sdfasdf

9.2.4 SOlJ: comandos Sal incrustados en Java

SQLJ es un estándar por el que han apostado varios desarrolladores para

incrustar SQL en Java.

Además, el programa debe conectar primero con la base de datos deseada utilizando una llamada a la

función getConnection, que es uno de los métodos de la clase oracle de la línea 5 de la Figura 9.5.

Antes de poder procesar SQLJ con Java en Oracle, hay que importar varias bibliotecas de clases (véase la Figura 9.5), entre las que se incluyen las clases JDBC y de E/S (líneas 1 y

2), además de las clases adicionales enumeradas en las líneas 3, 4 y 5.

Java ya utiliza el concepto de excepciones para la manipulación de elTores, se utiliza una

excepción especial denominada SQLException para devolver los elTores o las condiciones de excepción después de ejecutar un comando de

bases de datos SQL.

En SQLJ, los comandos de SQL incrustados dentro de un programa de Java van precedidos por #sql, como se

muestra en la línea 3 de 11, a fin de ser identificados por el preprocesador. SQLJ utiliza una cláusula INTO (parecida a la que se utiliza en SQL incrustado) para

devolver los valores de atributo recuperados de la base de datos por una consulta SQL en las variables del

programa Java.

En 11, la consulta SQLJ incrustada sólo selecciona una tupla; por eso podemos

asignar los valores de sus atributos directamente a las variables del programa

Java en la cláusula INTO de la línea 4. Para las consultas que recuperan muchas

tuplas, SQLJ utiliza el concepto de iterador, que es algo parecido a un cursor

en SQL incrustado.

sdfasdf

sdfasdf

9.2.5 Recuperación de varias tuplas en SQLJ utilizando iteradores

En SQLJ, un iterador es un tipo de objeto asociado con una colección (conjunto o multiconjunto) de tuplas del resultado de una consulta. 12 El iterador está asociado con las tuplas y los atributos que aparecen en el

resultado de una consulta. Hay dos tipos de iteradores:

1. Un iterador con nombre está asociado con el resultado de una consulta enumerando los nombres y los tipos de los atributos que aparecen en dicho resultado. Los nombres de atributo deben corresponderse con las variables del programa Java, como se muestra en la Figura 9.6. 2. Un iterador posicional sólo enumera los tipos de atributos que aparecen en el resultado de la consulta. En los dos casos, la lista debe tener el mismo orden que los atributos de la cláusula SELECT de la consulta.

sdfasdf

9.3 Programación de bases de datos con llamadas a funciones:

SQUCLI y JDBC

El uso de llamadas a funciones es una metodología más dinámica de programación de bases de datos que SQL incrustado.

Se utiliza una biblioteca de funciones, también conocida como interfaz de programación de aplicaciones (API), para acceder a la base de datos.

La principal ventaja del uso de una interfaz de llamadas a funciones es que facilita el acceso a varias bases de datos dentro del mismo programa de aplicación, aunque estén

almacenadas en diferentes paquetes DBMS.

9.3.1 Programación de bases de datos con SQL/CLI utilizando C como lenguaje host

Al utilizar SQLlCLI, las sentencias SQL se crean dinámicamente y se

pasan como parámetros de cadena en las llamadas a las funciones. Por

tanto, es necesario hacer un seguimiento de la información sobre las interacciones del programa hast

con la base de datos en estructuras de datos en tiempo de ejecución, porque los comandos de bases de datos se

procesan en tiempo de ejecución.

La información se guarda en cuatro tipos de registros, representados como

structs en los tipos de datos C. Se utiliza un registro de entorno como contenedor para rastrear una o más

conexiones de bases de datos y para establecer la información de entorno.

Un registro de conexión rastrea la información necesaria para una conexión de base de datos en

particular.

Un registro de sentencia mantiene la información necesaria para una sentencia SQL. Un registro de

descripción mantiene la información sobre las tuplas o parámetros; por

ejemplo, la cantidad de atributos y sus tipos de una tupla, o la cantidad y los tipos de parámetros de una llamada a

una función.

sdfasdf

sdfasdf

9.3.2 JDBC: llamadas a funciones SQl para la programación en Java

Un controlador JDBC es básicamente una implementación de las llamadas a las funciones especificadas en la interfaz

de programación de aplicaciones (API) JDBC para el RDBMS de un desarrollador en particular. Por tanto, un programa Java con llamadas a funciones JDBC puede acceder a cualquier RDBMS que tenga un controlador

JDBC.

Como Java está orientado a objetos, sus bibliotecas de funciones están implementadas como clases. Antes de poder procesar con Java las llamadas a funciones JDBC,

es necesario importar las bibliotecas de clases JDBC, que se denominan java. sql . *. Se pueden descargar e instalar

a través de la Web.

Para lograr esta flexibilidad se emplea una clase JDBC especial denominada administrador de controladores, que

hace un seguimiento de los controladores instalados. Antes de utilizarlo, el controlador debe registrarse con el

administrador de controladores. Las operaciones (métodos) de la clase del administrador de controladores son getDri ver, registerDri ver y deregisterDri ver, que se pueden utilizar para añadir o eliminar dinámicamente los

controladores.

En general, el programador puede comprobar las excepciones SQL después de cada llamada a una

función JDBC. JDBC no distingue entre consultas que devuelven una sola tupla y consultas que devuelven varias tuplas, a

diferencia de otras técnicas. Esto es justificable porque un resultado de una sola tupla es un caso especial.

sdfasdf

sdfasdf

sdfasdf

9.4 Procedimientos almacenados de bases de datos y SQUPSM

En este capitulo veremos las extensiones se conocen como SQL/PSM (SQLlMódulos almacenados persistentes, SQL( Persistent Stored Modules) y se pueden utilizar para escribir procedimientos almacenados. SQLlPSM también sirve como ejemplo de lenguaje de programación de bases de datos que amplía un modelo y lenguaje de bases de datos

(SQL) con algunas estructuras de programación, como sentencias condicionales y bucles.

9.4.1 Procedimientos almacenados de bases de datos y funciones

El término utilizado en el estándar SQL para los procedimientos almacenados es módulos almacenados persistentes, porque el DBMS almacena persistentemente estos programas, algo parecido a los datos

persistentes almacenados por el DBMS.

Si varias aplicaciones necesitan un mismo

programa de bases de base de datos, este último se puede almacenar en el

servidor e invocarlo desde esas aplicaciones. Esto reduce la duplicidad del

esfuerzo y mejora la modularidad del software.

La ejecución de un programa en el servidor puede reducir el coste

derivado de la transferencia y la comunicación de

datos entre el cliente y el servidor en ciertas

situaciones.

Estos procedimientos pueden mejorar la potencia

de modelado de las vistas al permitir que los usuarios de bases de datos cuenten con

tipos más complejos de datos derivados.

Muchos DBMSs comerciales permiten escribir procedimientos y funciones almacenados en un lenguaje de programación de propósito general.

Los parámetros y las declaraciones locales son opcionales, y sólo se especifican si se necesitan.En general, cada parámetro debe tener un tipo de parámetro; uno de los tipos de datos de SQL. También

debe tener un modo de parámetro, que es IN, OUT, o INOUT. Estos modos se corresponden con los parámetros cuyos valores son de sólo entrada, sólo salida, o de entrada y salida.

sdfasdf

9.4.2 SQL/PSM: ampliación de Sal para especificar módulos almacenados persistentes

SQL/PSM es la parte del estándar SQL encargada de especificar cómo han de escribirse los módulos almacenados persistentes. Incluye las sentencias para crear las funciones y los procedimientos que describimos en la sección anterior.

La sentencia de bifurcación condicional en SQLlPSM tiene la siguiente forma:

sdfasdf

sdfasdf

9.5 Resumen

En la Sección 9.1 ofrecimos una panorámica de las técnicas más importantes de programación de bases de datos. Después, en las Secciones 9.2 a 9.4 explicamos las distintas metodologías de programación de aplicaciones de base de datos.

En la Sección 9.2 explicamos la técnica general conocida como SQL incrustado, donde las consultas forman parte del código fuente del programa.

Ofrecimos una introducción de SQL incrustado haciendo uso del lenguaje de programación C como lenguaje host. También explicamos la técnica SQLJ para incrustar SQL en programas Java.

En la Sección 9.3 explicamos el uso de las bibliotecas de llamadas a funciones para acceder a las bases de datos SQL. Esta técnica es más dinámica que e SQL incrustado, pero requiere una programación más compleja porque los tipos y la cantidad de atributos del resultado de una consulta pueden determinarse en tiempo de ejecución. También hemos ofrecido

una visión general del estándar SQL/CLI, con ejemplos utilizando C como lenguaje host.

En la Sección 9.4, ofrecimos una introducción a los procedimientos almacenados, y explicamos SQLIPSM como un ejemplo de lenguaje de programación de bases de datos.

sdfasdf

sdfasdf

Capítulo Diez

Dependencias funcionales ynormalización en bases dedatos relacionales

sdfasdf

Dependencias funcionales ynormalización en bases dedatos relacionales

Impartir una semántica clara a los atributos de las relaciones: Siempre que agrupamos atributos para formar un esquema de relación asumimos que pertenecen a una relación que tiene cierta similitud con el mundo real y una interpretación propia asociada a ellos. La semántica de una relación hace referencia a la interpretación de los valores de un atributo en una tupla.

Considere la Figura 10.1, el significado del esquema de relación EMPLEADO es muy simple: cada tupla representa a un empleado, con valores que contienen su nombre (NombreE), su Documento Nacional de Identidad (Dni), su fecha de nacimiento (FechaNac), su dirección (Dirección) y el número del departamento en el que trabaja (NúmeroDpto). El atributo NúmeroDpto es una foreign key que representa una relación implícita entre EMPLEADO y DEPARTAMENTO. Las semánticas de los esquemas DEPARTAMENTO y PROYECTO son también muy directas: cada tupla DEPARTAMENTO representa a una entidad departamento, y cada tupla PROYECTO es una entidad proyecto. El atributo DniDirector de DEPARTAMENTO relaciona un departamento con el empleado que es director el mismo, mientras que NumDptoProyecto de PROYECTO asocia un proyecto con el departamento que lo gestiona; ambos atributos sonforeign keys. La facilidad con la que se pueda explicar el significado de los atributos de una relación es una medida informal de lo bien que está diseñada esa relación.

sdfasdf

sdfasdf

Información redundante en tuplas yanomalías en la actualización

Uno de los objetivos de un esquema de diseño es reducir el espacio de almacenamiento utilizado por las relaciones base (y, por tanto, por los ficheros correspondientes). El agrupamiento de atributos en esquemas de relación tiene un efecto significativo sobre el espacio de almacenamiento. Por ejemplo, compare el espacio empleado por las dos relaciones base EMPLEADO y DEPARTAMENTO de la Figura 10.2 con el necesario para EMP _DEPT de la Figura 10.4, que es el resultado de aplicar la operación NATURAL JOIN a EMPLEADO y DEPARTAMENTO. En EMP _DEPT, los valores de atributo pelienecientes a un departamento particular (NúmeroDpto, NombreDpto, DniDirector) están repetidos para cada empleado que trabaja en ese departamento.

Valores NULL en las tuplas: En algunos diseños podemos agrupar muchos atributos en una relación "muy grande". Si muchos de los atributosno se aplican a todas las tuplas de la relación, nos encontraremos con muchos valores NULL en esas tuplas. Esto puede desperdiciar espacio de almacenamiento y puede inducir a problemas a la hora de entenderel significado de los atributos con la especificación de operaciones JOIN a nivel lógico. Otro problema con los NULL es cómo contabilizarlos cuando se aplican operaciones de agregación como COUNT o SUMo Las operaciones SELECT o JOIN implican comparaciones. Si hay presentes valores NULL, los resultados seránimpredecibles.6 Además, los NULL pueden tener múltiples interpretaciones:• El atributo no se aplica a esta tupla.• El valor de atributo de esta tupla es desconocido.• El valor es conocido pero está ausente, es decir, aún no se ha grabado.

sdfasdf

10.2.1 Definición de dependencia funcional

Una dependencia funcional, denotada por X ---> Y, entre dos conjuntos de atributos X e y que son subconjuntos de R, especifica una restricción en las posibles tuplas que pueden formar un estado de relación l' de R. La restricción dice que dos tuplas t¡ y t2 en l' que cumplen que t¡[X] = t2

[X], deben cumplir también que t¡[y! = t2[1'].

Una dependencia funcional es una propiedad de la semántica o significado de los atributos. Los diseñadores de la base de datos utilizarán su comprensión de la semántica de los atributos de R (esto es, cómo se relacionan unos con otros) para especificar las dependencias funcionales

que deben mantenerse en todos los estados de relación (extensiones) l' de R.

Las extensiones de relación r(R) que satisfacen la restricción de dependencia funcional reciben el nombre de estados de relación legales (o extensiones legales) de R.

Una dependencia funcional es una propiedad del esquema de relación R, y no un estado de relación legal particular l' de R. Por consiguiente, una DF no puede ser inferida automáticamente a partir de una extensión de relación 1', sino que alguien que conozca la semántica de los atributos de

R debe definirla explícitamente. Por ejemplo, la Figura 10.7 muestra un estado particular del esquema de relación IMPARTIR.

sdfasdf

10.2.2 Reglas de inferencia para las dependencias funcionales

Formalmente, el conjunto de todas las dependencias que incluyen F, junto con las dependencias que pueden

inferirse de F, reciben el nombre de clausuras de F; está designada mediante r.

La regla reflexiva (RI1) especifica que un conjunto de atributos siempre se determina a sí mismo o cualquiera de sus subconjuntos, lo que es obvio. Ya

que la RI1 genera dependencias que siempre son verdaderas, éstas reciben el nombre de triviales. Formalmente, una dependencia funcional X ---7 Yes trivial

si X:2 Y; en cualquier otro caso es no trivial.

Reglas de inferencia de Armstrong.-Para cada conjunto de atributos X como éste, determinamos el conjunto x+- de atributos que están funcionalmente

determinados por X basados en F; x+- recibe el nombre de clausura de X bajo F. Puede usarse el Algoritmo

10.1 para calcular X+-.

Comprobación de RI4 (usando R11, RI2 Y RI3). 1. X --+ YZ (dada). 2. YZ --+ Y (usando RI1 y sabiendo que YZ:2 Y). 3. X --+ Y (usando RI3 en 1 y 2). Comprobación de RI5 (usando R11, RI2 Y RI3). 1. X--+Y(dada). 2. X --+ Z (dada). 3. X --+ XY (usando RI2 en 1 aumentando con X; observe que XX = X). 4. XY --+ YZ (usando RI2 en 2 aumentando con Y). 5. X --+ YZ (usando RI3 en 3 y 4). Comprobación de RI6 (usando las R11, RI2 Y RI3). 1. X--+Y(dada). 2. WY --+ Z (dada). 3. WX --+ WY (usando RI2 en 1 aumentando con W). 4. WX --+ Z (usando RI3 en 3 y 2).

sdfasdf

10.2.3 Equivalencia de los conjuntos de dependencias funcionales

Un conjunto de dependencias funcionales F se dice que cubre a otro conjunto de dependencias funcionales E si toda DF de E está también en r, es decir, si toda

dependencia de E puede ser inferida a partir de F; alternativamente, podemos decir que E está cubierto por F.

Dos conjuntos de dependencias funcionales E y F son equivalentes si Ir = r. Por consiguiente, equivalencia significa que cada DF de E puede inferirse a patiir de F, y

viceversa; es decir, E es equivalente a F si se cumplen las condiciones E cubre a F y F cubre a E.

10.2.4 Conjuntos mínimos de dependencias funcionales

Podemos definir formalmente que un conjunto de dependencias funcionales F es mínimo si satisface las siguientes condiciones: 1. Toda dependencia en F tiene un único atributo en su lado derecho. 2. No podemos reemplazar ninguna dependencia X ----+ A de F por otra dependencia Y ----+ A, donde Yes un subconjunto propio de X, y seguir teniendo un conjunto de dependencias equivalente a F. 3. No podemos eliminar ninguna dependencia de F y seguir teniendo un conjunto de dependencias equivalente a F.

Una cobertura mínima de un conjunto de dependencias funcionales E es un conjunto mínimo de dependencias

(en forma canónica estándar y sin redundancia) equivalente a E. Con el Algoritmo 10.2, siempre

podemos buscar, almenas, una cobertura mínima F por cada conjunto de dependencias E.

sdfasdf

10.3 Formas normales basadas en claves principales

Los proyectos de diseño relacional más prácticos siguen una de estas aproximaciones: 1. Realizar un diseño de esquema conceptual usando un modelo conceptual como el ER o el EER y asignar el diseño conceptual a un conjunto de relaciones. 2.Diseñar las relaciones en base a un conocimiento externo derivado de una implementación existente de ficheros o formularios o informes.

10.3.1 Normalización de relaciones

La normalización de datos puede considerarse como un proceso de

análisis de un esquema de relación, basado en sus DF y sus

claves principales, para obtener las propiedades deseables de (1) minimizar la redundancia y (2)

minimizar las anomalías de inserción, borrado y actualización

Definición. La forma normal de una relación

hace referencia a la forma normal más alta que

cumple, e indica por tanto el grado al que ha sido

normalizada.

El proceso de normalización por descomposición debe confirmar también la existencia de las propiedades

adicionales que los esquemas relacionales, en conjunto, deben poseer. Dos de estas propiedades son las siguientes: 11 La propiedad de reunión sin pérdida o reunión no aditiva,

que garantiza que no se presentará el problema de las tuplas falsas comentado en la Sección 10.1.4, respecto a los

esquema de relación creados después de la descomposición. 11 La propiedad de conservación de las dependencias, que

asegura que todas las dependencias funcionales están representadas en alguna relación individual resultante tras la

descomposición.

sdfasdf

10.3.2 Uso práctico de las formas normales

Definición. El proceso para almacenar la concatenación de relaciones de forma normal superiores como relación base (que se

encuentra en una forma normal inferior) recibe el nombre de desnormalización.

10.3.3 Definiciones de claves y atributos que participan en las claves

Una superclave de un esquema de relación R = {Al' A2, ... ,AII} es un conjunto de atributos S ~ R con la propiedad de que no habrá un par de tuplas tI y t2 en ningún estado de relación permitido l' de R tal que tl[S] = t2[S]. Una clave K es una superclave con la propiedad adicional de que la eliminación de cualquier atributo de K provocará

que K deje de ser una superclave.

Un atributo del esquema de relación R recibe el nombre de atributo primo de R si es miembro de alguna de las claves candidatas de R. Un atributo es no primo si no es miembro de ninguna clave candidata.

sdfasdf

10.3.4 Primera forma normal

lFN prohíbe tener un conjunto de valores, una tupla de valores o una combinación de ambos como valor de un atributo para una tupla individual.

lFN prohíbe las relaciones dentro de las relaciones o las relaciones como valores de atributo dentro de las tuplas. Los únicos valores de atributo permitidos por lFN son los atómicos (o

indivisibles).

La primera forma normal (lFN) está considerada como una parte de la definición formal de una relación en el modelo relacional básico;históricamente, fue definida para prohibir los atributos

multivalor, los atributos compuestos y sus combinaciones.

sdfasdf

Segunda forma normal

La segunda forma normal (2FN) está basada en el concepto de dependenciafimcional total. Una dependencia funcional X ---+ Yes total si la eliminación de cualquier atributo A de X implica que la dependencia deje de ser válida, es decir, para cualquier atributo A E X, (X - {A}) no determina funcionalmente a Y. Una dependenciafuncional X ---+ Yes parcial si al eliminarse algún atributo A E X de X la dependencia sigue siendo válida, es decir, para algún A E X, (X - {A}) ---+ Y. En la Figura 1O.3(b), {Dní, NumProyecto} ---+ Horas es una dependencia completa (ni Dni ---+ Horas ni NumProyecto ---+ Horas son válidas). Sin embargo, la dependencia {Dni, NumProyecto} ---+ NombreE es parcial porque se cumple Dni ---+ NombreE.Definición. Un esquema de relación R está en 2FN si todo atributo no primo A en R es completa y fumcionalmente dependiente de la clave principal de R.

Tercera forma normal

La tercera forma normal (3FN) se basa en el concepto de dependencia transitiva. Una dependencia funcionalX ---+ Yen un esquema de relación R es una dependencia transitiva si existe un conjunto de atributos Z que ni es clave candidata ni un subconjunto de ninguna clave de R,15 Y se cumple tanto X ---+ Z como Z ---+ Y. La dependencia Dni ---+ DniDirector es transitiva a través de NúmeroDpto en EMP _DEPT en la Figura 10.3(a)porque se cumplen las dependencias Dni ---+ NúmeroDpto y NúmeroDpto ---+ DniDirector y NúmeroDpto no esuna clave por sí misma ni un subconjunto de la clave de EMP DEPT. Intuitivamente, podemos ver que la dependencia de DniDirector en NúmeroDpto no es deseable en EMP _DEPT ya que NúmeroDpto no es una clave de EMP DEPT.Definición. Según la definición original de Codd, un esquema de relación R está en 3FN si satisface 2FN y ningún atributo no primo de R es transitivamente dependiente en la clave principal.

sdfasdf

sdfasdf

Definiciones generales de la segunday tercera formas normales

Definición general de la segunda forma normalDefinición. Un esquema de relación R está en segunda forma normal (2FN) si cada atributo no primo A en R no es parcialmente dependiente de ninguna clave de R.16 La prueba para 2FN implica la verificación de las dependencias funcionales cuyos atributos de la izquierda forman parte de la clave principal. Si la clave principal contiene un único atributo, no es preciso aplicar lacomprobación a todo. Considere el esquema de relación PARCELAS de la Figura 10.11(a), que describe los terrenos en venta en distintas provincias. Suponga que existen dos claves candidatas: IdPropiedad y{NombreMunicipio, NúmeroParcela}, es decir, los números de parcela son únicos en cada provincia, mientras que los Id Propiedad son únicos para toda una provincia. En base a las dos claves candidatas IdPropiedad y {NombreMunicipio, NúmeroParcela}, sabemos que se cumplen las dependencias funcionales FD1 y FD2 de la Figura 10. l1(a). Elegimos Id Propiedad como clave principal, razón por la que aparece subrayada en la Figura 1 0.11(a), aunque no es preciso tomar ninguna consideraciónespecial con esta clave en relación con la otra clave candidata. Supongamos que también se cumplen las dos siguientes dependencias funcionales en PARCELAS:FD3: NombreProvincia -> ImpuestosFD4: Área -> Precio

sdfasdf

sdfasdf

Definición general de la tercera forma normal

Definición. Un esquema de relación R está en tercera forma normal (3FN) si, siempre que una dependencia funcional no trivial X -) A se cumple en R, ya sea (a) X una superclave de R, o (b) A un atributo primo de R. Según esta definición, PARCELAS2 (Figura 1O.11(b)) está en 3FN. Sin embargo, FD4 de PARCELAS1 viola 3FN porque Área no es una superclave y Precio no es un atributo primo en PARCELAS1. Para normalizar PARCELAS1 a 3FN, la descomponemos en los esquemas de relación PARCELAS1A y PARCELAS1B de la Figura IO.ll(c). Construimos PARCELAS1A eliminando el atributo Precio de PARCELAS1, que viola 3FN, y colocándolo junto con Área (el lado izquierdo de FD4 que provoca la dependencia transitiva) en otra relación PARCELAS1B. Tanto PARCELAS1A como PARCELAS1B están en 3FN.

Dos son los puntos a destacar en este ejemplo y en la definición general de la 3FN:• PARCELAS1 viola 3FN porque Precio depende transitivamente de cada una de las claves candidatas de PARCELAS 1 a través del atributo no primo Área.• Esta definición general puede aplicarse directamente para comprobar si un esquema de relación está en 3FN; esto no implica pasar primero por 2FN. Si aplicamos la definición anterior de 3FN a PARCELAS con las dependencias FD1 a FD4, encontramos que tanto FD3 como FD4 violan 3FN. Por consiguiente, podríamos descomponer PARCELAS en PARCELAS1A, PARCELAS1 By PARCELAS2 directamente. Por consiguiente, las dependencias transitiva y parcial que violan 3FN pueden eliminarse en cualquier orden.