Niveles de un sgbd

En 1975, el comité ANSI-SPARC (American National Standard Institute - Standards Planning and Requirements Committee) 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

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 Computer Associates.

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

Ejemplo de diagrama E-R.

Un diagrama o modelo entidad-relación (a veces denominado por su siglas, E-R "Entity

relationship", 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

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.

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.

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]

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.

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.

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:

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".

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 - Presentation Transcript

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

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

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

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.

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

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

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.