Using MDE for Teaching Database Query Optimizer

Abdelkader Ouared

and Abdelhaﬁd Chadli

Ibn Khaldoun University (UIK), Tiaret, Algeria

Keywords:

Database Query Optimizer Learning, Using MDE in Teaching, Metamodeling, Domain-speciﬁc Language.

Abstract:

Query optimization is considered as an important part of Data Base Management Systems (DBMS) and plays

a major role in database research community (e.g. SQL, Spark, Map-reduce). Generally, this optimization is

done using Cost Base Optimization (CBO), which is difﬁcult to understand due to the complexity of platform,

database, query and DBMS. Moreover, database query optimizer is usually a very complex process, with

difﬁcult concepts depending on the behaviour of the query engine of DBMS. Therefore, users (e.g. novice

user, developer, DB administrator) have difﬁculties to understand and build a mental image of database query

optimizer in order to produce more efﬁcient queries. In this paper, we propose a Framework based on the

model-driven engineering (MDE) paradigm to facilitate understanding and improving query performance.

Indeed, MDE approach has been proven useful for developing new software applications, and its adoption

for a teaching perspective presents a major challenge. We illustrate our proposal with use case and proof-of-

concept prototype for the whole provided process.

1 INTRODUCTION

Generally speaking, the query optimizer is viewed

as the bottleneck of database application perfor-

mance. Recently several calls and demands have been

raised to make this design much easier, by teach-

ing DBMS architecture and query optimization pro-

cess (Scherzinger, 2019), (Pavlo et al., 2017). Query

Optimizer process is difﬁcult to understand since it

includes several parameters belonging to databases,

platforms, DBMS, queries, etc. Furthermore, in all

existing query optimizers, users are systematically out

of the process loop. To remedy this situation, a variety

of query optimizer (SQL, Map-reduce, etc.) might be

used or taught for different purposes such as including

users to interact with the optimizing process.

1.1 Problem Statement

As stated above, query optimizers are considered as

an important part of DBMS and plays a major role

in database research community (e.g. (Siddiqui and

Other, 2020; Gallinucci and Golfarelli, 2019)). This

component is one of the most important quality indi-

cators that companies are looking for to choose their

https://orcid.org/0000-0003-4257-0522

https://orcid.org/0000-0003-0559-1439

appropriate query process in DBMS, since they es-

timate metrics associated to non-functional require-

ments (e.g., query response time, Quality of service,

energy consumption). The DBMS must then design

an execution strategy or query plan to retrieve the

query results from the database ﬁles. A query has

many possible execution strategies, and the process

of choosing a suitable one to handle an SQL query

is known as Cost Based Optimization (CBO) (Jarke

and Koch, 1984). Generally, this optimization is

done using CBO, which is difﬁcult to understand due

to the complexity of platform, database, query and

DBMS. Moreover, Query Optimizers are usually seen

as black box systems, and depend on cardinality esti-

mates, plan properties, and specialized cost formulas

for each relational algebra operator in an execution

plan. Consequently, database users have difﬁculties

to build a mental image on query optimization process

and how to improve query performance. For example,

how to use a special hint (e.g. HASH) in a way to dic-

tate the optimizer a different retrieval path rather than

that one calculated by the optimizer (e.g. rewriting the

query differently so as to inﬂuence the default query

execution). Indeed, one of the most challenging as-

pects of teaching advanced database in undergraduate

computer programs is the query optimizer (Liu et al.,

2019). To address the lack of query performance un-

dergraduate course teaching, we present in this paper

Ouared, A. and Chadli, A.

Using MDE for Teaching Database Query Optimizer.

DOI: 10.5220/0010535105290536

In Proceedings of the 16th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2021), pages 529-536

ISBN: 978-989-758-508-1

529

an MDE-based framework to facilitate understanding

and improving query performance. We aim to answer

the following research question.

RQ: is it possible to build an MDE-based concep-

tual framework to help database users understand the

SQL Cost Based Optimizer process?

1.2 Paper Contributions

There has been a lot of work in the query optimiza-

tion ﬁeld. However, previous works have not focused

on facilitating the learning experience to be reward-

ing for students and professionals so that they bet-

ter understand how the system works. In this paper,

we focus on solving these difﬁculties by proposing

a framework for assisting users to analyze and bet-

ter cope with CBO difﬁculties on Relational DBMS.

We propose a framework called CF-CBO (Conceptual

Framework for teaching CBO). Our framework ex-

plicit Query Optimizer at a high level of abstraction

and provides students with CBO-processing men-

tal image to facilitate understanding and improving

query performance. We ﬁrst propose a domain spe-

ciﬁc language (DSL), called OptDSL dedicated to de-

scribe Database Query Optimizer. Second, we de-

scribe the methodology associated with our frame-

work to explain how the system works. Finally, we

illustrate our Tool Support.

1.3 Paper Outline

The paper is structured as follows. Section 2 presents

the background and discusses the related work. In

Section 3, we present our proposed approach. Section

4 highlights the implementation of our proposition.

Finally, Section 5 concludes this paper.

2 BACKGROUND

In order to make this research self-contained and

straightforward, this section introduces the notions of

Query Optimization for Database Systems.

2.1 Query Optimization Domain

Description

Let us deﬁne a query plan as a tree P = (O, E)

(see Figure 1 (b)), where the set of nodes O of the

tree P represents the operations (i.e. selection in

relational algebra), and the set of edges E denotes

the precedence between two operations. More pre-

cisely, a plan P

is a set of relational algebra oper-

ators (e.g., restriction, projection, join, scan, sort),

= {O

1 j

, . . . , O

n j

}. Each O

∈ P

is annotated

with a quadruplet O

= (Imp

, T

, C

, ProP

) in which

Imp

is the implementation algorithm for each phys-

ical query operator (e.g. Nested-loops-join algorithm

to implement a Join Operation) , T

is the set of asso-

ciated input database objects such as tables, indexes,

materialized views etc., C

is the set of options used

to execute the operation, like adding the buffer option,

and ProP

is the Programming Paradigm (Sequential,

MapReduce, etc.). Each directed edge e ∈ E is an or-

dered pair of vertices deﬁned as e = (i, j) and connects

the operation i to the operation j when the execution

of i directly precedes that of j. A global plan P

may

possibly aggregate several subplans SP

...SP

to be

executed on the database. Figure 1 shows the query

plan for TPC-H

query 9 depicted as a tree structure

based upon the logical operators in the query. Each

node is responsible for executing one SQL operator

in the query, like sort and aggregation.

The Query Optimizer converts (or rewrites) logi-

cal requests, expressed in SQL language, into phys-

ical plans in order to ﬁnd a good execution plan in

terms of execution costs. Hence, the Query Optimizer

uses two strategies (Rule-Based Optimization, Cost-

Based Optimization) to associate several candidate

execution plans with a given SQL query and chooses

the best one. The query optimizer (Jarke and Koch,

1984), uses the CBO approach by means of cost mod-

els (Manegold et al., 2002) to process the cost of each

operation in the query. For example, CBO strategy

can be used to estimate I/O and CPU costs of each

execution plan in order to choose the best cost by

making a calculation of the database statistics. The

Query Optimizer as three main components, namely,

the plan generator, the performance cost calculator

and the plan evaluator. Figure 2 shows the workﬂow

between these three parts. First, the plan generator

produces the candidate plans of a given query, then

performance cost calculator estimates the cost of each

operation in the query plan, and ﬁnally the plan eval-

uator returns the optimal query plan.

2.2 Motivating Example

Let us consider a real scenario, where a database

user wants to optimize an SQL query. A typi-

cal query optimizer relies on host hardware infor-

mation and database statistics (called metadata) to

ﬁnd the cheapest execution plan for an SQL state-

ment. In Figure 1,we depict an example taken from

the TPC-H benchmark schema to optimize the total

costs. First, the user can visualize the query plan

http://www.tpc.org/tpch/

MDI4SE 2021 - Special Session on Model-Driven Innovations for Software Engineering

530

Figure 1: Two query plans of TPC-H query 9.

Figure 2: The query optimizer components workﬂow.

by using for instance the EXPLAIN ANALYZE instruc-

tion, then he can rewrite the query by forcing the

optimizer through query hints (e.g. SET enable

hashjoin=off) to determine which physical rela-

tional operator should be used, he can also choose

the physical structure, like index, in order to im-

prove the cost. For example, we can see in Fig-

ure 1 (a,b) that when nested loop join has been re-

placed with the hash join and the full scan been re-

placed with the index scan, as consequence, the query

performance related to the CPU overhead and disk

I/O was improved (Execution Time decrease from:

3812,040 seconds ⇒ 64,610 seconds) (is 60x faster).

From these results, it is concluded that choosing of

hints, like join operation, and physical structure, like

index, has a signiﬁcant impact on the cost of queries

but not explained or justiﬁed.

2.3 Existing CBO Tools in Academic

and Industrial Areas

There is a long line of studies on cost based optimiz-

ers for database users (e.g. SQL/SparkSQL,Spark,

SQL-on-Hadoop engine, Map-reduce, Spark, Flink,

SQL) because it is considered as an important part of

DBMS and plays a major role in database research

community. From the industry and academia, there

has been much research on CBO problems, such as

the automatic selection of materialized views and in-

dexes selection (Agarawal and Others, 2000). In ad-

dition, most modern databases come with designer

tools, e.g., Tuning Wizard in Microsoft SQL Server

(Chaudhuri and Narasayya, 1998), Teradata’s Index

Wizard (Brown et al., 2009), and Oracle’s SQL Tun-

ing Adviser (Bhagat and Shukla, 2014). However,

these tools optimize query without proposing a men-

tal image of this process. By examining the database

design life cycle, we found that computer science ed-

ucation follows the traditional 3-phase design: con-

ceptual, logical and physical. However, a revue of

educational solutions for database design showed that

topics in educational domain include only database

design (e.g. (Keberle and Utkin, 2012; Al-Dmour,

2010)), relational algebra and SQL (e.g. by interact-

ing tools like QueryVis (Leventidis and Other, 2020),

concurrency control in DBMS (e.g. (Allenstein and

Others, 2008; Scherzinger, 2019)), Database Tun-

ing (Almeida and Others, 2019) and teaching DBMS

architecture (Sciore, 2007; Galaktionov and Cherni-

shev, 2019). Furthermore, we found in the litera-

ture a lot of work that is interested in CBO related

to SQL queries. For example, academic and indus-

trial database admin tools (Parinda, IndexStore, etc.)

use CBO by iterative invocations of cost evaluation

module, but users are keep out the loop of the optimiz-

ing process. These tools provide optimal performance

cost with less knowledge about how to optimize query

plans and no effort is made to teach CBO basic knowl-

edge to students, doctoral students and professionals.

Using MDE for Teaching Database Query Optimizer

531

3 OUR FRAMEWORK

This section is devoted to present the CF-CBO Con-

ceptual Framework for Cost Based Optimization. CF-

CBO is intended to move the Database Query Opti-

mizer process from depth complex details to a high

level of abstraction so as to facilitate the learning pro-

cess. We ﬁrst formalize relevant foundations of the

CF-CBO Framework using a DSL, called OptDSL,

dedicated to Query Optimizer domain. Then, we give

an overview of the framework workﬂow that explains

the whole provided process.

3.1 CF-CBO Overview

Since the paper contributions have led to the devel-

opment of the CF-CBO framework, we ﬁrst give an

overview of the capabilities that it provides. Our

Framework is based on MDE paradigm that focuses

on the use of models and model transformations to

raise the level of abstraction and automation in query

optimizer. CF-CBO offers the following services: (i)

Service 1: Visual plan construction of a given query

that is expressed in OptDSL. The goal of optimiza-

tion is to minimize the cost of a given SQL Query

by additional physical information for each relational

algebra operation. (ii) Service 2: Query Rewriting

from any query plan expressed by Service 1. The gen-

erated SQL code have to be compliant with DBMS.

(iii) Service 3: This service helps users to combine

their modiﬁcations to be included in a global query

plan. User interactions with OptDSL metamodel in-

stance (Add, Remove, etc.) and feedback are saved

in event logs and used later to provide users with hint

suggestions to help choosing different relational al-

gebra operations (e.g. Join Operator type) according

to algorithms implementation (e.g. NestedLoop-Join,

Hash-Join, etc.)

Figure 3: Overview of the CF-CBO Framework.

Figure 3 shows all these services and how they com-

municate with each other. Indeed, Service 1 is based

on the OptDSL language (presented in Section 3.2)),

it allows expressing the query plan as an instance

of the OptDSL metamodel. That will help to edit,

display, insert, and remove query operators under

the same formalism. In this case, Service 3 is re-

quired. That is, every user can use Service 3 not

only for visual query exploration, but also to obtain

a complete user documentation as metamodeling hi-

erarchy that deﬁnes the query optimizer components

and properties thanks to the syntax and semantics of

our OptDSL. The beneﬁt is that during the optimiz-

ing process, we assume that user understands OptDSL

language since it contains a set of concepts, which are

common usually in CBO. Another important point is

that user can generate a transformation script in SQL

once a draft version of a query plan is obtained, rather

than rewriting the query manually, to avoid statement

errors. Service 2 provides this transformation auto-

matically based on our OptDSL metamodel. The CF-

CBO framework is in charge of generating the source

code of the targeted DBMS (e.g. PostgreSQL). In the

following, we will focus on the cornerstone elements

of Service 1, Service 2 and Service 3.

3.2 Core Elements of CF-CBO

The OptDSL language is the core element of CF-

CBO, dedicated to CBO. An instance of the OptDSL

language can represent a user need, which consists in

understanding/improving a query performance. Users

can interact with an instance of the OptDSL language

to understand/improve a query performance. In this

case, the user has to specify the context of his sys-

tem (i.e. database instance, query and platform) on

which he needs help. By instantiating OptDSL lan-

guage, we can also get a detailed relational database

query plan. Hereafter, we focus on core elements

of OptDSL metamodel and their semantics. Figure

4 depicts elements that are dedicated to express the

optimizer and its characteristics at a high-level of

abstraction. The root element of the metamodel is

the QueryPlan class, each QueryPlan instance con-

sists of a Database class instance, a Query class in-

stance, a Platform class instance, an Optimization-

Structure class instance, a Hints class instance, an

Operation class instance and a CostModel class in-

stance. An instance of the Database class is com-

posed of conceptual entities and their attributes. In

addition, links between entities are also represented

via associations. We also represent several semantic

restrictions such as primary and foreign keys. An in-

stance of the Query class takes as input a set of con-

MDI4SE 2021 - Special Session on Model-Driven Innovations for Software Engineering

532

Figure 4: Excerpt of OptDSL Meta-Model: Core Entities.

cepts, which are used to perform a set of algebra op-

erations (join, union, etc.). Furthermore, query op-

timizer can use access method such as B-tree index

or in-memory access method. An instance of the Plat-

form class includes the deployment architecture of the

database such as distributed or parallel database sys-

tems, database clusters, or cloud environments. An

instance of Cost Model class is deﬁned as a function

and corresponds to a given metric of an elementary

query operation, it is composed of a metric (an in-

stance of Metric class), a context (an instance of Con-

text class) and a cost function (an instance of Cost-

Function class). Also, every instance of the Cost-

Model class has at least one cost type (for more de-

tails, refer to our previous work (Ouared et al., 2016)).

3.3 The CF-CBO Process

The proposed approach is a multi-step process that

primarily consists of 3 phases as depicted in Figure 3:

(1) Plan Exploration (2) Visual Query Construction,

and (3) Query Plan Rewrite. In the following, we de-

tail this process systematically.

3.3.1 Plan Exploration

Plan Exploration helps users to understand and ex-

plore a query plan by showing the query plan/sub-

plan, the order of operations, and used hints. This

assistance allows users browsing the knowledge of

CBO concepts (e.g. physical operations like scan,

sort, join...), identifying correctly the order of opera-

tions, and accessing SubQuery and Query Plan Meth-

ods. Furthermore, Plan exploration provides a com-

plete user documentation since the metamodeling hi-

erarchy deﬁnes all components of the query optimizer

and the properties of these components. Thanks to the

syntax and semantics of our Query Optimizer DSL,

our metamodel relies on concepts categorization that

will play a key role in the query optimizer’s process

learning (see Section 3.2)). One should use the inter-

face in order to express the query and visualize the

plan to be analyzed. One should use the interface in

order to express the query and visualize the plan to be

analyzed. Figure 5 shows an example of the Q9 query

plan (c.f. Section 2 see Figure 1)) with seven subplans

using DSL parser as shown in Figure 5.

3.3.2 Visual Query Construction

The presence of a design language that allows brows-

ing the query plans, enriching, editing, validating,

transforming them, etc. represents a valuable asset for

database users. Users can use our design tool to select

the required hints and to identify the required physical

conﬁguration parameters that reduce the query cost.

In addition, users are required to decide about choice

of different relational algebra operations depending

on their implementation algorithms. For example, use

of special hint (e.g. HASH JOIN), rewrite queries

(e.g. remove GROUP BY clause), add/remove physi-

cal structures (such as materialized views, indexes, or

a combination of these). In addition, users can display

and customize various internal performance parame-

Using MDE for Teaching Database Query Optimizer

533

Figure 5: Segmentation of query Q9 into Subplans.

ters like Shared SQL Pool, Redo Log Buffer and other

information needed in the query optimization.

3.3.3 Query Plan Rewrite

Every query plan instance is generated according to

OptDSL. For that, a set of structural rules have been

injected in the OptDSL. These rules are expressed as

OCL (Object Constraint Language) invariants. List-

ing 1 is an example of a structural rule. This ex-

ample means that all implementation type operations

and their programming paradigm, that are query plan

inputs, have to be referenced as OperationType in-

stances in the ProgrammingModelType instance of

the operation class.

Cl ass Oper a t i o n

se lf . Im p l e m e n t a t i o n . typ e -> i n c l u d e s A l l ( s el f .

EI m p l e m e n t a t i o n T y p e )

an d s e lf . Pr o g r a m m i n g M o d e l . typ e -> in c l u desA l l ( se l f

. E P r o g r a m m i n g M o d e l )

Listing 1: An OCL structural rule.

In order to transform any query plan that is expressed

in OptDSL language into PostgreSQL, we have devel-

oped a code generator based on MDE settings using

the model-to-text transformation, since our objective

is to obtain the query physical plan. The implemen-

tation relies on the utilization of Acceleo. Listing 2

shows the generated query plan of the example pre-

sented in Figure 1.

So rt ( c o st = 4 1 0 3 1 7 . 3 5 . . 4 1 0 3 17 . 3 7 r ow s = 6 w i dth

=2 5) ( act u a l ti m e =1 0 4 2 4 . 8 1 5 . . 1 0 4 2 4 . 8 1 6 r o ws

=4 lo o ps =1)

So rt K ey : l _ r e tur n f l ag , l _ l inest a t u s

So rt Me t h o d : q u i c k sor t Me m o ry : 2 5 kB

-> H a s h A g g r e g a t e ( c o st = 4 1 0 3 1 7 . 1 1 . . 4 1 0 3 1 7 .2 7

ro ws =6 wid t h =25 ) ( a ctu a l t im e

=1 0 4 2 4 . 7 6 9 . . 1 0 4 2 4 . 7 75 ro w s =4 l o op s =1)

Gr o up K ey : l_ r e t ur n f l ag , l _ l i n esta t u s

.. ..

Pl a n n i n g tim e : 0 .3 8 0 ms

Ex e c u t i o n t im e : 1 0 4 2 4 . 8 9 4 m s

(1 0 r o ws )

Listing 2: Example of Displaying Execution Plans.

4 PROOF OF CONCEPT

To stress our approach and to proof how it is use-

ful and helpful, this section is devoted to present

a global usage scenario of the CF-CBO framework.

CF-CBO has been implemented for academic require-

ments based on PostgreSQL

, mostly because it is

open source. To ease the understanding, we provide

the URL of a demonstration video of the CF-CBO

framework

. In this section, we describe the function-

alities of CF-CBO which is composed of two parts,

the backend which contains the DBMS and the fron-

tend part that is represented by the graphical user in-

terface. The component modules are listed below.

The CBO Learning support is divided into four

parts: (1) Database Schema Analysis, (2) Query

http://www.postgresql.org/

The demonstration video of CF-CBO is available at:

https://www.youtube.com/watch?v=OGn3mf4s2aQ

MDI4SE 2021 - Special Session on Model-Driven Innovations for Software Engineering

534

(a) Database Schema Analysis (b) Query Plan Analysis

Figure 6: CF-CBO main GUI and its component module panels (A).

(a) Query Plan Construction (b) Results-Reports

Figure 7: CF-CBO main GUI and its component module panels (B).

Analysis, (3) Query Plan Construction and (4)

Results-Reports and Plan Exploration. In the begin-

ning, our tool displays a conﬁguration form that in-

cludes database connection information. When the

user is connected, he has ﬁrst to select a database

schema (e.g. TPC-H schema database) among many

ones and then selects a query of TPC-H benchmark

to optimize (cf. Figure 6

). The Database Schema

Analysis panel assists users in analyzing information

about database statistics. Figures 6 and 7 show the

CF-CBO main GUI and its component module pan-

els. The Query Plan Analysis panel helps users to get

information about the query structure (Selection/Join

predicate, aggregation functions, etc. These informa-

tion are required to improve query performance (cf.

Figure 6

). In Query Plan Construction (cf. Figure

http://www.tpc.org/tpch/

), the system displays three informational panels.

On the top right, our tool displays the logical query

plan indicating the algebra operators’ execution order

to enable the user making a global understanding on

query result. On the top left, the user can customize

algorithm implementation for each relational algebra

operator in the query plan. In addition, user can get in-

formation about database server parameters and cus-

tomize each value appropriately such as the Shared

SQL Pool and system page size. Finally, the user can

select the hints that are organized into categories (e.g.

Access Paths) and subcategories (e.g. FULL Scan).

The output of this stage is a rewritten SQL query with

automatic code generation from high-level abstrac-

tion description language. In panel Results-Reports

(cf. Figure 7

), the user can verify if the execu-

tion time of the new query plan is higher cost than the

initial cost and tries to reﬁne the query plan by return-

Using MDE for Teaching Database Query Optimizer

535

ing to panel three. In order to assess the user’s query

performance skill, we employed a checklist as edu-

cational strategy to get the participants’ feedback by

selecting the correct or best response from a provided

list (as shown in Figure 7

). The system prompts the

user to answer some questions, like why query has a

lower/upper cost? with several answers such as ”Is

the data for this query beneﬁt from cached data” etc.

The interactions and feedback of users are saved in

the the event logs. This latter indicates users’ per-

formance based on collected data from users’ actions

during interaction with CF-CBO.

5 CONCLUSION

This paper presents a Conceptual and Methodologi-

cal Framework to explain Database Query Optimizer

to users dealing with query performance and to help

transferring the domain knowledge effectively to that

users. The work is motivated by the complexity of the

CBO entity compared to its cardinality estimates, plan

properties, database operations and its algorithms.

Our approach supports that MDE can be applied to a

real problem in advanced courses of database, in par-

ticular, the cost based optimization. The main contri-

butions of this work are as follows. First, (i) we built

a metamodel to explicit Database Query Optimizer

knowledge and to provide a domain vocabulary that

helps learning query plan, understanding and combin-

ing hints, and customizing query plan. Second, (ii) we

developed an MDE based process that offers different

bricks (operations, hints) that are required in CBO to

facilitate query plan optimization. Finally, (iii) we de-

veloped the tool support of the whole approach. Cur-

rently, we are evaluating how the CF-CBO can sig-

niﬁcantly increase efﬁciency and effectiveness of the

students understanding in the query optimization do-

main. Nevertheless, this work opens several direc-

tions of further research. First, we are studying to

explore more intensively DBMS inside in order to de-

liver a more informative instruction on database query

optimization at a high level of abstraction. Second,

we project to develop a rule-based errors diagnosis

related to users selection of required hints to enhance

CBO learnability.

REFERENCES

Agarawal, S. and Others (2000). Automated selection

of materialized views and indexes for Sql databses.

In Proceedings of 26th International Conference on

VLDB, Cairo, Egypt, pages 191–207.

Al-Dmour, A. (2010). A cognitive apprenticeship based

approach to teaching relational database analysis and

design. Journal of Information & Computational Sci-

ence, 7(12):2495–2502.

Allenstein, B. and Others (2008). A query simulation sys-

tem to illustrate database query execution. In Pro-

ceedings of the 39th SIGCSE technical symposium on

Computer science education, pages 493–497.

Almeida, A. C. and Others (2019). An ontological perspec-

tive for database tuning heuristics. In International

Conference on ER, pages 240–254. Springer.

Bhagat, M. and Shukla, S. (2014). Tuning the tpc-c bench-

mark using oracle 10 g. IJEMR, 4(5):179–182.

Brown, D. P., Chaware, J., and Koppuravuri, M. (2009).

Index selection in a database system. US Patent

7,499,907.

Chaudhuri, S. and Narasayya, V. (1998). Autoadmin “what-

if” index analysis utility. ACM SIGMOD Record,

27(2):367–378.

Galaktionov, V. and Chernishev, G. (2019). Designing a

DBMS development course with automatic assign-

ment evaluation. In Fourth Conference on SEIM-2019

(full papers), volume 8, page 48.

Gallinucci, E. and Golfarelli, M. (2019). Sparktune: tun-

ing spark Sql through query cost modeling. In EDBT,

pages 546–549.

Jarke, M. and Koch, J. (1984). Query optimization in

database systems. ACM Computing surveys (CsUR),

16(2):111–152.

Keberle, N. and Utkin, I. V. (2012). Teaching conceptual

modeling in er: Chen worlds. In ICTERI, pages 222–

227.

Leventidis, A. and Other (2020). Queryvis: Logic-based di-

agrams help users understand complicated Sql queries

faster. In Proceedings of the 2020 ACM SIGMOD,

pages 2303–2318.

Liu, S., Bhowmick, S. S., Zhang, W., Wang, S., Huang,

W., and Joty, S. (2019). Neuron: Query execution

plan meets natural language processing for augment-

ing DB education. In Proceedings of the 2019 Inter-

national Conference on Management of Data, pages

1953–1956.

Manegold, S., Boncz, P., and Kersten, M. L. (2002).

Generic database cost models for hierarchical mem-

ory systems. In VLDB, pages 191–202.

Ouared, A., Ouhammou, Y., and Bellatreche, L. (2016).

Costdl: a cost models description language for per-

formance metrics in database. In 2016 21st Interna-

tional Conference on Engineering of Complex Com-

puter Systems (ICECCS), pages 187–190. IEEE.

Pavlo, A. et al. (2017). Self-driving database management

systems. In CIDR, volume 4, page 1.

Scherzinger, S. (2019). Have your Students build their own

Mini Hive in just Eight Weeks. In LWDA, pages 38–

41.

Sciore, E. (2007). Simpledb: a simple java-based multiuser

syst for teaching database internals. ACM SIGCSE

Bulletin, 39(1):561–565.

Siddiqui, T. and Other (2020). Cost models for big data

query processing: Learning, retroﬁtting, and our ﬁnd-

ings. In Proceedings of the 2020 ACM SIGMOD,

pages 99–113.

MDI4SE 2021 - Special Session on Model-Driven Innovations for Software Engineering

536