BD U3 PDF

BD – Bases de Datos Unidad 3: Modelo Relacional
UNIDAD 3: EL MODELO RELACIONAL
Tema 1. Fundamentos
El modelo relacional es sin lugar a dudas el fundamento de la tecnología moderna de bases

de datos; este fundamento es el que hace de este campo una ciencia.
El modelo relacional propuesto por E.F. Codd (en el artículo “A Relational Model of Data for
Large Shared Data Banks” en 1970), luego de más de 30 años se mantiene asombrosamente
vigente. Obviamente muchas ideas han sido refinadas, pero los cambios han sido evolutivos,
no revolucionarios.
El modelo relacional propuesto por Codd en su primer artículo es llamado RM/V1 y se ocupa
de tres aspectos esenciales: estructura, manipulación e integridad.
Codd dedicó varios años a revisar y ampliar su modelo. En 1990 publica el libro “The
Relational Model for Database Managemente Version 2”, en el cual describe lo que él llama
RM/V2 donde habla de más aspectos relacionados a la totalidad de la administración de
bases de datos:
- Autorización - Manipulación
- Operadores básicos - Asignación de nombres
- Catálogo - Protección
- Principios de diseño de DBMS - Calificadores
- Comandos para el DBA - Estructura
- Funciones - Tipos de datos
- Integridad - Vistas
- Indicadores - Base de datos distribuidas
- Principios de diseño de lenguaje - Operadores avanzados
1.1. Objetivos
Los objetivos por los que se piensa en un modelo de datos relacionales es encontrar una
manera de describir los datos que:
 Pueda ser entendida fácilmente por los usuarios que no tienen preparación
como programadores.
 Que haga posible ampliar la base de datos sin modificación de la estructura

lógica existente y, por tanto, sin modificación de los programas de aplicación.
 Que permita la máxima flexibilidad en la formulación de interrogantes de forma

no prevista, o espontánea, en los terminales.
El modelo relacional representa la segunda generación de los DMBS. En él, todos los
datos están estructurados a nivel lógico como tablas formadas por filas y columnas,
aunque a nivel físico pueden tener una estructura completamente distinta. Un punto
fuerte del modelo relacional es la sencillez de su estructura lógica. Pero detrás de esa
simple estructura hay un fundamento teórico importante del que carecen los DMBS de la
primera generación, lo que constituye otro punto a su favor.
Dada la popularidad del modelo relacional, muchos sistemas de la primera generación se

han modificado para proporcionar una interfaz de usuario relacional, con independencia
del modelo lógico que soportan (de red o jerárquico). Por ejemplo, el sistema de red
IDMS ha evolucionado a IDMS/R e IDMS/SQL, ofreciendo una visión relacional de los
datos.
En los últimos años, se han propuesto algunas extensiones al modelo relacional para
capturar mejor el significado de los datos, para disponer de los conceptos de la
orientación a objetos y para disponer de capacidad deductiva.
Facultad de Ingeniería 1
1.2. Relaciones
Una relación es un concepto matemático que consta de dos partes: encabezado y

cuerpo:
o Al encabezado se le llama también esquema o intensión. Es un conjunto de n

atributos de la forma (Ai, Ti) donde Ai (que deben ser todos distintos) son los
nombres de atributos de la relación y los Ti son los nombres de los tipos
correspondientes.
o Al cuerpo se le conoce como extensión. Es un conjunto de m tuplas t, donde t es a

su vez un conjunto de componentes de la forma (Ai, vi) en la cual vi es un valor de
tipo Ti para el atributo Ai de la tupla t.
A los valores m y n se les denomina cardinalidad y grado, respectivamente, de la

relación r.
Al valor n se le llama grado (en ocasiones, aridad). Se dice que una relación de grado
uno es unaria, una relación de grado dos binaria, una de grado tres ternaria, … y una
relación de grado n n-aria.
En general, el modelo relacional se ocupa entonces de las relaciones n-arias para un

entero n cualquiera no negativo.
El gráfico anterior muestra un ejemplo de un modelo relacional. Todos los elementos se

muestran con su nomenclatura original.
Propiedades de las relaciones
1. No existen tuplas duplicadas

El cuerpo de una relación es un conjunto matemático y los conjuntos en
matemáticas no incluyen elementos duplicados.
Esto sirve para ilustrar que, en general, una relación y una tabla no son lo
mismo; ya que en general una tabla puede contener filas duplicadas mientras
que una relación no.
2. Las tuplas están en desorden, de arriba hacia abajo

El cuerpo de una relación es un conjunto matemático y en matemáticas, los
conjuntos no están ordenados.
Esto sirve para ilustrar, también, que una relación y una tabla no son lo mismo
puesto que las filas de una tabla tienen un ordenamiento obvio de arriba hacia
abajo, mientras que las tuplas de una relación no lo tienen.
3. Los atributos están en desorden, de izquierda a derecha

Esta propiedad surge del hecho de que el encabezado de una relación también es
un conjunto (de atributos).
Siempre se hace referencia a los atributos por nombre, no por posición.
4. Cada tupla contiene exactamente un valor para cada atributo

Esta propiedad surgen inmediatamente de la definición de tupla: una tupla es un
conjunto de n componentes o pares ordenados de la forma (Ai, vi). Se dice que
una relación que satisface esta cuarta propiedad está normalizada o, lo que es
equivalente, está en la primera forma normal.
5. Cada relación y cada atributo tienen nombres únicos

Cada relación tiene un nombre y éste es distinto del nombre de todas las demás.
Dentro de una relación no hay dos atributos que se llamen igual.
Representación de una Relación

Una relación se representa gráficamente como una tabla bidimensional en la que las filas
corresponden a registros individuales y las columnas corresponden a los campos o
atributos de esos registros. Los atributos pueden aparecer en la relación en cualquier
orden.
Una base de datos relacional está compuesta por una serie de tablas que contienen
información relacionada. Cada tabla se compone de columnas que son elementos de
datos individuales conocidos como campos, y filas que son los registros o instancias de
datos.
Las tablas almacenan datos sobre una entidad o relación
Una entidad puede ser una persona, una parte de una máquina, un libro o cualquier
objeto tangible o intangible. La consideración principal es que una tabla sólo almacena
datos acerca de una cosa.
Poseen las siguientes propiedades generales:
o Cada entrada de la tabla representa un ítem de datos; no hay grupos repetitivos.
o Son homogéneas por columna: es decir, todos los ítems de una columna son de la
misma clase.
o Cada columna tiene su nombre propio.
Una relación es una tabla con columnas y filas. Un DMBS relacional sólo necesita que el
usuario pueda percibir la base de datos como un conjunto de tablas.
Tipos de Relaciones
1. Relaciones Base: Son aquellas cuya importancia es tal que el diseñador de la

base de datos ha decidido darles un nombre y hacerlas parte directa de la base
de datos en sí, a diferencia de otras relaciones cuya naturaleza es más efímera,
como por ejemplo, el resultado de una consulta.
2. Vistas: Es una relación derivada, con nombre, representada dentro del sistema
exclusivamente mediante su definición en términos de otras relaciones con
nombre.
3. Resultados de Consultas: Ésta es tan sólo la relación final resultante de alguna

consulta especificada.
4. Resultados intermedios: Es una relación, casi siempre sin nombre, resultante de

alguna expresión relacional más grande.
1.3. Atributos
Un atributo es el nombre de una columna de una relación. En el modelo relacional, las
relaciones se utilizan para almacenar información sobre los objetos que se representan
en la base de datos.
Las columnas contienen los atributos de la entidad
De la misma manera en que una tabla contiene los datos de una única entidad, cada
columna debería contener únicamente un ítem de data acerca de esa entidad.
Tabla Perro
Número de Peso en Fecha Altura en
Nombre
Licencia libras Nacimiento pulgadas
AE1235 Spot 120 12-04-1999 24
TR578F Nena 32 04-07-2004 17
7GK342 Kayser 9 17-03-2002 9
AE980 Toby 18 09-05-1999 14
E1TH7 Lulú 26 07-01-2008 18
Registros de la
tabla (filas) Campos de la tabla (columnas)
1.4. Dominio
Un dominio es el conjunto de valores legales de uno o varios atributos. Los dominios

constituyen una poderosa característica del modelo relacional.
Definimos un dominio como un conjunto de valores, todos del mismo tipo, de esta
manera, los dominios son “fondos de valores”, de los cuales se extraen los valores reales
que aparecen con los atributos. Cada atributo debe estar definido sobre un dominio
subyacente, y sólo uno, lo que significa que los valores de ese atributo deben proceder
de ese dominio.
El concepto de dominio es importante porque permite que el usuario defina, en un lugar

común, el significado y la fuente de los valores que los atributos pueden tomar. Esto
hace que haya más información disponible para el sistema cuando éste va a ejecutar una
operación relacional, de modo que las operaciones que son semánticamente incorrectas,
se pueden evitar.
Ejemplo:
- El atributo Edad de una relación CIUDADANO, tiene un dominio que se representa:
DEdad = { x/x ε N ^ x < 120 }
- El atributo Día de una relación REGISTROS, tiene un dominio que se representa:
DDía = {Lunes, Martes, Miércoles, Jueves, Viernes, Sábado, Domingo}
- El atributo IndAcum, índice acumulado de una relación ALUMNO, tiene un dominio

que se representa:
DIndAcum = { x/x ε R ^ 0 ≤ x ≤ 20 }
1.5. Ventajas de la base de datos relacional
Facilidad de uso
La manera más fácil de representar la mayor parte de los datos para uso del usuario
lego es la que se basa en el empleo de tablas bidimensionales.
Flexibilidad
Las operaciones permiten a los usuarios obtener los archivos que necesitan para sus
aplicaciones y de la forma en que los quieren.
Precisión
Las relaciones de tablas tienen un significado preciso y pueden ser manipuladas con
álgebra o cálculo relacional.
Seguridad
Es más fácil implementar los controles de seguridad. Las autorizaciones de
seguridad se refieren a relaciones.
Relacionabilidad
Se tiene máxima flexibilidad para relacionar atributos de diferentes conjuntos de
registros o diferentes archivos.
Facilidad de implementación
Es mucho más fácil de implementar que los modelos de red y jerárquico. En general,
no contiene sistemas de punteros que hagan tediosa la implementación.
Independencia de datos
Si la base de datos está normalizada, será fácil que pueda crecer, tanto en atributos
como en operaciones, sin obligar, en la mayoría de los casos, a volver a escribir los
programas de aplicaciones.
Lenguaje para la manipulación de datos

Los lenguajes para manipular los datos se basan en el álgebra relacional o el cálculo
relacional, haciendo mucho más accesible para usuarios no especializados en el tema
de la programación.
Claridad
Con el crecimiento de las bases de datos y su tendencia a abarcar más y más
actividades, es imperativo que terminemos con las representaciones lógicas basadas
en el uso de punteros. Las bases relacionales ofrecen, al parecer la mejor solución.
1.6. Claves en el Modelo Relacional
Una clave es simplemente un campo o un conjunto de campos que puede ser usado para
identificar un registro. En algunos casos, los campos claves son una parte de la data que
se está almacenando y en otros casos son derivados de la data. Existen cuatro tipos de
claves: las aspirantes, primarias, secundarias y foráneas.
Clave Aspirante o Clave Candidata
Un campo de clave aspirante tiene una propiedad tal que su valor de campo sólo
puede identificar a cada registro en un archivo de manera única. Una clave candidata
tiene dos cualidades:
- Unicidad: En cualquier momento no existen dos registros con el mismo valor de X en

la misma relación.
- Minimalidad: Si X es compuesto, al eliminar cualquiera de sus componentes,

perdemos la cualidad de Unicidad.
De todas las claves candidatas existentes en una entidad, el diseñador de la base de

datos ha de escoger una, que se denominará clave principal o primaria. Al resto de
las claves candidatas (las que no han sido elegidas como primarias) se les llamará
Claves Alternativas.
Clave Primaria
Es aquella clave que se utiliza para definir unívocamente un registro o una tupla, es
decir, un identificador formado por uno o más atributos. La clave primaria es de gran
importancia porque son el único medio de acceder a un registro específico. Llamada
también Clave del Registro.
Clave Secundaria
Son aquellas claves que no identifican registros únicos, sino todos aquellos que
tienen cierta propiedad. A menudo un archivo puede tener varias claves secundarias,
las que sirven para explorar el archivo en busca de entidades que tienen
determinadas propiedades.
Clave Foránea
Una columna o campo de una tabla cuyo valor coincide con la clave primaria de
alguna otra tabla se denomina clave foránea.
Por ejemplo, supongamos que tenemos el archivo ALUMNO, con los siguientes
atributos: {Carné, Nombre, Apellido, DNI, Dirección, Teléfono, Fecha_Nacimiento}
Encontramos como ejemplo de superclaves los siguientes atributos o campos:
- Carné
- DNI(se asume que no existen DNI’s repetidos)
- Nombre+Apellido (suponiendo que no existan dos personas que se llamen igual)
- Nombre+Apellido+DNI, Carne+DNI (si Carné identifica de forma unívoca a un
alumno, más aún se le discriminará si se le añade como condición DNI)
- Carné+Nombre+Apellido+DNI
- Carné, Nombre, Apellido, DNI, Dirección, Teléfono, Fecha_Nacimiento
Sin embargo, las claves candidatas que aparecen son: Carné, DNI (suponiendo que
no existen DNI’s repetidos) y Nombre+Apellido (suponiendo que no existan dos
personas que se llamen igual).
Entre las claves candidatas escogemos como clave primaria Carné, por ser la más
discriminatoria, las otras dos claves pasarán a ser claves alternativas.
Clave Primaria Claves Secundarias
Código de capacitación
Numero de empleado
Departamento
Calificación
Nombre
Salario
Nombre del Atributo
Titulo
Fecha
Sexo
Forma de Representación N5 AV B1 N2 N6 N3 N2 AV N4
Valor de atributo
53730 JONES, ALVERTO 1 03 100335 044 73 CONTADOR 2000
28719 LARRONDO, JOSE 1 05 101019 172 43 PLOMERO 1800
53550 GOMEZ, EMILIA 0 07 090938 044 02 AUXILIAR 1100
79632 GUTIERREZ, PEDRO 1 11 011132 090 11 CONSULTOR 5000
Registro 15971 GLAS, FRENANDO 1 13 021242 172 43 PLOMERO 1700
Segmento o 51883 NEURINGER, JUAN 1 03 091130 044 73 CONTADOR 2000
Tuple 36453 BARREIRO, PASCUAL 1 08 110941 044 02 AUXILIAR 1200
41618 RUSS, PATRICIA 0 07 071235 172 07 INGENIERO 2500
61903 PANZA, VICTOR 1 11 011030 172 21 ARQUITECTO 3700
72921 TABOADA, CAROLINA 0 03 020442 090 93 PROGRAMADOR 2100
Identificador de Conjunto de valores de un Algunos atributos son identificadores

Entidad item de datos (un dominio) de entidades en otros archivos
Tema 2. Álgebra Relacional
La parte de manipulación del modelo relacional ha evolucionado considerablemente desde la

publicación de los documentos originales de Codd sobre el tema. Sin embargo, todavía se da
el caso de que el componente principal de esa parte de manipulación es lo que se denomina
álgebra relacional, que básicamente es sólo el conjunto de operadores que toman relaciones
como sus operandos y regresan una relación como su resultado.
Propiedad de Cierre del Álgebra Relacional

La salida de cualquier operación relacional dada es otra relación.
2.1. Álgebra Relacional
El álgebra original constaba de ocho operadores en dos grupos de cuatro cada uno:
o Conjunto tradicional de operadores unión, intersección, diferencia, y producto

cartesiano.
o Operadores relacionales especiales restringir (también conocido como seleccionar),
proyectar, juntar y dividir.
Restringir Proyectar Producto
a x a x
b y a y
c b x
b y
c x
c y
Unión Intersección Diferencia
Junta Dividir
a1 b1 b1 c1 a1 b1 c1 a a x x a
a2 b1 b2 c2 a2 b1 c1 b a y z
a3 b2 b3 c3 a3 b2 c2 c a z
b z
c y
Semántica de las Operaciones del Álgebra Relacional
Imaginemos estas dos relaciones A y B para explicar mejor los conceptos que
veremos más adelante:
A B
V# Proveedor Status Ciudad V# Proveedor Status Ciudad
V1 Smith 20 Londres V1 Smith 20 Londres

V4 Clark 20 Londres V2 Jones 10 París
Unión
La unión en el álgebra relacional requiere que las dos relaciones de entrada sean del
mismo tipo, esto es que deben contener tuplas de una o de otra, pero no una mezcla
de tuplas de ambas.
Dadas dos relaciones A y B del mismo tipo, la unión de dichas relaciones, definida
como (A UNION B), es una relación del mismo tipo con un cuerpo que consiste en
todas las tuplas t, tal que t aparece en A, en B o en ambas.
(A UNION B)
V# Proveedor Status Ciudad
V1 Smith 20 Londres
V4 Clark 20 Londres
V2 Jones 10 París
Intersección
Al igual que la unión, y básicamente por la misma razón, el operador relacional de
intersección requiere que sus operandos sean del mismo tipo. Dadas dos relaciones A
y B del mismo tipo, entonces la intersección de esas dos relaciones (A INTERSECT
B) es una relación del mismo tipo con un cuerpo que consiste en todas las tuplas t,
tal que t aparece tanto en A como en B.
(A INTERSECT B)
V1 Smith 20 Londres
Diferencia
Al igual que la unión y la intersección, el operador relacional de diferencia requiere
que sus operandos sean del mismo tipo. Dadas dos relaciones A y B del mismo tipo,
entonces la diferencia entre esas dos relaciones, expresado como (A MINUS B), es
una relación del mismo tipo con un cuerpo que consiste en todas las tuplas t, tal que
t aparece en A y no en B.
(A MINUS B)
V4 Clark 20 Londres
(B MINUS A)
V2 Jones 10 París
Producto
Dadas dos relaciones A y B – donde A y B no tienen nombres de atributo comunes -
definimos el producto cartesiano relacional (A TIMES B) como una relación de un
encabezado que es la unión (como conjuntos) de los encabezados de A y B y con un
cuerpo que consiste en el conjunto de todas las tuplas t, tal que t es la unión (como
conjuntos) de una tupla que aparece en A y una tupla que aparece en B.
La cardinalidad del resultado es el producto de las cardinalidades de A y B, y que la

suma de sus grados es el grado del resultado.
A B (A TIMES B)
V# P# V# P#
V1 P1 V1 P1
V2 P2 V1 P2
V3 P3 V1 P3
V4 V2 P1
V2 P2
V2 P3
V3 P1
V3 P2
V3 P3
V4 P1
V4 P2
V4 P3
Restringir
Tenga la relación A atributos X y Y (y quizás otros) y sea ¥ un operador (por lo
regular “=”, “>”, etc.) tal que la condición X ¥ Y esté bien definida y de como
resultado un valor de verdad (verdadero o falso) para valores particulares de X y Y;
entonces la restricción ¥ de la relación A sobre los atributos X y Y (en ese orden) es
una relación con el mismo encabezado que A y con un cuerpo que consiste en todas
las tuplas t de A tal que la condición X ¥ Y da como resultado verdadero para esa
tupla t.
(V WHERE CIUDAD = ‘Londres’) (V WHERE STATUS < 15)
V# Proveedor Status Ciudad V# Proveedor Status Ciudad
V1 Smith 20 Londres V2 Jones 10 París

V4 Clark 20 Londres
Proyectar
Tenga la relación A los atributos X, Y…, Z (y posiblemente otros); entonces la
proyección de la relación A sobre X, Y, …, Z
A { X, Y, …, Z }
es una relación con:
o con un encabezado derivado del encabezado de A al quitar todos los atributos

no mencionados en el conjunto { X, Y, …, Z}, y
o un cuerpo consistente en todas las tuplas { X:x, Y:y, …, Z:z} tal que una
tupla aparece en A con el valor x para X, el valor y para Y,…, y el valor z para
Z.
El operador de proyección produce un efecto de subconjunto vertical de una relación

dada, es decir, ese subconjunto obtenido al quitar todos los atributos no
mencionados en la lista de atributos especificada después eliminar las (sub)tuplas
duplicadas.
P { CIUDAD } P { COLOR, CIUDAD}
CIUDAD COLOR CIUDAD
Londres Rojo Londres

París Verde París
Atenas Azul Roma
Azul París
Juntar
Tengan las relaciones A y B los encabezados
{ X1, X2, …, Xm, Y1, Y2, …, Yn }
{ Y1, Y2, …, Yn, Z1, Z2, …, Zp }
respectivamente; es decir, sólo los atributos Y: Y1, Y2, …, Yn son comunes a las dos
relaciones. Los atributos X: X1, X2, …, Xm son los otros atributos de A y los atributos
Z: Z1, Z2, …, Zp son los otros atributos de B. Ahora considere que { X1, X2, …, Xm
}, { Y1, Y2, …, Yn} y { Z1, Z2, …, Zp} son los tres atributos compuestos X, Y y Z,
respectivamente. Entonces la junta de A y B (A JOIN B) es una relación con el
encabezado { X, Y, Z } y un cuerpo que consiste en el conjunto de todas las tuplas {
X:x, Y:y, Z:z} tal que una tupla aparece en A con el valor x para X y el valor y para
Y, mientras que una tupla aparece en B con el valor y para Y y el valor z para Z.
(V JOIN P)
V# Proveedor Status Ciudad P# Parte Color Peso
V1 Smith 20 Londres P1 Tuerca Rojo 12.0

V1 Smith 20 Londres P4 Tornillo Rojo 14.0
V1 Smith 20 Londres P6 Engrane Rojo 19.0
V2 Jones 10 París P2 Perno Verde 17.0
V2 Jones 10 París P5 Leva Azul 12.0
V3 Blake 30 París P2 Perno Verde 17.0
V3 Blake 30 París P5 Leva Azul 12.0
V4 Clark 20 Londres P1 Tuerca Rojo 12.0
V4 Clark 20 Londres P4 Tornillo Rojo 14.0
V4 Clark 20 Londres P6 Engrane Rojo 19.0
Dividir
Tengan las relaciones A y B los encabezados
{ X1, X2, …, Xm }
{ Y1, Y2, …, Yn }
respectivamente (es decir, A y B tienen encabezados disjuntos) y tenga la relación C

el encabezado
{ X1, X2, …, Xm, Y1, Y2, …, Yn }
es decir, C tiene un encabezado que es la unión de los encabezados de A y B.
Ahora consideremos a { X1, X2, …, Xm} y a { Y1, Y2, ..., Yn} como los atributos
compuestos X y Y respectivamente. Entonces, la división de A entre B por C (donde
A es el dividendo, B es el divisor y C es el mediador) expresada como (A DIVIDEBY B
PER C) es una relación con un encabezado { X } y su cuerpo está formado por
valores X de A cuyos correspondientes valores Y en C incluyen a todos los valores Y
de B, en términos generales.
Dividendo Divisores Mediador

A B1 B2 B3 C
V# P# P# P# V# P#
V1 P1 P2 P1 V1 P1
V2 P4 P2 V1 P2
V3 P3 V1 P3
V4 P4 V1 P4
P5 V1 P5
P6 V1 P6
V2 P1
V2 P2
V3 P2
V4 P2
V4 P4
V4 P5
A DIVIDEBY B1 PER C A DIVIDEBY B2 PER C A DIVIDEBY B3 PER C
V# V# V#
V1 V1 V1
V2 V4
2.2. Cálculo Relacional
En la sección anterior hemos dicho que la parte de manipulación del modelo

relacional estaba basada en el álgebra relacional; sin embargo, de igual forma
pudimos haber dicho que estaba basada en el cálculo relacional. En otras palabras, el
álgebra y el cálculo son alternativos entre sí.
La diferencia principal entre el álgebra y el cálculo es la siguiente: Mientras que el

álgebra proporciona un conjunto de operadores explícitos – juntar, unión, proyectar,
etc. – que pueden usarse para indicar al sistema cómo construir cierta relación
deseada a partir de relaciones dadas, el cálculo simplemente proporciona una
notación para establecer la definición de esa relación deseada en términos de
relaciones dadas.
Por ejemplo, considere la consulta “obtener los códigos de proveedor y ciudades para
los proveedores que suministran la parte P2”. Una formulación algebraica de esa
consulta podría especificar las siguientes operaciones:
o Primero, juntar las tuplas de proveedores y envíos en base al código del

proveedor;
o A continuación, restringir el resultado de esa junta a las tuplas de la parte
P2;
o Por último, proyectar el resultado de esa restricción sobre código de
proveedor y ciudad.
En contraste, una formulación del cálculo podría declarar simplemente:
o Obtener código de proveedor y ciudad de los proveedores tales que exista un

envío VP con el mismo valor del código del proveedor y con el valor P2 para
el código de parte.
En esta última formulación, el usuario simplemente declara las características de la

definición del resultado deseado y deja al sistema que decida exactamente qué
juntas, restricciones, etc. debe ejecutar a fin de construir el resultado.
Por lo tanto, podemos decir que el cálculo simplemente define cuál es el problema y
el álgebra define cuál es el procedimiento para resolver ese problema. Sin embargo,
podemos afirmar categóricamente que el álgebra y el cálculo son lógicamente
equivalentes: para cada expresión algebraica existe una equivalente del cálculo
(existe una correspondencia uno a uno entre ambos).
Para este capítulo nos quedaremos sólo con la idea proporcionada por el álgebra
relacional puesto que las definiciones principales del cálculo las veremos explícitas e
implementadas en el lenguaje de consulta estructurado SQL.
Tema 3. Generación del modelo relacional a partir del modelo entidad-relación
Antes de generar el diseño de la base de datos relacional hay que asegurarse que el modelo
de datos esté completo:
o Cada atributo debe tener el tipo de datos adecuado

o Las cardinalidades deben estar completas y correctas
o Cada entidad debe tener un identificador único.
3.1. Traducción de entidades y atributos identificadores
o Cada entidad se convierte en una tabla.

o El identificador único para cada entidad se convierte en la clave primaria de
la tabla.
o Cada atributo se convierte en una columna de su tabla respectiva.
3.2. Traducción de las relaciones
Relaciones uno a muchos
La relaciones uno a muchos son las más frecuentes.
La regla es: la clave primaria del lado “uno” es incrustada en la tabla del lado de
“muchos” para implementar la relación.
Ejemplo:
Posee actualmente
Persona Perro
Es actualmente propiedad
- En el ejemplo, una persona puede poseer muchos perros, pero un perro debe
ser poseído sólo por una persona. Para implementar la relación, la clave
primaria de la tabla persona se incrusta en la tabla perro.
- No podemos incrustar la clave primaria de la tabla perro en la tabla persona,
debido a que esto daría como resultado un grupo repetido para cualquiera que
poseyera más de un perro.
- Para unir un perro con su propietario actual se unen los renglones de perro con
el renglón de persona correspondiente, haciendo concordar la clave externa de
la persona que está en la tabla perro con la clave primaria de la persona que
está en la tabla persona.
- El concepto de la unión de tablas es un principio básico del lenguaje de
consulta estructurado SQL que se usa para acceder los datos en las bases de
datos relacionales.
Persona Perro
ID_persona Char(8) Número_de_licencia Char(8)

Nombre Char(30) Nombre Char(30)
Apellido Char(30) Peso_en_libras Integer
Teléfono Char(10) Fecha_nacimiento Date
Altura_en_pulgadas Integer
ID_persona Char(8)
Las claves externas permiten que el sistema manejador de la base de datos se

asegure de que ningún registro pueda ser borrado de ella mientras haya un
registro en cualquier tabla que haga referencia a su clave primaria. No se puede
borrar un registro de persona si existe un registro de perro que haga referencia a
él. Primero se debe borrar al perro antes de que se pueda eliminar a la persona.
A esto se le llama integridad referencial.
Relación uno a uno
Las relaciones uno a uno son muy extrañas y se pueden considerar como
excepcionalmente raras en un sistema organizacional.
La clave externa puede ser colocada en cualquier tabla para implementar la

relación de uno a uno.
Si ambos lados de la relación son obligatorios o ambos son opcionales, el diseñador

tiene libertad para elegir, aunque debe imaginar cuál de ellas es más probable que
se convierte en una relación de uno a muchos en el futuro.
Ejemplo:
Posee actualmente
Persona Perro
Es actualmente propiedad
- La clave primaria de la tabla persona deberá colocarse en la tabla perro

como clave externa, debido a que es obligatoria.
- En forma alterna si se colocara la clave de perro en la tabla persona tendría
que ser opcional y no se cumpliría la regla que indica que se requiere que
un perro tenga un propietario.
- Se puede pensar en combinar estas tablas. Definitivamente se puede
hacer, pero teniendo cuidado de que el objeto resultante no sea extraño o
que difiera de la realidad: una persona perro que es en parte persona y
opcionalmente perro sería una criatura en el mundo real. Además hay que
tener en cuenta que complicaría que cualquier código se reutilice.
Relaciones muchos a muchos
Las relaciones muchos a muchos deben de romperse por medio de una tercera
entidad.
Luego de lograr romper la relación, estamos ante los casos anteriores de uno a
muchos o de uno a uno, para los cuales ya se conoce como actuar.
Tema 4. Reglas y Operadores
4.1. Valores Nulos
Un valor nulo es un valor que está fuera de la definición de cualquier dominio el cual
permite dejar el valor del atributo “latente”. Su uso es frecuente en las siguientes
situaciones:
- Cuando se crea una tupla o registro y no se conocen todos los valores de cada
uno de los atributos.
- Cuando se agrega un atributo a una relación ya existente.
- Para no tomarse en cuenta al hacer cálculos numéricos
Suelen representarse por la palabra NULL.
4.2. Regla de Integridad de las Entidades
Esta regla es muy sencilla y dice así: “Ningún componente de la clave primaria de una
relación base puede aceptar valores nulos”.
La justificación de esta regla es la siguiente:
- Los registros dentro de las relaciones base representan entidades del mundo
real.
- Las entidades del mundo real se pueden identificar de alguna manera (esto por
definición).
- Dado el punto anterior, los representantes de las entidades en la base de datos
deben ser identificados (Distinguibles).
- Las claves primarias cumplen la función de identificación única dentro de la
base de datos.
- Si se incluyese un valor nulo en la clave primaria de un registro, equivale a
decir que ese valor existe en el mundo real como atributo de las relaciones.
- Si sucede lo anterior, puede ocurrir que el valor de ese registro no tiene
sentido o que se desconoce, esto es erróneo ya que las entidades deben tener
identidades, por algo la regla se llama “Integridad de las entidades”.
En conclusión: si una entidad es lo bastante importante para requerir una representación

explícita en la base de datos, entonces tal representación debe tener identificación
definida y sin ambigüedad, es por eso que la regla de integridad de identidades se
expresa a veces de esta manera: “En una base de datos relacional, nunca
registraremos información acerca de algo que no podamos identificar”
4.3. Reglas de Integridad Referencial
Esta regla dice así: “La base de datos no debe contener valores de clave ajena sin
concordancia”.
Con el término “valores de clave ajena sin concordancia”, se quiere decir que los valores
no nulos almacenados en la clave ajena deben ser concordantes con la clave primaria.
Esto sugiere la siguiente interpretación: si Y hace referencia a X, entonces X debe existir.
4.4. Operadores en el modelo Relacional
Los operadores del mundo relacional son de dos tipos: operadores de actualización y los
operadores del álgebra relacional, que serán analizados luego.
Las operaciones válidas para los valores de los registros son las de borrar, agregar o
modificar. El manejo de llaves primarias y foráneas incide directamente en procurar que
no se violen las reglas de integridad, al determinar cómo han de manejarse los
operadores de manera que al aplicar cualquier de estas operaciones no se produzca
inconsistencia.
Las reglas son las siguientes:
Reglas para agregar

Al insertar un registro en una relación, el valor de un atributo que sea llave foránea
puede ser nulo, o algún valor del atributo de la llave primaria en la relación
correspondiente.
Reglas para borrar

Si se tiene un registro de una relación R1 con un atributo Ai como llave primaria, y otra
relación R2 que tiene ese mismo atributo Ai pero como llave foránea, tenemos 3 casos:
- Borrado restringido: No se puede borrar el registro en la relación R1 cuya

llave primaria tenga un valor que en la relación R2 exista como uno de los
valores de la llave foránea.
- Borrado en cascada: Al borrar un registro en la relación R1 con cierto valor
en la llave primaria, se borrarán todos los registros en R 2 que tengan ese
mismo valor en la llave foránea.
- Borrado por nulificación: Al borrar un registro en la relación R1, a todos los
registros con el mismo valor de Ai en la relación R2 se les asigna un valor nulo
en el atributo de la llave foránea.
Reglas para modificar

Tenemos dos opciones:
- Modificación en cascada: Al modificar una llave primaria en R1 se le cambian

los valores correspondientes a la llave foránea en R2.
- Modificación por nulificación: Al cambiar los valores de la llave primaria en
R1, a los correspondientes valores en la llave foránea de R2 se les pone el valor
nulo.
Los esquemas por nulificación, en cascada y restringido tienen una aplicación lógica en
cuanto a cual de ellas utilizar, esto es, quien decide el esquema a utilizar es quien genera
las relaciones y quien sabe cuáles son las dependencias entre una relación o atributo con
otros, además podemos pensar que por períodos o situaciones particulares podemos
cambiar de uno a otro esquema.
Además la implementación del modelo relacional en un manejador de bases de datos no

obedece al 100% con todo el modelo y en particular necesita uno ubicar cuál de estos
esquemas permite (si es que tiene alguno).
Tema 5. Normalización
La teoría de la normalización, cuyas tres primeras formas normales fueron introducidas por
Codd desde sus primeros trabajos, elimina dependencias entre atributos que originan
anomalías en la actualización de la base de datos y proporciona una estructura más regular
en la representación de las relaciones, constituyendo el soporte para el diseño de bases de
datos relacionales.
5.1. Anomalías presentes
Antes de ingresar a discutir la normalización de tablas, veamos algunas de las fallas

comunes del diseño de base de datos relacionales y los problemas que ellas causan. Para
ilustrar estos problemas, usaremos la siguiente tabla de ejemplo que se muestra en la tabla
de la siguiente página.
Nombre_ Nombre_ ID_Curso1 Descripción_ Nombre_ ID_Curso2 Descripción_ Nombre_

Alumno Asesor Curso1 Instructor_ Curso2 Instructor_
Curso1 Curso2
Andrés Jorge Introducción a Guillermo Programación Roberto
VB1 DAO1
Guerrero Ortíz Visual Basic Roberts DAO Castro
Alvaro Daniel Programación Roberto SQL Server con Pedro
DAO1 VB-SQL1
Tresierra Camacho DAO Castro VB Vásquez
Luis César Ernesto Programación Eduardo
API1 API con VB OOP1
Flores Angulo Guevara O-O Talledo
Oscar Juan Introducción a Guillermo Ernesto
VB1 API1 API con VB
Sandoval Buendía Visual Basic Roberts Guevara
Algunos de los problemas que surgen ante esta estructura son:
Repetición de grupos
El ID, descripción e instructor de curso son repetidos para cada materia. Si un
estudiante necesita una tercera materia, se necesitará modificar la estructura de la
tabla para registrarlo. Así se podría necesitar añadir los campos correspondientes a
las materias ID_Curso3, ID_Curso4, ID_Curso5, etc., incluso así muchos de los
alumnos no las utilicen.
Inconsistencia de datos
Suponiendo que después de ingresar todas esas columnas, se descubre que el curso
que Guillermo Roberts dicta actualmente se llama “Introducción a Visual Basic
Avanzado”. Para reflejar ese cambio, se deben de revisar todos los registros y
cambiarlos individualmente. Esto introduce errores potenciales si uno de los cambios
es omitido o hecho incorrectamente.
Anomalías de eliminación
Suponiendo que quiera eliminar el registro de la materia que dicta Roberto Castro.
Para esto debería eliminar dos registros, lo que implica eliminar dos alumnos, dos
asesores y toda la información referente a los demás cursos de dichos alumnos.
Anomalías de Inserción
Imagine que el departamento académico piensa incorporar un nuevo curso llamado
“Programación Avanzada en DAO”, pero todavía no tiene un horario ni instructor para
éste. Tendríamos problemas para registrarlo puesto que no sabríamos qué colocar
en los campos estudiante e instructor
Como se puede ver, el diseño en una única tabla ha inducido a numerosos

problemas, los cuales pueden ser resueltos por procedimientos de normalización. Sin
embargo, hay que tener en cuenta que la normalización no es la solución a todos los
problemas. Existen muchas situaciones en las que es mejor ignorarla para obtener
otros beneficios como por ejemplo, mejor desempeño.
5.2. Proceso de Normalización
Esencialmente, la normalización es el proceso mediante el cual los esquemas

insatisfactorios se descomponen repartiendo los atributos en esquemas más pequeños
que poseen propiedades deseables.
Un diseño adecuadamente normalizado permite usar eficientemente el espacio de

almacenamiento, eliminar data redundante, reducir o eliminar la inconsistencia de los
datos y facilita el mantenimiento del modelo. Sin embargo, un esquema normalizado no
es garantía de un buen diseño (necesario, pero no suficiente).
Dependencia funcional
Dada una relación R, un atributo A de R es funcionalmente dependiente de un atributo B
de R, si para cada valor de B existe un único valor para A (B puede referirse a un
conjunto de atributos) y se denota B --> A.
Ejemplo:
DNI --> nombre
DNI --> fecha de nacimiento
(dia,hora,sala) --> curso
Dependencia funcional total

Un atributo A tiene dependencia (funcional) total de un conjunto de atributos B (B debe
ser compuesto), si tiene dependencia funcional de B pero no de algún subconjunto de B
(no hay dependencia parcial).
Ejemplo:
(dia,hora,sala) --> curso
Dos atributos son mutuamente independientes si ninguno tiene dependencia del otro.
Un atributo A es determinante si otro atributo B tiene dependencia funcional total de A.
Es la semántica asociada a cada aplicación la que determina el tipo de dependencia entre

los datos.
5.3. Formas de Normalización
Las reglas de normalización son llamadas formas normales. Las más comunes y
usadas son:
Primera Forma Normal (1FN)

Elimina la repetición de grupos (los campos sólo almacenan valores atómicos).
Segunda Forma Normal (2FN)

Logra que todos los atributos que no son claves dependan funcionalmente de la
totalidad de la clave primaria.
Tercera Forma Normal (3FN)

Logra que ningún atributo dependa funcionalmente de otro atributo que no sea un tipo
de clave.
Para que una base de datos esté en 2FN, esta debe estar también en 1FN y para que la
base de datos esté en 3FN, antes debe de estar en 1FN y 2FN.
Existe una versión más estricta de la tercera forma normal propuesta por Boyce y Codd
llamada la forma normal de Boyce-Codd.
Además, más adelante, se agregaron la cuarta forma normal (4FN) - que tiene que ver
con dependencias multivaluadas- y quinta forma normal (5FN) –llamada también
DK/NF que garantiza la eliminación de anomalías, pero no son usadas para los diseños
de bases de datos en la actualidad por ser poco requeridas y porque no existen
algoritmos para su aplicación.
Primera Forma Normal (1FN)
Establece que los dominios de los atributos sólo incluyen valores atómicos (simples e
indivisibles) y que los valores son individuales. Actualmente 1FN se considera parte de
la definición de relación. Además, 1FN no permite la anidación de relaciones ni la
repetición de grupos.
El valor de un atributo no puede ser un conjunto o tupla de valores, es decir que no

puede tener valores no atómicos.
Citemos el ejemplo presentado al inicio. Las columnas de la tabla son:
Alumnos
Nombre_Alumno
Nombre_Asesor
ID_Curso1
Descripción_Curso1
Nombre_Instructor_Curso1
ID_Curso2
Descripción_Curso2
Nombre_Instructor_Curso2
La parte terminal de los últimos 6 atributos (Curso1 y Curso2) nos da una señal que
hay una repetición de grupos. Estas columnas han sido repetidas para permitir
almacenar información referida a dos cursos por alumno. El problema, como vimos
antes, viene cuando se desea registrar más de dos cursos para un alumno.
Para solucionar esto, creemos una tabla separada para los datos del curso y la
relacionamos con la tabla que contiene los datos del alumno por medio de un ID que
actuará como clave foránea, como se muestra en las siguientes tablas.
Alumnos AlumnosCursos
ID_Alumno ID_Alumno
Nombre_Alumno ID_Curso
Nombre_Asesor Descripcion_Curso
Nombre_Instructor_Curso
Segunda Forma Normal (2FN)
Un esquema de una relación está en 2FN si todo atributo no primo (no es clave)
depende funcionalmente de manera total de la clave primaria de la relación.
La 2FN realmente sólo se aplica a tablas donde la clave primaria es definida por dos o
más atributos. La esencia es que si existen atributos que pueden ser identificados por
sólo una parte de la clave primaria, ellos necesitan estar en su propia tabla.
Por ejemplo, consideremos las tablas de la anterior. En la tabla AlumnosCursos, la

clave primaria está compuesta por la combinación de ID_Alumno y ID_Curso. Sin
embargo en la tabla existen atributos que solamente dependen de ID_Curso.
Aplicando 2FN a las tablas de la figura anterior, que están en 1FN, obtenemos las
tablas que se muestran en la siguiente figura.
Alumnos AlumnosCursos Cursos
ID_Alumno ID_Alumno ID_Curso

Nombre_Alumno ID_Curso Descripcion_Curso
Nombre_Asesor Nombre_Instructor_Curso
Antes de ingresar a la 3FN, modifiquemos el detalle de las tablas anteriores,

ingresando más información en ellas, como se muestra a continuación.
Alumnos AlumnosCursos Cursos
ID_Alumno ID_Alumno ID_Curso

Nombre_Alumno ID_Curso Descripcion_Curso
Teléfono_Alumno Nombre_Instructor_Curso
Dirección_Alumno Teléfono_Instructor_Curso
Ciudad_Alumno
Nombre_Asesor
Teléfono_Asesor
Tercera Forma Normal (3FN)
Una relación está en 3FN cuando ningún atributo no clave, depende funcionalmente de
otro atributo que no es clave de la relación. Esto quiere decir que todas las columnas
de la tabla contienen sólo data de la entidad que es definida por la clave primaria.
Para completar la normalización, necesitamos encontrar columnas que no dependan de

la clave primaria en la tabla. En la tabla Alumnos, tenemos dos tipos de datos acerca
del asesor del alumno: su nombre y su número telefónico. La información del asesor,
sin embargo, no es dependiente del alumno. Si el alumno sale de la escuela, los datos
del asesor deben seguir siendo los mismos y de alguna manera conservarse en
registro. La misma lógica se aplica a la información del instructor en la tabla Cursos.
La siguiente figura muestra la normalización completa y en ella se puede observar que

tanto asesor como instructor tienen sus propias tablas para registrar su información.
Alumnos Asesor AlumnosCursos Cursos
ID_Alumno ID_Asesor ID_Alumno ID_Curso

Nombre_Alumno Nombre_Asesor ID_Curso Descripcion_Curso
Teléfono_Alumno Teléfono_Asesor ID_Instructor_Curso
Dirección_Alumno
Ciudad_Alumno Instructor
ID_Asesor_Alumno
ID_Instructor
Nombre_Instructor
Teléfono_Instructor
Tema 6: Criterios de Diseño de Bases de Datos Relacionales
Desempeño Read versus Write/Update

Algunos diseños permiten realizar lecturas a una sola tabla, mientras otros toman en
cuenta lecturas a varias tablas. Por lo tanto, se debe conocer la frecuencia de las
lecturas y escrituras/actualizaciones antes de decidirse por un cierto diseño de
tablas.
Flexibilidad y Desempeño
Hay casos en que la flexibilidad es más importante que el desempeño. Un buen
ejemplo de esto son los procesos de desarrollo por prototipo, donde usualmente se
necesita insertar o eliminar atributos y tablas o reestructurar la organización de las
relaciones. Sin embargo, una vez que la estructura de las tablas y sus relaciones
estén bien definidas, el diseño debe estar orientado a un óptimo desempeño.
Desempeño versus Redundancia

El paradigma relacional nos ayuda a eliminar redundancia usando formas normales.
Sin embargo, las aplicaciones con bases de datos relacionales muestran mejor
desempeño con un mínimo número de accesos a la base de datos. Los accesos a la
base de datos pueden ser reducidos ignorando la normalización, con consecuencias
negativas en la mantenibilidad de la base de datos.
La mantenibilidad del modelo de datos y el desempeño son dos objetivos conflictivos.

A medida que se modifica el modelo de datos para óptimo desempeño, los costos de
mantenimiento aumentan en caso de cambios en la aplicación.
Consumo de espacio versus Desempeño

Existen diseños que resultan en bases de datos con campos conteniendo valores
nulos. Sin embargo, como todo está contenido en una sola tabla, el acceso es menor
y el desempeño mejor.
Procesamiento de Consultas
Debemos diferenciar dos tipos de propósitos de los datos en un sistema de
información: los que sirven para procesamiento de transacciones en línea, en las
cuales lo más importante es el desempeño. El otro tipo de datos es el que está
enfocado para data warehouse para los que se requiere una buena representación en
formas normales y no redundantes. Para realizar el mapeo a tablas debemos
conocer el objetivo de la aplicación, si es para procesamiento en línea o para data
warehouse.
Estilo de la Aplicación
Existen tipos de aplicaciones en las cuales resulta desastroso usar bases de datos
relacionales como mecanismo de persistencia. Algunas de estas son: aplicaciones
CAD, herramientas CASE o cualquier aplicación con persistencia check-in / check-out.
Tema 7: Limitaciones del Modelo Relacional
Durante los últimos años los Sistemas de Bases de Datos se han ido popularizando
cada vez más como una efectiva herramienta en el ámbito del almacenamiento y
recuperación de información. De los primeros sistemas de tipo jerárquico, se pasó a
sistemas más elaborados que utilizaban el modelo de red, y finalmente, el modelo
relacional ha sido aceptado ampliamente tanto en el mundo académico como
comercial.
No obstante lo anterior, en el último tiempo se han encontrado ciertos escenarios, en

que el modelo de dato relacional es insatisfactorio, y se han propuesto
modificaciones y extensiones a los sistemas, de modo de hacerlos más aplicables.
Concretamente, en el dominio de aplicaciones relacionadas con sistemas de diseño
apoyado por computador (CAD), en que la base de datos corresponde, por ejemplo,
a partes y piezas, en lugar de clientes y proveedores, el modelo relacional presenta
deficiencias tanto en la expresividad permitida, como en la eficiencia de las
operaciones necesarias.
El modelo relacional plantea una clase de objetos única: la Relación. Las ventajas de
la sencillez conceptual son evidentes, pero no siempre el mundo real es susceptible
de ser modelado en forma de tablas planas. A veces los objetos tienen estructura
jerárquica y no conviene aplanarlos (pérdida de claridad y de eficiencia).
Piénsese por ejemplo en una representación de objetos geométricos (para simplificar

rectángulos) mediante el siguiente esquema:
rect(nombre-rect, lado1, lado2, lado3, lado4)

lado(nombre-lado, vertice1, vertice2)
vertice(nombre-vert, coordenada-x, coordenada-y)
Podemos observar que la información de un objeto concreto está distribuida en 3

relaciones lo cual, por una parte dificulta la programación de aplicaciones que hagan
uso de estos objetos (expresividad), y además hace necesario efectuar un número
excesivo de "joins" para reconstruir el objeto (eficiencia).

BD U3 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

BD U3 PDF

Cargado por

Copyright:

Formatos disponibles

BD – Bases de Datos Unidad 3: Modelo Relacional

UNIDAD 3: EL MODELO RELACIONAL

El modelo relacional es sin lugar a dudas el fundamento de la tecnología moderna de bases

 Que haga posible ampliar la base de datos sin modificación de la estructura

 Que permita la máxima flexibilidad en la formulación de interrogantes de forma

Dada la popularidad del modelo relacional, muchos sistemas de la primera generación se

Una relación es un concepto matemático que consta de dos partes: encabezado y

o Al encabezado se le llama también esquema o intensión. Es un conjunto de n

o Al cuerpo se le conoce como extensión. Es un conjunto de m tuplas t, donde t es a

A los valores m y n se les denomina cardinalidad y grado, respectivamente, de la

En general, el modelo relacional se ocupa entonces de las relaciones n-arias para un

El gráfico anterior muestra un ejemplo de un modelo relacional. Todos los elementos se

Propiedades de las relaciones

1. No existen tuplas duplicadas

2. Las tuplas están en desorden, de arriba hacia abajo

3. Los atributos están en desorden, de izquierda a derecha

Siempre se hace referencia a los atributos por nombre, no por posición.

4. Cada tupla contiene exactamente un valor para cada atributo

5. Cada relación y cada atributo tienen nombres únicos

Representación de una Relación

Las tablas almacenan datos sobre una entidad o relación

Poseen las siguientes propiedades generales:

o Cada entrada de la tabla representa un ítem de datos; no hay grupos repetitivos.

o Cada columna tiene su nombre propio.

1. Relaciones Base: Son aquellas cuya importancia es tal que el diseñador de la

3. Resultados de Consultas: Ésta es tan sólo la relación final resultante de alguna

4. Resultados intermedios: Es una relación, casi siempre sin nombre, resultante de

Las columnas contienen los atributos de la entidad

Un dominio es el conjunto de valores legales de uno o varios atributos. Los dominios

El concepto de dominio es importante porque permite que el usuario defina, en un lugar

- El atributo Edad de una relación CIUDADANO, tiene un dominio que se representa:

DEdad = { x/x ε N ^ x < 120 }

- El atributo Día de una relación REGISTROS, tiene un dominio que se representa:

DDía = {Lunes, Martes, Miércoles, Jueves, Viernes, Sábado, Domingo}

- El atributo IndAcum, índice acumulado de una relación ALUMNO, tiene un dominio

1.5. Ventajas de la base de datos relacional

Lenguaje para la manipulación de datos

1.6. Claves en el Modelo Relacional

Clave Aspirante o Clave Candidata

- Unicidad: En cualquier momento no existen dos registros con el mismo valor de X en

- Minimalidad: Si X es compuesto, al eliminar cualquiera de sus componentes,

De todas las claves candidatas existentes en una entidad, el diseñador de la base de

Encontramos como ejemplo de superclaves los siguientes atributos o campos:

Clave Primaria Claves Secundarias

Identificador de Conjunto de valores de un Algunos atributos son identificadores

Tema 2. Álgebra Relacional

La parte de manipulación del modelo relacional ha evolucionado considerablemente desde la

Propiedad de Cierre del Álgebra Relacional

2.1. Álgebra Relacional

o Conjunto tradicional de operadores unión, intersección, diferencia, y producto

Restringir Proyectar Producto

Unión Intersección Diferencia

Semántica de las Operaciones del Álgebra Relacional

V# Proveedor Status Ciudad V# Proveedor Status Ciudad

V1 Smith 20 Londres V1 Smith 20 Londres

V# Proveedor Status Ciudad

V# Proveedor Status Ciudad

V# Proveedor Status Ciudad

V# Proveedor Status Ciudad

La cardinalidad del resultado es el producto de las cardinalidades de A y B, y que la

(V WHERE CIUDAD = ‘Londres’) (V WHERE STATUS < 15)

V# Proveedor Status Ciudad V# Proveedor Status Ciudad

V1 Smith 20 Londres V2 Jones 10 París