Database Reference
In-Depth Information
RULES FOR DISTRIBUTED DATABASES
C. J. Date (Date, C. J.
ComputerWorld 21.23, June 8, 1987) for-
mulated 12 rules that distributed databases should follow. The basic goal is that a distributed database should
feel like a nondistributed database to users; that is, users should not be aware that the database is distrib-
uted. The 12 rules serve as a benchmark against which you can measure DDBMSs. The 12 rules are as
follows:
Twelve Rules for a Distributed Database.
1. Local autonomy. No site should depend on another site to perform its database functions.
2. No reliance on a central site. The DDBMS should not rely on a single central site to control
specific types of operations. These operations include data dictionary management, query pro-
cessing, update management, database recovery, and concurrent update.
3. Continuous operation. Performing functions such as adding sites, changing versions of DBMSs,
creating backups, and modifying hardware should not require planned shutdowns of the entire
distributed database.
4. Location transparency. Users should not be concerned with the location of any specific data in
the database. Users should feel as if the entire database is stored at their location.
5. Fragmentation transparency. Users should not be aware of any data fragmentation that has
occurred in the database. Users should feel as if they are using a single central database.
6. Replication transparency. Users should not be aware of any data replication. The DDBMS
should perform all the work required to keep the replicas consistent; users should be unaware of
the data synchronization work carried out by the DDBMS.
7. Distributed query processing. You already learned about the complexities of query processing
in a distributed database. The DDBMS must process queries as rapidly as possible.
8. Distributed transaction management. You already learned about the complexities of update
management in a distributed database and the need for the two-phase commit strategy. The
DDBMS must effectively manage transaction updates at multiple sites.
9. Hardware independence. Organizations usually have many different types of hardware, and a
DDBMS must be able to run on this hardware. Without this capability, users are restricted to
accessing data stored only on similar computers, disks, and so on.
10. Operating system independence. Even if an organization uses similar hardware, different oper-
ating systems might be used within the organization. For the same reason that it is desirable for
a DDBMS to support different types of hardware, a DDBMS must be able to run on different
operating systems.
11. Network independence. Because different sites within an organization might use different com-
munications networks, a DDBMS must run on different types of networks and not be restricted
to a single type of network.
12. DBMS independence. Another way of stating this requirement is that a DDBMS should be het-
erogeneous; that is, a DDBMS must support different local DBMSs. Supporting heterogeneous
DBMSs is a difficult task. In practice, each local DBMS must
285
speak
a common language; this
common language most likely is SQL.
CLIENT/SERVER SYSTEMS
Networks often include a file server, as shown in Figure 9-4. The file server stores the files required by the
users on the network. When users need data from a file or a group of files, they send requests to the file
server. The file server then sends the requested file or files to the user
s computer; that is, the file server
sends entire files, not just the data needed by users. Although this approach works to supply data to users,
sending entire files generates a high level of communication activity on the network. Adding users to the net-
work and larger files to the file server adds higher levels of communication activity and eventually causes
longer delays in supplying data to users.
'
Search WWH ::




Custom Search