Diseño Conceptual 

Diseño 2 
Objetivo 2 
Importancia 2 
Cualidades 3 
Compleción (cualidad de completo) 3 
Corrección 3 
Minimalidad 4 
Expresividad 4 
Legibilidad 4 
Auto-explicación 4 
Normalidad 5 
Esquema Conceptual 5 
Identificar las entidades 5 
Identificar las relaciones 6 
Identificar los atributos y asociarlos a entidades y relaciones 8 
Determinar los dominios de los atributos 10 
Determinar los identificadores 10 
Determinar las jerarquías de generalización (si las hay) 11 
Dibujar el diagrama entidad-relación 12 
Instanciar el modelo 12 
Implementar el DER 12 
Revisar el esquema conceptual local con el usuario 12 
 
 

 
 
   

Página 1 de 13
 Diseño Conceptual 

Diseño 
Es  la  estrategia  de  alto  nivel  para  resolver  problemas  y  construir  una  solución. 
Desde  la  perspectiva  de  datos  abarca  un  esquema  conceptual  de  toda  la 
información  relevante  utilizada  por  un  ente  o  empresa  para  poder  gestionar  sus 
actividades. 
En  informática,  ​la  abstracción  es  importante  porque  facilita  ​el  análisis  y  ​el 
diseño​.  Permitiendo determinar la estructura de los datos a representar y tener una 
mejor visión de sus interrelaciones. 

Objetivo 

Analizar  y estudiar los requisitos funcionales para obtener un esquema de datos 
de manera abstracta, sin importar cual será la tecnología de implementación.  
Para  lograr  este  objetivo  se  especifica  todos  los  conjuntos  de  entidades,  las 
relaciones,  los  atributos  y  las  restricciones  de  correspondencia.  Lo  importante  en 
esta  etapa  es  describir  los  datos  y  sus  relaciones  más  que  especificar  el 
almacenamiento físico. 

Importancia 

Estos  modelos  permiten  tener  una  visión  abstracta  de  los  componentes 
participantes  en  el  negocio  y  sus  interacciones,  las  cuales  enfatizan  las  reglas 
propias del mismo. 
A  través  de  estos  modelos  ​se  estudia  los  elementos  participantes  del  sistema a 
desarrollar  y  la  información  relevante  del  mismo​,  sin  considerar  ningún  detalle  de 
almacenamiento,  permitiendo  reflejar  cómo  estos  componentes  participan  entre 
sí.   
Esta  visualización  debe  ser  revisada  y  validada  conjuntamente con los usuarios 
para  que  ellos  puedan  corroborar  si  está  comprendiendo  correctamente  la 
funcionalidad del negocio. 

Página 2 de 13
 Diseño Conceptual 

Cualidades 

Antes  de  finalizar  con  el  diseño  de  un  esquema  de  base  de  datos  es  necesario 
validarlo  basándose  en  sus  cualidades:  compleción,  corrección,  expresividad, 
minimalidad, auto-aplicación, extensibilidad y normalidad. 
Estas  cualidades  permiten  guiar  al  proceso  de  diseño  de  una  base  de  datos 
teniendo  en  cuenta  su  revisión  continua  cuando  se  está  desarrollando  el  diseño 
(mejora continua). 

1. Compleción (cualidad de completo) 

Un  esquema  de  bases  de  datos  está  completo  cuando  ​todos  los 
elementos  del  negocio  están  presentes  en  él​.  Como  primera  opción  se 
revisa  las  especificaciones  y  se  verifica  si  se  mencionan  estos  elementos 
en los documentos, gráficos, etc. La segunda opción es revisar el esquema 
y cotejar si cada elemento se localiza en los requerimientos. 

2. Corrección 

Un  esquema  de  base  de  datos  es  correcto  cuando  se  utiliza  con 
propiedad  los  conceptos  del  modelo,  generalmente  se  analiza  el  modelo 
sintácticamente  y  semánticamente.  Está  correctamente  especificado 
sintácticamente  cuando  sus  conceptos  se  han  aplicado  correctamente, 
por  ejemplo  si  los  subconjuntos  y  generalidades  son  aplicados  a  las 
entidades  y  no  a  las  relaciones.  Semánticamente  es  correcto  cuando  los 
conceptos se usan teniendo en cuenta sus definiciones.  
A continuación se enuncian los errores más comunes: 
❖ Usar un atributo en lugar de una entidad. 
❖ No especificar una generalización o subconjunto. 
❖ Olvidar la propiedad de herencia en las generalizaciones.  
❖ Aplicar una interrelación binaria cuando es ternaria. 
❖ Usar una entidad en vez de una interrelación. 
❖ Olvidar algún identificador en una entidad. 
❖ Omitir alguna especificación de cardinalidad. 

Página 3 de 13
 Diseño Conceptual 

3. Minimalidad 

Se  considera  como  esquema  mínimo  cuando  cada  elemento  aparece 

una  sola  vez.  También se considera mínimo si se elimina algún elemento y 
no  se  pierde  información  relevante del sistema, por ejemplo si tenemos un 
atributo calculable en el modelo y lo eliminamos podemos observar que no 
se  pierde  contenido  de  la información del modelo.  Por ejemplo: es posible 
calcular  la  edad  de  una  persona  basándose  en  el  atributo  fecha  de 
nacimiento  y  extrayendo  la  fecha  del  equipo,  porcentajes  de descuentos, 
etc. 

4. Expresividad 

Es  expresivo  cuando  representa  los  requerimientos  en  forma  natural  y 

se puede entender con mucha facilidad. 

5. Legibilidad 

Un  diagrama  legible  es  cuando  se  respetan  determinados  criterios 

estéticos  que  reflejan  elegancia  y  comprensión.  Cómo  definir  un 
determinado  tamaño,  alto  y  ancho,  de  los  cuadrados  o  rectángulos  para 
representar  las  entidades,  adicionalmente  el  mismo  concepto  se  aplica 
para  los  rombos  de  las  relaciones,  y  los  trazos  horizontales,  diagonales,  o 
verticales de líneas para asociar los elementos del modelo. 

6. Auto-explicación 

Cuando  se  logra  explicar  las  propiedades  del  problema  con  los 
conceptos del modelo de bases de datos sin recurrir a otros medios.  

7. Extensibilidad 

Un  diagrama  de  bases  de  datos  es  extensible  cuando  se  adapta  a 
nuevos  conceptos  o  mejoras  de  paradigmas.  Para  alcanzar  estos 
objetivos  es  necesario  poder  descomponer  el  modelo  en  partes,  módulos 
o vistas, y permitir incorporar fácilmente cambios. 

Página 4 de 13
 Diseño Conceptual 

8. Normalidad 

Se  considera  esta  premisa  cuando  el  modelo  cumple  con  las  formas 
normales,  las  cuales  están  vinculadas  con  el esquema relacional (primera, 
segunda,  tercera,  cuarta  y  quinta  forma  normal,  además  una  variación  de 
la  tercera  denominada  Boyce-Codd).  Intentan  mantener  la  estructura 
lógica  de  los  datos  en  forma  limpia,  evitando  redundancia  innecesaria  de 
información,  disminuyendo  los  problemas  de  inserción,  actualización  y 
borrado de los datos. 

Esquema Conceptual 
Para  representar  las  necesidades  de  una  empresa  por  lo  general  se construyen 
uno  o  varios  esquemas conceptuales, y cada uno de ellos representa una visión de 
la  información  perteneciente  a  un  área  o  departamento,  es  decir,  producción 
tendrá  una  visión  personal  de  los  datos  con  respecto  a  los  demás departamentos 
en  su  área  funcional  específica,  compartiendo  parte  de  su  información  con  otras 
secciones. 
La  obtención  de  estos  diagramas  conceptuales  se  realiza  capturando  ​los 
requisitos  funcionales  ​por  cada  visión  detectada,  la  cual  consiste  en  poder extraer 
la funcionalidad del sector a través de documentos, informes, reportes, entrevistas, 
observaciones, diagramas de flujo, etc.  
A  los  esquemas  conceptuales  correspondientes  de  cada vista de usuario se los 
denomina  esquemas  conceptuales  locales.  Cada  uno  de  estos  se  compone  de 
entidades,  relaciones,  atributos,  dominios  de  atributos  e  identificadores.  También 
tendrá una documentación adicional que se irá produciendo durante su desarrollo.  
Las tareas a realizar en el diseño conceptual son las siguientes: 

1. Identificar​ las entidades 

Este  paso  intenta poder describir los objetos participantes del negocio y 
los  mismos  se  capturan con las especificaciones de los requerimientos de 
los usuarios. 
Se  intenta  identificar  los  sustantivos,  determinados  por  objetos 
concretos  o  abstractos  de  los  diferentes  elementos  que  participan  en  el 
negocio.  Obtenidos  de  las  expresiones  verbales  para  describir  las  tareas 

Página 5 de 13
 Diseño Conceptual 
realizadas  por  las  personas  día  a  día  en  su  trabajo,  además  se  debe 
contemplar  los  sinónimos  (cuando  dos  o  más  palabras  tienen  el  mismo 
significado),  o  los  homónimos  (cuando  una  palabra  puede  contener 
diferentes significados dependiendo de su contexto). 
También  puede  llegar  a  ocurrir  complicaciones  porque  las  personas 
cuando  intentan  narrar  las  especificaciones  utilizan  ejemplos  o  analogías, 
en  lugar  de  referenciar  las  funcionalidades,  hablan  de  puestos  o  nombres 
de personas concretas. 
Saber  si  un  objeto  es  una  entidad,  atributo  o  relación  no  es  tan  trivial, 
esto  dependerá  de  la  opinión  y  experiencia  del  diseñador,  porque 
diferentes  personas  pueden  clasificar  un  objeto  de  diferentes  maneras  y 
todas  pueden  ser  válidas.  Los  diseñadores  de  bases de datos deben tener 
una  visión  selectiva  y  clasificar  las  cosas  que  observan  dentro  del 
contexto de la empresa u organización.  
A  partir  de  las  especificaciones  de  los  usuarios  es  posible  que  no  se 
pueda  deducir  un  conjunto  único  de  entidades,  pero  después  de  varias 
iteraciones  del  proceso  de  análisis  de  los  datos  se  llegará  a  obtener  un 
conjunto de entidades adecuadas al sistema que se desea construir. 

2. Identificar las relaciones 

Una  vez  realiza  la  primera  etapa  podemos  comenzar  el  análisis  de  la 
conexiones entre las entidades. 
Se  intenta  identificar  las  expresiones  verbales  de  la  misma manera que 
han  sido  detectados  los  sustantivos,  algunas  de  estas  expresiones 
reveladas  pueden  llegar  a  no  reflejarse  en  el  esquema  conceptual  porque 
no  reflejan algo significativo, el empleado ofrece un determinado servicio a 
los clientes. 
Existe  la  posibilidad  de  detectar  relaciones  en  la  que  participan  más  de 
dos  entidades,  pero  la  mayoría  de  las  relaciones  son  binarias  (entre  dos 
entidades),  así  como  relaciones  recursivas  (una  relación  sobre  la  misma 
entidad). 
Una  relación  ternaria  está  compuesta por tres entidades por ejemplo un 
empleado  que  trabaja  en  un determinado proyecto con un carga asignado. 

Página 6 de 13
 Diseño Conceptual 
Si  participan  cuatro  entidades  se  denomina  cuaternaria,  etc.  Relación 
n-arias. 
Una  relación  recursiva es una relación donde la misma entidad participa 
más  de  una  vez  en  la  relación  con  distintos  papeles.  El  nombre  de  estos 
papeles  es  importante  para  determinar  la  función  de  cada  participación. 
Un empleado es jefe de otro empleado. 
Cada  relación  puede  contener  un  nombre  significativo  para  el  usuario y 
además  poseer  su  respectiva  par  de  cardinalidad,  mínima  y  máxima, 
participantes.  La  cardinalidad  es  un  tipo  de  restricción  utilizada  para 
comprobar  y  mantener  la  calidad  de  los  datos.  Estas  restricciones  son 
aserciones  sobre  las  entidades  y  pueden  aplicarse  cuando  se  actualiza  la 
base  de  datos  para  determinar  si las actualizaciones violan o no las reglas 
establecidas sobre la semántica de los datos. 
Las  reglas  que  definen  la  cardinalidad  de  las  relaciones  son  las  reglas 
de  negocio.  La  cardinalidad  expresa  la  cantidad  de  tupla/s  de  la  entidad 
extremo  destino  relacionada  con  un  total  de  tupla/s  de  la  entidad origen y 
ambas son participantes en la relación.   
Una  vez  completado  el  esquema  conceptual  con  sus  relaciones  es 
necesario  repasar  todas  las  especificaciones  para  comprobar  si  se  han 
detectado  o  si son correctas todas las relaciones, verificando la naturaleza 
de las mismas con los usuarios. 
A  veces,  surgen  problemas  cuando  se  está  diseñando  un  esquema 
conceptual.  Estos  problemas,  denominados  trampas,  suelen  producirse  a 
causa  de  una  mala  interpretación  en  el  significado  de  alguna  relación, por 
lo  que  es  importante  comprobar  que  el  esquema  conceptual  construido 
carece  de  dichas  trampas.  En  general  para  encontrar las trampas, hay que 
asegurarse  de  que  se  entiende  completamente  el  significado  de  cada 
relación.  Si  no  se  especifican  correctamente  las  relaciones  no  se  puede 
crear un esquema fielmente representativo de la realidad.  
Una  de  las  trampas  ocurre  cuando  el  esquema  representa  una  relación 
entre  entidades,  pero  el  camino  entre  algunas  de  sus  ocurrencias  es 
ambiguo.  El  modo  de  resolverla  es  reestructurando  el  esquema  para 
representar la asociación entre las entidades.  
Otra  de  las  trampas  sucede  si  el  camino  entre  una  y otra no existe para 
algunas  de  sus  ocurrencias.  En  este  caso,  se  produce  una  pérdida  de 

Página 7 de 13
 Diseño Conceptual 
información  pudiendo  ser  subsanar  introduciendo  la  relación  que  sugería 
el esquema y que no estaba representada. 

3. Identificar los atributos y asociarlos a entidades y relaciones 

Cuando  se  intenta  determinar  los  atributos  de  una  entidad  debemos 
pensar  cuales  son  las  cosas  contenidas  en  ella  para  permitir  diferenciarla 
de  las  demás  teniendo  en  cuenta  sus  propiedades y cualidades. Debemos 
también  considerar  a  las  relaciones  porque  ellas  pueden  contener 
atributos propios. 
Estos  atributos  pueden  ser  considerados  como  simples  o  compuestos, 
simples  son  aquellos  atributos  atómicos  indivisibles  y  los  compuestos  si 
se  pueden  subdividir  pero  se  deberá  apreciar  si  el  usuario  necesita 
manipular  división  para  que  la  misma sea tenida en cuenta. Por ejemplo el 
atributo  fecha  y  hora  compuesto  por  día,  mes  año,  hora,  minuto,  y 
segundos. 
Existe  la  posibilidad  de  detectar  atributos  derivados  o  calculables  a 
partir  de  otros  atributos,  como  ser  la  edad  de  una  persona  teniendo  la 
fecha  de  nacimiento  y  la  fecha  de  la  computadora,  si  estos son reflejados 
en  el  esquema  conceptual  es  necesario  etiquetarlos  para  ser  fácilmente 
identificados  en  las  etapas  posteriores  cuando  se  analice  cómo  van  a  ser 
implementados  en  la  BD.  Es  decir  si  se  almacenarán  en  la  BD  o  se 
obtienen a través de consultas.  
Cuando  se  están  reconociendo  los  atributos  se  puede  descubrir  alguna 
entidad  no  identificada  previamente  por  lo  que  hay  que  volver  al  principio 
introduciendo  esta  entidad  y  analizando  si  se  relaciona  con  otras 
entidades. 
Es  muy  útil  elaborar  una  lista  de  atributos  y  eliminar  de  esa  lista 
conforme  se  vayan  asociando  a una entidad o relación. De este modo, uno 
se  puede  asegurar  cómo  cada  atributo  se  asocia  a  una  sola  entidad  o 
relación,  y  una  vez  finalizado  este  procedimiento  se  han  asociado  todos 
los atributos. 
Hay  que  tener  mucho  cuidado  cuando  parece que un mismo atributo se 
debe  asociar  a  varias  entidades.  Esto  puede  ser  por  una  de  las  siguientes 
causas: 

Página 8 de 13
 Diseño Conceptual 

Se  han  identificado  varias  entidades,  como  director,  supervisor  y 

administrativo,  y  pueden  representarse  como  una  sola  entidad 
denominada  empleado.  En  este  caso,  se  puede  escoger  entre 
introducir  una  jerarquía  de  generalización,  o  dejar  las  entidades 
que representan cada uno de los puestos de empleado. 
Se  ha  identificado  una  relación  entre  entidades.  En  este  caso,  se 
debe  asociar  el  atributo  a  una  sola  de  las  entidades  y  hay  que 
asegurarse  de  que  la  relación  ya  se  había  identificado 
previamente.  Si  no  es  así,  se  debe  actualizar  la  documentación 
para recoger la nueva relación. 
Conforme  se  van  identificando  los  atributos,  se  les  asignan  nombres 
que  tengan  significado  para  el  usuario.  De  cada  atributo  se debe anotar la 
siguiente información: 
❖ Nombre y descripción del atributo. 
❖ Alias o sinónimos por los que se conoce al atributo. 
❖ Tipo de dato y longitud. 
❖ Valores por defecto del atributo (si se especifican). 
❖ Si el atributo siempre va a tener un valor (o si admite nulo). 
❖ Si  el  atributo  es  compuesto  y,  en  su  caso,  cuáles  son  los 
atributos simples que lo conforman. 
❖ Si el atributo es derivado cómo se calcula su valor. 
❖ Si el atributo es multivaluado. 
Los  atributos  también  pueden  clasificarse  en  monovalentes  o 
polivalentes.  Un  atributo  monovalente  es  aquel  que  contiene  un  solo valor 
para  cada  ocurrencia  de  la  entidad  o  relación  perteneciente.  Un  atributo 
polivalente  contiene  varios  valores  para  cada  ocurrencia  de  la  entidad  o 
relación  perteneciente.  A  estos  atributos  también  se  les  denomina 
multivaluados  y  pueden  tener  un  número  máximo  y  un  número  mínimo de 
valores o cantidad de valores indeterminados.  
Cada  atributo  polivalente  deberá  crear  una  entidad  y  representará  al 
atributo  como  monovalente  en  una  ocurrencia  de  la  nueva  entidad.  Por 
ejemplo  si  tenemos  una  entidad  “Producto”  la  cual  a  su  vez  contiene  un 
atributo  polivalente  material  será  necesario  la  creación  de  una  nueva 

Página 9 de 13
 Diseño Conceptual 
entidad  “Producto_Material”,  quedando  reflejado  el  conjunto de materiales 
por producto. 

4. Determinar los dominios de los atributos 

El  dominio  de  los  atributos  referencia  al  conjunto  de  valores  posible  de 
aceptar,  contemplando  la  posibilidad  de  cumplir  si  es  continuo  o discreto. 
Por continuo se considera a uno o varios rangos de valores a ser aceptado, 
ejemplo  (1,  …  ,  30)  y  (300,  ...  ,  500),  siendo  posible  también  alternar 
contenidos  alfanuméricos.  Y  por  discreto  son  aquellos  valores  que  no 
representan  ningún  patrón  de  comportamiento  como  ser  (20,  35,  60), 
también  es  posible  obtener  valores  alfabéticamente  siendo  posible 
especificar los días de la semana. 
Un  esquema  conceptual  está  completo  si  se  incluye  los  dominios  de 
cada  atributo:  los  valores  permitidos  para  cada  atributo,  su  tamaño  y  su 
formato.  También  se  puede  incluir  información  adicional,  por  ejemplo,  las 
operaciones  posibles  a  realizar  sobre  cada  atributo,  cuales  atributos 
pueden compararse entre sí o qué atributos pueden combinarse con otros.  

5. Determinar los identificadores 

Un  identificador  de  una  entidad  es  un  atributo  (simple)  o  conjunto  de 
atributos  (compuestos)  para  determinar  de  modo  único  cada  ocurrencia 
de  esa  entidad.  Un  identificador  de  una  entidad  debe  cumplir  dos 
condiciones:  

a) No pueden existir dos ocurrencias de la entidad con el mismo valor 
del identificador.  
b) Si se omite cualquier atributo del identificador la condición anterior 
deja de cumplirse.  
Dentro  de  los  conjuntos  de  entidades  existen  los  siguientes  tipos  de 
claves: 
❖ Superclave:  es  un  subconjunto  de  atributos  o  todos  que  permite 
distinguir  unívocamente  cada  una  de  las  entidades  de un conjunto 
de  entidades,  no  existe  una  ocurrencia de la relación con el mismo 
valor  de la superclave. Ejemplo, el atributo -“​idCliente​”-​ del conjunto 
de  entidades -“​Cliente​”-​ permite  diferenciar  una  entidad -“​Cliente​“- 

Página 10 de 13
 Diseño Conceptual 
de  las  otras,  conformando  una  superclave.  Pero,  también  la 
concatenación  de -“​nombreCliente​”-​ y -“​idCliente​”-​ es  una 
superclave  del  conjunto  de  entidades -“​Cliente​”-​.  El  atributo  por  si 
solo -“​nombreCliente​”-​ del  conjunto  de  entidades  -“​Cliente​”-  no  es 
una  superclave,  porque  varias  personas  podrían  tener  el  mismo 
nombre.  Se  podría  concatenar  todos  los  atributos  del  conjunto  de 
entidades -“​Cliente​”- ​y se formaría una superclave. 
❖ Clave  candidata:  es  el  atributo  o  atributos  sin  considerar  los 
atributos  participantes  de  la  entidad  para  identificar  una  tupla  del 
resto,  y  además  puede  ser  seleccionada  para  ser la clave principal 
porque cumple con la característica de ser única. 
❖ Clave  primaria:  una  de  las  claves  candidatas  es  elegida  por  el 
diseñador  de  la  base  de  datos  para  identificar  unívocamente  una 
entidad  de  un  conjunto  de  entidades.  Utilizada  para  asociar 
distintos  conjuntos  de  entidades  replicando  su  valor.  Todo 
conjunto  de  entidades  tiene  al  menos  un  identificador  y  puede 
tener  varios  identificadores  alternativos,  a  diferencia  de  las 
relaciones que no tienen identificadores por ser el resultado de una 
consulta ejecutada.  
Cuando  se  determinan  los  identificadores  es  fácil  darse  cuenta 
si  una  entidad  es  fuerte  o  débil.  Si  una  entidad  tiene  al  menos  un 
identificador  es  fuerte  (otras  denominaciones  son:  padre, 
propietaria  o  dominante).  Si  una  entidad  no  tiene  atributos  que 
puedan ser un identificador es débil. 

6. Determinar las jerarquías de generalización (si las hay) 

Una  entidad  (E)  es  una  generalización  de  un  grupo  de  entidades  (E , E

,  ...,  E ),  si  una  ocurrencia  de  cada  una  de  esas  entidades  es  también 
una  ocurrencia  de  E.  Todas  las  propiedades  de la entidad genérica (E) son 
heredadas por las subentidades.  
Cada  jerarquía  es  total  o  parcial  y  a  su  vez  pueden  ser  exclusivas  o 
superpuestas.  Una  jerarquía  es  total  si  cada  ocurrencia  de  la  entidad 
genérica  corresponde  al  menos  con  una  ocurrencia  de alguna subentidad. 

Página 11 de 13
 Diseño Conceptual 
Es  parcial  si  existe  alguna  ocurrencia  de  la  entidad  genérica  no 
corresponde con ninguna ocurrencia de ninguna subentidad.  
Una  jerarquía  es  exclusiva  si  cada  ocurrencia  de  la  entidad  genérica 
corresponde  con  una  ocurrencia  de  una  sola  de  las  subentidades.  Es 
superpuesta  si  existe  alguna  ocurrencia  de  la  entidad  genérica  que 
corresponde a ocurrencias de dos o más subentidades diferentes.  

7. Dibujar el diagrama entidad-relación 

Una  vez  identificados  todos los conceptos se puede dibujar el diagrama 
entidad-relación  correspondiente  a  una  de  las  vistas  de  los  usuarios.  Se 
obtiene así un esquema conceptual local. 

8. Instanciar el modelo 
Se  realiza  la  creación  de  la  base  y  posteriormente  se elabora una carga 
previa  con  datos  reales  para  poder  realizar  diferentes  pruebas  y  permitir 
poder  verificar  si  el  diseño  de  la  base  de  datos  es  posible  de  ser 
implementado en un motor de SGBD utilizado. 

9. Implementar el DER 
Una  vez  realizada  la  carga  de  datos  real  se  procede  a  ejecutar  un 
conjunto  de  consultas  de  datos  para  validar  si  las  relaciones  entre  las 
tablas  son  consistentes,  es  posible  poder  construir  estas  consultas 
utilizando  el  álgebra  relacional  para  la  extracción  de  los  datos 
almacenados. 

10. Revisar el esquema conceptual local con el usuario 

Para  finalizar  la  fase  del  diseño  conceptual,  se debe revisar el esquema 
conceptual  local  con  el  usuario.  Este  esquema  está  formado  por  el 
diagrama  entidad  relación  y  toda  la  documentación  concerniente  para 
describir  el  esquema,  como  ser  el  diccionario  de  datos.  Si  se  encuentra 
alguna  anomalía,  se  debe  corregir  haciendo  los  cambios  oportunos,  y 
posiblemente  haya  que  repetir  alguno  de  los  pasos  anteriores.  Este 
proceso  debe  repetirse  hasta  estar  seguro  que  el  esquema  conceptual  es 
una  fiel  representación  de  la  parte  de  la  empresa  que  se  está  tratando  de 
modelar. 

Página 12 de 13
 Diseño Conceptual 

Metodología del Diseño DER 

Recomendamos repasar el apunte de metodología del diseño DER 
 
 

Página 13 de 13