~~SLIDESHOW~~
====== Enterprise Integration-Tier Services ======
* The Enterprise Integration Tier is where the Enterprise Knowledge exists.
* There is a prime role of relational databases here.
* Most databases use the Relational Database Model.
* Defined and queried in a dialect of SQL
* Need to map relational tables to objects and back.
* We will introduce SQL and the Java Database Connectivity (JDBC) API and go on to discuss persistence.
* Enterprise Integration is not just about databases so we will conclude with some other examples.
===== Lecture Contents =====
* **[[#What is a Database?|An introduction to relational databases and SQL]]**
* [[#The Trouble with Databases|JDBC -- Java database connectivity API]]
* [[#Immortal Objects]]
* [[#Persistence Patterns]]
* [[#Other forms of Enterprise Integration]]
===== What is a Database? =====
* Programming is data processing
* Data is central to everything that you do with a computer
* A database is a specialized tool for data storage
===== What is a Relational Database? =====
Relational databases are most common form of database:
* Consists of a set of tables.
* Each table consists of a set of records (rows of the table).
* Each record consists of a set of attributes (columns of the table).
* Rows of one table can be related to rows of another.
===== An example: CDs from a Music Collection =====
^ Artist ^ Title ^ Category ^ Year ^
|The Cure|Pornography|Alternative|1983|
|Garbage|Garbage|Alternative|1996|
|Hole|Live Through This|Alternative|1994|
|Nine Inch Nails|The Downward Spiral|Industrial|1994|
|Public Image Limited|Compact Disk|Alternative|1985|
|The Sex Pistols|Never Mind the Bollocks: Here's the Sex Pistols|Punk|1977|
|Skinny Puppy|Last Rights|Industrial|1992|
|Wire|A Bell is a Cup Until it is Struck|Alternative|1989|
===== Johnny Rotten Night for a Party =====
* Easy to select CDs for an //Alternative// or a //Punk// night.
* What if we want a Johnny Rotten night?
* No data for that in the table.
* Need another table of musicians.
^Last name^First name^Nickname^
|Jourgenson|Al| |
|Lydon|John|Johnny Rotten|
|Smith|Robert| |
===== Keys (1) =====
In order to relate musicians to bands and bands to CDs we need a unique key to the data.
^album_id^ Artist ^ Title ^ Category ^ Year ^
|1|The Cure|Pornography|Alternative|1983|
|2|Garbage|Garbage|Alternative|1996|
|3|Hole|Live Through This|Alternative|1994|
|4|Nine Inch Nails|The Downward Spiral|Industrial|1994|
|5|Public Image Limited|Compact Disk|Alternative|1985|
|6|The Sex Pistols|Never Mind the Bollocks: Here's the Sex Pistols|Punk|1977|
|7|Skinny Puppy|Last Rights|Industrial|1992|
|8|Wire|A Bell is a Cup Until it is Struck|Alternative|1989|
===== Keys (2) =====
In order to relate musicians to bands and bands to CDs we need a unique key to the data.
^artist_id^Last name^First name^Nickname^
|1|Jourgenson|Al| |
|2|Lydon|John|Johnny Rotten|
|3|Smith|Robert| |
===== Logical Data Model for Sample Database =====
{{:at-m42:logical-data-model.png?545|Logical data model}}
----
Interpretation of the //logical data model//:
* each band has one or more albums;
* each album belongs to exactly one band;
* each band contains one or more musicians;
* each musician is a member of one or more bands.
===== Physical Data Model =====
{{:at-m42:physical_data_model.png?713|physical data model}}
===== UML to Physical Data =====
{{:at-m42:uml-to-physical.png?450|UML to physical data}}
----
Classes, objects, properties and methods:
- Class maps to table
- Each object will be a row in the table
- Each property will be a column in the table
- Only properties are stored, no place in the database for methods.
Associations:
- //One to many associations//: index to //one// side is stored in a column in the //many// table as a //foreign key//.
- //Many to many associations//: need a cross reference table containing indices to both linked tables as //foreign keys//.
Object model: unique id implied.
Relational model: unique id must be explicit.
===== An Introduction to SQL =====
* All major databases support the Structured Query Language (SQL).
* SQL is not a programming language as such.
* An example of SQL is
SELECT title FROM albums
[[#The Trouble with Databases|Skip to JDBC ->]]
===== SQL commands =====
There are essentially only five SQL commands:
* ''CREATE'' -- //defines a new table//
* ''INSERT'' -- //inserts a record into a table//
* ''UPDATE'' -- //updates an existing record//
* ''DELETE'' -- //deletes a record from a table//
* ''SELECT'' -- //finds records in database// * All major databases support the Structured Query Language (SQL).
===== CREATE =====
* Before you can put data into a database you need to create the tables:
CREATE TABLE table_name (
column_name column_type column_modifiers,
...,
column_name column_type column_modifiers)
===== CREATE Musicians =====
* Unfortunately, this is database specific. In MS Access (where it is called a data definition query) this works:
CREATE TABLE musicians (
musician_id INT PRIMARY KEY,
last_name CHAR(40),
first_name CHAR(40),
nickname CHAR(40))
===== CREATE (2) =====
* The database-dependent part of the ''CREATE'' statement lies in the column modifiers.
* These might be modifiers such as ''NOT NULL'', ''PRIMARY KEY'', or other modifiers that say something about the column and the kind of data it can take.
* You have to //read the manual//.
===== INSERT =====
* Used to add data to tables. Called an //append query// in Access.
INSERT INTO table_name (column_name, ..., column_name) VALUES (value, ..., value)
* First value matches to first named column, 2nd to 2nd etc (types have to match column types in the table)
INSERT INTO musicians (musician_id, last_name, first_name, nickname)VALUES (2, 'Lydon', 'John', 'Johnny Rotten')
* Has to be repeated for every data record!
===== UPDATE =====
* Used to add modify the data in a table. Called an //update query// in Access.
UPDATE table_name
SET column_name = value,
...,
column_name = value
WHERE column_name = value
===== UPDATE Examples =====
* E.g. to change date in //The Downward Spiral//
UPDATE albums
SET year = 1994
WHERE album_id = 4
* Can be used to update several records at once:
UPDATE albums
SET category = 'old music'
WHERE year < 1980
===== DELETE =====
* A lot like the update query. Used to delete rows that match a where clause. Called a //delete query// in Access.
DELETE FROM table_name
WHERE column_name = value
* E.g. to delete //The Downward Spiral// from your collection
DELETE FROM albums
WHERE album_id = 4
===== SELECT =====
* Most common type of query.
SELECT column_name, ..., column_name FROM table_name
WHERE column_name = value
* E.g to select all of the industrial albums.
SELECT title FROM albums
WHERE category='industrial'
===== Query By Example =====
* In user friendly tools like //Access// it is possible to create queries and relationships without having to actually write any SQL.
* Called "query by example".
* A good way to create your queries for use in Groovy or Java!
===== Joins and … =====
* When you want to follow relationships such as "//find all albums on which Johnny Rotten played//" you need to follow the relationships between tables using //joins//.
* A join creates a virtual table on the fly that contains data from two or more tables. E.g.
SELECT bands.band_name FROM bands.albums
WHERE albums.category='alternative'
AND bands.band_id = albums.artist
* But we still need to relate //album// to //artist// for which there is no direct link. For this we need a //sub query//.
===== … Sub-queries =====
* To relate //album// to //artist// for which there is no direct link we need a sub query.
* In this case we need to select all the bands for which Johnny Rotten was a musician...
* ... and then get the album titles for those bands.
SELECT title
FROM albums
WHERE artist IN (
SELECT bands.band_id
FROM bands, band_musicians
WHERE band_musicians.musician_id = 2
AND bands.band_id = band_musicians.band_id )
===== Lecture Contents =====
* [[#What is a Relational Database?|An introduction to relational databases and SQL]]
* **[[#The Trouble with Databases|JDBC -- Java database connectivity API]]**
* [[#Immortal Objects]]
* [[#Persistence Patterns]]
* [[#Other forms of Enterprise Integration]]
===== The Trouble with Databases =====
* One of the major problems with databases has been the feature wars between the database companies.
* There is a "standard" database language, Structured Query Language (SQL-92), but you must usually know which database vendor you're working with despite the standard.
* JDBC is designed to be platform-independent, so you don't need to worry about the database you're using while you're programming.
* However, it's still possible to make vendor-specific calls from JDBC so you aren't restricted from doing what you must.
===== A Word about SQL and Portability =====
* One place where programmers may need to use SQL type names is in the SQL ''TABLE CREATE'' statement when they are creating a new database table and defining the SQL type for each column.
* Significant variations between SQL types supported by different database products.
* E.g. large binary values:
* Oracle: ''LONG RAW'',
* Sybase: ''IMAGE''
* Informix: ''BYTE''
* DB2: ''LONG VARCHAR FOR BIT DATA''.
* Therefore, if database portability is a goal you should try to use only generic SQL type identifiers.
===== Design for Portability =====
* Reliance on a third party product can break the platform-independence of Java.
* You should try to limit the impact of such things by choice of suitable abstractions.
* E.g.
* Isolate database-specific code in order to centralize any changes that you may need to perform to port to a new environment.
* Consider use of configuration files to specify database driver, table definition, query and update commands, etc that may vary.
* Use abstractions [see later]:
* map object attributes to database row
* map query result to collection
* Note when an object changes ... it will need to be updated in the database.
===== What is JDBC? =====
A single API for database access:
* JDBC is an SQL--level API.
* JDBC capitalizes on the experience of existing database APIs.
* JDBC is designed for simplicity.
===== SQL-level API =====
* You construct SQL statements and embed them (as strings) inside Java API calls.
* You are using SQL.
* JDBC smoothly translates between world of the database and the world of the Java application.
* Results from the database are returned as Java objects.
* Access problems are thrown as exceptions.
* You can even completely hide the database from your application objects (as we shall see)
===== Based on existing APIs =====
* The need to provide a universal access API is not new.
* Open Database Connectivity (ODBC) a standard API for databases on the windows platform provided some inspiration.
* One of the first drivers developed was the JDBC-ODBC bridge which makes it easy to take to a database under windows.
* Other inspiration comes from such APIs as the X/OPEN SQL Call Level Interface (CLI).
* By basing JDBC on such industry standards improved the chance of take up by the industry.
===== Designed for Simplicity =====
* Simple and common tasks use simple interfaces.
* The method calls you make correspond to the logical operations you'd think of doing when gathering data from a database:
* connect to the database
* create a statement
* execute the query
* look at the result set.
* JDBC provides several other interfaces for handling more complex and unusual tasks.
===== The Structure of JDBC =====
{{ :at-m42:jdbc-structure.png?358|The Structure of JDBC}}
* Each Java interface is implemented differently by a database vendor.
* The set of classes that implement the interface is called a driver.
* You only need to use the interface which is the same for all databases.
===== Basic Classes and Interfaces of the JDBC API =====
{{:at-m42:jdbc-api.png?657|Basic Classes and Interfaces of the JDBC API}}
===== Databases and Drivers =====
* //Type 1// -- bridging technology. Access database through another database interface. E.g. JDBC-ODBC. Requires software to be installed on client machine.
* //Type 2// -- native API drivers. Driver calls C or C++ methods provided by vendor. Requires software to be installed on client machine.
* //Type 3// -- generic network API that accesses database on a server machine via a middleware application that translates client requests into database API on the server. No software needed on client.
* //Type 4// -- direct connection to network protocols built into database using Java sockets. Usually only available from the database vendor.
===== JDBC Driver Managers =====
* To allow for platform independence, JDBC provides a driver manager that dynamically maintains all the driver objects that your database queries will need.
* If you have three different kinds of vendor databases to connect to, you'll need three different driver objects.
* The driver objects register themselves with the driver manager at the time of loading, and you can force the loading using ''Class.forName()''.
===== Database URL =====
* To open a database, you must create a "database URL" that specifies:
* That you're using JDBC with "''jdbc''".
* The "subprotocol": the name of the driver or the name of a database connectivity mechanism.
* The database identifier. This generally provides a logical name that is mapped by the database administration software to a physical directory where the database tables are located.
* All this information is combined into one string, the "database URL."
* Examples:
String dbUrl = "jdbc:odbc:CDs";
jdbc:rmi://192.168.170.27:1099/jdbc:cloudscape:db
===== Making a Connection =====
* To connect to the database, call the static method ''DriverManager.getConnection( )'' and pass it the database URL, the user name, and a password to get into the database.
* You get back a ''Connection'' object that you can then use to query and manipulate the database.
* The following example opens a database of CD data and looks for a CD's that match a given theme as given on the command line.
* It selects only the CDs that match the category then prints out the CD data:
===== Find CDs for a party =====
See notes for listing.
----
extern> http://www.cpjobling.org.uk/~eechris/at-m42/Examples/lecture14/Lookup.java
===== … define db attributes =====
static final String DB = "jdbc:derby:CDs";
static final String USER = "";
static final String PASSWORD = "";
static final String DRIVER = "org.apache.derby.jdbc.EmbeddedDriver";
----
* These values used to make the connection: **dbURL**: protocol "''jdbc''"; subprotocol "''derby''"; database id: "CDs"
* user and password are used for access control if database management system needs them.
===== … load the driver =====
Class.forName(DRIVER);
----
* This could throw ''ClassNotFoundException'' which we don't bother the catch!
* That's why it has to be declared as an exception that may be thrown by ''main()''.
===== … connect to database =====
Connection c = DriverManager.getConnection(DB, USER, PASSSWORD);
----
* The atabase driver knows how to connect to databases that it manages.
* Connection object represents the database for rest of session.
* Possible (and desirable) to pool connections if many clients may access same database simultaneously.
* Database management system is responsible for handling simultaneous updates.
===== … create a "statement" object =====
Statement s = c.createStatement();
----
* ''Statement'' represents and atomic interaction with the database.
* Can be used to query database, create tables, update records or delete records.
* SQL code is passed to statement object (as a ''String'').
* ''Statement'' object returns a ''ResultSet''.
* For efficiency, statements can be "compiled" by DBMS so that they run faster.
===== … execute query and return results =====
// SQL query
String QUERY = "SELECT albums.title, bands.band_name, albums.year\n"
+ " FROM bands INNER JOIN albums ON \n"
+ " bands.band_id = albums.artist \n"
+ " WHERE (((albums.category)='" + args[0] + "'))"
// SQL code:
ResultSet r = s.executeQuery(QUERY);
----
* ''executeQuery()'' takes a ''String'' parameter
* String is SQL code in this case
* Returns a ''ResultSet'' (an '''Iterator'')
* Query term ''albums.category'' is taken from **arguments** to program.
* ''Result'' is fields: //albums.title//, //bands.band_name//, //albums.year//; for records in join of albums and bands whose //albums.catogory// field matches ''args[0]''.
* Easiest way to create a query is to use query by example with a database tool.
===== … process results =====
while (r.next()) {
// Capitalization doesn't matter:
System.out.println("Have a result!");
System.out.println(r.getString("Title") + " by "
+ r.getString("bAND_NAME") + " released in "
+ r.getString("YEAR") + ".");
}
----
* ''r'' is an ''Iterator''. ''r.next()'' moves "cursor" to next result.
* Returns false if there is no next (query returned nothing) or have reached last record.
* You must call ''next()'' before first result is used.
* ''getXxxx(String //columnName//)'' gets item of type ''Xxxx'' for column named by ''String''. Most standard Java types (including ''Object'') can be returned.
* ''updateXxxx(String //columnName//, Xxxx //value//)'' can be used to update a record value.
===== … close down connection and clean up =====
s.close();
----
* Closing the statement also closes the results set.
* We do not need to close the database connection explicitly as it's closed when the program exits.
* If you have a pool of connections you'd want to release your connection (returning it to the pool) when you've finished.
===== Simplified Queries with Groovy =====
extern> http://www.cpjobling.org.uk/~eechris/at-m42/Examples/lecture14/Lookup.groovy
----
As with other examples we've seen in this course, the designers of Groovy have created a JDBC API that further simplifies the interaction with a JDBC-supported database (and as we'll see, takes this even further in the Grails framework).
In this example we note immediately that the opening of a connection to a database is achieved in a single //factory method// ''def sql = Sql.newInstance(DB, USER, PASSWORD, DRIVER)''. Once we have the ''Sql'' object, we can use the ''eachRow'' method, which takes a closure, to process each row. Note also, that the results are returned as a Map, so we can refer to each field as ''r.band_name'' (or if you prefer ''%%r['band_name']%%'' rather than the more long-winded ''r.getString(%%"bAND_NAME"%%)''). Also, because Groovy is a dynamic language, we need not know, nor care, what the type of the field represents.
Further more, the use of multi-line strings simplifies the creation of queries, and because ''String'' interpretation works, queries can easily be made //programmatic//.
===== SQL Data-types and Java Data-types =====
* Should always use Java data-types and map these to database rather than the other way around.
^Java Type^SQL Types (from ''java.sql.Types'')^
|''boolean''|''BIT''|
|''byte''|''TINYINT''|
|''short''|''SMALLINT''|
|''int''|''INTEGER''|
|''long''|''BIGINT''|
|''float''|''REAL''|
|''double''|''DOUBLE''|
|''java.Math.BigDecimal''|''NUMERIC''|
|''java.lang.String''|''VARCHAR or LONGVARCHAR''|
===== SQL Data-types and Java Data-types (2) =====
^Java Type^SQL Types (from ''java.sql.Types'')^
|''byte[]''|''VARBINARY'' or ''LONGVARBINARY''|
|''java.sql.Date''|''DATE''|
|''java.sql.Time''|''TIME''|
|''java.sql.Timestamp''|''TIMESTAMP''|
|''java.sql.Blob''|''//BLOB//'' (SQL3 datatype)|
|''java.sql.Clob''|''//CLOB//'' (SQL3 datatype)|
|''java.sql.Array''|''//ARRAY//'' (SQL3 datatype)|
|''java.sql.Ref''|''//REF//'' (SQL3 datatype)|
|''java.sql.Struct''|''//STRUCT//'' (SQL3 datatype)|
===== What else does JDBC provide? =====
* Can call JDBC from a servlet or from an applet.
* It is possible to create a database and populate it from Java. Also possible to delete tables from a database.
* Select, update, delete queries supported.
* ''DatabaseMetaData'' interface is huge! It is provided to allow you to query the capabilities of a database from Java and work around database idiosyncrasies.
* Many more features provided for enterprise applications. Support for database transactions, rollback, etc.
===== Transaction Logic (1) =====
* Often you need to issue many updates or inserts together as part of a single transaction
* New band: add all musicians in the band at the same time.
* Individual SQL statements may fail, e.g. because of a network problem.
* If we have a failure in the middle of a group of transactions you can be left with corrupt data.
* SQL allows you to group a set of commands that should be executed together into a transaction.
===== Transaction Logic (2) =====
* As //transaction// is one or more SQL statements that should be treated as a single unit of work.
* If one statement in the transaction fails, the whole transaction should be aborted, //including any statements that have been successfully executed//.
* If all the statements are successfully executed the changes can be made permanent.
* An abort is called a ''ROLLBACK'' -- database is left in the state it was in before transaction began.
* A transaction is made permanent with a ''COMMIT''.
* If not committed the database is not changed by a transaction!
===== Lecture Contents =====
* [[#What is a Relational Database?|An introduction to relational databases and SQL]]
* [[#The Trouble with Databases|JDBC -- Java database connectivity API]]
* **[[#Immortal Objects]]**
* [[#Persistence Patterns]]
* [[#Other forms of Enterprise Integration]]
===== Immortal Objects =====
* How to ensure that the state of your business objects survives (''persists'') beyond the ending of one process to the start of the next. E.g. to survive crashes and shutdown.
* Although you can use files for persistence, it doesn't scale well.
* These days you have to use a relational database. If you use Java to implement your application you have to use JDBC.
* How can persistence issues can be affectively hidden from the business objects that rely on it?
===== Persistence is Last Step in a Transaction =====
* In distributed applications we need transactions to guarantee data integrity.
* Commit if successful. Rollback if fails.
* Transaction choreographs a persistence operation.
* When the transaction is notified that it is complete it creates a //persistence transaction// which tells **each object modified in the transaction** to //insert//, //update// or //delete// itself in the persistent store.
* The persistence transaction makes sure that all data store accesses take place within a **single data store transaction** (i.e using the same connection object) and is **committed** at the end.
* The component model doesn't care about how the persistence is achieved. It only cares about the transaction.
===== Component Transaction and Persistence Transaction =====
{{:at-m42:persitence.png?417|Persistence transaction}}
===== Lecture Contents =====
* [[#What is a Relational Database?|An introduction to relational databases and SQL]]
* [[#The Trouble with Databases|JDBC -- Java database connectivity API]]
* [[#Immortal Objects]]
* **[[#Persistence Patterns]]**
* [[#Other forms of Enterprise Integration]]
===== Persistence Patterns: Transaction script =====
In many applications it is natural to work directly with the relational model, issuing SQL queries and parsing result sets.
* This is known as the //[[http://martinfowler.com/eaaCatalog/transactionScript.html|Transaction Script]]// pattern((All patterns discussed in this lecture are from //Patterns of Enterprise Application Architecture//. See [[Recommended Reading]] for bibliographic details.)): business logic is organized into procedures for each use case.
* Direct use of SQL is also well suited for aggregating queries and set-based updates (accessing large amounts of data or updating many tables in the same transaction)
===== Persistence Patterns: ORM =====
Another scenario is that you have simple queries returning small sets of rows (often in a single table), which receive selective updates.
* Little need for set-based updates
* Data entities mapped to persistent Java objects
* Business logic deals with these objects rather than the tables and records.
General term for this pattern is Object-Relational Mapping (ORM)
===== Patterns for ORM Strategies =====
* //[[http://martinfowler.com/eaaCatalog/activeRecord.html|Active record]]// – wraps a row in a database table, encapsulates the database access, and adds domain logic to the data.
* //[[http://martinfowler.com/eaaCatalog/dataMapper.html|Data mapper]]// – A layer of mappers that move data between objects and a database while keeping them independent of each other and the mapper itself.
* //[[http://martinfowler.com/eaaCatalog/queryObject.html|Query object]]// – An object that represents a database query
* //[[http://martinfowler.com/eaaCatalog/unitOfWork.html|Unit of work]]// – Maintains a list of objects effected by a business transaction and coordinates the writing of changes and the resolution of concurrency problems.
===== Persistence Frameworks =====
* You can "roll your own" persistence framework ...
* ... but it's a non-trivial task and fraught with difficulties and traps.
* Better to use an existing framework. Many available!
* All implement //Data Mapper//, //Query Object// and //Unit of Work// patterns to provide **Transparent Persistence** for Java objects.
----
Reese (see [[Recommended Reading]]) gives an extended example of the development of a persistence framework.
The most widely used persistence frameworks are:
* Java EE Container Managed Persistence (CMP) (more later),
* [[http://java.sun.com/jdo/index.jsp|Java Data objects]] (JDO) (Java extension),
* [[http://www.hibernate.org/|Hibernate]] (a widely deployed open source framework) and
* The "official" [[https://glassfish.dev.java.net/javaee5/persistence/#Java_Persistence_API|Java Persistence API]] (JPA) part of Java EE 5 and available as a standalone extension API for Java SE 6.
===== The Object/Relational Impedance Mismatch =====
* For all but the simplest domain models, there is no direct match from relational database to object model.
* OO concepts such as class, //polymorphism//, and //inheritance// have no direct analogy in an RDMS.
* RDMS concepts such as //normalized data//, //sets// and //efficient access// have no direct relationship in the OO world.
* It's best to keep the two worlds separate and in the domain of the experts.
* Use an ORM framework (if it's appropriate) to provide the bridge between the two worlds.
===== Some Issues that the Developers of an ORM Have to be Aware Of =====
* //Identity//: ensuring a record in a database is unique in a global sense.
* //Instantiated objects should be cached//: avoids a further trip to the database if it is needed in two separate transactions.
* "Dirty" objects (objects that have been created or changed in a transaction) //have to be committed to the database in a single atomic operation//.
* Objects that have not been changed do not need to be written back to the database.
* Queries may result in large numbers of records being returned from a database:
* Usually returned as a collection
* However objects in the collection should not be instantiated unless it is needed.
===== Choosing a Persistence Strategy (1) =====
* Many enterprise applications need to use legacy databases, or share the database with other systems, so choices are limited!
* Despite the hype, it is rare for an enterprise to change its database supplier, so it is often not worth completely abstracting the details of a DBMS out of code.
* It is worth providing a data access layer so that your business logic does not talk directly JDBC but goes through a set of //Data Access Objects//.
* If the database schema changes, it will be in the access layer that changes will be needed, not in the business logic.
* If the business logic changes, again, persistence code changes are limited to the access layer.
===== Choosing a Persistence Strategy (2) =====
* In some applications with a limited number of simple tables it will be quickest to use //active record// and talk directly to the database.
* If the application will require heavy use of set access, aggregation of data from many tables, or batch updates in many rows, a direct implementation using //transaction script// may be most efficient.
* ORM is a complex strategy which be of benefit only for complex domain models and or databases
===== Choosing a Persistence Strategy (3) =====
ORM can be of benefit if:
* Your application has the typical CRUD – create, retrieve, update, delete – workflow for domain objects.
* Objects are found in large sets but are updated and deleted individually.
* A large number of objects exist but they are "read-mostly"
* There is a natural mapping between classes and fields and database tables and records
* There are no unusual requirements such as the need to use customized SQL optimizations.
* For Java programmers ORM has the advantage of keeping SQL out of the code. But that is why we have DB architects!
===== Lecture Contents =====
* [[#What is a Relational Database?|An introduction to relational databases and SQL]]
* [[#The Trouble with Databases|JDBC -- Java database connectivity API]]
* [[#Immortal Objects]]
* [[#Persistence Patterns]]
* **[[#Other forms of Enterprise Integration]]**
===== Other Forms of Enterprise Integration =====
* Enterprise integration is not just about databases and SQL.
* Enterprise information systms also often have to be built in to enterprise applications.
* Main technologies for this form of integration is the Java Connectivity API and Web Services.
* May not be talking Java so CORBA and similar technologies may come into play.
----
Some examples of enterprise information systems are:
* Human Resources Systems
* Payroll systems
* Enterprise Resource Planning
* Business to Business Systems
* Enterprise communication systems
* Other //so-called// "legacy" systems
===== Lecture Summary =====
* [[#What is a Relational Database?|An introduction to relational databases and SQL]]
* [[#The Trouble with Databases|JDBC -- Java database connectivity API]]
* [[#Immortal Objects]]
* [[#Persistence Patterns]]
* [[#Other forms of Enterprise Integration]]
----
[[Home]] | [[lecture13|Previous Lecture]] | [[Lectures]] | [[lecture15|Next Lecture]]