2.- Modelamiento de Datos (Modelo Entidad Relacin).

El modelo E-R se basa en una percepcin del mundo real, la cual esta formada por
objetos bsicos llamados entidades y las relaciones entre estos objetos as como las
caractersticas de estos objetos llamados atributos.

2.1.- Entidades y conjunto de entidades

Una entidad es un objeto que existe y se distingue de otros objetos de acuerdo a sus
caractersticas llamadas atributos . Las entidades pueden ser concretas como una
persona o abstractas como una fecha.

Un conjunto de entidades es un grupo de entidades del mismo tipo.

Por ejemplo el conjunto de entidades CUENTA, podra representar al conjunto de cuentas

de un banco, o ALUMNO representa a un conjunto de entidades de todos los alumnos
que existen en una institucin.

Una entidad se caracteriza y distingue de otra por los atributos, en ocasiones llamadas
propiedades, que representan las caractersticas de una entidad.

Los atributos de una entidad pueden tomar un conjunto de valores permitidos al que se le
conoce como dominio del atributo.

As cada entidad se describe por medio de un conjunto de parejas formadas por el

atributo y el valor de dato. Habr una pareja para cada atributo del conjunto de entidades.

2.2.- Relaciones y conjunto de relaciones.

Una relacin es la asociacin que existe entre dos a ms entidades.

Un conjunto de relaciones es un grupo de relaciones del mismo tipo.

La cantidad de entidades en una relacin determina el grado de la relacin, por ejemplo

de una relacin ALUMNO-MATERIA es de grado 2, ya que intervienen la entidad
ALUMNO y la entidad MATERIA, la relacin PADRES, puede ser de grado 3, ya que
involucra las entidades PADRE, MADRE e HIJO.

Aunque el modelo E-R permite relaciones de cualquier grado, la mayora de las

aplicaciones del modelo slo consideran relaciones del grado 2.

Cuando son de tal tipo, se denominan relaciones binarias.

La funcin que tiene una relacin se llama papel, generalmente no se especifican los
papeles o roles, a menos que se quiera aclarar el significado de una relacin.
Diagrama E-R (sin considerar los atributos, slo las entidades) para los modelos
ejemplificados:

2.3.- Tipos de relaciones:

2.3.1.- Relacin uno a uno.

Se presenta cuando existe una relacin como su nombre lo indica uno a

uno, denominado tambin relacin de matrimonio.

Una entidad del tipo A solo se puede relacionar con una entidad del tipo B, y
viceversa.

Por ejemplo: la relacin asignacin de automvil que contiene a las entidades

EMPLEADO, AUTO, es una relacin 1 a 1, ya que asocia a un empleado con un
nico automvil por lo tanto ningn empleado posee ms de un automvil
asignado, y ningn vehculo se asigna a ms de un trabajador.

Es representado grficamente de la siguiente manera:

A: Representa a una entidad de cualquier tipo diferente a una entidad B.

R: en el diagrama representa a la relacin que existe entre las entidades.

El extremo de la flecha que se encuentra punteada indica el uno de la relacin, en

este caso, una entidad A ligada a una entidad B.
2.3.2.- Relacin uno a muchos.

Significa que una entidad del tipo A puede relacionarse con cualquier
cantidad de entidades del tipo B, y una entidad del tipo B solo puede estar
relacionada con una entidad del tipo A.

Su representacin grfica es la siguiente:

Ntese en este caso que el extremo punteado de la flecha de la relacin de A y B,

indica una entidad A conectada a muchas entidades B.

2.3.3.- Relacin Muchos a uno.

Indica que una entidad del tipo B puede relacionarse con cualquier cantidad
de entidades del tipo A, mientras que cada entidad del tipo A solo puede
relacionarse con solo una entidad del tipo B.

2.3.4.- Relacin Muchas a muchas.

Establece que cualquier cantidad de entidades del tipo A pueden estar

relacionados con cualquier cantidad de entidades del tipo B.
A los tipos de relaciones antes descritos, tambin se le conoce como cardinalidad.

La cardinalidad nos especifica los tipos de relaciones que existen entre las entidades en el
modelo E-R y establecer con esto las validaciones necesarias para conseguir que los
datos de la instancia (valor nico en un momento dado de una base de datos)
correspondan con la realidad.

Algunos ejemplos de cardinalidad de la vida comn pueden ser:

Uno a uno.

El noviazgo, el RUT de cada persona.

El acta de nacimiento, ya que solo existe un solo documento de este tipo

para cada una de las diferentes personas.

Uno a muchos.

Cliente Cuenta en un banco, Padre-Hijos, Camin-Pasajeros, zoolgico-

animales, rbol hojas.

Muchos a muchos.

Arquitectos proyectos, estudiante materias.

2.4.- Llaves primarias.

Como ya se ha mencionado anteriormente, la distincin de una entidad entre otra

se debe a sus atributos, lo cual lo hacen nico.

Una llave primaria es aquel atributo el cual consideramos clave para la identificacin de
los dems atributos que describen a la entidad.

Por ejemplo, si consideramos la entidad ALUMNO de una Universidad podramos tener

los siguientes atributos: Nombre, Semestre, Especialidad, Direccin, Telfono, Nmero
de matrcula, de todos estos atributos el que podremos designar como llave primaria es el
nmero de matrcula, ya que es diferente para cada alumno y este nos identifica en la
institucin.

Claro que puede haber ms de un atributo que pueda identificarse como llave primaria en
este caso se selecciona la que consideremos ms importante, los dems atributos son
denominados llaves secundarias.

Una clave o llave primaria es indicada grficamente en el modelo E-R con una lnea
debajo del nombre del atributo.
2.5.- Diagrama Entidad-Relacin

Denominado por sus siglas como: E-R; Este modelo representa a la realidad a
travs de un esquema grfico empleando los terminologa de entidades, que son objetos
que existen y son los elementos principales que se identifican en el problema a resolver
con el diagramado y se distinguen de otros por sus caractersticas particulares
denominadas atributos, el enlace que rige la unin de las entidades esta representada
por la relacin del modelo.

Recordemos que un rectngulo nos representa a las entidades; una elipse a los atributos
de las entidades, y una etiqueta dentro de un rombo nos indica la relacin que existe entre
las entidades, destacando con lneas las uniones de estas y que la llave primaria de una
entidad es aquel atributo que se encuentra subrayado.

A continuacin mostraremos algunos ejemplos de modelos E-R, considerando las

cardinalidades que existen entre ellos:

2.5.1.- Relacin Uno a Uno.

Problema :

Disear el modelo E-R, para la relacin Registro de automvil que consiste en

obtener la tarjeta de circulacin de un automvil con los siguientes datos:-
Automvil- Modelo, Placas, Color - tarjeta de circulacin -Propietario, N serie,
Tipo.

Indicamos con este ejemplo que existe una relacin de pertenencia de uno a uno, ya que
existe una tarjeta de circulacin registrada por cada automvil.

En este ejemplo, representamos que existe un solo presidente para cada pas.
2.5.1.- Relacin uno a muchos.

El siguiente ejemplo indica que un cliente puede tener muchas cuentas, pero
que una cuenta puede llegar a pertenecer a un solo cliente (Decimos puede, ya que
existen cuentas registradas a favor de ms de una persona).

2.6.- Normalizacin.

En el proceso de normalizacin, segn la propuesta original de Codd (1972), se

somete un esquema de relacin a una serie de pruebas para "certificar si pertenece o
no a una cierta forma normal.

En un principio, Codd propuso tres formas normales, a las cuales llam primera, segunda
y tercera formas normales (1FN, 2FN, 3FN).

Posteriormente, Boyce y Codd propusieron una definicin ms estricta de 3FN, a la que

se conoce como Forma Normal de Boyce-Codd (FNBC).

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

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

La normalizacin de los datos puede considerarse como un proceso durante el cual los
esquemas de relacin que no cumplen las condiciones se descomponen repartiendo sus
atributos entre esquemas de relacin ms pequeos que cumplen las condiciones
establecidas.

Un objetivo del proceso de normalizacin es garantizar que no ocurran anomalas de

actualizacin.

Las formas normales, consideradas aparte de otros factores, no garantizan un buen

diseo de BD.

Otro punto que merece la pena destacar es que los diseadores de BD no tienen que
normalizar hasta la forma normal ms alta posible.
Las relaciones pueden dejarse en formas normales inferiores por razones de
rendimiento

El proceso de normalizacin es un estndar que consiste, bsicamente, en un proceso de

conversin de las relaciones entre las entidades, cuyo objetivo es evitar:

La redundancia de los datos: Repeticin de datos en un sistema.

Anomalas de actualizacin: Inconsistencias de los datos como resultado de

datos redundantes y actualizaciones parciales.

Anomalas de borrado: Prdidas no intencionadas de datos debido a que se han

borrado otros datos.

Anomalas de insercin: Imposibilidad de adicionar datos en la base de datos

debido a la ausencia de otros datos.

Tomando como referencia la tabla siguiente:

AUTORES Y LIBROS
NOMBRE NACION CODLIBRO TITULO EDITOR
Smith USA 999 IBD AW
Perez ESP 888 CyD RM
Monetta ITA 777 CyD RM
Smith USA 666 BdD AW

Se plantean una serie de problemas:

Redundancia: cuando un autor tiene varios libros, se repite la nacionalidad.

Anomalas de modificacin: Si Prez y Monetta desean cambiar de editor, se

modifica en los 2 lugares.

A priori no podemos saber cuntos autores tiene un libro. Los errores son
frecuentes al olvidar la modificacin de un autor.

Se pretende modificar en un slo sitio.

Anomalas de insercin: Se desea ingresar un autor sin libros, en un principio.

NOMBRE y CODLIBRO son campos clave, una clave no puede tomar valores
nulos.
Definicin de la clave

Antes de proceder a la normalizacin de la tabla lo primero que debemos de definir

es una clave, esta clave deber contener un valor nico para cada registro (no podrn
existir dos valores iguales en toda la tabla) y podr estar formado por un nico campo o
por un grupo de campos.

En la tabla de alumnos de un centro de estudios no podemos definir como campo clave el

nombre del alumno ya que pueden existir varios alumnos con el mismo nombre.

Podramos considerar la posibilidad de definir como clave los campos nombre y apellidos,
pero estamos en la misma situacin: podra darse el caso de alumnos que tuvieran los
mismo apellidos y el mismo nombre (Juan Fernndez Martn).

La solucin en este caso es asignar un cdigo de alumno a cada uno, un nmero que
identifique al alumno y que estemos seguros que es nico.

Una vez definida la clave podremos pasar a estudiar la primera forma normal.

2.6.1.- Primera forma normal (1FN):

Una relacin est en primera forma normal (1FN) si los valores para cada atributo de la relacin son atmicos.

Esto quiere decir simplemente que cada atributo slo puede pertenecer a un dominio (es
indivisible) y que tiene un valor nico para cada fila.

La primera forma normal se defini para prohibir los atributos multivaluados, compuestos
y sus combinaciones.

Cuando una relacin no est en primera forma normal, se divide en otras relaciones,
repartiendo sus atributos entre las resultantes.

Normalmente la idea es eliminar el atributo que viola la 1 FN de la relacin original y

colocarlo en una relacin aparte junto con la clave primara de la relacin de partida.

Se dice que una tabla se encuentra en primera forma normal (1NF) si y solo si cada
uno de los campos contiene un nico valor para un registro determinado.

Supongamos que deseamos realizar una tabla para guardar los cursos que estn
realizando los alumnos de un determinado centro de estudios, podramos considerar el
siguiente diseo:

Cdigo Nombre Cursos

1 Marcos Ingls
2 Lucas Contabilidad, Informtica
3 Marta Ingls, Contabilidad
Podemos observar que el registro de cdigo 1 si cumple la primera forma normal, cada
campo del registro contiene un nico dato, pero no ocurre as con los registros 2 y 3 ya
que en el campo cursos contiene ms de un dato cada uno.

La solucin en este caso es crear dos tablas del siguiente modo:

Tabla A (alumnos)
Cdigo Nombre
1 Marcos
2 Lucas
3 Marta

Tabla B (Cursos)
Cdigo Curso
1 Ingls
2 Contabilidad
2 Informtica
3 Ingls
3 Informtica

Como se puede comprobar ahora todos los registros de ambas tablas contienen valores
nicos en sus campos, por lo tanto ambas tablas cumplen la primera forma normal.

Una vez normalizada la tabla en 1NF, podemos pasar a la segunda forma normal.

2.6.2.- Segunda forma normal (2FN):

Una relacin est en segunda forma normal si est en la 1 FN y todos los atributos no clave dependen de la clave completa y no slo de
una parte de esta.

Si todos los campos dependen directamente de la clave se dice que la tabla est es
segunda forma normal (2NF).

Este paso slo se aplica a relaciones que tienen claves compuestas, es decir, que estn
formadas por mas de un atributo.

Si un esquema de relacin no est en 2FN, se le puede normalizar a varias relaciones en

2FN en las que los atributos que dependen de una parte de la clave formarn una nueva
relacin que tendr esa parte de la clave como clave primaria.
La segunda forma normal compara todos y cada uno de los campos de la tabla con la
clave definida.

Supongamos que construimos una tabla con los aos que cada empleado ha estado
trabajando en cada departamento de una empresa:

Cdigo Empleado Cdigo Dpto. Nombre Departamento Aos

1 6 Juan Contabilidad 6
2 3 Pedro Sistemas 3
3 2 Sonia I+D 1
4 3 Vernica Sistemas 10
2 6 Pedro Contabilidad 5

Tomando como punto de partida que la clave de esta tabla est formada por los campos
cdigo de empleado y cdigo de departamento, podemos decir que la tabla se encuentra
en primera forma normal, por tanto vamos a estudiar la segunda:

El campo nombre no depende funcionalmente de toda la clave, slo depende del cdigo
del empleado.

El campo departamento no depende funcionalmente de toda la clave, slo del cdigo del
departamento.

El campo aos si que depende funcionalmente de la clave ya que depende del cdigo del
empleado y del cdigo del departamento (representa el nmero de aos que cada
empleado ha trabajado en cada departamento)

Por tanto, al no depender todos los campos de la totalidad de la clave la tabla no est en
segunda forma normal, la solucin es la siguiente:

Tabla A (empleado)
Cdigo Empleado Nombre
1 Juan
2 Pedro
3 Sonia
4 Vernica

Tabla B (departamentos)
Cdigo Departamento Dpto.
2 I+D
3 Sistemas
 6 Contabilidad

Tabla C (aos empleado por departamento)

Cdigo Empleado Cdigo Departamento Aos
1 6 6
2 3 3
3 2 1
4 3 10
2 6 5

Podemos observar que ahora si se encuentran las tres tabla en segunda forma normal,
considerando que la tabla A tiene como ndice el campo Cdigo Empleado, la tabla B
Cdigo Departamento y la tabla C una clave compuesta por los campos Cdigo Empleado
y Cdigo Departamento.

2.6.3.- Tercera forma normal (3FN):

"Una relacin est en tercera forma normal si todos los atributos de la relacin dependen funcionalmente slo de la clave, y no de ningn
otro atributo".

Se dice que una tabla est en tercera forma normal si y solo si los campos de la
tabla dependen nicamente de la clave, dicho en otras palabras los campos de las
tablas no dependen unos de otros.

Podemos observar que si una relacin est en tercera forma normal, est tambin en
segunda forma normal, sin embargo lo inverso no siempre es cierto.

Tomando como referencia el ejemplo anterior, supongamos que cada alumno slo puede
realizar un nico curso a la vez y que deseamos guardar en que aula se imparte el curso.

A voz de pronto podemos plantear la siguiente estructura:

Cdigo Nombre Curso Aula

1 Marcos Informtica Aula A
2 Lucas Ingls Aula B
3 Marta Contabilidad Aula C

Estudiemos la dependencia de cada campo con respecto a la clave cdigo:

Nombre depende directamente del cdigo del alumno.

Curso depende de igual modo del cdigo del alumno.

El aula, aunque en parte tambin depende del alumno, est ms ligado al curso que el
alumno est realizando.

Por esta ltima razn se dice que la tabla no est en 3NF.

La solucin sera la siguiente:

Tabla A (alumnos-cursos)
Cdigo Nombre Curso
1 Marcos Informtica
2 Lucas Ingls
3 Marta Contabilidad

Tabla B (curso-
aula)
Curso Aula
Informtica Aula A
Ingls Aula B
Contabilidad Aula C

Una vez conseguida la tercera forma normal, se puede estudiar la cuarta forma normal.

2.6.4.- Cuarta forma normal (4NF)

Una tabla est en cuarta forma normal si y slo si para cualquier combinacin clave
- campo no existen valores duplicados.

Vemoslo con un ejemplo:

Geometra
Figura Color Tamao
Cuadrado Rojo Grande
Cuadrado Azul Grande
Cuadrado Azul Mediano
Crculo Blanco Mediano
 Crculo Azul Pequeo
Crculo Azul Mediano

Comparemos ahora la clave (Figura) con el atributo Tamao, podemos observar que
Cuadrado Grande est repetido; igual pasa con Crculo Azul, entre otras.

Estas repeticiones son las que se deben evitar para tener una tabla en 4NF.

La solucin en este caso sera la siguiente:

Tamao
Figura Tamao
Cuadrado Grande
Cuadrado Pequeo
Crculo Mediano
Crculo Pequeo

Color
Figura Color
Cuadrado Rojo
Cuadrado Azul
Crculo Blanco
Crculo Azul

Ahora si tenemos nuestra base de datos en 4NF.

2.6.5.- Otras formas normales

Existen otras dos formas normales, la llamada quinta forma normal (5FN) que se no
detalla por su dudoso valor prctico ya que conduce a una gran divisin de tablas y la
forma normal dominio / clave (FNDLL) de la que no existe mtodo alguno para su
implantacin.

2.6.6.- Las interrelaciones

 Las interrelaciones son las relaciones que existen entre varias tablas del sistema
(Clientes y Pedidos, por ejemplo).

Existen tres formas de interrelaciones dependiendo de la cardinalidad con la que se

combinan los elementos de ambas tablas.

2.6.6.1.- Interrelaciones uno a uno

Una interrelacin es de uno a uno entre la tabla A y la tabla B cuando a cada

elemento de la clave de A se le asigna un nico elemento de la tabla B y para cada
elemento de la clave de la tabla B contiene un nico elemento en la tabla A.

Un ejemplo de interrelacin de este tipo es la formada por las tablas Datos

Generales de Clientes y Datos Contables de Clientes. En esta relacin cada
cliente tiene una nica direccin y una direccin en cada una de las tablas.
Representamos la relacin como A 1: 1 B.

Ante la presencia de este tipo de relacin nos podemos plantear el caso de unificar
todos los datos en nica tabla pues no es necesario mantener ambas tablas a la
misma vez.

Este tipo de relacin se genera cuando aparecen tablas muy grandes, con gran
cantidad de campos, disgregando la tabla principal en dos para evitar tener una
tabla muy grande.

Tambin surge cuando los diferentes grupos de usuario cumplimentan una

informacin diferente para un mismo registros; en este caso se crean tantas tablas
como registros, evitando as tener que acceder a informacin que el usuario del
grupo actual no necesita.

2.6.6.2.- Interrelaciones uno a varios

Una interrelacin es de uno a varios entre las tablas A y B cuando una

clave de la tabla A posee varios elementos relacionados en la tabla B y cuando
una clave de la tabla B posee un nico elemento relacionado en la tabla A.

Estudiemos la relacin entre la tabla de clientes y la tabla de pedidos. Un cliente

puede realizar varios pedidos pero un pedido pertenece a un nico cliente, por
tanto se trata de una relacin uno a varios y la representamos A 1: n B.

Estas relaciones suelen surgir de aplicar la 1NF a una tabla.

2.6.2.3.- Interrelaciones varios a varios

Una interrelacin es de varios a varios entre las tablas A y B cuando una

clave de la tabla A posee varios elementos relacionados en la tabla B y cuando
una clave de la tabla B posee varios elementos relacionados en la tabla A.
 Un caso muy caracterstico de esta interrelacin es la que surge entre las tablas de
Puestos de Trabajo y Empleados de una empresa.

Un Empleado puede desempear realizar varias funciones dentro de una empresa

(desempear varios puestos de trabajo), y un puesto de trabajo puede estar
ocupado por varios empleados a la misma vez.

Esta interrelacin la representamos como A n: n B.

No se deben definir relaciones de este tipo en un sistema de bases de datos,

debido a su complejidad a la hora de su mantenimiento, por este motivo se debe
transformar este tipo de relacin es dos interrelaciones de tipo 1: n, empleando
para ello una tabla que denominaremos puente y que estar formada por las
claves de ambas tablas.

Esta tabla puente debe contener una nica clave compuesta formada por los
campos clave de las tablas primeras.

Empleados
Cdigo Empleado Empleado
103 Juan
105 Luisa
251 Martn
736 Ana Mara

Puestos
Cdigo Puesto Puesto
52 Comercial
73 Administrativo

Tabla Puente
Cdigo Empleado Cdigo Puesto
103 52
103 73
105 73
251 52
736 52
736 73

Ahora existe una relacin 1: n entre Empleados y Tabla Puente y otra relacin 1: n entre
Puestos y Tabla Puente ya que un empleado posee varios cdigos de empleado en la
tabla puente pero cada elemento de la tabla puente pertenece a un nico empleado.
Por otro la un puesto de trabajo posee varios elementos relacionados en la tabla puente,
pero cada elemento de la tabla puente est relacionado con un nico elemento de la tabla
puestos.

2.7.- Problemas con las interrelaciones

A la hora de establecer las interrelaciones existentes en un sistema de bases de datos

nos podemos encontrar dos problemas:

Interrelaciones recursivas: un elemento se relaciona consigo mismo

directamente.

Interrelaciones circulares o cclicas: A se relaciona con B, B se relaciona con C

y C se relaciona con A.

Ambos casos pueden suponer un grave problema si definimos una relacin con integridad
referencial y decimos eliminar en cascada (al eliminar una clave de la tabla A se eliminan
los elementos relacionados en la tabla B).

Supongamos la relacin recursiva existen en la relacin Empleado y Supervisor (ambos

son empleados de la empresa).

Est claro que un empleado est supervisado por otro empleado.

Veamos la forma de solucionarlo:

Empleados
Cdigo Nombre Supervisor
102 Juan NO
105 Luis SI
821 Mara NO
956 Martn SI

Para solucionar la relacin debemos crear una tabla formada por dos campos.

Ambos campos deben ser el cdigo del empleado pero como no podemos tener dos
campos con el mismo nombre a uno de ellos le llamaremos cdigo supervisor.

Tabla Puente
Cdigo Empleado Cdigo Supervisor
102 105
 105 956
821 105
956 105

Para terminar de resolver la interrelacin recursiva basta con definir dos interrelaciones
entre la tabla empleados y la tabla puente de tipo 1: n.

La primera relacin se crea utilizando las claves Empleados[Cdigo] y Tabla

Puente[Cdigo Empleado]. La segunda entre Empleados[Cdigo] y Tabla Puente [Cdigo
Supervisor].

Las interrelaciones cclicas o circulares no son muy frecuentes y no existe una

metodologa estndar para su eliminacin, normalmente son debidas a errores de diseo
en la base de datos, principalmente en el diseo conceptual del sistema de datos.

Por tanto si llegamos a este punto hay que volver a replantearse todo el diseo de la base
de datos.

2.8.- Atributos de las interrelaciones

En la mayora de las interrelaciones definidas ser conveniente exigir integridad relacional

entre las claves.

Exigiendo la integridad referencial se consigue que en una relacin de tipo 1: n o de tipo

1: 1, no se puede aadir ningn valor en la tabla destino si no existe en la tabla origen.

Dicho con un ejemplo: en la relacin Clientes y Pedidos la tabla Pedidos contiene un

campo que se corresponde con el cdigo del Cliente, si se exige la integridad referencia
no se podr escribir un cdigo de cliente en la tabla Pedidos que no exista en la tabla
Clientes; de no exigir la integridad referencial se podrn crear pedidos con cdigos de
clientes que no existen, generando incongruencia de datos en la base de datos.

Definida la integridad referencial (siempre necesaria) podemos exigir la actualizacin en

cascada (siempre necesaria); esta actualizacin implica que si cambiamos el cdigo a un
cliente, debemos actualizar dicho cdigo en la tabla de pedidos, de no ser as, al cambiar
el cdigo a un cliente, perderemos los pedidos que tena realizados.

Para concluir debemos hablar de la eliminacin en cascada (NO siempre necesaria), la

eliminacin en cascada consiste en eliminar todos los datos dependientes de una clave.

En nuestro ejemplo implica que al borrar un cliente hay que eliminar todos los pendidos
que ha realizado.

En muchas ocasiones no interesa realizar esta operacin de eliminacin en cascada por

motivos diversos.
Si en el caso de clientes y pedidos no se exige eliminacin en cascada no se podr borrar
ningn cliente en tanto en cuanto tenga realizado algn pedido (de lo contrario tendramos
incongruencia de datos).