Modelacin de datos

Unidad I. Anlisis y Diseo Parte III Modelos E - R Ing. en Computacin Inteligente 4 semestre Profesor: Dr. Carlos Argelio Arvalo Mercado

Contenido

Qu es el modelado de datos? Por qu modelar los datos por separado? Historia del modelo conceptual de datos Modelo Entidad Relacin (E-R) Conceptos Notacin Construccin Jerarqua de modelos Transformacin a tablas Balanceo de modelos

UAA - Carlos Arvalo 2013

Que es el modelado de datos?

Los Diagramas de Flujo de Datos (DFDs) ayudan a comprender los procesos de un sistema, y aunque se muestran los flujos y almacenes de datos, stos no proporcionan una comprensin detallada y profunda del sistema desde el punto de vista de la estructura de los datos almacenados.
La tcnica usada para obtener una mayor comprensin de los datos de un sistema se denomina modelado de datos. En ocasiones se utiliza el trmino anlisis de datos.

UAA - Carlos Arvalo 2013

Por qu modelar los datos de un sistema?

Porque las estructuras de datos y las relaciones entre ellos pueden ser tan complejas que se desear enfatizarlas independientemente de los procesos. A los gerentes y administradores suelen interesarles ms los datos que los detalles funcionales. Tal vez se requiera comunicacin con los administradores de datos para integrar el nuevo sistema con el resto de la arquitectura de informacin corporativa. Para el analista, los diagramas E-R representan el beneficio de enfatizar las relaciones entre almacenes de datos en el DFD, que de otra forma se hubieran visto solo en las p-specs

UAA - Carlos Arvalo 2013

Porque se requiere una comprensin detallada de los datos?

En metodologas anteriores, el modelado de datos era una tcnica que se practicaba en la fase de diseo y no en el anlisis. Ahora se considera tanto una tcnica de anlisis como de diseo, ya que se reconoce que si se logra obtener una mejor comprensin de los datos de manera temprana, el sistema final ser ms robusto y flexible. Otra razn es que los datos tienen una estructura relativamente mas estable que los procesos, los cuales probablemente requerirn ms cambios a lo largo del ciclo de vida del sistema. Finalmente, si el sistema que se va a desarrollar estar basado en computadoras, el modelo de datos ser la base para crear la base de datos fsica del mismo.

UAA - Carlos Arvalo 2013

Importancia del modelado de datos

El modelado es la actividad ms delicada e importante en la realizacin de una aplicacin con base de datos Al igual que en el desarrollo de un sistema, toda modificacin al esquema de base de datos debe realizarse primero en el modelo conceptual, no en el lgico ni en el fsico. La habilidad de crear buenos modelos es una cualidad que se adquiere con la experiencia.
6

UAA - Carlos Arvalo 2013

Historia del Modelo conceptual de datos

El modelo conceptual de datos fue propuesto por Peter Chen en 19761, y hasta la fecha ha sido ampliado con extensiones por diversos autores. Describe el mundo real como un conjunto de entidades y las relaciones que existen entre ellas. Su uso est muy extendido como mtodo de diseo de bases de datos y por muchas herramientas de ingeniera de software asistido por computadora (CASE).
1Peter

Chen, The Entity Relationship Model: Toward A Unified View of Data, ACM Transactions on Database Systems, Vol. 1, nmero 1 (marzo de 1976), pp 9-36

UAA - Carlos Arvalo 2013

Modelo Entidad-Relacin

Un modelo entidad relacin es una forma efectiva de integrar y documentar los requerimientos de informacin del usuario: Los usuarios pueden entender fcilmente el formato grfico del modelo. El modelo E-R puede ser fcilmente desarrollado y refinado. un modelo E-R provee una clara imagen del alcance de los requerimientos de informacin del usuario. Provee una estructura adecuada para la integracin de mltiples aplicaciones.

UAA - Carlos Arvalo 2013

Conceptos de un modelo E-R

Atributos Compuestos (varios datos en misma columna)

Atributos (columnas)
Llave (Identifica el
Rengln completo)

Entidad (Una Tabla)

Llave fornea (es llave en otra Entidad)

Instancias (renglones)

UAA - Carlos Arvalo 2013

Notacin

10

Estndares de notacin (IE2 Pata de Gallo)

Las entidades se representan como cajas de cualquier dimensin con las esquinas redondeadas, Un nombre nico para cada entidad. Nombre de la entidad en maysculas y en singular. Nombre de los atributos en minsculas. La llave se identifica por separarse del resto de los atributos mediante una lnea Las llaves forneas se identifican con las siglas FK Una llave fornea puede ser parte de la llave primaria de una entidad

2James

Martin, Computer Database Organization, Englewood Cliffs, N.J. Prentice-Hall, 1982. UAA - Carlos Arvalo 2013

11

Estndares de notacin

Resumen de notacin de relaciones:

UAA - Carlos Arvalo 2013

12

Otras notaciones (Chen)

UAA - Carlos Arvalo 2013

13

Conceptos bsicos

Conceptos

Entidad. Una entidad es un objeto (un sustantivo) a travs del cual se identifica una persona, animal, cosa, concepto, organizacin, etc. y sobre el cual tenemos inters en guardar informacin identificada con atributos de ese sustantivo. Atributo: es una caracterstica de una entidad o relacin. Ej. Altura, peso, direccin, telfono, etc. de un estudiante. Compuestos: pueden derivarse en otros con significado propio. P.ej. Fecha = dia + mes + ao Simples o atmicos: ya no pueden descomponerse en otros datos. P.ej. Gnero, estado civil.. Instancia: Un conjunto de atributos definen una instancia. Es sinnimo de registro. Llave: es el conjunto mnimo de atributos de una entidad cuya tarea es identificar de manera nica a una instancia. Llave fornea: Es el atributo o conjunto de atributos de una instancia o relacin que son la llave primaria de otra relacin Entidad Fuerte Regular: Es la entidad cuya llave identifica de manera nica a cada una de sus instancias. Entidad dbil: No tiene atributos llave propios. Existe solo por el hecho de que existan otras entidades. Algunos o todos sus atributos claves pertenecen a otras entidades (ver mas adelante relacin de tipo M-M)

UAA - Carlos Arvalo 2013

15

Relaciones y cardinalidades

16

Relacin y cardinalidad

Relacin. Una relacin representa la asociacin entre entidades. Cardinalidades. Dadas dos instancias A y B: 1 a 1: cada instancia de la entidad A est asociada cuando mucho con una instancia de la entidad B y viceversa. 1 a M: cada instancia de la entidad A se asocia con cero, una o ms instancias de la entidad B, pero cada instancia de B se asocia cuando mucho con una instancia de A. M a N: cada instancia de la entidad A se asocia con cero, una o ms instancias de la entidad B y cada instancia de B se asocia con cero, una o ms instancias de A.

UAA - Carlos Arvalo 2013

17

Relacin de cardinalidad 1:1

Proyecto clave 12344 44321 Nombre inicio fin Desarrollo de redes academicas 01/01/2010 31/12/2010 Verificacin emprica de mtricas 01/01/2010 31/12/2010

ID 55577 10134

Nombres Carlos Argelio Jorge Eduardo

Profesor Apellidos Depto Arvalo Mercado Sistemas de Informacin Macias Luevano Sistemas de Informacin

La relacin debe leerse como: Un profesor es responsable de un proyecto, y un proyecto Tiene un solo responsable 1:1
UAA - Carlos Arvalo 2013

18

Relacin 1:M

La relacin debe leerse como: una carrera puede tener M alumnos y un alumno pertenece a UNA y solo UNA carrera 1:M
UAA - Carlos Arvalo 2013

19

Relacin M:M
Alumno Apellidos Reyes Romo Avliez Cisneros Ferrer Camorlinga Cedillo Zaragoza Martinez Chavez

ID 30458 92519 30206 118598 128670

Nombres Nacy Pamela Israel Antonio Viridiana Leticia Rogelio

Cve_Carrera 7-76 7-76 7-76 7-60 7-60

Clave 14131 11768 11567 11345

Materia Nombre Introduccin a los sistemas de Informacin Analisis y diseo de sistemas Simulacin Analisis y Diseo orientado a objetos

Cve_profesor 55577 55577 10134 10134

La relacin debe leerse: Un alumno puede cursar 1 o ms materias y una materia puede ser cursada por 1 o ms alumnos M:M
UAA - Carlos Arvalo 2013

20

Tipos de relaciones

21

Tipos de relaciones, segn el diseo y comportamiento de sus llaves

Identificadoras

Relaciones

Con nulos (opcional) No-Identificadoras Sin nulos (obligatoria)

UAA - Carlos Arvalo 2013

22

Relacin identificadora (Identifying relationship)

Una relacin identificadora es aquella que se da entre dos entidades, en las cuales cada instancia de la entidad hija es identificada SOLO a travs de su asociacin con su entidad padre. Lo anterior significa que este tipo de relacin la entidad hija es DEPENDIENTE de la entidad padre para identificar sus renglones. En una relacin identificadora, una instancia de la entidad padre esta relacionada con mltiples instancias de la entidad hija (1:N)

UAA - Carlos Arvalo 2013

23

Ejemplo de relacin identificadora

Movie Movie-rental Movie-number Movie-Rating rate 1 G 5 2 PG-13 5 3 PG-13 5 4 R 5 customer status OK OK OK OK
Movie Copy MovieMasternumber Number 1 1 1 1 1 1 2 1 2 1 2 1

Movie Copynumber 1 2 3 1 2 3

Generalcondition OK OK OK BAD OK OK

En este diseo, la llave de la entidad movie-copy es una llave compuesta, formada por Movie-copy-number (cuyos valores se repiten) y el Movie-number (que tambin se repiten). PERO LA COMBINACIN DE AMBOS VALORES NO SE REPITE NUNCA, SIRIVIENDO AMBOS COMO LLAVE. Este diseo tambin exige que exista un valor en la tabla Movie-copy, que la relacione con la tabla Movie
UAA - Carlos Arvalo 2013

24

Prctica 1

Crear dos tablas, crear la relacin y capturar datos los datos del ejemplo anterior en MSAccess

UAA - Carlos Arvalo 2013

25

Relacin No-identificadora (Non-Identifying relationship)

Una relacin no identificadora es aquella relacin entre dos entidades en la cual una instancia de la entidad hija no es identificada a travs de su relacin con una entidad padre. Lo anterior quiere decir que la entidad hija NO ES DEPENDIENTE de la entidad padre para identificar a sus instancias y puede existir sin ella. En una relacin No-identificadora, una instancia de la entidad padre est relacionada con mltiples instancias de la entidad hija (1:N) Existen dos tipos de relaciones no-identificadoras:

opcionales y obligatorias.

UAA - Carlos Arvalo 2013

26

Relacin No-identificadora opcional

En una relacin no-identificadora opcional, los atributos que no son llave de la entidad hija no son necesarios en la entidad hija (pueden no tener datos)

Lo anterior significa que en este tipo de diseo EST PERMITIDOS QUE LA LLAVE FORNEA NO TENGA VALORES

UAA - Carlos Arvalo 2013

27

Notacin para una relacin No-identificadora opcional

Movie Movie-rental Movie-number Movie-Rating rate 1 G 5 2 PG-13 5 3 PG-13 5 4 R 5 customer status OK OK OK OK

Movie-copy Movie-copy- Movie Masternumber number Number 00001 1 1 00002 1 1 00003 1 1 00004 2 1 00005 null 1 00006 null 2

Generalcondition OK OK OK BAD OK OK

En este diseo, la llave de la entidad movie-copy est formada solamente por la columna movie-copynumber, (cuyos valores en este caso no se repiten) y la columna Movie-number (la llave fornea) PUEDE tener valores que no estn relacionados con la tabla Movie (valores nulos o vacios)
UAA - Carlos Arvalo 2013

28

Prctica 2

Modificar las tablas, llaves y la relacin creadas en MS-Access, para representar la relacin noidentificadora opcional

UAA - Carlos Arvalo 2013

29

Relacin No-identificadora obligatoria

En una relacin No-identificadora obligatoria, los atributos que estn en la parte no-llave de la entidad hija, son requeridos forzosamente en la entidad hija

Esto significa que la LLAVE FORNEA NO PUEDE SER NULA

UAA - Carlos Arvalo 2013

30

Notacin para una relacin No-identificadora obligatoria

Movie Movie-rental Movie-number Movie-Rating rate 1 G 5 2 PG-13 5 3 PG-13 5 4 R 5 customer status OK OK OK OK

Movie-copy Movie-copy- Movie Masternumber number Number 00001 1 1 00002 1 1 00003 1 1 00004 2 1 00005 3 1 00006 4 2

Generalcondition OK OK OK BAD OK OK

En este diseo, la llave de la entidad movie-copy es solamente movie-copy-number, (porque en este caso sus valores no se repiten) y la columna Movienumber (la llave fornea) DEBE estar relacionada con un valor de la tabla Movie

UAA - Carlos Arvalo 2013

31

Prctica 3

Modificar las tablas, llaves y la relacin creadas en MS-Access, para representar la relacin noidentificadora obligatoria

UAA - Carlos Arvalo 2013

32

El caso especial de la Relacin M:M

Se reemplaza o resuelve una relacin M:M con una entidad interseccin nueva y con dos relaciones M:1. Las relaciones desde una entidad interseccin son siempre obligatorias Las entidades interseccin son muy comunes para representar situaciones de negocios del mundo real Las entidades interseccin normalmente generan requerimientos de atributos adicionales, como el uso de cantidades y fechas. Tienden a tener alto volumen de registros. Los atributos de la entidad interseccin se forman con las llaves primarias de las entidades originales, que pasan como llaves forneas a la entidad interseccin.
33

UAA - Carlos Arvalo 2013

Pasos para construir un diagrama entidadrelacin

1. Identificar las entidades dentro del sistema: para ello, debe conocerse el funcionamiento del sistema en estudio, a travs de estudios de usuarios, de necesidades de informacin, de tipos de informacin, etc. Como gua puede utilizarse para la definicin de las entidades objetos reales, personas, objetos abstractos, etc. Identificar y describir los atributos de cada entidad: sealar aquellas propiedades de la entidad de inters para el sistema. Determinar las claves o identificadores de entidades: sealar aquellos atributos que identifiquen inequvocamente cada ocurrencia de la entidad, y que no puedan ofrecer valores nulos. Establecer las relaciones entre la entidades: estudiar las asociaciones entre las entidades, para definir su importancia dentro del contexto del sistema. Obtener su cardinalidad. (CONSIDERAR EL CASO ESPECIAL M:M) Verificaciones: eliminacin de las relaciones redundantes (o innecesarias) que puedan ser obtenidas a travs de combinar otras asociaciones.

2.

3.

UAA - Carlos Arvalo 2013

34

Jerarqua de modelos de datos

35

Jerarqua de modelos de datos

Frecuentemente, durante el anlisis se hace referencia a muchos modelos. Particularmente, la jerarqua de los modelos de datos puede entenderse bajo la siguiente secuencia: Modelo Conceptual (E-R) 2. Modelo Relacional o Lgico (Tablas Relacionales) 3. Modelo Fsico (Implementacin en un DBMS)
1.

NOTA: Con herramientas CASE de modelado de datos, esta jerarqua de modelos puede caracterizarse en un solo paso, mediante la exportacin del modelo E-R al modelo fsico de implementacin (relacional)
UAA - Carlos Arvalo 2013

36

Transformacin a tablas

La transformacin del Modelo E-R al Modelo Relacional Lgico (conjunto de tablas), debe hacerse observando las siguientes reglas: Toda entidad es una tabla, sus campos, por lo tanto, son los atributos que se encuentren en la misma. Cardinalidades:

1 a 1: La llave de la entidad de un archivo pasa como llave fornea a la entidad del otro archivo. La persona encargada de la conversin, toma la decisin de decidir a cual tabla agregar esa llave. 1 a N: En este caso, la llave de la entidad con cardinalidad uno (1), pasa como llave fornea a la tabla con cardinalidad de muchos (N). M a M: En esta situacin, Se crea una nueva tabla con las llaves de las entidades de las entidades involucradas en la relacin. La nueva tabla debe llevar el nombre de la relacin. (se puede poner en el E-R la nueva tabla, que tendr una relacin M a 1 con las entidades relacionadas)

UAA - Carlos Arvalo 2013

37

Ejemplo de modelo fsico [de datos]

UAA - Carlos Arvalo 2013

38

Cul modelo desarrollar primero?

Algunos estudiosos se preguntan si debe desarrollarse primero el DFD y luego el ER, o a la inversa. Algunos, incluso preguntan si es necesario desarrollar ambos modelos. Realmente tiene importancia tener dos modelos distintos de un mismo sistema? Esto depende del tipo de sistema que se va a desarrollar: 1. Si el sistema es muy complejo en cuanto a procesos y funciones, pero con estructuras de datos relativamente sencillas. 2. Algunos sistemas de apoyo a decisiones y de sistemas de bases de datos contienen complejas relaciones de datos, pero casi nada de actividades funcionales. 3. Si el sistema es sencillo y unidimensional, el analista puede concentrarse en la herramienta de modelado que enfatiza el aspecto ms importante del sistema.

UAA - Carlos Arvalo 2013

39