Cur So BD Completo

CINFE
..
Es un conjunto de elementos
interrelacionados formando un
todo, que buscan alcanzar un
conjunto de objetivos.
Sistemas
naturales
Sistema planetario solar
Clasificaci
n de
Sistemas
Sistema circulatorio humano
Sistemas hechos por el

hombre
Sistema elctrico interconectado del sur
Sistema de Contabilidad
Conjunto de componentes interrelacionados que permiten

capturar, almacenar, procesar y distribuir la informacin para
apoyar la toma de decisiones y el control en una organizacin.
MEDIO AMBIENTE
PROVEEDORES
ORGANIZACION
SISTEMA DE INFORMACION
Entrada
de datos
Procesamiento
clasificacin
ordenamiento
clculos
retroalimentacin
ACCIONISTAS
Salida de la
informacin
COMPETIDORES
EN TES DEL ESTADO
CLIENTES
PRECISA
No es lo mismo el clculo de notas de un

alumno que las transacciones bancarias
a nivel de empresas multinacionales
OPORTUNA
La informacin resulta oportuna si esta

disponible en el momento requerido.
SIGNIFICATIVA
Ha de ser comprensible e importante. El

volmen mostrado debe ser lo justo.
COHERENTE
Los resultados obtenidos deben parecerse a lo

esperado y la relacin entre ellos debe ser lgica
SEGURA
Debe estar protegida contra daos fsicos,

errores lgicos o de accesos no autorizados.
Referenciales
Datos
Hardware
Software
Administrador
Usuarios
Directos
Estructurados
No estructurados ( texto, video, sonido )
CPU
Dispositivos perifricos
Sistema Operativo
Sistemas de gestin de Bases de Datos (SGBD)
Control de Comunicaciones
Aplicaciones especficas
Area de datos
Area Informtica
Informticos
No informticos
El grfico siguiente ilustra el comportamiento de la informacin,

dentro de las organizaciones, desde los puntos de vista de su
procesamiento y de su uso :
MAYOR
MENOR
MAYOR
Cantidad de
informacin
procesada y
generada
Cantidad de
informacin
utilizada en la
toma de
decisiones
MENOR
ETAPAS PARA LA GESTION DE DATOS

1. Aplicaciones con manejo de datos independiente
( Sistema de archivos )
En este enfoque las aplicaciones recurren a archivos separados para
cada aplicacin. Si se toma como ejemplo un Banco, bajo este criterio
se tendran por separado las operaciones bancarias en reas
funcionales, como cuenta corriente, ahorros y prestamos, donde cada
rea funcional tiene su propio archivo.
Si Juan Prez es un cliente del Banco y tiene cuenta corriente, cuenta
de ahorros y un prstamo que actualmente esta pagando, los datos
concernientes a Juan, estaran repetidos en los tres archivos, cada uno
de los cuales se actualiza con programas diferentes. Ver grfico sgte.
Archivo de cuentas corrientes

Num. Cliente
nombre cliente
2056
juan prez
Aplicacin 1
DatosCuentaCorriente
SISTEMA
DE
ARCHIVOS
........ ........ ....... .......
Archivo de Ahorros
Num. Cliente
2056
Datos de Ahorros
nombre cliente
juan prez
........ ........ ....... .......
redundancia
Aplicacin 3
Aplicacin 2
Archivo de prestamos
inconsistencia
Num. Cliente
2056
nombre cliente
juan prez
Datos de Prestamos
........ ........ ....... .......
2. Gestin centralizada de los datos

( Sistema de Bases de Datos )
Usando el ejemplo anterior a fin de facilitar la explicacin, se
establece un solo archivo de clientes para las tres cuentas y el
registro de cliente contiene los datos bsicos de cada cliente .
Tambien se crea un archivo para cada actividad bancaria : Cuenta
corriente, Cuenta de ahorros y Prestamos. Cada registro de
cliente contiene un campos especiales que lo asocian a los datos
de las cuentas y prestamos que posee este cliente.
Una de las caractersticas mas importantes es que los datos son
compartidos por todas las aplicaciones. Asi por ejemplo es
posible transferir dinero entre una cuenta y las otras, o preparar
un solo estado mensual para las tres cuentas de un cliente o de
todos los clientes. Ver grfico sgte.
Aplicacin 1
Archivo de Clientes
Num. Cliente
nombre cliente
2056
Archivo de
Cuentas
Corrientes
juan prez
Datos de
cuentas
corrientes
Archivo de
Cuentas de
Ahorros
Aplicacin 2
Datos de
cuentas de
ahorros
Datos de
Cuentas
Corrientes
Datos de
Cuentas de
Ahorros
Datos de
Prestamos
Archivo de
Prstamos
Datos de
prstamos
ENFOQUE
DE BASES
DE DATOS
Aplicacin 3
Alto nivel de redundancia

Un mismo dato puede estar repetido en diferentes
archivos.
Riesgo de inconsistencias
Las diversas copias de los mismos datos pueden no

coincidir ( por ejemplo el cambio de direccin de un cliente )
Uso excesivo de recursos humanos

Una alta proporcin de recurso humano, se dedica a
actividades de mantenimiento de software.
Las aplicaciones dependen de los archivos

Si se hacen cambios en los formatos de archivos, tambin
deben modificarse los programas( falta de independencia ).
Los archivos pueden ser incompatibles

Un archivo en Cobol no es igual que un archivo hecho en C+
+. Los archivos no pueden combinarse o compararse.
Datos separados y aislados

En ocasiones es necesario obtener informacin de dos o
mas archivos.
Costos elevados
Es muy costoso hacer cambios a las aplicaciones, un
cambio trivial provoca una reaccin en cadena de otros
cambios. Adems el almacenamiento redundante
incrementa los costos.
Tendencia a crear ms y ms archivos

Proliferacin constante de nuevos archivos y por tanto
dificultad en la actualizacin de los mismos.
Es una coleccin compartida de datos sin

redundancias innecesarias, almacenados en un
soporte informtico no voltil, independiente de
los programas que los usen, interrelacionados y
estructurados de acuerdo a un modelo de datos
con el objeto de atender todas las necesidades
de los diferentes usuarios.
Es un conjunto de programas que permite a los usuarios

crear y mantener una base de datos. De hecho un SGBD
debe facilitar la definicin, construccin y manipulacin de
una base de datos. Para ello se usan Lenguajes ad-hoc
En
Eningls
ingls:: DBMS
DBMS ((database
databasemanagement
managementsystem
system ))
Poder especificar
los tipos de
datos, las
estructuras y las
restricciones
Poder guardar
los datos en
algn medio de
almacenamiento
controlado por el
SGBD
Poder usar
funciones para
consultar o
actualizar la base
de datos y
generar informes
Usuarios / Programadores / DBA

Programas de aplicacin / Consultas
Software para procesar
consultas/programas
Software para accesar
los datos almacenados
Diccionario de
Datos
Sistema de
gestin de
Base de datos
Base de datos
Naturaleza autodescriptiva de los SGBD

El SGBD contiene adems de la BD
una definicin o descripcin
completa de la base de datos. Esta
definicin se almacena en el
Diccionario de Datos ( Catalogo o
Metadatos ). Aqu va la informacin
de la estructura de cada archivo, el
tipo y formato de los datos
elementales y las diversas
restricciones que se aplican a nivel
de columna o de archivo.
archivo
Independencia respecto a programas y datos

Los programas que accesan a los SGBD se pueden
escribir de modo que sean independientes de cualquier
archivo especfico. Esto es posible gracias a la
abstraccin de los datos, lo que se explica cuando el
SGBD ofrece a los usuarios una representacin
conceptual de los datos que no incluye muchos de los
detalles de cmo se almacenan.
La independencia se debe a que las estructuras de los
archivos estn almacenados en el diccionario de datos
del SGBD
Manejo de mltiples vistas de los datos

Varios usuarios pueden desear ver datos de la base de
datos, cada uno de los cuales puede requerir una
perspectiva o vista diferente.
Una vista normalmente es un subconjunto de la base de
datos o puede contener datos derivados.
Control de Concurrencia
Un SGBD incluye software de control de concurrencia
( gestor de transacciones ) para asegurar que cuando
varios usuarios intenten actualizar los mismos datos, lo
hagan de manera controlada.
Control de Redundancia
Queda minimizada o controlada la repeticin del mismo
dato en diferentes archivos. De esta forma ya no se
desperdicia espacio de almacenamiento ni se producen
inconsistencias.
Restriccin de accesos no autorizados

Normalmente algunos usuarios tienen autorizacin solo
para leer los datos de la base de datos, mientras que
otros pueden leer y actualizar. Un SGBD tiene un
subsistema de seguridad y autorizacin que permite al
DBA crear cuentas y especificar restricciones para ellas
Restricciones de integridad
El SGBD debe ofrecer recursos para definir y hacer
cumplir ciertas restricciones de integridad sobre los
datos. Veamos algunos ejemplos : definir un tipo de dato,
las edades de colegiales ( 13 a 17 ), que un valor sea
nico ( cdigo de trabajador ), etc
Respaldo y Recuperacin
Todo SGBD debe contar con un subsistema de respaldo y
recuperacin, a fin de enfrentar exitosamente fallas de
hardware o de software. La idea es que despus de una
caida, se restaure la base de datos al estado en el que
estaba.
ELEMENTO
DE ESQUEMA
Representa el diseo global

de la Base de Datos. Los
esquemas cambian muy
raras veces o nunca. El
concepto de esquema se
puede asociar por analoga
con la declaracin de
arreglos en los lenguajes
de programacin.
ESTUDIANTE
codEstud
nombre
ciclo
espec
nomCur
cred
depto
CURSO
codCurs
REQUISITOS
codCurs
CodCursRequisito
NOTAS
codCurs
codEstud
parc
trab
fin
PROFESOR
codProf
codCurs
nomProf
fechIngre
Existen tres esquemas que describen la arquitectura de una

BD
Tambin
Tambin conocido
conocidocomo
como
estado
estado de
dela
labase
basede
dedatos
datos
Es el conjunto de registros almacenados en la
base de datos, en un instante dado.
Las bases de datos cambian a lo largo del
tiempo, segn se aade o elimina informacin.
Una instancia de BD se puede comparar por
analoga a los datos colocados en arreglos ya
declarados en algn lenguaje de programacin.
CURSO
ESTUDIANTE
codEstud
nombre
ciclo
100
Ana
Contabilidad
150
Alex
Sistemas
250
Ins
Contabilidad
350
Max
Sistemas
REQUISITOS
codCurs
CodCursRequisito
S200
M100
S310
S200
M100
espec
codCurs
nomCur
cred
depto
M100
Matemtica I
S200
Algoritmos I
S310
Algoritmos II
NOTAS
codCurs
codEstud
parc
trab
fin
S200
350
11
16
13
S310
100
06
17
12
M100
250
17
13
18
PROFESOR
codProf
codCurs
nomProf
fechIngre
P100
S200
Prado
22/01/90
P200
M100
Horna
14/01/93
Un Base de Datos presenta una arquitectura de tres niveles,

donde son definidos los esquemas correspondientes :
Usuarios finales
NIVEL
EXTERNO
NIVEL
CONCEPTUAL
NIVEL
INTERNO
Vista
Externa 1
Vista
Externa 2
...
Vista
Externa n
Correspondencia
externa/conceptual
ESQUEMA CONCEPTUAL
Correspondencia
conceptual/ interna
ESQUEMA INTERNO
BD ALMACENADA
Correspondencia : proceso de transformar pedidos y respuestas

de un nivel a otro.
Niveles de abstraccion
NIVEL EXTERNO Es conocido como el nivel de vistas de usuario.
Cada vista de usuario se conoce como subesquema o esquema
externo, donde cada uno de ellos describe alguna parte de la base
de datos. Oculta al usuario toda la base de datos restante.
NIVEL CONCEPTUAL
A este nivel se tiene el esquema de la base
de datos, que describe la estructura de toda la base de datos. El
esquema conceptual oculta los detalles de las estructuras fsicas
de almacenamiento y se concentra en describir entidades, tipos
de datos, relaciones, operaciones y restricciones
NIVEL INTERNO o FISICO
tiene un esquema interno o fsico.

Describe como se almacenan realmente los datos y los caminos
de acceso a la base de datos.
Un SGBD proporciona dos tipos de lenguajes : uno para

especificar la base de datos y otro para expresar las
consultas y actualizaciones de la BD.
Data definition
language
Permite especificar los esquemas Conceptual e Interno. Da

al DBA los recursos para describir los datos, especificando
sus diversas estructuras. Cuando se ejecutan instrucciones
DDL, resultan un conjunto de tablas que se almacenan en el
DDD. Para especificar la estructura de almacenamiento
(esquema interno) y los mtodos de acceso se usa un tipo
especial de DDL llamado Lenguaje de definicin de
almacenamiento (SDL)
Data
manipulation
language
Permite realizar las principales operaciones de manipulacin

de datos, como son la recuperacin, insercin, eliminacin y
la modificacin. Son dos los principales tipos de DML :
DML no procedimentales : permiten introducir
interactivamente instrucciones de alto nivel, para su
procesamiento.
DML procedimentales : son de bajo nivel y deben estar
incorporados en un lenguaje de programacin. Se
caracterizan porque trabajan registro por registro, por tanto
hace falta introducir estructuras cclicas de programacin.
Programadores
Escriben aplicaciones, donde incrustan comandos DML para
interactuar con el sistema
Usuarios normales
Interactan con el sistema mediante el uso de aplicaciones que
han sido escritos por informticos.
Usuarios sofisticados
Interactan con el sistema creando consultas con un lenguaje
de consulta, las cuales entran al procesador de consultas que
transforma las instrucciones DML, para ser entendidas por el
gestor de almacenamiento.
Administrador de la Base de Datos

Crea BD, define mtodos de acceso, concede autorizaciones, etc
Entre las interfaces amables con el usuario que pueden ofrecer

estos sistemas estn :
Interfaces basadas en mens
Presentan mens para facilitar formular solicitudes. No hace falta
memorizar comandos.
Interfaces Grficas
Presentan esquemas en forma de diagramas, ud. puede especificar
consultas manipulando el diagrama.
Interfaces basadas en formularios
Presentan un formulario, donde el usuario llena los espacios con
alguna clave que servir para localizar la informacin.
Interfaces de lenguaje natural
Acepta comandos e interpreta su solicitud. Si es correcta se
genera una consulta de alto nivel.
Usuarios
normales
Programadores
de aplicaciones
Usuarios
sofisticados
Administrador de
Base de Datos
Interfaces de
aplicaciones
Programas de
aplicacion
Consulta
Esquema de
base de datos
Precompilador
del DML
Cdigo objeto
de las
aplicaciones
compilador
del DML
Interprete
del DDL
Motor de evaluacin de
consultas
Gestor de
transacciones
Gestor de memoria intermedia
Usuarios
Procesador
de
Consultas
Gestor de
almacenamiento
Gestor de archivos
Archivos de datos
estadstica
indices
Diccionario de datos
Sistema
de gestin
de base de
datos
Es una coleccin de herramientas conceptuales para describir

datos, relaciones entre ellos, semntica asociada a los datos y
restricciones de consistencia.
Los modelos de datos se clasifican en tres grupos de acuerdo
al nivel de abstraccin :
1. Modelos de alto nivel o conceptuales

2. Modelos de representacin o de implementacin
3. Modelos de bajo nivel o fsicos
Son modelos lgicos basados en objetos y se usan para

describir datos en los niveles conceptual y de vistas. Se
caracterizan por el hecho de que proporcionan
capacidades estructurales muy flexibles y permiten que las
relaciones de datos sean especificadas explcitamente.
Utilizan conceptos como entidades, atributos y relaciones.
Entre los modelos mas difundidos tenemos :
El modelo Entidad - Relacin
basado en una percepcin del mundo real que consta de

objetos llamados entidades y de relaciones entre ellos
El modelo orientado a objetos

Similar al modelo E/R, pero los objetos contienen
adems de datos, segmentos de cdigo ( mtodos) que
manipulan estos datos.
Son muy usados en los SGBD comerciales. Representan los

datos valiendose de estructuras de registros, por eso se les
conoce tambien como Modelos basados en registros. Los
modelos mas representativos de esta categora son :
El modelo de datos Relacional

Se basa en el uso de tablas (filas y columnas) para representar
los datos y sus relaciones
El modelo de datos de Redes
Se basa en el empleo de colecciones de registros y las

relaciones se representan mediante enlaces como punteros,
en forma de grafos.
El modelo de datos Jerrquico
Similar al modelo de redes, pero los registros se organizan en

forma de rbol.
Describen como se almacenan los datos en el computador al

representar informacin como los formatos, ordenamientos
de los registros y las estructuras de bsqueda que hacen mas
eficiente de acceso.
Los modelos fsicos mas conocidos son :
El modelo de Unificacin
El modelo de memoria por marcos
Esta basado en una percepcin del mundo real que

consta de objetos llamados entidades y de relaciones
entre ellos. Permite especificar un esquema de la
organizacin que representa la estructura lgica
completa de una base de datos.
CONCEPTOS PRINCIPALES
ENTIDA
Es una cosa u objeto del mundo real que es
D distinguible de todos los dems objetos ( de un grupo de
alumnos, un alumno es una entidad )
RELACIONES
son asociaciones entre dos o mas entidades

que representan un hecho o situacin del mundo real. Ejem :
Empleado
pertenece a
departamento
ATRIBUTOS
son las propiedades especficas que describen

la entidad. Por ejemplo la entidad empleado puede ser descrita
por su nombre, cargo y sueldo. Los atributos pueden tener
valores.
TIPO DE ENTIDADES define un conjunto de entidades que

poseen los mismos atributos. Concepto til para el diseo.
Ejemplo : empleado, cliente, proveedor
Tipo de entidades
Tipo de entidades dbil
Relacin
Atributo
Atributo clave
Atributo multivaluado
Atributo compuesto
Atributo derivado
E1
E1
E2
E2
Participacin total de E2 en R
Cardinalidad 1:N para E1:E2 en R
Es un modelo de datos de alto nivel que se emplea en el

diseo conceptual de la base de datos. Percibe el mundo
real como objetos llamados entidades y las relaciones entre
ellos. Especifica un esquema de la organizacin que
representa la estructura lgica completa de una base de
datos.
Fue introducido por Peter Chen en 1976
CLIENTE
CLIENTE
coloca
coloca
Es colocada
ORDEN DE
COMPRA
ORDEN DE
COMPRA
CONCEPTOS PRINCIPALES
ENTIDA
Es una cosa u objeto del mundo real que es
distinguible de todos los dems objetos ( Ejemplo : de un
D
grupo de alumnos, un alumno es una entidad )
ATRIBUTOS
son las propiedades especficas que describen

la entidad. Por ejemplo la entidad empleado puede ser descrita
por su nombre, cargo y sueldo. Los atributos pueden tener
valores.
TIPO DE ENTIDADES
define un conjunto de entidades que

poseen los mismos atributos. Concepto til para el diseo.
Ejemplo : empleado, cliente, proveedor
TIPOS DE
RELACIONE
S
son asociaciones entre dos o mas tipos de entidades que

representan un hecho o situacin del mundo real. Ejem :
Empleado
pertenece a
departamento
CLASIFICACION DE
ENTIDADES :
TANGIBLES
Cliente, articulo, factura
CONCEPTUALES
Centro de costo
EVENTOS
Sesion tecnica, averia de equipo, etc
Tipo de entidades
Tipo de entidades dbil
Relacin
Atributo
Atributo clave
Clave parcial
( Corresponde a
una entidad dbil )
Atributo multivaluado
Atributo compuesto
Atributo derivado
E1
E2
R
1
E1
(min , max)
Participacin total de E2 en R
E2
Cardinalidad 1:N para E1:E2 en R
Restriccin Estructural (min , max )

de la participacin de E en R
1. Simples o compuestos
2. Monovaluados o Multivaluados
3. Almacenados o Derivados
Atributo Simple
Son atributos que se visualizan o conceptualizan como un solo
valor. Ejemplo :
direccin
CLIENTE
Direccin = Angamos 1535-201, Lima, Per
Atributo Compuesto
Son atributos que se han dividido en componentes mas
pequeos. Por ejemplo el atributo direccin de una entidad
cliente, se puede subdividir en domicilio, ciudad y pais :
Direccion = Angamos 1535-201, Lima, Per
Domicilio = Angamos 1535-201
Direccin
Ciudad = Lima
Pas = Per
El valor del atributo compuesto es la concatenacin de

los valores de los atributos simples que lo constituyen
Atributo Compuesto
ciudad
domicilio
pais
direccin
CLIENTE
Atributo Compuesto
Estos atributos pueden formar una jerarqua
Direccin
Domicilio
calle
numero
Ciudad
departamento
Pas
Atributo Monovaluado
Estos atributos tienen un solo valor. Por ejemplo el
atributo edad :
edad
ALUMNO
Atributo Multivaluado
Es el caso en que un atributo puede tener un conjunto de
valores para la misma entidad. Por ejemplo el atributo
aficiones, asi una persona podra tener mas de una aficin :
rugby, filatelia, lectura.
aficin
FUNCIONARIO
area
Atributo Almacenado
Es el que mantiene sus valores almacenados en algn medio
persistente. Por ejemplo el atributo fechaNacimiento
fechaNacimiento
FUNCIONARIO
Si se desea trabajar
con este valor,
simplemente se le
extrae directamente
de su medio de
almacenamiento
Atributo Derivado
Es el que se obtiene en forma indirecta, normalmente a partir
de algn atributo almacenado. Por ejemplo el atributo edad ,
se puede obtener a partir del atributo fechaNacimiento y de la
fecha actual ( obtenible del S.O ).
edad
ALUMNO
Es un atributo cuyo valor es distinto para cada entidad

individual. Constituyen una variedad de restriccin
importante y se puede expresar como restriccin de clave
o de unicidad. De hecho son atributos que identifican de
manera inequvoca a una entidad.
El cdigo de un empleado, es un ejemplo de atributo
clave :
cdigo
EMPLEADO
A veces una clave se forma en base

a varios atributos que se
concatenan. Esto nos llevara al
concepto de atributo compuesto, el
cual se convertira en el atributo
clave del tipo de entidades
analizado.
Especifica los valores que es posible asignar a este

atributo para cada entidad individual.
Por ejemplo el atributo EDAD del tipo de entidades
EMPLEADO. Sabemos que en una empresa la edad
legal para laborar (varones) esta entre 18 y 65 aos,
por tanto el dominio del atributo EDAD sera (16,65)
El dominio no se representa en el DER.
Son asociaciones entre dos o mas entidades que representan un hecho o

situacin del mundo real. Se representan con rombos conectados
mediante lneas rectas con los tipos de entidades asociados.
CLIENTE
MEDICO
coloca
ORDEN DE
COMPRA
trata
PACIENTE
da
recibo
RELACION
SIMPLE
MULTIRELACION
Es el nmero de tipos de entidades que participan

en una relacin
CLIENTE
PROFESOR
coloca
dicta
ORDEN DE
COMPRA
GRADO 2
CURSO
GRADO 3
AULA
Se produce cuando dos entidades relacionadas requieren almacenar

un dato que no corresponde a ninguna de ellas. Por ejemplo, un
cliente compra artculos :
CLIENTE
compra
ARTICULO
pero si deseamos recordar que da se compr ese artculo,

donde se almacenara la fecha ?
La fecha de compra no es atributo de cliente
La fecha de compra no es atributo de artculo
La fecha de compra esta asociada a la compra misma :
fecha
CLIENTE
compra
ARTICULO
Todo tipo de entidades cuando participa en un tipo de relaciones,

desempea algn rol. Por ejemplo en el tipo de relacin :
EMPLEADO
Pertenece
a
DEPARTAMENTO
Aqu EMPLEADO desempea el rol de empleado o trabajador y el

tipo de entidad DEPARTAMENTO tiene el rol de departamento o
patrn.
EMPLEADO
trabajador
Pertenece
a
patrn
DEPARTAMENTO
Normalmente no esnecesario escribir los roles en los tipos de

relaciones cuando los nombres de los tipos de entidades son
distintos, ya que cada nombre de tipo de entidades es autodescriptivo
y se puede usar para expresar su rol.
Un tipo de relaciones es recursiva, cuando en algunos casos el

mismo tipo de entidades participa mas de una vez en un tipo de
relaciones con roles diferentes. En tales casos el nombre del rol
resulta indispensable para distinguir el significado de cada
participacin
EMPLEADO
Pertenece
a
supervisado
supervisor
supervisin
DEPARTAMENTO
Son restricciones que aplican los tipos de relaciones sobre las

entidades que participan en la relacin, limitando sus posibles
combinaciones.
Por ejemplo una empresa puede tener como norma que un

empleado solo puede pertenecer a un solo departamento. Por otro
lado como es obvio, a un departamento pertenecen muchos
empleados. El asunto es como expresar esta restriccin ?
Este tipo de relacin se modela y se lee as :

( de IZQ a DER )
Un empleado pertenece a un Departamento
EMPLEADO
Pertenece
a
DEPARTAMENTO
( de DER a IZQ )
A un Departamento pertenecen muchos empleados
1. RAZON DE CARDINALIDAD
2. RESTRICCION DE PARTICIPACION
Indica cuantas veces puede participar una entidad en un tipo

de relaciones
(1,1)
Indica uno a uno
(1,N)
Indica uno a muchos
(M,N)
Indica muchos a muchos
En el Departamento de Marketing trabajan 35 personas y hoy

Jorge Lamas ha sido nombrado Gerente de este Departamento y
por tanto, tiene ahora la grave responsabilidad de dirigir a todas
las dems personas. Si deseamos modelar esta empresa :
EMPLEADO
dirige
DEPARTAMENTO
Como se lee este modelo ?

Un empleado dirige un Departamento
Un Departamento es dirigido por un empleado
Si asumimos que en todas las empresas comerciales se cumple que

un vendedor puede visitar a muchos clientes y que un cliente debe
ser visitado por un vendedor. Como modelara esta situacin ?
VENDEDOR
visita

Un vendedor visita muchos cliente
Un cliente es visitado por un vendedor
CLIENTE
ALUMNO
matricularse
CURSO

Un alumno puede matricularse en muchos cursos
En un curso pueden matricularse muchos alumnos
ORDEN
tiene
ARTICULO

Una orden tiene muchos articulos
Un artculo tiene presencia en muchas ordenes
EMPLEADO
dirige
DEPARTAMENTO
(1,1)
EMPLEADO
Pertenece a
DEPARTAMENTO
(1,N)
ORDEN
tiene
ARTICULO
(M,N)
1. TOTAL
2. PARCIAL
R es un tipo de relacin entre los tipos de entidades E1 y E2. Se

dice que E1 participa totalmente en el tipo de relacin R, si toda
entidad de E1 esta relacionada con por lo menos una entidad de E2
EMPLEADO
Pertenece
a
DEPARTAMENTO
Ejemplo : Todo empleado debe

pertenecer a un departamento
PARTICIPACION
TOTAL
Ejemplo : A Todo departamento

le pertenecen empleados
EMPLEADO
Un tipo de entidades E1 participa

parcialmente en el tipo de relacin R
1
1
dirige
DEPARTAMENTO
Ejemplo : No todo empleado

dirige un departamento
Todo departamento es dirigido
por un empleado ( total)
PROFESOR
tiene
OFICINA
Ejemplo : No todo profesor

tiene una oficina
No toda oficina tiene un
profesor ( tambin parcial)
La empresa Cosmos S.A. Vende maquinaria industrial de ltima

tecnologa, existiendo dentro de la empresa como es obvio un
rea de ventas. Cada vendedor trabaja con diversos tipos de
clientes y tiene acceso a varios consultores distintos en la
organizacin. Cuando el cliente pide informacin muy
especializada, el vendedor debe acceder a los consultores de la
compaa para que ellos informen al cliente en una sesin de
consultora. Una sesin de consultora para un cliente puede
requerir varios consultores, cuando el tema es muy complejo.
Durante la sesin el vendedor no se involucra y los consultores
informan directamente al cliente.
Desarrolle el DER correspondiente
IDENTIFICAR ENTIDADES
Primero identificar tipos de entidades, para ello buscar objetos sustantivos
o importantes, tal que a la organizacin le sera til almacenar informacin
sobre ellos. Entonces dar nombre a los tipos de entidades
Cuales son los atributos que identificaran a estas entidades ?
Identificar el atributo clave
VENDEDOR
Atributos
Atributo
clave
codVend
nombre
apellido
fechNac
codVend
CLIENTE
codClien
nombre
apellido
fono
fax
interes
codClien
CONSULTOR
codConsul
nombre
apellido
fechNac
especiald
codConsul
SESION
numSesion
fecha
codClien
codConsul
numSesion
codClien
IDENTIFICAR TIPOS DE RELACIONES

VENDEDOR - CLIENTE
VENDEDOR
Trabaja
con
CLIENTE
VENDEDOR - CONSULTOR
VENDEDOR
accesa
CONSULTOR
CONSULTOR- CLIENTE
CONSULTOR
informa
CLIENTE
CLIENTE - SESION
CLIENTE
asiste
SESION
CONSULTOR - SESION
CONSULTOR
asiste
SESION
DEFINIR CARDINALIDAD
1
VENDEDOR
VENDEDOR
CLIENTE
CONSULTOR
accesa
CONSULTOR
asiste
CLIENTE
CONSULTOR
informa
asiste
Trabaja
con
CLIENTE
SESION
SESION
DEFINIR PARTICIPACION
1
VENDEDOR
M
VENDEDOR
accesa
CONSULTOR
CLIENTE
CONSULTOR
asiste
CLIENTE
CONSULTOR
informa
asiste
Trabaja
con
CLIENTE
SESION
SESION
CONSTRUIR DE DIAGRAMA
ENTIDAD - RELACION
VENDEDOR
CLIENTE
accesa
1
asiste
informa
CONSULTOR
Trabaja
con
asiste
SESION
Notacin Martin
En la Editorial INFOWEB trabajan varios autores diferentes que

escriben los libros que publica esta empresa. Algunos autores
escriben solo un libro, mientras que otros escriben varios. Se
sabe que en algunos libros se produce coautora.
INFOWEB tambin trabaja con mltiples imprentas, sin embargo
un libro dado lo imprime una sola imprenta.
Un editor cualquiera de la empresa, trabaja con diversos autores
al mismo tiempo, editando y produciendo sus libros. Es tambin
labor del editor entregar a la imprenta el original para su
procesamiento cuando la obra ya ha sido revisada.
Desarrolle el DER correspondiente
DIAGRAMA ENTIDAD - RELACION
AUTOR
escribe
LIBRO
Trabaja
con
Edita y
produce
EDITOR
imprime
Entrega
original
IMPRENTA
Notacin Martin
Se caracterizan porque no poseen atributos clave propios.

Dependen su existencia de otro tipo de entidades que se conoce
como propietario.
Resumiendo entonces, los tipos de entidades dbiles siempre

tienen una restriccin de participacin total ( dependencia de
existencia ) y la ausencia de atributo clave propio
Para distinguir una entidad dbil de otras, debemos asociarla
con la entidad fuerte o propietaria y ubicar un atributo
discriminante dentro de la entidad dbil, que se conoce como
clave parcial.
Finalmente la clave primaria de un tipo de entidades dbil se
forma mediante la clave primaria del tipo de entidades
propietario ms la clave parcial del tipo de entidades dbil.
EJEMPLO
EJEMPLO :
Cuando obtenemos un prstamo de una entidad crediticia, nos
comprometemos a pagarlo mediante una secuencia de pagos. De aqu
podemos notar que aparecen dos entidades : prstamo y pago .
Consideremos que los atributos son :
prestamo( numPrestamo, importe , fechPrestamo )

pago( numPago, fechaPago, importe )
Aunque cada entidad pago es distinta, muchos pagos
corespondientes a diferentes prestamos, de hecho van a tener el
mismo numero de pago.
En otras palabras cualquier pago depender existencialmente de una
entidad prstamo y por otro lado no posee atributo clave, ya que
numPago no es nico. Entonces estamos frente a un tipo de entidades
dbil.
Diagrama E-R con un tipo de entidades dbil

importe
numPrestamo
prstamo
importe
numPago
fechaPrest
posee
fechaPago
pago
Un prstamo posee muchos pagos

Un pago es propiedad de un prstamo
Todo pago pertenece a UN prstamo
Es otro mtodo de expresar las restricciones de cardinalidad y de

participacin, mostrandolos como un par coordenado de la forma :
( mn , max )
Consiste en asociar un par de nmeros enteros (mn, mx) a cada
participacin de un tipo de entidades E en un tipo de relaciones R,
donde : 0 <= mn <= mx >= 1
INTERPRETACION :
1. Los nmeros significan que, para cada entidad e de E, e debe
participar en por lo menos mn y cuando mas en mx ejemplares de
relaciones de R en todo momento ( cardinalidad ).
2. Cuando mn = 0 , implica participacin parcial y cuando mn > 0 implica
participacin Total.
( mn , mx )
Cardinalidad : Un empleado dirige 0 UN Departamento ( UNO a UNO )
Participacin : No todo empleado dirige un Departamento
(0,1)
EMPLEADO
dirige
(1,1)
( PARCIAL )
DEPARTAMENTO
Cardinalidad : Un Departamento es dirigido por UN empleado
( UNO a UNO )
Participacin : Todo Departamento es dirigido por UN empleado
( TOTAL )
Nota : observe que en esta notacin, cuando

se tiene participacin total, no se usa doble
lnea.
Sin embargo debe usarse necesariamente

cuando se modelan entidades dbiles
empleado
(0,N)
posee
(1,1)
hijos
fechNac
nombre
sexo
HISTORIA CLINICA DEL PACIENTE

CODIGO :
NOMBRE :
DNI :
FONO :
DIRECCION :
SEXO :
FECHA INSCRIPCION :
NOMBRE EMPRESA :
RUC :
DIRECCION :
Fecha
Hora
Doctor
CMP
Especialidad
Diagnstico
Construya el DER para el presente formulario
Notacin Martin
PACIENTE
tiene
pertenece
codigo
nombre
direc
fono
dni
sexo
fechInsc
ATENCION
fecha
hora
diagnostico
EMPRESA
nombre
direc
ruc
hacer
DOCTOR
nombre
cmp
especialidad
Rehaga el DER aplicando la notacin standar
MULTINACIONAL
Una gran multinacional en el Per es duea de varios bancos, los cuales
poseen muchas sucursales. La informacin relevante de los bancos es
nmero de banco, nombre y direccin. Para las sucursales el nmero de
la sucursal y la direccin.
Las sucursales son responsables de crear todas las nuevas cuentas o
brindar los prstamos que requieran los clientes.
Es importante para la organizacin almacenar los nmeros de cuenta ,
los saldos y el tipo de cuenta ( ahorro, cta corriente, plazo ) . Igualmente
informacin sobre el nm. de prstamo, importe y la fecha del prstamo.
Los prstamos se pagan en cuotas para lo cual se almacena el nm. de
cuota, el monto y la fecha de pago.
Los clientes pueden tener varias cuentas o pedir los prestamos que
necesiten. Los datos del cliente son cdigo, nombre, direccin y
telfono.
Construya el DER
HOTEL 4 ESTRELLAS
Lima Beach es un hotel de cuatro estrellas que tiene una clientela muy
seleccionada, y gracias a la calidad del servicio que brinda, cuenta con
una gran demanda. Por esta razn los clientes nicamente pueden
acceder a l, mediante reservaciones previas que son admitidas por un
empleado recepcionista, quien ingresa la reservacin a una
computadora, donde se registra adems del nombre del cliente, su
direccin y telfono, lo cual sirve para que en el futuro, el Hotel enve
tarjetas por onomstico o navidad, asi como folletines publicitarios.
Gran parte del negocio consiste en reservaciones que efectan algunas
empresas para reuniones de trabajo que por lo general duran todo un fin
de semana, pero el ingreso principal proviene de reservaciones que
realizan las personas naturales.
El promedio de ocupacin diaria del Hotel esta en un 80%, lo cual es
bastante bueno para este tipo de negocio y ello se debe al esmero en la
atencin de los clientes, pues se tiene una dotacin de empleados de
limpieza, donde cada empleado no atiende mas de 10 habitaciones.
HOTEL 4 ESTRELLAS
Se sabe tambin que tanto el recepcionista como los empleados de
limpieza reciben un porcentaje de los ingresos producidos por los
clientes.
Por otro lado el Hotel otorga un 20% de descuento cuando la reservacin
es hecha por una empresa y de 10% de descuento cuando la reservacin
es hecha por una persona natural por dos o mas habitaciones, lo cual se
hace efectivo ante la presentacin de la factura correspondiente.
Construya el DER
Los primeros en asociar una estructura de datos con una relacin fueron
los investigadores R.E. Levein y M.E. Maron por el ao de 1967.
Pero es Eddgar F. Codd quien en Junio de 1970 publica en el volmen 13,
nmero 6 de la revista cientfica Communications of the ACM, el artculo A
Relational Model of Data for Large Shared Data banks. Este artculo origin
que se empezaran a disear y desarrollar sistemas basados en la teora del
modelo Relacional.
El primero de los prototipos fue el PRTV (Peterlee Relational Test Vehicle )
desarrollado por el centro Cientfico de Peterlee, pero estaba muy sesgado a
problemas urbanos y de salud. El segundo prototipo se le llam XRM
( Extended Relational Memory) y fue de IBM. En 1978 se desarrollo el
Q.B.E., Query By Example. El prototipo base y mas completo fue el famoso
Sistema R, desarrollado por IBM (1980) y luego muchos ms. Ante esta
jungla de productos, Codd decidi establecer una referencia de 12 reglas
para sealar cuando un SGBD cumple con el modelo relacional o no. Hasta
la fecha no existe ningn SGBD que cumpla con todas las reglas.
Representa la base de datos como una coleccin de

relaciones, donde cada relacin es una tabla.
Una tabla esta conformada por filas y columnas.
Conceptos :
ATRIBUTO
codEstud nombre ciclo
TABLA
( relacin )
espec
100
Ana
Contabilidad
150
Alex
Sistemas
250
Ins
Contabilidad
350
Max
Sistemas
Tabla : ESTUDIANTE
Ciclo = 1 al 10
( DOMINIO )
TUPLA
( ocurrencia )

DOMINIO
El dominio se refiere al conjunto de valores permitidos

por un atributo o columna. El dominio mas simple sera
especificar un tipo de datos para sus valores.
Otros ejemplos :
Notas promedio : valores posibles entre 0 y 20
Edades de empleados : deberan ser entre 18 y 65 aos
Facultades : el conjunto formado por Sistemas,
Contabilidad, Administracin Economa de una Univ.
Telfonos : el conjunto de nm. Telefnicos de 7 digitos
Un dominio debe tener un nombre,

un tipo de datos y un formato
Un esquema de relacin, es forzando una analoga, como la estructura de

un archivo. Otra analoga es compararla con el concepto de tipo de dato de
los lenguajes de programacin o la declaracin de un arreglo de registros.
Matemticamente se denota como :
R ( A1 , A2 , A3 , . . . . , An )
Donde :
= Es el nombre del esquema de relacin
( A1 , A2 , A3 , . . . . , An )
= Lista de atributos del esquema

de relacin
El dominio de un atributo se denota :
GRADO
dom( A i )
= Es el nmero de atributos del esquema de relacin
Ejemplo :
nombre del esquema de relacin
Atributos
CLIENTE
Grado = 5
( codCli, nombre, ruc, fono, direc )
Atributo A 1 = codCli ,
Atributo A 2 = nombre ,
Atributo A 3 = ruc ,
Dom ( A 1 ) = Conjunto de
nmeros de
5 dgitos
nombres de
clientes
nmeros de
8 dgitos
Una relacin
del esquema de relacin :
R ( A1 , A2
, . . . , An)
es denotado por : r ( R )
Una relacin r ( R ) es un conjunto de n-tuplas en un instante dado :
( filas )
r = { t1, t2 , ... ,tn}
Cada n-tupla ( o fila ) t i es una lista de n valores v i
t = { v1,v2 , ... ,vn }

codEstud nombre ciclo
t1
t2
t3
t4
espec
100
Ana
Contabilidad
150
Alex
Sistemas
250
Ins
Contabilidad
350
Max
Sistemas
relacin
Es una
instancia de
un esquema
de relacin
Cada valor en una tupla es atmico, por ello no se permiten atributos

compuestos ni multivaluados. Esto, porque debe cumplirse con la
primera forma normal del diseo de base de datos.
Los atributos multivaluados , se deben representar con

relaciones individuales
Los atributos compuestos , se representan nicamente mediante

sus atributos componentes elementales.
Valor NULO , se aplica cuando el valor de algn atributo dentro de

una tupla en particular sea desconocido o no corresponda. Por ejemplo
cuando en una encuesta una persona no quiso decir su fecha de
nacimiento o cuando no todas las personas tienen telfono.
Es el conjunto de de esquemas de relacin, ms un

conjunto de restricciones.
Ejemplo :
PROFESOR ( codigo, nombre, fechIngre )
CURSO ( codigo, nombre, creditos )
FACULTAD ( codigo, nombre, decano )
ESQUEMAS
DE RELACION
Son las que se pueden especificar en un esquema de

base de datos relacional. Estas restricciones se
enumeran a continuacin :
De Dominio
De Clave
De Integridad de entidades
Para
normalizacin
De Integridad Referencial
De Dependencias de los datos ( funcionales y
multivaluadas)
Los valores que forman el dominio de los atributos

deben ser atmicos.
Ya se explic antes con ejemplos las formas de
especificar los dominios. Por rangos de valores,
datos enumerados o por tipos de datos entre los que
se incluyen enteros, reales, caracteres, cadenas de
longitud fija y cadenas de longitud variable, adems
de otros tipos especiales como son fecha, dinero, etc
Las restricciones de clave exigen que todas las tuplas de

una relacin deben ser distintas.
SUPER CLAVE
De un esquema de relacin
Es cualquier conjunto de atributos, para los cuales sea

imposible que dos tuplas diferentes, tengan los mismos
valores ( propiedad de unicidad ).
Sin embargo en una superclave pueden haber atributos
redundantes. Por ejemplo, veamos el esquema de relacin :
ESTUDIANTE ( codigo, nombre, direc, sexo, fechNac )
Analizando el esquema de relacin :

Son superclaves :
{ codigo, nombre, sexo }

{ codigo, nombre }
{ nombre, fechNac, sexo }
{ nombre, fechNac }
{ codigo } , etc
No son superclaves :
{ nombre }
{ nombre, sexo }
conjuntos de
atributos
CLAVE
De un esquema de relacin
Es una super clave mnima, es decir una super clave a la cual

no podemos quitarle atributos sin que deje de ser una
superclave ( prdida de unicidad ).
Por ejemplo, en el esquema de relacin anterior,
Analizemos las siguientes superclaves :
{ codigo, nombre, sexo }
No es clave
{ codigo, nombre }
No es clave
{ nombre, fechNac, sexo }
No es clave
{ nombre, fechNac }
Es una clave
{ codigo }
Es una clave
CLAVE CANDIDATA
Es toda clave que se puede encontrar en un esquema de
relacin.
Son claves candidatas :
{ nombre, fechNac }
{ codigo }
CLAVE PRIMARIA
Es la clave candidata que se elige por que sus valores
sirven para identificar inequvocamente a las tuplas de la
relacin.
ESTUDIANTE ( codigo , nombre, direc, sexo, fechNac )
Especificando
clave primaria
Una clave primaria nunca puede tener el

valor NULO. Esto se debe a que el valor
de la clave primaria sirve para identificar
las tuplas individuales en una relacin
NOTA : las restricciones de clave y de
integridad de entidades se especifican
sobre relaciones individuales.
Se especifica entre dos relaciones y sirve para mantener la

consistencia entre tuplas de las dos relaciones.
Dicho de otro modo, establece que una tupla en una relacin que
haga referencia a una segunda relacin, deber referirse a una
tupla existente en la segunda relacin. Por ejemplo analizemos
los esquemas de relaciones empleado y departamento.
Clave FORANEA
EMPLEADO ( codEm , nom, fechNac, direc, sexo, suel, codSuper, nDep )
Clave PRIMARIA
DEPARTAMENTO ( numDep , nombre, codJefe , fechIniJefe)
( FK ) Foreign Key
Clave FORANEA
Una clave fornea FK es un atributo de una relacin R1

asociado a otra relacin R2 , donde aparece replicada como
clave primaria de R2.
Si fuese insertado un nuevo
empleado y le asignamos el
departamento 8, estaramos
violando la restriccin de
Integridad Referencial, ya que no
existe la tupla con numDep = 8 en
la relacin Departamento
Clave FORANEA
R1
EMPLEADO
codEm
nom
fechNac
direc
sexo suel
100
Tovar
15-07-57
Lomas 234
5400
400
300
Silva
07-03-65
Grau 935
4500
200
400
Sierra
22-10-67
Rosas 732
7200
700
150
Castro
12-11-72
America 912
2800
200
200
Rios
04-04-70
Vicus 138
700
Sillars
12-11-72
America 912
9800
nulo
600
Nieto
25-08-73
Flores 1731
4600
400
8700
codSuper nDep
700
Clave PRIMARIA
R2
numDep
nom
DEPARTAMENTO
codJefefe
fechIniJefe
Administracin
200
07-06-95
Ingeniera
400
11-07-92
Gerencia
700
14-10-90
EMPLEADO
codEm
nom
fechNac
direc
100
Tovar
15-07-57
Lomas 234
5400
400
300
Silva
07-03-65
Grau 935
4500
200
400
Sierra
22-10-67
Rosas 732
7200
700
150
Castro
12-11-72
America 912
2800
200
200
Rios
04-04-70
Vicus 138
600
Nieto
25-08-73
Flores 1731
700
Sillars
12-11-72
America 912
HIJOS
codEm
nomHjo
sexo
fechana
100
Norma
10-05-97
400
Cesar
11-08-93
100
Marco
07-11-95
600
Sofa
05-03-98
150
Alicia
25-05-86
sexo suel
codSuper nDep
8700
700
4600
400
9800
nulo
DEPARTAMENTO
numDep
nom
codJefefe
fechIniJefe
Ingeniera
400
11-07-92
Administracin
200
07-06-95
Gerencia
700
14-10-90
LUGARES_DEPA
TRABAJA_EN
cEmp
nProy
horas
300
70
100
40
400
38
nPry
600
45
150
200
nDep
lugarDep
Trujillo
Cuzco
Tacna
PROYECTO
nomPry
Lugar
nDepa
Reorga III
Trujillo
60
TurboDiesel
Tacna
50
Camisea II
Cuzco
Instancia de la Base de Datos : Compaa

Conjunto de relaciones de la base de datos Compaa
Restricciones de Integridad Referencial

Esquema de la base de datos Compaa
EMPLEADO
codEm
nom
fechNac
direc
sexo
suel
codSuper
1.
FK hace referencia a su
propia relacin. Ver lmina
anterior.
2.
El FK nDep del empleado

hace referencia al
departamento donde
trabaja
3.
El FK nDepa del proyecto

hace referencia al
departamento encargado
del proyecto.
nDep
2
DEPARTAMENTO
numDep
nom
codJefefe
fechIniJefe
LUGARES_DEPA
nDep
lugarDep
PROYECTO
nPry
nomPry
Lugar
TRABAJA_EN
cEmp
HIJOS
codEm
nomHjo
sexo
fechana
nProy
horas
nDepa
Insertar ( 100, Soler, 05-10-70, Bolognesi 450, F, 3000, 400, 5)

en EMPLEADO
Viola la restriccin de clave porque ya existe otra tupla con el mismo
valor de codEm en la relacin EMPLEADO
Insertar ( nulo, Soler, 05-10-70, Bolognesi 450, F, 3000, 400, 5)

en EMPLEADO
Viola la restriccin de integridad de entidades porque no es aceptable
que una clave primaria posea valor nulo .
Insertar ( nulo, Soler, 05-10-70, Bolognesi 450, F, 3000, 400, 9)

en EMPLEADO
Viola la restriccin de integridad Referencial porque el FK nDep = 9
no se corresponde con ninguna tupla de DEPARTAMENTO en la que
numDep = 9.
Es un lenguaje de consulta procedimental. Esta constituida por una

coleccin de operaciones que sirven para manipular relaciones enteras
de una base de datos.
Trabajando con una o mas relaciones podemos especificar consultas de
la base de datos. El resultado de cada operacin es una nueva relacin,
que podremos manipular en una ocasin futura.
CLASIFICACION DE LAS OPERACIONES DEL ALGEBRA RELACIONAL
Operaciones de conjuntos
Operaciones de Base de Datos :
union
Interseccion
diferencia
Select
Project
Join
LA OPERACIN SELECT
Sirve para seleccionar un
subconjunto de las tuplas de una
relacin que satisfacen una
condicin de seleccin.
condicin
( NOMBRE RELACION )
Ejemplo : Seleccionar el subconjunto de tuplas de EMPLEADO, para

aquellos que ganen menos de 3,000 soles :
EMPLEADO
codEm
nom
fechNac
direc
sexo suel
100
Tovar
15-07-57
Lomas 234
5400
400
300
Silva
07-03-65
Grau 935
4500
200
400
Sierra
22-10-67
Rosas 732
7200
700
150
Castro
12-11-72
America 912
2800
200
200
Rios
04-04-70
Vicus 138
600
Nieto
25-08-73
Flores 1731
700
Sillars
12-11-72
America 912
8700
codSuper nDep
700
4600
400
9800
nulo
codEm
nom
150
Castro
Suel < 3000
fechNac
12-11-72
direc
America 912
(EMPLEADO)
sexo suel
F
2800
codSuper nDep
200
Ejemplo : Seleccionar de la relacin EMPLEADO, a los que trabajan en el

departamento nDep = 4 :
EMPLEADO
codEm
nom
fechNac
direc
sexo suel
codSuper nDep
100
Tovar
15-07-57
Lomas 234
5400
400
300
Silva
07-03-65
Grau 935
4500
200
400
Sierra
22-10-67
Rosas 732
7200
700
150
Castro
12-11-72
America 912
2800
200
200
Rios
04-04-70
Vicus 138
600
Nieto
25-08-73
Flores 1731
700
Sillars
12-11-72
America 912
8700
700
4600
400
9800
nulo
nDep = 4
codEm
nom
fechNac
direc
300
Silva
07-03-65
Grau 935
150
Castro
12-11-72
200
Rios
04-04-70
sexo suel
(EMPLEADO)
codSuper nDep
4500
200
America 912
2800
200
Vicus 138
8700
700
Ejemplo : Seleccionar a todos los empleados del departamento 4 que

ganen mas de 4,000 soles :
Suel > 4000
nDep = 4
(EMPLEADO)
codEm
nom
fechNac
direc
sexo suel
300
Silva
07-03-65
Grau 935
150
Castro
12-11-72
200
Rios
04-04-70
codSuper nDep
4500
200
America 912
2800
200
Vicus 138
sexo suel
8700
700
codEm
nom
fechNac
direc
codSuper nDep
300
Silva
07-03-65
Grau 935
4500
200
200
Rios
04-04-70
Vicus 138
8700
700
Usando operadores lgicos AND , OR :

Ejemplo : Seleccionar a todos los empleados del departamento 4 que
ganen mas de 4,000 soles :
( nDep = 4 ) AND (suel > 4000 )
(EMPLEADO)
codEm
nom
fechNac
direc
sexo suel
codSuper nDep
300
Silva
07-03-65
Grau 935
4500
200
200
Rios
04-04-70
Vicus 138
8700
700
Ejemplo : Seleccionar a todos los empleados del departamento 1 o del

departamento 4 :
( nDep = 1 ) OR (nDep = 4 )
codEm
nom
fechNac
direc
300
Silva
07-03-65
Grau 935
150
Castro
12-11-72
200
Rios
700
Sillars
sexo suel
(EMPLEADO)
codSuper nDep
4500
200
America 912
2800
200
04-04-70
Vicus 138
12-11-72
America 912
8700
2800
700
nulo
4
1
LA OPERACIN PROJECT
Permite seleccionar los atributos que se indiquen de una relacin. Genera
un listado con las columnas sealadas. Se puede combinar con el Select
Lista de atributos
( NOMBRE RELACION )
Ejemplo : Mostrar cdigo y nombre de todos los empleados :

codEm , nom
( EMPLEADO )
codEm
nom
100
Tovar
300
Silva
400
Sierra
150
Castro
200
Rios
600
Nieto
700
Sillars
Ejemplo : Mostrar cdigo, nombre y sueldo de los empleados que ganan

mas de 5,000 soles :
suel > 5000
codEm , nom , suel
(EMPLEADO)
codEm
nom
fechNac
direc
sexo suel
100
Tovar
15-07-57
Lomas 234
5400
400
400
Sierra
22-10-67
Rosas 732
7200
700
200
Rios
04-04-70
Vicus 138
700
700
Sillars
12-11-72
America 912
codEm
nom
suel
100
Tovar
5400
400
Sierra
7200
200
Rios
8700
700
Sillars
9800
8700
9800
codSuper nDep
nulo
LA OPERACIN JOIN
Permite combinar dos relaciones para formar una tercera, aplicando el
vinculo que existe entre dos relaciones por las claves fornea y primaria.
Existen diversos tipos de JOIN en los SGBD comerciales. Aqu veremos
dos tipos :
EQUI JOIN
NATURAL JOIN
EQUI JOIN
Al combinar dos relaciones R1 y R2 , concatena todos los atributos
de R1 y R2 , quedando repetidas las columnas de vnculo ( foreign
key / primary key ) , que como sabemos, poseen el mismo dominio.
NOTACION :
Igualdad de atributos
del vnculo
EQUI JOIN
Obtener los datos de proyectos y los nombres de los departamentos
responsables :
DEPARTAMENTO
Primary Key
SOLUCION :
PROYECTO
numDep
nDepa = numdep
nom
nomPry
Lugar
Ingeniera
400
11-07-92
Administracin
200
07-06-95
Gerencia
700
14-10-90
DEPARTAMENTO
Reorga III
Trujillo
TurboDiesel
Tacna
Camisea II
Cuzco
5
nPry
Foreign Key
RESULTADO
Atributos del vinculo
nDepa
fechIniJefe
PROYECTO
nPry
codJefefe
nomPry
Lugar
nDepa
numDep
Reorga III
Trujillo
TurboDiesel
Tacna
Camisea II
Cuzco
nom
codJefefe
fechIniJefe
Administracin
200
07-06-95
Ingeniera
400
11-07-92
Ingeniera
400
11-07-92
Nmero de departamento
esta repetido
EJERCICIO :
Repetir el ejercicio anterior, para mostrar nicamente el nombre del
proyecto y el departamento responsable :
nomPry, nom
nomPry, nDepa
nomPry
(PROYECTO )
nDepa = numDep
(DEPARTAMENTO)
numDep, nom
nDepa
numDep
nom
Reorga III
Ingeniera
TurboDiesel
Administracin
Camisea II
Gerencia
nomPry
nDepa
numDep
nom
Reorga III
Administracin
TurboDiesel
Ingeniera
Camisea II
Ingeniera
nomPry
nom
Reorga III
Administracin
TurboDiesel
Ingeniera
Camisea II
Ingeniera
OTRA FORMA DE SOLUCION ( Por ejecuciones parciales ) :

PROY_np_nd
nomPry, nom
nomPry, nDepa
DEPA_nd_nom
U_proy_dep
(PROYECTO )
nDepa = numDep
(DEPARTAMENTO)
numDep, nom
U_proy_dep
PROY_np_nd
DEPA_nd_nom
U_proy_dep
Nomp_Nomdep
nomPry, nDepa
(PROYECTO )
(DEPARTAMENTO)
numDep, nom
PROY_np_nd
nomPry, nom
nDepa = numDep
U_proy_dep
DEPA_nd_nom
NATURAL JOIN
Permite deshacerse del segundo atributo repetido en una condicin
de equi join. Es decir se busca eliminar los atributos superfluos.
NOTACION :
Atributo1 , atributo2
Atributos del Vinculo
EJERCICIO :
Obtener los datos de proyectos y los nombres de los departamentos
responsables :
DEPARTAMENTO
numDep
PROYECTO
nDepa , numdep
nomPry
Lugar
Reorga III
Trujillo
TurboDiesel
Tacna
Camisea II
Cuzco
codJefefe
fechIniJefe
Ingeniera
400
11-07-92
Administracin
200
07-06-95
Gerencia
700
14-10-90
DEPARTAMENTO
PROYECTO
nPry
nom
RESULTADO
nDepa
nPry
nomPry
Lugar
nDepa
nom
Reorga III
Trujillo
Administracin
200
07-06-95
TurboDiesel
Tacna
Ingeniera
400
11-07-92
Camisea II
Cuzco
Ingeniera
400
11-07-92
Nmero de departamento
no esta repetido
codJefefe
fechIniJefe
La Operacin UNION
El resultado de esta operacin, denotada por R U T , es una relacin
que incluye todas las tuplas que estn en R o en T o en ambas. Las tuplas
repetidas se eliminan.
Compatibilidad para la unin

Dos relaciones son compatibles para la unin, si :
Tiene el mismo nmero de atributos.
Los atributos correspondientes tienen el mismo dominio.
Notacin :
EJERCICIO :
TRABAJADOR
Se pide que a partir de la

siguiente relacin, se
obtenga otra relacin que
contenga los trabajadores
que ganan 1500 o 1800
soles :
Cod
sueldo
nDpto
100
1500
400
2000
200
1800
700
1500
300
1800
(TRABAJADOR)
sueldo =1500
(TRABAJADOR)
sueldo = 1800
Cod
sueldo
nDpto
Cod
sueldo
nDpto
100
1500
200
1800
700
1500
300
1800
Cod
sueldo
nDpto
100
1500
700
1500
200
1800
300
1800
La Operacin INTERSECCION
U
El resultado de esta operacin, denotada por R

T , es una relacin que
incluye las tuplas que estn tanto en R como en T.
Notacin :
TRABAJADOR
Se pide que a partir de la

siguiente relacin, se obtenga
otra relacin que contenga los
trabajadores que ganen entre
1500 y 1800 soles :
(TRABAJADOR)
sueldo >=1500
Cod
sueldo
nDpto
100
1200
400
2000
200
1800
700
1500
300
1300
EJERCICIO :
(TRABAJADOR)
sueldo <= 1800
Cod
sueldo
nDpto
Cod
sueldo
nDpto
400
2000
100
1200
200
1800
200
1800
700
1500
700
1500
300
1300
Cod
sueldo
nDpto
200
1800
700
1500
La Operacin DIFERENCIA
El resultado de esta operacin, denotada por R - T , es una relacin que
incluye todas las tuplas que estn en R pero no en T.
Notacin :
TRABAJADOR
Obtener a partir de esta relacin,

otra relacin que contenga los
trabajadores que ganen mas de
1500 pero que no trabajen en el
Departamento 5 :
sueldo > 1500
Cod
sueldo
nDpto
100
1200
400
2000
200
1800
700
1500
300
1900
(TRABAJADOR)
Cod
sueldo
nDpto
400
2000
200
1800
300
1900
EJERCICIO :
nDpto = 5
No esta en la otra relacin

Entonc
es, vale
Cod
sueldo
nDpto
400
2000
200
1800
(TRABAJADOR)
Cod
sueldo
nDpto
100
1200
700
1500
300
1900
RESUMEN DE EJERCICIOS :
EMPLEADO
codEm
nome
fechNac
direc
sexo suel
100
Tovar
15-07-57
Lomas 234
5400
400
300
Silva
07-03-65
Grau 935
4500
200
400
Sierra
22-10-67
Rosas 732
7200
700
150
Castro
12-11-72
America 912
2800
200
200
Rios
04-04-70
Vicus 138
600
Nieto
25-08-73
Flores 1731
700
Sillars
12-11-72
America 912
8700
codSuper nDep
700
4600
400
9800
nulo
DEPARTAMENTO
numDep
nomd
codJefefe
fechIniJefe
Ingeniera
400
11-07-92
Administracin
200
07-06-95
Gerencia
700
14-10-90
LUGARES_DEPA
TRABAJA_EN
cEmp
HIJOS
codEm
nomHjo
sexo
fechana
100
Norma
10-05-97
400
Cesar
11-08-93
100
Marco
07-11-95
600
Sofa
05-03-98
150
Alicia
25-05-86
nDep
lugarDep
nProy
horas
Trujillo
300
70
Cuzco
100
40
Tacna
400
38
600
45
150
60
nPry
200
50
PROYECTO
nomPry
Lugar
nDepa
Reorga III
Trujillo
TurboDiesel
Tacna
Camisea II
Cuzco
RESUMEN DE EJERCICIOS :
Obtener el nombre, direccin y el nombre de departamento de los
empleados que trabajan en el departamento Ingeniera
Solucin :
Notamos que el vnculo entre empleado y departamento es el nmero
de departamento. Por tanto podramos proyectar la relacin
empleados para obtener nombre, direccin con nmero de
departamento y proyectar tambin la relacin departamento para
obtener nombre de departamento con nmero de departamento, y
luego unirlos con un join natural y finalmente seleccionar a los que
trabajan en el departamento de Ingeniera
DAT_EMP
DAT_DEPT
nome, direc, nDep
nomd, numDep
(EMPLEADO )
(DEPARTAMENTO )
EMP_DEPT
DATEMP
ndep, numDep
DATDEPT
En el join natural, se
pierde el atributo
numdep
nomd = Ingeniera
EMP_DEPT
Seleccionando a
los que trabajan en
el departamento de
Ingeniera
nome
direc
nomd
Tovar
Lomas 234
Ingeniera
Sierra
Rosas 732
Ingeniera
Nieto
Flores 1731
Ingeniera
EJERCICIO :
Para cada proyecto cuyo lugar de ubicacin es Trujillo, dar el nmero
de proyecto, nmero de departamento que lo administra, el nombre del
jefe de ese departamento, su direccin y fecha de nacimiento.
EJERCICIO :
Obtener como datos, los nombres de los empleados y los nombres de
todos los proyectos donde trabajen, que estn controlados por el
departamento 5.
El Clculo Relacional es un lenguaje declarativo formal

NO procedimental, basado en la rama de la lgica
matemtica llamada Clculo de Predicados. As
podemos escribir una expresin declarativa para
especificar una solicitud de obtencin de datos, es
decir no necesitamos describir como evaluar una
consulta.
Una expresin del clculo relacional especifica que
debe obtenerse, no como debe hacerse.
Una consulta elemental del clculo relacional sera :

{ t / COND ( t) }
Que representa un conjunto de tuplas t
que satisfacen COND(t)
Donde :
t
= es conocida como variable de tupla
COND( t ) = expresin condicional donde interviene t
EJEMPLO :
Obtener todos los empleados cuyo sueldo sea mayor a
los 3,000 soles
SOLUCION :
{ t / EMPLEADO( t ) and t.SUELDO > 3000 }
La expresin EMPLEADO( t ) especifica que la relacin asociada
la variable de tupla t , es EMPLEADO.
Por tanto se obtendr el conjunto de tuplas t de EMPLEADO
que satisfagan la condicin t . SUELDO > 3000.
EJEMPLO :
Obtener todos los empleados cuyo sueldo sea mayor a
los 3,000 soles, pero considerar solo los atributos cdigo
y nombre.
SOLUCION :
barra
{ t.CODIGO , t.NOMBRE / EMPLEADO( t ) and t.SUELDO > 3000 }
Se obtendr el conjunto de tuplas t con las columnas
codigo y nombre de la relacin EMPLEADO, tal que
satisfagan la condicin t . SUELDO > 3000.
Cuantificador existencial :
Se llama as por que una expresin tal como : (
t ) ( COND )
Es TRUE si existe alguna tupla t que haga que COND sea TRUE
Variable de tupla libre :

Una variable de tupla es libre cuando no esta cuantificada por :
Estas variables aparecen a la izquierda de la barra inclinada
Variable de tupla ligada :

Es la variable de tupla que esta cuantificada por :
EJEMPLO :
Obtener el nombre y la direccin de todos los empleados que
trabajan en el departamento de Ingeniera
{ t.NOMBRE , t.DIRECCION / EMPLEADO( t ) and

(
d ) ( DEPARTAMENTO( d ) and
d.NOMDEP = Ingeniera and
d.NUMDEP = t.NDEP
)
)
Como el join del
algebra relacional
Como el select del

algebra relacional
Consiste en transformar un esquema

conceptual de alto nivel creado mediante
el modelamiento Entidad-Relacin a un
esquema de Base de datos Relacional.
EJERCICIO
Construir el DER para el siguiente caso :
La compaa ABC esta organizada en Departamentos. Cada departamento

tiene un nombre nico, un nmero nico y un cierto empleado lo dirige. Nos
interesa la fecha en que dicho empleado comenz a dirigir el departamento.
Un departamento esta distribuido en varios lugares ( ciudades). Todo
empleado esta asignado a un departamento.
Cada departamento controla varios proyectos, cada uno de los cuales
tiene un nombre y un nmero nicos y se lleva a cabo en un solo lugar.
Los datos de inters por cada empleado son cdigo, nombre, sueldo,
sexo y fecha de nacimiento. Un empleado puede trabajar en varios
proyectos, que no necesariamente estarn controlados por el mismo
departamento. Es importante el nmero de horas por semana que un
empleado trabaja en cada proyecto y tambin quien es el supervisor de
cada empleado.
Deben registrarse los datos de los hijos que tienen los empleados, a fin de
pagarles la escolaridad segn convenio sindical. Los datos son apellido
materno, sexo y fecha de nacimiento.
Identificacin de tipos de entidades

empleado
departamento
proyecto
hijo
Identificacin de tipos de relaciones y cardinalidad

Por cada empleado son
cdigo, nombre, sueldo,
sexo y fecha de
nacimiento
nome
sex
fechNac
suel
Un empleado esta
asignado a un
departamento
pat
nom
empleado
mat
numdepa
code
tiene un nombre nico,

un nmero nico
esta
asignado
En un departamento
estn asignados
muchos empleados
nomd
lugares
departamento
Un departamento
esta distribuido
en varios lugares
pat
nome
sex
fechNac
suel
mat
nom
empleado
numdepa
code
1
un cierto
empleado
lo dirige
esta
asignado
dirige
nomd
lugares
departamento
1
fechIni
interesa la fecha en que dicho

empleado comenz a dirigir. Ojo,
no pertenece a empleado ni a
departamento, sino a la relacin
pat
nome
sex
fechNac
suel
mat
nom
empleado
numdepa
code
esta
asignado
nomd
lugares
departamento
1
dirige
fechIni
Un empleado
puede trabajar en
varios proyectos
M
Trabaja
en
proyecto
lugar
horas
nmero de horas por

semana que un empleado
trabaja en cada proyecto.
Horas no es atributo de
empleado ni de proyecto,
sino de la relacin
nomp
nump
Cada proyecto tiene un

nombre y un nmero
nicos y se lleva a cabo
en un solo lugar
pat
nome
sex
fechNac
suel
mat
nom
empleado
numdepa
code
esta
asignado
lugares
departamento
1
dirige
nomd
controla
fechIni
M
Trabaja
en
Cada departamento
controla varios
proyectos
proyecto
lugar
horas
nomp
nump
pat
nome
sex
fechNac
suel
mat
nom
empleado
supervisado
supervisin
esta
asignado
supervisor
numdepa
code
quien es el supervisor de
cada empleado. Se genera
aqu una relacin recursiva.
Ya que un empleado puede
ser supervisor o
supervisado
1
controla
fechIni
lugares
departamento
1
dirige
nomd
M
Trabaja
en
N
N
proyecto
lugar
horas
nomp
nump
pat
nome
sex
fechNac
suel
mat
nom
numdepa
code
empleado
esta
asignado
1
supervisin
controla
fechIni
N
M
1
los hijos que
tienen los
empleados
dirige
supervisado
N
N
Trabaja
en
tiene
lugares
departamento
supervisor
nomd
proyecto
lugar
horas
nomp
hijo
fechaNac
apemat
HIJO depende
existencialmente de
empleado, por tanto es
tipo de entidad dbil
sexo
Los datos son

apellido materno,
sexo y fecha de
nacimiento
nump
PROCEDIMIENTO PARA TRANSFORMAR

Por cada tipo de entidades fuerte E, se crea un esquema
de relacin R que contenga todos los atributos simples.
En el caso de atributos compuestos, usar solo sus
atributos simples componentes.
Elija uno de los atributos clave de E como clave
primaria de R. Si la clave elegida es compuesta, el
conjunto de sus atributos simples constituirn la clave
primaria de R.
NOTA : por ahora ignore los atributos multivaluados.
AVANCE DE SOLUCION : OBJETIVO : construir el esquema
de la base de datos relacional
EMPLEADO(code , nome , pat , mat , suel , sex , fechNac)
DEPARTAMENTO(numdepa , nomd)
PROYECTO(nump , nomp , lugar)
Por cada tipo de entidades dbil D, se crea un esquema

de relacin R que contenga todos los atributos simples de
D ( si hay atributos compuestos usar sus componentes
simples) .
Incluir adems como atributos de clave fornea de R , los
atributos de clave primaria de la relacin propietaria. Por
tanto la clave primaria de R es la combinacin de las claves
primaria de la propietaria y la clave parcial de D ( si existe ).
AVANCE DE SOLUCION :
Vnculo a empleado
Clave parcial
HIJO (code , apemat , sexo , fechaNac)

EMPLEADO (code , nome , pat , mat , suel , sex , fechNac)
DEPARTAMENTO (numdepa , nomd)
PROYECTO (nump , nomp , lugar)
Por cada tipo de relacin 1:1 R , se identifican los tipos de

entidades ( S , T ) que participan en R , para a partir de
ellas escoger entre S y T. Se escoge una de ellas ( por
ejemplo S ) y se incluye como clave fornea en S, la clave
primaria de T ( se prefiere las que tienen participacin
total en R en el papel de S ) . Incluir todos los atributos
simples del tipo de relacin 1:1 R como atributos de S.
Aqu tomamos el tipo de relaciones 1 : 1 dirige
empleado
departamento
1
dirige
fechIni
eligiendo DEPARTAMENTO ( S ) ya que su participacin es

total (todo departamento es dirigido por un empleado) :
DEPARTAMENTO (numdepa , nomd )

Incluimos la clave primaria de EMPLEADO (code) como
clave fornea en DEPARTAMENTO cambiando su nombre
a codJefe (por claridad) y tambien incluimos el atributo
fechIni del tipo de relacion dirige, usando un nombre mas
significativo, como fechIniJefe.
fechIniJefe No va lugares, por que es
multivaluado :
DEPARTAMENTO ( numdepa , nomd , codJefe , fechIniJefe )
EMPLEADO (code , nome , pat , mat , suel , sex , fechNac)
PROYECTO (nump , nomp , lugar)
En
Enotros
otroscasos
casosse
secombinan
combinanlos
lostipos
tiposde
deentidades
entidadesyyelelvnculo
vnculoen
enuna
unasola
sola
relacin.
relacin.Resulta
Resultaapropiado
apropiadocuando
cuandolas
lasdos
dosparticipaciones
participacionesson
sontotales
totalesyy
cuando
cuandolos
lostipos
tiposde
deentidades
entidadesno
noparticipan
participanen
enningn
ningnotro
otrotipo
tipode
derelaciones.
relaciones.
Por cada tipo de relacin normal 1 : N R , se identifica la

relacin S que representa el tipo de entidades participante
del lado N del tipo de relaciones . Se incluye como clave
fornea en S, la clave primaria de la otra relacin que
participa en R.
Se incluyen todos los atributos simples ( y los componentes
simples de atributos compuestos) del tipo de relaciones 1 : N
como atributos de S.
Como tipos de relaciones 1 : N , en este caso tenemos a :
Esta asignado
controla
supervisin
Para el caso de esta asignado se trata de EMPLEADO :

empleado
esta
asignado
lado N
departamento
Incluimos la clave primaria numdepa de la relacin

DEPARTAMENTO como clave fornea en la relacin
EMPLEADO y la llamamos nDep :
EMPLEADO (code , nome , pat , mat , suel , sex , fechNac , nDep)
nDep
Para el caso de supervisin, se trata de EMPLEADO, siendo el
nico, ya que el tipo de relaciones es recursiva :
Incluimos la clave primaria code de la relacin
EMPLEADO como clave fornea en la misma
relacin EMPLEADO y la llamamos codSuper :
EMPLEADO (code , nome , pat , mat , suel , sex , fechNac , codSuper , nDep)
Para el caso de controla se trata de PROYECTO :

departamento
controla
proyecto
Incluimos la clave primaria numdepa de la relacin

DEPARTAMENTO como clave fornea en la relacin
PROYECTO y la llamamos nDepa :
PROYECTO ( nump , nomp , lugar , nDepa )

Por cada tipo de relacin M : N R , se crea una nueva

relacin S para representar R. Se incluyen como atributos
de clave fornea en S, las claves primarias de las relaciones
que representan los tipos de entidades participantes. Su
combinacin constituir la clave primaria de S.
Incluir tambin todos los atributos simples ( y los
componentes simples de atributos compuestos) del tipo de
relaciones M : N como atributos de S.
Aqu tomamos el tipo de relaciones M : N trabaja en
empleado
Trabaja
en
proyecto
horas
Y creamos el esquema de relacin LABORA_EN. Incluir aqu las

claves primarias code de EMPLEADO y nump de PROYECTO como
las claves foraneas cEmp y nProy
LABORA_EN ( cEmp , nProy )
Tambin debemos incluir el atributo horas del tipo de

relaciones trabaja en :
LABORA_EN ( cEmp , nProy , horas )

La clave primaria de la relacion LABORA_EN es la
combinacin de los atributos { cEmp , nProy }

NOTA :
Siempre es posible transformar las relaciones 1:1 o 1:N de manera similar a como se
hace con las relaciones M:N. Esto es til cuando hay pocos ejemplares de relaciones, a fin de
evitar valores nulos en las claves forneas. As la clave primaria de la relacin vinculo ser la
clave fornea de solo una de las relaciones entidad participantes.
En el caso de una relacin 1:N , esta ser la relacin entidad del lado N
En el caso de una relacin 1:1 se eligir la relacin entidad con participacin total ( si existe )
Por cada atributo multivaluado A se crea un esquema de

relacin R que incluye el atributo multivaluado de A , ms el
atributo de la clave primaria K del tipo de entidades o de
relaciones que tiene a A como atributo. La clave primaria de
R es la combinacin de A y K. Si el atributo multivaluado es
compuesto, se incluyen sus componentes simples
El tipo de entidades DEPARTAMENTO posee el atributo
multivaluado lugares . Entonces creamos un esquema de
relacin que llamaremos lugares_depa que debe contener
el atributo lugares de DEPARTAMENTO que llamaremos
lugarDep, mas la clave primaria numdepa de
DEPARTAMENTO que nombraremos como nDep.
LUGARES_DEPA ( nDep , lugarDep )
La clave primaria de lugares_depa es la combinacin de

nDep y lugarDep
Entonces el esquema de base de datos relacional quedara :

ESQUEMA DE LA BASE DE DATOS RELACIONAL

ABC
EMPLEADO
code
nome
pat
mat
suel
sex
fechNac codSuper nDep
DEPARTAMENTO
numdepa
nomd
codJefefe
fechIniJefe
LUGARES_DEPA
nDep
lugarDep
PROYECTO
nump
nomp
lugar
LABORA_EN
cEmp
nProy
HIJO
code
apemat
sexo
fechanac
horas
nDepa
Para tipos de relaciones con grado > 2 normalmente son

raros los tipos de relaciones n-arias, pero si se da el caso
debemos poder realizar la transformacin.
Para esto si se tiene un tipo de relaciones n-aria R, se crea
un esquema de relacin S, donde se incluyen las claves
primarias de los tipos de entidades que participan del tipo de
relaciones R, formando as la clave primaria de S . Incluir
tambin los atributos del tipo de relacin R. Si hay atributos
compuestos , usar sus componentes simples.
EJEMPLO :
Un grupo de proveedores suministran repuestos a los
proyectos de una compaa que se dedica a la generacin
de energa elctrica.
cant
ruc
nom
codProv
PROVEEDOR
numProy
suministrar
codRep
nomProy
PROYECTO
descrip
REPUESTO
Los esquemas resultantes son :

PROVEEDOR ( codProve , nom , ruc )
PROYECTO ( numProy , nomProy )
REPUESTO ( codRep , descrip )
SUMINISTRAR ( codProve , numProy , codRep , cant )
Integridad
Referencial :
PROVEEDOR
codProve nom
ruc
codProve
numProy
numProy
SUMINISTRAR
codRep
cant
PROYECTO
nomProy
codRep
REPUESTO
descrip
4500
ING
E
NIE
R
IA
AN
JU
El termino normalizacin se refiere a la

manera en que los atributos son agrupados
en los esquemas de relaciones de una base
de datos, a fin de evitar anomalas y
problemas que pueden ocurrir con los
datos.
M
Cuando agrupamos atributos para formar un

esquema de relacin, buscaremos que exista un
significado asociado a los atributos escogidos.
La semntica especifica que relacin hay entre los
valores de los atributos de una tupla.
Cuanto mas fcil sea explicar la semntica de la
relacin , mejor ser el diseo del esquema
correspondiente.
EJEMPLO :
El significado del esquema de relacin empleado es sencillo :
cada tupla representa a un empleado, con valores para su
cdigo, nombre, fecha de nacimiento, sexo, sueldo y para el
numero de departamento al que pertenece ( nDep ). El
atributo nDep es una clave fornea que representa un vnculo
implcito entre empleado y departamento, es decir un
empleado pertenece a un departamento.
EMPLEADO
codEm
nom
fechNac
direc
sexo
suel
nDep
DEPARTAMENTO
numDep
nom
codJefefe
fechIniJefe
Son problemas que se presentan en el manejo de los datos,

ocasionados por un mal diseo de la base de datos. Estas
anomalas pueden clasificarse en :
Anomalas de Insercin
Anomalas de Eliminacin
Anomalas de Modificacin
Aqu vemos un mal diseo, donde como se nota hay datos de

empleado y de departamento juntos.
EMPLEADO
codEm
nom
fechNac
direc
suel
nDep nomDep
codJefe
100
Soler Ana
10-06-65
Flores 129
3400
Ingeniera
800
200
Alva Juan
19-03-67
Valles 722
6200
Ingeniera
800
250
Jobe Alan
11-09-69
Mar 1824
3600
Ventas
900
300
Vall Kate
05-02-75
Jan 181
2400
Ventas
900
800
Com Ivan
15-03-72
Grau 485
7600
Ingeniera
999
900
Kori Rony
07-12-59
Lomas 18
7200
Ventas
999
999
Pita Ins
25-03-72
Liz 1151
9500
Gerencia
999
Datos del
empleado
Datos del
departamento
A continuacin veremos mediante dos casos, los problemas

derivados con la insercin :
INSERCIN DE UN NUEVO EMPLEADO : Al insertar un nuevo

empleado, debemos tambin incluir los atributos del departamento al que
pertenece, en caso el empleado todava no sea asignado a ningn
departamento colocaremos nulos.
El problema que puede presentarse es cuando ingresemos mal los datos del
departamento de algn empleado. As tendremos empleados que trabajan en el
mismo departamento, donde la informacin del departamento es inconsistente.
EMPLEADO
codEm
nom
fechNac
direc
suel
nDep nomDep
codJefe
100
Soler Ana
10-06-65
Flores 129
3400
Ingeniera
800
200
Alva Juan
19-03-67
Valles 722
6200
Ingeniera
800
250
Jobe Alan
11-09-69
Mar 1824
3600
Ventas
900
300
Vall Kate
05-02-75
Jan 181
2400
Ventas
900
800
Com Ivan
15-03-72
Grau 485
7600
Ingeniera
999
900
Kori Rony
07-12-59
Lomas 18
7200
Ventas
999
999
Pita Ins
25-03-72
Liz 1151
9500
Gerencia
999
350
More Ann
15-11-75
Onda 156
3500
Ventas
800
mal
INSERCIN DE UN NUEVO DEPARTAMENTO : cuando se inserta un

nuevo departamento, debemos tener en cuenta que todava no tiene empleados .
Por tanto debemos colocar valores nulos en los atributos de empleado
Un problema es que la clave primaria codEm del empleado no puede ser nula
Otra anomala es que cuando insertemos el primer empleado para ese
departamento, ya no har falta la tupla con valores nulos.
codEm
EMPLEADO
nom
fechNac
direc
suel
nDep nomDep
codJefe
100
Soler Ana
10-06-65
Flores 129
3400
Ingeniera
800
200
Alva Juan
19-03-67
Valles 722
6200
Ingeniera
800
250
Jobe Alan
11-09-69
Mar 1824
3600
Ventas
900
300
Vall Kate
05-02-75
Jan 181
2400
Ventas
900
800
Com Ivan
15-03-72
Grau 485
7600
Ingeniera
999
900
Kori Rony
07-12-59
Lomas 18
7200
Ventas
999
999
Pita Ins
25-03-72
Liz 1151
9500
Gerencia
999
nulos
Finanzas
950
Nuevo
departamento
Este problema se relaciona con el segundo caso de anomala de insercin.

Por ejemplo, si en un departamento trabajan tres empleados y estos deciden
renunciar, como es natural debemos eliminarlos de la relacin, ocurrir
entonces que se perder toda la informacin de ese departamento.
EMPLEADO
codEm
nom
fechNac
direc
suel
nDep nomDep
codJefe
100
Soler Ana
10-06-65
Flores 129
3400
Ingeniera
800
200
Alva Juan
19-03-67
Valles 722
6200
Ingeniera
800
250
Jobe Alan
11-09-69
Mar 1824
3600
Ventas
Ventas
900
300
Vall Kate
05-02-75
Jan 181
2400
Ventas
900
800
Com Ivan
15-03-72
Grau 485
7600
Ingeniera
999
900
Kori Rony
07-12-59
Lomas 18
7200
Ventas
Ventas
999
999
Pita Ins
25-03-72
Liz 1151
9500
Gerencia
999
codEm
nom
fechNac
direc
suel
nDep nomDep
codJefe
100
Soler Ana
10-06-65
Flores 129
3400
Ingeniera
800
200
Alva Juan
19-03-67
Valles 722
6200
Ingeniera
800
800
Com Ivan
15-03-72
Grau 485
7600
Ingeniera
999
999
Pita Ins
25-03-72
Liz 1151
9500
Gerencia
999
En el ejemplo dado, si alteramos el valor de alguno de los atributos de un

departamento ( por ejemplo el cdigo del jefe de Ingeniera de Ana soler )
codEm
100
nom
Soler Ana
fechNac
10-06-65
direc
suel
Flores 129
nDep nomDep
3400
Ingeniera
codJefe
950
800
Nos veramos obligados a actualizar todas las tuplas de todos los empleados
del departamento de Ingeniera. De lo contrario la base de datos se tornara
inconsistente.
SOLUCION A LAS ANOMALIAS : Descomponer la relacin, separando la
parte que es responsable de la generacin de las anomalas. En este ejemplo
seran los atributos del departamento que pasaran a formar una nueva
relacin :
EMPLEADO
codEm
nom
fechNac
direc
suel
nDep
DEPARTAMENTO
numDep
nomDep
codJefefe
Asegurarse de crear
el vnculo necesario :
FK - PK
Fue Edgar F. Codd quien en 1972 propuso el proceso de

normalizacin, as cualquier esquema de relacin se puede
someter a una serie de pruebas para certificar si pertenece
o no a cierta forma normal, que originalmente fueron tres :
primera, segunda y tercera formas normales.
Posteriormente Boyce y Codd replantearon la tercera forma
normal que se conoce hoy como Boice - Codd Norm Form
( BCNF). La segunda y tercera formas se fundamentan en
el concepto de dependencias funcionales.
Despus se formularon la cuarta y quinta forma normal,
basados en dependencias multivaluadas y dependencias
de reunin.
Se implement para prohibir atributos compuestos, multivaluados y sus

combinaciones. Entonces debemos evitar grupos repetitivos de datos.
EJEMPLO :
DEPARTAMENTO
Para este
ejemplo el
esquema
departamento
no esta en
1FN
numDep
nomDep
numDep
nomDep
codJefefe
lugaresDep
Grupo
repetitivo
Un departamento puede estar distribuido en varios lugares.

Por ejemplo el Departamento de Ingeniera ( numDep=5)
puede tener oficinas en Cuzco y Tacna (lugaresDep)
codJefefe
lugaresDep
Ingeniera
400
Tacna
Ingeniera
400
Cuzco
Administracin
200
Trujillo
El atributo multivaluado obliga a replicar

la informacin del departamento,
generando redundancia. Esta solucin
ya esta en 1FN , pero no es aceptable
porque genera anomalas de
actualizacin.
LA SOLUCION :
Es eliminar de la relacin departamento el atributo lugaresDep ( grupo
repetitivo) que viola la 1FN y colocarlo en otra relacin aparte que
llamaramos lugares_depa . Esta nueva relacin tendra como atributos : la
clave primaria de la relacin departamento ( para asegurar el vnculo entre
estas dos relaciones ) y lugarDep ( contiene los nombres de los lugares )
La clave primaria de esta nueva relacin es la combinacin :
{ numDep , lugarDep }
numDep
LUGARES_DEPA
numDep
lugarDep
DEPARTAMENTO
numDep
nomDep
LUGARES_DEPA
codJefefe
lugarDep
Trujillo
Tacna
Cuzco
DEPARTAMENTO
numDep
nomDep
Ingeniera
Administracin
codJefefe
400
200
EJEMPLO :
Se tiene el esquema OBRERO. Cada obrero puede tener mas de un oficio,
as, el obrero Jorge Huaman es carpintero, albail y pintor y posee 3, 8 y 2
aos de experiencia en esos oficios.
Esto quiere decir que los atributos oficio y aosExp forman una unidad
multivaluada, con lo que se esta violando la 1FN
Dicho de otro modo {oficio, aosExp} ocurren varias veces en una tupla. De
esta forma la tupla ya no es plana.
Grupo
OBRERO
repetitivo
codObr
nom
fechNac direc
jornal codJefe oficio aosExp
OBRERO
codObr
nom
fechNac
direc
jornal
codJefe oficio
aosExp
300
Huaman Jorge
10-05-67
Surco
25
800
carpintero
300
Huaman Jorge
10-05-67
Surco
25
800
albail
300
Huaman Jorge
10-05-67
Surco
25
800
pintor
350
Sulca Amrico
22-11-70
Comas
30
900
electrnico
SOLUCION :
Es eliminar el grupo repetitivo {oficio, aosExp} de la relacin obrero, que
viola la 1FN y colocarlo en otra relacin aparte que llamaramos
habilidades . Esta nueva relacin tendra como atributos : la clave primaria
codObr de la relacin obrero ( para asegurar el vnculo entre estas dos
relaciones ) , adems de oficio y aosExp.
La clave primaria de la nueva relacin habilidades estara conformada por :
{ codObr , oficio }
HABILIDADES
codObr
oficio
aosExp
OBRERO
codObr
nom
fechNac
direc
jornal
codJefe
Sea el esquema de relacin R :

R ( A1 , A2 , A3 , . . . Ak , Ak+1 , . . . Am , Am+1 , . . . At , At+1 , . . . An-1 , An )
Y los subconjuntos
Se dice que Y depende funcionalmente de X ,
que X determina Y
que X implica Y
implicante
implicado
Si y solo si , cada valor de X tiene asociado en todo momento un nico valor de Y
EJEMPLO :
Tenemos la relacin :
LIBRO ( cod_Lib, titulo, editorial )
Se puede decir que el

cdigo de un libro
determina su ttulo.
Aqu se dice que titulo depende funcionalmente de codLib

Este concepto de dependencia funcional tambin nos dice que el titulo es
una informacin acerca del libro
GRAFICAMENTE :
Cod_Lib
Podemos mostrar grficamente la dependencia funcional :

determina
determina
Cod_Lector
determina
Titulo , editorial
Fech_prestamo , fecha_devol
nombre , direc , fono
Veamos las DF en el siguiente esquema de relacin :
EJEMPLO :
EMP_PROY
codEmp
numProy
nomEmp nomProy lugarProy
EMP_PROY ( codEmp, numProy, nomEmp, nomProy, lugarProy )
Se lee :
codEmp
nomEmp
numProy
{ nomProy , lugarProy }
El valor de cdigo del empleado ( codEmp ) determina de manera nica el

nombre de ese empleado ( nomEmp )
El valor del nmero de proyecto ( numProy ) determina de manera nica el
nombre del proyecto ( nomProy ) y su lugar ( lugarProy )
Veamos las DF en este otro esquema de relacin :
EJEMPLO :
EMP_DEPTO
codEmp
nomEmp
fechNac direc numDep nomDep codJefe
EMP_DEPTO ( codEmp, nomEmp, fechNac, direc, numDep, nomDep. codJefe )

codEmp
{ nomEmp , fechNac , direc }
numDep
{ nomDep , codJefe }
EJEMPLO :
Veamos cuando no existe dependencia funcional :

DICTAR
PROFESOR
CURSO
TEXTOBASE
Canales Julio
Algoritmos II
Cairo
Canales Julio
Base de Datos
Korth
Arias Freud
Visual Basic
Joyanes
Pacheco Rosa
Leng. Prog I
Vasquez
Se puede decir que profesor determina funcionalmente curso ?
RESPUESTA :
El hecho de que Canales julio dicta Algoritmos II as como Base de Datos
nos lleva a concluir que profesor no determina funcionalmente curso
EJEMPLO :
Veamos cuando no existe dependencia funcional :
EMPLE-PROY
codEmp
numProy
nomEmp sueldo nomProy fechFin
EMP_PROY ( codEmp, numProy, nomEmp, sueldo, nomProy, fechFin )
Cdigo de empleado (codEmp) no es funcionalmente dependiente de

sueldo, porque mas de un empleado podra tener el mismo sueldo
codEmp no es funcionalmente dependiente de numProy, ya que mas de
un empleado puede trabajar para el mismo proyecto
Pero fecha de fin de proyecto ( fechFin) si es funcionalmente

dependiente de nmero de proyecto (numProy)
Conocida
tambin
como TOTAL
Una simple dependencia funcional se define as :
Si X es un subconjunto de dos atributos :
X ( X1 , X2 )
Se dice que Y tiene dependencia funcional completa de X si depende

funcionalmente de X pero no depende de X1 ni de X2 , esto es :
x1
x2
Lo que se representa como :
Veamos las DF en el siguiente esquema de relacin :
EJEMPLO :
Dependencias funcionales parciales
EMP_PROY
codEmp
numProy
horas nomEmp nomProy lugarProy
Dependencia funcional completa
codEmp
nomEmp
numProy
{ nomProy , lugarProy }
Dependencia funcional parcial
La combinacin de valores de ( codEmp ) y ( numProy ) determinan de

manera nica el nmero de horas ( horas ) que el empleado trabaja en un
proyecto cada semana. Ni cdigo de empleado, ni tampoco nmero de
proyecto, determinan por si solos, las horas trabajadas, ya que un
empleado puede tener diferentes horas trabajadas en diferentes
proyectos, asi como un proyecto tiene diversas horas de trabajo de
diferentes empleados. Por tanto, respecto al atributo HORAS tenemos
una dependencia funcional completa :
{ codEmp , numProy }
horas
EJEMPLO :
Analizemos el siguiente esquema de relacin :
PRESTAR
codLib codLector titulo
editorial nombre direc fono
fechPrest
PRESTAR ( codLib, codLector, titulo, editorial, nombre, direc, fono, fechPrest )

Dado un cdigo de libro ( codLib ) y un cdigo de lector ( codLector )
existe una nica fecha de prstamo ( fechPrest ) para ese libro. Ni cdigo
de libro, ni tampoco cdigo de lector, determinan por si solos, la fecha de
prstamo, ya que un libro se puede prestar en diversas fechas, asi
como un lector puede recibir libros prestados en diferentes fechas.
Por tanto, tenemos una dependencia funcional completa :
{ codLib , codLector }
fechPrest
EJEMPLO :
Indique grficamente las dependencias funcionales del

siguiente esquema de relacin :
PROGRAM(codProgramador, codModulo, nomProgramador, nomModulo, horasTrab )

RESPUESTA :
PROGRAM
codProgramador codModulo nomProgramador nomModulo horasTrab
Es aquel atributo que forma parte de cualquier clave primaria o es clave

candidata de una relacin.
Clave primaria
EMP_PROY
codEmp
Atributo
PRIMO
numProy
horas nomEmp nomProy lugarProy
Atributo
PRIMO
Atributos
NO
PRIMOS
Un esquema de relacin esta en segunda forma normal , si esta en

primera forma normal y todo atributo no primo posee una
dependencia funcional completa de la clave primaria de la relacin.
El siguiente esquema representa un mal diseo, el cual si
bien no tiene atributos compuestos ni grupos repetitivos y
por tanto esta en 1FN , sin embargo no esta en 2FN.
EJEMPLO :
EMP_PROY
codEmp
numProy
horas nomEmp
nomEmp nomProy
Clave primaria
lugarProy
NOTA:: elelnico
nicoatributo
atributono
no
NOTA
primoque
quetiene
tienedependencia
dependencia
primo
funcionalcompleta
completaes
eshoras
horas
funcional
El atributo no primo nomEmp viola la 2FN debido a que su dependencia

funcional de la clave primaria es solo parcial. Es decir, depende
funcionalmente solo parcialmente de la clave primaria ( solo de codEmp ).
EMP_PROY
codEmp
numProy
horas nomEmp nomProy

nomProy lugarProy
Clave primaria
El atributo no primo nomProy viola la 2FN debido a que su dependencia

funcionalmente solo parcialmente de la clave primaria ( solo de numProy ).
EMP_PROY
codEmp
numProy
lugarProy
lugarProy
Clave primaria
El atributo no primo lugarProy viola la 2FN debido a que su dependencia

funcionalmente solo parcialmente de la clave primaria ( solo de numProy ).
ESTO SE ACOSTUMBRA GRAFICAR ASI :
Dependencias funcionales parciales
EMP_PROY
codEmp
numProy
lugarProy
lugarProy
SOLUCION :
Como el esquema de relacin no esta en 2FN, debemos normalizar a varias
relaciones en 2FN en las que los atributos no primos originales presenten una
dependencia funcional total respecto a las nuevas claves primarias formadas :
EMP_PROY
codEmp
numProy
lugarProy
solucin
Identificadas las dependencias, estn
definidas las nuevas relaciones
EMPLE
codEmp
nomEmp
HORAS_TRAB
codEmp
numProy
PROYEC
horas
numProy numProy
lugarProy
EJERCICIO :
Una empresa comercializadora posee varias sucursales en diversas ciudades del
pas. Donde cada sucursal es identificada por su cdigo de sucursal.
Cada sucursal tiene su staff de empleados, a los cuales se les reconoce por un
cdigo de empleado en la sucursal , el cual siempre empieza con el nmero 100.
Lo que significa que para distinguir a un empleado de otro es necesario conocer el
cdigo de la sucursal y el cdigo que el empleado tenga en la sucursal. Es
importante registrar el DNI , la hora de ingreso al trabajo y el nombre de la
sucursal.
Entonces se pide normalizar el siguiente esquema de relacin :
EMPLEADO
codigoDeSucursal
codigoEnSucursal DNI sueldo horaIngre nomSucursal
Clave primaria
Atributo
primo
( Clave candidata )
Atributos
no primos
SOLUCION :
Aqu de hecho estn combinados datos de sucursal y datos de empleado.
Descartando el atributo primo DNI, por que presenta la propiedad de unicidad (
clave candidata ) , nos centraremos en los atributos no primos : sueldo,
horaIngre y nomSucursal.
Datos de sucursal
: horaIngre , nomSucursal
Datos de empleado : DNI , sueldo
1. Construyendo esquema para la sucursal :

sucursal
codigoDeSucursal
horaIngre nomSucursal
Ya esta en 1FN ( no hay

grupos repetitivos ) y esta
en 2FN ya que no hay
clave mltiple. Por tanto
horaIngre y nomSucursal
dependen totalmente de la
clave primaria
2. Construyendo esquema para el empleado :

El sueldo de un empleado no depende nicamente del cdigo del
empleado en la sucursal, porque como ya sabemos estos cdigos se
repiten en cada sucursal. Por tanto :
{codigoDeSucursal , codigoEnSucursal}
sueldo
En consecuencia :
EMPLEADO
codigoDeSucursal
codigoEnSucursal DNI sueldo
Ya esta en 1FN y en 2FN
Suponga que se tiene la siguiente relacin R y sus atributos :
De donde se puede interpretar :

C es funcionalmente dependiente de B y
B es funcionalmente dependiente de A , entonces :
C es funcionalmente dependiente de A
Tenemos as una
dependencia
funcional transitiva
De una manera mas formal :

Sea la relacin : R ( A , B , C )
Donde se presentan las siguientes dependencias funcionales :
A
Entonces podemos decir que C depende transitivamente de A

Esto se representa as :
A
Grficamente :
Ejercicio :
Se sabe que los libros para ser comercializados estn codificados
con un nmero nico conocido como ISBN. Cada cdigo
corresponde a alguna Editorial. Se entiende que cada Editorial tiene
un nico pas de procedencia. Esta situacin puede expresarse en
el siguiente esquema :
LIBRO ( Cdigo, Editorial, Pas )

Aqu se verifican las siguientes dependencias :
Cdigo
Editorial
El cdigo determina una nica editorial

La editorial determina un nico pas de orgen
Y adems se cumple que :
Pas
Una editorial no determina un nico libro,

ya que puede publicar muchos libros
Ejercicio :
En una empresa laboran empleados debidamente codificados. Los
empleados tiene un sueldo bsico de 2000 y trabajan para un solo
proyecto que presenta una fecha de finalizacin y se identifica por
su nmero. Se tiene entonces el siguiente esquema, identifique si
existe alguna dependencia transitiva :
EMPLEPROY ( CodEmp,
CodEmp nomEmp, sueldo, numProy, fecha Fin )
Solucin :
El cdigo del empleado determina un nico proyecto y un proyecto tiene
una nica fecha de finalizacin
EMPLEPROY ( CodEmp,
CodEmp nomEmp, sueldo, numProy, fechaFin )
No es cierto que en un proyecto trabaje un nico empleado

mas bien, en un proyecto trabajan muchos empleados
Entonces se tiene una dependencia transitiva CodEmp

a travs de numProy
fechaFin
EMPLEPROY ( CodEmp, nomEmp, sueldo, numProy, fechaFin )
CodEmp
numProy
fechaFin
Un esquema de relacin esta en 3FN, si esta en 2FN ( no hay

dependencias parciales) y ningn atributo NO primo depende
transitivamente de la clave primaria.
Ejemplo :
Normalizar el siguiente esquema de relacin :
EMPLEPROY
CodEmp nomEmp
sueldo
numProy
dependencia funcional transitiva
fechaFin
Esta en 1FN
por que no
hay grupos
repetitivos
Esta en 2FN
pues no existe
clave
compuesta
Pero la
dependencia
transitiva viola
la 3FN
La solucin es desdoblar empleado y proyecto como esquemas

separados, de esta forma estaramos rompiendo la transitividad :
EMPLEADO
codEmp
nomEmp
sueldo nProy
PROYECTO
numProy
As,
As,ya
yaesta
estaen
en1FN
1FNpor
porque
queno
nohay
hay
grupos
gruposrepetitivos,
repetitivos,en
en2FN
2FNporque
porqueno
no
existen
existendependencias
dependenciasparciales
parcialessobre
sobre
claves
clavescompuestas,
compuestas,yyen
en3FN
3FNpor
porque
que
no
noexisten
existentransitividades.
transitividades.
fechaFin
Ejercicio :
En una empresa un empleado trabaja para un solo
departamento. Vea entonces el siguiente esquema de
relacin y proceda a normalizarlo :
EMP_DEP
CodEmp nomEmp direc numDep nomDep codJef
Esta en 1FN
por que no
hay grupos
repetitivos
Esta en 2FN
pues no existe
clave
compuesta
Pero las
dependencias
transitivas
violan la 3FN
dependencia funcional transitiva
La solucin es desdoblar empleado y departamento como

esquemas separados, de esta forma estaramos rompiendo la
transitividad presentada :
EMPLEADO
codEmp
nomEmp
direc
nDep
DEPARTAMENTO
numDep
As,
As,ya
yaesta
estaen
en1FN
1FNpor
porque
queno
nohay
hay
grupos
gruposrepetitivos,
repetitivos,en
en2FN
2FNporque
porque
no
noexisten
existendependencias
dependenciasparciales
parciales
sobre
sobreclaves
clavescompuestas,
compuestas,yyen
en3FN
3FN
por
porque
queno
noexisten
existentransitividades.
transitividades.
nomDep codJef
Conversin a PRIMERA FORMA NORMAL

A
D
C
E
D
F
E
B
A
G
C D
C
Conversin a SEGUNDA FORMA NORMAL

A
C D
C
B D
C
A
Conversin a TERCERA FORMA NORMAL

A
Un esquema de relacin esta en BCNF, si para toda

dependencia funcional X
Y que se cumple en R ,
Es condicin que X sea una super clave de R.
EJEMPLO :
Se tiene el siguiente esquema donde se distinguen

todas las dependencias :
Empleado ( codEm, nss, sueldo, codDpto, nomDpto)
La primera dependencia :
Se puede afirmar que codEm es una superclave
La segunda dependencia :
Se puede afirmar que nss es una superclave
La tercera dependencia :

Se puede afirmar que codDpto no es una superclave
Esta dependencia funcional viola la BCNF
SOLUCION :
debemos descomponer el esquema :
Empleado ( codEm, nss, sueldo, codDepa )

Departamento ( codDpto, nomDpto)
Empleado ( codEm, nss, sueldo, codDepa )
Ya no hay problema, se cumple la condicin
Departamento ( codDpto, nomDpto)

Aqu tambin se cumple la condicin
EJEMPLO :
Considere que cada proyecto tiene un administrador

y que cada uno maneja un solo proyecto :
Proyecto
administrador Articulo
cantUsada
P1
Castro
Martillo 10
P1
Castro
Taladro 20
P2
Garcia
Taladro 30
P2
Garcia
Sierra
P3
Meneses Martillo 15
22
Identifiquemos las dependencias :
UsoProy ( proyecto, administrador, articulo, cantUsada )

{administrador, articulo} es una superclave
{proyecto, articulo} es una superclave

Aqu hay dos dependencias funcionales :
Administrador
proyecto
proyecto
Administrador
Pero ni administrador ni proyecto son superclaves, por tanto

violan la BCNF
SOLUCION :
debemos descomponer el esquema :
Uso ( proyecto, articulo, cantUsada )

proyecto ( proyecto, administrador )
Uso ( proyecto, articulo, cantUsada )
{proyecto, articulo}
cantUsada
Es una superclave
proyecto ( proyecto, administrador )
Entonces ambos estn en BCNF
Este modelo incluye toda la teora del modelado ER, pero

adems contempla los siguientes conceptos :
Subclase y superclase
Especializacin y generalizacin
Categora
Herencia de atributos
En ocasiones, un tipo de entidades tiene

varias subagrupaciones, por ejemplo el tipo
de entidades
SUPERCLASE
EMPLEADO
puede presentar agrupaciones de entidades como :
SECRETARIA
INGENIERO
TECNICO
GERENTE
EMP_ASAL
EMP_CONT
SUBCLASES
Los miembros de una subclase heredan todos los

atributos de la superclase
Tambin heredan todos los vnculos en los que participa
la superclase
Es el proceso de definir un conjunto de subclases a partir

de un tipo de entidades, conocido como superclase de la
especializacin
EJEMPLO :
El conjunto de subclases
{ SECRETARIA, INGENIERO, TECNICO }
es una especializacin de la superclase :
EMPLEADO
Las subclases de la especializacin se conectan a un circulo

pequeo, el cual se conecta a su vez a la superclase
EMPLEADO
SECRETARIA
TECNICO
INGENIERO
GERENTE
indica direccin
del vnculo
EMP_ASAL
EMP_CONT
Aqu hay tres especializaciones : {secretaria, tcnico, ingeniero}

{ gerente }
{ emp_asal, emp_cont }
Atributo
especifico
EMPLEADO
RAPIDEZ DE
TECLEO
SECRETARIA
PagoHora
NIVEL
TECNICO
ESPECI
INGENIERO
CREDCARD
GERENTE
SUELDO
EMP_ASAL
EMP_CONT
En el caso del gerente no se usa crculo, porque es una sola subclase.
NOMBRE
NSS
DIREC
EMPLEADO
RAPIDEZ DE
TECLEO
PagoHora
NIVEL
SECRETARIA
TECNICO
Tipo de
vnculo
especfico
ESPECI
INGENIERO
CREDCARD
GERENTE
dirige
PROYECTO
SUELDO
EMP_ASAL
EMP_CONT
Razones para incluir clase/subclases en un modelo de datos :

No todos los atributos que deseamos representar se pueden
aplicar a todas las entidades de la superclase. Por ello se crean
subclases para agrupar entidades a las que se puede aplicar
estos atributos( ver diagramas anteriores).
En algunos tipos de relaciones solo pueden participar entidades
que sean miembros de la subclase. Por ejemplo un gerente dirige
un proyecto.
Consiste en dirigir la atencin a entidades, en las cuales

identificamos rasgos comunes y los generalizamos para formar
una superclase.
Por ejemplo : podemos pensar en auto y camin :
placa
velocMax
precio
color
AUTO
numPasjeros
placa
tonelaje
precio
color
CAMION
numEjes
Notamos que existen atributos comunes a ambos
entonces, es posible generalizarlos a un tipo de entidades que

llamaramos VEHICULO.
placa
precio
color
VEHICULO
tonelaje
numEjes
velocMax
AUTO
numPasjeros
CAMION
Lo que se explique aqu sobre la especializacin es tambin vlido

para la generalizacin, ya que ambos conceptos son caras de una
misma moneda.
SUBCLASES DEFINIDAS POR PREDICADO
Es una condicin
restrictiva que conduce
al uso de un atributo en
la superclase que
permite especificar la
pertenencia a la alguna
subclase, en funcin de
un predicado que se
coloca junto a la
subclase y entre
comillas.
NSS
NOMBRE
DIREC
TIPOTRAB
EMPLEADO
RAPIDEZ DE
TECLEO
tipoTrab =
Secretaria
SECRETARIA
tipoTrab =
Ingeniero
tipoTrab =
Tcnico
NIVEL
TECNICO
ESPECI
INGENIERO
SUBCLASES DEFINIDAS POR ATRIBUTO

En este modo las
especializaciones estn
definidas por un atributo.
Se representan
colocando el nombre del
atributo de definicin
junto a la lnea que se
aproxima a la superclase.
NOMBRE
NSS
DIREC
TIPOTRABAJO
EMPLEADO
tipoTrabajo
RAPIDEZ DE
TECLEO
SECRETARIA
NIVEL
TECNICO
ESPECI
INGENIERO
Cuando no hay una condicin que determine la pertenencia, se dice

que la subclase esta definida por el usuario
Especifica que las subclases de una especializacin deben ser

disjuntas : Una entidad puede ser miembro de a lo mas una de las
subclases de la especializacin. Se usa una d dentro del circulo
para denotar disyuncin
NSS
Un empleado para este
NOMBRE
DIREC
caso puede ser
nicamente solo una
EMPLEADO
de las siguientes
especializaciones :
secretaria o tcnico o
ingeniero
d
RAPIDEZ
DE TECLEO
SECRETARIA
NIVEL
TECNICO
ESPECI
INGENIERO
Si las subclases no son disjuntas, sus conjuntos de entidades

pueden traslaparse, as una misma entidad puede ser miembro de
mas una subclase de la especializacin. En este caso se usa una O
en el circulo.
numComp
descrip
COMPONENTE
O
numDibuj
Fecha
Fabricacin
COMPONENTE_FABRICADO
numLote
proveedor
Precio
Lista
COMPONENTE_COMPRADO
Puede ser total o parcial.
Una restriccin de especializacin total especifica que

toda entidad de la superclase debe ser miembro de alguna subclase
de la especializacin. Se denota con una lnea doble que conecta la
superclase con el crculo.
NOMBRE
NSS
EMPLEADO
RAPIDEZ
DE TECLEO
SECRETARIA
NIVEL
TECNICO
ESPECI
INGENIERO
DIREC
Todo empleado debe ser

un empleado asalariado
o un empleado
contratado por horas
SUELDO
EMP_ASAL
PagoHora
EMP_CONT
{emp_asal, emp_cont} es una especializacin total de empleado
Una restriccin de especializacin parcial permite que

alguna entidad de la superclase no pertenece a ninguna subclase de
la especializacin. Se denota con una lnea simple. Por ejemplo , si
algunas entidades empleado no pertenecen a ninguna de las
subclases {secretaria,tecnico, ingeniero}, esa especializacin ser
parcial.
NOMBRE
NSS
DIREC
EMPLEADO
RAPIDEZ
DE TECLEO
SECRETARIA
NIVEL
TECNICO
ESPECI
INGENIERO
SUELDO
EMP_ASAL
PagoHora
EMP_CONT
Resumiendo, existen cuatro tipos de especializacin :

DISJUNTA TOTAL
DISJUNTA PARCIAL
TRASLAPADA TOTAL
TRASLAPADA PARCIAL
REGLAS DE INSERCION y ELIMINACION

La eliminacin de una entidad de una superclase implica que
automticamente se le elimina de todas las subclases a las que
pertenece.
La insercin de una entidad en una superclase implica que la entidad
se inserta por fuerza en todas las subclases definidas por predicado
para las cuales la entidad satisface el predicado de definicin.
La insercin de una entidad en una superclase de una especializacin

total implica que la entidad se insertar por fuerza en por lo menos
una de las subclases de la especializacin.
Son rboles de clases y subclases, mediante los cuales podemos

mostrar la especializacin y generalizacin de las clases.
JERARQUIA DE ESPECIALIZACION :
Tiene la restriccin de que toda subclase participa como tal en
un vinculo clase/subclase. Como es obvio tambin existirn
jerarquas de Generalizacin.
RETICULA DE ESPECIALIZACION :
Aqu una subclase puede ser subclase en mas de un vinculo
clase/subclase. Como es obvio tambin existirn retculas de
Generalizacin.
sexo
nomb
dni
fechNac
PERSONA
JERARQUIA DE
ESPECIALIZACION :
Tiene la restriccin de
que toda subClase
participa como tal en un
vinculo clase/subClase.
especialidad
numCarnet
sueldo
EMPLEADO
EX-ALUMNO
ESTUDIANTE
fechIngre
cargo
grados
categ
grado
OFICINISTA
PROFESOR
fecha
especialidad
ESTUD POST
GRADO
Ttulo_Prof
ESTUD PRE
GRADO
sexo
nomb
dni
Aqu una subclase

puede ser subclase en
mas de un vnculo
clase/subclase
fechNac
PERSONA
RETICULA DE
ESPECIALIZACION :
especialidad
numCarnet
sueldo
EMPLEADO
EX-ALUMNO
grados
cargo
grado
OFICINISTA
horas
PROFESOR
categ
Proyecto
ESTUDIANTE
fechIngre
fecha
especialidad
ESTUD POST
GRADO
ESTUDIANTE
ASISTENTE
d
ASISTENTE_INVESTIGADOR
curso
Ttulo_Prof
ASISTENTE_PROF
ESTUD PRE
GRADO
Herencia
Mltiple
NOMBRE
NSS
Herencia Mltiple
DIREC
RETICULA DE
ESPECIALIZACION
EMPLEADO
RAPIDEZ
DE TECLEO
PagoHora
ESPECI
SECRETARIA
TECNICO
SUELDO
NIVEL
INGENIERO
GERENTE
EMP_ASAL
EMP_CONT
GERENTE_DE_INGENIERIA
Gerente_de_ingeniera es un subconjunto de la interseccin de

las tres superclases. Asi el gerente de Ingeniera debe ser un
Ingeniero, un gerente y un empleado asalariado.
Una categora nos permite crear subclases que posean dos o mas
superclases, tal que esta subclase o categora pueda ser en un momento dado
cualquiera de las superclases.
Para indicar una categora se usa un crculo con la letra U dentro.
Una categora es un subconjunto de la unin de sus superclases.
Por ejemplo modelar el escenario donde un vehiculo pueda ser propiedad de
una persona, un banco o una compaa.
PERSONA
BANCO
U
Dueo es una
subclase de la
unin persona,
banco y
compaa
DUEO
COMPAIA
Esto expresa :
Una persona puede poseer un vehculo
Un banco puede poseer un vehculo
Una compaa puede poseer un vehculo
posee
VEHICULO
A esto se le puede aadir atributos,

cardinalidad, participacin, etc
Ejemplo modelar el hecho de que el vehculo en cuestin, puede ser un

auto o un camin
PERSONA
BANCO
COMPAIA
DUEO
La herencia de atributos funciona de

manera mas selectiva en las
categoras, en comparacin con las
jerarquas o retculas. As por
ejemplo cada entidad dueo hereda
los atributos de una compaa, o
una persona o un un banco,
dependiendo de la superclase a la
que pertenezca
posee
VEHICULO
U
AUTO
Especializacin
o generalizacin
INGENIERO
GERENTE
EMP_ASAL
GERENTE DE
INGENIERIA
CAMION
En este caso de retcula la subclase

gerente de ingeniera hereda todos los
atributos de sus superclases
Ejercicio :
persona
tipo
d
profesor
estudiante
1
asesora
Tipo=3
N
matricula
Estud_post
N
1
Ong_subvenc
pertenece
Seccin actual
apoya
dirige
Sem=2000-1
Prof_invest
sem
Seccin
dicta
N
tiene
departamento
1
gestiona
curso
NOMBRE
NSS
DIREC
TIPOTRAB
EMPLEADO
empleado(nss,
nss nombre, direc)
secretaria(nss,
nss rapidezdeTecleo)
tecnico(nss,
nss nivel)
secretaria
RAPIDEZ
DE TECLEO
SECRETARIA
ingeniero(nss,
nss especi)
tecnico
ingeniero
NIVEL
TECNICO
ESPECI
INGENIERO
Subclases definidas
por predicado
placa
precio
codVehi
generalizacin
VEHICULO
d
numPasajeros
AUTO
veloMax
tonelaje
CAMION
Eliminando la
generalizacin
numEjes
auto( placa, codVehi, precio, numpasajeros, veloMax)

camion( placa, codVehi, precio, numejes, tonelaje)
NOMBRE
NSS
DIREC
TIPOTRAB
EMPLEADO
Usando el
atributo de tipo
TIPOTRAB
d
RAPIDEZ
DE TECLEO
SECRETARIA
NIVEL
TECNICO
ESPECI
INGENIERO
empleado(nss,
nss nombre, direc, tipoTrab, rapidezdeTecleo, nivel, especi)
numComp
descrip
COMPONENTE
Usando campos
booleanos
O
numDibuj
Fecha
Fabricacin
COMPONENTE_FABRICADO
numLote
proveedor
Precio
Lista
COMPONENTE_COMPRADO
componente(numComp,
numComp descrip, flag_F, numDibuj, fechFabricacion,
flag_C, proveedor, precioLista)

Cur So BD Completo

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Cur So BD Completo

Enviado por

Direitos autorais:

Formatos disponíveis

CINFE

Sistema circulatorio humano

Sistemas hechos por el

Conjunto de componentes interrelacionados que permiten

EN TES DEL ESTADO

No es lo mismo el clculo de notas de un

La informacin resulta oportuna si esta

Ha de ser comprensible e importante. El

Los resultados obtenidos deben parecerse a lo

Debe estar protegida contra daos fsicos,

El grfico siguiente ilustra el comportamiento de la informacin,

ETAPAS PARA LA GESTION DE DATOS

Archivo de cuentas corrientes

........ ........ ....... .......

........ ........ ....... .......

2. Gestin centralizada de los datos

Alto nivel de redundancia

Las diversas copias de los mismos datos pueden no

Uso excesivo de recursos humanos

Las aplicaciones dependen de los archivos

Los archivos pueden ser incompatibles

Datos separados y aislados

Tendencia a crear ms y ms archivos

Es una coleccin compartida de datos sin

Es un conjunto de programas que permite a los usuarios

Usuarios / Programadores / DBA

Naturaleza autodescriptiva de los SGBD

Independencia respecto a programas y datos

Manejo de mltiples vistas de los datos

Restriccin de accesos no autorizados

Representa el diseo global

Existen tres esquemas que describen la arquitectura de una

Un Base de Datos presenta una arquitectura de tres niveles,

Correspondencia : proceso de transformar pedidos y respuestas

tiene un esquema interno o fsico.

Un SGBD proporciona dos tipos de lenguajes : uno para

Permite especificar los esquemas Conceptual e Interno. Da

Permite realizar las principales operaciones de manipulacin

Administrador de la Base de Datos

Entre las interfaces amables con el usuario que pueden ofrecer

Gestor de memoria intermedia

Es una coleccin de herramientas conceptuales para describir

1. Modelos de alto nivel o conceptuales

Son modelos lgicos basados en objetos y se usan para

El modelo Entidad - Relacin

basado en una percepcin del mundo real que consta de

El modelo orientado a objetos

Son muy usados en los SGBD comerciales. Representan los

El modelo de datos Relacional

El modelo de datos de Redes

Se basa en el empleo de colecciones de registros y las

El modelo de datos Jerrquico

Similar al modelo de redes, pero los registros se organizan en

Describen como se almacenan los datos en el computador al

Esta basado en una percepcin del mundo real que

son asociaciones entre dos o mas entidades

son las propiedades especficas que describen

TIPO DE ENTIDADES define un conjunto de entidades que

Es un modelo de datos de alto nivel que se emplea en el

son las propiedades especficas que describen

define un conjunto de entidades que

son asociaciones entre dos o mas tipos de entidades que

Cardinalidad 1:N para E1:E2 en R