sistemas de bases de datos

696
I. Conceptos Básicos de las I. Conceptos Básicos de las Bases de Datos Bases de Datos

Upload: ivan-almada

Post on 24-Jul-2015

9.434 views

Category:

Documents


4 download

TRANSCRIPT

Page 1: Sistemas de Bases de Datos

I. Conceptos Básicos de las I. Conceptos Básicos de las Bases de DatosBases de Datos

Page 2: Sistemas de Bases de Datos

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.

DATO

Page 3: Sistemas de Bases de Datos

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…

CALIDAD DE LA INFORMACIÓN

Page 4: Sistemas de Bases 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.

BASE DE DATOS

Page 5: Sistemas de Bases de Datos

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.

Page 6: Sistemas de Bases 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.

SISTEMA MANEJADOR DE BASE DE DATOS

Page 7: Sistemas de Bases de Datos

• 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.

FUNCIONES DE UN SMBD

Page 8: Sistemas de Bases de Datos

Usuarios Finales

Programas de Aplicación

Sistema Manejador de Base Sistema Manejador de Base de Datos (SMBD)de Datos (SMBD)

Base de Datos

Page 9: Sistemas de Bases de Datos

Principios

• 50’s50’s

• 6060’’ss

• 7070’’ss

• 8080’’ss

• 9090’’ss

Modelos

• Sistemas manejadores de archivosSistemas manejadores de archivos

• Bases de datos jerárquicasBases de datos jerárquicas

• Bases de datos de redBases de datos de red

• Bases de datos relacionalesBases de datos relacionales

• Bases de datos OOBases de datos OO

HISTORIA

Page 10: Sistemas de Bases de Datos

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.

ARQUITECTURA DE TRES NIVELES

Page 11: Sistemas de Bases de Datos
Page 12: Sistemas de Bases de Datos

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 los datos en él.

OBJETIVOS DE UN SMBD

Page 13: Sistemas de Bases de Datos

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.

Page 14: Sistemas de Bases de Datos

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.

Page 15: Sistemas de Bases de Datos

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.

Page 16: Sistemas de Bases de Datos

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.

Page 17: Sistemas de Bases de Datos

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.

Page 18: Sistemas de Bases de Datos

1. Datos

2. Hardware (Máquinas)

3. Software (Programas)

4. Usuarios (Personas)

COMPONENTES DE UN SBD

Page 19: Sistemas de Bases de 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”.

1. DATOS

Page 20: Sistemas de Bases de Datos

Sus componentes son:

• Los volúmenes de almacenamiento secundario• Los procesadores de hardware y la memoria principal

2. HARDWARE

Page 21: Sistemas de Bases de Datos

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 datosSubsistema de Definición de Datos: Crea y mantiene el diccionario de datos y define la estructura de los archivos de la base de datosSubsistema de Manipulación de Datos: Agrega, cambia, elimina y consulta datos de una base de datos

3. SOFTWARE

Page 22: Sistemas de Bases de Datos

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)

3. SOFTWARE

Page 23: Sistemas de Bases de Datos

Sistema Manejador de Bases de DatosSistema Manejador de Bases de Datos

Page 24: Sistemas de Bases de Datos

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.)

4. USUARIOS

Page 25: Sistemas de Bases de Datos

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.

DBA

Page 26: Sistemas de Bases de Datos

• 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.

DISEÑADORES DE DB

Page 27: Sistemas de Bases de Datos

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.

USUARIO FINAL

Page 28: Sistemas de Bases de Datos

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.

Page 29: Sistemas de Bases de Datos

• 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.

SMBD VS. MANEJADOR DE ARCHIVOS

Page 30: Sistemas de Bases de Datos

ARCHIVO CONVENCIONAL

MEMORIA PRINCIPAL

BUFFER DEL SISTEMA OPERATIVO

PROGRAMA DE APLICACIONES

ÁREA DE TRABAJO DEL PROGRAMA DE APLICACIONES

SISTEMA OPERATIVO

11

22

3344

Page 31: Sistemas de Bases de Datos

MEMORIA PRINCIPAL

BUFFER DEL SISTEMA OPERATIVO

PROGRAMA DE APLICACIONES

ÁREA DE TRABAJO DEL PROGRAMA DE APLICACIONES

BASE DE DATOS

SISTEMA OPERATIVO

11

22

44

5566

SMBD

BUFFER DEL SMBD

33

44

Nota: El propio SMBD puedeinteractuar directamente con laBD pudiendo ser de esta forma más eficiente

Page 32: Sistemas de Bases de Datos

Extracción:

Resultado (mostrado en una pantalla):

EJEMPLO DE UNA CONSULTA

Page 33: Sistemas de Bases de Datos

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.

VENTAJAS DE LOS SMBD

Page 34: Sistemas de Bases de Datos

II Modelos Lógicos BasadosII Modelos Lógicos Basadosen Objetosen Objetos

Page 35: Sistemas de Bases de Datos

Definición:Definición: Colección de herramientas conceptuales para Colección de herramientas conceptuales para describir datos, relaciones entre ellos, su semántica y describir datos, relaciones entre ellos, su semántica y restricciones de integridad. 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.

MODELO DE DATOS

Page 36: Sistemas de Bases de Datos

• Modelos basados en registrosModelos basados en registros

• Modelos basados en objetosModelos basados en objetos

• Modelos objeto - relacionalesModelos objeto - relacionales

CLASIFICACIÓN

Page 37: Sistemas de Bases de Datos

Jerárquico

• Almacenan su información Almacenan su información en una estructura jerárquica.en una estructura jerárquica.

• Los datos se organizan en Los datos se organizan en una forma similar a un árbol una forma similar a un árbol (visto al revés).(visto al revés).

• El contenido de un registro El contenido de un registro específico puede repetirse en específico puede repetirse en varios sitios varios sitios ⇒⇒ una una inconsistencia de datosinconsistencia de datos .

Modelos Basados en Registros

Page 38: Sistemas de Bases de Datos

De Red

• Representa los datos mediante Representa los datos mediante colecciones de registroscolecciones de registrosy sus relaciones se representan y sus relaciones se representan por medio de ligas.por medio de ligas.

• Se permite que un mismo nodo Se permite que un mismo nodo tenga varios padres.tenga varios padres.

• Ofrecía una solución eficiente Ofrecía una solución eficiente al problema de redundancia de al problema de redundancia de datos.datos.

Modelos Basados en Registros

Page 39: Sistemas de Bases de Datos

Relacional

Dr. Edgar F. "Ted" CoddDr. Edgar F. "Ted" Codd Junio 1970Junio 1970

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

• Fundamentos MatemáticosFundamentos Matemáticos..

• Los datos están estructurados Los datos están estructurados a nivel lógico como tablas a nivel lógico como tablas formadas por filas y columnas.formadas por filas y columnas.

• Concepto fundamental: Concepto fundamental: Relación.Relación.

• Alto nivel de abstracción.Alto nivel de abstracción.

Modelos Basados en Registros

Page 40: Sistemas de Bases de Datos

Modelos Basados en Objetos Entidad - Relación

• Percepción de un mundo Percepción de un mundo real. real. EntidadesEntidades y y relaciones.relaciones.

• EntidadesEntidades: descritas por : descritas por un conjunto de atributos.un conjunto de atributos.

• RelacionesRelaciones: Asociación : Asociación entre entidades.entre entidades.

Dr. Peter Pin-Shan Chen Marzo 1976Dr. Peter Pin-Shan Chen Marzo 1976

““The Entity-Relationship Model--Toward a Unified View of DataThe Entity-Relationship Model--Toward a Unified View of Data””

Page 41: Sistemas de Bases de Datos
Page 42: Sistemas de Bases de Datos

Orientado a Objetos

• Soporta el paradigma orientado a Soporta el paradigma orientado a objetos almacenando datos y objetos almacenando datos y métodos.métodos.

• Flexibilidad y soporte para el Flexibilidad y soporte para el manejo de tipos de datos complejos.manejo de tipos de datos complejos.

• Manipula datos complejos en forma Manipula datos complejos en forma rápida y ágilmente .rápida y ágilmente .

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

Modelos Basados en Objetos

Page 43: Sistemas de Bases de Datos

Modelos Objeto - Relacionales

Dr. Michael Stonebraker. Dr. Michael Stonebraker.

Page 44: Sistemas de Bases de Datos

• Las bases de datos están presentes en muchos aspectos.Las bases de datos están presentes en muchos aspectos.

• Su desarrollo ha sido en paralelo con las necesidades de Su desarrollo ha sido en paralelo con las necesidades de información por parte de los distintos usuarios (información por parte de los distintos usuarios (datamining, datamining, datawarehousedatawarehouse).).

• Su nivel de abstracción también ha evolucionado con Su nivel de abstracción también ha evolucionado con estos últimos.estos últimos.

• Nuevas formas de representar información:Nuevas formas de representar información:

• Datos semi-estructurados.Datos semi-estructurados.

Page 45: Sistemas de Bases de Datos

• Modelo Entidad – RelaciónModelo Entidad – Relación(MER)(MER)

Page 46: Sistemas de Bases de Datos

• 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.).

MODELO ENTIDAD-RELACIÓN

Page 47: Sistemas de Bases de Datos

• 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 Entity-Relationship Model-Toward a Unified View of Data, Massachusetts Institute of Technology.

HISTORIA

Page 48: Sistemas de Bases de Datos

• 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”.

Page 49: Sistemas de Bases de Datos

Diagramas de Chen

Page 50: Sistemas de Bases de Datos

• 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.

Page 51: Sistemas de Bases de Datos

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.

DEFINICIÓN

Page 52: Sistemas de Bases de Datos

• Entidad

• Atributo

• Relación (Interrelación)

• Diagramas Entidad-Relación

CONCEPTOS BÁSICOS

Page 53: Sistemas de Bases de Datos

• 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

CONJUNTO DE ENTIDADES

Page 54: Sistemas de Bases de Datos

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

– Instancia o entidad

Persona

ENTIDAD

Page 55: Sistemas de Bases de Datos

• 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

TIPOS DE ENTIDADES

Page 56: Sistemas de Bases de Datos

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

• Símbolo:

NombreAtributo

Persona

NombreEdad

Nacionalidad

ATRIBUTO

Page 57: Sistemas de Bases de Datos

• 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

Page 58: Sistemas de Bases de Datos

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

26

Salvadoreña

Persona

Edad

Nacionalidad

TIPOS DE ATRIBUTOS

Page 59: Sistemas de Bases de Datos

• Opcional: aquellos atributos que pueden tener valores o no tenerlos. Posiblemente nulo (ausencia de valor).

26

Salvadoreña

Persona

Edad

Nacionalidad

nulo

Teléfono

Page 60: Sistemas de Bases de Datos

• Monovaluado: aquel atributo que sólo puede tener un único valor. Ejemplo: Edad.

26

Salvadoreña

Persona

Edad

Nacionalidad

nuloTeléfono

Page 61: Sistemas de Bases de Datos

• Multivaluado: aquellos atributos que pueden tener varios valores. Ejemplo: Teléfono.

• Símbolo:Atributo

26

Salvadoreña

Persona

Edad

Nacionalidad

044551234567856061234

Teléfono

Page 62: Sistemas de Bases de Datos

• 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

Page 63: Sistemas de Bases de Datos

• Simples: No se pueden dividir en subpartes.

• Símbolo:

• Compuestos: Se pueden dividir en subpartes.

• Símbolo:

Nacionalidad

Fecha de nacimiento

AñoMes

Día

Page 64: Sistemas de Bases de Datos

• 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

Page 65: Sistemas de Bases de Datos

• 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).

Cliente

Id_clienteNombre

Teléfono

CLAVES

Page 66: Sistemas de Bases de Datos

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

Cliente

Id_clienteNombre

Teléfono

No_IFE

Page 67: Sistemas de Bases de Datos

• 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.

Page 68: Sistemas de Bases de Datos

Cliente

Id_clienteNombre

Teléfono

No_IFENo_IFE

SELECCIÓN DE LA CLAVE PRIMARIA

Page 69: Sistemas de Bases de Datos

Alumno

Fecha de nacimiento

Número de cuenta

Edad

Nombre

Nacionalidad

Año

Mes

Día

Teléfono

ENTIDAD-ATRIBUTO

Page 70: Sistemas de Bases de Datos

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

Maestro enseña a alumnos

Interrelación Enseña

INTERRELACIONES (ASOCIACIONES)

Page 71: Sistemas de Bases de Datos

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.

Page 72: Sistemas de Bases de Datos

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.

Page 73: Sistemas de Bases de Datos

Asociación unaria Asociación binaria

R

E

RE E

Casadacon

Persona

atiendeMédico Paciente

GRADO

Page 74: Sistemas de Bases de Datos

Asociación ternaria

E E

E

RMateria Evaluación

Estudiante

Obtiene

Page 75: Sistemas de Bases de Datos

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

Empleado Supervisa

Page 76: Sistemas de Bases de Datos

Empleado Supervisa

Supervisor

Supervisado

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.

ROL

Page 77: Sistemas de Bases de Datos

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.

CLAVE FORANEA

Page 78: Sistemas de Bases de Datos

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.

CARDINALIDAD

Page 79: Sistemas de Bases de Datos

• Uno a uno

Municipio

a1

a2

a3

Ayuntamiento

b1

b2

b3

Tiene

Page 80: Sistemas de Bases de Datos

• Uno a muchos:

Empresa

a1

a2

a3

Departamento

b1

b2

b3

b4

Conformada por

b5

Page 81: Sistemas de Bases de Datos

• Muchos a uno

Sucursal

a1

a2

a3

Empresa

b1

b2

b3a4

Pertenece a

a5

Page 82: Sistemas de Bases de Datos

• Muchos a muchos

Profesor

a1

a2

a3

a4

Estudiante

b1

b2

b3

b4

Atiende a

Page 83: Sistemas de Bases de Datos

Consideremos un vínculoTRABAJA_PARAentre los dos conjuntos de entidadesEMPLEADO y DEPARTAMENTO, que asocia a cada empleado con el departamento para el que trabaja

Page 84: Sistemas de Bases de Datos

• Las interrelaciones pueden tener atributos como las entidades.

Interrelación

Atributo

ATRIBUTOS DE LAS INTERRELACIONES

Page 85: Sistemas de Bases de Datos

Imparte

Semestre

Profesor Asignatura

Page 86: Sistemas de Bases de Datos

Muchos a muchos (M:N)

Muchos a uno (N:1)

Uno a muchos (1:N)

Uno a uno (1:1)

ChenCardinalidad

1 1

1 N

M N

N 1

OPCIONES DE SIMBOLOGÍA

Page 87: Sistemas de Bases de Datos

OpcionalObligatoria

OpcionalOpcionalNo existeOpcional

ObligatoriaObligatoriaObligatoria

Chen

Page 88: Sistemas de Bases de Datos

Muchos a muchos

(M:N)

Muchos a uno

(N:1)

Uno a muchos

(1:N)

Uno a uno

(1:1)

Cardinalidad

Page 89: Sistemas de Bases de Datos

OpcionalObligatoria

OpcionalOpcional

ObligatoriaObligatoria

Page 90: Sistemas de Bases de Datos

• Modelo EntidadModelo Entidad – Relación– RelaciónExtendido Extendido

(MERE)(MERE)

Page 91: Sistemas de Bases de Datos

• 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.

MODELO ERE

Page 92: Sistemas de Bases de Datos

• 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.

Page 93: Sistemas de Bases de Datos

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

SUBTIPOS, SUPERTIPOS Y HERENCIA

Page 94: Sistemas de Bases de Datos

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

Page 95: Sistemas de Bases de Datos

• Herencia de tipo:

– Los subtipos heredan los atributos del

supertipo relacionado. – Una instancia de un subtipo es también una

instancia de un supertipo.

Page 96: Sistemas de Bases de Datos

Supertipo Empleado con Tres Subtipos

Derivados

Page 97: Sistemas de Bases de Datos

Notación para

Subtipos y Supertipos

en el Modelo EER

Interrelación en la cual todas las

instancias participan

Interrelación en la cual sólo las

versiones especializadas

participan

Conjunto de entidades General

Versión especializada del

supertipo

Page 98: Sistemas de Bases de Datos

Conjunto de entidades General

Versión especializada del supertipo

Interrelación en la cual todas las

instancias participan

Interrelación en la cual sólo las

versiones especializadas

participan

NOTACIÓN DE ALGUNAS HERRAMIENTAS

Page 99: Sistemas de Bases de Datos

• 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.

INTERRELACIONES Y SUBTIPOS

Page 100: Sistemas de Bases de Datos

Interrelación a nivel de

supertipos

Interrelación a nivel de subtipos

Page 101: Sistemas de Bases de Datos

• 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.

GENERALIZACIÓN

Page 102: Sistemas de Bases de Datos

Carro

Moto

Camión

Marca Modelo

TipoCabina

Capacidad

No_deMotorPrecio

Nombre_Vehículo

Marca Modelo

Nombre_Vehículo

No_Pasajeros

Id_Vehículo

PrecioNo_deMotor

Marca Modelo

Id_Vehículo

Id_Vehículo

Nombre_Vehículo

No_deMotor

Precio

EJEMPLO

Page 103: Sistemas de Bases de Datos
Page 104: Sistemas de Bases de Datos

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

(Top-down)

ESPECIALIZACIÓN

Page 105: Sistemas de Bases de Datos

Pieza

Proveedor

Precio_unitario

Id_ProveedorDescripción

No_Parte

UbicaciónCant_Disponible

Num_Envío

EJEMPLO

Page 106: Sistemas de Bases de Datos
Page 107: Sistemas de Bases de Datos

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.

Page 108: Sistemas de Bases de Datos

• Indica que una instancia de un supertipo debe también ser miembro de un subtipo.

– Regla de especialización total (completa):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íneadoble línea..

– Regla de especialización parcialRegla de especialización parcial: Indica que es posible que alguna instancia del supertipo no pertenezca a ninguno de los subtipos. Símbolo: línea simple.línea simple.

RESTRICCIONES EN SUPERTIPOS

Page 109: Sistemas de Bases de Datos

Un paciente debe ser ya sea paciente externo o paciente residente

EJEMPLOS

Page 110: Sistemas de Bases de Datos

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

Page 111: Sistemas de Bases de Datos

• Si una instancia de un supertipo puede ser simultáneamente, un miembro de dos o más subtipos

– Regla disjuntaRegla disjunta: una instancia del supertipo puede ser sólo una de los subtipos.

– Regla de traslapeRegla de traslape: una instancia del supertipo puede ser más de una de los subtipos.

Page 112: Sistemas de Bases de Datos

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

d

Page 113: Sistemas de Bases de Datos

o

Una pieza puede ser ambos, comprada y manufacturada

Page 114: Sistemas de Bases de Datos

• Es un atributo del supertipo cuyo valor determina el subtipo correspondiente.– DisjuntoDisjunto: un atributo simple con valores

alternativos para indicar el subtipo correspondiente.

– TraslapeTraslape: un atributo compuesto cuyas subpartes pertenecen a los diferentes subtipos. Cada subparte contiene un valor lógico que indica si la instancia pertenece o no al subtipo asociado.

Page 115: Sistemas de Bases de Datos

Atributo simple que indica el tipo de subclase correspondiente

Tipo_empleado

dTipo_empleado=

“H”“S”

“C”

Page 116: Sistemas de Bases de Datos

O

Tipo

Comprada Manufacturada

Page 117: Sistemas de Bases de Datos

• 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 entidadesCluster de entidades: conjunto de uno o más tipos de entidad y las interrelaciones asociadas agrupadas en un único conjunto de entidades abstracta.

CLUSTER DE ENTIDADES

Page 118: Sistemas de Bases de Datos

Grupos de Entidades

Relacionadas Pueden Formar

Clusters

Page 119: Sistemas de Bases de Datos

Usado ArtículoArtículo vendido

Producido en

Manufacturera

ClienteUnidad de

ventas

Hace negocios

con

Compra

Material

Page 120: Sistemas de Bases de Datos

Regla de traslape

Especialización total

Especialización parcial

Regla disjunta

Herencia

SímboloDescripción

SIMBOLOGÍA

Page 121: Sistemas de Bases de Datos

• 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

FincaEdificio

d

JERARQUÍAS DE ÁRBOL

Page 122: Sistemas de Bases de Datos

• 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.

MÚLTIPLES JERARQUÍAS

Page 123: Sistemas de Bases de Datos

Jefe de ingeniería

Jefe Subcont

sueldo

Precio

Asalariado

d

Secretaria Ingeniero

veloc

nivel

tipo

Técnico

d

nombre

fecha direcdnipila

ape1

ape2

Empleado

JERARQUÍA MÚLTIPLE

Page 124: Sistemas de Bases de Datos

• 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 SIMPLE

Page 125: Sistemas de Bases de Datos

• 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.

HERENCIA MÚLTIPLE

Page 126: Sistemas de Bases de Datos

Maestria Licenciatura

grupotitulo

d

Docenciaproyecto práctica

d

Investigación

Docente

nivel categoría

d

Laboral Ayudante

sueldo

dni

nombresexo

direc

fecha-n

especialidad

O

Persona

Empleado Estudiante

Page 127: Sistemas de Bases de Datos

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

Ayudante

Empleado

Estudiante

Horario

Horario

¿Horario?

Page 128: Sistemas de Bases de Datos

¿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.

Page 129: Sistemas de Bases de Datos

• 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

RectánguloTriángulo

d

Cuadrado

Ancho

Alto

Lado

Ancho y Alto no deberían ser

heredados por Cuadrado

INHIBICIÓN DE LA HERENCIA

Page 130: Sistemas de Bases de Datos

• 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 sobre todo para atributos derivados.

REDEFINICIÓN DE ATRIBUTOS HEREDADOS

Page 131: Sistemas de Bases de Datos

Rectángulo

Cuadrado

Ancho

Alto

Lado

Área

Área

Page 132: Sistemas de Bases de Datos

• 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.

Page 133: Sistemas de Bases de Datos

• 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.

CATEGORÍAS

Page 134: Sistemas de Bases de Datos

Vehículo

tiene

Propietario

Banco EmpresaPersona

U

matricula

fechacompra

nombre dir

nombre dir

IFEdir

nombreUnión

Page 135: Sistemas de Bases de Datos

• Una categoría puede ser parcial o total.• Las categorías parciales implementan

herencia selectiva.

Símbolo:

• Las categorías totales implementan herencia múltiple.

Símbolo:

U

U

Page 136: Sistemas de Bases de Datos

Edificio Finca

Propiedad

U

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

Propietario

BancoEmpresaPersona

U

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

Page 137: Sistemas de Bases de Datos

• 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

Propiedad

FincaEdificio

d≡

CATEGORÍAS Y GENERALIZACIÓN

Page 138: Sistemas de Bases de Datos

• 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.

AGREGACIÓN

Page 139: Sistemas de Bases de Datos

• Para esta interrelación se quiere registrar los administradores que supervisan las tareas de un empleado.

• Existe una entidad Administrador.

Empleado Sucursal

Trabajo

Trabaja en

Page 140: Sistemas de Bases de Datos

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

Empleado Sucursal

Trabajo

Trabaja en

Administrador

Dirige

Page 141: Sistemas de Bases de Datos

Trabaja-en

• Alternativa 2: agregación.

Administrador

Dirige

Empleado Sucursal

Trabajo

Trabaja en

Page 142: Sistemas de Bases de Datos

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

Page 143: Sistemas de Bases de Datos

Traslape

Disjunción

Generalización / Especialización

Especialización parcial

Especialización total

SímboloElemento

d

O

RESUMEN DE SIMBOLOGÍA

Page 144: Sistemas de Bases de Datos

Como entidadAgregación

Categoría total

Categoría parcial

Unión / Categoría

SímboloElemento

U

U

U

Page 145: Sistemas de Bases de Datos

• Algunos les llaman esquemas ER relacionales.

Es una mezcla entre estos modelos y son muy utilizados por herramientas case.

ESQUEMAS RELACIONALES DERIVADOS DEL MER

Page 146: Sistemas de Bases de Datos

Tabla con campos para el atributo y para la llave de la entidad.

Atributo multivaluado

Cada sub atributo se convierte en campo

Atributo compuesto (monovaluados)

Llave primariaClave primaria

CampoAtributo

TablaConj. de entidades

Equivalencia RelacionalElemento

PASO DE MER Y MERE A TABLAS

Page 147: Sistemas de Bases de Datos

Tabla con llave foránea de la entidad fuerte relacionada.

Entidad débil

----Atributo derivado

Los atributos multivaluados forman tablas, los monovaluados son campos en la tabla de la entidad.

Atributo compuesto

(multivaluados)

Equivalencia RelacionalElemento

Page 148: Sistemas de Bases de Datos

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

Interrelaciones de orden n

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

Interrelación muchos a muchos

Equivalencia RelacionalElemento

Page 149: Sistemas de Bases de Datos

La clave de una tabla pasa a la otra tabla relacionada.

Interrelación uno a uno

La tabla del lado varios incluye los atributos de la interrelación y la clave de la tabla del lado uno.

Interrelación binaria uno a muchos con atributos

La tabla del lado varios incluye a la clave de la tabla del lado uno.

Interrelación binaria uno a muchos sin atributos

Equivalencia RelacionalElemento

Page 150: Sistemas de Bases de Datos

Para convertir este tipo de interrelación en su equivalencia del modelo relacional hay varias opciones.

Generalización

Se tratan igual que las otras pero puede resultar en la duplicación de un atributo en una tabla.

interrelaciones recursivas

Equivalencia RelacionalElemento

Page 151: Sistemas de Bases de Datos

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.

Generalización

Equivalencia RelacionalElemento

Page 152: Sistemas de Bases de Datos

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.

Generalización

Equivalencia RelacionalElemento

Page 153: Sistemas de Bases de Datos

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.

Generalización

Equivalencia RelacionalElemento

Page 154: Sistemas de Bases de Datos

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.

Generalización

Equivalencia RelacionalElemento

Page 155: Sistemas de Bases de Datos

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.

Categorías

Equivalencia RelacionalElemento

Page 156: Sistemas de Bases de Datos

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

PROBLEMA

Page 157: Sistemas de Bases de Datos

• 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.

Page 158: Sistemas de Bases de Datos

• 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.

Page 159: Sistemas de Bases de Datos

Empleado

EnterradorAdministrativo Jardinero

d

Nombre completo

ID

Salario

Antigüedad

Teléfono

DirecciónFecha de

contratación

DíaMes

Año

NombreAMaternoAPaterno

Tipo_empleado A

E

J

Sepulcro

Tumba Nicho Fosa común

d

Id_sepulcro Tipo

Altura

InscripciónN

T

N

F

CapacidadF

CapacidadT

InscripciónT

Fecha de compra

Page 160: Sistemas de Bases de Datos

Sector

Id_sector

NSectorCapacidad

Superficie

Familiar

Nombrecompleto

AMaterno

APaternoNombre

Dirección

Id_familiar

Teléfono

Factura

Id_factura

Fecha

AñoMes

Día

Cantidad

Fallecido

Nombrecompleto

AMaterno

APaternoNombre

FechaFallecimiento

AñoMes

Día

FechaNacimiento

AñoMes

Día

Enterrador Id_fallecido

Page 161: Sistemas de Bases de Datos

Asignado a

Sector

Id_sector

NSector

Capacidad

Superficie

Sector

Id_sector

NSector

Capacidad

Superficie

Empleado

EnterradorAdministrativo Jardinero

d

Nombre

completo

ID

Salario

Antigüedad

Teléfono

Dirección

Fecha de

contratación

Día

Mes

Año

Nombre

AMaterno

APaterno

Tipo_empleado

A

E

J

Empleado

EnterradorAdministrativo Jardinero

d

Empleado

EnterradorAdministrativo Jardinero

d

Nombre

completo

ID

Salario

Antigüedad

Teléfono

Dirección

Fecha de

contratación

Día

Mes

Año

Nombre

AMaterno

APaterno

Tipo_empleado

A

E

J

Factura

Id_factura

Fecha

AñoMes

Día

Cantidad

Factura

Id_factura

Fecha

AñoMes

Día

Cantidad

Familiar

Nombre

completo

AMaterno

APaterno

Nombre

Dirección

Id_familiar

Teléfono

Familiar

Nombre

completo

AMaterno

APaterno

Nombre

Dirección

Id_familiar

Teléfono

Fallecido

Nombre

completo

AMaterno

APaterno

Nombre

Fecha

Fallecimiento

AñoMes

Día

Fecha

Nacimiento

AñoMes

Día

Enterrador Id_fallecido

Fallecido

Nombre

completo

AMaterno

APaterno

Nombre

Fecha

Fallecimiento

AñoMes

Día

Fecha

Nacimiento

AñoMes

Día

Enterrador Id_fallecido

Sepulcro

Tumba Nicho Fosa común

d

Id_sepulcro

Tipo

Altura

InscripciónN

T

N

F

CapacidadF

CapacidadT

InscripciónT

Fecha de compra

Sepulcro

Tumba Nicho Fosa común

d

Id_sepulcro

Tipo

Altura

InscripciónN

T

N

F

CapacidadF

CapacidadT

InscripciónT

Sepulcro

Tumba Nicho Fosa común

d

Id_sepulcro

Tipo

Altura

InscripciónN

T

N

F

CapacidadF

CapacidadT

InscripciónT

Fecha de compra

Page 162: Sistemas de Bases de Datos

Relationship_4Relationship_6

Relationship_8

Relationship_12

Relationship_13

Relationship_17

Relationship_15

Relationship_16 Relationship_18 Relationship_19Relationship_20

Relationship_21

Relationship_22

Relationship_14

Administrativo

IDAdmininstradorNombreAPaternoAMaternoDireccionSalarioAntigüedadFechaContratación

<pi> IntegerTextTextTextTextDecimalIntegerDate

<M><M><M>

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

Identifier_1 <pi>

Nicho

AlturaInscripción

DecimalText

<M>

Sector

IdSectorNSectorCapacidadSuperficie

<pi> IntegerTextIntegerDecimal

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

Identifier_1 <pi>

Sepulcro

IDSepulcroTipo

<pi> IntegerText

<M><M>

Identifier_1 <pi>

FosaComún

Capacidad Integer <M>

Tumba

CapacidadInscripción

IntegerText

<M>

Familiar

IdFamiliarNombreAPaternoAMaternoDireccion

<pi> IntegerTextTextTextText

<M>

<M><M><M>

Identifier_1 <pi>

Fallecido

IdFallecidoNombreAPaternoAMaternoFechaDeNacimientoFechaDeFallecimiento

<pi> IntegerTextTextTextDateDate

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

Identifier_1 <pi>

Factura

IdFacturaCantidadFecha

<pi> IntegerDecimalDate

<M><M>

Identifier_1 <pi>

Teléfono

IDTeléfonoTeléfono

<pi> IntegerInteger

<M>

Identifier_1 <pi>

Enterrador

IDEnterradorNombreAPaternoAMaternoDireccionSalarioAntigüedadFechaContratación

<pi> IntegerTextTextTextTextDecimalIntegerDate

<M><M><M>

<M><M><M>

Identifier_1 <pi>

Jardinero

IDJardineroNombreAPaternoAMaternoDireccionSalarioAntigüedadFechaContratación

<pi> IntegerTextTextTextTextDecimalIntegerDate

<M><M><M>

<M><M><M>

Identifier_1 <pi>

Page 163: Sistemas de Bases de Datos

FK_FACTURA_RELATIONS_FAMILIAR

FK_TUMBA_RELATIONS_SEPULCRO

FK_NICHO_RELATIONS_SEPULCRO

FK_FACTURA_RELATIONS_ADMINIST

FK_FALLECID_RELATIONS_FAMILIAR

FK_TELEFONO_RELATIONS_FAMILIAR

FK_FALLECID_RELATIONS_ENTERRAD

FK_SECTOR_RELATIONS_JARDINERFK_TELEFONO_RELATIONS_JARDINERFK_TELEFONO_RELATIONS_ADMINIST

FK_TELEFONO_RELATIONS_ENTERRAD

FK_FOSACOMU_RELATIONS_SEPULCRO

FK_FALLECID_RELATIONS_SEPULCRO

FK_SEPULCRO_RELATIONS_SECTOR

Administrativo

IDAdmininstradorNombreAPaternoAMaternoDireccionSalarioAntigüedadFechaContratación

integerlong varcharlong varcharlong varcharlong varchardecimalintegerdate

<pk>

Nicho

IDSepulcroAlturaInscripción

integerdecimallong varchar

<fk>

Sector

IdSectorIDJardineroNSectorCapacidadSuperficie

integerintegerlong varcharintegerdecimal

<pk><fk>

Sepulcro

IDSepulcroIdSectorTipo

integerintegerlong varchar

<pk><fk>

FosaComún

IDSepulcroCapacidad

integerinteger

<fk>

Tumba

IDSepulcroCapacidadInscripción

integerintegerlong varchar

<fk>

Famil iar

IdFamiliarNombreAPaternoAMaternoDireccion

integerlong varcharlong varcharlong varcharlong varchar

<pk>

Fallecido

IdFallecidoIdFamil iarIDSepulcroIDEnterradorNombreAPaternoAMaternoFechaDeNacimientoFechaDeFallecimiento

integerintegerintegerintegerlong varcharlong varcharlong varchardatedate

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

Factura

IdFacturaIdFamiliarIDAdmininstradorCantidadFecha

integerintegerintegerdecimaldate

<pk><fk1><fk2>

Teléfono

IDTeléfonoIDEnterradorIDAdmininstradorIdFamil iarIDJardineroTeléfono

integerintegerintegerintegerintegerinteger

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

Enterrador

IDEnterradorNombreAPaternoAMaternoDireccionSalarioAntigüedadFechaContratación

integerlong varcharlong varcharlong varcharlong varchardecimalintegerdate

<pk>

Jardinero

IDJardineroNombreAPaternoAMaternoDireccionSalarioAntigüedadFechaContratación

integerlong varcharlong varcharlong varcharlong varchardecimalintegerdate

<pk>

Page 164: Sistemas 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.

NOCIONES DE DISEÑO DE BASES DE DATOS

Page 165: Sistemas de Bases de Datos

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.

Page 166: Sistemas de Bases de Datos

• Diseño Conceptual

• Diseño Lógico

• Diseño Físico

Page 167: Sistemas de Bases de Datos

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 CONCEPTUAL

Page 168: Sistemas de Bases de Datos

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

DISEÑO LÓGICO

Page 169: Sistemas de Bases de Datos

ExpresividadExpresividad –– Expresar perfectamente la realidad con suficientes conceptos.

SimplicidadSimplicidad – Fáciles de entender.

MinimalidadMinimalidad – Cada concepto debe tener un significado distinto.

FormalidadFormalidad – Conceptos con interpretación única, precisa y bien definida.

CUALIDADES DE UN BUEN DISEÑO

Page 170: Sistemas de Bases de Datos

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 y las interrelaciones entre ellas de diferentes formas.

METODOLOGÍA DE DISEÑO

Page 171: Sistemas de Bases de Datos

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.

Page 172: Sistemas de Bases de Datos

• 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.

TAREAS A REALIZAR

Page 173: Sistemas de Bases de Datos

• Determinar los identificadores.

• Determinar las jerarquías de generalización.

• Dibujar el diagrama entidad-relación.

• Revisar el esquema con el usuario.

Page 174: Sistemas de Bases de Datos

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.

1. Identificar los conjuntos de entidades:

Page 175: Sistemas de Bases de Datos

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.

2. Identificar los conjuntos de relaciones:

Page 176: Sistemas de Bases de Datos

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.

3. Identificar los atributos:

Page 177: Sistemas de Bases de Datos

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’ .

4. Determinar los dominios:

Page 178: Sistemas de Bases de Datos

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.

5. Determinar los identificadores:

Page 179: Sistemas de Bases de Datos

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.

6. Jerarquías de generalización:

Page 180: Sistemas de Bases de Datos

Dibujar el diagrama entidad-relación correspondiente a una de las vistas de los usuarios.

Se obtiene así un esquema conceptual local.

7. Diagrama entidad-relación:

Page 181: Sistemas de Bases de Datos

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

8. Revisar esquema con usuario:

Page 182: Sistemas de Bases de Datos

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.

EJEMPLO

Page 183: Sistemas de Bases de Datos
Page 184: Sistemas de Bases de Datos
Page 185: Sistemas de Bases de Datos
Page 186: Sistemas de Bases de Datos

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

Page 187: Sistemas de Bases de Datos

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

Page 188: Sistemas de Bases de Datos

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.

Page 189: Sistemas de Bases de Datos

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.

Page 190: Sistemas de Bases de Datos

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.

Page 191: Sistemas de Bases de Datos

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

Page 192: Sistemas de Bases de Datos

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

Page 193: Sistemas de Bases de Datos

• Modelos Orientado a objetosModelos Orientado a objetos

Page 194: Sistemas de Bases de Datos

• 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.

MODELO ORIENTADO A OBJETOS

Page 195: Sistemas de Bases de Datos

• 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.

Page 196: Sistemas de Bases de Datos
Page 197: Sistemas de Bases de Datos
Page 198: Sistemas de Bases de Datos

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

BASES DE DATOS ORIENTADAS A OBJETOS

Page 199: Sistemas de Bases de Datos

Vehículo

Punto

Figura

Animal

(1,3)

(2,2)

(2,1)

(5,2.5)

Platero:Animal

CONCEPTOS DEL MODELO OO

Page 200: Sistemas de Bases de Datos

• 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.

Page 201: Sistemas de Bases de Datos

• 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.

Page 202: Sistemas de Bases de Datos

• 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.

Page 203: Sistemas de Bases de Datos

• 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.

Page 204: Sistemas de Bases de Datos

• 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.

Page 205: Sistemas de Bases de Datos

• 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.

Page 206: Sistemas de Bases de Datos

• 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.

Page 207: Sistemas de Bases de Datos

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

Figura

Triángulo Cuadrado Círculo

EJEMPLO

Page 208: Sistemas de Bases de Datos

UML

Page 209: Sistemas de Bases de Datos

• 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).

MODELO Y DIAGRAMA

Page 210: Sistemas de Bases de Datos

• 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 PORQUE DE MODELAR

Page 211: Sistemas de Bases de Datos

• 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.

EL LENGUAJE DE MODELADO

Page 212: Sistemas de Bases de Datos

• 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

¿QUÉ ES UML?

Page 213: Sistemas de Bases de Datos

• 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.

EL PAPEL DE UML

Page 214: Sistemas de Bases de Datos

• 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.

UML

Page 215: Sistemas de Bases de Datos
Page 216: Sistemas de Bases de Datos

DIAGRAMAS UML v1.x

Page 217: Sistemas de Bases de Datos

DIAGRAMAS UML v2.0

Page 218: Sistemas de Bases de Datos

• 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

PAQUETES

Page 219: Sistemas de Bases de Datos

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

CASOS DE USO

Page 220: Sistemas de Bases de Datos

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

SECUENCIA

Page 221: Sistemas de Bases de Datos

• 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.

ESTADOS

Page 222: Sistemas de Bases de Datos

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

DISTRIBUCIÓN (DESPLIEGUE)

Page 223: Sistemas de Bases de Datos

• 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.

ACTIVIDAD

Page 224: Sistemas de Bases de Datos

• 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.

Transacciones

Reservas

Actualizar_transacciones

búsqueda

Consultas

/reportes

COMPONENTES

Page 225: Sistemas de Bases de Datos

• 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.

CLASES

Page 226: Sistemas de Bases de Datos

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

OBJETOS

Page 227: Sistemas de Bases de Datos

• 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.).

NUEVOS DIAGRAMAS EN UML v2.0

Page 228: Sistemas de Bases de Datos

• 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.

Page 229: Sistemas de Bases de Datos

• 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.

COLABORACIÓN

Page 230: Sistemas de Bases de Datos

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

Page 231: Sistemas de Bases de Datos

• 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.

Page 232: Sistemas de Bases de Datos
Page 233: Sistemas de Bases de Datos

• 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.

MODELO CONCEPTUAL DE OBJETOS CON UML

Page 234: Sistemas de Bases de Datos

• 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.

DIAGRAMA DE CLASES

Page 235: Sistemas de Bases de Datos

• 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).

ELEMENTOS

Page 236: Sistemas de Bases de Datos

• 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).

ATRIBUTOS

Page 237: Sistemas de Bases de Datos

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).

MÉTODOS

Page 238: Sistemas de Bases de Datos

EJEMPLO

Page 239: Sistemas de Bases de Datos

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

PRINCIPIOS PARA EL MODELADO

Page 240: Sistemas de Bases de Datos

• 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

Page 241: Sistemas de Bases de Datos

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

VehículoSe identifica por un código que puede serEl número de motor.

Page 242: Sistemas de Bases de Datos

• 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.

Page 243: Sistemas de Bases de Datos

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

Vehículo PilotoConducido por

Page 244: Sistemas de Bases de Datos

• 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

Page 245: Sistemas de Bases de Datos

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

Page 246: Sistemas de Bases de Datos

• 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

Motor Asiento

UML 2.0 ya sólo considera la composición

Page 247: Sistemas de Bases de Datos

• 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 ESTÁTICOS

Page 248: Sistemas de Bases de Datos

• 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.

DIAGRAMAS DE CLASES

Page 249: Sistemas de Bases de Datos

• 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.

ClaseClase

atributos

Métodos

SIMBOLOGÍA DE LOS DIAGRAMAS DE CLASES

Page 250: Sistemas de Bases de Datos

• 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.

Page 251: Sistemas de Bases de Datos

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

Dependencia

Page 252: Sistemas de Bases de Datos

• 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.

Page 253: Sistemas de Bases de Datos

• 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

Page 254: Sistemas de Bases de Datos

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.

Page 255: Sistemas de Bases de Datos

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

Page 256: Sistemas de Bases de Datos

• 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 «»

CONCEPTOS AVANZADOS

Page 257: Sistemas de Bases de Datos

• 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»

Page 258: Sistemas de Bases de Datos

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

Clase A Clase B«create»

Indica que la clase B es creada por la clase A

Page 259: Sistemas de Bases de Datos

• 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

Page 260: Sistemas de Bases de Datos

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

Equipo

Año

Jugador

Marcas

Page 261: Sistemas de Bases de Datos

• 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.

Page 262: Sistemas de Bases de Datos

• Asociaciones calificadas

Page 263: Sistemas de Bases de Datos

EJEMPLO

Page 264: Sistemas de Bases de Datos
Page 265: Sistemas de Bases de Datos
Page 266: Sistemas de Bases de Datos
Page 267: Sistemas de Bases de Datos

Asociación

Persona Compañíatrabaja-para

nombres. s.

nombredirección

jefe

Administra

empleado

* *

emplea-a

0.. 1

0.. 1

0.. 1

*

marido

casado-con

mujer

Page 268: Sistemas de Bases de Datos

Agregación

motor

coche

1

1

1

1

Persona

0..2*

+Padre

0..2

+Hijos

*

Page 269: Sistemas de Bases de Datos

Generalización

Page 270: Sistemas de Bases de Datos

Responsabilidades

Page 271: Sistemas de Bases de Datos

Herencia Múltiple

Page 272: Sistemas de Bases de Datos

Dependencia

Page 273: Sistemas de Bases de Datos

Herencia

Page 274: Sistemas de Bases de Datos

Polimorfismo

• Se relaciona fuertemente con herencia.

• Muchas formas.

Page 275: Sistemas de Bases de Datos
Page 276: Sistemas de Bases de Datos

III. Modelo RelacionalIII. Modelo Relacional

Page 277: Sistemas de Bases de Datos

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.

Page 278: Sistemas de Bases de Datos

• 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.

INTRODUCCIÓN

Page 279: Sistemas de Bases de Datos

¿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.

Page 280: Sistemas de Bases de Datos

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.

Page 281: Sistemas de Bases de Datos
Page 282: Sistemas de Bases de Datos

• 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.

Page 283: Sistemas de Bases de Datos

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.

Page 284: Sistemas de Bases de Datos

• Las bases de datos relacionales tienen un principio interesante, denominado:

Principio de Información

“Todo 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.”

Page 285: Sistemas de Bases de Datos

• 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).

Page 286: Sistemas de Bases de Datos

• 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.

ESTRUCTURA

Page 287: Sistemas de Bases de Datos

• 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}.

Page 288: Sistemas de Bases de Datos

• 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”.

Page 289: Sistemas de Bases de Datos

• 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.

Page 290: Sistemas de Bases de 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’;

Page 291: Sistemas de Bases de Datos

• 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.

Page 292: Sistemas de Bases de Datos

• 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

Page 293: Sistemas de Bases de Datos

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)

Page 294: Sistemas de Bases de Datos

• 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).

Page 295: Sistemas de Bases de Datos

• 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.

Page 296: Sistemas de Bases de Datos

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

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

Page 297: Sistemas de Bases de Datos

• 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.

Page 298: Sistemas de Bases de Datos

• 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.

Page 299: Sistemas de Bases de Datos

• 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.

Page 300: Sistemas de Bases de Datos

“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 ajenaONUM

PLANTILLA OFICINA: Oficina pertenece empleado

Page 301: Sistemas de Bases de Datos

una colección de valores Dominio

un identificador único para la relación La clave primaria

Número de columnas Grado

ColumnaAtributo

número de filas (tuplas) en la relaciónCardinalidad

una columna de la relaciónUn atributo

una fila en la relaciónUna tupla

una tabla con ciertas características Una relación

RESUMEN

Page 302: Sistemas de Bases de Datos

Clave Primaria

RE

LA

CIÓ

N

V#:V# PROVEEDOR:NOMBRE STATUS:STATUS CIUDAD:CIUDADv1 Fernando 20 D.F.v2 José 10 Guadalajarav3 Joel 30 Monterreyv4 Miguel 20 Tolucav5 Ivan 30 Cancún

TU

PL

A

C A

R D

I N

A L

I D

A D

ATRIBUTO

---- ---- --- --- --- --- --- ---

--- --- --

---- ---- --- --- --- --- --- ---

--- --- ------ ---- --- --- --- --- --- ---

--- --- --

D.FGUDALAJARA

ETC...

DO

MIN

IO

GRADO

• Resumen

RELACIÓN

Page 303: Sistemas de Bases de Datos

ESTRUCTURA DEL MODELO RELACIONAL

Page 304: Sistemas de Bases de Datos

Ejemplo de RELACIÓN:

Page 305: Sistemas de Bases de Datos

RESTRICCIONES DEL MODELO

Page 306: Sistemas de Bases de Datos
Page 307: Sistemas de Bases de Datos
Page 308: Sistemas de Bases de Datos

RESTRICCIONES SEMÁNTICAS DEL MODELO

Page 309: Sistemas de Bases de Datos
Page 310: Sistemas de Bases de Datos
Page 311: Sistemas de Bases de Datos
Page 312: Sistemas de Bases de Datos

EL MODELO Y LA ARQUITECTURA ANSI

Page 313: Sistemas de Bases de Datos

• 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.

EL MODELO RELACIONAL

Page 314: Sistemas de Bases de Datos

• 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.

NO PROCEDIMENTAL

Page 315: Sistemas de Bases de Datos

• 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

PROCEDIMENTAL

Page 316: Sistemas de Bases de Datos

• 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.

ÁLGEBRA VS. CÁLCULO

Page 317: Sistemas de Bases de Datos

• Principios básicos Modelo Relacional:

– Estructura de datos relacional.– Reglas de Integridad.– Manipulación (Álgebra Relacional).– Cálculo Relacional.

PRINCIPIOS BÁSICOS

Page 318: Sistemas de Bases de Datos

• Á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.

Page 319: Sistemas de Bases de Datos

• 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.

Page 320: Sistemas de Bases de Datos

• 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.

Page 321: Sistemas de Bases de Datos

• 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.

Page 322: Sistemas de Bases de Datos

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

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

CIUDADESMONTERREYMONTERREYD.F.MONTERREYACAPULCOMAZATLANVERACRUZYUCATAN

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

NOMBRES

xxxxxxxxxxxxxx

50

DOMINIOS

Relación Cliente

EJEMPLO

Page 323: Sistemas de Bases de Datos

• 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.

EL MODELO DE DATOS RELACIONAL

Page 324: Sistemas de Bases de Datos
Page 325: Sistemas de Bases de Datos

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.

Page 326: Sistemas de Bases de Datos

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.

REGLAS DE INTEGRIDAD

Page 327: Sistemas de Bases de Datos

“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

Page 328: Sistemas de Bases de Datos

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

Producto# Descripcion Precio Existencia100 TABLA 42101 PARED 750.00102 SILLA 13103 VESTIDOR 500.00 8

Relación: Producto

Clave Primaria

Nulos

Nulos

Page 329: Sistemas de Bases de Datos

“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.

RESTRICCIONES DE DOMINIO

Page 330: Sistemas de Bases de Datos

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

EJEMPLO

Page 331: Sistemas de Bases de Datos

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 .

INTEGRIDAD DE ENTIDADES

Page 332: Sistemas de Bases de Datos

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.

REGLAS DE INTEGRIDAD REFERENCIAL

Page 333: Sistemas de Bases de Datos

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.

Page 334: Sistemas de Bases de Datos

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).

Page 335: Sistemas de Bases de Datos

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

REGLAS DEL NEGOCIO

Page 336: Sistemas de Bases de Datos

Ejemplo:

Restricción en lenguaje natural:

1. Todos los proveedores deben tener valor del status entre 0 y 101Restricció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

Page 337: Sistemas de Bases de Datos

Atributo desconocido o ausencia de valorNulo

Asociar a cada atributo con un conjunto de posibles valoresRestricciones de dominio

Ningún componente de la clave primaria de una relación base puede aceptar nulos.

Regla de integridad de Entidades

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 Integridad referencial

Restricciones específicas sobre los datosReglas de negocio o Integridad del Usuario

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

Reglas de Integridad

RESUMEN

Page 338: Sistemas de Bases de Datos

• 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.

ÁLGEBRA RELACIONAL

Page 339: Sistemas de Bases de Datos

•Hay ocho operadores en el álgebra relacional que construyen relaciones y manipulan datos, estos son:

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

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

Operaciones básicas (fundamentales)

Operaciones derivadas (compuestas)

Page 340: Sistemas de Bases de Datos

• 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.

Page 341: Sistemas de Bases de Datos

• 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.

SELECCIÓN

Page 342: Sistemas de Bases de Datos

Enum Nombre Apellido Dirección Teléfono Puesto Fecha_nac Salario DNI Onum

EL21 Amelia Pastor Magallanes, 15 964 284 560 Director 12/10/62 30000 39432212E O5

EG37 Pedro Cubedo Bayarri, 11 964 535 690 Supervisor 24/3/57 18000 38766623X O3

EG14 Luis Collado Borriol, 35 964 522 230 Administ. 9/5/70 12000 24391223L O3

EA9 Rita Renau Casalduch, 964 257 550 Supervisor 19/5/60 18000 39233190F O7

EG5 Julio Prats Melilla, 23 964 524 590 Director 19/12/50 24000 25644309X O3

EL41 Carlos Baeza Herrero, 51 964 247 250 Supervisor 29/2/67 18000 39552133T O5

σ salario > 18000 (PLANTILLA)Resultado:

Enum Nombre Apellido Dirección Teléfono Puesto Fecha_nac Salario DNI Onum

EL21 Amelia Pastor Magallanes, 15 964 284 560 Director 12/10/62 30000 39432212E O5

EG5 Julio Prats Melilla, 23 964 524 590 Director 19/12/50 24000 25644309X O3

EJEMPLO

Page 343: Sistemas de Bases de Datos

Obtener todos los empleados que trabajan en la oficina 03, dada la siguiente relación (Plantilla)

Enum Nombre Apellido Dirección Teléfono Puesto Fecha_nac Salario DNI Onum

EL21 Amelia Pastor Magallanes, 15 964 284 560 Director 12/10/62 30000 39432212E O5

EG37 Pedro Cubedo Bayarri, 11 964 535 690 Supervisor 24/3/57 18000 38766623X O3

EG14 Luis Collado Borriol, 35 964 522 230 Administ. 9/5/70 12000 24391223L O3

EA9 Rita Renau Casalduch, 964 257 550 Supervisor 19/5/60 18000 39233190F O7

EG5 Julio Prats Melilla, 23 964 524 590 Director 19/12/50 24000 25644309X O3

EL41 Carlos Baeza Herrero, 51 964 247 250 Supervisor 29/2/67 18000 39552133T O5

σ Onum = “03” (PLANTILLA)Resultado:

Enum

Nombre

Apellido Dirección Teléfono PuestoFecha_nac

Salario

DNI Onum

EG37 Pedro Cubedo Bayarri, 11 964 535 690

Supervisor

24/3/57 18000 38766623X

O3

EG14 Luis Collado Borriol, 35 964 522 230

Administ. 9/5/70 12000 24391223L

O3

EG5 Julio Prats Melilla, 23 964 524 590

Director 19/12/50 24000 25644309X

O3

Page 344: Sistemas de Bases de Datos

Obtener todos los inmuebles de Castellón con un alquiler mensual de hasta 350. Dada la siguiente relación (Inmueble)

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

Resultado:

Inum Calle Area Población Tipo Hab Alquiler Pnum

IA14 Enmedio, 128 Centro Castellón Casa 6 600 P46

IL94 Riu Ebre, 24 Ronda Sur Castellón Piso 4 350 P87

IG4 Sorell, 5 Grao Castellón Piso 3 300 P40

IG36 Alicante,1 Segorbe Casa 3 325 P93

IG21 San Francisco, 10 Vinaroz Piso 5 550 P87

IG16 Capuchinos, 19 Rafalafena Castellón Piso 4 400 P93

Inum Calle Area Población Tipo Hab Alquiler Pnum

IL94 Riu Ebre, 24 Ronda Sur Castellón Piso 4 350 P87

IG4 Sorell, 5 Grao Castellón Piso 3 300 P40

Page 345: Sistemas de Bases de Datos

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.

PROYECCIÓN

Page 346: Sistemas de Bases de Datos

Obtener un listado de empleados mostrando su número, nombre, apellido y salario. Dada la siguiente Relación (Plantilla)

Enum Nombre Apellido Dirección Teléfono Puesto Fecha_nac Salario DNI Onum

EL21 Amelia Pastor Magallanes, 15 964 284 560 Director 12/10/62 30000 39432212E O5

EG37 Pedro Cubedo Bayarri, 11 964 535 690 Supervisor 24/3/57 18000 38766623X O3

EG14 Luis Collado Borriol, 35 964 522 230 Administ. 9/5/70 12000 24391223L O3

EA9 Rita Renau Casalduch, 964 257 550 Supervisor 19/5/60 18000 39233190F O7

EG5 Julio Prats Melilla, 23 964 524 590 Director 19/12/50 24000 25644309X O3

EL41 Carlos Baeza Herrero, 51 964 247 250 Supervisor 29/2/67 18000 39552133T O5

Π enum,nombre,apellido,salario (PLANTILLA)

Resultado:Enum Nombre Apellido Salario

EL21 Amelia Pastor 30000

EG37 Pedro Cubedo 18000

EG14 Luis Collado 12000

EA9 Rita Renau 18000

EG5 Julio Prats 24000

EL41 Carlos Baeza 18000

EJEMPLO

Page 347: Sistemas de Bases de Datos

• 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.

PRODUCTO CARTESIANO

Page 348: Sistemas de Bases de Datos

número-préstamo

P-11

P-14

P-15

P-16

nombre-cliente

Gómez

Fernández

(Prestamo) X (Cliente)

nombre cliente número préstamo

Gómez P-11

Gómez P-14

Gómez P-15

Gómez P-16

Fernández P-11

Fernández P-14

P-15

Fernández P-16

Fernández

392

EJEMPLO

Page 349: Sistemas de Bases de Datos

• 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).

UNIÓN

Page 350: Sistemas de Bases de Datos

Obtener un listado de las áreas en las que hay oficinas o inmuebles para alquilar. Onum Calle Area Población Teléfono Fax

O5 Enmedio, 8 Centro Castellón 964 201 240 964 201 340

O7 Moyano, s/n Centro Castellón 964 215 760 964 215 670

O3 San Miguel, 1 Villarreal 964 520 250 964 520 255

O4 Trafalgar, 23 Grao Castellón 964 284 440 964 284 420

O2 Cedre, 26 Villarreal 964 525 810 964 252 811

Inum Calle Area Población Tipo Hab Alquiler Pnum

IA14 Enmedio, 128 Centro Castellón Casa 6 600 P46

IL94 Riu Ebre, 24 Ronda Sur Castellón Piso 4 350 P87

IG4 Sorell, 5 Grao Castellón Piso 3 300 P40

IG36 Alicante,1 Segorbe Casa 3 325 P93

IG21 San Francisco, 10 Vinaroz Piso 5 550 P87

IG16 Capuchinos, 19 Rafalafena Castellón Piso 4 400 P93

( Π área (OFICINA) ) U

( Π área (INMUEBLE) )Resultado:

Area

Centro

Grao

Ronda Sur

Rafalafena

EJEMPLO

Page 351: Sistemas de Bases de Datos

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).

REUNIÓN NATURAL (NATURAL JOIN)

Page 352: Sistemas de Bases de Datos

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))número-préstamo nombre-sucursal importe

P-11 Collado Mediano 900

P-14 Centro 1500

P-15 Navacerrada 1500

P-16 Navacerrada 1300

P-17 Centro 1000

P-23 Moralzarzal 2000

P-93 Becerril 500

nombre cliente número préstamo

Fernández P-16

Gómez P-93

Gómez P-15

López P-14

Pérez P-17

Santos P-11

Sotoca P-23

Valdivieso P-17

Π nombre-cliente, número-

préstamo, importe

(prestatario |x| cliente)

nombre-cliente

número - préstamo

Importe

Fernández P-16 1.300

Gómez P-23 2.000

Gómez P-11 900

López P-15 1.500

Pérez P-93 500

Santos P-17 1.000

Sotoca P-14 1.500

Valdivieso P-17 1.000

EJEMPLO

Page 353: Sistemas de Bases de Datos

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.

DIVISIÓN

Page 354: Sistemas de Bases de Datos

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)

P87

Pnum

ÁLGEBRA RELACIONAL

Page 355: Sistemas de Bases de Datos

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

Page 356: Sistemas de Bases de Datos

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.

DIFERENCIA

Page 357: Sistemas de Bases de Datos

Obtener un listado de todas las poblaciones en donde hay una oficina y no hay inmuebles para alquilar. Dada las siguientes relaciones

Onum Calle Area Población Teléfono Fax

O5 Enmedio, 8 Centro Castellón 964 201 240 964 201 340

O7 Moyano, s/n Centro Castellón 964 215 760 964 215 670

O3 San Miguel, 1 Villarreal 964 520 250 964 520 255

O4 Trafalgar, 23 Grao Castellón 964 284 440 964 284 420

O2 Cedre, 26 Villarreal 964 525 810 964 252 811

Inum Calle Area Población Tipo Hab Alquiler Pnum

IA14 Enmedio, 128 Centro Castellón Casa 6 600 P46

IL94 Riu Ebre, 24 Ronda Sur Castellón Piso 4 350 P87

IG4 Sorell, 5 Grao Castellón Piso 3 300 P40

IG36 Alicante,1 Segorbe Casa 3 325 P93

IG21 San Francisco, 10 Vinaroz Piso 5 550 P87

IG16 Capuchinos, 19 Rafalafena Castellón Piso 4 400 P93

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

Población

Villarreal

EJEMPLO

Page 358: Sistemas de Bases de Datos

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)

INTESECCIÓN

Page 359: Sistemas de Bases de Datos

Obtener los inmuebles de 3 habitaciones que han recibido visitas de inquilinos. Dada las siguientes relaciones

Inum Calle Area Población Tipo Hab Alquiler Pnum

IA14 Enmedio, 128 Centro Castellón Casa 6 600 P46

IL94 Riu Ebre, 24 Ronda Sur Castellón Piso 4 350 P87

IG4 Sorell, 5 Grao Castellón Piso 3 300 P40

IG36 Alicante,1 Segorbe Casa 3 325 P93

IG21 San Francisco, 10 Vinaroz Piso 5 550 P87

IG16 Capuchinos, 19 Rafalafena Castellón Piso 4 400 P93

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

Qnum Inum Fecha Comentario

Q56 IA14 24/11/99 muy pequeño

Q76 IG4 20/10/99 muy lejos

Q56 IG4 26/11/99

Q62 IA14 14/11/99 no tiene salón

N

IG4

EJEMPLO

Page 360: Sistemas de Bases de Datos

Álgebra Relacional ExtendidaÁlgebra Relacional Extendida

Page 361: Sistemas de Bases de Datos

• 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.

PROYECCIÓN EXTENDIDA

Page 362: Sistemas de Bases de Datos

No_Cta Materia Calificacon95481904 Leng. de Prog 950385974 Algoritmos 1098385928 Autómatas 898792838 I. A. 897218294 Prog. Lógica 7

Materia

No_Cta Materia Calificacon-195481904 Leng. de Prog 850385974 Algoritmos 998385928 Autómatas 798792838 I. A. 797218294 Prog. Lógica 6

Resultado

EJEMPLO

Page 363: Sistemas de Bases de Datos

• 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.

REUNIÓN EXTERNA

Page 364: Sistemas de Bases de Datos

• Esta operación tiene tres formas:

Page 365: Sistemas de Bases de Datos

• 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.

Page 366: Sistemas de Bases de Datos

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

Page 367: Sistemas de Bases de Datos

No_Cta Nombre Sexo Nacionalidad95481904 Juan M Mexicana50385974 Edgar M Mexicana97218294 Elizabeth F Peruana

No_Cta Materia Calificacon95481904 Leng. de Prog 950385974 Algoritmos 1098385928 Autómatas 898792838 I. A. 8

Alumno Materia

No_Cta Nombre Sexo Nacionalidad No_Cta Materia Calificacon95481904 Juan M Mexicana 95481904 Leng. de Prog 950385974 Edgar M Mexicana 50385974 Algoritmos 1097218294 Elizabeth F Peruana null null null

Page 368: Sistemas de Bases de Datos

No_Cta Nombre Sexo Nacionalidad No_Cta Materia Calificacon95481904 Juan M Mexicana 95481904 Leng. de Prog 950385974 Edgar M Mexicana 50385974 Algoritmos 10

null null null null 98385928 Autómatas 8null null null null 98792838 I. A. 8

No_Cta Nombre Sexo Nacionalidad No_Cta Materia Calificacon95481904 Juan M Mexicana 95481904 Leng. de Prog 950385974 Edgar M Mexicana 50385974 Algoritmos 10

null null null null 98385928 Autómatas 8null null null null 98792838 I. A. 8

97218294 Elizabeth F Peruana null null null

Page 369: Sistemas de Bases de Datos

• 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.

FUNCIONES DE AGREGACIÓN

Page 370: Sistemas de Bases de Datos

• 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.

Page 371: Sistemas de Bases de Datos

• 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.

AGRUPACIÓN

Page 372: Sistemas de Bases de Datos

Letra Numero Nombrea 1 Angela 2 Amaliaa 4 Armandob 1 Betob 2 Bernabéc 3 Carlosc 4 Cecilia

Letra max(numero) count(nombre) avg(numero)a 4 3 2.333b 2 2 1.5c 4 2 3.5

Muestra

EJEMPLO

Page 373: Sistemas de Bases de Datos

• 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.

RENOMBRAMIENTO

Page 374: Sistemas de Bases de Datos

ρ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.

Page 375: Sistemas de Bases 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

MODIFICACIONES DE LA BASE DE DATOS

Page 376: Sistemas de Bases de Datos

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

r ← r U E

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

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

INSERCIÓN

Page 377: Sistemas de Bases de Datos

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))

ACTUALIZACIÓN

Page 378: Sistemas de Bases de Datos

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

create view v as Expresión

CREACIÓN DE VISTAS

Page 379: Sistemas de Bases de Datos

• 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.

CÁLCULO RELACIONAL

Page 380: Sistemas de Bases de Datos

• 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

[Argumento] [Función]

Page 381: Sistemas de Bases de Datos

Existen dos lenguajes lógicos de manipulación para el modelo relacional:

• El Cálculo Relacional de Tuplas.

• El Cálculo Relacional de Dominios.

Page 382: Sistemas de Bases de Datos

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

CÁLCULO RELACIONAL DE TUPLAS

Page 383: Sistemas de Bases de Datos

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.

VARIABLE TUPLA

Page 384: Sistemas de Bases de Datos

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.

Page 385: Sistemas de Bases de Datos

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)

∀ x F

∃ x F

Fórmulas (Ejemplos):x.A = y.Bx.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')

FÓRMULAS

Page 386: Sistemas de Bases de Datos

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.

Donde:

t es la variable tupla.

P( t ) es cualquier formula

Su forma general es:

{ t / P ( t )}

EVALUACIÓN DE FÓRMULAS

Page 387: Sistemas de Bases de Datos

• 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:

EJEMPLOS

Page 388: Sistemas de Bases de Datos

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.

Page 389: Sistemas de Bases de Datos

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.

Page 390: Sistemas de Bases de Datos

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:

Page 391: Sistemas de Bases de Datos

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.

CÁLCULO RELACIONAL DE DOMINIOS

Page 392: Sistemas de Bases de Datos

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.

Page 393: Sistemas de Bases de Datos

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.

Page 394: Sistemas de Bases de Datos

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.

Evaluación de Fórmulas:

Page 395: Sistemas de Bases de Datos

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:

EJEMPLOS

Page 396: Sistemas de Bases de Datos

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

Page 397: Sistemas de Bases de Datos

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

Page 398: Sistemas de Bases de Datos

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:

Page 399: Sistemas de Bases de Datos

CRT VS. CRD

Page 400: Sistemas de Bases de Datos
Page 401: Sistemas de Bases de Datos

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-by-

Example).

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.

QUERY BY EXAMPLE

Page 402: Sistemas de Bases de Datos

• 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.

Page 403: Sistemas de Bases de Datos

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:

Page 404: Sistemas de Bases de Datos

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

Todos las cuentas con balance entre 1300 y 1500:

Page 405: Sistemas de Bases de Datos

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.

DATALOG

Page 406: Sistemas de Bases de Datos

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.

SIGNIFICADO DE LAS REGLAS LÓGICAS

Page 407: Sistemas de Bases de Datos

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).

Page 408: Sistemas de Bases de Datos

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.

EJEMPLO

Page 409: Sistemas de Bases de Datos

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.

Page 410: Sistemas de Bases de Datos

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: extencionalmadre(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).

PREDICADOS INTENCIONALES Y EXTENCIONALES

Page 411: Sistemas de Bases de Datos

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).

RECURSIVIDAD Y GRAFOS DE DEPENDENCIA

Page 412: Sistemas de Bases de Datos

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).

EJEMPLO

Page 413: Sistemas de Bases de Datos

• Reglas de CoddReglas de Codd

Page 414: Sistemas de Bases de Datos

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.

ANTECEDENTES

Page 415: Sistemas de Bases de Datos

1. Reglas fundamentales

2. Reglas estructurales

3. Reglas de integridad

4. Reglas de manipulación de datos

5. Reglas de independencia de datos

Las reglas pueden ser divididas en 5 áreas funcionales:

REGLAS DE CODD

Page 416: Sistemas de Bases de Datos

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.

1. FUNDAMENTALES (0 Y 12)

Page 417: Sistemas de Bases 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.

Page 418: Sistemas de Bases de Datos

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.

2. ESTRUCTURALES (1 Y 6)

Page 419: Sistemas de Bases de Datos

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.

Page 420: Sistemas de Bases de 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.

Page 421: Sistemas de Bases de Datos

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.

3. INTEGRIDAD (3 y 10)

Page 422: Sistemas de Bases de Datos

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:

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

Verdadero=nullORVerdadero

etc.

Falso=nullANDFalso

null=nullANDVerdadero

null=nullANDnull

Page 423: Sistemas de Bases de Datos

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.

Page 424: Sistemas de Bases de Datos

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).

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

Page 425: Sistemas de Bases de Datos

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.

Page 426: Sistemas de Bases de Datos

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).

Page 427: Sistemas de Bases de Datos

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.

Page 428: Sistemas de Bases de Datos

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).

Page 429: Sistemas de Bases de Datos

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.

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

Page 430: Sistemas de Bases de Datos

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.

Page 431: Sistemas de Bases de Datos

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.

Page 432: Sistemas de Bases de Datos

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.

Page 433: Sistemas de Bases de Datos

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 distribuidas

Page 434: Sistemas de Bases de Datos

29290Distributed database managementRX

1798Principles of language designRL

1688Principles of DBMS designRD

541ProtectionRP

1073FunctionsRF

16106AutorizationRA

808ViewsRV

1138CatalogRC

342311IntegrityRI

20614ManipulationRM

14140IndicatorsRJ

13103QualifiersRQ

22148Commands for the DBARE

1477NamingRN

44422Advenced operatorsRZ

37631Basic operatorsRB

963Data TypesRT

1459StructureRS

TotalBasicFundDESCRIPCIÓNCLASE

REGLAS DE CODD

Page 435: Sistemas de Bases de Datos

Non-SubversionRI-1612

Distribution independenceRP-411

Integrity independenceRP-310

Logical data independenceRP-29

Physical data independenceRP-18

High level languageRM-47

View updatabilityRV-4,RV-56

Comprehensive data sublanguage

RM-35

Active catalogRC-14

Missing informationRS-13,RM-103

Guaranteed accessRM–12

Information ruleRS–11

NombreCaracterística RM/V2Regla de 1985

Comparación con las reglas de Codd originales (las 12):

Page 436: Sistemas de Bases de Datos

Número de filas en una tabla-R

Cardinalidad de una relación

Fila en una tabla-RTupla

Tipo de datos extendidoDominio

Columna de una tabla-RAtributo

tabla-R con n columnasRelación de grado n

Término en la Base de DatosTérmino Matemático

Terminología:Una tabla-R es un tipo especial de subconjunto

No existe el concepto de posición ni duplicados

Una tabla-R es un tipo especial de subconjunto

No existe el concepto de posición ni duplicados

DESCRIPCIÓN DE LAS CATEGORÍAS

Page 437: Sistemas de Bases de Datos

• 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.

RS - ESTRUCTURA

Page 438: Sistemas de Bases de Datos

• 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.

RT – TIPOS DE DATOS EXTENDIDOS

Page 439: Sistemas de Bases de Datos

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 .

RB – OPERADORES BÁSICOS

Page 440: Sistemas de Bases de Datos

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.

RZ – OPERADORES AVANZADOS

Page 441: Sistemas de Bases de Datos

• 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.

RN – REGLAS DE NOMBRAMIENTO

Page 442: Sistemas de Bases de Datos

• 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.

RA – AUTORIZACIÓN

Page 443: Sistemas de Bases de Datos

• 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.

RF – FUNCIONES ESCALARES Y DE AGREGACIÓN

Page 444: Sistemas de Bases de Datos

• 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.

RP – PROTECCIÓN FÍSICA

Page 445: Sistemas de Bases de Datos

• 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.

RD – PRINCIPIOS DE DISEÑO DE SMBD

Page 446: Sistemas de Bases de Datos

• 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.

RL – DISEÑO DE LENGUAJES RELACIONALES

Page 447: Sistemas de Bases de Datos

• 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.

RX – ADMINISTRACIÓN DE BD DISTRIBUIDAS

Page 448: Sistemas de Bases de Datos

• 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.

RE – COMANDOS PARA EL ABD

Page 449: Sistemas de Bases de Datos

• 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.

RQ – CALIFICADORES

Page 450: Sistemas de Bases de Datos

• 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.

RM – MANIPULACIÓN

Page 451: Sistemas de Bases de Datos

• 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).

RI – INTEGRIDAD

Page 452: Sistemas de Bases de Datos

• 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.

RC - CATÁLOGO

Page 453: Sistemas de Bases de Datos

• 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.

RV – VISTAS

Page 454: Sistemas de Bases de Datos

• 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.

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

Page 455: Sistemas de Bases de Datos

Características Orientadas a la Estructura y a los Datos

Page 456: Sistemas de Bases de Datos

• 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 representadas internamente por datos almacenados en alguna forma definida por la implementación, de otra forma son llamadas relaciones derivadas, como las vistas que se crean a partir de las primeras sin contener datos.

•Las relaciones base son aquellas que estan representadas internamente por datos almacenados en alguna forma definida por la implementación, de otra forma son llamadas relaciones derivadas, como las vistas que se crean a partir de las primeras sin contener datos.

RS-1 – LA INFORMACIÓN

Page 457: Sistemas de Bases de Datos

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

RS-2 – LIBRES DE CONCEPTOS POSICIONALES

Page 458: Sistemas de Bases de Datos

• 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-3 - NO DUPLICIDAD DE FILAS EN RELACIONES

Page 459: Sistemas de Bases de Datos

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-4 – PORTABILIDAD DE LA INFORMACIÓN

Page 460: Sistemas de Bases de Datos

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

Representación al almacenar

Esquema interno

Relaciones baseEsquema conceptual

VistasEsquema externo

Término-RTérmino ANSI

RS-5 – ARQUITECTURA EN 3 NIVELES

Page 461: Sistemas de Bases de Datos

• 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-6 - DOMINIOS COMO TIPO DE DATO EXTENDIDO

Page 462: Sistemas de Bases de Datos

• 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-7 – DESCRIPCIÓN DE COLUMNAS

Page 463: Sistemas de Bases de Datos

• 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-8 – UNA LLAVE PRIMARIA EN CADA TABLA-R BASE

Page 464: Sistemas de Bases de Datos

• 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-9 – LLAVE PRIMARIA EN ALGUNAS VISTAS

Page 465: Sistemas de Bases de Datos

• 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-10 – LLAVE FORANEA

Page 466: Sistemas de Bases de Datos

• 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-11 – DOMINIOS COMPUESTOS

Page 467: Sistemas de Bases de Datos

• 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-12 – COLUMNAS COMPUESTAS

Page 468: Sistemas de Bases de Datos

• 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-13 – INFORMACIÓN FALTANTE REPRESENTADA

Page 469: Sistemas de Bases de Datos

• 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 artículo de 1988 llamado “The universal-relational data model for logical independence” buscando una forma para lograr que si hay una modificación en la base de datos (ej. porque dos tablas se convierten en una sola) no sea necesario modificar la aplicación, y no se haga por medio de crear Vistas innecesarias desde el principio peviendo posibles modificaciones futuras.

•Moshe Y. Vardi habla sobre la “relacion universal” en su artículo de 1988 llamado “The universal-relational data model for logical independence” buscando una forma para lograr que si hay una modificación en la base de datos (ej. porque dos tablas se convierten en una sola) no sea necesario modificar la aplicación, y no se haga por medio de crear Vistas innecesarias desde el principio peviendo posibles modificaciones futuras.

RS-14 – EVITANDO LA RELACIÓN UNIVERSAL

Page 470: Sistemas de Bases de Datos

Operadores Básicos

Page 471: Sistemas de Bases de Datos

• 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-1 – REDUCIR EL ÉNFASIS EN EL PRODUCTO CARTESIANO COMO

OPERADOR

Page 472: Sistemas de Bases de Datos
Page 473: Sistemas de Bases de Datos

• 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.

RB-2 – EL OPERADOR PROYECCIÓN

Page 474: Sistemas de Bases de Datos

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

Sobre la tabla:

Page 475: Sistemas de Bases de Datos

• 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.

RB-3 a 12 – EL OPERADOR THETA-SELECT

Page 476: Sistemas de Bases de Datos

1) RB-3 Igualdad2) RB-4 Desigualdad3) RB-5 Menor que4) RB-6 Menor o igual que5) RB-7 Mayor que6) RB-8 Mayor o igual que7) RB-9 El más grande que sea menor que8) RB-10 El más grande que sea menor o igual que9) RB-11 El más chico que sea mayor que10)RB-12 El más chico que sea mayor o igual que

Page 477: Sistemas de Bases de Datos

• 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 cualquier combinación de los términos de comparación utilizando los conectores lógicos NOT, OR, AND e IMPLICA

•Los valores de verdad pueden ser cualquier combinación de los términos de comparación utilizando los conectores lógicos NOT, OR, AND e IMPLICA

RB-13 – EXTENSIÓN BOOLEANA THETA-SELECT

Page 478: Sistemas de Bases de Datos

• 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.

RB-14 a 23 – OPERADOR THETA-JOIN

Page 479: Sistemas de Bases de Datos

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

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

Page 480: Sistemas de Bases de Datos

• 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 términos de comparación utilizando los conectores lógicos NOT, OR, AND e IMPLICA

•Los valores de verdad pueden ser cualquier combinación de los términos de comparación utilizando los conectores lógicos NOT, OR, AND e IMPLICA

RB-24 – EXTENSIÓN BOOLEANA THETA-JOIN

Page 481: Sistemas de Bases de Datos

• 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-25 – EL OPERADOR DE JOIN NATURAL

Page 482: Sistemas de Bases de Datos

• 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-26 – EL OPERADOR DE UNIÓN

Page 483: Sistemas de Bases de Datos
Page 484: Sistemas de Bases de Datos

• 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-27 – OPERADOR DE INTERSECCIÓN

Page 485: Sistemas de Bases de Datos
Page 486: Sistemas de Bases de Datos

• 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-28 – OPERADOR DIFERENCIA

Page 487: Sistemas de Bases de Datos
Page 488: Sistemas de Bases de Datos

• 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-29 – OPERADOR DIVISIÓN RELACIONAL

Page 489: Sistemas de Bases de Datos
Page 490: Sistemas de Bases de Datos

• 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-30 – ASIGNACIÓN RELACIONAL

Page 491: Sistemas de Bases de Datos

• 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-31 – OPERADOR INSERT

Page 492: Sistemas de Bases de Datos

• 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-32 – OPERADOR UPDATE

Page 493: Sistemas de Bases de Datos

• 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-33 – ACTUALIZACIÓN DE PK CON CASCADA

Page 494: Sistemas de Bases de Datos

• 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-34 – ACTUALIZACIÓN DE PK MARCANDO FKs

Page 495: Sistemas de Bases de Datos

• 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-35 – OPERADOR DELETE

Page 496: Sistemas de Bases de Datos

• 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-36 – BORRADO CON CASCADA

Page 497: Sistemas de Bases de Datos

• 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.

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

Page 498: Sistemas de Bases de Datos

Operadores Avanzados

Page 499: Sistemas de Bases de Datos

• 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-1 – DELIMITANDO UNA RELACIÓN

Page 500: Sistemas de Bases de Datos
Page 501: Sistemas de Bases de Datos

• 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-2 – EXTENDER LA DESCRIPCIÓN DE UNA RELACIÓN PARA INCLUIR COLUMNAS

DE OTRA

Page 502: Sistemas de Bases de Datos

• 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 semi-join 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-3 a 12 – SEMI-THETA-JOIN

Page 503: Sistemas de Bases de Datos

• 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 equi-join 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-13 – LEFT OUTER EQUI-JOIN

Page 504: Sistemas de Bases de Datos
Page 505: Sistemas de Bases de Datos

• 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-14 – RIGHT OUTER EQUI-JOIN

Page 506: Sistemas de Bases de Datos
Page 507: Sistemas de Bases de Datos

• La reunión externa simétrica (symmetric outer equi-join) 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-15 – EQUI-JOIN EXTERNOS SIMÉTRICOS

Page 508: Sistemas de Bases de Datos
Page 509: Sistemas de Bases de Datos

• 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-16 – LEFT OUTER NATURAL JOIN

Page 510: Sistemas de Bases de Datos

• 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-17 – RIGHT OUTER NATURAL JOIN

Page 511: Sistemas de Bases de Datos

• 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-18 – SYMMETRIC OUTER NATURAL JOIN

Page 512: Sistemas de Bases de Datos

• 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-19 – OUTER UNION

Page 513: Sistemas de Bases de Datos

• 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-20 – OUTER SET DIFFERENCE

Page 514: Sistemas de Bases de Datos
Page 515: Sistemas de Bases de Datos

• Se representa por:S \ ∩ / T

RZ-21 – INTERSECCIÓN INTERNA DETERMINADA

Page 516: Sistemas de Bases de Datos

• Las 4 uniones internas están basadas en los comparadores:

Menor, menor o igual, mayor y mayor o igual.

RZ-22 a 25 – UNIONES – T INTERNOS

Page 517: Sistemas de Bases de Datos
Page 518: Sistemas de Bases de Datos

• 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-26 a 37 – UNIONES – T EXTERNAS

Page 519: Sistemas de Bases de Datos

• 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-38 – SELECT DEFINIDO POR EL USUARIO

Page 520: Sistemas de Bases de Datos

• 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-39 – UNIÓN DEFINIDA POR EL USUARIO

Page 521: Sistemas de Bases de Datos

• 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-40 – UNIÓN RECURSIVA

Page 522: Sistemas de Bases de Datos

• 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-41 – OPERADOR SEMI-INSERT

Page 523: Sistemas de Bases de Datos

• 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-42 – OPERADOR SEMI-UPDATE

Page 524: Sistemas de Bases de Datos

• 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

RZ-43 y 44 – SEMI-ARCHIVE Y SEMI-DELETE

Page 525: Sistemas de Bases de Datos

• Clasificación de información faltante por tipo y por razón

Ausente

Tuplas completas Valor-de-BD

No-eventos

Eventos

desconocidos

para el SMBD

Eventos

no aplicables

Aplicable

(Marca-A)

No aplicable

(Marca-I)Otro

•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)

•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)

MANEJO DE INFORMACIÓN FALTANTE EN MR V2

Page 526: Sistemas de Bases de Datos

• 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.

Page 527: Sistemas de Bases de Datos

Se debe dejar de usar el término “valor nulo” por las siguientes razones:

1. El SMBD no maneja las marcas como si fueran valores.

1. Ahora hay dos tipos de marcas, donde antes solamente existía una.

1. Algunos lenguajes anfitriones manejan objetos llamados “nulos” que su significado es algo muy distinto a las marcas en la base de datos.

1. En inglés es un término mas adecuado.

Page 528: Sistemas de Bases de Datos

• 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:

I + x = Ix + I = II + I = I

I + A = IA + I = IA + A = A

A + x = Ax + A = Ax + x = 2x

• 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.

Page 529: Sistemas de Bases de Datos

• 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.

Page 530: Sistemas de Bases de Datos

• 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.

PK Y FK EN RELACIONES BASE

Page 531: Sistemas de Bases de Datos

• 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.

FILAS CON MARCAS-A Y/O MARCAS-I

Page 532: Sistemas de Bases de Datos

• 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

APLICACIÓN DE IGUALDAD

Page 533: Sistemas de Bases de Datos

vf

mm

fv

not PP

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

LÓGICA DE 3 VALORES DEL RM/V2 (RM V1)

Page 534: Sistemas de Bases de Datos

vf

mm

fv

not PP

fmvf

mmvm

vvvv

P

fmv

QP ۷ Q

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

Page 535: Sistemas de Bases de Datos

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

fmvf

mmvm

vvvv

P

fmv

QP ۷ Q

ffff

fmmm

fmvv

P

fmv

QP ٨ Q

vf

mm

fv

not PP

Page 536: Sistemas de Bases de Datos

aa

vf

ii

fv

not PP

a = Marca-A, i = Marca-I

LÓGICA DE 4 VALORES DEL RM/V2 (RM V2)

Page 537: Sistemas de Bases de Datos

aa

vf

ii

fv

not PP

v

v

v

v

v

fiai

ffaf

aaaa

vvvv

P

fia

QP ۷ Q

a = Marca-A, i = Marca-I

Page 538: Sistemas de Bases de Datos

a = Marca-A, i = Marca-I

aa

vf

ii

fv

not PP

v

v

v

v

v

iiai

fIaf

aaaa

vvvv

P

fia

QP ۷ Q

f

i

a

v

v

fiii

ffff

fiaa

fiav

P

fia

QP ٨ Q

Page 539: Sistemas de Bases de Datos

• 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.

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

Page 540: Sistemas de Bases de Datos

• 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.

ORDENACIÓN DE VALORES Y MARCAS

Page 541: Sistemas de Bases de Datos

• 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.

FUNCIONES ESCALARES APLICADAS A ARGUMENTOS “MARCADOS”

Page 542: Sistemas de Bases de Datos

• 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).

APLICACIÓN DE FUNCIONES ESTADÍSTICAS

Page 543: Sistemas de Bases de Datos

• 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 o2.- Uno del par es marcado el otro no o3.- 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

Page 544: Sistemas de Bases de Datos

Cuernavaca15,000D01AdriánE123

Puebla— A— ARodrigoE224

Colima— AD12PedroE575

Colima12,000— AJoséE239

Colima12,000— AJoséE912

Zitácuaro10,000D12PanchoE107

H_CiudadSalarioDep#ENombreEmp#EMP

ELIMINACIÓN DE FILAS DUPLICADAS

Page 545: Sistemas de Bases de Datos

Cuernavaca15,000D01AdriánE123

Puebla— A— ARodrigoE224

Colima— AD12PedroE575

Colima12,000— AJoséE239

Colima12,000— AJoséE912

Citácuaro10,000D12PanchoE107

H_CiudadSalarioDep#ENombreEmp#

E <- EMP [Dep#, Salario]

EMP

— A— A***

15,000D01

— AD12

12,000— A**

12,000— A*

10,000D12

SalarioDep#E’

15,000

— A

12,000

10,000

Salario

D01

##D12

#— A

D12

Dep#E

Page 546: Sistemas de Bases de Datos

• 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.

MARCAS GENERADAS POR OPERADORES

Page 547: Sistemas de Bases de Datos

•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 ventasSELECT serial_number FROM employeesWHERE comission IS NOT I-MARKED

2) Todos los empleados que no podrían recibir comisiones por ventasSELECT serial_number FROM employeesWHERE comission IS I-MARKED

CAMBIOS NECESARIOS EN EL LENGUAJE

Page 548: Sistemas de Bases de Datos

IV. SQLIV. SQL

Page 549: Sistemas de Bases de Datos

• 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.

INTRODUCCIÓN

Page 550: Sistemas de Bases de Datos

– 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.

Page 551: Sistemas de Bases de Datos

• 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.

HISTORIA

Page 552: Sistemas de Bases de Datos

• 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.

Page 553: Sistemas de Bases de Datos

• 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).

Page 554: Sistemas de Bases de Datos

• 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.

Page 555: Sistemas de Bases de Datos

• 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.

Page 556: Sistemas de Bases de Datos

• 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.

Page 557: Sistemas de Bases de Datos

• 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 SQL-92) el cual ocupa cerca de 600 páginas mientras que SQL1 tenía menos de 100.

Page 558: Sistemas de Bases de Datos

• 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.

Page 559: Sistemas de Bases de Datos

• 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.

Page 560: Sistemas de Bases de Datos

Ashton-state y Microsoft anuncian SQL Server para 0S/2.1988

Se ratifica el estándar ISO SQL1.1987

Se ratifica el estándar SQL1.Sybase introduce un SMBDR para el procesamiento de transacciones.

1986

IBM anuncia DB2.1983

ANSI forma el comité para estándares de SQL.1982

Relational Technology introduce Ingres.IBM anuncia SQL/DS.

1981

Oracle introduce el primer SMBDR comercial.1979

Se realizan pruebas de System/R con clientes.1978

IBM comienza el proyecto System/R.Se publica el primer articulo que describe el lenguaje SEQUEL.

1974

Codd define el modelo relacional de bases de datos.1970

EVENTOFECHA

Page 561: Sistemas de Bases de Datos

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.

1997

Se publican el API estándar para el acceso OLAP a bases de datos y la prueba de rendimiento OLAP.

1996

Se distribuye comercialmente tecnología paralela de servidores de bases de datos.1994

Por primera vez se distribuyen sistemas de almacenamiento de datos SQL especializados.Por primera vez se distribuyen productos ODBC.

1993

Microsoft publica la especificación ODBC.Se ratifica el estándar ANSI SQL2 (SQL.2).Se publica la pruba de rendimiento TCP-C (OLTP).

1992

Se publica la especificación de acceso a bases de datos SQL Access Group.1991

Se publica la prueba de rendimiento TCP-B.1990

Se publica la primera prueba de rendimiento TPC (TPC-A).1989

EVENTOFECHA

Page 562: Sistemas de Bases de Datos

Gartner clasifica a IBM como primer fabricante de bases de datos, superando a Oracle.2002

La posibilidad de integración de XML aparece en los principales productos SMBDR.IBM adquiere el negocio de bases de datos de Informix.

2001

Oracle introduce servidores de aplicaciones con caché integrada de bases de datos.Microsoft introduce SQL Server 2000, dirigido a las aplicaciones empresariales.

2000

J2EE estandariza el acceso JDBC a bases de datos desde los servidores de aplicaciones.1999

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.

1998

EVENTOFECHA

Page 563: Sistemas de Bases de Datos

• 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.

Page 564: Sistemas de Bases de Datos

Utilizada para eliminar filas de una tabla en una base de datosDELETE

Utilizada para modificar los valores de los datos en la base de datos.

UPDATE

Utilizada para añadir filas de datos a una tabla en la base de datos.INSERT

Utilizada para recuperar datos de la base de datos.SELECT

DESCRIPCIÓNSENTENCIA

LENGUAJE DE MANIPULACIÓN DE DATOS (LDM)

Page 565: Sistemas de Bases de Datos

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

ALTER

Empleada para eliminar tablas, vistas, esquemas, dominios e índices.

DROP

Utilizada para crear nuevas tablas, vistas, esquemas, dominios e índices.

CREATE

DESCRIPCIÓN SENTENCIA

LENGUAJE DE DEFINICIÓN DE DATOS (LDD)

Page 566: Sistemas de Bases de Datos

Utilizada para abortar la transacción actualROLLBACK

Se Utiliza para finalizar la transacción actual.COMMIT

Utilizada eliminar privilegios de acceso a los usuarios.REVOKE

Se utiliza para conceder privilegios de acceso a los usuarios.GRANT

DESCRIPCIÓNSENTENCIA

LENGUAJE DE CONTROL DE DATOS (LCD)

Page 567: Sistemas de Bases de Datos

• Capacidades de la sentencia SELECT

SelecciónProyección

Tabla 1 Tabla 2

Tabla 1Tabla 1

Reunión

LDM: SELECT

Page 568: Sistemas de Bases de Datos

• 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],...];

Page 569: Sistemas de Bases de Datos

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

SELECT *FROM departments;

Page 570: Sistemas de Bases de Datos

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

SELECT department_id, location_idFROM departments;

Page 571: Sistemas de Bases de Datos

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

LMD: SELECT - OPERADORES

Page 572: Sistemas de Bases de Datos

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

SELECT last_name, salary, salary + 300FROM employees;

Page 573: Sistemas de Bases de Datos

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.

* / + -

Page 574: Sistemas de Bases de Datos

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

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

Page 575: Sistemas de Bases de Datos

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;

Page 576: Sistemas de Bases de Datos

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

SELECT last_name, 12*salary*commission_pctFROM employees;

LMD: SELECT – NULOS EN EXPRESIONES

Page 577: Sistemas de Bases de Datos

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.

LMD: SELECT – COLUMNAS ALIAS

Page 578: Sistemas de Bases de Datos

La siguiente sentencia muestra como poner alias a las columnas:

SELECT last_name AS name, commission_pct AS commFROM employees;

Page 579: Sistemas de Bases de Datos

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.

LMD: SELECT – OPERADOR DE CONCATENACIÓN

Page 580: Sistemas de Bases de Datos

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

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

Page 581: Sistemas de Bases de Datos

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

SELECT last_name ||' is a '||job_id AS "Employee Details"

FROM employees;

Page 582: Sistemas de Bases de Datos

La siguiente sentencia muestra como eliminar las filas duplicadas:

SELECT DISTINCT department_idFROM employees;

LMD: SELECT – COLUMNAS DUPLICADAS

Page 583: Sistemas de Bases de Datos

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

SELECT employee_id, last_name, job_id, department_idFROM employeesWHERE department_id = 90 ;

LMD: SELECT – CLAUSULA WHERE

Page 584: Sistemas de Bases de Datos

• 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_idFROM employeesWHERE last_name = 'Whalen';

La cláusula WHERE nos permite limitar en base al last_name:

SELECT start_date, end_date FROM job_historyWHERE start_date = '1993-01-13';

Page 585: Sistemas de Bases de Datos

Operador

=

>

>=

<

<=

<>

Significado

Igual que

Mayor que

Mayor que o igual que

Menor que

Menor que o igual que

Diferente que

Page 586: Sistemas de Bases de Datos

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

SELECT last_name, salaryFROM employeesWHERE salary <= 3000;

Page 587: Sistemas de Bases de Datos

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

Page 588: Sistemas de Bases de Datos

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

SELECT last_name, salaryFROM employeesWHERE salary BETWEEN 2500 AND 3500;

Page 589: Sistemas de Bases de Datos

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

SELECT employee_id, last_name, salary, manager_idFROM employeesWHERE manager_id IN (100, 101, 201);

Page 590: Sistemas de Bases de Datos

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%';

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

Page 591: Sistemas de Bases de Datos

El operador LIKE nos permite buscar filas que cumplan con un determinado patrón:

“ El Segundo caracter es ‘o’”

SELECT last_name

FROM employees

WHERE 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>’ “

Page 592: Sistemas de Bases de Datos

El operador IS NULL nos sirve para identificar los nulos:

SELECT last_name, manager_id

FROM employees

WHERE manager_id IS NULL;

Page 593: Sistemas de Bases de Datos

Operador

AND

OR

NOT

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

Page 594: Sistemas de Bases de Datos

Operador

AND

OR

NOT

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

Orden de evaluación Operador

1 Operadores aritméticos

2 Operador de concatenación

3 Operadores de comparación

4 IS [NOT] NULL, LIKE, [NOT] IN5 [NOT] BETWEEN6 Operador lógico NOT7 Operador lógico AND8 Operador lógico OR

Page 595: Sistemas de Bases de Datos

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.

LMD: SELECT – ORDER BY

Page 596: Sistemas de Bases de Datos

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 ;

Page 597: Sistemas de Bases de Datos

• Se puede ordenar en base al alias de una columna:

SELECT employee_id, last_name, salary*12 as annsal

FROM employees

ORDER BY annsal ;

SELECT employee_id, salary*12 as annsal

FROM employees

ORDER BY last_name;

• También en base a una columna que no se desplegará:

Page 598: Sistemas de Bases de Datos

•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.

Page 599: Sistemas de Bases de Datos

Extrae la parte especificada de la Fecha especificada.

EXTRACT (parte FROM expresión)

Devuelve la hora actual y la fecha actual del sistema, con la precisión especificada

CURRENT_TIMESTAMP (precisión)

Devuelve la hora actual y la fecha actual del sistema, con la precisión especificada

CURRENT_TIME (precisión)

Devuelve la fecha actual del sistema.CURRENT_DATE

Convierte una cadena al tipo especificado de codificación.

CONVERT (expresión USING conversión)

Devuelve la longitud de la expresión, generalmente cadena, en caracteres.

CHAR_LENGTH (expresión)

Convierte el valor que está en un tipo de dato a otro tipo de dato compatible.

CAST (valor AS tipo de dato)

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

BIT_LENGTH (expresión)

DescripciónFunción SQL

ESTÁNDAR DE SQL-99

Page 600: Sistemas de Bases de Datos

Convierte la cadena de caracteres a mayúsculas.UPPER (cadena)

Elimina el carácter indicado que aparezca en la posición especificada de la cadena.

TRIM(LEADING | TRAILING | BOTH char expression FROM string expression)

Devuelve Returns string translated into another string according to specified rules.

TRANSLATE (string expression USING translation rule)

Devuelve una subcadena de la cadena especificada, desde la posición de inicio hasta la longitud dada.

SUBSTRING (cadena, inicio, longitud)

Devuelve la posición del carácter o subcadena en la cadena de caracteres.

POSITION (subcadena IN cadena)

Regresa la longitud de la expresión en bytes.OCTET_LENGTH (cadena)

Convierte la cadena de caracteres a minúsculas.LOWER (cadena)

DescripciónFunción SQL

Page 601: Sistemas de Bases de Datos

FuncionesFunciones

Funciones de Funciones de sólo una filasólo una fila

Funciones de Funciones de múltiples filasmúltiples filas

Page 602: Sistemas de Bases de Datos

• 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.

LMD: FUNCIONES DE UNA SOLA FILA

Page 603: Sistemas de Bases de Datos

ConversiónConversión

CaracteresCaracteres

NuméricasNuméricas

FechasFechas

GeneralesGeneralesFunciones de Funciones de sólo una filasólo una fila

Page 604: Sistemas de Bases de Datos

Funciones Funciones de caracteresde caracteres

LOWERUPPERINITCAP

SUBSTRLENGTHPOSITIONLPAD | RPADTRIMREPLACE

Funciones de manipulaciónFunciones de manipulaciónde mayúsculas y minúsculasde mayúsculas y minúsculas

Funciones de manipulaciónFunciones de manipulaciónde caracteresde caracteres

LMD: FUNCIONES DE CARACTERES

Page 605: Sistemas de Bases de Datos

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

Función Resultado

LOWER(‘Hola')

UPPER('Hola')

INITCAP('hola mundo')

hola

HOLA

Hola Mundo

Page 606: Sistemas de Bases de Datos

SELECT employee_id, last_name, department_idFROM employeesWHERE last_name = 'higgins';

SELECT employee_id, last_name, department_idFROM employeesWHERE last_name = 'higgins';

SELECT employee_id, last_name, department_idFROM employeesWHERE LOWER(last_name) = 'higgins';

Page 607: Sistemas de Bases de Datos

• Estas funciones manipulan cadenas de caracteres:

SUBSTR('Hola Mundo', ,1,5)

LENGTH('Hola Mundo')

POSITION('Hola Mundo, ‘a')

LPAD(‘Hola’,10,'*')

RPAD(‘Hola’, 10, '*')

TRIM('H' FROM 'Hola Mundo')

Hola

10

4

******Hola

Hola******

ola Mundo

Función Resultado

Page 608: Sistemas de Bases de Datos

• 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 employeesWHERE SUBSTR(job_id, 4) = 'REP';

Page 609: Sistemas de Bases de Datos

• 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

LMD: FUNCIONES NUMÉRICAS

Page 610: Sistemas de Bases de Datos

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

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

Page 611: Sistemas de Bases de Datos

• 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

Page 612: Sistemas de Bases de Datos

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

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

Page 613: Sistemas de Bases de Datos

• CURRENT_DATE devuelve la fecha actual

• CURRENT_TIME devuelve la hora

• CURRENT_TIMESTAMP devuelve la fecha y la hora

LMD: FUNCIONES DE FECHAS

Page 614: Sistemas de Bases de Datos

• Uso de las funciones CURRENT_DATE, CURRENT_TIME y CURRENT_TIMESTAMP;

SELECT CURRENT_TIME, CURRENT_DATE, CURRENT_TIMESTAMP

Page 615: Sistemas de Bases de Datos

• 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)

LMD: FUNCIONES GENERALES

Page 616: Sistemas de Bases de Datos

• Uso de la función COALESCE:

SELECT last_name, COALESCE(commission_pct, salary, 10)as commFROM employeesORDER BY commission_pct;

Page 617: Sistemas de Bases de Datos

• 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;

Page 618: Sistemas de Bases de Datos

• • •70Baer204

110Higgins205

90Kochhar101

90King100

department_idlast_nameemployee_id

1700Treasury120

• • •

1700Accounting110

1700Finance100

1700Executive90

2500Sales80

2700Public Relations70

1400IT60

• • •

location_iddepartment_namedepartment_id

Accounting110206

Accounting110205

Public Relations70204

Human Resources40203

Marketing20202

Marketing20201

Administration10200

Shipping50199

• • •

department_namedepartment_idemployee_id

LMD: MÚLTIPLES TABLAS

Page 619: Sistemas de Bases de Datos

• 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.

Page 620: Sistemas de Bases de Datos

• 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) ];

Page 621: Sistemas de Bases de Datos

• CROSS JOIN

Esta cláusula produce el producto cruz de las dos tablas.

select last_name, department_name

from employees

CROSS JOIN departments;

select last_name, department_name

from employees, departments;

Produce el mismo resultado que:

Page 622: Sistemas de Bases de Datos

• 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);

Page 623: Sistemas de Bases de Datos

• 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.

Page 624: Sistemas de Bases de Datos

• JOIN con USINGselect 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.d.department_id);

select employees.employee_id, employees.last_name,

departments.location_id

from employees, departments

where employees.department_id = departments.department_id;

Se obtiene el mismo resultado con:

Equijoin

Page 625: Sistemas de Bases de Datos

• 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);

Page 626: Sistemas de Bases de Datos

• 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);

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);

Se obtiene el mismo resultado con:

Equijoin

Page 627: Sistemas de Bases de Datos

• 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.

Page 628: Sistemas de Bases de Datos

• LEFT 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) ;

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

Page 629: Sistemas de Bases de Datos

• 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) ;

Page 630: Sistemas de Bases de Datos

VI. Diseño de Base de DatosVI. Diseño de Base de Datos

Page 631: Sistemas de Bases de Datos

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 exentos de anomalías de manipulación.

OBJETIVO

Page 632: Sistemas de Bases de Datos

• 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.

PROBLEMAS DEL ESQUEMA RELACIONAL

Page 633: Sistemas de Bases de Datos

• 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.

Page 634: Sistemas de Bases de Datos

Pérdida de restricciones de integridad. Normalmente debido a dependencias funcionales.

• 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.

Page 635: Sistemas de Bases de Datos

• 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).

Page 636: Sistemas de Bases de Datos

• Propiedades indeseables. Un mal diseño nos conduciría a:

• Metas del diseño:

– Repetición de la información.– Imposibilidad para representar determinada información con certeza.

– 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.

Page 637: Sistemas de Bases de Datos

• 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, nombre-

cliente, número-préstamo, importe)

EJEMPLO

Page 638: Sistemas de Bases de Datos

nombre-sucursal ciudad-sucursal activo nombre-clientenumero-

préstamo importe

Centro Arganzuela 9.000.000 Santos P-17 1.000

Moralzarzal La Granja 2.100.000 Gómez P-23 2.000

Navacerrada Aluche 1.700.000 López P-15 1.500

Centro Arganzuela 9.000.000 Sotoca P-14 1.500

Becerril Aluche 400.000 Santos P-93 500

Collado Mediano Aluche 8.000.000 Abril P-11 900

Navas de la Asunción Alcalá de Henares 300.000 Valdivieso P-29 1.200

Segovia Cerceda 3.700.000 López P-16 1.300

Centro Arganzuela 9.000.000 González P-18 2.000

Navacerrada Aluche 1.700.000 Rodríguez P-25 2.500

Galapagar Arganzuela 7.100.000 Amo P-10 2.200

Page 639: Sistemas de Bases de Datos

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.

Page 640: Sistemas de Bases de Datos

• 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

Page 641: Sistemas de Bases de Datos

• 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.

Page 642: Sistemas de Bases de Datos

• 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.

PAUTAS INFORMALES DE DISEÑO

Page 643: Sistemas de Bases de Datos

• Ejemplo:

a) Semánticamente confusas

Page 644: Sistemas de Bases de Datos

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.

Page 645: Sistemas de Bases de Datos

• Ejemplo:b) Información redundante en la tuplas y

anomalías de actualización.

Page 646: Sistemas de Bases de Datos

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.

Page 647: Sistemas de Bases de Datos
Page 648: Sistemas de Bases de Datos

• Ejemplo:

c) Valores nulos en la tuplas.

Page 649: Sistemas de Bases de Datos

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.

Page 650: Sistemas de Bases de Datos

• Ejemplo:c)Tuplas espurias.

Se aplica proyección a EMP_PROY

Page 651: Sistemas de Bases de Datos

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.

Se aplica join natural a EMP_PROY1 y LUGARES_EMP.

Page 652: Sistemas de Bases de Datos

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 es una generalización de la idea de una llave.

DEPENDENCIA FUNCIONAL: BASES

Page 653: Sistemas de Bases de Datos

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}

Page 654: Sistemas de Bases de Datos

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.

Page 655: Sistemas de Bases de Datos

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

Page 656: Sistemas de Bases de Datos

Sea R un esquema de relación.

Sean A y B dos conjuntos de atributos de la base de datos.

Donde A ⊆ R y B ⊆ 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 ]

DEFINICIÓN

Page 657: Sistemas de Bases de Datos

Por ejemplo: la siguiente relación satisface la DF.

{ V# } { ciudad }

400P5LondresV4

400P4LondresV4

400P2LondresV4

300P2ParísV3

200P2ParísV2

200P1ParísV2

100P2LondresV1

100P1LondresV1

CANTP#CIUDADV#

No se cumple: { P# } { cant }

Page 658: Sistemas de Bases de Datos

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# }

Page 659: Sistemas de Bases de Datos

Determinante Dependiente

Cuando se contiene sólo un atributo en ambos conjuntos denominado conjunto individual, se escribe:

V# ciudad

DETERMINANTE Y DEPENDIENTE

Page 660: Sistemas de Bases de Datos

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

Page 661: Sistemas de Bases de Datos

De las dependencias anteriores, las siguientes DFs no son válidas “todo el tiempo”:

V# cantCant 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.

Page 662: Sistemas de Bases de Datos

• Equivalente:

X Y y Y X se representa: X ↔ Y

Ejemplo: { V# } { cant } y { cant } { V# }

• 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 X2 | Y

Lo representamos: X Y

TIPOS DE DEPENDENCIA

Page 663: Sistemas de Bases de Datos

• 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.

Page 664: Sistemas de Bases de Datos

• Funcional trivial: X Y es trivial si Y es un subconjunto de X (Y C X).

{ V#, P# } { V# }

Page 665: Sistemas de Bases de Datos

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

USO DE DEPENDENCIAS FUNCIONALES

Page 666: Sistemas de Bases de Datos

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

Page 667: Sistemas de Bases de Datos

La GranjaArenalGonzález

LeónJazmínFernández

CercedaCarreterasPérez

PeguerinosMayor López

CercedaCarreterasGómez

PeguerinosMayorSantos

Ciudad-clientecalle-clientenombre-cliente

Relación cliente

calle-cliente ciudad-cliente

En el mundo real

Dos ciudades pueden tener calles que se llamen igual.

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

UNA RELACIÓN SATISFACE UNA DF

Page 668: Sistemas de Bases de Datos

2.000CentroP-18

500BecerrilP-93

1.500CentroP-14

1.500NavacerradaP-15

2.000MoralzarzalP-23

1.000CentroP-17

importeNombre-sucursalnumero-prestamo

Relación préstamo

numero-prestamo importe

En la empresa real

Cada préstamo tienen un único importe.

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

UNA DF SE CUMPLE EN UN ESQUEMA

Page 669: Sistemas de Bases de Datos

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

Page 670: Sistemas de Bases de Datos

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

CIERRE DE UN CONJUNTO DE DEPENDENCIAS

Page 671: Sistemas de Bases de Datos

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.

Page 672: Sistemas de Bases de Datos

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+.

AXIOMAS DE ARMSTRONG

Page 673: Sistemas de Bases de Datos

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 α β

Page 674: Sistemas de Bases de Datos

• 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+

Page 675: Sistemas de Bases de Datos

• 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 αγ δ.

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

OTRAS REGLAS

Page 676: Sistemas de Bases de Datos

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

Esquema de relación R = (A, B, C, G, H, I)

Conjunto de dependencias funcionales A BA C

CG HCG IB H

La dependencia funcional A H.

EJEMPLO

Page 677: Sistemas de Bases de Datos

Dado que CG H y CG I, se aplica la regla de unión.

La dependencia funcional CG HI.

Dado que A C y CG I, se aplica la regla de pseudotransitividad.

La dependencia funcional AG I.

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 .

Page 678: Sistemas de Bases de Datos

• 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 = 2n + 1

dependencias funcionales posibles

• n es el número de atributos de R.

CIERRE DE UN CONJUNTO DE ATRIBUTOS

Page 679: Sistemas de Bases de Datos

• 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

Page 680: Sistemas de Bases de Datos

• 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.

Page 681: Sistemas de Bases de Datos

• 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 dobegin

if β ⊆ resultado then resultado:= resultado ∪ γ ;end

Page 682: Sistemas de Bases de Datos

• Ejemplo:Esquema de relación R = (A, B, C, G, H, I)

Conjunto de dependencias funcionales A BA C

CG HCG IB H

(AG)+Calcular

resultado = AG

A B hace que se incluya B a resultado A B está en F A ⊆ resultado (AG)

resultado:= resultado ∪ B

Page 683: Sistemas de Bases de Datos

• Ejemplo:

A BA C

CG HCG IB H

A C hace que resultado sea ABCG

CG H hace que resultado sea ABCGH

CG I hace que resultado sea ABCGHI

Page 684: Sistemas de Bases de Datos

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.

USO DE ATRIBUTOS DE CERRADURA

Page 685: Sistemas de Bases de Datos

Conjuntos de dependencias funcionales pueden tener dependencias redundantes que pueden ser deducidas desde otras

Ejemplo: AC es redundante en {AB, BC, AC}.

Partes de una dependencia funcional pueden ser redundantes.Ejemplo: {AB, BC, ACD}

Puede ser simplificada a {AB, BC, AD}

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.

COBERTURA CANÓNICA

Page 686: Sistemas de Bases de Datos

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.

Page 687: Sistemas de Bases de Datos

• Sea F un conjunto de dependencias funcionales y α β la dependencia funcional de F.

• El atributo A es raro en β si A∈β y el conjunto de

dependencias funcionales (F- {αβ}) ∪ {α - (β

A)} implica lógicamente a F.

• El atributo A es raro en α si A∈α y F implica

lógicamente a (F - {αβ}) ∪ {(α - A) β}

DEFINICIÓN

Page 688: Sistemas de Bases de Datos

• Sean las dependencias funcionales:

• 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

Entonces es raro en

ABCAC

B ABC

• Sean las dependencias funcionales:

Entonces es raro en el lado derecho de

ABCDAC

C ABCD

EJEMPLOS

Page 689: Sistemas de Bases de Datos

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 α .

Page 690: Sistemas de Bases de Datos

• Sea F AB CD, A E y EC

• Comprobar si C es raro en AB (α) CD (β)

• Hay que calcular el cierre de los atributos AB bajo F´=

Page 691: Sistemas de Bases de Datos

Conjuntos de dependencias funcionales pueden tener dependencias redundantes que pueden ser deducidas desde otras.

• 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.

Partes de una dependencia funcional pueden ser redundantes

Ejemplo: A C es redundante en: { A B, BC, AC }

{ A B, BC, ACD}

puede ser simplificada a { A B, BC, AD}

Page 692: Sistemas de Bases de Datos

Un recubrimiento canónico Fc, de F es un conjunto de

dependencias tales que F implica lógicamente todas las dependencias de Fc, y Fc, implica lógicamente todas las

dependencias de F. Además, Fc debe cumplir las

propiedades siguientes:

• 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.

Page 693: Sistemas de Bases de Datos

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.

Page 694: Sistemas de Bases de Datos

Considérese el siguiente conjunto de dependencias funcionales F del esquema (A,B,C):

ABCBCAB

ABC

Calculamos el recubrimiento canónico de F.

Page 695: Sistemas de Bases de Datos

Hay dos dependencias funcionales con el mismo conjunto de atributos a la izquierda de la flecha:

ABCAB

Estas dependencias funcionales se combinan en:

ABC

Page 696: Sistemas de Bases de Datos

A es raro para ABC porque F implica lógicamente

(F – {ABC}) U {BC}

Esta afirmación es verdadera porque BC ya está en el conjunto de dependencias funcionales.

C es raro para ABC, ya que ABC viene lógicamente implicado por AB y por BC.

Por tanto, el recubrimiento canónico es

ABBC