Home My formal education Article list PIS Decentralized database

Decentralized database

E-mail Print
Share/Save/Bookmark
Database in general can be described as a pair: data (D) and index (I). We distinguish four types of database access:
  • read (r)
  • add (a)
  • update (u)
  • delete (d)

Decentralized database types - based on data and index location

DB0 - central database

Located within one computer system. We have only one copy of data and index.

DB1 - replicated  database

Central database is copied on multiple computers. We have to assure consistency - it means that all copies are identical DBi = DBj. This type is good if reading (r) is main operation on the database. Problem emerges when users change contents of database (add, update or delete). In this case local indexes and data on all locations have to be renewed (if we update only index has to be renewed).

DB2 - central database with subsets

Subsets contain their own data of specified location. Other data can be found in central DB when need for that emerges.

DB3 - central database with intersecting subsets

DB3 works like DB2. The main difference is when data is being changed. In DB2 we only have to renew at one location. In DB3 we have to know locations where particular data is stored and renew those locations as well - data consistency is very hard to maintain. DB3 type is highly avoided.

DB4 - central index with subsets

We don't have central data anymore, only index stays central.

DB5 - central index with intersecting subsets

Same as above DB4 type. However same data can appear on multiple locations. When reading we get multiple locations where data is stored. When changing we have to update data on all locations, central and local indexes as well.

DB6 - partitioned database

Database without central data or index. In this type is impossible to plan search procedures that would be consistent and defined in advance.
Change data is simple (done only in one place) when we found its location.

DB7 - intersecting database

Same as DB6 - we don't have central data or index. We have however additional problems because data can be stored at different locations (when changing we have to update them all).


Other possible classifications

Horizontal decentralization

Data structure (entity model) is the same at all locations. Data is being organized in same manner. Subsets are only distinguished in contents.

Scheme decentralization

Various data structure on different locations that are based on same logical entity model.

Reorganized decentralization

Related to horizontal decentralization. Subsets have the same attributes dictionary but they are differently ordered. This type is typical for independently developed information systems - problem domain is the same. Contents are identical but their structure is not compatible.

Vertical decentralization

Subsets differentiate in data structure and it is not necessary they can be united in unified entity model. This type is typical for different subsystem integration in uniform system.

Hybrid decentralization

Data is vertical and horizontal decentralized.

Non-compatible decentralization

This can be a result of badly coordinated information system development.
Hits: 8368
Comments (3)Add Comment
December 09, 2008     
distributed database over a distributed mobile system
Miha,
Can a database be run on a distributed mobile system of handheld devices so without a database controller? Currently, I am tied to a stand-alone database that interacts with my distributed mobile system which creates a significant critical vulnerability. If my laptop that the database manager is running goes down then I lose all functionality of my distributed mobile system.
Can you make any suggestions of open source database software that might be able to solve this. What about a independent db on each handheld device that shares it information to other dbs?
rs
Brad
Brad | 205.155.65.236
December 13, 2008     
not enough info
This depends what kind of application do you want to run? How important it is to have centralized DB? As I wrote you should consider what are your typical transactions? Will there be a lot of writing to the database or the main operation will be reading from it?

Maybe you can have main database replication? Reliability towards single database is increased but this is not very good solution if there are many writings.
Miha Trtnik | 193.77.156.218
February 03, 2009     
like to now the dbms
hi sir
with all your respect i like u to ask so many questions to u so sir i need your assistance pls soon
sis  | 213.55.74.224

Write comment

busy
Last Updated ( Sunday, 23 November 2008 19:05 )  

Sponsored Links

My friends

Bookingpoint
partner websites

Donate

Do you find content useful? Please donate so I can cover my hosting expenses! Thanks!