Automatic storage of persistent ASN.1 objects in a relational schema

A translator for translating objects defined in Abstract Syntax Notation such as ASN.1 to a relational database schema permits persistent storage of object instances as records in a relational database. Object classes are mapped to entity tables with object instances represented by entity records. Simple attributes are mapped to primitive typed attribute columns and package or group attributes are mapped to separate dependent entity tables. Derived attributes are represented by joins of the parent and child entity records.

CROSS REFERENCE TO RELATED APPLICATIONS 
This invention is related to a co-pending application Ser. No. 09/628,258, 
filed Dec. 14, 1990 entitled "Automatic Storage of Persistent Objects in a 
Relational Schema" invented by the inventor of the present invention and 
filed simultaneously herewith. This co-pending application is hereby 
incorporated by reference. 
BACKGROUND 
1. Field of the Invention 
This invention relates generally to a technique for storing object 
instances described in an abstract syntax in a relational database schema. 
In particular, the present invention describes a method and apparatus for 
storing ASN.1 (see definition below) object instances in a relational 
database using a language such as SQL (Structured Query Language), 
although the present invention should not be limited to these particular 
languages. 
2. Background of the Invention 
With the advent of OSI standard descriptions of object representations in 
abstract syntax, it becomes desirable or necessary to store these objects 
in some form of persistent storage. Current OSI standards (ASN.1 and ASN.1 
Basic Encoding Rules) define only how an object representation is laid out 
within a protocol data stream. However, to store a persistent 
representation of objects, there is no definition for a storage format. 
Although object-oriented databases seek to achieve this function, they are 
not a mature technology at the time of this writing, and are not expected 
to reach this stage for some time to come. 
Relational database products, on the other hand, represent a mature 
technology. As standard object definition languages (such as ASN.1) gain 
rapid acceptance for application development, there will be a demand for 
techniques to store persistent object definitions within the schema of a 
relational database management system. The current invention addresses 
this need. It provides a technique for the easy storage of persistent 
representations of objects defined in source constructs of an abstract 
syntax, within the schema of a relational database. 
The technique will be illustrated in the examples with source constructs in 
ASN.1 interfaced with relational database requests issued in standard SQL. 
However, this is not restrictive, as this technique can be used with any 
abstract syntax using object-oriented macro notation with any relational 
database. 
The following sections describe how such translation could be implemented 
using a programmed computer. For purposes of this discussion, this 
programmed computer will be referred to with the tentative name "MIB 
Schema Compiler" (i.e. A compiler for an Abstract Syntax Notation 
definition for a Management Information Base, which generates a 
corresponding database schema definition in, for example, SQL). 
All examples in this discussion are from the realm of object modeling in a 
communications network. With the exception of occasional simplifications 
for conceptual clarity, all examples conform to object modeling guidelines 
proposed by various standards bodies. A basic familiarity with 
object-oriented modeling is assumed. 
DEFINITION OF TERMS 
Several of the terms used herein, while commonplace in relational database 
management environments or object oriented programming or ASN.1 
environments, may not be generally understood. General definitions of 
these terms are provided below. While it is not intended that the present 
invention be restricted by shortcomings in these definitions, it is 
believed helpful to provide these definitions as guidance to those 
unfamiliar with the terms. Those skilled in the art will understand that 
the present invention should only be limited by the conventionally 
understood meaning of these terms. 
object--A real physical or abstract logical entity useful for a given 
application (e.g. "person"). 
instance--A specific realization of an object (e.g. "Groucho Marx"). 
object class--A template specifying the abstraction for a given set of 
objects having characteristics in common. 
class construct or class macro--The representation of the template within 
the syntax of a programming language. 
inheritance--The classification of classes themselves, allowing classes to 
be organized in a hierarchy from the most abstract to the most specific, 
such that the lower classes are specializations of the upper classes, 
possessing all of the attributes of the upper classes and defining some of 
their own. 
relationship--The superclass/subclass relationship (also called a parent 
class/derived class relationship) along an inheritance hierarchy. 
schema--The logical organization of the data structures within a database. 
ASN.1--Abstract Syntax Notation One, an OSI and CCITT standard (ISO 8824 
and CCITT X.208) for describing the structure and contents of information 
objects in a formal notation. 
ASN.1 macro--A facility provided in ASN.1 to extend the syntax of the 
notation for customization to particular applications. 
SUMMARY OF THE INVENTION 
It is an object of the present invention to provide a method for 
representing ASN.1 object representations in a relational table schema. 
It is another object to provide a technique which permits storage of ASN.1 
objects in a persistent storage media. 
It is an advantage that the SQL relational database management systems can 
be used to store and manipulate the ASN.1 representations. 
These and other objects, advantages and features of the invention will 
become apparent to those skilled in the art upon consideration of the 
following description of the invention. 
In one aspect of the present invention, a translator for translating 
objects defined in Abstract Syntax Notation such as ASN.1 to a relational 
database schema permits persistent storage of object instances as records 
in a relational database. Object classes are mapped to entity tables with 
object instances represented by entity records. Simple attributes are 
mapped to primitive typed attribute columns and package or group 
attributes are mapped to separate dependent entity tables. Derived 
attributes are represented by joins of the parent and child entity 
records. 
In another aspect of the present invention, an apparatus for translating 
information represented as an Abstract Syntax Notation object-class 
hierarchy into a relational table schema includes a central processor and 
computer memory operatively coupled to the central processor for temporary 
storage of information. Persistent storage, operatively coupled to the 
central processor stores information in a persistent manner. An Abstract 
Syntax Notation file stored in the computer memory represents data in an 
Abstract Syntax Notation object class hierarchy. A MIB Schema Compiler is 
stored in the computer memory, for translating the data represented in the 
Abstract Syntax Notation object class hierarchy into a relational table 
schema. 
A method, according to the present invention, for a computer to translate 
an Abstract Syntax Notation object class hierarchy into a relational 
schema includes the steps of: providing an Abstract Syntax Notation class 
hierarchy of object-oriented information comprising at least one parent 
class having a first attribute and one derived class having a second 
attribute, the derived class inheriting the first attribute from the 
parent class; defining a first table structure, corresponding to the 
parent class, including a first table name, the first table structure 
including: a first instance identifier field for storing a first instance 
identifier which identifies a particular instance of the derived class, 
and a first field for storing instances of the first attribute, the first 
instance identifier field and the first field comprising a record of the 
first table structure; defining a second table structure, corresponding to 
the derived class, including a second table name, the second table 
structure including: a second instance identifier field for storing a 
second instance identifier which identifies a particular instance of the 
derived class, and a second field for storing instances of the second 
attribute, the second instance identifier field and the second field 
comprising a record of the second table structure; and referencing the 
second instance identifier field to the first instance identifier field. 
Another method for a computer to translate an Abstract Syntax Notation 
object class definition into a relational schema, includes the steps of: 
providing an Abstract Syntax Notation class definition of object 
information comprising a first attribute; defining a first table 
structure, corresponding to the object class, including a first table 
name, the first table structure including: a first instance identifier 
field for storing a first instance identifier which identifies a 
particular instance of the object class, and a first field for storing 
instances of the first attribute, the first instance identifier field and 
the first field comprising a record of the first table structure. 
The features of the invention believed to be novel are set forth with 
particularity in the appended claims. The invention itself however, both 
as to organization and method of operation, together with further objects 
and advantages thereof, may be best understood by reference to the 
following description taken in conjunction with the accompanying drawings 
and examples.

DETAILED DESCRIPTION OF THE INVENTION 
1. Overview 
The preferred embodiment of the present invention is implemented in the 
form of a translator which converts ASN.1 object-oriented representations 
into relational tables. This concept is illustrated in FIG. 1 which shows 
unstructured data 10 upon which structure may be imposed in either of two 
ways. When structure is imposed by modeling process 12, an object class 
hierarchy organization 14 of the data results. When structure is imposed 
by modeling process 16, a relational schema organization 18 results. The 
present invention bridges these two structured representations of data by 
providing a translator from a class hierarchy organization such as 14 to a 
relational schema organization such as 18 providing a mechanism for 
persistent storage of data using known relational database techniques. 
The technique of the preferred embodiment of the present invention will be 
illustrated in examples with source constructs in ASN.1, interfaced with 
relational database requests issued in standard SQL. However, this is not 
restrictive, as this technique can be used with other object 
representations with any appropriate relational database. Standard SQL is 
described, for example, in "A Guide to the SQL Standard" , by C. J. Date, 
2nd Ed., Addison Wesley, 1989. ASN.1 is described in "Abstract Syntax 
Notation One: The Tutorial and Reference", Douglas Steedman, The PSC 
Institute, 1990 which is incorporated by reference. 
The present invention will be described with the help of flow charts to 
describe the actual process, followed by ASN.1 and SQL examples. All 
examples are from the realm of object modeling in a communications 
network. With the possible exception of occasional simplifications for 
conceptual clarity, all examples conform to object modeling guidelines 
proposed by various standards bodies. A basic familiarity with SQL and 
ASN.1 is assumed. 
Before proceeding with a discussion of the invention itself, it may be 
helpful to provide a brief discussion of the physical environment 
associated with the sample code, that is a communication network. Such a 
communication network may be made up of many physical devices such as 
modems, digital service units (DSU's), terminals, computers, multiplexers 
and such equipment coupled together via, for example, telephone lines, 
fiber optic channels, satellite links, etc. A typical example of such a 
network is an airline reservation system where numerous terminals (at 
airports, travel agencies, airline reservation offices, etc.) communicate 
with a central computer to access reservation information, flight 
schedules, seat assignments, etc. In such networks, there is typically a 
network management function which is used to monitor the network and 
determine the cause of any malfunction. In these environments, it is often 
critical to operation of the business to have the system fully operational 
nearly 100% of the time. Network management functions are used to quickly 
isolate problems and possibly reroute data traffic to circumvent problems. 
As part of the data communication network management system, a database 
containing various attributes of all physical objects (e.g. modems, DSU's, 
multiplexers, etc.) is usually maintained to facilitate the above 
functions. In order to utilize OOP techniques in the network management 
function, it is desirable to be able to provide persistent storage of the 
attributes of these objects managed by the network management system. With 
this background on the physical characteristics of the environment used 
for the examples, we can proceed with a discussion of the invention 
itself. 
In ASN.1, as well as other implementations of OOP, objects are represented 
using the class construct. A simple graphic example is shown in FIG. 2. A 
parent class 22 (designated P1) may have several attributes associated 
with it, for example attributes shown as att1, att2, att3 and att4. Such 
attributes might represent any physical attribute being manipulated by the 
program (e.g. temperature, color, size, manufacturer, modem speed, service 
contract number, etc. etc.). A derived class 24 (designated D1) inherits 
the attributes of parent class 22 and, in addition, derived class 24 has 
its own attributes designated att5, att6, att7 and att8. Similarly, 
derived class 26 (designated D2) inherits attributes att1 through att8 
from derived class 24 and parent class 22 and contributes its own 
attributes att9, att10, att11 and att12. An instance of derived class 26, 
therefore, includes all attributes att1 through att12 which fully define 
the object instance for purposes of the system at hand. This graphic 
example can be constructed using ASN.1 predefined macros to define the 
hierarchical relationship shown in FIG. 2. 
The macros used to illustrate examples in the present invention are the 
ASN.1 Managed Object Class macros defined by various network management 
standards bodies (such as those of the OSI/Network Management Forum 
specified in "Forum 003: Object Specification Framework" and ISO/CCITT 
specified in "X.722/ISO 10165-4: Structure of Management Information Part 
4"). However, the present invention should not be restricted to these 
standards alone. 
The present invention provides a mechanism for mapping this hierarchical 
schema into a relational table schema. Consider, for example, FIG. 3 in 
which an instance of derived class 26 is represented as a list of 
attributes 30. This list of attributes represents the form of information 
that a user of the system is interested in as a characterization of the 
instance of an object in class 26. Parent class 22 is mapped to a table 32 
which is named after the class name (P1) and which has four field columns 
defined for attributes att1 through att4. A fifth column 34 is defined to 
carry an object identifier (obj.sub.-- id) which may be generated by the 
translator 20. Records of this table (rows) are used to carry instances of 
all objects of class 22. 
In a similar manner, a table 38 is constructed representing derived class 
24. Table 38 is named D1 after the class 24 and includes field columns for 
attributes att5 through att8. In addition, a field column 40 is named P1 
after the parent class above class 24 in the hierarchy. In the preferred 
embodiment, this field contains the same object identifier (obj.sub.-- id) 
as that used in table 32. 
A third table 44 is constructed to represent derived class 26. Table 44 is 
named D2 after the name of class 26 and has four field columns 
representing attributes att9 through att12. A fifth column is named after 
the parent table or class as D1 and carries the same object identifier as 
those carried by tables 32 and 38 in the preferred embodiment. The three 
tables can be queried to extract a particular instance of class 26 by 
using, for example, a "JOIN" operator from SQL to find all attributes in 
records having the same object identifier in fields obj.sub.-- id of table 
P1, field P1 of table D1 and field D1 of table D2. 
FIG. 4A taken in conjunction with FIG. 4B shows how certain ASN.1 
constructs map into a relational schema. In particular, it shows how 
direct attributes of a Managed Object Class Template, including SET and 
SEQUENCE attributes of specified size, as well as CHOICE attributes, 
become direct columns in the table corresponding to the managed object 
class. It also shows that MULTI-VALUED attributes, as well as SET and 
SEQUENCE attributes of unspecified size are isolated into their own tables 
with an "instance identifier" column providing the joining linkage back to 
the table for the Managed Object Class. 
Table 50 is a mapping of the basic object class macro. Columns of table 50 
indicate specific attributes of the object class. Record 52 indicates an 
instance of the object class with specific attribute values for that 
instance stored in its various columns. Column 54 is the instance 
identifier for that object class and serves as a key into the entire 
table. Columns 56 are examples of direct attributes of primitive ASN.1 
types defined for the object class. Columns 58 show a relational 
representation of direct attributes of structured ASN.1 types of specified 
size, such as SET or SEQUENCE defined for the object class. Columns 60 
show a relational representation of a CHOICE ASN.1 type attribute defined 
for the object class. 
Table 62 indicates a relational representation of a MULTI-VALUED ASN.1 
attribute defined for the object class which is isolated in its own 
separate Table. Records 64 are instances of this MULTI-VALUED attribute 
belonging to the same object instance stored in Table 50. The instance 
identifier column 66 of Table 62 stores the same value as the instance 
identifier column 54 of Table 50 linking the two tables together and 
providing a mechanism for reconstructing the entire object. Column 68 of 
Table 62 stores the corresponding instances of the MULTI-VALUED attribute. 
If the MULTI-VALUED attribute is in turn a structured type, then 
additional columns may be necessary in Table 62, or additional dependent 
tables may be necessary. 
Table 70 shows a relational representation of a structured ASN.1 attribute 
of unspecified size of the object class (such as SET OF). Records 76 are 
the components of the instances of the structured attribute belonging to 
the same instance of the object class that was stored in Table 50. The 
instance identifier column 72 of Table 70 holds the same value as the 
instance identifier column 54 of Table 50, serving as a mechanism to link 
the two tables. Column 74 of Table 70 stores the values of the instances 
of the structured attribute. If the structured attribute is in turn a 
structured ASN.1 type, then additional columns may be necessary in Table 
70, or additional dependent tables may be necessary. 
Table 78 of FIG. 4B shows a relational representation of a structured ASN.1 
attribute of unspecified size of the object class (such as SEQUENCE OF). 
Records 86 are the instances of the structured attribute belonging to the 
same instance of the object class that was stored in Table 50. The 
instance identifier column 80 of Table 78 holds the same value as the 
instance identifier column 54 of Table 50, serving as a mechanism to link 
the two tables. Column 84 of Table 78 stores the values of the instances 
of the structured attribute. If the structured attribute is in turn a 
structured ASN.1 type, then additional columns may be necessary in Table 
78, or additional dependent tables may be necessary. In addition, column 
82 of Table 78 stores a sequence index to indicate the order of appearance 
of attribute instances in the structured type for use in reconstructing 
the SEQUENCE type. 
FIG. 4C shows how ASN.1 constructs corresponding to ATTRIBUTE GROUPS or 
CONDITIONAL KAGES map into a relational schema. These are mapped into 
separate tables for normalization purposes, as will be explained later. 
Any SET, SEQUENCE or MULTI-VALUED attributes which are part of such 
packages are treated similarly. That is, they are isolated into sub-tables 
if they are of unspecified size, or stored as direct columns if they are 
of specified size. 
All ATTRIBUTE GROUPS and CONDITIONAL KAGES are isolated into separate 
tables of their own such as Table 87. Record 88 of Table 87 indicates an 
instance of such an ATTRIBUTE GROUP or CONDITIONAL KAGE. Column 89 of 
Table 87 stores an instance identifier holding the same value as column 54 
of Table 50 indicating the object instance stored in Table 50 possessing 
that ATTRIBUTE GROUP or CONDITIONAL KAGE. Columns 90 of Table 87 store 
actual instances of attributes within the ATTRIBUTE GROUP or CONDITIONAL 
KAGE. Tables 91 and 94 are examples of how structured types of 
unspecified size or MULTI-VALUED attributes which may be part of the 
ATTRIBUTE GROUP or CONDITIONAL KAGE are mapped into the relational 
schema by isolating them in their own table in a manner similar to Tables 
62 and 70 of FIG. 4A. Columns 92 and 95 of Tables 91 and 94 respectively 
store the same instance identifier value as stored in column 89 of Table 
87 and column 54 of Table 50, serving to link the four tables. Columns 93 
and 96 of Tables 91 and 94 respectively store actual instances of the 
structured ASN.1 attributes of unspecified size. 
2. Mapping of Object Representations into Relational Schema 
2.1 Object Representation 
In standards being defined by Data Communications and Telecommunications 
standards bodies (such as the OSI/Network Management Forum, ANSI TIM1, and 
the CCITT X.700 series), objects are represented using ASN.1 macro 
notation. The macro notation defines a template for creating managed 
objects, and as such, can be viewed as analogous to a schema definition in 
a relational database. 
Typically, objects are defined in an object class hierarchy. This is done 
using clauses such as DERIVED FROM or SUBCLASS OF in the macro notation 
template. Further, attributes in each object macro are defined, with the 
syntax of each attribute expanding into an appropriate ASN.1 primitive 
type specified in the WITH ATTRIBUTE SYNTAX clause. 
For example, the following template is used by the OSI/Network Management 
Forum to define object classes. (Henceforth this will be referred to as 
the Forum Object Template). 
______________________________________ 
{class-label}M-OBJECT-