Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Diseño de bases de datos distribuidas

Unidad 2 BDD
by

Lucero Zamora

on 9 April 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Diseño de bases de datos distribuidas

Diseño de BDD Unidad 2 Consideraciones de diseño de BDD Razones Fragmentación BDD Ing. Lucero Zamora Se sugiere que la organización de sistemas distribuidos puede ser investigada a lo largo de tres dimensiones ortogonales Estos tres niveles son:
1. Nivel de distribución
2. Comportamiento de los patrones de acceso.
3. Nivel de conocimiento en el comportamiento del patrón de acceso. La imagen representa los tres niveles a lo largo de las dimensiones. En términos del nivel de distribución hay tres posibilidades. Primero: Que no haya distribución; cada aplicación y sus datos se ejecutan en
un sitio y no hay comunicación con algún otro programa o acceso a algún archivo de
datos de otro sitio. Esto caracterizaba a los primeros días de trabajo en red pero ya no
es tan común en nuestros tiempos. Segundo: Distribución de datos; Todos los programas son replicados en todos
los sitios pero no los archivos de datos por consiguiente las peticiones de los usuarios
son manejadas en el sitio donde fueron originados y solo los archivos de datos
necesarios son movidos alrededor de la red. Datos + programas: los archivos de datos y los programas pueden ser compartidos. Estrategias de diseño alternativos Se consideraran estrategias para el diseño de base de datos que se usan comúnmente son principalmente dos enfoques. El enfoque Up-Down y el enfoque Bottom-Up que como su nombre lo indica son enfoques muy diferentes para el proceso de diseño pero como la mayoría de los diseñadores de software saben es muy raro que sea suficiente que una aplicación se ajuste perfectamente a uno de estos dos enfoques. Proceso de diseño Top-Down La actividad para este proceso de diseño comienza con el análisis de requerimientos que define el ambiente del sistema y determina tanto las necesidades de los datos como las del proceso. Con respecto al DBMS este es definido en base al desempeño, la confiabilidad y disponibilidad, economía y flexibilidad. El documento resultante de el análisis de requerimientos es la entrada para el
desarrollo de dos actividades paralelas que son el diseño conceptual y el diseño visual. El diseño visual: se encarga de definir las interfaces para el usuario final El diseño conceptual: es el proceso por el cual la empresa es examinada para determinar los tipos de entidades y las relaciones entre esas entidades. En ambas actividades de diseño el usuario necesita especificar las entidades de datos y debe determinar la aplicación que correrá en a base de datos así como la información estática acerca de la aplicación. El esquema conceptual global y la información de los patrones de acceso recopilados como resultado del diseño visual son entradas para el diseño de la
distribución. El objetivo en esta etapa es diseñar el esquema local conceptual distribuyendo las entidades sobre los sitios del sistema distribuido. Las relaciones distribuidas son comúnmente divididas en sub-relaciones llamadas fragmentos los cuales estarán distribuidos. Así entonces la actividad de diseño de distribución consiste
en dos pasos: Fragmentación y asignación. El último paso en este proceso de diseño es el diseño físico, en el cual mapeamos los esquemas conceptuales locales con los dispositivos de almacenamiento físicos disponibles en los sitios correspondientes. Proceso de diseño Bottom-Up Este tipo de proceso es conveniente cuando las bases de datos ya existen y las tareas del proceso de diseño involucran integrarlas en una sola base de datos. El punto de inicio de este proceso son los esquemas conceptuales locales individuales; el
proceso consiste en integrar esos esquemas en un esquema conceptual global. TAREA:
Niveles de transparencia en una BDD Desde el punto de vista de la distribución de datos no hay realmente una razón para la fragmentación después de todo en sistemas distribuidos la distribución es realizada en la base de los archivos completos. Pero con respecto a la fragmentación es necesaria debido a tres aspectos: 1.- Encontrar la unidad de relación apropiada; ya que el acceso a la aplicación no se hace en la totalidad de las relaciones de la base pero si de un subconjunto de ellas. 2.- Si tenemos las sub-relaciones como unidades de relación cuando tratemos de accesar a datos que estén en otros sitios será mas conveniente hacer la replicación de los datos que están en las sub relaciones en lugar de traer los datos de todas las relaciones. 3.- Si tomamos las sub-relaciones como unidades de relación se pueden ejecutar una cantidad de transacciones concurrentemente, además la
fragmentación de relaciones típicamente resulta en la ejecución paralela de un único query dividiéndolo en sub-queries que operan sobre los fragmentos. Pero como en todo hay costes y uno de ellos es que si necesitamos recuperar datos de dos fragmentos los obtenemos pero después tendremos que unirlos y esto es costoso evitar esto es una de las principales problemáticas de la fragmentación. El segundo problema es referido al control de la semántica de los datos, especialmente en la revisión de la integridad. Alternativas Esencialmente las instancias de relación son tablas y una de las situaciones es
encontrar un método o forma de convertir la tabla completa en sub-tablas mas pequeñas. Tenemos dos alternativas para esto, dividirlas en forma horizontal o en forma vertical. Corrección de las reglas Grado La fragmentación horizontal se da sobre las tuplas y la fragmentación vertical se da sobre los atributos. Si se usa más de una fragmentación estas deben estar anidadas y si se utilizan fragmentaciones anidadas de diferentes tipos la fragmentación se convierte en una fragmentación hibrida. El grado al cual debería ser fragmentada la base de datos es una decisión importante que afecta al desempeño de la ejecución del query. El grado de fragmentación dependerá de las necesidades de nuestra aplicación la cual correrá en la base de datos Hay tres reglas importantes que debemos reforzar cuando se va a realizar la fragmentación: Completitud: Esta referida a una descomposición sin pérdida de datos, es decir que se asegure que los datos en una relación global pueden ser mapeados en fragmentos si ningún tipo de perdida Reconstrucción: la posibilidad de reconstrucción de una relación global a partir de fragmentos de relaciones asegura que las restricciones definidas sobre los datos en forma de dependencias sean preservadas. Disyunción: Dice que si particionamos la relación de forma horizontal un dato que tengamos en un fragmento no debe estar presente en algún otro de los fragmentos de la relación.
Full transcript