Modelado Conceptual MER-UML

BASES DE DATOS
MULTIMEDIA
MÓDULO DEL CURSO
Lyda Peña Paz

17/12/2013
Tabla de contenido
BASES DE DATOS ......................................................................................................... 3

ORIGEN ........................................................................................................................... 3
VENTAJAS ...................................................................................................................... 4
DEFINICIÓN ................................................................................................................... 5
ARQUITECTURA DE SISTEMAS DE BASES DE DATOS ........................................ 6
EVOLUCIÓN DE LAS BASES DE DATOS .................................................................. 7
EL SISTEMA GESTOR DE BASES DE DATOS (DBMS) ........................................... 8
Funciones .......................................................................................................................... 9
Lenguajes .......................................................................................................................... 9
Manejadores de Bases de Datos ..................................................................................... 10
EL ADMINISTRADOR DE LA BASES DE DATOS (DBA) ...................................... 10
Funciones ........................................................................................................................ 10
BASES DE DATOS MULTIMEDIA ............................................................................ 11
¿Cuál es la diferencia con los datos Multimedia? .......................................................... 11
MANEJADOR DE BASES DE DATOS MULTIMEDIA (MMDBMS) ...................... 12
REFERENCIA ............................................................................................................... 13
MODELO ENTIDAD - RELACIÓN ............................. ¡Error! Marcador no definido.
ELEMENTOS DEL MODELO ENTIDAD - RELACIÓN ........................................... 14
Relaciones recursivas ..................................................................................................... 18
Definición de claves o llaves .......................................................................................... 19
Relaciones redundantes y ciclos ..................................................................................... 21
Rompimiento de relaciones muchos a muchos............................................................... 23
Supertipos y subtipos ...................................................................................................... 25
Relaciones Excluyentes .................................................................................................. 26
NORMALIZACIÓN ...................................................... ¡Error! Marcador no definido.
FoRmas Normales .......................................................... ¡Error! Marcador no definido.
Primera Forma Normal ................................................... ¡Error! Marcador no definido.
Segunda Forma Normal .................................................. ¡Error! Marcador no definido.
Tercera Forma Normal ................................................... ¡Error! Marcador no definido.
Otras Formas Normales. ................................................ ¡Error! Marcador no definido.
Modelo Relacional de Datos........................................................................................... 30
REPRESENTACIÓN ..................................................................................................... 30
PASOS PARA OBTENER EL MRD DESDE EL MER ¡Error! Marcador no definido.
ACTIVIDADES ............................................................................................................. 39
MODELO ENTIDAD - RELACIÓN ............................................................................. 39
REFINAMIENTO DEL MODELO ............................................................................... 41
Normalización ................................................................................................................ 44
MODELAMIENTO ....................................................................................................... 51
REFERENCIAS ............................................................................................................ 53
SQL................................................................................................................................. 54
CREACIÓN DE LA BASE DE DATOS ....................................................................... 54
Tipos de Datos ................................................................................................................ 55
CREACIÓN DE TABLAS ............................................................................................. 56
MODIFICACIÓN DE TABLAS .................................................................................... 59
MANIPULACIÓN DE DATOS ..................................................................................... 61
CREAR INDICES .......................................................... ¡Error! Marcador no definido.
CONSULTAS ................................................................................................................. 63
Ordenamiento ................................................................................................................. 65
Agrupamiento ................................................................................................................. 65
Consulta sobre varias tablas ............................................................................................ 67
JDBC – Java Database Connectivity .............................................................................. 68
Arquitectura .................................................................................................................... 68
Usando el JDBC ............................................................................................................. 69
Consultas sobre la Base de Datos ................................................................................... 70
ACTUALIZACIÓN DE la Base de Datos ..................................................................... 71
El ResultSet .................................................................................................................... 71
ACTIVIDADES ............................................................................................................. 77
I. INTRODUCCION
BASES DE DATOS
ORIGEN
Con el paso de los años la información ha cobrado cada vez mayor importancia para el
desarrollo de todo tipo de organizaciones, este mismo fenómeno ocasiona que se
desarrollen formas eficientes para su recolección, proceso y almacenamiento.
La primera propuesta para el almacenamiento de información fueron los archivos o

ficheros, los cuales permitían almacenar los datos requeridos para el desarrollo de algún
proceso o aplicación; sin embargo se presentaban algunos inconvenientes, ya que, como
se puede observar en la figura 1, algunos datos podían encontrarse repetidos en
diferentes archivos y cada archivo solamente podía accederse desde una aplicación, es
decir que una nueva aplicación generaría un nuevo archivo (y viceversa); estos aspectos
que son en sí mismos problemáticos, podían llegar a generar otros inconvenientes como:
duplicación de datos, inconsistencia entre los datos que se encuentran en los diferentes
archivos, poca flexibilidad y adaptabilidad a los cambios que se requieran, total
desconexión entre los diferentes archivos.
Figura 1. Organización clásica: Sistemas Orientados al proceso. Tomado de: Piatinni, Mario G.; Marcos, Esperanza;
Calero, Coral y Vela, Belén. Tecnología y Diseño de Bases de Datos. Ed. Algaomega Ra-Ma. México, 2007. Pg. 18
Debido a estos inconvenientes surgidos, se busca una forma más eficiente para el
almacenamiento de datos y es cuando surgen las Bases de Datos como un repositorio
centralizado de datos independiente del tratamiento que se haga de ellos. Este nuevo
enfoque se centraba en los datos a diferencia del sistema de archivos que se centraba en
los procesos.
El término Bases de Datos surge a principios de los setenta, aunque su primera mención se
remonta a 1963 cuando se realizó en Estados Unidos un simposio en cuyo título se
encontraba la expresión Data Base y aunque durante dicho evento se propuso una
definición no fue aceptada y solamente hasta 1967 cuando el grupo de estandarización
Codasyl decidió cambiar su denominación por Data Base Task Group, el concepto empezó
a imponerse.
VENTAJAS
Respecto al anterior sistema de archivos, las Bases de Datos presentaban algunas

ventajas:
 Independencia entre los datos y su tratamiento: Los datos son independientes de las
transacciones que se realicen sobre ellos, de forma que diversas aplicaciones pueden
tener acceso al mismo conjunto de datos.
 Coherencia de los datos: Los datos son recogidos y almacenados una vez en la base de
datos lo cual permite disminuir la redundancia de datos y evita las inconsistencias.
 Mayor disponibilidad de datos: Debido a que los datos ya no dependen de las
aplicaciones que los utilicen, los usuarios pueden tener mayor acceso a estos, lo cual
se puede controlar a través de permisos.
 Mayor valor informativo: Al contener todos los datos en el mismo repositorio es
posible representar las relaciones que ellos guardan en el mundo real, generando
mayor valor en la información que se genera.
 Mejor documentación de la información: En el esquema de Archivos, los datos se
guardan de manera independiente a su estructura (la estructura era manejada
directamente por las aplicaciones), en las Bases de Datos la estructura y los datos se
guardan en el mismo repositorio, logrando una mejor documentación de la
información contenida.
 Mayor eficiencia en la validación y mantenimiento de datos: Al no existir datos
duplicados, la validación y mantenimiento de los mismos resulta más eficiente.
 Reducción del espacio de almacenamiento: Debido a que las bases de datos emplean
un espacio común para los datos y se elimina la duplicidad de los mismos, el espacio
de almacenamiento se reduce.
En su momento (años 70) se plantearon algunos inconvenientes para el uso de las bases
de datos, sin embargo, en este momento han perdido vigencia, ya que los costos de
instalación han bajado sustancialmente y existe personal capacitado para su manejo, por
lo tanto no se requiere una inversión adicional para la empresa; por otro parte, las
ventajas en el uso de Bases de Datos superan enormemente las posibles desventajas que
se pudieran presentar.
DEFINICIÓN
Algunas definiciones recopiladas por Piatinni et al 1son:
“Colección de datos interrelacionados almacenados en conjunto sin redundancias

perjudiciales o innecesarias; sin finalidad de servir a una aplicación o más, de la mejor
manera posible; los datos se almacenan de modo que resulten independientes de los
programas que los usan; se emplean métodos bien determinados para incluir nuevos
datos y para modificar o extraer los datos almacenados”. (Martin, 1975)
“Colección o depósito de datos, donde los datos están lógicamente relacionados entre sí,
tienen una definición y descripción comunes y están estructurados de una forma
particular. Una base de datos es también un modelo del mundo real y; como tal, debe
servir para toda una gama de usos y aplicaciones” (Conference des Statisticiens
Européens, 1977)
“Conjunto de datos de la empresa memorizado en un ordenador, que es utilizado por

numerosas personas y cuya organización está regida por un modelo de datos” (Flory,
1982)
“Conjunto estructurado de datos registrados sobre soportes accesibles por ordenador

para satisfacer simultáneamente a varios usuarios de forma selectiva y en tiempo
oportuno” (Delobel, 1982)
“Colección no redundante de datos que son compartidos por diferentes sistemas de

aplicación” (Howe, 1983)
“Colección integrada y generalizada de datos, estructurada atendiendo a las relaciones

naturales de modo que suministre todos los caminos de acceso necesarios a cada unidad
de datos con objeto de poder atender todas las necesidades de los diferentes usuarios”
(Deen, 1985)
1
Piatinni, Mario G.; Marcos, Esperanza; Calero, Coral y Vela, Belén. Tecnología y Diseño de Bases de Datos. Ed.
Algaomega Ra-Ma. México, 2007. Pg. 24
“Conjunto de ficheros maestros, organizados y administrados de una manera flexible de
modo que los ficheros puedan ser fácilmente adaptados a nuevas tareas imprevisibles”
(Frand, 1985)
“Colección de datos interrelacionados” (Elmasri y Navathe, 1989)
La siguiente definición es propuesta por de Miguel y Piatinni2 :
“Colección o depósito de datos integrados, almacenados en

soporte secundario (no volátil) y con redundancia controlada. Los
datos, que han de ser compartidos por diferentes usuarios y
aplicaciones, deben mantenerse independientes de ellos, y su
definición (estructura de la base de datos) única y almacenada
junto con los datos, se ha de apoyar en un modelo de datos, el
cual ha de permitir captar las interrelaciones y restricciones
existentes en el mundo real. Los procedimientos de actualización
y recuperación, comunes y bien determinados, facilitarán la
seguridad del conjunto de datos”
ARQUITECTURA DE SISTEMAS DE BASES DE DATOS
En una base de datos se distinguen tres estructuras, tal como se presenta en la Figura 2.
Figura 2. Arquitectura de las Bases de Datos
2 De Miguel, Adoración; Piattini, Mario. Fundamentos y Modelos de Bases de Datos. Ed. Alfa Omega Ra-Ma. Mexico.
1999. Pg28
 La estructura lógica de usuario o Vista externa corresponde a la visión que cada
usuario tiene de la Base de Datos, estas vistas pueden ser diferentes para los diversos
usuarios y dependen de las funcionalidades que cada uno de ellos requiera de la Base
de Datos.
 La estructura lógica global o Vista conceptual, es la visión global de los datos, desde el
punto de vista lógico, incluye la descripción de los datos y las relaciones que estos
guardan. Esta capa es un modelo de representación y debe guardar las características
que los datos mantienen en el mundo real.
 El esquema interno o Vista física, corresponde a la forma como los datos se organizan
en el almacenamiento físico y es altamente dependiente del programa manejador,
algunos aspectos que involucra esta vista son la estrategia de almacenamiento, los
caminos de acceso, manejo de índices, administración de memoria y control de acceso
(físico).
Esta estructuración de las Bases de Datos en tres niveles, es los que permite mantener la
independencia entre los datos y las aplicaciones, además de garantizar un modelo
apropiado de los datos, que represente el mundo real.
EVOLUCIÓN DE LAS BASES DE DATOS
Si bien el concepto y las características esenciales de las Bases de Datos se han mantenido
desde sus inicios, los modelos que se han empleado para representarlas han variado a lo
largo del tiempo.
Primera Generación: En los años sesenta y setenta surge la primera generación de Bases
de datos, que se basaban en modelos jerárquicos y en red, que proporcionaban una
estructura de los datos a manera de árboles o grafos.
(a) (b)
Figura 4. Esquemas de Sistemas de Bases de Datos Jerárquico (a) y de Red (b).

Aunque estos esquemas cumplían su propósito, tenían una flexibilidad limitada y no
proporcionaban suficiente independencia entre los datos y los procesos.
Segunda Generación: En 1970, el Dr. E.F. Codd, propuso el modelo relacional, el cual fue
considerado inicialmente como un buen modelo matemático pero no era clara su
implementación, sin embargo poco a poco se entendió su potencial por lo que llegó a
convertirse en el principal modelo para desarrollo de Bases de Datos, el cual se usa hasta
la actualidad.
Tercera Generación: Los proveedores de tecnología se han encargado de evolucionar las

Bases de Datos incorporando a sus DBMS capacidades de gestión, incluyendo la gestión de
objetos, tipos grandes de datos (entre los que se encuentran los datos multimediales) y
gestión de conocimiento (minería de datos).
EL SISTEMA GESTOR DE BASES DE DATOS (DBMS)
El sistema Manejador de Bases de Datos o DBMS (DataBase Management System) se

puede definir como “Un conjunto coordinado de programas, procedimientos, lenguajes,
etc. que suministra a los distintos tipos de usuarios los medios necesarios para describir y
manipular los datos almacenados en la base, garantizando su seguridad”3
El manejador de la base de datos se encarga de conectar la base de datos con las

aplicaciones que la emplean, tal como se presenta en la figura 3.
3
Piatinni, Mario G.; Marcos, Esperanza; Calero, Coral y Vela, Belén. Tecnología y Diseño de Bases de Datos. Ed.
Algaomega Ra-Ma. México, 2007. Pg. 36
Figura 3. Estructura del DBMS. ElMasri, Ramez., Navathe, Shamkant. Sistemas de Bases de Datos. 2ª edición.
Addison Wesley.
Funciones
Las funciones del DBMS se pueden agrupar en tres categorías: Funciones de definición o
descripción, Funciones de Manipulación y Funciones de control.
• Funciones de Definición o Descripción: Permite al diseñador de la base, especificar los

elementos que la integran, su estructura y las relaciones entre ellos.
• Funciones de Manipulación (de datos): Permite cargar, actualizar o consultar los datos
existentes en la Base de Datos. Las consultas pueden generarse sobre la totalidad de
los datos o un conjunto seleccionado de estos; la actualización permite realizar
inserción, borrado o modificación de los datos existentes.
• Funciones de Control: Integra diferentes actividades que facilitan las tareas del
administrador, tales como generar estadísticas de utilización, cargar archivos, manejo
de la seguridad, protección frente a accesos no autorizados o generar copias de
seguridad.
Lenguajes
Para cumplir las funcionalidades descritas, el DBMS dispone de diferentes tipos de
lenguajes:
 Lenguajes de Definición de Datos: Entre los que se incluyen Lenguajes de definición
de la estructura lógica global, lenguajes de definición de la estructura interna y
Lenguajes de definición de la estructura externa.
 Lenguaje de Manipulación de Datos (DML): Que permite al usuario establecer las
condiciones para la actualización de los datos en la Base de Datos.
MANEJADORES DE BASES DE DATOS

Entre los manejadores de Bases de Datos más utilizados actualmente se encuentran:
Oracle, DB2 (IBM), Informix, PosgreSQL, MySQL, Sql Server.
EL ADMINISTRADOR DE LA BASES DE DATOS (DBA)
El administrador de la Base de Datos es la persona encargada de crear, mantener y

actualizar el esquema de la base de datos, es el superusuario que asegura el correcto
funcionamiento de la Base de Datos en todo momento.
FUNCIONES
Las funciones del Administrador de la Base de Datos se pueden resumir de la siguiente
forma:
 Definir políticas de instalación física: Establece las políticas de la ubicación física
para el manejo de la base de datos, por ejemplo partición de disco en el que se
ubicará y las condiciones de instalación.
 Definir características técnicas servidor: Determina las características que debe
tener el servidor donde se alojará la base de datos, incluyendo capacidad de disco,
conexiones externas (a redes), capacidad de memoria.
 Definir el esquema de la base de datos: Definir el esquema de la base de datos que
se instalará, el cual se basa en el diseño establecido para la misma.
 Definir las estructuras de almacenamiento.
 Mantener las estructuras físicas y lógicas: Asegurar que las estructuras que se han
definido a nivel físico y lógico se mantengan en las mismas condiciones durante el
periodo de utilización de la base de datos.
 Autorizar el acceso: Crear usuarios y definir los privilegios respectivos para la
utilización de la base de datos.
 Resguardar los datos: Generar el esquema de copias de seguridad para mantener
la integridad de los datos contenidos en la base de datos.
BASES DE DATOS MULTIMEDIA
Las bases de datos multimedia han cobrado importancia en respuesta a los cambios en la
tecnología que se emplea tanto en los entornos sociales como empresariales. Hasta hace
algunos años, la información que se intercambiaba a muchos niveles era básicamente
texto, pero en la actualidad esta información involucra diversos tipos de datos que
incluyen imágenes, video, sonido, animaciones y texto, es decir, información multimedia.
Por otro lado, los avances tecnológicos han posibilitado labores de administración,
indexación y consulta sobre diversos tipos de datos (como imagen o audio), posibilitando
el desarrollo de los sistemas manejadores de bases de datos multimedia. No obstante,
siguen existiendo dificultades respecto a las bases de datos tradicionales, especialmente
en cuanto a la manipulación, almacenamiento y recuperación de los diferentes tipos de
datos, ocasionados principalmente por la dimensión de este tipo de datos.
¿CUÁL ES LA DIFERENCIA CON LOS DATOS MULTIMEDIA?

Algunos autores han planteado las diferencias fundamentales para el tratamiento de
datos multimedia, respecto a los tipos de datos, que se podrían llamar tradicionales
(números, fechas y caracteres). Dunckley4 propone tres aspectos que diferencian los datos
multimedia de otro tipo de datos:
 El tamaño: cuando se considera el almacenamiento de una imagen de buena

calidad puede requerir hasta 6Mb, un video de 5 minutos que maneje 30 frames
por segundo puede requerir 54Gb, una secuencia de audio típica ocuparía 8kb por
segundo; se entiende que el tamaño de los datos manejados afectará los procesos
de almacenamiento, recuperación y transmisión y que los algoritmos para
compresión de datos juegan un papel primordial.
 El tiempo: Los datos multimedia tienen una especial relación con el tiempo, ya que
estos deben desplegarse en el orden y momento apropiados para que tengan
sentido. Esta relación afecta, inevitablemente, la forma como los datos son
almacenados, recuperados, transmitidos y sincronizados.
 Semántica Natural de la multimedia: La semántica que manejan los datos
multimedia es mucho más compleja que la de los tipos de datos tradicionales, lo
cual dificulta la identificación de componentes que pueden ser usados para
recuperar o procesar una transacción. Debido a la dificultad de hacer consultas
directas sobre los datos multimedia, es necesario la inclusión de metadatos que
presenten la información significativa.
4
Dunckley, Lynne. Mutlimedia Databases. An object-relational approach. Ed. Addison-Wesley. Great
Britain. 2003. Pg. 6-9
MANEJADOR DE BASES DE DATOS MULTIMEDIA (MMDBMS)
Subrahmanian define el Manejador de Bases de Datos Multimedia como “el framework

que maneja los diferentes tipos de datos potencialmente representados en una amplia
diversidad de formatos sobre un amplio conjunto de fuentes” 5
Un Manejador de Bases de Datos Multimedia, debe realizar las mismas operaciones que
se han definido para cualquier DBMS, adicionalemnte, Subrahmanian establece las
siguientes habilidades adicionales que debe tener un MMDBMS6:
 Consultar datos en diferentes formatos.

 Consultar datos que han sido almacenados en diferentes medios.
 Recuperar objetos multimedia de forma continua y libre de interferencias.
 Responder a una consulta, desarrollando una presentación apropiada de la
respuesta, de acuerdo al formato del contenido.
5 Subrahmanian, V.S. Principles of Multimedia Database Systems. Morgan Kaufmann Publishers. USA.1998. Pg.5-6
6 Ibid.
REFERENCIA
 De Miguel, Adoración; Piattini, Mario. Fundamentos y Modelos de Bases de Datos. Ed.

Alfa Omega Ra-Ma. Mexico. 1999.
 Dunckley, Lynne. Mutlimedia Databases. An object-relational approach. Ed. Addison-

Wesley. Great Britain. 2003
 ElMasri, Ramez., Navathe, Shamkant. Sistemas de Bases de Datos. 2ª edición. Addison

Wesley
 Piatinni, Mario G.; Marcos, Esperanza; Calero, Coral y Vela, Belén. Tecnología y Diseño
de Bases de Datos. Ed. Algaomega Ra-Ma. México, 2007
 Subrahmanian, V.S. Principles of Multimedia Database Systems. Morgan Kaufmann

Publishers. USA.1998
II. MODELAMIENTO
El desarrollo de modelos en Bases de Datos tiene por objetivo representar las estructuras
de los datos en el mundo real, estableciendo las características necesarias de acuerdo al
contexto en que se trabaja.
A través de la historia se han empleado varios tipos de diagramas para representar los
modelos de datos, en lo referente a Bases de Datos Relacionales, durante mucho tiempo
se ha empleado el Modelo Entidad – Relación y más recientemente se ha hecho una
aproximación del Modelo de Clases de UML para realizar el modelamiento de datos. El
siguiente cuadro presenta diferentes notaciones para el modelado de datos.
Figura 5. Comparativo de los elementos en las principales notaciones de modelo de datos .Quintero, Juan B,;
Hernández, Diana M. y Yanza, Andrea. Directrices para la construcción de artefactos de persistencia en el proceso
de desarrollo de Software. En: Revista EIA, Numero 9, Julio 2008. Medellín. Pag. 77-90.
ELEMENTOS DEL MODELO RELACIONAL
Un modelo de datos relacional se compone básicamente de dos elementos: Uno que

representa las tablas que se implementarán finalmente en la base de datos y que
normalmente se denominan Entidades y las relaciones que se establecen entre estas
entidades.
Entidades: Una entidad es la representación de una “cosa” u “objeto” físico o lógico que
existe en el mundo real. Algunas reglas básicas permiten definir si un objeto es una
entidad válida para el modelo:
 Múltiples ocurrencias: Las entidades deben tener múltiples ocurrencias, si para el
modelo propuesto, solamente existe una ocurrencia de una entidad, debe
examinarse mejor, ya que lo más posible es que no se requiera modelar como
entidad independiente. Se entiende por ocurrencia un caso particular de la
entidad, por ejemplo la UAO es una ocurrencia de la entidad Universidad, Juan
Gómez es una ocurrencia de la entidad Estudiante.
 Múltiples atributos: Toda entidad contendrá atributos o características que la
definen, por ejemplo la entidad persona, puede tener como atributos: nombre,
edad, sexo, teléfono, dirección. Una entidad válida debe contener varios
atributos, si una entidad tiene solamente un atributo es posible que corresponda a
otra entidad.
 Exclusividad de ocurrencias: Las ocurrencias de una entidad deben pertenecer
solamente a ella; en ningún caso, una ocurrencia puede corresponder a dos
entidades. Por ejemplo, si todas las ocurrencias de la entidad Profesor, también
son ocurrencias de la entidad empleado, es muy probable que una de las dos
entidades sobre.
 Exclusividad de atributos: Cada atributo debe ser definido dentro de una entidad,
no es válido que el mismo atributo pertenezca a dos entidades diferentes. Por
ejemplo, si todos los atributos de la entidad programa se repiten en la entidad
grupo, es probable que una de las dos entidades sobre.
Observación: Dos entidades pueden tener atributos con el mismo nombre, siempre
y cuando no hagan referencia a lo mismo. Por ejemplo el empleado tiene código y
el departamento también tiene código; lo cual es válido si el primero se refiere al
código del empleado y el segundo al código del departamento.
Gráficamente las entidades se representan como clases, en las que se incluyen solamente
los atributos. Por convención el nombre de la clase (o entidad) se escribe en singular.
Por ejemplo:
PERSONA ESCENA
Atributos: Un atributo es una característica relevante de una entidad. Cualquier entidad

tiene múltiples atributos, pero es parte de la habilidad del diseñador definir cuáles son
necesarios para la situación que se quiere modelar.
Los atributos que se definan deben tener las siguientes características:
 Simplicidad: Cada atributo debe representar una única característica, no deben existir
atributos compuestos.
 Univaluados: Cada atributo debe tomar un único valor para cada ocurrencia de la
entidad.
 Exclusividad: Cada atributo debe ser exclusivo e independiente de los otros atributos
que se encuentren en la misma o en otra entidad.
 No calculables: Un atributo válido no es calculable a partir de otros atributos de la
misma o de otra entidad, ya que esto generaría redundancia y posible inconsistencia
de los datos.
 Dominio: Cada atributo tiene un dominio particular, es decir, un conjunto de valores
que puede tomar, este conjunto puede ser finito o infinito y enumerable o no
enumerable.
 Obligatoriedad: Dependiendo del modelo que se está representando, cada atributo es
obligatorio u opcional. Cuando se declara un atributo obligatorio, implica que para la
creación de la entidad es necesario que se conozca el valor de ese atributo, cuando se
declara un atributo opcional, implica que al momento de la creación de la entidad se
puede tener o no el valor del atributo.
Los atributos se escriben en singular, con un nombre corto que indique con claridad
aquella característica que representan. Para facilitar la implementación posterior de la
Base de Datos, conviene indicar el tipo de dato que se maneja en el atributo (carácter,
texto, numérico, booleano o fecha). Si un atributo es opcional, se puede indicar que su
multiplicidad es de 0 a 1 ([0..1]), entendiendo que puede presentarse 0 ó 1 vez.
Por ejemplo:
PERSONA
Nombre: texto
Cedula: numerico
Direccion: texto [0..1]
Telefono: numerico
Relaciones: Las relaciones en un modelo de datos, definen cuales entidades tienen alguna
relación con otra, estas relaciones pueden ser de múltiples tipos y nuevamente, serán
importantes o no, dependiendo de la situación que están representando.
En las bases de datos relacionales, cada relación es realmente una interrelación, es decir
que representa las dos relaciones que existen entre dos entidades (de la entidad A hacia la
entidad B y de la entidad B hacia la entidad A). Si la entidad Persona tiene una relación con
compra, es porque la entidad compra tiene una relación con persona.
Cada una de las relaciones tiene algunas características que la definen:
 Nombre: identifica la relación que representa, generalmente es un verbo de una o dos
palabras y debe ser claro, sencillo y representativo (se sugiere evitar verbos genéricos
como tiene o es).
 Sentido: Debido a que una relación, realmente representa dos relaciones, es
conveniente indicar el sentido en el que se está manejando la relación (de A hacia B o
de B hacia A).
 Cardinalidad: Indica el número de ocurrencias que pueden eventualmente participar
en la relación. Aunque se entiende que en una relación particular participa una
ocurrencia de cada entidad, la Base de Datos va a representar muchas relaciones en el
tiempo, por lo tanto, bajo esta consideración, las cardinalidades pueden ser múltiples
(con número definido de ocurrencias o con número indeterminado de ocurrencias).
Bajo este mismo concepto se puede incluir la obligatoriedad de la relación, de forma
que se especifique si la relación debe ocurrir siempre o no.
Por ejemplo:
El siguiente diagrama indica que existe una relación entre la entidad Persona y la Entidad
escena, pero no indica más características. La relación podría ser: crea, publica, juega,
termina, etc. por ello es importante indicar el nombre de la relación.
PERSONA ESCENA
Nombre: texto
Cedula: numerico Tipo: texto
Direccion: texto [0..1] Nivel: numerico
Telefono: numerico
El nombre de la relación, da mayor información sobre la misma y debería estar

acompañado de la dirección de la misma; en el siguiente caso sería: “Persona crea
escena”.
PERSONA ESCENA
crea
Nombre: texto
Telefono: numerico
Sin embargo, aún faltaría mucha información respecto a la relación: ¿cuántas personas
crean una escena?¿cuántas escenas puede crear una persona? ¿todas las persona debe
crear una escena o pueden existir personas que no creen escenas? ¿todas las escenas
deben ser creadas por una persona o pueden existir escenas anónimas?
Las respuestas a estas preguntas dependen del contexto de la aplicación, una empresa en
particular puede exigir que toda escena tenga una persona como creador, mientras para
otra empresa, este requisito no es necesario.
A continuación se especifica la cardinalidad de la relación, en este caso se indica que:

 Una persona puede crear de 0 a muchas (*) escenas, es decir que no todas las
personas crean escenas y una misma persona puede crear 1,2, 20, 100.. escenas.
 Una escena debe ser creada por 1 y sólo 1 persona. Todas las escenas tendrán un
autor y no más de uno.
PERSONA ESCENA
1 crea 0..*
Nombre: texto
Telefono: numerico
La cardinalidad de la relación se puede marcar con número exactos o con * para indicar
que son muchos. Por ejemplo:
1 Uno y solo uno

0..1 Cero o uno (equivalente a opcional)
1..2 Uno o dos
2..* 2 o más
Relaciones recursivas
La relación recursiva o auto-asociación, es una forma particular de relación que se puede
hallar en el modelo de datos es la relación recursiva, como su nombre lo indica se refiere a
relaciones de una entidad consigo misma.
Por ejemplo:
En este caso, la relación indica que una página puede enlazar a otra u otras páginas. Se
entiende que una página no enlaza a sí misma sino a otras ocurrencias de la misma
entidad.
Definición de claves o llaves

En una entidad, se define como identificador, llave o clave primaria, a un atributo o
conjunto de atributos que identifican inequivocamente cada ocurrencia de la entidad, es
decir que conociendo ese o esos atributos, se puede identificar una y solo una ocurrencia
de la entidad. (por ejemplo, el código de un estudiante permite identificar al estudiante,
pero si se conoce el primer nombre –Juan- no se podría identificar a un estudiante en
particular).
En el modelo relacional, es obligatorio definir una llave primaria para cada entidad, ya
que esta permitirá realizar las búsquedas y enlazar las entidades entre sí.
Para establecer la llave de una entidad se sigue este procedimiento:

1. Verificar si existe algún atributo que pueda identificar inequívocamente cada
ocurrencia de la entidad. Por definición, los atributos que identifican a una entidad
deben ser obligatorios. Por ejemplo: cédula de persona o código de estudiante.
1. Si no existe un atributo que pueda servir como identificador, verifique si puede
generarse un conjunto de atributos que puedan identificar la entidad. Por ejemplo:
fecha y número de compra.
2. Si no existe un conjunto de atributos que pueda identificar la entidad, adicione un
atributo que sirva como identificador, por ejemplo: consecutivo.
Para identificar la llave primaria, se empleará el estereotipo PK, el cual se incluye antes del
nombre del o de los atributos respectivos.
CLIENTE COMPRA
<<PK>> cedula: numerico <<PK>> fecha:fecha

Telefono: numerico <<PK>> consecutivo: numerico
Nombre: texto Valor:numerico
Descripcion: texto
Para el ejemplo anterior, el Cliente se identifica mediante la cedula y la compra tiene una
llave compuesta por fecha y consecutivo (en este caso se entiende que es un consecutivo
por fecha, al cambiar de día el consecutivo se reinicia).
OBSERVACIÓN: Debe recordarse que una entidad solamente tiene una llave primaria, si
varios atributos están estereotipados con PK, es porque la llave es compuesta.
Relaciones redundantes y ciclos
En ocasiones durante el desarrollo del Modelo Entidad – Relación, se incluyen algunas
relaciones que sí bien tienen información válida para el modelo pueden ser eliminadas sin
afectar la información que brinda el modelo; esta situación ocurre debido a que la
información que contiene la relación redundante puede ser recuperada a través de otras
relaciones.
Una forma de identificar las relaciones redundantes es identificando ciclos, en los cuales
se forma un circuito cerrado de relaciones entre tres o más entidades. Por ejemplo:
NOTA: Debe prestarse atención, ya que no todos los circuitos cerrados de entidades,
corresponden a ciclos, estos solamente se forman si las relaciones implicadas se refieren a
lo mismo.
Si se concluye que existe un ciclo, debe identificarse cuál es la relación redundante, es

decir aquella que se puede eliminar sin ocasionar pérdida de información.
Para el ejemplo, se puede revisar de la siguiente forma:
1. Supóngase que la relación redundante es la que existe entre PELICULA y ACTOR, si

esto es cierto, se debe poder recuperar esta información (cual actor participa en
cual película) a través de las otras relaciones, entonces:
Por la relación entre PELICULA y DIRECTOR, se puede saber cuál director dirige una
película en particular; por la relación entre DIRECTOR y ACTOR se puede saber a
cuales actores dirige ese director; pero como el director dirige varias películas y a
varios actores, no es posible conocer cuales actores participan en cuál película.
Conclusión: esta relación no se puede eliminar.
2. Supóngase que la relación redundante es la que existe entre PELICULA y DIRECTOR,
si esto es cierto, se debe poder recuperar esta información (cuál película ha sido
dirigida por cual director) a través de las otras relaciones, entonces:
Por la relación entre PELICULA y ACTOR, se puede saber que actores han
participado en una película en particular; por la relación entre DIRECTOR Y ACTOR
se puede saber cuál director ha dirigido a un actor en particular; pero como el
director dirige a varios actores y un actor puede participar en varias películas, no es
posible conocer cual director ha dirigido una película en particular. Conclusión:
esta relación no se puede eliminar.
3. Supóngase que la relación redundante es la que existe entre DIRECTOR y ACTOR, si

esto es cierto, se debe poder recuperar esta información (cuál director ha dirigido
a cuál actor) a través de las otras relaciones, entonces:
Por la relación entre ACTOR y PELICULA, se puede saber que actores han
participado en una película en particular; por la relación entre PELICULA y
DIRECTOR, se puede saber cuál director ha dirigido una película en particular;
ahora bien, si el director X dirigió la película Y, y en dicha película actuaron A y B, se
puede afirmar (sin lugar a equivocación) que el director X ha dirigido a A y B.
Conclusión: esta relación se puede eliminar.
El modelo quedaría entonces, de la siguiente forma, asegurando que no se ha perdido la

información.
¿Por qué es necesario eliminar las relaciones redundantes?

R// La presencia de relaciones redundantes en la Base de Datos puede
ocasionar inconsistencia en la información que se maneja; en el caso de
ejemplo, si no se elimina la relación redundante puede existir una relación
entre el director X y el actor A, sin que exista una película que los relacione.
¿Y si no eliminó las relaciones redundantes?
R// No eliminar relaciones redundantes se considera una mala práctica de
diseño, pero si se decidiera dejar alguna, debería controlarse directamente
a través del software el ingreso de información para asegurar que no
existan inconsistencias.
Rompimiento de relaciones muchos a muchos

Las relaciones muchos a muchos entre dos entidades no pueden ser representadas a nivel
físico en las bases de datos relacionales, por esta razón, este tipo de relaciones deben
cambiarse por relaciones uno a muchos, lo que se conoce comúnmente como
Rompimiento de relaciones muchos a muchos.
Al realizar un rompimiento de la relación muchos a muchos entre dos entidades A y B,

esta relación será sustituida por una nueva entidad, denominada entidad asociativa, que
representa la vinculación entre cada una de las ocurrencias de la entidad A y cada una de
las ocurrencias de la entidad B.
Esta nueva entidad, debe tener un nombre apropiado que indique la relación que
representa y las relaciones hacia las entidades que le dieron origen se deben establecer,
sin embargo, se pueden seguir algunas directrices:
 Las relaciones que salen de la entidad asociativa hacia las entidades que le dieron
origen deben ser obligatorias, ya que para que exista esta entidad deben existir
ocurrencias de las otras dos.
 Las relaciones que llegan a la entidad asociativa tienen cardinalidad múltiple (a
muchos), debido a que una ocurrencia de cualquiera de las otras entidades estará
asociada con varias ocurrencias en esta entidad.
 Las relaciones que llegan a cada una de las entidades origen tienen cardinalidad única
(a uno), debido a que cada ocurrencia de la entidad asociativa se vincula con una
ocurrencia de cada una de las otras.
 La obligatoriedad de las relaciones que salen de cada una de las entidades origen,
dependen de la relación original.
Por ejemplo: La siguiente figura muestra el rompimiento de la relación muchos a muchos

entre Película y Actor.
Una vez se establezca la entidad asociativa y se definan las relaciones, debe verificarse si
existen atributos que le correspondan a esta entidad, aunque puede ocurrir que no tenga
atributos propios.
¿No se supone que todas las entidades deben tener atributos?

R// Existe una excepción a esa regla y es justamente con las entidades
asociativas, las cuales pueden quedar sin atributos (aparentes).
Para este caso en particular (Actuación), se pueden incluir varios atributos que no son ni
de la película ni del actor sino que corresponden a la participación de un actor particular
en una película en particular. Como siempre, debe asegurarse la necesidad de guardar
esta información en la base de datos. Por ejemplo:
Como se mencionó, puede suceder que la entidad asociativa no tenga atributos propios,
no obstante, siempre debe tener un identificador o llave primaria. En estos casos, puede
recurrirse a emplear como llave primaria, la llave de una o varias de las entidades con las
que se relacionan.
En el caso anterior, los atributos incluidos en Actuación no sirven para identificar cada
ocurrencia de la entidad y por tanto no pueden ser llave primaria. En este caso
(entendiendo que cada actor actúa un solo papel en una película), se puede identificar la
entidad actuación, empleando la llave primaria de actor y la llave primaria de película.
Para representar esto en el diagrama de clases, se hará uso de otro estereotipo: <<FK>>,
que representa una llave foránea o heredada.
La llave foránea permitirá representar cada una de las relaciones cuando se implemente la
base de datos; en general, no es indican en el modelo de datos, sin embargo por claridad
cuando la llave primaria es heredada de otra entidad, se incluye la respectiva llave
foránea.
Por ejemplo:
Supertipos y subtipos
Cuando un grupo de entidades se pueden agrupar en un mismo conjunto y tienen
atributos y/o relaciones comunes, se puede emplear un esquema de Supertipo y Subtipo,
donde el Supertipo corresponde a la entidad que agrupa y en ella se incluyen los atributos
y relaciones que sean comunes a todas las entidades subtipo, estas últimas incluirán
solamente aquellos atributos o relaciones que le sean propios. Los subtipos que se
incluyan deben ser mutuamente excluyentes.
Los supertipos y subtipos se representan mediante relaciones de herencia entre las clases
involucradas. Tal como sucede en este tipo de relaciones, cada una de las clases puede
tener atributos y relaciones propias, además de las que tenga la clase padre.
Por ejemplo:
En este caso se representa que los empleados (supertipo) pueden ser de dos clases
(subtipos): fijos o temporales. Todos los empleados, independiente de su tipo, se
identifican con la cedula y deben tener un nombre, adicionalmente están asignados a un
departamento. Los empleados fijos son los únicos que tienen definido un salario. Los
empleados temporales tienen asignado un valor por hora y pertenecen a una empresa de
temporales.
Al igual que otras entidades, los supertipos y subtipos deben tener una clave o llave; si la
clave se ha definido para el supertipo (como en el ejemplo anterior), se entiende que es la
misma para todos los subtipos; de otra forma, cada subtipo deberá definir su propia clave.
¿Qué pasa si no se usan los supertipos y subtipos?

R// Debido a que el Modelo de datos es un modelo conceptual, el manejo
de supertipos y subtipos ayuda a representar mejor el mundo real,
identificando atributos comunes; sin embargo, no es obligatoria su
utilización, pero sí debe asegurarse que toda la información necesaria se
represente en el modelo; en el caso del ejemplo, deberían entonces
crearse dos entidades: empleado fijo y empleado temporal con sus
respectivos atributos y relaciones.
MEJORAMIENTO MODELO DE DATOS
Cuando se realiza el diseño de una Base de Datos, es común que se generen errores en la
medida en que avanza el proceso mismo, por ello es conveniente revisar algunos aspectos
(de lógica) para verificar que el modelo esté correcto7.
Aspectos a revisar:
1. Cada atributo debe ser único e indivisible, cada atributo de cada entidad debe
corresponder a un valor único para cada ocurrencia, no deben existir atributos
compuestos (que correspondan a una estructura de datos más que a un dato
atómico), ni atributos múltiples (varios valores del atributo para una misma ocurrencia
de la entidad).
Por ejemplo:
Sugiere que un empleado puede
tener varias áreas, lo cual no es
correcto.
SOLUCIÓN: Estos casos pueden seleccionarse de dos formas: separar el atributo dentro de
la misma entidad o crear otra entidad.
Si el atributo es compuesto, por ejemplo horario que en realidad incluye fecha y hora, se
pueden incluir los dos atributos (fecha y hora) en lugar de horario.
Si el atributo es múltiple, pero las ocurrencias son pocas y se conocen de antemano se

pueden incluir varios atributos (con diferente nombre) en la misma entidad, por ejemplo,
si se requieren dos teléfonos del cliente, se pueden establecer los atributos teléfono_casa,
teléfono_celular en lugar del atributo teléfonos.
Si el atributo es múltiple y tiene muchas ocurrencias o no se conoce con exactitud cuántas

ocurrencias pueden llegar a tener, es mejor incluirlo como otra entidad. Por ejemplo, un
sensor genera una medición, pero podrían ser muchas, entonces es mejor que la medición
en sí misma sea otra entidad.
7Este es el objetivo de la normalización de las Bases de Datos, sin embargo, si el diseñador es cuidadoso, cuando realice
su modelo, estará en Tercera Forma Normal y no será necesario normalizar.
2. Cada atributo dentro de la entidad debe corresponder a una característica de dicha
entidad y no de otra.
Por ejemplo:
Los atributos código_producto,

valor_unitario y
nombre_producto,
corresponden a otra entidad
(producto).
SOLUCIÓN: En estos casos, es mejor que se genere otra entidad que incluya los
atributos que le corresponden, por ejemplo, en el caso anterior, se generaría otra
entidad llamada Producto que incluye como atributos: código, valor_unitario y
nombre. Debe prestarse especial atención a la conformación de la llave primaria
en la entidad origen, en este caso, la llave de DETALLE_PEDIDO está formada por
número y código de producto, por lo cual, la clase DETALLE_PEDIDO, debe incluir
como llave primaria la llave foránea heredada de PRODUCTO.
3. Los atributos de las entidad asociativas deben corresponder a la relación que
representan y no a las entidades relacionadas.
En el ejemplo siguiente el rol del comisario, puede variar de un evento a otro, en un

evento un comisario puede ser principal y en otro evento el mismo comisario podría ser
auxiliar; en este caso el rol no puede asociarse al comisario porque puede variar, por lo
tanto, es un atributo de la relación.
Por ejemplo:
SOLUCIÓN: Debe revisarse que cada atributo incluido en una entidad corresponda
a ella, en caso de no ser así, ubicarse en la entidad que le corresponde.
4. Toda entidad debe tener un identificador (clave primaria).
SOLUCIÓN: Debe establecerse una llave primaria para cada entidad, si no se logra
definir una con los atributos existentes, debería adicionarse un atributo que pueda
ser empleado como llave primaria.
Modelo Relacional de Datos
El modelo Relacional de Datos o MRD fue introducido por Edgar Codd en 1970; es una
representación lógica de la Base de Datos y se puede entender como el paso intermedio
entre el modelo entidad – relación, que es el modelo conceptual de la base de datos, y su
implementación física.
Debido a que el MRD es otra representación de la Base de Datos, debe ser consistente
con el diseño realizado a través del Modelo de Datos.
¿Es obligatorio realizar el MRD?

R// Debido a que el Modelo Relacional de Datos es un acercamiento a la
implementación de la Base de Datos, permite definir algunos elementos
que no son claros en el Modelo de datos, por esta razón es recomendable
desarrollar el MRD.
En el MRD la información se presenta en tablas, cada una de las cuales tiene un nombre
definido y unos campos o columnas; a su vez, para cada campo debe declararse: el
nombre, tipo de dato que contiene, longitud, obligatoriedad, dominio y restricciones (si
tiene) y tipo de llave (si aplica).
Las definiciones que se hacen en el MRD, permiten establecer las llamadas restricciones de
integridad de la base de datos; de forma que el DBMS pueda realizar las validaciones
apropiadas sobre los datos. Existen diferentes tipos de restricciones de integridad:
 Integridad de entidad: ningún componente de una clave primaria puede ser null
(opcional)
 Integridad referencial: todo valor de una clave foránea debe existir en la clave
primaria a la que hace referencia o ser null.
 Integridad de columna: toda columna debe contener valores acordes con su dominio
y formato, por ejemplo, si se define una columna como numérica no debe aceptar
caracteres en su contenido.
 Restricciones del sistema impuestas por los usuarios: corresponden a las reglas del
negocio, por ejemplo, se define que las notas de un estudiante deben estar en el
rango [0.0, 5.0].
REPRESENTACIÓN
En el MRD cada tabla se representará con un nombre y 5 filas para cada campo o
columna, estos corresponden a:
<NOMBRE DE LA TABLA>
Nombre Es el nombre asignado al campo o columna
Corresponde al tipo de dato que almacenará el campo, se sugiere
emplear: Texto, Numérico, Fecha, Booleano.
Tipo Cuando el campo sea de tipo Texto, es conveniente incluir entre

paréntesis la cantidad de caracteres máximos que podría almacenar.
Los campos tipo Fecha, almacenan fecha y hora.

Define si el campo puede tener valor Nulo o no.
Un campo obligatorio, no puede ser nulo, entonces se marca como NOT
NULL.
Un campo opcional, puede tener valor nulo, entonces se marca como
Obligatoriedad NULL.
Se emplea para especificar si el campo es utilizado como llave, puede
ser:
PK – (Primary Key) Llave primaria, cuando el campo se emplea como

llave principal.
FK – (Foreign Key) Llave foránea, cuando el campo se emplea para
realizar el enlace con otra tabla, en cuyo caso, hereda la llave primaria
Función de la otra tabla.
Define las restricciones de dominio que tendrá el campo, por ejemplo un
rango o valores específicos.
Dominio
Si se requiere, puede adicionarse esta fila para hacer alguna aclaración
sobre el campo o dar un ejemplo del formato que se va a emplear.
Observaciones
NOTA: tanto el nombre de la tabla como el de los campos, deben iniciar con letras, no
incluir espacios o caracteres especiales y por incompatibilidad con algunos manejadores,
se sugiere no utilizar la letra Ñ.
PASOS PARA OBTENER EL MRD DESDE EL MODELO DE DATOS
1. Traducir las entidades o clases a tablas, nombrando cada tabla en plural.

2. Traducir cada atributo a una columna en la tabla correspondiente; los atributos
opcionales tiene obligatoriedad null – N (es decir que pueden ser nulos) y los atributos
obligatorios tienen obligatoriedad not null – NN.
3. Los identificadores primarios se traducen como claves primarias (PK) y los secundarios
como llaves alternas (AK).
4. Los dominios, formatos y conjunto de valores de los atributos se traducen como
dominio y restricciones.
Ejemplo:
Para el anterior Modelo de Datos, el Modelo de Datos Relacional equivalente para las
entidades sería:
CLIENTES
Nombre nombre login contrasena email
Tipo Varchar2(20) Varchar2(15) Varchar2(15) Varchar2(15)
Obligatoriedad NN NN NN NN
Funcion PK
Dominio
MEDIOS_PAGO
Nombre tipo numero fecha_venc
Tipo Varchar2(1) Number Date
Obligatoriedad NN NN N
Funcion PK PK
Dominio T','P'
Si se considera apropiado, puede incluirse un campo de comentarios u observaciones para

realizar anotaciones que pueden ser útiles para el DBA o el programador; por ejemplo el
significado de cada elemento del dominio (en tipo: T – Tarjeta, P – PayPal)
5. Cada relación se traduce como una llave foránea (FK). En una relación uno a muchos,
la relación que tiene el lado de muchos (subordinada) recibe la llave primaria de la
otra entidad como foránea. La obligatoriedad es determinada por el tipo de relación.
6. Para relaciones uno a uno, se presentan las siguientes situaciones:
a. Opcional – Obligatorio: se toma como maestro la entidad que se encuentra al
lado opcional y como detalle la del lado obligatorio. La entidad detalle lleva la
FK.
b. Opcional – Opcional: se toma como maestro la entidad que nace primero o que
tenga mayor permanencia en el tiempo.
c. Obligatorio – Obligatorio: son relaciones raras, pero si ocurren, se toma como
maestro la entidad que nace primero o que tenga mayor permanencia en el
tiempo.
MEDIOS_PAGO
Nombre tipo numero fecha_venc log_cliente
Tipo Varchar2(1) Number Date Varchar2(15)
Obligatoriedad NN NN N NN
Funcion PK PK FK(Clientes)
Dominio T','P'
7. Una relación exclusiva (o excluyente), se pueden resolver de dos formas:

a. Forma explícita: Se crea una clave foránea en el detalle por cada uno de los
maestros. El carácter excluyente de la relación se maneja por la aplicación,
pero se perdería la obligatoriedad.
b. Forma genérica: se crea una sola clave foránea para todos los maestros y una
columna para determinar el tipo de maestro. En este caso, los identificadores
deben tener el mismo tipo de formato y el DBMS controla la relación exclusiva;
el manejo de la integridad referencial es más difícil.
Para el caso:
La tabla de Canciones en la forma explícita, quedarían así:
CANCIONES
nombre codigo titulo Cedula_int codigo_orquesta codigo_grupovocal
tipo Numerico(6) Caracter(20) Numerico(12) Numerico(12) Numerico(12)
función PK FK(Interpretes) FK(orquestas) FK(Grupos_vocales)
obligatoriedad NN NN N N N
dominio
La tabla de Canciones en la forma genérica, quedarían así:
CANCIONES
nombre codigo titulo cod_interprete tipo_interprete
tipo y longitud Numerico(6) Caracter(20) Numerico(12) Numerico(1)
FK(solista u orquesta o
función PK grupo vocal)
obligatoriedad NN NN NN NN
dominio 1, 2, 3
8. Existen tres maneras de convertir el supertipo a tablas simples:
a. Una tabla para el supertipo: se considera el supertipo como una tabla simple con los
atributos del supertipo y los subtipos, se adiciona un atributo que indique el tipo de
subtipo la que se hace referencia. Se pierde la obligatoriedad de los atributos y de las
relaciones de los subtipos.
En este caso, se trata el modelo como si fuera de la siguiente forma:

EMPLEADOS
nombre cedula nombre salario valor_hora tipo
tipo y longitud numerico(12) Caracter(30) numerico(10,2) numerico(10,2) Caracter(1)
función PK
obligatoriedad NN NN N N NN
solo aplica si el
solo aplica si el tipo es T
tipo es F (Empleado
dominio (Empleado Fijo) Temporal) F, T
nombre cod_dpto nit_empresatemp

tipo y longitud Numerico(6) Caracter(20)
función FK(Departamentos) FK(Empresas_Temp)
obligatoriedad NN N
dominio
9. Una tabla por cada subtipo: se consideran los subtipos como entidades simples que
heredan los atributos del supertipo. No se pierde la obligatoriedad de los atributos y
relaciones de los subtipos, pero si la clave primaria es un consecutivo será más difícil
de manejar. Es mejor cuando se dispone de muchos atributos y relaciones propias a
cada subtipo.
EMPLEADOS_FIJOS
nombre cedula nombre salario cod_dpto
tipo y longitud numerico(12) Caracter(30) numerico(10,2) Numerico(6)
función PK FK(Departamentos)
dominio
EMPLEADOS_TEMPORALES
nombre cedula nombre valor_hora cod_dpto nit_empresatemp
tipo y longitud numerico(12) Caracter(30) numerico(10,2) Numerico(6) Caracter(20)
función PK FK(Departamentos) FK(Empresas_Temp)
obligatoriedad NN NN NN NN NN
dominio
a. Implementar los subtipos con un arco: se tiene una tabla para el supertipo y
una para cada subtipo. Se convierte de la forma como se trabajan los arcos.
Y se resuelve de alguna de las formas como se resuelven los arcos de exclusividad:
1) De forma genérica:
EMPLEADOS
nombre cedula nombre tipo cod_dpto
tipo y longitud numerico(12) Caracter(30) Caracter(1) Numerico(6)
FK(Departamentos
función PK )
dominio F, T
EMPLEADOS_FIJOS
nombre cedula salario
tipo y longitud numerico(12) numerico(10,2)
función PK, FK (Empleados)
obligatoriedad NN NN
dominio
EMPLEADOS_TEMPORALES
nombre cedula valor_hora nit_empresatemp
tipo y longitud numerico(12) numerico(10,2) Caracter(20)
función PK, FK (Empleados) FK(Empresas_Temp)
obligatoriedad NN NN NN
dominio
2) de forma explícita: Para implementar el modelo de forma explícita, cada subtipo

debería tener un identificador.
ACTIVIDADES
MODELO ENTIDAD - RELACIÓN

A continuación se describen algunos casos, para que el estudiante plantee el Modelo Entidad –
Relación que lo represente.
CASO 1: En una tienda de vídeo se rentan películas a las personas inscritas (que comúnmente se
conocen como socios). Los videos se rentan por un día si la renta ocurre en un día de semana o
dos si la renta ocurre un sábado. En general, se desea conocer datos sobre quienes son socios de
la video tienda (incluyendo una foto que se toma al momento de la inscripción), las películas
disponibles y los vídeos que ha rentado cada socio.
Para facilitar la búsqueda de las películas se dispondrá de un quisco que permitirá al usuario
consultar las películas por título, categoría, actores participantes o director; adicionalmente se
dispondrá de imágenes de la película, los actores y directores y en algunos casos del triller para
ayudar al usuario en su ubicación.
CASO 2: CINENACIONAL es la cadena de cine más grande del país, tienen distribuidos teatros
multiplex en diferentes ciudades, cada uno de los cuales incluye entre 4 y 10 salas. Se quiere
diseñar una base de datos, para almacenar los datos básicos de cada cliente (todos los clientes
tienen una tarjeta con la que realizan la compra de sus boletas), los datos de las películas que se
presentan y los datos básicos de las salas y teatros. La idea es que se puedan realizar consultas
sobre las películas más vistas, las películas que se presentan en determinada ciudad o teatro, las
ventas que se realizan a los clientes y las salas con mayor ocupación. Igualmente, la cadena de
cines quiere llevar un ranking de las películas que proyecta, para lo cual consulta entre 50 y 100
clientes que hayan asistido a una película su opinión de la misma (Excelente, Buena, Regular o
Mala).
CASO 3: Un grupo de estudiantes de la UAO quiere diseñar un sitio similar a e-bay, donde las
personas puedan inscribirse y participar en subastas virtuales sobre diferentes productos, para
ello, se requiere una Base de datos que pueda tener los datos de los productos en subasta, la
subasta misma (incluyendo fecha de inicio, fecha de terminación y precio base), la persona que
pone el producto en subasta y los diferente oferentes del mismo; igualmente las personas que
reciben los productos tendrán la posibilidad de calificar al vendedor, considerando si la descripción
que hizo del producto fue apropiada y el tiempo de entrega. Cada vendedor sube la información
que considere pertinente de su producto, lo cual puede incluir una descripción textual, imágenes,
vídeo o audio. Para facilitar la búsqueda, los productos se definen por categorías.
CASO 4: Una compañía productora de vídeos desea crear una aplicación que le permita almacenar
y acceder rápidamente a los diferentes productos que elaboran. Se sabe que la compañía tiene 4
sucursales en el país y en cada una de ellas se realizan producciones de diferente tipo, por
ejemplo, vídeos musicales, comerciales para televisión, cortometrajes y algunos largometrajes. Es
necesario que se conozca el o los directores de cada trabajo (pueden ser hasta 3), el o los
productores del mismo, aunque algunos trabajos no cuentan con productor, el cliente al que se le
realizó el trabajo (con sus datos de localización), la fecha de realización, los datos de la cuenta de
cobro que se entregó al cliente (el valor, fecha de entrega, persona que recibió la cuenta y fecha
de pago).
La aplicación debe permitir realizar búsquedas por tipo de producción, director, productor, cliente
o fecha de producción.
CASO 5: La empresa de servicio de Taxis "TAXISPERMANENTES" quiere implementar un sistema de

información que permita controlar los datos de los taxis que están afiliados, todos los clientes que
utilizan sus servicios, los dueños de los taxis, los conductores de los taxis y los servicios realizados;
toda esta información debe poderse consultar por parte de los dueños de los taxis o de la
empresa.
Sobre la información manejada, se sabe que:

• Un cliente puede solicitar más de un servicio.
• Cada servicio incluye una dirección, un cliente y una clave (con la cual se verifica que el
pasajero sea quien solicitó el servicio), además de la fecha y hora en que fue solicitado, y
la hora en que fue realizado.
• Una persona puede ser dueña de muchos vehículos.
• Un conductor puede trabajar para varios dueños de vehículos.
• Un conductor puede manejar varios vehículos.
• Un cliente puede llamar varias veces a solicitar servicios.
• A los vehículos se les ha asignado un código dentro de la empresa.
• Cada servicio es atendido por un vehiculo y un conductor.
CASO 6: Una compañía de Videojuegos está realizando una novedosa aplicación que permite a los
usuarios crear juegos de manera colaborativa, si el resultado es atractivo, es posible que la
compañía adquiera los derechos sobre él, si no es así, se dispondrá de forma gratuita para que
pueda ser jugado en línea.
Su equipo de trabajo ha sido contratado para desarrollar la base de datos que soporte la creación
del juego, el cual debe permitir crear el juego asignando un nombre, una imagen, un video de
introducción; igualmente debe permitir crear niveles del juego, cada nivel se compone de varias
escenas, en las escenas se encuentran elementos (para lo cual la compañía dispone de un librería
de elementos o el usuario puede adicionarlos) que pueden ser adaptados a la escena (esto implica
dar su ubicación, cambiar el tamaño, la textura, el color o girarlo n grados), igualmente cada
escena puede llevar una imagen de fondo (deben usarse las que dispone la compañía) y música
(esta debe ser provista por el usuario).
Considerando que la idea es que sea un trabajo colaborativo, varios usuarios pueden participar en
su creación, es decir que cada escena puede ser desarrollada entre varios usuarios y todos
aquellos que participen en la creación de escenas se considerarán autores del juego. Para esto,
cada usuario debe registrarse indicando sus datos básicos y una cuenta de correo electrónico que
servirá para contactarlo; la única condición es que un usuario no puede alterar algo que haya
hecho otro usuario, sin embargo la aplicación le permitirá enviar una sugerencia por correo
electrónico para realizar un cambio, todos estos comentarios deben quedar almacenados para su
posterior revisión.
CASO 7: En una tienda de vídeo se rentan películas a las personas inscritas (que comúnmente se
conocen como socios). Los videos se rentan por un día si la renta ocurre en un día de semana o
dos si la renta ocurre un sábado. En general, se desea conocer datos sobre quienes son socios de
la videotienda (incluyendo una foto que se toma al momento de la inscripción), las películas
disponibles y los vídeos que ha rentado cada socio.
Para facilitar la búsqueda de las películas se dispondrá de un quisco que permitirá al usuario
consultar las películas por título, categoría, actores participantes o director; adicionalmente se
dispondrá de imágenes de la película, los actores y directores y en algunos casos del triller para
ayudar al usuario en su ubicación.
Tenga en cuenta que de una película pueden existir varias copias en la tienda, las cuales se
identificarán con el código de la película más un consecutivo.
CASO 8: Una agencia matrimonial quiere desarrollar un software que le permita llevar un control
de las personas que se han inscrito, incluyendo sus datos personales como nombre, sexo, edad,
profesión, ciudad y país de vivienda, e-mail, una foto y si la persona está de acuerdo, puede incluir
un vídeo de presentación. Al momento de la inscripción cada persona escribe un pequeño texto en
donde indica sus preferencias acerca de las posibles parejas.
Igualmente se debe llevar control de las citas concertadas (hora, fecha y lugar) y cada uno de los
participantes escribe un comentario sobre la cita; si las personas involucradas en una cita llegan a
casarse, también se incluyen los datos del matrimonio. Una persona puede inactivarse cambiando
su estado a no disponible y obviamente cuando se casan, el estado cambia a casado, lo cual,
también lo inactiva.
REFINAMIENTO DEL MODELO

Para los casos que se presentan a continuación, realice el rompimiento de ciclos, rompimiento de
muchos a muchos y generación de claves, cuando se requiera.
CASO 10: Se quiere desarrollar una base de datos que soporte una aplicación para almacenar y
consultar accidentes de tránsito. Es necesario conocer la información propia del accidente (dónde,
cuándo y qué ocurrió exactamente); las personas implicadas, las cuales pueden ser conductores de
vehículos, pasajeros o peatones, igualmente se debe indicar si cada una de las personas sufrió
heridas o muerte en el accidente; los vehículos implicados, incluyendo su dueño y los seguros que
pueda tener (SOAT, seguro de accidentes, etc.); el agente de tránsito que sigue el caso.
CASO 11: En una Universidad se quiere tener una base de datos que tenga los datos de los
profesores que dictan cada una de las asignaturas y de los estudiantes que toman estas mismas
asignaturas. Se sabe que para cada asignatura se programan varios cursos por periodo académico
y obviamente, cada curso es asignado a un único profesor. Adicionalmente, debe verificarse que
un estudiante que desee tomar una asignatura haya aprobado el prerrequisito correspondiente
(un estudiante aprueba una asignatura si tiene una nota de 3.0 o superior).
CASO 12: CINENACIONAL es la cadena de cine más grande del país, tienen distribuidos teatros
multiplex en diferentes ciudades, cada uno de los cuales incluye entre 4 y 10 salas. Se quiere
diseñar una base de datos, para almacenar los datos básicos de cada cliente (todos los clientes
tienen una tarjeta con la que realizan la compra de sus boletas), los datos de las películas que se
presentan y los datos básicos de las salas y teatros. La idea es que se puedan realizar consultas
sobre las películas más vistas, las películas que se presentan en determinada ciudad o teatro, las
ventas que se realizan a los clientes y las salas con mayor ocupación.
CASO 13: Una compañía de transporte de mercancías, está diseñando la Base de Datos para el
control de sus operaciones; sobre estas se sabe que los clientes pueden enviar o recibir paquetes
de la compañía, por facilidad, cada cliente se identifica mediante el número telefónico y de ellos se
debe conocer una identificación (si es una persona natural), el nombre, la dirección y algunas
observaciones (que se usa principalmente si el cliente es una institución). Un cliente puede remitir
varios paquetes, si todos van al mismo destino, entonces se agrupan en un envío que se radica con
un número, la fecha y hora de envío y se guarda el valor del envío. Por su parte, cada paquete
incluye un consecutivo por envío y se hace una descripción, para cierto tipo de mercancías debe
incluirse el valor aproximado del paquete, por posibles reclamos de seguros.
Los envíos son transportados en camiones, aunque puede ocurrir que un camión solamente haga
una parte del recorrido del paquete; cada camión cubre una ruta entre dos ciudades, aunque
también podría ser un recorrido interno dentro de una ciudad.
NORMALIZACIÓN
Para los siguientes casos, debe verificarse que el modelo está en 3FN y si no es así, debe llevarse a
esa forma normal, si el
CASO 14: Se quiere desarrollar un sistema de información para las consultas en el centro médico
“SANITOS”, sobre el sistema, se tiene la siguiente información:
 Un médico atiende a muchos paciente y puede llegar a atender a un paciente en varias

ocasiones.
 Un paciente puede ser atendido por varios médicos.
 A los pacientes se les realiza un cobro por cada consulta (denominado copago), el cual
varía de acuerdo al estrato al que pertenezca el paciente.
 Los médicos tienen diferentes especialidades y un médico puede tener varias de ellas, por
ejemplo puede ser anestesiólogo y cardiólogo.
 Para cada paciente, es importante conocer la EPS a la cual se encuentra afiliado.
 Es importante poder localizar a los médicos, en caso de emergencia, por lo cual, siempre
se solicita que proporcionen la información de tres teléfonos.
 Cada médico tiene un número de matrícula, que es único.
 Cuando ingresa un nuevo paciente para atención, se le asigna un número consecutivo
dependiendo la EPS a la que pertenezca.
 Cuando se realiza una consulta, se deben indicar las observaciones que realiza el médico,
el diagnóstico y una descripción general del tratamiento definido (estos campos se
manejan como texto).
CASO 15: Una empresa de mensajería desea llevar un control más preciso de los paquetes que
transporta, para ello requiere información de los mismos, tales como la fecha, la descripción
general, la dirección y nombre del destinatario y el número asignado a la guía (número único
definido para cada paquete); igualmente se quieren almacenar los datos de ubicación de los
clientes que envían los paquetes, con la intención que la próxima vez que un cliente desee enviar
un paquete no tenga que dar nuevamente sus datos (solamente si han cambiado). Se debe
almacenar también la ciudad de origen y de destino de cada paquete (puede ser la misma), cada
ciudad tiene un código único, un nombre y una zona a la cual pertenece.
Se sabe que un paquete puede estar compuesto de varios artículos, por ejemplo Juan Pérez envía
el paquete número 01200 y en este envía dos libros, un reloj y una loción; por ello es necesario
conocer todos los artículos que componen cada paquete (su peso, descripción y valor
aproximado), como medida de control, los artículos se numeran de forma consecutiva por cada
paquete.
El director de logística, al saber que se estaba desarrollando una Base de Datos, solicitó que se
incluyeran los datos de los camiones que transportan los paquetes, sabiendo que un paquete
desde su origen hasta su destino puede ser transportado por varios camiones. En la empresa cada
camión está identificado mediante un código asignado al momento de comprar el camión.
CASO 16: En una Universidad se quiere tener una base de datos que almacene los datos de los
CASO 17: En la empresa EQUIPOS INDUSTRIALES, tienen diferente clase de equipos que
distribuyen en sus departamentos, cada equipo se encuentra a cargo de un empleado, que debe
responder por el mismo y en caso de ausencia, el jefe de ese empleado, será quien responda por
el equipo. La empresa requiere una base de datos que le permita conocer sobre los
mantenimientos que se solicitan y/o realizan a cada equipo, incluyendo los datos de la persona
que realizó el mantenimiento, que puede ser un empleado de la empresa o una persona externa
que se contrata para tal fin; igualmente debe tenerse información de las piezas que se cambian
durante el mantenimiento, indicando cuál pieza se elimina del equipo y cual pieza entra a
remplazarla.
CASO 18: En una empresa se quiere llevar un estricto control de sus pedidos. Cada pedido se
compone de varias líneas, en cada una de las cuales se determina un artículo solicitado con su
código y nombre, la cantidad que se solicita, su precio unitario, el precio total por dicho artículo y
el porcentaje de descuento sobre el mismo.
CASO 19: En la venta de autos “El pichirilo” se quieren guardar los datos de cada venta que se
realiza, incluyendo datos del auto, el vendedor y la venta misma. Es necesario aclarar que cada
vendedor tiene un porcentaje de comisión asignado, el cual es invariable, independiente del valor
de la venta que realice. Igualmente, se tiene establecido, que en ciertas fechas se realizan
descuentos especiales.
NOTA: Si observan bien, la entidad no tiene clave, por lo tanto, su primer trabajo es determinar la
clase apropiada.
CASO 20: Se desea implementar una base de datos para una biblioteca, de forma que se puedan
consultar rápidamente los datos de los libros bien sea por título, por el código asignado en la
biblioteca, por el nombre de algún autor o por el tema al que pertenecen; igualmente se quiere
consultar los nombres de las personas que han prestado el libro (lectores), ordenado por apellido.
Un estudiante de la UAO planteó el siguiente modelo entidad – relación que al parecer no se

encuentra en 3FN, su trabajo es llevarlo a 3FN y asegurar que el modelo sea consistente.
Sugerencia: establezca primero la llave primaria.
CASO 21: En un restaurante se contratan diferentes chefs para que construyan los menús que se
ofrecerán a los clientes, cada menú tiene un tiempo de vigencia, por ello es importante
determinar cuál es el que está vigente. Cada menú incluye varios platos que serán presentados a
los clientes con el nombre respectivo y el valor comercial, pero para el trabajo interno del
restaurante se debe conocer cuáles ingredientes (nombre, cantidad y valor promedio) se incluyen
en el plato, cuál es el valor real del plato, el número de veces que se ha pedido en el restaurante y
la receta, está última se maneja como un archivo de texto.
Inicialmente se ha definido el siguiente modelo, que debe ser revisado y llevado a 3FN y ajustado.
CASO 22: En una organización se desarrollan diferentes proyectos, los cuales son asignados a un
departamento específico, cada proyecto tiene asignado un número consecutivo por
departamento, nombre, presupuesto total, un periodo de trabajo (desde qué fecha y hasta qué
fecha se realizará), una duración real (puede ser diferente a lo planeado inicialmente), un
encargado (que debe pertenecer al departamento del proyecto), unos participantes (que también
son empleados del departamento) y una actividades definidas, para cada actividad se tiene un
nombre, fecha de inicio, fecha de fin y si tiene otra actividad predecesora, es decir, si se debe
terminar otra actividad antes de realizar esta (cada actividad tiene máximo una predecesora).
Uno de los encargados de sistemas en la empresa, empezó a realizar el modelo pero no lo

terminó, usted debe llevarlo a 3FN y realizar los ajustes necesarios para que quede completo.
CASO 23: Una asociación de ingenieros internacional ha decidido desarrollar una Base de Datos
que le permita llevar el control de sus publicaciones seriadas (revistas). Cada revista tiene un título
y un código internacional llamado ISSN, cada publicación de la revista tiene se identifica con un
volumen (que generalmente corresponde al año) y un número y corresponde a un periodo en
particular (por ejemplo, enero – mayo de 2012).
Generalmente se hace convocatoria abierta para las publicaciones, es decir, que se reciben
artículos de forma permanente para ser evaluados, los artículos deben ser entregados en formato
pdf, pero debe entregarse de forma separada un resumen del mismo; cada artículo debe incluir un
titulo en español y en ingles, el o los temas que trata (generalmente se toman de un listado de
temas que maneja la asociación), los autores (incluyendo nombre, grado académico, institución a
la que pertenecen y e_mail); cuando se recibe un artículo se le asigna un código y se envía a
evaluar por parte de 2 ó 3 personas, dependiendo de la temática.
De los evaluadores se tienen sus datos básicos (nombre, identificación, profesión, grado
académico), los datos de la institución a la que se encuentre vinculado (siglas, nombre, web
institucional) y el o las área(s) de trabajo que maneja, este último dato facilita la asignación de
evaluadores para los artículos. A los evaluadores se les paga una comisión por el trabajo de
evaluación del artículo, la cual depende del grado académico que tenga.
Cada evaluador, califica en una escala de 1 a 10 cuatro aspectos del artículo: calidad, pertinencia,
aplicabilidad y desarrollo general; de acuerdo a las calificaciones que den los evaluadores, la
asociación decide publicar o no el artículo y en cual revista hacerlo. Para asegurar la transparencia
del proceso, se guardan las evaluaciones de todos los artículos.
Notas: En la entidad artículo, el numero_paginas indica la cantidad de páginas del artículo.

En la entidad Publicación, paginas indica la página de inicio y fin de un artículo.
CASO 24: En una Universidad se quiere tener una base de datos que tenga los datos de los
MODELAMIENTO
Para cada uno de los casos planteados, presente:
 Un modelo entidad-relación inicial.
 Indique en qué forma normal se encuentra el modelo (justifique) y si es necesario, indique
los cambios requeridos para llevarlo a 3FN.
 Presente el modelo entidad – relación final que se encuentre en 3FN, no tenga ciclos ni
relaciones muchos a muchos.
 Presente el Modelo Relacional de Datos equivalente al MER presentado.
CASO 25: En el torneo de fútbol profesional colombiano participan equipos de las principales
ciudades del país de las cuales necesitamos conocer su población, altura y temperatura promedio.
Hay ciudades que tienen más de un equipo y deben tener por lo menos un estadio, del cual
necesitamos conocer su nombre, la ciudad de ubicación el equipo al cual pertenece, su capacidad
y el largo y ancho de la cancha. Todo equipo debe tener un estadio aunque los estadios pueden
ser compartidos por varios equipos.
Los equipos tienen un grupo de jugadores, unos en préstamo y otros propios. Los jugadores no
pueden cambiar de equipo durante el campeonato pero nos interesa saber en qué equipos han
jugado y quién es el dueño de su pase. Ellos se identifican por un código dado por la FIFA y
guardamos sus apellidos, nombres, equipo al cual pertenecen, equipo en el cual están jugando
actualmente, número de goles anotados en el presente campeonato y número de tarjetas
amarillas y rojas acumuladas en el presente campeonato.
En los partidos de cada fecha un equipo juega de local y otro de visitante; aunque no siempre se
juega en el estadio del local. De cada partido registramos las alineaciones de cada equipo y sus
goles, el estadio en el cual se jugó, el número de personas que asistieron, el valor de la taquilla, las
tarjetas amarillas y rojas y los jugadores a quienes se las impusieron, los goles anotados por cada
jugador, los cambios que se realizaron, el árbitro central y los jueces de línea. De los árbitros
guardamos su código dado por la FIFA, apellidos, nombre y tiempo de experiencia.
Aunque es información derivable, también guardamos la tabla actualizada de posiciones del
campeonato, para no calcularla cada vez que se consulta. Esta tabla contiene la posición del
equipo, el número de partidos jugados, empatados y perdidos, el número de goles a favor y en
contra y el número total de puntos.
CASO 26: La editorial ABC trabaja con varios autores diferentes que escriben los libros que publica
y normalmente lleva registro del título del libro, su número de páginas, código, los nombres de los
autores, su cédula, dirección y teléfono.
Algunos de nuestros autores han escrito sólo un libro, mientras que otros han escrito varios;
además, algunos libros tienen coautoría. Los libros tienen un autor principal y algunos un coautor
o varios. Obviamente, es necesario sabe quién es su autor principal o quienes sus coautores.
ABC también trabaja con múltiples imprentas de las cuales registra su nombre, dirección y
teléfono. Un libro dado lo imprime una sola imprenta.
Los editores, empleados de ABC, trabajan con diversos autores al mismo tiempo, editando y
produciendo sus libros; es labor del editor dar a la imprenta la copia final y revisada y esto lo hace
sólo un editor. Llevamos un registro histórico de qué autores han trabajado con qué autor.
Cada autor recibe un salario mensual básico, diferente para los distintos editores; además, recibe
también una comisión por cada libro editado y producido ese mes, que depende de la antigüedad
del editor y el número de páginas del libro. ABC necesita esta información para poder pagar a sus
editores cada mes8.
CASO 27: En una galería de arte se quiere llevar la información de las exposiciones realizadas, los
artistas contratados y los cuadros vendidos; se le ha solicitado a su equipo de trabajo que diseñe
una base de datos que permita recoger la siguiente información:
 Fechas y nombre de las exposiciones realizadas (considere que las exposiciones duran
entre 1 y 3 semanas).
 Fecha y costo del lanzamiento de la exposición, refiriéndose al acto con el que se da inicio
a la exposición; en general es el primer día de la exposición, pero en algunas ocasiones se
ha realizado el lanzamiento hasta una semana antes de iniciar la exposición.
 Nombre de las obras expuestas en cada exposición.
 Fecha de creación de una obra en particular (en general los artistas solamente incluyen el
año, pero algunos incluyen mes y año).
 Nombre del o de los artistas que se incluyeron en una exposición.
 Datos de contacto de un artista (dirección, teléfono fijo, celular, ciudad, e-mail, usuario en
Facebook, usuario en twitter, página web).
 Nombre y ubicación de los clientes, es decir, las personas que han comprado cuadros en la
galería.
 Nombre de la persona que compró un cuadro en particular.
 Estilo y técnica utilizada en cada obra expuesta.
 Nombre del artista que desarrolló cada obra expuesta o vendida en la galería.
 Nombre de los clientes que han comprado obras de un artista en particular.
 Datos de cada compra: fecha, valor, nombre de la obra, nombre del artista, nombra del
cliente, forma de pago (efectivo, tarjeta debito, tarjeta crédito, cheque).
 Comentarios que han realizado los clientes sobre una obra o una exposición.
8
Tomado de Notas de Clase: Ingeniería de Software. ICESI. Guillermo Londoño.
REFERENCIAS
 Quintero, Juan B,; Hernández, Diana M. y Yanza, Andrea. Directrices para la

construcción de artefactos de persistencia en el proceso de desarrollo de Software.
En: Revista EIA, Numero 9, Julio 2008. Medellín.
 ACM. A Relational Model of Data for Large Shared Data Banks Communications of
the ACM, Vol. 13, No. 6, June 1970, pp. 377-387
III. PROGRAMACION
SQL
SQL nació como un lenguaje especializado para realizar consultas en Bases de Datos Relacionales,
aunque como se verá posteriormente puede realizar muchas más operaciones. Fue propuesto por
E. F. Cood a principios de los años 80. En 1986 se generó el primer estándar ANSI sobre SQL. En
1999 se propone el llamado SQL3 o SQL:1999 que extiende las capacidades de SQL incluyendo
opciones para el manejo de objetos.
Entre las principales característica del SQL se encuentra su simplicidad, lo que permite que
personas no expertas en el manejo de Bases de Datos puedan emplearlo para realizar consultas y
operaciones sencillas y la portabilidad, que brinda la opción de ser utilizado por diferentes
manejadores de bases de datos relacionales. Adicionalmente SQL establece reglas para el manejo
de la base de datos, de tal forma que se asegura la integridad y consistencia de los datos.
CREACIÓN DE LA BASE DE DATOS

En algunos manejadores de Bases de Datos se puede crear la Base de Datos a partir de la línea de
comandos, MySQL es uno de ellos. Para crear la base de datos se emplea la siguiente sintaxis:
CREATE DATABASE <nombre> ;
Por ejemplo:
CREATE DATABASE nomina; lo cual creará una base de datos llamada nomina
Una vez creada la base de datos se puede empezar a trabajar con ella, basta seleccionarla cada vez
que se vaya a trabajar con ella, para esto se emplea el comando USE.
Por ejemplo:
USE nomina;
TIPOS DE DATOS
SQL maneja tipos de datos estándar, sin embargo algunos manejadores han hecho variación sobre
estos datos; la tabla a continuación presenta los tipos estándar de SQL y su equivalente en Oracle.
Tabla 1 Tipos de datos de SQL
Estándar SQL Descripción Especificación de MySQL
CHAR(n) o CHARACTER(n) Cadenas de longitud fija de n CHAR (n)

caracteres.
CHAR VARYING(n) o Caracteres de longitud VARCHAR (n)9

CHARACTER VARYING(n) variable, n es la longitud
máxima en bytes.
INTEGER, SMALLINT o INT Números enteros INTEGER, SAMLLINT
Puede especificarse el ancho a

mostrar en un tipo entero, si
se especifica el tamaño, por
ejemplo INT (5).
NUMERIC (p,n) Números decimales de DECIMAL, NUMERIC, FLOAT,

precisión p, con n dígitos REAL, DOUBLE PRECISION.
después del punto decimal.
Para los tipos DECIMAL y
NUMERIC, se puede
especificar la precisión y
escala, por ejemplo
DECIMAL(7,3), en este caso, 7
representa la precisión, que es
el número de decimales
significativos que se van a
almacenar y el 3 es la escala,
que indica el número de
dígitos que se almacenan
después del punto decimal.
9
Últimas versiones de MySQL solamente aceptan VARCHAR, a diferencia de Oracle donde el VARCHAR
fue reemplazado por VARCHAR2.
DATE Datos fecha y hora. DATETIME, DATE, TIMESTAMP,
TIME y YEAR.
BLOB Binary Large Object (objetos TINYBLOB, BLOB,

binarios grandes). MEDIUMBLOB, LONGBLOB.
Estos tipos de datos se tratan

como cadenas binarias de
datos.
TEXT TINYTEXT, TEXT,

MEDIUMTEXT, LONGTEXT.
Estos tipos de datos se tratan

como cadenas de caracteres.
CREACIÓN DE TABLAS
Para la creación de una Bases de datos a través del manejador, básicamente se deben crear las
tablas que se incluyen en la base de datos, especificando sus características.
La instrucción para crear tablas es la siguiente:
CREATE TABLE <nombre_tabla>

(<lista de definición de la columna>, PRIMARY KEY (<nombre columna>));
En la lista de definición de la columna, debe especificarse el nombre de la columna (o campo), el

tipo y longitud (si se requiere).
Por ejemplo:
CREATE TABLE clientes (

nombre Varchar(20),
login Varchar(15),
contrasena Varchar(30),
email Varchar(30)
);
CREATE TABLE album (

caratula BLOB,
nombre Varchar (20),
anho Year,
precio Decimal(10,2)
);
Restricciones
Para adicionar restricciones a las columnas se pueden emplear las palabras que se muestran en la
siguiente tabla:
Tabla 2 Palabras clave para definir restricciones
Palabra Descripción
Not Null El campo es obligatorio
Unique El valor del campo no se puede repetir
Primary Key El campo es llave primaria
Foreign Key El campo es llave foránea
Check El campo tiene una restricción que debe chequearse

(por ejemplo para los posibles valores que puede
tomar).
Algunas de estas restricciones se pueden incluir en la definición de la columna, otras se deben

incluir al final de la definición de la tabla.
Por ejemplo:
CREATE TABLE clientes (

Nombre Varchar(20) NOT NULL,
login Varchar(15) NOT NULL PRIMARY KEY,
contrasena Varchar(30) NOT NULL,
email Varchar(30) NOT NULL
);
En el caso anterior, se está especificando que todos los campos son obligatorios y que el
login es la llave primaria de la tabla.
CREATE TABLE album (

caratula BLOB,
nombre Varchar(20) NOT NULL,
anho Integer NOT NULL,
precio Decimal(10,2) NOT NULL ,
CONSTRAINT album_pk PRIMARY KEY(nombre ,anho),
CONSTRAINT anho_album CHECK (anho > 0)
);
En el caso anterior, se puede observar que el campo caratula, de tipo BLOB, no es un
campo obligatorio (por ello no tiene la restricción NOT NULL), los otros campos sí son
obligatorios10.
La llave primara es una llave compuesta de nombre y anho, por esta razón no puede
incluirse en los nombres de las columnas (sería como si tuvieras dos llaves primarias lo
cual no es válido), en estos casos, debe crearse una restricción (CONSTRAINT) a la cual se
asigna un nombre que la identifique (album_pk), se indica que restricción de llave primaria
(PRIMARY KEY) y los campos que la conforman (nombre y anho).
Finalmente se ha adicionado una restricción que permite asegurar que el valor del año sea
mayor que 0, nuevamente se indicar que es una restricción (CONSTRAINT), se le agrega el
nombre (anho_album) se indica que es una restricción de chequeo (CHECK) y se incluye la
condición respectiva (anho >0).
CREATE TABLE medio_pago (

tipo varchar(1) NOT NULL,
numero Integer NOT NULL,
fecha_vencimiento Date NULL,
log_cliente Varchar(15) NOT NULL,
CONSTRAINT mp_pk PRIMARY KEY(tipo,numero),
CONSTRAINT mp_check CHECK (tipo In ('T','P')),
CONSTRAINT mp_fk FOREIGN KEY(log_cliente) REFERENCES clientes(login)
);
La restricción FOREIGN KEY marca la llave foránea de la tabla, en este caso se incluye un nombre
para la restricción (mp_fk), el tipo de restricción (FOREIGN KEY), el campo dentro de la tabla actual
que es llave foránea (log_cliente) y la referencia, que indica a cuál campo (login) de cuál tabla
(clientes) hace referencia esta llave foránea.
Adicionalmente, en la restricción de llave foránea se pueden incluir dos instrucciones que ayudan
a mantener la integridad de las tablas:
 ON DELETE CASCADE: indica que si se elimina la fila en la tabla padre, se eliminen las filas
relacionadas en las tablas hijas.
 ON DELETE SET NULL: cuando se elimina un valor en la tabla padre, los valores de las llaves
foráneas en las hijas se vuelven nulos.
10
Inicialmente no se van a ingresar datos de tipo BLOB, así que es conveniente dejar como NULL
(opcionales), todos los atributos de este tipo.
AUTOINCREMENTO
MySQL tiene una opción para manejar los tipos consecutivos o autoincrementales, con los cuales
se genera de forma automática un identificador único para cada nueva fila de la tabla; para ello,
basta adicionar a la definición de la columna la palabra AUTO_INCREMENT.
Por ejemplo:
CREATE TABLE documentos (

Consecutivo INTEGER NOT NULL AUTO_INCREMENT,
Descripción VARCHAR(50) NOT NULL,
PRIMARY KEY(consecutivo) );
MODIFICACIÓN DE TABLAS
Una vez creadas las tablas es posible que se requiera hacer cambios sobre la estructura de las
mismas, las siguientes instrucciones permiten realizar estos cambios:
1. Renombrar una tabla: Permite cambiar el nombre de la tabla después que ha sido creada-
ALTER TABLE <nombre_actual_tabla>

RENAME <nuevo nombre_tabla>
Por ejemplo:
ALTER TABLE Clientes
RENAME Usuarios;
2. Adicionar columnas a una tabla: Permite agregar columnas a una tabla ya creada, debe
tenerse en cuenta que esta nueva columna no puede tener restricción Not Null, especialmente
si ya existen datos ingresados en la tabla.
ALTER TABLE <nombre_tabla>
ADD <columna> <definiciones>
Por ejemplo:
ALTER TABLE clientes
ADD tipo_pago varchar(10) NULL;
Modificar una columna de una tabla: Permite variar las especificaciones de una columna en
una tabla, nuevamente debe tenerse en cuenta que si ya existen datos ingresados en la tabla,
los cambios admitidos sobre la columna serán limitados.

MODIFY <columna> <definiciones>
Por ejemplo:
MODIFY login varchar(45) NOT NULL;
3. Borrar una columna de una tabla: Permite eliminar una columna de una tabla, esta operación
será posible si no corresponde a una llave primaria o foránea.

DROP COLUMN <columna>
Por ejemplo:

DROP COLUMN tipo_pago;
4. Renombrar una columna de una tabla: Permite cambiar el nombre a una columna de una
tabla, esta operación será posible si no corresponde a una llave foránea.

CHANGE <columna> <definición nueva columna>
Por ejemplo:

CHANGE contrasena password VARCHAR(30) NOT NULL;
5. Adicionar restricciones de una tabla: Esta operación permite adicionar restricciones a una
tabla, esta operación será válida si la columna sobre la cual se implementa la restricción no
tiene valores.

ADD CONSTRAINT <restriccion>
Por ejemplo:

ADD CONSTRAINT cliente_u UNIQUE (password);
6. Borrar una tabla: Esta operación borrará todos los datos de la tabla y su estructura de la Base
de Datos, nuevamente debe considerarse si la tabla que se pretende eliminar se encuentra
enlazada a otra mediante una llave foránea y que tipo de borrado se implementó en la llave
foránea.
DROP TABLE <nombre_tabla>;
Por ejemplo:
DROP TABLE clientes;

MANIPULACIÓN DE DATOS
Una vez creada la estructura de la base de datos, puede realizarse la manipulación de datos, con lo
cual se pueden insertar nuevos registros, borrarlos o modificarlos; las instrucciones para realizar
estas operaciones se presentan a continuación.
1. Insertar datos en la tabla: Para insertar datos en la tabla se emplea la instrucción INSERT
INTO, la cual varía si se van a insertar todos los campos de la tabla o solamente algunos.
Si se van a insertar todos los campos de la tabla, en el orden definido al crearla, la instrucción
es la siguiente:
INSERT INTO <nombre_tabla>

VALUES (<valores>);
Por ejemplo:
INSERT INTO clientes

VALUES (‘Juan Perez’,’jperez’,’232323’,’jperez@hotmail.com’);
Por otra parte, si no se van a insertar todos los campos de la tabla o se quieren insertar en un
orden diferente al que se estableció cuando se creó la tabla, es necesario indicar los nombres
de las columnas (o campos) a insertar:
INSERT INTO <nombre_tabla> (<columnas>)

VALUES (<valores>);
Por ejemplo:
INSERT INTO medio_pago (tipo, numero, log_cliente)

VALUES (‘T’,123456789,’jperez’);
INSERT INTO medio_pago (numero, tipo, log_cliente,fecha_vencimiento)

VALUES (987654321,’P’,’jperez’,’07-08-11’);
NOTA: En MySQL el tipo de dato DATE se almacena en formato YYYY-MM-DD, aunque existen
varias formas de realizar la inserción: '03-05-21’, '04.05.21', '05/05/21', '06@05@21', NOW();
Observación 1: Debe tenerse en cuenta que las columnas o campos no insertados deben ser no
obligatorios, de otra forma se generaría un error en el proceso de inserción.
Observación 2: Los campos marcados con AUTO_INCREMENT no deben insertarse en la tabla,

ellos serán insertados automáticamente por el manejador.
2. Modificar datos de la tabla: Una vez insertados los datos en la tabla, estos pueden ser
modificados empleando la cláusula UPDATE, la cual puede incluir una condición o no; si no se
incluye la condición se modificarán todos los datos que existan en la columna respectiva.
UPDATE <nombre_tabla>
SET <columna> = <valor>
WHERE <condicion>;
Por ejemplo:
UPDATE medio_pago
SET tipo = ‘T’;
En este caso, se modifica el campo tipo de la tabla medio_pago, poniendo el valor ‘T’ para
TODOS los registros de la tabla.
UPDATE medio_pago
SET tipo = ‘P’
WHERE numero=987654321;
En este caso, se modifica el tipo de la tabla medio_pago, poniendo el valor ‘P’ solamente para
el o los registros que tengan número = 987654321.
UPDATE empleado
SET salario = salario*1.1;
En caso anterior muestra cómo se pueden realizar operaciones sobre los campos para realizar
la actualización de los mismos.
3. Borrado de datos: Esta es la operación para eliminar datos que se han insertado en la tabla,
nuevamente la condición es opcional, si no es incluye, se eliminarán todos los datos de la
tabla.
DELETE FROM <nombre_tabla>

WHERE <condicion>;
Por ejemplo:
DELETE FROM medio_pago; Eliminará todos los datos de la tabla medio_pago
DELETE FROM medio_pago

WHERE numero=987654321;
Eliminará de la tabla medio_pago, aquellos registros que tengan como numero 987654321
CONSULTAS
El lenguaje SQL fue diseñado originalmente para realizar consultas en las bases de datos, con esta
intención se proporciona una sentencia, comúnmente llamada SELECT.
La forma más sencilla del Select es:
SELECT <columna1, columna2, …>

FROM <tabla>
En el SELECT se especifican las columnas que se quieren consultar o * si se quieren consultar todas
las columnas de la tabla y en el FROM se indica la tabla sobre la que se está haciendo la consulta.
Por ejemplo:
SELECT nombre, login, contrasena

FROM clientes;
Consulta el nombre, login y constrasena de todos los registros de la tabla clientes.
SELECT *
FROM medios_pago;
Consulta todos los datos (campos) de todos los registros de la tabla medios_pago.
SELECT nombre, anho, precio * 0,5

FROM albunes;
Este último ejemplo muestra cómo se pueden realizar operaciones básicas en el momento
de la consulta.
En la consulta se pueden adicionar condiciones, que permite consultar solamente aquellos

registros para los que sea válida la condición. La estructura en este caso es la siguiente:
SELECT <columna1, columna2, …>

FROM <tabla>
WHERE <condición>
La condición debe ser una expresión booleana y para ello se pueden emplear los siguientes
operadores:
Operador Descripción
< Menor que

> Mayor que
= Igual
<> Diferente
>= Mayor o igual
<= Mejor o igual
LIKE Busca un patrón similar
BETWEEN Entre un rango inclusivo de datos
IN Si está en un conjunto de valores descritos
Por ejemplo:
SELECT nombre, anho

FROM album
WHERE anho > 1990;
Consulta el nombre y año de los registros de la table albunes cuyo año sea mayor a 1990.
SELECT *
FROM medio_pago
WHERE tipo = ‘T’;
Consulta todos los datos de los medios de pago que sean de tipo ‘T’.
SELECT nombre, password

FROM clientes
WHERE nombre LIKE ‘Jul%’;
Consulta el nombre y constraseña de los clientes cuyo nombre empiece por Jul.
SELECT *
FROM medio_pago
WHERE tipo = ‘T’ AND fecha_vencimiento > ‘2011-01-01’;
Consulta todos los datos de la tabla medios de pago, que tengan como tipo ‘T’ y cuya fecha
de vencimiento sea mayor al 01 de enero de 2011.
Ordenamiento
Los datos obtenidos de la consulta pueden ser ordenados por alguno de los campos, por defecto el
ordenamiento se hace de forma Ascendente, si se quiere cambiar esto, se debe indicar poniendo
la palabra DESC en la sentencia de ordenamiento.
Por ejemplo:
SELECT nombre, anho

FROM album
WHERE anho > 1990
ORDER BY anho;
SELECT *
FROM usuarios
ORDER BY login, password;
SELECT login, contrasena

FROM usuarios
ORDER BY nombre DESC;
Agrupamiento
En algunas ocasiones los resultados de la consulta pueden generar datos repetidos, por ejemplo
en la siguiente consulta:
SELECT login
FROM compras;
Si se quiere consultar solamente los datos que sean diferentes, sin considerar repetidos, se puede
realizar un agrupamiento; para esto, debe tener en cuenta que el agrupamiento debe realizarse
por uno de los campos consultados.
Por ejemplo:
SELECT login
FROM compras
GROUP BY login;
Cuando se tienen datos agrupados, se pueden realizar algunas operaciones de agregación de

datos.
Las funciones de agregación más utilizadas son:
Operación Descripción
SUM Suma el valor de los registros
AVG Promedio de los valores de registro
COUNT Conteo de Registros
MIN Valor mínimo del conjunto
MAX Valor máximo del conjunto.
Por ejemplo:
SELECT log_cliente, SUM(valor)

FROM compras
GROUP BY login;
SELECT COUNT(*)
FROM vendedores;
SELECT AVG(numero_orden)
FROM ventas
WHERE precio>200;
Si se quiere agregar una condición sobre los valores calculados, se puede hacer con la cláusula
HAVING, aunque debe tenerse en cuenta que la operación haya sido incluida en el Select.
Por ejemplo:
SELECT log_cliente, SUM(valor)

FROM compras
GROUP BY login
HAVING SUM(valor) > 1000000;
Consulta sobre varias tablas
Para realizar una consulta que involucre varias tablas, se deben incluir las tablas respectivas en el
FROM de la sentencia y se debe adicionar una condición indicando cuáles campos son
equivalentes en las respectivas tablas.
Por ejemplo:
SELECT log_cliente, nombre, fecha

FROM compras, clientes
WHERE log_cliente = login;
En este caso, log_cliente es una llave foránea en compras y es equivalente al

campo login en la tabla clientes.
Cuando se quiere hacer mayor claridad sobre cada campo, se puede adicionar el nombre
de la tabla antes del nombre del campo:
SELECT log_cliente, nombre, fecha

FROM compras, clientes
WHERE compras.log_cliente = clientes.login;
Cuando las tablas involucradas en la consulta tienen campos con el mismo nombre, se
debe asignar a cada tabla un alias (nombre temporal) para referirse con precisión a los
campos de cada una:
SELECT a.nombre, c.nombre, fecha

FROM albunes a, cantantes c
WHERE nombre_art = nombre_artistico;
JDBC – Java Database Connectivity
La API JDBC permite acceder desde Java a datos almacenados de forma tabular, especialmente
Bases de datos Relacionales.
Las actividades que controla el JDBC son:

 Conexión a la fuente de datos (Base de Datos)
 Envío de instrucciones de consulta (queries) o actualización hacia la base de datos.
 Recuperación y procesamiento de los resultados recibidos desde la base de datos.
JDBC incluye cuatro componentes:

• JDCB API: Provee acceso a datos relacionales desde JAVA, permite ejecutar sentencias
SQL, recuperar resultados y enviar cambios a la fuente de datos. Permite también,
interactuar con múltiples fuentes de datos en un entorno distribuido.
• JDBC Driver Manager: Define objetos con los que se puede realizar la conexión al driver
JDBC.
• JDBC Test Suite: Ayuda a determinar que drivers manejará el programa.
• JDBC – ODBC Bridge: Provee acceso a JDBC a través de los drivers ODBC. Este código ODBC
debe cargarse en cada máquina cliente.
Arquitectura
El JDBC permite trabajar con arquitecturas de software de 2 o 3 capas. En una arquitectura de dos
capas (aplicación y datos), el JDBC se ubica en la capa de aplicación; en una arquitectura de tres
capas (aplicación, control y datos), el JDBC se ubica en la capa del control, desde donde se realiza
el acceso a los datos.
En cualquier caso, el JDBC debe entenderse como el intermediario entre la aplicación que se
realiza en Java y el DBMS correspondiente que se esté usando (por ejemplo Oracle), lo que da
como ventaja, entre otras cosas, que se pueda cambiar fácilmente de manejador para la base de
datos, sin que esto afecte las sentencias de la aplicación. La siguiente figura presenta un esquema
de las conexiones entre la aplicación, el JDBC y el DBMS.
USANDO EL JDBC
Para acceder a una Base de Datos desde Java, lo primero que se debe hacer es establecer la
conexión con la Base de Datos.
Generalmente una aplicación JDBC se conecta a una fuente de datos usando dos mecanismos:
• DriverManager: Permite cargar un driver específico usando una dirección URL (lo que permite
acceder a una Base de Datos que se encuentre en otro sitio físico). Como parte de la
inicialización, el DriverManager carga las clases driver referenciadas.
• DataSource: Esta interface es preferida sobre el DriverManager, ya que permite manejar
detalles adicionales sobre la fuente de datos.
Observación: La mayoría de los métodos de la API JDBC pueden generar la excepción

SQLException, por lo que el compilador exigirá que las instrucciones respectivas se ubiquen dentro
de una clausula try – catch que atrape dicha excepción.
Para establecer la conexión se requieren dos pasos: cargar el driver y crear la conexión
efectivamente.
1. Cargar el Driver
Para realizar la carga del driver, se debe verificar que este se encuentre disponible desde Java,
si no es así, se debe buscar el driver en la página del fabricante e instalarlo en el directorio
respectivo de Java. En la documentación asociada al driver se indica el nombre que debe
usarse para su acceso.
Por ejemplo:
Para MySQL:
Class.forName("com.mysql.jdbc.Driver");
Para Oracle:
Class.forName("oracle.jdbc.driver.OracleDriver")
2. Establecer la Conexión
Para establecer la conexión, se emplea la sentencia getConnection, dentro de la cual se debe

indicar el URL de ubicación de la Base de Datos, su nombre y se puede incluir el nombre de
usuario y contraseña.
Connection conn = DriverManager.getConnection("jdbc:derby:COFFEES");
En el ejemplo anterior el nombre de la base de datos es COFFEES.
String url = "jdbc:derby:Fred";

Connection con = DriverManager.getConnection(url, "Fernanda", "J8");
En el ejemplo anterior el nombre de la base de datos es Fred, el

login de la base de datos es Fernanda11 y el password es J8.
Una vez se ha establecido la conexión, se empleará esta para realizar las diferentes operaciones
que se requieran sobre la base de datos.
CONSULTAS SOBRE LA BASE DE DATOS

Para realizar una consulta sobre la base de datos, se emplearán las sentencias SQL estándar,
atendiendo el siguiente proceso:
• Debe crearse una sentencia (statement) para realizar la consulta, esta sentencia será un objeto
de alguna clase que implemente java.sql.Statement
Statement stmt = con.createStatement( );
• Debe construirse la consulta a realizar como una cadena, esta consulta debe escribirse tal
como se haría en el manejador sin incluir el punto y coma final.
String query = “SELECT * FROM Customer”;
• Finalmente se ejecuta el método executeQuery() para enviar la consulta al manejador. El

ejecutar una consulta (query), el método retorna un objeto de clase Resultset, por tanto debe
recibirse en una variable de este tipo (más adelante se da una visión general de esta clase).
ResultSet rs = stmt.executeQuery(query);
11
En el caso de MySQL el usuario por defecto es root, así que este debería ser el login aemplear.
ACTUALIZACIÓN DE LA BASE DE DATOS
Si se desea realizar una operación de inserción, borrado o actualización de datos sobre la Base de
Datos, debe emplearse el método executeUpdate() en lugar del executeQuery, este método
retorna un entero donde indica cuántas filas o registros de la Base de Datos se afectaron al
ejecutar la instrucción.
String request = “INSERT INTO Customer (ssn, cust_name, address)” +

“VALUES (‘222’,’Juan’,’Calle 10’)”;
int rowsAffected = stmt.executeUpdate(request);
String request = “DELETE FROM Customer WHERE ssn=‘222’”;

String request = “UPDATE Customer SET cust_name=‘Jose’,

address=‘Carrera 10’ WHERE ssn=‘222’”;
EL RESULTSET
ResultSet es una tabla de datos que representa el conjunto de resultados que se obtienen de una
consulta a una base de datos; un objeto derivado de ResultSet mantiene un cursor a una fila de la
tabla, inicialmente se ubica antes de la primera posición y va cambiando a la siguiente cada vez
que se da la instrucción next(), cuando no hay más filas en la tabla, este método retornará false.
Algunos métodos de la interface ResultSet son:
Método Accion
next() mueve el cursor a la siguiente fila.
previous() mueve el cursor a la fila anterior.
first() mueve el cursor a la primera fila.
last() mueve el cursos a la última fila.
beforeFirst() posiciona el cursor al inicio del ResultSet, antes de la primera
fila.
afterLast() posiciona el cursor al final del ResultSet, después de la última
fila.
relative(int rows) mueve el cursos a una posición relativa a la actual.
absolute(int row) mueve el cursos a una posición absoluta.
getXxx() retorna el valor de la columna especificada por el nombre o
indice. Los tipos válidos son: double, byte, int, Date, String,
float, short, long, Time, Object
La forma más sencilla de recorrer un ResultSet es la siguiente:
String query = “SELECT ssn, cust_name, address FROM Customer”;

while (rs.next()) {
System.out.println(“SSN: “+ rs.getInt(“ssn”).trim());
System.out.println(“Name: “+rs.getString(“cust_name”).trim());
System.out.println(“Address: “+rs.getString(“address”).trim();
System.out.println(“ ”);
}
En este caso, se ejecuta el ciclo mientras existan más registros o filas en la tabla del
resultSet, para cada registro se recupera el campo denominado ssn, el campo cust_name y
el campo address; estos campos pueden recuperarse con el nombre del campo o con el
número de la posición en que se encuentra el campo, por ejemplo ssn sería el campo 1,
cust_name el campo 2 y address el campo, por lo tanto la misma porción de código se
podría escribir así:
String query = “SELECT ssn, cust_name, address FROM Customer”;

while (rs.next()) {
System.out.println(“SSN: “+ rs.getInt(1).trim());
System.out.println(“Name: “+rs.getString(2).trim());
System.out.println(“Address: “+rs.getString(3).trim();
System.out.println(“ ”);
}
Observe que en la primera forma, los nombres de las columnas se escriben entre comillas,
ya que son cadenas; en la segunda forma son enteros por tanto, no deben incluirse
comillas.
Para realizar una correcta recuperación de datos, es preciso conocer el tipo de cada
columna en la Base de datos, en este caso, el ssn es un entero y por ello se recupera con
getInt(),a diferencia del nombre y dirección que son cadenas y se recuperan con getString().
Ejemplo 1:
La siguiente clase, permite consultar los datos de la tabla llamada PROFESORES, en la base
de datos denominada OBJETOS.
public class ConsultaProfesores2 {
// JDBC driver name and database URL

static final String JDBC_DRIVER = "com.mysql.jdbc.Driver ";
// URL de la base de datos

static final String DATABASE_URL = "jdbc:derby: objetos";
// declaración de la conexión y el statement

// para acceso a la base de datos
private Connection connection;
private Statement statement;
// constructor que crea el Frame y hace la conexión a la base de datos

public ConsultaProfesores2()
{
// conecta a la base de datos
try {
// carga el driver correspondiente
Class.forName( JDBC_DRIVER );
// establece la conexión a la base de datos, login y password son system

connection = DriverManager.getConnection( DATABASE_URL,"root","root" );
// crea un statement para consulta

statement = connection.createStatement();
// consulta a la base de datos

ResultSet resultSet =
statement.executeQuery( "SELECT nombre,email,cedula,cod_dpto FROM profesores" );
// Procesamiento de los resultados

StringBuffer results = new StringBuffer();
//la MetaData contiene los datos de la estructura de la

//respuesta, por ejemplo, los nombres de las columnas
ResultSetMetaData metaData = resultSet.getMetaData();
//se consulta el número de columnas de la respuesta

int numberOfColumns = metaData.getColumnCount();
//se adiciona el nombre de cada columna y un tabulador

for ( int i = 1; i <= numberOfColumns; i++ )
results.append( metaData.getColumnName( i ) + "\t" );
results.append( "\n" );
//se adicionan los resultados que estan en resultSet

while ( resultSet.next() ) {
for ( int i = 1; i <= numberOfColumns; i++ )
results.append( resultSet.getObject( i ) + "\t" );
results.append( "\n" );
}
// estalece la GUI, un area de Texto

System.out.println(results);
} // end try
//detecta los problemas al interactual con la base de datos

catch ( SQLException sqlException ) {
JOptionPane.showMessageDialog( null, sqlException.getMessage(),
"Database Error", JOptionPane.ERROR_MESSAGE );
System.exit( 1 );
}
// detecta problemas al cargar el driver

catch ( ClassNotFoundException classNotFound ) {
JOptionPane.showMessageDialog( null, classNotFound.getMessage(),
"Driver Not Found", JOptionPane.ERROR_MESSAGE );
System.exit( 1 );
}
// se asegura que al finalizar se cierre el statement y la conexión

// no importa si ocurrió una excepción o no en ejecución
finally {
try {
statement.close();
connection.close();
}
// Maneja las excepciones que puedan ocurrir en el cierre
JOptionPane.showMessageDialog( null,
sqlException.getMessage(), "Database Error",
JOptionPane.ERROR_MESSAGE );
System.exit( 1 );
}
}
} // fin del constructor

Ejemplo 2:
La siguiente clase, permite la inserción de datos en una tabla llamada DEPARTAMENTO, en

la base de datos denominada OBJETOS.
public class InsertarDpto extends JFrame {
// JDBC driver name and database URL

static final String JDBC_DRIVER = "com.mysql.jdbc.Driver ";
// URL de la base de datos

static final String DATABASE_URL = "jdbc:derby: objetos";
// declaración de la conexión y el statement para acceso a la base de datos

private Connection connection;
private Statement statement;
// constructor que crea el Frame y hace la conexión a la base de datos

public InsertarDpto()
{
super( "Ingreso de datos" );
// conecta a la base de datos

try {
// carga el driver correspondiente
Class.forName( JDBC_DRIVER );
// establece la conexión a la base de datos
connection = DriverManager.getConnection( DATABASE_URL,"root","root" );
// crea un statement para consulta
statement = connection.createStatement();
// inserta los datos en la tabla correspondiente
int L = statement.executeUpdate( "INSERT INTO departamentos VALUES ('Biologia', 600, 300)");
} // end try
//detecta los problemas al interactual con la base de datos

JOptionPane.showMessageDialog( null, sqlException.getMessage(),
"Database Error", JOptionPane.ERROR_MESSAGE );
System.exit( 1 );
}
// detecta problemas al cargar el driver

catch ( ClassNotFoundException classNotFound ) {
JOptionPane.showMessageDialog( null, classNotFound.getMessage(),
"Driver Not Found", JOptionPane.ERROR_MESSAGE );
System.exit( 1 );
}
// se asegura que al finalizar se cierre el statement y la conexión

// no importa si ocurrió una excepción o no en ejecución
finally {
try {
statement.close();
connection.close();
}
// Maneja las excepciones que puedan ocurrir en el cierre

JOptionPane.showMessageDialog( null,
sqlException.getMessage(), "Database Error",
JOptionPane.ERROR_MESSAGE );
System.exit( 1 );
}
}
} // fin del constructor
ACTIVIDADES
Procedimiento:
1. Ingrese a través del “Asistente de configuración de la Base de Datos” y cree una nueva
base de datos llamada Tienda.
2. Ingrese a través del “SQL Plus”, con el login: system, password: system y Hot String:
Tienda.
3. Cree las tablas de la base de datos, de acuerdo a lo indicado en el siguiente modelo
relacional de datos. Recuerde que el orden de creación es importante, ya que para
crear una restricción de llave foránea, debe estar creada la tabla y columna a la que
hace referencia.
CLIENTES
Nombre nombre login contrasena email
Tipo Varchar2(20) Varchar2(15) Varchar2(15) Varchar2(15)
Llaves PK
Dominio
ALBUNES
Nombre caratula nombre anho precio
Tipo BLOB Varchar2(20) Number Number(10,2)
Obligatoriedad N NN NN NN
Llaves PK PK
Dominio
ARTISTAS
Nombre genero_1 genero_2 genero_3 casa_disquera nombre foto
Tipo Varchar2(10) Varchar2(10) Varchar2(10) Varchar2(20) Varchar2(30) BLOB
Obligatoriedad NN N N N N N
Llaves
Dominio
Nombre hoja_vida nomb_artistico

Tipo CLOB Varchar2(30)
Obligatoriedad N NN
Llaves PK
Dominio
MEDIOS_PAGO
Nombre tipo numero fecha_venc log_cliente
Tipo Varchar2(1) Number Date Varchar2(15)
Obligatoriedad NN NN N NN
Llaves PK PK FK(Clientes)
Dominio T','P'
COMPRAS
Nombre fecha numero tipo_mp numero_mp
Tipo Date Number Varchar2(1) Number
Llaves PK FK(medios_pago) FK(medios_pago)
Dominio
CANCION
Nombre duracion nombre genero tamano formato
Tipo Numbre Varchar2(20) Varchar2(20) Number Varchar2(10)
Obligatoriedad NN NN NN NN NN
Llaves
Dominio
Nombre precio archivo porcentaje codigo nom_artista

Tipo Number(10,2) BLOB Number(10,2) Number Varchar2(30)
Obligatoriedad NN N NN NN NN
Llaves PK FK(Artistas)
Dominio
DETALLES_CARRITO
Nombre fecha cod_cancion log_cliente
Tipo Date Number Varchar2(15)
Obligatoriedad NN NN NN
Llaves FK(canciones), PK FK(Clientes), PK
Dominio
PISTAS
Nombre numero nom_album anho_album cod_cancion
Tipo Number Varchar2(20) Number Number
Llaves PK FK(albunes),PK FK(albunes),PK FK(canciones)
Dominio >0
DETALLES_COMPRA
Nombre precio num_descargas cod_cancion num_compra
Tipo Number(10,2) Number Number Number
Llaves FK(canciones), PK FK(Compras),PK
Dominio
Valor Defecto 0
PAGOS
Nombre fecha nom_artista
Tipo Date Varchar2(30)
Obligatoriedad NN NN
Llaves PK FK(Artistas),PK
Dominio
CANCIONES_PAGADAS
Nombre valor_pagado fecha_pago nom_artista cod_cancion
Tipo Number(10,2) Date Varchar2(30) Number
Llaves FK(Pagos),PK FK(Pagos),PK FK(canciones), PK
Dominio >0
4. Inserte en cada tabla los datos que se muestran a continuación.
CLIENTES
Nombre login contrasena email
Jonathan Acosta jacosta 123juanito jacosta@hotmail.com
Raul Martinez rmartinez raulito rmartinez@hotmail.com
Nicolas Tafur ntafur nico1999 nico_nico@gmail.com
Miguel Morales mmorales mmorales miguelito@yahoo.com
Holmes Osorio hosorio oso23rio98 hjulianosorio@yahoo.com
ALBUNES
nombre anho precio
No culpes a la noche 2009 65
The number of the beast 1982 120
ARTISTAS
genero_1 genero_2 genero_3 casa_disquera nomb_artistico
Baladas Boleros Sony Music Luis Miguel
Heavy Metal Iron Maiden
CANCIONES
duracion nombre genero tamano formato precio porcentaje codigo nom_artista
200 alguien como tu Balada 30 mp3 3 3,4 1000 Luis Miguel
260 eres Balada 37 wav 3 3,4 1001 Luis Miguel
180 suave Balada 20 mp3 10 3,4 1002 Luis Miguel
The number of the Heavy
290 beast Metal 47 mp3 15 6 2000 Iron Maiden
Heavy
268 Total Eclipse Metal 42 wav 4 5 2001 Iron Maiden
PISTA
numero nombre anho cod_cancion
1 No culpes a la noche 2009 1000
The number of the
5 beast 1982 2000
The number of the
8 beast 1982 2001
MEDIOS_PAGO
tipo numero fecha_vencimiento log_cliente
'T' 1230000 rmartinez
'P' 9870101 10/06/2012 ntafur
'T' 1212121 rmartinez
'T' 7676767 12/12/2013 mmorales
COMPRAS
fecha numero tipo_mp numero_mp
01/03/2011 1 'P' 9870101
16/02/2011 2 'T' 1212121
16/02/2011 3 'T' 1230000
03/03/2011 4 'T' 1230000
DETALLES_COMPRA
precio num_descargas num_compra cod_cancion
3 1 1 1000
3 3 1 1001
15 2 2 2000
10 1 3 1002
5. Ingrese a Oracle utilizando la Base de Datos Tienda que creó en la práctica anterior.
6. Realice las siguientes consultas sobre la base de datos; para cada una de ellas debe
indicar cuál es la instrucción para realizarla y el resultado obtenido.
a. Consultar todos los datos del artista que tiene como nombre artístico “Luis
Miguel”.
b. Consultar el nombre y duración de las canciones que de género Balada.
c. Consultar el número y nombre de las pistas que tienen año superior a 1999.
d. Consultar todas las compras de tipo T ordenadas por fecha.
e. Consultar todos los datos de los clientes cuyo email empieza por ‘m’ o ‘n’.
f. Consultar las canciones agrupadas por artista, totalizando el precio de las mismas
(obviamente por artista).
g. Consultar las canciones (nombre, duración y precio) de género Heavy Metal en
formato wav.
h. Consultar el nombre del artista, género, nombre del álbum y año.
i. Consultar todos los datos de los medios de pago de Raúl Martinez (OJO debe
consultarse por este nombre, no vale consultar por el email).
j. Consultar la fecha de compra, nombre y tipo del medio de pago, nombre y login
del cliente, para cada compra.
k. Consultar todos los datos de las canciones (incluyendo el nombre del artista) que
se encuentren en albunes del año 2000 o posterior.
l. Consultar todas las compras (incluyendo las canciones compradas) que ha hecho
Nicolás Tafur (OJO debe consultarse por este nombre, no vale consultar por el
email).
7. Ingrese a través del “Asistente de configuración de la Base de Datos” y cree una nueva
base de datos llamada FotoAlbum.
8. Ingrese a través del “SQL Plus”, con el login: system, password: system y Hot String:
FotoAlbum.
9. Cree las tablas de la base de datos, de acuerdo a lo indicado en el siguiente modelo
relacional de datos. Recuerde que el orden de creación es importante, ya que para
crear una restricción de llave foránea, debe estar creada la tabla y columna a la que
hace referencia.
USUARIOS
fecha_nacimient contrasen
Nombre nombre correo o a pais calificacion
Texto(20 Numerico(2
Tipo Texto(30) Texto(20) Fecha Texto(15) ) )
Obligatoriedad NN NN NN NN NN N
Llaves AK PK
Dominio >0
ALBUNES
Nombre nombre comentario codigo email_usuario

Tipo Texto(20) Texto(100) Numerico(3) Texto(20)
Obligatoriedad NN N NN NN
Llaves PK FK(Usuarios)
Dominio
SESIONES
Nombre fecha_inicio fecha_salida numero email_usuario

Tipo Fecha Fecha Numerico(6) Texto(20)
Obligatoriedad NN N NN NN
Llaves PK FK(Usuarios)
Dominio
CONTACTOS
Nombre privacidad numero categoria calificacion u_recibe u_contacto

Tipo Texto(1) Numerico(6) Texto(15) Numerico(2) Texto(20) Texto(20)
Obligatoriedad NN NN N N NN NN
Llaves PK FK(Usuarios),PK FK(Usuarios)
Dominio T','P' >0
FOTOS
Nombre nombre tamano comentario clasificacion formato archivo

Tipo Texto(30) Numerico(6) Texto(100) Texto(30) Texto(20) BLOB
Obligatoriedad NN NN N N NN N
Llaves
Dominio
Nombre descripcion privacidad f_almacen calificacion denuncia numero_visitas

Tipo Texto(100) Texto(1) Fecha Numerico(2) Numerico(1) Numerico(5)
Obligatoriedad N NN NN N N NN
Llaves
Dominio T','P' >0 0,1
Nombre codigo cod_album email_usuario

Tipo Numerico(4) Numerico(3) Texto(20)
Obligatoriedad NN N NN
Llaves PK FK(albunes) FK(Usuarios)
Dominio >0
ETIQUETAS
Nombre cod_foto email_usuario

Tipo Numerico(4) Texto(20)
Obligatoriedad NN NN
Llaves FK(Fotos), PK FK(Usuarios),PK
Dominio
COMENTARIOS
Nombre descripcion categoria numero creador u_destino foto_destino

Tipo Texto(50) Texto(1) Numerico(3) Texto(20) Texto(20) Numerico(4)
Obligatoriedad NN N NN N N
Llaves FK(Usuarios) FK(Usuarios) FK(Fotos)
Dominio G','P' >0
10. Inserte en cada tabla los datos que se muestran a continuación.
USUARIOS
Nombre correo fecha_nacimiento contrasena pais

Fernando Marroquin fmarro@yahoo.com 05/02/1955 fmarroquin Ecuador
Maria Lucia Gomez mlgomez@uniweb 07/08/1979 mlgomez Colombia
Juan Pablo Montoya jpm42@yahoo.es 25/03/1971 jpmontoya Colombia
Martha Jimenez nenita@msn.net 15/01/1988 mjimenez Peru
ALBUNES
nombre comentario codigo email_usuario

Familia Son las fotos de la familia 1 mlgomez@uniweb
Amigos Las del parche 2 mlgomez@uniweb
Familia Para recordar 3 jpm42@yahoo.es
Carreras 4 jpm42@yahoo.es
CONTACTOS
privacidad Numero categoria calificacion u_recibe u_contacto
T 1 10 mlgomez@uniweb nenita@msn.net
P 2 Amigo mlgomez@uniweb fmarro@yahoo.com
P 3 jpm42@yahoo.es fmarro@yahoo.com
FOTOS
nombre Tamaño comentario clasificacion formato

Playa1 100 En San Andres jpg
Playa2 50 Vacaciones jpg
Descripción privacidad f_almacen calificacion denuncia numero_visitas

Esta fue tomada por
Juan en las vacaciones
en San Andres P 03/09/2011 5 10
T 04/09/2011 10 20
codigo cod_album email_usuario

1 1 mlgomez@uniweb
2 1 mlgomez@uniweb
ETIQUETAS
cod_foto email_usuario
1 nenita@msn.net
1 fmarro@yahoo.com
COMENTARIOS
Descripción categoria numero creador u_destino foto_destino

Hay que subir más fotos P 1 fmarro@yahoo.com mlgomez@uniweb
Que lindos que quedamos G 2 nenita@msn.net 1
Contame de tu vida P 3 fmarro@yahoo.com nenita@msn.net
Procedimiento:
11. Ingrese a Oracle utilizando la Base de Datos FotoAlbum que creó en la práctica
anterior.
12. Realice las siguientes consultas sobre la base de datos; para cada una de ellas debe
indicar cuál es la instrucción para realizarla y el resultado obtenido.
a. Consultar el nombre y correo de todos los usuarios.

b. Consultar todos los datos de los usuarios de Colombia.
c. Consultar los datos de los albunes del usuario mlgomez@uniweb.
d. Consultar el nombre, tamaño, formato, clasificación y número de visitas de las
fotos con clasificación mayor a 5.
e. Consultar todos los datos de los comentarios que tengan categoría G.
f. Consultar todos los datos de las fotos que se almacenaron después del
05/02/2011.
g. Consultar todos los datos (menos la contraseña) de los usuarios que han sido
etiquetados en la foto número 1.
h. Consultar la descripción, categoría, nombre del creador y correo del creador de los
comentarios que se hayan realizado a la foto número 1.
i. Consultar los nombres y categoría de los contactos de Maria Lucia Gomez (para la
consulta debe usar el nombre no el correo).
j. Consultar el nombre y comentario de cada álbum, así como el nombre, tamaño,
comentario, clasificación, formato, descripción, privacidad, nombre del dueño y
correo del dueño de cada foto que se encuentre en el álbum.
MANEJO DE OBJETOS GRANDES
Los BLOB (Binary Large Object) son objetos binarios que permiten almacenar gran cantidad de
información, por lo cual son muy apropiados para almacenar archivos, que pueden ser textos de
Word, PDFs, MP3 o cualquier otra clase de archivo que se requiera.
MySQL define varios tipos de datos BLOB, dependiendo del tamaño que se desea almacenar:
- tinyblob: longitud máxima de 255 bytes.

- mediumblob: longitud de 16777215 bytes.
- Longblob: longitud para 4294967295 bytes.
Si se van a almacenar solamente datos de tipo texto (caracteres), se recomienda emplear los tipo
TEXT:
- tinytext: longitud máxima de 255 caracteres.

- mediumtext: longitud de 16777215 caracteres.
- longtext: longitud para 4294967295 caracteres
INSERTAR TIPOS TEXT

Los datos de tipo Text se pueden insertar de forma similar a como se insertan otros tipos que
contienen caracteres (por ejemplo Varchar). Debe tenerse en cuenta que los tipo TEXT, al igual
que los BLOB no permiten valores por defecto, como sí lo hacen los otros tipos de datos.
La Inserción de campos de tipo texto se puede realizar de dos formas:

 Ingresar la cadena directamente, tal como se hace con los campos de tipo Varchar.
 Ingresar el archivo con la función LOAD_FILE, tal como se hace con los campos tipo
BLOB.
INSERTAR TIPOS BLOB

Los datos de tipo BLOB se pueden insertar en MySQL, empleando la función LOAD_FILE():
INSERT INTO empleados (nombre, foto) VALUES (‘Pepe Lopez’,LOAD_FILE(‘fotopepe.png’));
NOTA: Es necesario indicar todo el camino (path) completo donde se encuentra el archivo,
teniendo en cuenta que para sistemas Windows, MySQL no acepta nombres de archivos o
carpetas que tengan espacios (por ejemplo d:\Mis documentos no sería válido) y que debe
incluirse doble barra para indicar las carpetas.
Por ejemplo: …. LOAD_FILE(‘d:\\carpeta1\\carpeta2\\archivo.doc’),

CONSULTAR TIPOS TEXT Y BLOB
Los tipos de dato Text y Blob se pueden consultar en la pantalla de MySQL igual que se consultan
otros tipos de datos, pero al mostrar un tipo de dato BLOB, se presentarán los bytes que lo
contiene, así que es probable que no se entienda su contenido; por su parte los campos de tipos
TEXT serán presentados como caracteres, lo cual permitirá su lectura fácilmente.
ACCESO DESDE JDBC

Los campos de tipo TEXTO se pueden recuperar desde JDBC de la misma forma que los datos de
tipo Varchar, es decir, empleando el método getString () del ResultSet.
El manejo de los datos grandes desde JDBC se realiza haciendo uso de la clase java.sql.Blob.
Obtener la referencia a un objeto LOB

Como se mencionó anteriormente, para operar con los datos tipo BLOB en el JDBC, primero se
debe obtener la referencia al objeto, para ello se realiza una consulta a la base de datos, ya que
Java no posee un método directo para recuperar objetos de este tipo, estos se deben recuperar
como Object (empleando el método getObject del resultSet) y hacer el casting correspondiente
para obtener la referencia apropiada.
Por ejemplo:
result set. ResultSet rs = Las observaciones son

stmt.executeQuery ("SELECT blob_col FROM lob_table"); anotaciones que el DBMS
no puede controlar, se
incluyen para que el
desarrollador de la
aplicación las tenga en
while (rs.next()) cuenta.
Realiza la consulta a la
{ Base de Datos para traer
java.sql.Blob blob = (java.sql.Blob)rs.getObject(1); los datos tipo Blob.
…
}
Recupera los datos que trae la consulta como Objetos y hace el casting
respectivo para tener la referencia como Blob.
Una vez obtenida la referencia BLOB, el objeto se puede manipular en JAVA dependiendo del tipo
de información que tenga (texto, imagen, audio o video), para ello, se emplearían las APIs
correspondientes en Java: Java 2D, Java 3D, Java Advance Image, Java Image I/O o JMF- Java
Media Framework.
Insertar objetos BLOB desde JDBC
Para realizar la inserción de un dato tipo BLOB desde el JDBC, se emplea un PreparedStament , al
que se asignará un archivo del tipo que se desea.
Por ejemplo:
String sql="Insert into album (caratula,nombre,anho, precio) values (?,?,?,?)";

PreparedStatement stmt = connection.prepareStatement(sql);
File imagen = new File("d:\\duke.jpg");

FileInputStream fis = new FileInputStream(imagen);
stmt.setBinaryStream(1,fis,(int)imagen.length());
stmt.setString(2,"dukito");
stmt.setInt(3,2011);
stmt.setInt(4,45000);
stmt.execute();
Los signos de interrogación corresponden a datos que se van a adicionar posteriormente, en este
caso los cuatro datos: caratula, nombre, anho y precio se adicionar después.
Para adicionar el archivo, en este caso para la carátula que es de tipo BLOB, se carga el archivo
correspondiente como un File a través de un FileInputStream; entonces se asigna al campo
correspondiente (1) el archivo correspondiente:
stmt.setBinaryStream(1,fis,(int)imagen.length());
los otros campos se asignan de forma sencilla, según su tipo (String o Int). Finalmente se ejecuta la
sentencia, mediante el comando execute().

Modelado Conceptual MER-UML

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modelado Conceptual MER-UML

Cargado por

Copyright:

Formatos disponibles

BASES DE DATOS

Lyda Peña Paz

BASES DE DATOS ......................................................................................................... 3

La primera propuesta para el almacenamiento de información fueron los archivos o

Respecto al anterior sistema de archivos, las Bases de Datos presentaban algunas

Algunas definiciones recopiladas por Piatinni et al 1son:

“Colección de datos interrelacionados almacenados en conjunto sin redundancias

“Conjunto de datos de la empresa memorizado en un ordenador, que es utilizado por

“Conjunto estructurado de datos registrados sobre soportes accesibles por ordenador

“Colección no redundante de datos que son compartidos por diferentes sistemas de

“Colección integrada y generalizada de datos, estructurada atendiendo a las relaciones

“Colección de datos interrelacionados” (Elmasri y Navathe, 1989)

La siguiente definición es propuesta por de Miguel y Piatinni2 :

“Colección o depósito de datos integrados, almacenados en

ARQUITECTURA DE SISTEMAS DE BASES DE DATOS

Figura 2. Arquitectura de las Bases de Datos

EVOLUCIÓN DE LAS BASES DE DATOS

Figura 4. Esquemas de Sistemas de Bases de Datos Jerárquico (a) y de Red (b).

Tercera Generación: Los proveedores de tecnología se han encargado de evolucionar las

EL SISTEMA GESTOR DE BASES DE DATOS (DBMS)

El sistema Manejador de Bases de Datos o DBMS (DataBase Management System) se

El manejador de la base de datos se encarga de conectar la base de datos con las

• Funciones de Definición o Descripción: Permite al diseñador de la base, especificar los

MANEJADORES DE BASES DE DATOS

EL ADMINISTRADOR DE LA BASES DE DATOS (DBA)

El administrador de la Base de Datos es la persona encargada de crear, mantener y

¿CUÁL ES LA DIFERENCIA CON LOS DATOS MULTIMEDIA?

 El tamaño: cuando se considera el almacenamiento de una imagen de buena

Subrahmanian define el Manejador de Bases de Datos Multimedia como “el framework

 Consultar datos en diferentes formatos.

 De Miguel, Adoración; Piattini, Mario. Fundamentos y Modelos de Bases de Datos. Ed.

 Dunckley, Lynne. Mutlimedia Databases. An object-relational approach. Ed. Addison-

 ElMasri, Ramez., Navathe, Shamkant. Sistemas de Bases de Datos. 2ª edición. Addison

 Subrahmanian, V.S. Principles of Multimedia Database Systems. Morgan Kaufmann

ELEMENTOS DEL MODELO RELACIONAL

Un modelo de datos relacional se compone básicamente de dos elementos: Uno que

Atributos: Un atributo es una característica relevante de una entidad. Cualquier entidad

El nombre de la relación, da mayor información sobre la misma y debería estar

A continuación se especifica la cardinalidad de la relación, en este caso se indica que:

1 Uno y solo uno

Definición de claves o llaves

Para establecer la llave de una entidad se sigue este procedimiento:

<<PK>> cedula: numerico <<PK>> fecha:fecha

Si se concluye que existe un ciclo, debe identificarse cuál es la relación redundante, es

Para el ejemplo, se puede revisar de la siguiente forma:

1. Supóngase que la relación redundante es la que existe entre PELICULA y ACTOR, si

3. Supóngase que la relación redundante es la que existe entre DIRECTOR y ACTOR, si

El modelo quedaría entonces, de la siguiente forma, asegurando que no se ha perdido la

¿Por qué es necesario eliminar las relaciones redundantes?

Rompimiento de relaciones muchos a muchos

Al realizar un rompimiento de la relación muchos a muchos entre dos entidades A y B,

Por ejemplo: La siguiente figura muestra el rompimiento de la relación muchos a muchos

¿No se supone que todas las entidades deben tener atributos?

¿Qué pasa si no se usan los supertipos y subtipos?

Si el atributo es múltiple, pero las ocurrencias son pocas y se conocen de antemano se

Si el atributo es múltiple y tiene muchas ocurrencias o no se conoce con exactitud cuántas

Los atributos código_producto,

En el ejemplo siguiente el rol del comisario, puede variar de un evento a otro, en un

4. Toda entidad debe tener un identificador (clave primaria).

¿Es obligatorio realizar el MRD?

Tipo Cuando el campo sea de tipo Texto, es conveniente incluir entre

Los campos tipo Fecha, almacenan fecha y hora.

PK – (Primary Key) Llave primaria, cuando el campo se emplea como