Upload
ali-jamil
View
643
Download
4
Embed Size (px)
Citation preview
Distributed DBMS Architecture
Ali Samad
Tahir Rashid DDBMS Architecture 2
Defines the structure of the system– Defines the structure of the system– components identified– functions of each component defined– interrelationships and interactions between
components defined
Architecture
Ali Samad
Tahir Rashid DDBMS Architecture 3
Architecture
• Goal:– present the issues that need to be addressed at
design
– present a framework within which the design and implementation issues can be discussed
• The ISO/OSI 7-layered reference model for computer networks
Ali Samad
Tahir Rashid DDBMS Architecture 4
Reference Model– A conceptual framework whose purpose is to divide
standardization work into manageable pieces and to show at a general level how these pieces are related to one another.
A reference model can be described according to three different approaches:
• Based on components• Based on functions• Based on data
Standardization
Ali Samad
Tahir Rashid DDBMS Architecture 5
DBMS STANDARDIZATION
• Based on components.The components of the system are defined together with the interrelationships between components. A DBMS consists of a number of components, each of which provides some functionality.
• Based on functions.The different classes of users are identified and the functions that the system will perform for each class are defined. The system specifications within this category typically specify a hierarchical structure for the user classes. The ISO/OSI architecture fall in this category.
Ali Samad
Tahir Rashid DDBMS Architecture 6
DBMS STANDARDIZATION
• Based on data.The different types of data are identified, and an architectural framework is specified which defines the functional units that will realize or use data according to these different views. This approach (also referred as the data logical approach) is claimed to be the preferable choice for standardization activities.
Ali Samad
Tahir Rashid DDBMS Architecture 7
DBMS STANDARDIZATIONANSI / SPARC ARCHITECTURE
The ANSI / SPARC architecture is claimed to be based on the data organization. It recognizes three views of data:
the external view, which is that of the user, who might be a programmer; the internal view, that of the system or machine; and the conceptual view, that of the enterprise.
For each of these views, an appropriate schema definition is required.
Ali Samad
Tahir Rashid DDBMS Architecture 8
DBMS STANDARDIZATIONANSI / SPARC ARCHITECTURE
Ali Samad
Tahir Rashid DDBMS Architecture 9
DBMS STANDARDIZATIONANSI / SPARC ARCHITECTURE
• At the lowest level of the architecture is the internal view, which deals with the physical definition and organization of data.
• At the other extreme is the external view, which is concerned with how users view the database.
• Between these two ends is the conceptual schema, which is an abstract definition of the database. It is the „real world” view of the enterprise being modeled in the database.
Ali Samad
Tahir Rashid DDBMS Architecture 10
RELATION EMP [KEY = {ENO}
ATTRIBUTES = {ENO : CHARACTER(9)
ENAME : CHARACTER(15)
TITLE : CHARACTER(10)
}
]
RELATION PAY [KEY = {TITLE}
ATTRIBUTES = {TITLE : CHARACTER(10)
SAL : NUMERIC(6)
}
]
Conceptual Schema Definition
Ali Samad
Tahir Rashid DDBMS Architecture 11
RELATION PROJ [KEY = {PNO}
ATTRIBUTES = {PNO : CHARACTER(7)
PNAME : CHARACTER(20)
BUDGET : NUMERIC(7)
}
]
RELATION ASG [KEY = {ENO,PNO}
ATTRIBUTES = {ENO : CHARACTER(9)
PNO : CHARACTER(7)
RESP : CHARACTER(10)
DUR : NUMERIC(3)
}
]
Conceptual Schema Definition
Ali Samad
Tahir Rashid DDBMS Architecture 12
RELATION EMP [KEY = {ENO}ATTRIBUTES = {
ENO : CHARACTER(9)ENAME : CHARACTER(15)TITLE : CHARACTER(10)
}
]
INTERNAL_REL EMPL [
INDEX ON E# CALL EMINXFIELD = {
HEADER : BYTE(1)E# : BYTE(9)ENAME : BYTE(15)TIT : BYTE(10)
}
]
Internal Schema Definition
Ali Samad
Tahir Rashid DDBMS Architecture 13
Create a BUDGET view from the PROJ relation
CREATE VIEW BUDGET(PNAME, BUD)
AS SELECT PNAME, BUDGET
FROM PROJ
External View Definition – Example 1
Ali Samad
Tahir Rashid DDBMS Architecture 14
Create a Payroll view from relations EMP and TITLE_SALARY
CREATE VIEW PAYROLL (ENO, ENAME, SAL)
AS SELECT EMP.ENO,EMP.ENAME,PAY.SAL FROM EMP, PAY
WHERE EMP.TITLE = PAY.TITLE
External View Definition – Example 2
Ali Samad
Tahir Rashid DDBMS Architecture 15
DBMS STANDARDIZATIONANSI / SPARC ARCHITECTURE
Ali Samad
Tahir Rashid DDBMS Architecture 16
DBMS STANDARDIZATIONANSI / SPARC ARCHITECTURE
• The square boxes represent processing functions, whereas the hexagons are administrative roles.
• The arrows indicate data, command, program, and description flow, whereas the „I”-shaped bars on them represent interfaces.
• The major component that permits mapping between different data organizational views is the data dictionary / directory (depicted as a triangle), which is a meta-database.
• The database administrator is responsible for defining the internal schema definition.
• The enterprise administrator’s role is to prepare the conceptual schema definition.
• The application administrator is responsible for preparing the external schema for applications.Ali Samad
Tahir Rashid DDBMS Architecture 17
• Two more users:– Application programmer– System programmer
• Two user classes:– Casual user
• Retrieve database and possible update• Added in external schema
– Novice user• Typically have no knowledge of data base• Example (banking machine)
DBMS STANDARDIZATIONANSI / SPARC ARCHITECTURE
Ali Samad
Tahir Rashid DDBMS Architecture 18
ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs
The systems are characterized with respect to:
(1) the autonomy of the local systems,
(2) their distribution,
(3) their heterogeneity.Ali Samad
Tahir Rashid DDBMS Architecture 19
Architectural models for Distributed DBMSs
Ali Samad
Tahir Rashid DDBMS Architecture 20
Autonomy
• Distribution of control (and not data) - the degree of
independence– The local operations of the individual DBMSs are not
affected by their participation in the multidatabase system
– The manner in which individual DBMSs process queries and optimize them should not be affected by the execution of global queries
– System consistency should not be compromised when
individual DBMSs join or leave the multidatabase system
Ali Samad
Tahir Rashid DDBMS Architecture 21
Autonomy
• On the other hand specifies the dimension of autonomy as:
• Design autonomy: Ability of a component DBMS to decide on issues related to its own design.
• Communication autonomy: Ability of a component DBMS to decide whether and how to communicate with other DBMSs.
• Execution autonomy: Ability of a component DBMS to execute local operations in any manner it wants to.
Ali Samad
Tahir Rashid DDBMS Architecture 22
Autonomy
• Possibilities:– Tight integration – a single-image of the entire
database is available to any user who wants to share the information, which may reside in multiple databases.
– Semiautonomous system – consist of DBMSs that can operate independently, but have decided to participate in a federation to make their local data sharable.
– Total isolation – the individual systems are stand-alone DBMSs, which know neither of the existence of other DBMSs nor how to communicate with them.
Ali Samad
Tahir Rashid DDBMS Architecture 23
ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs - DISTRIBUTION
Distributions refers to the distributions of data. Of course, we are considering the physical distribution of data over multiple sites; the user sees the data as one logical pool.
Two alternatives:– client / server distribution– peer-to-peer distribution (full distribution)
Ali Samad
Tahir Rashid DDBMS Architecture 24
ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs - DISTRIBUTION
Client / server distribution.The client / server distribution concentrates data management duties at servers while the clients focus on providing the application environment including the user interface. The communication duties are shared between the client machines and servers. Client / server DBMSs represent the first attempt at distributing functionality.
Peer-to-peer distribution.There is no distinction of client machines versus servers. Each machine has full DBMS functionality and can communicate with other machines to execute queries and transactions.
Ali Samad
Tahir Rashid DDBMS Architecture 25
ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs - DISTRIBUTION
Client / server distribution.The client / server distribution concentrates data management duties at servers while the clients focus on providing the application environment including the user interface. The communication duties are shared between the client machines and servers. Client / server DBMSs represent the first attempt at distributing functionality.
Peer-to-peer distribution.There is no distinction of client machines versus servers. Each machine has full DBMS functionality and can communicate with other machines to execute queries and transactions.
Ali Samad
Tahir Rashid DDBMS Architecture 26
ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs - HETEROGENEITY
Heterogeneity may occur in various forms in distributed systems, ranging form hardware heterogeneity and differences in networking protocols to variations in data managers.
Representing data with different modeling tools creates heterogeneity because of the inherent expressive powers and limitations of individual data models. Heterogeneity in query languages not only involves the use of completely different data access paradigms in different data models, but also covers differences in languages even when the individual systems use the same data model.
Ali Samad
Tahir Rashid DDBMS Architecture 27
• Various levels (hardware, communications, operating system)
• DBMS important one – data model, query language, transaction management algorithms
• Representing data with different modeling tools creates heterogeneity because of the inherent expressive power and limitations of individual data models.
ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs -
HETEROGENEITY
Ali Samad
Tahir Rashid DDBMS Architecture 28
ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs - ALTERNATIVES
The dimensions are identified as: A (autonomy), D (distribution) and H (heterogeneity).
The alternatives along each dimension are identified by numbers as: 0, 1 or 2.
Ali Samad
Tahir Rashid DDBMS Architecture 29
A0 - tight integrationA1 - semiautonomous systemsA2 - total isolation
H0 - homogeneous systemsH1 - heterogeneous systems
D0 - no distributionD1 - client / server systemsD2 - peer-to-peer systems
ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs - ALTERNATIVES
Ali Samad
Tahir Rashid DDBMS Architecture 30
ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs
Ali Samad
Tahir Rashid DDBMS Architecture 31
Alternatives in Distributed Database Systems
Distribution
Heterogeneity
Autonomy
Client/server
Peer-to-peerDistributed DBMS
Federated DBMS
Distributedmulti-DBMS
Multi-DBMS
Ali Samad
Tahir Rashid DDBMS Architecture 32
• In figure 4.3 , two alternative architectures that are focus of this book:
• (A0, D2, H0)
• (A2, D2, H1)
• Not all the architectures that are identified by this design space are meaningful.
ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs - ALTERNATIVES
Ali Samad
Tahir Rashid DDBMS Architecture 33
ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs - ALTERNATIVES
(A0, D0, H0)If there is no distribution or heterogeneity, the system is a set of multiple DBMSs that are logically integrated. Such systems can be given generic name composite systems. Not such examples but they may be suitable for shared everything multiprocessor systems.
(A0, D0, H1)
If heterogeneity is introduced, one has multiple data managers that are heterogeneous but provide an integrated view to the user.
(A0, D1, H0)
The more interesting case is where the database is distributed even though an integrated view of the data is provided to users (client / server distribution). Mentioned earlier and will discuss further.
Ali Samad
Tahir Rashid DDBMS Architecture 34
ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs - ALTERNATIVES
(A0, D2, H0)
The same type of transparency is provided to the user in a fully distributed environment. There is no distinction among clients and servers, each site providing identical functionality.
(A1, D0, H0)
These are semiautonomous systems, which are commonly termed federated DBMS. The component systems in a federated environment have significant autonomy in their execution, but their participation in the federation indicate that they are willing to cooperate with other in executing user requests that access multiple databases. An example may be multiple installations of an DBMS.
Ali Samad
Tahir Rashid DDBMS Architecture 35
ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs - ALTERNATIVES
(A1, D0, H1)
These are systems that introduce heterogeneity as well as autonomy, what we might call a heterogeneous federated DBMS.
(A1, D1, H1)
System of this type introduce distribution by placing component systems on different machines. They may be referred to as distributed, heterogeneous federated DBMS.
(A2, D0, H0)
Now we have full autonomy. These are multidatabase systems (MDBS). The components have no concept of cooperation. Without heterogeneity and distribution, an MDBS is an interconnected collection of autonomous databases.
Ali Samad
Tahir Rashid DDBMS Architecture 36
ARCHITECTURAL MODELS FOR DISTRIBUTED DBMSs - ALTERNATIVES
(A2, D0, H1)
These case is realistic, maybe even more so than (A1, D0, H1), in that we always want to built applications which access data from multiple storage systems with different characteristics.
(A2, D1, H1) and (A2, D2, H1)
These two cases are together, because of the similarity of the problem. They both represent the case where component databases that make up the MDBS are distributed over a number of sites - we call this the distributed MDBS.
Ali Samad
Tahir Rashid DDBMS Architecture 37
Data logical Distributed DBMS Architecture
...
...
...
ES1 ES2 ESn
GCS
LCS1 LCS2 LCSn
LIS1 LIS2 LISn
ES: External Schema
GCS: Global Conceptual Schema
LCS: Local Conceptual Schema
LIS: Local Internal Schema
Ali Samad
Tahir Rashid DDBMS Architecture 38
Datalogical Multi-DBMS Architecture
...
GCS… …
GES1
LCS2 LCSn…
…LIS2 LISn
LES11 LES1n LESn1 LESnm
GES2 GESn
LIS1
LCS1
• GES: Global External Schema• LES: Local External Schema
• LCS: Local Conceptual Schema• LIS: Local Internal Schema
Ali Samad
Tahir Rashid DDBMS Architecture 39
Distributed DBMS• Distributed database requires distributed DBMS• Functions of a distributed DBMS:
– Locate data with a distributed data dictionary
– Determine location from which to retrieve data and process query components
– DBMS translation between nodes with different local DBMSs (using middleware)
– Data consistency (via multiphase commit protocols)
– Global primary key control
– Scalability
– Security, concurrency, query optimization, failure recovery
Ali Samad
Tahir Rashid DDBMS Architecture 40
Figure 13-10 – Distributed DBMS architecture
Ali Samad
Tahir Rashid DDBMS Architecture 41
Local Transaction Steps
1. Application makes request to distributed DBMS
2. Distributed DBMS checks distributed data repository for location of data. Finds that it is local
3. Distributed DBMS sends request to local DBMS
4. Local DBMS processes request5. Local DBMS sends results to application
Ali Samad
Tahir Rashid DDBMS Architecture 42
Figure 13-10: Distributed DBMS Architecture (cont.) (showing local transaction steps)
Local transaction – all data stored locally
1
3
4
5
2
Ali Samad
Tahir Rashid DDBMS Architecture 43
Global Transaction Steps1. Application makes request to distributed DBMS2. Distributed DBMS checks distributed data repository for location
of data. Finds that it is remote3. Distributed DBMS routes request to remote site4. Distributed DBMS at remote site translates request for its local
DBMS if necessary, and sends request to local DBMS5. Local DBMS at remote site processes request6. Local DBMS at remote site sends results to distributed DBMS at
remote site7. Remote distributed DBMS sends results back to originating site8. Distributed DBMS at originating site sends results to application
Ali Samad
Tahir Rashid DDBMS Architecture 44
Figure 13-10: Distributed DBMS architecture (cont.) (showing global transaction steps)
Global transaction – some data is at remote site(s)
1
2
4
5
6
3
7
8
Ali Samad
Tahir Rashid DDBMS Architecture 45
DISTRIBUTED DBMS ARCHITECTURE
• Client / server systems - (Ax, D1, Hy)
• Distributed databases - (A0, D2, H0)
• Multidatabase systems - (A2, Dx, Hy)
Ali Samad
The Client/Server Database Environment
Ali Samad
Tahir Rashid DDBMS Architecture 47
Client/Server Systems
• Networked computing model• Processes distributed between clients and
servers• Client – Workstation (usually a PC) that requests
and uses a service• Server – Computer (PC/mini/mainframe) that
provides a service• For DBMS, server is a database server
Ali Samad
Tahir Rashid DDBMS Architecture 48
Application Logic in C/S Systems
• Presentation Logic– Input – keyboard/mouse– Output – monitor/printer
• Processing Logic– I/O processing– Business rules– Data management
• Storage Logic– Data storage/retrieval
GUI Interface
Procedures, functions,programs
DBMS activities
Ali Samad
Tahir Rashid DDBMS Architecture 49
Client/Server Architectures
• File Server Architecture
• Database Server Architecture
• Three-tier Architecture
Ali Samad
Tahir Rashid DDBMS Architecture 50
File Server Architecture
• All processing is done at the PC that requested the data
• Entire files are transferred from the server to the client for processing.
• Problems:– Huge amount of data transfer on the network– Each client must contain full DBMS
• Heavy resource demand on clients• Client DBMSs must recognize shared locks, integrity checks,
etc.Ali Samad
Tahir Rashid DDBMS Architecture 51
File Server Architecture
Ali Samad
Tahir Rashid DDBMS Architecture 52
Database Server Architectures• 2-tiered approach• Client is responsible for
– I/O processing logic – Some business rules logic
• Server performs all data storage and access processing DBMS is only on server
• Advantages– Clients do not have to be as powerful– Greatly reduces data traffic on the network– Improved data integrity since it is all processed centrally– Stored procedures some business rules done on server
Ali Samad
Tahir Rashid DDBMS Architecture 53
Advantages of Stored Procedures
• Compiled SQL statements
• Reduced network traffic
• Improved security
• Improved data integrity
Ali Samad
Tahir Rashid DDBMS Architecture 54
Database server architecture
DBMS DBMS only on only on serverserver
Ali Samad
Tahir Rashid DDBMS Architecture 55
Three-Tier Architectures
• Three layers:– Client– Application server– Database server
Thin Client PC just for user interface and a little application
processing. Limited or no data storage (sometimes no hard drive)
GUI interface (I/O processing) Browser
Business rules Web Server
Data storage DBMS
Ali Samad
Tahir Rashid DDBMS Architecture 56
Three-tier architecture
Thinnest Thinnest clientsclients
Business rules on Business rules on separate serverseparate server
DBMS only DBMS only on DB serveron DB server
Ali Samad
Tahir Rashid DDBMS Architecture 57
DISTRIBUTED DBMS ARCHITECTURECLIENT / SERVER SYSTEMS
• This provides two-level architecture which make it easier to manage the complexity of modern DBMSs and the complexity of distribution.
• The server does most of the data management work (query processing and optimization, transaction management, storage management).
• The client is the application and the user interface (management the data that is cached to the client, management the transaction locks).
Ali Samad
Tahir Rashid DDBMS Architecture 58
DISTRIBUTED DBMS ARCHITECTURECLIENT / SERVER SYSTEMS
• This architecture is quite common in relational systems where the communication between the clients and the server(s) is at the level of SQL statements.
Ali Samad
Tahir Rashid DDBMS Architecture 59
DISTRIBUTED DBMS ARCHITECTURE
CLIENT / SERVER SYSTEMS
Ali Samad
Tahir Rashid DDBMS Architecture 60
DISTRIBUTED DBMS ARCHITECTURE
CLIENT / SERVER SYSTEMS
Multiple client - single server
From a data management perspective, this is not much different from centralized databases since the database is stored on only one machine (the server) which also hosts the software to manage it. However, there are some differences from centralized systems in the way transactions are executed and caches are managed.
Multiple client - multiple serverIn this case, two alternative management strategies are possible: either each client manages its own connection to the appropriate server or each client knows of only its “home server” which then communicates with other servers as required.
Ali Samad
Tahir Rashid DDBMS Architecture 61
Multiple Clients/Single Server
Communications
ClientServices
Applications
Communications
DBMS Services
LANHigh-levelrequests
Filtereddata only
Communications
ClientServices
Applications
Communications
ClientServices
Applications
Database
Ali Samad
Tahir Rashid DDBMS Architecture 62
Task Distribution
Application
Communications Manager
Communications Manager
Lock Manager
Storage Manager
Page & Cache Manager
Query Optimizer
QLInterface
ProgrammaticInterface…
SQLquery
resulttable
Database
Ali Samad
Tahir Rashid DDBMS Architecture 63
Advantages of Client-Server Architectures
• More efficient division of labor
• Better price/performance on client machines
• Ability to use familiar tools on client machines
• Client access to remote data (via standards)
• Full DBMS functionality provided to client workstations
• Overall better system price/performance
Ali Samad
Tahir Rashid DDBMS Architecture 64
Problems With Multiple-Client/Single Server
• Server forms bottleneck
• Server forms single point of failure
• Database scaling difficult
Ali Samad
Tahir Rashid DDBMS Architecture 65
Multiple Clients/Multiple Servers
Communications
ClientServices
Applications
LAN
• directory• caching• query decomposition• commit protocols
Communications
DBMS Services
Database
Communications
DBMS Services
Database
Ali Samad
Tahir Rashid DDBMS Architecture 66
Server-to-Server
Communications
DBMS Services
LAN
Communications
DBMS Services
• SQL interface• programmatic
interface• other application
support environments
Communications
ClientServices
Applications
Database Database
Ali Samad
Tahir Rashid DDBMS Architecture 67
DISTRIBUTED DBMS ARCHITECTURE
PEER-TO-PEER DISTRIBUTED SYSTEMS
• The physical data organization on each machine may be different.
• Local internal scheme (LIS) - is an individual internal schema definition at each site.
• Global conceptual schema (GCS) - describes the enterprise view of the data.
• Local conceptual schema (LCS) - describes the logical organization of data at each site.
• External schemas (ESs) - support user applications and user access to the database.
Ali Samad
Tahir Rashid DDBMS Architecture 68
DISTRIBUTED DBMS ARCHITECTURE
PEER-TO-PEER DISTRIBUTED SYSTEMS
Ali Samad
Tahir Rashid DDBMS Architecture 69
DISTRIBUTED DBMS ARCHITECTURE
PEER-TO-PEER DISTRIBUTED SYSTEMS
In these case, the ANSI/SPARC model is extended by the addition of global directory / dictionary (GD/D) to permits the required global mappings. The local mappings are still performed by local directory / dictionary (LD/D). The local database management components are integrated by means of global DBMS functions. Local conceptual schemas are mappings of global schema onto each site.
Ali Samad
Tahir Rashid DDBMS Architecture 70
DISTRIBUTED DBMS ARCHITECTUREPEER-TO-PEER DISTRIBUTED SYSTEMS
Ali Samad
Tahir Rashid DDBMS Architecture 71
DISTRIBUTED DBMS ARCHITECTURE
PEER-TO-PEER DISTRIBUTED SYSTEMS
The detailed components of a distributed DBMS.
Two major components:– user processor
– data processor
Ali Samad
Tahir Rashid DDBMS Architecture 72Ali Samad
Tahir Rashid DDBMS Architecture 73
DISTRIBUTED DBMS ARCHITECTURE
PEER-TO-PEER DISTRIBUTED SYSTEMS
User processor• user interface handler - is responsible for interpreting user
commands as they come in, and formatting the result data as it is sent to the user,
• semantic data controller - uses the integrity constraints and authorizations that are defined as part of the global conceptual schema to check if the user query can be processed,
• global query optimizer and decomposer - determines an execution strategy to minimize a cost function, and translates the global queries in local ones using the global and local conceptual schemas as well as global directory,
• distributed execution monitor - coordinates the distributed execution of the user request.
Ali Samad
Tahir Rashid DDBMS Architecture 74
DISTRIBUTED DBMS ARCHITECTURE
PEER-TO-PEER DISTRIBUTED SYSTEMSData processor• local query optimizer - is responsible for choosing the best
access path to access any data item,
• local recovery manager - is responsible for making sure that the local database remains consistent even when failures occur,
• run-time support processor - physically accesses the database according to the physical commands in the schedule generated by the query optimizer. This is the interface to the operating system and contains the database buffer (or cache) manager, which is responsible for maintaining the main memory buffers and managing the data accesses.
Ali Samad
Tahir Rashid DDBMS Architecture 75
Peer-to-PeerComponent Architecture
Database
DATA PROCESSORUSER PROCESSOR
USER
Userrequests
Systemresponses
ExternalSchema
User
Inte
rface
Han
dle
r
GlobalConceptual
Schema
Sem
an
tic D
ata
Con
troller
Glo
bal
Execu
tion
Mon
itor
SystemLog
Local R
ecovery
Man
ag
er
LocalInternalSchema
Ru
nti
me
Su
pp
ort
Pro
cessor
Local Q
uery
Pro
cessor
LocalConceptual
Schema
Glo
bal Q
uery
Op
tim
izer
GD/D
Ali Samad