Está en la página 1de 54

TABLA DE CONTENIDO

1. BREVE HISTORIA DE LAS BASES DE DATOS 3


2. QUE ES UNA BASE DE DATOS? 6
3. LA INFORMACIN COMO RECURSO CORPORATIVO 3
Ventajas y Desventajas de un Sistema de Bases de Datos 7
Funciones de un Sistema Gestor de Bases de Datos 7
4. NIVELES DE ABSTRACCIN DE UNA BASE DE DATOS 9
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
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 3
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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 4
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 Programas Lenguaje
en archivos de desarrollo
nombre, cdula, valor cancelado por matrcula, prstamos, etc. Fortran
nombre, carrera, cdula, materias, notas, telfono, etc. Cobol
nombre, carrera, nota promedio, valor prstamo, caducidad, etc. 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
Prstamo estudiantil
Ingresos y Egresos
Registro y matrcula
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 5
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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 6
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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 7
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:
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 8
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
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 9
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
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.
Anlisis sintctico
Verificacin de
privilegios y de la
existencia de los
objetos en la base de
datos
Diccionario
de datos
Error
Optimizacin de la
consulta
Manejo de
Transacciones
Base de
datos
Bitcora
Administracin del
almacenamiento
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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.
1
2 n
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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
Diseo
Anlisis Conceptual de
la Base de Datos
Modelo Entidad-Relacin
Diseo Diseo lgico
de la Base de
Datos Tablas, ndices, Vistas,
Clsteres, Definiciones de
espacios
Construccin 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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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 Modelamiento
Conceptual de Chequeos Cruzados de
Anlisis Funciones
Modelo Entidad-Relacin Modelo Jerrquico
Def de Funciones
DFDs
Diseo Diseo de la Diseo de las
Base de Datos Chequeos Cruzados Aplicaciones
Tablas, Indices, Vistas, Diseo de mdulos
Clusters, Definiciones de
espacios
Construccin Construccin Construccin de
de la Base de las aplicaciones
Datos
BASE DE DATOS EN OPERACIN APLICACIONES 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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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 entidad-
relacin, con la notacin de Barker.
EMPLEADO
DEPARTAMENTO # * carn
* nombre
* apellido
o cargo
* fecha enganche
o salario
o comisin
# * nmero
* nombre
* ubicacin
jefe
de
subordinado
de
asignado a
responsable
de
Los conceptos bsicos de un modelo Entidad-Relacin son:
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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:
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:
PROYECTO
# cdigo
nombre
fecha de inicio
fecha de finalizacin
EQUIPO
# referencia
fabricante
marca
fecha de
compra
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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 DEPARTAMENTO
asignado
a
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:
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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 PASAJERO
comprado
por
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 ALQUILER generador
de
originado
por


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
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 2 2
OPERARIO
encargado
de
manejada
por
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 ORDEN BODEGA
CLIENTE el generador
de
ARTICULO comprado
mediante
almacenado
en
ORDEN Hecha para Compuesta de
BODEGA sitio de
almacenamiento
Una vez se tengan definidas las relaciones en la matriz, se pueden llevar al
modelo entidad-relacin.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 2 3
ARTICULO
cdigo
descripcin
BODEGA
identificador
direccin
ORDEN
nmero
fecha
CLIENTE
identificador
direccin
razn social
almacenado en
el repositorio de
comprado por
compuesta
de
originada por
el originador de
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
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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
notas
carrera
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
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 2 5
COMPUTADOR
referencia
marca
tarjeta madre
fecha de compra
COMPUTADOR
referencia
marca
TARJETA MADRE
fecha de compra
nmero serie
chip procesador
velocidad procesador
chip coprocesador
para
poseedora
de
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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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
ESTUDIANTE CURSO
# * carn
* nombre * nombre
# * cdigo
# * fecha
de
registrado
en
para
motivo
para
o nota definitiva
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
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 2 7
ARTICULO
* descripcin
* unidad de medida
* cantidad a la mano
* precio de venta
* marca
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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 2 8
NORMALIZACION DEL MODELO DE DATOS
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 3 0
CITA MEDICA
en
para
PACIENTE
# * nmero
# * identificacin
* nombre
* direccin
* telfono
* fecha
figura
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

de
manejada
BANCO
# * nmero # * nmero
* nombre * fecha apertura
administrador
* localizacin
por
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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

# * nmero
* codigo editorial
REVISTA
* 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.

# nmero # codigo
REVISTA
* nombre * fecha publicacin
EDITORIAL editada
por
editora
de
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
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 3 2
Considere una relacin muchos a muchos entre COMPAA DE SEGUROS
y SINIESTRO.
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.

de
ASEGURADORA
# cdigo
# cdigo
* nombre
encargada
de
SINIESTRO
* nombre
* direccin
# nmero
POLIZA
* fecha inicial
* fecha vencimiento
* valor asegurado
amparado con
registradora
de
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:
SINIESTRO
# Cdigo
* Nombre
COMPAIA DE
SEGUROS
# Nmero
* Nombre
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 3 3
entidad de
interseccin
entidades de
referencia
o as
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
ESTUDIANTE
# cdigo
* nombre
* crditos
* duracin
* nombre
* telfono
tomado por
inscrito en
# carn
Para resolver la relacin de muchos a muchos, adicionamos la entidad de
interseccin INSCRIPCION y dos relaciones 1: m.
CURSO
ESTUDIANTE
# cdigo
* nombre
* crditos
* duracin
* nombre
* telfono
tomado via registrado en
# carn
para de
INSCRIPCION
* fecha iniciacin
* fecha culminacin
* nota definitiva
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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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
PELICULA
# cdigo
* nombre artistico
o nombre real
o fecha nacimiento
* nombre
* clasificacin
protagonista
protagonizada
# identificador
de
por
Para esta relacin de muchos a muchos, no se identifican atributos
asociados. Entonces, se resuelve con una entidad de interseccin sin
atributos.
ACTOR
PELICULA
# cdigo
* nombre artistico
o nombre real
o fecha nacimiento
* nombre
* clasificacin
# identificador
PAPEL ESTELAR
poseedor de
de
figurar con
en
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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 3 5
APARTAMENTO
# nmero
situado en
conformado por
PISO
BLOQUE
* propietario
# nmero
# nmero
UNIDAD
# cdigo
* nombre
* direccin
situado en
situado en
conformado por
conformado por
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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 3 6
Ejemplo
EMPLEADO
# cdula
* nombre
o profesin
* cargo
* fecha ingreso
* salario
a cargo
de
bajo ordenes
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
situado en
conformado por
PISO
BLOQUE
* propietario
# nmero
# nmero
UNIDAD
# cdigo
* nombre
* direccin
situado en
situado en
conformado por
conformado por

# cdigo
o nombre
o direccin
LOCALIZACION
dentro de
conformada
por
o propietario
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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.
Figura 3. Arquitectura del DBMS Jerrquico IMS/360.
Aplicacin 2
Programa de
comunicacin
Aplicacin 1 Aplicacin n
Programa de
comunicacin
Programa de
comunicacin
Descripciones de la base de datos
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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
REQUISITOS CURSOS
PROFESORES ESTUDIANTES
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)
Cdigo Descripcin
Fecha Grupo Aula
Cdula Nombre Cdula Nombre
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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.
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.
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
ESTUDIANTE CURSO
REGISTRO
123 | Juan Prez
registro 128
registro 145
registro 146 registro 149
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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:
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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 Comn Sistemas de Archivos
Relacin Tabla Archivo
Tupla Fila Registro
Atributo Columna Campo
Instancia Valor 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
Columna
EMPNO NOMB APELL TBJO FCHING SAL JEFE DEPNO
Tipo de
Clave
CP CF1 CF2
Nulos/
Unicos
NN, U NN NN NN NN
Ejemplos 7369 Pedro Hoyos Dependiente 17-12-80 800 7902 20
7902 Ana Casas Analista 03-12-81 3000 7566 50

Los tipos de clave vlidos, son CP para una columna de clave primaria, y CF
para una columna de clave fornea.
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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.
para
tomado
por medio de
de dictado por
registrado con instructor de
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
INSCRIPCION
* Fecha inscripcin
o Fecha finalizacin
o Nota
CURSO
# Cdigo
* Nombre
o Cuota
o Duracin
ESTUDIANTE
# Identificacin
* Nombre
* Apellido
* Telfono
PROFESOR
# Identificacin
* Nombre
* Apellido
oTelfono oficina
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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 TEL
Tipo de
Clave
Nulos/
Unicos
NN NN NN
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.


C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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 FCH_INS FCH_FIN NOTA COD_CUR ID_EST
Tipo Clave CP, CF1 CP, CF2
Nulos/
Unicos
NN NN, U1 NN, U1
Ejemplos 20/08/98 29/09/98 --- 344 47593
05/06/98 --- --- 401 15402
14/06/98 28/06/98 4.1 717 51394
08/05/98 28/06/98 4.2 717 94572
05/05/98 21/05/98 4.0 401 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
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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
Tabla: CURSO
Nombre
Columna
COD_CUR NOMBRE CUOTA DUR ID_PROF
Tipo de
Clave
CP CF
Nulos/
Unicos
NN, U NN
Ejemplos 344 SQL SERVER 1000 5 81
974 ORACLE 400 2 73
401 DISEO BD 400 2 95
717 TAREAS DE
UN DBA
900 3 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
CURSO
#Cdigo
* Nombre
o Cuota
o Duracin
PROFESOR
# Identificacin
* Nombre
* Apellido
oTelfono oficina
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 4 8
como NOT NULL. ID_TM es la clavbe fornea aadida. Esta columna tambin
se rotula como U para hacer cumplir la relacin 1:1.
COMPUTADOR_PERSONAL TARJETA_MADRE
Nombre
Columna
NO_
INV
TIPO_
CASE
FTE_
ENER
ID_TM 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 N
Prueba 0437 Baby AT 200 8731 Prueba 4517 386 40 S
1458 Tower 220 4773 4773 486 25 N
1223 Tower 220 9978 4579 386SX 25 N
1088 Minitower 200 4517 8731 386 33 S
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
Nombre
Columna
ID_EMP NOMBRE APELL ID_JEFE
EMPLEADO
#*Id
*Nombre
*Apellido
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 4 9
Tipo de clave CP CF
Nulos/
Unicos
NN, U NN NN
Ejemplos 7450 Mara Prez ---
5579 Juana Meja 7450
6714 Susana Jimnez 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
ID_PERS NOMBRE APELL ID_ESP
Tipo de Clave CP CF
Nulos/Unicos NN, U1 NN NN U1
Ejemplo 7450 Mara Prez ---
5579 Juana Gmez 9451
6714 Susana Jimnez 3040
9451 Ral Tobn 5579
3040 Diego Garca 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
PERSONA
#*Id
*Nombre
*Apellido
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 5 0
Figura 8 . Relacin exclusiva
Los arcos representan una clase de clave fornea con varias alternativas. Se
escoge entre dos diseos para llevar los arcos a claves forneas:

Diseo de Arco Explcito

Diseo de Arco Genrico


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
ID_EDIF NO_OFIC ID_IND COD_SOC NO_COMP
Tipo de Clave CP CP CF1 CF2 CF3
Valores
nulos/nicos
NN, U1 NN, U1
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.
INDIVIDUAL
#*Id
SOCIEDAD
#*Cdigo
COMPAIA
#*Nmero
INDIVIDUAL
#*Id
SOCIEDAD
#*Cdigo
COMPAIA
#*Nmero
SOCIEDAD
# Cdigo
COMPAIA
# Nmero
OFICINA
#*Id edificio
#*Nmero oficina
OFICINA
#*Id edificio
#*Nmero oficina
OFICINA
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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
ID_EDIF NO_OFIC ID_RENTADOR TIPO_RENTADOR
Tipo de Clave CP CP CF
Valores
nulos/nicos
NN, U1 NN, U1 NN NN
Ejemplos 1024 101 30045 I
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 6- ESCOGER OPCIONES PARA LAS RELACIONES
SUPERTIPO/SUBTIPOS
Las opciones posibles, son las siguientes:

Diseo de los subtipos, en una sola tabla (el supertipo).

Diseo de los subtipos en tablas separadas.

Como un arco de una relacin exclusiva.


Opcin 1 - Diseo de los subtipos en una sola tabla.
EMPLEADO
# Nmero
* Nombre
* Apellidos
DE PLANTA
*Salario
TEMPORAL
* Valor hora
* Valor hora extra
DEPARTAMENTO
#*Cdigo
EMPRESA
# nit
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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
NUM NOMB APELL TIPO SALARIO VLR_
HORA
VLR_
EXTRA
NUM_
EMP
COD_
DEP
Tipo de
Clave
CP CF1 CF2
Nulos/
Unicos
NN, U NN NN NN NN
Ejemplos 4579 Jaime Prez P 29000 40
6631 Ana Casas P 25000 35
1190 Juan Hoyos P 42700 40
370 Pedro Daz P 44050 30
800 Luis Ruiz P 38450 35
7147 Alex Ros T 8.50 12.75 201 35
6794 Lili Vega T 6.75 11.50 150 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
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 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

En cada tabla de un subtipo, crear las columnas para cada atributo del
subtipo.

En cada tabla de un subtipo, crear las columnas para los atributos del
supertipo.

En cada tabla de un subtipo, crear columnas CF para cada relacin del


subtipo.

En cada tablas del subtipo, crear columnas CF para cada relacin del
supertipo.
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
Tipo Clave CP CF
Nulls/Unique NN, U NN NN NN NN
Ejemplos 4579 Jaime Prez 29000 40
6631 Ana Casas 25000 35
1190 Juan Hoyos 42700
40
370 Pedro Daz 44050
30
A
B
C
TABLA
B
TABLA
C
C l a u d i a J i m n e z R a m r e z B a s e s d e D a t o s 5 4
800 Luis Ruiz 38450
35
Tabla: EMPLEADO TEMPORAL
Nombre
Columna
NUMERO NOMB APELL VLR_HORA VLR_EXTRA NUM_EMP COD_DEP
Tipo Clave CP CF1 CF2
Nulls/
Unique
NN, U NN NN NN NN NN 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.