Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Bdrelacional
Bdrelacional
Bdrelacional
Este trabajo est protegido bajo una licencia de Creative Commons del tipo Attribution-NonCommercial-ShareAlike. Para ver una copia de esta licencia visite: http://creativecommons.org/licenses/by-nc-sa/2.0/ o enve una carta a: Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
<1>
<2>
Los contenidos de este documento estn protegidos bajo una licencia de Creative Commons del tipo Attribution-Noncomercial-Share Alike. Con esta licencia: Eres libre de:
Noncommercial (No comercial). No puedes utilizar este trabajo con propsitos comerciales.
Share Alike (Compartir igual). Si modificas, alteras o construyes nuevos trabajos a partir de este, debes distribuir tu trabajo con una licencia idntica a sta
Si estas limitaciones son incompatible con tu objetivo, puedes contactar con el autor para solicitar el permiso correspondiente
No obstante tu derecho a un uso justo y legtimo de la obra, as como derechos no se ven de manera alguna afectados por lo anteriormente expuesto.
Esta nota no es la licencia completa de la obra, sino una traduccin del resumen en formato comprensible del texto legal. La licencia original completa (jurdicamente vlida y pendiente de su traduccin oficial al espaol) est disponible en http://creativecommons.org/licenses/by-nc-sa/2.0/legalcode
<3>
ndice
ndice.............................................................................................. 5 modelos lgicos de datos............................................................... 7 esquema cannico .............................................................................. 7 tipos de base de datos ......................................................................... 7 modelo relacional ........................................................................ 11 introduccin...................................................................................... 11 tablas ............................................................................................... 12 dominios........................................................................................... 13 claves ............................................................................................... 13 nulos ................................................................................................ 13 restricciones ...................................................................................... 14 las 12 reglas de Codd ....................................................................... 14 paso del esquema ER al modelo relacional................................. 17 transformaciones de entidades fuertes ................................................. 17 transformacin de relaciones.............................................................. 17 entidades dbiles............................................................................... 19 generalizaciones y especificaciones..................................................... 20 normalizacin del esquema relacional ....................................... 23 problemas del esquema relacional...................................................... 23 formas normales................................................................................ 23 apndice: trminos tcnicos......................................................... 31
<5>
Mundo real
Esquema Conceptual
Esquema cannico
Esquema interno
BD Fsical
Ilustracin 1, Posicin de esquema cannico dentro de los esquema de creacin de una base de datos
El esquema cannico o lgico global, es un esquema que presenta de forma conceptual la estructura de una base de datos. Es un esquema que depende del tipo de DBMS que vayamos a utilizar. Se crea a partir del modelo conceptual (vase el documento Diseo Conceptual de Bases de Datos en www.jorgesanchez.net/bd). Y servira para cualquier base de datos comercial del tipo elegido en el esquema (hay esquemas relacionales, en red, jerrquicos,...)
<7>
Documentos
Personal
Tareas
Ilustracin 2, Ejemplo de esquema jerrquico
en red
Se trata de un modelo que se utiliz durante mucho tiempo. Organiza la informacin en registros y enlaces. Los registros representan las entidades del modelo entidad / relacin. En los registros se almacenan los datos utilizando atributos. Los enlaces permiten relacionar los registros de la base de datos. El modelo en red ms aceptado es el llamado codasyl, que durante mucho tiempo se ha convertido en un estndar. Las bases de datos en red son parecidas a las jerrquicas slo que en ellas puede haber ms de un padre. En este modelo se pueden representar perfectamente relaciones varios a varios. Pero su dificultad de manejo y complejidad hace que se estn abandonando completamente.
relacionales
Los datos se muestran en forma de tablas y relaciones. Este es el modelo que se comenta en el presente documento. De hecho es el claramente ms popular.
orientadas a objetos
Desde la aparicin de la programacin orientada a objetos (POO u OOP) se empez a pensar en bases de datos adaptadas a estos lenguajes. En estos lenguajes los datos y los procedimientos se almacenan juntos. Esta es la idea de las bases de datos orientadas a objetos. A travs de esta idea se intenta que estas bases de datos consiguen arreglar las limitaciones de las relacionales. Por ejemplo el problema de la herencia, tipos definidos por el usuario, disparadores almacenables en la base de datos, soporte multimedia... Se supone que son las bases de datos de tercera generacin (la primera fue las bases de datos en red y la segunda las relacionales), lo que significa que el futuro parece estar a favor de estas bases de datos. Pero siguen sin reemplazar a las relacionales (aunque cada vez hay ms). Su modelo conceptual se suele disear en UML y el lgico en ODMG 3.0
objeto relacionales
Tratan de ser un hbrido entre el modelo relacional y el orientado a objetos. El problema de las bases de datos orientadas a objetos es que requieren reinvertir de nuevo para convertir las bases de datos. En las bases de datos objeto relacionales se intenta conseguir una compatibilidad relacional dando la posibilidad de integrar mejoras de la orientacin a objetos. <8>
Estas bases de datos se basan en el estndar SQL 99 que dict las normas para estas bases de datos. En ese estndar se aade a las bases relacionales la posibilidad de almacenar procedimientos de usuario, triggers, tipos definidos por el usuario, consultas recursivas, bases de datos OLAP, tipos LOB,... Las ltimas versiones de la mayora de las grandes bases de datos relacionales (Oracle, SQL Server, Informix, ...) son objeto relacionales.
<9>
modelo relacional
introduccin
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 aos despus el modelo se empez a implementar cada vez ms, hasta ser el modelo de bases de datos ms popular. En las bases de Codd se definan los objetivos de este modelo: Independencia fsica. La forma de almacenar los datos, no debe influir en su manipulacin lgica Independencia lgica. Las aplicaciones que utilizan la base de datos no deben ser modificadas por que se modifiquen elementos de la base de datos. Flexibilidad. La base de datos ofrece fcilmente distintas vistas en funcin de los usuarios y aplicaciones. Uniformidad. Las estructuras lgicas siempre tienen una nica forma conceptual (las tablas) Sencillez. En 1978, IBM desarrolla el lenguaje QBE. Que aproximaba la idea relacional a sus ficheros VSAM. En 1979 Oracle se convierte en el primer producto comercial DBMS relacional (RDBMS). En 1980 aparece Ingres que utilizaba el lenguaje Quel que implementaba el clculo relacional.
<11>
modelo relacional
tablas
Las bases de datos relacionales se basan en el uso de tablas (tambin se las llama relaciones). Las tablas se representan grficamente como una estructura rectangular formada por filas y columnas. Cada columna almacena informacin sobre una propiedad determinada de la tabla (se le llama tambin atributo), nombre, dni, apellidos, edad,.... Cada fila posee una ocurrencia o ejemplar de la instancia o relacin representada por la tabla (a las filas se las llama tambin tuplas). NOMBRE atributo 1 valor 1,1 valor 2,1 ..... valor m,1 atributo 2 valor 1,2 valor 2,2 ..... valor m,2 atributo 3 valor 1,3 valor 2,3 ...... valor m,3 .... .... .... .... .... atributo n valor 1,n valor 2,n ..... valor m,n
terminologa relacional
Tupla. Cada fila de la tabla (cada ejemplar que la tabla representa) Atributo. Cada columna de la tabla Grado. Nmero de atributos de la tabla Cardinalidad. Nmero de tuplas de una tabla Dominio. Conjunto vlido de valores representables por un atributo.
tipos de tablas
Persistentes. Slo pueden ser borradas por los usuarios: Base. Independientes, se crean indicando su estructura y sus ejemplares. Vistas. Son tablas que slo almacenan una definicin de consulta, resultado de la cual se produce una tabla cuyos datos proceden de las bases o de otras vistas e instantneas. Si los datos de las tablas base cambian, los de la vista que utiliza esos datos tambin cambia. Instantneas. Son vistas (creadas de la misma forma) que s que almacenan los datos que muestra, adems de la consulta que dio lugar a esa vista. Slo modifican su resultado (actualizan los datos) siendo refrescadas por el sistema cada cierto tiempo. Temporales. Son tablas que se eliminan automticamente por el sistema. Pueden ser de cualquiera de los tipos anterior
<12>
dominios
Los dominios suponen una gran mejora en este modelo ya que permiten especificar los posibles valores vlidos para un atributo. Cada dominio incorpora su nombre y una definicin del mismo. Ejemplos de dominio: Direccin: 50 caracteres Nacionalidad: Espaol, Francs, Italiano,... Los dominios pueden ser tambin compuestos a partir de otros (ao, mes y da = fecha)
clave primaria
Clave candidata que se escoge como identificador de las tuplas.
clave alternativa
Cualquier clave candidata que no sea primaria
nulos
Los valores nulos indican contenidos de atributos que no tienen ningn 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 razn que sea. Las bases de datos relacionales admiten utilizar ese valor en todo tipo de operaciones. Eso significa definir un tercer valor en la lgica. Adems de el valor verdadero o falso, existe el valor para los nulos. La razn de este tercer valor ambiguo es que comparar dos atributos con valor nulo, no puede resultar ni verdadero, ni falso. De hecho necesitamos definir la lgica con este valor: verdadero Y (AND) nulo da como resultado, nulo falso Y (AND) nulo da como resultado, falso verdadero O (OR) nulo da como resultado, verdadero falso O nulo da como resultado nulo la negacin de nulo, da como resultado nulo
<13>
modelo relacional
restricciones
Se trata de unas condiciones de obligado cumplimiento por los datos de la base de datos. Las hay de varios tipos.
inherentes
Son aquellas que no son determinadas por los usuarios, sino que son definidas por el hecho de que la base de datos sea relacional. Por ejemplo: No puede haber dos tuplas iguales El orden de las tuplas no importa El orden de los atributos no importa Cada atributo slo puede tomar un valor en el dominio en el que est inscrito
semnticas
El modelo relacional permite a los usuario incorporar restricciones personales a los datos. Las principales son: Clave primaria. Hace que los atributos marcados como clave primaria no puedan repetir valores. Unicidad. Impide que los valores de los atributos marcados de esa forma, puedan repetirse. Obligatoriedad. Prohbe que el atributo marcado de esta forma no tenga ningn valor Integridad referencial. Prohbe colocar valores en una clave externa que no estn reflejados en la tabla donde ese atributo es clave primaria. Regla de validacin. Condicin que debe de cumplir un dato concreto para que sea actualizado.
1>
Informacin. Toda la informacin de la base de datos debe estar representada explcitamente en el esquema lgico. Es decir, todos los datos estn en las tablas. Acceso garantizado. Todo dato es accesible sabiendo el valor de su clave y el nombre de la columna o atributo que contiene el dato. Tratamiento sistemtico de los valores nulos. El DBMS debe permitir el tratamiento adecuado de estos valores <14>
2> 3>
4> 5>
Catlogo en lnea basado en el modelo relacional. Los metadatos deben de ser accesibles usando un esquema relacional. 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 operacin. Actualizacin de vistas. El DBMS debe encargarse de que las vistas muestren la ltima informacin Inserciones, modificaciones y eliminaciones de dato nivel. Cualquier operacin de modificacin debe actuar sobre conjuntos de filas, nunca deben actuar registro a registro. Independencia fsica. Los datos deben de ser accesibles desde la lgica de la base de datos an cuando se modifique el almacenamiento. Independencia lgica. Los programas no deben verse afectados por cambios en las tablas en la base de datos (en el diccionario de datos), no en los programas de aplicacin.
6> 7>
8> 9>
registro a registro, ste no puede utilizarse para incumplir las reglas relacionales.
<15>
Nombre
Atributo2 Atributo2
transformacin de relaciones
La idea inicial es transformar a cada relacin en una tabla en el modelo relacional. Pero hay que distinguir segn el tipo de relacin.
Nombre
Identificador1
Atributo1
Identificador2
Nombre(Identificador1,Identificador2,Atributo1,Atributo2)
<17>
relaciones de orden n
Las relaciones ternarias, cuaternarias y n-arias que unen ms de dos relaciones se transforman en una tabla que contiene los atributos de la relacin ms los identificadores de las entidades relacionadas. La clave la forman todas las claves externas:
Identificador1 Atributo1
Nombre Identificador2
Identificador3
Atributo1
Identificador4
Nombre(Identificador1,Identificador2,,Identificador3,Identificador4,Atributo1,Atributo2)
Entidad1
Nombre
Entidad2
Identificador1
Identificador2
Entidad2(Identificador2,Atributo3) Entidad1(Identificador1,Atributo1,Identificador2,Atributo2)
As en el dibujo, el identificador2 en la tabla Entidad1 pasa a ser una clave externa. En el caso de que el nmero mnimo de la relacin sea de cero (puede haber ejemplares de la entidad uno sin relacionar), se deber permitir valores nulos en la clave externa
1
Clave externa, clave ajena, clave fornea, clave secundaria y foreign key son sinnimos
<18>
identificador2. En otro caso no se podrn permitir (ya que siempre habr un valor relacionado). En el caso de las relaciones uno a uno, ocurre lo mismo: la relacin no se convierte en tabla, sino que se coloca en una de las tablas (en principio dara igual cul) el identificador de la entidad relacionada como clave externa. En el caso de que una entidad participe opcionalmente en la relacin, entonces es el identificador de sta el que se colocar como clave externa en la tabla que representa a la otra entidad.
relaciones recursivas
Las relaciones recursivas se tratan de la misma forma que las otras, slo que un mismo atributo puede figurar dos veces en una tabla como resultado de la transformacin:
Identificador Rol2 Identificador Rol2
Entidad
Atributo 1 Rol1 Relac. Atributo 1
Entidad
Rol1 Relac.
Entidad(Identificador,Atributo1,Identificador Rol 1)
entidades dbiles
Toda entidad dbil incorpora una relacin implcita con una entidad fuerte. Esta relacin 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 dbil. Es ms, normalmente esa clave externa forma parte de la clave principal de la tabla que representa a la entidad dbil. El proceso es:
Atributo1 Atributo2
Entidad Fuerte
Entidad Dbil
Id Fuerte
Id Dbil
<19>
paso del esquema ER modelo relacional En ocasiones el identificador de la entidad dbil es suficiente para identificar los ejemplares de dicha entidad, entonces ese identificador quedara como clave principal, pero el identificador de la entidad fuerte seguira figurando como clave externa en la entidad dbil.
generalizaciones y especificaciones
Las generalizaciones y/o especificaciones se convierten al modelo relacional de esta forma:
1> 2>
Las subentidades pasan a ser tablas. Si la clave de la superentidad es distinta de las subentidades, entonces se coloca el identificador de la superentidad en cada subentidad como clave externa:
Id1
Atributo1
Superentidad
Atributo2 Atributo3
Subentidad1
Id2
Subentidad2
Id3
3>
Si la clave es la misma, entonces todas las entidades tendrn la misma columna como identificador:
Id
Atributo1
Superentidad
Atributo2 Atributo3
Subentidad1
Id
Subentidad2
Id
Ilustracin 11, Proceso de transformacin de relaciones ISA en el modelo relacional si tienen la misma clave
<20>
4>
La superentidad debe generar una tabla slo en el caso de que haya posibilidad de que exista un ejemplar de dicha entidad que no sea ejemplar de las subentidades. De otro modo basta con generar las tablas de las subentidades e incluir los atributos de la entidad superior:
Id
Atributo1
Superentidad
Atributo2 Atributo3
Subentidad1
Id
Subentidad2
Id
Ilustracin 12, Paso de relaciones ISA al modelo relacional cuando toda superentidad figura como subentidad
<21>
formas normales
Las formas normales se corresponde a una teora de normalizacin iniciada por el propio Codd y continuada por otros autores (entre los que destacan Boyce y Fagin). Codd defini en 1970 la primera forma normal, desde ese momento aparecieron la segunda, tercera, la Boyce-Codd, la cuarta y la quinta forma normal. Una tabla puede encontrarse en primera forma normal y no en segunda forma normal, pero no al contrario. Es decir los nmeros altos de formas normales son ms restrictivos (la quinta forma normal cumple todas las anteriores). La teora de formas normales es una teora absolutamente matemtica, pero en el presente manual se describen de forma intuitiva.
<23>
apndice: trminos tcnicos Visualmente es un tabla, pero no una tabla relacional (lo que en terminologa de bases de datos relacionales se llama relacin). No cumple la primera forma normal. Lo cumplira si: TRABAJADOR Nombre Andrs Andrea Andrea
dependencias funcionales
Se dice que un conjunto de atributos (Y) depende funcionalmente de otro conjunto de atributos (X) si para cada valor de X hay un nico valor posible para Y. Simblicamente se denota por XY. Por ejemplo el nombre de una persona depende funcionalmente del DNI, para un DNI concreto slo hay un nombre posible. En la tabla ejemplo anterior, el departamento no tiene dependencia funcional, ya que para un mismo DNO puede haber ms de un departamento posible. Al conjunto X del que depende funcionalmente el conjunto Y se le llama determinante. Al conjunto Y se le llama implicado.
departamento). Como no ocurre que YX (el cdigo de la clase no depende funcionalmente del cdigo tutor, un cdigo tutor se puede corresponder con varios cdigos de clase). Entonces X Z (el cdigo del departamento depende transitivamente del cdigo de la clase).
Cod Curso 34 25 34 25 34
Nota 9 8 6 7 6
Suponiendo que el DNI y el nmero de curso formen una clave principal para esta tabla, slo la nota tiene dependencia funcional completa. El nombre y los apellidos dependen de forma completa del DNI. La tabla no es 2FN, para arreglarlo: ALUMNOS Nombre Pedro Ana Sara ASISTENCIA Cod Curso 34 25 34 25 34
Nota 9 8 6 7 6
<25>
apndice: trminos tcnicos Ejemplo: ALUMNOS Apellido1 Velasco Valiente Fernndez Crespo Serrat
Cod Provincia 34 34 47 47 08
La Provincia depende funcionalmente del cdigo de provincia, lo que hace que no est en 3FN. El arreglo sera: ALUMNOS Apellido1 Velasco Valiente Fernndez Crespo Serrat
Cod Provincia 34 34 47 47 08
Esa tabla est en tercera forma normal (no hay dependencias transitivas), pero no en forma de Boyce - Codd, ya que (DNI, Asignatura) Tutor y TutorAsignatura. En este caso la redundancia ocurre por mala seleccin de clave. La redundancia de la asignatura es completamente evitable. La solucin sera: <26>
ASIGNATURASTUTOR Asignatura Tutor Lenguaje Eva Matemticas Andrs Matemticas Guillermo Lenguaje Julia En las formas de Boyce-Codd hay que tener cuidado al descomponer ya que se podra perder informacin por una mala descomposicin
dependencia multivaluada
Para el resto de formas normales (las diseadas por Fagin, mucho ms complejas), es importante definir este tipo de dependencia, que es distinta de las funcionales. Si las funcionales eran la base de la segunda y tercera forma normal (y de la de Boyce-Codd), stas son la base de la cuarta forma normal. Una dependencia multivaluada de una tabla con atributos X, Y, Z de X sobre Z (es decir X->>Z) ocurre cuando los posibles valores de Y sobre cualquier par de valores X y Z dependen slo del valor de X y son independientes de Z. Ejemplo: N Curso 17 17 17 17 25 25 25 Profesor Eva Eva Julia Julia Eva Eva Eva Material 1 2 1 2 1 2 3
La tabla cursos, profesores y materiales del curso. La tabla est en FNBC ya que no hay dependencias transitivas y todos los atributos son clave sin dependencia funcional hacia ellos. Sin embargo hay redundancia. Los materiales se van a repetir para cualquier profesor dando cualquier curso, ya que los profesores van a utilizar todos los materiales del curso (de no ser as no habra ninguna redundancia).
<27>
apndice: trminos tcnicos Los materiales del curso dependen del curso y no del profesor en una dependencia multivaluada. Para el par N de curso y profeso podemos saber los materiales, pero por el curso y no por el profesor.
Un teorema de Fagin indica cuando hay tres pares de conjuntos de atributos X, Y y Z si ocurre X->>Y|Z (Y y Z tienen dependencia multivaluada sobre X), entonces las tablas X,Y y X,Z reproducen sin perder informacin lo que posea la tabla original. Este teorema marca la forma de dividir las tablas hacia una 4FN
Indican cdigos de material suministrado por un proveedor y utilizado en un determinado proyecto. Si ocurre una restriccin especial como por ejemplo: Cuando un proveedor nos ha suministrado alguna vez un determinado material, si ese material aparece en otro proyecto, haremos que el proveedor nos suministre tambin ese material para ese proyecto.
<28>
Eso ocurre en los datos como el proveedor nmero 1 nos suministr el material nmero 1 para el proyecto 2 y en el proyecto 1 utilizamos el material 1, aparecer la tupla proveedor 1, material 1 y proyecto 1. La dependencia que produce esta restriccin es lejana y se la llama de reunin. Para esa restriccin esta divisin en tablas sera vlida: Proveedor 1 1 2 Material 1 2 1 Material 1 2 1 Proyecto 2 1 1
Esa descomposicin no pierde valores en este caso, sabiendo que si el proveedor nos suministra un material podremos relacionarle con todos los proyectos que utilizan ese material. Resumiendo, una tabla no est en quinta forma normal si hay una descomposicin de esa tabla que muestre la misma informacin que la original.
<29>
ERE FNBC
apndice: trminos tcnicos LOB Large Object Binary, objeto binario largo. Tipo de datos de muchas bases de datos que admiten almacenar grandes cantidades de informacin en formato binario. Object Data Management Group, grupo de administracin de objetos de datos. Estndar utilizado para definir modelos lgicos de bases de datos de objetos. On Line Analytical Process, Proceso analtico en lnea. Nombre que reciben las OOP Programacin orientada a objetos Vase SO Programacin orientada a objetos Query by Example, consultas mediante ejemplos. Lenguaje relacional utilizado en algunas de las primeras bases de datos relacionales. Relational Model Version 2, Modelo relacional, versin 2. Modelo desarrollado por Codd, considerado como la segunda versin del modelo relacional. Relational Data Base Management System, Sistema gestor de bases de datos relacionales. El software encargado de administrar y producir bases de datos relacionales Vase DBMS Vase RDBMS Sistema operativo System Planing and Repairments Comitte, comit de planificacin de sistemas y reparaciones, subseccin de ANSI. Uniform Modeling Language, Lenguaje de modelado universal, utilizado para realizar modelos conceptuales de informacin orientada al objeto. Seccin de ANSI encargada de los estndares de ordenadores y m
ODMG
RDBMS
<32>