El documento describe los tres niveles de abstracción de un SGBD según el modelo ANSI-SPARC: el nivel interno o físico, el nivel externo o de visión, y el nivel conceptual. El nivel interno describe la estructura física de la base de datos, el nivel externo describe las vistas de los usuarios, y el nivel conceptual describe la estructura de toda la base de datos para un grupo de usuarios de forma conceptual, ocultando los detalles físicos.

1. Niveles de un sgbd
En 1975, el comité ANSI-SPARC (American National Standard Institute -
StandardsPlanning and RequirementsCommittee) propuso una arquitectura de tres
niveles para los SGBD cuyo objetivo principal era el de separar los programas de
aplicación de la BD física. En esta arquitectura el esquema de una BD se define en tres
niveles de abstracción distintos:
- Nivel interno o físico: el más cercano al almacenamiento físico, es decir, tal y como
están almacenados en el ordenador. Describe la estructura física de la BD mediante un
esquema interno. Este esquema se especifica con un modelo físico y describe los detalles
de cómo se almacenan físicamente los datos: los archivos que contienen la información,
su organización, los métodos de acceso a los registros, los tipos de registros, la longitud,
los campos que los componen, etcétera.
- Nivel externo o de visión: es el más cercano a los usuarios, es decir, es donde se
describen varios esquemas externos o vistas de usuarios. Cada esquema describe la
parte de la BD que interesa a un grupo de usuarios en este nivel se representa la visión
individual de un usuario o de un grupo de usuarios.
- Nivel conceptual: describe la estructura de toda la BD para un grupo de usuarios
mediante un esquema conceptual. Este esquema describe las entidades, atributos,
relaciones, operaciones de los usuarios y restricciones, ocultando los detalles de las
estructuras físicas de almacenamiento. Representa la información contenida en la BD.
Tipos de sgbd
Clasificación de los SGBD
Esta clasificación está basada en el modelo de datos en que está basado el SGBD. Los modelos de datos
más habituales son:
* Relacional (SGBDR): representa a la base de datos como una colección de tablas. Estas bases de datos
suelen utilizar SQL como lenguaje de consultas de alto nivel.
* Orientado a objetos: define a la base de datos en términos de objetos, sus propiedades y sus operaciones.
Todos los objetos que tienen la misma estructura y comportamiento pertenecen a una clase y las clases de

2. organizan en jerarquías.
* Objeto-relacional o relacional extendido: son los sistemas relacionales con características de los orientado a
objetos.
* Jerárquico: representa los datos como estructuras jerárquicas de árbol.
* En red o CODASYL DBTG.
Un SGBD también puede clasificarse por el número de usuario a los que da servicio:
* Monousuario
* Multiusuario
También puede clasificarse según el número de sitios en los que está distribuida la base de datos:
* Centralizado: la base de datos y el software SGBD están almacenados en un solo sitio (una sola
computadora).
* Distribuido (SGBDD): la base de datos y el software SGBD pueden estar distribuidos en múltiples sitios
conectados por una red.
Breve historia de los SGBDR
El modelo relacional fue presentado en la década del 70, y a partir de ese momento comenzaron a
desarrollarse múltiples sistemas para gestionar las bases de datos relacionales. IBM fue una de las pioneras
en el desarrollo de productos comerciales sobre SGBD relacionales; algunos de sus productos fueron el
SQL/DS para los entornos DOS/VSE y VM/CMS, y el DB2 para el sistema operativo MVS en 1983.
En tanto, INGRES fue otro SGBDR desarrollado por la Universidad de Berkeley a principios de los setenta.
Luego se convirtió en comercial y comenzó a ser distribuido por Ingres Inc. y luego por ComputerAssociates.
Otras marcas comerciales de SGBDR son Oracle de Oracle Inc., Sybase de Sybase Inc., RDB de Digital
Equipment Corp. de Compaq, INFORMIX de Informix Inc. y UNIFY de Unify Inc.
Además de los SGBDR mencionados, en los ochenta aparecen múltiples aplicaciones para PCs como ser
RIM, RBASE 5000, PARADOX, OS/2 Database Manager, DBase IV, XDB, WAT-COM SQL, SQL
Server (deSybase Inc.), SQL Server (de Microsoft), Access, etc.
Modelo entidad-relación

3. Ejemplo de diagrama E-R.
Un diagrama o modelo entidad-relación (a veces denominado por su siglas, E-
R "Entityrelationship", o, "DER" Diagrama de Entidad Relación) es una herramienta para
el modelado de datos de un sistema de información. Estos modelos expresan entidades relevantes
para un sistema de información así como sus interrelaciones y propiedades.
Contenido
[ocultar]
1 Modelado Entidad-Relación
2 Base Teórica y Conceptual
o 2.1 Entidad
o 2.2 Conjunto de entidades
o 2.3 Atributos
o 2.4 Relación
o 2.5 Conjunto de relaciones
3 Restricciones
o 3.1 Correspondencia de cardinalidades
o 3.2 Restricciones de participación
4 Claves
5 Diagrama entidad-relación
o 5.1 Entidad
o 5.2 Atributo
o 5.3 Relaciones
6 Diagramas extendidos
o 6.1 Entidades fuertes y débiles

4. o 6.2 Cardinalidad de las relaciones
o 6.3 Atributos en relaciones
o 6.4 Herencia
o 6.5 Agregación
7 Véase también
Modelado Entidad-Relación [editar]
El Modelo Entidad-Relación, también conocido como DER (diagramas entidad-relación) es una
herramienta de modelado para bases de datos, propuesto por Peter Chen en 1976, mediante el
cual se pretende 'visualizar' los objetos que pertenecen a la Base de Datos como entidades (se
corresponde al concepto de clase, cada tupla representaría un objeto, de la Programación
Orientada a Objetos) las cuales tienen unos atributos y se vinculan mediante relaciones.
Es una representación conceptual de la información. Mediante una serie de procedimientos se
puede pasar del modelo E-R a otros, como por ejemplo el modelo relacional.
El modelado entidad-relación es una técnica para el modelado de datos utilizando diagramas
entidad relación. No es la única técnica pero sí la más utilizada. Brevemente consiste en los
siguientes pasos:
1. Se parte de una descripción textual del problema o sistema de información 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-relación.
7. Se completa el modelo con listas de atributos y una descripción de otras restricciones que
no se pueden reflejar en el diagrama.
Dado lo rudimentario de esta técnica se necesita cierto entrenamiento y experiencia para lograr
buenos modelos de datos.
El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras técnicas para
lograr un modelo directamente implementable en una base de datos. Brevemente:
 Transformación de relaciones múltiples en binarias.

5.  Normalización de una base de datos de relaciones (algunas relaciones pueden transformarse
en atributos y viceversa).
 Conversión en tablas (en caso de utilizar una base de datos relacional).
Base Teórica y Conceptual [editar]
El modelo entidad-relación se basa en los conceptos descritos a continuación para representar un
modelo de la vida real.
Entidad [editar]
Representa una “cosa” u "objeto" del mundo real con existencia independiente, es decir, se
diferencia unívocamente de cualquier otro objeto o cosa, incluso siendo del mismo tipo, o una
misma entidad.
Algunos Ejemplos:
 Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos).
 Un automóvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrán atributos
diferentes, por ejemplo, el número de bastidor).
 Una casa (Aunque sea exactamente igual a otra, aún se diferenciará en su dirección).
Una entidad puede ser un objeto con existencia física como: una persona, un animal, una casa,
etc. (entidad concreta), o un objeto con existencia conceptual como: un puesto de trabajo, una
asignatura de clases, un nombre,etc. (entidad abstracta).
Una entidad está descrita y se representa por sus características o atributos. Por ejemplo, la
entidad Persona puede llevar consigo las características: Nombre, Apellido, Género, Estatura,
Peso, Fecha de nacimiento, etc...
Conjunto de entidades [editar]
Es una colección de entidades que comparten los mismos atributos o características.
Ejemplos:
 Todos los atletas que participan en los Juegos Olímpicos, comparten sus atributos: nombre,
número de identificación, edad, peso, categoría...
 Todos los países del mundo, comparten las características: nombre, continente, área, lengua
principal, lengua secundaria, moneda, etc.
Atributos [editar]
Los atributos son las propiedades que describen a cada entidad en un conjunto de entidades.

6. Un conjunto de entidades dentro de una entidad, tiene valores específicos asignados para cada
uno de sus atributos, de esta forma, es posible su identificación unívoca.
Ejemplos:
A la colección de entidades Alumnos, con el siguiente conjunto de atributos en común, (id, nombre,
edad, semestre), pertenecen las entidades:
 (1, Sofia, 18 años, 2)
 (2, Josefa, 19 años, 5)
 (3, Gabriela, 20 años, 2)
 ...
Cada una de las entidades pertenecientes a este conjunto se diferencia de las demás por el valor
de sus atributos. Nótese que dos o más entidades diferentes pueden tener los mismos valores para
algunos de sus atributos, pero nunca para todos.
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 alumno de
otro es su número de id.
Para cada atributo, existe un dominio del mismo, este hace referencia al tipo de datos que será
almacenado o a restricciones en los valores que el atributo puede tomar (Cadenas de caracteres,
números, solo dos letras, solo números mayores que cero, solo números enteros...).
Cuando una entidad no tiene un valor para un atributo dado, este toma el valor nulo, bien sea que
no se conoce, que no existe o que no se sabe nada al respecto del mismo.
Relación [editar]
Describe cierta dependencia entre entidades o permite la asociación de las mismas.
Ejemplo:
Dadas dos entidades "Habitación 502" y "Mark", es posible relacionar que
la
habitacion 502 se encuentra ocupada por el huésped de nombre Mark.
Una relación tiene sentido al expresar las entidades que relaciona. En el ejemplo anterior, Un
Huésped (entidad), se aloja (relación) en una habitación (entidad).
Conjunto de relaciones [editar]

7. Consiste en una colección, o conjunto, de relaciones de la misma naturaleza.
Ejemplo:
Dados los conjuntos de entidades "Habitación" y "Huésped", todas las relaciones de la forma
habitación-huésped, permiten obtener la información de los huéspedes y sus respectivas
habitaciones.
La dependencia o asociación entre los conjuntos de entidades es llamada participación. En el
ejemplo anterior los conjuntos de entidades "Habitación" y "Huésped" participan en el conjunto de
relaciones habitación-huésped.
Se llama grado del conjunto de relaciones a la cantidad de conjuntos de entidades participantes en
la relación.
Restricciones [editar]
Son reglas que deben mantener los datos almacenados en la base de datos.
Correspondencia de cardinalidades [editar]
Dado un conjunto de relaciones en el que participan dos o más conjuntos de entidades, la
correspondencia de cardinalidad indica el número de entidades con las que puede estar
relacionada una entidad dada.
Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia de
cardinalidades puede ser:
 Uno a uno: Una entidad de A se relaciona únicamente con una entidad en B y viceversa.
 Uno a varios: Una entidad en A se relaciona con cero o muchas entidades en B. Pero una
entidad en B se relaciona con una única entidad en A.
 Varios a uno: Una entidad en A se relaciona exclusivamente con una entidad en B. Pero una
entidad en B se puede relacionar con 0 o muchas entidades en A.
 Varios a varios: Una entidad en A se puede relacionar con 0 o muchas entidades en B y
viceversa.
Restricciones de participación [editar]
Dado un conjunto de relaciones R en el cual participa un conjunto de entidades A, dicha
participación puede ser de dos tipos:
 Total: Cuando cada entidad en A participa en al menos una relación de R.

8.  Parcial: Cuando al menos una entidad en A NO participa en alguna relación de R.
Claves [editar]
Es un subconjunto del conjunto de atributos comunes en una colección de entidades, que permite
identificar unívocamente cada una de las entidades pertenecientes a dicha colección. Asimismo,
permiten distinguir entre sí las relaciones de un conjunto de relaciones.
Dentro de los conjuntos de entidades existen los siguientes tipos de claves:
 Superclave: Es un subconjunto de atributos que permite distinguir unívocamente cada una de
las entidades de un conjunto de entidades. Si se añade un atributo al anterior subconjunto, el
resultado seguirá siendo una superclave.
 Clave candidata: Dada una superclave, si ésta deja de serlo quitando únicamente uno de los
atributos que la componen, entonces ésta es una clave candidata.
 Clave primaria: Es una clave candidata, elegida por el diseñador de la base de datos, para
identificar unívocamente las entidades en un conjunto de entidades.
Los valores de los atributos de una clave, no pueden ser todos iguales para dos o más entidades.
Para poder distinguir unívocamente las relaciones en un conjunto de relaciones R, se deben
considerar dos casos:
 R NO tiene atributos asociados: En este caso, se usa como clave primaria de R la unión de
las claves primarias de todos los conjuntos de entidades participantes.
 R tiene atributos asociados: En este caso, se usa como clave primaria de R la unión de los
atributos asociados y las claves primarias de todos los conjuntos de entidades participantes.
Si el conjunto de relaciones, R, sobre las que se pretende determinar la clave primaria está
compuesto de relaciones binarias, con los conjuntos de entidades participantes A y B, se
consideran los siguientes casos, según sus cardinalidades:
 R es de muchos a uno de A a B entonces sólo se toma la clave primaria de A, como clave
primaria de R.
 R es de uno a muchos de A a B entonces se toma sólo la clave primaria de B, como clave
primaria de R.
 R es de uno a uno de A a B entonces se toma cualquiera de las dos claves primarias, como
clave primaria de R.

9.  R es de muchos a muchos de A a B entonces se toma la unión de los atributos que
conforman las claves primarias de A y de B, como clave primaria de R.
Diagrama entidad-relación [editar]
Formalmente, los diagramas E-R son un lenguaje gráfico para describir conceptos. Informalmente,
son simples dibujos o gráficos que describen la información que trata un sistema de información y
el software que lo automatiza.
Entidad [editar]
Se representa mediante un rectángulo o "caja" etiquetada en su interior mediante un identificador.
Ejemplos de entidades habituales en los sistemas de información son: factura, persona, empleado,
etc.
Atributo [editar]
Se representan mediante un círculo o elipse etiquetado mediante un nombre en su interior. Cuando
un atributo es identificativo de la entidad se suele subrayar dicha etiqueta.
Relaciones [editar]
Se representa mediante un rombo etiquetado en su interior con un verbo. Este rombo se debe unir
mediante líneas con las entidades (rectángulos) que relaciona.
Por motivos de legibilidad, los atributos no suelen representarse en un diagrama entidad-relación,
sino que se describen textualmente en otros documentos adjuntos.
Diagramas extendidos [editar]
DER extendido
Los diagramas Entidad-Relación no cumplen su propósito con eficacia debido a que tienen
limitaciones semánticas. Por ese motivo se suelen utilizar los diagramas Entidad-Relación
extendidos que incorporan algunos elementos más al lenguaje:

10. Entidades fuertes y débiles [editar]
Cuando una entidad participa en una relación puede adquirir un papel fuerte o débil. Una entidad
débil es aquella que no puede existir sin participar en la relación, es decir, aquella que no puede
ser unívocamente identificada solamente por sus atributos. Una entidad fuerte (también conocida
como entidad regular) es aquella que sí puede ser identificada unívocamente. En los casos en que
se requiera, se puede dar que una entidad fuerte "preste" algunos de sus atributos a una entidad
débil para que, esta última, se pueda identificar.
Las entidades débiles se representan- mediante un doble rectángulo, es decir, un rectángulo con
doble línea.
Cardinalidad de las relaciones [editar]
El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relación,
respectivamente: "1:1", "1:N" y "N:M", aunque la notación depende del lenguaje utilizado, la que
más se usa actualmente es el unificado. Otra forma de expresar la cardinalidad es situando un
símbolo cerca de la línea que conecta una entidad con una relación:
 "0" si cada instancia de la entidad no está obligada a participar en la relación.
 "1" si toda instancia de la entidad está obligada a participar en la relación y, además,
solamente participa una vez.
 "N" , "M", ó "*" si cada instancia de la entidad no está obligada a participar en la relación y
puede hacerlo cualquier número de veces.
Ejemplos de relaciones que expresan cardinalidad:
 Cada esposo (entidad) está casado (relación) con una única esposa (entidad) y viceversa. Es
una relación 1:1.
 Una factura (entidad) se emite (relación) a una persona (entidad) y sólo una, pero una persona
puede tener varias facturas emitidas a su nombre. Todas las facturas se emiten a nombre de
alguien. Es una relación 1:N.
 Un cliente (entidad) puede comprar (relación) varios artículos (entidad) y un artículo puede ser
comprado por varios clientes distintos. Es una relación N:M.
Atributos en relaciones [editar]
Las relaciones también pueden tener atributos asociados. Se representan igual que los atributos de
las entidades. Un ejemplo típico son las relaciones de tipo "histórico" donde debe constar una
fecha o una hora. Por ejemplo, supongamos que es necesario hacer constar la fecha de emisión
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 emisión" de la factura debería colocarse en la relación "se emite".

11. Herencia [editar]
La herencia es un intento de adaptación de estos diagramas al paradigma orientado a objetos. La
herencia es un tipo de relación 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 relación de herencia se representa mediante un
triángulo interconectado por líneas a las entidades. La entidad conectada por el vértice superior del
triángulo es la entidad "padre". Solamente puede existir una entidad "padre" (herencia simple). Las
entidades "hijo" se conectan por la base del triángulo.
Agregación [editar]
Ejemplo agregación
Es una abstracción a través de la cual las relaciones se tratan como entidades de un nivel más
alto. Se utiliza para expresar relaciones entre relaciones o entre entidades y relaciones. Se
representa englobando la relación abstraída y las entidades que participan en ella en un
rectángulo. En la figura se muestra un ejemplo de agregación en el que se representa la situación
en la que un profesor, cuando está impartiendo una clase, puede poner una incidencia ocurrida a lo
largo de ésta (se fue la luz, falta la configuración de un determinado software, etc.).
Modelo Relacional - PresentationTranscript
1. BASE DE DATOS (IV) Prof. Omar A. Rivera Zarate Instituto Superior Tecnológico Público “OXAPAMPA”
2. MODELO RELACIONAL
3. MODELO RELACIONAL
o Edgar Frank Codd a finales definió las bases del modelo relacional a finales de los 60.Trabajaba para IBM empresa
que tardó un poco en implementar sus bases. Pocos años después el modelo se empezó a implementar cada vez
más, hasta ser el modelo de bases de datos más popular.
4. OBJETIVOS DEL MODELO

12. o Independencia física . La forma de almacenar los datos, no debe influir en su manipulación lógica
o Independencia lógica . Las aplicaciones que utilizan la base de datos no deben ser modificadas por que se
modifiquen elementos de la base de datos.
o Flexibilidad . La base de datos ofrece fácilmente distintas vistas en función de los usuarios y aplicaciones.
o Uniformidad . Las estructuras lógicas siempre tienen una única forma conceptual (las tablas)
o Sencillez .
5. EVOLUCION DEL MODELO
o Año Hecho
o 1970 Codd publica las bases del modelo relacional
o 1971-72 Primeros desarrollos teóricos
o 1973-78 Primeros prototipos
o 1978 Aparece el lenguaje QBE
o 1979 Aparece Oracle
o 1980 Aparece Ingres
o 1981 Aparece SQL
o 1982 Aparece DB2
o 1986 ANSI normaliza el SQL (SQL/ANSI)
o 1987 SQL de ISO
o 1990 Versión dos del modelo relacional (RM/V2)
o 1992 SQL 92
o 1998 SQL 3
6. TABLAS
o Las bases de datos relacionales se basan en el uso de tablas (también se las llama relaciones ). 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 (se le llama también atributo ), nombre, dni, 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 ).
7. TABLAS
8. TERMINOLOGIA RELACIONAL
o Tupla. Cada fila de la tabla (cada ejemplar que la tabla representa)
o Atributo. Cada columna de la tabla

13. o Grado. Número de atributos de la tabla
o Cardinalidad. Número de tuplas de una tabla
o Dominio . Conjunto válido de valores representables por un atributo.
9. TIPOS DE TABLAS
o Persistentes. Sólo pueden ser borradas por los usuarios:
 Base . Independientes, se crean indicando su estructura y sus ejemplares.
 Vistas . Son tablas que sólo almacenan una definición de consulta, resultado de la cual se produce una tabla
cuyos datos proceden de las bases o de otras vistas e instantáneas. Si los datos de las tablas base cambian, los
de la vista que utiliza esos datos también cambia.
 Instantáneas . Son vistas (creadas de la misma forma) que sí que almacenan los datos que muestra, además
de la consulta que dio lugar a esa vista. Sólo modifican su resultado (actualizan los datos) siendo refrescadas
por el sistema cada cierto tiempo.
o Temporales . Son tablas que se eliminan automáticamente por el sistema. Pueden ser de cualquiera de los tipos
anterior.
10. DOMINIOS
o Los dominios suponen una gran mejora en este modelo ya que permiten especificar los posibles valores válidos
para un atributo. Cada dominio incorpora su nombre y una definición del mismo.
o Ejemplos de dominio:
o Dirección: 50 caracteres
o Nacionalidad: Español, Francés, Italiano,...
o Los dominios pueden ser también compuestos a partir de otros (año, mes y día = fecha)
11. CLAVES
o Clave candidata
o Conjunto de atributos de una tabla que identifican unívocamente cada tupla de la tabla.
o Clave primaria
o Clave candidata que se escoge como identificador de las tuplas.
o Clave alternativa
o Cualquier clave candidata que no sea primaria
o Clave externa o secundaria
o Atributo de una tabla relacionado con una clave de otra tabla.
12. VALORES NULOS

14. o Los valores nulos indican contenidos de atributos que no tienen ningún valor. En claves secundarias indican que el
registro actual no está relacionado con ninguno. En otros atributos indica que no se puede rellenar ese valor por la
razón que sea.
o Las bases de datos relacionales admiten utilizar ese valor en todo tipo de operaciones. Eso significa definir un
tercer valor en la lógica. Además de el valor verdadero o falso, existe el valor para los nulos.
13. LOGICA DEL VALOR NULO
o verdadero Y (AND) nulo da como resultado, nulo
o falso Y (AND) nulo da como resultado, falso
o verdadero O (OR) nulo da como resultado, verdadero
o falso O nulo da como resultado nulo
o la negación de nulo, da como resultado nulo
14. RESTRICCIONES
o Se trata de unas condiciones de obligado cumplimiento por los datos de la base de datos.
o Las hay de varios tipos.
o Inherentes
o Semánticas
15. RESTRICCIONES INHERENTES
o Son aquellas que no son determinadas por los usuarios, sino que son definidas por el hecho de que la base de datos
sea relacional.
o Por ejemplo:
o No puede haber dos tuplas iguales
o El orden de las tuplas no importa
o El orden de los atributos no importa
o Cada atributo sólo puede tomar un valor en el dominio en el que está inscrito
16. RESTRICCIONES SEMANTICAS
o El modelo relacional permite a los usuario incorporar restricciones personales a los datos. Las principales son:
o Clave primaria . Hace que los atributos marcados como clave primaria no puedan repetir valores.
o Unicidad . Impide que los valores de los atributos marcados de esa forma, puedan repetirse.
o Obligatoriedad . Prohíbe que el atributo marcado de esta forma no tenga ningún valor
o Integridad referencial . Prohíbe colocar valores en una clave externa que no estén reflejados en la tabla donde ese
atributo es clave primaria.

15. o Regla de validación. Condición que debe de cumplir un dato concreto para que sea actualizado.
17. LAS 12 REGLAS DE CODD
o Preocupado por los productos que decían ser sistemas gestores de bases de datos relacionales (RDBMS) sin serlo,
Codd publica las 12 reglas que debe cumplir todo DBMS para ser considerado relacional. Estas reglas en la práctica
las cumplen pocos sistemas relacionales.
18. LAS 12 REGLAS DE CODD
o 1. Información . Toda la información de la base de datos debe estar representada explícitamente en el esquema
lógico. Es decir, todos los datos están en las tablas.
o 2. Acceso garantizado . Todo dato es accesible sabiendo el valor de su clave y el nombre de la columna o atributo
que contiene el dato.
o 3. Tratamiento sistemático de los valores nulos . El DBMS debe permitir el tratamiento adecuado de estos valores.
o 4. Catálogo en línea basado en el modelo relacional. Los metadatos deben de ser accesibles usando un esquema
relacional.
19. LAS 12 REGLAS DE CODD
o 5. Sublenguaje de datos completo . Al menos debe de existir un lenguaje que permita el manejo completo de la base
de datos. Este lenguaje, por lo tanto, debe permitir realizar cualquier operación.
o 6. Actualización de vistas. El DBMS debe encargarse de que las vistas muestren la última información
o 7. Inserciones, modificaciones y eliminaciones de dato nivel. Cualquier operación de modificación debe actuar
sobre conjuntos de filas, nunca deben actuar registro a registro.
o 8. Independencia física. Los datos deben de ser accesibles desde la lógica de la base de datos aún cuando se
modifique el almacenamiento.
20. LAS 12 REGLAS DE CODD
o 9. Independencia lógica. Los programas no deben verse afectados por cambios en las tablas
o 10.Independencia de integridad. Las reglas de integridad deben almacenarse en la base de datos (en el diccionario
de datos), no en los programas de aplicación.
o 11.Independencia de la distribución. El sublenguaje de datos debe permitir que sus instrucciones funciones
igualmente en una base de datos distribuida que en una que no lo es.
o 12.No subversión . Si el DBMS posee un lenguaje que permite el recorrido registro a registro, éste no puede
utilizarse para incumplir las reglas relacionales.
21. PASO DEL ESQUEMA E/R AL MODELO RELACIONAL
o TRANSFORMACION DE ENTIDADES FUERTES
o En principio las entidades fuertes del modelo. Entidad Relación son transformados al modelo relacional siguiendo
estas instrucciones:
o Entidades. Las entidades pasan a ser tablas

16. o Atributos . Los atributos pasan a ser columnas.
o Identificadores principales . Pasan a ser claves primarias
o Identificadores candidatos . Pasan a ser claves candidatas.
22. PASO DEL ESQUEMA E/R AL MODELO RELACIONAL
23. TRANSFORMACION DE RELACIONES
o RELACION VARIOS A VARIOS
o En las relaciones varios a varios, la relación se transforma en una tabla cuyos atributos son: los atributos de la
relación y las claves de las entidades relacionadas (que pasarán a ser claves externas). La clave de la tabla la forman
todas las claves externas:
24. TRANSFORMACION DE RELACIONES
o RELACION VARIOS A VARIOS
25. TRANSFORMACION DE RELACIONES
o RELACIONES DE ORDEN N
o Las relaciones ternarias, cuaternarias y n-arias que unen más de dos relaciones se transforman en una tabla que
contiene los atributos de la relación más los identificadores de las entidades relacionadas. La clave la forman todas
las claves externas:
26. TRANSFORMACION DE RELACIONES
o RELACIONES DE ORDEN N
27. TRANSFORMACION DE RELACIONES
o RELACIONES DE UNO A VARIOS Y DE UNO A UNO
o Las relaciones binarios de tipo uno a varios no requieren ser transformadas en una tabla en el modelo relacional. En
su lugar la tabla del lado varios ( tabla relacionada) incluye como clave externa1 el identificador de la entidad del
lado uno ( tabla principal ):
28. TRANSFORMACION DE RELACIONES
o RELACIONES DE UNO A VARIOS Y DE UNO A UNO
29. TRANSFORMACION DE RELACIONES
o Así en el dibujo, el identificador2 en la tabla E ntidad1 pasa a ser una clave externa. En el caso de que el número
mínimo de la relación sea de cero (puede haber ejemplares de la entidad uno sin relacionar), se deberá permitir
valores nulos en la clave externa. Así en el dibujo, el identificador2 en la tabla E ntidad1 pasa a ser una clave
externa. En el caso de que el número mínimo de la relación sea de cero (puede haber ejemplares de la entidad uno
sin relacionar), se deberá permitir valores nulos en la clave externa
30. TRANSFORMACION DE RELACIONES
o RELACIONES RECURSIVAS

17. o Las relaciones recursivas se tratan de la misma forma que las otras, sólo que un mismo atributo puede figurar dos
veces en una tabla como resultado de la transformación:
31. TRANSFORMACION DE RELACIONES
o RELACIONES RECURSIVAS
32. TRANSFORMACION DE RELACIONES
o RELACIONES RECURSIVAS
33. TRANSFORMACION DE RELACIONES
o ENTIDADES DEBILES
o Toda entidad débil incorpora una relación implícita con una entidad fuerte. Esta relación no necesita incorporarse
como tabla en el modelo relacional. Sí se necesita incorporar la clave de la entidad fuerte como clave externa en la
entidad débil. Es más, normalmente esa clave externa forma parte de la clave principal de la tabla que representa a
la entidad débil.
34. TRANSFORMACION DE RELACIONES
o ENTIDADES DEBILES
35. TRANSFORMACION DE RELACIONES
o ENTIDADES DEBILES
o En ocasiones el identificador de la entidad débil es suficiente para identificar los ejemplares de dicha entidad,
entonces ese identificador quedaría como clave principal, pero el identificador de la entidad fuerte seguiría
figurando como clave externa en la entidad débil.