Database Design &

Management (II)
Lecturer: Isaac Baffour Senkyire
Review of DB Design &
Management (I)
Database
• Shared collection of logically related data (and a description of this
data), designed to meet the information needs of an organization
or is a system which holds data as an integrated system of records
and metadata, or data about data/descriptions of the data held in
the database.

• Logically related data comprises

entities,
attributes, relationships and constraints
of an organization’s information.
Database Management System
(DBMS)
• A software system that enables users to define, create, maintain, and
control access to the DB
ANSI-SPARC Three-Level
Architecture
ANSI-SPARC Three-Level
Architecture
• External Level
• Users’ view of the database.
• Describes that part of database that is relevant to a particular
user.

• Conceptual Level
• Community view of the database.
• Describes what data is stored in database and relationships
among the data.
ANSI-SPARC Three-Level
Architecture
• Internal Level
• Physical representation of the database on the
computer.
• Describes how the data is stored in the database.
 Database
Administration
DB Administrator
• A Database Administrator (DBA) is a person (or group of people)
who controls the day to day running of the database and provides
technical support for users in ensuring that the database is used
efficiently and correctly.
Functions of a DB Administrator
• Defining the database
• Liaising with users
• Defining & Monitoring
• security & integrity checks
• backup & recovery procedures
• Monitoring performance
• Responding to change
Functions of a DB Administrator
• Defining the database
• Definitions of the DB Schema from the logical DB design
• Mapping the model onto the storage
• Liaising with users
• Defining the user’s view of the data
• Assistance with application design
• Technical education
Functions of a DB Administrator
• Security Checks
• Enrolling new users
• Defining their level of access
• Integrity Checks
• Usually defined within the data definition of the
schema/subschema
• Often relies on the data dictionary
• Backup Procedures
• Definition of measures to ensure the safety of the DB
• Ensuring that these procedures are carried out
Functions of a DB Administrator
• Recovery Procedures
• Definition of procedures to be carried out in the event of failure
• Testing of these procedures to make sure they will work if/when
needed
• Monitoring Performance
• Dealing with problems - use of tools e.g. Oracle Enterprise Manager
• Looking at the way that the various users of the DB are being serviced
• Educating users in ways to use the DB more efficiently
• Changing the logical/physical structure of the DB to enhance
performance
Functions of a DB Administrator
• Responding to Changes
• New users
• New user requirements
• Software/hardware enhancements
Use of Tools
• Many modern DB environments are very complex, often using
multiple databases. It therefore becomes essential to make use of
tools to carry out the job of Database administration
• Oracle Enterprise Manager
Alternative Definitions
• Data Administration: A high-level function that is responsible for
the overall management of data resources in an organization,
including maintaining corporate-wide definitions and standards
• Database Administration: A technical function that is
responsible for physical database design and for dealing with
technical issues such as security enforcement, database
performance, and backup and recovery
Data Administration Functions
• Data policies, procedures, standards
• Planning
• Data conflict (ownership) resolution
• Internal marketing of DA concepts
• Managing the data repository
Database Administration
Functions
• Selection of hardware and software
• Installing/upgrading DBMS
• Tuning database performance
• Improving query processing performance
• Managing data security, privacy, and integrity
• Data backup and recovery
Data Warehouse Administration
• New role, coming with the growth in data warehouses
• Similar to DA/DBA roles
• Emphasis on integration and coordination of metadata/data across
many data sources
• Specific roles:
• Support decision –support applications
• Manage data warehouse growth
• Establish service level agreements regarding data warehouses and data marts
 Database
architecture
The Three Level Architecture
Database architecture
The architecture of a database determines its capability of meeting
user requirements reliably, effectively and efficiently
The 3 schema approach
Based on assumptions that
• Computers and users need to be able to view the same data in different ways
• Different users need to be able to view the same data in different ways
• It is desirable for users and computers to change the way they view data
independently
• it is undesirable for the computer to dictate or constrain the way that users view
the data
Views of data
Two different kinds of view of data
• user views (external views)
defined by external schemas
• implementation view (internal view)
defined by an internal schema
Schemas contain information about the view, not data in the view
Mappings between schemas
To allow users to access data there must be mappings between
external and internal schemas
Direct mappings
Each external schema could be mapped directly to the internal schema

User User User external

1 2 3 levels
mappings
internal
Internal Schema
level

This does not however provide much data independence

The 3 schema approach
A neutral integrated view of the data is inserted between the external
and internal levels.
This level is the conceptual view

User mappings mapping

1 Conceptual Internal
Schema Schema
User
2
external conceptual internal
level level level
A simple example
A personnel DB with 2 users, one an access application program, the other a ‘C’ application program
Conceptual schema
Employee
EmployeeNumber Character (6)
DepartmentNumber Character (4)
Salary Numeric (5)
Internal schema
StoredEmp Length = 18
Prefix Type=Byte(6), Offset=0
Emp# Type=Byte(6), Offset=6, Index=EmpX
Dept# Type=Byte(4), Offset=12
Pay Type=Fullword, Offset=16
A simple example (continued)

Access
external
schema
A simple example (continued)

‘C’ external schema

struct Employee {
char EmpNum [6];
int Sal;
};
The external level
(the user level)
• Each external view includes multiple occurrences of multiple types of
external record
• A user will either be an application program(mer) or a terminal (end)
user
• Each user has a language at their disposal
Accessing the external level
• Application programmer
• a conventional programming language (eg ‘C’)
• with special DB language embedded in it
• End user
• a query language or special purpose language tailored to the users
requirements
• very high level language
DB Languages
• DBMS Languages: After the DB design is completed the conceptual
and internal schemas of the DB must be mapped
• In many DBMSs where no strict separation of levels is maintained,
one language (data definition language – DDL) is used by the DBA
and DB designer to define both schemas.
• DBMS has a DDL compiler – it processes DDL statements in order to
identify descriptions of the schema constructs and to store the
schema description in the DBMS catalog
DB Languages
• In DBMSs where conceptual and internal levels are separated, DDL is
used to specify only the conceptual schema
• Storage definition language (SDL) is used to specify only the internal
schema.
• In a true 3-schema architecture, a 3rd language is needed. View
definition language (VDL) it is used to specify user views and their
mapping to the conceptual schema.
• Note: In most DBMSs, the DDL is used to define both conceptual and
external schemas
DB Languages
• To use a populated DB, one need a data manipulation language (DML) to
retrieve, insert, delete, and or modify data
• Current DBMSs uses comprehensive integrated language – Structured
Querying Language (SQL): which includes constructs for
• Conceptual schema definition DDL
• View definition VDL
• Data manipulation DML
• The storge definition is kept separated so the fine-tuning of the
performance will be made easier.
• SQL no longer includes storage definition language (SDL) to include
conceptual and external levels only.
DB Languages
• There are 2 types of DML
• High-level (nonprocedural DML)
• Low-level (procedural DML)
• High-level DMS: can be used on its own to specify complex operations in a
concise manner. SQL is an example
• In most DBMSs, statements are entered interactively from a terminal or by
embedding them in a general-purpose code.
• In a general-purpose code: the DML part is identified within the program so
that it can be extracted by the compiler
• A query in high-level DML means which data to retrieve rather than how to
retrieve it.
DB Languages
• Low-level DML: must be embedded in a general-purpose
programming language.
• This type of DML typically retrieve individual records or objects from
the DB and process each separately.
• The low-level DML needs to use programming language constructs,
such as looping, to retrieve and process each record from a set of
records
• sometimes DML commands, high or low-level are embedded in a host
language and the DML is called the data sublanguage.
Data Sublanguage (DSL)
• A DSL is a subset of the language concerned specifically with DB
objects and operations
• The DSL is said to be embedded in the host language
• The host language is responsible for non-DB facilities
DDL and DML
The DSL contains 2 sublanguages:
• Data definition language (DDL)
For designing and describing DB objects

• Data manipulation language (DML)

Supports processing and manipulation of DB objects
The conceptual level
• The conceptual view includes multiple occurrences of multiple
types of conceptual record
• Represents entire information content of the DB
• Does not include considerations of storage structure or access
strategy
• Written using a conceptual DDL
The internal level
• The internal view includes multiple occurrences of multiple types of
internal (stored) records
• Note that external and internal records are not the same
• In general, each external record may be constructed from many
internal records
The internal level (continued)

• The internal view is described by an internal schema which

• defines the various types of internal record
• specifies which indexes exist
• specifies how stored attribute values are represented
• what physical sequence the stored records are in
• Written using an internal DDL
Definitions
(from Connolly and Begg)
• External level – The users’ view of the database. This level describes that part of
the database that is relevant to each user
• Conceptual level – The community view of the database. This level describes
what data is stored in the database and the relationships among the data
• Internal level – The physical representation of the database on the computer.
This level describes how the data is stored
Database Security
Objectives
• The meaning of database security
• How security protects privacy and confidentiality
• Examples of accidental or deliberate threats to security
• Some database security measures
• The meaning of user authentication
• The meaning of authorization
• How access control can be represented
• How the view functions as a security device
Objectives
• The purpose of the security log and audit trail
• How and why data encryption is performed
• How to protect databases against SQL injection
• How security is enforced in some systems
• How internet security is implemented
Database Security Issues
• Database Security: involves protecting the database from unauthorized access,
modification, or destruction.
• In addition to the need to preserve and protect data for the smooth functioning of the
organization, DB designers must protect the privacy of individuals about whom data is
kept.
• Privacy: is the right of individuals to have some control over information about
themselves.
• Confidentiality: requires that only authorized users have access to information in
order to preserve the privacy of individuals, business intellectual property, and
national security efforts.
Database Security Issues
• Integrity: requires that only authorized users be allowed to modify data.
Question: what will this seek to achieve?
• Availability: requires that information be accessible by authorized users when
needed.
Database Security Issues
• Laws and standards requiring controls on access, disclosure, and modification of
sensitive data are:
• Data Protection Act, 2012 – Ghana
• The Federal Information Security Management Act (FISMA)
• The European General Data Protection Regulation (GDPR)
• The U.S Health Insurance Portability and Accountability Act (HIPAA)
• The U.S. Sarbanes-Oxley (SOX) Act
• The Worldwide Payment Card Industry Data Security Standard (PCI DSS)
Database Security Issues
• Security threats: are events or situations that could harm the system by compromising
privacy or confidentiality, or by damaging the database itself.
• Vulnerability: is a weakness in a system, such as an inappropriate access control or
loopholes in firewall protection, that allows a threat to occur.
• Threats to the DB
• Unauthorized modification: changing data values for reasons of sabotage, crime or
ignorance which may be enabled by inadequate security mechanisms, or sharing of
passwords or password guessing.
• Unauthorized disclosure: when information that should not have been disclosed has been
disclosed. A general issue of crucial importance, which can be accidental or deliberate.
Database Security Issues
• Threats to the DB
• Loss of availability: sometimes called denial of service. When the DB is not available it
incurs a loss. So any threat that gives rise to time offline, even to check whether
something has occurred, is to be avoided.
• Categories of specific regulatory threats to DB Systems:
• Commercial sensitivity: most financial losses through fraud arise from employees. Access
controls provide both protection against criminal acts and evidence of attempts
(successful or otherwise) to carry out acts detrimental to the organization
• Personal privacy and data protection: example the postal code of the home of a person
who lives alone should be protected
Database Security Issues
• Categories of specific regulatory threats to DB Systems:
• Computer misuse: there are legislation on the misuse of computers.
• Misuse includes: violation of access controls and attempts to cause damage by changing
the DB state or introducing worms and viruses to interfere with proper operation
• Audit Requirements: these are operational constraints built around the need to
know who did what, who tried to do what, and were and when everything
happened.
Database Security Issues
• Security threats can occur either accidentally or deliberately.
• Accidental Security Threats:
• A person may accidentally be sent a message that should be directed to another user, resulting in
unauthorized disclosure of database contents.
Accidental Security Threats:
• The OS might accidentally overwrite files and destroy part of the database, fetch the wrong files,
and then inadvertently sent them to the user, or it might fail to erase files that should be destroyed.
• The user may unintentionally request an object or an operation for which he or she should not be
authorized, and the request could be granted because of an oversite in authorization procedures or
because of an error in the database management system or OS.
Database Security Issues
• Deliberate Security Threats: deliberate security violations occur when a user intentionally gains
unauthorized access and/or performs unauthorized operations on the database.
• Wiretapping of communication lines to intercept messages to and from the database
• Electronic eavesdropping, to pick up signals from workstations, printers, or other devices within a
building
• Impersonating an authorized user, or a user with greater access, by using his or her log-in and
password
• Writing systems programs with illegal code to bypass the DBMS and its authorization mechanism,
and to access DB data directly through the OS.
• Modifying DB queries through SQL injection to gain unauthorized access to data or to maliciously
modify or delete data.
Fundamentals of Access Control
Access control mechanisms regulate who can access which data. It supports
confidentiality and integrity.
•Access control must be addressed in the context of physical security as well as
information system access control.
•To protect the information system, the database administrator is responsible for the
following major tasks:
•Installing the database management system and configuring it securely
•Creating and securing user accounts and developing appropriate access controls for users
•Developing and enforcing standards for applications programs that access the database
Fundamentals of Access Control
• Encrypting sensitive data
• Ensuring that network connections to the data are secure
• Establishing appropriate audit mechanisms for the database
• Protecting the database against intruders by identifying and guarding against
security threats and applying security controls and security updates as needed.
Fundamentals of Access Control
• Physical Security
• Access control plan begins with physical security measures for the: Building
itself, with special precautions for the computer facilities.
• The DBA should be able to suggest measures that would control access to the
database facilities – it often begins with the front door, where all employees
must be identified.
• Physical security measures should be extended to cover any location where
offline data, such as backups are stored as well.
Fundamentals of Access Control
• Information System Access Control
• Involves: authorization, identification, authentication, and accountability.
• Authorization: requires defining who has access to the system and the specific
data they are allowed to access.
• Identification: refers to the way in which users are identified. Example: user ID,
database ID, smart cards, Biometrics – fingerprints, handprints, face
recognition, voice recognition, and retina scans
• Authentication: is the process of verifying the identity of a user – checking to
ensure that the actual user is who he or she claims to be.
Fundamentals of Access Control

Information System Access Control

•Accountability: refers to the need to capture and maintain log files that can be
used for traceability when security incidents occur.
Database Access Control
Database Access Control:
•Is the process of making sure that data or other resources are
accessed only in authorized ways.
•4 Categories of access control mechanisms: discretionary access
control (DAC) - obsolete, role-based access control (RBAC) – most
common method today, and mandatory access control (MAC) –
obsolete, and Attribute based access control (ABAC) – the most recent
model
 DATABASE ACCESS CONTROL
• Discretionary Access Control Mechanisms (DAC): Govern access to data
based on the identity of the subject and authorization rules. It allows
subjects to grant access to data to other subjects.
Database Access Control
• Access control matrix is a typical access control mechanism that
lends itself well to the discretionary access control.
• Access control matrix: is a table that states a subject’s access rights
on an object.
Database Access Control

• The column headings represent database objects; names of tables, views,

data items, objects, modules, or other categories, depending on the DB
model and management system used.
• The row labels represent individuals, roles, groups of users, or applications
• Cell entries specify the type of access permitted: READ, INSERT, UPDATE,
DELETE, EXECUTE, CREATE, and others
DATABASE ACCESS CONTROL
• ROLE-BASED ACCESS CONTROL (RBAC): introduces roles and assign
privileges to the roles instead of directly to users.
DATABASE ACCESS CONTRL
• Most role – based access control models also include the concept of
role hierarchies, allowing to express role-subrole relationships.
• This allows for authorization inheritance and separation of duty
(SOD) constraints which prevents a subject from receiving too many
authorizations.
• Limiting the amount of authorizations mitigates the impacts of an
attack directed at a particular subject.
• Separation of duty; static SOD AND Dynamic SOD
• Static sod constraints: impose limits on role intersections and the
number of users that can be assigned to a particular role
DATABASE ACCESS CONTRL
• DYNAMIC SOD CONSTRAINTS: are based on the notion of sessions.
A session is a set of accesses performed by a user under one or more
roles.
• Dynamic sod restricts access to roles based on the history of the
user’s role usage during the current or previous sessions.
• Mandatory access control mechanisms (MAC): determines access
to data based on classifications of subjects and objects.
• the classification defines a partially ordered set of access classes (or
labels, security classes). The labels, are assigned to each subject and
object in the system.
• The classification of a data object is related to its sensitivity.
DATABASE ACCESS CONTRL
• Bell-lapadula model is an example of mac model: to illustrate this
model, consider a security classification with the 4 security levels:
top secret (ts), secret (S), confidential (c), and unclassified (u).
• These classes are given the order ts > s > c > u.
• 2 restrictions are enforced in the bell-lapadula model: no read – up,
and no write – down.
• No read – up: a subject can only read objects if class (subject) >=
class (object). Thus a subject with the classification secret (s) can
only access objects classified as secret (s), confidential (c) and
unclassified (u). This is also known as the simple security property
DATABASE ACCESS CONTRL
• NO WRITE – DOWN: a subject can only write objects if class
(subject) <= class (object). thus a subject with access classification
secret (s) can only write objects with the access classification secret
(s) and top secret (ts).
• THIS IS ALSO KNOWN AS THE STAR PROPERTY.
DATABASE ACCESS CONTRL
• ATTRIBUTE BASED ACCESS CONTROL (ABAC)
• In ABAC – resources and users are allocated series of attributes. This
is a dynamic method where user’s attributes ( time of day, position
and location) are used to effect decision on access to a resource.
Using Views for Access Control
• View is a widely used method for implementing access control in database
applications.
• The view mechanism:
• Simplifies and customizes the external model through which the user deals with
the database
• Is a security device – that hides structures and data that the user should not see
• By specifying restrictions in the WHERE line of the SELECT statement used to
create views, the view can be made value-dependent.
Using Views for Access Control
• Value-Dependent View

• Value-Independent view
Security Logs and Audit Trails
• Security log: is a journal that keeps a record of all attempted security violations.
• The violation can be recorded in the log or it can trigger an immediate message to the
system operator or to the DBA.
• Audit trails is necessary to set up if the DBA suspects that data is being compromised
without triggering security log entries.
• Triggers: can also be used to set up an audit trail for a table, recording all changes, the
time they were made, and the identity of the user.
• Example: in Oracle – to monitor changes to say grade in the ENROLL table, we could 1 st
set up a table to hold the audit records.
Security Logs and Audit Trails
• The schema for that table might be:
EnrollAudit (dateandTimeOfUpdate, userId, oldStuId, oldClassNo, oldGrade,
newGrade)
• The trigger should insert a record in the ENROLLAUDIT table when a user tries
to update a grade in the ENROLL table.
Encryption
• Encryption requires a cipher system, which consists of the
following components:
• Encryption algorithm: which takes the normal text (plaintext) as
input, performs some operations on it, and produces the
encrypted text (ciphertext) as output.
• Encryption Key: which is part of the input for the encrypting
algorithm and is chosen from a very large set of possible keys.
• Decrypting Algorithm: which operates on the ciphertext as input
and produces the plaintext as output.
• Decryption key: which is part of the input for the decrypting
algorithm and is chosen from a very large set of possible keys
Encryption
• Symmetric Key Encryption: is a from of encryption where the
decryption key is the same as the encryption key, and the
decrypting algorithm is the inverse of the encrypting algorithm.
• Example: Data Encryption Standard (DES), Advanced Encryption
Standard (AES)
• Public – Key Encryption/Asymmetric Encryption: uses 2 separate
keys, where one is a public key and the other is a private key.
• The public key is shared freely – so that anyone wishing to send a
message to a user can find his or her public key easily
• The key is then used as input to an encryption algorithm, which
produces the ciphertext for that user
Encryption
• When the user receives an encrypted message, he or she must
produce the prime factors of the public key to decode it.
• One well – known method of public – key encryption is RSA,
named for its developers, Rivest, Shamir, and Adleman.
• DES Encryption
• Public-key Encryption
SQL Data Control Language
• The Data Control Language of SQL is its authorization sublanguage, it
includes statements to grant privileges to and revoke privileges from
users.
• Privilege: is an action, such as creating, executing, reading, updating,
or deleting, that a user is permitted to perform on database objects.
• Statement for granting privileges:
GRANT {ALL PRIVILEGES | privilege – list}
ON {object - name}
TO {PUBLIC | user – list | role – list} [WITH GRANT OPTION];
SQL Data Control Language
• Possible privileges for base tables are: SELECT, DELETE, INSERT,
UPDATE, or REFERENCES (col – name).
• GRANT UPDATE ON Student (major) TO U101;
• Note: the UPDATE privilege can be made more restrictive by
specifying a column list in parentheses, (example above)
• The REFERENCES privilege is applied to columns that may be used as
foreign keys.
• This privilege allows the user to refer to those columns in creating
foreign key integrity constraints.
SQL Data Control Language
• GRANT REFERENCES (stuId) ON Student TO U101;
• The user list in the TO clause can include a single, several or all users
(the public).
• The optional WITH GRANT OPTION clause gives the newly
authorized user(s) permission to pass the same privilege to others,
example;
• GRANT SELECT, INSERT, UPDATE ON Student TO U101, U102, U103
WITH GRANT OPTION;
• Users U101, U102, U103 would then be permited to write SQL
SELECT, INSERT, and UPDATE statements for the Student table, and
to pass that permission on to other users.
SQL Data Control Language
• Authorization graph or grant diagram is used to keep track of
authorizations.
SQL Data Control Language
• SQL DCL includes the capability to create user roles.
• Role: set of operations that should be performed by an individual or
a group of individuals as part of a job.
1.Create a role
2.Give a grant privilege to a role
3.Assign a role to a user
• CREATE ROLE AdvisorRole; or CREATE ROLE FacultyRole;
• GRANT SELECT ON Student TO AdvisorRole;
• GRANT AdvisorRole to U999
SQL Data Control Language
• SQL DCL statements to remove privileges has this form:
REVOKE {ALL PRIVILEGES | privilege – list}
ON object – list
FROM {PUBLIC | user – list | role – list};
[CASCADE | RESTRICT];
Statistical DB Security
• Statistical DBs are designed to provide data to support statistical
analysis on populations.
• The data itself may contain facts about individuals, but the data is
not meant to be retrieved on an individual basis.
• Users are granted permission to access statistical information such
as totals, counts, or averages, but not information about individuals
• Example: if a user is permitted statistical access to an employee DB,
he or she is able to write queries such as:
Statistical DB Security
• Special precautions must be taken when users are permitted access
to statistical data, to ensure that they are not able to deduce data
about individuals.
• If there are no restrictions in place except that all queries must
involve COUNT, SUM, or AVERAGE, a user who wishes to find the
employee of E101 can do so by adding conditions to the WHERE line
to narrow the population down to that one individual, as in:
SQL INJECTION
• Is an application security weakness that allows attackers to
control an application’s database – letting them access or delete
data, change an application’s data-driven behavior, and do
other undesirable things – by tricking the application into
sending unexpected SQL commands.
SQL INJECTION
SQL Injection Attack Tutorial
End of Lecture