Chapter -11

Access Layer : Object storage and Object interoperability

Database Views
DBMS provides the database users with a conceptual representation that is

independent of the low-level details (physical view) of how the data are stored.
The database provides an abstract data model that uses logical concepts such as field, records and tables and their interrelationships. These models can be

easily understood by the user than the low-level storage concepts.

This abstract data model can facilitate multiple views of the same underlying data. Each application may be interested in only a subset of the data. DBMS can provide multiple views (virtual) of the data that are tailored to individual applications.

Relational Model
It is simple and widespread. Here the relation can be thought of as a table.

The columns of each table are attributes that define the data or value domain
for entries in that column. The rows of each table are tuples representing individual data objects being stored. A relational table should have only one primary key. A primary key is a combination of one or more attributes whose value unambiguously locates each row in the table.

A foreign key is a primary key of one table that is embedded in another table to link the tables.
3

Micro and Macro Level Analysis

Micro-level At the micro-level, also referred to as the local level, the research population typically is an individual in their social setting or a small group of individuals in a particular social context. Examples of micro-level units of analysis include, but are not limited to, the following. Alien, stateless person, asylum seeker, refugee Person Citizen Partnership, marriage Families Household Neighborhood Macro-level Macro-level analyses generally trace the outcomes of interactions, such as economic or other resource transfer interactions over a large population. Also referred to as the global level. Examples of macro-level units of analysis include, but are not limited to, the following. Nation Society Civilization International

Designing Interface Objects

The interface on a database must include a data definition language (DDL), a query and data manipulation language (DML).

These languages must be designed to reflect the flexibility and constraints

inherent in the data model. Databases have adopted 2 approaches for interfaces with the system. One is to embed a database language such as structured query language (SQL), in the host programming language. The problem here is that

application programmers have to learn and use two different languages. The application programmers have to negotiate the differences in the data models and data structures allowed in both languages.

Another approach is to extend the host programming language with

Designing View Layer Interface

Translate the request: The access layer must be able to translate any data

related requests from the business layer into the appropriate protocol for
data access. Translate the results: The access layer also must be able to translate the

data retrieved back into the appropriate business objects and pass those
objects back into the business layer. Here design is tied to any base engine or distributed object technology such as CORBA or DCOM. Here we can switch easily from one database to another with no major changes to the user interface or business layer objects. All we need to change are the access classes methods.
6

Access Layer: Object storage and object interoperability

A Date Base Management System (DBMS) is a set of programs that

enables the creation and maintenance (access, manipulate, protect and

manage) of a collection of related data. The purpose of DBMS is to provide reliable, persistent data storage and

mechanisms for efficient, convenient data access and retrieval.

Persistence refers to the ability of some objects to outlive the programs that created them.

Object lifetimes can be short for local objects (called transient objects) or
long for objects stored indefinitely in a database (called persistent objects).
7

Persistent stores
Most object-oriented languages do not support serialization or object

persistence, which is the process of writing or reading an object to and from

a persistence storage medium, such as disk file. Unlike object oriented DBMS systems, the persistent object stores do not

support query or interactive user interface facilities.

Controlling concurrent access by users, providing ad-hoc query capability and allowing independent control over the physical location of data are not

possible with persistent objects.