UNIDAD II 

2.1 Consideración de diseño 

1. Diseño conceptual el cual representa el esquema general de la base de datos local. Su 
esquema consiste:

· Nivel conceptual
· Nivel lógico
· Nivel físico y diccionario de datos. 

2. diseño físico, permite mapear el esquema conceptual a las áreas de almacenamiento y 
determina los métodos de acción a la base de datos y donde interviene la arquitectura del 
sistema. 

Existen diferentes tipos de Sistemas de Gestión de Bases de Datos Distribuidos. 

De  acuerdo  a  sus  características  y  dependiendo  de  la  homogeneidad  de  los  SGBD 
locales, de la distribución de los datos y de la autonomía de los mismos. 

La homogeneidad se subdivide en 2:

· Los  que  todos  los  SGBD  sus  iguales  donde  se  obtiene  mi  único  producto  y 
lenguaje de consulta por lo que son sistemas integrados, y los que los SGBD son 
diferentes o heterogéneos donde aun cuando utilizan el mismo modelo de datos se 
tienen  distintos  productos  y  lenguajes  de  consulta  que  requieren  ser  integrados 
entendiéndose como productos el resultado de las consultas y transacciones. 

La distribución es la que determina si los datos están divididos físicamente sobre múltiples 
sitios que se comunican entre si o si se mantienen centralizados. 

La  autonomía  la  cual  determina  la  distribución  del  control  y  se  distinguen  3  niveles  de 
autonomía: diseño, de comunicación y de ejecución. 

Partiendo de estas 3 características, los sistemas se subdividen en:

· Sistemas  estrechamente  ligados  o  sistemas  compuestos  los  cuales  son  los  que 
todo el acceso a los datos se realiza a través del procesador de datos distribuido 
con las sedes locales totalmente dependientes a él, él gestiona  todos los accesos 
y funciones de administración. 

Ejemplo:

1 
 SGBD

· Acceso
· Realiza 
transacción
· Administración

Arquitectura cliente/servidor 
Figura 4.1

· Sistemas  semiautónomos  o  sistemas  federados  en  el  que  cada  procesador  local 
actúa  de  forma  autómata  e  independiente,  es  decir,  cada  uno  de  ellos  tiene  sus 
usuarios,  administradores,  transacciones  y  aplicaciones  además  de  porciones 
específicas de la base de datos distribuidas.
· Sistemas  multi­base de datos, en  la  que  los  procesadores  locales  no  conocen  la 
existencia  de  otros  sistemas  de  gestión  de  base  de  datos  ni  como  comunicarse 
entre  ellos  y  por  lo  que  se  encuentran  en  total  autonomía,  es  el  caso  de  los 
sistemas middleware. 

Otros aspectos para  el diseño físico, es  la  arquitectura  de estos  sistemas  los  cuales 

son de dos tipos:
· ANSI/X3/SPARC  (American  National  Standard  Institute­Standards  Planning  and 
Requirements Committec), la cual está basada en esquema conceptual, esquema 
lógico  o  externo  y  el  esquema  físico  o  interno.  Corresponde  a  los  sistemas 
federados y son una extensión de los sistemas centralizados donde la integración 
está  dada  por  la  omisión  de  los  esquemas  externos  locales.  El  esquema 
conceptual  global  es  un  subconcepto  de  los  esquemas  conceptuales  locales  del 
sitio  que  comparte  datos  y  los  esquemas  globales  ofrecen  una  independencia 
lógica de los datos. 

Ejemplo: 

2 
 Esquema  Esquema  Esquema 
externo  externo  .  .  . externo 
global 1  global 2  global n 

Esquema  Esquema  Esquema  Esquema  Esquema 

externo  externo  conceptual  externo  externo 
local 1  local 1z  global  local n1  local nm 

Esquema  Esquema 
conceptual  conceptual 
BD local 1  BD local n 

Esquema interno BD  Esquema interno BD 
local 1  local n 

Figura 4.2 Esquema ANSI/X3/SPARC

· Arquitectura multibase: en los que no se tiene esquema global conceptual, por lo 
que la autonomía local es completa, los SGBD pueden ser de diferentes tipos, la 
integración de ellos se realiza atraves de sistemas de aplicación que permiten a 
los usuarios globales y localestrabajar sin verse afectados en la distribución de los 
datos. 

Ejemplo 

3 
 Esquema  Esquema  Esquema 
externo 1  externo 2  externo n 

Esquema  Esquema  Esquema 

conceptual  conceptual  conceptual 
BD local 1  BD local 2  BD local n 

Esquema  Esquema  Esquema 

interno BD  interno BD  interno BD 
local 1  local 2  local n

Figura 4.3 

Por  lo  que  en  resumen  se  debe  considerar  en  el  diseño  de  las  BDD:  el  diseño  de  la 
fragmentación  la  cual  se  determina  por  la  forma  en  que  las  relaciones  globales  se 
subdividen en fragmentos horizontales, verticales ó mixtos y el diseño de la  asignación de 
los fragmentos y en la solicitud de ellos. 

Ejercicio 

Determine la arquitectura del siguiente ejercicio. 

Por otra parte, existen dos aproximaciones básicas en el diseño: la top­down y la bottom 
up.  La  top­down  también  conocida  como  metodología  ascendente  o  enfoque  de  arriba 
hacia  abajo  se  utiliza  cuando  existen  varios  base  de  datos  locales  y  se  quiere  contraer 
una base de datos distribuidos, por lo que se parte de distintos esquemas lógicos locales 
(ELL) que se corresponden a bases de datos ubicadas en diferentes modos de una real y 
se integran, parte de ellos o todo, en un único esquema global. 
Cuando  no  existen  bases  de  datos  locales  o  se  desea  partir  de  cero  se  inicia  con  un 
análisis de requerimientos para definir el diseño conceptual y las vistas de usuario. 
A  partir  de  aquí  se  define  un  esquema  global  y  esquemas  externos  necesarios.  A 
continuación se diseña la fragmentación en los sitios creando las imágenes físicas. Esta 
aproximación se completa ejecutando en cada sitio “el diseño físico” de los datos que se 
localizan en él. 

En resumen las fases del diseño top­down se muestran en la siguiente figura quedando 
integrados así. 

4 
 Análisis de requerimientos 

Objetivos 

Usuario 
Diseño Conceptual  Diseño de vistas 
Integración de vistas 

Esquema conceptual  Información de  Esquemas 

global  acceso 

Usuario
Diseño de la Distribución 

Esquemas locales 
conceptuales 

Diseño Físico 

Esquema internos 
locales 

Figura 4.4 

Ejemplo: 

Una compañía productora de flores de invernadero desea controlar la información de sus 
productos  por  lo  que  desea  saber  cual  es  la  producción  por  flores  así  como  por 
invernadero. Además desea conocer las ventas por semana, mes y año. Es importante la 
demanda de flores de acuerdo a la temporada por lo que desea el nombre de la flor, la 
temporada,  país  donde  es  demandada,  total  de  flores  producidas,  invernadero  que  la 
produce así como el costo de producción, de venta y de transportación. Los invernaderos 
de la empresa se encuentran en: Amecameca e Ixtapa de la Sal en el Estado de México y 
en Cuernavaca y Tenayuca Estado de Morelos en México. 

5 
Análisis de Requerimientos:
· Una base de datos local que contenga las siguientes entidades: 
Flores: nombre de la flor, precio en el mercado, costo de producción, periodo de 
floración, tiempo de traslado, costo de transporte, temporada de demanda. 
Lugar de demanda por nombre de ciudad, estado y país. 
Producción: subtotal de producción por flor, total de producción, costo de 
producción, insumos para la producción. 
Ventas: total de ventas por producto, datos generales del cliente a quien se le 
vendió. 

Objetivos:
· Desarrollar una base de datos local.
· Desarrollar una base de datos distribuidas que ofrezca información sobre la 
existencia de los productos, en este caso flores, para la realización de pedidos y 
prospectiva de la producción anual. 

Diseño Conceptual 

Modelo entidad­relación 

Diseño de vistas 
Se desarrollaran las siguientes consultas, las cuales podrán realizarse a través de 
una aplicación desarrollada en un lenguaje huésped. 
Consulta de la existencia de flores, precio. 
Alta, modificación, consulta  de productos. 
Alta, modificación, consulta  de ventas.

6 
Los usuarios que accederán a la base de datos local son: 

Usuario  Departame  Tabla  Permisos  Autorizaciones  Observaciones 

nto 

Operador  Producción  Flores  Lectura y  Alta, 

escritura  modificación y 
consulta de 
producto 

Contador  Ventas  Venta  Lectura y  Alta y 

escritura  modificación y 
consulta de 
producto  y 
venta 

Gerente  Gerencia  Flores,  lectura  Consulta 

General  venta, 
producción 

Operador  Ventas  Flores  Lectura y  Alta, 

de pedido  escritura  modificación y 
consulta de 
producto 

Administrad  Soporte  Flores,  Lectura y 

or  técnico  producción  escritura 
, 

Tabla 1 

Esquema conceptual global 
Diagrama relacional 
Diccionario de datos 

DISEÑO DE LA DISTRIBUCIÓN 

Para el diseño de la distribución se debe analizar la fragmentación de datos que se va a 
realizar, externa en cuanto a las tuplas, vertical por los dominios o mixta de ser necesaria, 
además del tema de asignación, por ser temas posteriores a este se retomará este 
ejercicio posteriormente en el diseño distribuido.

7 
 Bottom up o metodología descendente o enfoque de diseño hacia arriba.

· Se  utiliza  a  partir  de  BD  existentes  y  parte  de  un  esquema  lógico  global  (ELG)  que  es 
constituido por los distintos esquemas lógicos que  se definen dentro de él generando los 
esquemas  de  fragmentación,  asignación  y  replicación  los  cuales  determinan  la 
distribución de los datos a través de los nodos de la red.(ver figura 4.5) 

Esquema Lógico 
Global 

Esquema Lógico  Esquema Lógico  Esquema 

Amecameca  BD Ixtapa  Lógico 

BD  BD Ixtapa 
Amecamec 
a  BD 
Tenayuca

4.5 Diseño Bottom up 

Los esquemas de fragmentación se basan en el análisis de los datos utilizados por las 
distintas ap0licaciones que acceden a la base de datos para crear relaciones más 
pequeñas y mas adaptados a las operaciones de recuperación y actualización, es decir, 
tener los datos divididos según  la utilización que de ellos se hace. Sin embargo, en los 
esquemas de asignación y replicación se fija desde que nodo se demandan los datos y e 
tipo de operación que se realiza (si es de consulta o actualización), para que estas 
operaciones se puedan llevar a cabo de forma local y minimizar de esta forma el tráfico 
por la red que los ralentiza. 
La replicación o duplicación se puede realizar cuando desde distintos nodos, se requiere 
la misma información, si además las operaciones son de consulta no existe ningún 
problema en duplicar los datos. Si por el contrario se realiza actualización de los datos el 

8 
SGBD debe asegurar que todas las copias de los datos modificados. Es importante 
analizar ventajas y desventajas de replicar  los datos. 

2.2 Diccionario de Datos (complementarlo pues esto no es lo mío) 

Un  diccionario  de  datos  es  un  conjunto  de  metadatos  que  contiene  las  características 
lógicas  de  los  datos  que  se  van  a  utilizar  en  el  sistema  que  se  programa,  incluyendo 
nombre, descripción, alias, contenido y organización. 

Estos  diccionarios  se  desarrollan  durante  el  análisis  de  flujo  de  datos  y  ayuda  a  los 
analistas  que  participan  en  la  determinación  de  los  requerimientos  del  sistema,  su 
contenido también se emplea durante el diseño del proyecto. 

Identifica  los  procesos  donde  se  emplean  los  datos  y  los  sitios  donde  se  necesita  el 
acceso  inmediato  a  la  información,  se  desarrolla  durante  el  análisis  de  flujo  de  datos  y 
auxilia  a  los  analistas  que  participan  en  la  determinación  de  los  requerimientos  del 
sistema, su contenido también se emplea durante el diseño. 

En un diccionario de datos se encuentra la lista de todos los elementos que forman parte 
del flujo de datos de todo el sistema. Los elementos mas importantes son flujos de datos, 
almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripción 
de todos estos elementos. 

Ejemplos 

Nombre = Título + Primer­nombre + Apellido­paterno + Apellido­materno 

Título = [ Sr | Sra | Dr | Ing] 

Primer­nombre = {caracter} 

Apellido­paterno = {caracter} 

Apellido­materno = {caracter} 

caracter = [A­Z|a­z| |’] a

9 
de se almacenan los datos del sistema, incluyendo nombre, descripción, alias, contenido y 
organización.  Identifica  los  procesos  donde  se  emplean  los  datos  y  los  sitios  donde  se 
necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de 
datos y auxilia a los analistas que participan en la determinación de los requerimientos del 
sistema, su contenido también se emplea durante el diseño. 

Razones para su utilización: 

1­ Para manejar los detalles en sistemas muy grandes, ya que tienen enormes cantidades 
de  datos,  aun  en  los  sistemas  mas  chicos  hay gran  cantidad  de  datos.  Los  sistemas  al 
sufrir cambios continuos, es muy difícil manejar todos los detalles. Por eso se registra la 
información, ya  sea  sobre  hoja de papel o  usando procesadores de  texto. Los  analistas 
mas organizados usan el diccionario de datos automatizados diseñados específicamente 
para el análisis y diseño de software. 

2­  Para  asignarle  un  solo  significado  a  cada  uno  de  los  elementos  y  actividades  del 
sistema.  Los  diccionarios  de  datos  proporcionan  asistencia  para  asegurar  significados 
comunes para los elementos y actividades del sistema y registrando detalles adicionales 
relacionadas con el flujo de datos en el sistema, de tal manera que todo pueda localizarse 
con rapidez. 

3­ Para documentar las características del sistema, incluyendo partes o componentes así 
como  los  aspectos  que  los  distinguen.  Tambien  es  necesario  saber  bajo  que 
circunstancias  se  lleva a  cabo  cada proceso  y con que frecuencia ocurren.  Produciendo 
una  comprensión  mas  completa.  Una  vez  que  las  características  están  articuladas  y 
registradas,  todos  los  participantes  en  el  proyecto  tendrán  una  fuente  común  de 
información con respecto al sistema. 

4­ Para facilitar el análisis de los detalles con la finalidad de evaluar las características y 
determinar  donde  efectuar  cambios  en  el  sistema.  Determina  si  son  necesarias  nuevas 
características  o  si  están  en  orden  los  cambios  de  cualquier  tipo.  Se  abordan  las 
características:

· Naturaleza  de  las  transacciones:  las  actividades  de  la  empresa  que  se  llevan  a 
cabo mientras se emplea el sistema.
· Preguntas: solicitudes para la recuperación o procesamiento de información para 
generar una respuesta especifica.

10 
 · Archivos y bases de datos: detalles de las transacciones y registros maestros que 
son de interés para la organización.
· Capacidad del sistema: Habilidad del sistema para aceptar, procesar y almacenar 
transacciones y datos 

5­ Localizar errores y omisiones en el sistema, detectan dificultades, y las presentan en un 
informe. Aun en los manuales, se revelan errores. 

Contenido de un registro del diccionario 

El diccionario tiene dos tipos de descripciones para el flujo de datos del sistema, son los 
elementos datos y estructura de datos. 

Elemento dato:  son  los  bloques  básicos para  todos  los demás  datos del  sistema, por  si 
mismos  no  le  dan  un  significado  suficiente  al  usuario.  Se  agrupan  para  formar  una 
estructura de datos. 

Descripción:  Cada  entrada  en  el  diccionario  consiste  de  un  conjunto  de  detalles  que 
describen los datos utilizados o producidos por el sistema. Cada uno esta identificado con: 
Un  nombre:  para  distinguir  un  dato  de  otro.  Descripción:  indica  lo  que  representa  en  el 
sistema. Alias: porque un dato puede recibir varios nombres, dependiendo de quien uso 
este dato. Longitud: porque es de importancia de saber la cantidad de espacio necesario 
para  cada  dato.  Valores  de  los  datos:  porque  en  algunos  procesos  solo  son  permitidos 
valores muy específicos para los datos. Si los valores de los datos están restringidos a un 
intervalo especifico, esto debe estar en la entrada del diccionario. 

Estructura  de  datos:  es  un  grupo  de  datos  que  están  relacionados  con  otros  y  que  en 
conjunto describen un componente del sistema. 

Descripción: Se  construyen  sobre  cuatro  relaciones de  componentes.  Se pueden  utilizar 

las  siguientes  combinaciones  ya  sea  individualmente  o  en  conjunción  con  alguna  otra. 
Relación secuencial: define los componentes que siempre se incluyen en una estructura 
de  datos.  Relación  de  selección:  (uno  u  otro),  define  las  alternativas  para  datos  o 
estructuras  de  datos  incluidos  en  una  estructura  de  datos.  Relación  de  iteración: 
(repetitiva), define la repetición de un componente. Relación opcional: los datos pueden o 
no estar incluidos, o sea, una o ninguna iteración. 

Notación
11
Los analistas usan símbolos especiales con la finalidad de no usar demasiada cantidad de 
texto  para  la  descripción  de  las  relaciones  entre  datos  y  mostrar  con  claridad  las 
relaciones estructurales. En algunos casos se emplean términos diferentes para describir 
la misma entidad (alias) estos se representan con un signo igual (=) que vincula los datos.

12