Distributed database security with discretionary access control.. This was my my final year project. This is based on Bell Lapadula model

1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 26 | P a g e
Appendix
Different views to different users having different security levels

27. 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. 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)||r
pad('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. 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. 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. 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)
);