O O D B Design And Implementation - Part 2 -


Thành viên VIP

(cont. of Part 1)

OODB Structural Design

As we've learned that OO data cannot be isolated because they are parts of an object. In RDB data are "ACIDed". Meaning they are separated and normalized (structured) so that they could be accessed quickly. The drawback is the loss of the identity of the data and the "post-processing" of data (assembled or "sewed back" as they were). The example People highlights the uniqueness of OO Data and the difference to ACID RDB data. Person "Trump" or "Joe" cannot be "ACIDed" so that a part of Trump could become a part of Joe, or vice versa. The soul always stays unique -even between the twins. The physical can be similar (twins or the "double") or replaced (e.g. Heart or Kidney transplantation). Data are inseparable from the object. For your imagination: RDB data are dead data while OODB data are alive data.

The RDB data are "dead" and we aren't aware about this fact. The circumstance that RDB data have to be "resurrected" in an OO environment manifests their "lifelessness". To do that lots of measures are presented to us. The most widespread measure is the so-called ORM. A heavy buzzword and it stands for Object-Relational-Mapping (see Quydtkt's series [16. Spring Data Jpa 4]). In conjunction with Spring-Boot/Java Persistence API (or JPA) ORM is the "resurrection" mean for the dead RDB data. With OODB such a circumstantial work-around is unnecessary. They are always alive in a class like a soul in a healthy body.

From the "simple" viewpoint of "Data-Object-Inseparability" we have to think about the structural OO Data and that consequently leads us to the Structural OODB design. Inseparability between data and object. But the DB design requires in general an isolation between DB-Clients and DB-Server (C/S). A conflict between Inseparability and C/S Isolation. And that is the veritable challenge for an OODB design.

Let's start with the OO data. As you've already seen that the physical data (of "People") can be easily ACIDed as RDB rules require: name (string field on n letters), age (numeric field), address, etc. But as long as the data are normalizable it works with the ACID paradigm. What would be if the field "URL" is not a link, but an image file (jpeg/png/gif/etc.)? And that is the problem of RDB. It saved the data chunk as a blob and treats it as a peculiar chunk of data. With OO images or sounds are themselves objects. An integral part of another object. So, we have to deal with two structural challenges:

- Client and Server,
- OO-Data-Inseparability

The following picture gives you a raw impression how an OODB Structure could be:

The clients are "physically" separated from the ODB Server as the law of DB-Design requires us. ODB Server handles on its own the OO data as an entity as the law of OO Data of an object dictates us. The two mentioned structural challenges are the base of an ODB Structural Design. In other words: we have to deal with TWO separate parts that communicate a tightly-woven structure (OO data-OO class) to each other loosely over a network which could be a LAN (Local Area Network), a WAN (Wide Area Network) or the Web

Another unspoken challenge that some DB designers shun to talk about is the distributed Database (DDB). Why we need a "distributed DB" and what is a DDB really? In our modern world where everyone owns a smartphone and everyone creates big data per day (imagine how long a teen babbles into his/her smartphone a day). The (big) data increase enormously from second to second. And if the data are stored locally on one "big" server the access will degrade accordingly to the increasing size of the data. Some DB owners unconsciously "store" their data in some gigantic "tables" and boast about the billions or millions of rows and columns. And then they complain at the same time about the sluggish accessing time. The solution for their problems lies in the distributing of data.

Powerful PC can doubtlessly serve as a DB Server. Two powerful PCs that share a half part of the work as if they were "one" server by managing the half part of the data are much better. The access time would certainly improve...

The idea of sharing work is luring, but is the implementation still "Kalashnikov"?

Too complex? Maybe.
Too difficult? Probably.
No significant improvement? No one could give a convincing answer.
So, we let DDB aside?

NO! Kalashnikov's principle is still valid here, too. The implementation can be so simple that you would be flabbergasted if I show you the implementation.

The following picture gives you an idea how the architectural structure of an Object-Oriented DDB looks like and how the networked servers work.

Unseen by the clients the servers communicate and synchronize themselves so that the data are available as if they came from one single source (see images)

Before Cluster @port 9980 starts

After Cluster @port 9980 started.

(Next: OODB Infrastructure on the Client site)
Sửa lần cuối:
  • Like
Reactions: Thanhpv