UNIVERSIDAD DE GUAYAQUILEXTENCION LA CONCORDIAINFORMATICA EDUCATIVA 4TO AÑO UNICO

MATERIA: SISTEMAS DE DISEÑO

PROFESOR:Lic. LUIS NUÑEZ Msc.

NOMBREDIANA ESTEFANIA VALDEZ

HURTADO

QUÉ ES EL MODELO ENTIDAD-RELACIÓN

Como ya he comentado este modelo es solo y exclusivamente un método del que disponemos

para diseñar estos esquemas que posteriormente debemos de implementar en un gestor de BBDD

(bases de datos). Este modelo se representa a través de diagramas y está formado por varios ele-

mentos.

Entidad: Objeto del mundo real distinguible de otros objetos. Una entidad se describe usando un

conjunto de atributo.

Conjunto de entidades (tipo de entidad): Una colección de entidades similares (ej. todos

los empleados).

Todas las entidades de un conjunto tiene los mismos atributos (a excepción de una jerar-

quía)

Cada conjunto de entidades tiene una llave

Cada atributo tiene un dominio

Correspondencia de cardinalidades

Dado un conjunto de relaciones en el que participan dos o más conjuntos de entidades, la corres-

pondencia de cardinalidad indica el número de entidades con las que puede estar relacionada una

entidad dada.

Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia

de cardinalidades puede ser:

Uno a Uno: (1:1) Un registro de una entidad A se relaciona con solo un registro en una

entidad B. (ejemplo dos entidades, profesor y departamento, con llaves primarias, codi-

go_profesor y jefe_depto respectivamente, un profesor solo puede ser jefe de un departa-

mento y un departamento solo puede tener un jefe).

Uno a varios: (1:N) Un registro en una entidad en A se relaciona con cero o muchos re-

gistros en una entidad B. Pero los registros de B solamente se relacionan con un registro

en A. (ejemplo: dos entidades, vendedor y ventas, con llaves primarias, codigo_vendedor

y venta, respectivamente, un vendedor puede tener muchas ventas pero una venta solo

puede tener un vendedor).

Varios a Uno: (N:1) Una entidad en A se relaciona exclusivamente con una entidad en

B. Pero una entidad en B se puede relacionar con 0 o muchas entidades en A (ejemplo

empleado-centro de trabajo).

Varios a Varios: (N:M) Una entidad en A se puede relacionar con 0 o con muchas enti-

dades en B y viceversa (ejemplo asociaciones-ciudadanos, donde muchos ciudadanos

pueden pertenecer a una misma asociación, y cada ciudadano puede pertenecer a muchas

asociaciones distintas).

Restricciones de participación.

Dado un conjunto de relaciones R en el cual participa un conjunto de entidades A, dicha partici-

pación puede ser de dos tipos:

Total: Cuando cada entidad en A participa en al menos una relación de R.

Parcial: Cuando al menos una entidad en A NO participa en alguna relación de R.

Por definición el Diseño Conceptual debe identificar los objetivos y requerimientos del Sistema.

Es una fase delicada porque precede inmediatamente aquella muy importante del análisis del sis-

tema, para la cual los objetivos y justificaciones deben haber sido ya definidos. La fase de análi-

sis del sistema será, en práctica, definir la factibilidad y el costo (en términos de recursos, ries-

gos, etc…) para la implementación del proyecto.

Una vez que los objetivos y metas hayan sido definidos, será formado por los siguientes compo-

nentes:

1. una arquitectura predefinida,

2. una serie (conjunto) de recursos humanos,

3. una serie de instrumentos automáticos y manuales para la obtención, agregación,

recuperación y procesamiento de datos,

4. una serie de procedimientos y técnicas para lograr el objetivo,

5. un modelo predefinido de datos/información.

Transcripción de Diseño Conceptual Sistemas de Información.

0 + - = 9 8 7 1 2 3 4 5 6 c Diseño de hardware: debe especificarse todo el equipo de cómputo, lo

que incluye todo dispositivo de entrada, procedimientos y salidas con sus características de

rendimiento; por ejemplo, en el diseño lógico se especifica que la base de datos debe contener

grandes volúmenes de datos históricos, por lo que se requerirá de los dispositivos de

almacenamiento del sistema que sean de gran capacidad

DISEÑO CONCEPTUAL

El diseño conceptual es la base de la creación de cualquier elemento.  Nos permite encausar la forma y sus atributos en pos de una meta definida.  En este sentido, el diseño nunca es fruto del azar, pese a las múltiples soluciones que se puedan obtenerCuando se trabaja bajo el análisis conceptual de una situación, nos referimos a la abstracción de hechos reales de los cuales se emite un concepto o es posible hacer una idea de ello.   Para poder realizar la abstracción de un tema en un área específica, a nivel informático,  es necesario tener los requerimientos formulados por los usuarios con respecto a este.  Estos requerimientos contienen el conjunto de hechos y reglas que dan pauta a la creación del esquema conceptua l donde por medio de este se podrá realizar una descripción de alto nivel de la futura base de datos.  Para manipular este esquema se utiliza un modelo conceptual que proporciona un lenguaje que permite utilizar un conjunto de símbolos (estándares) para la creación de este. El diseño conceptual se hace independiente al sistema gestor de base de datos que utilice el usuario para la implementación de esta.El diseño conceptual proviene del Arte conceptual, principalmente postulado por Duchamp el cual materializaba sus obras de arte según una idea. Aveces la idea era tal que en muchas ocasiones la obra solo terminaba siendo un mero soporte de la idea que se queria expresar. Esto quiere decir que el arte conceptual concentraba el arte de la obra en la idea.Por lo tanto podemos definir que el Diseño Conceptual trata de: Capitalizar recursos para conformar una idea, la cual nos sirve para a llevar a cabo un prototipo el cual sirve para; (una vez llevado a cabo) satisfacer una necesidad.

DISEÑO LÓGICO

Una vez establecido el modelo conceptual del problema o situación, el diseño lógico de los datos

permite que estos se puedan representar usando de manera eficiente posibles recursos para

estructurar datos y modelar restricciones disponibles en el modelo lógico.   El objetivo es

convertir el esquema conceptual de datos en un esquema lógico que se ajuste al gestor de la base

de datos que va a ser utilizado. Para escenificar esta situación se tomará el Modelo Relacional

cuyo esquema relacional es trabajado por muchos DBMS comerciales.  Algunos de ellos son:

ORACLE (Oracle Inc.), INFORMIX (Informix Inc.), SQL/DS, DB2 (IBM), INGRES

(ASK/Computer Systems Inc.), UNIFY(Unify Inc.).

El diseño lógico es el proceso de construir un esquema de la información que utiliza la empresa,

basándose en un modelo de base de datos específico, independiente del SGBD concreto que se

vaya a utilizar y de cualquier otra consideración física.

En esta etapa, se transforma el esquema conceptual en un esquema lógico que utilizará las

estructuras de datos del modelo de base de datos en el que se basa el SGBD que se vaya a

utilizar, como puede ser el modelo relacional, el modelo de red, el modelo jerárquico o el modelo

orientado a objetos. Conforme se va desarrollando el esquema lógico, éste se va probando y

validando con los requisitos de usuario.

La normalización es una técnica que se utiliza para comprobar la validez de los esquemas

lógicos basados en el modelo relacional, ya que asegura que las relaciones (tablas) obtenidas no

tienen datos redundantes. Esta técnica se presenta en el capítulo dedicado al diseño lógico de

bases de datos.

El esquema lógico es una fuente de información para el diseño físico. Además, juega un papel

importante durante la etapa de mantenimiento del sistema, ya que permite que los futuros

cambios que se realicen sobre los programas de aplicación o sobre los datos, se representen

correctamente en la base de datos.

Tanto el diseño conceptual, como el diseño lógico, son procesos iterativos, tienen un punto de

inicio y se van refinando continuamente. Ambos se deben ver como un proceso de aprendizaje

en el que el diseñador va comprendiendo el funcionamiento de la empresa y el significado de los

datos que maneja. El diseño conceptual y el diseño lógico son etapas clave para conseguir un

sistema que funcione correctamente. Si el esquema no es una representación fiel de la empresa,

será difícil, sino imposible, definir todas las vistas de usuario (esquemas externos), o mantener la

integridad de la base de datos. También puede ser difícil definir la implementación física o el

mantener unas prestaciones aceptables del sistema. Además, hay que tener en cuenta que la

capacidad de ajustarse a futuros cambios es un sello que identifica a los buenos diseños de bases

de datos. Por todo esto, es fundamental dedicar el tiempo y las energías necesarias para producir

el mejor esquema que sea posible.

EL DISEÑO FISICO

El diseño físico es el proceso de producir la descripción de la implementación de la base de datos

en memoria secundaria: estructuras de almacenamiento y métodos de acceso que garanticen un

acceso eficiente a los datos.

Para llevar a cabo esta etapa, se debe haber decidido cuál es el SGBD que se va a utilizar, ya que

el esquema físico se adapta a él. Entre el diseño físico y el diseño lógico hay una realimentación,

ya que algunas de las decisiones que se tomen durante el diseño físico para mejorar las

prestaciones, pueden afectar a la estructura del esquema lógico.

El diseño físico traduce el diseño lógico en una solución implementable y costo-efectiva o

económica.

El componente es la unidad de construcción elemental del diseño físico. Las características de

un componente son:

Se define según cómo interactúa con otros

Encapsula sus funciones y sus datos

Es reusable a través de las aplicaciones

Puede verse como una caja negra

Puede contener otros componentes

En el diseño físico se debe cuidar el nivel de granularidad (un componente puede ser tan grande

o tan pequeño según su funcionalidad, es decir, del tamaño tal que pueda proveer de una

funcionalidad compleja pero de control genérico) y la agregación y contención (un componente

puede reusar utilizando técnicas de agregación y contención, sin duplicar código).

El diseño físico debe involucrar:

El diseño para distribución – debe minimizarse la cantidad de datos que pasan como pa-

rámetros entre los componentes y éstos deben enviarse de manera segura por la red.

El diseño para multitarea – debe diseñarse en términos de la administración concurrente

de dos o más tareas distintas por una computadora y el multithreading o múltiples hilos

de un mismo proceso)

El diseño para uso concurrente – el desempeño de un componente remoto depende de si

está corriendo mientras recibe una solicitud.

El diseño con el manejo de errores y prueba de eventos:

o Validando los parámetros- a la entrada antes de continuar con cualquier proceso.

o Protegiendo recursos críticos –manejar excepciones para evitar la falla o termina-

ción sin cerrar archivos, liberar objetos sincronizados o memoria.

o Protegiendo datos importantes – contar con una excepción a la mitad de la actua-

ción en las bases de datos.

o Debugging – crear una versión para limpiar errores.

o Protección integral de transacciones de negocios – los errores deben regresarse al

componente que llama.