1. Unidad Educativa San
Juan Evangelista.
Optimización y Diseño de Base de Datos Relacionales
16/09/2013
Nathaly Espinoza

2. Introducción:
Primero definamos que es una base de datos Relacional, básicamente es una
base de datos que sigue un modelo relacional, es decir un es un almacén de datos
que está conformada estructuralmente por tablas que tienen interconexiones entre
ellas (relacionales).
Como cualquier modelo de base de datos la idea es la manipulación de datos y
hoy por hoy es el modelo más utilizado para sistemas transaccionales (aclaro que
no todo sistema debe utilizar una BD relacional, se debe de analizar si otros
modeles aplican mejor, tales como Bases de Datos XML, Bases de Datos
Orientadas a objetos, Multidimensionales – muy populares para inteligencia de
negocios, entre otros). Las operaciones básicas sobre datos en este modelo se
realizan mediante operaciones de algebra relacional (muy orientadas a teoría de
conjuntos), por lo que es común observar una consulta a una base de datos
expresada de manera algebraica para determinar si existe alguna manera de
hacerla más eficiente.
Problemas que puede presentar el diseño de una Base de Datos
Relacional:
 sólo permite establecer relaciones a través de una columna:
Esto obliga a los usuarios a recurrir a una serie de procedimientos
elaborados para construir una clave de una sola columna.
 no puede trabajar con expresiones "al vuelo":
Los porcentajes y las proporciones se deben almacenar en columnas extra.
Estos valores pueden quedar desfasados y su creación requiere un gran
trabajo extra.
 no funciona demasiado bien con relaciones muchos a muchos.
 Una relación uno a muchos produce un valor arbitrario en la tabla
relacionada.
 Un "enlace" o vínculo, más que una relación, proporciona alguna capacidad
muchos a uno, aunque bastante limitada.
 Las herramientas de agregado y "agrupamiento" disponibles son también
limitadas.
Anomalías CODD:

3. ANOMALIAS CODD
El proceso de normalización esun estándar
que consiste,básicamente, en un proceso
de conversión de las relacionesentre las
entidades, evitando
Concepto
La
redundancia
de datos
Repetición de datosen un
sistema
ANOMALIAS DE
ACTUACION
Inconsistencias delos datos
comoresultado de
datosredundancia
yactualizacionesparciales
ANOMALIAS DE
borrado
Pérdidas nointencionadasde
datos debidoa que se
hanborrado otrosdatos
ANOMALIAS DE
INCERSION
Imposibilidad deadicionar
datosen la base dedatos
debido a laausencia de
otrosdatos
INTEGRIDAD DE
LOS DATOS
La solución a estasanomalías
es ladescomposición
delesquema original
ensubesquema lo
queseguimos con elproceso

4. Normalización:
Consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del
modelo entidad-relación al modelo relacional.
Las bases de datos relacionales se normalizan para:
♥ Evitar la redundancia de los datos.
♥ Evitar problemas de actualización de los datos en las tablas.
♥ Proteger la integridad de los datos.
En el modelo relacional es frecuente llamar tabla a una relación, aunque para que
una tabla sea considerada como una relación tiene que cumplir con algunas
restricciones:
♠ Cada tabla 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.

5. Estructura de los datos:
En programación, una estructura de datos es una forma de organizar un conjunto
de datos elementales con el objetivo de facilitar su manipulación.
♥ Un dato elemental es la mínima información que se tiene en un sistema.
Una estructura de datos define la organización e interrelación de estos y un
conjunto de operaciones que se pueden realizar sobre ellos. Las operaciones
básicas son:
♠ Alta, adicionar un nuevo valor a la estructura.
♠ Baja, borrar un valor de la estructura.
♠ Búsqueda, encontrar un determinado valor en la estructura para realizar una
operación con este valor, en forma secuencial o binario (siempre y cuando los
datos estén ordenados).
Otras operaciones que se pueden realizar son:
♣ Ordenamiento, de los elementos pertenecientes a la estructura.
♣ Apareo, dadas dos estructuras originar una nueva ordenada y que contenga a
las apareadas.
Cada estructura ofrece ventajas y desventajas en relación a la simplicidad y
eficiencia para la realización de cada operación.
De esta forma, la elección de la estructura de datos apropiada para cada problema
depende de factores como la frecuencia y el orden en que se realiza cada
operación sobre los datos.
Dependencia Funcional:
Una dependencia funcional, denotada por X -> Y, entre dos conjuntos de atributos
X y Y que son subconjuntos de R (R = {A1, A2,..., A3}) especifica una restricción
sobre las posibles tuplas que podrían formar un ejemplar de relación r de R. La
restricción dice que, para cualesquier dos tuplas t1 y t2 de r tales que t1 [X] = t2
[X], debemos tener también t1 [Y] = t2 [Y]. Esto significa que los valores
componentes de Y de una tupla de r dependen de los valores del componente X, o
están determinados por ellos; o bien, que los valores del componente X de una
tupla determinan de manera única (o funcionalmente) los valores del componente
Y. También decimos que hay una dependencia funcional de X a Y o que Y
depende funcionalmente de X.

6. Las dependencias funcionales verifican una serie de propiedades denominadas
axiomas de Armstrong:
햪 Reflexividad. A partir de cualquier atributo o conjunto de atributos siempre
puede deducirse él mismo. Dependencia trivial: x -> x.
♥ Aumentatividad. Si x -> y entonces x+z -> y. Así se puede aumentar trivialmente
el antecedente de una dependencia. Ejemplo: si con el DNI se determina el
nombre de una persona, entonces con el DNI más la dirección también se
determina el nombre.
♥ Proyectividad. Si x -> y+z entonces x -> y. Ejemplo: si a partir del DNI es posible
deducir el nombre y la dirección de una persona, entonces con el DNI es posible
determinar el nombre.
♥ Aditividad. Si x -> y y z -> w entonces x+z -> y+z. Ejemplo: si con el DNI se
determina el nombre y con la dirección el teléfono de una persona, entonces con
el DNI y la dirección podrá determinarse el nombre y el teléfono.
♥Transitividad o enlace de dependencias funcionales. Si x -> y e y -> z entonces x
-> z. Ejemplo: si con el DNI puede determinarse el código de la provincia de
residencia de una persona y con éste código puede determinarse el nombre de la
provincia, entonces con el DNI puede determinarse el nombre de la provincia. Éste
es el mecanismo básico de funcionamiento del enlace entre tablas a partir de
claves ajenas.
Primera Forma Normal:
(1FN o forma mínima) es una forma normal usada en normalización de bases de
datos. Una tabla de base de datos relacional que se adhiere a la 1FN es una que
satisface cierto conjunto mínimo de criterios. Estos criterios se refieren
básicamente a asegurarse que la tabla es una representación fiel de una relación
y está libre de "grupos repetitivos".
Sin embargo, el concepto de "grupo repetitivo", es entendido de diversas maneras
por diferentes teóricos. Como consecuencia, no hay un acuerdo universal en
cuanto a qué características descalificarían a una tabla de estar en 1FN. Muy
notablemente, la 1FN, tal y como es definida por algunos autores excluye
"atributos relación-valor" (tablas dentro de tablas) siguiendo el precedente
establecido por (E.F. Codd) (algunos de esos autores son: Ramez Elmasri y
Shamkant B. Navathe). Por otro lado, según lo definido por otros autores, la 1FN
sí los permite (por ejemplo como la define Chris Date).

7. Segunda Forma Normal:
La segunda forma normal (2NF) es una forma normal usada en normalización 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. Específicamente: 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 términos levemente más 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 más de un atributo), la tabla está
automáticamente en 2NF.
Tercera Forma Normal:
La tercera forma normal (3NF) es una forma normal usada en la normalización de
bases de datos. La 3NF fue definida originalmente por E.F. Codd en 1971. La
definición 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)
☺ Ningún 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 formulación alternativa de la definición de Codd, dada por Carlo Zaniolo2
en 1982, es ésta: Una tabla está en 3NF si y solo si, para cada una de sus

8. dependencias funcionales X → A, por lo menos una de las condiciones siguientes
se mantiene:
☺ X contiene A, oX es una súperclave, oA es un atributo primario (es decir, A está
contenido dentro de una clave candidata)
Forma Normal Boyce-Codd:
La Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en la
normalización de bases de datos. Es una versión ligeramente más 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 A to A). 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 términos 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 sólo tiene asignado uno. Tendríamos una tabla con las columnas:
ID Trabajador, ID Departamento, ID Responsable
La única clave candidata es ID Trabajador (que será por tanto la clave primaria).
Si añadimos la limitación de que el responsable sólo puede serlo de un
departamento, este detalle produce una dependencia funcional ya que:
Responsable → Departamento
Por lo tanto hemos encontrado un determinante (ID Responsable) que sin
embargo no es clave candidata. Por ello, esta tabla no está en FNBC. En este
caso la redundancia ocurre por mala selección de clave. La repetición del par [ID
Departamento + ID Responsable] 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

9. estudiante puede tener más de un tutor):
El propósito de la tabla es mostrar qué tutores están asignados a qué estudiantes.
Las claves candidatas de la tabla son:{ID Tutor, ID Estudiante}
{Número de seguro social del tutor, ID Estudiante}
FIN ♥