BASES DE DATOS

Modelos de Datos
Sistemas Administradores (Gestores) de Bases de Datos (SGBDs o
DBMS's)

Modelos de Datos
Hablar del concepto lgico o fsico de Base de Datos involucra un conjunto de
pensamientos concretos que hacen posible la absorcin temtica del
significado de los datos. La abstraccin de los datos como una forma o un
comportamiento que hace posible concretar un algo, se asocia con un
esquema del conocimiento lgico, su semntica, condiciones y acciones, que
permiten la produccin de modelos por medio de los cuales se representa la
funcionalidad de un sistema.
Inicialmente el "dato" fue trabajado desde la ptica pura de su almacenamiento
a travs de los "Sistemas de Archivos"; donde cada uno de los archivos que se
creaban solo obedecan a una necesidad de almacenamiento ms que a la
utilizacin funcional del dato. Por este motivo surgen los esquemas
conceptuales que son elaborados a travs del anlisis de procesos de las
reas del negocio, los cuales involucran al "dato" como una consecuencia
lgica funcional de ellos. Pero para poder estandarizar este tratamiento se crea
el concepto del "Modelo de Datos", por medio del cual se definen un conjunto
de elementos y smbolos que permiten estandarizar traducir dicho anlisis a un
lenguaje semntico y sistemtico que dispone de reglas de control y evaluacin
del comportamiento del dato en el transcurso del tiempo, tanto en su
almacenamiento como en su utilizacin.
Estos modelos de datos, hacen posible que la lgica de un negocio pueda ser
estructurada de forma tangible a travs de un esquema fsico que representa
el almacenamiento de los datos bajo las reglas del negocio y de un sistema
gestor de base de datos que permitir la persistencia de estos a travs del
tiempo.
Los Modelos de Datos, tambin llamados modelos lgicos, se han clasificado
en dos grandes grupos debido al tratamiento de los datos: Basados en Objetos
y basados en Registros. Estos dos grupos de modelos representan dos
estados de la interpretacin de los requerimientos de usuario:

Basados en Objetos: Un problema de la vida real maneja concepciones

abstractas o concretas, tangibles o intangibles, a las cuales se les ha
dado el nombre de "objetos", calificados a partir de un valor significativo
dentro de los parmetros de una forma o estilo de vida; dichos objetos
se modelan a travs de propuestas que fueron estructuradas para as
poder estandarizar la forma de manipularlos. Dentro de estos modelos
tenemos:

o
o
o
o

Modelo Entidad Relacin (MER)

Modelo Orientado a Objetos (MOO)
Modelo Semntico
Modelo Deductivo

Basados en Registros: Otra forma de tratar lgicamente la informacin

suministrada por un sistema es a travs de los "Registros", originalmente
concebidos por los sistemas de archivos (registro: conjunto de campos
que almacenan informacin de diferentes tipos), lo cual di pie a la
estructuracin de modelos lgicos tales como:
o
o
o

Modelo Relacional (MR)

Modelo de Red
Modelo Jerarquico

Al modelar es importante conocer muy bien la semntica de estos modelos y lo

que es posible lograr con ellos.
En la Ingeniera de Software, el tratamiento de los datos Las Bases de Datos
dentro del ciclo de vida de un proyecto informtico, estn ubicadas dentro del
proceso del Diseo, "el CMO", estructurar la funcionalidad expuesta en los
requerimientos. El siguiente esquema escenifica esta situacin:

_________

Sistemas Administradores (Gestores) de Bases de Datos

Una vez terminado el diseo lgico a travs de modelos basados en registros, se da
inicio al diseo fsico de la base de datos. Para esto es muy importante conocer los
Sistemas Administradores de Bases de Datos (DBMS: Database Managment Systems)
los cuales permiten almacenar y controlar los datos a la vez, por medio de lenguajes
propios de estos. Diferentes DBMS se especializaron en la utilizacin de Modelos de
Datos especficos como es el caso de los RDBMS que trabajan con el Modelo
Relacional, los ORDBMS que trabaja con el Modelo Relacional Extendido y algunos
elementos del paradigma orientado a objetos, y por ltimo se encuentran los OODBMS
que trabajan con el Modelo Orientado a Objetos.

DISEO CONCEPTUAL
Cuando se trabaja bajo el anlisis conceptual de una situacin, nos referimos a la
abstraccin de hechos reales de los cuales se emite un concepto o es posible hacer una
idea de ello. Para poder realizar la abstraccin de un tema en un rea especfica, a nivel
informtico, es necesario tener los requerimientos formulados por los usuarios con
respecto a este. Estos requerimientos contienen el conjunto de hechos y reglas que dan
pauta a la creacin del esquema conceptual donde por medio de este se podr realizar
una descripcin de alto nivel de la futura base de datos. Para manipular este esquema se
utiliza un modelo conceptual que proporciona un lenguaje que permite utilizar un
conjunto de smbolos (estndares) para la creacin de este.
El diseo conceptual se hace independiente al sistema gestor de base de datos (DBMS)
que utilice el usuario para la implementacin de esta.
Para modelar Conceptualmente es posible utilizar varios Modelos de Datos Un modelo
prctico para ilustrar el diseo conceptual es el modelo entidad relacin.

Modelo Entidad Relacin (MER)

Diseado por Chen en 1976, maneja los siguientes conceptos:

Conceptos del MER:

ENTIDADES: Una entidad es una "cosa" u "objeto" del mundo real, con existencia
independiente y distinguible de los dems objetos. Cada entidad tiene un conjunto de
propiedades y valores que la identifican de forma unvoca. Esta puede ser tanto tangible
(existencia fsica), ejemplo: Un carro, como intangible (existencia conceptual),
ejemplo: Un curso universitario.
ATRIBUTOS: Las propiedades que califican y le dan vida a la entidad se denominan
atributos. Ejemplo: la entidad persona se puede describir por las siguientes propiedades:
cdula, nombre, direccin, sexo, peso, altura, color, tipo de sangre, salario.
Cada entidad tendr un valor por cada uno de los atributos, que posteriormente ser
almacenado en la base de datos. El valor de cada atributo est enmarcado en un
conjunto de valores permitidos llamado Dominio. Ejemplo: el conjunto de valores
permitidos (dominio) para el atributo cdula pueden ser todos los enteros positivos.
Tipos de Atributos:
Simples: No divisible, es decir es un atributo atmico. Ejemplo: El atributo cdula, su
propiedad no tiene sentido dividirla, no tendr significado para la entidad, ya que la
concepcin de este es un nmero indivisible.
Compuesto: Est conformado por un conjunto de partes que en el momento de dividirlas
pueden formar otros atributos sin perder el sentido bsico de la propiedad que est
calificando la entidad. Ejemplo: los atributos nombre, direccin pueden estar
conformados en su naturaleza funcional por varias partes. Si tomramos el atributo
nombre con un valor de: JUAN PEREZ CORREA, sin perder la propiedad del mismo,
se podrn crear otros dos atributos simples tales como: primer_apellido,
segundo_apellido. As se tendr: (nombre, JUAN), (primer_apellido, PEREZ),
(segundo_apellido, CORREA).
Un atributo compuesto se divide slo por razones de manejo a nivel del lenguaje de
consulta o programacin o por requerimientos del usuario, si no hay necesidad no se
debe dividir ya que en algunas ocasiones se vuelve complejo el manejo de esta
situacin, es decir el atributo compuesto se trabaja como un atributo simple. As se
puede concluir que un atributo compuesto es la suma (concatenacin) de los valores de
los atributos simples que lo conforman.
Univaluados (univalorados o monovaluados): Son atributos que en el transcurso del
tiempo slo toman un valor para una entidad en particular. Ejemplo: El atributo cdula,
solo toma un valor para una entidad persona en particular.
Multivaluados (multivalorados): Son atributos que en el transcurso del tiempo pueden
tener un conjunto de valores para una entidad en particular. Ejemplo: El atributo
Grado_Academico para el conjunto de entidades persona puede tomar diferentes valores
desde 0 o primaria o medio, entre otros. Tambin es caracterstico que este tipo de
atributo maneje rangos de valores. Ejemplo: el atributo sexo, puede tener un rango de
valores [F,M] y tomar uno de estos en algn instante en el tiempo para una entidad
especfica.

Nulos: Son atributos que en cualquier instante en el tiempo pueden tomar el valor nulo
para una entidad en particular.
Derivado: Son atributos cuyo valor depende de los valores de otros atributos o
entidades. Ejemplo: el atributo salario pude derivarse a partir del clculo de los
siguientes valores:
PARAMETROS(salario_base, 5000), NOVEDADES(nro_horas_trabajadas, 240), el
valor que tendra el atributo en un instante en el tiempo ser:
PERSONA(salario,1200000).

TIPO DE ENTIDADES: Cuando se habla de tipo de entidad, se refiere al conjunto de

entidades que poseen los mismos atributos, es decir: la entidad e1 tiene el conjunto de
atributos (a1, a2,... ,an) que la califican y as mismo las entidades e2, e3 , ..., en . Entonces a
partir de este conjunto de entidades se puede conformar la entidad E= (e1, e2, e3 , ..., en).

El modelo E-R se representa grficamente as: los tipos de entidades por medio de
rectngulos que contienen el nombre del tipo de entidad. Los nombres de los atributos
se encierran en valos y se conectan con su tipo de entidad a travs de lneas. Ejemplo:

ATRIBUTOS CLAVE: Por lo general todo tipo de entidad cuenta con un atributo cuyo
valor diferencia (identifica) una entidad individual de otra. El atributo o conjunto de
atributos que ejercen esta funcin se denominan atributos claves, donde a partir de estos
se ejerce la restriccin por clave o unicidad de atributos en los tipos de entidad.
Ejemplo: el atributo cedula en el tipo de entidad persona se utiliza como atributo clave
para diferenciar una entidad de otra. Un atributo clave puede ser un atributo compuesto.
Grficamente en el modelo E-R el atributo clave va subrayado dentro del vulo.
TIPOS DE ENTIDADES FUERTE Y DBILES: Las entidades fuertes o propietaria
se caracterizan porque tienen atributos claves propios. Ejemplo: la entidad persona tiene

como atributo clave la cedula, el cual no es entregado o heredado de otra entidad. Las
entidades dbiles no tienen atributos claves propios sino que dependen del que posee
una fuerte, pero si pueden tener atributos que identifiquen una clave parcial (fornea)
que la identifican como nica dentro del tipo de entidad dbil. Ejemplo: la entidad
ocupacion depende la existencia de una entidad persona, ya que sin esta no tendra
sentido. En el modelo E-R se esquematiza grficamente a travs de rectngulos dobles.
El atributo parcial se subraya con lnea punteada.
VNCULOS o INTERRELACIONES(relaciones): La asociacin entre uno o tipos de
entidades E1,E2,...,En define un vnculo R entre estas, donde R matemticamente se
puede definir como el conjunto de vnculos ri y cada uno de estos asocia n entidades (e1,
e2, e3 , ..., en) y cada ej de ri es miembro del tipo de entidad Ej (1<=j<=n). Expresndolo
de otra forma, es un subconjunto del producto cartesiano E1x E2x ... x En.
Ejemplo: Tenemos dos tipos de entidades Estudiantes y Curso, el vnculo o asociacin
entre esta es INSCRITO EN, de la siguiente forma:

Grficamente en el diagrama E-R los vnculos (asociaciones o relaciones) se

representan por medio de rombos, ejemplo:

Esta relacin se conoce como binaria ya que se realiza entre dos tipos de entidad.
Existen las relaciones n-arias (entre ms de 2 entidades), por ejemplo:

Y las relaciones recursivas como:

CARDINALIDAD: Especifica el nmero de ejemplares de vnculos en los que puede

participar una entidad. Las razones de cardinalidad ms comunes para relaciones
binarias son: 1:1,1:N,M:N. A partir de estas aparecen las Restricciones de cardinalidad
y participacin (integridad).
Los tipos de entidad dbil siempre tienen una restriccin de participacin (dependencia
de existencia) con respecto a su vnculo identificador, porque una entidad dbil no se
puede identificar sin una entidad fuerte o propietaria. Ejemplos: entidad
licencia_conductor depende de la entidad persona.
GRADO: El grado de un tipo de entidad indica el nmero de entidades participantes.
OTROS ELEMENTOS DEL MODELO E-R
Jerarqua de Generalizacin: Una entidad E es una generalizacin de un grupo de
entidades E1,E2, ... , En , si cada objeto de estas es tambin un objeto de la entidad E.
Ejemplo: el tipo de entidad VEHCULO es una generalizacin del tipo de entidad
BICICLETA, ya que todas las bicicletas son vehculos. El tipo de entidad PERSONA es
una generalizacin de las entidades HOMBRE y MUJER. Se puede decir que estos son
subconjuntos de la generalizacin (Es_un o Es_parte_de).
Lo opuesto a la generalizacin es la ESPECIALIZACIN (son miembros de la entidad
general).

Ejercicio: Extraer las posibles generalizaciones de la siguiente especializacin:

{silla negra, mesa negra, silla blanca, mesa blanca}

DISEO LGICO
Una vez establecido el modelo conceptual del problema o situacin, el diseo lgico de
los datos permite que estos se puedan representar usando de manera eficiente posibles
recursos para estructurar datos y modelar restricciones disponibles en el modelo
lgico. El objetivo es convertir el esquema conceptual de datos en un esquema lgico
que se ajuste al gestor de la base de datos que va a ser utilizado (el DBMS). Para
escenificar esta situacin se tomar el Modelo Relacional cuyo esquema relacional es
trabajado por muchos DBMS comerciales. Algunos de ellos son: ORACLE (Oracle
Inc.), INFORMIX (Informix Inc.), SQL/DS, DB2 (IBM), INGRES (ASK/Computer
Systems Inc.), UNIFY(Unify Inc.).

Modelo Relacional
Caractersticas para pasar de un MER a un MR
Normalizacin y Dependencia Funcional
Algebra Relacional
SQL

Modelo Relacional (MR)

Propuesto por Codd en 1970 como un modelo simple, potente y formal para representar
una situacin y de enfocar y analizar trabajos relacionados con la gestin de la base de
datos, como la redundancia, las restricciones, la forma de acceso, etc. El formalismo y
una base matemtica son las temas fundamentales en el desarrollo de las bases de datos
relacionales.

Conceptos del MR:

A travs de esta grfica se escenifican los componentes bsicos de un MR. Los aspectos
ms importantes que se formalizan en este son: la definicin de la estructura, el control
integridad y la manipulacin de los datos, . Para lograr esto maneja los siguientes
conceptos: relacin, dominio, tupla, cardinalidad, atributo, grado y clave (primaria y
fornea).

Relacin: Es el elemento bsico del modelo, est compuesta por dos partes:
Cabecera y Cuerpo. La cabecera esta formada por un conjunto fijo de atributos.
El cuerpo est formado por un conjunto de tuplas . Por esto podemos nombrar
una relacin con el nombre de TABLA, la cual est compuesta por filas y
columnas, donde cada fila (tupla) representa un conjunto de valores
relacionados entre s(hechos del mundo real), y las columnas (atributos) tienen
la funcin de ayudar a interpretar el significado de los valores que estn en cada
fila de la tabla. Como ejemplo, la grfica representa la relacin PERSONA.
Una forma lgica de diferenciar entre el trmino Relacin y el trmino Tabla es
la siguiente: una relacin es una especie abstracta de objeto; y una tabla es una
representacin concreta de tal objeto abstracto. Las tablas poseen ciertas
propiedades, todas ellas consecuencia inmediata de la relacin. Estas son:
- No existen tuplas repetidas: Esta propiedad es consecuencia del hecho de que
el cuerpo de la relacin es un conjunto matemtico( es decir, un conjunto de
tuplas) y en matemticas por definicin los conjuntos no incluyen elementos
repetidos.
- Las tuplas no estn ordenadas: Esta propiedad sirve para ilustrar la diferencia
entre una relacin y una tabla, porque las filas de una tabla tienen un orden
obvio de arriba hacia abajo, en tanto que las tuplas de una relacin carecen de tal
orden.

- Los atributos no estn ordenados: Esta propiedad desprende el hecho de que la

cabecera de una relacin se define tambin como conjunto. Las columnas de una
tabla tienen un orden evidente de izquierda a derecha, pero los atributos de una
relacin carecen de tal orden.
- Todos los valores de los atributos son atmicos.

Dominio: (D). Es un conjunto de valores atmicos que puede adoptar un

atributo en particular. Un dominio reune caractersticas de tipo,
comportamientos propios y distinguibles. Por ejemplo: el conjunto de
direcciones de la ciudad de Medelln, el conjunto de posibles ciudades de las
personas que constituyen la base de datos. Pero para que el dominio pueda
formar parte de una estructura se debe especificar sul tipo de dato, siendo estos
definidos por el DBMS.
La definicin matemtica de las relaciones se basa en la nocin de dominio.
Dados varios atributos A1,A2,...,An, con dominios D1,D2,...,Dn, un caso de
relacin de grado est dada por el subconjunto del producto carteciano D1 x D2
x ... x Dn.
En conclusin, un dominio debe tener: un nombre, un tipo de dato y un formato.

Esquema Relacional: Est compuesto por un nombre de relacin, R, y una

lista de atributos A1,A2,...,An, de tal forma que se puede denotar como
R(A1,A2,...,An). Ejemplo:
R= PERSONA
Atributos: Cedula, Nombre, Ubicacin, Ciudad
PERSONA(Cedula, Nombre, Ubicacin, Ciudad)
Cada atributo Ai es el nombre de un papel desempeado por algn dominio D,
denotado por D(Ai), en el esquema R. El nmero de atributos, n, del esquema
de relacin se denomina grado de una relacin, y el nmero de tuplas es la
cardinalidad.
Una relacin, r, del esquema de relacin, R, es el conjunto de n-tuplas r =
{t1,t2, ..., tn}. Cada n-tupla, t, es una lista ordenada de n valores, donde cada
uno de estos es un elemento del dominio de D(Ai), o bien un valor nulo.

Clave: Su definicin y funcin es similar a la definida en el MER. La clave de

una relacin es un conjunto de atributos de la relacin que identifica de manera
nica cada tupla. Los tipos de claves son: primaria y candidata.

Restricciones de Integridad en los Esquemas Relacionales:

La restriccin se interpreta como una condicin que debe ser cumplida por una relacin
especfica. Se tienen los siguientes tipos de restricciones:
Restriccin de Clave: Se especifican las claves de cada esquema de relacin;
estos valores deben ser nicos para cada tupla en cualquier caso de ese esquema
de relacin. Ejemplo: Para el esquema de relacin PERSONA la restriccin por
clave est dada por el atributo Cedula. En otros esquemas puede darse por la
concatenacin de varios atributos.

Restriccin de Ingridad de entidades: Establece que ningn valor de clave

primaria puede ser nulo, ya que el valor de nulo no podra identificar una tupla y
menos como nica. En otras palabras, los atributos que pertenezcan a la clave
primaria deben tener valores diferentes a nulo.

Restricciones de Integridad Referencial: Se especifica entre dos relaciones y

sirve para mantener la consistencia entre tuplas de las dos relaciones. En otras
palabras, una tupla de una relacin que haga referencia a otra relacin debe
referirse a una tupla existente en esa relacin. Esta restriccin permite el manejo
de clave ajena(externa) o fornea , entendiendo a estas como claves heredadas
de otra entidad pero que no forman parte de la clave primaria, por esto permite el
manejo de valores nulos.

Caractersticas importantes para pasar de un MER a

un MR
- Eliminacin de Identificadores Externos
- Eliminacin de atributos compuestos y polivalentes
- Transformacin de entidades
- Transformacin de interrelaciones 1:1
- Transformacin de Interrelaciones de 1:n
- Transformacin de interrelaciones n:m
- Transformacin de relaciones n-arias y recursivas.

Normalizacin y Dependencia Funcional

Normalizacin
La normalizacin es un proceso que consiste en comprobar que las tablas (tambin
denominadas relaciones en terminologa propia del modelo relacional de datos)
definidas cumplen unas determinadas condiciones. Se pretente garantizar la no
existencia de redundancia y una cierta coherencia en la representacin mediante un
esquema relacional de las entidades y relaciones del modelo conceptual (diagrama E-R).
Mediante la normalizacin se pueden solucionar diversos errores en el
diseo de la base de datos as como mejorarlo. Tambin se facilita el trabajo posterior
del administrador de la base de datos y de los desarrolladores de aplicaciones.

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 restriccin sobre las
posibles tuplas que podran formar un ejemplar de relacin r de R. La restriccin dice
que, para cualesquier dos tuplas t1 y t2 de r tales que t1[X] = t2[X], debemos tener
tambin 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 estn 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. Tambin decimos que hay una
dependencia funcional de X a Y o que Y depende funcionalmente de X.
Sean a y b atributos de una misma tabla o relacin T. Se dice que b es funcionalmente
dependiente de a y se denota T.a -> T.b o bien simplemente a -> b si todo posible valor
de a tiene asociado un nico valor de b, o lo que es lo mismo, en todas las tuplas de T en
las que el atributo a toma el mismo valor v1, el atributo b toma tambin un mismo valor
v2. Claramente a -> b no implica b -> a. Pueden repetirse los valores del atributo b para
distintos valores de a. Un mismo
atributo puede determinar funcionalmente a varios atributos lo cual se denota a -> (b1,
b2, ...). Puede darse una dependencia funcional mutua: a -> b y b -> a o lo que es lo
mismo a <-> b. Nse que el concepto de dependencia funcional no depende de la
extensin concreta (contenido) que en un momento determinado tenga la tabla sino de
cualquier posible extensin que pudiera tener.
Los atributos a y b pueden ser simples o compuestos (formados por la agregacin de
varios atributos). Los atributos funcionalmente dependientes pueden o no formar parte
de la clave primaria de la tabla, de una clave altenativa o de una clave ajena de otra
tabla.

El atributo b es funcionalmente dependiente de forma completa de a si a -> b y b no

depende funcionalmente de ningn subconjunto de atributos de a. Si a es un atributo
simple y a -> b entonces la dependencia funcional es con seguridad completa.
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 ms la direccin
tambin 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 direccin
de una persona, entonces con el dni es posible determinar el nombre.
Aditividad. Si x -> y y z -> w entonces x+z -> y+w. Ejemplo: si con el dni se
determina el nombre y con la
direccin el telfono de una persona, entonces con el dni y la direccin podr
determinarse el nombre y el telfono.
Transitividad o enlace de dependencias funcionales. Si x -> y e y -> z entonces x
-> z. Ejemplo: si con el dni
puede determinarse el cdigo de la provincia de residencia de una persona y con ste
cdigo puede determinarse el
nombre de la provincia, entonces con el dni puede determinarse el nombre de la
provincia. ste es el mecanismo
bsico de funcionamiento del enlace entre tablas a partir de claves ajenas.

Reglas de normalizacin
El punto de partida del proceso de normalizacin es un conjunto de tablas con sus
atributos, el denominado esquema
relacional. Se pretende mejorar dicho esquema de datos. Se dice que una tabla estn en
una determinada forma normal si
satisface un cierto nmero de restricciones impuestas por la correspondiente regla de
normalizacin. La aplicacin de una
de estas reglas a un esquema relacional produce un nuevo esquema relacional en el que
no se ha introducido ningn nuevo
atributo.

Un esquema relacional se compone de una serie de ternas T(A,D) donde T es el nombre

de una tabla, A el conjunto de los
atributos de esa tabla y D el conjunto de dependencias funcionales que existen entre
esos atributos.
Si una tabla no satisface una determinada regla de normalizacin, se procede a
descomponerla en otras dos nuevas que s
las satisfagan. Esto usualmente requiere decidir qu atributos de la tabla original van a
residir en una u otra de las nuevas
tablas. La descomposicin tiene que conservar dos propiedades fundamentales:
1.No prdida de informacin. Sea T(A,D) que se divide en T1(A1,D1) y T2(A2,D2). A
partir de los atributos comunes
en ambos esquemas es posible determinar los atributos de T1 no presentes en T2 (es
decir, el conjunto A1 - A2) o bien
los atributos de T2 no presentes en T1 (el conjunto diferencia A2 - A1). Desde
cualquier esquema se consigue
recuperar los datos del otro mediante un mecanismo de clave ajena que permite
reconstituir el esquema original de
partida. Expresado mediante dependencias funcionales, la interseccin de los
conjuntos de atributos A1 y A2 debe
determinar funcionalmente la diferencia de los conjuntos de atributos A1 - A2 o bien
A2 - A1.
2.No prdida de dependencias funcionales.
La normalizacin consiste pues en descomponer los esquemas relacionales (tablas) en
otros equivalentes (puede obtenerse
el original a partir de los otros) de manera que se verifiquen unas determinadas reglas de
normalizacin. Evidentemente las
reglas de normalizacin imponen una serie de restricciones en lo relativo a la existencia
de determinados esquemas
relacionales. Segn se avance en el cumplimiento de reglas y restricciones se alcanzar
una mayor forma normal. Existen
cinco formas normales hacia las cuales puede conducir el proceso de normalizacin de
forma incremental ms una forma
normal independiente de las otras.
Un esquema relacional que satisface todas las restricciones impuestas por la tercera
forma normal se considera de buena
calidad aunque es mejor que satisfaga una interesante propiedad. La verificacin de una
forma normal implica el
cumplimiento de todas las formas normales anteriores. La primera forma normal es de
cumplimiento obligatorio para que
exista siquiera un esquema relacional propiamente formado
FN1. Se pretende garantizar la no existencia de grupos repetitivos. Un grupo
repetitivo es un conjunto de atributos de
igual semntica en el problema y dominio, que toman valores distintos para la misma

clave. Cualquier esquema que

tenga claves correctas est seguro en FN1.
FN2.Si FN1 y cada atributo de la tabla que no forma parte de la clave depende
funcionalmente de forma completa de la
clave primaria. Es decir, depende de toda la clave y no de ningn subconjunto de ella.
Se pretende garantizar una
correcta eleccin de claves y eliminar redundancias. Si la clave estn formada por un
nico atributo entonces ese
esquema estar seguro en segunda forma normal.
FN3. Si FN2 y cada atributo no primo de la tabla no depende funcionalmente de
forma transitiva de la clave primaria.
FNBC (Forma Normal de Boyce-Codd). Se basa en el concepto de determinante
funcional: uno o varios atributos de
una tabla de los cuales dependen funcionalmente de forma completa algn otro
atributo de la misma tabla. Una relacin
est en FNBC si FN1 y cada determinante funcional es una clave candidata de la
tabla. As se garantiza que se han
elegido bien las claves al no existir dependencias funcionales entre atributos que no
son clave. Cada vez que se
verifica una dependencia funcional a -> b entonces a es clave primaria o alterna con
seguridad. Todas las
dependencias funcionales cumplen que en su parte izquierda solo aparecen atributos
que son parte de una clave
candidata. Esta forma normal es ms restrictiva que la tercera y tiene la interesante
propiedad de que su cumplimiento
implica la satisfaccin de FN3 o sea que FNBC -> FN3.
Ejemplo: Dependencias funcionales
Ejemplo:
a.Empleado_departameto
nombre nss fecha_n direccin
b.Empleado_proyecto
nss numero_proy horas

numero_dep

nombre_emp

nombre_dep

nombre_proy

lugar_proy

Emp_proy
- nss -> nombre (el nss del empleado determina de forma nica el nombre de ese
empleado)
- numero_proy -> {nombre_proy,lugar_proy}
- {nss, numero_proy} -> horas

Algebra Relacional
Conjunto de operaciones para manipular las tuplas de las relaciones o tablas. El
resultado de cada operacin es una nueva relacin que podemos manipular
posteriormente.

Operaciones
- Seleccionar ()
- Proyectar ()
- Operaciones de Teora de Conjuntos: Unin (), Interseccin (), Diferencia (-),
Producto Cartesiano (X).
- Reunin ()

* Seleccionar ( )
Por medio de esta operacin se posibilita la seleccin de un subconjunto de tuplas de
una relacin que corresponden a una condicin (columna OPERADOR valor)determinada. El
grado (total de columnas de la Relacin), se conserva.
Formato de Uso:

(condicin)

(RELACION)

Esta operacin es conmutativa, es decir:

(condicin1)

(condicin1)

(condicin2)

(R) ) =

(condicin2)

(R) )

Ejemplos:
PERSONA
Cedula

Nombre

Primer_Apellid Segundo_Apellid
Direcci
Sexo
Telefono Salario
o
o
n
Mesa

Uribe

Cra 25
22-1

2567532 1,600,000

Betancur

Bermudez

Cra 45
11-13

3433444 1,300,000

12453535 Gloria Betancur

Garces

Tr. 12 432756533 1,700,000

5

75556743 Pedro

Pelaez

Cll.6ta
14-45

2686885 1,200,000

Guzmn

Cll. 45
23-1

2674563 1,350,000

71134534 Juan
23423445

Ana
Mara

Ochoa

43533322 Patricia Angel

78900456 Carlos Betancur

Agudelo

Cir. 5 124445775 1,500,000

5

La seleccin, permite extraer todas las filas (tuplas) que cumple una condicin
determinada. Esta condicin permite la utilizacin de los operadores de comparacin:
=,>,<,>=,adems de los conectores lgicos "y" - "o":

a.

cedula = 71134534

(PERSONA)

Resultado:
Cedula

Nombre

71134534 Juan

b.

sexo ='F'

Primer_Apellid Segundo_Apellid
Direcci
Sexo
Telefono Salario
o
o
n
Mesa

Uribe

Cra 25
22-1

2567532 1,600,000

(PERSONA)

Resultado:
Cedula

Nombre

Primer_Apellid Segundo_Apellid
Direcci
Sexo
Telefono Salario
o
o
n

23423445

Ana
Mara

Betancur

12453535 Gloria Betancur

c.

(primer_apellido ='Betancur') y (sexo='F')

Bermudez

Cra 45
11-13

Garces

Tr. 12 432756533 1,700,000

5

3433444 1,300,000

(PERSONA)

Resultado:
Cedula

Nombre

Primer_Apellid Segundo_Apellid
Direcci
Sexo
Telefono Salario
o
o
n

23423445

Ana
Mara

Betancur

12453535 Gloria Betancur

d. c.

(sexo = 'M'') o (Salario >=1,350,000)

Bermudez

Cra 45
11-13

Garces

Tr. 12 432756533 1,700,000

5

3433444 1,300,000

(PERSONA)

Resultado:
Cedula

Nombre

Primer_Apellid Segundo_Apellid
Direcci
Sexo
Telefono Salario
o
o
n

Uribe

Cra 25
22-1

12453535 Gloria Betancur

Garces

Tr. 12 432756533 1,700,000

5

75556743 Pedro

Pelaez

Cll.6ta
14-45

2686885 1,200,000

43533322 Patricia Angel

Guzmn

Cll. 45
23-1

2674563 1,350,000

78900456 Carlos Betancur

Agudelo

Cir. 5 124445775 1,500,000

5

71134534 Juan

Mesa

Ochoa

2567532 1,600,000

* Proyectar ()
Esta operacin permite seleccionar algunas columnas de una relacin.
Formato de Uso:

<

lista de Atributos

> (RELACION)

Ejemplos:
Se construyen con base en la Relacin anterior: PERSONA.
a.

cedula, nombre, primer_apellido, segundo_apellido

(PERSONA)

Resultado
Cedula

Nombre Primer_Apellido Segundo_Apellido

71134534 Juan

Mesa

Uribe

Ana
Mara

Betancur

Bermudez

12453535 Gloria

Betancur

Garces

75556743 Pedro

Ochoa

Pelaez

23423445

43533322 Patricia Angel

Guzmn

78900456 Carlos

Agudelo

b.

cedula, salario

Betancur

(PERSONA)

Resultado:
Cedula

Salario

71134534 1,600,000
23423445 1,300,000

12453535 1,700,000
75556743 1,200,000
43533322 1,350,000
78900456 1,500,000
La operacin SELECCIN combinada con la operacin PROYECCIN, podemos
tener:
c.

cedula, nombre, salario

(sexo = 'M'') o (Salario >=1,350,000)

(PERSONA) )

Resultado:
Cedula

Nombre Salario

71134534 Juan

1,600,000

12453535 Gloria

1,700,000

75556743 Pedro

1,200,000

43533322 Patricia 1,350,000

78900456 Carlos

1,500,000

EL RESULTADO DE LAS OPERACIONES PUEDEN SER LLEVADOS A

RELACIONES TEMPORALES DE LA SIGUIENTE FORMA:
REL_TEMP

cedula, nombre, salario

(sexo = 'M'') o (Salario >=1,350,000)

(PERSONA) )

Resultado:
REL_TEMP Cedula

Nombre Salario

71134534 Juan

1,600,000

12453535 Gloria

1,700,000

75556743 Pedro

1,200,000

43533322 Patricia 1,350,000

78900456 Carlos

1,500,000

SQL (Structured Query Language)

Las operaciones sobre la base de datos estn determinadas por el Lenguaje SQL, bajo
estndares determinados los cuales pueden ser utilizadas de forma bsica o avanzada
segn el DBMS utilizado.
SELECT
Operaciones Adicionales 1
Operaciones Adicionales 2
Operaciones Adicionales 3
Operaciones Adicionales 4

Operaciones Adicionales 5
Operaciones Adicionales 6
Tutorial Sql (.pdf)
EJERCICIOS

Las operaciones SQL correspondientes al SELECT se realizarn con el siguente

ejempo:
PERSONAS
Cedula

Nomb Primer_Apel Segundo_Ape Sex Direcci Telefo

Cedula_ Cod_d
Salario
re
lido
llido
o n
no
Sup
ep

711345
Juan Mesa
34

Uribe

Cra 25 25675 1,600,0 2342344

3
22-1 32
00
5

234234 Ana
Betancur
45
Mara

Bermudez

Cra 45 34334 1,700,0 4389023

2
11-13 44
00
1

124535
Gloria Betancur
35

Garces

Tr. 12 27565 1,350,0 7113453

3
43-5 33
00
4

755567
Pedro Ochoa
43

Pelaez

Cll.6ta 26868 1,700,0 4389023

1
14-45 85
00
1

435333 Patrici
Angel
22
a

Guzmn

Cll. 45 26745 1,350,0 7113453

3
23-1 63
00
4

789004
Carlos Betancur
56

Agudelo

Cir. 5
12-5

734567
Mario Gmez
89

Angel

Cr. 53 34567 1,200,0 2342344

2
23-1 89
00
5

438902 Claud
Gonzalez
31
ia

Beltran

Cll. 10 26603 1,800,0 4389023

0
14-1 56
00
1

789007
Fabio Solano
00

Prez

Tr. 3
32-1

44457 1,500,0 7555674

1
75
00
3

43456 1,200,0 7555674

1
78
00
3

DEPENDIENTES
Cedula

Nombre_Dep Sexo FechaN

Parentesco

78900456 Juanita

12-Abr-95

Hija

78900456 Oscar

15-Ene-89

Hijo

23423445 Hector

23-Dic-67

Cnyuge

71134534 Mara

05-Mar-60 Cnyuge

71134534 Gloria

27-Nov-97 Hija

75556734 Jorge

14-Mar-96 Hijo

DEPARTAMENTOS
Codigo_Dep Nombre_Dep

Cedula_Jefe

Gerencia

43890231

Teleinformatica 75556734

Desarrollo

Soporte Tcnico 71134534

23423445

PROYECTOS
Numero_Proy Nombre

Lugar

Codigo_Dep

129001

Registro y
Matrcula

Bloque
2
21

139001

Red Lan

Bloque
1
14

139002

Instalacin nuevo Bloque

1
Switche
21

129002

Notas

Campus 2

129003

Paso de
aplicativos
FOXPRO A
COBOL

Bloque
2
21

149001

Inventario de
HW y SW

Minas

149002

Licenciamiento

Campus 3

149003

Evaluacin de
equipos PC's

Bloque
3
18

1. OPERACIN SELECT
La sintaxis bsica de esta operacin es:
SELECT <lista de atributos>
FROM <lista de tablas>
WHERE <condiciones>
Ejemplos:
a. Select bsico. Se desea obtener la cdula y el nombre de todas las personas que
trabajan en la compaa.
SELECT cedula, nombre
FROM personas

Similar la operacin el lgebra relacional sera:

cedula, nombre

(PERSONAS)

Resultado/
Cedula

Nombre

71134534

Juan

23423445

Ana Mara

12453535

Gloria

75556743

Pedro

43533322

Patricia

78900456

Carlos

b. Select con clausula WHERE. Se desea obtener toda la informacin de la persona

cuya cdula sea igual a 12453535.
SELECT nombre,primer_apellido,segundo_apellido,direccion,telefono
FROM personas
WHERE cedula = 12453535
Similar la operacin el lgebra relacional sera:

nombre, primer_apellido, segundo_apellido, direccion, telefono

cedula = 1245353

(PERSONAS) )

Resultado/
Nombre Primer_Apellido Segundo_Apellido Direccin
Gloria

Betancur

Garces

Telefono

Tr. 12 43-5 2756533

c. En la clausula WHERE es posible utilizar los conectores lgicos AND - OR. Se

necesita la cdula y el nombre de las personas cuyo apellido sea BETANCUR y su sexo
sea MASCULINO:
SELECT cedula,nombre
FROM personas
WHERE primer_apellido = 'Betancur'
AND sexo = 'M'
Resultado/
Cedula

Nombre

78900456

Carlos

d. Select combinando tablas y utilizacin del comodn '*'. Se desea obtener la

informacin de todos los dependientes de las personas cuyo apellido sea BETANCUR y
su sexo sea MASCULINO. Cuando se trabaja con varias tablas y se utiliza el '*', se le
debe anteponer el nombre de la tabla de la cual se desea extraer la informacin:
SELECT dependientes.*
FROM personas, dependientes
WHERE primer_apellido = 'Betancur'
AND sexo = 'M'
AND dependiente.cedula = personas.cedula
Resultado/
Cedula

Nombre_Dep

Sexo FechaN

Parentesco

78900456 Juanita

12-Abr-95 Hija

78900456 Oscar

15-Ene-89 Hijo

e. Utilizando alias o sinnimos de trabajo a las tablas del Select. Estos se utilizan por
facilidad en el manejo de la instruccin. La misma consulta anterior:
SELECT d.*
FROM personas p, dependientes d
WHERE primer_apellido = 'Betancur'
AND sexo = 'M'
AND d.cedula = p.cedula
Resultado/
Cedula

Nombre_Dep

Sexo FechaN

Parentesco

78900456 Juanita

12-Abr-95 Hija

78900456 Oscar

15-Ene-89 Hijo

f. Cuando se necesita extraer informacin distintiva dentro de un grupo de tuplas, se

utiliza la clausula DISTINCT. Por ejemplo, se necesita extraer los diferentes valores
de salarios que se pagan en la compaa:
SELECT distinct salario
FROM personas
Resultado/
Salario
1,600,000
1,700,000
1,350,000
1,500,000

1,200,000
1,800,000
g. Una de las clausulas ms significativas en el Select es el COUNT, la cual se utiliza
para contar la cantidad de registros que cumplen con una condicin especfica:
g.1 Mostrar el total de empleados en la compaa:
SELECT count(*)
FROM personas
Resultado/
9
g.2 Mostrar el total de proyectos que tiene asignada la dependencia 3
SELECT count(*)
FROM proyectos
WHERE codigo_dep = 3
Resultado/
3
g.3 Mostrar cuntos salarios diferentes o distintas se pagan en la compaa:
SELECT count(distinct salario)
FROM personas
Resultado/
6
h. Clusula WHERE compara sus campos comunmente con valores nicos, pero
tambien es posible comparar con un "conjunto" de valores. Esto es realizable a travs
del operador IN. Ejemplo, se desea saber qu empleados estn involucrados en los
proyectos 139001 o 139002.
h.1 Forma bsica:
SELECT personas.*
FROM personas, proyectos
WHERE (numero_proy = 139001 OR numero_proy =139002)
AND cod_dep = codigo_dep
h.2 Forma con IN:
SELECT personas.*
FROM personas, proyectos
WHERE numero_proy IN (139001,139002)
AND cod_dep = codigo_dep

Resultado/
PENDIENTE
i. Operacin Select con anidamientos. La clausula WHERE comunmente compara los
campos con valores exactos, pero tambin es probable utilizarla comparando sus
campos con otras sentencias Select. Esta forma tambin es llamada Consulta anidada:
i.1 Mostrar los diferentes proyectos en donde el ingeniero OCHOA participa:
SELECT distinct numero_proy
FROM proyectos
WHERE numero_proy IN (select numero_proy
from proyectos p, departamentos d, personas
where p.codigo_dep = d.codigo_dep
and primer_apellido = 'Ochoa')
i.2 Mostrar los empleados cuyo jefe es de apellidos BETANCUR BERMUDEZ:
SELECT personas.*
FROM personas
WHERE cedula_sup IN (select cedula
from personas
where primer_apellido = 'Betancur'
and segundo_apellido = 'Bermudez')
i.3 Mostrar el nombre de los empleados cuyo salario es mayor que el de todos los
empleados del departamento 3. Aqu se utiliza la utilizacin de la clusula ALL:
SELECT nombre, primer_apellido, segundo_apellido
FROM personas
WHERE salario > ALL (select salario
from personas
where cod_dep = 3)
j. En el select es posible validar la existencia de informacin nula a travs de la
clusula NULL. Ejemplo, Mostrar los empleados que no tengan asignado salario:
SELECT *
FROM personas
WHERE salario IS NULL
k. Otra clusula que es posible utilizar en el Select es EXIST, la cual ayuda a validar si
el resultado de una consulta anidada es vacio o no.
k.1 Seleccionar todos los empleados cuyo dependiente tenga la misma cedula, sexo y
nombre.
SELECT p.nombre, p.primer_apellido, p.segundo_apellido
FROM personas p

WHERE EXIST (select *

from dependiente d
where p.cedula = d.cedula
and d.sexo = p.sexo
and nombre = nombre_dep)
k.2 Seleccionar los empleados que no tienen dependientes:
SELECT p.nombre, p.primer_apellido, p.segundo_apellido
FROM personas p
WHERE NOT EXIST (select *
from dependiente d
where p.cedula = d.cedula)
l. Con la operacin de Select tambin es posible utilizar funciones agregadas para:
sumar (SUM), maximizar (MAX), minimizar (MIN) y promediar (AVG). Se pueden
utilizar al nivel de la clusula SELECT o en la clusual HAVING (que veremos
posteriormente. Ejemplo, el total pagado por la compaa, el mximo y el mnimo
salario y el promedio pagado:
SELECT sum(salario), max(salario), min(salario), avg(salario)
FROM personas
m. Agrupacin de tuplas y aplicacin de condiciones para ellas. Aqu se utilizan dos
clusulas nuevas: GROUP BY, la cual agrupa tuplas segn las columnas puestas en la
clusula Select; HAVING, permite hacer operaciones sobre estas agrupaciones.
Veamos:
m.1 Mostrar el nmero y el nombre del proyecto en donde trabajen ms de dos
empleados
SELECT nombre, numero_proy
FROM proyectos, trabaja_en
WHERE numero_proy = nump
GROUP BY nombre, numero_proy
HAVING count(*) > 1
n. La clusula WHERE adems de las anteriores instrucciones tambin puede utilizar la
instruccin LIKE, que le sirve para encontrar informacin string no precisa. Veamos el
siguiente ejemplo:
SELECT nombre, numero_proy
FROM proyectos
WHERE nombre LIKE '%lic%'
o. En la clusula Select tambin es posible realizar operaciones aritmticas '+', '-', '*',
con los campos de valor:

SELECT salario*1.18
FROM personas
WHERE salario < 1200000
p. Una clusula ms que podemos utilizar en la operacin Select es la que me permite
dale un orden a las tuplas, ORDER BY, segn el o los criterios indicados a travs de
columnas.
SELECT *
FROM personas
ORDER BY nombre, primer_apellido, segundo_apellido

2. EJERCICIOS CON LA CLAUSULA SELECT

Se tiene el siguiente esquema de base de datos para el manejo de informacin de un
Sistema de Transportes intermunicipales:
TERMINALES_TRANSPORTE (cod_terminal, nombre, ciudad, estado)
VIAJES(nmero, transportadora, das)
TARIFAS(num_viaje, cod_tarifa, monto, restricciones)
TRAYECTO_VIAJE(num_viaje, num_trayecto, cod_terminal_sale,
hora_salida_programada, cod_terminal_llega, hora_llegada_programada)
VIAJES_REALIZADOS(num_viaje, num_trayecto, fecha, num_asientos_disponibles,
id_transporte, cod_terminal_sale, hora_salida, cod_terminal_llega, hora_llegada)
VIAJES_AUTORIZADOS(tipo_transporte, cod_terminal)
TRANSPORTE(id_transporte, total_de_asientos, tipo_transporte)
RESERVA_ASIENTOS(num_viaje, num_trayecto, fecha, num_asiento,
nombre_cliente, tel_cliente)
El anterior esquema describe una base de datos con informacin sobre viajes de lneas
areas. Cada VIAJE se identifica con un nmero de viaje, y consta de uno o ms
TRAYECTO_VIAJE con num_trayecto 1, 2, 3, etc. Cada trayecto tiene horas y
terminales de salida y de llegada programados, y tiene muchos TRAYECTO_VIAJE,
uno por cada fecha en que tiene lugar el viaje. Se mantienen TARIFAS para cada
viaje. Para cada movimiento de trayecto, se mantiene RESERVA_ASIENTOS, el
transporte empleado en el trayecto y las horas de salida y llegada y los terminales
especficos. Un TRANSPORTE se identifica con id_transporte y es de un cierto
tipo_transporte. VIAJES AUTORIZADOS relaciona los tipo_transporte con los
terminales en los que puede aterrizar. Cada TERMINAL se identifica con un
cod_terminal.
Especifique las siguientes consultas:

1. Prepare una lista con los nmeros de viaje y los das de todos los viajes o trayectos de
viaje que salen del terminal codigo CA001 y llegan al terminal cdigo BO001.
Solucin 1:
SELECT num_viaje, num_trayecto,fecha
FROM viajes_realizados
WHERE cod_terminal_sale = 'CA001'
AND cod_terminal_llega = 'BO001';
Solucin 2:
SELECT distinct numero, dias
FROM viajes_realizados, viajes
WHERE cod_terminal_sale = 'CA001'
AND cod_terminal_llega = 'BO001'
AND numero = num_viaje

2. Obtenga una lista con los nmeros de viaje, cdigos de terminal de salida, horas de
salida programadas, cdigos de terminal de llegada, horas de llegada programadas y
das de todos los viajes o trayectos de viajes que salgan de algn terminal de la ciudad
de Santa Marta y lleguen a algn terminal de la ciudad de Buenaventura.
Solucin 1:
SELECT tv.*, dias
FROM trayecto_viaje tv, terminales_transporte tt, viajes
WHERE (ciudad = 'Santa Marta' AND cod_terminal_sale = tt.cod_terminal)
AND (ciudad = 'Buenaventura' AND cod_terminal_llega = tt.cod_terminal)
AND (numero = num_viaje);
Solucin 2:
SELECT tv.*, dias
FROM trayecto_viaje tv, viajes
WHERE cod_terminal_sale = (SELECT cod_terminal
FROM terminales_transporte
WHERE ciudad = 'Santa Marta')
AND cod_terminal_llega = (SELECT cod_terminal
FROM terminales_transporte
WHERE ciudad = 'Buenaventura')
AND numero = num_viaje;
3. Liste las diferentes tarifas que se aplicaron a los viajes que se realizaron entre los
terminales de Santa Marta y Medelln, en el ao 1999.
Solucin 1:
SELECT distinct cod_tarifa, monto
FROM viajes_realizados vr, tarifas ta, terminales_transporte
WHERE (ciudad = 'Santa Marta' AND cod_terminal_sale = cod_terminal)
AND (ciudad = 'Medelln' AND cod_terminal_llega = cod_terminal)

AND fecha between '01/01/00' and '31/12/99'

AND ta.num_viaje = vr.num_viaje;
Solucin 2:
SELECT distinct cod_tarifa, monto
FROM viajes_realizados vr, tarifas ta, terminales_transporte
WHERE cod_terminal_sale = (SELECT cod_terminal
FROM terminales_transporte
WHERE ciudad = 'Santa Marta')
AND cod_terminal_llega = (SELECT cod_terminal
FROM terminales_transporte
WHERE ciudad = 'Medelln')
AND fecha between '01/01/00' and '31/12/99'
AND ta.num_viaje = vr.num_viaje;
4. Liste los terminales que tienen el mayor trfico en un da (haga el ejemplo con
cualquier fecha).
CREATE TABLE tmp (term varchar2(5), total number(10));
INSERT INTO tmp (term, total)
SELECT cod_terminal, count(*)
FROM terminales_transporte, viajes_realizados
WHERE fecha = '21/10/00'
AND cod_terminal_sale = cod_terminal
OR cod_terminal_llega = cod_terminal
GROUP BY cod_terminal;
SELECT term, MAX(total)
FROM tmp
GROUP BY term;
5. Muestre los viajes con los correspondientes transportes, que tuvieron ms de 50
pasajero con reservas.
SELECT num_viaje, id_transporte
FROM viajes_realizados
WHERE num_viaje IN (SELECT num_viaje
FROM reserva_asientos
GROUP BY num_viaje
HAVING count(*) > 50);

Normalizacin de base de datos

Indice
1. Descomposicin y Normalizacin
2. Dependencia
3. Normalizacin
4. Primera Forma Normal
5. Segunda Forma Normal
6. Tercera Forma Normal
7. Cuarta Forma Normal

1. Descomposicin y Normalizacin
Siempre que un analista de sistemas de base de datos arma una base de
datos, queda a su cargo descomponer dicha base en grupos y segmentos de
registros. Este proceso es la descomposicin; el mismo es necesario
independientemente de la arquitectura de la base de datos - relacional, red o
jerrquica-. Sin embargo, para la base de datos relacional, la accin
correspondiente puede dividirse y expresarse en trminos formales y se
denomina normalizacin a la misma.
La normalizacin convierte una relacin en varias sub-relaciones, cada una de
las cuales obedece a reglas. Estas reglas se describen en trminos de
dependencia. Una vez que hayamos examinado las distintas formas de
dependencia, encontraremos procedimientos a aplicar a las relaciones de
modo tal que las mismas puedan descomponerse de acuerdo a la dependencia
que prevalece. Esto no llevar indefectiblemente a formar varias subrelaciones
a partir de la nica relacin preexistente.
2. Dependencia
Significado :
Antes de entrar en el tpico principal de dependencia, vamos a rever algunos
conceptos acerca de los individuos y acerca de las tuplas que los describen en
la base de datos relacional (BDR). Restringiremos la discusin a la BDR, si
bien la misma se aplica igualmente a las otras arquitecturas.
Los individuos tienen muchos atributos que pueden ser de inters a diferentes
personas en diferentes momentos. Nuestro problema actual es con una sola
aplicacin o conjunto de aplicaciones: solemne son de inters algunos de los
atributos.
Los smbolos aplicables a la relacin han sido introducidos previamente.
R es una tupla general o vector que describe a un individuo;

 R es una relacin, una matriz o un conjunto de

vectores que pertenecen la poblacin de inters.
U es el universo consistente en todas las posibles
descripciones individuales, obtenido mediante una
combinacin exhaustiva de los valores a atributos.
La tupla general toma la siguiente forma
R = (a, b, c, ...., n) La pertenencia con respecto a relaciones, tuplas y universos
se indica mediante. Con respecto a los atributos:
A es el smbolo del nombre de un atributo
a es el smbolo de un valor del atributo.
Dominio (A) es el dominio para el atributo cuyo nombre es A.
Campo de aplicacin
Estamos interesados en relaciones dependientes entre atributos de los
individuos en una o varias poblaciones. Consideramos a los atributos D, E, y F.
La dependencia es una relacin funcional tal que los valores de una (o ms de
una) de las variables determina y fija el valor de las otras variables en la
relacin dependiente. Consideramos el caso en el que E y F dependen de D.
Esto se describe ms brevemente en forma simblica:
e = e (d) f = f(d)
Existen tres tipos distintos de dependencia.
o
o
o

Total uno-uno-sinnimo
Completa - subtupla
Transitiva - mltiple.

La dependencia es una relacin funcional que penetra en el universo de

posibilidades. La dependencia no puede deducirse solamente de los datos de
nuestra, ya que stos son necesariamente incompletos, sino que debe ser
inherente al comportamiento del sistema. Por ejemplo, si los datos revelan que
cada uno de nuestros proveedores tiene exactamente una planta y que todas
estas plantas estn en diferentes ciudades, podemos asumir una dependencia
total entre proveedor, planta y ciudad. Es decir, dada una ciudad, la misma est
asociada con un proveedor; y dado este proveedor estar asociado con una
ciudad. En la prctica, solamente cuando un nuevo proveedor se incorpore con
una planta en la misma ciudad que uno de nuestro antiguos proveedores,
resultar claro que no existe dicha dependencia total, Esto no podra ser
deducido a partir de los datos previos.
Dependencia Total

Consideremos los atributos x e y. Cada valor de x tiene uno y solo un valor de y

asociados a el; e inversamente, dado un valor de y existe solamente un valor
de x asociado a ste. Se trata de una funcin unitaria de una variable tanto en
sentido directo como inverso y por o tanto se denomina dependencia total. Otra
forma de expresar lo mismo es decir que x e y son sinnimos; ambas
expresiones son equivalentes.
Ejemplo con clave
Si una de las variables es al mismo tiempo la clave, como consecuencia todo
valor de ambas variables es nico en cualquier tupla de la relacin. Por
ejemplo, consideremos un archivo de personal donde cada uno de los
empleados es identificado de tres maneras.
Su nombre
Su nmero de seguridad social
Su nmero de empleado
Los tres pueden representar una dependencia total. Tanto el nmero de
seguridad social como el nmero de empleado identifican al individuo en forma
nica. El nmero de seguridad social atae a la poblacin completa de
trabajadores de los Estados Unidos. El nmero de empleado se aplica
solamente al personal de una empresa en particular. El nombre puede no ser
totalmente nico y la dependencia total existe solamente cuando cada
empleado tiene un nombre nico.
Si el nmero de empleado es al clave de la relacin, el nmero de seguridad
social es sinnimo de aquel. Podemos en consecuencia decir que el nmero de
seguridad social, el campo no clave, es totalmente dependiente de la clave, y
es una clave candidata.
Si los nombres de todos nuestros empleados son nicos, tambin pueden, ser
claves candidatas. Sin embargo puede existir alguna duplicacin, dos personas
llamadas John Smith, por ejemplo. Dado que esta es una posibilidad, no puede
establecerse una dependencia total con respecto total con respecto al nombre.
Puede incorporarse a la firma un nuevo empleado y este puede tener el mismo
nombre que uno de nuestros empleados actuales.
Ejemplo con estado Consideremos una relacin que contiene informacin
sobre estado en dos formas :
Una identificacin de estado con dos letras, tal
como CA para California.
Una designacin con un nmero de dos dgitos tal
como 12 para
California.

Estas dos formas de informacin sobre estado ilustran una dependencia total.
Debe notarse sin embargo que muchas tuplas pueden contener la misma
identificacin de Estado, dado que muchos de nuestros clientes pueden
provenir de California. En consecuencia resulta claro que la dependencia total
no significa unicidad.
Dependencia Completa
El concepto de dependencia completa se aplica solamente cuando:
Tenemos ms de dos variables, y
Una variable dependiente depende de dos o ms variables
independientes.
Consideramos una relacin que abarca las variables P, Q y R. Supongamos
que P es la variable dependiente. Si el valor de P est determinado por una
funcin de Q y R combinados, se trata de una dependencia completa. Esto es,
el valor de P no depende nicamente ni de Q ni de R.
Vamos a repetir esto simblicamente. El valor de P es completamente
dependiente de los valores de q y r.
p = p (q,r)
Ejemplo con orden de compra
Como un ejemplo de dependencia completa, consideremos el caso de una
orden de compra. Supongamos que esta orden de compra describe mediante
tres variables que son de inters para nosotros:
El nmero de orden de compra (PON) designa la orden completa;
El nmero de parte de pieza designa una de las
partes ordenadas por el pedido;
La cantidad de piezas es el nmero de unidades
de dicha pieza requerida para satisfacer el pedido.
Los pedidos describen en consecuencia una orden por medio de varias partes
diferentes, y para cada una distinta asociada. El sistema contable ve varios
pedidos diferentes. La misma parte puede aparecer en distintos pedidos y,
cuando ello sucede, puede estar asociadas distintas cantidades con la misma
parte.
Un tupla de la base de datos relacional contendr un PON un nmero de parte
y una cantidad. La cantidad es completamente dependiente del PON y del
nmero de parte. Resulta claro que el nmero de pedido no es suficiente para
determinar la cantidad todas las partes de un determinado pedido no tiene la

misma cantidad). Anlogamente, un nmero de parte no es suficiente para

determinar la cantidad ordenada, dado que diferentes pedidos pueden requerir
distintas cantidades de dicha parte. Por lo tanto, es nuestro ejemplo, la
cantidad no es dependiente solamente del PON o del nmero de parte; es
completamente dependiente de ambos.
Puede imaginarse, aunque no es muy probable el caso de que cada vez
ordenados una parte la ordenamos solamente por una cantidad como una
docena, o tres gruesas o cualquier otro valor fijo. Si esto ocurre para todas las
partes y para todos los pedidos de nuestro sistema, en consecuencia no
existir dependencia completa. En efecto podemos decir que hay dependencia
total entre cantidad y nmero de partes - condicin improbable-.
Hemos examinado anteriormente un ejemplo acadmico y las variables
profesor, clase y seccin. Tenemos en esta caso una dependencia completa de
profesor respecto de clase y seccin. Si en nuestra facultad est establecido
existir dependencia completa. Esto existira que un profesor ensee siempre a
todas las secciones de una clase particular - una condicin no muy factible con
un curso de 20 secciones-.
Dependencia transitiva
La dependencia transitiva se aplica o tres o ms variables. Consideremos el
caso de solo tres variables y llammoslas S, T y V.
Diremos que S es la variable independiente si los valores de S determinan
tanto a T como a V, y se simbolizar as:
S ----> T; S ----> V
Sin embargo, sera deseable encontrar una relacin ms restrictiva o definida.
Tenemos dependencia transitiva cuando S determina a T y V, pero los valores
de V pueden considerarse siempre como dependiendo de los valores de T.
Esto puede escribirse como
S ----> T; T ---->
o alternativamente como
v = v(t); t = t(s) v = v(t(s))
Reduccin
Si podemos manejar las dependencias transitivas, podremos reducir el espacio
total requerido para almacenar los datos. Varios valores de S pueden generar
un nico valor de T. De modo similar, pueden existir varios valores de T
asociados solamente con un valor de V. La separacin de estas relaciones
permite conservar espacios. Esto puede observarse mejor con respecto al
ejemplo que se describe ms abajo.

Ejemplo
Consideramos un ejemplo que asocia cursos con departamento y con escuela.
En consecuencia, canto ser dictado por el departamento de msica en la
escuela de Artes y Ciencias; hidrulica ser dictada por ingeniera civil en la
Escuela de Ingeniera; impuestos ser dictado por el departamento contable en
la Escuela de Administracin.
Llamemos
S al curso
T al departamento
V a la escuela
Por lo tanto
S ----> T ----> V
la descomposicin consiste en la asociacin de un curso con un departamento
en una relacin. Otras relacin identifica a cada departamento con una escuela.
Esta segunda relacin es necesariamente menor tanto en grado como en
cardinalidad y aqu reside el ahorro de espacio.
3. Normalizacion
Qu es normalizacin?
Normalizacin es un proceso que clasifica relaciones, objetos, formas de
relacin y dems elementos en grupos, en base a las caractersticas que cada
uno posee. Si se identifican ciertas reglas, se aplica un categora; si se definen
otras reglas, se aplicar otra categora.
Estamos interesados en particular en la clasificacin de las relaciones BDR. La
forma de efectuar esto es a travs de los tipos de dependencias que podemos
determinar dentro de la relacin. Cuando las reglas de clasificacin sean ms y
ms restrictivas, diremos que la relacin est en una forma normal ms
elevada. La relacin que est en la forma normal ms elevada posible es que
mejor se adapta a nuestras necesidades debido a que optimiza las condiciones
que son de importancia para nosotros:
La cantidad de espacio requerido para almacenar
los datos es la menor posible;
La facilidad para actualizar la relacin es la mayor
posible;
La explicacin de la base de datos es la ms sencilla posible.

4. Primera forma normal

Para que una relacin est en primera forma normal (1 FN), debe ser
solamente una relacin propia, una matrz m por n, donde:
Ninguna celda de la matriz est vaca;
El valor n cualquier columna est definido por el
dominio para dicho atributo.
Cada tupla tiene una clave que la identifica en
forma unvoca, pero dicha clave no significa orden.
La aplicacin determina la relacin
Para que una relacin sea normalizada en pasos adicionales, debe encontrarse
en la primera forma normal. Colocar los datos en la primera forma normal est
a cargo del diseador de la aplicacin. Estos datos se encuentran disponibles
de alguna manera inicialmente. Si la aplicacin existe en forma manual, o ha
sido anteriormente computarizada pero no todava como relacin, el diseador
reorganiza los datos de modo de conformar una matrz 1FN.
La segunda inicial ms importante es la dimensin de la relacin cuntos
componentes existen en la tupla o cuntas columnas en la tabla? De qu
manera se compara esto con el nmero de campos en el documento fuente?.
En la figura se puede observar un documento como muestra, una factura tpica.
Parte de la informacin es fija y otra variable. La figura nos muestra un
formulario impreso dentro de l cual se ha agregado informacin. La impresin
puede dividirse en dos categoras.
Informacin descriptiva para el usuario
Nombres de atributos.
La informacin impresa es necesariamente fija. Podemos observar el nombre
de la compaa en la figura, as como otras particularidades (tales como el
nmero de telfono que no figura aqu). Otros nombres impresos corresponden
a los atributos cuyos valores se escriben en el momento en que el formulario es
llenado. Estos nombres de atributos son tambin los nombres de campos para
almacenar los datos en el sistema. Los que se escribe son los valores de
atributos.
La informacin convertida queda formada en tuplas. La prxima pregunta es
cuantas tuplas representarn a la formacin en esta forma. Debe notarse que
el nmero de partes ordenadas vara de una factura o pedido a otro.

Wetco factura no. 91529

23 river road fecha factura 3/19/77

saltsea texas
orden fecha

de cliente vendedor de la orden via orden wetco

M0007 2-14 3/12/17 ups 1922447
Cliente no. 31-0285-fl
Venta a flores associates expedido a
108 8 avenue el mismo

brooklyn, n.y. 11215

cantidad precio parte descripcion monto

PenOrde-despa-dienNada chada te
2 2 3.50 018719 camisa 7.00
2 2 .35 020428 guia .70
1 1 .70 020808 rodillo motor .70
1 0 .25 020811 rodillo libre 0.00
1 1 6.00 020819 humidrum 8.00
Transporte Y Seguro .96
17.38

Dado que una tupla debe tener un nmero fijo de componentes, necesitamos
una tupla en primera forma normal para cada parte de cada pedido. Sin
embargo, la informacin que se encuentra en la parte superior del formulario, y
que se llena a mquina, es la misma para todas las partes ordenadas ms
abajo. Por lo tanto cada tupla consiste en una parte de datos que son variables
y datos del pedido que se duplican para cada parte ordenada.
Grafo de Dependencia
Una vez que los datos han sido puestos en primera forma normal, resulta
conveniente descomponer la relacin en un nmero de relaciones ms
pequeas, cada una en forma normal superior, de modo de optimizar el
almacenamiento y usar su funciones. Para esto resulta necesario reconocer las
dependencias existentes. Un grafo exhibe los distintos tipos de dependencias
que existen, y enfatizan que hemos investigado completamente cada
dependencia.
El grafo simple no est diseado para mostrar dependencias. Para hacer
utilizable a este grafo, se agregan colores pueden expresarse en blanco y
negro mediante distintos tipos de lneas. Discutiremos estos tipos de lneas en
trminos de la dependencia que cada uno representa. En las figuras que
siguen las formas grficas aparecen a la izquierda y se utilizan para constituir
un grafo completo. A la derecha se puede observar una forma simblica para
describir dependencias nicas.
Dependencia nica
En la figura vemos un arco que conecta dos vrtices A y B. A es la cola y B es
la cabeza de la "flecha". Esto significa que B depende de A. Es decir dado un
valor de A podemos predecir de A. Es decir, dado un valor de A podemos
predecir cul ser el valor de B.
Dependencia total
La dependencia total se define como una dependencia bilateral o simtrica. Es
decir, si C depende de D, en consecuencia D ser dependiente en forma similar
de C. Esto se expresa en la figura mediante una arista (sin una flecha) que une
C y D. Para enfatizar la dependencia total, se usa una lnea doble o una lnea
ms gruesa. Esto representa una medida de seguridad para verificar que el
usuario no dibuje un arco e inadvertidamente omita la flecha. Simblicamente
se utiliza una doble flecha.
Dependencia completa
La variable G depende en forma completa de otras dos variables E y F, lo cual
puede ilustrarse como se ve a la izquierda de la figura. Pero as no es
representada adecuadamente la dependencia completa, ya que el valor de G
no depende de E o F, independiente, sino que depende de ambos valores. Por
lo tanto en el centro de la figura A, vemos una forma mejor; la arista que une E
y F no intenta demostrar una dependencia entre E y F, por lo tanto se dibuja en

lneas de trazos; a partir del centro de esta lnea de trazos, se dibuja un arco
dirigido hacia G para indica que G depende de ambas variables E y F.
Dependencia transitiva
Supongamos que dos variables, K y L, dependen de J. Si puede verificarse que
L depende en forma primaria de K, existira una dependencia transitiva.
Mostramos a la izquierda de la figura B que L. depende de J o de K. Ms
apropiado s el grafo del centro de la figura B, donde podemos ver que L est
definida por K la cual, a su vez, est determinada por los valores de J.
Simblicamente indicamos una dependencia transitiva de L respecto de J
mediante una flecha de trazos desde J a L, como puede verse a la derecha de
la figura B.
Ejemplo
En la figura B se presenta un grafo de dependencia hipottico. En el mismo se
dibujan las relaciones de dependencia entre atributos para una aplicacin de
remuneracin. EMPNO y DEPTNO estn subrayadas en la figura para expresar
que ambas son partes de una clave compuesta para la relacin. Una lnea
gruesa conecta EMPNO a EMPNOM para indicar que si nombre de empleado y
existe una dependencia total.
Varios atributos dependen directamente del nmero de empleados:
TITL es el ttulo de la tarea del empleado
PAYLVL es un carcter que indica el nivel de
sueldo del empleado.
HORAS representa el nmero de horas que el
empleado ha trabajado la presente semana.
PAYRT est apuntado a PAYLVL indicando que el
rgimen de pago es transitivamente dependiente del
nivel de pago.
La lnea de trazos que une PAYRT y HORAS indica que ambas participan en
una dependencia completa por la cual el receptor es PAYAMT, el valor pagado
para esta semana.
A la derecha de la figura, encontramos los atributos que dependen del nmero
de departamento. Obsrvense la dependencia total entre nmero y nombre del
jefe del mismo (MGRO y MGRNM).
Hay solamente un atributo que es completamente dependiente de ambas
partes de la clave compuesta, es decir, el nmero de proyecto, PROJNO.
5. Segunda Forma Normal

Una relacin est en segunda forma normal (2FN) solamente si todos los
atributos son dependientes en forma completa de la clave.
Descripcion De La Segunda Forma Normal (2 Fn)
Su nombre ya nos indica el hecho de que la segunda forma normal es por lo
general el prximo paso de normalizacin y descomposicin. Para ser
accesible a la normalizacin, y poder ser puesta en segunda forma normal, la
relacin debe poseer las siguientes propiedades:
Debe estar en primera forma normal
Debe tener una clave compuesta.
La consecuencia inmediata de los requerimientos expresados ms arriba es
que cualquier relacin en primera forma normal que tiene una clave simple,
est automticamente en segunda forma normal. Comencemos con un ejemplo
en forma de tabla de una relacin consistente en 17 atributos, que se presenta
en la figura. La misma se encuentra en primera forma normal y tiene una clave
compuesta que consiste en dos atributos P y Q. Estos estn subrayados en la
figura para mostrar que sirven como clave. La tupla de relacin puede tambin
escribirse linealmente en forma simblicamente:
R = (A,B,C,D,E,F,G,H,I,L,M,N,O,P,Q)
El prximo paso es crear un grafo de dependencia, presentando aqu como
figura. Debe notarse que este grafo se crea examinado con conocimientos y
atributos para determinar como participan y relacionan entre ellos.
No resulta suficiente analizar la matrz de relacin, la cual puede hacernos
creer que existe una dependencia debido a que la muestra de la cual se ha
extrado dicha relacin es pequea. Si somos inducidos a error por los datos
existentes y construimos una dependencia donde esta no existe, se plantear
un problema. Cuando lleguen nuevos datos que contradigan la dependencia,
deber dejarse de lado el esquema completo.
Supongamos en consecuencia que el grafo que se puede observar en la figura
ha sido derivado en forma funcional y que expresa correctamente las
dependencias. Resulta claro a partir de este grafo que los atributos que parten
de P son dependientes solamente de este. De un modo similar los que parten
de Q dependen solamente de este ltimo. Solamente aquellos que parten de la
lnea de trazos que conecta a P y Q tienen dependencia completa de ambos.
Esta es la gua para la descomposicin.
Descomposicin
La figura contiene 3 sub-rboles, la base de nuestra descomposicin.
Definimos una subtupla general en base a cada sub-rbol y en consecuencia:
P' = (P,A,B,C,E,H,K)

Q' = (Q,F,G,J,N)
PQ = (P,Q,D,I,L,M,O)
Aqu la raz de los sub-rboles de la izquierda y la derecha. P y Q, se convierte
en la clave de sus respectivas subtuplas; ambos. P y Q forman la clave
compuesta para la subtupla PQ.
Proyeccin
El prximo paso es proyectar la relacin R sobre cada una de estas subtuplas
para formar tres nuevas relaciones, y en consecuencia.
P' = proyectar R(P')
Q' = proyectar R(Q')
PQ = proyectar R(PQ)
Las relaciones as formadas nos dan tres nuevas sub-relaciones. Una
subrelacin es la relacin que deriva de una relacin mayor. Las subrelaciones
ilustradas en la figura estn correlacionadas por medio de los componentes de
sus claves. La clave compuesta P y Q de la relacin original R. es tambin la
clave de la sub-relacin PQ. P y Q tienen a P y Q respectivamente como
claves. La lnea de trazos en la figura indica que Q est correlacionada con PQ
por medio de la componente Q y P est correlacionada con PQ por medio de P.
Para restablecer la relacin original R debemos juntar estas tres subrelaciones
en algn orden, indicado simblicamente como:
R = juntar P [juntar PQ, (Q)] (P) = juntar Q[juntar PQ P(P)] (Q).
Grafos
La nueva sub-relacin que se ve en la figura se presenta en forma de grafo en
la figura siguiente. Existe una considerable analoga entres estas figuras y la
figura anterior. Lo importante es la diferencia. En PQ existe una lnea de trazos
que conecta los componentes de la clave compuesta P y Q en el centro de la
figura. Los arcos parten del centro de esta lnea de trazos hacia todos los
componentes de P y Q, los cuales son dependientes en forma completa de
ambos, es decir de P y Q. Una lnea de puntos conecta P en la relacin PQ a P
de la relacin P. Esto representa la correspondencia entre ambas veces P. Una
lnea de puntos conecta de un modo similar Q en PQ a Q en Q para indicar una
correspondencia similar.
Efectos
El efecto de esta descomposicin puede no resultar inmediatamente claro.
Debemos insistir en que ninguna relacin correcta debe contener tuplas
duplicadas. La relacin original R contiene muchas subtuplas duplicadas P' y

Q'. Las mismas han sido eliminadas durante la descomposicin. Esto facilita en
forma extraordinaria la actualizacin y otras importantes operaciones que
afectan a estas relaciones, las cuales sern aclaradas en los ejemplos que
siguen.
Ejemplo de inventario
Vamos a utilizar ahora un ejemplo prctico para demostrar la normalizacin. En
la figura se observa una parte de la matrz de relacin PW.
Pueden verse los nombres de los atributos simblicos y sus significados, pero
no sus valores. Las columnas no aparecen en ningn orden en particular. Debe
observarse la clave compuesta que distingue cada tupla, que abarca el nmero
de pieza y el nmero de depsito PNO y WNO.
Arbol de Dependencia
El medio para descomponer la relacin es el rbol de dependencia que se ve
en la figura. Este rbol ha sido construido solamente teniendo en cuenta la
dependencia completa, y no muestra las dependencias total o transitiva, que se
describe ms adelante, si es que las mismas existen.
Como podamos esperar, aparecen tres sub-rboles. El sub-rbol de la
izquierda, con raz PNO, contiene los atributos que se aplican solamente a la
pieza o parte. El sub-rbol de la derecha con raz WNO describe cada depsito.
EDl sub-rbol del centro corresponde a las partes y al depsito, y describe la
cantidad de partes disponibles en el depsito, QOH, y el nmero de cajn o
estante, BIN (o algn otro parmetro de ubicacin), donde dichas partes
pueden ser halladas.
El prximo paso es definir tres tuplas generales para cada sub-rbol,
P = (PNO, DESC, PR, UNIT)
W = (WNO, WAD, FUE)
P/W = (PNO, WNO, BIN, QOH)
La descomposicin consiste en proyectar la relacin PW sobre cada una de
estas tuplas para obtener tres nuevas sub-relaciones:
P = proyectar PW(P)
W = proyectar PW(W)
P/W = proyectar PW(P/W)
La descomposicin en la figura muestra las tres relaciones como matrices; la
lnea de trazos indica como se vinculan las relaciones.

Efecto
Discutiremos ahora algunas de las ventajas obtenidas mediante la
descomposicin. Si estas relaciones se utilizan para el control de inventario.
nuestra preocupacin ser cuantas piezas de cada tipo estn disponibles en un
depsito en particular. Cuando se retiran piezas o se reciben nuevos envos la
cantidad disponible, QOH ser la variable de cambio. La actualizacin consiste
en poner al da sub-relacin P/W la cual ahora contiene solamente malos
componentes en lugar de los nuevos P/W.
Existe una tupla P en la sub-relacin de pieza o parte, P, para cada parte y una
tupla. W, en la sub relacin W, para cada depsito y estos ltimos
probablemente no sern muchos. Consideremos la facilidad de efectuar
cambios en un depsito en particular. Si un atributo de uno de los depsitos
vara entraremos en W para efectuar el cambio solamente en una tupla. En la
primera forma normal para PW tenamos que encontrar todas las tuplas en las
cuales el valor de WNO esta el particularmente deseado, y efectuar el mismo
cambio en cada una de ellas. Si dicho depsito almacenaba 100 partes, como
consecuencia deba variar 100 tuplas de PW. El procedimiento de actualizacin
se aplica tambin a las descripciones de partes. Si el precio de alguna parte o
pieza cambia, este cambio es independiente del depsito en el cual se
almacena dicha parte. Solamente se efecta un cambio en P a diferencia de los
muchos que hubieran sido requeridos para PW.
6. Tercera forma normal
Una relacin se encuentra en tercera forma normal (EFN) si no existen
transitividades entre sus atributos y si ya se encuentra en 2 FN.
Descripcin
Una relacin R a poner en tercera forma normal debe estar en la segunda
forma normal. Es muy comn que R sea una sub-relacin; la relacin original
estaba en primera forma normal (para ponerla en segunda forma normal fue
descompuesta en varias sub-relaciones). Estas son ahora candidatas a una
descomposicin adicional.
Recordamos que las propiedades de la segunda forma normal (2Fn) son:
Tenemos una matrz m x n con un valor determinado para cada
componente de cada tupla.
Cada valor es obtenido a partir de un dominio
propiamente definimos
Cada valor contiene una clave, ya sea simple o compuesta
Cada componente no clave es dependiente en forma completa
de su clave.

En consecuencia es evidente que tenemos, o bien una clave simple, o una

clave compuesta de la cual todos los componentes no clave son dependientes
en forma completa.
El objeto de esta fase es determinar todas las dependencias transitivas; la
descomposicin producir a continuacin sub-relaciones para las cuales no
existirn dependencias transitivas -la definicin de la tercera forma normal
(EFN)-.
Una dependencia transitiva abarca como mnimo tres componentes. Si los
componentes fueran ms, la dependencia mltiple puede derivarse en varias
dependencias atransitivas de tres componentes solamente dada una. Por lo
tanto dirigiremos nuestra atencin a una dependencia transitiva simple de tres
componentes. Tal dependencia puede expresarse como:
Q ---> A ----> B
En la cual se dice que B depende de A y que A depende de Q. La transitividad
existe debido a que el valor de B depende en la ltima instancia del valor de Q.
La dependencia transitiva es degenerada si cualquiera de las dependencias
anteriores es total. Esto es, podemos prever que la relacin de Q a A es
muchos-unos, donde varios valor nico de A. Dado un valor tal Q el valor de A
queda determinado. La inversa no se aplica y en consecuencia no existe una
dependencia total: dado un valor de A el valor correspondiente de Q no queda
determinado a menos de que se trate de una dependencia total.
El ahorro que surge de colocar la relacin en tercera forma normal aparece a
raz de la granularidad del dominio involucrado. Se puede prever que:
num dominio (Q)> num dominio (A) > num dominio (B)
Determinacin de al dependencia transitiva
Si el grafo utilizado para llevar la relacin a la segunda forma normal es
completo en termino de las transitividades existentes, no resulta necesario un
grafo adicional. El grafo para convertir a la segunda forma normal requiere
solamente que todas las dependencias completas y parciales sean conocidas.
Supongamos que no hemos establecido todas las dependencias transitivas. Se
presenta una situacin simple en la figura anterior donde A, B y C son
dependientes de Q. SI suponemos que existe una dependencia entre A, B y C
son dependientes de Q. Si suponemos que existe una dependencia entre a y B
debemos confirmarlo en forma funcional.
Una dependencia total entre A y B en el grafo de la figura puede representarse
como se ve en la figura el arco desde A a B no muestra una dependencia de B
respecto de A inversamente el arco a partir de B hacia A muestra una
dependencia de A respecto de B; los arcos a partir de Q a A y a B nos muestra
la dependencia de cada una de stas respecto de Q. Esto puede observarse
nuevamente en la figura, donde una doble arista entre A y B indica la bi-

direccionalidad de esta dependencia. El hecho de que Q apunte a esta arista

nos muestra que cada una de las variables A y B es claramente dependiente de
aquella.
Como ejemplo sea Q el nmero PO, A el nmero de parte o pieza y B el
nombre de parte, A y B son totalmente dependientes y cada uno dependen de
Q.
Transitividad simple
Para la dependencia transitiva unilateral, la variable independiente apunta a la
variable dependiente, tal cual se presenta en el figura donde B depende de A.
El arco entre B y Q ha sido eliminando; la dependencia implcita de B respecto
de Q resulta obvia.
Si se presenta la dependencia inversa, debe gratificarse como se ve en la
figura.
Descomposicin
Dada una sub-relacin con una o ms dependencias transitivas, la
descomposicin consiste en partir la relacin en una o ms de una subrelacin, donde la variable intermedia aparezca como variable dependiente en
una y como variable independiente en la otra.
Caso simple Tenemos:
Q ---> A ----> B
Q ---> C
Dado que ambas, A y C dependen directamente de Q deben conservarse en
una sub-relacin Q, con clave Q.:
Q ---> A; Q ---> C
Debe separarse la relacin directa remanente, y colocarla en su propia subrelacin A' con la A:
A ---> B
Los grados de Q' y A'. Aqu la componente A relaciona Q' con A, a es la clave
simple de A'. Si bien A no es la clave de Q' es le medio de relacionar un valor
de Q en Q' con un valor de B en A' y se llama por lo tanto la clave externa de Q'
. Para crear Q' y A' debemos utilizar las subtuplas generales Q' y A' denifidas
en consecuencia:
Q' = (Q,A,C)
A' = (A,B) donde el subrayado indica una clave.

Este deben proyectarse sobre Q para obtener las sub-relaciones:

Q'= proyectar Q(Q')
A'= proyectar Q(A')
Caso Compuesto
Las dependientes transitivas mltiples han sido investigadas y exhibidas.
Tenemos en consecuencia.
Q --> C
Q --> A --> B1
Q --> A --> B2
Q --> A --> B3
La descomposicin separa nuevamente todas estas variables directamente
dependiente de la clase original en una subtupla. Q'' = (Q, A, C)
Las variables restantes son todas dependientes directa o totalmente de A o C y
se reorganizan de un modo similar. A'' = (A, B1, B2, B3); C'' = (C, D)
Deben construirse tres sub-relaciones por proyeccin:
Q'' = proyectar Q(Q'')
A'' = proyectar Q(A'')
C'' = proyectar Q(C'')
Aqu Q'', A'' y C'' aparecen como sub-rboles. Las mismas se relacionan por
medio de la clave externa de Q'' es decir A y C; esto se muestra mediante la
lnea de puntos entre A y A y entre C y C. Nos podemos mover directamente
entre las dos figuras sin la intervencin de pasos simblicos, utilizando
solamente manipulaciones grficas.
Descomposicin Grfica
Hemos discutido el enfoque simblico. Dado un grafo 2FN. Debemos
seleccionar en primer trmino los nodos apuntados por la raz que no sean
hojas. Los mismos se convierten en races de sus propios sub-rboles, A'' y C''.
Estos sub-rboles son eliminados de Q dejando en Q'' solamente los nodos A y
C, que son las races de A;; y C''.
Ejemplo de orden de compra

Examinaremos solamente una pequea porcin de la relacin orden de compra

que ha sido convertida en un grafo de dependencia. Para esta porcin de la
relacin compra PP, tenemos:
Las partes se compran utilizando el nmero de parte, PNO;
Un vendedor, VNDR est asociado a cada parte;
Cada vendedor tiene una clasificacin de forma de pago, PAYCLS.
Por lo tanto PAYCLS representa si el vendedor debe cobrar dentro de los 10
das, 30 das, 60 das, etc. La accin para convertir la relacin.
Tenemos aqu una relacin transitiva que puede ser representada en
consecuencia:
PNO ---> PAYCLS
Sabemos que la variable intermedia, el vendedor VNDR, es el que determina el
tipo de pago de modo tal que
PNO ---> VNDR --> PAYCLS
para poner esta relacin en la tercera forma normal, la misma se descompone
en dos sub-relaciones. Las dos sub-relaciones PV y VP, se forman por
proyeccin a partir de la relacin original PP de modo tal que:
PV = proyectar PP (PNO, VNDR); PV = proyectar PP (VNDR, PAYCLS).
La relacin PV relaciona partes con vendedores.
La identificacin del vendedor, VNDR es la clave externa par PV. La misma se
utiliza para entrar en la relacin VP, en la cual es la clave primaria.
Debe notarse que, para el mantenimiento, si cambia la clase de pago
solamente cambiara una entrada o tupla en VP y ninguna en PV. Para el caso
de PP hubiera cambiado muchas tuplas.
Ejemplo de inventario
Presentamos ahora una porcin de un ejemplo de inventario, al cual
corresponde el grafo parcial. Tenemos en este caso:
PNO es un nmero de parte
PNM es el nombre de parte y tiene dependencia
total con el nmero de parte
PREC es el costo de UNITS multiplicado por el nmero de partes

 PCL es la clase de parte, la cual da el tipo de parte

en trminos de su peso y de su forma.
WHN es el nmero de depsito donde est almacenada la parte.
WHLOC Es la ubicacin del deposito
FUE es la categora de seguro de incendio del depsivto.
Resulta claro a partir del grafo que el nmero de parte determina la
clasificacin de la parte, la cual a su vez determina parcialmente el deposito
donde est almacenada dicha parte. Usaremos esta dependencia transitiva,
que est circundada con lnea de trazos gruesos, para descomponer la relacin
en su tercera forma normal: PNO ---> WHN; PNO ---> PCL ---> WHN
La variable intermedia, clase de parte, PCL, es el medio de que disponemos
para descomponer el grafo. Se deja como ejercicio hallar las proyecciones y la
relaciones resultantes.
Ejemplo bancario
Consideremos parte de un ejemplo de banco donde cada depositante tiene un
nmero de cuenta que lo identifica. El depositante recibe una lnea de crdito.
Puede extraer dinero hasta dicho valor. La parte no utilizada de crdito puede
ser retirada cuando lo desee. Vemos que la lnea de crdito LNCR es
funcionalmente dependiente del nmero de cuenta CUET; el valor ya extrado
DEBIT es tambin dependiente del nmero de cuenta. El valor de crdito
disponible en este momento, DISP, es dependiente en forma completa de
ambos, LNCR y DEBIT.
Parecera que lo lgico es descomponer el grafo y volver a presentarlo. En
base a esto, P tiene como clave el nmero de cuenta CUENT. Debemos entrar
en P para obtener LNCR y DEBIT. Estas son claves externas para P; las
mismas forman la clave compuesta para entrar en Q y hallar el valor de la
variable completamente dependiente DISP.
Esto funcionara, pero hay una forma ms simple de resolver el problema. El
valor de crdito disponible en la actualidad es simplemente la diferencia entre
la lnea de crdito y el debido corriente. Todo lo que tenemos que hacer es
ejecutar una sustraccin. La relacin original no necesita contener DISP. dado
que ste se calcula simplemente durante el procesamiento. Por lo tanto
podemos sencillamente omitir Q.
Transitivas mltiples.
Establecemos de entrada la condicin simple de que Z sea dependiente en
forma transitiva de Q. Si existe ms de una variable intermedia de
dependencia, la transitiva no ser completa hasta que se especifiquen todas
dichas variables. Es decir, si bien empezamos con la condicin de transitividad,
Q ---> Z,

la condicin completa podra ser, Q ---> X ---> Y ---> Z

Ninguna condicin intermedia Q ---> X ---> Z --->; Q ---> Y ----> Z
sera suficiente para descomponer la original de la figura.
7. Cuarta forma normal
Dependencias multivaluadas
La tercera forma normal toma en cuenta la dependencia transitiva y provee una
reduccin ptima universal, excepto para los casos infrecuentes de
dependencia multivaluadas. Ha quedado claro en pocas recientes que es
posible una reduccin adicional en este caso, y esto es lo que se lleva a cabo
mediante la cuarta forma normal.
Existe una dependencia multivaluada cuando un valor de una variable est
siempre asociado con varios valores de otra u otras variables dependientes que
son siempre las mismas y estn siempre presentes. Esto se ilustra mejor con el
ejemplo presentado en la figura. La relacin FAB describe tejidos. La variable
independiente (con respecto a las dependencias (multivaluadas) es el nmero
de tejido FABNO. Con el se encuentra asociados un modelo (o patrn) y un
color. En la figura, el tejido 345 vienen en dos modelos y entres combinaciones
de modelo y color. En este caso se aplica el grafo de dependencia. Para hacer
mas clara que esta es una dependencia multivariable, una cabeza doble de
flecha apunta desde FABNO o PATRN y tambin desde FABNO a COLOR.
La ineficiencia en el registro de informacin y se resulta clara al examinar las
dos nuevas relaciones. La primera de stas, FABPAT lista el nmero de tejido
contra el modelo; en el segundo caso, FABCOL, lista el nmero de tejido contra
las combinaciones de color. Dado que la regla es que todas las combinaciones
de las variables dependientes multivaluadas deben prevalecer, resulta simple
reconstruir la relacin FAB a partir de las dos sub-relaciones que resultaron.
Descomposicin Para poner una relacin o sub-relacin en la cuarta forma
normal debe poder aplicarse lo siguiente:
Debe estar en la tercera forma normal.
Deben existir una o mas multidependencias.
Despus de construir el grafo de dependencia, el prximo paso es ejecutar
proyecciones utilizando la variable independiente y una de las variables
multidependientes.
FABPAT = proyectar FAB (FABNO, PATRN)
FABCOL = proyectar FAB (FABNO, COLOR)

El resultado son nuevas sub-relaciones que han sido utilizadas para ahorra
espacio y permitir una ms fcil actualizacin.
Ejemplo de profesor y texto
Consideremos otro ejemplo. Los cursos dictados en una escuela corresponden
a un nmero de curso. Asociada a cada nmero de curso se encuentra la
descripcin del mismo. Para cada curso existe una seleccin de textos y una
seleccin de profesores. Puede darse cualquier combinacin de texto y
profesor.
El grafo de dependencia. El mismo nos muestra una dependencia total entre el
nmero de curso y la descripcin del curso. Existe una multidependencia entre
texto y nmero de curso, y tambin entre profesor y nmero de curso.
Para descomponer la sub-relacin en sus relaciones ms pequeas, se
efectan tres proyecciones. Las sub-relaciones resultantes.