Developing Object-Relational Database Applications

download Developing Object-Relational Database Applications

of 45

  • date post

  • Category


  • view

  • download


Embed Size (px)


Developing Object-Relational Database Applications. Paul Brown Chief Plumber INFORMIX Software. What We Will Talk About. Plenty of Focus on Features & Functionality Question is, “How to use it all?” - PowerPoint PPT Presentation

Transcript of Developing Object-Relational Database Applications

  • Developing Object-Relational Database Applications Paul Brown Chief Plumber INFORMIX Software

  • What We Will Talk AboutPlenty of Focus on Features & FunctionalityQuestion 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.

  • Overview of TutorialDesign Objectives of DatabasesHow are OR Database Similar/Different?What about the theory?Methodology DescriptionSteps of a development procedureAnalysis and designImplementation adviceExamples as we go throughArchitecture AdviceBack-end and middle-wareComponent-centric development

  • Design ObjectivesMeet the Needs of End UsersCompleteThe Database needs to model everything that is relevant to the problem domain (PD).CorrectThe Database needs to be an accurate model of the PD.ConsistentThe database model should not contain redundant data.FlexibleThe database should adapt to changing requirements.EfficientFast, scaleable and simple to administer.

  • Object-Relational Data ModelBased on Relational Model of Codd [1971]Relation as storage abstraction and organizing principleDeclarative programming as interface modelAn Object-Relational DBMS ProvidesPhysical 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.

  • 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 ) aRelation 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 )

  • Theoretic Overview ( 2/ 2 )Operations to Manipulate RelationsProjection (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 . .)

  • Enough Greek!What does it look like in practice?Declarative language programmingDynamic, 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.

  • Development Road-map1. Analyze the Problem DomainDocument the high level structure (E-ER)Describe each kind of data (UML Class Diagrams)2. Design and ImplementationUse User-Defined Types (UDT) and User-Defined Functions (UDF) for ObjectsCombine Objects into Schema Tables/ViewsQueries to map to user views3. Verify Each StepPrototype UDT/UDFsNormalizeTest performance against production scale loads

  • Outline of Procedure: 3 Tier Model1. Conceptual2. 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 . );..

  • Phase 1: Conceptual ModelingDescribe User Views of Problem DomainPictures instead of wordsMultiple Semantic Model PossibilitiesExtended Entity-Relationship (E-ER) ModelingObject-Role Modeling (ORM or NIAM)Universal Modeling Language (UML)Use E-ER in this TutorialFamiliar to most developers and analystsConcepts introduced here apply everywhere

  • E-ER Diagrams for DummiesEntity: Principle data objects in the problem domain. Typically identified with a noun term; Branch, Employee, etchas_a Relationship: Association between Entities. Typically identified with a verb term; Manufacturers, WorksFor, etc. has_a relationships can have additional attributes.BranchBranchProductEmployeesBranchFull_TimeProductionSalesis_a Relationship: Inheritance relationship between Entities.

  • 1.1 Describe High-Level E-EREmployeesContractorsFull_TimeProductionSalesCustomer




    worked forsoldmanufactures

  • 1.2 Describe Each EntityFor each entity, name its attributes, and decide what kind of data is in each of them.

  • E-ER Modeling ReviewThis is Really Nothing NewBetter modeling of is_a relationships (inheritance)What Other Tasks?Note Logical Keys in EntitiesRecord arity of has_a relationships (1:N, N:M, etc)Record mandatory and optional relationshipsWhat is New?Resist the temptation to analyze down to SQL-92 types. Within E-ER modeling, maintain a degree of abstraction.

  • Handling Multiple Conceptual ViewsMultiple Semantic Model PossibilitiesExtended Entity-Relationship ModelingObject-Role ModelingUniversal Modeling LanguageWhat 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.

  • The Object ConceptThe most brutalized term in computer scienceWhat is an Object?Atomic unit of meaning encapsulating both state and behavior.Objects mostly map to domains in Relational TheoryWhy is the Concept Useful?Intuitive way of describing things in the data modelThese intuitions can drive user-defined type and user-defined function design.

  • 1.3 Catalog the Kinds of DataCreate 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.





















  • 1.4 Use UML Class Diagrams

  • Class 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- LatitudeFLOATEllispoid_EnumFLOAT- EllipsoidState Elements(Data Structure)Kind of Data in ElementInterface MethodsWhy These?

  • Implementation Tip # 1Object Classes are used in OR-SQL queriesSELECT DISTINCT, UNION are SQL operationsMerge-Join and Hash-Join for internal efficienciesAlways 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.

  • 1.5 Minimize Set of Object ClassesUse Detailed Specifications to Identifysynonyms andantonymsIdentify like Object Classes Inheritance allows re-use { Mail_Address, Delivery_Address }Describe Algorithms for all BehaviorsWhat does it mean to have Equal UPC?Space efficient internal representation

  • Workload and Common QueriesDocument Common Queries and ProcessesHelps to flesh out Object Class specificationsUseful for identifying additional kinds of dataUseful for later functionality/scalability testing SELECT E.Name FROM Employees E WHERE Birthday(E.Date_of_Birth) = Birthday(TODAY);Note: Types dont have to be used to define tables. They can be used to extend SQL.

  • By this Point you Out to Have:An E-ER Model Representing High Level ViewList of entities, and their structureUnderstanding of relationships among entitiesList of rules-- keys, constraints etcClass Diagrams of each Distinct Kind of DataDescribed in terms of Structure, and BehaviorAnalysis of algorithms in methodsNext Step: Transform this conceptual model into a sound OR database design and implementation.

  • Phase 2: Database ImplementationUDTs and UDFs for each DomainUse DataBlade extension librariesDevelop business objects from scratchBuild Relational SchemaNave translation of E-ER conceptual modelNormalize the initial modelSome special considerationsPerformance and Scalability TestingCreate volume data quicklyWorkload test harness

  • 2.1 Implement Domains/Kinds of DataSeveral Mechanisms to Choose FromDo 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 TYPEEach mechanism has different propertiesHow to Implement the UDFs?SPL, Java or C?

  • Implementation Options



    Strengths and Weaknesses

    Built-In Types

    INTEGER, VARCHAR, DATE etc. These are standardized in the SQL-92 language specification.

    Mature and high performance because they are compiled into the ORDBMS. But they are very simple. Good building-blocks for other types.