Developing Object-Relational Database Applications

Developing Object-Developing Object-Relational Database Relational Database

Applications Applications

Paul BrownChief Plumber

INFORMIX Software

2

useruser .conference.conferenceInformixInformix

What We Will Talk AboutWhat We Will Talk About

• Plenty of Focus on Features & Functionality• Question is, “How to use it all?”

Object-Relational technology makes a fresh look at the process of database analysis and design useful.

• What is different, what is the same?• Many things are the same . . .• . . . some things are new.

Developers using an ORDBMS benefit by taking a more holistic approach to development than was

common with SQL-92 DBMS products.

• Plenty of Focus on Features & Functionality• Question is, “How to use it all?”

Object-Relational technology makes a fresh look at the process of database analysis and design useful.

• What is different, what is the same?• Many things are the same . . .• . . . some things are new.

Developers using an ORDBMS benefit by taking a more holistic approach to development than was

common with SQL-92 DBMS products.

3


Overview of TutorialOverview of TutorialOverview of TutorialOverview of Tutorial

• Design Objectives of Databases

• How are OR Database Similar/Different?

• What about the theory?

• Methodology Description

• Steps of a development procedure

• Analysis and design

• Implementation advice

• Examples as we go through

• Architecture Advice

• Back-end and middle-ware

• Component-centric development

• Design Objectives of Databases

• How are OR Database Similar/Different?

• What about the theory?

• Methodology Description

• Steps of a development procedure

• Analysis and design

• Implementation advice

• Examples as we go through

• Architecture Advice

• Back-end and middle-ware

• Component-centric development

4


Design ObjectivesDesign ObjectivesDesign ObjectivesDesign Objectives

Meet the Needs of End Users• Complete

• The Database needs to model everything that is relevant to the problem domain (PD).

• Correct• The Database needs to be an accurate model of the PD.

• Consistent• The database model should not contain redundant data.

• Flexible• The database should adapt to changing requirements.

• Efficient• Fast, scaleable and simple to administer.

Meet the Needs of End Users• Complete

• The Database needs to model everything that is relevant to the problem domain (PD).

• Correct• The Database needs to be an accurate model of the PD.

• Consistent• The database model should not contain redundant data.

• Flexible• The database should adapt to changing requirements.

• Efficient• Fast, scaleable and simple to administer.

5


Object-Relational Data ModelObject-Relational Data Model

• Based on Relational Model of Codd [1971]• Relation as storage abstraction and organizing

principle• Declarative programming as interface model

• An Object-Relational DBMS Provides• Physical abstraction (no byte level details for OR-

SQL)• Formal modeling techniques (normalization)

20 years of R&D have addressed most performance, reliability and scalability issues.

• Based on Relational Model of Codd [1971]• Relation as storage abstraction and organizing

principle• Declarative programming as interface model

• An Object-Relational DBMS Provides• Physical abstraction (no byte level details for OR-

SQL)• Formal modeling techniques (normalization)

20 years of R&D have addressed most performance, reliability and scalability issues.

6


Theoretic Overview ( 1/2 )Theoretic Overview ( 1/2 )Theoretic Overview ( 1/2 )Theoretic Overview ( 1/2 )

• Domains ( kinds or classes of data objects)• { a, b, c . . . }

• Attributes (named columns of a domain)• { A, B, C . . . }• Dom ( A ) a

• Relation Schema (set of attributes)

• { . . . X, Y, Z } where X {A, B, C . . }

• Relation (set of n-ary tuples over a relation schema)

• { . . P, Q, R . . } For P over X, P Dom ( Xi )

• We also say t: X Dom ( X )

• Domains ( kinds or classes of data objects)• { a, b, c . . . }

• Attributes (named columns of a domain)• { A, B, C . . . }• Dom ( A ) a

• Relation Schema (set of attributes)

• { . . . X, Y, Z } where X {A, B, C . . }

• Relation (set of n-ary tuples over a relation schema)

• { . . P, Q, R . . } For P over X, P Dom ( Xi )

• We also say t: X Dom ( X )

7


Theoretic Overview ( 2/ 2 )Theoretic Overview ( 2/ 2 )Theoretic Overview ( 2/ 2 )Theoretic Overview ( 2/ 2 )

Operations to Manipulate Relations• Projection (select sub-set of columns from relation)

• Given P over X, and Y X, < P, Y > Q over Y s.t. t P, t’ Q where t ( A ) = t’ ( A ) A Y.

• Restriction (select sub-set of tuples from relation )• Given P over X, and ( X ), < P, > Q over X s.t. t Q, (t) true.

• Join ( cross-product of two relations ) • Given P over X, and Q over Y, < P, Q > R over ( X Y ) s.t. t R, t’

P and t’’ Q where t [ X ] = t’, and t [ Y ] = t’’.

• Plus (Aggregate, Intersection, Division, Union . .)

Operations to Manipulate Relations• Projection (select sub-set of columns from relation)

• Given P over X, and Y X, < P, Y > Q over Y s.t. t P, t’ Q where t ( A ) = t’ ( A ) A Y.

• Restriction (select sub-set of tuples from relation )• Given P over X, and ( X ), < P, > Q over X s.t. t Q, (t) true.

• Join ( cross-product of two relations ) • Given P over X, and Q over Y, < P, Q > R over ( X Y ) s.t. t R, t’

P and t’’ Q where t [ X ] = t’, and t [ Y ] = t’’.

• Plus (Aggregate, Intersection, Division, Union . .)

8


Enough Greek!Enough Greek!Enough Greek!Enough Greek!

What does it look like in practice?• Declarative language programming

• Dynamic, run-time interpretation

What does it look like in practice?• Declarative language programming

• Dynamic, run-time interpretation

CREATE TABLE Employees ( Id Employee_Number PRIMARY KEY, Name PersonName NOT NULL, Date_of_Birth DATE NOT NULL, Address MailAddress NOT NULL, LivesAt st_point NOT NULL, Resume Document NOT NULL, Voice_Key Audio_Recording NOT NULL, Holidays SET ( Period NOT NULL ) );

How do you get to here, starting with a bunch of users, a small herd of programmers, and a budget.How do you get to here, starting with a bunch of users, a small herd of programmers, and a budget.

9


Development Road-mapDevelopment Road-mapDevelopment Road-mapDevelopment Road-map

1. Analyze the Problem Domain• Document the high level structure (E-ER)• Describe each kind of data (UML Class Diagrams)

2. Design and Implementation• Use User-Defined Types (UDT) and User-Defined Functions

(UDF) for Objects• Combine Objects into Schema Tables/Views• Queries to map to user views

3. Verify Each Step• Prototype UDT/UDFs• Normalize• Test performance against production scale loads

1. Analyze the Problem Domain• Document the high level structure (E-ER)• Describe each kind of data (UML Class Diagrams)

2. Design and Implementation• Use User-Defined Types (UDT) and User-Defined Functions

(UDF) for Objects• Combine Objects into Schema Tables/Views• Queries to map to user views

3. Verify Each Step• Prototype UDT/UDFs• Normalize• Test performance against production scale loads

10


Outline of Procedure: 3 Tier ModelOutline of Procedure: 3 Tier Model

1. Conceptual 2. Logical3. Physical

.

CREATE OPAQUE TYPE PersonName( internallength = variable, maxlen = 64 );

CREATE FUNCTION getFamilyName (..

CREATE TABLE Employees ( Id Employee_Id PRIMARY KEY, Dept Dept_Id REFERENCES Dept ( Id ), Name PersonName NOT NULL, DOB DATE NOT NULL . );..

11


Phase 1: Conceptual ModelingPhase 1: Conceptual Modeling

• Describe User Views of Problem Domain• Pictures instead of words

• Multiple Semantic Model Possibilities• Extended Entity-Relationship (E-ER) Modeling

• Object-Role Modeling (ORM or NIAM)

• Universal Modeling Language (UML)

• Use E-ER in this Tutorial• Familiar to most developers and analysts

• Concepts introduced here apply everywhere

• Describe User Views of Problem Domain• Pictures instead of words

• Multiple Semantic Model Possibilities• Extended Entity-Relationship (E-ER) Modeling

• Object-Role Modeling (ORM or NIAM)

• Universal Modeling Language (UML)

• Use E-ER in this Tutorial• Familiar to most developers and analysts

• Concepts introduced here apply everywhere

12


E-ER Diagrams for DummiesE-ER Diagrams for DummiesE-ER Diagrams for DummiesE-ER Diagrams for Dummies

Entity: Principle data objects in the problem domain. Typically identified with a noun term; Branch, Employee, etc

has_a Relationship: Association between Entities. Typically identified with a verb term; Manufacturers, WorksFor, etc. has_a relationships can have additional attributes.

Branch

Branch Product

Employees Branch

Full_Time

Production Sales

is_a Relationship: Inheritance relationship between Entities.

13


1.1 Describe High-Level E-ER1.1 Describe High-Level E-ER1.1 Describe High-Level E-ER1.1 Describe High-Level E-ER

Employees

Contractors Full_Time

Production Sales

Customer

When

Qty

Branch

Product

worked for

sold

manufactures

14


1.2 Describe Each Entity1.2 Describe Each Entity1.2 Describe Each Entity1.2 Describe Each Entity

Customer

KindName

Cust_NumId

Person_NameContact

Deliver_AddrAddress

Mail_AddrBill_Address

Employee

KindName

Employ_NumId

Person_NameName

Mail_AddrAddress

DocumentResume

Geo_PointLives_At

DATEDate_of_Birth

Products

KindName

UPC_CodeId

LabelStringName

Physical_SizeDimensions

MassCapacity

SET{ Color }Available_In

Price Currency

For each entity, name its attributes, and decide For each entity, name its attributes, and decide

what kind of data is in each of them.what kind of data is in each of them.

15


E-ER Modeling ReviewE-ER Modeling ReviewE-ER Modeling ReviewE-ER Modeling Review

• This is Really Nothing New• Better modeling of is_a relationships (inheritance)

• What Other Tasks?• Note Logical Keys in Entities

• Record arity of has_a relationships (1:N, N:M, etc)

• Record mandatory and optional relationships

• What is New?

Resist the temptation to analyze down to SQL-92 types. Within E-ER modeling, maintain a degree of

abstraction.

• This is Really Nothing New• Better modeling of is_a relationships (inheritance)

• What Other Tasks?• Note Logical Keys in Entities

• Record arity of has_a relationships (1:N, N:M, etc)

• Record mandatory and optional relationships

• What is New?

Resist the temptation to analyze down to SQL-92 types. Within E-ER modeling, maintain a degree of

abstraction.

16


Handling Multiple Conceptual ViewsHandling Multiple Conceptual ViewsHandling Multiple Conceptual ViewsHandling Multiple Conceptual Views

• Multiple Semantic Model Possibilities

• Extended Entity-Relationship Modeling

• Object-Role Modeling

• Universal Modeling Language

• What about their Object Model?

User Object Models often contain elements of interest to OR database developers. A UDT defined

in the database need not be used in a table.

• Multiple Semantic Model Possibilities

• Extended Entity-Relationship Modeling

• Object-Role Modeling

• Universal Modeling Language

• What about their Object Model?

User Object Models often contain elements of interest to OR database developers. A UDT defined

in the database need not be used in a table.

17


The ‘Object’ ConceptThe ‘Object’ Concept

“The most brutalized term in computer science”

• What is an ‘Object’?

• Atomic unit of meaning encapsulating both state and behavior.

• Objects mostly map to domains in Relational Theory

• Why is the Concept Useful?

• Intuitive way of describing ‘things’ in the data model

• These intuitions can drive user-defined type and user-defined function design.

“The most brutalized term in computer science”

• What is an ‘Object’?

• Atomic unit of meaning encapsulating both state and behavior.

• Objects mostly map to domains in Relational Theory

• Why is the Concept Useful?

• Intuitive way of describing ‘things’ in the data model

• These intuitions can drive user-defined type and user-defined function design.

18


1.3 Catalog the 1.3 Catalog the Kinds of DataKinds of Data1.3 Catalog the 1.3 Catalog the Kinds of DataKinds of Data

Product_Number String Physical_Size MassColor Employee_Num Person_Name Mail_AddressGeo_Point Document Customer_Num Delivery_AddressCurrency Bonus_Plan Period QuantityProduct Employees Full_Time_Emp Sales

Create a list of all of the different kinds of data identified in the schema and in the object

models. Some of these will be in more than one entity.

19


1.4 Use UML Class Diagrams1.4 Use UML Class Diagrams1.4 Use UML Class Diagrams1.4 Use UML Class Diagrams

Delivery_Address

String+ Address_Line_One

String+ Address_Line_Two

String+ City

Zip_Code+ ZipCode

String+ State

+ Delivery_Address(String, String, String, Zip_Code, Document)

+ Equal () - Compare()

String+ Country

Document+ Delivery_Notes

+ Label () + approximateMatches ()

Mail_Address

String+ Address_Line_One

String+ Address_Line_Two

String+ City

Zip_Code+ ZipCode

String+ State

+ Mail_Address(String, String, String, Zip_Code)

+ Equal () - Compare()

String+ Country

+ Label () + approximateMatches ()

20


Class Diagram DetailsClass Diagram DetailsClass Diagram DetailsClass Diagram Details

+ GeoPoint ( String ) -> GeoPoint,+ GeoPoint( FLOAT, FLOAT) -> GeoPoint,+ Latitude ( GeoPoint ) -> FLOAT,+ Longitude ( GeoPoint ) -> FLOAT+ Distance ( GeoPoint, GeoPoint ) -> FLOAT+ Quadrant ( GeoPoint ) -> CHAR(2)+ SetLatitude( FLOAT ) -> GeoPoint+ SetLongitude ( FLOAT ) -> GeoPoint[ Spatial Operators, R-Tree Support ][ Compare(), Equal, NotEqual ]

GeoPoint

- Longitude

- Latitude FLOAT

Ellispoid_Enum

FLOAT

- Ellipsoid

State Elements(Data Structure)

Kind of Data in Element

Interface Methods

Constructors

Extract Data

Operators

ModifiersWhy These?

21


Implementation Tip # 1Implementation Tip # 1Implementation Tip # 1Implementation Tip # 1

• Object Classes are used in OR-SQL queries• SELECT DISTINCT, UNION are SQL operations• Merge-Join and Hash-Join for internal efficiencies

• Object Classes are used in OR-SQL queries• SELECT DISTINCT, UNION are SQL operations• Merge-Join and Hash-Join for internal efficiencies

Always create a Compare() for any object that has an Equal(). The resulting order might be meaningless, but within the context of the query processor it can make

sense.

22


1.5 Minimize Set of Object Classes1.5 Minimize Set of Object Classes1.5 Minimize Set of Object Classes1.5 Minimize Set of Object Classes

• Use Detailed Specifications to Identify• synonyms and• antonyms

• Identify ‘like’ Object Classes

• Inheritance allows re-use • { Mail_Address, Delivery_Address }

• Describe Algorithms for all Behaviors• What does it mean to have ‘Equal’ UPC?• Space efficient internal representation

• Use Detailed Specifications to Identify• synonyms and• antonyms

• Identify ‘like’ Object Classes

• Inheritance allows re-use • { Mail_Address, Delivery_Address }

• Describe Algorithms for all Behaviors• What does it mean to have ‘Equal’ UPC?• Space efficient internal representation

23


Workload and Common QueriesWorkload and Common Queries

• Document Common Queries and Processes• Helps to flesh out Object Class specifications• Useful for identifying additional kinds of data• Useful for later functionality/scalability testing

• Document Common Queries and Processes• Helps to flesh out Object Class specifications• Useful for identifying additional kinds of data• Useful for later functionality/scalability testing

SELECT E.Name FROM Employees E WHERE Birthday(E.Date_of_Birth) = Birthday(TODAY);

Note: Types don’t have to be used to define tables. They can be used to extend SQL.

Birthday

INTEGER+ Month

+ Birthday( DATE ) -> Birthday ,+ Print( Birthday ) -> String,+ Equal( Birthday,Birthday)-> boolean. etc .

INTEGER+ Day

boolean- From_Leap_Year

24


By this Point you Out to Have:By this Point you Out to Have:

• An E-ER Model Representing High Level View

• List of entities, and their structure

• Understanding of relationships among entities

• List of rules-- keys, constraints etc

• Class Diagrams of each Distinct Kind of Data

• Described in terms of Structure, and Behavior

• Analysis of algorithms in methods

• An E-ER Model Representing High Level View

• List of entities, and their structure

• Understanding of relationships among entities

• List of rules-- keys, constraints etc

• Class Diagrams of each Distinct Kind of Data

• Described in terms of Structure, and Behavior

• Analysis of algorithms in methods

Next Step: Transform this conceptual model into a sound OR database design and implementation.

25


Phase 2: Database ImplementationPhase 2: Database ImplementationPhase 2: Database ImplementationPhase 2: Database Implementation

• UDTs and UDFs for each Domain• Use DataBlade extension libraries

• Develop business objects from scratch

• Build Relational Schema• Naïve translation of E-ER conceptual model

• Normalize the initial model

• Some special considerations

• Performance and Scalability Testing• Create volume data quickly

• Workload test harness

• UDTs and UDFs for each Domain• Use DataBlade extension libraries

• Develop business objects from scratch

• Build Relational Schema• Naïve translation of E-ER conceptual model

• Normalize the initial model

• Some special considerations

• Performance and Scalability Testing• Create volume data quickly

• Workload test harness

26


2.1 Implement Domains/Kinds of Data2.1 Implement Domains/Kinds of Data2.1 Implement Domains/Kinds of Data2.1 Implement Domains/Kinds of Data

• Several Mechanisms to Choose From• Do I buy a DataBlade™ product?

• Do I build objects from scratch?

• What about the client side?

• If Build, Which Technique?• Built-in type, ROW TYPE, DISTINCT TYPE,

OPAQUE TYPE

• Each mechanism has different properties

• How to Implement the UDFs?• SPL, Java or ‘C’?

• Several Mechanisms to Choose From• Do I buy a DataBlade™ product?

• Do I build objects from scratch?

• What about the client side?

• If Build, Which Technique?• Built-in type, ROW TYPE, DISTINCT TYPE,

OPAQUE TYPE

• Each mechanism has different properties

• How to Implement the UDFs?• SPL, Java or ‘C’?

27


Implementation OptionsImplementation OptionsImplementation OptionsImplementation Options

Mechanism Example Strengths and WeaknessesBuilt-InTypes

INTEGER, VARCHAR, DATE etc. Theseare standardized in the SQL-92 languagespecification.

Mature and high performance because theyare compiled into the ORDBMS. But theyare very simple. Good building-blocks forother types.

DISTINCT CREATE DISTINCT TYPEString AS VARCHAR(32);

Simple to create, and useful when what youwant is something very close to another type.

ROW TYPES CREATE ROW TYPE Address ( Address_Line_One String NOT NULL, Address_Line_Two String NOTNULL, City String NOT NULL, State String, ZipCode PostCode, Country String NOT NULL);

Relatively easy to use means of combiningpre-existing types into a more complexobjects, and enforcing rules about contents.ROW TYPEs have several drawbacks thatmakes them a poor choice for types to definecolumns.

Java Classes Combination of Java UDRs with opaquedata storage.

More complex to develop, but an excellentchoice when you want code that runs in boththe outside, and inside, the DBMS.

OPAQUETYPES

CREATE OPAQUE TYPE GeoPoint ( internallength = 16);

Most complex to develop, but these are themost powerful in terms of performance,scalability and the range of object sizes thatcan be supported.

28



• DISTINCT TYPES Re-Use Pre-Existing Types• Create EXPLICIT Cast between Parent and DISTINCT• Overload that CAST to Enforce Data Integrity

• DISTINCT TYPES Re-Use Pre-Existing Types• Create EXPLICIT Cast between Parent and DISTINCT• Overload that CAST to Enforce Data Integrity

CREATE DISTINCT TYPE QuantityAS INTEGER;--CREATE FUNCTION INTEGER2Quantity ( Arg1 INTEGER )RETURNS Quantity

IF ( Arg1 < 0 ) THENRAISE EXCEPTION –746,0,

“Error: Quantity must be non-negative”;END IF;RETURN Arg1::Quantity;

END FUNCTION;--DROP CAST ( INTEGER AS Quantity );CREATE IMPLICIT CAST ( INTEGER AS Quantity WITH INTEGER2Quantity );

29


UDF Implementation PerformanceUDF Implementation PerformanceUDF Implementation PerformanceUDF Implementation Performance

• Choice of Three Languages• Stored Procedure Language, Java and ‘C’• Experiment: Pop( INTEGER ) and IsPrime ( INTEGER )

• Choice of Three Languages• Stored Procedure Language, Java and ‘C’• Experiment: Pop( INTEGER ) and IsPrime ( INTEGER )

Performance of UDR Languages

0

200

400

600

800

1000

4 5 6 7 8 9 10

Log ( Size ( Values ) )

Se

co

nd

s t

o C

om

pu

te

10

,00

0

'C' Prime Performance

'C' Pop Performance

Java Prime Performance

Java Pop Performance

SPL Prime Performance

SPL Pop Performance

30



• Avoid SQL Callbacks Inside User-Defined Functions• UDFs with SQL are variant and can’t be parallelized• SQL inside a UDF kind of violates the philosophy

• Avoid SQL Callbacks Inside User-Defined Functions• UDFs with SQL are variant and can’t be parallelized• SQL inside a UDF kind of violates the philosophy

CREATE OPAQUE TYPE Mass ( internallength = 16, alignment = 8 );---- The code implementing this external function includes all -- of the conversion rates compiled into it. This permits it-- to perform conversion operations hyper-fast.--CREATE FUNCTION Compare (Mass ,Mass)RETURNS INTEGERWITH ( NOT VARIANT, PARALLELIZABLE )EXTERNAL NAME ”$INFORMIXDIR/extend/Massbin/Mass.bld(MassCompare)"LANGUAGE C;

31


2.2 Create the Schema Tables2.2 Create the Schema Tables2.2 Create the Schema Tables2.2 Create the Schema Tables

• Combine the Types into Schema TablesCombine the Types into Schema Tables• Simply CREATE TABLE if it is not in hierarchy• Create Hierarchy of ROW TYPE instances if it is• For simple has_a relationships, extend the dependent table

with additional column for the first table’s primary key column.

• For multi-variant has_a relationships, create a table with one column per key, and extra columns

Similar procedure to the one used transforming ER to RDBMS, except in the handling of Inheritance.

• Combine the Types into Schema TablesCombine the Types into Schema Tables• Simply CREATE TABLE if it is not in hierarchy• Create Hierarchy of ROW TYPE instances if it is• For simple has_a relationships, extend the dependent table

with additional column for the first table’s primary key column.

• For multi-variant has_a relationships, create a table with one column per key, and extra columns

Similar procedure to the one used transforming ER to RDBMS, except in the handling of Inheritance.

32


A Note on KeysA Note on KeysA Note on KeysA Note on Keys

• The Relational Key Concept is Important• Identifies correctness constraints within schema• Drives normalization, which helps ensure consistency

• Formerly, a Key is defined as:A column where no two values are equal.

• The Relational Key Concept is Important• Identifies correctness constraints within schema• Drives normalization, which helps ensure consistency

• Formerly, a Key is defined as:A column where no two values are equal.

ProductsId Name Dimensions Capacity Available_In PriceB-SH-3001 Shoe Box ’18 IN x 6 IN x 6 IN’ ’11 LB’ {white, black} $US 0.12B-P-312-A Small Pizza ’21 IN x 21 IN x 2 IN’ ‘3 LB’ {brown} $US 0.25B-P-312-L Large Pizza ’26 IN x 26 IN x 2 IN’ ‘4 LB’ {brown} $US 0.25B-PACK-411 Computer ’40 IN x 40 IN x 40 IN’ ’50 LB’ {brown,white} $US 5.00

33


Example Schema (1/3)Example Schema (1/3)Example Schema (1/3)Example Schema (1/3)

--

CREATE TABLE Products (

Id Product_Num NOT NULL PRIMARY KEY,

Name LabelString NOT NULL,

Dimensions Physical_Size NOT NULL,

Capacity Mass NOT NULL,

Available_In SET{Color NOT NULL},

Price Currency NOT NULL

);

--

CREATE TABLE Customers (

Id Customer_Num NOT NULL PRIMARY KEY,

Contact Person_Name NOT NULL,

Address Mail_Address NOT NULL,

Delivery Delivery_Address

);

--

CREATE TABLE Products (

Id Product_Num NOT NULL PRIMARY KEY,

Name LabelString NOT NULL,

Dimensions Physical_Size NOT NULL,

Capacity Mass NOT NULL,

Available_In SET{Color NOT NULL},

Price Currency NOT NULL

);

--

CREATE TABLE Customers (

Id Customer_Num NOT NULL PRIMARY KEY,

Contact Person_Name NOT NULL,

Address Mail_Address NOT NULL,

Delivery Delivery_Address

);

34



--

CREATE ROW TYPE Sales_Employee_Type (

Base_Salary Currency NOT NULL,

Sales_YTD Currency NOT NULL

) UNDER Full_Time_Employee_Type;

--

CREATE TABLE Sales_Reps

USING Sales_Employee_Type

UNDER Full_Timers;

--

CREATE TABLE Product_Sales_to_Customers (Customer Customer_Num NOT NULL REFERENCES Customers ( Id ),Product Product_Num NOT NULL REFERENCES Products ( Id ),Sales_Rep Employee_Num NOT NULL REFERENCES Sales_Reps ( Id ),Qty_Sold Quantity NOT NULL

);

--

CREATE ROW TYPE Sales_Employee_Type (

Base_Salary Currency NOT NULL,

Sales_YTD Currency NOT NULL

) UNDER Full_Time_Employee_Type;

--

CREATE TABLE Sales_Reps

USING Sales_Employee_Type

UNDER Full_Timers;

--

CREATE TABLE Product_Sales_to_Customers (Customer Customer_Num NOT NULL REFERENCES Customers ( Id ),Product Product_Num NOT NULL REFERENCES Products ( Id ),Sales_Rep Employee_Num NOT NULL REFERENCES Sales_Reps ( Id ),Qty_Sold Quantity NOT NULL

);

35



---- Query against the Product.Capacity column showing-- behavior of the Mass object class invoked.--SELECT P.Id,

P.Capacity

FROM Products P

WHERE P.Capacity > ’3 KG’

ORDER BY P.Capacity ASC;

---- Query against the Product.Capacity column showing-- behavior of the Mass object class invoked.--SELECT P.Id,

P.Capacity

FROM Products P

WHERE P.Capacity > ’3 KG’

ORDER BY P.Capacity ASC;

Id::Product_Num Capacity::MassB-SH-3001 ’11 LB’B-PACK-411 ’50 LB’

Mass

{ Ounce, LB, Gram, KG . .}- Unit

float- Quantity

+ Mass( String ) -> Mass ,+ Print( Mass ) -> String,+ Equal( Mass, Mass ) -> boolean, + LessThan( Mass, Mass ) -> boolean,+ LessThanOrEqual( Mass, Mass ) ->boolean,+ GreaterThan( Mass, Mass ) ->boolean,+ GreaterThanOrEqual( Mass, Mass ) -> boolean,+ NotEqual( Mass, Mass ) -> boolean,- Compare( Mass, Mass ) -> INTEGER,+ Plus( Mass, Mass ) ->Mass, + Minus( Mass, Mass ) ->Mass,+ Divide ( Mass, INTEGER ) ->Mass,+ Times ( Mass, INTEGER ) -> Mass

36


2.3 Normalization2.3 Normalization2.3 Normalization2.3 Normalization

• Normalization Concept & Procedure SameNormalization Concept & Procedure Same• Key, Whole Key, Nothing but the Key• Keys can be User-defined Types (of course)• New “corner cases”: spatial key (topography), temporal key

• What about COLLECTION Attributes?What about COLLECTION Attributes?• Good for domains of limited cardinalityGood for domains of limited cardinality

• { Work Days, Sizes_Available, Other_Phone_Nums }{ Work Days, Sizes_Available, Other_Phone_Nums }

• Bigger sets, bigger domains, less usefulBigger sets, bigger domains, less useful• No Indexing!No Indexing!

• Nested Tables are Right Out. Nested Tables are Right Out.

• Normalization Concept & Procedure SameNormalization Concept & Procedure Same• Key, Whole Key, Nothing but the Key• Keys can be User-defined Types (of course)• New “corner cases”: spatial key (topography), temporal key

• What about COLLECTION Attributes?What about COLLECTION Attributes?• Good for domains of limited cardinalityGood for domains of limited cardinality

• { Work Days, Sizes_Available, Other_Phone_Nums }{ Work Days, Sizes_Available, Other_Phone_Nums }

• Bigger sets, bigger domains, less usefulBigger sets, bigger domains, less useful• No Indexing!No Indexing!

• Nested Tables are Right Out. Nested Tables are Right Out.

COLLECTION works well for UDF varargs.COLLECTION works well for UDF varargs.

37


2.4 Load and Test (and test)2.4 Load and Test (and test)2.4 Load and Test (and test)2.4 Load and Test (and test)

• Can Use ORDBMS to Generate DataCan Use ORDBMS to Generate Data• Can Use ORDBMS to Generate DataCan Use ORDBMS to Generate DataINSERT INTO Products

( Name, Dimensions, Capacity, Available_In, Price )SELECT MakeString( Random(1000), 24 ), Random_Dimensions(), Random_Mass(), Random_Color_Set(), Random_Currency() FROM TABLE(SET{0,1,2,3,4,5,6,7,8,9}) N1 ( Num ), TABLE(SET{0,1,2,3,4,5,6,7,8,9}) N2 ( Num ), TABLE(SET{0,1,2,3,4,5,6,7,8,9}) N3 ( Num );

INSERT INTO Products

( Name, Dimensions, Capacity, Available_In, Price )SELECT MakeString( Random(1000), 24 ), Random_Dimensions(), Random_Mass(), Random_Color_Set(), Random_Currency() FROM TABLE(SET{0,1,2,3,4,5,6,7,8,9}) N1 ( Num ), TABLE(SET{0,1,2,3,4,5,6,7,8,9}) N2 ( Num ), TABLE(SET{0,1,2,3,4,5,6,7,8,9}) N3 ( Num );

• Physical TuningPhysical Tuning• IDS.2000 Little Different from 7.X• Remember to partition SBLOB data, as well as table data (text

indexing particularly!)

• Physical TuningPhysical Tuning• IDS.2000 Little Different from 7.X• Remember to partition SBLOB data, as well as table data (text

indexing particularly!)

38


Organizing Development TeamsOrganizing Development TeamsOrganizing Development TeamsOrganizing Development Teams

• Developers Writing Extensions Get own Instance

• Writing UDFs means debugging, which will halt the IDS instance.

• Testing with the DBMS

• Development Staging Process

• Individual Instances, to Test Environment

• only released to Production when happy.

• Looks like Mainframe development.

• Prototyping an Annealing

• SPL pass 1, Java or ‘C’ for what’s slow

• Developers Writing Extensions Get own Instance

• Writing UDFs means debugging, which will halt the IDS instance.

• Testing with the DBMS

• Development Staging Process

• Individual Instances, to Test Environment

• only released to Production when happy.

• Looks like Mainframe development.

• Prototyping an Annealing

• SPL pass 1, Java or ‘C’ for what’s slow

39


Architectural ViewArchitectural ViewArchitectural ViewArchitectural View

Application Process

Application Process

SQL

SQL

Java, C, etc

Java or SPL

JDBC (if Java)

Types in SchemaBuilt-in, DISTINCT,

or OPAQUE

JDBC, ODBC,ESQL/C, RMI,

Foo-ML, etc

JDBC, ODBC,ESQL/C, RMI

UDF‘C’, SPL, Java

UDF‘C’, SPL, Java

40


Err..What was that?Err..What was that?Err..What was that?Err..What was that?

The Following Principles Seem to Work:The Following Principles Seem to Work:

• No SQL Inside a UDT Method

• Objects are orthogonal to schema structure

• Do not put SQL inside ‘C’ User-defined Routines

• No performance advantage

• Makes development hard

• UI calls App Logic calls SQL Still Applies

• Impedance mis-match between SQL DBMS and languages like Java are minimized.

The Following Principles Seem to Work:The Following Principles Seem to Work:

• No SQL Inside a UDT Method

• Objects are orthogonal to schema structure

• Do not put SQL inside ‘C’ User-defined Routines

• No performance advantage

• Makes development hard

• UI calls App Logic calls SQL Still Applies

• Impedance mis-match between SQL DBMS and languages like Java are minimized.

41



• User-defined Functions Work in SPL• Any ‘C’ or Java (or SPL) UDF can be called as subroutine• Most useful with iterator functions

• User-defined Functions Work in SPL• Any ‘C’ or Java (or SPL) UDF can be called as subroutine• Most useful with iterator functions

CREATE FUNCTION GetFirstName ( Arg1 LVARCHAR )RETURNING lvarchar; DEFINE lIntVals LIST(lvarchar NOT NULL); DEFINE lvRetVal lvarchar; LET lIntVals = Split(Arg1, ' ' ); FOREACH cursor1 FOR SELECT * INTO lvRetVal FROM TABLE(lIntVals) EXIT FOREACH; END FOREACH; RETURN lvRetVal;END FUNCTION;--EXECUTE FUNCTION GetFirstName (“John Fitzgerald Kennedy”)John

42


On the Client SideOn the Client SideOn the Client SideOn the Client Side

• 4GL is Perfectly Reasonable for ORDBMS

• OR-SQL queries can take & return strings & numbers, and can invoke stored procedures.

• ‘C’, C++

• ESQL/C, ODBC, CLI are workable

• DataBlade™ products ship with client libraries and header files

• Java

• JDBC 2.0 is majestic mojo

• Type <-> Class mapping can make the interaction seamless

• 4GL is Perfectly Reasonable for ORDBMS

• OR-SQL queries can take & return strings & numbers, and can invoke stored procedures.

• ‘C’, C++

• ESQL/C, ODBC, CLI are workable

• DataBlade™ products ship with client libraries and header files

• Java

• JDBC 2.0 is majestic mojo

• Type <-> Class mapping can make the interaction seamless

43


‘‘Organic’ ApplicationsOrganic’ Applications‘‘Organic’ ApplicationsOrganic’ Applications

Another way to look at Database Another way to look at Database DevelopmentDevelopment

• What is an ORDBMS?What is an ORDBMS?• An ORDBMS is a Software Back-Plane . . . An ORDBMS is a Software Back-Plane . . .

• supporting a declarative/query-centric interface. supporting a declarative/query-centric interface.

• How do you use it?How do you use it?• Combine objects to solve problems.Combine objects to solve problems.

• No more system-wide upgrades.No more system-wide upgrades.

• Component-centric development.Component-centric development.

Another way to look at Database Another way to look at Database DevelopmentDevelopment

• What is an ORDBMS?What is an ORDBMS?• An ORDBMS is a Software Back-Plane . . . An ORDBMS is a Software Back-Plane . . .

• supporting a declarative/query-centric interface. supporting a declarative/query-centric interface.

• How do you use it?How do you use it?• Combine objects to solve problems.Combine objects to solve problems.

• No more system-wide upgrades.No more system-wide upgrades.

• Component-centric development.Component-centric development.

44


Summary and ConclusionsSummary and ConclusionsSummary and ConclusionsSummary and Conclusions

• ORDBMS Development IsORDBMS Development Is• Best approached in a ‘holistic’ fashion.• Consider the design of at high-level (relational)• and low-level (objects and components)

• More Implementation TipsMore Implementation Tips

http://www.informix.com/idnhttp://www.iiug.org/softwarehttp://examples.informix.com/

• ORDBMS Development IsORDBMS Development Is• Best approached in a ‘holistic’ fashion.• Consider the design of at high-level (relational)• and low-level (objects and components)

• More Implementation TipsMore Implementation Tips

http://www.informix.com/idnhttp://www.iiug.org/softwarehttp://examples.informix.com/

45


References and Further ReadingReferences and Further ReadingReferences and Further ReadingReferences and Further Reading

INFORMIX Tech Notes: Q1, Q2 of 2000 contains two long papers describing this in more detail.

Roy, Jacques Server-Side Programming in C: INFORMIX Dynamic Server 2000 INFORMIX Press. 1999

And lastly!

Brown, Paul G. Developing Object-Relational Database Applications INFORMIX Press. Dec, 2000.

Developing Object-Relational Database Applications

Documents

Transcript of Developing Object-Relational Database Applications