REPORT ON USES OF DATA BASE IN

DIFFERENT SECTORS BY MANAGERS

SUBJECT- MANAGEMENT INFORMATION

SYSTEM

SUBMITTED TO: DR. RICHA MISRA

SUBMITTED BY:
SHUBHADIP BISWAS
ROLL NO.-FT-10-948
SEC-A
GROUP-4
PGDM 10-12
IILM-GSM

DATE OF SUBMISSION- 19/01/11

REPORT ON USES OF DATA BASE IN DIFFERENT SECTORS
BY MANAGERS---
DATABASE:
A database is a collection of information organized to
provide efficient retrieval.

DBMS is a central system which provides a common interface

between the data and the various front-end programs in the
application. It also provides a central location for the whole data
in the application to reside.
Due to its centralized nature, the database system can overcome
the disadvantages of the file-based system as discussed below.
Minimal Data Redundancy
Since the whole data resides in one central database, the various
programs in the application can access data in different data files.
Hence data present in one file need not be duplicated in another.
This reduces data redundancy. However, this does not mean all
redundancy can be eliminated. There could be business or
technical reasons for having some amount of redundancy. Any
such redundancy should be carefully controlled and the DBMS
should be aware of it.
Data Consistency
Reduced data redundancy leads to better data consistency.

Data Integration
Since related data is stored in one single database, enforcing data
integrity is much easier. Moreover, the functions in the DBMS can
be used to enforce the integrity rules with minimum programming
in the application programs.
Data Sharing
Related data can be shared across programs since the data is
stored in a centralized manner. Even new applications can be
developed to operate against the same data.
Enforcement of Standards
Enforcing standards in the organization and structure of data files
is required and also easy in a Database System, since it is one
single set of programs which is always interacting with the data
files.
 Application Development Ease
The application programmer need not build the functions for
handling issues like concurrent access, security, data integrity,
etc. The programmer only needs to implement the application
business rules.
This brings in application development ease. Adding additional
functional modules is also easier than in file-based systems.
Better Controls
Better controls can be achieved due to the centralized nature of
the system.
Data Independence
The architecture of the DBMS can be viewed as a 3-level system
comprising the following:
– The internal or the physical level where the data resides.
– The conceptual level which is the level of the DBMS functions
– The external level which is the level of the application programs
or the end user.
Data Independence is isolating an upper level from the changes
in the organization or structure of a lower level. For example, if
changes in the file organization of a data file do not demand for
changes in the functions in the DBMS or in the application
programs, data independence is achieved. Thus Data
Independence can be defined as immunity of applications to
change in physical representation and access technique. The
provision of data independence is a major objective for database
systems.
Reduced Maintenance
Maintenance is less and easy, again, due to the centralized nature
of the System The following figure shows the process of database
access in general. The DBMS views the database as a collection of
records. The File Manager of the underlying Operating System
views it as a set of pages and the Disk Manager views it as a
collection of physical locations on the disk.
When the DBMS makes a request for a specific record to the File
Manager, the latter maps the record to a page containing it and
requests the Disk Manager for the specific page. The Disk
Manager determines the physical location on the disk and
retrieves the required page.
Clustering
In this process if the page containing the requested record is
already in the memory, retrieval from the disk is not necessary.
In such a situation, time taken for the whole operation will be
less. Thus, if records which are frequently used together are
placed physically together, more records will be in the same
page. Hence the number of pages to be retrieved will be less
and this reduces the number of disk accesses which in turn gives
a better performance.
This method of storing logically related records, physically
together is called clustering.
If queries retrieving Customers with consecutive Cust_IDs
frequently occur in the application, clustering based on Cust_ID
will help improving the performance of these queries. This can be
explained as follows.
Assume that the Customer record size is 128 bytes and the
typical size of a page retrieved by the File Manager is 1 Kb (1024
bytes).
If there is no clustering, it can be assumed that the Customer
records are stored at random physical locations. In the worst-
case scenario, each record may be placed in a different page.
Hence a query to retrieve 100 records with consecutive Cust_Ids
(say, 10001 to 10100), will require 100 pages to be accessed
which in turn translates to 100 disk accesses.
But, if the records are clustered, a page can contain 8 records.
Hence the number of pages to be accessed for retrieving the 100
consecutive records will be ceil(100/8) = 13. i.e., only 13 disk
accesses will be required to obtain the query results. Thus, in the
given example, clustering improves the speed by a factor of 7.7
Indexing
Indexing is another common method for making retrievals faster.
Consider the example of CUSTOMER table used above. The
following query is based on Customer's city.
“Retrieve the records of all customers who reside in Delhi”
Here a sequential search on the CUSTOMER table has to be
carried out and all records with the value 'Delhi' in the Cust_City
field have to be retrieved. The time taken for this operation
depends on the number of pages to be accessed. If the records
are randomly stored, the page accesses depends on the volume
of data. If the records are stored physically together, the number
of pages depends on the size of each record also.
a sequential search on the CUSTOMER table has to be carried out
and all records with the value 'Delhi' in the Cust_City field have to
be retrieved. The time taken for this operation depends on the
number of pages to be accessed. If the records are randomly
stored, the page accesses depends on the volume of data. If the
records are stored physically together, the number of pages
depends on the size of each record also.
If such queries based on Cust_City field are very frequent in the
application, steps can be taken to improve the performance of
these queries. Creating an Index on Cust_City is one such
method. This results in the scenario as shown below.
A new index file is created. The number of records in the index
file is same as that of the data file. The index file has two fields in
each record. One field contains the value of the Cust_City field
and the second contains a pointer to the actual data record in the
CUSTOMER table. Whenever a query based on Cust_City field
occurs, a search is carried out on the Index file. Here, it is to be
noted that this search will be much faster than a sequential
search in the CUSTOMER table, if the records are stored
physically together. This is because of the much smaller size of
the index record due to which each page will be able to contain
more number of records.
When the records with value 'Delhi' in the Cust_City field in the
index file are located, the pointer in the second field of the
records can be followed to directly retrieve the corresponding
CUSTOMER records.

 It is possible to create an index with multiple fields i.e.,

index on field combinations. Multiple indexes can also be
created on the same table simultaneously though there may
be a limit on the maximum number of indexes that can be
created on a table.
Relational database is usually used in various sector:
Database architecture used by various sectors:
One Tier Architectures
Imagine a person on a desktop computer who uses Microsoft
Access to load up a list of personal addresses and phone numbers
that he or she has saved in MS Windows' “My Documents” folder.
This is an example of a onetier database architecture. The
program (Microsoft Access) runs on the user's local machine, and
references a file that is stored on that machine's hard drive, thus
using a single physical resource to access and process
information.
Another example of a one-tier architecture is a file server
architecture. In this scenario, a workgroup database is stored in a
shared location on a single machine. Workgroup members use a
software package such as Microsoft Access to load the data and
then process it on their local machine. In this case, the data may
be shared among different users, but all of the processing occurs
on the local machine. Essentially, the file-server is just an extra
hard drive from which to retrieve files.
Yet another way one-tier architectures have appeared is in that of
mainframe computing. In this outdated system, large machines
provide directly connected unintelligent terminals with the means
necessary to access, view and manipulate data. Even though this
is considered a clientserver system, since all of the processing
power (for both data and applications) occurs on a single
machine, we have a one-tier architecture.
One-tier architectures can be beneficial when we are dealing with
data that is relevant to a single user (or small number of users)
and we have a relatively small amount of data. They are
somewhat inexpensive to deploy and maintain.

Two Tier Client/Server Architectures

A two-tier architecture is one that is familiar to many of today's
computer users. A common implementation of this type of system
is that of a Microsoft Windows based client program that accesses
a server database such as Oracle or SQL Server. Users interact
through a GUI (Graphical User Interface) to communicate with
the database server across a network via SQL (Structured Query
Language).
N-Tier Client/Server Architectures
Most n-tier database architectures exist in a three-tier
configuration. In this architecture the client/server model
expands to include a middle tier (business tier), which is an
application server that houses the business logic. This middle tier
relieves the client application(s) and database server of some of
their processing duties by translating client calls into database
queries and translating data from the database into client data in
return.
COMPONENT MODEL OF DATABASE AND THEIR
INTERACTIONS:

Tools, Application Environments, and Communications

Facilities
Many tools are often available to database designers, users, and
DBAs. CASE tools" are used in the design phase of database
systems. Another tool that can be quite useful in large
organizations is an expanded data dictionary (or data
repository) system. In addition to storing catalog
information about schemas and constraints, the data dictionary
stores other information, such as design decisions, usage
standards, application program descriptions, and user
information. Such a system is also called an information
repository. This information can he accessed directly by users
or the DBA when needed. A data dictionary utility is similar to the
DBMS catalog, but it includes a wider variety of information and is
accessed mainly by users rather than by the DBMS software.
Application development environments, such as the
PowerBuilder (Sybase) or JBuilder (Borland) system, are
becoming quite popular. These systems provide an environment
for developing database applications and include facilities that
help in many facets of database systems, including database
design, GUI development, querying and updating, and application
program development.
The DBMS also needs to interface with communications
software, whose function is to allow users at locations remote
from the database system site to access the database through
computer terminals, workstations, or their local personal
computers. These are connected to the database site through
data communications hardware such as phone lines, long-haul
networks, local area networks, or satellite communication
devices. Many commercial database systems have communication
packages that work with the DBMS.
The integrated DBMS and data communications system is called a
DB/DC system. In addition, some distributed DBMSs are
physically distributed over multiple machines. In this case,
communications networks are needed to connect the machines.
These are often local area networks (LANs), but
they can also be other types of networks.

Advantages of Database Processing

Economy of Scale
Since several users are sharing the database, any improvement
in the database will benefit several users, The term economy of
scale refers to the fact that the collective cost of several
combined operations may be less than the sum of the cost of
individual operations. This type of combination is possible using
database processing.
Efficient extraction of relevant Information
The primary goal of a computer system is to tune data (recorded
facts) into information (knowledge gained by processing these
facts). This is possible using database.
Sharing of Data
Authorized users can share the data. Several users can have
access to the same piece of data ( for example, faculty members
address) and use it for several purposes, when a faculty members
address is changed. The change is available to all users.
Balancing Conflicting Requirements
For the database approach to function properly there must be a
person or group in change of the database. This group is called
database Administration (DBA). By keeping the overall
requirements of the organization in mind, DBA can structure the
database to the benefit of the entire organization. Thus the
overall organization will benefit.
Environment of Standards
With the centralized control, DBA can ensure those standards for
data names etc. is followed uniformly throughout the
organization.
Controlled Redundancy
Since data, which was kept in several files, is now integrated into
a single database, we no longer have multiple copies of the same
data. There may be occasions when duplication of data will be
necessary. DBMS helps us to control redundancy rather than
eliminate it.
Consistency
Consistency follows from the control or elimination of
redundancy. If the address of a faculty appears only in one place,
it is not possible for a faculty to have one address in one place
and another address in another place.
Integrity
An Integrity constraint is a rule which data in the database should
follow. One integrity constraint may be that the department
number for a faculty must be that of a department which actually
exists. A database has integrity if data in the database satisfies
all integrity constraints, which have been established.
Security
Security is the prevention of access to the database by
unauthorized users. Since DBA has complete control over data it
can define authorization procedures to ensure that only legitimate
users can have access to the data.
DBA can also allow different users to have different types of
access to the same data . the payroll department should
be able to view and change the salary of a faculty and the
Insurance department should be able to view the salary of a
faculty but not change it whereas the person in charge of
handling academic activities of faculty may not be even able to
see the salary. One method by which DBA achieves this security
is through user views. If a data item is not included in the user
view for a use, then that user will not be able to have access to
that data.
Flexibility and Responsiveness
Since the data, which was previously kept in several files, is now
in the same database, responding to requests from different
areas is possible in a much easier and more flexible manner.
Suppose we want to find all faculty members who are in
department2, who are covered by insurance plan3 and who have
a salary below RM35000, we can write
SELECT facultyumber, Name
FROM FACULTY WHERE DeptNo = 2
AND PlanNo = 3 AND SALARY < 35000

Data Independence
Data independence occurs when the structure of the database
can change without requiring programs that access the database
to change. Data independence is achieved through the use of
external views. Each program accesses data through an external
view. The underlying structure of the database can change
without requiring a change in the external view. Of course, the
change to the database structure should be such that a required
field should not be removed from the database structure.

Database Services
Following are services which should be provided by any full scale
DBMS.
1. Data Storage, Retrieval and Update
A DBMS must furnish users with the ability to store, retrieve and
update data in the database.
2. A User Accessible Catalog.
A DBMS must furnish a catalog in which descriptions of data
items are stored which is accessible to users.
3. Transaction support
A DBMS must furnish a mechanism, which will ensure that either
all the updates corresponding to a given transaction are made, or
that none of them is made.
4. concurrency control services
A DBMS must furnish a mechanism to ensure that the database is
updated correctly when multiple users are updating the database
at the same time.
5. Recovery Services
A DBMS must furnish a mechanism for recovering the database if
the database is damaged in any way.
6. Authorization Services
A DBMS must furnish a mechanism to ensure that only authorized
users can have access to the database.
7. Support for data Communication
A DBMS must be able to integrate with communication software.
8. Integrity Services
A DBMS must furnish a mechanism to ensure that both the data
in the database and changes to the data follow certain rules.
9. Services to Promote Data Independence.
A DBMS must include facilities to support the independence of
programs from the actual structure of the database.
10. Utility Services
A DBMS should provide a set of utility services.

EXAMPLE:
Give the computer ID and manufacturer name of all computers,
which either have a 386SX processor or have been assigned, for
the use or both.
SELECT COMPUTER WHERE ProcType = „386SX‟ GIVING TEMP1
PROJECT TEMP1 OVER Compid, Mfgname GIVING TEMP2
JOIN COMPUTER, PC WHERE COMPUTER.Compid = PC.compid
GIVING TEMP3
SELECT TEMP3 WHERE LOCATION = „Home‟ GIVING TEMP4
PROJECT TEMP4 OVER Compid.MfgName GIVING TEMP5
UNION TEMP2 WITH TEMP5 GIVING ANSWER
Give the computer ID and the name of the manufacturer of all
computers which have 386SX processor and which have been
assigned for home use.
Change the last line to
INSERT TEMP2 WITH TEMP5 GIVING ANSWER
Give the computer id and manufacturer name of all computers,
which have a 386SX processor but have not been assigned for
home use.
Change the last line to
SUBTRACT TEMP5 FROM TEMP2 GIVING ANSWER
Product of two relations is the relation obtained by concatenating
every row of the first relation with every row of second relation.

E-R Modeling
Entity Relationship Modeling (ER modeling) is by far the most
common way to express the analytical result of an early stage in
the construction of a new database. E-R Diagrams are the way to
achieve this.
Entity relationship diagrams are a way to represent the structure
and layout of a database. It is used frequently to describe the
database schema. ER diagrams are very useful as they provide a
good conceptual view of any database, regardless of the
underlying hardware and software. An ERD is a model that
identifies the concepts or entities that exist in a system and the
relationships between those entities. An ERD is often used as a
way to visualize a relational database: each entity represents a
database table, and the relationship lines represent the keys in
one table that point to specific records in related tables. ERDs
may also be more abstract, not necessarily capturing every table
needed within a database, but serving to diagram the major
concepts and relationships. This ERD is of the latter type,
intended to present an abstract, theoretical view of the major
entities and relationships needed for management of electronic
resources. It may assist the database design process for an e-
resource management system, but does not identify every table
that would be necessary for an electronic resource management
database.

shows an ER schema diagram for the COMPANY database

Basic Constructs of E-R Modeling
The ER model views the real world as a construct of entities and
association between entities.
Entities
Entities are the principal data object about which information is to
be collected. Entities are usually recognizable concepts, either
concrete or abstract, such as person, places, things, or events
which have relevance to the database. Some specific examples of
entities are EMPLOYEES, PROJECTS, INVOICES. An entity is
analogous to a table in the relational model. Entities are classified
as independent or dependent (in some methodologies, the terms
used are strong and weak, respectively). An independent entity is
one that does not rely on another for identification. A
dependent entity is one that relies on another for identification.
An entity occurrence (also called an instance) is an individual
occurrence of an entity.
An occurrence is analogous to a row in the relational table.
Special Entity Types
Associative entities (also known as intersection entities) are
entities used to associate two or more entities in order to
reconcile a many-to-many relationship.
Subtypes entities are used in generalization hierarchies to
represent a subset of instances of their parent entity, called the
supertype, but which have attributes or relationships that apply
only to the subset.
Associative entities and generalization hierarchies are discussed
in more detail below.
Relationships
A Relationship represents an association between two or more
entities. An example of a relationship would be:
employees are assigned to projects
projects have subtasks departments manage one or more
projects Relationships are classified in terms of degree,
connectivity, cardinality, and existence
Some relationship instances in the SUPPLY ternary relationship set

Schema diagram for the COMPANY relational database schema

One possible database state for the COMPANY relational database schema
Attributes
Attributes describe the entity of which they are associated. A
particular instance of an attribute is a value. For example, "Jane
R. Hathaway" is one value of the attribute Name. The domain of
an attribute is the collection of all possible values an attribute can
have. The domain of Name is a character string.
Attributes can be classified as identifiers or descriptors.
Identifiers, more commonly called keys, uniquely identify an
instance of an entity. A descriptor describes a non-unique
characteristic of an entity instance.
Classifying Relationships
Relationships are classified by their degree, connectivity,
cardinality, direction, type, and existence. Not all modeling
methodologies use all these classifications.
Degree of a Relationship
The degree of a relationship is the number of entities associated
with the relationship. The n-ary relationship is the general form
for degree n. Special cases are the binary, and ternary ,where the
degree is 2, and 3, respectively. Binary relationships, the
association between two entities are the most common type in
the real world. A recursive binary relationship occurs when
an entity is related to itself. An example might be "some
employees are married to other employees".
A ternary relationship involves three entities and is used when a
binary relationship is inadequate. Many modeling approaches
recognize only binary relationships. Ternary or n-ary relationships
are decomposed into two or more binary relationships.
Connectivity and Cardinality
The connectivity of a relationship describes the mapping of
associated entity instances in the relationship. The values of
connectivity are "one" or "many".
The cardinality of a relationship is the actual number of related
occurrences for each of the two entities. The basic types of
connectivity for relations are:
one-to-one, one-to-many, and many-to-many.
A one-to-one (1:1) relationship is when at most one instance of a
entity A is associated with one instance of entity B. For example,
"employees in the company are each assigned their own office.
For each employee there exists a unique office and for each office
there exists a unique employee.
A one-to-many (1:N) relationships is when for one instance of
entity A, there are zero, one, or many instances of entity B, but
for one instance of entity B, there is only one instance of entity A.
An example of a 1:N relationships is a department has many
employees each employee is assigned to one department.
A many-to-many (M:N) relationship, sometimes called non-
specific, is when for one instance of entity A, there are zero, one,
or many instances of entity B and for one instance of entity B
there are zero, one, or many instances of entity A. An example
is:
employees can be assigned to no more than two projects at the
same time; projects must have assigned at least three employees
A single employee can be assigned to many projects; conversely,
a single project can have assigned to it many employee. Here the
cardinality for the relationship between employees and projects is
two and the cardinality between project and employee is three.
Many-to-many relationships cannot be directly translated to
relational tables but instead must be transformed into two or
more one-to-many relationships using associative entities.
Direction
The direction of a relationship indicates the originating entity of a
binary relationship. The entity from which a relationship
originates is the parent entity; the entity where the relationship
terminates is the child entity. The direction of a relationship is
determined by its connectivity. In a one-to-one relationship the
direction is from the independent entity to a dependent entity. If
both entities are independent, the direction is arbitrary. With one-
to many relationships, the entity occurring once is the parent.
The direction of many-to-many relationships is arbitrary.
Type
An identifying relationship is one in which one of the child entities
is also a dependent entity. A non-identifying relationship is one in
which both entities are independent.
Existence
Existence denotes whether the existence of an entity instance is
dependent upon the existence of another, related, entity
instance. The existence of an entity in a relationship is defined as
either mandatory or optional. If an instance of an entity must
always occur for an entity to be included in a relationship, then it
is mandatory. An example of mandatory existence is the
statement "every project must be managed by a single
department". If the instance of the entity is not required, it is
optional. An example of optional existence is the statement,
"employees may be assigned to work on projects".
Generalization Hierarchies
A generalization hierarchy is a form of abstraction that specifies
that two or more entities that share common attributes can be
generalized into a higher level entity type called a supertype or
generic entity. The lower-level of entities become the subtype, or
categories, to the supertype. Subtypes are dependent entities.
Generalization occurs when two or more entities represent
categories of the same real-world object. For example,
Wages_Employees and Classified_Employees represent categories
of the same entity, Employees.
In this example, Employees would be the supertype;
Wages_Employees and Classified_Employees would be the
subtypes.
ER Notation
There is no standard for representing data objects in ER
diagrams. Each modeling methodology uses its own notation. The
original notation used by Chen is widely used in academics texts
and journals but rarely seen in either CASE tools or publications
by non-academics. Today, there are a number of notations used,
among the more common are Bachman, crow's foot, and IDEFIX.
Database Security and the DBA
The database administrator (DBA) is the central authority for
managing a database system. The DBA's responsibilities include
granting privileges to users who need to use the system and
classifying users and data in accordance with the policy of the
organization. The DBA has a DBA account in the DBMS,
sometimes called a system or superuser account, which
provides powerful capabilities that are not made available to
regular database accounts and users. DBA-privileged commands
include commands for granting and revoking privileges to
individual accounts, users, or user groups and for performing the
following types of actions:
1. Account creation: This action creates a new account and
password for a user or a group of users to enable access to the
DBMS.
2. Privilege granting: This action permits the DBA to grant certain
privileges to certain accounts.
3. Privilege revocation: This action permits the DBA to revoke
(cancel) certain privileges that were previously given to certain
accounts.
4. Security level assignment: This action consists of assigning
user accounts to the appropriate security classification level.
The DBA is responsible for the overall security of the database
system.
Action 1 in the preceding list is used to control access to the
DBMS as a whole, whereas actions 2 and 3 are used to control
discretionary database authorization, and action 4 is used to
control mandatory authorization.
Access Control Policies for E-Commerce and the Web
Electronic commerce (E-commerce) environments are
characterized by any transactions that are done electronically.
They require elaborate access control policies that go beyond
traditional DBMSs. In conventional database environments,
access control is usually performed using a set of authorizations
stated by security officers or users according to some security
policies. Such a simple paradigm is not well suited for a dynamic
environment like e-commerce. Furthermore, in an e-commerce
environment the resources to be protected are not only
traditional data but also knowledge and experience. Such
peculiarities call for more flexibility in specifying access control
policies. The access control mechanism must be flexible enough
to support a wide spectrum of heterogeneous protection objects.
A second related requirement is the support for content-based
access control. Content-based access control allows one to
express access control policies that take the protection object
content into account. In order to support content-based access
control, access control policies must allow inclusion of conditions
based on the object content.
A third requirement is related to the heterogeneity of subjects,
which requires access control policies based on user
characteristics and qualifications rather than on very specific and
individual characteristics (e.g., user IDs). A possible solution, to
better take into account user profiles in the formulation of access
control policies, is to support the notion of credentials.
A credential is a set of properties concerning a user that are
relevant for security purposes (for example, age, position within
an organization). For instance, by using credentials, one can
simply formulate policies such as "Only permanent staff with 5 or
more years of service can access documents related to the
internals of the system."
It is believed that the XML language can play a key role in access
control for e-commerce applications.4 The reason is that XML is
becoming the common representation language for document
interchange over the Web, and is also becoming the language for
e-commerce. Thus, on the one hand there is the need to make
XML representations secure, by providing access control
mechanisms specifically tailored to the protection of XML
documents.
On the other hand, access control information (that is, access
control policies and user credentials) can be expressed using XML
itself. The Directory Service Markup Language provides a
foundation for this: a standard for communicating with the
directory services that will be responsible for providing and
authenticating user credentials. The uniform presentation of both
protection objects and access control policies can be applied to
policies and credentials themselves. For instance, some credential
properties (such as the user name) may be accessible to
everyone, whereas other properties may be visible only to a
restricted class of users. Additionally, the use of an XML-based
language for specifying credentials and access control policies
facilitates secure credential submission and export of access
control policies.
Statistical Database Security
Statistical databases are used mainly to produce statistics on
various populations. The database may contain confidential data
on individuals, which should be protected from user access.
However, users are permitted to retrieve statistical information
on the populations, such as averages, sums, counts, maximums,
minimums, and standard deviations. The techniques that have
been developed to protect the privacy of individual information
are outside the scope of this book.
A population is a set of tuples of a relation (table) that satisfy
some selection condition. Hence each selection condition on the
PERSON relation will specify a particular population of PERSON
tuples. For example, the condition SEX = 'M' specifies the male
population; the condition ((SEX = 'M')
AND (l_AST_DEGREE = 'M.S.' OR LAST_DEGREE = 'PH.D.'))
specifies the female population that has an M.S. or PH.D. degree
as their highest degree; and the condition CITY = 'Hyderabad'
specifies the population that lives in Hyderabad
SQL is an ANSI (American National Standards Institute) standard
computer language for accessing and manipulating database
systems. SQL statements are used to retrieve and update data in
a database. SQL works with database programs like MS Access,
DB2, Informix, MS SQL Server, Oracle, Sybase, etc.
Unfortunately, there are many different versions of the SQL
language, but to be in compliance with the ANSI standard, they
must support the same major keywords in a similar manner (such
as SELECT, UPDATE, DELETE, INSERT, WHERE, and others).

Uses of DBMS in different sectors: Database is widely used all

around the world in different sectors:

1.Banking:
For customer information, accounts loans and banking transactions.

2.Airlines:
For reservations and schedule information. Airlines were among the
first to use database in a geographically disturbed manner-terminals
situated around the world accessed the central database system
through phone lines and other data networks.

3.Universities:
For student information, course registrations and grades.

4.Credit card transactions:

For purchases on credit cards and generation of monthly
statements.

5.Telecommunications:
For keeping records of calls made, generating monthly bills,
maintaining balances on prepaid calling cards and storing
information about the communication networks.

6.Finance:
For storing information about holdings, sales and purchase of
financial instruments such as stocks and bonds.

7.Sales:
For customer, product and purchase information.
8.Manufacturing:
For management of supply chain and for tracking production of
items in factories, inventories of items in warehouses/stores and
orders for items.

9.Human Resources:
For information about employees, salaries, payroll taxes and
benefits and for generation of paychecks.

10.Web based services:

For taking web users feedback,responses,resource sharing etc.

DATABASE USED IN RETAIL SECTOR:

SPECIALLY FOR-------
 ADMINISTRATIVE PURPOSE
 CUSTOMER SERVICES

ADMINISTRATIVE PURPOSE::
EMPLOYEE(Emp_Id, Work_Location, Name, Address)
STORE(Store_ID, Region, Manager_ID, Square_Feet)
DEPARTMENT(Dep_ID, Manager_ID, Sales, Goal)
SCHEDULE(Dep_ID, Emp_ID, Date)
CUSTOMER SERVICES

 Uses of DBMS in fmcg sectors:

 Database is widely used all around the world in fmcg sectors:
 Sales: For customer, product and purchase information.
 Manufacturing: For management of supply chain and for tracking
production of items in factories, inventories of items in warehouses/stores
and orders for items.

Attributes used are customer _id, customer_address, customer_sales record,

product_id, product_price, product_quantity,product_purchased, creditcard_id,
order_id ,employee_id,employee_address etc.

Example----
How The ER conceptual schema diagram can be used for the COMPANY database in
fmcg sector for keeping track records of employees

DATABASE IS REQUIRED TO ACQUIRE INFORMATION,STORE

INFORMATION, RETRIEVING INFORMATION, COMMUNICATING
INFORMATION
some commonly used DBMS are MySQL, PostgreSQL, Microsoft
Access, SQL Server, FileMaker,Oracle,Sybase, dBASE, Clipper,FoxPro
etc. Almost every database software comes with an Open Database
Connectivity (ODBC) driver that allows the database to integrate
with other databases.

Hospital industry:

 Hospital-----Department wise database-employer like-

Doctor, Nurse, Pathology, House Keeping, Medicine Store(if)
 Patient- In and out timing, Advance amount, Doctor Allotted,
Details etc.

Management Reporting Systems

Management reporting systems (MRS) are the most elaborate of
the management-oriented MIS components. Indeed, some writers
call MRS management information systems, the name we reserve
for the entire area of informational support of operations and
management. The main objective of MRS is to provide lower and
middle management with printed reports and inquiry capabilities
to help maintain operational and management control of the
enterprise
1) MRS are usually designed by MIS professionals, rather than
end users, over an extensive period time, with the use of life-
cycle oriented development methodologies (as opposed to first
building a simpler prototype system and then refining it in
response to user experience). Great care is exercised in
developing such systems because MRS is large and complex in
terms of the number of system interfaces with various users and
databases.
2) MRS is built for situations in which information requirements
are reasonably well known and are expected to remain relatively
stable. Modification of such systems, like their development, is a
rather elaborate process. This limits the informational flexibility
of MRS but ensures a stable informational environment.
3) MRS does not directly support the decision-making process as
a search for alternative solutions to problems. Naturally,
information gained through MRS is used in the manager's
decision-making process. Well- structured decision rules, such as
economic order quantities for ordering inventory or accounting
formulas for computing various forms of return on equity, are
built into the MRS itself.
4) MRS is oriented towards reporting on the past and the present,
rather than projecting the future.
5) MRS generally has limited analytical capabilities-they are not
built around elaborate models, but rather rely on summarization
and extraction from the database according to given criteria.
Based on simple processing of the data summaries and extracts,
report information is obtained and printed (or, if of limited size,
displayed as a screen) in a pre specified format.
6) MRS generally report on internal company operations rather
than spanning the company's boundaries by reporting external
information.
Reporting by MRS
MRS may produce reports; either directly from the database
collected through transaction processing systems, or from
databases spun off for the purpose. Separate spin-off databases
may be created for several reasons, such as avoiding interference
and delays in transaction processing, maintaining the security of
central databases, or economizing by using local databases
accessible to local managers to counter the heavy
telecommunication costs of working with a central database.
MRS provides the following report forms:
1)Scheduled (Periodic) Reports
These reports are furnished on a daily, weekly, biweekly, or other
basis depending on the decision making need. The sales manager
to assess the performances of sales districts or individual
salespeople may use a weekly sales analysis report. A brand
manager responsible for a particular product might obtain weekly
sales report containing information useful in his or her decision
making-showing regional sales and sales to various market
segments.
2)Exception Reports
Another means of preventing information overload is resorting to
exception reports, produced only when preestablished "out-of-
bounds" conditions occur and containing solely the information
regarding these conditions. For example, purchasing managers
may need an exception report when suppliers are a week late in
deliveries. Such a report may be triggered automatically by the
delay of an individual supplier, or produced on a scheduled basis-
but only if there are late suppliers. The report might include a list
of late suppliers, the extent to which each is late, and the
supplies ordered from each. Exception reporting helps managers
avoid perusal of unneeded figures.
3)Demand (Ad Hoc) Reports
The ability of a manager to request a report or screen output as
needed enhances the flexibility of MRS use and gives the end
user (the individual manager) the capability to request the
information and format that best suit his or her needs. Query
languages provided by DBMS make data accessible for demand
reporting.