Sie sind auf Seite 1von 14

BASES DE DATOS

DISTRIBUIDAS – EJERCICIOS

BASES DE DATOS AVANZADAS


DEPARTAMENTO DE INFORMÁTICA

BDA INGENIERÍA TÉCNICA EN INFORMÁTICA DE GESTIÓN – G11

SUPUESTOS PRÁCTICOS (1)

 DISEÑ
DISEÑO DE UNA BASE DE DATOS
DISTRIBUIDA:

GRUPO DE RADIODIFUSIÓ
RADIODIFUSIÓN SUPERSOUND

-2

1
SUPUESTO PRÁCTICO –
ENUNCIADO (I)
 El grupo de comunicaciones por radio Supersound (GRS) cuenta con 3
emisoras locales en la Comunidad. En cada una de ellas se emiten varios
programas, que cuentan con diferentes anunciantes. En cada emisora una
serie de locutores dirigen los programas.

 Se desea modelar una base de datos distribuida que gestione los datos
que maneja GRS, de manera que se dote de la mayor autonomía local a
las emisoras, sabiendo que el funcionamiento de la empresa es el
siguiente:
 Las sedes se identifican mediante su código de emisora, que es 001, 002 y
003 respectivamente.
 Cada emisora tiene un nombre y una dirección.
 En cada emisora trabajan varios locutores, que sólo colaboran en una
emisora.

-3

SUPUESTO PRÁCTICO –
ENUNCIADO (II)
 La empresa guarda los siguientes datos de cada locutor: código, DNI,
nombre, teléfono, tono de voz, timbre de voz y horas de emisión por
semana.
 En la sede 001 se trabaja en colaboración con una escuela de doblaje. Por
esta razón en ella se guardan datos sobre las características de la voz de los
locutores de GRS (tono, timbre), así como de su experiencia (horas de
emisión por semana)
 Cada emisora difunde una serie de programas de ámbito local. Dichos
programas son exclusiva de cada emisora. Sobre ellos existe un código, una
descripción, un día a la semana y una hora de emisión. Además, un
programa puede ser musical o noticiero. En el primer caso se guardará el
estilo musical, y en caso de ser noticiero se conservará su línea editorial.
 Diferentes anunciantes pueden publicitarse dentro de cada programa,
estableciéndose un precio fijo por programa y anunciante. Un anunciante
tiene un CIF que lo identifica, un nombre y una descripción del negocio que
maneja.

-4

2
SUPUESTO PRÁCTICO -
ENUNCIADO (y III)
 Se pide:
 Realizar el diseño centralizado puro de la BD
 Producto generado: Esquema E/R
 Identificar los sitios de distribución (SEDES) y sus respectivos roles
 Producto generado: Tabla de sedes y roles
 Analizar qué distribuir (identificación accesos frecuentes, etc)
 Producto generado: Resumen del análisis
 Fragmentación
 Producto generado: Esquema de fragmentación
 Asignación de fragmentos a los sitios
 Producto generado: Esquema de asignación
 Replicación
 Producto generado: Esquema de replicación

 Justificar las decisiones tomadas en cada paso

-5

SOLUCIÓN: ESQUEMA E/R

EMISORA emite 1:N ANUNCIANTE

trabaja 1:N
tiene_
PROGRAMA anunciante
N:M

LOCUTOR

MUSICAL NOTICIERO

-6

3
SOLUCIÓN: MODELO LÓGICO

-7

SOLUCIÓN: IDENTIFICACIÓN
DE SEDES

 3 SEDES ALMACENAMIENTO:

CODIGO_EMISORA=001 CODIGO_EMISORA=002 CODIGO_EMISORA = 003

 SEDE 1 (CENTRAL): ROLES: DOBLAJE y EMISORA


 COD_EMISORA = 001.

ROLES  SEDES 2 Y 3. ROL: EMISORA


 COD_EMISORA = 002 y 003

-8

4
SOLUCIÓN: ANÁLISIS DE LOS
DATOS

 Identificación de requisitos de distribución


 Operaciones mayoritariamente sobre datos locales.
 Una sede accede a determinados atributos de Locutor para gestión de
escuela de doblaje .
 Datos de Emisora poco dinámicos (baja actualización) y escasos.

 Asignación inicial
 Fragmentos de cada relación en todas las sedes, conteniendo sólo
datos locales.
 Relación Emisora completa en todas las sedes
 Atributos de Empleado sólo accedidos en la sucursal 001:
TONO_VOZ, TIMBRE_VOZ, HORAS_SEMANALES

-9

SOLUCIÓN:
FRAGMENTACIÓN (I)
 Criterio de fragmentación: independencia local de cada
emisora con respecto a sus datos.

 RELACIÓN EMISORA: no se fragmenta

 RELACIÓN LOCUTOR: vertical y horizontal

LOCUTOR_ESCUELA=Пcod_locutor, tonovoz, timbrevoz, horas_semana (LOCUTOR)

LOCUTOR_EMISORA=Пcod_locutor, cod_emisora, nombre, dni, telefono(LOCUTOR)

LOCUTOR_EMISORA_i = σ cod_emisora = ‘i’ LOCUTOR_EMISORA


donde i = {001,002,003}

- 10

5
SOLUCIÓN:
FRAGMENTACIÓN (y II)
 RELACIÓN PROGRAMA: horizontal primaria
PROGRAMA_i = σ cod_emisora = ‘i’ PROGRAMA

donde i = {001,002,003}

 RELACIÓN TIENE_ANUNCIANTE: horizontal derivada


TIENE_ANUNCIANTE_i = TIENE_ANUNCIANTE PROGRAMA_i
cod_programa
donde i = {001,002,003}

 RELACIÓN ANUNCIANTE: horizontal derivada


ANUNCIANTE_i = ANUNCIANTE TIENE_ANUNCIANTE_i
CIF
donde i = {001,002,003}

- 11

SOLUCIÓN:
FRAGMENTACIÓN (y III)

RELACIÓN PROGRAMA RELACIÓN TIENE_ANUNCIANTE RELACIÓN ANUNCIANTE

Cod_Pro …… Cod_Em Cod_Pro CIF CIF ……….


A …… 001 A J J …..
B …… 001 A K K …..
C …… 002 B J L …..
D …… 002 C L M …..
E …… 003 C M N …
D M
E N

- 12

6
SOLUCIÓN: ESQUEMA DE
ASIGNACIÓN

EMISORA 001 EMISORA 002 EMISORA 003

LOCUTOR_ESCUELA LOCUTOR_ESCUELA

LOCUTOR_EMISORA LOCUTOR_EMISORA_001 LOCUTOR_EMISORA_002 LOCUTOR_EMISORA_003

EMISORA EMISORA

PROGRAMA PROGRAMA_001 PROGRAMA_002 PROGRAMA_003

ANUNCIANTE ANUNCIANTE_001 ANUNCIANTE_002 ANUNCIANTE_003

TIENE_ANUNCIANTE TIENE_ANUNCIANTE_001 TIENE_ANUNCIANTE_002 TIENE_ANUNCIANTE_003

- 13

SOLUCIÓN: REPLICACIÓN (I)


 Análisis de la conveniencia de replicación.
 Relaciones LOCUTOR_EMISORA y, LOCUTOR_ESCUELA :
algunas actualizaciones.
 Relación EMISORA: pocos datos y pocas actualizaciones.
 Relación ANUNCIANTE: algunas modificaciones.
 Relación TIENE_ANUNCIANTE: la relación sufre algunas
actualizaciones.
 En general: datos poco críticos

 El Administrador de la BD toma la decisión de replicar las


relaciones/fragmentos con baja necesidad de actualización

- 14

7
SOLUCIÓN: ESQUEMA DE
REPLICACIÓN
EMISORA 001 EMISORA 002 EMISORA 003

LOCUTOR_ESCUELA LOCUTOR_ESCUELA

LOCUTOR_EMISORA LOCUTOR_EMISORA_001 LOCUTOR_EMISORA_002 LOCUTOR_EMISORA_003

EMISORA EMISORA R_EMISORA R_EMISORA

PROGRAMA PROGRAMA_001 PROGRAMA_002 PROGRAMA_003

ANUNCIANTE ANUNCIANTE_001 ANUNCIANTE_002 ANUNCIANTE_003

TIENE_ANUNCIANTE TIENE_ANUNCIANTE_001 TIENE_ANUNCIANTE_002 TIENE_ANUNCIANTE_003

- 15

SUPUESTOS PRÁCTICOS (2)

 DISEÑ
DISEÑO DE UNA BASE DE DATOS
DISTRIBUIDA:

REPARACIONES MARTÍ
MARTÍNEZ Y ASOCIADOS, S. L.

- 16

8
SUPUESTO PRÁCTICO –
ENUNCIADO (I)
 La empresa Reparaciones Martínez y Asociados, S. L. (Repamar S.L.)
desea diseñar e implementar una base de datos distribuida para gestionar
el personal que tiene empleado, los datos de clientes, y la información
sobre los automóviles que repara en cada una de sus franquicias. Los
datos de las diferentes franquicias estarán almacenados en cuatro
localidades dependiendo de la ciudad en la que esté ubicada la misma.

 Las localidades de almacenamiento serán: Valladolid (para franquicias


de Valladolid y Palencia), Burgos (para talleres de Burgos y Soria),
Zamora (para talleres de Zamora y Salamanca) y Segovia (para
franquicias de Segovia y Ávila).

B S
V Z
- 17

SUPUESTO PRÁCTICO –
ENUNCIADO (II)
 La siguiente lista de especificaciones describe los principales requisitos de
funcionamiento de Repamar S.L.:
 Cada franquicia o taller está ubicado en una localidad, se identifica con un

código único, tiene un nombre y un director que es empleado del taller.


 El personal contratado por la empresa se identifica mediante un código de

empleado que mantendrán mientras trabajen en dicha empresa


independientemente del taller al que estén asignados. La Administración
almacena para cada empleado el DNI, el nombre, el número de teléfono, la
fecha de comienzo de contrato, el salario y la franquicia en la que trabaja.
Cada empleado sólo puede estar asignado a un taller.

- 18

9
SUPUESTO PRÁCTICO –
ENUNCIADO (III)
 Los talleres trabajan con sólo dos tipos de vehículos: utilitarios o todo
terrenos. Los vehículos que pasan por taller pueden asociarse a más de un
cliente y un cliente puede tener más de un vehículo. Cada vehículo se
identifica por un número de matrícula. La empresa mantiene para cada
vehículo la fecha de compra, las fechas en las que el vehículo fue llevado a
reparar, el tipo de reparación, las observaciones y el precio de la reparación.
Así pues, cada reparación es única para un determinado vehículo. Además,
para cada vehículo utilitario se almacena el número de puertas, mientras que
para cada todo terreno se guarda el número de defensas.

 Considérese también que cuando el cliente lleva a reparar a un taller un


nuevo vehículo y éste se da de alta en la Base de Datos, se vincula el
automóvil a dicho taller de la red de franquicias. Esto no impide que el
cliente pueda llevar después su vehículo a reparar a otros talleres, sin
embargo ya no es relevante almacenar en qué taller se llevan a cabo
sucesivas reparaciones.

- 19

SUPUESTO PRÁCTICO –
ENUNCIADO (IV)
 Los clientes de Repamar S.L. se identifican mediante un código de cliente.
La empresa almacena para cada cliente el DNI, el nombre, la ciudad donde
reside y los números de matrícula de los vehículos que posee.

 Además, en las franquicias de Valladolid se elaboran estudios estadísticos


acerca de la movilidad de los empleados de la empresa, para lo cual
necesitan sus datos de fecha de inicio de contrato y de salario.

- 20

10
SUPUESTO PRÁCTICO –
ENUNCIADO (y V)
 Se pide:
 Realizar el diseño centralizado puro de la BD
 Producto generado: Esquema E/R
 Identificar los sitios de distribución (SEDES) y sus respectivos roles
 Producto generado: Tabla de sedes y roles
 Analizar qué distribuir (identificación accesos frecuentes, etc)
 Producto generado: Resumen del análisis
 Fragmentación
 Producto generado: Esquema de fragmentación
 Asignación de fragmentos a los sitios
 Producto generado: Esquema de asignación
 Replicación
 Producto generado: Esquema de replicación

 Justificar las decisiones tomadas en cada paso


- 21

SOLUCIÓN: MODELO LÓGICO

- 22

11
SOLUCIÓN: IDENTIFICACIÓN
DE SEDES

 4 SEDES ALMACENAMIENTO:

VALLADOLID BURGOS ZAMORA SEGOVIA


VALLADOLID Y PALENCIA BURGOS Y SORIA ZAMORA Y SALAMANCA SEGOVIA Y ÁVILA

 SEDE 1: CENTRAL. ROLES: ESTADÍSTICAS y SEDE


 VALLADOLID: sede de franquicia y gestión estadística.

ROLES  SEDES 2, 3 Y 4. ROL: SEDE


 BURGOS, ZAMORA y SEGOVIA: sedes de franquicia.

- 23

SOLUCIÓN: ANÁLISIS DE LOS


DATOS

 Identificación de requisitos de distribución


 Operaciones mayoritariamente sobre datos locales.
 Una sede accede a determinados atributos de Empleado para estudio
estadístico.
 Principalmente, actualizaciones de Reparaciones y consultas en el
resto de relaciones.
 Asignación inicial
 Fragmentos de cada relación en todas las sedes, conteniendo sólo
datos locales.
 Atributos de Empleado sólo accedidos en la sede de Valladolid:
FECHA_INICIO, SALARIO

- 24

12
SOLUCIÓN:
FRAGMENTACIÓN (I)
 Criterio de fragmentación: ubicación cercana de
los datos respecto a donde son consultados.
 FRAGMENTACIÓN:
 RELACIÓN TALLER: horizontal
TALLER_i = σ localidad = ‘i’ (TALLER), donde i = {V,B,Z,S}

 RELACIÓN EMPLEADO: vertical y horizontal derivada

EMPLEADO_SEDE=Пcod_empleado, cod_taller, nombre, dni, telefono(EMPLEADO)


EMPLEADO_ESTADISTICAS=Пcod_empleado, fecha_inicio, salario (EMPLEADO)
EMPLEADO_SEDE_i = EMPLEADO_SEDE TALLER_i
cod_taller
donde i = {V,B,Z,S}

- 25

SOLUCIÓN:
FRAGMENTACIÓN (II)
 RELACIÓN VEHICULO: horizontal derivada
VEHICULO_i = VEHICULO TALLER_i
cod_taller
donde i = {V,B,Z,S}
 RELACIÓN REPARACION: horizontal derivada
REPARACION_i = REPARACION VEHICULO_i
num_matricula

donde i = {V,B,Z,S}

 RELACIÓN POSEE_VEHICULO: horizontal derivada


POSEE_VEHICULO_i = POSEE_VEHICULO VEHICULO_i
num_matricula

donde i = {V,B,Z,S}
 RELACIÓN CLIENTE: horizontal derivada
CLIENTE_i = CLIENTE POSEE_VEHICULO_i
cod_cliente

donde i = {V,B,Z,S}

- 26

13
SOLUCIÓN: REPLICACIÓN (I)
 Análisis de la conveniencia de replicación.
 Relaciones EMP_SEDE, EMP_ESTADISTISCAS y TALLER: pocas
actualizaciones.
 Relación CLIENTE: baja frecuencia de modificaciones.
 Relación POSEE_VEHICULO: la relación sufre pocas
actualizaciones.
 Relación VEHICULO: actualización baja.
 Relación REPARACION: muy susceptible de modificación.
Criticidad de sus datos. Alta disponibilidad.

 Decisión de réplica de los fragmentos con baja necesidad de


actualización y de los que se tiene alto requerimiento de
disponibilidad.

- 27

SOLUCIÓN: REPLICACIÓN (II)


• Ejemplo de esquema de replicación en la sede Valladolid:
VALLADOLID

RELACIÓN FRAGMENTOS RÉPLICAS


ORIGINALES

TALLER TALLER_V R_TALLER_B R_TALLER_Z R_TALLER_S

EMP_ESTADISTICAS EMP_ESTADISTICAS - - -

EMP_SEDE EMP_SEDE_V R_EMP_SEDE_B R_EMP_SEDE_Z R_EMP_SEDE_S

VEHICULO VEHICULO_V R_VEHICULO_B R_VEHICULO_Z R_VEHICULO_S

REPARACION REPARACION_V R_REPARACION R_REPARACION R_REPARACION

POSEE_VEHICULO POSEE_VEHICULO_V R_ POSEE_VEHICULO_B R_ POSEE_VEHICULO_Z R_ POSEE_VEHICULO_S

CLIENTE CLIENTE_V R_CLIENTE_B R_CLIENTE_Z R_CLIENTE_S

- 28

14

Das könnte Ihnen auch gefallen