Modelo Relacional

65,538 views

Published on

Published in: Technology
3 Comments
8 Likes
Statistics
Notes
  • no puedo descargarlo porque no me an mandado el link a mi correo!!!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Puede que me equivoque, pero en la diapositiva 32, juraría que la tabla Relac no debería tener como columna Atributo1
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • excelente muy bien explicado
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
65,538
On SlideShare
0
From Embeds
0
Number of Embeds
1,168
Actions
Shares
0
Downloads
1,664
Comments
3
Likes
8
Embeds 0
No embeds

No notes for slide

Modelo Relacional

  1. 1. BASE DE DATOS (IV) Prof. Omar A. Rivera Zarate Instituto Superior Tecnológico Público “OXAPAMPA”
  2. 2. MODELO RELACIONAL
  3. 3. MODELO RELACIONAL <ul><li>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. </li></ul>
  4. 4. OBJETIVOS DEL MODELO <ul><li>Independencia física . La forma de almacenar los datos, no debe influir en su manipulación lógica </li></ul><ul><li>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. </li></ul><ul><li>Flexibilidad . La base de datos ofrece fácilmente distintas vistas en función de los usuarios y aplicaciones. </li></ul><ul><li>Uniformidad . Las estructuras lógicas siempre tienen una única forma conceptual (las tablas) </li></ul><ul><li>Sencillez . </li></ul>
  5. 5. EVOLUCION DEL MODELO <ul><li>Año Hecho </li></ul><ul><li>1970 Codd publica las bases del modelo relacional </li></ul><ul><li>1971-72 Primeros desarrollos teóricos </li></ul><ul><li>1973-78 Primeros prototipos </li></ul><ul><li>1978 Aparece el lenguaje QBE </li></ul><ul><li>1979 Aparece Oracle </li></ul><ul><li>1980 Aparece Ingres </li></ul><ul><li>1981 Aparece SQL </li></ul><ul><li>1982 Aparece DB2 </li></ul><ul><li>1986 ANSI normaliza el SQL (SQL/ANSI) </li></ul><ul><li>1987 SQL de ISO </li></ul><ul><li>1990 Versión dos del modelo relacional (RM/V2) </li></ul><ul><li>1992 SQL 92 </li></ul><ul><li>1998 SQL 3 </li></ul>
  6. 6. TABLAS <ul><li>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 ). </li></ul>
  7. 7. TABLAS
  8. 8. TERMINOLOGIA RELACIONAL <ul><li>Tupla. Cada fila de la tabla (cada ejemplar que la tabla representa) </li></ul><ul><li>Atributo. Cada columna de la tabla </li></ul><ul><li>Grado. Número de atributos de la tabla </li></ul><ul><li>Cardinalidad. Número de tuplas de una tabla </li></ul><ul><li>Dominio . Conjunto válido de valores representables por un atributo. </li></ul>
  9. 9. TIPOS DE TABLAS <ul><li>Persistentes. Sólo pueden ser borradas por los usuarios: </li></ul><ul><ul><li>Base . Independientes, se crean indicando su estructura y sus ejemplares. </li></ul></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>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. </li></ul></ul><ul><li>Temporales . Son tablas que se eliminan automáticamente por el sistema. Pueden ser de cualquiera de los tipos anterior. </li></ul>
  10. 10. DOMINIOS <ul><li>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. </li></ul><ul><li>Ejemplos de dominio: </li></ul><ul><li>Dirección: 50 caracteres </li></ul><ul><li>Nacionalidad: Español, Francés, Italiano,... </li></ul><ul><li>Los dominios pueden ser también compuestos a partir de otros (año, mes y día = fecha) </li></ul>
  11. 11. CLAVES <ul><li>Clave candidata </li></ul><ul><li>Conjunto de atributos de una tabla que identifican unívocamente cada tupla de la tabla. </li></ul><ul><li>Clave primaria </li></ul><ul><li>Clave candidata que se escoge como identificador de las tuplas. </li></ul><ul><li>Clave alternativa </li></ul><ul><li>Cualquier clave candidata que no sea primaria </li></ul><ul><li>Clave externa o secundaria </li></ul><ul><li>Atributo de una tabla relacionado con una clave de otra tabla. </li></ul>
  12. 12. VALORES NULOS <ul><li>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. </li></ul><ul><li>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. </li></ul>
  13. 13. LOGICA DEL VALOR NULO <ul><li>verdadero Y (AND) nulo da como resultado, nulo </li></ul><ul><li>falso Y (AND) nulo da como resultado, falso </li></ul><ul><li>verdadero O (OR) nulo da como resultado, verdadero </li></ul><ul><li>falso O nulo da como resultado nulo </li></ul><ul><li>la negación de nulo, da como resultado nulo </li></ul>
  14. 14. RESTRICCIONES <ul><li>Se trata de unas condiciones de obligado cumplimiento por los datos de la base de datos. </li></ul><ul><li>Las hay de varios tipos. </li></ul><ul><li>Inherentes </li></ul><ul><li>Semánticas </li></ul>
  15. 15. RESTRICCIONES INHERENTES <ul><li>Son aquellas que no son determinadas por los usuarios, sino que son definidas por el hecho de que la base de datos sea relacional. </li></ul><ul><li>Por ejemplo: </li></ul><ul><li>No puede haber dos tuplas iguales </li></ul><ul><li>El orden de las tuplas no importa </li></ul><ul><li>El orden de los atributos no importa </li></ul><ul><li>Cada atributo sólo puede tomar un valor en el dominio en el que está inscrito </li></ul>
  16. 16. RESTRICCIONES SEMANTICAS <ul><li>El modelo relacional permite a los usuario incorporar restricciones personales a los datos. Las principales son: </li></ul><ul><li>Clave primaria . Hace que los atributos marcados como clave primaria no puedan repetir valores. </li></ul><ul><li>Unicidad . Impide que los valores de los atributos marcados de esa forma, puedan repetirse. </li></ul><ul><li>Obligatoriedad . Prohíbe que el atributo marcado de esta forma no tenga ningún valor </li></ul><ul><li>Integridad referencial . Prohíbe colocar valores en una clave externa que no estén reflejados en la tabla donde ese atributo es clave primaria. </li></ul><ul><li>Regla de validación. Condición que debe de cumplir un dato concreto para que sea actualizado. </li></ul>
  17. 17. LAS 12 REGLAS DE CODD <ul><li>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. </li></ul>
  18. 18. LAS 12 REGLAS DE CODD <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>3. Tratamiento sistemático de los valores nulos . El DBMS debe permitir el tratamiento adecuado de estos valores. </li></ul><ul><li>4. Catálogo en línea basado en el modelo relacional. Los metadatos deben de ser accesibles usando un esquema relacional. </li></ul>
  19. 19. LAS 12 REGLAS DE CODD <ul><li>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. </li></ul><ul><li>6. Actualización de vistas. El DBMS debe encargarse de que las vistas muestren la última información </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
  20. 20. LAS 12 REGLAS DE CODD <ul><li>9. Independencia lógica. Los programas no deben verse afectados por cambios en las tablas </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
  21. 21. PASO DEL ESQUEMA E/R AL MODELO RELACIONAL <ul><li>TRANSFORMACION DE ENTIDADES FUERTES </li></ul><ul><li>En principio las entidades fuertes del modelo. Entidad Relación son transformados al modelo relacional siguiendo estas instrucciones: </li></ul><ul><li>Entidades. Las entidades pasan a ser tablas </li></ul><ul><li>Atributos . Los atributos pasan a ser columnas. </li></ul><ul><li>Identificadores principales . Pasan a ser claves primarias </li></ul><ul><li>Identificadores candidatos . Pasan a ser claves candidatas. </li></ul>
  22. 22. PASO DEL ESQUEMA E/R AL MODELO RELACIONAL
  23. 23. TRANSFORMACION DE RELACIONES <ul><li>RELACION VARIOS A VARIOS </li></ul><ul><li>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: </li></ul>
  24. 24. TRANSFORMACION DE RELACIONES <ul><li>RELACION VARIOS A VARIOS </li></ul>
  25. 25. TRANSFORMACION DE RELACIONES <ul><li>RELACIONES DE ORDEN N </li></ul><ul><li>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: </li></ul>
  26. 26. TRANSFORMACION DE RELACIONES <ul><li>RELACIONES DE ORDEN N </li></ul>
  27. 27. TRANSFORMACION DE RELACIONES <ul><li>RELACIONES DE UNO A VARIOS Y DE UNO A UNO </li></ul><ul><li>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 ): </li></ul>
  28. 28. TRANSFORMACION DE RELACIONES <ul><li>RELACIONES DE UNO A VARIOS Y DE UNO A UNO </li></ul>
  29. 29. TRANSFORMACION DE RELACIONES <ul><li>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 </li></ul>
  30. 30. TRANSFORMACION DE RELACIONES <ul><li>RELACIONES RECURSIVAS </li></ul><ul><li>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: </li></ul>
  31. 31. TRANSFORMACION DE RELACIONES <ul><li>RELACIONES RECURSIVAS </li></ul>
  32. 32. TRANSFORMACION DE RELACIONES <ul><li>RELACIONES RECURSIVAS </li></ul>
  33. 33. TRANSFORMACION DE RELACIONES <ul><li>ENTIDADES DEBILES </li></ul><ul><li>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. </li></ul>
  34. 34. TRANSFORMACION DE RELACIONES <ul><li>ENTIDADES DEBILES </li></ul>
  35. 35. TRANSFORMACION DE RELACIONES <ul><li>ENTIDADES DEBILES </li></ul><ul><li>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. </li></ul>

×