sábado, 28 de septiembre de 2013

OPTIMIZACIÓN DEL DISEÑO DE BASES DE DATOS RELACIONALES.

OPTIMIZACIÓN DEL DISEÑO DE BASES DE DATOS RELACIONALES.

Hechos/conceptos (contenidos soporte)
ü  Problemas que puede presentar el diseño de una base de datos relacional. Anomalías de Codd (inserción, actualización y borrado).

ü  Normalización. Necesidad de su utilización. Formas normales de Codd: primera forma normal (condiciones que debe cumplir la relación para estar en primera forma normal, paso a primera forma normal), segunda forma normal (condiciones que debe cumplir la relación para estar en segunda forma normal, paso a segunda forma normal), tercera forma normal  (condiciones de transformación de las relaciones a tercera forma normal), proceso de transformación de las relaciones a tercera forma normal. Forma normal de Boyce-Codd (condiciones que debe cumplir la relación para estar en la forma  normal de Boyce-Codd, paso a la forma normal de Boyce-Codd). Algoritmo de descomposición. Otras  formas normales.



Anomalías de Codd

5.-TEORIA DE LA NORMALIZACION
Cuando se diseña una base de datos mediante el modelo relacional, al igual que ocurre en otros modelos de datos, tenemos distintas alternativas, es decir, podemos obtener diferentes esquemas relacionales y no todos son equivalentes, ya que algunos van a representar la realidad mejor que otros.
Es necesario conocer qué propiedades debe tener un esquema relacional para representar adecuadamente una realidad y cuáles son los problemas que se pueden derivar de un diseño inadecuado.
La teoría de la Normalización es un método objetivo y riguroso que se aplica en el diseño de bases de datos relacionales.
Cuando estudiamos la estructura del modelo relacional, nos dimos cuenta que la base de datos puede representarse por medio de un conjunto de objetos (dominios y relaciones) y de un conjunto de reglas de integridad.
El esquema relacional puede obtenerse de dos formas distintas:
  • Directamente a partir de la observación de nuestro universo del discurso, en donde especificamos conjuntos de atributos, relaciones y restricciones que corresponden a los observados en el mundo real.
  • Realizando el proceso de diseño en dos fases, primero el diseño conceptual (E/R) obteniendo el esquema conceptual y posteriormente transformar éste a un esquema relacional, siguiendo algunas reglas generales, que fueron dadas anteriormente.
Algunos problemas que se pueden presentar son:
  • Incapacidad para almacenar ciertos hechos
  • Redundancias y por tanto, posibilidad de incoherencias
  • Ambigüedades
  • Pérdida de información (aparición de tuplas espúreas)
  • Pérdida de dependencias funcionales, es decir, ciertas restricciones de integridad que dan lugar a interdependencias entre los datos.
  • Aparición en la BD de estados no válidos, es decir, anomalías de inserción, borrado y modificación.
En conclusión el esquema relacional obtenido debe ser analizado para comprobar que no presenta los problemas anteriores.
Analicemos la siguiente relación: ESCRIBE
AUTORNACIONALIDADCOD_LIBROTITULOEDITORIALAÑO
Date, C.Norteamericana98987DatabaseAddison1990
Date, C.Norteamericana97777SQL StanAddison, W.1986
Date, C.Norteamericana98987Guide forAddison, W.1988
Codd,E.Norteamericana7890RelationalAddison,W.1990
GardarinFrancesa12345Basi DatiParaninfo1986
GardarinFrancesa67890Comp BDEyrolles1984
ValduriezFrancesa67890Comp BDEyrolles1984
Kim,W.Norteamericana11223BD OOACM1989
LochovskyCanadiense11223BD OOACM1989

Esta relación almacena datos de autores y de libros.
Algunos problemas son:
  • Redundancia, ya que la nacionalidad del autor se repite por cada ocurrencia del mismo. Lo mismo sucede cuando un libro tiene mas de un autor, se repite la editorial y el año de publicación.
  • Anomalías de modificación, es fácil cambiar el nombre de una editorial en una tupla sin modificar el resto de las que corresponden al mismo libro, lo que da lugar a incoherencias.
  • Anomalías de inserción, ya que si queremos ingresar información de algún autor, del que no hubiera ningún libro en la base datos, no sería posible, ya que cod_libro es parte de la clave primaria de la relación (regla de integridad de la entidad). La inserción de un libro, que tiene dos autores obliga a insertar dos tuplas en la relación.
  • Anomalías de borrado, ya que si queremos eliminar un cierto libro, deberíamos perder los datos de su autor y viceversa.
En los casos anteriores, se deja en manos del usuario manejar la integridad de la base de datos.
Lo anterior sucede pues no se cumple un hecho básico de todo diseño:
"hechos distintos, deben almacenarse en objetos distintos"
Una forma de evitar este tipo de problemas consiste en seguir la metodología propuesta en el curso, es decir, un riguroso diseño conceptual y un traspaso de éste al modelo relacional.
Sin embargo, ante posibles dudas respecto a si un esquema relacional está correcto, aplicaremos a dicho esquema un método formal de análisis, que permita analizar errores y generar esquemas correctos. Esta es la teoría de la normalización.
En el ejemplo anterior, el conjunto de las siguientes relaciones no presenta estos problemas:
LIBRO( cod_libro, titulo, editorial, año )
AUTOR( nombre, nacionalidad )
ESCRIBE( cod_libro, nombre )
La normalización introduce una técnica formal para diseñar bases de datos relacionales, y permite mecanizar parte del proceso al disponer de algoritmos de normalización.
Una observación importante, es que las anomalías antes descritas se producen en procesos de actualización y no en procesos de consulta. La normalización penaliza las consultas, al disminuir la eficiencia, ya que la normalización aumenta el nro. de relaciones presentes en la base de datos, por lo que una determinada consulta puede llevar consigo el acceso a varias tablas, lo que aumenta el costo de ésta.

5.1.-Noción intuitiva de las formas normales
La normalización tiene como objetivo obtener esquemas relacionales que cumplan determinadas condiciones, a través de las formas normales.
Primera Forma Normal (1FN) fue introducida por Codd, en su primer trabajo. Es una restricción inherente al modelo relacional por lo que su cumplimiento es obligatorio. Consiste en la prohibición de que en una relación existan grupos repetitivos, es decir, un atributo no puede tomar más de un valor del dominio subyacente.
Segunda Forma Normal (2FN), fue introducida por Codd. Una relación está en 2FN, si además de estar en 1FN, todos los atributos que no forman parte de ninguna clave candidata suministran información acerca de la clave completa.
Para la relación PRESTAMO( num_socio, nombre_socio, cod_libro, fec_prest, editorial, país )
las claves candidatas son:
(num_socio, cod_libro) y (nombre_socio, cod_libro)
Se puede observar que ciertos atributos que no forman parte de las claves candidatas, tal como editorial, constituye información acerca del libro, pero no acerca de la clave completa. Luego, la relación préstamo no se encuentra en 2FN.
La solución es descomponer esta relación en las siguientes:
PRESTAMO1( num_socio, nombre_socio, cod_libro, fec_prest )
LIBRO( cod_libro, editorial, país )
En la relación PRESTAMO1, el único atributo que no forma parte de las claves candidatas es fec_prest, pero suministra información acerca de la clave completa. Por lo que está en 2FN.
La relación LIBRO, la clave es cod_libro, y los dos atributos: editorial y país suministran información de la clave completa. Por lo tanto, está en 2FN.
OBS: Una relación que está formada por un único atributo esta en 2 FN.
Tercera Forma Normal (3FN), propuesta por Codd. Una relación está en 3FN, si además de estar en 2FN, los atributos que no forman parte de ninguna clave candidata facilitan información sólo acerca de la(s) clave(s) y no acerca de otros atributos.
En la relación PRESTAMO1, el atributo fec_prest facilita información acerca de las claves, ya que no existen más atributos. Por lo que está en 3FN.
En la relación LIBRO, el atributo país entrega información acerca de la editorial que publica el libro, por lo que no está en 3FN.
La solución es descomponerla en:
LIBRO1( cod_libro, editorial )
EDITORIAL( editorial, país ),
que están en 3FN, ya que todo atributo no clave facilita información acerca de la clave.
Forma Normal de Boycce y Codd (FNBC). La relación PRESTAMO1, que está en 3FN, todavía presenta anomalías, ya que num_socio nombre_socio, se repiten innecesariamente por cada cod_libro. Una relación está en FNBCsi y solo si, el conocimiento de las claves candidatas permite averiguar todas las interrelaciones existentes entre los datos de la relación, o lo que es igual, las claves candidatas son los únicos descriptores sobre los que se facilita información por cualquier otro atributo.
En la relación PRESTAMO1num_socio es información acerca de nombre_socio y viceversa. Ninguno de estos atributos son clave (aunque formen parte de la clave). Para solucionarlo la descomponemos:
SOCIO( num_socio, nombre_socio )
PRESTAMO2( num_socio, cod_libro, fec_prest ), que están en FNBC.
Hasta ahora nuestro esquema relacional está compuesto por las siguientes relaciones en FNBC:
LIBRO1( cod_libro, editorial )
EDITORIAL( editorial, país )
SOCIO( num_socio, nombre_socio )
PRESTAMO2( num_socio, cod_libro, fec_prest )
La teoría de la normalización se basa en restricciones definidas sobre los atributos de una relación. que son conocidas como dependencias. Existen varios tipos de dependencias:
  • Funcionales, relacionadas con la 2FN 3FN FNBC
  • Multivaluadas, relacionadas con la 4FN
  • De proyección o combinación, relacionadas con la 5FN.

5.2.-Dependencias funcionales
Sea el esquema de relación R definido sobre el conjunto de atributos A y sean X e Y subconjuntos de A llamados descriptores. Se dice que Y depende funcionalmente de X o que X determina o implica a Y, que se representa por® Y, si solo si, cada valor de X tiene asociado en todo momento un único valor de Y.
ej: cod_libro ® titulo, el código del libro determina el titulo. El cod_libro es el implicante y titulo es el implicado. Siempre el implicado es un hecho (una información) acerca del implicante.
OBS1: la afirmación cod_libro determina titulo NO significa que a partir de cod_libro podamos conocer el titulo. Es decir, para un esquema R, si tenemos la dependencia funcional ® Y, dado un valor de no podemos en general conocer el valor de Y. Solo nos limitaremos a firmar que para dos tuplas de cualquier extensión de que tengan el mismo valor de X, el valor de también será igual en ambas.
OBS2: Las dependencias son predicados o restricciones sobre cualquier extensión válida del esquema de relación, por lo que observar una determinada extensión (datos) no puede llevarnos a afirmar la existencia de una dependencia funcional.
5.2.1.-Dependencia funcional completa
Si el descriptor X es compuesto, es decir, X(X1, X2), se dice que Y tiene dependencia funcional completa de X, si depende funcionalmente de X, pero no depende de ningún subconjunto del mismo, esto es:
® Y
X1 ® | Y
X2 ® | Y. Se representa Þ Y.
Þ Y si y solo si NO $ X’ Ì X / X’ ® Y.
Ejemplos:
La relación PUBLICA( articulo, revista, numero, pagina ), que representa la pagina inicial en la que comienza un articulo en una revista. Un mismo articulo puede aparecer publicado en distintas revistas y en cada una de ellas, en paginas distintas y una revista publica varios artículos, se tiene:
articulo, revista, numero ® pagina
articulo ® | pagina
revista ® | pagina
numero ® | pagina
5.2.2.-Dependencia funcional trivial
Una dependencia funcional ® Y es trivial si Y es un subconjunto de X (Y Í X).
Ejemplos:
cod_libro ® cod_libro
articulo, revista ® revista.
5.2.3.-Dependencia funcional elemental
Solo las dependencias elementales son útiles en la normalización.
Una dependencia funcional ® Y es elemental si Y es un atributo único, no incluido en X y no existe X’ incluido en tal que X’ ® Y, es decir, la dependencia funcional elemental es un dependencia funcional completa no trivial, en la que el implicado es un atributo único.
5.2.4.- Dependencia funcional transitiva
Sea la relación R( X,Y,Z ), en la que existen las siguientes dependencias funcionales:
® Y, ® Z y ® | X, se dice que tiene dependencia transitiva respecto a X, a través de Y.
ej: LIBRO_ED( codlibro, editorial, país )
La dependencia entre codlibro país es transitiva, a través de editorial. Intuitivamente se interpreta como que PAIS es una información del libro, pero indirectamente, ya que es una información de EDITORIAL y esta a su vez de LIBRO.
5.3.-Teoría formal de la Normalización
Dado un conjunto de atributos A y un conjunto de dependencias entre ellos, D, que constituyen un esquema de relación R(A,D) (esquema origen), se trata de transformar este esquema original en un conjunto de n esquemas de relación Ri(Ai,Di), i=1,n (esquemas resultantes), que cumplan determinadas características.
Estas son:
  • Conservación de la información
  • Conservación de las dependencias
  • Normalización de las relaciones

5.3.1.-Conservación de la información
Se debe cumplir:
Conservación de los atributos
U Ai = A, i=1, n.
Conservación del contenido (las tuplas)
Para toda extensión r de R, la combinación (join) de las relaciones resultantes ha de producir la relación origen, es decir,
* ri = r, i=1,n.
Si el proceso de normalización no se lleva a cabo correctamente , pueden aparecen nuevas tuplas que no estaban en la relación origen. Estas se llaman tuplas espúreas, que falsean el contenido de la base de datos.
Ejemplo: Dada la relación original
 
LIBRO(COD_LIBRO, EDITORIAL, PAIS)
COD_LIBROEDITORIALPAIS
9030
RAMA ESPAÑA
9110
RAMAESPAÑA
9040
PARANINFOESPAÑA
9234
ANAYAESPAÑA
9567
ADD.WESUSA
y las relaciones resultantes:
 
LIBRO1(COD_LIBRO, PAIS)
COD_LIBROPAIS
9030 ESPAÑA
9040 ESPAÑA
9110 ESPAÑA
9234 ESPAÑA
9567USA

EDITORIAL(EDITORIAL, PAIS)
EDITORIALPAIS
RAMA ESPAÑA
RAMAESPAÑA
PARANINFOESPAÑA
ANAYAESPAÑA
ADD.WESUSA

LIBRO1 * EDITORIAL
COD_LIBROEDITORIALPAIS
9030RAMA ESPAÑA
9030PARANINFOESPAÑA
9030 ANAYAESPAÑA
9040RAMAESPAÑA
9040PARANINFOESPAÑA
9040 ANAYAESPAÑA
9010RAMAESPAÑA
9110 PARANINFOESPAÑA
9010ANAYAESPAÑA
9234 RAMAESPAÑA
9234 PARANINFOESPAÑA
9234ANAYAESPAÑA
9567 ADD.WESUSA

En negrita, tuplas espúreas.
5.3.3.-Definición formal de la tres primeras formas normales
Primera Forma Normal: equivalente a la definición dada antes
Segunda Forma Normal:
  • Está en 1FN
  • Cada atributo no principal tiene dependencia funcional completa respecto de cada una de las claves.
ejemplo: La relación
PUBLICA2( articulo, revista, numero, pagina, editorial )
que refleja en qué numero de qué revista se publica un artículo, en qué pagina comienza y cuál es la editorial.
Tenemos las siguientes dependencias:
articulo, revista, numero ® pagina
revista ® editorial
clave:(articulo, revista, numero)
Esta relación no esta en 2FN, ya que editorial depende de la revista y tiene redundancia, pues se repite la editorial para cada articulo que se publica en una revista.
Tercera Forma Normal:
  • Está en 2FN
  • Ningún atributo no principal depende transitivamente de ninguna clave de la relación
Ejercicio:
R( estudiante, nro_matricula,curso,centro, profesor, texto ), con las restricciones:
  • Un estudiante puede estar matriculado en varios cursos
  • Un estudiante tiene un numero de matrícula distinto para cada curso en el que está matriculado
  • Un curso se imparte en un solo centro
  • El número de matrícula identifica al centro en el que se imparte el curso y al curso mismo
  • Un curso es impartido por un solo profesor, pero un profesor puede impartir varios cursos
  • Un curso se apoya en distintos textos y un mismo texto puede servir de soporte a varios cursos.
Reducir el esquema anterior a un conjunto equivalente de relaciones en FNBC
Las dependencias funcionales se relacionan con el modelado relacional de interrelaciones 1:N y 1:1.
5.4.- Dependencias Multivaluadas y 4FN
Las dependencias multivaluadas son una generalización de las dependencias funcionales. En éstas un conjunto de valores del implicado, son determinados por un implicante. Esta situación aparece cuando existen grupos repetitivos.
Ej: la siguiente tabla
 
AUTORES
AUTORMATERIAINSTITUCION
DateLenguaje SQL; Diseño BDRelational Inst.; Codd& Date Cons.
UllmanDiseño BD; Bases Conc.Stanford Univ.

La tabla no cumple la 1FN.
La normalización de esta tabla produce la siguiente:
 
AUTORES
AUTORMATERIAINSTITUCION
Date Lenguaje SQLRelational Inst
Date Lenguaje SQLCodd& Date Cons
Date Diseño BDCodd& Date Cons
Date Diseño BDRelatinal Inst.
UllmanDiseño BD Stanford Univ.
UllmanBases Conc. Stanford Univ

Esta tabla normalizada presenta gran cantidad de redundancia. La clave es el conjunto de los 2 atributos. Por lo que está en FNBC.
En ella tenemos que un autor multidetermina a materia y un autor multidetermina a institución.
Las dependencias multivaluadas se producen cuando existen interrelaciones N:M independientes entre si. Entre autor y materia hay una interrelación N:M y también entre autor e institución y materia e institución son independientes.
Definición Dependencia Multivaluada.
Fagin (1977). La dependencia multivaluada se denota ®® Y, y se lee multidetermina a Y, y significa que implica un conjunto de valores de Y con independencia de los demás atributos de la relación.
Las dependencias multivaluadas dependen del contexto, es decir influye el resto de los atributos de la relación.
Si agregamos un atributo a AUTORES, departamento, que nos indica el departamento de una institución en el que se trabaja en una cierta materia, obteniendo:
 
AUTORMATERIAINSTITUCIONDEPTO
Date Lenguaje SQLRelational Inst.Lenguajes
Date Lenguaje SQLCodd& Date Cons.Bases de Datos
Date Diseño BD Codd& Date Cons.Analisis
DateDiseño BD Relatinal Inst.Bases de Datos
UllmanDiseño BDStanford Univ.Lenguajes
UllmanBases ConcStanford Univ.Inteligencia Artificial

Aquí, la dependencia autor®® materia no se cumple, porque depende del contexto ( de depto).
Cuarta Forma Normal (4 FN)
Una relación se encuentra en 4FN, si y solo si, las únicas dependencias multivaluadas no triviales son aquellas en las cuales una clave multidetermina un atributo, es decir, toda dependencia multivaluada viene determinada por una clave candidata.
En la tabla AUTORES(autor, materia, institución), existen las dependencias multivaluadas:
autor ®® materia y autor ®® institución. La relación no se encuentra en 4FN, ya que estas dependencias están implicadas por autor, que no es clave candidata. La clave candidata es el conjunto de los tres atributos.
Para normalizarla se descompone en 2 proyecciones:
AUTORES1(autor, materia)
AUTORES2(autor,institucion), que si están en 4FN.
Revisar la 5FN en libros.

5.6.-Organización de Relaciones
- estructuración (consideraciones lógicas)
  • Normalización
  • Particionamiento horizontal
- reestructuración (consideraciones físicas)
  • Desnormalización
  • Particionamiento (horizontal, vertical)
Particionamiento Horizontal de relaciones
Esta estructuración permite eliminar valores nulos, debido en general a no haberse detectado los subtipos de una entidad o haberlas reunido en una sola entidad.
DOCUMENTO(cod-doc, titulo, idioma, editorial)
Que almacena datos de libros y artículos. El atributo editorial es inaplicable a articulo, podríamos descomponer la relación en:
LIBRO(cod-doc, titulo, idioma, editorial)
ARTICULO(cod-doc, titulo, idioma)
Relación origen pasa por selección a una que tiene todos los atributos que la original, pero contiene valores conocidos junto con otra a través de selección que contiene solo los atributos no nulos, eliminando el atributo de la relación origen que tenia nulos (proyección).
La construcción de la relación original se realiza por medio de la unión relacional, después de añadir los atributos para que sean compatibles en la unión.
Desnormalizacion y Particionamiento
Son métodos o formas de organizar las relaciones, teniendo en cuenta razones de tipo físico:
  • Tasa de actualizaciones versus consultas
  • Las veces que se accede conjuntamente a los atributos
  • El tamaño en bytes de los atributos
  • Tipos de proceso (en linea-batch)
  • Prioridad de los procesos
  • Tamaño de las tablas.








Bases de datos relacionales /AXIOMAS DE AMSTRONG

Hechos/conceptos (contenidos soporte)
ü  Bases de datos relacionales. Antecedentes históricos. Fundamentos. Características. Conceptos básicos (tablas, atributos, tuplas, dominio, grado, cardinalidad, claves, asociaciones de relaciones, claves ajenas, reglas de integridad, definición de las relaciones: por  Extensión y por comprensión).

ü  Requisitos que deben cumplir las tablas para ser relaciones. Esquemas y subesquemas. Dependencias funcionales (parciales, completa y transitiva).

ü  Axiomas de Armstrong. Eliminación de dependencias redundantes. Obtención de claves.

Base de Datos Relacional 


Una base de datos relacional es una base de datos que cumple con el modelo relacional, el cual es el modelo más utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San José (California), no tardó en consolidarse como un nuevo paradigma en los modelos de base de datos.


Características 
  • Una base de datos relacional se compone de varias tablas o relaciones.
  • No pueden existir dos tablas con el mismo nombre.
  • Cada tabla es a su vez un conjunto de registros, filas o tuplas.
  • Cada registro representa un objeto del mundo real.
  • Cada una de estos registros consta de varias columnas, campos o atributos.
  • No pueden existir dos columnas con el mismo nombre en una misma tabla.
  • Los valores almacenados en una columna deben ser del mismo tipo de dato.
  • Todas las filas de una misma tabla poseen el mismo número de columnas.
  • No se considera el orden en que se almacenan los registros en las tablas.
  • No se considera el orden en que se almacenan las tablas en la base de datos.
  • La información puede ser recuperada o almacenada por medio de sentencias llamadas «consultas».
Elementos 
Relaciones base y derivadas 
En una base de datos relacional, todos los datos se almacenan y se acceden a ellos por medio de relaciones. Las relaciones que almacenan datos son llamados "relaciones base" y su implementación es llamada "tabla". Otras relaciones no almacenan datos, pero que son calculadas al aplicar operaciones relacionales. Estas relaciones son llamadas "relaciones derivadas" y su implementación es llamada "vista" o "consulta". Las relaciones derivadas son convenientes ya que expresan información de varias relaciones actuando como si fuera una sola.
Restricciones 
Una restricción es una condición que obliga el cumplimiento de ciertas condiciones en la base de datos. Algunas no son determinadas por los usuarios, sino que son inherentemente definidas por el simple hecho de que la base de datos sea relacional. Algunas otras restricciones las puede definir el usuario, por ejemplo, usar un campo con valores enteros entre 1 y 10.
Las restricciones proveen un método de implementar reglas en la base de datos. Las restricciones restringen los datos que pueden ser almacenados en las tablas. Usualmente se definen usando expresiones que dan como resultado un valor booleano, indicando si los datos satisfacen la restricción o no.
Las restricciones no son parte formal del modelo relacional, pero son incluidas porque juegan el rol de organizar mejor los datos. Las restricciones son muy discutidas junto con los conceptos relacionales.
Dominios 
Un dominio describe un conjunto de posibles valores para cierto atributo. Como un dominio restringe los valores del atributo, puede ser considerado como una restricción. Matemáticamente, atribuir un dominio a un atributo significa "todos los valores de este atributo deben de ser elementos del conjunto especificado".
Distintos tipos de dominios son: enteros, cadenas de texto, fecha, etc...
Clave única 
Cada tabla puede tener uno o más campos cuyos valores identifican de forma única cada registro de dicha tabla, es decir, no pueden existir dos o más registros diferentes cuyos valores en dichos campos sean idénticos. Este conjunto de campos se llama clave única.
Pueden existir varias claves únicas en una determinada tabla, y a cada una de éstas suele llamársele candidata a clave primaria.
Clave primaria 
Una clave primaria es una clave única elegida entre todas las candidatas que define univocamente a todos los demas atributos de la tabla, para especificar los datos que serán relacionados con las demás tablas. La forma de hacer esto es por medio de claves foráneas.
Sólo puede existir una clave primaria por tabla y ningún campo de dicha clave puede contener valores NULL.
Clave foránea 
Una clave foránea es una referencia a una clave en otra tabla. Las claves foráneas no necesitan ser claves únicas en la tabla donde estan y si a donde estan referenciadas.
Por ejemplo, el código de departamento puede ser una clave foránea en la tabla de empleados, pero obviamente se permite que haya varios empleados en un mismo departamento, pero existira solo un departamento.
Clave índice 
Las claves índice surgen con la necesidad de tener un acceso más rápido a los datos. Los índices pueden ser creados con cualquier combinación de campos de una tabla. Las consultas que filtran registros por medio de estos campos, pueden encontrar los registros de forma no secuencial usando la clave índice.
Las bases de datos relacionales incluyen múltiples técnicas de ordenamiento, cada una de ellas es óptima para cierta distribución de datos y tamaño de la relación.
Los índices generalmente no se consideran parte de la base de datos, pues son un detalle agregado. Sin embargo, las claves índices son desarrolladas por el mismo grupo de programadores que las otras partes de la base de datos.
Procedimientos almacenados
Un procedimiento almacenado es código ejecutable que se asocia y se almacena con la base de datos. Los procedimientos almacenados usualmente recogen y personalizan operaciones comunes, como insertar un registro dentro de una tabla, recopilar información estadística, o encapsular cálculos complejos. Son frecuentemente usados por un API por seguridad o simplicidad.
Los procedimientos almacenados no son parte del modelo relacional, pero todas las implementaciones comerciales los incluyen...
Estructura 
La base de datos se organiza en dos marcadas secciones; el esquema y los datos (o instancia).
El esquema es la definición de la estructura de la base de datos y principalmente almacena los siguientes datos:
  • El nombre de cada tabla
  • El nombre de cada campo
  • El tipo de dato de cada campo
  • La tabla a la que pertenece cada campo
Las bases de datos relacionales pasan por un proceso al que se le conoce como normalización, el resultado de dicho proceso es un esquema que permite que la base de datos sea usada de manera óptima.
Los datos o instancia es el contenido de la base de datos en un momento dado. Es en si, el contenido de todos los registros.
Manipulación de la información 
Para manipular la información utilizamos un lenguaje relacional, actualmente se cuenta con dos lenguajes formales el álgebra relacional y el cálculo relacional. El álgebra relacional permite describir la forma de realizar una consulta, en cambio, el cálculo relacional sólo indica lo que se desea devolver.
El lenguaje más común para construir las consultas a bases de datos relacionales es SQL (Structured Query Language), un estándar implementado por los principales motores o sistemas de gestión de bases de datos relacionales.
En el modelo relacional los atributos deben estar explícitamente relacionados a un nombre en todas las operaciones, en cambio, el estándar SQL permite usar columnas sin nombre en conjuntos de resultados, como el asterisco taquigráfico (*) como notación de consultas.
Al contrario del modelo relacional, el estándar SQL requiere que las columnas tengan un orden definido, lo cual es fácil de implementar en una computadora, ya que la memoria es lineal.
Es de notar, sin embargo, que en SQL el orden de las columnas y los registros devueltos en cierto conjunto de resultado nunca está garantizado, a no ser que explícitamente sea especificado por el usuario.
Manejadores de base de datos relacionales 
Existe software exclusivamente dedicado a tratar con bases de datos relacionales. Este software se conoce como SGBD (Sistema de gestión de base de datos relacional) o RDBMS (del inglés Relational database management system).
Entre los gestores o manejadores más actuales y populares encontramos: MySQL, PostgreSQL, Oracle y Microsoft SQL Server.
Ventajas y desventajas 
Ventajas
  • Provee herramientas que garantizan evitar la duplicidad de registros.
  • Garantiza la integridad referencial, así, al eliminar un registro elimina todos los registros relacionados dependientes.
  • Favorece la normalización por ser más comprensible y aplicable.
Desventajas
Las bases de datos orientadas a objetos (BDOO) se propusieron con el objetivo de satisfacer las necesidades de las aplicaciones anteriores y así, complementar pero no sustituir a las bases de datos relacionales. Esto lo dijo el analista en sistemas wilson e.






AXIOMAS DE AMSTRONG
"AXIOMAS DE AMSTRONG"


1. Reflexiva x->y
· Direccion->Estrato
· Nombre->Apellido
· Direccion->Telefono
· Sexo->Nombre

2.Aumentatividad x+y->z
· Nombre+Registro_medico->Especialidad
· Identificacion+Registro_medico->Nombre
· Registro_medico+Especialidad->Salario
· Nombre+Identificacion->Edad

3. Proyectividad x->y+z
· Registro_medico->Nombre+Especialidad
· Estrato->Direccion+Identificacion
· Sexo->Nombre+Identificacion
· Salario-> Registro_medico+Especialidad

4.Aditividad x+y->w+z
· Registro_medico+Identificacion->Nombre+Especialidad
· Nombre+Identificacion->Sexo+ Registro_medico
· Direccion+Telefono->Nombre+Identificacion
· Identificacion+ Registro_medico->Sexo+Edad

5. Transitividad x->y y->z x->z
· Nombre->Telefono Telefono->Direccion Nombre->Direccion
· Nombre->Sexo Sexo->Identificacion Nombre->Identificacion
· Direccion->Telefono Telefono->Estrato Direccion->Estrato
· Registro_medico->Nombre Nombre->Especialidad Registro_medico->Especialidad