03 De conceptual a relacional

2,520 views

Published on

Conversión del modelo conceptual a modelo relacional

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,520
On SlideShare
0
From Embeds
0
Number of Embeds
132
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

03 De conceptual a relacional

  1. 1. Del Modelo Conceptual al Modelo Relacional <ul><li>Es un paso que nos acerca más a los detalles que necesitaremos para crear una BD en un gestor.
  2. 2. Pasos clásicos: </li><ul><li>Modelo Conceptual -> Modelo Relacional -> Modelo Físico
  3. 3. Nivel de detalle creciente
  4. 4. El paso siguiente es mucho más fácil si se ha echo el anterior </li></ul></ul>
  5. 5. Traducción de conceptos MC -> MR Modelo Conceptual Modelo Relacional Centrado en describir objetos del problema y los vínculos entre ellos Describe los mecanismos para tratar el problema deseado en una BD Entidades (suelen describirse en singular) Tablas (Se suelen nombrar en plural. También se las llama RELACIONES) Atributos Columnas o atributos Ejemplares o instancias Filas o tuplas Dominios Tipos de datos Identificador Clave primaria (Primary Key) Relación 1:N Clave foránea o extranjera (Foreign Key) Relación N:M (muchos a muchos) Tabla intermedia Relación 1:1 entre 2 entidades Decidimos qué tabla recibe una (FK) o si unificamos las 2 entidades en 1 Formato gráfico Formato descriptivo (texto) Algunas entidades débiles Pueden convertirse en restricciones
  6. 6. Ejemplo EMPLEADOS ( codigo , DEP_codigo (FK) , nombre, salario, ○ fechaNac, extTelefonica) DEPARTAMENTOS( codigo , nombre) CONVENIOS <ul><li>Atributos identificadores subrayados
  7. 7. ○ en los atributos opcionales
  8. 8. Nombre para claves extranjeras: AbreviaturaTablaOrigen(3letras) _ nombreAtributo (FK) </li></ul>(esta flecha no se pone)
  9. 9. Tipos de datos predefinidos (dominios) <ul><li>Fechas e instantes de tiempo: </li><ul><li>DATE, TIME y DATETIME </li></ul><li>Valores numéricos: </li><ul><li>INT, FLOAT, DECIMAL(n,m) </li></ul><li>Cadenas de texto: </li><ul><li>CHAR(n), VARCHAR(n) </li></ul><li>Enumeraciones: </li><ul><li>ENUM('v1', 'v2', 'v3',..., 'vn') </li></ul><li>Otros (imágenes, sonidos...): </li><ul><li>BLOB (binary large objects) </li></ul></ul>
  10. 10. Restricciones a respetar en un modelo relacional <ul><li>Un Gestor de BD relacional las verifica automáticamente
  11. 11. En una tabla no puede haber 2 filas iguales. La clave primaria es obligatoria
  12. 12. El orden de filas y columnas no es importante
  13. 13. Cada columna sólo puede tomar un valor de su dominio, nunca varios
  14. 14. Ningún atributo que forme parte de la clave primaria puede quedar sin valor (no puede tener valor NULL)
  15. 15. Integridad referencial : Los atributos que sean una clave extranjera deben tomar valores de filas existentes en la tabla referenciada (o nulo si se admite) </li></ul>
  16. 16. Acciones relacionadas con la integridad referencial <ul><li>¿Qué hacer si modificamos/borramos una clave referenciada por otras instancias?
  17. 17. IMPEDIR (suele ser la acción por defecto)
  18. 18. BORRAR / MODIFICAR en cascada
  19. 19. AJUSTAR a NULL o a un VALOR POR DEFECTO </li></ul>
  20. 20. Incrementando la semántica incluida en el modelo ER <ul><li>En el modelo relacional se pueden reforzar los supuestos semánticos del problema mediante varios mecanismos: </li><ul><li>CHECK s (restricciones de verificación). P.ej. ”El salario puede oscilar entre los 600 y los 3000€/mes”
  21. 21. TRIGGERS (disparadores) . Permiten rechazar o hacer acciones auxiliares antes o despues de cualquier inserción, borrado o modificación de información. Evento -> Condición -> Acción P.ej. ”Antes de insertar un árbitro comprobar si su nacionalidad coincide con la de alguno de los jugadores y en ese caso rechazar la inserción” </li></ul></ul>

×