Client/Server DBMS

There are virtually limitless factors needed to be taken into consideration when evaluation client/server architecture. These factors range from hardware requirements, deployment topology, communication protocol, middleware requirements, integration of management interface, security aspects, scalability (horizontal and vertical) of the solution, development application interfaces, etc. Similarly, client/server database has a number of characteristics which can impact the overall solution. Peter Rob et al. (2009) notes that these include interoperability and remote query execution.

On of the most important client/server database management system characteristic is interoperability which manifest itself in the ability to “provide transparent data access to multiple and heterogeneous clients” (Peter Rob, Carlos Coronel and Steven Morris, 2009. Appendix F. Page 158). Numerous clients written in Java, .NET, C/C++ or Perl have the capacity to interact with the database management server to retrieve or update information through usage of standard protocols such as ODBC and JDBC.

In addition, client/server DBMS architecture allow the end-user to manipulate the information stored in the server DBMS in a number of forms. For example, one design can utilize resources (often distributed) allocated to the DBMS server to process the information (thin client), while another design can distribute the information processing relying on the computing resources of the clients (fat client). Peter Rob et al. (2009) notes that in many cases, the client/server architecture is closely related to distributed database management systems (DDBMS) where the processing of a single query can take place on a number of remote servers.

The client/server database architecture can take a number of forms. Peter Rob et al. (2009) mentions 2-tier and 3-tier architecture which adds a middleware between the client and the server tierd. The middleware, as the name suggests, has a number of functions to facilitate connectivity to the database management server ranging from exposing ODBC or MQ API, converting query formats and managing security aspect (authentication and authorization). Mohammad Ghulam Ali (2009) suggests a 4-tier database architecture which adds a Global Database Management System component to decompose the query “into a set of sub queries to be executed at various remote heterogeneous local component database servers” (Ali, M 2009).

As with any application, distribution of business logic and/or presentation increases the number of attack vectors, thus requiring thorough risk assessment and implementation of appropriate compensating controls to secure the overall solution (Cherry, D 2011). For example, distribution of information from a single location into multiple clients can have a security impact on information considered as private or confidential. Don Klely (2011) notes that additional security controls should be implemented to compensate for the remote storage (on the client side) and transportation of the information. Although this can be solved through a trivial implementation of SSL/TLS protocol between the database server and clients, the solution designer has to consider all applicable risks (both technical and operational) before deciding on the optimal compensating control(s).

Bibliography

• Ali, M 2009, 'A Multidatabase System as 4-Tiered Client-Server Distributed Heterogeneous Database System', arXiv, EBSCOhost, viewed 16 August 2012.
• Cherry, D 2011, Securing SQL Server [Electronic Book] : Protecting Your Database From Attackers / Denny Cherry, n.p.: Burlington, MA : Syngress, 2011., University of Liverpool Catalogue, EBSCOhost, viewed 16 August 2012.
• Kiely, D 2011, 'Key Ways to Secure ASP.NET Applications with a SQL Server Back End', SQL Server Magazine, 13, 12, pp. 27-31, Computers & Applied Sciences Complete, EBSCOhost, viewed 16 August 2012.
• Peter Rob, Carlos Coronel and Steven Morris, 2009. “Database Systems: Design, Implementation and Management”. 9th Edition. Course Technology.