UD4 Modelo de Datos Relacional - Sesión 1

El modelo relacional
Previo
La implementación del diseño de una base de datos requiere un
modelo lógico, como el modelo relacional, donde se utilicen
determinadas estructuras de datos para representar los distintos
elementos de información.
Por tanto, es necesario que el modelo conceptual resultado de la
abstracción de diseño sea traducido al conjunto de estructuras
de datos que utilice el Sistema de Gestión de Base de Datos
(SGBD) elegido para su implementación.
Actualmente, los Sistemas de Gestión de Bases de Datos
Relacionales (SGBDR) son los más ampliamente utilizados para la
implementación de bases de datos. Estos sistemas se basan en el
concepto de relación que establece el Álgebra de la Teoría de
Conjuntos como estructura para la representación lógica de la
información.
Previo
Dada la importancia que tienen en el panorama actual las bases
de datos relacionales resulta imposible no dedicarles una unidad
completa para su adecuado estudio.
En esta unidad se van estudiar los conceptos relacionados con el
modelo relacional. Este modelo sigue, en el desarrollo de bases
de datos, al diseño realizado mediante la herramienta que
proporciona el modelo conceptual que se ha tratado.
El modelo relacional es un modelo lógico en que puede
concretarse el diseño de una base de datos realizado a través de
la herramienta que proporciona el modelo conceptual tratado en
la Unidad anterior.
Previo
Así pues, esta Unidad profundizará en la obtención del modelo
lógico relacional a partir del modelo conceptual que constituye
el modelo Entidad/Relación. De esta forma, se estudiarán las
estrategias para llevar a cabo este paso y, sobre todo, para
realizarlo de forma que no exista pérdida semántica en la
traducción o que esta sea mínima.
Previo
En la presente unidad vamos a tratar en profundidad los
siguientes temas:
 El concepto algebraico de relación que constituye el
fundamento de las bases de datos relacionales.
 Las propiedades más importantes de las relaciones y sus
restricciones semánticas, incluida la integridad referencial.
 La representación de entidades y asociaciones entre ellas a
través del grafo relacional.
 Finalmente, y de gran importancia, se tratarán las distintas
técnicas para llevar a cabo la transformación del Modelo
Entidad/Relación al Modelo Relacional.
Introducción
En la Unidad 3 se trató ampliamente el modelo Entidad/Relación
como modelo conceptual que proporciona una herramienta de
abstracción para el diseño de bases de datos.
El modelo Entidad/Relación, y el modelo Entidad/Relación
Extendido, ofrecen un robusto modelo formal para la
representación de la información considerada de interés así
como de su estructura de interrelaciones. De esta forma, el
modelo Entidad/Relación permite reflejar gran parte, sino toda,
de la semántica propia del universo de discurso a modelar.
Sin embargo, el modelo Entidad/Relación es un modelo
netamente conceptual y como tal no es directamente soportado
por ningún Sistema de Gestión de Base de Datos (SGBD).
Introducción
Sin embargo, el modelo Entidad/Relación es un modelo
netamente conceptual y como tal no es directamente soportado
por ningún Sistema de Gestión de Base de Datos (SGBD).
Como se ha podido ver, hay algunos elementos que no se
trasladan directamente desde el modelo de datos conceptual
(realizado mediante por ejemplo la herramienta Dia) al modelo
lógico (realizado mediante por ejemplo la herramienta MySQL
Workbench. Un ejemplo de estos elementos, son las relaciones
M:N que existen en el modelo de datos conceptual pero en
MySQL Workbench, se convierten automáticamente a relaciones
1:N con una entidad auxiliar.
Introducción
Así pues, para llevar a cabo la implementación de una
determinada base de datos será necesario desarrollar un modelo
de datos lógico que, utilizando determinadas estructuras de
datos, permita representar la misma información que el modelo
conceptual.
El modelo lógico será parte del Sistema de Gestión de la Base de
Datos (SGBD) que proporcionará las herramientas adecuadas para
su definición y gestión.
Además, será el mismo Sistema de Gestión de Base de Datos el
que traslade el modelo lógico generado a un modelo físico que
permita el almacenamiento de los datos en un sistema
informático.
Introducción
En función del tipo de estructura de datos utilizada, existen
distintas formas de presentar la información y, por tanto,
distintos modelos lógicos. En nuestro caso, nos centraremos en el
modelo relacional que es casi hegemónico en el panorama actual
de las bases de datos corporativas.
Bases de datos relacionales
Las bases de datos relacionales, como su nombre indica, utilizan
un modelo lógico de datos basado en el concepto de relación.
Según la Teoría de Conjuntos, una relación viene dada por grupos
de valores (denominados tuplas) que se toman de los
correspondientes dominios.
El concepto de dominio es completamente similar al utilizado en
el modelo Entidad/Relación y especifica una colección completa
de posibles valores para un determinado elemento. Ejemplos de
dominios serían: los números naturales, los números enteros
(positivos y negativos), las cadenas de caracteres de longitud 6,
etc.
De esta forma, en cada tupla de la relación cada valor se indica
como perteneciente al dominio del que se ha tomado.
Así:
donde t1 Є R y t2 Є R corresponderían a dos tuplas de una

hipotética relación R.
Cada tupla estaría formada por n valores y, según se ha indicado,
cada valor se toma de su correspondiente dominio. A
continuación se puede ver un ejemplo:
Tupla 1
Tupla 2
Dominio 1: Dominio 2:
Proveedores Apellidos
https://yanoquiero.com/c-tecnologia/que-es-una-tabla-en-base-de-datos/
Por supuesto, todas las tuplas de la relación mantendrán el
mismo número y ordenación de sus valores que se tomarán de los
mismos dominios. Por ejemplo, el primer valor de todas las
tuplas corresponderá siempre al dominio D1.
Como puede apreciarse, incluso visualmente, una sucesión de
tuplas forma una matriz o tabla de valores donde las filas
(elementos horizontales) corresponden a las distintas tuplas de
valores y las columnas (elementos verticales) a los
correspondientes dominios.
Por esta razón, normalmente se dice que las bases de datos
relacionales estructuran la información mediante tablas.
El modelo relacional fue propuesto por E. F. Codd a finales de los
años 60 en un artículo denominado “A Relational Model for Large
Shared Data Banks” basándose en conceptos de la Teoría de
Conjuntos y de las Relaciones algebraicas.
El modelo Relacional persigue los siguientes objetivos:
El modelo Relacional persigue los siguientes objetivos:
 Independencia física: De manera que la representación lógica
de la información se mantenga separada de su
almacenamiento físico.
 Flexibilidad: Para poder recoger los esquemas de información
de los distintos usuarios (perfiles de usuarios).
 Uniformidad: De forma que se utilice un único tipo de
estructura de datos para la representación tanto de las
distintas entidades consideradas de interés como de las
interrelaciones entre ellas.
 Sencillez: Para que su manejo y comprensión resulten
sencillos.
Aunque en algunas ocasiones sería posible obtener el modelo
relacional directamente a partir de las condiciones del
problema, se seguirá la metodología basada en obtenerlo como
refinamiento del modelo conceptual de diseño plasmado en un
diagrama Entidad/Relación.
De esta forma, se utilizará un conjunto tipificado de reglas para
pasar del modelo Entidad/Relación al Modelo Relacional.
Como todo modelo, incluye una parte estática y otra dinámica.
Se introduce el concepto de relación como estructura básica de
la parte estática del modelo.
Como parte dinámica se proponen un conjunto de operadores
sobre las relaciones que dan lugar a la denominada Álgebra
Relacional.
Relaciones o tablas
La estructura básica de las relaciones quedará representada
como se indica a continuación:
Representación genérica de una tabla o relación (OpenUAX).

Relaciones o tablas
Cada relación quedará así caracterizada por:
 Nombre: Identifica la relación.
 Atributos: Representan las propiedades comunes de todos los
elementos que forman parte de la relación.
 Tupla: Conjunto de valores que toman los atributos para un
elemento concreto de la relación.
Relaciones o tablas
Además, se establecen también las siguientes propiedades de
una relación:
 Grado: Número de atributos o propiedades de los elementos
de la relación.
 Cardinalidad: Número de tuplas.
 Dominio: Conjunto finito de valores homogéneos y atómicos.
Todo dominio tendrá un nombre y se asociará a un tipo
concreto de datos. Cada atributo de la relación tomará sus
valores de un solo dominio. Por supuesto, pueden definirse
distintos atributos sobre un mismo dominio. Por ejemplo,
nombre y apellidos toman el dominio de las cadenas de
caracteres.
Relaciones o tablas
La siguiente figura muestra un sencillo ejemplo de relación:
Ejemplo de relación (OpenUAX).

Relaciones o tablas
Es posible definir una relación mediante su Intensión. La
intensión constituye la parte estática y de definición de una
relación y también se denomina esquema de relación.
La notación para un esquema de relación es la siguiente:
R({Ai:Di}i=1 .. n)
Donde R es el nombre de la relación, Ai cada uno de sus atributos

y Di el dominio de cada uno de ellos.
Al conjunto de n pares {Ai:Di} se le suele denominar cabecera de
la relación. Por tanto el esquema de relación se compone del
nombre de la relación y de su cabecera.
Relaciones o tablas
La definición por Extensión de una relación consiste en
especificar la relación a través del conjunto de tuplas que, en un
momento determinado, cumplen el esquema de la relación. Es
decir, poner los datos como en la figura anterior.
Relaciones o tablas
Por otro lado, se establecen los siguientes tipos de relación:
 Relaciones básicas: Se definen con independencia de las
demás relaciones. Se corresponden con las entidades o
asociaciones definidas en el nivel conceptual y siempre tienen
nombre.
 Relaciones derivadas: Se definen como el resultado de
efectuar operaciones relacionales sobre otras relaciones
básicas o derivadas. Pueden no tener existencia física ni
almacenarse nombre bastando con almacenarse su definición.
Las relaciones derivadas son convenientes ya que expresan
información de varias relaciones actuando como si fuera una
sola.
Relaciones o tablas
Las relaciones derivadas pueden ser:
 Vistas: Se corresponden con el nivel más externo o de usuario,
son virtuales. Se definen dando un nombre a una expresión de
consulta y no tienen datos propios almacenados.
 Instantáneas: Se corresponde con el nivel más interno, son
reales. Tienen datos propios almacenados que son el resultado
de ejecutar una consulta. Se corresponden con la situación de
la base de datos en un instante determinado.
Atributos clave de la relación
En el modelo relacional, se define la clave candidata de una
relación como un conjunto no vacío de atributos que identifican
de forma unívoca cada tupla de la relación. Esto significa que:
 No puede haber dos o más tuplas con el mismo de valor de una
clave candidata (el valor de la clave candidata tiene que ser
distinto en todas las tuplas).
El conjunto de atributos de una clave candidata deberá ser tal
que si se suprime cualquiera de ellos, la clave deje de serlo. Es
decir, no se consideran claves candidatas los superconjuntos de
claves candidatas. Ya que si hay un conjunto de claves
candidatas, la supresión de una clave sigue permitiendo a las
demás, identificar tuplas de manera inequívoca.
A partir del conjunto de claves candidatas de una relación se
definen:
 Clave primaria: Es aquella clave candidata que se elige para
identificar a las tuplas.
 Clave alternativa: Cualquiera del resto de claves candidatas.
Por otro lado tenemos las claves externas o ajenas. Una clave
externa de una relación R2 con respecto de una relación R1 se
define como un conjunto no vacío de atributos de R2 cuyos
valores deben ser nulos o coincidir con los de alguna de las
claves candidatas de R1 para una determinada tupla (es clave
candidata en la otra relación pero puede ser nula en esta).
El dominio de la clave externa debe coincidir con el dominio de
la candidata con la que se corresponde.
De esta forma, una clave externa en R2 debe poder referenciar
de forma unívoca una de las tuplas de la relación R1 desde otra
de R2.
Restricciones del modelo relacional
La parte estática del modelo relacional incluye restricciones
inherentes impuestas por la naturaleza del propio modelo y
restricciones semánticas que ayudan a representar con mayor
fidelidad las características del mundo real.
Las restricciones inherentes se derivan de la definición
matemática de relación.
 No pueden existir tuplas duplicadas (implica la existencia de
una clave primaria). Si hay una clave primaria en las
relaciones, no puede haber tuplas duplicadas.
 El orden de las tuplas no es relevante.
 El orden de los atributos no es significativo.
 Regla de integridad de entidad: Ningún atributo de la clave
primaria de una relación puede tener valor desconocido o
inexistente, es decir, no puede ser nulo (NULL).
 Cada atributo de una tupla sólo puede tomar un valor de su
dominio. No se permiten grupos repetitivos. Esta es la
definición de Primera forma normal (1FN) de la tabla como se
verá en la siguiente unidad. A continuación se ven ejemplos de
grupos repetitivos.
Grupo repetitivo de dominios y valores: el campo "Teléfono"
contiene más de un valor en un registro dado. Si "Teléfono" está
definido en algún tipo de dominio de número telefónico (como
podría ser por ejemplo, el dominio de cadenas de 12 caracteres
de longitud), se tendría un campo con más de un valor de
dominio de columna (varias cadenas de 12 caracteres de
longitud):
https://es.wikipedia.org/wiki/Primera_forma_normal#Grupos_repetidos
Grupo repetitivo a través de columnas: Definir varias columnas
del número telefónico con el mismo dominio (cadenas de 12
caracteres de longitud). En este caso se generan valores nulos
que no se pueden permitir como se vio anteriormente (regla de
integridad de entidad).
Repetición de grupos dentro de columnas: Conservar una sola
columna de número de teléfono, pero alterando su dominio,
haciendo una cadena de suficiente longitud para acomodar
múltiples números telefónicos. Se genera un error semántico: ¿se
representa un teléfono o una lista de teléfonos? Cómo se
solucionaría el caso de obtener pares de clientes con el mismo
teléfono?
Se podría solucionar con dos relaciones/tablas: Cliente y
Teléfono de cliente como se indica a continuación:
Las restricciones semánticas permiten expresar normas presentes
en el Universo del Discurso de forma que éste pueda ser
modelado con más fidelidad. Las principales son:
 Clave primaria (PRIMARY KEY): Permite declarar uno o varios
atributos como clave primaria por lo que sus valores no podrán
repetirse dentro del conjunto de tuplas ni tampoco ser nulos.
 Unicidad (UNIQUE): Indica que no puede haber valores
duplicados de ese atributo en todo el conjunto de tuplas.
Permite valores nulos y permite definir claves alternativas.
 Obligatoriedad (NOT NULL): Indica que un atributo no admite
valores nulos.
 Integridad referencial (FOREIGN KEY): Si en una relación R2
existen uno, o varios atributos que constituyen una clave
candidata en otra relación R1, su valor tendrá que coincidir
con el de alguna de las tuplas de R1 para ese conjunto de
atributos o ser nulo. El atributo (o atributos) en cuestión
cumple así con el principio de integridad referencial y de esta
forma se evitan referencias nulas o vacías. A continuación se
ve un ejemplo donde se incumple esto:
La relación Teléfono del cliente tiene el atributo ID Cliente que
es clave candidata en la relación Cliente, pero en el caso del
valor 456, no coincide con ninguna tupla de Cliente y no es nulo:
Integridad referencial
Siendo que una relación R2 que incluye uno o varios atributos
que actúan como clave externa hacia R1, podemos considerar
que
 R2 es la relación que referencia ya que es la relación que
incluye a la clave externa.
 R1 es la relación referenciada. Es decir, R1 es la relación que
contiene la clave candidata cuyos valores deben coincidir con
los de la clave externa.
Se puede ver un ejemplo a continuación:

Relación referenciada Relación que referencia
La integridad referencial persigue que todas las ocurrencias de
asociación entre las tuplas (que se corresponden a ocurrencias
de entidad) de distintas tablas sean válidas. Esto se traduce en
que todo valor incluido en el atributo que actúa como clave
externa en una tabla exista para el atributo que actúa como
clave candidata en la otra tabla.
De esta forma, junto con las claves externas es necesario definir
unas reglas de integridad referencial, es decir, el
comportamiento deseado cuando se intente eliminar una tupla
de R1 cuya valor de clave candidata se incluye en el atributo o
atributo que actúa como clave externa en R2:
Además del borrado, también es posible que se modifique el
valor de la clave candidata en alguna tupla de R1, lo que violaría
la integridad referencial si el valor se incluye entre los de la
clave externa de R2:
621
Así, si se borran tuplas de una relación R1 con claves
referenciadas desde una relación R2 o los valores de las claves
de R1 son modificados, se puede establecer la realización de una
de las siguientes acciones:
 Operación restringida (NO ACTION): Sólo es posible el
borrado/modificación de las tuplas de R1 si NO existen tuplas
en R2 que contengan esos valores para los atributos que hacen
de claves externas.
 Operación en cascada (CASCADE): El borrado/modificación de
las tuplas de R1 desencadena el borrado/modificación de las
tuplas de la relación R2 que tengan esos mismos valores para
los atributos que estén actuando como claves externas.
 Operación puesta a nulo (SET NULL) o a valor por defecto (SET
DEFAULT): El borrado/modificación de las tuplas de R1 hace
que los valores de los atributos que actúan como clave externa
en la tabla R2 que las referencian se pongan a NULL (si es
posible) o al valor establecido por defecto.
El rechazo es otro tipo de restricción semántica que se basa en

la formulación de una condición sobre un conjunto de tuplas o
atributos. Una determinada operación de borrado o actualización
sólo podrá efectuarse si su resultado verifica la/s condición/es
establecida/s. El objetivo de esta restricción es evitar que la
base de datos se quede en un estado incorrecto.
En SQL92 se establecen dos tipos de rechazo:
 Verificación (CHECK): Se establece sobre un determinado
elemento y se comprueba cada vez que se realiza una
operación sobre el mismo. Por ejemplo se puede establecer un
atributo edad que tenga que ser mayor de 18.
 Aserción (ASSERTION): Funciona como la anterior pero puede
aplicarse a varios elementos, por ejemplo, dos relaciones.
Deben tener nombre porque tienen existencia propia en la
Base de Datos.
Los disparadores o triggers permiten, además de especificar una
condición, indicar la acción que se llevará a cabo si la condición
se cumple.
Pueden interpretarse como reglas de tipo Evento-Condición-
Acción que especifican que cuando se produce un evento y se
cumple una condición, se realiza una determinada acción. Estos
elementos:
 Amplían la funcionalidad de la Base de Datos ya que permiten
establecer reglas y acciones cuando se realicen operaciones de
inserción, borrado y modificación sobre elementos de las
relaciones.
 Son procedimentales, es decir, se implementan con código
escrito en un lenguaje de programación que especifica la
acción que se desea llevar a cabo.
El grafo relacional
El Grafo Relacional permite representar gráficamente las
distintas partes de la estática del Modelo Relacional. Así, este
tipo de grafo permite incluir las relaciones, las interrelaciones
entre ellas, los distintos tipos de claves y las restricciones de
integridad referencial.
Se utiliza una notación especial que se enumera a continuación:
 Los nombres de las relaciones se escriben con mayúsculas.
 Los atributos suelen expresarse al lado del nombre de la
relación entre paréntesis.
 Las claves primarias se subrayan con un trazo continuo.
 Las claves alternativas se subrayan con un trazo discontinuo.
El grafo relacional
 Las claves externas referencian a claves candidatas de otras
relaciones mediante flechas dirigidas hacia ellas.
 Los atributos que pueden tomar valores nulos aparecen
acompañados de un asterisco.
 Para las opciones de borrado y modificación relativas a las
reglas de la integridad referencial se pueden utilizar las
siguientes siglas:
 Para el borrado:
 BR: Borrado Restringido.
 BC: Borrado en Cascada
 BN: Borrado con set NULL.
 BD: Borrado con set DEFAULT.
El grafo relacional
 Para la modificación
 MR: Modificación Restringido.
 MC: Modificación en Cascada
 MN: Modificación con set NULL.
 MD: Modificación con set DEFAULT.
El grafo relacional
La siguiente figura muestra un ejemplo de grafo relacional:
Ejemplo de grafo relacional

(OpenUAX).
Transformación del modelo entidad/relación
al modelo relacional
La obtención del diagrama relacional debe identificarse con el
modelado lógico en el que se determinan las estructuras de
datos que recogen los elementos de información y sus distintas
interrelaciones que se han definido previa y conceptualmente en
el modelo Entidad/Relación.
El diagrama o grafo relacional ya es soportado por el Sistema de
Gestión de Bases de Datos (SGBD) que se va a utilizar y, por
tanto, constituye, el primer acercamiento al sistema informático
en que implementará finalmente la Base de Datos.
Transformación del modelo entidad/relación
al modelo relacional
Normalmente, el Sistema de Gestión de Bases de Datos (SGBD)
utilizado será capaz de trasladar automáticamente las relaciones
o tablas especificadas al servidor de bases de datos creando para
ello el correspondiente modelo físico y resolviendo todas las
cuestiones relacionadas con el almacenamiento de la
información de forma persistente en el sistema informático de
soporte.
Reglas básicas
Con respecto a los atributos, se seguirán las siguientes reglas
básicas a la hora de transformar el diagrama Entidad/Relación en
el diagrama Relacional:
 Toda entidad del Modelo Entidad/Relación se transformará en
una relación del Modelo Relacional.
 De forma automática el Atributo Identificador Principal de la
entidad se transformará en la clave primaria de la relación y
aparecerá indicado con subrayado continuo.
 Los Atributos Identificadores Alternativos se transformarán,
por su parte, en atributos con la restricción UNIQUE y
aparecerán con subrayado discontinuo.
Reglas básicas
 Toda interrelación o asociación de tipo Muchos a Muchos (N:M)
se transformará en una nueva relación del Modelo Relacional.
 Las interrelaciones o asociaciones de tipo Uno a muchos (1:N)
darán lugar, o bien a la propagación de clave de una relación a
otra, o bien a nueva relación en el Modelo Relacional.
 Con respecto a los demás atributos se tendrán en cuenta las
siguientes consideraciones:
 Losatributos univaluados del Modelo Entidad/Relación se
mantendrán en el Modelo Relacional.
 Los atributos multivaluados (teléfonos, notas, valores,…)
darían lugar a grupos repetitivos y se transformarán en una
relación cuya clave primaria será la clave primaria de la
relación donde se encontraba el atributo multivaluado más
el propio atributo multivaluado. Por ejemplo:
Reglas básicas
Se elimina Teléfono
de PERSONAL y pasa
a ser clave principal
PERSONAL (DNI, Nombre) de TELEFONOS en
TELEFONOS (DNI, Teléfono) combinación con DNI.
Reglas básicas
 Los atributos obligatorios del Modelo Entidad/Relación pasan a
ser atributos con la restricción NOT NULL.
 Los atributos opcionales (que pueden tener valores NULL) se
indican acompañados por un asterisco.
 Los atributos compuestos se transformarán en los atributos que
los componen:
PERSONAL (DNI, Nombre, Ciudad, Calle, Número)

Transformación de las asociaciones muchos a
muchos (M:N)
Cada asociación o interrelación Muchos a Muchos (M:N) de modelo
Entidad/Relación dará lugar a una nueva relación cuya clave
primaria será la concatenación de las claves primarias de las dos
relaciones involucradas en la asociación. De esta forma, el
atributo (o conjunto de ellos) que constituye la clave primaria de
cada relación se integrará en la clave primaria de la relación que
representa a la asociación y actuará como clave externa hacia la
relación cuyas tuplas identifica.
Si en la asociación existieran atributos multivaluados, estos
pasarán forzosamente a formar parte de la clave primaria de la
relación que representa la asociación.
Esto no es necesario en el caso de los atributos univaluados.
muchos (M:N)
Considere el diagrama Entidad/Relación con una asociación
Muchos a Muchos como el que se presenta a continuación:
Diagrama Entidad/Relación con Asociación Muchos a Muchos

(OpenUAX).
muchos (M:N)
La transformación del diagrama Entidad/Relación de esta figura a
un diagrama relacional se realizará habilitando una relación por
cada entidad expresada (Socio y Película) y otra relación adicional
para representar la asociación Muchos a Muchos. Dado que un
Socio puede alquilar la misma Película en varias ocasiones, el
atributo FecAlquiler de la asociación se incorporará a la clave
primaria de la relación que la representa.
muchos (M:N)
Como se indicaba anteriormente, los atributos que constituyen las
claves primaras de las relaciones Socio y Película actúan como
claves externas hacia ellas desde la relación que representa la
asociación Alquila y se unen para actuar como clave primaria de
dicha relación. En este caso, será necesario además añadir el
atributo que representa la Fecha de Alquiler ya que se requiere la
combinación de IdSocio, CodPelícula y FecAlquiler para crear un
alquiler único.
Teniendo en cuenta todo lo anterior, el resultado de transformar
a grafo relacional el diagrama Entidad/Relación es el siguiente:
muchos (M:N)
Borrado y
modificación en
cascada si cambia
Diagrama o Grafo Relacional resultado (OpenUAX)

Transformación de las asociaciones uno a
muchos (1:N)
Para la transformación de asociaciones Uno a Muchos (1:N) a
relaciones existen dos posibilidades:
 Propagar el Atributo Identificador Principal (AIP) de la entidad
que se encuentra en el lado 1 de la asociación al esquema de
relación resultante de la entidad en el lado N. Es decir, la clave
primaria de la relación en el lado 1 se incorpora como clave
externa en el esquema de la relación del lado N.
 Crear una nueva relación cuya clave primaria será sólo el
Atributo Identificador Principal (AIP) de la entidad en el lado N.
Esta opción suele utilizarse si la asociación tiene atributos o si
la propagación daría lugar a gran cantidad de valores NULOS
(NULL) para el campo que actúe como clave externa.

UD4 Modelo de Datos Relacional - Sesión 1

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

UD4 Modelo de Datos Relacional - Sesión 1

Cargado por

Copyright:

Formatos disponibles

El modelo relacional

donde t1 Є R y t2 Є R corresponderían a dos tuplas de una

Representación genérica de una tabla o relación (OpenUAX).

Ejemplo de relación (OpenUAX).

Donde R es el nombre de la relación, Ai cada uno de sus atributos

Se puede ver un ejemplo a continuación:

El rechazo es otro tipo de restricción semántica que se basa en

Ejemplo de grafo relacional

PERSONAL (DNI, Nombre, Ciudad, Calle, Número)

Diagrama Entidad/Relación con Asociación Muchos a Muchos

Diagrama o Grafo Relacional resultado (OpenUAX)

También podría gustarte