1. Fundamentals, Design, and Implementation, 9/e by David M. Kroenke BSA206 Database Management Systems Lecture 21: Databases and the Web Chapters 12, 13 & 14

2. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 2 Copyright © 2004 Introduction  Because database applications today reside in a complicated environment, various standards have been developed for accessing database servers  Some of the traditional standards are –OBDC (Open Database Connectivity) is the early standard for relational databases –OLE DB is Microsoft’s object-oriented interface for relational and other databases –ADO (Active Data Objects) is the Microsoft standard providing easier access to OLE DB data for the non- object-oriented programmer

3. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 3 Copyright © 2004 Web Server Data Environment  Web server needs to publish applications that involve different data types

4. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 4 Copyright © 2004 Role of OBDC

5. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 5 Copyright © 2004 Role of OLE DB

6. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 6 Copyright © 2004 Role of ADO

7. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 7 Copyright © 2004 OBDC  ODBC (Open Database Connectivity) standard provides a DBMS-independent means for processing relational database data  It was developed in the early 1990s by an industry committee and has been implemented by Microsoft and many other vendors  The goal is to allow a developer to create a single application that can access databases supported by different DBMS products without needing to be changed or recompiled

8. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 8 Copyright © 2004 ODBC Architecture

9. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 9 Copyright © 2004 OBDC Components  OBDC consists of data source, application program, drivermanager, and DBMS driver  Data source is the database, its associated DBMS, operating system, and network platform –An ODBC data source can be a relational database, a file server, or a spreadsheet  Applications program issues requests to create a connection with a data source

10. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 10 Copyright © 2004 OBDC Components (cont.)  Driver manager determines the type of DBMS for a given ODBC data source and loads that driver in memory  DBMS driver processes ODBC requests and submits specific SQL statements to a given type of data source –A single-tier driver processes both ODBC calls and SQL statements –A multiple-tier driver processes ODBC calls, but passes the SQL requests to the database server

11. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 11 Copyright © 2004 OBDC Driver Types

12. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 12 Copyright © 2004 Conformance Levels  Levels of conformance balance the scope of OBDC standard  Two types of conformance levels –ODBC conformance levels concern the features and functions that are made available through the driver’s application program interface (API) A driver API is a set of functions that the application can call to receive services –SQL conformance levels specify which SQL statements, expressions, and data types a driver can process

13. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 13 Copyright © 2004 Introduction to XML and ADO.NET  Database processing and document processing need each other –Database processing needs document processing for expressing database views –Document processing needs database processing for storing and manipulating data  As Internet usage increased, organizations wanted to make their Web pages more functional by displaying and updating data from organizational databases

14. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 14 Copyright © 2004 XML  XML, or Extensible Markup Language, developed in early 1990s –XML is a subset of SGML, or Standard Generalized Markup Language  Today XML is a hybrid of document processing and database processing –It provides a standardized yet customizable way to describe the content of documents –XML documents can automatically be generated from database data, and vice versa  SOAP is an XML-based standard protocol for sending messages of any type, using any protocol over the Internet

15. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 15 Copyright © 2004 XML (cont.)  XML is used for describing, representing, and materializing database views  XML is better than HTML because –It provides a clear separation between document structure, content, and materialization –It is standardized but allows for extension by developers –XML tags accurately represent the semantics of their data  Document Type Declarations (DTDs) and XML Schemas can be used to describe the content of XML documents  Both Oracle and SQL Server can produce XML documents from database data

16. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 16 Copyright © 2004 ADO.NET  ADO.NET is a new, improved, and greatly expanded version of ADO that was developed for the Microsoft.NET initiative  It incorporates all of the functionality of ADO and facilitates the transformation of XML documents to and from database data  It uses datasets, which are in-memory, fully-functioned, independent databases

17. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 17 Copyright © 2004 Role of ADO.NET  ADO.NET serves as an intermediary between all types of.NET applications and the DBMS and database

18. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 18 Copyright © 2004 Data Provider  A.NET data provider is a library of classes that provides ADO.NET services  Microsoft’s provides three data providers –OLE DB data provider can be used to process any OLE DB-compliant data source –SQLClient data provider is purpose-built for use with SQL Server –OracleClient data provider is purpose-built for use with Oracle

19. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 19 Copyright © 2004 Data Provider Components

20. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 20 Copyright © 2004 Data Provider Components  A connection object is similar to the OBDC’s connection object  A command object is created on an established connection  A data reader provides read-only, forward-only, fast access to database data  An application can get and put data to and from the database using the command object  A dataset is an in-memory database that is disconnected from any regular database –It distinguishes ADO.NET from the previous data access technology

21. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 21 Copyright © 2004 The ADO.NET Dataset  A dataset is an in-memory database that is disconnected from any regular database  Datasets can have –Multiple tables, views, and relationships Tables may have surrogate key (auto increment columns), primary keys, and be declared as unique –Referential integrity rules and actions –The equivalent of triggers  Datasets may be constructed from several different databases and managed by different DBMS

22. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 22 Copyright © 2004 JDBC  JDBC is an alternative to ODBC and ADO that provides database access to programs written in Java

23. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 23 Copyright © 2004 Java Servlet and Applet  An applet is a compiled, machine-independent, Java bytecode program that is transmitted to a browser via HTTP and is invoked using the HTTP protocol  A servlet is a Java program that is invoked on the server to respond to HTTP requests  Type 3 and Type 4 drivers can be used for both applets and servlets  Type 2 drivers can be used only in servlets

24. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 24 Copyright © 2004 JDBC Components

25. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 25 Copyright © 2004 MySQL  MySQL is an open source DBMS that runs on UNIX, Linux, and Windows  MySQL is easy to use, relatively inexpensive (no license fee), and can provide fast query processing  Limitations –MySQL does not support views, stored procedures, or triggers –Referential integrity can be defined, but it is not enforced by MySQL

26. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 26 Copyright © 2004 MySQL (cont.)  MySQL maintains a data dictionary in a database named mysql  The user and db tables can be queried to determine user permissions  To access MySQL from JDBC, the user account must be granted access to the database, either from any location or from a TCP/IP address that represents the local computer

27. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 27 Copyright © 2004 Concurrency Control  MySQL provides limited support for concurrent processing –There is no support for transactions, i.e., no COMMIT or ROLL BACK statements or transaction isolation  MySQL locks at the table level –This may cause throughput problem –Shared read locks are obtained when processing SELECT statements –Exclusive locks are obtained when processing INSERT, UPDATE, or DELETE

28. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 28 Copyright © 2004 Concurrency Control (cont.)  Users can surround transaction logic with LOCK TABLES and UNLOCK TABLES commands  Deadlock is prevented by allowing, at most, one lock statement to be open at a time  Dirty reads are possible if some applications roll back their own work and do not surround their activity with table locks

29. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 29 Copyright © 2004 Backup and Recovery  MySQL provides limited backup and recovery facilities  There is a backup utility that augments the operating system copy utilities  MySQL maintains a log of commands processed but no before and after images, nor data values from bulk updates or deletions  To restore a database, an older version of the database is copied back, and the commands in the log are reapplied

30. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 30 Copyright © 2004 Form Design  Form structure should reflect the View structure  The semantics of the data should be graphically evident  The form structure should encourage appropriate action  GUI form constructs –Drop-down lists –Option buttons –Check boxes –Web forms –Natural cursor movement –Pervasive keys (e.g. Esc and function keys)

31. Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. Kroenke Lecture 21 / Slide 31 Copyright © 2004 Report Design  Report structure should reflect the underlying View structure –e.g. (generally) group data from same table together Invoice customer data (name/address) Invoice order data (order number and date) Invoice product data (item code/description) Invoice order-line data (quantity, price, discount)