Anlisis y Diseo de Sistemas de Informacin II

TEMA 5: MODELIZACIN CONCEPTUAL DE DATOS 1. INTRODUCCIN A LA MODELIZACIN CONCEPTUAL DE DATOS 2. MODELO CONCEPTUAL DE DATOS 2.1. Caractersticas Generales. 2.2. Pasos para su Desarrollo. 2.3. Aadir Detalles al Modelo 3. RELACIONES COMPLEJAS 4. REGLAS DE FUNCIONAMIENTO 5. DOCUMENTACIN DEL MODELO ANEXO: Consistencia entre Modelos

1. INTRODUCCIN A LA MODELIZACIN CONCEPTUAL DE DATOS

Representa Informacin lgica de un sistema Estructura Reglas EL DISEO CONCEPTUAL es un esquema o descripcin de alto nivel de la estructura de los datos de un sistema independientemente de la implementacin posterior de la base de datos. CARACTERSTICAS - Es un proceso dirigido completamente a los datos. - Enfatiza la comprensin de los requerimientos de informacin del sistema. - Permite una mejor comunicacin entre usuarios, analistas y programadores durante toda las fases del diseo. - Proporcionar las bases para disear una base de datos del sistema correcta, consistente, compartible y flexible. CUESTIONES (qu debe plantearse el analista para su desarrollo?) Principal informacin Objetos de inters Detalles que los caracterizan Cmo estn relacionados
1

Anlisis y Diseo de Sistemas de Informacin II

FACTORES CRTICOS: - Trabajar interactivamente con los usuarios - Seguir una metodologa (pasos para su desarrollo) - Considerar tanto la estructura de la informacin como la integridad de la misma. (parte del principio del dominio de la informacin) - Utilizar diagramas para representar el modelo de datos lgico (principio de modelado) - Construir un diccionario de datos BENEFICIOS - Un correcto diseo de la base de datos. - Ayuda a valorar cul es la tecnologa 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 sern sus datos en el sistema final sin tener este implementado. - Favorece una visin del sistema y de cules son las necesidades reales de informacin. - El modelo de datos facilita la migracin de una base de datos a otra.

2. MODELO DE DATOS 2.1. Caractersticas Generales.

Las entidades de datos:
Artculo

ARTICULO

(Silverrun) Ocurrencia: Atributos Reglas: - Un atributo debe pertenecer a una entidad y slo 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 clculos en el modelo conceptual Relacin, asociaciones Clasificacin de las relaciones por su cardinalidad (o conectividad)
2

Anlisis y Diseo de Sistemas de Informacin II

a) Uno a muchos: Una ocurrencia de la primera entidad puede estar relacionada como mnimo con cero o una ocurrencia de la segunda y como mximo con muchas. Una ocurrencia de la segunda entidad puede estar relacionada como mnimo con cero o una ocurrencia de la primera y como mximo con una. Ejemplo: Un cliente realiza/tiene/ 0 (mnimo 0) n (mximo) pedidos Un pedido siempre pertenece a un cliente (obligacin, mnimo uno) y slo puede ser de un cliente (mximo uno).
CLIENTE PEDIDO

CLIENTE realiza 0,N

1,1

PEDIDO

Notacin Silverrun

b) Uno a uno: Una ocurrencia de la primera entidad relacionada como mnimo con una o cero ocurrencias, y como mximo con una de la segunda. Una ocurrencia de la segunda entidad relacionada como mnimo con cero o una ocurrencias y como mximo con una de la primera. Ejemplo: Un grupo de (4 -A de Ing. Informtica) puede tener como mnimo ningn delegado (antes de su eleccin) y como mximo uno. Un delegado es siempre delegado de un grupo como mnimo (obligacin) y slo puede ser delegado de un grupo como mximo.
GRUPO
DELEGADO

Grupo 0,1

Delegado tiene 1,1

Notacin Silverrun

c) Muchos a muchos: Una ocurrencia de la primera entidad relacionada como mnimo con cero o una ocurrencias y como mximo con muchas de la segunda,
3

Anlisis y Diseo de Sistemas de Informacin II

y una ocurrencia de la segunda entidad relacionada como mnimo con cero o una y como mximo con muchas de la primera. Ejemplo: Un artculo aparece/est es solicitado en cero pedidos como mnimo (no hay obligacin) y como mximo puede ser solicitado en muchos. En un pedido debe ser solicitado como mnimo un artculo y como mximo muchos
ARTICULO PEDIDO

ARTCULO 0,N

1,N Es solicitado

PEDIDO

Identificador El identificador debe tomar uno y slo 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 comn y fcilmente memorizable.

ARTCULO ARTCULO CDIGO PROVEEDOR CDIGO

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

En la notacin 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 ARTCULO ARTCULO CDIGO 1,1 0,N PROVEEDOR PROVEEDOR CDIGO

Anlisis y Diseo de Sistemas de Informacin II

2.2. Pasos para el desarrollo del Modelo de Datos

2.2.1. Identificar las principales entidades Comenzar identificando los objetos de inters (a partir de los requisitos) y analizar cada uno para ver si son de inters o no para el sistema. Considerar algn ejemplo de ocurrencia para comprobar que tiene sentido pensar en el concepto que representa, una misma representacin puede significar diferentes conceptos para analistas diferentes Nombrar, definir y documentar las entidades en el diccionario de datos o en el documento de diseo correspondiente. 2.2.2. Determinar las relaciones entre entidades Las relaciones son los hechos de inters para el sistema que proporcionan la conexin entre las ocurrencias de dos o ms entidades. Existentes o de Posesin (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 mnimo un identificador para cada entidad. - Establecer estndares de nomenclatura, abreviaturas, etc. - Uso comn entre los usuarios

2.3. Aadir Atributos al Modelo de Datos.

Un atributo es un hecho o una unidad de informacin sobre una entidad que no se puede descomponer. Asociar cada siguientes: atributo con la entidad que cumple las dos condiciones

Anlisis y Diseo de Sistemas de Informacin 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 ms general, cumpliendo la misma condicin anterior

PROVEEDOR CODIGO DIRECCION NOMBRE le realizamos

PEDIDO NUMERO esta formado

LINEA DE PEDIDO PEDIDO NUMERO NUMLIN DE LINEA PEDIDO FECHA

PRECIO-VENTA

ARTICULO CODIGO PRECIO-UNIDAD UNIDAD-MED

Atributos con valores mltiples

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

1,1 Cliente Cliente NIF 0,n R-1

Facturado FActurado Mes FActurado Importe

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

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

ARTICULO

PEDIDO

Anlisis y Diseo de Sistemas de Informacin II

Si existe un concepto que puede sustituir la relacin, tiene sentido como entidad y aporta una mejor comprensin 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 ms entidades

VEHCULO

COMPRADOR

VENDEDOR

VEHCULO

VENDEDOR

COMPRADOR

VENTA

Las relaciones entre tres o ms 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 comprensin al problema.

Anlisis y Diseo de Sistemas de Informacin II

Relaciones Potencialmente redundantes (pueden serlo o no, depende del significado de las relaciones y de las cardinalidades)
Tiene
ORGANIZACIN EMPLEADO

Desarrolla
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 correccin

Anlisis y Diseo de Sistemas de Informacin II

Reglas que afectan a las operaciones de borrar, insertar En algunos casos la definicin de la cardinalidad ya implica una obligatoriedad en el comportamiento de la relacin. 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 aaden nuevas ocurrencias

a) Reglas de Insertar, el problema se produce cuando se quiere aadir una ocurrencia y no existe, previamente en el sistema, la ocurrencia de la otra entidad de la que depende en cierra forma por la conexin de la relacin 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 problemtico y no es necesario considerarlo)
Genera
PROVEEDOR PEDIDO

NOTA: El usuario y el analista deben decidir una solucin para cada relacin 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 slo 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 refirindose a un proveedor determinado o asignarlo directamente a uno por defecto. - El usuario puede realizar pedidos a proveedores que no tengan ms de cuatro pedidos pendientes.

Anlisis y Diseo de Sistemas de Informacin II

- Los usuarios pueden realizar pedidos son tener en cuenta el usuario, despus 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, adems debern ser coherentes con la respuesta seleccionada para insertar en la misma relacin.
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 tenan 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 revisin.

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

10

Anlisis y Diseo de Sistemas de Informacin II

5. DOCUMENTACIN DEL MODELO

Las herramientas CASE proporcionan utilidades para documentar y obtener informes de los modelos. Como mnimo la documentacin del modelo debera contener: Documentacin de Entidades: Nombre Identificador/es Alias Descripcin Arcos Atributos (Nombre, Descripcin, Tipo de Dato, Longitud) Documentacin de Relaciones Nombre Descripcin Entidades que conecta

11

Anlisis y Diseo de Sistemas de Informacin II

ANEXO: CONSISTENCIA ENTRE MODELOS Bohem: "Los errores del anlisis aumenta exponencialmente en fases posteriores. Es diez veces ms econmico corregir un error de anlisis en la misma fase que posteriormente." Inconsistencias: Por falta de definicin Conceptos que representan la misma realidad y estn definidos de diferentes formas en cada uno de los modelos. ENTRE EL DFD Y EL DD
Cada flujo de Datos y cada almacn deben estar definidos en el diccionario

de datos. Cada dato y cada almacn 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

especificacin del proceso. Cada especificacin de procesos debe tener una burbuja de un nivel ms 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 almacn conectado a la burbuja que se est describiendo, o un componente o bien ser un trmino local definido en la misma especificacin del proceso.

EL MCD, EL DFD Y LAS ESPECIFICACIONES DE LOS PROCESOS.

Cada almacn de los DFD debe corresponder con una entidad, o una relacin

o una combinacin 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 debern coincidir. Deben existir procesos en el DFD para crear y eliminar ocurrencias de cada una de las entidades del modelo de datos.

12

Anlisis y Diseo de Sistemas de Informacin 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 relacin, y debe existir algn proceso que los lea o utilice.

13