1. INTRODUCCIÓN A LA MODELIZACIÓN CONCEPTUAL DE DATOS

Análisis y Diseño de Sistemas de Información II

TEMA 5: MODELIZACIÓN CONCEPTUAL DE DATOS 1. INTRODUCCIÓN A LA MODELIZACIÓN CONCEPTUAL DE DATOS 2. MODELO CONCEPTUAL DE DATOS 2.1. Características Generales. 2.2. Pasos para su Desarrollo. 2.3. Añadir Detalles al Modelo 3. RELACIONES COMPLEJAS 4. REGLAS DE FUNCIONAMIENTO 5. DOCUMENTACIÓN DEL MODELO ANEXO: Consistencia entre Modelos

1. INTRODUCCIÓN A LA MODELIZACIÓN CONCEPTUAL DE DATOS Representa Información lógica de un sistema Estructura Reglas EL DISEÑO CONCEPTUAL es un esquema o descripción de alto nivel de la estructura de los datos de un sistema independientemente de la implementación posterior de la base de datos. CARACTERÍSTICAS - Es un proceso dirigido completamente a los datos. - Enfatiza la comprensión de los requerimientos de información del sistema. - Permite una mejor comunicación entre usuarios, analistas y programadores durante toda las fases del diseño. - Proporcionará las bases para diseñar una base de datos del sistema correcta, consistente, compartible y flexible. CUESTIONES (qué debe plantearse el analista para su desarrollo?) Principal información Objetos de interés Detalles que los caracterizan Cómo están relacionados 1

Análisis y Diseño de Sistemas de Información II

FACTORES CRÍTICOS: - Trabajar interactivamente con los usuarios - Seguir una metodología (pasos para su desarrollo) - Considerar tanto la estructura de la información como la integridad de la misma. (parte del principio del dominio de la información) - Utilizar diagramas para representar el modelo de datos lógico (principio de modelado) - Construir un diccionario de datos BENEFICIOS - Un correcto diseño de la base de datos. - Ayuda a valorar cuál es la tecnología óptima para desarrollar la base de datos del sistema. - Permite reconocer como van a afectar posibles cambios en el futuro. - Permite a los usuarios comprender cuales serán sus datos en el sistema final sin tener este implementado. - Favorece una visión del sistema y de cuáles son las necesidades reales de información. - El modelo de datos facilita la migración de una base de datos a otra.

2. MODELO DE DATOS 2.1. Características Generales. • Las entidades de datos: Artículo

ARTICULO

(Silverrun) • Ocurrencia: • Atributos Reglas: - Un atributo debe pertenecer a una entidad y sólo a una. - Deben tener valores para las ocurrencias de las entidades - Cada atributo debe tener un significado único y consistente. - No es necesario especificar los atributos que se obtienen mediante cálculos en el modelo conceptual • Relación, asociaciones Clasificación de las relaciones por su cardinalidad (o conectividad) 2

Análisis y Diseño de Sistemas de Información II

a) Uno a muchos: Una ocurrencia de la primera entidad puede estar relacionada como mínimo con cero o una ocurrencia de la segunda y como máximo con muchas. Una ocurrencia de la segunda entidad puede estar relacionada como mínimo con cero o una ocurrencia de la primera y como máximo con una. Ejemplo: Un cliente realiza/tiene/ 0 (mínimo 0) ó n (máximo) pedidos Un pedido siempre pertenece a un cliente (obligación, mínimo uno) y sólo puede ser de un cliente (máximo uno). CLIENTE

PEDIDO

CLIENTE realiza

1,1

PEDIDO

0,N

Notación Silverrun

b) Uno a uno: Una ocurrencia de la primera entidad relacionada como mínimo con una o cero ocurrencias, y como máximo con una de la segunda. Una ocurrencia de la segunda entidad relacionada como mínimo con cero o una ocurrencias y como máximo con una de la primera. Ejemplo: Un grupo de (4º -A de Ing. Informática) puede tener como mínimo ningún delegado (antes de su elección) y como máximo uno. Un delegado es siempre delegado de un grupo como mínimo (obligación) y sólo puede ser delegado de un grupo como máximo. DELEGADO

GRUPO

Delegado

Grupo 0,1

tiene

1,1

Notación Silverrun

c) Muchos a muchos: Una ocurrencia de la primera entidad relacionada como mínimo con cero o una ocurrencias y como máximo con muchas de la segunda, 3

Análisis y Diseño de Sistemas de Información II

y una ocurrencia de la segunda entidad relacionada como mínimo con cero o una y como máximo con muchas de la primera. Ejemplo: Un artículo aparece/está es solicitado en cero pedidos como mínimo (no hay obligación) y como máximo puede ser solicitado en muchos. En un pedido debe ser solicitado como mínimo un artículo y como máximo muchos ARTICULO

PEDIDO

1,N

ARTÍCULO

PEDIDO

Es solicitado 0,N

• Identificador • El identificador debe tomar uno y sólo un valor para cada una de las ocurrencias de la entidad. • Para una misma entidad pueden haber diferentes opciones de definir identificadores (Nota: en el modelo E/R se elige una de estas opciones para definir la clave primaria). • Es aconsejable que sea de corta longitud, de uso común y fácilmente memorizable.

ARTÍCULO ARTÍCULO CÓDIGO PROVEEDOR CÓDIGO

Ejemplo: identificador compuesto por el identificador de otra entidad mas un atributo.

En la notación de la herramienta Silverrun los identificadores de una entidad no se escriben en otras entidades, para indicar la dependencia del identificador se subraya la cardinalidad del arco, que siempre ha de ser (1,1) (razonar por qué) Sumnistra ARTÍCULO ARTÍCULO CÓDIGO

1,1

0,N

PROVEEDOR PROVEEDOR CÓDIGO

4

Análisis y Diseño de Sistemas de Información II

2.2. Pasos para el desarrollo del Modelo de Datos 2.2.1. Identificar las principales entidades Comenzar identificando los objetos de interés (a partir de los requisitos) y analizar cada uno para ver si son de interés o no para el sistema. • Considerar algún ejemplo de ocurrencia para comprobar que tiene sentido • pensar en el concepto que representa, una misma representación puede significar diferentes conceptos para analistas diferentes • Nombrar, definir y documentar las entidades en el diccionario de datos o en el documento de diseño correspondiente. 2.2.2. Determinar las relaciones entre entidades Las relaciones son los hechos de interés para el sistema que proporcionan la conexión entre las ocurrencias de dos o más entidades. • Existentes o de Posesión (por ejemplo un empleado tiene hijos) • Funcionales (El profesor explica a los alumnos) • Sucesos (El cliente realiza pedidos) Reglas: • Identificar las relaciones y darles un nombre, documentarlas en el diccionario de datos • Asignar cardinalidad o conectividad 2.2.3. Definir identificadores - Elegir como mínimo un identificador para cada entidad. - Establecer estándares de nomenclatura, abreviaturas, etc. - Uso común entre los usuarios

2.3. Añadir Atributos al Modelo de Datos. Un atributo es un hecho o una unidad de información sobre una entidad que no se puede descomponer. Asociar cada siguientes:

atributo con la entidad que cumple las dos condiciones

5

Análisis y Diseño de Sistemas de Información II

a) dado identificador de la entidad el valor que toma para una ocurrencia define completamente el valor del atributo b) No puede ubicarse en otra entidad más general, cumpliendo la misma condición anterior

PROVEEDOR CODIGO

PEDIDO le realizamos

LINEA DE PEDIDO

NUMERO

PEDIDO NUMERO

esta formado

NUMLIN LINEA DE

DIRECCION

PEDIDO FECHA

NOMBRE

PRECIO-VENTA

ARTICULO CODIGO PRECIO-UNIDAD UNIDAD-MED

• Atributos con valores múltiples 1,1

Cliente

Facturado

Cliente

Cliente FActurado-mes-1 Cliente FActurado-mes-2 Cliente FActurado-mes-3 Cliente FActurado-....

R-1

Cliente NIF 0,n

FActurado Mes FActurado Importe

Crear una entidad para representar la información y comprender mejor el problema. Rehacer las relaciones convenientemente.

3. RELACIONES COMPLEJAS • Relaciones del tipo M:N (muchos a muchos)

ARTICULO

PEDIDO

6

Análisis y Diseño de Sistemas de Información II

Si existe un concepto que puede sustituir la relación, tiene sentido como entidad y aporta una mejor comprensión al modelo (para usuarios y analistas) es conveniente deshacerlas mediante esta entidad y las relaciones uno a muchos adecuadas. ARTICULO

PEDIDO

LINEA DE PEDIDO

• Relaciones entre tres o más entidades

COMPRADOR

VEHÍCULO

VENDEDOR

VEHÍCULO

VENDEDOR

COMPRADOR

VENTA

Las relaciones entre tres o más entidades se reclasificaran mediante una entidad relacionada con cada una de ellas, si existe un concepto que puede ser representado como una entidad, y aporta mayor comprensión al problema.

7

Análisis y Diseño de Sistemas de Información II

• Relaciones Potencialmente redundantes (pueden serlo o no, depende del significado de las relaciones y de las cardinalidades) Tiene ORGANIZACIÓN

Desarrolla EMPLEADO

TAREA

Puede realizar

Las relaciones redundantes deben eliminarse. Explica PROFESOR

ALUMNO

Es tutor

• Relaciones Recursivas o Autorrelaciones

EMPLEADO

EMPLEADO

Dirige

Dirige/es dirigido

4. REGLAS DE FUNCIONAMIENTO O DE NEGOCIO. Proporcionan: Integridad, Consistencia y corrección

8

Análisis y Diseño de Sistemas de Información II

• Reglas que afectan a las operaciones de borrar, insertar En algunos casos la definición de la cardinalidad ya implica una obligatoriedad en el comportamiento de la relación. En otros casos depende de los requerimientos funcionales del sistema. El objetivo es identificar cuando pueden haber problemas con ocurrencias de una entidad relacionadas con ocurrencias de otra entidad, si se borran o añaden nuevas ocurrencias

a) Reglas de Insertar, el problema se produce cuando se quiere añadir una ocurrencia y no existe, previamente en el sistema, la ocurrencia de la otra entidad de la que depende en cierra forma por la conexión de la relación EJEMPLO El usuario desea introducir un pedido de compras y o bien, no existe, o no se ha dado de alta, o se desconoce el proveedor al cual se le va a solicitar. (Introducir un nuevo proveedor en este caso no es problemático y no es necesario considerarlo) Genera PROVEEDOR

PEDIDO

NOTA: El usuario y el analista deben decidir una solución para cada relación teniendo en cuenta la integridad del modelo, los requisitos funcionales y de datos. En este caso la respuesta afectará al proceso introducir pedido a proveedor del DFD. Ejercicio: pensar como afecta cada respuesta al modelo, a la cardinalidad y al proceso del DFD. Las soluciones pueden ser: - El usuario sólo puede realizar pedidos a proveedores existentes. - Si el proveedor es nuevo y no existe el usuario lo da de alta al mismo tiempo que hace el pedido. - El usuario puede realizar pedidos sin especificar el proveedor o indicando un proveedor existente. - El usuario puede realizar el pedido refiriéndose a un proveedor determinado o asignarlo directamente a uno por defecto. - El usuario puede realizar pedidos a proveedores que no tengan más de cuatro pedidos pendientes.

9

Análisis y Diseño de Sistemas de Información II

- Los usuarios pueden realizar pedidos son tener en cuenta el usuario, después alguien indicará quien es el proveedor.

b) Reglas de Borrar Condiciones para eliminar una ocurrencia de una entidad con respecto a las ocurrencias de otra entidad conectadas con la que se desea eliminar. En el mismo ejemplo anterior el problema se produce cuando se desea borrar un proveedor, ¿qué ocurre con los pedidos que se ha realizado a ese proveedor? El analista y el usuario deben decidir una respuesta teniendo en cuenta, al igual que en el caso anterior, la integridad del sistema y los requisitos, además deberán ser coherentes con la respuesta seleccionada para insertar en la misma relación. Genera PROVEEDOR

PEDIDO

Las repuestas pueden ser: - Un proveedor no se puede dar de baja si tiene pedidos pendientes. - Cuando se da de baja un proveedor se anulan y eliminan todos los pedidos que se tenían pendientes con él. - Los pedidos pendientes se mantienen aunque se de de baja el proveedor. - Cuando un proveedor se borra, si tiene pedidos pendiente se asignan a un proveedor por defecto, real o no. - Los proveedores con pedidos pendientes no se borran pero se marcan para una posterior revisión.

Cada relación del tipo uno a muchos o uno a uno debe estudiarse para definir una regla de insertar y una de borrar.

10

Análisis y Diseño de Sistemas de Información II

5. DOCUMENTACIÓN DEL MODELO Las herramientas CASE proporcionan utilidades para documentar y obtener informes de los modelos. Como mínimo la documentación del modelo debería contener: • Documentación de Entidades:
Nombre
Identificador/es
Alias
Descripción
Arcos
Atributos (Nombre, Descripción, Tipo de Dato, Longitud) • Documentación de Relaciones
Nombre
Descripción
Entidades que conecta

11

Análisis y Diseño de Sistemas de Información II

ANEXO: CONSISTENCIA ENTRE MODELOS Bohem: "Los errores del análisis aumenta exponencialmente en fases posteriores. Es diez veces más económico corregir un error de análisis en la misma fase que posteriormente." Inconsistencias: – Por falta de definición – Conceptos que representan la misma realidad y están definidos de diferentes formas en cada uno de los modelos. •

ENTRE EL DFD Y EL DD – Cada flujo de Datos y cada almacén deben estar definidos en el diccionario

de datos. – Cada dato y cada almacén que se define en el diccionario de datos debe aparecer en alguno de los DFD. •

EL DFD Y LAS ESPECIFICACIONES DE LOS PROCESOS – Cada proceso debe estar asociado a un DFD de un nivel inferior o a una

especificación del proceso. – Cada especificación de procesos debe tener una burbuja de un nivel más bajo asociada. – Las entradas y salidas de las especificaciones de los procesos deben coincidir con las entradas y salidas reflejadas en los diagramas. •

LAS ESPECIFICACIONES DE PROCESOS Y EL DD – Cada referencia a datos que aparezca en las especificaciones de procesos

debe coincidir o bien con un flujo de datos o con un almacén conectado a la burbuja que se está describiendo, o un componente o bien ser un término local definido en la misma especificación del proceso.

•

EL MCD, EL DFD Y LAS ESPECIFICACIONES DE LOS PROCESOS. – Cada almacén de los DFD debe corresponder con una entidad, o una relación

o una combinación de ambos. – Los nombres de los almacenes de datos y los de las entidades deben coincidir. – En el caso de utilizar un único diccionario de datos las entradas deberán coincidir. – Deben existir procesos en el DFD para crear y eliminar ocurrencias de cada una de las entidades del modelo de datos.

12

Análisis y Diseño de Sistemas de Información II

– Debe existir al menos una burbuja o procesos para asignar valores a cada uno

de los atributos de cada una de las entidades del modelo entidad relación, y debe existir algún proceso que los lea o utilice.

13