A Proxy Service for Multi-tenant Elastic Extension Tables - Transactions on Large-Scale-Data-and Knowledge-Centered Systems XX - page 8

Two tables by using the union operator that combines the result-set of these tables
whether they are CTTs or VETs.

￿

Two or more tables that have relationships between them, by using lters on

￿

multiple tables, or ltering data based on the results of subqueries.

Moreover, EETPS functions have the capabilities of retrieving data from CTTs or VETs
by using the following query options: Logical Operators, Arithmetic operators,
Aggregate Functions, Mathematical functions, Using Single or Composite Primary
Keys, Specifying Query SELECT clauses, Specifying Query WHERE Clause, Speci-
fying Query Limit, and Retrieving BLOB and CLOB Values. The overview architecture
of the service is shown in Fig. 2 . This architecture shows the four main layers of EETPS
architecture, including the Presentation Layer, the Application Programming Interface
(API) layer, the Service Layer, and the Domain Layer. The Presentation Layer repre-
sents the applications that access EET database through EETPS such as SaaS, mobile,
web, and stand-alone applications. The API Layer is the EET Data Retrieval API. The
Service Layer consists of EETPS, and nally, the Domain Layer is EET that consists of

three types of tables CTT, ET, and VET. The Presentation Layer allows the tenants to
retrieve data by calling functions from EETPS through the API Layer, and passing
parameters to these functions. When invoked, EETPS function generates a tenant query
from CTTs and/or VETs by using the ET and a number of query options, and then
executes the query in a RDBMS. The RDBMS returns the retrieved table rows from
EET and passes these rows back to EETPS to store them in an array. Finally, EETPS
returns the tenant s requested data in an array to the tenant through the API Layer.

Using this service on top of EET multi-tenant database schema gives the service
provider tenants a choice of the following three database models (Fig. 4 ):

'

￿ Multi-tenant relational database. This database model allows tenants to use a
standard relational database schema for a particular business domain database
without the need to extend the existing database structures. This business domain
database can be shared between multiple tenants and differentiate between them by
using a Tenant ID column in the physical tables. This model can be applied to any
business domain database.

Integrated multi-tenant relational database with virtual relational database.
This database model allows tenants to use a standard relational database schema or
a particular business domain, extend it by adding additional virtual database tables,
and combine these tables with the existing database structure by creating virtual
relationships between them.

￿

￿ Multi-tenant virtual relational database. This database model allows tenants to
use their own con gurable database through creating their virtual database schema

from the scratch, by creating virtual database tables, virtual database relationships,
and other database constraints to satisfy the requirements of

their business

applications.

For example, if a service provider offers a Sales database schema to be used by multiple
tenants, and on top of this database schema the service provider uses EETPS, then this
service provider is able to use the three database models listed above that ful ll various