Conceptos BD

Conceptos sobre
BASE DE DATOS
PROFESOR
Dr. Juan Fco. Corona Burgueo
INTRODUCCIN A LA BASES DE
DATOS
Buenas decisiones requieren buena informacin, la cual se obtiene de datos
almacenados en una base de datos accesados por medio de un sistema
manejador de la base de datos.
Datos: son hechos crudos referentes a gente, objetos, eventos u otras
entidades; por ejemplo, una coleccin de respuestas individuales a una encuesta
de mercado.
Informacin: son datos que han sido procesados y presentados en una forma
adecuada para la interpretacin humana, frecuentemente con el propsito de
revelar tendencias y patrones; por ejemplo, los datos del ejemplo de la encuesta
de mercado se analizaran y resumiran utilizando mediciones estadsticas tales
como medias, rangos y desviaciones estndar.
Base de datos: es una estructura computacional integrada y

compartida que contiene:
Datos de inters para los usuarios.
Metadatos, es decir, datos sobre los datos que
describen las caractersticas de los datos as como las
relaciones que vinculan los datos en la base de datos.
Sistema Manejador de Base de Datos (DBMS) (DBMS:
Database Management System): es una coleccin de
programas que permite a los usuarios crear, mantener y
controlar el acceso a los datos en una base de datos.
Estructura de la base de datos

Metadatos
Clientes
Datos
del
usuario
final
Inventario
Facturas
Productos
SMBD
Sistema Manejador
de Base de Datos
Datos
Datos
Consulta
Usuario final
Consulta
Usuario final
El SMBD administra la interaccin entre el

usuario final y la base de datos
Evolucin del concepto Informacin

Los sistemas de informacin de los 50s se enfocaban a reducir el costo del
proceso rutinario de papel, especialmente en la Contabilidad.
Los sistemas de informacin de los 60s y 70s se enfocaron a la generacin de
reportes de todo tipo (produccin mensual, informacin financiera mensual,
inventarios, cuentas por pagar, cuentas por cobrar, etc.). Se apoyaban varias
funciones dentro de la organizacin, ya no slo la Contabilidad.
Para la mitad de los 70s y los 80s, los sistemas de informacin se concibieron
como para proveer control administrativo especfico. Son los llamados DSS
(Decision Support System) y los EIS (Executive Information Systems). Su
propsito fue mejorar el proceso de toma de decisiones de gerentes para un rango
grande de problemas.
Para los 90s la informacin es considerada un recurso estratgico. Como tales,
los sistemas de informacin deben asegurar la supervivencia y prosperidad de la
organizacin.
SISTEMAS DE ARCHIVOS
La facilidad que dieron las computadoras para grabar datos dentro
de unidades de almacenamiento secundario, aceler el uso de
ellas para aplicaciones administrativas como cuentas por pagar,
cuentas por cobrar, nmina, inventarios, contabilidad, etc. Al
principio los datos se guardaron en la misma disposicin o forma
como se guardaban manualmente, lo que trajo como consecuencia
una mala administracin de ellos. En consecuencia, una nueva
clase de profesionista prolifer, a saber, los especialistas en
procesamiento de datos (DP). Ellos fueron los encargados de crear
las estructuras de los archivos, as como el software para su
administracin, naciendo de esta forma los sistemas de archivos.
Terminologa
Dato: hechos crudos que tiene poco significado que por

si solos no tienen valor.
Campo: un carcter o grupo de caracteres que tienen un
significado especfico.
Registro: un conjunto de uno o ms campos relacionados
lgicamente que describen a una persona, lugar o cosa.
Archivo: una coleccin de registros relacionados.
Ejemplo: archivo CUSTOMER
C_NAME
Juan Prez
Mara Rodrguez
Pablo Martnez
C_PHONE
123-4567
776-3565
743-0395
C_ADDRESS
Jurez 461
Hidalgo 294
Zapata 432
C_ZIP AGENT A_PHONE

38700 Pedro Lpez 234-7123
52926 Luis Garca 734-0193
85345 Pedro Lpez 234-7123
TP AMT REN_DATE
T1 100 01/05/1998
T2 2000 14/02/1998
T2 500 16/01/1999
El especialista en DP escriba programas para, por ejemplo:
Resmenes mensuales de ventas para ver productividad.

Reportes mensuales para identificar las renovaciones.
Evolucin de los sistemas de archivos
Se crearon nuevos archivos.

Se requirieron nuevos reportes y por ende, nuevos programas.
Otros departamentos crearon sus propios archivos y
aplicaciones.
Se crearon los sistemas de archivos.
Se contrataron ms especialistas en DP.
Se cre el puesto de Gerente de DP.
Componentes de un Sistema de Archivos
Hardware: la computadora
Software: el sistema operativo, las utileras, los archivos,
los programas para la administracin de archivos y los
programas de aplicacin que generan los reportes de los
datos almacenados en los archivos.
Personas: los gerentes o administradores y los especialistas
en DP, los programadores y los usuarios finales.
Procedimientos: las instrucciones y reglas que gobiernan el
diseo y el uso de los componentes de software.
Datos: la coleccin de hechos.
Para qu estudiar los sistemas de archivos?
Entender sus limitaciones nos permite entender mejor las

razones para el desarrollo de las bases de datos.
Evitar cometer los mismos errores.
Desventajas de un sistema de archivos

Consisten, principalmente, en la administracin de los archivos.
Programacin extensa en lenguajes de 3ra. Generacin (3GL: requiere que el programador
especifique que es lo que se quiere y como obtenerlo).
COBOL: Common Business-Oriented Language.
BASIC: Beginners All-purpose Symbolic Instruction Code.
FORTRAN: FORmula TRANslation.
Si el nmero de archivos crece, la administracin se dificulta, ya que se necesitan 5 programas
por archivo para su mantenimiento.
Crear la estructura del archivo.
Agregar datos al archivo.
Borrar datos del archivo.
Modificar datos del archivo.
Listar los datos del archivo.
Es complicado modificar un campo o registro o agregar otro dentro de la

estructura de un archivo.
Dependencia estructural: modificar la estructura de un archivo obliga a
modificar todos los programas que utilizan los datos en ese archivo, en
otras palabras, el acceso a un archivo depende de su estructura.
Dependencia de datos: cambiar las caractersticas de los datos (entero a
decimal, por ejemplo) obliga a cambiar los programas que utilizan esos
datos.
Mucho tiempo se dedica a la depuracin.
Es difcil incorporar medidas de seguridad, por lo tanto la integridad y
confidencialidad de los datos est en riesgo.
No se pueden responder consultas ad-hoc.
Duplicacin de datos: los mismos datos se almacenan en diferentes
localidades o archivos.
Redundancia de datos: ms tiempo en la captura de datos y se requiere ms

espacio para almacenamiento.
Inconsistencia de datos (prdida de la integridad de los datos).
Las modificaciones no se hacen en todos los lugares.
Errores de dedo al capturar los datos.
Nombres o valores inexistentes.
Anomalas de datos
Modificaciones: se hacen en todos los registros o campos en donde aparece el
dato.
Insercin: si se quiere capturar parte de un registro (por ejemplo, datos de un
cliente), tambin hay que capturar el resto del registro (por ejemplo, el agente
que atiende al cliente)
Eliminacin: si se elimina parte de un registro (por ejemplo, un agente
renuncia), entonces el registro queda incompleto (por ejemplo, un cliente no
tiene quien lo atienda).
Resumiendo
Los sistemas de archivos no son

adecuados para los requerimientos
modernos de informacin.
BASE DE DATOS
Es una coleccin de datos interrelacionados y almacenados en

conjunto, sin redundancias perjudiciales o innecesarias.
Su finalidad es la de servir a una o ms aplicaciones de la mejor
manera posible.
Los datos se almacenan de modo que resulten independientes de
los programas que los usan.
Se emplean mtodos bien determinados para incluir datos nuevos
o para modificar o extraer datos almacenados.
SISTEMA MANEJADOR DE BASE DE DATOS (DBMS)

Es un software que organiza y recupera los datos almacenados en una base de
datos. Facilita el acceso a todo tipo de datos. Permite que el usuario accese los
datos como el los ve y no como estn almacenados fsicamente.
Funciones normales de un DBMS actual
1. Diccionario de datos: almacena las definiciones de las caractersticas de los
datos y las relaciones entre ellos (metadatos). Se eliminan las dependencias
estructurales y de datos.
2. Administracin del almacenamiento de los datos : Crea las estructuras
complejas necesarias para el almacenamiento de los datos.
3. Transformacin y presentacin de los datos : transforma los datos capturados
para que coincidan con la estructura del punto 2.
4. Seguridad: crea un sistema de seguridad y fuerza su cumplimiento.
5. Control de acceso mltiple: crea las estructuras complejas que permiten a

mltiples usuarios accesar los datos.
6. Respaldo y recuperacin: provee procedimientos de respaldo y recuperacin
que garantizan la seguridad e integridad de los datos.
7. Integridad de datos: promueve y obliga el cumplimiento de reglas de
integridad, eliminando problemas de integridad de los datos y permitiendo as
minimizar la redundancia de datos y maximizar la consistencia de los mismos.
8. Lenguajes de acceso a la base de datos e interfaces de programacin de
aplicaciones (API): provee acceso a los datos por medio de lenguajes de
consulta as como tambin por medio de lenguajes procedurales (3GL).
9. Interfaces de comunicacin para la base de datos: permite que la base de
datos acepte solicitudes de usuarios dentro de una red computacional.
Consecuentemente, el papel del especialista o gerente de DP cambia de poner

nfasis en la programacin a poner ms atencin en los ms amplios
aspectos administrativos relativos a la organizacin de los recursos de datos
y en la administracin del mismo complejo software de la base de datos. De
esta manera surge el puesto de Administrador de Sistemas, cuyas
responsabilidades son:
Evaluacin de diseos de bases de datos.
Mantenimiento del software de la base de datos.
Asigna los derechos de uso de la base de datos a individuos.
Coordina el desarrollo de aplicaciones basadas en los recursos de datos.
Si los recursos de datos requieren el uso de ms de una base de datos, el
administrador de sistemas puede nombrar a un administrador de la base de
datos.
Principales partes que componen un

Sistema de Base de Datos
Hardware: la computadora, los dispositivos de entrada y salida y el equipo de
comunicacin en red.
Software:
Sistema Operativo (OS).
Sistema Operativo de la Red (NOS).
Sistema Manejador de la Base de Datos (DBMS).
Aplicaciones de la base de datos y utileras.
Gente: administrador del sistema, administrador de la base de datos, programadores y
usuarios finales.
Procedimientos: las instrucciones y reglas que gobiernan el diseo y uso de la base de
datos.
Datos: la coleccin de hechos almacenados en la base de datos, inclusive los metadatos.
Quien es quien en un sistema de base de datos

Administrador de la base de datos: administra la base de datos, el SMBD
y el software con l relacionado. Se encarga de autorizar el acceso a la
base de datos, de coordinar y vigilar su empleo y de adquirir los recursos
necesarios d e software y de hardware. Es responsable cuando surgen
problemas como violaciones a la seguridad o una respuesta lenta del
sistema.
Diseadores de la base de datos: se encargan de identificar los datos que
se almacenarn en la base de datos y de elegir las estructuras apropiadas
para representar y almacenar dichos datos. Por lo general, estas tareas se
realizan antes de que de hecho se implemente la base de datos. Los
diseadores tienen la responsabilidad de comunicarse con todos los
futuros usuarios de la base de datos, a fin de comprender sus necesidades
y de presentar un diseo que satisfaga sus requerimientos.
Usuarios finales: son las personas que necesitan tener acceso a la base de
datos para consultarla, actualizarla y generar informes; la base de datos existe
primordialmente para ellos.
Espordicos: accesan la base de datos de vez en cuando y es posible que
requieran informacin diferente en cada ocasin. Utilizan un lenguaje de
consulta de base de datos; suelen ser gerentes de nivel medio.
Simples o paramtricos: utilizan transacciones programadas oprimiendo
slo un botn.
Avanzados: desarrollan aplicaciones como CAD, Sistemas expertos y
Anlisis estadstico para satisfacer sus complejos requerimientos.
Autnomos: emplean bases de datos personalizadas gracias a los paquetes
comerciales que cuentan con interfaces de fcil uso, basadas en mens o en
grficos.
Analistas de sistemas y programadores de aplicaciones: los

primeros determinan los requerimientos de los usuarios
finales, sobre todo los de los paramtricos y desarrollan
especificaciones para transacciones programadas que
satisfagan dichos requerimientos. Los programadores de
aplicaciones implementan esas especificaciones en forma de
programas y luego prueban, depuran, documentan y
mantienen estas transacciones programadas.
Deben conocer a la perfeccin toda la gama de capacidades
del SMBD.
Diseo y modelado de la base de datos
El diseo de la base de datos es una de las actividades cruciales

en un ambiente de base de datos. El crear las clases de
estructuras necesarias dentro de la base de datos as como sus
relaciones juegan un papel muy importante en determinar el
desempeo que tendr el sistema manejador de la base de
datos. El diseo de la base de datos se vuelve ms sencillo si
se usan los modelos. Modelos son simples abstracciones de
condiciones o eventos del mundo real.
Por qu es tan importante el diseo de la

base de datos?
Un mal diseo tiende a generar errores los que pueden conducir a
malas decisiones. Organizaciones que utilizan bases de datos
pobremente diseadas, con frecuencia fallan porque sus
gerentes no tienen acceso, de manera oportuna, a la
informacin necesaria; en ocasiones, inclusive, la informacin
no es correcta.
Modelos de base de datos

Un modelo de base de datos es una coleccin de construcciones
lgicas usadas para representar la estructura de datos y sus
relaciones dentro de la base de datos.
Bsicamente los modelos de base de datos estn agrupados en dos
categoras:
Modelos conceptuales o de alto nivel: es la representacin lgica
de los datos y su enfoque es ms bien en el qu est representado
y no en el cmo est representado.
Modelos de implementacin o de representacin: su enfoque es
en como se van a representar los datos dentro de la base de datos
o como se implementan las estructuras de datos para representar
lo que se modela.
Relaciones o vnculos (relationship)

Los modelos conceptuales usan tres tipos de relaciones para
describir las asociaciones entre los datos.
Uno a uno (1:1): cada entidad de un conjunto est
asociada con una y slo una entidad del otro conjunto
Paciente
Esposa
Cama
Esposo
Uno a muchos (1:M): cada entidad de un conjunto puede

estar asociada con varias (muchas) entidades del otro
conjunto.
Pintor
Pinturas
Cuarto
Paciente
Muchos a muchos (M:N): cada entidad de un conjunto

puede estar asociada con varias entidades del otro conjunto
y viceversa, es decir, cada entidad del otro conjunto puede
estar asociada con varias del primer conjunto.
Empleado
Habilidad
Curso
Estudiante
Modelos de Implementacin
Modelo de Base de Datos Jerrquica.

Modelo de Base de Datos de Red.
Modelo de Base de Datos Relacional.
Modelo Jerrquico
Antecedentes. North American Rockwell fue el primer contratista para el
proyecto Apolo, que culmin en el viaje tripulado a la luna en 1969. El
xito de este proyecto requiri la administracin de millones de partes.
Despus de esto se vio la necesidad de tener algo mejor que un sistema
de archivos ya que se requera administrar los datos, en los cuales
tenan una gran cantidad de redundancia.
Cuando la North American Rockwell empez a desarrollar su propio
sistema de base de datos, la coleccin de cintas computacionales
revel que ms del 60% de los datos eran redundantes. Tomando algo
de los conceptos existentes de base de datos, se desarroll el software
conocido como GUAM (Generalized Update Access Method).
El GUAM estaba conformado por arreglos ordenados en forma de rbol

de arriba abajo. A ese conjunto de arreglos ordenados se le conoci
como Estructura Jerrquica.
A mediados de los 60s, IBM y North American Rockwell se unieron para
expandir las capacidades del GUAM, reemplazando el medio de
almacenamiento de cintas a discos, el cual permiti introducir un
complejo sistema de apuntadores.
El resultado de la unin de IBM y North American Rockwell se comenz
a conocer como el Information Management System (IMS). El
desarrollo y comercializacin por parte de IBM dio un gran golpe a
sus competidores y comenz a dominar el mundo con su sistema de
base de datos jerrquico para los 70s y principios de los 80s.
JERRQUICO
CLIENTES
1:M
FACTURAS
1:M
DETALLE DE
FACTURAS
Segmento Raz
1:M
PAGOS
Segmento
Nivel 1
Cliente
No._CTE
Nombre_CTE
Dir_CTE
Factura
No._FAC
Fecha_FAC
Monto_FAC
1276
Roberto Snchez
Jurez 328, Mxico, D.F.
102
26/01/1998
54.25
Detalle Factura
Artculo
Pistola soldar
Precio
34.25
Cantidad
1
1345
23/12/1997
150.00
Broca
15.00
1
Clavos
5.00
20
Pago
No._PAG
Fecha_PAG
Monto_PAG
Ventajas del Modelo Jerrquico

La antigedad del Modelo Jerrquico da testimonio de su fuerza
Ya que todos los datos estaban contenidos en una base de datos
comn, es prctico el compartir datos; el DBMS se encargaba de la
seguridad.
El DBMS creaba un ambiente en el cual la independencia de datos
poda ser mantenida, por eso los esfuerzos de programacin y el
mantenimiento se vieron sustancialmente disminuidos.
Dada la relacin padre/hijo en el modelo jerrquico, hay siempre una
liga entre el segmento padre y el segmento hijo(s). Desde entonces el
segmento hijo es siempre, automticamente, referenciado por el padre.
El modelo jerrquico fomenta una condicin conocida como
integridad de la base de datos.
El Modelo Jerrquico ofrece ser muy eficiente cuando una

base de datos contiene un gran volumen de datos en relacin
1:M y cuando el usuario requiere un gran nmero de
transacciones que utilizan datos cuyas asociaciones no
cambian con el tiempo.
La base instalada (mainframe) actual es grande.
Consecuentemente, programadores quienes conocen el
sistema, tienden a estar disponibles.
Hay una gran cantidad de aplicaciones para negocios, dignas
de confianza dentro de ambientes de mainframe.
Desventajas del Modelo Jerrquico

Aunque existe una gran base instalada de aplicaciones para el Modelo
Jerrquico, este ya no es considerado como una primera opcin.
Aunque los DBMS jerrquicos aliviaban a los programadores del
problema de dependencia de datos, el DBMS todava requiere
conocimiento del nivel fsico de almacenamiento de los datos. Cualquier
cambio en la estructura de las bases de datos, tal como la reubicacin de
un segmento, an requiere cambios en todos los programas de aplicacin
que accesen la base de datos. Por lo tanto, la implementacin de un
diseo de una base de datos suele ser muy complicada.
Muchas relaciones comnmente no son del tipo 1:M, adecuadas para el
modelo jerrquico, sino por relaciones M:N, como la relacin entre
cursos y alumnos en una universidad.
En el mundo real hay muchas relaciones basadas en un hijo con muchos padres. Por
ejemplo, un estudiante puede estar inscrito en varias clases.
Tiende a ser compleja su administracin y no es muy flexible.
La programacin de aplicaciones es extensa y compleja. El programador debe saber
codificar comandos de control para accesar los datos y debe estar familiarizado con
la estructura de la base de datos para poder navegar al segmento deseado.
No incluye herramientas para explotar informacin de forma fcil (generadores de
aplicacin, facilidades para consultas interactivas, etc.), estas deben ser invocadas
por separado.
No existe un modelo terico que sustente los conceptos del modelo jerrquico.
Adems, no hay estndares precisos para su diseo e implementacin.
La base de datos jerrquica ha sido llamada un sistema creado por programadores
para programadores.
Modelo de Red
Antecedentes
El Modelo de Base de Datos de Red fue creado para
Para cubrir la necesidad de representar relaciones
complejas entre los datos de una manera ms efectiva que
el modelo jerrquico.
Mejorar el desempeo de la base de datos.
Definir e imponer un estndar.
CODASYL (Conference on Data Systems Languages) cre en
1971 el DBTG (DataBase Task Group) con el fin de establecer
estndares para bases de datos.
Especificaciones del DBTG

Esquema de red: organizacin conceptual de toda la base de datos segn es
vista por el administrador de la misma.
Subesquema: define la porcin de la base de datos como la ven los
programas de aplicacin que son los que producen la informacin deseada a
partir de los datos contenidos en la base de datos.
Lenguaje de administracin de datos: sirve para definir las caractersticas y
estructura de los datos as como para manejarlos.
Lenguaje de Definicin de Datos (DDL): permite al administrador definir
las componentes del esquema.
DDL para subesquemas: permite a los programas de aplicacin definir las
componentes de la base de datos que sern utilizadas.
Lenguaje para el Manejo de Datos (DML): permite manejar el contenido de
la base de datos.
Lenguajes de Administracin de Datos

Lenguaje de Definicin de Datos (DDL): lenguaje en el que se expresan el
conjunto de definiciones que especifican el esquema de una base de datos. Al compilar las
instrucciones del DDL, se obtiene un catlogo o diccionario de datos, el cual es un archivo
que contiene metadatos, es decir datos sobre los datos.
Lenguaje para el Manejo de Datos (DML): lenguaje que permite manejar una
base de datos.
Recuperar informacin utilizando un lenguaje de consulta
Incluir nueva informacin
Borrar informacin
Modificar datos
Tipos de DML
Procedurales: el usuario especifica que datos necesita y cmo obtenerlos.
No-procedurales: el usuario slo indica que datos necesita sin especificar como
obtenerlos
Estructura bsica del Modelo de Red

Una asociacin es llamada un conjunto, el cual est compuesto por dos tipos de
registros, propietario y miembro, entre los cuales existe una relacin 1:M
Propietario 1
Miembro
Vendedor
Cliente
Producto
Factura Pago
1:M
1:M
Conjunto COMISIONES
DetFactura
1:M
1:M
Conjunto VENTAS
1:M
Ventajas del Modelo de Red

Conserva muchas de las ventajas del modelo jerrquico y corrige o
mejora varias de sus limitaciones.
Las relaciones M:N son ms fciles de implementar que en el modelo
jerrquico.
Es ms sencillo el acceso a los datos y tiene ms flexibilidad que el
modelo jerrquico.
Obliga a tener integridad en la base de datos porque el usuario debe
primero definir al registro propietario y despus al registro miembro.
Tiene un nivel suficiente de independencia de datos para, al menos,
aislar parcialmente los programas de los detalles complejos del
almacenamiento fsico. Por lo tanto, cambios en las caractersticas de los
datos no requieren cambios en los programas de aplicacin.
Desventajas del Modelo de Red
Las bases de datos de red son difciles de disear y utilizar adecuadamente.

No tiene independencia estructural. Es difcil hacer cambios en la base de
datos y si se hacen, entonces todas las definiciones de los subesquemas deben
validarse antes de que una aplicacin pueda accesar la base de datos.
Desde el punto de vista del programador de aplicaciones, tiene una estructura
muy compleja.
Como en el modelo jerrquico, el modelo de red tambin tiene un ambiente
navegacional para accesar a los datos.
El control de integridad de la base de datos y la eficiencia con que el modelo de
red maneja las relaciones, algunas veces se contraponen con la complejidad
del sistema. El modelo de red no fue diseado para ser user-friendly, est
enfocado hacia los programadores y administradores capaces y tcnicamente
orientados.
Modelo Relacional
Antecedentes
El Modelo Relacional fue introducido por E. F. Codd en su artculo
A Relational Model for Large Shared Data Banks, CACM, Vol
13, Num 6, Junio de 1970.
Inicialmente se le consider ingenioso pero poco prctico porque
demandaba muchos recursos computacionales. Afortunadamente,
el poder de las computadoras creci exponencialmente, as como
tambin la eficiencia de los sistemas operativos. Adems de esto,
el costo disminuy rpidamente. Actualmente, existen DBMSs
comerciales que corren en microcomputadoras, las cuales cuestan
una pequea fraccin de lo que costaban los antiguos mainframes.
Relaciones
El usuario percibe a la base de datos relacional como un
conjunto de tablas o relaciones en las que los renglones
corresponden a entidades cuyos atributos son las columnas.
Ejemplo
Nombre Matrcula Telfono
Direccin
B. Baeza
612435
373-1616 Jurez 291
K. Armenta
811245
375-4009 Hidalgo 125
D. Prez
222320
Central 345
C. Corts
981100
376-9821 Barrera 32
B. Lpez
691238
839-4654 Libertad 265
Ventajas del Modelo Relacional
Independencia estructural y de datos.

Es ms sencillo disear y manejar la base de datos.
Lenguaje de consulta poderoso y flexible
SQL (Structured Query Language)
Permite consultas ad-hoc.
Lenguaje de Cuarta Generacin (4GL): se especifica lo que se
quiere sin necesidad de especificar como obtenerlo.
Estndar de facto para los DBMSs relacionales (RDBMS).
El RDBMS se encarga de los aspectos fsicos de la base de datos,
permitiendo as al usuario concentrar sus esfuerzos en la parte lgica de
la base de datos y su correspondiente diseo.
Desventajas del Modelo Relacional
El que el RDBMS esconda la mayor parte de la complejidad

de la base de datos, hace que requiera ms recursos
computacionales y por lo tanto tiende a ser ms lento que los
modelos jerrquico y de red. Sin embargo, gracias al rpido
crecimiento de la capacidad del hardware y a las mejoras en
los sistemas operativos, esta desventaja est desapareciendo.
Modelo de datos
Modelo: es una descripcin o analoga usada para visualizar algo
que no puede observarse directamente.
Diccionario Webster.
Modelo de datos: es la representacin relativamente simple, por lo
general grfica, de las complejas estructuras de datos del mundo real.
Su principal funcin es la de ayudarnos a entender las complejidades
de un ambiente del mundo real.
El modelo de datos representa las estructuras y caractersticas de los
datos, sus relaciones, restricciones y transformaciones.
Abstraccin de los datos: es la caracterstica que hace posible la
independencia con respecto a los programas y datos y la
independencia con respecto a los programas y operaciones.
Modelos de datos (ANSI/SPARC)

ANSI/SPARC (American National Standards Institute /
Standards Planning and Requirements Committee System
Problem Analysis and Resolution Committee) define cuatro
modelos de datos basados en su grado de abstraccin.
Modelo Conceptual
Modelo Externo
Modelo Interno
Modelo Fsico
Modelos de datos ANSI/SPARC

Grado de
abstraccin
Caractersticas
Modelo
Conceptual
Alto
Independiente del HW
Independiente del SW
Modelo
Interno
Mediano
Independiente del HW
Dependiente del SW
Modelo
Externo
Modelo
Externo
DBMS
R
e
l
a
c
i
o
n
a
l
J
e
r
r
q
u
i
c
o
&
Modelo
Fsico
Bajo
Dependiente del HW
Dependiente del SW
R
e
d
e
s
Modelo Conceptual
El modelo conceptual es el ms alto nivel de abstraccin,

representa una visin global de los datos. Es una visin a todo
lo amplio de la empresa, como es vista por directivos de alto
nivel. Es la base para la identificacin y descripcin de los
principales objetos de datos, sin fijarse en los detalles. El
modelo conceptual ms utilizado es el Modelo EntidadRelacin.
Es independiente del software y del hardware porque el
modelo no depende del DBMS ni del equipo (computadora)
utilizados para implementar el modelo.
Ejemplo de Modelo Conceptual (ITESM)

Entidades
PROFESOR
...
CURSO
...
SALN
...
ESTUDIANTE
Matrcula
Nombre(s)
Apellido Paterno
Apellido Materno
Sexo
Fecha de Nacimiento
Carrera
Semestre
Promedio
Esquema Conceptual:
entidades y las relaciones
entre ellas.
Profesor
1
imparte
M
Clase
requiere
M
contiene
N
Estudiante
Saln
Modelo Interno
Una vez que se ha seleccionado el DBMS especfico, el

modelo interno adapta el modelo conceptual al DBMS
escogido. En otras palabras, el modelo interno requiere que el
diseador haga corresponder las caractersticas y restricciones
del modelo conceptual a las del modelo de base de datos
relacional o jerrquico o de redes seleccionado. El modelo
interno depende de la existencia del software de base de datos
especfico, por lo que se dice que es dependiente del software
(DBMS), pero es independiente del hardware porque no
depende del equipo, HW, utilizado para implementar el
sistema.
Modelo Externo
El modelo externo es la visin que de los datos tiene el
programador de aplicaciones, basado en el modelo interno o
en el esquema de la base de datos. Un modelo externo est
representado por su correspondiente esquema externo, que es
un subconjunto del modelo interno.
Clase
M
Profesor
1
contiene
N
Estudiante
Esquema externo del

programador J. Lpez
imparte
M
Clase
requiere
M
Saln
Esquema externo de la
programadora L.Rodrguez
Modelos externos
Proceso
Vista Externa
Clase
Inscripcin
Cupo mximo es de 35 estudiantes.
M
N
Estudiante
Un estudiante puede inscribirse hasta

seis clases, mximo.
Profesor
Un profesor puede impartir un mximo

de tres clases.
Programacin
de clases
Restricciones
Clase
Una clase solo tiene un profesor
M
1
Saln
Un saln puede ser usado para varias

clases, pero una clase solo se imparte
en un saln.
Modelo Fsico
El Modelo Fsico opera al ms bajo nivel de abstraccin,

describe la manera como los datos son guardados en los
dispositivos de almacenamiento. El modelo fsico requiere la
definicin de los dispositivos fsicos de almacenamiento as
como los mtodos de acceso para llegar a los datos que se
encuentran dentro de esos dispositivos de almacenamiento.
El modelo fsico es dependiente del software y del hardware.
Independencia de datos
Capacidad de modificar un esquema sin afectar la definicin de un
esquema superior.
Independencia fsica: capacidad de modificar el esquema fsico sin
alterar el esquema conceptual ni tener que redefinir los subesquemas
ni volver a escribir los programas de aplicacin. La modificacin del
esquema fsico se puede requerir para optimizar el funcionamiento de
la base de datos.
Independencia lgica: capacidad de modificar el esquema conceptual
sin tener que redefinir los subesquemas ni volver a escribir los
programas de aplicacin. La modificacin del esquema conceptual se
puede requerir al aadir datos como nuevos tipos de entidades o
nuevos atributos para entidades existentes.
Aclaracin
Las palabras en ingls relationship y relation, ambas se

traducen al espaol como relacin, por lo que debemos tener
cuidado para poder diferenciar si se trata de relacin en el
sentido de asociacin o vnculo (relationship) o relacin en el
sentido de tabla (relation) como la estructura fundamental en
el modelo relacional. Para evitar esta posible confusin,
algunos autores llaman al modelo E-R, el modelo EntidadVnculo. Nosotros lo seguiremos llamando Modelo EntidadRelacin, confiando que el contexto en que utilicemos la
palabra relacin evite la posible confusin.
Modelo Entidad-Relacin (E-R)

Antecedentes
El enfoque del modelo E-R al diseo conceptual de una base de datos fue
originalmente descrita por Peter Chen (M.I.T.) en 1976 en su artculo The
Entity-Relationship Model: Toward a Unified View of Data publicado en
ACM Transactions on Database Systems, Vol. 1, Num. 1, Marzo de 1976.
El modelo E-R se utiliza para
Traducir diferentes vistas de datos entre gerentes, usuarios y
programadores para encajarlos dentro de un marco comn.
Definir los requerimientos sobre restricciones y proceso de datos con el
fin de ayudarnos a obtener las diferentes vistas.
Apoyar a implementar la base de datos.
Modelo Entidad-Relacin
El modelo E-R es un modelo de datos conceptual que proporciona una
serie de construcciones capaces de describir los requerimientos de datos
de una aplicacin en una manera fcil de entender y que es independiente
de los criterios para la administracin y organizacin de datos en el
sistema.
El modelo E-R tiene tres componentes principales:
Conjuntos de entidades: coleccin de entidades, es decir, de cosas
u objetos, que son distinguibles entre si por medio de sus atributos.
Atributos: caractersticas o propiedades que poseen las entidades;
con valores para cada entidad.
Relaciones o vnculos (relationships): son conexiones lgicas entre
dos o ms conjuntos de entidades.
Tipos de atributos
Compuestos: se pueden dividir.
Nombre: Apellido paterno, apellido materno, nombre de pila.

Direccin: calle, nmero, ciudad, CP.
Simples: no se pueden dividir

Sexo, salario, NSS.
Monovaluados: tienen un solo valor para cada entidad.

Edad, sexo, salario, NSS.
Multivaluados: puede tener varios valores para una sola entidad.

Habilidades. Grados acadmicos.
Almacenados: su valor est fsicamente almacenado en la base de datos.

Fecha de nacimiento, sexo, salario.
Derivados: su valor se puede obtener de atributos almacenados.

Edad, nmero de empleados en un departamento, salario promedio.
Llaves (claves)
Llave de un conjunto de entidades: es un atributo o conjunto
de atributos cuyo valor(es) identifican de manera inequvoca a
cada entidad del conjunto.
NSS.
Nombre, edad y domicilio.
NSS y nombre
Llave candidata: son llaves mnimas, es decir, no le
sobran atributos.
Llave primaria: llave candidata elegida por el diseador de la
base de datos segn la realidad que est modelando.
Ejemplo: Base de datos COMPAA

COMPAA contiene la informacin de empleados, departamentos y proyectos
de una empresa.
Departamento
Nombre y nmero nico. Un empleado lo dirige a partir de cierta fecha. Puede estar
distribuido en varios lugares. Controla varios proyectos.
Proyecto
Nombre y nmero nico. Se lleva a cabo en un solo lugar.
Empleado
Nombre. Nmero de seguridad social. Direccin. Salario. Sexo. Fecha de nacimiento.
Est asignado a un departamento. Puede trabajar en varios proyectos no necesariamente
controlados por el mismo departamento. Interesa saber cuantas horas por semana trabaja
en cada proyecto y quien es su supervisor.
Dependiente
Nombre. Sexo. Fecha de nacimiento. Parentesco con el empleado.
Entidades para COMPAA

DEPARTAMENTO: Nombre, Nmero, {Lugares}, Gerente,
FechaInicGerente.
PROYECTO: Nombre, Nmero, Lugar, DeptoControlador.
EMPLEADO: Nombre(NomPila, Apellido Paterno, Apellido
Materno), NSS, Sexo, Direccin, Salario, FechaNac, Departamento,
Supervisor, {TrabajaEn(Proyecto, Horas)}.
DEPENDIENTE: Empleado, NombreDependiente, Sexo,
FechaNac, Parentesco.
Notacin:
Atributo compuesto: ()
Atributo multivaluado: {}
Vnculos o Relaciones (relationships)

Vnculos: asociaciones entre entidades.
Grado de un vnculo: nmero de conjuntos de unidades que participan en el vnculo.
Binaria (involucra dos conjuntos de entidades):
EMPLEADO ------- PERTENECE_A ------- DEPARTAMENTO
Ternaria (involucra tres conjuntos de entidades):
PROVEEDOR
PROYECTO
\
/
\
/
SUMINISTRAR
|
|
COMPONENTE
Vnculos
Rol o papel de un vnculo: funcin que juega una entidad en un vnculo. Por lo
general el rol est implcito y no es necesario especificarlo a menos que sea un
vnculo recursivo, es decir, que asocie a un conjunto de entidades consigo misma.
EMPLEADO ----1---- SUPERVISIN ----2---- EMPLEADO
1: Supervisor
2: Supervisado
Cardinalidad de un vnculo: es el nmero de entidades a las que puede asociarse
una entidad mediante el vnculo.
1:1 EMPLEADO ----- DIRIGE ----- DEPARTAMENTO
1:N EMPLEADO ----- PERTENECE_A ----- DEPARTAMENTO
M:N EMPLEADO ----- TRABAJA_EN ----- PROYECTO
Un vnculo puede tener atributos

Horas para TRABAJA_EN: nmero de horas por semana que un empleado trabaja en un
proyecto.
FechaInic para PERTENECE_A: fecha cuando un empleado comenz a trabajar en un
departamento.
Dnde poner los atributos? La seleccin de atributos relevantes para un conjunto de entidades es
un paso crtico en el diseo de un modelo del mundo real. Se puede definir un conjunto de
entidades y sus relaciones de varias maneras, dependiendo de la forma en que tratemos los diversos
atributos. Por ejemplo, si queremos tener informacin de empleados y telfonos en la oficina.
EMPLEADO: Nombre-empleado, Nmero-telfono.
EMPLEADO: Nombre-empleado.
TELFONO: Nmero-telfono, Ubicacin.
EMPLTELEF: vnculo que asocia EMPLEADO con TELFONO.
Cul esquema es mejor?
Vnculos
Restriccin de Participacin
Total: todas las entidades del conjunto de entidades estn asociadas
con al menos una entidad del otro conjunto.
En el vnculo PERTENECE_A entre EMPLEADO y
DEPARTAMENTO, la participacin de EMPLEADO es total.
Cuando la participacin es total decimos que hay una dependencia
de existencia porque una entidad del conjunto de participacin total
no puede existir si no est asociada con una entidad del otro conjunto.
Parcial: Algunas entidades no participan en el vnculo. En el vnculo
DIRIGE entre EMPLEADO y DEPARTAMENTO, la participacin
de EMPLEADO es parcial.
Entidades dbiles
Conjunto de entidades dbiles: no tienen suficientes atributos para formar
una llave y tienen una dependencia de existencia de otro conjunto de
entidades, llamado el propietario identificador, el cual permite la
identificacin de las entidades dbiles. El vnculo entre un conjunto de
entidades dbil y su propietario identificador es llamado vnculo
identificador.
DEPENDIENTE es un conjunto de entidades dbil cuyo propietario
identificador es EMPLEADO.
Un conjunto de entidades dbil tiene una llave parcial que permite
identificar a las diferentes entidades dbiles relacionadas con la misma
entidad propietaria.
Las entidades dbiles se pueden representar como atributos multivaluados
compuestos de las entidades del conjunto propietario identificador.
Vnculos para COMPAA

DIRIGE es 1:1 entre EMPLEADO(parcial) y DEPARTAMENTO(total); tiene
atributo FechaInic.
PERTENECE_A es 1:N entre DEPARTAMENTO(total) y
EMPLEADO(total).
CONTROLA es 1:N entre DEPARTAMENTO(parcial) y PROYECTO(total).
SUPERVISIN es 1:N entre EMPLEADO como supervisor(parcial) y
EMPLEADO como supervisado(parcial).
TRABAJA_EN es M:N entre EMPLEADO(total) y PROYECTO(total); tiene
atributo Horas.
DEPENDIENTES_DE es 1:N y es el vnculo identificador
EMPLEADO(parcial) y DEPENDIENTE(total) que es dbil.
Diagrama Entidad-Relacin
Rectngulos: conjuntos de entidades.

Elipses: atributos.
Rombos: vnculos.
Lneas: conectan atributos con conjuntos de entidades y conjuntos
de entidades con vnculos.
Etiquetas sobre las lneas: roles o papeles.
Rectngulos con doble contorno: conjuntos de entidades dbiles.
Ejemplos de Diagramas E-R

Pre-requisito
Relaciones unarias
MATERIA
Relaciones binarias
PROFESOR
ENSEA
Relacin ternaria
PREREQUI
SITO
Materia
MATERIA
PROVEEDOR
ALUMNO
INSCRITO
SUMINISTRA
Relacin cuaternaria o tetranaria (incluir DPTO)

COMPONENTE
MATERIA
PROYECTO
Jerarqua de Generalizacin
En ocasiones hay casos especiales de algunas entidades
Empleados: secretarias, pilotos, tcnicos.
Cuentas bancarias: cuentas de cheques, cuentas de ahorro.
Las cuales tienen atributos en comn y atributos o caractersticas
diferentes. Si registramos todas las caractersticas de todas los
casos especiales o subtipos, entonces tendramos muchos
atributos en blanco, lo cual puede complicar su manejo.
En este caso decimos que tenemos una relacin padre-hijo entre
una entidad de nivel superior llamada supertipo y una entidad
de nivel inferior llamada subtipo.
Jerarqua de Generalizacin
EMPLEADO
Supertipo
IS-A
Subtipo
SECRETARIA
PILOTO
TCNICO
Modelo Relacional
Base de Datos Relacional: coleccin de relaciones (relations) o tablas en las cuales cada
rengln o tupla es una entidad y cada columna es un atributo. Los valores de los atributos de
una entidad estn relacionados entre si.
Dominio del atributo: conjunto de valores permitidos
Definiciones lgicas; tipo de datos o formato
Definicin matemtica: una relacin es un subconjunto del producto cartesiano de los
dominios
R D1 D2 Dn = {(d1, d2, , dn) | di Di, i = 1, 2, ,n}
Esquema de una relacin: nombre de la relacin y una lista de sus atributos R(A1, A2, , An)
Grado de una relacin: nmero de atributos de la relacin.
Cardinalidad de una relacin: nmero de tuplas de la relacin.
Instancia de una relacin: conjunto de tuplas y sus valores.
Notacin: t(lista de atributos) son los valores que toman los atributos de la lista en la tupla t.
Restricciones
Requerimientos y restricciones de integridad: presentar aspectos y conceptos importantes de

seguridad e integridad de los datos as como dependencias y definicin de requerimientos.
Tipos de restricciones:
De dominio
Forma ms elemental de restriccin, es fcil probarlas.
Se especifica el tipo de datos, longitud, formato.
Restriccin de llave
Llave: identifica inequvocamente a cada tupla.
Llave candidata: llave mnima.
Llave primaria: llave candidata seleccionada.
Restriccin de integridad de identidad: ningn valor de una llave primaria puede ser nulo.
Otras restricciones del negocio o de integridad semntica: dependen de la realidad que se
modela.
Integridad referencial:
Esquema de una base de datos

Esquema de una base de datos relacional: es un conjunto de
esquemas de relaciones y un conjunto de restricciones de
integridad.
Ejemplo COMPAA:
EMPLEADO(NOMBREP, APELLIDO, NSSE, FECHAN,
DIRECCIN, SEXO, SALARIO, NSSSGT, ND)
DEPARTAMENTO(NOMBRED, NMEROD, NSSGTE,
FECHAINGTE)
LUGARES_DEPTOS(NMD, LUGARD)
PROYECTO(NOMBREP, NMP, LUGARP, NMD)
TRABAJA_EN(NSSE, NMP, HORAS)
DEPENDIENTE(NSSE, NOMBREDEPENDIENTE, SEXO,
FECHAN, PARENTESCO)
Instancia de una base de datos: es un conjunto de instancias de
las relaciones tal que se satisfacen las restricciones de integridad.
ESQUEMA
EMPLEADO(NOMBREE, NSSE, FECHAN, DIRECCIN,

NMEROD)
DEPARTAMENTO (NOMBRED, NMEROD, NSSGTED)
LUGARES_DEPTOS (NMEROD, LUGARD)
PROYECTO(NOMBREP, NMEROP, LUGARP,
NMEROD)
TRABAJA_EN(NSSE, NMEROP, HORAS)
DEPENDIENTE(NSSE, NOMBREDEPENDIENTE, SEXO,
FECHAN, PARENTESCO)
79
Integridad referencial
La construccin bsica para representar un vnculo en el

modelo relacional es colocar un atributo comn en cada
relacin o tabla vinculada o representando el vnculo por
medio de una tabla en la que aparecen atributos de las
relaciones vinculadas. Por lo tanto es necesario que el(los)
valor(es) de cierto(s) atributo(s) que aparece(n) en una
relacin tambin aparezca(n) en algn(os) atributo(s) de otra
relacin o relaciones.
En otras palabras, una tupla que haga referencia a otra
relacin deber referirse a una tupla existente en esa relacin.
Llave externa o fornea (foreign key)

Llave externa: atributo o conjunto de atributos que son la
llave primaria de alguna relacin.
Ms formalmente:
Definicin: sean R y S relaciones con llaves primarias K1 y K2,
respectivamente. Decimos que un subconjunto de atributos
de S es una llave externa de S con referencia a K1 en la
relacin R si se requiere que para toda tupla t2 S, haya una
tupla t1 R tal que t1 [K1] = t2[].
Equivalentemente: (S) K1(R)
Este tipo de restricciones se les llama restricciones de integridad
referencial o de dependencia de subconjuntos.
Del Modelo E-R al Modelo Relacional

(Reduccin de diagramas E-R a tablas)
Si F es un conjunto de entidades fuerte (no dbil) con atributos A1, A2, , An,
entonces la tabla o relacin que representa a F, llamada tambin F, consta de n
columnas, una para cada atributo y tiene una fila o rengln para cada una de las
entidades de F. La llave primaria de la relacin es la misma que la del conjunto
de entidades.
Si D es un conjunto de entidades dbil con atributos A1, A2, , An, el cual
depende del conjunto de entidades fuerte F cuya llave primaria es B (puede ser
una llave compuesta), entonces representamos a D con una tabla con atributos
A1, A2, , An, B. La llave primaria de la relacin resultante est formada por la
llave parcial de D combinada con B. Si D dependiera de ms de un conjunto de
entidades, entonces tendramos que combinar las llaves primarias de los otros
conjuntos de entidades tanto en la representacin de D como en la composicin
de su llave primaria.
Cmo convertir vnculos a tablas?

Un vnculo binario 1:1 que vincula los conjuntos de entidades
R y S: escogemos una de las dos relaciones, de preferencia la que
tenga participacin total, y en su tabla correspondiente le aadimos
como llave fornea los atributos que forman la llave primaria de la
otra relacin, tambin le aadimos los atributos del vnculo.
Un vnculo binario 1:N que vincula los conjuntos de entidades
R y S (digamos que R es el que est del lado 1 del vnculo y S es
el que est del lado N): en la tabla correspondiente de S le
aadimos como llave fornea los atributos que forman la llave
primaria de R, tambin le aadimos los atributos del vnculo.
Cmo convertir vnculos a tablas?
Un vnculo binario M:N que vincula los conjuntos de

entidades R y S: construimos una nueva tabla en la que se
incluyen los atributos del vnculo y como llave primaria es la
combinacin de las llaves primarias de R y S, las cuales son
tambin llaves forneas de la tabla.
Este mtodo se puede utilizar para representar a los vnculos
1:1 o 1:N cuando la participacin de las entidades es poca. Si
se sigue este mtodo, entonces la llave primaria de la tabla
resultante, en el caso 1:N, es la llave primaria de la tabla del
lado N. En el caso de 1:1, se escoge la que tenga
participacin total, si la hay.
Atributos multivaluados?
Para cada atributo multivaluado A se crea una relacin cuyos atributos son A
mas la llave primaria K de la relacin de la cual forma parte el atributo
multivaluado. La llave primaria de la relacin resultante est formada por la
combinacin de A y K.
Vnculos n-arios?
Un vnculo n-ario que vincula varios conjuntos de entidades: se crea una
relacin que tiene como llaves forneas las llaves primarias de cada conjunto de
entidades que participa en el vnculo. Tambin se incluyen los atributos del
vnculo. La llave primaria de la relacin resultante es la combinacin de las llaves
primarias de los conjuntos de entidades que participan en el vnculo, a menos que
uno de los conjuntos tenga una participacin mxima igual a 1 en cuyo caso su
llave primaria es tambin la llave primaria de la relacin resultante.
Y Jerarqua de Generalizacin?
Jerarqua de generalizacin: hay dos mtodos para

convertirla en tabla
Mtodo 1
Se crea una tabla para el supertipo.
Se crea una tabla para cada subtipo con sus propios
atributos mas los de la llave primaria del supertipo.
Mtodo 2
Slo se crean tablas para cada uno de los subtipos con
sus propios atributos mas todos los del supertipo.
Normalizacin
Cmo obtener un buen diseo de una base de datos?

Qu es un buen diseo?
Qu es un diseo?
Diseo de una base de datos

Diseo: es el esquema de la base de datos relacional, es decir, es el conjunto de
esquemas de relaciones junto con el conjunto de restricciones de integridad.
Niveles para evaluar la bondad de un diseo:
Nivel lgico: buena interpretacin de los esquemas y del significado de los
atributos.
Nivel de manipulacin o de almacenamiento: que tan eficientemente se llevan a
cabo el almacenamiento y la actualizacin de las relaciones base, es decir, de las
que fsicamente estn almacenadas.
Criterios de evaluacin de un diseo:
Semntica de los atributos.
Reduccin de redundancia.
Reduccin de valores nulos.
Prohibicin de tuplas espurias (?).
Semntica de los atributos

Qu tan fcil es interpretar el esquema de una relacin?
EMPLEADO(NOMBREE, NSSE, FECHAN, DIRECCIN,
NMEROD)
DEPARTAMENTO(NOMBRED, NMEROD, NSSGTED)
LUGARES_DEPTOS(NMEROD, LUGARD)
PROYECTO(NOMBREP, NMEROP, LUGARP, NMD)
TRABAJA_EN(NSSE, NMEROP, HORAS)
DEPENDIENTE(NSSE, NOMBREDEPENDIENTE, SEXO, FECHAN,
PARENTESCO)
Gua 1: disee un esquema relacional fcil de entender. No mezclar atributos
de varios conjuntos de entidades o vnculos.
Reduccin de redundancia
Esquemas redundantes: repiten datos innecesariamente.

EMP_DPTO(NOMBREE, NSS, FECHAN, DIRECCIN,
NMEROD, NOMBRED, NSSGTED)
EMP_PROY(NSS, NMEROP, HORAS, NOMBREE,
NOMPREP, LUGARP)
En EMP_DPTO los datos de un departamento se repiten
tantas veces como empleados haya en ese departamento.
La relacin EMP_PROY tambin tiene un alto nivel de
redundancia.
Instancia de EMP_DPTO
EMP_DPTO
NOMBREE
NSS
Silva, Jos B.
123456789
Vizcarra, Federico T. 333445555
Zapata, Alicia J.
999887777
Valds, Jazmn S.
987654321
Nieto, Ramn K.
666884444
Esparza, Josefa A.
453453453
Jabbar, Ahmed V.
987987987
Botello, Jaime E.
888665555
FECHAN
09-Ene-55
08-Dic-45
19-Jul-58
20-Jun-31
15-Sep-52
31-Jul-62
29-Mar-59
10-Nov-27
DIRECCIN
NMEROD NOMBRED
Fresnos 731, Higueras, MX
5
Investigacin
Valle 638, Higueras, MX
5
Investigacin
Castillo 3321, Sucre, MX
4
Administracin
Bravo 291, Beln, MX
4
Administracin
Espiga 957, Heras, MX
5
Investigacin
Rosas 5631, Higueras, MX
5
Investigacin
Dalias 980, Higueras, MX
4
Administracin
Sorgo 450, Higueras, MX
1
Direccin
NSSGTED
333445555
333445555
987654321
987654321
333445555
333445555
987654321
888665555
Instancia de EMP_PROY
NSS
123456789
123456789
666884444
453453453
453453453
333445555
333445555
333445555
333445555
999887777
999887777
987987987
987987987
987654321
987654321
888665555
EMP_PROY
NMEROP HORAS
NOMBREE
1
32.5
Silva, Jos B.
2
7.5
Silva, Jos B.
3
40.0
Nieto, Ramn K.
1
20.0
Esparza, Josefa A.
2
20.0
Esparza, Josefa A.
2
10.0
Vizcarra, Federico T.
3
10.0
10
10.0
20
10.0
30
30.0
Zapata, Alicia J.
10
10.0
Zapata, Alicia J.
10
35.0
Jabbar, Ahmed V.
30
5.0
Jabbar, Ahmed V.
30
20.0
Valds, Jazmn S.
20
15.0
Valds, Jazmn S.
20
nulo
Botello, Jaime E.
NOMBREP
ProductoX
ProductoY
ProductoZ
ProductoX
ProductoY
ProductoY
ProductoZ
Automatizacin
Reorganizacin
NuevasPrestaciones
Automatizacin
Automatizacin
NuevasPrestaciones
NuevasPrestaciones
Reorganizacin
Reorganizacin
LUGARP
Beln
Sacramento
Higueras
Beln
Sacramento
Sacramento
Higueras
Santiago
Higueras
Santiago
Santiago
Santiago
Santiago
Santiago
Higueras
Higueras
Anomalas de actualizacin
Anomalas de insercin: para insertar cierta informacin se requiere de otra.

Insertar un nuevo empleado en EMP_DPTO requiere de los datos del departamento o
utilizar valores nulos.
Insertar datos de un departamento en EMP_DPTO requiere que tenga empleados o
utilizar valores nulos para NSS.
Anomalas de eliminacin: al eliminar cierta informacin tambin se eliminara otra.
Al eliminar al ltimo empleado de un departamento en EMP_DPTO tambin se
eliminara la informacin del departamento correspondiente.
Anomalas de actualizacin (modificacin): varias tuplas tienen que ser modificadas al
cambiar ciertos datos.
Al cambiar de gerente del departamento 5, hay que modificar todas las tuplas de los
empleados de ese departamento.
Gua 2: Evitar las anomalas de insercin, eliminacin y actualizacin.
Reduccin de valores nulos
Qu significa un valor nulo?

El atributo no se aplica a la tupla.
Se desconoce el valor del atributo para la tupla.
El valor, aunque conocido, an no se ha registrado.
Cmo se suma o cuenta un valor nulo?
Gua 3: Evitar el uso de valores nulos. La llave primaria no
puede tener valores nulos.
Normalizacin
Normalizacin: es el proceso de asignar atributos a entidades con
el fin de reducir redundancia y, por consecuencia, ayuda a
eliminar las anomalas que resultan de esta redundancia.
Importante:
La normalizacin no elimina la redundancia slo busca
alcanzar el nivel necesario y adecuado para vincular las
relaciones.
Un alto grado de normalizacin puede degradar el desempeo
por lo que en ocasiones habr que desnormalizar.
Primera forma normal
Formas normales
CARGOS_PROY
NMEROP NOMBREP
NSSE
NOMBREE
PUESTOE CARGO/HORA HORAS CARGO
Prohibe atributos multivaluados, grupos repetitivos, es decir, relaciones dentro de relaciones o anidadas. Por ejemplo, un mismo proyecto tiene un grupo de varias entradas en la tabla.
Resumiendo: la primera forma1
normal
(1FN) slo permite valores atmicos.
PRODUCTOX
123456789 Silva, Jos B.
Ingeniero
65
13
845
333445555 Vizcarra, Federico T. Tcnico
60
16
960
999887777 Zapata, Alicia J.
Tcnica
60
19
1140
2 PRODUCTOY
123456789 Silva, Jos B.
Ingeniero
65
15
975
987654321 Valds, Jazmn S.
Secretaria
55
17
935
3 PRODUCTOZ
999887777 Zapata, Alicia J.
Tcnica
60
18
1080
333445555 Vizcarra, Federico T. Tcnico
60
14
840
NMEROP
1
1
1
2
2
3
3
CARGOS_PROY
NOMBREP
NSSE
PRODUCTOX
123456789
PRODUCTOX
333445555
PRODUCTOX
999887777
PRODUCTOY
123456789
PRODUCTOY
987654321
PRODUCTOZ
999887777
PRODUCTOZ
333445555
NOMBREE
Silva, Jos B.
Zapata, Alicia J.
Silva, Jos B.
Valds, Jazmn S.
Zapata, Alicia J.
PUESTOE CARGO/HORA HORAS CARGO

Ingeniero
65
13
845
Tcnico
60
16
960
Tcnica
60
19
1140
Ingeniero
65
15
975
Secretaria
55
17
935
Tcnica
60
18
1080
Tcnico
60
14
840
Primera Forma Normal (1FN)
***
Primera Forma Normal:

Todos los atributos llave primaria estn definidos.
No hay grupos repetitivos, es decir, cada entrada solo tiene un valor atmico y no un
conjunto de valores.
Todos los atributos dependen de la llave primaria.
CARGOS_PROY tiene llave compuesta: (NUMEROP, NSSE)
Algunos atributos dependen parcialmente de la llave primaria

NOMBREP
slo de NMEROP
NMEROP
NOMBREPdependeNSSE
NOMBREE
PUESTOE CARGO/HORA HORAS
NOMBREE, PUESTOE, CARGO/HORAS depende slo de NSSE.
Este esquema relacional presenta anomalas.
Dependencia Funcional
Decimos que un atributo o conjunto de atributos Y depende funcionalmente
de un atributo o conjunto de atributos X si para cualesquiera dos tuplas t1 y
t2 tales que
t1(X) = t2(X), entonces tambin se tiene t1(Y) = t2(Y).
En otras palabras:
Decimos que el atributo Y es funcionalmente dependiente del atributo X si
el valor del atributo X determina el valor del atributo Y, es decir, no hay dos
tuplas diferentes que tengan los mismos valores en los atributos X y distintos
valores en los atributos Y. Al atributo X se le llama atributo determinante.
Notacin: X Y
Hecho: X es una superllave del esquema de relacin R si
X R, es decir, todos los atributos de R dependen funcionalmente de X.
Ejemplos
En el esquema PRSTAMO(NOMBRE_SUCURSAL,
NMERO_PRSTAMO, NOMBRE_CLIENTE, CANTIDAD) se
tiene NUMERO_PRSTAMO CANTIDAD
A B C D
En esta instancia se tienen las siguientes
a1 b1 c1 d1
dependencias funcionales:
a1 b2 c1 d2
A C, A A, AB A
a2 b2 c2 d2
AB D es verdadera porque no hay dos a2 b3 c2 d3
a3 b3 c2 d4
tuplas distintas que coincidan en AB
Sin embargo la dependencia C A no es vlida.
En la instancia EMP_PROY (Lmina 91) se tienen las siguientes
dependencias:
NSS NOMBREE
NMEROP NOMBREP, LUGARP
NSS, NMEROP HORAS
Dependencia vlida en un esquema

VS
Dependencia vlida en una instancia
Es posible que una dependencia se satisfaga en una instancia
de una relacin, sin embargo, es una dependencia que no
esperamos que se satisfaga siempre. Por ejemplo en la
siguiente instancia de la relacin CLIENTE
se tiene que la dependencia
NOMBRE_CLIENTE CALLE CIUDAD
Jones
Main
Harrison
CALLE CIUDAD
Smith
North Rye
pero no la incluiramos como
Hayes
Main
Harrison
Curry
North Rye
una dependencia funcional
Lindsay
Park
Pittsfield
vlida porque es posible que
Turner
Putnam Stamford
Williams
Nassau Princeton
en alguna instancia futura de
Adams
Spring Pittsfield
la relacin, se tenga que dos
Johnson
Alma
Palo Alto
Sand Hil Woodside
ciudades tengan la misma calle. Glenn
Brooks
Green
Senator Brooklyn
Walnut Stamford
Segunda Forma Normal (2FN)
Una relacin est en Segunda Forma Normal (2FN) si no

tiene dependencias funcionales parciales, es decir, no hay
atributos no primos (no son parte alguna llave candidata) que
dependen funcionalmente de slo parte de la llave primaria.
Cules son las dependencias vlidas de la relacin
EMP_PROY(NSS, NMEROP, HORAS, NOMBREE,
NOMPREP, LUGARP)?
Hay dependencias funcionales parciales?
Cules son?
Cmo la pasaramos a 2FN?
Dependencias de EMP_PROY
Dependencias funcionales
NSS, NMEROP HORAS
NSS NOMBREE
NMEROP NOMBREP, LUGARP
EMP_PROY en 2FN
EP1(NSS, NMEROP, HORAS)
EP2(NSS, NOMBREE)
EP3(NMEROP, NOMBREP, LUGARP)
EMP_PROY en 2FN
EP1
NSS
NMEROP
123456789
1
123456789
2
666884444
3
453453453
1
453453453
2
333445555
2
333445555
3
333445555
10
333445555
20
999887777
30
999887777
10
987987987
10
987987987
30
987654321
30
987654321
20
888665555
20
EP2
HORAS
32.5
7.5
40.0
20.0
20.0
10.0
10.0
10.0
10.0
30.0
10.0
35.0
5.0
20.0
15.0
nulo
NSS
123456789
666884444
453453453
333445555
999887777
987987987
987654321
888665555
NOMBREE
Silva, Jos B.
Nieto, Ramn K.
Esparza, Josefa A.
Zapata, Alicia J.
Jabbar, Ahmed V.
Valds, Jazmn S.
Botello, Jaime E.
EP3
NMEROP
1
2
3
10
20
30
NOMBREP
ProductoX
ProductoY
ProductoZ
Automatizacin
Reorganizacin
NuevasPrestaciones
LUGARP
Beln
Sacramento
Higueras
Santiago
Higueras
Santiago
Otro ejemplo
Esquema relacional:
REPORTE_CALIFS(MATRCULA, NOMBREEST, DIRECCIN,
CARRERA, CLAVECUR, NOMBRECUR, NOMBREPROF,
OFICPROF, CALIF)
Dependencias funcionales: se asume que cada curso tiene slo un
instructor.
MATRCULA NOMBREEST, DIRECCIN, CARRERA
CLAVECUR NOMBRECUR, NOMBREPROF,
OFICPROF
MATRCULA, CLAVECURSO CALIF
REPORTE_CALIFS EN 2FN:
EST(MATRCULA, NOMBREEST, DIRECCIN, CARRERA)
CURSO_PROF(CLAVECUR, NOMBRECUR, NOMBREPROF,
OFICPROF)
CURSO_CALIF(MATRCULA, CLAVECUR,CALIF)
Relacin REPORTE_CALIFS
Relacin REPORTE_CALIFS en 1FN

MATRCULA
123456
123456
654321
654321
654321
REPORTE_CALIFS
NOMBREEST DIRECCIN
Lpez, Luis
Jurez 461
Lpez, Luis
Jurez 461
Prez, Jess Hidalgo 87
CARRERA
ISC
ISC
LAE
LAE
LAE
CLAVECUR
CB95861
CB95841
CF95864
VA95801
CB95861
NOMBRECUR NOMBREPROF OFICPROF CALIF

Bases de DatosCorona, Juan Fco.P3 104
90
Teora de la Computacin
Bauer, Ken
P3 102
85
Impuestos
Rodrguez, LeticiaP2 106
95
Tpicos 1
Romn, Pedro P2 101
70
Bases de DatosCorona, Juan Fco.P3 104
80
Descomposicin de REPORTE_CALIFS en 2FN
EST
MATRCULA NOMBREEST DIRECCIN CARRERA
123456 Lpez, Luis
Jurez 461 ISC
654321 Prez, Jess Hidalgo 87 LAE
MATRCULA
123456
123456
654321
654321
654321
CURSO_CALIF
CLAVECUR CALIF
CB95861
CB95841
CF95864
VA95801
CB95861
90
85
95
70
80
CURSO_PROF
CLAVECUR NOMBRECUR NOMBREPROF
OFICPROF
CB95861
Bases de DatosCorona, Juan P3
Fco.
104
CB95841
Teora de la Computacin
Bauer, Ken P3 102
CF95864
Impuestos
Rodrguez, Leticia
P2 106
VA95801
Tpicos 1
Romn, PedroP2 101
Anomalas de 2FN
La relacin
EMP_DPTO(NOMBREE, NSS, FECHAN, DIRECCIN,
NMEROD, NOMBRED, NSSGTED)
est en 2FN? S porque la llave consta de un slo atributo, por lo que
ningn otro atributo puede depender parcialmente de la llave. Sin
embargo,
Tiene anomalas de insercin, eliminacin, modificacin?
Por qu?
La relacin
CURSO_PROF(CLAVECUR, NOMBRECUR, NOMBREPROF,
OFICPROF)
est en 2FN? S, porque la llave consta de un solo atributo.
Tiene anomalas de insercin, eliminacin, modificacin?
Por qu?
Anomalas de EMP_DPTO
Insercin: no podemos insertar la informacin de un

departamento a menos que ya tenga empleados.
Eliminacin: si el ltimo empleado de un departamento es
despedido, entonces se pierde la informacin del
departamento correspondiente.
Modificacin: si se cambia al gerente de un departamento,
entonces hay que hacer el cambio en varias tuplas (tantas
como empleados haya en el departamento).
Anomalas de CURSO_PROF
Insercin: no podemos insertar la informacin de un profesor

a menos que ya tenga cursos asignados.
Eliminacin: si un profesor ensea slo un curso y este se
cierra, entonces se pierde la informacin del profesor
correspondiente.
Modificacin: si se cambia la oficina de un profesor, entonces
hay que hacer el cambio en varias tuplas (tantas como cursos
ensee).
Razones para las anomalas de 2FN

En las dependencias vlidas en el esquema de la tabla
CURSO_PROF, vemos que aunque el atributo OFICPROF
depende totalmente de la llave CLAVECUR, esta dependencia
es transitiva (va NOMBREPROF) y no debiera haber
relacin entre el curso que imparte el profesor y la oficina del
profesor.
CLAVECUR NOMBREPROF
NOMBREPROF OFICPROF
de donde se obtiene
CLAVECUR OFICPROF
Cul son las dependencias transitivas en EMP_DPTO?
NSS NMEROD
NMEROD NOMBRED, NSSGTED
Tercera Forma Normal (3FN)

Para evitar las anomalas que an aparecen en la 2FN, debemos eliminar
las dependencias transitivas.
Decimos que una relacin est en Tercera Forma Normal (3FN) si los
atributos que no son parte de la llave primaria satisfacen
a. Son mutuamente independientes, es decir, ninguno de ellos es
funcionalmente dependiente de cualquier combinacin de los otros.
b. Son totalmente dependientes de la llave primaria (estn en 2FN).
En otras palabras, decimos que una relacin est en 3FN si est en 2FN
y los atributos que no son parte de la llave primaria no dependen
transitivamente de ella, es decir, no hay dependencias transitivas.
Descomposicin en 3FN
Descomposicin de EMP_DPTO en 3FN:
DFs:
NSS NMEROD
NMEROD NOMBRED, NSSGTED
Nuevas relaciones en 3FN:

ED1(NOMBREE, NSS, FECHAN, DIRECCIN, NMEROD)
ED2(NMEROD, NOMBRED, NSSGTED)
Descomposicin de CURSO_PROF en 3FN:
Dependencias funcionales:
CLAVECUR NOMBREPROF
NOMBREPROF OFICPROF
Nuevas relaciones en 3FN:

CURSO(CLAVECUR, NOMBRECUR, NOMBREPROF)
PROFESOR(NOMBREPROF, OFICPROF)
Est la 3FN libre de anomalas?

Relacin EST_ESP_ASESOR
Un estudiante puede tener varias especialidades.
Para cada especialidad un estudiante slo tiene un asesor.
Cada especialidad tiene varios asesores.
Cada asesor asesora slo una especialidad
Cada asesor asesora varios estudiantes en una especialidad
Dependencias funcionales
MATRCULA, ESPECIALIDAD ASESOR
ASESOR ESPECIALIDAD
Qu pasa si el estudiante 111222 cambia de
EST_ESP_ASESOR
MATRCULA ESPECIALIDAD
especialidad?
123456
Fsica
123456
Msica
654321
Biologa
112233
Fsica
332211
Fsica
111222
Computacin
ASESOR
Einstein
Mozart
Darwin
Bohr
Einstein
Corona
Forma Normal de Boyce-Codd (FNBC)
Recordemos que en una dependencia funcional X Y , al

atributo o conjunto de atributos X se le denomina
determinante.
Definicin: una relacin est en Forma Normal Boyce-Codd
(FNBC) si cualquier atributo o conjunto de atributos que es un
determinante es tambin una llave candidata. En otras
palabras, los nicos determinantes son las llaves candidatas,
en otras palabras, en un diagrama de dependencias, las nicas
flechas que existen son las que salen de las llaves candidatas.
Utilidad de la FNBC
La forma normal de Boyce Codd es til para tratar anomalas

que surgen cuando en una relacin o esquema se tiene que hay
varias llaves candidatas, las cuales
Son llaves compuestas (consisten de ms de un atributo)
Las llaves candidatas se traslapan (tienen al menos un
atributo en comn)
Ejemplo
Consideremos una relacin sobre el esquema

ESTUD-MAT-PROF(Matrcula-Estud, Clave-Materia, Nombre-Prof)
en el que una tupla (m, c, n) de la relacin significa que el estudiante
con matrcula m est cursando la materia con clave c con el profesor
de nombre n. Supongamos que las siguientes restricciones se aplican:
Para cada materia, cada estudiante tiene un solo profesor para esa
materia.
Cada profesor ensea una sola materia (no muy acorde con la
realidad).
Dependencias funcionales en el ejemplo
Las dependencias funcionales que se satisfacen son

Matrcula-Estud, Clave-Materia Nombre-Prof
Nombre-Prof Clave-Materia
y tenemos dos llaves candidatas compuestas, a saber
(Matrcula-Estud, Clave-Materia) y
(Matrcula-Estud, Nombre-Prof)
donde hemos escogido la primera como llave primaria.
Instancia de ESTUD-MAT-PROF
Matrcula-Estud
123
123
456
789
999
Clave-Materia
FIS001
MUS001
BIO001
FIS001
FIS001
Nombre-Prof
Einstein
Mozart
Darwin
Bohr
Einstein
Podemos ver que esta relacin est en 3FN pero no en FNBC

porque la dependencia Nombre-Prof Clave-Materia no cumple
con la definicin Qu anomalas tiene esta relacin?
Eliminacin: si el estudiante con matrcula 456 se da de baja de
la materia BIO001, entonces se pierde la informacin de que el
Prof. Darwin ensea esa materia.
Insercin: si queremos incluir el hecho de que el Prof. Corona
ensea la materia COM001, no podemos hacerlo hasta que algn
alumno se inscriba en dicha materia.
Actualizacin: ?
El problema surge porque hay dos llaves candidatas que se
traslapan en el atributo Matrcula-Estud. Esta situacin no es
comn, sin embargo puede aparecer, como en este ejemplo.
Como convertirla a FNBC
RESPUESTA
El atributo Nombre-Prof, que es un determinante pero no una
llave candidata, debe ser colocado en una relacin en la que
sea la llave primaria. Esto puede ser hecho de dos maneras:
Estud-Materia(Matrcula, Clave-Materia) y
Materia-Prof (Clave-Materia, Nombre-Prof)
Estud-Prof (Matrcula-Estud, Nombre-Prof) y
Materia-Prof (Clave-Materia, Nombre-Prof)
EJEMPLO
Consideremos el esquema R(C, D, Z) donde

C = Ciudad, D = Direccin y Z = Cdigo Postal
con dependencias F = {CD Z, Z C}
Este esquema est en 3FN pero no en FNBC porque Z es
un determinante que no es llave.
MAS EJEMPLOS
Sucursal(Nombre-Sucursal, Activo, Ciudad-Sucursal)
Nombre-Sucursal Activo, Ciudad-Sucursal
Cliente(Nombre-Cliente, Calle, Ciudad-Cliente)
Nombre-Cliente Calle, Ciudad-Cliente
Depsito(Nombre-Sucursal, Nmero-Cuenta, Nombre-Cliente,
Saldo)
Nmero-Cuenta Saldo, Nombre-Sucursal
Prstamo(Nombre-Sucursal, Nmero-Prstamo, NombreCliente, Cantidad)
Nmero-Prstamo Cantidad, Nombre-Sucursal
Cules esquemas con las dependencias dadas estn en FNBC?
RESPUESTA
Sucursal: Si, porque las nicas dependencias no triviales tienen el
atributo Nombre-sucursal como determinante, el cual es llave.
Cliente: Si, porque las nicas dependencias no triviales tienen el
atributo Nombre-Sucursal como determinante, el cual es llave.
Depsito: No, porque la dependencia
no es trivial y el atributo Nmero-Cuenta no es llave ya que pueden
tener cuentas mancomunadas.
Qu es una dependencia funcional trivial? Si X Y, entonces
decimos que X Y es es una dependencia funcional trivial porque
siempre se cumple.
Prstamo: No, porque la dependencia

no es trivial y el atributo Nmero-Prstamo no es llave ya
que dependencias funcionales del esquema Prstamo no
excluyen este caso
Cmo descomponer los esquemas Depsito y Prstamo para
lograr FNBC?
DESCOMPOSICIN DEL ESQUEMADEPSITO

Info-Cuenta(Nombre-Sucursal, Nmero-Cuenta, Saldo)
Cuenta-Cliente(Nombre-Cliente, Nmero-Cuenta)
En el esquema Info-Cuenta tenemos que, adems de las
dependencias triviales, se cumple la dependencia
cuyo determinante es llave candidata, por lo tanto est en
FNBC.
Por otro lado, en el esquema Cuenta-Cliente tenemos que
slo las dependencias triviales son vlidas, por lo que est
en FNBC
DESCOMPOSICIN DEL ESQUEMAPRSTAMO

Info-Prstamo(Nombre-Sucursal, Nmero-Prstamo,
Cantidad)
Prstamo-Cliente(Nombre-Cliente, Nmero-Prstamo)
En el esquema Info-Prstamo tenemos que, adems de las
dependencias triviales, se cumple la dependencia
cuyo determinante es llave candidata, por lo tanto est en
FNBC.
Por otro lado, en el esquema Prstamo-Cliente tenemos
que slo las dependencias triviales son vlidas, por lo que
est en FNBC
Ejercicio
Consideremos el esquema R(M, P, H, S, E, C) donde
M = Materia
P = Profesor
H = Horario
S = Saln
E = Estudiante
C = Calificacin
en el que se cumplen las siguientes dependencias funcionales
Dependecias funcionales en R(M, P, H, S, E, C)

M P: cada materia tiene un solo profesor asignado
HS M: solo una materia puede estar en un saln a determinada
hora
HP S: un profesor solo puede estar en un saln a determinada
hora
ME C: cada estudiante obtiene una calificacin en cada materia
HE S: un estudiante solo puede estar en un saln a determinada
hora.
Obtenga la llave primaria del esquema R y descompngalo en la
FNBC.
Algoritmo de descomposicin en 3FN
Sea R un esquema relacional en el que se cumple el conjunto de dependencias funcionales F y sea Fc la

cobertura cannica de F. Este algoritmo conserva dependencias y no se pierde informacin.
i:=0;
for each dependencia funcional X Y en Fc do
if ninguno de los esquemas Rj, j=1,2,,i contiene XY
then begin
i:= i + 1;
Ri:= XY;
end
if ninguno de los esquemas Rj, j=1,2,,i contiene una llave candidata de R
then begin
i:= i + 1;
Ri:= cualquier llave candidata de R;
end
return (R1, R2, , Ri)
Algoritmo de descomposicin en FNBC

Sea R un esquema relacional en el que se cumple el conjunto de dependencias
funcionales F. Este algoritmo no pierde informacin, pero es posible que no se
conserven algunas dependencias.
D:= {R};
listo:= falso;
while (not listo) do
if (existe un esquema S en D que no est en FNBC)
then begin
sea X A una dependencia funcional no trivial
que se cumple en S tal que X no es una llave de S;
D:= (D - S) (A, X) (S - A);
end;
else listo:= verdadero;
Solucin del ejercicio

La nica llave candidata de R es HE.
La dependencia ME C descompone a R en
(M, E, C), ya en FNBC, y (M, P, H, S, E).
La dependencia M P descompone (M, P, H, S, E) en
(M, P), ya en FNBC, y (M, H, S, E).
La dependencia HS M descompone (M, H, S, E) en
(H, S, M) y (H, S, E), ambas en FNBC.
Resumiendo, la descomposicin es:
(M, E, C): calificaciones de los estudiantes en sus materias.
(M, P): el profesor de cada materia.
(H, S, M): el horario de cada materia y el saln correspondiente.
(H, S, E): el saln y horario donde se encuentra el estudiante.
Esquemas de la base de datos relacional

BANCO
DEPSITO(Nombre-Sucursal, Nmero-Cuenta,
Nombre-Cliente, Saldo)
CLIENTE(Nombre-Cliente, Calle, Ciudad-Cliente)
SUCURSAL(Nombre-Sucursal, Activo, Ciudad-Sucursal)
PRSTAMO(Nombre-Sucursal, Nmero-Prstamo,
Nombre-Cliente, Cantidad)
SERVICIO(Nombre-Cliente, Nombre-Banquero)
Instancia de DEPSITO
Nombre-Sucursal Nmero-Cuenta Nombre-Cliente Saldo

Downtown
101
Johnson
500
Mianus
215
Smith
700
Perryridge
102
Hayes
400
Round Hill
305
Turner
350
Perryridge
201
Williams
900
Redwood
222
Lindsay
700
Brighton
217
Green
750
Downtown
105
Green
850
Instancia de CLIENTE
Nombre-Cliente
Jones
Smith
Hayes
Curry
Lindsay
Turner
Williams
Adams
Johnson
Glenn
Brooks
Green
Calle
Main
North
Main
North
Park
Putnam
Nassau
Spring
Alma
Sand Hill
Senator
Walnut
Ciudad-Cliente
Harrison
Rye
Harrison
Rye
Pittsfield
Stamford
Princeton
Pittsfield
Palo Alto
Woodside
Brooklyn
Stamford
Instancia de SUCURSAL
Nombre-Sucursal
Downtown
Redwood
Perryridge
Mianus
Round Hill
Pownal
North Town
Brighton
Activo
Ciudad-Sucursal
9,000,000
Brooklyn
2,100,000
Palo Alto
1,700,000
Horseneck
400,000
Horseneck
8,000,000
Horseneck
300,000
Bennington
3,700,000
Rye
7,100,000
Brooklyn
Instancia de PRSTAMO
Nombre-Sucursal
Downtown
Redwood
Perryridge
Downtown
Mianus
Round Hill
Pownal
North Town
Downtown
Perryridge
Brighton
Nmero-Prstamo
17
23
15
14
93
11
29
16
18
25
10
Nombre-Cliente Cantidad
Jones
1,000
Smith
2,000
Hayes
1,500
Jackson
1,500
Curry
500
Turner
900
Williams
1,200
Adams
1,300
Johnson
2,000
Glenn
2,500
Brooks
2,200
Instancia de SERVICIO
Nombre-Cliente
Turner
Hayes
Johnson
Nombre-Banquero
Johnson
Jones
Johnson
Lenguajes de Consulta
Procedural: el usuario indica como obtener el resultado

deseado.
lgebra relacional
No-procedural: el usuario slo especifica las condiciones que
se deben cumplir en el resultado.
Clculo Relacional
Clculo Relacional de Tuplas
Clculo Relacional de Dominios
lgebra Relacional
Operaciones fundamentales
SELECCIONAR
PROYECTAR
PRODUCTO CARTESIANO
RENOMBRAR
UNIN
DIFERENCIA DE CONJUNTOS
Operaciones unarias
SELECCIONAR: P(R)
Selecciona las tuplas de una relacin (R) que satisfacen un
predicado o condicin (P). Se conservan todos los atributos.
PROYECTAR: Lista-atributos(R)
El resultado es la relacin que conserva slo los atributos
especificados en Lista-atributos. Se eliminan las tuplas repetidas.
RENOMBRAR: NUEVO-NOMBRE(R)
Cambia el nombre de una relacin de R a NUEVO-NOMBRE
Operaciones binarias
PRODUCTO CARTESIANO: R S
El resultado es la relacin que contiene todas las
combinaciones posibles entre las tuplas de la primera relacin
(R) con las tuplas de la segunda relacin (S). El nmero de
columnas es igual a la suma del nmero de columnas de las
dos relaciones. Cuando las relaciones tienen un atributo
comn, entonces se usa un calificativo que identifica la
relacin de la cual proviene.
Ejemplo:
SERVICIO CLIENTE(SERVICIO.Nombre-Cliente,
Nombre-Banquero, CLIENTE.Nombre-Cliente, Calle,
Ciudad-Cliente)
SERVICIO CLIENTE
SERVICIO CLIENTE
(SERVICIO.Nombre-Cliente, Nombre-Banquero, CLIENTE.Nombre-Cliente, Calle,
Ciudad-Cliente)
SERVICIO.
NombreNombreCliente
Banquero
Turner
Turner
Turner
Turner
Turner
Turner
Turner
Turner
Turner
Turner
Turner
Turner
Hayes
Hayes
Hayes
Hayes
Hayes
Hayes
Hayes
Hayes
Hayes
Hayes
Hayes
Hayes
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Jones
Jones
Jones
Jones
Jones
Jones
Jones
Jones
Jones
Jones
Jones
Jones
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
Johnson
CLIENTE.
NombreCliente
Jones
Smith
Hayes
Curry
Lindsay
Turner
Williams
Adams
Johnson
Glenn
Brooks
Green
Jones
Smith
Hayes
Curry
Lindsay
Turner
Williams
Adams
Johnson
Glenn
Brooks
Green
Jones
Smith
Hayes
Curry
Lindsay
Turner
Williams
Adams
Johnson
Glenn
Brooks
Green
Calle
CiudadCliente
Main
North
Main
North
Park
Putnam
Nassau
Spring
Alma
Sand Hill
Senator
Walnut
Main
North
Main
North
Park
Putnam
Nassau
Spring
Alma
Sand Hill
Senator
Walnut
Main
North
Main
North
Park
Putnam
Nassau
Spring
Alma
Sand Hill
Senator
Walnut
Harrison
Rye
Harrison
Rye
Pittsfield
Stamford
Princeton
Pittsfield
Palo Alto
Woodside
Brooklyn
Stamford
Harrison
Rye
Harrison
Rye
Pittsfield
Stamford
Princeton
Pittsfield
Palo Alto
Woodside
Brooklyn
Stamford
Harrison
Rye
Harrison
Rye
Pittsfield
Stamford
Princeton
Pittsfield
Palo Alto
Woodside
Brooklyn
Stamford
PROBLEMA
Encontrar a todos los clientes del banquero Johnson y las
ciudades donde ellos viven.
SERVICIO.Nombre-Cliente, Ciudad-Cliente(
SERVICIO.Nombre-Cliente=CLIENTE.Nombre-Cliente(
Nombre-Banquero=Johnson(SERVICIO CLIENTE)
SERVICIO.Nombre-Cliente Ciudad-Cliente
Turner
Stamford
Johnson
Palo Alto
Problema
Encontrar los nombres de todos los clientes que viven en la misma calle y en la misma
ciudad que el cliente Smith.
???.Nombre-Cliente( P(
CLIENTE ( Calle, Ciudad-Cliente( Nombre-Cliente=Smith(CLIENTE)))))

donde
P es el predicado que requiere que los valores de los dos atributos Calle sean iguales as
como tambin los dos atributos
Ciudad-Cliente, pero Cmo podemos diferenciar entre ellos si ambos provienen de la
misma relacin?
CLIENTE.Nombre-Cliente(
CLIENTE.Calle=CLIENTE2.Calle CLIENTE.Ciudad-Cliente=CLIENTE2.Ciudad-Cliente(
CLIENTE ( Calle, Ciudad-Cliente( Nombre-Cliente=Smith(
CLIENTE2(CLIENTE))))))
Operaciones binarias
UNIN: R S
Es la relacin que contiene las tuplas que pertenecen a una o a ambas
relaciones. Se eliminan tuplas repetidas.
DIFERENCIA: R - S
El resultado es una relacin que consiste de las tuplas que pertenecen a
una relacin (R) pero no a la otra (S).
Tanto para la unin como para la diferencia, las dos relaciones deben
cumplir:
Tener el mismo nmero de atributos.
Los dominios de los atributos correspondientes deben ser idnticos.
Problemas
Encontrar a todos los clientes de la Sucursal Perryridge.
Nombre-Cliente( Nombre-Sucursal=Perryridge(DEPSITO))
Nombre-Cliente( Nombre-Sucursal=Perryridge(PRSTAMO))
Encontrar los clientes de la Sucursal Perryridge que tienen una cuenta pero no un
prstamo.
Encontrar el saldo mayor.
Saldo(DEPSITO) DEPSITO.Saldo(
DEPSITO.SALDO < D.Saldo(DEPSITO D(DEPSITO)))
Operaciones adicionales
INTERSECCIN: R S
Nos da las tuplas que pertenecen a simultneamente a las dos
relaciones R y S.
R S = R - (R - S)
Problema: Encontrar a todos los clientes de la Sucursal
Perryridge que tienen cuenta y prstamo.
JOIN o -JOIN: R F S
Procedimiento para obtener el Join:
Se obtiene el producto cartesiano de las dos relaciones.
Del producto cartesiano, se seleccionan las tuplas que
satisfacen el predicado F
R F S = F (R S)
Si el predicado indica solo igualdad entre atributos,
entonces la operacin es llamada EQUI-JOIN.
JOIN NATURAL: R S
Es una equi-reunin en el cual se comparan todos los atributos
con los mismos nombres en las dos relaciones. Se eliminan los
atributos duplicados.
Problema
Obtener el nombre y ciudad donde viven de todos los clientes

que tienen un prstamo en el banco.
Solucin 1:
CLIENTE.Nombre-Cliente, Ciudad-C liente(
CLIENTE.Nombre-Cliente = PRSTAMO.Nombre-Cliente(
CLIENTE PRSTAMO))
Solucin 2:
Nombre-Cliente, Ciudad-C liente(CLIENTE

Nombre-Cliente
Jones
Smith
Hayes
Curry
Turner
Williams
Adams
Johnson
Glenn
Brooks
PRSTAMO)
Ciudad-Cliente
Harrison
Rye
Harrison
Rye
Stamford
Princeton
Pittsfield
Palo Alto
Woodside
Brooklyn
Problemas
Obtener el activo de todas las sucursales que tienen cuentahabientes que viven en
Stamford.
Nombre-Sucursal, Activo(
Ciudad-Cliente = Stamford(
CLIENTE DEPSITO SUCURSAL))
Nombre-Sucursal
Activo
Hilllos clientes que tienen
8,000,000
Obtener el nombreRound
de todos
una cuenta y un prstamo en la
Brighton
7,100,000
sucursal Perryridge.
Downtown
9,000,000
Nombre-Cliente(
Nombre-Sucursal = Perryridge(PRSTAMO DEPSITO))
Definicin formal del Join Natural
R S = Atr(R) Atr(S)(
(R.A1=S.A1) (R.A2=S.A2)... (R.An=S.An)(R S))

donde
Atr(R) Atr(S) = {A1, A2, , An}
Problema
Encontrar a todos los clientes que tienen cuenta en todas las sucursales de Brooklyn.
R1 = Sucursales de Brooklyn =
Nombre-Sucursal( Ciudad-Sucurasl=Brooklyn(SUCURSAL)) =
R2 = Clientes con cuenta y sucursal donde tienen la cuenta =

Nombre-Sucursal
Nombre-Cliente, Nombre-Sucursal(DEPSITO)
=
Brighton
Downtown
Nombre-Cliente
Johnson
Respuesta = R2 R1 = Smith
Hayes
Turner
Williams
Lindsay
Green
Green
Nombre-Sucursal
Downtown
Mianus
Perryridge
Round Hill
Perryridge
Redwood
Brighton
Downtown
Nombre-Cliente
Green
Divisn: Sean R y S relaciones tales que Atr(S) Atr(R).
Entonces R S es una relacin que satisface:
Atr(R S) = Atr(R) - Atr(S)
Una tupla t pertenece a R S
si para cada tupla ts S existe una tupla tr R tales que:
tr[Atr(S)] = ts[Atr(S)]
tr[Atr(R) - Atr(S)] = t[Atr(R) - Atr(S)]
Formalmente:
R S = Atr(R) - Atr(S)(R) - Atr(R) - Atr(S)(( Atr(R) - Atr(S)(R) S) - R)
Proceso para obtener paso por paso R2 R1

R2 R1 =
Atr(R2) - Atr(R1)(R2) - Atr(R2) - Atr(R1)(( Atr(R2) - Atr(R1)(R2) R1) - R2)
Obtenga Atr(R2) - Atr(R1)(R2)
Obtenga Atr(R2) - Atr(R1)(R2) R1
Obtenga ( Atr(R2) - Atr(R1)(R2) R1) - R2
Obtenga
Atr(R2) - Atr(R1)(R2)
Atr(R2) - Atr(R1)(( Atr(R2) - Atr(R1)(R2) R1) - R2)
Obtenga
Atr(R2) - Atr(R1)(R2) - Atr(R2) - Atr(R1)(( Atr(R2) - Atr(R1)(R2) R1) - R2)
Asignacin: se utiliza para escribir por partes una expresin

de lgebra relacional, asignando resultados intermedios a
relaciones definidas temporalmente. Se usa el smbolo para
denotar esta operacin.
Ejemplo:
Si TEMP Atr(R) - Atr(S)(R), entonces
R S = TEMP - Atr(R) - Atr(S)(TEMP S) - R)
Nota: es conveniente utilizar la asignacin para simplificar
expresiones algebraicas complejas.
Modificacin de la base de datos

Eliminacin: R R - E donde R es una relacin y E es una expresin en lgebra
relacional o el resultado de una consulta.
Ejemplo: Eliminar todas la cuentas de Smith
DEPSITO DEPSITO - Nombre-Cliente=Smith(DEPSITO)
Ejemplo: Eliminar todos los prstamos con nmero entre 1300 y 1500.
PRSTAMO PRSTAMO - 1300Nmero-Prstamo1500(PRSTAMO)
Ejemplo: Eliminar todas las cuentas de las sucursales situadas en Needham.

R1 Ciudad-Sucursal=Needham(DEPSITO SUCURSAL)
R2 Nombre-Sucursal, Nmero-Cuenta, Nombre-Cliente, Saldo(R1)
DEPSITO DEPSITO - R2

Insercin: R R E donde R es una relacin y E es una expresin en lgebra
relacional o el resultado de una consulta.
Problema: Incluir el hecho de que Smith tiene una cuenta en la sucursal Perryridge con
saldo $1,200.00 dlares.
DEPSITO DEPSITO {(Perryridge, 9732, Smith, 1200)}
Problema: Proporcionar una cuenta con $200.00 dlares a todos los clientes que tienen un
prstamo en la sucursal Perryridge. El nmero de la cuenta debe ser igual al nmero de
prstamo.
R1 Nombre-Sucursal=Perryridge(PRSTAMO)
R2 Nombre-Sucursal, Nmero-Prstamo, Nombre-Cliente(R1)
DEPSITO DEPSITO (R2 {200})
Actualizacin: AE(R) donde R es una relacin, A es un atributo de R al cual se le asigna el

valor de la expresin E.
Problema: Pagar 5% de inters a todos los depsitos.
Saldo1.05 Saldo(DEPSITO)
Problema: Las cuentas con saldos mayores a $10,000.00 dlares reciben un inters de 6%, el
resto slo de 5%.
Saldo1.06 Saldo( Saldo > 10000(DEPSITO))
Saldo1.05 Saldo( Saldo 10000(DEPSITO))
En este ltimo ejemplo es importante el orden en que se hacen las actualizaciones porque si se
hicieran en el orden opuesto, entonces puede ocurrir que cuentas con saldo un poquito menor
a $10,000.00 dlares (entre $9,523.81 y $10,000 dlares) recibiran un inters de 11.3%
Clculo Relacional
De tuplas: {t | F(t)} donde t es una variable de tupla y F es

una frmula o predicado.
De dominios: {x1, x2, ..., xn | F(x1, x2, ..., xn)} donde las xs son
variables de dominio y F es un frmula o predicado.
Codd demostr que el clculo relacional y el lgebra
relacional son equivalentes, en trminos de poder expresivo.
Ejemplo
Encontrar Nombre-Sucursal, Nmero-Prstamo, Nombre-Cliente y
Cantidad para prstamos mayores a $1200.00 dlares.
Clculo relacional de tuplas
{t | t PRSTAMO t[Cantidad] > 1200}
Clculo relacional de dominios
{<b, l, c, a> | < b, l, c, a > PRSTAMO a > 1200}
Si solamente queremos Nombre-Cliente
{t | s PRSTAMO (t[Nombre-Cliente] = s[Nombre-Cliente]
s[Cantidad] > 1200)}
{<c> | b, l, a (< b, l, c, a > PRSTAMO a > 1200)}
Ejemplo
Encontrar a todos los clientes que tienen un prstamo en la
Sucursal Perryridge y las ciudades donde viven.
s[Nombre-Sucursal] = Perryridge
u CLIENTE (u[Nombre-Cliente] = s[Nombre-Cliente]
t[Ciudad-Cliente] = u[Ciudad-Cliente]))}
{<c, x> | b, l, a(<b, l, c, a> PRSTAMO b = Perryridge
y(<c, y, x> CLIENTE))}
Nombre-Cliente Ciudad-Cliente
Hayes
Harrison
Glenn
Woodside
Ejemplo
Encontrar a todos los clientes que tienen un prstamo y/o una
cuenta en la sucursal Perryridge.
s[Nombre-Sucursal] = Perryridge)
u DEPSITO (t[Nombre-Cliente] = u[Nombre-Cliente]
u[Nombre-Sucursal] = Perryridge)}
{<c> | b, l, a(<b, l, c, a> PRSTAMO b = Perryridge)
B, A, N (<B, A, c, N> DEPSITO B = Perryridge)}
Nombre-Cliente
Hayes
Glenn
Williams
Ejemplo
Encontrar a todos los clientes que tienen una cuenta en todas
las sucursales de Brooklyn.
{t | u SUCURSAL (u[Ciudad-Sucursal] = Brooklyn
s DEPSITO (t[Nombre-Cliente] = s[Nombre-Cliente]
u[Nombre-Sucursal] = s[Nombre-Sucursal]))}
{<c> | x, y, z ((<x, y, z> SUCURSAL) z Brooklyn
( a, n (<x, a, c, n> DEPSITO)))}
Nombre-Cliente
Green
SQL: Structured Query Language
Lenguaje no-procedural de Cuarta Generacin (?)

Sequel (Structured English QUEry Language): precursor de
SQL, desarrollado para System R en el Centro de
Investigacin de IBM en San Jos, Cal. a principios de los
70s.
Es el lenguaje para bases de datos relacionales.
Lenguajes de 4a. generacin

Un lenguaje de "aplicacin especfica". El trmino fue inventado por Jim Martin para
referirse a lenguajes de alto nivel no-procedurales construidos alrededor de sistemas de
bases de datos. Las primeras tres generaciones fueron desarrolladas muy rpidamente,
pero an el programar computadoras era frustrante, lento y sujeto a errores, llevando esto
a la primera "crisis de programacin", en la cual la cantidad de trabajo que poda ser
asignada a los programadores exceda en mucho la cantidad de tiempo de programacin
disponible para hacerla. Mientras tanto, mucha experiencia se desarroll en ciertas reas y
se vio claro que ciertas aplicaciones podan generalizarse aadindoles lenguajes de
programacin limitados. As nacieron los lenguajes generadores de reportes, a los cuales
se les alimentaba una descripcin del formato de los datos y del reporte que deberan
generar y lo convertan en un programa de COBOL u otro lenguaje el cual realmente
contena las instrucciones para leer y procesar los datos y colocar los resultados en la
pgina.
Lenguajes de Cuarta Generacin:
SQL, Focus, Metafont, PostScript, RPG-II, S, IDL-PV/WAVE, Gauss, Mathematica, AVS,
APE, Iris Explorer.
Estndares ANSI para SQL
ANSI (American National Standards Institute)

Especificar sintaxis y semntica para DDL y DML.
Definir la estructura de datos y operaciones bsicas.
Diseo, acceso, mantenimiento, control y proteccin.
Proveer portabilidad de aplicaciones y definicin de una
base de datos.
Especificar estndares mnimos y completos para permitir
diferentes grados de adopcin en productos.
Proveer un estndar inicial el cual puede ser ampliado
posteriormente.
IBM Testimonial on SQL Standards

SQL is a widely used computer application that permits a user at a computer to
request in a simple, easy-to-understand and use manner virtually any information
from a database. SQL's success is due largely to the voluntary national and
international standards that have been developed to define it. In late 1986, ANSI
(the American National Standards Institute) published the first edition of a formal
standard for SQL as ANSI X3.135-1986; a couple of months later, ISO (the
International Organization for Standardization) published an identical document as
ISO 9075-1987; the document was informally known as SQL-86 (or SQL-87).
In late 1992, a major revision of the SQL standard was published as ANSI X3.1351992 and ISO/IEC 9075:1992, and commonly called SQL-92. This standard has
proved to be a major event in database standardization history. For the first time, it
became possible to write significant applications entirely in a standard language,
although it was and is true that no vendor implemented the entire language. The
focus of SQL-92 was to standardize enough language to allow significant
applications to built without depending on vendor extensions to SQL.
The results have been phenomenal. SQL standards are the foundation of a multibillion dollar industry employing thousands of people in the United States. In fact,
SQL arguably represents one of the most successful standards in existence.
http://www.x3.org/testimonials/ibm.htm
Estndares
Son buenos? Malos? Todo lo contrario?
Ventajas
Se reducen los costos de entrenamiento.
Portabilidad de las aplicaciones.
Longevidad de las aplicaciones.
Poca dependencia de un slo proveedor.
Comunicacin inter-sistemas.
Desventajas
Limita la creatividad y la innovacin.
Nunca se satisfacen todas las necesidades.
Lejos de ser un sistema ideal: resultado de un compromiso entre varios participantes.
Difcil de cambiarlo: intereses creados por proveedores poderosos.
Arreglar deficiencias puede requerir un esfuerzo considerable.
C.J.Date: en el estndar ANSI de SQL se omitieron aspectos importantes y es
extremadamente redundante.
Componentes de SQL
Lenguaje de Definicin de Datos (DDL): instrucciones para

definir, modificar, borrar esquemas relacionales, crear vistas y
definir privilegios.
Lenguaje de Manipulacin de Datos Interactivo (DML):
lenguaje de consulta basado en el lgebra y Clculo relacional
de tuplas. Tambin permite insertar, borrar y modificar tuplas.
Lenguaje de Manipulacin de Datos inmerso o incrustado:
permite incluir instrucciones de SQL en lenguajes de
programacin de propsito general o tercera generacin.
Permite la definicin de restricciones de integridad.
Permite definir el inicio y fin de transacciones.
Esquema de la base de datos relacional

COMPAIA
EMPLEADO(NOMBREP, INIC, APELLIDO, NSS, FECHAN, DIRECCION,
SEXO, SALARIO, NSSSUPER, ND)
DEPARTAMENTO(NOMBRED, NUMEROD, NSSGTE, FECHAINICGTE)
LUGARES_DEPTOS(NUMEROD, LUGARD)
PROYECTO(NOMBREP, NUMEROP, LUGARP, NUMD)
TRABAJA_EN(NSSE, NUMP, HORAS)
DEPENDIENTE(NSSE, NOMBRE-DEPENDIENTE, SEXO, FECHAN,
PARENTESCO)
Instancias de los esquemas de COMPAA

NOMBREP INIC APELLIDO
Jos
B Silva
Federico
T Vizcarra
Alicia
J Zapata
Jazmn
S Valds
Ramn
K Nieto
Josefa
A Esparza
Ahmed
V Jabbar
Jaime
E Botello
NSS
123456789
333445555
999887777
987654321
666884444
453453453
987987987
888665555
FECHAN
09-Ene-55
08-Dic-45
19-Jul-58
20-Jun-31
15-Sep-52
31-Jul-62
29-Mar-59
10-Nov-27
DIRECCION
SEXO SALARIO NSSSUPER
Fresnos 731, Higueras, MX M
30000
33344555
Valle 638, Higueras, MX
M
40000
888665555
Castillo 3321, Sucre, MX
F
25000
987654321
Bravo 291, Beln, MX
F
43000
888665555
Espiga 875, Heras, MX
M
38000
333445555
Rosas 5631, Higueras, MX
F
25000
333445555
Dalias 980, Higueras, MX
M
25000
987654321
Sorgo 450, Higueras, MX
M
55000
NULO
EMPLEADO
NOMBRED NUMEROD NSSGTE FECHAINICGTE

Investigacin
5
333445555
22-May-78
Administracin
4
987654321
01-Ene-85
Direccin
1
888665555
19-Jun-71
DEPARTAMENTO
NUMEROD
1
4
5
5
5
LUGARD
Higueras
Santiago
Beln
Sacramento
Higueras
LUGARES_DPTOS
ND
5
5
4
4
5
5
4
1
Instancias de los esquemas de COMPAA

NSSE
123456789
123456789
666884444
453453453
453453453
333445555
333445555
333445555
333445555
999887777
999887777
987987987
987987987
987654321
987654321
888665555
NUMP
1
2
3
1
2
2
3
10
20
30
10
10
30
30
20
20
TRABAJA_EN
HORAS
32.5
7.5
40.0
20.0
20.0
10.0
10.0
10.0
10.0
30.0
10.0
35.0
5.0
20.0
15.0
NULO
NOMBREP
NUMEROP LUGARP NUMD
ProductoX
1
Beln
5
ProductoY
2
Sacramento
5
ProductoZ
3
Higueras
5
Automatizacin
10
Santiago
4
Reorganizacin
20
Higueras
1
Nuevasprestaciones
30
Santiago
4
PROYECTO
NSSE
NOMBRE-DEPENDIENTE SEXO FECHAN PARENTESCO
333445555
Alicia
F
05-Abr-76
Hija
333445555
Teodoro
M
25-Oct-73
Hijo
333445555
Jovita
F
03-May-48
Cnyuge
987654321
Abdiel
M
29-Feb-32
Cnyuge
123456789
Miguel
M
01-Ene-78
Hijo
123456789
Alicia
F
31-Dic-78
Hija
123456789
Elizabeth
F
05-May-57
Cnyuge
DEPENDIENTE
DDL en SQL
Definicin del nombre del esquema de la base de datos
CREATE SCHEMA COMPAA AUTHORIZATION JSILVA
Definicin del esquema de una relacin o tabla base
CREATE TABLE EMPLEADO
CREATE TABLE COMPAA.EMPLEADO
Definicin del esquema de una vista o relacin virtual
CREATE VIEW TRABAJA_EN
Definicin de restricciones
Llave primaria: PRIMARY KEY
Llave candidata: UNIQUE
Integridad referencial: FOREIGN KEY
Eliminacin de esquemas o tablas
DROP SCHEMA COMPAA CASCADE (RESTRICT);
DROP TABLE DEPENDIENTE CASCADE (RESTRICT);
Aadir o eliminar columnas
ALTER TABLE COMPAA.EMPLEADO ADD PUESTO VARCHAR(12);
ALTER TABLE COMPAA.EMPLEADO DROP DIRECCIN CASCADE
(RESTRICT);
Estructura bsica de una consulta en SQL

SELECT <lista de atributos deseados>
FROM <lista de tablas o vistas>
WHERE <condiciones que se deben cumplir>
Alternativamente,
SELECT A1, A2, ..., An
FROM R1, R2, ..., Rm
WHERE P
Algebra relacional:
SELECT equivale a proyectar
FROM equivale a producto cartesiano
WHERE equivale a seleccionar
A1, A2, ...An( P(R1 R2 ... Rm))
Encuentre los nombres de todas las sucursales en la relacin
DEPSITO:
SELECT Nombre-Sucursal FROM DEPSITO
SQL permite duplicados, por lo que si queremos evitarlas:
SELECT DISTINCT Nombre-Sucursal FROM DEPSITO
Consultas a la base de datos COMPAA

1) Obtener la fecha de nacimiento y la direccin del empleado cuyo
nombre es Jos B. Silva.
2) Obtener el nombre completo y la direccin de todos los empleados
que pertenecen al departamento Investigacin.
3) Para cada proyecto ubicado en Santiago, listar el nmero de
proyecto, el nmero del departamento controlador y el apellido, la
direccin y la fecha de nacimiento del gerente de ese departamento.
Cuando haya lugar a confusin porque varias relaciones utilicen el
mismo nombre de atributo, entonces anteponer el nombre de la
relacin al nombre del atributo.
4) Reformular la consulta 2) suponiendo que en la relacin EMPLEADO
los atributos ND y APELLIDO se llaman NMEROD y NOMBRE,
respectivamente, y que el atributo NOMBRED de la relacin
DEPARTAMENTO tambin se llama NOMBRE.
5) Para cada empleado, obtener su nombre de pila y apellido y el nombre
de pila y apellido del supervisor inmediato.
Respuestas en SQL a las consultas sobre

COMPAA
1) SELECT FECHAN, DIRECCIN
FROM EMPLEADO
WHERE NOMBREP=Jose AND INIC=B AND APELLIDO=Silva
2) SELECT NOMBREP, INIC, APELLIDO, DIRECCIN
FROM EMPLEADO, DEPARTAMENTO
WHERE NOMBRED=Investigacin AND NMEROD=ND
3) SELECT NMEROP, NMD, APELLIDO, DIRECCIN, FECHAN
FROM PROYECTO, DEPARTAMENTO, EMPLEADO
WHERE NMD=NMEROD AND NSSGTE=NSS AND LUGARP=Santiago
4) SELECT NOMBREP, INIC, EMPLEADO.NOMB RE, DIRECCIN
WHERE DEPARTAMENTO.NOMBRE=Investigacin AND
DEPARTAMENTO.NMEROD=EMPLEADO.NMEROD
5) SELECT E.NOMBREP, E.APELLIDO, S.NOMBREP, S.APELLIDO
FROM EMPLEADO E, EMPLEADO S
WHERE E.NSSSUPER=S.NSS
Consultas a la base de datos BANCO

(lmina 130)
1) Encuentre los nombres de todas la sucursales en la relacin DEPSITO.
2) SQL permite tuplas duplicadas. Reformule la consulta 1) para evitar las
duplicaciones.
3) Encontrar a todos los clientes que tienen una cuenta y/o un prstamo en la
4) Encontrar a todos los clientes que tienen una cuenta y un prstamo en la sucursal
Perryridge.
5) Encontrar a todos los clientes que tienen una cuenta pero no un prstamo en la
6) Encuentre el nombre y la ciudad de todos los clientes que tienen un prstamo en
alguna sucursal.
7) Encuentre el nombre y la ciudad de todos los clientes que tienen un prstamo en
la sucursal Perryridge.
8) Encontrar el nmero de cuenta de todas las cuentas con saldos entre $90,000.00
y $100,000.00
Respuestas en SQL a las consultas sobre BANCO

1) SELECT Nombre-Sucursal FROM DEPSITO
2) SELECT DISTINCT Nombre-Sucursal FROM DEPSITO
3) (SELECT DISTINCT Nombre-Cliente FROM DEPSITO
WHERE Nombre-Sucursal=Perryridge)
UNION
(SELECT DISTINCT Nombre-Cliente FROM PRSTAMO
Como la operacin UNION elimina duplicados, DISTINCT no es necesario.
INTERSECT
MINUS
Respuestas en SQL a las consultas sobre BANCO

6) SELECT DISTINCT CLIENTE.Nombre-Cliente, Ciudad-Cliente
FROM PRSTAMO, CLIENTE
WHERE PRSTAMO.Nombre-Cliente=CLIENTE.Nombre-Cliente
7) SELECT DISTINCT CLIENTE.Nombre-Cliente, Ciudad-Cliente
FROM PRSTAMO, CLIENTE
AND Nombre-Sucursal=Perryridge
8) Solucin a:
SELECT Nmero-Cuenta
FROM DEPSITO
WHERE Saldo100000 AND Saldo90000
Solucin b:
SELECT Nmero-Cuenta
FROM DEPSITO
WHERE Saldo BETWEEN90000 AND 100000
Uso de * y ausencia de WHERE
* significa todos los atributos.
Qu se obtiene en cada una de las siguientes expresiones?

1) SELECT NSS
FROM EMPLEADO
2) SELECT NSS, NOMBRED
3) SELECT *
FROM EMPLEADO
WHERE ND=5
4) SELECT *
WHERE NOMBRED=Investigacin AND ND=NMEROD
5) SELECT *
6) SELECT SALARIO
FROM EMPLEADO
7) SELECT DISTINCT SALARIO
FROM EMPLEADO
Respuestas a Qu se obtiene?
1) El Nmero de Seguridad Social de todos los empleados.
2) Todas las combinaciones posibles entre los Nmeros de Seguridad Social de
todos los empleados con los Nmeros de Departamento de todos los
departamentos.
3) Todos los datos de los empleados que trabajan en el departamento nmero 5.
4) Todos los datos de los empleados que trabajan en el departamento
Investigacin as como los datos de este departamento.
5) Todas las tuplas de EMPLEADO combinadas con todas las tuplas de
DEPARTAMENTO (EMPLEADO DEPARTAMENTO)
6) Los salarios de todos los empleados, se incluyen duplicados.
7) Los salarios de todos los empleados sin listar duplicados.
Caracteres especiales. Base de datos BANCO

Consultas
1) Encontrar los nombres de todos los clientes cuya calle incluye la cadena Main.
2) Encontrar los nombres de todos los clientes cuya calle tiene cuatro letras empezando
con M.
3) Cmo incluir los caracteres especiales % y _?
Respuestas
1) SELECT Nombre-Cliente
FROM CLIENTE
WHERE Calle LIKE %Main%
2) SELECT Nombre-Cliente
FROM CLIENTE
WHERE Calle LIKE M_ _ _
3) LIKE ab\%cd% ESCAPE \: cadena que empiece con ab%cd
LIKE ab\_cd% ESCAPE \ cadena que empiece con ab_cd
Consultas
Uso de IN(tR) y NOT IN(tR)
1) Encontrar a todos los clientes que tienen una cuenta y un prstamo en la sucursal Perryridge.
2) Encontrar a todos los clientes que tienen una cuenta pero no un prstamo en la sucursal Perryridge.
Respuestas
1.a) SELECT DISTINCT Nombre-Cliente FROM PRSTAMO
WHERE Nombre-Sucursal=Perryridge AND
Nombre-Cliente IN (SELECT Nombre-Cliente FROM DEPSITO
1.b) SELECT DISTINCT Nombre-Cliente FROM PRSTAMO
<Nombre-Sucursal, Nombre-Cliente> IN (SELECT Nombre-Sucursal,
DEPSITO)
2) SELECT DISTINCT Nombre-Cliente FROM DEPSITO
Nombre-Cliente NOT IN (SELECT Nombre-Cliente FROM PRSTAMO
Nombre-Cliente FROM
Variables de tupla
Consultas
1) Encuentre el nombre y la ciudad de todos los clientes que tienen un prstamo en alguna sucursal.
2) Encuentre a todos los clientes que tienen una cuenta en alguna sucursal donde Jones tiene una cuenta.
Respuestas
1) SELECT DISTINCT T.Nombre-Cliente, Ciudad-Cliente
FROM PRSTAMO S, CLIENTE T
WHERE S.Nombre-Cliente=T.Nombre-Cliente
2.a) SELECT DISTINCT T.Nombre-Cliente
FROM DEPSITO S, DEPSITO T
WHERE S.Nombre-Cliente=Jones AND
S.Nombre-Sucursal=T.Nombre-Sucursal
2.b) SELECT DISTINCT Nombre-Cliente FROM DEPSITO
WHERE Nombre-Sucursal IN (SELECT Nombre-Sucursal
FROM DEPSITO
WHERE Nombre-Cliente=Jones)
Consultas
Comparacin de conjuntos
1) Encuentre los nombres de todas las sucursales que tienen un activo mayor que alguna de las sucursales de
Brooklyn.
2) Encuentre los nombres de todas las sucursales que tienen un activo mayor que todas las sucursales de Brooklyn.
Respuestas
1.a) SELECT DISTINCT T.Nombre-Sucursal
FROM SUCURSAL T, SUCURSAL S
WHERE T.Activo> S.Activo AND S.Ciudad-Sucursal=Brooklyn
1.b) SELECT Nombre-Sucursal FROM SUCURSAL
WHERE Activo > SOME (SELECT Activo FROM SUCURSAL
WHERE Ciudad-Sucursal=Brooklyn)
Se permite el uso de < SOME, SOME, SOME, = SOME, SOME
2) SELECT Nombre-Sucursal FROM SUCURSAL
WHERE Activo > ALL (SELECT Activo FROM SUCURSAL
WHERE Nombre-Sucursal=Brooklyn
Se permite el uso de < ALL, ALL, ALL, = ALL, ALL
CONTAINS(R1 R2), EXISTS(R)
Consultas
1) Encuentre el nombre de todos los clientes que tienen una cuenta en todas las sucursales de Brooklyn.
2) Encuentre el nombre de todos los clientes que tienen una cuenta y un prstamo en la sucursal Perryridge
Respuestas
1)SELECT DISTINCT S.Nombre-Cliente FROM DEPSITO S
WHERE (SELECT T.Nombre-Sucursal FROM DEPSITO T
WHERE S.Nombre-Cliente=T.Nombre-Cliente)
CONTAINS (SELECT Nombre-Sucursal FROM Sucursal
2)SELECT Nombre-Cliente FROM CLIENTE
WHERE EXISTS (SELECT * FROM DEPSITO
WHERE DEPSITO.Nombre-Cliente=CLIENTE.Nombre-Cliente
AND Nombre-Sucursal=Perryridge )
AND EXISTS (SELECT * FROM PRSTAMO
WHERE prstamo.Nombre-Cliente=CLIENTE.Nombre-Cliente
AND Nombre-Sucursal=Perryridge)
Consultas
NOT EXISTS (R=)
1) Encuentre el nombre de todos los clientes que tienen una cuenta pero no un prstamo en la sucursal Perryridge.
2) Encuentre el nombre de todos los clientes que tienen una cuenta en todas las sucursales de Brooklyn.
Respuestas
1) SELECT Nombre-Cliente FROM CLIENTE
WHERE EXISTS (SELECT * FROM DEPSITO
AND NOT EXISTS (SELECT * FROM PRSTAMO
2) SELECT DISTINCT S.Nombre-Cliente FROM DEPSITO S
WHERE NOT EXISTS ((SELECT Nombre-Sucursal FROM SUCURSAL
MINUS (SELECT T.Nombre-Sucursal FROM DEPSITO T
WHERE S.Nombre-Cliente=T.Nombre-Cliente))
ORDER BY (Ordena el resultado de una consulta)

Consultas
1) Listar en orden alfabtico el nombre de los clientes que tienen un prstamo en la sucursal
Perryridge.
2) Listar la relacin PRSTAMO de acuerdo a la cantidad del prstamo en orden ascendente y,
en caso de prstamos por la misma cantidad, ordenarlos de acuerdo al nmero de prstamo
en orden descendente.
Respuestas
1) SELECT DISTINCT Nombre-Cliente
FROM PRSTAMO
WHERE Nombre-Sucursal=Perryridge
ORDER BY Nombre-Cliente
2) SELECT *
FROM PRSTAMO
ORDER BY Cantidad ASC, Nmero-Prstamo DESC
Nota: El valor por omisin del ordenamiento es ASC.
GROUP BY (agrupa las tuplas que tengan el mismo

valor en todos los atributos indicados en la clusula)
Funciones de agregacin: se definen sobre los grupos de tuplas obtenidos con la clusula
GROUP BY.
AVG: promedio
MIN: mnimo
MAX: mximo
SUM: total
COUNT: contar
Consultas
1) Encontrar el saldo promedio de las cuentas en cada sucursal.
2) Encontrar cuantos clientes, con al menos una cuenta, tiene cada sucursal.
Respuestas
1) SELECT Nombre-Sucursal, AVG(SALDO) FROM DEPSITO
GROUP BY Nombre-Sucursal
2) SELECT Nombre-Sucursal, COUNT (DISTINCT Nombre-Cliente) FROM DEPSITO
GROUP BY Nombre-Sucursal
HAVING (expresa una condicin sobre grupos de

tuplas en lugar de sobre tuplas individuales)
Consultas
1)
2)
3)
4)
Listar todas las sucursales que tienen un saldo promedio mayor que $1,200.00
Encontrar las sucursales que tienen el mayor saldo promedio.
Obtener el saldo promedio de todas las cuentas del banco.
Encontrar el nmero de tuplas en la relacin CLIENTE.
Respuestas
1) SELECT Nombre-Sucursal, AVG(Saldo) FROM DEPSITO
GROUP BY Nombre-Sucursal HAVING AVG(Saldo)>1200
2) SELECT Nombre-Sucursal FROM DEPSITO GROUP BY Nombre-Sucursal
HAVING AVG(Saldo) ALL (SELECT AVG(Saldo) FROM DEPSITO
GROUP BY Nombre-Sucursal)
Nota: SQL no permite composicin de funciones por lo que MAX(AVG(Saldo)) no es vlido.
3) SELECT AVG(Saldo) FROM DEPSITO
4) SELECT COUNT(*) FROM CLIENTE
WHERE y HAVING
Cul primero? HAVING
Consulta
Obtenga el saldo promedio de todos los cuenta-habientes que viven en
Harrison y que tienen al menos tres cuentas.
Respuesta
SELECT AVG(Saldo)
FROM DEPSITO, CLIENTE
AND Ciudad-Cliente=Harrison
GROUP BY DEPSITO.Nombre-Cliente
HAVING COUNT(DISTINCT Nmero-Cuenta) 3
Eliminaciones
Eliminar de la relacin R las tuplas que satisfacen el predicado P
DELETE R WHERE P
Borre todas las cuentas de Smith
DELETE DEPSITO
WHERE Nombre-Cliente=Smith
Borre los prstamos con nmero entre 1300 y 1500
DELETE PRSTAMO
WHERE Nmero-Prstamo BETWEEN 1300 AND 1500
Borre todas las cuentas de las sucursales de Perryridge
DELETE DEPSITO
WHERE Nombre-Sucursal IN
(SELECT Nombre-Sucursal FROM SUCURSAL
WHERE Ciudad-Sucursal=Perryridge)
Borre las cuentas con saldo menor que el promedio.
La expresin en SQL podra ser
DELETE DEPSITO
WHERE Saldo < (SELECT AVG(Saldo) FROM DEPSITO)
Sin embargo el estndar ANSI de SQL no lo permite porque el resultado
dependera del orden en que se procesen las tuplas.
Modificaciones a la Base de Datos: Inserciones
Incluir que Smith tiene la cuenta 9732 con $1,200.00 en la sucursal Perryridge
INSERT INTO DEPSITO
VALUES (Perryridge, 9732, Smith, 1200)
Si no conociramos el orden de los atributos
INSERT INTO DEPSITO(Nombre-Sucursal, Nmero-Cuenta,
Nombre-Cliente, Saldo)
VALUES (Perryridge, 9732, Smith, 1200)
INSERT INTO DEPSITO(Nmero-Cuenta, Nombre-Cliente,
Nombre-Sucursal, Saldo)
VALUES (9732, Smith, Perryridge, 1200)
Darle a los clientes que tienen prstamo una cuenta en la sucursal Perryridge con $200.00 y nmero igual al nmero de
prstamo
INSERT INTO DEPSITO
SELECT Nombre-Sucursal, Nmero-Prstamo, Nombre-Cliente, 200
FROM PRSTAMO WHERE Nombre-Sucursal=Perryridge
El estndar ANSI de SQL no permite insertar tuplas a una relacin mencionada en el SELECT. Por ejemplo, el resultado de
INSERT INTO DEPSITO
SELECT * FROM DEPSITO
podra ser un loop infinito.
Modificaciones a la Base de Datos:Actualizaciones

Pagarles un inters de 5% a todas las cuentas
UPDATE DEPSITO
SET SALDO = SALDO*1.05
Pagarles un inters de 6% a todas las cuentas con un saldo mayor a $10,000.00, al
resto slo 5%
UPDATE DEPSITO SET SALDO = SALDO*1.06
WHERE SALDO > 10000
WHERE SALDO 10000
Nota: el orden de las actualizaciones es importante.
El estndar ANSI de SQL no permite modificar tuplas a una relacin mencionada en el
SELECT. Por ejemplo, el resultado de
WHERE SALDO > SELECT AVG(SALDO) FROM DEPSITO
dependera del orden en que se procesen las tuplas.
VALORES NULOS: NULL

Abrir una cuenta con $1,200.00 para Smith sin tener an el nmero de cuenta
INSERT INTO DEPSITO
VALUES (Perryride, NULL, Smith, 1200)
Comparaciones con NULL son falsas por definicin. Por ejemplo
SELECT * FROM DEPSITO
WHERE Nmero-Cuenta=1700
No analiza la cuenta insertada en la solicitud anterior.
S se puede buscar explcitamente el valor NULL, por ejemplo
SELECT DISTINCT Nombre-Cliente
FROM PRSTAMO
WHERE CANTIDAD IS NULL
da como resultado los nombres de los clientes en la relacin PRSTAMO que tienen el valor NULL
en el atributo Cantidad.
Las funciones de agregacin, excepto COUNT, ignoran las tuplas con valores en los atributos
utilizados como argumento. Por ejemplo
SELECT SUM(CANTIDAD) FROM PRSTAMO
No considera las tuplas con valor NULL en el atributo Cantidad.
Vistas
Creacin de vistas:
CREATE VIEW NOMBRE-VISTA AS <Consulta>
Crear la vista TODOS-CLIENTES la cual incluye el nombre de todos los clientes con su correspondiente
sucursal
CREATE VIEW TODOS-CLIENTES AS
(SELECT Nombre-Cliente, Nombre-Sucursal FROM DEPSITO)
UNION
(SELECT Nombre-Cliente, Nombre-Sucursal FROM PRSTAMO)
Una vista puede usarse como si fuera una relacin. Encontrar a todos los clientes de la sucursal Perryridge
SELECT Nombre-Cliente FROM TODOS-CLIENTES
WHERE Nombre-Sucursal=Perryridge
SQL permite la modificacin de ciertas vistas. Por ejemplo
CREATE VIEW INFO-PRSTAMO AS
(SELECT Nombre-Sucursal, Nmero-Prstamo, Nombre-Cliente
FROM PRSTAMO)
INSERT INTO INFO-PRSTAMO VALUES (Perryridge, 3, Ruth)
es permitida y lo que hace es insertar la tupla (Perryridge, 3, Ruth, NULL) en la relacin PRSTAMO.
No se permite modificar una vista cuando la definicin de esta involucra ms de una relacin de la base de
datos.
DROP vs DELETE
Siendo R una relacin, Cul es la diferencia entre las

siguientes instrucciones?
DROP TABLE R
DELETE R
La primera elimina la relacin junto con su esquema.
La segunda elimina las tuplas pero se mantiene el esquema.
QBE
QBE (Query By Example) fue desarrollado, a principios de
los 70s en el Centro de Investigacin Thomas J. Watson de
IBM en Yorktown Heights, NY. Es el nombre tanto para el
sistema de base de datos como para el lenguaje de consulta.
Es utilizado por Access de Microsoft y por QMF (Query
Management Facility) de IBM.
Las consultas se expresan llenando tablas esqueleto o
plantillas.
Las consultas se expresan por ejemplo, es decir,
ejemplificando la consulta.
Est basado en el Clculo Relacional de Dominios.
QUEL
Quel (Query Language) fue el lenguaje de consulta de

INGRES (Interactive Graphics and Retrieval System)
desarrollado en la Universidad de California en Berkeley a
mediados de los 70s.
Est basado en el Clculo Relacional de Tuplas..

Conceptos BD

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Conceptos BD

Transféré par

Droits d'auteur :

Formats disponibles

Conceptos sobre

Base de datos: es una estructura computacional integrada y

Estructura de la base de datos

El SMBD administra la interaccin entre el

Evolucin del concepto Informacin

Dato: hechos crudos que tiene poco significado que por

Ejemplo: archivo CUSTOMER

C_ZIP AGENT A_PHONE

El especialista en DP escriba programas para, por ejemplo:

Resmenes mensuales de ventas para ver productividad.

Evolucin de los sistemas de archivos

Se crearon nuevos archivos.

Componentes de un Sistema de Archivos

Para qu estudiar los sistemas de archivos?

Entender sus limitaciones nos permite entender mejor las

Evitar cometer los mismos errores.

Desventajas de un sistema de archivos

Es complicado modificar un campo o registro o agregar otro dentro de la

Redundancia de datos: ms tiempo en la captura de datos y se requiere ms

Los sistemas de archivos no son

Es una coleccin de datos interrelacionados y almacenados en

SISTEMA MANEJADOR DE BASE DE DATOS (DBMS)

5. Control de acceso mltiple: crea las estructuras complejas que permiten a

Consecuentemente, el papel del especialista o gerente de DP cambia de poner

Principales partes que componen un

Quien es quien en un sistema de base de datos

Analistas de sistemas y programadores de aplicaciones: los

Diseo y modelado de la base de datos

El diseo de la base de datos es una de las actividades cruciales

Por qu es tan importante el diseo de la

Modelos de base de datos

Relaciones o vnculos (relationship)

Uno a muchos (1:M): cada entidad de un conjunto puede

Muchos a muchos (M:N): cada entidad de un conjunto

Modelo de Base de Datos Jerrquica.

El GUAM estaba conformado por arreglos ordenados en forma de rbol

Ventajas del Modelo Jerrquico

El Modelo Jerrquico ofrece ser muy eficiente cuando una

Desventajas del Modelo Jerrquico

Especificaciones del DBTG

Lenguajes de Administracin de Datos

Estructura bsica del Modelo de Red

Ventajas del Modelo de Red

Desventajas del Modelo de Red

Las bases de datos de red son difciles de disear y utilizar adecuadamente.

373-1616 Jurez 291

375-4009 Hidalgo 125

839-4654 Libertad 265

Ventajas del Modelo Relacional

Independencia estructural y de datos.

Desventajas del Modelo Relacional

El que el RDBMS esconda la mayor parte de la complejidad

Modelos de datos (ANSI/SPARC)

Modelos de datos ANSI/SPARC

El modelo conceptual es el ms alto nivel de abstraccin,

Ejemplo de Modelo Conceptual (ITESM)

Una vez que se ha seleccionado el DBMS especfico, el

Esquema externo del

Cupo mximo es de 35 estudiantes.

Un estudiante puede inscribirse hasta

Un profesor puede impartir un mximo

Una clase solo tiene un profesor

Un saln puede ser usado para varias