BD

Resultado del proceso de diseo fsico de una base de datos.
El esquema fsico de una base de datos, depende del tipo de SGBD y de un SGBD especfico. El esquema fsico de una base de datos es una descripcin de la implementacin de una base de datos en memoria secundaria, describiendo las estructuras de almacenamiento y los mtodos de acceso a esos datos.
El modelo relacional En 1970, el modo en que se vean las bases de datos cambi por completo cuando E. F. Codd introdujo el modelo relacional. En aquellos momentos, el enfoque existente para la estructura de las bases de datos utilizaba punteros fsicos (direcciones de disco) para relacionar registros de distintos ficheros. Si, por ejemplo, se quera relacionar un registro con un registro , se deba aadir al registro un campo conteniendo la direccin en disco del registro . Este campo aadido, un puntero fsico, siempre sealara desde el registro al registro . Codd demostr que estas bases de datos limitaban en gran medida los tipos de operaciones que los usuarios podan realizar sobre los datos. Adems, estas bases de datos eran muy vulnerables a cambios en el entorno fsico. Si se aadan los controladores de un nuevo disco al sistema y los datos se movan de una localizacin fsica a otra, se requera una conversin de los ficheros de datos. Estos sistemas se basaban en el modelo de red y el modelo jerrquico, los dos modelos lgicos que constituyeron la primera generacin de los SGBD. El modelo relacional representa la segunda generacin de los SGBD. En l, todos los datos estn estructurados a nivel lgico como tablas formadas por filas y columnas, aunque a nivel fsico pueden tener una estructura completamente distinta. Un punto fuerte del modelo relacional es la sencillez de su estructura lgica. Pero detrs de esa simple estructura hay un fundamento terico importante del que carecen los SGBD de la primera generacin, lo que constituye otro punto a su favor. Dada la popularidad del modelo relacional, muchos sistemas de la primera generacin se han modificado para proporcionar una interfaz de usuario relacional, con independencia del modelo lgico que soportan (de red o jerrquico). Por ejemplo, el sistema de red IDMS ha evolucionado a IDMS/R e IDMS/SQL, ofreciendo una visin relacional de los datos. En los ltimos aos, se han propuesto algunas extensiones al modelo relacional para capturar mejor el significado de los datos, para disponer de los conceptos de la orientacin a objetos y para disponer de capacidad deductiva. El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de los datos: Estructura de datos. Integridad de datos. Manejo de datos.
Estructura de datos relacional En este apartado se presenta la estructura de datos del modelo relacional: la relacin Relaciones
Definiciones informales El modelo relacional se basa en el concepto matemtico de relacin, que grficamente se representa mediante una tabla. Codd, que era un experto matemtico, utiliz una terminologa perteneciente a las matemticas, en concreto de la teora de conjuntos y de la lgica de predicados. Una relacin es una tabla con columnas y filas. Un SGBD slo necesita que el usuario pueda percibir la base de datos como un conjunto de tablas. Esta percepcin slo se aplica a la estructura lgica de la base de datos (en el nivel externo y conceptual de la arquitectura de tres niveles ANSI-SPARC). No se aplica a la estructura fsica de la base de datos, que se puede implementar con distintas estructuras de almacenamiento. Un atributo es el nombre de una columna de una relacin. En el modelo relacional, las relaciones se utilizan para almacenar informacin sobre los objetos que se representan en la base de datos. Una relacin se representa grficamente como una tabla bidimensional en la que las filas corresponden a registros individuales y las columnas corresponden a los campos o atributos de esos registros. Los atributos pueden aparecer en la relacin en cualquier orden. Por ejemplo, la informacin de las oficinas de la empresa inmobiliaria se representa mediante la relacin OFICINA, que tiene columnas para los atributos Onum (nmero de oficina), Calle, Area, Poblacin, Telfono y Fax. La informacin sobre la plantilla se representa mediante la relacin PLANTILLA, que tiene columnas para los atributos Enum (nmero de empleado), Nombre, Apellido, Direccin, Telfono, Puesto, Fecha_nac, Salario, DNI, Onum (nmero de la oficina a la que pertenece el empleado). A continuacin se muestra una instancia de la relacin OFICINA y una instancia de la relacin PLANTILLA. Como se puede observar, cada columna contiene valores de un solo atributo. Por ejemplo, la columna Onum slo contiene nmeros de oficinas que existen. OFICINA
Onum Calle Area Poblacin Telfono Fax O5 Enmedio, 8 Centro Castelln 964 201 240 964 201 340 O7 Moyano, s/n Centro Castelln 964 215 760 964 215 670 O3 San Miguel, 1 Villarreal 964 520 250 964 520 255 O4 Trafalgar, 23 Grao Castelln 964 284 440 964 284 420 O2 Cedre, 26 Villarreal 964 525 810 964 252 811 PLANTILLA Enu Nombr Apellid Telfon Direccin Puesto m e o o 964 EL2 Magallane Amelia Pastor 284 Director 1 s, 15 560 Castelln 964 EG3 Cubed Bayarri, Supervis Pedro 535 7 o 11 or 690 Villarreal 964 EG1 Collad Luis Borriol, 35 522 Administ. 4 o 230 Villarreal 964 Casalduc Supervis EA9 Rita Renau 257 h, 32 or 550 Castelln 964 EG5 Julio Prats Melilla, 23 524 Director 590 Villarreal 964 EL4 Herrero, Supervis Carlos Baeza 247 1 51 or 250 Castelln Fecha_n Salari DNI ac o 12/10/62 Onu m
3000 39432212 O5 0 E
24/3/57
1800 38766623 O3 0 X
9/5/70
1200 24391223 O3 0 L
19/5/60
1800 39233190 O7 0 F
19/12/50
2400 25644309 O3 0 X
29/2/67
1800 39552133 O5 0 T
Un dominio es el conjunto de valores legales de uno o varios atributos. Los dominios constituyen una poderosa caracterstica del modelo relacional. Cada atributo de una base de datos relacional se define sobre un dominio, pudiendo haber varios atributos definidos sobre el mismo dominio. La siguiente tabla muestra los dominios de los atributos de la relacin OFICINA. Ntese que en esta
relacin hay dos atributos que estn definidos sobre el mismo dominio, Telfono y Fax. Atributo Onum Nombre del Dominio NUM_OFICINA Descripcin Posibles valores de nmero de oficina Definicin 3 caracteres; rango O1O99 25 caracteres 20 caracteres 15 caracteres 9 caracteres 9 caracteres
Calle Area
NOM_CALLE NOM_AREA
Nombres de calles de Espaa
Nombres de reas de las poblaciones de Espaa Nombres de las poblaciones de Poblacin NOM_POBLACION Espaa Telfono NUM_TEL_FAX Nmeros de telfono de Espaa Fax NUM_TEL_FAX Nmeros de telfono de Espaa
El concepto de dominio es importante porque permite que el usuario defina, en un lugar comn, el significado y la fuente de los valores que los atributos pueden tomar. Esto hace que haya ms informacin disponible para el sistema cuando ste va a ejecutar una operacin relacional, de modo que las operaciones que son semnticamente incorrectas, se pueden evitar. Por ejemplo, no tiene sentido comparar el nombre de una calle con un nmero de telfono, aunque los dos atributos sean cadenas de caracteres. Sin embargo, el importe mensual del alquiler de un inmueble no estar definido sobre el mismo dominio que el nmero de meses que dura el alquiler, pero s tiene sentido multiplicar los valores de ambos dominios para averiguar el importe total al que asciende el alquiler. Los SGBD relacionales no ofrecen un soporte completo de los dominios ya que su implementacin es extremadamente compleja. Una tupla es una fila de una relacin. Los elementos de una relacin son las tuplas o filas de la tabla. En la relacin OFICINA, cada tupla tiene seis valores, uno para cada atributo. Las tuplas de una relacin no siguen ningn orden. El grado de una relacin es el nmero de atributos que contiene. La relacin OFICINA es de grado seis porque tiene seis atributos. Esto quiere decir que cada fila de la tabla es una tupla con seis valores. El grado de una relacin no cambia con frecuencia. La cardinalidad de una relacin es el nmero de tuplas que contiene. Ya que en las relaciones se van insertando y borrando tuplas a menudo, la cardinalidad de las mismas vara constantemente.
Una base de datos relacional es un conjunto de relaciones normalizadas. Definiciones formales Una relacindefinida sobre un conjunto de dominios consta de: Cabecera: conjunto fijo de pares atributo:dominio
donde cada atributo corresponde a un nico dominio y todos los son distintos, es decir, no hay dos atributos que se llamen igual. El grado de la relacin es . Cuerpo: conjunto variable de tuplas. Cada tupla es un conjunto de paresatributo:valor:
con , donde es la cardinalidad de la relacin . En cada par se tiene que . La relacin OFICINA tiene la siguiente cabecera: {(Onum:NUM_OFICINA), (Calle:NOM_CALLE), (Area:NOM_AREA), (Poblacin:NOM_POBLACION), (Telfono:NUM_TEL_FAX), (Fax:NUM_TEL_FAX)}. Siendo la siguiente una de sus tuplas: {(Onum:O5), (Calle:Enmedio,8), (Area:Centro), (Poblacin:Castelln), (Telfono:964 201 240), (Fax:964 201 340)}. Este conjunto de pares no est ordenado, por lo que esta tupla y la siguiente, son la misma: {(Calle:Enmedio,8), (Fax:964 201 340), (Poblacin:Castelln), (Onum:O5), (Telfono:964 201 240), (Area:Centro)} Grficamente se suelen representar las relaciones mediante tablas. Los nombres de las columnas corresponden a los nombres de los atributos y las filas son cada una de las tuplas de la relacin. Los valores que aparecen en cada una de las columnas pertenecen al conjunto de valores del dominio sobre el que est definido el atributo correspondiente.
Propiedades de las relaciones Las relaciones tienen las siguientes caractersticas: Cada relacin tiene un nombre y ste es distinto del nombre de todas las dems. Los valores de los atributos son atmicos: en cada tupla, cada atributo toma un solo valor. Se dice que las relaciones estn normalizadas. No hay dos atributos que se llamen igual. El orden de los atributos no importa: los atributos no estn ordenados. Cada tupla es distinta de las dems: no hay tuplas duplicadas. El orden de las tuplas no importa: las tuplas no estn ordenadas.
Tipos de relaciones En un SGBD relacional pueden existir varios tipos de relaciones, aunque no todos manejan todos los tipos. Relaciones base. Son relaciones reales que tienen nombre y forman parte directa de la base de datos almacenada (son autnomas). Vistas. Tambin denominadas relaciones virtuales, son relaciones con nombre y derivadas: se representan mediante su definicin en trminos de otras relaciones con nombre, no poseen datos almacenados propios. Instantneas. Son relaciones con nombre y derivadas. Pero a diferencia de las vistas, son reales, no virtuales: estn representadas no slo por su definicin en trminos de otras relaciones con nombre, sino tambin por sus propios datos almacenados. Son relaciones de slo de lectura y se refrescan peridicamente. Resultados de consultas. Son las relaciones resultantes de alguna consulta especificada. Pueden o no tener nombre y no persisten en la base de datos. Resultados intermedios. Son las relaciones que contienen los resultados de las subconsultas. Normalmente no tienen nombre y tampoco persisten en la base de datos.
Resultados temporales. Son relaciones con nombre, similares a las relaciones base o a las instantneas, pero la diferencia es que se destruyen automticamente en algn momento apropiado. Claves Ya que en una relacin no hay tuplas repetidas, stas se pueden distinguir unas de otras, es decir, se pueden identificar de modo nico. La forma de identificarlas es mediante los valores de sus atributos. Una superclave es un atributo o un conjunto de atributos que identifican de modo nico las tuplas de una relacin. Una clave candidata es una superclave en la que ninguno de sus subconjuntos es una superclave de la relacin. El atributo o conjunto de atributos de la relacin es una clave candidata para si y slo si satisface las siguientes propiedades: Unicidad: nunca hay dos tuplas en la relacin con el mismo valor de .
Irreducibilidad (minimalidad): ningn subconjunto de tiene la propiedad de unicidad, es decir, no se pueden eliminar componentes de sin destruir la unicidad. Cuando una clave candidata est formada por ms de un atributo, se dice que es unaclave compuesta. Una relacin puede tener varias claves candidatas. Por ejemplo, en la relacin OFICINA, el atributo Poblacin no es una clave candidata ya que puede haber varias oficinas en una misma poblacin. Sin embargo, ya que la empresa asigna un cdigo nico a cada oficina, el atributo Onum s es una clave candidata de la relacin OFICINA. Tambin son claves candidatas de esta relacin los atributos Telfono y Fax. En la base de datos de la inmobiliaria hay una relacin denominada VISITA que contiene informacin sobre las visitas que los clientes han realizado a los inmuebles. Esta relacin contiene el nmero del cliente Qnum, el nmero del inmueble Inum, la fecha de la visita Fecha y un comentario opcional. Para un determinado nmero de cliente Qnum, se pueden encontrar varias visitas a varios inmuebles. Del mismo modo, dado un nmero de inmueble Inum, puede que haya varios clientes que lo hayan visitado. Por lo tanto, el atributo Qnum no es una clave candidata para la relacin VISITA, como tampoco lo es el atributo Inum. Sin embargo, la combinacin de los dos atributos s identifica a una sola tupla, por lo que los dos juntos son una clave candidata de VISITA. Si se desea considerar la posibilidad de que un mismo cliente pueda visitar un mismo inmueble en varias
ocasiones, habra que incluir el atributo Fecha para identificar las tuplas de modo nico (aunque ste no es el caso de la empresa que nos ocupa). Para identificar las claves candidatas de una relacin no hay que fijarse en un estado o instancia de la base de datos. El hecho de que en un momento dado no haya duplicados para un atributo o conjunto de atributos, no garantiza que los duplicados no sean posibles. Sin embargo, la presencia de duplicados en un estado de la base de datos s es til para demostrar que cierta combinacin de atributos no es una clave candidata. El nico modo de identificar las claves candidatas es conociendo el significado real de los atributos, ya que esto permite saber si es posible que aparezcan duplicados. Slo usando esta informacin semntica se puede saber con certeza si un conjunto de atributos forman una clave candidata. Por ejemplo, viendo la instancia anterior de la relacin PLANTILLA se podra pensar que el atributo Apellido es una clave candidata. Pero ya que este atributo es el apellido de un empleado y es posible que haya dos empleados con el mismo apellido, el atributo no es una clave candidata. La clave primaria de un relacin es aquella clave candidata que se escoge para identificar sus tuplas de modo nico. Ya que una relacin no tiene tuplas duplicadas, siempre hay una clave candidata y, por lo tanto, la relacin siempre tiene clave primaria. En el peor caso, la clave primaria estar formada por todos los atributos de la relacin, pero normalmente habr un pequeo subconjunto de los atributos que haga esta funcin. Las claves candidatas que no son escogidas como clave primaria son denominadasclaves alternativas. Por ejemplo, la clave primaria de la relacin OFICINA es el atributo Onum, siendo Telfono y Fax dos claves alternativas. En la relacin VISITA slo hay una clave candidata formada por los atributos Qnum e Inum, por lo que esta clave candidata es la clave primaria. Una clave ajena es un atributo o un conjunto de atributos de una relacin cuyos valores coinciden con los valores de la clave primaria de alguna otra relacin (puede ser la misma). Las claves ajenas representan relaciones entre datos. El atributo Onum de PLANTILLA relaciona a cada empleado con la oficina a la que pertenece. Este atributo es una clave ajena cuyos valores hacen referencia al atributo Onum, clave primaria de OFICINA. Se dice que un valor de clave ajena representa una referencia a la tupla que contiene el mismo valor en su clave primaria ( tupla referenciada). Esquema de una base de datos relacional Una base de datos relacional es un conjunto de relaciones normalizadas. Para representar el esquema de una base de datos relacional se debe dar el
nombre de sus relaciones, los atributos de stas, los dominios sobre los que se definen estos atributos, las claves primarias y las claves ajenas.
Modelo relacional
El modelo relacional para la gestin de una base de datos es un modelo de datos basado en la lgica de predicados y en la teora de conjuntos. Es el modelo ms utilizado en la actualidad para modelar problemas reales y administrar datos dinmicamente. Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San Jos (California), no tard en consolidarse como un nuevo paradigma en los modelos de base de datos. Su idea fundamental es el uso de relaciones. Estas relaciones podran considerarse en forma lgica como conjuntos de datos llamados tuplas. Pese a que sta es la teora de las bases de datos relacionales creadas por Edgar Frank Codd, la mayora de las veces se conceptualiza de una manera ms fcil de imaginar, esto es, pensando en cada relacin como si fuese una tablaque est compuesta por registros (cada fila de la tabla sera un registro o tupla), y columnas (tambin llamadas campos).
ndice
[ocultar]
1 Descripcin
o o
1.1 Esquema 1.2 Instancias
2 Base de datos relacional 3 Vase tambin
Descripcin[editar editar cdigo]

En este modelo todos los datos son almacenados en relaciones, y como cada relacin es un conjunto de datos, el orden en el que stos se almacenen no tiene relevancia (a diferencia de otros modelos como el jerrquico y el de red). Esto tiene la considerable ventaja de que es ms fcil de entender y de utilizar por un usuario no experto. La informacin puede ser recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder para administrar la informacin. Este modelo considera la base de datos como una coleccin de relaciones. De manera simple, una relacin representa una tabla que no es ms que un conjunto de filas, cada fila es un conjunto de campos y cada campo representa un valor que interpretado describe el mundo real. Cada fila tambin se puede denominar tupla o registro y a cada columna tambin se le puede llamar campo o atributo. Para manipular la informacin utilizamos un lenguaje relacional, actualmente se cuenta con dos lenguajes formales el lgebra relacional y el Clculo relacional. El lgebra relacional permite describir la forma de realizar una consulta, en cambio, el Clculo relacional slo indica lo que se desea devolver.
Esquema[editar editar cdigo]

Un esquema contiene la definicin de una estructura (generalmente relaciones o tablas de una base de datos), es decir, determina la identidad de la relacin y qu tipo de informacin podr ser almacenada dentro de ella; en otras palabras, el esquema contiene los metadatos de la relacin. Todo esquema constar de:
Nombre de la relacin (su identificador). Nombre de los atributos (o campos) de la relacin y sus dominios; el dominio de un atributo o campo define los valores permitidos para el mismo, equivalente al tipo de dato por ejemplocharacter, integer, date, string...
Instancias[editar editar cdigo]

Una instancia de manera formal es la aplicacin de un esquema a un conjunto finito de datos. En palabras no tan tcnicas, se puede definir como el contenido de una tabla en un momento dado, pero tambin es valido referirnos a una instancia cuando trabajamos o mostramos nicamente un subconjunto de la informacin contenida en una relacin o tabla, como por ejemplo:
Ciertos caracteres y nmeros (una sola columna de una sola fila). Algunas o todas las filas con todas o algunas columnas
Cada fila es una tupla. El nmero de filas es llamado cardinalidad. El nmero de columnas es llamado aridad o grado.
Base de datos relacional[editar editar cdigo]

Artculo principal: Base de datos relacional.
Una base de datos relacional es un conjunto de una o ms tablas estructuradas en registros (lneas) y campos (columnas), que se vinculan entre s por un campo en comn, en ambos casos posee las mismas caractersticas como por ejemplo el nombre de campo, tipo y longitud; a este campo generalmente se le denomina ID, identificador o clave. A esta manera de construir bases de datos se le denomina modelo relacional. Estrictamente hablando el trmino se refiere a una coleccin especfica de datos pero a menudo se le usa, en forma errnea como sinnimo del software usado para gestionar esa coleccin de datos. Ese software se conoce como SGBD (sistema gestor de base de datos) relacional o RDBMS (del ingls relational database management system).
Las bases de datos relacionales pasan por un proceso al que se le conoce como normalizacin de una base de datos, el cual es entendido como el proceso necesario para que una base de datos sea utilizada de manera ptima. Entre las ventajas de este modelo estn: 1. Garantiza herramientas para evitar la duplicidad de registros, a travs de campos claves o llaves. 2. Garantiza la integridad referencial: As al eliminar un registro elimina todos los registros relacionados dependientes. 3. Favorece la normalizacin por ser ms comprensible y aplicable.
Vase tambin[editar editar cdigo]

12 reglas de Codd Hugh Darwen Bases de datos Modelo de Datos lgebra relacional Clculo relacional Modelo entidad-relacin SQL Lenguaje de consulta estructurado. Tabla Registro Campo
3. Modelo relacional
3.1 Introduccin
En el captulo anterior se mencionaron 3 tipos de modelado: conceptual, lgico y fsico. El modelo e-r se considera un modelo conceptual ya que permite a un nivel alto el ver con claridad la informacin utilizada en algun problema o negocio. En este captulo nos concentraremos en desarrollar un buen modelo "lgico" que se conoce como "esquema de la base de datos" (database schema) a partir del cual se podr realizar el modelado fsico en el DBMS, es importante mencionar que es un paso necesario, no se puede partir de un modelo conceptual para realizar un fsico.
3.2 Por qu "modelo relacional" ?

Puede resultar confuso el concepto de modelo entidad-relacin vs modelo relacional, quizs porque ambos comparten casi las mismas palabras. Como se mencion en la seccin anterior, el objetivo del modelo relacional es crear un "esquema" (schema), lo cual como se mencionar posteriormente consiste de un conjunto de "tablas" que representan "relaciones", relaciones entre los datos. Estas tablas, pueden ser construdas de diversas maneras:
Creando un conjunto de tablas iniciales y aplicar operaciones de normalizacin hasta conseguir el esquema ms ptimo. Las tcnicas de nomalizacin se explican ms adelante en este captulo. Convertir el diagrama e-r a tablas y posteriormente aplicar tambin operaciones de normalizacin hasta conseguir el esquema ptimo.
La primer tcnica fue de las primeras en existir y, como es de suponerse, la segunda al ser ms reciente es mucho ms conveniente en varios aspectos:
El partir de un diagrama visual es muy til para apreciar los detalles, de ah que se llame modelo conceptual. El crear las tablas iniciales es mucho ms simple a travs de las reglas de conversin. Se podra pensar que es lo mismo porque finalmente hay que "normalizar" las tablas de todas formas, pero la ventaja de partir del modelo e-r es que la "normalizacin" es mnima por lo general. Lo anterior tiene otra ventaja, an cuando se normalice de manera deficiente, se garantiza un esquema aceptable, en la primer tcnica no es as.
3.3 Conceptos bsicos

3.3.1 Tablas
El modelo relacional proporciona un manera simple de representar los datos: una tabla bidimensional llamada relacin.
ttulo Star Wars ao 1977 duracin 124 104 95 tipo color color color
Mighty Ducks 1991 Wayne's World 1992
Relacin Pelculas La relacin Pelculas tiene la intencin de manejar la informacin de las instancias en la entidad Pelculas, cada rengln corresponde a una entidad pelcula y cada columna corresponde a uno de los atributos de la entidad. Sin embargo las relaciones pueden representar ms que entidades, como se explicar ms adelante.
3.3.2 Atributos
Los atributos son las columnas de un relacin y describen caractersticas particulares de ella.
3.3.3 Esquemas
Es el nombre que se le da a una relacin y el conjunto de atributos en ella. Pelculas (ttulo, ao, duracin, tipo) En un modelo relacin, un diseo consiste de uno o ms esquemas, a este conjunto se le conoce como "esquema relacional de base de datos" (relational database schema) o simplemente "esquema de base de datos" (database schema)
3.3.4 Tuplas
Cada uno de los renglones en una relacin conteniendo valores para cada uno de los atributos. (Star Wars, 1977, 124, color)
3.3.5 Dominios
Se debe considerar que cada atributo (columna) debe ser atmico, es decir, que no sea divisible, no se puede pensar en un atributo como un "registro" o "estructura" de datos.
3.3.6 Representaciones equivalentes de una relacin

Las relaciones son un conjunto de tuplas, no una lista de tuplas. El orden en que aparecen las tuplas es irrelevante. As mismo el orden de los atributos tampoco es relevante
ao 1991 1992 1977 ttulo tipo duracin 104 95 124
Mighty Ducks color Wayne's World Star Wars color color
Otra representacin de la relacin Pelculas
3.4 Conversin del modelo e-r a un esquema de
base de datos (Conversin a tablas)

3.4.1 Introduccin
El modelo es una representacin visual que grficamente nos da una perspectiva de como se encuentran los datos involucrados en un proyecto u organizacin. Pero el modelo no nos presenta propiamente una instancia de los datos, un ejemplo que muestre con claridad algunas datos de muestra y como se relacionan en realidad. Por eso es conveniente crear un "esquema", el cual consiste de tablas las cuales en sus renglones (tuplas) contienen instancias de los datos.
3.4.2 Conversin a tablas desde un modelo con relaciones (11,1-m,m-m)

Las tablas siguientes muestran las reglas que se deben seguir para poder crear dicho esquema.
modelo e-r conversin a tablas

una tabla por cada conjunto de entidades o nombre de tabla = nombre de conjunto de entidades una tabla por cada conjunto de relaciones m-m o nombre de tabla = nombre de conjunto de relaciones definicin de columnas para cada tabla o conjuntos fuertes de entidades columnas = nombre de atributos o conjuntos dbiles de entidades columnas = llave_primaria (dominante) U atributos(subordinado) o conjunto de relaciones R (m-m) entre A, B columnas (R) = llave_primaria (A) U llave_primaria (B) U atributos(R) o conjunto de relaciones R (1-1) entre A y B columnas (A) = atribs(A) U llave primaria(B) U atributos(R) o conjunto de relaciones R (1-m) entre A y B columnas (B) = atribs(B) U llave primaria(A) U atributos(R)
El diagrama anterior se convertira al siguiente esquema: Debil

atribs_Debil LLP_A atribs_rel_0
A
LLP_A atribs_A
B1
LLP_B1 atribs_B1
B2
LLP_B2 atribs_B2 LLP_A attribs_rel_2
B3
LLP_B3 atribs_B3 LLP_A atribs_rel_3
A_B1
LLP_A LLP_B1 atribs_rel_1
donde: LLP_X es la llave primaria de la entidad X (un subconjunto de atribs_X)
Ejemplo:
Para el ejemplo de la figura tendramos el esquema:
escuela
id url nombre
departamento
clave url nombre id_escuela
curso
clave seccion nombre clave_depto
profesor
id nombre extension
estudiante
id nombre carrera
profesor_curso
id_prof clave_curso seccion_curso
estudiante_curso
id_estud clave_curso seccion_curso
3.4.3 Conversin a tablas desde un modelo con generalizacin
modelo e-r de generalizacin a tablas dos posibilidades:

1.
o
crear una tabla para el conjunto de entidades A de mayor nivel columnas (A) = atributos(A) para cada conjunto de entidades B de menor nivel, crear una tabla tal que: columns (B) = atributos (B) U llave_primaria (A)
2.
o
si A es un conjunto de entidades de mayor nivel para cada conjunto de entidades B de menor nivel, crear una tabla tal que: columnas (B) = atributos (B) U atributos (A)
La generalizacin se convertira al siguiente esquema: 1) A

LLP_A atribs_A
B1
atribs_B1 LLP_A
B2
atribs_B2 LLP_A
B3
atribs_B3
LLP_A
2) B1
atribs_B1 LLP_A atribs_A
B2
B3
Es importante mencionar que a pesar de que existen 2 mtodos para convertir una generalizacin a tablas, no hay una regla exacta de cual usar en determinado caso. A continuacin se mencionan algunos consejos tiles para la determinacin de cual mtodo emplear:
1. Si la entidad de nivel superior est relacionada con otra(s) entidades puede sugerirse emplear el mtodo (1) ya que de esa manera la tabla (A) ser la nica involucrada en la relacin, de otra forma se tendran tres tablas (B1,B2 y B3) formando parte de la relacin 2. Es importante tomar en cuenta la pertenencia de instancias, si se considera que hablamos de una generalizacin disjunta, donde no se puede pertenecer a varias entidades de nivel inferior, quizs sea recomendable el mtodo (1), en otro caso se podra pensar en el mtodo (2).
3. Tambin es importante analizar ambos casos con respecto a las "consultas" que se deseen realizar ya que esto tambin determina en muchos casos el mtodo a emplear.
3.4.4 Descubrimiento de llaves en las relaciones

Las llaves resultantes en las relaciones de un esquema se pueden inferir de la siguiente manera: 1) Cada tabla que provenga de una entidad contiene por si misma una llave 2) Para las tablas resultado de una relacin se toman las llaves primarias de ambas entidades y stas conforman la nueva llave primaria, excepto en un caso como el que sigue:
Podemos observar que existe una relacin m-m entre "actor" y "serie", demostrando que un actor puede actuar en muchas series y que muchas
series tendrn a los mismos actores. La tabla que se creara sera: actor_serie
id_actor Joaqun Pardav Evita Muoz (Chachita) Joaqun Pardav Evita Muoz (Chachita) id_serie Gnesis Qu bonita familia Gnesis Hermelinda linda id_personaje Abel hermano bueno Dulce abuelita Can hermano malo Bruja Hermelinda
si se considera "id_actor, id_serie" como la llave primaria caemos en un problema porque esa combinacin no identifica de manera nica a la tupla, como es el caso de "Joaqun Pardav, Gnesis" ya que en la primer tupla tenemos que determina a "Abel hermano bueno" y en la tercera a "Can hermano malo". La relacin es correcta ya que un actor puede representar a varios personajes en la misma obra, pero entonces la llave "id_actor, id_serie" no es la correcta y en este caso lo ms recomendable sera emplear los tres atributos de la relacin "id_actor, id_serie, id_personaje"
3.5 Normalizacin
Una vez creadas las tablas hay que verificarlas y revisar si an se puede reducir u optimizar de alguna manera. Los problemas tales como la redundancia que ocurren cuando se abarrotan demasiados datos en un sola relacin son llamados anomalas. Los principales tipos son:
1. Redundancia: la informacin se repite innecesariamente en muchas tuplas. En la
relacin siguiente, length y filmType. 2. Anomalas de actualizacin: cuando al cambiar la informacin en una tupla se descuida el actualizarla en otra. Si en la relacin encontramos que el length de StarWars es 125 podramos cambiarlo nicamente para la primer tupla y olvidar actualizar las dems. 3. Anomalas de eliminacin: si un conjunto de valores llegan a estar vacos y se llega a perder informacin relacionada como un efecto de la eliminacin. Si eliminamos al actor Emilio Estevez, perdemos tambin la tupla de la pelcula MightyDucks. title Star Wars Star Wars Star Wars year length filmType studioName starName 1977 1977 1977 124 124 124 104 95 95 color color color color color color Fox Fox Fox Disney Paramount Paramount Carrie Fisher Mark Hamill Harrison Ford Emilio Estevez Dana Carvey Mike Meyers
Mighty Ducks 1991 Wayne's World Wayne's World 1992 1992
3.5.1 Dependencias funcionales (FD)

3.5.1.1 Definicin
En el diseo de esquemas de bases de datos el concepto de dependencia funcional (functional dependency) es vital para eliminar "redundancia", otros factores sera el manejo de dependencias multivaluadas y las restricciones de integridad referencial. Una dependencia funcional en una relacin R es una enunciado de la forma "si dos
tuplas de R concuerdan en los atributos A1,A2,...An (tienen los mismos valorespara cada atributo), entonces deben concordar tambin con otro atributo B" . Esta FD se escribira como A1,A2,....An --> B y se dice que "A1, A2,....An
determina funcionalmente a B". Por otro lado, si un conjunto de atributos A1,A2...An determina funcionalmente a ms de un atributo, A1, A2, ... An ---> B1
A1, A2, ... An ---> B2 A1, A2, ... An ---> Bm entonces podemos simplemente escribir este conjunto de FDs como: A1, A2, ...An ---> B1,B2,...Bm Movies(title, year, length, filmType, studioName, starName)
title Star Wars year length 1977 124 filmType studioName starName color Fox Carrie Fisher Mark Hamill Harrison Ford Emilio Estevez Dana Carvey Mike Meyers
Star Wars
1977 124
color
Fox
Star Wars Mighty Ducks Wayne's World Wayne's World ...
1977 124
color
Fox
1991 104
color
Disney
1992 95
color
Paramount
1992 95
color
Paramount
title, year --> length title, year --> filmType title, year --> studioName title, year -/-> starName podemos entonces afirmar que: title, year --> length, filmType, studioName Quizs las dependencias funcionales ms evidentes sean las llaves. Decimos que un conjunto { A1, A2,....An } es una llave de un relacin si:
1. Esos atributos determinan funcionalmente a "todos" los dems atributos de una relacin. 2. No hay un subconjunto de { A1, A2,....An } que determine funcionalmente a "todos" los dems atributos (incluyendo al resto del conjunto { A1, A2,....An })
La definicin anterior de llave es similar a la que se mencion anteriormente de superllave, sin embargo las superllaves no son llaves "mnimas", recordemos que una llave primaria se escoge de entre el conjunto de superllaves mnimas. Es importante hacer notar que una llave mnima no se refiere al nmero de atributos includos, se puede tener una llave mnima ABC y otra DE donde ambas son mnimas an cuando una de ellas sea todava de menor tamao que la otra. Al conjunto de dependencia funcionales de una relacin R se le denominar F.
3.5.1.2 Axiomas de Armstrong:
Reflexividad: sea >
un conjunto de atributos y --> --> y y
entonces
---
*
es un conjunto de atributos entonces --> entonces -->
Aumentacin: si > Transitividad: si
*Nota:
De manera general una dependencia funcional de la forma "dependencia funcional trivial" si Si al menos algn elemento de dependencia no trivial. no pertenece a
-->
se considera
se considera una
Si ningn elemento de pertenece a completamente no trivial
entonces se considera una dependencia
3.5.1.3 Reglas adicionales

Unin: si
-->
--> --> -->
entonces entonces y
--> --> --> y --> --> entonces
Decomposicin: si
Pseudotransitividad: si
3.5.1.4 Cerradura de un conjunto de atributos
Para un esquema R y un conjunto de atributos superllave para determinar lo anterior se puede encontrar dependen funcionalmente de teniendo R(A,B,C,D,E)
, si
--> R entonces
es
+, todos los atributos que
si A+=(A,B,C,D,E), entonces A--> R entonces A es superllave La cerradura se puede calcular siguiendo el siguiente algoritmo: entrada: salida: +
result= while changes to result do for each ( ) do begin if result then result=result end end result --> (reflexividad) --> , --> --> F = =result
,F
(transitividad)
teniendo R (A,B,C,D,E,F) y F las dependencias: AB-->C, BC-->AD, D-->E, CF-->B. Comprobar que {A,B}+ ={A,B,C,D,E}
Si {A,B}+ = {A,B,C,D,E,F} entonces podramos afirmar que AB es superllave, pero para ello sera necesaria alguna dependencia adicional ej. AB --> CF El calcular la cerradura es empleado para:

Verificar si es una superllave, calculando todos los atributos de la relacin R. Verificar una dependencia funcional -->
+ y revisando si
+ contiene a
(es decir, si pertenece a F+)
checando si +. Calcular F+ (la cerradura de todo el conjunto de dependencias F en una relacin R): Para cada R se calcula + y para cada elemento S --> S. + se obtiene una dependencia funcional
3.5.2 Primera forma normal

Una tabla se encuentra en 1a NF, si todos sus atributos son atmicos (indivisibles) El ejemplo clsico:
nombre direccin telfono
En 1a. NF
nombre apellido_paterno apellido_materno direccin telfono
3.5.3 Segunda forma normal

Una tabla se encuentra en 2a NF, si est en 1a NF y cada atributo que NO es llave es "completamente" dependiente de la llave. Si tenemos la tabla: calificaciones_cursos
id_estudiante depto clave_curso descripcin calificacin
NO se encuentra en 2a NF ya que { id,clave,depto} --> descripcin {clave,depto} --> descripcin
Analizando todas las dependencias funcionales: { id,clave,depto} --> descripcin {clave,depto} --> descripcin { id,clave,depto} --> calificacin Para realizar la normalizacin (2NF) la relacin se descompondra en: curso
depto clave_curso descripcin
estud_curso
id depto clave_curso calificacin
La descomposicin se basa bsicamente en:

La intuicin Las dependencias funcionales
Es importante que al descomponer una relacin exista:

Descomposicin sin prdida Preservacin de dependencias funcionales
3.5.4 Descomposicin sin prdida
Al descomponer una relacin R en varias relaciones R1 y R2 se debe verificar que no haya prdidas, es decir, que al volver a combinar las relaciones (producto entre R1 y R2) se obtengan exactamente las mismas tuplas. Decimos entonces que para una descomposicin en R1 y R2 no hay prdida si: { R1 R2 --> R1 } F+
o bien si { R1 R2 --> R2 } F+
Para el ejemplo anterior la relacin

id_estudiante depto clave_curso descripcin calificacin
F={ { id,clave,depto} --> descripcin, {clave,depto} --> descripcin, { id,clave,depto} --> calificacin } tiene F+= { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin } y dicha relacin se descompone en:
depto clave_curso descripcin
id_estudiante
depto
clave_curso
calificacin
donde R1
R2 = depto,clave_curso donde depto,clave_curso -->descripcin
y {depto,clave_curso -->descripcin} { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin }
3.5.5 Preservacin de dependencias

Al descomponer una relacin R en varias relaciones R1,R2,..Rn es importante revisar que se preserven las dependencias funcionales iniciales. De esta manera se garantiza que una actualizacin no provoque una relacin invlida, verificando las FDs o bien a travs de combinaciones de relaciones(productos o joins) aunque esto ltimo no es muy eficiente. Para ello se analizan todas la dependencias funcionales Fi para cada Ri que debern ser un subconjunto de F+
De manera que F' = F1
F2
...Fn
y la preservacin se verifica si F'+= F+ para el ejemplo anterior teniendo: F={ { id,clave,depto} --> descripcin, {clave,depto} --> descripcin, { id,clave,depto} --> calificacin } F+= { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} -> descripcin } F1= depto,clave_curso--> descripcin F2= id_estudiante,depto,clave_curso --> calificacin F' = F1 F2
depto,clave_curso--> descripcin id_estudiante,depto,clave_curso --> calificacin F'+= { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} -> descripcin } y como F'+= F+ entonces si hay preservacin de dependencias.
3.5.6 Forma normal de Boyce-Codd (BCNF)

3.5.6.1 Caractersticas
Un esquema relacional se encuentra en BCNF si para toda dependencia funcional X --> A:
X --> A es una dependencia funcional trivial
X es una super llave
BCNF no necesariamente preserva las dependencias funcionales F'+ != F+
3.5.6.2 Algoritmo general de descomposicin tratando de alcanzar BCNF
result= {R} done=false calcular F+ while (! done) do if(existe un esquema Ri en result que no est en BCNF) then si --> es una dependencia funcional no trivial en Ri tal que est en F+ y else done=true end =0 result= ( result - Ri ) ( Ri ) ( , ) --> Ri no
Ejemplo: R(A,B,C,D) B--> C

B-->D (B)+ = {CD}
La superllave sera {AB} por lo tanto no cumple con BCNF (B-->CD y B no es superllave). Descomponiendo usando B-->CD (A,B) (B,C,D) Esta ltima en BCNF
3.5.7 Tercera forma normal

3.5.7.1 Caractersticas
Un esquema relacional se encuentra en 3NF si para toda dependencia funcional X -> A:
X --> A es una dependencia funcional trivial
X es una super llave
A es miembro de una llave candidata de R Lo anterior no quiere decir que una sola llave candidata deba contener a todos los atributos de A, cada atributo de A puede estar contenido en llaves candidatas diferentes.
Se puede observar que las 2 primeras restricciones son las mismas que para BCNF pero existe una tercera que da flexibilidad a las relaciones. Podemos afirmar entonces que: "Si una relacin est en BCNF, est tambin 3NF; pero si una relacin est en 3NF no necesariamente est en BCNF". ejemplo, dada la relacin
branch-name customer-name banker-name office-number
banker-name --> branch-name office-number customer-name branch-name --> banker-name Se puede observar {customer-name branch-name} determina al resto de los atributos as que es la superllave de R. No est en 3NF porque:

Las DFs no son triviales En la primer dependencia, "banker-name" no es superllave de R Se puede observar que office-number y banker-name no son parte de alguna llave candidata
se descompondra en:
banker-name branch-name office-number
banker-name --> branch-name office-number
customer-name
branch-name
banker-name
customer-name branch-name --> banker-name banker-name --> branch-name Esta descomposicin si est en 3NF porque:

No hay dependencias funcionales triviales En la segunda relacin, la segunda DF no cumple que banker-name es superllave
En la segunda relacin, la segunda DF, branch-name es miembro de la llave candidata {customer-name, branch-name}
Al cumplirse la 3er regla se confirma que la descomposicin est en 3NF. Se puede observar que al no cumplir con las 2 primeras no est en BCNF pero gracias al relajamiento si est en 3NF Otro ejemplo: deptos
nombre_depto extensin id_jefe
nombre_depto --> extensin, jefe empleados

id_empleado nombre_depto id_jefe
id_empleado --> nombre_depto, id_jefe nombre_depto --> id_jefe No est en 3NF porque:

Las DFs no son triviales En la dependencia "nombre_depto-->id_jefe" de la segunda relacin, "nombre_depto" no es superllave de R Se puede observar nuevamente para la segunda relacin que id_jefe no es parte de alguna llave candidata
Aplicando la descomposicin: deptos

nombre_depto extensin id_jefe
nombre_depto --> extensin, jefe empleados

id_empleado nombre_depto
id_empleado --> nombre_depto Esta descomposicin si est en 3NF porque:

No hay dependencias funcionales triviales Para toda dependencia X--> A , X es superllave.
Se observa como la relacin no solo est en 3NF sino tambin en BCNF por cumplir con la segunda regla.
3.5.7.2 Algoritmo general de descomposicin tratando de alcanzar 3NF 3.5.7.2.1 Forma cannica de las FDs (Fc)
La forma cannica de F es aquel conjunto mnimo de dependencias funcionales equivalentes a F, sin dependencias redundantes o partes redundantes de dependencias. Para obtener la Fc se deben extraer todos los miembros "extraos", suponga un conjunto F de dependencias funcionales y la dependencia --> est en F.
El atributo A es extrao en F lgicamente implica (F - {
si A --> })
y {( - A ) --> }
Ejemplo: F = { A --> C , AB --> C } B es extrao en AB --> C porque { A --> C, AB --> C } lgicamente implica A --> C (el resultado de quitar B de AB --> C ).
El atributo A es extrao en
si A
el conjunto de dependencias (F - { lgicamente a F
-->
})
--> (
- A ) } implica
Ejemplo: F = { A --> C , AB --> CD} C es extrao en AB --> CD porque A B --> C puede ser inferido an despus de eliminar C Test para verificar si un atributo es extrao Dado un conjunto de dependencias F y
-->
est en F
Para verificar si A
o o
es extrao en } - A )+ usando las dependencias en F } - A )+ contiene a es extrao en + usando solo las dependencias en: , si lo hace entonces A es extrao
calcular ( { verificar si ( { calcular
Para verificar si A
o
F'=(F - {
o
-->
})
--> (
- A) }
verificar si
+ contiene a A, si lo hace entonces A es extrao
3.5.7.2.2 Algoritmo basado en Fc

Fc: Forma cannica de las FDs
1. Para cada dependencia X --> Y en Fc, crear una relacin Ri (X,Y) 2. Si ninguna de las Ris contiene una de las superllaves de la relacin, crear Ri(X) donde X es una de las superllaves de la relacin original 3. Si Ri y Rj tienen una llave en comn, mezclar Ri y Rj 4. Eliminar relaciones redundantes
*El algoritmo anterior garantiza que en una descomposicin no haya prdida (al incluir por lo menos en una relacin una de las superllaves) y que se preserven las dependencias funcionales (al incluir cada una de ellas). Ejemplo:
sid
name
street student
city
zip
Fc: sid -->name,street,city street, city-->zip zip --> city Descomponer en 3NF
1. 2. 3. 4. R1(sid, name, street, city), R2(zip, street, city), R3(zip, city) Eliminar R3 sid name street city
R1 sid -->name,street,city
zip street city
R2 street, city-->zip zip --> city
3.5.8 BCNF vs 3NF

Como se mencion anteriormente: "Si una relacin est en BCNF, est tambin 3NF; pero si una relacin est en 3NF no necesariamente est en BCNF". En la prctica la mayora de los esquemas en 3NF tambin estn en BCNF, contraejemplo: (Sucursal, Cliente, Banquero) banquero --> sucursal sucursal, cliente --> banquero
est en 3NF pero no en BCNF puesto que "banquero" no es una superllave, normalizando: suc-banquero (sucursal, banquero) suc-cliente (sucursal, cliente) Nuevamente se presentan las prdidas de dependencias Qu es mejor ? BCNF o 3NF ?

De manera general se puede decir que ambas son buenas. El caso ideal es conseguir BCNF sin prdidas y con preservacin de dependencias. Si se alcanza BCNF pero no hay preservacin de dependencias se puede considerar una 3NF (recordando que 3NF siempre debe carecer de prdidas y debe preservar dependencias).
3.6 Conclusiones
De manera que las metas del diseo de bases de datos con dependencias funcionales son:

BCNF* Descomposicin sin prdida Preservacin de dependencias
* Llegar a una forma BCNF puede llegar a ser complicado, debido a esto en muchas ocasiones es suficiente con alcanzar la 3NF para lograr un buen diseo.
Forma normal (base de datos)

En la teora de bases de datos relacionales, las formas normales (NF) proporcionan los criterios para determinar el grado de vulnerabilidad de una tabla a inconsistencias y anomalas lgicas. Mientras sea ms alta la forma normal aplicable a una tabla, es menos vulnerable a inconsistencias y anomalas. Cada tabla tiene una "forma normal ms alta" (HNF): por definicin, una tabla siempre satisface los requisitos de su HNF y de todas las formas normales ms bajas que su HNF; tambin por definicin, una tabla no puede satisfacer los requisitos de ninguna forma normal ms arriba que su HNF. Las formas normales son aplicables a tablas individuales; decir que una base de datos entera est en la forma normal n es decir que todas sus tablas estn en la forma normal n. Los recin llegados al diseo de bases de datos a veces suponen que la normalizacin procede de una manera iterativa, es decir un diseo 1NF primero se normaliza a 2NF, entonces a 3NF, etctera. sta no es una descripcin exacta de cmo la normalizacin trabaja tpicamente. Una tabla sensiblemente diseada es probable que est en 3NF en la primera tentativa; adems, si est en 3NF, tambin es extremadamente probable que tenga una forma HNF de 5NF. Conseguir formas normales "ms altas" (sobre 3NF) usualmente no requiere un gasto adicional de esfuerzo por parte del diseador, porque las tablas 3NF usualmente no necesitan ninguna modificacin para satisfacer los requisitos de estas formas normales ms altas. Edgar F. Codd originalmente defini las tres primeras formas normales (1NF, 2NF, y 3NF). Estas formas normales se han resumido como requiriendo que todos los atributos no-clave sean dependientes en "la clave, la clave completa, y nada excepto la clave". Las cuarta y quinta formas normales (4NF y 5NF) se ocupan especficamente de la representacin de las relacionesmuchos a muchos y uno muchos entre los atributos. La sexta forma normal (6NF), en pocas palabras, se basa en el principio de que si se tiene ms de dos llaves candidatas en una tabla, se tendrn que crear otras tablas con estas. Por ejemplo si tenemos "tem" con un id cdigo de producto y con los atributos descripcin y precio que son llaves candidatas se tendra que crear otras tablas separando la tabla tem: ItemDesc {cdigo_producto*, Descripcin} ItemPrecio {cdigo_producto*, Precio}. No es muy utilizada la sexta forma normal por que genera mas tablas cuando tenemos pequeas bases de datos.
Primera forma normal

(Redirigido desde 1NF)
La primera forma normal (1FN o forma mnima) es una forma normal usada en normalizacin de bases de datos. Una tabla de base de datos relacional que se adhiere a la 1FN es una que satisface cierto conjunto mnimo de criterios. Estos criterios se refieren bsicamente a asegurarse que la tabla es una representacin fiel de una relacin1 y est libre de "grupos repetitivos".2 Sin embargo, el concepto de "grupo repetitivo", es entendido de diversas maneras por diferentes tericos. Como consecuencia, no hay un acuerdo universal en cuanto a qu caractersticas descalificaran a una tabla de estar en 1FN. Muy notablemente, la 1FN, tal y como es definida por algunos autores excluye "atributos relacin-valor" (tablas dentro de tablas) siguiendo el precedente establecido por (E.F. Codd) (algunos de esos autores son: Ramez Elmasri y Shamkant B. Navathe 3 ). Por otro lado, segn lo definido por otros autores, la 1FN s los permite (por ejemplo como la define Chris Date).
ndice
[ocultar]
1 Las tablas 1FN como representaciones de relaciones 2 Grupos repetidos
o o o o
2.1 Ejemplo 1: Dominios y valores 2.2 Ejemplo 2: Grupos repetidos a travs de columnas 2.3 Ejemplo 3: Repeticin de grupos dentro de columnas 2.4 Un diseo conforme con 1FN
3 Atomicidad 4 Normalizacin ms all de la 1NF 5 Notas y referencias 6 Vase tambin 7 Lectura adicional 8 Enlaces externos
Las tablas 1FN como representaciones de relaciones[editar editar

cdigo]
Segn la definicin de Date de la 1FN, una tabla est en 1FN si y solo si es "isomorfa a alguna relacin", lo que significa, especficamente, que satisface las siguientes cinco condiciones:
1. No hay orden de arriba-a-abajo en las filas.
2. No hay orden de izquierda-a-derecha en las columnas. 3. No hay filas duplicadas. 4. Cada interseccin de fila-y-columna contiene exactamente un valor del dominio aplicable (y nada ms). 5. Todas las columnas son regulares [es decir, las filas no tienen componentes como IDs de fila, IDs de objeto, o timestamps ocultos]. Chris Date, "What First Normal Form Really Means", pp. 127-8
4
La violacin de cualesquiera de estas condiciones significara que la tabla no es estrictamente relacional, y por lo tanto no est en 1FN. Algunos ejemplos de tablas (o de vistas) que no satisfacen esta definicin de 1FN son:
Una tabla que carece de una clave primaria. Esta tabla podra acomodar filas duplicadas, en violacin de la condicin 3.
Una vista cuya definicin exige que los resultados sean retornados en un orden particular, de modo que el orden de la fila sea un aspecto intrnseco y significativo de la vista.5 Esto viola la condicin 1. Las tuplas en relaciones verdaderas no estn ordenadas una con respecto de la otra.
Una tabla con por lo menos un atributo que pueda ser nulo. Un atributo que pueda ser nulo estara en violacin de la condicin 4, que requiere a cada campo contener exactamente un valor de su dominio de columna. Sin embargo, debe observarse que este aspecto de la condicin 4 es controvertido. Muchos autores consideran que una tabla est en 1FN si ninguna clave candidata puede contener valores nulos, pero se aceptan stos para atributos (campos) que no sean clave, segn el modelo original de Codd sobre el modelo relacional, el cual hizo disposicin explcita para los nulos.6
Grupos repetidos[editar editar cdigo]

La cuarta condicin de Date, que expresa "lo que la mayora de la gente piensa como la caracterstica que define la 1FN",7 concierne a grupos repetidos. El siguiente ejemplo ilustra cmo un diseo de base de datos puede incorporar la repeticin de grupos, en violacin de la 1FN.
Ejemplo 1: Dominios y valores[editar editar cdigo]
Suponga que un diseador principiante desea guardar los nombres y los nmeros telefnicos de los clientes. Procede a definir una tabla de cliente como la que sigue:
Cliente
ID Cliente Nombre Apellido
Telfono
123
Rachel
Ingram
555-861-2025
456
James
Wright
555-403-1659
789
Cesar
Dure
555-808-9633
En este punto, el diseador se da cuenta de un requisito para guardar mltiples nmeros telfonicos para algunos clientes. Razona que la manera ms simple de hacer esto es permitir que el campo "Telfono" contenga ms de un valor en cualquier registro dado:
Cliente
Telfono
123
Rachel
Ingram
555-861-2025
456
James
Wright
555-403-1659 555-776-4100
789
Cesar
Dure
555-808-9633
Asumiendo, sin embargo, que la columna "Telfono" est definida en algn tipo de dominio de nmero telefnico (por ejemplo, el dominio de cadenas de 12 caracteres de longitud), la representacin de arriba no est en 1FN. La
1FN (y, para esa materia, el RDBMS) prohbe a un campo contener ms de un valor de su dominio de columna.
Ejemplo 2: Grupos repetidos a travs de columnas[editar editar cdigo]

El diseador puede evitar esta restriccin definiendo mltiples columnas del nmero telefnico:
Cliente
Telfono 1
Telfono 2
Telfono 3
123
Rachel
Ingram
555-861-2025
456
James
Wright
555-403-1659 555-776-4100
789
Cesar
Dure
555-808-9633
Sin embargo, esta representacin hace uso de columnas que permiten valores nulos, y por lo tanto no se conforman con la definicin de la 1NF de Date. Incluso si se contempla la posibilidad de columnas con valores nulos, el diseo no est en armona con el espritu de 1NF. Telfono 1, Telfono 2, y Telfono 3, comparten exactamente el mismo dominio y exactamente el mismo significado; el dividir del nmero de telfono en tres encabezados es artificial y causa problemas lgicos. Estos problemas incluyen:
Dificultad en hacer consultas a la tabla. Es difcil contestar preguntas tales como "Qu clientes tienen el telfono X?" y "Qu pares de clientes comparten un nmero de telfono?".
La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-aTelfono por medio del RDBMS. Al cliente 789 se le puede dar equivocadamente un valor para el Telfono 2 que es exactamente igual que el valor de su Telfono 1.
La restriccin de los nmeros de telfono por cliente a tres. Si viene un cliente con cuatro nmeros de telfono, estamos obligados a guardar
solamente tres y dejar el cuarto sin guardar. Esto significa que el diseo de la base de datos est imponiendo restricciones al proceso del negocio, en vez de (como idealmente debe ser el caso) al revs.
Ejemplo 3: Repeticin de grupos dentro de columnas[editar editar cdigo]

El diseador puede, alternativamente, conservar una sola columna de nmero de telfono, pero alterando su dominio, haciendo una cadena de suficiente longitud para acomodar mltiples nmeros telefnicos:
Cliente
Telfono
123
Rachel
Ingram
555-861-2025
456
James
Wright
555-403-1659, 555-776-4100
789
Cesar
Dure
555-808-9633
ste es defendiblemente el peor diseo de todos, y otra vez no mantiene el espritu de la 1NF. El encabezado "Telfono" llega a ser semnticamente difuso, ya que ahora puede representar, o un nmero de telfono, o una lista de nmeros de telfono, o de hecho cualquier cosa. Una consulta como "Qu pares de clientes comparten un nmero telefnico?" es virtualmente imposible de formular, dada la necesidad de proveerse de listas de nmeros telefnicos as como nmeros telefnicos individuales. Con este diseo en la RDBMS, son tambin imposibles de definir significativas restricciones en nmeros telefnicos.
Un diseo conforme con 1FN[editar editar cdigo]

Un diseo que est inequvocamente en 1FN hace uso de dos tablas: una tabla de cliente y una tabla de telfono del cliente.
Cliente
123
Rachel
Ingram
456
James
Wright
789
Cesar
Dure
Telfono del cliente
ID Cliente
Telfono
123
555-861-2025
456
555-403-1659
456
555-776-4100
789
555-808-9633
En este diseo no ocurren grupos repetidos de nmeros telefnicos. En lugar de eso, cada enlace Cliente-a-Telfono aparece en su propio registro. Es valioso notar que este diseo cumple los requerimientos adicionales para la segunda (2NF) y la tercera forma normal (3FN).
Atomicidad[editar editar cdigo]

Algunas definiciones de 1NF, ms notablemente la de E.F. Codd, hacen referencia al concepto de atomicidad. Codd indica que "se requiere que los valores sean atmicos con respecto al DBMS en los dominios en los que cada relacin es definida".8 Codd define un valor atmico como uno que "no puede ser descompuesto en pedazos ms pequeos por el DBMS (excepto ciertas funciones especiales)".9
[Hugh Darwen] y [Chris Date] han sugerido que el concepto de Codd de un "valor atmico" es ambiguo, y que esta ambigedad ha conducido a una extensa confusin sobre cmo debe ser entendida la 1NF.10 11 En particular, la nocin de un "valor que no puede ser descompuesto" es problemtica, pues parecera implicar que pocos, si algn, tipos de datos son atmicos:
Una cadena de caracteres parecera no ser atmica, ya que el RDBMS tpicamente proporciona operadores para descomponerla en subcadenas.
Una fecha parecera no ser atmica, ya que el RDBMS proporciona tpicamente operadores para descomponerla los componentes de da, mes, y ao.
Un nmero de punto fijo parecera no ser atmico, ya que el RDBMS proporciona tpicamente operadores para descomponerlo en componentes de nmeros enteros y fraccionarios.
Date sugiere que "la nocin de atomicidad no tiene ningn significado absoluto":12 un valor puede ser considerado atmico para algunos propsitos, pero puede ser considerado un ensamblaje de elementos ms bsicos para otros propsitos. Si esta posicin es aceptada, la 1NF no puede ser definida con referencia a la atomicidad. Las columnas de cualquier tipo de datos concebible (desde tipos de cadenas y tipos numricos hasta tipos de arreglos y tipos de tabla) son entonces aceptables en un tabla 1NF - aunque quizs no siempre deseable. Date discute que los atributos relacin-valor, por medio de los cuales un campo dentro de una tabla puede contener una tabla, son tiles en casos raros.13
Normalizacin ms all de la 1NF[editar editar

cdigo]
Cualquier tabla que est en la segunda forma normal (2NF) o ms arriba, tambin est, por definicin, en 1NF (cada forma normal tiene criterios ms rigurosos que su precursor). Por una parte, una tabla que est en 1NF puede o no puede estar en 2NF; si est en 2NF, puede o no puede estar en 3NF, y as sucesivamente.
Las formas normales ms arriba que la 1NF son pensadas para ocuparse de las situaciones en las que una tabla sufre de problemas de diseo que pueden comprometer la integridad de los datos dentro de ella. Por ejemplo, la tabla siguiente est en 1NF, pero no est en 2NF y por lo tanto es vulnerable a inconsistencias lgicas:
Direccin de correo del subscriptor
ID del subscriptor
Direccin de correo
Primer nombre del subscriptor
Apellido del subscriptor
108
steve@aardvarkmail.net
Steve
Wallace
252
carol@mongoosemail.org
Carol
Robertson
252
crobertson@aardvarkmail.net Carol
Robertson
360
hclark@antelopemail.com
Harriet
Clark
La clave de la tabla es {ID del subscriptor, Direccin de correo}. Si Carol Robertson cambia su apellido por el de matrimonio, el cambio debe ser aplicado a dos filas. Si el cambio es aplicado solamente a una fila, resulta en una contradiccin: la pregunta "cul es nombre del cliente 252?" tiene dos respuestas que estn en conflicto. La 2NF aborda este problema.
Notas y referencias[editar editar cdigo]

1. Jump up "[T]he overriding requirement, to the effect that the table must directly and faithfully represent a relation, follows from the fact that 1NF was originally defined as a property of relations, not tables." Date, C.J. "What First Normal Form Really Means" in Date on Database: Writings 2000-2006 (Springer-Verlag, 2006), p. 128.
2.
Jump up "First normal form excludes variable repeating fields and groups." Kent, William. "A Simple Guide to Five Normal Forms in Relational Database Theory", Communications of the ACM 26 (2), Feb. 1983, pp. 120-125.
3.
Jump up Elmasri, Ramez and Navathe, Carlos C, Shamkant B. Fundamentals of Database Systems, Fourth Edition (AddisonWesley, 2003), p. 315.
4.
Jump up Date, C.J. "What First Normal Form Really Means" pp. 127-128.
5.
Jump up Such views cannot be created using SQL that conforms to the SQL:2003 standard.
6.
Jump up The third of Codd's 12 rules states that "Null values... [must be] supported in a fully relational DBMS for representing missing information and inapplicable information in a systematic way, independent of data type." Codd, E.F. "Is Your DBMS Really Relational?" Computerworld, October 14, 1985.
7.
Jump up Date, C.J. "What First Normal Form Really Means" p. 128.
8.
Jump up Codd, E.F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990).
9.
Jump up Codd, E.F. The Relational Model for Database Management Version 2 (Addison-Wesley, 1990), p. 6.
10. Jump up Darwen, Hugh. "Relation-Valued Attributes; or, Will the Real First Normal Form Please Stand Up?", in C. J. Date and Hugh Darwen, Relational Database Writings 1989-1991 (AddisonWesley, 1992). 11. Jump up "[F]or many years," writes Date, "I was as confused as anyone else. What's worse, I did my best (worst?) to spread that confusion through my writings, seminars, and other presentations." Date, C.J."What First Normal Form Really Means" in Date on Database: Writings 2000-2006 (Springer-Verlag, 2006), p. 108 12. Jump up Date, C.J. "What First Normal Form Really Means" p. 112. 13. Jump up Date, C.J. "What First Normal Form Really Means" pp. 121-126.

1NF - 2NF - 3NF - BCNF - 4NF - 5NF - DKNF - Denormalizacin Sistema atributo-valor
Segunda forma normal

La segunda forma normal (2NF) es una forma normal usada en normalizacin de bases de datos. La 2NF fue definida originalmente por E.F. Codd1 en 1971. Una tabla que est en la primera forma normal (1NF) debe satisfacer criterios adicionales para calificar para la segunda forma normal. Especficamente: una tabla 1NF est en 2NF si y solo si, dada una clave primaria y cualquier atributo que no sea un constituyente de la clave primaria, el atributo no clave depende de toda la clave primaria en vez de solo de una parte de ella. En trminos levemente ms formales: una tabla 1NF est en 2NF si y solo si ninguno de sus atributos no-principales son funcionalmente dependientes en una parte (subconjunto propio) de unaclave primaria (Un atributo no-principal es uno que no pertenece a ninguna clave primaria). Observe que cuando una tabla 1NF no tiene ninguna clave candidata compuesta (claves candidatas consistiendo en ms de un atributo), la tabla est automticamente en 2NF.
ndice
[ocultar]
1 Ejemplo 2 2NF y las claves candidatas 3 Referencias 4 Lectura adicional 5 Vase tambin 6 Enlaces externos
Ejemplo[editar editar cdigo]

Considere una tabla describiendo las habilidades de los empleados:
Habilidades de los empleados
Empleado
Habilidad
Lugar actual de trabajo
Jones
Mecanografa
114 Main Street
Jones
Taquigrafa
114 Main Street
Jones
Tallado
114 Main Street
Bravo
Limpieza ligera 73 Industrial Way
Ellis
Alquimia
73 Industrial Way
Ellis
Malabarismo
73 Industrial Way
Harrison
Limpieza ligera 73 Industrial Way
La nica clave candidata de la tabla es {Empleado, Habilidad}. El atributo restante, Lugar actual de trabajo, es dependiente solo en parte de la clave candidata, llamada Empleado. Por lo tanto la tabla no est en 2NF. Observe la redundancia de la manera en que son representadas los Lugares actuales de trabajo: nos dicen tres veces que Jones trabaja en la 114 Main Street, y dos veces que Ellis trabaja en 73 Industrial Way. Esta redundancia hace a la tabla vulnerable a anomalas de actualizacin: por ejemplo, es posible actualizar el lugar del trabajo de Jones en sus registros "Mecanografa" y "Taquigrafa" y no actualizar su registro "Tallado". Los datos resultantes implicaran respuestas contradictorias a la pregunta "Cul es el lugar actual de trabajo de Jones?". Un alternativa 2NF a este diseo representara la misma informacin en dos tablas:
Empleados
Empleado Lugar actual de trabajo
Jones
114 Main Street
Bravo
73 Industrial Way
Ellis
73 Industrial Way
Harrison
73 Industrial Way
Habilidades de los empleados
Empleado
Habilidad
Jones
Mecanografa
Jones
Taquigrafa
Jones
Tallado
Bravo
Limpieza ligera
Ellis
Alquimia
Ellis
Malabarismo
Harrison
Limpieza ligera
Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales estn en 2NF. Sin embargo, no todas las tablas 2NF estn libres de anomalas de actualizacin. Un ejemplo de una tabla 2NF que sufre de anomalas de actualizacin es:
Ganadores del torneo
Torneo
Ao
Ganador
Fecha de nacimiento del ganador
Des Moines Masters 1998 Chip Masterson 14 de marzo de 1977
Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975
Cleveland Open
1999 Bob Albertson 28 de septiembre de 1968
Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975
Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977
Aunque el Ganador y la Fecha de nacimiento del ganador estn determinadas por una clave completa {Torneo, Ao} y no son partes de ella, particularmente las combinaciones Ganador / Fecha de nacimiento del ganador son mostradas redundantemente en mltiples registros. Este problema es tratado por la tercera forma normal (3NF).
2NF y las claves candidatas[editar editar cdigo]

Una tabla para la cual no hay dependencias funcionales parciales en la clave primaria est tpicamente, pero no siempre, en 2NF. Adems de la clave principal, la tabla puede contener otras claves candidatas; es necesario establecer que ningn atributo no-principal tienen dependencias de clave parciales en cualesquiera de estas claves candidatas. Las mltiples claves candidatas ocurren en la siguiente tabla:
Modelos elctricos de cepillo de dientes
Fabricante
Modelo
Nombre completo del modelo Pas del fabricante
Forte
X-Prime
Forte X-Prime
Italia
Forte
Ultraclean
Forte Ultraclean
Italia
Dent-o-Fresh EZBrush
Dent-o-Fresh EZBrush
USA
Kobayashi
ST-60
Kobayashi ST-60
Japn
Hoch
Toothmaster Hoch Toothmaster
Alemania
Hoch
Contender
Hoch Contender
Alemania
Aun si el diseador ha especificado la clave principal como {Nombre completo del modelo}, la tabla no est en 2NF. {Fabricante, Modelo} es tambin una clave candidata, y Pas del fabricante es dependiente en un subconjunto apropiado de l: Fabricante.
Referencias[editar editar cdigo]

1. Jump up Codd, E.F. "Further Normalization of the Data Base Relational Model." (Presented at Courant Computer Science Symposia Series 6, "Data Base Systems," New York City, May 24th25th, 1971.) IBM Research Report RJ909 (August 31st, 1971). Republished in Randall J. Rustin (ed.), Data Base Systems: Courant Computer Science Symposia Series 6. Prentice-Hall, 1972.
Lectura adicional[editar editar cdigo]

Litt's Tips: Normalization Rules Of Data Normalization Date, C. J., & Lorentzos, N., & Darwen, H. (2002). Temporal Data & the Relational Model (1st ed.). Morgan Kaufmann. ISBN 1-55860-855-9.
Date, C. J. (1999), An Introduction to Database Systems (8th ed.). Addison-Wesley Longman. ISBN 0-321-19784-4.
Kent, W. (1983) A Simple Guide to Five Normal Forms in Relational Database Theory, Communications of the ACM, vol. 26, pp. 120-125
Date, C.J., & Darwen, H., & Pascal, F. Database Debunkings
1NF - 3NF - BCNF - 4NF - 5NF - DKNF - Denormalizacin
Tercera forma normal

La tercera forma normal (3NF) es una forma normal usada en la normalizacin de bases de datos. La 3NF fue definida originalmente por E.F. Codd1 en 1971. La definicin de Codd indica que una tabla est en 3NF si y solo si las dos condiciones siguientes se cumplen:
La tabla est en la segunda forma normal (2NF) Ningn atributo no-primario de la tabla es dependiente transitivamente de una clave primaria
Un atributo no-primario es un atributo que no pertenece a ninguna clave candidata. Una dependencia transitiva es una dependencia funcional X Z en la cual Z no es inmediatamente dependiente de X, pero s de un tercer conjunto de atributos Y, que a su vez depende de X. Es decir, X Z por virtud de X Y e Y Z. Una formulacin alternativa de la definicin de Codd, dada por Carlo Zaniolo2 en 1982, es sta: Una tabla est en 3NF si y solo si, para cada una de sus dependencias funcionales X A, por lo menos una de las condiciones siguientes se mantiene:
X contiene A, X es una superclave, A es un atributo primario (es decir, A est contenido dentro de una clave candidata)
La definicin de Zaniolo tiene la ventaja de dar un claro sentido de la diferencia entre la 3NF y la ms rigurosa forma normal de Boyce-Codd (BCNF). La BCNF simplemente elimina la tercera alternativa ("A es un atributo primario").
ndice
[ocultar]
1 "Nada excepto la clave" 2 Ejemplo 3 Derivacin de las condiciones de Zambruno 4 Normalizacin ms all de la 3NF 5 Referencias 6 Lectura adicional 7 Vase tambin 8 Enlaces externos
"Nada excepto la clave"[editar editar cdigo]

Un memorable resumen de la definicin de Codd de la 3NF, siendo paralelo al compromiso tradicional de dar evidencia verdadera en un tribunal de justicia, fue dado por Bill Kent: cada atributo no-clave "debe proporcionar un hecho sobre la clave, la clave entera, y nada ms excepto la clave".3 Una variacin comn complementa esta definicin con el juramento: "con la ayuda de Codd".4 Requerir que los atributos no-clave sean dependientes en "la clave completa" asegura que una tabla est en 2NF; un requerimiento posterior que los atributos no-clave sean dependientes de "nada excepto la clave" asegura que la tabla est en 3NF. Chris Date refiere al resumen de Kent como "una intuitiva atractiva caracterizacin" de la 3NF, y observa que con una ligera adaptacin puede servir como definicin ligeramente ms fuerte de laforma normal de Boyce-Codd: "Cada atributo debe representar un hecho acerca de la clave, la clave entera, y nada excepto la clave".5 La versin 3NF de la definicin es ms dbil que la variacin de BCNF de Date, pues el anterior se refiere solamente a asegurarse de que los atributos no-clave son dependientes en las claves. Los atributos primarios (que son claves o partes de claves) no deben ser funcionalmente dependientes en absoluto; cada uno de ellos representa un hecho sobre la clave en el sentido de proporcionar parte o toda la clave en s misma. Debe ser observado que esta regla se aplica solamente a los atributos funcionalmente dependientes, Ya que aplicndola a todos los atributos prohibira implcitamente claves de candidato compuestas, puesto que cada parte de cualquiera de tales claves violara la clusula de "clave completa"..

Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:
Torneo
Ao
Ganador
Fecha de nacimiento del ganador
Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975
Cleveland Open
1999 Bob Albertson 28 de septiembre de 1968
Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975
Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977
La nica clave candidata es {Torneo, Ao}. La violacin de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del ganador es dependiente transitivamente de {Torneo, Ao} va el atributo no primario Ganador. El hecho de que la Fecha de nacimiento del ganador es funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias lgicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas de nacimiento en diversos registros. Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:
Torneo
Ao
Ganador
Indiana Invitational 1998 Al Fredrickson
Cleveland Open
1999 Bob Albertson
Des Moines Masters 1999 Al Fredrickson
Indiana Invitational 1999 Chip Masterson
Fecha de nacimiento del jugador
Ganador
Fecha de nacimiento
Chip Masterson 14 de marzo de 1977
Al Fredrickson 21 de julio de 1975
Bob Albertson 28 de septiembre de 1968
Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales estn en 3NF.
Derivacin de las condiciones de Zambruno[editar editar cdigo]

La definicin de 3NF ofrecida por Carlo Zaniolo en 1982, y dada arriba, es probada as: Sea X A un FD no trivial (es decir, uno donde X no contiene a A) y sea A un atributo no clave. Tambin sea Y una clave de R. Entonces Y X. Por lo tanto A no es dependiente transitivo de Y, si y solo si el X Y, es decir, si y solo si X es una superclave.6
Normalizacin ms all de la 3NF[editar editar cdigo]

La mayora de las tablas 3NF estn libres anomalas de actualizacin, insercin, y borrado. Ciertos tipos de tablas 3NF, que en la prctica raramente se encuentran, son afectadas por tales anomalas; stas son tablas que no satisfacen la forma normal de Boyce-Codd (BCNF) o, si satisfacen la BCNF, son insuficientes para satisfacer las formas normales ms altas 4NF o 5NF.
Referencias[editar editar cdigo]

1. Jump up Codd, E.F. "Further Normalization of the Data Base Relational Model." (Presented at Courant Computer Science Symposia Series 6, "Data Base Systems," New York City, May 24th25th, 1971.) IBM Research Report RJ909 (August 31st, 1971). Republished in Randall J. Rustin (ed.), Data Base Systems: Courant Computer Science Symposia Series 6. Prentice-Hall, 1972. 2. Jump up Zaniolo, Carlo. "A New Normal Form for the Design of Relational Database Schemata." ACM Transactions on Database Systems 7(3), September 1982. 3. Jump up Kent, William. "A Simple Guide to Five Normal Forms in Relational Database Theory", Communications of the ACM 26 (2), Feb. 1983, pp. 120-125. 4. Jump up The author of a 1989 book on database management credits one of his students with coming up with the "so help me Codd" addendum. Diehr, George. Database Management (Scott, Foresman, 1989), p. 331. 5. Jump up Date, C.J. An Introduction to Database Systems (7th ed.) (Addison Wesley, 2000), p. 379. 6. Jump up Zaniolo, p. 494.
Lectura adicional[editar editar cdigo]
Date, C. J. (1999), An Introduction to Database Systems (8th ed.). Addison-Wesley Longman. ISBN 0-321-19784-4.
Kent, W. (1983) A Simple Guide to Five Normal Forms in Relational Database Theory, Communications of the ACM, vol. 26, pp. 120-125
1NF - 2NF - 3NF - BCNF - 4NF - 5NF - DKNF - Denormalizacin
Enlaces externos
Cuarta forma normal

La cuarta forma normal (4NF) es una forma normal usada en la normalizacin de bases de datos. La 4NF se asegura de que las dependencias multivaluadas independientes estn correctas y eficientemente representadas en un diseo de base de datos. La 4NF es el siguiente nivel de normalizacin despus de la forma normal de Boyce-Codd (BCNF).
ndice
[ocultar]
1 Caractersticas 2 Dependencia multivaluada 3 Ejemplo 4 4NF en la prctica 5 Referencias 6 Vase tambin
Caractersticas[editar editar cdigo]

Una tabla est en 4NF si y solo si esta en Tercera forma normal o en BCNF (Cualquiera de ambas) y no posee dependencias multivaluadas no triviales. La definicin de la 4NF confa en la nocin de una dependencia multivaluada. Una tabla con una dependencia multivaluada es una donde la existencia de dos o ms relaciones independientes muchos a muchos causa redundancia; y es esta redundancia la que es suprimida por la cuarta forma normal.
Dependencia multivaluada[editar editar cdigo]

Sea R un esquema de relacin. La dependencia multivaluada X ->> Y vale en R si los pares de tuplas t1 y t2 en R, tal que t1[X] = t2[X] existen las tuplas t3 y t4 en R tales que: t1[X] = t2[X] = t3[X] = t4[X] t3[Y] = t1[Y] t3[R-X-Y] = t2[R-X-Y] t4[Y] = t2[Y] t4[R-X-Y] = t1[R-X-Y] En otras palabras se puede decir que: X ->> Y si dado un valor de X, hay un conjunto de valores de Y asociados y este conjunto de valores de Y NO est relacionado (ni funcional ni multifuncionalmente) con
los valores de R - X -Y (donde R es el esquema), es decir Y es independiente de los atributos de R-X-Y. (Ctedra de Base de Datos 1, 2009) Una dependencia multivaluada de la forma X->> Y, es trivial cuando el conjunto de atributos {X,Y} conforma el total de los atributos del esquema.

Considere el siguiente ejemplo:
Permutaciones de envos de pizzas
Restaurante
Variedad de Pizza rea de envo
Vincenzo's Pizza Corteza gruesa
Springfield
Shelbyville
Vincenzo's Pizza Corteza fina
Springfield
Shelbyville
Elite Pizza
Corteza fina
Capital City
Elite Pizza
Corteza rellena
Capital City
A1 Pizza
Corteza gruesa
Springfield
A1 Pizza
Corteza gruesa
Shelbyville
A1 Pizza
Corteza gruesa
Capital City
A1 Pizza
Corteza rellena
Springfield
A1 Pizza
Corteza rellena
Shelbyville
A1 Pizza
Corteza rellena
Capital City
Cada fila indica que un restaurante dado puede entregar una variedad dada de pizza a un rea dada. Note que debido a que la tabla tiene una clave nica y ningn atributo no-clave, no viola ninguna forma normal hasta el BCNF. Pero debido a que las variedades de pizza que un restaurante ofrece son independientes de las reas a las cuales el restaurante enva, hay redundancia en la tabla: por ejemplo, nos dicen tres veces que A1 Pizza ofrece la Corteza rellena, y si A1 Pizza comienza a producir pizzas de Corteza de queso entonces necesitaremos agregar mltiples registros, uno para cada una de las reas de envo de A1 Pizza. En trminos formales, esto se describe como que Variedad de pizza est teniendo una dependencia multivalor en Restaurante. Para satisfacer la 4NF, debemos poner los hechos sobre las variedades de pizza ofrecidas en una tabla diferente de los hechos sobre reas de envo:
Variedades por restaurante
reas de envo por restaurante
Restaurante
Variedad de pizza
Restaurante
rea de envo
Vincenzo's Pizza Springfield
Vincenzo's Pizza Shelbyville
Elite Pizza
Corteza fina
Elite Pizza
Capital City
Elite Pizza
Corteza rellena
A1 Pizza
Springfield
A1 Pizza
Corteza gruesa
A1 Pizza
Shelbyville
A1 Pizza
Corteza rellena
A1 Pizza
Capital City
En contraste, si las variedades de pizza ofrecidas por un restaurante a veces variaran de un rea de envo a otra, la tabla original de la tres columnas satisfara la 4NF.
Ronald Fagin demostr que es siempre posible alcanzar la 4NF (pero no siempre deseable). El teorema de Rissanen es tambin aplicable en dependencias multivalor.
4NF en la prctica[editar editar cdigo]

Un artculo de 1992 de Margaret S. Wu observa que la enseanza de la normalizacin de la base de datos se detiene tpicamente justo antes de la 4NF, quizs debido a una creencia que las tablas que violan la 4NF (pero que hacen frente a todas las formas normales ms bajas) son raramente encontradas en aplicaciones empresariales. Sin embargo, esta creencia puede no ser exacta. Wu reporta que en un estudio de cuarenta bases de datos de organizaciones, ms del 20% contena una o ms tablas que violaban la 4NF mientras que satisfacen todas las formas normales ms bajas. 1
Comandos del DDL y del DML

Comandos DLL Comando CREATE DROP ALTER Descripcin Utilizado para crear nuevas tablas, stored procedures e ndices Empleado para eliminar tablas, stored procedures e ndices Utilizado para modificar las tablas agregando campos o cambiando la definicin de los campos
Comandos DML Comando SELECT INSERT DELETE UPDATE Anterior Descripcin Utilizado para consultar registros de la base de datos que satisfagan un criterio determinado. Utilizado para cargar lotes de datos en la base de datos en una nica operacin. Utilizado para modificar los valores de los campos y registros especificados. Utilizado para eliminar registros de una tabla de una base de datos. Inicio Siguiente
DDL y DML
Lenguaje de definicin de datos (DDL: Data Definition Language):Sencillo lenguaje artificial para definir y describir los objetos de la base de datos, su estructura, relaciones y restricciones. En la prctica puede consistir en un subconjunto de instrucciones de otro lenguaje informtico. Aparte suele poseer dos subconjuntos de instrucciones:
Lenguaje de definicin del almacenamiento de los datos (DSDL: Data Storage Definition Language): permite especificar caractersticas fsicas de la base de datos (volmenes y archivos donde van a ser almacenados los datos, etc). Lenguaje de control de datos (DCL: Data Control Language): encargado del control y seguridad de los datos (privilegios y modos de acceso, etc).
Lenguaje de manipulacin de datos (DML: Data Manipulation Language): Lenguaje artificial de cierta complejidad que permite el manejo y procesamiento del contenido de la base de datos. En la prctica puede consistir en un subconjunto de instrucciones de otro lenguaje informtico. Las aplicaciones que trabajan sobre la base de datos se programan en un lenguaje de programacin (C, Cobol, ...) insertando en el cdigo fuente sentencias del DML. Al utilizar un DML se deben especificar los datos que sern afectados por las sentencias del lenguaje. Un DML
puede tener o no procedimientos, segn sea necesario especificar ademns cnmo deben obtenerse esos datos. Los DML con procedimientos tienen sentencias de control de flujo como bucles o condicionales. Los DML sin procedimientos son conocidos tambin como declarativos. Anterior Inicio Siguiente

BD

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

BD

Încărcat de

Drepturi de autor:

Formate disponibile

Resultado del proceso de diseo fsico de una base de datos.

Nombres de calles de Espaa

1.1 Esquema 1.2 Instancias

2 Base de datos relacional 3 Vase tambin

Descripcin[editar editar cdigo]

Esquema[editar editar cdigo]

Instancias[editar editar cdigo]

Base de datos relacional[editar editar cdigo]

Vase tambin[editar editar cdigo]

3.2 Por qu "modelo relacional" ?

3.3 Conceptos bsicos

Mighty Ducks 1991 Wayne's World 1992

3.3.6 Representaciones equivalentes de una relacin

Mighty Ducks color Wayne's World Star Wars color color

Otra representacin de la relacin Pelculas

3.4 Conversin del modelo e-r a un esquema de

base de datos (Conversin a tablas)

3.4.2 Conversin a tablas desde un modelo con relaciones (11,1-m,m-m)

modelo e-r conversin a tablas

El diagrama anterior se convertira al siguiente esquema: Debil

donde: LLP_X es la llave primaria de la entidad X (un subconjunto de atribs_X)

Para el ejemplo de la figura tendramos el esquema:

3.4.3 Conversin a tablas desde un modelo con generalizacin

modelo e-r de generalizacin a tablas dos posibilidades:

La generalizacin se convertira al siguiente esquema: 1) A

donde: LLP_X es la llave primaria de la entidad X (un subconjunto de atribs_X)

donde: LLP_X es la llave primaria de la entidad X (un subconjunto de atribs_X)

3.4.4 Descubrimiento de llaves en las relaciones

Mighty Ducks 1991 Wayne's World Wayne's World 1992 1992

3.5.1 Dependencias funcionales (FD)

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

3.5.1.2 Axiomas de Armstrong:

Reflexividad: sea >

un conjunto de atributos y --> --> y y

Aumentacin: si > Transitividad: si

Si ningn elemento de pertenece a completamente no trivial

entonces se considera una dependencia

3.5.1.3 Reglas adicionales

--> --> -->

--> --> --> y --> --> entonces

3.5.1.4 Cerradura de un conjunto de atributos

+, todos los atributos que

(es decir, si pertenece a F+)

3.5.2 Primera forma normal

3.5.3 Segunda forma normal

NO se encuentra en 2a NF ya que { id,clave,depto} --> descripcin {clave,depto} --> descripcin

La descomposicin se basa bsicamente en:

La intuicin Las dependencias funcionales

Es importante que al descomponer una relacin exista:

Descomposicin sin prdida Preservacin de dependencias funcionales

3.5.4 Descomposicin sin prdida

Para el ejemplo anterior la relacin

R2 = depto,clave_curso donde depto,clave_curso -->descripcin

y {depto,clave_curso -->descripcin} { { id,clave,depto} --> id,clave,depto,descripcin,calificacin, {clave,depto} --> descripcin }

3.5.5 Preservacin de dependencias

De manera que F' = F1

3.5.6 Forma normal de Boyce-Codd (BCNF)

Un esquema relacional se encuentra en BCNF si para toda dependencia funcional X --> A:

X --> A es una dependencia funcional trivial

X es una super llave

BCNF no necesariamente preserva las dependencias funcionales F'+ != F+

3.5.6.2 Algoritmo general de descomposicin tratando de alcanzar BCNF

Ejemplo: R(A,B,C,D) B--> C