Sie sind auf Seite 1von 15

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.

2
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:

Esquem Esquema Esquema


a externo . . externo
externo global 2 global n
global 1

Esquema Esquema Esquema Esquema Esquema


externo externo conceptu externo externo
local 1 local 1z al global local n1 local nm

Esquema Esquema
conceptu conceptu
al BD al BD
local 1 local n
3
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

4
Esquema Esquema Esquema
externo 1 externo 2 externo n

Esquema Esquema Esquema


conceptua conceptua conceptua
l BD local l BD local l BD local
1 2 n

Esquema Esquema Esquema


interno interno interno
BD local 1 BD local 2 BD 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
5
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í.

Análisis de
requerimientos

Objetivos

Usuario
Diseño Diseño de vistas
Conceptual Integración de
vistas
Esquema Información de Esquemas
conceptual global acceso externos

Usuari
Diseño de la o
Distribución

Esquemas locales
conceptuales

6
Diseño Físico

Esquema internos
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.

7
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.


8
Alta, modificación, consulta de productos.

Alta, modificación, consulta de ventas.

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,

9
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.

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)

10
Esquema Lógico
Global

Esquema Lógico Esquema Esquema


Amecameca Lógico BD Lógico
Ixtapa

BD
Amecamec BD Ixtapa
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
11
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
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]

12
Primer-nombre = {caracter}

Apellido-paterno = {caracter}

Apellido-materno = {caracter}

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

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

13
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.
• 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
14
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

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.

15

Das könnte Ihnen auch gefallen