U 4,5,6

<1
Unidad 4

Principios
sobre
Bases de Datos
Relacionales

Autor: Jorge Snchez (www.jorgesanchez.net) ao 2004
e-mail: mailto:info@jorgesanchez.net

Este trabajo est protegido bajo una licencia de Creative Commons del
tipo Attribution-NonCommercial-ShareAlike.
Para ver una copia de esta licencia visite:
http://creativecommons.org/licenses/by-nc-sa/2.0/
o enve una carta a:
Creative Commons, 559 Nathan Abbott Way, Stanford, California
94305, USA.
<2

<3

Los contenidos de este documento estn protegidos bajo una licencia de Creative Commons
del tipo Attribution-Noncomercial-Share Alike. Con esta licencia:
Eres libre de:
Copiar, distribuir y mostrar este trabajo
Realizar modificaciones de este trabajo

Bajo las siguientes condiciones:

Attribution (Reconocimiento). Debe figurar siempre el autor
original de este trabajo

Noncommercial (No comercial). No puedes utilizar este trabajo
con propsitos comerciales.

Share Alike (Compartir igual). Si modificas, alteras o construyes
nuevos trabajos a partir de este, debes distribuir tu trabajo con una
licencia idntica a sta

Si estas limitaciones son incompatible con tu objetivo, puedes contactar con
el autor para solicitar el permiso correspondiente

No obstante tu derecho a un uso justo y legtimo de la obra, as como
derechos no se ven de manera alguna afectados por lo anteriormente
expuesto.

Esta nota no es la licencia completa de la obra, sino una traduccin del resumen en formato
comprensible del texto legal. La licencia original completa (jurdicamente vlida y pendiente
de su traduccin oficial al espaol) est disponible en
http://creativecommons.org/licenses/by-nc-sa/2.0/legalcode

<5>

n nd di ic ce e

ndice.............................................................................................. 5
modelos lgicos de datos............................................................... 7
esquema cannico .............................................................................. 7
tipos de base de datos ......................................................................... 7
modelo relacional ........................................................................ 11
introduccin ...................................................................................... 11
tablas ............................................................................................... 12
dominios........................................................................................... 13
claves ............................................................................................... 13
nulos ................................................................................................ 13
restricciones ...................................................................................... 14
las 12 reglas de Codd ....................................................................... 14
paso del esquema ER al modelo relacional................................. 17
transformaciones de entidades fuertes ................................................. 17
transformacin de relaciones .............................................................. 17
entidades dbiles............................................................................... 19
generalizaciones y especificaciones ..................................................... 20
normalizacin del esquema relacional ....................................... 23
problemas del esquema relacional...................................................... 23
formas normales................................................................................ 23
apndice: trminos tcnicos......................................................... 31

<7

m mo od de el lo os s l l g gi ic co os s d de e d da at to os s

esquema cannico

Mundo
real

Esquema
Conceptual

Esquema
cannico

Esquema
interno
BD
Fsical

Modelo
Lgico Tiene en
cuenta el tipo de
DBMS a utilizar

Ilustracin 1, Posicin de esquema cannico dentro de los esquema de creacin de
una base de datos

El esquema cannico o lgico global, es un esquema que presenta de forma conceptual la
estructura de una base de datos. Es un esquema que depende del tipo de DBMS que
vayamos a utilizar.
Se crea a partir del modelo conceptual (vase el documento Diseo Conceptual de
Bases de Datos en www.jorgesanchez.net/bd). Y servira para cualquier base de datos
comercial del tipo elegido en el esquema (hay esquemas relacionales, en red,
jerrquicos,...)

tipos de base de datos

jerrquicas

En ellas se organiza la informacin se organiza con un jerarqua en la que la relacin entre
las entidades de este modelo siempre es del tipo padre / hijo. De esta forma hay una
serie de nodos que contendrn atributos y que se relacionarn con nodos hijos de forma
que puede haber ms de un hijo para el mismo padre (pero un hijo slo tiene un padre).
Las entidades de este modelo se llaman segmentos y los atributos campos. La forma
visual de este modelo es de rbol invertido, en la parte superior estn los padres y en la
inferior los hijos.
<8

Personal

Tareas

Diseo conceptual de bases de datos
modelos lgicos de datos

Departamento

Documentos

Ilustracin 2, Ejemplo de esquema jerrquico

en red

Se trata de un modelo que se utiliz durante mucho tiempo. Organiza la informacin en
registros y enlaces. Los registros representan las entidades del modelo entidad /
relacin. En los registros se almacenan los datos utilizando atributos. Los enlaces
permiten relacionar los registros de la base de datos.
El modelo en red ms aceptado es el llamado codasyl, que durante mucho tiempo se
ha convertido en un estndar.
Las bases de datos en red son parecidas a las jerrquicas slo que en ellas puede haber
ms de un padre. En este modelo se pueden representar perfectamente relaciones varios a
varios. Pero su dificultad de manejo y complejidad hace que se estn abandonando
completamente.

relacionales

Los datos se muestran en forma de tablas y relaciones. Este es el modelo que se comenta
en el presente documento. De hecho es el claramente ms popular.

orientadas a objetos

Desde la aparicin de la programacin orientada a objetos (POO u OOP) se empez a
pensar en bases de datos adaptadas a estos lenguajes. En estos lenguajes los datos y los
procedimientos se almacenan juntos. Esta es la idea de las bases de datos orientadas a
objetos.
A travs de esta idea se intenta que estas bases de datos consiguen arreglar las
limitaciones de las relacionales. Por ejemplo el problema de la herencia, tipos definidos
por el usuario, disparadores almacenables en la base de datos, soporte multimedia...
Se supone que son las bases de datos de tercera generacin (la primera fue las bases de
datos en red y la segunda las relacionales), lo que significa que el futuro parece estar a
favor de estas bases de datos. Pero siguen sin reemplazar a las relacionales (aunque cada
vez hay ms).
Su modelo conceptual se suele disear en UML y el lgico en ODMG 3.0

objeto relacionales

Tratan de ser un hbrido entre el modelo relacional y el orientado a objetos. El problema
de las bases de datos orientadas a objetos es que requieren reinvertir de nuevo para
convertir las bases de datos. En las bases de datos objeto relacionales se intenta conseguir
una compatibilidad relacional dando la posibilidad de integrar mejoras de la orientacin a
objetos.
<9>
Copyright-Copyleft: Jorge Snchez 2004

Estas bases de datos se basan en el estndar SQL 99 que dict las normas para estas
bases de datos. En ese estndar se aade a las bases relacionales la posibilidad de
almacenar procedimientos de usuario, triggers, tipos definidos por el usuario, consultas
recursivas, bases de datos OLAP, tipos LOB,...
Las ltimas versiones de la mayora de las grandes bases de datos relacionales (Oracle,
SQL Server, Informix, ...) son objeto relacionales.

<11

m mo od de el lo o r re el la ac ci io on na al l

introduccin

Edgar Frank Codd a finales defini las bases del modelo relacional a finales de los 60.
Trabajaba para IBM empresa que tard un poco en implementar sus bases. Pocos aos
despus el modelo se empez a implementar cada vez ms, hasta ser el modelo de bases de
datos ms popular.
En las bases de Codd se definan los objetivos de este modelo:

Independencia fsica. La forma de almacenar los datos, no debe influir en su
manipulacin lgica

Independencia lgica. Las aplicaciones que utilizan la base de datos no deben ser
modificadas por que se modifiquen elementos de la base de datos.

Flexibilidad. La base de datos ofrece fcilmente distintas vistas en funcin de los
usuarios y aplicaciones.

Uniformidad. Las estructuras lgicas siempre tienen una nica forma conceptual
(las tablas)

Sencillez.

En 1978, IBM desarrolla el lenguaje QBE. Que aproximaba la idea relacional a sus ficheros
VSAM. En 1979 Oracle se convierte en el primer producto comercial DBMS relacional
(RDBMS). En 1980 aparece Ingres que utilizaba el lenguaje Quel que implementaba el
clculo relacional.

evolucin del modelo relacional

Ao Hecho
1970 Codd publica las bases del modelo relacional
1971-72 Primeros desarrollos tericos
1973-78 Primeros prototipos
1978 Aparece el lenguaje QBE
1979 Aparece Oracle
1980 Aparece Ingres
1981 Aparece SQL
1982 Aparece DB2
1986 ANSI normaliza el SQL (SQL/ANSI)
1987 SQL de ISO
1990 Versin dos del modelo relacional (RM/V2)
1992 SQL 92
1998 SQL 3
<12
atributo 1 atributo 2 atributo 3 .... atributo n
valor 1,1 valor 1,2 valor 1,3 .... valor 1,n
valor 2,1 valor 2,2 valor 2,3 .... valor 2,n
..... ..... ...... .... .....
valor m,1 valor m,2 valor m,3 .... valor m,n

modelo relacional
tablas

Las bases de datos relacionales se basan en el uso de tablas (tambin se las llama
relaciones). Las tablas se representan grficamente como una estructura rectangular
formada por filas y columnas. Cada columna almacena informacin sobre una propiedad
determinada de la tabla (se le llama tambin atributo), nombre, dni, apellidos, edad,....
Cada fila posee una ocurrencia o ejemplar de la instancia o relacin representada por la
tabla (a las filas se las llama tambin tuplas).

NOMBRE

tupla 1
tupla 2
....
tupla m

Ilustracin 3, Representacin de una tabla en el modelo relacional

terminologa relacional

Tupla. Cada fila de la tabla (cada ejemplar que la tabla representa)

Atributo. Cada columna de la tabla

Grado. Nmero de atributos de la tabla

Cardinalidad. Nmero de tuplas de una tabla

Dominio. Conjunto vlido de valores representables por un atributo.

tipos de tablas

Persistentes. Slo pueden ser borradas por los usuarios:

Base. Independientes, se crean indicando su estructura y sus ejemplares.

Vistas. Son tablas que slo almacenan una definicin de consulta, resultado de
la cual se produce una tabla cuyos datos proceden de las bases o de otras vistas
e instantneas. Si los datos de las tablas base cambian, los de la vista que utiliza
esos datos tambin cambia.

Instantneas. Son vistas (creadas de la misma forma) que s que almacenan
los datos que muestra, adems de la consulta que dio lugar a esa vista. Slo
modifican su resultado (actualizan los datos) siendo refrescadas por el sistema
cada cierto tiempo.

Temporales. Son tablas que se eliminan automticamente por el sistema. Pueden
ser de cualquiera de los tipos anterior
<13

dominios

Los dominios suponen una gran mejora en este modelo ya que permiten especificar los
posibles valores vlidos para un atributo. Cada dominio incorpora su nombre y una
definicin del mismo. Ejemplos de dominio:

Direccin: 50 caracteres

Nacionalidad: Espaol, Francs, Italiano,...

Los dominios pueden ser tambin compuestos a partir de otros (ao, mes y da = fecha)

claves

clave candidata

Conjunto de atributos de una tabla que identifican unvocamente cada tupla de la tabla.

clave primaria

Clave candidata que se escoge como identificador de las tuplas.

clave alternativa

Cualquier clave candidata que no sea primaria

clave externa o secundaria

Atributo de una tabla relacionado con una clave de otra tabla.

nulos

Los valores nulos indican contenidos de atributos que no tienen ningn valor. En claves
secundarias indican que el registro actual no est relacionado con ninguno. En otros
atributos indica que no se puede rellenar ese valor por la razn que sea.
Las bases de datos relacionales admiten utilizar ese valor en todo tipo de operaciones.
Eso significa definir un tercer valor en la lgica. Adems de el valor verdadero o falso,
existe el valor para los nulos.
La razn de este tercer valor ambiguo es que comparar dos atributos con valor nulo, no
puede resultar ni verdadero, ni falso. De hecho necesitamos definir la lgica con este valor:

verdadero Y (AND) nulo da como resultado, nulo

falso Y (AND) nulo da como resultado, falso

verdadero O (OR) nulo da como resultado, verdadero

falso O nulo da como resultado nulo

la negacin de nulo, da como resultado nulo
<14
modelo relacional
restricciones

Se trata de unas condiciones de obligado cumplimiento por los datos de la base de datos.
Las hay de varios tipos.

inherentes

Son aquellas que no son determinadas por los usuarios, sino que son definidas por el
hecho de que la base de datos sea relacional. Por ejemplo:

No puede haber dos tuplas iguales

El orden de las tuplas no importa

El orden de los atributos no importa

Cada atributo slo puede tomar un valor en el dominio en el que est
inscrito

semnticas

El modelo relacional permite a los usuario incorporar restricciones personales a los datos.
Las principales son:

Clave primaria. Hace que los atributos marcados como clave primaria no puedan
repetir valores.

Unicidad. Impide que los valores de los atributos marcados de esa forma, puedan
repetirse.

Obligatoriedad. Prohbe que el atributo marcado de esta forma no tenga ningn
valor

Integridad referencial. Prohbe colocar valores en una clave externa que no estn
reflejados en la tabla donde ese atributo es clave primaria.

Regla de validacin. Condicin que debe de cumplir un dato concreto para que
sea actualizado.

las 12 reglas de Codd

Preocupado por los productos que decan ser sistemas gestores de bases de datos
relacionales (RDBMS) sin serlo, Codd publica las 12 reglas que debe cumplir todo DBMS
para ser considerado relacional. Estas reglas en la prctica las cumplen pocos sistemas
relacionales. Las reglas son:

1> Informacin. Toda la informacin de la base de datos debe estar representada
explcitamente en el esquema lgico. Es decir, todos los datos estn en las
tablas.

2> Acceso garantizado. Todo dato es accesible sabiendo el valor de su clave y el
nombre de la columna o atributo que contiene el dato.

3> Tratamiento sistemtico de los valores nulos. El DBMS debe permitir el
tratamiento adecuado de estos valores
<15>

4> Catlogo en lnea basado en el modelo relacional. Los metadatos deben
de ser accesibles usando un esquema relacional.

5> Sublenguaje de datos completo. Al menos debe de existir un lenguaje que
permita el manejo completo de la base de datos. Este lenguaje, por lo tanto,
debe permitir realizar cualquier operacin.

6> Actualizacin de vistas. El DBMS debe encargarse de que las vistas
muestren la ltima informacin

7> Inserciones, modificaciones y eliminaciones de dato nivel. Cualquier
operacin de modificacin debe actuar sobre conjuntos de filas, nunca deben
actuar registro a registro.

8> Independencia fsica. Los datos deben de ser accesibles desde la lgica de la
base de datos an cuando se modifique el almacenamiento.

9> Independencia lgica. Los programas no deben verse afectados por cambios
en las tablas

10> Independencia de integridad. Las reglas de integridad deben almacenarse
en la base de datos (en el diccionario de datos), no en los programas de
aplicacin.

11> Independencia de la distribucin. El sublenguaje de datos debe permitir
que sus instrucciones funciones igualmente en una base de datos distribuida
que en una que no lo es.

12> No subversin. Si el DBMS posee un lenguaje que permite el recorrido
registro a registro, ste no puede utilizarse para incumplir las reglas
relacionales.

<17

p pa as so o d de el l e es sq qu ue em ma a E ER R a al l m mo od de el lo o r re el la ac ci io on na al l

transformaciones de entidades fuertes

En principio las entidades fuertes del modelo Entidad Relacin son transformados al
modelo relacional siguiendo estas instrucciones:

Entidades. Las entidades pasan a ser tablas

Atributos. Los atributos pasan a ser columnas.

Identificadores principales. Pasan a ser claves primarias

Identificadores candidatos. Pasan a ser claves candidatas.

Esto hace que la transformacin sea de esta forma:

Identificador Atributo1

Nombre Nombre(Identificador, Atributo 1, Atributo 2, Atributo 3)

Atributo2
Atributo2

Ilustracin 4,Transformacin de una entidad fuerte al esquema relacional

transformacin de relaciones

La idea inicial es transformar a cada relacin en una tabla en el modelo relacional. Pero
hay que distinguir segn el tipo de relacin.

relaciones varios a varios

En las relaciones varios a varios, la relacin se transforma en una tabla cuyos atributos
son: los atributos de la relacin y las claves de las entidades relacionadas (que pasarn a
ser claves externas). La clave de la tabla la forman todas las claves externas:

Atributo1

Nombre

Identificador1
Atributo1

Identificador2

Nombre(Identificador1,Identificador2,Atributo1,Atributo2)

Ilustracin 5, Transformacin de una relacin varios a varios
<18
paso del esquema ER modelo relacional
relaciones de orden n

Las relaciones ternarias, cuaternarias y n-arias que unen ms de dos relaciones se
transforman en una tabla que contiene los atributos de la relacin ms los identificadores
de las entidades relacionadas. La clave la forman todas las claves externas:

Identificador1

Atributo1

Nombre
Identificador3

Identificador2

Atributo1

Identificador4

Nombre(Identificador1,Identificador2,,Identificador3,Identificador4,Atributo1,Atributo2)

Ilustracin 6, Transformacin en el modelo relacional de una entidad n-aria

relaciones uno a varios y uno a uno

Las relaciones binarios de tipo uno a varios no requieren ser transformadas en una tabla
en el modelo relacional. En su lugar la tabla del lado varios (tabla relacionada) incluye
como clave externa
1
el identificador de la entidad del lado uno (tabla principal):

Atributo2

Atributo1
Atributo3

Entidad1
Nombre
Entidad2

Iden tificador1
Identificador2

Entidad2(Identificador2,Atributo3)
Entidad1(Identificador1,Atributo1,Identificador2,Atributo2)

Ilustracin 7, Transformacin de una relacin uno a varios

As en el dibujo, el identificador2 en la tabla Entidad1 pasa a ser una clave externa. En el
caso de que el nmero mnimo de la relacin sea de cero (puede haber ejemplares de la
entidad uno sin relacionar), se deber permitir valores nulos en la clave externa

1
Clave externa, clave ajena, clave fornea, clave secundaria y foreign key son sinnimos
<19

identificador2. En otro caso no se podrn permitir (ya que siempre habr un valor
relacionado).
En el caso de las relaciones uno a uno, ocurre lo mismo: la relacin no se convierte en
tabla, sino que se coloca en una de las tablas (en principio dara igual cul) el identificador
de la entidad relacionada como clave externa.
En el caso de que una entidad participe opcionalmente en la relacin, entonces es el
identificador de sta el que se colocar como clave externa en la tabla que representa a la
otra entidad.

relaciones recursivas

Las relaciones recursivas se tratan de la misma forma que las otras, slo que un mismo
atributo puede figurar dos veces en una tabla como resultado de la transformacin:

Identificador

Rol2
Identificador

Rol2

Entidad Entidad

Atributo 1

Rol1
Relac.

Atributo 1

Rol1
Relac.

Entidad(Identificador,Atributo1,Identificador Rol 1) Entidad(Identificador,Atributo1)

Relac(Identificador Rol 1, Identificador Rol 2,Atributo1)

Ilustracin 8, Transformacin de relaciones recursivas en el modelo relacional

entidades dbiles

Toda entidad dbil incorpora una relacin implcita con una entidad fuerte. Esta relacin
no necesita incorporarse como tabla en el modelo relacional. S se necesita incorporar la
clave de la entidad fuerte como clave externa en la entidad dbil. Es ms, normalmente esa
clave externa forma parte de la clave principal de la tabla que representa a la entidad dbil.
El proceso es:

Atributo1 Atributo2

Entidad Fuerte Entidad Dbil

Id Fuerte Id Dbil

Entidad Fuerte(Id Fuerte, Atributo 1)
Entidad1(Id Dbil, Id Fuerte, Atributo2)

Ilustracin 9, transformacin de una entidad dbil en el modelo relacional
<20
paso del esquema ER modelo relacional
En ocasiones el identificador de la entidad dbil es suficiente para identificar los
ejemplares de dicha entidad, entonces ese identificador quedara como clave principal,
pero el identificador de la entidad fuerte seguira figurando como clave externa en la
entidad dbil.

generalizaciones y especificaciones

Las generalizaciones y/o especificaciones se convierten al modelo relacional de esta forma:

1> Las subentidades pasan a ser tablas.

2> Si la clave de la superentidad es distinta de las subentidades, entonces se coloca
el identificador de la superentidad en cada subentidad como clave externa:

Id1
Atributo1

Atributo2
Superentidad

Atributo3

Subentidad1 Subentidad2

Id2 Id3

Superentidad(Id1, Atributo 1)
Subentidad2(Id3, Atributo 3, Id1)
Subentidad1(Id2, Atributo 2, Id1)

Ilustracin 10, Proceso de transformacin de relaciones ISA con clave propia

3> Si la clave es la misma, entonces todas las entidades tendrn la misma columna
como identificador:

Id
Atributo1

Atributo2
Superentidad

Atributo3


Id Id

Superentidad(Id, Atributo 1)
Subentidad2(Id, Atributo 3)
Subentidad1(Id, Atributo 2)

Ilustracin 11, Proceso de transformacin de relaciones ISA en el modelo relacional
si tienen la misma clave
<21>

4> La superentidad debe generar una tabla slo en el caso de que haya posibilidad
de que exista un ejemplar de dicha entidad que no sea ejemplar de las
subentidades. De otro modo basta con generar las tablas de las subentidades e
incluir los atributos de la entidad superior:

Id
Atributo1

Atributo2
Superentidad

Atributo3


Id Id

Subentidad2(Id, Atributo 3, Atributo1)
Subentidad1(Id, Atributo 2, Atributo1)

Ilustracin 12, Paso de relaciones ISA al modelo relacional cuando toda
superentidad figura como subentidad

<23

n no or rm ma al li iz za ac ci i n n d de el l e es sq qu ue em ma a r re el la ac ci io on na al l

problemas del esquema relacional

Una vez obtenido el esquema relacional resultantes del modelo entidad relacin que
representaba la base de datos, normalmente tendremos una buena base de datos. Pero
otras veces, debido a fallos en el diseo o a problemas indetectables en esta fase del
diseo, tendremos un esquema que puede producir una base de datos que incorpore estos
problemas:

Redundancia. Se llama as a los datos que se repiten continua e innecesariamente
por las tablas de las bases de datos.

Ambigedades. Datos que no clarifican suficientemente el registro al que
representan.

Prdida de restricciones de integridad.

Anomalas en operaciones de modificacin de datos. El hecho de que al
insertar un solo elemento haya que repetir tuplas en una tabla para variar unos
pocos datos. O que eliminar un elemento suponga eliminar varias tuplas.

El principio fundamental reside en que las tablas deben referirse a objetos o situaciones
muy concretas. Lo que ocurre es que conceptualmente es difcil obtener ese problema.
La solucin suele ser dividir la tabla con problemas en otras tablas ms adecuadas.

formas normales

Las formas normales se corresponde a una teora de normalizacin iniciada por el propio
Codd y continuada por otros autores (entre los que destacan Boyce y Fagin). Codd defini
en 1970 la primera forma normal, desde ese momento aparecieron la segunda, tercera, la
Boyce-Codd, la cuarta y la quinta forma normal.
Una tabla puede encontrarse en primera forma normal y no en segunda forma normal,
pero no al contrario. Es decir los nmeros altos de formas normales son ms restrictivos
(la quinta forma normal cumple todas las anteriores).
La teora de formas normales es una teora absolutamente matemtica, pero en el
presente manual se describen de forma intuitiva.

primera forma normal (1FN)

Una tabla se encuentra en primera forma normal si impide que un atributo de una tupla
pueda tomar ms de un valor. La tabla:

TRABAJADOR
DNI Nombre Departamento
12121212A Andrs Mantenimiento
12345345G Andrea Direccin
Gestin
<24
apndice: trminos tcnicos
Visualmente es un tabla, pero no una tabla relacional (lo que en terminologa de bases de
datos relacionales se llama relacin). No cumple la primera forma normal. Lo cumplira
si:

TRABAJADOR
DNI Nombre Departamento
12121212A Andrs Mantenimiento
12345345G Andrea Direccin
12345345G Andrea Gestin

Esa tabla s esta en primera forma normal.

dependencias funcionales

Se dice que un conjunto de atributos (Y) depende funcionalmente de otro conjunto de
atributos (X) si para cada valor de X hay un nico valor posible para Y. Simblicamente se
denota por XY.
Por ejemplo el nombre de una persona depende funcionalmente del DNI, para un DNI
concreto slo hay un nombre posible. En la tabla ejemplo anterior, el departamento no
tiene dependencia funcional, ya que para un mismo DNO puede haber ms de un
departamento posible.
Al conjunto X del que depende funcionalmente el conjunto Y se le llama
determinante. Al conjunto Y se le llama implicado.

dependencia funcional completa

Un conjunto de atributos (Y) tiene una dependencia funcional completa sobre otro
conjunto de atributos (X) si Y tiene dependencia funcional de X y adems no se puede
obtener de X un conjunto de atributos ms pequeo que consiga una dependencia
funcional de Y.
Por ejemplo en una tabla de clientes, el conjunto de atributos formado por el nombre
y el dni producen una dependencia funcional sobre el atributo apellidos. Pero no es
plena ya que el dni slo tambin produce una dependencia funcional sobre apellidos. El
dni s produce una dependencia funcional completa sobre el campo apellidos.
Una dependencia funcional completa se denota como XY

dependencia funcional elemental

Se produce cuando X e Y forman una dependencia funcional completa y adems Y es un
nico atributo.

dependencia funcional transitiva

Es ms compleja de explicar, pero tiene tambin utilidad. Se produce cuando tenemos tres
conjuntos de atributos X, Y y Z. Y depende funcionalmente de X (XY), Z depende
funcionalmente de Y (YZ). Adems X no depende funcionalmente de Y. Entonces ocurre
que X produce una dependencia funcional transitiva sobre Z. Esto se denota como:
(X Z)
Por ejemplo si X es el atributo Nmero de Clase de un instituto, e Y es el atributo
Cdigo Tutor. Entonces XY (el tutor depende funcionalmente del nmero de clase). Si Z
representa el Cdigo del departamento, entonces YZ (el cdigo del departamento
depende funcionalmente del cdigo tutor, cada tutor slo puede estar en un
<25

departamento). Como no ocurre que YX (el cdigo de la clase no depende
funcionalmente del cdigo tutor, un cdigo tutor se puede corresponder con varios
cdigos de clase). Entonces X Z (el cdigo del departamento depende transitivamente
del cdigo de la clase).

segunda forma normal (2FN)

Ocurre si una tabla est en primera forma normal y adems cada atributo que no sea clave,
depende de forma funcional completa respecto de cualquiera de las claves. Toda la clave
principal debe hacer dependientes al resto de atributos, si hay atributos que depende slo
de parte de la clave, entonces esa parte de la clave y esos atributos formarn otra tabla.
Ejemplo:

ALUMNOS
DNI Cod Curso Nombre Apellido1 Nota
12121219A 34 Pedro Valiente 9
12121219A 25 Pedro Valiente 8
3457775G 34 Ana Fernndez 6
5674378J 25 Sara Crespo 7
5674378J 34 Sara Crespo 6

Suponiendo que el DNI y el nmero de curso formen una clave principal para esta tabla,
slo la nota tiene dependencia funcional completa. El nombre y los apellidos dependen de
forma completa del DNI. La tabla no es 2FN, para arreglarlo:

ALUMNOS
DNI Nombre Apellido1
12121219A Pedro Valiente
3457775G Ana Fernndez
5674378J Sara Crespo

ASISTENCIA
DNI Cod Curso Nota
12121219A 34 9
12121219A 25 8
3457775G 34 6
5674378J 25 7
5674378J 34 6

tercera forma normal (3FN)

Ocurre cuando una tabla est en 2FN y adems ningn atributo que no sea clave depende
transitivamente de las claves de la tabla. Es decir no ocurre cuando algn atributo
depende funcionalmente de atributos que no son clave.
<26
Ejemplo:

ALUMNOS
DNI Nombre Apellido1 Cod Provincia Provincia
12121349A Salvador Velasco 34 Palencia
12121219A Pedro Valiente 34 Palencia
3457775G Ana Fernndez 47 Valladolid
5674378J Sara Crespo 47 Valladolid
3456858S Marina Serrat 08 Barcelona

La Provincia depende funcionalmente del cdigo de provincia, lo que hace que no est en
3FN. El arreglo sera:

ALUMNOS
DNI Nombre Apellido1 Cod Provincia
12121349A Salvador Velasco 34
12121219A Pedro Valiente 34
3457775G Ana Fernndez 47
5674378J Sara Crespo 47
3456858S Marina Serrat 08

PROVINCIA
Cod Provincia Provincia
34 Palencia
47 Valladolid
08 Barcelona

forma normal de Boyce-Codd (FNBC o BCFN)

Ocurre si una tabla est en tercera forma normal y adems todo determinante es una clave
candidata. Ejemplo:

TUTORAS
DNI Asignatura Tutor
12121219A Lenguaje Eva
12121219A Matemticas Andrs
3457775G Lenguaje Eva
5674378J Matemticas Guillermo
5674378J Lenguaje Julia
5634823H Matemticas Guillermo

Esa tabla est en tercera forma normal (no hay dependencias transitivas), pero no en
forma de Boyce - Codd, ya que (DNI, Asignatura) Tutor y TutorAsignatura. En este
caso la redundancia ocurre por mala seleccin de clave. La redundancia de la asignatura es
completamente evitable. La solucin sera:
<27

TUTORAS
DNI Tutor
12121219A Eva
12121219A Andrs
3457775G Eva
5674378J Guillermo
5674378J Julia
5634823H Guillermo

ASIGNATURASTUTOR
Asignatura Tutor
Lenguaje Eva
Matemticas Andrs
Matemticas Guillermo
Lenguaje Julia

En las formas de Boyce-Codd hay que tener cuidado al descomponer ya que se podra
perder informacin por una mala descomposicin

dependencia multivaluada

Para el resto de formas normales (las diseadas por Fagin, mucho ms complejas), es
importante definir este tipo de dependencia, que es distinta de las funcionales. Si las
funcionales eran la base de la segunda y tercera forma normal (y de la de Boyce-Codd),
stas son la base de la cuarta forma normal.
Una dependencia multivaluada de una tabla con atributos X, Y, Z de X sobre Z (es
decir X->>Z) ocurre cuando los posibles valores de Y sobre cualquier par de valores X y Z
dependen slo del valor de X y son independientes de Z.
Ejemplo:

N Curso Profesor Material
17 Eva 1
17 Eva 2
17 Julia 1
17 Julia 2
25 Eva 1
25 Eva 2
25 Eva 3

La tabla cursos, profesores y materiales del curso. La tabla est en FNBC ya que no hay
dependencias transitivas y todos los atributos son clave sin dependencia funcional hacia
ellos. Sin embargo hay redundancia. Los materiales se van a repetir para cualquier
profesor dando cualquier curso, ya que los profesores van a utilizar todos los materiales
del curso (de no ser as no habra ninguna redundancia).
<28
Los materiales del curso dependen del curso y no del profesor en una dependencia
multivaluada. Para el par N de curso y profeso podemos saber los materiales, pero por el
curso y no por el profesor.

cuarta forma normal (4FN)

Ocurre esta forma normal cuando una tabla est en forma normal de Boyce Codd y toda
dependencia multivaluada es una dependencia funcional. Para la tabla anterior la solucin
seran dos tablas:

N Curso Material
17 1
17 2
25 1
25 2
25 3

N Curso Profesor
17 Eva
17 Julia
25 Eva

Un teorema de Fagin indica cuando hay tres pares de conjuntos de atributos X, Y y Z si
ocurre X->>Y|Z (Y y Z tienen dependencia multivaluada sobre X), entonces las tablas X,Y
y X,Z reproducen sin perder informacin lo que posea la tabla original. Este teorema
marca la forma de dividir las tablas hacia una 4FN

quinta forma normal (5FN)

Es la ms compleja y polmica de todas. Polmica pues no est claro en muchas ocasiones
que sea una solucin mejor que el no llegar a este nivel de normalizacin. Fue definida
tambin por Fagin.
Es raro encontrarse este tipo de problemas cuando la normalizacin llega a 4FN. Se
deben a restricciones muy concretas. Ejemplo:

Proveedor Material Proyecto
1 1 2
1 2 1
2 1 1
1 1 1

Indican cdigos de material suministrado por un proveedor y utilizado en un determinado
proyecto.
Si ocurre una restriccin especial como por ejemplo: Cuando un proveedor nos ha
suministrado alguna vez un determinado material, si ese material aparece en otro
proyecto, haremos que el proveedor nos suministre tambin ese material para ese
proyecto.
<29>

Eso ocurre en los datos como el proveedor nmero 1 nos suministr el material
nmero 1 para el proyecto 2 y en el proyecto 1 utilizamos el material 1, aparecer la tupla
proveedor 1, material 1 y proyecto 1.
La dependencia que produce esta restriccin es lejana y se la llama de reunin. Para
esa restriccin esta divisin en tablas sera vlida:

Proveedor Material
1 1
1 2
2 1

Material Proyecto
1 2
2 1
1 1

Esa descomposicin no pierde valores en este caso, sabiendo que si el proveedor nos
suministra un material podremos relacionarle con todos los proyectos que utilizan ese
material.
Resumiendo, una tabla no est en quinta forma normal si hay una descomposicin de
esa tabla que muestre la misma informacin que la original.

<31

a ap p n nd di ic ce e: : t t r rm mi in no os s t t c cn ni ic co os s

1FN Abreviatura de Primera Forma Normal. Normalizacin estndar de las tablas
relacionales.

2FN Abreviatura de Segunda Forma Normal. Normalizacin estndar de las tablas
relacionales.

3FN Abreviatura de Tercera Forma Normal. Normalizacin estndar de las tablas
relacionales.

4FN Abreviatura de Cuarta Forma Normal. Normalizacin estndar de las tablas
relacionales.

5FN Abreviatura de Quinta Forma Normal. Normalizacin estndar de las tablas
relacionales.

ANSI American National Standards Institute, Instituto de estndares de Estados
Unidos. Uno de los organismos de estandarizacin ms importantes.

ATU rea de trabajo de usuario. Parte de la memoria que utilizan los procesos de
usuario para almacenar los datos recibidos de una base de datos.

BCNF Vase FNBC

BD Abreviatura de Base de Datos.

Buffer Zona de la memoria que se utiliza para almacenar temporalmente algunos
datos.

Codasyl Conference on Data System Languages, Data Base Task Group. Nombre que
se da al modelo de bases de datos en red que result de una conferencia en el
ao 1971 y que provoc su aceptacin como estndar.

DB Abreviatura de Data Base, base de datos

DBA Data Base Administrator, nombre que recibe el administrador de la base de
datos

DBMS Data Base Management System, Sistema gestor de bases de datos. El software
encargado de administrar y producir bases de datos.

DCL Data Control Language, lenguaje de control de datos. Lenguaje que
proporcionan las DBMS para controlar los usuarios de la base de datos.

DDL Data Definition Language, lenguaje de definicin de datos. Lenguaje que
proporcionan las DBMS para definir la base de datos.

DML Data Modification Language, lenguaje de modificacin de datos. Lenguaje
que proporcionan las DBMS para realizar operaciones de bsqueda y
modificacin de datos.

ERE Modelo entidad relacin extendido

FNBC Abreviatura de Forma Normal de Boyce Codd. Normalizacin estndar de las
tablas relacionales.

LOB Large Object Binary, objeto binario largo. Tipo de datos de muchas bases de datos que admiten almacenar grandes
cantidades de informacin en formato binario.

ODMG Object Data Management Group, grupo de administracin de objetos de datos. Estndar utilizado para definir
modelos lgicos de bases de datos de objetos.

OLAP On Line Analytical Process, Proceso analtico en lnea. Nombre que reciben las
OOP Programacin orientada a objetos

OS Vase SO

POO Programacin orientada a objetos

QBE Query by Example, consultas mediante ejemplos. Lenguaje relacional utilizado en algunas de las primeras
bases de datos relacionales.

RM/V2 Relational Model Version 2, Modelo relacional, versin 2. Modelo desarrollado por Codd, considerado
como la segunda versin del modelo relacional.

RDBMS Relational Data Base Management System, Sistema gestor de bases de datos relacionales. El software encargado de
administrar y producir bases de datos relacionales

SGBD Vase DBMS

SGBDR Vase RDBMS

SO Sistema operativo

SPARC System Planing and Repairments Comitte, comit de planificacin de sistemas y reparaciones, subseccin de
ANSI.

UML Uniform Modeling Language, Lenguaje de modelado universal, utilizado para realizar modelos conceptuales de
informacin orientada al objeto.

X3 Seccin de ANSI encargada de los estndares de ordenadores y m

4.1 Peligros en el diseo de bases de datos relacionales

Recordemos que cada esquema de
relacin consiste en diversos atributos y el
esquema de base de datos consta de
algunos esquemas de relacin.

Hasta aqu, hemos supuesto que los
atributos se agrupan para formar un
esquema de relacin empleando el sentido
comn del diseador de bases de datos o
estableciendo una transformacin del
modelo E-R a un esquema relacional.


En esta unidad se estudiar parte de la
teora que se ha desarrollado en un intento por
elegir buenos esquemas de relacin;
esto es, por medir formalmente las
razones por las que una agrupacin de
atributos en esquemas de
relacin es mejor que otra.

Hay dos niveles en los que podemos evaluar la
bondad de los esquemas de relacin:

Nivel lgico y Nivel de manipulacin (o de
almacenamiento)


El nivel lgico se refiere a la manera en
que los usuarios interpretan los
esquemas de relacin y el significado de
sus atributos.

Contar con buenos esquemas de
relacin en este nivel ayuda a los
usuarios a comprender con claridad el
significado de las tuplas de datos en
las relaciones, y por tanto a
formular sus consultas
correctamente.


El nivel de manipulacin (o de
almacenamiento) se refiere a cmo se
almacenan y actualizan las tuplas de una
relacin base (relacin base es la que se
almacena fsicamente como archivo).

En el nivel lgico nos interesan los
esquemas tanto de las relaciones base
como de las vistas (relaciones virtuales).


Existen cuatro medidas informales de la
calidad para el diseo de esquemas de
relaciones:

Semntica de los atributos,

Reduccin de los valores redundantes en las
tuplas,

Reduccin de los valores nulos en las tuplas,

Prohibicin de tuplas espurias.


Semntica de los atributos.

El significado o semntica especifica cmo
se han de interpretar los valores de
los atributos almacenados en una tupla de
la relacin; dicho de otro modo,
qu relacin hay entre los
valores de los atributos de una tupla.

Cuanto ms fcil sea explicar la semntica
de la relacin mejor ser el
diseo del esquema correspondiente.



Pauta 1: Se debe disear un esquema de
relacin de modo que sea fcil explicar su
significado.

No combinar atributos de varios tipos de
entidades y tipos de vnculos en una sola
relacin.



Pauta 1:

Intuitivamente, si un esquema de relacin
corresponde a un tipo de entidades o a un tipo
de vnculos, el significado tiende a ser claro.

En caso contrario, tiende a ser una mezcla de
mltiples entidades y vnculos y, por tanto, ser
semnticamente confuso.


Informacin redundante en las tuplas y
anomalas de actualizacin

Uno de los objetivos en el diseo de esquemas
es minimizar el espacio de almacenamiento
que ocupan las relaciones base (archivos).

El problema generado por la informacin
redundante son las anomalas de actualizacin
(anomalas de insercin, anomalas de
eliminacin y anomalas de modificacin).


Informacin redundante en las tuplas y
anomalas de actualizacin

Pauta 2:

Se debe disear los esquemas de las
relaciones base de modo que no haya
anomalas de insercin, eliminacin o
modificacin en las relaciones. Si hay
anomalas, se deben sealar con claridad a
fin de que los programas que actualicen
la base de datos operen correctamente.


Valores nulos en las tuplas.

En algunos diseos de esquemas se agrupan
muchos atributos para formar una relacin
gruesa, si muchos de los atributos no se
aplican a todas las tuplas de la relacin, existen
un gran nmero de nulos en esas tuplas.

Lo anterior origina un considerable
desperdicio de espacio en el nivel
de almacenamiento y dificulta el
entendimiento del significado de los
atributos.



En algunos diseos de esquemas se agrupan
muchos atributos para formar una relacin
gruesa, si muchos de los atributos no se
aplican a todas las tuplas de la relacin, existen
un gran nmero de nulos en esas tuplas.

Lo anterior origina un considerable
desperdicio de espacio en el nivel
de almacenamiento y dificulta el
entendimiento del significado de los
atributos.



Otro problema con los nulos es cmo
manejarlos cuando se aplican funciones
agregadas como COUNT o SUM, adems los
nulos pueden tener diversas interpretaciones.



Veamos algunas interpretaciones de los nulos:

1. El atributo no se aplica a esta tupla.

2. Se desconoce el valor del atributo para
esta tupla.

3. El valor se conoce pero est ausente, esto
es, todava no se ha registrado.



Pauta 3:

Hasta donde sea posible, se debe evitar
incluir en una relacin base atributos
cuyos valores puedan ser nulos. Si no
es posible evitar los nulos,
debemos asegurarnos de que se
apliquen slo en casos
excepcionales y no a la mayora de las
tuplas de una relacin.


Tuplas espurias.

Son tuplas que representan informacin
errnea.

Pauta 4: Se debe disear los esquemas de
relacin de modo que puedan reunirse
mediante condiciones de igualdad sobre
atributos que sean claves primarias o claves
externas, a fin de garantizar que no se
formarn tuplas espurias.


Introduccin a la normalizacin.

En el proceso de normalizacin, segn la
propuesta original de Codd (1972), se somete a
un esquema de relacin a una serie de pruebas
para certificar si pertenece o no a una cierta
forma normal.

En principio, Codd propuso tres formas
normales, a las cuales llam primera, segunda y
tercera formas normales.



Posteriormente, Boyce y Codd propusieron una
definicin ms estricta de 3FN, a la que se
conoce como forma normal Boyce-Codd.

Todas estas formas se basan en las
dependencias funcionales entre los
atributos de una relacin.



Ms adelante se propusieron una cuarta
forma normal (4FN) y una
quinta (5FN), con fundamento en
los conceptos de dependencias multivaluadas
y dependencias de reunin
respectivamente.



La normalizacin de los datos puede
considerarse como un proceso durante el cual
los esquemas de relacin insatisfactorios se
descomponen repartiendo sus atributos entre
esquemas de relacin ms pequeos que
poseen propiedades deseables.

El principal objetivo del proceso de
normalizacin original es garantizar que no
ocurran las anomalas de actualizacin.



Las formas normales proveen a los
diseadores de bases de datos lo siguiente:

1) Un marco formal para analizar los esquemas
de relacin con base en sus claves y en las
dependencias funcionales entre sus atributos.

2) Una serie de pruebas que pueden efectuarse
sobre esquemas de relacin individuales de
modo que la base de datos relacional pueda
normalizarse hasta el grado deseado.



Cuando una prueba falla, la relacin que
provoca el fallo debe descomponerse en
relaciones que individualmente satisfagan las
pruebas de normalizacin.



Cuando una prueba falla, la relacin que provoca el
fallo debe descomponerse en relaciones que
individualmente satisfagan las pruebas de
normalizacin.

En resumen, podemos concluir que la
normalizacin de datos es un proceso de
refinamiento de las estructuras de la base de
datos para mejorar la velocidad a la que los
datos puedan accederse, as como mejorar su
integridad.



Cuando una prueba falla, la relacin que provoca el
fallo debe descomponerse en relaciones que
individualmente satisfagan las pruebas de
normalizacin.

En resumen, podemos concluir que la
normalizacin de datos es un proceso de
refinamiento de las estructuras de la base de
datos para mejorar la velocidad a la que los
datos puedan accederse, as como mejorar su
integridad.


Dependencias funcionales

El concepto ms importante en el diseo de
esquemas de relacin es el de DEPENDENCIA
FUNCIONAL.

Una df es una restriccin entre dos conjuntos
de atributos de la base de datos.



Supongamos el esquema de la relacin

R={A1, A2, , An}

Una dependencia funcional, denotada XY (X
determina funcionalmente a Y o Y depende
funcionalmente de X), entre dos conjuntos de
atributos X e Y que son subconjuntos de R,
especifica una restriccin sobre las posibles
tuplas que podran formar una relacin r de R.



si t1(X)=t2(X), se debe cumplir tambin que
t1(Y)=t2(Y)

X determina funcionalmente a Y en un esquema
de relacin R si y slo si, siempre que dos tuplas
de r(R) coincidan en su valor X,
necesariamente deben coincidir en su valor Y.



Observacin: Si una restriccin de R dice que no
puede haber ms de una tupla con un valor X
dado en cualquier relacin r(R), esto significa que
X es una clave candidata de R.

Si XY se cumple en R, no implica que Y
X
se cumple en R tambin.

LAS DEPENDENCIAS FUNCIONALES SON
PROPIEDADES DE LA SEMNTICA DE LOS
ATRIBUTOS.



Siempre que la semntica de dos conjuntos de
atributos de R, indique quedebe cumplirse una
dependencia funcional, especificamos a esa
dependencia como una restriccin.

La utilidad principal de las dependencias
funcionales es describir mejor un esquema de
relacin R mediante la especificacin de
restricciones sobre sus atributos que deban
cumplirse siempre.



Una dependencia funcional es una propiedad del
esquema de relacin R (intensin), y no de un
ejemplar de relacin permitido r de R (extensin)
en particular. Por esto una dependencia funcional
no puede inferirse automticamente de una
extensin de relacin r dada, sino que debe
definirla explcitamente alguien que conozca la
semntica de los atributos de R.



Ejemplo,

EMP_DEPTO(NOMBREE, NSS, FECHAN,
DIRECCION, NUMEROD, NOMBRED,
NSSGTED)

F={ NSS NOMBREE, FECHAN, DIRECCION
NUMEROD NOMBRED, NSSGTED}



Ejemplo,

EMP_PROY(NSS, NUMEROP, HORAS,
NOMBREE, NOMBREP, LUGARP)

F={ NSS NOMBREE

NSS, NUMEROP HORAS
NUMEROP NOMBREP, LUGARP }

4.2 Primera y segunda forma normal

Primera forma normal (1FN)

Se define para prohibir los atributos
multivaluados, los atributos compuestos y
sus combinaciones.

La 1FN establece que los dominios de los
atributos deben incluir slo valores atmicos,
es decir, se prohbe tener un conjunto de
valores, como valor de un atributo.


Segunda forma normal (2FN)

Se basa en el concepto de dependencia
funcional total.

XY es una DEPENDENCIA FUNCIONAL
TOTAL si la eliminacin de cualquier
atributo A de X hace que la dependencia
deje de ser vlida.

Es decir cualquier atributo A X,

(X-{A}) NO DETERMINA FUNCIONALMENTE A Y



XY es una DEPENDENCIA FUNCIONAL
PARCIAL si es posible eliminar un atributo
A X de X y la dependencia
sigue siendo vlida.

Es decir cualquier atributo A X,

(X-{A}) SI DETERMINA FUNCIONALMENTE A Y



Por ejemplo,
NSS,NUMEROP HORAS
Es una dependencia total, porque no se
cumple:

NSS HORAS ni

NUMEROP HORAS



Sin embargo, la dependencia

NSS, NUMEROP NOMBREE

es una dependencia parcial, porque se cumple
que:

NSS NOMBREE



Otro concepto a definir es el atributo primo.

Un atributo del esquema de relacin R se
denomina atributo primo de R si es miembro
de cualquier clave de R.

Por ejemplo,

Para el esquema de relacin

TRABAJA_EN (NSS, NUMEROP, HORAS)



TRABAJA_EN (NSS, NUMEROP, HORAS)
La clave es NSS, NUMEROP, por tanto
NSS es atributo primo y
NUMEROP es atributo primo, porque ambos
son parte de la clave.

HORAS es atributo no primo, porque no
participa en ninguna clave.



Un esquema de relacin R est en 2FN si
todo atributo no primo A en R depende
funcionalmente de manera total de la clave
primaria de R



Por ejemplo

F={ NSS, NUMEROP HORAS
NSS NOMBREE NO
NUMEROP NOMBREP NO
NUMEROP LUGARP NO}



Las dependencias marcadas con NO,
dependen parcialmente de la clave primaria
NSS, NUMEROP.

Entonces hay que descomponer el esquema
EMP_PROY en los siguientes esquemas:


ESQUEMA ANTERIOR:


ESQUEMA EN 2FN:

EP1(NSS, NUMEROP, HORAS)
EP2(NSS, NOMBREE)
EP3(NUMEROP, NOMBREP, LUGARP)



Los correspondientes conjuntos de
dependencias funcionales:

DFEP1={NSS,NUMEROP HORAS}
DFEP2={NSS NOMBREE}
DFEP3={NUMEROP NOMBREP
NUMEROP LUGARP}
Donde EP1, EP2 y EP3 se encuentran en 2FN

4.3 Tercera forma normal y la FN de Boyce-Codd

Tercera forma normal

La tercera forma normal se basa en el
concepto de dependencia transitiva.

Una dependencia funcional X Y en un
esquema de relacin R es una dependencia
transitiva si existe un conjunto de atributos Z
que no sea un subconjunto de cualquier clave
de R, y se cumplen tanto X Z como Z Y,
y adems Z X y adems Z no define
funcionalmente a X.



Por ejemplo,

EMP_DEPTO(NOME, NSS, FECHAN, DIREC,
NUMD, NOMD, NSSG)

F={NSS NOME, NSS FECHAN,
NSS DIREC, NSS NUMD,
NUMD NOMD (NO), NUMD NSSG (NO)}

NUMD no es un subconjunto de la clave



La dependencia NSS NSSG es transitiva
a travs de NUMD, porque se cumplen las
dos dependencias

NSS NUMD y NUMD NSSG

(Recordemos X Z as como Z Y)

y adems NUMD no es un subconjunto de
la clave.



Un esquema de relacin R est en 3FN, si
est en 2FN y ningn atributo no primo de
R depende transitivamente de la clave.



Si tomamos el esquema EMP_DEPTO est en
2FN, no existen dependencias parciales
respecto a la clave primaria.

Pero no est en 3FN porque existen
dependencias transitivas.



EMP_DEPTO(NOME, NSS, FECHAN, DIREC,
NUMD, NOMD, NSSG)

Descomponemos el esquema EMP_DEPTO
en dos esquemas que se encuentran en 3FN.

ED1(NOME, NSS, FECHAN, DIREC, NUMD)
ED2(NUMD, NOMD, NSSG)



Los correspondientes conjuntos de
dependencias funcionales de ED1 y ED2.

DFED1= { NSS NOME, NSS
FECHAN, NSS DIREC, NSS, NUMD}

DFED2= {NUMD NOMD, NUMD NSSG}


Forma normal de Boyce-Codd (FNBC)

Esta regla se deriva de 3FN, pero es ms estricta.

Un esquema de relacin R est en FNBC,
siempre que una dependencia funcional XA es
vlida en R, entonces X es una superclave de R.

La nica diferencia entre FNBC y 3FN es que la
condicin de 3FN, que permite que:

A sea primo si X no es una superclave,

no es permitido en FNBC.



En la prctica, casi todos los esquemas de
relacin que estn en 3FN tambin estn en
FNBC. Slo si existe una dependencia XA
en un esquema de relacin R, y X no es
una superclave y A es un atributo primo, R
estar en 3FN pero no en FNBC.



Basado en el esquema de lotes

LOTES(ID_PROPIEDAD, NOMBRE_MUNIC,
NUM_LOTE, AREA, PRECIO, TASA_FISCAL)

Supongamos que tenemos miles de lotes en la
relacin pero que dichos lotes pertenecen a
slo dos municipios. A y B. Supongamos
tambin que los tamaos de los lotes en el
municipio A son de slo 0.5,0.6,0.7,0.8,0.9 y
.10 hectreas.

1
4.3 Tercera forma normal y la FN de
Boyce-Codd


y los lotes en el municipio B estn restringidos
a 1.1, 1.2, 1.9 y 2.0 hectreas.

En una situacin as tendramos la
dependencia funcional
AREANOMBRE_MUNIC.

La relacin lotes sigue estando en 3FN porque
NOMBRE_MUNIC es un atributo primo.

2

CC42A/CC55A - BASES DE DATOS
Profesor: Claudio Gutierrez Auxiliar:
Mauricio Monsalve


1 El concepto de dependencia funcional

1.1 El concepto de dependencia funcional

Hay veces en que los atributos estan relacionados entre s de manera mas especfica que la de
pertenecer a una misma relacion. Hay veces en que es posible determinar que un atributo depende
de otro f uncionalmente, como si existiera una funcion f en el mundo, tal que t[A] = f (t[B]).
La funcion se anotara como f : A B, pero como f es desconocida (o sino B sera un atributo
derivado), solo nos quedamos con A B, la dependencia funcional, que se lee A determina B.
Formalmente, X Y en R se cumple si y solo si s, t R, s[X ] = t[X ] s[Y ] = t[Y ]. Esto es
analogo a las funciones: x
1
, x
2
X, x
1
= x
2
f (x
1
) = f (x
2
), con f : X Y .

1.2 Utilidad en el diseno de bases de datos

Las dependencias funcionales son restricciones de integridad sobre los datos. Conocer las dependen-
cias funcionales en el momento del diseno de la base de datos permite crear mecanismos para evitar
la redundancia (y los potenciales problemas de integridad que eso conlleva) y mejorar la eficiencia.

1.3 Un ejemplo real

Por ejemplo, sea la siguiente relacion: Vehiculo(serie, nombre, motor, carrocera, peso, eficien-
cia). Aqu, serie es la llave. Por ende, hay solo un [modelo de] motor por serie, solo una [forma de]
carrocera por serie, solo un peso por serie y solo una eficiencia [energetica] por serie: nombre = nom-
bre(serie), motor = motor(serie), etcetera. O sea, serie nombre, motor, carrocera, peso, ef iciencia
(la relacion es funcion de su llave; solo hay una tupla por llave).
Otra observacion, que requiere mucho mas conocimiento del problema, nos indica que la eficien-
cia energetica del vehculo es una funcion del motor, la carrocera y el peso. Considerando esto,
tenemos que motor, carrocera, peso ef iciencia. Por que? La eficiencia energetica consiste en la
distancia que puede recorrer un vehculo por litro, a una velocidad moderadamente alta. La poten-
cia del vehculo reside en el motor: el modelo de motor indica la fuerza que imprime el vehculo. Sin
embargo, esta fuerza es contrarrestada por el roce aerodinamico del vehculo, que es una funcion
del roce viscoso del aire (es un dato fijo) y de la forma de la carrocera. Y el peso entrega la masa
del vehculo (masa = 9, 8m/s
2
peso). Si se divide la fuerza resultante del vehculo por la masa,
se obtiene la aceleracion (y en un equilibrio de velocidades se obtiene la eficiencia). Luego, existe
una funcion tal que ef iciencia = ef iciencia(motor, carrocera, peso).
1

3
1
Siendo mas precisos, notemos que ef iciencia = g(motor, carrocera)/peso. Entonces, este atributo es mediana-
mente derivado. Luego, es posible definir un atributo ef ic motor carro = g(motor, carrocera) a partir del cual
eficiencia se vuelve un atributo derivado. Esta solucion evita aun mas redundancia, aunque es mas idealizada.
4
1.4 Un ejemplo mas sencillo

A veces es facil encontrar dependencias en un esquema. Esto es un indicado de un mal modelo
entidad-relacion o de una mala conversion a relacional.
Por ejemplo, sea Pelcula(ttulo, ano, estudio, presidente, fono presidente). Digamos que ttulo
es llave de la relacion (determina todo). Sin embargo, notemos que el presidente de un estudio se
puede determinar conociendo el estudio y el ano (idealmente). Luego, estudio, ano presidente.
Ademas, es claro que presidente f ono presidente.
La relacion Pelcula fue mal modelada desde un principio. En un modelo entidad-relacion,
Pelcula, Estudio y Presidente habran sido entidades distintas, luego relaciones distintas en
el modelo relacional.

1.5 Un ejemplo visual

Que dependencias funcionales se cumplen en esta relacion?

A B C D E F G H
1 a eth cdr cdr 0 0x00 10
2 a eth car cdr 0 0xf0 10
3 b usb cdr car 0 0xff 10
4 b com car car 1 0x68 10
5 c lpt cddr car 1 0xa0 12

Algunas dependencias funcionales faciles de ver:

A determina toda la relacion (A es llave).

B determina H.

C determina B.

C determina F.

D,E determina toda la relacion (D,E es llave).

G es llave.

etcetera (hay varias mas).

1.6 Como obtener las dependencias funcionales?

La mejor manera de obtenerlas es a traves del conocimiento del problema. Es lo mas disponible en
la fase de diseno de una base de datos. Sin embargo, esto puede tornarse bastante difcil, como en el
caso del vehculo (honestamente, esto puede ocurrir cuando la base de datos modela conocimiento
tecnico, que escapa al sentido comun).
Otra manera, relacionada con el ejemplo anterior, es comprobar dependencias funcionales sobre
una gran poblacion de datos usando la definicion.
5
2 Demostracion de los axiomas de Armstrong

2.1 Ejercicio

Los axiomas de Armstrong son los siguientes:

1. (dependencia trivial) A B A.

2. (aumentacion) A B (A C ) (B C ). O mas comodamente, A B AC BC .

3. (transitividad) A B B C A C .
Demuestre los axiomas de Armstrong.

2.2 Solucion

Esto se hace mediante la definicion de dependencia funcional.

1) (dependencia trivial)
Sea A = A
1
, ..., A
n
, y sea B A tal que B = B
1
, ..., B
m
. Luego, i < m, j < n, B
i
= A
j
.
Entonces, sean s, t R, tal que A esq(R) (A es parte del esquema de R). Luego, si s[A] = t[A]
j < n, s[A
j
] = t[A
j
] (por definicion
2
). Esto implica, en particular, que s[B
i
] = t[B
i
], i < m.
Entonces se concluye que A B A. O

2) (aumentacion)
Sea A B, A, B esq(R). Luego, s, t R, s[A] = t[A] s[B] = t[B]. Si exigimos que
s[C ] = t[C ], s, t R, s[A] = t[A] s[C ] = t[C ] s[B] = t[B] se sigue cumpliendo (un mero
asunto de logica proposicional). Y sin afectar los valores de verdad, se cumple que s, t R, s[A] =
t[A] s[C ] = t[C ] s[B] = t[B] s[C ] = t[C ] (nuevamente, un mero asunto de logica). Pero la
ultima implicancia es lo mismo que AC BC , con lo que se prueba el axioma. O

3) (transitividad)
Sean A, B, C esq(R) y las dependencias A B y B C . Por definicion, se cumplen:
A B : s, t R, s[A] = t[A] s[B] = t[B]
B C : s, t R, s[B] = t[B] s[C ] = t[C ]
Luego, usando la transitividad de las implicancias (), se obtiene:
s, t R, s[A] = t[A] s[C ] = t[C ], o sea, A C . O

3 Una manera mas directa de proceder

3.1 Una pequena propiedad

Sea A BC y B D. Entonces, A ABC D.
Prueba:
A BC A A BC A A ABC (aumentacion).
B D B B D B B BD (aumentacion).
B BD B AC BD AC ABC ABC D (aumentacion).
A ABC ABC ABC D A ABC D (transitividad). O

2
Esto es igual a la comparacion de vectores: dos vectores son iguales si y solo si cada componente posee el mismo
valor: X
~
= Y
~
j, Xj = Yj .
6
3.2 Ejemplo de uso de la regla anterior

Sea R(A, B, C ) y F = {A B, C AB, B BC }. Calcular F+.
(A modo de nota, F+ es la clausura de F. Es el conjunto de todas las dependencias funcionales
que se pueden deducir de F.)
Solucion:
A+ : A AB(A B)
A AB ABC (B BC ) llave
B+ : B BC (B BC idem)
B BC ABC (C AB) llave
C + : C ABC (C AB) llave
AB+ : AB ABC
AC + : AC ABC
BC + : BC ABC
ABC + : ABC ABC

Como se puede notar, resolver dependencias funcionales aumentando el lado derecho (el deter-
minado) de las dependencias, asegura el avance de la resolucion. En efecto, cada dependencia se
puede usar una sola vez por la clausura de cada atributo. Ademas, la resolucion del problema se
simplifica bastante.

4 Ejercicios

4.1 Problema

Sea R(A, B, C, D, E) y DF = {A BC, C D E, B D, E A}. Determinar las llaves
candidato (minimales) de R.

4.2 Solucion

Calcularemos las clausuras de todos los atributos (descartando cualquier superllave). Para dar
legibilidad a la respuesta, enumero las dependencias funcionales de DF:

DF = {A BC (1), C D E(2), B D(3), E A(4)}
As, cada vez que use una dependencia funcional, la mencionare con un numero.
A+: A ABC (1) ABC D(3) ABC DE(2). Luego A es llave candidato.
B+: B BD(3).
C+: C C .
D+: D D.
E+: E A(4) ABC DE(A+). E es llave candidato.
Para no considerar superllaves, no usare A ni E. Solo combinare B, C y D.
BC+: BC BC D(3) BC DE(2) ABC DE(4). BC es llave candidato.
BD+: BD BD.
CD+: C D C DE(2) ABC DE(E+). CD es llave candidato.
No puedo considerar mas combinaciones.
Luego, A, E, BC y CD son llaves candidato.
7
4.3 Problema

Sea R(A, B, C, D, E, F ) y DF = {BD E, C D A, E C, B D}. Cuales son las llaves
minimales?

4.4 Solucion

Aqu conviene hacer una observacion: todo atributo que no es determinado por otro es parte de la
llave minimal (por que?). Observando el lado derecho de cada dependencia, vemos que ni B ni F
son determinados por otros atributos (F ni siquiera es parte de alguna dependendencia funcional).
Luego, empezar por BF+ puede ser una buena estrategia.
Otra vez voy a enumerar las dependencias, para facilitar la lectura:

DF = {BD E(1), C D A(2), E C (3), B D(4)}

BF+: BF BDF (4) BDEF (1) BC DEF (3) ABC DEF (4). Luego, BF es llave
minimal.
Como B y F son atributos que deben ser parte de toda llave minimal, BF es la unica llave
minimal de R.

5 Formas normales

La forma normal de una relacion indica la calidad de su diseno en cuanto a la redundancia de infor-
macion evitada. Y su definicion esta basada en las dependencias, sean funcionales, multivaluadas,
de join, etc. En el curso se trabajara solo con dependencias funcionales (debido a una relacion entre
eficiencia y control de redundancia).

5.1 Primera forma normal: 1FN

Una relacion esta en primera forma normal cuando todos sus atributos son atomicos. Como se
indico en clases, siempre estamos en 1FN (por lo menos).

5.2 Segunda forma normal: 2FN

Todos los atributos no primos dependen de la totalidad de la llave (y no de un subconjunto de esta).
Nota: por la llave se entiende de cualquier llave minimal o bien todas las llaves minimales.

5.3 Tercera forma normal: 3FN (importante)

Un modelo de datos relacional en tercera forma normal se considera de buena calidad. 3FN garantiza
un buen equilibrio entre eficiencia y control de redundancia.
Un esquema R esta en 3FN si X Y no trivial:
- X es superllave (contiene a alguna llave candidato)
- Y es atributo primo (es parte de alguna llave candidato)
Es importante destacar es necesario conocer todas las llaves candidato o minimales.
8
5.4 Forma normal de Boyce-Codd: FNBC (importante)

Una forma normal ideal, el maximo control de redundancia mediante dependencias funcionales. La
idea consiste en que cada atributo depende de solo de la llave (en su totalidad, no de una parte).
Un esquema R esta en FNBC si X Y no trivial, X es superllave (contiene a alguna llave
candidato).

5.5 Cuarta forma normal: 4FN

Es como FNBC, pero con dependencias multivaluadas.
Un esquema R esta en 4FN si X Y no trivial, X es superllave. Pero notese que, como X
es superllave, X Y . Luego, 4FN exige que toda dependencia multivaluada sea en realidad una
dependencia funcional.

5.6 Quinta forma normal: 5FN

Se trata de producto-reunion (join). Una relacion tal que R = A B C
3
, todas relaciones con
distintos esquemas, NO esta en 5FN. Una relacion esta en 5FN cuando no se puede dividir y volver
a reconstruir sin perdida de informacion.

5.7 Lo que interesa

Interesa mucho el dominio de la tercera forma normal y la forma normal de Boyce-Codd. En partic-
ular, la 3FN es la forma normal mas alta que asegura preservacion de la informacion (preservacion
de join) y de las dependencias. Pero si se puede llegar a FNBC, mejor todava.
Ejercicio propuesto: Demuestre que: 4F N F N BC 3F N 2F N (alguna version de
esta pregunta ha aparecido en controles).

6 Normalizacion

El proceso de normalizacion es un proceso de descomposicion de los esquemas de relacion hasta que
todas las relaciones alcancen la forma normal deseada. En general, interesa:

1. Determinar las llaves candidato (minimales) de cada relacion.

2. Determinar la forma normal de la relacion.

3. Esta en FNBC? Sino, normalizar.

4. La normalizacion no asegura la preservacion de informacion y dependencias? Conformarse
con 3FN.

Ahora, un par de algoritmos para normalizar. Estos algoritmos aseguran la preservacion de la
informacion pero no necesariamente la preservacion de las dependencias (ello no siempre se puede
lograr con FNBC).

3
El join natural se anota como * y como aa.
9
6.1 Algoritmo para normalizar en FNBC

De manera informal, el algoritmo es el siguiente:

1. (Calcular F+)

2. Sea un esquema R
i
que no esta en FNBC: determinar X Y que hace que R
i
no este en
FNBC y agregar a la descomposicion (R
i
Y ) (X Y ) y remover R
i
.

3. Terminar cuando todos los esquemas esten en FNBC.

En resumen, por cada dependencia funcional conflictiva con FNBC, sacar el lado derecho de la
relacion con problemas y agregar una nueva relacion que guarde la dependencia. Esta estrategia de
normalizacion no asegura preservar dependencias, pero s asegura la recuperacion de la informacion
por join.

6.2 Ejemplo

Sea R(A, B, C, D, E) y F = {A BC (1), C D(2), B E(3)}.

1. R no esta en FNBC. Basta ver la dependencia (2); claramente C no es llave de R. Entonces
partimos R en R1(A,B,C,E) y R2(C,D). No se ha roto ninguna dependencia.

2. R1 no esta en FNBC. Basta ver (3); claramente B no es llave de R. Entonces partimos R1 en
R3(A,B,C) y R4(B,E). No se ha roto ninguna dependencia.

3. R2, R3 y R4 estan en FNBC, por lo que el algoritmo concluye.

6.3 FNBC infactible (ejercicio)

Uno de los objetivos de diseno es preservar la informacion (recuperacion mediante join) y las
dependencias.
Sea R(A, B, C ) y F = {AB toC, C B}. En que forma normal se encuentra? Trate de
normalizar a FNBC. Es posible lograr una descomposicion de R que este en FNBC y preserve las
dependencias funcionales?

6.4 Algoritmo para normalizar en 3FN

1. Calcular F mnimo (conjunto covertor mnimo, conjunto canonico, equivalente minimal, re-
cubrimiento minimal, etc.).

2. Convertir cada dependencia en una relacion (X Y R
k
(X Y )).

3. Si no esta la llave en una relacion, agregarla.

La dificultad estriba en obtener el conjunto convertor mnimo de dependencias funcionales. De
todas maneras, un conjunto es mnimo cuando:

1. X Y , Y es atributo atomico.

2. Remover X Y altera F+.

3. Si X Y , $W X : W Y .
Anlisis y Diseo de Bases de Datos M.Sc. Ing. Hernando Buenao
Un Enfoque Prctico para Aprendizaje en el Aula 75

6
.
5

E
j
e
m
p
l
o

Sea R(A, B, C, D, E) y F = {A B(1), A C (2), C D(3),
B E(4)}. F es mnimo.

1. Al notar A+ vemos que: A AB(1) ABC (2) ABC D(3)
ABC DE(4). Y como A
no es determinada por ninguna dependencia funcional, A es la
unica llave.

2. Tomando las cuatro dependencias, tenemos: R
1
(A, B), R
2
(A, C ),
R
3
(C, D), R
4
(B, E). Como
R
1
y R
2
preservan la llave, la normalizacion ha terminado.

OJO: Sean S y R dos relaciones en 3FN con la misma llave (y
todas las dependencias estan preservadas). Que ocurre con S R?
(Hable de llaves candidato, forma normal, etc.)

7

Y

e
l


i
n
f
o
r
m
e

Lo primero es convertir el diagrama E/R en relacional. Este es un paso
bastante trivial pero puede tomar una cantidad importante de tiempo.
Son cruciales las decisiones sobre entidades debiles y herencia.
Luego viene lo complicado: las dependencias funcionales. Es
esencial una buena revision de dependencias funcionales. Este es un
problema no trivial: sale de su conocimiento del problema. En
particular, la observacion debera ir sobre las relaciones n-arias, con n >
2, sobre los atributos multivaluados compuestos y sobre aquellos
atributos que casi son derivados. Otra fuente de dependencias
funcionales reside en las cardinalidades del diagrama E/R (ojo con las
(1,1) o (0,1)). Las relaciones con muchos atributos tambien pueden
albergar bastantes dependencias funcionales (de entre los trabajos que
correg, hay varios de estos casos). Y obviamente estan las relaciones de
la forma llave
relacion y
las triviales
4
.
Luego de obtenidas las dependencias funcionales, es menester
recalcular las llaves. Conocer todas las llaves candidato es una
obligacion para determinar la forma normal de sus relaciones. Por
supuesto, las llaves candidato son minimales.
El siguiente paso es obtener la forma normal de todas las relaciones
del modelo. Especialmente crticas son las relaciones con muchos
atributos, puesto que pueden albergar muchas dependencias funcionales.
Revsese muy bien para buscar relaciones que no cumplan con FNBC.
Ademas es importante saber si ya cumplen 3FN.
Toda relacion en FNBC debera ser normalizada, en lo posible, para
obtener una descomposicion

FNBC preservando la informacion y las dependencias. Si esto no es
posible, conformarse con lograr
3FN. Naturalmente, todo esto debera
estar muy bien explicado.
Y no se confen. Recuerdo haber visto entidades laaaargas que
pueden tener bastantes dependencias funcionales, relaciones ternarias
y cuaternarias que ciertamente albergaban dependencias funcionales (y
que llevaran a reducir la llave), y muchas restricciones relacionadas
con las cardinalidades. Si bien no recuerdo haber visto modelos sobre
conocimiento tecnico, aun es posible descubrir dependencias sobre temas
mas cercanos a la cultura general.

4
Omita las dependencias triviales


NORMALIZACION

Definicin.

La normalizacin es una tcnica que se utiliza para crear relaciones lgicas
apropiadas entre tablas de una base de datos. La normalizacin se adopt
porque el viejo estilo de poner todos los datos en un solo lugar, como un
archivo o una tabla de la base de datos, era ineficiente y conduca a
errores de lgica cuando se trataba de manipular los datos.

El proceso de normalizacin parte de las formas normales definidas por
Edgar Frank Codd (1970) creador de las bases de datos relacionales.
Primeramente, Codd formul las tres primeras formas normales (1FN,

2FN, 3FN); posteriormente, unas anomalas detectadas forzaron a crear
una forma normal ms completa que la 3FN, es la FNBC (forma normal de
Boyce y Codd), despus Fagin defini la 4FN y 5FN.

La normalizacin es el proceso mediante el cual se transforman datos
complejos a un conjunto de estructuras de datos ms pequeas, que
adems de ser ms simples y ms estables, son ms fciles de mantener.

Los seres humanos tenemos la tendencia de simplificar las cosas al
mximo. Lo hacemos con casi todo, desde los animales hasta con los
automviles. Vemos una imagen de gran tamao y la hacemos ms simple
agrupando cosas similares juntas. Las guas que la normalizacin provee
crean el marco de referencia para simplificar una estructura de datos
compleja.

La normalizacin se utiliza para mejor el esquema lgico, de modo que
satisfaga ciertas restricciones que eviten la duplicidad de datos.

Objetivos de la Normalizacin

Minimizar la redundancia
Minimizar el mantenimiento de datos
Minimizar el impacto de futuros cambios (anomalas de actualizacin y
anomalas de borrado) de de datos, e ingreso de informacin (anomalas
de insercin).

Ventajas de la Normalizacin

Evita anomalas en inserciones, modificaciones y borrados.
Mejora la independencia de datos.
No establece restricciones artificiales en la estructura de los datos.
Facilidad de uso.
Flexibilidad.
Precisin.
Seguridad.
Facilidad de implementacin.
Independencia de datos.
Claridad.
Facilidad de gestin.
Mnima redundancia.
Mximo rendimiento de las aplicaciones.
Existen 5 Formas Normales:
Primera Forma Normal (1FN)
Segunda Forma Normal (2FN)
Tercera Forma Normal (3FN)
Forma Normal de Boyce Codd(FNBC)
Cuarta Forma Normal (1FN)
Quinta Forma Normal (1FN)

Cada una de estas formas tiene sus propias reglas.

En general, las primeras tres formas normales son suficientes para cubrir
las necesidades de la mayora de las bases de datos.

Antes de iniciar con la teora referente a normalizacin es necesario
conocer los conceptos de Dependencias Funcionales, los mismos que se
utilizarn en la teora de Normalizacin.

Dependencias Funcionales

Codd introdujo el concepto de dependencia funcional como:

"Dados dos atributos A y B de una relacin R, se dice que B es
funcionalmente dependiente de A, si para cada valor de A existe un valor
de B, y slo uno, asociado con l.

En otros trminos, se puede decir que si dos tuplas de una relacin R
tienen el mismo valor en el atributo A deben tener el mismo valor en el
atributo B. O dicho de otro modo, si conocemos el valor de A podemos
conocer el valor de B.

Definicin. Un atributo B de un esquema de relacin R depende
funcionalmente de un atributo A de R, si y slo si, cada valor de A est
asociado con un nico valor de B. Es decir, dado un valor de A queda
unvocamente determinado el valor de B. Se dice que B depende
funcionalmente de A, y que A determina funcionalmente a B. Tanto A
como B pueden ser atributos simples o compuestos

Suponga que tiene R = {A1, A2, A3, , An} , R es una relacin y A es un
conjunto de atributos. Sea X, Y subconjuntos de A.
Notacin DF: X Y
Se lee: X determina o implica Y
Y depende funcionalmente de X
Si y slo si cada valor de X tiene asociado en todo momento un
nico valor de Y

Donde: X es el determinante
Y es el implicado
X e Y se les dice Descriptores.
Un determinante es un conjunto del que depende funcionalmente
otro conjunto de atributos llamado implicado.
Ejemplo:
CI_estudiante Nombre_estudiante
Las CI del estudiante determina el nombre del estudiante.

Dos descriptores son equivalentes cuando X Y Y X.
Ejemplo:
CI_ estudiante Num_Carnet_estudiante y
Num_Carnet _estudiante CI_estudiante

Notacin:

X Y bien, X1, , Xn Y1,, Ym n,m >= 1

Axiomas de Amstrong

Conjunto de dependencias, que permite encontrar otras dependencias
implicadas por ellas, las cuales son consistentes y completas.
Los axiomas de Armstrong son consistentes y completos
Los Axiomas de Armstrong son ms bien reglas de inferencia.
Estas reglas permiten deducir todas las dependencias funcionales que
tienen lugar a un conjunto dado de atributos que se dan a partir del
conocimiento del problema.

Reflexividad

Los valores de X y Y que son un conjunto de atributos Y estn incluidos o
son iguales a los conjuntos de atributos X, entonces se cumplen que Y
depende funcionalmente de X.

Es decir que matemticamente es:
(Y S X) S(X S Y)
Por ejemplo
(Cod_Pais SCod_Cap) S( Cod_Cap SCod_Pais)

Siendo Cod_Pais el cdigo del Pais y Cod_Cap el cdigo de la Capital.

Aumentatividad

Si el conjunto de atributos Y depende funcionalmente de X, entonces
dicha dependencia se mantiene aunque se aada un atributo a ambos
conjuntos. Es decir, si:
(X S Y) S (X.Z S Y.Z)
Por ejemplo si:

ci Snombre
ci,direccin S nombre,direccin

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

Transitividad

Si Y depende funcionalmente de X y Z depende funcionalmente de X,
entonces se verifica que Z depende funcionalmente de X. por lo tanto, si:
(X S Y) y (YS Z) S (X SZ)
Por ejemplo:
FechaDeNacimiento SEdad
Edad SPuede_Conducir
FechaDeNacimiento SEdad SPuede_Conducir

Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad
determina a Conducir, indirectamente. Por tanto podemos saber a travs
de FechaDeNacimiento si Puede_Conducir.

Aditividad

Si Y depende funcionalmente de X y tambin se cumple que Z depende
funcionalmente de X, eso implica que Y y Z dependen funcionalmente de
X. por tanto:
(X SY) y( X S Z) entonces (X SY Z)
PseudoTransitividad
Si se cumple que:
(X Y) y (WY Z) entonces (WX Z)
La demostracin de esta regla se la obtiene aplicando:
(X Y), por aumentacin (WX WY) (WY Z) y ahora tras
aplicar la transitividad (WY Z)

Por ejemplo:

(Nombre S CI) y (CI.Nom_Empresa S Sueldo)S
(Nombre.Nom_Empresa S Sueldo)
Descomposicin
Si el conjunto de atributos Y depende funcionalmente de X y tambin se
cumple que los valores del conjunto de atributos Z estn incluidos en los
valores de Y, entonces se tiene que cumplir que Z depende
funcionalmente de X. por lo tanto:
(X Y) y ( Z Y) entonces (X Z).

Se puede demostrar aplicando:

(X Y)
( Z Y), por reflexividad (Y Z)

Este conjunto de reglas nos permite abordar y resolver una serie de

problemas fundamentales que luego nos conducirn al establecimiento de
algoritmos de diseo que sean sencillos y fiables.

Estos problemas fundamentales, son :
Cierre de un conjunto de dependencias.
Equivalencia lgica de esquemas .
Deduccin de dependencias .
Cierre de un descriptor respecto de un conjunto de dependencias.
Clculo de las claves de un esquema
Tipos de Dependencias Funcionales
Dependencia Funcional Completa
Un atributo B de R tiene dependencia funcional completa de un atributo A
de una relacin R, si tiene dependencia funcional de A pero no tiene
dependencia funcional de ningn subconjunto de A.

Formato:
ASB
A determina funcionalmente a B
Ejemplo
CI.Empleado Sueldo

La cedula del empleado determina el sueldo.
El sueldo no depende de ningn subconjunto de la cdula que es la clave
primaria.

Dependencia Funcional Multivaluada

Sea A,B,C tres subconjuntos distintos de atributos de una tabla T, se dice
que A tiene una dependencia Multivaluada con B, que A multidetermina a
B, o que B depende multivaluadamente de A.. Existen casos de relaciones
en los que un atributo puede determinar a otro restringiendo su rango de

valores validos. A este tipo de dependencias se les conoce como
dependencias multivaluadas.

Formato:
AB

A multidetermina a B
Dependencia Funcional Transitiva
Sean A, B y C atributos de un esquema de relacin R; si C tiene
dependencia funcional de B y B tiene dependencia funcional de A,
entonces C tiene dependencia funcional transitiva de A.
Formato:
AB ,BC
A determina B y si B determina C entonces A determina a C

Ejemplo:
La tabla
Ciudades(ciudad, poblacin, superficie, renta, pas, continente)

ciudad pas, pas continente.
ciudad continente.
Adems, pas |ciudad. Es decir, cada ciudad pertenece a un pas y cada
pas a un continente, pero en cada pas puede haber muchas ciudades. En
este caso continente tiene una dependencia funcional transitiva con
respecto a ciudad, a travs de pas. Es decir, cada ciudad est en un pas,
pero tambin en un continente.

Diagrama de Dependencias Funcionales

Los diagramas de dependencia son grficos que representan el contexto
semntico observado en un determinado universo, donde los nodos son
atributos y los arcos representan dependencias entre nodos.
Normalmente se representan dependencias que van de un nodo o a un
solo atributo.

Es la forma grafica de representar las dependencias funcionales, as:

A A B

F Fe ec ch ha a_ _N Na ac ci im mi ie en nt to o Edad

Comprender la Dependencia Funcional es parte importante para entender
la semntica de los datos.

Ejemplo
Para la entidad Proveedor conformada por:
Proveedor (Numero_Prov, Nombre_Prov, Tipo_Prov, Ciudad).


Diagrama de Dependencia Funcional Completa

Dado los atributos A, B y C de una relacin R. Si, C depende de ambos
atributos A y B y lo denotamos as: [A, B] --> --> C, y si adems: C, no
depende de A ni tampoco depende de B exclusivamente.
C, tiene una dependencia completa de [A, B] ylo denotamos:
[A, B] --> --> C (tambin se dice: C tiene dependencia total de [A, B].

NOTA: Si existiera una dependencia funcional completa en una relacin R,
todos los dems atributos de R que no son llave primaria, debern tener la
misma dependencia completa de los mismos atributos, de lo contrario se
presentaran ineficiencias y anomalas en R, as

D D
B

C C

En el ejemplo B, tiene una dependencia completa de [C,D]->B

Se dice: B tiene dependencia total de [C,D]

Segundo Ejemplo.


En el ejemplo Fecha de Terminacin del Proyecto(Fech-Term), Tienet una
Dependencia Funcional Completa de la Clave(Num_Emp + Num_Proy), y
no depende de un subconjunto de ella.

Diagrama de Dependencia Funcional Parcial

Un atributo B de R tiene dependencia funcional parcial de un atributo C de
R, si tiene dependencia funcional de C y adems tiene dependencia
funcional de un subconjunto propio A de C.

Diagrama de Dependencia Funcional Transitiva

Sean A, B y C atributos de un esquema de relacin R; si C tiene
dependencia funcional de B y B tiene dependencia funcional de A,
entonces C tiene dependencia funcional transitiva de A.

NOTA: La dependencia transitiva no es buena en una relacin o tabla de
base de datos, porque evidencia la existencia de atributos que no
dependen nicamente de la llave primaria sino de otros atributos,
ocasionando lo que se llama: anomala en los procesos de actualizacin,
insercin o eliminacin. Una vez definidos claramente los conceptos de
Dependencia Funcional, se puede analizar la Normalizacin.

NORMALIZACION
Formas Normales

La regla de la Primera Forma Normal establece que las columnas repetidas
deben eliminarse y colocarse en tablas separadas.

Poner la base de datos en la Primera Forma Normal resuelve el problema
de los encabezados de columna mltiples. Muy a menudo, los diseadores
de bases de datos inexpertos harn algo similar a la tabla no normalizada.
Una y otra vez, crearn columnas que representen los mismos datos. La
normalizacin ayuda a clarificar la base de datos y a organizarla en partes
ms pequeas y ms fciles de entender. En lugar de tener que entender
una tabla gigantesca y monoltica que tiene muchos diferentes aspectos,
slo tenemos que entender los objetos pequeos y ms tangibles, as
como las relaciones que guardan con otros objetos tambin pequeos.

Si una relacin no est en 1FN, hay que eliminar de ella los grupos
repetitivos. Un grupo repetitivo ser el atributo o grupo de atributos que
tiene mltiples valores para cada tupla de la relacin.

Por Ejemplo: En la siguiente tabla se encuentran los datos del alquiler de
diferentes pelculas. Esta tabla se encuentra en Forma Normal 0.
(Totalmente Desnormalizada).

Para que esta tabla pase a 1FN se debe eliminar los grupos repetitivos de
las tablas individuales. Es decir la columna que contiene mltiples valores,
que es Nom_Cli contiene el nombre y el apellido del cliente, esta columna
se debe dividir en columnas individuales que guarden valores indivisibles,
como Nom_Cli, y Ape_Cli. Se puede hacer lo mismo con la columna
Nom_Ren.

La tabla en 1FN ser:


Una tabla se dice que est en 2FN si y slo si cumple dos condiciones:
1) Se encuentra en 1 FN

2) Todo atributo secundario (aqullos que no pertenecen a la clave
principal, los que se encuentran fuera de la caja) depende
totalmente (tiene una dependencia funcional total) de la clave
completa y, por tanto, no de una parte de ella.
Esta forma normal slo se considera si la clave principal es compuesta y,
por tanto, est formada por varios atributos. Si la clave principal de la
tabla est formada por un nico atributo, entonces la tabla ya se
encuentra en 2FN.
Si una tabla T tiene como atributos A, B, C, D y la clave es A.B
cumplindose las dependencias:
A.B > C
B > D
Se observa que la tabla no se encuentra en 2FN puesto que el atributo D
no tiene una dependencia funcional total con la clave entera A.B, sino con
una parte de la clave (B).
Para convertir una tabla que no est en segunda forma normal a 2FN, se
realiza una proyeccin y se crea:
1) Una tabla con la clave y todas sus dependencias totales con los
atributos secundarios afectados
2) Otra tabla con la parte de la clave que tiene dependencias, junto
con los atributos secundarios implicados
La clave de la nueva tabla ser la antigua parte de la clave.
En nuestro ejemplo, tendremos que se va a crear una tabla con los datos
de las Pelculas:

PELICULAS


Otra tabla con los datos de los prstamos de esas pelculas.


Una tabla se dice que est en tercera forma normal si y slo si se cumplen
dos condiciones:
1) Se encuentra en 2FN
2) No existen atributos no primarios que son transitivamente
dependientes de cada posible clave de la tabla.
Esto quiere decir que un atributo secundario slo se debe conocer a travs
de la clave principal o claves secundarias de la tabla y no por medio de
otro atributo no primario.
Por tanto, para pasar una tabla que no cumple la tercera forma normal a
3FN, se realiza una proyeccin y se genera:
1) Una tabla con la clave y todos los atributos no primarios que no
son transitivos
2) Otra tabla con los atributos transitivos y el atributo no primario
(que ser la clave de la nueva tabla) por medio del cual mantienen
la transitividad
Lgicamente, en la primera tabla TI, el atributo C es clave ajena con
respecto de T2 y de ese modo todos los atributos quedan relacionados
entre s. Es lo que se denomina interrelacin entre la tabla TI y T2.

En nuestro ejemplo tendremos que se van a generar las siguientes tablas:

Tabla Clientes para contener los datos de la persona que rento la pelcula
agregando en su cedula de identidad como clave.
Clientes

Tabla Rentadores para contener los datos de la persona que renta la
pelcula agregando un su cedula de identidad como clave.

Rentadores

Tabla Pelculas con los datos de las pelculas, con el cdigo de la pelcula
como clave.

Pelculas


Tabla Prestamos con el cdigo de la pelcula, cedula del cliente y la cedula
de la persona que rento, la fecha devolucin y fecha de rento

Prestamos

Hasta esta 3FN se considera un esquema de base de datos normalizado.

Forma Normal de Boyce Codd (FNBC)

Tras la creacin de la 3FN se observ posteriormente que se encontraban
algunas anomalas que no eran abordadas. Son casos de tablas que
estando en 3FN mantienen una dependencia de un atributo secundario
con parte de la clave. Para poder manejar esa dependencia en las
aplicaciones es imprescindible manejar una gran cantidad de registros
innecesarios (aqullos donde se mantiene fija la parte de la clave que
depende y va variando el resto de la clave)

La nueva definicin se debe a Boyce y Codd:
"Una tabla T est en FNBC si y slo si las nicas DF elementales son
aquellas en las que la clave principal (y claves secundarias) determinan un
atributo".
La definicin engloba la 3FN puesto que las dependencias transitivas
existen por medio de atributos secundarios que no eran clave.
Pero esta definicin realmente se cre para evitar los casos anmalos que
no se evitaban con la 3FN y que aparecen cuando a partir de un atributo
no primario se conoce una parte de la clave.
Si la clave est formada por un slo atributo, la tabla est en FNBC (si ya
estaba en 3FN) como suceda con la 2FN.
Normalizacin de bases de datos
www.mysql-hispano.org Fecha de creacin: 29 May del 2003 - 12:31 pm

Por lo tanto, para que una tabla que est en 3FN y no cumple la norma de Boyce-Codd se encuentre en FNBC se
realiza una proyeccin procediendo de la siguiente manera:
1. Se crea una tabla con la parte de la clave que es independiente (A)
y todos los atributos no primarios (C)
2. Se crea otra tabla con la parte de la clave restante y el atributo secundario del que depende, y ser
ste ltimo la clave de la nueva tabla


La 4FN la gener Fagin tras el teorema que demostr y que dice:
"Una tabla T con atributos A, B y C se puede descomponer sin prdidas en sus dos proyecciones T1(A,B) y T2(A,C)
si y solo si la Dependencia Multivaluada A B | C se cumple en T"
De ese modo, se define la 4FN de la siguiente forma:
Una tabla T se dice que est en 4FN si cumple dos condiciones:
1) Est en FNBC.
2) Las nicas Dependencias Multivaluadas existentes son las Dependencias Funcionales de la clave con
los atributos secundarios.


Para que una tabla se encuentra en 5FN se deben cumplir dos condiciones:
1) Se encuentra en 4FN
2) Toda Dependencia de Join viene implicada por las claves (principal o secundarias) de la tabla.
Es decir, que la tabla estar en 5FN si es posible generar unas proyecciones y al realizar su join, los
atributos comunes que realizan la operacin (atributos de join) estn formados por claves (principal o
secundarias) de la tabla.


Se explican los conceptos de la normalizacin de bases de datos, mismos
que son necesarios para un buen diseo de una base de datos.

www.mysql-hispano.org Fecha de creacin: 29 May del 2003 - 12:31 pm

www.mysql-hispano.org 1 of 5

Qu es la normalizacin

La normalizacin es el proceso mediante el cual se transforman datos complejos a un conjunto de
estructuras de datos ms pequeas, que adems de ser ms simples y ms estables, son ms
fciles de mantener. Tambin se puede entender la normalizacin como una serie de reglas que sirven
para ayudar a los diseadores de bases de datos a desarrollar un esquema que minimice los
problemas de lgica. Cada regla est basada en la que le antecede. La normalizacin se adopt porque el
viejo estilo de poner todos los datos en un solo lugar, como un archivo o una tabla de la base de datos,
era ineficiente y conduca a errores de lgica cuando se trataban de manipular los datos.

La normalizacin tambin hace las cosas fciles de entender. Los seres humanos tenemos la tendencia
de simplificar las cosas al mximo. Lo hacemos con casi todo, desde los animales hasta con los
automviles. Vemos una imagen de gran tamao y la hacemos ms simple agrupando cosas similares
juntas. Las guas que la normalizacin provee crean el marco de referencia para simplificar una estructura
de datos compleja.

Otra ventaja de la normalizacin de base de datos es el consumo de espacio. Una base de datos
normalizada ocupa menos espacio en disco que una no normalizada. Hay menos repeticin de datos, lo
que tiene como consecuencia un mucho menor uso de espacio en disco.

El proceso de normalizacin tiene un nombre y una serie de reglas para cada fase. Esto puede parecer
un poco confuso al principio, pero poco a poco se va entendiendo el proceso, as como las razones para
hacerlo de esta manera.

Grados de normalizacin

Existen bsicamente tres niveles de normalizacin: Primera Forma Normal (1NF), Segunda Forma
Normal (2NF) y Tercera Forma Normal (3NF). Cada una de estas formas tiene sus propias reglas.
Cuando una base de datos se conforma a un nivel, se considera normalizada a esa forma de
normalizacin. No siempre es una buena idea tener una base de datos conformada en el nivel ms alto
de normalizacin, puede llevar a un nivel de complejidad que pudiera ser evitado si estuviera en un nivel
ms bajo de normalizacin.

En la tabla siguiente se describe brevemente en que consiste cada una de las reglas, y posteriormente
se explican con ms detalle.

Regla Descripcin
Primera Forma Normal (1FN) Incluye la eliminacin de todos los grupos repetidos.
Segunda Forma Normal (2FN) Asegura que todas las columnas que no son llave sean
completamente dependientes de la llave primaria (PK).
Tercera Forma Normal (3FN) Elimina cualquier dependencia transitiva. Una dependencia
transitiva es aquella en la cual las columnas que no son llave son
dependientes de otras columnas que tampoco son llave.

Primera Forma Normal

La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y
colocarse en tablas separadas.

Poner la base de datos en la Primera Forma Normal resuelve el problema de los encabezados de
columna mltiples. Muy a menudo, los diseadores de bases de datos inexpertos harn algo similar a
la tabla no normalizada. Una y otra vez, crearn columnas que representen los mismos datos. La
normalizacin ayuda a clarificar la base de datos y a organizarla en partes ms pequeas y ms
fciles de entender. En lugar de tener que entender una tabla gigantesca y monoltica que tiene
muchos diferentes aspectos, slo tenemos que entender los objetos pequeos y ms tangibles, as
como las relaciones que guardan con otros objetos tambin pequeos.

Segunda Forma Normal

La regla de la Segunda Forma Normal establece que todas las dependencias parciales se deben
eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un trmino que describe a
aquellos datos que no dependen de la llave primaria de la tabla para identificarlos.

Una vez alcanzado el nivel de la Segunda Forma Normal, se controlan la mayora de los problemas de
lgica. Podemos insertar un registro sin un exceso de datos en la mayora de las tablas.

Tercera Forma Normal

Una tabla est normalizada en esta forma si todas las columnas que no son llave son funcionalmente
dependientes por completo de la llave primaria y no hay dependencias transitivas. Comentamos
anteriormente que una dependencia transitiva es aquella en la cual existen columnas que no son llave
que dependen de otras columnas que tampoco son llave.

Cuando las tablas estn en la Tercera Forma Normal se previenen errores de lgica cuando se insertan
o borran registros. Cada columna en una tabla est identificada de manera nica por la llave primaria,
y no deben haber datos repetidos. Esto provee un esquema limpio y elegante, que es fcil de trabajar y
expandir.

Un dato sin normalizar no cumple con ninguna regla de normalizacin. Para explicar con un ejemplo en
que consiste cada una de las reglas, vamos a considerar los datos de la siguiente tabla.

ID_ORDEN FECHA ID_CLIENTE NOM_CLIENTE ESTADO NUM_ITEM DESC_ITEM CANT PRECIO
2301 2/23/03 101 MARTI CA 3786 RED 3 35
2301 2/23/03 101 MARTI CA 4011 RAQUETA 6 65
2301 2/23/03 101 MARTI CA 9132 PAQ-3 8 4.75
2302 2/25/03 107 HERMAN WI 5794 PAQ-6 4 5.0
2303 2/27/03 110 WE-SPORTS MI 4011 RAQUETA 2 65
2303 2/27/03 110 WE-SPORTS MI 3141 FUNDA 2 10

Al examinar estos registros, podemos darnos cuenta que contienen un grupo repetido para NUM_ITEM,
DESC_ITEM, CANT y PRECIO. La 1FN prohibe los grupos repetidos, por lo tanto tenemos que
convertir a la primera forma normal. Los pasos a seguir son:

Tenemos que eliminar los grupos repetidos.
Tenemos que crear una nueva tabla con la PK de la tabla base y el grupo repetido.

Los registros quedan ahora conformados en dos tablas que llamaemos ORDENES y
ARTICULOS_ORDENES

- ORDENES

ID_ORDEN FECHA ID_CLIENTE NOM_CLIENTE ESTADO
2301 2/23/03 101 MARTI CA
2302 2/25/03 107 HERMAN WI
2303 2/27/03 110 WE-SPORTS MI

- ARTICULOS_ORDENES

ID_ORDEN NUM_ITEM DESC_ITEM CANT PRECIO
2301 3786 RED 3 35
2301 4011 RAQUETA 6 65
2301 9132 PAQ-3 8 4.75
2302 5794 PAQ-6 4 5.0
2303 4011 RAQUETA 2 65
2303 3141 FUNDA 2 10

Ahora procederemos a aplicar la segunda formal normal, es decir, tenemos que eliminar cualquier
columna no llave que no dependa de la llave primaria de la tabla. Los pasos a seguir son:

Determinar cules columnas que no son llave no dependen de la llave primaria de la tabla.
Eliminar esas columnas de la tabla base.
Crear una segunda tabla con esas columnas y la(s) columna(s) de la PK de la cual dependen.

La tabla ORDENES est en 2FN. Cualquier valor nico de ID_ORDEN determina un slo valor para
cada columna. Por lo tanto, todas las columnas son dependientes de la llave primaria ID_ORDEN.

Por su parte, la tabla ARTICULOS_ORDENES no se encuentra en 2FN ya que las columnas PRECIO y
DESC_ITEM son dependientes de NUM_ITEM, pero no son dependientes de ID_ORDEN. Lo que
haremos a continuacin es eliminar estas columnas de la tabla ARTICULOS_ORDENES y crear una
tabla ARTICULOS con dichas columnas y la llave primaria de la que dependen.

Las tablas quedan ahora de la siguiente manera.

- ARTICULOS_ORDENES

ID_ORDEN NUM_ITEM CANT
2301 3786 3
2301 4011 6
2301 9132 8
2302 5794 4
2303 4011 2
2303 3141 2

- ARTICULOS

NUM_ITEM DESC_ITEM PRECIO
3786 RED 35
4011 RAQUETA 65
9132 PAQ-3 4.75
5794 PAQ-6 5.0
4011 RAQUETA 65
3141 FUNDA 10

La tercera forma normal nos dice que tenemos que eliminar cualquier columna no llave que sea
dependiente de otra columna no llave. Los pasos a seguir son:

Determinar las columnas que son dependientes de otra columna no llave.
Crear una segunda tabla con esas columnas y con la columna no llave de la cual son
dependientes.

Al observar las tablas que hemos creado, nos damos cuenta que tanto la tabla ARTICULOS, como la
tabla ARTICULOS_ORDENES se encuentran en 3FN. Sin embargo la tabla ORDENES no lo est, ya
que NOM_CLIENTE y ESTADO son dependientes de ID_CLIENTE, y esta columna no es la llave
primaria.

Para normalizar esta tabla, moveremos las columnas no llave y la columna llave de la cual dependen
dentro de una nueva tabla CLIENTES. Las nuevas tablas CLIENTES y ORDENES se muestran a
continuacin.

- ORDENES

ID_ORDEN FECHA ID_CLIENTE
2301 2/23/03 101
2302 2/25/03 107
2303 2/27/03 110

- CLIENTES

ID_CLIENTE NOM_CLIENTE ESTADO
101 MARTI CA
107 HERMAN WI
110 WE-SPORTS MI

Qu tan lejos debe llevar la normalizacin?

La siguiente decisin es qu tan lejos debe llevar la normalizacin? La normalizacin es una ciencia
subjetiva. Determinar las necesidades de simplificacin depende de nosotros. Si nuestra base de datos
va a proveer informacin a un solo usuario para un propsito simple y existen pocas posibilidades de
expansin, normalizar los datos hasta la 3FN quiz sea algo exagerado. Las reglas de normalizacin
existen como guas para crear tablas que sean fciles de manejar, as como flexibles y eficientes. A
veces puede ocurrir que normalizar los datos hasta el nivel ms alto no tenga sentido.
Normalizacin de base de datos | Fundamentos de Bases de Datos http://quintonivel2010.wordpress.com/2010/05/28/normalizacion-de-ba...
1 de 6 19/06/2013 10:32 p.m.

Se estn dividiendo tablas slo para seguir las reglas o estas divisiones son en verdad prcticas?. stas
son el tipo de cosas que nosotros como diseadores de la base de datos, necesitamos decidir, y la experiencia
y el sentido comn nos pueden auxiliar para tomar la decisin correcta. La normalizacin no es una ciencia
exacta, ms bien subjetiva.

Existen seis niveles ms de normalizacin que no se han discutido aqu. Ellos son Forma Normal Boyce- Codd,
Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o Forma Normal de Proyeccin-Unin, Forma Normal
de Proyeccin-Unin Fuerte, Forma Normal de Proyeccin-Unin Extra Fuerte y Forma Normal de Clave de
Dominio. Estas formas de normalizacin pueden llevar las cosas ms all de lo
que necesitamos. stas existen para hacer una base de datos realmente relacional. Tienen que ver
principalmente con dependencias mltiples y claves relacionales.

En resumen

La normalizacin es una tcnica que se utiliza para crear relaciones lgicas apropiadas entre tablas de una
base de datos. Ayuda a prevenir errores lgicos en la manipulacin de datos. La normalizacin facilita tambin
agregar nuevas columnas sin romper el esquema actual ni las relaciones.

Existen varios niveles de normalizacin: Primera Forma Normal, Segunda Forma Normal, Tercera Forma Normal,
Forma Normal Boyce-Codd, Cuarta Forma Normal, Quinta Forma Normal o Forma Normal de Proyeccin-Unin,
Forma Normal de Proyeccin-Unin Fuerte, Forma Normal de Proyeccin-Unin Extra Fuerte y Forma Normal de
Clave de Dominio. Cada nuevo nivel o forma nos acerca ms a hacer una
base de datos verdaderamente relacional.

Se discutieron las primeras tres formas. stas proveen suficiente nivel de normalizacin para cumplir con las
necesidades de la mayora de las bases de datos. Normalizar demasiado puede conducir a tener una base de
datos ineficiente y hacer a su esquema demasiado complejo para trabajar. Un balance apropiado de
sentido comn y prctico puede ayudarnos a decidir cundo normalizar.

Fundamentos de Bases de Datos

Fundamentos BD

Normalizacin de base de datos

About these ads

i
2 Votes

Qu es normalizacin?

La normalizacin nos ayuda a clasicar objetos, relaciones, diferentes formas de relacin que existan,
basndose en cierta caracterstica de cada uno.
2 de 6 19/06/2013 10:32 p.m.

Dependiendo de ciertas reglas que sean identicadas se puede poner en una categora u otra.

Cules son los benecios de la normalizacin?

Nos ayudan a eliminar redundancias e inconsistencias de dependencia en el diseo de la tabla.

Formalizacin cero

Es cuando ninguna de las reglas formales ha sido aplicada.


Estas son las caractersticas que deben cumplirse para estar en primera forma normal.

Las celdas de las tablas deben tener valore simples y no se puede tener grupos ni arreglos que se
repitan como valores, un valor por celda
La tabla contiene una clave primaria.
No existen columnas vacas.
La clave primaria no tiene atributos nulos.


Estas son las caractersticas que deben cumplirse para estar en segunda forma normal.
3 de 6 19/06/2013 10:32 p.m.

Una relacin debe estar en 1FN.
Relacionar tablas mediante claves forneas.
Los atributos que no forman parte de ninguna clave dependen de forma completa de la clave
principal. Es decir que no existen dependencias parciales.


Estas son las caractersticas que deben cumplirse para estar en tercera forma normal.

La tabla se encuentra en 2FN
Se eliminan campos que no dependan de la clave.
No hay dependencias transitivas entre los atributos, queremos decir con dependencias transitivas
cuando existe ms de una forma de llegar a referencias a un atributo de una relacin.


Estas son las caractersticas que deben cumplirse para estar en cuarta forma normal

Se encuentra con respecto a un conjunto D de dependencias funcionales y de valores mltiples s,
para todas las dependencias de valores mltiples en D de la forma X->->Y, donde X<=R y Y<=R, se
cumple por lo menos una de estas condiciones:

* X->->Y es una dependencia de valores mltiples trivial.
* X es una superllave del esquema R.


Estas son las caractersticas que deben cumplirse para estar en quinta forma normal.

La tabla debe estar en 4FN
No existen relaciones de dependencias no triviales que no siguen los criterios de las claves.
Una tabla que se encuentra en la 4FN se dice que est en la 5FN si cada relacin de dependencia se
encuentra denida por las claves candidatas.

Reglas de Codd

Codd se dio cuenta que haban bases de datos en el mercado que decan ser relacionales, pero solo
guardaban informacin en tablas, sin estar estas tablas literalmente normalizadas; por lo tanto dio 12
reglas que se deban establecer, pero en la vida real es difcil poner en prctica.
4 de 6 19/06/2013 10:32 p.m.

Regla N1 La Regla de la informacin

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

Cualquier dato que no est en una tabla no existe del todo. Cualquier tipo de informacin debe estar
siempre adentro de una tabla en una base de datos. Las tablas que contienen tal informacin
constituyen el Diccionario de Datos.

Regla N2 La regla del acceso garantizado

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

Esto signica que dado un nombre de tabla, la clave primaria, y el nombre de la columna que se
necesita, deber encontrarse uno y solamente un valor. Por esta razn es importante las claves
primarias para todas las tablas.

Regla N3 Tratamiento sistemtico de los valores nulos

La informacin inaplicable o faltante puede ser representada a travs de valores nulos

Un Sistema Gestor de Bases de Datos Relacionales debe soportar el ingreso de valores nulos en el lugar
de columnas cuyos valores sean desconocidos.

Regla N4 La regla de la descripcin de la base de datos

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

Toda la informacin debe ser almacenada nicamente: En tablas. Estas tablas deben ser accesibles
igual que todas las tablas, a travs de sentencias de SQL.

Regla N5 La regla del sub-lenguaje Integral

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

Tiene que existir al menos un nico lenguaje con una sintaxis bien denida, que ser usado para
5 de 6 19/06/2013 10:32 p.m.

administrar la base de datos

Regla N6 La regla de la actualizacin de vistas

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

La mayora de los Sistemas Gestor de Bases de Datos Relacionales permiten actualizar vistas simples
en algunos momentos, pero no se puede ver las vistas complejas.

Regla N7 La regla de insertar y actualizar

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

Quiere decir que para leer, escribir, eliminar y agregar registros deben estar disponibles y operables
siempre, independientemente del tipo de relaciones y restricciones que exista entre las tablas.

Regla N8 La regla de independencia fsica

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

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

Regla N9 La regla de independencia lgica

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

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

Regla N10 La regla de la independencia de la integridad
Un ejemplo simple de normalizacin de bases de datos relacionales (has... http://cnx.org/content/m18350/latest/
1 de 5 18/06/2013 08:08 p.m.

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

Existen algunas reglas de integridad que son:

1. Los componentes de una clave primaria no pueden tener valores en blanco o nulos.
2. Para cada valor de clave fornea deber existir un valor de clave primaria concordante. La unin de
estas reglas garantizan que haya integridad referencial.

Regla N11 La regla de la distribucin

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

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

Regla N12 Regla de la no-subversin

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

Ciertos productos unicamente hacen una interfaz relacional para sus bases de datos No relacionales,
por lo que abre la subversin de las restricciones de integridad. Pero no es permitido.

2 de 5 18/06/2013 08:08 p.m.

Un ejemplo simple de normalizacin de
bases de datos relacionales (hasta 3FN)

Module by: Miguel-Angel Sicilia.

Summary: Se describe un ejemplo sencillo (de una sola tabla) de aplicacin de la normalizacin de bases de
datos relacionales.

El proceso de normalizacin de bases de datos relacionales

La normalizacin de bases de datos relacionales toma un esquema relacional y le aplic a un conjunto de
tcnicas para producir un nuevo esquema que representa la misma informacin pero cont iene menos
redundancias y evita posibles anomalas en las inserciones, actualizaciones y borrado s.

Breve recordatorio del modelo (formal) relacional

El modelo relacional de bases de datos se basa en un modelo formal especificado de acuerdo a la teora
de conjuntos. Una base de datos relacional puede considerarse como un conjunto de rel aciones o
tablas de la forma R(A1, ..., An), donde R es el nombre de la relacin, que se define por una serie
de atributos Ai.

Sobre las tablas relacionales se pueden definir diferentes restricciones. La integridad de entidad es una
restriccin que nos indica que cada entidad representada por una tupla tiene que ser diferente de las
dems en su relacin, es decir, debe haber algunos atributos cuyos valores identifiqu en unvocamente
las tuplas. La integridad referencial indica que una clave ajena solo debe contener valores que o bien
sean nulos, o bien existan en la relacin referenciada por la clave ajena.

3 de 5 18/06/2013 08:08 p.m.

El proceso de normalizacin

El proceso de normalizacin consiste en comprobar en secuencia si el esquema original est en 1FN,
2FN y 3FN, analizando las dependencias funcionales en cada paso.

Un ejemplo completo

Tenemos una empresa pblica donde los puestos de trabajo estn regulados por el Estado, de modo
que las condiciones salariales estn determinadas por el puesto. Se ha creado el sigu iente esquema
relacional

EMPLEADOS(nss, nombre, puesto, salario, emails) con nss como clave primaria.
4 de 5 18/06/2013 08:08 p.m.

nss nombre Puesto salario emails
111 Juan Prez Jefe de rea 3000 juanp@ecn.es; jefe2@ecn.es
222 Jos Snchez Administrativo 1500 jsanchez@ecn.es
333 Ana Daz Administrativo 1500 adiaz@ecn.es; ana32@gmail.com
... ... ... ... ...
T ABLE 1

Primera forma normal (1FN)

Una tabla est en 1FN si sus atributos contienen valores atmicos. En el ejemplo, podemos ver que el
atributo emails puede contener ms de un valor, por lo que viola 1FN.

En general, tenemos una relacin R con clave primaria K. Si un atributo M viola la condicin de 1FN,
tenemos dos opciones.

Solucin 1: duplicar los registros con valores repetidos
En general, esta solucin pasa por sustituir R por una nueva relacin modificada R', en la cual:
El atributo M que violaba 1FN se elimina.

Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo que
si R'[M'] es uno de los valores que tenamos en R[M], entonces R'[K] = R[K]. En otras
palabras, para una tupla con n valores duplicados en M, en la nueva relacin habr n
tuplas, que slo varan en que cada una de ellas guarda uno de los valores que haba en
M.

La clave primaria de R' es (K, M'), dado que podr haber valores de K repetidos, para
los valores multivaluados en M.

Siguiendo el ejemplo, tendramos el siguiente esquema para la nueva tabla EMPLEADOS'(a)
con clave primaria (nss, email):

nss Nombre puesto salario email
111 Juan Prez Jefe de rea 3000 juanp@ecn.es
111 Juan Prez Jefe de rea 3000 jefe2@ecn.es
222 Jos Snchez Administrativo 1500 jsanchez@ecn.es
333 Ana Daz Administrativo 1500 adiaz@ecn.es
333 Ana Daz Administrativo 1500 ana32@gmail.com
... ... ... ... ...
T ABLE 2

Solucin 2: separar el atributo que viola 1FN en una tabla

En general, esta solucin pasa por:

sustituir R por una nueva relacin modificada R' que no contiene el atributo M.

Crear una nueva relacin N(K, M'), es decir, una relacin con una clave ajena K referenciando
5 de 5 18/06/2013 08:08 p.m.

R', junto al atributo M', que es la variante mono-valuada del atributo M.
La nueva relacin N tiene como clave (K, M').
Siguiendo el ejemplo, tendramos el siguiente esquema para la nueva tabla EMPLEADOS'(b)

nss nombre puesto salario
111 Juan Prez Jefe de rea 3000
222 Jos Snchez Administrativo 1500
333 Ana Daz Administrativo 1500
... ... ... ...
T ABLE 3

Y adems tendramos una nueva tabla EMAILS con clave primaria (nss, email):

nss email
111 juanp@ecn.es
111 jefe2@ecn.es
222 jsanchez@ecn.es
333 adiaz@ecn.es
333 ana32@gmail.com
... ...
T ABLE 4


Un esquema est en 2FN si:
Est en 1FN.
Todos sus atributos que no son de la clave principal tienen dependencia funcional com pleta respecto de
todas las claves existentes en el esquema. En otras palabras, para determinar cada atributo no clave se
necesita la clave primaria completa, no vale con una subclave.

La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o m s atributos. Si
una relacin est en 1FN y su clave primaria es simple (tiene un solo atributo), ento nces tambin est
en 2FN. Por tanto, de las soluciones anteriores, la tabla EMPLEADOS'(b) est en 1FN (y la tabla
EMAILS no tiene atributos no clave), por lo que el esquema est en 2FN. Sin embargo, tenemos que
examinar las dependencias funcionales de los atributos no clave de EMPLEADOS'(a). Las
dependencias funcionales que tenemos son las siguientes:

nss->nombre, salario, email
puesto->salario
Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas, por
lo que la relacin no est en 2FN.

En general, tendremos que observar los atributos no clave que dependan de parte de la clave.
Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de atributos con
6 de 5 18/06/2013 08:08 p.m.

dependencia incompleta M:
Eliminar de R el atributo M.
Crear una nueva relacin N con el atributo M y la parte de la clave primaria K de la que depende, que
llamaremos K'.

La clave primaria de la nueva relacin ser K'.

Siguiendo el ejemplo anterior, crearamos una nueva relacin con los atributos que ti enen
dependencia incompleta:

nss nombre puesto salario
111 Juan Prez Jefe de rea 3000
222 Jos Snchez Administrativo 1500
333 Ana Daz Administrativo 1500
... ... ... ...
T ABLE 5

Y al eliminar de la tabla original estos atributos nos quedara:

nss email
111 juanp@ecn.es
111 jefe2@ecn.es
222 jsanchez@ecn.es
333 adiaz@ecn.es
333 ana32@gmail.com
... ...
T ABLE 6

Como vemos, la solucin a la que llegamos es la misma que en la otra opcin de soluci n para el
problema de 1FN.

Tercera forma normal (3FN)

Una relacin est en tercera forma normal si, y slo si:

est en 2FN

y, adems, cada atributo que no est incluido en la clave primaria no depende transit ivamente de la
clave primaria.

Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales entre
atributos que no estn en la clave.

En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuen cias de
dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La solucin a este
tipo de dependencias est en separar en una tabla adicional N el/los atributos B, y poner como clave
primaria de N el atributo que define la transitividad A.

Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:
Geynen Rossler Montenegro Cochas Pgina 1

n
s
s
-
>
p
u
e
s
t
o

p
u
e
s
t
o
-
>
s
a
l
a
r

i
o
Por lo tanto la descomposicin sera la siguiente:

nss nombre puesto
111 Juan Prez Jefe de rea
222 Jos Snchez Administrativo
333 Ana Daz Administrativo
... ... ...
T

A
B
L
E

7

En la nueva tabla PUESTOS, la clave sera el puesto, que tambin queda
como clave ajena referenciando la tabla EMPLEADOS. El resto de las
tablas quedan como estaban.


Ejemplo 2

Normalizacin de Datos

Cuando trabajamos con una base de datos relacional, los esquemas de las distintas
relaciones que la constituyen nos indican que cada dato tiene su lugar. Pero, qu ocurre si
se modifican estas estructuras lgicas? . Muchas veces e s tan obvio que un dato debe de
almacenarse en una de las relaciones y no en otra que se nos escapa la respuesta a porqu es
as.

Concepto:
La teora de la normalizacin es en esencia una expresin formal de ideas sencillas
con una aplicacin muy prctic a en el rea del diseo de bases de datos, ya que conducen a
una correcta eleccin del esquema de la base de datos.

Es la simplificacin de los datos dentro de los campos de registro, este proceso lo
considero importante ya que nos ayuda a dejar datos en estado demasiado simple de una
forma entendible precisa, predecible y manejable. La normalizacin permite estructurar datos
de forma precisa para representar las relaci ones necesarias entre los campos de un registro,
tambin permite la recuperacin de dato s sencillos que se pierden al realizar consultas y
reportes.

Universo de las relaciones (normalizadas y no normalizadas)
Relaciones 1FN Normalizadas Codd


Relaciones BCFN Boyce Codd

Relaciones 4FN Fagin

Relaciones 5FN Fagin

Visin de la Teora de Normalizacin

Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos.

Evitar problemas de actualizacin de los datos en las tablas.
Proteger la integridad de los datos.

Hablaremos de las 3 primeras formas de normalizacin bsic a para el diseo de una
base de datos.

PRIMERA FORMA NORMAL: Una relacin est en primera forma normal (1FN) si y
slo si todos los dominios simples subyacentes contienen s lo valores atmicos.

La regla de la Primera Forma Normal establece que las columnas repetidas deben
eliminarse y colocarse en tablas separadas.
Poner la base de datos en la Primera Forma Normal resuelve el problema de los
encabezados de columna mltiples .

SEGUNDA FORMA NORMA: Una relacin est en segunda forma normal (2FN) si y slo
si est en 1FN y todos los atributos no clave dependen por completo de cualquier clave
candidata.

La regla de la Segunda Forma Normal establece que todas las dependencias p arciales
se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un
trmino que describe a aquellos datos que no dependen de la llave primaria de la tabla para
identificarlos.

TERCERA FORMA NORMA : Una relacin est en tercera forma normal (3FN) si y slo
si est en 2FN y todos los atributos no clave dependen de manera no transitiva de cualquier
clave candidata.

Una tabla est normalizada en esta forma si todas las columnas que no son llave son
funcionalmente dependientes por c ompleto de la llave primaria y no hay dependencias
transitivas. Una dependencia transitiva es aquella en la cual existen columnas que no son
llave que dependen de otras columnas que tampoco son llave.

EJEMPLO:
A travs del siguiente ejercicio se intenta afirmar los conocimientos de normalizacin
con un ejemplo simplificado de una base de datos para una pequea biblioteca.

CodLibro Titulo Autor Editorial NombreLector FechaDev
1001 Variable compleja Murray Spiegel McGraw Hill Prez Gmez, Juan 15/04/2005
1004 Visual Basic 5 E. Petroustsos Anaya Ros Tern, Ana 17/04/2005
1005 Estadstica Murray Spiegel McGraw Hill Roca, Ren 16/04/2005

1006

Oracle University
Nancy Greenberg y
Priya Nathan

Oracle Corp.

Garca Roque, Luis

20/04/2005
1007 Clipper 5.01 Ramalho McGraw Hill Prez Gmez, Juan 18/04/2005

Esta tabla no cumple el requisito de la Primera Forma Normal (1NF) de slo
tener campos atmicos, pues el nombre del lector es un campo que puede (y conviene)
descomponerse en apellido pat erno, apellido materno y nombres. Tal como se muestra en la
siguiente tabla.

1NF
CodLibro Titulo Autor Editorial Paterno Materno Nombres FechaDev
1001 Variable compleja Murray Spiegel McGraw Hill Prez Gmez Juan 15/04/2005
1004 Visual Basic 5 E. Petroustsos Anaya Ros Tern Ana 17/04/2005
1005 Estadstica Murray Spiegel McGraw Hill Roca

Ren 16/04/2005
1006 Oracle University Nancy Greenberg Oracle Corp. Garca Roque Luis 20/04/2005

1006 Oracle University Priya Nathan Oracle Corp. Garca Roque Luis 20/04/2005
1007 Clipper 5.01 Ramalho McGraw Hill Prez Gmez Juan 18/04/2005

Como se puede ver, hay cierta redundancia caracterstica de 1NF.

La Segunda Forma Normal (2NF) pide que no existan dependencias parciales o dicho
de otra manera, todos los a tributos no clave deben depender por completo de la clave
primaria.

Actualmente en nuestra tabla tenemos varias dependencias parciales si
consideramos como atributo clave el cdigo del libro.

Por ejemplo, el ttulo es completamente id entificado por el cdigo del libro, pero el
nombre del lector en realidad no tiene dependencia de este cdigo, por tanto estos
datos deben ser trasladados a otra tabla.

2NF
CodLibro Titulo Autor Editorial
1001 Variable compleja Murray Spiegel McGraw Hill
1004 Visual Basic 5 E. Petroustsos Anaya
1005 Estadstica Murray Spiegel McGraw Hill
1006 Oracle University Nancy Greenberg Oracle Corp.
1006 Oracle University Priya Nathan Oracle Corp.
1007 Clipper 5.01 Ramalho McGraw Hill

La nueva tabla slo contendr datos del lector.

CodLector Paterno Materno Nombres
501 Prez Gmez Juan
502 Ros Tern Ana
503 Roca

Ren
504 Garca Roque Luis
Hemos creado una tabla para contener los datos del lector y tambin tuvimos
que crear la columna CodLector para identificar unvocamente a cada uno. Sin
embargo, esta nueva disposicin de la base de datos necesita que exista otra tabla para
mantener la informacin de qu libros estn prestados a qu lectores. Esta tabla se muestr a a
continuacin:

CodLibro CodLector FechaDev
1001 501 15/04/2005
1004 502 17/04/2005
1005 503 16/04/2005
1006 504 20/04/2005
1007 501 18/04/2005

Para la Tercera Forma Normal (3NF) la relacin debe estar en 2NF y adems los
atributos no clave deben ser mutuamente independientes y dependientes por completo de la
clave primaria. Tambin recordemos que dijimos que esto significa que las columnas

en la tabla deben contener solamente informacin sobre la entidad definida por la clave
primaria y, por tanto, las columnas en la tabla deben contener datos acerca de una sola cosa.
En nuestro ejemplo en 2NF, la primera tabla conserva informacin acerca del libro,
los autores y editoriales, por lo que debemos crear nuevas tablas para satisfacer los requisitos
de 3NF.

3NF
CodLibro Titulo
1001 Variable compleja
1004 Visual Basic 5
1005 Estadstica
1006 Oracle University
1007 Clipper 5.01

CodAutor Autor
801 Murray Spiegel
802 E. Petroustsos
803 Nancy Greenberg
804 Priya Nathan
806 Ramalho

CodEditorial Editorial
901 McGraw Hill
902 Anaya
903 Oracle Corp.

Aunque hemos creado nuevas tablas para que cada una tenga slo informacin acerca
de una entidad, tambin hemos perdido la informacin acerca de qu autor ha escrito qu
libro y las editoriales correspondientes, por lo que debemos crear otras tablas que relacionen
cada libro con sus autores y editoriales.

CodLibro codAutor
1001 801
1004 802
1005 801
1006 803
1006 804
1007 806

CodLibro codEditorial
1001 901
1004 902
1005 901
1006 903

1007 901

Y el resto de las tablas no necesitan modificacin.

CodLector Paterno Materno Nombres
501 Prez Gmez Juan
502 Ros Tern Ana
503 Roca

Ren
504 Garca Roque Luis

CodLibro CodLector FechaDev
1001 501 15/04/2005
1004 502 17/04/2005
1005 503 16/04/2005
1006 504 20/04/2005
1007 501 18/04/2005
Ing. Orlando Bettin j. Reestructurado y Modificado por BJ System

BIBLIOGRAFIA

Libros en pantalla de SQL Server 2005.

Geynen Rossler Montenegro Cochas Pgina
10

Ejemplo de normalizacin de una factura de venta

En la siguiente factura de compra venta, usted debe analizar toda la informacin disponible y debe crear
el diccionario de datos.

No. 500456

Fecha: 05/04/2011
11

DESARROLLO

1. Creamos el Diccionario de Datos, para ello hacemos una lista de todos los campos presentes
en el documento y elegimos para ellos una llave primaria.

Clave Principal

2. Aplicamos Primera Forma Normal 1FN: Dividimos la lista de datos del diccionario de datos en
dos grupos: El grupo # 1 estar formado por aquellos datos que no se repiten y en grupo # 2
por aquellos datos repetitivos

No. 500456

Fecha: 05/04/2011

Datos no Repetitivos

Dato
s

R
E
P
E
T
12

Al aplicar primera forma normal debemos adicionar en el grupo repetitivo el campo que se
selecciono como llave primaria al momento de elaborar el diccionario de datos para que sirva
como llave secundaria y permita establecer una relacin de cardinalidad 1-N desde el grupo#1(no
repetitivo) al grupo#2(grupo repetitivo) y seleccionamos una llave primaria al grupo#2. Aplicando
lo anteriormente expuesto nos queda el siguiente modelo relacional en primera forma normal
(1FN).
Grupo repetitivo

Llave secundaria

Relacin de cardinalidad 1-N

3. Aplicamos Segunda Forma Normal 2FN: Al aplicar segunda forma normal slo se analiza el
grupo repetitivo (grupo #2) y se determina que datos dependen de forma nica del la llave
primaria, Codigo_Producto en nuestro caso, estos datos junto con la llave primaria formarn
un nuevo grupo (grupo #3) cuya llave primaria ser la misma que tena el grupo
#2(Codigo_Producto) y este mismo dato se conserva en el grupo #2 pero para este grupo pasa
a ser llave secundaria.

Este grupo dependen de forma nica del la llave primaria y son
inherentes al producto.

Este grupo No dependen de forma nica del la llave primaria y son
inherentes a la venta No al producto

Al aplicar segunda forma normal nos que el siguiente modelo relacional

13

4. Aplicamos Tercera Forma Norma 3FN. Al aplicar tercera forma normal se analiza slo al grupo
no repetitivo, grupo # 1 en nuestro caso, y se separan de l aquellos campos que no dependan
directamente de la llave primaria. Para el nuevo grupo se selecciona una llave primaria y dicho
campo se conserva en el primer grupo como llave secundaria. As nos queda el siguiente
modelo.

5. D OTRAS OBSERVACIONES. Se ha seguido el proceso de normalizacin haciendo un ARD
partiendo de un diccionario de datos formado a partir del esquema de una factura, es decir
nos hemos basado en uno de los mltiples documentos que puede generar una empresa para
formar la lista de datos, luego se ha procedido a aplicar 1FN,2FN y3FN. No obstante haber
seguido el proceso de normalizacin hasta 3FN en posible que aun nuestra base de datos
necesite algunos ajustes. En tal sentido procederemos a analizar cada una de las tablas y a
hacer los ajustes que sean necesarios.

Cambiaremos los nombres de las tablas.
El cambio en los nombres de las tablas se hace para que dichos nombres guarden
relacin con los datos que almacenan cada tabla. Los cambios propuestos se
muestran a continuacin.

Nota: Ahora asignar Nombres a las tablas

NOMBRE DEL GRUPO DESCRIPCION DE LA INFORMACION QUE CONTIENE CADA GRUPO NUEVO NOMBRE PARA LA TABLA
REPRESENTATIVA DE CADA GRUPO
Grupo # 1 Informacin de la factura TBLFactura
Grupo # 2 Detalles de la venta realizada, es la lista de productos
vendido y relacionados en una factura particular.
TBLDetalleFactura
Grupo # 3 Datos de los productos. TBLProductos
Grupo # 4 Datos del cliente TBLClientes

Adicionamos datos en aquellas tablas que lo requieran.

- La tabla que guarda los datos de los productos no
registra el valor actual de los productos por lo que se le
adicionar un nuevo campo llamado VALOR_ACTUAL. Es
importante no confundir el campo VALOR_ACTUAl de la
tabla de productos con el campo VALOR_UNITARIO de la
tabla de detalles de la factura el VALOR_ACTUAL como su
nombre lo indica es el valor presente a la fecha de un
producto en particular y el VALOR_UNITARIO es el precio al
cual fue vendido un producto en particular

Despus de haber hecho los ajustes necesarios (cabio de nombres a las
tablas y adicin de nuevos datos) hemos llegado al final del proceso de
normalizacin y podemos estar seguros de que tenemos un buen diseo de
nuestra base de datos. El modelo relacional final es el siguiente

Practicas

Gua de Ejercicios
Aplicar las reglas de normalizacin los siguientes ejercicios.

1. Un dato sin normalizar no cumple con ninguna regla de normalizacin. Para explicar con un
ejemplo en qu consiste cada una de las reglas, vamos a considerar los datos de la siguiente tabla.

ordenes (id_orden, fecha, id_cliente, nom_cliente, estado, num_art, nom_art, cant, precio)

Ordenes
Id_orde
n
Fecha Id_client
e
Nom_client
e
Estado Num_ar
t
nom_ar
t
can
t
Preci
o
2301 23/02/1
1
101 Martin Caracas 3786 Red 3 35,00
2301 23/02/1
1
101 Martin Caracas 4011 Raqueta 6 65,00
2301 23/02/1
1
101 Martin Caracas 9132 Paq-3 8 4,75
2302 25/02/1
1
107 Herman Coro 5794 Paq-6 4 5,00
2303 27/02/1
1
110 Pedro Maraca
y
4011 Raqueta 2 65,00
2303 27/02/1
1
110 Pedro Maraca
y
3141 Funda 2 10,00

solucion
PRIMERA FORMAL NORMAL (1FN)
Al examinar estos registros, podemos darnos cuenta que contienen un grupo repetido para
NUM_ART, NOM_ART, CANT y PRECIO. La 1FN prohbe los grupos repetidos, por lo
tanto tenemos que convertir a la primera forma normal. Los pasos a seguir son:
Tenemos que eliminar los grupos repetidos.
Tenemos que crear una nueva tabla con la PK de la tabla base y el grupo repetido.

Los registros quedan ahora conformados en dos tablas que llamaremos ORDENES y
ARTICULOS_ORDENES

ordenes (id_orden, fecha, id_cliente, nom_cliente, estado)
Articulos_ordenes (id_orden, num_art, nom_art, cant, precio)

Ordenes
Id_orden Fecha Id_cliente Nom_cliente Estado
2301 23/02/11 101 Martin Caracas
2302 25/02/11 107 Herman Coro
2303 27/02/11 110 Pedro Maracay

Articulos_ordenes
Id_orden Num_art nom_art cant Precio
2301 3786 Red 3 35,00
2301 4011 Raqueta 6 65,00
2301 9132 Paq-3 8 4,75
2302 5794 Paq-6 4 5,00
2303 4011 Raqueta 2 65,00
2303 3141 Funda 2 10,00

SEGUNDA FORMAL NORMAL (2FN)

Ahora procederemos a aplicar la segunda formal normal, es decir, tenemos que eliminar
cualquier columna no llave que no dependa de la llave primaria de la tabla. Los pasos a
seguir son:
Determinar cules columnas que no son llave no dependen de la llave primaria de la
tabla.
Crear una segunda tabla con esas columnas y la(s) columna(s) de la PK de la cual
dependen.

La tabla ORDENES est en 2FN. Cualquier valor nico de ID_ORDEN determina un slo
valor para cada columna. Por lo tanto, todas las columnas son dependientes de la llave
primaria ID_ORDEN.

Por su parte, la tabla ARTICULOS_ORDENES no se encuentra en 2FN ya que las
columnas PRECIO y NOM_ART son dependientes de NUM_ART, pero no son
dependientes de ID_ORDEN. Lo que haremos a continuacin es eliminar estas columnas de
la tabla ARTICULOS_ORDENES y crear una tabla ARTICULOS con dichas columnas y
la llave primaria de la que dependen.

Las tablas quedan ahora de la siguiente manera.

Articulos_ordenes (id_orden, num_art, cant)

Articulos_ordenes
Id_orden Num_art cant
2301 3786 3
2301 4011 6
2301 9132 8
2302 5794 4
2303 4011 2
2303 3141 2

Articulos ( num_art, nom_art, precio)

Articulos
Num_art nom_art Precio
3786 Red 35,00
4011 Raqueta 65,00
9132 Paq-3 4,75
5794 Paq-6 5,00
3141 Funda 10,00

TERCERA FORMAL NORMAL (3FN)
La tercera forma normal nos dice que tenemos que eliminar cualquier columna no llave que
sea dependiente de otra columna no llave. Los pasos a seguir son:
Determinar las columnas que son dependientes de otra columna no llave.
Crear una segunda tabla con esas columnas y con la columna no llave de la cual son
dependientes.

Al observar las tablas que hemos creado, nos damos cuenta que tanto la tabla
ARTICULOS, como la tabla ARTICULOS_ORDENES se encuentran en 3FN. Sin

embargo la tabla ORDENES no lo est, ya que NOM_CLIENTE y ESTADO son
dependientes de ID_CLIENTE, y esta columna no es la llave primaria.

Para normalizar esta tabla, moveremos las columnas no llave y la columna llave de la cual
dependen dentro de una nueva tabla CLIENTES. Las nuevas tablas CLIENTES y
ORDENES se muestran a continuacin.

ordenes (id_orden, fecha, id_cliente)

Ordenes
Id_orden Fecha Id_cliente
2301 23/02/11 101
2302 25/02/11 107
2303 27/02/11 110

Clientes (id_cliente, nom_cliente, estado)

Ordenes
Id_cliente Nom_cliente Estado
101 Martin Caracas
107 Herman Coro
110 Pedro Maracay
Por lo tanto la base de datos queda de la siguiente manera:

ordenes (id_orden, fecha, id_cliente)
Clientes (id_cliente, nom_cliente, estado)
Articulos ( num_art, nom_art, precio)
Articulos_ordenes (id_orden, num_art, cant)

Unidad 5

3.1
Bases de Datos Relacionales
Definicin de base de datos relacional
lgebra relacional
lgebra relacional extendida
Vistas

Algebra Relacional
1
Es un conjunto de operadores que se aplican a una o dos relaciones y
producen como resultado otra relacin.
Las operaciones fundamentales del lgebra relacional son:
Seleccin
Proyeccin
Unin
Diferencia
Producto Cartesiano
Join
Join Natural
Adems de las operaciones fundamentales, hay otras operaciones, por
ejemplo: Interseccin de conjuntos, join natural, divisin y asignacin.

IV LGEBRA RELACIONAL

Codd propuso tres lenguajes de especificacin para el modelo
relacional como base terica de cualquier lenguaje que quisiera
cumplir con los requisitos formales del modelo. Estos lenguajes
no pueden ser explotados comercialmente, al menos tal y como
los defini Codd, porque adolecen de falta de operadores:
carecen de operadores aritmticos simples (sumas, restas, etc.),
o de manipulacin de cadenas de caracteres, por poner dos
ejemplos escandalosos. El propsito de estos lenguajes no es el
de definir y manejar bases de datos relaciones, tan slo
constituyen una declaracin de los mnimos requeridos para
cualquier lenguaje de manipulacin de datos que se quiera
etiquetar a s mismo como relacional. En otras palabras,
cualquier lenguaje de manipulacin y definicin de datos en
bases de datos relacionales ha de poseer la potencia suficiente
como para hacer, como mnimo, lo que pueden hacer los
lenguajes de Codd.

El primero de ellos, al menos por el orden en el que se van a
introducir en esta asignatura, es el lgebra relacional. Recibe este
nombre precisamente por su carcter algebraico: incluye un
conjunto de operadores (ocho, concretamente) cuyos operandos
son relaciones y el resultado de la operacin es otra relacin, del
mismo modo que cuando sumamos dos enteros obtenemos otro
nmero entero.

En primer lugar se definirn una serie de conceptos necesarios
para definir los operadores del lgebra relacional y para,
finalmente, trabajar con ellos. A continuacin se describirn, uno
por uno, los ocho operadores propuestos por Codd:

Unin
Seleccin donde
Interseccin

Proyeccin [ ]
Diferencia

Concatenacin Natural

Producto Cartesiano Divisin

61

IV1. Conceptos previos.

Al describir las propiedades de cada operador se van a utilizar una serie de
trminos que debemos definir previamente.

En primer lugar se presentar una adaptacin del concepto de relacin
matemtica en la que se vuelve a hacer uso de la ordenacin de las
componentes de una tupla. El resto, son expresiones o reformulaciones de
conceptos ya presentes en la definicin del modelo.

Los conceptos a definir son:

Relacin
Esquema de relacin

Nombres Cualificados de Atributo

Alias de una relacin

Relacin Nominada

Relacin Derivada

Relaciones Compatibles

Operacin conmutativa

Operacin asociativa

relacin

El AR hace uso del orden de las componentes de las tuplas para definir
operadores y propiedades de los operadores. En realidad, se trata de retomar
la definicin original de la relacin matemtica como el subconjunto de un
producto cartesiano de n dominios, de tal forma que las tuplas resultado de
ese producto cumplan y cumplen que

Las tuplas son listas de valores (conjunto ordenado) tal que el
i-simo valor pertenece al i-simo dominio.

Vamos a combinar la definicin anterior de tupla con la adaptacin que en su
momento introdujimos a la relacin matemtica para adecuarla al objetivo final
que es una base de datos. Utilizaremos al mismo tiempo los nombres de
atributos y el orden de las componentes en una tupla:
El conjunto de nombres de atributos es un conjunto ordenado.
Las tuplas son listas de valores (conjunto ordenado) tal que el
i-simo valor pertenece al i-simo dominio asociado al i-simo
nombre de atributo.

A partir de ahora, los operadores pueden utilizar tanto el nombre simblico de
un atributo como su orden dentro de la tupla.

62
lgebra relacional
63

esquema de relacin

Es la descripcin formal de la relacin con sus atributos y dominios
asociados. En realidad se aplica nicamente a las relaciones nominadas,
aquellas descritas en el esquema lgico relacional.

R( A
1
:D
1
, A
2
:D
2
, ..., A
n
:D
n
)
donde: R es el nombre de la relacin
A
i
es el nombre del atributo
D
i
es el nombre del dominio asociado a A
i

nombres cualificados de atributo

Es, por decirlo as, el nombre completo de un atributo, por ejemplo R.A
i
, el
atributo A
i
de la relacin R. Su uso evita la ambigedad de dos atributos en
dos tablas distintas con el mismo nombre.

En general, nos referimos a los atributos por su nombre sin especificar la
relacin a la que pertenecen. No obstante, es habitual que en distintas
relaciones, y sobre todo en las relaciones derivadas (los resultados de operar
con relaciones nominadas), nos podamos encontrar nombres de atributo
coincidentes en relaciones distintas. La forma de diferenciar unos de otros es
utilizar los nombres cualificados: alumno.nombre, asignatura.nombre.

En definitiva, se pueden utilizar indistintamente, siempre y cuando no se
produzcan ambigedades, las dos formas ya conocidas de referirse a un
atributo:

nombre cualificado: R.A
i

nombre no cualificado: A
i

alias de una relacin

Nombre alternativo para una relacin. Dada una relacin R se define un alias
mediante la declaracin:

definir alias S para R

Entonces la relacin puede referenciarse tanto por R como por S, y los
nombres cualificados de atributos R.A
i
o S.A
i
.

relacin nominada

Es toda relacin definida en el esquema lgico relacional. En otras palabras,
las que constituyen nuestra base de datos.

relacin derivada

Es aquella que se obtiene como resultado de una expresin del lgebra
Relacional.
lgebra relacional
64

Una relacin derivada no tiene nombre ni alias. As pues, los nombres de los
atributos de sta se obtendrn a partir de los nombres cualificados de
atributos de las relaciones operando, y si existe ambigedad se utilizarn los
alias.

Las reglas que rigen en los operadores para la asignacin de nombres a los
atributos de relaciones derivadas se vern con cada uno de ellos.

relaciones compatibles

Dos relaciones son compatibles si el grado de ambas es el mismo y los
dominios asociados a los i-simos atributos de cada una son iguales.

R( A1:D1, A2:D2, ..., An:Dn )
S( B1:E1, B2:E2, ..., Bm:Em )

R y S son compatibles si y slo si:
1) n = m
2) i Di = Ei (1 i n)

Dicho de otra forma, el nmero de atributos ha de ser el mismo en ambas
relaciones y, adems, los dominios han de ser los mismos para atributos de la
misma posicin.

operacin conmutativa

Un operacin es conmutativa
15
si se cumple que
A B = B A

operacin asociativa

Una operacin es asociativa si se cumple que
(A B) C = A (B C)

operadores

Los operadores del lgebra Relacional (bajo el punto de vista de Codd) se
dividen en dos grupos:

de la teora de conjuntos relacionales
UNIN
INTERSECCIN
DIFERENCIA
PRODUCTO CARTESIANO
SELECCIN
PROYECCIN
DIVISIN
CONCATENACIN NATURAL

15
En la descripcin de los operadores, algunos se dice que cumplen la propiedad conmutativa,
refirindonos exclusivamente al conjunto de tuplas de la relacin derivada, y no al conjunto de
atributos de dicha relacin resultado, cuyos nombres cualificados dependen del orden de las
relaciones operando.
lgebra relacional
65

Como el resultado de una expresin en lgebra Relacional es otra relacin,
sta puede participar como operando a su vez, permitiendo la construccin de
expresiones anidadas.

R S = D
1
D
1
O = D
2

R S O = D
2

La nica regla de precedencia entre operadores es la utilizacin de
parntesis, en cualquier caso las expresiones se evalan de izquierda a
derecha de tal forma que el resultado de una operacin es el operando de la
siguiente operacin a su derecha:

R S = D
1
O D
1
= D
2

O ( R S ) = D
2

Otra clasificacin se basa en la propia definicin de los operadores: Son
operadores bsicos (o primitivas) la unin, diferencia, producto cartesiano,
seleccin y proyeccin, y operadores derivados la interseccin, la divisin y
la concatenacin natural ya se definen a partir de la combinacin de varios
operadores bsicos.

Dicho de otra forma, los cinco operadores bsicos definen la potencia
expresiva del lenguaje, con ellos se pueden realizar todas las operaciones
que permite el lgebra relacional, mientras que los tres derivados se pueden
ver como atajos o resmenes de varias operaciones bsicas reunidas en
un nico operador.

IV2. definicin informal de los
operadores

En primer lugar, se pretende dar una visin de cmo operan y que resultado
obtienen los operadores antes mencionados. Posteriormente, se dar la
definicin formal de todos ellos como referencia del lenguaje.

Cuando trabajamos con una base de datos relacional, si de manipulacin de
datos estamos hablando, la recuperacin de informacin desde las tablas es
un proceso habitual y necesario.

En lgebra relacional, si queremos recuperar el contenido completo de una
relacin, por ejemplo todos los alumnos almacenados en mi base de datos,
una vez identificada la tabla de la que extraer los datos, la tabla alumno, la
evaluacin del nombre de la relacin nos devuelve todas sus filas:

Alumno
alumno nombre direccin
234 LUCA c/A, 3
321 JUAN c/C, 33
221 LUISA c/E, 333

select *
from alumno
lgebra relacional
66

Si a un intrprete de AR terico le ordenamos simplemente alumno, el
resultado es la tabla de 3 filas anterior. Por razones de claridad los ejemplos
incluyen la operacin, el esquema de la relacin resultado y las filas
obtenidas, segn se detalla en el grfico siguiente.

esquema de la tabla
resultado de evaluar
dicha operacin

filas
obtenidas en
la operacin
operacin que
se desea
evaluar

Alumno
234 LUCA c/A, 3
321 JUAN c/C, 33
221 LUISA c/E, 333

A partir de ahora, los ejemplos muestran el contenido de las tablas utilizadas y
el resultado de cada uno de los operadores. Tambin se darn las
expresiones correspondientes en SQL como ayuda para la comprensin de
cada operacin.

seleccin

En muchas ocasiones slo nos interesan algunos individuos de una relacin,
aquellos que poseen unas determinadas caractersticas: clientes de la
provincia de Alicante, artculos que cuestan mas de 500 euros.

El operador seleccin (donde condicin) recupera tuplas de una relacin
que cumplen una determinada condicin.

Alumno
577 YNIFER c/C, 33
234 LUCA c/A, 3
321 JUAN c/C, 33
221 LUISA c/E, 333

Alumno donde direccin = c/C, 33


577 YNIFER c/C, 33
321 JUAN c/C, 33

select *
from alumno
where direccin = c/C, 33

proyeccin

Si la seleccin recupera filas, la proyeccin ([columna(s)]) recupera atributos.

Alumno
577 YNIFER c/C, 33
lgebra relacional
67

234 LUCA c/A, 3
321 JUAN c/C, 33
221 LUISA c/E, 333

Alumno [alumno, nombre]

alumno nombre

577 YNIFER
234 LUCA
321 JUAN
221 LUISA

select alumno, nombre
from alumno

La seleccin me permite recuperar aquellos individuos que me interesan y la
proyeccin elimina aquellos datos de los individuos que no necesito. Como ya
se ha dicho, se pueden realizar varias operaciones consecutivas, como se
muestra a continuacin:

Alumno donde direccin = c/C, 33 [alumno, nombre]

alumno nombre

577 YNIFER
321 JUAN

select alumno, nombre
from alumno
where direccin = c/C, 33

La proyeccin podra eliminar la o las columnas definidas como clave
candidata y podra dar lugar a duplicados entre las filas (o ms bien nuestra
percepcin de la relacin nos puede inducir a pensar que se puedan mostrar
filas iguales). Como el resultado de esta operacin es tambin una tabla, sta
est sujeta a las mismas restricciones del modelo que cualquier otra. Se
puede pensar que el AR realiza la proyeccin en dos pasos: la proyeccin
como tal y una eliminacin de duplicados, si es que se producen.

Si proyectramos sobre la columna direccin, la tabla alumno contiene dos
filas con los mismos valores. Sin embargo, el resultado de tal operacin es el
siguiente:

Alumno [direccin]

direccin

c/C, 33
c/A, 3
c/E, 333

select direccin
16

from alumno

16
En realidad, es habitual que los SGBD relacionales y su implementacin de SQL, ante
expresiones como esta devuelvan filas duplicadas. El modificador distinct realiza ese segundo
paso al que hemos hecho referencia en el lgebra relacional. A partir de ahora, aunque no
aparezca en los ejemplos, se entender que todas las rdenes select incluyen este modificador:
select distinct direccin from alumno where direccin = c/C, 33
lgebra relacional
68

Obviamente, esto es aplicable a cualquier operacin que hagamos puesto
que el resultado siempre va a ser una tabla derivada.

unin

La unin de dos relaciones da como resultado otra relacin que contiene las
tuplas de las dos. Como en una relacin no existen tuplas duplicadas (por ser
un conjunto, por estar definida por un producto cartesiano), sera ms exacto
describir la unin de dos relaciones A y B como otra relacin C que contiene
las tuplas de A que no estn en B, las tuplas de B que no estn en A, y las
tuplas que estn en A y B a la vez.

Alumno
234 LUCA c/A, 3
321 JUAN c/C, 33
221 LUISA c/E, 333

Profesor
profesor nombre direccin
522 JOS c/F, 32
778 EVA c/F, 51
221 LUISA c/E, 333

Alumno Profesor
234 LUCA c/A, 3
321 JUAN c/C, 33
221 LUISA c/E, 333
522 JOS c/F, 32
778 EVA c/F, 51

select * from alumno
union
select * from profesor

La unin slo se puede realizar si A y B son compatibles y, evidentemente, es
conmutativa y asociativa (ver las definiciones anteriores)
lgebra relacional
69

interseccin

La interseccin de dos relaciones da como resultado otra relacin que
contiene las tuplas comunes a las dos primeras.

Alumno
234 LUCA c/A, 3
321 JUAN c/C, 33
221 LUISA c/E, 333

Profesor
522 JOS c/F, 32
778 EVA c/F, 51
221 LUISA c/E, 333

Alumno Profesor
221 LUISA c/E, 333

intersect

Al igual que la unin, la interseccin slo se puede realizar si A y B son
compatibles y es conmutativa y asociativa.

diferencia

La diferencia de dos relaciones se define como aquellas tuplas que estn en
la primera pero no en la segunda. Ntese que este operador ya no es
conmutativo, importa el orden de los operandos.

lgebra relacional
70

Alumno
234 LUCA c/A, 3
321 JUAN c/C, 33
221 LUISA c/E, 333

Profesor
522 JOS c/F, 32
778 EVA c/F, 51
221 LUISA c/E, 333

Alumno - Profesor
234 LUCA c/A, 3
321 JUAN c/C, 33

minus

La diferencia slo se puede realizar si A y B son compatibles.

producto cartesiano

Este operador se utiliza para generar todas las posibles combinaciones de las
tuplas de una relacin con todas y cada una de las tuplas de otra relacin; se
obtienen todas las combinaciones posibles de filas entre dos tablas.

Alumno
234 LUCA c/A, 3
321 JUAN c/C, 33
221 LUISA c/E, 333

Profesor
522 JOS c/F, 32
778 EVA c/F, 51
221 LUISA c/E, 333
lgebra relacional
71

cod departamento
LSI LENGUAJES
CCIA CIENCIAS
FI FILOLOGA

Alumno Profesor
alumno nombre direccin profesor nombre direccin
234 LUCA c/A, 3 522 JOS c/F, 32
234 LUCA c/A, 3 778 EVA c/F, 51
234 LUCA c/A, 3 221 LUISA c/E, 333
321 JUAN c/C, 33 522 JOS c/F, 32
321 JUAN c/C, 33 778 EVA c/F, 51
321 JUAN c/C, 33 221 LUISA c/E, 333
221 LUISA c/E, 333 522 JOS c/F, 32
221 LUISA c/E, 333 778 EVA c/F, 51
221 LUISA c/E, 333 221 LUISA c/E, 333

select * from alumno, profesor

concatenacin natural

Este operador se utiliza para combinar informacin de dos tablas que
comparten un atributo comn. En este caso quedar ms claro un ejemplo en
el que la base de datos refleje una relacin entre, por ejemplo, profesores y
departamentos a los que estn adscritos. La relacin entre los dos se
representa por una columna en la tabla profesor que indica el cdigo de
departamento en el que trabaja.

La concatenacin natural utiliza los atributos que tienen el mismo nombre y,
por supuesto, estn definidos sobre el mismo dominio.

Profesor Departamento
profesor nombre Direccin cod
522 JOS c/F, 32 LSI
778 EVA c/F, 51 LSI
221 LUISA c/E, 333 FI

profesor nombre direccin cod departamento
522 JOS c/F, 32 LSI LENGUAJES
778 EVA c/F, 51 LSI LENGUAJES
221 LUISA c/E, 333 FI FILOLOGA

select p.*, d.departamento
from profesor p, departamento d
where p.cod = d.cod
17

Si no existen 2 filas, una en cada tabla con ese valor idntico que las une, el
resultado de la concatenacin es vaco (no devuelve ninguna tupla). En
nuestro ejemplo sera el caso de que ningn profesor trabajara en ningn
departamento (si la columna Profesor.cod almacenara nulos para todas las
filas en un determinado estado de la base de datos).

El problema se presenta cuando ms de una columna comparte tanto nombre
como dominio: el operador intentar unir las filas que comparten los mismos
valores en todos esos atributos. Cambiando un poco el ejemplo anterior,

17
El operador concatenacin natural lleva implcita la condicin de la clusula where. En realidad,
esta expresin en SQL es la descomposicin en primitivas de la concatenacin natural que se
ver ms adelante: un producto cartesiano ms una seleccin y una proyeccin.
lgebra relacional
72

cod nombre
LSI LENGUAJES
CCIA CIENCIAS
FI FILOLOGA

podemos pensar que el esquema de Departamento tiene como nombre de la
columna de descripcin nombre en vez de departamento. La concatenacin
natural slo devolver aquellos profesores y departamentos que cumplan que
el profesor trabaja en l y que ambos tienen el mismo nombre.

profesor nombre direccin cod
522 LENGUAJES c/F, 32 LSI
778 EVA c/F, 51 LSI
221 LUISA c/E, 333 FI

profesor nombre direccin cod
522 LENGUAJES c/F, 32 LSI

select p.*,d.departamento
from profesor p, departamento d
where p.cod = d.cod and p.nombre =
d.nombre

Cuando no se desea este comportamiento, si queremos que la unin de filas
se realice nicamente por las columnas etiquetadas como cod, estamos
obligados a utilizar una combinacin de otros operadores. De hecho, la
concatenacin natural es uno de los operadores derivados, y se puede
expresar en funcin de los operadores bsicos seleccin, proyeccin y
producto cartesiano.

divisin

Este operador es el de aplicacin menos habitual, se utiliza para consultas del
tipo alumnos matriculados en todas las asignaturas. Es, adems, el
operador con ms restricciones a la hora de construir una expresin en AR. El
dividendo debe tener ms atributos que el divisor, dividendo y divisor han de
compartir uno o varios atributos, stos han de ser los ltimos del dividendo y
los nicos del divisor y estar en el mismo orden. Los atributos no comunes
son la informacin que se obtiene de la divisin. En la prctica, sea necesario
o no, se suele utilizar la proyeccin para asegurar que se cumplen todas
estas reglas.

En nuestro ejemplo, alumnos matriculados en todas las asignaturas,
usamos la tabla matriculado que es la que representa qu alumnos estn
matriculados en qu asignaturas. Todas la asignaturas son, evidentemente,
las asignaturas almacenadas en la tabla asignatura
18
: el atributo comn a
ambas relaciones es asignatura, y la informacin que queremos obtener es
alumno (que despus se puede concatenar con la tabla Alumno para
obtener su nombre y direccin).

18
En realidad, debemos identificar ese todos al qu se refiere, a qu tabla y a qu datos, puede
no ser trivial: alumnos matriculados en todas las asignaturas de menos de 6 crditos, por
ejemplo.
lgebra relacional
73

asignatura nombre
BD1 Bases1
BD2 Bases2
FP2 Prog2

Alumno Asignatura
234 LUCA c/A, 3
321 JUAN c/C, 33
221 LUISA c/E, 333
Matriculado
alumno asignatura
234 BD1
234 BD2
234 FP2
321 BD1
321 FP2

Matriculado [alumno, asignatura] % ( Asignatura [asignatura] )
alumno
234
select alumno
from matriculado m
where not exists
(select * from asignatura a
where not exists
(select * from matriculado m2
where m2.alumno = m.alumno
and m2.asignatura =
a.asignatura))
19

La razn de que la divisin tenga unas reglas de composicin tan estrictas
est en que ste es otro de los operadores derivados, ya que se puede
realizar la misma operacin con una combinacin de diferencias y
proyecciones.

IV2.1.el problema de los nombres de los atributos en
las relaciones derivadas

Cuando operamos en AR de dos tablas obtenemos una tercera tabla
resultado. Esta tabla cumple todas las restricciones del modelo relacional y,
por tanto, tiene un esquema de relacin que es generado automticamente.
Dicho de otra forma, las relaciones derivadas tambin tienen nombre para sus
atributos pero estos nombres se asignan directamente de los operandos y
segn el operador utilizado y el orden de tales operandos.

Por ejemplo, la unin, interseccin y diferencia dan como resultado una tabla
que tiene los mismos nombres de columna que la primera tabla operando.

Alumno (alumno, nombre, direccin)
Profesor (profesor, nombre, direccin)
Alumno Profesor
T(Alumno.alumno, Alumno.nombre, Alumno.direccin)

19
La expresin seleccionar aquellos alumnos que estn matriculados en todas las asignaturas
se puede resolver en SQL si cambiamos un poco el enunciado: seleccionar aquellos alumnos
que cumplen que no existe ninguna asignatura en la que no estn matriculados
lgebra relacional
74

Pero para la concatenacin natural los nombres se asignan de diferente
forma: todos los nombres de atributo de la primera relacin ms los no
comunes de la segunda.

Profesor (profesor, nombre, direccin, cod)
Departamento (cod, descripcin)

T(Profesor.profesor, Profesor.nombre,
Profesor.direccin, Profesor.cod,
Departamento.descripcin)

El producto cartesiano produce tablas con todos los atributos de las dos
relaciones operando, pero respetando el orden en que se ha operado:

Alumno (alumno, nombre, direccin)
Profesor (profesor, nombre, direccin)
Alumno Profesor
T(Alumno.alumno, Alumno.nombre,
Alumno.direccin, Profesor.profesor,
Profesor.nombre, Profesor.direccin)

La divisin produce una tabla con los atributos no comunes de la primera
relacin:

Matriculado [alumno, asignatura]
% ( Asignatura [asignatura] )
T(Matriculado.alumno)

Finalmente, la seleccin y la proyeccin, al ser operadores con un nico
operando, la tabla resultado tiene todos (si es una seleccin) o algunos (si es
una proyeccin) de los atributos de la relacin operando.

Alumno donde direccin=c/C, 33
T(Alumno.alumno, Alumno.nombre, Alumno.direccin)

Alumno [direccin]
T(Alumno.direccin)

Es fundamental tener claro cuales son los atributos que resultan de cada
operacin ya que las expresiones del AR son una secuencia de operaciones
cuyo resultado es el operando de la siguiente. La evaluacin de las
expresiones se realiza de izquierda a derecha salvo si se utilizan parntesis
que alteran el orden de evaluacin. Las siguientes expresiones son correctas:

Alumno Profesor [Alumno.nombre]

Matriculado [alumno, asignatura]
% ( Asignatura [asignatura] )
Alumno donde direccin = c/C, 33 [alumno, nombre]

Pero las mostradas a continuacin son incorrectas:

Alumno Profesor [nombre]
hay dos columnas nombre en la relacin derivada.

Matriculado [alumno, asignatura] % Asignatura [asignatura]
lgebra relacional
75

al evaluar de izquierda a derecha la aplicacin de los operadores
sera proyeccin, divisin y, finalmente, proyeccin. Los atributos del
divisor seran todos los de Asignatura, y no son consistentes con las
restricciones del operador. Antes de dividir, se debera proyectar
sobre Asignatura.

Alumno [alumno, nombre] donde direccin = c/C, 33

si proyectamos antes de seleccionar estamos eliminando
precisamente la columna direccin que es la que utiliza la seleccin
en la condicin de filtro.

IV2.2.operaciones primitivas.

Las nicas operaciones consideradas como primitivas son la seleccin,
proyeccin, unin, producto cartesiano, y diferencia. As, concatenacin
natural, interseccin y divisin se pueden expresar en funcin de las
primitivas mencionadas antes:

R S = R - (R - S)
R S = ((RS) DONDE R.B
1
=S.B
1
y... y R.B
m
=S.B
m
)
[R.A
1
, ..., R.A
n
, R.B
1
, ..., R.B
m
, S.C
1
, ..., S.C
P
]

donde los B
i
son los atributos comunes a las dos
relaciones, los A
i
los no comunes de R y los C
i
los no
comunes de S.
R S = R[B] - ((R[B] S) - R)[B]
donde B es el conjunto de atributos no comunes de R.

IV2.3.uso del alias de una relacin

Se puede definir un alias para una relacin en cualquier ocasin pero su uso
est ms justificado por operaciones como la siguiente

Matriculado Matriculado

Un producto de una tabla por si misma es a veces necesario para ciertas
consultas de conteo simple (alumnos que se han matriculado de al menos 2
asignaturas). El problema reside en que el esquema de la relacin derivada
sera:

T(Matriculado.alumno, Matriculado.asignatura,
Matriculado.alumno, Matriculado.asignatura)

Evidentemente, en una tabla no pueden existir dos columnas distintas con el
mismo nombre (aunque s en dos tablas distintas). La solucin consiste en
utilizar uno o dos alias para la relacin Matriculado:

definir alias M para Matriculado
Matriculado M

T(Matriculado.alumno, Matriculado.asignatura,
76

Practicas

Tenemos el siguiente esquema relacional de base de datos:

CLIENTES(N Cliente, Nombre, Direccin, Telfono, Poblacin)

PRODUCTO(Cod Producto, Descripcin, Precio)

VENTA(Cod Producto, N Cliente, Cantidad, Id Venta)

La tabla de clientes almacena informacin sobre cada posible cliente
de nuestra empresa.

En la tabla de productos almacenamos informacin sobre cada
producto de la empresa.

La tabla de ventas relaciona a las dos anteriores utilizando el atributo
cod Producto para indicar el producto que se venda, y el atributo N
Cliente para indicar el cliente al que vendimos el producto.

Sobre ella se realizan estos ejercicios (las soluciones estn al final):

[1]
Realizar una consulta que muestre el
clientes de Palencia
nombre de los
[2]

Indicar el cdigo y descripcin de los
cdigo coincida con su descripcin

productos cuyo

[3] Obtener el nombre de los clientes junto con el
identificador de venta y la cantidad vendida, de aquellos
productos de los que se vendieron ms de 500 unidades

[4] Nombre de los clientes de la tabla Clientes que no
aparecen en la tabla de ventas (Clientes que no han
comprado nada)

[5] Nombre de los clientes que han comprado todos los
productos de la empresa

[6] Identificador de las ventas cuya cantidad supera a la
cantidad vendida en la venta nmero 18

[7] Productos que no se han comprado nunca en Palencia

[8] Productos que se han vendido tanto en Palencia como en
Valladolid
77

[9] Poblaciones a las que hemos vendido todos nuestros
productos

Imaginemos que aadimos la tabla de facturas que se relaciona con
la de ventas, de modo que a la tabla de ventas le aadimos el n de
Factura con la que se relaciona. En la tabla de factura indicamos la
fecha, el nmero y si se pago o no (un 1 significa pagado, un 0 que
no est pagada). Cada factura se corresponde con varias ventas y
con un solo cliente, para lo cual se vara el diseo:

FACTURA(N Factura, Fecha, Pagada, N Cliente)

VENTA(Cod Producto, N Factura, Cantidad, Id Venta)

[10] Obtener el nombre de los clientes que tienen alguna
factura sin pagar

[11] Clientes que han pagado todas sus facturas

Soluciones

Lo primero es renombrar las tablas para facilitar su manejo en las
consultas:

Clientes C
Pr oductos P
Ventas V

[1]

[2]

nombre
(
poblacin ="Palencia "
C )

cd Pr oducto , Descripcin
(
cod Pr oducto = Descripcin
P)

[3]

C . Nombre , P. Descripcin ,V .Cantidad

((
cantidad >500
V )PC )

[4]

nombre
C

nombre

(CV )

[5] Se aplica una divisin sobre toda la tabla de ventas
mezclada con clientes y se divide entre la tabla de
productos (quedan los clientes que tienen todas las
combinaciones de la tabla de productos)
78

nombre
((
C .nombre ,C . N Cliente ,V .codproducto
(CV )) : (
codproducto

P))

[6] Dividimos la consulta en dos, primero obtenemos la fila
correspondiente a la venta n 18 y luego la combinamos
con todas las dems eliminando las que tengan ventas
menores

idVenta =18
V

V '
V

V '

V .cantidad >V '.Cantidad

[7] Se resuelve sacando primero los productos que s se
compraron en Palencia y luego restndoles del conjunto
total de Productos

V .codproducto
((
poblacin="Palencia"
C )V )

Pale

codproducto

P Pale

[8] Se trata de una interseccin entre los productos de
Palencia y los productos comprados en Valladolid

V .codproducto
((
poblacin="Palencia"
C)V ) Pale

V .codproducto
((
poblacin="Valladolid "
C )V ) Vall

Pale I Vall

[9] Necesitamos sacar la lista de poblaciones con los cdigos
de productos que se han vendido en ellas. Luego
dividimos entre los cdigos de la tabla de productos y
quedarn las poblaciones en las que se han pedido todos
los cdigos

poblacion
((
C . poblacin ,V .codproducto
(CV )) : (
codprodcto

P))

[10]

nombre ,n factura
(
Pagada =0
(CF ))

79

[11] La consulta no se puede hacer como la anterior, ya que
puede haber clientes que hayan pagado algunas facturas y
otras no. Se parte de la consulta anterior para hacer esto:

nombre
(
Pagada =0
(CF ))

Pagadores

80

nombre
81

Pagadores

Practica 2

Ejercicios de lgebra relacional (2)

Tenemos el siguiente esquema relacional de base de datos:

EQUIPOS(Id Equipo, Nombre, Poblacin, n socios)

JUGADORES(Id Jugador, Nombre, Nacionalidad, Id Equipo)

PARTIDO(Id Equipo Casa, Id Equipo Fuera, Fecha,
Id Partido, Goles Casa, Goles Fuera)

Sobre ella se realizan estos ejercicios (las soluciones estn al final):

[1] Mostrar el nombre de los jugadores del Real Madrid

[2] Partidos en el que el resultado fue un empate, se requiere
el nombre del equipo que jug en casa, el nombre del
equipo que jug fuera y los goles que marc cada uno

Soluciones

consultas:

Jugadores J
Partidos P
Equipos E

[1]

nombre
((

nombre =

"Re

alMadrid "
E ) J )
IdEquipo
82

[2] El problema de esta consulta es que los equipos se
relacionan con los partidos dos veces, una como equipos
de casa y otra como equipos forneos. Por ello primero
conseguimos el nombre del equipo que juega en casa y
luego el nombre del que juega fuera. El resto es fcil

nombre , golescasa ,
( P

golesfuera ,idequipofu era

P.idequipocasa = e.idequipo
E ) > P'
83

P '.nombre , golescasa ,
( P'

golesfuera , E .nombre

golescasa = golesfuera
P' '

84

P.idequipofu era = e.idequipo
85

E ) P' '

PRACTICA 3

Ejercicios de lgebra relacional (3)

Con este esquema:

SANITARIOS(Id Sanitario, Nombre, Profesin)

PACIENTES(Id Paciente, Nombre, N SS, Direccin, Telfono)

CONSULTA(Id Sanitario, Id Paciente, Da, Mes, Ao, Comentarios,
Id Consulta)

RECETA(ID Consulta, Marca, Comentarios)

Sanitarios y sanitaria son el personal de un centro de salud, su
profesin es Mecicina, Enfermera,...

Los pacientes visitan al personal sanitario y se anota la visita
anotando una fila en la tabla de consultas en la que se indica la fecha
(separando el da, el mes y el ao) el sanitario y el paciente
relacionados con la consulta. Los pacientes son los que pertenecen al
centro de salud, pero no tienen porque haber hecho ni una sola
consulta.
En cada consulta se pueden recetar una o ms recetas.
Con este esquema realizar las siguientes consultas

[1] Mostrar el nombre y n de la seguridad social de los
pacientes que an no han hecho ni una sola consulta

[2] Mostrar el nombre de los profesionales sanitarios que han
tenido consulta con el o la paciente nmero 205

[3] Pacientes (nombre e identificador) que no han tenido
consulta con ningn enfermero o enfermera

[4] Pacientes (nombre e identificador) que han tenido
consulta con el personal sanitario nmero 189 y nmero
230

[5] Pacientes (nombre e identificador) a los que nunca se les
ha recetado nada

[6] Pacientes que han ido a consulta todos los meses

[7] Pacientes que no han ido a consulta en todo el ao 2005
86

Soluciones

consultas:

Consultas C
Sanitarios S
Pacientes P
recetas R

[1] Para sacar los pacientes que no han hecho consultas, hay
que tener en cuenta que dichos pacientes estarn en la
tabla de pacientes, pero no en la de consultas. Lo que se
realiza:

n SS ,nombre

P
n SS ,nombre
( PC )

[2] :

S .nombre
((
idpaciente = 205
P)CS ))

[3] Parecida a la primera, slo que tenemos que sacar los
pacientes que han tenido consulta de enfermera y
restarles del conjunto total de pacientes:

P.id ,nombre
((

profesin ="enfermera "
S )CP)

idpaciente ,nombre
P P'
87

[4] La tentacin es hacer una seleccin en la que utilicemos
una seleccin sobre la tabla de consultas usando una
condicin "OR". Pero no funcionara ya que queremos slo
los pacientes que han tenido consulta con ambos
profesionales.
La solucin es obtener los que tuvieron consulta con el
205. Luego los que la tuvieron con el 108 y hallar la
interseccin

P.idpaciente ,nombre
((
230
C )P)

((
198
C )P)

P230

P198

P230 I P198

[5] Otra vez el mismo juego, seleccionamos los que s han
tenido recetas y les restamos de los originales

( PCR)

P' '

P P' '

[6] Esta es la ms difcil. Necesitamos dos tablas para poder
dividirlas y as obtener este complicado resultado. Una
tabla contendr un solo atributo, los meses del ao.
Necesitaramos los 12 meses, para lo cual tendramos que
rellenar esa tabla, pero suponemos que se han consultas
todos los meses del ao y cogiendo los meses de la tabla
de consultas, tendremos todos (la proyeccin
supondremos que nos dar resultados nicos).
Luego utilizaremos una tabla en la que aparezca el
nmero de paciente, su nombre y otra columna con el mes
de su consulta. Dividiendo nos saldr el resultado deseado

[7]

mes
C

meses

mes , P.idpaciente ,nombre
( PC )

P' ' ': meses

P' ' '

UNIDAD 6

BASES DE DATOS
TEMA 4. SQL. UN LENGUAJE DE CONSULTA COMERCIAL
PARA BASES DE DATOS RELACIONALES
Contenidos generales

* Definicin de datos en SQL
* Consulta de datos en SQL
- Estructura bsica de una sentencia SQL
- Operaciones de conjuntos
- Funciones de agregacin
- Vistas
* Actualizacin de datos en SQL

Motivacin

BD deben facilitar la definicin y recuperacin de datos
Las BDR se encuentran bien establecidas
SQL es un lenguaje de consulta estndar para BDR
Definicin de datos
Consulta de datos
Actualizacin de datos

Bases de datos. Tema 4. 2

4.1. Introduccin (1)

Algebra relacional como lenguaje de consulta formal
procedimental -> Especificar el cmo
SGBDRs comerciales ofrecen una interfaz SQL
Sentencias SQL en aplicaciones (SQL embebido)

SQL permite definir la base de datos as como consultar y
modificar sus datos


4.1. Introduccin (2)

nombreSuc ciudadSuc Activo nombreEmp dniEmp telefono NombreSuc
Downtown Brooklyn 9000000 Smith 10 101010 Downtown
Redwood Palo Alto 2100000 Kortz 11 111111 Downtown

Sucursales
Perrydge Horseneck 1700000 Hansen 12 121212 Perrydge

Mianus Horseneck 400000 Dubitzky 13 131313 Perrydge
Round Hill Horseneck 8000000 Henson 14 141414 Mianus
Pownal Bennington 300000 Kravitz 15 151515 Brighton
North Town Rye 3700000

Brighton Brooklyn 7100000 Empleados
numeroCta saldo nombreSuc nombreCli dniCli Domicilio
1 10000 Downtown Johnson 1 La Reina n7
2 20000 Downtown Smith 2 Fragata azul n8
Cuentas
3 30000 Perrydge Hayes 3 Gibraltar espaol n14

4 40000 Perrydge Turner 4 Gibraltar espaol n17
5 50000 Mianus Williams 5 Diamante S/N
6 60000 Brighton Lindsay 6 Gato negro n13
Green 7 Perro n1

CtaCli
dniCli numeroCta

numeroCta numeroTrans fecha importe
Clientes

Transacciones
1 1
1 2
2 3
3 4
4 5
5 5
6 5
7 6
1 1 10-10 +10000
2 1 10-10 +30000
2 2 11-10 -20000
3 1 12-10 +30000
4 1 12-10 +40000
5 1 13-10 +50000
6 1 13-10 +60000

4.2. Definicin de datos en SQL (1)

Definicin de datos en SQL: Creacin, modificacin y
eliminacin de tablas (relaciones), vistas, ndices, ...

Trmino relacional Trmino SQL
Tabla Table
Fila Row
Column Column

Crear: CREATE
Eliminar: DROP
Modificar: ALTER



4.2.1. Esquemas y catlogos
Esquemas
* Permiten definir conjuntos de tablas y otros elementos
* Disponible desde SQL2
* Identificables mediante un nombre
* La creacin del esquema se puede hacer en un solo
paso (especificando sus elementos). Tambin se puede
declarar en esquema y luego incorporarle sus elementos
Ejemplo
CREATE SCHEMA BANCO AUTHORIZATION MLOPEZ
Catlogo: Conjunto de esquemas


4.2.2. Creacin de tablas, tipos de datos y restricciones
Creacin de tablas: CREATE TABLE
Ejemplo
i) CREATE TABLE BANCO.CLIENTE
ii)CREATE TABLE CLIENTE
Definicin de una tabla
Nombre de la tabla
Declaracin de atributos: Nombre, dominio, restricciones
Restricciones: Clave, integridad referencial, y dems



Ejemplo de creacin de tablas
CREATE TABLE CLIENTES
(NOMBRECLI VARCHAR(50) NOT NULL,
DNICLI VARCHAR(8) NOT NULL,
DOMICILIO VARCHAR(50) NOT NULL,
PRIMARY KEY (DNICLI)
ON DELETE CASCADE ON UPDATE CASCADE
);
CREATE TABLE CUENTAS
(NUMEROCTA VARCHAR(10) NOT NULL,
SALDO DECIMAL(12,2) NOT NULL,
NOMBRESUC VARCHAR(50) NOT NULL,
PRIMARY KEY (NUMEROCTA)
ON DELETE CASCADE ON UPDATE CASCADE
);
Atributos

Restricciones

Atributos

Restricciones


Ejemplo de creacin de tablas
CREATE TABLE CTACLI
(DNICLI VARCHAR(8) NOT NULL,

NUMEROCTA VARCHAR(20) NOT NULL,
PRIMARY KEY (DNICLI, CTACLI),
FOREIGN KEY (DNICLI) REFERENCES
CLIENTES(DNICLI),
FOREIGN KEY (NUMEROCTA) REFERENCES
CUENTAS(NUMEROCTA)
);
Atributos

Restricciones



4.2.3. Tipos de datos y dominios en SQL
Caracteres, numricos, fecha y hora
* Enteros: INTEGER o INT, SMALLINT
* Reales: FLOAT, REAL, DOUBLE PRECISION
* Cadena de longitud fija: CHAR(n) o CHARACTER(n)
* Cadena de longitud variable: VARCHAR(n)
* Fecha: DATE Componentes: YEAR, MONTH,DAY
Formato: YYYY-MM-DD
* Hora: TIME Componentes: HOUR, MINUTE, SECOND
Formato: HH:MM:SS.



4.2.4. Definicin de claves primarias y externas.
Especificacin de restricciones
Definicin de clave: PRIMARY KEY

Los atributos que forman la clave deben ser NOT NULL
Definicin de clave externa: FOREIGN KEY ... REFERENCES
CREATE TABLE CTACLI
(DNICLI VARCHAR(8) NOT NULL,
NUMEROCTA VARCHAR(20) NOT NULL,
PRIMARY KEY (DNICLI, CTACLI),
FOREIGN KEY (DNICLI) REFERENCES
CLIENTES(DNICLI),
FOREIGN KEY (NUMEROCTA) REFERENCES
CUENTAS(NUMEROCTA)
);



4.2.5. Modificacin de tablas
Modificacin de tablas: ALTER TABLE
* Aadir o eliminar columnas
* Modificar la definicin de una columna
* Aadir o eliminar restricciones de columna
Ejemplo (Aadir columna):
ALTER TABLE BANCO.CLIENTES ADD CIUDAD
VARCHAR(20);
Ejemplo (Eliminar columna):
i) Propagacin en cascada (CASCADE)
ii) No eliminar si hay relacionados (RESTRICT)
ALTER TABLE BANCO.CLIENTES DROP CIUDAD
CASCADE;



4.2.6. Eliminacin de tablas y esquemas
* Eliminacin de tablas: DROP TABLE
* Eliminacin de esquemas: DROP SCHEMA
Si hay elementos relacionados se puede detener el proceso
(RESTRICT) o se puede propagar el efecto (CASCADE)
Ejemplo:
DROP TABLE CLIENTES RESTRICT;
DROP SCHEMA BANCO CASCADE;


4.3. Estructura bsica de una consulta SQL (1)

Componentes bsicos de una sentencia SQL
* Clusula SELECT: Proyeccin. Atributos deseados
* Clusula FROM: Producto cartesiano. Tablas involucradas
* Clusula WHERE: Seleccin. Condiciones o predicados
Sentencia SQL tpica
SELECT A
1
, A
2
, ..., A
n
FROM R
1
, R
2
, ..., R
m

WHERE P

equivalente a
A1, A2, ..., An

(
P
(R
1
x R
2
x ... x R
m
))

El uso de SELECT * devuelve todos los atributos



Ejemplo: Nombres de todos los clientes
SELECT nombreCli
FROM clientes;
Ejemplo: Nombres de los empleados de Downtown
SELECT nombreEmp
FROM empleados
WHERE nombreSuc = "Downtown";
Eliminacin de duplicados
SELECT DISTINCT
Ejemplo: Nombres diferentes de empleados de
Downtown
SELECT DISTINCT nombreEmp
FROM empleados
WHERE nombreSuc = "Downtown";


Conservacin de duplicados (Predeterminado)
SELECT ALL
Uso de operadores aritmticos
SELECT numeroCta, saldo * 166.386
FROM cuentas;


4.4. Predicados y conectores (1)

Uso en la especificacin de predicados implcitos (para
combinar tablas) y de predicados explcitos.
SELECT empleados.nombreEmp
FROM sucursales, empleados
WHERE sucursales.nombreSuc = empleados.nombreSuc;
Conectores lgicos: AND, OR y NOT
Ejemplo: Nombres de empleados de la ciudad de
Brooklyn
SELECT empleados.nombreEmp
FROM sucursales, empleados
WHERE sucursales.nombreSuc = empleados.nombreSuc
AND sucursales.ciudadSuc = "Brooklyn";


4.4. Predicados y conectores (2)

Operador BETWEEN
Ejemplo: Nmeros de cuenta con saldos comprendidos
entre 20000 y 50000
SELECT numeroCta
FROM cuentas
WHERE saldo BETWEEN 20000 AND 50000;
Comparacin aproximada: Operador LIKE
Uso de comodines: 1 crcter _
Varios caracteres %
Ejemplo: Nombres de clientes que vivan en cualquier
casa de la calle Gibraltar espaol
SELECT nombreCli
FROM clientes
WHERE domicilio LIKE "Gibraltar espaol%";


4.5. Ordenacin de tuplas

Ordenacin mediante ORDER BY
ORDER BY va despus del WHERE, si procede.
Ordenacin ascendente de forma predeterminada
Ejemplo: Lista alfabtica de clientes con cuenta en
Downtown
SELECT DISTINCT nombreCli
FROM clientes, cuentas, ctacli
WHERE clientes.dniCli = ctacli.dniCli AND
cuentas.numeroCta = ctacli.numeroCta AND
cuentas.nombreSuc = "Downtown"
ORDER BY nombreCli;
Ordenacin descendente: Uso de DESC despus del

nombre de columna.


4.6. Creacin de alias (1)

Variables de tupla: Permiten la comparacin de dos filas de
la misma tabla. Renombra a una tabla
Ejemplo: Empleados que trabajan con Smith
SELECT E.nombreEmp
FROM Empleados E, Empleados Ebis
WHERE Ebis.nombreEmp = "Smith" AND
Ebis.nombreSuc = E.nombreSuc;
Ejemplo: Sucursales con activo superior al de alguna
sucursal de Horseneck
SELECT E.nombreEmp
FROM Sucursales S1, Sucursales S2
WHERE S1.ciudadSuc = Horseneck AND
S2.Activo > S1.Activo;


4.6. Creacin de alias (2)

Para renombrar atributos se usa AS
SELECT nombreSuc AS nombreDeSucursales
FROM sucursales;
Bastate til cuando se tienen nombres complicados para
una columna o se han realizado operaciones.
Ejemplo:
SELECT numeroCta, saldo * 166.386 AS SaldoAPesetas
FROM cuentas;


4.7. Operaciones de conjuntos (1)

Unin (UNION), Interseccin (INTERSECT) y Diferencia
(MINUS)
Ejemplo: Nombre de todas las personas
SELECT nombreEmp
FROM empleados
UNION
SELECT nombreCli
FROM clientes;
Ejemplo: Nombres de empleados que coinciden con
clientes
SELECT nombreEmp
FROM empleados
INTERSECT
SELECT nombreCli
FROM clientes;


4.7. Operaciones de conjuntos (2)

Ejemplo: Nombres de empleados que no coinciden con
clientes
SELECT nombreEmp
FROM empleados
MINUS
SELECT nombreCli
FROM clientes;

Estas 3 operaciones eliminan los duplicados de forma
predeterminada. Para conservar los duplicados utilizaremos
UNION ALL, INTERSECT ALL, y MINUS ALL


4.8. Consultas anidadas y pertenencia a conjuntos (1)

Para realizar una comparacin con un conjunto de valores
podemos utilizar conjuntos explcitos en lugar de varios OR
Ejemplo: Empleados que trabajan en Brighton o
Downtown
SELECT nombreEmp
FROM empleados
WHERE nombreSuc IN ("Downtown", "Brighton");

Tambin podemos utilizar NOT IN para la no pertenencia
Otro uso es que los valores se obtengan como resultado de
una consulta -> Consultas anidadas

Nombre Apellidos NSS AoNacimiento Sexo Salario NSSSuperv
Pedro Mrquez 1 1954 H 1200 2
Isabel Fernndez 2 1972 M 1150 3
Mara Yage 3 1963 M 2200 null
Juan Martn 4 1971 H 1050 3

Nombre NSSP AoNacimiento Sexo Parentesco
Juana 1 1974 M Hija
Manuel 1 1976 H Hijo
Margarita 1 1958 M Esposa
Mara 3 1993 M Hija
Luis 3 1963 H Esposo


Ejemplo: Empleados que trabajan en sucursales de la
ciudad de Brooklyn
SELECT nombreEmp
FROM empleados
WHERE nombreSuc IN (SELECT nombreSuc
FROM sucursales
WHERE ciudadSuc = "Brooklyn");

Si hay ambigedades en los nombres de las columnas se
solucionan buscando en la consulta ms interna



4.8.1. Consultas correlacionadas
Son un tipo especial de consultas anidadas
Son consultas en las que la consulta anidada se ejecuta una
vez para cada fila de la consulta externa
Se consigue cuando en el WHERE de la subconsulta se
hace referencia a columnas de la consulta externa

Personal

Familia


4.8.1. Consultas correlacionadas
Ejemplo: Nombre y apellidos de trabajadores con el
mismo nombre y sexo que sus familiares
SELECT Nombre, Apellidos
FROM Personal
WHERE Nombre IN
(SELECT Nombre
FROM Familia
WHERE NSS=NSSP AND

Personal.Nombre = Familia.Nombre AND
Personal.Sexo = Familia.Sexo);
Tambin se podra hacer combinndolas con el NSS



4.8.2. Funcin EXISTS
Permite comprobar si el resultado de una consulta es vaco
Ejemplo: Nombre y apellidos de trabajadores para los
que existan familiares con su nombre y su sexo
SELECT Nombre, Apellidos
FROM Personal
WHERE EXISTS
(SELECT *
FROM Familia
WHERE NSS=NSSP AND
Personal.Nombre = Familia.Nombre AND
Personal.Sexo = Familia.Sexo);
Tambin se puede utilizar NOT EXISTS

4.9. Comparacin de conjuntos

Se usa cuando el predicado supone la comparacin con los
algunos o todos los elementos de un conjunto
Para ello se utiliza SOME y ALL

Ejemplo: Sucursales que tienen un activo superior a
cualquiera de las sucursales de la ciudad de Horseneck
SELECT nombreSuc
FROM sucursales
WHERE activo > SOME (SELECT activo
FROM sucursales
WHERE ciudadSuc = "Horseneck");
Para comparar con todos los valores se utiliza ALL
Ambos se puede combinar con los operadores de
comparacin, dando lugar a
< SOME, <= SOME, >= SOME, <> SOME, = SOME, < ALL, <=
ALL, >= ALL, = ALL y <> ALL

4.10. Funciones de agregacin (1)

Son funciones aplicadas a grupos de filas
Promedio: AVG
Mnimo: MIN
Mximo: MAX
Total: SUM
Cuenta: COUNT
Los grupos se establecen mediante GROUP BY
La clusula GROUP BY va despus de la clusula WHERE
Las filas que se agrupan tienen el mismo valor en las
columnas por las que se realiza la agrupacin



Ejemplo: Activo medio por ciudades escribiramos lo
siguiente:
SELECT ciudadSuc, AVG(activo)
FROM sucursales
GROUP BY ciudadSuc;
Es posible establecer condiciones sobre los grupos. Esto se
hace mediante la clusula HAVING
Ejemplo: Activos de las sucursales por ciudades para
aquellas en que la media sea superior a 2000000,
escribiramos
SELECT ciudadSuc, AVG(activo)
FROM sucursales
GROUP BY ciudadSuc
HAVING AVG(activo) > 2000000;



Ejemplo: Sucursales que tienen ms de una cuenta, y
luego utilizar esto para obtener en qu ciudad est
SELECT ciudadSuc
FROM Sucursales
WHERE nombreSuc IN
(SELECT nombreSuc
FROM Cuentas
GROUP BY nombreSuc
HAVING COUNT(numeroCta) > 1);
Ejemplo: Nmero de ciudades en los que el banco tiene
sucursales
SELECT COUNT (DISTINCT ciudadSuc)
FROM Sucursales


4.11. Vistas (1)

Permiten la personalizacin de la informacin
Tablas derivadas a partir de otras (pueden ser vistas a su
vez)
Son tablas virtuales: No tienen por que estar almacenadas
fsicamente
Presentan algunos problemas en la actualizacin
Definidas con CREATE VIEW
Ejemplo: Vista que contiene el nombre, telfono y la
ciudad en la que trabajan cada uno de los empleados
CREATE VIEW EmpleCiudad
AS SELECT nombreEmp, telefono, ciudadSuc
FROM Empleados, Sucursales
WHERE Empleados.nombreSuc = Sucursales.nombreSuc;


4.11. Vistas (2)

Vistas con especificacin del nombre de las columnas
Ejemplo: Vista con el DNI de cada cliente y el saldo
total de sus cuentas
CREATE VIEW ClientesSumaSaldo (DNICli, SaldoTotal)
AS SELECT DNICli, SUM(Saldo)
FROM Clientes, CtaCli, Cuentas
WHERE Clientes.DNICli = CtaCli.DNICli and
CtaCli.numeroCta = Cuentas.numeroCta
GROUP BY Clientes.DNICli;
Eliminacin de vistas con DROP VIEW
Ejemplo: Eliminacin de la vista ClientesSumaSaldo
DROP VIEW ClientesSumaSaldo;


4.12. Operaciones de modificacin en SQL (1)

4.12.1. Insercin (INSERT)
Insertar un solo registro
Sintaxis:
INSERT INTO nombreTabla VALUES (valor1, valor2, ...);
Ejemplo:
INSERT INTO Empleados
VALUES (Harry, 16, 161616, Brighton);

Insercin de filas incompletas
INSERT INTO Empleados (nombreEmp, dniEmp, nombreSuc)
VALUES (Mukos, 17, Brighton);

Insertar el resultado de una consulta
Sintaxis:
INSERT INTO nombreTabla ExpresionSELECT;



4.12.2. Eliminacin (DELETE)
Eliminar de una tabla las filas que cumplen una condicin
Sintaxis:
DELETE
FROM Tabla
WHERE Condicion;
Ejemplo:
DELETE
FROM Empleados
WHERE nombreEmp = Mukos;



4.12.3. Actualizacin (UPDATE)
Actualizar en una tabla las filas que cumplen una condicin
Sintaxis:
UPDATE tabla
SET Modificacion
WHERE Condicion
Ejemplo: Incrementar en un 10 por ciento el saldo de las
cuentas de sucursales de la ciudad de Horseneck
UPDATE Cuentas
SET saldo = saldo * 1.1
WHERE nombreSuc IN (SELECT nombreSuc
FROM Sucursales
WHERE ciudadSuc = Horseneck);


4.13. Otras formas de combinacin de relaciones (1)

Hasta ahora, uso de FROM para indicar producto cartesiano
4.13.1. INNER JOIN
Forma compacta de combinar relaciones
Sintaxis:
Tabla1 INNER JOIN Tabla2 ON condicion
Ejemplo: Nombre de los empleados y la ciudad en la que
trabajan
SELECT nombreEmp, ciudadSuc
FROM Empleados INNER JOIN Sucursales ON
Empleados.nombreSuc = Sucursales.nombreSuc;



4.13.1. INNER JOIN
Ejemplo: Clientes y saldos de cada una de sus cuentas
SELECT nombreCli, saldo FROM
Cuentas INNER JOIN (Clientes
INNER JOIN CtaCli ON
Clientes.dniCli = CtaCli.dniCli) ON
Cuentas.numeroCta = CtaCli.numeroCta;



4.13.2. NATURAL INNER JOIN
Evita especificar la condicin de join
Realiza la combinacin basndose en columnas comunes
Ejemplo: Empleados y ciudad en la que trabajan
SELECT nombreEmp, ciudadSuc
FROM Empleados NATURAL INNER JOIN Sucursales;



4.13.3. Reuniones externas
Relajan la condicin de join respecto al INNER JOIN Permiten combinar registros
de una tabla que no tengan registros relaciones en otra
Reunin externa izquierda: LEFT OUTER JOIN
Permite registos de la tabla izquierda que no tengan registros relacionados en la
tabla derecha
Reunin externa derecha: RIGHT OUTER JOIN
Permite registos de la tabla derecha que no tengan registros relacionados en la
tabla izquierda
Reunin externa completa: FULL OUTER JOIN
Devuelve los registros de ambas tablas aunque no tengan registros
relacionados



4.13.3. Reuniones externas
Ejemplo: Reunin externa izquierda de Sucursales de
Horseneck con Empleados
SELECT Sucursales.nombreSuc, nombreEmp

FROM Sucursales LEFT OUTER JOIN Empleados ON Sucursales.nombreSuc =
Empleados.nombreSuc WHERE ciudadSuc = Horseneck;
Sucursales.nombreSuc nombreEmp Perrydge Hansen
Perrydge Dubitzky
Mianus Henson
Round Hill Null
Ejemplo: Reunin externa de Sucursales con Empleados
SELECT Sucursales.nombreSuc, nombreEmp
FROM Sucursales FULL OUTER JOIN Empleados ON Sucursales.nombreSuc =
Empleados.nombreSuc;


CONSULTAS
ANIDADAS
2.4 Manipulacin de datos: SQL-92
Tema 2. Modelo relacional de
datos

Consultas anidadas
E Es una consulta SELECT completa, dentro de clusula WHERE
de otra consulta (consulta exterior)
E Obtiene valores de la BD que se usan en la condicin de
otra consulta, para obtener otros datos
* Nmeros de los proyectos en que participa el empleado de apellido Silva, sea como trabajador o
como gerente del departamento que controla el proyecto
SELECT DISTINCT numerop FROM PROYECTO
WHERE numerop IN ( SELECT nump
FROM Trabaja_en, Empleado
WHERE nsse=nss AND apellido=Silva )
OR numerop IN ( SELECT numerop
FROM Proyecto, Departamento, Empleado
WHERE numd=nmerod
AND nssdire=nss AND apellido=Silva ) ;
datos

E Es posible tener varios niveles de consultas
anidadas
datos

Consultas anidadas (2): comparar conjuntos
E Operador IN (otro uso del mismo
operador)
t IN S
indica si la fila t pertenece al conjunto de filas S
(subconsulta)

* Nombre y direccin de los empleados que trabajan en algn proyecto.
SELECT nombre, direccin FROM Empleado
WHERE nss IN ( SELECT nsse FROM TRABAJA_EN );

* Nmeros de seguridad social de aquellos empleados que trabajan en algn proyecto en el que trabaje
el empleado Jos B. Silva, de forma que ambos tengan la misma combinacin (proyecto, horas); es
decir, todo empleado que trabaje las mismas horas que Jos B. Silva, en cada proyecto en el que
trabajen ambos. El nss de Jos B. Silva es 123456789.
SELECT DISTINCT nsse FROM Trabaja_en
datos

WHERE (nmp, horas) IN ( SELECT nmp, horas
FROM Trabaja_en
WHERE nsse=123456789);

Consultas anidadas (3): comparar conjuntos
E Operador ANY o SOME (otro uso del mismo operador)
t <op> ANY S o t <op> SOME S,, <op> { , , , , , }
Compara una fila t con las filas resultado de una
consulta

anidada S
Devuelve TRUE si alguna fila e de S cumple que t <op> e

E Operador ALL (otro uso del mismo operador)
t <op> ALL S,, <op> { , , , , , }
Compara una fila t con filas resultado de una consulta
anidada

S
Devuelve TRUE si para toda fila e de S se cumple que t
<op> e

* Nombres y apellidos de los empleados cuyo salario es menor que el de todos los empleados del
departamento 5
SELECT nombre, apellido FROM Empleado

WHERE salario < ALL ( SELECT salario

FROM Empleado
WH
T
E
em
R
a
E
2. M
n
o
d
d
=
el
5
o r
)
e
;
lacional de
datos

Mejor con
DISTINCT
en la
subconsulta?
datos

Consultas anidadas (4): columnas ambiguas
E Coincidencia de nombres de columnas en las
consultas exterior y anidada = Ambigedad
* Nombre y apellidos de cada empleado con familiares de igual nombre y sexo que l
WHERE nss IN ( SELECT nsse FROM Familiar
WHERE nsse=nss AND nombre_familiar=nombre
AND sexo=sexo ); cmo evitar esta ambigedad?
O Regla: Una columna no calificada se refiere a la tabla
declarada
en la consulta anidada ms interior
O Si en una consulta anidada es necesario usar columnas
de tablas
declaradas en una consulta exterior = calificar
* Nombre y apellidos de cada empleado con familiares de igual nombre y sexo que l
SELECT nombre, apellido FROM Empleado E
datos

WHERE nss=nsse AND nombre_familiar=nombre
AND sexo= E.sexo );
datos

Consultas anidadas (5): correlacin
E Una consulta exterior y otra anidada estn
correlacionadas si una condicin de la anidada
contiene columnas de una tabla declarada en la
consulta exterior
WHERE nss=nsse AND sexo=F );
E La consulta anidada se evala una vez para cada fila (o
combinacin de filas) de la consulta exterior
Evala la consulta anidada para cada fila de EMPLEADO,
Si el valor de nss de la fila EMPLEADO est en el resultado de la
consulta anidada, selecciona la fila EMPLEADO para el resultado final
E Una consulta anidada que use el operador = o IN
siempre puede

expresarse como una reunin (join)
datos

SELECT E.nombre, E.apellido
FROM Empleado, Familiar D
WHERE nss=nsse AND D.sexo=F;
datos

Consultas anidadas (6): EXISTS

E Operador EXISTS (S): comprobacin de tablas
vacas
Devuelve TRUE si la tabla S contiene al menos una fila
Devuelve FALSE si S es una tabla vaca (sin filas)
S suele ser una consulta anidada correlacionada

* Nombre y apellido de cada empleado con familiares de igual nombre y sexo que l
SELECT E.nombre, E.apellido FROM Empleado E
WHERE EXISTS ( SELECT * FROM Familiar
WHERE nsse=nss AND nombre_familiar=nombre
AND sexo=E.sexo );

* Nombres de empleados sin familiares
datos

SELECT nombre, apellido FROM Empleado E
WHERE NOT EXISTS (SELECT * FROM Familiar WHERE nsse=nss);
Base de datos II: CONSULTAS COMPLEJAS http://base-de-datos-manueljorge.blogspot.mx/2011/07/consultas-compl...
1 de 4 29/05/2013 04:19 p.m.

Consultas anidadas (y 7): UNIQUE

E Operador UNIQUE (S): Comprobacin de
filas duplicadas
Devuelve TRUE si NO hay filas repetidas en S
S suele ser una consulta anidada
correlacionada

* Nombres y apellidos de los empleados que trabajan en un nico proyecto
SELECT nombre, apellido FROM
Empleado
WHERE UNIQUE ( SELECT nsse
FROM Trabaja_en
WHERE nsse = nss );
* Nombres, apellidos y salario de los empleados con un solo familiar
SELECT nombre, apellido, salario FROM Empleado
WHERE UNIQUE ( SELECT *
FROM Familiar
WHERE nsse = nss );

2 de 4 29/05/2013 04:19 p.m.

Contenido temtico de las bases de datos, centrados en Oracle
te realizar esta operacin es el operador UNION.

La composicin de tablas

CONSULTAS COMPLEJAS

El SQL soporta dos grupos de consultas multitabla:

- la unin de tablas.

- la composicin de tablas.

La unin de tablas

Esta operacin se utiliza cuando tenemos dos tablas con las mismas columnas y queremos
obtener una nueva tabla con las filas de la primera y las filas de la segunda. En este caso la
tabla resultante tiene las mismas columnas que la primera tabla (que son las mismas que las de la
segunda tabla).

Cuando hablamos de tablas pueden ser tablas reales almacenadas en la base de datos o tablas
lgicas (resultados de una consulta), esto nos permite utilizar la operacin con ms frecuencia ya
que pocas veces tenemos en una base de datos tablas idnticas en cuanto a columnas. El
resultado es siempre una tabla lgica.

Por ejemplo queremos en un slo listado los productos cuyas existencias sean iguales a cero y
tambin los productos que aparecen en pedidos del ao 90. En este caso tenemos unos productos
en la tabla de productos y los otros en la tabla de pedidos, las tablas no tienen las mismas
columnas no se puede hacer una union de ellas pero lo que interesa realmente es el identificador del
producto (idfab,idproducto), luego por una parte sacamos los cdigos de los productos con
existencias cero (con una consulta), por otra parte los cdigos de los productos que aparecen en
pedidos del ao 90 (con otra consulta), y luego unimos estas dos tablas lgicas.

El operador que permi

3 de 4 29/05/2013 04:19 p.m.

edara de la siguiente forma con la composicin:

n la composicin permite obtener una fila con datos de la

La composicin de tablas consiste en concatenar filas de una tabla con filas de otra. En este caso
obtenemos una tabla con las columnas de la primera tabla unidas a las columnas de la segunda
tabla, y las filas de la tabla resultante son concatenaciones de filas de la primera tabla con filas
de la segunda tabla.

El ejemplo anterior qu

A diferencia de la uni s dos tablas, esto es
muy til cuando queremos visualizar filas cuyos datos se encuentran en dos tablas.
4 de 4 29/05/2013 04:19 p.m.

La sintaxis del LEFT JOIN es la siguiente:

Esta operacin consiste en aadir al resultado del INNER JOIN las filas de la tabla de
La sintaxis del RIGHT JOIN es la siguiente:

*Se pueden definir varias condiciones de emparejamiento unidas por los operadores AND y OR
poniendo cada condicin entre parntesis. Ejemplo:

SELECT *
FROM pedidos INNER JOIN productos ON (pedidos.fab = productos.idfab) AND
(pedidos.producto = productos.idproducto);

El LEFT / RIGHT JOIN

El LEFT JOIN y RIGHT JOIN son otro tipo de composicin de tablas, tambin denominada
composicin externa. Son una extensin del INNER JOIN.

Las composiciones vistas hasta ahora (el producto cartesiano y el INNER JOIN) son
composiciones internas ya que todos los valores de las filas del resultado son valores que estn
en las tablas que se combinan.

la izquierda
que no tienen correspondencia en la otra tabla, y rellenar en esas filas los campos de la tabla de
la derecha con valores nulos.

Ejemplo:

SELECT *
FROM empleados LEFT JOIN oficinas ON empleados.oficina = oficinas.oficina;

Con el ejemplo anterior obtenemos una lista de los empleados con los datos de su oficina, y el
empleado 110 que no tiene oficina aparece con sus datos normales y los datos de su oficina a
nulos.

Esta operacin consiste en aadir al resultado del INNER JOIN las filas
de la tabla de la derecha que no tienen correspondencia en la otra tabla, y
rellenar en esas filas los campos de la tabla de la izquierda con valores
nulos.

Ejemplo:

SELECT *
FROM empleados RIGHT JOIN oficinas ON empleados.oficina = oficinas.oficina;

Con el ejemplo anterior obtenemos una lista de los empleados con los datos de su oficina, y
adems aparece una fila por cada oficina que no est asignada a ningn empleado con los datos
del empleado a nulos.

Una operacin LEFT JOIN o RIGHT JOIN se puede anidar dentro de una operacin INNER JOIN,
pero una operacin INNER JOIN no se puede anidar dentro de LEFT JOIN o RIGHT JOIN.

EJEMPLOS PRCTICOS SQL


INTEGRIDAD REFERENCIAL

DROP SCHEMA IF EXISTS Tablas1;
CREATE SCHEMA Tablas1;
USE Tablas1;

create table Cliente(
Dni VARCHAR(10),
Nombre VARCHAR(10),
Apellido VARCHAR(10),

PRIMARY KEY (Dni)
)ENGINE=InnoDB;

create table Pedidos(
npedido INTEGER,
fecha DATE,
Cantidad DOUBLE,
cliente_Dni VARCHAR(10),
PRIMARY KEY (npedido),
FOREIGN KEY (cliente_Dni) REFERENCES Cliente(Dni)

)ENGINE=InnoDB;

INSERT INTO Cliente VALUES ('7211545v','Carlos','Martinez Lopez');

INSERT INTO Pedidos VALUES ('122','2010/01/05',7,'7211545v');

TABLA: Cliente

TABLA: Pedidos

Esto es un ejemplo de intento de borrado de una tupla que tiene un campo que
aparece como clave fornea en otra tabla. Por omision se aplica la condicin
de restrict y no se puede borrar hasta que no borre la tupla de la tabla hija.

Esto es un ejemplo de intento de actualizacin de una tupla que tiene un campo que
aparece como clave fornea en otra tabla. Por omision se aplica la condicin
de restrict y no se puede actualizar.

cliente Dni VARCHAR(10)

USE Tablas2;

Dni VARCHAR(10),
Nombre VARCHAR(10),

PRIMARY KEY (Dni)
)ENGINE=InnoDB;

npedido INTEGER,
fecha DATE,
Cantidad DOUBLE,
FOREIGN KEY (cliente_Dni) REFERENCES Cliente(Dni) ON DELETE CASCADE ON UPDATE CASCADE
)ENGINE=InnoDB;


TABLA: Cliente

TABLA: Pedidos

Para probar la restriccin ON UPDATE CASCADE actualizamos el valor
de un DNI. El resultado debe de ser que se actualiza la tabla padre y la hija

Se observa que se han actualizado las tablas padre e hija

Si ahora borramos una tupla de la tabla padre se borra la tupla
correspondiente de la tabla hija.

USE Tablas3;

Dni VARCHAR(10),
Nombre VARCHAR(10),

PRIMARY KEY (Dni)
)ENGINE=InnoDB;

npedido INTEGER,
fecha DATE,
Cantidad DOUBLE,
FOREIGN KEY (cliente_Dni) REFERENCES Cliente(Dni) ON DELETE RESTRICT ON UPDATE CASCADE

)ENGINE=InnoDB;


La restriccin ms adecuada en la mayora de los casos es
evitar realizar borrados en cascada y sin embargo si
actualizar en cascada

Observamos que la actualizacin en cascada ha funcionado

A diferencia del ejemplo de la Tablas2 ahora no se puede
borrar una tupla de la tabla padre por la restriccin ON DELETE RESTRICT.

Aunque es en la tabla hija donde se escribe la restriccin de la clave fornea

Ntese una cuestin que a veces es causa de confusin.
Aunque es en la tabla hija donde se escribe la restriccin de la clave fornea,
es decir, que un atributo depende de la clave de otra tabla.

Se puede borrar sin ningn problema una tupla de una tabla que contiene
una clave fornea sin afectar a la tupla correspondiente de la tabla padre
En la figura se ve el ejemplo de borrar una fila en la tabla de pedidos.

la tabla de clientes est intacta

Como se ve en la figura la tabla de pedidos est vaca y
la tabla de clientes est intacta.

)ENGINE=InnoDB;
INSERT INTO P did VALUES ('122' '2010/01/0 ' ' 211 4 ')

USE Tablas4;

Dni VARCHAR(10),
Nombre VARCHAR(10),

PRIMARY KEY (Dni)
)ENGINE=InnoDB;

npedido INTEGER,
fecha DATE,
Cantidad DOUBLE,
FOREIGN KEY (cliente_Dni) REFERENCES Cliente(Dni) ON DELETE RESTRICT ON UPDATE
CASCADE

)ENGINE=InnoDB;



Aqu mostramos el ejemplo de intentar incorporar una fila nueva de
pedidos de un cliente que no existe en la tabla de clientes. Las
reglas de integridad referencial nos lo impiden

Insertamos ahora dos nuevos clientes..

El resultado lo observamos en la figura

Ahora si que podemos incorporar una tupla nueva de pedido con
el cliente incorporado en la tabla de clientes


MODIFICACIN TABLAS

INSERT INTO Pedidos VALUES (' ' '2010/01/05' '7211545v'

USE Tablas5;

Dni VARCHAR(10),
Nombre VARCHAR(10),

PRIMARY KEY (Dni)
)ENGINE=InnoDB;

npedido INTEGER,
fecha DATE,
Cantidad DOUBLE,
FOREIGN KEY (cliente_Dni) REFERENCES Cliente(Dni) ON DELETE RESTRICT ON UPDATE CASCADE

)ENGINE=InnoDB;


INSERT INTO Pedidos VALUES ( 122 , 2010/01/05 ,7, 7211545v );

Agregamos una columna a la tabla con ALTER ADD

Cambiamos el nombre de una columna a la tabla con ALTER CHANGE

Modificamos el tipo de datos de una columna a la tabla con ALTER MODIFY

Eliminamos una columna a la tabla con ALTER DROP

Estamos tratando de borrar una tabla padre. Las restricciones de la BD
no nos permite al tener asociada la tabla una clave ajena

Es donde se haya la clave ajena

La tabla hija pedidos se puede borrar sin problemas.
Es donde se haya la clave ajena


INSERCIN

DATOS EN

TABLAS


USE Tablas6;

Dni VARCHAR(10),
Nombre VARCHAR(10),
PRIMARY KEY (Dni)
)ENGINE=InnoDB;

npedido INTEGER,
fecha DATE,
Cantidad DOUBLE,
FOREIGN KEY (cliente_Dni) REFERENCES Cliente(Dni) ON DELETE
RESTRICT ON UPDATE CASCADE
)ENGINE=InnoDB;

create table Personal(
Dni VARCHAR(10),
Nombre VARCHAR(10),
PRIMARY KEY (Dni)
)ENGINE=InnoDB;

INSERT INTO Personal VALUES ('7211541v','Juan','Garzn Rodriguez');
INSERT INTO Personal VALUES ('7211542v','Antonio','Marina Esquivel');
INSERT INTO Personal VALUES ('7211543v','Cesar','Bernal SanJose');
INSERT INTO Personal VALUES ('7211544v','Rodrigo','Alonso Vera');
INSERT INTO Personal VALUES ('7211546v','Maria','Lopez Gomez');

TABLA: Cliente

TABLA: Pedidos

TABLA: Personal

Con este comando que es un mezcla de INSERT INTO y SELECT conseguimos
meter en la tabla cliente 5 tuplas


ACTUALIZACIN

DATOS

EN TABLAS


USE Tablas7;

Dni VARCHAR(10),
Nombre VARCHAR(10),
PRIMARY KEY (Dni)
)ENGINE=InnoDB;

npedido INTEGER,
fecha DATE,
Cantidad DOUBLE,
FOREIGN KEY (cliente_Dni) REFERENCES Cliente(Dni) ON
DELETE RESTRICT ON UPDATE CASCADE
)ENGINE=InnoDB;

create table Personal(
Dni VARCHAR(10),
Nombre VARCHAR(10),
PRIMARY KEY (Dni)
)ENGINE=InnoDB;


INSERT INTO Cliente VALUES ('7211541v','Juan','Garzn Rodriguez');
INSERT INTO Cliente VALUES ('7211542v','Antonio','Marina Esquivel');
INSERT INTO Cliente VALUES ('7211543v','Cesar','Bernal SanJose');
INSERT INTO Cliente VALUES ('7211544v','Maria','Alonso Vera');
INSERT INTO Cliente VALUES ('7211546v','Maria','Lopez Gomez');

Vamos a probar el comando actualizar de SQL.
Para ello actualizamos todas las tuplas en la que aparece Maria

l b l l C i DNI

En este ejemplo vemos como es imposible actualizar los dos registros
en los que aparece en nombre el valor Carmen a un mismo DNI
ya que DNI tiene la restriccin de clave primaria


CONSULTAS

BSICAS

CON

SELECT

DROP SCHEMA IF EXISTS SELECT1;
CREATE SCHEMA SELECT1;
USE SELECT1;

create table Informacin_Ventas(
Tienda VARCHAR(10),
Ventas INTEGER,
Fecha DATE
)ENGINE=InnoDB;

create table Zona_Ventas(
Regin VARCHAR(10),
Tienda VARCHAR(10)
)ENGINE=InnoDB;

INSERT INTO Informacin_Ventas VALUES ('Madrid',1500,'2010/01/05');
INSERT INTO Informacin_Ventas VALUES ('Sevilla',250,'2010/01/08');
INSERT INTO Informacin_Ventas VALUES ('Barcelona',700,'2010/01/08');

INSERT INTO Zona_Ventas VALUES ('Centro-Sur','Madrid');
INSERT INTO Zona_Ventas VALUES ('Centro-Sur','Sevilla');
INSERT INTO Zona_Ventas VALUES ('Noreste','Zaragoza');
INSERT INTO Zona_Ventas VALUES ('Noreste','Barcelona');

TABLA: Informacion_ventas

TABLA:Zona_Ventas

Tabla: Informacin_Ventas

Seleccin Bsica:
Seleccionamos el nombre de todas las tiendas


Seleccin Bsica:

De esta forma eliminamos los duplicados que genera la consulta SELECT


Seleccin Condicional Simple:

Tiendas cuyas ventas son mayores de 1000

INSERT INTO Z V t VALUES ('C t

USE SELECT2;

Tienda VARCHAR(10),
Ventas INTEGER,
Fecha DATE
)ENGINE=InnoDB;

Regin VARCHAR(10),
Tienda VARCHAR(10)
)ENGINE=InnoDB;

INSERT INTO Informacin_Ventas VALUES ('Cuenca',300,'2010/01/07');



Seleccin Condicional Simple Compuesta:

Tiendas cuyas ventas son mayores de 1000 las ventas estn
comprendidas entre 275 y 500


Seleccin Tuplas en Funcin de Valores (IN):
Informacin completa de lasTiendas de Madrid y Sevilla


Seleccin Bsqueda de Patrones (LIKE):
Seleccion de tuplas que contengan un patrn

USE SELECT3;

Tienda VARCHAR(10),
Ventas INTEGER,
Fecha DATE
)ENGINE=InnoDB;

Regin VARCHAR(10),
Tienda VARCHAR(10)
)ENGINE=InnoDB;




Seleccin Ordenacin de Resultados (ORDER BY):
Seleccin de Tiendas ordenadas por el volumen de ventas en
Orden descendente


Seleccin Ordenacin de Resultados (ORDER BY):
En este ejemplo se clasifican las tuplas en primer lugar en orden
descendente del campo Ventas y luego si hay tuplas del mismo valor por
orden descentente de fecha

USE SELECT4;

Tienda VARCHAR(10),
Ventas INTEGER,
Fecha DATE
)ENGINE=InnoDB;

Regin VARCHAR(10),
Tienda VARCHAR(10)
)ENGINE=InnoDB;



S l i F i A it ti
( i t l l h ) bt i d l i ( t bl )


Seleccin Funciones Aritmticas:
Seleccionar todas las tuplas de la tabla Informacin_Ventas
(ya que no existe clausula when) , obteniendo una relacion(una tabla).
Luego proyectamos por el campo Ventas y hacemos una operacin.


Seleccin Funciones Aritmticas:
Nmero de Tuplas de una tabla

S l i F i A it ti G


Seleccin Funciones Aritmticas con Grupos:
Ventas agrupadas por tiendas


Seleccin Funciones Aritmticas con Grupos:

Ventas agrupadas por tiendas de las tiendas cuyas ventas
Son superiores a 1500


Seleccin con Grupos:

Esta consulta no tendra mucho sentido ya en un grupo la fecha de
cada tupla es diferente

La condicin que aplica HAVING tiene que ser un operador
que abarque a todos los miembros del grupo. Si se refiere a un
campo que puede ser diferente en los miembros del grupo no funciona

Tiendas y suma de ventas agrupadas por iguales valores de tienda y ventas


Suma de las ventas totales de las tiendas agrupadas por el nombre
de Madrid


Mximo de ventas de las tiendas agrupadas por el nombre


JOIN

NATURAL

CON

SELECT

V t INTEGER
INSERT INTO I f i V VA UES ('M d id' 1 00 '2010/01/0 ')
');

DROP SCHEMA IF EXISTS JOIN1;
CREATE SCHEMA JOIN1;
USE JOIN1;
Tienda VARCHAR(10),
Ventas INTEGER,
Fecha DATE
)ENGINE=InnoDB;

Regin VARCHAR(10),
Tienda VARCHAR(10)
)ENGINE=InnoDB;



TABLA: Informacion_ventas
TABLA:Zona_Ventas

Join Natural: Ventas
por Regiones


CONSULTAS ANIDADAS

Consulta Anidada:

TABLA:Zona_Ventas TABLA: Informacion_ventas

Consulta Anidada:

Ventas de todas las tiendas de la regin Noreste

Consulta join equivalente a anidada:
Ventas de todas las tiendas de la regin Noreste

INSERT INTO Z V VALUES ('N ' 'B l ')

DROP SCHEMA IF EXISTS CASE1;
CREATE SCHEMA CASE1;
USE CASE1;

Tienda VARCHAR(10),
Ventas INTEGER,
Fecha DATE
)ENGINE=InnoDB;

Regin VARCHAR(10),
Tienda VARCHAR(10)
)ENGINE=InnoDB;



Utilizacin comando case:

Modificacin de la columna Ventas en funcin del valor

INSERT INTO V i d VA UES ('B l ' 1 00 '2010/01/08')

DROP SCHEMA IF EXISTS UNION1;
CREATE SCHEMA UNION1;
USE UNION1;

create table Ventas_tienda(
Tienda VARCHAR(10),
Ventas INTEGER,
Fecha DATE
)ENGINE=InnoDB;

create table Ventas_Internet(
Fecha DATE,
Ventas INTEGER
)ENGINE=InnoDB;

INSERT INTO Ventas_tienda VALUES ('Madrid',1500,'2010/01/05');
INSERT INTO Ventas_tienda VALUES ('Sevilla',250,'2010/01/08');
INSERT INTO Ventas_tienda VALUES ('Madrid',300,'2010/01/07');
INSERT INTO Ventas_tienda VALUES ('Barcelona',1500,'2010/01/08');

INSERT INTO Ventas_Internet VALUES ('2010/01/07',250);

83 de
4
29/05/2013 04:19 p.m.

84 de
4
29/05/2013 04:19 p.m.

EJEMPLOS

Ejemplo completo: Empleados.

Diagrama entidad relacin:

nombreP

apellido1

apellido2

dni
nombre

sueldo

numDept
nombreDept

lugares

supervisor

empleados
pertenecia
n
1

departamentos

supervisado
1
n

dirige

1

fecha

1

controla

supervisa
n

n

trabaja en

m
n
proyectos

hijos

nombre

fecha
numHoras

numP

nombre
lugar
85 de
4
29/05/2013 04:19 p.m.

Modelo relacin

empleados

dni nombre apellido1 appellido2 sueldo numD dniSupervisor

departamentos

numDept nombreDept dniJefe fecha

proyectos

numP nombre lugar numDept

trabajaEn

dni numP numH

hijos

dni nombre fecha

lugaresDpto

Consultas:
numD lugar
1. Ver todos los datos de la tabla empleados.
2. Seleccionar todos los datos de los empleados del depto 5.
3. Nombre y apellidos de los empleados que trabajan en el depto 5 y que tienen sueldo >100.000.
4. Nombre y apellidos de los empleados que trabajan en el depto 1, 2 3.
5. Nombre y apellidos empleados que trabajan en el departamento: "investigacin.
6. Nombre de los empleados con al menos dos hijos.
7. Para cada empleado su nombre y el nombre del supervisor.
8. Para cada proyecto nmero de proyecto, nombre y nmero de empleados que trabajan en l.
9. Empleados que tienen el mismo sueldo y trabajan en el mismo departamento que algn garcia.
10. Nmero de proyecto en que trabaja garcia como jefe de proyecto.
11. Nombre y apellido de los empleados con algn hijo.
12. Nombre y apellido de los empleados sin hijos.
13. Nombre y apellido de jefes de departamento con al menos un hijo.
14. Nombre y apellido de los empleados que trabajan en todos los proyectos controlados por el
departamento 5.
15. Empleados que no tiene supervisor.
16. Nombre y apellido de los empleados con al menos dos hijos.
17. Para cada proyecto: nmero de proyecto, nombre y nmero de empleados que trabajan en l.
18. Para cada departamento con ms de tres empleados nmero de departamento y nmero de empleados
con sueldo mayor a 100.000.
86 de
4
29/05/2013 04:19 p.m.

Pasar a SQL
SQL:
Lenguaje de definicin de datos
Lenguaje de definicion de almacenamiento
Lenguaje de manipulacion de datos
Lenguaje de definicion de vistas

mysql> source filename
mysql> \. filename

empleados.sql
-- LENGUAJE DE DEFINICION DE DATOS:
--
-- Tipos de datos
-- Cadenas de caracteres
-- longitud fija char(m) 1..255 rellena con blancos
-- long varibale varchar(m)
-- TINYBLOB 255
-- TEXT 65,535 char string
-- BLOB[(M)] 65,535 binary string
-- MEDIUMBLOB 16,777,215
-- LONGTEXT 4,294,967,295
-- LONGTEXT 4,294,967,295
-- ENUM('value1','value2',...)
-- SET('value1','value2',...)
--
-- Numericos
-- enteros
-- int o integer, unsigned
-- TINYINT[(M)] [UNSIGNED] [ZEROFILL] -127 a 128
-- SMALLINT[(M)] [UNSIGNED] [ZEROFILL] -32768 to 32767
-- MEDIUMINT[(M)] [UNSIGNED] [ZEROFILL] -8388608 to 8388607
-- INT[(M)] [UNSIGNED] [ZEROFILL] -2147483648 to 2147483647
-- BIGINT[(M)] [UNSIGNED] [ZEROFILL] -9223372036854775808 to
9223372036854775807
-- reales
-- float[(m,d)]
-- (4,2) 4 espacios a lo sumo 2 son decimales
-- EJ
-- 42.35 bien
-- 325.54 mal redondea a 325.5
-- FLOAT[(M,D)] [UNSIGNED] [ZEROFILL] -3.402823466E+38 to -
1.175494351E-38, 0, and 1.175494351E-38 to 3.402823466E+38
-- DOUBLE[(M,D)] [UNSIGNED] [ZEROFILL] -1.7976931348623157E+308 to
-2.2250738585072014E-308, 0, and 2.2250738585072014E-308 to 1.7976931348623157E+308
-- DECIMAL[(M[,D])] [UNSIGNED] [ZEROFILL]
-- BOOL, BOOLEAN
--
--
-- DATE '1000-01-01' to '9999-12-31'
87 de
4
29/05/2013 04:19 p.m.

-- yyyy-mm-dd
-- 1999-02-03 o 19990203
-- DATETIME '1000-01-01 00:00:00' to '9999-12-31 23:59:59'
-- 'YYYY-MM-DD HH:MM:SS'
-- TIME '-838:59:59' to '838:59:59'
-- hh:mm:ss
-- 12:45:30
-- NULL pertenece a todos los tipos de datos en fichero \N
--
-- Modificadores:
-- AUTO_INCREMENT
-- DEFAULT value
-- NOT NULL
-- PRIMARY KEY
-- UNIQUE
-- ON DELETE action1 ON UPDATE action2
-- action:
-- SET NULL, SET DEFAULT, CASCADE
-- CASCADE se eliminan todos las tuplas de empleados que hagan referencia al departamento
-- y se continua en cascada.
--
-- Databases:
-- CREATE DATABASE nombre;
-- USE nombreDB;
-- GRANT ALL PRIVLILEGES ON nombreDB.* TO 'albertoe'@'%' IDENTIFIED BY 'clave';
--
-- Tablas:
-- CREATE TABLE nombre(listaCampos);
--
-- Creacion de tipos de datos:
-- CREATE DOMAIN tipoDNI AS char(8);
--
-- Modificacin de tablas:
-- ALTER TABLE empleados ADD peso int1 DEFAULT 0;
-- ALTER TABLE empleados ADD (peso int1 DEFAULT 0,aos int);
-- ALTER TABLE empleados ALTER peso DEFAULT 1;
-- ALTER TABLE empleados DROP dniSupervisor;
--
-- Borrado:
-- DROP DATABASE empleadosDB;
-- DROP TABLE departamentos RESTRICT; solo si ninguna otra hace referencia
-- DROP TABLE departamentos CASCADE; en cascada todas las que hacen referencia
--
-- Mostrar:
-- SHOW DATABASES;
-- SHOW TABLES;
-- DESCRIBE nombreTabla;
-- SHOW COLUMNS FROM nombreTabla;
88 de
4
29/05/2013 04:19 p.m.

CREATE DATABASE empleadosDB;
USE empleadosDB;
CREATE TABLE empleados(
dni char(8),
nombre varchar(20),
apellido1 varchar(20),
sueldo float(12,2),
numD int UNSIGNED,
dniSupervisor char(8),
PRIMARY KEY(dni)
-- ,FOREIGN KEY(dniSupervisor) REFERENCES empleados(dni) ON DELETE CASCADE ON
UPDATE CASCADE
);
CREATE TABLE departamentos(
numDept int UNSIGNED,
nombreDept varchar(20),
dniJefe char(8),
fecha date,
PRIMARY KEY(numDept),
FOREIGN KEY(dniJefe) REFERENCES empleados(dni) ON DELETE CASCADE ON UPDATE
CASCADE
);
CREATE TABLE proyectos(
numP int UNSIGNED,
nombre varchar(20),
lugar varchar(10),
PRIMARY KEY(numP),
FOREIGN KEY(numDept) REFERENCES departamentos(numDept) ON DELETE CASCADE ON
UPDATE CASCADE
);
CREATE TABLE trabajaEn(
dni char(8),
numP int UNSIGNED,
numH int UNSIGNED,
PRIMARY KEY(dni,numP),
FOREIGN KEY(dni) REFERENCES empleados(dni) ON DELETE CASCADE ON UPDATE
CASCADE,
FOREIGN KEY(numP) REFERENCES proyectos(numP) ON DELETE CASCADE ON UPDATE
CASCADE
);
CREATE TABLE hijos(
dni char(8),
nombre varchar(20),
fecha date,
PRIMARY KEY(dni,nombre),
FOREIGN KEY(dni) REFERENCES empleados(dni) ON DELETE CASCADE ON UPDATE CASCADE
89 de
4
29/05/2013 04:19 p.m.

);
CREATE TABLE lugaresDpto(
numD int UNSIGNED,
lugar varchar(20),
PRIMARY KEY(numD,lugar),
FOREIGN KEY(numD) REFERENCES departamentos(numDept) ON DELETE CASCADE ON
UPDATE CASCADE
);
90 de
4
29/05/2013 04:19 p.m.

loadEmpleados.sql
-- LENGUAJE DE ALMACENAMIENTO
--
-- Carga de ficheros:
-- LOAD DATA LOCAL INFILE ".\\nombreFich" INTO TABLE nombreTabla;
-- LOAD DATA LOCAL INFILE ".\\nombreFich" INTO TABLE nombreTabla
-- LINES TERMINATED BY '\r\n';
--
-- Insercion en tablas:
-- INSERT INTO
-- INSERT INTO pet VALUES
-- ('Fluffy', 'Harold', 'cat', 'f', '1993-02-04', NULL);
-- ('Fluffy', 'Harold', 'cat', 'f', '1993-02-04', NULL),
-- ('Moo, 'Harold', 'cat', 'f', '1993-02-04', NULL);
--
-- Actualizacion de datos:
-- UPDATE test SET
-- neme='busbunny'
-- WHERE name='patito';
-- UPDATE empleados SET
-- sueldo=sueldo+100 , categoria=categoria+1
-- WHERE categoria=13;
-- Borrado:
-- DELETE FROM empleados; --borra el contenido completo de una tabla
-- DELETE FROM nombreTabla WHERE consulta;

USE empleadosDB;
LOAD DATA LOCAL INFILE '.\\empleados.dat' INTO TABLE empleados;
LOAD DATA LOCAL INFILE '.\\departamentos.dat' INTO TABLE departamentos;
LOAD DATA LOCAL INFILE '.\\proyectos.dat' INTO TABLE proyectos;
LOAD DATA LOCAL INFILE ".\\hijos.dat" INTO TABLE hijos;
LOAD DATA LOCAL INFILE ".\\trabajaEn.dat" INTO TABLE trabajaEn;

INSERT INTO lugaresDpto VALUES
(1,'madrid'),
(1,'palencia'),
(2,'sevilla'),
(3,'granada'),
(4,'jaen'),
(5,'cordoba'),
(2,'guadalajara'),
(1,'almeria');

ALTER TABLE empleados
ADD CONSTRAINT atributosFK FOREIGN KEY(dniSupervisor)
REFERENCES empleados(dni) ON DELETE CASCADE ON UPDATE CASCADE;
91 de
4
29/05/2013 04:19 p.m.

conEmpleados.sql
-- LENGUAJE DE MANIPULACIN DE DATOS
--
--
-- SELECT what_to_select
-- FROM which_table
-- WHERE conditions_to_satisfy;
--
-- SELECT * FROM pet WHERE name LIKE 'b%';
--
-- SELECT [DISTINCT] columnas
-- FROM tablas
-- WHERE condiciones
-- GROUP BY atributos
-- HAVING condicion de seleccion de grupos
-- ORDER BY <columnas [ASC|DESC]>
--
-- SELECT *
-- FROM nombreTabla
-- INTO OUTFILE "C:\fichero";
--
-- Condiciones:
-- BETWEEN '1981-01-03' AND '1983-02-02'
-- [NOT] IN (300,400)
-- [NOT] IN ('a','z')
-- IS NULL;
-- IS NOT NULL;
--
-- Operaciones:
-- NOT !, AND &&, OR ||
-- =, !=, <>, <=, >=, <, >
--
-- SELECT name, birth, CURDATE(),
-- (YEAR(CURDATE())-YEAR(birth))
-- - (RIGHT(CURDATE(),5)<RIGHT(birth,5))
-- AS age
-- FROM pet;
--
-- Declaracion de variables:
-- SELECT @last := LAST_INSERT_ID();
--
-- SELECT *
-- FROM tabla1 LEFT JOIN tabla2 ON tabla1.campo1 = tabla2.campo2
-- WHERE condiciones;
--
-- SELECT *
-- FROM tabla1 AS t1 LEFT JOIN tabla2 AS t2 ON t1.campo1 = t2.campo2
-- WHERE condicones;
--
-- Funciones:
92 de
4
29/05/2013 04:19 p.m.

-- Headers() pone cabeceras
-- AVG(columna) calcula la media
--
-- Union, interseccin, diferencia:
-- UNION, INTERSEC, EXCEPT
USE empleadosDB;
-- Ver todos los datos de la tabla empleados;
SELECT * FROM empleados;

-- Seleccinar todos los datos de los empleados del depto 5
SELECT *
FROM empleados
WHERE numD=5;

-- Nombre y apellidos de los empleados que trabajan en el depto
-- 5 y que tienen sueldo >100.000 euros
SELECT nombre, apellido1, apellido2
FROM empleados
WHERE numD=5 AND sueldo>100000;

-- Nombre y apellidos de los empleados que trabajan en el depto 1, 2 3.
FROM empleados
WHERE numD IN (1,2,3);

-- Nombre y apellidos empleados que trabajan en el departamento: "investigacin"
SELECT nombre,apellido1,apellido2
FROM empleados,departamentos
WHERE nombreDept="investigacion" AND numD=numDept;
-- otra forma
SELECT nombre,apellido1
FROM empleados JOIN departamentos ON numDept=numD
WHERE nombreDept="investigacion";

-- Nombre de los empleados con al menos dos hijos
SELECT empleados.nombre
FROM empleados, hijos h1, hijos h2
WHERE empleados.dni=h1.dni AND empleados.dni=h2.dni AND h1.nombre!=h2.nombre;

-- Para cada empleado su nombre y el nombre del supervisor.
SELECT e.nombre, s.nombre
FROM empleados e, empleados s
WHERE e.dniSupervisor=s.dni;
93 de
4
29/05/2013 04:19 p.m.

-- Uniones
-- Numero de proyectos en los que tabaja algn "garcia"
-- o algn proyecto de ese departamento trabaje algn "garcia"
(SELECT numP
FROM empleados, trabajaEn
WHERE apellido1="garcia" AND empleados.dni=trabajaEn.dni)
UNION ALL {ALL: para mantener duplicados}
(SELECT numP
FROM empleados, departamentos, proyectos
WHERE apellido1="garcia" AND proyectos.numDept=departamentos.numDept AND dniJefe=dni);

--
SELECT DISTINCT numP
FROM proyectos
WHERE numP IN (SELECT numP
OR
numP IN (SELECT numP
FROM empleados,departamentos,proyectos
WHERE apellido1="garcia" AND proyectos.numDept=proyectos.numDept AND dniJefe=dni);

-- Empleados que tienen el mismo sueldo y trabajan en el mismo departamento que algun "garcia"
SELECT dni
FROM empleados
WHERE (sueldo,numD) IN
(SELECT sueldo,numD
FROM empleados
WHERE apellido1="garcia");

--es lo mismo
SELECT e1.dni
FROM empleados e1,empleados e2
WHERE E2.apellido1="garcia" AND E1.sueldo=E2.sueldo AND E1.numD=E2.numD;

-- En vez de IN se puede colocar un operador <,<=,>,>=,!=,<>,=, ANY, SOME, ALL,

--empleados con sueldo mayor que algun lopez sueldo>ANY
--empleados con sueldo mayor que todos lopez sueldo>ALL

--Numero de proyecto en que trabaja garcia como jefe de proyecto
SELECT numP
FROM proyectos
WHERE numP IN
(SELECT numDept
FROM departamentos
WHERE dniJefe IN
(SELECT dni
FROM empleados
94 de
4
29/05/2013 04:19 p.m.

WHERE apellido1="garcia"));

-- EXITS comprobar si existen tuplas
-- Nombre y apellido de los empleados con algun hijo
FROM empleados
WHERE EXISTS (SELECT *
FROM hijos
WHERE empleados.dni=hijos.dni);

-- Nombre y apellido de los empleados sin hijos
FROM empleados
WHERE NOT EXISTS
(SELECT *
FROM hijos
--otra forma
FROM empleados
WHERE DNI NOT IN
(SELECT dni
FROM hijos);
--otra forma
FROM empleados
EXCEPT
(SELECT nombre, apellido1
FROM empleados, hijos

-- Nombre y apellido de jefes de departamento con al menos un hijo
SELECT nombre, apellido1
FROM empleados
WHERE dni IN
(SELECT dniJefe
FROM departamentos
WHERE dniJefe IN
(SELECT dni
FROM hijos));
-- otra forma
FROM empleados
WHERE EXISTS
(SELECT *
FROM departamentos
WHERE dniJefe=dni)
AND EXISTS
(SELECT *
FROM hijos
95 de
4
29/05/2013 04:19 p.m.

WHERE empleados.dni=dni);

-- Nombre y apellido de los empleados que trabajan en todos los proyectos controlados por el departamento 5
FROM empleados
WHERE NOT EXISTS
(SELECT *
FROM proyectos p
WHERE p.numDept=5)
AND NOT EXISTS
(SELECT *
FROM trabajaEn, proyectos
WHERE empleados.dni=trabajaEn.dni AND proyectos.numP=trabajaEn.numP);

-- empleados que no tiene supervisor
SELECT *
FROM empleados
WHERE dniSupervisor IS NULL;
-- otra forma
SELECT *
FROM empleados
WHERE dniSupervisor NOT IN
(SELECT dni
FROM empleados);
-- otra forma
SELECT *
FROM empleados e
WHERE NOT EXISTS
(SELECT *
FROM empleados
WHERE e.dniSupervisor=dni);

-- FUNCIONES AGREGADAS
-- COUNT, SUM, MIN, MAX,ANG
-- COUNT cuenta los valores nulos, los demas los ignoran
-- cuando una tabla esta vacia COUNT devuelve 0 los demas NULL

-- Nombre y apellido de los empleados con al menos dos hijos
FROM empleados
WHERE (SELECT COUNT(*)
FROM hijos
WHERE empleados.dni=dni)>=2;

--AGRUPANDO
SELECT numD,count(*),avg(sueldo)
FROM empleados
GROUP BY numD;
96 de
4
29/05/2013 04:19 p.m.

-- Para cada proyecto numero de proyecto, nombre y numero de empleados que trabajan en el
SELECT numP, nombre, count(*)
FROM proyectos NATURAL JOIN trabajaEn
GROUP BY numP,nombre;

-- Para cada departamento con mas de tres empleados num de departamento
-- y numero de empleados con sueldo mayor a 100.000 euros
SELECT numD,count(*)
FROM empleados
WHERE sueldo>100000
GROUP BY numD
HAVING count(*)>3;

--ORDENando por defecto ascendente
SELECT numD,nombre,apellido1
FROM empleados
ORDER BY numD ASC, nombre DESC,apellido1
97 de
4
29/05/2013 04:19 p.m.

vistasEmpleados.sql
-- LENGUAJE DE CREACION DE VISTAS:
--
-- Creacion de vistas:
-- CREATE
-- VIEW view_name [(column_list)]
-- AS select_statement
--
-- Modificacin de vistas:
-- ALTER
--
-- Borrado de vistas:
-- DROP
-- VIEW view_name
-- [RESTRICT | CASCADE] USE
empleadosDB;
-- Creacin de una vista:

CREATE VIEW
test
AS SELECT * FROM
empleados;

CREATE
VIEW sueldosAnuales
AS SELECT dni, sueldo*12 AS sueldoAnual
FROM empleados;

PRACTICA: Empleados.

Diagrama entidad relacin:

nombreP

apellido1

apellido2

dni
nombre

sueldo

numDept
nombreD
ept
98 de
4
29/05/2013 04:19 p.m.

lugares

supervisor

empleados
pertenecia
n
1

departamentos

supervisado
1
n

dirige

1

fecha

1

controla

supervisa
n

n

trabaja en

m
n
proyectos

hijos

nombre

fecha
numHoras

numP

nombre
lugar
99 de
4
29/05/2013 04:19 p.m.

Modelo relacin

empleados

dni nombre apellido1 appellido2 sueldo numD dniSupervisor

departamentos

numDept nombreDept dniJefe fecha

proyectos

numP nombre lugar numDept

trabajaEn

dni numP numH

hijos

dni nombre fecha

lugaresDpto

Consultas:
numD lugar
1. Ver todos los datos de la tabla empleados.
2. Seleccionar todos los datos de los empleados del depto 5.
3. Nombre y apellidos de los empleados que trabajan en el depto 5 y que tienen sueldo >100.000.
4. Nombre y apellidos de los empleados que trabajan en el depto 1, 2 3.
5. Nombre y apellidos empleados que trabajan en el departamento: "investigacin.
6. Nombre de los empleados con al menos dos hijos.
7. Para cada empleado su nombre y el nombre del supervisor.
8. Para cada proyecto nmero de proyecto, nombre y nmero de empleados que trabajan en l.
9. Empleados que tienen el mismo sueldo y trabajan en el mismo departamento que algn garcia.
10. Nmero de proyecto en que trabaja garcia como jefe de proyecto.
11. Nombre y apellido de los empleados con algn hijo.
12. Nombre y apellido de los empleados sin hijos.
13. Nombre y apellido de jefes de departamento con al menos un hijo.
14. Nombre y apellido de los empleados que trabajan en todos los proyectos controlados por el
departamento 5.
15. Empleados que no tiene supervisor.
16. Nombre y apellido de los empleados con al menos dos hijos.
17. Para cada proyecto: nmero de proyecto, nombre y nmero de empleados que trabajan en l.
18. Para cada departamento con ms de tres empleados nmero de departamento y nmero de empleados
con sueldo mayor a 100.000.
100 de
4
29/05/2013 04:19 p.m.

Pasar a SQL
SQL:
Lenguaje de definicin de datos
Lenguaje de definicion de almacenamiento
Lenguaje de manipulacion de datos
Lenguaje de definicion de vistas

mysql> source filename
mysql> \. filename

empleados.sql
-- LENGUAJE DE DEFINICION DE DATOS:
--
-- Tipos de datos
-- Cadenas de caracteres
-- longitud fija char(m) 1..255 rellena con blancos
-- long varibale varchar(m)
-- TINYBLOB 255
-- TEXT 65,535 char string
-- BLOB[(M)] 65,535 binary string
-- LONGTEXT 4,294,967,295
-- LONGTEXT 4,294,967,295
-- ENUM('value1','value2',...)
-- SET('value1','value2',...)
--
-- Numericos
-- enteros
-- int o integer, unsigned
-- TINYINT[(M)] [UNSIGNED] [ZEROFILL] -127 a 128
-- SMALLINT[(M)] [UNSIGNED] [ZEROFILL] -32768 to 32767
-- MEDIUMINT[(M)] [UNSIGNED] [ZEROFILL] -8388608 to 8388607
-- INT[(M)] [UNSIGNED] [ZEROFILL] -2147483648 to 2147483647
-- BIGINT[(M)] [UNSIGNED] [ZEROFILL] -9223372036854775808 to
9223372036854775807
-- reales
-- float[(m,d)]
-- (4,2) 4 espacios a lo sumo 2 son decimales
-- EJ
-- 42.35 bien
-- 325.54 mal redondea a 325.5
-- FLOAT[(M,D)] [UNSIGNED] [ZEROFILL] -3.402823466E+38 to -
1.175494351E-38, 0, and 1.175494351E-38 to 3.402823466E+38
-- DOUBLE[(M,D)] [UNSIGNED] [ZEROFILL] -1.7976931348623157E+308 to
-2.2250738585072014E-308, 0, and 2.2250738585072014E-308 to 1.7976931348623157E+308
-- DECIMAL[(M[,D])] [UNSIGNED] [ZEROFILL]
-- BOOL, BOOLEAN
--
--
-- DATE '1000-01-01' to '9999-12-31'
101 de
4
29/05/2013 04:19 p.m.

-- yyyy-mm-dd
-- 1999-02-03 o 19990203
-- DATETIME '1000-01-01 00:00:00' to '9999-12-31 23:59:59'
-- 'YYYY-MM-DD HH:MM:SS'
-- TIME '-838:59:59' to '838:59:59'
-- hh:mm:ss
-- 12:45:30
-- NULL pertenece a todos los tipos de datos en fichero \N
--
-- Modificadores:
-- AUTO_INCREMENT
-- DEFAULT value
-- NOT NULL
-- PRIMARY KEY
-- UNIQUE
-- ON DELETE action1 ON UPDATE action2
-- action:
-- SET NULL, SET DEFAULT, CASCADE
-- CASCADE se eliminan todos las tuplas de empleados que hagan referencia al departamento
-- y se continua en cascada.
--
-- Databases:
-- CREATE DATABASE nombre;
-- USE nombreDB;
-- GRANT ALL PRIVLILEGES ON nombreDB.* TO 'albertoe'@'%' IDENTIFIED BY 'clave';
--
-- Tablas:
-- CREATE TABLE nombre(listaCampos);
--
-- Creacion de tipos de datos:
-- CREATE DOMAIN tipoDNI AS char(8);
--
-- Modificacin de tablas:
-- ALTER TABLE empleados ADD peso int1 DEFAULT 0;
-- ALTER TABLE empleados ADD (peso int1 DEFAULT 0,aos int);
-- ALTER TABLE empleados ALTER peso DEFAULT 1;
-- ALTER TABLE empleados DROP dniSupervisor;
--
-- Borrado:
-- DROP DATABASE empleadosDB;
-- DROP TABLE departamentos RESTRICT; solo si ninguna otra hace referencia
-- DROP TABLE departamentos CASCADE; en cascada todas las que hacen referencia
--
-- Mostrar:
-- SHOW DATABASES;
-- SHOW TABLES;
-- DESCRIBE nombreTabla;
-- SHOW COLUMNS FROM nombreTabla;
102 de
4
29/05/2013 04:19 p.m.

CREATE DATABASE empleadosDB;
USE empleadosDB;
CREATE TABLE empleados(
dni char(8),
nombre varchar(20),
sueldo float(12,2),
numD int UNSIGNED,
dniSupervisor char(8),
PRIMARY KEY(dni)
-- ,FOREIGN KEY(dniSupervisor) REFERENCES empleados(dni) ON DELETE CASCADE ON
UPDATE CASCADE
);
CREATE TABLE departamentos(
nombreDept varchar(20),
dniJefe char(8),
fecha date,
PRIMARY KEY(numDept),
FOREIGN KEY(dniJefe) REFERENCES empleados(dni) ON DELETE CASCADE ON UPDATE
CASCADE
);
CREATE TABLE proyectos(
numP int UNSIGNED,
nombre varchar(20),
lugar varchar(10),
PRIMARY KEY(numP),
FOREIGN KEY(numDept) REFERENCES departamentos(numDept) ON DELETE CASCADE ON
UPDATE CASCADE
);
CREATE TABLE trabajaEn(
dni char(8),
numP int UNSIGNED,
numH int UNSIGNED,
PRIMARY KEY(dni,numP),
FOREIGN KEY(dni) REFERENCES empleados(dni) ON DELETE CASCADE ON UPDATE
CASCADE,
FOREIGN KEY(numP) REFERENCES proyectos(numP) ON DELETE CASCADE ON UPDATE
CASCADE
);
CREATE TABLE hijos(
dni char(8),
nombre varchar(20),
fecha date,
PRIMARY KEY(dni,nombre),
FOREIGN KEY(dni) REFERENCES empleados(dni) ON DELETE CASCADE ON UPDATE CASCADE
103 de
4
29/05/2013 04:19 p.m.

);
CREATE TABLE lugaresDpto(
numD int UNSIGNED,
lugar varchar(20),
PRIMARY KEY(numD,lugar),
FOREIGN KEY(numD) REFERENCES departamentos(numDept) ON DELETE CASCADE ON
UPDATE CASCADE
);
104 de
4
29/05/2013 04:19 p.m.

loadEmpleados.sql
-- LENGUAJE DE ALMACENAMIENTO
--
-- Carga de ficheros:
-- LOAD DATA LOCAL INFILE ".\\nombreFich" INTO TABLE nombreTabla;
-- LOAD DATA LOCAL INFILE ".\\nombreFich" INTO TABLE nombreTabla
-- LINES TERMINATED BY '\r\n';
--
-- Insercion en tablas:
-- INSERT INTO
-- ('Fluffy', 'Harold', 'cat', 'f', '1993-02-04', NULL);
-- ('Fluffy', 'Harold', 'cat', 'f', '1993-02-04', NULL),
-- ('Moo, 'Harold', 'cat', 'f', '1993-02-04', NULL);
--
-- Actualizacion de datos:
-- UPDATE test SET
-- neme='busbunny'
-- WHERE name='patito';
-- UPDATE empleados SET
-- sueldo=sueldo+100 , categoria=categoria+1
-- WHERE categoria=13;
-- Borrado:
-- DELETE FROM empleados; --borra el contenido completo de una tabla
-- DELETE FROM nombreTabla WHERE consulta;

USE empleadosDB;
LOAD DATA LOCAL INFILE '.\\empleados.dat' INTO TABLE empleados;
LOAD DATA LOCAL INFILE '.\\departamentos.dat' INTO TABLE departamentos;
LOAD DATA LOCAL INFILE '.\\proyectos.dat' INTO TABLE proyectos;
LOAD DATA LOCAL INFILE ".\\hijos.dat" INTO TABLE hijos;
LOAD DATA LOCAL INFILE ".\\trabajaEn.dat" INTO TABLE trabajaEn;

INSERT INTO lugaresDpto VALUES
(1,'madrid'),
(1,'palencia'),
(2,'sevilla'),
(3,'granada'),
(4,'jaen'),
(5,'cordoba'),
(2,'guadalajara'),
(1,'almeria');

ALTER TABLE empleados
ADD CONSTRAINT atributosFK FOREIGN KEY(dniSupervisor)
REFERENCES empleados(dni) ON DELETE CASCADE ON UPDATE CASCADE;
105 de
4
29/05/2013 04:19 p.m.

conEmpleados.sql
-- LENGUAJE DE MANIPULACIN DE DATOS
--
--
-- SELECT what_to_select
-- FROM which_table
-- WHERE conditions_to_satisfy;
--
-- SELECT * FROM pet WHERE name LIKE 'b%';
--
-- SELECT [DISTINCT] columnas
-- FROM tablas
-- WHERE condiciones
-- GROUP BY atributos
-- HAVING condicion de seleccion de grupos
-- ORDER BY <columnas [ASC|DESC]>
--
-- SELECT *
-- FROM nombreTabla
-- INTO OUTFILE "C:\fichero";
--
-- Condiciones:
-- BETWEEN '1981-01-03' AND '1983-02-02'
-- [NOT] IN (300,400)
-- [NOT] IN ('a','z')
-- IS NULL;
-- IS NOT NULL;
--
-- Operaciones:
-- NOT !, AND &&, OR ||
-- =, !=, <>, <=, >=, <, >
--
-- SELECT name, birth, CURDATE(),
-- (YEAR(CURDATE())-YEAR(birth))
-- - (RIGHT(CURDATE(),5)<RIGHT(birth,5))
-- AS age
-- FROM pet;
--
-- Declaracion de variables:
-- SELECT @last := LAST_INSERT_ID();
--
-- SELECT *
-- FROM tabla1 LEFT JOIN tabla2 ON tabla1.campo1 = tabla2.campo2
-- WHERE condiciones;
--
-- SELECT *
-- FROM tabla1 AS t1 LEFT JOIN tabla2 AS t2 ON t1.campo1 = t2.campo2
-- WHERE condicones;
--
-- Funciones:
106 de
4
29/05/2013 04:19 p.m.

-- Headers() pone cabeceras
-- AVG(columna) calcula la media
--
-- Union, interseccin, diferencia:
-- UNION, INTERSEC, EXCEPT
USE empleadosDB;
-- Ver todos los datos de la tabla empleados;
SELECT * FROM empleados;

-- Seleccinar todos los datos de los empleados del depto 5
SELECT *
FROM empleados
WHERE numD=5;

-- Nombre y apellidos de los empleados que trabajan en el depto
-- 5 y que tienen sueldo >100.000 euros
FROM empleados
WHERE numD=5 AND sueldo>100000;

-- Nombre y apellidos de los empleados que trabajan en el depto 1, 2 3.
FROM empleados
WHERE numD IN (1,2,3);

-- Nombre y apellidos empleados que trabajan en el departamento: "investigacin"
SELECT nombre,apellido1,apellido2
FROM empleados,departamentos
WHERE nombreDept="investigacion" AND numD=numDept;
-- otra forma
FROM empleados JOIN departamentos ON numDept=numD
WHERE nombreDept="investigacion";

-- Nombre de los empleados con al menos dos hijos
SELECT empleados.nombre
FROM empleados, hijos h1, hijos h2
WHERE empleados.dni=h1.dni AND empleados.dni=h2.dni AND h1.nombre!=h2.nombre;

-- Para cada empleado su nombre y el nombre del supervisor.
SELECT e.nombre, s.nombre
FROM empleados e, empleados s
WHERE e.dniSupervisor=s.dni;
107 de
4
29/05/2013 04:19 p.m.

-- Uniones
-- Numero de proyectos en los que tabaja algn "garcia"
-- o algn proyecto de ese departamento trabaje algn "garcia"
(SELECT numP
UNION ALL {ALL: para mantener duplicados}
(SELECT numP
FROM empleados, departamentos, proyectos
WHERE apellido1="garcia" AND proyectos.numDept=departamentos.numDept AND dniJefe=dni);

--
SELECT DISTINCT numP
FROM proyectos
WHERE numP IN (SELECT numP
OR
numP IN (SELECT numP
FROM empleados,departamentos,proyectos
WHERE apellido1="garcia" AND proyectos.numDept=proyectos.numDept AND dniJefe=dni);

-- Empleados que tienen el mismo sueldo y trabajan en el mismo departamento que algun "garcia"
SELECT dni
FROM empleados
WHERE (sueldo,numD) IN
(SELECT sueldo,numD
FROM empleados
WHERE apellido1="garcia");

--es lo mismo
SELECT e1.dni
FROM empleados e1,empleados e2
WHERE E2.apellido1="garcia" AND E1.sueldo=E2.sueldo AND E1.numD=E2.numD;

-- En vez de IN se puede colocar un operador <,<=,>,>=,!=,<>,=, ANY, SOME, ALL,

--empleados con sueldo mayor que algun lopez sueldo>ANY
--empleados con sueldo mayor que todos lopez sueldo>ALL

--Numero de proyecto en que trabaja garcia como jefe de proyecto
SELECT numP
FROM proyectos
WHERE numP IN
(SELECT numDept
FROM departamentos
WHERE dniJefe IN
(SELECT dni
FROM empleados
108 de
4
29/05/2013 04:19 p.m.

WHERE apellido1="garcia"));

-- EXITS comprobar si existen tuplas
-- Nombre y apellido de los empleados con algun hijo
FROM empleados
WHERE EXISTS (SELECT *
FROM hijos

-- Nombre y apellido de los empleados sin hijos
FROM empleados
WHERE NOT EXISTS
(SELECT *
FROM hijos
--otra forma
FROM empleados
WHERE DNI NOT IN
(SELECT dni
FROM hijos);
--otra forma
FROM empleados
EXCEPT
(SELECT nombre, apellido1
FROM empleados, hijos

-- Nombre y apellido de jefes de departamento con al menos un hijo
FROM empleados
WHERE dni IN
(SELECT dniJefe
FROM departamentos
WHERE dniJefe IN
(SELECT dni
FROM hijos));
-- otra forma
FROM empleados
WHERE EXISTS
(SELECT *
FROM departamentos
WHERE dniJefe=dni)
AND EXISTS
(SELECT *
FROM hijos
109 de
4
29/05/2013 04:19 p.m.

WHERE empleados.dni=dni);

-- Nombre y apellido de los empleados que trabajan en todos los proyectos controlados por el departamento 5
FROM empleados
WHERE NOT EXISTS
(SELECT *
FROM proyectos p
WHERE p.numDept=5)
AND NOT EXISTS
(SELECT *
FROM trabajaEn, proyectos
WHERE empleados.dni=trabajaEn.dni AND proyectos.numP=trabajaEn.numP);

-- empleados que no tiene supervisor
SELECT *
FROM empleados
WHERE dniSupervisor IS NULL;
-- otra forma
SELECT *
FROM empleados
WHERE dniSupervisor NOT IN
(SELECT dni
FROM empleados);
-- otra forma
SELECT *
FROM empleados e
WHERE NOT EXISTS
(SELECT *
FROM empleados
WHERE e.dniSupervisor=dni);

-- FUNCIONES AGREGADAS
-- COUNT, SUM, MIN, MAX,ANG
-- COUNT cuenta los valores nulos, los demas los ignoran
-- cuando una tabla esta vacia COUNT devuelve 0 los demas NULL

-- Nombre y apellido de los empleados con al menos dos hijos
FROM empleados
WHERE (SELECT COUNT(*)
FROM hijos
WHERE empleados.dni=dni)>=2;

--AGRUPANDO
SELECT numD,count(*),avg(sueldo)
FROM empleados
GROUP BY numD;
110 de
4
29/05/2013 04:19 p.m.

-- Para cada proyecto numero de proyecto, nombre y numero de empleados que trabajan en el
SELECT numP, nombre, count(*)
FROM proyectos NATURAL JOIN trabajaEn
GROUP BY numP,nombre;

-- Para cada departamento con mas de tres empleados num de departamento
-- y numero de empleados con sueldo mayor a 100.000 euros
SELECT numD,count(*)
FROM empleados
WHERE sueldo>100000
GROUP BY numD
HAVING count(*)>3;

--ORDENando por defecto ascendente
SELECT numD,nombre,apellido1
FROM empleados
ORDER BY numD ASC, nombre DESC,apellido1
111 de
4
29/05/2013 04:19 p.m.

vistasEmpleados.sql
-- LENGUAJE DE CREACION DE VISTAS:
--
-- Creacion de vistas:
-- CREATE
--
-- Modificacin de vistas:
-- ALTER
--
-- Borrado de vistas:
-- DROP
-- VIEW view_name
-- [RESTRICT |
CASCADE] USE
empleadosDB;
-- Creacin de una vista:

C
R
E
A
T
E
V
I
E
W

t
e
st
AS
SELECT
* FROM
empleado
s;

CREATE
VIEW sueldosAnuales
AS SELECT dni, sueldo*12 AS sueldoAnual
FROM
empleado
s;
112 de
4
29/05/2013 04:19 p.m.

U 4,5,6

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

U 4,5,6

Diunggah oleh

Hak Cipta:

Format Tersedia

<1

A1, A2, ..., An

Anda mungkin juga menyukai