Capítulo 10:
Traduciendo Modelos a
Esquema Relacional
Agenda
• Traducción del modelo objeto a una BD relacional
• Traducción de diagramas de clases a tablas
Traduciendo un Modelo de Objetos a una BD
• Modelos de Objetos UML pueden ser traducidos a BD relacionales:
• Alguna degradación ocurre debido a que todos los constructores de UML debe ser traducidos a un sólo constructor de BD relacional – la tabla
• Traducción de clases, atributos y asociaciones
• Cada clase es traducida a una tabla
• Cada atributo es traducido a una columna en la tabla
• Una instancia de una clase representa a una tupla en la tabla
• Una asociación muchos-a-muchos es traducida como una tabla
• Una asociación uno-a-muchos es implementada a través de claves foráneas
• Los Métodos no son traducidos.
Traduciendo una Clase a una Tabla
User
+firstName:String +login:String
+email:String
id:long firstName:text[25] login:text[8] email:text[32]
User table
Claves Primarias y Foráneas
• Cualquier conjunto de atributos que pueden ser usados para identificar unívocamente cualquier tupla en una tabla relacional es llamado una
clave candidata
• La clave candidata actual que es usada en la aplicación para identificar las tuplas es llamada la clave primaria
• La clave primaria de una tabla es un conjunto de
atributos cuyos valores identifican unívocamente las tuplas de una tabla
• Una clave foránea es un atributo (o un
conjunto de atributos) que referencia la clave
primaria de otra tabla.
Ejemplo de Claves Primarias y Foráneas
Tabla User
Clave Candidata
login email
“am384” “[email protected]”
“js289” “[email protected]”
firstName
“alice”
“john”
“bd” “[email protected]”
“bob”
Clave Candidata Clave Primaria
Tabla League login
“am384”
“bd”
name
“tictactoeNovice”
“tictactoeExpert”
“js289”
“chessNovice”
Clave Foránea referenciando a User
Asociación Buried
League LeagueOwner 1 *
id:long
LeagueOwner table
... owner:long
League table ...
id:long
• Asociaciones con multiplicidad “uno” pueden ser implementadas usando una clave foránea
Para asociaciones uno-a-muchos, se añade la clave foránea a la tabla que representa a la clase que tiene a “muchos”
owner
Otro Ejemplo para Asociación Buried
Transaction transactionID
Portfolio portfolioID
...
*
portfolioID ...
Tabla Portfolio Tabla Transaction
transactionID portfolioID
Clave Foránea
Traduciendo Asociaciones Muchos-a- Muchos
City cityName
Airport airportCode airportName
* Serves *
cityName Houston
Albany Munich Hamburg Tabla City
airportCode IAH HOU
ALB MUC HAM
Tabla Airport airportName Intercontinental
Hobby Albany County Munich Airport Hamburg Airport
cityName Houston Houston Albany Munich Hamburg Tabla Serves
airportCode IAH HOU
ALB MUC HAM
En este caso se necesita una tabla separada para la asociación
Tabla Separada para la asociación “Serves”
Clave Primaria
Otra Traducción de Asociaciones Muchos- a-Muchos
Player
Tournament * *
id
Tabla Tournament
23
name ...
novice 24 expert
tournament player Tabla
TournamentPlayerAssociation
23 56
23 79
Tabla Player id
56
name ...
alice 79 john
Se necesita la asociación Tournament/Player como una tabla separada
Traduciendo Herencia
• BDR no soportan herencia
• Dos posibilidades para traducir una asociación de herencia a un esquema de BD
• Con una tabla separada (”traducción vertical”)
• Los atributos de las superclase y las subclases son traducidos hacia tablas diferentes
• Con columnas duplicadas (”traducción horizontal”)
• No hay una tabla para la superclase
• Cada subclase es traducida a una que contiene los atributos de la subclase y los atributos de la
superclase
Traduciendo Jerarquía de Herencia con una tabla separada (Traducción Vertical)
Tabla User id
56
name ...
zoe 79 john
role
LeagueOwner Player
Player User
LeagueOwner
maxNumLeagues credits name
Tabla Player id
79
credits ...
126 id
Tabla LeagueOwner
56
maxNumLeagues ...
12
Traduciendo Jerarquía de Herencia con columnas duplicadas (Traducción
Horizontal)
Player User
LeagueOwner
maxNumLeagues credits
name
id
Tabla LeagueOwner
56
maxNumLeagues ...
12 name
zoe
Tabla Player id
79
credits ...
126 name
john
Comparación: Tablas Separadas vs Columnas Duplicadas
• El trade-off es entre modificabilidad y tiempo de respuesta
• ¿Cuán probable es un cambio de la superclase?
• ¿Cuáles son los requerimientos de rendimiento para las consultas?
• Traducción de Tablas Separadas (Traducción Vertical)
☺Se pueden añadir atributos a la superclase agregando columnas a la tabla superclase
Buscar los atributos de un objeto requiere una operación de join.
• Columnas Duplicadas (Traducción Horizontal)
Modificar el esquema de BD es más complejo y propenso a error
☺Los objetos individuales no están fragmentados a
través de un número de tablas, resultando en consultas más rápidas
Correspondencia
• Uso del Patrón Representación de Objetos como Tablas
• Definir una tabla en una BDR por cada clase de objeto persistente.
• Los atributos cuyos tipos de datos son primitivos (número, cadena de texto, booleano, etc) se
corresponden con las columnas. (1FN)
• Relaciones 1:1:
• Crear una clave foránea en una o ambas tablas.
• Crear una tabla asociación con ambos OIDs
Correspondencia
• Uso del Patrón Representación de las Relaciones de los Objetos en Tablas
• Relaciones 1:N:
• Crear una clave foránea (del lado N).
• Crear una tabla asociación con ambos OIDs
• Relaciones M:N
• Crear una tabla asociación con ambos OIDs
