United States Patent [19J
`Chang et al.
`
`[54] SYSTEM AND METHOD FOR PROVIDING A
`HIGH LEVEL LANGUAGE FOR MAPPING
`AND ACCESSING OBJECTS IN DATA
`STORES
`
`[75]
`
`Inventors: Daniel T. Chang, San Jose, Calif.;
`Christina Lau, Don Mills, Canada;
`Taejae Lee, Cupertino, Calif.
`
`[73] Assignee: International Business Machines
`Corporation, Armonk, N.Y.
`
`[ *] Notice:
`
`This patent issued on a continued pros(cid:173)
`ecution application filed under 37 CFR
`1.53( d), and is subject to the twenty year
`patent term provisions of 35 U.S.C.
`154(a)(2).
`
`[21] Appl. No.: 08/866,374
`
`[22] Filed:
`
`May 30, 1997
`
`Related U.S. Application Data
`
`[63] Continuation of application No. 08/276,747, Jul. 18, 1994,
`abandoned.
`Int. Cl? ........................................................ G06F 9/44
`[51]
`[52] U.S. Cl. .......................... 395/702; 395/701; 707/100;
`707/103
`[58] Field of Search ..................................... 395!702, 600,
`395/701; 707/100, 103
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,315,709
`5,426,780
`5,448,727
`5,627,979
`
`5/1994 Alston, Jr. et a!. ... ... .... ... ... ... ... ... 707/6
`6/1995 Gerull et a!. ................................ 707/3
`9/1995 Annevelink ............................. 395/600
`5/1997 Chang et a!.
`.. ... ... ... ... .... ... ... ... 395/335
`
`01HER PUBLICATIONS
`
`The Common Object Requester Broker Architecture and
`Specification, OMG TC Document 91.12.1, 1991.
`IBM/Joss Object Services Persistence Service Specification,
`OMG TC Document 93.11.3 (OMG TC Document 93.5.7),
`Nov. 15, 1993.
`
`111111
`
`1111111111111111111111111111111111111111111111111111111111111
`US006061515A
`[11] Patent Number:
`[45] Date of Patent:
`
`6,061,515
`*May 9, 2000
`
`SOM Toolkit Users Guide, Version 2.0, Jun. 1993. (SOMob(cid:173)
`jects Developer Toolkit Users Guide, Version 2.0, Jun. 1993.
`ODMG-93, Standard R.G.G. Cattell (Ed), The Object Data(cid:173)
`base Standard: A ODMG-93, Morgan Kaufmann Publish(cid:173)
`ers, San Mateo, CA 1994.
`IBM SQL Reference Version 1, First Edition, Aug. 1993.
`Rumbaugh et al., "Object-Oriented Modeling and Design"
`pp. 1-3, 375-386, 1991.
`Aho et al. "Compilers Principles Techniques and Tools", p.
`56, 1988.
`Su-Yin et al., "Capturing the Object-Oriented Database
`model in Relational Form", 1993.
`
`(List continued on next page.)
`
`Primary Examiner-Tariq R. Hafiz
`Assistant Examiner-Todd Ingberg
`Attorney, Agent, or Firm-Prentiss W. Johnson
`
`[57]
`
`ABSTRACT
`
`A user may define a mapping between object schema and
`data store schema by use of a high level language, Schema
`Mapping Definition Language (SMDL), which is data store
`independent, object oriented language independent, and
`extensible. The user may either write SMDL directly or
`generate SMDL through the use of a graphical user interface
`Smart Schema whose graphical semantics support the
`SMDL semantics. A Schema Mapping Internal Representa(cid:173)
`tion (SMIR) containing representations of the object
`schema, the data store schema, and the mapping of the object
`schema and the data store schema is generated by an SMDL
`Parser from the SMDL. The SMIR is represented such that
`it may be accessible by both development interfaces and
`run-time environments. It supports the accessing of the
`mapping information given either the object schema or data
`store schema such that the data store schema may be
`accessed from the object schema, and the object schema may
`be accessed from the data store schema. An SMDL Genera(cid:173)
`tor may be used to generate the SMDL from the SMIR. The
`SMIR, SMDL Generator, SMDL Parser, and SMDL may be
`registered in a Data Store Manager (DSM) having a single,
`uniform, object oriented application programming interface
`for accessing one or more data stores, regardless of the type
`of data store.
`
`15 Claims, 17 Drawing Sheets
`
`0
`
`Smar\Schema
`
`0
`
`Relational
`
`Ob jec\
`
`Mapper
`
`700
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 1
`
`

`
`6,061,515
`Page 2
`
`01HER PUBLICATIONS
`
`Ying Ying et al, "Translating Relational Schema with Con(cid:173)
`straints in OODB Schema", 1993.
`Yan et al, "Translating Relation! Schema With Constraints
`Into OODB Schema", IFIP Transactions A: Computer Sci(cid:173)
`ence and Technology, pp. 69-85, Nov. 1992.
`Hsieh et al, "Capturing the Object-Oriented Database
`Model in Relational Form", Proceedings-IEEE Computer
`Society's International Computer Sofware and Applications
`Conference, p. 202-208, Nov. 1993.
`Rafii, A et al, "Integration Strategies in Pegasus Object
`Oriented Multidatabase System", Proceedings of the Twen(cid:173)
`ty-Fifth Hawaii International Conference on System Sci(cid:173)
`ences, p. 323-34, Jan. 7, 1992.
`Bertino, E., "Integration of Heterogeneous Data Reposito(cid:173)
`ries by Using Object-Oriented Views", IMS '91 Proceed(cid:173)
`ings. First International Workshop on Interoperability m
`Multidatabase Systems, p. 22-9, Apr. 7, 1991.
`
`Markowitz, V. et al, "Object Queries Over Relational Data(cid:173)
`bases: Language, Implementation, and Applications", Pro(cid:173)
`ceedings. Ninth International Conference on Data Engineer(cid:173)
`ing, p. 71-80, Apr. 19, 1993.
`Soutou, C., "Towards a Methodology for Developing a
`Federated Database System", Proceedings ICC '93. Fifth
`International Conference on Computing and Information, p.
`560-4, May 27, 1993.
`Sull, W. et al, "A Self-Organizing Knowledge Representa(cid:173)
`tion Scheme for Extensible Heterogeneous Information
`Environment", IEEE Transactions on Knowledge and Data
`Engineering, p. 185-91, Apr. 1992.
`Urban, S., "A Semantic Framework for Heterogeneous
`Database Environments", IMS '91 Proceedings. First Inter(cid:173)
`national Workshop on Interoperability in Multidatabase Sys(cid:173)
`tems, p. 156-63, Apr. 7, 1991.
`Rafii, A. et al, "Multidatabase Management in Pegasus",
`IMS '91 Proceedings. First International Workshop on
`Interoperability in Multidatabase Systems, p. 166-73, Apr.
`7, 1991.
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 2
`
`

`
`OBJECT
`SCHEMA ACCESS
`
`DATASTORE
`SCHEMA ACCESS
`
`120
`
`140
`
`SMDL PARSER
`
`230
`
`240
`
`220
`
`210
`
`,------
`
`1
`
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`
`150
`
`r - - - - - - - - - - -
`1 I ~-------
`1 I
`I I
`I I
`I I
`I I
`I I
`I I
`I I
`I I
`/ /(
`I I
`I I
`I I I
`I
`I I
`I
`I I
`I
`I I
`I
`I I
`I
`I I
`I
`I I
`I I I
`I
`I
`I L_
`L
`
`SMDL
`
`-, ,------
`
`110
`
`1 I
`I I
`I I
`: :
`I
`I
`I
`I
`
`310
`
`330
`
`320
`(
`- -L - - - - , OCLI
`
`------,
`I
`-...
`',
`)
`' , I
`'!,
`I
`'
`
`I
`
`'..._
`
`I
`
`I
`
`I
`
`Server DSM
`' ' ' ' ---~,---
`' ' ' '
`
`' ' ' ' ...,
`410 /
`I
`I
`
`-,
`
`I
`
`d •
`\Jl
`•
`~
`~ ......
`~ = ......
`
`~
`~
`'-<
`~~
`N c
`8
`
`'JJ. =(cid:173)~
`~ .....
`'"""' 0 ......,
`'"""'
`-..J
`
`Client
`................
`Server
`320
`I
`OCLI
`
`340
`
`I
`
`C++ & SQL
`
`I
`
`I
`
`I
`
`I
`
`I
`
`I
`
`I
`
`I
`
`420
`
`I
`
`I
`- - - '
`
`~100
`FIG. 1
`
`0\
`
`.... = 0\
`
`~ ....
`Ul
`~
`Ul
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 3
`
`

`
`U.S. Patent
`
`May 9, 2000
`
`Sheet 2 of 17
`
`6,061,515
`
`110
`
`SMART SCHEMA
`
`~200
`
`130
`
`150
`
`OBJ
`SCHE
`REPO
`
`OS
`SCHE
`REPO
`
`230
`
`OBJECT
`SCHEMA ACCESS
`
`DATASTORE
`SCHEMA ACCESS
`
`120
`
`140
`
`240
`
`SMDL PARSER
`
`210
`
`SMDL GENERATOR
`
`220
`
`FIG. 2
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 4
`
`

`
`Smart Access
`
`310
`
`.----____L_------, OCLI
`Client DSM
`
`330
`
`Client
`................. 'I' .................... .
`Server
`
`340
`r - ' - - - - - - ' - - - - . OCLI
`Server DSM
`
`d •
`\Jl
`•
`~
`~ ......
`~ = ......
`
`~
`~
`'-<
`~~
`N c
`8
`
`'JJ. =(cid:173)~
`~ ......
`~
`0 ......,
`'"""'
`-..J
`
`,300
`
`FIG. 3
`
`0\
`
`.... = 0\
`
`~ ....
`Ul
`~
`Ul
`
`230
`
`240
`
`SMDL PARSER
`
`220
`
`SMDL GENERATOR
`
`210
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 5
`
`

`
`U.S. Patent
`
`May 9, 2000
`
`Sheet 4 of 17
`
`6,061,515
`
`500
`
`I
`
`Client DSM
`
`330
`
`Client
`Server
`
`550
`
`\
`
`Staging
`
`350
`
`360
`
`370
`
`380
`(
`
`DSM_CSDM
`
`DSM_SQL
`
`DSM_CLI
`
`DSM_IMS
`
`DB2
`
`IMS/DB
`
`450
`
`460
`
`IMS/DB
`
`490
`
`Middlewore
`
`RDB
`
`4so
`
`FIG. 4
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 6
`
`

`
`U.S. Patent
`
`May 9, 2000
`
`Sheet 5 of 17
`
`6,061,515
`
`0
`-.;::1-
`C'.J
`
`0:::::
`LLJ
`(f)
`0:::::
`<(
`D....
`
`___J
`0
`::::::!:
`(f)
`
`0:::::
`0
`1--
`<(
`0:::::
`LLJ
`:z:
`LLJ
`C)
`
`_.J
`0
`:::2:
`(f)
`
`0
`N
`N
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 7
`
`

`
`l-------1
`
`OBJ
`SCHE
`130 ---i REPO
`-----'
`
`150-----1
`
`120
`
`OBJECT r) SMART SCHEMA
`
`~
`
`SCHEMA ACCESS
`
`~110
`
`DATASTORE
`SCHEMA ACCESS
`
`140
`
`240
`
`SMDL PARSER~
`
`I
`I
`
`230---{
`
`~MUL
`
`)
`
`SMIR
`
`220
`
`SMDL GENERA TOR
`
`FIG. 6
`
`IDL
`Ctt & SOL
`
`"'
`
`410
`
`l
`
`420
`
`C++ & SOL
`
`---
`
`d •
`\Jl
`•
`~
`~ ......
`~ = ......
`
`~
`~
`'-<
`~~
`
`N c c c
`
`'JJ. =-~
`~ .....
`0'1
`0 ......,
`'"""'
`-..J
`
`0\
`
`.... = 0\
`
`~ ....
`Ul
`~
`Ul
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 8
`
`

`
`U.S. Patent
`
`May 9, 2000
`
`Sheet 7 of 17
`
`6,061,515
`
`0
`
`SmartSchema
`
`0
`
`r-710
`
`Relational
`
`Object
`
`f-. 720 ~ c--]30
`
`Mapper
`
`FIG. 7
`
`700
`
`0
`
`Object Schema
`
`0
`
`820
`
`830
`
`840
`
`850
`
`810
`
`860
`
`870
`
`880
`
`FIG. 8
`
`800
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 9
`
`

`
`U.S. Patent
`
`May 9, 2000
`
`Sheet 8 of 17
`
`6,061,515
`
`Relational Schema
`
`I
`
`Config
`
`I
`
`I Help
`(
`950
`
`(
`940
`
`D
`
`l
`910
`
`D
`
`File
`l
`920
`
`I
`
`Schema
`
`l
`930
`
`m960
`
`Employee
`
`[f+J
`
`Person
`
`FIG. 9
`
`D
`
`I
`
`File
`l
`1020
`
`Schema I
`l
`1030
`
`Map
`
`Schema Mapper
`I
`
`I Help
`I
`1050
`
`I
`1040
`
`900
`
`D
`
`(
`1010
`
`FIG. 10
`
`1000
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 10
`
`

`
`U.S. Patent
`
`May 9, 2000
`
`Sheet 9 of 17
`
`6,061,515
`
`1020 -~--
`
`D
`
`1030~
`
`File
`
`Schema
`
`I
`Select classes
`1120- 1-- Select tables
`
`(
`1110
`
`D
`
`File 1
`7
`1020
`
`I
`
`Schema
`
`I
`1030
`
`E[B-1060
`
`Employee
`
`Map
`
`Schema Mapper
`I
`
`I Help
`7
`1050
`
`Employee ------f-1140
`Address
`RegularEmp
`SalaryEmp
`
`r--1130
`
`FIG. 11
`
`Schema Mapper
`
`Map 1 Help I
`7
`(
`1040
`1050
`
`D
`
`I
`1010
`
`I
`1000
`
`D
`
`I
`1010
`
`FIG. 12
`
`1000
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 11
`
`

`
`U.S. Patent
`
`May 9, 2000
`
`Sheet 10 of 17
`
`6,061,515
`
`1020
`
`~ -
`
`D
`
`1030~
`
`File
`
`Schema
`
`I
`1310 ~ 1- Select classes
`Select tables
`
`I
`1110
`
`D
`
`Map
`
`Schema Mapper
`I Help
`I
`I
`1050
`
`Person ---f--1330
`Manager
`
`I
`1320
`
`FIG. 13
`
`Map
`
`Schema Mapper
`I Help
`I
`I
`1050
`
`I
`1040
`
`D
`
`I
`1010
`
`I
`1000
`
`D
`
`I
`1010
`
`Person
`
`~1070
`
`FIG. 14
`
`1000
`
`File
`I
`1020
`
`I Schema
`
`I
`I
`1030
`
`ml060
`
`Employee
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 12
`
`

`
`U.S. Patent
`
`May 9, 2000
`
`Sheet 11 of 17
`
`6,061,515
`
`1020 ~ -
`
`File
`
`D
`
`1030~
`
`Map
`[ Schema
`1520-..--Link
`Generate SMDL
`
`1040 ~ Schema Mapper
`[ Help I
`\..._ 1050
`r-1510
`
`E[±j-1060
`
`Employee
`
`Person
`
`I
`
`~1070
`
`D
`
`(
`1010
`
`I
`1000
`
`D
`
`(
`1010
`
`FIG. 15
`
`Map
`
`Schema Mapper
`I Help I
`I
`1050
`
`I
`1040
`
`D
`
`I Schema
`
`File
`l
`1020
`
`I
`
`l
`1030
`~1060
`
`I I I
`Employee
`
`(
`1080
`
`--I
`
`Person
`
`~1070
`
`FIG. 16
`
`1000
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 13
`
`

`
`U.S. Patent
`
`May 9, 2000
`
`Sheet 12 of 17
`
`6,061,515
`
`0
`
`Define Mapping Info
`
`0
`
`Table: Employee
`
`1705~ empNum (k)
`1710 ~ firstName
`1715 ~ lastName
`1720~ hireD ate
`
`1725
`
`1740
`
`I OK
`
`I
`
`I
`
`Cancel
`
`Class: Person
`
`serialNumber
`
`) 735 ~1730
`fJ ~
`
`serialNumber
`
`r-----1745
`
`name
`
`day
`
`month
`
`year
`
`t--1750
`
`r-----1755
`
`r-1760
`
`--1765
`
`FIG. 17
`
`0
`
`Define Mapping Info
`
`1700
`
`0
`
`Table: Employee
`
`Class: Person
`
`serialNumber
`
`\1 I
`
`serialNumber
`name
`
`name
`
`1--
`r-
`r-
`
`1805
`1810
`1815
`
`1705
`
`1710
`
`1715
`1720
`
`~
`
`empNum (k)
`
`~
`
`firstName
`
`~
`
`lastName
`
`~
`
`hireD ate
`
`OK
`
`j
`
`I Cancel
`
`day, month, year
`\
`1
`1830
`1820
`
`\
`
`~ l
`
`1875
`
`1825
`
`FIG. 18
`
`1800
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 14
`
`

`
`U.S. Patent
`
`May 9, 2000
`
`Sheet 13 of 17
`
`6,061,515
`
`Schema Mapper
`
`D
`
`D
`
`File
`
`1910
`
`Schema
`
`Map
`
`1940
`
`Sal ary[mp
`
`1920
`
`Employee
`
`RegularEmp
`
`1930
`
`D
`
`D
`
`File
`
`I Schema
`
`2010~
`
`Employee
`
`FIG. 19
`
`Schema Mapper
`I Help
`I
`
`Map
`
`2040
`l
`
`Address
`
`Person
`
`2030
`
`2050
`
`FIG. 20
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 15
`
`

`
`U.S. Patent
`
`May 9, 2000
`
`Sheet 14 of 17
`
`6,061,515
`
`0
`
`Schema Mapper
`
`0
`
`File
`
`I Schema
`
`I
`
`Map
`
`I Help
`
`I
`
`2110
`l
`I Person
`
`l
`I
`
`2130
`l
`
`(" 2120
`
`Employee
`
`FIG. 21
`
`0
`
`Define Mapping Info
`
`0
`
`Class: Person
`
`~
`
`seriaiNumber
`
`2205
`2210
`
`~
`
`name
`
`~
`
`day
`
`2215
`2220
`
`~
`
`month
`
`2225
`
`~
`
`year
`
`Table: Employee
`2230~ empNum (k)
`empNum (k)
`
`2235
`
`~
`il
`~
`2245
`
`1---
`
`2240
`
`first Name
`
`lastName
`
`hireDate
`
`1---
`
`2250
`
`1---
`
`2255
`
`I--
`
`2260
`
`OK
`
`Cancel
`
`FIG. 22
`
`2200
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 16
`
`

`
`U.S. Patent
`
`May 9, 2000
`
`Sheet 15 of 17
`
`6,061,515
`
`0
`
`Define Mapping Info
`
`0
`
`Class: Person
`
`~
`
`seriaiNumber
`
`2305
`2310
`2315
`
`~
`
`name
`
`~
`
`day
`
`~
`
`month
`
`~
`
`year
`
`2320
`2325
`
`Table: Employee ~
`I empNum (k)
`V ~
`2345
`r-
`2355
`empNum
`235
`0
`)
`\... r-- firstName, lastName
`hireDate
`
`I userFd1
`r- 2360
`
`l2375
`
`hireDate
`
`hireDate
`
`r- 2365
`
`r- 2370
`
`OK
`
`Cancel
`
`FIG. 23
`
`0
`
`Schema Mapper
`
`0
`
`File
`
`Schema
`
`Map
`
`2440
`
`2410
`
`2450
`
`2420
`
`RegularEmp
`
`2430
`
`SalaryEmp
`
`FIG. 24
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 17
`
`

`
`U.S. Patent
`
`May 9, 2000
`
`Sheet 16 of 17
`
`6,061,515
`
`D
`
`Schema Mapper
`
`D
`
`File
`
`Schema
`
`Map
`
`2520
`
`Employee
`
`2530
`
`FIG. 25
`
`Schema Mapper
`I Help
`I
`
`D
`
`·j I I l2640
`
`Employee
`
`D
`
`File
`
`I Schema
`
`I
`
`Map
`
`2610
`"-.
`Person
`
`I
`
`I
`
`2650
`I
`
`I
`2620~
`
`Add Class
`Add Table- r- 2630
`
`FIG. 26
`
`2600
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 18
`
`

`
`U.S. Patent
`
`May 9, 2000
`
`Sheet 17 of 17
`
`6,061,515
`
`D
`
`File
`
`I Schema 1 Map
`
`Schema Mapper
`I Help I
`
`D
`
`2720~ Add Class-~ 2730
`Add Table
`
`2710~ I I I
`
`Employee
`
`~I
`
`2750
`
`2740
`;
`
`Person
`
`FIG. 27
`
`2700
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 19
`
`

`
`6,061,515
`
`1
`SYSTEM AND METHOD FOR PROVIDING A
`HIGH LEVEL LANGUAGE FOR MAPPING
`AND ACCESSING OBJECTS IN DATA
`STORES
`
`This application is a continuation of application Ser. No.
`08/276,747 filed Jul. 18, 1994, now abandoned.
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`Application Ser. No. 08/276,382, filed concurrently here(cid:173)
`with on Jul. 18, 1994 for A SYSTEM AND METHOD FOR
`MAPPING AND ACCESSING OBJECTS IN DATA
`STORES (IBM Docket ST9-94-016), currently co-pending,
`and assigned to the same assignee as the present invention. 15
`Application Ser. No. 08/276,389, filed concurrently here(cid:173)
`with on Jul. 18, 1994 for A SYSTEM AND METHOD FOR
`PROVIDING A GRAPHICAL USER INTERFACE FOR
`MAPPING AND ACCESSING OBJECTS IN DATA
`STORES (IBM Docket ST9-94-017), currently co-pending,
`and assigned to the same assignee as the present invention.
`The foregoing copending applications are incorporated
`herein by reference.
`A portion of the Disclosure of this patent document
`contains material which is subject to copyright protection.
`The copyright owner has no objection to the facsimile
`reproduction by anyone of the patent document or the patent
`disclosure, as it appears in the Patent and Trademark Office
`patent file or records, but otherwise reserves all copyright 30
`rights whatsoever.
`1. Field the Invention
`This invention relates to object oriented systems and data
`store systems, and more particularly to mapping between
`object schema and data store schema.
`2. Description of the Related Art
`The data processing industry and its customers have made
`considerable investments in conventional data store
`technology, including relational databases, hierarchial
`databases, fiat file databases, and network databases.
`Presently, the relational or entity-relationship model under(cid:173)
`lying relational databases is the predominant conventional
`method of storing data in databases.
`Object oriented technology has also gained wide accep(cid:173)
`tance due to its strengths in real world modeling, modularity,
`reuse, distributed computing, client/server computing, and
`graphical user interfaces.
`However, the object model underlying object oriented
`technology and the data model underlying conventional data
`stores are different, and a way is needed to provide the
`advantages of object oriented technology while preserving
`the substantial investment in conventional data store tech(cid:173)
`nology.
`An object model captures the structure of a system by
`representing the objects in the system, the relationships
`between those objects, and the attributes and operations that
`characterize each class of objects. The purpose of object
`modeling is to describe objects, and an object is simply
`something that has a meaningful behavior in an application
`context. An object has data, the value of which represent the
`object's state. The behavior that an object exhibits is pro(cid:173)
`vided by operations on that data, and this behavior may be
`invoked by other objects sending messages. These opera(cid:173)
`tions are implemented as procedures called methods. All 65
`objects have identity and are distinguishable. The term
`identity means that an object is distinguishable by its inher-
`
`20
`
`2
`ent existence and not by descriptive properties that it may
`have. A unique object may be referred to as an object
`instance or an instance.
`An object class describes a group of objects with similar
`5 properties (attributes), common behavior (operations), com(cid:173)
`mon relationships to other objects, and common semantics.
`Objects in a class have the same attributes and behavior
`patterns. The objects derive their individuality from differ(cid:173)
`ences in the attribute values and relationship to other objects.
`10 The class defines the object's data structure and methods to
`access that data structure. Methods and data structure are
`shared among objects of the same class. An object knows its
`class and the methods it possesses as a member of the class.
`Common definitions such as class name and attribute names
`are stored once per class, rather than once per object
`instance. Operations may be written once for a class so that
`all objects in the class benefit from code reuse.
`An attribute is a data value, not an object, held by the
`objects in a class. Each attribute has a value for each object
`instance. Different object instances may have the same or
`different values for a given attribute. Each attribute name is
`unique within a class, as opposed to being unique across all
`classes.
`A link is a relationship between object instances, a tuple
`25 or ordered list of object instances. A link is also an instance
`of an association. An association is a group of links with
`common structure and common semantics. All the links in
`an association connect objects from the same classes. An
`association describes a set of potential links in the sane way
`that a class describes a set of potential objects. Associations
`are inherently bidirectional and can be traversed in either
`direction. Associations are often implemented in various
`object oriented programming languages as pointers from one
`object to another. A pointer is an attribute in one object that
`35 contains an explicit reference to another object.
`As an attribute is a property of objects in a class, a link
`attribute is a property of the links in an association. Each link
`attribute has a value for each link. Many-to-many associa(cid:173)
`tions are the rationale for link attributes.
`Generalization and inheritance are powerful abstractions
`for sharing similarities among classes while preserving their
`differences. Generalization is the relationship between a
`class and one or more refined versions of it. The class being
`refined is called the superclass, and each refined version is
`45 called a subclass. Attributes and operations common to a
`group of subclasses are attached to the superclass and shared
`by each subclass. Each subclass is said to inherit the features
`of its superclass. Generalization and inheritance are transi(cid:173)
`tive across an arbitrary number of levels. The terms ancestor
`50 and descendent refer to generalization of classes across
`multiple levels. An instance of a subclass is simultaneously
`an instance of all of its ancestor classes. The state of an
`instance includes a value for every attribute of every ances(cid:173)
`tor class. Any operation on any ancestor class can be applied
`55 to an instance.
`Generalization and inheritance are fundamental concepts
`in object-oriented languages, and these concepts do not exist
`in conventional languages and databases. During conceptual
`modeling, generalization enables a developer to organize
`60 classes into a hierarchial structure based on their similarities
`and differences. During implementation, inheritance facili(cid:173)
`tates code reuse. Generalization refers to the relationship
`among classes; inheritance refers to the mechanism of
`obtaining attributes and operations using the generalization
`structure.
`The object schema may be viewed as consisting of a set
`of object classes, wherein each object class consists of a set
`
`40
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 20
`
`

`
`6,061,515
`
`5
`
`3
`of object instances, wherein each object instance contains a
`set of attributes, and wherein object classes and object
`instances may be linked in relationships.
`Instead of the above object model, conventional data store
`technology uses a data model in which a data model (also
`known as an information model or conceptual model) is
`designed by modeling the world that the application is to
`support. Then the data model is transformed into a particular
`database design by applying one or more standard
`transforms, for example, normalization which requires that 10
`data of an entity belong to that entity only.
`The data models offered by conventional database tech(cid:173)
`nology include fiat files, indexed file systems, network data
`model, hierarchial data model, and the relational model.
`The fiat file model provides a simple means of storing data 15
`in records which may be accessed according to the data
`therein; however, it provides no independence between the
`data and applications thus requiring the applications to be
`modified if the fiat file design is changed. A fiat file data store
`schema consists of records composed of fields.
`Indexed file systems provide fixed-length records com(cid:173)
`posed of data fields of various types, and indexes to more
`quickly locate records satisfying constraints on field values.
`An indexed file system data store schema consists of records
`composed of fields wherein certain fields may be keys
`(indexes).
`A network data model provides fixed-length records com(cid:173)
`posed of data fields of various types and indexes similar to
`the indexed file systems. In addition, the network data model 30
`provides record identifiers and link fields which may be used
`to connect records together for fast direct access. The
`network data model also uses pointer structures to encode a
`network structure or relationship of records. A network data
`store schema consists a set of network structures of records, 35
`wherein each record is composed of fields, wherein certain
`fields may be keys (indexes) and certain fields may be links
`to other records (link fields).
`The hierarchial data model, similar to the network data
`model, provides fixed-length records composed of data 40
`fields of various types, indexes, record identifiers and link
`fields, and pointer structures. However, the hierarchial data
`model limits the structure used to represent the relationship
`of records to tree structures. A hierarchial data store schema
`consists of a set of tree structures of segments (each tree 45
`structure defined by a pointer structure known as a Program
`Communication Block or PCB), wherein each segment
`consists of fields, and wherein certain fields may be keys
`(indexes), and wherein certain segments may be links or
`pointers to other segments (pointer segment).
`In the relational data model, the fundamental structure is
`the relation, which is a two-dimensional matrix consisting of
`columns and rows of data elements. A table is an instance of
`a relation in the relational data base. Each table has a name.
`A table must consist only of atomic fields of data, i.e., each
`field is a simple, indivisible type of data. A field is the basic
`unit of data representing one data fact.
`Each column has a label and contains atomic values of the
`same data type, wherein each atomic value is an attribute
`drawn from a set of possible values that is that column's
`domain. The order of columns is not significant and may be
`changed without changing the meaning of a tuple. Each
`column may be referred to by a unique pairing of the table
`name with the column label.
`Each table consists of zero or more tuples, which are rows 65
`of attribute values. Each row represents one relationship,
`and a row's identity is determined by its unique content, not
`
`4
`by its location. The order of rows is not significant. There are
`no duplicate rows. The domain for every attribute must
`consist of atomic value; there are no repeating groups. If the
`value for a particular field is unknown or does not apply,
`then the relational model assigns a null value.
`Tables contain information about entities or the relation(cid:173)
`ship between entities. Each tuple refers to a different entity,
`and each attribute value in the tuple supplies information
`about one characteristic of that entity. Each table must have
`a column or group of columns that serve to uniquely identify
`the tuple.
`Each set of attributes that uniquely identifies each tuple is
`referred to as a candidate key. There may be multiple
`candidate keys in a relation, but one must be designated as
`the primary key. Foreign keys are used to define a link to
`another table. A foreign key is a key taken from another table
`to create a linking value to serve as a means of navigation
`from one table to the other table. A table may contain as
`many foreign keys as links it requires to relate it to other
`tables with which it has relationships.
`The process of determining the correct location and
`function for each attribute to correctly formulate the rela(cid:173)
`tional schema is called normalization. Normalization
`decomposes incorrectly constructed relations into multiple
`correctly normalized relations.
`The relational model requires that all tables must be in at
`least first normal form. To be in first normal form, a relation
`must have domains consisting only of atomic values for each
`attribute. Repeating sets of attributes and multi-valued
`attributes are not allowed. Optionally, the relational model
`may be subject to additional higher forms of normalization
`based on functional dependency, i.e., the reliance of an
`attribute or group of attributes on another attribute or group
`of attributes for its value.
`The relational schema may be viewed as consisting of a
`set of tables, wherein each table consists of columns and
`rows, and wherein relations between table are specified by
`primary keys and foreign keys.
`In view of the above differences between object oriented
`technology and data store technology, there is a reed for a
`method of, and apparatus for, allowing a user to access a
`conventional data store from an object oriented application.
`In view of the above differences between object schema
`and data store schema, there is a need for a method of, and
`apparatus for, allowing a user to map between conventional
`data store schema and object schema.
`In view of the above, there is a need for a method of, and
`apparatus for, allowing a user to define a mapping between
`50 conventional data store schema and object schema.
`In view of the above, there is a need for a method of, and
`apparatus for, allowing a user to represent such a definition
`of a mapping between conventional data store schema and
`object schema.
`In view of the above differences between conventional
`data store schema, there is a need for a data store indepen(cid:173)
`dent method of, and apparatus for, meeting the above needs.
`In view of the above, there is a need for an object oriented
`60 language independent method of, and apparatus for, meeting
`the above needs.
`In view of the above, there is a need for a distributed
`client/server method of, and apparatus for, meeting the
`above needs.
`In view of the above, there is a need for a method of, and
`apparatus for, providing a user an improved user interface to
`meet the above needs.
`
`20
`
`25
`
`55
`
`BLUE COAT SYSTEMS - Exhibit 1086 Page 21
`
`

`
`5
`SUMMARY OF THE INVENTION
`
`6,061,515
`
`6
`Language, the data store independent Schema Mapping
`Internal Representation, and the single, uniform, data store
`independent interface to a Data Store Manager.
`In accordance with another aspect of the present
`invention, object oriented language independence is pro(cid:173)
`vided by the use of the object oriented language independent
`Schema Mapping Definition Language, the object oriented
`language independent Schema Mapping Internal
`Representation, and Code Generators which generate code
`10 in various object oriented languages from the Schema Map(cid:173)
`ping Internal Representation for accessing objects from data
`stores. These Code Generators may be used to generate
`access methods based on the Schema Mapping Internal
`Representation for accessing objects from a data store. To
`15 provide such access to a data store, a Code Generator may
`generate a combination of object oriented programming
`language and data store access language. The system then
`generates a make file describing the dependency of files,
`invokes the proper compilers, links the appropriate run-time
`20 libraries, and creates executable code for accessing a data
`store.
`In accordance with another aspect of the present
`invention, distributed client/server access of objects from
`conventional data stores is provided by use of one or more
`25 Client Data Store Managers and one or more Server Data
`Store Managers.
`In accordance with another aspect of the present
`invention, a graphical user interface, Smart Schema, is
`30 provided for mapping object schema to data store schema
`wherein the graphical semantics support the Schema Map(cid:173)
`ping Definition Language semantics. Another graphical user
`interface, Smart Access, allows an end user to access objects
`in a data store without the end user having to do any write
`35 application programming. The Smart Access user interface
`allows the user to test mapping and access methods regis(cid:173)
`tered with the Data Store Manager without having to write
`an application to access the objects from the data store in a
`run-time environment.
`
`5
`
`The invention disclosed herein comprises a method of,
`and system for, mapping and accessing objects from a
`conventional data store. The invention disclosed herein also
`comprises a method of, and system for, providing a high
`level language for mapping and accessing objects from a
`conventional data store. The invention disclosed herein also
`comprises a method of, and system for, providing a user
`interface for mapping and accessing objects from a conven(cid:173)
`tional data store. In accordance with one aspect of this
`invention, an object oriented application programming inter(cid:173)
`face to a data store manager provides a uniform and single
`interface for accessing one or more conventional data stores,
`regardless of the type of conventional data store.
`In accordance with another aspect of the present
`invention, a Smart Schema allows a user to map between
`object schema and conventional data store schema, regard(cid:173)
`less of the type of conventional data store.
`In accordance with another aspect of the present
`invention, a user may define a mapping between object
`schema and data store schema by use of a high level
`language, Schema Mapping Definition Language. The user
`may either write SMDL directly or generate SMDL through
`the use of the Smart Schema. The Schema Mapping Defi(cid:173)
`nition Language is data store independent, object oriented
`language independent, and extensible.
`In accordance with another aspect of the present
`invention, a definition of a mapping between object schema
`and conventional data store schema is represented by a
`Schema Mapping Internal Representation. The Schema
`Mapping Internal Representation contains representations of
`the object schema, the data store schema, and the mapping
`of the object schema and the data store schema. These
`representations are such that the Schema Mapping Internal
`Representation may be accessible by both development
`interfaces (Smart Schema and Smart Access) and run-time
`environments, or it may by used to generate an object
`oriented programming language for providing dire