Material BA1 2011

Base de
Datos I
Escuela Tecnolgica
Superior
Universidad de Piura
Base de Datos I
Escuela Tecnolgica Superior - UDEP Pgina 2

Tabla de contenido
TEORIA GENERAL DE SISTEMAS .................................................................................................................... 4
INTRODUCCIN .............................................................................................................................................. 4
OBJETIVO DE LOS SISTEMAS DE BDD ....................................................................................................... 4
ABSTRACCIN DE DATOS ............................................................................................................................ 4
MODELO DE DATOS ....................................................................................................................................... 5
INSTANCIA Y ESQUEMAS ............................................................................................................................. 7
INDEPENDENCIA DE DATOS ........................................................................................................................ 7
LENGUAJE DE DEFINICIN DE DATOS (DDL) ........................................................................................ 7
LENGUAJE DE MANIPULACIN DE DATOS (DML) ................................................................................ 8
GESTOR DE BASE DE DATOS ....................................................................................................................... 8
ADMINISTRADOR DE BASE DE DATOS ..................................................................................................... 9
LOS USUARIOS DE LA BASE DE DATOS .................................................................................................... 9
ESTRUCTURA DEL SISTEMA GLOBAL ..................................................................................................... 10
MODELO ENTIDAD - RELACIN ................................................................................................................... 12
ENTIDADES Y CONJUNTOS DE ENTIDADES ........................................................................................... 12
RELACIONES Y CONJUNTOS DE RELACIONES ...................................................................................... 12
ATRIBUTOS .................................................................................................................................................... 12
RESTRICCIONES DE ASIGNACIN (MAPPING) ...................................................................................... 13
CLAVES ........................................................................................................................................................... 14
DIAGRAMA ENTIDAD-RELACION ............................................................................................................. 15
REDUCCION DE LOS DIAGRAMAS E-R A TABLAS ............................................................................... 16
GENERALIZACION ........................................................................................................................................ 17
AGREGACIN ................................................................................................................................................ 18
DISEO DE UN ESQUEMA DE BASE DE DATOS DE E-R ....................................................................... 19
DICCIONARIO DE DATOS ................................................................................................................................ 20
DEFINICIN .................................................................................................................................................... 20
CONVENCIONALISMOS USADOS .............................................................................................................. 20
FORMATO DE LAS DEFINICIONES DEL DICCIONARIO DE DATOS ................................................... 20
MODELO RELACIONAL ................................................................................................................................... 22
ESTRUCTURA DE LA BASE DE DATOS ................................................................................................... 22
LENGUAJES RELACIONALES COMERCIALES ........................................................................................ 23
RESTRICCIONES DE INTEGRIDAD ................................................................................................................ 35
RESTRICCIONES DE DOMINIO .................................................................................................................. 35
INTEGRIDAD REFERENCIAL ...................................................................................................................... 35
DEPENDENCIAS FUNCIONALES: ............................................................................................................... 37
CIERRE DE UN CONJUNTO DE DEPENDENCIAS FUNCIONALES ....................................................... 38
RECUBRIMIENTO CANONICO: ................................................................................................................... 39
DISEO DE BASES DE DATOS RELACIONALES ......................................................................................... 41
PELIGROS EN EL DISEO DE BDD RELACIONALES ............................................................................. 41
Base de Datos I

NORMALIZACION POR MEDIO DE DEPENDENCIAS FUNCIONALES ................................................ 42
FORMA NORMAL DE BOYCE-CODD ......................................................................................................... 44
TERCERA FORMA NORMAL ....................................................................................................................... 45
COMPARACION DE BCNF Y 3NF ................................................................................................................ 46
DEPENDENCIAS MULTIEVALUADAS ....................................................................................................... 48
NORMALIZACIN ............................................................................................................................................. 50
MOTORES DE PERSISTENCIA ......................................................................................................................... 52
MODELO ORIENTADO A OBJETOS ........................................................................................................... 52
MODELO RELACIONAL ............................................................................................................................... 53
APLICACIONES TRADICIONALES ............................................................................................................. 54
BASES DE DATOS ORIENTADAS A OBJETOS ......................................................................................... 55
MOTORES DE PERSISTENCIA ..................................................................................................................... 55
OPCIONES PARA MOTORES DE PERSISTENCIA ..................................................................................... 56

Base de Datos I

TEORIA GENERAL DE SISTEMAS

INTRODUCCIN

Un sistema de gestin de base de datos (DBMS) consiste en una coleccin de datos interrelacionados y un
conjunto de programas para acceder a esos datos. La coleccin de datos normalmente denominada BASE DE
DATOS (BDD) contiene informacin acerca de una empresa determinada. El objetivo primordial de un sistema
de gestin de base de datos es proporcionar un entorno que sea a la vez conveniente y eficiente para ser utilizado
al extraer y almacenar informacin de la BDD.

Los sistemas de BDD estn diseados para gestionar grandes bloques de informacin y mantener la seguridad de
la informacin almacenada, pese a la cada o intento de acceso no autorizados. Si los datos son compartidos por
varios usuarios, el sistema debe evitar posibles resultados anmalos.

La gestin de datos implica tanto la definicin de la estructura para el almacenamiento de la informacin como
la previsin de mecanismos para la gestin de la informacin.

OBJETIVO DE LOS SISTEMAS DE BDD

Un sistema de procesamiento de archivos est apoyado por un sistema operativo convencional.

Los registros Varios Archivos Diferente nmero de Programa
de aplicacin
Almacenamos

Estos sistemas tienen un nmero de desventajas importantes:

1. Redundancia e inconsistencia de datos.
2. Dificultad de acceso a los datos.
3. Aislamiento de los datos (datos en diferentes archivos y con diferentes formatos. Es difcil escribir
nuevos programas).
4. Anomalas de acceso concurrente.
5. Problemas de Seguridad.
6. Problemas de Integridad (Restricciones de consistencia).

ABSTRACCIN DE DATOS

Un objetivo importante de un sistema de BDD es proporcionar a los usuarios de una visin abstracta de los
datos. Existen diversos niveles de abstraccin. As:

1. NIVEL FSICO.- Es el ms bajo y describe como se almacenan los datos

2. NIVEL CONCEPTUAL.- Es el nivel intermedio y describe que datos son realmente almacenados en la
BDD y las relaciones que existen entre los datos. Aqu se describe la BDD completa en trminos de un
nmero pequeo de estructuras relativamente sencillas aunque en el mundo fsico no es as. Este nivel
es usado por el administrador de la BDD, quien decide que informacin deben guardar.

3. NIVEL DE VISIONES. Es el nivel ms alto de abstraccin y describe parte de la BDD completa.
Muchos usuarios del sistema de BDD no les interesa la totalidad de la informacin, los usuarios solo
necesitan una parte de la informacin (solo necesitan una parte de la BDD). El sistema puede
proporcionar muchas visiones para la misma BDD.

Base de Datos I

.....

REGISTROS: Cuentas (Campos: nmero y saldo)
Empleado (Campos: nombre y salario)
Clientes (Campos: nombre, calle y ciudad)

NIVEL FSICO: Un registro puede describirse como un bloque de posiciones de memoria consecutivas (por
ejemplo palabras o bits).
NIVEL CONCEPTUAL: Cada uno de los registros se describe por medio de una definicin de tipo y se define la
interrelacin entre estos tipos de registros.
NIVEL DE VISIN: Se definen varias visiones de la BDD (Los cajeros solo ven la parte de la BDD que tiene
informacin sobre las cuentas de los clientes).

MODELO DE DATOS

Para describir la estructura de una BDD es necesario definir el concepto de modelo de dato. Un MODELO DE
DATO es una coleccin de herramientas conceptuales para describir datos, relaciones entre ellos, semntica
asociada a los datos y restricciones de consistencia. Los modelos de datos se dividen e tres grupos:
Modelo Lgico Basado en Objetos.
Modelo Lgico Basado en Registros.
Modelo Fsico de Datos.

- MODELO LGICO BASADO EN OBJETOS.- Se usan para describir datos en los niveles conceptual y
de visin. Se caracterizan por el hecho de que proporcionan capacidad de estructuracin bastante flexible y
permiten especificar restricciones de datos.

Los ms extensamente conocidos son:
- Modelo Entidad Relacin
- Modelo Orientado a Objetos
- Modelo Infolgico
- Modelo Binario
- Modelo Semntico de Datos
- Modelo Funcional de Datos

MODELO ENTIDAD RELACIN.- Se basa en una percepcin de un mundo real, consiste en una
coleccin de objetos bsicos llamados entidades y relaciones entre estos objetos. Una entidad es un objeto
que se distingue de otro objeto por medio de un conjunto de atributos. Una relacin es una asociacin entre
varias entidades.
Calle

Nombre Ciudad Nmero Saldo

Cliente CtaCli Cuenta

Visin 1 Visin 2 Visin 3 Visin N
Nivel Conceptual
Nivel Fsico
Base de Datos I

MODELO ORIENTADO A OBJETOS.- Se basa en una coleccin de objetos. Un objeto contiene valores
almacenados en variables instancias dentro del objeto. Un objeto tambin contiene parte de cdigo que
opera sobre el objeto, estas partes se llaman MTODOS. Los objetos que contienen los mismos tipos de
valores y los mismos mtodos se agrupan en clase (una clase puede ser vista como una definicin de TYPE
para objeto).
La nica forma en la que un objeto puede acceder a los datos de otro objeto es invocando a los mtodos de
ese objeto, esto se llama Envo de un mensaje al objeto.
Variable Instancia = Nmero y Saldo
Mtodo = Inters de Pago
Si vara la tasa de inters -- Slo vara el mtodo.
Otras BDD tendran que cambiar varios Programas de Aplicacin.

- MODELO LGICO BASADO EN REGISTROS.- Se utilizan para describir datos en los modelos
conceptual y fsico. Se llaman as porque la BDD est estructurada en registros de formato fijo de varios
tipos. Cada tipo de registro define un nmero fijo de campos o atributos y cada campo es normalmente de
longitud fija (esto simplifica la implementacin del nivel fsico en la BDD).

Estos modelos de datos no incluyen un mecanismo para la representacin directa de cdigos en la BDD. En
cambio hay lenguajes separados que se asocian con el modelo para expresar consultas y actualizaciones de la
BDD. Los modelos de datos ms ampliamente usados son:
Modelo relacional.
Modelo de red.
Modelo jerrquico.

MODELO RELACIONAL: Representa los datos y las relaciones entre los datos mediante una coleccin de
tablas, cada una de las cuales tienen un nmero de columnas con nombre nico.
CLIENTES CUENTA
Nombre Calle Ciudad Nmero Nmero Saldo
Jos Castro Av. H 23 Talara 900 900 1,000
Luis Lpez Av. Grau 572 Piura 556 556 500
Luis Lpez Av. Grau 572 Piura 647 647 1,520
Rita Ruiz Av. Grau 572 Piura 647

MODELO DE RED: Se representa mediante una coleccin de registros y las relaciones entre los datos se
representan mediante enlaces, los cuales pueden verse como punteros. Los registros de la BDD se organizan
como una coleccin de grafos arbitrarios.

Jos Castro Av. H 23 Talara

900 1,000

Luis Lpez Av. Grau 572 Piura

556 500

Rita Ruiz Av. Grau 572 Piura

647 1,520

MODELO JERRQUICO: Es similar al modelo de red, en el sentido de que los datos y las relaciones se
representan mediante registros y enlaces respectivamente. Se diferencian en que los registros estn
organizados como una coleccin de rboles en vez de grafos arbitrarios.

Jos
Castro
Av. H
23
Talara Luis
Lpez
Av. Grau
572
Piura Rita
Ruiz
Av. Grau
572
Piura

900 1,000 556 500 647 1,520 647 1,520

Base de Datos I

DIFERENCIAS: Los modelos Relacionales se diferencian de los modelos de red y jerrquico en que no
usan punteros o enlaces.
El modelo relacional conecta registros mediante los valores que estos contienen. Se define
una base matemticamente formal.

- MODELO FSICO DE DATOS.- Se usan para describir datos en el nivel ms bajo. A diferencia de los
modelos lgicos de datos, hay muy pocos en uso. Dos de los ms ampliamente conocidos son:
- Modelo Unificado.
- Memoria de Elementos.
Los modelos fsicos de datos capturan aspectos de la implementacin de los sistemas de BDD.

INSTANCIA Y ESQUEMAS

Una BDD cambia a lo largo del tiempo segn se aada o elimina informacin.

La coleccin de informacin almacenada en la base de datos en un determinado momento en el tiempo se llama
una Instancia de la BDD.

El diseo global de la BDD se llama Esquema de la BDD. Los esquemas se cambian muy raras veces o nunca.

Los sistemas de BDD tienen varios esquemas: (en funcin de su nivel de abstraccin)
- Esquema Fsico
- Esquema Conceptual y
- Subesquemas

INDEPENDENCIA DE DATOS

Es la capacidad de modificar una definicin de un esquema en un nivel sin afectar la definicin de un esquema
en el nivel superior siguiente. Hay dos niveles:
1. Independencia Fsica de Datos.- Es la capacidad de modificar el esquema fsico sin provocar que se vuelvan
a escribir los programas de aplicacin. En algunas ocasiones son necesarias las modificaciones en el nivel
fsico para mejorar el funcionamiento del sistema.
2. Independencia Lgica de Datos.- Es la capacidad de modificar el esquema conceptual sin provocar que se
vuelvan a escribir los programas de aplicacin. Las modificaciones del nivel conceptual son necesarias
siempre que se altere la estructura lgica de la BDD.

La Independencia Lgica de Datos es ms difcil de lograr que la Independencia Fsica de Datos, ya que los
programas de aplicacin son fuertemente dependientes de la estructura lgica de los datos a los que acceden.

LENGUAJE DE DEFINICIN DE DATOS (DDL)

Un esquema de BDD se especifica por medio de un conjunto de definiciones que se expresa mediante un
lenguaje especial llamado Lenguaje de Definicin de Datos (DDL Data Definition Languaje).

El resultado de la compilacin de sentencias del DDL, es un conjunto de tablas las cuales se almacenan en un
archivo especial llamado DICCIONARIO DE DATOS (o directorio).

El diccionario de datos es un archivo que contiene METADATOS, es decir datos sobre los datos. Estos archivos
se consultan antes de leer o modificar los datos reales en el sistema de BDD.

La estructura de almacenamiento y los mtodos de acceso usados por el sistema de BDD se especifican por
medio de un conjunto de definiciones en un tipo especial de DDL llamado Lenguaje de Almacenamiento y
Definicin de Datos.

La compilacin de estas definiciones da como resultado un conjunto de instrucciones que especifican los detalles
de implementacin de los esquemas de BDD que normalmente se esconden de los usuarios.
Base de Datos I

LENGUAJE DE MANIPULACIN DE DATOS (DML)
(Data Manipulation Languaje)

Es un lenguaje que capacita a los usuarios a acceder o manipular datos segn estn organizados por el modelo de
datos adecuado. Existen dos tipos:

Procedimentales: Los DML requieren que el usuario especifique que datos necesitan y como obtenerlos.

No Procedimentales: Los DML requieren que el usuario especifique que datos se necesitan, sin especificar
cmo obtenerlos.

Los DML No Procedimentales normalmente son ms sencillos de aprender y usar que los Procedimentales. Sin
embargo, puesto que el usuario no tiene que especificar cmo conseguir los datos, estos lenguajes pueden
generar cdigos que no sean tan eficientes como el producido por los lenguajes Procedimentales.

Una consulta es una sentencia que solicita la recuperacin de informacin. El trozo de un DML que implica la
recuperacin de informacin se llama: Lenguaje de consultas.

GESTOR DE BASE DE DATOS

Un gestor de BDD es un mdulo de programa que proporciona el interfaz entre los datos de bajo nivel
almacenados en la BDD y los programas de aplicacin y de consultas hechos al sistema.

El gestor de BDD es responsable de las siguientes tareas:
- Interaccin con el gestor de archivos
- Implantacin de la integridad
- Implantacin de la seguridad
- Copia de seguridad y recuperacin
- Control de concurrencias.

INTERACCIN CON EL GESTOR DE ARCHIVOS
El gestor de BDD traduce las distintas sentencias del DML a comandos del sistema de archivos de bajo
nivel. As el gestor de BDD es responsable del verdadero almacenamiento, recuperacin y actualizacin
de los datos en la BDD.

IMPLANTACIN DE LA INTEGRIDAD
Los valores de los datos deben satisfacer ciertos tipos de restricciones de consistencia. El administrador
de BDD debe especificar explcitamente estas restricciones.
El gestor de BDD puede determinar si las actualizaciones a la BDD da como resultado la violacin de las
restricciones, si as es, se debe tomar la accin apropiada.

IMPLANTACIN DE LA SEGURIDAD
No todos los usuarios de la BDD necesitan tener acceso a todo su contenido. Es trabajo del gestor de
BDD que se cumplan con estos requisitos.

COPIA DE SEGURIDAD Y RECUPERACIN
Es responsabilidad del gestor de BDD detectar fallas y restaurar la BDD al estado que exista antes de
ocurrir el fallo. Esto se lleva a cabo normalmente a travs de la iniciacin de varios procedimientos de
copia de seguridad y recuperacin.

CONTROL DE CONCURRENCIA
Controlar la interaccin entre los usuarios concurrentes es otra responsabilidad del gestor de BDD.

Los sistemas de BDD diseados para utilizarse en computadoras personales pequeas, pueden no tener todas las
caractersticas mencionadas anteriormente.

Base de Datos I

ADMINISTRADOR DE BASE DE DATOS

Una de las razones principales para tener Sistemas de Gestin de BDD es tener control central de los datos y de
los programas que acceden a esos datos. La persona que tiene dicho control sobre el sistema se llama
administrador de BDD (Database Administrator: DBA).

Las funciones del administrador de BDD incluyen:
- Definicin de esquema.
- Definicin de la estructura de almacenamiento y del mtodo de acceso.
- Modificacin del esquema y de la organizacin fsica.
- Concesin de autorizacin para el acceso a los datos.
- Especificaciones de las restricciones de integridad.

DEFINICIN DE ESQUEMAS
El esquema original de la BDD se crea escribiendo un conjunto de definiciones que son traducidas por el
compilador de DDL a un conjunto de tablas que son almacenadas permanentemente en un diccionario de
datos.

DEFINICIN DE LA ESTRUCTURA DE ALMACENAMIENTO DEL MTODO DE ACCESO
Se crean escribiendo un conjunto de definicin que son traducidas por el compilador de lenguaje de
almacenamiento y definicin de datos.

MODIFICACIN DEL ESQUEMA Y DE LA ORGANIZACIN FSICA
Son relativamente poco comunes, pero se logran escribiendo un conjunto de definiciones que son usadas
por el compilador DDL o bien por el compilador del lenguaje de almacenamiento y definicin de datos
para generar modificaciones a las tablas internas apropiadas.

CONCESIN DE AUTORIZACIN PARA EL ACCESO A LOS DATOS
La concesin de diferentes tipos de autorizacin permite al administrador de la BDD regular que parte de
la BDD van a poder ser accedidas por varios usuarios.

ESPECIFICACIN DE LAS RESTRICCIONES DE INTEGRIDAD
Las restricciones de integridad se mantienen en una estructura especial del sistema que consulta el gestor
de BDD cada vez que tiene lugar una actualizacin en el sistema.

LOS USUARIOS DE LA BASE DE DATOS

El objetivo primordial de un sistema de BDD es proporcionar un entorno para recuperar informacin de una
BDD y almacenar la informacin en la BDD. Hay cuatro tipos distintos de usuario de un sistema de BDD,
diferenciados por la forma en que interactan con el sistema:
- Programadores de aplicacin
- Usuarios sofisticados
- Usuarios especializados
- Usuarios ingenuos

PROGRAMADORES DE APLICACIONES
Los profesionales de computacin que interaccionan con el sistema por medio de llamadas en DML, las
cuales estn escritas en un lenguaje principal (Cobol, Pascal, C, etc.). Estos programas se denominan
programas de aplicacin.
Los lenguajes de 4ta generacin a menudo incluyen caractersticas especiales para facilitar la generacin
de formas y la presentacin de datos en las pantallas. La mayora de sistemas de BDD comerciales
incluyen un lenguaje de 4ta generacin.

USUARIOS SOFISTICADOS
Interaccionan con el sistema sin escribir programas. Escriben sus preguntas en un lenguaje de consultas
de BDD.
Base de Datos I

USUARIO ESPECIALIZADOS
Algunos usuarios sofisticados escriben aplicaciones de BDD especializadas que no encajan con el marco
tradicional de procesamiento de datos. Ejemplo: Diseo asistido por computadora. Sistemas expertos, etc.

USUARIOS INGENUOS
Interactan con el sistema, invocando a unos de los programas de aplicacin permanentes que se han
escrito anteriormente.

ESTRUCTURA DEL SISTEMA GLOBAL

Un sistema de BDD se divide en mdulos que tratan cada una de las responsabilidades del sistema general. El
sistema operativo (SO) proporciona nicamente los servicios ms bsicos por lo que el diseo de un sistema de
BDD debe incluir la interfaz entre el SO y Sistema de BDD.

Los componentes funcionales son:
1. Gestor de archivos
2. Gestor de base de datos
3. Procesador de consultas
4. Precompilador de DML
5. Compilador de DDL

1. Gestor de Archivos.- Gestiona la asignacin de espacio en la memoria del disco y de la estructura de
datos usada para representar la informacin almacenada en el disco.
2. Gestor de Base de datos.- Proporciona el interfaz entre los datos (bajo nivel) de la BDD y los
programas de aplicacin y las consultas que se hacen al sistema.
3. Procesador de Consultas.- Traduce sentencias en un lenguaje de consultas a instrucciones de bajo
nivel que tiene el gestor de base de datos.
4. Precompilador de DML.- Convierte las sentencias en DML incorporadas en un programa de
aplicacin a llamadas normales a procedimientos en el lenguaje principal.
5. Compilador de DDL.- Convierte sentencias en DML en un conjunto de tablas que contienen
metadatos.

Adems se requieren varias estructuras de datos como parte de la implementacin del sistema fsico,
incluyendo:
Archivos de datos: que almacena la BDD.
Diccionario de datos: que almacena Metadatos sobre la estructura de la BDD.
ndices: Que proporciona acceso rpido a los elementos de datos que contienen valores determinados.
Base de Datos I

ESTRUCTURA DE SISTEMA GLOBAL

USUARIOS

Usuario Ingenuo Programador de Usuarios Administrador de
Aplicacin Sofisticados Base de datos

Interface de Programas Consultas Planificacin de
Aplicacin Base de Datos

Precompilador
de DML Procesador de
consultas
Compilador de
DDL

Cdigo Objeto Gestor de
de Programas de BDD
aplicacin SISTEMA DE
GESTIN DE
BDD

Gestor
de Archivos

Archivos
de datos

Diccionario de
Datos

Almacenamiento en disco

Base de Datos I

MODELO ENTIDAD - RELACIN

El modelo de datos entidad relacin (E-R) se basa en la percepcin de un mundo real que consiste en un
conjunto de objetos bsicos llamados entidades y relaciones entre estos objetos. Se desarroll para facilitar el
diseo de BDD permitiendo la especificacin de un esquema empresarial. Este esquema representa la estructura
lgica global de la BDD.

ENTIDADES Y CONJUNTOS DE ENTIDADES

Una entidad es un objeto que existe y es distinguible de otros objetos. Una entidad puede ser concreta tal como
una persona o un libro, o puede ser abstracta como un da festivo o un concepto.

Un conjunto de entidades es un conjunto de entidades del mismo tipo Ejemplo: Clientes, Empleados, Cuentas.
Los conjuntos de entidades no necesitan ser disjuntos (Clientes, Empleados).

Una entidad est representada por un conjunto de ATRIBUTOS (Cuenta: #cuenta, saldo) (Cliente: Nombre,
Seguro social, Ciudad). Para cada atributo hay un conjunto de valores permitidos, llamados DOMINIO de ese
atributo.

Nombre = Conjunto de todas las cadenas de texto de una determinada longitud.
Num-cuenta = Conjunto de todos los enteros positivos.

El concepto de Conjunto de Entidades corresponde a la nocin de TIPO en un lenguaje de programacin.
As una variable corresponde al concepto de una Entidad en el modelo E-R.
Ejemplo:
Sucursal = { Nombre-Sucursal , Ciudad-Sucursal , Activo}
Cliente = { Nombre-Cliente , Seguro Social ,Calle ,Ciudad-Cliente}
Empleado = { Nombre-Empleado , Nmero telefnico}
Cuenta = { Nmero-Cuenta , Saldo}
Transaccin = { Nmero-Transaccin , Fecha , Cantidad}

RELACIONES Y CONJUNTOS DE RELACIONES

Una relacin es una asociacin entre varias entidades.

Cliente = Harris Cuenta = #401

Un conjunto de relaciones es un conjunto de relaciones del mismo tipo. Ejemplo : Cuenta - Cliente.
La mayora de los conjuntos de relaciones en un sistema de BDD son binarios. Ocasionalmente, sin embargo hay
conjuntos de relaciones que implican ms de dos conjuntos de entidades.(Relacin ternaria: Cliente- Cuenta-
Sucursal).

Siempre es posible sustituir un conjunto de relaciones no binarias por varios conjuntos de relaciones binarios
distintos. La funcin que juega una entidad se llama PAPEL Los papeles normalmente son implcitos y no se
suelen especificar, sin embargo son tiles cuando el significado de una relacin necesita ser clasificado. Una
relacin puede tener atributos descriptivos (Fecha Cta.CLi).

ATRIBUTOS

Es posible definir un conjunto de entidades y sus relaciones de varias formas diferentes. La diferencia est en la
forma en que tratamos los diversos atributos.
Ejemplo:
E Empleado = {Nombre-Empleado, Nmero-telefnico}
Si consideramos un telfono como una entidad en si mismo.
Cada empleado tiene un telfono.
Base de Datos I

E Empleado = {Nombre-Empleado }
E Telfono = { Nmero.telefnico, Situacin}
R Empl-Tel = { Nombre-Empleado, Nmero.telefnico}
Un empleado puede tener 0 o varios telfonos y un telfono puede ser asignado a varios empleados.

La distincin entre que constituye un atributo y que constituye un conjunto de entidades depende principalmente
de la estructura de la empresa que se est modelando y de la semntica asociada con el atributo en cuestin.

RESTRICCIONES DE ASIGNACIN (MAPPING)

Una planificacin E-R de una empresa puede definir ciertas restricciones a las cuales deben ajustarse los
contenidos de una BDD. Una restriccin importante es la de cardinalidades de asignacin que expresan el
nmero de entidades con las que se puede asociar otra entidad mediante un conjunto de relaciones. Las
cardinalidades de asignacin pueden ser una de las siguientes:

UNA A UNA
Una entidad en A est asociada a lo sumo con una entidad en B.
Una entidad en B est asociada a lo sumo con una entidad en A.

UNA A MUCHAS
Una entidad en A est asociada a muchas entidades en B.
Una entidad en B est asociada a lo sumo con una entidad en A.

MUCHAS A UNA
Una entidad en A est asociada a lo sumo con una entidad en B.
Una entidad en B est asociada a muchas entidades en A.

MUCHAS A MUCHAS
Una entidad en A est asociada a muchas entidades en B.
Una entidad en B est asociada a muchas entidades en A.

b1
b2
b3
a1
a2
a3
1 1 1 1
a1
a2
a3
b1
b2
b3
b4
b5
1
M
1
M
b1
b2
b3

1
M
a1
a2
a3
a4
a5
1
M
M M
M M
a1
a2
a3
a4

b1
b2
b3
b4

Base de Datos I

La cardinalidad de asignacin adecuada para un conjunto de relaciones determinado obviamente es dependiente
del mundo real que el conjunto de relaciones est modelando.

La dependencia de existencia constituye otra clase de restricciones. Si la existencia de la entidad X depende de la
existencia de la entidad Y se dice que Y es una entidad DOMINANTE y X es una entidad SUBORDINADA.

CLAVES

Conceptualmente las entidades y las relaciones son distintas pero desde la perspectiva de una BDD la diferencia
entre ellas debe expresarse en trminos de sus atributos. El concepto de superclave nos permite hacer tales
distinciones.

Una superclave es un conjunto de uno o ms atributos que considerados conjuntamente nos permiten identificar
de forma nica a una entidad y a un conjunto de entidades

Entidad Cliente = {nombre-cliente, seguro-social, calle, ciudad}
Superclaves: { seguro-social }
{ nombre-cliente, calle }
{ nombre-cliente, seguro-social }

Una clave candidata es un conjunto de superclaves mnimas.

Claves Candidatas: { seguro-social }
{ nombre-cliente, calle }

Una clave primaria es una clave candidata que elige el diseador de la BDD como el medio principal de
identificar entidades dentro de un conjunto de entidades.

Clave Principal: { seguro-social }

Es posible que un conjunto de entidades no tenga atributos suficientes para formar una clave primaria. Al
conjunto de entidades de este tipo se denomina CONJUNTO DE ENTIDADES DEBILES. Al conjunto de
entidades que si tienen una clave primaria se denominan CONJUNTO DE ENTIDADES FUERTES.

Las entidades dbiles y fuertes estn relacionadas con las dependencias de existencia.

Entidad Fuerte Entidad Dominante
Entidad Dbil Entidad Subordinada

Una clave primaria de un conjunto de entidades dbiles est formada por la clave primaria del conjunto de
entidades fuertes de la que depende su existencia y su discriminador.

El discriminador es un conjunto de atributos que permite que se haga distincin entre las entidades dbiles.

Ej. : E (Transaccin) = {Num-trans, fecha , saldo}

CP = Num-cuenta CP = Num-cuenta, Num-trans.

La composicin de la clave primaria depende de la cardinalidad de asignacin y de la estructura de los atributos
asociados con el conjunto de relaciones:

Si el conjunto de relaciones no tiene atributo asociados, entonces el conjunto de atributos forma una superclave.
Esta superclave es una clave principal si la cardinalidad de asignacin es muchas a muchas.

Cuenta Transaccin
Base de Datos I

Empleado
Si el conjunto de relaciones tiene varios atributos asociados, entonces una superclave est formada por los
atributos anteriormente descritos con la finalidad de agregar uno o ms atributos asociados.

DIAGRAMA ENTIDAD-RELACION

Una base de datos puede representarse grficamente por medio de un diagrama E-R. Consta de los siguientes
componentes.

Rectngulos Representan conjuntos de entidades

Elipse Representan atributos

Rombos Representan conjunto de relaciones

Lneas Enlazan atributos a conjuntos de entidades y estos a
conjuntos de relaciones.

Cardinalidad uno

Cardinalidad muchos

Los papeles que juegan las entidades indican en los DER etiquetando las lneas que conectan los rombos a los
rectngulos.

direc fecha saldo
nomcli ciudad #cta.

c/c

Nombre Telef

Director Trabaja
para
Trabajador

A B
A
B
A B
A B
A B
A B
Cliente Cuenta
Base de Datos I

Cuenta
Transaccin
Cliente Cuenta Transaccin

Fecha Cantidad
#cta. Saldo #trans

1 M
Entidad Fuerte BITCORA Entidad Dbil

Nomsuc Ciudad Activo

Conjunto de Relaciones
No Binarias

S.S
Direc #cta.
Nomcli Ciudad Saldo

CAB

M M

REDUCCION DE LOS DIAGRAMAS E-R A TABLAS

Una BDD que se ajusta a un diagrama E-R puede representarse por medio de una coleccin de tablas. Para cada
conjunto de entidades y para cada conjunto de relaciones en la BDD, existe un tabla nica a la que se le asigna el
nombre del conjunto de entidades o del conjunto de relaciones correspondiente. Cada tabla tiene un nmero de
columnas que, a su vez, tiene nombres nicos.

Ciudad
S.S Saldo Fecha
Nomcli Calle #cta. #trans

Cta Bita-
cli cora

- REPRESENTACIN DE CONJUNTO DE ENTIDADES FUERTES

CUENTA CLIENTE
Numcta. Saldo Nomcli Seg.Soc Calle Ciudad
259 1000 Ruiz 32-5151 Lima Piura
630 2000 Zapata 35-9384 Callao Sullana
400 500 Otolla 32-5847 Cusco Talara
701 400 Allain 32-8425 Tacna Castilla
189 1500 Alama 33-1288 Piura Tumbes

- REPRESENTACIN DE CONJUNTO DE ENTIDADES DBILES
Se representan mediante la unin de la clave primaria de la entidad fuerte del que depende con los atributos
del conjunto de entidades dbiles.

Ejemplo: Transaccin

Cliente
Cuenta
Sucursal
Base de Datos I

TRANSACCIN
Numcta Numtrans Fecha Cantidad
259 5 11 mayo 1990 +50
630 10 17 mayo 1990 +70
400 103 23 mayo 1990 -300
259 6 07 junio 1990 -44
801 58 15 junio 1990 +900
259 7 17 junio 1990 -80

- REPRESENTACIN DE CONJUNTOS DE RELACIN
Mediante una tabla que contenga n columnas distintas con los atributos del conjunto de relaciones y las
claves primarias del conjunto de entidades que relacionan.

Relacin Cuenta-Cliente ---> Atributo {fecha}
Entidad Cliente -------------> CP {SS}
Entidad Cuenta --------------> CP {Numcta}

Seguro Social NumCta Fecha
32-5171 259 17 junio 1990
32-9381 630 17 mayo 1990
27-8123 400 23 mayo 1990
12-1133 701 15 junio 1990

El caso de conjunto de relaciones que conectan un conjunto de entidades dbiles con su correspondiente
conjunto de entidades fuertes es especial. Estas relaciones son muchos a una y no tienen atributos
descriptivos. Adems, la clave primaria de un conjunto de entidades dbiles, incluye la clave primaria de
conjunto de entidades fuertes.

Entidad: Cuenta = { Numcta } CP
Transaccin = { Numcta, Numtrans } CP
Relacin Bitcora = { Numcta, Numtrans } Tabla
Entidad Transaccin = { Numcta, Numtrans , fecha , cantidad } Tabla

La tabla bitcora es redundante y no necesita presentarse en una representacin tabular en un diagrama E-R.

GENERALIZACION

En una relacin de inclusin que existe entre un conjunto de entidades del nivel ms alto y uno o ms conjuntos
de nivel ms bajo.

Numcta Saldo
Entidades del Nivel ms Alto

ISA

Entidades del Nivel ms Bajo

Saldo deudor tasainters

Cuenta
CtaAhorros CtaCorriente
Base de Datos I

Empleado
Maquinaria
Proyecto
La generalizacin se representa por medio de un componente triangular etiquetado ISA (significa es un o es
una).

Ejemplo: Una cuenta de ahorros es una cuenta. La generalizacin se usa para hacer resaltar los parecidos entre
tipos de entidades de nivel ms bajo y ocultar sus diferencias. Los atributos de los conjuntos de entidades de
nivel ms alto se dice que son heredados por los conjuntos de entidades de nivel ms bajo. Existen dos mtodos
para transformar un DER que incluyan generalizacin en forma tabular.

1.- Crear una tabla para el conjunto de entidades del nivel ms alto. Para cada conjunto de entidades de nivel ms
bajo crear una tabla que incluye una columna para cada uno de los atributos de ese conjunto de entidades ms
una columna para cada atributo de la clave primaria del conjunto de entidades del nivel mas alto.

Cuenta = { Numcta, saldo }
CuentaCorriente = { Numcta, saldodeudor }
Cuenta de Ahorros = { Numcta, tasainteres }

TABLA 1

CUENTA CTA AHORROS CTA CORRIENTE
Numcta Saldo Numcta TasaInteres Numcta SaldoDeudor

2.- Crear una tabla que incluya una columna para cada uno de los atributos de ese conjunto de entidades ms una
columna para cada atributo del conjunto de entidades del nivel ms alto.

CuentaCorriente = { Numcta, saldo, saldodeudor }
CuentaAhorros = { Numcta, saldo, tasainteres }

TABLA 2

CTAAHORROS CTACORRIENTE
Numcta Saldo TasaInteres Numcta Saldo SaldoDeudor

AGREGACIN

Una limitacin del modelo E-R es que no se puede expresar relaciones entre relaciones. La relacin es una
abstraccin en la cual las relaciones se tratan como entidades de nivel ms alto. Un conjunto de entidades de este
tipo se trata de la misma forma que cualquier otro conjunto de entidades.

Codemp Nomemp Codproy Nomproy

Trabajo

ISA

CodMaq NomMaq

Base de Datos I

Codemp Nomemp Codproy Nomproy

Nivel ms alto
Trabajo

ISA

Nivel ms bajo

CodMaq NomMaq

La transformacin de un diagrama E-R que incluyen agregacin a una forma tabular es directa.

Entidades:

EMPLEADO PROYECTO MAQUINARIA
CodEmp NomEmp CodProy NomProy CodMaq NomMaq

Relaciones:

TRABAJO ISA
CodEmp CodProy CodEmp CodProy CodMaq

DISEO DE UN ESQUEMA DE BASE DE DATOS DE E-R

El modelo E-R proporciona un alto grado de flexibilidad en el diseo de un esquema de BDD para modelar una
empresa dada.

Entre las decisiones a tomar se encuentran:
- El uso de una relacin ternaria o de un par de relaciones binarias.
- Si un concepto de un mundo real se expresa mejor mediante un conjunto de entidades o por un
conjunto de relaciones.
- El uso de un atributo de un conjunto de entidades.
- El uso de un conjunto de entidades fuertes o dbiles.
- La oportunidad de usar agregacin.
- La oportunidad de usar generalizacin.

El diseador de BDD necesita una buena comprensin de la empresa que se va a modelar para tomar esas
decisiones.

Proyecto Empleado
Maquinaria
Base de Datos I

DICCIONARIO DE DATOS

DEFINICIN

Es una herramienta que complementa a los Diagramas de Flujo de Datos para la especificacin tcnica de los
datos. Es un conjunto ordenado de definiciones de todos y cada uno de los elementos del DFD.

CONVENCIONALISMOS USADOS

Los operadores que se utilizan en las definiciones son:
Secuencia: [+] Concatenacin de dos o ms componentes.
Seleccin: [ / ] Seleccin de un componente, de dos o ms.
Repeticin: { } Repeticin de uno o varios componentes.
Agrupacin: ( ) Agrupacin de un conjunto de datos.

FORMATO DE LAS DEFINICIONES DEL DICCIONARIO DE DATOS

Ficheros

Nombre del Fichero:
Composicin: {Datos continuos / Definidos en s mismo / Discretos}
Organizacin: Secuencial / Indexado / Directo.
Ubicacin:
Nota :

Datos Continuos

Mnemnico :
Descripcin :
Tipo : (Carcter / Numrico / Fecha / Memo)
Longitud :
Unidad : (Entero / Moneda)
Rango :

Datos Definidos en s mismo

Mnemnico :
Descripcin :
Tipo :
Longitud :
Nota :

Datos Discretos

Mnemnico : Tipo:
Descripcin : Longitud:
Valores : Significado:
. .
. .
Nota:

Base de Datos I

Ejemplo de Fichero:

Nombre del fichero: Materiales

Composicin : ( Codmat + Descripmat + Stock + StockMin + Stockmax + Unidad)

Datos definidos en s mismo

1) Nombre : Codmat
Descripcin : Cdigo que identifica a un material
Tipo : carcter
Longitud : 10

2) Nombre : Descripmat
Descripcin : Detalla las caractersticas propias de un material.
Tipo : carcter
Longitud : 40

3) Nombre : Stock
Descripcin : Especifica la cantidad de materiales que hay en el almacn.
Tipo : Numrico.
Longitud : 8

4) Nombre : Stockmin
Descripcin : Es la cantidad mnima de materiales que debe haber en el almacn.
Tipo : Numrico.
Longitud : 8

5) Nombre : Stockmax
Descripcin : Es la cantidad mxima de materiales que debe haber en el almacn.
Tipo : Numrico.
Longitud : 8

6) Nombre : Unidad.
Descripcin : Es la unidad de medida en la que se expresan los diferentes materiales.
Tipo : Carcter.
Longitud : 10

Organizacin: Indexado.

Nota: Archivo que contiene la nica informacin sobre los materiales de se tienen en la empresa.

Base de Datos I

MODELO RELACIONAL

El modelo relacional se ha establecido como principal modelo de datos para aplicaciones comerciales de
procesamiento de datos.

ESTRUCTURA DE LA BASE DE DATOS

Una BDD relacional consiste en una coleccin de tablas, cada una de las cuales se le asigna un nombre nico.
Una fila de una tabla representa una relacin entre un conjunto de valores.

ESTRUCTURA BSICA

- Una tabla es una relacin.
- Una fila es una tupla.
- Una tupla tiene atributos
- Un atributo tiene un conjunto de valores llamado dominio.

Relacin Depsitos: 5 tuplas , 4 atributos

NomSuc NumCta NomCli Saldo
Piura 101 Lpez 800
Sullana 215 Benites 700
Paita 102 Sosa 400
Talara 305 Silup 350
El alto 208 Martnez 900

Sea la variable tupla t, la primera tupla de la relacin. Usaremos la notacin t [ NomSuc] para indicar el valor de
t en el atributo nombre-sucursal, as : t[NomSuc] = Piura
t[NumCta] = 101

ESQUEMA DE LA BASE DE DATOS

En una BDD debemos diferenciar entre el esquema de la BDD o el diseo lgico y una instancia de la BDD. Es
convenientemente dar nombres al esquema de una relacin. Adoptamos el convenio de usar nombres en
minsculas para las relaciones y nombres, empezando con una letra mayscula, para los esquemas de relaciones.

Esquema_depsito = (nomsuc, numcta, nomcli, saldo)

Esquema de Relacin

Si depsito es una relacin sobre el Equema_depsito por: deposito (Esquema_depsito)

El esquema de una relacin es una lista de atributos y sus correspondientes dominios, cuando queremos definir
los dominios usaremos la notacin:

(nombre_sucursal: cadena, numcta: entero, nomcli: cadena, saldo: entero)

Ejemplo: Relacin Clientes

Nomcli Calle Ciudad
Reyes Grau Piura
Sulln Arequipa Sullana
Chvez Brasil Talara
Zapata Tacna Lima
Benites Maran Lima

Esquema_Cliente = [nomcli, calle, ciudad]
Base de Datos I

El uso de atributos comunes en esquemas de relaciones es una forma de relacionar tuplas de distintas relaciones.

Ejemplo: Esquema_sucursal = (nomsuc, activo, ciudad)
Esquema_cliente = (nomcli, calle, ciudad)
Esquema_deposito = (nomsuc, numcta, nomcli, saldo)
Esquema_prestamo = (nomsuc , numpres, nomcli, cantidad)

CLAVES

Las nociones de superclave, clave candidata y clave primaria son iguales a las del modelo E-R.

LENGUAJES DE CONSULTAS

Un lenguaje de consultas es un lenguaje en el que un usuario solicita informacin de la BDD. Estos lenguajes
son de ms alto nivel que los lenguajes estndar de programacin. Se clasifican en lenguajes procedimentales y
lenguajes no procedimentales.

Lenguaje de Consulta Procedimental .- El usuario proporciona al sistema para que realice una secuencia de
operaciones de la BDD y poder calcular el resultado deseado.

Lenguaje de Consulta No Procedimental.- El usuario describe la informacin deseada sin dar un procedimiento
especfico para obtener esa informacin.

Estudiaremos dos lenguajes puros que son lgebra relacional y clculo relacional de tuplas

LENGUAJES RELACIONALES COMERCIALES

SQL (STRUCTURED QUERY LANGUAGE)
LENGUAJE DE CONSULTA ESTRUCTUIRADO

Es el lenguaje de BDD relacional estndar. El lenguaje SQL tiene varias partes:
- Lenguaje de Definicin de Datos (DDL).- El SQL DDL proporciona rdenes para definir esquemas de
relacin, eliminar relaciones, crear ndices y modificar esquemas de relaciones.
- Lenguaje de Manipulacin de Datos Interactivo (DML).- Incluye un lenguaje de consultas basado en el
lgebra relacional y el clculo relacional de tuplas. Tambin incluye rdenes para insertar, suprimir y
modificar tuplas en la base de datos.
- Lenguaje de Manipulacin de Datos Inmerso (DML).- La forma inmersa de SQL est diseada para usar
dentro del los lenguajes de programacin de propsito general. Tales como el PL/1, Cobol, Coreal, Fortran,
C, FoxPro, Visual Basic, etc.
- Definicin de Vistas.- El SQL DDL incluye rdenes para definir vistas.
- Actualizacin.- El SQL DDL incluye rdenes para especificar derechos de acceso a relaciones y vistas.
- Integridad.- Las versiones recientes de SQL incluyendo el ANSI estndar proporciona nicamente una
forma limitada de comprobacin de la integridad.
- Control de Transacciones.- SQL incluye rdenes para especificar el comienzo y final de las transacciones.

ESTRUCTURA BASICA

Consta de tres clusulas SELECT, FROM, WHERE

SELECT: Corresponde a la operacin de proyeccin del lgebra relacional. Se usa para listar los atributos
que se desean en el resultado de una consulta.
FROM: Corresponde a la operacin de producto cartesiano del lgebra relacional. Lista las relaciones que
se van a utilizar.
WHERE: Corresponde al predicado de seleccin del lgebra relacional. Consta de un predicado que
implica atributos de las relaciones que aparecen en la clusula FROM.
Base de Datos I

SELECT A1 , A2,....,An
FROM R1,R2,......,Rn
WHERE p

SELECT * : selecciona todos los atributos de todas las relaciones que aparecen en la clusula FROM.

Si se omite la clusula WHERE, el predicado p = verdadero.

El resultado de una consulta en SQL es por supuesto una relacin.

Ejemplo: Encontrar los nombres de todas las sucursales en la relacin depsito.
SELECT nomsuc
FROM deposito

OPERACIONES DE CONJUNTOS Y TUPLAS DUPLICADAS

En los casos que queremos forzar la eliminacin de duplicados, insertamos la palabra DISTINCT despus de
SELECT.

SELECT DISTINCT nomsuc Si queremos quitar duplicados
FROM deposito

SELECT ALL nomsuc Se especifica explcitamente que no se
FROM deposito eliminan los duplicados. Normalmente
no se utiliza ALL pues ya est implcita.

OPERACIONES DE CONJUNTOS:

SQL incluye operaciones de: Unin ( ), Intersect ( ), Minus ( ).

Ejemplo: Encontrar a todos los clientes que tienen una cuenta en la sucursal de Paita.
SELECT DISTINCT nomcli
FROM depsito
WHERE nomsuc = Paita

Ejemplo: Cliente que tenga un prstamo en la sucursal de Paita.
FROM prstamo

Ejemplo: Encontrar a todos los clientes que tiene una cuenta, un prstamo en la sucursal de Paita.
(SELECT DISTINCT nomcli
FROM depsito
WHERE nomsuc = Paita)
UNION
FROM prstamo

Ejemplo: Cliente que tiene una cuenta y un prstamo.
FROM depsito
INTERSECT
FROM prstamo
Base de Datos I


Ejemplo: Cliente de la sucursal de Paita que tienen una cuenta ,pero no un prstamo.
FROM depsito
MINUS
FROM prstamo

PREDICADOS Y CONECTORES

Ejemplo: Encontrar el nombre y la ciudad de todos los clientes que tienen un prstamo en alguna sucursal.

SELECT DISTINCT cliente. nomcli , ciudad
FROM prstamo, cliente
WHERE prstamo. nomcli = cliente. Nomcli

- SQL usa los conectores lgicos AND ( . ) , OR ( v ) , NOT ( )
- Las expresiones aritmticas tienen los operadores + , - , * y / operando sobre constantes o valores de
tuplas.

- BETWEEN: Operador de comparacin.

Ejemplo: Encontrar el nombre y la ciudad de todos los clientes de que tienen un prstamo en la sucursal de Piura.
SELECT DISTINCT cliente. nomcli , ciucli
FROM prstamo, cliente
WHERE prstamo. nomcli = cliente. Nomcli
AND nomsuc = Piura

Ejemplo: Encontrar aquellas cuentas cuyo saldo sea mayor igual que 90 000 y menor igual que 100 000.
SELECT numcta
FROM depsito
WHERE saldo s 100 000 AND saldo > 90 000

Tambin: WHERE saldo BETWEEN 90 000 AND 100 000

Ejemplo: Encontrar aquellas cuentas cuyo saldo sea diferente al rango de 90 000 y 100 000.
SELECT numcta
FROM depsito
WHERE saldo NOT BETWEEN 90 000 AND 100 000

LIKE: es un operador de comparacin de cadenas de caracteres.
%: El carcter % es igual a cualquier subcadena.
_: El carcter _ es igual a cualquier carcter.

ESCAPE ( \ ): se une antes de % o - cuando estos son un carcter normal.
Pedro % es igual a cualquier cadena que empiece por Pedro.
% 19 % es igual a cualquier cadena que contenga la subcadena 19.
_ _ _ es igual a cualquier cadena menor o igual a 3 caracteres.

SELECT nomcli
FROM Cliente
WHERE Calle LIKE % Jr. %
Base de Datos I

calle LIKE ab \ % cd % escape \ Resultado: ab %cd _______
calle LIKE ab \\ cd % escape \ Resultado: ab \ cd _______

PERTENENCIA A UN CONJUNTO

IN : Conector In Prueba si un conjunto pertenece si se es miembro de un conjunto, donde el conjunto es una
coleccin de valores producidos por la clusula SELECT.
NOT IN : Prueba la de No Pertenecer al conjunto

Ejemplo:

Encontrar a todos los clientes que tienen un prstamo y una cuenta en la sucursal de Piura.

(SELECT nnombre_cliente
FROM deposito
WHERE nombre_sucursal=Piura)

SELECT DISTINCT nombre_cliente
FROM prestamo
WHERE nombre_sucursal = Piura and
nombre_cliente IN ( SELECT nombre_cliente
FROM deposito
WHERE nombre_sucursal=Piura)

SELECT DISTINCT nombre_cliente
FROM prestamo
WHERE nombre_sucursal = Piura and
<nombre_sucursal,nombre_cliente > IN
SELECT nombre_sucursal,nombre_cliente
FROM deposito)

Ejemplo: Tiene una cuenta pero no un prstamo.

SELECT DISTINC nomcli
FROM deposito
WHERE nomsuc = Piura AND
nomcli NOT IN (SELECT DISTINC nomcli
FROM prstamo.
WHERE nomsuc = Piura)

VARIABLE DE TUPLA

Una variable de tupla en SQL debe estar asociada con una relacin determinada. Se definen en la clusula
FROM.

SELECT DISTINC T. Nomcli , ciudad
FROM prstamo S, cliente T
WHERE S. nomcli = T. Nomcli

Ejemplo: Queremos encontrar a todos los clientes que tienen una cuenta en la misma sucursal en la que Javier
tiene cuentas.

SELECT DISTINC T. Nomcli
FROM deposito S, deposito T
WHERE S. nomcli = Javier AND
S. nomsuc = T. nomsuc
Base de Datos I

Otra manera:
SELECT DISTINC Nomcli
FROM deposito
WHERE nomsuc IN
(SELECT nomsuc
FROM deposito
WHERE nomcli = Javier )

COMPARACION DE CONJUNTOS

La frase mayor que algn se representa en SQL por >SOME.
Ejemplo: Encontrar los nombres de todas las sucursales que tienen un activo mayor que alguna sucursal situada
en Sullana.

SELECT DISTINC T. nomsuc
FROM sucursal S, sucursal T
WHERE T. activo > S. activo AND
S. ciudad = Sullana

Ejemplo: Genera todos los activos de las sucursales de Sullana.

SELECT DISTINC nomsuc
FROM sucursal
WHERE activo > SOME
( SELECT activo
FROM sucursal
WHERE ciusuc = Sullana

SQL tambin permite las comparaciones < SOME , s SOME , > SOME , = SOME , = SOME.
(Any = Some)

La frase mayor que todos se representa > all.
SQL permite las comparaciones < ALL , s ALL , > ALL , = ALL , = ALL.

SELECT nomsuc
FROM sucursal
WHERE activo > ALL
(SELECT activo
FROM sucursal
WHERE ciusuc = Sullana)

Puesto que SELECT genera un conjunto de tuplas a veces queremos comparar conjuntos para determinar si un
conjunto contiene todos los miembros de algn otro conjunto. Tales comparaciones se hacen en SQL usando:

CONTAINS, NO CONTAINS

Ejemplo: Encontrar a todos los clientes que tienen una cuenta en todas las sucursales situadas en Piura.

SELECT DISTINC S. nomcli
FROM deposito S
WHERE ( SELECT T. nomsuc
FROM deposito T
WHERE S. nomcli = T. Nomcli ) Encuentra todas las sucursales en las
que el cliente tiene una cuenta.
CONTAINS

(SELECT nomsuc
FROM sucursal
Base de Datos I

WHERE ciusuc = Piura) Encuentra todas las sucursales de Piura.

El procesamiento de construccin CONTAINS por computadores es demasiado caro. Por lo que no aparece en
el ANSI estndar.

PRUEBAS PARA RELACIONES VACIAS

SQL incluye una caracterstica para probar si una subconsulta tiene alguna tupla en su resultado. La construccin
EXISTS devuelve el valor TRUE si la subconsulta del argumento no est vaca. NO EXISTS devuelve el valor
TRUE si la subconsulta del argumento est vaca.

Ejemplo: Encontrar a todos los clientes que tienen una cuenta y un prstamo en la sucursal de Paita.

SELECT nomcli
FROM cliente
WHERE EXISTS (SELECT *
FROM deposito
WHERE deposito.nomcli = cliente. nomcli
ciudad = Paita )
AND EXISTS (SELECT *
FROM prestamo
WHERE prestamo. nomcli = cliente. nomcli
ciudad = Paita )

Ejemplo: Encontrar a todos los clientes de la sucursal de Paita que tienen una cuenta all; pero no un prstamo.

SELECT nomcli
FROM cliente
WHERE EXISTS ( SELECT *
FROM deposito
WHERE deposito.nomcli = cliente. nomcli
ciudad = Paita )

AND NOT EXISTS ( SELECT *
FROM prestamo
WHERE prestamo. nomcli = cliente. nomcli
ciudad = Paita )

Ejemplo: Encontrar a todos los clientes que tienen una cuenta en todas las sucursales situadas en Sullana.

SELECT DISTINCT S. nomcli
FROM deposito S
WHERE NOT EXISTS ( ( SELECT nomsuc
FROM sucursal
WHERE ciudad = Sullana )

MINUS

( SELECT T. nomsuc
FROM depsito T
WHERE S. nomcli = T. nomcli ) )

ORDENACION DE LA PRESENTACION DE TUPLAS

La clusula ORDER BY hace que las tuplas en el resultado de una consulta en un orden determinado, por
omisin SQL lista en orden ascendente.
Encuentra todas las
sucursales de
Sullana.
Encuentra todas las
sucursales donde el
cliente S tiene una
cuenta.
Base de Datos I

Ejemplo: Para listar en orden alfabtico todos los clientes que tienen un prstamo en la sucursal de Piura.

FROM prstamo
WHERE nomsuc = Piura
ORDER BY nomcli

Ejemplo: Listar todos los datos de un prstamo ordenados desde la cantidad ms pequea y por nmero de
prstamo.

SELECT *
FROM prstamo
ORDER BY cantidad DESC,
numprest ASC

FUNCIONES DE AGREGACION

SQL ofrece la posibilidad de calcular funciones en grupos de tuplas usando la clusula GROUP BY .El atributo
o atributos dados en la clusula GROUP BY se usan para formar grupos. Las tuplas con el mismo valor se
colocan en un grupo.

Las funciones para calcular:
Promedio : AVG
Mnimo : MIN
Mximo : MAX
Total : SUM
Contar : COUNT

Ejemplo: Encontrar el saldo promedio de las cuentas de todas las sucursales.
SELECT nomsuc , AVG ( saldo)
FROM depsito
GROUP BY nomsuc

RECORDAR: SI SE QUIERE ELIMINAR DUPLICADOS USAR DISTINCT

Ejemplo: Encontrar el nmero de clientes con depsito para cada sucursal.

SELECT nomsuc , COUNT ( DISTINCT nomcli)
FROM depsito
GROUP BY nomsuc

Si se desea declarar una condicin que se aplica a los grupos ms que a las tuplas ,usaremos la clusula
HAVING de SQL.

Ejemplo: Saldo promedio de las sucursales mayor que 1 200.
SELECT nomsuc , AVG ( saldo)
FROM depsito
GROUP BY nomsuc
HAVING AVG ( saldo ) > 1 200

Las funciones de Agregacin no pueden componerse en SQL as:

MAX ( AVG (...) ) NO ESTA PERMITIDO.

Base de Datos I

Ejemplo: Encontrar aquellas sucursales con el saldo promedio mayor.
SELECT nomsuc
FROM depsito
GROUP BY nomsuc
HAVING AVG ( saldo ) > ALL (SELECT AVG ( saldo)
FROM depsito
GROUP BY nomsuc)

Cuando deseamos tratar la relacin completa como un grupo nico, no se usa la clusula GROUP BY.

Ejemplo: Encontar el saldo promedio en todas las cuentas.
SELECT AVG ( saldo)
FROM depsito

La funcin Agregacin COUNT se usa frecuentemente para contar el nmero de tuplas de una relacin.

Ejemplo: Encontar el saldo promedio de todos los clientes con depsito ,que viven en Sullana y tienen por lo
menos tres cuentas.
SELECT AVG ( saldo)
FROM depsito , cliente
WHERE depsito. nomcli = cliente. nomcli AND
ciudad = Sullana
GROUP BY depsito. nomcli
HAVING COUNT ( DISTINCT numcta ) > 3

ANSI de SQL permite utilizar COUNT como COUNT (*) o COUNT ( DISTINCT ... ). Se puede usar
DISTINCT con MAX y MIN aunque el resultado no cambia. La palabra clave ALL puede usarse en vez de
DISTINCT para especificar retencin de duplicados; pero puesto que ALL est implcito no es necesario.

MODIFICACIN DE LA BDD

ELIMINACIN.- En SQL una supresin se expresa por medio de:
DELETE r r = relacin
WHERE p p = predicado

La tupla T de r por la cual p(T) es verdadera ser eliminada de r.
DELETE opera sobre una sola relacin.

Ejemplo: Suprimir todas las tuplas de la relacin prstamo.

DELETE prstamo

Ejemplo: Suprimir todos los registros del cliente Prez.
DELETE depsito
WHERE nomcli = Prez

Ejemplo: Suprimir todos los prstamos cuyo nmero de prstamo est entre 1300 y 1500.
DELETE prstamo
WHERE numpres BETWEEN 1300 AND 1500

Ejemplo: Suprimir todas las cuentas en la sucursal de Piura.
DELETE depsito
WHERE nomsuc IN ( SELECT nomsuc
FROM sucursal
WHERE ciudad = Piura)
Base de Datos I

INSERCIN.- Los valores de atributos para tuplas insertadas deben ser miembros del dominio de los atributos,
y las tuplas insertadas deben tener el nmero correcto de atributos.

INSERT INTO depsito
VALUES ( Sullana , 9825 , Garca , 1 200)

Los atributos se especifican en orden de esquema de la relacin.

INSERT INTO depsito ( nomsuc , numcta , nomcli , saldo )
VALUES ( Sullana , 9825 , Garca , 1 200)

Ejemplo: Queremos proporcionar a todos los clientes con prstamo en la sucursal de Paita una cuenta de ahorros
con S/. 200,Y su nmero de prstamo ser igual al nmero de su cuenta de ahorros.
INSERT INTO depsito
SELECT nomsuc , numpres , nomcli , 200
FROM prstamo

ACTUALIZACIN.- Cada vez que se desee actualizar registros con datos recientes podr usarc la sentencia
UPDATE.

Ejemplo: Todos los saldos se van a incrementar en un 5 % por pago de inters.
UPDATE depsito
SET saldo = saldo * 1.05

Ejemplo: Para cuentas con saldos mayores a 10 000 incrementar e inters en 6 % y para las menores las cuentas
menores que 10 000 el inters es de 5 %.

UPDATE depsito
WHERE saldo > 10 000

UPDATE depsito
WHERE saldo s 10 000

En el caso de INSERT, DELETE, UPDATE cualquier SELECT incorporado en la clusula WHERE no debe
hacer referencia a la relacin que se est usando.

UPDATE depsito
WHERE saldo > (SELECT AVG ( saldo)
FROM depsito )

VALORES NULOS

Usaremos la sentencia NULL

INSERT INTO depsito
VALUES ( Sullana , NULL , Garca , 1 200)

Todas las comparaciones que implica NULL son falsas por definicin; sin embargo la palabra clave especial
NULL puede usarc en un predicado para probar si hay un valor nulo.

FROM depsito
WHERE cantidad IS NULL

El predicado IS NOT NULL prueba la ausencia de un valor no nulo.
No se puede, sta
solicitud es ambigua.
Base de Datos I

VISTAS

Usaremos la sentencia CREATE VIEW.

CREATE VIEW v AS <expresin de consulta>
v = nombre de la vista.
<Expresin de consulta > = cualquier expresin de consulta permitida.

Ejemplo : Queremos una vista que se llama Todos_clientes y que consta de sucursales y sus clientes.

CREATE VIEW Todos_clientes AS
( SELECT nomsuc , nomcli
FROM depsito)
UNION
( SELECT nomsuc , nomcli
FROM prstamo)

Dado que cada vista se considera como un archivo podra despus usarse:

SELECT nomcli
FROM Todos_clientes

DEFINICIN DE DATOS

Una relacin de SQL se define usando la orden:

CREATE TABLE r ( A1D1, A2D2, ... , AnDn )
r = Nombre de la relacin.
A = Nombre de un atributo del esquema de la relacin r.
D = Es el tipo de datos de los valores en el dominio del atributo A. Ejemplo CHR (30) , Integer , Real ,
NOT NULL.

La relacin recin creada est vaca. La orden INSERT puede usarc para cargar los datos.

Para eliminar una relacin de la BDD en SQL usaremos:
DROP TABLE r

Para aadir atributos en una relacin existente se usa:
ALTER TABLE r ADD A D

DELETE r Elimina todas las tuplas de r
DROP TABLE r Elimina todas las tuplas de r y tambin el esquema de r .

Ejemplo: Crear la tabla clientes

CREATE TABLE clientes
( nomcli CHR(30) NOT NULL,
ciudad CHR(30),
calle CHR(30) )

Recordar!
A : nombre del atributo.
D : tipo .
Base de Datos I

AFIRMACIONES

Una afirmacin es un predicado que se desea que siempre satisfaga la Base de Datos. Las restricciones de
dominio, las Dependencias Funcionales y las restricciones de integridad referencial son formas especiales de
afirmacin.

Sin embargo existen muchas restricciones que no pueden expresarse usando solamente estas tres formas
especiales.

Ejemplo:
La suma de todas las cantidades de prstamos para cada sucursal debe ser menos que la suma de todos los saldos
de cuenta de la sucursal.

Cuando se hace una afirmacin, el sistema prueba su validez. Si la afirmacin es vlida, entonces cualquier
modificacin en la BDD est permitida solo si no provoca que se viole la afirmacin.

La prueba puede introducir una cantidad significativa de tiempo si se han hecho afirmaciones complejas.

ASSERT < nombre_afirmacin > ON < nombre_relacin > : < predicado>

Ningn saldo negativo (Restriccin de integridad)

ASSERT lmite.saldo ON depsito : saldo >= 0
(Restriccin de dominio)

Ningn empleado del banco puede ser su propio banquero personal

ASSERT lmite_banquero ON persona :
nombre_cliente < > nombre_banquero

Las restricciones pueden restringirse para aplicarse solo a modificaciones de la BDD. En el caso que queramos
prevenir la adicin de una cuenta (depsitos) a menos que el nombre del cliente aparezca en la relacin cliente
(Restriccin de Integridad Referencial)

ASSERT lmite_direccin ON INSERTION TO depsito :
EXISTS ( SELECT *
FROM Cliente
WHERE Cliente. nomcli = Depsito.nomcli)

La forma ms general de afirmacin es:

ASSERT <nombre_afirmacin > : <predicado>

Es cualquier clausula en SQL.

DISPARADORES (TRIGGER)

El disparador es una sentencia que el sistema ejecuta automticamente como un efecto secundario de una
modificacin de la BDD. Para disear un mecanismo de disparador, debemos:

- Especificar las condiciones bajo las cuales se va a ejecutar el disparador.
- Especificar las acciones que se van a tomar cuando se ejecute el disparador.

Ejemplo:
En vez de permitir saldos negativos de cuentas, el banco trata los saldos deudores poniendo el saldo de cuenta en
cero y creando un prstamo en la cantidad de saldo deudor.

Base de Datos I

Insertar una nueva tupla S en la relacin prstamo con:
S[nomsuc] = T[nomsuc]
S[numprest] = T[numcta]
S[cantidad] = T[saldo]
S[nomcli] = T[nomcli]

Poner T[saldo] a cero

Los disparadores no estn incluidos en el SQL estndar

DEFINE TRIGGER saldodeudor
ON UPDATE OF deposito T
( IF NEW T.saldo < 0
THEN ( INSERT INTO prstamo VALUES
(T.Nomsuc, T.Numcta, T.nomcli , - NEW T.saldo)
UPDATE deposito S
SET S.Saldo =0
WHERE S.numcta = T.numcta ) )

Base de Datos I

RESTRICCIONES DE INTEGRIDAD

Las Restricciones de Integridad proporcionan un medio de asegurar que los cambios que se hacen en la BDD por
usuarios autorizados no resulten en una prdida de consistencia de los datos.

Las Restricciones de Integridad protegen la BDD contra daos accidentales.

Las Restricciones de Integridad para el modelo E-R estn en forma de:
- Declaracin de claves.
- Forma de una relacin (M a M, 1 a M, 1 a 1).

RESTRICCIONES DE DOMINIO

Los lmites de dominio son la forma ms elemental de restricciones de integridad.

Tipos de Dominio: Una definicin adecuada de tipos de dominio no solo nos permite probar valores insertados
en la BDD, sino que tambin nos permite probar consultas para asegurar que la comparacin que se hace tiene
sentido.
* Varios atributos pueden tener el mismo sentido.
( nombre_cliente , nombre_empleado ) = conjunto de todos los nombres de personas.

* Atributo con diferente dominio.
saldo y nombre_sucursal o nombre.cliente y nombre.sucursal.

Tipos de Dominios en SQL:
- Cadena de caracteres de longitud fija, longitud especificada por el usuario.
- Nmero en coma fija, con precisin especificada por el usuario.
- Entero (dependiente de la mquina).
- Entero pequeo (dependiente de la mquina).
- Nmero en coma flotante y en coma flotante de doble precisin, con precisin dependiente de la mquina.
- Fecha.

La transformacin de tipo de dominio se denomina Coaccin de Tipo (Convertir de entero pequeo a
entero.)
Para SQL Estndar, nombre.sucursal y nombre.cliente aunque tengan dominio de cadena de caracteres de
longitud diferente, SQL considera los dos dominios compatibles.

Valores Nulos: SQL estndar permite que la declaracin del dominio de un atributo incluya la especificacin
NOT NULL . Esto prohbe la insercin de un valor nulo para este atributo.
Cualquier modificacin en este caso genera un diagnstico de error.
Hay muchas situaciones en las que la prohibicin de valores nulos es deseable. As: Cuando el atributo es
una clave primaria de un esquema de relacin.

INTEGRIDAD REFERENCIAL

A menudo queremos asegurar que un valor que aparece en una relacin para un conjunto de atributos dados
tambin aparece para un conjunto de atributos en otra relacin.

Conceptos Bsicos: Considrese un par de relaciones r( R ) y d ( D ) y el producto natural r ||d, puede
darse el caso de que haga una tupla t en r que no se corresponda con ninguna tupla en d. Estas tuplas se llaman
Tuplas Colgadas.

Dependiendo del conjunto de entidades o del conjunto de relaciones que se est modelando, las tuplas colgadas
pueden ser aceptables o no.

Base de Datos I

Un atributo de una relacin que es una clave primaria de otra relacin se denomina Clave Exterior.
Los requerimientos de esta forma se llaman Restricciones de Integridad Referencial o Dependencia de
Subconjuntos.

Integridad Referencial en Modelo E-R: Estas restricciones se presentan frecuentemente. Si obtenemos el Esquema
de BDD Relacional construyendo tablas desde diagramas de E-R. Todas las relaciones que surgen de un
conjunto de relaciones tienen restricciones de integridad referencial.

Del esquema de relaciones, es una clave exterior que conduce a una restriccin de Integridad referencial.

Otra fuente de Integridad Referencial es el conjunto de entidades dbiles. El Esquema de Relaciones para cada
conjunto de Entidades dbiles incluye una clave exterior que conduce a una restriccin de Integridad
Referencial.

Modificacin de la BDD: La modificacin de la BDD puede causar violaciones de integridad Referencial.

( r2) _ k ( r1 )

Insertar: Si una tupla t2 se inserta en una relacin r2, el sistema debe asegurar que existe una tupla t1 en
r1 tal que: t1(k) = t2(). Es decir t2() k ( r1 )

Eliminar: Si una tupla t1 se elimina de r1, el sistema debe calcular el conjunto de tuplas en r2 que hacen
referencia a t1. = t1(k) (r2)
Si este conjunto no est vaco, o la orden de eliminar se rechaza como un error, o se debe eliminar
las tuplas que hacen referencia a t1.

Actualizar: Actualizar en la relacin que hace la referencia (r2) actualizar en la relacin referenciada (r1)

- Si se actualiza una tupla t2 en la relacin r2 y modifica valores para la clave exterior (),
entonces se hace una prueba similar a la del caso de insertar.

- Si se actualiza una tupla t1 en la relacin r1 y modifica valores para la clave primaria (k),
entonces se hace una prueba similar a la del caso de eliminar.

Integridad Referencial en SQL: Una caracterstica de Intensificacin de Integridad ha sido aprobada como un
aadido al estndar. Esta caracterstica permite la especificacin de claves primarias, candidatas y claves
exteriores como parte de al sentencia CREATE TABLE:

- La clusula "Primary Key" incluye una lista de atributos que comprenden la clave primaria.
- La clusula "Unique Key" incluye una lista de atributos que comprenden la clave candidata.
- La clusula "Foreign Key" incluye una lista de atributos que comprenden la clave exterior y el
nombre de la relacin a la que hace referencia la clave exterior ( Reference).

Cualquier atributo que sea miembro de una clave candidata debe ser declarado NOT NULL.

Ejemplo: DEFINICION DE DATOS EN SQL PARA UNA PARTE DE LA BDD (SQL DDL)

CREATE TABLE cliente
( nombre_cliente CHR( 30 ) NOT NULL,
calle CHR( 30 ),
ciudad_cliente CHR( 30 ),
PRIMARY KEY ( nombre_cliente ) )

Base de Datos I

CREATE TABLE sucursal
( nombre_sucursal CHR( 20 ) NOT NULL,
activo INTEGER ,
ciudad_sucursal CHR( 30 ) ,
PRIMARY KEY ( nombre_sucursal ) )

CREATE TABLE depsito
( nombre_sucursal CHR( 20 ) NOT NULL,
numero_cta CHR( 10 ) NOT NULL,
nombre_cliente CHR( 30 ) NOT NULL,
saldo INTEGER ,
PRIMARY KEY ( numero_cta , nombre_cliente) ,
FOREING KEY ( nombre_sucursal ) REFERENCE Sucursal ) ,
FOREING KEY ( nombre_cliente ) REFERENCE Cliente ) )

DEPENDENCIAS FUNCIONALES:

Las dependencias funcionales son una restriccin al conjunto de relaciones legales. Nos permite expresar hechos
acerca de la empresa que estamos modelando con la base de datos.

Las dependencias funcionales nos permiten expresar restricciones que no pueden expresarse por medio de
superclaves.

Usaremos las dependencias funcionales de dos formas:
1. Para especificar restricciones en el conjunto de relaciones legales. As pues nos interesaremos slo por las
relaciones que satisfagan un conjunto dado de dependencias funcionales.
Si queremos limitarnos a la relacin del esquema R que satisfacen F, decimos que F se cumple en R.

2. Para probar si una relacin es legal bajo un conjunto dado de dependencias funcionales. Si una relacin r es
legal bajo un conjunto F de dependencias funcionales, decimos que r satisface a F.

Relacin r
A B C D
a1 B1 c1 d1
a1 B2 c1 d2
a2 B2 c2 d2
a2 b3 c2 d3
a3 b3 c2 d4

A C } Dependencia Funcional
Hay dos tuplas que tienen el valor de a1 en A. Estas tuplas tienen el mismo valor en C = c1.
Dos tuplas de valor a2 en A tienen el valor en C = c2.

C A } No satisfacen las Dependencia Funcional
Porque las tres tuplas con valor C = c2 tienen diferentes valores en A = ( a1, a3La relacin r satisface muchas
otras Dependencias Funcionales, incluyendo por ejemplo la dependencia funcional.
AB D

Hay Dependencia Funcional que son "Triviales", porque se satisfacen por todas las relaciones.
Ejemplo: A A
AB A => B Es trivial si B _

RELACION CLIENTES
nomcli calle ciudad
Javier Vsquez Av. Grau 123 Piura
Jannette Luna Av. Las Palmeras 231 Talara
Katia Vsquez Jr. Gardenias 65 Piura
Base de Datos I

Calle Ciudad Puede haber el nombre de una calle en dos ciudades diferentes (no incluiremos esta
dependencia en el conjunto de Dependencias Funcionales que se cumplen en este esquema.

RELACION SUCURSAL

nomsuc activo Se exige que se cumpla en el esquema prstamo.
activo nomsuc No queremos exigir que se cumpla ya que es posible que varias
sucursales tengan el mismo valor de activos.

RELACION PRESTAMO
Nomsuc Numprest nomcli ciudad
P1 17 Javier Vsquez Piura
T1 15 Marco Valencia Sullana
S1 23 Jannette Luna Talara
P2 18 Katia Vsquez Piura

numprest catidad Queremos exigir que la relacin prstamo satisfaga esta dependencia en todo
momento. Imponemos la restriccin de que se cumpla numprest cantidad
en el esquema prstamo.

Al disear una base de datos relacional primeros listamos aquellas dependencias funcionales que se deben
cumplir siempre.

Ejemplo:
* En Esquema Sucursal
nombre_sucursal ciudad_sucursal
nombre_sucursal activo

*En Esquema Cliente
nombre_cliente ciudad_cliente
nombre_cliente calle

* En Esquema Prstamo
numprest cantidad
numprset nombre_sucursal

CIERRE DE UN CONJUNTO DE DEPENDENCIAS FUNCIONALES

No es suficiente considerar un conjunto dado de Dependencias Funcionales. Adems, necesitamos considerar
todas las Dependencias Funcionales que se cumplan.

R = ( A,B,C,G,H,I ) D.F. A B CG H B H
A C CG I

Las Dependencias Funcionales A H se implica lgicamente. Es decir podemos demostrar que se cumpla el
conjunto dado de Dependencias Funcionales, A H tambin debe cumplirse:
A B y B H A H
Nomsuc Activo ciudad
P1 1 000 000 Piura
S1 800 000 Talara
T1 500 000 Sullana
P2 300 000 Piura
Base de Datos I

Sea F un conjunto de Dependencias Funcionales. El cierre de F ( F+ ) es el conjunto de Dependencias
Funcionales que F implica lgicamente.

Existen tcnicas para deducir Dependencias Funcionales:

La primera tcnica se basa en tres axiomas o reglas de inferencia para Dependencias Funcionales. Aplicando
estas reglas repetidamente podemos encontrar F+ completo dado en F.

CONVENIOS: Letras griegas (o | ...) representan conjunto de atributos
Letras romanas en maysculas representan atributos individuales
o | = o |

Axiomas de Armstromg.-
- Reglas de Flexibilidad.- Si o es un conjunto de atributos y | _ o ,entonces se cumple o|.
- Regla de Aumento.- Si se cumple o| es un conjunto de atributos, entonces se cumple o |.
- Regla de Transitividad.- Si se cumple o | y se cumple | , entonces se cumple o .

Estas reglas son seguras porque no generan Dependencias Funcionales incorrectas.
Las reglas son completas porque para un conjunto dado de F de Dependencias Funcionales nos permiten
generar un F+ completo.

Para simplificar esta tarea, listaremos algunas reglas auxiliares.

- Regla de Unin.- Si se cumple o | y se cumple o , entonces se cumple o | .
- Regla de Descomposicin.- Si se cumple o | , entonces se cumple o | y o .
- Regla de Pseudotransitividad.- Si se cumple o | y | o , entonces se cumple o o.

A continuacin mostramos algunos miembros de F+:

A H Se cumple A B y B H Por regla de Transitividad A H

CG HI Se cumple CG H y CG I Por regla Unin CG HI

AG I Se cumple A C Por regla de Aumento AG CG.
Se cumple CG I Por regla de Transitividad AG I.

RECUBRIMIENTO CANONICO:

Para minimizar el nmero de Dependencias Funcionales que necesitan ser probadas en caso de una
actualizacin, restringimos un conjunto dado F de Dependencias Funcionales a un recubrimiento cannico Fc.

Fc debe tener las siguientes caractersticas:
a) Cada una de las Dependencias Funcionales o | en Fc no contienen atributos extraos a o. Los
atributos extraos son atributos que pueden eliminarse de o sin cambiar Fc+. As A es extrao a o si
A e o y Fc implica lgicamente a ( Fc {o |} ) {o A |}.

b) Cada una de las Dependencias Funcionales o | en Fc no contienen atributos extraos a |.
As A es extrao a | si A e | y ( Fc {o |} ) {o | A} implica lgicamente a Fc.

c) Cada lado izquierdo de una Dependencia Funcional en Fc es nico ( No existen dos dependencias
o1 |1 y o2 |2 en Fc, tales que o1 = o2 )
Base de Datos I

Para calcular un recubrimiento cannico para F, utilizo la Regla de Unin para sustituir cualquier dependencia en
F ( o1 |1 y o2 |2 o1 |1|2 )

Prubese cada dependencia funcional o | para ver si hay un atributo extrao a o o a |. Este proceso se
debe repetir hasta que no ocurran cambios.

Ejemplo:
A BC
B C
A B
AB C

Paso C
A BC A BC
A B
Paso A
A es extrao en AB C porque existe B C
Al suprimir A de AB C obtenemos B C que
ya est en el conjunto de dependencias funcionales.

El conjunto de Dependencias funcionales Fc es: A BC y B C

Base de Datos I

DISEO DE BASES DE DATOS RELACIONALES

El objetivo del diseo de una base de datos relacional es generar un conjunto de esquemas de relaciones que nos
permiten almacenar informacin sin redundancia innecesaria, pero que a la vez nos permitan recuperar
informacin fcilmente.

PELIGROS EN EL DISEO DE BDD RELACIONALES

Entre las propiedades indeseables que un mal diseo pueda tener estn:

- Repeticin de Informacin
- Incapacidad para representar cierta informacin.
- Prdida de informacin

REPRESENTACIN DE LA INFORMACIN:

Diseo Original
(1) Esquema_sucursal = ( nomsuc, activo, ciudad_suc)
Esquema_prestamo = ( nomsuc, numprest, nomcli, cantidad )

Diseo Alternativo
(2) Esquema_prestar = ( nomsuc, activo, ciudad_suc, numprest, nomcli, cantidad )

La repeticin de informacin que requiere el uso del diseo alternativo no es conveniente. La repeticin de
informacin desperdicia espacio. Adems, complica la actualizacin de la base de datos.

Ejemplo:
a) Aadir un nuevo prstamo en 1 y en 2
b) Actualizar la ciudad de una sucursal

Por qu es malo el diseo alternativo?
a) Sabemos que una sucursal bancaria est situada en una ciudad, as se cumple la Dependencias Funcionales.
nomsuc ciudad_suc

Sabemos que una sucursal pude hacer muchos prestamos. No se cumple la Dependencias Funcionales.
nomsuc numprest

El hecho de que una sucursal est situada en una ciudad y el hecho de que una ciudad realice prstamos son
procesos independientes. Estos hechos se representan mejor en relaciones separadas.

b) No podemos representar directamente la informacin referente a una sucursal (nomsuc, activo, ciudad_suc) a
menos que exista por lo menos un prstamo en la sucursal (deben tener valores de numprest, cantidad y nomcli).
Peor an tendramos que suprimir esta informacin cuando se hubieran pagado todos los prstamos.

PRDIDA DE INFORMACIN

El ejemplo anterior nos sugiere que debemos descomponer un esquema de relaciones con muchos atributos en
varios esquemas con menos atributos. Sin embargo si la descomposicin se hace sin cuidado puede llegarse a
otra forma de diseo defectuoso.

Ejemplo:
El esquema prstamo se descompone en:
Esquema_cantidad = (cantidad, nomcli)
Esquema_prestamo = (nomsuc, numprest, cantidad)

Queremos encontrar aquellas sucursales de las que Juan tiene un prstamo, ninguna de las relaciones de la Base
de Datos alternativa contiene estos datos. Podemos hacerlo escribiendo cantidad |x| prstamo.

Base de Datos I

Si sucede que varios prstamos tienen la misma cantidad, no podemos decir a qu cliente corresponde cada
prstamo. Ya no somos capaces de representar en la Base de Datos, que clientes tienen prestamos de qu
sucursal.

Debido a esta prdida de informacin, a esta descomposicin la llamaremos Descomposicin con prdida o
descomposicin de producto con prdida.

Debe estar claro, que una descomposicin de productos con prdida es un mal diseo de la Base de Datos.

Esquema_prestar Esquema_prestamo Esquema_prestamo Esquema_cantidad = {cantidad}
Esquema_cantidad inapropiado

Esquema_prestar Esquema_sucursal Esquema_sucursal Esquema_prestamo = {nomsuc}
Esquema_prestamo

Para tener una descomposicin de producto sin prdida, necesitamos imponer ciertas restricciones en el conjunto
de las relaciones posibles. Una de estas restricciones son las dependencias funcionales.

Ejemplo:
* R = Esquema_prestar r : relacin prestar
R1= Esquema_cantidad r1 : relacin cantidad r = r1 |x| r2 Hay prdida de la informacin
R2= Esquema_prestamo r2 : relacin prstamo

* Esquema_prestar = Esquema_prestamo |x| Esquema_sucursal Sin prdida debido a la dependencia
funcional nomsuc activo, ciudad_suc.

NORMALIZACION POR MEDIO DE DEPENDENCIAS FUNCIONALES

Usando Dependencias Funcionales, podemos definir varias formas normales que representen diseos buenos
de Base de Datos. Existe un gran nmero de formas normales. Las que trataremos aqu son BCNF y 3NF.

PROPIEDADES DESEABLES DE UNA DESCOMPOSICION

Esquema_prestar = ( nomsuc, activo, ciudad_suc, numprest, nomcli, cantidad)

El conjunto F de Dependencias Funcionales que es necesario que se cumpla en el esquema_prestar es :

nomsuc activo, ciudad_suc
numprest cantidad, nombre_sucursal

Descomposicin De Producto Sin Prdida

El criterio para determinar si una descomposicin sea sin prdida: Sea R un esquema de relaciones y F es un
conjunto de Dependencias Funcionales en R. R1 y R2 forman una descomposicin de R.

Esto es una descomposicin de producto sin prdida de R si por lo menos una de las dependencias funcionales
siguientes est en F+.
R1 R2 R1
R1 R2 R2

1) Ejemplo: Esquema_prestar en:
Esquema_sucursal = ( nomsuc, activo, ciudad_suc)
Esquema_prestamo = ( nomsuc, numprest, nomcli, cantidad)

Base de Datos I

Puesto que:
nomsuc activo, ciudad_suc F
(Regla de Aumento para Dependencias funcionales)
nomsuc nomsuc, activo, ciudad_suc F+

Esquema_sucursal Esquema_prestamo = {nomsuc} => Esquema_sucursal es OK

2) Ejemplo Esquema_prestamo:
Esque_Info_prestamo = ( nomsuc, numprest, cantidad)
Esque_prest_cliente = ( nomcli, numprest)

Puesto que:
numprest cantidad, nomsuc F
(Regla de Aumento para Dependencias funcionales)
numprest numprest , cantidad, nomsuc F+

Esque_Info_prestamo Esque_prest_cliente = {numprest} => Esquema_info_prestamo es OK

Conservacin de las Dependencias

Cuando se hace una actualizacin de la Base de Datos, el sistema debe poder comprobar que la actualizacin no
crear una relacin ilegal - es decir, una que no satisfaga todas las dependencias funcionales dadas.

Para comprobar las actualizaciones eficientemente es conveniente disear esquemas de Base de Datos
relacionales que permitan validar una actualizacin sin calcular los productos.

Ejemplo:
Podemos demostrar que la descomposicin del Esquema_prestar conserva las dependencias. Para ver estos,
consideramos cada uno de los miembros del conjunto F de Dependencias funcionales que necesitamos que se
cumplan en el Esquema_prestar y mostraremos que cada uno puede probarse en por lo menos una relacin de la
descomposicin.

D.F. nomsuc activo, ciudad_suc puede probarse usando el esquema sucursal.

D.F. numprest cantidad, nomsuc puede probarse usando Esquema_info_prestamo.

Repeticin De Informacin

La descomposicin de Esquema_prestar no padece del problema de la repeticin de informacin.

Ejemplo:
Esquema_Prestar repeta la ciudad y el activo de la sucursal para cada prstamo. La descomposicin repara
los datos de sucursal y de prstamo en relaciones distintas, eliminando esta redundancia.

Si se hace un solo prstamo a varios clientes, debemos repetir la cantidad del prstamo una vez por cada
cliente (as como la cantidad y el activo de la sucursal). En la descomposicin, la relacin del esquema del
Esquema_prestamo_cliente contiene la relacin numprest, nomcli, cosa que no sucede en las dems
esquemas. En el Esquema_info_prestamo, solo se necesita que aparezca una tupla por prstamo.

Claramente, la falta de redundancia que presenta la descomposicin es deseable. Las distintas formas normales
representan los grados de eliminacin de redundancia que pueden lograrse.

Base de Datos I

FORMA NORMAL DE BOYCE-CODD

Una de las formas normales ms deseables que podemos obtener es la BCNF. Un esquema de la relacin R est
en BCNF con respecto a un conjunto F de Dependencias Funcionales, si para todas las Dependencias
Funcionales en F+ de la forma o|, donde o _ R y | _ R, por lo menos se cumple una de las siguientes
condiciones :
o > | es una dependencia funcional trivial (Es decir | _ o)
o es una superclave del esquema R.

Un diseo de la Base de Datos est en BCNF si cada uno de los miembros del conjunto de los esquemas de
relaciones que comprende el diseo est en BCNF.

Ejemplo :
Esquema_sucursal = ( nomsuc, activo, ciudad_suc)
Esquema_cliente = ( nomcli, calle, ciudadcliente)
nomcli calle, ciudadcliente
Esquema_depsito = ( nomsuc, numcuenta, nomcli, saldo)
numcuenta saldo, nomsuc
Esquema_prestamo = ( nomsuc, numprest, nomcli, cantidad)
numprest cantidad , nomsuc

Esquema cliente esta en BCNF:
1. Nomcli es una clave candidata en el esquema cliente
2. La nica Dependencia funcional no trivial que se cumpla en esquema cliente tiene nomcli en el lado izquierdo
de la flecha.

Esquema sucursal est en BCNF:
1. Nomsuc es una clave candidata en el esquema sucursal
2. Dependencia Funcional no trivial que se cumple tiene nomsuc en el lado izquierdo de la flecha.

Esquema prstamo no est en BCNF:
1. numprest no es una superclave del esquema prstamo (por haber prstamos de dos o ms personas,
mancomunadas). Este esquema est en una forma no deseable, ya que padece del problema de repeticin de
informacin.

Tenemos como punto de partida los esquemas que no estn en BCNF y los descomponemos en:

Esquema_info_prestamo = ( nomsuc, numprest, cantidad )
Esquema_prestamo_cliente = ( nomcli, numprest )

a) Esto es una descomposicin de productos sin prdida.
b) Hay que determinar que Dependencias Funcionales les son aplicables:
numprest cantidad, nomsuc (Esquema_info_prstamo)
c) numprest es una clave candidata de Esquema_info_prstamo
d) En el Esquema_prstamo_cliente slo se aplican dependencias funcionales triviales.

Entonces los dos esquemas estn en BCNF.

Esquema depsitos no est en BCNF

Esquema_info_cuenta = ( nomsuc, numcuenta, saldo )
Esquema_cuenta_cliente = ( nomcli, numcuenta )

Ejemplos:
Esquema_prestar = ( nomsuc, activo, ciudad_suc, numprest, nomcli, cantidad)

Base de Datos I

Dependencias Funcionales:
numprest cantidad, nomsuc Este esquema no est en BCNF
Claves: (numprest, nomcli)

Realizar una descomposicin de producto sin prdida, que conserven las dependencias y que estn en BCNF.

Siempre hay que satisfacer los tres objetivos del diseo.
BCNF
Producto sin prdida
Conservacin de las dependencias

No todas las descomposiciones BCNF conservan las dependencias funciones :
Esquema_banquero = (nomsuc, nomcli, nombre_banquero)
D.F. nombre_banquero nomsuc
nomcli, nomsuc nombre_banquero

Esquema Banquero no est en BCNF, ya que nombre_banquero no es una superclave.

Esquema_sucursal_banquero = ( nombre_banquero , nomsuc )
Esquema_banquero_cliente = ( nomcli, nombre_banquero)

Los esquemas descompuestos conservan slo nombre_banquero nomsuc (y las dependencias triviales).

El cierre de { nombre_banquero nomsuc } no incluye nomcli, nomsuc nombre_banquero . La violacin
de esta dependencia no puede detectarse a menos que se calcule un producto.

Toda descomposicin BCNF de esquema banquero debe fallar a la conservacin de
nomcli, nomsuc nombre_banquero.

TERCERA FORMA NORMAL

En aquellos casos en los que no pueden satisfacerse los tres criterios de diseo, abandonamos BCNF y
aceptamos una forma normal ms dbil, llamada 3NF. (Siempre se puede conseguir llegar a esta 3NF)

BCNF requiere que todas las Dependencias Funcionales no triviales sean de la forma o| donde o es una
superclave.

3NF permite Dependencias Funcionales que el lado izquierdo no sea una superclave.

Un esquema de relaciones R est en 3NF con respecto a un conjunto de Dependencias Funcionales, si para todos
las Dependencias Funcionales en F+ de la forma o|, donde o _ R y | _ R, por lo menos se cumple una de
las condiciones siguientes:
o > | es una Dependencias Funcionales trivial.
o es una superclave de R.
Cada atributo A en | - o est contenido en una clave candidata en R.

- BCNF no acepta el 3er criterio. Dependencias Transitivas.
- Todo esquema BCNF est tambin en 3NF.
- BCNF es ms restrictiva que 3NF.

Esquema banquero si est en 3NF. Se sabe que nomcli y nomsuc es una clave candidata.
La Dependencia Funcional no trivial { nomcli, nomsuc nombre_banquero }

Esta dependencia no viola la definicin de 3NF.
Base de Datos I

Ejemplo:
Esquema_info_banquero = (nomsuc, nomcli, nombre_banquero, numoficina)
D.F. nombre_banquero nomsuc, numoficina
nomcli, nomsuc nombre_banquero

Descomposicin sin prdida.

Esquema_oficina_banquero = (nombre_banquero, numoficina)
Esquema_banquero = (nomcli, nomsuc, nombre_banquero)

Puesto que el esquema banquero contiene una clave candidata del Esquema_oficina_banquero, hemos hecho un
proceso de descomposicin.

COMPARACION DE BCNF Y 3NF

La 3NF tiene la ventaja de que sabemos que siempre es posible obtener un diseo 3NF sin sacrificar un producto
sin prdida o la conservacin de las dependencias.

No obstante, 3NF tiene una desventaja, sino eliminamos las Dependencias Funcionales transitivas, puede ser
necesario utilizar valores vacos para representar alguna de las posibles relaciones significativas entre los datos,
y esta el problema de la repeticin de informacin.

Ejemplo:

Esquema_banquero = ( nomcli, nombrebanquero, nomsuc) y un Dependencias Funcionales asociados
nombrebanquero Nomsuc

1. Para hacer esto, bien debe haber un valor correspondiente para nomcli o bien debemos utilizar un valor nulo
para el atributo nomcli.

2. Se presenta repeticin de informacin. (nomcli nomsuc .)

Si nos vemos obligados a elegir entre BCNF y la conservacin de las dependencias con 3NF, generalmente es
preferible optar por 3NF.

Si no podemos probar la conservacin de las dependencias eficientemente, pagamos un alto precio en el
rendimiento del sistema o un riesgo de integridad de los datos de la Base de Datos. Ninguna de estas alternativas
resulta atractiva.

Con tales alternativas, la cantidad limitada de redundancia impuesta por las dependencias transitivas, permitidas
en 3NF es la menos mala. As pues, normalmente elegimos asegurar la conservacin de las dependencias y
sacrificios BCNF.

Resumen:

El objeto de un diseo de Base de Datos relacional es:
BCNF
Producto sin prdida
Conservacin de las dependencias.

si no se puede lograr esto, aceptamos :
3NF
Producto si prdida
Conservacin de las dependencias.

Base de Datos I

Ejemplo:

rdenes de compra del catlogo de clientes de diferentes ciudades

Codcli nomcli ciudad
preciode
entrega
precio
unidad
Node
Inventariosolicitud Fecha
C1 John Chiclayo 0.75 8,25 13 1
2
06/05
10/12
C2 Jane Piura 195 4,01
8,20
2,00
12
13
11
1
2
3
05/15
C3 Pedro Chiclayo 0.75 4,01
2,01
12
11
1
2
08/10
10/10
C4 Rita Lima 225 10,51 14 1 05/05

Dependencias Funciones:
nomcli, num_inventario, fecha solicitud
num_inventario precio unidad
codcli nomcli, ciudad
ciudad precio_ent

Resultado:
orden = ( codcli, num_inventario, fecha, solicitud)
inventario = ( num_inventario, precio unidad)
cliente = (codcli, nomcli, ciudad)
preciodeentrega =(ciudad, precio_ent)

Estn en 3FN y BCNF

Ejemplo:

Relacin Proyecto-PC-Programador
#proyecto PC Programador
P01 IBM Renzo
P01 APPLE Aurelia
P15 ATARI Herbert
P23 IBM Renzo
P30 IBM Javier

Siguientes reglas Semnticas:

1. Para cada proyecto, una PC dada es usada por un slo programador an cuando el programador trabaje en ms
proyectos.
2. Un proyecto puede usar distintos tipos de PC
3. Un programador se especializa slo en un tipo de PC, pero una PC se puede compartir entre distintos
programadores, para distintos proyectos.

Dependencias Funcionales: #proyecto, PC Programador
Programador PC

Resultado:
Programador-PC = (programador, PC) = Programador-PC
Proyecto-Programador = (#proyecto, programador)
Esta en BCNF

Base de Datos I

DEPENDENCIAS MULTIEVALUADAS

Generalmente, un proceso de normalizacin termina cuando todas las relaciones divididas pertenecen a la tercera
forma normal. Sin embargo si una relacin contiene dependencias de valores mltiples, es necesaria una
normalizacin posterior.

B A

El atributo A de esta relacin se dice ser dependencia multivaluada (DMV) del atributo B si un rango
especificado de valores del atributo A est determinado por un valor particular de B.

A, B C DMV trivial

A B
C DMV no trivial

Relacin Inventario = (#inventario, color, talla, precio)

#inventario Precio Color Talla
L1
L1
L1
L1
L1
L1
L1
L1
L2
L2
L2
L2
L2
L2
2
2
2
2
2
2
2
2
4
4
4
4
4
4
azul
azul
azul
azul
rojo
rojo
rojo
rojo
verde
verde
rojo
rojo
blanco
blanco
1
2
3
4
1
2
3
4
1
2
1
2
1
2

#inventario color DMV no
talla trivial

#inventario precio DF no trivial

Las Dependencias multivaluadas se pueden eliminar siguiendo uno de los dos siguientes mtodos.

1) Crear una nueva relacin para cada atributo DMV

relacin Talla = ( #inventario, talla )
relacin Color = ( #inventario, color ) 4FN
relacin Precio = ( #inventario, precio)

2) Reemplazar un atributo DMV con atributos funcionalmente dependientes.

Relacin Talla = ( #inventario, talla )
Relacin Inventario = (#inventario, precio, color1, color2, color3) 4FN
I1 2 Azul Rojo ---
I2 4 Rojo Verde Blanco

Una relacin est en 4FN, si est en BCNF y no contiene DMV (no triviales)

Base de Datos I

Ejemplo : Relacin R = (A, B, C, D, E, F, G, H, I)

A D A I, C A, B H B E, F F G

D dependencia multivaluada de A
H dependencia funcional de AB
IC dependencia funcional de A
EF dependencia funcional de B
G dependencia funcional de F o dependencia transitiva de B

R D

A I C Separar relaciones DMV
H
B E F G

R2 A I , C R1 A D
H Separar no claves que no son totalmente
B E , F , G dependientes de la clave principal

R4 A R3 A I , C R1 A D
H
B R5 B E , F , G Eliminar dependencias transitivas

R4 A R3 A I , C R1 A D
H
B R6 B E , F R7 F G

Resultado: R1, R3, R4, R6, R7

Base de Datos I

NORMALIZACIN

Primera forma normal (1FN):
Una relacin esta en 1FN.-
Si y solo si todos los dominios simples subyacentes contienen valores atmicos
Si y solo si todos los campos en cada registro contienen un solo valor tomado de su dominio respectivo.

Segunda forma normal (2FN):
Si y solo si est en 1FN y todos los atributos no claves dependen por completo de la clave principal
Si y solo si est en 1FN y cada atributo no claves de la relacin es total y funcionalmente dependiente de la clave
principal.

Tercera forma normal (3FN):
Si y solo si est en 2FN y todos los atributos no claves dependen de manera no transitiva de la clave principal
Si y solo si est en 2FN y ningn atributo no clave en la relacin es funcionalmente dependiente de algn otro
atributo no clave.

Ejemplo:
R = ( CodCli, ciudad, situacin, CodPro, cantidad)

DF: CodCli, CodPro cantidad
CodCli ciudad, situacin
Ciudad situacin
1FN: R1 = ( CodCli, CodPro, cantidad )
R2 = ( CodCli, ciudad, situacin )

2FN: R1 y R2 cumplen la condicin

3FN: R1 = ( CodCli, CodPro, cantidad )
R21 = ( CodCli, ciudad )
R22 = ( ciudad, situacin )

Ejemplo:
R = (Codcli, nomcli, ciudad, tarifa, numinv, preuni, cant, fecha)

DF: Codcli nomcli, ciudad, tarifa
Numinv preuni
Codcli, numinv, fecha cant

1FN: R1 = ( codcli nomcli, ciudad, tarifa )
R2 = ( numinv, preuni )
R3 = ( codcli, numinv, fecha, cant )

2FN: R1 y R2 cumplen la condicin

3FN: R11 = ( codcli nomcli, ciudad )
R12 = ( ciudad, tarifa )
R2 = ( numinv, preuni )
R3 = ( codcli, numinv, fecha, cant )

Base de Datos I

Forma normal de Boyce Cobb (BCFN):
Una relacin esta en BCFN.-
Si y solo si est en 3FN y todo determinante es una clave candidata. Se puede presentar una de las siguientes
condiciones:
a) Hay varias claves candidatas
b) Las claves candidatas son compuestas
c) Las claves candidatas se traslapan (por lo menos un atributo en comn)
La combinacin de las condiciones se presenta muy raras veces. Si se presenta, las tablas estn en 3FN.

Un determinante es un atributo del cual depende funcionalmente algn otro atributo.

a) Dos claves candidatas sin atributos comunes

R = ( CodCli, nombre, situacin, ciudad )
Determinantes: {CodCli} y {nombre}
Claves candidatas: {CodCli} o {nombre}

DF: CodCli nombre, situacin, ciudad o nombre CodCli, situacin, ciudad

R esta en BCNF

Base de Datos I

MOTORES DE PERSISTENCIA

Es generalmente sabido que una aplicacin informtica consta de dos componentes
principales que colaboran para llevar a cabo la funcionalidad que el usuario desea. El
primero de estos componentes es la base de datos, que guarda la informacin necesaria
para operar la aplicacin, en forma de datos en disco. El segundo de estos componentes
es el programa propiamente dicho, que recupera esos datos de la base de datos, realiza
los clculos necesarios y presenta los resultados deseados al usuario.

Para que estos dos componentes puedan funcionar juntos deben poder comunicarse
intercambiando datos, como se observa en la figura 1. En otras palabras, deben ser
compatibles. Sin embargo, durante los ltimos treinta aos la evolucin de estos dos
componentes ha sido divergente, de forma que cada vez se ha hecho ms difcil que
colaboren en una misma aplicacin.

As, desde los aos 70 a la actualidad, las bases de datos utilizan un modelo terico llamado relacional, que se
ha convertido en un estndar y que es utilizado en la prctica totalidad de aplicaciones de software.

En cambio, los programas han usado, desde los aos 80, un modelo llamado orientado a objetos, que difiere en
mucho del modelo relacional y que se ha extendido cada vez ms. Es por ello que aparece un conflicto a la hora
de reunir estos dos componentes en una aplicacin, ya que cada uno responde a diferente modelo y forma de
operar. Cada componente maneja los datos con un formato diferente. Metafricamente, podramos afirmar que el
programa y la base de datos hablan idiomas diferentes y, por lo tanto, la comunicacin entre ellos resulta difcil.

Este artculo comienza con una descripcin de los dos modelos mencionados y de las diferencias que dificultan
su combinacin en una sola aplicacin. A continuacin, se exploran las diferentes soluciones a este problema y
se acaba concluyendo que la mejor manera de resolverlo es usando un motor de persistencia. El artculo finaliza
indicando los nombres de los motores de persistencia ms usados, con el fin de que el lector pueda elegir el que
ms se adapta a sus necesidades.

MODELO ORIENTADO A OBJETOS
El modelo orientado a objetos es el modelo terico que usa la mayora de los programas actuales. La
programacin orientada a objetos hunde sus races en los aos sesenta (en los que aparecieron los primeros
lenguajes de este tipo, llamados Simula I y Simula 67, desarrollados en el Centro Noruego de Computacin,
en Oslo). En los primeros 70, aparece Smalltalk, un lenguaje fundamental en la historia de la orientacin a
objetos.

Sin embargo, no es hasta la segunda mitad de los aos 80 cuando la orientacin de objetos se generaliza,
convirtindose en el estndar predominante en los aos 90, de la mano de lenguajes como C++ y Java. El triunfo
de la programacin orientada a objetos ha sido impulsado por la enorme difusin de otras tecnologas (como la
interfaz grfica o las arquitecturas distribuidas) que son ms fciles de implementar mediante este tipo de
desarrollo que mediante una programacin tradicional.

Hoy en da, la prctica totalidad de los lenguajes de programacin que surgen son orientados a objetos y esta
tecnologa se ha convertido en el estndar actual de programacin que, a su vez, est generando nuevos
desarrollos muy prometedores para el futuro (como, por ejemplo, la programacin orientada a aspectos).

La idea de la orientacin a objetos es modelar los programas de una forma parecida a cmo percibimos la
realidad. Para la mente humana, el universo est compuesto por una serie de objetos (en el sentido ms amplio
de la palabra, incluyendo seres vivos, ideas, etc.). Cada objeto tiene unas caractersticas que lo diferencian de los
dems y, con cada objeto, se pueden realizar unas acciones que son propias y especficas del mismo.
As, por ejemplo, un determinado auto tiene unas caractersticas (color rojo, caja de cambios automtica, diesel,
etc.) y puede realizar unas determinadas acciones (acelerar, frenar, etc.).

La programacin orientada a objetos intenta modelar estos objetos reales con estructuras de programa, llamadas
objetos de software o, simplemente, objetos. Cada uno de estos objetos de software, est compuesto por una
serie de caractersticas (llamadas atributos) y una serie de acciones (llamadas mtodos), al igual que un
objeto de la vida real. Una representacin grfica de un objeto de software se muestra en la figura 2.
Base de Datos I

La forma de programar estos objetos de software es similar a la forma en la que se comportan los objetos en la
realidad. As, por ejemplo, en la vida real un auto contiene piezas. Anlogamente, en el programa, un objeto de
software Auto contiene objetos Pieza, como podemos observar en la figura 3.

Es importante remarcar que el modelo orientado a objetos es un modelo que incluye tanto la parte esttica de un
objeto (los atributos del mismo, es decir, sus caractersticas) como su parte dinmica (los mtodos, es decir,
sus acciones). Usando una terminologa bien conocida en desarrollo, incluye tanto los datos como los
procesos.

En resumen, la programacin orientada a objetos se basa en la realidad. Su mayor ventaja es que simplifica el
mantenimiento de los programas y hace posible programar y mantener hasta los programas ms enormes al
dividirlos en partes ms pequeas, es decir, en objetos. Como consecuencia, produce reducciones de costos y
mayor calidad del cdigo y se ha convertido en el estndar actual de programacin.

MODELO RELACIONAL
Muy ajeno a la revolucin que supuso la orientacin a objetos, el rea de las bases de datos sigue fiel a un
modelo antiguo pero que ha probado su eficacia, el llamado modelo relacional.

El modelo relacional se basa en un artculo publicado por E.F.Codd en 1970. Las primeras bases de datos
relacionales comerciales aparecen en la segunda mitad de los aos setenta. Desde entonces, el modelo relacional
se convierte en un estndar prcticamente universal para el acceso a datos, dominando totalmente el rea de las
bases de datos hasta la actualidad.

El modelo relacional es muy diferente del modelo orientado a objetos. Por una parte, el modelo relacional slo se
ocupa de la parte esttica de la aplicacin (de los datos) y no de la parte dinmica (los procesos). Usando el
ejemplo anterior, en el modelo relacional, slo me interesan las caractersticas del auto (su color, su tipo de caja
de cambios, etc.) y no las acciones que puedo hacer con l (acelerar, frenar, etc.) . Este nfasis en los datos es
lgico en un modelo cuyo objetivo es modelar la parte esttica de la aplicacin, es decir, la base de datos.

Hay otras diferencias entre los dos modelos. Por ejemplo, la forma en la que el modelo relacional trata los datos
es muy diferente a como lo hace el modelo orientado a objetos. Mientras en este ltimo, los datos son modelados
en forma de objetos, en el modelo relacional son modelados como registros, los cuales son una serie de datos
pertenecientes a una misma entidad de la vida real. Un registro difiere de un objeto en que slo modela datos y
que stos no tienen estructura. La representacin grfica de un registro aparece en la figura 4.

Los registros similares se agrupan en tablas. Podemos imaginarnos las tablas como listados de datos parecidos a
los listados de impresin que hay en las empresas (de empleados, de facturas, etc.). En esta comparacin, cada
registro sera una lnea del listado.
Base de Datos I

Usando el ejemplo anterior, cada registro contendra los datos de un determinado auto (color rojo, caja de
cambios automtica, diesel, etc.) y las tablas no seran ms que listas de autos con todos sus datos, como se
observa en la figura 5.

El modelo relacional no refleja la estructura de la realidad. Como hemos dicho, si un auto contiene piezas, un
objeto de software Auto contiene objetos Pieza. Sin embargo, en el modelo relacional, los registros de los
autos y piezas estn por separado (esto se muestra en la figura 5) y se relacionan por un mecanismo implcito
llamado clave fornea. El programador debe saber que hay una relacin entre los autos y las piezas y debe
programar de acuerdo a ello. Sin embargo, el modelo no refleja explcitamente esta relacin y, en general, la
estructura de la realidad, al contrario del modelo orientado a objetos.

APLICACIONES TRADICIONALES
Como conclusin de lo que se ha dicho hasta ahora, una aplicacin est formada por un programa y una base de
datos que se comunican entre s. El programa suele estar diseado segn el modelo orientado a objetos y, por lo
tanto, trabaja con datos en formato de objetos. Por el contrario, la base de datos est diseada segn el modelo
relacional y, por lo tanto, trabaja con datos en formato de registros. Esto introduce una dificultad importante,
porque los dos formatos de datos (objetos y registros) son incompatibles entre s. As, cuando el programa quiere
guardar o recuperar los datos en disco (para que no se pierdan entre ejecuciones), lo hace n forma de objetos,
pues es el formato de datos que conoce. Sin embargo, la base de datos no puede guardar o recuperar objetos,
pues est diseada para guardar o recuperar registros (y no objetos), que es el formato de datos que ella
reconoce. Esto se muestra en la figura 6. Resumiendo, los formatos de datos que utilizan el programa y la base
de datos son incompatibles entre s. Podemos decir que el programa y la aplicacin hablan idiomas diferentes
y, por lo tanto, debemos encontrar una solucin para que se comuniquen.

La solucin ms obvia a este problema es hacer que uno de los componentes hable el idioma del otro. Es decir,
que un componente use el formato de datos del otro. As, la primera opcin que examinamos en este artculo es
la de que el programa est diseado para tratar con datos relacionales, la cual se refleja en la figura 7. En esta
opcin, tanto el programa como la base de datos hablan un mismo idioma: el relacional y utilizan como formato
de datos el de registro. Por lo tanto, la comunicacin es posible.
Base de Datos I

sta era la forma de programar universalmente adoptada antes de la aparicin de la orientacin a objetos y sigue
siendo la arquitectura dominante en El Salvador. An entre las empresas que utilizan lenguajes orientados a
objetos, la mayora programa sin tener en cuenta la orientacin a objetos a la hora de usar los datos, los cuales se
gestionan de forma relacional.

El problema de esta arquitectura es que se desaprovechan las grandes ventajas de flexibilidad, facilidad de
mantenimiento y facilidad de gestin de sistemas complejos que da la programacin orientada a objetos.
Asimismo, el cdigo que opera con datos relacionales suele ser complejo, difcil de mantener y de ampliar y muy
dependiente de la estructura de los datos.

BASES DE DATOS ORIENTADAS A OBJETOS
Como hemos visto en el apartado anterior, la opcin
consistente en que toda la aplicacin use un mismo
modelo terico relacional no es la ms adecuada.
Examinemos ahora la opcin en que toda la aplicacin
tenga un nico modelo terico, pero que ste sea el de
orientacin a objetos. Esta opcin, que se refleja en la
figura 8, implica que el formato de datos que usa toda la
aplicacin es el formato de objetos.

Para un programa resulta natural trabajar con objetos. Sin
embargo, esto es imposible para las bases de datos tradicionales, basadas en el modelo relacional. Para resolver
este problema han aparecido las bases de datos orientadas a objetos. Al contrario de sus homlogas relacionales,
que trabajan con registros, las bases de datos orientadas a objetos guardan y recuperan objetos. Por lo tanto, la
comunicacin de este tipo de base de datos con un programa orientado a objetos es posible.

Aunque, sobre el papel, sta es la mejor opcin para implementar una aplicacin de base de datos, en la prctica
presenta una serie de problemas importantes, debido a las caractersticas actuales de las bases de datos orientadas
a objetos. stas no estn tan maduras como sus homlogas relacionales y, por lo tanto, no gozan de la
abundancia de herramientas, la fiabilidad, facilidad de administracin y rendimiento de estas ltimas.

Lo que es peor, las bases de datos orientadas a objetos frecuentemente son incompatibles entre ellas. Esto hace
imposible migrar una aplicacin desde una base de datos orientada a objetos a otra, lo que nos obliga a depender
de un nico proveedor (fenmeno conocido como vendor lock-in), con todas las inconveniencias que esto
supone (obligacin de aceptar los aumentos de precio del proveedor, falta de soporte si el proveedor sale del
mercado, etc.).

Como conclusin, aunque sta pueda ser la opcin preferible en un futuro, en el que las bases de datos orientadas
a objetos alcancen una madurez y estandarizacin suficientes, en el presente resulta arriesgado aplicarla.

MOTORES DE PERSISTENCIA
Hemos visto que las opciones que se basan en imponer un nico modelo terico (un nico formato de datos) a
toda la aplicacin padecen de graves inconvenientes. En el caso de que toda la aplicacin siga el modelo
relacional, perdemos las ventajas de la orientacin a objetos. En el caso de que toda la aplicacin siga el modelo
orientado a objetos, tenemos que las bases de datos que debemos usar estn inmaduras y tienen un bajo nivel de
estandarizacin.

Examinemos ahora la opcin de que el programa sea orientado a objetos y la base de datos sea relacional, lo que,
en principio, constituye la opcin ms natural. Sin embargo, plantea el problema de cmo hacemos que dos
Base de Datos I

componentes con formatos de datos muy diferentes puedan comunicarse y trabajar conjuntamente. Siguiendo la
metfora anterior, se trata de hacer que dos personas que hablan idiomas diferentes se comprendan.

La solucin es la misma que se dara en la vida real. Se debe encontrar un traductor que sepa traducir de cada
idioma al otro. De esta forma, las dos personas se entendern sin necesidad de que uno hable el idioma del otro.
En el mundo de la programacin este traductor no es ms que un componente de software (concretamente, una
capa de programacin), al que se le dan los nombres de capa de persistencia, capa de datos,
correspondencia O/R (OR mapping) o motor de persistencia.

El motor de persistencia traduce entre los dos formatos de datos: de registros a objetos y de objetos a registros.
La situacin se ejemplifica en la figura 9. Cuando el programa quiere grabar un objeto llama al motor de
persistencia, que traduce el objeto a registros y llama a la base de datos para que guarde estos registros. De la
misma manera, cuando el programa quiere recuperar un objeto, la base de datos recupera los registros
correspondientes, los cuales son traducidos en formato de objeto por el motor de persistencia.

El programa slo ve que puede guardar objetos y recuperar objetos, como si estuviera programado para una base
de datos orientada a objetos. La base de datos slo ve que guarda registros y recupera registros, como si el
programa estuviera dirigindose a ella de forma relacional. Es decir, cada uno de los dos componentes trabaja
con el formato de datos (el idioma) que le resulta ms natural y es el motor de persistencia el que acta de
traductor entre los dos modelos, permitiendo que los dos componentes se comuniquen y trabajen conjuntamente.

Esta solucin goza de las mejores ventajas de los dos modelos.
- Por una parte, podemos programar con orientacin a objetos, aprovechando las ventajas de flexibilidad,
mantenimiento y reusabilidad.
- Por otra parte, podemos usar una base de datos relacional, aprovechndonos de su madurez y su
estandarizacin as como de las herramientas relacionales que hay para ella.

Se calcula que un motor de persistencia puede reducir el cdigo de una aplicacin en un 40%, hacindola menos
costosa de desarrollar. Adems, el cdigo que se obtiene programando de esta manera es ms limpio y sencillo y,
por lo tanto, ms fcil de mantener y ms robusto. Por aadidura, el motor de persistencia no slo simplifica la
programacin, sino que permite hacer ciertas optimizaciones de rendimiento que seran difciles de programar
por nosotros mismos.

Como conclusin, sta es la mejor opcin en la actualidad para implementar una aplicacin de software.

OPCIONES PARA MOTORES DE PERSISTENCIA
Una ventaja del motor de persistencia es que es el mismo para todas las aplicaciones. De esta forma slo debe
programarse una vez y puede usarse para todas las aplicaciones que se desarrollen en nuestra empresa. Sin
embargo, un motor de persistencia es difcil de programar y de mantener, por lo que necesita un gran esfuerzo en
costo y tiempo de desarrollo.

Es por ello que hay dos opciones a la hora de usar un motor de persistencia:
- Programarlo dentro de nuestra empresa. Como se ha dicho, esto no es lo ms recomendable, por la
complejidad y costo que introduce esta opcin.
- Utilizar un motor que ya est programado, comprndolo a un vendedor o bien usando un motor gratuito
de cdigo abierto.
Base de Datos I

Se recomienda fuertemente la segunda opcin, que es la menos costosa y la menos propensa a fallos. Se debe
escoger un motor de persistencia de los que estn programados, estudiarlo y aplicarlo a todas las aplicaciones de
una misma empresa. A continuacin, explicamos algunos de los motores de persistencia ms importantes para la
plataforma Java y para la plataforma .NET, con el fin de que el lector pueda comenzar una investigacin que le
lleve a escoger el que ms se ajuste a sus necesidades.

En cuanto a la plataforma Java, los servidores de aplicaciones basados en la especificacin EJB (Enterprise
JavaBeans), incorporan un motor de persistencia a travs del mecanismo conocido como entity beans. Sin
embargo, los entity beans no son un mecanismo de persistencia totalmente recomendable, pues no permiten
implementar algunas caractersticas de la programacin orientada a objetos (por ejemplo, herencia) y adems,
obligan a una forma de programar diferente a los objetos normales de Java (o POJOs, por Plain Old Java
Objects).

Hay motores de persistencia ms completos que no tienen este tipo de inconvenientes que se acaba de
mencionar. Entre los de cdigo abierto podemos destacar: Hibernate, Castor, Torque, OJB y Cayenne. Entre los
comerciales, podemos destacar TopLink, Cocobase y FastObjects. En los ltimos aos se ha creado una
especificacin llamada JDO, para estandarizar la forma de programar en Java con esos motores de persistencia.
Ejemplos de motores de persistencia que cumplen el estndar JDO son Kodo, JDO Genie, LiDo, Exadel JDO,
IntelliBO, JRelay JDO (todos ellos comerciales), TJDO y XORM (de cdigo abierto).

La plataforma .NET, por su relativa novedad, est ms inmadura que la plataforma Java. Adems, al ser una
plataforma propietaria, cuesta ms encontrar proyectos de cdigo abierto para ella. Por todo ello que no hay tanta
variedad de motores de persistencia en esta plataforma. Recientemente, Microsoft ha anunciado un motor de
persistencia llamado Objectspaces para .NET 2004. Mientras tanto, se puede usar ORM.NET, que es un motor
de persistencia comercial para .NET.

Material BA1 2011

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Material BA1 2011

Caricato da

Copyright:

Formati disponibili

Base de

Potrebbero piacerti anche