Base de Datos I

Base de

Datos I

Escuela Tecnológica Superior

Universidad de Piura

Base de Datos I

Escuela Tecnológica Superior - UDEP Página 2

Tabla de contenido

TEORIA GENERAL DE SISTEMAS .................................................................................................................... 4

INTRODUCCIÓN .............................................................................................................................................. 4

OBJETIVO DE LOS SISTEMAS DE BDD ....................................................................................................... 4

ABSTRACCIÓN DE DATOS ............................................................................................................................ 4

MODELO DE DATOS ....................................................................................................................................... 5

INSTANCIA Y ESQUEMAS ............................................................................................................................. 7

INDEPENDENCIA DE DATOS ........................................................................................................................ 7

LENGUAJE DE DEFINICIÓN DE DATOS (DDL) ........................................................................................ 7

LENGUAJE DE MANIPULACIÓN 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 - RELACIÓN ................................................................................................................... 12

ENTIDADES Y CONJUNTOS DE ENTIDADES ........................................................................................... 12

RELACIONES Y CONJUNTOS DE RELACIONES ...................................................................................... 12

ATRIBUTOS .................................................................................................................................................... 12

RESTRICCIONES DE ASIGNACIÓN (MAPPING) ...................................................................................... 13

CLAVES ........................................................................................................................................................... 14

DIAGRAMA ENTIDAD-RELACION ............................................................................................................. 15

REDUCCION DE LOS DIAGRAMAS E-R A TABLAS ............................................................................... 16

GENERALIZACION ........................................................................................................................................ 17

AGREGACIÓN ................................................................................................................................................ 18

DISEÑO DE UN ESQUEMA DE BASE DE DATOS DE E-R ....................................................................... 19

DICCIONARIO DE DATOS ................................................................................................................................ 20

DEFINICIÓN .................................................................................................................................................... 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

DISEÑO DE BASES DE DATOS RELACIONALES ......................................................................................... 41

PELIGROS EN EL DISEÑO 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

NORMALIZACIÓN ............................................................................................................................................. 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

INTRODUCCIÓN

Un sistema de gestión de base de datos (DBMS) consiste en una colección de datos interrelacionados y un

conjunto de programas para acceder a esos datos. La colección de datos normalmente denominada BASE DE

DATOS (BDD) contiene información acerca de una empresa determinada. El objetivo primordial de un sistema

de gestión de base de datos es proporcionar un entorno que sea a la vez conveniente y eficiente para ser utilizado

al extraer y almacenar información de la BDD.

Los sistemas de BDD están diseñados para gestionar grandes bloques de información y mantener la seguridad de

la información almacenada, pese a la caída o intento de acceso no autorizados. Si los datos son compartidos por

varios usuarios, el sistema debe evitar posibles resultados anómalos.

La gestión de datos implica tanto la definición de la estructura para el almacenamiento de la información como

la previsión de mecanismos para la gestión de la información.

OBJETIVO DE LOS SISTEMAS DE BDD

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

Los registros Varios Archivos Diferente número de Programa

de aplicación

Almacenamos

Estos sistemas tienen un número 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 difícil escribir

nuevos programas).

4. Anomalías de acceso concurrente.

5. Problemas de Seguridad.

6. Problemas de Integridad (Restricciones de consistencia).

ABSTRACCIÓN DE DATOS

Un objetivo importante de un sistema de BDD es proporcionar a los usuarios de una visión abstracta de los

datos. Existen diversos niveles de abstracción. Así:

1. NIVEL FÍSICO.- Es el más 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 términos de un

número pequeño de estructuras relativamente sencillas aunque en el mundo físico no es así. Este nivel

es usado por el administrador de la BDD, quien decide que información deben guardar.

3. NIVEL DE VISIONES. Es el nivel más alto de abstracción y describe parte de la BDD completa.

Muchos usuarios del sistema de BDD no les interesa la totalidad de la información, los usuarios solo

necesitan una parte de la información (solo necesitan una parte de la BDD). El sistema puede

proporcionar muchas visiones para la misma BDD.

Base de Datos I


.....

REGISTROS: Cuentas (Campos: número y saldo)

Empleado (Campos: nombre y salario)

Clientes (Campos: nombre, calle y ciudad)

NIVEL FÍSICO: 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 definición de tipo y se define la

interrelación entre estos tipos de registros.

NIVEL DE VISIÓN: Se definen varias visiones de la BDD (Los cajeros solo ven la parte de la BDD que tiene

información 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 colección de herramientas conceptuales para describir datos, relaciones entre ellos, semántica

asociada a los datos y restricciones de consistencia. Los modelos de datos se dividen e tres grupos:

Modelo Lógico Basado en Objetos.

Modelo Lógico Basado en Registros.

Modelo Físico de Datos.

MODELO LÓGICO BASADO EN OBJETOS.- Se usan para describir datos en los niveles conceptual y

de visión. Se caracterizan por el hecho de que proporcionan capacidad de estructuración bastante flexible y

permiten especificar restricciones de datos.

Los más extensamente conocidos son:

- Modelo Entidad Relación

- Modelo Orientado a Objetos

- Modelo Infológico

- Modelo Binario

- Modelo Semántico de Datos

- Modelo Funcional de Datos

MODELO ENTIDAD RELACIÓN.- Se basa en una percepción de un mundo real, consiste en una

colección de objetos básicos 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 relación es una asociación entre

varias entidades.

Calle

Nombre Ciudad Número Saldo

Cliente CtaCli Cuenta

Visión 1 Visión 2 Visión 3 Visión N

Nivel Conceptual

Nivel Físico

Base de Datos I


MODELO ORIENTADO A OBJETOS.- Se basa en una colección de objetos. Un objeto contiene valores

almacenados en variables instancias dentro del objeto. Un objeto también contiene parte de código que

opera sobre el objeto, estas partes se llaman MÉTODOS. Los objetos que contienen los mismos tipos de

valores y los mismos métodos se agrupan en clase (una clase puede ser vista como una definición de TYPE

para objeto).

La única forma en la que un objeto puede acceder a los datos de otro objeto es invocando a los métodos de

ese objeto, esto se llama “Envío de un mensaje” al objeto.

Variable Instancia = Número y Saldo

Método = Interés de Pago

Si varía la tasa de interés -- Sólo varía el método.

Otras BDD tendrían que cambiar varios Programas de Aplicación.

MODELO LÓGICO BASADO EN REGISTROS.- Se utilizan para describir datos en los modelos

conceptual y físico. Se llaman así porque la BDD está estructurada en registros de formato fijo de varios

tipos. Cada tipo de registro define un número fijo de campos o atributos y cada campo es normalmente de

longitud fija (esto simplifica la implementación del nivel físico en la BDD).

Estos modelos de datos no incluyen un mecanismo para la representación directa de códigos 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 más ampliamente usados son:

Modelo relacional.

Modelo de red.

Modelo jerárquico.

MODELO RELACIONAL: Representa los datos y las relaciones entre los datos mediante una colección de

tablas, cada una de las cuales tienen un número de columnas con nombre único.

CLIENTES CUENTA

Nombre Calle Ciudad Número Número Saldo

José Castro Av. H 23 Talara 900 900 1,000

Luis López Av. Grau 572 Piura 556 556 500

Luis López Av. Grau 572 Piura 647 647 1,520

Rita Ruiz Av. Grau 572 Piura 647

MODELO DE RED: Se representa mediante una colección 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 colección de grafos arbitrarios.

José Castro Av. H 23 Talara 900 1,000

Luis López Av. Grau 572 Piura 556 500

Rita Ruiz Av. Grau 572 Piura 647 1,520

MODELO JERÁRQUICO: 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 están

organizados como una colección de árboles en vez de grafos arbitrarios.

José

Castro

Av. H

23

Talara Luis

López

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 jerárquico en que no

usan punteros o enlaces.

El modelo relacional conecta registros mediante los valores que estos contienen. Se define

una base matemáticamente formal.

MODELO FÍSICO DE DATOS.- Se usan para describir datos en el nivel más bajo. A diferencia de los

modelos lógicos de datos, hay muy pocos en uso. Dos de los más ampliamente conocidos son:

- Modelo Unificado.

- Memoria de Elementos.

Los modelos físicos de datos capturan aspectos de la implementación de los sistemas de BDD.

INSTANCIA Y ESQUEMAS

Una BDD cambia a lo largo del tiempo según se añada o elimina información.

La colección de información almacenada en la base de datos en un determinado momento en el tiempo se llama

una Instancia de la BDD.

El diseño 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 función de su nivel de abstracción)

- Esquema Físico

- Esquema Conceptual y

- Subesquemas

INDEPENDENCIA DE DATOS

Es la capacidad de modificar una definición de un esquema en un nivel sin afectar la definición de un esquema

en el nivel superior siguiente. Hay dos niveles:

1. Independencia Física de Datos.- Es la capacidad de modificar el esquema físico sin provocar que se vuelvan

a escribir los programas de aplicación. En algunas ocasiones son necesarias las modificaciones en el nivel

físico para mejorar el funcionamiento del sistema.

2. Independencia Lógica de Datos.- Es la capacidad de modificar el esquema conceptual sin provocar que se

vuelvan a escribir los programas de aplicación. Las modificaciones del nivel conceptual son necesarias

siempre que se altere la estructura lógica de la BDD.

La Independencia Lógica de Datos es más difícil de lograr que la Independencia Física de Datos, ya que los

programas de aplicación son fuertemente dependientes de la estructura lógica de los datos a los que acceden.

LENGUAJE DE DEFINICIÓN 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 Definición de Datos (DDL Data Definition Languaje).

El resultado de la compilación 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 métodos 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

Definición de Datos.

La compilación de estas definiciones da como resultado un conjunto de instrucciones que especifican los detalles

de implementación de los esquemas de BDD que normalmente se esconden de los usuarios.

Base de Datos I


LENGUAJE DE MANIPULACIÓN DE DATOS (DML) (Data Manipulation Languaje)

Es un lenguaje que capacita a los usuarios a acceder o manipular datos según estén 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

cómo obtenerlos.

Los DML No Procedimentales normalmente son más sencillos de aprender y usar que los Procedimentales. Sin

embargo, puesto que el usuario no tiene que especificar cómo conseguir los datos, estos lenguajes pueden

generar códigos que no sean tan eficientes como el producido por los lenguajes Procedimentales.

Una consulta es una sentencia que solicita la recuperación de información. El trozo de un DML que implica la

recuperación de información se llama: “Lenguaje de consultas”.

GESTOR DE BASE DE DATOS

Un gestor de BDD es un módulo de programa que proporciona el interfaz entre los datos de bajo nivel

almacenados en la BDD y los programas de aplicación y de consultas hechos al sistema.

El gestor de BDD es responsable de las siguientes tareas:

Interacción con el gestor de archivos

Implantación de la integridad

Implantación de la seguridad

Copia de seguridad y recuperación

Control de concurrencias.

INTERACCIÓN 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, recuperación y actualización

de los datos en la BDD.

IMPLANTACIÓN DE LA INTEGRIDAD

Los valores de los datos deben satisfacer ciertos tipos de restricciones de consistencia. El administrador

de BDD debe especificar explícitamente estas restricciones.

El gestor de BDD puede determinar si las actualizaciones a la BDD da como resultado la violación de las

restricciones, si así es, se debe tomar la acción apropiada.

IMPLANTACIÓN 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 RECUPERACIÓN

Es responsabilidad del gestor de BDD detectar fallas y restaurar la BDD al estado que existía antes de

ocurrir el fallo. Esto se lleva a cabo normalmente a través de la iniciación de varios procedimientos de

copia de seguridad y recuperación.

CONTROL DE CONCURRENCIA

Controlar la interacción entre los usuarios concurrentes es otra responsabilidad del gestor de BDD.

Los sistemas de BDD diseñados para utilizarse en computadoras personales pequeñas, pueden no tener todas las

características mencionadas anteriormente.

Base de Datos I


ADMINISTRADOR DE BASE DE DATOS

Una de las razones principales para tener Sistemas de Gestión 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:

Definición de esquema.

Definición de la estructura de almacenamiento y del método de acceso.

Modificación del esquema y de la organización física.

Concesión de autorización para el acceso a los datos.

Especificaciones de las restricciones de integridad.

DEFINICIÓN 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.

DEFINICIÓN DE LA ESTRUCTURA DE ALMACENAMIENTO DEL MÉTODO DE ACCESO

Se crean escribiendo un conjunto de definición que son traducidas por el compilador de lenguaje de

almacenamiento y definición de datos.

MODIFICACIÓN DEL ESQUEMA Y DE LA ORGANIZACIÓN FÍSICA

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 definición de datos

para generar modificaciones a las tablas internas apropiadas.

CONCESIÓN DE AUTORIZACIÓN PARA EL ACCESO A LOS DATOS

La concesión de diferentes tipos de autorización permite al administrador de la BDD regular que parte de

la BDD van a poder ser accedidas por varios usuarios.

ESPECIFICACIÓN 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 actualización en el sistema.

LOS USUARIOS DE LA BASE DE DATOS El objetivo primordial de un sistema de BDD es proporcionar un entorno para recuperar información de una

BDD y almacenar la información en la BDD. Hay cuatro tipos distintos de usuario de un sistema de BDD,

diferenciados por la forma en que interactúan con el sistema:

Programadores de aplicación

Usuarios sofisticados

Usuarios especializados

Usuarios ingenuos

PROGRAMADORES DE APLICACIONES

Los profesionales de computación que interaccionan con el sistema por medio de llamadas en DML, las

cuales están escritas en un lenguaje principal (Cobol, Pascal, C, etc.). Estos programas se denominan

programas de aplicación.

Los lenguajes de 4ta generación a menudo incluyen características especiales para facilitar la generación

de formas y la presentación de datos en las pantallas. La mayoría de sistemas de BDD comerciales

incluyen un lenguaje de 4ta generación.

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: Diseño asistido por computadora. Sistemas expertos, etc.

USUARIOS INGENUOS

Interactúan con el sistema, invocando a unos de los programas de aplicación permanentes que se han

escrito anteriormente.

ESTRUCTURA DEL SISTEMA GLOBAL

Un sistema de BDD se divide en módulos que tratan cada una de las responsabilidades del sistema general. El

sistema operativo (SO) proporciona únicamente los servicios más básicos por lo que el diseño 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 asignación de espacio en la memoria del disco y de la estructura de

datos usada para representar la información 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 aplicación 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

aplicación 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.

Además se requieren varias estructuras de datos como parte de la implementación del sistema físico,

incluyendo:

Archivos de datos: que almacena la BDD.

Diccionario de datos: que almacena Metadatos sobre la estructura de la BDD.

Índices: Que proporciona acceso rápido 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

Aplicación Sofisticados Base de datos

Interface de Programas Consultas Planificación de

Aplicación Base de Datos

Precompilador

de DML Procesador de

consultas

Compilador de

DDL

Código Objeto Gestor de

de Programas de BDD

aplicación SISTEMA DE

GESTIÓN DE

BDD

Gestor

de Archivos

Archivos

de datos

Diccionario de

Datos

Almacenamiento en disco

Base de Datos I


MODELO ENTIDAD - RELACIÓN

El modelo de datos entidad – relación (E-R) se basa en la percepción de un mundo real que consiste en un

conjunto de objetos básicos llamados entidades y relaciones entre estos objetos. Se desarrolló para facilitar el

diseño de BDD permitiendo la especificación de un esquema empresarial. Este esquema representa la estructura

lógica 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 día 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 noción de “TIPO” en un lenguaje de programación.

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 , Número telefónico}

Cuenta = { Número-Cuenta , Saldo}

Transacción = { Número-Transacción , Fecha , Cantidad}

RELACIONES Y CONJUNTOS DE RELACIONES

Una relación es una asociación entre varias entidades.

Cliente = Harris Cuenta = #401

Un conjunto de relaciones es un conjunto de relaciones del mismo tipo. Ejemplo : Cuenta - Cliente.

La mayoría de los conjuntos de relaciones en un sistema de BDD son binarios. Ocasionalmente, sin embargo hay

conjuntos de relaciones que implican más de dos conjuntos de entidades.(Relación ternaria: Cliente- Cuenta-

Sucursal).

Siempre es posible sustituir un conjunto de relaciones no binarias por varios conjuntos de relaciones binarios

distintos. La función que juega una entidad se llama PAPEL Los papeles normalmente son implícitos y no se

suelen especificar, sin embargo son útiles cuando el significado de una relación necesita ser clasificado. Una

relación 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, Número-telefónico}

Si consideramos un teléfono como una entidad en si mismo.

Cada empleado tiene un teléfono.

Base de Datos I


E Empleado = {Nombre-Empleado }

E Teléfono = { Número.telefónico, Situación}

R Empl-Tel = { Nombre-Empleado, Número.telefónico}

Un empleado puede tener 0 o varios teléfonos y un teléfono puede ser asignado a varios empleados.

La distinción 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 semántica asociada con el atributo en cuestión.

RESTRICCIONES DE ASIGNACIÓN (MAPPING)

Una planificación E-R de una empresa puede definir ciertas restricciones a las cuales deben ajustarse los

contenidos de una BDD. Una restricción importante es la de cardinalidades de asignación que expresan el

número de entidades con las que se puede asociar otra entidad mediante un conjunto de relaciones. Las

cardinalidades de asignación 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 asignación 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 términos de sus atributos. El concepto de superclave nos permite hacer tales

distinciones.

Una superclave es un conjunto de uno o más 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 mínimas.

Claves Candidatas: { seguro-social }

{ nombre-cliente, calle }

Una clave primaria es una clave candidata que elige el diseñador 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 débiles y fuertes están relacionadas con las dependencias de existencia.

Entidad Fuerte Entidad Dominante

Entidad Débil Entidad Subordinada

Una clave primaria de un conjunto de entidades débiles 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 distinción entre las entidades débiles.

Ej. : E (Transacción) = {Num-trans, fecha , saldo}

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

La composición de la clave primaria depende de la cardinalidad de asignación 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 asignación es muchas a muchas.

Cuenta Transacción

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 más atributos asociados.

DIAGRAMA ENTIDAD-RELACION

Una base de datos puede representarse gráficamente por medio de un diagrama E-R. Consta de los siguientes

componentes.

Rectángulos Representan conjuntos de entidades

Elipse Representan atributos

Rombos Representan conjunto de relaciones

Líneas 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 líneas que conectan los rombos a los

rectángulos.

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 Transacción

Cliente Cuenta Transacción

Fecha Cantidad

#cta. Saldo #trans

1 M

Entidad Fuerte BITÁCORA Entidad Débil

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 colección 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 número de

columnas que, a su vez, tiene nombres únicos.

Ciudad

S.S Saldo Fecha

Nomcli Calle #cta. #trans

Cta Bita-

cli cora

REPRESENTACIÓN 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

REPRESENTACIÓN DE CONJUNTO DE ENTIDADES DÉBILES

Se representan mediante la unión de la clave primaria de la entidad fuerte del que depende con los atributos

del conjunto de entidades débiles.

Ejemplo: Transacción

Cliente Cuenta

Sucursal

Base de Datos I


TRANSACCIÓN

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

REPRESENTACIÓN DE CONJUNTOS DE RELACIÓN

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.

Relación 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 débiles con su correspondiente

conjunto de entidades fuertes es especial. Estas relaciones son muchos a una y no tienen atributos

descriptivos. Además, la clave primaria de un conjunto de entidades débiles, incluye la clave primaria de

conjunto de entidades fuertes.

Entidad: Cuenta = { Numcta } CP

Transacción = { Numcta, Numtrans } CP

Relación Bitácora = { Numcta, Numtrans } Tabla

Entidad Transacción = { Numcta, Numtrans , fecha , cantidad } Tabla

La tabla bitácora es redundante y no necesita presentarse en una representación tabular en un diagrama E-R.

GENERALIZACION

En una relación de inclusión que existe entre un conjunto de entidades del nivel más alto y uno o más conjuntos

de nivel más bajo.

Numcta Saldo

Entidades del Nivel más Alto

ISA

Entidades del Nivel más Bajo

Saldo deudor tasainterés

Cuenta

CtaAhorros CtaCorriente

Base de Datos I


Empleado

Maquinaria

Proyecto

La generalización 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 generalización se usa para hacer resaltar los parecidos entre

tipos de entidades de nivel más bajo y ocultar sus diferencias. Los atributos de los conjuntos de entidades de

nivel más alto se dice que son heredados por los conjuntos de entidades de nivel más bajo. Existen dos métodos

para transformar un DER que incluyan generalización en forma tabular.

1.- Crear una tabla para el conjunto de entidades del nivel más alto. Para cada conjunto de entidades de nivel más

bajo crear una tabla que incluye una columna para cada uno de los atributos de ese conjunto de entidades más

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 más una

columna para cada atributo del conjunto de entidades del nivel más alto.

CuentaCorriente = { Numcta, saldo, saldodeudor }

CuentaAhorros = { Numcta, saldo, tasainteres }

TABLA 2

CTAAHORROS CTACORRIENTE

Numcta Saldo TasaInteres Numcta Saldo SaldoDeudor

AGREGACIÓN

Una limitación del modelo E-R es que no se puede expresar relaciones entre relaciones. La relación es una

abstracción en la cual las relaciones se tratan como entidades de nivel más 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 más alto

Trabajo

ISA

Nivel más bajo

CodMaq NomMaq

La transformación de un diagrama E-R que incluyen agregación a una forma tabular es directa.

Entidades:

EMPLEADO PROYECTO MAQUINARIA

CodEmp NomEmp CodProy NomProy CodMaq NomMaq

Relaciones:

TRABAJO ISA

CodEmp CodProy CodEmp CodProy CodMaq

DISEÑO DE UN ESQUEMA DE BASE DE DATOS DE E-R

El modelo E-R proporciona un alto grado de flexibilidad en el diseño de un esquema de BDD para modelar una

empresa dada.

Entre las decisiones a tomar se encuentran:

El uso de una relación 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 débiles.

La oportunidad de usar agregación.

La oportunidad de usar generalización.

El diseñador de BDD necesita una buena comprensión de la empresa que se va a modelar para tomar esas

decisiones.

Proyecto Empleado

Maquinaria

Base de Datos I


DICCIONARIO DE DATOS

DEFINICIÓN

Es una herramienta que complementa a los Diagramas de Flujo de Datos para la especificación técnica 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: [+] Concatenación de dos o más componentes.

Selección: [ / ] Selección de un componente, de dos o más.

Repetición: { } Repetición de uno o varios componentes.

Agrupación: ( ) Agrupación de un conjunto de datos.

FORMATO DE LAS DEFINICIONES DEL DICCIONARIO DE DATOS

Ficheros

Nombre del Fichero:

Composición: {Datos continuos / Definidos en sí mismo / Discretos}

Organización: Secuencial / Indexado / Directo.

Ubicación:

Nota :

Datos Continuos

Mnemónico :

Descripción :

Tipo : (Carácter / Numérico / Fecha / Memo)

Longitud :

Unidad : (Entero / Moneda)

Rango :

Datos Definidos en sí mismo

Mnemónico :

Descripción :

Tipo :

Longitud :

Nota :

Datos Discretos

Mnemónico : Tipo:

Descripción : Longitud:

Valores : Significado:

. .

. .

Nota:

Base de Datos I


Ejemplo de Fichero:

Nombre del fichero: Materiales

Composición : ( Codmat + Descripmat + Stock + StockMin + Stockmax + Unidad)

Datos definidos en sí mismo

1) Nombre : Codmat

Descripción : Código que identifica a un material

Tipo : carácter

Longitud : 10

2) Nombre : Descripmat

Descripción : Detalla las características propias de un material.

Tipo : carácter

Longitud : 40

3) Nombre : Stock

Descripción : Especifica la cantidad de materiales que hay en el almacén.

Tipo : Numérico.

Longitud : 8

4) Nombre : Stockmin

Descripción : Es la cantidad mínima de materiales que debe haber en el almacén.

Tipo : Numérico.

Longitud : 8

5) Nombre : Stockmax

Descripción : Es la cantidad máxima de materiales que debe haber en el almacén.

Tipo : Numérico.

Longitud : 8

6) Nombre : Unidad.

Descripción : Es la unidad de medida en la que se expresan los diferentes materiales.

Tipo : Carácter.

Longitud : 10

Organización: Indexado.

Nota: Archivo que contiene la única información 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 colección de tablas, cada una de las cuales se le asigna un nombre único.

Una fila de una tabla representa una relación entre un conjunto de valores.

ESTRUCTURA BÁSICA

Una tabla es una relación.

Una fila es una tupla.

Una tupla tiene atributos

Un atributo tiene un conjunto de valores llamado dominio.

Relación Depósitos: 5 tuplas , 4 atributos

NomSuc NumCta NomCli Saldo

Piura 101 López 800

Sullana 215 Benites 700

Paita 102 Sosa 400

Talara 305 Silupú 350

El alto 208 Martínez 900

Sea la variable tupla t, la primera tupla de la relación. Usaremos la notación 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 diseño lógico y una instancia de la BDD. Es

convenientemente dar nombres al esquema de una relación. Adoptamos el convenio de usar nombres en

minúsculas para las relaciones y nombres, empezando con una letra mayúscula, para los esquemas de relaciones.

Esquema_depósito = (nomsuc, numcta, nomcli, saldo)

Esquema de Relación

Si depósito es una relación sobre el Equema_depósito por: deposito (Esquema_depósito)

El esquema de una relación es una lista de atributos y sus correspondientes dominios, cuando queremos definir

los dominios usaremos la notación:

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

Ejemplo: Relación Clientes

Nomcli Calle Ciudad

Reyes Grau Piura

Sullón Arequipa Sullana

Chávez Brasil Talara

Zapata Tacna Lima

Benites Marañón 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 información de la BDD. Estos lenguajes

son de más alto nivel que los lenguajes estándar de programación. 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 información deseada sin dar un procedimiento

específico para obtener esa información.

Estudiaremos dos lenguajes “puros” que son álgebra relacional y cálculo relacional de tuplas

LENGUAJES RELACIONALES COMERCIALES

SQL (STRUCTURED QUERY LANGUAGE)

LENGUAJE DE CONSULTA ESTRUCTUIRADO

Es el lenguaje de BDD relacional estándar. El lenguaje SQL tiene varias partes:

Lenguaje de Definición de Datos (DDL).- El SQL DDL proporciona órdenes para definir esquemas de

relación, eliminar relaciones, crear índices y modificar esquemas de relaciones.

Lenguaje de Manipulación de Datos Interactivo (DML).- Incluye un lenguaje de consultas basado en el

álgebra relacional y el cálculo relacional de tuplas. También incluye órdenes para insertar, suprimir y

modificar tuplas en la base de datos.

Lenguaje de Manipulación de Datos Inmerso (DML).- La forma inmersa de SQL está diseñada para usar

dentro del los lenguajes de programación de propósito general. Tales como el PL/1, Cobol, Coreal, Fortran,

C, FoxPro, Visual Basic, etc.

Definición de Vistas.- El SQL DDL incluye órdenes para definir vistas.

Actualización.- El SQL DDL incluye órdenes para especificar derechos de acceso a relaciones y vistas.

Integridad.- Las versiones recientes de SQL incluyendo el ANSI estándar proporciona únicamente una

forma limitada de comprobación de la integridad.

Control de Transacciones.- SQL incluye órdenes para especificar el comienzo y final de las transacciones.

ESTRUCTURA BASICA

Consta de tres cláusulas SELECT, FROM, WHERE

SELECT: Corresponde a la operación de proyección del álgebra relacional. Se usa para listar los atributos

que se desean en el resultado de una consulta.

FROM: Corresponde a la operación de producto cartesiano del álgebra relacional. Lista las relaciones que

se van a utilizar.

WHERE: Corresponde al predicado de selección del álgebra relacional. Consta de un predicado que

implica atributos de las relaciones que aparecen en la cláusula 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 cláusula FROM.

Si se omite la cláusula WHERE, el predicado p = verdadero.

El resultado de una consulta en SQL es por supuesto una relación.

Ejemplo: Encontrar los nombres de todas las sucursales en la relación depósito.

SELECT nomsuc

FROM deposito

OPERACIONES DE CONJUNTOS Y TUPLAS DUPLICADAS

En los casos que queremos forzar la eliminación de duplicados, insertamos la palabra DISTINCT después de

SELECT.

SELECT DISTINCT nomsuc Si queremos quitar duplicados

FROM deposito SELECT ALL nomsuc Se especifica explícitamente que no se

FROM deposito eliminan los duplicados. Normalmente

no se utiliza ALL pues ya está implícita.

OPERACIONES DE CONJUNTOS:

SQL incluye operaciones de: Unión ( ), Intersect ( ), Minus ( ).

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

SELECT DISTINCT nomcli

FROM depósito

WHERE nomsuc = “Paita”

Ejemplo: Cliente que tenga un préstamo en la sucursal de Paita.


FROM préstamo


Ejemplo: Encontrar a todos los clientes que tiene una cuenta, un préstamo en la sucursal de Paita.

(SELECT DISTINCT nomcli

FROM depósito

WHERE nomsuc = “Paita”)

UNION


FROM préstamo


Ejemplo: Cliente que tiene una cuenta y un préstamo.


FROM depósito


INTERSECT


FROM préstamo

Base de Datos I



Ejemplo: Cliente de la sucursal de Paita que tienen una cuenta ,pero no un préstamo.


FROM depósito


MINUS


FROM préstamo


PREDICADOS Y CONECTORES

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

SELECT DISTINCT cliente. nomcli , ciudad

FROM préstamo, cliente

WHERE préstamo. nomcli = cliente. Nomcli

SQL usa los conectores lógicos AND ( ) , OR ( ) , NOT ( )

Las expresiones aritméticas tienen los operadores + , - , * y / operando sobre constantes o valores de

tuplas.

BETWEEN: Operador de comparación.

Ejemplo: Encontrar el nombre y la ciudad de todos los clientes de que tienen un préstamo en la sucursal de Piura.

SELECT DISTINCT cliente. nomcli , ciucli

FROM préstamo, cliente

WHERE préstamo. 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 depósito

WHERE saldo 100 000 AND saldo 90 000

También: 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 depósito

WHERE saldo NOT BETWEEN 90 000 AND 100 000

LIKE: es un operador de comparación de cadenas de caracteres.

%: El carácter % es igual a cualquier subcadena.

_: El carácter _ es igual a cualquier carácter.

ESCAPE ( \ ): se une antes de % o - cuando estos son un carácter 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

colección de valores producidos por la cláusula SELECT.

NOT IN : Prueba la de No Pertenecer al conjunto

Ejemplo:

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

(SELECT nçnombre_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 préstamo.

SELECT DISTINC nomcli

FROM deposito

WHERE nomsuc = “Piura” AND

nomcli NOT IN (SELECT DISTINC nomcli

FROM prèstamo.

WHERE nomsuc = “Piura”)

VARIABLE DE TUPLA

Una variable de tupla en SQL debe estar asociada con una relación determinada. Se definen en la cláusula

FROM.

SELECT DISTINC T. Nomcli , ciudad

FROM prèstamo 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 algún” 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 también permite las comparaciones < SOME , SOME , SOME , SOME , SOME.

(Any = Some)

La frase “mayor que todos” se representa > all.

SQL permite las comparaciones < ALL , 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 algún 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 construcción CONTAINS por computadores es demasiado caro. Por lo que no aparece en

el ANSI estándar.

PRUEBAS PARA RELACIONES VACIAS

SQL incluye una característica para probar si una subconsulta tiene alguna tupla en su resultado. La construcción

EXISTS devuelve el valor TRUE si la subconsulta del argumento no está vacía. NO EXISTS devuelve el valor

TRUE si la subconsulta del argumento está vacía.

Ejemplo: Encontrar a todos los clientes que tienen una cuenta y un préstamo 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


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

SELECT nomcli

FROM cliente

WHERE EXISTS ( SELECT *

FROM deposito

WHERE deposito.nomcli = cliente. nomcli


AND NOT EXISTS ( SELECT *

FROM prestamo

WHERE prestamo. nomcli = cliente. nomcli


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 depósito T

WHERE S. nomcli = T. nomcli ) )

ORDENACION DE LA PRESENTACION DE TUPLAS

La cláusula ORDER BY hace que las tuplas en el resultado de una consulta en un orden determinado, por

omisión 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 alfabético todos los clientes que tienen un préstamo en la sucursal de Piura.


FROM préstamo

WHERE nomsuc = “Piura”

ORDER BY nomcli

Ejemplo: Listar todos los datos de un préstamo ordenados desde la cantidad más pequeña y por número de

préstamo.

SELECT *

FROM préstamo

ORDER BY cantidad DESC,

numprest ASC

FUNCIONES DE AGREGACION

SQL ofrece la posibilidad de calcular funciones en grupos de tuplas usando la cláusula GROUP BY .El atributo

o atributos dados en la cláusula GROUP BY se usan para formar grupos. Las tuplas con el mismo valor se

colocan en un grupo.

Las funciones para calcular:

Promedio : AVG

Mínimo : MIN

Máximo : MAX

Total : SUM

Contar : COUNT

Ejemplo: Encontrar el saldo promedio de las cuentas de todas las sucursales.

SELECT nomsuc , AVG ( saldo)

FROM depósito

GROUP BY nomsuc

RECORDAR: SI SE QUIERE ELIMINAR DUPLICADOS USAR DISTINCT

Ejemplo: Encontrar el número de clientes con depósito para cada sucursal.

SELECT nomsuc , COUNT ( DISTINCT nomcli)

FROM depósito

GROUP BY nomsuc

Si se desea declarar una condición que se aplica a los grupos más que a las tuplas ,usaremos la cláusula

HAVING de SQL.

Ejemplo: Saldo promedio de las sucursales mayor que 1 200.

SELECT nomsuc , AVG ( saldo)

FROM depósito

GROUP BY nomsuc

HAVING AVG ( saldo ) > 1 200

Las funciones de Agregación 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 depósito

GROUP BY nomsuc

HAVING AVG ( saldo ) ALL (SELECT AVG ( saldo)

FROM depósito

GROUP BY nomsuc)

Cuando deseamos tratar la relación completa como un grupo único, no se usa la cláusula GROUP BY.

Ejemplo: Encontar el saldo promedio en todas las cuentas.

SELECT AVG ( saldo)

FROM depósito

La función Agregación COUNT se usa frecuentemente para contar el número de tuplas de una relación.

Ejemplo: Encontar el saldo promedio de todos los clientes con depósito ,que viven en Sullana y tienen por lo

menos tres cuentas.

SELECT AVG ( saldo)

FROM depósito , cliente

WHERE depósito. nomcli = cliente. nomcli AND

ciudad = “Sullana”

GROUP BY depósito. 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 retención de duplicados; pero puesto que ALL está implícito no es necesario.

MODIFICACIÓN DE LA BDD

ELIMINACIÓN.- En SQL una supresión se expresa por medio de:

DELETE r r = relación

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 relación.

Ejemplo: Suprimir todas las tuplas de la relación préstamo.

DELETE préstamo

Ejemplo: Suprimir todos los registros del cliente Pérez.

DELETE depósito

WHERE nomcli = “Pérez”

Ejemplo: Suprimir todos los préstamos cuyo número de préstamo esté entre 1300 y 1500.

DELETE préstamo

WHERE numpres BETWEEN 1300 AND 1500

Ejemplo: Suprimir todas las cuentas en la sucursal de Piura.

DELETE depósito

WHERE nomsuc IN ( SELECT nomsuc

FROM sucursal

WHERE ciudad = “Piura”)

Base de Datos I


INSERCIÓN.- Los valores de atributos para tuplas insertadas deben ser miembros del dominio de los atributos,

y las tuplas insertadas deben tener el número correcto de atributos.

INSERT INTO depósito

VALUES ( “Sullana” , 9825 , “García” , 1 200)

Los atributos se especifican en orden de esquema de la relación.

INSERT INTO depósito ( nomsuc , numcta , nomcli , saldo )

VALUES ( “Sullana” , 9825 , “García” , 1 200)

Ejemplo: Queremos proporcionar a todos los clientes con préstamo en la sucursal de Paita una cuenta de ahorros

con S/. 200,Y su número de préstamo será igual al número de su cuenta de ahorros.


SELECT nomsuc , numpres , nomcli , 200

FROM préstamo


ACTUALIZACIÓN.- 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 interés.

UPDATE depósito

SET saldo = saldo * 1.05

Ejemplo: Para cuentas con saldos mayores a 10 000 incrementar e interés en 6 % y para las menores las cuentas

menores que 10 000 el interés es de 5 %.

UPDATE depósito


WHERE saldo > 10 000

UPDATE depósito


WHERE saldo 10 000

En el caso de INSERT, DELETE, UPDATE cualquier SELECT incorporado en la cláusula WHERE no debe

hacer referencia a la relación que se está usando.

UPDATE depósito


WHERE saldo > (SELECT AVG ( saldo)

FROM depósito )

VALORES NULOS

Usaremos la sentencia NULL


VALUES ( “Sullana” , NULL , “García” , 1 200)

Todas las comparaciones que implica NULL son falsas por definición; sin embargo la palabra clave especial

NULL puede usarcé en un predicado para probar si hay un valor nulo.


FROM depósito

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 AS <expresión de consulta>

= nombre de la vista.

<Expresión de consulta > = cualquier expresión 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 depósito)

UNION

( SELECT nomsuc , nomcli

FROM préstamo)

Dado que cada vista se considera como un archivo podría después usarse:

SELECT nomcli

FROM Todos_clientes


DEFINICIÓN DE DATOS

Una relación de SQL se define usando la orden:

CREATE TABLE r ( A1D1, A2D2, ... , AnDn )

r = Nombre de la relación.

A = Nombre de un atributo del esquema de la relación r. D = Es el tipo de datos de los valores en el dominio del atributo A. Ejemplo CHR (30) , Integer , Real ,

NOT NULL.

La relación recién creada está vacía. La orden INSERT puede usarcé para cargar los datos.

Para eliminar una relación de la BDD en SQL usaremos:

DROP TABLE r

Para añadir atributos en una relación 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 también 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 afirmación 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

afirmación.

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

especiales.

Ejemplo:

La suma de todas las cantidades de préstamos para cada sucursal debe ser menos que la suma de todos los saldos

de cuenta de la sucursal.

Cuando se hace una afirmación, el sistema prueba su validez. Si la afirmación es válida, entonces cualquier

modificación en la BDD está permitida solo si no provoca que se viole la afirmación.

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

ASSERT < nombre_afirmación > ON < nombre_relación > : < predicado>

Ningún saldo negativo (Restricción de integridad)

ASSERT límite.saldo ON depósito : saldo >= 0

(Restricción de dominio)

Ningún empleado del banco puede ser su propio banquero personal

ASSERT límite_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 adición de una cuenta (depósitos) a menos que el nombre del cliente aparezca en la relación cliente

(Restricción de Integridad Referencial)

ASSERT límite_dirección ON INSERTION TO depósito :

EXISTS ( SELECT *

FROM Cliente

WHERE Cliente. nomcli = Depósito.nomcli)

La forma más general de afirmación es:

ASSERT <nombre_afirmación > : <predicado>

Es cualquier clausula en SQL.

DISPARADORES (TRIGGER)

El disparador es una sentencia que el sistema ejecuta automáticamente como un efecto secundario de una

modificación de la BDD. Para diseñar 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 préstamo en la cantidad de saldo deudor.

Base de Datos I


Insertar una nueva tupla S en la relación préstamo 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 están incluidos en el SQL estándar

DEFINE TRIGGER saldodeudor

ON UPDATE OF deposito T

( IF NEW T.saldo < 0

THEN ( INSERT INTO préstamo 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 pérdida de consistencia de los datos.

Las Restricciones de Integridad protegen la BDD contra daños accidentales.

Las Restricciones de Integridad para el modelo E-R están en forma de:

Declaración de claves.

Forma de una relación (M a M, 1 a M, 1 a 1).

RESTRICCIONES DE DOMINIO

Los límites de dominio son la forma más elemental de restricciones de integridad.

Tipos de Dominio: Una definición adecuada de tipos de dominio no solo nos permite probar valores insertados

en la BDD, sino que también nos permite probar consultas para asegurar que la comparación 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.

Número en coma fija, con precisión especificada por el usuario.

Entero (dependiente de la máquina).

Entero pequeño (dependiente de la máquina).

Número en coma flotante y en coma flotante de doble precisión, con precisión dependiente de la máquina.

Fecha.

La transformación de tipo de dominio se denomina “Coacción de Tipo” (Convertir de entero pequeño a

entero.)

Para SQL Estándar, nombre.sucursal y nombre.cliente aunque tengan dominio de cadena de caracteres de

longitud diferente, SQL considera los dos dominios compatibles.

Valores Nulos: SQL estándar permite que la declaración del dominio de un atributo incluya la especificación

“NOT NULL “. Esto prohíbe la inserción de un valor nulo para este atributo.

Cualquier modificación en este caso genera un diagnóstico de error.

Hay muchas situaciones en las que la prohibición de valores nulos es deseable. Así: Cuando el atributo es

una clave primaria de un esquema de relación.

INTEGRIDAD REFERENCIAL

A menudo queremos asegurar que un valor que aparece en una relación para un conjunto de atributos dados

también aparece para un conjunto de atributos en otra relación.

Conceptos Básicos: Considérese 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 relación que es una clave primaria de otra relación 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 restricción de Integridad referencial.

Otra fuente de Integridad Referencial es el conjunto de entidades débiles. El Esquema de Relaciones para cada

conjunto de Entidades débiles incluye una clave exterior que conduce a una restricción de Integridad

Referencial.

Modificación de la BDD: La modificación de la BDD puede causar violaciones de integridad Referencial.

Πα( r2) Πk ( r1 )

Insertar: Si una tupla t2 se inserta en una relación 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á vacío, 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 relación que hace la referencia (r2) ó actualizar en la relación referenciada (r1)

Si se actualiza una tupla t2 en la relación 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 relación 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 característica de “Intensificación de Integridad” ha sido aprobada como un

añadido al estándar. Esta característica permite la especificación de claves primarias, candidatas y claves

exteriores como parte de al sentencia CREATE TABLE:

La cláusula "Primary Key" incluye una lista de atributos que comprenden la clave primaria.

La cláusula "Unique Key" incluye una lista de atributos que comprenden la clave candidata.

La cláusula "Foreign Key" incluye una lista de atributos que comprenden la clave exterior y el

nombre de la relación 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 depósito

( 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 restricción 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 sólo por las

relaciones que satisfagan un conjunto dado de dependencias funcionales.

Si queremos limitarnos a la relación del esquema R que satisfacen F, decimos que F se cumple en R.

2. Para probar si una relación es legal bajo un conjunto dado de dependencias funcionales. Si una relación r es

legal bajo un conjunto F de dependencias funcionales, decimos que r satisface a F.

Relación 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 relación 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 Vásquez Av. Grau 123 Piura

Jannette Luna Av. Las Palmeras 231 Talara

Katia Vásquez 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 préstamo.

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 Vásquez Piura

T1 15 Marco Valencia Sullana

S1 23 Jannette Luna Talara

P2 18 Katia Vásquez Piura

numprest catidad Queremos exigir que la relación préstamo satisfaga esta dependencia en todo

momento. Imponemos la restricción de que se cumpla numprest cantidad

en el esquema préstamo.

Al diseñar 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 Préstamo

numprest cantidad

numprset nombre_sucursal

CIERRE DE UN CONJUNTO DE DEPENDENCIAS FUNCIONALES

No es suficiente considerar un conjunto dado de Dependencias Funcionales. Además, 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 lógicamente. Es decir podemos demostrar que se cumpla el

conjunto dado de Dependencias Funcionales, A H también 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 lógicamente.

Existen técnicas para deducir Dependencias Funcionales:

La primera técnica 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 ( ...) representan conjunto de atributos

Letras romanas en mayúsculas representan atributos individuales

Axiomas de Armstromg.-

Reglas de Flexibilidad.- Si es un conjunto de atributos y entonces se cumple .

Regla de Aumento.- Si se cumple es un conjunto de atributos, entonces se cumple .

Regla de Transitividad.- Si se cumple y se cumple , entonces se cumple

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 Unión.- Si se cumple y se cumple , entonces se cumple

Regla de Descomposición.- Si se cumple , entonces se cumple y

Regla de Pseudotransitividad.- Si se cumple y , entonces se cumple

A continuación 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 Unión 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 número de Dependencias Funcionales que necesitan ser probadas en caso de una

actualización, restringimos un conjunto dado F de Dependencias Funcionales a un recubrimiento canónico Fc.

Fc debe tener las siguientes características:

a) Cada una de las Dependencias Funcionales en Fc no contienen atributos extraños a . Los

atributos extraños son atributos que pueden eliminarse de sin cambiar Fc+. Así A es extraño a si

A y Fc implica lógicamente a ( Fc .

b) Cada una de las Dependencias Funcionales en Fc no contienen atributos extraños a .

Así A es extraño a si A y ( Fc implica lógicamente a Fc.

c) Cada lado izquierdo de una Dependencia Funcional en Fc es único ( No existen dos dependencias

y en Fc, tales que )

Base de Datos I


Para calcular un recubrimiento canónico para F, utilizo la Regla de Unión para sustituir cualquier dependencia en

F ( y

Pruébese cada dependencia funcionalpara ver si hay un atributo extraño a 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 extraño 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


DISEÑO DE BASES DE DATOS RELACIONALES

El objetivo del diseño de una base de datos relacional es generar un conjunto de esquemas de relaciones que nos

permiten almacenar información sin redundancia innecesaria, pero que a la vez nos permitan recuperar

información fácilmente.

PELIGROS EN EL DISEÑO DE BDD RELACIONALES

Entre las propiedades indeseables que un mal diseño pueda tener están:

Repetición de Información

Incapacidad para representar cierta información.

Pérdida de información

REPRESENTACIÓN DE LA INFORMACIÓN:

Diseño Original

(1) Esquema_sucursal = ( nomsuc, activo, ciudad_suc)

Esquema_prestamo = ( nomsuc, numprest, nomcli, cantidad )

Diseño Alternativo

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

La repetición de información que requiere el uso del diseño alternativo no es conveniente. La repetición de

información desperdicia espacio. Además, complica la actualización de la base de datos.

Ejemplo:

a) Añadir un nuevo préstamo en 1 y en 2

b) Actualizar la ciudad de una sucursal

¿Por qué es malo el diseño 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 préstamos son

procesos independientes. Estos hechos se representan mejor en relaciones separadas.

b) No podemos representar directamente la información referente a una sucursal (nomsuc, activo, ciudad_suc) a

menos que exista por lo menos un préstamo en la sucursal (deben tener valores de numprest, cantidad y nomcli).

Peor aún tendríamos que suprimir esta información cuando se hubieran pagado todos los préstamos.

PÉRDIDA DE INFORMACIÓN

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 descomposición se hace sin cuidado puede llegarse a

otra forma de diseño defectuoso.

Ejemplo:

El esquema préstamo se descompone en:

Esquema_cantidad = (cantidad, nomcli)

Esquema_prestamo = (nomsuc, numprest, cantidad)

Queremos encontrar aquellas sucursales de las que Juan tiene un préstamo, ninguna de las relaciones de la Base

de Datos alternativa contiene estos datos. Podemos hacerlo escribiendo cantidad |x| préstamo.

Base de Datos I


Si sucede que varios préstamos tienen la misma cantidad, no podemos decir a qué cliente corresponde cada

préstamo. Ya no somos capaces de representar en la Base de Datos, que clientes tienen prestamos de qué

sucursal.

Debido a esta pérdida de información, a esta descomposición la llamaremos Descomposición con pérdida o

descomposición de producto con pérdida.

Debe estar claro, que una descomposición de productos con pérdida es un mal diseño 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 descomposición de producto sin pérdida, necesitamos imponer ciertas restricciones en el conjunto

de las relaciones posibles. Una de estas restricciones son las dependencias funcionales.

Ejemplo:

* R = Esquema_prestar r : relación prestar

R1= Esquema_cantidad r1 : relación cantidad r r1 |x| r2 Hay pérdida de la información

R2= Esquema_prestamo r2 : relación préstamo

* Esquema_prestar = Esquema_prestamo |x| Esquema_sucursal Sin pérdida 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 diseños buenos

de Base de Datos. Existe un gran número 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

Descomposición De Producto Sin Pérdida

El criterio para determinar si una descomposición sea sin pérdida: Sea R un esquema de relaciones y F es un

conjunto de Dependencias Funcionales en R. R1 y R2 forman una descomposición de R.

Esto es una descomposición de producto sin pérdida 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

Conservación de las Dependencias

Cuando se hace una actualización de la Base de Datos, el sistema debe poder comprobar que la actualización no

creará una relación ilegal - es decir, una que no satisfaga todas las dependencias funcionales dadas.

Para comprobar las actualizaciones eficientemente es conveniente diseñar esquemas de Base de Datos

relacionales que permitan validar una actualización sin calcular los productos.

Ejemplo:

Podemos demostrar que la descomposición 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 relación de la

descomposición.

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

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

Repetición De Información

La descomposición de Esquema_prestar no padece del problema de la repetición de información.

Ejemplo:

Esquema_Prestar repetía la ciudad y el activo de la sucursal para cada préstamo. La descomposición repara

los datos de sucursal y de préstamo en relaciones distintas, eliminando esta redundancia.

Si se hace un solo préstamo a varios clientes, debemos repetir la cantidad del préstamo una vez por cada

cliente (así como la cantidad y el activo de la sucursal). En la descomposición, la relación del esquema del

Esquema_prestamo_cliente contiene la relación numprest, nomcli, cosa que no sucede en las demás

esquemas. En el Esquema_info_prestamo, solo se necesita que aparezca una tupla por préstamo.

Claramente, la falta de redundancia que presenta la descomposición es deseable. Las distintas formas normales

representan los grados de eliminación de redundancia que pueden lograrse.

Base de Datos I


FORMA NORMAL DE BOYCE-CODD

Una de las formas normales más deseables que podemos obtener es la BCNF. Un esquema de la relación R está

en BCNF con respecto a un conjunto F de Dependencias Funcionales, si para todas las Dependencias

Funcionales en F+ de la forma , donde R y R, por lo menos se cumple una de las siguientes

condiciones :

es una dependencia funcional trivial (Es decir )

es una superclave del esquema R.

Un diseño de la Base de Datos está en BCNF si cada uno de los miembros del conjunto de los esquemas de

relaciones que comprende el diseño está en BCNF.

Ejemplo :

Esquema_sucursal = ( nomsuc, activo, ciudad_suc)


Esquema_cliente = ( nomcli, calle, ciudadcliente)

nomcli calle, ciudadcliente

Esquema_depósito = ( 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 préstamo no está en BCNF:

1. numprest no es una superclave del esquema préstamo (por haber préstamos de dos o más personas,

mancomunadas). Este esquema está en una forma no deseable, ya que padece del problema de repetición de

información.

Tenemos como punto de partida los esquemas que no están en BCNF y los descomponemos en:

Esquema_info_prestamo = ( nomsuc, numprest, cantidad )

Esquema_prestamo_cliente = ( nomcli, numprest )

a) Esto es una descomposición de productos sin pérdida.

b) Hay que determinar que Dependencias Funcionales les son aplicables:

numprest cantidad, nomsuc (Esquema_info_préstamo)

c) numprest es una clave candidata de Esquema_info_préstamo

d) En el Esquema_préstamo_cliente sólo se aplican dependencias funcionales triviales.

Entonces los dos esquemas están en BCNF.

Esquema depósitos 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 descomposición de producto sin pérdida, que conserven las dependencias y que estén en BCNF.

Siempre hay que satisfacer los tres objetivos del diseño.

BCNF

Producto sin pérdida

Conservación 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 sólo nombre_banquero nomsuc (y las dependencias triviales).

El cierre de { nombre_banquero nomsuc } no incluye nomcli, nomsuc nombre_banquero . La violación

de esta dependencia no puede detectarse a menos que se calcule un producto.

Toda descomposición BCNF de esquema banquero debe fallar a la conservación de

nomcli, nomsuc nombre_banquero.

TERCERA FORMA NORMAL

En aquellos casos en los que no pueden satisfacerse los tres criterios de diseño, abandonamos BCNF y

aceptamos una forma normal más débil, llamada 3NF. (Siempre se puede conseguir llegar a esta 3NF)

BCNF requiere que todas las Dependencias Funcionales no triviales sean de la forma donde 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 , donde R y R, por lo menos se cumple una de

las condiciones siguientes:

es una Dependencias Funcionales trivial.

es una superclave de R.

Cada atributo A en - está contenido en una clave candidata en R.

- BCNF no acepta el 3er criterio. Dependencias Transitivas.

- Todo esquema BCNF está también en 3NF.

- BCNF es más 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 definición 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

Descomposición sin pérdida.

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 descomposición.

COMPARACION DE BCNF Y 3NF

La 3NF tiene la ventaja de que sabemos que siempre es posible obtener un diseño 3NF sin sacrificar un producto

sin pérdida o la conservación de las dependencias.

No obstante, 3NF tiene una desventaja, sino eliminamos las Dependencias Funcionales transitivas, puede ser

necesario utilizar valores vacíos para representar alguna de las posibles relaciones significativas entre los datos,

y esta el problema de la repetición de información.

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 repetición de información. (nomcli nomsuc .)

Si nos vemos obligados a elegir entre BCNF y la conservación de las dependencias con 3NF, generalmente es

preferible optar por 3NF.

Si no podemos probar la conservación 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 conservación de las dependencias y

sacrificios BCNF.

Resumen:

El objeto de un diseño de Base de Datos relacional es:

BCNF

Producto sin pérdida

Conservación de las dependencias.

si no se puede lograr esto, aceptamos :

3NF

Producto si pérdida

Conservación de las dependencias.

Base de Datos I


Ejemplo:

Órdenes de compra del catálogo de clientes de diferentes ciudades

Codcli nomcli ciudad

precio de

entrega

precio

unidad

No de

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)

Están en 3FN y BCNF

Ejemplo:

Relación Proyecto-PC-Programador

#proyecto PC Programador

P01 IBM Renzo

P01 APPLE Aurelia

P15 ATARI Herbert

P23 IBM Renzo

P30 IBM Javier

Siguientes reglas Semánticas:

1. Para cada proyecto, una PC dada es usada por un sólo programador aún cuando el programador trabaje en más

proyectos.

2. Un proyecto puede usar distintos tipos de PC

3. Un programador se especializa sólo 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 normalización termina cuando todas las relaciones divididas pertenecen a la tercera

forma normal. Sin embargo si una relación contiene dependencias de valores múltiples, es necesaria una

normalización posterior.

B A

El atributo A de esta relación 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

Relación 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 métodos.

1) Crear una nueva relación para cada atributo DMV

relación Talla = ( #inventario, talla )

relación Color = ( #inventario, color ) 4FN

relación Precio = ( #inventario, precio)

2) Reemplazar un atributo DMV con atributos funcionalmente dependientes.

Relación Talla = ( #inventario, talla )

Relación Inventario = (#inventario, precio, color1, color2, color3) 4FN

I1 2 Azul Rojo ---

I2 4 Rojo Verde Blanco

Una relación está en 4FN, si está en BCNF y no contiene DMV (no triviales)

Base de Datos I


Ejemplo : Relación 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


NORMALIZACIÓN

Primera forma normal (1FN):

Una relación esta en 1FN.-

Si y solo si todos los dominios simples subyacentes contienen valores atómicos ó

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 relación 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 ningún atributo no clave en la relación es funcionalmente dependiente de algún otro

atributo no clave.

Ejemplo:

R = ( CodCli, ciudad, situación, CodPro, cantidad)

DF: CodCli, CodPro cantidad

CodCli ciudad, situación

Ciudad situación

1FN: R1 = ( CodCli, CodPro, cantidad )

R2 = ( CodCli, ciudad, situación )

2FN: R1 y R2 cumplen la condición

3FN: R1 = ( CodCli, CodPro, cantidad )

R21 = ( CodCli, ciudad )

R22 = ( ciudad, situación )

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 condición

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 relación 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 común)

La combinación de las condiciones se presenta muy raras veces. Si se presenta, las tablas están en 3FN.

Un determinante es un atributo del cual depende funcionalmente algún otro atributo.

a) Dos claves candidatas sin atributos comunes

R = ( CodCli, nombre, situación, ciudad )

Determinantes: {CodCli} y {nombre}

Claves candidatas: {CodCli} o {nombre}

DF: CodCli nombre, situación, ciudad o nombre CodCli, situación, ciudad

R esta en BCNF

Base de Datos I


MOTORES DE PERSISTENCIA

Es generalmente sabido que una aplicación informática 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 información necesaria

para operar la aplicación, 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 cálculos 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 años la evolución de estos dos

componentes ha sido divergente, de forma que cada vez se ha hecho más difícil que

colaboren en una misma aplicación.

Así, desde los años 70 a la actualidad, las bases de datos utilizan un modelo teórico llamado “relacional”, que se

ha convertido en un estándar y que es utilizado en la práctica totalidad de aplicaciones de software.

En cambio, los programas han usado, desde los años 80, un modelo llamado “orientado a objetos”, que difiere en

mucho del modelo relacional y que se ha extendido cada vez más. Es por ello que aparece un conflicto a la hora

de reunir estos dos componentes en una aplicación, ya que cada uno responde a diferente modelo y forma de

operar. Cada componente maneja los datos con un formato diferente. Metafóricamente, podríamos afirmar que el

programa y la base de datos hablan idiomas diferentes y, por lo tanto, la comunicación entre ellos resulta difícil.

Este artículo comienza con una descripción de los dos modelos mencionados y de las diferencias que dificultan

su combinación en una sola aplicación. A continuación, 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 artículo finaliza

indicando los nombres de los motores de persistencia más usados, con el fin de que el lector pueda elegir el que

más se adapta a sus necesidades.

MODELO ORIENTADO A OBJETOS El modelo orientado a objetos es el modelo teórico que usa la mayoría de los programas actuales. La

programación orientada a objetos hunde sus raíces en los años sesenta (en los que aparecieron los primeros

lenguajes de este tipo, llamados “Simula I” y “Simula 67”, desarrollados en el Centro Noruego de Computación,

en Oslo). En los primeros 70, aparece “Smalltalk”, un lenguaje fundamental en la historia de la orientación a

objetos.

Sin embargo, no es hasta la segunda mitad de los años 80 cuando la orientación de objetos se generaliza,

convirtiéndose en el estándar predominante en los años 90, de la mano de lenguajes como C++ y Java. El triunfo

de la programación orientada a objetos ha sido impulsado por la enorme difusión de otras tecnologías (como la

interfaz gráfica o las arquitecturas distribuidas) que son más fáciles de implementar mediante este tipo de

desarrollo que mediante una programación tradicional.

Hoy en día, la práctica totalidad de los lenguajes de programación que surgen son orientados a objetos y esta

tecnología se ha convertido en el estándar actual de programación que, a su vez, está generando nuevos

desarrollos muy prometedores para el futuro (como, por ejemplo, la programación orientada a aspectos).

La idea de la orientación a objetos es modelar los programas de una forma parecida a cómo percibimos la

realidad. Para la mente humana, el universo está compuesto por una serie de “objetos” (en el sentido más amplio

de la palabra, incluyendo seres vivos, ideas, etc.). Cada objeto tiene unas características que lo diferencian de los

demás y, con cada objeto, se pueden realizar unas acciones que son propias y específicas del mismo.

Así, por ejemplo, un determinado auto tiene unas características (color rojo, caja de cambios automática, diesel,

etc.) y puede realizar unas determinadas acciones (acelerar, frenar, etc.).

La programación 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 características (llamadas “atributos”) y una serie de acciones (llamadas “métodos”), al igual que un

objeto de la vida real. Una representación gráfica 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. Análogamente, 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 estática de un

objeto (los “atributos” del mismo, es decir, sus características) como su parte dinámica (los “métodos”, es decir,

sus acciones). Usando una terminología bien conocida en desarrollo, incluye tanto los “datos” como los

“procesos”.

En resumen, la programación 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 más enormes al

dividirlos en partes más pequeñas, es decir, en objetos. Como consecuencia, produce reducciones de costos y

mayor calidad del código y se ha convertido en el estándar actual de programación.

MODELO RELACIONAL Muy ajeno a la revolución que supuso la orientación 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 artículo publicado por E.F.Codd en 1970. Las primeras bases de datos

relacionales comerciales aparecen en la segunda mitad de los años setenta. Desde entonces, el modelo relacional

se convierte en un estándar prácticamente 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 sólo se

ocupa de la parte estática de la aplicación (de los “datos”) y no de la parte dinámica (“los procesos”). Usando el

ejemplo anterior, en el modelo relacional, sólo me interesan las características 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

lógico en un modelo cuyo objetivo es modelar la parte estática de la aplicación, 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 sólo modela datos y

que éstos no tienen estructura. La representación gráfica 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 impresión que hay en las empresas (de empleados, de facturas, etc.). En esta comparación, cada

registro sería una línea del listado.

Base de Datos I


Usando el ejemplo anterior, cada registro contendría los datos de un determinado auto (color rojo, caja de

cambios automática, diesel, etc.) y las tablas no serían más 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 están por separado (esto se muestra en la figura 5) y se relacionan por un mecanismo implícito

llamado “clave foránea”. El programador debe saber que hay una relación entre los autos y las piezas y debe

programar de acuerdo a ello. Sin embargo, el modelo no refleja explícitamente esta relación y, en general, la

estructura de la realidad, al contrario del modelo orientado a objetos.

APLICACIONES TRADICIONALES Como conclusión de lo que se ha dicho hasta ahora, una aplicación está formada por un programa y una base de

datos que se comunican entre sí. El programa suele estar diseñado según el modelo orientado a objetos y, por lo

tanto, trabaja con datos en formato de objetos. Por el contrario, la base de datos está diseñada según 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á diseñada 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 aplicación hablan “idiomas diferentes”

y, por lo tanto, debemos encontrar una solución para que se comuniquen.

La solución más 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 opción que examinamos en este artículo es

la de que el programa esté diseñado para tratar con datos relacionales, la cual se refleja en la figura 7. En esta

opción, 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 comunicación es posible.

Base de Datos I


Ésta era la forma de programar universalmente adoptada antes de la aparición de la orientación a objetos y sigue

siendo la arquitectura dominante en El Salvador. Aún entre las empresas que utilizan lenguajes orientados a

objetos, la mayoría programa sin tener en cuenta la orientación 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 gestión de sistemas complejos que da la programación orientada a objetos.

Asimismo, el código que opera con datos relacionales suele ser complejo, difícil 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 opción

consistente en que toda la aplicación use un mismo

modelo teórico relacional no es la más adecuada.

Examinemos ahora la opción en que toda la aplicación

tenga un único modelo teórico, pero que éste sea el de

orientación a objetos. Esta opción, que se refleja en la

figura 8, implica que el formato de datos que usa toda la

aplicación 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 homólogas relacionales,

que trabajan con registros, las bases de datos orientadas a objetos guardan y recuperan objetos. Por lo tanto, la

comunicación de este tipo de base de datos con un programa orientado a objetos es posible.

Aunque, sobre el papel, ésta es la mejor opción para implementar una aplicación de base de datos, en la práctica

presenta una serie de problemas importantes, debido a las características actuales de las bases de datos orientadas

a objetos. Éstas no están tan maduras como sus homólogas relacionales y, por lo tanto, no gozan de la

abundancia de herramientas, la fiabilidad, facilidad de administración 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 aplicación desde una base de datos orientada a objetos a otra, lo que nos obliga a depender

de un único proveedor (fenómeno conocido como “vendor lock-in”), con todas las inconveniencias que esto

supone (obligación de aceptar los aumentos de precio del proveedor, falta de soporte si el proveedor sale del

mercado, etc.).

Como conclusión, aunque ésta pueda ser la opción preferible en un futuro, en el que las bases de datos orientadas

a objetos alcancen una madurez y estandarización suficientes, en el presente resulta arriesgado aplicarla.

MOTORES DE PERSISTENCIA Hemos visto que las opciones que se basan en imponer un único modelo teórico (un único formato de datos) a

toda la aplicación padecen de graves inconvenientes. En el caso de que toda la aplicación siga el modelo

relacional, perdemos las ventajas de la orientación a objetos. En el caso de que toda la aplicación siga el modelo

orientado a objetos, tenemos que las bases de datos que debemos usar están inmaduras y tienen un bajo nivel de

estandarización.

Examinemos ahora la opción de que el programa sea orientado a objetos y la base de datos sea relacional, lo que,

en principio, constituye la opción más natural. Sin embargo, plantea el problema de cómo hacemos que dos

Base de Datos I


componentes con formatos de datos muy diferentes puedan comunicarse y trabajar conjuntamente. Siguiendo la

metáfora anterior, se trata de hacer que dos personas que hablan idiomas diferentes se comprendan.

La solución es la misma que se daría en la vida real. Se debe encontrar un traductor que sepa traducir de cada

idioma al otro. De esta forma, las dos personas se entenderán sin necesidad de que uno hable el idioma del otro.

En el mundo de la programación este traductor no es más que un componente de software (concretamente, una

capa de programación), 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 situación 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 sólo ve que puede guardar objetos y recuperar objetos, como si estuviera programado para una base

de datos orientada a objetos. La base de datos sólo ve que guarda registros y recupera registros, como si el

programa estuviera dirigiéndose a ella de forma relacional. Es decir, cada uno de los dos componentes trabaja

con el formato de datos (el “idioma”) que le resulta más natural y es el motor de persistencia el que actúa de

traductor entre los dos modelos, permitiendo que los dos componentes se comuniquen y trabajen conjuntamente.

Esta solución goza de las mejores ventajas de los dos modelos.

Por una parte, podemos programar con orientación a objetos, aprovechando las ventajas de flexibilidad,

mantenimiento y reusabilidad.

Por otra parte, podemos usar una base de datos relacional, aprovechándonos de su madurez y su

estandarización así como de las herramientas relacionales que hay para ella.

Se calcula que un motor de persistencia puede reducir el código de una aplicación en un 40%, haciéndola menos

costosa de desarrollar. Además, el código que se obtiene programando de esta manera es más limpio y sencillo y,

por lo tanto, más fácil de mantener y más robusto. Por añadidura, el motor de persistencia no sólo simplifica la

programación, sino que permite hacer ciertas optimizaciones de rendimiento que serían difíciles de programar

por nosotros mismos.

Como conclusión, ésta es la mejor opción en la actualidad para implementar una aplicación 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 sólo debe

programarse una vez y puede usarse para todas las aplicaciones que se desarrollen en nuestra empresa. Sin

embargo, un motor de persistencia es difícil 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 más recomendable, por la

complejidad y costo que introduce esta opción.

Utilizar un motor que ya esté programado, comprándolo a un vendedor o bien usando un motor gratuito

de código abierto.

Base de Datos I


Se recomienda fuertemente la segunda opción, que es la menos costosa y la menos propensa a fallos. Se debe

escoger un motor de persistencia de los que están programados, estudiarlo y aplicarlo a todas las aplicaciones de

una misma empresa. A continuación, explicamos algunos de los motores de persistencia más importantes para la

plataforma Java y para la plataforma .NET, con el fin de que el lector pueda comenzar una investigación que le

lleve a escoger el que más se ajuste a sus necesidades.

En cuanto a la plataforma Java, los servidores de aplicaciones basados en la especificación EJB (“Enterprise

JavaBeans”), incorporan un motor de persistencia a través del mecanismo conocido como “entity beans”. Sin

embargo, los “entity beans” no son un mecanismo de persistencia totalmente recomendable, pues no permiten

implementar algunas características de la programación orientada a objetos (por ejemplo, herencia) y además,

obligan a una forma de programar diferente a los objetos normales de Java (o POJOs, por “Plain Old Java

Objects”).

Hay motores de persistencia más completos que no tienen este tipo de inconvenientes que se acaba de

mencionar. Entre los de código abierto podemos destacar: Hibernate, Castor, Torque, OJB y Cayenne. Entre los

comerciales, podemos destacar TopLink, Cocobase y FastObjects. En los últimos años se ha creado una

especificación llamada JDO, para estandarizar la forma de programar en Java con esos motores de persistencia.

Ejemplos de motores de persistencia que cumplen el estándar JDO son Kodo, JDO Genie, LiDo, Exadel JDO,

IntelliBO, JRelay JDO (todos ellos comerciales), TJDO y XORM (de código abierto).

La plataforma .NET, por su relativa novedad, está más inmadura que la plataforma Java. Además, al ser una

plataforma propietaria, cuesta más encontrar proyectos de código 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.

http://hibernate.bluemars.net/

http://castor.exolab.org/

http://db.apache.org/torque/

http://db.apache.org/ojb

http://www.objectstyle.org/cayenne

http://otn.oracle.com/products/ias/toplink/content.html

http://www.thoughtinc.com/cber_index.html

http://www.fastobjects.com/eu

http://www.solarmetric.com/

http://www.hemtech.co.za/jdo/index.html

http://www.libelis.com/

http://www.exadel.com/products_jdoproducts.htm

http://www.signsoft.com/en/intellibo/index.jsp

http://www.objectindustries.com/crm/home/index.do

http://tjdo.sourceforge.net/

http://xorm.org/

http://www.olero.com/

Base de Datos I

Documents

Transcript of Base de Datos I