1 | P a g e

Distributed Database Security using Discretionary Access Control

A Project Report

Submitted by

SumitroBhaumik(Roll-000911001011)

&

JyotishkarDey (Roll-000911001036)

Of

B.E.

IN

INFORMATION TECHNOLOGY

At

FACULTY OF ENGINEERING AND TECHNOLOGY,

JADAVPUR UNIVERSITY

2009-2013

2 | P a g e

Student Declaration

We,

___________________________________________

___________________________________________

of final year, declare that this report contains only work completed by us

except for information obtained in a legitimate way from literature,

company or university sources. All information from these other sources has

been duly referenced and acknowledged.

Signature of student :

Date :

3 | P a g e

Certificate

This is to certify that the project entitled “Distributed Database Security” is the

work carried out by,

__________________________________________________________________________________________,

student of B.E. (IT) of Jadavpur University during the year 2012-2013,and that

the project contains only work completed by them except for information

obtained in a legitimate way from literature, company or university

sources. All information from these other sources has been duly referenced

and acknowledged.

Signature of Guide :

Date :

4 | P a g e

Acknowledgement

We would like to express our special thanks of gratitude to our mentor

Dr. Parama Bhaumik, who gave us the opportunity to work on this wonderful

project on the topic of Distributed Database Security, which also helped us in

doing a lot of Research and we came to know about so many new things.

Finally, we would also like to thank our friends who helped us a lot in

finishing this project within the limited time and our parents without whom

this project might not have been possible.

Sumitro Bhaumik

Jyotishkar Dey

5 | P a g e

Contents

1. Introduction … 6

2. Objective … 8

3. Designing a secure Database …9

4. Multilevel Database Security …13

5. Granularity …17

6. Working Principle(Bell LaPadula Model) …18

7. Implementation …21

8. Limitations …22

9. Area of Use …23

10. Conclusion …24

11. References …25

12. Appendix …26

6 | P a g e

Introduction

A conventional database management system does not consider the

security aspect of the database. Consider an RDBMS designed using Oracle or

MySQL. It only concerns with storage and organization of data. Standard

RDBMS techniques like normalization, concurrency control are only

considered. Database is designed by us considering normal forms to get rid of

problems like insertion anomaly, deletion anomaly and incorrect summary

problem. Concurrency control is done by the software. Sensitive data may be

stored on such database and if we do not consider security aspects of these

stored data then the security is compromised. In general case we have one

centralised or distributed server storing data and clients in remote location

access those data simultaneously. The data may be compromised on the way

during transfer by Network security attacks like eavesdropping; decrypting the

encrypted data. But in distributed database security we do not consider the

security of the data in transit. What we are really interested about is the access

control of different legitimate user. Suppose there are several tables and

depending upon access rights different legitimate users should view some of

the tuples and some of the columns of the tables. That is a part of the

database is displayed to users depending upon access right. Here our goal is to

implement such security level.

In the security aspect of database we have to deal with several concerns.

How do we protect the database from unauthorized access?

Who should be able to see which part of tables?

Who should be able to update?

To solve the problem of eavesdropping, encryption may be used. But that is

not the focus of our discussion. Our focus is on access and view of database

according to privileges of users and sensitivity of security levels of the

database.

To solve the problem for unauthorised access, using a password is common

practice. But it does not solve the whole problem as different users should

view different parts of the database according to the sensitivity of security

7 | P a g e

levels. A higher authority has right to view more sensitive information’s than

an ordinary employee who should be able to view only part of database.

In computer security, Mandatory Access Control (MAC) is a type of

access control in which only the administrator manages the access controls.

The administrator defines the usage and access policy, which cannot be

modified or changed by users, and the policy, will indicate who has access to

which programs and files. MAC is most often used in systems where priority is

placed on confidentiality.

In computer security, Discretionary Access Control (DAC) is a type of

access control in which a user has complete control over all the programs it

owns and executes, and also determines the permissions other users have

those files and programs. Because DAC requires permissions to be assigned to

those who need access, DAC is commonly called described as a "need-to-

know" access model

8 | P a g e

Objective

The problem with MAC is that MAC provides tighter security because only a

system administrator may access or alter controls.And also MAC policies

reduce security errors.It reduces the degree of flexibility.MAC specifies the

path of information flow.Multilevel security model is basically based on a finite

state model known as Bell-Lapadula model.The Bell–LaPadula model defines a

“secure state” through three multilevel properties

• The Simple Security Property (ss Property)

• The * (star) Security Property

• The Discretionary Security Property

The first two properties deal with MAC. Here in the first property a user with

low privilege is not allowed to view an object with high privilege. In the second

property a user with high privilege is not allowed to write on a n object having

low privilege as he/she may write vital information there and the object of low

priority being accessible to petty users there is a chance of security leak. Thus

in MAC, we restrict the flow of information. But these property needs not to be

followed always. Because we may trust few low privilege user to be able to

read write upon sensitive information. Such situations are very common. Using

MAC in such cases restricts our self to add these flexibilities. Also a super user

has the legitimate rights to perform write operation on low privileged objects.

But care has to be taken to avoid leakage of information.

But unlike MAC, Discretionary Access Control(DAC )is more flexible.DAC is

based on granting and revoking of privileges.Privileges here are assignedat two

levels.Each user account is assigned rights or privileges and the relations are

also assigned privileges is - the privilege to access a particular relation is

controlled or restricted.

9 | P a g e

Designing a secure Database

Step 1: Identification of subjects, objects and permitted actions (identification process).

Substep 1.1: Identification of the subjects

Characterization of the different user roles within the application must be

performed in the first place. This is performed by studying the duties of the

users within the application and the possible grouping of these duties into a

user role that can have different sensitivities that depend on the need-to-know

of the persons playing this role.

The responsibilities of the individuals are characterized into two distinct

levels of abstraction for the development of a User Role Hierarchy (URH): user

roles and user categories. User roles allow the security designer to allow

particular privileges to individual roles. To represent similarities that exist

among user roles, a user category can be defined. Different categories can be

grouped into categories of higher level. The highest category, represented as

the root, contains all user roles. Privileges that are supplied to each role are

passed on to its categories. The grouping of user roles into user categories is

very application dependent. This step can be further divided into the following

substeps:

1. Define all the user roles that exist within an application.

2. Group the existing user roles under the corresponding user category

depending on the task of the user in the application.

3. Repeat step (2), grouping all user categories into higher category, until

reaching the root category.

As a result of these actions, the security designer obtains an initial

characterization of the URH.

10 | P a g e

Substep 1.2: Identification of the objects.

The security objects are the target of the security protection, and are in

another sense the data contained in the application. Generally, data are

characterized by high complexity and heterogeneity in both the nature and the

sensitivity levels of the different data sets included in them. Organizing these

data in a structured manner is necessary for the development of the

appropriate user views, which in its turn is a required step in the design and

implementation of the application.

Data is grouped into data sets that will be target for the labelling process

later. Data sets represent data with a common use. These data sets are

grouped into a number of data categories. A data category characterizes

common characteristics among related data sets. In turn, the different data

categories can be grouped into one or more data categories of higher levels.

Step 2: Assignment of security label (labeling process).

Since our security policy supports MAC, the reading and writing of data by

individuals is based on their authorized security clearance label. And since, the

DAC security policy is supported too, a richer set of access modes that are

specific to the particular type or category of information is granted to the

individuals based on their need-to-know requirements. For this reason, we

have first to define the security labels, assigned to users, data and sites, and

then to define the type of permitted access.

The security label has two parts: The level and the category. The category of a

user depends on his position in the User Role Hierarchy (URH). The highest

category that corresponds to the root of the URH tree contains all sub

categories and roles defined in the application. The category of data depends

on its usage and corresponds to the needs of some categories of users. The

category of a site depends on its use (what categories of users use it and what

categories of data they need to use) and on its type (whether it is standalone,

internet connected, mobile, stationary, etc).

The security levels assigned to each one of the users, data and sites are defined

after an initial study that results in a rating of the clearance of users, the

sensitivity of data and the trustworthiness of sites.

11 | P a g e

Substep 2.1: Assignment of security labels to the subjects

Having obtained an initial characterization of the user roles (URH), this substep

allows us to assign a security label to each user role starting from the root and

moving to the last level before the leaves (that form the user roles) of the tree.

More specifically:

1. Assign the category of the user role, as represented in the URH, then

2. Assign a level to the user role that represents the level part of the label.

This level depends on the trustworthiness of the user and on his/her

responsibility

By completing this substep, the security designer obtains an initial

characterization (overall structure) of the User Role Hierarchy, and a primary

assignment of labels to users.

Substep 2.2: Assignment of security labels to the objects

After the overall structure of the User Role Hierarchy (URH) has been

established, the security designer can then proceed to assign data sets to the

URH leaves which correspond to the data that needs to be accessed by the

user roles. In this process, the designer uses the information accessing

requirements as a guide for ensuring that the correct privileges are given. The

procedure is repeated until reaching the root.

This step can be sub-divided into the following substeps:

1. Assign data sets starting with the user roles under a user category.

2. Move data sets shared by all user roles to their common user category.

3. Move data sets shared by all user categories to their common super

categories. This procedure is repeated till reaching the root.

4. The label to be assigned to the data set then consists of :

• A category that corresponds to the category of the node or the leaf

already assigned in the URH.

• A level that corresponds to the lowest clearance level of the user roles

contained in the category.

5. Repeat this process for all the data sets within each user role, and then

within their user categories.

As a security check for this substep, a stand-alone classification of the

sensitivity of the data can be processed. This classification is dependent on

12 | P a g e

both the content and the context of the data. In the case where the levels

differ, the security designer must check and decide which level to assign. By

completing this substep, the designer obtains an initial identification of

privileges of each URH node and an initial label assigned to each data set.

13 | P a g e

Multilevel Database Security

The security of a single element maybe different from other elements of

the same record.The first layer corresponds to a model for a non-protected

database. The second layer corresponds to a model for a multilevel database.

In this second layer, we propose a list of theorems that must be respected in

order to build a secure multilevel database. We also propose a new solution to

manage cover stories without using the ambiguous technique of

polyinstantiation. The third layer corresponds to a model for a MultiView

database, that is, a database that provides at each security level a consistent

view of the multilevel database

In order to restrict the scope of the security related design problem, we

have made a number of assumptions about the MLS-DBMS environment and

operation. These assumptions and their consequences are discussed in this

section. (The relational data model is discussed briefly in the next section)

We have assumed that both the database and its access language conform to

the relational model of data. This provides us with a well defined, regular

language for defining the database structure and operations.

We have assumed that it is necessary to provide data classification at a fine

granularity; that is, at the tuple, attribute or even element level. We have also

assumed that the results of functions applied to sets of data may need to be

classified independently of the data itself.

We have assumed that besides simply classifying each (arbitrary) unit of data,

it will be necessary to classify data depending upon its value or content, and

also the context in which it is seen.

This need generalizes into the need to control the user’s inference of more

sensitive information from less sensitive information.

14 | P a g e

Different views to different users having different security levels

Relational Database Definitions The MLS-DBMS uses the relational data model and a query language based

upon the relational algebra.In a relational database, the data may be thought

of as being structured into tables.

The columns of a relation are referred to as attributes. The degree of a relation

is the number of attributes defined for that relation. The rows of a particular

relation (table) are referred to as tuples. The cardinality of a relation is just the

number of (unordered) tuples it contains. In a particular tuple, the field which

corresponds to a particular attribute may contain any one of the values in the

domain of that attribute.

15 | P a g e

Relational Algebra

The five basic relational operators are:

1. Selection - The selection operator constructs a horizontal subset of a

relation. The result of the selection operation is the subset of tuples

within a relation, R, for which a specified predicate, P, is true.

2. Projection - The projection operator constructs a vertical subset of a

relation. The result of the projection operation is the subset of R

obtained by selecting specified attributes (A), and eliminating others

(and also eliminating duplicate tuples within the attributes selected).

3. Union - The union of two relations of the same degree, R and S, is the

set of tuples that are in R or S or both.

4. Set difference - The difference of two relations of the same degree, R

and S, is the set of tuples in R but not in S.

5. Cartesian product - The Cartesian product of tworelations of degree m

and n, R and S, is the set of (m x n)-tuples whose first m attributes form a

tuple in R and whose last n attributes form a tuple in S.

6. Intersection - The intersection of two relations of the same degree, R

and S, is the set of tuples in both R and S.

7. Join - The join of R and S is those tuples in the Cartesian product of R and

S for which a specified join predicate, jp, is true.

“View” Operation of a Multilevel Security System

Apply projection,thenselection.Do this for another tuple. Then do join

operation of these sets.

Tuple granularity : Deletion

Column granularity : Projection

Join : Cartesian product followed by intersection

16 | P a g e

The different types of information in a Multilevel Security System

Schema format for a Multilevel Security System

Schema R(A1,C1,…,An,Cn,Tc)

• R : relation name

• Ai : attribute name

• Ci : attribute security class

• Tc : Tuple security classes

17 | P a g e

Granularity

• Database: Different security levels are assigned to different database.

Users having varied security levels are allowed only to access the

granted database.

• Tuple: Tuples are assigned different sensitivity levels of security. A user

having a security level ‘x’ is allowed to access a tuple with security level y

if ‘x>=y’.

• Attribute: Attributes are assigned different sensitivity levels of security.

A user having a security level ‘x’ is allowed to access an attribute with

security level ‘y’ if ‘x>=y’.

• Element: By using granularity on tuples as well as elements, we are able

to achieve elemental level of granularity. A user with security level ‘x’

can see an element if he is able to access the corresponding tuple as well

as the attribute. That is, we have to pass through both the tuple level as

well as the attribute level security to access an element.

Tuple and attribute granularity

18 | P a g e

Working Principle

Bell – LaPadula Model

Throughout the 1970s and 1980s, significant energy was exerted to address

the problem of malicious and flawed software. The goal was to achieve MAC,

where the basis of access control decisions was not at the discretion of

individual users or even system administrators. We wanted to implement

an organizational security policy to control access to objects that could not be

affected by the actions of individual programs. The military funded most of this

work, which focused on protecting the confidentiality of classified government

data. In particular, the most common MAC mechanisms implemented to date

address the problem of multilevel security, a simplified form of which is shown

in Figure

Multilevel security (MLS) is typically based on a formal model called the Bell-

La-Padula model . In the MLS model, all subjects and objects are labelled with

a security level. In our example, we have a PUBLIC and a SECRET sensitivity

level. The levels represent the relative sensitivity of the data and the clearance

of the user on whose behalf the subjects are operating (SECRET being data of

"higher" sensitivity than PUBLIC). In MLS, subjects can always read and write

objects at the same sensitivity. In addition, subjects can read lower-level

objects ("read down") and write higher-level objects ("write up"). However, a

19 | P a g e

subject may never read higher-level objects ("no read up") nor write lower-

level objects ("no write down"). The idea being that information can flow from

lower levels to higher levels, but not the reverse, thereby protecting the

confidentiality of the higher-level data.

Unidirectional data flow

The Bell-LaPadula model is built on the state machine concept. This concept

defines a set of allowable states ( A i ) in a system. The transition from one

state to another upon receipt of input(s) ( X j ) is defined by transition functions

( f k ). The objective of this model is to ensure that the initial state is secure and

that the transitions always result in a secure state. The transitions between

two states are illustrated in Figure 5-9.

Figure 5.9: State transitions defined by the function f with an input X.

20 | P a g e

The Bell-LaPadula model defines a secure state through three multilevel

properties. The first two properties implement mandatory access control, and

the third one permits discretionary access control. These properties are

defined as follows:

1. The Simple Security Property (ss Property): States that reading of

information by a subject at a lower sensitivity level from an object at a

higher sensitivity level is not permitted (no read up). In formal terms,

this property states that a subject can read an object only if the access

class of the subject dominates the access class of the object. Thus, a

subject can read an object only if the subject is at a higher sensitivity

level than the object.

2. The * (star) Security Property: States that writing of information by a

subject at a higher level of sensitivity to an object at a lower level of

sensitivity is not permitted (no write-down). Formally stated, under *

property constraints, a subject can write to an object only if the access

class of the object dominates the access class of the subject. In other

words, a subject at a lower sensitivity level can write only to an object at

a higher sensitivity level.

3. The Discretionary Security Property: Uses an access matrix to specify

discretionary access control.

21 | P a g e

Implementation

Our implementation has three different types of user

• Manager

• Employee

• Public user

Our implementation of a multilevel security system, has 3 basic functionalities

• See database with a certain privilege

• Delete a tuple with a certain privilege

• Insert a tuple with a certain privilege

See/ViewDatabases • After a user logs in, fetch security status according to login ID

• According to login ID, use CURSOR to project necessary attributes which

should be visible to the appropriate security level

• SELECT the tuples which have security level equal to or lesser than the

security of the logged in person

Delete Tuple • If the logged in person is a manager, then and only then can the person

delete a record

Insert Tuple • If the logged in person is a manager or an employee, then and only then

can the person insert a tuple

• For an employee, certain attributes are mandatory but not visible to the

security level of an employee. We have taken care of such attributes by

setting them up as a function of user ID

22 | P a g e

Limitations

• For every query, the security level of every element needs to be checked

with the security level of the user. Hence, the process is a bit slow

• Care has to be taken for some special conditions which might arise

during “write up” operations

23 | P a g e

Area of Use

• Banking- High level manager can see all data of all customers. Branch

manager may see data of all customers in his/her branch. A customer

can see only his data. An external audit agency may be allowed to see

only final balance of all customers.

• Defence- Higher authority can access top secret data. Mid level users

can see those data which has been granted by higher authority.

Outsiders are not allowed to access any data.

• Office- Manager may access entire database. Ordinary users are allowed

to access only a part of it. And publics who use the product of the

company are allowed to see minimal information.

• Public/Private Database systems- For database containing both public

information (not at all sensitive) and private information (if leaked to

outsiders will cause trouble) multilevel security is mandatory.

24 | P a g e

Conclusion

This form of gradation of security has tremendous potential and is

already being used by major companies and organization where information

is accessed by both public users and members of the organization. However,

it increases the minimum required hardware compared to a basic relational

DBMS in order to calculate the extra security levels if we want to maintain

the same order of efficiency.

But since server hardware quality is increasing and cost per unit is

decreasing, it is advisable for mid-tier to high-tier organizations to switch to

this technology so save much hassle in the future regarding security.

Multilevel security can be used in several areas in future. For instance, this

concept may be implemented in the setop box of a TV. Before a person

wants to view a TV program his/her age group is asked. Depending upon

age group only appropriate programmes are allowed and the rest are

discarded from the total set of channels which is being accessible to the

setop box.

Similar use can be used in online library. Depending upon age group and

geographical locations books are filtered before being shown to the

customer. A customer may not be allowed to read a book being banned by

the government whereas the server is located outside the country.

Search engines may filter search results like information on drugs, weapons

for all age groups. But it may or may not allow contents on topics like

violence, war depending upon age group. Whereas it may allow all results

to defence or police use. Google earth blurs out areas sensitive to defence

like map of Whitehouse to public whereas a for a top military official no ban

is applied.

In our project due to lack of time several functionalities are not

implemented like updation function, use of a suitable interface at the front

end with sql engine at back end.

25 | P a g e

References:

• Wikipedia.org

• J. McLean, “A General Theory of Composition for Trace Sets Closed

under Selective Interleaving Functions,” Proceedings of 1994 IEEE

Symposium on Research in Security and Privacy (IEEE Press, 1994), pp.

79–93.

• Multilevel Security Issues in Distributed Database Management

Systems II BhavaniThuraisingham

26 | P a g e

Appendix

Different views to different users having different security levels

27 | P a g e

MAIN FUNCTION (Written in PL/SQL, tested in Oracle 9i)

------------------------------------------ -- -- -- . : FINAL YEAR PROJECT : . -- -- -- -- DISTRIBUTED SECURITY SYSTEM -- -- -- -- BY -- -- -- -- SUMITRO BHAUMIK ... 11 -- -- JYOTISHKAR DEY ... 36 -- -- -- ------------------------------------------ DECLARE l_privilegesecurity.val%TYPE; l_idinfo.id%TYPE; l_nameinfo.name%TYPE; l_telinfo.tel%TYPE; l_dobinfo.dob%TYPE; l_mailinfo.mail%TYPE; l_passwordinfo.password%TYPE; l_desinfo.designation%TYPE; l_temp number; l_option number; login_idinfo.id%TYPE; login_passwordinfo.password%TYPE; -- FOR INSERTING NEW TUPLES l_id_newinfo.id%TYPE; l_count integer; l_name_newinfo.name%TYPE; l_tel_newinfo.tel%TYPE; l_dob_newinfo.dob%TYPE; l_mail_newinfo.mail%TYPE; l_password_newinfo.password%TYPE; l_des_newinfo.designation%TYPE; --Selects rows of Manager CURSOR view_manager IS SELECT id FROM info WHERE Designation='Manager' OR Designation='Employee' OR Designation='Public'; --Selects rows of Employee CURSOR view_employee IS SELECT id FROM info WHERE Designation='Employee' OR Designation='Public'; --Selects rows of Public CURSOR view_public IS SELECT id FROM info WHERE Designation='Public'; ----------------------------------------------

28 | P a g e

-- -- -- . : FUNCTION see : . -- -- IT SELECTIVELY DISPLAYS THE DATABASE -- -- ACCORDING TO HIS OR HER SECURITY LEVEL -- -- -- ---------------------------------------------- FUNCTION see(l_privilege IN number) RETURN number IS z number; BEGIN --1 for manager, 2 for employee, 3 for public CASE l_privilege WHEN 1 THEN DBMS_OUTPUT.PUT_LINE('------------------------------------------------------------------------------------------'); DBMS_OUTPUT.PUT_LINE(rpad('ID',3)||rpad('NAME',20)||rpad('TELEPHONE',12)||rpad('DOB',12)||rpad('MAIL',25)||rpad('DESIGNATION',20)); DBMS_OUTPUT.PUT_LINE('------------------------------------------------------------------------------------------'); FOR iter_man IN view_manager LOOP SELECT id,Name,Tel,DOB,Mail,Designation INTO l_id,l_name,l_tel,l_dob,l_mail,l_des FROM info WHERE id=iter_man.id; DBMS_OUTPUT.PUT_LINE(rpad(l_id,3)||rpad(l_name,20)||rpad(l_tel,12)||rpad(l_dob,12)||rpad(l_mail,25)||rpad(l_des,20)); END LOOP; WHEN 2 THEN DBMS_OUTPUT.PUT_LINE('------------------------------------------------------------------------'); DBMS_OUTPUT.PUT_LINE(rpad('NAME',20)||rpad('DOB',12)||rpad('MAIL',25)||rpad('DESIGNATION',20)); DBMS_OUTPUT.PUT_LINE('------------------------------------------------------------------------'); FOR iter_emp IN view_employee LOOP SELECT Name,DOB,Mail,Designation INTO l_name,l_dob,l_mail,l_des FROM info WHERE id=iter_emp.id; DBMS_OUTPUT.PUT_LINE(rpad(l_name,20)||rpad(l_dob,12)||rpad(l_mail,25)||rpad(l_des,20)); END LOOP; WHEN 3 THEN DBMS_OUTPUT.PUT_LINE('--------------------------------------'); DBMS_OUTPUT.PUT_LINE(rpad('NAME',20)||rpad('DESIGNATION',20)); DBMS_OUTPUT.PUT_LINE('--------------------------------------'); FOR iter_pub IN view_public LOOP

29 | P a g e

SELECT Name,Designation INTO l_name,l_des FROM info WHERE id=iter_pub.id; DBMS_OUTPUT.PUT_LINE(rpad(l_name,20)||rpad(l_des,20)); END LOOP; END CASE; RETURN z; END; ------------------------------------------ -- -- -- . : FUNCTION del_tuple : . -- -- ALLOWS A PERSON TO DELETE A TUPLE -- -- IF HE OR SHE HAS THE PERMISSION -- -- -- ------------------------------------------ FUNCTION del_tuple(l_privilege IN number) RETURN number IS del_id number; BEGIN IF l_privilege> 1 THEN DBMS_OUTPUT.PUT_LINE('SORRY! YOU DONT HAVE PERMISSION TO DELETE'); ELSE DBMS_OUTPUT.PUT_LINE('ENTER THE ID OF THE PERSON YOU WANT DELETE'); del_id := &del_id; DELETE FROM info WHERE id = del_id; END IF; RETURN del_id; END; ------------------------------------------ -- -- -- . : FUNCTION insert_tuple : -- -- ALLOWS A PERSON TO INSERT A TUPLE -- -- -- ------------------------------------------ FUNCTION insert_tuple(l_privilege IN number) RETURN number IS insert_tuple number; BEGIN --Public are not allowed to inset IF l_privilege = 3 THEN DBMS_OUTPUT.PUT_LINE('PUBLIC USERS ARE NOT ALLOWED TO ENTER!'); --If not public ELSE SELECT max(id) INTO l_id_new FROM info; l_id_new :=l_id_new +1; l_password_new :=l_id_new; DBMS_OUTPUT.PUT_LINE(' ENTER NAME, DATE OF BIRTH, DESIGNATION AND MAIL ADDRESS'); l_name_new :='&l_name_new';

30 | P a g e

l_dob_new :=TO_DATE('&l_dob_new', 'DD.MM.YYYY'); l_des_new :='&l_des_new'; l_mail_new :='&l_mail_new'; DBMS_OUTPUT.PUT_LINE('NEW ID :'||l_id_new); DBMS_OUTPUT.PUT_LINE('NEW PASS :'||l_password_new); DBMS_OUTPUT.PUT_LINE('NEW NAME :'||l_name_new); DBMS_OUTPUT.PUT_LINE('NEW DOB :'||l_dob_new); DBMS_OUTPUT.PUT_LINE('NEW DES :'||l_des_new); --If manager IF l_privilege = 1 THEN DBMS_OUTPUT.PUT_LINE(' ENTER TELEPHONE'); l_tel_new :=&l_tel_new; INSERT INTO info VALUES(l_id_new,l_name_new,l_tel_new,l_dob_new ,l_mail_new,l_des_new,l_password_new); DBMS_OUTPUT.PUT_LINE('NEW TEL :'||l_tel_new); --If Employee ELSE INSERT INTO info VALUES(l_id_new,l_name_new,NULL,l_dob_new ,l_mail_new,l_des_new,l_password_new); END IF; END IF; RETURN insert_tuple; END; ---------------------------- -- -- -- . : MAIN SECTION : . -- -- -- ---------------------------- BEGIN DBMS_OUTPUT.PUT_LINE('ENTER USERNAME AND PASSWORD'); login_id := &login_id; login_password := '&login_password'; SELECT designation INTO l_des FROM info WHERE info.id=login_id; SELECT val INTO l_privilege FROM security WHERE designation=l_des; DBMS_OUTPUT.PUT_LINE('ENTER 1 TO VIEW'); DBMS_OUTPUT.PUT_LINE('ENTER 2 TO DELETE'); DBMS_OUTPUT.PUT_LINE('ENTER 3 TO INSERT'); l_option := &l_option; CASE l_option

31 | P a g e

WHEN 1 THEN l_temp := see(l_privilege); WHEN 2 THEN l_temp := del_tuple(l_privilege); WHEN 3 THEN l_temp := insert_tuple(l_privilege); END CASE; EXCEPTION WHEN no_data_found THEN DBMS_OUTPUT.PUT_LINE('NO SUCH RECORD ... INVALID INPUT!'); END; /

DDL STATEMENTS

INFO TABLE:: CREATE TABLE info (

id integer primary key, name Varchar2(20) NOT NULL, tel Number(10), dob DATE NOT NULL, mail Varchar2(30), designation Varchar2(20) NOT NULL, password Varchar2(20) NOT NULL

);

SECURITY TABLE:: CREATE TABLE security (

designation Varchar2(20) NOT NULL, val integer NOT NULL, CONSTRAINT uc_value UNIQUE (val)

);