JDBC
JDBC
in Java
Agenda
• Overview of Databases and Java
• Overview of JDBC
• JDBC APIs
• Other Database Techniques
Database Architectures
• Two-tier
• Three-tier
• N-tier
Two-Tier Architecture
• Client connects directly to server
• e.g. HTTP, email
• Pro:
– simple
– client-side scripting offloads work onto the client
• Con:
– fat client
– inflexible
Three-Tier Architecture
• Application Server sits between client and
database
Three-Tier Pros
• flexible: can change one part without affecting
others
• can connect to different databases without
changing code
• specialization: presentation / business logic /
data management
• can cache queries
• can implement proxies and firewalls
Three-Tier Cons
• higher complexity
• higher maintenance
• lower network efficiency
• more parts to configure (and buy)
N-Tier Architecture
• Design your application using as many “tiers”
as you need
• Use Object-Oriented Design techniques
• Put the various components on whatever host
makes sense
• Java allows N-Tier Architecture, especially with
RMI and JDBC
Database Technologies
• Hierarchical
– obsolete (in a manner of speaking)
– any specialized file format can be called a hierarchical DB
• Relational (aka SQL) (RDBMS)
– row, column
– most popular
• Object-relational DB (ORDBMS)
– add inheritance, blobs to RDB
– NOT object-oriented -- “object” is mostly a marketing term
• Object-oriented DB (OODB)
– data stored as objects
– high-performance for OO data models
Relational Databases
• invented by Dr. E.F.Codd
• data stored in records which live in tables
• maps row (record) to column (field) in a single
table
• “relation” (as in “relational”) means row to
column (not table to table)
Joining Tables
• you can associate tables with one another
• allows data to nest
• allows arbitrarily complicated data structures
• not object-oriented
Join example
• People
– name
– homeaddress
– workaddress
• Addresses
– id
– street
– state
– zip
SQL
• Structured Query Language
• Standardized syntax for “querying” (accessing)
a relational database
• Supposedly database-independent
• Actually, there are important variations from
DB to DB
SQL Syntax
INSERT INTO table ( field1, field2 ) VALUES (
value1, value2 )
– inserts a new record into the named table
UPDATE table SET ( field1 = value1, field2 =
value2 ) WHERE condition
– changes an existing record or records
DELETE FROM table WHERE condition
– removes all records that match condition
SELECT field1, field2 FROM table WHERE
condition
– retrieves all records that match condition
Transactions
• Transaction = more than one statement which
must all succeed (or all fail) together
• If one fails, the system must reverse all
previous actions
• Also can’t leave DB in inconsistent state
halfway through a transaction
• COMMIT = complete transaction
• ROLLBACK = abort
Part II: JDBC Overview
JDBC Goals
• SQL-Level
• 100% Pure Java
• Keep it simple
• High-performance
• Leverage existing database technology
– why reinvent the wheel?
• Use strong, static typing wherever possible
• Use multiple methods to express multiple
functionality
JDBC Architecture
Type I ODBC
ODBC
“Bridge” Driver
Type II
JDBC CLI (.lib)
“Native”
Type IV
“Pure”
Type I Drivers
• Use bridging technology
• Requires installation/configuration on client
machines
• Not good for Web
• e.g. ODBC Bridge
Type II Drivers
• Native API drivers
• Requires installation/configuration on client
machines
• Used to leverage existing CLI libraries
• Usually not thread-safe
• Mostly obsolete now
• e.g. Intersolv Oracle Driver, WebLogic drivers
Type III Drivers
• Calls middleware server, usually on database
host
• Very flexible -- allows access to multiple
databases using one driver
• Only need to download one driver
• But it’s another server application to install
and maintain
• e.g. Symantec DBAnywhere
Type IV Drivers
• 100% Pure Java -- the Holy Grail
• Use Java networking libraries to talk directly to
database engines
• Only disadvantage: need to download a new
driver for each database engine
• e.g. Oracle, mSQL
Part III: JDBC APIs
java.sql
• JDBC is implemented via classes in the java.sql
package
Loading a Driver Directly
Driver d = new
foo.bar.MyDriver();
Connection c = d.connect(...);
• Not recommended, use DriverManager
instead
• Useful if you know you want a particular driver
DriverManager
• DriverManager tries all the drivers
• Uses the first one that works
• When a driver class is first loaded, it registers
itself with the DriverManager
• Therefore, to register a driver, just load it!
Registering a Driver
• statically load driver
Class.forName(“foo.bar.MyDriver”);
Connection c =
DriverManager.getConnection(...);
• or use the jdbc.drivers system
property
JDBC Object Classes
• DriverManager
– Loads, chooses drivers
• Driver
– connects to actual database
• Connection
– a series of SQL statements to and from the DB
• Statement
– a single SQL statement
• ResultSet
– the records returned from a Statement
JDBC Class Usage
DriverManager
Driver
Connection
Statement
ResultSet
JDBC URLs
jdbc:subprotocol:source
• each driver has its own subprotocol
• each subprotocol has its own syntax for the
source
jdbc:odbc:DataSource
– e.g. jdbc:odbc:Northwind
jdbc:msql://host[:port]/database
– e.g. jdbc:msql://foo.nowhere.com:4333/accounting
DriverManager
Connection getConnection
(String url, String user,
String password)
• Connects to given JDBC URL with given user
name and password
• Throws java.sql.SQLException
• returns a Connection object
Connection
• A Connection represents a session with a specific database.
• Within the context of a Connection, SQL statements are
executed and results are returned.
• Can have multiple connections to a database
– NB: Some drivers don’t support serialized connections
– Fortunately, most do (now)
• Also provides “metadata” -- information about the database,
tables, and fields
• Also methods to deal with transactions
Obtaining a Connection