TABLA DE CONTENIDO

1. BREVE HISTORIA DE LAS BASES DE DATOS

2. QUE ES UNA BASE DE DATOS?

3. LA INFORMACIN COMO RECURSO CORPORATIVO

Ventajas y Desventajas de un Sistema de Bases de Datos

Funciones de un Sistema Gestor de Bases de Datos

7
7

4. NIVELES DE ABSTRACCIN DE UNA BASE DE DATOS

5. PROCESO DE DESARROLLO DE UNA BASE DE DATOS

11

6. LAS BASES DE DATOS Y EL DESARROLLO DE APLICACIONES

13

7. MODELAMIENTO CONCEPTUAL DE DATOS

15

8. ENTIDADES

17

9. RELACIONES

19

10.

MATRIZ DE RELACIONES

22

11.

LOS ATRIBUTOS

23

12.

IDENTIFICADORES UNICOS

25

13.

LA NORMALIZACIN

29

14.

RELACIONES JERRQUICAS

34

15.

RELACIONES RECURSIVAS

35

16.

GENERACIONES DE BASES DE DATOS

38

1.

Conceptos Bsicos

Claudia

Jimnez

Ramrez

Bases

de

Datos

LA INFORMACIN COMO RECURSO

CORPORATIVO
En los ltimos tiempos, se ha empezado a considerar la informacin como
un recurso estratgico de una organizacin; pues le facilita su supervivencia
y le permite, adems, ser competitiva en el mercado. Tambin le permite
anticiparse a los cambios futuros y adaptarse mucho ms rpidamente a
ellos.
De la informacin que una organizacin almacene y de cmo est
organizada esta informacin, dependen cules preguntas se pueden
formular acerca de su gestin actual o pasada, tanto internamente
como en el entorno.
El tratamiento estadstico con datos histricos es factor clave en el
futuro de la organizacin y vital en su planeacin.
La calidad y oportunidad de las decisiones a todos los niveles
depende en gran medida de hacer llegar la informacin correcta en el
momento adecuado, a las personas que la necesitan.
La informacin se debe considerar como otro recurso corporativo de la
misma manera que se considera el recurso humano o los recursos fsicos.
Por lo tanto, la administracin de la informacin debe implicar:
a) Planear su adquisicin por anticipado.
b) Conseguirla y guardarla antes de necesitarla.
c) Protegerla contra la destruccin o el mal uso.
d) Asegurar su calidad.
e) Retirarla de la organizacin cuando ya no se la requiera.
f) Asignarle un responsable.

2. Breve historia de las bases de datos

La cantidad de informacin que debe manejar una organizacin para
sobrevivir es cada vez mayor. Para ello, deben existir mtodos eficientes
tanto para el almacenamiento rpido como para la consulta gil. La
tecnologa que actualmente es ms utilizada para manejar grandes
volmenes de datos es la tecnologa de Bases de Datos.

Claudia

Jimnez

Ramrez

Bases

de

Datos

En los inicios de la computacin se elaboraban programas de computador a

los cuales, siempre que se ejecutaban, se les proporcionaban los datos de
entrada y no se vea la necesidad de guardar la informacin en memoria
secundaria, tanto la resultante como la de entrada, para su uso posterior.
Con el tiempo, el computador adquiere un uso ms comercial en las
empresas para llevar la contabilidad, la nmina y otras actividades. Estas
tareas, por lo general, necesitaban una serie de datos iguales para usarlos
en las diferentes corridas de los programas e implicaban un gran esfuerzo
porque haba que entrarlos nuevamente, cada vez.
Ante este problema, aparecen los Sistemas de Archivos, donde los datos se
almacenan de manera permanente para sobrevivir a los programas que los
usan; caracterstica conocida como la persistencia.
Aunque el ambiente de archivos represent un avance en su momento,
posteriormente se enfrentaron con tres problemas bsicos.
Informacin de estudiantes
en archivos
nombre, cdula, valor cancelado por matrcula, prstamos, etc.

nombre, carrera, cdula, materias, notas, telfono, etc.

nombre, carrera, nota promedio, valor prstamo, caducidad, etc.

Programas

Lenguaje
de desarrollo

Ingresos y Egresos

Registro y matrcula

Fortran

Cobol

Prstamo estudiantil
Pascal

Figura 1. Ejemplo hipottico del Sistema de Archivos

El primer problema, consiste en la alta redundancia de datos. El mismo

dato aparece repetido en varios archivos. Las diferentes versiones de un
mismo dato pueden estar con un grado de actualizacin distinto en cada
lugar. Esto, adems de aumentar los costos de almacenamiento y de
reescritura de la informacin, puede dar lugar a inconsistencias: un directivo
puede estar viendo un informe donde se muestra una cosa y viendo por
pantalla, otra.
El segundo problema es la inflexibilidad porque cuando se quiere agrupar
los datos de cierta manera no se puede hacer, debido a la organizacin
dada en los archivos que no tienen ninguna clase de vnculos o presentan
formatos diferentes; como en el ejemplo hipottico de la ilustracin 1. Esta
inflexibilidad impide resolver rpidamente consultas espontneas y aunque

Claudia

Jimnez

Ramrez

Bases

de

Datos

los datos existan, la informacin no puede proporcionarse relacionando

datos. Esta es la queja constante de los directivos; que teniendo la
informacin no tienen acceso a ella, en el momento en que la necesitan.
El tercer problema que se presenta con el sistema de archivos es el costo
de efectuar cambios en las estructuras de los datos porque al cambiar la
representacin de un dato, se necesita cambiar el programa para que lo
reciba de la nueva manera. Adems, es altamente probable que los mismos
datos se encuentren en otros archivos; entonces los cambios se propagarn
de una manera incontrolable por todos los lugares, aumentando el tiempo
que el personal especializado debe invertir en el mantenimiento de los
programas y, por ende, reduciendo el tiempo que le pudieran dedicar al
desarrollo de nuevas aplicaciones.
Uno de los objetivos de los Sistemas de Bases de Datos es tener la
posibilidad de usar los datos de nuevas maneras sin generar una reaccin
en cadena de modificaciones difciles sobre los otros programas existentes.
El propsito, pues, del ambiente de bases de datos es separar cada
programa de los efectos de los cambios a los otros programas. Tambin,
que todos los programas estn ms aislados de los efectos de reorganizar
los datos. Esta caracterstica es conocida como independencia de datos.
La tecnologa de bases de datos proporciona los medios, a las
organizaciones para que cumplan con sus objetivos de lograr mximos
beneficios (para las entidades sin nimo de lucro, a prestar un mejor
servicio) y ocupar una posicin de liderazgo por las razones que se
enumeran a continuacin.
1. Se logra el desarrollo de aplicaciones ms rpidamente porque los
programas reutilizan los datos y procedimientos almacenados en la base
de datos y con lenguajes de programacin de ms alto nivel.
2. Hay una mayor participacin del usuario final en la creacin de las
aplicaciones, haciendo el software ms tangible y de mayor valor
inmediato.
3. El acceso a los datos es flexible y rpido.
4. Se pueden generar informes y formularios de pantalla sin la
programacin convencional.
5. El usuario final puede, l mismo, extraer la informacin que necesita y
crear nuevos tipos de datos.

Claudia

Jimnez

Ramrez

Bases

de

Datos

En otras palabras, permite a las organizaciones implantar el justo a tiempo

para tener mejor y mayor informacin para la toma de decisiones e
incrementar su productividad.

3. DEFINICION DE UNA BASE DE DATOS

Es una coleccin de datos (actualmente, tambin de procedimientos o
funciones) almacenados de una manera permanente, que pueden ser
compartidos y usados con variados propsitos por mltiples usuarios.
Un usuario determinado no tiene que ver todos los datos de la base de
datos, slo aquellos que necesita o est autorizado para poder cumplir con
sus funciones dentro de una organizacin.
No todos los usuarios perciben los datos de la misma manera, a pesar de
que puedan ser extrados de la misma base de datos. Por ejemplo, la fecha
de compra de un artculo puede ser vista por el asistente de mercadeo con
un formato que no incluye la hora; mientras que el jefe de bodega s
necesita verla porque, para l, es informacin valiosa.
Sin embargo, se debe sealar, que la consecucin del objetivo de integrar
toda la informacin de una organizacin para evitar redundancias, esencial
para superar las limitaciones de los sistemas de archivos, a su vez, puede
generar nuevos problemas o dificultades que se deben resolver. Entre ellos,
est el problema del trabajo concurrente o simultneo de un grupo de
usuarios o aplicaciones sobre las mismas piezas de informacin y tambin el
problema de la seguridad.
Los usuarios de una base de datos se pueden clasificar en tres categoras:
el usuario final que interacta con la base de datos, por lo general, a
travs, de las aplicaciones, el usuario especialista que es el que disea y
programa las aplicaciones para los usuarios finales y, por ltimo, la persona
encargada de administrar la base de datos llamada en forma abreviada DBA
(database administrator).
No obstante, cualquier persona con cargos administrativos, ingeniero o
profesional cuyo trabajo sea cambiado por los sistemas de bases de datos
debera entender los principios de esta tecnologa y lo que ello involucra.

Claudia

Jimnez

Ramrez

Bases

de

Datos

3.1 Ventajas y Desventajas de un Sistema de Bases de Datos

3.1.1

Ventajas

1. Economa de escala: esencialmente, la concentracin de aplicaciones

en una sola localidad puede reducir costos: menos cantidad de
personas especializadas, en software, etc.
2. Se puede obtener mayor informacin de la misma cantidad de datos:
existe una mayor facilidad para el anlisis y la toma de decisiones.
3. Datos y programas compartidos: la reutilizacin de los mismos datos y
programas, permiten minimizar o controlar la redundancia.
4. Incentiva la adopcin de estndares.
5. Consistencia de los datos: est dada por el control o eliminacin de la
redundancia.
6. Integridad: el DBMS debe velar por el grado de validez y de correccin
de los datos. Debe permitir definir reglas que deben cumplir los datos,
en la base de datos. Por ejemplo, que el departamento asociado a un
profesor sea uno de los existentes en la Universidad.
7. Seguridad: se pueden especificar niveles de acceso con una
granularidad ms fina, segn los perfiles de los usuarios.
8. Flexibilidad y oportunidad: El uso de lenguajes de cuarta generacin
hacen ms fcil la construccin de los programas por parte de los
usuarios finales.
9. Mayor productividad de los programadores. Las aplicaciones nuevas
pueden desarrollarse en la mitad del tiempo, o menos, que con los
sistemas de archivos tradicionales debido al uso de lenguajes de
tercera generacin.
10.Facilidades para el mantenimiento y reingeniera: se puede cambiar la
estructura de los datos sin cambiar los programas que los usan.
3.1.2

Desventajas

1. Tamao: Un DBMS es un gran conjunto de programas.

2. Mayor susceptibilidad a las fallas: ms cantidad de huevos en una
sola canasta.
3. Recuperacin a las fallas: la recuperacin de un DBMS interactivo y
multiusuario puede ser muy compleja.
Funciones de un Sistema Gestor de Bases de Datos
Un sistema gestor de bases de datos (DBMS o Database Management
System) es el software que sirve de intermediario entre el usuario y la base
de datos. Tiene las siguientes funciones:

Claudia

Jimnez

Ramrez

Bases

de

Datos

1. Interactuar en forma transparente con el manejador de archivos del

sistema operativo para la actualizacin, almacenamiento y recuperacin
de los datos. El usuario, a excepcin del DBA, no debera preocuparse
por las estructuras internas o por los procedimientos usados para
manipularlos.
2. Optimizar la bsqueda de la informacin.
3. Ofrecer un catlogo asequible por el usuario (autodescriptivo). Un DBMS
debe ser capaz de responder a preguntas sobre:
i) Los elementos que conforman la estructura de la base de datos.
ii) Las caractersticas de los atributos o campos (i.e longitud, tipo de
datos)
iii) Las restricciones.
iv) Los significados de los elementos o datos.
v) Cules programas usan cules datos y cmo los usan.
4. Manejo de transacciones: para asegurar que todas las actualizaciones se
hagan todas o ninguna. Una transaccin es una secuencia de pasos para
cumplir una tarea, segn el punto de vista del usuario final.
5. Controlar el acceso concurrente o simultneo a los mismos datos para
que no existan conflictos por las peticiones de los usuarios o
aplicaciones.
6. Servicios de recuperacin ante fallas.
i) Permitir hacer respaldos totales o parciales de la base de datos.
ii) Creacin y mantenimiento de archivos log de transacciones o
bitcoras; que deben ser actualizados antes que los datos mismos.
iii) Incluye la identificacin de la transaccin, hora y fecha de la
misma.
iv) Archivos de imgenes anteriores y posteriores.
v) Permitir la devolucin de la base de datos a un estado correcto
conocido.
7. Poner en prctica la seguridad para impedir el acceso a los datos a los
usuarios no autorizados mediante:
i) El encriptamiento de la informacin.
ii) Los subesquemas o vistas
iii) Privilegios o reglas de autorizacin: sujeto, objeto, accin y
restriccin.
iv) Procedimientos definidos por el usuario que pueden aumentar la
seguridad.
8. Implantar mecanismos para preservar la integridad de los datos mediante
la especificacin con:
i) Tipos de datos
ii) Valores vlidos
iii) Formatos y valores por defecto

Claudia

Jimnez

Ramrez

Bases

de

Datos

iv) Restricciones
9. Servicios para promover la independencia de datos.
10.Otros servicios utilitarios para la administracin de los datos.
De lo recin expuesto, se puede apreciar que un sistema gestor de bases
de datos debe realizar muchas tareas bastante complejas y de ah su
tamao y costo.
No obstante, en el mercado se pueden encontrar una gran variedad de
sistemas gestores de bases de datos con precios muy dismiles y una de las
razones se debe a que no todos ellos cumplen con las funciones que se
acaban de mencionar.
Funcionamiento de un DBMS

Anlisis sintctico

Error

Verificacin de
privilegios y de la
existencia de los
objetos en la base de
datos

Diccionario
de datos

Optimizacin de la
consulta
Base de
datos

Bitcora
Manejo de
Transacciones

Administracin del
almacenamiento

4. Niveles de abstraccin de una base de datos

La manera cmo percibimos la base de datos, segn seamos usuarios
finales, especialistas o administradores, corresponde con un nivel de
abstraccin.

Claudia

Jimnez

Ramrez

Bases

de

Datos

1 0

Por lo anterior, la ANSI/SPARC ha propuesto una arquitectura considerando

tres niveles de abstraccin.

Los niveles son tres:

Nivel de visin
(vistas parciales)

Nivel conceptual
(vista comunitaria)

Nivel fsico
(almacenamiento)
1. El nivel de visin o externo es el ms cercano a los usuarios, esto
significa que se ocupa de la forma cmo los usuarios individuales
perciben la base de datos. A diferencia de los otros dos niveles, existen
mltiples maneras de percibir la base de datos a este nivel; tantas como
grupos de usuarios finales existan en la empresa. Toda vista externa de
la base de datos, se define mediante subesquemas.
2. El nivel conceptual es el nivel mediador entre el nivel fsico y el de visin,
se ocupa de cules son los datos reales almacenados en la base de
datos y de las relaciones existentes entre ellos. Este nivel, es de inters
primordialmente para el usuario especialista. El esquema lgico,
correspondiente con este nivel de abstraccin, est conformado por la
descripcin semntica de los datos que conforman la base de datos.
3. El nivel fsico o interno es el ms cercano a la mquina, es decir, es el
que se ocupa de la forma como se almacenan los datos fsicamente en la
memoria secundaria. El nivel fsico de la base de datos interesa al
administrador y al usuario especialista. La descripcin de este nivel de
abstraccin se le denomina esquema fsico y est conformado por la
descripcin de los datos, sus tipos, su tamao y dominio de acuerdo con
un DBMS particular.

Claudia

Jimnez

Ramrez

Bases

de

Datos

1 1

Independencia de datos: es una caracterstica de las bases de datos que

permiten modificaciones en la definicin de un esquema sin afectar, en la
medida de lo posible, la reescritura del esquema inmediatamente superior.
Independencia fsica: cuando un cambio en el esquema fsico no conduce
a efectuar cambios en el esquema lgico.
Independencia lgica: cuando un cambio en el esquema lgico no conlleva
a un cambio en el nivel de visin. Este tipo de independencia es ms difcil
de lograr que la independencia fsica.

5. Proceso de desarrollo de una base de datos

El desarrollo de una base de datos, es una tcnica arriba-abajo que
transforma los requerimientos de informacin en una base de datos en
funcionamiento.
REQUERIMIENTOS DE INFORMACIN DE LA ORGANIZACIN

Estrategia
Anlisis

Diseo
Conceptual de
la Base de Datos
Modelo Entidad-Relacin

Diseo

Construccin

Diseo lgico
de la Base de
Datos

Tablas, ndices, Vistas,

Clsteres, Definiciones de
espacios

Implementacin
de la Base de Datos

El diseo conceptual parte de la especificacin de requerimientos y su

resultado es el esquema conceptual, cuyo propsito es describir el contenido
de informacin de la base de datos, ms que las estructuras de
almacenamiento que se necesitarn para manejar la informacin. Es una
descripcin de alto nivel que es completamente independiente del software
de DBMS que se use, incluso si se pensara en implementar con archivos
tradicionales y con algn lenguaje de programacin convencional.

Claudia

Jimnez

Ramrez

Bases

de

Datos

1 2

El diseo lgico parte del esquema conceptual y da como resultado el

esquema lgico. El esquema lgico es una descripcin de la estructura de la
base de datos que puede procesar el software DBMS. El modelo lgico ms
usado actualmente, es el modelo relacional que ha sido enriquecido con los
modelos orientados por objetos. El modelo lgico no depende del DBMS en
particular, sino del modelo de datos usado por el DBMS.
El diseo fsico parte del esquema lgico y da como resultado un esquema
fsico. Es una descripcin de cmo est almacenada la base de datos en la
memoria secundaria; describe las estructuras de almacenamiento y los
mtodos usados para tener un acceso efectivo a los datos. Los esquemas
lgicos y fsicos se expresan haciendo uso del lenguaje de definicin de
datos del DBMS elegido; la base de datos se crea y se carga, y puede ser
probada. Lo mismo, puede probarse las aplicaciones sobre la base de datos
y de este modo la base de datos se vuelve operacional.

Claudia

Jimnez

Ramrez

Bases

de

Datos

1 3

6. LAS BASES DE DATOS Y EL DESARROLLO DE APLICACIONES

El proceso de desarrollo de la base de datos est estrechamente acoplado

con el proceso de desarrollo de aplicaciones:

Requerimientos de la organizacin

REQUERIMIENTOS DE INFORMACION

REQUERIMIENTOS DE APLICACIONES

Estrategia
Modelamiento
Conceptual de

Chequeos Cruzados

Anlisis

Modelo Entidad-Relacin

Diseo

Diseo de la
Base de Datos

Chequeos Cruzados

Tablas, Indices, Vistas,

Clusters, Definiciones de
espacios
Construccin

Construccin
de la Base de
Datos

Modelamiento
de
Funciones

Modelo Jerrquico
Def de Funciones
DFDs
Diseo de las
Aplicaciones

Diseo de mdulos

Construccin de
las aplicaciones

APLICACIONES EN OPERACIN

BASE DE DATOS EN OPERACIN

SISTEMA EN OPERACIN

Figura 2 Acoplamiento de la visin orientada a los datos y a las aplicaciones

Un enfoque alternativo en el diseo de los sistemas informticos llamado

orientado a las funciones se desarroll en la dcada de 1960 consiste en
centrarse en las aplicaciones y no en los datos.

Claudia

Jimnez

Ramrez

Bases

de

Datos

1 4

El anlisis funcional parte de los requerimientos de aplicaciones que

describen las actividades y los flujos de informacin dentro de una
organizacin para llegar a una especificacin formal de los procesos y
considera los archivos de datos depsitos de informacin aislados, utilizados
por cada actividad o intercambiados entre ellas; se pierde la visin de la
informacin como recurso corporativo de la organizacin.
Los enfoques orientados a los datos y a las funciones para el diseo de
sistemas informticos son complementarios, ambos proporcionan
caractersticas relevantes y se deben relacionar ntimamente como se
muestra en la ilustracin 2.
Lo anterior, tambin ha originado un el enfoque llamado orientado a objetos
donde se determinan los objetos del dominio del mundo real relevantes en la
solucin del problema, con sus caractersticas y comportamiento y de esta
manera juntar los dos enfoques anteriores.
Independiente del enfoque utilizado, la tarea ms difcil en el proceso de
desarrollo de una base de datos es determinar los datos necesitados por los
usuarios, representarlos en la base de datos y asegurar que ellos son, en
verdad, usados apropiadamente. Esto se dificulta, an ms, debido a los
diferentes nombres que los usuarios dan a un mismo dato, o por el contrario,
el mismo nombre para distintos datos.
De lo expuesto, nace la necesidad adicional de la creacin de un diccionario
de datos donde cada trmino es definido segn el lenguaje de la empresa,
buscando una estandarizacin para los datos y un significado preciso para
cada palabra.

Claudia

Jimnez

Ramrez

Bases

de

Datos

1 5

7. MODELAMIENTO CONCEPTUAL DE DATOS

Los modelos de datos son usados para describir la realidad. Los
diseadores usan los modelos de datos para construir esquemas que son
representaciones de la realidad. La calidad de los esquemas resultantes
depender, no slo del modelo elegido, sino tambin de la habilidad del
analista.
Un modelo de datos es una serie de conceptos que se utilizan para describir
un conjunto de datos y de operaciones para manipular los mismos. Cuando
un modelo de datos describe un conjunto de conceptos de una realidad se
llama modelo conceptual.
El bloque de construccin comn a todos los modelos conceptuales de
datos es una pequea coleccin de mecanismos de abstraccin:
clasificacin (agrupacin de una clase de objetos con caractersticas
comunes), agregacin (una nueva clase formada por la reunin de varios
objetos) y la generalizacin o especializacin (una relacin de subconjunto
entre los elementos de dos o ms clases).
La abstraccin es un proceso mental que se aplica al seleccionar algunas
caractersticas y propiedades de un conjunto de objetos y excluir otras no
pertinentes.
En el modelamiento conceptual, se identifican las propiedades estructurales
(sobre los objetos, sus atributos y relaciones) y dinmicas (operaciones
sobre los objetos) adems de ciertas restricciones de integridad, de un
dominio de aplicacin con miras a su transformacin en un modelo de ms
bajo nivel.
Los modelos conceptuales deben ser buenas herramientas para representar
la realidad; por esta razn debe poseer, entre otras las siguientes
caractersticas:
1. Expresividad: los modelos ms ricos en conceptos son ms expresivos.
Por ejemplo, la mayora de los modelos conceptuales hacen uso
frecuente de la abstraccin de generalizacin lo que permite la
representacin de una gran variedad de restricciones de integridad.
2. Simplicidad: un modelo conceptual debe ser simple o fcil de entender
por los diseadores y por los usuarios finales. Esta propiedad y la
expresividad son objetivos en conflicto; si un modelo es semnticamente
rico, es probable que no sea simple.

Claudia

Jimnez

Ramrez

Bases

de

Datos

1 6

3. Minimalidad: esta caracterstica se consigue si ningn concepto presente

puede expresarse por otros conceptos. Con la minimalidad se persigue
que el modelo abstraiga lo esencial de la realidad, buscando la
parsimonia.
4. Formalidad: todos los conceptos deben tener una interpretacin nica,
precisa y bien definida.
Los modelos en la ingeniera del software, suelen describirse mediante
representaciones lingsticas y grficas. El xito de un modelo de datos
depende en gran medida de su representacin grfica que debe ser lo ms
completa posible (si no requiere complementarse con una representacin
lingstica) y facilidad de lectura (si cada concepto se representa con un
smbolo grfico claramente distinguible del resto).
El modelo Entidad-Relacin es el ms usado para el modelamiento
conceptual de bases de datos. Fue propuesto por Chen en 1976. En 1988,
la ANSI seleccion el modelo E-R como el modelo estndar para los
sistemas de diccionarios de recursos de informacin (IRDS, Information
Resource Dictionary Systems).
Posteriormente, el modelo fue extendido por otros autores, como Richard
Barker en la metodologa Case Method, para adicionar una mayor
semntica.
En la figura siguiente, se aprecia un ejemplo de un diagrama entidadrelacin, con la notacin de Barker.
EMPLEADO
# * carn
* nombre
asignado a
* apellido
responsable
o cargo
de
* fecha enganche
o salario
o comisin
subordinado
de
jefe
de

DEPARTAMENTO
# * nmero
* nombre
* ubicacin

Los conceptos bsicos de un modelo Entidad-Relacin son:

Claudia

Jimnez

Ramrez

Bases

de

Datos

1 7

Entidad - representa una clase de objetos de la realidad, de la que se

necesita mantener y conocer informacin.
Relacin - representa una conexin entre los objetos de una o ms
entidades.
Atributo - representa una propiedad bsica que caracteriza a una
entidad o a una relacin.
El modelo Entidad-Relacin es un medio efectivo para recopilar y
documentar los requerimientos en un formato claro y preciso. Esto es, un
marco de especificacin formal, fcil de entender por los usuarios finales,
agilizando la comunicacin entre stos y los usuarios especialistas.
El modelo E-R (Entidad-Relacin) se caracteriza, adems, porque se puede
refinar con facilidad. Proporciona un claro cuadro del alcance de los
requerimientos de informacin y sirve de base de integracin de mltiples
aplicaciones, proyectos de desarrollo y paquetes comerciales.
Es importante establecer completamente los requerimientos de informacin
de la organizacin durante la etapa de modelamiento para evitar cambios en
etapas posteriores del desarrollo, pues siempre implican costos mayores
que los que se detectan en una etapa temprana.
El modelo E-R puede ser transformado una base de datos jerrquica, en
red, relacional u orientada por objetos e, incluso, a un ambiente tradicional
de desarrollo de software. Esto es, puede ser traducido a cualquier modelo
lgico que se desee.
8. ENTIDADES
Una entidad es una clase de objetos de importancia, en el dominio del
problema, sobre la cual se debe guardar o conocer alguna propiedad.
Tambin puede definirse como una categora. Ejemplos de entidades son:
EMPLEADO
ARTICULO
TIQUETE
Las entidades pueden ser simples si son irreducibles o complejas cuando
estn formadas, a su vez, por otras entidades.

Claudia

Jimnez

Ramrez

Bases

de

Datos

1 8

Cada entidad se define por los atributos y sus relaciones que poseen. Por lo
tanto, toda entidad debe poseer dichas propiedades. Algunos atributos
posibles para la entidad EMPLEADO son: su fecha de vinculacin, el salario
y cargo.
Convenciones:
Para dibujar las entidades en el diagrama E-R se utilizan cajas, con
bordes redondeados, de cualquier dimensin.
Cada entidad lleva un nombre nico en mayscula y en singular.
Puede ir un nombre sinnimo entre parntesis. Los sinnimos son tiles
cuando dos grupos de usuarios usan diferentes nombres para referirse a
una misma entidad.
Los nombres de los atributos deben ir en minsculas.
Ejemplos:
EQUIPO
#

referencia
fabricante
marca
fecha de
compra

PROYECTO
cdigo
nombre
fecha de inicio
fecha de finalizacin

Cada entidad suele tener mltiples ocurrencias o instancias; es decir, debe

tener asociada una poblacin de objetos. Toda instancia tiene valores
especficos para los atributos de la entidad.
Cada instancia debe ser identificable de las otras instancias u ocurrencias
de la misma entidad. Un atributo o conjunto de atributos que identifican
inequvocamente a cada instancia es llamado identificador nico (IU).
Para los empleados, por ejemplo, el atributo cdula servira como
identificador nico.
Los atributos que identifican a una entidad son marcados con el smbolo #.
Para identificar y modelar las entidades de las notas de las entrevistas, se
recomiendan los siguientes pasos:

Claudia

Jimnez

Ramrez

Bases

de

Datos

1 9

1. Examinar los sustantivos presentes en la descripcin verbal de los

requerimientos de informacin. Son cosas de importancia para
considerarlos como entidades?
2. Hay informacin de inters que se deba almacenar sobre esa entidad?
3. Es identificable unvocamente cada instancia de esa entidad?
4. Elabore una descripcin de cada entidad (ser incluida en el diccionario
de datos).
5. Dibuje la entidad y colquele sus atributos.
No se debe descalificar una entidad muy rpidamente. Posteriormente,
pueden surgir atributos de inters para la organizacin sobre esa entidad.
9. RELACIONES
Una relacin es una asociacin bidireccional, significativa, nombrable entre
dos entidades, o de una entidad consigo misma. Cada relacin asocia una
instancia de cada una de las entidades involucradas en ella.
La sintaxis de una relacin, permite una lectura:
debe
una o varias
Cada entidad1 puede ser o estar nombre-relacin una y slo una entidad2
Ejemplo
La relacin entre PROFESOR y CURSO es:
Cada CURSO puede ser dictado por uno y slo un PROFESOR.
Cada PROFESOR puede ser el docente de uno o ms CURSOs.
Cada direccin de una relacin tiene ciertas caractersticas que se pueden
especificar en el modelo E-R:
Un nombre - por ejemplo dictado por, asignado a
Una opcionalidad (una cardinalidad mnima).
Un grado o cardinalidad mxima.
Para dibujar las relaciones en el diagrama E-R, se siguen las siguientes
convenciones:
Una lnea entre las entidades relacionadas.

Claudia

Jimnez

Ramrez

Bases

de

Datos

2 0

Los nombres de las relaciones se escriben en minsculas y se colocan

en los extremos de la lnea de la relacin.
La cardinalidad mnima se representa con:
Si es obligatoria (debe ser o estar)
Si es opcional (puede ser o estar)
El grado o cardinalidad mxima se representa con:
Si la relacin se puede dar con una o varias
instancias de la otra entidad
Si la relacin se puede dar slo con una y slo una
instancia de la otra entidad
Si la cardinalidad, mxima o mnima, tiene una restriccin numrica definida,
se le agrega al extremo de la lnea conectiva.
Una relacin se lee primero en una direccin, y luego en la otra direccin.
Ejemplo
Para leer la relacin entre EMPLEADO y DEPARTAMENTO:

EMPLEADO

asignado
a

DEPARTAMENTO

responsable
de

Primero se leer de izquierda a derecha:

Cada EMPLEADO debe ser asignado a un, y slo un, DEPARTAMENTO.
Ahora, si se lee de derecha a izquierda, sera como se muestra a
continuacin.
Cada DEPARTAMENTO puede ser responsable de uno o varios un
EMPLEADOs.

Existen tres tipos de relaciones, de acuerdo con su grado:

Claudia

Jimnez

Ramrez

Bases

de

Datos

2 1

De muchos a uno (n:1) que se caracteriza por tener un grado de uno o

ms en una direccin y un grado de uno y slo uno en la otra direccin.
Es una relacin frecuente.
Ejemplo
TIQUETE

comprado
por

PASAJERO

poseedor
de

De muchos a muchos (n:m) que tienen un grado de uno o ms en ambas

direcciones. Tambin es una relacin muy comn.

Ejemplo
ARRENDADOR

generador
de
originado
por

ALQUILER

Uno a uno (1:1) tiene un grado uno y slo uno en ambas direcciones.
Este tipo de relaciones es rara. Es importante tener cuidado ya que
puede que una relacin de stas entre entidades sea realmente una
misma entidad.

Ejemplo

Claudia

Jimnez

Ramrez

OPERARIO

encargado
de
manejada
por

Bases

de

Datos

2 2

MAQUINA

Todas las entidades, relaciones y atributos deben representar los

requerimientos de informacin y las reglas de la organizacin.
10. MATRIZ DE RELACIONES
Como ayuda inicial en la recoleccin de la informacin acerca de las
relaciones entre un conjunto de entidades se emplea la matriz de relaciones.
Una matriz de relaciones muestra para cada entidad fila sobre el lado
izquierdo si tiene una relacin y cmo es sta, con cada entidad columna.
Todas las entidades son listadas tanto en el lado izquierdo como en la parte
superior de la matriz. Si una entidad fila tiene una relacin con una entidad
columna, entonces se coloca el nombre de la relacin en la celda que las
intercepta. Si no existe una relacin se coloca una raya horizontal.
Cada relacin encima de la diagonal es la inversa o el espejo de una
relacin por debajo de la diagonal. Las relaciones recursivas (de una entidad
consigo misma) se representan sobre la lnea diagonal.
Ejemplo
La siguiente matriz muestra las relaciones entre cuatro entidades.
CLIENTE

ARTICULO

CLIENTE
ARTICULO
ORDEN
BODEGA

Hecha para

ORDEN
el generador
de
comprado
mediante

BODEGA

almacenado
en

Compuesta de
sitio de
almacenamiento

Una vez se tengan definidas las relaciones en la matriz, se pueden llevar al

modelo entidad-relacin.

Claudia

Jimnez

ARTICULO
cdigo
descripcin

Ramrez

comprado por

almacenado en

compuesta
de

Bases

de

Datos

2 3

ORDEN
nmero
fecha
originada por

el repositorio de

BODEGA
identificador
direccin

el originador de

CLIENTE
identificador
razn social
direccin

Debemos leer en voz alta las relaciones para validarlas y emplear la matriz
de relaciones para examinar si existe una relacin entre cada pareja de
entidades.
No se deben usar los trminos "relacionado con" o "asociado a" como
nombres de relaciones, pues estos nombres no definen cul tipo de relacin
se est modelando.
11. LOS ATRIBUTOS
Los atributos son informacin que se necesita conocer y mantener de una
entidad. Sirven para describir, identificar, cualificar, clasificar, cuantificar o
expresar un estado de una entidad.
Los atributos representan un tipo de descripcin o detalle, no una instancia;
los nombres dados a los atributos deben ser claros para el usuario y no
deben incluir el nombre de la entidad; ya que sera redundante como en el
caso de colocar cdigo de curso en la entidad CURSO.
Los nombres de los atributos deben ser especficos y completos. Esto es,
cantidad comprada, fecha de envo en vez de, nicamente, cantidad y fecha.
Las convenciones que rigen para representar los atributos en diagrama E-R,
sealan que siempre deben ir en singular y en minscula y se colocan
dentro de la caja de la entidad
Se debe descomponer un atributo hasta aquella componente mnima con
significado propio. As, el nombre de una persona debe ser descompuesto
en nombre y apellidos. Los atributos que contengan fechas no se

Claudia

Jimnez

Ramrez

Bases

de

Datos

2 4

descomponen. No obstante, el nivel de descomposicin depender de las

necesidades organizacionales.
Se debe verificar que cada atributo tenga un solo valor para cada instancia
de la entidad; pues un atributo con mltiples valores o grupos que se repiten
no son un atributo vlido, en este modelo.
Para representarlos, entonces, es necesario ascenderlos a la categora de
entidad.
Ejemplo
En ESTUDIANTE, el atributo notas es multivaluado:
ESTUDIANTE
carn
nombre
apellido
carrera
notas

Entonces, es preciso crear promover el atributo notas a la categora de clase

y establecer una relacin con estudiante.
Se debe verificar que un atributo no sea calculado o derivado de los valores
existentes de otros atributos. El atributo derivado es redundante y las
redundancias pueden conducir a inconsistencias en los valores de los datos.
Algunas veces se necesita, por cuestiones de eficiencia, tener datos
redundantes; pero se debe tener muy presentes en la etapa de diseo para
que sean, en la medida de lo posible, calculados o recalculados (en el caso
de correcciones) automticamente por el sistema.
Si un atributo tiene, a su vez, atributos propios; entonces debe modelarse
como otra entidad.

Ejemplo

Claudia

Jimnez

COMPUTADOR
referencia
marca
tarjeta madre
fecha de compra

Ramrez

Bases

COMPUTADOR
referencia
marca
fecha de compra

de

Datos

2 5

TARJETA MADRE
poseedora
de

para

nmero serie
chip procesador
velocidad procesador
chip coprocesador

Existen atributos obligatorios y otros que pueden ser opcionales. El atributo

obligatorio significa que en todo momento es importante conocer el valor que
toma para cada ocurrencia de la entidad y se marcan con un asterisco.
Cuando el atributo es opcional se marca con la letra o.
Ejemplo
PERSONA
* cdigo
* nombre
o profesin
* sexo
o peso

12. IDENTIFICADORES UNICOS

Un identificador nico (IU) puede ser cualquier combinacin de atributos y/o
relaciones que sirven para identificar inequvocamente una ocurrencia de
una entidad. Cada instancia debe ser completamente identificable.
Puede ocurrir que una entidad sea identificada por medio de una relacin.
En las corporaciones financieras, por ejemplo, a cada sucursal se le asigna
un nmero de identificacin y dentro de ellas, cada cuenta tiene un nmero
nico. Entonces, una CUENTA se identifica completamente con su nmero
ms el nmero de la sucursal.

Claudia

Jimnez

Ramrez

Bases

de

Datos

2 6

Observe cmo, en este caso, se coloca una barra para indicar que la
relacin forma parte del identificador nico.
Una relacin parte de un Identificador Unico debe ser obligatoria y de grado
uno y slo uno en la direccin que participa en la identificacin nica.
No es raro, tampoco, que una entidad sea identificada por varias relaciones.
Ejemplo
Para diferenciar una inscripcin a un curso de otra, se necesita el carn del
estudiante, el cdigo del curso y de la fecha de inscripcin
INSCRIPCION
# * fecha
o nota definitiva
de

para
registrado
en

motivo
para

ESTUDIANTE

CURSO

# * carn
* nombre

# * cdigo
* nombre

Una entidad puede tener ms de un identificador nico. Este es el caso de

un estudiante que posee un carn y un documento de identificacin (cdula
o T.I)
Se debe seleccionar uno, entre los candidatos, para que sea el identificador
nico y los otros se dejan como UI secundarios; aunque, lastimosamente, no
se muestran los identificadores nicos alternos en el modelo E-R.
En ocasiones, se usan identificadores artificiales (como pasa en la realidad)
para ayudar en la diferenciacin rpida de las instancias de una entidad.

Ejemplo

Claudia

Jimnez

Ramrez

Bases

de

Datos

2 7

ARTICULO
* descripcin
* unidad de medida
* marca
* cantidad a la mano
* precio de venta

Para identificar los artculos que vende una tienda, se necesitara de la

descripcin del artculo, de la unidad de medida y de la marca. Para evitar
un identificador nico tan largo, es mejor crear un cdigo artificial que ser
nico para cada instancia.

Claudia

Jimnez

Ramrez

Bases

de

Datos

2 8

NORMALIZACION DEL MODELO DE DATOS

Claudia

Jimnez

Ramrez

Bases

de

Datos

2 9

13. La normalizacin
La normalizacin es un concepto de bases de datos relacionales, pero sus
principios se pueden aplicar desde la etapa del modelamiento conceptual.
La ubicacin de los atributos se valida, usando las reglas de normalizacin
La primera forma normal (1FN) determina que todos los atributos deben
poseer un slo valor (ser atmicos).
La segunda forma normal enuncia que todo atributo debe ser dependiente
del identificador nico de la entidad a la que pertenece.
La tercera forma normal dice que ningn atributo que no sea identificador
nico puede depender de otro que tampoco lo sea.
Lo que se persigue con la normalizacin es evitar redundancia de datos y,
por ende, posibles inconsistencias.
Hasta la tercera forma normal generalmente se acepta que se normalice.
Regla de la primera forma normal: todos los atributos deben poseer un
slo valor.
Revise que ningn atributo tenga ms de un valor para cada instancia de
una entidad.
Ejemplo
PACIENTE
# * identificacin
* nombre
* direccin
* telfono
* fechas citas

El atributo fechas de las citas porque tiene mltiples valores. Por lo tanto, la
entidad PACIENTE, no est en primera forma normal debemos crear una
nueva entidad CITA MEDICA con una relacin uno a muchas con
PACIENTE.

Claudia

Jimnez

CITA MEDICA

Ramrez

de

Datos

3 0

PACIENTE

para

# * nmero
* fecha

Bases

figura
en

# * identificacin
* nombre
* direccin
* telfono

SOLUCION: Si un atributo tiene mltiples valores, cree una entidad

adicional y relacinela con la original con una relacin n:1.
Regla de la segunda forma normal: todo atributo debe ser dependiente
del identificador nico de la entidad a la que pertenece.
Para validar si entidad cumple con la segunda forma normal, verifique que
cada identificador nico especfico determine una sola ocurrencia para cada
atributo. Asegrese de un atributo no dependa nicamente de una parte del
IU de esa entidad.
Ejemplos
1. Valide si PACIENTE est en segunda forma normal
PACIENTE
# * identificacin
* nombre
* direccin
* telfono

Cada instancia una identificacin de paciente determina un valor especfico

para nombre, direccin y telfono. Entonces los atributos estn bien
ubicados.
2. Valide la ubicacin de los atributos para las entidades

CUENTA
# * nmero
* fecha apertura
* localizacin

manejada
por
administrador
de

BANCO
# * nmero
* nombre

Claudia

Jimnez

Ramrez

Bases

de

Datos

3 1

En el ejemplo anterior, cada instancia de BANCO y de un nmero de cuenta

determinan una fecha especfica de apertura. El atributo localizacin est
mal ubicado. Depende del BANCO pero no del nmero de la cuenta. No
debera ser, entonces, atributo de cuenta.
SOLUCION: si un atributo no depende del identificador nico entero, est
mal ubicado y debe ser movido a otra entidad.
Regla tercera forma normal: ningn atributo que no sea identificador
nico puede depender de otro que tampoco lo sea.
Ejemplo
Verifique si algn atributo no IU depende de cualquier otro que tampoco es
IU
REVISTA
# * nmero
* codigo editorial
* nombre editorial
* fecha publicacin

El atributo nombre de la editorial depende de otro que no es identificador

nico: cdigo de la editorial. Luego, se debe crear una nueva entidad
EDITORIAL y se reubican los atributos.

REVISTA
# nmero
* fecha publicacin

EDITORIAL

editada
por
editora
de

# codigo
* nombre

Solucin: si un atributo no IU depende de otro que tampoco es IU, mueva

ambos a una nueva entidad relacionada con la original.
Resolucin de las relaciones de muchos a muchos (n:m)
Una relacin de este tipo no debe aparecer en el modelo E-R. Una relacin
de muchos a muchos se resuelve adicionando una entidad de interseccin.

Ejemplo

Claudia

Jimnez

Ramrez

Bases

de

Datos

3 2

Considere una relacin muchos a muchos entre COMPAA DE SEGUROS

y SINIESTRO.

SINIESTRO

COMPAIA DE
SEGUROS

# Cdigo
* Nombre

# Nmero
* Nombre

El valor del seguro y la fecha de vencimiento del mismo, son atributos de la

relacin entre SINIESTRO y COMPAA DE SEGUROS. Los atributos slo
describen a las entidades.
Si los atributos describen una relacin, entonces sta debe ser resuelta. Se
resuelve una relacin n:m con una entidad nueva de interseccin y dos
relaciones 1:n.
Para el ejemplo, se puede adicionar la entidad de interseccin POLIZA.
POLIZA
# nmero
* fecha inicial
* fecha vencimiento
* valor asegurado

ASEGURADORA

de
encargada
de

# cdigo
* nombre
* direccin

registradora
de
amparado con

SINIESTRO
# cdigo
* nombre

En efecto, los atributos valor del seguro, la fecha inicial y de vencimiento

pertenecen a la entidad POLIZA.
Para resolver una relacin muchos a muchos, se ubica la entidad de
interseccin de tal manera que las patas de gallina siempre se dirijan hacia
la izquierda o hacia arriba en el diagrama:

Claudia

Jimnez

Ramrez

Bases

entidad de
interseccin

de

Datos

3 3

o as

entidades de
referencia

El identificador nico de una entidad de interseccin casi siempre est

compuesto por las relaciones de las dos entidades que le dieron origen.
Ejemplo
CURSO
# cdigo
* nombre
* crditos
* duracin

ESTUDIANTE
tomado por

# carn
inscrito en

* nombre
* telfono

Para resolver la relacin de muchos a muchos, adicionamos la entidad de

interseccin INSCRIPCION y dos relaciones 1: m.
INSCRIPCION
* fecha iniciacin
* fecha culminacin
* nota definitiva
para

de
tomado via

CURSO
# cdigo
* nombre
* crditos
* duracin

registrado en

ESTUDIANTE
# carn

* nombre
* telfono

Una vez se identifique la entidad de interseccin, se deben buscar atributos

adicionales que la describan. Puede ocurrir, sin embargo, que obtengamos
una entidad de interseccin sin atributos; en este caso tendremos slo una
referencia cruzada entre las ocurrencias de las entidades y el identificador
nico para la entidad de interseccin, estar siempre compuesto de las
relaciones de las dos entidades de las cuales se origin.

Claudia

Jimnez

Ramrez

Bases

de

Datos

3 4

Una entidad de interseccin sin atributos es la excepcin a la regla de que

una entidad siempre debe poseer atributos para poder ser, realmente, una
entidad.
Ejemplo
ACTOR
# cdigo
* nombre artistico
o nombre real
o fecha nacimiento

PELICULA

protagonista
de
protagonizada
por

# identificador
* nombre
* clasificacin

Para esta relacin de muchos a muchos, no se identifican atributos

asociados. Entonces, se resuelve con una entidad de interseccin sin
atributos.
PAPEL ESTELAR

de

en
poseedor de

ACTOR
# cdigo
* nombre artistico
o nombre real
o fecha nacimiento

figurar con

PELICULA
# identificador
* nombre
* clasificacin

14. Relaciones jerrquicas

Los identificadores nicos para un conjunto de entidades con una
relacin de jerarqua se pueden propagar a travs de mltiples
relaciones como se ilustra en el siguiente ejemplo.

Claudia

Jimnez

Ramrez

Bases

de

Datos

3 5

APARTAMENTO
# nmero
* propietario
situado en
conformado por

PISO
# nmero

situado en
conformado por

BLOQUE
# nmero

situado en
conformado por

UNIDAD
# cdigo
* nombre
* direccin

El IU de APARTAMENTO es el nmero del apartamento y del PISO donde

se localiza.
El IU de PISO es el nmero del piso y del BLOQUE donde se localiza.
El IU de BLOQUE es el nmero del bloque y del cdigo de la UNIDAD
donde se localiza.
Cuando las estructuras jerrquicas cambian a menudo, es mejor crear
atributos artificiales para ayudar a identificar las entidades.

15. Relaciones recursivas

Una relacin recursiva es aquella que posee una entidad consigo misma.

Claudia

Jimnez

Ramrez

Bases

de

Datos

3 6

Ejemplo
EMPLEADO
# cdula
* nombre
o profesin
* cargo
* fecha ingreso
* salario

bajo ordenes
de

a cargo
de

La convencin para dibujar una relacin recursiva es conocida con el

nombre de cola de marrano. Puede aparecer en cualquier lado de la caja
de la entidad; pero recordando que el lado de muchos siempre va hacia la
izquierda o hacia arriba.
Es recomendable representar una relacin jerrquica como una recursiva:
APARTAMENTO
# nmero
* propietario
situado en
conformado por

PISO
# nmero
LOCALIZACION

situado en
conformado por

BLOQUE
# nmero

situado en
conformado por

UNIDAD
# cdigo
* nombre
* direccin

# cdigo
o nombre
o direccin
o propietario
conformada
por

dentro de

Claudia

Jimnez

Ramrez

Bases

de

Datos

3 7

La entidad recursiva debe incluir todos los atributos de cada entidad

individual. La relacin recursiva debe ser siempre opcional en ambas
direcciones; puesto que la jerarqua sera infinita.

Claudia

Jimnez

Ramrez

Bases

de

Datos

3 8

16. Generaciones de Bases de Datos

El origen del primer DBMS ocurre a mediados de los aos sesenta cuando
IBM y Rockwell International desarrollaron las primeras versiones de un
sistema conocido como DL/I con el propsito de administrar la gran cantidad
de datos del proyecto espacial APOLO [GON96]. Posteriormente, le
adicionan una componente de control de la informacin, en el sistema (ICS)
para el acceso a los datos en forma concurrente.
El anterior producto se comercializa en 1969, bajo el nombre de IMS/360
(Information Management System para el IBM 360).
Los sistemas manejadores de bases de datos, DBMS, se pueden clasificar
por el mtodo empleado para estructurar los datos internamente. A las
estructuras de datos utilizadas se les llaman tambin modelos fsicos de
datos.
El IMS es un DBMS de tipo jerrquico, es decir, se sustenta sobre una
estructura de datos jerrquica o de rbol; en donde los nodos representan
las entidades y los arcos representan las relaciones.
La arquitectura del IMS se muestra en la figura 3.

Aplicacin 1

Programa de
comunicacin

Aplicacin 2

Aplicacin n

Programa de
comunicacin

Programa de
comunicacin

Descripciones de la base de datos

Figura 3. Arquitectura del DBMS Jerrquico IMS/360.

Claudia

Jimnez

Ramrez

Bases

de

Datos

3 9

Las descripciones de la base de datos, definen una base de datos fsica que
agrupa la informacin sobre todos los segmentos (que representan las
entidades) con su longitud y clave, entre otras cosas.
El programa de comunicacin define el mecanismo usado para el paso del
modelo lgico al fsico.
Finalmente, cada aplicacin define el conjunto de procedimientos y de
funciones que requiere un usuario final.
Los desarrolladores de bases de datos jerrquicas se referan a las
relaciones 1:n, como relaciones padre-hijo entre los registros; que se
podan implementar por medio de adyacencia fsica (registro padre + arreglo
de registros hijos) o por medio de punteros. Las bases de datos jerrquicas
se construyen reuniendo mltiples relaciones padre-hijo.
La figura 4, muestra una estructura de rbol cuyo nodo raz, es Asignatura.
ASIGNATURA
Cdigo

Descripcin

REQUISITOS

CURSOS
Fecha

PROFESORES
Cdula

Nombre

Grupo

Aula

ESTUDIANTES
Cdula

Nombre

Figura 4. Estructura de una base de datos acadmica.

El problema bsico de la estructura jerrquica, consisti en que un registro
hijo no poda tener dos registros padres distintos. Esta situacin impeda
representar relaciones muchos a muchos, sin tener redundancia.
Considere, por ejemplo, las relaciones siguientes (ver figura 5):
Un estudiante puede matricularse en varios cursos (relacin 1:n)
Un curso puede ser tomado por varios estudiantes (relacin 1:n)

Claudia

Jimnez

Ramrez

Bases

de

Datos

4 0

Si se quisiera generar el certificado del registro acadmico de un estudiante,

se tendra que usar la primera relacin. Si se quisiera generar la lista de
estudiantes matriculados en un curso dado, se tendra que usar la segunda
relacin. El modelo jerrquico obliga a repetir informacin para dar
respuesta a estos dos tipos de consultas.
REGISTRO

ESTUDIANTE

CURSO

Figura 5. Una relacin n: m

Segunda Generacin de Bases de Datos

Para resolver el problema de la redundancia en las bases de datos
jerrquicas, con las relaciones de muchos a muchos, surgen las bases de
datos en red. La estructura de un DBMS en red es esencialmente la misma
que en el modelo de datos jerrquico; excepto que un miembro (registro
hijo) puede pertenecer a ms de un conjunto (registro padre).
Los DBMS en red son ms generales que un DBMS jerrquico; pues un
rbol siempre podr ser una red, en cambio una red puede no ser un rbol.
Las redes de conjuntos de una base de datos siempre son implementadas
mediante punteros, como lo ilustra la figura 6.
123 | Juan Prez

registro 128

registro 146

registro 145

registro 149

Figura 6. Una instancia de Conjunto

A pesar de superar el problema de la redundancia de datos, se origin otro
relacionado con el manejo de punteros; pues adems de aumentar la
complejidad, las relaciones que se creaban por medio de ellos hacan que

Claudia

Jimnez

Ramrez

Bases

de

Datos

4 1

se tuviera definir de antemano cmo se consultaran los datos; restando

flexibilidad a los sistemas.
TERCERA GENERACION DE BASES DE DATOS
En 1970, E.F. Codd de la IBM propone el modelo relacional que est basado en la
teora de conjuntos y en la lgica de predicados de primer orden. La idea de Codd
consista en evitar el uso de punteros por parte de los usuarios especialistas para
facilitar la gestin de los datos y sus relaciones; el DBMS se debera encargar del
manejo de los punteros de las estructuras de datos fsicas. La tcnica consista en
representar los datos como tablas bidimensionales; una manera mucho ms
sencilla y comprensible y por ello, este modelo de datos logr la popularidad que
hoy sigue teniendo.
Codd encontraba otro problema bsico de los modelos primitivos, adems del
manejo de punteros, que era la restriccin de procesar slo un registro a la vez y
por ello el usuario deba controlar condiciones como "fin de archivo". En lugar de
ello, l quera que se pudiera realizar operaciones sobre conjuntos de datos y que
el DBMS controlara los detalles o las condiciones para llevar a cabo estas
operaciones.

Ventajas del modelo relacional

1. Separacin clara del nivel lgico y el fsico. El usuario no ve para nada el nivel
fsico.
2. Simple y fcil de trabajar con l. La representacin de los datos por tablas es
intuitiva pues recuerda las hojas electrnicas.
3. Operadores poderosos para la manipulacin de datos.
4. Fundamentos tericos slidos.
Desventajas:
1. La eficiencia se ve afectada por la prohibicin de manejo de punteros en forma
explcita; aunque en algunos manejadores de bases de datos se puede tener
acceso a los objetos mediante su ROWID.
Terminologa
Antes de explorar el modelo relacional es importante dar la definicin de los
conceptos bsicos que ste incluye.
Relaciones y Tablas
La estructura bsica del modelo relacional, y de ah su nombre, es la relacin. El
trmino relacin es tomado de la teora de conjuntos y no tiene que ver para nada

Claudia

Jimnez

Ramrez

Bases

de

Datos

4 2

con el hecho de que los datos puedan estar relacionados. Una relacin es un
concepto abstracto de un estructura bidimensional. Una relacin se puede definir
por comprensin o por extensin. As, por ejemplo, podemos definir por
comprensin la relacin R:
R = { x / x(identificacin, nombre, telefono) es estudiante de la Universidad
Nacional }
La estructura bidimensional que asociamos familiarmente a una relacin es la
tabla, entonces estos dos trminos se usan indistintamente.
Una relacin en este modelo tiene las siguientes propiedades:

Cada celda es atmica o univaluada

Cada columna tiene un nombre nico dentro de la tabla

El orden de las columnas o filas es indiferente.

Cada fila es distinta e identificable por alguna combinacin de sus valores

en los atributos.

Tuplas, Atributos y Cardinalidad

Cada instancia o fila de una relacin se le denomina tupla y a cada columna se le
denomina tambin atributo. Al nmero de atributos se le denomina el grado de
una relacin y al nmero de tuplas se le denomina cardinalidad o extensin de la
relacin.
Dominio
Un dominio es un conjunto aceptable de valores para un atributo. Un dominio
puede ser compartido por varios atributos y se puede restringir para velar por la
integridad de la base de datos.
Clave Primaria
Las claves sirven para la identificacin de las tuplas. Se utiliza, entonces, una
coleccin mnima de atributos como clave primaria para representar los
identificadores nicos del modelo E-R.

Clave candidata:

Claudia

Jimnez

Ramrez

Bases

de

Datos

4 3

Atributo (columna) o atributos que identifican a una tupla (fila) dada. La clave
primaria es la clave candidata elegida por el DBA.
Clave fornea:
Es un atributo que es clave primaria en otra relacin. Permite explcitamente
especificar las relaciones entre dos diferentes tablas y es tambin un mecanismo
para asegurar la integridad.
Terminologa Alternativa de trminos
Relacional
Relacin
Tupla
Atributo
Instancia

Comn
Tabla
Fila
Columna
Valor

Sistemas de Archivos
Archivo
Registro
Campo
Valor

DISEO DE BASES DE DATOS

El diseo de la base de datos se realiza durante la etapa de diseo del sistema y
se hace al tiempo con el diseo de la aplicacin de las aplicaciones que se
piensen desarrollar, en paralelo.
El diseo, produce especificaciones para la implementacin de bases de datos
relacionales; incluyendo definiciones para las relaciones, los ndices, las vistas
que se deben crear y otras especificaciones sobre el espacio de almacenamiento.
Se debe documentar el sistema, con una tabla de especificaciones para cada
relacin en el modelo relacional.
Tabla de Especificacin de la Relacin EMPLEADOS
Nombre

EMPNO

NOMB

APELL

TBJO

FCHING

SAL

JEFE

DEPNO

CF1

CF2

Columna
Tipo de

CP

Clave
Nulos/

NN, U

NN

NN

NN

NN

7369

Pedro

Hoyos

Dependiente

17-12-80

800

7902

20

7902

Ana

Casas

Analista

03-12-81

3000

7566

50

Unicos
Ejemplos

Los tipos de clave vlidos, son CP para una columna de clave primaria, y CF
para una columna de clave fornea.

Claudia

Jimnez

Ramrez

Bases

de

Datos

4 4

Se usan sufijos para distinguir entre mltiples columnas de CF en una tabla

simple, por ejemplo, CF1 y CF2. Se rotulan mltiples columnas clave con el
mismo sufijo.
Se usa el rtulo NN para las columnas que deben ser definidas como no
nulas (NOT NULL).
Se usa el rtulo U para una columna que deba ser nica (unique).
Si varias columnas deben ser nicas en combinacin, se nombran con sufijos,
por ejemplo U1.
Se designa una columna simple que es clave primaria como NN, U.
Se designan mltiples columnas CP como NN, U1 o posiblemente como NN,
U1, U.

El modelo E-R de una institucin de educacin no formal que se observa en la

figura nmero 1, se emplear para ilustrar como transformar el modelo E-R en un
modelo relacional.

INSCRIPCION
* Fecha inscripcin
o Fecha finalizacin
o Nota

para

de

tomado
por medio de

CURSO
# Cdigo
* Nombre
o Cuota
o Duracin

dictado por
registrado con

ESTUDIANTE
# Identificacin
* Nombre
* Apellido
* Telfono

instructor de
PROFESOR
# Identificacin
* Nombre
* Apellido
oTelfono oficina

Figura 7 Modelo E_R de una institucin educativa

Se siguen una serie de pasos para transformar el Modelo E-R a una serie de
relaciones, produciendo un diseo inicial de la base de datos.

PASO 1 - CONVERTIR LAS ENTIDADES SIMPLES A RELACIONES

Claudia

Jimnez

Ramrez

Bases

de

Datos

4 5

Las entidades simples, entidades que no son subtipos o supertipos, ni participan

en una relacin exclusiva en el modelo E-R, se transforman en relaciones del
modelo relacional.
Se crea una tabla de especificacin para cada entidad simple. Inicialmente se
comienza con el nombre que se le va a dar a esta entidad en el modelo relacional.
El nombre de la tabla debe permitir recordar el nombre de la entidad. Se
acostumbra a utilizar el plural del nombre de la entidad para el nombre de la
relacin en el modelo relacional, en especial si ste no es largo.
PASO 2 - CONVERTIR LOS ATRIBUTOS A COLUMNAS
Cada atributo se vuelve una columna de la relacin a la cual pertenece. Se debe
especificar que los atributos requeridos son columnas NOT NULL (NN).
Ejemplo: Como los atributos identificacin, nombre y apellido son atributos de
entrada obligatoria de la entidad PROFESOR, se transforman en columnas no
nulas. Se debe, entonces, designar sus columnas como NOT NULL.
PROFESOR
Nombre
Columna

ID_PROF

NOMB

APELL

NN

NN

NN

TEL

Tipo de
Clave
Nulos/
Unicos
Ejemplos

Para cada atributo, se sugiere seleccionar un nombre de columna corto pero

significativo. El nombre de la columna debe ser fcil de recordar. Es bueno utilizar
abreviaturas consistentes para evitar confusin al programador y al usuario. Por
ejemplo, Nmero ser abreviado como NO o NUM. Esto es, NODEPTO o
NUMDEPTO?
Los nombres de las columnas cortos reducen el tiempo requerido para la
ejecucin de comandos del SQL. Para determinar los tipos de datos adecuados
es til documentar las tablas de especificaciones, con tuplas ejemplo.
Los datos ejemplo, se pueden obtener de diversas maneras:
De notas de entrevistas con los usuarios finales.
De la documentacin de sistemas informticos actuales.
De conversaciones adicionales con el usuario.

Claudia

Jimnez

Ramrez

Bases

de

Datos

4 6

PASO 3 - CONVERTIR LOS IDENTIFICADORES UNICOS A CLAVES

PRIMARIAS
En este paso, cada atributo que hace parte de los identificadores nicos de la
entidad se convierten en columnas con tipo de clave primaria (CP).

Todas las columnas CP deben ser tambin NN y U.

Un identificador nico que incluya varios atributos, se convierte en una clave
primaria compuesta. Estas columnas son NN y U1.

Si el identificador nico, IU, de una entidad incluye una relacin, se deben aadir
las columnas de las claves forneas a la tabla y marcarlas como parte de la clave
primaria.
Ejemplo: el identificador nico de la entidad INSCRIPCION est compuesto por
las relaciones con las entidades CURSO y ESTUDIANTE. Por lo tanto, es
necesario aadir dos columnas claves forneas, a la tabla INSCRIPCION, para
formar su clave primaria.
Tabla: INSCRIPCION
Columna
Tipo Clave
Nulos/
Unicos
Ejemplos

FCH_INS

FCH_FIN

NOTA

29/09/98
--28/06/98
28/06/98
21/05/98

----4.1
4.2
4.0

NN
20/08/98
05/06/98
14/06/98
08/05/98
05/05/98

COD_CUR ID_EST
CP, CF1 CP, CF2
NN, U1
NN, U1
344
401
717
717
401

47593
15402
51394
94572
51394

Escoger un nombre nico para cada columna CF, y rotular la(s) columna(s)
CP, NN y CF.
Si existen mltiples columnas CF en la tabla, usar sufijos para distinguir entre
ellas, por ejemplo, CF1 y CF2. Debemos rotular varias columnas claves con el
mismo sufijo
Una CP compuesta debe ser nica en combinacin y se debe rotular como
U1.

PASO 4 - CONVERTIR LAS RELACIONES EN CLAVES FORANEAS

Claudia

Jimnez

Ramrez

Bases

de

Datos

4 7

Para una relacin 1:n, se debe tomar el IU de la entidad con cardinalidad de uno y
ponerla en la tabla relacional que corresponde a la entidad con cardinalidad de
muchos.
Por ejemplo, se toma la clave primaria Identificacin en el lado de uno, y se coloca
en la relacin CURSO que est en el lado de "muchos".

instructor
de
dictado
por

CURSO
#Cdigo
* Nombre
o Cuota
o Duracin

Nombre
Columna
Tipo de
Clave
Nulos/
Unicos
Ejemplos

Tabla: CURSO

COD_CUR

NOMBRE

CUOTA

PROFESOR
# Identificacin
* Nombre
* Apellido
DUR oTelfono
ID_PROF oficina
CF

CP
NN, U

NN

344
974
401
717

SQL SERVER
ORACLE
DISEO BD
TAREAS DE
UN DBA

1000
400
400
900

5
2
2
3

81
73
95
73

Se debe seleccionar un nombre nico para la columna CF y rotularla como

CF.
Para relaciones obligatorias tambin se debe especificar que la columna es
no nula, NN.

Para una relacin 1:1 obligatoria, se debe colocar la clave fornea nica en la
tabla al lado de la obligatoriedad y usar la restriccin de NOT NULL para hacer
cumplir la relacin de obligacin.
Ejemplo: la relacin entre COMPUTADOR PERSONAL y TARJETA MADRE ES
UNA RELACIN 1:1 y es obligatoria hacia tarjeta madre. Entonces, se coloca la
clave fornea de la relacin en la tabla COMPUTADOR PERSONAL y se rotula

Claudia

Jimnez

Ramrez

Bases

como NOT NULL. ID_TM es la clavbe fornea aadida.

se rotula como U para hacer cumplir la relacin 1:1.

COMPUTADOR_PERSONAL
Nombre
Columna

NO_
INV

TIPO_
CASE

FTE_ ID_TM
ENER

de

Datos

4 8

Esta columna tambin

TARJETA_MADRE
Nombre
Columna

ID_TM

CHIP_
PRO

VEL_
PRO

CHIP_
COPR

Tipo Clave

CP

CF

Tipo Clave

CP

Nulls/
Unique

NN, U

NN

NN

NN, U

Nulls/
Unique

NN, U

NN

NN

NN

Datos de

1045

Baby AT

150

4579

Datos de

9978

486

33

Prueba

0437

Baby AT

200

8731

Prueba

4517

386

40

1458

Tower

220

4773

4773

486

25

1223

Tower

220

9978

4579

386SX

25

1088

Minitower

200

4517

8731

386

33

La clave fornea en una relacin 1:1 siempre debe ser nica, pero puede permitir
valores nulos, en algunos casos.
Si una relacin 1:1 es opcional en ambas direcciones, se puede colocar la clave
fornea en la tabla que corresponda a cualquier entidad participante en la
relacin.
Cuando exista una relacin recursiva 1:n, se debe adicionar una columna CF a la
tabla simple. Esta columna CF remitir a los valores de la columna CP.
Ejemplo: Para esta relacin recursiva 1:M, aadir una columna CF a la tabla
EMPLEADO por cada Jefe de empleado. Nombrar la columna ID_JEFE para
reflejar la relacin.
jefe de

bajo rdenes de

Tabla: EMPLEADO
EMPLEADO

Nombre
Columna

#*Id
ID_EMP

*Nombre
*Apellido

NOMBRE

APELL

ID_JEFE

Claudia

Jimnez

Tipo de clave
Nulos/
Unicos
Ejemplos

Ramrez

Bases

CP
NN, U

NN

NN

7450
5579
6714

Mara
Juana
Susana

Prez
Meja
Jimnez

de

Datos

4 9

CF

--7450
5579

Se debe observar que la columna CF se refiere a una fila en la misma tabla. La

columna CF se nombra de tal manera que refleje la relacin.
Debe observarse, adems, que una CF recursiva nunca ser NOT NULL porque
se creara un ciclo infinito.
Para una relacin recursiva 1:1, es necesario aadir una clave fornea nica a la
tabla. Esta columna CF remitir a los valores de la columna CP.
Ejemplo: Para la relacin recursiva 1:1 "casado(a) con", se agreg una columna
nica, a la tabla PERSONA.

esposo(a)
de

casado(a) con

Tabla: PERSONA
Nombre
Columna
Tipo de Clave
Nulos/Unicos
Ejemplo

ID_PERS
CP
PERSONA
NN,
U1
#*Id
7450
*Nombre
*Apellido
5579
6714
9451
3040

NOMBRE

APELL

ID_ESP

NN
Mara
Juana
Susana
Ral
Diego

NN
Prez
Gmez
Jimnez
Tobn
Garca

CF
U1
--9451
3040
5579
6714

La combinacin de las columnas CF y CP siempre debe ser nicas para

asegurar la relacin 1:1. Se garantiza que la combinacin sea nica
rotulndolas ambas columnas como U1.

PASO 5 - ESCOGER OPCIONES DE ARCO

Claudia

Jimnez

Ramrez

OFICINA
#*Id edificio
#*Nmero oficina

Bases

de

Datos

5 0

Figura 8 . Relacin exclusiva

INDIVIDUAL
#*Id

Los arcos representan una clase de clave fornea con varias alternativas. Se
escoge entre dos diseos para llevar los arcos a claves forneas:
SOCIEDAD
#*Cdigo
# Cdigo

Diseo de Arco Explcito

Diseo de Arco Genrico

COMPAIA
#*Nmero
# Nmero

El diseo de Arco Explcito crea una columna, clave fornea, para cada relacin
incluida en el arco.
As, por el ejemplo, el modelo E-R de la figura nmero 2, el arco se extiende sobre
el final de tres relaciones de "muchos". Entonces, se deben adicionar tres claves
forneas a la relacin de OFICINAS:
OFICINAS
Nombre
Columna
Tipo de Clave
Valores
nulos/nicos

ID_EDIF

NO_OFIC

ID_IND

COD_SOC

NO_COMP

CP
NN, U1

CP
NN, U1

CF1

CF2

CF3

El diseo de Arco Explcito soporta mltiples claves forneas con diferentes

formatos. Por ejemplo, ID_IND, COD_SOC y NO_COMP pueden tener diferentes
formatos de columna.
Sin embargo, con este tipo de diseo, la aplicacin debe hacer cumplir la
exclusividad de la relacin entre las claves forneas.
El diseo de arco genrico, por otro lado, crea una columna de clave fornea
simple y una columna adicional utilizada para indicar cul de las tablas es
referenciada por la columna clave fornea en cada fila. Como las relaciones son
exclusivas, solamente existe un valor de la clave fornea por cada fila en la tabla.

Claudia

Jimnez

Ramrez

Bases

de

Datos

5 1

Usando el diseo de arco genrico, con el ejemplo, se debe crear una columna de
clave fornea simple y aadir una columna de tipos para indicar cul de las tres
tablas es la referenciada en cada fila. Por ejemplo, I por INDIVIDUO, S por
SOCIEDAD y C por COMPAIA.
OFICINAS
Nombre
Columna
Tipo de Clave
Valores
nulos/nicos
Ejemplos

ID_EDIF

NO_OFIC

ID_RENTADOR

TIPO_RENTADOR

CP
NN, U1

CP
NN, U1

CF
NN

NN

1024

101

30045

Si la relacin bajo el arco es obligatoria, se deben definir todas las columnas

aadidas como NOT NULL.
Con este tipo de diseo, las claves forneas deben compartir el mismo formato en
todas las tablas de referencia y la relacin de exclusividad queda asegurada
automticamente.
PASO
6ESCOGER
SUPERTIPO/SUBTIPOS

Las opciones posibles, son las

OPCIONES

PARA

LAS

EMPLEADO
# Nmero
* Nombre
siguientes:
* Apellidos

DE PLANTA

TEMPORAL

Diseo de los subtipos,

en una sola tabla (el supertipo).
*Salario
* Valor hora
* Valor hora extra
Diseo de los subtipos en tablas separadas.
Como un arco de una relacin exclusiva.

Opcin 1 - Diseo de los subtipos en una sola tabla.

DEPARTAMENTO
#*Cdigo

EMPRESA
# nit

RELACIONES

Claudia

Jimnez

Ramrez

Bases

de

Datos

5 2

Consiste en disear una tabla para el supertipo con toda la informacin de los
subtipos. Es decir, la tabla resultante contendr las instancias de todos los
subtipos.
Este diseo es apropiado cuando los subtipos tienen pocos atributos y relaciones
propias y la consulta de los datos suele incluir datos de distintos subtipos.
Pasos de diseo

Crear una tabla para el supertipo

Crear una columna TIPO para identificar a cul subtipo pertenece cada fila.
Crear una columna para cada uno de los atributos del supertipo.
Crear una columna para cada uno de los atributos de los subtipos.
Crear columnas CF para cada una de las relaciones del supertipo.
Crear columnas CF para cada una de las relaciones de los subtipos.

Como ejemplo, se convertir el supertipo EMPLEADO y sus subtipos de la figura

3, en una sola tabla.
EMPLEADO
Nombre
Columna
Tipo de
Clave
Nulos/
Unicos
Ejemplos

NUM

NOMB

APELL

TIPO

NN, U

NN

NN

NN

4579
6631
1190
370
800
7147
6794

Jaime
Ana
Juan
Pedro
Luis
Alex
Lili

Prez
Casas
Hoyos
Daz
Ruiz
Ros
Vega

P
P
P
P
P
T
T

SALARIO

VLR_
HORA

VLR_
EXTRA

CP

NUM_
EMP
CF1

COD_
DEP
CF2
NN

29000
25000
42700
44050
38450
8.50
6.75

12.75
11.50

201
150

40
35
40
30
35
35
30

El diseo de en una sola tabla requiere siempre que se cree una nueva columna
(tipo) para identificar el subtipo correspondiente en cada fila.
Ventajas de este diseo

El acceso al supertipo es directo. Si en la organizacin se debe consultar

frecuentemente el supertipo, esta opcin es apropiada.
Se puede tener acceso a los subtipos mediante vistas.

Desventajas de este diseo

Claudia

Jimnez

Ramrez

Bases

de

Datos

5 3

Los requerimientos de atributos no nulos, en cada subtipo, no se pueden

hacer cumplir desde la definicin de la base de datos.
La lgica de la aplicacin debe proveer distintos atributos, dependiendo del
tipo.

Opcin 2 - Diseo de los subtipos en tablas diferentes

Esta opcin consiste en convertir los subtipos en tablas diferentes -una para cada
subtipo. Cada tabla contendr instancias solamente de ese subtipo.

Pasos de diseo

Crear una tabla para cada subtipo

TABLA para cada atributo
En cada tabla de un subtipo, crear las columnas
B
A
subtipo.
B
En cada tabla de un subtipo, crear las columnas para los atributos
supertipo.
TABLA
C
C para cada relacin
En cada tabla de un subtipo, crear columnas CF
subtipo.
En cada tablas del subtipo, crear columnas CF para cada relacin
supertipo.

del
del
del
del

Empleando este mtodo de diseo, la relacin supertipo/subtipo de la figura 3,

conduce a convertir el supertipo EMPLEADO en dos tablas -una por cada subtipo
como se muestra a continuacin.

Tabla: EMPLEADO DE PLANTA

Nombre
Columna

NUM_ESC

NOMB

APELL

SALARIO

COD_DEP

NN

NN

NN

Tipo Clave

CP

Nulls/Unique

NN, U

NN

Ejemplos

CF

4579

Jaime

Prez

29000

40

6631
1190

Ana
Juan

Casas
Hoyos

25000
42700

35

370

Pedro

Daz

44050

30

40

Claudia

Jimnez

Ramrez

800

Luis

Bases

Ruiz

38450

de

Datos

5 4

35

Tabla: EMPLEADO TEMPORAL

Nombre
Columna

NUMERO

NOMB

APELL

VLR_HORA VLR_EXTRA NUM_EMP COD_DEP

CF1

CF2

NN

NN

NN

NN

NN

Tipo Clave

CP

Nulls/
Unique

NN, U

NN

Ejemplos

7147

Alex

Ros

8.50

12.75

201

35

6794

Lili

Vega

6.75

11.50

150

30

941

Sal

Meja

12.00

18.00

201

45

Se usa el diseo de subtipos en tablas diferentes cuando los subtipos tienen

muchos atributos y relaciones especficas o particulares.
Ventajas de este diseo

La opcionalidad de los atributos del subtipo se hace cumplir desde la

definicin de la base de datos.
La lgica de la aplicacin no requiere comprobaciones para los subtipos

Desventajas de este diseo

El acceso al supertipo requiere del operador UNION o una vista creada con
este operador.
Las vistas que unen las dos tablas son solamente de lectura.
El mantenimiento de identificadores nicos a travs de los subtipos es ms
difcil de implementar, cuando los subtipos son excluyentes.