Fundamentos de Bases de Datos UNIDAD IV - Copiasi

FUNDAMENTOS BASES DE DATOS

DATOS DE LA ASIGNATURA

Nombre de la asignatura:

Carrera:

Clave de la asignatura:

Horas teora-horas prctica-crditosFundamentos de bases de datos

Ingeniera en tecnologas de la informacinAEF - 10313-2-5

1UNIDAD 4. DISEO DE BASES DE DATOS RELACIONALES

24.1CARACTERISTICAS DEL DISEO RELACIONAL.

44.2DOMINIOS ATMICOS Y LA PRIMERA FORMA NORMAL.

84.3DEPENDENCIAS FUNCIONALES.

94.4SEGUNDA FORMA NORMAL

114.5TERCERA FORMA NORMAL

134.6FORMA NORMAL DE BOYCE-CODD.

144.7ALGORITMOS DE DESCOMPOSICIN

144.8FORMAS NORMALES SUPERIORES

174.9INTEGRIDAD DE LAS BASES DE DATOS

UNIDAD 4. DISEO DE BASES DE DATOS RELACIONALES

Competencia especfica a desarrollarActividades de Aprendizaje

Aplicar la normalizacin al diseo de los esquemas de la base de datos. Sintetizar las caractersticas del diseo relacional por equipo.

Resolver problemas de normalizacin de bases de datos partiendo de los esquemas generados con el diagrama relacional.

Elaborar la normalizacin de datos del proyecto de curso.

Una base de datos relacional es una base de datos que cumple con el modelo relacional, el cual es el modelo ms utilizado en la actualidad para implementar bases de datos ya planificadas. Permiten establecer interconexiones (relaciones) entre los datos (que estn guardados en tablas), y a travs de dichas conexiones relacionar los datos de ambas tablas, de ah proviene su nombre: "Modelo Relacional". 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.El objetivo del diseo de las bases de datos relacionales es la generacin de un conjunto de esquemas relacionales que nos permita almacenar la informacin sin redundancias innecesarias, pero que tambin nos permita recuperar fcilmente esa informacin. Un enfoque es el diseo de esquemas que se hallen en una forma normal adecuada. Para determinar si el esquema de una relacin se halla en una de las formas normales deseables hace falta informacin adicional sobre la empresa real que se est modelando con la base de datos.

TERMINOLOGA RELACIONAL EQUIVALENTE

Figura 4.1: Trabajo (Cdigo, Nombre, Posicin, Salario), donde Cdigo es la Clave Primaria

Relacin = tabla o archivo.

Tupla = registro, fila o rengln.

Atributo = campo o columna.

Clave = llave o cdigo de identificacin.

Clave Primaria = superclave.

Clave Ajena = clave externa o clave fornea.

Clave Alternativa = clave secundaria.

Dependencia Multivaluada = dependencia multivalor.

RDBMS = Del ingls Relational Data Base Manager System que significa, Sistema Gestor de Bases de Datos Relacionales. 1FN = Significa, Primera Forma Normal o 1NF del ingles First Normal Form.Los trminos Relacin, Tupla y Atributo derivan de las matemticas relacionales, que constituyen la fuente terica del modelo de base de datos relacional.

4.1 CARACTERISTICAS DEL DISEO RELACIONAL. Una base de datos relacional se compone de varias tablas o relaciones.

No pueden existir dos tablas con el mismo nombre ni registro.

Cada tabla es a su vez un conjunto de registros (filas y columnas).

La relacin entre una tabla padre y un hijo se lleva a cabo por medio de las claves primarias y ajenas (o forneas).

Las claves primarias son la clave principal de un registro dentro de una tabla y stas deben cumplir con la integridad de datos.

Las claves ajenas se colocan en la tabla hija, contienen el mismo valor que la clave primaria del registro padre; por medio de stas se hacen las relaciones.

Las normas definen las interfaces de los sistemas de software; por ejemplo, las normas definen la sintaxis y la semntica de los lenguajes de programacin o las funciones en la interfaz de los programas de aplicaciones o, incluso, los modelos de datos (como las normas de las bases de datos orientadas a los objetos). Hoy en da los sistemas de bases de datos son complejos y suelen estar constituidos por varias partes creadas de manera independiente que deben interactuar entre s. Por ejemplo, puede que los programas clientes se creen de manera independiente de los sistemas dorsales, pero todos ellos deben poder interactuar entre s. Puede que una empresa que tenga varios sistemas de bases de datos heterogneos necesite intercambiar datos entre las bases de datos. En una situacin de este tipo las normas desempean un papel importante.

Las normas formales son las que han sido desarrolladas por una organizacin de normalizacin o por grupos de empresas mediante un procedimiento pblico. Los productos dominantes se convierten a veces en una norma de facto, en el sentido de que resultan aceptados de manera general como normas sin necesidad de ningn procedimiento formal de reconocimiento. Algunas normas formales, como muchos aspectos de las normas SQL-92 y SQL:1999, son normas anticipativas que lideran el mercado; definen las caractersticas que los fabricantes implementan posteriormente en los productos. En otros casos, las normas, o partes de las normas, son normas reaccionarias, en el sentido de que intentan normalizar las caractersticas que ya han implementado algunos fabricantes, y que pueden haberse convertido, incluso, en normas de facto. SQL-89 era, en muchos sentidos, reaccionario, dado que estandarizaba caractersticas, como la comprobacin de la integridad, que ya estaban presentes en la norma SAASQL de IBM y en otras bases de datos.

Los comits para las normas formales suelen estar compuestos por representantes de los fabricantes y por miembros de grupos de usuarios y de organizaciones de normalizacin como la Organizacin internacional de normalizacin (International Organization for Standardization, ISO) o el Instituto nacional americano de normalizacin (American National Standards Institute, ANSI) o de organismos profesionales como el Instituto de ingenieros elctricos y electrnicos (Institute of Electrical and Electronics Engineers, IEEE). Los comits para las normas formales se renen de manera peridica y sus componentes presentan propuestas de caractersticas de la norma que hay que aadir o modificar. Tras un periodo de discusin (generalmente amplio), de modificaciones de la propuesta y de examen pblico, los integrantes de los comits votan la aceptacin o el rechazo de las caractersticas. Cierto tiempo despus de la definicin e implementacin de una norma quedan claras sus carencias y aparecen nuevas necesidades. El proceso de actualizacin de la norma comienza entonces y tras unos cuantos aos suele publicarse una nueva versin de la misma. Este ciclo suele repetirse cada pocos aos hasta que finalmente (quizs muchos aos ms tarde) la norma se vuelve tecnolgicamente irrelevante o pierde su base de usuarios. La norma CODASYL de DBTG para bases de datos en red, formulada por el Grupo de trabajo para bases de datos (Database Task Group, DBTG), fue una de las primeras normas formales en este campo. Los productos de bases de datos de IBM solan establecer las normas de facto, dado que IBM ocupaba gran parte de este mercado. Con el crecimiento de las bases de datos relacionales aparecieron nuevos competidores en el negocio de las bases de datos; por tanto, surgi la necesidad de normas formales. En los ltimos aos Microsoft ha creado varias especificaciones que tambin se han convertido en normas de facto. Un ejemplo destacable es ODBC, que se utiliza actualmente en entornos que no son de Microsoft. JDBC, cuya especificacin fue creada por Sun Microsystems, es otra norma de facto muy utilizada.

Objetivos de la normalizacin

Una vez creadas las tablas hay que verificarlas y revisar si an se puede reducir u optimizar de alguna manera.

El proceso de normalizacin de una base de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo E-R (entidad-relacin) al modelo relacional.

Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos.

Evitar problemas de actualizacin de los datos en las tablas.

Proteger la integridad de los datos.

Entre las ventajas de utilizar la normalizacin estn:

Garantiza herramientas para evitar la duplicidad de registros, a travs de campos claves o llaves.

Garantiza la integridad referencial: as al eliminar un registro elimina todos los registros relacionados dependientes.

Favorece la normalizacin por ser ms comprensible y aplicable.

En el modelo relacional es frecuente llamar tabla a una relacin, aunque para que una tabla bidimensional sea considerada como una relacin tiene que cumplir con algunas restricciones:

Cada columna debe tener su nombre nico.

No puede haber dos filas iguales. No se permiten los duplicados.

Todos los datos en una columna deben ser del mismo tipo.

4.2 DOMINIOS ATMICOS Y LA PRIMERA FORMA NORMAL.Las primeras tres formas normales son suficientes para cubrir las necesidades de la mayora de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd, ste introdujo la normalizacin en un artculo llamado A Relational Model of Data for Large Shared Data Banks Communications of the ACM, Vol. 13, No. 6, June 1970, pp. 377387[1].

Definicin formal: Una relacin R se encuentra en 1FN si y solo s por cada rengln columna contiene valores atmicos.

Un dominio es atmico si se considera que los elementos del dominio son unidades indivisibles. Se dice que el esquema de una relacin R est en la primera forma normal (1FN) si los dominios de todos los atributos de R son atmicos

Abreviada como 1FN, se considera que una relacin se encuentra en la primera forma normal cuando cumple lo siguiente:

1. Las celdas de las tablas poseen valores simples y no se permiten grupos ni arreglos repetidos como valores, es decir, contienen un solo valor por cada celda.

2. Todos los ingresos en cualquier columna (atributo) deben ser del mismo tipo.

3. Cada columna debe tener un nombre nico, el orden de las columnas en la tabla no es importante.

4. Dos filas o renglones de una misma tabla no deben ser idnticas, aunque el orden de las filas no es importante.

Por lo general la mayora de las relaciones cumplen con estas caractersticas, as que podemos decir que la mayora de las relaciones se encuentran en la primera forma normal.

Una tabla est en 1FN si el valor que contiene un atributo de un registro, un campo, es nico y elemental. En cada uno de los atributos slo se puede incluir un dato, aunque sea compuesto, pero no se pueden incluir una lista de datos. Por ejemplo, no se pueden incluir en el atributo Direccin el domicilio habitual y el de vacaciones; habra que crear dos registros que se diferenciarn por el atributo Direccin.Las tablas 1FN como representaciones de relaciones

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

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. 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

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 1NF.

Ejemplo 1: Dominios y valores

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 ClienteNombreApellidoTelfono

123RachelIngram555-861-2025

456JamesWright555-403-1659

789CesarDure555-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



456JamesWright555-403-1659555-776-4100

789CesarDure555-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

El diseador puede evitar esta restriccin definiendo mltiples columnas del nmero telefnico:Cliente

ID ClienteNombreApellidoTelfono 1Telfono 2Telfono 3


456JamesWright555-403-1659555-776-4100

789CesarDure555-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-a-Telfono 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

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



456JamesWright555-403-1659, 555-776-4100

789CesarDure555-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

Un diseo que est inequvocamente en 1FN hace uso de dos tablas: una tabla de cliente y una tabla de telfono del cliente.Cliente

ID ClienteNombreApellido

123RachelIngram

456JamesWright

789CesarDure

Telfono del cliente

ID ClienteTelfono

123555-861-2025

456555-403-1659

456555-776-4100

789555-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

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". Codd define un valor atmico como uno que "no puede ser descompuesto en pedazos ms pequeos por el DBMS (excepto ciertas funciones especiales)".

[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. 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": 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.

Normalizacin ms all de la 1NF

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 subscriptorDireccin de correoPrimer nombre del subscriptorApellido del subscriptor

[email protected]

[email protected]

[email protected]

[email protected]

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.

4.3 DEPENDENCIAS FUNCIONALES.

B es funcionalmente dependiente de A.

Una dependencia funcional es un tipo de restriccin que constituye una generalizacin del concepto de clave.

Una dependencia funcional son conexiones entre uno o ms atributos. Por ejemplo si conocemos el valor de Fecha De Nacimiento podemos conocer el valor de Edad.Las dependencias funcionales se escriben utilizando una flecha, de la siguiente manera:FechaDeNacimiento -> Edad

Aqu a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de FechaDeNacimiento. De la normalizacin (lgica) a la implementacin (fsica o real) puede ser sugerible tener stas dependencias funcionales para lograr mayor eficiencia en las tablas.

Propiedades de la Dependencia funcional

Existen 3 axiomas de Armstong:

1. Dependencia funcional Reflexiva

Si y esta incluido en x entonces x->y

Si la direccin o el nombre de una persona estn incluidos en el dni, entonces con el dni podemos determinar la direccin o su nombre.

2. Dependencia funcional Aumentativa

x->y entonces xz->yz

dni -> nombre

dni,direccin -> nombre,direccin

Si con el dni se determina el nombre de una persona, entonces con el dni ms la direccin tambin se determina el nombre o su direccin.

3. Dependencia funcional transitiva

Dependencia funcional transitiva.

FechaDeNacimiento -> Edad

Edad -> Conducir

FechaDeNacimiento -> Edad -> Conducir

Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad determina a Conducir, indirectamente podemos saber a travs de FechaDeNacimiento a Conducir (En muchos pases, para una persona poder conducir un automvil la persona necesita ser mayor de X edad, por eso se utiliza este ejemplo).

4.4 SEGUNDA FORMA NORMALSegunda 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. Codd 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 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 una clave 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.

Ejemplo

Considere una tabla describiendo las habilidades de los empleados:Habilidades de los empleados

EmpleadoHabilidadLugar actual de trabajo

JonesMecanografa114 Main Street

JonesTaquigrafa114 Main Street

JonesTallado114 Main Street

BravoLimpieza ligera73 Industrial Way

EllisAlquimia73 Industrial Way

EllisMalabarismo73 Industrial Way

HarrisonLimpieza ligera73 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

EmpleadoLugar actual de trabajo

Jones114 Main Street

Bravo73 Industrial Way

Ellis73 Industrial Way

Harrison73 Industrial Way

Habilidades de los empleados

EmpleadoHabilidad

JonesMecanografa

JonesTaquigrafa

JonesTallado

BravoLimpieza ligera

EllisAlquimia

EllisMalabarismo

HarrisonLimpieza 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

TorneoAoGanadorFecha de nacimiento del ganador

Des Moines Masters1998Chip Masterson14 de marzo de 1977

Indiana Invitational1998Al Fredrickson21 de julio de 1975

Cleveland Open1999Bob Albertson28 de septiembre de 1968

Des Moines Masters1999Al Fredrickson21 de julio de 1975

Indiana Invitational1999Chip Masterson14 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

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

FabricanteModeloNombre completo del modeloPas del fabricante

ForteX-PrimeForte X-PrimeItalia

ForteUltracleanForte UltracleanItalia

Dent-o-FreshEZBrushDent-o-Fresh EZBrushUSA

KobayashiST-60Kobayashi ST-60Japn

HochToothmasterHoch ToothmasterAlemania

HochContenderHoch ContenderAlemania

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.

4.5 TERCERA FORMA NORMALLa tercera forma normal (3NF) es una forma normal usada en la normalizacin de bases de datos. La 3NF fue definida originalmente por E.F. Codd en 1971. La definicin de Codd indica que una tabla est en 3NF si y solo si las dos condiciones siguientes se mantienen:

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 Zaniolo[2] 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")."Nada excepto la clave"

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". Una variacin comn complementa esta definicin con el juramento: "con la ayuda de Codd".

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 la forma 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"..

Ejemplo

Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:Ganadores del torneo

TorneoAoGanadorFecha de nacimiento del ganador

Indiana Invitational1998Al Fredrickson21 de julio de 1975

Cleveland Open1999Bob Albertson28 de septiembre de 1968

Des Moines Masters1999Al Fredrickson21 de julio de 1975

Indiana Invitational1999Chip Masterson14 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:Ganadores del torneo

TorneoAoGanador

Indiana Invitational1998Al Fredrickson

Cleveland Open1999Bob Albertson

Des Moines Masters1999Al Fredrickson

Indiana Invitational1999Chip Masterson

Fecha de nacimiento del jugador

JugadorFecha de nacimiento

Chip Masterson14 de marzo de 1977

Al Fredrickson21 de julio de 1975

Bob Albertson28 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

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. Normalizacin ms all de la 3NF

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.

4.6 FORMA NORMAL DE BOYCE-CODD.La Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en la normalizacin de bases de datos. Es una versin ligeramente ms fuerte de la Tercera forma normal (3FN). La forma normal de Boyce-Codd requiere que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave candidata. En una tabla en 3FN, todos los atributos dependen de una clave, de la clave completa y de ninguna otra cosa excepto de la clave (excluyendo dependencias triviales, como ). Se dice que una tabla est en FNBC si y solo si est en 3FN y cada dependencia funcional no trivial tiene una clave candidata como determinante. En terminos menos formales, una tabla est en FNBC si est en 3FN y los nicos determinantes son claves candidatas.Ejemplo

Consideremos una empresa donde un trabajador puede trabajar en varios departamentos. En cada departamento hay varios responsables, pero cada trabajador slo tiene asignado uno. Tendramos una tabla con las columnas:IDTrabajador, IDDepartamento, IDResponsableLa nica clave candidata es IDTrabajador (que ser por tanto la clave primaria).

Si aadimos la limitacin de que el responsable slo puede serlo de un departamento, este detalle produce una dependencia funcional ya que: Responsable DepartamentoPor lo tanto hemos encontrado un determinante (IDResponsable) que sin embargo no es clave candidata. Por ello, esta tabla no est en FNBC. En este caso la redundancia ocurre por mala seleccin de clave. La repeticin del par [IDDepartamento + IDResponsable] es innecesaria y evitable.

Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la FNBC. Un ejemplo de tal tabla es (teniendo en cuenta que cada estudiante puede tener ms de un tutor):Referencia cruzada de Tutor/Estudiante

ID TutorNmero de seguro social del tutorID Estudiante

1078088-51-007431850

1078088-51-007437921

1293096-77-414646224

1480072-21-222331850

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

{ID Tutor, ID Estudiante}

{Nmero de seguro social del tutor, ID Estudiante}

Otra formulacin

Una forma sencilla de comprobar si una relacin se encuentra en FNBC consiste en comprobar, adems de que est en 3FN, lo siguiente:

(1) Si no existen claves candidatas compuestas (con varios atributos), est en FNBC.

(2) Si existen varias claves candidatas compuestas y stas tienen un elemento comn, no est en FNBC.

En la tabla de ejemplo anterior existen dos claves candidatas y ambas comparten el atributo ID Estudiante, por lo tanto no est en FNBC

4.7 ALGORITMOS DE DESCOMPOSICINLa palabra algoritmo se deriva del latn (algorithm). Que se refiere al conjunto finito de instrucciones para llevar a cabo una tarea. El cual es simplemente la manera de resolver un problema. Y cuya descomposicin consiste en dividir el problema en subproblemas ms simples, con el fin de encontrar una solucin.

Veamos el siguiente ejemplo para entenderlo mejor.

Ejemplo de descomposicin en FNBC

Dada una dependencia

R = (nombre-sucursal, ciudad-sucursal, activos, nombre-cliente, numero-prestamo, cantidad)

F = {nombre-sucursal, activos, ciudad-sucursal, numero-prestamo, cantidad, nombre-sucursal}

Clave = {numero-prestamo, nombre-cliente}

Descomposicin

R1 = (nombre-sucursal, ciudad-sucursal, activos)

R2 = (nombre-sucursal, nombre-cliente, numero-prstamo, cantidad)

R3 = (nombre-sucursal, numero-prstamo, cantidad)

R4 = (nombre-cliente, numero-prstamo)

Descomposicin final

R1, R3, R4

R=(Esquema de relacin)

F=(Dependencia funcional)

4.8 FORMAS NORMALES SUPERIORESCuarta Forma Normal (4FN)

Est en forma normal de Boyce-Codd y se eliminan las dependencias multivaluadas y se generan todas las relaciones externas con otras tablas u otras bases de datos.

Existe dependencia funcional multivalorada o de mltiples valores si, dados tres atributos de una tabla, si para cada valor del primer atributo existen mltiples valores en el segundo atributo y no hay ninguna relacin entre el tercer atributo y el primero, a no ser a travs del segundo atributo.

Una tabla est en Cuarta Forma Normal o 4FN si est en FNBC y las nicas dependencias funcionales multivaloradas que existen son las dependencias funcionales de la clave con los atributos que no forman parte de la misma. Estas dependencias multievaluadas de la clave con los atributos que no forman parte de la misma son dependencias triviales, por lo que algunos autores dicen que no existen dependencias multievaluadas en 4FN.

Supongamos que los atributos de la tabla transporte son conductor, tipo de vehculo y tipo de carga, formando los tres campos la clave primaria. A cada conductor se le puede asignar un vehculo u otro y cada vehculo puede transportar varios tipos de carga.

Tabla que no esta en cuarta forma normal

Transporte

ConductorTipo VehculoTipo Carga

JuanFurgonetaPerecederos

MarcosFurgonetaPerecederos

JuanFurgonetaMuebles

MarcosFurgonetaMuebles

JuanCaminMudanza

MarcosCaminMudanza

Con estas condiciones, los conductores son independientes de la carga; el tipo de vehculos depende del conductor y el tipo de vehculo depende de la carga. En este caso hay dependencias funcionales multivaloradas, ya que algunos atributos que forman la clave dependen de otro atributo que tambin la forman.

Para conseguir que esta tabla est en 4FN se necesita crear dos nuevas tablas en lugar de la tabla actual, mantenindose en cada una de ellas una dependencia mltiple. La primera tabla tendr los atributos conductor y tipo de vehculo y la segunda, tipo de vehculo y tipo de carga. De este modo la tabla esta en 4FN debido a que la clave primaria de ambas tablas son todos los campos que la forman. Resultado:

Tabla en cuarta forma normal

ConductorTipo Vehculo

JuanFurgoneta

MarcosFurgoneta

JuanFurgoneta

MarcosFurgoneta

JuanCamin

MarcosCamin

Tabla en cuarta forma normal

Tipo VehculoTipo Carga

FurgonetaPerecederos

FurgonetaPerecederos

FurgonetaMuebles

FurgonetaMuebles

CaminMudanza

CaminMudanza

DEPENDENCIA DE JUNTURA Y 5 FN

Est en cuarta forma normal y toda dependencia-join viene implicada por claves candidatas.

Se dice que hay dependencia de JOIN, de unin o de producto si una tabla tiene dependencia de *unin con varias de sus *proyecciones y se puede obtener la tabla por medio de la unin de dichas proyecciones.

Proyeccin:

Creacin de una tabla cuyos elementos forman un subconjunto de una tabla dada. Se incluyen todas las filas y algunas columnas.

Unin:

Formar, a partir de dos tablas, una nueva con todos los campos de una de ellas y los registros de ambas, excepto los repetidos. Ambas tablas han de tener el mismo grado y las mismas columnas.

Una tabla esta en Quinta Forma Normal (5FN) o Forma Normal de Proyeccin-Unin si est en 4FN y las nicas dependencias que existen son las dependencias de unin de una tabla con sus proyecciones relacionndose entre las distintas proyecciones mediante la clave primaria o cualquier clave alternativa. La 5FN se emplea cuando en una misma tabla tenemos mucha informacin redundante, con pocos atributos o cuando una tabla posee una gran cantidad de atributos y se hace por ello inmanejable.

Para conseguir que una tabla en 4FN con gran cantidad de atributos est en 5FN, se parte la tabla original en tantas tablas como se desee, teniendo cada una de ellas en comn con las dems los campos que forman la clave primaria en la tabla original.

Ejemplo para el caso de una tabla que posee una gran cantidad de atributos:

Tabla

IdDatos FamiliaresDatos ProfesionalesDatos PersonalesDatos Clnicos

1D1D2D3D4D5D6D7D8D9D10D11D12

En este caso tenemos una empresa donde se guardan los datos personales, familiares, profesionales y clnicos de cada empleado en una nica tabla llamada Empleados. Si esta tabla est ya en 4FN, se puede partir en las tablas empleados-personal, empleados-familia, empleados-profesional, empleados-clnicos; de este modo, la velocidad de acceso y la gestin de datos por cada departamento de la empresa se simplifica, al no tenerse que crear ningn tipo de restriccin sobre determinados atributos que no han de ser vistos por el personal que no los necesite.

El resultado sera:

Tabla en quinta forma normal

IdDatos Familiares

1D1D2D3


IdDatos Profesionales

1D4D5D6


IdDatos Personales

1D7D8D9


IdDatos Clnicos

1D10D11D12

4.9 INTEGRIDAD DE LAS BASES DE DATOSCONCEPTO

Las restricciones de integridad proporcionan un medio de asegurar que las modificaciones hechas a la base de datos por los usuarios autorizados no provoquen la prdida de la consistencia de los datos. Por tanto, las restricciones de integridad protegen a la base de datos contra los daos accidentales.

La integridad significa que todos los datos requeridos para responder a una pregunta especfica estn disponibles. Por ejemplo, un marcador de bisbol debe incluir el tanteo de ambos equipos. Si se oye el tanteo New York 6 y no oyes el del oponente, el anuncio ser incompleto y sin sentido. Los datos son inequvocos cuando el contexto es claro. Por ejemplo, el grupo de signos 2-x puede parecer la cantidad 2 menos la cantidad desconocida llamada x para un estudiante de lgebra, puede significar 2 barra x a un vaquero que marca ganado. Tenemos que conocer el contexto de estos smbolos antes de poder conocer su significado.

RESTRICCIONES BSICAS (NOT NULL, LLAVE PRIMARIA, ORDEN, VERIFICACIN Y ASERCIN)

En el modelo relacional, existen restricciones, es decir, estructuras u ocurrencias no permitidas, siendo preciso distinguir entre restricciones inherentes y restricciones de usuario.

Restricciones inherentes

Adems de las derivadas de la definicin matemtica de relacin como eran que:

No hay dos tuplas iguales.

El orden de las tuplas no es significativo.

El orden de los atributos (columnas) no es significativo.

Cada atributo slo puede tomar un nico valor del dominio, no admitindose por tanto los grupos repetitivos.

Tenemos que la regla de integridad de entidad establece que Ningn atributo que forme parte de la clave primaria de una relacin puede tomar un valor nulo; esto es, un valor desconocido o inexistente. Esta restriccin debera aplicarse tambin a las claves alternativas, pero el modelo no lo exige.

Restricciones de usuario

Podemos considerar la restriccin de usuario, dentro del contexto relacional, como un predicado definido sobre un conjunto de atributos, de tuplas o de dominios, que debe ser verificado por los correspondientes objetos para que stos constituyan una ocurrencia vlida del esquema.

Dentro de las restricciones de usuario destaca la restriccin de integridad referencial que dice que los valores de clave ajena deben coincidir con los de clave primaria asociada a ella o ser nulos.

La integridad referencial es una restriccin de comportamiento ya que viene impuesta por el mundo real y es el usuario quien la define al describir el esquema relacional; es tambin de tipo implcito, ya que se define en el esquema y el modelo la reconoce (o as algunos productos) sin necesidad de que se programe ni de que se tenga que escribir ningn procedimiento para obligar a que se cumpla.

Restriccin de valor no nulo (NOT NULL).

Restriccin que indica que un conjunto de atributos no admiten valores nulos.

Restriccin de clave primaria (PRIMARY KEY).

Para facilitar la manipulacin de las relaciones en una base de datos relacional, se introduce el concepto de clave primaria.

Una clave primaria de una relacin es un conjunto de atributos de su esquema que son elegidos para servir de identificador de sus tuplas. Debe cumplir tres requisitos:

- valor no nulo

- unicidad

- univalorado

Superllave o Superclave (superkey): Cualquier conjunto de atributos SK que cumple la restriccin de unicidad: Que no existan dos tuplas con el mismo valor en los atributos de SK.

Todos los atributos de una relacin forman siempre una superllave.

Llave o Clave: Superllave mnima, sin atributos superfluos. Si se quita un atributo de la llave, deja de ser superllave.

Llave Candidata: Llave que existe en una relacin (pueden existir varias).

Llave Primaria: Llave Candidata que se usar para identificar las tuplas de la relacin. Suele escogerse la que tenga menos atributos. Se representar subrayada. Ejemplo: Estudiante(NIF, Nombre, Fecha_Nacimiento, Direccion, Telefono);

Llave Externa: Atributos de una relacin que son Llave Primaria en otra.

Sirve para enlazar una relacin con otra

Restriccin de unicidad (UNIQUE).

Permite la definicin de conjuntos de atributos cuyos valores no pueden repetirse dentro de la relacin.

Restriccin de integridad referencial (FOREIGN KEY).

Las claves ajenas son el mecanismo que proporciona el modelo relacional para expresar asociaciones entre las relaciones.

La forma de incluirla, consiste en incluir en el esquema de una relacin R atributos identificadores de otra relacin S; a este conjunto de atributos se les conoce como claves ajenas de la relacin R.

check (P): la clusula check especifica un predicado P que debe satisfacer cada tupla de la relacin.

En SQL la clusula check permite al diseador del esquema especificar un predicado que debe satisfacer cualquier valor asignado a una variable cuyo tipo sea el dominio. Por ejemplo, una clusula check puede asegurar que un dominio de sueldo por hora slo permita valores mayores que un valor especificado (como puede ser el sueldo mnimo), tal y como se muestra aqu:

create domain sueldo-por-hora numeric(5,2)

constraint comprobacin-valor-sueldo

check(value 4.00)

Asercin. Un aserto es un predicado que expresa una condicin que se desea que la base de datos satisfaga siempre. Las restricciones de dominio y las de integridad referencial son formas especiales de los asertos. Se ha prestado una atencin especial a estos tipos de asertos porque se pueden verificar con facilidad y se aplican a una gran variedad de aplicaciones de bases de datos. Sin embargo, hay muchas restricciones que no se pueden expresar utilizando nicamente estas formas especiales. Ejemplos de estas restricciones pueden ser:

La suma de todos los importes de los prstamos de cada sucursal debe ser menor que la suma de todos los saldos de las cuentas de esa sucursal.

Cada prstamo tiene al menos un cliente que tiene una cuenta con un saldo mnimo de 1.000 .

En SQL los asertos adoptan la forma create assertion check

INTEGRIDAD DE ENTIDAD

Una llave primaria no puede ser Null.

La integridad de entidad define una fila como una nica instancia de una entidad para una tabla en particular. La integridad de entidad asegura la integridad de la columna de identificacin o la clave primaria de una tabla (a travs de ndices, restricciones UNIQUE, restricciones PRIMARY KEY, o propiedades IDENTITY).

INTEGRIDAD REFERENCIAL

Si en una relacin hay una referencia a una tupla de otra relacin, esa referencia debe ser a una tupla que exista.

Ejemplo: Dpto (NumDpto, Nombre, NIFDirector...)

NIFDirector indica el NIF del director del departamento nmero NumDpto. As, NIFDirector, debe existir en la relacin.

Empleado (NIF, Nombre, Direccion...).

NIFDirector en la relacin Dpto es una LLAVE EXTERNA.

La base de datos no debe contener valores de clave ajena sin concordancia. As como los valores de clave primaria representan identificadores de entidades, las claves ajenas representan referencia a entidades.

La regla dice: Si B hace referencia a A entonces A debe existir.

Surgen los siguientes dos puntos:

La integridad referencial exige concordancia en las claves ajenas, con las claves primarias, no con las claves alternativas.

Los conceptos de clave ajena e integridad referencial se definen uno en trmino del otro.

Otra definicin de Regla de integridad referencial

La segunda regla de integridad se aplica a las claves ajenas: si en una relacin hay alguna clave ajena, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o bien, deben ser completamente nulos.

La regla de integridad referencial se enmarca en trminos de estados de la base de datos: indica lo que es un estado ilegal, pero no dice cmo puede evitarse. La cuestin es qu hacer si estando en un estado legal, llega una peticin para realizar una operacin que conduce a un estado ilegal? Existen dos opciones: rechazar la operacin, o bien aceptar la operacin y realizar operaciones adicionales compensatorias que conduzcan a un estado legal.

Por lo tanto, para cada clave ajena de la base de datos habr que contestar a tres preguntas:

Regla de los nulos: Tiene sentido que la clave ajena acepte nulos?

Regla de borrado: Qu ocurre si se intenta borrar la tupla referenciada por la clave ajena?

Restringir: no se permite borrar la tupla referenciada.

Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas que la referencian mediante la clave ajena.

Anular: se borra la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena (slo si acepta nulos).

Regla de modificacin: Qu ocurre si se intenta modificar el valor de la clave primaria de la tupla referenciada por la clave ajena?

Restringir: no se permite modificar el valor de la clave primaria de la tupla referenciada.

Propagar: se modifica el valor de la clave primaria de la tupla referenciada y se propaga la modificacin a las tuplas que la referencian mediante la clave ajena.

Anular: se modifica la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena (slo si acepta nulos).

REGLAS DE RELACIN

Reglas de Relacin Segn [Elmasri / Navathe]

Orden de las tuplas en una relacin: una relacin se define como un conjunto de tuplas matemticamente, los elementos de un conjunto no estn ordenados; por tanto, las tuplas de una relacin no tienen orden especfico.

El ordenamiento de las tuplas no forma parte de la definicin de una relacin, porque la relacin intenta representar los hechos en un nivel lgico abstracto.

Orden de los valores dentro de una tupla, y definicin alternativa de relacin: Una tupla es una lista ordenada de n valores, as que el orden de los valores de una tupla y por tanto de los atributos en la definicin de un esquema de relacin es importante. No obstante, en un nivel lgico, el orden de los atributos y de sus valores en realidad no es importante en tanto se mantenga la correspondencia entre atributos y valores.

Valores en las Tuplas: Cada valor en una tupla es un valor atmico; esto es, no es divisible en componentes en lo que respecta al modelo relacional. Por ello no se permiten valores compuestos ni multivaluados.

REGLAS DE BASE DE DATOS

El Dr. Frank Codd Codd se percat de que existan bases de datos en el mercado las cuales decan ser relacionales, pero lo nico que hacan era guardar la informacin en las tablas, sin estar estas tablas literalmente normalizadas; entonces en 1985 ste public 12 reglas para evaluar si un DBMS (DataBase Management System) puede considerarse un RDBMS (Relational DataBase Management System), o dicho ms concisamente, si un sistema de bases de datos puede considerarse o no relacional.

En la prctica algunas de ellas son difciles de realizar. Un sistema podr considerarse "ms relacional" cuanto ms siga estas reglas.

Regla 1: La Regla de la informacin. Para que un sistema se denomine sistema de administracin de bases de datos relacionales, debe usar (exclusivamente) sus capacidades relacionales para gestionar la base de datos.

Toda la informacin en un RDBMS est explcitamente representada de una sola manera por valores en una tabla.

Cualquier cosa que no exista en una tabla no existe del todo. Toda la informacin, incluyendo nombres de tablas, nombres de vistas, nombres de columnas, y los datos de las columnas deben estar almacenados en tablas dentro de las bases de datos. Las tablas que contienen tal informacin constituyen el Diccionario de Datos. Esto significa que todo tiene que estar almacenado en las tablas.

Toda la informacin en una base de datos relacional se representa explcitamente en el nivel lgico exactamente de una manera: con valores en tablas. Por tanto los metadatos (diccionario, catlogo) se representan exactamente igual que los datos de usuario.

Y puede usarse el mismo lenguaje (ej. SQL) para acceder a los datos y a los metadatos (regla 4)

Regla 2: regla del acceso garantizado. Para todos y cada uno de los datos (valores atmicos) de una Base de Datos Relacional (BDR) se garantiza que son accesibles a nivel lgico utilizando una combinacin de nombre de tabla, valor de clave primaria y nombre de columna.

Cualquier dato almacenado en una BDR tiene que poder ser direccionado unvocamente. Para ello hay que indicar en qu tabla est, cul es la columna y cul es la fila (mediante la clave primaria).

Por tanto se necesita el concepto de clave primaria, que no es soportado en muchas implementaciones. En estos casos, para lograr un efecto similar se puede hacer lo siguiente:

Hacer que los atributos clave primaria no puedan ser nulos (NOT NULL).

Crear un ndice nico sobre la clave primaria.

No eliminar nunca el ndice.

Cada tem de datos debe ser lgicamente accesible al ejecutar una bsqueda que combine el nombre de la tabla, su clave primaria, y el nombre de la columna.

Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y dado el nombre de la columna requerida, deber encontrarse uno y solamente un valor. Por esta razn la definicin de claves primarias para todas las tablas es prcticamente obligatoria.

Regla 3: tratamiento sistemtico de valores nulos. Los valores nulos (que son distintos de la cadena vaca, blancos, 0, ) se soportan en los SGBD totalmente relacionales para representar informacin desconocida o no aplicable de manera sistemtica, independientemente del tipo de datos.

Se reconoce la necesidad de la existencia de valores nulos, para un tratamiento sistemtico de los mismos.

Hay problemas para soportar los valores nulos en las operaciones relacionales, especialmente en las operaciones lgicas.

Lgica trivaluada. En una posible solucin. Existen tres (no dos) valores de verdad: Verdadero, Falso y Desconocido (null). Se crean tablas de verdad para las operaciones lgicas:

null Y null = null

Verdadero Y null = null

Falso Y null = Falso

Verdadero O null = Verdadero etc.

Un inconveniente es que de cara al usuario el manejo de los lenguajes relacionales se complica pues es ms difcil de entender.

Regla 4: diccionario dinmico en lnea basado en el modelo relacional descripcin de la base de datos. La descripcin de la base de datos se representa a nivel lgico de la misma manera que los datos normales, de modo que los usuarios autorizados pueden aplicar el mismo lenguaje relacional a su consulta, igual que lo aplican a los datos normales. Es una consecuencia de la regla 1 que se destaca por su importancia. Los metadatos se almacenan usando el modelo relacional, con todas las consecuencias.

La descripcin de la base de datos es almacenada de la misma manera que los datos ordinarios, esto es, en tablas y columnas, y debe ser accesible a los usuarios autorizados.

La informacin de tablas, vistas, permisos de acceso de usuarios autorizados, etc, debe ser almacenada exactamente de la misma manera: En tablas. Estas tablas deben ser accesibles igual que todas las tablas, a travs de sentencias de SQL.

Regla 5: regla del sublenguaje de datos completo. Un sistema relacional debe soportar varios lenguajes y varios modos de uso de terminal (ej: rellenar formularios, etc.). Sin embargo, debe existir al menos un lenguaje cuyas sentencias sean expresables, mediante una sintaxis bien definida, como cadenas de caracteres y que sea completo, soportando:

Definicin de datos.

Definicin de vistas.

Manipulacin de datos (interactiva y por programa).

Limitantes de integridad. Limitantes de transaccin (iniciar, realizar, deshacer) (Begin, commit, rollback).

Adems de poder tener interfaces ms amigables para hacer consultas, etc. siempre debe de haber una manera de hacerlo todo de manera textual, que es tanto como decir que pueda ser incorporada en un programa tradicional.

Un lenguaje que cumple esto en gran medida es SQL.

Debe haber al menos un lenguaje que sea integral para soportar la definicin de datos, manipulacin de datos, definicin de vistas, restricciones de integridad, y control de autorizaciones y transacciones.

Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien definida que pueda ser usado para administrar completamente la base de datos.

Regla 6: regla de actualizacin de vistas. Todas las vistas que son tericamente actualizables se pueden actualizar por el sistema.

El problema es determinar cules son las vistas tericamente actualizables, ya que no est muy claro.

Cada sistema puede hacer unas suposiciones particulares sobre las vistas que son actualizables.

Todas las vistas que son tericamente actualizables, deben ser actualizables por el sistema mismo.

La mayora de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos de actualizar vistas complejas.

Regla 7: insercin, actualizacin y borrado de alto nivel. La capacidad de manejar una relacin base o derivada como un solo operando se aplica no slo a la recuperacin de los datos (consultas), sino tambin a la insercin, actualizacin y borrado de datos.

Esto es, el lenguaje de manejo de datos tambin debe ser de alto nivel (de conjuntos). Algunas bases de datos inicialmente slo podan modificar las tuplas de la base de datos de una en una (un registro de cada vez).

La capacidad de manejar una base de datos con operandos simples aplica no slo para la recuperacin o consulta de datos, sino tambin para la insercin, actualizacin y borrado de datos'.

Esto significa que las clusulas SELECT, UPDATE, DELETE e INSERT deben estar disponibles y operables sobre los registros, independientemente del tipo de relaciones y restricciones que haya entre las tablas.

Regla 8: independencia fsica de datos. Los programas de aplicacin y actividades del terminal permanecen inalterados a nivel fsico cuando quiera que se realicen cambios en las representaciones de almacenamiento o mtodos de acceso.

El modelo relacional es un modelo lgico de datos, y oculta las caractersticas de su representacin fsica.

Es la capacidad de modificar el esquema interno sin tener que alterar el esquema conceptual (o los externos). Por ejemplo, puede ser necesario reorganizar ciertos ficheros fsicos con el fin de mejorar el rendimiento de las operaciones de consulta o de actualizacin de datos. la independencia fsica se refiere slo a la separacin entre las aplicaciones y las estructuras fsicas de almacenamiento.

El acceso de usuarios a la base de datos a travs de terminales o programas de aplicacin, debe permanecer consistente lgicamente cuando quiera que haya cambios en los datos almacenados, o sean cambiados los mtodos de acceso a los datos.

El comportamiento de los programas de aplicacin y de la actividad de usuarios va terminales debera ser predecible basados en la definicin lgica de la base de datos, y ste comportamiento debera permanecer inalterado, independientemente de los cambios en la definicin fsica de sta.

Regla 9: independencia lgica de datos. Los programas de aplicacin y actividades del terminal permanecen inalterados a nivel lgico cuando quiera que se realicen cambios a las tablas base que preserven la informacin.

Cuando se modifica el esquema lgico preservando informacin (no valdra p. ej. eliminar un atributo) no es necesario modificar nada en niveles superiores.

Ejemplos de cambios que preservan la informacin:

Aadir un atributo a una tabla base.

Sustituir dos tablas base por la unin de las mismas. Usando vistas de la unin puedo recrear las tablas anteriores

Los programas de aplicacin y las actividades de acceso por terminal deben permanecer lgicamente inalteradas cuando quiera que se hagan cambios (segn los permisos asignados) en las tablas de la base de datos.

La independencia lgica de los datos especifica que los programas de aplicacin y las actividades de terminal deben ser independientes de la estructura lgica, por lo tanto los cambios en la estructura lgica no deben alterar o modificar estos programas de aplicacin.

Regla 10: independencia de integridad. Los limitantes de integridad especficos para una determinada base de datos relacional deben poder ser definidos en el sublenguaje de datos relacional, y almacenables en el catlogo, no en los programas de aplicacin.

El objetivo de las bases de datos no es slo almacenar los datos, sino tambin sus relaciones y evitar que estas (limitantes) se codifiquen en los programas. Por tanto en una BDR se deben poder definir limitantes de integridad.

Cada vez se van ampliando ms los tipos de limitantes de integridad que se pueden utilizar en los SGBDR, aunque hasta hace poco eran muy escasos.

Como parte de los limitantes inherentes al modelo relacional (forman parte de su definicin) estn:

Una BDR tiene integridad de entidad. Es decir, toda tabla debe tener una clave primaria.

Una BDR tiene integridad referencial. Es decir, toda clave externa no nula debe existir en la relacin donde es primaria.

Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catalogo, no en el programa de aplicacin.

Las reglas de integridadNingn componente de una clave primaria puede tener valores en blanco o nulos. (Esta es la norma bsica de integridad).

Para cada valor de clave fornea deber existir un valor de clave primaria concordante. La combinacin de estas reglas asegura que haya Integridad referencial.

Regla 11: independencia de distribucin. Una BDR tiene independencia de distribucin.

Las mismas rdenes y programas se ejecutan igual en una BD centralizada que en una distribuida.

Las BDR son fcilmente distribuibles:

Se parten las tablas en fragmentos que se distribuyen.

Cuando se necesitan las tablas completas se recombinan usando operaciones relacionales con los fragmentos.

Sin embargo se complica ms la gestin interna de la integridad, etc.

Esta regla es responsable de tres tipos de transparencia de distribucin:

Transparencia de localizacin. El usuario tiene la impresin de que trabaja con una BD local. (aspecto de la regla de independencia fsica).

Transparencia de fragmentacin. El usuario no se da cuenta de que la relacin con que trabaja est fragmentada. (aspecto de la regla de independencia lgica de datos).

Transparencia de replicacin. El usuario no se da cuenta de que pueden existir copias (rplicas) de una misma relacin en diferentes lugares.

El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos est distribuida fsicamente en distintos lugares sin que esto afecte o altere a los programas de aplicacin.

El soporte para bases de datos distribuidas significa que una coleccin arbitraria de relaciones, bases de datos corriendo en una mezcla de distintas mquinas y distintos sistemas operativos y que est conectada por una variedad de redes, pueda funcionar como si estuviera disponible como en una nica base de datos en una sola mquina.

Regla 12: regla de la no subversin (violacin). Si un sistema relacional tiene un lenguaje de bajo nivel (un registro de cada vez), ese bajo nivel no puede ser usado para saltarse (subvertir) las reglas de integridad y los limitantes expresados en los lenguajes relacionales de ms alto nivel (una relacin (conjunto de registros) de cada vez)

Algunos problemas no se pueden solucionar directamente con el lenguaje de alto nivel.

Normalmente se usa SQL inmerso en un lenguaje anfitrin para solucionar estos problemas. Se utiliza el concepto de cursor para tratar individualmente las tuplas de una relacin. En cualquier caso no debe ser posible saltarse los limitantes de integridad impuestos al tratar las tuplas a ese nivel.

Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser usados para violar la integridad de las reglas y restricciones expresadas en un lenguaje de alto nivel (como SQL).

Algunos productos solamente construyen una interfaz relacional para sus bases de datos No relacionales, lo que hace posible la subversin (violacin) de las restricciones de integridad. Esto no debe ser permitido.

REGLAS DE NEGOCIOS

Adems de las dos reglas de integridad anteriores, los usuarios o los administradores de la base de datos pueden imponer ciertas restricciones especficas sobre los datos, denominadas reglas de negocio.

Por ejemplo, si en una oficina de la empresa inmobiliaria slo puede haber hasta veinte empleados, el SGBD debe dar la posibilidad al usuario de definir una regla al respecto y debe hacerla respetar. En este caso, no debera permitir dar de alta un empleado en una oficina que ya tiene los veinte permitidos.

Hoy en da an existen SGBD relacionales que no permiten definir este tipo de restricciones ni las hacen respetar.

PROPIEDADES DE ATOMICIDAD, CONSISTENCIA AISLAMIENTO Y DURABILIDAD (ACID)Para asegurar la integridad de los datos se necesita que el sistema de base de datos mantenga las siguientes propiedades de las transacciones:

1. Atomicidad. Todas las operaciones de la transaccin son ejecutadas por completo adecuadamente, o no se ejecuta ninguna de ellas (si se ejecuta la transaccin, se hace hasta el final).

2. Consistencia. Una transaccin T transforma un estado consistente de la base de datos en otro estado consistente, aunque T no tiene por qu preservar la consistencia en todos los puntos intermedios de su ejecucin. Un ejemplo es el de la transferencia de una cantidad de dinero entre dos cuentas bancarias.

La ejecucin aislada de la transaccin (es decir, sin otra transaccin que se ejecute concurrentemente) conserva la consistencia de la base de datos.

3. Aislamiento (Isolation). Una transaccin est aislada del resto de transacciones. Aunque existan muchas transacciones ejecutndose a la vez, cualquier modificacin de datos que realice T est oculta para el resto de transacciones hasta que T sea confirmada (realiza COMMIT). Es decir, para cualesquiera T1 y T2, se cumple que - T1 ve las actualizaciones de T2 despus de que T2 realice COMMIT, o bien - T2 ve las modificaciones de T1, despus de que T1 haga un COMMIT Pero nunca se cumplen ambas cosas al mismo tiempo. Nota: esta propiedad puede no imponerse de forma estricta; de hecho, suelen definirse niveles de aislamiento de las transacciones.

Aunque se ejecuten varias transacciones concurrentemente, el sistema garantiza que para cada par de transacciones Ti y Tj, se cumple que para los efectos de Ti, o bien Tj ha terminado su ejecucin antes de que comience Ti , o bien que Tj ha comenzado su ejecucin despus de que Ti termine. De este modo, cada transaccin ignora al resto de las transacciones que se ejecuten concurrentemente en el sistema.

4. Durabilidad. Una vez que se confirma una transaccin, sus actualizaciones sobreviven cualquier fallo del sistema. Las modificaciones ya no se pierden, aunque el sistema falle justo despus de realizar dicha confirmacin. El Subsistema de Recuperacin del SGBD es el encargado de conseguir el cumplimiento de las propiedades de atomicidad y durabilidad de las transacciones. La conservacin de la consistencia es una propiedad cuyo cumplimiento han de asegurar, por un lado los programadores de base de datos, y por otro el Subsistema de Integridad del SGBD. El Subsistema de Control de Concurrencia es el encargado de conseguir el aislamiento de las transacciones.Tras la finalizacin con xito de una transaccin, los cambios realizados en la base de datos permanecen, incluso si hay fallos en el sistema.

Estas propiedades a menudo reciben el nombre de propiedades ACID; el acrnimo se obtiene de la primera letra de cada una de las cuatro propiedades en ingls (Atomicity, Consistency, Isolation y Durability, respectivamente).

BIBLIOGRAFASilberschatz, Korth, Sudarshan, Fundamentos de bases de datos, cuarta edicin, Mc Graw-Hill, 2002,787 p.ABRAMHAM, KORTH y SUDARSHAN)

(ELMASRI/NAVATHE)

http://www3.uji.es/~mmarques/f47/apun/node1.html

http://es.wikipedia.org/wiki/Sistema_administrador_de_bases_de_datos_relacionales

http://basesdedatosrelacionales.blogspot.com/2007/11/344-vistas-y-seguridad.htmlhttp://es.wikipedia.org/wiki/Primera_forma_normalhttp://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datoshttp://es.wikipedia.org/wiki/Segunda_forma_normalhttp://es.wikipedia.org/wiki/Tercera_forma_normalPAGE 17

Fundamentos de Bases de Datos UNIDAD IV - Copiasi

Documents

Transcript of Fundamentos de Bases de Datos UNIDAD IV - Copiasi