Escuela de Ingeniera de Sistemas e Informtica

Curso de Bases de datos I

Segundo semestre de 2014
Prof. Jaime Octavio Albarracn Ferreira
1

Propsitos
Entender la teora fundamental de Bases de datos y del modelamiento de
datos
Distinguir una relacin normal de una anormal y saber normalizarla
Comprender el significado e interpretacin de un modelo E/R (MER)
Enunciar y explicar las reglas de integridad de las bases de datos
Saber investigar, entender, deducir y plantear un MER

Competencias:
Al concluir el curso el estudiante:
Comprender la teora general de Bases de datos
Comprender el significado de una relacin y del modelo relacional
Disear modelos de datos reconociendo relaciones normales y sus
atributos, as como sus interrelaciones y semntica
Reconocer la integridad de una Base de datos y aplicar sus reglas.
Plantear modelos de datos que satisfagan las expectativas derivadas de los
2
problemas encontrados en la realidad.

Objetivosdelcurso
El estudiante comprender en este primer curso de Bases de datos:
1. La teora fundamental de bases de datos
2. Los conceptos de normalizacin de Bases de datos y las diferentes
formas normales
3. El diseo de Bases de datos segn la normalizacin
4. Los conceptos de modelamiento semntico, correspondencia y
cardinalidad
5. El diseo de Bases de datos segn el modelamiento semntico
6. Los conceptos de integridad de las Bases de datos y la reglas de
integridad
7. Cmo disear y plantear una base de datos para una empresa
especfica.
3

Contenidodelcurso
1.

Introduccin a las Bases de datos

1.1 Definicin de una Base de datos (DB)
1.2 Definicin de un DBMS y sus funciones
1.3 Tipos de usuarios de una DB

2.

Niveles de una Base de datos

2.1 Nivel interno
2.2 Nivel conceptual
2.3 Nivel externo
2.4 Mapeo de datos

3.

Propiedades de una Base de datos

3.1 Independencia de datos
3.2 Seguridad
3.3 Integridad
4

3.4 Respaldo y recuperacin

3.5 Control de redundancia
3.6 Consistencia
3.7 Auditoria
3.8 Control de concurrencia
4.

5.

Software complementario de un DBMS

4.1 Administrador de la Base de datos (DBA)
4.2 Diccionario de datos
4.3 Lenguajes de la Base de datos
4.3.1 DDL (Lenguaje de descripcin de datos)
4.3.2 DML (Lenguaje de manejo de datos)
Clases de DBMS
5.1 Enfoque jerrquico
5.2 Enfoque en red
5.3 Enfoque relacional
5

6.

Modelo relacional
6.1 Nivel conceptual
6.2 Nivel externo o vistas
6.3 Nivel interno
6.4 El lenguaje de datos
6.5 Ejemplo utilizando el lenguaje de datos SQL.

7. Diseo de Bases de datos: El modelo relacional y la normalizacin.

7.1 La relacin universal
7.2 Primera forma normal (1FN)
7.3 Concepto de claves y dependencias funcionales
7.4 Normalizacin de la relacin 1FN
7.5 Segunda forma normal (2FN)
7.6 Normalizacin de las relaciones 2FN
7.7 Tercera forma normal (3FN)
7.8 Forma normal de Boyce & Codd (BCNF)
7.9 Cuarta forma normal (4FN)
7.10 Talleres de normalizacin
6

8. El modelo semntico y diagramas E/R

8.1 Las reglas lgicas o reglas del negocio
8.2 Entidades e interrelaciones
8.3 Grado de las interrelaciones
8.4 Correspondencia de las interrelaciones
8.5 Cardinalidad de las interrelaciones
8.6 Diagramas E/R, modelos de datos o MER
8.7 Conversin de un diagrama E/R a un diagrama referencial
8.8 Valores de claves forneas segn cardinalidad
8.9 El modelo E/R extendido
8.9.1 La asociacin
8.9.2 La generalizacin
8.9.3 La agregacin
8.10 Problemas de modelamiento

Sistemadenotas:(Todos los previos con igual valor)

Previo1: Seciones 1 - 6 (teora basica)
Previo2: Seccin 7 (el modelo relacional y la normalizacin)
Tercerprevio: Secciones 8 (modelamiento semntico)
Cuartoprevio: Quices orales (en cualquier clase)

Textos

Diapositivas del curso.

Clare Churcher; Beginning Databases Design; www.apress.com;

ISBN-13: 978-1-59059-769-9

C. J. Date; Introduccin a los sistemas de bases de datos, Prentice Hall,

Sptima edicin, ISBN:968-444-419-2.

Siberschatz; Fundamentos de bases de datos, McGraw Hill, Quinta

edicin, ISBN: 84-481-4644-1.

SQL, manual de referencia, Groff & Weinberg, McGraw Hill, ISBN

84-481-3930-5.

Bibliografa

James R. Groff & Paul N. Weinberg; SQL Manual de referencia,

McGrawHill, ISBN: 0-07-222559-9
C. J. Date; Introduccin a los sistemas de Bases de datos, PrenticeHall,
ISBN: 968-444-419-2, sptima edicin
Abraham Silberschatz & Henry Korth; Fundamentos de Bases de datos,
McGrawHill, ISBN: 0-07-295886-3, quinta edicin
Ramakrishnan Raghu & Gehrke Johannes; Sistemas de gestin de Bases de
datos, McGrawHill, ISBN: 978-84-481-5638-1, tercera edicin
Ramez Elmasri & Shamkant B. Navathe; Fundamentos de sistemas de Bases
de datos, Pearson Addison Wesley, ISBN: 978-84-7829-085-7, quinta
edicin
Gillenson Mark L.; Administracin de Bases de datos, Limusa Wiley, ISBN13: 978-968-18-6595-2
Mario G. Piattini & otros; Tecnologa y diseo de Bases de datos;
Alfaomega-Rama, ISBN: 978-970-15-1268-5
Prez Csar; Oracle PL/SQL, Alfaomega-Rama, ISBN: 978-970-15-1374-3
Rodriguez Almeida Miguel; Bases de datos, McGrawHill, ISBN: 84-7615807-6
10

1.IntroduccinalasBasesdedatos
1.1DefinicindeunaBasededatos
Una Base de datos es un conjunto de archivos
almacenados de forma integrada y compartida, lo
cual es realizado por un software manejador de bases
de datos conocido como DBMS.
1.2DefinicindeunDBMSysusfunciones
Un DBMS es un software que tiene las siguientes
funciones:
11

Funciones de un DBMS
a.
b.
c.
d.
e.
f.
g.
h.
i.

Crear y organizar la Base de datos

Establecer ndices y mantener rutas de acceso
Agregar archivos nuevos a la Base de datos
Insertar registros nuevos en archivos existentes
Obtener datos de archivos existentes
Actualizar datos en archivos existentes
Borrar registros en archivos existentes
Modificar archivos de la Base de datos
Eliminar archivos de la Base de datos
12

Participacin de un DBMS en la E/S

Datos fsicos

SO
2

DBMS

3
13

1.3TiposdeusuariosdeunaBasededatos
a) El programador de aplicaciones
b) El usuario final
c) El administrador de la Base de datos (DBA)

14

2.NivelesdeunaBasededatos
Nivelexterno

Vista de usuario final

Esquema
externo

Nivelconceptual

Vista del diseador del sistema

Nivelinterno

Vista del sistema operativo

Esquema
externo

Esquema
externo

Esquema
conceptual

Esquema
interno

15

2.1NivelinternodeunaBasededatos
Est constituido por el conjunto de bloques de disco,
con sus diferentes registros y sus respectivas
direcciones, apuntadores, contadores y datos.
El nivel interno est directamente vinculado con el
sistema operativo (el servidor de archivos) y con el
software driver y tarjeta controladora del disco, por
lo cual es un esquema fsico binario.

16

Operaciones de E/S en una Base de datos

X
SQL
DBMS

o
chiv
r
a
e
ice)
re d
d
b
n

m
(
no
so
acce
e
d
e
clav

FS
n
N,

,D
, fid

l at
e
r
.
ir

iv a

1
1101
0
0
1
a
01
so l u t
b
a
n
ci
direc

Disco

Driver
bloques

RAM
17

Apuntadores
Hay tres clases de apuntadores:
a)

ndices: Es un campo propio al registro (viene de la primary key creada

en SQL) que lo identifica en forma nica y exclusiva. Deben ser
traducidos en direccin absoluta.

b)

Direccin relativa. Es un entero entre 0 o 1 hasta el nmero mximo de

registros de un archivo. Debe ser traducida en direccin absoluta.

c)

Direccin fsica o absoluta. Es la posicin real de un registro dentro del

disco, es decir, el nmero de bloque ocupado por el registro. No necesita
ser traducida.

18

2.2NivelconceptualdeunaBasededatos
Es el que corresponde a la percepcin general de
datos de la organizacin. Por lo tanto, se ve como
todo el conjunto universal de entidades de la
organizacin, vinculadas entre si, cada una con sus
propios atributos.
La apariencia de este nivel es producida por el
ingeniero diseador del sistema, aunque no tiene
existencia fsica sino solo lgica: Por esto es
conocido como modelo conceptual.
19

Entidad 1

Entidad 2

Entidad 3

Entidad 4

Entidad 5

Entidad 6

Modelo conceptual
20

2.3NivelexternodeunaBasededatos
Es el que corresponde a la percepcin de datos que
tienen los usuarios finales de cada rea funcional en
una empresa.
Es una vista o subconjunto del conjunto universal (o
modelo conceptual), que describe nicamente la parte
de los datos de inters para cada usuario y que
tampoco tiene existencia fsica.
Cada vista puede omitir uno o ms registros, atributos
o relaciones del esquema conceptual, o tambin
cambiar su orden.
A diferencia de los otros esquemas, el esquema
21

2.4Mapeodedatos
La existencia de tres niveles impone al DBMS la
necesidad de transformar los datos de un formato a
otro.
As habr dos formatos de transformacin:
Conceptual-interno y conceptual-externo.
Tanto el formato conceptual-interno como el
conceptual-externo opera en los dos sentidos: De lo
conceptual a lo interno y viceversa, y de lo conceptual
a lo externo y viceversa.
22

3.PropiedadesdeunaBasededatos
3.1Independenciadelosdatos.Es la capacidad
de modificar los esquemas interno o conceptual
sin causar cambios en los programas (que usan
esquemas externos).
La independencia entre lo externo y lo interno se
llama Independencia fsica y, entre lo externo y
lo conceptual Independencia lgica.
La independencia lgica ayuda al mantenimiento
de los programas software en la organizacin.
23

3.2 Seguridad. Los datos deben estar protegidos

contra accesos no autorizados, y adems reservados
en diferentes rangos de permisividad para accesos
autorizados.
3.3Integridad.Los datos, apuntadores, direcciones,
enlaces, ndices y contadores, deben mantenerse
siempre incorruptibles.
La corrupcin puede aparecer por fallas del
hardware, defectos del software, actualizaciones
incompletas o invlidas, o la violacin a las reglas de
integridad referencial.
24

3.4 Respaldo y recuperacin. Es la facilidad para

obtener copias de la Base de datos (en backups de
respaldo y/o servidores paralelos) que permitan
recuperar la Base de datos ante cualquier falla.
3.5 Control de redundancia. Es la propiedad por
medio de la cual, la repeticin de datos es mnima y
es controlable.
El proceso de normalizacin busca reducir al mximo
la redundancia de datos, aunque nunca al 100%

25

3.6 Consistencia. Es la propiedad que impide las

contradicciones entre datos.
Si la redundancia estuviera descontrolada, un mismo
dato repetido en lugares diferentes podra tener
valores diferentes, y por tanto inconsistentes.
3.7Auditora.Es el examen de la Base de datos y su
entorno, a fin de comprobar que se ajusta a lo
establecido. Este examen no es solo a posteriori sino
que tambin es a priori

26

3.8 Control de concurrencia. Es la capacidad para

ejercer un riguroso control en la ejecucin simultnea
de transacciones con el fin de proteger la consistencia
de las actualizaciones y consultas a la Base de datos.
Veamos lo que ocurrira si no hubiese control de
concurrencia. Supongamos en un banco, la ejecucin
simultnea de una transaccin de consignacin de un
cheque de 100 (T1) en una ventanilla, y una
transaccin de retiro de 50 en efectivo (T2) en otra
ventanilla.
Los pasos que se sucederan en ram se muestran en la
siguiente diapositiva.
27

Registro inicial
Tiempo

t=0

SAL CON RET

200
0
0
T2

T1
Lea cuentas

Lea cuentas
RET = RET + 50
Regrabe cuentas
CON = CON + 100
Regrabe cuentas
Registro final

t=n

SAL CON RET

200 100
0
28

Observamos que el saldo en el sistema es de 300

(SAL = SAL + CON RET), mientras que el saldo
real debe ser 250.
Para evitar inconsistencias los DBMS conforman sus
transacciones atmicamente por medio de seguros
(locks)
y
puntos
de
sincronizacin
(commit/rollback).

29

4. SoftwarecomplementariodeunDBMS
Para poder llevar a cabo su funcin en forma
ptima, un DBMS est complementado con:
4.1 Un administrador de la Base de datos (DBA)
4.2 Un diccionario de datos
4.3 Un lenguaje de datos (ddl, dml, sql).

30

4.1EladministradordelaBasededatos(DBA).
El DBA es el software utilizado por la persona o equipo de
personas responsable de mantener en regla una Base de datos
(BD). Est encargado:
a)
b)
c)
d)
e)
f)

De cargar inicialmente la BD, de ser necesario.

De reorganizar la BD (para liberar espacio).
Del registro de transacciones en bitcora (log).
De su recuperacin despus de un fallo.
Del anlisis de estadsticas de desempeo.
Del manejo de autorizaciones de acceso.

31

4.2Eldiccionariodedatos.
El diccionario de datos es el conjunto de datos que describen la
BD, y contiene:
a) La descripcin de todos los esquemas (externo, conceptual
e interno).
b) La descripcin de todos los campos (o atributos), registros
(o tuplas) y referencias cruzadas entre las tuplas de varios
archivos (tablas).
c) Los cdigos de autorizacin y seguridad para los datos (por
atributos, tuplas, tablas conceptuales, vistas externas, o
ndices internos).

32

4.3LenguajesdelaBasededatos.
Estos lenguajes permiten describir (con ddl), manipular (con
dml) y consultar (con sql) la BD.
Adems proporcionan interfaces con lenguajes de programacin
3gl como Cobol, PL/1, Fortran, C, o Java, ya que los lenguajes de
datos no son de programacin.
Con ddl describimos los esquemas conceptual y externo. El
compilador ddl al compilar estos esquemas produce el
diccionario de datos y tales esquemas.
Con dml nos valemos para insertar tuplas, modificar atributos, o
borrar tuplas de una BD.
Con sql consultamos una BD.
33

Las ordenes dml son pre-compiladas (o interpretadas) resultando

cdigo de tercera generacin en Cobol, PL/1, Fortran, C, Java,
los cuales son procedimentales porque el usuario debe especificar
al DBMS, lo que quiere y cmo debe hacerlo.
Pero sql tiende a ser un lenguaje de 4 generacin o sea 4gl, no
procedimental puesto que el usuario nicamente especifica lo que
quiere.
Inicialmente sql era un sublenguaje pero con la incorporacin de
los PSM (Persistent Stored Modules) en 1996, ahora es un
lenguaje ms completo (sql3) y no hay necesidad de combinar sql
con lenguajes anfitriones.

34

5.ClasesomodelosdeDBMSs.
Hasta el da de hoy ha habido cuatro clases de DBMS:
Jerrquicos, en Red, Relacionales y de Objetos.
Los dos primeros ya han quedado obsoletos, mientras que el
modelo relacional se mantiene en vigor todava.
Hasta la fecha el modelo de objetos no es ms que una
extensin del modelo relacional, pero an no satisface los
requerimientos de la industria.
El modelo semntico ampla el modelo relacional, y ambos
satisfacen los requerimientos de la industria, aunque no
totalmente.
35

5.1 El modelo jerrquico. A la manera de la organizacin

tradicional de las empresas, al estilo de la organizacin
militar, el modelo jerrquico organiza su datos reconociendo
ciertos archivos en la raz de la jerarqua, a los cuales este
modelo llama abuelos, para conformar el inicio de un rbol
invertido.
De los abuelos nacen hijos para conformar el siguiente nivel
del
rbol,
en
la
jerarqua.
De los hijos nacen los nietos para el siguiente nivel del rbol
en
la
jerarqua,
y
as
sucesivamente.
Este modelo de datos qued en desuso por la dificultad para
actualizar y consultar sus archivos a contrapelo. Adems, la
mayora de las organizaciones no tratan con enemigos como
los militares sino con amigos (los clientes).
36

5.2Elmodeloenred. El modelo jerrquico desapareci en

menos de veinte aos. Ante el poco exitoso modelo
jerrquico, la atencin se centr en el modelo en red.
El modelo en red interconecta mediante enlaces adicionales a
los
datos,
los
diferentes
archivos
entre
s.
Cada archivo es un nodo, y de cada nodo debe salir un enlace
para interconectar todos y cada uno de los dems archivos.
El modelo en red se transformaba al ser implementado en un
gran enredo y tambin fracas. La salvacin vendra a ser el
modelo relacional.

37

5.3 El enfoque relacional. El enfoque relacional es el

fundamento de la actual tecnologa de BD, lo que lo
convierte en una ciencia.
El modelo relacional se ocupa de tres aspectos principales:

Su estructura (planteamiento y descripcin de MERs

con ddl),

La manipulacin de datos (implementacin de

aplicaciones software incorporando dml y sql),

La integridad (las restricciones de comprobacin y de

clave fornea en create table).

De aqu en adelante, toda la teora de este curso har

referencia exclusiva al enfoque relacional.

38

6.ElmodelorelacionaldeBasesdedatos
El modelo relacional ha evolucionado a partir de lo publicado por
Edgar Frank Codd en 1970.
El modelo relacional no concibe registros individuales ni
archivos individuales como los lenguajes de programacin sino
varias relaciones completas y al mismo tiempo.
Las relaciones del modelo relacional equivalen a los archivos de
los lenguajes de programacin, a las tablas de SQL, a las
entidades del modelo semntico, o a los objetos de los actuales
modelos de objetos.

39

De acuerdo a las recomendaciones ANSI/SPARC, el modelo est

conformado por las siguientes partes: La estructura (el nivel
conceptual, el nivel externo, el nivel interno) y el lenguaje de
datos (DDL y DML).
6.1Nivelconceptual. Est representado por todo el conjunto de
tablas descritas en SQL, cada una de las cuales tiene existencia
por si sola, y se traducen en un archivo almacenado a nivel fsico.
C. J. Date diferencia una tabla de una varrel.
La sentencia SQL para crear una tabla es create table cuyo
formato se observa en la siguiente diapositiva.

40

create table nombre-tabla

(nom-col1 tipo-dato [not null]
[, nom-col2 tipo-dato [not null]
[, primary key (nom-col1 [, nom-col2] )
[, foreign key (nom-col-ajena1) references tabla-objetivo1
[, foreing key (nom-col-ajena2) references tabla-objetivo2
);

Ejemplo: Supongamos las relaciones S (proveedores), y P

(partes), en donde un proveedor puede haber suministrado varias
partes, y una parte puede haber sido suministrada por varios
proveedores. Estas tablas (con los mismos datos) sern utilizadas
durante todo el curso.

41

S
S#

SP
snombre

edo

ciudad

S#

P#

S1 Salazar

20

Londres

S1

P1

300

S2 Jaimes

10

Pars

S1

P2

200

S3 Bernal

30

Pars

S1

P3

400

S4 Corona

20

Londres

S1

P4

200

S5 Aldana

30

Atenas

S1

P5

100

S1

P6

100

S2

P1

300

S2

P2

400

S3

P2

200

S4

P2

200

S4

P4

300

S4

P5

400

P
P#

pnombre

color

peso

ciudad

P1

Tuerca

Rojo

12

Londres

P2

Perno

Verde

17

Pars

P3

Birlo

Azul

17

Roma

P4

Birlo

Rojo

14

Londres

P5

Leva

Azul

12

Pars

P6

Engrane

Rojo

19

Londres
42

cant

 Cuando una asociacin es muchos a muchos como se ve en

lo subrayado atrs (las reglas del negocio), se requiere una
tercera relacin adems de las relaciones S y P, para poder
averiguar los proveedores que han suministrado cada parte, y las
partes que han sido suministradas por cada proveedor.
En este caso, como las reglas del negocio estn en pasado, la
historia de envos, SP, puede satisfacer el requisito en cuestin.
De este modo, la asociacin entre S y SP es uno a muchos, y
entre P y SP uno a muchos tambin. La creacin en SQL de
estas tablas est en la siguiente diapositiva.

43

create table S
(s#
char(2)
not null,
snombre char(10)
not null,
edo
smallint not null,
ciudad
char(10)
not null,
primary key (s#));
create table P
(p#
char(2)
not null,
pnombre char(10)
not null,
color
char(10)
not null,
peso
smallint not null,
ciudad char(10)
not null,
primary key (p#));
create table SP
(s#
char(2)
not null,
p#
char(2)
not null,
cant
integer,
primary key (s#, p#),
foreign key (s#) references S,
foreign key (p#) references P);
44

 Null es algo indefinido que no es igual a nada, no es igual a

cero, no es igual a blanco, ni siquiera es igual a null. Por ejemplo,
s# y p# deben tener valores definidos o si no sern rechazados,
pero cant debe ser null para cuando no se conozca la cantidad
enviada.
Para modificar una tabla ya existente, est la sentencia alter
table. Si queremos agregar una columna, la sentencia tendra la
forma
alter table nombre-tabla add nom-col tipo-dato;

Ejemplo: alter table S add descuento smallint;

45

 Al aadir a la tabla S el atributo descuento, S crece en lo

conceptual, pero el nuevo atributo ser nulo, pues esta sentencia
no permite especificar not null.
Crecer en lo conceptual significa que la expansin de los
registros no se da en lo fsico sino que solo se modifica su
descripcin en el diccionario de datos. Al introducir un nuevo
proveedor s crecer fsicamente, excepto que su descuento siga
siendo nulo.
Tambin se puede alterar una tabla eliminando o modificando
columnas.
Una tabla se puede eliminar con drop table que tiene el
formato: drop table nombre-tabla;
46

6.2 Nivelexterno:vistas. En este nivel la BD se percibe como

una vista externa propia, o escenario particular a cada usuario.
Una vista se crea en SQL con la sentencia create view cuyo
formato es
create view nombre-vista [(columna [, columna] )]
as select columna [,columna]
from nombre-tabla
where condicin

Una vista no existe fsicamente pero en el diccionario de datos si

est guardada su definicin.
Una vista es un subconjunto de una tabla.
47

Ejemplo: Obtener la vista de la tabla P cuyas partes sean de color

rojo.
create view partes_rojas (codigo, nombre, peso, ciudad)
as select p#, pnombre, peso, ciudad
from P
where color = rojo;

Por medio de las vistas se logra la independencia lgica de los

datos.
Adems permiten a diferentes usuarios ver los mismos datos, de
distintas maneras, al mismo tiempo.
Finalmente, las vistas protegen los datos, pues los no visibles
para un usuario, estn a salvo de accesos indebidos.
48

Una vista se puede borrar del diccionario de datos mediante la

sentencia drop que tiene el siguiente formato:
drop view nombre-vista

6.3Nivelinterno:ndices.Con las sentencias SQL createindex

y drop index se crea y se destruye ndices, pero stas son las
nicas sentencias que los manejan.
La sintaxis de la sentencia create index es:
create [unique] index nombre-ndice
on nombre-tabla (columna [orden] [,columna [orden]])
[cluster]

En donde el orden puede asc (ascendente) o desc (descendente).

49

La opcin cluster indica que el ndice es de agrupamiento, o sea

que los datos para un mismo ndice son reunidos en secuencia
fsica igual a la lgica. Ejemplo:
create unique index xsp on SP (s#, p# desc) cluster;

As se crea el ndice xsp sobre la tabla SP, en el cual las entradas

se ordenan segn s# ascendentemente, y segn p#
descendentemente. Con unique se asegura que el ndice no se
repita.
Con la sentencia dropindexse destruye un ndice previamente
creado.
El nivel interno es pues el mismo conjunto de tablas del nivel
conceptual, pero almacenadas como archivos indexados.
50

El modelo relacional permite as crear, alterar y destruir tablas,

vistas e ndices, en cualquier momento, pues es muy tolerante.
6.4 El lenguaje de datos. SQL incluye tanto sentencias de
especificacin o descripcin de datos (DDL), como sentencias de
manipulacin (DML).
SQL tiene fundamentos del lgebra relacional por lo cual en
algunos aspectos es procedimental. Tambin del clculo
relacional por lo cual en otros aspectos es no procedimental.
De ah que para estudiar SQL con fundamento, sea necesario
estudiar lgebra relacional y clculo relacional.

51

7. Diseo de Bases de datos: El modelo

relacionalylanormalizacin
Cmo poder conseguir las relaciones o tablas ms adecuadas a
las exigencias de un problema real?
Y cmo poder determinar los atributos que deben pertenecer a
cada una de estas relaciones o tablas?
En general, Cmo plantear un conjunto conceptual de relaciones
con el cual mantener todos los datos de una empresa, con un
mnimo de redundancia, pero al mismo tiempo con la mayor
facilidad para su actualizacin y recuperacin?
Para resolver estos interrogantes hay dos caminos:
52

Uno intuitivo y natural que se aproxima a objetos en cuanto

determina la estructura de las tablas (los atributos que les
pertenecen y las identifican), pero no su funcionalidad. Este
camino produce, relaciones bastante normales por si solas.
El otro camino aunque extrao es ms oficial, y es el seguido en
este captulo. Parte de una mezcla anormal de todos los atributos
posibles en una misma relacin, la cual es llamada la relacin
universal.
Por este motivo es necesario hacer normal (normalizar) la
relacin universal, mediante una serie de pasos de
descomposicin. As pues, la normalizacin consiste en
descomponer tablas aislando atributos y reagrupndolos en
nuevas relaciones que se parezcan ms a objetos de la vida real.
53

7.1Larelacinuniversal. Supongamos que se desea implantar

una Base de datos (simplificada al extremo) para el suministro de
partes a una empresa.
Los datos (atributos) a mantener son los siguientes: La
identificacin del proveedor (s#), el nombre del proveedor
(snombre), el estado del proveedor (edo), la ciudad donde reside
el proveedor (ciudad), la cantidad suministrada por el proveedor
en cada envo (cant), la identificacin de cada parte (p#), el
nombre de cada parte (pnombre), su color (color), su peso (peso),
y la ciudad en donde se almacena la parte (ciudad). Todos estos
atributos arreglados en una misma tabla produce la relacin
universal (U).

54

U
s# snombre
s1 Salazar

edo ciudad cant p# pnombre color peso ciudad

20 Londres 300 p1 tuerca
rojo 12
Londres
200 p2 perno
verde 17
Pars
400

p3 birlo

azul

17

Roma

200

p4 birlo

rojo

14

Londres

100

p5 leva

azul

12

Pars

100

p6 engrane

rojo

19

Londres

s2 Jaimes

10

Pars

300
400

p1 tuerca
p2 perno

rojo 12
verde 17

Londres
Pars

s3 Bernal
s4 Corona

30
20

Pars
200
Londres 200
300

p2 perno
p2 perno
p4 birlo

verde 17
verde 17
rojo 14

Pars
Pars
Londres

p5 leva

azul

Pars

400

55

12

La principal anormalidad de la relacin U consisten en que para

cada proveedor se abre una lista de partes enviadas, por lo cual
los atributos cant, p#, pnombre, color, peso y ciudad, no son
atmicos, o sea que se pueden dividir en varias sub-tuplas.
Adems, en algunas tuplas los atributos s#, snombre, edo y
ciudad no quedan definidos, pero en otras tuplas si. As, con
DDL no podra ser creada la tabla U expresando null y
simultneamente notnull, en estos atributos.
La correccin de las anteriores anomalas normalizar la relacin
U, resultando una nueva relacin que se suele llamar la relacin
1NF (First Normal Form).

56

7.2Laprimeraformanormal(1NF).
Una relacin est en primera forma normal cuando
el valor de sus atributos en cada tupla es atmico.
En otras palabras, en la interseccin de cada tupla con cada
columna, siempre hay exactamente un valor, nunca un conjunto
de valores.
Entonces, para obtener la 1NF es necesario determinar valores
nicos o atmicos en cada interseccin. As, la relacin U queda
transformada en la relacin 1NF que se muestra en la siguiente
diapositiva.
Para las explicaciones subsiguientes, se ha incluido el atributo
fecha, y el estado de s3 se ha cambiado de 30 a 10. Adems, es
necesario repasar los conceptos de claves y dependencia
funcionales.
57

1NF
s#

snombre

edo

ciudad

cant fecha

p#

pnombre

color

peso

s1

Salazar

20

Londres 300

s1

Salazar

20

s1

Salazar

s1

10/5

p1

tuerca

rojo

12

Londres

Londres 200

10/8

p2

perno

verde

17

Pars

20

Londres 400

10/12 p3

birlo

azul

17

Roma

Salazar

20

Londres 200

11/9

p4

birlo

rojo

14

Londres

s1

Salazar

20

Londres 100

11/15 p5

leva

azul

12

Pars

s1

Salazar

20

Londres 100

11/18 p6

engrane

rojo

19

Londres

s2

Jaimes

10

Pars

300

10/7

p1

tuerca

rojo

12

Londres

s2

Jaimes

10

Pars

400

10/10 p2

perno

verde

17

Pars

s3

Bernal

10

Pars

200

10/2

p2

perno

verde

17

Pars

s4

Corona

20

Londres 200

11/3

p2

perno

verde

17

Pars

s4

Corona

20

Londres 300

11/8

p4

birlo

rojo

14

Londres

s4

Corona

20

Londres 400

11/10 p5

leva

azul

12

Pars

58

ciudad

9.3Quesunadependenciafuncional(DF)?
El concepto de dependencia funcional viene de las
matemticas, y significa que si el valor de una variable y
est siempre determinado por el valor de otra variable x,
se dice que y est en funcin de x, y se denota y = f(x).
Entonces, dados dos atributos A y B de una relacin R,
B ser funcionalmente dependiente de A si para cada
valor de A existe un valor de B y solo uno, o sea que al
conocer el valor de A se podr conocer el valor de B.
Esto se denota tambin A B.
A y B deben pertenecer a la misma relacin pues no
tiene sentido la dependencia funcional entre atributos de
diferentes relaciones.
59

Al analizar las dependencias funcionales de los atributos

entre si, se encontrarn atributos simples o compuestos
cuyos valores son nicos, y entonces pueden ser usados para
identificar las tuplas de una relacin. Tales atributos se
llaman claves. Existen diferentes clases de claves.
9.3.1 Clave candidata. Es cualquier atributo simple o
compuesto que puede ser utilizado para identificar las tuplas
de una relacin, por lo que su valor debe ser nico an en el
caso de ser compuesto.
9.3.2 Clave principal. Es la clave candidata elegida como
identificador, en la que ningn componente puede tomar el
valor nulo. Toda relacin debe tener una calve principal.
9.3.3 Clave fornea. Tambin llamada clave ajena o clave
externa, es un campo de una relacin que acta como clave
principal en otra relacin.
60

9.3.4Clavealterna. Es la clave candidata que no es clave

principal. Como s# es nico en S, es una clave candidata. Si
snombre fuera nico, tambin sera una clave candidata. Si
se elige s# como clave principal, snombre sera una clave
alterna.
Toda relacin tiene al menos una clave candidata ya que
ninguna relacin puede contener tuplas repetidas. Los dems
atributos no clave deben depender funcionalmente de la
clave candidata.
9.4 Normalizacin de la relacin 1NF. La relacin 1NF
tiene una estructura indeseable. Para apreciar esto se utilizan
los llamados diagramas de dependencias funcionales o
diagramas DF. El diagrama DF para la relacin 1NF es el
siguiente:
61

DiagramaDFdelarelacin

cant

1NF
snombre

edo

s#

p#

6
7

fecha

8
9

ciudad
pnombre
color
peso
ciudad

62

Sobre el diagrama DF anterior vemos que la nica clave

candidata es el atributo compuesto (s#,p#,fecha).
En una relacin normal cualquier atributo no clave debe
depender funcionalmente de la clave candidata, pero
esto no se cumple en la relacin 1NF. El nico atributo
que depende por completo de la clave candidata es cant
pero los dems no, como se ve en el diagrama DF.
Si hay atributos no clave que no dependen de la clave
candidata, entonces para qu la clave candidata? Sin
embargo, se ve cierta dependencia no completa de los
restantes atributos a la clave candidata: flechas 2, 3, 4,
6, 7, 8, 9.
63

Una dependencia funcional completa se define cuando

un atributo B depende funcionalmente de A, pero no de
ningn subconjunto propio de A.
Por ejemplo, snombre depende de la clave candidata
(s#,p#,fecha) pero no completamente porque tambin
depende de s# solo. Estas otras dependencias diferentes
a la clave candidata hacen anormal la relacin 1NF,
generando redundancias obvias: Por ejemplo, todas las
tuplas con s# = s1 indican que la ciudad es Londres; y
las tuplas con ciudad de proveedor = Londres indican
que el estado (edo) es 20.
Estas redundancias provocan las conocidas anomalas
de actualizacin, que son problemas surgidos al
actualizar la Base de datos con insert, delete o update.
64

La primera redundancia se origina por la dependencia

no completa s# ciudad (flecha4) y causa que no se
pueda insertar (insert) un nuevo proveedor hasta que no
suministre al menos una parte. De ah que en la relacin
1NF no se haya podido incluir el proveedor s5 situado
en Atenas, pues sin un suministro no se puede tener una
valor apropiado para la clave primaria.
Adems, al eliminar (delete) la nica tupla de un cierto
proveedor se perder no solo la informacin del envo
sino tambin la del proveedor. De ah que al eliminar la
tupla cuyo s# = s3 se eliminen los datos del envo pero
tambin los del provedor en los que dice que s3 est en
Pars. El problema radica en que la relacin 1NF
contiene demasiados datos y as, al eliminar una tupla
de elimina demasiado.
65

La solucin a este problema es desempacar, o sea

separar los datos de envos en una relacin y los de
proveedores en otra. As pues, la normalizacin es un
proceso de desempaque que coloca datos separados en
relaciones separadas.
Igualmente, no se puede actualizar (update) la relacin
1NF sin tener que recorrer todas sus tuplas para evitar
las inconsistencias. Por ejemplo, si el proveedor s1 se
cambia de Londres a Amsterdam.
La correccin de todas estas anormalidades transforma
la relacin 1NF en un conjunto de relaciones en
segunda forma normal (2NF), en las cuales los datos
quedan desempaquetados al eliminar las dependencias
funcionales no completas.
66

9.5Lasegundaformanormal(2NF).

Una relacin est en segunda forma

normal (2NF) si y solo si est en 1NF y
todos sus atributos no clave dependen
por completo de la clave principal.
Se puede ver que las siguientes relaciones corresponden
a las relaciones 2NF, en las cuales, s es posible incluir
datos del proveedor s5 aunque no haya hecho envos.
Adems, las redundancias han desaparecido y se pueden
aplicar operaciones insert, delete y update sin los
problemas ya vistos.
67

S
S#

SP
snombre

edo

ciudad

S#

P#

fecha

cant

S1 Salazar

20 Londres

S1

P1

10/5

300

S2 Jaimes

10 Pars

S1

P2

10/8

200

S3 Bernal

10 Pars

S1

P3

10/12

400

S4 Corona

20 Londres

S1

P4

11/9

200

S5 Aldana

30 Atenas

S1

P5

11/15

100

S1

P6

11/18

100

S2

P1

10/7

300

S2

P2

10/10

400

S3

P2

10/2

200

S4

P2

11/3

200

S4

P4

11/8

300

S4

P5

11/10

400

P
P#

pnombre

color

peso

ciudad

P1

Tuerca

Rojo

12

Londres

P2

Perno

Verde

17

Pars

P3

Birlo

Azul

17

Roma

P4

Birlo

Rojo

14

Londres

P5

Leva

Azul

12

Pars

P6

Engrane

Rojo

19

Londres
68

Finalmente es posible apreciar en la relaciones 2NF que

las dependencias funcionales son completas, como se
muestra en los diagramas DF a continuacin:
SP

snombre

s#
p#
fecha

S
1

cant

edo

s#

p#

ciudad
pnombre

7
8

color

peso
ciudad
69

Las relaciones 2NF representan mejor el mundo real

que la relacin 1NF y cualquier informacin derivable
de sta lo ser tambin de las relaciones 2NF, aunque lo
contrario no se cumple. Por ejemplo, el proveedor s5 no
puede ser representado en la relacin 1NF.
9.6Normalizacindelasrelaciones2NF.
Aunque las relaciones P y SP son satisfactorias, la
relacin S tiene todava una dependencia mutua entre
sus atributos no clave (flecha 5 en el diagrama DF de la
2NF).
En trminos ms especficos, la dependencia del
atributo edo con respecto a s#, aunque es funcional y
completa, es transitiva a travs de ciudad.
70

Si en una relacin R, R.A R.B y R.B R.C, por

transitividad R.A R.C
Por causa de la transitividad no se puede insertar
(insert) el estado de una ciudad hasta que no haya un
valor no nulo para la clave s#. Por ejemplo, no se puede
insertar Roma con edo 50, si no hay un proveedor all.
Tampoco se puede eliminar (delete) una tupla sin
perder ms datos de la cuenta. Por ejemplo, si se elimina
Aldana se pierde la ciudad Atenas y tambin el hecho de
que a Atenas le corresponde el estado 30.
Como S todava tiene redundancias es necesario
recorrerla toda al actualizar (update) algo, para no dejar
inconsistencias. Por ejemplo, si a Londres se le cambia
el estado de 20 a 40.
71

La correccin de la transitividad transforma la

relacin S en dos relaciones 3NF, las cuales
desempaquetan ms datos eliminando las dependencias
transitivas.

9.7Terceraformanormal(3NF).

Una relacin est en tercera forma

normal (3NF) si y solo si est en
segunda forma normal (2NF) y todos
los atributos no clave dependen de
manera no transitiva de la clave
principal.
72

S
S#

snombre

ciudad

ciudad

edo

S1

Salazar

Londres

Atenas

30

S2

Jaimes

Pars

Londres

20

S3

Bernal

Pars

Pars

10

S4

Corona

Londres

Roma

50

S5

Aldana

Atenas

Ahora s es posible incluir el estado 50 para Roma.

Se puede eliminar Aldana sin borrar los datos de
Atenas.
Las redundancias desaparecieron bastando
modificar el estado de Londres en una sola
tupla.
73

 As, las dependencias transitivas han desaparecido,

como se puede observar en los diagramas DF para las
relaciones S y la nueva relacin C (ciudad):
S

s#

2
4

snombre
ciudad

edo

ciudad

Si en 3NF se puede representar datos que en 2NF no

se poda, 3NF representa mejor el mundo real que 2NF.

74

9.8FormaNormaldeBoyce&Codd(BCNF).
Pero, la 3NF originalmente debida a Codd, no
satisface el caso en el cual una relacin tiene:
a) Varias claves candidatas
b) Claves candidatas compuestas
c) Claves candidatas traslapadas
Por esto, la definicin original de 3NF se sustituy
por una definicin ms adecuada que tuviese en cuenta
el caso abc. Pero como Ronald Fagin ya haba definido
la 4NF, la nueva 3NF no se pudo llamar 4NF sino
Forma Normal de Boyce & Codd o BCNF.

Las condiciones abc casi no se dan en la prctica y

cuando no existen, BCNF se reduce a la antigua 3NF.
75

 Cuando un atributo depende por completo de otro

atributo, ste determina al primero y se le llama un
determinante.
Por ejemplo, el snombre y la ciudad del proveedor
dependen por completo de s# en la relacin S.
Tambin el pnombre, el color, el peso y la ciudad de
las partes dependen por completo de p# en P.
Igualmente en SP, la cantidad enviada depende por
completo de (s#, p#, fecha).
Y en C, el estado depende por completo de ciudad.
Por lo tanto, s#, p#, (s#, p#, fecha) y ciudad son
todos determinantes en sus respectivas relaciones.
76

Una relacin est en forma normal de

Boyce y Codd (BCNF), si y solo si todo
determinante es una clave candidata.
Esta definicin es ms sencilla que la antigua 3NF
puesto que no hace referencia explcitamente a la 1NF,
ni a la 2NF, ni a la dependencia transitiva.
De acuerdo a esta definicin, las relaciones S, P, SP
y C, estn en 3NF, pero tambin en BCNF.
Pero la relacin 1NF (ver su diagrama DF) contiene
4 determinantes, s#, p#, ciudad y (s#, p#, fecha), de los
cuales solo (s#, p#, fecha) es clave candidata, y por esto
que la relacin 1NF n est en BCNF.
77

 Tampoco las relaciones en 2NFestn en BCNF

porque ciudad es determinante pero no es clave
candidata (ver el respectivo diagrama DF).
Las relaciones S, P, SP, y C por el contrario, estn
todas en BCNF porque en todos los casos la clave
principal es el nico determinante en cada relacin.
Pero consideremos ahora un caso en que haya varias
claves candidatas (sin atributos comunes). Supongamos
que en la relacin S cada s# tiene un nombre nico.
Entonces el diagrama DF sera:
s#

ciudad

snombre
78

 Ahora, aunque hay varias claves candidatas, los

nicos determinantes son dichas claves candidatas, o
sea que las nicas flechas son las que salen de las claves
candidatas, lo cual significa que la relacin S est en
BCNF.
Consideremos ahora la relacin estudiante (E) para
el caso en que haya varias claves candidatas que se
traslapan (que tienen atributos comunes). Supngase
que E tiene los atributos cdigo de estudiante (ce), nit
(n#), cdigo de carrera (cc) y promedio (p), es decir,
E(ce, n#, cc, p).
Las claves candidatas son (ce, cc) y (n#, cc). Est E
en BCNF? No porque contiene dos determinantes, ce y
n#, que no son claves candidatas, pero si se determinan
el uno al otro.
79

 La relacin E est en 3NF porque ningn atributo no

clave es transitivamente dependiente de la clave
principal, y el atributo no clave (p) es totalmente
dependiente de la clave principal, ya sea (ce, cc) (n#,
cc). Sin embargo, E no est en BCNF.
Admtase la relacin E con los siguientes datos:
ce

n# cc

071

n1

10

3.7

071

n1

11

3.9

071

n1

12

3.5

072

n2

10

3.8

072

n2

13

3.3
80

 Puede verse que la relacin E contiene el mismo tipo

de redundancias vistas atrs y por lo tanto est sujeta al
mismo tipo de anomalas de actualizacin.
La solucin es normalizar la relacin E, es decir,
descomponer la relacin en dos proyecciones, que en
este caso seran las proyecciones Estudiantes (E) y
Promedios (P), de la siguiente manera:
E(ce, n#) y P(ce, cc, p) o bien
E(ce, n#) y P(n#, cc, p).
En la siguiente diapositiva se muestran de la
relacin E, los diagramas DF, primero en 3NF pero n
en BCNF, y segundo en BCNF.
81

ce
cc

n#
Diagrama DF de E en 3NF pero no en BCNF

ce
ce

n#

cc
Diagrama de E en BCNF
82

9.9CuartaFormaNormal(4NF).
A veces se presentan en la vida real, relaciones muy
singulares, en las cuales no es posible identificar las
dependencias funcionales convencionales.
Por ejemplo, sea la relacin con los atributos curso,
profesor, texto, por lo cual se puede denominar la
relacin CPT (curso, profesor, texto).
Se puede observar que: Dado un curso, no se puede
saber, ni el profesor, ni el texto, porque un curso puede
ser dictado por varios profesores y utilizar varios textos.
Tambin que, dado un profesor, no se puede saber, ni
el curso, ni el texto, porque un profesor puede dictar
varios cursos, y utilizar varios textos.
83

 Finalmente que, dado un texto, no se puede saber,

ni el curso, ni el profesor, porque un texto puede ser
utilizado por varios profesores en distintos cursos.
Al tabular algunos datos, la relacin CPT no
normalizada se vera as:
CPT
curso
Fsica

profesor
Rosas

texto
Mecnica
ptica

Ramos

Mecnica
ptica

Matemticas

Rosas

Mecnica
Vectores
Funciones
84

 La nica operacin normalizadora disponible sera

aplanar la relacin CPT, de la siguiente manera:
CPT
curso

profesor

texto

Fsica

Rosas

Mecnica

Fsica

Rosas

ptica

Fsica

Ramos

Mecnica

Fsica

Ramos

ptica

Matemticas

Rosas

Mecnica

Matemticas

Rosas

Vectores

Matemticas

Rosas

Funciones

85

 Las redundancias que muestra la relacin CPT lleva

a anomalas de actualizacin, a pesar de que CPT est
en BCNF al ser toda clave.
Pero no se puede utilizar DF para descomponer CPT
ya que no existen DF.
Solo hasta 1977 Ronald Fagin estableci el concepto
de dependencias multivaluadas (DMV), con el cual es
posible normalizar la relacin CPT.
Una DMV es una generalizacin de DF, ya que toda
DF es una DMV, aunque no al contrario.
En CPT se puede considerar las siguientes DMV:
CPT.curso CPT.profesor
CPT.curso CPT.texto
86

 La primera DMV significa que aunque un curso no

es determinante de un profesor, de cualquier manera un
curso determina un conjunto muy bien definido de
profesores.
De la misma manera se interpreta la segunda DMV.

Una relacin est en 4NF si y solo si

est
en
BCNF
y
no
contiene
dependencias multivaluadas (DMV).
Aunque de CPT no se puede eliminar las DMV, s se
puede descomponer para eliminar las redundancias y las
anomalas de actualizacin.
87

 En general, una relacin R(A, B, C) con las DMV,

AB, y AC, se puede descomponer sin
prdidas en R1(A, B) y R2(A, C).
De ah que la relacin CPT se haya descompuesto
en las relacioes CP (curso, profesor) y CT (curso,
texto), o sea:
CT
CP
Curso

Profesor

Curso

Texto

Fsica

Rosas

Fsica

Mecnica

Fsica

Ramos

Fsica

ptica

Matemticas

Rosas

Matemticas

Mecnica

Matemticas

Vectores

Matemticas Funciones
88

 Al ir ms all de esta descomposicin, para este

caso, se salta a la conversin de cada uno de los
atributos de CP y CT en relaciones individuales, cada
una, a su vez, con sus propios atributos. O sea las
relaciones: C (cursos) con sus propios atributos, P
(profesor) con sus propios atributos, y T (textos) con sus
propios atributos.
Al concebir, en otra alternativa, entidades normales
en lugar de relaciones anormales susceptibles de ser
descompuestas, el diseo de una BD puede ajustarse
mejor a un mundo real compuesto de objetos, ya que
una entidad es una aproximacin a un objeto,

89

En el siguiente captulo se tratar el modelo

semntico, en el cual se habla de entidades mas no de
relaciones, por lo que al modelo semntico tambin se le
llama modelo entidad/relacin.

90

Taller1: Analizar las DF (dependencias funcionales) de las siguientes relaciones

de un sistema bancario perteneciente a cierta empresa.
Bancos {nit, nombre, telfonos (varios), web site, saldo en banco}
Cuentas {cuenta#, giros acumulados, depsitos acumulados, saldo en cuenta}
Cheques {cheque#, valor cheque, fecha cheque, consignado/girado}
Cheques consignados {fecha consignacin, nombre titular}
Cheques girados {fecha giro, nombre beneficiario}

Transacciones {cdigo trans, fecha trans, hora trans, nombre usuario,

efectivo/cheque}
Transacciones en efectivo {valor}
Transacciones en cheque {cheque#}

91

Taller2: Analizar las DF (dependencia funcionales) de las siguientes relaciones

correspondientes al software de cierta empresa ganadera:
Depositarios {cdigo, cdula, nombre, valor acumulado contratos, telfono(s)}
Contratos {contrato#, total cabezas, total kilos, fecha de inicio, valor, muertes,
nacimientos}
Solo un contrato de cra puede tener nacimientos, pero todos pueden tener muertes

Hatos {nombre, cabezas, kilos}

Ventas {fecha, valor, cabezas, kilos}

92

Taller3: Analizar las DF (dependencia funcionales) de la siguiente relacin:

Facturas {factura#, identificacin cliente, nombre cliente, valor}
La numeracin de facturas es hecha por cada cliente.
1.
2.
3.
4.
5.

Indicar si esta relacin est en 1NF

Indicar si est en 2NF
Indicar si est en 3NF
Indicar si est en BCNF
Indicar si est en 4NF

93

Taller4: Analizar las DF en estas tablas de una empresa textil:

De los vendedores: cdula, nombre, apellido, ciudad, direccin, telfono,
celular, porcentaje de comisin, fecha de ingreso, email, pgina web.
De los clientes: cdula, nombre, apellido, ciudad, direccin, telfono, celular
(no nico), cupo de crdito, email, pgina web.
De los pedidos: nmero de pedido, fecha del pedido, valor pedido,
referencias de tela pedidas, metros pedidos.
De las referencias de tela en existencia: cdigo de referencia, nombre de la
referencia, composicin.
De las facturas: nmero factura, fecha factura, valor factura, y descuento.

94

10ElModelosemnticoomodeloE/R.

E/R = Entity (Entidad), Relacin o Tabla

E/R =Vnculo o interrelacin, NO Relacin

Modelo semntico = {entidades, interrelaciones}

95

10.1 Las reglas lgicas o reglas del negocio:

Las Reglas del Negocio describen las polticas, normas, operaciones,

definiciones y restricciones presentes en una organizacin.

Las organizaciones funcionan siguiendo mltiples reglas de negocio,

explcitas o tcitas, que estn embebidas en procesos, aplicaciones
informticas, documentos, etc. Pueden residir en la cabeza de algunas
personas o en el cdigo fuente de programas informticos.
En las reglas del negocio se esconde el modelo E/R:
Los sustantivos pertinentes al negocio son entidades y/o atributos de las
entidades (rectngulos)
Los verbos son interrelaciones (flechas, rombos, tringulos o recuadros)
Las restricciones (la correspondencia entre entidades y su cardinalidad)
sern las restricciones de dominio y de integridad
En la siguiente URL se encuentra el manifiesto de las reglas del negocio:
http://www.businessrulesgroup.org/brmanifesto/BRManifiesto%5Bv1%5B1%5D.0%5D.pdf
96

10.2 Entidades e interrelaciones

Una entidad es aproximadamente un objeto, con:

Identidad (clave primaria)

Estructura (atributos)

Pero sin funcionalidad o comportamiento

Una entidad puede ser concreta como un cliente, una factura, una
materia, o abstracta como un concepto.
Una entidad se representa por un rectngulo:

97

Una interrelacin es un enlace entre entidades y describe:

Asociacin: Oficina y representante

Generalizacin: Cliente, representante

Agregacin: Modelo y sub-modelos de datos.

Una interrelacin es representada por flechas y rombos, tringulos y

recuadros.

98

10.3 Grado de las interrelaciones

Es el nmero de entidades participantes en la interrelacin, y puede ser
binario directo, binario indirecto o n-ario.

Entidad 1

Entidad 2

Entidad 1

grado binario directo

Entidad 1

vnculo

Entidad 2

grado binario indirecto

Entidad 2

entidad n

vnculo

grado n-ario

99

10.4 Correspondencia de las interrelaciones

Expresa el nmero de tuplas que de una entidad corresponden a las de otra
entidad.
La correspondencia de la cardinalidad puede ser
Una a una, 1:1
Una a muchas, 1:N
Muchas a muchas (grado dos), M:N
Muchas a muchas a muchas (grado tres), etc. L:M:N
Una a una. Es cuando a cada tupla de la entidad 1 le corresponde a lo sumo
una tupla de la entidad 2, y a cada tupla de la entidad 2 le corresponde a lo
sumo una tupla de la entidad 1
1:1
oficina

director

100

Una a muchas. Es cuando a cada tupla de una entidad 1 le corresponden

varias tuplas de una entidad 2, pero a cada tupla de la entidad 2 le
corresponde a lo sumo una tupla de la entidad 1.
1:N
clientes

pedidos

Muchas a muchas (grado dos). Es cuando a cada tupla de una entidad 1 le

corresponde varias tuplas de una entidad 2, y a cada tupla de la entidad 2 le
corresponde varias tuplas de la entidad 1.
M:N
clientes

productos

101

Muchas a muchas a muchas (grado tres), etc. Es cuando a cada tupla de una
entidad 1 le corresponde varias tuplas de una entidad 2 y varias tuplas de una
entidad 3, y a cada tupla de la entidad 2 le corresponde varias tuplas de la
entidad 1 y varias tuplas de la entidad 3, y a cada tupla de la entidad 3 le
corresponde varias tuplas de la entidad 1 y varias tuplas de la entidad 2.
L:M:N
clientes

agencias

productos

10.5 Cardinalidad de las interrelaciones

En todas las correspondencias anteriores, adems se considera la cardinalidad
que expresa un mnimo y un mximo de tuplas que de una entidad le
corresponden a cada tupla de la otra, o de las otras entidades. Se acostumbra
anotar como un par entre parntesis: (mnimo, mximo).
102

10.6 Diagramas E/R (Entity/Relationship)

El diagrama E/R es sacado de las reglas del negocio, pero esta fuente no
es suficiente y es necesario completar con otras fuentes como la
investigacin organizacional y el descubrimiento de requisitos.
Un elemento de la ingeniera del software es la especificacin de
requerimientos y requisitos o ingeniera de requisitos.
sta ingeniera es una gua para extraer, analizar, especificar y validar
los requisitos de un proyecto.
Como experiencia personal, tambin es considerable la utilidad del
catlogo de cuentas que toda organizacin debe mantener.
Tal catlogo es el conjunto de cuentas de contabilidad que una empresa
utiliza.
Cada cuenta tiene un nombre que es el nombre de una entidad del
modelo E/R que se busca.
103

Supngase el siguiente modelo E/R:

Trabaja en

oficinas

repventas

Es dirigido

Dirigida por
Es atendido
por

clientes

Tomado por

Es hecho por

pedidos

solicita

productos
104

Error frecuente 1: Aunque a veces s es posible considerar un sustantivo

como una interrelacin (en este caso pedidos), no se puede dejar una
contradiccin como la que se ve entre la lnea verde y la roja

Trabaja en

oficinas

repventas

Es dirigido

Dirigida por
Es atendido
por

clientes

pedidos

productos
105

Errorfrecuente2: Tampoco se puede eliminar la interrelacin es atendido

por para unificarla con pedidos en una interrelacin uno a muchos a
muchos. Una interrelacin uno a muchos a muchos son dos interrelaciones
uno a muchos diferentes.
Trabaja en

oficinas

repventas

Es dirigido

Dirigida por
Es atendido
por

clientes

pedidos

productos
106

Errorfrecuente3: Si en un modelo E/R aparece un ciclo, no se puede decir

que alguno de sus caminos sea redundante sin un previo anlisis de sus
cardinalidades para todas las posibles consultas. Analcese el siguiente caso:
1:N
clientes

(1,N)

(1,1)

1:N

(1,N)

hecho por

Redundante (?)

(1,1)

Es atendido
por

pedidos

repventas
(1,1)

(1,N)

Tomado
por

Ciclo con relativa redundancia

1:N

Redundante (?)

1:N
clientes

(1,N)

(1,1)

1:N

hecho por

No redundante

(1,1)

Es atendido
por

(0,N)

pedidos

repventas
(1,1)

(1,N)

Ciclo sin redundancia

Tomado
por

No redundante
107

1:N

 En el ciclo con redundancia, si el representante de un cliente dado ha

tomado pedidos, tal cliente ha hecho pedidos, porque la cardinalidad
(1,N)(1,1) obliga a que el cliente siempre tenga al menos un pedido.
El camino tomado por y hecho por seran caminos redundantes pues
para una consulta se podra obtener la misma informacin por cualquiera de
ellos.
En el ciclo sin redundancia, si el representante de un cliente dado ha
tomado pedidos, no se puede saber si tal cliente ha hecho o no ha hecho
pedidos, porque la cardinalidad (0,N)(1,1) permite que el cliente exista sin
pedidos.
Si el representante de un cliente dado ha tomado pedidos y el cliente ha
sido atendido por su representante, no se puede deducir que el cliente haya
hecho pedidos, y es necesario el camino hecho por al menos para sta
consulta.
Siempre es necesario tener mucha cautela con los caminos aparentemente
redundantes.
108

10.7 Conversin del diagrama E/R a diagrama referencial (tablas).

Como los rombos, los rectngulos y las flechas no pueden ser descritos para un
computador, es necesario convertirlos a algo que pueda ser descrito en un lenguaje
compilable. Este algo son tablas que puedan ser creadas con create table.
As, cuando la correspondencia es 1:1, la conversin a tablas de acuerdo a su
cardinalidad es:
S

1:1
(1,1)

(0,1)

(1,1)

1:1

(1,1)

S
S
(0,1)

1:1

(0,1)

SP
P

13. Modelo semntico.

109

Cuando la correspondencia es 1:N o M:1, segn su cardinalidad:

S

(1,*)

M:1

(1,1)

S
S

M:1
(1,*)

(0,1)

SP
P

S
S

(0,*)

(0,*)

M:1

(0,1)

SP
P

M:1

(1,1)

13. Modelo semntico.

110

Cuando la correspondencia es M:N, segn su cardinalidad

S
S

(1,M)

M:N

(1,N)

SP
P

S
S

(0,M)

M:N

(1,M)

SP
P

S
S

(0,M)

M:N

(0,M)

SP
P

13. Modelo semntico.

111

Cuando la correspondencia L:M:N, segn su cardinalidad

S
S

L:M:N

SPC
P

C
C

13. Modelo semntico.

112

Volviendo a nuestro diagrama E/R, ste quedar convertido a tablas, en lo que

C. J. Date llama Diagrama referencial, a preparar. Supngase las siguientes
cardinalidades:

Trabaja en
(1,1)

(0,1)

(1,N)

oficinas

vendedores

(0,N)

Es dirigido

(0,1) (0,1) (0,1) (0,N)

Dirigida por

Es atendido
por
(1,N)

clientes

Tomado por
(1,1)

(1,N)
Es hecho por

(1,N)

pedidos
(0,N)
solicita
(1,N)

productos

113

oficinas

vendedores

lderes

atendido por

Tomado por

clientes

pedidos

directores

solicita

productos

114

10.9 El modelo E/R extendido

El modelo ER tradicional solo incluye interrelaciones de asociacin pero no
las de generalizacin ni las de agregacin.
El modelo E/R extendido considera la generalizacin representndola
mediante un tringulo (ISA), y la agregacin mediante un recuadro que
contiene las entidades componentes.
Si en nuestro problema hubisemos considerado que tanto los representantes
de ventas (vendedores) como los clientes son personas, personas podra ser
una clase y vendedores y clientes seran instancias de esta clase, lo cual sera
representado en el diagrama E/R de la siguiente manera:
personas
isa

repventas

clientes

115

 De esta manera, con solo indicar que is a class al crear la tabla personas, y
que is a persona al crear tanto la tabla vendedores como la tabla clientes,
estas tablas (vendedores y clientes) heredaran de la tabla personas todos sus
atributos declarados (como la cdula, los nombres, los apellidos, el telfono, el
celular, la direccin, etc. etc.) sin necesidad de declararlos nuevamente como
atributos en las tablas vendedores y clientes.
Lo anterior se podra rudimentariamente implementar, si el motor no
reconoce herencia, mediante claves forneas en las tablas vendedores y
clientes haciendo referencia a personas.
Para ver la implementacin de la agregacin, analcese el caso de proyectos
en una empresa, desarrollados por diferentes departamentos y en donde cada
departamento puede estar desarrollando ms de un proyecto.
Supngase adems que el departamento financiero no desarrolla proyectos
pero si est encargado del control financiero del desarrollo; no del control de
cada proyecto ni de cada departamento. Para llevar a cabo este control nombra
uno o ms de sus funcionarios para esta tarea.
116
El diagrama E/R para este caso se muestra en la siguiente diapositiva.

funcionarios

controla

proyectos

desarrolla

!?
departamentos

117

funcionarios

controla

proyectos

desarrolla

departamentos

118

 La interrelacin entre los rombos controla y desarrolla no es permitida

en los modelos E/R.
Pero, controla debe convertirse en tabla porque tiene atributos propios
como la fecha desde y hasta la que el funcionario asignado tiene la facultad de
controlar.
El rombo desarrolla debe convertirse en otra tabla diferente porque
tambin tiene atributos propios como la fecha en que cada departamento inici
el desarrollo de cada proyecto y su presupuesto.
El rombo desarrolla se convierte a una tabla que tiene como claves
forneas la clave primaria de la entidad proyectos y la clave primaria de la
entidad departamentos.
El rombo controla queda interrelacionado al recuadro entero (una entidad
compuesta), y no meramente al rombo desarrolla. Por lo tanto, el rombo
controla se convierte a una tabla que tiene como claves forneas la clave
primaria de la tabla desarrolla, y la clave primaria de la entidad
funcionarios.
119

El diagrama referencial, para este caso, puede ser analizado a continuacin:

funcionarios
Cedula
Nombre
Telefono

controla

proyectos
Proy#
Nombre
Valor

Cedula
Proy#
Dep#
Desde
Hasta
Presupuesto

desarrolla

Proy#
Dep#
Inicio

departamentos
Dep#
Nombre
Telefono

120

10.10 Verificacin del grado de normalidad.

El modelado semntico ha sido desarrollado sobre los cimientos del modelo
relacional. Pero, los modelos E/R podran ser vistos en realidad como el
complemento lgico y necesario del modelo relacional. Porque teniendo listo
el conjunto interrelacionado de entidades, es preciso determinar sus atributos
contenidos de tal forma que cada una de tales entidades sea normal a la luz
de la teora de la normalizacin.
Considerando cada tabla obtenida tras la conversin del modelo E/R a tablas,
cada una de tales tablas debe ser verificada individualmente y conjuntamente
para asegurar un grado de normalidad al menos hasta Boyce & Codd.

121

Individualmente verificando que las dependencias funcionales de los atributos

de cada tabla sean las permitidas, y solo las permitidas, con respecto a su clave
primaria. Adicionalmente debe ser verificado el hecho por el que cada uno de
sus atributos debe ser mantenido por obligacin dentro de sus dominios
permitidos.
Conjuntamente verificando que los valores de sus claves forneas sean los
permitidos con respecto a las claves primarias de las dems tablas con las que
se interrelaciona cada tabla en particular, segn las restricciones de la integridad
referencial. Pero tambin verificando que los valores de sus claves forneas
sean los permitidos segn la cardinalidad de cada una de sus interrelaciones.

122

Taller 1.

Se desea construir una Base de datos para llevar los

asuntos acadmicos de una universidad. Las siguientes
son las reglas acadmicas (conocidas en general como
reglas del negocio):
Un estudiante cursa semestralmente varias materias (o ninguna),
an de diferentes carreras. Por cada curso obtendr una nota
que debe permanecer en la Base de datos hasta que el estudiante
se grade.
En cada curso son matriculados muchos estudiantes (al menos
siete), y son asignados varios profesores (al menos uno) para
dictar clase en uno o distintos salones.
13. Modelo semntico.

123

As mismo, un profesor pertenece a una sola escuela (o carrera)

pero puede dictar varias materias (al menos dos), a muchos
estudiantes en distintos salones.
Un curso es vigente solo por un semestre pues, una vez
actualizada la Base de datos con las diferentes notas, el curso
desaparece para permitir la creacin de nuevos cursos en el
siguiente semestre.
Lo anterior implica que, cada materia puede ser dictada por
distintos profesores, a muchos estudiantes, en diferentes salones:
O sea que, una materia puede ser ofrecida en varios cursos.

13. Modelo semntico.

124

Para que un estudiante pueda matricular una materia, l debe

haber cursado previamente otras materias o ninguna. Un
materia puede ser requisito para varias materias (o para
ninguna), y una materia puede tener varias materias como
requisito (o ninguna).

13. Modelo semntico.

125

1. Construir el diagrama E/R.

2. Deducir el respectivo diagrama referencial (DR).
3. Convertir las tablas resultantes en el diagrama referencial a
relaciones con atributos y claves asegurando su normalidad.
4. Crear en SQL las tablas resultantes.

13. Modelo semntico.

126

4. Eliminar los estudiantes cuyo promedio ponderado sea menor

de 3.2 .
5. Listar los estudiantes cuyo promedio ponderado haya sido
mayor a 4.5.

13. Modelo semntico.

127

Modelo E/R para asuntos acadmicos

de una universidad
Carrera = Escuela

carrera

empleado

pertenece

trabajador

salones

profesor

pensum

estudia

estudiante

Ha cursado

cursos
13. Modelo semntico.

128

materias

requisito

Diagrama referencial del modelo

(Las interrelaciones han sido convertidas a tablas)
carrera

saln

profesor

currcula

pensum

estudiante

materias
Ha cursado

cursos

13. Modelo semntico.

129

requisitos

Modelo relacional para asuntos acadmicos

(Cada relacin es normal)
Carrera

Pensum

Codi_car
Nomb_car
Cred_car

Codi_car
Codi_mat

Currcula
Estudiante
Codi_est
Nomb_est
Cedu_est
Dire_est
Tele_est

Codi_est
Codi_car
Fecha_ini
Prom_est
Cred_apr
Veces_con
Fecha_con

Profesor

Cursos

Codi_pro
Cedu_pro
Dedi_pro
Cate_pro
Codi_car

Codi_mat
Codi_gru
Codi_pro
Codi_est
Codi_hor
Codi_dia
Codi_sal

13. Modelo semntico.

Notas

Materias
Codi_mat
Codi_car
Nomb_mat
Cred_mat

Requisitos
Codi_req
Codi_mat

Codi_est
Codi_car
Codi_mat
Nota_mat
Fecha_not

Llave primaria
Llave fornea
Parte de ambas
130

Taller 2. Reglas del negocio de una librera.

Una librera desea desarrollar su propia Base de datos. Los libros estn
dispuestos en estantes por temas. Un estante puede contener varios temas, al
menos uno, y un tema podra estar en varios estantes o en uno al menos. De un
tema puede haber muchos libros, uno al menos, y un libro trata un solo tema y
solo uno.
En dicha librera se sabe que una editorial usualmente publica muchos libros, al
menos de uno, pero que un libro es publicado por una sola editorial y solo una.
As mismo, una editorial edita libros de muchos temas, y un tema suele ser
editado en varias editoriales.
Por otro lado, un libro podra ser escrito por varios autores, al menos por uno, y
un autor podra escribir muchos libros, uno al menos.

13. Modelo semntico.

131

La librera en cuestin esta tambin interesada en registrar las ventas realizadas a

sus diferentes clientes, as como los datos de sus clientes. Entonces, un cliente
podra comprar varios libros, uno al menos, pero un libro podra ser comprado
por muchos clientes o por ninguno. Tenga en cuenta que los clientes y los autores
son personas (naturales o jurdicas).
De las ventas hay que registrar: el libro vendido, el cliente, la fecha de la venta,
el valor de la venta, y los puntos ganados (los cuales sern calculados con cierto
criterio al mismo instante de cada venta).
1.

Construya a partir de estas reglas un modelo E/R.

2.

Deduzca un diagrama referencial segn el anterior MER.

3.

Proponga y especifique usted los atributos y claves que debe contener cada
tabla de modo que todas las relaciones sean normales hasta BCNF.

4.

Cree las tablas de esta Base de datos.

132

11.Integridaddeunabasededatos.
La integridad de las Bases de datos es muy importante porque si sta
no pudiera mantenerse garantizada se desplomara toda la anterior teora
semntico-relacional.
El concepto de integridad conlleva a que la BD debe quedar siempre,
en todo momento y lugar, incorruptible, para lo cual se debe velar por el
estricto cumplimiento de las reglas de integridad.
Existen reglas de integridad especficas y reglas de integridad
generales. Las reglas especficas se refieren a la validez de cada uno de
los valores guardados en la interseccin de cada fila y de cada
columna de cada tabla.
133

Las reglas generales se refieren a la validez de las interrelaciones entre las

entidades de un modelo E/R, o sea, a la correspondencia entre las claves
primarias y las claves forneas de las respectivas tablas de una BD.

11.1Restriccionesdedominio.
Las reglas especficas son conocidas tambin como restricciones de dominio,
ya que limitan los valores posibles que pueden tomar los diferentes atributos de
las entidades.
Por ejemplo, son restricciones de dominio:
Que el cdigo del estudiante sea de diez caracteres y que no pueda ser
ignorado, o sea, char (10) not null.
Que el estado de los proveedores sea un entero entre 1 y 100.
Que los das de la semana deban ser seleccionados de una lista.
Que las notas de los estudiantes sean reales positivos de una cifra entera y
134
otra decimal.

Que la cantidad despachada no sea mayor que la existencia.

Que el mes sea uno de los valores alfanumricos 01, 02, 03, 04, 05,
06, 07, 08, 09, 10, 11 o 12.
Que el nombre del cliente sea alfanumrico de diez caracteres y no pueda
ser ignorado, o sea, char (10) not null.
Etc.
Muchas son las reglas de integridad especficas las cuales se codifican en la
descripcin de las tablas con create table como restricciones de dominio. Con
SQL2 se usa la clusula check como se ilustra en el siguiente ejemplo:
Create table empleado
(
edad smallint not null check (edad >=18);
El conjunto de las reglas especficas o restricciones de dominio puede ser
distinguido aqu como la regla 0 y puede ser enunciada as:
135

Regla 0: Los valores de cualquier atributo de una BD siempre deben ajustarse

a su correspondiente dominio.

11.2Integridaddelasentidades.
Las reglas de integridad referencial generales, por su lado se subdividen en
dos: Una que se refiere a las claves primarias (la regla 1), y otra que se refiere
a las claves forneas (la regla 2).
Regla 1: Ningn componente de la clave primaria de una tabla puede aceptar
nulos.

En efecto, no puede haber tuplas cuya clave de identificacin total o

parcial sea desconocida, es decir cuyo valor sea nulo o contenga nulos, pues
nunca podran ser localizadas.

La anterior regla significa que en una BD jams se podr registrar algo,

ni entidades ni tuplas, que no puedan ser identificadas.

La regla 1 se denomina como la regla de integridad de las entidades.

136

11.3Integridadreferencial.

La integridad referencial hace alusin a la validez de las interrelaciones

entre entidades, y por lo tanto cuestiona la validez de los valores de las
claves forneas ajustados a la cardinalidad establecida en las reglas del
negocio.

La restriccin por la cual los valores de una clave fornea deben

concordar con los valores de la clave primaria correspondiente, se conoce
como restriccin referencial.

La entidad que contiene la clave fornea se llama entidad referente y la

que contiene la clave primaria entidad referida o entidad objetivo, lo
cual se puede representar mediante un diagrama referencial como el
mostrado a continuacin:
cursos

profesor

escuela

137

Cada flecha significa que existe una clave fornea en la entidad de la cual
sale la flecha, que hace referencia a la clave primaria de la entidad a la
cual apunta la flecha.

A diferencia de una clave primaria, una clave fornea si puede tomar

valores nulos si la cardinalidad expresada en las reglas del negocio
consideran la opcionalidad.
Pero si el valor de una clave fornea es no nulo, debe ser idntico al valor
de la clave primaria de alguna tupla en la entidad referida.
La entidad referida y la referente pueden llegar a ser la misma entidad, y
entonces se le llama una entidad autorreferencial. Este es el caso de los
representantes y sus directores para la empresa distribuidora de pedidos.
A veces, la clave fornea puede simultneamente componer la clave
primaria en la relacin que la contiene. Por ejemplo, en la relacin SP, s# y
p# son ambas claves forneas y simultneamente componen la clave
primaria (s#, p#).
Pero a menudo, la clave fornea es distinta de la clave primaria, como en
el caso de la agregacin de atrs con la relacin desarrolla en donde la
clave primaria fue Desa#, y las claves forneas Dep# y Proy#.

138

Las claves forneas que no constituyen la clave primaria tienen toda la

libertad para que sus dominios incluyan valores nulos o repetidos y as
puedan reflejar con mayor exactitud las reglas del negocio.

Observe tambin que, una relacin dada puede contener muchas claves
forneas. En general, si en una interrelacin hay n entidades participantes,
la entidad de la interrelacin contendr n claves forneas.

Sean las relaciones R1, R2, , Rn-1, Rn, tal que existe una restriccin
referencial de R1 a R2, otra de R2 a R3, y otra de Rn-1 a Rn
produciendo el diagrama referencial: R1R2 R3 Rn-1 Rn.

La sucesin de entidades y flechas desde R1 hasta Rn representa un

camino o ruta referencial de R1 a Rn. En un diagrama referencial puede
haber
muchas rutas referenciales en las que las claves forneas deben
concordar con las claves primarias. Entonces, la regla 2 dice:
Regla 2: Una Base de datos no puede contener valores de clave fornea
sin concordancia.

139

O sea, si R1 hace referencia a R2, R2 debe existir. Y si R2 va a ser

eliminada (delete), R1 debe impedirlo, eliminarse tambin o, poner nulos
en su respectiva clave fornea, segn sea la cardinalidad expresada en las
reglas del negocio, para mantener la integridad referencial.

El mismo cuidado hay que tener al hacer inserciones (insert) y

modificaciones (update), para mantener la concordancia entre claves
forneas y claves primarias.

Pero quin debe tener cuidado al realizar operaciones con las claves
forneas? Lo ideal es que el control est a cargo del DBMS y no del sujeto
programador, aunque ste debe dar al DBMS las indicaciones adecuadas.

As, el DBMS debera entender por si solo, que al cancelar una cuenta
corriente, por ejemplo, los cheques girados posteriormente buscando ser
insertados, deben ser rechazados. O que si un cliente cancela su deuda total,
el DBMS debe eliminar (delete) automticamente y en cascada todas las
facturas pendientes de dicho cliente.

140

Entonces, el usuario debe cuestionar por cada clave fornea, cuales

operaciones (insert, delete o upadate) han de rechazarse, y cuales han de
aceptarse y con qu operaciones de compensacin si es el caso.

Por ejemplo Insertando una tupla, puede aceptar nulos su clave

fornea?
Esto se sabra revisando la cardinalidad y los valores posibles
para las claves forneas.

Y Qu debe suceder si hay intento de eliminar una tupla referida por

una clave fornea? Al analizar este caso, hay tres posibilidades de
eliminacin:

Eliminacin restringida (restricted), si el delete a la tupla se puede

realizar solo si no existen otras tuplas que en sus claves forneas la
referencien. Si existen se rechaza.

Eliminacin propagada (cascade), si el delete a la tupla se propaga

(en
cascada) eliminando tambin las tuplas que hacen la referencia. El
programador no necesita as codificar sucesivos deletes.

Eliminacin anulada (set null), si el delete a la tupla se permite pero

asignando nulos a las claves forneas. El programador no necesita
codificar sucesivos updates.
141

Y Qu debe suceder si hay un intento de modificar la clave primaria

referida en una clave fornea? Una vez ms hay tres posibilidades como en
la eliminacin.

Modificacin restringida (restricted): Solo podr estar permitida la

modificacin si no est referida, pero se rechazar si lo est.
Modificacin en cascada: La modificacin se propagar (en cascada)
modificando tambin la clave fornea.
Modificacin anulada (set null): Se asignarn nulos a la clave fornea.

Observe que la respuesta a cada pregunta depende de lo que expresen

las reglas del negocio en la organizacin que se est modelando.

Para responder cada pregunta, en DDL se considera la siguiente sintaxis

de create table:
create table
foreign key (clave) references tabla objetivo
on delete efecto
on update efecto

En donde el efecto puede ser no action o sea restricted, cascades o set null.
142

Por ejemplo:
create table facturas
(factura# char(5) not null,
fecha
date not null,
valor
number(9) not null,
cedula#
char(10) not null,
primary key factura#,
foreign key (cedula#) references clientes
on deletes cascades
on update cascades);

Las anteriores preguntas tambin se pueden responder con DML si su

respuesta no fue clara al momento de describir las tablas con DDL.

Para responder cada pregunta con DML, particularmente si la operacin

es restringida por una condicin, se utilizan las afirmaciones o asertos
(assert) y los disparadores (trigger), cuya sintaxis es:
create assertion nombre del aserto check condicin;

Ejemplo, para que la cantidad de parte p1 enviada sea mayor a 100:

Create assertion envio_valido
143
Check (SP.s#=S.s# and SP.p#=P.p# and SP.p#=p1and SP.cant>=100);

Ejemplo para asegurar que el objetivo de cuota de cada oficina no

supere la suma de las cuotas de sus representantes:
create assertion cuota_valida
check (oficinas.objetivo <= sum(repventas.cuota) and
repventas.oficina_rep = oficinas.oficina);

Ejemplo para asegurar que el total de los pedidos de cualquier cliente no

supere su lmite de crdito.
create assertion control_pedidos
check (clientes.limite_credito >=
select sum(pedidos.importe)
from pedidos
where pedidos.clie = clientes.num_clie);

Transacciones. Los asertos describen restricciones que pueden definirse

como diferidas al fin de cierto conjunto de instrucciones llamado
transaccin. Inicialmente pueden ser declaradas inmediatas, o al contrario.
No obstante, tales caractersticas pueden ser modificadas dinmicamente
con la instruccin
144

set constraints nombre del aserto {deferred/immediate}.

Por ejemplo, supongamos que la anterior asercin sea declarada diferible al

terminar una transaccin pero inicialmente inmediata:
create assertion control_pedidos
check (clientes.limite_credito >=
select sum(pedidos.importe)
from pedidos
where pedidos.clie = clientes.num_clie)
deferrable initially immediate;

Esta restriccin ser procesada automticamente instruccin por instruccin

(lneas negras) pero despus del set constraints control_pedidos deferred
ser procesada diferida (deferred) al terminar la transaccin (lneas rojas),
inmediatamente despus del commit.

set constraints control_pedidos deferred

Commit;

145

Los trigger son fragmentos de cdigo que se ejecutan en forma implcita

con la ejecucin de un insert, de un update o de un delete sobre una tabla.

Aunque los conceptos de los trigger son muy consistentes de unos

motores a otros, sus particularidades sintcticas si varan bastante de un
motor a otro.

Para oracle, su sintaxis es la siguiente:

create [or replace] trigger
{beforeafter}

suceso disparo

[for each row [when

on

condicin

nombre del trigger

tabla

]]

cuerpo del trigger

Suponiendo definidas las tablas cursos (C), estudiantes (E) y

matriculas (M), veamos el trigger para actualizar los atributos
total_matriculas y total_crditos matriculados en cada curso,
creando el curso si no existe, cada vez que se inserte, se actualice o se
borre una
Tambin se asume
C(1,*)E(1,*) como
(M)
Cursos
(C) tupla de matriculas.
Estudiantes
(E) Matriculas
cod_c cod_e creditos
cardinalidad.
nombre_e
cod_c
total_matriculas total_creditos cod_e
146

create or replace trigger actualiza_cursos

after insert or delete or update on M
declare
cursor c_Totales is
select cod_c, count(*) totalmatriculas,
sum(creditos) totalcreditos
from M
group by cod_c
begin
for v_Totales in c_Totales
loop
update C
set total_matriculas = v_Totales.totalmatriculas
total_creditos = v_Totales.totalcreditos
where cod_c = v_Totales.cod_c;
if sql%notfound then
insert into C (cod_c, total_matriculas, total_creditos)
values(v_Totales.cod_c,
v_Totales.totalmatriculas,
v_Totales.totalcreditos);
end if;
end loop;
147
End actualiza_cursos;