Functional Dependencies (FDs)

Functional dependency can be defined as the method that describes the relationship
between the attributes in a given relation. It means we represent how the different
attributes in a dataset table are related to each other with the help of functional
dependencies. Suppose there is functional dependency A→B; it means 'A
determines B' or 'B is determined by A .'Here 'A' is a determinant attribute, and 'B' is
a determined attribute. We can also say that 'B' is dependent on 'A.'

Types of Functional Dependencies

They are four types of functional dependencies -

1. Trivial Functional Dependency
2. Non-trivial Functional Dependency
3. Multivalued Functional Dependency
4. Transitive Functional Dependency
Now, let’s understand what these are:

Trivial Functional Dependency

Let's assume there is functional dependency A→B. If it is a trivial functional
dependency, it means that 'B is a subset of A.' It confirms that trivial dependencies
are always valid because the attribute to be determined is the subset of the left-hand
side attribute. Here reflexive relation holds.
For example, STUDENT_ID→STUDENT_ID is a trivial functional dependency; it will
always be valid, validity and invalidity of a functional dependency have already been
discussed above.
There is another method to determine trivial functional dependency: if we take the
intersection of left and right attributes, it will never be empty('Ⲫ').
For example (STUDENT_ID, STUDENT_NAME)—>STUDENT_NAME, LHS and
RHS intersection is not null.

Non-trivial Functional Dependency

A non-trivial functional dependency A→B means that 'B is not a subset of A' and A
intersection B will be 'null' or 'Ⲫ.'
For example, a functional dependency STUDENT_ID→STUDENT_NAME is a non-
trivial dependency since STUDENT_NAME is not a subset of STUDENT_ID and the
intersection of both of these will be 'Ⲫ';
In non-trivial dependency cases of validity and invalidity arise, trivial ones are always
valid.

Multivalued Functional Dependency

When two attributes in a table are independent of each other but both rely on a third
attribute, this is referred to as multivalued dependency.
A multivalued dependency consists of at least two attributes that are dependent on a
third attribute, which is why at least three attributes are always required.
Let’s see an example of the ‘Student’ table:
 STU_ID COURSE PASSING_YEAR

1 Science 2020

2 Science 2021
Here, STU_ID can determine both COURSE and PASSING_YEAR. STU_ID→{
COURSE, PASSING_YEAR }, but there is no functional dependency between
COURSE and PASSING_YEAR. Hence we can say that COURSE and
PASSING_YEAR both are independent of each other which makes them a
multivalued dependent on STU_ID.

Transitive Functional Dependency

A functional dependency that is indirectly formed by two functional dependencies is
called transitive functional dependency.
For example, if A→B, B→C holds true, then according to the axiom of
transitivity, A→C will also hold true.
Let’s see an example of a ‘Student’ table:
STU_ID CLASS LECTURE_HALL

1 7 L202

2 6 B101
Here, with the STU_ID we can determine CLASS, and with CLASS, we can
determine the LECTURE_HALL number for that particular class. It means with the
help of STU_ID, we can determine LECTURE HALL.
Therefore STU_ID→LECTURE_HALL holds true

Armstrong Axioms

Some essential properties of functional dependencies are:

1. Reflexive: if B is a subset of A, then A→B.

If X ⊇ Y then X → Y // Reflexive property
For example {STU_ID, NAME} →NAME is valid reflexive relation.

2. Augmentation: if A→B then AC→BC for any C.

For example {STU_ID, NAME} →{ DEPT_BUILDING} is valid then {STU_ID,
NAME,DEPT_NAME} →{ DEPT_BUILDING,DEPT_NAME} is also valid.

3. Transitive: if A→B and B→C, then A→C.

For example, if STU_ID→CLASS, CLASS→LECTURE_HALL holds true then

according to the axiom of transitivity, STU_ID→LECTURE_HALL will also hold true.
5. Union: if A→B and A→C, then A→BC.
For example, STU_ID → STU_NAME, STU_ID→COURSE then STU_ID→
{STU_NAME, COURSE} holds true.

5. Decomposition: if A→BC, then A→B, and A→C .

For example STU_ID→ {STU_NAME, COURSE} then STU_ID → STU_NAME,

STU_ID→COURSE holds true.
After understanding the functional dependencies and their types, let's know what an
attribute closure is:

Attribute Closure

Attribute Closure of an attribute set is defined as a set of all attributes that can be
functionally determined from it.
The closure of an attribute is represented as +

Finding Closure of an attribute set

You can follow the steps to find the Closure of an attribute set:
1. Determine A+, the Closure of A under functional dependency set F.
2. A+: = will contain A itself; For example, if we need to find the closure of an
attribute X, the closure will incorporate the X itself and the other attributes that
the X attribute can determine.
3. Repeat the process as
4. old A+: = A Closure;
5. for each FB X → Y in the FD set, do
6. if X Closure is a subset of X, then A Closure:= A Closure U Y;
7. Repeat until ( A+= old A+);
For example,

Given a relation R(A,B,C,D) and FD { A→B, B→C, C→D}, then determine the A+:
1. A+=A, since A can determine A itself.
2. A+=AB, A can also determine B, it is because in the FD set A→B dependency is
given.
3. A+=ABC, A can also determine C with the help of B, since
A → B, B → C, thus, A → C // Transitive property
4. A+=ABCD, A can also determine D with the help of the C attribute, since C is
already determined now in the FD set functional dependency C→D holds, D can
be determined with C.
Therefore,
A+(A closure) =ABCD. A can determine all attributes (ABCD).
Now let's see some questions for a clear understanding of the concept.
 Codd's 12 Rules

(actually numbered 0-12) are a set of 13 criteria proposed by Dr. Edgar F. Codd in
1985 to define the requirements for a database management system (DBMS) to be
considered truly "relational" (RDBMS). They ensure data integrity, logical access,
and independence, requiring that data be represented solely as tables and managed
through relational capabilities.
The 13 Rules of Codd (0-12):
 Rule 0: Foundation Rule: A relational database system must be able to manage its
data entirely through its relational capabilities.

 Rule 1: Information Rule: All data, including metadata (dictionary data), must be
represented as values in rows and columns within tables

 Rule 2: Guaranteed Access Rule: Every individual, non-null data element is

logically accessible using a combination of table name, primary key value, and
column name.

 Rule 3: Systematic Treatment of NULL Values: The DBMS must support a

representation of "missing" or "not applicable" information that is distinct from zero,
empty strings, or blank characters.

 Rule 4: Active Online Catalog: The database description (metadata) must be

stored in an online catalog, which can be queried by authorized users using the
same query language as regular data.

 Rule 5: Comprehensive Data Sublanguage Rule: The system must support at

least one language that supports data definition, view definition, data manipulation,
integrity constraints, authorization, and transactions.

 Rule 6: View Updation Rule: Any view that is theoretically updateable must also be
updateable by the system.

 Rule 7: High-Level Insert, Update, and Delete: The system must support set-level
operations (INSERT, UPDATE, DELETE) rather than just row-level manipulation.

 Rule 8: Physical Data Independence: Changes made to the physical storage or

access methods (e.g., switching to a different file system) do not require changes to
application programs or logical views.
 Rule 9: Logical Data Independence: Changes to the logical structure (tables,
columns) do not require changes to application programs.

 Rule 10: Integrity Independence: Integrity constraints must be stored in the

catalog, not within application programs, and must be capable of being changed
without affecting existing applications.

 Rule 11: Distribution Independence: The database should remain functional

regardless of whether it is centralized or distributed.

 Rule 12: Nonsubversion Rule: If the system provides a low-level (record-at-a-time)

interface, that interface cannot be used to bypass or subvert the integrity rules
defined in the high-level relational language.

While these rules are used as a benchmark for RDBMS, it is rare for a product to
follow all of them perfectly; most adhere to 8-9 of the rules

NORMALIZATION

Normalization in DBMS reduces data redundancy and improves integrity through five
main sequential stages (1NF to 5NF), plus BCNF. Key rules include making values
atomic (1NF), removing partial dependencies (2NF), eliminating transitive
dependencies (3NF), resolving functional dependencies (BCNF), handling multi-
valued dependencies (4NF), and removing join dependencies (5NF).

First Normal Form (1NF): Atomic Values

In 1 1NF row mus not have a colum in which more than one value saved like a
comma separated values

STUDENT AGE SUBJECT

ADAM 15 BIOLOGY,MATHS
ALEX 14 MATHS
STAURT 17 MATHS

1NF

STUDENT AGE SUBJECT

ADAM 15 MATHS
ADAM 15 BIOLOGY
ALEX 14 MATHS
STAURT 17 MATHS
Second Normal Form (2NF): Full Functional Dependency

 Rule: Must be in 1NF and all non-key attributes must be fully functionally
dependent on the entire primary key (no partial dependencies).
 Example: If (STUDENT, SUBJECT) is the composite primary key, and AGE
depends only on STUDENT not on the subject , So there is a partial dependency

2NF

STUDENT SUBJECT
ADAM BIOLOGY
ADAM MATHS
ALEX MATHS
STAURT MATHS

STUDENT AGE
ADAM 15
ALEX 14
STUART 17

Third Normal Form (3NF): No Transitive Dependency

 Rule: Must be in 2NF and no non-key attribute depends on another non-key

attribute (no transitive dependencies).
 Example: In a Table(EmpID, Name, ZipCode, City), if ZipCode determines City, City
should be moved to a separate Zip_City lookup table.

Boyce-Codd Normal Form (BCNF): Strict 3NF

Any Table said to be in BCF if its candidate keys doesn’t have any partial
dependency on the non prime attribute .

STUDENT_ID MAJOR_SUBJECT ADVISORY_LECTURER

(STUDENT_ID, MAJOR_SUBJECT) ----> ADVIORY_LECTURER

(ADVIORY_LECTURER) ---->MAJOR_SUBJECT

Here Major_Subject is part of the composite candidate key is determined by the non
prime attribute it violates BCNF

 Example: In a table (Student, Subject, Teacher) where a Teacher teaches only

one Subject, but a Subject can have multiple Teachers, the (Teacher, Subject)
dependency forces a split.
5. Fourth Normal Form (4NF): Multi-valued Dependency

 Rule: Must be in BCNF and contains no multi-valued dependencies (where

one key determines multiple independent values).
 Example: A table (Student, Language, Hobby). If a student has multiple
independent languages and hobbies, it must be split into (Student, Language)
and (Student, Hobby).

6. Fifth Normal Form (5NF): Join Dependency

 Rule: A table is in 5NF if it is in 4NF and cannot be decomposed into smaller

tables without losing data (no join dependency).
 Example: A table (Agent, Company, Product) where an agent represents a
company, the company makes a product, and the agent sells that product. If
this relationship can be broken into three tables (Agent, Company), (Company,
Product), and (Agent, Product) without losing data, it should be to achieve 5NF.

ENTITIES
 CORE (Strong/Entity): Independent, represents primary objects (e.g.,
CUSTOMER). Represented by a single rectangle.

 CODE (Reference/Lookup): A type of strong entity used for looking up

specific, standardized data codes, such as a "State Table" or "Job Type
Table," which supports data integrity.

 ASSOCIATIVE (Junction/Bridge): Links two or more entities, typically

converting a Many-to-Many (

 SUBTYPE (Sub-class): A subset of a higher-level supertype entity, inheriting

shared attributes (e.g., HourlyEmployee and SalariedEmployee are subtypes of
Employee). It allows for specialized attributes.

Common Entity Types in ER Diagrams:

 Weak Entity: Depends on a parent entity for existence; shown as a double

rectangle.

 Supertype/Subtype (Enhanced ER): Used for generalization/specialization,

where subtypes inherit from a parent entity.

Attributes
Attributes in database modeling define entity characteristics, with primary types
including Simple (atomic, indivisible), Composite (divisible into sub-parts), Single-valued
(one value), Multi-valued (multiple values, e.g., phone numbers), Derived (calculated from
others), and Key (unique identifier). These categorize data structure and behavior within an
Entity-Relationship (ER) model.
 Key Attribute Types in Entities

 Simple (Atomic) Attribute: Indivisible values, such as an Age or Salary.

 Composite Attribute: Can be broken down into smaller, independent sub-parts. For
example, an Address attribute can be split into Street , City , State , and PIN code .

 Single-Valued Attribute: Holds one value for a specific entity, such as Date_of_Birth .

 Multi-Valued Attribute: Contains multiple values for a single entity, such

as Email_Address or Phone_Number . These are often represented by a double ellipse in
ER diagrams.

 Derived Attribute: Not physically stored in the database but calculated from other attributes.
A common example is Age , derived from the stored Date_of_Birth .

 Key Attribute: Uniquely identifies an entity in an entity set, such

as Student_ID or Roll_No . Represented by an underlined name in ER diagrams.

 Stored Attribute: Physically stored in the database, such as Birth_Date .

 Complex Attribute: A combination of composite and multi-valued attributes.

These attributes, represented by ovals in ER diagrams, are crucial for structuring database
tables and establishing entity relationships.

RELATIONSHIP PROPERTIES

In database management systems (DBMS) and Entity-Relationship (ER) modeling,

relationships are structural connections between entities. They are defined by the
following key properties: Degree, Cardinality, Direction, and Optionality.

1. Degree
The degree of a relationship defines the number of entity types participating in the
relationship.

Unary (Degree 1): A relationship where an entity is linked to itself (recursive), such
as an "Employee" who manages other "Employees".

Binary (Degree 2): A relationship linking two different entity types, such as "Student"
and "Course".
 Ternary (Degree 3): A relationship involving three entity types simultaneously, such
as Vendor-Part-Project.

2. Cardinality (Maximum Cardinality)

Cardinality specifies the maximum number of instances of one entity that can be
related to instances of another entity.

One-to-One (1:1): An instance in Entity A is related to at most one instance in Entity

B, and vice versa (e.g., Manager-Department).

One-to-Many (1:N or 1:M): An instance in Entity A is related to many instances in

Entity B, but an instance in B is related to only one in A (e.g., Customer-Orders).

Many-to-Many (M:N): Instances in Entity A are related to many in B, and vice versa
(e.g., Students-Classes).

3. Direction (Cross-filter Direction)

Direction defines how the relationship is used, particularly in data modeling and
querying, such as in Power BI or SQL.
 Single: Filters apply to the "one" side of a relationship to restrict the "many" side.

 Both: Filters flow in both directions (bi-directional), allowing one table to filter the
other regardless of which side it is on.

4. Optionality (Minimum Cardinality/Participation)

Optionality, often called participation, specifies whether an entity

instance must participate in a relationship or may participate (minimum number of
times).
 Mandatory (Total Participation): An entity instance must be connected to another
entity. Represented by a double line in ER diagrams (e.g., Every "Employee" must
belong to a "Department").

 Optional (Partial Participation): An entity instance may or may not be connected to

another entity. Represented by a single line (e.g., A "Project" may or may not have
an "Employee" assigned).

Summary Table
Property Definition Examples

Degree Number of entities involved. Unary, Binary, Ternary

Cardinality Max instances (1:1, 1:N, M:N). One-to-many, Many-to-many

Direction Flow of filtering/constraints. Single, Both

Optionality Minimum participation (Mandatory/Optional). 0 (Optional), 1 (Mandatory)

RELATIONSHIP TYPES
In Entity-Relationship (ER) modeling, relationships define how entities (tables)
interact. The types of relationships are determined by dependency, cardinality
(number of instances), and structure (subtypes or self-reference).
Here is a breakdown of the relationship types in the ER model:

1. Identifying Relationship (Solid Line)

An identifying relationship occurs when the child entity cannot exist without the
parent entity, and the child entity does not have a primary key of its own.

Key Behavior: The Primary Key (PK) of the parent entity becomes part of the
Composite Primary Key of the child entity.

Example: Order and OrderLineItem . A line item cannot exist without the order, so
the Order_ID is part of the OrderLineItem primary key.

Notation: Represented by a solid line in Crow's Foot notation.

2. Non-Identifying Relationship (Dashed Line)

A non-identifying relationship occurs when the child entity can exist independently of
the parent entity, even though they are related.

Key Behavior: The Primary Key of the parent entity is migrated to the child entity,
but only as a Foreign Key (FK) attribute, not as part of the primary key.

Example: Customer and SalesOrder . A customer can exist without placing an order.

Notation: Represented by a dashed line.

Sub-types of Non-Identifying Relationships:

Mandatory: The child record must have a parent (e.g., an Order must have a
Customer). The FK in the child is NOT NULL.

Optional: The child record can exist without a parent (e.g., an Employee might or
might not have a Laptop). The FK in the child allows NULL.
 3. Subtypes (Inclusive and Exclusive)
Subtypes are used in "Inheritance" or "Generalization/Specialization" where a
general entity (Supertype) has specific categories (Subtypes).

 Exclusive (Disjoint - d or x ):

 Three subtype entities, CHECKING-ACCOUNT, SAVINGS-ACCOUNT, and

LOAN-ACCOUNT, are added as dependent entities that are related to
ACCOUNT using a subtype relationship.
 The result is a structure like the one shown in the figure below:


 In this figure, an ACCOUNT is either a CHECKING-ACCOUNT, a SAVINGS-
ACCOUNT, or a LOAN-ACCOUNT. Each subtype entity is an ACCOUNT and
inherits the properties of ACCOUNT. The three different subtype entities of
ACCOUNT are mutually exclusive

 Inclusive (Overlapping - o or + ):

In an inclusive subtype relationship, each instance in the supertype can relate to one
or more subtypes. In our example, the business rule might now state that an Person
can be a employee and Manager at the same time.
 4. Many-to-Many (M:N) Relationship
A many-to-many relationship occurs when multiple instances of one entity are
related to multiple instances of another entity.
 Example: Students and Courses . A student takes many courses, and a course has
many students.

 Implementation: In a physical database, this cannot be directly implemented. It is

resolved by creating a junction/associative table (e.g., Enrollment ) that holds the
foreign keys of both entities.

5. Recursive (Unary) Relationship

A recursive relationship occurs when an entity has a relationship with itself.

 Example: In an Employee table, an employee is managed by another employee
(Manager). The ManagerID is a foreign key referencing the EmployeeID in the same
table.

 Usage: Frequently used to represent hierarchies or organizational charts.

Summary Table
Relationship Type Key Feature Diagram Line

Identifying Child relies on Parent for ID; PK migrates to PK Solid

Non-Identifying Child is independent; PK migrates as a Non-Key Dashed

Exclusive Subtype Instance can be only one child type (Disjoint) Arc with 'x'/'d'

Inclusive Subtype Instance can be multiple child types (Overlapping) Arc with 'o'

Many-to-Many Multiple to Multiple; Requires junction table Crow's foot (both ends)

Recursive Entity relates to itself Loop

ER DIGRAM SYMBOLS
 Data abstraction
 Using the ER model for larger datasets creates a lot of complexity when designing
a database model. To minimize the complexity, Generalization, Specialization, and
Aggregation were introduced in the ER model. These were used for data
abstraction. In which an abstraction mechanism is used to hide the details of a set
of objects.

Generalization
Process of extracting common properties from a set of entities and creating a
generalized entity from it. It is a bottom-up approach in which two or more entities
can be generalized to a higher-level entity if they have some attributes in common.
Example: STUDENT and FACULTY can be generalized to a higher-level entity
called PERSON as shown in diagram below. In this case, common attributes like
P_NAME and P_ADD become part of a higher entity (PERSON) and specialized
attributes like S_FEE become part of a specialized entity (STUDENT).

Specialization
In specialization, an entity is divided into sub-entities based on its characteristics. It
is a top-down approach where the higher-level entity is specialized into two or more
lower-level entities.
Specialization
Example: an EMPLOYEE entity in an Employee management system can be
specialized into DEVELOPER, TESTER, etc. In this case, common attributes like
E_NAME, E_SAL, etc. become part of a higher entity (EMPLOYEE) and
specialized attributes like TES_TYPE become part of a specialized entity
(TESTER).

Inheritance
It is an important feature of generalization and specialization. In specialization, a
higher-level entity is divided into lower-level sub-entities that inherit its attributes. In
generalization, similar lower-level entities are combined into a higher-level entity
that holds common attributes. In both cases, inheritance allows sub-entities to
reuse the properties of the parent entity.
1. Attribute inheritance: It allows lower level entities to inherit the attributes of
higher level entities but not vice versa. In diagram Car entity is an inheritance of
Vehicle entity ,So Car can acquire attributes of Vehicle. Example: Car can
acquire Model attribute of Vehicle.
2. Relationship Inheritance: Sub-entities also inherit relationships of the parent
entity.
3. Overriding Inheritance: Sub-entities can override or add their own attributes or
behaviors different from the parent.
4. Participation inheritance: Participation inheritance in ER modeling refers to
the inheritance of participation constraints from a higher-level entity
(superclass) to a lower-level entity (subclass). It ensures that subclasses
adhere to the same participation rules in relationships, although attributes and
relationships themselves are inherited differently.
 Example of Relation
Example: In diagram Vehicle entity has an relationship with Cycle entity, but it
would not automatically acquire the relationship itself with the Vehicle entity.
Participation inheritance only refers to the inheritance of participation constraints,
not the actual relationships between entities .

Aggregation
 An ER diagram is not capable of representing the relationship between an entity
and a relationship which may be required in some scenarios.
 In those cases, a relationship with its corresponding entities is aggregated into a
higher-level entity.
 Aggregation is an abstraction through which we can represent relationships as
higher-level entity sets.
Aggregation

Example: an Employee working on a project may require some machinery. So,

REQUIRE relationship is needed between the relationship WORKS_FOR and
entity MACHINERY. Using aggregation, WORKS_FOR relationship with its entities
EMPLOYEE and PROJECT is aggregated into a single entity and relationship
REQUIRE is created between the aggregated entity and MACHINERY.

Atomicity, Consistency, Isolation, Durability(ACID)

Oracle maintains ACID (Atomicity, Consistency, Isolation, Durability) properties primarily
through transactional logging, locking mechanisms, and the undo/redo log
architecture. Oracle Help Center ensures all-or-nothing changes (Atomicity) using undo logs
to roll back failed transactions and YouTube uses redo logs to ensure committed data is
never lost (Durability).

How ACID is Maintained in Oracle:

 Atomicity (All or Nothing): Oracle uses Undo Segments (undo logs) to store original data
before modifications. If a transaction fails or a ROLLBACK is issued, Oracle uses these logs
to reverse partial changes, ensuring the transaction is either fully completed or completely
rolled back.

 Consistency (Valid State): Oracle guarantees that a transaction moves the database from
one valid state to another, enforcing constraints (e.g., unique, foreign key, check
constraints). If a statement within a transaction violates a constraint, it is rolled back without
affecting the whole transaction.

 Isolation (Independent Execution): Oracle manages concurrent transactions

using locks and its Multi-Version Concurrency Control (MVCC). MVCC allows users to
 read data without holding locks, while locks prevent other transactions from modifying data
being updated, preventing conflicts.

 Durability (Permanent Changes): Once a transaction is committed, Oracle guarantees its

permanence through Redo Log Files. Before a commit is confirmed, the transaction's
changes are written to the Redo Log, allowing data to be recovered after a crash.

Isolation Level Solutions

1. Dirty Reads
A Dirty Read occurs when a transaction (Transaction B) reads data that has been
modified by another concurrent transaction (Transaction A), but Transaction A has
not yet committed that modification.

2. Non-Repeatable Reads

A Non-Repeatable Read happens when a transaction (Transaction A) reads the

same row twice, but finds different data each time. This occurs because a second
transaction (Transaction B) modifies or deletes that row and commits between the
two reads by Transaction A.

3. Phantom Reads
A Phantom Read occurs when a transaction (Transaction A) runs the same query
twice, but the number of rows returned is different. This is caused by a second
transaction (Transaction B) inserting or deleting rows that match the search
condition.

Summary Table
Reads Same Row Row Count
Phenomenon
Uncommitted? Changes? Changes?
Dirty Read Yes Yes Possible
Non-Repeatable No (Reads
Yes No
Read Committed)
No (Reads
Phantom Read No Yes
Committed)

Isolation Level Solutions

 Read Uncommitted: Allows Dirty, Non-Repeatable, and Phantom Reads.
 Read Committed: Prevents Dirty Reads (Default in many databases like
PostgreSQL).
 Repeatable Read: Prevents Dirty and Non-Repeatable Reads (Default in
MySQL).
 Serializable: Prevents all, including Phantom Reads
 The transaction isolation level in an Oracle database for a specific connection is set
by the application using the JDBC API, though the default level is determined by
the DBMS.

How the Transaction Level is Set

 Application Control via JDBC: The application developer explicitly sets the
isolation level for a specific Connection object using
the [Link]() method. The JDBC specification defines
standard integer constants for this purpose
(e.g., Connection.TRANSACTION_READ_COMMITTED , Connection.TRANSACTION_SERI
ALIZABLE ).

 Database and Driver Support: The underlying database and its specific JDBC
driver determine which isolation levels are actually supported. For example, the
Oracle server only
supports TRANSACTION_READ_COMMITTED and TRANSACTION_SERIALIZABLE .

 Default Level: If the application does not explicitly set the level, the connection uses
the default level provided by the DBMS. The default for Oracle Database
is TRANSACTION_READ_COMMITTED .

 When to Set: The isolation level must be set before a transaction begins. Attempting
to change it during an active transaction will cause the driver to commit the active
transaction or throw a SQLException .

 Alternative Methods: The isolation level can also be set using the SQL
command SET ISOLATION LEVEL or, in application server environments, through
administrative console settings for JDBC connection pools.

In summary, while the Oracle database enforces the available isolation levels, the
specific level used by a JDBC application is determined by the application through a
programmatic call to the JDBC AP