Unidad 1.

Introduccin a los sistemas de bases de datos.

1.1 Sistemas de informacin y bases de datos.
1.1.1Concepto de sistema de informacin.
Un sistema de informacin es un conjunto de elementos que interactan
entre s con el fin de apoyar las actividades de una empresa o negocio.
El equipo computacional: el hardware necesario para que el sistema de
informacin pueda operar.
El recurso humano que interacta con el Sistema de Informacin, el cual est
formado por las personas que utilizan el sistema.
Un sistema de informacin realiza cuatro actividades bsicas: entrada,
almacenamiento, procesamiento y salida de informacin.
Entrada de Informacin: Es el proceso mediante el cual el Sistema de
Informacin toma los datos que requiere para procesar la informacin. Las
entradas pueden ser manuales o automticas. Las manuales son aquellas
que se proporcionan en forma directa por el usuario, mientras que las
automticas son datos o informacin que provienen o son tomados de otros
sistemas o mdulos. Esto ltimo se denomina interfases automticas.
Las unidades tpicas de entrada de datos a las computadoras son las
terminales, las cintas magnticas, las unidades de diskette, los cdigos de
barras, los escners, la voz, los monitores sensibles al tacto, el teclado y el
mouse, entre otras.
Almacenamiento de informacin: El almacenamiento es una de las
actividades o capacidades ms importantes que tiene una computadora, ya
que a travs de esta propiedad el sistema puede recordar la informacin
guardada en la seccin o proceso anterior. Esta informacin suele ser
almacenada en estructuras de informacin denominadas archivos. La unidad
tpica de almacenamiento son los discos magnticos o discos duros, los
discos flexibles o diskettes y los discos compactos (CD-ROM).
Procesamiento de Informacin: Es la capacidad del Sistema de
Informacin para efectuar clculos de acuerdo con una secuencia de
operaciones preestablecida. Estos clculos pueden efectuarse con datos
introducidos recientemente en el sistema o bien con datos que estn
almacenados. Esta caracterstica de los sistemas permite la transformacin

de datos fuente en informacin que puede ser utilizada para la toma de

decisiones, lo que hace posible, entre otras cosas, que un tomador de
decisiones genere una proyeccin financiera a partir de los datos que
contiene un estado de resultados o un balance general de un ao base.
Salida de Informacin: La salida es la capacidad de un Sistema de
Informacin para sacar la informacin procesada o bien datos de entrada al
exterior. Las unidades tpicas de salida son las impresoras, terminales,
diskettes, cintas magnticas, la voz, los graficadores y los plotters, entre
otros. Es importante aclarar que la salida de un Sistema de Informacin
puede constituir la entrada a otro Sistema de Informacin o mdulo. En este
caso, tambin existe una interfase automtica de salida. Por ejemplo, el
Sistema de Control de Clientes tiene una interfase automtica de salida con
el Sistema de Contabilidad, ya que genera las plizas contables de los
movimientos procesales de los clientes.
A continuacin se muestran las diferentes actividades que puede realizar un
Sistema de Informacin de Control de Clientes:
Actividades que realiza un Sistema de Informacin:
Entradas:

Datos generales del cliente: nombre, direccin, tipo de cliente, etc.

Polticas de crditos: lmite de crdito, plazo de pago, etc.
Facturas (interfase automtico).
Pagos, depuraciones, etc.

Proceso:

Clculo de antigedad de saldos.

Clculo de intereses moratorios.
Clculo del saldo de un cliente.
Almacenamiento:

Movimientos del mes (pagos, depuraciones).

Catlogo de clientes.
Facturas.

Salidas:

Reporte de pagos.
Estados de cuenta.
Plizas contables (interfase automtica)
Consultas de saldos en pantalla de una terminal.

Las diferentes actividades que realiza un Sistema de Informacin se pueden

observar en el diseo conceptual ilustrado en la en la figura 1.2.
Tipos y Usos de los Sistemas de Informacin
Durante los prximos aos, los Sistemas de Informacin cumplirn tres
objetivos bsicos dentro de las organizaciones:
1. Automatizacin de procesos operativos.
2. Proporcionar informacin que sirva de apoyo al proceso de toma de
decisiones.

3.

Lograr
ventajas competitivas a travs de su implantacin y uso.

Los Sistemas de Informacin que logran la automatizacin de procesos

operativos dentro de una organizacin, son llamados frecuentemente
Sistemas Transaccionales, ya que su funcin primordial consiste en procesar
transacciones tales como pagos, cobros, plizas, entradas, salidas, etc. Por
otra parte, los Sistemas de Informacin que apoyan el proceso de toma de
decisiones son los Sistemas de Soporte a la Toma de Decisiones, Sistemas
para la Toma de Decisin de Grupo, Sistemas Expertos de Soporte a la Toma
de Decisiones y Sistema de Informacin para Ejecutivos. El tercer tipo de
sistema, de acuerdo con su uso u objetivos que cumplen, es el de los
Sistemas Estratgicos, los cuales se desarrollan en las organizaciones con el
fin de lograr ventajas competitivas, a travs del uso de la tecnologa de
informacin.

Ciclo de vida de las aplicaciones de bases de datos

Las etapas del ciclo de vida de una aplicacin de bases de datos son las
siguientes:
1. Planificacin del proyecto.
2. Definicin del sistema.
3. Recoleccin y anlisis de los requisitos.
4. Diseo de la base de datos.
5. Seleccin del SGBD.
6. Diseo de la aplicacin.
7. Prototipado.
8. Implementacin.
9. Conversin y carga de datos.
10.
Prueba.
11.
Mantenimiento.
Estas etapas no son estrictamente secuenciales. De hecho hay que repetir
algunas de las etapas varias veces, haciendo lo que se conocen como ciclos
de realimentacin. Por ejemplo, los problemas que se encuentran en la etapa
del diseo de la base de datos pueden requerir una recoleccin de requisitos
adicional y su posterior anlisis.
A continuacin, se muestran las tareas ms importantes que se realizan en
cada etapa.
1. Planificacin del proyecto
Esta etapa conlleva la planificacin de cmo se pueden llevar a cabo las
etapas del ciclo de vida de la manera ms eficiente. Hay tres componentes
principales: el trabajo que se ha de realizar, los recursos para llevarlo a cabo
y el dinero para pagar por todo ello. Como apoyo a esta etapa, se necesitar
un modelo de datos corporativo en donde se muestren las entidades
principales de la empresa y sus relaciones, y en donde se identifiquen las
principales reas funcionales. Normalmente, este modelo de datos se
representa mediante un diagrama entidad-relacin. En este modelo se tiene
que mostrar tambin qu datos comparten las distintas reas funcionales de
la empresa.
La planificacin de la base de datos tambin incluye el desarrollo de
estndares que especifiquen cmo realizar la recoleccin de datos, cmo
especificar su formato, qu documentacin ser necesaria y cmo se va a
llevar a cabo el diseo y la implementacin. El desarrollo y el mantenimiento
de los estndares puede llevar bastante tiempo, pero si estn bien
diseados, son una base para el personal informtico en formacin y para
medir la calidad, adems, garantizan que el trabajo se ajusta a unos

patrones, independientemente de las habilidades y la experiencia del

diseador. Por ejemplo, se pueden establecer reglas sobre cmo dar nombres
a los datos, lo que evitar redundancias e inconsistencias. Se deben
documentar todos los aspectos legales sobre los datos y los establecidos por
la empresa como, por ejemplo, qu datos deben tratarse de modo
confidencial.
2. Definicin del sistema
En esta etapa se especifica el mbito y los lmites de la aplicacin de bases
de datos, as como con qu otros sistemas interacta. Tambin hay que
determinar quienes son los usuarios y las reas de aplicacin.
3. Recoleccin y anlisis de los requisitos
En esta etapa se recogen y analizan los requerimientos de los usuarios y de
las reas de aplicacin. Esta informacin se puede recoger de varias formas:

Entrevistando al personal de la empresa, concretamente, a aquellos

que son considerados expertos en las reas de inters.
Observando el funcionamiento de la empresa.
Examinando documentos, sobre todo aquellos que se utilizan para
recoger o visualizar informacin.
Utilizando cuestionarios para recoger informacin de grandes grupos
de usuarios.
Utilizando la experiencia adquirida en el diseo de sistemas similares.

La informacin recogida debe incluir las principales reas de aplicacin y los

grupos de usuarios, la documentacin utilizada o generada por estas reas
de aplicacin o grupos de usuarios, las transacciones requeridas por cada
rea de aplicacin o grupo de usuarios y una lista priorizada de los
requerimientos de cada rea de aplicacin o grupo de usuarios.
Esta etapa tiene como resultado un conjunto de documentos con las
especificaciones de requisitos de los usuarios, en donde se describen las
operaciones que se realizan en la empresa desde distintos puntos de vista.
La informacin recogida se debe estructurar utilizando tcnicas de
especificacin de requisitos, como por ejemplo tcnicas de anlisis y diseo
estructurado y diagramas de flujo de datos. Tambin las herramientas CASE (
Computer-Aided Software Engineering) pueden proporcionar una asistencia
automatizada que garantice que los requisitos son completos y consistentes.
4. Diseo de la base de datos

Esta etapa consta de tres fases: diseo conceptual, diseo lgico y diseo
fsico de la base de datos. La primera fase consiste en la produccin de un
esquema conceptual, que es independiente de todas las consideraciones
fsicas. Este modelo se refina despus en un esquema lgico eliminando las
construcciones que no se pueden representar en el modelo de base de datos
escogido (relacional, orientado a objetos, etc.). En la tercera fase, el esquema
lgico se traduce en un esquema fsico para el SGBD escogido. La fase de
diseo fsico considera las estructuras de almacenamiento y los mtodos de
acceso necesarios para proporcionar un acceso eficiente a la base de datos
en memoria secundaria.
Los objetivos del diseo de la base de datos son:

Representar los datos que requieren las principales reas de aplicacin

y los grupos de usuarios, y representar las relaciones entre dichos
datos.
Proporcionar un modelo de datos que soporte las transacciones que se
vayan a realizar sobre los datos.
Especificar un esquema que alcance las prestaciones requeridas para
el sistema.

Hay varias estrategias a seguir para realizar el diseo: de abajo a arriba, de

arriba a abajo, de dentro a fuera y la estrategia mixta. La estrategia de abajo
a arriba parte de todos los atributos y los va agrupando en entidades y
relaciones. Es apropiada cuando la base de datos es simple, con pocos
atributos. La estrategia de arriba a abajo es ms apropiada cuando se trata
de bases de datos complejas. Se comienza con un esquema con entidades de
alto nivel, que se van refinando para obtener entidades de bajo nivel,
atributos y relaciones. La estrategia de dentro a fuera es similar a la
estrategia de abajo a arriba, pero difiere en que se parte de los conceptos
principales y se va extendiendo el esquema para considerar tambin otros
conceptos, asociados con los que se han identificado en primer lugar. La
estrategia mixta utiliza ambas estrategias, de abajo a arriba y de arriba a
abajo, con un esquema de divide y vencers. Se obtiene un esquema inicial
de alto nivel, se divide en partes, y de cada parte se obtiene un subesquema.
Estos subesquemas se integran despus para obtener el modelo final.
5. Seleccin del SGBD
Si no se dispone de un SGBD, o el que hay se encuentra obsoleto, se debe
escoger un SGBD que sea adecuado para el sistema de informacin. Esta
eleccin se debe hacer en cualquier momento antes del diseo lgico.
6. Diseo de la aplicacin
En esta etapa se disean los programas de aplicacin que usarn y
procesarn la base de datos. Esta etapa y el diseo de la base de datos, son

paralelas. En la mayor parte de los casos no se puede finalizar el diseo de

las aplicaciones hasta que se ha terminado con el diseo de la base de datos.
Por otro lado, la base de datos existe para dar soporte a las aplicaciones, por
lo que habr una realimentacin desde el diseo de las aplicaciones al diseo
de la base de datos.
En esta etapa hay que asegurarse de que toda la funcionalidad especificada
en los requisitos de usuario se encuentra en el diseo de la aplicacin. Habr
algunos programas que utilicen y procesen los datos de la base de datos.
Adems, habr que disear las interfaces de usuario, aspecto muy
importante que se suele ignorar. El sistema debe ser fcil de aprender, fcil
de usar, ser directo y estar ``dispuesto a perdonar''. Si la interface no tiene
estas caractersticas, el sistema dar problemas, sin lugar a dudas.
7. Prototipado
Esta etapa, que es opcional, es para construir prototipos de la aplicacin que
permitan a los diseadores y a los usuarios probar el sistema. Un prototipo es
un modelo de trabajo de las aplicaciones del sistema. El prototipo no tiene
toda la funcionalidad del sistema final, pero es suficiente para que los
usuarios puedan utilizar el sistema e identificar qu aspectos estn bien y
cules no son adecuados, adems de poder sugerir mejoras o la inclusin de
nuevos elementos. Este proceso permite que quienes disean e implementan
el sistema sepan si han interpretado correctamente los requisitos de los
usuarios. Otra ventaja de los prototipos es que se construyen rpidamente.
Esta etapa es imprescindible cuando el sistema que se va a implementar
tiene un gran coste, alto riesgo o utiliza nuevas tecnologas.
8. Implementacin
En esta etapa se crean las definiciones de la base de datos a nivel
conceptual, externo e interno, as como los programas de aplicacin. La
implementacin de la base de datos se realiza mediante las sentencias del
lenguaje de definicin de datos (LDD) del SGBD escogido. Estas sentencias se
encargan de crear el esquema de la base de datos, los ficheros en donde se
almacenarn los datos y las vistas de los usuarios.
Los programas de aplicacin se implementan utilizando lenguajes de tercera
o cuarta generacin. Partes de estas aplicaciones son transacciones sobre la
base de datos, que se implementan mediante el lenguaje de manejo de datos
(LMD) del SGBD. Las sentencias de este lenguaje se pueden embeber en un
lenguaje de programacin anfitrin como Visual Basic, Delphi, C, C++, Java,
COBOL, Fortran, Ada o Pascal. En esta etapa, tambin se implementan los
mens, los formularios para la introduccin de datos y los informes de

visualizacin de datos. Para ello, el SGBD puede disponer de lenguajes de

cuarta generacin que permiten el desarrollo rpido de aplicaciones
mediante lenguajes de consultas no procedurales, generadores de informes,
generadores de formularios, generadores de grficos y generadores de
aplicaciones.
Tambin se implementan en esta etapa todos los controles de seguridad e
integridad. Algunos de estos controles se pueden implementar mediante el
LDD y otros puede que haya que implementarlos mediante utilidades del
SGBD o mediante programas de aplicacin.
9. Conversin y carga de datos
Esta etapa es necesaria cuando se est reemplazando un sistema antiguo
por uno nuevo. Los datos se cargan desde el sistema viejo al nuevo
directamente o, si es necesario, se convierten al formato que requiera el
nuevo SGBD y luego se cargan. Si es posible, los programas de aplicacin del
sistema antiguo tambin se convierten para que se puedan utilizar en el
sistema nuevo.
10. Prueba
En esta etapa se prueba y valida el sistema con los requisitos especificados
por los usuarios. Para ello, se debe disear una batera de tests con datos
reales, que se deben llevar a cabo de manera metdica y rigurosa. Es
importante darse cuenta de que la fase de prueba no sirve para demostrar
que no hay fallos, sirve para encontrarlos. Si la fase de prueba se lleva a
cabo correctamente, descubrir los errores en los programas de aplicacin y
en la estructura de la base de datos. Adems, demostrar que los programas
``parecen'' trabajar tal y como se especificaba en los requisitos y que las
prestaciones deseadas ``parecen'' obtenerse. Por ltimo, en las pruebas se
podr hacer una medida de la fiabilidad y la calidad del software
desarrollado.
11. Mantenimiento
Una vez que el sistema est completamente implementado y probado, se
pone en marcha. El sistema est ahora en la fase de mantenimiento en la
que se llevan a cabo las siguientes tareas:

Monitorizacin de las prestaciones del sistema. Si las prestaciones caen

por debajo de un determinado nivel, puede ser necesario reorganizar la
base de datos.
Mantenimiento y actualizacin del sistema. Cuando sea necesario, los
nuevos requisitos que vayan surgiendo se incorporarn al sistema,

siguiendo de nuevo las etapas del ciclo de vida que se acaban de

presentar.
Sistemas de bases de datos y sus aplicaciones.
Los sistemas de base de datos se disean para manejar grandes cantidades
de informacin, la manipulacin de los datos involucra tanto la definicin de
estructuras para el almacenamiento de la informacin como la provisin de
mecanismos para la manipulacin de la informacin, adems un sistema de
base de datos debe de tener implementados mecanismos de seguridad que
garanticen la integridad de la informacin, a pesar de cadas del sistema o
intentos de accesos no autorizados.
Un objetivo principal de un sistema de base de datos es proporcionar a los
usuarios finales una visin abstracta de los datos, esto se logra escondiendo
ciertos detalles de como se almacenan y mantienen los datos.
Objetivos de los sistemas de bases de datos.
Los objetivos principales de un sistema de base de datos es disminuir los
siguientes aspectos:
Redundancia e inconsistencia de datos.
Puesto que los archivos que mantienen almacenada la informacin son
creados por diferentes tipos de programas de aplicacin existe la posibilidad
de que si no se controla detalladamente el almacenamiento, se pueda
originar un duplicado de informacin, es decir que la misma informacin sea
ms de una vez en un dispositivo de almacenamiento. Esto aumenta los
costos de almacenamiento y acceso a los datos, adems de que puede
originar la inconsistencia de los datos - es decir diversas copias de un mismo
dato no concuerdan entre si -, por ejemplo: que se actualiza la direccin de
un cliente en un archivo y que en otros archivos permanezca la anterior.
Dificultad para tener acceso a los datos.
Un sistema de base de datos debe contemplar un entorno de datos que le
facilite al usuario el manejo de los mismos. Supngase un banco, y que uno
de los gerentes necesita averiguar los nombres de todos los clientes que
viven dentro del cdigo postal 78733 de la ciudad. El gerente pide al
departamento de procesamiento de datos que genere la lista
correspondiente. Puesto que esta situacin no fue prevista en el diseo del
sistema, no existe ninguna aplicacin de consulta que permita este tipo de
solicitud, esto ocasiona una deficiencia del sistema.
Aislamiento de los datos.

Puesto que los datos estn repartidos en varios archivos, y estos no

pueden tener diferentes formatos, es difcil escribir nuevos programas de
aplicacin para obtener los datos apropiados.
Anomalas del acceso concurrente.
Para mejorar el funcionamiento global del sistema y obtener un tiempo de
respuesta ms rpido, muchos sistemas permiten que mltiples usuarios
actualicen los datos simultneamente. En un entorno as la interaccin de
actualizaciones concurrentes puede dar por resultado datos inconsistentes.
Para prevenir esta posibilidad debe mantenerse alguna forma de supervisin
en el sistema.
Problemas de seguridad.
La informacin de toda empresa es importante, aunque unos datos lo son
ms que otros, por tal motivo se debe considerar el control de acceso a los
mismos, no todos los usuarios pueden visualizar alguna informacin, por tal
motivo para que un sistema de base de datos sea confiable debe mantener
un grado de seguridad que garantice la autentificacin y proteccin de los
datos. En un banco por ejemplo, el personal de nminas slo necesita ver la
parte de la base de datos que tiene informacin acerca de los distintos
empleados del banco y no a otro tipo de informacin.
Problemas de integridad.
Los valores de datos almacenados en la base de datos deben satisfacer
cierto tipo de restricciones de consistencia. Estas restricciones se hacen
cumplir en el sistema aadiendocdigos apropiados en los diversos
programas de aplicacin.
Sistemas de bases de datos
Los inconvenientes de los sistemas de ficheros se pueden atribuir a dos
factores:

La definicin de los datos se encuentra codificada dentro de los

programas de aplicacin, en lugar de estar almacenada aparte y de
forma independiente.
No hay control sobre el acceso y la manipulacin de los datos ms all
de lo impuesto por los programas de aplicacin.

Para trabajar de un modo ms efectivo, surgieron las bases de datos y los

sistemas de gestin de bases de datos (SGBD).

Una base de datos es un conjunto de datos almacenados entre los que

existen relaciones lgicas y ha sido diseada para satisfacer los
requerimientos de informacin de una empresa u organizacin. En una base
de datos, adems de los datos, tambin se almacena su descripcin.
La base de datos es un gran almacn de datos que se define una sola vez y
que se utiliza al mismo tiempo por muchos departamentos y usuarios. En
lugar de trabajar con ficheros desconectados e informacin redundante,
todos los datos se integran con una mnima cantidad de duplicidad. La base
de datos no pertenece a un departamento, se comparte por toda la
organizacin. Adems, la base de datos no slo contiene los datos de la
organizacin, tambin almacena una descripcin de dichos datos. Esta
descripcin es lo que se denomina metadatos, se almacena en el diccionario
de datos o catlogo y es lo que permite que exista independencia de datos
lgica-fsica.
El modelo seguido con los sistemas de bases de datos, en donde se separa la
definicin de los datos de los programas de aplicacin, es muy similar al
modelo que se sigue en la actualidad para el desarrollo de programas, en
donde se da una definicin interna de un objeto y una definicin externa
separada. Los usuarios del objeto slo ven la definicin externa y no se
deben preocupar de cmo se define internamente el objeto y cmo funciona.
Una ventaja de este modelo, conocido como abstraccin de datos, es que se
puede cambiar la definicin interna de un objeto sin afectar a sus usuarios ya
que la definicin externa no se ve alterada. Del mismo modo, los sistemas de
bases de datos separan la definicin de la estructura de los datos, de los
programas de aplicacin y almacenan esta definicin en la base de datos. Si
se aaden nuevas estructuras de datos o se modifican las ya existentes, los
programas de aplicacin no se ven afectados ya que no dependen
directamente de aquello que se ha modificado.
El sistema de gestin de la base de datos (SGBD) es una aplicacin que
permite a los usuarios definir, crear y mantener la base de datos, y
proporciona acceso controlado a la misma.
El SGBD es la aplicacin que interacciona con los usuarios de los programas
de aplicacin y la base de datos. En general, un SGBD proporciona los
siguientes servicios:

Permite la definicin de la base de datos mediante el lenguaje de

definicin de datos. Este lenguaje permite especificar la estructura y el
tipo de los datos, as como las restricciones sobre los datos. Todo esto
se almacenar en la base de datos.
Permite la insercin, actualizacin, eliminacin y consulta de datos
mediante el lenguaje de manejo de datos. El hecho de disponer de un
lenguaje para realizar consultas reduce el problema de los sistemas de

ficheros, en los que el usuario tiene que trabajar con un conjunto fijo de
consultas, o bien, dispone de un gran nmero de programas de
aplicacin costosos de gestionar.
Hay dos tipos de lenguajes de manejo de datos: los procedurales y los
no procedurales. Estos dos tipos se distinguen por el modo en que
acceden a los datos. Los lenguajes procedurales manipulan la base de
datos registro a registro, mientras que los no procedurales operan
sobre conjuntos de registros. En los lenguajes procedurales se
especifica qu operaciones se deben realizar para obtener los datos
resultado, mientras que en los lenguajes no procedurales se especifica
qu datos deben obtenerse sin decir cmo hacerlo. El lenguaje no
procedural ms utilizado es el SQL (Structured Query Language) que,
de hecho, es un estndar y es el lenguaje de los SGBD relacionales.

Proporciona un acceso controlado a la base de datos mediante:

o un sistema de seguridad, de modo que los usuarios no
autorizados no puedan acceder a la base de datos;
o un sistema de integridad que mantiene la integridad y la
consistencia de los datos;
o un sistema de control de concurrencia que permite el acceso
compartido a la base de datos;
o un sistema de control de recuperacin que restablece la base de
datos despus de que se produzca un fallo del hardware o del
software;
o un diccionario de datos o catlogo accesible por el usuario que
contiene la descripcin de los datos de la base de datos.

A diferencia de los sistemas de ficheros, el SGBD gestiona la estructura fsica

de los datos y su almacenamiento. Con esta funcionalidad, el SGBD se
convierte en una herramienta de gran utilidad. Sin embargo, desde el punto
de vista del usuario, se podra discutir que los SGBD han hecho las cosas ms
complicadas, ya que ahora los usuarios ven ms datos de los que realmente
quieren o necesitan, puesto que ven la base de datos completa. Conscientes
de este problema, los SGBD proporcionan un mecanismo de vistas que
permite que cada usuario tenga su propia vista o visin de la base de datos.
El lenguaje de definicin de datos permite definir vistas como subconjuntos
de la base de datos.
Las vistas, adems de reducir la complejidad permitiendo que cada usuario
vea slo la parte de la base de datos que necesita, tienen otras ventajas:

Las vistas proporcionan un nivel de seguridad, ya que permiten excluir

datos para que ciertos usuarios no los vean.
Las vistas proporcionan un mecanismo para que los usuarios vean los
datos en el formato que deseen.

Una vista representa una imagen consistente y permanente de la base

de datos, incluso si la base de datos cambia su estructura.

Todos los SGBD no presentan la misma funcionalidad, depende de cada

producto. En general, los grandes SGBD multiusuario ofrecen todas las
funciones que se acaban de citar y muchas ms. Los sistemas modernos son
conjuntos de programas extremadamente complejos y sofisticados, con
millones de lneas de cdigo y con una documentacin consistente en varios
volmenes. Lo que se pretende es proporcionar un sistema que permita
gestionar cualquier tipo de requisitos y que tenga un 100% de fiabilidad ante
cualquier fallo hardware o software. Los SGBD estn en continua evolucin,
tratando de satisfacer los requerimientos de todo tipo de usuarios. Por
ejemplo, muchas aplicaciones de hoy en da necesitan almacenar imgenes,
vdeo, sonido, etc. Para satisfacer a este mercado, los SGBD deben cambiar.
Conforme vaya pasando el tiempo irn surgiendo nuevos requisitos, por lo
que los SGBD nunca permanecern estticos.
Ventajas e inconvenientes de los sistemas de bases de datos
Los sistemas de bases de datos presentan numerosas ventajas que se
pueden dividir en dos grupos: las que se deben a la integracin de datos y
las que se deben a la interface comn que proporciona el SGBD.
Ventajas por la integracin de datos
Control sobre la redundancia de datos. Los sistemas de ficheros
almacenan varias copias de los mismos datos en ficheros distintos.
Esto hace que se desperdicie espacio de almacenamiento, adems de
provocar la falta de consistencia de datos. En los sistemas de bases de
datos todos estos ficheros estn integrados, por lo que no se
almacenan varias copias de los mismos datos. Sin embargo, en una
base de datos no se puede eliminar la redundancia completamente, ya
que en ocasiones es necesaria para modelar las relaciones entre los
datos, o bien es necesaria para mejorar las prestaciones.
Consistencia de datos. Eliminando o controlando las redundancias de
datos se reduce en gran medida el riesgo de que haya inconsistencias.
Si un dato est almacenado una sola vez, cualquier actualizacin se
debe realizar slo una vez, y est disponible para todos los usuarios
inmediatamente. Si un dato est duplicado y el sistema conoce esta
redundancia, el propio sistema puede encargarse de garantizar que
todas las copias se mantienen consistentes. Desgraciadamente, no
todos los SGBD de hoy en da se encargan de mantener
automticamente la consistencia.
Ms informacin sobre la misma cantidad de datos. Al estar todos los
datos integrados, se puede extraer informacin adicional sobre los
mismos.

Comparticin de datos. En los sistemas de ficheros, los ficheros

pertenecen a las personas o a los departamentos que los utilizan. Pero
en los sistemas de bases de datos, la base de datos pertenece a la
empresa y puede ser compartida por todos los usuarios que estn
autorizados. Adems, las nuevas aplicaciones que se vayan creando
pueden utilizar los datos de la base de datos existente.
Mantenimiento de estndares. Gracias a la integracin es ms fcil
respetar los estndares necesarios, tanto los establecidos a nivel de la
empresa como los nacionales e internacionales. Estos estndares
pueden establecerse sobre el formato de los datos para facilitar su
intercambio, pueden ser estndares de documentacin, procedimientos
de actualizacin y tambin reglas de acceso.

Ventajas por la existencia del SGBD

Mejora en la integridad de datos. La integridad de la base de datos se
refiere a la validez y la consistencia de los datos almacenados.
Normalmente, la integridad se expresa mediante restricciones o reglas
que no se pueden violar. Estas restricciones se pueden aplicar tanto a
los datos, como a sus relaciones, y es el SGBD quien se debe encargar
de mantenerlas.
Mejora en la seguridad. La seguridad de la base de datos es la
proteccin de la base de datos frente a usuarios no autorizados. Sin
unas buenas medidas de seguridad, la integracin de datos en los
sistemas de bases de datos hace que stos sean ms vulnerables que
en los sistemas de ficheros. Sin embargo, los SGBD permiten mantener
la seguridad mediante el establecimiento de claves para identificar al
personal autorizado a utilizar la base de datos. Las autorizaciones se
pueden realizar a nivel de operaciones, de modo que un usuario puede
estar autorizado a consultar ciertos datos pero no a actualizarlos, por
ejemplo.
Mejora en la accesibilidad a los datos. Muchos SGBD proporcionan
lenguajes de consultas o generadores de informes que permiten al
usuario hacer cualquier tipo de consulta sobre los datos, sin que sea
necesario que un programador escriba una aplicacin que realice tal
tarea.
Mejora en la productividad. El SGBD proporciona muchas de las
funciones estndar que el programador necesita escribir en un sistema
de ficheros. A nivel bsico, el SGBD proporciona todas las rutinas de
manejo de ficheros tpicas de los programas de aplicacin. El hecho de
disponer de estas funciones permite al programador centrarse mejor en
la funcin especfica requerida por los usuarios, sin tener que
preocuparse de los detalles de implementacin de bajo nivel. Muchos
SGBD tambin proporcionan un entorno de cuarta generacin
consistente en un conjunto de herramientas que simplifican, en gran
medida, el desarrollo de las aplicaciones que acceden a la base de

datos. Gracias a estas herramientas, el programador puede ofrecer una

mayor productividad en un tiempo menor.
Mejora en el mantenimiento gracias a la independencia de datos. En
los sistemas de ficheros, las descripciones de los datos se encuentran
inmersas en los programas de aplicacin que los manejan. Esto hace
que los programas sean dependientes de los datos, de modo que un
cambio en su estructura, o un cambio en el modo en que se almacena
en disco, requiere cambios importantes en los programas cuyos datos
se ven afectados. Sin embargo, los SGBD separan las descripciones de
los datos de las aplicaciones. Esto es lo que se conoce como
independencia de datos, gracias a la cual se simplifica el
mantenimiento de las aplicaciones que acceden a la base de datos.
Aumento de la concurrencia. En algunos sistemas de ficheros, si hay
varios usuarios que pueden acceder simultneamente a un mismo
fichero, es posible que el acceso interfiera entre ellos de modo que se
pierda informacin o, incluso, que se pierda la integridad. La mayora
de los SGBD gestionan el acceso concurrente a la base de datos y
garantizan que no ocurran problemas de este tipo.
Mejora en los servicios de copias de seguridad y de recuperacin ante
fallos. Muchos sistemas de ficheros dejan que sea el usuario quien
proporcione las medidas necesarias para proteger los datos ante fallos
en el sistema o en las aplicaciones. Los usuarios tienen que hacer
copias de seguridad cada da, y si se produce algn fallo, utilizar estas
copias para restaurarlos. En este caso, todo el trabajo realizado sobre
los datos desde que se hizo la ltima copia de seguridad se pierde y se
tiene que volver a realizar. Sin embargo, los SGBD actuales funcionan
de modo que se minimiza la cantidad de trabajo perdido cuando se
produce un fallo.

Inconvenientes de los sistemas de bases de datos

Complejidad. Los SGBD son conjuntos de programas muy complejos
con una gran funcionalidad. Es preciso comprender muy bien esta
funcionalidad para poder sacar un buen partido de ellos.
Tamao. Los SGBD son programas complejos y muy extensos que
requieren una gran cantidad de espacio en disco y de memoria para
trabajar de forma eficiente.
Coste econmico del SGBD. El coste de un SGBD vara dependiendo del
entorno y de la funcionalidad que ofrece. Por ejemplo, un SGBD para un
ordenador personal puede costar 500 euros, mientras que un SGBD
para un sistema multiusuario que d servicio a cientos de usuarios
puede costar entre 10.000 y 100.000 euros. Adems, hay que pagar
una cuota anual de mantenimiento que suele ser un porcentaje del
precio del SGBD.
Coste del equipamiento adicional. Tanto el SGBD, como la propia base
de datos, pueden hacer que sea necesario adquirir ms espacio de
almacenamiento. Adems, para alcanzar las prestaciones deseadas, es

posible que sea necesario adquirir una mquina ms grande o una

mquina que se dedique solamente al SGBD. Todo esto har que la
implantacin de un sistema de bases de datos sea ms cara.
Coste de la conversin. En algunas ocasiones, el coste del SGBD y el
coste del equipo informtico que sea necesario adquirir para su buen
funcionamiento, es insignificante comparado al coste de convertir la
aplicacin actual en un sistema de bases de datos. Este coste incluye
el coste de ensear a la plantilla a utilizar estos sistemas y,
probablemente, el coste del personal especializado para ayudar a
realizar la conversin y poner en marcha el sistema. Este coste es una
de las razones principales por las que algunas empresas y
organizaciones se resisten a cambiar su sistema actual de ficheros por
un sistema de bases de datos.
Prestaciones. Un sistema de ficheros est escrito para una aplicacin
especfica, por lo que sus prestaciones suelen ser muy buenas. Sin
embargo, los SGBD estn escritos para ser ms generales y ser tiles
en muchas aplicaciones, lo que puede hacer que algunas de ellas no
sean tan rpidas como antes.
Vulnerable a los fallos. El hecho de que todo est centralizado en el
SGBD hace que el sistema sea ms vulnerable ante los fallos que
puedan producirse.
Los distintitos niveles de abstraccin de una base de datos.

Abstraccin de la informacin.
Una base de datos es en esencia una coleccin de archivos relacionados
entre s, de la cual los usuarios pueden extraer informacin sin considerar las
fronteras de los archivos.
Un objetivo importante de un sistema de base de datos es proporcionar a
los usuarios una visin abstracta de los datos, es decir, el sistema esconde
ciertos detalles de cmo se almacenan y mantienen los datos. Sin embargo
para que el sistema sea manejable, los datos se deben extraer
eficientemente.
Existen diferentes niveles de abstraccin para simplificar la interaccin de
los usuarios con el sistema; Interno, conceptual y externo, especficamente el
de almacenamiento fsico, el del usuario y el del programador.
Nivel fsico.
Es la representacin del nivel ms bajo de abstraccin, en ste se describe
en detalle la forma en como de almacenan los datos en los dispositivos de

almacenamiento(por ejemplo, mediante sealadores o ndices para el acceso

aleatorio a los datos).
Nivel conceptual.
El siguiente nivel ms alto de abstraccin, describe que datos son
almacenados realmente en la base de datos y las relaciones que existen
entre los mismos, describe la base de datos completa en trminos de su
estructura de diseo. El nivel conceptual de abstraccin lo usan los
administradores de bases de datos, quienes deben decidir qu informacin
se va a guardar en la base de datos.
Consta de las siguientes definiciones:
1. Definicin de los datos: Se describen el tipo de datos y la longitud
de campo todos los elementos direccionables en la base. Los
elementos por definir incluyen artculos elementales (atributos), totales
de datos y registros conceptuales (entidades).
2. Relaciones entre datos: Se definen las relaciones entre datos para
enlazar tipos de registros relacionados para el procesamiento de
archivos mltiples.
En el nivel conceptual la base de datos aparece como una coleccin de
registros lgicos, sin descriptores de almacenamiento. En realidad los
archivos conceptuales no existen fsicamente. La transformacin de registros
conceptuales a registros fsicos para el almacenamiento se lleva a cabo por el
sistema y es transparente al usuario.
Nivel de visin.
Nivel ms alto de abstraccin, es lo que el usuario final puede visualizar
del sistema terminado, describe slo una parte de la base de datos al usuario
acreditado para verla. El sistema puede proporcionar muchas visiones para la
misma
base
de
datos.
La interrelacin entre estos tres niveles de abstraccin se ilustra en la
siguiente figura.

1.2 Usuarios y administradores de la base de datos.

Administrador de Bases de Datos
Denominado por sus siglas como: DBA, Database Administrator.
Es la persona encargada y que tiene el control total sobre el sistema de
base de datos, sus funciones principales son:
Definicin de esquema.
Es el esquema original de la base de datos se crea escribiendo un
conjunto de definiciones que son traducidas por el compilador de DDL a un
conjunto de tablas que son almacenadas permanentemente en el diccionario
de datos.
Definicin de la estructura de almacenamiento del mtodo de
acceso.
Estructuras de almacenamiento y de acceso adecuados se crean
escribiendo un conjunto de definiciones que son traducidas por e compilador
del lenguaje de almacenamiento y definicin de datos.
Concesin de autorizacin para el acceso a los datos.
Permite al administrador de la base de datos regular las partes de las
bases de datos que van a ser accedidas por varios usuarios.
Especificacin de lmitantes de integridad.

Es una serie de restricciones que se encuentran almacenados en una

estructura especial del sistema que es consultada por el gestor de base de
datos cada vez que se realice una actualizacin al sistema.
Usuarios de las bases de datos.
Podemos definir a los usuarios como toda persona que tenga todo tipo de
contacto con el sistema de base de datos desde que este se disea, elabora,
termina y se usa.
Los usuarios que accesan una base de datos pueden clasificarse como:
Programadores de aplicaciones.
Los profesionales en computacin que interactuan con el sistema por
medio de llamadas en DML (Lenguaje de Manipulacin de Datos), las cuales
estn incorporadas en un progr ama escrito en un lenguaje de programacin
(Por ejemplo, COBOL, PL/I, Pascal, C, etc.)
Usuarios sofisticados.
Los usuarios sofisticados interactuan con el sistema sin escribir
programas. En cambio escriben sus preguntas en un lenguaje de consultas
de base de datos.
Usuarios especializados.
Algunos usuarios sofisticados escriben aplicaciones de base de datos
especializadas que no encajan en el marco tradicional de procesamiento de
datos.
Usuarios ingenuos.
Los usuarios no sofisticados interactuan con el sistema invocando a uno
de los programas de aplicacin permanentes que se han escrito
anteriormente en el sistema de base de datos, podemos mencionar al
usuario ingenuo como el usuario final que utiliza el sistema de base de datos
sin saber nada del diseo interno del mismo por ejemplo: un cajero.
Componentes de los sistemas de bases de datos.

Estructura general del sistema.

Un sistema de base de datos se encuentra dividido en mdulos cada uno
de los cuales controla una parte de la responsabilidad total de sistema. En la
mayora de los casos, el sistema operativo proporciona nicamente los
servicios ms bsicos y el sistema de la base de datos debe partir de esa
base y controlar adems el manejo correcto de los datos. As el diseo de un
sistema de base de datos debe incluir la interfaz entre el sistema de base de
datos y el sistema operativo.
Los componentes funcionales de un sistema de base de datos, son:
Gestor de archivos.
Gestiona la asignacin de espacio en la memoria del disco y de las
estructuras de datos usadas para representar informacin.
Manejador de base de datos.
Sirve de interfaz entre los datos y los programas de aplicacin.
Procesador de consultas.
Traduce las proposiciones en lenguajes de consulta a instrucciones
de bajo nivel. Adems convierte la solicitud del usuario en una forma ms
eficiente.
Compilador de DDL.
Convierte las proposiciones DDL en un conjunto de tablas que
contienen metadatos, estas se almacenan en el diccionario de datos.
Archivo de datos.
En l se encuentran almacenados fsicamente los datos de una
organizacin.
Diccionario de datos.
Contiene la informacin referente a la estructura de la base de datos.
Indices.
Permiten un rpido acceso a registros que contienen valores
especficos.
Una forma grfica de representar los componentes antes mencionados y la
relacin que existe entre ellos sera la siguiente.

Arquitectura de los sistemas de bases de datos.

Arquitectura de los sistemas de bases de datos
Hay tres caractersticas importantes inherentes a los sistemas de bases de
datos: la separacin entre los programas de aplicacin y los datos, el manejo

de mltiples vistas por parte de los usuarios y el uso de un catlogo para

almacenar el esquema de la base de datos. En 1975, el comit ANSI-SPARC
(American National Standard Institute - Standards Planning and Requirements
Committee) propuso una arquitectura de tres niveles para los sistemas de
bases de datos, que resulta muy til a la hora de conseguir estas tres
caractersticas.
El objetivo de la arquitectura de tres niveles es el de separar los programas
de aplicacin de la base de datos fsica. En esta arquitectura, el esquema de
una base de datos se define en tres niveles de abstraccin distintos:
1. En el nivel interno se describe la estructura fsica de la base de datos
mediante un esquema interno. Este esquema se especifica mediante
un modelo fsico y describe todos los detalles para el almacenamiento
de la base de datos, as como los mtodos de acceso.
2. En el nivel conceptual se describe la estructura de toda la base de
datos para una comunidad de usuarios (todos los de una empresa u
organizacin), mediante un esquema conceptual. Este esquema oculta
los detalles de las estructuras de almacenamiento y se concentra en
describir entidades, atributos, relaciones, operaciones de los usuarios y
restricciones. En este nivel se puede utilizar un modelo conceptual o un
modelo lgico para especificar el esquema.
3. En el nivel externo se describen varios esquemas externos o vistas de
usuario. Cada esquema externo describe la parte de la base de datos
que interesa a un grupo de usuarios determinado y oculta a ese grupo
el resto de la base de datos. En este nivel se puede utilizar un modelo
conceptual o un modelo lgico para especificar los esquemas.
La mayora de los SGBD no distinguen del todo los tres niveles. Algunos
incluyen detalles del nivel fsico en el esquema conceptual. En casi todos los
SGBD que se manejan vistas de usuario, los esquemas externos se
especifican con el mismo modelo de datos que describe la informacin a
nivel conceptual, aunque en algunos se pueden utilizar diferentes modelos
de datos en los niveles conceptual y externo.
Hay que destacar que los tres esquemas no son ms que descripciones de los
mismos datos pero con distintos niveles de abstraccin. Los nicos datos que
existen realmente estn a nivel fsico, almacenados en un dispositivo como
puede ser un disco. En un SGBD basado en la arquitectura de tres niveles,
cada grupo de usuarios hace referencia exclusivamente a su propio esquema
externo. Por lo tanto, el SGBD debe transformar cualquier peticin expresada
en trminos de un esquema externo a una peticin expresada en trminos
del esquema conceptual, y luego, a una peticin en el esquema interno, que
se procesar sobre la base de datos almacenada. Si la peticin es de una
obtencin (consulta) de datos, ser preciso modificar el formato de la
informacin extrada de la base de datos almacenada, para que coincida con

la vista externa del usuario. El proceso de transformar peticiones y resultados

de un nivel a otro se denomina correspondencia o transformacin. Estas
correspondencias pueden requerir bastante tiempo, por lo que algunos SGBD
no cuentan con vistas externas.
La arquitectura de tres niveles es til para explicar el concepto de
independencia de datos que podemos definir como la capacidad para
modificar el esquema en un nivel del sistema sin tener que modificar el
esquema del nivel inmediato superior. Se pueden definir dos tipos de
independencia de datos:

La independencia lgica es la capacidad de modificar el esquema

conceptual sin tener que alterar los esquemas externos ni los
programas de aplicacin. Se puede modificar el esquema conceptual
para ampliar la base de datos o para reducirla. Si, por ejemplo, se
reduce la base de datos eliminando una entidad, los esquemas
externos que no se refieran a ella no debern verse afectados.
La independencia fsica es la capacidad de modificar el esquema
interno sin tener que alterar el esquema conceptual (o los externos).
Por ejemplo, puede ser necesario reorganizar ciertos ficheros fsicos
con el fin de mejorar el rendimiento de las operaciones de consulta o
de actualizacin de datos. Dado que la independencia fsica se refiere
slo a la separacin entre las aplicaciones y las estructuras fsicas de
almacenamiento, es ms fcil de conseguir que la independencia
lgica.

En los SGBD que tienen la arquitectura de varios niveles es necesario ampliar

el catlogo o diccionario, de modo que incluya informacin sobre cmo
establecer la correspondencia entre las peticiones de los usuarios y los datos,
entre los diversos niveles. El SGBD utiliza una serie de procedimientos
adicionales para realizar estas correspondencias haciendo referencia a la
informacin de correspondencia que se encuentra en el catlogo. La
independencia de datos se consigue porque al modificarse el esquema en
algn nivel, el esquema del nivel inmediato superior permanece sin cambios,
slo se modifica la correspondencia entre los dos niveles. No es preciso
modificar los programas de aplicacin que hacen referencia al esquema del
nivel superior.
Por lo tanto, la arquitectura de tres niveles puede facilitar la obtencin de la
verdadera independencia de datos, tanto fsica como lgica. Sin embargo, los
dos niveles de correspondencia implican un gasto extra durante la ejecucin
de una consulta o de un programa, lo cual reduce la eficiencia del SGBD. Es
por esto que muy pocos SGBD han implementado esta arquitectura
completa.

Unidad 2. Modelo entidad relacin.

El modelo E-R se basa en una percepcin del mundo real, la cual esta
formada por objetos bsicos llamados entidades y las relaciones entre estos
objetos as como las caractersticas de estos objetos llamados atributos.
2.1 Conceptos bsicos.}
El modelo entidad-relacin
El modelo entidad-relacin es el modelo conceptual ms utilizado para el
diseo conceptual de bases de datos. Fue introducido por Peter Chen en
1976. El modelo entidad-relacin est formado por un conjunto de conceptos
que permiten describir la realidad mediante un conjunto de representaciones
grficas y lingsticas.
Originalmente, el modelo entidad-relacin slo inclua los conceptos de
entidad, relacin y atributo. Ms tarde, se aadieron otros conceptos, como
los atributos compuestos y las jerarquas de generalizacin, en lo que se ha
denominado modelo entidad-relacin extendido.

Figura 6.1: Conceptos del modelo entidad-relacin extendido.

Entidad

Cualquier tipo de objeto o concepto sobre el que se recoge informacin: cosa,

persona, concepto abstracto o suceso. Por ejemplo: coches, casas,
empleados, clientes, empresas, oficios, diseos de productos, conciertos,
excursiones, etc. Las entidades se representan grficamente mediante
rectngulos y su nombre aparece en el interior. Un nombre de entidad slo
puede aparecer una vez en el esquema conceptual.
Hay dos tipos de entidades: fuertes y dbiles. Una entidad dbil es una
entidad cuya existencia depende de la existencia de otra entidad. Una
entidad fuerte es una entidad que no es dbil.
Relacin (interrelacin)
Es una correspondencia o asociacin entre dos o ms entidades. Cada
relacin tiene un nombre que describe su funcin. Las relaciones se
representan grficamente mediante rombos y su nombre aparece en el
interior.
Las entidades que estn involucradas en una determinada relacin se
denominan entidades participantes. El nmero de participantes en una
relacin es lo que se denomina grado de la relacin. Por lo tanto, una relacin
en la que participan dos entidades es una relacin binaria; si son tres las
entidades participantes, la relacin es ternaria; etc.
Una relacin recursiva es una relacin donde la misma entidad participa ms
de una vez en la relacin con distintos papeles. El nombre de estos papeles
es importante para determinar la funcin de cada participacin.
La cardinalidad con la que una entidad participa en una relacin especifica el
nmero mnimo y el nmero mximo de correspondencias en las que puede
tomar parte cada ocurrencia de dicha entidad. La participacin de una
entidad en una relacin es obligatoria (total) si la existencia de cada una de
sus ocurrencias requiere la existencia de, al menos, una ocurrencia de la otra
entidad participante. Si no, la participacin es opcional (parcial). Las reglas
que definen la cardinalidad de las relaciones son las reglas de negocio.
A veces, surgen problemas cuando se est diseado un esquema conceptual.
Estos problemas, denominados trampas, suelen producirse a causa de una
mala interpretacin en el significado de alguna relacin, por lo que es
importante comprobar que el esquema conceptual carece de dichas trampas.
En general, para encontrar las trampas, hay que asegurarse de que se
entiende completamente el significado de cada relacin. Si no se entienden
las relaciones, se puede crear un esquema que no represente fielmente la
realidad.

Una de las trampas que pueden encontrarse ocurre cuando el esquema

representa una relacin entre entidades, pero el camino entre algunas de sus
ocurrencias es ambiguo. El modo de resolverla es reestructurando el
esquema para representar la asociacin entre las entidades correctamente.
Otra de las trampas sucede cuando un esquema sugiere la existencia de una
relacin entre entidades, pero el camino entre una y otra no existe para
algunas de sus ocurrencias. En este caso, se produce una prdida de
informacin que se puede subsanar introduciendo la relacin que sugera el
esquema y que no estaba representada.
Atributo
Es una caracterstica de inters o un hecho sobre una entidad o sobre una
relacin. Los atributos representan las propiedades bsicas de las entidades
y de las relaciones. Toda la informacin extensiva es portada por los
atributos. Grficamente, se representan mediante bolitas que cuelgan de las
entidades o relaciones a las que pertenecen.
Cada atributo tiene un conjunto de valores asociados denominado dominio. El
dominio define todos los valores posibles que puede tomar un atributo. Puede
haber varios atributos definidos sobre un mismo dominio.
Los atributos pueden ser simples o compuestos. Un atributo simple es un
atributo que tiene un solo componente, que no se puede dividir en partes
ms pequeas que tengan un significado propio. Un atributo compuesto es
un atributo con varios componentes, cada uno con un significado por s
mismo. Un grupo de atributos se representa mediante un atributo compuesto
cuando tienen afinidad en cuanto a su significado, o en cuanto a su uso. Un
atributo compuesto se representa grficamente mediante un valo.
Los atributos tambin pueden clasificarse en monovalentes o polivalentes.
Un atributo monovalente es aquel que tiene un solo valor para cada
ocurrencia de la entidad o relacin a la que pertenece. Un atributo
polivalente es aquel que tiene varios valores para cada ocurrencia de la
entidad o relacin a la que pertenece. A estos atributos tambin se les
denomina multivaluados, y pueden tener un nmero mximo y un nmero
mnimo de valores. La cardinalidad de un atributo indica el nmero mnimo y
el nmero mximo de valores que puede tomar para cada ocurrencia de la
entidad o relacin a la que pertenece. El valor por omisin es

Por ltimo, los atributos pueden ser derivados. Un atributo derivado es aquel
que representa un valor que se puede obtener a partir del valor de uno o
varios atributos, que no necesariamente deben pertenecer a la misma
entidad o relacin.

Identificador
Un identificador de una entidad es un atributo o conjunto de atributos que
determina de modo nico cada ocurrencia de esa entidad. Un identificador de
una entidad debe cumplir dos condiciones:
1. No pueden existir dos ocurrencias de la entidad con el mismo valor del
identificador.
2. Si se omite cualquier atributo del identificador, la condicin anterior
deja de cumplirse.
Toda entidad tiene al menos un identificador y puede tener varios
identificadores alternativos. Las relaciones no tienen identificadores.
Jerarqua de generalizacin
Una entidad E es una generalizacin de un grupo de entidades E , E , ... E ,
si cada ocurrencia de cada una de esas entidades es tambin una ocurrencia
de E. Todas las propiedades de la entidad genrica E son heredadas por las
subentidades.
Cada jerarqua es total o parcial, y exclusiva o superpuesta. Una jerarqua es
total si cada ocurrencia de la entidad genrica corresponde al menos con una
ocurrencia de alguna subentidad. Es parcial si existe alguna ocurrencia de la
entidad genrica que no corresponde con ninguna ocurrencia de ninguna
subentidad. Una jerarqua es exclusiva si cada ocurrencia de la entidad
genrica corresponde, como mucho, con una ocurrencia de una sola de las
subentidades. Es superpuesta si existe alguna ocurrencia de la entidad
genrica que corresponde a ocurrencias de dos o ms subentidades
diferentes.
Un subconjunto es un caso particular de generalizacin con una sola entidad
como subentidad. Un subconjunto siempre es una jerarqua parcial y
exclusiva.

2.1.1

Entidad.

Entidades y conjunto de entidades

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

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

ejemplo el conjunto de entidades CUENTA, podra representar al conjunto de
cuentas de un banco X, o ALUMNO representa a un conjunto de entidades de
todos los alumnos que existen en una institucin.
Una entidad se caracteriza y distingue de otra por los atributos, en
ocasiones llamadas propiedades, que representan las caractersticas de una
entidad. Los atributos de una entidad pueden tomar un conjunto de valores
permitidos al que se le conoce como dominio del atributo. As cada entidad
se describe por medio de un conjunto de parejas formadas por el atributo y el
valor de dato. Habr una pareja para cada atributo del conjunto de
entidades.
Ejemplo:
Hacer una descripcin en pareja para la entidad alumno con los atributos
No_control, Nombre y Especialidad.
Nombre_atributo, Valor
No_control ,

96310418

Nombre

Snchez Osuna Ana

Esp

,
,

LI

O considerando el ejemplo del Vendedor cuyos aributos son: RFC, Nombre,

Salario.
Nombre_atributo, Valor
RFC
Nombre
Salario
2.1.2

, COMD741101YHR
, Daniel Coln Morales
, 3000
Relacin.

Relaciones y conjunto de relaciones.

Una relacin es la asociacin que existe entre dos a ms entidades.
Un conjunto de relaciones es un grupo de relaciones del mismo tipo.
La cantidad de entidades en una relacin determina el grado de la
relacin, por ejemplo la relacin ALUMNO-MATERIA es de grado 2, ya que

intervienen la entidad ALUMNO y la entidad MATERIA, la relacin PADRES,

puede ser de grado 3, ya que involucra las entidades PADRE, MADRE e HIJO.
Aunque el modelo E-R permite relaciones de cualquier grado, la mayora
de las aplicaciones del modelo slo consideran relaciones del grado 2.
Cuando son de tal tipo, se denominan relaciones binarias.
La funcin que tiene una relacin se llama papel, generalmente no se
especifican los papeles o roles, a menos que se quiera aclarar el significado
de una relacin.
Diagrama E-R (sin considerar los atributos, slo las entidades) para los
modelos ejemplificados:

Limitantes de mapeo.
Existen 4 tipos de relaciones que pueden establecerse entre entidades,
las cuales establecen con cuantas entidades de tipo B se pueden relacionar
una entidad de tipo A:
Tipos de relaciones:
Relacin uno a uno.
Se presenta cuando existe una relacin como su nombre lo indica uno a
uno, denominado tambin relacin de matrimonio. Una entidad del tipo A
solo se puede relacionar con una entidad del tipo B, y viceversa;
Por ejemplo: la relacin asignacin de automvil que contiene a las
entidades EMPLEADO, AUTO, es una relacin 1 a 1, ya que asocia a un
empleado con un nico automvil por lo tanto ningn empleado posee ms

de un automvil asignado, y ningn vehculo se asigna a ms de un

trabajador.
Es representado grficamente de la siguiente manera:

A:

Representa

una

entidad
de
cualquier
tipo
diferente
a
una
entidad
B.
R: en el diagrama representa a la relacin que existe entre las entidades.
El extremo de la flecha que se encuentra punteada indica el uno de la
relacin, en este caso, una entidad A ligada a una entidad B.
Relacin uno a muchos.
Significa que una entidad del tipo A puede relacionarse con cualquier
cantidad de entidades del tipo B, y una entidad del tipo B solo puede estar
relacionada con una entidad del tipo A.
Su representacin grfica es la siguiente:

Ntese en este caso que el extremo punteado de la flecha de la relacin

de A y B, indica una entidad A conectada a muchas entidades B.
Muchos a uno.
Indica que una entidad del tipo B puede relacionarse con cualquier
cantidad de entidades del tipo A, mientras que cada entidad del tipo A solo
puede relacionarse con solo una entidad del tipo B.

Muchas a muchas.
Establece que cualquier cantidad de entidades del tipo A pueden estar
relacionados con cualquier cantidad de entidades del tipo B.

A los tipos de relaciones antes descritos, tambin se le conoce como

cardinalidad.
La cardinalidad nos especifica los tipos de relaciones que existen entre las
entidades en el modelo E-R y establecer con esto las validaciones necesarias
para conseguir que los datos de la instancia (valor nico en un momento
dado de una base de datos) correspondan con la realidad.
Algunos ejemplos de cardinalidades de la vida comn pueden ser:
Uno a uno.
El noviazgo, el RFC de cada persona, El CURP personal, El acta de
nacimiento, ya que solo existe un solo documento de este tipo para cada una
de las diferentes personas.
Uno a muchos.
Cliente Cuenta en un banco, Padre-Hijos, Camin-Pasajeros, zoologicoanimales, rbol hojas.
Muchos a muchos.
Arquitecto proyectos, fiesta personas, estudiante materias.
Cabe mencionar que la cardinalidad para cada conjunto de entidades
depende del punto de vista que se le de al modelo en estudio, claro esta,
sujetndose a la realidad.
Otra clase de limitantes lo constituye la dependencia de existencia.
Refirindonos a las mismas entidades A y B, decimos que si la entidad A
depende de la existencia de la entidad B, entonces A es dependiente de
existencia por B, si eliminamos a B tendramos que eliminar por consecuente

la entidad A, en este caso B es la entidad Dominante y A es la entidad

subordinada.
Ejemplo Un adulto puede no tener hijos o ser padre de uno o varios nios mientras que un nio
necesariamente debe tener o haber tenido en algn momento, un padre que lo engendrara y
tampoco puede tener ms de un padre. Esta relacin tiene una cardinalidad mxima de Uno a
Muchos (1:M) y la mnima es de Uno a cero (1:0) ya que al menos un padre debe tener cada nio
y un adulto puede no tener hijos.

Ejemplo En una empresa de desarrollo de software existen varios departamentos en los

cuales pueden trabajar uno o ms empleados, por supuesto siempre tienen al menos un empleado.
No todos los empleados realizan sus labores para un departamento especfico. En este caso la
cardinalidad mxima sigue siendo de Uno a Muchos (1:M) pero la mnima pasa a ser de Cero a
Uno (0:1) porque un empleado puede no trabajar en ningn departamento pero en todo
departamento debe haber al menos un empleado.

Ejemplo : En una eleccin para un cargo pblico, los candidatos al puesto pueden ser
independientes o estar apoyados por uno o varios partidos polticos, por su parte los partidos
polticos pueden apoyar a solo un candidato o abstenerse y no apoyar a ninguno. La cardinalidad
mxima en este caso es de Uno a Muchos (1:M) y la mnima es de Cero a Cero (0:0) ya que un
candidato podra no ser apoyado por ningn partido y un partido podra no apoyar a ningn
candidato.

2.2 Diagramas entidad-relacin (ER).

Diagrama Entidad-Relacin
Denominado por sus siglas como: E-R; Este modelo representa a la
realidad a travs de un esquema grfico empleando los terminologa de
entidades, que son objetos que existen y son los elementos principales que
se identifican en el problema a resolver con el diagramado y se distinguen de
otros por sus caractersticas particulares denominadas atributos, el enlace
que que rige la unin de las entidades esta representada por la relacin del
modelo.
Recordemos que un rectngulo nos representa a las entidades; una elipse
a los atributos de las entidades, y una etiqueta dentro de un rombo nos
indica la relacin que existe entre las entidades, destacando con lneas las
uniones de estas y que la llave primaria de una entidad es aquel atributo que
se encuentra subrayado.
A continuacin mostraremos algunos ejemplos
considerando las cardinalidades que existen entre ellos:

de

modelos

E-R,

Relacin Uno a Uno.

Problema:
Disear el modelo E-R, para la relacin Registro de automvil que consiste
en obtener la tarjeta de circulacin de un automvil con los siguientes datos:Automvil- Modelo, Placas, Color - Tarjeta de circulacin -Propietario,
No_serie, Tipo.

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

En este ejemplo, representamos que existe un solo presidente para cada

pas.

Relacin

muchos

muchos.

El siguiente ejemplo indica que un cliente puede tener muchas

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

Reduccin de diagramas E-R a tablas

Un diagrama E-R, puede ser representado tambin a travs de una
coleccin de tablas. Para cada una de las entidades y relaciones existe una
tabla nica a la que se le asigna como nombre el del conjunto de entidades y
de las relaciones respectivamente, cada tabla tiene un nmero de columnas
que son definidas por la cantidad de atributos y las cuales tienen el nombre
del atributo.
La transformacin de nuestro ejemplo Venta en la que intervienen las
entidades de Vendedor con los atributos RFC, nombre, puesto, salario y
Artculo con los atributos Clave, descripcin, costo.
Cuyo diagrama E-R es el siguiente:

Entonces las tablas resultantes siguiendo la descripcin anterior son:

Tabla Empleado

Nombr
Salari
Puesto
RFC
e
o
Tefilo Vendedo 2000
r
Cesar

Auxiliar
1200
ventas

TEAT701210XY
Z
COV741120AB
C

Tabla artculo
Clave

Descripci
Costo
n

A100

Abanico

C260

Colcha
matrimoni 1200
al

460

Tabla Venta
RFC

Clav
e

TEAT701210XY
C260
Z
COV741120AB
A100
C
Ntese que en la tabla de relacin - Venta -, contiene como atributos a las
llaves primarias de las entidades que intervienen en dicha relacin, en caso
de que exista un atributo en las relaciones, este atributo es anexado como
una fila ms de la tabla;
Por ejemplo si anexamos el atributo fecha a la relacin venta, la tabla que
se originaria sera la siguiente:
RFC

Clav
Fecha
e

TEAT701210XY
C260 10/12/96
Z
COV741120AB
A100 11/12/96
C
DIAGRAMAS DE ENTIDAD - RELACIN

Son esquemas que nos permitan representar conjunto de entidades y sus

relaciones mediante la siguiente simbologa.

*
Conjunto
de
entidades
o
relacin
con
*
Conjunto
entidades
con
* Cada elemento debe etiquetarse con su nombre.

sus
atributos
relaciones

CARDINALIDAD DE LAS RELACIONES

Notas:
a) Las entidades dbiles se sealan como rectngulos de doble pared
b) Los papeles se indican etiquetando las lneas que conectan a los
rectngulos con los rombos.
Ejercicios:

Represente mediante Diagramas E-R las siguientes situaciones:

-- Un vdeo club mantiene el control de sus clientes utilizando los siguientes
datos: numero de credencial, nombre, direccin y telfono; l catalogo de
pelculas contiene para cada cassette los datos clave, titulo, clasificacin y
costo de renta.
A fin de imprimir los pagares y mantener un control de rentas, se registran
tambin las fechas de renta y la cantidad de das que el cliente mantendr la
pelcula.

EJERCICIOS

Academia de clases
Crear un diseo entidad relacin que permita controlar el sistema de
informacin de una academia de cursos siguiendo estas premisas:

Se dan clases a trabajadores y desempleados. Los datos que se

almacenan de los alumnos son el DNI, direccin, nombre, telfono y la
edad
Adems de los que trabajan necesitamos saber el CIF, nombre, telfono
y direccin de la empresa en la que trabajan
Los cursos que imparte la academia se identifican con un cdigo de
curso. Adems se almacena el programa del curso, las horas de
duracin del mismo, el ttulo y cada vez que se imparte se anotar las
fechas de inicio y fin del curso junto con un nmero concreto de curso
(distinto del cdigo) y los datos del profesor o profesora (slo uno por
curso) que son: dni, nombre, apellidos, direccin y telfono
Se almacena la nota obtenida por cada alumno en cada curso teniendo
en cuenta que un mismo alumno o alumna puede realizar varios cursos
y en cada cual obtendr una nota.

Ejercicio 2. Geografa
Crear un diseo entidad relacin que permita almacenar datos geogrficos
referidos a Espaa:

Se almacenar el nombre y poblacin de cada localidad, junto con su

nombre y los datos de la provincia a la que pertenece la localidad, su
nombre, poblacin y superficie.
Necesitamos tambin conocer los datos de cada comunidad autnoma,
nombre, poblacin y superficie y por supuesto las localidades y
provincias de la misma
Para identificar a la provincia se usarn los dos primeros dgitos del
cdigo postal. Es decir 34 ser el cdigo de Palencia y 28 el de Madrid
Necesitamos saber qu localidad es la capital de cada provincia y
cules lo son de cada comunidad

Ejercicio 3. Almacn v1
Se trata de crear una base de datos sobre un almacn de piezas de modo
que:

Cada pieza se identifica con dos letras (tipo, por ejemplo TU=tuerca) y
un nmero (modelo, por ejemplo 6)
Almacenamos un atributo que permite saber la descripcin de cada
tipo de pieza. Es decir el tipo TU tendr la descripcin tuerca.
Necesitamos conocer el precio al que vendemos cada pieza.
Adems hay piezas que se componen de otras piezas, por ejemplo una
puerta se compone de una hoja de madera, una bisagra y un picaporte.
Incluso una pieza puede estar compuesta de otras piezas que ha su vez
pueden estar compuestas por otras y as sucesivamente
Tenemos una serie de almacenes de los que guardamos su nmero,
descripcin, direccin y el nombre de cada estantera de almacn.
Cada estantera se identifica por tres letras.
Necesitaremos saber la cantidad de piezas que tenemos en cada
almacn y saber en qu estanteras estn las piezas buscadas

ACTIVIDAD DIAGRAMA E-R : Biblioteca

Se trata de crear una base de datos sobre el funcionamiento de una

biblioteca

Almacenaremos el DNI, nombre, apellidos, cdigo de socio, direccin y

telfonos (pueden ser varios, pero al menos uno)
La biblioteca presta libros, CDs y pelculas. De todos ellos se almacena
un cdigo de artculo distinto para cada pieza en la biblioteca. Es decir
si tenemos tres libros del Quijote, los tres tendrn un nmero distinto
de artculo.
Adems almacenamos el nombre de cada artculo, el ao en el que se
hizo la obra (sea del tipo que sea) un resumen de la obra y los datos
de los autores del mismo. Se considera autor de la pelcula al director,
de la msica al intrprete y del libro al escritor. Pero de todos ellos se
guarda la misma informacin: nombre y pas.
De los libros adems se guarda el nmero de pginas, de los CDs el
nmero de canciones y de la pelcula la duracin

Anotamos si un artculo concreto est deteriorado y un comentario

sobre el posible deterioro
Cuando se presta un artculo, se anota fecha en la que se presta y la
fecha tope para devolverle. Cuando el socio le devuelve, se anota la
fecha de devolucin.
No hay tope sobre el nmero de artculos que puede prestarse a un
socio e incluso el socio podra llevarse varias veces el mismo artculo
en distintos prstamos

CONJUNTO DE RELACIONES CON DERIVACIN MLTIPLE

Puede darse el caso de que una relacin sea binaria: es decir, que asocie a
mas de dos conjunto de entidades. En estos casos la nica variacin para
representar el modelo consiste en que se establecer CARDINALIDAD para
cada pareja de conjuntos de entidades.

-- En un almacn se lleva el control de los artculos que son vendidos y

facturados. El objetivo primordial adems de mantener la informacin
almacenada consisten en proceso de facturacin. Los datos que se registran:

RFC del cliente, nombre del cliente, domicilio, clave del articulo, descripcin,
costo unitario, numero de factura, fecha, cantidad de artculos vendidos (de
cada
uno).

http://www.itlp.edu.mx/publica/tutoriales/basedat2/index.htm

2.3 Diseo de un esquema de base datos.

Diseo de un esquema de bases de datos Entidad - Relacin.
Para un diseo de un esquema de base de datos hay cuatro fases:
Especificacin de requisitos del usuario.- Consiste en obtener las
necesidades de datos de los usuarios de la base de datos, esto es, sonsacarle
al usuario toda la informacin que se desea plasmar en la base de datos.
Esta es la fase que se dar en el examen.
Diseo conceptual (Entidad - Relacin).


Especificacin de requisitos funcionales.- Vamos a definir las
operaciones que se harn sobre la base de datos (operaciones permitidas
sobre la base de datos)
Especificacin de requisitos funcionales.- Primero se procede a
realizar el diseo lgico, que consiste en adaptar el diseo conceptual al
sistema de gestin de la base de datos, y a continuacin se realiza el diseo
fsico, que consiste en dar todas las caractersticas de almacenamiento de la
base de datos.
http://html.rincondelvago.com/bases-de-datos_18.html

DISEO DE UN ESQUEMA DE BASE DE DATOS E-R

El modelo de datos E-R proporciona un alto grado de flexibilidad en el diseo
de un esquema de base de datos para modelar una empresa.
Un diseador de base de datos puede elegir entre una amplia variedad de
alternativas. Entre las decisiones a tomar se encuentran:

El uso de una relacin ternaria o de un par de relaciones binarias.

Si un concepto de un mundo real se expresa mejor mediante un
conjunto de entidades o por un conjunto de relaciones.
El uso de un atributo o de un conjunto de entidades.
El uso de un conjunto de entidades fuerte o dbil.
La oportunidad de utilizar generalizacin.
La oportunidad de utilizar agregacin.

USO DE CONJUNTOS
RELACIONES

DE

ENTIDADES

DE

CONJUNTOS

DE

La siguiente figura representa un modelo alternativo en el que las cuentas se

representan no como entidades, sino como relaciones entre clientes y
sucursales con nmero-cuenta y saldo como atributos descriptivos.
USO DE CARACTERISTICAS DE E-R AMPLIADO

Un conjunto de entidades fuerte y sus conjuntos de entidades dbiles

dependientes pueden ser considerados como un objeto nico en la
base de datos.

La agregacin agrupa una parte de un diagrama E-R en un conjunto de

entidades nicas.
La generalizacin contribuye a la modularidad permitiendo que
atributos comunes de conjuntos de entidades similares sean
representados una sola vez en un diagrama E-R.

REDUCCIN DE DIAGRAMAS E-R A TABLAS.

Con el objeto de observar instancias de las bases de datos, los diagramas
E-R se convierten en tablas, Se obtiene una tabla por cada conjunto de
entidades o de relaciones.
Existen reglas bien definidas para la conversin de los elementos de un
diagrama E-R a tablas:
a) ENTIDADES FUERTES.- Se crea una tabla con una columna para cada
atributo del conjunto de entidades.
b) ENTIDADES DBILES.- Se crea una tabla que contiene una columna para
los atributos que forman la llave primaria de la entidad fuerte a la que se
encuentra subordinada.
c) RELACIN.- se crea una tabla que contiene una columna para cada
atributo descriptivo de la relacin y para cada atributo que conforma la llave
primaria
de
las
entidades
que
estn
relacionadas.

Convierta a tablas y muestre instancias donde pueda observarse la

CARDINALIDAD del diagrama E-R en el caso del vdeo club.

EL LENGUAJE UNIFICADO DE MODELADO (UML)

En todas las disciplinas de la Ingeniera se hace evidente la importancia de
los modelos ya que describen el aspecto y la conducta de "algo". Ese "algo"
puede existir, estar en un estado de desarrollo o estar, todava, en un estado
de planeacin. Es en este momento cuando los diseadores del modelo
deben investigar los requerimientos del producto terminado y dichos
requerimientos pueden incluir reas tales como funcionalidad, performance y
confiabilidad. Adems, a menudo, el modelo es dividido en un nmero de

vistas, cada una de las cuales describe un aspecto especfico del producto o
sistema en construccin.
El modelado sirve no solamente para los grandes sistemas, aun en
aplicaciones de pequeo tamao se obtienen beneficios de modelado, sin
embargo es un hecho que entre ms grande y ms complejo es el sistema,
ms importante es el papel de que juega el modelado por una simple razn:
"El hombre hace modelos de sistemas complejos porque no puede
entenderlos en su totalidad".
UML es una tcnica para la especificacin sistemas en todas sus fases. Naci
en 1994 cubriendo los aspectos principales de todos los mtodos de diseo
antecesores y, precisamente, los padres de UML son Grady Booch, autor del
mtodo Booch; James Rumbaugh, autor del mtodo OMT e Ivar Jacobson,
autor de los mtodos OOSE y Objectory. La versin 1.0 de UML fue liberada
en Enero de 1997 y ha sido utilizado con xito en sistemas construidos para
toda clase de industrias alrededor del mundo: hospitales, bancos,
comunicaciones, aeronutica, finanzas, etc.
Los principales beneficios de UML son:

Mejores tiempos totales de desarrollo (de 50 % o ms).

Modelar sistemas (y no slo de software) utilizando conceptos
orientados a objetos.
Establecer conceptos y artefactos ejecutables.
Encaminar el desarrollo del escalamiento en sistemas complejos de
misin crtica.
Crear un lenguaje de modelado utilizado tanto por humanos como por
mquinas.
Mejor soporte a la planeacin y al control de proyectos.
Alta reutilizacin y minimizacin de costos.

UML, Mtodo o Lenguaje de Modelado?

UML es un lenguaje para hacer modelos y es independiente de los mtodos
de anlisis y diseo. Existen diferencias importantes entre un mtodo y un
lenguaje de modelado. Un mtodo es una manera explcita de estructurar el
pensamiento y las acciones de cada individuo. Adems, el mtodo le dice al
usuario qu hacer, cmo hacerlo, cundo hacerlo y por qu hacerlo; mientras
que el lenguaje de modelado carece de estas instrucciones. Los mtodos
contienen modelos y esos modelos son utilizados para describir algo y
comunicar los resultados del uso del mtodo.
Un modelo es expresado en un lenguaje de modelado. Un lenguaje de
modelado consiste de vistas, diagramas, elementos de modelo los
smbolos utilizados en los modelos y un conjunto de mecanismos

generales o reglas que indican cmo utilizar los elementos. Las reglas son
sintcticas, semnticas y pragmticas (figura 1).

figura 1
Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una
vista no es una grfica, pero s una abstraccin que consiste en un nmero
de diagramas y todos esos diagramas juntos muestran una "fotografa"
completa del sistema. Las vistas tambin ligan el lenguaje de modelado a los
mtodos o procesos elegidos para el desarrollo. Las diferentes vistas que
UML tiene son:

Vista Use-Case: Una vista que muestra la funcionalidad del sistema

como la perciben los actores externos.

Vista Lgica: Muestra cmo se disea la funcionalidad dentro del

sistema, en trminos de la estructura esttica y la conducta dinmica
del sistema.

Vista de Componentes: Muestra la organizacin de los componentes de

cdigo.

Vista Concurrente: Muestra la concurrencia en el sistema,

direccionando los problemas con la comunicacin y sincronizacin que
estn presentes en un sistema concurrente.

Vista de Distribucin: muestra la distribucin del sistema en la

arquitectura fsica con computadoras y dispositivos llamados nodos.

Diagramas: Los diagramas son las grficas que describen el contenido de

una vista. UML tiene nueve tipos de diagramas que son utilizados en
combinacin para proveer todas las vistas de un sistema: diagramas de caso
de uso, de clases, de objetos, de estados, de secuencia, de colaboracin, de
actividad, de componentes y de distribucin.

Smbolos o Elementos de modelo: Los conceptos utilizados en los

diagramas son los elementos de modelo que representan conceptos comunes
orientados a objetos, tales como clases, objetos y mensajes, y las relaciones
entre estos conceptos incluyendo la asociacin, dependencia y
generalizacin. Un elemento de modelo es utilizado en varios diagramas
diferentes, pero siempre tiene el mismo significado y simbologa.
Reglas o Mecanismos generales: Proveen comentarios extras,
informacin o semntica acerca del elemento de modelo; adems proveen
mecanismos de extensin para adaptar o extender UML a un mtodo o
proceso especfico, organizacin o usuario.
FASES DEL DESARROLLO DE UN SISTEMA
Las fases del desarrollo de sistemas que soporta UML son: Anlisis de
requerimientos, Anlisis, Diseo, Programacin y Pruebas.
Anlisis de Requerimientos
UML tiene casos de uso (use-cases) para capturar los requerimientos del
cliente. A travs del modelado de casos de uso, los actores externos que
tienen inters en el sistema son modelados con la funcionalidad que ellos
requieren del sistema (los casos de uso). Los actores y los casos de uso son
modelados con relaciones y tienen asociaciones entre ellos o stas son
divididas en jerarquas. Los actores y casos de uso son descritos en un
diagrama use-case. Cada use-case es descrito en texto y especifica los
requerimientos del cliente: lo que l (o ella) espera del sistema sin considerar
la funcionalidad que se implementar. Un anlisis de requerimientos puede
ser realizado tambin para procesos de negocios, no solamente para
sistemas de software.
Anlisis
La fase de anlisis abarca las abstracciones primarias (clases y objetos) y
mecanismos que estn presentes en el dominio del problema. Las clases que
se modelan son identificadas, con sus relaciones y descritas en un diagrama
de clases. Las colaboraciones entre las clases para ejecutar los casos de uso
tambin se consideran en esta fase a travs de los modelos dinmicos en
UML. Es importante notar que slo se consideran clases que estn en el
dominio del problema (conceptos del mundo real) y todava no se consideran
clases que definen detalles y soluciones en el sistema de software, tales
como clases para interfaces de usuario, bases de datos, comunicaciones,
concurrencia, etc.
Diseo

En la fase de diseo, el resultado del anlisis es expandido a una solucin

tcnica. Se agregan nuevas clases que proveen de la infraestructura tcnica:
interfaces de usuario, manejo de bases de datos para almacenar objetos en
una base de datos, comunicaciones con otros sistemas, etc. Las clases de
dominio del problema del anlisis son agregadas en esta fase. El diseo
resulta en especificaciones detalladas para la fase de programacin.
Programacin
En esta fase las clases del diseo son convertidas a cdigo en un lenguaje de
programacin orientado a objetos. Cuando se crean los modelos de anlisis y
diseo en UML, lo ms aconsejable es trasladar mentalmente esos modelos a
cdigo.
Pruebas
Normalmente, un sistema es tratado en pruebas de unidades, pruebas de
integracin, pruebas de sistema, pruebas de aceptacin, etc. Las pruebas de
unidades se realizan a clases individuales o a un grupo de clases y son
tpicamente ejecutadas por el programador. Las pruebas de integracin
integran componentes y clases en orden para verificar que se ejecutan como
se especific. Las pruebas de sistema ven al sistema como una "caja negra"
y validan que el sistema tenga la funcionalidad final que le usuario final
espera. Las pruebas de aceptacin conducidas por el cliente verifican que el
sistema satisface los requerimientos y son similares a las pruebas de
sistema.
Unidad 3. Modelo Relacional.
3.1 El modelo relacional.
Modelo relacional
La ventaja del modelo relacional es que los datos se almacenan, al menos
conceptualmente, de un modo en que los usuarios entienden con mayor
facilidad. Los datos se almacenan como tablas y las relaciones entre las filas
y las tablas son visibles en los datos. Este enfoque permite a los usuarios
obtener informacin de la base de datos sin asistencia de sistemas
profesionales de administracin de informacin.
Las caractersticas ms importantes de los modelos relacionales son:
a. Es importante saber que las entradas en la tabla tienen un solo valor
(son atmicos); no se admiten valores mltiples, por lo tanto la
interseccin de un rengln con una columna tiene un solo valor, nunca
un conjunto de valores.

b. Todas las entradas de cualquier columna son de un solo tipo. Por

ejemplo, una columna puede contener nombres de clientes, y en otra
puede tener fechas de nacimiento. Cada columna posee un nombre
nico, el orden de las comunas no es de importancia para la tabla, las
columnas de una tabla se conocen como atributos. Cada atributo tiene
un dominio, que es una descripcin fsica y lgica de valores
permitidos.
c. No existen 2 filas en la tabla que sean idnticas.
d. La informacin en las bases de datos son representados como datos
explcitos, no existen apuntadores o ligas entre las tablas.
En el enfoque relacional es sustancialmente distinto de otros enfoques en
trminos de sus estructuras lgicas y del modo de las operaciones de
entrada/salida. En el enfoque relacional, los datos se organizan en tablas
llamadas relaciones, cada una de las cuales se implanta como un archivo. En
terminologa relacional una fila en una relacin representa un registro o una
entidad; Cada columna en una relacin representa un campo o un atributo.
As, una relacin se compone de una coleccin de entidades(o registros)
cuyos propietarios estn descritos por cierto nmero de atributos
predeterminados implantados como campos.
Estructura de las bases de datos relacionales
La arquitectura relacional se puede expresar en trminos de tres niveles
de abstraccin: nivel interno, conceptual y de visin.
La arquitectura relacional consta de los siguientes componentes:
1. Modelo relacional de datos:
En el nivel conceptual, el modelo relacional de datos est
representado por una coleccin de relaciones almacenadas. Cada
registro de tipo conceptual en un modelo relacional de datos se
implanta como un archivo almacenado distinto.
2. Submodelo de datos:
Los esquemas externos de un sistema relacional se llaman
submodelos relacionales de datos; cada uno consta de uno a ms
escenarios (vistas) para describir los datos requeridos por una
aplicacin dada. Un escenario puede incluir datos de una o ms tablas
de datos. Cada programa de aplicacin est provisto de un buffer
("Area de trabajo de usuario") donde el DBMS puede depositar los
datos recuperados de la base para su procesamiento, o puede guardar

temporalmente sus salidas antes de que el DBMS las escriba en la base

de datos.
3. Esquema de almacenamiento:
En el nivel interno, cada tabla base se implanta como un archivo
almacenado. Para las recuperaciones sobre las claves principal o
secundaria se pueden establecer uno o ms ndices para accesar un
archivo almacenado.
4. Sublenguaje de datos:
Es un lenguaje de manejo de datos para el sistema relacional, el
lgebra relacional y clculo relacional, ambos lenguajes son
"relacionalmente completos", esto es, cualquier relacin que pueda
derivarse de una o ms tablas de datos, tambin se puede derivar con
u solo comando del sublenguaje. Por tanto, el modo de operacin de
entrada/Salida en un sistema relacional se puede procesar en la forma:
una tabla a la vez en lugar de: un registro a la vez; en otras palabras,
se puede recuperar una tabla en vez de un solo registro con la
ejecucin de un comando del sublenguaje de datos.
El modelo relacional
En 1970, el modo en que se vean las bases de datos cambi por completo
cuando E. F. Codd introdujo el modelo relacional. En aquellos momentos, el
enfoque existente para la estructura de las bases de datos utilizaba punteros
fsicos (direcciones de disco) para relacionar registros de distintos ficheros.
Si, por ejemplo, se quera relacionar un registro con un registro
, se deba
aadir al registro
un campo conteniendo la direccin en disco del registro
. Este campo aadido, un puntero fsico, siempre sealara desde el
registro al registro
. Codd demostr que estas bases de datos limitaban
en gran medida los tipos de operaciones que los usuarios podan realizar
sobre los datos. Adems, estas bases de datos eran muy vulnerables a
cambios en el entorno fsico. Si se aadan los controladores de un nuevo
disco al sistema y los datos se movan de una localizacin fsica a otra, se
requera una conversin de los ficheros de datos. Estos sistemas se basaban
en el modelo de red y el modelo jerrquico, los dos modelos lgicos que
constituyeron la primera generacin de los SGBD.
El modelo relacional representa la segunda generacin de los SGBD. En l,
todos los datos estn estructurados a nivel lgico como tablas formadas por
filas y columnas, aunque a nivel fsico pueden tener una estructura
completamente distinta. Un punto fuerte del modelo relacional es la sencillez
de su estructura lgica. Pero detrs de esa simple estructura hay un

fundamento terico importante del que carecen los SGBD de la primera

generacin, lo que constituye otro punto a su favor.
Dada la popularidad del modelo relacional, muchos sistemas de la primera
generacin se han modificado para proporcionar una interfaz de usuario
relacional, con independencia del modelo lgico que soportan (de red o
jerrquico). Por ejemplo, el sistema de red IDMS ha evolucionado a IDMS/R e
IDMS/SQL, ofreciendo una visin relacional de los datos.
En los ltimos aos, se han propuesto algunas extensiones al modelo
relacional para capturar mejor el significado de los datos, para disponer de
los conceptos de la orientacin a objetos y para disponer de capacidad
deductiva.
El modelo relacional, como todo modelo de datos, tiene que ver con tres
aspectos de los datos:

Estructura de datos.
Integridad de datos.
Manejo de datos.

http://www3.uji.es/~mmarques/f47/apun/node45.html
Relaciones
Definiciones informales
El modelo relacional se basa en el concepto matemtico de relacin, que
grficamente se representa mediante una tabla. Codd, que era un experto
matemtico, utiliz una terminologa perteneciente a las matemticas, en
concreto de la teora de conjuntos y de la lgica de predicados.
Una relacin es una tabla con columnas y filas. Un SGBD slo necesita que el
usuario pueda percibir la base de datos como un conjunto de tablas. Esta
percepcin slo se aplica a la estructura lgica de la base de datos (en el
nivel externo y conceptual de la arquitectura de tres niveles ANSI-SPARC). No
se aplica a la estructura fsica de la base de datos, que se puede
implementar con distintas estructuras de almacenamiento.
Un atributo es el nombre de una columna de una relacin. En el modelo
relacional, las relaciones se utilizan para almacenar informacin sobre los
objetos que se representan en la base de datos. Una relacin se representa
grficamente como una tabla bidimensional en la que las filas corresponden
a registros individuales y las columnas corresponden a los campos o atributos
de esos registros. Los atributos pueden aparecer en la relacin en cualquier
orden.

Por ejemplo, la informacin de las oficinas de la empresa inmobiliaria se

representa mediante la relacin OFICINA, que tiene columnas para los
atributos Onum (nmero de oficina), Calle, Area, Poblacin, Telfono y Fax. La
informacin sobre la plantilla se representa mediante la relacin PLANTILLA,
que tiene columnas para los atributos Enum (nmero de empleado), Nombre,
Apellido, Direccin, Telfono, Puesto, Fecha_nac, Salario, DNI, Onum (nmero
de la oficina a la que pertenece el empleado). A continuacin se muestra una
instancia de la relacin OFICINA y una instancia de la relacin PLANTILLA.
Como se puede observar, cada columna contiene valores de un solo atributo.
Por ejemplo, la columna Onum slo contiene nmeros de oficinas que
existen.
OFICINA
Onu
m

Calle

Area

Poblaci
Telfono
n

O5

Enmedio, 8

Centr Castell 964

o
n
240

201 964
340

201

O7

Moyano,
s/n

Centr Castell 964

o
n
760

215 964
670

215

O3

San Miguel,
1

964
250

520 964
255

520

O4

Trafalgar,
23

Castell 964
n
440

284 964
420

284

O2

Cedre, 26

964
810

525 964
811

252

Villarreal
Grao

Villarreal

Fax

PLANTILLA
Enu
m

Nombr Apellid
Telfon
Direccin
Puesto
e
o
o

EL21 Amelia Pastor

964
Magallane
284
s, 15
560

Director

Fecha_n Salari
DNI
ac
o
12/10/62 30000

Onu
m

39432212
O5
E

Castelln
EG37 Pedro

Cubed Bayarri,
o
11

964
535
690

Supervis
24/3/57
or

18000

38766623
O3
X

Administ. 9/5/70

12000

24391223
O3
L

Villarreal
EG14 Luis

964
Collado Borriol, 35 522
230

Villarreal
EA9

Rita

Renau

964
Casalduch
257
, 32
550

Supervis
19/5/60
or

18000

39233190
O7
F

19/12/50 24000

25644309
O3
X

Castelln
EG5

Julio

Prats

964
Melilla, 23 524
590

Director

Villarreal
EL41 Carlos Baeza

Herrero,
51

964
247
250

Supervis
29/2/67
or

18000

39552133
O5
T

Castelln
Un dominio es el conjunto de valores legales de uno o varios atributos. Los
dominios constituyen una poderosa caracterstica del modelo relacional.
Cada atributo de una base de datos relacional se define sobre un dominio,
pudiendo haber varios atributos definidos sobre el mismo dominio. La
siguiente tabla muestra los dominios de los atributos de la relacin OFICINA.
Ntese que en esta relacin hay dos atributos que estn definidos sobre el
mismo dominio, Telfono y Fax.
Atributo

Nombre
Dominio

Onum

NUM_OFICINA

del

Descripcin

Definicin

Posibles valores de nmero de oficina

3
caracteres;
rango
O99

O1-

25
caracteres

Calle

NOM_CALLE

Nombres de calles de Espaa

Area

NOM_AREA

Nombres de reas de las poblaciones 20

de Espaa
caracteres

Poblaci
Nombres
NOM_POBLACION
n
Espaa

de

las

poblaciones

de 15
caracteres

Telfono NUM_TEL_FAX

Nmeros de telfono de Espaa

9 caracteres

Fax

Nmeros de telfono de Espaa

9 caracteres

NUM_TEL_FAX

El concepto de dominio es importante porque permite que el usuario defina,

en un lugar comn, el significado y la fuente de los valores que los atributos
pueden tomar. Esto hace que haya ms informacin disponible para el
sistema cuando ste va a ejecutar una operacin relacional, de modo que las
operaciones que son semnticamente incorrectas, se pueden evitar. Por
ejemplo, no tiene sentido comparar el nombre de una calle con un nmero de
telfono, aunque los dos atributos sean cadenas de caracteres. Sin embargo,
el importe mensual del alquiler de un inmueble no estar definido sobre el
mismo dominio que el nmero de meses que dura el alquiler, pero s tiene
sentido multiplicar los valores de ambos dominios para averiguar el importe
total al que asciende el alquiler. Los SGBD relacionales no ofrecen un soporte
completo de los dominios ya que su implementacin es extremadamente
compleja.
Una tupla es una fila de una relacin. Los elementos de una relacin son las
tuplas o filas de la tabla. En la relacin OFICINA, cada tupla tiene seis valores,
uno para cada atributo. Las tuplas de una relacin no siguen ningn orden.
El grado de una relacin es el nmero de atributos que contiene. La relacin
OFICINA es de grado seis porque tiene seis atributos. Esto quiere decir que
cada fila de la tabla es una tupla con seis valores. El grado de una relacin no
cambia con frecuencia.
La cardinalidad de una relacin es el nmero de tuplas que contiene. Ya que
en las relaciones se van insertando y borrando tuplas a menudo, la
cardinalidad de las mismas vara constantemente.
Una base de datos relacional es un conjunto de relaciones normalizadas.
Definiciones formales
Una relacin
definida sobre un conjunto de dominios
de:
Cabecera: conjunto fijo de pares atributo:dominio

donde cada atributo

corresponde a un nico dominio

consta

y todos los

son distintos, es decir, no hay dos atributos que se llamen igual. El

grado de la relacin es .

Cuerpo: conjunto variable de tuplas. Cada tupla es un conjunto de

pares atributo:valor:

con

, donde

par

se tiene que

es la cardinalidad de la relacin

. En cada

La relacin OFICINA tiene la siguiente cabecera:

{ (Onum:NUM_OFICINA), (Calle:NOM_CALLE), (Area:NOM_AREA),
(Poblacin:NOM_POBLACION),
(Telfono:NUM_TEL_FAX),
(Fax:NUM_TEL_FAX)}.
Siendo la siguiente una de sus tuplas:
{ (Onum:O5), (Calle:Enmedio,8), (Area:Centro),
(Poblacin:Castelln), (Telfono:964 201 240), (Fax:964
201 340)}.
Este conjunto de pares no est ordenado, por lo que esta tupla y la siguiente,
son la misma:
{
(Calle:Enmedio,8),
(Fax:964
201
340),
(Poblacin:Castelln),
(Onum:O5), (Telfono:964 201 240), (Area:Centro)}
Grficamente se suelen representar las relaciones mediante tablas. Los
nombres de las columnas corresponden a los nombres de los atributos y las
filas son cada una de las tuplas de la relacin. Los valores que aparecen en
cada una de las columnas pertenecen al conjunto de valores del dominio
sobre el que est definido el atributo correspondiente.
http://www3.uji.es/~mmarques/f47/apun/node47.html
Propiedades de las relaciones
Las relaciones tienen las siguientes caractersticas:

Cada relacin tiene un nombre y ste es distinto del nombre de todas

las dems.

Los valores de los atributos son atmicos: en cada tupla, cada atributo
toma un solo valor. Se dice que las relaciones estn normalizadas.
No hay dos atributos que se llamen igual.
El orden de los atributos no importa: los atributos no estn ordenados.
Cada tupla es distinta de las dems: no hay tuplas duplicadas.
El orden de las tuplas no importa: las tuplas no estn ordenadas.

http://www3.uji.es/~mmarques/f47/apun/node48.html
Tipos de relaciones
En un SGBD relacional pueden existir varios tipos de relaciones, aunque no
todos manejan todos los tipos.

Relaciones base. Son relaciones reales que tienen nombre y forman

parte directa de la base de datos almacenada (son autnomas).
Vistas. Tambin denominadas relaciones virtuales, son relaciones con
nombre y derivadas: se representan mediante su definicin en
trminos de otras relaciones con nombre, no poseen datos
almacenados propios.
Instantneas. Son relaciones con nombre y derivadas. Pero a diferencia
de las vistas, son reales, no virtuales: estn representadas no slo por
su definicin en trminos de otras relaciones con nombre, sino tambin
por sus propios datos almacenados. Son relaciones de slo de lectura y
se refrescan peridicamente.
Resultados de consultas. Son las relaciones resultantes de alguna
consulta especificada. Pueden o no tener nombre y no persisten en la
base de datos.
Resultados intermedios. Son las relaciones que contienen los
resultados de las subconsultas. Normalmente no tienen nombre y
tampoco persisten en la base de datos.
Resultados temporales. Son relaciones con nombre, similares a las
relaciones base o a las instantneas, pero la diferencia es que se
destruyen automticamente en algn momento apropiado.

http://www3.uji.es/~mmarques/f47/apun/node49.html
Claves
Ya que en una relacin no hay tuplas repetidas, stas se pueden distinguir
unas de otras, es decir, se pueden identificar de modo nico. La forma de
identificarlas es mediante los valores de sus atributos.

Una superclave es un atributo o un conjunto de atributos que identifican de

modo nico las tuplas de una relacin.
Una clave candidata es una superclave en la que ninguno de sus
subconjuntos es una superclave de la relacin. El atributo o conjunto de
atributos
de la relacin
es una clave candidata para
si y slo si
satisface las siguientes propiedades:

Unicidad: nunca hay dos tuplas en la relacin

con el mismo valor de
.
Irreducibilidad (minimalidad): ningn subconjunto de
tiene la
propiedad de unicidad, es decir, no se pueden eliminar componentes
de
sin destruir la unicidad.

Cuando una clave candidata est formada por ms de un atributo, se dice

que es una clave compuesta. Una relacin puede tener varias claves
candidatas. Por ejemplo, en la relacin OFICINA, el atributo Poblacin no es
una clave candidata ya que puede haber varias oficinas en una misma
poblacin. Sin embargo, ya que la empresa asigna un cdigo nico a cada
oficina, el atributo Onum s es una clave candidata de la relacin OFICINA.
Tambin son claves candidatas de esta relacin los atributos Telfono y Fax.
En la base de datos de la inmobiliaria hay una relacin denominada VISITA
que contiene informacin sobre las visitas que los clientes han realizado a los
inmuebles. Esta relacin contiene el nmero del cliente Qnum, el nmero del
inmueble Inum, la fecha de la visita Fecha y un comentario opcional. Para un
determinado nmero de cliente Qnum, se pueden encontrar varias visitas a
varios inmuebles. Del mismo modo, dado un nmero de inmueble Inum,
puede que haya varios clientes que lo hayan visitado. Por lo tanto, el atributo
Qnum no es una clave candidata para la relacin VISITA, como tampoco lo es
el atributo Inum. Sin embargo, la combinacin de los dos atributos s
identifica a una sola tupla, por lo que los dos juntos son una clave candidata
de VISITA. Si se desea considerar la posibilidad de que un mismo cliente
pueda visitar un mismo inmueble en varias ocasiones, habra que incluir el
atributo Fecha para identificar las tuplas de modo nico (aunque ste no es
el caso de la empresa que nos ocupa).
Para identificar las claves candidatas de una relacin no hay que fijarse en un
estado o instancia de la base de datos. El hecho de que en un momento dado
no haya duplicados para un atributo o conjunto de atributos, no garantiza
que los duplicados no sean posibles. Sin embargo, la presencia de duplicados
en un estado de la base de datos s es til para demostrar que cierta
combinacin de atributos no es una clave candidata. El nico modo de
identificar las claves candidatas es conociendo el significado real de los
atributos, ya que esto permite saber si es posible que aparezcan duplicados.
Slo usando esta informacin semntica se puede saber con certeza si un

conjunto de atributos forman una clave candidata. Por ejemplo, viendo la

instancia anterior de la relacin PLANTILLA se podra pensar que el atributo
Apellido es una clave candidata. Pero ya que este atributo es el apellido de
un empleado y es posible que haya dos empleados con el mismo apellido, el
atributo no es una clave candidata.
La clave primaria de un relacin es aquella clave candidata que se escoge
para identificar sus tuplas de modo nico. Ya que una relacin no tiene tuplas
duplicadas, siempre hay una clave candidata y, por lo tanto, la relacin
siempre tiene clave primaria. En el peor caso, la clave primaria estar
formada por todos los atributos de la relacin, pero normalmente habr un
pequeo subconjunto de los atributos que haga esta funcin.
Las claves candidatas que no son escogidas como clave primaria son
denominadas claves alternativas. Por ejemplo, la clave primaria de la relacin
OFICINA es el atributo Onum, siendo Telfono y Fax dos claves alternativas.
En la relacin VISITA slo hay una clave candidata formada por los atributos
Qnum e Inum, por lo que esta clave candidata es la clave primaria.
Una clave ajena es un atributo o un conjunto de atributos de una relacin
cuyos valores coinciden con los valores de la clave primaria de alguna otra
relacin (puede ser la misma). Las claves ajenas representan relaciones
entre datos. El atributo Onum de PLANTILLA relaciona a cada empleado con
la oficina a la que pertenece. Este atributo es una clave ajena cuyos valores
hacen referencia al atributo Onum, clave primaria de OFICINA. Se dice que un
valor de clave ajena representa una referencia a la tupla que contiene el
mismo valor en su clave primaria ( tupla referenciada).
Esquema de una base de datos relacional
Una base de datos relacional es un conjunto de relaciones normalizadas. Para
representar el esquema de una base de datos relacional se debe dar el
nombre de sus relaciones, los atributos de stas, los dominios sobre los que
se definen estos atributos, las claves primarias y las claves ajenas.
El esquema de la base de datos de la empresa inmobiliaria es el siguiente:
OFICINA

(Onum, Calle, Area, Poblacin, Telfono, Fax)

PLANTILLA

(Enum, Nombre, Apellido, Direccin, Telfono, Puesto,

Fecha_nac,
Salario, DNI, Onum)

INMUEBLE

(Inum, Calle, Area, Poblacin, Tipo, Hab, Alquiler, Pnum,

Enum,
Onum)

INQUILINO

(Qnum,
Nombre,
Tipo_pref,

Apellido,

Direccin,

Telfono,

Alquiler_max)
PROPIETARI
(Pnum, Nombre, Apellido, Direccin, Telfono)
O
VISITA
(Qnum, Inum, Fecha, Comentario)
En el esquema, los nombres de las relaciones aparecen seguidos de los
nombres de los atributos encerrados entre parntesis. Las claves primarias
son los atributos subrayados. Las claves ajenas se representan mediante los
siguientes diagramas referenciales.
PLANTILL
Oficina a la que pertenece el
OFICINA
:
A
empleado.
INMUEBLE

PROPIETARI
: Propietario del inmueble.
O

INMUEBLE

PLANTILLA

Empleado
inmueble.

INMUEBLE

OFICINA

Oficina a la que pertenece el

inmueble.

VISITA

INQUILINO

Inquilino que
inmueble.

encargado

ha

visitado

del

el

VISITA
INMUEBLE : Inmueble que ha sido visitado.
A continuacin se muestra un estado (instancia) de la base de datos cuyo
esquema se acaba de definir.
OFICINA
Onu
m

Calle

Area

Poblaci
Telfono
n

O5

Enmedio, 8

Centr Castell 964

o
n
240

201 964
340

201

O7

Moyano,
s/n

Centr Castell 964

o
n
760

215 964
670

215

O3

San Miguel,
1

964
250

520 964
255

520

O4

Trafalgar,
23

Castell 964
n
440

284 964
420

284

O2

Cedre, 26

964
810

525 964
811

252

Villarreal
Grao

Villarreal

Fax

PLANTILLA
Enu

Nombr Apellid Direccin Telfon Puesto

Fecha_n Salari DNI

Onu

EL21 Amelia Pastor

o
964
Magallane
284
s, 15
560

ac
Director

12/10/62 30000

m
39432212
O5
E

Castelln
EG37 Pedro

964
535
690

Cubed Bayarri,
o
11

Supervis
24/3/57
or

18000

38766623
O3
X

Administ. 9/5/70

12000

24391223
O3
L

Supervis
19/5/60
or

18000

39233190
O7
F

19/12/50 24000

25644309
O3
X

Villarreal
EG14 Luis

964
Collado Borriol, 35 522
230
Villarreal

EA9

Rita

Renau

964
Casalduch
257
, 32
550
Castelln

EG5

Julio

Prats

964
Melilla, 23 524
590

Director

Villarreal
EL41 Carlos Baeza

964
247
250

Herrero,
51

Supervis
29/2/67
or

18000

Castelln
INMUEBLE
Inum Calle

Area

Poblaci
Ha Alquile
Tipo
Pnum
n
b
r

IA14 Enmedio, 128

Centro

Castell Cas
6
n
a

600

P46

IL94 Riu Ebre, 24

Ronda
Sur

Castell
Piso 4
n

350

P87

IG4

Grao

Castell
Piso 3
n

300

P40

Cas
3
a

325

P93

Sorell, 5

IG36 Alicante,1

Segorbe

39552133
O5
T

IG21

San Francisco,
10

IG16

Capuchinos,
19

Vinaroz

Piso 5

550

P87

Rafalafen Castell
Piso 4
a
n

400

P93

PROPIETARIO
Pnu
m

Nombr Apellid
Direccin
e
o

Telfono

P46

Ampar
Felip
o

Asensi 24, Castelln

964
680

230

P87

Manuel Obiol

Av. Libertad 15, Vinaroz

964
760

450

P40

Alberto Estrada

Av. del
Castelln

52, 964
740

200

P93

Yoland
Robles Pursima 4, Segorbe
a

964
430

710

Puerto

INQUILINO
Qnu
m

Nombr Apellid
Direccin
e
o

Q76

Juan

Felip

Q56

Ana

Grange San
Rafael
l
Almazora

Q74

Elena

Abaso

Navarra
Castelln

Q62

Alicia

Mori

Alloza 45, Castelln

Barcel
Castelln

VISITA
Qnu
m

Inu
m

Q56

IA14 24/11/99

Q76

IG4

20/10/99 muy lejos

Q56

IG4

26/11/99

Q62

IA14 14/11/99

Fecha

Comentario
muy
pequeo

no
saln

tiene

Telfono

Tipo Alquiler

47, 964
540

282

45, 964
110

551

76, 964
560

205 Cas
700
a

964
580

229

Piso 375
Piso 300

Piso 550

Q56

IG36 28/10/99

http://www3.uji.es/~mmarques/f47/apun/node51.html

lgebra relacional
El lgebra relacional es un conjunto de operaciones que describen paso a
paso como computar una respuesta sobre las relaciones, tal y como stas
son definidas en el modelo relacional. Denominada de tipo procedimental, a
diferencia del Clculo relacional que es de tipo declarativo.
Describe el aspecto de la manipulacin de datos. Estas operaciones se usan como
una representacin intermedia de una consulta a una base de datos y, debido a sus propiedades
algebraicas, sirven para obtener una versin ms optimizada y eficiente de dicha consulta.

Tuplas
Una tupla se define como una funcin finita que asocia unvocamente los
nombres de los atributos de una relacin con los valores de una instanciacin
de la misma. En trminos simplistas, es una fila de una tabla relacional.

Unin compatible
Una unin es compatible entre dos relaciones R, S, si ellas poseen el mismo
grado y el dominio del iesimo elemento de la relacin R es el mismo que el
iesimo elemento de la relacin S.

Grado (Aridad)
Nmero de atributos.

Las operaciones
Bsicas

Cada operador del lgebra acepta una o dos relaciones y retorna una
relacin como resultado. y son operadores unarios, el resto de los
operadores son binarios. Las operaciones bsicas del lgebra relacional son:
Seleccin ()

Permite seleccionar un subconjunto de tuplas de una relacin (R), todas

aquellas que cumplan la(s) condicin(es) P, esto es:

Ejemplo:

Selecciona todas las tuplas que contengan Gmez como apellido en la

relacin Alumnos.
Una condicin puede ser una combinacin booleana, donde se pueden usar
operadores como: , , combinndolos con operadores
.
Proyeccin ()

Permite extraer columnas (atributos) de una relacin, dando como resultado

un subconjunto vertical de atributos de la relacin, esto es:

donde

son atributos de la relacin R .

Ejemplo:

Selecciona los atributos Apellido, Semestre y NumeroControl de la relacin

Alumnos, mostrados como un subconjunto de la relacin Alumnos
Producto cartesiano (x)

El producto cartesiano de dos relaciones se escribe como:

y entrega una relacin, cuyo esquema corresponde a una combinacin de

todas las tuplas de R con cada una de las tuplas de S, y sus atributos
corresponden a los de R seguidos por los de S.
Ejemplo:

Muestra una nueva relacin, cuyo esquema contiene cada una de las tuplas
de la relacin Alumnos junto con las tuplas de la relacin Maestros,
mostrando primero los atributos de la relacin Alumnos seguidos por las
tuplas de la relacin Maestros.
Unin ()

La operacin

retorna el conjunto de tuplas que estn en R, o en S, o en ambas. R y S

deben ser uniones compatibles.
Diferencia (-)

La diferencia de dos relaciones, R y S denotada por:

entrega todas aquellas tuplas que estn en R, pero no en S. R y S deben ser

uniones compatibles.
Estas operaciones son fundamentales en el sentido en que (1) todas las
dems operaciones pueden ser expresadas como una combinacin de stas y
(2) ninguna de estas operaciones pueden ser omitidas sin que con ello se
pierda informacin.
No bsicas o Derivadas
Entre los operadores no bsicos tenemos:
Interseccin ()

La interseccin de dos relaciones se puede especificar en funcin de otros

operadores bsicos:

La interseccin, como en Teora de conjuntos, corresponde al conjunto de

todas las tuplas que estn en R y en S, siendo R y S uniones compatibles.
Unin natural (

) (Natural Join)

La operacin unin natural en el lgebra relacional es la que permite

reconstruir las tablas originales previas al proceso de normalizacin. Consiste
en combinar las proyeccin, seleccin y producto cartesiano en una sola
operacin, donde la condicin es la igualdad Clave Primaria = Clave Externa
(o Foranea), y la proyeccin elimina la columna duplicada (clave externa).
Expresada en las operaciones bsicas, queda

Una reunin theta ( -Join) de dos relaciones es equivalente a:

donde la condicin es libre.

Si la condicin es una igualdad se denomina EquiJoin.
Divisin (/)

Supongamos que tenemos dos relaciones A(x, y) y B(y) donde el dominio de

y en A y B, es el mismo.
El operador divisin A / B retorna todos los distintos valores de x tales que
para todo valor y en B existe una tupla
en A.
Agrupacin ()

Permite agrupar conjuntos de valores en funcin de un campo determinado y

hacer operaciones con otros campos.
Por ejemplo:

sum(puntos) as Total Equipo

Ejemplos
Suponga las relaciones o tablas:

(PARTIDOS).

Alumno
I
NOMBR
D E
0 Pedro
1
1 Juan
1
2 Diego
1
3 Rosita
1
4 Manuel
1

CIUDAD
Santiago

EDA
D
14

Buenos
Aires
Lima

18

Concepci
n
Lima

15

12

17

Apoderado
ID NOMBR FONO ID_ALUMN
E
O
05 Vctor
65464 21
4
4
45 Jos
45465 11
7
4
35 Mara
99745 31
4
5
44 Paz
74742 01
4
3
Curso
COD NOMBRE
FECHA_INICI
O
0114 Sicologa
13-01
2
0214 Biologa
15-02
5
0354 Matemtic 01-03
7
as
0457 Msica
05-04
8
0547 Fsica
20-04
8
Inscrito
I
ID_A COD
D L
1 01
0547
8
2 01
0214
5

DURACIO
N
15

VALO
R
3.000

12

2.500

30

4.000

10

1.500

15

3.200

11

21

41

0354
7
0214
5
0354
7

Mostrar los nombres de los alumnos y su apoderado

Primero, realizaremos una combinacin entre alumnos y apoderados (pues
necesitamos saber a que alumno le corresponde tal apoderado). La
combinacin realizar un producto cartesiano, es decir, para cada tupla de
alumnos (todas las filas de alumnos) har una mezcla con cada una tupla de
apoderados y seleccionar aquellas nuevas tuplas en que alumnos.id sea
igual a apoderados.id_alumno, esto es:
ID
(alumn
o)
01

NOMBRE
(alumno)

CIUDAD

EDA
D
14

ID
(apoderad
o)
054

NOMBRE
(apoderado
)
Vctor

Pedro

Santiago

01

Pedro

Santiago

14

457

Jos

01

Pedro

Santiago

14

354

Mara

01

Pedro

Santiago

14

444

Paz

11

Juan

18

054

Vctor

11

Juan

18

457

Jos

11

Juan

18

354

Mara

11

Juan

18

444

Paz

21

Diego

Buenos
Aires
Buenos
Aires
Buenos
Aires
Buenos
Aires
Lima

12

054

Vctor

21

Diego

Lima

12

457

Jos

21

Diego

Lima

12

354

Mara

21

Diego

Lima

12

444

Paz

31

Rosita

15

054

Vctor

31

Rosita

15

457

Jos

31

Rosita

Concepci
n
Concepci
n
Concepci
n

15

354

Mara

FONO

ID_ALUM
NO

65464
4
45465
4
99745
5
74742
3
65464
4
45465
4
99745
5
74742
3
65464
4
45465
4
99745
5
74742
3
65464
4
45465
4
99745
5

21
11
31
01
21
11
31
01
21
11
31
01
21
11
31

31

Rosita

15

444

Paz

Manuel

Concepci
n
Lima

41

17

054

Vctor

41

Manuel

Lima

17

457

Jos

41

Manuel

Lima

17

354

Mara

41

Manuel

Lima

17

444

Paz

74742
3
65464
4
45465
4
99745
5
74742
3

01

FONO

ID_ALUMN
O

74742
3
45465
4
65464
4
99745
5

01

21
11
31
01

Por tanto, el resultado final de la combinacin es:

Alumnos
ID
NOMBRE
(alumno (alumno)
)
01
Pedro
11

Juan

21

Diego

31

Rosita

CIUDAD

EDA
D

Santiago

14

Apoderados
ID
NOMBRE
(apoderado (apoderado)
)
444
Paz

Buenos
Aires
Lima

18

457

Jos

12

054

Vctor

Concepci
n

15

354

Mara

11
21
31

Ahora, aqu debemos mostrar solo el nombre del alumno y el nombre del
apoderado, esto lo hacemos con un Proyect o Proyeccin, donde la tabla
final sera:

NOMBRE
(alumno)
Pedro
Juan
Diego
Rosita

NOMBRE
(apoderado)
Paz
Jos
Vctor
Mara

Resumiendo en un solo paso:

Alumnos

Apoderados
Se lee: Proyecta los nombre de alumnos y nombre de apoderados de los
alumnos cuyo ID sea el mismo que el ID_ALUMNO de los apoderados.
Mostrar el nombre de los alumnos inscritos y el nombre de los
cursos que tomaron

Comenzaremos con una combinacin entre los inscritos y los cursos para
obtener el nombre de los cursos:

Lo que nos da la tabla:

Resultado 1
I
ID_A COD
D L
(inscritos)
1 01
05478
2 01
02145
3 11
03547

COD
(cursos)
05478
02145
03547

4
5

02145
03547

21
41

02145
03547

NOMBRE
Fsica
Biologa
Matemtic
as
Biologa
Matemtic
as

FECHA_INICI
O
20-04
15-02
01-03

DURACIO
N
15
12
30

VALO
R
3.200
2.500
4.000

15-02
01-03

12
30

2.500
4.000

Como podemos observar, la combinacin solo nos entrega las

combinaciones entre Inscritos y Cursos en que COD sea igual entre los
inscritos y el curso correspondiente.
Ahora necesitamos los nombres de los alumnos inscritos. Al resultado
anterior (Resultado 1) aplicaremos una nueva combinacin comparando los
ID de los alumnos para colocar el nombre adecuado con el estudiante
adecuado:
Resultado 1

Alumnos

O escrito todo junto:

Inscritos

Cursos
Alumnos

La tabla de este nuevo resultado sera:

Resultado 2
ID
ID_A
(inscrit
L
o)

COD
(inscrito
s)

COD
(curso
s)

NOMBRE
(curso)

FECHA_INICI
O

DURACIO
N

VALO
R

ID
(alumn
o)

01

05478

05478

Fsica

20-04

15

3.200

01

NOMBR
E
(alumn
o)
Pedro

01

02145

02145

Biologa

15-02

12

2.500

01

Pedro

11

03547

03547

01-03

30

4.000

11

Juan

4
5

21
41

02145
03547

02145
03547

Matemtic
as
Biologa
Matemtic

15-02
01-03

12
30

2.500
4.000

21
41

Diego
Manuel

CIUDA
D

ED
D

Santia
go
Santia
go
Bueno
s Aires
Lima
Lima

14

14

18

12
17

as

Finalmente con una Proyeccin mostraremos el nombre del alumno y el

curso inscrito:
Resultado 2
Donde la tabla final sera:
Tabla final
NOMBRE
(alumno)
Pedro
Pedro
Juan
Diego
Manuel

NOMBRE
(curso)
Fsica
Biologa
Matemticas
Biologa
Matemticas

La expresin completa sera:

Inscritos
Cursos

Alumnos

Mostrar los nombres y precios de los cursos inscritos con valor

menor a 3.000
Resultado 1
Lo que nos entregara la tabla:
Resultado
final
NOMB
VALO
RE
R
Biolog 2.500
a
Y la expresin completa sera:

Curso
Inscrito

Unidad 4. Introduccin a SQL.

4.1 Introduccin.
Un lenguaje de consulta comercial proporciona una interfaz ms amigable al
usuario. Un ejemplo de este tipo de lenguaje es el SQL, (Structured Query
Languaje, Lenguaje de Consulta Estructurado).
Las partes ms importantes del SQL son:
DDL: Lenguaje de definicin de datos (que nos permite crear las
estructuras)
DML: Lenguaje de manipulacin de datos (que nos permite tener acceso a
las estructuras para suprimir, modificar e insertar)
1. Introduccin
El lenguaje de consulta estructurado (SQL) es un lenguaje de base de datos
normalizado, utilizado por el motor de base de datos de Microsoft Jet. SQL se
utiliza para crear objetos QueryDef, como el argumento de origen del mtodo
OpenRecordSet y como la propiedad RecordSource del control de datos.
Tambin se puede utilizar con el mtodo Execute para crear y manipular
directamente las bases de datos Jet y crear consultas SQL de paso a travs
para manipular bases de datos remotas cliente - servidor.
1.1. Componentes del SQL
El lenguaje SQL est compuesto por comandos, clusulas, operadores y
funciones de agregado. Estos elementos se combinan en las instrucciones
para crear, actualizar y manipular las bases de datos.
1.2 Comandos
Existen dos tipos de comandos SQL:

Los DLL que permiten crear y definir nuevas bases de datos, campos e
ndices.

Los DML que permiten generar consultas para ordenar, filtrar y extraer
datos de la base de datos.

Comandos DLL
Coman
Descripcin
do
CREATE Utilizado para crear nuevas tablas, campos e ndices
DROP Empleado para eliminar tablas e ndices
Utilizado para modificar las tablas agregando campos o
ALTER
cambiando la definicin de los campos.
Comandos DML
Coman
Descripcin
do
Utilizado para consultar registros de la base de datos que
SELECT
satisfagan un criterio determinado
Utilizado para cargar lotes de datos en la base de datos en
INSERT
una nica operacin.
UPDAT Utilizado para modificar los valores de los campos y
E
registros especificados
Utilizado para eliminar registros de una tabla de una base
DELETE
de datos

1.3 Clusulas
Las clusulas son condiciones de modificacin utilizadas para definir los
datos que desea seleccionar o manipular.
Coman
Descripcin
do
Utilizada para especificar la tabla de la cual se van a
FROM
seleccionar los registros
Utilizada para especificar las condiciones que deben reunir
WHERE
los registros que se van a seleccionar
GROUP Utilizada para separar los registros seleccionados en grupos
BY
especficos
Utilizada para expresar la condicin que debe satisfacer
HAVING
cada grupo
ORDER Utilizada para ordenar los registros seleccionados de
BY
acuerdo con un orden especfico

1.4 Operadores Lgicos

Operad
Uso
or
Es el "y" lgico. Evala dos condiciones y devuelve un valor
AND
de verdad slo si ambas son ciertas.
Es el "o" lgico. Evala dos condiciones y devuelve un valor
OR
de verdad si alguna de las dos es cierta.
Negacin lgica. Devuelve el valor contrario de la
NOT
expresin.

1.5 Operadores de Comparacin

Operad
or
<
>
<>
<=
>=
BETWEE
N
LIKE
In

Uso
Menor que
Mayor que
Distinto de
Menor Igual que
Mayor Igual que
Utilizado para especificar un intervalo de valores.
Utilizado en la comparacin de un modelo
Utilizado para especificar registros de una base de datos

1.6 Funciones de Agregado

Las funciones de agregado se usan dentro de una clusula SELECT en
grupos de registros para devolver un nico valor que se aplica a un grupo de
registros.
Coman
Descripcin
do
Utilizada para calcular el promedio de los valores de un
AVG
campo determinado
Utilizada para devolver el nmero de registros de la
COUNT
seleccin
Utilizada para devolver la suma de todos los valores de un
SUM
campo determinado

MAX
MIN

Utilizada para devolver el valor ms alto de un campo

especificado
Utilizada para devolver el valor ms bajo de un campo
especificado

http://www.maestrosdelweb.com/editorial/tutsql1/
4.2 Estructura bsica (SELECT, WHERE).
La estructura bsica de una expresin en SQL contiene 3 partes, Select, From
y Where.
La clusula Select se usa para listar los atributos que se desean en el
resultado de una consulta.
From, Lista las relaciones que se van a examinar en la evaluacin de la
expresin.
Where, es la definicin de las condiciones a las que puede estar sujeta una
consulta.
La consulta tpica de SQL tiene la siguiente forma:
Select A1,A2,A3...An
From r1,r2,r3...rm
Where

Condicin(es)

Donde:
A1,A2,A3...An:

Representan a cada atributo(s) o campos de las

tablas
de
la
base
de
datos
relacional.
R1,r2,r3...rm: Representan a la(s) tabla(s) involucradas en la consulta.
Condicin: Es el enunciado que rige el resultado de la consulta.
Si se omite la clusula Where, la condicin es considerada como
verdadera, la lista de atributos (A1,A2..An) puede sustituirse por un asterisco
(*), para seleccionar todos los atributos de todas las tablas que aparecen en
la clusula From.
Funcionamiento del SQL.
El SQL forma el producto cartesiano de las tablas involucradas en la
clusula From, cumpliendo con la condicin establecida en la orden Where y
despus proyecta el resultado con la orden select.

Para nuestros ejemplos consideremos una tabla llamada CURSO, que

contiene los siguientes campos:

Nombre
campo

del Descripcin

NumC

Nmero del curso, nico para identificar

cada curso

NombreC

Nombre del curso, tambin es nico

DescC

Descripcin del curso

Creditos

Crditos, nmero de estos que gana al

estudiante al cursarlo

Costo

Costo del curso.

Depto

Departamento acadmico que ofrece el

curso.

Datos contenidos en la tabla CURSO

Num
C

NombreC

DescC

Credito Costo Depto

s

A01

Liderazgo

Para
pblico
General

10

S01

Introduccin
artificial

C01

Construccin de torres

la

inteligencia Para ISC y 10

LI
Para IC y 8
Arquitectur
a

100.0 Admn.
0

90.00 Sistemas.

0.00

Ciencias

B01

Situacin actual y perspectivas Para IB

de la alimentacin y la nutricin

80.00 Bioqumica

E01

Historia presente y futuro de la IE e II

energa solar

10

100.0 Electromecnic
0
a.

S02

Tecnologa OLAP

C02

Tecnologa del concreto y de las Para IC

Estructuras

10

100.0 Ciencias
0

B02

Metabolismo de lpidos en el Para IB

camarn

10

0.00

E02

Los
sistemas
potencia

10

100.0 Electromecnic
0
a

S03

Estructura de datos

Para ISC y 8
LI

0.00

Diseo bioclimtico

Para
10
Arquitectur
a

0.00

Para ISC y 8
LI

elctricos

de Para IE

A01

100.0 Sistemas
0

Bioqumica

Sistemas

Arquitectura

C03

Matemticas discretas

General

0.00

Ciencias

S04

Circuitos digitales

Para ISC

10

0.00

Sistemas

S05

Arquitectura de Computadoras

Para ISC

10

50.00 Sistemas

I01

Base de Datos Relacionales

Para ISC y 10
LI

Ejemplos de consultas:
OBTENCIN DE UNA TABLA ENTERA

150.0 Informtica
0

Obtener toda la informacin disponible sobre un curso donde Costo sea

0.

SELECT
FROM
WHERE Costo=0.00

*
CURSO

Resultado de la consulta anterior.

Num
C

NombreC

DescC

C01

Construccin de torres

Para IC y 8
Arquitectur
a

B02

Metabolismo
camarn

S03

Estructura de datos
Diseo bioclimtico

de

lpidos

A01

C03

Matemticas discretas

en

Credito Costo Depto

s
0.00

Ciencias

0.00

Bioqumica

Para ISC y 8
LI

0.00

Sistemas

Para
10
Arquitectur
a

0.00

General

0.00

el Para IB

10

Arquitectura

Ciencias

Colocamos un * debido a que no nos limitan la informacin de la tabla, es

decir nos piden que mostremos todos los datos atributo de la tabla CURSO.
Como la nica condicin en la sentencia WHERE es que la tarifa del curso
sea igual a 0, esta consulta regresa todas las tuplas donde se encuentre que
Costo = 0.00.
Debido a que Costo es un campo numrico, la condicin solo puede
comparar con campos del mismo tipo. Para representar valores negativos se
antepone a la izquierda el signo (-), en este ejemplo se considera solo el
signo (=) para establecer la condicin, sin embargo otros operadores que se
pueden utilizar son:
Menor que <

Mayor que >

Menor o igual que <=
Mayor o igual que >=
Diferente <>
Adems de los operadores booleanos AND, NOT, OR.
Cabe sealar que en la sentencia Where cuando se requiere establecer
condiciones con cadenas, estas son delimitadas por apstrofos (). Las
expresiones de cadenas son comparadas carcter por carcter, dos cadenas
son iguales solo si coinciden todos los caracteres de las mismas.
Ejemplos de consultas con cadenas:

Obtener toda la informacin sobre cualquier curso que ofrezca el

departamento de Ciencias.

SELECT
FROM
WHERE Depto = 'Ciencias';

*
CURSO

Resultado de la consulta.

Num NombreC
C

DescC

Credit
os

Cost
o

Depto

Ciencias

C01

Construccin de torres Para IC y 8

Arquitectur
a

0.00

C02

Tecnologa
concreto y
Estructuras

10

100.0 Ciencias
0

10

0.00

S04

de

Circuitos digitales

del Para IC
las

Para ISC

VISUALIZACIN DE COLUMNAS ESPECIFICADAS.

Sistemas

En los ejemplos anteriores obtenamos toda la tabla completa, ahora

veremos como mostrar solo algunos atributos especficos de una tabla.

Obtener los valores NumC,NombreC y Depto, en este orden de toda la

tabla curso.

SELECT
FROM CURSO;

NumC,

NombreC,

Resultado de la consulta:

NumC

NombreC

Depto

A01

Liderazgo

Admn.

S01

Introduccin a la inteligencia artificial

Sistemas.

C01

Construccin de torres

Ciencias

B01

Situacin actual y perspectivas de la Bioqumica

alimentacin y la nutricin

E01

Historia presente y futuro de la energa Electromecnica.

solar

S02

Tecnologa OLAP

C02

Tecnologa del
Estructuras

B02

Metabolismo de lpidos en el camarn

Bioqumica

E02

Los sistemas elctricos de potencia

Electromecnica

S03

Estructura de datos

Sistemas

Sistemas
concreto

de

las Ciencias

Diseo bioclimtico
A01

Arquitectura

Depto

C03

Matemticas discretas

Ciencias

S04

Circuitos digitales

Sistemas

S05

Arquitectura de Computadoras

Sistemas

I01

Base de Datos Relacionales

Informtica

Observamos que en este caso no se tiene la sentencia Where, no existe

condicin, por lo tanto, todas las filas de la tabla CURSO se recuperan, pero
solo se visualizaran las tres columnas especificadas.
As mismo, empleamos la (,) para separar los campos que deseamos
visualizar.

VISUALIZACIN DE UN SUBCONJUNTO DE FILAS Y COLUMNAS

Seleccionar los valores NumC, Depto y Costo para todos los cursos que
tengan un Costo inferior a $100

SELECT
NumC,
FROM
WHERE Costo < 100.00

Depto,

Costo
CURSO

Como resultado de esta consulta se obtendrn todas aquellas tuplas que

tengan un costo en CTARIFA menor que 100, y se visualizaran solo los
campos de NumC, Depto,Costo.
Podemos observar que este ejemplo cubre el formato general de una
consulta SQL.
La palabra clave

DISTINCT

DISTINCT, es una palabra reservada que elimina las filas que duplicadas en
el resultado de una consulta.

Visualizar todos los departamentos acadmicos que ofrezcan cursos,

rechazando los valores duplicados.

SELECT
FROM CURSO;

DISTINCT

Depto

Resultado de la consulta

Depto
Administraci
n
Sistemas
Ciencias
Bioqumica
electromecni
ca
Arquitectura
Informtica
La palabra DISTINCT va estrictamente despus de la palabra SELECT.
De no haberse utilizado la palabra DISTINCT, el resultado hubiera
mostrado todas las tuplas del atributo Depto que se encontraran, es decir, se
hubiera visualizado la columna de Depto completamente.
EMPLEO DE LOS CONECTORES BOOLEANOS (AND, OR, NOT)
Para emplear las condiciones mltiples dentro de la sentencia WHERE,
utilizamos los conectores lgicos.
El conector AND.
Este conector pide al sistema que seleccione una sola columna
nicamente si ambas condiciones se cumplen.

Obtener toda la informacin sobre todos los cursos que ofrece el

departamento Sistemas que tengan una tarifa igual a 0.

SELECT
FROM
WHERE Depto=Sistemas AND Costo=0.00;

*
CURSO

El resultado de esta consulta sera todas aquellas tuplas que cumplan

exactamente con las dos condiciones establecidas.
El conector OR.
Este conector al igual que el AND permite conectar condiciones mltiples
en la sentencia WHERE, a diferencia del conector AND, el OR permite la
seleccin de filas que cumplan con una sola de las condiciones establecidas a
travs de este conector.

Obtener toda la informacin existente sobre cualquier curso ofrecido

por los departamentos Arquitectura o Bioqumica.

SELECT
FROM
WHERE Depto = Arquitectura OR Depto= Bioqumica;

*
CURSO

El resultado de esta consulta ser la de visualizar todas aquellas tuplas

donde se cumpla cualquiera de las 2 condiciones, es decir mostrara todas las
tuplas que tengan en el atributo Depto=Arquitectura o Bioqumica.
El conector NOT
Este nos permite marcar aquellas tuplas que por alguna razn no
deseamos visualizar.

Obtener el nombre del curso y del departamento de todos los cursos

que no sean ofrecidos por el departamento Sistemas.

SELECT
NombreC,
FROM
WHERE NOT (Depto=Sistemas);

Depto
CURSO

JERARQUIA DE OPERADORES BOOLEANOS.

En orden descendente (de mayor a menor prioridad)
NOT
AND
OR
Existen dos formas para realizar consultas: Join de Querys y Subquerys.

Cuando en la sentencia From colocamos los nombres de las tablas

separados por comas se dice que efectuamos una consulta de la forma Join
de Querys, en este caso se requiere anteponer el nombre de la tabla y un
punto al nombre del atributo. En el Join de Querys el resultado que se
produce con las tablas que intervienen en la consulta es la concatenacin de
las tablas, en donde los valores de una columna de la primera tabla coinciden
con los valores de una segunda tabla, la tabla de resultado tiene una fila por
cada valor coincidente que resulte de las dos tablas originales.
Para ejemplificar esto, consideremos 2 tablas: Tabla1 y Tabla2, entonces:

C1

C2

C3

CA

CB

AAA

10

35

BBB

45

10

CCC

55

65

DDD

20

20

EEE

20

90

FFF

90

90

GGG

15

75

HHH

90

90

35

Resultado de la operacin Join:

C1

C2

C3

CA

CB

AAA

10

10

DDD

20

20

EEE

20

20

FFF

90

90

FFF

90

90

FFF

90

90

HHH

90

90

HHH

90

90

HHH

90

90

Como podemos observar, la comparacin se efectu por las columnas C3 y

CA, que son donde se encontraron valores iguales, el resultado muestra una
tupla por cada coincidencia encontrada.
Cuando las consultas se anidan se conoce como Subquerys o
subconsultas. Este tipo de consulta obtiene resultados parciales reduciendo
el espacio requerido para realizar una consulta.
Nota: Todas las consultas que se resuelven con subquerys pueden resolverse
con Join de Querys, pero no todas las consultas hechas con Join de Querys
pueden resolverse utilizando Subquerys.
Para

ejemplificar

lo

anterior

consideremos

el

ejemplo

ALUMNO cursa
- MATERIA, que tienen los siguientes atributos:
NControl
NControl
Clave
NombreA
Clave
NombreM
Especialidad Calif
Creditos
Direccin
Representando en tablas a los atributos quedaran de la siguiente forma:
Tabla alumno:

NContr Nombre Especialid Direcci

ol
A
ad
n

Tabla cursa:
NContr
Clave Calif
ol

Tabla materia:
Clav Nombre Credito
e
M
s

Obtener el nombre de la materia que cursa el alumno con nmero de

control 97310211 con crditos igual a ocho.

WHERE

SELECT
FROM
creditos=8
and

NombreA
Materia
clave
in(SELECT
clave
FROM
cursa
WHERE NControl=97310211;

Obtener el nmero de control del alumno que tenga alguna calificacin

igual a 100

SELECT
FROM
WHERE Calif=100;

DISTINC(NControl)
Cursa

Obtener el nombre de las materias que cursa el alumno Salvador

Chvez.
SELECT
NombreM
FROM
Materia
WHERE
Clave
in
(SELECT
DISTINC
(Clave)
FROM
Cursa
WHERE
NControl
in
(SELECT
NControl)
FROM
Alumno
WHERE
NombreA=Salvador
Chvez));

FUNCIONES AVANZADAS APLICABLES A CONSULTAS

Existen funciones que permiten la agilizacin de consultas similares a una

hoja de clculo, ya que trabajan en base a renglones y columnas.
COUNT ( ): Cuenta el nmero de tuplas en la columna establecida
MIN ( ): Localiza el valor mnimo de la columna establecida
MAX ( ): Localiza el valor mximo de la columna establecida.
AVG ( ): Obtiene el promedio de valores de la columna establecida
SUM ( ): Obtiene el valor total que implican los valores obtenidos en la
columna establecida.
Ejemplos:

Obtener el nmero de alumnos que existen en la carrera de Ingeniera

en Sistemas Computacionales.

SELECT
FROM
WHERE especialidad=ISC;

NControl

IN

(SELECT
FROM
WHERE NombreA= J.M. Cadena );

Max(Calif)
Cursa
NControl
Alumno

Obtener el promedio de calificaciones de Salvador Chvez.

SELECT
FROM
WHERE

(*)
Alumno

Obtener la mximo calificacin que ha obtenido J.M. Cadena.

SELECT
FROM
WHERE

Count

Avg
NCotrol

IN

(SELECT
FROM
WHERE NombreA=Salvador Chvez);

(Calif)
Cursa
NControl
Alumno

Obtener la suma total de las calificaciones obtenidas por Daniel Coln.

SELECT
FROM
WHERE

Sum
NControl

IN

(SELECT
FROM
WHERE NombreA=Daniel Coln);

(Calif)
Cursa
NControl
Alumno

Hasta aqu hemos visto el manejo sencillo de realizar consultas con SQL,
hay que destacar que en la realizacin de consultas anidadas se tiene que
poner cuidando a la prioridad de los operadores, teniendo cuidado tambin al
momento de agrupar los parntesis que involucran las condiciones con los
operadores.

La estructura bsica de una expresin para consulta SQL consta de tres

clusulas:

SELECT
FROM
WHERE
La clusula SELECT se usa para listar los atributos que se desean en el
resultado
de
una
consulta.
La clusula FROM lista las relaciones que se van a examinar en la evaluacin
de
la
expresin
La clusula WHERE costa de un predicado que implica atributos de las
relaciones
que
aparecen
en
la
clusula
FROM.
Una
consulta
bsica
en
SQL
tiene
la
forma:
SELECT
A1,A2,...,An
FROM
r1,r2,...,rn
WHERE
P
Donde
Ai
=
atributo
(
Campo
de
la
tabla
)
ri
=
relacin
(
Tabla
)
P = predicado ( condicin )
Ejemplo 2.1 : Seleccionar todos los nombres de las personas que tengan el
apellido
MARQUESI
de
la
tabla
persona
SELECT
nombre
FROM
persona
WHERE apellido = " MARQUESI"
ANSWER

NOMBRE

MARTIN

PABLO

El resultado de una consulta es por supuesto otra relacin. Si se omite la

clusula WHERE, el predicado P es verdadero. La lista A1, A2,..., An puede
sustituirse por un asterisco (*) para seleccionar todos los atributos de todas
las relaciones que aparecen en la clusula FROM, aunque no es conveniente

elegir esta ultima opcin salvo que sea necesario pues desperdiciamos
mucho tiempo en obtenerlo
Alias
Es posible renombrar los atributos y las relaciones, a veces por conveniencia
y otras veces por ser necesario, para esto usamos la clausula AS como en el
siguiente ejemplo.
Ejemplo
SELECT
P.nombre
FROM
WHERE apellido = "MARQUESI"

AS
persona

[PRIMER

ANSWER

PRIMER NOMBRE

MARTIN

PABLO

2.2
NOMBRE]
P

En este ejemplo cabe destacar un par de cosas. Cuando nos referimos a un

atributo como es el caso de nombre, podemos referirnos a este usando la
relacin ( o el alias en este ejemplo ) a la que pertenece el atributo seguido
de un punto seguido del atributo <P.nombre>, a veces esta notacin ser
necesaria para eliminar ambigedades. Los corchetes los usamos cuando
usamos espacios en blancos o el caratr () en el nombre de atributo o alias.
Usar alias en los atributos nos permite cambiar el nombre de los atributos de
la
respuesta
a
la
consulta.
Cuando asociamos un alias con una relacin decimos que creamos una
variable de tupla. Estas variables de tuplas se definen en la clusula FROM
despus
del
nombre
de
la
relacin.
En las consultas que contienen subconsultas, se aplica una regla de mbito a
las variables de tupla. En una subconsulta esta permitido usar solo variables
de tupla definidas en la misma subconsulta o en cualquier consulta que
tenga la subconsulta.
http://www.monografias.com/trabajos11/prosq/prosq.shtml#es
Consultas de Seleccin
Las consultas de seleccin se utilizan para indicar al motor de datos que
devuelva informacin de las bases de datos, esta informacin es devuelta en
forma de conjunto de registros que se pueden almacenar en un objeto
recordset. Este conjunto de registros es modificable.

2.1 Consultas bsicas

La sintaxis bsica de una consulta de seleccin es la siguiente:
SELECT Campos FROM Tabla;
En donde campos es la lista de campos que se deseen recuperar y tabla es el
origen de los mismos, por ejemplo:
SELECT Nombre, Telefono FROM Clientes;
Esta consulta devuelve un recordset con el campo nombre y telfono de la
tabla clientes.
2.2 Ordenar los registros
Adicionalmente se puede especificar el orden en que se desean recuperar los
registros de las tablas mediante la clasula ORDER BY Lista de Campos. En
donde Lista de campos representa los campos a ordenar. Ejemplo:
SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER BY Nombre;
Esta consulta devuelve los campos CodigoPostal, Nombre, Telefono de la
tabla Clientes ordenados por el campo Nombre.
Se pueden ordenar los registros por mas de un campo, como por ejemplo:
SELECT CodigoPostal,
CodigoPostal, Nombre;

Nombre,

Telefono

FROM

Clientes

ORDER

BY

Incluso se puede especificar el orden de los registros: ascendente mediante

la clasula (ASC -se toma este valor por defecto) descendente (DESC)
SELECT CodigoPostal, Nombre, Telefono
CodigoPostal DESC , Nombre ASC;

FROM

Clientes

ORDER

BY

2.3 Consultas con Predicado

El predicado se incluye entre la clasula y el primer nombre del campo a
recuperar, los posibles predicados son:
Predicado Descripcin

ALL

Devuelve todos los campos de la tabla

Devuelve un determinado nmero de registros de la
TOP
tabla
Omite los registros cuyos campos seleccionados
DISTINCT
coincidan totalmente
DISTINCRO Omite los registros duplicados basandose en la totalidad
W
del registro y no slo en los campos seleccionados.
ALL:
Si no se incluye ninguno de los predicados se asume ALL. El Motor de base
de datos selecciona todos los registros que cumplen las condiciones de la
instruccin SQL. No se conveniente abusar de este predicado ya que
obligamos al motor de la base de datos a analizar la estructura de la tabla
para averiguar los campos que contiene, es mucho ms rpido indicar el
listado de campos deseados.
SELECT
ALL
SELECT * FROM Empleados;

FROM

Empleados;

TOP:
Devuelve un cierto nmero de registros que entran entre al principio o al final
de un rango especificado por una clusula ORDER BY. Supongamos que
queremos recuperar los nombres de los 25 primeros estudiantes del curso
1994:
SELECT
TOP
25
ORDER BY Nota DESC;

Nombre,

Apellido

FROM

Estudiantes

Si no se incluye la clusula ORDER BY, la consulta devolver un conjunto

arbitrario de 25 registros de la tabla Estudiantes .El predicado TOP no elige
entre valores iguales. En el ejemplo anterior, si la nota media nmero 25 y la
26 son iguales, la consulta devolver 26 registros. Se puede utilizar la
palabra reservada PERCENT para devolver un cierto porcentaje de registros
que caen al principio o al final de un rango especificado por la clusula
ORDER BY. Supongamos que en lugar de los 25 primeros estudiantes
deseamos el 10 por ciento del curso:
SELECT TOP 10 PERCENT
ORDER BY Nota DESC;

Nombre,

Apellido

FROM

Estudiantes

El valor que va a continuacin de TOP debe ser un Integer sin signo.TOP no

afecta a la posible actualizacin de la consulta.

DISTINCT:
Omite los registros que contienen datos duplicados en los campos
seleccionados. Para que los valores de cada campo listado en la instruccin
SELECT se incluyan en la consulta deben ser nicos.
Por ejemplo, varios empleados listados en la tabla Empleados pueden tener
el mismo apellido. Si dos registros contienen Lpez en el campo Apellido, la
siguiente instruccin SQL devuelve un nico registro:
SELECT DISTINCT Apellido FROM Empleados;
Con otras palabras el predicado DISTINCT devuelve aquellos registros cuyos
campos indicados en la clusula SELECT posean un contenido diferente. El
resultado de una consulta que utiliza DISTINCT no es actualizable y no
refleja los cambios subsiguientes realizados por otros usuarios.
DISTINCTROW:
Devuelve los registros diferentes de una tabla; a diferencia del predicado
anterior que slo se fijaba en el contenido de los campos seleccionados, ste
lo hace en el contenido del registro completo independientemente de los
campo indicados en la clusula SELECT.
SELECT DISTINCTROW Apellido FROM Empleados;
Si la tabla empleados contiene dos registros: Antonio Lpez y Marta Lpez el
ejemplo del predicado DISTINCT devuleve un nico registro con el valor
Lpez en el campo Apellido ya que busca no duplicados en dicho campo. Este
ltimo ejemplo devuelve dos registros con el valor Lpez en el apellido ya
que
se
buscan
no
duplicados
en
el
registro
completo.
2.4 Alias
En determinadas circunstancias es necesario asignar un nombre a alguna
columna determinada de un conjunto devuelto, otras veces por simple
capricho o por otras circunstancias. Para resolver todas ellas tenemos la
palabra reservada AS que se encarga de asignar el nombre que deseamos a
la columna deseada. Tomado como referencia el ejemplo anterior podemos
hacer que la columna devuelta por la consulta, en lugar de llamarse apellido
(igual que el campo devuelto) se llame Empleado. En este caso
procederamos de la siguiente forma:
SELECT DISTINCTROW Apellido AS Empleado FROM Empleados;
2.5 Recuperar Informacin de una base de Datos Externa

Para concluir este captulo se debe hacer referencia a la recuperacin de

registros de bases de datos externa. Es ocasiones es necesario la
recuperacin de informacin que se encuentra contenida en una tabla que no
se encuentra en la base de datos que ejecutar la consulta o que en ese
momento no se encuentra abierta, esta situacin la podemos salvar con la
palabra reservada IN de la siguiente forma:
SELECT DISTINCTROW Apellido
IN 'c:\databases\gestion.mdb';

AS

Empleado

FROM

Empleados

En donde c:\databases\gestion.mdb es la base de datos que contiene la tabla

Empleados.
http://www.maestrosdelweb.com/editorial/tutsql3/
3. Criterios de Seleccin
En el captulo anterior se vio la forma de recuperar los registros de las tablas,
las formas empleadas devolvan todos los registros de la mencionada tabla. A
lo largo de este captulo se estudiarn las posibilidades de filtrar los registros
con el fin de recuperar solamente aquellos que cumplan unas condiciones
preestablecidas.
Antes de comenzar el desarrollo de este captulo hay que recalcar tres
detalles de vital importancia. El primero de ellos es que cada vez que se
desee establecer una condicin referida a un campo de texto la condicin de
bsqueda debe ir encerrada entre comillas simples; la segunda es que no se
posible establecer condiciones de bsqueda en los campos memo y; la
tercera y ltima hace referencia a las fechas. Las fechas se deben escribir
siempre en formato mm-dd-aa en donde mm representa el mes, dd el da y
aa el ao, hay que prestar atencin a los separadores -no sirve la separacin
habitual de la barra (/), hay que utilizar el guin (-) y adems la fecha debe ir
encerrada entre almohadillas (#). Por ejemplo si deseamos referirnos al da 3
de Septiembre de 1995 deberemos hacerlo de la siguiente forma; #09-0395# #9-3-95#.
3.1 Operadores Lgicos
Los operadores lgicos soportados por SQL son: AND, OR, XOR, Eqv, Imp,
Is y Not. A excepcin de los dos ltimos todos poseen la siguiente sintaxis:
<expresin1> operador <expresin2>

En donde expresin1 y expresin2 son las condiciones a evaluar, el

resultado de la operacin vara en funcin del operador lgico. La tabla
adjunta muestra los diferentes posibles resultados:
<expresin1>
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Verdad
Falso
Falso
Falso
Null
Null
Null

Operador
AND
AND
AND
AND
OR
OR
OR
OR
XOR
XOR
XOR
XOR
Eqv
Eqv
Eqv
Eqv
Imp
Imp
Imp
Imp
Imp
Imp
Imp
Imp
Imp

<expresin2>
Falso
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Falso
Verdad
Falso
Verdad
Falso
Verdad
Falso
Verdad
Falso
Verdad
Falso
Null
Verdad
Falso
Null
Verdad
Falso
Null

Resultado
Falso
Verdad
Falso
Falso
Verdad
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Falso
Verdad
Falso
Falso
Verdad
Verdad
Falso
Null
Verdad
Verdad
Verdad
Verdad
Null
Null

Si a cualquiera de las anteriores condiciones le anteponemos el operador

NOT el resultado de la operacin ser el contrario al devuelto sin el operador
NOT.
El ltimo operador denominado Is se emplea para comparar dos variables de
tipo objeto <Objeto1> Is <Objeto2>. Este operador devuelve verdad si los
dos objetos son iguales.
SELECT * FROM Empleados WHERE Edad > 25 AND Edad < 50;
SELECT * FROM Empleados WHERE (Edad > 25 AND Edad < 50) OR Sueldo =
100;
SELECT * FROM Empleados WHERE NOT Estado = 'Soltero';

SELECT * FROM Empleados WHERE (Sueldo > 100 AND Sueldo < 500) OR
(Provincia = 'Madrid' AND Estado = 'Casado');
3.2 Intervalos de Valores
Para indicar que deseamos recuperar los registros segn el intervalo de
valores de un campo emplearemos el operador Between cuya sintaxis es:
(campo [Not] Between valor1 And valor2 (la condicin Not es
opcional)
En este caso la consulta devolvera los registros que contengan en "campo"
un valor incluido en el intervalo valor1, valor2 (ambos inclusive). Si
anteponemos la condicin Not devolver aquellos valores no incluidos en el
intervalo.
SELECT * FROM Pedidos WHERE CodPostal Between 28000 And 28999;
(Devuelve los pedidos realizados en la provincia de Madrid)
SELECT IIf(CodPostal Between 28000 And 28999, 'Provincial', 'Nacional')
FROM
Editores;
(Devuelve el valor 'Provincial' si el cdigo postal se encuentra en el intervalo,
'Nacional' en caso contrario)
3.3 El Operador Like
Se utiliza para comparar una expresin de cadena con un modelo en una
expresin SQL. Su sintaxis es:
expresin Like modelo
En donde expresin es una cadena modelo o campo contra el que se
compara expresin. Se puede utilizar el operador Like para encontrar valores
en los campos que coincidan con el modelo especificado. Por modelo puede
especificar un valor completo (Ana Mara), o se pueden utilizar caracteres
comodn como los reconocidos por el sistema operativo para encontrar un
rango de valores (Like An*).
El operador Like se puede utilizar en una expresin para comparar un valor
de un campo con una expresin de cadena. Por ejemplo, si introduce Like C*
en una consulta SQL, la consulta devuelve todos los valores de campo que
comiencen por la letra C. En una consulta con parmetros, puede hacer que
el usuario escriba el modelo que se va a utilizar.

El ejemplo siguiente devuelve los datos que comienzan con la letra P seguido
de cualquier letra entre A y F y de tres dgitos:
Like 'P[A-F]###'
Este ejemplo devuelve los campos cuyo contenido empiece con una letra de
la A a la D seguidas de cualquier cadena.
Like '[A-D]*'
En la tabla siguiente se muestra cmo utilizar el operador Like para
comprobar expresiones con diferentes modelos.
Tipo de coincidencia Modelo Planteado Coincide
No Coincide
Varios caracteres
'a*a'
'aa', 'aBa', 'aBBBa' 'aBC'
Carcter especial
'a[*]a'
'a*a'
'aaa'
Varios caracteres
'ab*'
'abcdefg', 'abc'
'cab', 'aab'
Un solo carcter
'a?a'
'aaa', 'a3a', 'aBa' 'aBBBa'
Un solo dgito
'a#a'
'a0a', 'a1a', 'a2a' 'aaa', 'a10a'
Rango de caracteres '[a-z]'
'f', 'p', 'j'
'2', '&'
Fuera de un rango
'[!a-z]'
'9', '&', '%'
'b', 'a'
Distinto de un dgito
'[!0-9]'
'A', 'a', '&', '~'
'0', '1', '9'
Combinada
'a[!b-m]#'
'An9', 'az0', 'a99' 'abc', 'aj0'
3.4 El Operador In
Este operador devuelve aquellos registros cuyo campo indicado coincide con
alguno de los indicados en una lista. Su sintaxis es:
expresin [Not] In(valor1, valor2, . . .)
SELECT * FROM Pedidos WHERE Provincia In ('Madrid', 'Barcelona', 'Sevilla');
3.5 La clusula WHERE
La clusula WHERE puede usarse para determinar qu registros de las tablas
enumeradas en la clusula FROM aparecern en los resultados de la
instruccin SELECT. Despus de escribir esta clusula se deben especificar
las condiciones expuestas en los apartados 3.1 y 3.2. Si no se emplea esta
clusula, la consulta devolver todas las filas de la tabla. WHERE es
opcional, pero cuando aparece debe ir a continuacin de FROM.
SELECT Apellidos, Salario FROM Empleados WHERE Salario > 21000;

SELECT
Id_Producto,
Existencias
WHERE Existencias <= Nuevo_Pedido;

FROM

Productos

SELECT * FROM Pedidos WHERE Fecha_Envio = #5/10/94#;

SELECT Apellidos, Nombre FROM Empleados WHERE Apellidos = 'King';
SELECT Apellidos, Nombre FROM Empleados WHERE Apellidos Like 'S*';
SELECT Apellidos, Salario FROM Empleados WHERE Salario Between 200 And
300;
SELECT Apellidos, Salario FROM Empl WHERE Apellidos Between 'Lon' And
'Tol';
SELECT Id_Pedido, Fecha_Pedido FROM Pedidos WHERE Fecha_Pedido
Between #1-1-94# And #30-6-94#;
SELECT Apellidos, Nombre, Ciudad FROM Empleados WHERE Ciudad
In ('Sevilla', 'Los Angeles', 'Barcelona');
http://www.maestrosdelweb.com/editorial/tutsql3/
4.3 Funciones de agregacin (GROUP BY, HAVING).
Agrupamiento de Registros
4.1 GROUP BY
Combina los registros con valores idnticos, en la lista de campos
especificados, en un nico registro. Para cada registro se crea un valor
sumario si se incluye una funcin SQL agregada, como por ejemplo Sum o
Count, en la instruccin SELECT. Su sintaxis es:
SELECT campos FROM tabla WHERE criterio GROUP BY campos del grupo
GROUP BY es opcional. Los valores de resumen se omiten si no existe una
funcin SQL agregada en la instruccin SELECT. Los valores Null en los
campos GROUP BY se agrupan y no se omiten. No obstante, los valores Null
no se evalan en ninguna de las funciones SQL agregadas.
Se utiliza la clusula WHERE para excluir aquellas filas que no desea
agrupar, y la clusula HAVING para filtrar los registros una vez agrupados.

A menos que contenga un dato Memo u Objeto OLE , un campo de la lista de

campos GROUP BY puede referirse a cualquier campo de las tablas que
aparecen en la clusula FROM, incluso si el campo no esta incluido en la
instruccin SELECT, siempre y cuando la instruccin SELECT incluya al
menos una funcin SQL agregada.
Todos los campos de la lista de campos de SELECT deben o bien incluirse en
la clusula GROUP BY o como argumentos de una funcin SQL agregada.
SELECT Id_Familia, Sum(Stock) FROM Productos GROUP BY Id_Familia;
Una vez que GROUP BY ha combinado los registros, HAVING muestra
cualquier registro agrupado por la clusula GROUP BY que satisfaga las
condiciones de la clusula HAVING.
HAVING es similar a WHERE, determina qu registros se seleccionan. Una
vez que los registros se han agrupado utilizando GROUP BY, HAVING
determina cuales de ellos se van a mostrar.
SELECT Id_Familia Sum(Stock) FROM Productos GROUP BY Id_Familia
HAVING Sum(Stock) > 100 AND NombreProducto Like BOS*;
4.2 AVG
Calcula la media aritmtica de un conjunto de valores contenidos en un
campo especificado de una consulta. Su sintaxis es la siguiente
Avg(expr)
En donde expr representa el campo que contiene los datos numricos para
los que se desea calcular la media o una expresin que realiza un clculo
utilizando los datos de dicho campo. La media calculada por Avg es la media
aritmtica (la suma de los valores dividido por el nmero de valores). La
funcin Avg no incluye ningn campo Null en el clculo.
SELECT Avg(Gastos) AS Promedio FROM Pedidos WHERE Gastos > 100;
4.3 Count
Calcula el nmero de registros devueltos por una consulta. Su sintaxis es la
siguiente
Count(expr)

En donde expr contiene el nombre del campo que desea contar. Los
operandos de expr pueden incluir el nombre de un campo de una tabla, una
constante o una funcin (la cual puede ser intrnseca o definida por el usuario
pero no otras de las funciones agregadas de SQL). Puede contar cualquier
tipo de datos incluso texto.
Aunque expr puede realizar un clculo sobre un campo, Count simplemente
cuenta el nmero de registros sin tener en cuenta qu valores se almacenan
en los registros. La funcin Count no cuenta los registros que tienen campos
null a menos que expr sea el carcter comodn asterisco (*). Si utiliza un
asterisco, Count calcula el nmero total de registros, incluyendo aquellos
que contienen campos null. Count(*) es considerablemente ms rpida que
Count(Campo). No se debe poner el asterisco entre dobles comillas ('*').
SELECT Count(*) AS Total FROM Pedidos;
Si expr identifica a mltiples campos, la funcin Count cuenta un registro
slo si al menos uno de los campos no es Null. Si todos los campos
especificados son Null, no se cuenta el registro. Hay que separar los
nombres de los campos con ampersand (&).
SELECT Count(FechaEnvo & Transporte) AS Total FROM Pedidos;
4.4 Max, Min
Devuelven el mnimo o el mximo de un conjunto de valores contenidos en
un campo especifico de una consulta. Su sintaxis es:
Min(expr)
Max(expr)
En donde expr es el campo sobre el que se desea realizar el clculo. Expr
pueden incluir el nombre de un campo de una tabla, una constante o una
funcin (la cual puede ser intrnseca o definida por el usuario pero no otras
de las funciones agregadas de SQL).
SELECT Min(Gastos) AS ElMin FROM Pedidos WHERE Pais = 'Espaa';
SELECT Max(Gastos) AS ElMax FROM Pedidos WHERE Pais = 'Espaa';
4.5 StDev, StDevP
Devuelve estimaciones de la desviacin estndar para la poblacin (el total
de los registros de la tabla) o una muestra de la poblacin representada
(muestra aleatoria) . Su sintaxis es:

StDev(expr)
StDevP(expr)
En donde expr representa el nombre del campo que contiene los datos que
desean evaluarse o una expresin que realiza un clculo utilizando los datos
de dichos campos. Los operandos de expr pueden incluir el nombre de un
campo de una tabla, una constante o una funcin (la cual puede ser
intrnseca o definida por el usuario pero no otras de las funciones agregadas
de SQL)
StDevP evala una poblacin, y StDev evala una muestra de la poblacin.
Si la consulta contiene menos de dos registros (o ningn registro para
StDevP), estas funciones devuelven un valor Null (el cual indica que la
desviacin estndar no puede calcularse).
SELECT StDev(Gastos) AS Desviacion FROM Pedidos WHERE Pais = 'Espaa';
SELECT StDevP(Gastos) AS Desviacion FROM Pedidos WHERE Pais= 'Espaa';
4.6 Sum
Devuelve la suma del conjunto de valores contenido en un campo especifico
de una consulta. Su sintaxis es:
SumP(expr)
En donde expr representa el nombre del campo que contiene los datos que
desean sumarse o una expresin que realiza un clculo utilizando los datos
de dichos campos. Los operandos de expr pueden incluir el nombre de un
campo de una tabla, una constante o una funcin (la cual puede ser
intrnseca o definida por el usuario pero no otras de las funciones agregadas
de SQL).
SELECT Sum(PrecioUnidad * Cantidad) AS Total FROM DetallePedido;
4.7 Var, VarP
Devuelve una estimacin de la varianza de una poblacin (sobre el total de
los registros) o una muestra de la poblacin (muestra aleatoria de registros)
sobre los valores de un campo. Su sintaxis es:
Var(expr)
VarP(expr)
VarP evala una poblacin, y Var evala una muestra de la poblacin. Expr
el nombre del campo que contiene los datos que desean evaluarse o una

expresin que realiza un clculo utilizando los datos de dichos campos. Los
operandos de expr pueden incluir el nombre de un campo de una tabla, una
constante o una funcin (la cual puede ser intrnseca o definida por el usuario
pero no otras de las funciones agregadas de SQL)
Si la consulta contiene menos de dos registros, Var y VarP devuelven Null
(esto indica que la varianza no puede calcularse). Puede utilizar Var y VarP
en una expresin de consulta o en una Instruccin SQL.
SELECT Var(Gastos) AS Varianza FROM Pedidos WHERE Pais = 'Espaa';
SELECT VarP(Gastos) AS Varianza FROM Pedidos WHERE Pais = 'Espaa';
http://www.maestrosdelweb.com/editorial/tutsql4/
Clusula GROUP BY
La clusula GROUP BY especifica una consulta sumaria. En vez de producir un
fila de resultados por cada fila de datos de la base de datos, una consulta
sumaria agrupa todas las filas similares y luego produce una fila sumaria de
resultados para cada grupo.
Seguido de la clusula GROUP BY se especifican los nombres de uno o ms
campos cuyos resultados se desean agrupados. Tiene la forma:
GROUP BY expresin_columna
expresin_columna debe coincidir con la expresin de columna utilizada en la
clusula SELECT. Puede ser uno o ms nombres de campo de una tabla,
separados por coma o una o ms expresiones separadas por comas.
SELECT RUBRO_CLAVE, COUNT(*) FROM ACTIVOS WHERE TIPO = 'Compra'
GROUP BY RUBRO_CLAVE
Esta sentencia nos devolver una fila por cada area RUBRO_CLAVE, y el
numero de veces de cada uno.

Clusula HAVING

La clusula HAVING dice a SQL que incluya solo ciertos grupos producidos por
la clusula GROUP BY en los resultados de la consulta. Al igual que la clusula
WHERE, utiliza una condicin de bsqueda para especificar los grupos
deseados. En otras palabras, especifica la condicin que deben de cumplir los
grupos. Slo es vlida si previamente se ha especificado la clusula GROUP
BY. La clusula HAVING tiene la forma:
HAVING expresin1 operador expresin2
expresin1 y expresin2 pueden ser nombres de campos, valores constantes
o expresiones y estas deben coincidir con una expresin de columna en la
clusula SELECT.
operador es un operador relacional que une las dos expresiones. Ms tarde
se vern los distintos operadores que se pueden utilizar.
La sentencia siguiente nos mostrar el nmero de RUBRO_CLAVE, y el
numero de los mismos en cada RUBRO_CLAVE cuyo numero supera el 1:
SELECT RUBRO_CLAVE, COUNT(*) FROM ACTIVOS WHERE TIPO = 'Compra'
GROUP BY RUBRO_CLAVE HAVING RUBRO_CLAVE > 1
http://www.lania.mx/biblioteca/seminarios/basedatos/sql.html#cgrou
pby
4.4 Consultas sobre mltiples tablas.
4.4.1 Subconsultas.
SubConsultas
Una subconsulta es una instruccin SELECT anidada dentro de una
instruccin SELECT, SELECT...INTO, INSERT...INTO, DELETE, o UPDATE o
dentro
de
otra
subconsulta.
Puede utilizar tres formas de sintaxis para crear una subconsulta:
comparacin
[ANY
|
ALL
expresin
[NOT]
IN
[NOT] EXISTS (instruccin sql)

SOME]
(instruccin
sql)
(instruccin
sql)

En donde:
comparacin: Es una expresin y un operador de comparacin que compara
la expresin con el resultado de la subconsulta.

expresin: Es una expresin por la que se busca el conjunto resultante de la

subconsulta.
instruccin sql : Es una instruccin SELECT, que sigue el mismo formato y
reglas que cualquier otra instruccin SELECT. Debe ir entre parntesis.
Se puede utilizar una subconsulta en lugar de una expresin en la lista de
campos de una instruccin SELECT o en una clusula WHERE o HAVING. En
una subconsulta, se utiliza una instruccin SELECT para proporcionar un
conjunto de uno o ms valores especificados para evaluar en la expresin de
la clusula WHERE o HAVING.
Se puede utilizar el predicado ANY o SOME, los cuales son sinnimos, para
recuperar registros de la consulta principal, que satisfagan la comparacin
con cualquier otro registro recuperado en la subconsulta. El ejemplo siguiente
devuelve todos los productos cuyo precio unitario es mayor que el de
cualquier producto vendido con un descuento igual o mayor al 25 por ciento.:
SELECT
*
FROM
Productos
WHERE
PrecioUnidad
>
ANY
(SELECT PrecioUnidad FROM DetallePedido WHERE Descuento >= 0 .25);
El predicado ALL se utiliza para recuperar nicamente aquellos registros de
la consulta principal que satisfacen la comparacin con todos los registros
recuperados en la subconsulta. Si se cambia ANY por ALL en el ejemplo
anterior, la consulta devolver nicamente aquellos productos cuyo precio
unitario sea mayor que el de todos los productos vendidos con un descuento
igual o mayor al 25 por ciento. Esto es mucho ms restrictivo.
El predicado IN se emplea para recuperar nicamente aquellos registros de
la consulta principal para los que algunos registros de la subconsulta
contienen un valor igual. El ejemplo siguiente devuelve todos los productos
vendidos con un descuento igual o mayor al 25 por ciento.:
SELECT
*
FROM
Productos
WHERE
IDProducto
IN
(SELECT IDProducto FROM DetallePedido WHERE Descuento >= 0.25);
Inversamente se puede utilizar NOT IN para recuperar nicamente aquellos
registros de la consulta principal para los que no hay ningn registro de la
subconsulta que contenga un valor igual. El predicado EXISTS (con la
palabra reservada NOT opcional) se utiliza en comparaciones de verdad/falso
para determinar si la subconsulta devuelve algn registro.
Se puede utilizar tambin alias del nombre de la tabla en una subconsulta
para referirse a tablas listadas en la clusula FROM fuera de la subconsulta.
El ejemplo siguiente devuelve los nombres de los empleados cuyo salario es

igual o mayor que el salario medio de todos los empleados con el mismo
ttulo. A la tabla Empleados se le ha dado el alias T1::
SELECT Apellido, Nombre, Titulo, Salario FROM Empleados AS T1
WHERE
Salario
>=
(SELECT
Avg(Salario)
FROM
Empleados
WHERE T1.Titulo = Empleados.Titulo) ORDER BY Titulo;
En el ejemplo anterior , la palabra reservada AS es opcional.
SELECT
Apellidos,
Nombre,
Cargo,
Salario
FROM
Empleados
WHERE Cargo LIKE "Agente Ven*" AND Salario > ALL (SELECT Salario FROM
Empleados WHERE (Cargo LIKE "*Jefe*") OR (Cargo LIKE "*Director*"));
Obtiene una lista con el nombre, cargo y salario de todos los agentes de
ventas cuyo salario es mayor que el de todos los jefes y directores.
SELECT DISTINCTROW NombreProducto, Precio_Unidad FROM Productos
WHERE (Precio_Unidad = (SELECT Precio_Unidad FROM Productos WHERE
Nombre_Producto = "Almbar anisado");
Obtiene una lista con el nombre y el precio unitario de todos los productos
con el mismo precio que el almbar anisado.
SELECT
DISTINCTROW
Nombre_Contacto,
Nombre_Compaia,
Cargo_Contacto,
Telefono FROM Clientes WHERE (ID_Cliente IN (SELECT DISTINCTROW
ID_Cliente FROM Pedidos WHERE Fecha_Pedido >= #04/1/93# <#07/1/93#);
Obtiene una lista de las compaas y los contactos de todos los clientes que
han realizado un pedido en el segundo trimestre de 1993.
SELECT Nombre, Apellidos FROM Empleados AS E WHERE EXISTS
(SELECT * FROM Pedidos AS O WHERE O.ID_Empleado = E.ID_Empleado);
Selecciona el nombre de todos los empleados que han reservado al menos
un pedido.
SELECT
DISTINCTROW
Pedidos.Id_Producto,
Pedidos.Cantidad,
(SELECT DISTINCTROW Productos.Nombre FROM Productos WHERE
Productos.Id_Producto = Pedidos.Id_Producto) AS ElProducto FROM
Pedidos WHERE Pedidos.Cantidad > 150 ORDER BY Pedidos.Id_Producto;

Recupera el Cdigo del Producto y la Cantidad pedida de la tabla pedidos,

extrayendo el nombre del producto de la tabla de productos.
http://www.maestrosdelweb.com/editorial/tutsql7/

4.4.2 Operadores JOIN.

1. Para las siguientes relaciones

computar
1.
2.
3.
4.
5.
6.
7.
Operadores Join-Like
Existen varios operadores del estilo del join que son provistos por bases
de datos comerciales.
o El semijoin de las relaciones y
, es el multiconjunto de
tuplas tal que hay al menos una tupla en que concuerda con
en todos los atributos comunes de y .

o El antisemijoin
, es la bolsa de tuplas
en
que no
concuerdan con ninguna tupla de en los atributos
.
o El outerjoin
se forma con
ms el agregado de las
dangling tuples de o , donde una tupla est colgando si esta
no se junta con ninguna de la otra relacin. Las tuplas agregadas
se rellenan con el smbolo de indefinido o nulo
, en aquellos
atributos que la tupla colgante no posee pero que si aparecen en
la relacin resultante.
o El leftouterjoin
es como el outerjoin, pero solo las tuplas
colgantes de son rellenadas con y agregadas al resultado.
o El rightouterjoin
tambin es como el outerjoin, pero esta
vez el argumento que genera las dangling tuples es el derecho.
2. Dar expresiones para los cinco operadores definidos en el prrafo
anterior usando solamente los operadores standard del lgebra
relacional. Para las variantes ``outerjoin'' puede usar una relacin
nula
componente.
3.

que consiste de una nica tupla con

Un operador unario

es idempotente si,

en cada

. Para cada uno

de los operadores
, explique por que son idempotentes o
muestre un contraejemplo.
4. Cuando es posible empujar una seleccin en los dos argumentos de un
operador binario, es necesario decidir si hacerlo o no. Cmo afectara
la existencia de ndices en uno de los argumentos?. Considere, por
ejemplo, una expresin
, donde se tiene un ndice sobre .
5. Dar ejemplos donde se muestre que la eliminacin de duplicados no
puede ser empujada por debajo de la unin o diferencia de
multiconjuntos.
6. Los operadores similares al join del ejercicio 2 obedecen algunas reglas
comunes y otras no. Para cada caso pruebe o de un contraejemplo para
las siguientes leyes.
o
o
o
o
7. Reemplace los join naturales en las expresiones siguientes por thetajoins y proyecciones. Diga cuando los theta-join resultantes forman un
grupo asociativo y conmutativo.

1.
2.
3.
2. Dar reglas para convertir cada una de las siguientes formas de
condicin en lgebra relacional. Asuma que las condiciones se aplican a
una relacin
y no estn correlacionadas a ella. Tenga especial
cuidado para no introducir o eliminar duplicados respecto a la
definicion formal de SQL.
o
o
2.
3.
4.
5.
6.

, donde

es un atributo de

o
, donde es un atributo de
Transforme la siguiente query en un plan lgico y trate de mejorarlo
aplicando leyes algebraicas.
SELECT starName
FROM Actor1996
WHERE studioName="Paramount";
donde hay dos vistas definidas
CREATE VIEW Actor1996 AS
SELECT starName, studioName
FROM MoviesOf1996 NATURAL JOIN starsIn;
CREATE VIEW MovieOf1996 AS
SELECT *
FROM Movie
WHERE year=1996;
y los esquemas son

Movie(title,year,length,inColor,studioName,producerC#)

StarsIn(title,year,starName)

http://hal.famaf.unc.edu.ar/~bdd/Practico6/
JOIN (unir)
La sentencia JOIN, si es proveida, nombra una funcin de estimacin
selectiva join para el operador (nota que esto es un nombre de una funcin,
no un nombre de un operador). Las sentencias JOIN solamente tienen sentido
para operadores binarios que retorna valores bouleanos. La idea detrs de un
estimador selectivo join es suponer que fraccin de las filas de un par de
tablas satisfacern la condicin de la sentencia WHERE del formulario
table1.field1 OP table2.field2
para el operador corriente. Como la sentencia RESTRICT, esta ayuda al
optimizador muy sustancialmente permitiendole deducir cual de las posibles
secuencias join es probable que tome el menor trabajo.
como antes, este captulo no procurar explicar como escribir una funcin
estimadora selectiva join, pero solamente sugeriremos que tu uses uno de
los estimadores estandars si alguna es aplicable:
eqjoinsel
neqjoinsel
scalarltjoinsel
scalargtjoinsel
areajoinsel
positionjoinsel
contjoinsel

for
for
for
for
for
for
for

=
<>
< or <=
> or >=
2D area-based comparisons
2D position-based comparisons
2D containment-based comparisons

http://es.tldp.org/Postgresqles/web/navegable/todopostgresql/xoper.html
4.5 Manipulacin de la base de datos (INSERT, UPDATE, DELETE).
Consultas de Actualizacin

Las consultas de actualizacin son aquellas que no devuelven ningn

registro, son las encargadas de acciones como aadir y borrar y modificar
registros.
5.1 DELETE
Crea una consulta de eliminacin que elimina los registros de una o ms de
las tablas listadas en la clusula FROM que satisfagan la clusula WHERE.
Esta consulta elimina los registros completos, no es posible eliminar el
contenido de algn campo en concreto. Su sintaxis es:
DELETE Tabla.* FROM Tabla WHERE criterio
DELETE es especialmente til cuando se desea eliminar varios registros. En
una instruccin DELETE con mltiples tablas, debe incluir el nombre de tabla
(Tabla.*). Si especifica ms de una tabla desde la que eliminar registros,
todas deben ser tablas de muchos a uno. Si desea eliminar todos los registros
de una tabla, eliminar la propia tabla es ms eficiente que ejecutar una
consulta de borrado.
Se puede utilizar DELETE para eliminar registros de una nica tabla o desde
varios lados de una relacin uno a muchos. Las operaciones de eliminacin
en cascada en una consulta nicamente eliminan desde varios lados de una
relacin. Por ejemplo, en la relacin entre las tablas Clientes y Pedidos, la
tabla Pedidos es la parte de muchos por lo que las operaciones en cascada
solo afectaran a la tabla Pedidos. Una consulta de borrado elimina los
registros completos, no nicamente los datos en campos especficos. Si
desea eliminar valores en un campo especificado, crear una consulta de
actualizacin que cambie los valores a Null.
Una vez que se han eliminado los registros utilizando una consulta de
borrado, no puede deshacer la operacin. Si desea saber qu registros se
eliminarn, primero examine los resultados de una consulta de seleccin que
utilice el mismo criterio y despus ejecute la consulta de borrado. Mantenga
copias de seguridad de sus datos en todo momento. Si elimina los registros
equivocados podr recuperarlos desde las copias de seguridad.
DELETE * FROM Empleados WHERE Cargo = 'Vendedor';
5.2 INSERT INTO
Agrega un registro en una tabla. Se la conoce como una consulta de datos
aadidos. Esta consulta puede ser de dos tipos: Insertar un nico registro
Insertar en una tabla los registros contenidos en otra tabla.

5.2.1 Para insertar un nico Registro:

En este caso la sintaxis es la siguiente:
INSERT
INTO
Tabla
(campo1,
VALUES (valor1, valor2, ..., valorN)

campo2,

..,

campoN)

Esta consulta graba en el campo1 el valor1, en el campo2 y valor2 y as

sucesivamente. Hay que prestar especial atencin a acotar entre comillas
simples (') los valores literales (cadenas de caracteres) y las fechas indicarlas
en formato mm-dd-aa y entre caracteres de almohadillas (#).
5.2.2 Para insertar Registros de otra Tabla:
En este caso la sintaxis es:
INSERT INTO Tabla [IN base_externa] (campo1, campo2, ..., campoN)
SELECT TablaOrigen.campo1, TablaOrigen.campo2, ..., TablaOrigen.campoN
FROM TablaOrigen
En este caso se seleccionarn los campos 1,2, ..., n de la tabla origen y se
grabarn en los campos 1,2,.., n de la Tabla. La condicin SELECT puede
incluir la clusula WHERE para filtrar los registros a copiar. Si Tabla y
TablaOrigen poseen la misma estructura podemos simplificar la sintaxis a:
INSERT INTO Tabla SELECT TablaOrigen.* FROM TablaOrigen
De esta forma los campos de TablaOrigen se grabarn en Tabla, para
realizar esta operacin es necesario que todos los campos de TablaOrigen
estn contenidos con igual nombre en Tabla. Con otras palabras que Tabla
posea todos los campos de TablaOrigen (igual nombre e igual tipo).
En este tipo de consulta hay que tener especial atencin con los campos
contadores o autonumricos puesto que al insertar un valor en un campo de
este tipo se escribe el valor que contenga su campo homlogo en la tabla
origen, no incrementndose como le corresponde.
Se puede utilizar la instruccin INSERT INTO para agregar un registro nico
a una tabla, utilizando la sintaxis de la consulta de adicin de registro nico
tal y como se mostr anteriormente. En este caso, su cdigo especfica el
nombre y el valor de cada campo del registro. Debe especificar cada uno de
los campos del registro al que se le va a asignar un valor as como el valor
para dicho campo. Cuando no se especifica dicho campo, se inserta el valor
predeterminado o Null. Los registros se agregan al final de la tabla.

Tambin se puede utilizar INSERT INTO para agregar un conjunto de

registros pertenecientes a otra tabla o consulta utilizando la clusula SELECT
... FROM como se mostr anteriormente en la sintaxis de la consulta de
adicin de mltiples registros. En este caso la clusula SELECT especifica los
campos que se van a agregar en la tabla destino especificada.
La tabla destino u origen puede especificar una tabla o una consulta.
Si la tabla destino contiene una clave principal, hay que asegurarse que es
nica, y con valores no-Null ; si no es as, no se agregarn los registros. Si se
agregan registros a una tabla con un campo Contador, no se debe incluir el
campo Contador en la consulta. Se puede emplear la clusula IN para
agregar registros a una tabla en otra base de datos.
Se pueden averiguar los registros que se agregarn en la consulta
ejecutando primero una consulta de seleccin que utilice el mismo criterio de
seleccin y ver el resultado. Una consulta de adicin copia los registros de
una o ms tablas en otra. Las tablas que contienen los registros que se van a
agregar no se vern afectadas por la consulta de adicin. En lugar de agregar
registros existentes en otra tabla, se puede especificar los valores de cada
campo en un nuevo registro utilizando la clusula VALUES. Si se omite la
lista de campos, la clusula VALUES debe incluir un valor para cada campo
de la tabla, de otra forma fallar INSERT.
INSERT INTO Clientes SELECT Clientes_Viejos.* FROM Clientes_Nuevos;
INSERT
INTO
Empleados
(Nombre,
Apellido,
Cargo)
VALUES ('Luis', 'Snchez', 'Becario');
INSERT INTO Empleados SELECT Vendedores.*
WHERE Fecha_Contratacion < Now() - 30;

FROM

Vendedores

5.3 UPDATE
Crea una consulta de actualizacin que cambia los valores de los campos de
una tabla especificada basndose en un criterio especfico. Su sintaxis es:
UPDATE Tabla SET Campo1=Valor1, Campo2=Valor2, ... CampoN=ValorN
WHERE Criterio;
UPDATE es especialmente til cuando se desea cambiar un gran nmero de
registros o cuando stos se encuentran en mltiples tablas. Puede cambiar
varios campos a la vez. El ejemplo siguiente incrementa los valores
Cantidad pedidos en un 10 por ciento y los valores Transporte en un 3 por
ciento para aquellos que se hayan enviado al Reino Unido.:

UPDATE Pedidos SET Pedido = Pedidos * 1.1, Transporte = Transporte * 1.03

WHERE PaisEnvo = 'ES';
UPDATE no genera ningn resultado. Para saber qu registros se van a
cambiar, hay que examinar primero el resultado de una consulta de seleccin
que utilice el mismo criterio y despus ejecutar la consulta de actualizacin.
UPDATE Empleados SET Grado = 5 WHERE Grado = 2;
UPDATE Productos SET Precio = Precio * 1.1 WHERE Proveedor = 8 AND
Familia = 3;
Si en una consulta de actualizacin suprimimos la clusula WHERE todos los
registros de la tabla sealada sern actualizados.
UPDATE Empleados SET Salario = Salario * 1.1
http://www.maestrosdelweb.com/editorial/tutsql5/
Sentencia INSERT
La sentencia de INSERT se utiliza para aadir registros a las tablas de la base
de datos. El formato de la sentencia es:
INSERT INTO nombre_tabla [(nombre_columna, ...)] VALUES (expr, ...)
nombre_tabla puede ser nicamente el nombre de la tabla.
nombre_columna es una lista opcional de nombres de campo en los que se
insertarn valores en el mismo nmero y orden que se especificarn en la
clusula VALUES. Si no se especifica la lista de campos, los valores de expr
en la clusula VALUES deben ser tantos como campos tenga la tabla y en el
mismo orden que se definieron al crear la tabla.
expr es una lista de expresiones o valores constantes, separados por comas,
para dar valor a los distintos campos del registro que se aadir a la tabla.
Las cadenas de caracteres debern estar encerradas entre comillas .
Ejemplo para aadir un registro a una tabla:
INSERT INTO RUBROS (CLAVE, NOMBRE) VALUES 9, 'Otros');
Cada sentencia INSERT aade un nico registro a la tabla. En el ejemplo solo
se han especificado 2 campos con sus respectivos valores, el resto de

campos quedaran a nulo. Un valor nulo NULL no significa blancos o ceros sino
simplemente que el campo nunca ha tenido un valor.

Sentencia UPDATE
La sentencia UPDATE se utiliza para cambiar el contenido de los registros de
una tabla de la base de datos. Su formato es:
UPDATE nombre_tabla SET nombre_columna = expr, ...
[WHERE { condicin }]
nombre_tabla puede ser nicamente el nombre de la tabla.
nombre_columna es el nombre de columna o campo cuyo valor se desea
cambiar.
En una misma sentencia UPDATE pueden actualizarse varios campos de cada
registro de la tabla.
expr es el nuevo valor que se desea asignar al campo que le precede. La
expresin puede ser un valor constante o una subconsulta. Las cadenas de
caracteres debern estar encerradas entre comillas . Las subconsultas entre
parntesis.
La clusula WHERE sigue el mismo formato que la vista en la sentencia
SELECT y determina que registros se modificarn.
Por ejemplo, cambiar los nombres de los de la tabla RUBROS de aquellos de
aquelos cuya clave sea mayor que 2, sera:
UPDATE RUBROS SET NOMBRE = 'Nuevo' WHERE CLAVE = 9,

Sentencia DELETE
La sentencia DELETE se utiliza para borrar registros de una tabla de la base
de datos. El formato de la sentencia es:
DELETE FROM nombre_tabla [WHERE { condicin }]
nombre_tabla puede ser nicamente el nombre de la tabla.
La clusula WHERE sigue el mismo formato que la vista en la sentencia
SELECT y determina que registros se borrarn.
Cada sentencia DELETE borra los registros que cumplen la condicin
impuesta o todos si no se indica clusula WHERE.
DELETE FROM RUBROS WHERE CLAVE = 9
Con el ejemplo anterior se borraran todos los registros de la tabla rubros
cuya clave sea igual a 2.

SQL, cuenta con mdulos DDL, para la definicin de datos que nos permite
crear o modificar la estructura de las tablas.
Las instrucciones para realizar estas operaciones son:
CREATE TABLE: Nos permite crear una tabla de datos vaca.
INSERT:
Permite
almacenar
registros
en
una
tabla
creada.
UPDATE: Permite modificar datos de registros almacenados en la tabla.
DELETE: Borra un registro entero o grupo de registros
de una tabla.
CREATE INDEX: Crea un ndice que nos puede auxiliar para las consultas.
DROP
TABLE:
Permite
borrar
una
tabla.
DROP INDEX: Borra el ndice indicado.
Para ejemplificar las instrucciones anteriores consideremos el ejemplo
ALUMNO cursa
- MATERIA, que tienen los siguientes atributos:
NControl
NControl
Clave
NombreA
Clave
NombreM
Especialidad Calif
Creditos
Direccin
* Estructura de la sentencia CREATE TABLE.
CREATE

TABLE

<Nombre

de

la

tabla>
(

Atributo1:
Atributo2:
Atributo3:

tipo
tipo
tipo

de
de
de

dato
longitud
dato
longitud
dato
longitud
,

,
,
:
:

Atributon: tipo de dato longitud ,

PRIMARY KEY (Opcional) ) ;
Los campos pueden definirse como NOT NULL de manera opcional excepto
en la llave primaria para lo cual es obligatorio. Adems al definir la llave
primaria se genera automticamente un ndice con respecto al campo llave;
para definir la llave la denotamos dentro de los parntesis de PRIMARY KEY.
Ejemplo:
Crear la tabla alumno con los atributos antes descritos, tomando como
llave el numero de control.
CREATE
(
NControl
char(8)
NombreA
Especialidad
Direccin
PRIMARY KEY (NControl) );

TABLE

Alumno
NOT

NULL,
char(20),
char(3),
char(30),

Tabla Alumno:
NContr Nombre Especialid Direcci
ol
A
ad
n

Pueden existir ms de una llave primaria, esto es si se requiere, se crearn

tantos
ndices
como
llaves
primarias
se
establezcan.
Pueden existir tantos campos Not Null (No nulos) como se requieran; En si
estructurar la creacin de una tabla es siempre parecida al ejemplo anterior.
* Estructura de la sentencia INSERT
INSERT
INTO Nombre de la tabla a la que se le va a insertar el registro
VALUES (Conjunto de valores del registro ) ;
Ejemplo:

Insertar en la tabla Alumno, antes creada los datos del alumno Daniel
coln, con numero de control 95310518 de la especialidad de Ingeniera civil,
con domicilio Abasolo Norte #45.
INTO
VALUES("95310518","Daniel Coln","IC","Abasolo Norte #45") ;

INSERT
Alumno

Ntese que la insercin de los datos se realiza conforme la estructura que

se implanto en la tabla, es decir en el orden en que se creo dicha tabla. En
caso de querer omitir un dato que no sean no nulos solamente se ponen las
comillas indicando el vaco de la cadena.
* Estructura de la Sentencia CREATE INDEX
CREATE
INDEX
Nombre
que
se
le
asignara
al
ndice.
ON Nombre de la taba a la cual se le creara el ndice (Campo(s) por el cual
se creara el ndice);
Ejemplo:
Crear un ndice de la tabla Alumno por el campo Especialidad.
CREATE INDEX Indice1
ON Alumno(Especialidad);
Este ndice contendr a todos los alumnos ordenados por el campo
especialidad.
CREATE INDEX UNIQUE INDEX Indice2
ON Alumno (Especialidad);
En la creacin de este ndice utilizamos la sentencia UNIQUE, es un
indicador para permitir que se cree un ndice nico por especialidad, esta
sentencia siempre se coloca antes de CREATE INDEX. En este ejemplo se
creara un ndice que contenga un alumno por especialidad existente.
* Estructura de la sentencia UPDATE
UPDATE Nombre de la tabla en donde se modificaran los datos.
SET Valores
WHERE (Condicin);
Ejemplo:

Modificar el nmero de control del registro de Daniel Coln de la Tabla

alumno por el nmero 96310518.
UPDATE Alumno
SET NControl 96310518
WHERE NombreA=Daniel Coln;
* Estructura de la sentencia DROP TABLE
DROP TABLE Nombre de la tabla a borrar ;
Ejemplo:
Borrar la tabla Alumno creada anteriormente.
DROP TABLE Alumno;
* Estructura de la sentencia DROP INDEX
DROP INDEX Nombre del ndice a borrar;
Ejemplo:
Borrar el ndice Indice1 creado anteriormente.
DROP INDEX Indice1;
* Estructura de la sentencia DELETE
DELETE
FROM Nombre de la tabla
WHERE Condicin;
Ejemplos:
- Borrar el registro cuyo nmero de control es 95310386.
DELETE
FROM Alumno
WHERE Control=95310386;
- Borrar todos los registros de la tabla alumno.
DELETE
FROM Alumno;

En el primer ejemplo, se borrara todo el registro(todos los datos), del

alumno con nmero de control = 95310386.
En el segundo ejemplo se borraran todos los registros de la tabla alumno,
pero sin borrar la estructura de la tabla, ya que la orden Delete solo borra
registros, la sentencia Drop Table es la que borra toda la estructura de la
tabla junto con los registros de la misma.

Unidad 5. Diseo de bases de datos relacionales.

5.1 Diseo de esquemas relacionales de bases de datos.
Uno de los retos en el diseo de la base de datos es el de obtener una
estructura estable y lgica tal que:
1. El sistema de base de datos no sufra de anomalas de almacenamiento.
2. El modelo lgico pueda modificarse fcilmente para admitir nuevos
requerimientos.
Una base de datos implantada sobre un modelo bien diseado tiene
mayor esperanza de vida aun en un ambiente dinmico, que una base de
datos con un diseo pobre. En promedio, una base de datos experimenta una
reorganizacin general cada seis aos, dependiendo de lo dinmico de los
requerimientos de los usuarios. Una base de datos bien diseada tendr un
buen desempeo aunque aumente su tamao, y ser lo suficientemente
flexible para incorporar nuevos requerimientos o caractersticas adicionales.
Existen diversos riesgos en el diseo de las bases de datos relacionales
que afecten la funcionalidad de la misma, los riesgos generalmente son la
redundancia de informacin y la inconsistencia de datos.
La normalizacin es el proceso de simplificar la relacin entre los campos
de
un
registro.
Por medio de la normalizacin un conjunto de datos en un registro se
reemplaza por varios registros que son ms simples y predecibles y, por lo
tanto, ms manejables. La normalizacin se lleva a cabo por cuatro razones:

Estructurar los datos de forma que se puedan representar las

relaciones pertinentes entre los datos.
Permitir la recuperacin sencilla de los datos en respuesta a las
solicitudes de consultas y reportes.
Simplificar el mantenimiento
insertndolos y borrndolos.

de

los

datos

actualizndolos,

Reducir la necesidad de reestructurar o reorganizar los datos cuando

surjan nuevas aplicaciones.
5.1.1 Formas normales.

FORMA NORMAL
El proceso de normalizacin de bases de datos consiste en aplicar una serie de reglas a las
relaciones obtenidas tras el paso del modelo entidad-relacin al modelo relacional.
Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos.

Evitar problemas de actualizacin de los datos en las tablas.
Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relacin, aunque para que una tabla sea
considerada como una relacin tiene que cumplir con algunas restricciones:

Cada tabla debe tener su nombre nico.

No puede haber dos filas iguales. No se permiten los duplicados.
Todos los datos en una columna deben ser del mismo tipo.

Dependencia funcional

B es funcionalmente dependiente de A.
Una dependencia funcional es una conexin entre uno o ms atributos. Por ejemplo si se conoce
el valor de DNI tiene una conexin con Apellido o Nombre .
Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente
manera:
FechaDeNacimiento

Edad

De la normalizacin (lgica) a la implementacin (fsica o real) puede ser sugerible tener stas
dependencias funcionales para lograr la eficiencia en las tablas.

Propiedades de la Dependencia funcional

Existen 3 axiomas de Armstrong:

Dependencia funcional Reflexiva

Si "x" est incluido en "x" entonces x x A partir de cualquier atributo o conjunto de atributos
siempre puede deducirse l mismo. Si la direccin o el nombre de una persona estn incluidos en
el DNI, entonces con el DNI podemos determinar la direccin o su nombre.

Dependencia funcional Aumentativa

entonces
DNI

nombre

DNI,direccin

nombre,direccin

Si con el DNI se determina el nombre de una persona, entonces con el DNI ms la direccin
tambin se determina el nombre y su direccin.

Dependencia funcional transitiva

Dependencia funcional transitiva.

Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y depende
funcionalmente de X y Z de Y, pero X no depende funcionalmente de Y, se dice entonces que Z
depende transitivamente de X. Simblicamente sera:
X

Z entonces X

FechaDeNacimiento
Edad

Z
Edad

Conducir

FechaDeNacimiento

Edad

Conducir

Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad determina a Conducir,

indirectamente podemos saber a travs de FechaDeNacimiento a Conducir (En muchos pases,
una persona necesita ser mayor de cierta edad para poder conducir un automvil, por eso se
utiliza este ejemplo).

Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de datos
est en la forma normal N es decir que todas sus tablas estn en la forma normal N.

Diagrama de inclusin de todas las formas normales.

En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la
mayora de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue
Edgar F. Codd.1

Primera Forma Normal (1FN)

Una tabla est en Primera Forma Normal si:

Todos los atributos son atmicos. Un atributo es atmico si los elementos del dominio son
indivisibles, mnimos.
La tabla contiene una llave primaria nica.
La llave primaria no contiene atributos nulos.
No debe existir variacin en el nmero de columnas.
Los Campos no llave deben identificarse por la llave (Dependencia Funcional)
Debe Existir una independencia del orden tanto de las filas como de las columnas, es
decir, si los datos cambian de orden no deben cambiar sus significados
Una tabla no puede tener mltiples valores en cada columna.
Los datos son atmicos (a cada valor de X le pertenece un valor de Y y viceversa).

Esta forma normal elimina los valores repetidos dentro de una BD

Segunda Forma Normal (2FN)

Artculo principal: Segunda forma normal.

Dependencia Funcional. Una relacin est en 2FN si est en 1FN y si los atributos que no
forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no

existen dependencias parciales. (Todos los atributos que no son clave principal deben depender
nicamente de la clave principal).
En otras palabras podramos decir que la segunda forma normal est basada en el concepto de
dependencia completamente funcional. Una dependencia funcional
es completamente
funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es
que
. Una dependencia funcional
es una dependencia parcial
si hay algunos atributos
que pueden ser eliminados de X y la dependencia todava se
mantiene, esto es
.
Por ejemplo {DNI, ID_PROYECTO} HORAS_TRABAJO (con el DNI de un empleado y el
ID de un proyecto sabemos cuntas horas de trabajo por semana trabaja un empleado en dicho
proyecto) es completamente dependiente dado que ni DNI
HORAS_TRABAJO ni
ID_PROYECTO
HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI,
ID_PROYECTO}
NOMBRE_EMPLEADO es parcialmente dependiente dado que DNI
NOMBRE_EMPLEADO mantiene la dependencia.

Tercera Forma Normal (3FN)

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva
entre los atributos que no son clave.
Un ejemplo de este concepto sera que, una dependencia funcional X->Y en un esquema de
relacin R es una dependencia transitiva si hay un conjunto de atributos Z que no es un
subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.

Se dice que una forma normal particular si satisface cierto conjunto

especifico de restricciones; por ejemplo, se dice que una relacin esta en
primera forma normal si y solo si satisface la restriccin de contener
nicamente valores atmicos .

CASO PRACTICO PARA NORMALIZAR.

Un conjunto de proveedores distribuyen artculos en ciudades especificas.
Las ciudades se encuentran agrupadas por regiones, pero un proveedor solo
puede cubrir una ciudad. Cada proveedor es capaz de distribuir artculos que
estn numerados consecutivamente.

La siguiente tabla muestra la distribucin de los artculos que son

distribuidos por cada proveedor y las existencias actuales de estos.

PRIMERA FORMA NORMAL

Una relacin esta en primera forma normal si y solo si los dominios de sus
atributos solo contienen valores atmicos (no vas a dejar ningn casillero
co).

SEGUNDA FORMA NORMAL

Una relacin esta en segunda forma normal si y solo si esta en primera
forma normal y cada atributo no primo * es completamente dependiente de la
llave primaria.
*ATRIBUTO PRIMO: es aquel que forma parte de la llave primaria.

TERCERA FORMA NORMAL

Una relacin esta en tercera forma normal si y solo si esta en segunda
forma normal y todo atributo no primo es dependiente no transitivamente de
la llave primaria.
No se cumple la tercera forma normal porque hay transitividad de un
proveedor
a
regin.

Llave
(PROV,

ART)

Llave(
PROV)

Se considera que un esquema que alcanza tercera forma normal es

eficiente. No obstante, se ha propuesto una mejora que permitir obtener un
modelo ms eficiente con la ventaja de que no depende de formas normales
anteriores (aunque se recomienda ampliamente alcanzar tercera forma
normal antes de su aplicacin).
EJERCICIO
A travs del siguiente ejercicio se intenta afirmar los conocimientos de
normalizacin con un ejemplo simplificado de una base de datos para una
pequea biblioteca.

CodLibr Titulo
o

Autor

Editorial NombreLec FechaDev

tor

1001

Variable
compleja

Murray
Spiegel

McGraw
Hill

Prez
15/04/200
Gmez, Juan 5

1004

Visual

E.

Anaya

Ros

Tern, 17/04/200

CodLibr Titulo
o

Autor

Editorial NombreLec FechaDev

tor

Basic 5

Petroustsos

1005

Estadstica

Murray
Spiegel

1006

Oracle
University

Nancy
Greenberg Oracle
y
Priya Corp.
Nathan

1007

Clipper
5.01

Ramalho

McGraw
Hill

McGraw
Hill

Ana

Roca, Ren

16/04/200
5

Garca
Roque, Luis

20/04/200
5

Prez
18/04/200
Gmez, Juan 5

Esta tabla no cumple el requisito de la Primera Forma Normal (1NF) de slo

tener campos atmicos, pues el nombre del lector es un campo que puede (y
conviene) descomponerse en apellido paterno, apellido materno y nombres.
Tal como se muestra en la siguiente tabla.
1NF
CodLibr Titulo
o

Autor

Editori Patern Matern Nombr

al
o
o
es

FechaDev

McGraw
Prez
Hill

Gmez

Juan

15/04/200
5

Tern

Ana

17/04/200
5

Ren

16/04/200
5

1001

Variable Murray
compleja Spiegel

1004

Visual
Basic 5

E.
Petrousts
os

Anaya

1005

Estadsti
ca

Murray
Spiegel

McGraw
Roca
Hill

1006

Oracle
Nancy
Oracle
Universit Greenber Corp.

Ros

Garca

Roque

Luis

20/04/200
5

CodLibr Titulo
o

Editori Patern Matern Nombr

al
o
o
es

FechaDev

1006

Oracle
Priya
Universit
Nathan
y

Oracle
Corp.

1007

Clipper
5.01

McGraw
Prez
Hill

Autor

Ramalho

Garca

Roque

Luis

20/04/200
5

Gmez

Juan

18/04/200
5

Como se puede ver, hay cierta redundancia caracterstica de 1NF.

La Segunda Forma Normal (2NF) pide que no existan dependencias parciales
o dicho de otra manera, todos los atributos no clave deben depender por
completo de la clave primaria. Actualmente en nuestra tabla tenemos varias
dependencias parciales si consideramos como atributo clave el cdigo del
libro.
Por ejemplo, el ttulo es completamente identificado por el cdigo del libro,
pero el nombre del lector en realidad no tiene dependencia de este cdigo,
por tanto estos datos deben ser trasladados a otra tabla.
2NF
CodLibr Titulo
o

Autor

Editoria
l

Murray
Spiegel

McGraw
Hill

1001

Variable
compleja

1004

E.
Visual Basic 5 Petroustso Anaya
s

1005

Estadstica

Murray
Spiegel

McGraw
Hill

CodLibr Titulo
o

Autor

Editoria
l

1006

Oracle
University

Nancy
Oracle
Greenberg Corp.

1006

Oracle
University

Priya
Nathan

Oracle
Corp.

1007

Clipper 5.01

Ramalho

McGraw
Hill

La nueva tabla slo contendr datos del lector.

CodLect Patern Matern Nombre

or
o
o
s
501

Prez

Gmez

Juan

502

Ros

Tern

Ana

503

Roca

504

Garca

Ren
Roque

Luis

Hemos creado una tabla para contener los datos del lector y tambin tuvimos
que crear la columna CodLector para identificar unvocamente a cada uno.
Sin embargo, esta nueva disposicin de la base de datos necesita que exista
otra tabla para mantener la informacin de qu libros estn prestados a qu
lectores. Esta tabla se muestra a continuacin:

CodLibr CodLect FechaDev

o
or

1001

501

15/04/200
5

1004

502

17/04/200
5

503

16/04/200
5

1006

504

20/04/200
5

1007

501

18/04/200
5

1005

Para la Tercera Forma Normal (3NF) la relacin debe estar en 2NF y adems
los atributos no clave deben ser mutuamente independientes y dependientes
por completo de la clave primaria. Tambin recordemos que dijimos que esto
significa que las columnas en la tabla deben contener solamente informacin
sobre la entidad definida por la clave primaria y, por tanto, las columnas en
la tabla deben contener datos acerca de una sola cosa.
En nuestro ejemplo en 2NF, la primera tabla conserva informacin acerca del
libro, los autores y editoriales, por lo que debemos crear nuevas tablas para
satisfacer los requisitos de 3NF.
3NF

CodEditorial

Editorial

901

McGraw
Hill

902

Anaya

903

Oracle
Corp.

Aunque hemos creado nuevas tablas para que

cada una tenga slo informacin acerca de una
entidad, tambin hemos perdido la informacin
acerca de qu autor ha escrito qu libro y las
editoriales correspondientes, por lo que debemos
crear otras tablas que relacionen cada libro con
sus autores y editoriales.

CodLibr Titulo
o

1001

Variable
compleja

1004

Visual Basic 5

1005
CodLibroEstadstica
codAutor
1001
1006

Oracle
801
University

1004
1007

802
Clipper 5.01

1005

801

1006

803

1006

804

1007

806

CodLibr codEditori
o
al

Y el resto de las tablas no

1001

901

1004

902

1005

901

1006

903

1007

901

CodLect Patern Matern Nombre

or
o
o
s
501

Prez

Gmez

Juan

502

Ros

Tern

Ana

necesitan modificacin.

CodLect Patern Matern Nombre

or
o
o
s
503

Roca

CodLibr CodLect FechaDev

o
or

Ren
501

15/04/200
5

502

17/04/200
5

1005

503

16/04/200
5

Aplicar las reglas de normalizacin 1006

sgte ejercicio.

504

20/04/200
5

501

18/04/200
5

504

Garca

Roque

Luis

1001

1004

ACTIVIDAD: NORMALIZACION
DE DATOS

1. Un dato sin normalizar no cumple con

ninguna regla de normalizacin. Para
explicar con un ejemplo en qu 1007
consiste cada una de las reglas, vamos
considerar
los
datos
de
la

al

a
siguiente

tabla.

ordenes (id_orden, fecha, id_cliente, nom_cliente, estado, num_art, nom_art,

cant, precio)

Ordenes
Id_ord
Fecha
en

Id_clien
te

Nom_clie
nte

Estad
o

Num_a
rt

nom_a
rt

ca
nt

Preci
o

2301

23/02/1
1

101

Martin

Caraca
s

3786

Red

35,00

2301

23/02/1
1

101

Martin

Caraca
s

4011

Raquet
a

65,00

2301

23/02/1
1

101

Martin

Caraca
s

9132

Paq-3

4,75

2302

25/02/1
1

107

Herman

Coro

5794

Paq-6

5,00

2303

27/02/1
1

110

Pedro

Marac
ay

4011

Raquet
a

65,00

2303

27/02/1
1

110

Pedro

Marac
ay

3141

Funda

10,00

EJERCICIOS PROPUESTOS

DIAGRAMAS ENTIDAD RELACIN

Organigrama
Crear el esquema entidad/relacin que represente el organigrama de una
empresa, de modo que:

Aparezcan los datos de todos los empleados y empleadas: dni, n de

seguridad social, cdigo de trabajador, nombre, apellidos, direccin,
telfono y departamento en el que trabajan indicado por su cdigo y
nombre.
Tambin hay que tener en cuenta que cada trabajador puede tener un
responsable (que en realidad es otro trabajador)
Los departamentos poseen un nico coordinador del mismo
Necesitamos almacenar la categora profesional de los trabajadores y
trabajadoras, teniendo en cuenta que la categora a veces cambia al
cambiar el contrato, de los contratos se almacena la fecha de inicio del
mismo y la fecha final (un contrato en vigor tendr como fecha final el
valor nulo).
Tambin controlaremos las nminas que ha recibido el trabajador de las
que sabemos la fecha, el salario y a qu trabajador van dirigidas y la
categora del mismo.

Ejercicio Vuelos
Crear el esquema entidad/relacin que permita gestionar reservas de vuelos,
de modo que:

Los clientes pueden reservar vuelos. Con la reserva se pueden reservar

varias plazas, pero no poseeremos el nmero de asiento hasta obtener
la tarjeta de embarque. En ese instante se asignar el asiento que
tiene como identificacin la fila, columna y la planta en la que est
situado.
Se pueden obtener tarjetas de embarque sin tener reserva
Las tarjetas de embarque se refieren a un nico cliente. De modo que
aunque reservramos nueve plazas, cada cliente podr sacar su tarjeta
de embarque indicando el nmero de reserva, la fecha de la misma y
sus datos personales (dni, nombre, apellidos, direccin y telfono).
Adems la persona que reserva debe indicar una tarjeta de crdito que
quedar asociada a esa persona.
El vuelo que se reserva tiene un cdigo nico, una fecha y una hora de
salida y de llegada y un aeropuerto de salida y otro de llegada
Los aeropuertos poseen un cdigo nico, adems del nombre y la
localidad y el pas en el que se encuentran

Se guarda informacin sobre los aviones, cdigo y nmero de plazas.

Los vuelos slo les puede realizar un avin determinado, pero el mismo
avin puede realizar (como es lgico) otros vuelos

Ejercicio Recetas de cocina

Crear el esquema entidad/relacin que permita gestionar los datos sobre
preparacin de rectas de cocina

Ejercicio Futbol
Crear el esquema entidad/relacin que permita crear el diseo de una base
de datos que almacena informacin sobre los partidos de una liga de futbol
una temporada. Hay que tener en cuenta que en dicha liga los jugadores no
pueden cambiar de equipo

Ejercicio Accidentes geogrficos

Realizar un esquema entidad/relacin que sirva para almacenar informacin
geogrfica. Para ello hay que tener en cuenta
o
o
o
o
o

Se almacenan los siguientes accidentes geogrficos: ros, lagos y

montaas
De cada accidente se almacenan su posicin horizontal y vertical
segn el eje de la tierra, adems de su nombre
De los ros se almacena su longitud, de las montaas su altura y
de los lagos su extensin
Se almacena tambin informacin sobre cada pas, su nombre, su
extensin y su poblacin
Se desea almacenar informacin que permite saber en qu pas
est cada accidente geogrfico, teniendo en cuenta que cada
accidente puede estar en ms de un pas.
Se almacena tambin los nombres de cada localidad del planeta.
Y se almacena por qu localidades pasa cada ro.

Ejercicio: Empresa de software

Realizar un esquema entidad/relacin que permita modelar el sistema de
informacin de una empresa de software atendiendo las siguientes premisas

La empresa crea proyectos para otras empresas. De dichas empresas

se almacena el CIF, nombre, direccin y telfono as como un cdigo
interno de empresa.
Los proyectos se inician en una determinada fecha y finalizan en otra.
Adems al planificarle se almacena la fecha prevista de finalizacin
(que puede no coincidir con la finalizacin real)
Los proyectos los realizan varios trabajadores, cada uno de ellos
desempea una determinada profesin en el proyecto (analista, jefe de
proyecto, programador,), dicha profesin tiene un cdigo de
profesin. En el mismo proyecto puede haber varios analistas,
programadores,
Todos los trabajadores tienen un cdigo de trabajador, un dni, un
nombre y apellidos. Su profesin puede cambiar segn el proyecto: en
uno puede ser jefe y en otro un programador
Se anota las horas que ha trabajado cada trabajador en cada proyecto.
Puede haber varios proyectos que comiencen el mismo da.
A todas las empresas les hemos realizado al menos un proyecto
Todos los trabajadores han participado en algn proyecto
En la base de datos, la profesin administrador de diseo no la ha
desempeado todava ningn trabajador o trabajadora

Ejercicio Empresa de comidas

Crear un diseo entidad/relacin para una empresa de comidas. En la base
de datos tienen que figurar:

El nombre y apellidos de cada empleado, su dni y su nmero de SS

adems del telfono fijo y el mvil
Algunos empleados/as son cocineros/as. De los cocineros y cocineras
anotamos (adems de los datos propios de cada empleado) sus aos
de servicio en la empresa.
Hay empleados/as que son pinches. De los y las pinches anotamos su
fecha de nacimiento.
La mayora de trabajadores no son ni pinches ni cocineros/as
En la base de datos figura cada plato (su nombre como pollo a la
carlotea, bacalo al pil-pil,), el precio del plato junto con los
ingredientes que lleva. Anotamos tambin si cada plato es un entrante,
un primer plato, segundo plato o postre

De los ingredientes necesitamos la cantidad que necesitamos de l en

cada plato y en qu almacn y estantera del mismo le tenemos.
Cada almacn se tiene un nombre (despensa principal, cmara
frigorfica A, cmara frigorfica B), un nmero de almacn y una
descripcin del mismo.
Cada estante en el almacn se identifica con dos letras y un tamao en
centmetros. Dos almacenes distintos pueden tener dos estantes con
las mismas letras.
Necesitamos tambin saber qu cocineros son capaces de preparar
cada plato.
Cada pinche est a cargo de un cocinero o cocinera.
La cantidad de ingredientes en cada estantera de un almacn se
actualiza en la base de datos al instante. SI cogemos dos ajos de un
estante, figurar al instante que tenemos dos ajos menos en ese
estante. Es necesario por lo tanto saber los ingredientes (cules y en
qu nmero) que tenemos en cada estante.

Ejercicio Red social

Crear un diseo entidad/relacin que permita modelar un sistema que sirva
para simular el funcionamiento de una red social, teniendo en cuenta lo
siguiente:

Los usuarios de la red social se identifican con un identificador y una

contrasea. Adems se almacena de ellos:
o Su nombre, apellidos, direccin, telfono (puede tener varios
telfonos) e e-mail (el e-mail no tiene que poder coincidir con el
de otro usuario) y una foto
o Si los usuarios son celebridades, de ellos no aparecer ni el email
ni la direccin ni el telfono.
Los usuarios pueden tener una serie de contactos, que en realidad son
otros usuarios. De cada contacto se puede almacenar un comentario
que es personal y que sirve para describir al contacto.
Los usuarios pueden organizar sus contactos en grupos de los cuales se
almacena un nombre y deberemos saber los contactos que contiene. El
mismo contacto puede formar parte de varios grupos.
Adems cada usuario puede tener una lista de usuarios bloqueados a
fin de que no puedan contactar con l
Los usuarios pueden publicar en la red comentarios, los cuales se
puede hacer que los vea todo el mundo, que los vea uno o varios de los
grupos de contactos del usuario o bien una lista concreta de usuarios.
Los comentarios pueden incluir un texto y una imagen.

Ejercicio:Men diario
Crear un esquema Entidad/relacin que represente un modelo para llevar los
datos que maneja un restaurante de mens diarios. Teniendo en cuenta que:

Slo interesa llevar los datos de los mens diarios a la hora de la

comida, nada ms del restaurante
Cada mens se compone de una serie de posibles platos. cada plato se
puede repetir en diferentes das. Los platos pueden ser primer plato,
segundo plato o postres.
De cada plato se almacena el nombre (por ejemplo Arroz negro con
setas) y una pequea descripcin.
De los mens almacenamos la fecha en la que se ofrece el men, el
nmero de personas que han tomado men ese da. Adems
almacenamos la cantidad de cada plato que se ha tomado ese da.
Se almacena tambin la temperatura que haca el da del men para
as poder analizar las temperaturas y los platos exitosos

Ejercicio Twitter
Crear un esquema Entidad/relacin que represente un modelo para llevar los
datos que maneja la red social Twitter: usuarios, mensajes,...

Ejercicio Horario escolar

Crear un esquema Entidad/relacin que represente el funcionamiento de un
centro escolar de formacin profesional, teniendo en cuenta que:

Slo interesa llevar el control de ocupacin de las aulas en el horario

escolar
El horario es de seis horas diarias y en la base de datos simplemente
se anota si es la primera, segunda, y el da de la semana del que
hablamos (por ejemplo mircoles a tercera hora)
Las asignaturas tienen un nombre, un cdigo interno del centro y un
cdigo europeo. La misma asignatura se puede impartir en dos ciclos
distintos y en ese caso tendra el mismo cdigo europeo y nombre,
pero el cdigo interno sera distinto. Hace falta saber en qu curso del
ciclo se imparte la asignatura
Los ciclos tienen un nombre, pueden ser de grado superior,de grado
medio o de iniciacin profesional; adems tienen otro cdigo interno en
el centro.
Las asignaturas en cada momento ocupan un aula, del que tenemos
que almacenar un cdigo de aula, un nombre (que no se repite), un

nmero de aula (que tampoco se repite) y los metros que tiene. A una
hora concreta de la semana, el aula puede estar vacia o bien ocuparse,
pero slo se puede ocupar por una asignatura
Necesitamos saber y anotar en la base de datos si una asignatura
requiere que antes se hayan aprobado otras, para poder matricularse
en ella. Por ejemplo, Ampliacin de Matemticas de 2 a lo mejor
requiere aprobar Matemticas de 1. Puede requerirse terminar ms
de una asignatura previamente para poder matricularse de una
concreta.
Se entiende que la asignatura slo la puede impartir un profesor en
todo el ao, siempre ser uno en todo momento el titular
De los profesores se almacena su nombre, direccin, telfono, email,
DNI, n de Seguridad Social y un cdigo interno de profesor as como
los aos que tiene de antigedad impartiendo cada asignatura. Puede
ser cada profesora o profesor, tutora de un curso y tambin se anota la
antigedad que tiene en esa tarea

Complicamos el esquema anterior en este sentido

Siendo ms realistas, nos damos cuenta de que en un curso escolar,

puede haber varios profesores responsables de una asignatura (por
bajas, ceses, etc.); por lo que anotamos cundo empez a impartir
dicho profesor la asignatura y cuando termin (si no ha terminado, se
dejara vaco)
Asegurar que podemos averiguar gracias al diseo, que si buscamos a
un profesor un da concreto (por ejemplo el 13 de Mayo de 2012) a una
hora concreta (sexta hora), podramos saber en qu aula va a estar.

Ejercicio Inmuebles
Crear un diseo entidad/relacin que permita modelar un sistema que sirva
para gestionar una empresa que posee inmuebles. Para ello

Se almacenan los clientes usando su DNI, Telfono fijo, Mvil, Nombre y

Apellidos.
Se almacenan los trabajadores y se almacenan los mismos datos.
Ocurre adems que un trabajador puede ser un cliente (porque puede
alquilar o comprar mediante la inmobiliaria) a veces.
A cada cliente y trabajador se le asigna un cdigo personal
Los clientes pueden comprar pisos, locales o garajes. En los tres casos
se almacena un cdigo de inmueble (nico para cada inmueble), los
metros que tienen, una descripcin y su direccin.
Los pisos tienen un cdigo especial de piso que es distinto para cada
piso.
En los locales se indica el uso que puede tener y si tienen servicio o no.

De los garajes se almacena el nmero de garaje (podra repetirse en

distintos edificios) y la planta en que se encuentra (para el caso de
garajes que estn en varias plantas). Los garajes adems pueden
asociarse a un piso y as cuando se alquile el piso se incluir el garaje.
La empresa prev que podra haber inmuebles que podran no ser ni
locales, ni garajes, ni pisos
Los inmuebles se pueden comprar. Incluso varias veces. Se asigna un
cdigo de compra cada vez que se haga, la fecha y el valor de la
compra. La compra puede tener varios titulares.
Cada inmueble se puede alquilar y en ese caso se asigna un nmero de
alquiler por cada inmueble. Ese nmero se puede repetir en distintos
inmuebles (es decir puede haber alquiler n 18 para el inmueble 40 y el
35). Pero no se repite para el mismo inmueble.
Al alquilar queremos saber el nombre del agente de la empresa que
gestion el alquiler as como a qu persona (solo una) estamos
alquilando el inmueble.
Cada pago de cada alquiler ser almacenado en la base de datos,
llevando el ao, el mes y el valor del mismo.

EJERCICIO PROPUESTO # 2: NORMALIZACION

Digamos que queremos crear una tabla con la informacin de usuarios, y los
datos a guardar son el nombre, la empresa, la direccin de la empresa y
algun e-mail, o bien URL si las tienen. En principio comenzarias definiendo la
estructura de una tabla como esta:
Formalizacin CERO
usuarios
nombre

empresa

direccion_empresa

url1

url2

Joe

ABC

1 Work Lane

abc.com

xyz.com

Jill

XYZ

1 Job Street

abc.com

xyz.com

EJERCICIO PROPUESTO # 3. DETERMINAR LA RELACION DE

CARDINALIDAD DE LOS SIGUIENTES EJERCICIOS.
a) Muchos pases del mundo adoptan como oficial un idioma en particular, otros
pases tienen varios idiomas oficiales y existen algunos casos de pases que no
cuentan con un idioma oficial. Por otro lado existen idiomas que aun cuando se

emplean en diferentes pases, no son el idioma oficial en ninguno de ellos y otros

que son oficiales en varias naciones.

b) En un liceo se dictan diferentes materias y esas materias son impartidas por

diferentes profesores, un profesor puede impartir una o varias materias, incluso
algunos profesores no dictan ninguna materia ya que realizan labores de
coordinacin. Por su parte las materias son impartidas por uno o varios profesores

c) Los productos que vende una tienda de computacin son hechos por distintas
marcas, cada producto puede ser fabricado por una o varios marcas y cada marca
puede producir uno o varios productos. La cardinalidad mxima en esta relacin es
de Muchos a Muchos (M:N) y la mnima es de Uno a Uno (1:1), con este ejemplo
se completan las posibles cardinalidades que puede presentar una relacin entre
entidades.
EJERCICIOS PROPUESTOS # 4: DISEO EN ACCESS
Pasa el modelo entidad-relacin de los ejercicios del modelo relacional.
Disea las tablas en Access, realiza las relaciones que consideres
oportunas e inserta cinco registros en cada una de las tablas.