Michael's Interest in Database Management System
A database is just a file (or a set of many files) that stores data, and a database management
system, or commonly known as DBMS, is a software application that interacts with
databases and their users. Essentially you can read and write data to the
database, and it seems so simple this way. Each transaction consists of some
number of write operations and some number of read operations and it is done.
Simple huh? Not quite.
If every transaction were to be executed sequentially, then it is simple as I said.
However we are humans, and as such we are greedy!
We want more than performing a simple sequence of transactions; we want them to
be completed more quickly. That's right; we want SPEED. So somebody figured out
that each transaction can be on its own thread, or better yet, on a remote host.
When transactions are executed in parallel, they tend to finish more quickly
than when they are executed in serial order. That's what we want. Unfortunately
if we pay no attention to the order of the operations that are executed we are
in danger of causing data inconsistency, a terrible disaster in, for example, a financial institution.
For instance, transaction t1 wants to execute r1(x)w1(x) and t2 wants to execute
w2(x)r2(x). If the execution order is t1t2 or t2t1 it is fine. However if they
interleave like r1(x)w2(x)w1(x)r2(x), then this execution must be rolled back. As you can see
t1 reads the value of x, then decides to write to it. t2 butts in and writes to
x some value, and before t1 writes to x, x is a different value from what t1
observed last time.
This situation is not supposed to happen. It's analogous to the following situation.
I see my balance is $100.00, so I deposit $50.00 to it to make it $150.00, but someone
deposits $80.00 to it without my knowledge, and in the end my account has $230.00.
Do you see my point? Checking transactions for data dependency,
unfortunately, is complicated and easily confusing.
In addition, failures are a big problem for distributed database system. A
sample scenario is that several databases are deployed in different geographical
regions, and a user application needs to contact different databases for
different data through the help of a system known as the global transaction
You can immediately see the problem that can occur: While a transaction
is being executed some database may fail and come back up shortly. You need to
make sure the transaction is aborted and rolled back to the original state and
EVERY database that is involved in this transaction must process accordingly. In
our GTM project for Berkeley DB
we needed to consider several
failures types and make sure none of them results in database inconsistency.
Hard, huh? But we pulled it :)
My experience in this area is obtained in the course I took and the project I
did in that course. Also in the projects I conducted with HSM
I had experience using an HSM to do field-level encryption of a
database. I also know SQL quite well.