Diagrama Entidad Relación - V 1.

Notación del diagrama entidad relación

Es el modelo conceptual más utilizado para el diseño conceptual de

bases de datos. Fue introducido por Peter Chen en 1976.

Por lo tanto tenemos:

Empleado Entidad Hijo Entidad Débil

Relación Relación Débil

Atributo
Nombr Identificador
e Document
o
Derivable Multivaluado
Edad Hijo

Página 1 de 10
 Diagrama Entidad Relación - V 1.0

Ejemplo:

Relación Unaria
tiene
por
Subtipo jefe
Relación
Fuera de Cardinalidad Binaria
convenio
Empleado 11 tien N1
Hijo
e
Supertipo por Cardinalidad
Fuera de
Convenio
Subtipo
Relación Ternaria
tien
e
Proyecto
por

Cargo

Página 2 de 10
 Diagrama Entidad Relación - V 1.0

Aproximación al proceso de diseño de entidad relación.

Una metodología es un conjunto de técnicas, procedimientos y
ayudas para el desarrollo de un producto de software. Dicho de otra
manera podemos decir que una metodología es un conjunto de
modelos y herramientas que nos permiten pasar de una etapa a la
siguiente en el proceso de diseño de la base de datos. Rolland y Benci
(1988).
La concepción de una Base de Datos Relacional es una tarea larga y
costosa. Existe la necesidad de contar con procedimientos ordenados
para facilitar el desarrollo de un producto software (en este caso una
base de datos), ya que esto tiene una incidencia en cuanto a costos
y plazos de entrega, además de la calidad y mantenimiento del
producto.
Según Lan Sommerville (1988) un buen diseño es la clave de una
eficiente ingeniería del software. Un software bien diseñado es fácil de
aplicar y mantener, además de ser comprensible y fiable. Los
sistemas mal diseñados o con problemas en su diseño, aunque
puedan funcionar, serán costosos o difíciles de mantener, difíciles de
probar (o entender) y poco fiables (y algunas veces imprevisibles).
Muchas veces, se cree o supone que el diseño de una base de datos
se limita aplicar la teoría de normalización, cuando en realidad es una
actividad mucho más compleja, donde la normalización es apenas una
de sus etapas.
Por lo tanto, el diseño de un sistema de información es una
actividad complicada que incluye la planificación, especificación y
desarrollo de cada componente del dominio de la aplicación.
No existe una metodología consagrada, sin embargo, se pueden
distinguir ciertas etapas bien claras:

 Diseño Conceptual
Su objetivo es obtener una buena representación de los
recursos de información de la empresa (claro entendimiento
del negocio), independientemente de la tecnología y fuera
de consideraciones de eficiencia del computador.
Entregable de esta etapa: Esquema conceptual (DER).

 Diseño Lógico
Su objetivo es transformar el esquema conceptual
obtenido en la etapa anterior, adaptándolo al modelo de
datos en el que se apoya el SGBD que se va a utilizar
(modelo relacional).

Página 3 de 10
Diagrama Entidad Relación - V 1.0

Entregable de esta etapa: Esquema lógico (DER

normalizado y script)

Página 4 de 10
 Diagrama Entidad Relación - V 1.0

 Diseño Físico
Su objetivo es conseguir una instrumentación lo más
eficiente posible del esquema lógico.
Entregable de esta etapa: Esquema lógico (DER
normalizado y script)

Causas de malos diseños

 Falta de conocimiento del dominio de la aplicación (del negocio

que se está modelando).
 Falta de experiencia en el modelado.
 Poca confianza en las metodologías de diseño de base de datos.

Página 5 de 10
 Diagrama Entidad Relación - V 1.0

Metodología de diseño de una base de datos.

El ciclo de vida para el diseño de un esquema de base de datos es el

siguiente:

Estudio de Factibilidad

Análisis de Requerimientos Diseño Conceptual

Esquema Conceptual: DER

Diseño Diseño Lógico

Esquema Lógico: DER
normalizado e implementado
en SQL

Diseño Físico
Indicices, tablespaces,
backups

Creación de prototipo Implementación

Validación & Pruebas

Operación

Página 6 de 10
 Diagrama Entidad Relación - V 1.0

Etapas de Diseño (tomada de Fundamentals of database Systems,

Elmasri/Navathe)

Página 7 de 10
 Diagrama Entidad Relación - V 1.0

Estudio de Factibilidad
Realiza el estudio de la rentabilidad de las distintas alternativas del
diseño del sistema de información. Determina si es viable o no
continuar.

Análisis de Requerimientos
Capturar los requisitos funcionales de los diferentes grupos de
usuarios determinando cuales serán los usos que se le piensan aplicar
a la BD.
También capturar los requisitos no funcionales como ser: las
transacciones críticas a resolver y expectativa de tiempos de
respuesta. Esto puede ser clave en el negocio que se está
modelando (ejemplo: puestos de peajes de autopistas donde es crítico
que el sistema responda instantáneamente, por eso la base de datos,
reside en un datacenter al lado de los puestos de peajes y a la noche
se realiza una replicación a una base de datos maestra).

Diseño
Permite obtener una buena estructura de los datos perteneciente a
los conceptos del entorno del negocio.
Se pueden observar tres sub-etapas:
 Fase del diseño conceptual la cual obtiene una
representación de los recursos de la empresa sin considerar
ningún soporte informático.

Página 8 de 10
 Diagrama Entidad Relación - V 1.0

 Fase del diseño lógico transforma el modelo conceptual

adaptándolo a un modelo de datos para ser soportado por
algún SGBD (Sistema de Gestión de Base de datos).
 Fase del diseño físico obtiene una instrumentación más
eficientemente del modelo lógico teniendo en cuenta el
espacio de almacenamiento, accesos, índices, etc.
Corresponde a la descripción de la implantación de una BD
(Scripts). El diseño físico se adapta al SGBD específico que
se va a utilizar.
Se expresa haciendo uso del lenguaje de definición de
datos del SGBD (DML). Por ejemplo, en SQL las sentencias
que se utilizan son las siguientes:
CREATE DATABASE
CREATE SCHEMA
CREATE TABLE
CREATE VIEW
CREATE INDEX

Dependencia de cada una de las etapas del diseño, en el tipo de

SGBD y en el SGBD específico:

Tipo de SGDB SGDB Específico

(relacional, objetos, (MySQL, Oracle,
etc.) DB4O, etc).
Diseño
No No
conceptual
Diseño Lógico Si No
Diseño Físico Si Si

Creación de Prototipos:
Actualmente existen varios productos para desarrollar el diseño de
una base de datos y por lo general cada uno de ello cuenta con
buenas herramientas para obtener prototipos. Un prototipo es una
versión simplificada para ser ejecutado por el usuario y comprobar si
se han interpretado correctamente las especificaciones. ¿Qué es un
UAT? ¿Para que los usuarios lo validen?

Página 9 de 10
 Diagrama Entidad Relación - V 1.0

Implementación o despliegue
Se refiere a la programación de una versión final y operativa del
sistema de información.

Evaluación y Pruebas
Garantiza que cada fase se haya realizado con una calidad
aceptable verificando si se cumplen con las especificaciones definidas.

Operación
En esta etapa se comienza con la carga inicial de datos y finaliza
cuando el proyecto se haya vuelto obsoleto y deba ser reemplazado.
El ciclo de vida de un sistema de información es utilizado como guía
para el desarrollo de la estructura de datos deseada para ser
consultada y mantenida sin demasiados inconvenientes. En la práctica
algunas de las fases no se construyen porque sus divisiones no son
muy claras esto proporciona mayor agilidad en los tiempos de
desarrollo, pero se deberá balancear estos desvíos porque a mayor
tiempo de análisis y diseño mayor seguridad se obtendrá para
alcanzar la meta propuesta en tiempo y forma.

Derivación del esquema de datos a partir de la lista de eventos

Si poseemos una lista de eventos especificada en el análisis

funcional, etapa modelo del ambiente, esta nos serviría de guía para
encontrar los conceptos participantes en el dominio de la aplicación.
Cada evento se conecta con el sistema a través de una entidad
externa porque realiza o brinda un determinado servicio, es por ello
que se construye una lista de eventos para conocer cuales son todas
las respuestas que ofrece el sistema.
Para concretar el funcionamiento de una respuesta siempre debe
existir un agente de petición y otro agente de respuesta, estos
agentes son conceptos candidatos de nuestro esquema de base de
datos relacional. Además también se tendrá en cuenta la estructura
de los flujos de datos que circulan entre estos agentes obteniendo así
más conceptos participantes de nuestro modelo de datos.
La lista de eventos nos permite describir los eventos del ambiente y
a través de ellos el sistema conoce como dar una respuesta.
Un evento es un suceso en un entorno determinado y el sistema
debe responderle de alguna manera. El evento tiene las siguientes
características: ocurre en el medio ambiente del sistema y genera una
respuesta planeada del sistema de acuerdo como se detecte.

Página 10 de 10