Morteo y Otros - Fundamentos de Diseño y Modelado de Datos

Fundamentos de Diseo y Modelado de Datos
Primera Edicin
Francisco A. Morteo
Universidad de Buenos Aires Universidad Abierta Interamericana
Nicols L.E. Bocalandro

Universidad de Buenos Aires Universidad Abierta Interamericana
Cristian A. Cascn
Universidad de Buenos Aires
Hernn G. Cascn
Christian D. Descalzo
Karina M. De Rosa
Diego Krauthamer
Ediciones Cooperativas es un emprendimiento cooperativo de docentes de la Facultad de Ciencias Econmicas de la Universidad de Buenos Aires para difundir sus trabajos e investigaciones.
Ninguna parte de esta publicacin, incluido el diseo de cubierta puede ser reproducida, almacenada o transmitida en manera alguna ni por ningn medio, ya sea electrnico, mecnico, ptico de grabacin o de fotocopia sin permiso previo del Editor. Su infraccin est penada por las leyes 11723 y 25446
Fundamentos de diseo y modelado de datos / Francisco A. Morteo, Nicols L.E. Bocalandro...[et.al.].. - 1a ed. Buenos Aires: Ediciones Cooperativas, 2007. 230 p.; 28x21 cm. ISBN 978-987-1246-51-9 1. Procesamiento de Datos. 2. Diseo de Software. CDD 005.3 CDD 657
2007 Francisco A. Morteo Nicols L.E. Bocalandro - Cristian A. Cascn - Hernn G. Cascn Christian D. Descalzo - Karina M. De Rosa - Diego Krauthamer Derechos exclusivos 2007 Ediciones Cooperativas Tucumn 3227, (1189) Ciudad Autnoma de Buenos Aires Argentina (54 011) 4864 5520 / (15) 4198 5667 http://www.edicionescoop.org.ar " info@ edicionescoop.org.ar Diseo de Cubierta: Gabriela Castro " gabrielacastro@fibertel.com.ar Diseo Interior: Vctor Acua, Guillermo Boces, Adrin de Rosas, Guillermo Ferioli. Web Hosting: www.com.ar
" info@www.com.ar
Hecho el depsito que establece la ley 11.723 Impreso y encuadernado por: Imprenta Dorrego, Cap. Fed. 1. ed. Tirada: 100 ejemplares. Se termin de imprimir en Marzo de 2007
E d i t o r i al as o c i ad a a:
IMPRESO EN ARGENTINA PRINTED IN A
F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer
Indice I II Dedicatorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Los Autores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Francisco Agustn Morteo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Nicols Leocadio Eduardo Bocalandro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Cristian Ariel Cascn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Hernn Gabriel Cascn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Christian Daniel Descalzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Karina Mariana De Rosa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Diego Krauthamer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prlogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Carlos Waldbott de Bassenheim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Juan Mara Ale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metodologa de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cmo interpretar los smbolos de la bibliografa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Consideraciones antes del abordaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Grados de complejidad de la obra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aspectos generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Los Sistemas de Informacin y las Bases de Datos .. . . . . . . . . . . . . . . . . . . . . . . . 2 Dato, informacin y conocimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Dato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Informacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Conocimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Modelos de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Sistema Objeto, Sistema de Informacin y Sistema de Datos . . . . . . . . . . . . 9 Fig. 1. Interrelacin entre SO, SI y SD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Esquema de archivos tradicionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Fig. 2. Esquema de archivos convencionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Fig. 3. Relacin Programas y archivos en un esquema convencional . . 13 Esquema de Bases de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Fig. 4. Esquema de procesamiento con Base de datos . . . . . . . . . . . . . . . . . . . 15 Fig. 5. Definicin de datos en un esquema de BD . . . . . . . . . . . . . . . . . . . . . . . . . 16 Tipos de Bases de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Bases de datos jerrquicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Fig. 6. Modelo de estructura jerrquica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Bases de datos de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Fig. 7. Modelo de estructura jerrquica en red . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Bases de datos relacionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Bases de datos orientadas a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Arquitectura de una Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Fig. 8. Separacin de niveles de abstraccin de una BD . . . . . . . . . . . . . . . . 25 Independencia de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Fig. 9. Independencia fsica de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Fig. 10. Independencia lgica de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proceso de diseo de una base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 3 Proceso de diseo de una base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ciclo de Vida de un SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fig. 1. Descomposicin del proceso de diseo de los datos . . . . . . . . . . . .
3
III
IV V
VI A
9 14 14 15 16 17 18 19 20 21 21 21 23 24 24 25 26 27 28 28 28 28 30 30 31 31 32 33 33 34 35 35 36 37 37 37 38 38 38 38 39 40 40 40 41 43 44 44 45
C D
4 Fig. 2. Separacin de Problemas Infolgico y Datalgico . 5 Modelo de datos y Modelo Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Fig. 3. Relacin entre el Modelo Conceptual y el Modelo Funcional . Enunciado de caso base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Caso Aprendiendo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . Diseo Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Modelo Entidad Relacin bsico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Fig. 1. Ejemplo de Relacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Fig. 2. Ejemplo de Relacin Unaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Fig. 3. Ejemplo de Relacin Binaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Fig. 4. Ejemplo de Relacin Ternaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Fig. 5. Ejemplo de relacin con atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Fig. 6. Ejemplo de cardinalidad muchos a muchos . . . . . . . . . . . . . . . . . . . . . . . . 9 Fig. 7. Ejemplo de cardinalidad uno a muchos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Fig. 8. Ejemplo de cardinalidad muchos a uno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Fig. 9. Ejemplo de cardinalidad uno a uno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Fig. 10. Ejemplo de cardinalidad cero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Cardinalidad de relaciones unarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Fig. 11. Ejemplo de cardinalidad unaria uno a uno . . . . . . . . . . . . . . . . . . . . . . . . 15 Fig. 12. Ejemplo de cardinalidad unaria uno a muchos . . . . . . . . . . . . . . . . . . . 16 Entidad Dbil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Fig. 13. Ejemplo de Entidad Dbil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Mantenimiento de un historial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Fig. 14. Ejemplo de atributo multivaluado con respecto a precios 20 Fig. 15. Ejemplo de atributo multivaluado con respecto a precios . . . povistos por mas de un proveedor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Notaciones Alternativas Diagrama Entidad Relacin . . . . . . . . . . . . . . . . . . . . 22 Notacin segn Chen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Fig. 16. Notacin segn Chen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Notacin alternativa 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Fig. 17. Notacin alternativa 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Notacin Alternativa 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Fig. 18. Notacin alternativa 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modelo E-R Extendido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Especializacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Fig. 1. Representacin de una especializacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Fig. 2. Representacin de una especializacin con sus atributos . . 4 Generalizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Fig. 3. Representacin de una generalizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Agregacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Fig. 4. Representacin de una relacin ternaria . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Fig. 5. Representacin de una relacin cuaternaria . . . . . . . . . . . . . . . . . . . . . . 9 Fig. 6. Representacin de una agregacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Casos Prcticos Diseo Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Caso 2K TRAINNING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Caso FARMACIA LA RURAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Caso TODO LIBRO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Caso CHICHO PETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Caso LA CLNICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resoluciones Casos Prcticos Diseo Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
47 47 48 49 50 53 54 56 56 57 57 57 58 59 59 60 60 61 61 61 61 62 62 63 63 63 63 66 66 66 66 66 67 67 69 70 70 71 72 72 72 72 73 74 75 77 78 79 80 82 85
1 H
Resolucin Caso FARMACIA LA RURAL . . . . . . . . . . . . . . . . . . .
87 88 89 90 90 91 91 92 93 94 94 95 95 96 97 97 98 98 99 99 100 100 100 100 101 101 102 102 102 103 103 103 104 104 105 105 105 106 109 110 111 114 116 117 120 123 126 127 130 133
2 Resolucin Caso LA CLNICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diseo Lgico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Cuadro 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Proceso de Normalizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Fig. 1. Ejemplo de Factura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Cuadro 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Cuadro 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Primera Forma Normal (1FN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Cuadro 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Cuadro 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Cuadro 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Segunda Forma Normal (2FN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Cuadro 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Tercera Forma Normal (3FN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Cuadro 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Cuadro Resumen FN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Relaciones N a N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Fig. 2. Representacin en el DER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Cuadro 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Relaciones Recursivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Cardinalidad 1 a 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Fig. 3. Relacin Recursiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Cuadro 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Cuadro 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Cuadro 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Cuadro 13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Cardinalidad 1 a N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Fig. 4. Relacin Recursiva 1 a N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Cuadro 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Cuadro 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Histrico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Cuadro 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Fig. 5. Prod y sus atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Fig. 6. Prod y sus atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Cuadro 17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Diagrama Lgico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Fig. 7. Diagrama lgico de Factura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Casos Prcticos Diseo Lgico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Caso COMERCOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Caso MAGIC FUN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Caso SOLAR COLLEGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Caso TODO LIBRO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Caso SICON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Caso SOLARIUM TOSTADITOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Caso SURTIDITO S.A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Caso CHICHO PETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Caso RENT A KAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Caso ABC MOVIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Caso TERRA CONTROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Caso E-BOLSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Caso BAUXITA & CO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Caso SUSODA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Caso CUKI S.R.L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Resolucin de Casos Prcticos Diseo Lgico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Resolucin Caso COMERCOM . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Resolucin Caso MAGIC FUN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Resolucin Caso SOLAR COLLEGE . . . . . . . . . . . . . . . . . . . . . . 4 Resolucin Caso RENT A KAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Resolucin Caso TERRA CONTROL . . . . . . . . . . . . . . . . . . . . . . . 6 Resolucin Caso BAUXITA & CO . . . . . . . . . . . . . . . . . . . . . . . . . 7 Resolucin Caso CUKI S.R.L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lenguaje de Definicin de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Lenguaje de Definicin de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 CREATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Cuadro 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Sintaxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Restriccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Tipos de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Cuadro 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Restricciones (Constraints) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 PRIMARY KEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 FOREIGN KEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Cuadro 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Cuadro 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 ALTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Cuadro 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 DROP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Casos Prcticos de DDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Caso CUKI S.R.L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Caso MAGIC FUN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Caso ABC MOVIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Caso TERRA CONTROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Caso SUSODA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Caso TODO LIBRO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Caso CHICHO PETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Caso E-BOLSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Caso SOLARIUM TOSTADITOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Resolucin de Casos Prcticos de DDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resolucin Caso CUKI S.R.L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Resolucin Caso TERRA CONTROL . . . . . . . . . . . . . . . . . . . 2 Uso de herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 DeZign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Definir un nuevo proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Definiendo el Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Creando las entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Definiendo las relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Agregando Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Definiendo las propiedades de los atributos . . . . . . . . . . . . . . . . . . . . . .
6
12
136 139 142 145 149 151 152 153 154 156 159 162 165 166 166 167 167 168 168 168 168 169 170 171 172 174 174 175 177 178 179 180 181 182 183 184 185 186 187 189 192 195 196 196 198 196 199 200 201
DBDesigner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Creando un Diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Definiendo una nueva entidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Definiendo una relacin entre dos entidades . . . . . . . . . . . . . . . . . . . . 4 Agregando atributos a nuestras entidades, y definiendo sus propiedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Cambiando las notacin de las relaciones . . . . . . . . . . . . . . . . . . . . . . . 6 Notacin Tradicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Notacin EER (1,n) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Casos Adicionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Caso SALIENDO DEL PASO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Caso WEBSHOPING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Caso ELECTRO VENTAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Caso LA TOALLITA LIMPIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Caso DON PEINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Caso VIAJE VELOZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Caso Caso SU PEDIDO . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . 7 Caso VAMOS A LA FERIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Caso EL PUBLICISTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Preguntas frecuentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Cuntos tipos de claves primarias existen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Cul es la cantidad mximas de atributos que pueden formar parte de una clave primaria o fornea? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Las claves primarias puede ser cualquier atributo o conjunto de atributos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Es coherente que existan dos tablas que tengan como clave primaria los mismos atributos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Cul es el sentido de generar una clave fornea? . . . . . 6 Puede existir ms de una clave fornea para una misma tabla? . . 7 Es necesario crear todas las restricciones de integridad (claves forneas) que sean posibles sobre un atributo o conjunto de atributos? 8 En que circunstancia es necesario crear claves forneas compuestas? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Las relaciones derivables son dibujadas en el diagrama lgico? 10 Respecto a las restricciones de dominio (Check), puede una misma restriccin afectar a ms de un campo? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Los campos que forman parte de la clave primaria se los debe declarar como Not Null? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Es necesario declarar todos los campos que no forman parte de la clave primaria como Not Null? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Se deben incluir en una tabla los campos calculables? . . . . . . . . . . . . . . . . 14 Para que se utilizan las entidades recursivas? .. . . . . . . . . . . . . . . . . . . . . . . . . 15 Puede existir el caso de que una entidad se relacione con otra a travs de dos atributos pero que uno sea parte de la clave primaria y el otro no? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 En un diagrama de entidad relacin pueden existir relaciones de muchos a muchos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Cmo me doy cuenta en el diagrama lgico de s la relacin es de uno a muchos o de muchos a muchos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 En un DER la cardinalidad de la relacin utilizada para representar la recursividad es de uno a muchos o de uno a uno? . . . . . . . . . . . . . . . . . . . . . . .
7
202 202 202 203 205 205 206 206 207 209 210 212 213 214 215 216 217 218 219 219 220 220 220 220 220 220 220 220 221 221 221 221 221 222 222 222 222 222 222 222 223 223 223 223 223 223 223 224 224 225 225
19 20 21
Tabla de histricos. Cmo se debe definir las claves para una tabla en la cul se desea llevar un histrico? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Una vez diseado el modelo. Como se hace para validarlo? . . Cmo se procede a borrar registros en tablas relacionadas? . . . . .
225 225 226 226
D
Diseo Conceptual
$ Objetivos
%Conocer los elementos que componen el modelo de Entidad-Relacin. %Adquirir destreza en el manejo y construccin de Diagramas de EntidadRelacin.
D. Diseo Conceptual En este captulo analizaremos la etapa de diseo conceptual de la metodologa propuesta en el Captulo B. En ella se parte de los datos obtenidos en el relevamiento y se formalizan en un modelo con un alto nivel de abstraccin. Hablamos de abstraccin, ya que se extraen del mundo real aquellos elementos y objetos con las propiedades que se consideran pertinentes para el anlisis que se efecta. El modelo ms difundido, que utilizaremos en el captulo es el conocido como Modelo de Entidad Relacin (MER). Con respecto a este nombre cabe sealar que gramaticalmente debera utilizarse Modelo Entidad Interrelacin, ya que deriva de la expresin inglesa relationship, que significa precisamente interrelacin. Por seguir la expresin ms difundida en la bibliografa castellana en este libro utilizaremos la primera expresin. El modelo fue propuesto por Chen en la dcada de los 70. Se focaliza en los datos, y no toma aspectos vinculados con los procesos. La versin bsica del modelo reconoce 3 elementos: las entidades, las relaciones y los atributos. Algunos autores agregaron con posterioridad otros conceptos para que el modelo fuera ms expresivo, arribando al conocido como MER extendido.
Modelo Entidad Relacin bsico Parte de 3 conceptos que son las entidades, las relaciones y los atributos.
Las entidades son elementos que existen en el sistema objeto de anlisis, y como tales necesito identificarlos dentro de mi modelo. Korth1, define a una entidad como: Una cosa u objeto en el mundo real que es distinguible de todos los dems objetos. Por Ejemplo Empleado es una entidad del sistema de sueldos, Autos es una entidad de un sistema de remises, etc.
El smbolo utilizado para representar una entidad es un rectngulo en cuyo interior se le agrega su nombre. El nombre de una entidad es un sustantivo escrito en singular. Por ejemplo, en el caso Aprendiendo existe una entidad que representa los asistentes a los cursos, que debera representarse de la siguiente manera:
Asistente
Los atributos son caractersticas de las entidades que considero necesario individualizar para mi modelo. Se representan a travs de un valo en cuyo centro se agrega el nombre; por ejemplo, el atributo nacionalidad de los asistentes se representara:
1 A. Silberschatz, H. Korth y S. Sudarshan. Fundamentos de Bases de Datos 5ta. Edicin. Edit. McGraw-Hill. 2006.
10
Nacionalidad
El modelo requiere que exista un atributo o conjunto de atributos que identifiquen inequvocamente a cada entidad. A este atributo o atributos se lo/s denomina/n identificador nico y se representa/n de la misma manera que cualquier atributo pero con su nombre subrayado. Por ejemplo, el campo Cdigo de Tema es el identificador nico de la entidad Tema, y se representa:
CodigoTema
El identificador nico debe ser uno o la conjuncin de varios atributos que en la entidad no pueda/n repetirse. Por ejemplo, en la entidad Asistente, la Fecha de Nacimiento no puede ser identificador nico porque pueden existir 2 asistentes que hayan nacido el mismo da. En cambio, el Cdigo de Asistente s, porque es un nmero que identifica a cada asistente individualmente, y 2 asistentes no van a tener nunca el mismo Cdigo.
Para que un atributo pueda ser considerado identificador nico tiene que existir una caracterstica adicional: el atributo debe ser conocido para todas las ocurrencias de la entidad. Por ejemplo, el campo Nmero de Documento puede ser considerado para que sea el identificador nico de la entidad Asistente ya que no van a existir 2 asistentes con el mismo nmero de documento, pero puede ocurrir que no sepamos el nmero de documento de todos los asistentes. En ese caso no podemos tomarlo como identificador nico.
Cuando existen 2 o ms atributos que puedan ser considerados identificadores nicos, debemos elegir uno de ellos como tal, y los que no hemos seleccionado pasan a ser claves candidatas.
Existen atributos que pueden tomar ms de un valor para cada ocurrencia de la entidad. Por ejemplo, si nos interesara conocer ms de una direccin (comercial, particular, etc.) de cada asistente, el atributo Direccin de la entidad asistente sera un atributo multivaluado. Se lo suele denominar tambin grupo repetitivo, grupo multivalor o atributo no atmico.
Ntese que en el ejemplo que dimos, es el diseador quien considera que Domicilio es un atributo multivaluado. Si por el contrario considerara que es necesario tener un solo domicilio, este sera entonces un atributo atmico. Con esto estamos queriendo decir que la representacin del modelo depender de las observaciones que rescatemos de la realidad que estamos representando.
11
Un atributo multivaluado se representa con un valo de doble lnea. Por ejemplo en el caso Aprendiendo, el atributo CodigoDocente es multivaluado en la entidad Curso, ya que muchos docentes pueden dictar el mismo curso. La representacin del atributo sera:
CodigoDocente
Existe otro tipo de atributo, que es el derivable, cuya caracterstica es que puede ser obtenido a travs de un clculo realizado a partir de otro atributo que conocemos. Por ejemplo, el atributo Edad de un Asistente del caso Aprendiendo, puede ser obtenido a partir de su Fecha de Nacimiento, que es un atributo que conocemos. Se representa a travs de un valo punteado; en ese ejemplo sera:
Edad
Relaciones Por la importancia y complejidad del tema le vamos a dedicar un apartado especial. Las relaciones (o interrelaciones como vimos al principio), son objetos que vinculan 2 o ms entidades, con un caso especial en que una entidad se vincula consigo misma. Por ejemplo, en el caso Aprendiendo, existe un relacin entre las entidades Provincia y Pas, ya que una Provincia pertenece a un Pas. El smbolo para representar una Relacin es un rombo con el nombre de la relacin en su interior (verbo seguido de una preposicin), y lneas que la conectan con las entidades que relaciona. Por ejemplo, en nuestro caso sera:
Provincia
Pertenece a un
Pas
Fig. 1. Ejemplo de Relacin
12
Una relacin puede vincular una, dos o ms entidades. A la cantidad de entidades que relaciona se lo llama grado de la relacin. As, si vincula una sola entidad se la denomina relacin unaria o de grado uno y se representa:
Fig. 2. Ejemplo de Relacin Unaria
Si relaciona a dos binaria o de grado dos y se representa:
Fig. 3. Ejemplo de Relacin Binaria
Si vincula a tres se la llama ternaria o de grado tres y su representacin:
Fig. 4. Ejemplo de Relacin Ternaria
13
As como las entidades tienen atributos, las relaciones tambin pueden tenerlos. Por ejemplo, en la relacin Rindi que vincula a las entidades Alumno y Examen, existen al menos 2 atributos que son Fecha de Examen y Nota, que no pertenecen a ninguna de las entidades individualmente, sino a la relacin, ya que representa la nota que un determinado alumno obtuvo en un determinado examen. Se representa de la siguiente manera:
Fecha
Nota
CodAlumno
Rindi
CodMateria
Fig. 5. Ejemplo de relacin con atributos
Salvo casos especiales que veremos mas adelante, el identificador nico de una relacin est formada por los identificadores nicos de las relaciones que une.
De acuerdo con la visin que se tenga del problema que se est analizando, las relaciones pueden tener algunas limitaciones, una de las cuales se denomina cardinalidad y es la cantidad de elementos de una entidad que pueden vincularse con los elementos de la otra.
Decimos que surge de la visin que se tenga del contexto, porque una misma relacin analizada de dos formas distintas puede producir cardinalidades tambin diferentes. Por ejemplo, analicemos la relacin Tiene por esposa, que vincula las entidades Empleado y Esposa. En un pas como la Argentina, la cardinalidad es de 1 a 1, ya que un hombre no puede tener ms de una esposa. En cambio, si el contexto es un pas que admite la bigamia, la cardinalidad de la relacin es de 1 a muchos, ya que un hombre puede tener ms de una esposa.
La notacin que utilizaremos para marcar cardinalidad es la de dos elementos separados por el signo dos puntos (:). Por ejemplo, la relacin uno a uno la marcaremos 1:1, y la relacin uno a muchos como 1:N. Cuando la cantidad de elementos es 1 o ms, se utilizan las letras M y N.
Las notaciones para relaciones binarias son las siguientes: ! Cardinalidad muchos a muchos (N:M). Ejemplo: La relacin Tiene a cargo, que vincula las entidades Profesor y Curso, en el caso en que un profesor puede tener varios cursos a cargo y un curso esta a cargo de ms de un profesor.
F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer 14
O N
Fig. 6. Ejemplo de cardinalidad muchos a muchos
! Cardinalidad uno a muchos (1:N). Ejemplo: la relacin Tiene que vincula a las entidades CabeceraFactura y RenglonesFactura.
O 1
Fig. 7. Ejemplo de cardinalidad uno a muchos ! Cardinalidad muchos a uno (N:1). Ejemplo: la relacin Tiene por encargado que vincula a las entidades Farmacia y Farmacutico, en el caso en que muchas farmacias son responsabilidad del mismo farmacutico.
15
O N
Fig. 8. Ejemplo de cardinalidad muchos a uno
! Cardinalidad uno a uno (1:1). Ejemplo: la relacin Existe un que vincula las entidades Ciudad y Farmacutico, en el caso en que exista un nico farmacutico por cada ciudad.
O 1
Fig. 9. Ejemplo de cardinalidad uno a uno
! Existe un caso particular de cardinalidad que es aquella en donde puede suceder que la cantidad mnima de ocurrencias sea cero; por ejemplo en la relacin Tiene por esposa, los casos de empleados solteros es cero esposa. La forma de anotar esta forma de cardinalidad opcional es:
16
Fig. 10. Ejemplo de cardinalidad cero
Cardinalidad de relaciones unarias Las relaciones unarias tambin poseen su cardinalidad. Tomemos como ejemplo la relacin Tiene por jefe, correspondiente a la entidad Empleado. Posee una cardinalidad 1 a 1, ya que las reglas de negocio relevadas establecen que un empleado tiene slo un jefe. El diagrama de la relacin es la siguiente:
Empleado
1 1
Tiene por Jefe
Fig. 11. Ejemplo de cardinalidad unaria uno a uno
En cambio, la relacin Tiene por lmite, correspondiente a la entidad Pas es de 1 a n, dado que un pas puede tener 0 (Cuba), 1 (Portugal) o muchos (Argentina) pases lmites. La representacin del modelo en un DER es equivalente para ambas situaciones con la diferencia de la cardinalidad de la relacin.
Pas
1 N
Tiene por Lmite
Fig. 12. Ejemplo de cardinalidad unaria uno a muchos
17
Entidad Dbil Es una entidad cuya existencia depende de la existencia previa de otra entidad, la que recibe el nombre de entidad fuerte. Individualmente la entidad dbil no posee los suficientes atributos para formar su clave primaria, por lo que debe complementarla heredando la clave primaria de la entidad de la que depende.
Representacin de una entidad dbil:
Hijo
Una relacin que une una entidad fuerte con una dbil se denomina relacin dbil y se representa:
Tiene por
Un ejemplo de entidad dbil es el caso de los hijos que puede tener un empleado. La entidad hijo no posee los atributos suficientes para formar su propia clave primaria, ya que aunque cada hijo puede ser identificado en forma unvoca por su nmero de documento, esto por s solo no indica de que empleado es hijo. Id_Emp Id_Emp Nombre Id_Hijo
Nombre
Empleado
Tiene por
Hijo
Fig. 13. Ejemplo de Entidad Dbil
18
Mantenimiento de un historial Un caso particular de atributo multivaluado que nos parece importante mencionar por su frecuente uso se da cuando deseamos conservar los precios de nuestros productos a lo largo del tiempo; es lo que genricamente se conoce como histrico de precios. El problema se plantea cuando queremos incluir el precio como atributo especfico de la entidad Producto. En realidad, el precio en este caso no depende nicamente del producto, sino adems del lapso en el que cada producto mantuvo el mismo precio. Tendremos as tantos precios del producto como veces se haya modificado a lo largo del tiempo. Podemos decir entonces que el precio es un atributo multivaluado de producto, que est tambin en funcin de la fecha a partir de la cual vari. La manera de representar esta situacin en un DER es la siguiente:
CProd
Desc 1 Tiene por Precio
Fecha
Precio
Producto
Precio
Fig. 14. Ejemplo de atributo multivaluado con respecto a precios
Tambin podemos mencionar el caso de los precios de los productos adquiridos a nuestros proveedores. Supongamos que un mismo producto lo puede proveer ms de un proveedor, y un proveedor puede proveer ms de un producto. Siendo importante poder conocer el precio al que comercializa cada producto un proveedor y como varia el mismo a travs del tiempo. La manera de representar esta situacin en un DER es la siguiente:
Fecha
Precio
Proveedor
Provisto por
Producto
Fig. 15. Ejemplo de atributo multivaluado con respecto a precios provistos por mas de un proveedor
19
Aqu puede observarse a diferencia del caso anterior que ahora los atributos precio y fecha no dependen de la entidad producto sino que son atributos exclusivos de la relacin provisto por existente entre las entidad producto y proveedor.
Importante Con todos estos elementos estamos en condiciones de resolver el punto 1 del caso Aprendiendo en su totalidad utilizando la simbologa propuesta por Chen, obteniendo como ya dijimos el producto de la etapa de Diseo Conceptual que es el Diagrama Entidad Relacin (DER)
20
21
Diseo y Modelado de Datos
Fundamentos de
Notaciones Alternativas Diagrama Entidad Relacin En relacin a la simbologa utilizada para expresar un Diagrama de Entidad relacin no existe una notacin nica que sea aceptada por todos los autores.
Nuestra intencin no es hacer prevalecer una notacin por sobre otras sino exponer algunas de las diferentes propuestas.
Para ello tomaremos a modo de ejemplo las entidades Curso y Docente conjuntamente con sus atributos y relaciones a los fines de expresar distintos tipos de notaciones.
Notacin segn Chen
Id_curso
Nombre Duracion
id_docente
Nombre
Requi sito
1 Curso N N Dicta N Docente
Fig. 16. Notacin segn Chen
Notacin alternativa 1
Requi sito
Curso
IdCurso Nombre Duracion Dicta
Docente
IdDocente Nombre
Fig. 17. Notacin alternativa 1
Atributos: Se colocan a la derecha de la entidad remarcando con un circulo relleno aquellos campos considerados como identificador nico.
22
Relaciones: En este caso se seala con una flecha para representar que un curso (el apuntado) puede ser prerrequisito de muchos otros. Para la relacin Dicta ambos extremos estn unidos por flecha lo cual representa una razn de cardinalidad de muchos a muchos.
Notacin Alternativa 2
Curso *Id_Curso Nombre Duracion Dicta
Docente *Id_docente Nombre
Fig. 18. Notacin alternativa 2
Como se visualiza en la figura, este enfoque con diagramas mas cercanos a UML utiliza rectngulos con puntas redondeadas para representar las entidades, sealando los identificadores nicos anteponiendo asteriscos a los atributos que forman parte del mismo y las relaciones toman la forma de los diagramas de Pata de Gallo para representar la razn de cardinalidad.
Adicionalmente desiste de la utilizacin de rombos para la representacin de las relaciones al utilizar simplemente rtulos sobre las lneas de las relaciones.
Puede profundizar ms estos conceptos leyendo el captulo 3 de Sistemas de Bases de Datos Diseo, Implementacin y Administracin 5ta Edicin de Rob Coronel. Edit. Thompson.
23
24
E
Modelo E-R Extendido
$ Objetivos
%Complementar el modelo E-R. %Dar a conocer nuevos conceptos que simplifican, o mejoran el modelado de datos. %Lograr un acercamiento a otros modelos, tales como el diagrama de clases y otros utilizados en el modelado de aplicaciones.
25
E. Modelo Entidad - Relacin Extendido La mayora de las veces resulta suficiente con el E-R tradicional pero hay veces en donde es necesario introducir conceptos adicionales tales como la herencia, la especializacin, generalizacin y agregacin. Estos conceptos derivan de modelos evolucionados orientados a objetos. A continuacin analizaremos cada uno de los conceptos nombrados.
Especializacin Hay casos en donde una entidad puede tener atributos compartidos y atributos propios, tal es el caso por ejemplo de la entidad persona, la cul puede compartir los atributos id_persona, nombre y apellido, mientras que a su vez puede derivarse en otras entidades de nivel inferior que poseen sus propios atributos, entindase como tales entidades de nivel inferior por ejemplo a alumno, docente y secretaria. Esto se llama especializacin. De esta forma la entidad secretaria podra contener atributos propios de ella tal como experiencia_en_la_posicion, estudio_protocolar, mientras que la entidad docente podra tener los suyos propios tales como posgrado_en_docencia, anios_en_la_docencia, etc. Lo mismo sucedera con la entidad alumno. De la misma forma se podran obtener especializaciones sobre las mismas entidades a su vez ms refinadas, tales como docentes con mas de 10 aos de servicio de los que no los cumplen, o alumnos con excelentes calificaciones de aquellos cuyas calificaciones son ordinarias. Generalmente una especializacin se modela con un tringulo y se suelen denominar a este tipo de relaciones como superclase-subclase, mientras que las entidades se representan mediante rectngulos. A saber:
Persona
ES
Secretaria
Docente
Alumno
Fig. 1. Representacin de una especializacin
26
A continuacin se ejemplifica el mismo caso pero agregndole los atributos propios correspondientes a cada entidad.
nombre Id_pers apellido
Persona
ES
Secretaria
Docente
Alumno
experiencia_en_l a_posicion anios_en_la_ docencia
posgrado_en _docencia
estudio_proto colar
Fig. 2. Representacin de una especializacin con sus atributos
De esta forma se puede observar que la superclase persona tiene como subclases a las entidades alumno, docente y secretaria, conteniendo cada una de estas subclase sus atributos propios. La especializacin permite manejar tambin el concepto de herencia ya que determinados atributos, o sea aquellos que pertenecen a la clase superior o superclase se definen una nica vez y en un nico lugar y se pueden reutilizar en las clases inferiores, mientras que los propios son definidos en el nivel inferior. La figura 2 representa un ejemplo de una jerarqua de entidades cuya herencia es nica, es decir hay un nico padre y tres hijos y estos ltimos a su vez no son superclase de ninguna otra entidad. En este caso la entidad secretaria, alumno y docente tienen sus propios atributos y a ellos debe sumrseles los que tienen en comn y son representados perteneciendo a la superclase persona.
27
Puede profundizar ms los conceptos de herencia leyendo el captulo 19 de Ingeniera de Software Un Enfoque Prctico 4ta Edicin de Pressman. Edit. Mc Graw Hill.
Generalizacin Por el contrario a la especializacin existe el concepto de generalizacin que busca imponer ciertas restricciones al modelo, tales como la pertenencia a entidades de niveles inferior. De esta forma una generalizacin es el ejemplo citado anteriormente como persona, o bien podramos clasificar a los alumnos en Alumnos_becado y Alumnos_no_becado, en este ltimo caso la generalizacin estara dada por la superclase Alumno. De esta forma especializacin y generalizacin son dos caras de una misma moneda.
Alumno
ES
Alumnos_becado
Alumnos_no_becado
Fig. 3. Representacin de una generalizacin Agregacin En el modelo E-R tradicional no es posible representar relaciones de relaciones. De tal forma si queremos representar una relacin entre Alumno, materia y sede, y a su vez representar que una comisin de enseanza tiene por objetivo la revisin de los contenidos de las materias dictados en determinada sede.
Alumno
Materia
Estudia
Sede
Fig. 4. Representacin de una relacin ternaria

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer 28
Sera necesaria la aparicin de una relacin que vincule Materia con Sede con comision_de_enseanza, de esta forma se podra crear una relacin cuaternaria que permita modelar tal realidad. Quedando representado de la siguiente forma.
Alumno
Materia
Estudia
Sede
Revisa
Comision_de_Enseanza
Fig. 5. Representacin de una relacin cuaternaria
La mejor forma de entender las relaciones anteriormente explicadas sera utilizar el concepto de agregacin , que es una abstraccin a travs de la cul las relaciones se tratan como entidades de nivel superior.
29
Alumno
Materia
Estudia
Sede
Revisa
Comision_de_Enseanza
Fig. 6. Representacin de una agregacin
Puede profundizar ms estos conceptos leyendo los captulos 2 y 6 de Fundamentos de Bases de Datos 5ta Edicin de Silberschatz Korth y Sudarshan. Edit. Mc Graw Hill.
30
F
Casos Prcticos Diseo Conceptual
$ Objetivos
%Distinguir los conceptos de atributo multivaluado, dependencia funcional y dependencia transitiva. %Lograr habilidades para manejar fluidamente el proceso de conversin de estructuras de datos redundantes en estructuras normalizadas.
31
Importante Recuerde que un mismo ejercicio puede admitir en algn punto distintas soluciones a un mismo requerimiento, por lo que a continuacin se presenta una solucin propuesta para cada ejercicio, pudiendo alguna de ellas diferir en algn grado de la solucin desarrollada por usted, ante esto resulta de vital importancia asegurarse de que lo diseado por usted sea compatible con lo expresado en el relevamiento, no se olvide que el ltimo paso de un buen diseo es testear que el modelo diseado sea compatible con la realidad relevada.
Importante Algunas de las soluciones a los ejercicios planteadas en ste capitulo se las pueden encontrar en el captulo G. Resoluciones Diseo Conceptual.
32
F.1. Caso 2K TRAINNING La empresa 2K TRAINNING ha decidido comenzar con un proceso de informatizacin de su sistema de manejo de cursos, el cul actualmente es manejado mediante planillas de clculo y formularios manuales. Para llevar a cabo esta tarea se ha decidido contratar a un profesional o estudiante avanzado de la carrera de sistemas de informacin, por lo que usted ha sido seleccionado para realizar dicha tarea. De las reuniones mantenidas por usted con el personal de las distintas reas de la compaa se obtuvieron los siguientes puntos a ser contemplados por el sistema a ser desarrollado: De los alumnos se necesita disponer de la siguiente informacin: DNI, Apellido y nombre, domicilio (calle y nmero), telfono/s y edad. Del telfono hay que conocer adems del nmero su tipo (ej. Particular, Celular). Cada carrera dictada posee su propio plan de estudios, el cul a su vez posee una cantidad determinada de materias. A su vez para cada materia se ofrece una variedad de cursos, estando cada curso a cargo de un docente y en horarios distintos. En cada curso slo se dicta una nica materia y un mismo docente puede tener a su cargo ms de un curso de la misma o de diferentes materias. Los alumnos al momento de inscribirse no eligen solamente materia, sino que eligen materia y dentro de esta el curso en el que desean cursar. Es importante conocer las materias en las que el alumno se inscribi, la fecha de inscripcin y la nota final obtenida. De cada docente se debe conocer: DNI, apellido y nombre. Algunos profesores tienen un supervisor (slo uno), que es otro profesor. De cada curso es importante conocer a que materia pertenece, quin es el docente a cargo, la carga horaria (cantidad de horas a la semana), el/los das que se dicta y el horario, tener presente que no necesariamente el horario es el mismo para todos los das en que se dicta el curso.
Se pide 1. Desarrollar el Modelo Conceptual, definiendo las entidades, los atributos de cada una de ellas y la cardinalidad de las relaciones.
33
F.2. Caso FARMACIA LA RURAL Usted ha sido contratado con el motivo de disear una base de datos para una cadena de farmacias. De las entrevistas mantenidas con el personal de la empresa durante la etapa de relevamiento se obtuvieron los siguientes puntos a ser considerados: Las sucursales se encuentran distribuidas en diferentes ciudades. Cada farmacia tiene sus propios empleados y un farmacutico a cargo de la misma. Del personal propio adems de su nombre hay que poder conocer su fecha de ingreso a la empresa, antigedad, direccin (solo interesa calle y nmero). Por cada ciudad hay un nico farmacutico; es decir, si en una misma ciudad existe ms de una farmacia, entonces el mismo farmacutico estara afectado a todas las farmacias de esa ciudad. Cada farmacia tiene a su vez su propio stock de medicamentos, siendo el mismo organizado por medicamento. Por cada medicamento se guarda su precio, el laboratorio al que pertenece, la cantidad en existencia del mismo y la forma de presentacin. Cada medicamento puede venir en muchas formas de presentacin distintas pero es producido por un nico laboratorio.
34
F.3. Caso TODO LIBRO La empresa TODO LIBRO se dedica a la compra-venta y distribucin de libros. Posee una casa central y tres sucursales, situadas en Paran, Rosario, y la ltima en La Plata. La Casa Central esta ubicada en la Capital Federal. Cada sucursal cuenta con un nmero determinado de vendedores que brindan una atencin personalizada a cada cliente. La empresa se destaca por tener libros especializados en distintas ramas del conocimiento, Tales como matemticas, ciencias mdicas, deportes, astrologa, jardinera, cocina, historia, animales y teologa. Los empleados pertenecen a una sucursal determinada por un tiempo determinado, pudindose dar el caso de que un vendedor sea trasladado de una sucursal a otra. Por lo que es importante conocer las distintas sucursales por las que paso un vendedor. La empresa TODO LIBRO recibe de cada Editorial los libros que compra mensualmente. Al final de cada mes, el gerente de la central Buenos Aires, Ernesto Zapata, realiza un ranking de ventas por empleado en cada una de las sucursales, recibiendo el mejor vendedor de cada sucursal un estmulo econmico, por el desempeo alcanzado. Los datos que se necesita guardar de un libro son el tema, el/los autores, la fecha de publicacin, cantidad de paginas, y la editorial del mismo. Tambin se realiza un ranking anual de ventas por sucursal determinando la sucursal que ms ventas realiz en un perodo de un ao. Esto permite mejorar las comisiones percibidas por los vendedores.
Consideraciones adicionales ! Cada libro tiene un cdigo nico de identificacin. ! No todos los ttulos son comercializados por todas las editoriales. ! Las ventas son registradas mediante la emisin de una factura en la cul se incluyen los siguientes datos: Nmero de factura, fecha, cliente, sucursal, vendedor, libro, editorial, cantidad, importe.
35
F.4. Caso CHICHO PETS CHICHO PETS es una veterinaria de barrio que se dedica al cuidado de mascotas. Desde sus comienzos, la poltica de la empresa ha sido atender a los animales como si fueran humanos. Tal hecho nos brinda un acercamiento a la forma de pensar de su dueo. Dado que la veterinaria esta creciendo y volvindose cada vez ms conocida, ya no es posible llevar manualmente la registracin de las operaciones. Es por tal motivo que, Ayrton, dueo de CHICHO PETS, tiene intenciones de utilizar una base de datos para registrar toda su actividad comercial. CHICHO PETS presta atencin a diversos tipos de mascotas: aves, gatos y peces, pero su principal inters reside en los canes. Entre las cuestiones pensadas para mejorar su gestin se encuentra el hecho de brindar una atencin personalizada a cada mascota. Es por eso que Ayrton piensa en la idea de ofrecer una mutual y gestionar la afiliacin de socios. De esta forma, cada socio abonara un arancel mensual que le posibilitara acceder a un set de servicios variados tales como vacunas, internaciones, belleza y cuidados intensivos. Cada plan posee una cierta cantidad de servicios cubiertos por el mismo, por lo que es importante conocer los servicios cubiertos por cada plan. Dependiendo de cada plan, se ofrecen diversos descuentos en los servicios prestados por CHICHO PETS. En el caso del plan Premium, este cubre todos los costos generados por un animal al momento de su atencin. El sistema debe permitir la posibilidad de llevar un historial de visitas por mascota, de tal forma que permita realizar un seguimiento completo del animal desde que fue atendido por primera vez en CHICHO PETS. Los datos que se desea guardar son: Identificador de la mascota, fecha de atencin, estudios (servicios) que se le realizaron, diagnstico y profesional que la atendi. Entre los datos que se guardan cada vez que se da de alta un socio, se encuentran el nombre de la mascota, su fecha de nacimiento y nombre de su dueo. En CHICHO PETS se sostiene que si a una mascota se la alimenta inadecuadamente la misma puede llegar a enfermarse. Es por tal motivo que adicionalmente tambin se dedica a la elaboracin de dietas especiales para animales. La empresa cuenta con proveedores de alimentos especializados en mascotas, un mismo alimento puede ser provisto por ms de un proveedor. Compramos alimentos de la mejor calidad, y elaboramos segn su mascota el alimento mas adecuado..., nos cuenta Ayrton. Cada alimento contiene una composicin determinada de vitaminas y minerales.
36
De los alimentos comercializados es importante conocer en detalle su composicin (insumos que lo forman) como as tambin la medida de cada uno de estos elementos. Tener presente que los elementos poseen una unidad de medida (litros, milmetro cbico, etc.) y que no necesariamente todos se encuentran expresados en la misma unidad.
Consideraciones adicionales En la visita de cada mascota se registran datos como la fecha de la consulta, su peso, estudio realizado y el estado general de la mascota. Los Estados Generales de cada mascota pueden ser: ! Sano. ! Enfermo. ! Comprometido. ! Delicado. Como el monto de la cuota mensual para cada plan puede variar en el tiempo es importante conocer como vari la misma. Los planes alimentarios son diseados en forma personalizada para cada mascota y pueden variar con el tiempo por lo que es importante conocer los distintos planes que se arm para la mascota. No necesariamente el nmero de historia clnica coincide con el de mascota. La composicin de un alimento no necesariamente es la misma para todos los proveedores de dicho alimento.
37
F.5. Caso LA CLNICA Una clnica de la ciudad presenta la necesidad de manipular y almacenar todo tipo de informacin que pueda estar relacionada con ella. En una reunin mantenida con el personal de la clnica se obtuvo la siguiente informacin. La clnica cuenta con una estructura fsica de tres torres, de las cuales dos son para hospitalizacin y cirugas y una para consulta. A su vez las torres de hospitalizacin se encuentran divididas en habitaciones mientras que la de consulta en consultorios. Por cada habitacin o consultorio es importante conocer su ubicacin (torre, piso y nmero), longitud (ancho y largo). A su vez por cada habitacin tambin se necesita conocer que comodidades posee, a saber: ! Cantidad de baos. ! Si posee clset. ! Cantidad de camas. ! Si posee ventana. Es importante tambin conocer quien est ocupando cada habitacin, desde cuando lo hace y por cuanto tiempo est previsto que la ocupe. En cuanto a los consultorios, estos son utilizados para atender las consultas realizadas por los distintos servicios prestados por la clnica (cardiologa, pediatra, fisioterapia, etc.). Respecto de los pacientes cada uno es identificado con un nmero nico y los datos guardados son su nombre, fecha de nacimiento, edad, telfono/s y prepaga que posee. Todo paciente posee una historia clnica (el nmero de historia coincide con el de paciente) y en esta se registran todas las consultas realizadas por el paciente, guardndose la fecha de consulta, el profesional que lo atendi, el motivo de la consulta (servicio) y el diagnstico. De cada profesional se guarda su nombre, telfono particular, telfono para urgencias y especialidad. Una caracterstica importante es que un doctor puede dirigir un rea especfica como ser por ejemplo pediatra o cardiologa, por lo que para un jefe de rea es importante saber que personal tiene a su cargo. De la torre tambin es importante conocer su direccin, la cul se compone por calle, nmero, piso y departamento.
38
39

Morteo y Otros - Fundamentos de Diseño y Modelado de Datos

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Morteo y Otros - Fundamentos de Diseño y Modelado de Datos

Încărcat de

Drepturi de autor:

Formate disponibile

Fundamentos de Diseo y Modelado de Datos

Nicols L.E. Bocalandro

Fundamentos de Diseo y Modelado de Datos

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

Resolucin Caso FARMACIA LA RURAL . . . . . . . . . . . . . . . . . . .

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

225 225 226 226

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

Fig. 1. Ejemplo de Relacin

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

Fig. 2. Ejemplo de Relacin Unaria

Si relaciona a dos binaria o de grado dos y se representa:

Fig. 3. Ejemplo de Relacin Binaria

Si vincula a tres se la llama ternaria o de grado tres y su representacin:

Fig. 4. Ejemplo de Relacin Ternaria

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

Fig. 5. Ejemplo de relacin con atributos

Fundamentos de Diseo y Modelado de Datos

Fig. 6. Ejemplo de cardinalidad muchos a muchos

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

Fig. 8. Ejemplo de cardinalidad muchos a uno

Fig. 9. Ejemplo de cardinalidad uno a uno

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

Fig. 10. Ejemplo de cardinalidad cero

Tiene por Jefe

Fig. 11. Ejemplo de cardinalidad unaria uno a uno

Tiene por Lmite

Fig. 12. Ejemplo de cardinalidad unaria uno a muchos

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

Representacin de una entidad dbil:

Fig. 13. Ejemplo de Entidad Dbil

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

Desc 1 Tiene por Precio

Fig. 14. Ejemplo de atributo multivaluado con respecto a precios

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Fundamentos de Diseo y Modelado de Datos

F Morteo ! N Bocalandro ! C Cascn ! H Cascn ! C Descalzo ! K De Rosa ! D Krauthamer

Diseo y Modelado de Datos