1.0 Abstract
This paper presents a proposed conceptual architecture for the MySQL Relational Database Management
System (RDBMS). The paper first goes into a brief examination of general RDBMS's. This research serves as a
"roadmap" for further architectural discovery. It is a good assumption that the architecture for MySQL is similar
to that of a general RDBMS architecture. Beyond this, MySQL documentation and literature specific to MySQL
was examined to assist in defining the actual conceptual architecture of MySQL.
The MySQL architecture was first broken down into three layers: an application layer, a logical layer, and a
physical layer. The logical layer, which is focused upon in detail, was broken down into four components: a
query processor, a transaction management system, a recovery management system, and a storage
management system.
It should be noted that recovering a conceptual architecture has a noticeable envelope for inaccuracy; putting
the pieces of the puzzle together depends not only on facts, but also on relative intuition and logic, which may
vary between the realization of the researchers and the designers. Thus, there should never be a guarantee
that a conceptual architecture is completely correct; rather, someone who had no part in development should
use the conceptual architecture as a general interpretation of the true architecture for MySQL.
2.0 Introduction and Overview
The purpose of this report is to extract the conceptual architecture of the MySQL open-source RDBMS 4.0,
based from existing MySQL documentation and the general architecture of RDBMS's. There is no actual
architectural diagram for the MySQL RDBMS provided by the designers. The conceptual architecture shows the
information about what the system does and how this is broken into interacting parts. The MySQL RDBMS is a
very popular database system that is being used all over the world for its performance, simplicity and
robustness. (It should be noted that this document attempts to obtain the conceptual architecture of MySQL 4.0,
which incorporates transaction and recovery functionality.)
This report is organized into the following sections. Section 1.0 is an Abstract that provides a brief overview of
the key points in this report. Section 2.0 is the Introduction and Overview (this section) that basically
summarizes the purpose of the report, its organization and conclusions. Section 3.0, following this section, is
the General RDBMS Architecture that provides a high-level overview of the architecture of a RDBMS. From
here, section 4.0 is the MySQL Architecture. This section provides the details of the high-level layered
architecture of an RDBMS pertaining specifically to MySQL. Within each layer, we go deeper into the sublayers
that characterize the interactions in the MySQL RDBMS system. Finally, we drill a level deeper and provide a
diagram of the components and interaction between them. These components are described in detail as to
their functionality and their relationship with other components in the same layer. This diagram is extracted
based from reading documentation and books on MySQL and then mapping them onto the general architecture
of an RDBMS found from RDBMS concept books. For each layer, we discuss how the architecture we prescribe
is subject to system evolvability. Our conceptual architecture is using the logical view of the 4+1 Architectural
Views paper by Phillipe Kruchten. Scenarios are then presented to the reader in section 5.0, which provide a
walkthrough of the conceptual architecture to illustrate the interaction between the various components within
the layer and communication among layers. Data dictionary section 6.0 provides a glossary of terms used
within this report and their meaning. Finally, references are listed from which the reader can search and
explore more information, and from which our research is based on.
Extracting the conceptual architecture from a RDBMS such as MySQL is not a trivial task. It involves reading
lots of documentation on the system itself as well as external references to the theoretical structure or general
structure of the system. There really is no guided way to extract a conceptual architecture. The conceptual
architecture is just a mental view as to how the system works and is basically a graphical representation of the
system to help understand its functionality.
3.0 General RDBMS Architecture
It was found in all of the consulted resources that all database systems, can be viewed as a Garlan & Shaw
layered architecture at the highest level of abstraction. It has three main components as outlined in the
following diagram:
Database Layered Architecture
Application Layer
Logical Layer
Physical Layer
Figure 1: Database Layered Architecture
3.1 Application Layer
The application layer represents the interface for all the users of the system; it essentially provides the means
by which the outside world can interact with the database server. In general, it has been found that users can
be categorized into four main groups:
1. Sophisticated users interact with the system without using any form of application; they form
their requests directly with the use of a database query language.
2. Specialized users are application programmers who write specialized database applications
that do not fit into the traditional data-processing framework.
3. Naïve users are unsophisticated users who interact with the system by invoking one of the
permanent application programs that have been previously written.
4. Database Administrators have complete control over the entire database system. They have
a wide variety of responsibilities, including schema definition, the granting of access
authorization, as well as the specification of integrity constraints.
All database systems provide extensive services for each of these groups; it is then left to the logical layer to
appropriately process the varying requests.
3.2 Logical Layer
The core functionality of the RDBMS is represented in the logical layer of the architecture; it is in this portion of
the system that there are a wide variety of vendor specific implementations (see Figure 2). However, upon
reading a number of general database management texts, it was found that general core logical functionality
can indeed be abstracted. The following diagram is a high level abstraction of the modules found in any robust
RDBMS.
