Programacion de 'Bases de Datos1

BASES DE DATOS
MODELADOS Y ANALISIS DE
DATOS
PARTE I
FUNDAMENTOS DE BASES
DE DATOS
Objetivos
■ Usar en forma detallada las técnicas

para diseño e implantación de bases de
datos relacionales, para que sirvan de
cimiento para el desarrollo de sistemas
de información.
■ Desarrollar un proyecto de ingeniería
referente a un sistema de información.
UNIDAD 1. INTRODUCCIÓN
■ Un sistema de manejo de Bases de

Datos DBMS, es un conjunto de datos
relacionados entre sí y un grupo de
programas para tener acceso a esos
datos.
DATOS PROGRAMAS
UNIDAD 1. INTRODUCCIÓN
■ El objetivo del DBMS es crear un ambiente

en el que sea posible guardar y recuperar
información de la base de datos, de forma
eficiente.
■ Incluye:
- Definición de estructuras de
almacenamiento de datos
- Mecanismos para manejo de datos
- Seguridad de la información
- Uso concurrente de la base de datos
1. Propósito de los sistemas de
bases de datos
■ Los DBMS minimizan los problemas de los

sistemas de procesamiento de archivos:
- Redundancia e inconsistencia de datos
- Dificultad en el acceso a los datos
- Aislamiento de datos
- Problemas de integridad
- Problemas de atomicidad
- Anomalías en el acceso concurrente
- Problemas de seguridad
2. Visión de los datos
■ Los DBMS proporcionan a los usuarios una

visión abstracta de los datos.
■ El sistema esconde ciertos detalles de
cómo se almacenan y mantienen los datos.
■ Las bases de datos revolucionaron el
mundo de las computadoras, con este
nuevo concepto “abstracción de los datos”,
a diferencia de lo que era tradicional
“abstracción de lenguajes de
programación”.
2.1. Abstracción de los datos
■ Para ocultar esta complejidad del

almacenamiento se definen 3 niveles:
■ Nivel físico.- Describe como se
almacenan realmente los datos en forma
de palabras y bytes.
■ Nivel conceptual.- Describe qué datos se
almacenan y qué relaciones hay entre
ellos, en forma de estructuras.
■ Nivel de visión.- Muchos usuarios
necesitan acceder a una parte de la base
de datos. El sistema proporciona vistas.
2.2. Ejemplares y esquemas
■ La colección de la información almacenada

en la base de datos en un momento
particular se llama un ejemplar de la base
de datos.
■ El esquema de la base de datos es una
descripción de la misma en forma de
estructuras de datos.
Existen tres tipos de esquema: físico,
lógico y subesquemas.
2.3. Independencia de datos
■ Es la capacidad de modificar una definición

de esquema en un nivel sin que afecte al
nivel superior.
■ Independencia física de datos.- Es la
capacidad de modificar el esquema físico
sin tener que modificar los programas.
■ Independencia lógica de datos.- Es la
capacidad de modificar el esquema lógico
sin tener que modificar los programas.
■ La independencia lógica es más difícil de
lograr que la independencia física.
3. Modelos de datos
■ Para describir el esquema de una base de

datos en cualquiera de los 3 niveles, es
necesario definir los modelos de datos.
■ Un modelo de datos es un grupo de
herramientas para describir los datos, sus
relaciones, su semántica y sus ligaduras
de consistencia.
■ Se pueden agrupar en 3 tipos de modelos:
- Modelos lógicos basados en objetos
- Modelos lógicos basados en registros
- Modelos físicos de datos
3.1 Modelos lógicos basados en
objetos
■ Parten de mundo real delimitando el

entorno del sistema y dentro de este
entorno identifican los objetos de interés.
■ Se utilizan para describir los datos en los
niveles lógico y de visión, y especifican
claramente las ligaduras de consistencia
de los datos.
■ Como ejemplos de este grupo están el
modelo entidad-relación y el modelo
orientado a objetos.
3.1.1. Modelo entidad-relación
■ Se basa en la percepción de un mundo

real que consiste en un conjunto de
objetos básicos llamados entidades, y de
las relaciones entre estos objetos.
ci
modelo
conductor
nombre domicilio año kilometraje fecha importe
persona posee automóvil ocurrió accidente

3.1.2. Modelo orientado a objetos
■ Está basado en una colección de objetos agrupados

en clases.
■ Una clase describe un conjunto de objetos que
comparten los mismos atributos, operaciones,
relaciones y semántica.
Valor
valorActual()
historia()
CuentaCorriente Acción Bono Propiedad

tasaIeInterés tasación
ValorActual() valorActual() valorActual() valorActual()
3.2 Modelos lógicos basados en
registros
■ Se usan para describir los datos en los

niveles lógico y de visión.
■ Se usan tanto para especificar la
estructura lógica completa de la base de
datos como para una descripción de alto
nivel.
■ A diferencia de los modelos basados en
registros, no describen muy bien las
ligaduras de consistencia de la base de
datos.
3.2.1. Modelo relacional
■ Los datos y las relaciones entre ellos se

representa por medio de una serie de tablas,
donde cada una tiene varias columnas.
Artículos Movimientos
nro_artí nombre nro_artí tipo cant pre_unit
5 Escobas 10 1 10 10
10 Sardina 10 2 20 10
25 Café 10 1 5 10
35 Pasas 10 1 2 10
25 1 1 20
25 2 2 20
25 1 2 5
35 1 10 5
3.2.2. Modelo de red
■ Se representa por un conjunto de registros y

las relaciones entre ellos por punteros
10 1 10 10
5 Escobas
10 2 20 10
10 Sardinas 10 1 5 10
25 1 1 20
25 Café
25 2 2 20
35 Pasas
35 1 10 5
3.2.3. Modelo jerárquico
■ Igual que el de red pero en forma de árbol
5 Escobas 25 Café
10 Sardinas 35 Pasas
10 1 10 10 10 1 5 10 25 2 2 20
10 2 20 10 25 1 1 20 35 1 10 5
3.3 Modelo de datos físico
■ El modelo de datos físico se usa para

describir datos en un nivel más bajo.
■ Dos de los más conocidos son el modelo de
unificación y el modelo de memoria de
marcos.
■ Este tipo de modelos no serán tema de
estudio.
9. Estructura del sistema completo
Usuarios Programadores Usuarios Administrador Usuarios
Normales de aplicación sofisticados de base de datos
Interfaces de Programas consulta Esquema de

aplicaciones de aplicación base de datos
Precompilador Compilador Intérprete de

del DML del DML DDL Procesador
Código objeto de
de los Motor de evaluación consultas
programas de consultas
Gestor de Gestor de Gestor de

transac- memoria Gestor de almacena-
ciones intermedia archivos
miento
DBMS Índices Datos estadísticos Almacena-

miento en
Archivo de datos Diccionario de datos disco
4. Lenguajes de bases de datos
■ Lenguaje de definición de datos DDL, es

una serie de definiciones que especifican el
esquema de la base de datos
■ Lenguaje de manejo de datos DML, permite
manipular la base de datos, utilizando las
operaciones de recuperar, insertar,
actualizar y borrar. Hay 2 tipos:
- DML procedimental, se especifica qué
datos se necesitan y cómo obtenerlos.
- DML no procedimentales, solo se indica
qué datos se necesitan, no cómo obtenerlos.
5. Gestión de transacciones
■ Una transacción es una colección de

operaciones que se llevan a cabo en una
aplicación de bases de datos. Debe ser
atómica, consistente y permitir durabilidad.
TRANSACCIÓN.-
!Me hacés Transferencia de fondos: !!!Y no te
todo INICIA equivoqués!
o nada! RETIRA DE CUENTA A
DEPOSITA A CUENTA B
FIN
5. Gestión de transacciones
■ El gestor de transacciones asegura las

propiedades de atomicidad, consistencia y
durabilidad de las transacciones.
■ Atomicidad.- Se hacen todas las
operaciones o ninguna.
■ Consistencia.- Si la base de datos es
consistente cuando comienza debe serlo
también cuando termine.
■ Durabilidad.- Los datos modificados por la
transacción en la base de datos deben
persistir.
6. Gestión de almacenamiento
■ El gestor de almacenamiento es un
módulo de programas que proporciona la
interfaz entre los datos de bajo nivel en la
base de datos, y los programas de
aplicación y consultas.
■ Es responsable de la interacción con el
gestor de archivos, y del almacenamiento,
recuperación y actualización de la base.
7. Administración de la base de
datos
■ El DBMS tiene control centralizado sobre
datos y programas.
■ La persona que tiene este control sobre el
sistema es el administrador de base de
datos o DBA en inglés. Se ocupa de:
- Definir el esquema
- Estructura de almacenamiento y accesos
- Modificación de la organización física
- Autorización para el acceso a los datos
- Especificación de ligaduras de integridad
8. Usuarios de la base de datos
■ Hay 4 tipos de usuarios en un sistema de

base de datos, dependiendo de la forma
como interactuan con el sistema.
→ Programadores de aplicación, quienes
usan un lenguaje anfitrión que permite
anidar consultas DML
→ Usuarios sofisticados, usan lenguaje DML
→ Usuarios especializados, usan inteligen-
cia artificial, sistemas de expertos, etc.
→ Usuarios normales, usan programas que
se han escrito previamente.
UNIDAD 2.
MODELO ENTIDAD RELACIÓN
Objetivo
Usar las técnicas existentes para modelar bases de
datos de gran tamaño y complejas.
1. Conceptos básicos
■ Entidad.- Es una cosa que puede ser

objeto o concepto que el caso de
estudio considera que tiene existencia
independiente.
■ Atributo.- Es una propiedad de la
entidad.
■ Relación.- Es una asociación entre
entidades.
■ Entidades, relaciones y ocurrencias.

agencia almacena producto
a1 La Paz pr2 printer
pr7 tape drive
a5 Santa Cruz pr4 disk drive
pr8 controler
pr6 ploter
Entidades.- agencia, producto

Relaciones.- almacena
Ocurrencia de entidad.- 2 agencia, 5 producto
Ocurrencia de relación.- 7 de almacena
■ Identificador de entidad.- Es un atributo

o atributo compuesto, cuyos valores
identifican una ocurrencia de una
entidad, puede haber varios
“identificadores candidatos”.
■ Identificador de relación.- Es la unión
de los identificadores de las entidades
que participan en la relación.
2. Propiedades de las
relaciones
cardinalidad y participación
■ Cardinalidad o grado de una relación.-
Determina la cantidad de ocurrencias
de las entidades que participan en la
relación
■ Para relaciones binarias hay tres
posibles clases de cardinalidad
relaciones
■ Cardinalidad 1:1
1 1
profesor enseña cursor
Rosario IF-317
Angel MAT-101
Corrado QMC-100
Ramona FIS-300
relaciones
■ Cardinalidad 1:m
1 m
Rosario IF-317
Angel MAT-101
Corrado QMC-100
Ramona FIS-300
relaciones
■ Cardinalidad m:m
m n
Rosario IF-317
Angel MAT-101
Corrado QMC-100
Ramona FIS-300
relaciones
■ Participación.- Hay dos formas en que
una entidad puede participar en una
relación:
■ Obligatoria.- Cada ocurrencia de la
entidad participa en la relación, o sea
que tiene al menos una ocurrencia
asociada en la otra entidad
■ No obligatoria.- Una ocurrencia puede
existir independientemente.
relaciones
departamento emplea empleado
Un departamento debe emplear al menos un empleado

Un empleado debe ser empleado por un departamento
Un departamento no necesita emplear ningun empleado

Un empleado no necesita ser empleado por ningún depto.
relaciones
Un departamento no necesita emplear ningún empleado

Un empleado debe ser empleado por un departamento
Un departamento debe emplear al menos un empleado

Un empleado no necesita ser empleado por ningún depto.
3. Trampas de conexión y
relaciones ternarias
■ Trampa de abanico.- Existe cuando
dos o más relaciones salen de una
entidad. 1 1
división
tiene emplea
m m
depto empleado
Me sacás el departamento donde trabaja el empleado e1?

■ Trampa de abanico.-
!! Oh mi Dios, no puedo... !!
depto tiene división emplea empleado
de1 e1
di1 e2
de2
1 m 1 m
división tiene depto emplea empleado
■ Trampa de grieta.- Ocurre cuando una
relación descubierta no existe en el
diagrama.
1 m 1 m
Hola?. Quién habla?.

El sereno.
En que te puedo servir?.
Mi contrato no está en la base de datos.
■ Trampa de grieta.-
No tengo departamento “vigilancia”, y no
me permiten crearlo...
1 1 m
1 m
trabaja
■ Relaciones ternarias.- Otras trampas de
conexión no pueden resolverse aumentando
una relación binaria, la única forma es utilizar
relaciones ternarias.
parte n m n m proyecto
provee proveedor entrega
Hola, quien habla?

La contadora, no sabemos que materiales se han
usado en el proyecto del puente.
A ver....., “que partes utilizan que proyectos?”.
■ Relaciones ternarias.-
parte n m n m proyecto
provee proveedor entrega
utiliza
Y ahora quien será. Hola, quien habla?

El encargado de compras, aquí hay un transpor-
tista que dice que entregó ripio al proyecto del
puente, y no está en la base de datos.
..“que proveedor entrega que parte a que proyecto?”.
■ Relaciones ternarias.-
proveedor m
n contrata
n
m p
parte entrega proyecto
parte4 proy9
parte3 proy8
proveedor6 proveedor7
4. Características del modelo
ER extendido
■ El modelo ER extendido incluye los
conceptos de especialización y
categorización.
■ Subclases y superclases.- En muchos
casos es necesario representar una
entidad como varias entidades. Por
ejemplo, empleado como secretaria y
administrador, empleado representa la
superclase y las otras son subclases.
ER extendido
■ Especialización.- Es el proceso de definición
de un set de subclases de una entidad,
denominada superclase
empleado
d d
secretaria técnico administrador asalariado horario
1 Admi-
nistra proyecto
velocidad_tipeo 1
ER extendido
■ Especialización.- Hay dos motivos para
generar especializaciones:
1 La primera es que ciertos atributos son
aplicables solo a algunas ocurrencias de la
entidad. Por ejemplo, secretaria tiene el
atributo velocidad tipeo.
2 La segunda es que algunas relaciones
participan con las subclases diréctamente y
no con la superclase. Por ejemplo, la entidad
proyecto participa con administrador y no
necesariamente con empleado
ER extendido
■ Especialización.- Hay dos tipos de
especialización:
1 Disjunta. Las ocurrencias de la superclase
pertenecen a una o ninguna subclase.
empleado
secretaria técnico
ER extendido
■ Especialización.- Hay dos tipos de
especialización:
2 Sobrepuesta.- Las ocurrencias de la
superclase pueden pertenecer a varias
subclases. parte
parte_comprada parte_manufacturada
ER extendido
■ Especialización.- La especialización puede
ser parcial o total:
1 Total.- Todas las ocurrencias de la
superclase están representadas en la
subclase.
2 Parcial.- No es obligatorio que las
ocurrencias de la superclase estén
representadas en alguna subclase.
ER extendido
■ Categorización.- En algunos casos hay dos o
más entidades que no tienen nada en
común, que se relacionan con otra entidad,
en este caso es posible representarlas en
una categoria.
persona banco compañia
dueño
1 tiene
m vehículo
5. Esqueleto del modelo ER
reglas de representación
■ Esqueleto del ER.- Es el diagrama

ER, sus restricciones, y una lista de
tablas con sus identificadores.
■ Modelo ER.- Es el diagrama ER, sus
restricciones, y una descripción
completa de las tablas y sus
identificadores.
■ 1-1. Participación obligatoria de ambas
1 * 1 * auto
empleado usa
empleado(nro_emple, ....., nro_auto, .....)
Mario 317-SJH
Enrique 101-PLU
Gino 100-WRA
Chichi 300-LPQ
■ 1-1. Participación obligatoria de una entidad
1 * 1
empleado usa auto
empleado(nro_emple, .......)
auto (nro_auto, ......., nro_emple)
Mario 317-SJH
Enrique 101-PLU
Gino 100-WRA
Chichi
■ 1-1. Participación no obligatoria en ambas
1 1
empleado usa auto
empleado (nro_emple, .......)

auto (nro_auto, .......)
usa (nro_auto, nro_emple, .........)
Mario 317-SJH
Enrique 101-PLU
Gino 100-WRA
Chichi 300-LPQ
■ 1-m. Participación obligatoria de entidad m.
1 * m
sala ocupa paciente
sala (nro_sala, .......)

paciente (nro_paciente, ......., nro_sala)
sala-1 Dante
sala-7 Diodato
sala-8 Oso
sala-4 Techo e paja
■ 1-m. Participación no obligatoria de entidad m.
1 m
sala ocupa paciente
sala (nro_sala, .......)

paciente (nro_paciente, .......)
ocupa (nro_paciente, nro_sala, ........)
sala-1 Dante
sala-7 Diodato
Oso
Techo e paja
■ m-n. Muchos a muchos todos los casos.
m n
profesor enseña alumno
profesor (nro_profe, .......)

alumno (nro_alumno, .......)
enseña (nro_profe, nro_alumno, .........)
Corrado Jesús
Chichi María
Gustavo José
Mario Isabel
■ Especialización.- Hay 4 formas de mapeo:
1.- todos los casos
empleado
empleado (ci, nombre,...)
tipo secretaria (ci, vel_tipeo, ...)
Participa- técnico (ci, univ, .....)
ción
2.- Disjunto y participación total
secretaria técnico secretaria (ci, vel_tipeo,nombre..)
técnico (ci, universidad,nombre..)
3.- Pocos atributos en subclases y disjunto.
empleado (ci, nombre, vel_tipeo,universidad,t,...)
4. Pocos atributos en subclases y sobrepuesto
empleado (ci, nombre, vel_tipeo,universidad,t1,t2,...)
■ Categorización.- Forma de mapeo:
persona banco compañia
dueño
persona (ci, nombre,...)

banco (banco#, banco_dirección,...)
compañía (compañía#, compañía_dirección, ...)
dueño (dueño#, .....)
6. Entidades débiles
■ Entidad débil o identificador prepuesto.-

Cuando el identificador de la tabla, contiene el
identificador de otra tabla.
1 * m departamento
compañia tiene
compañia (nro_depto, .......)

departamento (nro_compañía, nro_depto, .......)
7. Relaciones recursivas
■ Las reglas de representación de relaciones

es la misma, pero es necesario distinguir
entre los diferentes roles que tienen los
identificadores
■ Relación 1:1
persona
1 1
esposo
a
espos
casado
persona (persona_id, ........)

casado (persona_id_esposo, persona_id_esposa, ......)
■ Relación 1:m
empleado
1 m
supervisado
supervisor
*
supervisa
Empleado (nro_empleado, ......., nro_emple_supervisor)

■ Relación m:n
parte
m n
parte_mayor
parte_menor
compone
Parte (nro_parte, .......)

compone (nro_parte_mayor, nro_parte_menor, .........)
8. Asignación de atributos
■ El próximo paso después de hacer el

esqueleto del modelo es asignar atributos.
■ Debemos asignar atributos a las tablas de
tal forma que queden normalizadas, hasta la
cuarta forma normal incluyendo la forma
normal de Boyce Cood.
■ 1:1 no obligatorio en ambas entidades.

nom_emple marca km_auto
km_emple km_actual
empleado (nro_emple, nom_emple, km_emple )

auto (nro_auto, marca, km_auto )
usa (nro_emple, nro_auto, km_actual )
■ 1:m no obligatorio en entidad m.

fecha_admisión nom_paciente fecha_nacim
número_camas tipo_sala
sala (nro_sala, tipo_sala, número_camas )

paciente (nro_paciente, nom_paciente, fecha_nacim )
ocupa (nro_paciente, nro_sala, fecha_admisión )
■ m:n en todos los casos.

horas_atención nom_alumno horas_alu_sem
horas_prof_sem nro_aula
profesor (nro_prof, nro_aula, horas_prof_sem )

alumno (nro_alum, nom_alumno, horas_alu_sem )
supervisa (nro_prof, nro_alum, horas_atención )
9. Metodología de diseño
conceptual y lógico
1.- Identificar los objetos del sistema que
están dentro del contexto y son de interés.
2.- Prepara una lista preliminar de eventos o
transacciones, que el sistema soportará.
3.- Preparar una lista preliminar de atributos.
4.- Hacer una lista de entidades importantes
2 a 4, con sus identificadores.
5.- Dibujar el diagrama ER partiendo de las
entidades más importantes, no es
necesario más que 2 a 4 entidades.
6.- Verificar si el diagrama ER soporta los
eventos, corregir el diagrama si es
necesario. Analizar trampas de conexión.
7.- Hacer el esqueleto del modelo a partir del
diagrama ER.
8.- Asignar atributos a las tablas, borrándolos
de la lista.
9.- Si hay atributos que no entran en las
tablas, definir nuevas entidades y/o
relaciones. Si es necesario repetir de 5
10.- Verificar si hay algún atributo o evento
que sea necesario incluir, si es así repetir
de 6 con nuevos eventos o de 8 con
nuevos atributos.
11.- Hacer una revisión general, ver si las
tablas están normalizadas, si los eventos
son soportados. Si es necesario repetir
desde 1.
12.- Borrar entidades superfluas.
10. Caso de estudio de
modelo conceptual y lógico
MODELO DE DATOS
BIBLIOTECA
11. Diseño físico
■ Las tablas obtenidas en el diseño

conceptual y lógico, se obtienen a partir
de las reglas de mapeo descritas.
■ En el diseño físico, dependiendo del
hardware y software en que se
implementa, pueden aplicarse cambios
en base a un estudio de las siguientes
consideraciones.
11. Diseño físico
■ 1-1. Participación no obligatoria en ambas

1 1
empleado trabaja proyecto
10% 95%
Casi todos los proyectos tienen empleado,
aquí se puede mapear como si proyecto
fuese obligatorio en la relación.
empleado (nro_emple, nom_emple)

proyecto (nro_proy, nom_proy, nro_emple)
11. Diseño físico
■ 1-m. Participación obligatoria de 1

m 1
solo 2
Un proyecto tiene m empleados pero m=2,
El lado m puede mapearse como si fuese 1,
en ese caso mapeamos solo dos tablas.

proyecto (nro_proy, nom_proy,
nro_emple_reponsable, nro_emple_subal)
11. Diseño físico
■ m-n. Participación obligatoria de m

m n
Pocos 1, 2
Un proyecto tiene m empleados el lado m son
pocos 1 o 2. El lado m puede mapearse como
si fuese 1, en ese caso mapeamos solo dos
tablas.

proyecto (nro_proy, nro_emple, nom_proy)
11. Diseño físico
■ Partición de tablas
1 1
máquina tiene máquina_detalle
Máquina es una entidad pero tiene muchos

atributos, y unos se usan más que otros. Es
posible generar máquina_detalle.
máquina (nro_maq, tipo, centro_trabajo, capacidad)

máquina_detalle (nro_maq, fecha_adquisición,
fecha_servicio, fecha_último_fallo)
11. Diseño físico
■ Atributos derivados.- Son aquellos cuya

información puede obtenerse a partir de otras
tablas de la base de datos.
precio_total = cantidad * precio_unitario
empleado (nro_emple, nro_proy, nom_proy)

proyecto (nro_proy, nom_proy, fecha_ini_pro)
12. Caso de estudio
modelo físico
CASO DE ESTUDIO
LA BIBLIOTECA
UNIDAD 4.
ALGEBRA RELACIONAL
Objetivo
Introducir los lenguajes conceptuales de las bases de
datos relacionales, creados a partir de fundamentos
matemáticos.
1. LAS BASES DE DATOS
RELACIONALES
■ Una base de datos relacional muestra las

tablas en forma de filas y columnas
ciudad (nro_ciudad nom_ciudad)
a1 La Paz
a5 Santa Cruz
a6 Tarija
a9 Potosí
■ Dominio.- Es el conjunto de todos los valores

permitidos que una columna puede tomar. Se
tiene D1,D2,...,Dn, si tenemos n columnas.
RELACIONALES
■ Tupla.- Cada una de las filas de una tabla se
compone de n elementos (v1,v2,..,vn)
En matemáticas este conjunto ordenado de
elementos se llama tupla.
■ Producto cartesiano.- De lo anterior se tiene
v1 ∈D1, v2 ∈D2, ... , vn ∈Dn, porque cada
elemento está en el dominio respectivo. En
matemáticas podemos decir que la tupla es
un elemento del producto cartesiano de los
dominios:
(v1,v2,....,vn) ∈(D1xD2x.....xDn) =Xi=1,n(Di)
RELACIONALES
■ Relación.- Por tanto, la tabla es un
subconjunto del producto cartesiano de
dominios, en otras palabra, por definición
matemática, es una relación.
■ Es por esto que en el álgebra relacional se
denomina relación a una tabla y tupla a un fila
de tabla.
2. EL ÁLGEBRA RELACIONAL
■ Se define el álgebra relacional como un

lenguaje para bases de datos relacionales de
tipo procedural. Operadores:
seleccionar σ unario
proyectar π unario
producto cartesiano x binario
renombrar ρ unario
unión ∪ binario
diferencia - binario
Estos son los 6 operadores fundamentales
del álgebra relacional para generar consultas
SELECCIONAR, σ, UNARIO
■ Permite recuperar un subconjunto de

tuplas de una relación.
préstamo (nom_suc nro_pres importe)
CAÑOTO 144 1500
BOLIVAR 122 1200
JUNIN 125 1800
BOQUERON 188 1500
JUNIN 132 1600
BOLIVAR 177 1550
Ej.1.- “Los préstamos de la sucursal JUNIN” :

σ nom_suc=‘JUNIN’ (préstamo)
JUNIN 125 1800
JUNIN 132 1600
Operadores relacionales: =, ≠, >, <, <=, >=

Operadores lógicos: ∧, ∨
CAÑOTO 144 1500
BOLIVAR 122 1200
JUNIN 125 1800
BOQUERON 188 1500
JUNIN 132 1600
BOLIVAR 177 1550
Ej.2.- “Los préstamos de la sucursal JUNIN,

con importe mayor a 1650” :
σ nom_suc=‘JUNIN’ ∧ importe>1650 (préstamo)
JUNIN 125 1800
resp_presta (nom_clien nom_emple nro_pres)
SUCHA RAMONA 134
MARCO JAIME 122
RUBÉN RUBÉN 178
Ej.3.- “Los clientes que tienen el mismo nombre que

su oficial de créditos” :
σ nom_clien = nom_emple (resp_presta)
RUBÉN RUBÉN 178
PROYECTAR, π, UNARIO

columnas de una relación.
CAÑOTO 144 1500
BOLIVAR 122 1200
JUNIN 125 1800
BOQUERON 188 1500
JUNIN 132 1600
BOLIVAR 177 1550
Ej.4.- “Seleccionar los clientes con préstamos mayores

a 1500, y la sucursal donde sacaron el préstamo” :
π nro_pres, importe (σ importe>1500 (préstamo))
125 1800
132 1600
177 1550
SUCHA RAMONA 134
MARCO JAIME 122
RUBÉN RUBÉN 178

su oficial de créditos, sin repetir el nombre” :
π nom_clien (σ nom_clien = nom_emple (resp_presta))
RUBÉN
Producto cartesiano, x, binario
■ Opera sobre dos relaciones r,s.

Permite combinar cada un de las
tuplas de r con cada una de las tuplas
de s.
■ Si r tiene n columnas y s tiene m
columnas r x s tiene n+m columnas.
cliente resp_presta
(nom_clien calle ciudad) (nom_clien nom_emple nro_pres)
MARCO calle5 La Paz SUCHA RAMONA 134
RUBÉN calle12 Potosí MARCO JAIME 122
RUBÉN RUBÉN 178
Ej.6.- “Los clientes que tienen oficial y la ciudad

donde radican”. cliente x resp_presta:
cliente. resp_presta.
nom_clien calle ciudad nom_clien nom_emple
MARCO calle5 La Paz MARCO JAIME 122
MARCO calle5 La Paz RUBÉN RUBÉN 178
RUBÉN calle12 Potosí SUCHA RAMONA 134
RUBÉN calle12 Potosí RUBÉN RUBÉN 178
cliente x resp_presta :
nom_clien calle ciudad nom_clien nom_emple nro_pres
σ resp_presta.nom_clien=cliente.nom_clien ( cliente x resp_presta)

cliente. atiende.
σ resp_presta.nom_clien=cliente.nom_clien ( cliente x resp_presta)
cliente. resp_préstamo.
π cliente.nom_clien, ciudad (
σ resp_presta.nom_clien=cliente.nom_clien ( cliente x resp_presta))
cliente.
nom_clien ciudad
MARCO La Paz
RUBÉN Potosí
RENOMBRAR, ρ, UNARIO
■ Permite cambiar el nombre de una

una relación. Se usa normalmente
cuando se usa dos veces una relación
en una consulta, permite diferenciar
los nombres de las columnas, que de
otra forma serían idénticos.
RENOMBRAR, ρ, UNARIO
■ Permite cambiar el nombre de la relación,
para diferenciar atributos del mismo nombre.
cliente resp_presta
SUCHA calle5 Sta. Cruz SUCHA RAMONA 134
RAMONA calle8 Tarija RUBÉN RUBÉN 178
RENATO calle1 Potosí
cliente x resp_presta x ρcli(cliente)

UNION, ∪, BINARIO
■ Permite recuperar los atributos de la

primera relación r más los atributos de
la segunda relación s. La unión solo
es posible cuando r y s cumplen las
siguientes dos condiciones:
1 r y s tienen la misma cantidad de
atributos.
2 Los atributos que se corresponden en
r y s tienen los mismos dominios.
UNION, ∪, BINARIO
prestatario (nro_pres nom_clien)
144 MARCO
125 SUCHA
impositor (nro_cuen nom_clien)

174 MARCO
182 RUBEN
Ej.7.- “Los clientes que tienen préstamo o depósito”

π nom_clien (prestatario) ∪ π nom_clien (impositor)
nom_suc
MARCO
SUCHA
RUBEN
DIFERENCIA, -, BINARIO

primera relación r que no están en la
segunda relación s. La diferencia solo
atributos.
DIFERENCIA, -, BINARIO
144 MARCO
125 SUCHA

174 MARCO
182 RUBEN
Ej.7.- “Los clientes que tienen préstamo pero no

tienen depósito”
π nom_clien (prestatario) - π nom_clien (impositor)
nom_suc
SUCHA
COMPLETITUD
■ Es posible demostrar matemáticamente que
se puede obtener cualquier consulta con los 6
operadores fundamentales que vimos:
seleccionar σ unario
proyectar π unario
producto cartesiano x binario
renombrar ρ unario
unión ∪ binario
diferencia - binario
Cualquier otro lenguaje es “completo” si
puede ejecutar estas 6 operaciones.
OPERADORES ADICIONALES
■ En el álgebra relacional se definen los
operadores adicionales:
intersección ∩ binario
producto natural ⇑ binario
división ÷ binario
todos estos operadores pueden ser
expresados mediante los 6 fundamentales.
Son necesarios solo para simplificar la
escritura de algunas consultas.
INTERSECCIÓN, ∩, BINARIO
primera relación r que también están en
la segunda relación s. La intersección
solo es posible cuando r y s cumplen las
siguientes mismas dos condiciones.
■ Equivalencia.-
r∩s=r-(r-s)
INTERSECCIÓN, ∩, BINARIO
144 MARCO
125 SUCHA

174 MARCO
182 RUBEN
Ej.7.- “Los clientes que tienen préstamo y depósito”

π nom_clien (prestatario) ∩ π nom_clien (impositor)
nom_suc
MARCO
Producto natural, ⇑, BINARIO
■ El producto natural es un producto
cartesiano mas la condición de que los
valores de los atributos comunes deben
ser los mismos.
■ Equivalencia.-
Sea r,s relaciones y R,S sus esquemas
o listas de atributos:
r ⇑ s = π R ∪ S (σ r.A1=s.A1 ∧.... ∧ r.An=s.An(r x s))
donde: R ∩ S = {A1, A2, ....,An}
Producto natural, ⇑, BINARIO
cliente resp_presta
RUBÉN RUBÉN 178

donde radican”. cliente ⇑ resp_presta:
nom_clien calle ciudad nom_emple nro_pres
MARCO calle5 La Paz JAIME 122
RUBÉN calle12 Potosí RUBÉN 178
π nom_clien, ciudad (cliente ⇑ resp_presta)

MARCO La Paz
RUBÉN Potosí
División, ÷, BINARIO
■ La división entre r y s, de esquemas R y
S, requiere que S⊆R.
■ La división da algunas tuplas de r
proyectadas sobre R-S, aquellas que en
su proyección sobre S tienen todas las
tuplas de la relación s.
■ Equivalencia.-
r ÷ s = π R-S ( r ) - π R-S ((π R-S ( r ) x s) - r)
■ Definición formal.- Dadas r,s relaciones
y R,S sus esquemas. Una tupla t está
en la división si:
■ t está en π R-S ( r )
■ para cada tupla ts de s hay una tupla tr
de r que cumple las condiciones:
a) tr[S] = ts[S]
b) t = tr[R-S]
r s r÷s
(A B C D) (C D) (A B)
a b c d c d a b
a b e f e f e d
b c e f
e d c d
e d e f
a b d e
División, ÷, BINARIO, prespres←préstamo⇑
prestatario
prespres sucursal
(nom_suc nro_pr nom_clien importe) (nom_suc ciudad)
CAÑOTO 144 MARCO 1500 CAÑOTO LPZ
BOLIVAR 122 RUBEN 1200 BOLIVAR SCZ
JUNIN 125 RUBEN 1800 BOQUERON LPZ
BOQUERON 188 RUBEN 1500 JUNIN SCZ
JUNIN 132 PLATINI 1600 BOLIVAR CBBA
BOLIVAR 177 PLATINI 1550
Los clientes que tienen préstamo en todas las sucursales de SCZ

π nom_clien, nom_suc ( préstamo ) ÷
RUBEN
π nom_suc (σ ciudad=‘SCZ’ ( sucursal))
PLATINI
5. OPERACIONES DEL ALGEBRA
RELACIONAL EXTENDIDA
■ Reunión externa.- Cuando hacemos
producto natural, las tuplas de una tabla que
no se combinan con tuplas de la otra tabla
no aparecen en la relación resultante.
1 r ⇐ s, en el producto natural mantiene las
tuplas de r que no se combinan.
2 r ⇒ s, en el producto natural mantiene las
tuplas de s que no se combinan.
3 r ⇔ s, en el producto natural mantiene las
tuplas de r y s que no se combinan.
5. OPERACIONES DEL ALGEBRA
RELACIONAL EXTENDIDA
■ Funciones de agregación.- se puede usar las
funciones agregadas: sum, avg, max, min,
count, count_distinct, etc. Se usan así:
sum importe (préstamo)
suma todos los importes de la relación
préstamo.
■ Agrupación.- Saca los resultados agrupando
por los atributos indicados. La forma es:
nom_suc Gsum importe (préstamo)
suma los préstamos de cada sucursal.
6. MODIFICACIÓN DE LA BASE
DE DATOS
■ Hasta ahora todos los programas se han

centrado en extraer información. Es
necesario además, insertar, borrar y
modificar información en la base de datos.
■ Borrado.- Permite eliminar tuplas de la base
de datos. Se expresa así:
r←r-E
donde r es una relación y E es una consulta
del álgebra relacional, que obtiene las tuplas
que se eliminarán de r.
6. MODIFICACIÓN DE LA BASE
DE DATOS
■ Inserción.- Permite aumentar una o varias
tuplas en la base de datos. Se usa:
r←r∪E
donde r es una relación y E es un consulta
del álgebra relacional o una tupla a insertar.
■ Actualización.- Permite modificar uno o
varios valores de la base de datos. Se puede
usar la proyección extendida:
r ← π F1,F2,....,Fn (r) . Por ejemplo, aumentar 5%
a todas las cuentas de depósito=r:
r ← π nom_suc, nro_cue, saldo←saldo*1.05 (r)
7. VISTAS
■ create view v como E; donde E es una
consulta del álgebra relacional, y v es el
nombre de la vista.
3. CALCULO RELACIONAL DE TUPLAS
■ El cálculo relacional es un lenguaje sin

procedimientos o no procedural, donde se da
una descripción formal de la información
deseada sin especificar como obtenerla.
■ Existen dos formas el cálculo relacional de
tuplas CRT y el cálculo relacional de dominios
CRD, las dos de características muy
similares.
■ La forma general de una consulta en el CRT
es: { t / P(t) }, se dice conjunto de tuplas t
tales que cumplen P(T).
SELECCIÓN

tuplas de una relación.
SELECCIÓN

CAÑOTO 144 1500
BOLIVAR 122 1200
JUNIN 125 1800
BOQUERON 188 1500
JUNIN 132 1600
BOLIVAR 177 1550

{ t / t ∈préstamo ∧ nom_suc=‘JUNIN’ }
JUNIN 125 1800

JUNIN 132 1600
SELECCIÓN

CAÑOTO 144 1500
BOLIVAR 122 1200
JUNIN 125 1800
BOQUERON 188 1500
JUNIN 132 1600
BOLIVAR 177 1550

{ t / t ∈préstamo ∧ nom_suc=‘JUNIN’ ∧
importe>1650 }
JUNIN 125 1800
SELECCIÓN

SUCHA RAMONA 134
MARCO JAIME 122
RUBÉN RUBÉN 178

{ t / t ∈resp_presta ∧ nom_clien=nom_emple }
RUBÉN RUBÉN 178

PROYECCIÓN

columnas de una relación.
PROYECCIÓN

CAÑOTO 144 1500
BOLIVAR 122 1200
JUNIN 125 1800
BOQUERON 188 1500
JUNIN 132 1600
BOLIVAR 177 1550
Ej.4.- “Seleccionar los clientes con préstamos mayores

{ t[nro_pres, importe] / t ∈préstamo ∧
importe>1500 } 125 1800
132 1600
177 1550
PROYECCIÓN

SUCHA RAMONA 134
MARCO JAIME 122
RUBÉN RUBÉN 178

{ t[nom_clien] / t ∈resp_presta ∧
nom_clien=nom_emple }
RUBÉN
PRODUCTO
■ Es posible en el CRT operar sobre

dos o más relaciones.
PRODUCTO
cliente resp_presta
RUBÉN RUBÉN 178

donde radican”. cliente x atiende:
{ t[nom_clien, ciudad] / t ∈cliente ∧
∃ u (u ∈resp_presta ∧ t[nom_clien]=u[nom_clien] ) }
nom_clien ciudad
MARCO La Paz
RUBÉN Potosí
UNIÓN

primera relación r más los atributos de
la segunda relación s. La unión solo
atributos.
UNIÓN

144 MARCO
125 SUCHA

174 MARCO
182 RUBEN

{ t[nom_clien]/∃ u(u ∈ prestatario ∧ t[nom_cli]=u[nom_cli])
∨ ∃ v(v ∈ impositor ∧ t[nom_cli]=v[nom_cli]) }
MARCO
SUCHA
RUBEN
DIFERENCIA
■ Permite recuperar las tuplas de la

primera relación r que no están en la
segunda relación s. La diferencia solo
atributos.
DEFERENCIA

144 MARCO
125 SUCHA

174 MARCO
182 RUBEN

tienen depósito”
∧ ¬∃ v(v ∈ impositor ∧ t[nom_cli]=v[nom_cli]) }
SUCHA
INTERSECCIÓN
■ Permite recuperar las tuplas de la

primera relación r que también están en
la segunda relación s. La intersección
solo es posible cuando r y s cumplen las
dos condiciones mencionadas en unión.
INTERSECCIÓN

144 MARCO
125 SUCHA

174 MARCO
182 RUBEN

∧ ∃ v(v ∈ impositor ∧ t[nom_cli]=v[nom_cli]) }
nom_suc
MARCO
DEFINICIÓN FORMAL
■ Las expresiones del CRT son de la forma:

{ t / ψ(t) }, donde t es una variable de tipo
tupla y ψ es una fórmula construida a partir de
átomos. Hay tres tipos de átomo:
1 t ∈ r, significa que la tupla t pertenece a la
relación r.
2 t[i] Θ u[j], Θ es un operador relacional: =, ≠, >,
<, <=, >=, i-j son dos atributos de las tuplas t-
u
3 t[i] Θ a, donde a es una constante.
DEFINICIÓN FORMAL
■ Las fórmulas ψ se forman a partir de átomos

usando las siguiente definición recursiva:
1 Un átomo es un fórmula
2 Si β es una fórmula también lo son ¬ β y (β)
3 Si β1 y β2 son fórmulas, también los son:
β1 ∧ β2, β1 ∨ β2, β1 ⇒ β2
4 Si β(s) es una fórmula en función de s, donde
s es una variable de tipo tupla, entonces:
∀s (β(s)), ∃s (β(s)), también son fórmulas.
5 Nada más es una fórmula.
DEFINICIÓN FORMAL
■ A continuación tenemos las siguientes

equivalencias más utilizadas en el CRT
■ (β1 ∧ β2) ⇔ ¬ (¬β1 ∨ ¬β2)
■ ∀s (β(s)) ⇔ ¬∃s (¬β(s))
■ (β1 ⇒ β2) ⇔ (¬β1 ∨ β2)
SEGURIDAD DE LAS FÓRMULAS
■ En el CRT no se permite obtener consultas

que retornen un número infinito de tuplas. Sin
embargo es necesario 3 reglas adicionales
para impedir expresiones incorrectas como:
{ t / ¬ψ(t) }. Pero necesitamos la definición:
■ Dominio de fórmula.- DOM(ψ), es el conjunto
de constantes que aparecen en ψ más todos
los valores de las relaciones que se usa ψ.
■ Por ejemplo en ψ=“t[1]=a ∨ (t ∈ r)”, donde r es
una relación con dos atributos (1,2)
DOM(ψ) = {a} ∪ π1( r ) ∪ π2( r )
■ Decimos que una expresión del CRT { t / ψ(t)}

es una fórmula segura si:
1 Siempre que t haga verdadera ψ, cada
componente de t debe pertenecer a DOM(ψ).
2 Para cada subfórmula ψ de la forma
∃s (W(s)), si s hace verdadera la fórmula W,
entonces cada componente de s debe
pertenecer al dominio DOM(W).
3 Para cada subfórmula ψ de la forma
∀s (W(s)), si un componente de s no está en
DOM(W), entonces s debe hacer verdad W.
■ Normalmente se usa de la siguiente forma los

cuantificadores existencial y universal:
∃s (s∈r ∧ ......)
∀s (¬(s∈r) ∨ ......)
■ son dos formas de comenzar a escribir la
fórmula, para que la fórmula resultante sea
segura.
DIVISIÓN

■ La división genera algunas tuplas de r
DIVISIÓN
r s
(A B C D) (C D) (A B)
a b c d c d a b
a b e f e f e d
b c e f
e d c d
e d e f
a b d e
{ t[A,B] / t∈r ∧ ∀u (¬(u∈r) ∨

∃v (v∈r ∧ u[C]=v[C] ∧ u[D]=v[D]
∧ t[A]=v[A] ∧ t[B]=v[B] ))}
DIVISIÓN, prespres←préstamo⇑prestatario
prespres sucursal
BOLIVAR 144 MARCO 1500 CAÑOTO LPZ

{ t[nom_clien] / t∈prespres ∧ ∀u (¬(u∈sucursal)
∨ ¬(u[ciudad]=‘SCZ’) ∨ ∃v (v∈prespres ∧
u[nom_suc]=v[nom_suc] ∧ t[nom_clien]=v[nom_clien] )) }
RUBEN
PLATINI
4. CALCULO RELACIONAL DE DOMINIOS
■ Se construye con los mismo operadores y

reglas del CRT, se usan variables tipo
dominio en vez de variables tipo tupla.
■ Diferencias en la definición de átomos:
1 <x1,x2,...,xn>∈r; donde x1,..,xn son las
variables tipo dominio y r una relación.
2 x Θ y; x e y son las variables dominio.
3 x Θ k; x es variable dominio y k constante
■ Las otras definiciones y reglas son
equivalentes.
SELECCIÓN

CAÑOTO 144 1500
BOLIVAR 122 1200
JUNIN 125 1800
BOQUERON 188 1500
JUNIN 132 1600
BOLIVAR 177 1550
“Los préstamos de la sucursal JUNIN” :

{ ns,np,im / <ns,np,im> ∈préstamo
∧ ns=‘JUNIN’ }
JUNIN 125 1800
JUNIN 132 1600
SELECCIÓN

CAÑOTO 144 1500
BOLIVAR 122 1200
JUNIN 125 1800
BOQUERON 188 1500
JUNIN 132 1600
BOLIVAR 177 1550
“Los préstamos de la sucursal JUNIN,

{ ns,np,im / <ns,np,im> ∈préstamo
∧ ns=‘JUNIN’ ∧ im>1650 }
JUNIN 125 1800
SELECCIÓN

SUCHA RAMONA 134
MARCO JAIME 122
RUBÉN RUBÉN 178
“Los clientes que tienen el mismo nombre que

{ nc,ne,np / <nc,ne,np> ∈ resp_presta ∧ ns=ne }
RUBÉN RUBÉN 178

PROYECCIÓN

CAÑOTO 144 1500
BOLIVAR 122 1200
JUNIN 125 1800
BOQUERON 188 1500
JUNIN 132 1600
BOLIVAR 177 1550
“Seleccionar los clientes con préstamos mayores

{ np,im / ∃ ns (<ns,np,im> ∈ préstamo ∧
im>1500) } 125 1800
132 1600
177 1550
PROYECCIÓN

SUCHA RAMONA 134
MARCO JAIME 122
RUBÉN RUBÉN 178
“Los clientes que tienen el mismo nombre que

{ nc / ∃ ne,np (<nc,ne,np> ∈ resp_presta ∧ nc=ne) }
RUBÉN
PRODUCTO
cliente resp_presta
RUBÉN RUBÉN 178

donde radican”. cliente x atiende:
{ nc, ci / ∃ ca (<nc,ca,ci> ∈ cliente ∧
∃ ne,np (<nc,ne,np> ∈ resp_presta ) ) }
nom_clien ciudad
MARCO La Paz
RUBÉN Potosí
UNIÓN

144 MARCO
125 SUCHA

174 MARCO
182 RUBEN

{ nc/ ∃ np (<np,nc> ∈ prestatario )
∨ ∃ ncu (<ncu,nc> ∈ impositor) }
MARCO
SUCHA
RUBEN
DIFERENCIA

144 MARCO
125 SUCHA

174 MARCO
182 RUBEN

tienen depósito”
∧ ¬∃ ncu (<ncu,nc> ∈ impositor ) }
SUCHA
INTERSECCIÓN

144 MARCO
125 SUCHA

174 MARCO
182 RUBEN

∧ ∃ ncu (<ncu,nc> ∈ impositor)
nom_suc
MARCO
DIVISIÓN

■ La división genera algunas tuplas de r
DIVISIÓN
r s
(A B C D) (C D) (A B)
a b c d c d a b
a b e f e f e d
b c e f
e d c d
e d e f
a b d e
{ A,B / ∃C,D(< A,B,C,D>∈r ∧ ∀C1,D1 (

¬(<C1,D1>∈s) ∨ (< A,B,C1,D1>∈r ) ) }
DIVISIÓN, prespres←préstamo⇑prestatario
préstamo sucursal
BOLIVAR 144 MARCO 1500 CAÑOTO LPZ

{ nc / ∃ns,np,im(< ns,np,nc,im>∈préstamo ∧ ∀ns1,ci (
¬(<ns1,ci>∈sucursal) ∨ ¬(ci=‘SCZ’)
∨ ∃np1,im1 (<ns1,np1,nc,im1>∈préstamo ) ) }
RUBEN
PLATINI
UNIDAD 4.
SQL Y OTROS LENGUAJES
Objetivo
Introducir a los lenguajes de uso más frecuente en
bases de datos relacionales SQL y QBE.
1. SQL
■ SQL se ha establecido claramente en el

lenguaje estandar de bases de datos
relacionales.
■ Es un lenguaje LDD o de definición de
datos, LMD de manipulación de datos, y
LCD o de control de datos. Todo esto en un
solo lenguaje SQL.
1. SQL
■ Los comando más importante son:

■ LDD, definición de datos:
CREATE TABLE, CREATE INDEX,
CREATE VIEW, DROP TABLE, DROP
INDEX, DROP VIEW, ALTER TABLE,
COMMENT.
■ LMD, manipulación de datos:
SELECT, INSERT, UPDATE, DELETE.
■ LCD, control de datos:
GRANT, REVOKE, COMMIT, ROOLBACK.
1. SQL
SELECT
■ Permite recuperar información de la

base de datos.
■ Junto con insert, update y delete
permiten manipular los datos de
cualquier forma.
1. SQL
SELECT - SELECCIÓN
CAÑOTO 144 1500
BOLIVAR 122 1200
JUNIN 125 1800
BOQUERON 188 1500
JUNIN 132 1600
BOLIVAR 177 1550

select * from prestamo where
nom_suc=‘JUNIN’
JUNIN 125 1800
JUNIN 132 1600
1. SQL
SELECT - SELECCIÓN
CAÑOTO 144 1500
BOLIVAR 122 1200
JUNIN 125 1800
BOQUERON 188 1500
JUNIN 132 1600
BOLIVAR 177 1550

select * from prestamo where
nom_suc=‘JUNIN’ and importe>1650
JUNIN 125 1800
1. SQL
SELECT - SELECCIÓN
SUCHA RAMONA 134
MARCO JAIME 122
RUBÉN RUBÉN 178

select * from resp_presta where
nom_clien=nom_emple
RUBÉN RUBÉN 178

1. SQL
SELECT - PROYECCIÓN
CAÑOTO 144 1500
BOLIVAR 122 1200
JUNIN 125 1800
BOQUERON 188 1500
JUNIN 132 1600
BOLIVAR 177 1550
Ej.4.- “Número de préstamo e importe de los

préstamos con importe mayor a 1500” :
select nro_pres, importe from préstamo
where importe = 1500 125 1800
132 1600
177 1550
1. SQL
SUCHA RAMONA 134
MARCO JAIME 122
RUBÉN RUBÉN 178

select nom_clien from resp_presta
where nom_clien=nom_emple
RUBÉN
1. SQL
SELECT - PRODUCTO
cliente resp_presta
RUBÉN RUBÉN 178

donde radican”. Select * from cliente, resp_presta:
nom_clien calle ciudad nom_clien nom_emple
1. SQL
SELECT - PRODUCTO
Select * from cliente, resp_presta :
Select * from cliente, resp_presta where

resp_presta.nom_clien, cliente.nom_clien
cliente. atiende.
1. SQL
SELECT - PRODUCTO
Select * from cliente, resp_présta
where resp_presta.nom_clien, cliente.nom_clien
cliente. resp_préstamo.
Select cliente.nom_clien, ciudad from cliente, resp_présta

where resp_presta.nom_clien, cliente.nom_clien
cliente.
nom_clien ciudad
MARCO La Paz
RUBÉN Potosí
1. SQL
SELECT - RENOMBRAR
■ Permite cambiar el nombre de la relación,
para diferenciar atributos del mismo nombre.
cliente resp_presta
SUCHA calle5 Sta. Cruz SUCHA RAMONA 134
RAMONA calle8 Tarija RUBÉN RUBÉN 178
RENATO calle1 Potosí
Select * from cliente, resp_presta, cliente as cl

1. SQL
SELECT - UNION
144 MARCO
125 SUCHA

174 MARCO
182 RUBEN

(select nom_clien from prestatario) union
(select nom_clien from impositor)
nom_suc
MARCO
SUCHA
RUBEN
1. SQL
SELECT - DIFERENCIA
144 MARCO
125 SUCHA

174 MARCO
182 RUBEN

tienen depósito”
(select nom_clien from prestatario) except
nom_suc
SUCHA
1. SQL
SELECT - INTERSECCIÓN
144 MARCO
125 SUCHA

174 MARCO
182 RUBEN

(select nom_clien from prestatario) intersect
nom_suc
MARCO
1. SQL
SELECT - OUTER JOIN
■ Reunión externa.- Cuando hacemos
producto natural, las tuplas de una tabla que
no se combinan con tuplas de la otra tabla
no aparecen en la relación resultante.
1 Select * from tabla1, tabla2
where tabla1.columna (+) = tabla2.columna
en el producto natural mantiene las tuplas de
r que no se combinan.
1. SQL
SELECT - OUTER JOIN
2 Select * from tabla1, tabla2
where tabla1.columna = tabla2.columna (+)
s que no se combinan.
3 Select * from tabla1, tabla2 where
tabla1.columna (+) = tabla2.columna (+)
r y s que no se combinan.
1. SQL
SELECT - FUNCIONES AGREGADAS
■ Funciones agregadas.- se puede usar las
count, count_distinct, etc. Se usan así:
select sum(importe) from préstamo
suma todos los importes de la relación
préstamo.
por los atributos indicados. La forma es:
select sum(importe) from préstamo
group by nom_suc
suma los préstamos de cada sucursal.
1. SQL
DELETE

de datos. Se expresa así:
delete from r where <condición>
donde r es una relación y es una condición
where de SQL, que obtiene las tuplas de r
que se eliminarán.
1. SQL
INSERT, UPDATE
tuplas en la base de datos. Se usa:
insert into r E
donde r es una relación y E es un consulta
“select” o “values(...)” donde se indican los
datos de la tupla a insertar.
varios valores de la base de datos. Se puede
usar la proyección extendida:
update set <asigna> where <condición>
1. SQL
VISTAS
■ create view v as E; donde E es una consulta
“select” del SQL, y v es el nombre de la vista.
1. QBE
■ Query by example QBE es un lenguaje para

bases de datos relacionales, basado en el
cálculo relacional de dominios.
■ Por tanto es lo más próximo a un lenguaje
no procedural, en la práctica no existe como
lenguaje, está inmerso en los lenguajes
comerciales, con excelentes resultados.
■ También se conoce el QUEL basado en el
cálculo relacional de tuplas, el cual no los
trataremos.
1. QBE
SELECT
■ Permite recuperar información de la

base de datos. QBE elimina los
resultados duplicados por default.
■ Junto con insert, update y delete
permiten manipular los datos de
cualquier forma.
1. QBE
SELECT - SELECCIÓN
CAÑOTO 144 1500
BOLIVAR 122 1200
JUNIN 125 1800
BOQUERON 188 1500
JUNIN 132 1600
BOLIVAR 177 1550

préstamo nom_suc nro_pres importe
P. JUNIN
JUNIN 125 1800

JUNIN 132 1600
1. QBE
SELECT - SELECCIÓN
CAÑOTO 144 1500
BOLIVAR 122 1200
JUNIN 125 1800
BOQUERON 188 1500
JUNIN 132 1600
BOLIVAR 177 1550

P. JUNIN >1650
JUNIN 125 1800

1. QBE
SELECT - SELECCIÓN
resp_préstamo (nom_clien nom_emple nro_pres)
SUCHA RAMONA 134
MARCO JAIME 122
RUBÉN RUBÉN 178

resp_préstamo nom_clien nom_emple nro_pres
P. _x _x
RUBÉN RUBÉN 178

1. QBE
CAÑOTO 144 1500
BOLIVAR 122 1200
JUNIN 125 1800
BOQUERON 188 1500
JUNIN 132 1600
BOLIVAR 177 1550
Ej.4.- “Número de préstamo e importe de los

préstamos con importe mayor a 1500” :
P. P.>1650
125 1800
132 1600
177 1550
1. QBE
resp_préstamo (nom_clien nom_emple nro_pres)
SUCHA RAMONA 134
MARCO JAIME 122
RUBÉN RUBÉN 178

P._x _x
RUBÉN
1. QBE
SELECT - PRODUCTO
cliente resp_presta
RUBÉN RUBÉN 178

donde radican”.
cliente nom_clien calle ciudad
P._x P.
_x
MARCO La Paz
RUBÉN Potosí
1. QBE
SELECT - UNION
144 MARCO
125 SUCHA

174 MARCO
182 RUBEN

prestatario nro_pres nom_clien
P._x MARCO
SUCHA
impositor nro_cuen nom_clien RUBEN
P._y
1. QBE
SELECT - DIFERENCIA
144 MARCO
125 SUCHA

174 MARCO
182 RUBEN

tienen depósito”
P._x nom_suc
impositor nro_cuen nom_clien SUCHA
¬ _x
1. QBE
SELECT - INTERSECCIÓN
144 MARCO
125 SUCHA

174 MARCO
182 RUBEN

nom_suc
P._x
MARCO
impositor nro_cuen nom_clien
_x
1. QBE
CAJA DE CONDICIÓN
CAÑOTO 144 1500
BOLIVAR 122 1200
JUNIN 125 1400
BOQUERON 188 1500
JUNIN 132 1600
BOLIVAR 177 1550
Ej.7.- “Los números de préstamo que tienen importe
mayor a cualquier préstamo de la sucursal BOLIVAR”
¬ _v P. _x nro_pres
_v _y 144
condición 188
177
_v='JUNIN' and _x>_y
1. QBE
RELACIÓN RESULTADO
préstamo prestatario
(nom_suc nro_pres importe) (nro_pres nom_clien)
CAÑOTO 144 1500 144 MARCO
BOLIVAR 122 1200 125 SUCHA
JUNIN 125 1400 122 TUCHO
BOQUERON 188 1500 188 RUBÉN
JUNIN 132 1600 177 TUCHO
BOLIVAR 177 1550 132 JOSELITO
“Préstamos de sucursal BOLIVAR con nom_clien”

BOLIVAR _x _v
_x _u
resultado nom_clien nro_pres importe
P. _u _x _v
1. QBE
FUNCIONES AGREGADAS
■ Funciones agregadas.- se puede usar las
cnt, cnt_distinct, etc. Es necesario aumentar
.all para evitar que elimine los duplicados.
por los atributos indicados.
1. QBE
FUNCIONES AGREGADAS

BOLIVAR P.sum.all

P.cnt.unq.all

P.G P.avg.all._x
condición
avg.all._x > 8000
1. SQL
DELETE

de datos. Por ejemplo para eliminar los
préstamos de la sucursal JUNIN:
D. BOLIVAR
1. QBE
INSERT, UPDATE
tuplas en la base de datos. Por ejemplo para
insertar un cliente:
cliente nom_clien calle ciudad
I. JOSELITO ca3 SCZ

varios valores de la base de datos. Por
ejemplo para incrementar el 5% a todos los
saldos de las cuentas:
cuenta nom_suc nro_cuen saldo
U. _x * 1.05
_x
UNIDAD 5.
OPTIMIZACIÓN DE CONSULTAS
Objetivo
Usar las técnicas existentes para optimizar las
consultas a las bases de datos relacionales.
Especialmente aquellas que son críticas en el
funcionamiento del sistema.
Dr. Renato Barrera.
1. INTRODUCCIÓN
■ El enfoque ciego y el de descomposición

permiten responder bien y barato.
■ Ambos se basan en representaciones
algebraicas.
■ Bueno, en realidad es optimización de las
respuestas no de consultas.
2. EL MÉTODO CIEGO
■ Trabaja con un árbol sintáctico.

■ Es una receta de cocina.
■ Fácil de aplicar
■ Bastante bueno.
■ Es ciego a:
La implementación de los operadores, quizá
los operadores lo consideran, pero por lo
general si optimiza. !Y cuando lo necesitás!
Estadisticas de los datos, quizá de acuerdo
a la cantidad de datos no es necesario.
2. EL MÉTODO CIEGO
MOTIVACIÓN
■ Cuesta menos procesar relaciones

pequeñas que grandes.
■ Las selecciones y proyecciones reducen el
tamaño de las relaciones
■ Luego, haga usted cuanto antes las
selecciones y proyecciones.
2. EL MÉTODO CIEGO
PASOS CIEGOS
1 Obtenga el árbol sintáctico

2 Transforme producto natural en “selección -
producto cartesiano”.
⇑ σ
⇔
x
3 Empuje las selecciones lo mas abajo posible

4 Empuje proyecciones lo mas abajo posible
2. EL MÉTODO CIEGO
PASOS CIEGOS
■ Unifique selecciones y proyecciones

πA πB ⇔ πA∩B
σc1 σc2 ⇔ σc1∧c2
■ Recombine juntas
■ Haga planes de ejecución
2. EL MÉTODO CIEGO
EJEMPLO
■ “Dame nombres de los proveedores de
partes de color rojo”.
π sname (σ color=‘rojo’ ( (s ⇑ sp) ⇑ p))
1 πsname
σcolor=‘rojo’
Árbol ⇑
sintáctico
⇑ p
s sp
2. EL MÉTODO CIEGO
EJEMPLO
2 Descomposición Empuja selecciones
3
de juntas hacia abajo
πsname πsname
σcolor=‘rojo’ σp.p#=sp.p#
σp.p#=sp.p# x
x σs.s#=sp.s# σcolor=‘rojo’
σs.s#=sp.s# p x
x s sp p
s sp
2. EL MÉTODO CIEGO
EJEMPLO
4 Empuja proyecciones hacia abajo
πsname
σp.p#=sp.p#
x
πp#, sname
σs.s#=sp.s#
x πp#
πsname, s# σcolor=‘rojo’
πp#, s#
s πp#, color
sp
p
2. EL MÉTODO CIEGO
EJEMPLO
5 Unificar proyecciones y selecciones. Innecesario
6 Recombinar juntas
πsname
⇑
πp#, sname
⇑
πp#
πsname, s# πp#, s#
σcolor=‘rojo’
s sp
πp#, color
p
2. EL MÉTODO CIEGO
EJEMPLO
7 Planes de ejecución
πsname
⇑
πp#, sname
⇑
πp#
πsname, s# πp#, s#
σcolor=‘rojo’
s sp
πp#, color
p
3. MÉTODO DE DESCOMPOSICIÓN
■ Se concentra en juntas
■ Todas las otras operaciones se consideran
triviales
■ Representa consulta como “grafo de
consulta”
■ Semijunta
A←B ⇔ π A ( A ⇑ B)
■ Grafo de consulta.-
Cada nodo del grafo es una relación
Existe lado entre nodo A y nodo B, si A y B
están unidos por una junta.
GRAFO DE UNA RUTA
■ Cuando el grafo es de una ruta, se hace un

paso atrás y uno adelante
r1 r2 rk-1 rk
HACIA ATRÁS HACIA ADELANTE

ratk = rk rad1 = rat1
ratk-1 = rk-1 ← ratk rad2 = rat2 ← rat1
ratk-2 = rk-2 ← ratk-1 rad3 = rat3 ← rat2
........... ...........
rat2 = r2 ← rat3 radk-1 = ratk-1 ← ratk-2
rat = r ← rat rad = rat ← rat
GRAFO DE VARIAS RUTA
■ Método.-
1 Escoja un nodo del árbol como raíz del
mismo
2 Oriente los lados del árbol hacia fuera de la
raíz
3 Haga el barrido hacia atrás de cada rama de
árbol
4 Haga barrido hacia delante, partiendo de la
raíz
5 Mande ensamblar
Escoja una raiz B raiz
E
C
A D
E
Oriente los lados A B
D
C
Paso hacia atrás

E
Eat=E Bat=B Aat=A
Dat=D←E
A B D Cat=((C ←Aat) ←Bat) ←Da

Cad=Cat
Paso hacia delante

Aad=Aat ←Cad Bad=Bat←Cad Dad=Dat←Cad
C Ead=Eat←Dad
Envíe A B C D E y ensamble.
GRAFO CON CICLO
“Dame las personas que practican su deporte nacional”

deporte_practicado origen
(deporte persona) (persona país)
Futbol Venancio Joao Brasil
Jai Alai Joao Venancio España
deporte_nacional
(país deporte)
deporte_practicado
Brasil Futbol origen
España Jai Alai
deporte_nacional
Quienes? !!NADIE!!
GRAFO CON CICLO
origen deporte_practicado
deporte_nacional
■ TRUCO.- migración de llaves.
1 Rompa un nodo del ciclo
2 Añada una llave a tal nodo, tomo ese nodo
como raíz.
3 Haga pasos hacia atrás y hacia delante:
Migrando llaves cuando haga semijunta con
otra relación sin llave, y usando llaves
cuando junte con relación que tiene llave.
GRAFO CON CICLO
origen deporte_practicado
deporte_nacional
origen1 dep_prac dep_nac origen2
origen2 (llave, persona, país)
1 Joao Brasil
2 Venancio España
GRAFO CON CICLO

dep_nac origen2_at
(país, deporte) (llave, persona, país)
Brasil Futbol 1 Joao Brasil
España Jai Alai 2 Venancio España
dep_nac_at = dep_nac ← origen2

dep_nac_at (llave, país, deporte)
1 Brasil Futbol
2 España Jai Alai
GRAFO CON CICLO

dep_prac dep_nac_at
(deporte persona) (llave, país, deporte)
Futbol Venancio 1 Brasil Futbol
Jai Alai Joao 2 España Jai Alai
dep_prac_at = dep_prac ← dep_nac_at

dep_prac_at (llave, deporte, persona)
1 Futbol Venancio
2 Jai Alai Joao
GRAFO CON CICLO

origen1 dep_prac_at
(llave, persona, país) (llave, deporte, persona)
1 Joao Brasil 1 Futbol Venancio
2 Venancio España 2 Jai Alai Joao
origen1_at = origen1 ← dep_prac_at

origen1_at (llave, persona, país)
!!!!NADIE!!!, correcto Fin Renato.

UNIDAD 6.
CREACIÓN DE BASES DE DATOS
Objetivo
Implementar bases de datos relacionales, utilizando
los recursos y lenguajes existentes en el momento.
INTRODUCCIÓN
■ La implementación de la base de datos

comienza con la creación de las tablas.
❧ CREATE SEQUENCE s_dept_id
❧ MINVALUE 1
❧ MAXVALUE 9999999
❧ INCREMENT BY 1
❧ START WITH 51
❧ NOCACHE NOORDER NOCYCLE;
INTRODUCCIÓN
❧ CREATE TABLE s_dept

❧ (id NUMBER(7)
❧ CONSTRAINT s_dept_id_nn NOT NULL,
❧ name VARCHAR2(25)
❧ CONSTRAINT s_dept_name_nn NOT NULL,
❧ region_id NUMBER(7),
❧ CONSTRAINT id PRIMARY KEY (id),
❧ CONSTRAINT nr UNIQUE (name,region_id));
❧ INSERT INTO s_dept VALUES

❧ (10, 'Finance',1);
1. ÍNDICES
■ Los índices aceleran la recuperación de

datos, pero ocupan espacio, pueden ser:
unique
admitir valores duplicados
■ Las claves primarias son siempre unique
■ Las claves foráneas pueden admitir
duplicados
■ Pueden crearse índices sobre grupos de
campos
1. ÍNDICES
■ Create unique index index_id on s_dept(id)
■ Create index index_name on s_dept(name)
■ Create unique index index_name_reg

on s_dept(name, region_id)
2. INTEGRIDAD REFERENCIAL
■ Permite asegurar la consistencia entre las

relaciones.
Padre
Clave primaria (maestro)
Clave foránea Hijo

(detalle)
Todo hijo debe tener un padre

Todo padre debe tener una clave primaria única
■ Las claves primarias deben declararse como

not nulls.
■ La clave primaria debe ser unique.
■ Si el usuario borra una clave primaria, y
existen claves foráneas asociadas, falla.
■ Si el usuario modifica una clave primaria y
existen claves foráneas asociadas, falla.
■ Si el usuario actualiza o inserta una clave
foránea y no existe clave primaria, falla.
■ Referencias cíclicas Padre
Hijo
■ Autoreferencias Padre/Hijo
Padre
■ Referencias múltiples
Hijo Hijo
Referencias cíclicas
❧ ALTER TABLE s_dept ADD

❧ CONSTRAINT s_dept_id_pk
❧ PRIMARY KEY (id),
❧ ALTER TABLE s_dept ADD

❧ CONSTRAINT s_dept_region_id_fk
❧ FOREIGN KEY (region_id)
❧ REFERENCES s_region (id);
Autoreferencias
❧ CREATE TABLE empleado (

❧ emp_num number NOT NULL,
❧ gerente number,
❧ CONSTRAINT pk_en
❧ PRIMARY KEY (emp_num),
❧ CONSTRAINT fk_en
❧ FOREIGN KEY (gerente)
❧ REFERENCES empleado(emp_num)
❧ );
Referencias múltiples
❧ ALTER TABLE tienda

❧ ADD CONSTRAINT pk_tienda
❧ PRIMARY KEY (tienda_cod);
❧ ALTER TABLE video

❧ ADD CONSTRAINT fk1_tienda FOREING KEY
❧ (tienda_cod) REFERENCES tienda;
❧ ALTER TABLE empleado

❧ ADD CONSTRAINT fk2_tienda FOREING KEY
❧ (tienda_cod) REFERENCES tienda;
3. CLAVES Y COLUMNAS CON
VALORES ÚNICOS
■ Toda clave primaria es un índice. Las claves

primarias y foráneas son estructurales:
implican una relación con otra relación.
■ Un índice es básicamente una herramienta de
optimización de performance: no es parte de
la estructura: “podemos hacer un drop de un índice,
no podemos eliminar una clave primaria”.
■ Las claves foráneas no incluyen un índice,
cuando la tabla crece es importante
incorporarlo para mejorar la performance.
3. CLAVES Y COLUMNAS CON
VALORES ÚNICOS
■ La restricción unique asegura que todas las

filas tendrán un valor único en la columna
indicada.
■ Una columna que es primary key es
automáticamente de valor único.
■ Un índice único también asegura esta
propiedad:
ALTER TABLE s_dept ADD

CONSTRAINT s_dept_na_reg_id_uk
UNIQUE (name, region_id);
4. PERMISOS DE ACCESO
Y PRIVILEGIOS
■ Las autorizaciones de uso de la base de

datos son denominadas privilegios.
■ El dueño de la base de datos tiene todos los
privilegios.
■ Existen privilegios sobre:
la base
las tablas
las columnas
Y PRIVILEGIOS
■ Connect.- Permite crear un usuario que podrá

conectarse a otras bases de datos si le dan
permiso. Se usa para los usuarios comunes.
Grant connect to pedro identified by caña;
■ Resource.- Da permiso a un usuario ya
creado con “connect”, para crear una base de
datos, incluyendo tablas, procedimiento
almacenados, índices, etc.
Grant resource to paty identified by minie;
Y PRIVILEGIOS
■ DBA.- Da permiso a un usuario con permiso

“resource”, para convertirse en administrador
de la base de datos.
Grant dba to katia identified by clarabella;
Y PRIVILEGIOS
■ Solo el dueño puede dar permisos para

accesar a una base de datos. Se puede usar:
all, select, update, insert, delete y otros.
■ Por ejemplo Paty puede autorizar a Pedro:
Grant all on s_dept to pedro;
■ Paty autoriza a Katia para actualizar el
atributo name de la tabla s_dept
Grant update(name) on paty.s_dept to katia;
5. VISTAS
■ Restringe el uso de columnas de tablas

■ Restringe el uso de filas de tablas
■ Restringe los updates a rangos
■ Acceso a datos derivados
■ Encapsular detalles de un select complicado
■ Permite optimizar consultas, de acuerdo a los
criterios del método ciego.
5. VISTAS
■ CREATE VIEW v_cliente AS

SELECT cod, nom, apell FROM cliente;
■ CREATE VIEW v_cli_est AS

SELECT cli_cod, dir, ciu, estado.nom
FROM cliente, estado
WHERE cliente.est=estado.cod;
■ SELECT * FROM v_cli_est

WHERE cli_cod=105;
UNIDAD 7.
GENERACIÓN DE APLICACIONES
Objetivo
Utilizar herramientas Oracle para generar bases de
datos y desarrollar aplicaciones.
- Control de usuarios
- Desarrollo de aplicaciones en Oracle
UNIDAD 8.
DISEÑO DE BASES DE DATOS
RELACIONALES
Objetivo
Aplicar las reglas de normalización de tablas en
bases de datos relacionales, propuestas por Cood y
otros.
1. DIFICULTADES EN EL DISEÑO
DE BD RELACIONALES
■ El DBMS no es suficiente, de ninguna
manera, para administrar una base de datos
relacional, en gran parte depende del DBA.
Para comenzar, debe aplicar las siguientes
restricciones cuando crea las tablas:
1 El orden de las filas no debe ser significante.
2 Orden de columnas no debe ser significante.
3 Cada intersección fila/columna debe
contener un valor simple del atributo.
4 Cada fila en una tabla debe ser distinta.
2. REDUNDANCIA VERSUS
DUPLICIDAD DE DATOS
■ Duplicidad.- La duplicidad de datos está
presente cuando un atributo tiene dos valores
idénticos, la duplicidad si está permitida. Al
borrar un datos repetido se pierde información.
p (p#, color) p (p#, color)
P1 rojo P1 rojo
p2 azul p2 azul
p3 rojo p3
!!PERDI LA INFORMACIÓN!!, QUE COLOR TIENE p3?

2. REDUNDANCIA VERSUS
DUPLICIDAD DE DATOS
■ Redundancia.- Un dato es redundante cuando
está repetido, esto es, se puede borrar sin
perder información, la redundancia no está
permitida en bases de datos, es 100%
responsabilidad del DBA evitar la redundancia.
sp (s#, p#, pnombre) sp (s#, p#, pnombre)
s2 p1 lápiz s2 p1 lápiz
s3 p1 lápiz s3 p1
s4 p3 borrador s4 p3 borrador
NO PIERDO LA INFORMACIÓN, p1 ES lápiz

3. REPETICIÓN DE GRUPOS
PRIMERA FORMA NORMAL
■ La primera forma normal tiene que ver con las
siguientes tres forma de almacenamiento de
datos en una tabla de una base de datos
relacional.
■ Repetición de grupos.- Mencionamos que cada
intersección fila/columna debe contener un
valor simple del atributo. Estas formas de la
tabla sp, no cumplen la primera forma normal:
sp (s#, snombre p# )
sp (s#, snombre p# ) s5 Aria p1
s5 Aria p1 s2 Baratillo p1
s2 Baratillo p1, p4 p4
s7 ABC p6 s7 ABC p6
s9 Tiluchi p8,p2,p6 s9 Tiluchi p8
p2
p6
■ Atributos separados.- Para evitar la repetición
de grupos podría crearse tres atributos p#_1a,
p#_2a, p#_3a, pero esto tampoco está
permitido por la 1FN, porque p# es un solo
atributo indivisible.
sp (s#, snombre p#_1a p#_2a p#_3a )
s5 Aria p1
s2 Baratillo p1 p4
s7 ABC p6
s9 Tiluchi p8 p2 p6
4. DETERMINANTES E
IDENTIFICADORES
■ Determinante o “atributo que tiene
dependencia funcional” .- Un atributo A es
determinante de otro atributo B, si cada valor
de A tiene precisamente un valor asociado de
B.
carnet_id combre_persona
Carnet_id es determinante de nombre_persona

porque un carnet tiene un solo nombre.
Y EN SENTIDO CONTRARIO?
4. DETERMINANTES E
IDENTIFICADORES
■ Diagrama de dependencias funcionales.- Es
posible generar un diagrama de dependencias
funcionales. Las otras reglas de normalización
se basan en estas dependencias funcionales,
por tanto el DBA si no tiene el diagrama debe
conocer a la perfección estas dependencias.
p_nombre
p#
cant_en_stock
4. DETERMINANTES E
IDENTIFICADORES
■ Determinantes compuestos.- A veces un grupo
de atributos son determinate de otro atributo.
factura# fecha_factura
artículo# cant_vendida
4. DETERMINANTES E
IDENTIFICADORES
■ Dependencias transitivas.- Si A determina a B
y B determina a C, por definición A determina
a C y se llama dependencia transitiva. Pero
esta última no es necesario representarla en el
diagrama, se sobreentiende.
A B C
factura# cliente# nombre_cli

4. DETERMINANTES E
IDENTIFICADORES
■ Identificadores.- Identificador de una tabla es
uno o más atributos que identifican
plenamente a una fila, además, debe tener la
mínima cantidad de atributos.
■ La regla que dice que no pueden haber dos
filas idénticas en una tabla, significa que toda
tabla tiene al menos un identificador. Algunas
tablas tiene varios identificadores.

5. FORMAS NORMALES, COOD
SEGUNDA FORMA NORMAL
■ “Una tabla no cumple la 2FN cuando un
atributo, que no sea identificador ni parte de
identificador, depende de una parte de un
identificador”.
parte# cantidad
bodega# dirección_bodega
SEGUNDA FORMA NORMAL
identificador, depende de una parte de un
identificador”. NORMALIZADO.
parte#
cantidad
bodega#
bodega# dirección_bodega
TERCERA FORMA NORMAL
identificador, depende de otro atributo que
tampoco es identificador ni parte de
identificador”.

TERCERA FORMA NORMAL
identificador, depende de otro atributo que
tampoco es identificador ni parte de
identificador”. NORMALIZADO.
factura# cliente#
cliente# nombre_cli
FORMA NORMAL DE BOYCE-COOD
■ Simplemente. “Una tabla está en FNBC si todo
determinante es un identificador”.
nombre_cliente
nombre_banquero
nombre_sucursal
OJO. !!DOS IDENTIFICADORES!!

FORMA NORMAL DE BOYCE-COOD
■ Simplemente. “Una tabla está en FNBC si todo
determinante es un identificador”.
NORMALIZADO.
nombre_cliente nombre_banquero
nombre_banquero nombre_sucursal
CUARTA FORMA NORMAL
■ La 4FN y 5FN tienen que ver con hechos
”multivalorados” , por ejemplo el empleado que
tiene muchos dependientes, o el empleado
que tiene muchas habilidades.
empleado# dependiente
empleado# habilidad
CUARTA FORMA NORMAL
■ Una tabla está en 4FN si cumple:
➦ No tiene dos o más hechos multivalorados
independientes
➦ Está en FNBC.
auto
empleado#
dirección
CUARTA FORMA NORMAL
■ Una tabla está en 4FN si cumple:
➦ No tiene dos o más hechos multivalorados
independientes
➦ Está en FNBC. NORMALIZADO
empleado# auto
empleado# dirección
QUINTA FORMA NORMAL
■ La 5FN tiene que ver con hechos
multivalorados dependientes como:
p#
s#
j#
■ Este tipo de tablas solo es posible
descomponer en otras más pequeñas, si
hacemos que las tuplas cumplan la condición:
si (sx,px,j1)∈spj y (sx,p1,jx)∈spj y (s1,px,jx)∈
spj entonces (s1,p1,j1)∈spj
QUINTA FORMA NORMAL
■ Si la tabla cumple la condición indicada:
si (sx,px,j1)∈spj y (sx,p1,jx)∈spj y (s1,px,jx)∈
spj entonces (s1,p1,j1)∈spj, entonces se
puede normalizar separando en tres tablas:
s# p# p# j#
s# j#
QUINTA FORMA NORMAL
■ Dependencia de junta.- Una relación r
satisface una dependencia de junta:
DJ*(x1, x2,....,xn), si es igual a la junta o
producto natural de sus proyecciones sobre
x1, x2,....,xn. Donde x1, x2,....,xn son
subconjuntos del esquema de r.
■ Una relación está en 5FN si tiene una
dependencia de junta DJ*(x1, x2,....,xn), y
cada una de las proyecciones de r sobre
x1,x2,..,xn, tiene como identificador un
identificador de r.
UNIDAD 9. BASES DE DATOS
ORIENTADAS A OBJETOS
■ Nuevas aplicaciones de las bases de datos
■ El modelo orientado a objetos
■ Lenguajes orientados a objetos
■ Lenguajes de programación persistentes
■ Sistemas C++ persistentes
UNIDAD 10. BD RELACIONALES
ORIENTADAS A OBJETOS
■ Relaciones anidadas
■ Los tipos complejos y la programación
orientada a objetos
■ Consultas con tipos complejos
■ Creación de valores y de objetos complejos
■ Comparación entre las bases de datos
orientadas a objetos y las bases de datos
relacionales orientadas a objetos
CONCLUSIÓN
PARTE II
ANÁLISIS Y DISEÑO
ESTRUCTURADO
Objetivos
■ Aplicar en detalle los conocimientos

científicos, capacidades técnicas y métodos
básicos, para el análisis y diseño
estructurado de sistemas de información.
■ Desarrollar un proyecto de ingeniería
referente a un sistema de información.
DEFINICIONES
❧ Análisis estructurado
● Deriva en un modelo estructurado de
requerimientos
❧ Diseño estructurado
● Desarrollo de un sistema computarizado,
como solución a un problema

OBJETIVOS DEL AE Y DE
❧ Mejorar la calidad del software y recudir el

riesgo de fallas.
❧ Permitie confiabilidad, flexibilidad,
facilidad de mantenimiento, eficiencia,
portabilidad y seguridad.
BENEFICIOS DEL AE Y DE
❧ Concentrarse sobre el propósito

fundamental del sistema
❧ Desarrollo de documentación del software
❧ Creación de un mapa del sistema
HISTORIA DEL ANÁLISIS
ESTRUCTURADO
❧ Structured Analysis Design Technique
● Douglas Ross
❧ Structured Design
● Tom DeMarco
HISTORIA DEL DISEÑO
ESTRUCTURADO
❧ Desarrollado en los 1970s
❧ Larry Constantine
❧ Edward Yourdon
❧ Diseño estructurado de procesos
❧ Michael Jackson y Jean Dominique Warnier
❧ Diseño estructurado de datos
1. INTRODUCCIÓN
❧ Concepto general de sistema

❧ Clasificación de los sistemas
❧ Sistemas automatizados. Clasificación.
❧ Principios generales de los sistemas.
❧ El análisis de sistemas.
2. PARTICIPANTES EN EL
ANÁLISIS DE SISTEMAS
❧ Usuarios.
❧ Dirección.
❧ Auditores, encargados de calidad y
estándares.
❧ Analistas de sistemas.
❧ Diseñador de sistemas.
❧ Programadores.
❧ Personal operativo.
3. TÉCNICAS DE ENTREVISTAS
Y RECOLECCIÓN DE DATOS
❧ Objetivos de una entrevista
❧ Tipos de entrevistas
❧ Guías para conducir entrevistas
❧ Posibles formas de resistencia en la
entrevista
❧ Problemas que hay que evitar
❧ Formas alternativas de recolectar
información
4. HERRAMIENTAS DE ANÁLISIS
ESTRUCTURADO
❧ Características de las herramientas
❧ Diagrama de flujo de datos
❧ Diagrama entidad relación
❧ Diagramas de transición de estado
❧ Diagramas de estructura
5. CICLO DE VIDA DE LOS
SISTEMAS
❧ Concepto de ciclo de vida de los proyectos
❧ El ciclo de vida clásico. Desventajas
❧ Ciclo de vida semiestructurado
❧ Ciclo de vida estructurado. Ventajas.
Formas de aplicación
❧ Ciclo de vida por prototipos
❧ Las herramientas CASE
6. ASPECTOS IMPORTANTES DE
LOS SISTEMAS
AUTOMATIZADOS
❧ Productividad
❧ Confiabilidad
❧ Facilidad de mantenimiento
❧ Eficiencia
❧ Portabilidad
❧ Seguridad
UNIDAD 3. PROCESOS DEL
ANÁLISIS
❧ El libro de Edward Yourdon fue escrito en 1989
● después de dos años de estudio y experiencias.
❧ Modelo esencial
● Modelo ambiental
● Modelo del comportamiento
❧ Implementación del modelo
13. EL MODELO ESENCIAL
❧ Dificultades en la identificación de
requerimientos
❧ El concepto de esencia del sistema
❧ Dificultades en la construcción de un
modelo
❧ Componentes del modelo esencial
14. EL MODELO AMBIENTAL
❧ Descripción del propósito del sistema

❧ Diagrama de contexto
❧ Lista de eventos
❧ Otros componentes del modelo ambiental
❧ Construcción del modelo ambiental
Diagrama de contexto
❧ Diagrama de flujo de datos de nivel alto
❧ Sistema en perspectiva del mundo real
❧ Simple caja negra con interfaces a fuentes
externas y usuarios
Diagrama de contexto
Monedas y
selección Soda en lata y cambio
El usuario Máquina monedera La máquina

de soda en lata
Soda en lata y cambio Monedas

Lista de eventos
❧ Vendedor llena máquina de soda en lata con soda
❧ Vendedor saca monedas de la máquina de soda en lata
❧ Vendedor aumenta cambio a máquina de soda en lata
❧ Usuario inserta monedas en la máquina de soda en lata
❧ Usuario selecciona el sabor de la soda
❧ Usuario saca la soda de la máquina de soda en lata
❧ Usuario saca su cambio de la máquina de soda en lata
Ejercicio
Caso de estudio
● Automatizar el sistema de control de inventario
para un almacén de salida de grandes cajas
(muebles, herramientas, abarrotes, etc.).
● Use el AE y el DE para modelar la situación
actual y determinar como puede ser
automatizado el sistema.
Ejercicio
Situation actual
● Cada dia, Ramona introduce los recibos de
ventas, en una hoja Excel que Renato generó.
● La hoja electrónica marca los ítems que deben
ser reordenados.
● Ramona escribe las órdenes de compra para
cada ítem que fue marcado.
● Cuando el ítem llega, Ramona introduce este en
la hoja electrónica.
Ejercicio
❧ Propósito del nuevo sistema

● Ramona está comenzando a fallar.
● Rosalva necesita más control sobre el sistema.
● Renato está comenzando a perder peso en la
organización, solo tiene tiempo para mantener
la hoja electrónica.
Ejercicio
Propósito del ejercicio:

● familiarizarse con lo que es un diagrama de
contexto, y poder desarrollar un sesión con
lluvia de ideas,
● evaluar las ventajas y desventajas de la técnica,
● determinar el criterio de entrada y salida en la
sesión de construcción del diagrama de
contexto.
Ejercicio
❧ Proceso
● Desarrollar el diagrama de contexto y discutir
el resultado.
❧ Símbolos
Sistema Interacciones Objectos externos

15. EL MODELO DEL
COMPORTAMIENTO
❧ Identificación de respuestas a los eventos

❧ Conexión de las respuestas
❧ Desarrollo del modelo inicial
❧ Nivelación de los DFDs
❧ Completando el diccionario de datos
❧ Completando las especificaciones del
proceso
❧ Refinamiento del diagrama entidad relación
16. EL MODELO A IMPLEMENTARSE
❧ Determinar los límites a automatizarse

❧ Determinar dispositivos de entrada y salida
❧ Formatos de entrada y salida
❧ Diseño de formularios
❧ Códigos de entrada y salida
❧ Identificar soporte manual adicional
❧ Especificación de restricciones de
operaciones
UNIDAD 2. HERRAMIENTAS
PARA MODELAR SISTEMAS
❧ Diagrama de flujo de datos DFD
❧ Diccionario de datos DD
❧ Especificación de procesos
❧ Diagramas entidad relación
❧ Diagramas de transición de estado
7. DIAGRAMA DE FLUJO DE
DATOS
❧ Componentes de los diagramas de flujo de
datos (DFD)
❧ Guías para la construcción de un DFD
❧ DFDs con niveles
❧ Extensiones de DFDs a procesos de tiempo
real
DATOS
❧ El diagrama de flujo de datos DFDs,
muestran la descomposición funcional,
con un énfasis en la transferencia de
datos dentro y fuera del sistema, y
entre unidades de programa.
DATOS
Componentes de los DFDs
❧ Notación (Yourdon/DeMarco)
Flujo
Proceso
Terminador
Almacén
DATOS
Guías para la construcción de un
DFD
❧ Como debe ser la notación de los DFDs?
● Flujo de dato: nombre-frase que describa el dato.
● Terminator: nombre o frase que describa el sistema,
agente, dispositivo, u otro, al que el dato entra, y donde el
dato existe en el sistema.
● Almacén de datos: nombre-frase del archivo, base de
datos o repositorio donde el sistema guarda el dato.
● Proceso: verbo-frase que describe la operación hecha
sobre el dato: puede contener el nombre de un sistema u
operación que manipula el dato.
DATOS
Guías para la construcción de un
DFD
❧ Donde comenzar?
● Diagrama de contexto
● Nivel cero del DFD
Monedas y

de soda en lata

DATOS
DFDs con niveles
❧ Como continuar?
● Descomponer los procesos en niveles más y más
bajos hasta que estén listos para representar
diseño detallado.
● Cada DFD debería tener entre 3 y 9 procesos.
● La descripción de procesos primitivos se llama
“especificación de procesos” o
“miniespecificaciones”, usualmente se representa
en seudocódigo.
DATOS
DFDs con niveles
Monedas y

de soda en lata
Monedas Cambio
Monedas Cambio coloca
Cambio cuenta Momedas
Deposito saca
Soda lata Monedas
Selección
Congelador
Soda lata Sodas lata Sodas lata
despacha carga
DATOS
DFDs con niveles
❧Terminador Vs. Almacén:
Un terminador (fuente de datos o basurero)
está fuera de la frontera del sistema en
análisis; un almacén de datos está dentro
y bajo el control del sistema objeto de
análisis.
Terminador Almacén
DATOS
DFDs con niveles
Y
X F
a f2 c f6
f h
X f1 f4 e Y
b d
f5 g f7
f3
c c1 f42
f41 c2 e
d d1 d2 f43
f44 f45
DATOS
DFDs con niveles
❧Balanceo :
● Los “datos de entrada” del nivel hijo,
deben ser idénticos a los “datos de
entrada” del nivel padre.
● Los “datos de salida” del nivel hijo,
deben ser idénticos a los “datos de
salida” del nivel padre.
DATOS
DFDs con niveles
❧ Consideraciones prácticas:
● Cada símbolo debe ser etiquetado.
● No hay procesos sin flujos de datos de
entrada.
● No hay procesos sin flujos de datos de
salida.
● Los datos no fluyen diréctamente entre
datos fuente, basureros o almacenes.
● Los niveles deberían ser balanceados.
DATOS
DFDs con niveles
❧ Sumario de DFD:
● Se centra en aspectos funcionales
del sistema:
• Qué funciones debe ejecutar el sistema?
• Cuales son las interacciones entre estas
funciones?
● Representar el DFD en niveles es
una técnica “Top down”.
8. DICCIONARIO DE DATOS
❧ Necesidad de una notación
❧ Notación: definiciones, datos elementales,
datos opcionales, iteracción-selección-alias
❧ Como mostrar el diccionario de datos al
usuario
❧ Implementación del Diccionario de Datos
❧ Es un repositorio de descripciones
detalladas referentes a varias construcciones
que aparecen el cada DFD.
❧ No hay un formato formal, pero cada
construcción debería tener una entrada en el
Diccionario de Datos.
❧ Muchas de las herramientas CASE proveen
el Diccionario de Datos en forma
automática.
❧ Describir por cada entrada:
● Tipo(Flujo de datos, Almacén de datos,Terminador,
Proceso)
● Nombre
● Alias
● Descripción
● Contenido
❧ Un ejemplo:
● Tipo: Flujo de dato
● Nombre:Cambio
● Alias:
● Description:
Fdesde el proceso “coloca” hasta el almacén
de datos “depósito” …...
● Contenido: …….
9. ESPECIFICACIÓN DE
PROCESOS
❧ Lenguaje estructurado
❧ Pre/post condiciones
❧ Tablas de decisión
❧ Gráficos y diagramas
❧ Diagramas de flujo
❧ Diagramas Nassi-Shneiderman
PROCESOS
❧ Son las especificaciones de los procesos
primitivos, o mini-especificaciones.
● Los pasos esenciales de tipo procedural, para
lograr la acción necesaria de un proceso
primitivo.
● Tipos de acción: secuencial, paralela, decisión e
iteracción.
● Español estructurado, árbol o tabla de
decisiones, o seudocódigo…
PROCESOS
Monedas Cambio
Deposito saca
Soda lata Monedas
Selección
Congelador
despacha carga
Especificación de proceso: cuenta

Inicio:
Hacer{
Obtener moneda
}hasta (total >= requirido);.
Informa proceso “despachar”;
if (total > requirido)
Return cambio:
End;
Ejercicio: DFD
Propósito del ejercicio:

● familiarizarse con lo que los DFDs son, y
conococer como se obtiene este a partir del
diagrama de contexto.
● Descubir el propósito del diseño en varios
niveles.
Ejercicio: DFD
❧ Crear un DFD y su diccionario de datos a

partir de tu diagrama de contexto.
● Partir el diagrama de contexto en al menos 3
burbujas.
● Escoger una burbuja del primer nivel y partirla
en otras, y así sucesivamente.
❧ Grupos de discución:
● Compare / contraste los DFDs con Casos de
Uso.
10. DIAGRAMAS ENTIDAD
RELACIÓN
❧ Componentes de un diagrama entidad

relación
❧ Guías para la construcción de un diagrama
entidad relación
❧ Extensiones del diccionario de datos para
los diagramas entidad relación
RELACIÓN
❧ Qué es?
● Una herramienta para modelamiento de datos.
● Por P. Chen’s modelo ER (1976).
● El modelo ER ha sido usado ampliamente en el
diseño de bases de datos.
❧ Porqué el diagrama ER?
RELACIÓN
❧ Construcción del diagrama ER

● Entidad
● Relación
● Atributo(Propiedad)
RELACIÓN
❧ Entidad
● Una entidad en ER representa un objeto del
mundo real
Entity Name
RELACIÓN
❧ Relación
● Una relación define como se relacionan las
entidades, es representada por un rombo.
Fuente Relación Destino

RELACIÓN
❧ Cardinalidad y participación. !YA VIMOS!

RELACIÓN
Paciente
1 1
Genera
1-n tiene 1-n
1-n
Visita tiene
1 estudio 0-n
1- 1 Resultados
includes
n contiene
1
1-n
1 contiene
contiene Series
0-1
1
0-n contiene Reporte
imagenes 0-n
resultados
11. DIAGRAMA TRANSICIÓN DE
ESTADO
❧ Notación y componentes
❧ Diagramas particionados
❧ Construcción de diagramas de transición de
estado
❧ Relación con otras herramientas de
modelación
ESTADO
❧ Qué son?
● Herramientas para definir el comportamiento
del modelo
● Un estado es:
“Un set de circunstancias o atributos que
caracterizan a una persona o cosa en un momento o
tiempo dado; camino o forma en que existe;
condición.”
❧ Aplicación
● Sistemas que dependen del tiempo
ESTADO
Notación y componentes
Estado o Estado
❧ Símbolos
condición
acción
Transición de estado
– Estados
■ corresponde a estados observables del sistema
■ estados inicial y final
– Condiciones y acciones
– Diagramas particionados
ESTADO
Construcción diagramas transición de
estado
Espera Producto vendido

monedas Da cambio si hay
Rechaza botón Suficiente dinero

presionado insertado Vende
Retorna moneda producto
insertada
Espera
Selección hecha
selección
ESTADO
Construcción diagramas transición de
estado
❧ Guía para la construcción

● definir primero todos los posibles estados
● definir el estado inicial y obtener todas las
transiciones
❧ Verificación y completitud
● todos los estados deben ser definidos
(incluyendo errores)
● todos los estados deben ser representados
● todo estado final debe tener un sucesor
ESTADO
Relación con otras herramientas
❧ Relación con otras herramientas

● especificación de procesos para control de
burbujas de DFD
• condiciones == aferente (de entrada) flujo de control
• acciones == eferente (de salida) control de flujo
● puede ser especificación de proceso para el
sistema completo (diagrama de contexto)
ESTADO
Pros y contras
❧ Pros
● provee alto detalle para la implementación
● provee buena documentación para aspectos
dependientes del tiempo en el sistema
❧ Contras
● mucho esfuerzo de diseño requerido
● asume que los estados de transición son
instantaneos
● puede resultar muy complejo
11. RELACIÓN ENTRE DISTINTAS
HERRAMIENTAS
❧ Balance del DFD contra el DD
❧ Balance del DFD y las especificaciones de proceso
❧ Balance de las especificaciones de proceso contra
el DFD y el DD
❧ Balance del DD contra el DFD y las
especificaciones de proceso
❧ Balance del DER contra el DFD y las
especificaciones de proceso
❧ Balance del DFD contra el diagrama de estado de
transición
UNIDAD 4. ETAPAS
POSTERIORES AL ANÁLISIS
17. EL DISEÑO DE SISTEMAS
❧ Asignación de procesadores
❧ Asignación de tareas
❧ Implementación de tareas por programas
❧ Diagramas de estructura
❧ Cohesión
❧ Acoplamiento
❧ Diseño basado en la transformación central
❧ Diseño basado en las transacciones
Diagrama de estructura
❧ Qué son ellos?

● Herramienta para ayudar a definir la
implementación del modelo
● modularizar vistas del sistema
● originalmente fue la principal herramienta
del diseño estructurado
❧ Aplicaciones
● vista general para desarrolladores y
diseñadores
❧ Símbolos de módulo
Módulo
Módulo
Predefinido
Llamada a módulo
❧ Símbolos de comunicación
● Dato de acople
nombre
• procesado
emisor receptor
• externamente relevante
● Bandera nombre
• seteado y probado
emisor receptor
• internamente relevante
❧ Modulos
● nombrado por un verbo sentencia, describe un
procesamiento
❧ Dato
● nombrado con un nombre.
❧ Bandera descriptiva
● nombrada por un adjetivo, descripción de estado
❧ Bandera de control
● nombrada por un verbo.
Vende
soda
Suficientes en lata Producto
nonedas seleccionado
Producto moneda
seleccionado
Obtener Lee
Obtiene Entrega
suficientes producto
cambio producto
fondos seleccionado
monedas Monedas >= selección
monedas cant. necesitada
Verifica
Recibir Lee
suficiente
monedas selección
fondo
❧ Módulos
● necesitan funciones bien definidas e interfaces
● Deberían ser relativamente pequeños (10-100 LOC)
❧ Banderas
● reducir banderas de control (indican pobre partición)
❧ Relación con otras herramientas
● muy relacionados con DFDs
● DFD a diagramas de estructura por transformación
del análisis
❧ Pros
● vista gráfica de alto nivel
● se concentra sobre los aspectos “caja-negra” de
los módulos
● Permite subjetividad
❧ Contras
● puede ser difícil crearlo
● puede volverse muy subjetivo
Ejercicio: Diagrama de estructura
❧ Porpósito del ejercicio:

● introducir los conceptos de transacción y
transformación del análisis,
● familiarizarse con el diagrama de estructura.
❧ Transformar una transacción en tu DFD del
ejercicio en un diagrama de estructura para
esa transacción.
❧ Diagrama de estructura
● Tomado de Page-Jones:
“The Practical Guide to Structured System Design”
● Objetivo: crear un jerárquico y bien balanceado
sistema
• módulos top trabajan con datos limpios y refinados
• módulos bottom trabajan con datos crudos y no
editados
❧ Identificar transacciones en DFD
❧ Para cada transacción, identificar la “transformación
central”
● inspección o,
● aislar flujo de datos esencial o,
● seguir criterio “mundo ideal”
❧ Producir primer diagrama de estructura
● identificar o crear un módulo “jefe”
● convertir datos e ítems de control en datos acoplados y flags
● Partir las burbujas del DFD en una jerarquía de módulos
funcionales, llamados desde el módulo “jefe”
Ejercicio: Diagrama de estructura.
Identificar la transformación central
❧ Inspección
● Visualmente inspeccionar el DFD e identificar lo que
“parece” la transformación central
❧ Aislar flujos de datos esenciales
● Marcar el punto entre flujos de datos aferentes
(input) y eferentes (output), donde los datos han sido
refinados pero no transformados, las burbujas que
están dentro son la transformación central
❧ “Mundo ideal”
● Remover algunas burbujas mediante manejo central
de errores y formateo de datos, dejar las burbujas que
Ejemplo
Monedas y

de soda en lata
Monedas Cambio
Deposito saca
Soda lata Monedas
Selección
Congelador
despacha carga
Ejemplo
Vende
soda
Suficientes en lata Producto
nonedas seleccionado
Producto moneda
seleccionado
Obtener Lee
Obtiene Entrega
suficientes producto
cambio producto
fondos seleccionado
monedas Monedas >= selección
monedas cant. necesitada
Verifica
Recibir Lee
suficiente
monedas selección
fondo
Cohesión
❧ Medida de la fuerza de asociación de los

elementos de un módulo
❧ Niveles
● funcional best
● secuencial
● comunicacional
● procedural
● temporal
● logico
worst
● coincidental
Acoplamiento
❧ Medida de la interdependencia de los

módulos
❧ Tipos best
● normal
• datos
• estampilla
• control
● común worst
● contenido
Especificaciones
❧ Muchos métodos potenciales

❧ Interface y especificaciones funcionales
● dan un buen balance de detalle de especificación
● proveen módulo general de documentación
● menos detalles de implementación
❧ Seudocódigo
● Alto detalle, menos errores potenciales
● puede resultar muy abundante en palabras
18. PROGRAMACIÓN, PRUEBAS,
CONVERSIÓN, INSTALACIÓN Y
ENTRENAMIENTO
❧ El papel del analista en la programación y

prueba
❧ Organización del trabajo de programación
❧ Programación y lenguaje de programación
❧ Aspectos importantes de la programación
❧ La prueba de programas
❧ Instalación
❧ Entrenamiento
Conclusión

Programacion de &#39;Bases de Datos1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Programacion de &#39;Bases de Datos1

Cargado por

Copyright:

Formatos disponibles

BASES DE DATOS

■ Usar en forma detallada las técnicas

■ Un sistema de manejo de Bases de

■ El objetivo del DBMS es crear un ambiente

■ Los DBMS minimizan los problemas de los

■ Los DBMS proporcionan a los usuarios una

■ Para ocultar esta complejidad del

■ La colección de la información almacenada

■ Es la capacidad de modificar una definición

■ Para describir el esquema de una base de

■ Parten de mundo real delimitando el

■ Se basa en la percepción de un mundo

persona posee automóvil ocurrió accidente

■ Está basado en una colección de objetos agrupados

CuentaCorriente Acción Bono Propiedad

■ Se usan para describir los datos en los

■ Los datos y las relaciones entre ellos se

■ Se representa por un conjunto de registros y

■ Igual que el de red pero en forma de árbol

■ El modelo de datos físico se usa para

Interfaces de Programas consulta Esquema de

Precompilador Compilador Intérprete de

Gestor de Gestor de Gestor de

DBMS Índices Datos estadísticos Almacena-

■ Lenguaje de definición de datos DDL, es

■ Una transacción es una colección de

■ El gestor de transacciones asegura las

■ Hay 4 tipos de usuarios en un sistema de

■ Entidad.- Es una cosa que puede ser

■ Entidades, relaciones y ocurrencias.

Entidades.- agencia, producto

■ Identificador de entidad.- Es un atributo

Un departamento debe emplear al menos un empleado

departamento emplea empleado

Un departamento no necesita emplear ningun empleado

Un departamento no necesita emplear ningún empleado

departamento emplea empleado

Un departamento debe emplear al menos un empleado

Me sacás el departamento donde trabaja el empleado e1?

Hola?. Quién habla?.

Hola, quien habla?

Y ahora quien será. Hola, quien habla?

secretaria técnico administrador asalariado horario

■ Esqueleto del ER.- Es el diagrama

empleado(nro_emple, ....., nro_auto, .....)

empleado (nro_emple, .......)

sala (nro_sala, .......)

sala (nro_sala, .......)

profesor (nro_profe, .......)

persona (ci, nombre,...)

■ Entidad débil o identificador prepuesto.-

compañia (nro_depto, .......)

■ Las reglas de representación de relaciones

persona (persona_id, ........)

Empleado (nro_empleado, ......., nro_emple_supervisor)

Parte (nro_parte, .......)

■ El próximo paso después de hacer el

■ 1:1 no obligatorio en ambas entidades.

empleado (nro_emple, nom_emple, km_emple )

■ 1:m no obligatorio en entidad m.

sala (nro_sala, tipo_sala, número_camas )

■ m:n en todos los casos.

profesor (nro_prof, nro_aula, horas_prof_sem )

■ Las tablas obtenidas en el diseño

Programacion de 'Bases de Datos1

Programacion de 'Bases de Datos1