An Oracle PL/SQL API can provide several benefits as a data protection mechanism: 1) It enforces consistent updates, authorized access, and protects against misbehaved applications through mechanisms like triggers, constraints, and virtual private databases. 2) It controls access to data structures and prevents dependency on the underlying data model through validation procedures and abstracted retrieval/update types. 3) It avoids issues caused by direct database access like "funny" updates, mal-formed queries, and sub-optimal access paths by funneling all data handling through the API.

1. Case Study:
PL/SQL API as data
protection mechanism
in Oracle databases
by Ziemowit Jankowski
Database Architect

2. Intended use
● Large databases
● Intensive updates
● Heterogeneous environment
● Many external actors with potentially
misbehaved applications or ad-hoc
queries
● Due to enterprise nature impossible to
know who is doing what and how
● Non-existent or insufficient GUI-
capabilities for users

3. ● Consistency in updates (triggers and
constraints)
● Updating/reading in correct context
(triggers, VPD)
● Authorized access (Oracle authorization,
roles, VPD, ACL)
● Protection against misbehaved
application:
● Reading
● Updating (e.g. improper transaction
handling)
Data protection – a look at the
broader meaning

4. ● Exposing data structures to external
actors:
o Access to “more than needed”
o Dependency on data model
o “Funny” updates
● Misbehaved applications and/or users
● Mal-formed SQL queries
o Sub-optimal data access paths
● Possible need for multiple
implementations of business logic
A few pitfalls for “classic”
approach

5. Example scenarios
Database
(triggers,
constraints,
VPD etc)
App server
Valid
ation
Automated
application
Other
database
GUI-based
application

6. • Updating
• Validation of data
• One place, one algorithm
• Complex validation algorithms
• Avoiding bad application / user behaviour
• Updates independent from data model
• Retrieval
• Controlled access paths (performance)
• Validation of search conditions
• Results independent from data model
• Logging
• Security through obfuscation
Some benefits of an API in data
handling

7. • Software platform specific:
• .NET
• Java
• Others
• Common platform
• Oracle PL/SQL
Different API implementations

8. • Pros
• One point, one algorithm for all data
validation
• All ”internal” data validation close to data
store (overhead elimination)
• No ”out of control” access paths
• Cons
• PL/SQL based
• Hard to understand for novice programmers
Oracle PL/SQL API

9. Example scenarios revisited
Container schema
(data, metadata, stored
code)
App server
Validation
Automated
application
Other
database
GUI-based
application
Access
schema
Access
schema
Access
schema

10. • Container schema includes:
• Data containers (tables, views, mviews)
incl. triggers, constraints etc.
• Data retrieval and data manipulation code
• Interface data model, abstracted from
underlying data model
• Access schema includes:
• Execution rights to data retrieval and
manipulation code in container schema
• Synonyms pointing at relevant code in
container schema
General principles

11. • Actors connect to database through
access schema
• Actors do not have direct access to data
• Actors do not have direct access to
meta-data
• Actors have to use predefined access
paths in orderly manner
• Actors cannot circumvent data
validation, on purpose or by accident
Usage

12. • Usually not a major problem
• Might become major performance issue:
• Data-intensive updates
• Large data volumes
• Time critical updates (e.g. quasi-realtime)
• Non-trivial validation
• No possibility to take in “dirty data” and
validate later on
• In-database validation inside API usually
faster than external application
Data validation

13. • Examples:
• Long rollbacks
• Commit waiting for user interaction
• Long transactions on quasi-real-time data
• Culprits:
• Rookie application programmers (been
there, seen that)
• Interactive users
• Insufficient validation of data
Eliminated by API that enforces some basic
rules.
Bad behaviour

14. • Enforced usage of correct data types
• Example:
WHERE to_char(dateCol,’YYYYMM’) = ’200101’
• SQL statements entirely within API code
• No user-generated statements that cause
poor performance
Controlled access paths

15. • The API defines own Oracle types for
data retrieval and update
• The API types may or may not
correspond to actual data containers
• Changes in table layout can be hidden
from caller
• Backward compatibility
• No need to rewrite all applications using the
altered table/-s.
Independency from data model
(retrieval and updates)

16. • Procedures returning strongly typed
cursors
• At all costs avoid SYS_REFCURSOR
• Alternative: use pipelined functions that
return strongly typed data
• Might lead to undesirable side-effects with
WHERE-clauses
• In both above cases: strongly typed
parameters help avoiding full table scans
due to malformed WHERE-clauses
Some implementation details –
data retrieval

17. • Procedures accept strongly typed
parameters
• Procedures return status code or
message
Some implementation details –
data update

18. • SOA
• Will not deliver same throughput
• Will lock you in an infrastructure
Alternatives?