INSTITUTO TECNOLOGICO SUPERIOR DE MACUSPA NA

INGENIERIA EN SISTEMAS COMPUTACIONALES

UNIDAD V DISEO DE B.D RELACIONAL

ING. RICARDO ANTONIO SERAGIN

EDY BAEZA RODRIGUEZ

4TO SEMESTRE T/V

16/05/11

FUNDAMENTOS DE BASE DE DATOS

Pgina 1

INDICE

UNIDAD V DISEO DE BASE DE DATOS RELACIONAL

OBJETIVO_______________________________________ 3

5.1 DISEO DE B.D.R DE BASE DE DATOS____________4

5.2 MODELO E.R Y LA NORMALIZACION______________5

5.3 RELACION DE UN ESQUEMA E.R A TABLA________15

BIBLIOGRAFIA___________________________________17

FUNDAMENTOS DE BASE DE DATOS

Pgina 2

OBJETIVO

El objetivo del diseo de una base de datos relacional es generar un conjunto de esquemas de relaciones que permitan almacenar la informacin con un mnimo de redundancia, pero que a la vez faciliten la recuperacin de la informacin. Una de las tcnicas para lograrlo consiste en disear esquemas que tengan una forma normal adecuada. Para determinar si un esquema de relaciones tiene una de las formas normales se requiere mayor informacin sobre la empresa del "mundo real" que se intenta modelar con la base de datos. La informacin adicional la proporciona una serie de limitantes que se denominan dependencias de los datos.

FUNDAMENTOS DE BASE DE DATOS

Pgina 3

5.1 DISEO DE BASE DE DATOS RELACIONAL DE B.D

El primer paso para crear una base de datos, es planificar el tipo de informacin que se quiere almacenar en la misma, teniendo en cuenta dos aspectos: la informacin disponible y la informacin que necesitamos. La planificacin de la estructura de la base de datos, en particular de las tablas, es vital para la gestin efectiva de la misma. El diseo de la estructura de una tabla consiste en una descripcin de cada uno de los campos que componen el registro y los valores o datos que contendr cada uno de esos campos. Los campos son los distintos tipos de datos que componen la tabla, por ejemplo: nombre, apellido, domicilio. La definicin de un campo requiere: el nombre del campo, el tipo de campo, el ancho del campo, etc. Los registros constituyen la informacin que va contenida en los campos de la tabla, por ejemplo: el nombre del paciente, el apellido del paciente y la direccin de este. Generalmente los diferente tispos de campos que su pueden almacenar son los siguientes: Texto (caracteres), Numrico (nmeros), Fecha / Hora, Lgico (informaciones lgicas si/no, verdadero/falso, etc., imgenes. En resumen, el principal aspecto a tener en cuenta durante el diseo de una tabla es determinar claramente los campos necesarios, definirlos en forma adecuada con un nombre especificando su tipo y su longitud

FUNDAMENTOS DE BASE DE DATOS

Pgina 4

5.2 MODELO DE E-R Y LA NORMALIZACION Los diagramas o modelos entidad-relacin (a veces denominado por su siglas, E-R Entity relationship) son una herramienta para el modelado de datos de un sistema de informacin. Estos modelos expresan entidades relevantes para un sistema de informacin, sus inter-relaciones y propiedades. Es una representacin lgica de la informacin. Mediante una serie de procedimientos se puede pasar del modelo E-R a otros, como por ejemplo el modelo relacional. El modelado entidad-relacin es una tcnica para el modelado de datos utilizando diagramas entidad relacin. No es la nica tcnica pero s la ms utilizada. Brevemente consiste en los siguientes pasos: 1. Se parte de una descripcin textual del problema o sistema de informacin a automatizar (los requisitos). 2. Se hace una lista de los sustantivos y verbos que aparecen. 3. Los sustantivos son posibles entidades o atributos. 4. Los verbos son posibles relaciones. 5. Analizando las frases se determina la cardinalidad de las relaciones y otros detalles. 6. Se elabora el diagrama (o diagramas) entidad-relacin. 7. Se completa el modelo con listas de atributos y una descripcin de otras restricciones que no se pueden reflejar en el diagrama. Dado lo rudimentario de esta tcnica se necesita cierto entrenamiento y experiencia para lograr buenos modelos de datos. El modelado de datos no acaba con el uso de esta tcnica. Son necesarias otras tcnicas para lograr un modelo directamente implementable en una base de datos. Brevemente: Transformacin de relaciones mltiples en binarias.

Normalizacin de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa). Conversin en tablas en caso de utilizar una base de datos relacional. Etc.

FUNDAMENTOS DE BASE DE DATOS

Pgina 5

Formalmente, los diagramas E-R son un lenguaje grfico para describir conceptos. Informalmente, son simples dibujos o grficos que describen la informacin que trata un sistema de informacin y el software que lo automatiza. Los elementos de dicho lenguaje se describen a continuacin, por orden de importancia.

Una entidad es cualquier objeto discreto sobre el que se tiene informacin. Se representa mediante un rectngulo o caja etiquetada en su interior mediante un nombre. Ejemplos de entidades habituales en los sistemas de informacin son: factura, persona, empleado, etc. Cada ejemplar de una entidad se denomina instancia.Por ejemplo,carlos ch y doris ar pueden ser dos instancias distintas de la entidad persona. Las instancias no se representan en el diagrama. No obstante, se pueden documentar aparte porque son tiles para inicializar la base de datos resultante. Por ejemplo, los departamentos existentes de una empresa pueden ser relevantes como datos iniciales de la entidad departamento.

Una relacin describe cierta interdependencia (de cualquier tipo) entre entidades. Se representa mediante un rombo etiquetado en su interior mediante un verbo. Adems, dicho rombo debe unirse mediante lneas con las entidades que relaciona (es decir, los rectngulos). Una relacin no tiene sentido sin las entidades que relaciona. Por ejemplo: una persona (entidad) trabaja (relacin) para un departamento (entidad). Modelo Er http://danielfigueroa11.googlepages.com/1.swf :) (entidad-relacin)(:flash

Los atributos son propiedades relevantes propias de una entidad y/o relacion. Se representan mediante un crculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta. Por motivos de legibilidad, los atributos no suelen representarse en un diagrama entidad-relacin, sino que se describen textualmente en otros documentos adjuntos.

FUNDAMENTOS DE BASE DE DATOS

Pgina 6

Los atributos describen informacin til sobre las entidades. En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un empleado de otro es su nmero de la Seguridad Social. Ejemplos de atributos de la entidad persona: Documento Nacional de Identidad (identificativo). Nombre. Apellidos. Direccin. Cdigo postal.

Los diagramas Entidad-Relacin no cumplen su propsito con eficacia debido a que tienen limitaciones semnticas. Por ese motivo se suelen utilizar los diagramas Entidad-Relacin extendidos que incorporan algunos elementos ms al lenguaje:

Cuando una entidad participa en una relacin puede adquirir un papel fuerte o dbil. Una entidad dbil es aquella que no puede existir sin participar en la relacin, es decir, aquella que no puede ser unvocamente identificada solamente por sus atributos. Una entidad fuerte es aquella que s puede ser identificada unvocamente. En los casos en que se requiera, se puede dar que una entidad fuerte preste algunos de sus atributos a una entidad dbil para que, esta ultima, se pueda identificar. Las entidades dbiles se representan mediante un doble rectngulo, es decir, un rectngulo con doble lnea.

Las relaciones, en principio binarias, pueden involucrar a un nmero distinto de instancias de cada entidad. As, son posibles tres tipos de cardinalidades: Relaciones de uno a uno: una instancia de la entidad A se relaciona con una y solamente una de la entidad B. Relaciones de uno a muchos: cada instancia de la entidad A se relaciona con varias instancias de la entidad B. Relaciones de muchos a muchos: cualquier instancia dela entidad A se relaciona con cualquier instancia de la entidad B.
FUNDAMENTOS DE BASE DE DATOS Pgina 7

El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relacin, respectivamente: 1:1, 1:N y N:M, aunque la notacin depende del lenguaje utilizado, la que ms se usa actualmente es el unificado. Otra forma de expresar la cardinalidad es situando un smbolo cerca de la lnea que conecta una entidad con una relacin: si la entidad no est obligada a participar en la relacin.

1 si la entidad est obligada a participar en la relacin y adems, cada instancia solamente participa una vez. N , M, * si la entidad no est obligada a participar en la relacin y cada instancia puede participar cualquier nmero de veces. Ejemplos de relaciones que expresan cardinalidad: Una factura (entidad) se emite (relacin) a una persona (entidad) y slo una, pero una persona puede tener varias facturas emitidas a su nombre. Es una relacin 1:N. Un cliente (entidad) puede comprar (relacin) varios artculos (entidad) y un artculo puede ser comprado por varios clientes distintos. Es una relacin N:M.

Las relaciones tambin pueden tener atributos asociados. Se representan igual que los atributos de las entidades. Un ejemplo tpico son las relaciones de tipo histrico donde debe constar una fecha o una hora. Por ejemplo, supongamos que es necesario hacer constar la fecha de emisin de una factura a un cliente, y que es posible emitir duplicados de la factura (con distinta fecha). En tal caso, el atributo Fecha de emisin de la factura debera colocarse en la relacin se emite.

La herencia es un intento de adaptacin de estos diagramas al paradigma orientado a objetos. La herencia es un tipo de relacin entre una entidad padre y una entidad hijo. La entidad hijo hereda todos los atributos y relaciones de la entidad padre. Por tanto, no necesitan ser representadas dos veces en el diagrama. La relacin de herencia se representa mediante un tringulo interconectado por lneas a las entidades. La entidad conectada por el vrtice superior del tringulo es la entidad padre. Solamente puede existir una entidad padre (herencia simple). Las entidades hijo se conectan por la base del tringulo.

FUNDAMENTOS DE BASE DE DATOS

Pgina 8

(:includeurl http://docs.google.com/TeamPresent?fs=true&docid=dd7r732g_1fqzm6k&skipa uth=true :)

El proceso de normalizacin de una base de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo E-R (entidadrelacin) al modelo relacional. Las bases de datos relacionales se normalizan para: Evitar la redundancia de los datos. Evitar problemas de actualizacin de los datos en las tablas. Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relacin, aunque para que una tabla bidimensional sea considerada como una relacin tiene que cumplir con algunas restricciones: Cada columna debe tener su nombre nico. No puede haber dos filas iguales. No se permiten los duplicados. Todos los datos en una columna deben ser del mismo tipo.

entidad = tabla o archivo tupla = registro, fila o rengln atributo = campo o columna base de datos = banco de datos dependencia multivaluada = dependencia multivalor clave = llave clave primaria = superclave clave ajena = clave externa o clave fornea

RDBMS = Del ingls Relational Data Base Manager System que significa, Sistema Gestor de Bases de Datos Relacionales. 1FN = Significa, Primera Forma Normal aunque en diferentes articulos puede que lo encontremos como 1NF que viene del ingles First Normal Form.
FUNDAMENTOS DE BASE DE DATOS Pgina 9

Una dependencia funcional son conexiones entre uno o ms atributos. Por ejemplo si conocemos el valor de Fecha De Nacimiento podemos conocer el valor de Edad. Las dependencias funcionales se escriben utilizando una flecha, de la siguiente manera: Fecha De NacimientoEdad Aqu a Fecha De Nacimiento se le conoce como un determinante. Se puede leer de dos formas Fecha De Nacimiento determina a Edad o Edad es funcionalmente dependiente de Fecha De Nacimiento. De la normalizacin (lgica) a la implementacin (fsica o real) puede ser sugerible tener stas dependencias funcionales para lograr mayor eficiencia en las tablas. transitiva ID_Estudiante Curso_Tomando Curso_Tomando Profesor_Asignado ID_Estudiante Curso_Tomando Profesor_Asignado Entonces tenemos que ID_Estudiante determina a Curso_Tomando y el Curso_Tomando determina a Profesor_Asignado, indirectamente podemos saber a travs del ID_estudiante el Profesor_Asignado.

Clave candidata Este registro de cada entrada en la tabla es imprescindible. Indicar de forma unvoca la identidad de la entrada a la que representa. Es habitual usar un nmero que se incrementa con cada insercin, o autonumrico. Puede haber ms de una clave candidata en una tabla. Slo una de ellas actuar como clave primaria. Clave alternativa Son aquellas claves candidatas que no han sido seleccionadas como clave primaria. Clave simple Es una clave que est compuesta de un solo atributo, pero que est aparte en un sistema. Clave compuesta Es una clave que est compuesta por ms de un atributo. View Album Get your own

FUNDAMENTOS DE BASE DE DATOS

Pgina 10

En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayora de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd, ste introdujo la normalizacin en un artculo llamado A Relational Model of Data for Large Shared Data Banks.. Primera Forma Normal (1FN) Una relacin est en Primera Forma Normal si y slo si todos los atributos son atmicos. Un atributo es atmico si los elementos del dominio son indivisibles, mnimos. Por ejemplo La Relacin: cursos: nombre, cdigo, vacantes, horario, bibliografa

Queda despus de aplicar la Forma Normal 1 de la siguiente manera: cursos1: nombre, cdigo, vacantes horario1: cdigo, da, mdulo bibliografia1: cdigo, nombre, autor

Una columna no puede tener multiples valores. Los datos son atmicos. (Si a cada valor de X le pertenece un valor de Y, entonces a cada valor de Y le pertenece un valor de X). Segunda Forma Normal (2FN) Dependencia completa. Una relacin est en 2FN si est en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependecias parciales. Los atributos dependen de la clave. Vara la clave y varan los atributos. En Otras palabras pudisemos decir que la segunda forma normal est basada en el concepto de dependencia completamente funcional. Una dependencia funcional X Y es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que A X, (X ) -x Y. Una dependencia funcional X Y es una dependencia parcial si hay algunos atributos A X que pueden ser removidos de X y la dependencia todava se mantiene, esto es A X, (X ) Y . Por ejemplo {SSN,PNUMBER} HOURS es completamente dependencia dado que ni SSN HOURS ni PNUMBER HOURS mantienen la dependencia. Sin embargo {SSN,PNUMBER} ENAME es parcialmente dependiente dado que SSNENAME mantiene la dependencia Tercera Forma Normal (3FN) La tabla se encuentra en 3FN si es 2FN y cada atributo que no forma parte de ninguna clave, depende directamente y no transitivamente, de la clave primaria.
FUNDAMENTOS DE BASE DE DATOS Pgina 11

Un ejemplo de este concepto sera que, una dependencia funcional XY en un esquema de relacin R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene XZ y ZY.. Por ejemplo, la dependencia SSNDMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva via DNUMBER porque las dependencias SSNDNUMBER y DNUMBERDMGRSSN son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT. Forma Normal de Boyce-Codd (FNBC) La tabla se encuentra en BCNF si cada determinante, atributo que determina completamente a otro, es clave candidata.

Codd se percat de que existan bases de datos en el mercado las cuales decan ser relacionales, pero lo nico que hacan era guardar la informacin en las tablas, sin estar estas tablas literalmente normalizadas; entonces ste public 12 reglas que un verdadero sistema relacional debera tener, en la prctica algunas de ellas son difciles de realizar. Un sistema podr considerarse ms relacional cuanto ms siga estas reglas. Regla No. 1 - La Regla de la informacin Toda la informacin en un RDBMS est explcitamente representada de una sola manera por valores en una tabla. Cualquier cosa que no exista en una tabla no existe del todo. Toda la informacin, incluyendo nombres de tablas, nombres de vistas, nombres de columnas, y los datos de las columnas deben estar almacenados en tablas dentro de las bases de datos. Las tablas que contienen tal informacin constituyen el Diccionario de Datos. Regla No. 2 - La regla del acceso garantizado Cada tem de datos debe ser lgicamente accesible al ejecutar una bsqueda que combine el nombre de la tabla, su clave primaria, y el nombre de la columna. Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y dado el nombre de la columna requerida, deber encontrarse uno y solamente un valor. Por esta razn la definicin de claves primarias para todas las tablas es prcticamente obligatoria.
FUNDAMENTOS DE BASE DE DATOS Pgina 12

% Regla No. 3 - Tratamiento sistemtico de los valores nulos La informacin inaplicable o faltante puede ser representada a travs de valores nulos. Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de soportar el uso de valores nulos en el lugar de columnas cuyos valores sean desconocidos o inaplicables. No. 4 - La regla de la descripcin de la base de datos La descripcin de la base de datos es almacenada de la misma manera que los datos ordinarios, esto es, en tablas y columnas, y debe ser accesible a los usuarios autorizados. La informacin de tablas, vistas, permisos de acceso de usuarios autorizados, etc, debe ser almacenada exactamente de la misma manera: En tablas. Estas tablas deben ser accesibles igual que todas las tablas, a travs de sentencias de SQL. Regla No. 5 - La regla del sub-lenguaje Integral Debe haber al menos un lenguaje que sea integral para soportar la definicin de datos, manipulacin de datos, definicin de vistas, restricciones de integridad, y control de autorizaciones y transacciones. Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien definida que pueda ser usado para administrar completamente la base de datos. Regla No. 6 - La regla de la actualizacin de vistas Todas las vistas que son tericamente actualizables, deben ser actualizables por el sistema mismo. La mayora de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos de actualizar vistas complejas. Regla No. 7 - La regla de insertar y actualizar La capacidad de manejar una base de datos con operandos simples aplica no solo para la recuperacin o consulta de datos, sino tambin para la insercin, actualizacin y borrado de datos. Esto significa que las clusulas SELECT, UPDATE, DELETE e INSERT deben estar disponibles y operables sobre los registros, independientemente del tipo de relaciones y restricciones que haya entre las tablas. Regla No. 8 - La regla de independencia fsica
FUNDAMENTOS DE BASE DE DATOS Pgina 13

El acceso de usuarios a la base de datos a travs de terminales o programas de aplicacin, debe permanecer consistente lgicamente cuando quiera que haya cambios en los datos almacenados, o sean cambiados los mtodos de acceso a los datos. El comportamiento de los programas de aplicacin y de la actividad de usuarios va terminales debera ser predecible basados en la definicin lgica de la base de datos, y ste comportamiento debera permanecer inalterado, independientemente de los cambios en la definicin fsica de sta. Regla No. 9 - La regla de independencia lgica Los programas de aplicacin y las actividades de acceso por terminal deben permanecer lgicamente inalteradas cuando quiera que se hagan cambios (segn los permisos asignados) en las tablas de la base de datos. La independencia lgica de los datos especifica que los programas de aplicacin y las actividades de terminal deben ser independientes de la estructura lgica, por lo tanto los cambios en la estructura lgica no deben alterar o modificar estos programas de aplicacin. Regla No. 10 - La regla de la independencia de la integridad Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catalogo, no en el programa de aplicacin. Las reglas de integridad son: 1. Ningn componente de una clave primaria puede tener valores en blanco o nulos. (esta es la norma bsica de integridad). 2. Para cada valor de clave fornea deber existir un valor de clave primaria concordante. La combinacin de estas reglas aseguran que haya Integridad referencial. Regla No. 11 - La regla de la distribucin El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos est distribuida fsicamente en distintos lugares sin que esto afecte o altere a los programas de aplicacin. El soporte para bases de datos distribuidas significa que una coleccin arbitraria de relaciones, bases de datos corriendo en una mezcla de distintas mquinas y distintos sistemas operativos y que este conectada por una variedad de redes, pueda funcionar como si estuviera disponible como en una nica base de datos en una sola mquina. Regla No. 12 - Regla de la no-subversin

FUNDAMENTOS DE BASE DE DATOS

Pgina 14

Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser usados para violar la integridad de las reglas y restricciones expresadas en un lenguaje de alto nivel (como SQL). Algunos productos solamente construyen una interfaz relacional para sus bases de datos No relacionales, lo que hace posible la subversin (violacin) de las restricciones de integridad. Esto no debe ser permitido.

5.3 REDUCCION DE UN ESQUEMA E-R A TABLAS

Una base de datos que se ajusta a un diagrama E-R puede representarse por medio de una coleccin de tablas. Para cada conjunto de entidades y para cada conjunto de relaciones existe una tabla nica a la que se le asigna el nombre del conjunto de entidades, o el nombre de conjunto de relaciones correspondiente. Cada tabla tiene un nmero de columnas con nombres nicos. Representacin tabular de las entidades fuertes: una entidad fuerte se representa mediante una tabla con n columnas distintas cada una de las cuales corresponde a uno de los atributos de la entidad. Sea E un conjunto de entidades fuertes con los atributos descriptivos a1, a2,an, E, (a1, a2,,an). Una tabla para E constara de columnas, una para cada atributo descriptivo. Cada fila de la tabla ser una entidad del conjunto entidad E.

Representacin tabular de las entidades dbiles: una entidad dbil, dependiente de una entidad fuerte, se representa mediante una tabla con una columna por cada uno de las claves primarias de la entidad fuerte que depende mas los atributos propios de la entidad dbil. Sea A un conjunto de entidades debiles con los atributos descriptivos a1, a2,,an , A (a1, a2,,an). Sea B el conjunto de entidades fuertes que domina a A con clave atributos descriptivos b1, b2,,bm , B (b1,b2,,bm) y sea la clave primaria de B pk(b1,b2,,bj) Una tabla para A constara de n+j columnas, una para cada atributo del conjunto:

FUNDAMENTOS DE BASE DE DATOS

Pgina 15

{ a1, a2,,an } { b1, b2,,bj } Representacion tabular de las relaciones: se representa mediante una tabla con una columna por cada atributo formado por la union de las claves primarias de las entidades que relaciona mas los atributos descriptivos de la relacion (si los tiene). Sea R un conjunto de relaciones que implica a los conjuntos de entidades E1, E2,, En (n > 1) con llaves primarias pk(E1),,pk(En) respectivamente. Si R no tiene atributos propios entonces se crea una tabla con una columna por cada elemento del conjunto: pk(E1) pk(En) Si R tiene como atributos descriptivos propios, {a1,,am} entonces se crea una tabla con una columna por cada elemento del conjunto: pk(E1) pk(En) {a1,,am} Redundancia de tablas: en general, la tabla para la relacion que une una entidad debil con su correspondiente entidad fuerte es redundante y no necesita ser representada en una representacion tabular de un diagrama E-R. Combinacion de tablas: si una entidad es dependiente de otra, se pueden combinar para formar una nica tabla consistente en la union de las columnas de ambas tablas Atributos multivalorados: para un atributo multivalorado se crea una tabla con una columna que corresponde a la clave primaria de la entidad o de relaciones al que pertenece el atributo multivalorado. Representacion tabular de la especializacion: hay dos formas; la primera es crear una tabla para la entidad de nivel mas alto y para cada entidad de nivel mas bajo, crear una tabla que incluya una columna para cada uno de los atributos de esa entidad mas una columna por cada atributo de la clave primaria de la entidad de nivel mas alto; la segunda, para especializaciones disjuntas y completas, se crea para cada entidad de nivel mas bajo, una tabla que incluya una columna para cada atributo de la entidad mas una columna por cada atributo de la entidad de nivel mas alto.

FUNDAMENTOS DE BASE DE DATOS

Pgina 16

BIBLIOGRAFIA

http://gva1.dec.usc.es/~antonio/docencia/2004basesdedatos/teoria/ModeloRela cional.pdf http://gva1.dec.usc.es/~antonio/docencia/2005bd/teoria/PBModeloRelacional_g ris.pdf

FUNDAMENTOS DE BASE DE DATOS

Pgina 17