You are on page 1of 7

BASE DE DATOS

Historia
Desde tiempos remotos, los datos han sido registrados por el hombre en algn tipo de soporte (papel, piedra, madera, etc.) a fin que quedara constancia de
un fenmeno o idea.
Los datos han de ser interpretados (incorporndoles significado) decimos, por ejemplo, que una persona ha nacido en 1965, el dato(1965) va acompaado
de su interpretacin (ao de nacimiento de una cierta persona); sin embargo, en la informtica, desde sus inicios, se separ el dato de su significado.
Por ello, a fin de facilitar la interpretacin de los datos, surgen los modelos de datos como instrumentos que ayudan a incorporar significado a los datos.
Segn FLORY (1982), modelar consiste en definir un mundo abstracto y terico tal que las conclusiones que se puedan sacar de el coincidan con las
manifestaciones aparentes del mundo real. Siendo un modelo un conjunto de conceptos que permite reconstruir una representacin organizacional de la
empresa.
Como sealan TSICHRITZIS Y LOCHOVSKY (1982), un modelo de datos es un dispositivo de abstraccin que nos permite ver el bosque (esto es, la
informacin contenida en los datos) en oposicin de los rboles (valores individuales de los datos).Segn el DRAE, la abstraccin es la accin y el efecto de
abstraer, "separar por medio de una operacin intelectual las cualidades de un objeto para considerarlas aisladamente o para considerar el mismo objeto en
su pura esencia o nocin". Por tanto, la abstraccin, como proceso mental capaz de ocultar detalles y fijarse en la esencia, busca las propiedades comunes de
un conjunto de objetos, reduciendo as la complejidad y ayudando la comprensin del mundo real.
Los modelos de datos proporcionan mecanismos de abstraccin que permiten la representacin de aquella parcela del mundo real cuyos datos nos interesa
registrar, lo que habitualmente se llama universo del discurso o en otras palabras de DITTRICH (1994) mini-mundo. Dicha interpretacin se concibe en dos
niveles: el de las estructuras que hacen posible la representacin de la informacin, y el de a informacin en s misma. Estos dos niveles dan lugar, en el
mbito de las bases de datos, a la distincin entre esquema y base de datos, conceptos que DITTRICH (1994) define como: "la descripcin especifica de un
mini-mundo determinado, en trminos, de un modelo de datos, recibe el nombre de esquema (esquema de datos o esquema de base de datos) de dicho minimundo.
La coleccin de datos que en si misma representa la informacin del mini-mundo da lugar a la base de datos. Asociados a los modelos de datos estn los
lenguajes de datos que permiten definir y manipular (consultar y actualizar) la base de datos. En lo que respecta a la relacin entre los modelos y los
lenguajes de datos, hay que destacar que los modelos son la base para que los lenguajes, aunque el nivel de abstraccin de estos ltimos es menor, ya que el
lenguaje es el modelo mas una sintaxis; por ejemplo, el lenguaje SQL es el resultado de aplicar una determinada sintaxis al modelo relacional, mientras que
el QUEL es otro lenguaje relacional que la sintaxis es distinta aunque el modelo sea el mismo; el OQL es el resultado de asociar a otro modelo (el modelo de
objetos - MO-).En la arquitectura de una base de datos propuesta por ANSI(1957) y (1978) se suele diferenciar tres niveles de abstraccin: Global, Externo
e Interno.
El nivel global contiene una representacin de un conjunto de los datos de una organizacin; en el nivel externo, los datos (en general, slo una parte de los
mismos) se describen para atender las necesidades de uno o varios procesos o de un grupo de usuarios en particular; el nivel interno describe las
caractersticas de los datos tal como han de encontrarse almacenados fsicamente, siendo sus elementos de descripcin punteros, ndices, agrupamientos,
ect.

Definicin
El trmino base de datos fue acuado por primera vez en 1963, en un simposio celebrado en California en 1967.- Codasyl, cambia su nombre por el de
Data Base Taskgroup . De forma sencilla podemos indicar que una base de datos no es ms que un conjunto de informacin relacionada que se encuentra
agrupada o estructurada.
El archivo por s mismo, no constituye una base de datos, sino ms bien la forma en que est organizada la informacin es la que da origen a la base de
datos. Las bases de datos manuales, pueden ser difciles de gestionar y modificar. Por ejemplo, en una gua de telfonos no es posible encontrar el nmero de
un individuo si no sabemos su apellido, aunque conozcamos su domicilio. Del mismo modo, en un archivo de pacientes en el que la informacin est
desordenada por el nombre de los mismos, ser una tarea bastante engorrosa encontrar todos los pacientes que viven en una zona determinada. Los
problemas expuestos anteriormente se pueden resolver creando una base de datos informatizada.
Codd, (1970), propone un modelo de datos basados en la Teora de las relaciones, donde los datos se estructuran lgicamente en forma de relaciones
(TABLAS), siendo un objetivo fundamental mantener la independencia de la estructura lgica respecto al modelo de almacenamiento y a otras
caracteristicas del tipo fisico.
Desde el punto de vista informtico, una base de datos es un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso
directo a ellos y un conjunto de programas que manipulan ese conjunto de datos.
Desde el punto de vista ms formal, podramos definir una base de datos como un conjunto de datos estructurados, fiables y homogneos, organizados
independientemente en mquina, accesibles a tiempo real, compartibles por usuarios concurrentes que tienen necesidades de informacin diferente y no
predecibles en el tiempo.La idea general es que estamos tratando con una coleccin de datos que cumplen las siguientes propiedades:

Estan estructurados independientemente de las aplicaciones y del soporte de almacenamiento que los contiene.

Presentan la menor rebundancia posible.

Son compartidos por varios usuarios y/o aplicaciones.

Independencia fisica .- Que el modo en que se almacenan los datos no influya en su manipulacin lgica, y por tanto, no sea
necesario modificar los programas por cambios en el almacenamiento fisico. (Codd concede mucha importancia a este aspecto
Independencia de ordenacin , independencia de indexacin e independencia en criterios de acceso ).

Independencia Lgica .- Que la modificacin de objetos en la base de datos no repercuta en los programas y/o usuarios que esten
accediendo al subconjunto parcial de la base de datos.

Flexibilidad .- Poder presentar a cada usuario los datos de la forma que prefiera.

Uniformidad.- Las estructuras logicas de datos presentan un estado uniforme.

Objetivos

Tipos de base de Datos


Base de datos relacionales
En una computadora existen diferentes formas de almacenar informacin. Esto da lugar a distintos modelos de organizacin de la base de datos: jerrquico,
red, relacional y orientada a objeto.
Los sistemas relacionales son importantes porque ofrecen muchos tipos de procesos de datos, como: simplicidad y generalidad, facilidad de uso para el
usuario final, perodos cortos de aprendizaje y las consultas de informacin se especifican de forma sencilla.
Las tablas son un medio de representar la informacin de una forma ms compacta y es posible acceder a la informacin contenida en dos o ms tablas.Las
bases de datos relacionales estn constituidas por una o ms tablas que contienen la informacin ordenada de una forma organizada. Cumplen las siguientes
leyes bsicas:

Generalmente, contendrn muchas tablas.

Una tabla slo contiene un nmero fijo de campos.

El nombre de los campos de una tabla es distinto.

Cada registro de la tabla es nico.

El orden de los registros y de los campos no est determinados.

El modelo relacional se divide en tres partes, las cuales se ocupan de la estructura, la integridad y la manipulacin de los datos respectivamente. Cada una de
las tres partes tiene sus propios trminos especiales:
Los trminos en cuestin son relacin, tupla, cardinalidad, atributo, grado, dominio y clave primaria.

Una relacin corresponde a lo que hasta ahora hemos llamado en general tabla.

Una tupla corresponde a una fila de esa tabla y un atributo a una columna.

El nmero de tuplas se denomina cardinalidad y el nmero de atributos se llama grado.

La clave primaria es un identificador nico para la tabla; es decir, una columna o combinacin de columnas con la siguiente
propiedad

nunca existen dos filas de la tabla con el mismo valor en esa columna o combinacin de columnas.

El dominio es una coleccin de valores, de los cuales uno o ms atributos (columnas) obtienen sus valores reales.

La nocin de "dominio" , en particular , nos sirve de inmediato para ilustrar una cosa muy importante no todos los sistemas relacionales se ajustan a todos
los aspectos del modelo relacional.

Trmino relacional formal

Equivalente informal

Relacin
Tupla
Cardinalidad
Atributo
Grado
Clave primaria
Dominio

Tabla
Fila o registro
Nmero de filas o registros
Columna o campo
Nmero de columnas o campos
Identificador nico
Fondos de valores legales

Trminos relacionales y equivalentes informale


DOMINIOS
El punto de partida para nuestro tratamiento formal de la estructura de datos relacional es la menor variedad semntica de informacin , la cual suponemos
es el valor de un dato individual( como el nmero de un proveedor o el peso de una parte o el nombre de una ciudad individual , etc)
Llamaremos a estos valores escalares. Los valores escalares representan la menor unidad semntica de informacin en el sentido de que son
atmicos; no poseen estructura interna. (es decir no se pueden descomponer) desde el punto de vista modelo.A continuacin, definimos un
dominio como un conjunto de valores escalares, todos del mismo tipo. Por ejemplo: el dominio de nmeros de proveedor es el conjunto de
todos los nmero de proveedor posibles, el dominio de cantidades de envo es el conjunto de todos los enteros mayores que cero y menores que
10,000 (digamos). As los dominios son fondos de valores de los cuales se extraen los valores reales que aparecen en los atributos. El nombre
de un atributo dado puede ser igual al del dominio correspondiente o puede ser un nombre distinto en los casos donde lo contario dara pie a
una ambigedad.
RELACIONES
Una relacin se compone de dos partes: cabecera (heading) y cuerpo (body). La cabecera es el conjunto de atributos (columnas) y el cuerpo es el conjunto
de tuplas (filas)en la tabla, la primera lnea (en negrita) es la cabecera y el resto de las filas el cuerpo.

ID
1
2
3
4
5

PROFESOR
Date
Miller
Booch
Sag
Sinclair

CURSO
Bases de datos
Intro Psicolingstica
Modelado semntico
HPSG
Lingstica de corpus

AO
1991
1994
1995
1994
1990

DEPARTAMENTO
Informtica
Psicolingstica
Informtica
Lingstica
Lexicografa

Tabla, cabecera, cuerpo


Una tabla y una relacin no son en realidad la misma cosa . Ms bien una relacin es una especie abstracta de objeto; y una tabla es una representacin
concreta de tal objeto abstracto. Las relaciones poseen ciertas propiedades, todas ellas consecuencia inmediata de la relacin.

En todo momento deberamos ser conscientes de que los elementos de una relacin, como ya mencionamos, no tienen orden alguno, lo cual se desprende del
hecho de que una relacin no es ms que un conjunto matemtico, con algunas diferencias que exponemos ms abajo. As, la tupla con ID 1 no es la
primera, ni la ID 5 la ltima, la numeracin de identificacin es totalmente aleatoria, normalmente el resultado de un campo contador.
Del mismo modo, los atributos tampoco tienen orden alguno; el hecho de que el atributo PROFESOR aparezca antes que el de CURSO en la sucesin de
columnas no tiene relevancia alguna para la relacin. Como hemos mencionado, el concepto matemtico de relacin, puede resultar muy poco intuitivo y,
como recuerda, no se adapta a las definiciones de "relacin" encontradas en los diccionarios. Se refiere a la propiedad de que una relacin unaria (de grado o
aridad uno), es una relacin en sentido pleno. As, una relacin matemtica de grado mayor que uno interrelaciona dos o ms objetos, mientras que una
relacin de grado uno no. El tratamiento de una relacin unaria es exactamente el mismo que el de una de mayor aridad.Por otra parte, el concepto de
relacin en el modelo relacional presenta algunas diferencias con respecto a su correspondiente matemtico. La siguiente tabla presenta estas diferencias de
forma esquemtica
Matemticas

Modelo relacional

Sin restricciones en el tipo de valores


Columnas sin nombre
Distincin de columnas individuales por su posicin
Normalmente constantes en el tiempo

Valores atmicos
Columnas con nombre
Distincin de columnas individuales por dominios y por nombres
Normalmente vara con el tiempo

Relaciones en Matemticas y en el Modelo Relacional


Adems de la caracterstica mencionada en cuanto a los tipos de valores, otra diferencia destacable (la tercera de las listadas en la tabla), es que mientras que
ninguno de los dos tipos de relaciones est ordenado en cuanto a sus elementos (tuplas), una relacin matemtica est ordenada en cuanto a sus atributos
(columnas), ya que stas se distinguen por su posicin. En el modelo relacional, al estar distinguidas por su nombre, su posicin es totalmente irrelevante.
Esta caracterstica no es casual, sino que su objetivo es facilitar las operaciones con los atributos de las relaciones.Finalmente, hemos de aclarar que
relaciones no slo son las "tablas" base de la base de datos, sino que tambin son los distintos tipos de relaciones que se pueden generar mediante consultas
a las relaciones base.
El modelo relacional ofrece una buena solucin a este problema, que nos permite reducir la redundancia de datos al mnimo y agilizar las operaciones de
consulta y actualizacin. Lo que deberamos hacer es separar la informacin que se refiere a las tres entidades que tenemos (profesores, cursos y
departamentos) en tres relaciones independientes, y despus relacionarlas entre s. Los recuadros indican relaciones base, mientras que las flechas indican las
interrelaciones entre ellas. Repetimos que estas interrelaciones, en realidad, no existen a nivel de la base de datos, se usan slo a nivel de representacin
grfica.Los nombres de algunos atributos (Prof_ID, Depto_ID, Curso_ID) sugieren el tipo de claves que hemos usado: claves subrogadas.

Ejemplo de disposicin relacional


A partir de estas tres relaciones, y mediante el mecanismo de comparacin de valores que antes mencionamos, se tiene acceso a toda la informacin que
deseamos sin redundancia alguna. Los "1" y "M" que etiquetan las flechas hacen referencia al tipo de interrelacin "uno a muchos": en la tabla PROFESOR
no hay valores repetidos para el atributo Prof_ID (existe un solo conjunto de atributos para describir un determinado profesor), pero encontraremos varios de
ellos en la tabla CURSO (un profesor puede dar varios cursos). Igualmente, un departamento consta de varios profesores. Las interrelaciones que hemos
mostrado en el grafico anterior son todas del mismo tipo: de uno a muchos (one-to-many). sta es la interrelacin ms frecuente. Adems tenemos las de:

Muchos a muchos (many-to-many): en una relacin de este tipo, la tabla A puede tener ms de un registro coincidente en la tabla B, y un registro
en la tabla B puede tener ms de un registro coincidente en la tabla A. Par detectar las relaciones "muchos a muchos" entre las tablas, es
importante observar la relacin en los dos sentidos. Este tipo de relacin requiere cambiar el diseo de la base de datos, ya que en realidad, es
decir, a nivel fsico, esto no es factible. La forma de implementar este tipo de interrelacin, es mediante una tercera tabla que sirva de puente
entre las dos. Esta tercera tabla contendr informacin procedente de las otras dos tablas interrelacionando los registros pertinentes. Veremos
algunas interrelaciones de este tipo en nuestra implementacin relacional del lexicn.

Uno a uno (one-to-one): en una relacin de este tipo, un registro en la tabla A no puede tener ms de un slo registro coincidente en la tabla B, u
viceversa. Este tipo de interrelacin es muy poco frecuente, ya que en la mayora de los casos la informacin de las dos tablas puede ser
combinada en una sola tabla. Tan slo es apropiado cuando el nmero de campos de la tabla B es muy alto y concerniente a un determinado tipo
de informacin. En estos casos es aconsejable tener esa informacin en una tabla separada.

Las interrelaciones de uno a muchos se implementan mediante el uso de claves ajenas, tambin llamadas externas o forneas (foreign keys). Una clave ajena
es un atributo (posiblemente indexado y posiblemente compuesto) de una relacin R2, cuyos valores han de concordar con los de alguna clave primaria en
otra relacin R1. R1 y R2 no han de ser necesariamente distintas.
Los atributos Prof_ID, en la tabla PROFESOR , Curso_IDen la tabla CURSO y Depto_IDen la tabla DEPTO, son claves primarias, mientras que los
atributos Prof_ID en la tabla CURSO y Depto_ID en la tabla PROFESOR, son claves externas.
TIPOS DE CLAVES.
1.

Clave candidata: Conjunto no vacio de atributos que identifican univoca y minimamente cada tupla.

2.

Clave primaria : La que el usuario escoge de las calves candidatas.

3.

Claves alternativas: Claves candidatas que no han sido escogidas.

4.

Clave ajena: Conjunto de atributos de la tabla cuyos valores han de coincidir con los de la clave primaria de otra tabla. (Clave ajena y primaria debe
estar definida sobre los mismos dominios).

TIPOS DE RELACION
Podemos distinguir los siguientes tipos de relaciones:

1.

Relaciones base o reales: es lo que corresponde al concepto de tabla. El conjunto de stas son las que componen la base de datos realmente.

2.

Conjunto dinmico de datos: no poseen datos almacenados propios y estn representadas nicamente dentro del sistema mediante su definicin en
trminos de otras relaciones (es decir, mediante consultas). Tambin conocidas como dynasets.

3.

Instantneas (snapshots): iguales que las anteriores, pero los datos que contienen no son virtuales, sino que estn realmente almacenados en la
instantnea. Se utilizan para manejar datos susceptibles de cambios.

4.

Resultados de consultas: la relacin resultante de consultar una o ms relaciones base.

5.

Resultados intermedios: el resultado de una operacin anidada en una consulta,


estos resultados son usados por la consulta externa para otra
operacin. La facilidad de anidar consultas dota de gran potencia al lenguaje de consulta relacional (SQL).

PROPIEDADES DE LAS RELACIONES


Las propiedades son cuatro dentro de una relacin dada:
1.- No existen tuplas repetidas.- Esta propiedad es consecuencia del hecho de que el cuerpo de la relacin es un conjunto matemtico( es decir, un conjunto
de tuplas) y en matemticas por definicin los conjuntos no incluyen elementos repetidos.
2.- Las tuplas no estn ordenadas (de arriba hacia abajo).- Esta propiedad sirve para ilustrar la diferencia entre una relacin y una tabla, porque las filas de
una tabla tienen un orden obvio de arriba hacia abajo, en tanto que las tuplas de una relacin carecen de tal orden.
3.- Los atributos no estn ordenados (de izquierda a derecha).- Esta propiedad desprende el hecho de que la cabecera de una relacin se define tambin como
conjunto. Las columnas de una tabla tienen un orden evidente de izquierda a derecha, pero los atributos de una relacin carecen de tal orden.
4.- Todos los valores de los atributos son atmicos.- Todos los valores de los atributos simples son atmicos.

LENGUAJE DE DESCRIPCION DE DATOS RELACIONAL.


Desde el punto de vista del usuario, las principales caracteristicas del lenguaje de definicin de datos son:
CREATE TABLE
ALTER TABLE
DROP TABLE
CREATE VIEW
DROP VIEW
CREATE INDEX
DROP INDEX

TABLA BASE: Una tabla base es un caso especial del concepto ms general de la tabla.
Definicin:Una tabla en un sistema relacional se compone de una fila de cabeceras de columna, junto con cero o ms valores de datos. Para una tabla dada:
a) La fila de cabeceras de columna especifica una o ms columnas.
b)Cada fila de datos contiene un valor escalar para cada una de las columnas especificadas en la fila de cabeceras de columna. Adems, todos los valores de
una columna dad tienen el mismo tipo de datos, a saber, el tipo especificado en la fila de cabeceras de columna para esa columna.
Algoritmos de Diseo del Modelo Relacional
Los algoritmos de normalizacin son herramientas de ayuda al diseo de base de datos relacionales y resultan especialmente tiles cuando se parte de la
relacin universal y se desea obtener esquemas normalizados. Originariamente surgieron como complemento de la teora matemtica del modelo
relacional y como solucin para obtener esquemas normalizados de una forma automtica. segn se han ido extendiendo los SGBD relacionales,
as como con la introduccin de herramienta CASE.
INTRODUCCION
El gran salto en la administracin de datos se produce con los sistemas relacionales, basados en el modelo relacional propuesto por Edgar Codd, de la IBM,
dado a conocer a travs de un famoso artculo de 1970. En lo fundamental, este modelo comparte muchos elementos.
El modelo relacional de base de datos, actualmente es el ms difundido de todos los aspectos de la teora y por tanto presente casi en cualquier sistema de
computo medianadamente desarrollado.
Dominio Conjunto de valores homogeneos y atomicos, caracterizados por un nombre. Todo dominio debe tener un nombre por el que referirnos a el y un
tipo de datos. Los dominios pueden definirse por intensin y por extensin.
Un atributo en el papel tiene un determinado dominio en la relacin.
En el UD de un base de datos, esta compuesto por un conjunto finito de relaciones. Cada atributo toma sus valores de un unico dominio y varios atributos
pueden tener el mismo dominio.

Extension, ocurrencia o instancia de la relacin.- conjunto de tuplas, que en una instante determinado satisface el esquema correspondiente.

RESTRICCIONES
INHERENTES.

No hay dos tuplas iguales.

el orden de las tuplas no es significativo.

El orden de los atributos no es significativo.

Cada atributo solo puede tomar un valor del dominio, no adminitiendose por tanto dos grupos repetitivos.

Se debe cumplir la regla de Integridad de entidad Ningn atributo que forme parte de la clave primaria de una relacin puede tomar un valor
desconocido o inexistente.

DE USUARIO.
Integridad referencial Si la relacin R2 tiene un descriptor que referencia a la clave primaria de la relacin R1 todo valor de dicha clave (Clave ajena R2)
debe concordar con los valores de la clave primaria R1 o ser NULO. R1 y R2 son claves necesariamente distintas. Adems, la clave ajena puede formar
parte de la relacin R2.
Tambien se deben definir las acciones a tomar en caso de acciones de modificacin y borrado :

Operacin RESTRINGUIDA .- Solo se puede borrar una fila de la tabla que tiene clave primaria referenciada si no existen filas con esa clave en
la tabla referenciada.

Operacin con transmisin en cascada.- El borrado o la modificacin de una fila de la tabla que contiene la clave primaria lleva consigo la
modificacin de las tablas cuya clave ajena coincida con la clave primaria modificada.

Operacin con puesta a nulos.- El borrado o la modificacin de una fila de la tabla que contiene la tabla primaria lleva consigo la puesta nulos de
los valores de la clave ajena de las filas de la tabla que referencia cuya clave coincida con el valor de la clave primaria de la tabla referenciada.

Otra restricciones.-

Definir predicados sobre :

Atributo de una relacin.

Tuplas de una relacin.

Atributos de varias relaciones.

Dominios.

Evaluacin de restricciones.

Con cada operacin

Diferido.

TRANSFORMACION DEL MODELO E/R AL MODELO RELACIONAL.


Tres principios :
1.

Toda entidad se transforma en una tabla.

2.

Toda interrrelacin M :N se transforma en una tabla.

3.

Toda interrrelacin del tipo 1 :N se traduce en el fenomeno de propagacin de calve o se crea una nueva tabla.

Reglas de transformacin del Modelo Bsico.


Transformacin de Dominios .- Hay sistemas relacionales que no lo permiten.
Trans. de entidades .- Toda entidad se tranforma en una tabla.
Transformacin de atributos .- Cada atributo de una entidad se transforma en una columna de la tabla.
AIP Clave primaria de la relacin.
Transformacin interrelaciones .- Segn tipo :
N :M Se transforma en una nueva tabla cuyos atributos son la concatenacin de los AIP de las entidades que asocian.

Cada uno de estos atributos es clave ajena de la tabla donde estos atributos son clave primaria.

CLAVE AJENA ()
REFERENCIA TABLA ()
TABLA ESCRIBE (Cod_Libro, Nombre)
CLAVE PRIMARIA (Cod_Libro, Nombre)
CLAVE AJENA (Cod_Libro)
REFERENCIA TABLA LIBRO

EN BORRADO : CASCADA
EN ACTUALIZACION : CASCADA
CLAVE AJENA (Nombre)
REFERENCIA TABLA AUTOR
EN BORRADO : NULOS
EN ACTUALIZACION : CASCADA
1 :N Dos soluciones :
A:Propagacin :
Propaga AIP de entidad con cardinalidad Maxima 1
Perdida de semantica
A:Considerarla como una relacin M :_N
Cuando A y cuando B ?

Si la relacin al final resultar una M :N mejor B

Si hay atributos propios en la relacin B

Si el n de ocurrencias interrlacionadas de la entidad que produce la clave es pequea o bien la cardinalidad minima es 0 (Nulos ) B

Perdida de semantica en cardinalidades :


a.

Cardinalidad maxima (Predicados)

a.

cardinalidad minima (Tabla distinta para la relacin ) Predicado

a.

Car minima Pro do claves (Permitir NULOS en clave ajena)

1 :N) Maximo es conocido (En tablas se permite limitar el nmero de filas)

Interrelaciones 1 :1

Caso particular de las relaciones 1 : y M :N

No existe una regla fija para su transformacin , pudiendose crear una tabla nueva o propagar la clave. En este ltimo caso, la
propagacin de la clave puede realizarse en ambas direcciones.

Criterios para la seleccin de una solucin :

Cardinalidad minima.

Semantica

Eficiencia (Nulos o no Nulos / Accesos ms frecuentes)

Si la cardinalidad es (0,1) en ambas entidades la interrelacin se transforma en una nueva tabla.

Si la cardinalidad de una de ellas es (0,1) y la otra es (1,1) conviene propagarla la clave de la entidad con cardinalidad (1,1) a la tabla resultante
de la entidad con cardinalidad (0,1)

Si en ambas la cardinalidad es (1,1) se puede propagar clave en ambos sentidos o incluso propagar ambas claves.

Solucin en el modelo Relacional.


Ej 1
EMPLEADO (Cod_emp, .....)
DEPARTAMENTO (Cod_Dep, ......., Cod_emp)
Ej 2.MATRIMONIO ( Cod_H, Cod_ M)
HOMBRE (Cod_H , .....)
MUJER (Cod_M, .....)
Caso 1 : 1 Cardinalidades en ambos (1,1) , (1,1)

Propagar las dos entidades.

Accesos ms frecuentes (Primar estos accesos)

Transformacin de los atributos de interrelaciones.

Si la interrelacin se transforma en una relacin , todos sus atributos pasan a ser columnas de la relacin .

Si se transforma mesiante propagacin de clave, sus atributos migran junto con la clave de la relacin correspondiente, aunque suele ser mejor
crear una nueva tabla para realizar esta migracin de la interrelacin con sus atributos.

Transformacin de restricciones de usuario.

Se aaden como predicados al definir las tablas.

Tipos :

Comprobacin del rango de valores de los atributos.

Especificar todos los valores posibles de un atributo

Comprobar un predicado. (Ej : sobre valor de un atributo).

NOTACION :

RANGO ENTRE < Intervalo (Valores)>

EN < conjunto de valores>

COMPROBAR (, )

TRANSFORMACION DE REGLAS DEL MODELO EXTENDIDO.


Transformacin de dependencias en identificacin y en existencia.
(*) No reflejado por el modelo realcional

Utilizar el mecanismo de propagacin de clave, creando una clave ajena con NULOS no permitidos en la tabla de la entidad
dependiente, obligando a la modificacin y borrado en cascada.

si la dependencia es en identificacin la clave primaria de la tabla de al entidad debil, debe estar formada por la concatenacin de las
claves de las dos entidades que participan en la interrelacin.

SOLUCION (Ej)
TABLA LIBRO (Cod_ Libro, ...............)
CLAVE RPIMARIA (Cod_Libro)
TABLA EJEMPLAR (Cod_Libro ; Cod _ Ejem, ..........)
CLAVE PRIMARIA ( Cod_Libro, Cod_ejem)
CLAVE AJENA (Cod_Libro)
REFERENCIA A TABLA LIBRO
EN BORRADO : CASCADA
EN MODIFICACION : CASCADA
Relaciones exclusivas

En cada caso segn su semantica.

Edita 1 EXCLUYE Edita 2

Pro do claves :

TABLA LIBRO (Cod_Libro, CodEd, Cod_Univ.......)


CLAVE PRIMARIA ( Cod_libro)
CLAVE AJENA ( CodEd)
REFERNCIA A TABLA EDITORIAL
EN BORRADO : CASCADA
EN ACTUALIZACION : CASCADA
CLAVE AJENA( Cod_Univ)
REFERNCIA TABLA UNIVERSIDAD
EN ACTUALIZACION Y BORRADO : CASCADA
COMPROBACION [ (CodEd == NULO ) y ( Cod_univ != NULO)] o
[ (CodEd != NULO) y( COD_univ == NULO)]
Transformacin de TIPOS y SUBTIPOS.

No esta recogido directamente en el modelo Relacional.

Se pierde semantica.

Opciones :

A:Una tabla que englobe los atributos del supertipo y de los subtipos.

Cuando los subtipos se diferencian en muy pocos atributos

Las interrelaciones que les asocian con otras entidades sean las mismas parta todos los subtipos.

Se debe aadir a la tabla un atributo adicional. (DISCRIMINANTE).

A:Una sola tabla para el Supertipo y tantas tablas como subtipos haya con sus atributos correspondientes.

Cuando existen atributos diferentes en los subtipos y se quieren mantener los atributos comunes en una tabla.

Tablas distintas para cada subtipo que tengan adems los atributos comunes Cuando existan atributos distintos entre los
subtipos

Cuando los acceso realizados a los datos de lossubtipos siempre afectan a los
*atributos comunes.
Evaluacin de eficiencia.
A.

Acceso a una fial que refleje todos los datos de una entidad es mucho ms rapido.

B.

Mejor desde punto de vista semantico.

C.

Aumenta eficiencia en determinadas consultas. Se produce redundancia y perdida de semantica.

Dimensin Temporal.
OBS Puede ocurrir.

Atributo temporal forma parte de las claves. (Fecha diferencia una ocurrencia de otras)

Atributos derivados.
No hay representacin directa.
Opciones :
a.Considerarlo una columna ms :

Procedimientos para recalcular valores cada vez que se modifique la tabla.

a.Disparadores .- Sin columnas en las tablas. Procedimientos que calculan los datos en el momento en que se piden.

You might also like