Bases de datos

BASES DE DATOS
• Modelos de Datos
• Sistemas Administradores (Gestores) de Bases de Datos (SGBDs o
DBMS's)
Modelos de Datos
Hablar del concepto lógico o físico de Base de Datos involucra un conjunto de
pensamientos concretos que hacen posible la absorción temática del
significado de los datos. La abstracción de los datos como una forma o un
comportamiento que hace posible concretar un “algo”, se asocia con un
esquema del conocimiento lógico, su semántica, condiciones y acciones, que
permiten la producción 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 través de los "Sistemas de Archivos"; donde cada uno de los archivos que se
creaban solo obedecían a una necesidad de almacenamiento más que a la
utilización funcional del dato. Por este motivo surgen los esquemas
conceptuales que son elaborados a través del análisis de procesos de las
áreas del negocio, los cuales involucran al "dato" como una consecuencia
lógica 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 símbolos que permiten estandarizar traducir dicho análisis a un
lenguaje semántico y sistemático que dispone de reglas de control y evaluación
del comportamiento del dato en el transcurso del tiempo, tanto en su
almacenamiento como en su utilización.
Estos modelos de datos, hacen posible que la lógica de un negocio pueda ser
estructurada de forma tangible a través de un esquema físico 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 través del
tiempo.
Los Modelos de Datos, también llamados modelos lógicos, 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 interpretación 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 parámetros de una forma o estilo de vida; dichos objetos
se modelan a través de propuestas que fueron estructuradas para así
poder estandarizar la forma de manipularlos. Dentro de estos modelos
tenemos:

o Modelo Entidad Relación (MER)
o Modelo Orientado a Objetos (MOO)
o Modelo Semántico
o Modelo Deductivo
• Basados en Registros: Otra forma de tratar lógicamente la información
suministrada por un sistema es a través de los "Registros", originalmente
concebidos por los sistemas de archivos (registro: conjunto de campos
que almacenan información de diferentes tipos), lo cual dió pie a la
estructuración de modelos lógicos tales como:
o Modelo Relacional (MR)
o Modelo de Red
o Modelo Jerarquico
Al modelar es importante conocer muy bien la semántica de estos modelos y lo
que es posible lograr con ellos.
En la Ingeniería de Software, el tratamiento de los datos Las Bases de Datos
dentro del ciclo de vida de un proyecto informático, están ubicadas dentro del
proceso del Diseño, "el CÓMO", estructurar la funcionalidad expuesta en los
requerimientos. El siguiente esquema escenifica esta situación:
_________

Sistemas Administradores (Gestores) de Bases de
Datos
Una vez terminado el diseño lógico a través de modelos basados en registros, se da
inicio al diseño físico 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 utilización de Modelos de
Datos específicos 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.
DISEÑO CONCEPTUAL
Cuando se trabaja bajo el análisis conceptual de una situación, nos referimos a la
abstracción de hechos reales de los cuales se emite un concepto o es posible hacer una
idea de ello. Para poder realizar la abstracción de un tema en un área específica, a nivel
informático, 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 creación del esquema conceptual donde por medio de este se podrá realizar
una descripción 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 símbolos (estándares) para la creación de este.
El diseño conceptual se hace independiente al sistema gestor de base de datos (DBMS)
que utilice el usuario para la implementación de esta.
Para modelar Conceptualmente es posible utilizar varios Modelos de Datos Un modelo
práctico para ilustrar el diseño conceptual es el modelo entidad relación.
Modelo Entidad Relación (MER)
Diseñado 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 demás objetos. Cada entidad tiene un conjunto de
propiedades y valores que la identifican de forma unívoca. Esta puede ser tanto tangible
(existencia física), 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:
cédula, nombre, dirección, 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 cédula pueden ser todos los enteros positivos.
Tipos de Atributos:
Simples: No divisible, es decir es un atributo atómico. Ejemplo: El atributo cédula, su
propiedad no tiene sentido dividirla, no tendrá significado para la entidad, ya que la
concepción de este es un número indivisible.
Compuesto: Está conformado por un conjunto de partes que en el momento de dividirlas
pueden formar otros atributos sin perder el sentido básico de la propiedad que está
calificando la entidad. Ejemplo: los atributos nombre, dirección pueden estar
conformados en su naturaleza funcional por varias partes. Si tomáramos el atributo
nombre con un valor de: JUAN PEREZ CORREA, sin perder la propiedad del mismo,
se podrán 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 sólo por razones de manejo a nivel del lenguaje de
consulta o programación 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
situación, es decir el atributo compuesto se trabaja como un atributo simple. Así se
puede concluir que un atributo compuesto es la suma (concatenación) de los valores de
los atributos simples que lo conforman.
Univaluados (univalorados o monovaluados): Son atributos que en el transcurso del
tiempo sólo toman un valor para una entidad en particular. Ejemplo: El atributo cédula,
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. También es característico 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 algún instante en el tiempo para una entidad
específica.

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 cálculo de los
siguientes valores:
PARAMETROS(salario_base, 5000), NOVEDADES(nro_horas_trabajadas, 240), el
valor que tendría 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 gráficamente así: los tipos de entidades por medio de
rectángulos 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 través de líneas. 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 función se denominan atributos claves, donde a partir de estos
se ejerce la restricción 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.
Gráficamente en el modelo E-R el atributo clave va subrayado dentro del óvulo.
TIPOS DE ENTIDADES FUERTE Y DÉBILES: 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 débiles no tienen atributos claves propios sino que dependen del que posee
una fuerte, pero si pueden tener atributos que identifiquen una clave parcial (foránea)
que la identifican como única dentro del tipo de entidad débil. Ejemplo: la entidad
ocupacion depende la existencia de una entidad persona, ya que sin esta no tendría
sentido. En el modelo E-R se esquematiza gráficamente a través de rectángulos dobles.
El atributo parcial se subraya con línea punteada.
VÍNCULOS o INTERRELACIONES(relaciones): La asociación entre uno o tipos de
entidades E1,E2,...,En define un vínculo R entre estas, donde R matemáticamente se
puede definir como el conjunto de vínculos 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). Expresándolo
de otra forma, es un subconjunto del producto cartesiano E1x E2x ... x En.
Ejemplo: Tenemos dos tipos de entidades Estudiantes y Curso, el vínculo o asociación
entre esta es INSCRITO EN, de la siguiente forma:
Gráficamente en el diagrama E-R los vínculos (asociaciones o relaciones) se
representan por medio de rombos, ejemplo:
Esta relación se conoce como binaria ya que se realiza entre dos tipos de entidad.
Existen las relaciones n-arias (entre más de 2 entidades), por ejemplo:

Y las relaciones recursivas como:
CARDINALIDAD: Especifica el número de ejemplares de vínculos en los que puede
participar una entidad. Las razones de cardinalidad más comunes para relaciones
binarias son: 1:1,1:N,M:N. A partir de estas aparecen las Restricciones de cardinalidad
y participación (integridad).
Los tipos de entidad débil siempre tienen una restricción de participación (dependencia
de existencia) con respecto a su vínculo identificador, porque una entidad débil 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 número de entidades participantes.
OTROS ELEMENTOS DEL MODELO E-R
Jerarquía de Generalización: Una entidad E es una generalización de un grupo de
entidades E1,E2, ... , En , si cada objeto de estas es también un objeto de la entidad E.
Ejemplo: el tipo de entidad VEHÍCULO es una generalización del tipo de entidad
BICICLETA, ya que todas las bicicletas son vehículos. El tipo de entidad PERSONA es
una generalización de las entidades HOMBRE y MUJER. Se puede decir que estos son
subconjuntos de la generalización (Es_un o Es_parte_de).
Lo opuesto a la generalización es la ESPECIALIZACIÓN (son miembros de la entidad
general).

Ejercicio: Extraer las posibles generalizaciones de la siguiente especialización:
{silla negra, mesa negra, silla blanca, mesa blanca}
DISEÑO LÓGICO
Una vez establecido el modelo conceptual del problema o situación, el diseño lógico 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
lógico. El objetivo es convertir el esquema conceptual de datos en un esquema lógico
que se ajuste al gestor de la base de datos que va a ser utilizado (el DBMS). Para
escenificar esta situación 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
• Características para pasar de un MER a un MR
• Normalización y Dependencia Funcional
• Algebra Relacional
• SQL
Modelo Relacional (MR)
Propuesto por Codd en 1970 como un modelo simple, potente y formal para representar
una situación y de enfocar y analizar trabajos relacionados con la gestión de la base de
datos, como la redundancia, las restricciones, la forma de acceso, etc. El formalismo y
una base matemática son las temas fundamentales en el desarrollo de las bases de datos
relacionales.
Conceptos del MR:

A través de esta gráfica se escenifican los componentes básicos de un MR. Los
aspectos más importantes que se formalizan en este son: la definición de la estructura, el
control integridad y la manipulación de los datos, . Para lograr esto maneja los
siguientes conceptos: relación, dominio, tupla, cardinalidad, atributo, grado y clave
(primaria y foránea).
• Relación: Es el elemento básico 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 relación 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 función de ayudar a interpretar el significado de los valores que están en cada
fila de la tabla. Como ejemplo, la gráfica representa la relación PERSONA.
Una forma lógica de diferenciar entre el término Relación y el término Tabla es
la siguiente: una relación es una especie abstracta de objeto; y una tabla es una
representación concreta de tal objeto abstracto. Las tablas poseen ciertas
propiedades, todas ellas consecuencia inmediata de la relación. Estas son:
- No existen tuplas repetidas: Esta propiedad es consecuencia del hecho de que
el cuerpo de la relación es un conjunto matemático( es decir, un conjunto de
tuplas) y en matemáticas por definición los conjuntos no incluyen elementos
repetidos.
- Las tuplas no están ordenadas: Esta propiedad sirve para ilustrar la diferencia
entre una relación y una tabla, porque las filas de una tabla tienen un orden
obvio de arriba hacia abajo, en tanto que las tuplas de una relación carecen de tal
orden.

- Los atributos no están ordenados: Esta propiedad desprende el hecho de que la
cabecera de una relación se define también como conjunto. Las columnas de una
tabla tienen un orden evidente de izquierda a derecha, pero los atributos de una
relación carecen de tal orden.
- Todos los valores de los atributos son atómicos.
• Dominio: (D). Es un conjunto de valores atómicos que puede adoptar un
atributo en particular. Un dominio reune características de tipo,
comportamientos propios y distinguibles. Por ejemplo: el conjunto de
direcciones de la ciudad de Medellín, 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 definición matemática de las relaciones se basa en la noción de dominio.
Dados varios atributos A1,A2,...,An, con dominios D1,D2,...,Dn, un caso de
relación de grado está dada por el subconjunto del producto carteciano D1 x D2
x ... x Dn.
En conclusión, un dominio debe tener: un nombre, un tipo de dato y un formato.
• Esquema Relacional: Está compuesto por un nombre de relación, 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, Ubicación, Ciudad
PERSONA(Cedula, Nombre, Ubicación, Ciudad)
Cada atributo Ai es el nombre de un papel desempeñado por algún dominio D,
denotado por D(Ai), en el esquema R. El número de atributos, n, del esquema
de relación se denomina grado de una relación, y el número de tuplas es la
cardinalidad.
Una relación, r, del esquema de relación, 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 definición y función es similar a la definida en el MER. La clave de
una relación es un conjunto de atributos de la relación que identifica de manera
única cada tupla. Los tipos de claves son: primaria y candidata.

Restricciones de Integridad en los Esquemas Relacionales:
La restricción se interpreta como una condición que debe ser cumplida por una relación
específica. Se tienen los siguientes tipos de restricciones:
• Restricción de Clave: Se especifican las claves de cada esquema de relación;
estos valores deben ser únicos para cada tupla en cualquier caso de ese esquema
de relación. Ejemplo: Para el esquema de relación PERSONA la restricción por
clave está dada por el atributo Cedula. En otros esquemas puede darse por la
concatenación de varios atributos.
• Restricción de Ingridad de entidades: Establece que ningún valor de clave
primaria puede ser nulo, ya que el valor de nulo no podría 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 relación que haga referencia a otra relación debe
referirse a una tupla existente en esa relación. Esta restricción permite el manejo
de clave ajena(externa) o foránea , 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.
Características importantes para pasar de un MER a
un MR
- Eliminación de Identificadores Externos
- Eliminación de atributos compuestos y polivalentes
- Transformación de entidades
- Transformación de interrelaciones 1:1
- Transformación de Interrelaciones de 1:n
- Transformación de interrelaciones n:m
- Transformación de relaciones n-arias y recursivas.

Normalización y Dependencia Funcional
Normalización
La normalización es un proceso que consiste en comprobar que las tablas (también
denominadas relaciones en terminología 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 representación mediante un
esquema relacional de las entidades y relaciones del modelo conceptual (diagrama E-R).
Mediante la normalización se pueden solucionar diversos errores en el
diseño de la base de datos así como mejorarlo. También 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 restricción sobre las
posibles tuplas que podrían formar un ejemplar de relación r de R. La restricción dice
que, para cualesquier dos tuplas t1 y t2 de r tales que t1[X] = t2[X], debemos tener
también t1[Y] = t2[Y]. Esto significa que los valores componentes de Y de una tupla de
r dependen de los valores del componente X, o están determinados por ellos; o bien, que
los valores del componente X de una tupla determinan de manera única (o
funcionalmente) los valores del componente Y. También decimos que hay una
dependencia funcional de X a Y o que Y depende funcionalmente de X.
Sean a y b atributos de una misma tabla o relación 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 también 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. Nóse que el concepto de dependencia funcional no depende de la
extensión concreta (contenido) que en un momento determinado tenga la tabla sino de
cualquier posible extensión que pudiera tener.
Los atributos a y b pueden ser simples o compuestos (formados por la agregación 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 ningún 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 más la dirección
también se determina el nombre.
Proyectividad. Si x -> y+z entonces x -> y. Ejemplo: si a partir del dni es posible
deducir el nombre y la dirección
de una persona, entonces con el dni es posible determinar el nombre.
Aditividad. Si x -> y y z -> w entonces x+z -> y+w. Ejemplo: si con el dni se
determina el nombre y con la
dirección el teléfono de una persona, entonces con el dni y la dirección podrá
determinarse el nombre y el teléfono.
Transitividad o enlace de dependencias funcionales. Si x -> y e y -> z entonces x
-> z. Ejemplo: si con el dni
puede determinarse el código de la provincia de residencia de una persona y con éste
código puede determinarse el
nombre de la provincia, entonces con el dni puede determinarse el nombre de la
provincia. Éste es el mecanismo
básico de funcionamiento del enlace entre tablas a partir de claves ajenas.
Reglas de normalización
El punto de partida del proceso de normalización es un conjunto de tablas con sus
atributos, el denominado esquema
relacional. Se pretende mejorar dicho esquema de datos. Se dice que una tabla están en
una determinada forma normal si
satisface un cierto número de restricciones impuestas por la correspondiente regla de
normalización. La aplicación de una
de estas reglas a un esquema relacional produce un nuevo esquema relacional en el que
no se ha introducido ningún 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 normalización, 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 descomposición tiene que conservar dos propiedades fundamentales:
1.No pérdida de información. 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 intersección 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 pérdida de dependencias funcionales.
La normalización 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
normalización. Evidentemente las
reglas de normalización imponen una serie de restricciones en lo relativo a la existencia
de determinados esquemas
relacionales. Según 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 normalización de
forma incremental más 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 verificación 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 semántica 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 ningún subconjunto de ella.
Se pretende garantizar una
correcta elección de claves y eliminar redundancias. Si la clave están 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 algún otro
atributo de la misma tabla. Una relación
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 más restrictiva que la tercera y tiene la interesante
propiedad de que su cumplimiento
implica la satisfacción de FN3 o sea que FNBC -> FN3.
Ejemplo: Dependencias funcionales
Ejemplo:
a.Empleado_departameto
nombre nss fecha_n dirección numero_dep nombre_dep
b.Empleado_proyecto
nss numero_proy horas nombre_emp 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 operación es una nueva relación que podemos manipular
posteriormente.
Operaciones
- Seleccionar (σ)
- Proyectar (π)
- Operaciones de Teoría de Conjuntos: Unión (∪), Intersección (∩), Diferencia (-),
Producto Cartesiano (X).
- Reunión (α)
* Seleccionar (σ)
Por medio de esta operación se posibilita la selección de un subconjunto de tuplas de
una relación que corresponden a una condición (columna OPERADOR valor)determinada. El
grado (total de columnas de la Relación), se conserva.
Formato de Uso: σ(condición) (RELACION)
Esta operación es conmutativa, es decir: σ(condición1) ( σ(condición2) (R) ) = σ(condición2) (
σ(condición1) (R) )
Ejemplos:
PERSONA
Cedula Nombre
Primer_Apellid
o
Segundo_Apellid
o
Sexo
Direcció
n
Telefono Salario
71134534 Juan Mesa Uribe M
Cra 25
22-1
2567532 1,600,000
23423445
Ana
María
Betancur Bermudez F
Cra 45
11-13
3433444 1,300,000
12453535 Gloria Betancur Garces F
Tr. 12
43-5
2756533 1,700,000
75556743 Pedro Ochoa Pelaez M
Cll.6ta
14-45
2686885 1,200,000
43533322 Patricia Angel Guzmán F
Cll. 45
23-1
2674563 1,350,000

78900456 Carlos Betancur Agudelo M
Cir. 5 12-
5
4445775 1,500,000
La selección, permite extraer todas las filas (tuplas) que cumple una condición
determinada. Esta condición permite la utilización de los operadores de comparación:
=,>,<,>=,≠, además de los conectores lógicos "y" - "o":
a. σ cedula = 71134534 (PERSONA)
Resultado:
Cedula Nombre
Primer_Apellid
o
Segundo_Apellid
o
Sexo
Direcció
n
Telefono Salario
Cra 25
22-1
2567532 1,600,000
b. σ sexo ='F' (PERSONA)
Resultado:
Cedula Nombre
Primer_Apellid
o
Segundo_Apellid
o
Sexo
Direcció
n
Telefono Salario
23423445
Ana
María
Betancur Bermudez F
Cra 45
11-13
3433444 1,300,000
Tr. 12
43-5
2756533 1,700,000
c. σ (primer_apellido ='Betancur') y (sexo='F') (PERSONA)
Resultado:
Cedula Nombre
Primer_Apellid
o
Segundo_Apellid
o
Sexo
Direcció
n
Telefono Salario
23423445
Ana
María
Betancur Bermudez F
Cra 45
11-13
3433444 1,300,000
Tr. 12
43-5
2756533 1,700,000
d. c. σ (sexo = 'M'') o (Salario >=1,350,000) (PERSONA)
Resultado:
Cedula Nombre Primer_Apellid Segundo_Apellid Sexo Direcció Telefono Salario

o o n
Cra 25
22-1
2567532 1,600,000
Tr. 12
43-5
2756533 1,700,000
75556743 Pedro Ochoa Pelaez M
Cll.6ta
14-45
2686885 1,200,000
43533322 Patricia Angel Guzmán F
Cll. 45
23-1
2674563 1,350,000
78900456 Carlos Betancur Agudelo M
Cir. 5 12-
5
4445775 1,500,000
* Proyectar (π)
Esta operación permite seleccionar algunas columnas de una relación.
Formato de Uso: π<lista de Atributos> (RELACION)
Ejemplos:
Se construyen con base en la Relación anterior: PERSONA.
a. πcedula, nombre, primer_apellido, segundo_apellido (PERSONA)
Resultado
Cedula Nombre Primer_Apellido Segundo_Apellido
71134534 Juan Mesa Uribe
23423445
Ana
María
Betancur Bermudez
12453535 Gloria Betancur Garces
75556743 Pedro Ochoa Pelaez
43533322 Patricia Angel Guzmán
78900456 Carlos Betancur Agudelo
b. πcedula, salario (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 operación SELECCIÓN combinada con la operación PROYECCIÓN, 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 están determinadas por el Lenguaje SQL, bajo
estándares determinados los cuales pueden ser utilizadas de forma básica o avanzada
según el DBMS utilizado.
• SELECT
• Operaciones Adicionales 1

• Tutorial Sql (.pdf)
• EJERCICIOS
Las operaciones SQL correspondientes al SELECT se realizarán con el siguente
ejempo:
PERSONAS
Cedula
Nomb
re
Primer_Apel
lido
Segundo_Ape
llido
Sex
o
Direcci
ón
Telefo
no
Salario
Cedula_
Sup
Cod_d
ep
711345
34
Juan Mesa Uribe M
Cra 25
22-1
25675
32
1,600,0
00
2342344
5
3
234234
45
Ana
María
Betancur Bermudez F
Cra 45
11-13
34334
44
1,700,0
00
4389023
1
2
124535
35
Gloria Betancur Garces F
Tr. 12
43-5
27565
33
1,350,0
00
7113453
4
3
755567
43
Pedro Ochoa Pelaez M
Cll.6ta
14-45
26868
85
1,700,0
00
4389023
1
1
435333
22
Patrici
a
Angel Guzmán F
Cll. 45
23-1
26745
63
1,350,0
00
7113453
4
3
789004
56
Carlos Betancur Agudelo M
Cir. 5
12-5
44457
75
1,500,0
00
7555674
3
1
734567
89
Mario Gómez Angel M
Cr. 53
23-1
34567
89
1,200,0
00
2342344
5
2
438902
31
Claud
ia
Gonzalez Beltran F
Cll. 10
14-1
26603
56
1,800,0
00
4389023
1
0
789007
00
Fabio Solano Pérez M
Tr. 3
32-1
43456
78
1,200,0
00
7555674
3
1
DEPENDIENTES
Cedula Nombre_Dep Sexo FechaN Parentesco
78900456 Juanita F 12-Abr-95 Hija
78900456 Oscar M 15-Ene-89 Hijo
23423445 Hector M 23-Dic-67 Cónyuge
71134534 María F 05-Mar-60 Cónyuge
71134534 Gloria F 27-Nov-97 Hija

75556734 Jorge M 14-Mar-96 Hijo
DEPARTAMENTOS
Codigo_Dep Nombre_Dep Cedula_Jefe
0 Gerencia 43890231
1 Teleinformatica 75556734
2 Desarrollo 23423445
3 Soporte Técnico 71134534
PROYECTOS
Numero_Proy Nombre Lugar Codigo_Dep
129001
Registro y
Matrícula
Bloque
21
2
139001 Red Lan
Bloque
14
1
139002
Instalación nuevo
Switche
Bloque
21
1
129002 Notas Campus 2
129003
Paso de
aplicativos
FOXPRO A
COBOL
Bloque
21
2
149001
Inventario de
HW y SW
Minas 3
149002 Licenciamiento Campus 3
149003
Evaluación de
equipos PC's
Bloque
18
3
1. OPERACIÓN SELECT
La sintaxis básica de esta operación es:
SELECT <lista de atributos>
FROM <lista de tablas>
WHERE <condiciones>
Ejemplos:
a. Select básico. Se desea obtener la cédula y el nombre de todas las personas que
trabajan en la compañía.

SELECT cedula, nombre
FROM personas
Similar la operación el álgebra relacional sería:
πcedula, nombre (PERSONAS)
Resultado/
Cedula Nombre
71134534 Juan
23423445 Ana María
12453535 Gloria
75556743 Pedro
43533322 Patricia
78900456 Carlos
b. Select con clausula WHERE. Se desea obtener toda la información de la persona
cuya cédula sea igual a 12453535.
SELECT nombre,primer_apellido,segundo_apellido,direccion,telefono
FROM personas
WHERE cedula = 12453535
Similar la operación el álgebra relacional sería:
π nombre, primer_apellido, segundo_apellido, direccion, telefono (σcedula = 1245353 (PERSONAS) )
Resultado/
Nombre Primer_Apellido Segundo_Apellido Dirección Telefono
Gloria Betancur Garces Tr. 12 43-5 2756533
c. En la clausula WHERE es posible utilizar los conectores lógicos AND - OR. Se
necesita la cédula 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 utilización del comodín '*'. Se desea obtener la
información 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 información:
SELECT dependientes.*
FROM personas, dependientes
AND sexo = 'M'
AND dependiente.cedula = personas.cedula
Resultado/
e. Utilizando alias o sinónimos de trabajo a las tablas del Select. Estos se utilizan por
facilidad en el manejo de la instrucción. La misma consulta anterior:
SELECT d.*
FROM personas p, dependientes d
AND sexo = 'M'
AND d.cedula = p.cedula
Resultado/
f. Cuando se necesita extraer información 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 compañía:
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 más significativas en el Select es el COUNT, la cual se utiliza
para contar la cantidad de registros que cumplen con una condición específica:
g.1 Mostrar el total de empleados en la compañía:
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 cuántos salarios diferentes o distintas se pagan en la compañía:
SELECT count(distinct salario)
FROM personas
Resultado/
6
h. Cláusula WHERE compara sus campos comunmente con valores únicos, pero
tambien es posible comparar con un "conjunto" de valores. Esto es realizable a través
del operador IN. Ejemplo, se desea saber qué empleados están involucrados en los
proyectos 139001 o 139002.
h.1 Forma básica:
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. Operación Select con anidamientos. La clausula WHERE comunmente compara los
campos con valores exactos, pero también es probable utilizarla comparando sus
campos con otras sentencias Select. Esta forma también 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 utilización de la cláusula 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 información nula a través de la
cláusula NULL. Ejemplo, Mostrar los empleados que no tengan asignado salario:
SELECT *
FROM personas
WHERE salario IS NULL
k. Otra cláusula 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 operación de Select también es posible utilizar funciones agregadas para:
sumar (SUM), maximizar (MAX), minimizar (MIN) y promediar (AVG). Se pueden
utilizar al nivel de la cláusula SELECT o en la cláusual HAVING (que veremos
posteriormente. Ejemplo, el total pagado por la compañía, el máximo y el mínimo
salario y el promedio pagado:
SELECT sum(salario), max(salario), min(salario), avg(salario)
FROM personas
m. Agrupación de tuplas y aplicación de condiciones para ellas. Aquí se utilizan dos
cláusulas nuevas: GROUP BY, la cual agrupa tuplas según las columnas puestas en la
cláusula Select; HAVING, permite hacer operaciones sobre estas agrupaciones.
Veamos:
m.1 Mostrar el número y el nombre del proyecto en donde trabajen más 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 cláusula WHERE además de las anteriores instrucciones también puede utilizar la
instrucción LIKE, que le sirve para encontrar información string no precisa. Veamos el
siguiente ejemplo:

SELECT nombre, numero_proy
FROM proyectos
WHERE nombre LIKE '%lic%'
o. En la cláusula Select también es posible realizar operaciones aritméticas '+', '-', '*',
con los campos de valor:
SELECT salario*1.18
FROM personas
WHERE salario < 1200000
p. Una cláusula más que podemos utilizar en la operación Select es la que me permite
dale un orden a las tuplas, ORDER BY, según el o los criterios indicados a través 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 información de un
Sistema de Transportes intermunicipales:
TERMINALES_TRANSPORTE (cod_terminal, nombre, ciudad, estado)
VIAJES(número, transportadora, días)
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 información sobre viajes de líneas
aéreas. Cada VIAJE se identifica con un número de viaje, y consta de uno o más
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
específicos. 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 números de viaje y los días de todos los viajes o trayectos de
viaje que salen del terminal codigo ‘CA001’ y llegan al terminal código ‘BO001.
Solución 1:
SELECT num_viaje, num_trayecto,fecha
FROM viajes_realizados
WHERE cod_terminal_sale = 'CA001'
AND cod_terminal_llega = 'BO001';
Solución 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 números de viaje, códigos de terminal de salida, horas de
salida programadas, códigos de terminal de llegada, horas de llegada programadas y
días de todos los viajes o trayectos de viajes que salgan de algún terminal de la ciudad
de Santa Marta y lleguen a algún terminal de la ciudad de Buenaventura.
Solución 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);
Solución 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
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 Medellín, en el año 1999.

Solución 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 = 'Medellín' AND cod_terminal_llega = cod_terminal)
AND fecha between '01/01/00' and '31/12/99'
AND ta.num_viaje = vr.num_viaje;
Solución 2:
SELECT distinct cod_tarifa, monto
FROM viajes_realizados vr, tarifas ta, terminales_transporte
WHERE cod_terminal_sale = (SELECT cod_terminal
WHERE ciudad = 'Santa Marta')
AND cod_terminal_llega = (SELECT cod_terminal
WHERE ciudad = 'Medellín')
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 tráfico en un día (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 más 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);

Normalización de base de datos
Indice
1. Descomposición y Normalización
2. Dependencia
3. Normalización
4. Primera Forma Normal
5. Segunda Forma Normal
6. Tercera Forma Normal
7. Cuarta Forma Normal
1. Descomposición y Normalización
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 descomposición; el mismo es necesario
independientemente de la arquitectura de la base de datos - relacional, red o
jerárquica-. Sin embargo, para la base de datos relacional, la acción
correspondiente puede dividirse y expresarse en términos formales y se
denomina normalización a la misma.
La normalización convierte una relación en varias sub-relaciones, cada una de
las cuales obedece a reglas. Estas reglas se describen en términos 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 relación preexistente.
2. Dependencia
Significado :
Antes de entrar en el tópico 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 discusión a la BDR, si
bien la misma se aplica igualmente a las otras arquitecturas.
Los individuos tienen muchos atributos que pueden ser de interés a diferentes
personas en diferentes momentos. Nuestro problema actual es con una sola

aplicación o conjunto de aplicaciones: solemne son de interés algunos de los
atributos.
Los símbolos aplicables a la relación han sido introducidos previamente.
• R es una tupla general o vector que describe a un individuo;
• R es una relación, una matriz o un conjunto de
vectores que pertenecen la población de interés.
• U es el universo consistente en todas las posibles
descripciones individuales, obtenido mediante una
combinación 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 símbolo del nombre de un atributo
• a es el símbolo de un valor del atributo.
Dominio (A) es el dominio para el atributo cuyo nombre es A.
Campo de aplicación
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 relación funcional tal que los valores de una (o más de
una) de las variables determina y fija el valor de las otras variables en la
relación dependiente. Consideramos el caso en el que E y F dependen de D.
Esto se describe más brevemente en forma simbólica:
e = e (d) f = f(d)
Existen tres tipos distintos de dependencia.
o Total uno-uno-sinónimo
o Completa - subtupla
o Transitiva - múltiple.
La dependencia es una relación 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 están 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 práctica, 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 podría 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 función 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 sinónimos; 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 relación. Por
ejemplo, consideremos un archivo de personal donde cada uno de los
empleados es identificado de tres maneras.
• Su nombre
• Su número de seguridad social
• Su número de empleado
Los tres pueden representar una dependencia total. Tanto el número de
seguridad social como el número de empleado identifican al individuo en forma
única. El número de seguridad social atañe a la población completa de
trabajadores de los Estados Unidos. El número 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 número de empleado es al clave de la relación, el número de seguridad
social es sinónimo de aquel. Podemos en consecuencia decir que el número 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, también pueden, ser
claves candidatas. Sin embargo puede existir alguna duplicación, 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 relación que contiene información
sobre estado en dos formas :

• Una identificación de estado con dos letras, tal
como CA para California.
• Una designación con un número de dos dígitos tal
como 12 para
California.
Estas dos formas de información sobre estado ilustran una dependencia total.
Debe notarse sin embargo que muchas tuplas pueden contener la misma
identificación 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 más de dos variables, y
• Una variable dependiente depende de dos o más variables
independientes.
Consideramos una relación que abarca las variables P, Q y R. Supongamos
que P es la variable dependiente. Si el valor de P está determinado por una
función 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 simbólicamente. 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 interés para nosotros:
• El número de orden de compra (PON) designa la orden completa;
• El número de parte de pieza designa una de las
partes ordenadas por el pedido;
• La cantidad de piezas es el número 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 número de parte
y una cantidad. La cantidad es completamente dependiente del PON y del
número de parte. Resulta claro que el número de pedido no es suficiente para
determinar la cantidad todas las partes de un determinado pedido no tiene la
misma cantidad). Análogamente, un número 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 número 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 número de partes - condición improbable-.
Hemos examinado anteriormente un ejemplo académico y las variables
profesor, clase y sección. Tenemos en esta caso una dependencia completa de
profesor respecto de clase y sección. Si en nuestra facultad está establecido
existirá dependencia completa. Esto existiría que un profesor enseñe siempre a
todas las secciones de una clase particular - una condición no muy factible con
un curso de 20 secciones-.
Dependencia transitiva
La dependencia transitiva se aplica o tres o más variables. Consideremos el
caso de solo tres variables y llamémoslas 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, sería deseable encontrar una relación más 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))

Reducción
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 separación de estas relaciones
permite conservar espacios. Esto puede observarse mejor con respecto al
ejemplo que se describe más abajo.
Ejemplo
Consideramos un ejemplo que asocia cursos con departamento y con escuela.
En consecuencia, canto será dictado por el departamento de música en la
escuela de Artes y Ciencias; hidráulica será dictada por ingeniería civil en la
Escuela de Ingeniería; impuestos será dictado por el departamento contable en
la Escuela de Administración.
Llamemos
• S al curso
• T al departamento
• V a la escuela
Por lo tanto
S ----> T ----> V
la descomposición consiste en la asociación de un curso con un departamento
en una relación. Otras relación identifica a cada departamento con una escuela.
Esta segunda relación es necesariamente menor tanto en grado como en
cardinalidad y aquí reside el ahorro de espacio.
3. Normalizacion
¿Qué es normalización?
Normalización es un proceso que clasifica relaciones, objetos, formas de
relación y demás elementos en grupos, en base a las características que cada
uno posee. Si se identifican ciertas reglas, se aplica un categoría; si se definen
otras reglas, se aplicará otra categoría.
Estamos interesados en particular en la clasificación de las relaciones BDR. La
forma de efectuar esto es a través de los tipos de dependencias que podemos
determinar dentro de la relación. Cuando las reglas de clasificación sean más y
más restrictivas, diremos que la relación está en una forma normal más
elevada. La relación que está en la forma normal más 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 relación es la mayor
posible;
• La explicación de la base de datos es la más sencilla posible.
4. Primera forma normal
Para que una relación esté en primera forma normal (1 FN), debe ser
solamente una relación propia, una matríz m por n, donde:
• Ninguna celda de la matriz está vacía;
• El valor n cualquier columna está definido por el
dominio para dicho atributo.
• Cada tupla tiene una clave que la identifica en
forma unívoca, pero dicha clave no significa orden.
La aplicación determina la relación
Para que una relación sea normalizada en pasos adicionales, debe encontrarse
en la primera forma normal. Colocar los datos en la primera forma normal está
a cargo del diseñador de la aplicación. Estos datos se encuentran disponibles
de alguna manera inicialmente. Si la aplicación existe en forma manual, o ha
sido anteriormente computarizada pero no todavía como relación, el diseñador
reorganiza los datos de modo de conformar una matríz 1FN.
La segunda inicial más importante es la dimensión de la relación ¿cuántos
componentes existen en la tupla o cuántas columnas en la tabla? ¿De qué
manera se compara esto con el número de campos en el documento fuente?.
En la figura se puede observar un documento como muestra, una factura típica.
Parte de la información es fija y otra variable. La figura nos muestra un
formulario impreso dentro de l cual se ha agregado información. La impresión
puede dividirse en dos categorías.
• Información descriptiva para el usuario
• Nombres de atributos.
La información impresa es necesariamente fija. Podemos observar el nombre
de la compañía en la figura, así como otras particularidades (tales como el
número de teléfono 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 también los nombres de campos para

almacenar los datos en el sistema. Los que se escribe son los valores de
atributos.
La información convertida queda formada en tuplas. La próxima pregunta es
cuantas tuplas representarán a la formación en esta forma. Debe notarse que
el número de partes ordenadas varía 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
Pen-
Orde-despa-dien-
Nada 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 número fijo de componentes, necesitamos
una tupla en primera forma normal para cada parte de cada pedido. Sin
embargo, la información que se encuentra en la parte superior del formulario, y
que se llena a máquina, es la misma para todas las partes ordenadas más
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 relación en un número de relaciones más
pequeñas, 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á diseñado para mostrar dependencias. Para hacer
utilizable a este grafo, se agregan colores pueden expresarse en blanco y
negro mediante distintos tipos de líneas. Discutiremos estos tipos de líneas en
términos de la dependencia que cada uno representa. En las figuras que
siguen las formas gráficas aparecen a la izquierda y se utilizan para constituir
un grafo completo. A la derecha se puede observar una forma simbólica para
describir dependencias únicas.
Dependencia única
En la figura vemos un arco que conecta dos vértices 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 cuál será el valor de B.
Dependencia total
La dependencia total se define como una dependencia bilateral o simétrica. 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 línea doble o
una línea más gruesa. Esto representa una medida de seguridad para verificar
que el usuario no dibuje un arco e inadvertidamente omita la flecha.
Simbólicamente 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
líneas de trazos; a partir del centro de esta línea 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, existiría una dependencia transitiva.
Mostramos a la izquierda de la figura B que L. depende de J o de K. Más
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.
Simbólicamente 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 hipotético. En el mismo se
dibujan las relaciones de dependencia entre atributos para una aplicación de
remuneración. EMPNO y DEPTNO están subrayadas en la figura para expresar
que ambas son partes de una clave compuesta para la relación. Una línea
gruesa conecta EMPNO a EMPNOM para indicar que si nombre de empleado y
existe una dependencia total.
Varios atributos dependen directamente del número de empleados:
• TITL es el título de la tarea del empleado
• PAYLVL es un carácter que indica el nivel de
sueldo del empleado.
• HORAS representa el número de horas que el
empleado ha trabajado la presente semana.
• PAYRT está apuntado a PAYLVL indicando que el
régimen de pago es transitivamente dependiente del
nivel de pago.
La línea 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 número
de departamento. Obsérvense la dependencia total entre número 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 número de proyecto, PROJNO.
5. Segunda Forma Normal
Una relación 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 próximo paso de normalización y descomposición. Para ser
accesible a la normalización, y poder ser puesta en segunda forma normal, la
relación debe poseer las siguientes propiedades:
• Debe estar en primera forma normal
• Debe tener una clave compuesta.
La consecuencia inmediata de los requerimientos expresados más arriba es
que cualquier relación en primera forma normal que tiene una clave simple,
está automáticamente en segunda forma normal. Comencemos con un ejemplo
en forma de tabla de una relación 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 están subrayados en la
figura para mostrar que sirven como clave. La tupla de relación puede también
escribirse linealmente en forma simbólicamente:
R = (A,B,C,D,E,F,G,H,I,L,M,N,O,P,Q)
El próximo 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 matríz de relación, la cual puede hacernos
creer que existe una dependencia debido a que la muestra de la cual se ha
extraído dicha relación es pequeña. 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
línea de trazos que conecta a P y Q tienen dependencia completa de ambos.
Esta es la guía para la descomposición.
Descomposición

La figura contiene 3 sub-árboles, la base de nuestra descomposición.
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 raíz 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.
Proyección
El próximo paso es proyectar la relación 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
subrelación es la relación que deriva de una relación mayor. Las subrelaciones
ilustradas en la figura están correlacionadas por medio de los componentes de
sus claves. La clave compuesta P y Q de la relación original R. es también la
clave de la sub-relación PQ. P y Q tienen a P y Q respectivamente como
claves. La línea 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 relación original R debemos juntar estas tres subrelaciones
en algún orden, indicado simbólicamente como:
R = juntar P [juntar PQ, (Q)] (P) = juntar Q[juntar PQ P(P)] (Q).
Grafos
La nueva sub-relación que se ve en la figura se presenta en forma de grafo en
la figura siguiente. Existe una considerable analogía entres estas figuras y la
figura anterior. Lo importante es la diferencia. En PQ existe una línea 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 línea 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 línea de puntos conecta P en la relación PQ a P
de la relación P. Esto representa la correspondencia entre ambas veces P. Una
línea de puntos conecta de un modo similar Q en PQ a Q en Q para indicar una
correspondencia similar.

Efectos
El efecto de esta descomposición puede no resultar inmediatamente claro.
Debemos insistir en que ninguna relación correcta debe contener tuplas
duplicadas. La relación original R contiene muchas subtuplas duplicadas P' y
Q'. Las mismas han sido eliminadas durante la descomposición. Esto facilita en
forma extraordinaria la actualización y otras importantes operaciones que
afectan a estas relaciones, las cuales serán aclaradas en los ejemplos que
siguen.
Ejemplo de inventario
Vamos a utilizar ahora un ejemplo práctico para demostrar la normalización. En
la figura se observa una parte de la matríz de relación PW.
Pueden verse los nombres de los atributos simbólicos y sus significados, pero
no sus valores. Las columnas no aparecen en ningún orden en particular. Debe
observarse la clave compuesta que distingue cada tupla, que abarca el número
de pieza y el número de depósito PNO y WNO.
Arbol de Dependencia
El medio para descomponer la relación 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 más adelante, si es que las mismas existen.
Como podíamos esperar, aparecen tres sub-árboles. El sub-árbol de la
izquierda, con raíz PNO, contiene los atributos que se aplican solamente a la
pieza o parte. El sub-árbol de la derecha con raíz WNO describe cada depósito.
EDl sub-árbol del centro corresponde a las partes y al depósito, y describe la
cantidad de partes disponibles en el depósito, QOH, y el número de cajón o
estante, BIN (o algún otro parámetro de ubicación), donde dichas partes
pueden ser halladas.
El próximo 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 descomposición consiste en proyectar la relación 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 descomposición en la figura muestra las tres relaciones como matrices; la
línea de trazos indica como se vinculan las relaciones.
Efecto
Discutiremos ahora algunas de las ventajas obtenidas mediante la
descomposición. Si estas relaciones se utilizan para el control de inventario.
nuestra preocupación será cuantas piezas de cada tipo están disponibles en un
depósito en particular. Cuando se retiran piezas o se reciben nuevos envíos la
cantidad disponible, QOH será la variable de cambio. La actualización consiste
en poner al día sub-relación P/W la cual ahora contiene solamente malos
componentes en lugar de los nuevos P/W.
Existe una tupla P en la sub-relación de pieza o parte, P, para cada parte y una
tupla. W, en la sub relación W, para cada depósito y estos últimos
probablemente no serán muchos. Consideremos la facilidad de efectuar
cambios en un depósito en particular. Si un atributo de uno de los depósitos
varía entraremos en W para efectuar el cambio solamente en una tupla. En la
primera forma normal para PW teníamos 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 depósito almacenaba 100 partes, como
consecuencia debía variar 100 tuplas de PW. El procedimiento de actualización
se aplica también a las descripciones de partes. Si el precio de alguna parte o
pieza cambia, este cambio es independiente del depósito en el cual se
almacena dicha parte. Solamente se efectúa un cambio en P a diferencia de los
muchos que hubieran sido requeridos para PW.
6. Tercera forma normal
Una relación se encuentra en tercera forma normal (EFN) si no existen
transitividades entre sus atributos y si ya se encuentra en 2 FN.
Descripción
Una relación R a poner en tercera forma normal debe estar en la segunda
forma normal. Es muy común que R sea una sub-relación; la relación original
estaba en primera forma normal (para ponerla en segunda forma normal fue
descompuesta en varias sub-relaciones). Estas son ahora candidatas a una
descomposición adicional.
Recordamos que las propiedades de la segunda forma normal (2Fn) son:
• Tenemos una matríz 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
descomposición producirá a continuación sub-relaciones para las cuales no
existirán dependencias transitivas -la definición de la tercera forma normal
(EFN)-.
Una dependencia transitiva abarca como mínimo tres componentes. Si los
componentes fueran más, la dependencia múltiple puede derivarse en varias
dependencias atransitivas de tres componentes solamente dada una. Por lo
tanto dirigiremos nuestra atención 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 relación 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 relación en tercera forma normal aparece a
raíz de la granularidad del dominio involucrado. Se puede prever que:
num dominio (Q)> num dominio (A) > num dominio (B)
Determinación de al dependencia transitiva
Si el grafo utilizado para llevar la relación 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 situación 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 número PO, A el número 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 implícita de B respecto
de Q resulta obvia.
Si se presenta la dependencia inversa, debe gratificarse como se ve en la
figura.
Descomposición
Dada una sub-relación con una o más dependencias transitivas, la
descomposición consiste en partir la relación en una o más de una sub-
relación, 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-relación Q, con clave Q.:
Q ---> A; Q ---> C
Debe separarse la relación directa remanente, y colocarla en su propia sub-
relación 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 múltiples han sido investigadas y exhibidas.
Tenemos en consecuencia.
Q --> C
Q --> A --> B1
Q --> A --> B2
Q --> A --> B3
La descomposición 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 proyección:
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
línea de puntos entre A y A y entre C y C. Nos podemos mover directamente
entre las dos figuras sin la intervención de pasos simbólicos, utilizando
solamente manipulaciones gráficas.
Descomposición Gráfica
Hemos discutido el enfoque simbólico. Dado un grafo 2FN. Debemos
seleccionar en primer término los nodos apuntados por la raíz que no sean

hojas. Los mismos se convierten en raíces 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 raíces de A;; y C''.
Ejemplo de orden de compra
Examinaremos solamente una pequeña porción de la relación orden de compra
que ha sido convertida en un grafo de dependencia. Para esta porción de la
relación compra PP, tenemos:
• Las partes se compran utilizando el número de parte, PNO;
• Un vendedor, VNDR está asociado a cada parte;
• Cada vendedor tiene una clasificación de forma de pago, PAYCLS.
Por lo tanto PAYCLS representa si el vendedor debe cobrar dentro de los 10
días, 30 días, 60 días, etc. La acción para convertir la relación.
Tenemos aquí una relación 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 relación en la tercera forma normal, la misma se descompone
en dos sub-relaciones. Las dos sub-relaciones PV y VP, se forman por
proyección a partir de la relación original PP de modo tal que:
PV = proyectar PP (PNO, VNDR); PV = proyectar PP (VNDR, PAYCLS).
La relación PV relaciona partes con vendedores.
La identificación del vendedor, VNDR es la clave externa par PV. La misma se
utiliza para entrar en la relación 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 porción de un ejemplo de inventario, al cual
corresponde el grafo parcial. Tenemos en este caso:
• PNO es un número de parte

• PNM es el nombre de parte y tiene dependencia
total con el número de parte
• PREC es el costo de UNITS multiplicado por el número de partes
• PCL es la clase de parte, la cual da el tipo de parte
en términos de su peso y de su forma.
• WHN es el número de depósito donde está almacenada la parte.
• WHLOC Es la ubicación del deposito
• FUE es la categoría de seguro de incendio del depósivto.
Resulta claro a partir del grafo que el número de parte determina la
clasificación 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 línea de trazos gruesos, para descomponer la relación
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
número de cuenta que lo identifica. El depositante recibe una línea de crédito.
Puede extraer dinero hasta dicho valor. La parte no utilizada de crédito puede
ser retirada cuando lo desee. Vemos que la línea de crédito LNCR es
funcionalmente dependiente del número de cuenta CUET; el valor ya extraído
DEBIT es también dependiente del número de cuenta. El valor de crédito
disponible en este momento, DISP, es dependiente en forma completa de
ambos, LNCR y DEBIT.
Parecería que lo lógico es descomponer el grafo y volver a presentarlo. En
base a esto, P tiene como clave el número 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 funcionaría, pero hay una forma más simple de resolver el problema. El
valor de crédito disponible en la actualidad es simplemente la diferencia entre
la línea de crédito y el debido corriente. Todo lo que tenemos que hacer es
ejecutar una sustracción. La relación original no necesita contener DISP. dado
que éste se calcula simplemente durante el procesamiento. Por lo tanto
podemos sencillamente omitir Q.
Transitivas múltiples.

Establecemos de entrada la condición simple de que Z sea dependiente en
forma transitiva de Q. Si existe más 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 condición de transitividad,
Q ---> Z,
la condición completa podría ser, Q ---> X ---> Y ---> Z
Ninguna condición intermedia Q ---> X ---> Z --->; Q ---> Y ----> Z
sería 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
reducción óptima universal, excepto para los casos infrecuentes de
dependencia multivaluadas. Ha quedado claro en épocas recientes que es
posible una reducción 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 están siempre presentes. Esto se ilustra mejor con el
ejemplo presentado en la figura. La relación FAB describe tejidos. La variable
independiente (con respecto a las dependencias (multivaluadas) es el número
de tejido FABNO. Con el se encuentra asociados un modelo (o patrón) 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 también desde FABNO a COLOR.
La ineficiencia en el registro de información y se resulta clara al examinar las
dos nuevas relaciones. La primera de éstas, FABPAT lista el número de tejido
contra el modelo; en el segundo caso, FABCOL, lista el número 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 relación FAB a partir de las dos sub-relaciones que resultaron.
Descomposición Para poner una relación o sub-relación en la cuarta forma
normal debe poder aplicarse lo siguiente:
• Debe estar en la tercera forma normal.
• Deben existir una o mas multidependencias.
Después de construir el grafo de dependencia, el próximo 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 más fácil actualización.
Ejemplo de profesor y texto
Consideremos otro ejemplo. Los cursos dictados en una escuela corresponden
a un número de curso. Asociada a cada número de curso se encuentra la
descripción del mismo. Para cada curso existe una selección de textos y una
selección de profesores. Puede darse cualquier combinación de texto y
profesor.
El grafo de dependencia. El mismo nos muestra una dependencia total entre el
número de curso y la descripción del curso. Existe una multidependencia entre
texto y número de curso, y también entre profesor y número de curso.
Para descomponer la sub-relación en sus relaciones más pequeñas, se
efectúan tres proyecciones. Las sub-relaciones resultantes.

Bases de datos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Bases de datos

Similar a Bases de datos (20)

Último

Último (11)

Bases de datos