Adbms 26 architectures for a distributed system
- 1. Advance Database Management Systems :26 Architectures for a Distributed System Prof Neeraj Bhargava Vaibhav Khanna Department of Computer Science School of Engineering and Systems Sciences Maharshi Dayanand Saraswati University Ajmer
- 2. Rationale for Distribution • A distributed database system is one in which multiple database sites are linked by a communications system in such a way that the data at any site is available to users at other sites. • Normally, each site or node has a complete information processing system, with its own data administration function, personnel, users, hardware, and software—including a local database, database management system, and communications software. • At the very least, a site must have memory and a communications processor. • The sites are usually geographically remote and are linked by a telecommunications system, although it is possible to have a distributed system linked by a local area network within a single building or small area.
- 3. Rationale for Distribution • Ideally, users need not be aware of the true location of the data they access, and the system appears to be a local database to them. • Depending on the needs of the organization, distributed databases can have many advantages over a single, centralized system that – provides remote access to users, – including increased local autonomy, – improved reliability, – better data availability, – increased performance, – reduced response time, and – lower communications cost. • Distributed database systems include traditional SQL-based relational systems, object databases, XMLbased databases, unstructured data systems, NoSQL, and NewSQL databases.
- 4. Architecture Factors • Factors the designer of a distributed database system must consider in choosing an architecture – include data placement, – the type of communications system, – data models supported, and – types of applications. • Data placement alternatives differ in the amount of data replication they permit.
- 5. Architectures for a Distributed System • Each alternative dictates a different type of system, using different update and request decomposition procedures. • Various data models and accompanying manipulation languages are supported in distributed systems. • In general, a designer should avoid models that use record-at-a-time retrieval, and choose instead those that allow set-level operations, because of the number of messages that are required for programmer-navigated retrieval.
- 6. Architectures for a Distributed System • In considering the types of applications to be performed against the chosen database, the designer needs to – estimate the size of the database, – the number of transactions, – the amount of data the transactions require, – the complexity of transactions, – the number of retrievals relative to the number of updates, and – the number of transactions that refer to local data as opposed to remote data.
- 7. Distributed Processing Using a Centralized Database • In this the database itself is not distributed, but users access it over a computer network. • Processing can be performed at multiple sites, using data from the central database site. • The central site also does processing, often both for its local applications and for some centralized applications. • Local sites communicate only with the central site, not with one another, when they access data from the database for processing.
- 8. A Distributed Processing System
- 10. Client-Server Systems • In client-server systems the database resides on a server, and users typically access the data through their workstations, which function as clients. • The database functions are divided between client and server. • The client provides the user interface and runs the application logic, while the server manages the data and processes data requests. • In a typical interactive transaction, the user interacts with the client workstation, using a graphical user interface provided either by the database system or by a third-party vendor. • Besides handling the application logic, the client performs – initial editing of data requests, – checks the syntax of the request, and – generates a database request, which is sent via the network to the server.
- 11. Client-Server Systems • The server validates the request by – checking the data dictionary, – authorization, and integrity constraints; – optimizes the query; – applies concurrency controls and recovery techniques; – retrieves the data; and sends it back to the client. • The client presents the data to the user. Application programs also run on the client, passing data requests through an application programming interface (API) to the server in a similar fashion. • If the client adheres to a standard such as ODBC or JDBC, it can communicate with any server that provides a standard interface. • Unlike the centralized database environment, the server does not do application processing itself.
- 12. Assignments • Explain the Rationale for Distribution for a distributed DBMS • Explain the Architecture Factors that are considered in deciding the distributed DBMS design • Briefly Explain the Client-Server Systems