DATABASE ADMINISTRATION

COURSE CODE: ITEC4138

CREDIT HOUR: 4 (3 + 1)
TOPIC: MANAGING SCHEMA OBJECTS

MIRZA ARSLAN BAIG LECTURER COMPUTER SCIENCE

WhatsApp: 0308 6877143 E-Mail: [email protected]
UNIVERSITY OF EDUCATION LAHORE
FAISALABAD CAMPUS
MANAGING SCHEMA OBJECTS
CREATE AND MODIFY TABLES
USERS, USER ACCOUNTS
SCHEMAS AND SCHEMA OBJECTS
NAMING SCHEMA OBJECTS
OBJECT NAMESPACES
DATA TYPES
CREATING TABLES
MANAGE CONSTRAINTS
CREATE INDEXES
CREATE AND USE TEMPORARY TABLES
CREATE AND
MODIFY TABLE
To create or modify a table in a database, you typically use
SQL (Structured Query Language). Below are the general
commands for both creating and modifying tables:
CREATING A TABLE
To create a new table in a database, you use the CREATE
TABLE statement. You define the table name, followed by
column names and their data types.
EmployeeID is the primary key, which uniquely identifies
each employee.
FirstName and LastName are text fields, with a maximum
length of 50 characters.
DateOfBirth and HireDate are dates.
Salary is a decimal with 2 digits after the decimal point.
MODIFYING AN EXISTING TABLE
To modify an existing table (e.g., to add, delete, or modify columns), you can use ALTER TABLE.
ADDING A COLUMN
You can add a new column to an existing table using the ADD keyword.
ALTER TABLE Employees ADD Email VARCHAR(100);

This command adds a new column Email to the Employees table, with a maximum length of 100
characters.

DROPPING A COLUMN
To remove a column from an existing table, use the DROP COLUMN command.
ALTER TABLE Employees DROP COLUMN Salary;

This command removes the Salary column from the Employees table.
CHANGING A COLUMN DATA TYPE
You can modify an existing column's data type using MODIFY (in MySQL) or ALTER COLUMN (in
PostgreSQL, SQL Server, etc.).
ALTER TABLE Employees MODIFY COLUMN FirstName VARCHAR(100);

RENAMING A COLUMN
To rename a column, you can use the RENAME COLUMN syntax.
For PostgreSQL or MySQL (8.0+):
ALTER TABLE Employees RENAME COLUMN FirstName TO First_Name;

RENAMING A TABLE
To rename a table, use the RENAME TO (PostgreSQL) or RENAME (SQL Server, MySQL) command.
RENAME TABLE Employees TO Staff;

DELETING A TABLE
If you want to remove an entire table (and all of its data) from the database, use the drop table command.
DROP TABLE Employees;
 USERS
USER ACCOUNTS
In Database Administration (DBA), the terms Users and User Accounts refer to individuals or entities
that have access to a database system, along with their permissions, roles, and access rights.
A key part of a DBA's role is to manage these users, ensuring that access to the database is secure,
compliant, and appropriately configured.

USERS IN DATABASE CONTEXT

➢ A user in a database is an entity that can connect to and interact with the database system.
➢ A user may represent a human (e.g., a developer, administrator, or analyst) or an application that needs
access to the database.
CHARACTERISTICS OF USERS
Authentication
Users must authenticate themselves to the database, typically through a username and password.
Authorization
After authentication, users are granted specific permissions or privileges that allow them to perform
various actions (e.g., select, insert, update, delete data).
Roles
Users may be assigned roles that define a group of permissions, which simplifies user management.
Account Locking
To prevent unauthorized access, user accounts may be locked after multiple failed login attempts.
Session Management
Users can create database sessions, perform transactions, and interact with the data.
USER ACCOUNTS
A user account in a database system consists of the following components:
Username
A unique identifier for the user within the database.
Password
A secret string used to authenticate the user. It is stored securely (often hashed) to prevent unauthorized access.
Schema
The schema is a collection of database objects (tables, views, procedures, etc.) that are owned by the user.
Privileges
Permissions granted to the user that specify what actions they can perform within the database (e.g., SELECT,
INSERT, UPDATE, DELETE).
Roles
Roles are predefined collections of privileges, which can be granted to users to simplify permission
management.
MANAGING USERS & USER ACCOUNTS
As a DBA, you will frequently work with user accounts to ensure that the right people have access to the
right resources, while protecting sensitive data.
CREATING USERS
You create user accounts to allow access to the database system. The syntax to create a user varies by
database management system (DBMS), but here's an example for MySQL and PostgreSQL:
CREATE USER 'username'@'hostname' IDENTIFIED BY 'password';

➢ username is the new user's name.

➢ hostname specifies from which host the user can connect. You can use % to allow access from any host.
➢ password is the user's password.
GRANTING PRIVILEGES
After creating a user, you grant them the appropriate permissions to perform actions within the database.
GRANT SELECT, INSERT, UPDATE ON database_name.* TO 'username'@'hostname';

This grants the user the ability to select, insert, and update data in a specific database.
ROLES
Roles simplify the management of privileges by grouping together common permissions.
Instead of granting individual permissions to each user, you can create roles with predefined
permissions and assign them to users.
CREATE ROLE 'role_name'; GRANT SELECT, INSERT ON database_name.* TO 'role_name’;

MODIFYING USERS
If you need to update a user’s password or change their privileges, you can do so using ALTER commands.
ALTER USER 'username'@'hostname' IDENTIFIED BY 'new_password';
REVOKING PRIVILEGES
If you need to revoke a user’s access to certain parts of the database, you can remove their privileges
REVOKE SELECT, INSERT ON database_name.* FROM 'username'@'hostname’;

DROPPING USERS
If a user no longer requires access to the database, you can drop their account
DROP USER 'username'@'hostname’;

ACCOUNT LOCKING AND EXPIRATION

For security, many DBMSs allow you to lock or expire user accounts to prevent unauthorized access.
ALTER USER 'username'@'hostname' ACCOUNT LOCK;
 SCHEMAS AND
SCHEMA OBJECTS
In Database Administrator (DBA), schemas and schema objects are fundamental concepts in the
management and organization of a database
SCHEMA
➢ A schema in a relational database is a logical container or namespace that holds database objects such as
tables, views, indexes, stored procedures, and other structures.
➢ A schema helps organize and manage database objects, and it provides a level of abstraction for the
user.
➢ Schemas allow DBAs to group related objects together and assign specific permissions to those objects.
EXAMPLE IN ORACLE
In Oracle, a schema is essentially equivalent to a user account. When you create a new user in Oracle, a
schema with the same name is created, and the user owns the schema's objects.
CREATE USER hr IDENTIFIED BY password;

This creates the 'hr' schema, and the user 'hr' will own it.
FEATURES OF SCHEMAS:
Namespace: A schema acts as a namespace for database objects, meaning that you can have objects with
the same name in different schemas (e.g., two tables named employees in schema1 and schema2).
Ownership: A schema is usually owned by a database user, and that user or role has control over the
objects within the schema.
Security & Permissions: The DBA can assign access controls to schemas to restrict or grant permissions
to users or roles. For example, a schema might have permissions to allow certain users to query its tables
but restrict updates or inserts.
Logical Organization: It helps in logically organizing objects, so for example, a schema could be created
for each department of an organization (e.g., hr_schema, finance_schema, etc.).

In most modern database systems like Oracle, SQL Server, and PostgreSQL, a schema is a structural entity,
but different databases might use different terminology and underlying mechanisms.
SCHEMA OBJECTS
Schema objects are the individual elements that exist within a schema. These objects are the actual entities
that make up the database's functionality and structure.
Tables: Store data in rows and columns.
Views: Virtual tables that present data from one or more tables. A view doesn't store data, but rather, it
displays data from underlying tables based on a query.
Indexes: Improve the speed of data retrieval operations on a table or a view.
Sequences: Generate unique numbers, often used for creating primary key values.
Synonyms: Aliases for database objects that allow a more simplified way to reference them.
Procedures/Functions: Stored programs that can be executed to perform a specific task, such as data
manipulation or business logic.
Triggers: Stored procedures that automatically execute when certain events occur in the database, such as
INSERT, UPDATE, or DELETE.
SCHEMA OBJECTS (Count……)
Constraints: Rules that enforce data integrity, such as PRIMARY KEY, FOREIGN KEY, CHECK, or
UNIQUE.
Types: User-defined data types.
Materialized Views: Precomputed views that store their result on disk for performance purposes.
SCHEMAS AND THE DBA ROLE
Database Administrator (DBA), managing schemas is an essential part of the role.
Organizing Data: The DBA ensures that the database schema structure is well-organized to meet the needs of
the application and business logic. This often includes designing tables, views, and relationships.
Security & Access Control: DBAs are responsible for assigning and managing user permissions at the schema
level. By controlling access to schemas and schema objects, the DBA ensures that users only have access to the
data they need.
Backup & Recovery: DBAs must understand the schema structure when performing backup and recovery
operations. In some cases, it might be necessary to backup specific schemas or perform recovery based on
schema-level configurations.
Data Integrity & Performance: The DBA uses schema objects like indexes, constraints, and triggers to
maintain data integrity and optimize query performance.
Compliance & Auditing: A DBA needs to set up auditing on schema objects, track changes, and ensure
compliance with organizational standards and regulations.
 NAMING
SCHEMA OBJECTS
NAMING SCHEMA OBJECTS
➢ Database Administrator (DBA), naming schema objects in a clear, consistent, and meaningful way is
crucial for the long-term maintenance, readability, and efficiency of the database system.
➢ Proper naming conventions ensure that schema objects are easily identified and understood by team
members, developers, and future DBAs, thus avoiding confusion, ensuring data integrity, and improving
system performance.
GENERAL PRINCIPLES FOR NAMING SCHEMA OBJECTS
Clarity: Names should be descriptive, providing clear insight into what the object represents. Avoid
abbreviations or overly cryptic names.
Consistency: Naming conventions should be applied consistently across the entire database. This makes
the schema easier to navigate, especially as it grows over time.
Avoid Reserved Words: Ensure names do not conflict with SQL reserved keywords to prevent errors or
unexpected behavior.
Use Meaningful Names: A table or object name should reflect the business domain or the functionality it
serves. For example, a table storing employee details should be called employees, not emp_data.
Limit Length: While names should be descriptive, they should also be reasonably short. Most databases
have a limit on the length of object names (e.g., 30 characters in Oracle).
No Spaces or Special Characters: Use underscores (_) to separate words instead of spaces. Avoid special
characters (e.g., hyphens, periods) in object names.
 OBJECT
NAMESPACES
OBJECT NAMESPACES
In simple terms, object namespaces are ways to organize and manage different objects in a database.
These objects include things like tables, views, indexes, stored procedures, and more.
The main goal of using namespaces is to group related objects together and avoid name conflicts.
SCHEMAS AS NAMESPACES
A schema is the primary type of namespace in most databases.
It’s a logical container that holds all types of database objects (e.g., tables, views, functions).
Different schemas can have objects with the same name, as long as they are in different schemas.
For example: You could have a hr schema with a table called employees and a sales schema with a table
also called employees.
These two tables won't conflict because they are in different schemas (namespaces).
WHY USE SCHEMAS?
Organize objects: Keep related tables, views, and other objects grouped.
Avoid name conflicts: You can have the same name for different objects, as long as they are in different
schemas.
Security: You can control access to entire schemas, allowing or denying access to users or roles.
SCHEMAS AS OWNERSHIP AND SECURITY
Each schema is typically owned by a user. This user has control over all the objects inside the schema, and
the DBA can control access permissions. For example, only certain users may have access to the hr schema
while others can access the sales schema.
MULTI-TENANT DATABASES
In a multi-tenant system (for example, a SaaS application where multiple customers use the same
database), each customer can have its own schema. This keeps their data separate from others and adds an
extra layer of security.
Schema
A logical grouping of database objects such as tables, views, indexes, stored procedures, and triggers.
Namespace
A context in which object names (tables, views, etc.) are unique. Namespaces allow the same name to be
used for different objects as long as they reside in different schemas.
Example
Two schemas, hr_schema and sales_schema, could both contain a table named employees, but because
they are in different schemas (namespaces), there is no conflict.
DATA
TYPES
In Database Administration (DBA), data types refers to the kinds of data that can be stored in a
database. Each column in a database table is defined by a specific data type that dictates the kind of data it
can hold, how it is stored, and the operations that can be performed on it.
NUMERIC DATA TYPES
Used for storing numbers, whether integers or decimals.
INT or INTEGER: Used for storing whole numbers.
DECIMAL or NUMERIC: Used for storing fixed-point numbers (numbers with decimal points) with
specified precision and scale
FLOAT or REAL: Used for storing approximate numeric values with floating decimal points.
In this example:
➢ employee_id will store integer values (e.g., 101, 102, 103).
➢ salary will store values with up to 10 digits, 2 of which can be
after the decimal point (e.g., 45000.99).
Character/String Data Types
These are used to store text or alphanumeric data.
CHAR: Fixed-length character string. If you define
a column as CHAR(10), it will always store exactly
10 characters, padding with spaces if necessary.
VARCHAR: Variable-length character string.
Unlike CHAR, the length can vary, so it's more
space-efficient.
TEXT: Used for storing large amounts of text data,
typically without an upper limit.
DATE AND TIME DATA TYPES
Used to store date and time-related data.
DATE: Stores only the date (e.g., 2024-11-14).
TIME: Stores the time of day (e.g., 14:30:00).
DATETIME or TIMESTAMP: Stores both date
and time (e.g., 2024-11-14 14:30:00).
YEAR: Stores a year (e.g., 2024)

BOOLEAN DATA TYPES

Used for storing TRUE or FALSE values.
In some databases, there is a BOOLEAN data type,
while in others, it may be represented as integers (1
for TRUE, 0 for FALSE).
BINARY DATA TYPES
Used for storing binary data such as images, audio
files, or any other kind of non-text data.
BLOB (Binary Large Object): Used for storing
large binary data (e.g., images, videos).
VARBINARY: Stores variable-length binary data.

UUID (UNIVERSALLY UNIQUE IDENTIFIER)

Used for storing globally unique identifiers.
Typically represented as a 128-bit number, often
used for primary keys in distributed systems.
CREATING
TABLES
In Database Administration (DBA), creating tables is a fundamental task that involves defining the
structure of the database objects where data will be stored.
A table consists of rows and columns, and each column is defined by a data type that determines what
kind of data can be stored in that column.
Creating tables requires writing a SQL CREATE TABLE statement that specifies the table name, the
columns in the table, their data types, constraints (such as primary keys, foreign keys, etc.), and other table
properties.
FEATURES OF CREATING TABLES
Table Name: The name you give to the table. It should be descriptive of the data being stored and unique
within the schema.
Columns: Each table consists of columns that define the types of data the table will hold. Each column is
defined by:
•Name: A unique name for the column within the table.
•Data Type: Defines the kind of data (e.g., integer, string, date, etc.) that can be stored in that column.
•Constraints: Rules applied to the column to enforce data integrity (e.g., NOT NULL, UNIQUE,
DEFAULT, etc.).
Primary Key: A column or set of columns that uniquely identifies each row in the table.
Foreign Key: A column that references the primary key in another table, ensuring referential integrity.
Other Constraints: Additional rules that can be applied to data like CHECK constraints, DEFAULT
values, etc.
EXPLANATION
employee_id: This column is defined as INT (integer) and will store employee IDs. It's marked as the
primary key, ensuring each employee has a unique ID.
first_name and last_name: These columns are defined as VARCHAR(50), meaning they can store
variable-length strings up to 50 characters long.
hire_date: This is a DATE type column to store the date the employee was hired.
salary: The DECIMAL(10, 2) type specifies that the salary will have up to 10 digits, with 2 digits after the
decimal point.
CREATING A TABLE WITH CONSTRAINTS
EXPLANATION
order_id: This column is the primary key for the orders table, ensuring that each order has a unique
identifier.
customer_id: This column cannot be NULL (hence the NOT NULL constraint).
order_date: A DATETIME column that automatically gets set to the current timestamp when a new order
is inserted, thanks to the DEFAULT CURRENT_TIMESTAMP clause.
total_amount: A DECIMAL(10, 2) column, which stores the total value of the order, with a CHECK
constraint to ensure the amount is never negative.
status: An ENUM data type is used here, restricting the status column to one of the predefined values:
'Pending', 'Shipped', 'Delivered', or 'Cancelled'. The NOT NULL constraint ensures that a status is always
specified.
CREATING A TABLE WITH FOREIGN KEY
EXPLANATION
The customers table contains information about the customers, such as customer_id, first_name,
last_name, and email.
The orders table contains a foreign key customer_id, which refers to the customer_id column in the
customers table.
The FOREIGN KEY constraint ensures that every customer_id in the orders table must exist in the
customers table, thus enforcing referential integrity between the two tables.
CREATING A TABLE WITH COMPOSITE PRIMARY KEY

EXPLANATION
The order_items table is designed to store multiple items for each order. Each row represents a product
within an order.
The composite primary key is created using both order_id and product_id, ensuring that there can be
multiple rows for the same order_id, but each row will have a unique combination of order_id and
product_id.
CREATING A TABLE WITH AUTO-INCREMENT COLUMN

EXPLANATION
employee_id: This column will automatically generate a unique value for each new row added to the table,
starting from 1 and incrementing by 1 for each new row.
The AUTO_INCREMENT keyword ensures that the value is automatically handled by the database.
 MANAGE
CONSTRAINTS
➢ In Database Administration (DBA), managing constraints refers to the process of enforcing rules or
conditions on the data in database tables to maintain data integrity, consistency, and correctness.
➢ Constraints ensure that the data adheres to specific business rules or validation criteria.
➢ Constraints are defined at the column or table level and can control the values that are allowed to be
inserted, updated, or deleted from the database.
TYPES OF CONSTRAINTS
1.Primary Key Constraint
2.Foreign Key Constraint
3.Unique Constraint
4.Check Constraint
5.Not Null Constraint
6.Default Constraint
7.Index Constraint (sometimes considered part of constraint management)
PRIMARY KEY CONSTRAINT
➢ The Primary Key constraint ensures that each
row in a table is uniquely identifiable.
➢ It is a combination of one or more columns that
must contain unique values.
➢ A primary key also implicitly enforces a NOT
NULL constraint, meaning no column in the
primary key can have NULL values.
Purpose: Uniquely identifies each row in a table.
Usage: Generally used on a column like id,
employee_id, or order_id.
FOREIGN KEY CONSTRAINT
➢ A Foreign Key constraint ensures that values in
one table correspond to values in another table,
establishing a relationship between two tables.
➢ It enforces referential integrity, ensuring that
rows in a child table must correspond to rows in
a parent table.
Purpose: Ensures referential integrity by linking
tables.
Usage: Commonly used to enforce relationships
between parent and child tables (e.g., an orders table
referencing a customers table).
UNIQUE CONSTRAINT
➢ A Unique constraint ensures that all values in a
column (or a combination of columns) are unique
across the table, meaning no duplicate values are
allowed.
➢ Unlike the primary key, a unique constraint can
allow NULL values (though behavior may
depend on the database system).
Purpose: Ensures that each value in a column or a
set of columns is unique.
Usage: Used to enforce uniqueness on non-primary
key columns (e.g., email, username).
CHECK CONSTRAINT
➢ A Check constraint ensures that the values in a
column satisfy a specific condition or rule.
➢ It can be applied to enforce domain integrity,
such as limiting the range of values in a numeric
column or validating a string format.
Purpose: Enforces conditions on the values of a
column.
Usage: Commonly used to limit the range of
numeric values or to enforce a format for string data
(e.g., checking that age is greater than zero, or salary
is within a certain range).
NOT NULL CONSTRAINT
➢ The Not Null constraint ensures that a column
cannot contain NULL values.
➢ This is a basic constraint that enforces the
presence of a value in a column.
Purpose: Ensures that a column always contains a
value.
Usage: Used when a column is required to have a
value, such as in name, address, or date fields.
DEFAULT CONSTRAINT
➢ The Default constraint automatically assigns a
default value to a column when no value is
specified during insertion.
➢ This can be useful for setting default dates, status
values, or numeric values.
Purpose: Automatically provides a default value for
a column when a value is not explicitly provided.
Usage: Often used for status or timestamp fields, or
when a common default value is needed.
INDEX CONSTRAINT (OPTIONAL)
➢ While not strictly a "constraint" in the traditional
sense, indexes can be used to enforce unique
constraints and improve the performance of
certain queries, such as those involving JOINs or
WHERE clauses on indexed columns.
➢ Indexes improve query speed but may slow down
INSERT, UPDATE, and DELETE operations due
to the overhead of maintaining the index.
Purpose: Improves query performance by creating
an internal data structure that speeds up searches.
Usage: Frequently used for columns that are often
queried or used in sorting.
CREATE
INDEXES
➢ In Database Administration (DBA), creating and managing indexes is a crucial task that directly
impacts the performance of a database, especially in terms of query speed.
➢ Indexes are database objects that improve the retrieval speed of rows in a table by providing a more
efficient way of searching, sorting, and filtering data.
➢ An index is essentially a data structure (often a B-tree or hash structure) that the database uses to
quickly locate rows based on the values in one or more columns.
➢ While indexes significantly improve read operations, they can have an overhead on write operations
(like INSERT, UPDATE, and DELETE) because the index itself needs to be updated.
FEATURES OF INDEXES
Index Definition: An index provides an efficient lookup mechanism for a database query. When a query requires data
retrieval based on a column's value, the database engine will first check if there's an index on that column, and use the
index to speed up the search operation.
Primary Use of Indexes:
•Faster Data Retrieval: Indexes improve the performance of queries that use SELECT statements with
WHERE, JOIN, ORDER BY, and GROUP BY clauses.
•Sorting: Indexes help speed up sorting of results in queries with ORDER BY.
•Uniqueness Enforcement: Indexes are used to enforce uniqueness on columns like primary keys or unique
constraints.
Trade-offs:
•Performance: While indexes speed up data retrieval, they can slow down write operations (INSERT, UPDATE,
DELETE), as the database must update the index as well as the data.
•Storage Overhead: Indexes consume additional disk space. This overhead is generally proportional to the size
of the indexed columns.
TYPES OF INDEXES
Single-Column Index: Indexing a single column in a table.
Composite Index: Indexing multiple columns, which is useful for queries that involve multiple columns in
a WHERE clause or JOIN.
Unique Index: Ensures that all values in the indexed column(s) are unique.
Full-text Index: Used for full-text search operations, allowing quick searches for text-based data within
large text fields.
Spatial Index: Used for indexing geographic or geometric data types, like points, lines, or polygons, often
in GIS (Geographical Information Systems) applications.
CREATING INDEXES

➢ index_name: A unique name for the index.

➢ table_name: The name of the table on which the index is being created.
➢ column(s): One or more columns in the table that will be indexed.
MANAGING INDEXES
Viewing Existing Indexes
Dropping Indexes
Rebuilding or Reorganizing Indexes
Indexing Strategy
 CREATE AND
USE TEMPORARY
TABLES
TEMPORARY TABLES
➢ Temporary tables are a powerful feature in relational database management systems (RDBMS) like
MySQL, PostgreSQL, SQL Server, and Oracle.
➢ They are tables that exist temporarily during the session or the execution of a specific task.
➢ They are typically used for intermediate storage or to hold temporary data that you don't want to persist
after the session or transaction ends.
➢ Session-Specific Temporary Tables: These are only available to the session that created them. Once
the session ends, the table is automatically dropped.
➢ Global Temporary Tables: These are available across sessions, but the data within the table is session-
specific (i.e., different sessions cannot see each other’s data).
EXAMPLE SCENARIOS FOR USING TEMPORARY TABLES
Staging Data
➢ Importing or transforming data temporarily before inserting it into the permanent tables.
Complex Queries
➢ Breaking complex queries into smaller, easier-to-understand subqueries.
Performance Optimization
➢ Storing intermediate results that would otherwise require multiple expensive joins or subqueries.
Data Transformation
➢ Converting or processing data before inserting it into the production database.
THANK YOU