el modelo relacional: estáticad… · las 12 reglas de codd 6. bibliografía. diseño de bases de...

El Modelo Relacional: Estática

El Modelo Relacional

Tema 7

Diseño de Bases de Datos y Seguridad de la Información - 2010 www.kybele.urjc.es

Índice

1. Presentación y Objetivos

2. Estructura del Modelo Relacional

1. Elementos del Modelo Relacional

2. Definición Formal de Relación

3. Claves

4. Restricciones

3. El MR y la Arquitectura ANSI

4. Los Valores Nulos y la Lógica Trivaluada

5. Las 12 Reglas de Codd

6. Bibliografía


Objetivos del Modelo Relacional

A finales de los años sesenta E. F. Codd introdujo la teoría matemática de las relaciones en el campo de las Bases de Datos (BD).

El Modelo Relacional fue propuesto por Codd en su artículo titulado “A relational model of data for large shared data banks” (Codd, 1970).

Los objetivos de Codd con el Modelo Relacional son: • Independencia física.- Almacenamiento/manipulación. Un cambio físico no afecta a los programas. • Independencia lógica.- Añadir, eliminar o modificar elementos en la BD no debe repercutir en los programas y/o usuarios que acceden a ellos. • Flexibilidad.- Ofrecer al usuario los datos en la forma más adecuada a cada aplicación. • Uniformidad.- Las estructuras lógicas de los datos son tablas. Facilita la concepción y utilización de la BD por parte de los usuarios. • Sencillez.- Por las características anteriores y por los lenguajes de usuario sencillos, el modelo relacional es fácil de comprender y utilizar por parte del usuario final.

Presentación y Objetivos

Concepto de RELACIÓN como estructura básica


Evolución del Modelo Relacional 1968 - 1970 Surge el modelo

1970 . . . Desarrollos teóricos

1973 - 1978 Prototipos (Ingres, sistema R de IBM, ect. . .)

1978 QBE (Query by Example) de IBM

1979 Oracle (1er SGBD Relacional)

1980 Ingres

1981 SQL

1982 DB2

1986 SQL/ANS

1987 SQL ISO (9075)

1989 SQL Addendum

1989 Manifiesto de los SGBO

1990 Modelo Relacional Versión 2

1990 Manifiesto de los SGBO-3G

1992 SQL 92

1995 3er Manifiesto

1999 SQL:1999

2003 SQL:2003

P

R

E

R

R

E

L

A

C

I

O

N

A

L R

E

L

A

C

I

O

N

A

L

P

O

S

T

R

E

L

A

C

I

O

N

A

L


Actual Estándar Relacional


VENTAS MUNDIALES DE SGBD 1991-1999

Tecnología de

bases de datos

1991 1992 1993 1994 1995 1996 1997 1998 1999 Crecim.

(%)

1994-

1999

Prerrelacional 2.000 2.090 2.109 2.050 1.866 1.721 1.701 1.689 1.638 Crecimiento - 4,5 0,9 -2,8 -9,0 -7,8 -1,2 -0,7 -3,0 -4,4 Cuota de

mercado52,0 45,5 38,8 31,6 24,0 18,4 15,2 12,6 10,3

Relacional 1.844 2.502 3.328 4.435 5.925 7.652 9.513 11.685 14.254 Crecimiento - 35,7 33,0 33,3 33,6 29,1 24,3 22,8 22,0 26,3 Cuota de

mercado48,0 54,5 61,2 68,4 76,0 81,6 84,8 87,4 89,7

SGBD total 3.844 4.592 5.437 6.485 7.791 9.373 11.214 13.374 15.892

Crecimiento - 19,5 18,4 19,3 20,1 20,3 19,6 19,3 18,8 19,6

VENTAS MUNDIALES DE SGBD

FUENTE: Estudio IDC



0

2

4

6

8

10

12

14

16

1994 1995 1996 1997 1998Miles d

e m

illo

nes d

e d

óla

res

Total ingresos por las ventas mundiales de SGBD

Orientado al objeto

Pre-relacionales

Relacionales

FUENTE: PriceWaterhouse 1996



Ejemplo de una relación

NOMBRE NACIONALIDAD … ATRIBUTO N

RODRÍGUEZ ESPAÑOLA … XXXX

SÁNCHEZ ESPAÑOLA … XXXX

… … … …

XXXX XXXX … XXXX

Tupla 1

Tupla 2

Tupla M

. . .

Representación de la relación “AUTOR” en forma de tabla de grado N y cardinalidad M.

Estructura del MR Elementos del MR

AUTOR


Relación

Es la estructura básica del modelo relacional. Se representa mediante una tabla.

Atributo

Representa las propiedades de la relación. Se representa mediante una columna.

Dominio

Es el conjunto válido de valores que toma un atributo.

Tupla

Es una ocurrencia de la relación. Se representa mediante una fila.



Grado

Es el número de atributos de la relación (columnas de la tabla).

Cardinalidad

Es el número de tuplas de la relación (filas de la tabla).



Características de una relación:

No puede haber tuplas duplicadas.

El orden de las tuplas es irrelevante.

La tabla es plana, es decir, en el cruce de un atributo y una tupla sólo puede haber un valor.

El orden de los atributos no es significativo.



Nombre Nacionalidad Institución

Date, C.J.

Codd, E.F.

Ceri, S.

Saltor, F.

Norteamericana

Norteamericana

Italiana

Española

Relational Institute


Politécnico de Milán

U.P.C.

Grado 3

Atributos

T

U

P

L

A

S

Cardinalidad

4

AUTOR

xxxxxxxx

25

Española

Francesa

Italiana

Norteamericana

Inglesa

U.P.M.

U.P.C.



NOMBRES NACIONALIDADES INSTITUCIONES

DOMINIOS



RELACIÓN TABLA FICHERO

TUPLA

ATRIBUTO

GRADO

CARDINALIDAD

FILA

COLUMNA

Nº DE COLUMNAS

Nº DE FILAS

REGISTRO

CAMPO

Nº DE CAMPOS

Nº DE REGISTROS

~ ~

Comparación de la terminología relación, tabla, fichero



Las vistas son “tablas virtuales” que se definen sobre una o más tablas. Las vistas son ventanas sobre tablas “reales” de las que sólo se almacena su definición; no tienen representación directa en el almacenamiento.

Vista:

ALUMNO

Dni Nombre Edad

1 A0001 José 17 2 A0002 María 21 3 A0003 Juan 20

Num_Mat Vista de ALUMNO: V_Alumnos_MayoresEdad: Incluye el número de la matrícula, nombre y edad de los alumnos mayores de edad.



Ventajas del uso de vistas:

Mecanismo de seguridad potente y flexible al ocultar partes de la BD a ojos de ciertos usuario. Los usuarios no son conscientes de la existencia de ningún atributo o tupla no incluida en la vista.

Acceso a los datos de forma personalizada para las necesidades de los usuarios.

Simplifican las operaciones complejas sobre relaciones base.



Actualización de las vistas:

Todas las actualizaciones efectuadas en una relación base deben verse inmediatamente reflejadas en todas las vistas que hagan referencia a esa relación base.

De forma similar, si se actualiza una vista, la relación base subyacente debe reflejar el cambio.

Sin embargo, existen restricciones en los tipos de modificaciones que pueden efectuarse mediante vistas:

Una vista es actualizable si está definida utilizando una consulta simple en la que esté involucrada una única relación base y que contenga la clave principal o una clave candidata de la relación base.

Una vista NO es actualizable si implica múltiples relaciones base.

Una vista NO es actualizable si implica operaciones de agregación o de agrupación.



Con nombre Sin nombre (son siempre temporales)

Persistentes Temporales

Base (definición + extensión) Vistas (definición) Instantáneas (definición +datos)

Autónomas (o base temporales) Vistas temporales Instantáneas Temporales

Resultado final de una consulta Resultados intermedios de una consulta

Clases de relación:

Derivadas



El Universo del Discurso (UD) de una base de datos relacional está compuesto por un conjunto de dominios {Di} y de relaciones {Ri} definidas sobre los dominios.

Un dominio es un conjunto nominado, finito y homogéneo de valores atómicos. Cada dominio se especifica lógicamente mediante un nombre y un formato, el cual puede definirse por extensión (dando sus posibles valores) o por intensión (mediante un tipo de datos y ciertas restricciones, como un rango de valores).

Un atributo (A) es la interpretación de un determinado dominio en una relación, es decir el “papel” que juega en la misma; si D es el dominio de A se denota:

D = Dom (A).

Una relación definida sobre un conjunto de dominios D1...Dn (no necesariamente distintos) es un subconjunto del producto cartesiano de los n dominios (n es el grado de la relación).

R D1x D2x...Dn

Estructura del MR Definición Formal de Relación


Un esquema de relación (intensión) se compone de un nombre de relación R, de un conjunto de n atributos {A1} y de un conjunto de n dominios (no necesariamente distintos) {Di}, donde cada atributo será definido sobre un dominio: R ( A1 : D1, A2 : D2, . . . An : Dn) Una relación r(R) (extensión) es un conjunto de m elementos denominados tuplas {tj}. Cada tuplaj es conjunto de pares (<A1:v1j>,...<Ai:vij>,...<An:vnj>) donde cada Ai es el nombre de un atributo y vij es un valor del correspondiente dominio Di sobre el que está definido el atributo: r(R) = tj {(<A1:v1j>, . . . <Ai:vij>, . . . <An:vnj>) : vij Di }



ESQUEMA DE RELACIÓN (INTENSIÓN):

AUTOR (Nombre: Nombres, Nacionalidad: Nacionalidades, Institución: Instituciones)

RELACIÓN (EXTENSIÓN, ESTADO u OCURRENCIA):

Nombre Nacionalidad Institución

Date, C.J.

Saltor, F.

Ceri, S.

Norteamericana

Española

Italiana


U.P.C.


AUTOR cabecera

de la relación

cuerpo de la relación



Clave Candidata

Es el conjunto no vacío de atributos que identifica unívoca y mínimamente cada tupla de una relación.

Clave Primaria (primary key)

Es la clave candidata que elige el usuario para identificar las tuplas de la relación. Se dice que una clave primaria es compuesta cuando está formada por más de un atributo.

Regla de Integridad de Entidad

Ningún atributo principal, es decir, ningún atributo que forme parte de la clave primaria, puede tomar un valor nulo.

Clave Alternativa (unique)

Aquella clave candidata que no ha sido elegida como clave primaria.

Estructura del MR Claves


Clave Ajena (foreign key)

La clave ajena 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 una relación R1 (R1 y R2 no son necesariamente distintas).

La clave ajena y la correspondiente clave primaria han de estar definidas sobre los mismos dominios.

La clave ajena sirve para relacionar tablas.

R2 (A1, A2, A3, A4) R1(B1, B2)

Clave Ajena



LIBRO (código, título, idioma…, nombre-e)

EDITORIAL (nombre-e, dirección, ciudad, país…)

Nombre-e es clave ajena de LIBRO, y referencia a EDITORIAL (nombre-e es clave primaria de EDITORIAL). Esta última tabla (EDITORIAL) se denomina tabla referenciada.

Ejemplo de relación entre tablas 1:N



Ejemplo de relación entre tablas N:M

AUTOR (Nombre, Nacionalidad, Institución, …) LIBRO (Código, Título, Idioma, Editorial, …) ESCRIBE (Nombre, Cod_Libro) clave ajena clave ajena



Si una relación R2 tiene un atributo que es clave primaria de la relación R1, entonces los valores de dicho atributo deben concordar con los de la clave primaria de la tabla referenciada o tener valores nulos.

Regla de Integridad Referencial

Ejemplo:

Código Título Idioma Nombre_e

001 Bases de

Datos

Español Ra-ma

002 Data

Base

Inglés

003 Diseño de

Bases de

Datos

Español Ra-ma

LIBRO

Nombre_e Dirección Ciudad País

Ra-ma Pez, 20 Madrid España

Addison-

Wesley

24 Lennon London UK

Paraninfo Entenza, 5 Barcelona España

EDITORIAL



Restricciones Inherentes

Derivadas de la definición de relación:

No hay dos tuplas iguales (obligatoriedad de la clave primaria)

El orden de las tuplas no es significativo

El orden de los atributos no es significativo

Cada atributo sólo puede tomar un único valor del dominio sobre el que está definido, no admitiéndose por tanto los grupos repetitivos. Se dice que una tabla que cumple esta condición está normalizada (o también que está en primera forma normal).

Regla de Integridad de Entidad (ningún atributo que forme parte de la clave primaria, puede tomar un valor nulo).

Regla de Integridad Referencial (si una relación R2 tiene un atributo que es clave primaria de la relación R1, entonces los valores de dicho atributo deben concordar con los de la clave primaria o tener valores nulos).

Estructura del MR Restricciones


Nombre Nacionalidad Institucion

Date, C.J.

Codd, E.F.

Ceri, S.

Saltor, F.

Norteamericana

Norteamericana

Italiana

Española



Politécnico de Milan

U.P.C.

Idiomas

Inglés, Español

Inglés

Italiano, Inglés

Español, Catalán

AUTOR1

Nombre Nacionalidad Institucion

Date, C.J.

Date, C.J.

Codd, E.F.

Ceri, S.

Ceri, S.

Saltor, F.

Saltor, F.

Norteamericana

Norteamericana

Norteamericana

Italiana

Italiana

Española

Española






U.P.C.

U.P.C.

Idioma

Inglés

Español

Inglés

Italiano

Inglés

Español

Catalán

AUTOR2



Restricciones Semánticas

• Clave primaria (PRIMARY KEY). Permite declarar un atributo o un conjunto de atributos como clave primaria de una relación por lo que sus valores no se podrán repetir ni se admitirán los nulos (o valores “ausentes”).

• Unicidad (UNIQUE). Mediante la cual se indica que los valores de un conjunto de atributos (uno o más) no pueden repetirse en una relación. Esta restricción permite la definición de claves alternativas.

• Obligatoriedad (NOT NULL), de uno ó mas atributos, con lo que se indica que el conjunto de atributos no admite valores nulos.

• Integridad referencial (FOREIGN KEY). Si una relación R2 (relación que referencia) tiene un descriptor que es una clave candidata de la relación R1 (relación referenciada), todo valor de dicho descriptor debe, bien concordar con un valor de la clave candidata referenciada de R1, bien ser nulo. El descriptor es, por tanto, una clave ajena de la relación R2. Las relaciones R1 y R2 no son necesariamente distintas. Además, cabe destacar que la clave ajena puede ser también parte (o la totalidad) de la clave primaria de R2.



CREATE TABLE editorial (

nombre_e CHAR(20) PRIMARY KEY,

dirección CHAR(50) NOT NULL,

ciudad CHAR (15),

país CHAR(15));

CREATE TABLE libro (

código CHAR(3),

titulo CHAR (50) UNIQUE,

idioma CHAR(25),

nombre_e CHAR(20),

PRIMARY KEY (código),

FOREIGN KEY (nombre_e) REFERENCES editorial

ON DELETE SET NULL

ON UPDATE CASCADE);

Ejemplo:



NO ACTION: rechazar la operación de borrado o actualización.

CASCADE: propagar la modificación o borrar las tuplas de la tabla que referencia.

SET NULL: poner a valor nulo en la Clave Ajena de la tabla que referencia.

SET DEFAULT: poner valor por defecto en la Clave Ajena de la tabla que referencia.

Opciones de Borrado y Actualización en la Clave Ajena



PROGRAMA ( Cód_Programa , Nombre, Departamento )

ESTUDIANTE ( Cód_Estudiante, Nombre, Apellidos, DNI, … )

BECA ( Cód_Beca, Nombre, Requisitos, … )

CURSO_DOCTORADO ( Cód_Curso, Nombre, N_Horas, Cód_Programa, F_ Com)

Clave Ajena

Modificación: Cascada

Borrado: puesta a nulos

SOLICITA ( Cod_Estudiante, Cód_Beca,)

Clave Ajena


Borrado: Cascada

Clave Ajena

Modificación: NO ACTION

Borrado: NO ACTION

SE_MATRICULA ( Cód_Estudiante, Cod_Curso )

Clave Ajena


Borrado: Cascada

Clave Ajena


Borrado: Cascada

CONCEDE (Cód_Estudiante, Cód_Beca)

Ejemplo:



• Verificación (CHECK). Comprueba, en toda operación de actualización, si el predicado es cierto o falso y, en el segundo caso, rechaza la operación. La restricción de verificación se define sobre un único elemento (dominio, relación) y puede o no tener nombre.

• Aserción (ASSERTION). Actúa de forma idéntica a la anterior, pero se diferencia de ella en que puede afectar a varios elementos (por ejemplo, a dos relaciones distintas) y su definición, por tanto, no va unida a la de un determinado elemento por lo que siempre ha de tener un nombre, ya que la aserción es un elemento más del esquema que tiene vida por sí mismo.

• Disparador (“trigger”). Restricciones en las que el usuario pueda especificar libremente la respuesta (acción) ante una determinada condición. Así como las anteriores reglas de integridad son declarativas, los disparadores son procedimentales, siendo preciso que el usuario escriba el procedimiento que ha de aplicarse en caso de que se cumpla la condición.

Otras Restricciones Semánticas



SQL - Manipulación

VISTA 1 VISTA 2 VISTA m

TABLA BASE

TB 1

TABLA BASE

TB 2

TABLA BASE

TB p

RELACIONAL

DATOS ALMACENADOS (Registros de las tablas base, índices, agrupamientos, etc.)

EXTERNO

CREATE VIEW +

sentencia de manipulación

(SELECT)

CONCEPTUAL

(CREATE TABLE,

CREATE DOMAIN,

CREATE ASSERTION

…)

INTERNO

(CREATE INDEX,

CREATE PARTITION,

CREATE CLUSTER,

…)

Independen-

cia lógica

Independen-

cia física

…...

N

I

V

E

L

L

O

G

I

C

O

N

I

V

E

L

F

I

S

I

C

O

El MR y la Arquitectura ANSI


ANS I RELACIONAL

L

O

G

I

C

O

F

I

S

I

C

O

S

Q

L

PRODUCTOS

Nivel Externo Vistas

Relaciones Base

Nivel Conceptual Relaciones Base

Nivel Interno Datos Almacenados

- Relaciones base almacenadas

- Indices

- Punteros

- Direcciones de página

- ...

El MR y la Arquitectura ANSI


Valor nulo: Señal utilizada para representar información desconocida, inaplicable, inexistente, no

válida, no proporcionada, indefinida, etc.

Necesidad de los valores nulos en BD:

• Crear tuplas (filas) con ciertos atributos desconocidos en ese momento, p.e. el año de edición de un libro.

• Añadir un nuevo atributo a una relación existente; atributo que, en el momento de añadirse, no tendría ningún valor para las tuplas de la relación.

• Atributos inaplicables a ciertas tuplas, por ejemplo, la editorial para un artículo (ya que un artículo no tiene editorial) o la profesión de un menor.

Los Valores Nulos y la Lógica Trivaluada


El tratamiento de valores nulos exige definir:

• operaciones de comparación • operaciones aritméticas • operaciones algebraicas • funciones de agregación

Tablas de Verdad de la Lógica Trivaluada:

Los Valores Nulos y la Lógica Trivaluada

NOT A A B A AND B A OR B

F T T T T

F T F F T

F T N N T

T F F F F

T F N F N

N N N N N

T: True F: False N: Null


Las 12 Reglas de Codd

Codd definió un conjunto de reglas que un SGBD debe satisfacer para que sea considerado relacional en su artículo titulado: “Is your DBMS really relational” (Codd, 1985 en ComputerWorld). Se denominan las 12 Reglas de Codd, aunque en realidad definió 13 reglas para considerar un sistema relacional (Regla 0- Regla 12).


Regla 1.- Representación de la información:

Toda información almacenada en una base de datos relacional debe representarse explícitamente a nivel lógico, y de manera única, por medio de valores en tablas. Podríamos decir que éste es el principio básico del modelo relacional.


Tabla

A1 A2 A3 A4

Los nombres de las tablas, nombres de los atributos y toda la información necesaria para el funcionamiento de la BD se representa mediante tablas Catálogo del sistema es una BD relacional


Regla 2.- Acceso garantizado:

Todo dato debe ser accesible mediante una combinación de un nombre de tabla, un valor de su clave y el nombre de una columna. Es una forma de insistir en la obligatoriedad de la clave primaria.


ALUMNO

Dni Nombre Edad

1 José 18 2 María 21 3 Juan 20

¿Nombre de ALUMNO

Con DNI =2?

María

En una BD Relacional los datos NO se referencian por su posición física.


Regla 3.- Tratamiento sistemático de valores nulos:

Los valores nulos, información desconocida o inaplicable, han de ser tratados sistemáticamente por el sistema, el cual ha de ofrecer las facilidades necesarias para su tratamiento.


ALUMNO

Dni Nombre Edad

1 José 18 2 NULL 21 3 Juan NULL


Regla 4.- Catálogo activo en línea basado en el modelo relacional:

La representación de la metainformación (descripción de la base de datos) debe ser igual a la de los otros datos y su acceso debe poder realizarse por medio del mismo lenguaje relacional que se utiliza para los demás datos; es decir, el modelo de datos para la metainformación debe ser también el relacional.


En un SGBD Relacional hay dos tipos de tablas: •Tablas de usuario con datos •Tablas del sistema que contienen datos que describen la estructura de la BD Catálogo


Regla 5.- Sublenguaje de datos completo:

Debe existir un lenguaje que permita un completo manejo de la base de datos (definición de datos, definición de vistas, manipulación de datos, restricciones de integridad, autorizaciones y gestión de transacciones).


El lenguaje SQL aporta todas estas funciones.


Regla 6.- Actualización de vistas:

Toda vista teóricamente actualizable debe poder ser actualizada por el sistema.


Esta regla obliga al SGBD a ser capaz de actualizar cualquier vista que se haya definido en el sistema y que cumpla con las condiciones teóricas que hagan posible la actualización de datos a través de ella.


Regla 7.- Inserciones, modificaciones y eliminaciones de alto nivel:

Todas las operaciones de manipulación de datos (consulta, inserción, modificación y borrado) deben operar sobre conjuntos de filas (lenguaje no navegacional).

Los sistemas existentes hasta el momento en el que surge el modelo relacional actuaban registro a registro obligando al programador de una base de datos a navegar por la misma.



Regla 8.- Independencia física de los datos:

El acceso lógico a los datos debe mantenerse incluso cuando cambien los métodos de acceso o la forma de almacenamiento.

Los programas de las aplicaciones y las operaciones sobre la BD deben mantenerse inalterados desde el punto de vista lógico, aunque se produzcan cambios en los mecanismos de almacenamiento (p.e. ubicación física de los ficheros de la BD ) y acceso de la BD (p.e. índices).



Regla 9.- Independencia lógica de los datos:

Los programas de aplicación no deben verse afectados por cambios realizados en las tablas que estén permitidos teóricamente y que preserven la información.

No habrá que modificar los programas de las aplicaciones aunque se realicen cambios sobre las tablas, siempre que esos cambios mantengan la información que en ellas hubiese.



Regla 10.- Independencia de la integridad:

Las reglas de integridad de una base de datos deben ser definibles por medio del sublenguaje de datos relacional y habrán de almacenarse en el catálogo de la base de datos (metabase), no en los programas de aplicación.



Regla 11.- Independencia de la distribución:

Debe existir un sublenguaje de datos que pueda soportar bases de datos distribuidas sin alterar los programas de aplicación cuando se distribuyan los datos por primera vez o se redistribuyan éstos posteriormente.

Un programa de aplicación no debe notar la diferencia entre trabajar sobre la BD cuando esta se encuentra centralizada en una máquina y cuando los datos se distribuyen entre varias máquinas. El sistema debe ser responsable de presentar los datos al usuario final como si estuvieran en una única máquina.

PERO: Para que un sistema sea relacional no tiene obligatoriamente que dar soporte a las BD distribuidas.



Regla 12.- Regla de la no subversión:

Si un SGBD soporta un lenguaje de bajo nivel que permite el acceso fila a fila, éste no puede utilizarse para saltarse las reglas de integridad expresadas por medio del lenguaje de más alto nivel.

El SGBD debe controlar todos los accesos a la BD de forma que la integridad de la BD no pueda verse comprometida sin conocimiento del usuarios y el administrador de la BD.



Regla 0.- Regla básica:

Cualquier sistema que se anuncie como sistema gestor de bases de datos relacionales debe ser capaz de gestionar por completo las BD utilizando sus capacidades relacionales.

El SGBD Relacional NO debe recurrir a operaciones NO relacionales para completar sus capacidades de gestión de datos (definición y manipulación).



Tecnología y Diseño de Bases de Datos M.Piattini, E. Marcos, C.Calero y B. Vela Ed.: RA-MA, 2006 Octubre Parte II, capítulo 6

Fundamentos y Modelos de Bases de Datos A. de Miguel y M. Piattini Ed.: RA-MA, 1997 Capítulo 5 (Pág. 123-166)

Sistemas de Bases de Datos T. M. Connolly y C. E. Begg Ed.: Addison Wesley, Cuarta Edición, 2001 Parte II , capítulo 3 (Pág. 61-78)

Introducción a las Bases de Datos. El Modelo Relacional O. Pons et al. Ed.: Thomson, 2005 Capítulo 5 (Pág. 141-159)

Introducción a los Sistemas de Bases de Datos C. J. Date Ed.: Prentice Hall, Séptima Edición, 2001 Parte II (Pág. 109-149)

Diseño de Bases de Datos. Problemas Resueltos. A. de Miguel et al. Ed.: RA-MA, 2001

Bibliografía

el modelo relacional: estáticad… · las 12 reglas de codd 6. bibliografía. diseño de bases de...

Documents