Challenges of Teaching OO Constructs with Databases Shahram

Challenges of Teaching OO Constructs with Databases Shahram Ghandeharizadeh Database Laboratory Computer Science Department University of Southern California

Outline l l l An overview of Introductory course to databases. Object-oriented challenges. Future role of object-oriented constructs in data intensive applications.

Database Systems l Used almost on a daily basis for either individual or business use. l Relational database vendors were one of the fastest growing sectors during the. COM boom!

Data Models Build a database of all my assets for licensing and royalty collection

Data Models Conceptual Logical Physical

Relational DBMS l Why? Ø Ø Ø Performance! Reduced application development time Use of SQL makes access to data more uniform: § § Software modularity, Extensibility

Challenge 1 l Make students aware of the importance of conceptual data modeling.

Challenge 1 l l Make students aware of the importance of conceptual data modeling. Solution: Ø No-one builds a house without a design.

Challenge 1 l l Make students aware of the importance of conceptual data modeling. Solution: Ø Ø No-one builds a house without a design. Michael Jackson is picky and won’t pay for a system that does not meet his requirements.

Relational DBMS l Why? Ø Ø Ø Performance! Reduced application development time Use of SQL makes access to data more uniform: § § Software modularity, Extensibility

Challenge 2 l Two ways to teach this course: Ø How to implement a DBMS? § Ø How to use a DBMS? § l l Protocols to realize atomic property of transactions Setup a web server with a database and build a shopping bag Key difference: discussion at both the logical and physical levels Both require use of OO constructs

Challenges Conceptual Logical Physical Abstraction, Inheritance, Encapsulation Reduction to tables with minimal: data duplication, potential for data loss and update anomalies Effective use of a DBMS, management of mismatch between tables and OO constructs

Conceptual Data Models l Entity-Relationship (ER) data model Ø Entities, Attributes, Relationships SS# name address Emp

Conceptual Data Models l Entity-Relationship (ER) data model Ø Entities, Attributes, Relationships Co-Pay SS# name address Emp Enrolled in Health Plan name

Conceptual Data Models l Entity-Relationship (ER) data model Ø Ø Entities, Attributes, Relationships Recursive relationships SS# name address Emp Married to

Conceptual Data Models l Entity-Relationship (ER) data model Ø Ø Entities, Attributes, Relationships Recursive relationships SS# name address Emp Works for

Conceptual Data Models l Entity-Relationship (ER) data model Ø Ø Entities, Attributes, Relationships Recursive relationships SS# name address Emp Works for date

Conceptual Data Models l Entity-Relationship (ER) data model Ø Ø Ø Entities, Attributes, Relationships Recursive relationships Inheritance student sid name Generalization Undergrad ISA Specialization graduate

Conceptual Data Models l l Abstraction, Inheritance, Encapsulation Exercise these concepts using in-class examples and homework assignments Ø A library database contains a listing of authors who have written books on various subjects (one author per book). It also contains information about libraries that carry books on various subjects.

Conceptual Data Models l l Abstraction, Inheritance, Encapsulation Exercise these concepts using in-class examples and homework assignments Ø Ø Ø A library database contains a listing of authors who have written books on various subjects (one author per book). It also contains information about libraries that carry books on various subjects. Entity sets: authors, subjects, books, libraries Relationship sets: wrote, carry, indexed

Conceptual Data Models l l Abstraction, Inheritance, Encapsulation Exercise these concepts using in-class examples and homework assignments Ø A library database contains a listing of authors who have written books on various subjects (one author per book). It also contains information about libraries that carry books on various subjects. title SS# authors wrote books libraries carry name address Subject matter isbn index subject

Data Models SS# name Emp address Works for Logical Physical

Relational Data Model l Prevalent in today’s market place. Ø Why? Performance! l Everything is a table! l Logical data design is the process of reducing an ER diagram to a collection of tables.

Logical Data Design l Trivial reduction: Ø Ø l An entity set = a table A relationship set = a table Pitfalls: Ø Ø Ø Duplication of data Unintentional loss of data Data ambiguity that impacts software design, resulting in update anomalies

Data Duplication SS# Emp name Works for address SS# Name Address SS# MGR SS# 396 Shahra Seattle m 396 400 Asoke 200 400 120 400 200 Joe Chicago New York

Data Duplication SS# Emp name Works for address SS# Name Address SS# MGR SS# 396 Shahra Seattle m 396 400 Asoke 200 400 120 400 200 l Joe Chicago New York The SS# column is duplicated!

Data Duplication: Solution l Merge the two tables into one: SS# Emp name Works for address SS# Name Address 396 Shah ram Seatt le 400 Asok e Chic ago NULL 200 Joe New York 400 MGR SS#

Data Loss l Ford maintains warehouses containing different automobile parts Part# Location 123 Piston Tijuana 203 Cylinder Michigan 877 Bumper Michigan 389 l Description Seats Arizona Records are inserted and deleted based on availability of a part at a warehouse

Data Loss (Cont…) l When a warehouse becomes empty, it is lost from the database: Part# Location 123 Piston Tijuana 389 l Description Seats Arizona Solution: utilize two different tables Part# Description WHID Location 123 Piston 12 12 Tijuana 389 Seats 45 45 Arizona

Data Ambiguity l Represent faculty of a department as: Faculty Ghandeharizadeh Comp Sci SAL Papadopoulos Comp Sci SAL Bohem l Department Location Comp Sci SAL A change of address for a faculty might be for the entire department. This cannot be differentiated with this table design!

Data Ambiguity l Utilize two tables: Faculty Department Location Ghandeharizadeh Papadopoulos Jenkins Bohem Comp Sci Bio Medical Comp Sci SAL Sex Ed BOVARD Bio Medical HEDCO

Data Ambiguity (Cont…) l Employees of a bi-lingual company having different skills. Employee Language Asoke Teach Hindi Asoke Cook French Asoke Null German Asoke l Skill Program English Update anomalies!

Data Ambiguity: Solution l Utilize two tables: Employee Skill Asoke Teach Asoke Cook Asoke Program Language Asoke Hindi Asoke French Asoke German Asoke English

Logical Data Design l A quest to flatten objects with minimal data duplication, loss of data, and update anomalies! l William Kent, “A Simple Guide to Five Normal Forms in Relational Database Theory”, Communications of the ACM 26(2), Feb 1983, 120 -125.

Data Models SS# name Emp address Works for Logical Data Design SS# Name Address MGR SS# 396 Shahram Seattle 400 Asoke Chicago Null Physical

Physical Implementation l Reconstruct main memory objects for manipulation and presentation: Ø Specify class definitions § Ø Ø Ø Typically correspond to entity-sets Populate an instance of a class by issuing SQL queries to a DBMS Update instances in memory Flush dirty instances back to DBMS § Potential use of transactions

Type Mismatch l A column of a row must be a primitive such as an integer, real, etc. Ø l l It may NOT be an array of integers or object pointers A property (attribute) of a class might be of a multi-valued type, e. g. , an array, a vector, etc. Changes in software may impact the design of tables. (Management of type mismatch by the system designer. )

Implementation l Set operators in the DBMS Ø Ø l Does set A contain set B? Does value v 1 appear in set A? Aggregates in the DBMS Ø Ø Ø Compute average employee salary Count the number of employees Find the oldest employee

Challenges Conceptual Logical Physical Abstraction, Inheritance, Encapsulation Reduction to tables with minimal: data duplication, potential for data loss and update anomalies Effective use of a DBMS, management of mismatch between tables and OO constructs

A Shift in Computing Internet 1985 -2000 Server-centric Dumb clients Hardware-driven User to app Information access One-way Monolithic islands Integration an afterthought Challenge: scale 1999+ Distributed Smart clients Software-driven User to app; app to app Information action Two-way peer-to-peer Integration by design Challenge: value

Future Vision l l In the future, any two IT components will automatically integrate and “communicate” with one another, even though they were not specifically designed to interoperate How? Ø Ø Ø Semantics Standards Concept of “software and data” as a service, web service, e. g. , § § Google as a web service Microsoft Teraserver web services Experian (TRW) credit report web services Etc.

XML l A standard for data interoperability among web services Language independent Ø § Sun’s Java, Microsoft’s C# Device and software platform independent Ø l l l Motorola i 85 s J 2 ME l l Compaq i. PAQ Windows CE Strong. ARM l l l PERL Apache 2. 0 My. SQL Linux l l l . NET SQL 2000 Commerce server Windows 2000

Future Challenge l l Educate students to see Internet as an object-oriented software platform! Software at an Internet scale must be: Ø Ø Robust: Physical location independence Ensure availability of data and functionality at all times Modular and Extendible Integrate with other software components