Question

a) Explain the MAIN objectives of the ANSI-SPARC architecture for a DBMS. Discuss briefly the challenges of achieving these objectives in practice.     

b) Nowadays, many organisations have chosen to have their data resources and services managed remotely by hosting databases on the ‘Cloud’.

Describe the concept of the ‘Cloud’ and explain how it differs from a client-server database architecture. Comment on the advantages of running an organisation’s database resources and services on the ‘Cloud’                                             

Answer 1

 

a)

The ANSI-SPARC Architecture, where ANSI-SPARC stands for American National Standards Institute, Standards Planning And Requirements Committee, is an abstract design standard for a Database Management System (DBMS), first proposed in 1975.

The ANSI-SPARC model however never became a formal standard. No mainstream DBMS systems are fully based on it (they tend not to exhibit full physical independence or to prevent direct user access to the conceptual level), but the idea of logical data independence is widely adopted.

Three-level architecture

The objectives of the three-level architecture is to separate the user's view,

• It allows independent customized user views: Each user should be able to access the same data, but have a different customized view of the data. These should be independent: changes to one view should not affect others.
• It hides the physical storage details from users: Users should not have to deal with physical database storage details.
• The database administrator should be able to change the database storage structures without affecting the users’ views.
• The internal structure of the database should be unaffected by changes to the physical aspects of the storage: For example, a changeover to a new disk.

The three levels are:

• External Level (User Views): A user's view of the database describes a part of the database that is relevant to a particular user. It excludes irrelevant data as well as data which the user is not authorised to access.
• Conceptual Level: The conceptual level is a way of describing what data is stored within the whole database and how the data is inter-related. The conceptual level does not specify how the data is physically stored. Some important facts about this level are:

1. DBA works at this level.
2. Describes the structure of all users.
3. Only DBA can define this level.
4. Global view of database.
5. Independent of hardware and software.

• Internal Level: The internal level involves how the database is physically represented on the computer system. It describes how the data is actually stored in the database and on the computer hardware.

The Three Level Architecture has the aim of enabling users to access the same data but with a personalised view of it. The distancing of the internal level from the external level means that users do not need to know how the data is physically stored in the database. This level separation also allows the Database Administrator (DBA) to change the database storage structures without affecting the users' views.

Database schemas

There are three different types of schema corresponding to the three levels in the ANSI-SPARC architecture.

• The external schemas describe the different external views of the data and there may be many external schemas for a given database.
• The conceptual schema describes all the data items and relationships between them, together with integrity constraints (later). There is only one conceptual schema per database.
• The internal schema at the lowest level contains definitions of the stored records, the methods of representation, the data fields, and indexes. There is only one internal schema per database.

The overall description of a database is called the database schema.

(b) Concept of cloud:

"Cloud computing" is a blanket term meant to do two things: first, to abstract all possible uses of a client-server model behind a single term, as opposed to more specific use cases like "file servers", "database servers", "web servers", "application servers" etc.; and second, to abstract the server architecture itself, in terms of hardware, topology, location, and even ownership.

In a traditional client-server model, which is definitely still in common use today, a client connects to a server that performs a particular job. This server may host a database, or a series of file shares, or a webpage. When the client connects to that server, there is an implicit understanding of the type of communication and data transmission that will ensue between the two computers. There may also be an understanding by the client, or the end user, of the capabilities of the server's hardware, and its limitations. This relatively "tight coupling" between the client machine and its server can pose problems for a sysadmin who needs to take down a server for maintenance; all the applications dependent upon resources provided by this server have to be pointed at another server, and not all applications and infrastructures are designed with this type of redundancy and failover-tolerance in mind.

In a cloud model, the hardware, topology, division of labor, and even number of actual machines involved is all abstracted behind a single endpoint. The analogy could be drawn to a modern "web application", as opposed to older generations of "website" which were more static. We might guess that there is an application server and a DB server behind the scenes, but we really don't have to care; the web server, as part of its job to serve the full application to users beyond the "edge", provides a unified endpoint allowing controlled access to all the data and services provided by other machines behind this front door.

The upshot is that, with a single endpoint exposed to provide the functionality of the application, that's all a client consumer of the application ever has to care about, instead of where to get its data, where to call such and such a remote application process, etc; that means that the administrators and architects of the service provider within this cloud are more or less free to change the machines, topology and other specific implementation details of this "cloud service" without the clients being any the wiser. Facebook could, if it thought it wise, rebuild its entire data storage system from scratch using a different DBMS and all new servers, and as long as the site remained available during the transition, nobody would ever be the wiser; in fact, Facebook did just that, many times, as it expanded from a site hosted from Mark Zuckerberg's personal machine in a dorm room to dedicated hosting off-campus, to server farms in several locations worldwide.