I.

Conceptos Básicos de las Bases de Datos

DATO

Dato es una colección de hechos considerados de forma aislada. Los datos pueden ser números, palabras, imagenes. Son el nivel más bajo de abstracción a partir del cual se deriva la información. Información es un dato que ha sido manipulado, con lo que resulta de utilidad para alguien.

CALIDAD DE LA INFORMACIÓN

La calidad de la información se basa en los atributos claves: • Exactitud. Significa que es clara y refleja adecuadamente el sentido de los datos en los que se basa. • Oportunidad. Implica hacerla llegar dentro del marco del tiempo necesario. Que se pueda obtener cuando se necesita.
• Relevancia. Debe responder de manera

específica a lo que busque: qué, dónde, cuándo, quién, cómo…

BASE DE DATOS

Una base de datos es un conjunto de datos que pertenecen al mismo contexto y son almacenados sistemáticamente para su uso posterior. Son datos interrelacionados que modelan una realidad La base de datos es el componente estructural clave en el diseño de sistemas de información. Es la principal fuerza de integración del sistema de información de una organización.

La base de datos se considera desde dos puntos de vista, el físico y el lógico:
• La base de datos física está compuesta de los medios de

almacenamiento, es la forma en que los datos se almacenan realmente.
• El lado lógico se refiere a la recuperación de los datos almacenados

para satisfacer necesidades específicas de información.

SISTEMA MANEJADOR DE BASE DE DATOS

Un sistema manejador de base de datos (SMBD) es un conjunto de programas especializados diseñados para describir, proteger, almacenar y accesar la base de datos. En un SMBD se pueden realizar las siguientes operaciones con los datos: definir, crear, organizar, relacionar, estructurar, acceder a datos, manejar, consultar.

FUNCIONES DE UN SMBD
• Definir todos los datos empleados en el sistema y

especificar las relaciones entre los datos.
• Proporcionar un método para dar de alta, dar de baja y

modificar los datos que están en la base de datos.
• Proteger el recurso de los datos de manera que sea

seguro, confiable, consistente y correcto.
• Permitir que los usuarios múltiples de la base de datos

compartan los datos.
• Permitir la recuperación de datos mediante un lenguaje

entendible a los usuarios del sistema.

Sistema Manejador de Base de Datos (SMBD)

Base de Datos

Programas de Aplicación

Usuarios Finales

HISTORIA

Principios • 50’s • 60’s • 70’s • 80’s • 90’s

Modelos • Sistemas manejadores de archivos • Bases de datos jerárquicas • Bases de datos de red • Bases de datos relacionales • Bases de datos OO

ARQUITECTURA DE TRES NIVELES
NIVEL FÍSICO (interno) Se describe la estructura física de la base de datos mediante un esquema interno. Este esquema se especifica mediante un modelo físico y describe todos los detalles para el almacenamiento de la base de datos, así como los métodos de acceso. Es el nivel más bajo de representación de la base de datos. NIVEL CONCEPTUAL (lógico) Es aquel en el que se definen las estructuras de almacenamiento y las relaciones que se darán entre ellas. Este esquema oculta los detalles de las estructuras de almacenamiento y se concentra en describir entidades, atributos, relaciones, operaciones de los usuarios y restricciones. NIVEL EXTERNO (externo - vistas) Puede definirse como la forma en que el usuario aprecia la información y sus relaciones. Cada esquema externo describe la parte de la base de datos que interesa a un grupo de usuarios determinado y oculta a ese grupo el resto de la base de datos.

OBJETIVOS DE UN SMBD
Independencia LÓGICA: Ocurre cuando se modifica el esquema conceptual sin afectar al resto de los esquemas. Básicamente se modifica el esquema conceptual cuando cambian las características de los datos a almacenar. Independencia FÍSICA: Se presenta cuando es posible la modificación del esquema físico sin afectar a los esquemas restantes. Las principales razones para llevar a cabo una modificación del esquema físico serán un ajuste en el hardware de almacenamiento o una redistribución de

Manipulación de los datos por personas no especializadas en computación: cualquier persona consulte y actualice los datos, por medio de lenguajes de programación no procedimentales. Eficacia en el acceso a los datos: permite el acceso eficaz sin que el que hace el acceso sea especialista o no en el área y que conozca o no la estructura interna de los datos. El tiempo de respuesta está íntimamente ligado al número de accesos a disco, lo que será soportado por el SMBD.

Administración centralizada de los datos: un grupo de trabajo que se dedique a la definición de las estructuras de almacenamiento y de los datos de la base siguiendo su evolución a través del tiempo. Redundancia de datos controlada: se busca la no duplicación física de los datos y de ser absolutamente necesario un cierto nivel de redundancia, éste debe estar estrictamente controlado por el SMBD.

Coherencia de los datos: el SMBD debe tener ciertas facilidades o útiles para hacer que los PA respeten las reglas de integridad de la Base de Datos, en particular aquellas correspondientes a la modificación de los datos. Posibilidad de compartir los datos: un PA puede usar los datos almacenados en la Base de Datos como lo desee y como si fuera el único en usarlo, sin saber que otro puede estar modificándolo concurrentemente. Seguridad de los datos: se debe permitir la protección contra accesos no autorizados o malintencionados.

MANEJO DE TRANSACCIONES: Recuperación vía reprocesamiento
• Realizar un respaldo de la base de datos. • Conservar un registro de todas las transacciones

que se hayan procesado a partir de dicho respaldo.
• Al presentarse una falla, el equipo de operaciones

puede restaurar la base de datos partiendo del respaldo y reprocesando todas las transacciones.

Recuperación vía progresiva • Consiste en recuperar la base de datos del respaldo y aplicar todas las transacciones válidas a partir del respaldo. Recuperación vía regresiva • Se deshacen los cambios efectuados por transacciones erróneas o procesadas de un modo parcial, deshaciendo las modificaciones que éstas hicieron en la base de datos. Concurrencia • Diferentes usuarios pueden manipular los datos al mismo tiempo y la integridad de los datos se conserva.

COMPONENTES DE UN SBD

1. Datos 2. Hardware 3. Software 4. Usuarios (Máquinas) (Programas) (Personas)

1. DATOS

Los sistemas de base de datos están disponibles en máquinas que van desde las computadoras personales más pequeñas hasta las mainframes más grandes. Los datos de la base de datos en un sistema grande, serán tanto “Integrados” como “Compartidos”.

2. HARDWARE

Sus componentes son: • Los volúmenes de almacenamiento secundario • Los procesadores de hardware y la memoria principal

3. SOFTWARE

Un SMBD es un conjunto de programas que controlan la creación, el mantenimiento y el uso de la base de datos. Componentes: Motor del SMBD: Recibe requerimientos lógicos de otros subsistemas del SMBDs, los convierte en su equivalente físico y accesa la base de datos Subsistema de Definición de Datos: Crea y mantiene el diccionario de datos y define la estructura de los archivos de la base de datos Subsistema de Manipulación de Datos: Agrega, cambia, elimina y consulta datos de una base de datos

3. SOFTWARE

Componentes (continuación...) Subsistema de Generación de Aplicaciones: Apoya al usuario a generar aplicaciones transaccionales Subsistema de Administración: Apoya al usuario en la administración de todo el ambiente de una base de datos (recuperación, seguridad, optimización, concurrencia, administración de cambios)

Sistema Manejador de Bases de Datos

4. USUARIOS

Usuarios sofisticados Interactúan con el sistema sin escribir programas. En cambio escriben sus preguntas en un lenguaje de consultas de base de datos. Usuarios especializados Algunos usuarios sofisticados escriben aplicaciones de base de datos especializadas que no encajan en el marco tradicional de procesamiento de datos. Usuarios no sofisticados Los usuarios no sofisticados interactúan con el sistema invocando a uno de los programas de aplicación permanentes que se han escrito anteriormente en el sistema de base de datos. Programadores de aplicaciones Los que interactúan con el sistema por medio de llamadas en DML, las cuales están incorporadas en un programa escrito en un lenguaje de programación (C, Java, etc.)

DBA

El Administrador de la Base de Datos (ABD) se encarga de administrar:
• • • • • •

La Base de Datos. El SMBD relacionado . Autoriza accesos. Coordina y vigila su utilización. Adquiere los recursos de software y hardware. Define las políticas de respaldo y recuperación de la base de datos.

DISEÑADORES DE DB

• Identifican los datos que se almacenarán

en la base de datos.
• Eligen las estructuras apropiadas para

presentar y almacenar dichos datos.
• Estas tareas se realizan antes de que se

implemente la BD y se carguen los datos.

USUARIO FINAL

Existen varias categorías de usuario final: Usuarios finales ocasionales acceden de vez en cuando a la BD. • Usuarios finales simples su función principal gira en torno a consultas y actualizaciones constante de la base de datos. • Usuarios finales avanzados pueden ser los ingenieros, científicos, analistas de negocios y otros que tiene requerimientos complejos. • Usuarios autónomos mantienen BD personales mediante la utilización de programas comerciales.

Los componentes funcionales de un sistema manejador de base de datos, son: Gestor de archivos Gestiona la asignación de espacio en la memoria del disco y de las estructuras de datos usadas para representar información. Manejador de base de datos Sirve de interfaz entre los datos y los programas de aplicación. Procesador de consultas Traduce las proposiciones en lenguajes de consulta a instrucciones de bajo nivel. Además convierte la solicitud del usuario en una forma más eficiente. Compilador de DDL Convierte las proposiciones DDL en un conjunto de tablas que contienen metadatos, estas se almacenan en el diccionario de datos. Archivo de datos En él se encuentran almacenados físicamente los datos de una organización. Diccionario de datos Contiene la información referente a la estructura de la base de datos. Índices Permiten un rápido acceso a registros que contienen valores específicos.

SMBD VS. MANEJADOR DE ARCHIVOS

• • • • •

Los manejadores de archivos no tienen una estructura interna de registros. Proporcionan poca o nula seguridad o restricción de integridad. Proporcionan pocas facilidades para recuperar datos o actualizarlos. Proporciona poca independencia de los datos Los archivos típicamente no están integrados y no comparten información.

MEMORIA PRINCIPAL

SISTEMA OPERATIVO

2 1
BUFFER DEL SISTEMA OPERATIVO

PROGRAMA DE APLICACIONES

4

3
ARCHIVO CONVENCIONAL

ÁREA DE TRABAJO DEL PROGRAMA DE APLICACIONES

MEMORIA PRINCIPAL

4
SISTEMA OPERATIVO

3
BUFFER DEL SISTEMA OPERATIVO SMBD

2

4

BASE DE DATOS

1

BUFFER DEL SMBD

PROGRAMA DE APLICACIONES ÁREA DE TRABAJO DEL PROGRAMA DE APLICACIONES

6

5

Nota: El propio SMBD puede interactuar directamente con la BD pudiendo ser de esta forma más eficiente

EJEMPLO DE UNA CONSULTA

Extracción:

Resultado (mostrado en una pantalla):

VENTAJAS DE LOS SMBD

1. Independencia de datos y tratamiento ▪ (lógica) Cambio en datos no implica cambio en programas y viceversa. • (física) Cambio físico no implica cambios en la estructura de los datos. (Menor costo de mantenimiento, promueve integridad de los datos) 2. Coherencia de resultados ▪ Reduce redundancia: ▪ Acciones lógicamente únicas. ▪ Se evita inconsistencia. 3. Mejora en la disponibilidad de datos ▪ No hay dueño de datos (No igual a ser públicos). ▪ Guarda descripción y reglas de integridad (Idea de catálogos). 4. Cumplimiento de ciertas normas ▪ Restricciones de seguridad: ▪ Accesos (Usuarios a datos). ▪ Operaciones (Operaciones sobre datos). 5. Otras ventajas ▪ Más eficiente gestión de almacenamiento.

II Modelos Lógicos Basados en Objetos

MODELO DE DATOS

Definición: Colección de herramientas conceptuales para describir datos, relaciones entre ellos, su semántica y restricciones de integridad. Se pueden clasificar dependiendo de los tipos de conceptos que ofrecen para describir la estructura de la base de datos:

Modelos de alto nivel o conceptuales, disponen de conceptos muy cercanos al modo como la mayoría de los usuarios perciben los datos. Modelos de Datos de Representación, tiene conceptos que pueden ser entendidos por los usuarios finales aunque no están demasiado alejados de la forma como se organizan dentro de la computadora.

CLASIFICACIÓN

• Modelos basados en registros • Modelos basados en objetos • Modelos objeto - relacionales

Modelos Basados en Registros
• Almacenan su información en una estructura jerárquica. • Los datos se organizan en una forma similar a un árbol (visto al revés). • El contenido de un registro específico puede repetirse en varios sitios ⇒ una inconsistencia de datos .

Jerárquico

Modelos Basados en Registros
• Representa los datos mediante colecciones de registros y sus relaciones se representan por medio de ligas. • Se permite que un mismo nodo tenga varios padres. • Ofrecía una solución eficiente al problema de redundancia de datos.

De Red

Modelos Basados en Registros
• Fundamentos Matemáticos. • Los datos están estructurados a nivel lógico como tablas formadas por filas y columnas. • Concepto fundamental: Relación. • Alto nivel de abstracción. Dr. Edgar F. "Ted" Codd Junio 1970

Relacional

“A Relational Model of Data for Large Shared Data Banks ”

Modelos Basados en Objetos
• Percepción de un mundo real. Entidades y relaciones. • Entidades: descritas por un conjunto de atributos. • Relaciones: Asociación entre entidades.

Entidad - Relación

Dr. Peter Pin-Shan Chen Marzo 1976 “The Entity-Relationship Model--Toward a Unified View of Data”

Modelos Basados en Objetos

Orientado a Objetos
• “Development of an object-oriented DBMS” D. Maier, J. Stein, A. Otis, A. Purdy 1986.

• Soporta el paradigma orientado a objetos almacenando datos y métodos. • Flexibilidad y soporte para el manejo de tipos de datos complejos. • Manipula datos complejos en forma rápida y ágilmente .

Modelos Objeto - Relacionales
Dr. Michael Stonebraker.

• Las bases de datos están presentes en muchos aspectos. • Su desarrollo ha sido en paralelo con las necesidades de información por parte de los distintos usuarios (datamining, datawarehouse). • Su nivel de abstracción también ha evolucionado con estos últimos. • Nuevas formas de representar información: • Datos semi-estructurados.

• Modelo Entidad – Relación (MER)

MODELO ENTIDAD-RELACIÓN

El modelo Entidad Relación (ER) describe los datos como entidades, vínculos (asociaciones, interrelaciones) y atributos. Entidades y sus atributos. El objeto básico que representa el modelo ER es la entidad que es una cosa del mundo real. Una entidad puede ser un objeto con existencia física (una persona, un automóvil, una casa o un empleado) o un objeto sin existencia física (proyecto, empresa, empleado, etc.).

HISTORIA

• El Modelo Entidad-Relación, propuesto por Peter Chen en el artículo ya histórico en 1976, es uno de los modelos conceptuales más extendidos. • Artículo: ACM Transactions on Database Systems, Vol.1, No. 1, March 1976, Peter Pin-Shan Chen, The EntityRelationship Model-Toward a Unified View of Data, Massachusetts Institute of Technology.

• Chen lo caracteriza: “El Modelo Entidad-Relación puede ser usado como una base para una vista unificada de los datos”, adoptando “el enfoque más natural del mundo real que consiste en entidades e interrelaciones”.

Diagramas de Chen

• Posteriormente otros autores lo han ampliado con importantes aportaciones, formándose en realidad una familia de modelos entidad relación. • En este tema se exponen los conceptos del modelo MER básico. • El modelo entidad-relación está formado por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de representaciones gráficas y lingüísticas.

DEFINICIÓN

Técnica semántica de modelado gráfico de datos basada en la percepción del mundo real como un conjunto de objetos básicos llamados entidades y las interrelaciones existentes entre ellas.

CONCEPTOS BÁSICOS

• Entidad • Atributo • Relación (Interrelación) • Diagramas Entidad-Relación

CONJUNTO DE ENTIDADES

• Es un conjunto de objetos reales o abstractos sobre el que se tiene información, pueden ser personas, lugares, cosas o eventos de interés.

• Símbolo:
NombreEntidad

ENTIDAD

• Cada ejemplar de un conjunto de entidades se denomina instancia o entidad.
– Conjunto de entidades
Persona

– Instancia o entidad

TIPOS DE ENTIDADES

• Regular o fuerte: Las instancias de este tipo tienen existencia por sí mismas en el universo de estudio independientemente de cualquier otro conjunto de entidades. • Débil: Las instancias de este tipo dependen de un conjunto de entidades existente en el universo, al desaparecer este conjunto superior, desaparecerán todos los conjuntos de entidades débiles vinculadas al mismo.

Entidad

Entidad débil

ATRIBUTO

• Los atributos son cada una de las propiedades o características descriptivas de la entidad, tales como nombre, edad y nacionalidad. • Símbolo:

Nombre

Edad

Persona

Nacionalidad

NombreAtributo

• Cada entidad de un mismo conjunto de entidades posee los mismos atributos, tanto en nombre como en número, diferenciándose cada uno de las entidades por los valores que toman dichos atributos.

25

Mexicana

26

Salvadoreña

TIPOS DE ATRIBUTOS

• Obligatorios: aquellos que deben tomar un valor y no se permite que alguna entidad no tenga un valor en el atributo.
Edad

26

Persona Salvadoreña Nacionalidad

• Opcional: aquellos atributos que pueden tener valores o no tenerlos. Posiblemente nulo (ausencia de valor).
nulo Teléfono Edad 26 Persona Salvadoreña Nacionalidad

• Monovaluado: aquel atributo que sólo puede tener un único valor. Ejemplo: Edad.
nulo Teléfono Edad 26 Persona Salvadoreña Nacionalidad

• Multivaluado: aquellos atributos que pueden tener varios valores. Ejemplo: Teléfono. • Símbolo: 0445512345678
Atributo 56061234

Teléfono

Edad 26 Persona Salvadoreña Nacionalidad

• Derivados: Su valor se obtiene a partir de los valores de otros atributos, es decir, derivan de valores de otros atributos o entidades relacionadas. • Símbolo:
Edad

• Simples: No se pueden dividir en subpartes. • Símbolo: Nacionalidad • Compuestos: Se pueden dividir en subpartes. Mes • Símbolo: Día
Fecha de nacimiento

Año

• Claves: Una clave, es el conjunto de atributos de una entidad que permiten distinguirla de forma única del resto de entidades del conjunto de entidades. • Se aplica también a las interrelaciones. • Símbolo:
Atributo

CLAVES

• Superclave: Es un conjunto de uno o más atributos que, tomados colectivamente, permiten identificar de forma única una entidad en el conjunto de entidades o una interrelación en el conjunto de interrelaciones (este conjunto no necesariamente es mínimo).

Nombre Id_cliente

Teléfono

Cliente

• Claves candidatas: Son superclaves tales que todos sus subconjuntos propios de atributos no son superclave.
Nombre Id_cliente

Teléfono

Cliente

No_IFE

• Clave primaria: Es una clave candidata elegida por el diseñador como elemento principal para identificar de forma única las entidades dentro de un conjunto de entidades o una interrelación en el conjunto de interrelaciones. La clave primaria se debe elegir de manera que sus atributos en lo posible nunca cambien.

SELECCIÓN DE LA CLAVE PRIMARIA

Nombre Id_cliente

Teléfono

Cliente

No_IFE

ENTIDAD-ATRIBUTO

Nombre
Teléfono

Número de cuenta Alumno

Fecha de nacimiento Nacionalidad
Día Mes Año

Edad

INTERRELACIONES (ASOCIACIONES)

• Las interrelaciones representan asociaciones del mundo real entre dos o más entidades.

Maestro enseña a alumnos
Interrelación Enseña

Nota: Consideramos que el modelo Entidad – Relación fue una desafortunada referencia (traducción) del modelo que Chen llamó Entity – Relationship (no Entity – Relation). En este caso la palabra Relación se refiere a Asociación o Vínculo o Interrelación entre Entidades. Es importante esta aclaración pues en el modelo Relacional, la palabra Relación tiene una connotación muy diferente.

Las interrelaciones se caracterizan por: • Nombre: que es un verbo en singular. Ejemplo: Imparte, escribe, etc. • Grado: número de entidades que participan en la interrelación. • Cardinalidad: Expresa el número de entidades a las que otra entidad pueda estar asociada, por medio de un conjunto de interrelaciones.

GRADO

Asociación unaria
Casada R con

Asociación binaria

Médico E Persona E

atiende R

Paciente E

Asociación ternaria

E Materia

R Obtiene

E Evaluación

E Estudiante

• Una interrelación puede ser recursiva, si relaciona un conjunto de entidad consigo mismo.

Empleado

Supervisa

ROL

El nombre de rol indica el papel que una entidad participante de un conjunto de entidades desempeña en cada instancia de una interrelación y ayuda a explicar el significado de la interrelación.
Supervisado

Empleado

Supervisa

Supervisor

CLAVE FORANEA

CLAVE FORÁNEA (FK)
Atributo o conjunto de atributos que hace referencia a una llave primaria de otra relación o de la misma relación. En una interrelación recursiva como la anterior, un conjunto de atributos en la relación Empleado hace referencia a la clave primaria para indicar quien es el Supervisor.

CARDINALIDAD

Tipos de interrelaciones: • Uno a uno • Uno a muchos • Muchos a uno • Muchos a muchos Esto depende del entono real dentro del que se esté modelando.

• Uno a uno
Tiene a1 a2 b1

b2 b3 Ayuntamiento

a3 Municipio

• Uno a muchos:
Conformada por a1 a2 b1 b2 b3 b4 b5 Departamento

a3

Empresa

• Muchos a uno
Pertenece a a1 a2 b1 b2 b3

a3 a4 a5 Sucursal

Empresa

• Muchos a muchos
Atiende a a1 a2 b1 b2

a3 a4 Profesor

b3 b4 Estudiante

Consideremos un vínculo TRABAJA_PARA entre los dos conjuntos de entidades EMPLEADO y DEPARTAMENT O, que asocia a cada empleado con el departamento para el que trabaja

ATRIBUTOS DE LAS INTERRELACIONES

• Las interrelaciones pueden tener atributos como las entidades.
Atributo

Interrelación

Semestre

Profesor

Imparte

Asignatura

OPCIONES DE SIMBOLOGÍA

Cardinalidad

Chen 1 1 N 1 N 1

Uno a uno (1:1) Uno a muchos (1:N) Muchos a uno (N:1) Muchos a muchos (M:N)

M

N

Chen
Obligatoria Obligatoria Obligatoria

Opcional

No existe

Opcional

Opcional

Obligatoria

Opcional

Cardinalidad
Uno a uno (1:1) Uno a muchos (1:N) Muchos a uno (N:1) Muchos a muchos (M:N)

Obligatoria

Obligatoria

Opcional

Opcional

Obligatoria

Opcional

• Modelo Entidad – Relación Extendido (MERE)

MODELO ERE

• • • • • • •

Subtipos, supertipos y herencia. Especialización y generalización. Notación para subtipos y supertipos. Interrelaciones y subtipos. Restricciones en supertipos. Múltiples jerarquías y herencia. Categorías.

• El modelo ER basta para representar esquemas de BD de aplicaciones tradicionales. • Aplicaciones más nuevas como BD para CAD/CAM, imágenes, multimedia, minería de datos, data warehousing, índices web, etc. Necesitan un modelo semántico con conceptos adicionales, componiéndose el ER-extendido.

SUBTIPOS, SUPERTIPOS Y HERENCIA

• Subtipo (o subclase): un subagrupamiento de entidades en un conjunto de entidades que tiene atributos que son distintos de otros subagrupamientos.

• Supertipo (superclase): un conjunto de entidades genérica que tiene una interrelación con uno o más subtipos.

• Herencia de tipo:
– Los subtipos heredan los atributos del supertipo relacionado. – Una instancia de un subtipo es también una instancia de un supertipo.

Supertipo Empleado con Tres Subtipos Derivados

Interrelación en la cual todas las instancias participan

Conjunto de entidades General

Interrelación en la cual sólo las versiones especializadas participan Versión especializada del supertipo

Notación para Subtipos y Supertipos en el Modelo EER

NOTACIÓN DE ALGUNAS HERRAMIENTAS
Interrelación en la cual todas las instancias participan

Conjunto de entidades General

Interrelación en la cual sólo las versiones especializadas participan

Versión especializada del supertipo

INTERRELACIONES Y SUBTIPOS

• Interrelaciones en el nivel de supertipos indica que todos los subtipos participarán en la interrelación. • Las instancias de un subtipo pueden participar en una interrelación única para el subtipo. En este caso, la interrelación es mostrada en el nivel de subtipo.

Interrelación a nivel de supertipos

Interrelación a nivel de subtipos

GENERALIZACIÓN

• Generalización: es el proceso de definir un conjunto de entidades más general a partir de un conjunto de entidades más especializadas. (Bottom-up) • El conjunto de entidades que se especializa en otros se llama supertipo ( Vehículo, Empleado). • Identificar atributos e interrelaciones comunes, y formar un supertipo que los incluya.

EJEMPLO
Marca Modelo Marca Modelo
Tipo Cabina

Id_ Vehículo

Nombre_ Vehículo

No_ Pasajeros

Id_ Vehículo

Nombre_ Vehículo

Capacidad

Precio

Carro

No_de Motor

Precio

Camión

No_de Motor

Marca

Modelo

Id_ Vehículo

Nombre_ Vehículo

No_de Motor

Precio

Moto

ESPECIALIZACIÓN

• Especialización: el proceso de definir uno o más subtipos del supertipo y formar interrelaciones supertipo/subtipo. (Top-down)

EJEMPLO

Precio_unitario

Descripción

Proveedor

Id_Proveedor

No_Parte

Pieza

Num_Envío

Cant_Disponible

Ubicación

 Generalización • Énfasis en las similitudes. • Cada instancia del supertipo es también una instancia de alguno de los subtipos.  Especialización • Énfasis en las diferencias. • Alguna instancia del supertipo puede no ser instancia de ningún subtipo.

RESTRICCIONES EN SUPERTIPOS

• Indica que una instancia de un supertipo debe también ser miembro de un subtipo.
– Regla de especialización total (completa): Indica que toda instancia del supertipo también debe ser instancia de algún subtipo. Símbolo: doble línea. – Regla de especialización parcial: Indica que es parcial posible que alguna instancia del supertipo no pertenezca a ninguno de los subtipos. Símbolo: línea simple.

EJEMPLOS

Un paciente debe ser ya sea paciente externo o paciente residente

Un vehículo puede ser un carro, un camión o ninguno

• Si una instancia de un supertipo puede ser simultáneamente, un miembro de dos o más subtipos
– Regla disjunta: una instancia del supertipo disjunta puede ser sólo una de los subtipos. – Regla de traslape: una instancia del traslape supertipo puede ser más de una de los subtipos.

d

Un paciente puede ser ya sea paciente externo o paciente residente, pero no ambos

Una pieza puede ser ambos, comprada y manufacturada o

• Es un atributo del supertipo cuyo valor determina el subtipo correspondiente.
– Disjunto: un atributo simple con valores Disjunto alternativos para indicar el subtipo correspondiente. – Traslape: un atributo compuesto cuyas Traslape subpartes pertenecen a los diferentes subtipos. Cada subparte contiene un valor lógico que indica si la instancia pertenece o no al subtipo asociado.

Tipo_empleado

Tipo_empleado=

Atributo simple que indica el tipo de subclase correspondiente

d
“H” “S”

“C”

Comprada

Manufacturada

Tipo

O

CLUSTER DE ENTIDADES

• Los diagramas MERE pueden ser difíciles de entender por la cantidad de elementos que puede contener. • La solución es agrupar entidades e interrelaciones dentro de clusters de entidades. • Cluster de entidades: conjunto de uno o entidades más tipos de entidad y las interrelaciones asociadas agrupadas en un único conjunto de entidades abstracta.

Grupos de Entidades Relacionadas Pueden Formar Clusters

Unidad de ventas

Hace negocios con

Cliente

Compra

Material

Usado

Artículo

Artículo vendido

Producido en

Manufacturera

SIMBOLOGÍA

Descripción
Herencia Especialización total Especialización parcial Regla disjunta Regla de traslape

Símbolo

JERARQUÍAS DE ÁRBOL

• Son las jerarquías que se han visto hasta ahora, en las que se cumple la restricción:
– Todo subtipo participa en sólo una interrelación supertipo/subtipo. – Un subtipo tiene un único supertipo: es el concepto de árbol.

Propiedad d

Edificio

Finca

MÚLTIPLES JERARQUÍAS

• Múltiples jerarquías: el modelo ERE nos permite dar al mismo supertipo más de una especialización. • A veces la misma entidad puede ser un subtipo de dos o más supertipos. Tal clase es llamada subtipo compartido y posee herencia múltiple de sus supertipos.

JERARQUÍA MÚLTIPLE
dni pila ape1 ape2 d d nombre Empleado fecha direc

veloc Secretaria Técnico nivel

tipo Ingeniero Jefe Asalariado sueldo Jefe de ingeniería

Precio Subcont

HERENCIA SIMPLE

• En una jerarquía de árbol o jerarquía de especialización, cada subtipo hereda sus atributos e interrelaciones…
– De su único supertipo directo, – Y de sus supertipos predecesores hasta la raíz.

HERENCIA MÚLTIPLE

• En una jerarquía múltiple de especialización un subtipo hereda atributos e interrelaciones:
– De sus supertipos (múltiples) directas. – De todos sus supertipos predecesoras hasta la raíz.

nombre dni

sexo

direc fecha-n

Persona O

sueldo

Empleado d

Estudiante d Ayudante d Maestria
titulo

especialidad

Laboral
nivel

Docente
categoría

Licenciatura
grupo

proyecto

Investigación

Docencia

práctica

• En herencia múltiple pueden surgir conflictos al heredar atributos distintos denominados igual.
Horario Horario Estudiante Empleado

¿Horario?

Ayudante

¿Cómo resolver el problema? • Definir un orden de prioridad en la herencia. Ayudante hereda horario de Estudiante y no de Empleado. • Renombrar algunos de los atributos en conflicto. Ayudante hereda ambos atributos: – “Horario” corresponde a “Horario” de Empleado, – “HorarioEscuela” a “Horario” de estudiante.

INHIBICIÓN DE LA HERENCIA

• En algunos casos se puede indicar que ciertos atributos del supertipo no deben ser heredados por los subtipos. Se puede representar cambiando el color de los símbolos de atributos inhibidos o con comentarios.
Polígono Ancho y Alto no deberían ser heredados por Cuadrado Triángulo d Ancho Rectángulo Alto

Lado

Cuadrado

REDEFINICIÓN DE ATRIBUTOS HEREDADOS

• Si un supertipo y un subtipo tienen un atributo con el mismo nombre, se entiende que el atributo del subtipo redefine el del supertipo. – Se utiliza el mismo nombre y significado semántico. – pero se modifica cómo se calcula o cómo se representa el valor del atributo. • Tiene sentido derivados. sobre todo para atributos

Área

Ancho Rectángulo Alto

Lado

Cuadrado

Área

• Si en el MERE se considera la inhibición de herencia y la redefinición de atributos, al presentarse conflicto de nombres por herencia múltiple, las opciones serán:
– Renombrar algunos atributos en conflicto. – Inhibir la herencia de algunos atributos.

CATEGORÍAS

• Una categoría tiene dos o más supertipos que pueden representar distintas entidades, mientras que las otras interrelaciones supertipo /subtipo tienen un solo supertipo. • Una categoría es un subconjunto de la unión de sus supertipos. debe existir al menos en uno de los supertipos, pero no tiene que ser miembro de todos.

dir

IFE Persona nombre nombre Unión Banco U dir Empresa nombre dir

Propietario tiene matricula Vehículo fechacompra

• Una categoría puede ser parcial o total. • Las categorías parciales implementan herencia selectiva. Símbolo: U • Las categorías totales implementan herencia múltiple. Símbolo:
U

Edificio

Finca

Persona

Banco U

Empresa

U

Propiedad

Propietario Categoría parcial: Cada propietario hereda los atributos de una Empresa, una Persona o un Banco, dependiendo del supertipo al que pertenezca.

Categoría total: Cada Edificio o Finca debe ser miembro de Propiedad.

CATEGORÍAS Y GENERALIZACIÓN

• Si dos tipos representan las mismas entidades y comparten muchos atributos, incluyendo la misma clave, es preferible la utilización de especialización/generalización; en otro caso la categorización es más apropiada.
Edificio Finca Propiedad

U


Edificio

d

Propiedad

Finca

AGREGACIÓN

• Permite combinar varios conjuntos de entidad, relacionados mediante un conjunto de interrelación, para formar un conjunto de entidad agregada de nivel superior. • Útil cuando el conjunto de entidad agregado debe relacionarse con otros conjuntos de entidad.

• Para esta interrelación se quiere registrar los administradores que supervisan las tareas de un empleado. • Existe una entidad Administrador.
Trabajo

Empleado

Trabaja en

Sucursal

• Alternativa 1: interrelación cuaternaria. Da origen a redundancia. Trabajo

Empleado

Trabaja en

Sucursal

Dirige

Administrador

• Alternativa 2: agregación.
Trabajo

Empleado Trabaja-en

Trabaja en

Sucursal

Dirige

Administrador

• La agregación es una abstracción según la cual las interrelaciones se tratan como entidades de nivel más alto.

RESUMEN DE SIMBOLOGÍA

Elemento Generalización / Especialización Especialización total Especialización parcial Disjunción Traslape

Símbolo

d O

Elemento Unión / Categoría Categoría parcial

Símbolo
U

U

Categoría total Agregación

U

Como entidad

ESQUEMAS RELACIONALES DERIVADOS DEL MER

• Algunos les llaman esquemas ER relacionales. Es una mezcla entre estos modelos y son muy utilizados por herramientas case.

PASO DE MER Y MERE A TABLAS

Elemento Conj. de entidades Atributo Clave primaria Atributo compuesto (monovaluados) Atributo multivaluado

Equivalencia Relacional Tabla Campo Llave primaria Cada sub atributo se convierte en campo Tabla con campos para el atributo y para la llave de la entidad.

Elemento Atributo compuesto (multivaluados)

Equivalencia Relacional Los atributos multivaluados forman tablas, los monovaluados son campos en la tabla de la entidad. ---Tabla con llave foránea de la entidad fuerte relacionada.

Atributo derivado Entidad débil

Elemento Interrelación muchos a muchos

Equivalencia Relacional Tabla cuyos atributos son los de la interrelación y las claves primarias de las entidades relacionadas.

Interrelaciones de orden n

Tabla con los atributos de la interrelación y las claves primarias de las entidades relacionadas.

Elemento Interrelación binaria uno a muchos sin atributos Interrelación binaria uno a muchos con atributos Interrelación uno a uno

Equivalencia Relacional La tabla del lado varios incluye a la clave de la tabla del lado uno. La tabla del lado varios incluye los atributos de la interrelación y la clave de la tabla del lado uno. La clave de una tabla pasa a la otra tabla relacionada.

Elemento interrelaciones recursivas Generalización

Equivalencia Relacional Se tratan igual que las otras pero puede resultar en la duplicación de un atributo en una tabla. Para convertir este tipo de interrelación en su equivalencia del modelo relacional hay varias opciones.

Elemento Generalización

Equivalencia Relacional OPCIÓN A: Crear una tabla para el supertipo, con sus atributos correspondientes y una tabla para cada subtipo con sus atributos más la clave primaria del supertipo.

Elemento

Equivalencia Relacional

Generalización

OPCIÓN B: Crear para cada subtipo una tabla con los atributos del supertipo más los atributos propios, donde la clave primaria será la del supertipo. Esta opción sólo es válida para especializaciones totales disjuntas.

Elemento Generalización

Equivalencia Relacional OPCIÓN C: Crear una sola tabla con todos los atributos del supertipo y los subtipos más un atributo T que indica el subtipo al que la tupla pertenece. Esto corresponde a una especialización disjunta y puede generar muchos valores nulos.

Elemento Generalización

Equivalencia Relacional OPCIÓN D: Crear una sola tabla con todos los atributos del supertipo más los atributos de los subtipos, más unos atributos Ti cuyo valor lógico nos indicará a qué subtipo pertenece la tupla. Esta opción corresponde una especialización con solapamiento.

Elemento Categorías

Equivalencia Relacional Se crea una clave para la categoría que identifique cada una de las ocurrencias de la categoría y que será heredada como clave foránea por cada uno de los supertipos. Se añadirá un atributo a la tabla de la categoría que exprese a que subtipo pertenece cada túpla en particular.

PROBLEMA

Enunciado del problema: • Se desea implementar una base de datos para facilitar la gestión y administración de un cementerio, en dicha base de datos se contemplan diferentes categorías laborales, distintos tipos de sepulturas, facturas por los servicios prestados, incluso se permite que una familia posea su propia sepultura para un determinado número de personas. El cementerio está dividido en sectores, teniendo estos una capacidad y extensión variable que ha de quedar reflejada. Asimismo se quiere tener información sobre los empleados mediante datos personales como nombre y apellidos, dirección, teléfono, salario, antigüedad, etc. Las categorías en las que se dividen los empleados son:

• • •

– Enterradores – Jardineros – Administrativos

• • •

Los jardineros se ocuparán del cuidado de los sectores, de tal forma que un jardinero está al cuidado de un sector, aunque del cuidado de un sector pueden encargarse varios jardineros. Asimismo, cada sector contendrá un determinado número de sepulturas. Una sepultura pertenece a un sector. Las Sepulturas pueden ser:

– Nicho – Tumba – Fosa Común
• Es necesario, además, almacenar información sobre el fallecido, así como de la persona (familiar) que se hará cargo de los costes del servicio (todo ello, obviamente identificado mediante los datos personales y de interés para la empresa). Cada fallecido es enterrado por un único enterrador, lógicamente el enterrador puede enterrar a más de un fallecido durante su jornada laboral.

• • • • •

Los nichos tienen capacidad para una sola persona. Sin embargo una tumba tiene capacidad para varias personas siendo lo normal 4. La capacidad de una Fosa Común es superior a la de una Tumba, y es de tipo entero. En este caso y en los dos anteriores asumimos la indivisibilidad del fallecido. Además, los administrativos emiten facturas para los familiares, de tal forma que un administrativo puede emitir facturas a varios familiares, y un familiar puede recibir varias facturas. El único tipo de sepultura que puede ser propiedad de un familiar es la Tumba, siendo propiedad de una única persona, y dicha persona puede poseer varias tumbas.

APaterno Nombre Nombre completo ID

AMaterno

Día Antigüedad Fecha de contratación Teléfono Empleado

Mes Año

Dirección

Tipo_empleado

A E

Salario

d
Enterrador

J

Administrativo

Jardinero

Id_sepulcro

Tipo Fecha de compra Sepulcro

T N Tumba CapacidadT InscripciónT

d
Nicho Altura

F Fosa común CapacidadF

InscripciónN

NSector Id_sector

Capacidad Superficie

Nombre

APaterno

Sector

Nombre completo Teléfono Id_familiar

AMaterno Mes Dirección Día Familiar Nombre Fecha Año

Id_factura Cantidad Factura

APaterno

Nombre completo Mes Día Año

AMaterno Mes Día Año

Fecha Nacimiento

Fallecido

Fecha Fallecimiento

Enterrador

Id_fallecido

Asignado a

Jardinero IDJardinero <pi> Integer Nombre Text APaterno Text AMaterno Text Direccion Text Salario Decimal Antigüedad Integer FechaContratación Date Identifier_1 <pi> Relationship_16 Sector IdSector <pi> Integer NSector Text Capacidad Integer Superficie Decimal Identifier_1 <pi> <M> <M> <M> <M> Relationship_18 <M> <M> <M> <M> <M> <M>

Administrativo IDAdmininstrador <pi> Integer Nombre Text APaterno Text AMaterno Text Direccion Text Salario Decimal Antigüedad Integer FechaContratación Date Identifier_1 <pi> <M> <M> <M> <M> <M> <M> <M>

Enterrador IDEnterrador <pi> Integer Nombre Text APaterno Text AMaterno Text Direccion Text Salario Decimal Antigüedad Integer FechaContratación Date Identifier_1 <pi> <M> <M> <M> <M> <M> <M>

Relationship_19

Relationship_20

Teléfono IDTeléfono <pi> Integer <M> Teléfono Integer Identifier_1 <pi> Relationship_17 Relationship_12 Familiar IdFamiliar <pi> Integer Nombre Text APaterno Text AMaterno Text Direccion Text Identifier_1 <pi> Relationship_15 Relationship_6 Relationship_4 Relationship_13 <M> <M> <M> <M>

Relationship_14

Sepulcro IDSepulcro <pi> Integer <M> Tipo Text <M> Identifier_1 <pi> Relationship_8 Relationship_21 Nicho Altura Decimal <M> Inscripción Text FosaComún Capacidad Integer <M> Relationship_22 Fallecido Tumba Capacidad Integer <M> Inscripción Text

Factura IdFactura <pi> Integer <M> Cantidad Decimal <M> Fecha Date Identifier_1 <pi>

IdFallecido <pi> Integer Nombre Text APaterno Text AMaterno Text FechaDeNacimiento Date FechaDeFallecimiento Date Identifier_1 <pi>

<M> <M> <M> <M> <M> <M>

Jardinero IDJardinero Nombre APaterno AMaterno Direccion Salario Antigüedad FechaContratación integer <pk> long varchar long varchar long varchar long varchar decimal integer date

Administrativo IDAdmininstrador Nombre APaterno AMaterno Direccion Salario Antigüedad FechaContratación integer <pk> long varchar long varchar long varchar long varchar decimal integer date

Enterrador IDEnterrador Nombre APaterno AMaterno Direccion Salario Antigüedad FechaContratación integer <pk> long varchar long varchar long varchar long varchar decimal integer date

FK_TELEFONO_RELATIONS_ADMINIST FK_SECTOR_RELATIONS_JARDINER FK_TELEFONO_RELATIONS_JARDINER Teléfono IDTeléfono IDEnterrador IDAdmininstrador IdFamiliar IDJardinero Teléfono integer integer integer integer integer integer

FK_TELEFONO_RELATIONS_ENTERRAD

Sector IdSector integer <pk> IDJardinero integer <fk> NSector long varchar Capacidad integer Superficie decimal FK_SEPULCRO_RELATIONS_SECTOR

<pk> <fk4> <fk3> <fk1> <fk2>

FK_TELEFONO_RELATIONS_FAMILIAR FK_FACTURA_RELATIONS_ADMINIST Familiar FK_FALLECID_RELATIONS_FAMILIAR IdFamiliar integer <pk> Nombre long varchar APaterno long varchar AMaterno long varchar Direccion long varchar FK_FALLECID_RELATIONS_ENTERRAD FK_FACTURA_RELATIONS_FAMILIAR

Sepulcro IDSepulcro integer <pk> IdSector integer FK_TUMBA_RELATIONS_SEPULCRO <fk> IDSepulcro Tipo long varchar Capacidad FK_FOSACOMU_RELATIONS_SEPULCRO Inscripción FK_NICHO_RELATIONS_SEPULCRO Tumba integer <fk> integer long varchar

Factura IdFactura IdFamiliar IDAdmininstrador Cantidad Fecha integer <pk> integer <fk1> integer <fk2> decimal date

Nicho IDSepulcro integer <fk> Altura decimal Inscripción long varchar FosaComún IDSepulcro integer <fk> Capacidad integer FK_FALLECID_RELATIONS_SEPULCRO Fallecido IdFallecido IdFamiliar IDSepulcro IDEnterrador Nombre APaterno AMaterno FechaDeNacimiento FechaDeFallecimiento integer integer integer integer long varchar long varchar long varchar date date <pk> <fk1> <fk3> <fk2>

NOCIONES DE DISEÑO DE BASES DE DATOS

Proceso por el que se determina la organización de una base de datos, incluidos su estructura, contenido y las aplicaciones que se han de desarrollar.

Las metodologías de diseño de bases de datos NO son muy populares; el NO LLEVAR UNA METODOLOGÍA se considera, con frecuencia, una de las principales causas de fracaso en el desarrollo de los sistemas de información.

• Diseño Conceptual • Diseño Lógico • Diseño Físico

DISEÑO CONCEPTUAL

Descripción de alto nivel de la estructura de la base de datos. No describe las estructuras de almacenamiento que se necesitarán para manejar esta información.

DISEÑO LÓGICO

Parte del esquema conceptual y es una descripción de la estructura de la base de datos.

CUALIDADES DE UN BUEN DISEÑO

Expresividad – Expresar perfectamente la realidad con suficientes conceptos. Simplicidad – Fáciles de entender. Minimalidad – Cada concepto debe tener un significado distinto. Formalidad – Conceptos con interpretación única, precisa y bien definida.

METODOLOGÍA DE DISEÑO

El primer paso en el diseño de una base de datos es la producción del esquema conceptual. Cada esquema conceptual (VISTAS) representa las distintas visiones que los usuarios tienen de la información. Las nociones de conjunto de entidades y conjunto de interrelaciones no son precisas. Es posible definir un conjunto de entidades interrelaciones entre ellas de diferentes formas. y las

Examinar los diagramas de flujo de datos, que se pueden haber producido previamente, para identificar cada una de las áreas funcionales. Entrevistar a los usuarios, examinar los procedimientos, los informes y los formularios, y también observar el funcionamiento de la empresa.

TAREAS A REALIZAR

• Identificar los conjuntos de entidades. • Identificar los conjuntos de relaciones. • Identificar los atributos y asociarlos a entidades y relaciones. • Determinar los dominios de los atributos.

• Determinar los identificadores. • Determinar las jerarquías de generalización. • Dibujar el diagrama entidad-relación. • Revisar el esquema con el usuario.

1. Identificar los conjuntos de entidades:

Examinar las especificaciones de requisitos de usuario. Se buscan objetos importantes como personas, lugares o conceptos de interés. Siempre que sea posible, el usuario debe colaborar en la identificación de las entidades.

2. Identificar los conjuntos de relaciones:

Expresiones verbales (oficina tiene empleados). Si las especificaciones de requisitos reflejan estas relaciones es porque son importantes para la empresa y por lo tanto, se deben reflejar en el esquema conceptual.

3. Identificar los atributos:

Es muy útil elaborar una lista de atributos e ir eliminándolos de la lista conforme se vayan asociando a una entidad o relación.

4. Determinar los dominios:

Conjunto de valores que puede tomar el atributo. Por ejemplo el dominio del atributo ‘sexo’ de los empleados es ‘femenino’ ó ‘masculino’. Se puede representar por la inicial de la palabra: ‘F’, ‘M’ .

5. Determinar los identificadores:

Cada entidad tiene al menos un identificador. De cada entidad se escogerá uno de los identificadores como clave primaria en la fase del diseño lógico.

6. Jerarquías de generalización:

Ver si es necesario reflejar las diferencias entre distintas ocurrencias de una entidad, con lo que surgirán nuevas subentidades de esta entidad genérica.

7. Diagrama entidad-relación:

Dibujar el diagrama entidad-relación correspondiente a una de las vistas de los usuarios. Se obtiene así un esquema conceptual local.

8. Revisar esquema con usuario:

Este esquema está formado por el diagrama entidad-relación y toda la documentación que describe el esquema. Retroalimentación.

EJEMPLO

Se quiere modelar un sistema para manejar artículos científicos. Un ARTÍCULO está escrito por un AUTOR, aunque a veces pueden ser varios. Obviamente una misma persona puede participar en más de un artículo. Cada artículo tiene título, resumen y contenido. Cada autor pertenece a alguna INSTITUCIÓN.

Utilizamos las siguientes reglas: 1.- Entidad Fuerte – Se representa con una tabla, cuyas columnas corresponden a los atributos de las entidades. Tabla Autores.
autor_id nombre nacionalidad fecha de nacimiento

Utilizamos las siguientes reglas: 2.- Entidad Débil – Se adiciona una columna por cada atributo de la llave primaria de la entidad fuerte de la cual el conjunto de entidades débil depende. Tabla Experimentos.
articulo_id experimento_id nombre descripcion

Utilizamos las siguientes reglas: 3.- Relación “uno a varios” – Se incluye en la tabla del extremo “varios” las columnas de la llave primaria del extremo “uno”. Alternativamente, se puede representar usando la regla siguiente.

Utilizamos las siguientes reglas: 4.- Relación “varios a varios” – Se representa con una tabla, la cual tiene una columna por cada atributo de las llaves primarias de los conjuntos de entidades a los que está ligada, más una columna por cada atributo descriptivo de la relación.

INTERRELACIONES – “autor pertenece a institución” se representa agregando una columna institucion_id a la tabla autores. La interrelación “artículo es escrito por autor” se representa de la misma manera, agregando un nuevo atributo a la tabla artículos.

INTERRELACIONES – “artículo cita a artículo”. Crear tabla adicional para almacenar esta información. Una de las columnas indicará el artículo que cita, y la otra será el artículo citado.

articulo_id

ref_articulo_id

INTERRELACIONES – Ternaria. Una institución financia a un autor para que trabaje en un artículo. Crear una tabla que lleva las llaves primarias de las tres tablas, y una columna adicional para la fecha de recepción y el monto.
autor_id articulo_id institucion_id monto fecha recepcion

Modelos Orientado a objetos

MODELO ORIENTADO A OBJETOS

• • • • • •

Modelo orientado a objetos. Conceptos de datos orientados a objetos. Modelado conceptual de objetos mediante UML. Simbología. Conceptos avanzados. Ejemplo de diagrama de clases.

• El modelo relacional tradicional es limitado en su habilidad para representar los datos e interrelaciones complejas necesarias para aplicaciones avanzadas. • Gran influencia de las tecnologías orientadas a objetos. • La motivación es mover de objetos temporales manipulados por programas a objetos persistentes que pueden ser almacenados en una base de datos.

BASES DE DATOS ORIENTADAS A OBJETOS

• una colección de objetos sobre la que se definen ciertas reglas de organización en almacenamiento secundario para poder accesarlos.

CONCEPTOS DEL MODELO OO

Vehículo Platero:Animal Animal

Punto Figura (1,3) (2,2) (2,1)

(5,2.5)

• Objeto: es una entidad discreta con límites bien definidos y con identidad, es una unidad atómica que encapsula estado y comportamiento. • Literal: difiere de un objeto en que posee un estado pero no un identificador de objeto.

• Clase: es un conjunto de objetos que poseen la misma estructura, incluyendo los mismos atributos con los mismos tipos de datos y los mismos métodos e interrelaciones. Se definen listando sus elementos de datos, métodos e interrelaciones.

• Atributo: es una sección dentro de un clasificador (una interfaz, clase, subsistema, base de datos o componente) que describe un rango de valores que una instancia del clasificador puede contener. • Operación: un servicio que puede ser requerido a un objeto para efectuar un comportamiento.

• Método: La implementación de una operación. Específica el algoritmo o procedimiento que efectúa el resultado de una operación. • Interrelación: una conexión semántica entre elementos modelados.

• Asociación: La interrelación semántica entre dos o más clasificadores que implica conexiones entre sus instancias. • Generalización: una interrelación entre un elemento más general y un elemento más específico.

• Polimorfismo: es la habilidad para usar el mismo nombre para diferentes operaciones. • Interfase: una declaración de una colección de operaciones que pueden ser usadas para definir un servicio ofrecido por una instancia.

• Jerarquía de clases: Organización de clases consistentes de superclases y subtipos, en el cual cada interrelación es del tipo “es un”. • Identidad de objeto: Cada objeto en la base de datos tiene asignado su propio identificador único. El modelo OO provee identificadores únicos automáticamente.

EJEMPLO

Figura

Triángulo

Cuadrado

Círculo

• Se aplica: – Jerarquía de clases – Generalización – Polimorfismo

UML

MODELO Y DIAGRAMA

• Un Modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle. • Un Diagrama es una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vértices (otros elementos del modelo).

EL PORQUE DE MODELAR

• Un modelo es una simplificación de la realidad. • Se construyen modelos de sistemas complejos porque no se puede comprender un sistema en su totalidad. • El decidir qué modelo a crear tiene una influencia profunda en cómo un problema es atacado y cómo una solución es formada. • Cada modelo puede ser expresado a diferentes niveles de precisión. • Los mejores modelos están conectados a la realidad.

EL LENGUAJE DE MODELADO

• Los métodos orientados a objetos consisten, al menos en principio, en un lenguaje y en un proceso para modelar. • Un lenguaje de modelado es la notación (principalmente gráfica) de que se valen los métodos para expresar diseños. • Notación: material gráfico que se ven en los modelos (sintaxis del lenguaje de modelado). • Metamodelo: el cual es un diagrama, usualmente un diagrama de clases que define la notación, en ella se muestra las relaciones entre las notaciones.

¿QUÉ ES UML?

• • •

UML = Unified Modeling Language Un lenguaje de propósito general para el modelado orientado a objetos UML combina notaciones provenientes desde: - Modelado Orientado a Objetos - Modelado de Datos - Modelado de Componentes - Modelado de Flujos de Trabajo (Workflows) UML es un lenguaje gráfico para:

– – – –

Especificar Construir Visualizar Documentar

EL PAPEL DE UML

• El principal papel de UML es describir cualquier tipo de sistema en términos de diagramas orientados a objetos. • Sistemas de información. • Sistemas de tiempo real. • Sistemas distribuidos. • Software de sistemas. • Sistemas de negocios.

UML

• El Lenguaje Unificado de Modelado (UML) es una notación que combina elementos de tres importantes estándares de diseño OO: – OMT de Rumbaugh – Análisis y diseño OO de Booch y – El modelo de Jacobson • Ha tenido varias modificaciones desde su creación siendo la última versión la 2.0.

DIAGRAMAS UML v1.x

DIAGRAMAS UML v2.0

PAQUETES

• Permite dividir un sistema grande en unidades más pequeñas. • Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado.

Paquete 1

Paquete 2

CASOS DE USO

• Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa con los usuarios.

SECUENCIA

• Muestra una interacción ordenada según la secuencia temporal de eventos.

ESTADOS

• Muestra la secuencia de estados por los que pasa un caso de uso, un objeto a lo largo de su vida, o todo el sistema. • Controla la forma con la que el usuario se introduce al sistema.

DISTRIBUCIÓN (DESPLIEGUE)

• Muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos.

ACTIVIDAD

• Muestra cómo fluye el control de unas clases a otras con la finalidad de culminar con un flujo de control total que corresponde con la consecución de un proceso más complejo.

COMPONENTES

• Los diagramas de componentes describen los elementos físicos del sistema y sus interrelaciones. • Los componentes representan todos los tipos de elementos de software que entran en la fabricación de aplicaciones informáticas.

Transaccione s

Actualizar_transaccione s

búsqueda

Consultas /reportes

Reservas

CLASES

• Es el diagrama principal para el análisis y diseño. • Un diagrama de clases presenta las clases del sistema con sus interrelaciones estructurales y de herencia. • La definición de clase incluye definiciones para atributos y operaciones.

OBJETOS

• El Modelado de Objetos permite representar el ciclo de vida de los objetos a través de sus interacciones.

NUEVOS DIAGRAMAS EN UML v2.0

• Diagramas de Tiempos. Empleados para mostrar las interacciones donde el propósito fundamental consiste en razonar sobre la ocurrencia de eventos en el tiempo que provocan el cambio de estados de un elemento estructural (clase, componente, etc.).

• Diagrama de Comunicación. Equivalente al diagrama de colaboración del OMG UML 1.x. Permite especificar interacciones entre objetos que conforman la estructura interna de un clasificador.

COLABORACIÓN

• Es una forma de representar interacción entre objetos. • El diagrama de colaboración se centra en estudiar todos los efectos de un objeto dado durante un escenario.

• Diagrama de Estructura Compuesta. Se emplea para visualizar de manera gráfica las partes que definen la estructura interna de un clasificador.

• Diagrama General de Interacción. Se emplea fundamentalmente para representar las interacciones, a través de diagramas o fragmentos de diagramas de secuencias, entre los actores y el sistema como una gran caja negra, y de diagramas de actividades en los que aparecen dichos fragmentos.

MODELO CONCEPTUAL DE OBJETOS CON UML

• Para el diseño de una base de datos se pueden utilizar los diagramas de:
– Casos de uso: para el análisis de la base de datos, examinando roles de los usuarios y operaciones a realizarse con la base de datos. – Diagrama de clases: para el diseño conceptual de la base de datos.

DIAGRAMA DE CLASES

• El Diagrama de Clases es el diagrama principal utilizado para análisis y diseño. • Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. • La definición de clase incluye definiciones para atributos y operaciones. • El modelo de casos de uso aporta información para establecer las clases, objetos, atributos y operaciones. • Representa conjuntos de objetos que comparten atributos y características comunes. • Muestra el conjunto de clases, interfaces, colaboración y relaciones entre objetos.

ELEMENTOS

• Superior: Contiene el nombre. • Intermedio: Contiene los atributos que caracterizan a la Clase (privado, protegido o público). • Inferior: Contiene los métodos, los cuales son la forma como interactúa el objeto con su entorno (privado, protegido o público).

ATRIBUTOS

• Público: Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. • Privado: Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar). • Protegido: Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia).

MÉTODOS

Un método u operación es la implementación de un servicio de la clase, que muestra un comportamiento común a todos los objetos. En resumen es una función que le indica a las instancias de la clase que hagan algo:

• Público: Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. • Privado: Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden invocar). • Protegido: Indica que el método no será accesible desde fuera de la clase, pero si podrá ser invocado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia).

EJEMPLO

PRINCIPIOS PARA EL MODELADO

• Atomización: es la división de un complejo dominio del mundo en entidades individuales (átomos), llamados objetos.

• Clasificación: usa las interrelaciones equivalentes de objetos con propiedades comunes y similares para integrarlas en un conjunto y describirlas con una clase equivalente para el conjunto de elementos.
Vehículo

• Identificación: la identificación es realizada por un identificador para cada unidad.

Vehículo

Se identifica por un código que puede ser El número de motor.

• Encapsulación: asegura la consistencia de un conjunto de información. Un acceso externo directo a la información encapsulada no es posible. • Persistencia: el ciclo de vida de un objeto persistente es independiente de su uso en un proceso de aplicación.

• Asociación: describe interrelaciones entre objetos con derechos iguales.

Vehículo

Conducido por

Piloto

• Generalización y especialización: definen una interrelación “es un” entre objetos. Usando este principio en diferentes niveles se forman jerarquías o familias de clases.
Vehículo

Terrestre

Aéreo

Marítimo

• Estandarización: se definen los objetos y clases independientemente de un dominio específico del mundo, como elementos de modelado estándar.

• Agregación y composición: definen una interrelación “es parte de” entre clases. La diferencia entre la agregación y la composición está dada por la dependencia entre objetos componentes y el objeto contenedor.
Carro
UML 2.0 ya sólo considera la composición

Motor

Asiento

DIAGRAMAS ESTÁTICOS

• Los diagramas estáticos muestran mediante un gráfico la clasificación de elementos conectados mediante relaciones estáticas. • El diagrama de clase describe los tipos de objetos que hay en el sistema y las diversas clases de relaciones estáticas que existen entre ellos. Hay dos tipos principales de relaciones estáticas:  Asociaciones (por ejemplo, un cliente puede rentar diversas videocintas).  Subtipos (una enfermera es un tipo de persona).

DIAGRAMAS DE CLASES

Los diagramas de clase muestran los atributos y métodos de una clase.

Por todo esto podemos afirmar que: • • • • El Diagrama de Clases es el diagrama utilizado para análisis y diseño. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. La definición de clase incluye definiciones para atributos y operaciones. Un diagrama de clases es una alternativa de representación de modelos de objetos. Esta notación es independiente de cualquier lenguaje de programación.

SIMBOLOGÍA DE LOS DIAGRAMAS DE CLASES

• Clase: Puede representarse con el símbolo completo que incluye los atributos y métodos de la clase o con un icono de clase para simplicidad.

Clase
atributos Métodos

Clase

• Atributos y métodos: éstos pueden tener íconos indicadores de la visibilidad que presentan en la clase. Los íconos dependerán de la herramienta de modelado. Por lo general se utilizan símbolos como: - Atributo o método privado. + Atributo o método público. # Atributo o método protegido.

• Interrelaciones: las interrelaciones entre clases se representan con líneas que siguen estos formatos:

Dependencia

• Nombre de asociación y dirección: El nombre de la asociación es opcional. Se puede añadir un triángulo negro sólido que indique la dirección en la cual leer el nombre de la asociación.

• Multiplicidad: es una restricción que se pone a una asociación, que limita el número de instancias de una clase que pueden tener esa asociación con una instancia de la otra clase.

Cuenta

La multiplicidad se representa con: • Un número fijo: 1 • Un intervalo de valores: 2..5 • Un rango en el cual uno de los extremos es un asterisco. Por ejemplo, 2..* significa 2 o más. • Una combinación de elementos separados por comas: 1, 3..5, 7, 15..* • Un asterisco: * . Indica cero o más.

• Roles: Indican el papel que juega una clase en una asociación.

CONCEPTOS AVANZADOS

• Estereotipo: Son una forma de extender los diagramas de clase, que permiten definir un estilo de plantilla de clases. Se colocan entre comillas españolas «»

• Clase abstracta: son clases que no pueden generar ninguna instancia de clase. Se consideran un concepto intermedio que debe ser redefinido mediante especialización. Se representan igual que una clase normal y se pueden diferenciar colocándoles el estereotipo «abstract»

• Estereotipo de asociación: Las asociaciones pueden estar etiquetadas con estereotipos que cambian su significado.

Clase A

«create»

Clase B

Indica que la clase B es creada por la clase A

• Clase asociación: muestran como se implementa una asociación particular. Pueden indicar también, formas especiales de referencia, como referencias débiles.

Registrador Referencia débil

Mensaje de registro

• Asociaciones N-arias: es una asociación en la que participan más de dos clases.
Año

Equipo

Jugador

Marcas

• Asociaciones calificadas: un calificador es un atributo de la asociación cuyos valores sirven para particionar el conjunto de objetos enlazados a otro. • Un calificador se representa como un pequeño rectángulo conectado al final de una asociación y a la clase. • El calificador es parte de la asociación y no de la clase.

• Asociaciones calificadas

EJEMPLO

Asociación
marido 0.. 1 0.. 1 mujer jefe 0.. 1 Administra

casado-con

Persona nombre s. s.

*

trabaja-para emplea-a

*

Compañía nombre dirección

*

empleado

Agregación

coche 1

Persona 0..2 +Padre

+Hijos *

1 motor

Generalización

Responsabilidades

Herencia Múltiple

Dependencia

Herencia

Polimorfismo • Se relaciona fuertemente con herencia. • Muchas formas.

III. Modelo Relacional

El Modelo Relacional es sin lugar a dudas el fundamento de la tecnología moderna de base de datos. • Es un modelo lógico. • Álgebra en la mayoría de los SMBD. • SMBD: aplicación que permite definir, crear, mantener la BD y proporciona acceso a la misma.

INTRODUCCIÓN

• En 1970 Codd introdujo el modelo relacional, que más tarde sería la base para los actuales SMBD.

Dr. Edgar Frank Codd Fallecido el 18 de abril del 2003.

¿Quién fue…Edgar Frank Codd?
•Nació en Portland Bill, Inglaterra. • Estudió becado matemáticas y química en Oxford. • A los 25 años viajó a los Estados Unidos y consiguió trabajo en IBM. • En 1965 terminó un doctorado en computación de la Univ. de Michigan en Ann Arbor. • Una evaluación negativa de su supervisor en Nueva York significó un traslado a los laboratorios de IBM en San José en 1967. Sería aquí que Codd conocería el mundo de las bases de datos, al que se dedicaría en los años siguientes. • En 1996 obtuvo el premio de la IEEE a pioneros de la computación.

Edgar Frank Codd Sus Contribuciones…

• En 1969 inventó el Modelo Relacional, el Modelo de Base de Datos más utilizado hoy en día. • Al inicio el apoyo de IBM a los Sistemas de Base de Datos Tradicionales (de redes) era mayoritario. • Hasta 1978 el Modelo Relacional llamó la atención del Presidente de IBM Frank Cary. • Más tarde IBM anuncia SQL/DS su 1er producto relacional en 1981 y después sacan al mercado DB2 en 1983. • El trabajo inicial de Codd fue publicado en Communications of the ACM en 1970. • En 1985 postuló una lista de 12 reglas que debía cumplir un producto de bases de datos para ser llamado relacional.

• Un poco de historia...

– 1970, E.F.Codd introduce Modelo Relacional. – Codd, experto matemático. – Anteriormente uso de “punteros”. – Direccionamiento a disco. – El archivo B contenía un campo con la dirección de disco de A (relación).
• Desventajas:

– Operaciones limitadas sobre datos. – Vulnerables a cambios físicos. – Mover datos se tenían que redireccionar punteros.

Modelo Relacional, segunda generación de SMBD. Datos estructurados a nivel lógico. Tablas (filas y columnas). Estructura Lógica, No física (Sistema Relacional). Estructura a nivel físico era diferente, pero no importaba (archivos secuenciales, indexación, cadenas apuntadores, etc.). Ventaja: sencillez de su estructura lógica.

• Las bases de datos relacionales tienen un principio interesante, denominado: Principio de Información
el contenido de información de la base de datos está representado en una sola forma; es decir, como valores explícitos dentro de posiciones de columnas dentro de filas dentro de tablas.”
“Todo

• Aspectos de datos del Modelo Relacional:

– Estructura de Datos. – Integridad de Datos. – Manejo de Datos.
• Estructura Datos:

– La Relación. – Concepto matemático. – Representa por una tabla. – Terminología matemática (teoría de conjuntos y lógica de predicados).

ESTRUCTURA

• Una base de datos relacional consiste de una colección de “tablas”. Cada “tabla” tiene una estructura similar a la que se presentó en el modelo Entidad-Interrelación. • Cada renglón de esta tabla representa una relación entre un conjunto de valores, esto es conocido formalmente como tupla. Dado que una tabla es un conjunto de estas relaciones, hay una fuerte correspondencia entre el concepto de tabla y el concepto de relación.

• Un atributo representa las propiedades de la relación, y se representan mediante columnas en las tablas. Cada atributo de una relación se caracteriza por un nombre y por un dominio. • Un dominio indica qué valores pueden ser asumidos por una columna de la relación, o sea, es el conjunto de valores sobre los que se define el tipo de un atributo. Por ejemplo, del atributo días de la semana, su dominio podría ser: {Lunes, … , Domingo}.

• Matemáticamente una relación definida sobre los n dominios D1, D2,.., Dn no necesariamente distintos, es un subconjunto del producto cartesiano de estos dominios donde cada elemento de la relación, una tupla, es una serie de n valores ordenados, o sea, su primer elemento es de D1, el segundo de D2, etc*. No debe confundirse con el concepto de relación que se dio en el modelo entidad-interrelación.
*Definición de Codd, 1970, “A relational Model of Data for Larged Shared Data Banks”.

• Los dominios de todos los atributos deben ser atómicos (sus dominios son indivisibles). • Es posible que varios atributos tengan el mismo dominio (nombre_cliente, nombre_empleado). • La integridad de dominio significa que todas las entradas para cada atributo sean válidas. Se puede restringir el tipo de dato, intervalo de valores, formato, NOT NULL, etc., esto para garantizar la integridad de los datos.

• Los dominios sirven para restringir las comparaciones. • Cuando se realiza una consulta, las condiciones de la consulta suelen representarse a través de comparaciones entre atributos de las relaciones. • Una forma sencilla de identificar si la consulta es semánticamente correcta es analizar si los atributos que forman parte de una comparación son compatibles, es decir, si pertenecen al mismo dominio. SELECT * FROM PACIENTE WHERE PACIENTE.FECHA_INGRESO = ‘01011984’; SELECT * FROM PACIENTE WHERE ANIO(PACIENTE.FECHA_INGRESO) < ‘1984’;

• Tupla: fila de la relación.
– No siguen orden

• Grado: número de atributos que contiene una relación.
– No cambia con frecuencia

• Cardinalidad: número de tuplas que contiene.
– Por insertar y eliminar varia constantemente.

• Una relación R definida sobre un conjunto de dominios D1, D2, D3,... Dn, consta de...
CABECERA (atributo:dominio) {(A1:D1), (A2:D2),.... (An:Dn)} – El grado de la relación es “n” – No hay atributos que se llamen igual

CUERPO (atributo:valor) {(A1 : VI1), (A2 : VI2),...... (An : VIn)} – Con “i=1,2,..,m” m es la cardinalidad de la relación

• Gráficamente
– Relación = Tabla – Atributo = Columna – Tupla = Fila

• La menor unidad semántica de información (dato individual) = Valor Escalar (no tienen estructura interna)

• Propiedades Relaciones:

– Cada relación tiene nombre y es distinto a los demás. – Valor de atributo es atómico (normalizado). – No hay atributos con mismo nombre. – Orden atributos no importa (no aporta información). – Tuplas distintas, no hay duplicadas. – Orden tuplas no importa (no aporta información).

• Tipos de Relaciones:

– Relaciones Base • Tienen nombre. • Forman parte directa de la BD (autónomas). – Vistas • Con nombre y derivadas. • No poseen datos almacenados propios. – Instantáneas • Con nombre y derivadas. • Son reales, tienen datos propios almacenados. • Solo lectura y se refrescan periódicamente. – Resultados de Consulta • Originan de una consulta. • Con o sin nombre. • No persistentes en la BD.

– Resultados intermedios
• Origen = subconsultas. • Sin nombre y no persisten en la BD.

– Resultados temporales
• Con nombre. • Se destruyen automáticamente en un momento dado.

• Claves
– Identificadores únicos. – Mediante valores de atributos.

• Superclave
– Atributo o conjunto de atributos que identifican de modo único las tuplas de una relación.

• Clave candidata
– Una superclave en la que ninguno de sus subconjuntos es una superclave de la relación.

• Clave Candidata (propiedades)
– Unicidad (única) – Irreducibilidad (minimalidad)

• Clave candidata con más de un atributo = Clave Compuesta. • Para identificar una clave candidata se debe conocer el significado real de los atributos. • Clave primaria = clave candidata seleccionada por el diseñador.

• Peor de los casos
– Clave primaria = todos los atributos de la relación.

• Claves Alternativas (Alternas)
– Claves candidatas no seleccionadas como primarias.

• Clave Ajena (Foránea)
– Atributo(s) que coinciden con la clave primaria de otra relación. – Representan relaciones entre datos. – Representa una referencia a otra tupla.

“Una BD Relacional es un conjunto de relaciones normalizadas” • Para representar el esquema de una BD Relacional:
– Nombre de sus relaciones – Atributos – Dominios – Claves primarias – Claves ajenas VISITA (Qnum,Inum,Fecha,Comentario)

• Clave ajena
ONUM

PLANTILLA  OFICINA: Oficina pertenece empleado

RESUMEN
Una relación Una tupla Un atributo Cardinalidad una tabla con ciertas características una fila en la relación una columna de la relación número de filas (tuplas) en la relación

Atributo Grado La clave primaria Dominio

Columna Número de columnas un identificador único para la relación una colección de valores

RELACIÓN

• Resumen
---- ---- --- ----- --- --- ----- --- ----- ---- --- ----- --- --- ----- --- -D.F GUDALAJARA ETC...

V#:V# v1 v2 v3 v4 v5

PROVEEDOR:NOMBRE STATUS:STATUS CIUDAD:CIUDAD Fernando 20 D.F. José 10 Guadalajara Joel 30 Monterrey Miguel 20 Toluca Ivan 30 Cancún
ATRIBUTO GRADO

DOMINIO

---- ---- --- ----- --- --- ----- --- -Clave Primaria

CARDINALIDAD

RELACIÓN

TUPLA

ESTRUCTURA DEL MODELO RELACIONAL

Ejemplo de RELACIÓN:

RESTRICCIONES DEL MODELO

RESTRICCIONES SEMÁNTICAS DEL MODELO

EL MODELO Y LA ARQUITECTURA ANSI

EL MODELO RELACIONAL

• Para el desarrollo de este modelo, Codd introdujo una teoría que lo respalda: • Álgebra relacional que esta basada en la teoría de conjuntos. • Calculo relacional basado en lógica de predicados de primer orden. • Los SMBD típicamente utilizan lenguajes de alto nivel que pueden ser clasificados en procedimentales y no procedimentales.

NO PROCEDIMENTAL

• En un lenguaje no procedimental, el usuario describe la información deseada sin dar algún procedimiento específico para obtener la información:

{ t | C(t) }
Donde C es una condición dada.

PROCEDIMENTAL

• En el lenguaje procedimental el usuario indica al sistema una secuencia de operaciones sobre la base da datos para calcular el resultado deseado:

Selecciona Atributon de Tabla1

ÁLGEBRA VS. CÁLCULO

• El álgebra relacional es procedimental y consiste en un conjunto de operaciones que toman 1 ó 2 relaciones como entrada y produce una nueva relación como resultado. • El cálculo relacional es no procedimental y sólo describe la información deseada sin algún procedimiento específico.

PRINCIPIOS BÁSICOS

• Principios básicos Modelo Relacional: – Estructura de datos relacional. – Reglas de Integridad. – Manipulación (Álgebra Relacional). – Cálculo Relacional.

• Álgebra Relacional
– Conjunto de operaciones para manipular la estructura de datos relacional. – Especificar la consulta de datos. – Lenguaje procedimental.

• Cálculo Relacional
– Lenguaje equivalente. – No procedimental.

• Disciplinas tienen bases teóricas. • Industria del automóvil: aerodinámica.

– Menor consumo de combustible.
• Teoría hace las cosas predecibles.

– Saber que ocurrirá al realizar una acción.
• Ejemplo: BD Relacional.

– ¿Si un par de tablas están relacionadas? – Extracción de datos de las dos a la vez.

• Datos obtenidos se basan en valores coincidentes del campo que tienen en común. • Por lo tanto, tienen un resultado predecible. • Modelo Relacional y Matemáticas – Teoría de conjuntos. – Lógica de predicados de primer orden. • Ventaja: Seguro, Robusto, Predecible, Confiables. • No es necesario ser expertos en Matemáticas.

• Teoría describe:
– Elementos básicos para crear una BD Relacional. – Las líneas para construirla.

• El organizar estos elementos para conseguir el resultado = Diseño.

EJEMPLO Los atributos Nombre, Ciudad, Tipo-Cliente toman los valores de sus correspondientes dominios.
DOMINIOS

NOMBRES xxxxxxxxxxxxxx 50

CIUDADES MONTERREY MONTERREY D.F. MONTERREY ACAPULCO MAZATLAN VERACRUZ YUCATAN

TIPOS DE CLIENTES BANCOS CENTROS EDUCATIVOS EMPRESAS PRIVADAS FILIALES HOSPITALES PRIVADOS PARA-ESTATALES DOCTORES ACCIONISTAS

Relación Cliente
Nombre Ciudad INSTITUTO MEXICANO, A.C. MONTERREY UNIVERSIDAD DEL SUR, A.C. MONTERREY ADMINISTRADORA MEDICA DE OCCIDENTE, S.A. D.F.C.V. DE SERVICIOS HOSPITALARIOS S.A. DE C.V. MONTERREY SERVICIOS AGENTE DE SEGURIDAD ACAPULCO LAVA RÁPIDO S.A. DE C.V. MAZATLAN BEBIDAS NACIONALES, S.A. DE C.V. VERACRUZ CLINICAS DEL NORTE, S.A. DE C.V. YUCATAN Tipo-Cliente BANCOS CENTROS EDUCATIVOS EMPRESAS PRIVADAS FILIALES HOSPITALES PRIVADOS PARA-ESTATALES DOCTORES ACCIONISTAS

EL MODELO DE DATOS RELACIONAL

• El modelo relacional representa la base de datos como una colección de relaciones. En términos más sencillos, cada relación se asemeja a una tabla de valores.
• En la terminología formal del modelo relacional,

una fila se denomina tupla, una cabecera de columnas es un atributo y la tabla se denomina relación. El tipo de datos que describe los tipos de valores que puede aparecer en cada columna se llama dominio.

Un esquema de relacional R, denotado por R(A1, A2, ..., An), se compone de un nombre de relación R y una lista de atributos A1, A2, …, An. El grado de una relación es el número de atributos n de su esquema de relación. ALUMNO(Nombre, NSS, TelefonoCasa, Dirección) En este esquema de relación, ALUMNO es el nombre de la relación, la cual tiene 4 atributos. El grado de la relación es 4.

REGLAS DE INTEGRIDAD

Son expresiones de verdad asociadas a una base de datos que siempre tienen que ser verdaderas. Las reglas de integridad aseguran que los cambios hechos a la base de datos no resulten en pérdida de consistencia de los datos.

Nulos

“Atributo desconocido o ausencia de valor”
No representa 0 (cero) ni la cadena vacía Ocurre porque al momento de insertar la tupla:
se desconocía el valor (nulo aplicable) no tiene sentido para dicha tupla (nulo no aplicable)

Nulos Por ejemplo la relación de productos puede presentar nulos en ciertos atributos.
Nulos

Relación: Producto
Producto# 100 101 102 103 Descripcion Precio Existencia TABLA 42 PARED 750.00 SILLA 13 VESTIDOR 500.00 8

Clave Primaria

RESTRICCIONES DE DOMINIO

“Se debe asociar a cada atributo con un conjunto de posibles valores” Son las restricciones más básicas del modelo relacional. Son fáciles de validar. Una clara definición de dominios ayuda a validar los valores y a que la información tenga sentido.

EJEMPLO

Los atributos nombre_cliente y nombre_empleado pueden pertenecer al mismo dominio, ambos son cadenas de caracteres. Pero sueldoxhora e índice_de_ganancia a cierto nivel ambos son números con decimales, pero a un nivel conceptual el sueldo no puede ser menor a x cantidad y un índice va de 0.0 a 1.0

INTEGRIDAD DE ENTIDADES

Ningún componente de la clave primaria de una relación base puede aceptar nulos. • La regla de integridad de las entidades se aplica a las relaciones base. • La regla de integridad de las entidades se aplica sólo a las claves primarias. Por definición, una clave primaria es un identificador irreducible que se utiliza para identificar de modo único las tuplas. Si se permite que parte de la clave primaria sea nula, se está diciendo que no todos sus atributos son necesarios para distinguir las tuplas, con lo que se contradice la irreducibilidad .

REGLAS DE INTEGRIDAD REFERENCIAL

Si en una relación hay alguna clave ajena, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o bien, deben ser completamente nulos. • Se aplica a claves ajenas. • Se trata de justificar que si B hace referencia a A, entonces A debe existir. • La regla indica lo que no se debe presentar pero no dice como debe evitarse.

Si estando en un estado legal, llega una petición de operación que conduce a un estado ilegal existen 2 opciones: • Rechazar la operación. • Aceptar la operación y realizar las operaciones que conduzcan a un estado legal.

Por lo tanto toda llave ajena deberá contestar a 3 preguntas: Regla de nulos ¿Tiene sentido aceptar nulos? Regla de borrado ¿Qué ocurre si se intenta borrar la tupla representada por la clave ajena? • • • Restringir: no se permite borrar la tupla referenciada. Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas que la referencian mediante la clave ajena. Anular: se borra la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena (sólo si acepta nulos).

Regla de modificación ¿Qué ocurre si se intenta modificar el valor de la clave primaria de la tupla referenciada por la clave ajena ? • • • Restringir: no se permite modificar el valor clave primaria de la tupla referenciada. Propagar: se modifica el valor de la clave primaria de la tupla referenciada y se propaga a las tuplas que la referencian mediante la clave ajena. Anular: se modifica la clave primaria de la tupla referenciada y las tuplas que la referenciaban ponen a nulo la clave ajena (sólo si acepta nulos).

REGLAS DEL NEGOCIO

Los usuarios o los administradores de la base de datos pueden imponer ciertas restricciones específicas sobre los datos, denominadas reglas de negocio.

• Son siempre referidas en lenguaje natural en un inicio. • Antes de definirse los datos deben de cumplir la condición.
A este conjunto de reglas Codd le llama:

Integridad del usuario

Ejemplo: Restricción en lenguaje natural:

1.

Todos los proveedores deben tener valor del status entre 0 y 101

Restricción formal

CONSTRAINT PROV_R1 IS_EMPTY (PROV WHERE STATUS <1 OR STATUS>100)
El Administrador debe hacer que se ejecute esta restricción en todas las operaciones que intenten insertar un proveedor o cambiar el estatus de uno existente

RESUMEN

Reglas de Integridad

Son expresiones de verdad asociadas a una base de datos que siempre tienen que ser verdaderas.

Nulo

Atributo desconocido o ausencia de valor

Restricciones de dominio

Asociar a cada atributo con un conjunto de posibles valores

Regla de integridad de Entidades Reglas de Integridad referencial

Ningún componente de la clave primaria de una relación base puede aceptar nulos. Si en una relación hay alguna clave ajena, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o bien, deben ser completamente nulos.

Reglas de negocio o Integridad del Usuario

Restricciones específicas sobre los datos

ÁLGEBRA RELACIONAL

• Es un lenguaje de consulta procedimental. • Consta de un conjunto de operaciones. • Toman como entrada una o dos relaciones y producen como resultado una nueva relación (álgebra). • Es posible anidar y combinar operadores.

•Hay ocho operadores en el álgebra relacional que construyen relaciones y manipulan datos, estos son:
Operaciones básicas (fundamentales) Operaciones derivadas (compuestas)

1. Unión. 2. Selección. 3. Diferencia. 4. Producto. 5. Proyección.

1. Intersección. 2. División. 3. Join (Reunión).

Operadores Unarios y Binarios.

La Selección y la proyección son operaciones unarias porque operan sobre una sola relación.

El resto de las operaciones son binarias porque trabajan sobre pares de relaciones.

SELECCIÓN
• Opta por tuplas que satisfagan cierto predicado. Compara

todas las tuplas, una por una y selecciona sólo las tuplas que satisfagan cierta condición (predicado) especificada.
• Representado por sigma (σ). • Predicado aparece como subíndice de (σ). • La relación se da entre paréntesis.

EJEMPLO

Enum EL21 EG37 EG14 EA9 EG5 EL41

Nombre Amelia Pedro Luis Rita Julio Carlos

Apellido Pastor Cubedo Collado Renau Prats Baeza

Dirección Magallanes, 15 Bayarri, 11 Borriol, 35 Casalduch, Melilla, 23 Herrero, 51

Teléfono 964 284 560 964 535 690 964 522 230 964 257 550 964 524 590 964 247 250

Puesto Director Supervisor Administ. Supervisor Director Supervisor

Fecha_nac 12/10/62 24/3/57 9/5/70 19/5/60 19/12/50 29/2/67

Salario 30000 18000 12000 18000 24000 18000

DNI 39432212E 38766623X 24391223L 39233190F 25644309X 39552133T

Onum O5 O3 O3 O7 O3 O5

σ salario > 18000 (PLANTILLA)
Resultado:
Enum EL21 EG5 Nombre Amelia Julio Apellido Pastor Prats Dirección Magallanes, 15 Melilla, 23 Teléfono 964 284 560 964 524 590 Puesto Director Director Fecha_nac 12/10/62 19/12/50 Salario 30000 24000 DNI 39432212E 25644309X Onum O5 O3

Obtener todos los empleados que trabajan en la oficina 03, dada la siguiente relación (Plantilla)
Enum EL21 EG37 EG14 EA9 EG5 EL41 Nombre Amelia Pedro Luis Rita Julio Carlos Apellido Pastor Cubedo Collado Renau Prats Baeza Dirección Magallanes, 15 Bayarri, 11 Borriol, 35 Casalduch, Melilla, 23 Herrero, 51 Teléfono 964 284 560 964 535 690 964 522 230 964 257 550 964 524 590 964 247 250 Puesto Director Supervisor Administ. Supervisor Director Supervisor Fecha_nac 12/10/62 24/3/57 9/5/70 19/5/60 19/12/50 29/2/67
Salario

DNI 39432212E 38766623X 24391223L 39233190F 25644309X 39552133T

Onum

30000 18000 12000 18000 24000 18000

O5 O3 O3 O7 O3 O5

σ Onum = “03” (PLANTILLA)
Resultado:
Enu m EG37 EG14 EG5 Nombr e Pedro Luis Julio Apellido Cubedo Collado Prats Dirección Bayarri, 11 Borriol, 35 Melilla, 23 Teléfono 964 535 690 964 522 230 964 524 590 Puesto Superviso r Administ. Director Fecha_na c 24/3/57 9/5/70 19/12/50 Salari o 18000 12000 24000 DNI 38766623 X 24391223 L 25644309 X Onum O3 O3 O3

Obtener todos los inmuebles de Castellón con un alquiler mensual de hasta 350. Dada la siguiente relación (Inmueble)
Inum IA14 IL94 IG4 IG36 IG21 IG16 Calle Enmedio, 128 Riu Ebre, 24 Sorell, 5 Alicante,1 San Francisco, 10 Capuchinos, 19 Rafalafena Area Centro Ronda Sur Grao Población Castellón Castellón Castellón Segorbe Vinaroz Castellón Tipo Casa Piso Piso Casa Piso Piso Hab 6 4 3 3 5 4 Alquiler 600 350 300 325 550 400 Pnum P46 P87 P40 P93 P87 P93

σ población='Castellón' AND alquiler<=350 (INMUEBLE)

Resultado:
Inum IL94 IG4 Calle Riu Ebre, 24 Sorell, 5 Area Ronda Sur Grao Población Castellón Castellón Tipo Piso Piso Hab 4 3 Alquiler 350 300 Pnum P87 P40

PROYECCIÓN

Devuelve una relación que contiene sólo los atributos especificados junto con el operador. Se representa por la letra griega pi minúscula (π), con los atributos objeto de la proyección como subíndices del operador. Por ejemplo: πc1,c2,c3(A)

*devolvería una relación formada por los atributos, c1, c2 y c3 de la relación A.

EJEMPLO

Obtener un listado de empleados mostrando su número, nombre, apellido y salario. Dada la siguiente Relación (Plantilla)
Enum EL21 EG37 EG14 EA9 EG5 EL41 Nombre Amelia Pedro Luis Rita Julio Carlos Apellido Pastor Cubedo Collado Renau Prats Baeza Dirección Magallanes, 15 Bayarri, 11 Borriol, 35 Casalduch, Melilla, 23 Herrero, 51 Teléfono 964 284 560 964 535 690 964 522 230 964 257 550 964 524 590 964 247 250 Puesto Director Supervisor Administ. Supervisor Director Supervisor Fecha_nac 12/10/62 24/3/57 9/5/70 19/5/60 19/12/50 29/2/67 Salario 30000 18000 12000 18000 24000 18000 DNI 39432212E 38766623X 24391223L 39233190F 25644309X 39552133T Onum O5 O3 O3 O7 O3 O5

Π enum,nombre,apellido,salario (PLANTILLA)

Resultado:
Enum EL21 EG37 EG14 EA9 EG5 EL41 Nombre Amelia Pedro Luis Rita Julio Carlos Apellido Pastor Cubedo Collado Renau Prats Baeza Salario 30000 18000 12000 18000 24000 18000

PRODUCTO CARTESIANO

• En álgebra relacional el producto de dos relaciones A y B es: A Veces B o A X B • Produce el conjunto de todas las tuplas t tales que t es el encadenamiento de una tupla a perteneciente a A y de una b que pertenece a B. se utiliza el símbolo X para representar el producto. • Se obtienen todas las posibles combinaciones de tuplas entre ambas relaciones.

EJEMPLO

(Prestamo)
número-préstamo P-11 P-14 P-15 P-16

X

(Cliente)
nombre-cliente Gómez Fernández 392 nombre cliente Gómez Gómez Gómez Gómez Fernández Fernández Fernández Fernández número préstamo P-11 P-14 P-15 P-16 P-11 P-14 P-15 P-16

UNIÓN

• El resultado de la unión es una relación. • Debe cumplirse la compatibilidad respecto a la unión entre los dos operandos, lo que garantiza que los atributos de las relaciones (cabeceras) que participan del operador en la expresión sean del mismo grado y se correspondan en cuanto a su dominio. • La unión de dos relaciones A y B compatibles respecto a la unión, A ∪ B es otra relación cuya cabecera es idéntica a la de A o B y cuyo cuerpo está formado por todas las tuplas t pertenecientes ya sea a A o a B (o a las dos).

EJEMPLO
Obtener un listado de las áreas en las que hay oficinas o inmuebles para alquilar.
Onum O5 O7 O3 O4 O2 Inum IA14 IL94 IG4 IG36 IG21 IG16 Calle Enmedio, 128 Riu Ebre, 24 Sorell, 5 Alicante,1 San Francisco, 10 Capuchinos, 19 Rafalafena Calle Area Población Castellón Castellón Villarreal Grao Castellón Villarreal Area Centro Ronda Sur Grao Población Castellón Castellón Castellón Segorbe Vinaroz Castellón Tipo Casa Piso Piso Casa Piso Piso Teléfono Enmedio, 8 Moyano, s/n San Miguel, 1 Trafalgar, 23 Cedre, 26 Centro Centro 964 201 240 964 215 760 964 520 250 964 284 440 964 525 810 Hab 6 4 3 3 5 4 Alquiler 600 350 300 325 550 400 Fax 964 201 340 964 215 670 964 520 255 964 284 420 964 252 811 Pnum P46 P87 P40 P93 P87 P93

Area
( Π área (OFICINA) ) U

Centro Grao Ronda Sur Rafalafena

( Π área (INMUEBLE) ) Resultado:

REUNIÓN NATURAL (NATURAL JOIN)

La reunión natural ( |x| ) de dos relaciones A y B obtiene como resultado una relación cuyas tuplas son todas las tuplas de A concatenadas con todas las tuplas de B que en los atributos comunes (que se llaman igual) tienen los mismos valores. Estos atributos comunes aparecen una sola vez en el resultado. Es una combinación del producto cartesiano, la selección (para seleccionar las tuplas que tienen los mismos valores) y la proyección (para que aparezcan en el resultado los atributos comunes una sola vez).

EJEMPLO
Averiguar los nombres de todos los clientes que tienen concedido un préstamo en el banco y averiguar su importe. Πnombre-cliente, préstamo.número-préstamo, importe (σprestatario.número-préstamo = préstamo.número-préstamo (prestario x cliente))
nombre-sucursal importe 900 1500 1500 1300 1000 2000 500 nombre cliente Fernández Gómez Gómez López Pérez Santos Sotoca Valdivieso número préstamo P-16 P-93 P-15 P-14 P-17 P-11 P-23 P-17 P-11 P-14 P-15 P-16 P-17 P-23 P-93 Collado Mediano Centro Navacerrada Navacerrada Centro Moralzarzal Becerril

número-préstamo

nombrecliente Fernández

número préstamo P-16 P-23 P-11 P-15 P-93 P-17 P-14 P-17

Import e 1.300 2.000 900 1.500 500 1.000 1.500 1.000

Π nombre-cliente, númeropréstamo, importe

Gómez Gómez López Pérez Santos Sotoca Valdivieso

(prestatario |x| cliente)

DIVISIÓN

Suponiendo que la cabecera de R es el conjunto de atributos A y que la cabecera S es el conjunto de atributos B, tales que B es un subconjunto de A, y si C=A-B (los atributos de R que no están en S), la división (÷) obtiene una relación cuya cabecera es el conjunto de atributos C y que contiene las tuplas de R que están acompañadas de todas las tuplas de S.

ÁLGEBRA RELACIONAL

Obtener los propietarios que tengan inmuebles de 4 y 5 habitaciones (a la vez) que hayan sido visitados. Πhab,pnum(VISITA) ÷Π hab=4 or 5(VISITA)

Pnum P87

La división también puede ser definida con los operadores fundamentales de la siguiente forma:

DIFERENCIA

La diferencia de dos relaciones A y B compatibles respecto a la unión, A – B es una relación cuya cabecera es idéntica a la de A o B y cuyo cuerpo está formado por todas las tuplas t pertenecientes a A pero no a B. Permite obtener la Diferencia de dos relaciones tomadas como conjuntos de tuplas.

EJEMPLO
Onum O5 O7 O3 O4 O2

Obtener un listado de todas las poblaciones en donde hay una oficina y no hay inmuebles para alquilar. Dada las siguientes relaciones
Calle Area Población Castellón Castellón Villarreal Grao Castellón Villarreal Teléfono Fax Enmedio, 8 Moyano, s/n San Miguel, 1 Trafalgar, 23 Cedre, 26 Centro Centro 964 201 240 964 215 760 964 520 250 964 284 440 964 525 810 964 201 340 964 215 670 964 520 255 964 284 420 964 252 811

Inum IA14 IL94 IG4 IG36 IG21 IG16

Calle Enmedio, 128 Riu Ebre, 24 Sorell, 5 Alicante,1 San Francisco, 10 Capuchinos, 19

Area Centro Ronda Sur Grao

Población Castellón Castellón Castellón Segorbe Vinaroz

Tipo Casa Piso Piso Casa Piso Piso

Hab 6 4 3 3 5 4

Alquiler 600 350 300 325 550 400

Pnum P46 P87 P40 P93 P87 P93

Rafalafena

Castellón

Población
(Π población (OFICINA) - (Π población (INMUEBLE)

Villarreal

INTESECCIÓN

La intersección de dos relaciones A y B compatibles respecto a la unión, A ∩ B es una relación cuya cabecera es idéntica a la de A o B y cuyo cuerpo está formado por todas las tuplas t pertenecientes tanto a A como a B. Produce el conjunto de todas las tuplas pertenecientes a A y B. A ∩ B = A-(A-B)

EJEMPLO

Qnum

Inum IA14 IG4 IG4 IA14

Fecha 24/11/99 20/10/99 26/11/99 14/11/99

Comentario muy pequeño muy lejos

Obtener los inmuebles de 3 habitaciones que han recibido visitas de inquilinos. Dada las siguientes relaciones
Inum IA14 IL94 IG4 IG36 IG21 IG16 Calle Enmedio, 128 Riu Ebre, 24 Sorell, 5 Alicante,1 San Francisco, 10 Capuchinos, 19 Area Centro

Q56 Q76 Q56 Q62

no tiene salón

Población Castellón Castellón Castellón Segorbe Vinaroz

Tipo Casa Piso Piso Casa Piso Piso

Hab 6 4 3 3 5 4

Alquiler 600 350 300 325 550 400

Pnum P46 P87 P40 P93 P87 P93

Ronda Sur Grao

Rafalafena

Castellón

N ( Π Inum (VISITA) )

( Π Inum ( σ(Hab = 3) INMUEBLE) )

IG4

Álgebra Relacional Extendida

PROYECCIÓN EXTENDIDA

• Amplía la proyección permitiendo que se utilicen funciones aritméticas en la lista de proyección. Tiene la forma:

Donde E es cualquier expresión de álgebra relacional y F1, F2, …, Fn son expresiones aritméticas que pueden incluir constantes y/o atributos.

EJEMPLO

No_Cta Materia Calificacon 95481904 Leng. de Prog 9 50385974 Algoritmos 10 98385928 Autómatas 8 98792838 I. A. 8 97218294 Prog. Lógica 7

Materia

No_Cta Materia 95481904 Leng. de Prog 50385974 Algoritmos 98385928 Autómatas 98792838 I. A. 97218294 Prog. Lógica

Calificacon-1 8 9 7 7 6

Resultado

REUNIÓN EXTERNA

• Es una ampliación de la reunión para trabajar con la información que falta. Es la concatenación de las tuplas de R con las de S siendo que los atributos comunes, que se llaman igual, tienen los mismos valores ó estos atributos tienen nulo en S o R.

• Esta operación tiene tres formas:

• Reunión externa por la izquierda. Toma todas las tuplas de la izquierda que no coincidan con ninguna tupla de la relación de la derecha, rellena con valores nulos en todos los demás atributos de la relación de la derecha. • Reunión externa por la derecha. Igual que la anterior pero con las tuplas de la derecha.

• Reunión externa completa. Es la unión de la reunión externa izquierda y la reunión externa derecha.

No_Cta Nombre Sexo Nacionalidad 95481904 Juan M Mexicana 50385974 Edgar M Mexicana 97218294 Elizabeth F Peruana
Alumno

No_Cta Materia Calificacon 95481904 Leng. de Prog 9 50385974 Algoritmos 10 98385928 Autómatas 8 98792838 I. A. 8
Materia

No_Cta Nombre Sexo Nacionalidad No_Cta Materia Calificacon 95481904 Juan M Mexicana 95481904 Leng. de Prog 9 50385974 Edgar M Mexicana 50385974 Algoritmos 10 97218294 Elizabeth F Peruana null null null

No_Cta Nombre Sexo Nacionalidad No_Cta Materia Calificacon 95481904 Juan M Mexicana 95481904 Leng. de Prog 9 50385974 Edgar M Mexicana 50385974 Algoritmos 10 null null null null 98385928 Autómatas 8 null null null null 98792838 I. A. 8

No_Cta Nombre Sexo Nacionalidad No_Cta Materia Calificacon 95481904 Juan M Mexicana 95481904 Leng. de Prog 9 50385974 Edgar M Mexicana 50385974 Algoritmos 10 null null null null 98385928 Autómatas 8 null null null null 98792838 I. A. 8
97218294 Elizabeth F Peruana null null null

FUNCIONES DE AGREGACIÓN

• Son funciones que toman una colección de valores y devuelven como resultado un único valor. • La función de agregación sum toma un conjunto de valores y devuelve la suma de los mismos. • La función de agregación avg devuelve la media de los valores.

• La función de agregación count devuelve el número de elementos del conjunto. • Otras funciones de agregación habituales son min y max, que devuelven el valor mínimo y el máximo de la colección. • Las colecciones en las que se utilizan las funciones de agregación pueden tener valores repetidos; el orden en el que aparezcan los valores no tiene importancia.

AGRUPACIÓN

• Esta operación agrupa las tuplas que tienen los mismos valores en los atributos especificados y realiza uno o más cálculos (funciones de agregación) sobre los grupos obtenidos. • Se utiliza la notación:

…para agrupar las tuplas de R por los atributos A1, A2,…An.

EJEMPLO

Letra a a a b b c c

Numero 1 2 4 1 2 3 4

Nombre Angel Amalia Armando Beto Bernabé Carlos Cecilia

Muestra

Letra a b c

max(numero) count(nombre) avg(numero) 4 3 2.333 2 2 1.5 4 2 3.5

RENOMBRAMIENTO

• Se utiliza para cambiar el nombre de una relación, o de sus atributos. • Se hace necesaria cuando se debe trabajar varias veces con la misma relación como operando, o cuando existen nombres de relaciones y atributos idénticos como operandos en una misma operación. •El operador se representa por la letra griega ro (ρ), y toma como subíndice el nuevo nombre para la relación sobre la que actúa.

ρx(A) iIndica que el resultado de la operación es una nueva relación con el nombre x. Si se desea cambiar también el nombre de los atributos, se indica del siguiente modo: ρx(A1,A2,...,An)(A) dDonde A1, A2, ... An son los nuevos nombres de los atributos.

MODIFICACIONES DE LA BASE DE DATOS

También es posible expresar en álgebra relacional la realización de ciertas operaciones sobre la base de datos, con el objetivo de modificar su contenido.

Borrado r←r–E

INSERCIÓN

Para insertar el resultado de una expresión se puede utilizar: r←rUE

pero también se pueden insertar valores constantes del siguiente modo:

r ← r U {(“Fuengirola”,124.765)}

ACTUALIZACIÓN

Para modificar el valor de una tupla sin modificarlas todas, se puede utilizar:

r ← πF1,F2,…,Fn(r)

y si se desea seleccionar varias tuplas y modificar sólo esas tuplas, se puede utilizar:

r ← πF1,F2,…,Fn(σP(r)) U (r – σP(r))

CREACIÓN DE VISTAS

La creación de una vista se puede realizar del siguiente modo:

create view v as Expresión

CÁLCULO RELACIONAL

• El cálculo relacional proporciona una notación para formular la definición de la relación deseada en términos de las relaciones de la base de datos. • El CR está basado en una rama de la lógica matemática, llamada Lógica de Predicados, ó Cálculo de predicados de primer orden.
• Mientras que en álgebra relacional se debe dar un secuencia de pasos ó un procedimiento para obtener cierto resultado, en el cálculo relacional, se describe la información que se desea obtener sin dar algún procedimiento específico para obtener dicho resultado.

• Un predicado es una función con argumentos que se puede evaluar a verdadero o falso. • Cuando los argumentos se sustituyen por valores, la función lleva a una expresión denominada proposición. Ejemplo: Carlos es hombre [Función]

[Argumento]

Existen dos lenguajes lógicos de manipulación para el modelo relacional: • El Cálculo Relacional de Tuplas. • El Cálculo Relacional de Dominios.

CÁLCULO RELACIONAL DE TUPLAS

El Cálculo Relacional de Tuplas es en el que se basa el lenguaje de manipulación SQL. Conceptos previos:
Variable-Tupla Conectivas Cuantificadores Términos Fórmulas bien formadas

VARIABLE TUPLA

Una variable tupla es una variable cuyo rango de valores son las tuplas de una relación.
x : R tal que R (a1:dom1, a2:dom2, ..., an:domn)

De esta forma, se especifica de que relaciones tomarán valores las variables. La variable x tomará valores en el producto cartesiano de todos los dominios de R, dom1 × dom2 × ... × domn.

Conectivas ¬ Negación ∧ Conjunción ∨ Disyunción → Implicación Cuantificadores ∀ Universal ∃ Existencial

Términos: Los símbolos de constantes: Luis, María, Juan, AD1, BDA Términos de proyección: x.A, donde x es una variable-tupla y A es el nombre de un atributo de la relación sobre la que se declaró x. El término x.A representa el valor del atributo A en la tupla x.

FÓRMULAS

Un término de dominio R(x), donde R es el nombre de una relación y x es el nombre de una variable-tupla que se declaró sobre la relación R t1 θ t2, donde t1 y t2 son términos y θ es un operador de comparación (<, >, =, ≥, ≤,≠ ). Si F1 y F2 son fórmulas bien formadas, entonces también lo son: F1 ∧ F2 F1 ∨ F2 F1 → F2 ¬ F1 (F1)

Fórmulas (Ejemplos):
x.A = y.B x.A = 'Dedalo' ¬ ( x.ciudad='Londres') ( x.codigo=y.codigo ∧ y.numero<>z.numero) ∃x (x.codigo=y.codigo ∧ x.numero='123') ∀x (x.color='rojo')

∀ ∃

xF xF

EVALUACIÓN DE FÓRMULAS

R(x): cuando x se instancia a una tupla t, tal que t ∈ R, entonces se evalúa a cierto. En caso contrario se evalúa a falso. t1 θ t2: se evaluará a cierto o falso según el resultado de la comparación. En el caso de que alguno de los términos sea de proyección, es decir, de la forma x.A, el valor que se utilizará para realizar la comparación será el del aributo A de la tupla que en ese momento instancie la variable. Con operadores lógicos no cambia. La evaluación de fórmulas con cuantificadores se realiza igual que para la lógica de primer orden. Lo que interesa es encontrar tuplas para las que se cumple cierto predicado.

Su forma general es: { t / P ( t )}

Donde: t es la variable tupla. P( t ) es cualquier formula

EJEMPLOS

• La unión de dos relaciones R ∪ S puede expresarse en CRT así:

2) La diferencia de dos relaciones R - S se expresa de la siguiente forma:

Dado el esquema de base de datos siguiente: sucursal( nombre, activo, ciudad) cliente( nombre, calle, ciudad) depósito( sucursal, n-cuenta, cliente, saldo) préstamo( sucursal, n-prestamo, cliente, importe) a) Encontrar la sucursal, n-prestamo, cliente e importe para los préstamos mayores de 300,000.

Dado el esquema de base de datos siguiente: sucursal( nombre, activo, ciudad) cliente( nombre, calle, ciudad) depósito( sucursal, n-cuenta, cliente, saldo) préstamo( sucursal, n-prestamo, cliente, importe) b) Obtener todos los clientes que tienen préstamos de más de 300,000.

Dado el esquema de base de datos siguiente: sucursal( nombre, activo, ciudad) cliente( nombre, calle, ciudad) depósito( sucursal, n-cuenta, cliente, saldo) préstamo( sucursal, n-prestamo, cliente, importe) b) Encontrar a todos los clientes que tienen una cuenta en la sucursal 'Paz', pero que no han sacado un préstamo en esa sucursal:

CÁLCULO RELACIONAL DE DOMINIOS

Esta forma usa variables de dominio que toman valores del dominio de un atributo más que valores de una tupla completa. El cálculo relacional de dominios, sin embargo, está íntimamente relacionado con el cálculo relacional de tuplas.

Los átomos del cálculo relacional de dominios tienen una de las formas siguientes:
<X1, X2, … Xn> ∈r, donde r es una relación con n atributos y x1, x2, ..., xn,, son variables de dominio o constantes de dominio. Sea x Θ y, donde x e y son variables de dominio y Θ es un operador de comparación ≦, ≧, <, =, ≠, >. Se exige que los atributos x e y tengan dominios que puedan compararse mediante Θ. X Θ c, donde x es una variable de dominio, Θ es un operador de comparación y c es una constante del dominio del atributo para el que x es una variable de dominio.

Las expresiones del cálculo relacional de dominios son de la forma: {<X1, X2, … Xn> | P(X1, X2, … Xn) } donde x1, x2, ..., xn, representan las variables de dominio, P representa una fórmula compuesta de átomos.

Evaluación de Fórmulas:
1) Depende de la clase de átomo que sea: a) R(t1, t2, ..., tn): Si se puede encontrar una tupla de R, tal que los valores de los atributos a1, a2, ..., an de la tupla coinciden con los de los respectivos términos t1, t2, ..., tn, entonces la fórmula se evalúa a cierto. En otro caso se evalúa a falso. b) t1 θ t2: La evaluación es equivalente a la vista en el CRT, dependiendo del resultado de la comparación. 2) Evaluación de fórmulas con operadores lógicos: Es idéntica a la ya estudiada. 3) Evaluación de fórmulas con cuantificadores: La única diferencia es que ahora el dominio de las variables es el dominio asociado a uno de los atributos de una relación. Este es el dominio que se debe usar para realizar su asignación.

EJEMPLOS

1) La unión de dos relaciones R ∪ S puede expresarse en CRT así:

2) La diferencia de dos relaciones R - S se expresa de la siguiente forma:

Dado el esquema de base de datos siguiente: sucursal( nombre, activo, ciudad) cliente( nombre, calle, ciudad) depósito( sucursal, n-cuenta, cliente, saldo) préstamo( sucursal, n-prestamo, cliente, importe) a) Encontrar la sucursal, n-prestamo, cliente e importe para los préstamos mayores de 300,000

Dado el esquema de base de datos siguiente: sucursal( nombre, activo, ciudad) cliente( nombre, calle, ciudad) depósito( sucursal, n-cuenta, cliente, saldo) préstamo( sucursal, n-prestamo, cliente, importe) b) Obtener todos los clientes que tienen préstamos de más de 300,000

Dado el esquema de base de datos siguiente: sucursal( nombre, activo, ciudad) cliente( nombre, calle, ciudad) depósito( sucursal, n-cuenta, cliente, saldo) préstamo( sucursal, n-prestamo, cliente, importe) b) Encontrar a todos los clientes que tienen una cuenta en la sucursal 'Paz', pero que no han sacado un préstamo en esa sucursal:

CRT VS. CRD

QUERY BY EXAMPLE

Visualizan en pantalla una fila vacía de cada una de las tablas que indica el usuario. El usuario rellena estas filas con un ‘ejemplo’ de lo que desea y el sistema devuelve los datos que siguen tal ejemplo. Uno de estos lenguajes es QBE (Query-byExample). Características del QBE • • • • • • • Utiliza una sintaxis bidimensional. Los querys se expresan con ejemplos. Alta relación con cálculo relacional. No procedural. Los querys se expresan utilizando Esqueletos de tablas. El usuario selecciona el esqueleto que requiera. El usuario llena el esqueleto con un ejemplo.

• • •

Una fila ejemplo se forma de constantes y elementos ejemplo que en realidad son variables de dominio. Las variables de dominio se distinguen por un guion bajo al inicio. Las constantes se despliegan sin ninguna característica especial. Ejemplos del QBE

Encontrar todos los clientes con una cuenta de tipo SFU:

El prefijo P indica que se imprima este campo. La variable de dominio se puede omitir si no se usa en otro lugar del query.

Encontrar todos las cuentas que no se encuentran en Burnaby:

Encontrar todos los clientes con cuenta tipo SFC y Metro Town:

Encontrar los clientes que tengan una cuenta tipo SFC, Metro Town o ambas:

Encontrar todos los clientes que tengan una cuenta igual a la de Jones:

Todos las cuentas con balance entre 1300 y 1500:

DATALOG

Datalog (Database Logic) es un lenguaje lógico que es la forma más simple de lógica desarrollada para el modelo relacional. Datalog sin recursión tiene el mismo poder expresivo que el álgebra relacional. Datalog es similar a Prolog en su sintaxis, pero su semántica operacional es diferente. Una regla o cláusula en Datalog tiene la forma: cabeza ← cuerpo. donde cabeza es un átomo y cuerpo es una lista de átomos que puede ser vacía; en este caso se habla de un hecho. Los hechos se escriben así: cabeza Un átomo es de la forma: P(t1,...,tn) Donde P es un símbolo de predicado y ti son variables o constantes. No se admiten símbolos de función en ti, a diferencia de Prolog.

SIGNIFICADO DE LAS REGLAS LÓGICAS

Una regla se escribe:

P ← Q1, ..., Qn.

y se lee: "Si Q1, Q2, ... y Qn son ciertos, entonces P es cierto". Si n=0, "P es cierto", y se escribe: P. (esto es un hecho) Interpretación de la teoría de modelos La interpretación de una colección de predicados asigna cierto o falso a cada posible instancia de los predicados, donde los argumentos se escogen de un conjunto infinito de constantes. La interpretación se representa habitualmente por el conjunto de instancias verdaderas. Ejemplo:(1) p(X) :- q(X). (2) q(X) :- r(X). Dominio: los enteros. Un posible dominio M1={r(1),q(1),p(1),q(2),p(2),p(3)}, conjunto de instancias verdaderas.

Datalog es una versión de Prolog adecuada para las bases de datos, y se diferencia en: 1. Datalog no admite símbolos de función en los argumentos. 2. El significado de los programas Datalog sigue el punto de vista de teoría de modelos. Prolog, en cambio, se basa en un significado computacional que se desvía de los significados de la teoría de modelos y de la teoría de pruebas. El modelo de datos de Datalog es similar al relacional: Una relación se representa por un predicado. Sin embargo, sus argumentos siguen una notación posicional, no explícita como en el modelo relacional (cada columna tiene un nombre).

EJEMPLO

Una instancia r de la relación R(A,B) en el modelo relacional definida por:

se representa en Datalog por los hechos:

r(1,2), r(3,4).

En Datalog, el primer argumento de R se corresponde con el atributo A, y el segundo con B. El significado de la relación en ambos modelos de datos es el mismo, el conjunto de tuplas {(1,2), (3,4)}. Es decir, hay una relación de tipo R entre 1 y 2, y entre 3 y 4.

En Datalog, el primer argumento de R se corresponde con el atributo A, y el segundo con B. El significado de la relación en ambos modelos de datos es el mismo, el conjunto de tuplas {(1,2), (3,4)}. Es decir, hay una relación de tipo R entre 1 y 2, y entre 3 y 4. Predicados intencionales y extencionales Es otra diferencia entre Datalog y las bases de datos relacionales. Un predicado cuya relación se almacena explícitamente en la base de datos se denomina extencional. Un predicado que se define en términos de reglas se denomina intencional.

PREDICADOS INTENCIONALES Y EXTENCIONALES
Es otra diferencia entre Datalog y las bases de datos relacionales. Un predicado cuya relación se almacena explícitamente en la base de datos se denomina extencional. Un predicado que se define en términos de reglas se denomina intencional. Por ejemplo, en la base de datos genealógica: madre, padre, mujer, hombre: extencional madre(ana,pedro). madre(ana,juan). ... padre(jose,julia). padre(luis,jose). ... progenitor, antepasado: intencional progenitor(X,Y) :- madre(X,Y). progenitor(X,Y) :- padre(X,Y). antepasado(X,Y) :- progenitor(X,Y). antepasado(X,Y) :- progenitor(X,Z), antepasado(Z,Y).

RECURSIVIDAD Y GRAFOS DE DEPENDENCIA Las reglas Datalog son en general recursivas. Para determinar si un determinado predicado es recursivo se construye un grafo de dependencias. Sus nodos son predicados. Hay un arco de p a q si hay una regla con un subobjetivo cuyo predicado sea p y con una cabeza cuyo predicado sea q. Un programa lógico es recursivo si hay uno o más ciclos en el grafo. Un predicado es recursivo si forma parte de un ciclo. Nótese que p y q pueden ser el mismo predicado (de hecho, el caso más habitual).

EJEMPLO

hermano(X,Y) :- progenitor(Z,X), progenitor(Z,Y), X ≠ Y. primo(X,Y) :- progenitor(PX,X), progenitor(PY,Y), hermano(PX,PY). primo(X,Y) :- progenitor(PX,X), progenitor(PY,Y), primo(PX,PY). pariente(X,Y) :- hermano(X,Y). pariente(X,Y) :- pariente(X,Z), progenitor(Z,Y). pariente(X,Y) :- pariente(Z,Y), progenitor(Z,X).

• Reglas de Codd

ANTECEDENTES En la década de los 80 comenzaron a aparecer numerosos sistemas de gestión de bases de datos (SGBD) que se anunciaban como "relacionales". Sin embargo estos sistemas carecían de muchas características que se consideran importantes en un sistema relacional, perdiendo muchas ventajas del modelo relacional. Como ejemplo extremo de esto "sistemas relacionales" eran simplemente sistemas que utilizaban tablas para almacenar la información, no disponiendo de elementos como claves primarias, etc.

En 1985 Codd publicó 12 reglas que un verdadero sistema relacional debería de cumplir. En la práctica algunas de ellas son difíciles de realizar.

Un sistema podrá considerarse "más relacional" cuanto más siga estas reglas.

REGLAS DE CODD

Las reglas pueden ser divididas en 5 áreas funcionales:

1. 2. 3. 4. 5.

Reglas fundamentales Reglas estructurales Reglas de integridad Reglas de manipulación de datos Reglas de independencia de datos

1. FUNDAMENTALES (0 Y 12)

Regla 0

Para que un sistema se denomine sistema de gestión de bases de datos relacionales (SMBDR o RDBMS por sus siglas en inglés), este sistema debe usar (exclusivamente) sus capacidades relacional para gestionar la base de datos.

Regla 12: Regla de la No Subversión Si un sistema relacional tiene un lenguaje de bajo nivel (una tupla cada vez), ese lenguaje de bajo nivel no puede ser usado para saltarse (subvertir) las reglas de integridad y restricciones expresadas en los lenguajes relacionales de más alto nivel (una relación o conjunto de tuplas cada vez). Todo acceso a la base de datos debe ser controlado a través del SGBD para que la integridad de la base de datos no pueda ser comprometida sin el conocimiento del usuario o el administrador de la base de datos (ABD). Debido a que algunos problemas no se pueden solucionar directamente con el lenguaje de alto nivel. Normalmente se usa SQL incrustado en un lenguaje anfitrión (por ejemplo C) para solucionar estos problemas. Se utiliza el concepto de cursor para tratar individualmente las tuplas de una relación. En cualquier caso no debe ser posible saltarse los limitantes de integridad impuestos al tratar las tuplas a ese nivel.

2. ESTRUCTURALES (1 Y 6)

La pieza estructural fundamental es la relación.

Codd indica que los SMBDR deben soportar relaciones, dominios, llaves primarias y llaves foráneas.

Cada relación debe tener una llave primaria.

Regla 1: Regla de la Información

Toda la información en una base de datos relacional se representa explícitamente en el nivel lógico exactamente de una manera: con valores en relaciones.

Toda la información, aún los metadatos (diccionario, catálogo) se deben de representar (en relaciones) y manipular exactamente igual que los datos.

Regla 6: Regla de Actualización de Vistas

Todas las vistas que son teóricamente actualizables se pueden actualizar por el sistema.

El problema es determinar cuáles son las vistas teóricamente actualizables, ya que no está muy claro. Cada sistema puede hacer unas suposiciones particulares sobre las vistas que son actualizables.

3. INTEGRIDAD (3 y 10)

Regla 3: Tratamiento Sistemático de Ausencia de Valores

En la base de datos, el hecho de que algún valor falte, es siempre representado de la misma forma sistemática y uniforme, independientemente del tipo de datos del valor faltante. Para éste propósito son utilizadas marcas.

Se reconoce la necesidad de la existencia de marcas nulas, para un tratamiento sistemático de los mismos pero hay problemas para soportarlos en las operaciones relacionales, especialmente en las operaciones lógicas.

Lógica trivaluada. Existen tres (no dos) valores de verdad: Verdadero, Falso y Desconocido (null). Se crean tablas de verdad para las operaciones lógicas:

null Verdadero Falso Verdadero etc.

AND AND AND OR

null null null null

= = = =

null null Falso Verdadero

Un inconveniente es que de cara al usuario el manejo de los lenguajes relacionales se complica pues es más difícil de entender.

Regla 10: Independencia de Integridad Las restricciones de integridad específicas para una determinada base de datos relacional deben (poder) ser definidas en el sublenguaje de datos relacional, y almacenadas en la base de datos (catálogo), no en los programas de aplicación. El objetivo de las bases de datos no es sólo almacenar los datos, si no también sus interrelaciones y restricciones para evitar que se codifiquen en los programas. Por lo tanto en una base de datos relacional se deben poder definir restricciones de integridad. Como parte de las restricciones inherentes al modelo relacional, es decir que forman parte de su definición, están: Integridad de entidad. Toda relación debe tener una clave primaria. Integridad referencial. Toda clave externa no nula debe existir en la relación donde es primaria.

4. MANIPULACIÓN DE DATOS (2,4, 5 Y 7)

Regla 2: Regla del Acceso Garantizado

Para todos y cada uno de los datos (valores atómicos) de una base de datos relacional se garantiza que son accesibles por una combinación de nombre de relación, valor de clave primaria y nombre de columna. Cualquier dato almacenado en una base de datos relacional tiene que poderse referenciar unívocamente. Para ello hay que indicar en qué relación está, cuál es la columna y cuál es la fila (mediante la clave primaria).

Regla 4: Diccionario Dinámico en Línea Basado en el Modelo Relacional La descripción de la base de datos (metadatos) está representada a nivel lógico de la misma forma que los datos ordinarios, de modo que los usuarios autorizados pueden usar el mismo lenguaje relacional para su consulta, igual que lo aplican a los datos normales. Esta es una consecuencia de la regla 1 que se destaca por su importancia. Los metadatos se almacenan usando el modelo relacional, con todas las consecuencias.

Regla 5: Regla del Sublenguaje de Datos Completo Un sistema manejador de bases de datos relacionales debe soportar varios lenguajes y varios modos de uso. Sin embargo, debe existir al menos un lenguaje cuyas sentencias sean expresables, mediante una sintaxis bien definida, como cadenas de caracteres y que sea completo, soportando: • • • • • • Definición de datos Definición de vistas Manipulación de datos (interactiva y por programa) Restricciones de integridad Autorización Restricciones de transacción (Begin, commit, rollback).

Además de poder tener interfaces más fáciles de utilizar para hacer consultas, siempre debe de haber una manera de hacerlo todo de manera textual, que es tanto como decir que pueda ser incorporada en un programa tradicional.

Un lenguaje que cumple esto en gran medida es SQL.

Regla 7: Inserción, Actualización y Borrado de Alto Nivel

La capacidad de manejar una relación base o derivada como un solo operando se aplica no sólo a la recuperación de los datos (consultas), si no también a las operaciones de inserción, actualización y borrado de datos.

Esto es, el lenguaje de manejo de datos también debe ser de alto nivel (de conjuntos). Algunas bases de datos inicialmente sólo podían modificar las tuplas de la base de datos de una en una (un registro cada vez).

5. INDEPENDECIA DE DATOS (8, 9 Y 11)

Regla 8: Independencia Física de Datos

Los programas de aplicación y actividades de la terminal permanecen inalterados a nivel lógico siempre que se realicen cambios en las representaciones de almacenamiento o métodos de acceso.

El modelo relacional es un modelo lógico de datos, y oculta las características de su representación física.

Regla 9: Independencia Lógica de Datos

Los programas de aplicación y actividades de la terminal permanecen inalterados a nivel lógico siempre que se realicen cambios a las relaciones base que preserven la información. Cuando se modifica el esquema lógico preservando información no es necesario modificar nada en niveles superiores. Ejemplo de cambios que preservan la información: • Añadir un atributo a una relación base.

Regla 11: Independencia de Distribución

El sublenguaje de manipulación de datos de un sistema manejador de bases de datos relacionales debe permitir que los programas de aplicación y las consultas permanezcan lógicamente sin cambios si los datos están físicamente centralizados o distribuidos. Las mismas órdenes y programas se ejecutan igual en una base de datos centralizada que en una distribuida.

Las bases de datos relacionales son fácilmente distribuibles: • Se parten las relaciones en fragmentos que se distribuyen. • Cuando se necesitan las relaciones completas se recombinan usando operaciones relacionales con los fragmentos. Sin embargo se complica más la gestión interna de la integridad, etc.

Esta regla es responsable de tres tipos de transparencia de distribución: • Transparencia de localización. El usuario tiene la impresión de que trabaja con una BD local. (aspecto de la regla de independencia física) • Transparencia de fragmentación. El usuario no se da cuenta de que la relación con que trabaja está fragmentada. (aspecto de la regla de independencia lógica de datos). • Transparencia de replicación. El usuario no se da cuenta de que pueden existir copias (réplicas) de una misma relación en diferentes lugares. Esta regla no dice que para ser completamente relacional el sistema manejador de base de datos debe de soportar bases de datos

REGLAS DE CODD
CLASE RS RT RB RZ RN RE RQ RJ RM RI RC RV RA RF RP RD RL RX Structure Data Types Basic operators Advenced operators Naming Commands for the DBA Qualifiers Indicators Manipulation Integrity Catalog Views Autorization Functions Protection Principles of DBMS design Principles of language design Distributed database management DESCRIPCIÓN Fund 9 3 31 2 7 8 3 0 14 11 8 8 6 3 1 8 8 0 Basic 5 6 6 42 7 14 10 14 6 23 3 0 10 7 4 8 9 29 Total 14 9 37 44 14 22 13 14 20 34 11 8 16 10 5 16 17 29

Comparación con las reglas de Codd originales (las 12):
Regla de 1985 1 2 3 4 5 6 7 8 9 10 11 12 Característica RM/V2 RS–1 RM–1 RS-13,RM-10 RC-1 RM-3 RV-4,RV-5 RM-4 RP-1 RP-2 RP-3 RP-4 RI-16 Nombre Information rule Guaranteed access Missing information Active catalog Comprehensive data sublanguage View updatability High level language Physical data independence Logical data independence Integrity independence Distribution independence Non-Subversion

DESCRIPCIÓN DE LAS CATEGORÍAS

Terminología:

Una tabla-R es Una tabla-R es un tipo especial un tipo especial de subconjunto de subconjunto No existe el No existe el concepto de concepto de posición ni posición ni duplicados duplicados

Término Matemático Relación de grado n Atributo Dominio Tupla Cardinalidad de una relación

Término en la Base de Datos tabla-R con n columnas Columna de una tabla-R Tipo de datos extendido Fila en una tabla-R Número de filas en una tabla-R

RS - ESTRUCTURA

• Estas reglas se refieren a la estructura del SGDBR, en general estas reglas indican que la información contenida en la base de datos puede ser vista por los usuarios y por los programadores de la aplicación y estos no necesitan saber conceptos posicionales en la base de datos, es decir, a un usuario no le importa en donde esta almacenada la información o cual es el primer registro o el último; si una fila es movida a otro tipo de almacenamiento, el usuario lo percibe como si no se hubiese cambiado. • En estas reglas también se prohíbe la duplicidad de filas en cualquier relación, ya sea tabla, vista o algún derivado. • También nos hablan de la llaves primarias y foráneas.

RT – TIPOS DE DATOS EXTENDIDOS

• Son reglas que todo SMBDR debe cumplir y se refieren al manejo de los datos de fecha, hora y moneda. • Todo SMBDR debe soportar fechas, tiempo de reloj y moneda como tipos de datos extendidos y en todo momento se debe tener acceso a la fecha y hora actual. • Los componentes de fecha (DD/MM/AA) pueden ser tratados por separado al igual que los componentes de hora (HH:MM:SS). • El SMBDR soporta la conversión de fecha y hora de cualquier zona horaria a fecha y hora Greenwich y viceversa; soporta monedas no negativas pero no necesariamente soporta la conversión automática de monedas de diferentes países.

RB – OPERADORES BÁSICOS

Estas reglas se refieren al manejo de los operadores básicos como son: • el producto cartesiano, la proyección, el operador select haciendo uso de todos sus comparadores (por ejemplo: <, >, =, <=, >=,por mencionar algunos), la extensión booleana del select como es el uso de los operadores and, or, not, el uso del join, unión, operadores como intersección, diferencia, división, asignación, inserción, actualización y borrado .

RZ – OPERADORES AVANZADOS

Estas reglas hacen referencia a los operadores avanzados que utilizan los SMBDR. Algunos operadores son: • Delimitador o frame, joins entre 2 o mas relaciones, incluyendo todos los operadores relacionales (<, >, =, <=, >=, etc), joins internos, externos, izquierdos y derechos, unión, diferencia, intersección, inserción, actualización, borrado, etc.

RN – REGLAS DE NOMBRAMIENTO

• Todos los dominios deben tener asignados nombres que sean distintos el uno del otro y distintos de los nombres de relaciones y funciones. Todas las relaciones y todas las funciones definidas por el usuario deben tener asignados nombres que sean distintos el uno del otro y distintos de los dominios, tipos de datos y columnas. • También se menciona en estas reglas la nomenclatura de las columnas de resultados ya sea al aplicar algún operador o alguna función.

RA – AUTORIZACIÓN

• Este conjunto de reglas describe la forma en que un SMBD debe realizar los permisos a la base de datos, define los tipos de permisos, la autorización de acciones, el bloqueo por registro, renglón o columna, el ámbito de los permisos, la forma de asignar y revocar los permisos, etc.

RF – FUNCIONES ESCALARES Y DE AGREGACIÓN

• Este conjunto de reglas describe los dos tipos de funciones escalares (como las funciones de manipulación de fechas) y de agregación (funciones de conteo de registros, suma, promedio, máximos y mínimos) que un SMBD debe de tener para la manipulación de registros y columnas, así también describe la forma en que deben tratarse las funciones definidas por el usuario.

RP – PROTECCIÓN FÍSICA

• Estas reglas describen cómo un SMBD debe proteger la inversión que una empresa o institución hace por su uso. Dichos temas de los que trata esta regla se refieren a la protección física y lógica de los datos, así como a la independencia de integridad y de distribución de los datos.

RD – PRINCIPIOS DE DISEÑO DE SMBD

• Estas reglas describen cuales son los principios básicos de diseño que un SMBD debe contemplar, como la no violación de las leyes fundamentales de las matemáticas en las cuales se basa el modelo relacional, la capa de presentación de acceso, la independencia de concurrencia, la protección y bloqueos de accesos no autorizados, los índices basados en el dominio, las estadísticas de la base de datos, la forma de tratar los datos, etc.

RL – DISEÑO DE LENGUAJES RELACIONALES

• Estas reglas describen qué factores se deben de tomar en cuenta para el diseño de un lenguaje relacional, entre esos factores describe a la variedad de usuarios incluyendo a los programadores, la forma en que deben de compilarse y re-compilarse los programas que se realicen con este lenguaje, las reglas para el ámbito de las instrucciones, y entre otros temas los bloques delimitadores de múltiples comandos como el BEGIN y el END.

RX – ADMINISTRACIÓN DE BD DISTRIBUIDAS

• Este conjunto de reglas describe la forma en que un SMDB debe ser autónomo para poder distribuir los datos en varios sitios, la forma en que deben de estar organizados los catálogos que definen la estructura de la base de datos, el nombrado de las reglas, la forma en que deben ser nombrados los objetos en una base de datos distribuida, la redistribución y reversibilidad de transacciones, las reglas de integridad para la distribución de las vistas y datos, etc.

RE – COMANDOS PARA EL ABD

• Estos son orientados para el uso del administrador de la base de datos (ABD). Se enfocan en la estructura de la base y en la administración de la información, realiza cambios en la estructura de los dominios, renombra, elimina, agrega y modifica las características de las columnas de una tabla-R. Se especifican el manejo de los índices, de su creación y eliminación, la existencia de un comando para el control de las filas duplicadas. Establece la existencia de comandos para la carga de información en la base de datos así como su respectiva exportación a un tipo determinado de archivo.

RQ – CALIFICADORES

• Un calificador o modificador es una expresión que puede usarse en un comando para alterar algún aspecto de la ejecución de dicho comando. En este contexto hablamos de los comandos relacionales. El interés de estas reglas está en la administración de la base de datos.

RM – MANIPULACIÓN

• Las reglas de manipulación se enfocan en las capacidades y en las propiedades generales del lenguaje relacional, sin especificar sus características y su sintaxis. Se especifica que el acceso a los datos debe estar garantizado en una lógica accesible por una combinación adecuada de propiedades. Establece las características principales del lenguaje relacional de datos, sentencias de alto nivel referentes a actualización, inserción y borrado de información, los efectos de la aplicación de operadores aritméticos sobre valores ausentes (aplicables o inaplicables) y la manipulación de la información que contiene valores ausentes.

RI – INTEGRIDAD

• Se establecen los tipos de restricciones (constraints) que un SMBD debe soportar usando declaraciones expresadas en lenguaje relacional. Estas reglas se refieren a las especificaciones que una restricción debe aplicar, las respuestas que se dan a un intento de violación a la integridad de la restricción, determinación de la aplicabilidad y el almacenamiento de su definición. Especifica las definiciones de usuario referentes a los valores de la base de datos así como el manejo de los tipos de datos marcados (Mark A y Mark I, ausentes aplicable y ausente no aplicable).

RC - CATÁLOGO

• Los catálogos según las reglas de Codd es una parte muy importante en un SMBD ya que establecen parte de las características del sistema como puede ser la concurrencia que debe poseer ya que los SMBD son usados generalmente en red con varios usuarios a la vez, además de que acumula toda la información de las estructuras utilizadas, como por ejemplo para las tablas-R establece 10 puntos que se deben especificar en su creación para su correcto almacenamiento. Establece la descripción de las vistas, la descripción de las columnas (Cómo se almacenan en el catálogo y qué puntos se deben especificar). Establece que en los catálogos se deben especificar las características de los datos autorizados y como regla también se tiene que en el catalogo se tienen las estadísticas.

RV – VISTAS

• Las vistas están diseñadas para intentar aislar a los usuarios, incluyendo a las aplicaciones de los programadores, de la base relacional. Permitiendo (1) cambios a realizarse en la definición de las relaciones de la base (2) Los cambios correspondientes en la definición de la vista, en tal caso almacenar las vistas que no se cambiaron según el contexto. Las vistas permiten al usuario percibir la base de datos en términos de las relaciones derivadas que directamente pertenecen en las aplicaciones. Las vistas también pueden ser usadas para restringir el acceso a la totalidad de los datos de la base y establecer que con la debida autorización un usuario tenga acceso a determinadas vistas.

RS-1 – CARACTERÍSTICAS DE LA INFORMACIÓN

• El SGBD requiere que toda la información de la base de datos pueda ser vista por los programadores de aplicación y usuarios interactivos en las terminales en términos de valores por relaciones y de ninguna otra manera en las relaciones base. Exactamente una manera adicional está permitida en relaciones derivadas llamada, ordenamiento por valores dentro de la relación.

Características Orientadas a la Estructura y a los Datos

RS-1 – LA INFORMACIÓN

• Para las relaciones base el SMBD requiere que toda la información de la base de datos que pueda ser vista por los programadores de aplicaciones y usuarios interactivos en las terminales esté explícitamente en términos de valores en relaciones, y no de otra forma.
•Las relaciones base son aquellas que estan •Las relaciones base son aquellas que estan representadas internamente por datos representadas internamente por datos almacenados en alguna forma definida por la almacenados en alguna forma definida por la implementación, de otra forma son llamadas implementación, de otra forma son llamadas relaciones derivadas, como las vistas que se relaciones derivadas, como las vistas que se crean aapartir de las primeras sin contener crean partir de las primeras sin contener datos. datos.

RS-2 – LIBRES DE CONCEPTOS POSICIONALES

• El SMBD protege a los programadores y a usuarios finales contra tener que saber conceptos posicionales en la base de datos.

RS-3 - NO DUPLICIDAD DE FILAS EN RELACIONES

• El SMBD prohíbe la ocurrencia de filas duplicadas en cualquier relación (base, vista o derivado), y de esta manera protege al usuario de las complejidades sutiles y lo poco optimizable de la base de datos que resultan como consecuencia de permitir el uso de filas duplicadas.

RS-4 Portabilidad de la Información

RS-4 – PORTABILIDAD DE LA INFORMACIÓN

• Si una fila de una tabla-R es movida por el SMBD, el contenido de su información tal como es percibida por el usuario permanece sin cambio alguno, y por lo tanto no necesita ser cambiada. La información tal como es percibida por los usuarios, no debe depender del equipo o ubicación en que se encuentren los datos.

RS-5 – ARQUITECTURA EN 3 NIVELES

• Un SMBD relacional tiene una arquitectura de tres niveles que consiste en vistas, relaciones base y la representación de datos al ser almacenados.

Término ANSI
Esquema externo Esquema conceptual Esquema interno

Término-R
Vistas Relaciones base Representación al almacenar

RS-6 - DOMINIOS COMO TIPO DE DATO EXTENDIDO

• Cada dominio que semánticamente es diferente, debe ser nombrado en forma diferente y debe ser definido por separado de la declaración de la tabla-R (ya que puede ser usado en mas de una tabla-R). • Cada dominio se declara como un tipo de datos extendido, no como un simple tipo de datos básico.

RS-7 – DESCRIPCIÓN DE COLUMNAS

• Por cada columna de cada tabla-R, debe haber la capacidad de declarar (1) el dominio a utilizar en aquella columna (de forma que se pueda identificar el tipo de datos extendido) y (2) las restricciones adicionales, si es que las hay, que se deben aplicar a los valores de dicha columna.

RS-8 – UNA LLAVE PRIMARIA EN CADA TABLA-R BASE

• En todas y cada una de las tablas-R base, el SMBD debe requerir que sea declarada una y sólo una llave primaria. En todo momento los valores almacenados en una columna (en forma simple o compuesta) deben ser diferentes entre sí. En ningún momento se debe permitir que falte algún valor en una columna que componga la llave primaria. • No debe tener nulos en un atributo o en un conjunto de atributos que componen la llave primaria.

RS-9 – LLAVE PRIMARIA EN ALGUNAS VISTAS

• Para cada vista, el SMBD debe soportar la declaración de una sola llave primaria siempre que el ABD observe que la definición de esta vista así lo permita, sin ignorar la caracteristica de entidad-integridad (RI-7). En lo posible, el SMBD debe verificar que la declaración de una llave primaria de una vista sea consistente con las declaraciones de la llave primaria de las tablas-R base que la componen.

RS-10 – LLAVE FORANEA

• El SMBD permite la declaración de cualquier columna o combinación de columnas de la tabla-R base como una llave foránea (donde sea semánticamente aplicable). Generalmente se incluye en esta declaración las llaves primarias destinadas (usualmente es sólo una) para esta llave foránea. Sin embargo, el SMBD no debe, con su diseño, obligar a que sólo una llave primaria sea dada para una llave foránea, a pesar de que muy frecuentemente ocurre el caso de que esto se de.

RS-11 – DOMINIOS COMPUESTOS

• Se puede declarar un nombre a una combinación de dominios simples, tomando en cuenta que este nombre es distinto de cualquier otro dominio (simple o compuesto). La secuencia en la cual los dominios aparecen en esta declaración es parte del significado de la combinación.

RS-12 – COLUMNAS COMPUESTAS

• Se puede declarar un nombre a una combinación de columnas en una tabla-R base o en una vista, siempre y cuando ese nombre sea distinto del de cualquier otra columna (simple o compuesta) de esa tabla-R y siempre y cuando se haya declarado un dominio compuesto para los valores de esta columna compuesta. El orden de las columnas que conforman esta columna compuesta es parte de su significado, y debe corresponder exactamente con el orden de los dominios que forman el dominio compuesto correspondiente.

RS-13 – INFORMACIÓN FALTANTE REPRESENTADA

• En toda la base de datos, el hecho de que falte algún valor es representado de la misma forma y en forma sistemática, independientemente del tipo de dato faltante. • Se utilizan “marcas” con este fin.

RS-14 – EVITANDO LA RELACIÓN UNIVERSAL

• Ni la agrupación de todas las relaciones base, ni la agrupación de todas las vistas, debe verse como una “relacion universal” (como es definida por la universidad Stanford). Sin embargo el ABD debe poder crear dicha relación como una vista mas.
•Moshe Y. Vardi habla sobre la “relacion universal” en su •Moshe Y. Vardi habla sobre la “relacion universal” en su artículo de 1988 llamado “The universal-relational data model artículo de 1988 llamado “The universal-relational data model for logical independence” buscando una forma para lograr que for logical independence” buscando una forma para lograr que si hay una modificación en la base de datos (ej. porque dos si hay una modificación en la base de datos (ej. porque dos tablas se convierten en una sola) no sea necesario modificar tablas se convierten en una sola) no sea necesario modificar la aplicación, yyno se haga por medio de crear Vistas la aplicación, no se haga por medio de crear Vistas innecesarias desde el principio peviendo posibles innecesarias desde el principio peviendo posibles modificaciones futuras. modificaciones futuras.

Operadores Básicos

RB-1 – REDUCIR EL ÉNFASIS EN EL PRODUCTO CARTESIANO COMO OPERADOR

• Un SMBD relacional no debe soportar el producto cartesiano como un operador explícitamente separado. Sin embargo un comando relacional podría tener un caso extremo que sea interpretado como la petición de hacer un producto cartesiano.

RB-2 – EL OPERADOR PROYECCIÓN

• El operador proyección emplea una sola tabla-R como su operando. El operador genera un resultado intermedio en el cuál las columnas listadas por nombre en el comando son salvadas y las columnas omitidas en el comando son ignoradas. • De esta tabla-R se genera el resultado final, removiendo todas las ocurrencias excepto una de cada fila que ocurre mas de una vez.

Buscando aplicar la proyección de ENAME, BIRTH_DATE, SALARY, CITY Sobre la tabla:

RB-3 a 12 – EL OPERADOR THETA-SELECT

• El operador theta-select originalmente llamado theta-restrict emplea una sola tabla-R como su operando. En su uso normal, el termino theta-select es abreviado como select y esto significa que el comparador de igualdad ‘=’ debería ser asumido a menos que exista un comparador alternativo explícito especificado. Esto genera como resultado una tabla-R que contiene algunas de las mismas filas completas que el operando contiene (las filas que satisfacen la condición expresada en el comando). Para distinguir el theta-select del comando select de SQL, podemos referimos explícitamente al theta-select como un select algebráico y referirnos explícitamente al select de SQL como select de SQL. Es importante recordar que el operando no contiene filas duplicadas y por lo tanto tampoco el resultado.

1) RB-3 Igualdad 2) RB-4 Desigualdad 3) RB-5 Menor que 4) RB-6 Menor o igual que 5) RB-7 Mayor que 6) RB-8 Mayor o igual que 7) RB-9 El más grande que sea menor que 8) RB-10 El más grande que sea menor o igual que 9) RB-11 El más chico que sea mayor que 10)RB-12 El más chico que sea mayor o igual que

RB-13 – EXTENSIÓN BOOLEANA THETASELECT
• Sea R una relación con columnas simples o compuestas que incluyen la columna A y la columna B. Sea @ uno de los 10 comparadores usados en el theta-select, y sea x una variable o constante en un lenguaje de computadora. • Suponiendo que: R [ A @ x ] y R [ A @ B ] denotan operaciones theta-select, Entonces: A @ x y A @ B son llamadas términos de comparación cada término de comparación tiene un valor de verdad.
•Los valores de verdad pueden ser •Los valores de verdad pueden ser cualquier combinación de los términos de cualquier combinación de los términos de comparación utilizando los conectores comparación utilizando los conectores lógicos NOT, OR, AND eeIMPLICA lógicos NOT, OR, AND IMPLICA

RB-14 a 23 – OPERADOR THETA-JOIN

• Emplea 2 tablas-R como sus operandos. Esto genera como resultado una tabla-R que contiene filas de un operando concatenado con filas del segundo operando, pero sólo donde la condición específica verdadera es encontrada. Para simplificar, siempre se hace referencia a este operador con el nombre join.

•Se puede usar cualquiera de los 10 •Se puede usar cualquiera de los 10 operadores lógicos vistos previamente operadores lógicos vistos previamente

RB-24 – EXTENSIÓN BOOLEANA THETAJOIN

• Sean R, S relaciónes con columnas simples o compuestas que incluyan a R.B y S.C. Suponga que R.B y S.C trazan sus valores en un dominio común. Sea @ uno de los Operadores de comparación usados en theta-join. • Suponiendo que R [B @ C] S denota una operación theta-join. Entonces B @ C es llamado un termino de comparación, y cada termino de comparación es un valor de verdad.
•Los valores de verdad pueden ser cualquier combinación de •Los valores de verdad pueden ser cualquier combinación de los términos de comparación utilizando los conectores lógicos los términos de comparación utilizando los conectores lógicos NOT, OR, AND eeIMPLICA NOT, OR, AND IMPLICA

RB-25 – EL OPERADOR DE JOIN NATURAL

• Un equi-join genera un resultado en el cual dos de las columnas son idénticas en valores, aunque con nombres de columnas diferentes. Estas dos columnas se derivan de la comparación de columnas de los operandos (ya sean columnas simples o compuestas). De los 10 tipos del theta-join, equi-join es el único que arroja un resultado en el cual dichas columnas son redundantes por completo. El join natural se comporta exactamente como el equi-join excepto que una de las columnas redundantes, simple o compuesta, es omitida en el resultado. Para hacer que el nombre de la columna sea claro y respetar la conmutatividad entre las columnas, la columna de comparación que se quede en el resultado recibirá el nombre de la que aparezca primero alfabéticamente, de las dos posibilidades.

RB-26 – EL OPERADOR DE UNIÓN

• Intencionalmente no es tan general como el operador de unión en matemáticas, el cuál permite formación de la unión de un conjunto de construcciones con un conjunto de partes con un conjunto de empleados, por ejemplo. En cambio la unión relacional permite solamente la unión de construcciones con construcciones, partes con partes o empleados con empleados, siguiendo el mismo ejemplo. (los operandos que cumplen con esta característica son union-compatibles).

RB-27 – OPERADOR DE INTERSECCIÓN

• Suponga que S y T son dos relaciones unión-compatibles. Entonces, son suficientemente compatibles una con otra para que el operador de intersección sea aplicable. Las columnas deben ser alineadas de la misma forma que deben ser alineadas para el operador unión. El resultado de aplicar la intersección a la relación S y T es una relación que contiene sólo aquellas filas de S que también aparezcan en T. Por supuesto, el resultado de la relación no contiene filas duplicadas.

RB-28 – OPERADOR DIFERENCIA

• Suponga que S y T son dos relaciones unión-compatibles. Entonces, ellas son suficientemente compatibles para aplicar el operador diferencia. Las columnas deben ser alineadas en la misma forma en que deben ser alineadas para aplicar el operador unión. El resultado de aplicar la diferencia relacional a las relaciones S y T es una relación que contiene sólo aquellas filas de S que no aparezcan como filas de T. Por supuesto, la relación resultante no contiene filas duplicadas.

RB-29 – OPERADOR DIVISIÓN RELACIONAL

• La división relacional es similar en algunos aspectos a la división aritmética. En la división relacional, tal como en la división aritmética hay un dividendo, un divisor, un cociente, e incluso un residuo. Es decir, la división relacional tiene operadores y resultados muy similares a la división matemática. Sin embargo, en vez de manejar enteros, maneja relaciones. Ninguna de dichas relaciones requiere información numérica en absoluto, e incluso si la tuviera, no deben ser los componentes que jueguen un papel crucial en la división relacional.

RB-30 – ASIGNACIÓN RELACIONAL

• Cuando se consulta una base de datos, el usuario deseará tener el resultado de la consulta (una relación) almacenada en memoria bajo el nombre de su elección. El usuario también podría desear que esta relación almacenada, participe en alguna consulta relacional posterior o una actividad de manipulación. Ambas peticiones son satisfechas en una extensión certera por la asignación relacional. Este operador es denotado por  en la expresión T  rve, donde (1) rve denota una expresión relación-valor (una expresión cuya evaluación produce una realación), y (2) T denota un nombre de usuario-seleccionado para la relación que es especificada por rve y que es almacenada en memoria.

RB-31 – OPERADOR INSERT

• El operador insert permite una colección de una o más filas sean insertadas dentro de una relación. Sin embargo, el usuario no tiene control sobre donde van las filas insertadas. Pueden aún ser agregadas por el SMBD “al final o en otro sitio” de la relación principal. La frase se indica entre comillas porque no hay concepto para el final de una relación en el modelo relacional. Esta es responsabilidad sólo del SMBD determinar exactamente en donde deberían estar almacenadas las filas, aunque esta posición pueda ser afectada por las rutas de acceso ya declaradas por el ABD para aquella relación. Se asume que, para la inserción de nuevas filas dentro de una relación T, el catalogo ya contiene una descripción detallada de T.

RB-32 – OPERADOR UPDATE

• Administrando una base de datos, ocasionalmente puede ser necesario cambiar los valores de uno o más componentes de una o más filas que ya existen dentro de una relación. Usualmente se distingue de insertar por completo nuevas filas porque los componentes que su valor cambia llegan a representar un porcentaje muy pequeño del número de componentes en cada fila.

RB-33 – ACTUALIZACIÓN DE PK CON CASCADA

• Rara vez es necesario actualizar el valor de la llave primaria, pero cuando es necesario es importante que se haya hecho correctamente. De otro modo, la integridad en la base de datos puede ser perdida y esta puede ser relativamente difícil de recuperar.

RB-34 – ACTUALIZACIÓN DE PK MARCANDO FKs

• Este operador se comporta de la misma forma que la de la característica RB-33, en vez de actualizar los valores de las llaves foráneas, el SMBD marca cada valor de la llave foránea como ausente-pero-aplicable. Si una o más llaves foráneas esta declarada entonces el valor ya no tiene el estatus de ausente, entonces el comando es por completo rechazado por el SMBD.

RB-35 – OPERADOR DELETE

• El operador delete permite a un usuario borrar múltiples renglones; de una relación “múltiple” incluye los casos especiales de cero y uno, y estos casos no reciben un trato especial. Porque incluye el cero como una posibilidad. Una razón es que esa condición donde el usuario tiene incorporado el comando delete puede no satisfacer a ningún renglón. Por supuesto, es necesario para el usuario especificar la relación pertinente e identificar los renglones a ser borrados en cualquiera de las dos formas permitidas por el operador update.

RB-36 – BORRADO CON CASCADA

• Esto operador de borrado es similar al descrito en regla RB-35, excepto que se tiene que tomar en cuenta que un componente simple o compuesto de cada una de las filas siendo suprimidas resulta ser el valor de la llave primaria de una relación base. Esto es verdadero incluso si la tachadura es ejecutada por una vista (relación virtual). Así, la ejecución de RB-35 a menudo violará la integridad referencial. Ya que la integridad de referencia por lo general no es comprobada totalmente hasta el final de una transacción, esta violación puede ser solamente un estado transitorio dentro de la transacción.

RB-37 – BORRADO EN CASCADA Y DELETE OPCIONAL DEL HERMANO

• Este operador es similar a la regla RB-36, pero es mucho menos peligroso, porque el ciclo inicial de caída secuencial no provoca el disparo de ciclos subsecuentes. Esto reduce el peligro y es una razón fuerte por la que debería permitirse llaves foráneas con valores que fallen, a no ser que el DBA tenga una razón importante para que esto no se justifique.

Operadores Avanzados

RZ-1 – DELIMITANDO UNA RELACIÓN

• Un marco separa un conjunto de renglones dentro de cualquier partición del conjunto de renglones en cualquier otro miembro. Esta separación se realiza agregando una nueva columna a la relación en la relación y, con esta columna, asignar un valor distinto para cada miembro distinto de la partición. El nombre estándar para esta columna es FID o identificador de marco.

RZ-2 – EXTENDER LA DESCRIPCIÓN DE UNA RELACIÓN PARA INCLUIR COLUMNAS DE OTRA

• La relación citada primero en el comando es única cuya descripción es alterada para incluir todas las columnas de la segunda relación citada que no esté en la primera. • Las columnas de esta manera introducidas en la primera relación son llenados de valores marca-A, a menos que el calificador VALUE RQ-13 es aplicado para especificar un valor particular.

RZ-3 a 12 – SEMI-THETA-JOIN

• Suponga que los operandos de un theta-join son S y T, donde theta es una de las 10 operadores de comparación (=, <>, <, <=, >, >=, G<, G<=, L>, L>=), y las columnas a ser comparadas son la columna A simple o compuesta de S con la columna B simple o compuesta de T. Suponga que la relación T es proyectada sobre de la columna B. El resultado de esta proyección contiene sólo aquellos valores de B que son distintos de la otra. El semijoin de S sobre A con T sobre B produce esa subrelación de S cuyos valores en la columna A están restringidos para sólo esas que califica de acuerdo con el comparador theta con respecto a la proyección de T sobre B.

RZ-13 – LEFT OUTER EQUI-JOIN

• La reunión externa izquierda (left outer equi-join) de S sobre B con T sobre C, denotada por U = S [ B / = C) T, está definida en términos de la reunión interna (inner equijoin o IEJ) y el incremento izquierdo externo (left outer increment o LOI). LOI esta definido como sigue: seleccionar aquellas tuplas de S cuyos valores a comparar están en la columna S a comparar. B no participan en la reunión interior, y añaden a cada tupla una tupla vacía pero de valores ausentes y tamaño compatible con T.

RZ-14 – RIGHT OUTER EQUI-JOIN

• La reunión externa derecha (right outer equi-join) de S sobre B con T sobre C, denotada por V = S [B = \ C] T, está definida en términos de inner equi-union (IEJ) y el incremento derecho externo (ROl). ROl está definida como sigue: selecciona aquellas tuplas de T cuyos valores a comparar están en la columna T. Y no participa en la reunión interna, y añaden a cada tupla una tupla vacia pero de valores ausentes y tamaño compatible con S.

RZ-15 – EQUI-JOIN EXTERNOS SIMÉTRICOS

• La reunión externa simétrica (symmetric outer equijoin) de S sobre B con T sobre C, denotada W = S [ B / = \ C ] T, está definida por W = LOI union IEJ union ROI. Esto implica que W = U union V.

RZ-16 – LEFT OUTER NATURAL JOIN

• Primero, se forma el equi-join natural interno W de S sobre A con T sobre B. Entonces, se forma la diferencia relacional W1 = S - W [P, A]. Entonces, extendemos W1 a través de S para producir W2. Finalmente, se forma la left outer natural union LONJ = W union W2

RZ-17 – RIGHT OUTER NATURAL JOIN

• Primero, se forma la inner natural equi-join W de S sobre A con T en B. Después, se forma la diferencia W3 = T - W [A, Q]. Entonces, se extiende W3 a S para formar W4. Finalmente, se forma la right outer natural union RONJ = W union W4.

RZ-18 – SYMMETRIC OUTER NATURAL JOIN

• Primero, se forma W y W2 como en los tres primeros pasos de la regla : RZ-16. Entonces, se forma W4 como en los tres primeros pasos de la regla RZ-17. Finalmente, se forma la symmetric outer natural union, tomando la unión: SONJ = W2 union W union W4. O bien, la symmetric outer union = LONJ union RONJ. Note que la union en el modelo relacional siempre incluye el retiro de las filas duplicadas de el resultado.

RZ-19 – OUTER UNION

• Suponga que los operandos de outer union son la S y la T. Como primer paso aplicamos el operador extend tanto a la S como a la T: extend S per T y llamamos esto St: extend T per S y llamamos esto Ts. Ahora, St y Ts son del mismo grado, y cada uno contiene columnas basadas en todos los dominios en S y todos los dominios en T. De hecho St y Ts son completamente compatibles en la unión. Como el paso segundo y final, se forma St union Ts, que producen outer union S \ U / T.

RZ-20 – OUTER SET DIFFERENCE

La outer set difference S \ - / T entre las relaciones S y T, con S como la fuente información y T como la relación reducida. Esta generada por medio de los siguientes pasos: Se forma St = S per T; Se forma Ts = T per S; Se forma la semi-equi-join U = S[sem=] Ts; Se forma S \ - / T = St – U.

• • • •

RZ-21 – INTERSECCIÓN INTERNA DETERMINADA

• Se representa por: S \ ∩/T

RZ-22 a 25 – UNIONES – T INTERNOS

• Las 4 uniones internas están basadas en los comparadores: Menor, menor o igual, mayor y mayor o igual.

RZ-26 a 37 – UNIONES – T EXTERNAS
• La unión externa T de relaciones S sobre A con T sobre B consiste en la unión-T U de S sobre A con T sobre B, juntos con los conjuntos adicionales de tuplas, llamado incrementos externos. La unión interior T de S sobre A con T sobre B se denota: V = S [[ A @ B ] ] T , donde @ espera uno de los cuatro ordenamientos de comparación. S es llamada el operador izquierdo y T el operador derecho. Hay dos incrementos externos claramente definidos. Para construir el incremento izquierdo externo, recoja aquellas tuplas del operando izquierdo S que no resulta participar en la unión T interior; a cada uno de estos, añada un número suficiente de valores marcados para indicar que el valor de cada componente de una tupla de T. Para construir el incremento derecho externo, recoja aquellas tuplas del operando derecho T que no participen en la unión T interior; a cada uno de estos, añada un número suficiente de valores para indicar que el valor de cada componente de una tupla de S.

RZ-38 – SELECT DEFINIDO POR EL USUARIO • Este operador está denotado: S [ i; p(A); t ] Donde: i es el valor inicial de la función (opcional) p es la función de evaluación (requerido) t es terminador de la función (opcional) El argumento A de la función p denota una o mas columnas simples de la relación S. Sin embargo, un valor verdadero de p(A) puede ser computado por algunas filas usando solamente componentes de A de esas filas. Si A es una colección de columnas, mas de un componente de cada fila es involucrado.

RZ-39 – UNIÓN DEFINIDA POR EL USUARIO

• La unión definida por usuario es más poderosa que las uniones empotradas. Esto contiene una fila de una relación con una fila del otro siempre que una función definida por usuario p transforme los componentes especificados de estas filas en el valor de verdad VERDADERO. De ser incluido en la orden, la función que inicializa es ejecutada a la terminación y al principio mismo de la unión antes de que cualquier fila del primer operando sea encadenada con cualquier fila del segundo operando. Las versiones temporales de los operandos son entregadas como el resultado de ejecución. De ser incluido en el comando, la función que se termina es ejecutada al final mismo de la unión en el punto que todas las filas que deben ser encadenado han sido encadenados.

RZ-40 – UNIÓN RECURSIVA

• La unión recursiva es un operando con el operando. Este operando es una relación que representa un gráfico dirigido. Una de las columnas de esta relación juega un papel subordinado (SUB), mientras el otro juega un superior (SUP) papel. Cada tupla representa un borde de un gráfico dirigido, y según la convención este borde es dirigido del nodo identificado por el componente de SUP abajo al nodo identificado por el componente SUB. Como las uniones normalmente son aplicadas a los pares de relaciones, es conveniente pensar en el operando solo como 2 relaciones idénticas. La unión recursiva es como este par de relaciones idénticas por corresponder cada SUB valor en un operando a un valor del segundo operando. Esto es en todos los pares de identificadores para los nodos que son unidos por relaciones en un gráfico cíclico, no importan las longitudes de la relaciones.

RZ-41 – OPERADOR SEMI-INSERT

• Una inserción en la T en el acto f representada por un semi-tupla es solicitada. El SMBD examina la mitad pertinente de T para ver si la f ya se encuentra ahí. Si la f esta en la T, el SMBD rechaza la petición. Si no, el SMBD asocia la f con una existencia que aparea el hecho que resulta tener su otra mitad por omisión, si ningún punto está disponible, crea tal punto haciendo una copia que satisfactoriamente puede unirse.

RZ-42 – OPERADOR SEMI-UPDATE

• Una actualización es solicitada lo que debe ser aplicado a un hecho que es representado por una semi-tupla de T. Si el SMBD es capaz de encontrar al menos una semi-tupla la cual pertenezca, se procede a actualizar cada copia que exista. Si el SMBD es incapaz de encontrar tal semi-tupla, es rechazada la petición.

RZ-43 y 44 – SEMI-ARCHIVE Y SEMIDELETE

• El DBMS comprueba para considerar si el hecho ser archivado o suprimido ocurra en más de un semi-tuple de T. Si es así como paso 1, almacena o elimina todas las filas de T(excepto una fila) en el cual el ocurre el hecho. Como paso 2, el SMBD marca como faltantes los componentes de un semi-tuple restante de T. Si en el comienzo el hecho que se archivará o suprimido ocurre solamente una vez, se omite el paso 1 y se ejecuta el paso 2. Si el hecho que se archivará o será suprimido no ocurre en T, el SMBD rechaza la petición

MANEJO DE INFORMACIÓN FALTANTE EN MR V2

• Clasificación de información faltante por tipo y por razón
Ausente Tuplas completas
No-eventos Eventos desconocidos para el SMBD Eventos no aplicables Aplicable (Marca-A)

Valor-de-BD
No aplicable (Marca-I) Otro

•Valor de BD: Valor elemental de la base de datos. Es cualquier valor que una •Valor de BD: Valor elemental de la base de datos. Es cualquier valor que una sola columna puede tener en una relación. (Excepto en ciertas funciones sola columna puede tener en una relación. (Excepto en ciertas funciones específicos es un valor atómico) específicos es un valor atómico)

• Valor-de-BD: Valor elemental de la base de datos. Es cualquier valor que una sola columna puede tener en una relación. (Excepto en ciertas funciones específicos es un valor atómico). • MARCAS:

– Anteriormente se conocían como “valores nulos”. – El SMBD no las trata como valores, ni como variables. – Sin embargo podrían ser tratadas como algún tipo de valor por el lenguaje anfitrión.
• Marca-A: Marca de valor ausente, pero aplicable. • Marca-I: Marca de valor no aplicable.

Se debe dejar de usar el término “valor nulo” por las siguientes razones: 1. 1. El SMBD no maneja las marcas como si fueran valores. Ahora hay dos tipos de marcas, donde antes solamente existía una. Algunos lenguajes anfitriones manejan objetos llamados “nulos” que su significado es algo muy distinto a las marcas en la base de datos. En inglés es un término mas adecuado.

1.

1.

• Las marcas no son tratadas como valores. Por ejemplo si la columna es de tipo numérica, no se permite incrementar o decrementar aritméticamente una marca, aun que al resto de los valores si. • Si x es un Valor-de-BD, I es una Marca-I y A es una Marca-A:

x + x = 2x A+A=A I+I=I

x+A=A A+I=I x+I=I

A+x=A I+A=I I+x=I

• Existen tablas muy similares para la resta, multiplicación y división, excepto que las operaciones solamente entre Valores-de-BD entregan el valor aritmético según la operación.

• En cuanto a las cadenas de caracteres, no se puede concatenar nada a una marca. • Existe también una tabla similar a la de la suma con marcas. Dichas tablas se pueden resumir así:

Si decimos que las Marcas-I son de primera clase, las Marcas-A son de segunda clase y los Valores-de-BD son de tercera clase, la combinación (aritmética o de otra forma) de cualesquiera dos elementos entrega un elemento del tipo de mayor clase presente en los operandos.

PK Y FK EN RELACIONES BASE

• Una regla importante es que en una BD relacional, para mantener integridad, nunca se almacena información de un objeto no identificado (o identificado en forma no adecuada). Es por eso que no se permite que las llaves primarias contengan marcas (de ninguno de los dos tipos) -> integridad de entidad. • En el caso de las llaves foráneas debe ser posible exclusivamente asignar Marcas-A, o algún valor que preserve la restricción de integridad referencial.

FILAS CON MARCAS-A Y/O MARCAS-I

• Cualquier fila que contenga solamente Marcas-A y/o Marcas-I debe ser eliminada de la relación por el SMBD. (RI-12) • Dicha fila no presenta información para ninguna relación derivada, ya sea vista, consulta, “snapshot”, etc.

APLICACIÓN DE IGUALDAD

• Igualdad semántica: El significado participa fuertemente Por ejemplo: Si el atributo Fecha_Nacimiento tiene Marca-A, y se evalúa: Fecha_Nacimiento > 1966-1-1 ¿es verdadero? ¿es falso? • Igualdad simbólica (o formal): El significado es ignorado

LÓGICA DE 3 VALORES DEL RM/V2 (RM V1) • El valor nulo representa un “tal vez” (maybe)

P v m f

not P f m v

• El valor nulo representa un “tal vez” (maybe)

P۷Q P v m f not P f m v v P m f

v v v v

Q m f v v m m m f

• El valor nulo representa un “tal vez” (maybe)

P۷Q P v m f not P f m v v P m f

v v v v

Q m f v v m m m f

Q P٨Q v m v v m P m m m f f f

f f f f

LÓGICA DE 4 VALORES DEL RM/V2 (RM V2) a = Marca-A, i = Marca-I

P v a i f

not P f a i v

a = Marca-A, i = Marca-I

P v a i f

not P f a i v

P۷Q

Q a i f v v v a a a a i f a f f

P

v v v a v i v f v

a = Marca-A, i = Marca-I

P v a i f

not P f a i v

P۷Q

Q a i f v v v a a a a i i a I f

P

v v v a v i v f v

P٨Q

Q a a a i f i i i i f f f f f f

P

v v v a a i i f f

SELECTS, EQUI-JOINS, INEQUALITY JOINS, DIVISIÓN RELACIONAL

• Siempre que un Equi-Join requiera una comparación de igualdad, y uno de los dos, o los dos elementos sean una marca del mismo tipo (aplicable o no aplicable), las filas adecuadas serán pegadas si y sólo si fue especificado el cualificador “Tal vez”. • Si el cualificador “Tal vez” no fue especificado, entonces la ejecución entregará solamente aquellos casos en que la evaluación sea verdadera.

ORDENACIÓN DE VALORES Y MARCAS

• El ordenamiento debería ser manejado de forma similar que la igualdad. • Hay dos tipos de ordenamiento: orden semántico, y orden simbólico. El orden semántico aplica cuado se está usando un menor-que o un mayor-que en un sublenguaje de datos relacionales. El orden simbólico aplica cuando se utiliza la cláusula “Order By”. (por lo pronto SQL, cuando maneja marcas en la cláusula “Order By” éstas deben ser del tipo “aplicables”). Por ejemplo en DB2, las Marcas-A van inmediatamente después de los valores, y después de ésos van las Marcas-I.

FUNCIONES ESCALARES APLICADAS A ARGUMENTOS “MARCADOS”

• Función escalar es aquella que recibe escalares como operandos y entrega un escalar. • Como vimos en la tabla de la suma, si alguno de los operandos es Marca-I, el resultado es Marca-I, en cambio si el operando de la clase mayor es Marca-A, el resultado será Marca-A.

APLICACIÓN DE FUNCIONES ESTADÍSTICAS

• Una forma conveniente para manejar este tipo de funciones, es por medio de funciones de un solo argumento, para reemplazar las Maracas-A y las Marcas-I por algún valor predeterminado (reglas RQ-4 y RQ-5).

ELIMINACIÓN DE FILAS DUPLICADAS

• En ninguna circunstancia el SMBD debería permitir entregar filas repetidas. Incluso si el usuario ejecuta una proyección que no tiene la llave primaria o por alguna otra razón que pudiera presentar filas repetidas. El optimizador del SMBD debería eliminar la necesidad actual de especificar expresamente que no se quieren los duplicados. • Si las filas no tienen marcas, entonces es obvia la identificación de filas duplicadas, pero de otra forma dos filas son duplicadas si al evaluar dos componentes de filas <x, y> se cumple:
1.- x, y son valores y x=y o 2.- Uno del par es marcado el otro no o 3.- ambos x, y son marcas, y las marcas son iguales simbólicamente (ambas son Marca-A o ambas son Marca-I) y si la condición 1 es satisfecha para al menos un par de componentes evaluados.

ELIMINACIÓN DE FILAS DUPLICADAS

EMP

Emp# E107 E912 E239 E575 E123 E224

ENombre Pancho José José Pedro Adrián Rodrigo

Dep# D12 —A —A D12 D01 —A

Salario 10,000 12,000 12,000 —A 15,000 —A

H_Ciudad Zitácuaro Colima Colima Colima Cuernavaca Puebla

EMP

Emp# E107 E912 E239 E575 E123 E224

ENombre Pancho José José Pedro Adrián Rodrigo D12 —A —A D12 D01 —A

Dep#

Salario 10,000 12,000 12,000 —A 15,000 —A

H_Ciudad Citácuaro Colima Colima Colima Cuernavaca Puebla

E <- EMP [Dep#, Salario]
E’ Dep# D12 * ** —A —A D12 D01 *** —A Salario 10,000 12,000 12,000 —A 15,000 —A E Dep# D12 —A D12 D01 Salario 10,000 12,000 —A 15,000 # ##

MARCAS GENERADAS POR OPERADORES

• Al agregar una columna en una relación dada, todos los valores de dicha columna serán Marcas-A. No tendría caso ponerles Marcas-I ya que no tendría sentido la existencia de esa columna si todas las filas debieran tener marcas no aplicables en esa columna. • Los operadores “outer-join” y “outer-union” son capaces de generar relaciones derivadas en que alguna(s) columna(s) tengan Valores-de-BD ausentes. En ese caso también será razonable que usen Marcas-A.

CAMBIOS NECESARIOS EN EL LENGUAJE
• Manejo del cualificador “Tal vez” (para esto sería necesario que el SGBD maneje la lógica de tres-valores o la de cuatro-valores)
• Ej.: el elemento X requiere que la condición K que sea Verdadero o “Tal Vez”:
(X where K) U (X where K MAYBE)

• Si se usa la lógica de cuatro-valores, será necesario un “Tal Vez_A” y un “Tal Vez_I”
• Ej: si queremos encontrar:
1) Todos los empleados que reciben o podrían recibir comisiones por ventas SELECT serial_number FROM employees WHERE comission IS NOT I-MARKED 2) Todos los empleados que no podrían recibir comisiones por ventas SELECT serial_number FROM employees WHERE comission IS I-MARKED

IV. SQL

INTRODUCCIÓN

• El Lenguaje de consulta estructurado (Structured Query Language o SQL) es un lenguaje que se utiliza para interactuar con bases de datos relacionales. • SQL se utiliza para controlar todas las funciones que el SGBD ofrece a los usuarios, entre las que se hallan las siguientes:

– Definición de los datos. SQL permite que el usuario defina la estructura y la organización de los datos almacenados y las relaciones entre los elementos almacenados. – Recuperación de los datos. SQL permite que el usuario o un programa de aplicación recupere de la base de datos los datos almacenados y los utilice.

– Manipulación de datos. SQL permite que el usuario o una aplicación actualice la base de datos añadiendo datos nuevos, eliminando datos antiguos y modificando los datos almacenados previamente.

– Control de acceso. SQL puede utilizarse para restringir la capacidad del usuario para recuperar, añadir y modificar datos, protegiendo así los datos almacenados contra los accesos no autorizados. – Compartir datos. SQL utiliza para coordinar los datos compartidos entre usuarios concurrentes, asegurando así que no interfieran entre sí. – Integridad de datos. SQL define restricciones de integridad en la base de datos, protegiéndola así del deterioro debido a las actualizaciones inconsistentes o a los fallos del sistema.

HISTORIA

• SQL (que se pronuncia "ese-cu-ele" y no "siquel") empieza en 1974 con la definición, por parte de Donald Chamberlin y de otras personas de IBM, de un lenguaje para la especificación de las características de las bases de datos que adoptaban el modelo relacional. • Este lenguaje se llamaba SEQUEL (Structured English Query Language) y se implementó en un prototipo llamado SEQUEL-XRM entre 1974 y 1975.

• Las experimentaciones con ese prototipo llevaron, entre 1976 y 1977, a una revisión del lenguaje (SEQUEL/2), que a partir de ese momento cambió de nombre por motivos legales, convirtiéndose en SQL. • IBM creo el prototipo System R, a finales de los 70’s, basado en SQL Gracias al éxito de este sistema, también otras compañías empezaron a desarrollar sus productos relacionales basados en SQL.

• Otro producto relacional llamado Ingres, desarrollado por científicos en la Universidad de California, Berkeley, casi al mismo tiempo, trabajaba en su propio lenguaje llamado QUEL muy similar al SQL de IBM. • El primer producto relacional fue el de Oracle Corporation en 1979 seguido por el de IBM, SQL/DS (1980/81) y DB2 (1982/83).

• La primera versión comercial de Ingres estuvo disponible a principios de los 80’s. Sybase liberó la primera versión de su producto en 1986 y en 1988 Microsoft liberó SQL Server. • SQL fue reconocido como el lenguaje comúnmente usado en los SGBD, pero los diferentes productos tenían diferencias que se incrementaban con el tiempo, por lo cual era necesario crear un estándar.

• El trabajo en el estándar oficial de SQL comenzó en 1982, cuando ANSI encargo a su comité X3H2 la definición de un lenguaje estándar de bases de datos, ese lenguaje fue SQL ese lenguaje fue SQL debido a su amplia aceptación. • El estándar se desarrollo basándose en el SQL de DB2, pero con algunas diferencias. Después de varias revisiones se termino el estándar ANSI en 1986 y como estándar ISO en 1987.

• El estándar fue revisado y aumentado en 1989 y suele llamarse SQL-89 o estándar SQL1. • A SQL1 le faltaban muchas características por la incompatibilidad de los productos por lo cual se definían como características dependientes de la implementación.

• Para abordar los problemas que tenía el estándar SQL1 el comité ANSI siguió con el proceso de estandarización y distribuyó borradores que especificaban características que muchos productos SQL no tenían. • En 1992 el estándar supero la proceso de aprobación del comité ANSI y surgió SQL2 (denominado oficialmente SQL92) el cual ocupa cerca de 600 páginas mientras que SQL1 tenía menos de 100.

• SQL2 tenía tres niveles de cumplimiento del estándar: – Nivel inicial. Sólo exige una capacidad adicional mínima respecto al estándar SQL-89. – Nivel intermedio. Se creo como un avance con respecto a SQL-89 pero evitando los aspectos más complejos y la mayoría de los problemas dependientes del sistema y de los productos. – Nivel completo. Exige una implementación completa de todas las posibilidades de SQL2.

• EL estándar ANSI/ISO SQL3 surgió en 1999 y fue desarrollado bajo la supervisión de los comités ANSI e ISO. El estándar tiene más de 1500 páginas. • SQL3 extiende el modelo relacional de datos para incorporar objetos y tipos de datos complejos dentro de tablas relacionales junto con todos los mecanismos de soporte.

FECHA 1970 1974 1978 1979 1981 1982 1983 1986 1987 1988

EVENTO Codd define el modelo relacional de bases de datos. IBM comienza el proyecto System/R. Se publica el primer articulo que describe el lenguaje SEQUEL. Se realizan pruebas de System/R con clientes. Oracle introduce el primer SMBDR comercial. Relational Technology introduce Ingres. IBM anuncia SQL/DS. ANSI forma el comité para estándares de SQL. IBM anuncia DB2. Se ratifica el estándar SQL1. Sybase introduce un SMBDR para el procesamiento de transacciones. Se ratifica el estándar ISO SQL1. Ashton-state y Microsoft anuncian SQL Server para 0S/2.

FECHA 1989 1990 1991 1992

EVENTO Se publica la primera prueba de rendimiento TPC (TPC-A). Se publica la prueba de rendimiento TCP-B. Se publica la especificación de acceso a bases de datos SQL Access Group. Microsoft publica la especificación ODBC. Se ratifica el estándar ANSI SQL2 (SQL.2). Se publica la pruba de rendimiento TCP-C (OLTP). Por primera vez se distribuyen sistemas de almacenamiento de datos SQL especializados. Por primera vez se distribuyen productos ODBC. Se distribuye comercialmente tecnología paralela de servidores de bases de datos. Se publican el API estándar para el acceso OLAP a bases de datos y la prueba de rendimiento OLAP. UDB DB2 de IBM unifica la arquitectura DB2 para las plataformas de IBM y de otros fabricantes. Los principales fabricantes de SGBD anuncian estrategias de integración de Java.

1993

1994 1996 1997

FECHA 1998

EVENTO Microsoft SQL Server 7 ofrece soporte de bases de datos para Windows NT en el ámbito empresarial. Oracle 8i ofrece integración entre las bases de datos e Internet y rompe con el modelo Cliente/Servidor. Se distribuyen por primera vez productos comerciales de bases de datos residentes en memoria. J2EE estandariza el acceso JDBC a bases de datos desde los servidores de aplicaciones. Oracle introduce servidores de aplicaciones con caché integrada de bases de datos. Microsoft introduce SQL Server 2000, dirigido a las aplicaciones empresariales. La posibilidad de integración de XML aparece en los principales productos SMBDR. IBM adquiere el negocio de bases de datos de Informix. Gartner clasifica a IBM como primer fabricante de bases de datos, superando a Oracle.

1999 2000 2001

2002

• Una sentencia o instrucción SQL es como una frase (escrita en inglés ) con la que decimos lo que queremos obtener y de donde obtenerlo. • Todas las sentencias empiezan con un verbo (palabra reservada que indica la acción a realizar), seguido del resto de cláusulas, algunas obligatorias y otras opcionales que completan la frase. • Consideraciones para escribir sentencias SQL:

– Las sentencias SQL no distinguen entre mayúsculas y minúsculas. – Las sentencias SQL pueden estar en una o más Líneas. – Las palabras reservadas (keywords) no pueden ser abreviadas o divididas entre líneas. – Las cláusulas son usualmente colocadas en líneas separadas. – El sangrado debe ser usado para mejorar la legibilidad.

LENGUAJE DE MANIPULACIÓN DE DATOS (LDM)

SENTENCIA SELECT INSERT UPDATE DELETE

DESCRIPCIÓN Utilizada para recuperar datos de la base de datos. Utilizada para añadir filas de datos a una tabla en la base de datos. Utilizada para modificar los valores de los datos en la base de datos. Utilizada para eliminar filas de una tabla en una base de datos

LENGUAJE DE DEFINICIÓN DE DATOS (LDD)

SENTENCIA CREATE DROP

DESCRIPCIÓN Utilizada para crear nuevas tablas, vistas, esquemas, dominios e índices. Empleada para eliminar tablas, vistas, esquemas, dominios e

índices.
Utilizada para modificar las tablas, vistas, esquemas, dominios

ALTER

e índices.

LENGUAJE DE CONTROL DE DATOS (LCD)

SENTENCIA GRANT REVOKE COMMIT ROLLBACK

DESCRIPCIÓN Se utiliza para conceder privilegios de acceso a los usuarios. Utilizada eliminar privilegios de acceso a los usuarios. Se Utiliza para finalizar la transacción actual. Utilizada para abortar la transacción actual

LDM: SELECT

• Capacidades de la sentencia SELECT

Proyección

Selección

Tabla 1 Reunión

Tabla 1

Tabla 1

Tabla 2

• Sintaxis de la sentencia SELECT: SELECT [DISTINCT] [<calificador>.]<nombre_columna> | * | <expresión> [AS <alias_columna>],... FROM <tabla_o_nombre_vista> | [[AS] <tabla_alias>] [WHERE <predicado>] [GROUP BY [<calificador>.]<nombre_columna>,... [HAVING <predicado>] ] [ORDER BY <nombre_columna> | <numero_columna> [ASC | DESC],...];

La siguiente sentencia selecciona todas las columnas de la tabla departments:

SELECT * FROM departments;

La siguiente sentencia selecciona todas las columnas de la tabla departments:

SELECT department_id, location_id FROM departments;

LMD: SELECT - OPERADORES

Se pueden crear expresiones usando datos de tipo numérico y fecha con los siguientes operadores aritméticos:

Operador + * /

Descripción Suma Resta Multiplicación División

La siguiente sentencia muestra el uso del operador suma con la columna salary:

SELECT last_name, salary, salary + 300 FROM employees;

La precedencia de los operadores es la siguiente:

*

/

+

-

• La Multiplicación y la división tienen más prioridad que la suma y las resta. • Los operadores que tiene la misma prioridad son evaluados de izquierda a derecha. • Los paréntesis son usados para forzar el orden de evaluación y clarificar las sentencias.

La siguiente sentencia muestra la precedencia del operador multiplicación con la columna salary:

SELECT last_name, salary, 12*salary+100 FROM employees;

La siguiente sentencia muestra el uso de paréntesis para cambiar el orden de evaluación:

SELECT last_name, salary, 12*(salary+100) FROM employees;

LMD: SELECT – NULOS EN EXPRESIONES

La siguiente sentencia muestra como afectan los nulos en expresiones aritméticas:

SELECT last_name, 12*salary*commission_pct FROM employees;

LMD: SELECT – COLUMNAS ALIAS

Una columna alias: • Renombra el encabezado de una columna. • Es útil con cálculos. • Inmediatamente después del nombre de columna debe de ir la palabra reservada AS entre el nombre de columna y el alias. • Requiere comillas dobles para alias que contengan espacios o caracteres especiales.

La siguiente sentencia muestra como poner alias a las columnas:

SELECT last_name AS name, commission_pct AS comm FROM employees;

LMD: SELECT – OPERADOR DE CONCATENACIÓN

Un operador de concatenación: • Concatena columnas o cadenas de caracteres a otras columnas. • Esta representado por dos barras verticales ( || ). • Crea una columna como resultado que es una expresión de carácter.

La siguiente sentencia muestra como utilizar el operador de concatenación:

SELECT last_name || job_id AS "Employees" FROM employees;

La siguiente sentencia muestra como utilizar el operador de concatenación:

SELECT last_name ||' is a '||job_id AS "Employee Details" FROM employees;

LMD: SELECT – COLUMNAS DUPLICADAS

La siguiente sentencia muestra como eliminar las filas duplicadas:

SELECT DISTINCT department_id FROM employees;

LMD: SELECT – CLAUSULA WHERE

La cláusula WHERE nos permite limitar el número de filas en una consulta:

SELECT employee_id, last_name, job_id, department_id FROM employees WHERE department_id = 90 ;

• Las cadenas de caracteres y los valores de fecha deben ir encerradas en comillas simples. • Los valores de carácter son sensibles a las mayúsculas y minúsculas, y los valores de fechas son sensibles al formato. La cláusula WHERE nos permite limitar en base al last_name: SELECT last_name, job_id, department_id FROM employees WHERE last_name = 'Whalen'; La cláusula WHERE nos permite limitar en base al last_name: SELECT start_date, end_date FROM job_history WHERE start_date = '1993-01-13';

Operador = > >= < <= <>

Significado Igual que Mayor que Mayor que o igual que Menor que Menor que o igual que Diferente que

La cláusula WHERE nos permite limitar el número de filas con el operador de comparación:

SELECT last_name, salary FROM employees WHERE salary <= 3000;

Operador BETWEEN ...AND... IN(lista) LIKE IS NULL

Significado Entre dos valores (inclusivo)

Cualquiera de la lista de valores Que coincida con el patrón Si es un nulo

El operador BETWEEN nos permite limitar el número de filas utilizando un rango de valores:

SELECT last_name, salary FROM employees WHERE salary BETWEEN 2500 AND 3500;

El operador IN nos permite probar si un elemento es parte de una lista de valores:

SELECT employee_id, last_name, salary, manager_id FROM employees WHERE manager_id IN (100, 101, 201);

• % : Cualquier secuencia de cero o mas caracteres • _ : Un solo carácter. (cualquiera)

El operador LIKE nos permite buscar filas que cumplan con un determinado patrón: “ Empieza con ‘S’ ” SELECT first_name FROM employees WHERE first_name LIKE 'S%';

El operador LIKE nos permite buscar filas que cumplan con un determinado patrón: “ El Segundo caracter es ‘o’”
SELECT FROM WHERE last_name employees last_name LIKE ‘_o%';

“ Contiene ‘SA_’ “
SELECT employee_id, last_name, job_id FROM employees WHERE job_id like '%SA\_%';

\ : Es el carácter de escape predeterminado, el cual puede ser cambiado agregando al final: “ ESCAPE ‘<CHAR>’ “

El operador IS NULL nos sirve para identificar los nulos:

SELECT last_name, manager_id FROM employees WHERE manager_id IS NULL;

Operador AND OR

Significado Es TRUE si ambas condiciones son verdaderas Es TRUE si alguna es las condiciones es verdadera Es TRUE si la siguiente condición es falsa

NOT

Orden de evaluación Operador Significado 1 Operadores aritméticos Operador 2 Es TRUEOperador de concatenación si ambas condiciones son AND 3 Operadores de comparación verdaderas IS [NOT] NULL, LIKE, [NOT] IN OR 4 Es TRUE si alguna es las condiciones 5 [NOT] BETWEEN es verdadera 6 Operador lógico NOT Es TRUE si la siguiente condición es NOT 7 Operador lógico AND falsa 8 Operador lógico OR

LMD: SELECT – ORDER BY

Para ordenar filas se utiliza la cláusula ORDER BY. La cláusula ORDER BY debe estar al final de la sentencia SELECT. Esta cláusula tiene un modificador que puede ser: ASC: orden ascendente (opción por defecto). DESC: orden descendente.

La siguiente consulta ordena de manera ascendente la fecha de contrato: SELECT last_name, job_id, department_id, hire_date FROM employees ORDER BY hire_date ;

La siguiente consulta ordena de manera descendente la fecha de contrato: SELECT last_name, job_id, department_id, hire_date FROM employees ORDER BY hire_date DESC ;

• Se puede ordenar en base al alias de una columna: SELECT employee_id, last_name, salary*12 as annsal FROM employees ORDER BY annsal ; • También en base a una columna que no se desplegará: SELECT employee_id, salary*12 as annsal FROM employees ORDER BY last_name;

•Se puede ordenar con múltiples columnas:

SELECT last_name, department_id, salary FROM employees ORDER BY department_id, salary DESC ; En este caso serán acomodadas las filas de acuerdo a “department_id”, y todas las filas que tengan el mismo dato en ésta columna, serán ordenadas en forma descendente según el salario de cada empleado.

ESTÁNDAR DE SQL-99

Función SQL BIT_LENGTH (expresión) CAST (valor AS tipo de dato) CHAR_LENGTH (expresión) CONVERT (expresión USING conversión) CURRENT_DATE CURRENT_TIME (precisión) CURRENT_TIMESTAMP (precisión) EXTRACT (parte FROM expresión)

Descripción Devuelve la longitud de la generalmente una cadena, en bits. expresión,

Convierte el valor que está en un tipo de dato a otro tipo de dato compatible. Devuelve la longitud de la expresión, generalmente cadena, en caracteres. Convierte una cadena al tipo especificado de codificación. Devuelve la fecha actual del sistema. Devuelve la hora actual y la fecha actual del sistema, con la precisión especificada Devuelve la hora actual y la fecha actual del sistema, con la precisión especificada Extrae la parte especificada de la Fecha especificada.

Función SQL LOWER (cadena) OCTET_LENGTH (cadena) POSITION (subcadena IN cadena) SUBSTRING (cadena, inicio, longitud)

Descripción Convierte la cadena de caracteres a minúsculas. Regresa la longitud de la expresión en bytes. Devuelve la posición del carácter o subcadena en la cadena de caracteres. Devuelve una subcadena de la cadena especificada, desde la posición de inicio hasta la longitud dada. Devuelve Returns string translated into another string according to specified rules. Elimina el carácter indicado que aparezca en la posición especificada de la cadena. Convierte la cadena de caracteres a mayúsculas.

TRANSLATE (string expression USING translation rule) TRIM(LEADING | TRAILING | BOTH char expression FROM string expression) UPPER (cadena)

Funciones

Funciones de sólo una fila

Funciones de múltiples filas

LMD: FUNCIONES DE UNA SOLA FILA

• • • • • •

Permiten manipular datos. Actúan sobre cada fila. Devuelven un valor por fila. Pueden modificar el tipo de dato. Pueden estar anidadas. Aceptan argumentos, los cuales pueden ser una columna o una expresión.

Caracteres

Generales

Funciones de sólo una fila

Numéricas

Conversión

Fechas

LMD: FUNCIONES DE CARACTERES

Funciones de caracteres

Funciones de manipulación de mayúsculas y minúsculas
LOWER UPPER INITCAP

Funciones de manipulación de caracteres
SUBSTR LENGTH POSITION LPAD | RPAD TRIM REPLACE

Estas funciones convierten las mayúsculas y minúsculas.

Función LOWER(‘Hola') UPPER('Hola') hola HOLA

Resultado

INITCAP('hola mundo') Hola Mundo

SELECT SELECT FROM FROM WHERE WHERE

employee_id, last_name, department_id employee_id, last_name, department_id employees employees last_name = 'higgins'; last_name = 'higgins';

SELECT employee_id, last_name, department_id FROM employees WHERE LOWER(last_name) = 'higgins';

• Estas funciones manipulan cadenas de caracteres: Función SUBSTR('Hola Mundo', ,1,5) LENGTH('Hola Mundo') POSITION('Hola Mundo, ‘a') LPAD(‘Hola’,10,'*') RPAD(‘Hola’, 10, '*') TRIM('H' FROM 'Hola Mundo') Resultado Hola 10 4 ******Hola Hola****** ola Mundo

• Uso de las funciones de manipulación de caracteres:

SELECT employee_id, first_name, last_name, job_id, LENGTH (last_name), POSITION('a' in last_name) as "Contiene 'a'?" FROM employees WHERE SUBSTR(job_id, 4) = 'REP';

LMD: FUNCIONES NUMÉRICAS

• ROUND: Redondea el valor al decimal especificado ROUND(45.926, 2) 45.93 • TRUNC: Trunca un valor al decimal especificado TRUNC(45.926, 2) 45.92 • MOD: Devuelve el residuo de una división MOD(1600, 300) 100

• Uso de la función numérica ROUND:

SELECT ROUND(45.923,2), ROUND(45.923,0), ROUND(45.923,-1)

• Uso de la función numérica TRUNC:

SELECT

TRUNC(45.923,2), TRUNC(45.923), TRUNC(45.923,-2), TRUNC(4365.923,-2)

-------------------------------------45.92 45 0 4300

• Uso de la función numérica MOD:

SELECT last_name, salary, MOD(salary, 5000) FROM employees WHERE job_id = 'SA_REP';

LMD: FUNCIONES DE FECHAS

• CURRENT_DATE devuelve la fecha actual • CURRENT_TIME devuelve la hora • CURRENT_TIMESTAMP devuelve la fecha y la hora

• Uso de las funciones CURRENT_DATE, CURRENT_TIME y CURRENT_TIMESTAMP;

SELECT CURRENT_TIME, CURRENT_DATE, CURRENT_TIMESTAMP

LMD: FUNCIONES GENERALES

• Estas funciones trabajan con cualquier tipo de datos y permiten trabajar con nulos: • NULLIF (expr1, expr2) (nota: iguales null, diferentes expr1) • COALESCE (expr1, expr2, ..., exprn) (nota: primer no null)

• Uso de la función COALESCE:

SELECT

last_name, COALESCE(commission_pct, salary, 10)as comm FROM employees ORDER BY commission_pct;

• Uso de la función NULLIF:

SELECT first_name, LENGTH(first_name) as "expr1", last_name, LENGTH(last_name) as "expr2", NULLIF(LENGTH(first_name), LENGTH(last_name)) AS result FROM employees;

LMD: MÚLTIPLES TABLAS
department_id department_name location_id

employee_id 100 101

last_name King Kochhar

department_id 90 90

•••
60 70 80 90 100 110 120 IT Public Relations Sales Executive Finance Accounting Treasury 1400 2700 2500 1700 1700 1700 1700

•••
204 205 employee_id Baer Higgins department_id 70 110 department_name

•••
199 200 201 202 203 204 205 206 50 10 20 20 40 70 110 110 Shipping Administration Marketing Marketing Human Resources Public Relations Accounting Accounting

•••

• Atención: en los siguientes casos el número de registros obtenidos es el producto cartesiano de las tablas originales  Faltó alguna condición en el join.  Alguna condición en el join es inválida.  Todas las filas de la primera tabla son reunidas a todas las filas de la segunda.

• Sintaxis de la sentencia SELECT (en sql 99): SELECT table1.column, table2.column FROM table1 [ CROSS JOIN table2 ] | [ NATURAL JOIN table2 ] | [ JOIN table2 USING (column_name) ] | [ JOIN table2 ON (table1.column_name = table2.column_name) ] | [ LEFT | RIGHT | FULL OUTER JOIN table2 ON (table1.column_name = table2.column_name) ];

• CROSS JOIN Esta cláusula produce el producto cruz de las dos tablas.
select last_name, department_name from employees CROSS JOIN departments;

Produce el mismo resultado que:
select last_name, department_name from employees, departments;

• NATURAL JOIN – Esta cláusula está basada en todas las columnas de las dos tablas que tienen el mismo nombre – Selecciona las filas que tienen el mismo valor en estas columnas de ambas tablas – Si hay columnas con el mismo nombre, pero con tipo de datos diferente, sale un error.
select department_id, department_name, location_id, location_id, city from departments NATURAL JOIN locations where department_id IN (20, 50);

• JOIN con USING

– Si varias columnas tienen el mismo nombre, pero diferentes tipos de datos, se puede modificar el NATURAL JOIN para especificar las columnas que se deben usar. – Si varias columnas tienen el mismo nombre, pero queremos especificar que solamente una debe participar en el NATURAL JOIN, se debe usar USING. – No se deben usar nombres de tablas o alias en las columnas referenciadas. – NATURAL JOIN y USING son mutuamente excluyentes.

• JOIN con USING
select e.employee_id, e.last_name, d.location_id from employees e JOIN departments d USING (department_id); select e.employee_id, e.last_name, d.location_id from employees e JOIN departments d USING (d.department_id); d.

Se obtiene el mismo resultado con:
n select employees.employee_id, employees.last_name, joi i departments.location_id qu E from employees, departments where employees.department_id = departments.department_id;

• JOIN con ON

– La cláusula NATURAL JOIN es básicamente un equijoin de todas las columnas con el mismo nombre. – Se usa ON para especificar condiciones arbitrarias o especificar columnas a reunir. – Si se usa ON, las condiciones de búsqueda están separadas de las condiciones del join, por lo que es más fácil de entender.

select e.employee_id, e.last_name, e.department_id, d.department_id, d.location_id from employees e JOIN departments d ON (e.department_id = d.department_id) where e.department_id IN (20, 50);

• JOIN de tres tablas usando ON
select employee_id, city, department_name from employees e JOIN departments d ON d.department_id = e.department_id JOIN locations l ON d.location_id = l.location_id where e.department_id IN (20, 50);

Se obtiene el mismo resultado con:
select employee_id, city, department_name from employees e, departments d, locations l where d.department_id = e.department_id and d.location_id = l.location_id and e.department_id IN (20, 50);

n joi i qu E

• INNER JOIN vs. OUTER JOIN

– En SQL ’99 el join de dos tablas que devuelve solamente filas que si coinciden con las condiciones, es un INNER JOIN. – Un join entre dos tablas que devuelve el resultado del INNER JOIN y también devuelve las filas que no coinciden con las condiciones, en la tabla de la izquierda, en la de la derecha, o ambas es un LEFT OUTER JOIN, RIGHT OUTER JOIN, o un FULL OUTER JOIN.

• LEFT OUTER JOIN
select e.last_name, e.department_id, d.department_name from employees e LEFT OUTER JOIN departments d ON (e.department_id = d.department_id) ;

• RIGHT OUTER JOIN
select e.last_name, e.department_id, d.department_name from employees e RIGHT OUTER JOIN departments d ON (e.department_id = d.department_id) ;

• FULL OUTER JOIN

select e.last_name, e.department_id, d.department_name from employees e FULL OUTER JOIN departments d ON (e.department_id = d.department_id) ;

VI. Diseño de Base de Datos

OBJETIVO

Generar un conjunto de esquemas relacionales que permitan almacenar la información con un mínimo de redundancia, pero a la vez faciliten la recuperación de la información. Obtener esquemas manipulación. exentos de anomalías de

PROBLEMAS DEL ESQUEMA RELACIONAL

• Redundancia. Se llama así a los datos que se repiten continua e innecesariamente por las tablas de las bases de datos. • Ocasiona un mayor tamaño en la base de datos almacenada, lo que repercute en problemas de espacio, acceso más lento de la información. La más grave de las consecuencias es si deviene en inconsistencia. • Cuando es excesiva es evidente que el diseño hay que revisarlo. • Es el primer síntoma de problemas y se detecta fácilmente.

• Ambigüedades. Datos que no clarifican suficientemente el registro al que representan. Los datos de cada registro podrían referirse a más de un registro o incluso puede ser imposible saber a qué ejemplar exactamente se están refiriendo. • Es un problema muy grave y difícil de detectar.

Pérdida de restricciones dependencias funcionales.

de

integridad.

Normalmente

debido

a

• Ejemplos: – Restricciones de existencia (valores nulos). – Restricciones de unicidad (valores duplicados. • Integridad referencial: permite asegurar que un valor que aparece en una relación para un conjunto de atributos determinado aparezca también en otra relación para un cierto conjunto de atributos. Se arreglan siguiendo una serie de pasos concretos.

• Anomalías en operaciones de modificación de datos. El hecho de que al insertar un elemento haya que repetir tuplas en una tabla para variar unos pocos datos. • O que eliminar un elemento suponga eliminar varias tuplas. Por ejemplo, que eliminar un cliente suponga borrar seis o siete filas de la tabla de clientes, sería un error muy grave y por lo tanto un diseño terrible).

Propiedades indeseables. Un mal diseño nos conduciría a: – Repetición de la información. – Imposibilidad para representar determinada información con certeza.

Metas del diseño: – Evitar redundancia de datos. – Asegurar que las relaciones entre atributos estén representadas. – Facilitar la verificación de actualizaciones para evitar violaciones de integridad en la base de datos.

EJEMPLO

• Algunos de los problemas planteados se ven en el siguiente diseño de datos para un banco. • La información es sobre los préstamos que se guardan en una sola relación, préstamo, que se define mediante el esquema de relación:

Esquema-prestamo =(nombre-sucursal, ciudad-sucursal, activo, nombrecliente, número-préstamo, importe)

nombre-sucursal Centro Moralzarzal Navacerrada Centro Becerril Collado Mediano Navas de la Asunción Segovia Centro Navacerrada Galapagar

ciudad-sucursal Arganzuela La Granja Aluche Arganzuela Aluche Aluche Alcalá de Henares Cerceda Arganzuela Aluche Arganzuela

activo 9.000.000 2.100.000 1.700.000 9.000.000 400.000 8.000.000 300.000 3.700.000 9.000.000 1.700.000 7.100.000

nombre-cliente Santos Gómez López Sotoca Santos Abril Valdivieso López González Rodríguez Amo

numeropréstamo P-17 P-23 P-15 P-14 P-93 P-11 P-29 P-16 P-18 P-25 P-10

importe 1.000 2.000 1.500 1.500 500 900 1.200 1.300 2.000 2.500 2.200

Se sabe que: • Cada sucursal bancaria tiene un valor único del activo, por lo que dado el nombre de una sucursal se puede identificar de manera única el valor del activo. • Cada sucursal puede conceder muchos préstamos por lo que, dado el nombre de una sucursal, no se puede determinar de manera única el numero de un préstamo.

Repetición de la información. Supóngase que se desea añadir un nuevo préstamo a la base de datos: Navacerrada, Aluche, 1.700.000, Fernández, P-31, 1.500

Hay que repetir los datos del activo y de la ciudad de la sucursal.
• Actualización. Supóngase que el activo de la sucursal de Navacerrada cambia de 1.700.000 a 1.900.000.

Hay que modificar muchas tuplas de la relación prestamo.
• Imposibilidad para representar determinada información. No se puede representar de manera directa la información relativa a cada sucursal (nombre-sucursal, ciudad-sucursal, activo) a menos que haya como mínimo un préstamo en esa sucursal

• El principio fundamental reside en que las tablas deben referirse a objetos o situaciones muy concretas, relacionados exactamente con elementos reconocibles por el sistema de información de forma inequívoca y que cada fila de una tabla representa inequívocamente un elemento reconocible en el sistema. • Es difícil a nivel conceptual agrupar esos elementos correctamente. • La teoría de la normalización permite afrontar el problema de diseño de bases de datos relacionales de una manera rigurosa y objetiva.

PAUTAS INFORMALES DE DISEÑO

• Semántica de los atributos. • Reducción de los valores redundantes en la tuplas. • Reducción de los valores nulos en las tuplas. • Eliminación de la posibilidad de generación de tuplas espurias. Para representar el esquema de una base de datos relacional se debe dar el nombre de sus relaciones, los atributos de éstas, los dominios sobre los que se definen estos atributos, las llaves primarias y las llaves foráneas.

• Ejemplo: a) Semánticamente confusas

Pauta 1: Diseñe un esquema de relación de modo que sea fácil explicar su significado. No combine atributos de varios tipos de entidades y tipos de vínculos en una sola relación.

• Ejemplo: b) Información redundante en la tuplas y anomalías de actualización.

Anomalías de actualización: • Anomalías de inserción. • Anomalías de eliminación. • Anomalías de modificación.

Pauta 2: Diseñe los esquemas de las relaciones de modo que no haya anomalías de inserción, eliminación o modificación en las relaciones. Si hay anomalías señálelas con claridad a fin de que los programas que actualicen la BD operen correctamente.

• Ejemplo: c) Valores nulos en la tuplas.

Pauta 3: Hasta donde sea posible, evite incluir en una relación base atributos cuyos valores puedan ser nulos. Si no es posible evitar los nulos, asegúrese de que se apliquen sólo en casos excepcionales y no a la mayoría de las tuplas de la relación.

• Ejemplo: c)Tuplas espurias. Se aplica proyección a EMP_PROY

Se aplica join natural a EMP_PROY1 y LUGARES_EMP.

Pauta 4: Diseñe los esquemas de modo que puedan reunirse por condiciones de igualdad sobre atributos claves, para garantizar que no se formen tuplas erróneas.

DEPENDENCIA FUNCIONAL: BASES

Es una restricción entre dos conjuntos de atributos de la base de datos. Son restricciones del conjunto de relaciones legales. Juega un papel importante en el Diseño de Base de datos. El concepto de dependencia funcional generalización de la idea de una llave. es una

Definición: Es una restricción entre dos conjuntos de atributos de la base de datos. Teniendo una relación R. Con n atributos {A1,A2, ... , An} En lo que R = {A1,A2, ... , An}

Dos casos de DF (Dependencia Funcional): • El valor de una clave candidata dada en un determinado momento. El conjunto de todos los valores posibles que podría tomar esa clave candidata en diferentes momentos.

Definición de DF según caso a): Sea r una relación y sean X y Y subcojuntos arbitrarios del conjunto de atributos de r. Entonces decimos que Y es dependiente funcional de X si y sólo si cada valor de X en r está asociado precisamente con un valor de Y en r. (siempre que dos tuplas de r coincidan en su valor X, también coincidirán en su valor Y). XY

DEFINICIÓN

Sea R un esquema de relación. Sean A y B dos conjuntos de atributos de la base de datos. Donde A⊆ RyB⊆ R

La dependencia funcional A B es en R si y solo si para alguna relación aceptable r(R), siempre que dos tuplas t1 y t2 de r concuerden con los atributos A, también concuerdan sobre los atributos B. Esto es: t1[A] = t2 [A] ⇒ t1[B ] = t2 [B ]

Por ejemplo: la siguiente relación satisface la DF. { V# }  { ciudad }
V# V1 V1 V2 V2 V3 V4 V4 V4 CIUDAD Londres Londres París París París Londres Londres Londres P# P1 P2 P1 P2 P2 P2 P4 P5 CANT 100 100 200 200 300 400 400 400

No se cumple: { P# }  { cant }

Otras dependencias funcionales: { V#, P# }  { cant } { V#, P# }  { ciudad } { V#, P# }  { ciudad, cant } { V#, P# }  { V# } { V#, P# }  { V#, P#, ciudad, cant } { V# }  { cant } { cant }  { V# }

DETERMINANTE Y DEPENDIENTE

Determinante  Dependiente Cuando se contiene sólo un atributo en ambos conjuntos denominado conjunto individual, se escribe: V#  ciudad

Definición de DF según caso b). Sea R una llave candidata y sean X y Y subconjuntos cualesquiera del conjunto de atributos de R. Entonces, decimos que Y es dependiente funcionalmente de X si y sólo si en todo valor válido posible de R, cada valor X está asociado precisamente con un valor Y. (En todo valor válido posible de R, siempre que dos tuplas coincidan en X, también lo harán en Y). XY

De las dependencias anteriores, las siguientes DFs no son válidas “todo el tiempo”: V#  cant Cant  V# Debido a que se tendría como restricción que “todo envío de un proveedor dado tiene la misma cantidad”. Lo cual es valido para la instancia actual de la relación, pero no para todos los valores posibles de la relación. Se usara el término “dependencia funcional” para el caso b), e independiente del tiempo.

TIPOS DE DEPENDENCIA

• Equivalente: XY y YX se representa: X ↔ Y
y { cant }  { V# }

Ejemplo: { V# }  { cant }

• Plena o completa: Si X(X1,X2), se dice que Y es dependiente funcional completa de X, si depende funcionalmente de X, pero no depende de ningún subconjunto del mismo. XY pero: X1  | Y Y y X2  | Y Lo representamos: X

• Funcional elemental: Si una DF plena tiene como descriptor determinado un atributo simple. V#  ciudad. • Funcional Transitiva: Sea una relación R(X,Y,Z), en la que: X  Y, Y Z y Y | X, se dice que Z tiene dependencia transitiva respecto a X, a través de Y.

• Funcional trivial: X Y de X (Y C X).

es trivial si Y es un subconjunto

{ V#, P# }  { V# }

USO DE DEPENDENCIAS FUNCIONALES

1.

Probar las relaciones para verificar si éstas son válidas bajo un conjunto dado de dependencias funcionales. Si una relación r es válida bajo un conjunto F de dependencias funcionales, se dice que

r satisface F

1.

Especifica restricciones sobre el conjunto de relaciones validas.

Decimos que F cumple con R si todas las relaciones validas sobre R satisfacen el conjunto de dependencias funcionales F.

F se cumple en R

UNA RELACIÓN SATISFACE UNA DF

calle-cliente ciudad-cliente

nombre-cliente Santos Gómez

calle-cliente Mayor Carreteras Mayor Carreteras Jazmín Arenal

Ciudad-cliente Peguerinos Cerceda Peguerinos Cerceda León La Granja

En el mundo real Dos ciudades pueden tener calles que se llamen igual.

López Pérez Fernández González

Relación cliente

No se incluye en el conjunto de dependencias funcionales que se cumple en Esquema-cliente.

UNA DF SE CUMPLE EN UN ESQUEMA

numero-prestamo  importe

numero-prestamo P-17 P-23

Nombre-sucursal Centro Moralzarzal Navacerrada Centro Becerril Centro

importe 1.000 2.000 1.500 1.500 500 2.000

En la empresa real Cada préstamo tienen único importe.

P-15

un

P-14 P-93 P-18

Relación préstamo

Se exige que la restricción número-préstamo  importe se cumpla en Esquema-préstamo

Cuando se diseña una base de datos relacional se enumera en primer lugar las dependencias funcionales que se deben cumplir siempre.

CIERRE DE UN CONJUNTO DE DEPENDENCIAS

Dado un conjunto de dependencias funcionales S, hay seguramente otras dependencias funcionales que son lógicamente implícitas por S. Si A  B y B  C, entonces podemos inferir A C Ejemplo: { V#, P# }  { CIUDAD, CANT } Implica a las dos siguientes: { V#, P# }  CIUDAD { V#, P# }  CANT

El conjunto de todas la dependencias funcionales lógicamente implicadas por S es la cerradura de S. ( S+ ). Podemos encontrar todas las DF de S+, aplicando las Reglas de Inferencia, también llamados Axiomas de Armstrong. El cómputo del cierre de un conjunto de atributos con respecto a un conjunto de dependencias funcionales se utiliza para determinar llaves y para asistir a la normalización de relaciones.

AXIOMAS DE ARMSTRONG

Propuestas por W. Armstrong en “Dependency Structures of Data Base Relationships” Suecia, 1974. Son correctos porque no generan dependencias funcionales incorrectas. Son completos, porque, para un conjunto dado F de dependencias funcionales permite generar todo F+.

Notación: • Letras griegas (α, β, γ ,..) para conjuntos de atributos • Letras latinas mayúsculas para atributos individuales • ab denota α ∪ β • Regla de la reflexibilidad. Si α es un conjunto de atributos y β ⊆ α, entonces se cumple que α  β

• Regla de la aumentatividad. Si se cumple que α β y un γ es un conjunto de atributos y β ⊆ α, entonces se cumple que γ α  γ β • Regla de la transitividad. Si se cumple que α β y también se cumple que un β γ , entonces se cumple que α  γ . Aunque los axiomas son completos, resulta difícil utilizarlos directamente para el cálculo de F+

OTRAS REGLAS

• Regla de la unión. Si se cumple que α β y que α  γ entonces se cumple que α  βγ . • Regla de la descomposición. Si se cumple que entonces se cumple que α  β y que α  γ .

α βγ

• Regla de la pseudotransitividad. Si se cumple que α β y que γ β  δ, entonces se cumple que αγ  δ.

EJEMPLO

Esquema de relación Conjunto de dependencias funcionales

R = (A, B, C, G, H, I) A B A C CG  H CG  I B H

La dependencia funcional H.

A

Dado que se cumple A B y B  H, se aplica la regla de transitividad

La dependencia funcional

CG  HI.

Dado que CG H y CG  I, se aplica la regla de unión. La dependencia funcional AG  I.

Dado que A  C y CG  I, se aplica la regla de pseudotransitividad. O se aplica la regla de aumentatividad en A  C para inferir AG  CG. Finalmente se aplica la regla de transitividad de la anterior y CG  I .

CIERRE DE UN CONJUNTO DE ATRIBUTOS

• Los términos a la derecha y a la izquierda de una dependencia funcional son subconjuntos de R. • Un conjunto de tamaño n tiene 2n subconjuntos. • Por lo que hay

2 x 2n = 2 n + 1 dependencias funcionales posibles
• n es el número de atributos de R.

• Procedimiento que demuestra formalmente el modo de utilizar los axiomas de Armstrong para calcular F+. F+ := F
repeat for each dependencia funcional f en F+ aplicar reflexibilidad y agregación sobre f agregar el resultado de dependencias funcionales hacia F+ for each par de dependencias funcionales f1y f2 en F+ If f1y f2 puede ser combinada usando transitividad then agrega el resultado de la dependencia funcional a F+ until F+ no cambie más

• El algoritmo para encontrar si un conjunto α es una superclave implica el cálculo del conjunto de atributos determinados funcionalmente por α .

• Uno no muy eficiente es tomar todas las dependencias

funcionales con α como término de la izquierda y tomar la unión de los términos de la derecha de todas esas dependencias.

• Uno más eficiente tiene que dado un conjunto de atributos α , se define el cierre de α bajo F (denotado por α +) como el conjunto de atributos que son funcionalmente determinados por α bajo F:
resultado:=α; While (cambios en resultado) do for each dependencia funcional β  γ in F do begin if β ⊆ resultado then resultado:= resultado ∪ γ ; end

• Ejemplo:
Esquema de relación Conjunto de dependencias funcionales Calcular (AG)+ R = (A, B, C, G, H, I) AB AC CG  H CG  I BH A  B está en F A ⊆ resultado (AG)

resultado = AG A  B hace que se incluya B a resultado resultado:= resultado ∪ B

• Ejemplo:

AB AC CG  H CG  I BH

A  C hace que resultado sea ABCG CG  H hace que resultado sea ABCGH CG  I hace que resultado sea ABCGHI

USO DE ATRIBUTOS DE CERRADURA

Existen múltiples usos para el algoritmo del atributo cerradura: • Prueba de la superllave: – Para probar si X es una superllave, calculamos X+, y checamos si X+ contiene todos los atributos de R. • Prueba de dependencias funcionales – Para checar si una dependencia funcional X  Y conserva (o en otras palabras, esta en F+), solo checa si Y C X+. – Es decir, calculamos X+ usando atributos cerradura, y entonces checar si éste contiene Y.

COBERTURA CANÓNICA

Conjuntos de dependencias funcionales pueden tener dependencias redundantes que pueden ser deducidas desde otras Ejemplo: AC es redundante en {AB, BC, AC}. Partes de una dependencia funcional pueden ser redundantes. Ejemplo: {AB, BC, ACD} Puede ser simplificada a {AB, BC, AD} Intuitivamente una cobertura canónica de F es un conjunto “minimo” de dependencias funcionales equivalente a F, no teniendo dependencias redundantes o partes redundantes de dependencias.

Cualquier base de datos que satisfaga el conjunto de dependencias funcionales simplificado también satisfará el conjunto original, y viceversa, dado que los dos conjuntos tienen el mismo cierre. Sin embargo, el conjunto simplificado es más sencillo de verificar. El conjunto simplificado puede construirse como se describirá a continuación. Un atributo de una DF es raro o extraño si puede eliminarse sin modificar el cierre del conjunto de DFs.

DEFINICIÓN

• Sea F un conjunto de dependencias funcionales y α β la dependencia funcional de F. • El atributo A es raro en α si A∈α y F implica lógicamente a (F - {αβ}) ∪ {(α - A)  β} • El atributo A es raro en β si A∈β y el conjunto de dependencias funcionales (F- {αβ}) ∪ {α - (β  A)} implica lógicamente a F.

EJEMPLOS

• Sean las dependencias funcionales: Entonces
B

ABC AC

es raro en

ABC ABCD AC

• Sean las dependencias funcionales: Entonces
C

es raro en el lado derecho de ABCD

• Hay que prestar atención a la dirección de las implicaciones cuando se utiliza la definición de los atributos raros: si se intercambian el lado derecho y el izquierdo la implicación se cumplirá siempre

Para comprobar eficientemente si un atributo A es raro en la dependencia α  β: • Si A∈β, hay que considerar el conjunto: F’= (F-{α  β}) U {α  (β-A)}) Y comprobar si α  A puede inferirse a partir de F’, para ello hay que calcular α + bajo F’: si α incluye A entonces A es raro en β. • Si A∈α , sea γ =α-{A}, hay que comprobar si se puede inferir que γ  β a partir de F, para ello hay que calcular γ + bajo F: si γ + incluye todos los atributos de β entonces A es raro en α.

• Sea F

AB CD, A  E y EC

• Comprobar si C es raro en AB (α)  CD (β) • Hay que calcular el cierre de los atributos AB bajo F´=

Conjuntos de dependencias funcionales pueden tener dependencias redundantes que pueden ser deducidas desde otras. Ejemplo: A  C es redundante en: { A  B, BC, AC }

Partes de una dependencia funcional pueden ser redundantes { A  B, BC, ACD} puede ser simplificada a { A  B, BC, AD}

• Intuitivamente, una cobertura canónica de F es un conjunto "mínimo" de dependencias funcionales equivalente a F, no teniendo dependencias redundantes o partes redundantes de dependencias.

Un recubrimiento canónico Fc, de F es un conjunto dependencias tales que F implica lógicamente todas dependencias de Fc, y Fc, implica lógicamente todas dependencias de F. Además, Fc debe cumplir propiedades siguientes:

de las las las

• Ninguna dependencia de Fc, contiene atributos raros. • Cada lado izquierdo de una dependencia funcional es único. Es decir, no hay dos dependencias α1β1, y α2β2 de Fc, tales que α1= α2.

El recubrimiento canónico de un conjunto de dependencias funcionales F puede calcularse de la manera siguiente: Repeat Utilizar la regla de la unión para sustituir cualquier dependencia de F de la forma α1β1 U α1β2 con α1β1β2 . Hallar una dependencia funcional αβ con un atributo raro en α o en β. Until F no cambie.

Considérese el siguiente conjunto funcionales F del esquema (A,B,C): ABC BC AB ABC

de

dependencias

Calculamos el recubrimiento canónico de F.

Hay dos dependencias funcionales con el mismo conjunto de atributos a la izquierda de la flecha: ABC AB Estas dependencias funcionales se combinan en: ABC

A es raro para ABC porque F implica lógicamente (F – {ABC}) U {BC} Esta afirmación es verdadera porque BC ya está en el conjunto de dependencias funcionales. C es raro para ABC, ya que ABC viene lógicamente implicado por AB y por BC. Por tanto, el recubrimiento canónico es AB BC

Sign up to vote on this title
UsefulNot useful