Modelo Relacional. En 1970, el modo en que se veían las bases de datos cambió por completo cuando E. F. Codd introdujo el modelo relacional. En aquellos momentos, el enfoque existente para la estructura de las bases de datos utilizaba punteros físicos (direcciones de disco) para relacionar registros de distintos archivos. Si, por ejemplo, se quería relacionar un registro con un registro, se debía añadir al registro un campo conteniendo la dirección en disco del registro. Este campo añadido, un puntero físico, siempre señalaría desde el registro al registro. Codd demostró que estas bases de datos limitaban en gran medida los tipos de operaciones que los usuarios podían realizar sobre los datos. Además, estas bases de datos eran muy vulnerables a cambios en el entorno físico. Si se añadían los controladores de un nuevo disco al sistema y los datos se movían de una localización física a otra, se requería una conversión de los archivos de datos. Estos sistemas se basaban en el modelo de red y el modelo jerárquico, los dos modelos lógicos que constituyeron la primera generación de los SGBD. El modelo relacional representa la segunda generación de los SGBD. 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. Estas tablas, pueden ser construidas de diversas maneras: Creando un conjunto de tablas iniciales y aplicar ciertas operaciones (normalización) hasta conseguir el esquema más óptimo. Convertir el diagrama MER a tablas y posteriormente aplicar también estas operaciones hasta conseguir el esquema óptimo. La primera técnica fue de las primeras en existir y, como es de suponerse, la segunda al ser más reciente es mucho más conveniente en varios aspectos: El partir de un diagrama visual es muy útil para apreciar los detalles, de ahí que se llame modelo conceptual. El crear las tablas iniciales es mucho más simple a través de las reglas de conversión (MER-Relacional). Se podría pensar que es lo mismo porque finalmente hay que aplicar operaciones (normalización) a las tablas de todas formas, pero la ventaja de partir del MER es que estas operaciones son mínimas por lo general. Lo anterior tiene otra ventaja: aún cuando se normalice de manera deficiente, se garantiza un esquema aceptable, lo que en la primera técnica no es así.
El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de los datos: Estructura de datos. Integridad de datos. Manejo de datos. Nos avocaremos por ahora al primer punto. A continuación se presenta un ejemplo de modelo relacional correspondiente a clientes de un banco y sus cuentas. Se puede apreciar la tabla cliente y los datos del mismo, así como la tabla cuenta y los datos de cada cuenta. Pero, se puede saber quién es el dueño de cada cuenta? O bien a quién le pertenece alguna de esas cuentas? Este diagrama está incompleto, ya que no hay como relacionar estas tablas. Se presenta a continuación el esquema que sí corresponde al problema referido:
Qué información se puede obtener? Claramente la información de cada cliente, la información de cada cuenta y se puede conocer a quien pertenece cada cuenta. Podría querer conocer por ejemplo el nombre y dirección de los clientes que mantienen saldos mayores a 500. Cómo se relacionan? A través de la tabla cliente-cuenta. Este esquema corresponde al MER que se encuentra a continuación. Como se mencionó, es posible obtenerlo directamente a partir del MER, como también generar las tablas partiendo de cero. Nótese que ambas cardinalidades son (1,N), lo que significa que los clientes de la base tienen una o más cuentas y que las cuentas de la base tienen uno o más clientes propietarios. id_cliente nombre_cliente calle_cliente ciudad_cliente Cliente (1,n) tiene (1,n) Cuenta número_cuenta saldo Estructura La relación es el elemento básico del modelo relacional y se representa por una tabla. Las tablas se representan gráficamente como una estructura rectangular formada por filas y columnas. Cada columna almacena información sobre una propiedad determinada de la tabla (atributo): nombre, carnet, apellidos, edad,... Cada fila posee una ocurrencia o ejemplar de la instancia o relación representada por la tabla (a las filas se las llama también tuplas). Elementos importantes: Relación Tupla Atributo Numero de tuplas Numero de atributos Dominio Clave primaria Tabla Fila Columna Cardinalidad Grado Colección de valores, de los cuales uno o más atributos obtienen sus valores reales. Identificador único para la tabla, es decir, una columna o combinación de columnas con la propiedad de que nunca existen 2 filas de la tabla con el mismo valor en esa columna o combinación de columnas.
Ejemplo Tabla (relación) Película título año duración Tipo Star Wars 1977 124 color Mighty Ducks 1991 104 color Wayne's World 1992 95 color Por ejemplo, la información de las oficinas de una empresa inmobiliaria se representa mediante la relación OFICINA, que tiene columnas para los atributos Onum (número de oficina), Calle, Area, Población, Teléfono y Fax. La información sobre el staff se representa mediante la relación PLANTILLA, que tiene columnas para los atributos Enum (número de empleado), Nombre, Apellido, Dirección, Teléfono, Puesto, Fecha_nac, Salario, DNI, Onum (número de la oficina a la que pertenece el empleado). A continuación se muestra una instancia de la relación OFICINA y una instancia de la relación PLANTILLA. Como se puede observar, cada columna contiene valores de un solo atributo. Por ejemplo, la columna Onum sólo contiene números de oficinas que existen. OFICINA 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
PLANTILLA Enum Nombre Apellido Dirección Teléfono Puesto Fecha_nac Salario DNI Onum EL21 Amelia Pastor Magallanes, 15 Castellón 964 284 560 Director 12/10/62 30000 39432212 O5 EG37 Pedro Cubedo Bayarri, 11 Villarreal 964 535 690 Superviso r 24/3/57 18000 38766623 O3 EG14 Luis Collado Borriol, 35 Villarreal 964 522 230 Administ. 9/5/70 12000 24391223 O3 EA9 Rita Renal Casalduch, 32 Castellón 964 257 550 Superviso r 19/5/60 18000 39233190 O7 EG5 Julio Prats Melilla, 23 Villarreal 964 524 590 Director 19/12/50 24000 25644309 O3 EL41 Carlos Baeza Herrero, 51 Castellón 964 247 250 Superviso r 29/2/67 18000 39552133 O5 Dominio Los dominios constituyen una poderosa característica del modelo relacional. Cada atributo de una base de datos relacional se define sobre un dominio, pudiendo haber varios atributos definidos sobre el mismo dominio. Permiten especificar los posibles valores válidos para uno o varios atributos. Un dominio D es un conjunto finito de valores homogéneos y atómicos caracterizados por un nombre. Homogéneo significa que los valores son todos del mismo tipo y atómicos significa que son indivisibles. Ejemplos de dominios serían: Colores: Es el conjunto de los colores D={rojo, verde, azul} Números de DNI: Es conjunto de números del DNI válidos (0-9), formados por ocho dígitos. Edad: Edades posibles de los empleados entre 18 y 80 años. Todo dominio ha de tener un nombre por el cual nos podamos referir a él. Por ejemplo el dominio "Nacionalidades" tiene valores: España, Francia, Chile, Argentina... Si descompusiéramos España en E,s,p,... perdería la semántica. (indivisible)
Cada domino debe tener también un tipo de datos; así el tipo de datos del dominio "nacionalidades" es un conjunto de caracteres de longitud 10. Se considera que los dominios no incluyen nulos, ya que nulo (null) no es un valor. La siguiente tabla muestra los dominios de los atributos de la relación OFICINA. Nótese que en esta relación hay dos atributos que están definidos sobre el mismo dominio: Teléfono y Fax. Atributo Nombre del Dominio Descripción Definición Onum NUM_OFICINA Posibles valores de número de oficina 3 digitos; rango O1-O99 Calle NOM_CALLE Nombres de calles de España 25 caracteres Area NOM_AREA Nombres de áreas de las poblaciones de España 20 caracteres Población NOM_POBLACION Nombres de las poblaciones de España 15 caracteres Teléfono NUM_TEL_FAX Números de teléfono de España 9 digitos Fax NUM_TEL_FAX Números de teléfono de España 9 dígitos Tipos de Datos Como se menciono, cada dominio debe definirse sobre algún tipo de dato, es decir cada atributo tendrá que estar definido de acuerdo a un tipo de datos. Veamos algunos: Entero (Integer) Números enteros sin parte decimal. Carácter (Char) Caracteres del código ASCII, de 0-255 Boleano (Boolean) Real Cadena (String) Pueden contener los valores de falso o verdadero Números que pueden incluir una parte decimal En una secuencia de caracteres que se trata como un solo dato. En relación a los datos numéricos, existen diversos tipos, que consideran rangos específicos que pueden abarcar. La elección de uno u otro dependerá del problema: el rango que alcanza el valor del atributo debe definir cual utilizar. Entero Tipo Rango de valores que acepta Integer (Entero) -32,768 a 32,767 Word (Palabra) 0 a 65535 ShortInt (Entero corto) -128 a 127
Byte 0 a 255 LongInt (Entero largo) -2,147,483,648 a 2,147,483,648 Real Tipo Rango de valores que acepta Real 2.9E-39 a 1.7E38 Single 1.5E-45 a 3.4E38 Double 5.0E-324 a 1.7E308 Extended 1.9E-4851 a 1.1E4932 Comp -9.2E18 a 9.2E18 Los tipos de datos a utilizar dependerán del SGBD que se utilice. Algunos manejan otro tipo de datos como Fecha/Hora: para introducir datos en formato fecha u hora Moneda :para introducir datos en formato número y con el signo monetario Autonumérico: se numera automáticamente el contenido Nulos Un nulo no representa el valor cero ni la cadena vacía; éstos son valores que tienen significado. El nulo implica ausencia de información. Se puede definir el valor nulo como una marca utilizada para representar información desconocida. La necesidad de valores nulos es evidente por diversas razones: Existencia de tuplas con ciertos atributos desconocidos en ese momento. Necesidad de añadir un nuevo atributo a una tabla ya existente; atributo que en el momento de introducirse no tendrá ningún valor para las tuplas de la relación. Posibilidad de atributos inaplicables a ciertas tuplas, como la editorial para un artículo. En claves foráneas indican que el registro actual no está relacionado con ninguna tabla. Ya que los nulos no son valores, deben tratarse de modo diferente, lo que puede causar problemas de implementación.
Atributo Un atributo A es el papel que tiene un determinado dominio en una relación. D es el dominio de A y se denota dom(a). Es muy usual dar el mismo nombre al atributo y al dominio. En el caso de que sean varios los atributos de una misma tabla definidos sobre el mismo dominio, habrá que darles nombres distintos, ya que una tabla no puede tener dos atributos con el mismo nombre. Por ejemplo los atributos edad_física y edad_mental pueden estar definidos sobre el mismo dominio edad; o los atributos precio_compra y precio_venta pueden estar definidos sobre el mismo dominio precio, enteros de longitud 5 mayores que 0. Relación Una relación R sobre un conjunto de valores D 1, D 2, D n se compone de 2 partes: una cabecera y un cuerpo. La cabecera esta formada por un conjunto de atributos. Cada atributo corresponde a un único dominio, y todos los atributos son distintos, es decir, no hay dos atributos que se llamen igual. El cuerpo esta formado por un conjunto de tuplas que varía en el tiempo. Cada tupla es un conjunto de pares atributo:valor: La cantidad de atributos se le conoce como grado y la cantidad de tuplas se le conoce como cardinalidad. La relación OFICINA tiene la siguiente cabecera: { (Onum:NUM_OFICINA), (Calle:NOM_CALLE), (Area:NOM_AREA), (Población:NOM_POBLACION),(Teléfono:NUM_TEL_FAX), Fax:NUM_TEL_FAX)}. Siendo la siguiente una de sus tuplas: { (Onum:O5), (Calle:Enmedio,8), (Area:Centro), (Población:Castellón), (Teléfono:964 201 240), (Fax:964 201 340)}.
Claves Una clave candidata de una relación R es un conjunto no vacío de atributos que identifican univoca y mínimamente a una tupla. Toda relación siempre tendrá una clave candidata. Clave primaria: es aquella clave candidata que el usuario escogerá, por consideraciones ajenas al modelo relacional, para identificar a las tuplas de una relación. Clave alternativa: son aquellas claves candidatas que no han sido elegidas como primarias. Clave ajena o foránea de una relación R2 es un conjunto no vacío de atributos cuyos valores han de coincidir con los valores de la clave primaria de otra relación R1. La clave foránea y la correspondiente clave primaria han de estar definidas sobre los mismos dominios. Ningún componente de la clave primaria de una relación puede en algún momento no tener valor (aceptar nulos); no tiene sentido modelar una entidad que no podemos identificar ni distinguir una de otra.
Transformación MER-Relacional Se transformara el esquema conceptual (MER) obtenido en la fase anterior a un esquema relacional. Este esquema sigue siendo independiente del SGBD a ser utilizado en la siguiente etapa. El paso del esquema MER al relacional se basa en los siguientes principios: 1. Todo tipo de entidad se convierte en relación. Cada entidad del esquema MER dará lugar a una nueva relación cuya clave primaria es el identificador principal de la entidad. Identificador principal: atributo(s) que forman la clave primaria de la nueva relación. Se deben subrayar en la relación. Cada atributo de una entidad se transforma en un atributo de la relación creada para la entidad. Tomar en cuenta: Atributos obligatorios: atributos que deben contar con un valor en la tabla, no debe aceptar valores nulos. (restricción NOT NULL.) Atributos opcionales: atributos que pueden tomar valores nulos (no se conoce el valor, etc) Identificador alternativo: atributo alternativo en la entidad que debe ser único en la relación (restricción UNIQUE). Atributos monovaluados: dan lugar a un atributo de la relación. id_cliente nombre_cliente calle_cliente ciudad_cliente Cliente La relación sería la siguiente: Cliente (id_cliente, nombre_cliente, calle_cliente, ciudad_cliente) PK: id_cliente (PK: primary key->clave primaria) Atributos multivaluados: dan lugar a una nueva relación cuya clave primaria es la concatenación de la clave primaria de la entidad en la que se sitúa el atributo multivaluado mas el nombre del atributo multivaluado.
id_cliente nombre_cliente direccion_cliente telefono_cliente Cliente Cliente (id_cliente, nombre_cliente, direccion_cliente) PK: id_cliente Teléfonos_cliente (id_cliente, telefono_cliente) PK: id_cliente, telefono_cliente; FK: id_cliente referencia a Cliente. FK: foreign key->clave foranea) Atributos compuestos: se pueden transformar según las siguientes alternativas: a. Eliminar el atributo compuesto considerando todos sus componentes como atributos individuales. calle numero ciudad id_cliente nombre_cliente direccion_cliente telefono_cliente Cliente Cliente (id_cliente, nombre_cliente, calle, numero, ciudad, telefono_cliente) PK: id_cliente b. eliminar los componentes individuales y considerar el atributo compuesto entero como un sólo atributo. Cliente (id_cliente, nombre_cliente, direccion_cliente, telefono_cliente) PK: id_cliente Atributos derivados: atributos que se obtienen como resultado de un calculo sobre otros atributos. No existe para los atributos derivados una representación directa y concreta en el modelo relacional y sus SGBD. En este caso, los atributos se tratan de la forma usual. Se calcula el valor del atributo derivado cada vez que se inserten o borren las ocurrencias de los atributos que intervienen en el cálculo de este. Para esto se implementan los procedimientos del caso y se añaden las restricciones correspondientes. Atributos de Interrelaciones Si la interrelación se transforma en una relación, todos sus atributos pasan a ser columnas de la relación. En caso de que la relación se transforme mediante propagación de clave, sus atributos migran junto con la clave a la relación que corresponda, aunque puede ser mejor crear una nueva relación para representar una interrelación que tiene atributos.
Dependencia por existencia. Una interrelación 1:N de dependencia en existencia origina una propagación de clave desde la relación que representa a la entidad fuerte a la relación que representa a la entidad débil. No puede existir ninguna ocurrencia de la entidad hijo (débil) que no este relacionada con una ocurrencia de la entidad padre (fuerte). codigo_edificio direccion_edificio Edificio (1,1) E tiene (1,n) Planta codigo_planta numero_habitaciones Edificio (codigo_edificio, direccion_edificio) PK: codigo_edificio Planta (codigo_planta, numero_habitaciones, codigo_edificio) PK: codigo_planta FK: codigo_edificio referencia a Edificio. Dependencia por identidad. Una interrelación 1:N de dependencia en identificación da lugar a una propagación de clave desde la relación que representa a la entidad fuerte a la relación que representa a la entidad débil, de tal forma que la entidad débil requiere de la clave de la entidad fuerte para su identificación. La clave de la relación que representa a la entidad débil queda formada por la concatenación de la clave foránea y la clave de la entidad débil. Có d igo No mb re Nr_hojas Editorial Libro (1,1) I ti ene (1,N) Ejemplar Númer o Estado Posición Libro (codigo, nombre, nr_hojas, editorial) PK: codigo Ejemplar (codigo, numero, estado, posición) PK: codigo, numero FK: codigo referencia a Libro. 2. Todo tipo de interrelación N:M se transforma en relación. Las interrelaciones N:M dan lugar a una nueva relación cuya clave serán las claves primarias de las entidades que enlaza la interrelación. De esta forma los atributos que forman la clave primaria de esta nueva relación son claves foráneas respecto a las tablas en donde son claves primarias.
id_cliente nombre_cliente calle_cliente ciudad_cliente Cliente (1,n) tiene (1,n) Cuenta número_cuenta saldo Cliente (id_cliente, nombre_cliente, calle_cliente, ciudad_cliente) PK: id_cliente Cuenta (numero_cuenta, saldo) PK: numero_cuenta Tiene (id_cliente, numero_cuenta) PK. Id_cliente, numero_cuenta FK: id_cliente referencia a Cliente, numero_cuenta referencia a Cuenta. Si la interrelación tiene atributos, estos pasaran a formar parte de la relación creada para la interrelación. id_cliente nombre_cliente calle_cliente ciudad_cliente Cliente (1,n) tiene privilegio (1,n) Cuenta número_cuenta saldo Cliente (id_cliente, nombre_cliente, calle_cliente, ciudad_cliente) PK: id_cliente Cuenta (numero_cuenta, saldo) PK: numero_cuenta Tiene (id_cliente, numero_cuenta, privilegio) PK. Id_cliente, numero_cuenta FK: id_cliente referencia a Cliente, numero_cuenta referencia a Cuenta. 3. Todo tipo de interrelación 1:N se traduce en el fenómeno de propagación de la clave. Se propaga la clave primaria de la entidad que se encuentra en el lado 1 a la entidad que se encuentra en el lado N. Si existen atributos en la interrelación, estos también se propagaran. nombre_ciudad habitantes_ciudad Ciudad (1,n) (1,1) esta Region numero_region nombre_region habitantes_region Region (numero_region, nombre_region, habitantes_region) PK: numero_region Ciudad (nombre_ciudad, habitantes_ciudad, numero_region) PK: nombre_ciudad, FK: numero_region referencia a Region. fecha código nombre direccion Proveedor (1,1) (1,n) suministra Producto código nombre precio_unitario
Proveedor (codigo, nombre, direccion) PK: codigo Vendedor (codigo, nombre, precio_unitario, codigo_prov, fecha) PK: codigo, FK: codigo_prov referencia a Proveedor Un aspecto importante en estas interrelaciones tiene que ver con las cardinalidades mínimas. Si la cardinalidad mínima de la entidad que se propaga es 1, significa que no pueden admitirse valores nulos en la clave foránea (clave propagada). En cambio, si es 0, si se admiten valores nulos. Si en la parte de cardinalidad minima hay una participación parcial: tasa_descuento numero_pedido fecha Pedido (1,n) (0,1) suministra Vendedor nombre_vendedor fono Se podrían generar las siguientes tablas: Vendedor (nombre_vendedor, fono_vendedor) PK: nombre_vendedor Pedido (numero_pedido, fecha, tasa_descuento, nombre_vendedor) PK: numero_pedido, FK: nombre_vendedor referencia a Vendedor En este caso puede ocurrir que tasa_descuento y nombre_vendedor tomen valores nulos. Si el número relativo de esos pedidos es grande, y no se puede admitir valores nulos, una mejor alternativa sería establecer tres relaciones (lo cual es el caso más general): Se crea una nueva relación para la interrelación cuyo tratamiento seria igual que el de las interrelaciones N:M con la salvedad de que la clave primaria de la nueva relación constara de la clave primaria de la entidad que se encuentra en el lado N de la interrelación. Vendedor (nombre_vendedor, fono_vendedor) PK: nombre_vendedor Pedido (numero_pedido, fecha) PK: numero_pedido Pedido_Ventas (numero_pedido, nombre_vendedor, tasa_descuento) PK: numero_pedido, FK: numero_pedido referencia a Pedido, nombre_vendedor referencia a Vendedor
Si en la parte de cardinalidad maxima hay una participación parcial se necesitan tres tablas: una para representar cada entidad y una para representar la relación. patente_auto marca_auto Auto (0,n) (1,1) es_prop Persona CI_persona nombre_persona direccion_persona Auto (patente_auto, marca_auto) PK: patente_auto Persona (CI_persona, nombre_persona, direccion_persona) PK CI_persona Auto_persona (CI_persona, patente_auto) PK: patente_auto, CI_persona, FK: PK: patente_auto referencia a Auto, CI_persona referencia a Persona Se podría propagar también la clave de la entidad que tiene la cardinalidad minima a la que tiene máximo N: Auto (patente_auto, marca_auto, CI_persona) PK: patente_auto, FK CI_persona referencia a Persona Persona (CI_persona, nombre_persona, direccion_persona) PK CI_persona 4. Interrelaciones 1:1 Son casos en donde se puede crear una relación o bien propagar la clave. Esto último puede ser en ambas direcciones: a) Si la relación es del tipo 1:1 y es obligatorio (total) tipo de participación de ambas entidades, cada entidad se transforma en una tabla con clave principal el identificador de la entidad correspondiente y cada tabla tendrá como clave ajena el identificador de la otra tabla con la cual está relacionada. codigo_empresa direccion_empresa Empresa (1,1) (1,1) tiene Director CI_director nombre Empresa (codigo_empresa, direccion_empresa, CI_director) PK codigo_empresa, FK CI_director referencia a Director Director (CI_director, nombre, codigo_empresa) PK CI_director, FK codigo_empresa referencia a Empresa b) Una de las entidades tiene cardinalidad (0,1) y la otra (1,1), conviene propagar la clave de la entidad con cardinalidad (1,1) a la tabla resultante de la entidad de cardinalidad (0,1). Esta clave foránea no debe aceptar valores nulos.
codigo_empleado nombre_empleado Empleado (1,1) responsabl (0,1) e Depto codigo_depto nombre_depto Empleado (codigo_empleado, nombre_empleado) PK: codigo_empleado Depto (codigo_depto, nombre_depto, codigo_empleado) PK: codigo_depto, FK: codigo_empleado referencia a Empleado. c) Si las entidades que se asocian tienen ambas cardinalidades (0,1) entonces es necesario generar tres tablas, una para cada entidad y otra para la relación que deberá contener como atributos las claves primarias de las entidades que participan en la relación. Asi se evitan los valores nulos que aparecerian en caso de propagar una de las claves primarias. No todas las personas tienen animales, en el ejemplo. CI_persona nombre_persona Persona fecha (0,1) (0,1) posee Animal codigo_animal nombre_animal Persona (codigo_persona, nombre_persona) PK: codigo_persona Animal (codigo_animal, nombre_animal) PK: codigo_animal Persona_Animal (codigo_persona, codigo_animal, fecha) PK: codigo_persona, codigo_animal FK: codigo_persona referencia a Persona, codigo_animal referencia a Animal. 5. Relaciones reflexivas Para transformar una relación reflexiva al modelo relacional, se debe suponer que se trata de una relación binaria con la particularidad que las dos entidades son iguales y aplicar las reglas vistas. CI_persona nombre_persona (1,n) Persona (1,1) apadrina Persona (CI_persona, nombre_persona, CI_o_persona) PK: CI_persona FK: CI_o_persona referencia a Persona En este caso la clave foránea no puede aceptar nulos (todas las personas tienen un padrino). Todas las personas de la base son padrinos de al menos una persona.
El siguiente caso es igual que el anterior, con la diferencia que la clave foránea si puede aceptar nulos (una persona puede o no tener padrino). CI_persona nombre_persona (1,n) Persona (0,1) apadrina Los mismos esquemas se darán para los siguientes casos. Aquí la diferencia es que una persona de la base puede no aparecer como padrino de alguien (0,n). (No todas las personas de la base son padrinos) CI_persona nombre_persona (0,n) Persona (1,1) apadrina En el siguiente caso una persona de la base puede no aparecer como padrino y una persona puede no tener padrino, por lo que debe aceptar valor nulo en la clave foránea. CI_persona nombre_persona (0,n) Persona (0,1) apadrina Una persona apadrina a una persona y una persona es apadrinada por solo una persona. CI_persona nombre_persona (1,1) Persona (1,1) apadrina Persona (CI_persona, nombre_persona, CI_o_persona) PK: CI_persona FK: CI_o_persona referencia a Persona No se deben aceptar valores nulos. Todas las personas son padrinos de una persona. Si persona apadrina a (0,1) persona y persona puede ser apadrinado por solo una persona el esquema es el mismo. Si una persona apadrina a una sola persona, y una
persona puede apadrinar o no (0,1) se deben aceptar valores nulos en la clave foránea. Lo mismo pasa en el caso en que la cardinalidad sea (0,1) en ambos lados. Casos N:M Se tendria una tabla por entidad persona, y una tabla representando la relación apadrina : Persona (CI_persona, nombre_persona) PK: CI_persona Apadrina (CI_persona, CI_o_persona) PK: CI_persona, CI_o_persona FK: CI_persona, CI_o_persona referencia a Persona 6. Generalizaciones Las generalizaciones no son objetos que puedan representarse directamente en el modelo relacional. Ante una entidad y sus subtipos caben varias soluciones de transformación, con la consiguiente pérdida de semántica dependiendo de la estrategia elegida, las cuales son 3: a. Integrar la jerarquía de generalización en una sola entidad uniendo los atributos de las subentidades y añadiendo estos atributos a los de la superentidad. Se añade un atributo discriminativo para indicar el caso al cual pertenece la entidad en consideración. Esta alternativa es aplicable a todos los casos, con todas las coberturas, teniendo el problema de tener que manejar en algunos casos demasiados valores nulos y que las operaciones que sólo actuaban sobre una subentidad tendrán que buscar ahora los casos correspondientes dentro del conjunto completo de casos. matricula_estudiante nombre_estudiante carrera titulo_tesis Estudiante (matricula_estudiante, nombre_estudiante, carrera, titulo_tesis, tipo) PK: matricula_estudiante b. Eliminar la superentidad reteniendo las subentidades. Aquí los atributos heredados deben propagarse entre las subentidades. Esta alternativa no es práctica para
generalizaciones superpuestas o parciales; sólo lo es para jerarquías totales y exclusivas. Además, si el número de atributos de la superentidad (comunes a toda las subentidades) es excesivo, su duplicación en el esquema de cada subentidad no se justifica. rut_empleado nombre_empleado especialidad nr_supervisados Ingeniero (rut_empleado, nombre_empleado, especialidad) PK: rut_empleado Gerente (rut_empleado, nombre_empleado, nr_supervisados) PK: rut_empleado c. Retener todas las entidades y establecer explícitamente las interrelaciones entre la superentidad y las subentidades. Esta alternativa se puede considerar como la más general de las tres, ya que siempre es posible. Las desventajas de este enfoque son que el esquema resultante es bastante complejo y hay una redundancia inherente al representar cada eslabón ES-UN en la jerarquía original a través de una relación explícita. Las ventajas, por otra parte, son que modela todos los casos, lo que la hace más flexible ante cambios de requerimientos, y es conveniente si la mayoría de las operaciones son estrictamente locales respecto a la superentidad o a una de las subentidades. nr_proyecto nombre_proyecto nr_modulos contratista principal Proyecto (nr_proyecto, nombre_proyecto) PK: nr_proyecto Desarrollo_Sw (nr_proyecto, nr_módulos) PK: nr_proyecto FK: nr_proyecto referencia a Proyecto Subcontrato (nr_proyecto, contratista_principal) PK: nr_proyecto FK: nr_proyecto referencia a Proyecto
Esquema de una base de datos relacional Una base de datos relacional es un conjunto de relaciones normalizadas. 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 claves primarias y las claves ajenas. El esquema de la base de datos de la empresa inmobiliaria es el siguiente: OFICINA PLANTILLA INMUEBLE INQUILINO PROPIETARIO VISITA (Onum, Calle, Area, Población, Teléfono, Fax) (Enum, Nombre, Apellido, Dirección, Teléfono, Puesto, Fecha_nac, Salario, DNI, Onum) (Inum, Calle, Area, Población, Tipo, Hab, Alquiler, Pnum, Enum, Onum) (Qnum, Nombre, Apellido, Dirección, Teléfono, Tipo_pref, Alquiler_max) (Pnum, Nombre, Apellido, Dirección, Teléfono) (Qnum, Inum, Fecha, Comentario) En el esquema, los nombres de las relaciones aparecen seguidos de los nombres de los atributos encerrados entre paréntesis. Las claves primarias son los atributos subrayados. Las claves ajenas se representan mediante los siguientes diagramas referenciales. PLANTILLA OFICINA : Oficina a la que pertenece el empleado. INMUEBLE PROPIETARIO : Propietario del inmueble. INMUEBLE PLANTILLA : Empleado encargado del inmueble. INMUEBLE OFICINA : Oficina a la que pertenece el inmueble. VISITA INQUILINO : Inquilino que ha visitado el inmueble. VISITA INMUEBLE : Inmueble que ha sido visitado. A continuación se muestra un estado (instancia) de la base de datos cuyo esquema se acaba de definir.
OFICINA 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 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 Castellón EG37 Pedro Cubedo Bayarri, 11 964 535 690 Supervisor 24/3/57 18000 38766623X O3 Villarreal EG14 Luis Collado Borriol, 35 964 522 230 Administ. 9/5/70 12000 24391223L O3 Villarreal EA9 Rita Renau Casalduch, 32 964 257 550 Supervisor 19/5/60 18000 39233190F O7 Castellón EG5 Julio Prats Melilla, 23 964 524 590 Director 19/12/50 24000 25644309X O3 Villarreal EL41 Carlos Baeza Herrero, 51 964 247 250 Supervisor 29/2/67 18000 39552133T O5 Castellón INMUEBLE 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
PROPIETARIO Pnum Nombre Apellido Dirección Teléfono P46 Amparo Felip Asensi 24, Castellón 964 230 680 P87 Manuel Obiol Av. Libertad 15, Vinaroz 964 450 760 P40 Alberto Estrada Av. del Puerto 52, Castellón 964 200 740 P93 Yolanda Robles Purísima 4, Segorbe 964 710 430 INQUILINO Qnum Nombre Apellido Dirección Teléfono Tipo Alquiler Q76 Juan Felip Barceló 47, Castellón 964 282 540 Piso 375 Q56 Ana Grangel San Rafael 45, Almazora 964 551 110 Piso 300 Q74 Elena Abaso Navarra 76, Castellón 964 205 560 Casa 700 Q62 Alicia Mori Alloza 45, Castellón 964 229 580 Piso 550 VISITA 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 Q56 IG36 28/10/99