Procesamiento de consultas

capas
1. Interfaces. Es la capa que recibe las peticiones de las aplicaciones, estas
peticiones pueden ser mediante SQL o SQL embebido.
2. Control. En esta capa se verifican las restricciones de integridad y
autorizaciones de acceso a los datos.
3. Compilación. Aquí se descomponen las consultas para generar secuencias
de operaciones algebraicas optimizadas.
4. Ejecución. Se interpretan y ejecutan las operaciones, incluyendo el control
de transacciones, es decir los commits y rollback.
5. Acceso a los datos. Maneja la estructuras de datos que implementan las
relaciones, acceso a archivos, uso de índices y de buffers para la optimización
del acceso a disco.
6. Consistencia. Se encarga del control de concurrencia, registro de eventos y
errores y permite la recuperación de las datos en caso de fallas.
In particular, the relations
involved in a distributed query
may be
and/or
, thereby inducing
.
The
of a
Map a high-level query on a
distributed database into a
sequence of database operators
(of
) on
relation fragments.
Consulta en dos niveles:
(i) Plantear la estrategia de ejecución
(ii) Ejecutar la consulta.
La estrategia de ejecución debe ser:
, es decir que produzca el mismo resultado
que la consulta de alto nivel.
, Se debe seleccionar la estrategia correcta
que minimiza el consumo de recursos.
*En un ambiente distribuido se deben involucrar aspectos
asociados a los recursos de comunicación, principalmente se
debe seleccionar donde se ejecutará la consulta.
of a distributed query processor
1. Descomposición de las consultas en
operaciones algebraicas.
2. Localización de los datos (fragmentos) para la
realización de las operaciones.
3. Comunicación de los fragmentos.
4. Optimización de las consultas con relación a
la función de optimización de recursos,
típicamente incluye, accesos a disco,
procesamiento y redes de comunicación.
A query may have
into
relational algebra.
Since each equivalent execution strategy
can lead to very different consumptions
of computer resources,
consumption.
“Find the names of employees who
are managing a project”
EMP(ENO, ENAME, TITLE)
ASG(ENO, PNO, RESP, DUR)
SELECT ENAME
FROM EMP, ASG
WHERE EMP.ENO = ASG.ENO
AND RESP = ‘‘Manager’’
ΠENAME(𝜎RESP= “Manager” ^ EMP.ENO=ASG.ENO (EMP X ASG))
ΠENAME(EMP ⋈ENO (𝜎 RESP=“Manager” (ASG)))
EMP1 = 𝜎ENO“E3” (EMP)
EMP2 = 𝜎ENO>“E3”(EMP)
ASG1 = 𝜎ENO“E3”(ASG)
ASG2 = 𝜎ENO>“E3”(ASG)
Fragments ASG1, ASG2, EMP1, and EMP2
are stored at sites 1, 2, 3, and 4,
respectively, and the result is expected at
site 5.
We assume that a tuple
access, denoted by
,
is 1 unit and a tuple transfer,
denoted
, is 10
units.
• We assume that relations EMP
and ASG have 400 and 1000
tuples, respectively, and that
there are 20 managers in relation
ASG.
• We also assume that data is
uniformly distributed among
sites.
• Selección y proyección - O(n)
• Join y semijoin - O(n*log n)
• Producto cartesiano - O(n2)