Está en la página 1de 35

BASES DE DATOS MIS 308

1
4. DISEO DE BASES DE DATOS RELACIONALES
Introduccin
4.1 Definicin del problema
4.2 Solucin de problemas
4.3 Normalizacin: 1NF, 2NF, 3FN
4.4 Criterios para normalizar

Introduccin
Como ya hemos visto en los Subtemas Nos. 2.4 y 3.4 los Modelos
Relacionales son de los utilizados muy ampliamente y recordando que el
modelo es la base (core) para los DBMS es importante refrendar los
conceptos bsicos y de donde vienen.
Muchas disciplinas (y sus metodologas de diseo asociadas) tienen
algn tipo de base terica. Los ingenieros industriales disean
estructuras utilizando teoras de la fsica. Los compositores crean
sinfonas utilizando conceptos de teora de la msica. La industria del
automvil utiliza teoras de la aerodinmica para disear automviles con
menor consumo. La industria aeronutica utiliza las mismas teoras para
disear alas de aviones que reduzcan la resistencia al viento.
Estos ejemplos demuestran que la teora es muy importante. La ventaja
principal de la teora es que hace que las cosas sean predecibles: nos
permite predecir qu ocurrir si realizamos una determinada accin. Por
ejemplo, sabemos que si soltamos una piedra, caer al suelo. Si somos
rpidos, podemos apartar nuestros pies del camino de la teora de la
gravedad de Newton. Lo importante es que siempre funciona. Si
ponemos una piedra plana encima de otra piedra plana, podemos
predecir que se quedarn tal y como las hemos puesto. Esta teora
permite disear pirmides, catedrales y casas de ladrillos. Consideremos
ahora el ejemplo de una base de datos relacional. Sabemos que si un par
de tablas estn relacionadas, podemos extraer datos de las dos a la vez,
simplemente por el modo en que funciona la teora de las }bases de
datos relacionales. Los datos que se saquen de las dos tablas se
basarn en los valores coincidentes del campo que ambas tienen en
comn. Una vez ms, nuestras acciones tienen un resultado predecible.
El modelo relacional se basa en dos ramas de las matemticas: la teora
de conjuntos y la lgica de predicados de primer orden. El hecho de que
el modelo relacional est basado en la teora de las matemticas es lo
que lo hace tan seguro y robusto. Al mismo tiempo, estas ramas de las
BASES DE DATOS MIS 308
2
matemticas proporcionan los elementos bsicos necesarios para crear
una base de datos relacional con una buena estructura, y proporcionan
las lneas que se utilizan para formular buenas metodologas de diseo.
Hay quien ofrece una cierta resistencia a estudiar complicados conceptos
matemticos para tan slo llevar a cabo una tarea bastante concreta. Es
habitual escuchar quejas sobre que las teoras matemticas en las que
se basa el modelo relacional y sus metodologas de diseo, no tienen
relevancia en el mundo real o que no son prcticas. No es cierto: las
matemticas son bsicas en el modelo relacional. Pero, por fortuna, no
hay que aprender teora de conjuntos o lgica de predicados de primer
orden para utilizar el modelo relacional. Sera como decir que hay que
saber todos los detalles de la aerodinmica para poder conducir un
automvil. Las teoras de la aerodinmica ayudan a entender cmo un
automvil puede ahorrar combustible, pero desde luego no son
necesarias para manejarlo.
La teora matemtica proporciona la base para el modelo relacional y, por
lo tanto, hace que el modelo sea predecible, fiable y seguro. La teora
describe los elementos bsicos que se utilizan para crear una base de
datos relacional y proporciona las lneas a seguir para construirla. El
organizar estos elementos para conseguir el resultado deseado es lo que
se denomina diseo.
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 DBMS.
El modelo relacional representa la segunda generacin de los DBMS. 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
DBMS de la primera generacin, lo que constituye otro punto a su favor.
BASES DE DATOS MIS 308
3
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:
o Estructura de datos.
o Integridad de datos.
o Manejo de datos.

4.1 Definicin del problema
La definicin del problema es el proceso por el que se determina la
organizacin de una base de datos, incluidos su estructura, contenido y
las aplicaciones que se han de desarrollar. Durante mucho tiempo, el
diseo de bases de datos fue considerado una tarea para expertos: ms
un arte que una ciencia. Sin embargo, se ha progresado mucho en el
diseo de bases de datos y ste se considera ahora una disciplina
estable, con mtodos y tcnicas propios. Debido a la creciente
aceptacin de las bases de datos por parte de la industria y el gobierno
en el plano comercial, y a una variedad de aplicaciones cientficas y
tcnicas, el diseo de bases de datos desempea un papel central en el
empleo de los recursos de informacin en la mayora de las
organizaciones. El diseo de bases de datos ha pasado a constituir parte
de la formacin general de los informticos, en el mismo nivel que la
capacidad de construir algoritmos usando un lenguaje de programacin
convencional
Para definir correctamente al Problema lo primero es realizar diseo
conceptual, que parte de las especificaciones de los requisitos del
usuario y su resultado es el esquema conceptual de la base de datos que
corresponder a un Modelo Entidad Relacin (E / R). Un esquema
conceptual es una descripcin de alto nivel de la estructura de la base de
datos, independientemente del DBMS que se vaya a utilizar para
manipularla. Un modelo conceptual es un lenguaje que se utiliza para
describir esquemas conceptuales. El objetivo del diseo conceptual es
describir el contenido de los Datos de la base de datos (DB) y no las
BASES DE DATOS MIS 308
4
estructuras de almacenamiento que se necesitarn para manejar esta
informacin.
El modelo relacional representa un sistema de bases de datos en un
nivel de abstraccin un tanto alejado de los detalles de la mquina
subyacente, de la misma manera como, por ejemplo, un lenguaje del tipo
de PL/1 representa un sistema de programacin con un nivel de
abstraccin un tanto alejado de los detalles de la mquina subyacente.
De hecho, el modelo relacional puede considerarse como un lenguaje de
programacin mas bien abstracto, orientado de manera especfica hacia
las aplicaciones de bases de datos [Date, 1993]
En trminos tradicionales una relacin se asemeja a un archivo, una
tupla a un registro, y un atributo a un campo. Pero estas
correspondencias son aproximadas, en el mejor de los casos. Una
relacin no debe considerase como ``solo un archivo'', sino mas bien
como un archivo disciplinado, siendo el resultado de esta disciplina una
simplificacin considerable de las estructuras de datos con las cuales
debe interactuar el usuario, lo cual a su vez simplifica los operadores
requeridos para manejar esas estructuras.
Caractersticas principales de los ``archivos'' relacionales:
Cada ``archivo'' contiene solo un tipo de registros
Los campos no tienen un orden especfico, de izquierda a derecha
Los registros no tienen un orden especfico, de arriba hacia abajo
Cada campo tiene un solo valor
Los registros poseen un campo identificador nico (o combinacin
de campos) llamado clave primaria
As, todos los datos en una base de datos relacional se representan de
una y solo una manera, a saber, por su valor explcito (esta se denomina
en ocasiones ``principio bsico del modelo relacional''). En particular, las
conexiones lgicas dentro de una relacin y entre las relaciones se
representan mediante esos valores; no existen ``ligas'' o apuntadores
visibles para el usuario, ni ordenamientos visibles para el usuario, ni
grupos repetitivos visibles para el usuario, etc.
Actualmente algunos de los manejadores de bases de datos, utilizan un
sistema de bsqueda con algoritmos de rboles b. Pero las bsquedas
que se pueden realizar con estos algoritmos son slo para memoria
principal.
Los algoritmos implementados para realizar bsquedas con listas
salteadas o por bloques (skip lists) son eficientes para realizar
bsquedas en memoria secundaria. Como tienen varios niveles en cada
BASES DE DATOS MIS 308
5
nodo de la lista, nos permite dar saltos mas largos al realizar las
bsquedas, esto provoca que las sean mas rpidas.

El primer paso para la definicin del Problema l diseo de una base de
datos es la produccin del esquema conceptual. Normalmente, se
construyen varios esquemas conceptuales, cada uno para representar
las distintas visiones que los usuarios tienen de la informacin. Cada una
de estas visiones suelen corresponder a las diferentes reas funcionales
de la empresa como, por ejemplo, produccin, ventas, recursos
humanos, etc.
A los esquemas conceptuales correspondientes a cada vista de usuario
se les denomina esquemas conceptuales locales. Cada uno de estos
esquemas se compone de entidades, relaciones, atributos, dominios de
atributos e identificadores. El esquema conceptual tambin tendr una
documentacin, que se ir produciendo durante su desarrollo. Las tareas
a realizar en el diseo conceptual son las siguientes:
1. Identificar las entidades.
2. Identificar las relaciones.
3. Identificar los atributos y asociarlos a entidades y relaciones.
4. Determinar los dominios de los atributos.
5. Determinar los identificadores.
6. Determinar las jerarquas de generalizacin (si las hay).
7. Dibujar el diagrama entidad-relacin.
8. Revisar el esquema conceptual local con el usuario
El modelo Entidad-Relacin (E/R) se basa en una representacin del
mundo real en que los datos se describen como entidades, relaciones y
atributos.
El principal concepto del modelo ER es la entidad, que es una "cosa" en
el mundo real con existencia independiente. Una entidad puede ser un
objeto fsico (una persona, un auto, una casa o un empleado) o un objeto
conceptual (una compaa, un puesto de trabajo o un curso universitario).
En nuestro ejemplo de la seccin anterior podemos definir dos entidades
alumnos y cursos.
Cada entidad tiene propiedades especficas, llamadas atributos, que la
describen. Por ejemplo, una sala de clases tiene un nombre, una
ubicacin, un cupo mximo, etc. En nuestro ejemplo, la entidad "alumno"
BASES DE DATOS MIS 308
6
posee los atributos nombre y matrcula. Una entidad particular tiene un
valor para cada uno de los atributos.
Cada uno de los atributos de una entidad posee un dominio, el que
corresponde al tipo del atributo. Por ejemplo, "matrcula" tiene como
dominio al conjunto de los enteros positivos y "nombre" tiene como
dominio al conjunto de caracteres.
Para todo conjunto de valores de una entidad, debe existir un atributo o
combinacin de atributos, que identifique a cada entidad en forma nica.
Este atributo o combinacin de atributos se denomina llave (primaria).
Por ejemplo, el nmero de matricula es una buena llave para la entidad
alumno, no as el nombre, porque pueden existir dos personas con el
mismo nombre.
Una relacin se puede definir como una asociacin entre entidades. Por
ejemplo, la entidad "libro" puede estar relacionada con la entidad
"persona" por medio de la relacin "est pedido". La entidad "alumno"
puede estar relacionada con la entidad "curso" por la relacin "est
inscrito". Una relacin tambin puede tener atributos. Por ejemplo, la
relacin "est inscrito" puede tener los atributos "semestre" y "nota de
aprobacin".

NOTA PARA VER BIEN EL DIAGRAMA PONER ZOOM A 150

Ejemplo:


DIAGRAMA FASES DISENO DB
BASES DE DATOS MIS 308
7
Suponga que estamos modelando los datos de una COMPAIA. La base
de datos COMPAIA debe mantener los Datos sobre los empleados de
la compaa, los departamentos y los proyectos. La descripcin del mini-
mundo (la parte de la compaa a ser representada en la base de datos)
es la siguiente:
1. La compaa est organizada en departamentos. Cada departamento
tiene un nombre nico. Un nmero nico, y un empleado particular quien
lo administra. Se quiere saber la fecha en que el empleado administrador
empez a hacerse cargo del departamento. Un departamento puede
tener varios locales.

2. Cada departamento controla un cierto nmero de proyectos. Cada
proyecto tiene un nombre y nmero nicos, y un local.

3. Para cada empleado se desea tener su nombre, rut, direccin, salario,
sexo y ao de nacimiento. Un empleado es asignado a un departamento,
pero puede trabajar en varios proyectos, los que no son necesariamente
controlados por el mismo departamento. Se quiere saber el nmero de
horas semanales que un empleado trabaja en cada proyecto. Se quiere
adems saber cul es el supervisor directo de cada empleado.

4. Se desea conocer las personas dependientes de cada empleado para
propsitos de seguros. De cada dependiente se desea conocer el
nombre, sexo, fecha de nacimiento y relacin con el empleado.
La siguiente figura muestra el esquema de esta base de datos, a travs
de una notacin grfica llamada diagrama ER.

BASES DE DATOS MIS 308
8

En este diagrama los rectngulos representan conjuntos de entidades,
las elipses representan atributos y los rombos representan conjuntos de
relaciones.

Usando esta notacin, podemos ahora hacer el diagrama E-R del
ejemplo anterior de los alumnos y los cursos matriculados.



Tipos de relaciones
Un tipo de relacin R entre n tipos de entidades E
1
, ..., E
n
define un
conjunto de asociaciones entre estos tipos.
BASES DE DATOS MIS 308
9

Puede ser visto como un conjunto de instancias de la relacin r
i
, donde
cada r
i
asocia n entidades (e
1
, ..., e
n
), y cada entidad e
j
en r
i
es un
miembro del tipo de entidad E
j
(1 <= j <= n).

Un tipo de relacin es un subconjunto del producto cartesiano E
1
x E
2
x ...
x.E
n
.

Ejemplo. Algunas instancias de la relacin TRABAJA_PARA del ejemplo
anterior, podran ser las siguientes.


Un tipo de relacin podra tambin interpretarse como un conjunto de
pares ordenados, en este caso: (e1, d1), (e2, d2), (e3, d1), (e4, d2), (e5,
d3), (e6, d1), (e7, d3).

Segn el nmero de entidades relacionadas (o razn de cardinalidad), se
pueden definir tres tipos de relaciones:
1. Relaciones Uno a Uno (1:1). Una entidad A est asociada a lo ms
con una entidad B, y una entidad B a lo ms con una entidad A. Ejemplo:
"Ser jefe de" es una relacin 1:1 entre las entidades empleado y
departamento.

2. Relaciones Uno a Muchos (1:n). Una entidad A est asociada con una
o varias entidades B. Una entidad B, sin embargo, puede estar a lo ms
asociada con una entidad A. Ejemplo: "Ser profesor" es una relacin 1:n
entre profesor y curso, suponiendo que un curso slo lo dicta un profesor.
BASES DE DATOS MIS 308
10

3. Relaciones Muchos a Muchos (n:m). Una entidad A est asociada con
una o varias entidades B, y una entidad B est asociada con una o varias
entidades A. Ejemplo: "Estar inscrito" es una relacin n:m entre las
entidades alumno y curso.
El siguiente es un ejemplo de la relacin ADMINISTRA, con participacin
parcial de EMPLEADOS, y participacin total de DEPARTAMENTOS.

La siguiente figura muestra un ejemplo de la relacin M:N
TRABAJA_PARA.

Tipos de atributos
BASES DE DATOS MIS 308
11
Los atributos compuestos se pueden dividir en sub-partes ms
pequeas, que representan atributos ms bsicos con significados
propios. Por ejemplo, una "direccin" puede sub-dividirse en: dir-calle,
comuna, ciudad, regin. Ejemplo:


Los atributos no sub-dividibles se llaman atmicos o simples. Si no hay
necesidad de referirse a los elementos individuales de una direccin,
entonces la direccin completa puede considerarse un atributo simple.

Atributos de valor simple son los que tienen un slo valor para una
entidad particular.
Por ejemplo: edad.
Atributos multivalorados pueden tener un conjunto de valores para una
misma entidad. Por ejemplo: "ttulos profesionales" (una persona puede
no tener ninguno, uno, dos o ms).

En algunos casos una entidad particular puede no tener valores
aplicables para un atributo. Ejemplo: "depto". Para estas situaciones
tenemos un valor especial llamado nulo. Tambin, si no se conoce el
valor.

Un tipo de entidad define un conjunto de entidades con los mismos
atributos.
Ejemplo:

Nombre del tipo de entidad: EMPLEADO
Atributos: Nombre, Edad, Sueldo
Conjunto de entidades: (Juan Prez, 55, 800.000), (Federico Pardo, 40,
550.000), (Rodrigo Pozo, 25, 400.000).

En los diagramas E-R, un tipo de entidad se representa como una caja
rectangular, los nombres de los atributos como elipses y las relaciones
BASES DE DATOS MIS 308
12
como rombos. Los atributos multivalorados se representan con elipses
dobles.

Un tipo de atributo usualmente tiene un atributo cuyos valores son
distintos para cada entidad individual (atributo clave o llave) y sus valores
se usan para identificar cada entidad unvocamente. Para una entidad
tipo PERSONA, un atributo clave tpico es el RUT. Algunas veces, varios
atributos juntos forman una clave (la combinacin debe ser distinta).
Estos atributos clave aparecen subrayados en los diagramas.

Cada atributo simple tiene un conjunto de valores o dominio asociado,
que especifica el conjunto de valores que puede asignarse a cada
entidad individual. Por ejemplo, si las edades de los empleados pueden
variar entre 16 y 70, entonces el dominio de Edad es {x N / 16 <= x <=
70}. Los dominios no se muestran en los diagramas.

Un atributo A del tipo de entidad E cuyo dominio es V, puede definirse
como una funcin de E al conjunto potencia V (conjunto de todos los
subconjuntos de V):
A: E <e> P(V)
El valor del atributo A para la entidad e es A(e). Un valor nulo se
representa por el conjunto vaco.

Para un atributo compuesto A, el dominio V es el producto cartesiano de
P(V
1
), ..., P(V
n
) donde V
1
, ..., V
n
son los dominios de los atributos simples
que forman A:
V = P(V
1
) x P(V
2
) x ... x P(V
n
).
Notemos que atributos compuestos y multivalorados pueden ser
anidados de cualquier manera. Podemos representar anidamiento
agrupando componentes de un atributo compuesto entre parntesis ( ),
separando componentes con comas, y mostrando atributos multivalor a
dos entre llaves {}.
Ejemplo: Si una persona puede tener ms de una direccin, y en cada
una de ellas hay mltiples telfonos, podemos especificar un atributo
DirTel para una PERSONA as:
{ DirTel ( { Telfono ( CdigoArea, NumTel ) }, Direccin ( DirCalle (
Calle, Nmero, NumDepto ), Comuna, Ciudad, Regin ) ) }
La persona Juan Prez puede tener una instancia de este atributo as:
{ DirTel ( { Telfono ( 2, 442-2855 ) }, Direccin ( DirCalle ( Blanco, 2120,
nulo ), Santiago, Santiago, RM ) ), DirTel ( { Telfono ( 2, 241-3416 ) },
BASES DE DATOS MIS 308
13
Direccin ( DirCalle ( Manuel Montt, 74, 201 ), Providencia, Santiago, RM
) ) }
Este modelo considera la Base de Datos (BD) como una coleccin de
relaciones. De manera simple, una relacin representa una tabla, en que
cada fila representa una coleccin de valores que describen una entidad
del mundo real. Cada fila se denomina tupla.
Dominios, tuplas, atributos, relaciones
Un dominio D es un conjunto de valores atmicos. Atmico quiere decir
que cada valor en el dominio es indivisible. Es til dar nombres a los
dominios. Ejemplo:Nmeros-telefnicos-locales: el conjunto de nmero
de telfono de 7 dgitos.
RUTs: nmeros de 8 dgitos ms un carcter que puede ser del 0 al 9 o K
Nombres: el conjunto de nombres de personas Notas: valores entre 1.0 y
7.0
Tambin se puede especificar un tipo de datos o formato para cada
dominio. Un esquema de relacin R, denotado R(A
1
, A
2
, ..., A
n
) est
constituido por un nombre de relacin R y una lista de atributos A
1
, ..., A
n
.
Cada atributo A
i
es el nombre de un rol jugado por el dominio D en el
esquema de la relacin R.

D se llama el dominio de A
i
y se denota dom(A
i
). Un esquema relacional
se usa para describir una relacin. R es el nombre de esta relacin. El
grado de una relacin es el nmero n de atributos del esquema de la
relacin.

Ejemplos:
ESTUDIANTE(Nombre, Rut, Telfono, Direccin, Edad, Carrera, Prom-
nota) tiene grado 7.
dom(Nombre) = Nombres
dom(Telfono) = Nmeros-telefnicos-locales
etc.
Def. Una relacin o instancia de relacin r del esquema de relacin R(A
1
,
A
2
, ..., A
n
), denotado tambin como r(R) es un conjunto de n-tuplas r = {t
1
,
t
2
, ..., t
m
}. Cada n-tupla t es una lista ordenada de n valores t = <v
1
, ...,
v
n
>, donde cada valor v
i
, i <= i <= n, es un elemento de dom(A
i
) o es un
valor nulo.

Ejemplo:
ESTUDIANT
E
Nombre Rut
Telfon
o
Direcci
n
Eda
d
Carrer
a
Prom
-nota
BASES DE DATOS MIS 308
14

Benjam
n
Gonzle
z
13.245.62
2-1
224-
4211
Rosas
3241
19
Plan
comn
4.8

Sergio
Soto
12.341.22
8-5
nulo
Gay214
2
20
Ing.
Ind.
5.1
... ... ... ... ... ... ...

Cada tupla representa una entidad de estudiante en particular. La
definicin de relacin puede replantearse as: Una relacin r(R) es un
subconjunto del producto cartesiano de los dominios que definen r:
r(R) <e> (dom(A
1
) x dom(A
2
) x ... x dom(A
n
))
El nmero total de tuplas en el producto cartesiano es:
|dom(A
1
)| * |dom(A
2
)| * ... * |dom(A
n
)|
Una instancia de relacin refleja slo las tuplas vlidas que representa un
estado particular del mundo real. A medida que el mundo real cambia,
tambin lo hace la relacin, transformndose en otro estado de relacin
(el esquema R es relativamente esttico y no cambia excepto muy pocas
veces).

Notacin
Un esquema de relacin R de grado n se denota R(A
1
, A
2
, ..., A
n
)

Una n-tupla t en una relacin r(R) se denota t = <v
1
, ..., v
2
>, donde v
i
es el
valor correspondiente del atributo A
i


t[A
i
] se refiere al valor v
i
en t para el atributo A
i


t[A
u
, A
w
, ..., A
z
] donde A
u
, A
w
, ..., A
z
es una lista de atributos de R, se
refiere a las subtuplas de valores <v
u
, v
w
, ..., v
z
> de t correspondientes a
los atributos especificados en la lista

Las letras Q, R, S denotan nombres de relacin

Las letras q, r, s denotan estados de relacin

Las letras t, u, v denotan tuplas

Los nombres de atributos se califican con el nombre de relacin a la cual
pertenecen. Por ejemplo, ESTUDIANTE.Nombre o ESTUDIANTE.Edad
BASES DE DATOS MIS 308
15

Para la tupla t = <Benjamn Gonzlez, 13.245.622-1, 224-4211, Rosas
3241, 19, Plan comn, 4.8>, tenemos t[Nombre] = <Benjamn Gonzlez>,
t[Rut, Prom-notas, Edad] = <13.245.622-1, 4.8, 19>
Restricciones
Las restricciones de dominios especifican que el valor de cada atributo A
debe ser un valor atmico del dominio dom(A).

Una relacin se define como un conjunto de tuplas. Por definicin todos
los elementos de un conjunto son distintos. Luego todas las tuplas de
una relacin deben ser distintas. Esto implica que dos tuplas no pueden
tener la misma combinacin de valores para todos sus atributos. Pero
puede haber otros subconjuntos de atributos de un esquema de relacin
R con la propiedad de que no haya dos tuplas en una instancia de
relacin r de R que tengan la misma combinacin de valores para esos
atributos. Supongamos que denotamos tal subconjunto de atributos por
SC. Entonces para cada dos tuplas distintas t1 y t2 en una instancia de
relacin r de R, tenemos la restriccin:
t1[SC] <e> t2[SC]
Cualquier conjunto de atributos SC es denominado super llave del
esquema de relacin R. Cada relacin tiene al menos una super llave (el
conjunto de todos sus atributos). Una llave o clave K de un esquema de
relacin R es una sper llave de R con la propiedad adicional de que al
sacar cualquier atributo A de K deja un conjunto de atributos K' que no es
sper llave de R (una clave es una sper llave mnima).

El valor de un atributo clave se usa para identificar unvocamente una
tupla en una relacin. El hecho que un conjunto de atributos constituya
una clase es una propiedad del esquema de la relacin, y es invariante
en el tiempo.

En general, un esquema de relacin puede tener ms de una clave, y en
ese caso, cada una de las llaves es una llave candidata. Una de las
llaves candidatas se designa como llave primaria de la relacin. Usamos
la convencin de que los atributos que forman la llave primaria de un
esquema de relacin se subrayan.


Base de datos relacional
BASES DE DATOS MIS 308
16
Un esquema de Base de Datos (DB) relacional es un conjunto de
esquemas de relacin S = (R
1
, R
2
, ..., R
m
) y un conjunto RI de
restricciones de integridad.
Una instancia de DB relacional DB de S es un conjunto de instancias de
relacin DB = {r
1
, ..., r
n
} tal que cada r
i
es una instancia de R
i
y tal que las
relaciones r
i
satisfacen las restricciones de integridad especificadas en
RI.

Ejemplo:

EMPLEADO
NPIL
A
APP
AT
APM
AT
RU
T
FNA
C
DIRECCI
ON
SEX
O
SUEL
DO
RUTSUPE
RV
NDEP
TO

DEPARTAMENTO
DNOMBRE DNUMERO RUTGERENTE GERFECHAINIC

UBICACIONES_DEPTO
DNUMERO DUBICACION

PROYECTO
PNOMBRE PNUMERO PUBICACION DNUM

TRABAJA_EN
ERUT PNO HORAS

CARGA
ERUT NOMBRE_CARGA SEXO FNAC PARENTESCO


Los siguientes datos corresponden a una instancia de la base de datos.
EMPLE
ADO
NPIL
A
APP
AT
APM
AT
RUT
FN
AC
DIREC
CION
SE
XO
SUE
LDO
RUTSU
PERV
NDE
PTO
BASES DE DATOS MIS 308
17
Juan
Pr
ez
Garc
a
1234
5678
9-
1-
55
Toesca
965
M 120
333445
55
5
Alicia
Zela
ya
Roa
9998
8777
19-
7-
58
Blanco
2120
F 105
987654
32
4

Juan
a
Bes
a
Mart
nez
9876
5432
20-
6-
31
Mapoc
ho
2540
F 240
888665
55
4

Franc
isco
Cea Daza
3334
4555
8-
12-
45
Condell
221
M 310
888665
55
5
Jaime
Ra
mos
Sala
s
8886
6555
10-
11-
30
Vitacur
a 1015
M 360 nulo 1

DEPARTAMENT
O
DNOMBRE
DNUMER
O
RUTGERENT
E
GERFECHAINI
C
Of. Central 1 88866555 19-6-71

Administraci
n
4 98765432 1-1-85
Investigacin 5 33344555 22-5-78

UBICACIONES_DEPTO DNUMERO DUBICACION
1 Providencia
4 uoa
5 La Florida
5 Pirque

PROYECTO PNOMBRE PNUMERO PUBICACION DNUM
BASES DE DATOS MIS 308
18
Producto X 1 La Florida 5
Producto Y 2 Pirque 5
Computarizacin 10 uoa 4
Reorganizacin 20 Providencia 1

TRABAJA_EN ERUT PNO HORAS
12345678 1 32.5
12345678 2 7.5
33344555 2 10.0
99988777 10 10.0
98765432 10 10.0
98765432 20 15.0
88866555 20 nulo

CARGA ERUT NOMBRE_CARGA SEXO FNAC PARENTESCO
33344555 Alicia F 5-4-86 Hija
33344555 Teodoro M 25-10-83 Hijo
33344555 Ximena F 3-5-54 Cnyuge
98765432 Rodolfo M 28-2-32 Cnyuge
12345678 Alicia F 5-5-57 cnyuge


Observemos que DNUMERO es el mismo para DEPARTAMENTO y
PROYECTO. Pero el mismo concepto se llama DNO en EMPLEADO y
DNUM en PROYECTO No hay problema.
La restriccin de integridad de entidad establece que ningn valor de
llave primaria puede ser nulo. Esto es porque ellas identifican tuplas de la
relacin.
BASES DE DATOS MIS 308
19

La restriccin de integridad referencial se especifica entre dos relaciones
y se usa para mantener la consistencia entre tuplas de las dos
relaciones. Informalmente, una tupla en una relacin que hace referencia
a otra relacin debe referirse a una tupla existente en esa relacin. Por
ejemplo, NDEPTO de EMPLEADO debe coincidir con el DNUMERO de
alguna tupla de la relacin DEPARTAMENTO. Para una definicin
formal, necesitamos el concepto de llave fornea.
Def. Un conjunto de atributos LF en el esquema de relacin R
1
es una
llave fornea de R
1
si satisface las siguientes reglas:
1. Los atributos en LF tienen el mismo dominio que los atributos de la
llave primaria LP de otro esquema de relacin R
2
. Los atributos LF se
dicequereferencianlarelacinR
2
.

2. Un valor de LF en una tulpa t
1
de R
1
ya sea es nulo, o ocurre como un
valor de LP para alguna tupla t
2
de R
2
.
Ejemplo: NDEPTO en una tupla t
1
de EMPLEADO debe coincidir con el
valor de una llave primaria DNUMERO en alguna tupla t
2
de la relacin
DEPARTAMENTO, o el valor de DNO puede ser nulo si el empleado no
pertenece a un departamento.
Las restricciones anteriores no consideran las restricciones semnticas
que quizs puedan especificarse y sostenerse en una BD relacional. Por
ejemplo, "el sueldo de un empleado no puede exceder el de su
supervisor", "el nmero mximo de horas que puede trabajar un
empleado en todos los proyectos es 56".
Operaciones de actualizacin
La operacin Insert provee una lista de valores de atributos para una
nueva tupla t que se va a insertar en una relacin R. Ejemplo:

Insert <"Cecilia", "Rodrguez", "Kolonsky", "67767898", "5-4-50", "Ejrcito
565", "F", 100, nulo, "4"> en EMPLEADO. Esta insercin satisface todas
las restricciones, as que es aceptable.

Insert <"Alicia", "Zelaya", "Roa", "99988777", "15-3-50", "Gay 1315", "F",
120, "98765432", "4"> en EMPLEADO. Viola la restriccin de clave
porque otra tupla con el mismo Rut ya existe en la relacin. Inaceptable.

Insert <"Cecilia", "Rodrguez", "Kolonsky", nulo, "5-4-50", "Ejrcito 565",
"F", 100, nulo, 4> en EMPLEADO. Viola la restriccin de integridad (nulo
para clave primaria Rut). Inaceptable.

Insert <"Cecilia", "Rodrguez", "Kolonsky", "67767898", "5-4-50", "Ejrcito
BASES DE DATOS MIS 308
20
565", "F", 100, "98765432", 7> en EMPLEADO. Viola la restriccin de
integridad referencial porque no existe una tupla en DEPARTAMENTO
con DNUMERO = 7.

El DBMS puede hacer dos opciones cuando hay violacin de
restricciones. Una es rechazar la insercin. La otra es intentar corregir la
razn de rechazo de la insercin.
Operaciones de borrado
La operacin Delete borra tuplas de una relacin. Es posible que se viole
la integridad referencial cuando una tupla que se quiere borrar es
referenciada por las llaves forneas de otras tuplas de la BD. Las tuplas
a borrar se especifican a travs de condiciones sobre los atributos de la
relacin. Ejemplos:

Delete tupla con ERUT = "99988777" AND PNO = 10 en la relacin
TRABAJA_EN. Esta operacin es aceptable.

Delete tupla con RUT = "99988777" en la relacin EMPLEADO.
Inaceptable porque dos tuplas en TRABAJA_EN se refieren a esta tupla.
Si se borra, hay violaciones a la integridad referencial.

Hay tres opciones con respecto a una operacin de borrado que causa
una violacin. La primera es rechazar la operacin. La segunda es
intentar propagar el borrado. Una tercera opcin es modificar los valores
de los atributos referenciantes que causan la violacin (cada uno de
estos valores puede ser puesto en nulo o cambiado para referenciar otra
tupla vlida). Hay que observar que si un atributo referenciante que
causa una violacin, es parte de la llave primaria, no puede ser nulo,
pues se violara la integridad de entidad.
Operaciones de modificacin
La operacin Modify se usa para cambiar valores a uno o ms atributos
en una tupla (o tuplas) de una relacin R. Es necesario especificar una
condicin sobre los atributos de R para seleccionar la o las tuplas a
modificar. Ejemplos:
Modify SUELDO de la tupla de EMPLEADO con RUT = "99988777" a
135.
Aceptable.

Modify NDEPTO de la tupla de EMPLEADO con RUT = "99988777" a 1.
Aceptable.

BASES DE DATOS MIS 308
21
Modify NDEPTO de la tupla de EMPLEADO con RUT = "99988777" a 7.
Inaceptable pues viola la integridad referencial.
Modify RUT de la tupla de EMPLEADO con RUT = "99988777" a
"98765432". Inaceptable pues viola restricciones de clave primaria e
integridad-referencial.

El modificar un atributo que no es llave primaria ni llave fornea no tiene
problemas. El modificar una llave primaria es similar a borrar una tupla e
insertar otra en su lugar. Por tanto, es relevante la discusin anterior
(Insert y Delete). Si se modifica un atributo de una llave fornea, el
Sistema Administrador de Base de Datos ( DBMS ) debe asegurarse que
el nuevo valor se refiere a una tupla existente en la relacin referenciada.
Terminologa relacional equivalente


Trabajo (Cdigo, Nombre, Posicin, Salario), donde Cdigo es la Clave
Primaria
Relacin = tabla o archivo
Tupla = registro, fila o rengln
Atributo = columna o campo
Clave = llave o cdigo de identificacin
Clave Candidata = superclave mnima
Clave Primaria = clave candidata elegida
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.
BASES DE DATOS MIS 308
22
1FN = Significa, Primera Forma Normal o 1NF del ingls 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.
Todo atributo en una tabla tiene un dominio, el cual representa el
conjunto de valores que el mismo puede tomar. Una instancia de una
tabla puede verse entonces como un subconjunto del producto
cartesiano entre los dominios de los atributos. Sin embargo, suele haber
algunas diferencias con la analoga matemtica, dado que algunos
RDBMS permiten filas duplicadas, entre otras cosas. Finalmente, una
tupla puede razonarse matemticamente como un elemento del producto
cartesiano entre los dominios.

4.2 Solucin de problemas
Redundancia e inconsistencia de datos.
Puesto que los archivos que mantienen almacenada la informacin son
creados por diferentes tipos de programas de aplicacin existe la
posibilidad de que si no se controla detalladamente el almacenamiento,
se pueda originar un duplicado de informacin, es decir que la misma
informacin sea ms de una vez en un dispositivo de almacenamiento.
Esto aumenta los costos de almacenamiento y acceso a los datos,
adems de que puede originar la inconsistencia de los datos - es decir
diversas copias de un mismo dato no concuerdan entre si -, por ejemplo:
que se actualiza la direccin de un cliente en un archivo y que en otros
archivos permanezca la anterior.
Dificultad para tener acceso a los datos.
Un sistema de base de datos debe contemplar un entorno de datos
que le facilite al usuario el manejo de los mismos. Supngase un banco,
y que uno de los gerentes necesita averiguar los nombres de todos los
clientes que viven dentro del cdigo postal 78733 de la ciudad. El gerente
pide al departamento de procesamiento de datos que genere la lista
correspondiente. Puesto que esta situacin no fue prevista en el diseo
del sistema, no existe ninguna aplicacin de consulta que permita este
tipo de solicitud, esto ocasiona una deficiencia del sistema.
Aislamiento de los datos.
Puesto que los datos estn repartidos en varios archivos, y estos no
pueden tener diferentes formatos, es difcil escribir nuevos programas de
aplicacin para obtener los datos apropiados.
Anomalas del acceso concurrente.
BASES DE DATOS MIS 308
23
Para mejorar el funcionamiento global del sistema y obtener un tiempo
de respuesta ms rpido, muchos sistemas permiten que mltiples
usuarios actualicen los datos simultneamente. En un entorno as la
interaccin de actualizaciones concurrentes puede dar por resultado
datos inconsistentes. Para prevenir esta posibilidad debe mantenerse
alguna forma de supervisin en el sistema.
Problemas de seguridad.
La informacin de toda empresa es importante, aunque unos datos lo
son ms que otros, por tal motivo se debe considerar el control de
acceso a los mismos, no todos los usuarios pueden visualizar alguna
informacin, por tal motivo para que un sistema de base de datos sea
confiable debe mantener un grado de seguridad que garantice la
autentificacin y proteccin de los datos. En un banco por ejemplo, el
personal de nminas slo necesita ver la parte de la base de datos que
tiene informacin acerca de los distintos empleados del banco y no a otro
tipo de informacin.
Problemas de integridad.
Los valores de datos almacenados en la base de datos deben
satisfacer cierto tipo de restricciones de consistencia. Estas restricciones
se hacen cumplir en el sistema aadiendo cdigos apropiados en los
diversos programas de aplicacin.

Lo anterior es originado por:
Redundancia
Anomalas
o Actualizacin
o Insercin
o Borrado
Creadas durante:
Mantenimiento
Creacin
Modificacin


BASES DE DATOS MIS 308
24
Donde la Solucin es:
Normalizacin

4.3 Normalizacin: 1NF, 2NF, 3FN, BCNF
Si nunca antes hemos odo hablar de la "normalizacin de datos", no
debemos temer. Mientras que la normalizacin puede parecer un tema
complicado, nos podemos beneficiar ampliamente al entender los
conceptos ms elementales de la normalizacin.
Una de las formas ms fciles de entender esto es pensar en nuestras
tablas como hojas de clculo. Por ejemplo, si quisiramos seguir la pista
de nuestra coleccin de CDs en una hoja de clculo, podramos disear
algo parecido a lo que se muestra en la siguiente tabla.

+------------+-------------+--------------+ .. +--------------+
| lbum | track1 | track2 | | track10 |
+------------+-------------+--------------+ .. +--------------+

Esto parece razonable. Sin embargo el problema es que el nmero de
pistas que tiene un CD vara bastante. Esto significa que con este
mtodo tendramos que tener una hoja de clculo realmente grande para
albergar todos los datos, que en los peores casos podran ser de hasta
20 pistas. Esto en definitiva no es nada bueno.
Uno de los objetivos de una estructura de tabla normalizada es minimizar
el nmero de "celdas vacas". El darnos cuenta de que cada lista de CDs
tiene un conjunto fijo de campos (ttulo, artista, ao, gnero) y un
conjunto variable de atributos (el nmero de pistas) nos da una idea de
cmo dividir los datos en mltiples tablas que luego podamos relacionar
entre s.
Mucha gente no esta familiarizada con el concepto "relacional", de
manera sencilla esto significa, que grupos parecidos de informacin son
almacenados en distintas tablas que luego pueden ser "juntadas"
(relacionadas) basndose en los datos que tengan en comn.
Es necesario que al realizar la estructura de una base de datos, esta sea
flexible. La flexibilidad est en el hecho que podemos agregar datos al
sistema posteriormente sin tener que rescribir lo que ya tenemos. Por
ejemplo, si quisiramos agregar la informacin de los artistas de cada
lbum, lo nico que tenemos que hacer es crear una tabla artista que
BASES DE DATOS MIS 308
25
est relacionada a la tabla lbum de la misma manera que la tabla pista.
Por lo tanto, no tendremos que modificar la estructura de nuestras tablas
actuales, simplemente agregar la que hace falta.
La eficiencia se refiere al hecho de que no tenemos duplicacin de datos,
y tampoco tenemos grandes cantidades de "celdas vacas".
El objetivo principal del diseo de bases de datos es generar tablas que
modelan los registros en los que guardaremos nuestra informacin.
Es importante que esta informacin se almacene sin redundancia para
que se pueda tener una recuperacin rpida y eficiente de los datos.
A travs de la normalizacin tratamos de evitar ciertos defectos que nos
conduzcan a un mal diseo y que lleven a un procesamiento menos
eficaz de los datos.
Podramos decir que estos son los principales objetivos de la
normalizacin:
Controlar la redundancia de la informacin.
Evitar prdidas de informacin.
Capacidad para representar toda la informacin.
Mantener la consistencia de los datos.
La normalizacin es una tcnica para disear la estructura lgica de los
datos de un sistema de informacin en el modelo relacional, desarrollada
por E. F. Codd en 1972. Es una estrategia de diseo de abajo a arriba:
se parte de los atributos y stos se van agrupando en relaciones (tablas)
segn su afinidad. Aqu no se utilizar la normalizacin como una tcnica
de diseo de bases de datos, sino como una etapa posterior a la
correspondencia entre el esquema conceptual y el esquema lgico, que
elimine las dependencias entre atributos no deseadas. Las ventajas de la
normalizacin son las siguientes:
Evita anomalas en inserciones, modificaciones y borrados.
Mejora la independencia de datos.
No establece restricciones artificiales en la estructura de los datos.
Uno de los conceptos fundamentales en la normalizacin es el de
dependencia funcional. Una dependencia funcional es una relacin entre
atributos de una misma relacin (tabla). Si e son atributos de la
relacin , se dice que es funcionalmente dependiente de (se denota
por ) si cada valor de tiene asociado un solo valor de ( e
BASES DE DATOS MIS 308
26
pueden constar de uno o varios atributos). A se le denomina
determinante, ya que determina el valor de . Se dice que el atributo
es completamente dependiente de si depende funcionalmente de y
no depende de ningn subconjunto de .
La dependencia funcional es una nocin semntica. Si hay o no
dependencias funcionales entre atributos no lo determina una serie
abstracta de reglas, sino, ms bien, los modelos mentales del usuario y
las reglas de negocio de la organizacin o empresa para la que se
desarrolla el sistema de informacin. Cada dependencia funcional es una
clase especial de regla de integridad y representa una relacin de uno a
muchos.
En el proceso de normalizacin se debe ir comprobando que cada
relacin (tabla) cumple una serie de reglas que se basan en la clave
primaria y las dependencias funcionales. Cada regla que se cumple
aumenta el grado de normalizacin. Si una regla no se cumple, la
relacin se debe descomponer en varias relaciones que s la cumplan.
La normalizacin se lleva a cabo en una serie pasos. Cada paso
corresponde a una forma normal que tiene unas propiedades. Conforme
se va avanzando en la normalizacin, las relaciones tienen un formato
ms estricto (ms fuerte) y, por lo tanto, son menos vulnerables a las
anomalas de actualizacin. El modelo relacional slo requiere un
conjunto de relaciones en primera forma normal. Las restantes formas
normales son opcionales. Sin embargo, para evitar las anomalas de
actualizacin, es recomendable llegar al menos a la tercera forma
normal.
Uno de los retos en el diseo de la base de datos es el de obtener una
estructura estable y lgica tal que:
1. El sistema de base de datos no sufra de anomalas de
almacenamiento.
2. El modelo lgico pueda modificarse fcilmente para admitir nuevos
requerimientos.
Una base de datos implantada sobre un modelo bien diseado tiene
mayor esperanza de vida aun en un ambiente dinmico, que una base de
datos con un diseo pobre. En promedio, una base de datos experimenta
una reorganizacin general cada seis aos, dependiendo de lo dinmico
de los requerimientos de los usuarios. Una base de datos bien diseada
tendr un buen desempeo aunque aumente su tamao, y ser lo
suficientemente flexible para incorporar nuevos requerimientos o
caractersticas adicionales.
BASES DE DATOS MIS 308
27
Existen diversos riesgos en el diseo de las bases de datos relacionales
que afecten la funcionalidad de la misma, los riesgos generalmente son
la redundancia de informacin y la inconsistencia de datos.
La normalizacin es el proceso de simplificar la relacin entre los campos
de un registro.

Por medio de la normalizacin un conjunto de datos en un registro se
reemplaza por varios registros que son ms simples y predecibles y, por
lo tanto, ms manejables. La normalizacin se lleva a cabo por cuatro
razones:
Estructurar los datos de forma que se puedan representar las
relaciones pertinentes entre los datos.
Permitir la recuperacin sencilla de los datos en respuesta a las
solicitudes de consultas y reportes.
Simplificar el mantenimiento de los datos actualizndolos,
insertndolos y borrndolos.
Reducir la necesidad de reestructurar o reorganizar los datos
cuando surjan nuevas aplicaciones.
En trminos ms sencillos la normalizacin trata de simplificar el diseo
de una base de datos, esto a travs de la bsqueda de la mejor
estructuracin que pueda utilizarse con las entidades involucradas en
ella.
Pasos de la normalizacin:
1. Descomponer todos los grupos de datos en registros
bidimensionales.
2. Eliminar todas las relaciones en la que los datos no dependan
completamente de la llave primaria del registro.
3. Eliminar todas las relaciones que contengan dependencias
transitivas.
La teora de normalizacin tiene como fundamento el concepto de formas
normales; se dice que una relacin est en una determinada forma
normal si satisface un conjunto de restricciones.
Primera y segunda formas normales.
Formas normales.
BASES DE DATOS MIS 308
28
Son las tcnicas para prevenir las anomalas en las tablas. Dependiendo
de su estructura, una tabla puede estar en primera forma normal,
segunda forma normal o en cualquier otra.
Relacin entre las formas normales:

Primera forma normal.
Definicin formal:
Una relacin R se encuentra en 1FN si y solo s por cada rengln
columna contiene valores 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.
Para ejemplificar como se representan grficamente las relaciones en
primera forma normal consideremos la relacin alumno cursa materia
cuyo diagrama E-R es el siguiente:
BASES DE DATOS MIS 308
29



Como esta relacin maneja valores atmicos, es decir un solo valor por
cada uno de los campos que conforman a los atributos de las entidades,
ya se encuentra en primera forma normal, grficamente as
representamos a las relaciones en 1FN.
Segunda forma normal.
Para definir formalmente la segunda forma normal requerimos saber que
es una dependencia funcional: Consiste en edificar que atributos
dependen de otro(s) atributo(s).

Definicin formal:

Una relacin R est en 2FN si y solo si est en 1FN y los atributos no
primos dependen funcionalmente de la llave primaria.
Una relacin se encuentra en segunda forma normal, cuando cumple con
las reglas de la primera forma normal y todos sus atributos que no son
claves (llaves) dependen por completo de la clave. De acuerdo con est
definicin, cada tabla que tiene un atributo nico como clave, esta en
segunda forma normal.
La segunda forma normal se representa por dependencias funcionales
como:

Ntese que las llaves primarias estn representadas con doble cuadro,
las flechas nos indican que de estos atributos se puede referenciar a los
otros atributos que dependen funcionalmente de la llave primaria.
BASES DE DATOS MIS 308
30
Tercera forma normal y la forma normal de Boyce Codd.

Para definir formalmente la 3FN necesitamos definir dependencia
transitiva: En una afinidad (tabla bidimensional) que tiene por lo menos
3 atributos (A,B,C) en donde A determina a B, B determina a C pero no
determina a A.
Tercera forma normal.

Definicin formal:

Una relacin R est en 3FN si y solo si esta en 2FN y todos sus atributos
no primos dependen no transitivamente de la llave primaria.
Consiste en eliminar la dependencia transitiva que queda en una
segunda forma normal, en pocas palabras una relacin esta en tercera
forma normal si est en segunda forma normal y no existen
dependencias transitivas entre los atributos, nos referimos a
dependencias transitivas cuando existe ms de una forma de llegar a
referencias a un atributo de una relacin.
Por ejemplo, consideremos el siguiente caso:


Tenemos la relacin alumno-cursa-materia manejada anteriormente, pero
ahora consideramos al elemento maestro, grficamente lo podemos
representar de la siguiente manera:
BASES DE DATOS MIS 308
31



Podemos darnos cuenta que se encuentra graficado en segunda forma
normal, es decir que todos los atributos llave estn indicados en doble
cuadro indicando los atributos que dependen de dichas llaves, sin
embargo en la llave Necono tiene como dependientes a 3 atributos en el
cual el nombre puede ser referenciado por dos atributos: Necono y RFC
(Existe dependencia transitiva), podemos solucionar esto aplicando la
tercera forma normal que consiste en eliminar estas dependencias
separando los atributos, entonces tenemos:



Forma normal de Boyce Codd.

Determinante: Uno o ms atributos que, de manera funcional,
determinan otro atributo o atributos. En la dependencia funcional (A,B)--
>C, (A,B) son los determinantes.

Definicin formal:

Una relacin R esta en FNBC si y solo si cada determinante es una llave
candidato.
BASES DE DATOS MIS 308
32
Denominada por sus siglas en ingles como BCNF; Una tabla se
considera en esta forma si y slo s cada determinante o atributo es una
llave candidato.
Continuando con el ejemplo anterior, si consideramos que en la entidad
alumno sus atributos control y nombre nos puede hacer referencia al
atributo esp., entonces decimos que dichos atributos pueden ser llaves
candidato.
Grficamente podemos representar la forma normal de Boyce Codd de
la siguiente forma:


Obsrvese que a diferencia de la tercera forma normal, agrupamos todas
las llaves candidato para formar una global (representadas en el
recuadro) las cuales hacen referencia a los atributos que no son llaves
candidato.

4.4 Criterios para normalizar
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 ste public 12 reglas que un verdadero sistema
relacional debera tener, en la prctica algunas de ellas son difciles de
realizar. Un sistema podr considerarse "ms relacional" cuanto ms siga
estas reglas.
Regla No. 1 - La Regla de la informacin
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
BASES DE DATOS MIS 308
33
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 No. 2 - La regla del acceso garantizado
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 No. 3 - Tratamiento sistemtico de los valores nulos
La informacin inaplicable o faltante puede ser representada a travs de
valores nulos.
Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser
capaz de soportar el uso de valores nulos en el lugar de columnas cuyos
valores sean desconocidos o inaplicables.
Regla No. 4 - La regla de la descripcin de la base de datos
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 (o similar).
Regla No. 5 - La regla del sub-lenguaje Integral
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 No. 6 - La regla de la actualizacin de vistas
BASES DE DATOS MIS 308
34
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 No. 7 - La regla de insertar y actualizar
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 para leer, escribir, eliminar y agregar
registros (SELECT, UPDATE, DELETE e INSERT en SQL) deben estar
disponibles y operables, independientemente del tipo de relaciones y
restricciones que haya entre las tablas.


Regla No. 8 - La regla de independencia fsica
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 No. 9 - La regla de independencia lgica
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 No. 10 - La regla de la independencia de la integridad
Todas las restricciones de integridad deben ser definibles en los datos, y
almacenables en el catalogo, no en el programa de aplicacin.
BASES DE DATOS MIS 308
35
Las reglas de integridad
1. Ningn componente de una clave primaria puede tener valores en
blanco o nulos. (esta es la norma bsica de integridad).
2. Para cada valor de clave fornea deber existir un valor de clave
primaria concordante. La combinacin de estas reglas aseguran que
haya Integridad referencial.
Regla No. 11 - La regla de la distribucin
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 No. 12 - Regla de la no-subversin
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.

También podría gustarte