Manual Prof - Luza PDF

Modelado y Diseo de Base de datos Csar Luza Montero
1

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS
FACULTAD DE INGENIERA DE SISTEMAS E INFORMATICA

MODELADO Y DISEO DE BASE DE DATOS

CSAR LUZA MONTERO

LIMA-PER, 2010
2

Contenido
UNIDAD 1................................................................................................................................ 4
INTRODUCCIN A LOS SISTEMAS DE BASE DE DATOS Y AL DISEO DE BASE DE
DATOS ..................................................................................................................................... 4
Leccin 1.................................................................................................................................. 5
Introduccin a los Sistemas de Base de Datos ........................................................................ 5
1.1 Sistema de Archivos .................................................................................................................... 5
1.2 Sistema de Base de Datos ........................................................................................................... 6
1.3 Base de Datos .............................................................................................................................. 7
1.4 Sistema de gestin de base de datos .......................................................................................... 8
1.5 Arquitectura de tres niveles ........................................................................................................ 9
1.6 Independencia de datos ............................................................................................................ 10
Leccin 2................................................................................................................................ 11
Introduccin al Diseo de Base de Datos .............................................................................. 11
2.1 Qu es el diseo de base de datos? ........................................................................................ 11
2.2 Fases del diseo de base de datos ............................................................................................ 11
2.3 Un ejemplo sencillo de diseo de base de datos ...................................................................... 12
2.4 Modelos de Datos ..................................................................................................................... 13
2.5 Abstracciones de datos ............................................................................................................. 15
Resumen ................................................................................................................................ 17
Lectura................................................................................................................................... 18
Actividades ............................................................................................................................ 19
Autoevaluacin ...................................................................................................................... 19
Exploracin On-Line .............................................................................................................. 20
Referencias Bibliogrficas ..................................................................................................... 20

UNIDAD 2.............................................................................................................................. 21
EL MODELO ENTIDAD-RELACIN (MER) .......................................................................... 21
Leccin 3................................................................................................................................ 22
Conceptos asociados al MER ................................................................................................. 22
3.1 Qu es el MER? ....................................................................................................................... 22
3.2 Entidad y Atributo ..................................................................................................................... 22
3.3 Tipo de Entidad, Atributo Identificador y Conjunto de valores ................................................ 23
3.4 Relacin y Tipo de Relacin....................................................................................................... 25
Leccin 4................................................................................................................................ 29
Extendiendo el MER .............................................................................................................. 29
4.1 Razn de Participacin .............................................................................................................. 29
4.2 Entidades dbiles ...................................................................................................................... 30
4.3 Generalizacin o Especializacin............................................................................................... 30
Leccin 5................................................................................................................................ 35
Proceso de Construccin de un MER .................................................................................... 35
5.1 Identificar Tipos de Entidades ................................................................................................... 35
5.2 Identificar Atributos .................................................................................................................. 35
5.3 Identificar Tipos de relaciones .................................................................................................. 36
5.4 Determinar Identificadores y Entidades dbiles ....................................................................... 36
5.5 Determinar Jerarquas de Generalizacin ................................................................................ 36
5.6 Revisar el Esquema Conceptual ............................................................................................. 36
5.7 Casos de ejemplo ..................................................................................................................... 37
Resumen ................................................................................................................................ 40
Lectura................................................................................................................................... 41
Actividades ............................................................................................................................ 43
Autoevaluacin ...................................................................................................................... 45
Exploracin On-Line .............................................................................................................. 46
3


UNIDAD 3.............................................................................................................................. 48
EL MODELO RELACIONAL (MR) ......................................................................................... 48
Leccin 6................................................................................................................................ 49
Definicin y elementos del MR .............................................................................................. 49
4.1 Definicin .................................................................................................................................. 49
4.2 Elementos ................................................................................................................................. 49
4.3 Reglas ........................................................................................................................................ 51
Leccin 7................................................................................................................................ 53
Transformacin de un MER a MR ......................................................................................... 53
7.1 Transformacin de tipo de entidad........................................................................................... 53
7.2 Transformacin de tipo de relacin .......................................................................................... 53
7.3 Transformacin de entidades dbiles ....................................................................................... 55
7.4 Transformacin de generalizaciones ........................................................................................ 55
7.5 Caso Ejemplo ............................................................................................................................. 56
Leccin 8................................................................................................................................ 58
Normalizacin ....................................................................................................................... 58
8.1 Definicin .................................................................................................................................. 58
8.2 Dependencias funcionales ........................................................................................................ 58
8.3 Formas normales....................................................................................................................... 59
8.4 Proceso de Normalizacin......................................................................................................... 61
8.5 Normalizacin Avanzada ........................................................................................................... 65
Resumen ................................................................................................................................ 66
Actividades ............................................................................................................................ 67

GLOSARIO ............................................................................................................................. 70
BIBLIOGRAFA GENERAL .................................................................................................... 71

4

UNIDAD 1
INTRODUCCIN A LOS SISTEMAS DE
BASE DE DATOS Y AL DISEO DE BASE
DE DATOS

Qu es un Sistema de Base de datos? Qu es una Base de Datos?
Qu es un Sistema de gestin de base de datos? Quines son los usuarios?
En qu consiste la arquitectura de tres niveles?
En qu consiste la independencia de datos?
Cules son las fases del proceso de diseo de base de datos?
Qu son los modelos de datos? Cmo se clasifican?
Qu es abstraccin de datos? Qu tipos de abstraccin existen?

5

Leccin 1
Introduccin a los Sistemas de Base de
Datos
Las organizaciones requieren de informacin para apoyar sus actividades de toma de
decisiones y controlar sus operaciones rutinarias. Esta informacin se transmite en todos los
niveles de la organizacin a travs de los sistemas de informacin. Uno de los componentes
fundamentales de los sistemas de informacin modernos es el Sistema de Base de Datos. Su
propsito es almacenar, recuperar y mantener las grandes cantidades de datos requeridos por
la organizacin.
1.1 Sistema de Archivos
Tradicionalmente, para almacenar los datos, se utilizaban los llamados sistemas de archivos.
En este enfoque, los archivos se diseaban para cada programa de aplicacin destinado a
apoyar las actividades de un departamento especfico. Cada departamento era responsable de
crear y mantener los datos en sus propios archivos a travs de sus programas de aplicacin.
Por ejemplo, en la figura 1.1 se aprecia que el Dpto. de Ventas es responsable de los datos de
Empleados y Clientes; el Dpto. de Personal, de los datos de Empleados y Nominas, y el Dpto.
de Contabilidad, de los datos de Empleados, Clientes y Nminas.
Figura 1.1 Organizacin de los datos mediante archivos

Fuente
1
: Elaboracin propia
Como se aprecia, esta forma de organizacin implicaba que los archivos por departamento
podran contener informacin duplicada (redundancia de informacin), que ocasionaba uso
inadecuado de espacio en disco y posibles inconsistencias porque un mismo dato podra
reflejar diferentes valores. Asimismo, se generaba dependencia de los datos respecto del
soporte fsico y los programas, que conlleva a falta de flexibilidad frente a cambios.
Adicionalmente, los sistemas de archivos no eran apropiados para sistemas de ayuda a la toma
de decisiones.

1
En lo sucesivo, en este libro, si las figuras, imgenes o tablas no consignan fuente, es porque son de
propia elaboracin.
6

1.2 Sistema de Base de Datos
La idea de los sistemas de base de datos es mantener los datos en un repositorio centralizado
(base de datos) evitando los inconvenientes generados por los sistemas de archivos. Cada
departamento crea, mantiene y recupera la informacin de este repositorio centralizado, no
de sus propios archivos (figura 1.2).
Para lograr este objetivo, los sistemas de base de datos tienen un componente software,
llamado sistema de gestin de base de datos (SGBD), que permite administrar este
repositorio. Cada programa de aplicacin interacta con el sistema de gestin de base de
datos para crear, mantener o recuperar datos de la base de datos. El SGBD se constituye en la
interfaz entre los programas de aplicacin y la base de datos.
Figura 1.2 Organizacin de los datos mediante base de datos

1.2.1 Definicin
Un sistema de base de datos es una coleccin de datos interrelacionados, almacenados en
conjunto, sin redundancias perjudiciales o innecesarias. Su finalidad es servir a una aplicacin o
ms de la mejor manera posible. Los datos se almacenan de modo que resulten
independientes de los programas que los usan. Se emplean mtodos bien definidos para
incluir nuevos datos y para modificar o extraer los datos almacenados (Martin, 1975, p.19).
De acuerdo con Elmasri (1997, p.3), podemos decir que un sistema de base de datos est
formado por la base de datos y el sistema de gestin de la base de datos (SGBD). En la figura
1.3, podemos ver un entorno simplificado de un sistema de base de datos. Los usuarios
acceden a la base de datos almacenada a travs de programas de aplicacin o consultas
interactivas. El Software SGBD atiende y gestiona las solicitudes de acceso a la base de datos
(repositorio). Estas solicitudes pueden incluir aadir, borrar, cambiar o consultar los datos del
repositorio.
Figura 1.3 Entorno simplificado de un Sistema de Base de Datos

SISTEMA DE BASE DE DATOS

Base de
Datos

SGBD
PROGRAMAS
CONSULTAS
Usuarios
7

1.3 Base de Datos
La base de datos se constituye en el repositorio de los datos de la empresa, o de un dominio
particular, que debe permanecer en el tiempo con el propsito de brindar informacin
requerida para apoyar las actividades de la organizacin.
1.3.1 Definicin
Una base de datos consiste en alguna coleccin de datos persistentes e independientes,
usados por una organizacin determinada (Date, 1995, p.10).
En la base de datos, los datos deben estar organizados de tal manera que refleje la realidad del
dominio o de la empresa en el contexto de informacin requerida. Esto implica que adems de
los datos, se deben guardar las relaciones que existen entre los datos.
Por ejemplo, en el dominio de la gestin de matrcula en una institucin educativa, los datos
de los alumnos, asignaturas y docentes son necesarios; pero, adems es necesario guardar la
relacin entre alumno con asignatura para saber las asignaturas que un alumno est llevando.
Asimismo, la relacin entre docente y asignatura.
Una base de datos es una coleccin de datos relacionados, y una descripcin de estos datos,
diseados para cumplir con las necesidades de informacin de una organizacin (Connolly,
2008, p.17).
La base de datos tambin incluye la descripcin de los datos almacenados. Dicho de otra
forma, se almacena tambin la estructura de los datos. Por ejemplo, para alumno, se almacena
el tipo y tamao de sus atributos: cdigo, nombre, etc. Entonces, tenemos dos mbitos dentro
de la base de datos: las descripciones de los datos y los propios datos almacenados.
Para ilustrar ambos aspectos, en la figura 1.4, se muestra un ejemplo de descripcin de datos
de alumno, y en la figura 1.5, los datos almacenados de cuatro alumnos. Tanto la descripcin
como los datos se almacenan en la base de datos.
Figura 1.4 Descripcin datos Alumno

Figura 1.5 Datos almacenados de alumnos
ALUMNO
Cdigo Apellidos Nombres edad Gnero
2111199 GONZALES ROJAS JUAN 21 M
2122233 MARTNEZ QUISPE PEDRO 20 M
2199882 MUOZ RA CARMEN 20 F
2157660 ARIAS JUREZ HUGO 18 M
Table ALUMNO
(
Cdigo numeric (09) not null,
Apellidos varchar(30),
Nombres (varchar(30),
Edad numeric (02),
Gnero char(01) default (M, N),
Primary key (cdigo)
);
8

1.3.2 Aplicaciones
Toda base de datos se disea, construye y puebla con datos para un propsito especifico. Est
dirigida a un grupo de usuarios y tienen ciertas aplicaciones preconcebidas que interesan a
dicho usuarios (Elmasri, 1997, p.2). Algunas aplicaciones son las siguientes:
En la banca, para almacenar informacin de los clientes, cuentas y prstamos y transacciones
bancarias.
En Lneas areas, para reservas e informacin de planificacin. Las lneas areas fueron las
primeras en usar las bases de datos de forma distribuida geogrficamente (los terminales
situados en todo el planeta accedan al sistema de bases de datos centralizado a travs de las
lneas telefnicas y otras redes de datos).
En Universidades, para informacin de los estudiantes, matrculas de las asignaturas y cursos.
En Transacciones de tarjetas de crdito, para compras con tarjeta de crdito y generacin
mensual de extractos.
En Telecomunicaciones, para guardar un registro de las llamadas realizadas, generacin
mensual de facturas manteniendo el saldo de las tarjetas telefnicas de prepago y para
almacenar informacin sobre las redes de comunicaciones.
En Finanzas, para almacenar informacin sobre grandes empresas, ventas y compras de
documentos formales financieros, como bolsa y bonos.
En Ventas, para informacin de clientes, productos y compras.
En Produccin, para la gestin de la cadena de produccin y para el seguimiento de la
produccin de elementos en las factoras, inventarios de elementos en almacenes y pedidos de
elementos.
En Recursos humanos, para informacin sobre los empleados, salarios, impuestos y beneficios,
y para la generacin de las nminas.

1.4 Sistema de gestin de base de datos
1.4.1 Definicin
Un Sistema de Gestin de Base de Datos (SGBD) o Data Base Management System (DBMS) es
el conjunto de programas que permite a los usuarios crear y mantener una base de datos. Es
decir, el SGBD facilita el proceso de definir, construir y manipular base de datos para diversas
aplicaciones (Elmasri, 1997, p.2).
Definir una base de datos significa especificar los tipos de datos, las estructuras y las
restricciones de los datos que se almacenarn en ella.
Construir una base de datos se refiere al proceso de poblar (crear y guardar) los datos en un
medio de almacenamiento controlado por el SGBD.
Manipular la base de datos es realizar funciones como: consultar la base de datos para
obtener datos especficos, actualizar (aadir, modificar o eliminar) la base de datos para
reflejar los cambios del mbito o espacio del problema (mundo real) y generar informes a
partir de estos datos.
9

1.4.2 Usuarios
El sistema de gestin de base de datos se constituye en la interfaz entre los usuarios y la base
de datos. Los usuarios pueden ser: usuarios finales o usuarios informticos.
Los usuarios finales son aquellos que utilizan servicios de programas previamente preparados
para realizar consultas o actualizaciones a la base de datos.
Los usuarios informticos pueden ser: administrador de la base de datos, diseador y
analista/programador. El administrador de la base de datos (Data Base Administrator, DBA) es
responsable de la confidencialidad, disponibilidad, seguridad e integridad de los datos
almacenados en la base de datos; vigila el buen funcionamiento del sistema de base de datos.
El diseador identifica los datos que han de estar contenidos en la base de datos y determina
las estructuras ms apropiadas. El analista/programador desarrolla los programas para los
usuarios finales.
1.4.3 Funciones
Las funciones de un SGBD se pueden agrupar en funcin de definicin de datos, funcin de
manipulacin de datos y funcin de control.
La funcin de definicin de datos permite describir los elementos de datos, su estructura, sus
interrelaciones y sus validaciones o restricciones a tres niveles (interno, conceptual y externo)
a travs del lenguaje de definicin de datos (DDL).
La funcin de manipulacin permite: consultar (Sobre la totalidad o selectiva), aadir,
suprimir, modificar; lo cual supone definir normas de seguridad (administrador), definir un
criterio de seleccin (usuario), definir la estructura externa a recuperar (usuario) y acceder a la
estructura fsica (sistema) a travs del lenguaje de manipulacin de datos (DDL).
La funcin de control rene las interfaces de los usuarios y suministra procedimientos para el
administrador. Algunas funciones son: cambiar la capacidad de los ficheros, obtener
estadsticas de utilizacin, obtener copias de seguridad, etc.
1.5 Arquitectura de tres niveles
Se ha establecido una arquitectura de tres niveles, llamada tambin arquitectura de tres
esquemas (Elmasri, 1997, p.25). En la figura 1.6, se muestra esta arquitectura, cuyo objetivo es
lograr independencia de los datos respecto de los programas de aplicacin y del
almacenamiento fsico.
En el nivel interno, se establece la organizacin fsica de almacenamiento de los datos, es decir
la estructura de datos en disco y las rutas de acceso a los mismos considerando la velocidad en
responder los requerimientos del usuario y el uso eficiente del espacio en disco. Formalmente,
el artefacto en el que se define la organizacin interna de los datos se conoce como esquema
interno.
En el nivel conceptual, se define la estructura lgica de almacenamiento de los datos de toda
la base de datos considerando que esta estructura debe reflejar los aspectos conceptuales (se
omiten detalles de almacenamiento fsico), de los requerimientos de informacin del mbito o
espacio de problema global (mundo real). Formalmente, el artefacto en el que se define la
estructura lgica de la base de datos completa se conoce como esquema conceptual.
En el nivel externo, se define la estructura lgica de la porcin de la base de datos (vista)
requerida por un grupo particular de usuarios. Formalmente, a esta descripcin lgica parcial
de la base datos se conoce como esquema externo.

10

Figura 1.6 Arquitectura de tres niveles

Fuente: (Elmasri, 1997)

1.6 Independencia de datos
Los sistemas de base de datos deben mantener la coherencia entre los esquemas interno,
conceptual y externo, y lograr la independencia de los datos.
Los datos en la base de datos se organizan independientemente de los programas que lo van a
usar (independencia lgica) y del dispositivo de almacenamiento fsico (independencia fsica).
1.6.1 Independencia lgica de datos
Con la Independencia Lgica, los cambios en el esquema conceptual no afectan fuertemente el
esquema externo ni el programa de aplicacin. Si hay cambios en el esquema conceptual (por
ejemplo, agregar ms elementos de informacin, no afecta a las vistas o esquemas externos);
si se modifica algn elemento de informacin, solo afecta a las vistas que la incluyen.
1.6.2 Independencia fsica de datos
Con la Independencia Fsica, los cambios en el esquema interno no afectan el esquema
conceptual ni los esquemas externos. Si hay cambios en la organizacin interna de los datos,
no se afecta al esquema conceptual global ni a las vistas. Por ejemplo, si hay cambio de versin
del SGBD o migrar a otro, no hay problemas con el esquema conceptual ni con las aplicaciones.
ESQUEMA
EXTERNO 1
ESQUEMA
EXTERNO n
ESQUEMA CONCEPTUAL
ESQUEMA INTERNO
NIVEL
EXTERNO
NIVEL
CONCEPTUAL
NIVEL
INTERNO
USUARIOS FINALES
11

Leccin 2
Introduccin al Diseo de Base de
Datos
La forma en que los datos se organizan y se almacenan en la base de datos es vital para cubrir
exitosamente las necesidades de informacin de los usuarios de una empresa y hacer uso
adecuado de los recursos de almacenamiento fsico. Para lograr este objetivo, se sigue un
mtodo sistemtico conocido como diseo de base de datos.
En esta leccin, se realiza una breve introduccin al diseo de base de datos.
2.1 Qu es el diseo de base de datos?
El diseo de base de datos es el proceso mediante el cual se define la estructura lgica y fsica
de una base de datos que cubra los requerimientos de informacin de los usuarios en una
organizacin (Elmasri, 1997).
La estructura lgica es la descripcin de los datos que se almacenarn en la base de datos sin
considerar aspectos de implementacin. La estructura fsica es la descripcin de los datos
considerando el SGBD especfico y detalles de almacenamiento fsico. En la estructura lgica,
se define que se almacenar, en la estructura fsica se define como se almacenar.
2.2 Fases del diseo de base de datos
El diseo de base de datos es un proceso complejo que considera decisiones en diversos
niveles. La literatura sobre base de datos descompone el proceso de diseo de base de datos
en tres fases (figura 2.1): Diseo Conceptual, Diseo Lgico y Diseo Fsico.
Figura 2.1 Fases del Diseo de Base de datos

ESQUEMA LGICO
ESQUEMA CONCEPTUAL
REQUERIMIENTOS DE DATOS
DISEO CONCEPTUAL
DISEO LGICO
DISEO FSICO
ESQUEMA FSICO
12

2.2.1 Diseo Conceptual
En el diseo conceptual, se utiliza como punto de partida los requerimientos de informacin
planteados por los usuarios y se los expresa en un esquema conceptual.
Un esquema conceptual es una descripcin concisa de la estructura de la base de datos,
expresada en un lenguaje independiente del SGBD a utilizar para manipularla. El lenguaje que
se utiliza para describir esquemas conceptuales se conoce como modelo conceptual.
En resumen, el objetivo del diseo conceptual es describir el contenido de informacin de la
base de datos y no las estructuras de almacenamiento fsico que se necesitarn para manejar
esta informacin.
2.2.2 Diseo Lgico
En el diseo lgico, se utiliza el esquema conceptual elaborado en la fase de diseo conceptual
y se elabora el esquema lgico.
Un esquema lgico es una descripcin de la estructura de la base de datos en trminos de las
estructuras de datos que puede procesar un tipo de SGBD, por ejemplo SGBD de tipo
Relacional. El lenguaje que se utiliza para especificar esquemas lgicos se conoce como modelo
lgico.
En resumen, el diseo lgico transforma el esquema conceptual en esquema lgico; depende
del tipo de SGBD que se vaya a utilizar, no depende del producto concreto.
2.2.3 Diseo Fsico
En el diseo fsico, se utiliza el esquema lgico elaborado en la fase de diseo lgico, y se
elabora el esquema fsico correspondiente.
Un esquema fsico es una descripcin detallada de la implementacin de una base de datos en
trminos de estructura de almacenamiento internos y los mtodos utilizados para tener
acceso eficiente a los datos.
En resumen, el diseo fsico depende del SGBD concreto y el esquema fsico se expresa
mediante su lenguaje de definicin de datos.
2.3 Un ejemplo sencillo de diseo de base de datos
Consideremos una porcin pequea de requerimientos de informacin del dominio de gestin
acadmica de una Universidad. Se necesita mantener informacin de las Facultades y de los
alumnos que pertenecen a ellas.
En la fase de diseo conceptual, se elabora el esquema conceptual. En este ejemplo, se usa la
notacin del modelo entidad relacin de Chen (1976). En la figura 2.2, se aprecia el modelo
entidad relacin para reflejar los requerimientos sealados.
Figura 2.2 Ejemplo de MER

(1,n)
(1,1)
FACULTAD
CODIGO
NOMBRE
ALUMNO TIENE
CODIGO
APELLIDOS
NOMBRES
13

En la fase de diseo lgico, se transforma el esquema conceptual a esquema lgico. En este
ejemplo, usaremos el esquema relacional. A continuacin se aprecia el esquema lgico
relacional:

En la fase de diseo fsico se define las tablas usando la sintaxis de SQL, como se aprecia a
continuacin:

2.4 Modelos de Datos
Durante el proceso de diseo de base de datos, se utilizan modelos de datos, en diversos
niveles, para representar los requerimientos de los usuarios.
2.4.1 Definicin
De acuerdo con De Miguel (1999), un modelo de datos describe, en base a conceptos y reglas,
los datos de una porcin del mundo real.
En otras palabras, un modelo de datos es un conjunto de conceptos y reglas que permiten
describir, a distintos niveles de abstraccin, la estructura de una base de datos, a la cual
denominamos esquema.
2.4.2 Tipos
De acuerdo con las fases del proceso de diseo, los modelos de datos se pueden clasificar en:
conceptuales, lgicos y fsicos.
Los modelos de datos conceptuales se enfocan en describir el mundo real con independencia
del tipo de SGBD y de detalles de implementacin en la mquina.
FACULTAD (CDIGO, NOMBRE);
CLAVE PRIMARIA= CDIGO
ALUMNO (CDIGO, APELLIDOS, NOMBRES, CDIGO, FACULTAD);
CLAVE PRIMARIA=CDIGO
CLAVE FORNEA = CDIGO, FACULTAD

CREATE TABLE FACULTAD
( CODIGO CHAR (02) NOT NULL,
NOMBRE VARCHAR (40),
PRIMARY KEY (CODIGO)
);
CREATE TABLE ALUMNO
( CODIGO NUMERIC (09) NOT NULL,
NOMBRES VARCHAR (40),
APELLIDOS VARCHAR (60),
CODIGO_FACULTAD CHAR (02),
PRIMARY KEY (CODIGO),
FOREING KEY (CODIGO_FACULTAD) REFERENCES
FACULTAD (CDIGO)
);

14

Los modelos de datos lgicos se orientan a representar los datos segn la implementacin del
tipo SGBD especfico, pero sin detalles de implementacin de la mquina.
Los modelos de datos fsicos se orientan a representar los datos considerando detalles de
implementacin en la mquina.
Otra forma de clasificar a los modelos de datos es segn los niveles de abstraccin de la
arquitectura de tres niveles: Externo, Global e Interno.
El modelo de datos externo representa el punto de vista de cada usuario en particular.
El modelo de datos global representa el punto de vista del conjunto de usuarios de la
empresa.
El modelo de datos interno representa el punto de vista de la maquina.

2.4.3 Notaciones
Existen diversas notaciones para el modelo de datos. La eleccin de una depende de las
condiciones en que se realizar el proceso de diseo de la base de datos y el ambiente de la
organizacin. Se puede mencionar:
Notacin CHEN (1976), para modelos de datos conceptuales que da especial nfasis a las
relaciones entre entidades representndolas con un rombo (figura 2.3).

Figura 2.3 Modelo conceptual Notacin CHEN

Notacin IE (Information Engineering) desarrollada inicialmente por Clive Finkelstein (1992)
quien, luego, la refin con el apoyo de James Martin. Aunque es clara e intuitiva, sirve solo
para modelos de alto nivel de abstraccin (modelos conceptuales y lgicos), pues no permite
modelar los atributos de las entidades (Figura 2.4).

Figura 2.4 Modelo conceptual Notacin IE

Notacin UML (Unified Modeling Language): si bien es un lenguaje de modelado objetual, se
puede extender a travs de perfiles para soportar otro tipo de modelos, como el modelo de
datos (Booch, 1999) (figura 2.5).

(1,n)
(1,1)
FACULTAD
CODIGO
NOMBRE
ALUMNO TIENE
CODIGO
APELLIDOS
NOMBRES
TIENE
FACULTAD
CODIGO
NOMBRE
ALUMNO
CODIGO
NOMBRES
APELLIDOS
15

Figura 2.5 Modelo conceptual Notacin UML

2.5 Abstracciones de datos
El modelado de datos se realiza en base a abstracciones. La abstraccin consiste en seleccionar
caractersticas relevantes de un conjunto de objetos o elementos del dominio del problema y
excluir otras no pertinentes. A travs de ellas se establecen vnculos entre los elementos del
modelo.
Se puede establecer los siguientes tipos de abstracciones: Clasificacin, Asociacin,
Generalizacin y Agregacin.
2.5.1 Abstraccin de Clasificacin
Mediante la clasificacin se abstrae las caractersticas comunes a un conjunto de elementos u
objetos del mundo real para crear una categora (clase o tipo) a la cual pertenecen dichos
elementos. Se corresponde con el concepto de pertenencia a un conjunto. Se utiliza para
definir un concepto como una clase de objetos de la realidad caracterizados por propiedades
comunes.
Por ejemplo, considere los siguientes elementos u objetos del dominio de Gestin Acadmica
de una Universidad: Anlisis de Sistemas, Base de datos I, Matemtica I, Fsica I y
Fundamentos de informtica; todas ellas pertenecen a una clase o tipo que podemos llamar:
ASIGNATURA (Figura 2.6).
Figura 2.6 Proceso de clasificacin

Los mismos objetos admiten clasificaciones distintas. Por ejemplo, podemos clasificar las
asignaturas de varias maneras:
obligatorias / electivas,
de primer ciclo, segundo ciclo, etc.,
tericas / prcticas, etc.

2.5.2 Abstraccin de Agregacin
Mediante la agregacin se construye una nueva clase o tipo o categora de objetos a partir de
un conjunto de otras clases denominadas componentes o partes. Define una nueva clase de
CLASIFICACIN
Anlisis de Sistemas
Base de datos I Matemtica I
Fsica I
Fundamentos de informatica
ASIGNATURA
16

objetos a partir de un conjunto de clases (otras, no necesariamente distintas) que representan
sus partes componentes.
Por ejemplo: CPU, Teclado, Mouse, Monitor son partes de Computadora (figura 2.7). En otras
palabras, una Computadora est compuesta por Mouse, CPU, Teclado y Monitor.
Figura 2.7 Proceso de agregacin

2.5.3 Abstraccin de Generalizacin
Mediantes la generalizacin se aabstrae las caractersticas comunes a varias clases (subclases)
para construir una clase ms general (superclase). Define una relacin de subconjunto entre
elementos de dos o ms clases.
Por ejemplo, Secretaria, Tcnico, Ingeniero son tipos de Empleados (figura 2.8).

Figura 2.8 Proceso de Generalizacin

2.5.4 Abstraccin de Asociacin
Mediante la abstraccin de asociacin se vincula dos o ms clases crendose un elemento de
tipo distinto (Vnculo). Puede parecerse a la agregacin, pero posee rasgos distintivos.
Por ejemplo PROFESOR imparte ASIGNATURA figura 2.9).

Figura 2.9 Asociacin

Una Clase ES UN TIPO DE otra clase
Una Clase ES PARTE DE otra clase
AGREGACIN CPU
TECLADO
MOUSE
MONITOR
COMPUTADORA
GENERALIZACIN
SECRETARIA TECNICO
INGENIERO
EMPLEADO
ASOCIACIN: IMPARTE
ASIGNATURA
PROFESOR
17

Resumen
Introduccin a los sistemas de base de datos
Un Sistema de base de datos est formado por: la base de datos y el sistema de gestin de base de
datos. Una base de datos consiste en alguna coleccin de datos persistentes e independientes,
usados por una organizacin determinada. Un sistema de gestin de base de datos (SGBD) o Data
Base Management System (DBMS) es el conjunto de programas que permite a los usuarios crear y
mantener una base de datos.
Los usuarios pueden ser usuarios finales y usuarios informticos. Los usuarios finales usan los
programas preparados previamente para consultas o actualizar la base de datos. Los usuarios
informticos pueden ser administrador de la base de datos, diseador de base de datos y anlisis
programador de aplicaciones.
Las funciones de un SGBD son: definicin de datos, manipulacin de datos y control. La funcin de
definicin permite describir los elementos de datos. La funcin de manipulacin permite consultar y
actualizar la base de datos. La funcin de control est dirigida a la administracin de la base de
datos.
La arquitectura de tres niveles considera: nivel interno, nivel conceptual y nivel externo. En el nivel
interno se establece la organizacin fsica de almacenamiento de los datos, conocido como
esquema interno. En el nivel conceptual se define la estructura lgica de almacenamiento de los
datos de toda la base de datos, conocido como esquema conceptual. En el nivel externo se define la
estructura lgica de la porcin de la base de datos (vista) requerida por un gripo particular de
usuarios, conocido como esquema externo.
La Independencia Lgica, permite que los cambios en el esquema conceptual no afectan
fuertemente en el esquema externo ni el programa de aplicacin.
La Independencia Fsica, permite que los cambios en el esquema interno no afectan el esquema
conceptual ni a los esquemas externos.
Introduccin al diseo de base de datos
El diseo de base de datos es el proceso mediante el cual se define la estructura lgica y fsica de
una base de datos que cubra los requerimientos de informacin de los usuarios. La estructura lgica
es la descripcin de los datos sin considerar aspectos de implementacin. La estructura fsica es la
descripcin de los datos considerando el SGBD especfico y detalles de almacenamiento fsico.
El proceso de de diseo tiene tres fases: Diseo conceptual, Diseo Lgico y Diseo Fsico. En el
diseo conceptual, los requerimientos se expresan en un esquema conceptual, descripcin concisa
de la estructura de la base de datos, independiente del SGBD (modelo conceptual). En el diseo
lgico, el esquema conceptual se transforma en esquema lgico, descripcin de la estructura de la
base de datos en trminos de las estructuras de datos que puede procesar un tipo de SGBD (modelo
lgico). En el diseo fsico, el esquema lgico se transforma en esquema fsico, descripcin
detallada de la implementacin de una base de datos en trminos de estructura d almacenamiento
internos y los mtodos utilizados para tener acceso a los datos.
Un modelo de datos es un conjunto de conceptos y reglas para describir la estructura de una base
de datos, en distintos niveles de abstraccin. Se clasifican en: Conceptuales, Lgicos y Fsicos. El
Conceptual se enfoca en describir el mundo real con independencia del tipo de SGBD y de detalles
de implementacin en la mquina. El lgico se orienta a representar los datos segn la
implementacin del tipo SGBD especfico, pero sin detalles de implementacin de la mquina. El
fsico se orientan a representar los datos considerando detalles de implementacin en la mquina.
La abstraccin de datos consiste en seleccionar caractersticas relevantes en un dominio y excluir
otras no pertinentes. Existen cuatro tipos de abstraccin: Clasificacin, Agregacin, Generalizacin,
y Asociacin. Mediante la clasificacin un conjunto de objetos con las mismas caractersticas se
abstraen en una clase de objetos. La agregacin define una nueva clase de objetos a partir de otras
que representan sus partes o componentes. La generalizacin define una nueva clase de objetos a
partir las caractersticas comunas de otras que representan sus subclases. Mediante la asociacin se
establece un vnculo entre dos clases de objetos.
18

Lectura
Oficina Estatal de Licencias y Registro de Vehculo (*)
Ahora consideremos una aplicacin aun mayor de las tecnologas de base de datos:
una oficina estatal de licencias y registro de vehculo. Tiene 52 centros de pruebas de
manejo, expedicin de licencias para conductores, renovacin de licencias de manejo, y
tambin 37 oficinas que expiden registros de vehculos.
El personal tiene acceso a una base de datos para realizar su trabajo. Antes que a las
personas se les otorgue o renueve su licencia de conducir, hay que verificar su registro
en la base de datos para buscar posibles infracciones de trnsito, accidentes o arrestos.
Estos ltimos datos se utiliza para determinar si la licencia debe o no ser renovada, o si
se debe otorgar con ciertas limitaciones. De igual manera, el personal del
departamento de registro de automviles tiene acceso a la base de datos para
determinar si un auto ha sido registrado antes y, si es as, quien lo registro, o si existe
algn asunto importante que impide expedir el registro.
Esta base de datos tiene ciento de usuarios, incluyendo no solo al personal de las
licencias y registros, sino al del departamento tal de contribuciones y del
departamento jurdico. No es de extraar que la base de datos sea grande y compleja,
con ms de 40 diferentes tablas de datos, muchas de las cuales contienen cientos de
miles de filas.
La base de datos de las grandes organizaciones, como la oficina de licencias y registros,
fueron las primeras aplicaciones de este tipo de tecnologa. Estos sistemas han existido
durante 20 o 30 aos y se han modificado para satisfacer los cambios que ocurrieron
durante ese periodo. Otros ejemplos de bases de datos organizacionales se relacionan
con el procesamiento de cuentas en bancos e instituciones financieras, sistemas de
produccin y de suministro de material en fbricas grandes, procesamiento de registros
mdicos en hospitales, y en compaas de seguros y agencias gubernamentales.
Actualmente muchas organizaciones estn adaptando sus aplicaciones de bases de
datos para permitir a los clientes tener acceso, e incluso cambiar sus datos, por medio
de internet. Si usted llegar a trabajar en una gran organizacin importante,
probablemente le podran asignar ese proyecto.
(*) Fuente: (Kroenke, 2003, p.8)

19

Actividades
1. Realice una bsqueda en internet, ubique un sistema de gestin de base de datos
LIBRE y descrguelo.
2. Descargue de internet un software libre para modelar base de datos.
Autoevaluacin
1. Con respecto al concepto de Sistema de Base de Datos, entre los parntesis de la siguiente lista,
marque V=Verdadero o F=Falso, segn corresponda:
a. ( ) Est compuesto por base de datos y SGBD.
b. ( ) Est formado por base de datos y DBA
c. ( ) Solo es un repositorio donde se almacenan los datos
d. ( ) Es el conjunto de usuarios y programas para hacer consultas
e. ( ) Es el software que atiende a las solicitudes de acceso a la base de datos.
2. Con respecto al concepto de Base de Datos, entre los parntesis de la siguiente lista, marque
V=Verdadero o F=Falso, segn corresponda:
a. ( ) Esta compuesto por programas y datos
b. ( ) Es una coleccin de datos temporales usados por una organizacin
c. ( ) Es un conjunto de datos persistentes requeridos por una organizacin
d. ( ) Es un almacn que guarda datos y las relaciones entre los datos.
e. ( ) Guarda datos, relaciones y la descripcin de los datos y relaciones.
3. Respecto al concepto de SGBD, marque V=Verdadero o F=Falso segn corresponda:
a. ( ) Conjunto de usuarios
b. ( ) Conjunto de programas
c. ( ) Permite crear la base de datos
d. ( ) Permite compilar los programas para los usuarios finales
e. ( ) Es el conjunto de datos almacenados sin redundancias perjudicial
4. Con respecto a la arquitectura de tres niveles, entre los parntesis de la siguiente lista coloque
I=Nivel Interno, C=Nivel conceptual o E=Nivel Externo, segn corresponda:
a. ( ) Estructura lgica de almacenamiento de toda la base de datos
b. ( ) Su descripcin se llama esquema externo
c. ( ) Estructura lgica de una porcin de la base de datos
d. ( ) Considera detalle de implementacin
e. ( ) Considera el uso eficiente de espacio en disco
5. Establezca la relacin de concepto y su descripcin, colocando la letra de la descripcin en la celda a
la derecha del Concepto:
Concepto Descripcin del concepto.
1. Independencia
Lgica
a) Su resultado es el esquema conceptual obtenido a partir de los
requerimientos de informacin de los usuarios
2. Independencia
Fsica
b) Descripcin de la estructura de la base de datos considerando el
tipo de SGBD
3. Diseo
Conceptual
c) Si hay cambio de versin en el SGBD no afecta a esquema
conceptual ni a las aplicaciones
4. Diseo Lgico
d) Depende del SGBD para elabora el esquema fsico
5. Diseo Fsico e) Descripcin de los datos considerando detalles de
implementacin
6. Esquema
Conceptual
f) Los cambios en el esquema conceptual no afecta a los programas
de aplicacin
20

7. Esquema
Lgico

g) Se transforma el esquema conceptual en esquema lgico
8. Esquema
Fsico
h) Descripcin concisa de la estructura de la base de datos
independiente del SGBD
6. Con respecto a los tipos de abstraccin, entre los parntesis de la siguiente lista coloque
C=Abstraccin de Clasificacin, A=Abstraccin de Agregacin, G=Abstraccin de Generalizacin o
V=Abstraccin de Asociacin, segn corresponda:
a. ( ) Csar Luza, Pedro Carpio y Pedro Alvarado son Personas
b. ( ) Docente, Alumno y Empleado son Personas
c. ( ) Pas est formado por Departamentos
d. ( ) Profesor asignado a Facultad
e. ( ) Proveedor y Cliente son tipos de Agente Comercial
Respuestas de Control
1. a = V, b = F, c = F, d = F, e = F
2. a = F, b = F, c = V, d = V, e = V
3. a = F, b = V, c = V, d = F, e = V
4. a = C, b = E, c = E, d = I, e = I
5. 1 = f, 2 = c, 3 = a, 4 = g, 5 = d, 6 = h, 7 = b, 8 = e
6. a = C, b = G, c = A, d = V, e = G
Exploracin On-Line
Microsoft SQL Server 2008
http://www.microsoft.com/latam/sqlserver/
Oracle :
http://www.oracle.com/index.html
MySQL
http://www.mysql.com/
Referencias Bibliogrficas
1. Booch, G., Rumbaugh, J. y Jacobson, I. (1999) El lenguaje unificado de modelado. Madrid. Addison
Wesley Iberoamericana.
2. Chen, Peter (1976), The entety-relationship model:Towards a unified view of data. ACM Trans.
Database systems 1 (1) 9-36
3. Connolly, Thomas y Begg, Carolyn. (2008) Database Solutions. 5ta. Ed. Massachusetts. Addison
Wesley.
4. Date, C. (1995) An introduction to data base systems. 5ta. Ed. Massachusetts. Addison Wesley.
5. De Miguel A. y Piattini M., (1999) Fundamentos y Modelos de Base de datos. 2da. Ed. Madrid. Alfa y
Omega.
6. Elmasri, Ramez y Shamkant Navathe (1997) Sistemas de Bases de Datos. Conceptos fundamentales.
Segunda Edicin, Madrid, Addison-Wesley Iberoamericana.
7. Finkelstein, C. (1992) Strategic systems development. Sydney: Addison-Wesley.
8. Kroenke, David M. (2003) Procesamiento de base de datos. Fundamentos, diseo e implementacin.
Mxico. Pearson Educacin.
9. Martin, James. (1975) Computer Data Base Organization. New Jersey. Prentice Hall.
21

UNIDAD 2
EL MODELO ENTIDAD-RELACIN
(MER)

Qu es el MER? Cules son sus elementos? Cmo se representan?
Cul es la diferencia entre entidad y tipo de entidad?
Qu es un atributo Qu significa atributo Identificado?
Cul es la diferencia entre Relacin y Tipo de Relacin?
Qu es Razn de Cardinalidad o Tipo de correspondencia? Qu tipos hay?
Qu es Razn de participacin o Cardinalidad mnima y mxima?
Qu son los atributos de una relacin? Cmo se representan?
Qu son las entidades dbiles? Cmo se representan?
Qu es una generalizacin? Qu es una especializacin? Cmo se representan?

22

Leccin 3
Conceptos asociados al MER
3.1 Qu es el MER?
El MER (Modelo Entidad Relacin) es un modelo de datos conceptual propuesto por Peter
Chen (1976). Se han realizado extensiones y aportaciones por otros autores.
El MER describe, de manera concisa, los requisitos de informacin de los usuarios como un
conjunto de entidades y sus atributos, las relaciones entre las entidades y las restricciones
que ellas deben cumplir. No se consideran detalles de implementacin, permitiendo una
comunicacin ms adecuada entre desarrolladores y usuarios no tcnicos.
Los elementos bsicos del MER incluyen Tipo de Entidad, Tipo de Relacin y Atributos. Las
extensiones consideran representaciones para entidad dbil, generalizacin, entre otros.
3.2 Entidad y Atributo
3.2.1 Entidad
El elemento bsico en el MER es la entidad. Una Entidad es una persona, lugar, cosa,
concepto o suceso, real o abstracto, de inters para la empresa (ANSI
2
, 1977).
Una entidad es una cosa u objeto en el mundo real que es distinguible de otros objetos
(Korth, 2002, p.5).
Por ejemplo, una persona, un alumno, el libro Anlisis de sistemas, un empleado, una
asignatura, la asignatura Base de datos 1, un viaje, etc. En la figura 3.1, se representa una
entidad persona.
Figura 3.1 Una Persona

3.2.2 Atributo
Cada entidad tiene propiedades especficas llamadas atributos que la describen. Un atributo es
una propiedad o caractersticas de una entidad. Una entidad particular es descrita por los
valores de sus atributos dentro del tipo de entidad.
Por ejemplo, una entidad PERSONA puede describirse por su DNI, Nombre, Apellidos, Gnero,
Estatura, Peso, Fecha de nacimiento. Una persona particular tendr un valor para cada uno de
sus atributos. As dos entidades Persona con sus valores para cada atributo son:
06111988, CSAR, LUZA MONTERO, M, 1,70 m., 76 kg, 06-02-1959.
05879997, PEDRO, CARPIO FARFN, M, 1,76 m., 76 kg, 03-03-1959.
Otro ejemplo: Considere el Tipo de entidad ALUMNO con los siguientes atributos: Cdigo.
Nombre, Edad, Ciclo; a continuacin se muestra una porcin del conjunto de alumnos:

2
ANSI = American National Standards Institute, <http://www.ansi.org/> Instituto de estndares
Americano

23

(21-223333-23, Sofa, 18 aos, 2)
(21-333333-44, Josefa, 19 aos, 5)
(21.555555-55, Gabriela, 20 aos, 2)
Cada una de las entidades pertenecientes a este conjunto se diferencia de las dems por el
valor de sus atributos. Ntese que dos o ms entidades diferentes pueden tener los mismos
valores para algunos de sus atributos, pero nunca para todos.
3.3 Tipo de Entidad, Atributo Identificador y Conjunto de valores
Un Tipo de entidad define un conjunto de entidades que poseen los mismos atributos (Elmasri,
1997). Por ejemplo, el conjunto de entidades personas forman el tipo de entidad PERSONA
(Figura 3.2).
Figura 3.2 Conjunto de personas, tipo de entidad PERSONA

Otros ejemplos de tipo de entidad son:
LIBRO,
EMPLEADO,
ASIGNATURA,
VIAJE.
Desde el punto de vista de la abstraccin de clasificacin, el tipo de entidad describe un
conjunto de entidades como resultado de la clasificacin, cada entidad es un elemento del tipo
de entidad. En la figura 3.3, se observa cinco entidades que se clasifican en el tipo de entidad
Asignatura.
Figura 3.3 Entidades y Tipo de entidad por abstraccin de clasificacin

Un tipo de entidad est formado por un conjunto de entidades, a los elementos de este
conjunto tambin se le conoce como instancias de tipo de entidad. Por ejemplo, anlisis de
sistemas es una instancia del tipo de entidad ASIGNATURA.
3.3.1 Notacin de Tipo de Entidad
La notacin Chen (1976) para un tipo de entidad es un rectngulo con el nombre del tipo de
entidad en el interior (figura 3.4):
Figura 3.4 Notacin de Tipo de entidad (Chen, 1976)

PERSONA
CLASIFICACIN
Anlisis de Sistemas
Base de datos I Matemtica I
Fsica I
Fundamentos de informtica
ASIGNATURA
24

En la figura 3.5, se aprecia la notacin IE (Finkelstein, 1992) para un tipo de entidad.

Figura 3.5 Notacin de Tipo de entidad segn IE

En la figura 3.6, se observa algunos ejemplos de tipos de entidad para un sistema acadmico:
Figura 3.6 Ejemplos de Tipo de entidad

3.3.2 Atributo Identificador de un tipo de entidad
Los tipos de entidades casi siempre tienen un atributo cuyo valor es distinto para cada entidad
individual, denominado atributo identificador.
Un atributo identificador es aquel atributo que permite distinguir a una entidad de otra
distinta.
Por ejemplo, el atributo identificador que distingue a un alumno de otro es su cdigo, el DNI es
el atributo identificador del tipo de entidad Persona.
3.3.3 Notacin de atributo de un tipo de entidad
La notacin Chen (1976) para atributos es un crculo con el nombre especfico. El atributo
identificador se denota con el circulo sombreado (Figura 3.7).
Figura 3.7 Notacin de atributos segn Chen

En la figura 3.8, se aprecia la notacin IE (Finkelstein, 1992) para atributos.
Figura 3.8 Notacin de atributo segn IE

PERSONA
ALUMNO PROFESOR
ASIGNATURA
MATRICULA
AULA
HORARIO
ALUMNO
Codigo
Nombre
Edad
Cicl o
25

3.4 Relacin y Tipo de Relacin
3.4.1 Relacin
Una Relacin, tambin llamada interrelacin, es una asociacin, vnculo o correspondencia
entre entidades relacionadas de alguna manera en un contexto determinado.
Ejemplos:
El profesor Jos Cruz ensea la asignatura Fundamentos de informtica
El profesor Cesar Luza ensea la asignatura de Base de datos I
El cliente Juan Prez realiza el pedido 34677
El cliente Jos Quiroz realiza el pedido 17450
El producto Tornillo se almacena en el almacn Central
3.4.2 Tipo de Relacin
Un Tipo de Relacin es la abstraccin del conjunto de relaciones existentes entre dos o ms
tipos de entidad.
Ejemplos: PROFESOR ensea ASIGNATURA.
CLIENTE realiza PEDIDO
PRODUCTO se almacena en ALMACN
La notacin Chen (1976) para un tipo de relacin es un rombo que une a los tipos de entidades
asociadas (figura 3.9).
Figura 3.9 Notacin de tipo de relacin segn Chen (1976)

La figura 3.10 muestra la notacin IE para un tipo de relacin.
Figura 3.10 Notacin de tipo de relacin segn IE

En la figura 3.11, se observa algunos ejemplos de tipo de relacin para un sistema acadmico.
Figura 3.11 ejemplos de tipo de relacin

Entre dos tipos de entidades puede establecer ms de un tipo de relacin. En la figura 3.12, se
observa dos relaciones entre persona y edificio. El tipo de relacin Persona USA Edificio
significa que una persona es usuaria del edificio. El tipo de relacin Persona POSEE Edificio
ENSEA
PROFESOR
ASIGNATURA
26

Original
Continuacin
significa que la persona es propietaria del edificio. Ambas relaciones se modelan porque es de
inters la informacin de quien es el propietario y quines son los usuarios.
Figura 3.12 Dos tipos de relacin entre dos tipos de entidad

3.4.3 Grado de un Tipo de Relacin
El grado de un tipo de relacin es el nmero de tipos de entidad que participan en el tipo de
relacin. En la figura 3.13, se aprecia un ejemplo de tipo de relacin binaria o de grado 2, es el
ms frecuente, se interpreta como: actor acta en pelcula. En la figura 3.14, se muestra un
ejemplo de tipo relacin de grado 3 o ternaria, se interpreta como: El cliente alquila pelcula un
local del videoclub. En la figura 3.15, se presenta un ejemplo de tipo de relacin de grado 1 o
unaria, se interpreta como: la pelcula es continuacin de otra pelcula.

Figura 3.13 Tipo de relacin binaria (Grado 2)

Figura 3.14 Tipo de relacin ternaria (Grado 3)

Figura 3.15 Tipo de relacin unaria (Grado 1)

3.4.4 Nombre de Rol
Todo tipo de entidad que participa en un tipo de relacin juega un papel especfico en la
relacin. Los nombres de rol ayudan a explicar el significado de la relacin, por eso su uso es
casi obligatorio en los tipos de relacin unarias, para evitar la ambigedad. En figura 3.16, el
tipo de relacin Continuacin de establece el vinculo entre dos pelculas, una de ellas juega
el rol de original, y la otra juega el rol de continuacin.
Figura 3.16 nombre de rol

27

3.4.5 Restricciones Estructurales
3

Las restricciones estructurales son reglas que limitan las posibles combinaciones de entidades
que pueden participar en las relaciones. Son extradas de la situacin real que se modela. Por
ejemplo, Una asignatura puede ser dictada por uno o ms profesores y Un profesor puede
dictar ms de una asignatura, son reglas que deben cumplir los datos que se almacenaran en
la base de datos de un sistema acadmico.
Las restricciones bsicas en el MER se conocen como Razn de cardinalidad o Tipo de
Correspondencia.
La Razn de cardinalidad o Tipo de correspondencia es el nmero mximo de instancias o
entidades de un tipo de entidad que puede estar relacionado con una instancia de otro tipo de
entidad. Puede ser de tres tipos de correspondencia:
1 a 1, Uno a Uno.
1 a N, Uno a Mucho y
M a N, Muchos a Muchos
El Tipo de correspondencia 1 a 1 (Uno a Uno) significa que una instancia de un tipo de entidad
est vinculada a lo ms con una instancia del otro tipo de entidad asociada y viceversa. Por
ejemplo el tipo de relacin DECANO dirige FACULTAD es de Uno a Uno, porque un Decano
dirige una sola Facultad, adems una Facultad es dirigida por solo un Decano (Figura 3.17).
Figura 3.17 Ejemplo Tipo de Relacin Uno a Uno
Notacin Chen

Notacin IE

El Tipo de correspondencia 1 a N (Uno a Muchos) significa que una instancia de un tipo de
entidad est vinculada a lo ms con varias instancias del otro tipo de entidad asociada. Por
ejemplo el tipo de relacin FACULTAD tiene ALUMNO es de Uno a Muchos, porque una
Facultad tiene muchos Alumnos, adems un Alumno pertenece solo a una Facultad (Figura
3.18).
Figura 3.18 Ejemplo Tipo de Relacin Uno a Muchos

3
En adelante, se usa notacin Chen y su equivalente en notacin IE.
DIRI GE
DECANO
FACULTAD
TIENE
FACULTAD
ALUMNO
28

El Tipo de correspondencia M a N (Muchos a Muchos) significa que una instancia de un tipo de
entidad est vinculada a lo ms con varias instancias del otro tipo de entidad asociada, y
viceversa. Por ejemplo el tipo de relacin ALUMNO lleva ASIGNATURA es de Muchos a
Muchos, porque un Alumno lleva varias Asignaturas, adems una Asignatura es llevada por
varios Alumnos (Figura 3.19).
Figura 3.19 Ejemplo Tipo de Relacin Muchos a Muchos

3.4.6 Atributos de una relacin
Un tipo de relacin puede tener atributos, conceptualmente pertenecen al tipo de relacin.
Un atributo de un tipo relacin M:N es propio del tipo de relacin. En cambio, un atributo de
un tipo relacin 1:1 o 1:N se puede llevar a uno de los tipos de entidad participantes. En la
figura 3.22 se muestra notacin Chen para atributos de una relacin.

Figura 3.22 Atributos de una relacin

LLEVA
ALUMNO
ASIGNATURA
R
R
ACTOR
PELICULA
ACTUA
Papel
Salari o
29

Leccin 4
Extendiendo el MER
4.1 Razn de Participacin
En el modelo MER bsico de Chen, otros autores han agregado ms detalles para representar
restricciones estructurales que se conocen como Razn de Participacin o Cardinalidad
Mnima y Mxima.
La Razn de Participacin o cardinalidad mnima y mxima de una relacin, son los nmeros
mnimo y mximo de instancias de tipo de relacin en las que puede intervenir una instancia
del tipo de entidad participante. Se denota mediante (min., mx.) en la lnea que une el tipo de
entidad con el tipo de relacin.
Por ejemplo, consideremos la relacin Facultad tiene Alumno, una Facultad como mnimo
tiene un alumno y como mximo muchos alumnos; adems, un alumno como mnimo
pertenece a una Facultad y como mximo a una sola (figura 3.20).

Figura 3.20 Ejemplo Razn de participacin

Ahora, consideremos la relacin Alumno lleva Asignatura, un alumno como mnimo lleva cero
asignaturas (puede no matricularse en un semestre), como mximo puede llevar muchas
asignaturas; adems, una asignatura como mnimo tiene cero alumnos (cuando la asignatura
se cancela o no se programa) y como mximo muchos alumnos (figura 3.21).

Figura 3.21 Otros ejemplo Razn de participacin

TIENE
FACULTAD
ALUMNO
LLEVA
ALUMNO
ASIGNATURA
30

4.2 Entidades dbiles
En ocasiones, una entidad no tiene por s misma datos suficientes como para poder
identificarla. Por ejemplo, las aulas de una Facultad se pueden identificar por nmero de aula,
pero los nmeros podran repetirse en otra Facultad. En este caso diremos que el tipo de
entidad AULA es dbil respecto de FACULTAD (entidad fuerte).
4.2.1 Definicin
Una entidad dbil es aquella que no tiene atributo identificador propio. Su existencia depende
de otra entidad (fuerte) que la posee y la identifica inequvocamente.
Ejemplo:
Provincia es entidad dbil de departamento, para identificar una provincia se
necesitar el nombre de la provincia y del departamento.
En el contexto de la planilla de una empresa, FAMILIAR depende de EMPLEADO,
Familiar es entidad dbil porque depende de Empleado.
4.2.2 Notacin
Una entidad dbil se representa con un rectngulo de doble lnea, con el nombre al interior. En
la figura 4.1 se muestra la entidad dbil familiar que depende de Empleado.

Figura 4.1 Notacin de entidad dbil

4.3 Generalizacin o Especializacin
4.3.1 Definicin
La generalizacin es caso especial de relacin entre un tipo de entidad y varios otros tipos de
entidad. La jerarqua o relacin que se establece entre uno y otros corresponde a la nocin de
es_un o de es_un_tipo_de.
Estas jerarquas pueden formarse por especializacin o bien por generalizacin.
Por ejemplo:
Un ANIMAL es un FELINO, es una jerarqua obtenida por Especializacin, de arriba
hacia abajo.
Un REPTIL es un tipo de ANIMAL; Un INSECTO es un tipo de ANIMAL son jerarquas
obtenidas por Generalizacin.
El proceso de generalizacin se caracteriza por el nfasis en las similitudes de los subtipos y
cada instancia del supertipo es tambin una instancia de algunos de los subtipos.
(1,1) (0,n)
EMPLEADO FAMILIAR
E
Tiene
dependientes
TIENE_DEPEDIENTES
EMPLEADO
FAMILIAR
31

El proceso de especializacin se caracteriza por las diferencias de los subtipos y alguna
instancia del supertipo puede no ser instancia de ningn subtipo.
4.3.2 Notacin
4

La generalizacin o especializacin se representa con un triangulo, en la figura 4.2, representa
que Secretario es un tipo de Empleado, de igual forma Gerente y Comercial son tipos de
Empleados.
Figura 4.2 Notacin de generalizacin

4.3.3 Subtipo y Supertipo
En una relacin de generalizacin, el subtipo es un tipo de entidad que agrupa a las instancias
dentro de otro tipo de entidad, llamado supertipo, que debe representarse explcitamente
debido a su importancia para el diseo o aplicacin
Ejemplos:
Los Subtipos de VEHCULO son: CAMIN, TURISMO, AUTOBS y CICLOMOTOR.
Los Subtipos del tipo de entidad EMPLEADO son: SECRETARIO, GERENTE COMERCIAL
El supertipo es el tipo de entidad que se especializa en otros o se generaliza de otros. En los
ejemplos anteriores VEHCULO y EMPLEADO son supertipo.
La extensin o conjunto de entidades de un subtipo es un subconjunto de la extensin del
supertipo. Es decir, una instancia o entidad de un subtipo tambin es instancia del supertipo y
es la misma instancia, pero con un papel especfico distinto. Una instancia no puede existir
slo por ser miembro de un subtipo: tambin debe ser miembro del supertipo. Una instancia
del supertipo puede no ser miembro de ningn subtipo. En la figura 4.3 se muestra tres
subtipos de vehculo, pero pueden existir otros tipos que no estn representados, por ejemplo
AUTO.

4
La notacin Chen que utilizamos, en esta leccin, se basa en De Miguel (1999).
EMPLEADO
SECRETARIO
GERENTE COMERCIAL
32

Figura 4.3 Supertipo Vehculo y subtipos Camin, Turismo y Ciclomotor

4.3.4 Herencia de tipo
En la generalizacin, un subtipo puede tener atributos propios (especficos) y participar en
relaciones por separado. Un subtipo hereda todos los atributos del supertipo, y toda relacin
en la que participa el supertipo.
Un subtipo, con sus atributos y relaciones especficos, ms los atributos y relaciones que
hereda del supertipo, es un tipo de entidad por derecho propio.
En la figura 4.4, se muestra un ejemplo de subtipos con atributos propios y relaciones
independientes.
Figura 4.4 Subtipos con atributos propios y relaciones independientes

4.3.5 Restricciones de definicin
En el modelado de generalizacin o especializacin algunas veces es importante definir que
instancias del supertipo pertenecen a cada subtipo, esto se conoce como Restriccin de
definicin. Por ejemplo, en la figura 4.5, se utiliza un atributo del supertipo: claseTrabajo,
para discriminar la que subtipo pertenecen las instancias del supertipo. Una instancia del
supertipo Empleado_Hospital, segn el valor que tome el atributo claseTrabajo, ser
pertenecer a Medico, Celador, Enfermero o Limpiador. El atributo claseTrabajo se conoce
como Atributo Discriminante.
Figura 4.5 Ejemplo de atributo discriminante

(1,1)
(1,n)
(0,1)
(1,1)
(0,1)
(0,1)
(0,1) (0,1)
VEHICULO FABRICANTE
CAMION TURISMO
BICICLETA SIDECAR
Fabricado
ID
lleva
ISA 1
Nmero
Precio
NumEjes
NumPuertas
33

4.3.6 Restricciones de Disyuncin y Solapamiento
Permite determinar a cuntos subtipos puede pertenecer (a la vez) una instancia del supertipo
dentro de una relacin de generalizacin.
Los subtipos son disjuntos si una instancia del supertipo puede ser miembro de cmo mximo
uno de los subtipos. En la figura 4.6 se representa a los subtipos disjuntos mediante un arco,
significa que una instancia de VEHCULO puede ser pertenecer al subtipo Turismo o Camin,
pero no a ambas.

Figura 4.6 Ejemplo de Disyuncin

Los Subtipos son solapados si una instancia del supertipo puede ser, a la vez, miembro de ms
de un subtipo. Es la opcin por defecto. En la figura 4.7, una instancia de Persona puede
pertenecer a Empleado y a estudiante a la vez.

Figura 4.7 Ejemplo de Solapamiento

4.3.7 Restricciones de Completitud y Parcialidad
Permite determinar si toda instancia del supertipo debe pertenecer a algn subtipo en la
relacin de generalizacin.
La Especializacin total (completa) indica que toda instancia del supertipo tambin debe ser
instancia de algn subtipo. En la figura 4.8, todas las instancias del supertipo Animal,
pertenecen a algn subtipo; es decir, un animal es macho o es hembra o es hermafrodita. La
totalidad se representa con el pequeo crculo cerca del supertipo.

Figura 4.8 Ejemplo de Completitud

34

La Especializacin parcial indica que es posible que alguna instancia del supertipo no
pertenezca a ninguno de los subtipos. Es la opcin por defecto. La unin de las extensiones
de los subtipos no es la extensin del supertipo en su totalidad. En la figura 4.9, existen
algunas instancias del supertipo Alimento que no pertenecen a ninguno de los subtipos
representados.
Figura 4.9 Ejemplo de Parcialidad

35

Leccin 5
Proceso de Construccin de un MER
El proceso de construccin de un MER corresponde a la fase de Diseo Conceptual de una
base de datos. El artefacto de entrada para el diseo conceptual es la especificacin de
requerimientos de informacin obtenidos del mundo real (dominio de la aplicacin o del
negocio). El artefacto de salida del diseo conceptual se conoce como esquema conceptual
(un ejemplo es el modelo entidad-relacin).
Se pueden considerar las siguientes actividades para el proceso de construccin de un MER
(Diseo Conceptual): Identificar tipo de entidades, Identificar atributos para cada tipo de
entidad, identificar tipos de relaciones, determinar identificadores y entidades dbiles,
determinar jerarquas de generalizacin, y finalmente, revisar el modelo.
5.1 Identificar Tipos de Entidades
Para identificar los tipos de entidad, es muy importante considerar el contexto o dominio del
problema descrito en la especificacin de requerimientos de informacin.
En general, se puede seleccionar como tipo de entidad los nombres o sustantivos que
aparecen en la especificacin de requerimiento, por ejemplo Cliente, Aula, Alumno. Se sugiere,
tambin, seleccionar objetos importantes como personas, lugares o conceptos de inters,
excluyendo aquellos nombres que slo son propiedades de otros objetos, por ejemplo, se
pueden agrupar el nmero de empleado y el nombre de empleado en un tipo de entidad
denominada Empleado, y agrupar nmero de inmueble, direccin del inmueble y nmero de
habitaciones en otro tipo de entidad denominada Inmueble.
Una de las decisiones cruciales del diseo conceptual es determinar si un objeto o concepto se
modela como un tipo de entidad o no. Por ejemplo, el color es habitualmente un atributo de
una entidad (color de un auto), pero en una fbrica de pinturas probablemente sera
apropiado modelar el color como una entidad con sus propios atributos.
No siempre es obvio saber si un objeto es una entidad, una relacin o un atributo. Por ejemplo
cmo se podra clasificar matrimonio? Pues de cualquiera de las tres formas. El anlisis es
subjetivo, por lo que distintos diseadores pueden hacer distintas interpretaciones, aunque
todas igualmente vlidas.
Todo depende de la opinin y la experiencia de cada uno. Los diseadores de bases de datos
deben tener una visin selectiva y clasificar las cosas que observan dentro del contexto de la
empresa u organizacin. A partir de unas especificaciones de usuario es posible que no se
pueda deducir un conjunto nico de entidades, pero despus de varias iteraciones del proceso
de anlisis, se llegar a obtener un conjunto de entidades que sean adecuadas para el sistema
que se ha de construir.
5.2 Identificar Atributos
Para identificar atributos, al igual que con las entidades, se buscan nombres en las
especificaciones de requisitos. Son atributos los nombres que identifican propiedades,
cualidades, identificadores o caractersticas de entidades o relaciones.
36

Otra forma sencilla para identificar atributos es preguntarse qu informacin se quiere saber
de cada entidad? La respuesta a esta pregunta se debe encontrar en las especificaciones de
requisitos.
Cuando se estn identificando los atributos, se puede descubrir alguna entidad que no se ha
identificado previamente, por lo que hay que volver al principio introduciendo esta entidad y
viendo si se relaciona con otras entidades.
5.3 Identificar Tipos de relaciones
Para identificar los tipos de relaciones se suelen buscar las expresiones verbales (por ejemplo:
oficina tiene empleados, empleado gestiona inmueble, cliente visita inmueble). Si las
especificaciones de requisitos reflejan estas relaciones es porque son importantes para la
empresa y, por lo tanto, se deben reflejar en el esquema conceptual.
Slo interesan las relaciones que son necesarias. En el ejemplo anterior, se han identificado las
relaciones empleado gestiona inmueble y cliente visita inmueble. Se podra pensar en incluir
una relacin entre empleado y cliente: empleado atiende a cliente, pero observando las
especificaciones de requisitos no parece que haya inters en modelar tal relacin.
La mayora de las relaciones son binarias (entre dos entidades), pero no hay que olvidar que
tambin puede haber relaciones en las que participen ms de dos entidades, as como
relaciones recursivas.
Una vez identificadas todas las relaciones, hay que determinar la cardinalidad mnima y
mxima con la que participa cada entidad en cada una de ellas. Si la relacin es de muchos a
muchos es importante asegurarse si tiene o no atributos. De este modo, el esquema
representa de un modo ms explcito la semntica de las relaciones.
5.4 Determinar Identificadores y Entidades dbiles
Cada entidad tiene al menos un identificador. En este paso, se trata de encontrar todos los
identificadores de cada una de las entidades. Los identificadores pueden ser simples o
compuestos. De cada entidad se escoger uno de los identificadores como clave primaria en la
fase del diseo lgico.
Cuando se determinan los identificadores es fcil darse cuenta de si una entidad es fuerte o
dbil. Si una entidad tiene al menos un identificador, es fuerte (otras denominaciones son
padre, propietaria o dominante). Si una entidad no tiene atributos que le sirvan de
identificador, es dbil (otras denominaciones son hijo, dependiente o subordinada)..
5.5 Determinar Jerarquas de Generalizacin
En este paso hay que observar los tipos de entidades que se han identificado hasta el
momento. Si es necesario reflejar las diferencias entre distintas ocurrencias de un tipo sw
entidad, con lo que surgirn nuevos subtipos de esta entidad genrica; o bien, si hay entidades
que tienen caractersticas en comn y que realmente son subtipos de una nueva entidad
genrica.
5.6 Revisar el Esquema Conceptual
Antes de finalizar el diseo conceptual, se debe revisar el esquema conceptual con el usuario.
Este esquema est formado por el diagrama entidad-relacin y toda la documentacin que
describe el esquema. Si se encuentra alguna anomala, hay que corregirla haciendo los
cambios oportunos, por lo que posiblemente haya que repetir alguno de los pasos anteriores.
37

Este proceso debe repetirse hasta que se est seguro de que el esquema conceptual es una fiel
representacin de la parte de la empresa que se est tratando de modelar.

5.7 Casos de ejemplo
5.7.1 Empresa de alquiler de autos
Un determinado cliente, cuyos datos importantes son Cdigo y Nombre, puede tener en un
momento dado varias reservas. Una reserva la realiza un nico cliente y solo puede involucrar
a un auto. Un auto puede tener varias reservas en un determinado periodo de tiempo. Es
importante registrar el nmero de orden de la reserva, la fecha de comienzo de reserva y la de
terminacin. Todo automvil, que se identifica por su nmero de placa, tiene siempre
asignado un determinado garaje, que no puede cambiar. El Garaje se describe por su direccin
y capacidad. Cada reserva se realiza en una determinada agencia. De la agencia se necesita su
cdigo y direccin. En la base de datos pueden existir clientes que no hayan hecho ninguna
reserva. Es importante saber si un automvil est reservado o no en un momento
determinado.
Se pide elaborar el MER correspondiente
Solucin:
Identificando Entidades

Figura 5.1 Tipos de Entidades

Identificando Atributos:

Figura 5.2 Atributos de Entidades

CLIENTE
RESERVA
AUTO
GARAJE
AGENCIA
CLIENTE
RESERVA
AUTO
GARAJE
AGENCIA
DNI
NOMBRE NUMERO
FECHA_INICIO
FECHA_FIN NRO_PLACA
DIRECCION CAPACIDAD
CODIGO DIRECCION
38

Identificando Tipos de Relaciones y agregando cardinalidades:

Figura 5.3 Modelo ER completo

En la siguiente figura 5.3, se muestra el mismo MER con notacin IE
Figura 5.3 Modelo ER completo con Notacin IE

(0,n)
(1,1)
(1,1)
(0,n)
(1,1)
(0,n)
(1,1)
(0,n)
CLIENTE
RESERVA
AUTO
GARAJE
AGENCIA
DNI
NOMBRE
NUMERO FECHA_INICIO
FECHA_FIN
NRO_PLACA
DIRECCION
CAPACIDAD
CODIGO
DIRECCION
REALIZA
INVOLUCRA
ASIGNADO
REALIZADA
ASIGNADO
REALIZADA
INVOLUCRA
REALIZA
CLIENTE
DNI
NOMBRE
RESERVA
NUMERO
FECHA_INICIO
FECHA_FIN
AUTO
PLACA
GARAJE
DIRECCION_GARAJ
CAPACIDAD
AGENCIA
CODIGO
DIRECCION
39

5.7.2 Gestin de Trnsito Vehicular
La Polica de Trnsito de un determinado pas, dividido en Demarcaciones, desea un mejor control de la
gestin vehicular, en especial en lo que se refiere a las multas y accidentes.
Las Demarcaciones se identifican por su cdigo y tienen un nombre; adems, se requiere los datos
actuales referentes a su nmero de habitantes, nmero de vehculos y nmero de conductores con
carnet.
Un vehculo viene identificado por su matrcula (que consta del cdigo de la demarcacin
correspondiente, y de un nmero correlativo dentro de la demarcacin). Supondremos que la matrcula
no cambia por ningn concepto.
En un momento determinado, un vehculo tiene un nico propietario, que puede ir cambiando en
sucesivas ventas. Interesa, en los diferentes momentos de cada compra, su kilometraje (0, si es nuevo),
y su estado de conservacin (valorado de A hasta E, en sentido decreciente).
Tanto las multas como los accidentes se producen en una demarcacin determinada, y una consulta que
se estima ser frecuente es la de conocer las multas o los accidentes que se han producido en una fecha
determinada, o bien en un intervalo determinado.
Las multas y accidentes son identificados por un nmero dentro de cada demarcacin. De un accidente
interesa saber la hora y el lugar donde se ha producido, as como el/los vehculos, que se hayan visto
involucrados, y tambin el/los ciudadanos afectados. De estos ltimos, queremos saber si eran o no
conductores en el accidente, y tambin el dao fsico recibido, que se calificar de 1 a 5, segn la
gravedad, significando 1 que ha resultado muerto. De los vehculos anotaremos el estado en que han
quedado, valorado de 1 a 5, significando aqu 1 que no ha habido daos.
Las multas se ponen a un vehculo y a su propietario correspondiente, y especifican el lugar, el tipo de
infraccin (como por ejemplo, exceso de velocidad), el importe, etc. Como que muchas veces el polica
no podr pedir documentaciones (caso de multas de aparcamiento, radar, etc.), ser la base de datos la
que conseguir los datos del propietario, haciendo un clculo apropiado.

SOLUCIN

REGISTRA
APLICADA
DUEO_ACTUAL
COMPRADO
VENDIDO
AFECTA
INVOLUCRA
SE_PRODUCE
DEMARCACION
CODIGO
NOMBRE
NUM_HABITANTES
NUM_VEHICULOS
NUM_CONDUCTORES
VEHICULO
MATRICULA
MULTA
TIPO_INFRACCION
IMPORTE
ACCIDENTE
ESTADO_VEHICULO
PROPIETARIO
NUM_TARJETA_PROP
INCIDENTETRANSITO
NUMERO
FECHA
HORA
LUGAR
CIUDADANO
IDENTIFICACION
DAO_FISICO
IND_CONDUCTOR_SN
VENTA
KILOMETRAJE
ESTADO_CONSERVACION
40

Resumen
Un MER es un modelo conceptual, basado en Tipos de entidad, Tipos de relacin y atributos. Sus
extensiones consideran entidades dbiles, generalizacin, etc.
Una entidad es una persona, lugar, cosa, concepto o suceso, real o abstracto, de inters para la
empresa.
Un atributo es una propiedad de la entidad.
Un tipo de entidad define un conjunto de entidades con los mismos atributos.
Un atributo identificado permite distinguir una entidad de otra.
Una relacin es una asociacin entre dos entidades.
Un tipo de relacin es un conjunto de relaciones existentes entre entidades.
El grado de una relacin es el numero de entidades que participa en la relacin
Los roles ayudan a explicar el significado de una relacin, se usa relaciones unarias
La razn de cardinalidad o tipo de correspondencia es una restriccin definida por el nmero
mximo de instancias de un tipo de entidad que puede estar relacionada con una instancia del otro
tipo de entidad asociada. Puede ser: uno a uno, uno a muchos y muchos a muchos.
Un atributo de una relacin es propio de la relacin.
La Razn de Participacin o cardinalidad mnima y mxima de una relacin, son los nmeros
mnimo y mximo de instancias de tipo de relacin en las que puede intervenir una instancia del
tipo de entidad participante.
Una entidad dbil es aquella que no tiene atributo identificador propio. Su existencia depende de
otra entidad (fuerte) que la posee y la identifica inequvocamente.
La generalizacin es una relacin entre un tipo de entidad (padre) y varios otros tipos de entidad
(hijos), donde la jerarqua o relacin que se establece entre uno y otros corresponde a la nocin de
es_un o de es_un_tipo_de.

41

Lectura
El Lenguaje de Modelado Unificado UML (*)
Los diagramas entidad-relacin ayudan a modelar el componente de representacin de datos
de un sistema software. La representacin de datos, sin embargo, slo forma parte de un
diseo completo de un sistema. Otros componentes son modelos de interaccin del usuario
con el sistema, especificacin de mdulos funcionales del sistema y su interaccin, etc. El
lenguaje de modelado unificado (UML, Unified Modeling Language) es un estndar propuesto
para la creacin de especificaciones de varios componentes de un sistema software. Algunas
de las partes de UML son:
Diagrama de clase. Un diagrama de clase es similar a un diagrama E-R. Ms adelante
en este apartado se mostrarn algunas caractersticas de los diagramas de clase y
cmo se corresponden con los diagramas E-R.
Diagrama de caso de uso. Los diagramas de caso de uso muestran la interaccin entre
los usuarios y el sistema, en particular los pasos de las tareas que realiza el usuario
(tales como prestar dinero o matricularse de una asignatura).
Diagrama de actividad. Los diagramas de actividad describen el ujo de tareas entre
varios componentes de un sistema.
Diagrama de implementacin. Los diagramas de implementacin muestran los
componentes del sistema y sus interconexiones tanto en el nivel del componente
software como el hardware.
Aqu no se intentar proporcionar un tratamiento detallado de las diferentes partes de UML.
Vanse las notas bibliogrficas para encontrar referencias de UML. En su lugar se ilustrarn
algunas caractersticas de UML mediante ejemplos.
La Figura 2.28 muestra varios constructores de diagramas E-R y sus constructores equivalentes
de los diagramas de clase UML. Ms abajo se describen estos constructores. UML muestra los
conjuntos de entidades como cuadros y, a diferencia de E-R, muestra los atributos dentro del
cuadro en lugar de como elipses separadas. UML modela realmente objetos, mientras que E-R
modela entidades. Los objetos son como entidades y tienen atributos, pero adems
proporcionan un conjunto de funciones (denominadas mtodos) que se pueden invocar para
calcular valores en trminos de los atributos de los objetos, o para modificar el propio objeto.
Los diagramas de clase pueden describir mtodos adems de atributos.
Los conjuntos de relaciones binarias se representan en UML dibujando simplemente una lnea
que conecte los conjuntos de entidades. Se escribe el nombre del conjunto de relaciones
adyacente a la lnea. Tambin se puede especificar el papel que juega un conjunto de
entidades en un conjunto de relaciones escribiendo el nombre del papel en un cuadro, junto
con los atributos del conjunto de relaciones, y conectar el cuadro con una lnea discontinua a
la lnea que describe el conjunto de relaciones. Este cuadro se puede tratar entonces como un
conjunto de entidades, de la misma forma que una agregacin en los diagramas E-R puede
participar en relaciones con otros conjuntos de entidades.
La relaciones no binarias no se pueden representar directamente en UML .se deben convertir
en relaciones binarias.
Las restricciones de cardinalidad se especifican en UML de la misma forma que en los
diagramas E-R, de la forma i..h, donde i denota el mnimo y h el mximo nmero de relaciones
en que puede participar una entidad. Sin embargo, se debera ser consciente que la ubicacin
de las restricciones es exactamente el inverso de la ubicacin de las restricciones en los
diagramas E-R, como muestra la Figura 2.28. La restriccin 0..* en el lado E2 y 0..1 en el lado E1
42

significa que cada entidad E2 puede participar a lo sumo en una relacin, mientras que cada
entidad E1 puede participar en varias relaciones; en otras palabras, la relacin es varios a uno
de E2 a E1.
Los valores como 1 o * se pueden escribir en los arcos; el valor 1 sobre un arco se trata
equivalentemente como 1..1, mientras que * es equivalente a 0..*.
La generalizacin y especializacin se representan en el diagrama E-R conectando conjuntos de
entidades por una lnea con un tringulo al final correspondiente al conjunto de entidades ms
general. Por ejemplo, el conjunto de entidades persona es una generalizacin de cliente y
empleado. Los diagramas UML tambin pueden representar explcitamente las restricciones
de generalizaciones disjuntas y solapadas. La Figura 2.28 muestra generalizaciones disjuntas y
solapadas de cliente y empleado a persona. Recurdese que la generalizacin de cliente /
empleado a persona es disjunta, y significa que ninguna entidad puede ser a la vez un cliente y
un empleado. Una generalizacin solapada permite que una persona sea tanto cliente como
empleado.

(*)Korth (2002, pp.46-47)
43

Actividades
Elaborar el MER para los siguientes casos
1. Empresa de venta de productos
Una empresa vende productos a varios clientes. Se necesita conocer los datos personales de los clientes:
DNI, nombre, apellidos, direccin y fecha de nacimiento. Cada producto tiene un cdigo y un nombre as
como un precio unitario. Un cliente puede comprar varios productos a la empresa, y un mismo producto
puede ser comprado por varios clientes.
Se debe tener en cuenta que un producto solo puede ser suministrado por un proveedor, y que un
proveedor puede suministrar diferentes productos. De cada proveedor se desea conocer el RUC,
nombre y direccin.
2. Institucin Educativa
Se desea elabora una base de datos para el administrador de una institucin educativa, que brinda
cursos de informtica, quien manifiesta lo siguiente: Enseamos muchos cursos, cada uno de los cuales
tiene un cdigo, un nombre y un precio. Dos de nuestros cursos ms populares son: Introduccin a
Internet y Programacin Java. Los cursos se dictan entre uno a cuatro das. Un instructor puede ensear
varios cursos. Registramos el nombre y nmero de telfono de los profesores. Cada curso es enseado
por slo un instructor. Creamos un curso y luego le asignamos un profesor. Los estudiantes pueden
tomar varios cursos a la vez, y muchos de ellos lo hacen. Tambin registramos el nombre y telfono de
cada estudiante. Algunos de nuestros estudiantes e instructores no nos dan sus nmeros telefnicos."
3. Empresa de venta de automviles
Se desea disear una base de datos para almacenar y gestionar la informacin empleada por una
empresa dedicada a la venta de automviles, teniendo en cuenta los siguientes aspectos: La empresa
dispone de una serie de coches para su venta. Se necesita conocer la matrcula, marca y modelo, el color
y el precio de venta de cada coche. Los datos que interesa conocer de cada cliente son el DNI, nombre,
direccin, ciudad y nmero de telfono: adems, los clientes se diferencian por un cdigo interno de la
empresa que se incrementa automticamente cuando un cliente se da de alta en ella. Un cliente puede
comprar tantos coches como desee a la empresa. Un coche determinado solo puede ser comprado por
un nico cliente. El concesionario tambin se encarga de llevar a cabo las revisiones que se realizan a
cada coche. Cada revisin tiene asociado un cdigo que se incrementa automticamente por cada
revisin que se haga. De cada revisin se desea saber si se ha hecho cambio de filtro, si se ha hecho
cambio de aceite, si se ha hecho cambio de frenos u otros. Los coches pueden pasar varias revisiones en
el concesionario.
4. Compaa de Videos
Soy el propietario de una pequea tienda de videos. Tenemos alrededor de 3.000 cintas de las cuales
necesitamos mantener su estado.
Cada uno de nuestras cintas tiene un nmero de identificacin. Para cada pelcula, necesitamos conocer
su ttulo y categora (comedia, suspenso, drama, accin, guerra, etc.)Tenemos mltiples copias de
muchas de nuestras pelculas. A cada pelcula le asignamos un identificador y le asociamos la cinta que
la contiene. Una cinta puede ser formato Beta o VHS. Siempre tenemos al menos una cinta para cada
pelcula que nosotros rastreamos, y cada cinta es siempre una copia de una nica pelcula. Nuestras
cintas son de larga duracin y no tenemos pelculas que requieran mltiples cintas.
Frecuentemente nos preguntan por pelculas con actores populares especficos. As que deseamos
registrar las pelculas donde estn los actores de moda. No todas nuestras pelculas tienen actores
famosos o de moda. Clientes desean conocer de cada actor su nombre real y fecha de cumpleaos. Slo
registramos los actores que aparecen en pelculas de nuestro inventario.
44

Tenemos cientos de clientes. Slo arrendamos videos a gente asociada a nuestro video-club. Para cada
socio, registramos su nombre, apellido, telfono, direccin. Y, por supuesto cada socio tiene su nmero
de socio. Luego, necesitamos conocer que cinta ha retirado cada cliente. Un cliente puede retirar varias
cintas al mismo tiempo. Slo registramos los arriendos actuales, no los histricos.
5. Empresa Bancaria
Un banco brinda cuentas corrientes y cuentas de ahorro. Un cliente tiene al menos una cuenta, aunque
puede tener varias cuentas de cualquiera de los dos tipos. Cada cuenta pertenece a un nico cliente. Los
clientes tienen un nombre, una direccin y se identifican por su cdigo. Los clientes son personas reales
u organizaciones. Las personas tienen fecha de nacimiento y sexo; en cambio las organizaciones tienen
un tipo de organizacin (empresa, institucin pblica, etc.), un representante y un total de empleados.
Cada cuenta se identifica por un cdigo, formado por el nmero de la sucursal y el n de la cuenta
(dentro de dicha sucursal). Todas las cuentas tienen un saldo actual y un saldo medio, pero el tipo de
amortizacin slo lo tienen las cuentas de ahorro (que slo suponen el 5% del total de cuentas
existentes).
Cada sucursal se identifica por su nmero. Adems tiene una direccin, un cdigo postal y una ciudad.
Los empleados del banco se identifican por su DNI. Tambin interesa conocer su nombre, fecha de
nacimiento, sexo y la sucursal en la que trabajan (aunque hay empleados que no trabajan en ninguna
sucursal).
6. Organizacin Interna de Empresa
Una empresa necesita organizar la siguiente informacin referente a su organizacin interna. La
empresa est organizada en una serie de departamentos. Cada departamento tiene un cdigo, nombre
y presupuesto anual. Cada departamento est ubicado en un centro de trabajo. La informacin que se
desea guardar del centro de trabajo es el cdigo de centro, nombre, poblacin y direccin del centro. La
empresa tiene una serie de empleados. Cada empleado tiene un telfono, fecha de alta en la empresa,
DNI y nombre. De cada empleado tambin interesa saber el nmero de hijos que tiene y su salario. A
esta empresa tambin le interesa tener guardada informacin sobre los hijos de los empleados. Cada
hijo de un empleado tendr un cdigo, nombre y fecha de nacimiento. Se desea mantener tambin
informacin sobre las habilidades de los empleados (por ejemplo, mercadotecnia, trato con el cliente,
fresador, operador de telefona, etc). Cada habilidad tendr una descripcin y un cdigo.
Considerar tambin los siguientes aspectos:
Un empleado est asignado a un nico departamento. Un departamento estar compuesto por
uno o ms empleados.
Cada departamento se ubica en un nico centro de trabajo. Estos se componen de uno o ms
departamentos.
Un empleado puede tener varios hijos.
Un empleado puede tener varias habilidades, y una misma habilidad puede ser poseda por
empleados diferentes.
Un centro de trabajo es dirigido por un empleado. Un mismo empleado puede dirigir centros de
trabajo distintos.

45

Autoevaluacin
1. Con respecto al concepto de MER, entre los parntesis de la siguiente lista, marque V=Verdadero o
F=Falso, segn corresponda:
a. ( ) Es un modelo de datos lgico
b. ( ) Es un modelo de datos conceptual
c. ( ) Incluye detalles de implementacin
d. ( ) Incluye tipos de entidades y tipos de relacin
e. ( ) Es un software para representar datos
2. Establezca la relacin de concepto y su descripcin, colocando la letra de la descripcin en la celda a
la derecha del Concepto:

Concepto Descripcin del concepto.
1. Entidad
a) Cdigo, nombre, edad de alumno; DNI, nombre de
persona
2. Tipo de entidad

b) Cesar alquila un video; Juan lleva base de datos 1
3. Atributo

c) Juan Prez, Pedro Miranda,
4. Atributo Identificador
d) Ayudan a explicar el significado de una relacin y se
usa en relaciones unarias
5. Relacin

e) DNI de una persona, Cdigo de una Asignatura
6. Tipo de Relacin
f) Numero de tipos de entidad que participan en un tipo
de relacin
7. Grado de Tipo Relacin

g) Alumno, Persona
8. Rol

h) Cliente alquila Video

3. A continuacin se listan una serie de supuestos semnticos y una serie de diagramas entidad
relacin, establezca la correspondencia correcta colocando la letra del diagrama en la casilla DERal
costado del supuesto semntico:

Supuesto semnticos DER
1. Un promotor vende uno o ms productos y un producto es vendido por solo un
promotor.

2. Un promotor puede vender muchos productos (al menos uno) y un producto puede ser
vendido por muchos promotores.

3. Un promotor vende uno y solo un producto, un producto puede ser vendido por solo un
promotor. Hay promotores que no venden ningn producto.

4. Un promotor vende uno y solo un producto, pero un producto puede ser vendido por
muchos promotores

Diagramas Entidad Relacin
a)

b)

VENDE
PROMOTOR
PRODUCTO
VENDE
PROMOTOR
PRODUCTO
46

c)

d)

4. Considerando el siguiente Diagrama Entidad Relacin

Entre los parntesis de la siguiente lista, marque V=Verdadero o F=Falso, segn corresponda:

a. ( ) Una persona puede solicitar prstamo
b. ( ) Un prstamo puede ser solicitado solo por un cliente persona, no por empresas
c. ( ) Un cliente es un tipo de empresas
d. ( ) Una empresa es un tipo de cliente
e. ( ) Una persona es un tipo de cliente

Respuestas de Control
1. a = F, b = V, c = F, d = V, e = F
2. 1 = c, 2 = g, 3 = a, 4 = e, 5 = b, 6 = h, 7 = f, 8 = d
3. 1 = c, 2 = d, 3 = a, 4 = b
4. a = V, b = F, c = F, d = V, e = V

Exploracin On-Line
Herramienta de modelado dbdesigner
http://fabforce.net/dbdesigner4/
Herramienta de modelado DIA for Windows
http://dia-installer.de/index_en.html

1. ANSI (1977): The ANSI/X3/SPARC DBMS Framework. Report on the Study Group on
Database Management Systems. D. Tsichiritzis y A. Klug (eds). Montvalle, N.J.: AFIP Press.
VENDE
PROMOTOR
PRODUCTO
VENDE
PROMOTOR
PRODUCTO
SOLICITA
CLIENTE
PERSONA
EMPRESA
PRESTAMO
47

2. Chen, Peter (1976), The entety-relationship model:Towards a unified view of data. ACM
Trans.Sistemas de bases de datos 1 (1) 9-36.
3. De Miguel A. y Piattini M., (1999) Fundamentos y Modelos de Base de datos. 2da. Ed.
Madrid. Alfa y Omega.
4. Elmasri, Ramez y Shamkant Navathe (1997) Sistemas de Bases de Datos. Conceptos
fundamentales. Segunda Edicin. Madrid. Addison-Wesley Iberoamericana.
6. Korth, H., Silberschatz, A., Sudarschan, S. (2002) Fundamentos de base de datos. 4ta. Ed.
Madrid. McGrawHill/Interamericana.

48

UNIDAD 3
EL MODELO RELACIONAL (MR)

Qu es el Modelo relacional? Cules son sus elementos?
Qu es una relacin? Qu es un domino de atributo?
Qu es el esquema y estado de la base de datos?
Qu es una clave candidata?, Qu es Clave Primaria y Clave fornea?
Cules son las restricciones del modelo relacional?
Qu es la normalizacin? Cules son sus reglas o formas normales?

49

Leccin 6
Definicin y elementos del MR
4.1 Definicin
El Modelo Relacional, es un modelo de datos lgico, fue introducido por Codd (1970). Es el
modelo ms utilizado en la actualidad para modelar y administrar datos.
En el modelo relacional los datos se representan como una coleccin de Relaciones o Tablas
(Figura 6.1). Una Relacin es un conjunto de datos.
Figura 6.1 Organizacin de datos como relaciones o tablas

Este modelo de datos persegua una serie de objetivos que se resumen en: Independencia
fsica, Independencia lgica, Flexibilidad, Uniformidad. Sencillez.
Con la Independencia fsica el modo en que se almacenan los datos no influye en su
manipulacin lgica y por tanto, los usuarios que acceden a esos datos no tienen que
modificar sus programas por cambios en el almacenamiento fsico.
Con la Independencia lgica el aadir, eliminar o modificar objetos de la base de datos no
repercute en los programas y usuarios que estn accediendo a subconjuntos parciales de los
mismos (vistas).
Con la Flexibilidad se pretende presentar a cada usuario los datos de la forma en que ste
prefiera.
Con la Uniformidad las estructuras lgicas de los datos presentan un aspecto uniforme, lo que
facilita la concepcin y manipulacin de la base de datos por parte de los usuarios.
Con la Sencillez las caractersticas anteriores, as como unos lenguajes de usuario muy
sencillos, producen como resultado que el modelo de datos relacional sea fcil de comprender
y de utilizar por parte del usuario final.
4.2 Elementos
4.2.1 Relacin
De manera simple, una relacin representa una tabla, que no es ms que un conjunto de filas y
columnas. Cada fila es un conjunto de atributos, el conjunto de atributos se conoce como
cabecera o esquema de la relacin y cada atributo representa un valor que interpretado
describe el mundo real (Figura 6.2).
ITEM_FACTURA
FACTURA
PRODUCTO
FACTURA
ITEM 1
PRODUCTO 1
ITEM 1
PRODUCTO 2
FACTURA
ITEM PRODUCTO
cod fecha id_t
cod desc stock cod cant prod
Modelo Entidad-Relacin
Base Datos Relacional
Base Datos Red
Base Datos Jerarquica
FACTURA
ITEM1 ITEM2
PROD1
PROD2
50

Cada fila tambin se puede denominar tupla o registro y a cada columna tambin se le puede
llamar campo o atributo.

Figura 6.2 Elementos de una relacin

4.2.2 Dominio de un atributo
El Dominio de un atributo es el conjunto de valores que un atributo puede tomar. Un dominio
es usualmente representado por un tipo.
Ejemplos: .
El Domino del atributo Cdigo es un Char(09) --- Cadena de caracteres de longitud 9.
El Dominio de Nombre es un Varchar(30) --- Cadena de caracteres de longitud variable
hasta 30 caracteres.
El Dominio de Edad, es un rango de nmeros: 15 a 90.
El Dominio del atributo Nota es un rango de nmero de 0 a 20.
El Dominio del atributo Gnero es el conjunto de valores Masculino y Femenino.
4.2.3 Esquema y Estado de una Relacin
El Esquema (schema) de una relacin o cabecera de la relacin es el conjunto de los atributos
de la relacin (korth, 2002).
Por ejemplo, el esquema de la relacin ALUMNO, de la figura 6.2, es (Cdigo, Nombre, Edad,
Nota) y se representa:
ALUMNO (Cdigo, Nombre, Edad, Nota)
El Estado (o contenido) de la relacin es el actual conjunto de tuplas o filas de la relacin.
Un esquema determinado puede tener diferentes estados en diferentes tiempos.
El esquema de una relacin raramente cambia. Algunos posibles cambios son: Renombrar un
atributo, Borrar un atributo, Aadir un atributo, Borrar el esquema.
El estado de una relacin puede cambiar frecuentemente. Algunos posibles cambios son:
Modificar algunos valores de atributos, Borrar una tupla existente, Insertar una nueva tupla.
4.2.4 Esquema y Estado de una Base de Datos
El esquema de base de datos relacional consiste de un conjunto de esquemas de relaciones.
Por ejemplo, el esquema de una base de datos acadmica sencilla podra ser:
51

FACULTADES (Cdigo, Nombre)
ALUMNOS (Cdigo, Nombre, Edad, Facultad),
ASIGNATURAS (Cdigo, Descripcin),
DOCENTES (DNI, Nombre)
El estado de la base de datos es la data actualmente en la base de datos. En la figura 6.3 se
muestra un ejemplo de estado de base de datos en un momento determinado.
Figura 6.3 Estado de una base de dato
FACULTADES

ALUMNOS

Cdigo Nombre

Cdigo Nombre Edad Facultad
21 SISTEMAS

21-990101 JUAN 21 17
17 INDUSTRIAL

21-872342 MARA 19 21
11 ADMINISTRACIN

21-765349 ALBERTO 18 21

ASIGNATURAS

DOCENTES

Cdigo Nombre

Cdigo Nombre

BD01 BASE DE DATOS 1

6222888 CARPIO

AS99
ANLISIS DE
SISTEMAS

3490023 CRUZ

LP03 LENGUAJE

8674444 LUZA

CC00 CIRCUITOS DIGITALES

OM00 ORGANIZACIN

4.2.5 Claves Candidata, Clave Primaria y Clave Fornea
Las Claves Candidatas es un conjunto no vacio de atributos que identifican univoca y
mnimamente cada tupla que cumple un esquema de relacin, puede haber varias en el mismo
esquema.
Una Clave Primaria (Primary Key) es una clave candidata elegida, mediante algn criterio,
para este fin.
Una Clave Fornea (Foreign Key) es una combinacin de atributos cuyos valores estn basados
en los valores de la clave primaria de otra tabla o de la misma tabla.
Por ejemplo, sean los siguientes esquemas de relaciones:
EMPLEADO ( NEmpleado, NSeguridadSocial, DNI, Nombre, Edad, NDepartamento,
NEmpleadoSupervisor )
DEPARTAMENTO ( NDepartamento, Denominacin, NEmpleadoJefe )
Las Claves candidatas de EMPLEADO son: NEmpleado, NSeguridadSocial y DNI. La clave
Primaria elegida puede ser NEmpleado. La Clave Primaria de DEPARTAMENTO es
NDepartamento.
Las Claves Forneas de EMPLEADO son NDepartamento y NEmpleadoSupervisor y la Clave
Fornea de DEAPARTAMENTO es NEmpleadoJefe.
4.3 Reglas
El modelo relacional considera una serie de reglas o restricciones para estar completamente
definida.
52

4.3.1 Regla de primera forma normal
No se permiten atributo multivaluado en una tabla. Es decir, para cualquier tupla t y atributo
A en una tabla, t [A] debe ser un valor simple o atmico.

4.3.2 Regla de fila nica
No se permite dos filas en la misma tabla que sean idnticas en cualquier momento dado. Es
decir cada tupla en la tabla es nica. Cuando una nueva tupla es insertada a la relacin, el
sistema tiene que estar seguro que la nueva tupla es diferente a todas las tuplas existentes en
la relacin.
4.3.3 Regla de Integridad de Entidad
No se permiten valores nulos en la llave primaria y todas las entradas sern nicas. Con las
reglas de integridad de entidad se garantiza que cada entidad (tupla) tiene un identificador
nico.
4.3.4 Regla de Integridad Referencial
El valor de la clave fornea puede ser nulo o tiene que parear (coincidir) con el valor de la clave
primaria de la tabla con la cual se establece la interrelacin. Se garantiza que no es posible
establecer relaciones que no pareen. Con las reglas de integridad se minimizan los errores de
entrada de datos, esto es, que haya consistencia.

53

Leccin 7
Transformacin de un MER a MR
El proceso de transformacin de un MER a MR corresponde a la fase de Diseo Lgico de una
base de datos. El artefacto de entrada para el diseo lgico es el esquema conceptual (MER)
elaborado en la fase de diseo conceptual. El artefacto de salida del diseo lgico es el
esquema lgico.
Se pueden considera las siguientes reglas para el proceso de transformacin de un MER a MR:
7.1 Transformacin de tipo de entidad
Para transformar un tipo de entidad a relacin (esquema relacional) se se crea una relacin por
cada entidad; los atributos de la entidad se transforman en atributos de la relacin; el
identificador del tipo de entidad se transforma en la clave primaria de la relacin.
Por ejemplo, el siguiente tipo de entidad

Se transforma en el siguiente esquema relacional:
CATEGORA (CDIGO, DESCRIPCIN)
PK = Cdigo
Donde PK = Primary Key, Clave Primaria.
7.2 Transformacin de tipo de relacin
Las reglas bsicas de transformacin de tipo de relacin a esquema relacional se puede
resumir segn el tipo de correspondencia en:
7.2.1 Uno a Muchos
Para los tipos de relacin unarias o binarias de tipo 1:N se adicionan los atributos
identificadores de la entidad del lado 1 a la del lado N, convirtindose en claves forneas
(Foreign Key) .
i. Por ejemplo, el siguiente tipo de relacin unaria de Uno a Muchos:

Se transforma en el siguiente esquema relacional:
CATEGORIA
CODIGO DESCRIPCION
(0,1)
(0,n)
ALUMNO
CODIGO
APELLIDO
NOMBRE
Es_tutor_de
54

ALUMNO (CDIGO, APELLIDO, NOMBRE, CODIGO_TUTOR)
PK = CDIGO
FK = CODIGO_TUTOR de ALUMNO

FK = Foreign Key, Clave Foranea.

ii. El siguiente tipo de relacin binaria Uno a Muchos:

Se transforma en los siguientes esquemas relacionales:
FACULTAD (CDIGO, DESCRIPCIN)
PK = CDIGO
ALUMNO (CDIGO, APELLIDO, NOMBRE, CODIGO_FACULTAD)
PK = CDIGO
FK = CODIGO_FACULTAD de AFACULTAD
7.2.2 Muchos a Muchos
Para los tipos de relacin unarias o binarias de cardinalidad M:N y ternarias, se crea una nueva
relacin cuya clave primaria estar formada por la combinacin de las claves primarias de las
entidades participantes.
El siguiente tipo de relacin binaria de M:N:

Se transforma en los siguientes esquemas relacionales:

ALUMNO (CODIGO, APELLIDO, NOMBRE)
PK= CODIGO
ASIGNATURA (CODIGO, NOMBRE)
PK = CODIGO
LLEVA (CODIGO_ALUMNO, CODIGO_ASIGNATURA)
PK = (CODIGO_ALUMNO, CODIGO_ASIGNATURA)
FK = CODIGO_ALUMNO de ALUMNO
FK = CODIGO_ASIGNATURA de ASIGNATURA

Se ha creado una nueva relacin llamada LLEVA, cuyo PK est formado por la combinacin de
los atributos: CodigoAlumno y CodigoAsignatura, cada uno de estos atributos es clave fornea
independientemente.
(0,n)
(1,1)
ALUMNO
CODIGO
APELLIDO
NOMBRE
TIENE FACULTAD
CODIGO DESCRIPCION
(0,n) (0,n)
ALUMNO
CODIGO
NOMBRE
APELLIDO
ASIGNATURA
LLEVA
CODIGO
NOMBRE
55

7.2.3 Uno a Uno
Para los tipos de relacin unaria o binaria de cardinalidad 1:1, se intercambia los atributos
identificadores entre los tipos de entidad participantes.
Por ejemplo el siguiente tipo de relacin binaria Uno a Uno:

Se transforma en los siguientes esquemas relacionales, se ha intercambiado los atributos
identificadores de ambas entidades:.

DECANO (DNI, APELLIDOS, NOMBRES, CODIGO_FACULTAD))
PK = DNI
FK = CODIGO_FACULTAD de FACULTAD
FACULTAD (CODIGO, NOMBRE, DNI_DECANO)
PK = CODIGO
FK = DNI_DECANO de DECANO

7.3 Transformacin de entidades dbiles
Para transformar una entidad dbil, se crea una relacin para cada entidad dbil incluyendo
todos sus atributos. Se aade una clave ajena a la entidad de la que depende. Para ello, se
incluye la clave primaria de la relacin que representa a la entidad fuerte en la nueva relacin
creada para la entidad dbil. A continuacin, determinar la clave primaria de la nueva relacin.

Por ejemplo, el siguiente MER que incluye entidad dbil:

Se transforma en:

FACTURA (NroFac, Fecha, Condicin)
PK = NroFac
DETALLE (NroFac, NroDet, CodArticulo, Cantidad)
PK = (NroFac, NroDet)
FK = NroFac de FACTURA

7.4 Transformacin de generalizaciones
Para transformar una generalizacin se crear una relacin por cada entidad. Las relaciones de
las entidades hijo heredan como clave primaria la de la entidad padre. Por lo tanto, la clave
(0,1)
(1,1)
DECANO
DNI
NOMBRES
APELLIDOS
FACULTAD
DIRIGE
CODIGO
NOMBRE
(1,1) (1,n)
FACTURA DETALLE
E
TIENE
Nro_Fac
Fecha
Condicin
Nro_Det
Cod_Articulo
Cantidad
56

primaria de las entidades hijo es tambin una clave ajena al padre. Esta opcin sirve para
cualquier tipo de jerarqua, total o parcial y exclusiva o superpuesta.
Por ejemplo, la siguiente jerarqua:

Se transforma en:
ESTUDIANTE (Cdigo, Apellidos, Nombres)
PK = Cdigo
GRADUADO (Cdigo, FechaGraduacin))
PK = Cdigo
FK = Cdigo de ESTUDIANTE
NO_GRADUADO (Cdigo, FechaInspcripcin))
PK = Cdigo
FK = Cdigo de ESTUDIANTE
7.5 Caso Ejemplo
Transformar el siguiente MER a MR

(0,1)
(0,1)
(0,1)
ESTUDIANTE
Codigo
Apellidos
Nombres
ISA 1
GRADUADO
NO GRADUADO
FechaInscripcin
FechaGraduacion
(1,1)
(0,n)
(1,1)
(1,n)
(0,n)
(1,n)
(0,n)
(1,1)
(1,1)
(0,1) (0,1)
CATEGORIA
PRODUCTO
INCLUYE
Codigo Descripcin
Codigo
Nombre
PRESENTACION
E
TIENE
Numero
Descripcin
Cantidad
Precio
LimiteInf
LimiteSup
PEDIDO
VENDIDO
Cantidad
CLIENTE
NUMERO
FECHA
REALIZADO
RUC FechaCompra
EMPRESA PERSONA
ISA 1
RaznSocial
Contacto
Apellidos
Nombres
57

SOLUCIN
CATEGORA (Cdigo, Descripcin);
PK = Cdigo
PRODUCTO (Cdigo, Nombre, CodigoCategoria);
PK = Cdigo,
FK = CodigoCategoria de CATEGORIA
PRESENTACIN (CodigoProducto, Nmero, Descripcin, Cantidad, LimiteInf, LimiteSup);
PK = (CodigoProducto, Nmero);
FK = CodigoProducto de PRODUCTO
CLIENTE (RUC, FechaCompra);
PK = RUC
EMPRESA (RUC, RaznSocial, Contacto);
PK = RUC
FK = RUC de CLIENTE
PERSONA (RUC, Apellidos, nombres);
PK = RUC
FK = RUC de CLIENTE
PEDIDO (Nmero, Fecha, RUC);
PK = Nmero
FK = RUC de CLIENTE
VENDIDO (CodigoProducto, NmeroPedido, Cantidad);
PK = (CodigoProducto, NumeroPedido)
FK = CodigoProducto de PRODUCTO
FK = NumeroPedido de PEDIDO

58

Leccin 8
Normalizacin
8.1 Definicin
La normalizacin de base de datos relacional es considerada un proceso formal para asegurar
un buen diseo de base de datos relacional. A travs de este proceso, se descompone las
relaciones (tablas) en otras de menor cantidad de columnas con el objetivo de evitar
anomalas que pueden ocurrir en las operaciones de actualizacin de las mismas.
La teora asociada al concepto de normalizacin fue introducida por E.D. Codd (1970). Se basa
en el concepto matemtico de dependencias funcionales, y se expresa como reglas conocidas
como formas normales.
8.2 Dependencias funcionales
Informalmente, el concepto de dependencia funcional se puede explicar de la siguiente
manera: Un dato depende funcionalmente de otro, si este ltimo siempre lo identifica, es decir
que conociendo su valor podemos identificar al primero.
Por ejemplo, conociendo el valor de fecha de nacimiento podemos conocer el valor de Edad,
entonces, se dice que Edad depende funcionalmente de fecha de nacimiento, y se representa:
Fecha de Nacimiento Edad
Formalmente, la dependencia funcional se puede definir de la siguiente manera: Sean A y B
atributos de una relacin R. Se dice que B es funcionalmente dependiente de A (A B) si todo
posible valor de A tiene asociado un nico valor de B. A y B pueden ser atributos simples o
compuestos.
Veamos otro ejemplo, consideremos la siguiente tabla:

MATRICULA

Se observa que en las filas correspondientes a un mismo Alumno, existe el mismo valor para la
Direccin. En otras palabras, en todas las filas con el mismo valor del atributo Alumno, el
atributo Direccin tendr tambin el mismo valor.
Entonces, se dice que el esquema cumple una dependencia funcional, y que el atributo
Direccin depende funcionalmente de Alumno o que Alumno determina funcionalmente a
Direccin y se denota:
Alumno Direccin
Tambin se observa que: Nota depende funcionalmente de Alumno y Asignatura juntos.
(Alumno, Asignatura) Nota
Alumno Asignatura Direccin Nota
Jos Prez Base de datos I Bolvar 180. Pueblo Libre 18
Luis Adonis Base de datos I Junn 300. Jess Mara 16
Jos Prez Anlisis de Sistemas Bolvar 180. Pueblo Libre 19
Lucas Len Organizacin y Mtodos Quiones 780. San Miguel 17
59

8.2.1 Dependencia Funcional Completa
Sea X (conjunto de atributos). Se dice que un atributo Y tiene dependencia funcional y
completa de un conjunto de atributos X, si depende funcionalmente de TODO el conjunto,
pero no de algn subconjunto de X.
Por ejemplo, consideremos la siguiente relacin:

MATRICULA

Se observa que (Alumno, Asignatura) ==> Nota es una dependencia funcional completa. En
cambio: (Alumno, Asignatura) Crditos no es una dependencia funcional completa,
porque Asignatura Crditos.
8.2.2 Dependencia Funcional Transitiva
Sean X e Y, atributos de una relacin R. Si XY (Y depende funcionalmente de X), Y-/X (X
No depende funcionalmente de Y), YZ (Z depende funcionalmente de Y), entonces, Z
depende transitivamente de X ( X--Z ).
MATRICULA
Se observa que: Alumno Distrito,
Distrito --/ Alumno (no determina funcionalmente), y
Distrito Distancia,
Entonces, Alumno --- distancia (Alumno determina transitivamente a distancia).

8.3 Formas normales
Las Formas Normales son reglas que permiten estructurar las relaciones (tablas) de tal manera
que los datos de la base de datos permanezcan organizados y sea fcil realizar cambios sin
efectos secundarios.
Las formas normales bsicas son conocidas como: Primera Forma normal, Segunda Forma
Normal y Tercera Forma Normal. Cada una se basa en el conjunto precedente de reglas, por lo
que los datos que se encuentran en la Tercera Forma Normal, estn automticamente en las
Primera y Segunda formas Normales, tambin.
8.3.1 Primera Forma Normal (1FN)
Un esquema o relacin (tabla) est en 1 FN, si el dominio asociado a cada atributo contiene
nicamente valores atmicos; es decir, no tiene atributos multivalorados (repetidos).
Alumno Asignatura Direccin Nota Crditos
Jos Prez Base de datos I Bolvar 180. Pueblo Libre 18 3
Luis Adonis Base de datos I Junn 300. Jess Mara 16 3
Jos Prez Anlisis de Sistemas Bolvar 180. Pueblo Libre 19 4
Lucas Len Organizacin y Mtodos Quiones 780. San Miguel 17 2
Alumno Asignatura Distrito Nota Distancia
Jos Prez Base de datos I Pueblo Libre 18 200
Luis Adonis Base de datos I Jess Mara 16 100
Jos Prez Anlisis de Sistemas Pueblo Libre 19 200
Lucas Len Organizacin y Mtodos San Miguel 17 300
60

MATRICULA

Se observa que la relacin no esta en 1FN, porque el atributo telfono es multivalorado
(permite varios valores).
Las siguientes relaciones si estn en 1FN:
MATRICULA

MATRICULA

8.3.2 Segunda Forma Normal (2FN)
Un esquema o relacin (tabla) est en 2 FN, si y slo si est en 1 FN y sus atributos no
primarios dependen completamente de la clave primaria.

MATRICULA

Se observa que Alumno y Asignatura forman la clave primaria compuesta, mientras que
Direccin y Nota son atributos no primarios (no forma parte de la clave primaria).
Adems, (Alumno, Asignatura) ==> Nota es una dependencia funcional completa.
Pero, (Alumno, Asignatura) Direccin no es una dependencia funcional completa, porque
Alumno Direccin (Direccin solo depende de Alumno).
Por lo tanto: La relacin MATRICULA, no esta en 2FN, porque, hay atributos no primarios que
no depende completamente de la clave primaria.

Alumno Asignatura Distrito Telfonos
Jos Prez Base de datos I Pueblo Libre 4519089, 93009877
Luis Adonis Base de datos I Jess Mara 5490878
Lucas Len Organizacin y Mtodos San Miguel 9876523, 8762552
Alumno Asignatura Distrito Telfono1 Telfono2
Jos Prez Base de datos I Pueblo Libre 4519089 93009877
Lucas Len Organizacin y Mtodos San Miguel 9876523 8762552
Alumno Asignatura Distrito Telfono
Jos Prez Base de datos I Pueblo Libre 4519089,
Jos Prez Base de datos I Pueblo Libre 93009877
Lucas Len Organizacin y Mtodos San Miguel 9876523
Lucas Len Organizacin y Mtodos San Miguel 8762552
Alumno Asignatura Direccin Nota
Jos Prez Base de datos I Bolvar 180. Pueblo Libre 18
Luis Adonis Base de datos I Junn 300. Jess Mara 16
Jos Prez Anlisis de Sistemas Bolvar 180. Pueblo Libre 19
Lucas Len Organizacin y Mtodos Quiones 780. San Miguel 17
61

MATRICULA ALUMNO

8.3.3 Tercera Forma Normal (3FN)
Un esquema o relacin (tabla) est en 3 FN, si y slo si est en 2 FN y ninguno de sus
atributos no primarios depende transitivamente de la clave primaria. Es decir no hay
dependencias funcionales transitivas.
Por ejemplo, consideremos la siguiente relacin cuya clave primaria es Alumno:
ALUMNO

Se observa que: Alumno Distrito, Distrito --/ Alumno (no determina funcionalmente), y
Distrito Distancia, eEntonces, Alumno --- distancia (Alumno determina
transitivamente a distancia).

Por lo tanto: la relacin ALUMNO, no est en 3FN.

ALUMNO DISTRITO

8.4 Proceso de Normalizacin
La normalizacin involucra varias fases que se realizan en orden. La realizacin de la 2da fase
supone que se ha concluido la 1ra y as sucesivamente. Tras completar cada fase se dice que la
relacin esta en: Primera Formal Normal (1FN), Segunda Forma Normal (2FN) o Tercera Forma
Normal (3FN), en ese orden.
Para ejemplificar el proceso de normalizacin, consideremos la siguiente relacin, que muestra
los datos asociados a los pedidos de productos realizados por los clientes de una determinada
compaa:
Alumno Asignatura Nota Alumno Direccin
Jos Prez Base de datos I 18 Jos Prez Bolvar 180. Pueblo Libre
Luis Adonis Base de datos I 16 Luis Adonis Junn 300. Jess Mara
Jos Prez Anlisis de Sistemas 19 Jos Prez Bolvar 180. Pueblo Libre
Lucas Len Organizacin y Mtodos 17 Lucas Len Quiones 780. San Miguel
Alumno Edad Distrito Distancia
Jos Prez 15 Pueblo Libre 200
Luis Adonis 20 Jess Mara 100
Jos Prez 15 Pueblo Libre 200
Lucas Len 18 San Miguel 300
Alumno Edad Distrito Alumno Distancia
Jos Prez 15 Pueblo Libre Pueblo Libre 200
Luis Adonis 20 Jess Mara Jess Mara 100
Jos Prez 15 Pueblo Libre Pueblo Libre 200
Lucas Len 18 San Miguel San Miguel 300
62

PEDIDO_DE_PRODUCTOS

ID_PEDIDO FECHA ID_CLIENTE NOMCLI ID_PROD NOMB_PROD CANT
123 23/11/2008 010 E.METALICAS
P2
P9
COMPAC
PLANILLA
MTO ANUAL
20
5
1
246 13/10/2008 020 M.SOLDADURA
P2
P9
COMPAC
MTO ANUAL
10
1
280 5/12/2008 010 E.METALICAS
P8
P12
MTO ANUALP
LOTUS
1
5

El anlisis de la organizacin de datos en esta tabla de pedido de productos nos permite
observar las siguientes anomalas que se presentan cuando se realizan operaciones de
actualizacin:
Si se desea registrar a un nuevo cliente, se tendra que registrar, como consecuencia,
un pedido ficticio. Es decir, no se puede registrar a un cliente sin un pedido.
Si se desea actualizar algn dato de un cliente, se tendra que actualizar, como
consecuencia, en mas de una fila.
Si se desea anular un pedido de un cliente, se tendra, como consecuencia la
eliminacin del cliente.
Estas anomalas corresponden a un mal diseo, procedamos a normalizar para evitar estas
anomalas.
8.4.1 Pasando a 1FN
La relacin PEDIDO_DE_PRODUCTOS no est en 1FN. Para pasar a 1FN, despus de verificar
que existan repeticiones de valores en algn atributo, debe descomponerse la relacin en dos
relaciones:
Una que contenga los atributos sin repeticiones y
Otra que contenga repeticiones; si en esta ultima relacin existe la necesidad de un
atributo adicional para tener una llave nica, entonces, incorporar la llave de la otra
relacin.
Por ejemplo, la relacin PEDIDO_DE_PRODUCTOS, se descompone en dos relaciones: PEDIDO
(con los atributos sin repeticiones) y DETALLE_PEDIDO (con las repeticiones), como se muestra
a continuacin:
PEDIDO

ID_PEDIDO FECHA ID_CLIENT
E
NOMBRE_CLI
123 23/11/200
8
010 E. METALICAS
246 13/10/200
8
020 M .SOLDADURA
280 5/12/2008 010 E. METALICAS
63

DETALLE_PEDIDO

ID_PEDIDO ID_PRODUCTO NOMBRE_PROD CANT
123 P2 LIC. CONTA 20
123 P4 LIC. PLAN 5
123 P9 MTO. ANUAL 1
246 P9 MTO ANUAL 1
280 P8 MTO ANUAL X 1
280 P12 LOTUS 5

8.4.2 Pasando a 2FN
Una vez asegurados que la relacin esta en 1FN, se debe preguntar si la LLAVE de la relacin
NO ES CONCATENADA, entonces, estar en 2FN.
Si la llave es concatenada, preguntarse por cada atributo NO PRIMO si depende totalmente de
la llave.
Para aquellos atributos que dependen de un subconjunto de la llave (o parcialmente de la
llave) deber formarse una nueva relacin que precisamente tenga como llave este
subconjunto.
Por ejemplo, la relacin PEDIDO tiene llave no concatenada, entonces, esta en 2FN.
En cambio, la relacin DETALLE_PEDIDO si tiene llave concatenada:
DETALLE_PEDIDO
ID_PEDIDO ID_PRODUCTO NOMBRE_PROD CANT
123 P4 LIC. PLAN 5
123 P9 MTO. ANUAL 1
246 P9 MTO ANUAL 1
280 P8 MTO ANUAL X 1
280 P12 LOTUS 5

Observamos que NOMBRE_PROD depende de ID_PRODUCTO, (Hay dependencia parcial),
entonces, no esta 2FN. Procedemos a formar otra relacin que tendr como llaves este
subconjunto, a esta nueva relacin le llamamos PRODUCTO, como se muestra a continuacin:
PRODUCTO
ID_PRODUCTO NOMBRE_PROD
P2 LIC. CONTA
P4 LIC. PLAN
P9 MTO. ANUAL
P2 LIC. CONTA
P9 MTO ANUAL
P8 MTO ANUAL X
P12 LOTUS

64

Y la relacin DETALLE_PEDIDO quedar como sigue:
DETALLE_PEDIDO
ID_PEDIDO ID_PRODUCTO CANT
123 P2 20
123 P4 5
123 P9 1
246 P2 10
246 P9 1
280 P8 1
280 P12 5

8.4.3 Pasando a 3FN
Una vez asegurados que la relacin esta en 2FN, se debe preguntar si cada uno de los atributos
que no son parte de la llave, dependen directamente de ella.
Para aquellos atributos que no dependan directamente de la llave, se debern formar una
relacin con estos datos adjuntando como llave primaria, precisamente, al atributo a travs
del cual dependen indirectamente de la llave primaria de la relacin.
Por ejemplo, en la relacin PEDIDO, que se muestra abajo, el atributo no primo NOMBRE_CLI
depende de la llave ID_PEDIDO, pero indirectamente a travs del dato ID_CLIENTE, por tanto,
no esta 3FN.
PEDIDO

Para pasar a 3FN, deber formarse una NUEVA relacin con este dato. Esta relacin deber
tener como llave a ID_CLIENTE. A esta nueva tabla le llamamos CLIENTE:

CLIENTE

Y la relacin PEDIDO quedara como sigue:
PEDIDO

ID_PEDIDO FECHA ID_CLIENTE NOMBRE_CLI
123 23/11/2008 010 E. METALICAS
246 13/10/2008 020 M .SOLDADURA
280 5/12/2008 010 E. METALICAS
ID_CLIENT
E
NOMBRE_CLI
010 E. METALICAS
020 M .SOLDADURA
010 E. METALICAS
ID_PEDIDO FECHA ID_CLIENT
E
123 23/11/200
8
010
246 13/10/200
8
020
280 5/12/2008 010
65

Finalmente, el esquema normalizado es:
CLIENTE (ID_CLIENTE, NOMBRE_CLI)
PEDIDO (ID_PEDIDO, FECHA, ID_CLIENTE)
PRODUCTO (ID_PRODUCTO, NOMBRE_PROD)
DETALLE_PEDIDO ( ID_PEDIDO, ID_PRODUCTO, CANTIDAD) .

8.5 Normalizacin Avanzada
Con las tres formas normales bsicas se pueden realizar diseo adecuados de base de datos
relacionales. Sin embargo, hay casos especiales que requieren otras reglas de normalizacin,
estas son: la Forma Normal de Boyce-Codd (FNBC), la Cuarta (4FN) y la Quinta Forma (5FN).
8.5.1 Forma Normal de Boyce-Code (FBNC)
Para definir la FNBC es preciso, previamente, definir el concepto de Determinante- Un
Determinante es cualquier atributo o conjuntos de atributos del cual depende funcional y
completamente cualquier otro atributo.
Una relacin est en la forma normal de Boyce-Codd si y solo si, todo determinante es una
clave candidata. Esta forma normal en realidad aade la restriccin para que cada columna
que no forma parte de la clave principal deba depender de toda la clave principal
La violacin de la (FNBC) es poco frecuente ya que se da bajo ciertas condiciones que
raramente se presentan. Se debe comprobar si una relacin viola la (FNBC) si tiene dos o ms
claves candidatas compuestas que tienen al menos un atributo en comn. Una relacin que
este en (FNBC) est tambin en 1FN, 2FN y 3FN
8.5.2 Cuarta Forma Normal (4FN)
La 4FN aborda los problemas que se surgen cuando existen dependencias de conjuntos de
entidades. La regla de normalizacin (4FN) est basada en la eliminacin de las relaciones de
un tipo especial de dependencias multivaloradas, las cuales fueron consideradas por primera
vez por Fagin (1977).
8.5.3 Quinta Forma Normal (5FN)
La quinta forma normal resuelve un problema en el que una tabla no se puede descomponer
en dos tablas sin perder informacin, pero si puede descomponer en ms de dos tablas.
En una relacin r puede estar presente un caso especial de dependencias llamadas
dependencias de reunin, las cuales son la base de aplicacin de (5FN). Las dependencias de
reunin son difciles de detectar, por lo tanto la aplicacin de esta regla de normalizacin no es
muy usual. Adems hay que ver si se mejora o no la aplicacin, pues se adiciona una cierta
complejidad al esquema por el nmero de relaciones nuevas que se introduce.

66

Resumen
El modelo relacional es un modelo de datos lgico. Los datos son representados como tablas.
Una relacin o tabla es un conjunto de filas y columnas. Cada fila es un conjunto de atributos
(esquema o cabecera de la relacin). El estado o contenido de la relacin es el conjunto de filas.
El dominio de un atributos es el conjunto de valores que el atributo puede tomar.
La Clave Candidata es un conjunto no vacio de atributos que identifican univoca y
mnimamente cada tupla que cumple un esquema de relacin.
Una Clave Primaria (Primary Key) es una clave candidata elegida, mediante algn criterio, para
este fin.
Una Clave Fornea (Foreign Key) es una combinacin de atributos cuyos valores estn basados
en los valores de la clave primaria de otra tabla o de la misma tabla.
La normalizacin es un proceso que permite asegurar un buen diseo de base de datos
relacionalesr.
Los pasos del proceso de normalizacin son los siguientes:
o Representar en una nica relacin todos los atributos
o Determinar las llaves candidatas y seleccionar la llave primaria
o Aplicar la 2FN
o Aplicar la 3FN
o Analizar las relaciones obtenidas para optimizarlas
Al aplicar la 2FN a una relacin, puede ser necesario crear varias tablas, ya que puede haber
diferentes conjuntos de atributos no llaves que dependan, cada uno, de diferentes
subconjuntos de la llave primaria y, por lo tanto, habr que hacer una tabla por cada
subconjunto diferente de la llave primaria que determine a los distintos conjuntos de atributos
no llaves. Los subconjuntos de la llave primaria pueden ser simples o compuestos.
Al aplicar la 3FN pueden derivarse tambin varias tablas, si hay distintos conjuntos de atributos
no llaves que dependen transitivamente de la llave primaria a travs de diferentes atributos ( o
conjunto de atributos) no llaves primarias
Al aplicar la normalizacin a un determinado fenmeno, puede ocurrir que no haya que aplicar
una determinada forma normal, es decir puede ocurrir que, al encontrar bien la llave y por lo
tanto tener la relacin en 1FN, ya este tambin en 2 FN o que, al llevar una relacin a 2 FN, ya
este tambin en 3 FN.
Puede haber varias llaves candidatas para una relacin. De estas, se escoge como llave
primaria, en general, la que resulte ms cmoda para trabajar
Al aplicar la normalizacin a una relacin que tiene ms de una llave candidata,
independientemente de la llave primaria que se haya escogido, se obtienen modelos de datos
equivalentes.
Puede ocurrir que, aplicar la 3FN a una relacin, alguna de las que se deriven de ella no est
aun en 3FN y, entonces es necesario aplicar nuevamente la 3FN a esta relacin resultante.
En la mayora de casos, bastara con normalizar los datos hasta FNBC, tambin deber tener en
cuenta algunas de nuestras advertencias o recomendaciones vertidas en esta unidad.

67

Actividades
1. Transformar los siguientes MER a MR

a)

b)

(1,n)
(1,1)
(1,n) (1,n)
(1,1)
(1,n)
(0,n)
(0,n)
(1,1)
(0,n)
DIRECTOR
PELICULA ACTOR
EJEMPLAR
SOCIO
DIRIGE PARTICIPA
TIENE
AVAL
SOLICITA
nombre Nacionalidad
Sexo
Titulo
Productora
Ao
Nombre Nacionalidad
Sexo
Numero
Estado
FecSolicitud
FecDevolucion
DNI
Nombre Direccin
(1,1)
(1,n)
(0,1)
(0,1)
(0,1)
(1,n) (0,n)
EMPLEADO
DEPARTAMENTO
ADMINISTRATIVO
TECNICO PROYECTO
PERTENECE
S
TRABAJA
Codigo
Nombre
Direccin CodDepto NomDepto
FecAsignacin FecCese
Numero
Nombre
FecInicio
FecCese
Nivel
68

c)

(1,n)
(1,1)
(1,1)
(0,n)
(1,n)
(1,n)
(0,1)
(0,n)
DEPARTAMENTO
EMPLEADO
RECURSO
BENEFICIARIO
ASIGNADO
E
TIENE
CONSUME
Codigo Nombre
SUPERVISA
Codigo
Estudios
Nombre
Direccin
Parentesco
Nombre
FecNacimiento
Sexo
Cantidad
CodRecurso Descripcin
69

1. Codd, E.F. (1970) "A Relational Model of Data for Large Shared Data Banks")
Communications of the ACM, Vol 13 Num. 6.
2. Fagin R. (1977) Multi-Valued Dependencies and a New Normal Form for relationa data
bases. ACM TODS 2 . No 3 (Septiembre)
3. Korth, H., Silberschatz, A., Sudarschan, S. (2002) Fundamentos de base de datos. 4ta. Ed.
Madrid. McGrawHill/Interamericana.

70

GLOSARIO
1. DBA: Data Base Administrator, persona responsable de la confidencialidad, disponibilidad,
seguridad e integridad de los datos almacenados en la base de datos; vigila el buen
funcionamiento del sistema de base de datos.
2. DBMS: Data Base Management System, Sistema de Gestin de de Base de Datos
3. Arquitectura ANSI/x3/SPARC: Arquitectura de tres niveles (externo, conceptual e interno)
que permite la independencia de datos.
4. SQL: Structured Query Language, Lenguaje de Consultas estructurado, formado por DDL,
DML y DCL.
5. DDL: Data Definition Language, Lenguaje de definicin de datos
6. DML: Data Manipulation Language, Lenguaje de manipulacin de datos
7. DCL: Data Control Language, Lenguaje de Control de los datos

71

BIBLIOGRAFA GENERAL
1. ANSI (1977): The ANSI/X3/SPARC DBMS Framework. Report on the Study Group on
Database Management Systems. D. Tsichiritzis y A. Klug (eds). Montvalle, N.J.: AFIP Press.
2. Booch, G., Rumbaugh, J. y Jacobson, I. (1999) El lenguaje unificado de modelado.
Madrid: Addison Wesley,
3. Chen, Peter (1976), The entety-relationship model:Towards a unified view of data. ACM
Trans.Sistemas de bases de datos 1 (1) 9-36
4. Codd, E.F. (1970) "A Relational Model of Data for Large Shared Data Banks")
Communications of the ACM, Vol 13 Num. 6.
5. Connolly, Thomas y Begg, Carolyn. (2008) Database Solutions. 5ta. Ed. Madrid. Addison
Wesley.
6. Date, C. (1995) An introduction to data base systems. 5ta. Ed. Massachusetts Addison
Wesley.
7. De Miguel A. y Piattini M., (1999) Fundamentos y Modelos de Base de datos. 2da. Ed.
Madrid. Alfa y Omega.
8. Elmasri, Ramez y Shamkant Navathe (1997) Sistemas de Bases de Datos. Conceptos
fundamentales. Segunda Edicin. Madrid. Addison-Wesley Iberoamericana.
9. Fagin R. (1977) Multi-Valued Dependencies and a New Normal Form for relationa data
bases. ACM TODS 2 . No 3 (Septiembre)
11. Korth, H. y otros (2002) Fundamentos de base de datos. 5ta. Ed. Madrid. MacGrawHill.
12. Kroenke, D. (2003) Procesamiento de base de datos. Fundamentos, diseo e
implementacin. 8va. Edicin, Mexico. Pearson Educacion.
13. Martin, James. (1975) Computer Data Base Organization. New Jersey. Prentice Hall.

Manual Prof - Luza PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Manual Prof - Luza PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Modelado y Diseo de Base de datos Csar Luza Montero

S-ar putea să vă placă și