Application program VSAMACCeSS Method
Charly Brown2017
visibility
…
description
9 pages
link
1 file
The present invention relates to a System and method for accessing non-relational data Stored in records on a host System by a relational access method. The implementation of a relational interface component allows data transforma tion and type conversion and gives a relational interface to non-relational data. An integrated mapping component is used to define the relational Structure of non-relational records or data. This relational Structure is used by the application program or database request. The mapping com ponent allows one to define columns with their characteristic (i.e. byte offset, data type, length). The definitions can be grouped in maps equivalent to a relational table and views representing a Subset of the columns defined in a map. Multiple different maps and views can be defined for one record. The information of the maps, columns and views are Stored in a repository. The inventive interface component uses the definitions Stored in the repository to access the non-...
Related papers
Database Implementation
Encyclopedia of Database Systems, 2009
Chapter 7 has presented models of databases; Chap. 8 discussed means to describe databases, and now we can finally look at actual database implementation problems. In this chapter we will proceed in a top-down fashion. We begin with methods derived from formal models and continue on to systems developed over time and regular use. The discussion in this chapter proceeds in the direction of increased binding, which causes loss of flexibility but increases the performance of systems. Such important implementation issues such as reliability, access protection, integrity, and data representation are not covered in this chapter; they are separately discussed in Chaps. 11, 12, 13, and 14. We concentrate on concepts, and do not present complete system descriptions, although many actual systems will be referenced to allow further study. Appendix B can be consulted for references about the systems named in this chapter. The exact syntax of examples based on these systems has been modified at times in order to provide continuity. The fact that a certain system is cited here as a commendable example does not imply an endorsement of this implementation for a given application but only reflects on the values of the concepts being discussed. 449 Objectives We have implied earlier a number of objectives for a database system design: 1 The ability to refer to data items without having knowledge of record or file structure and as a corollary: 2 The ability to change record or file content and structure without affecting existing database programs We also desire 3 The ability to handle related files within one general framework, so that the data in separate files can remain consistent and so that excessive redundancy in updating and storage can be avoided and 4 A description of the database integrating diverse points of view, so that this description can become a communication medium between data generators and information seekers In order to achieve these lofty goals, we will consider how to implement systems that use schemas to present high-level services while using file-based, record-oriented structures. Sec. 9-1 Issues in Database Implementation 451 9-1 ISSUES IN DATABASE IMPLEMENTATION In this introductory section we will introduce briefly some concepts that recur throughout this chapter. 9-1-1 Functionality and Generality Database-management systems can be built with a wide range of generality. A categorization of these approaches into three levels distinguishes systems which support a single application, several applications of the same type, or multiple types of applications. Some systems have developed through these three levels; others have been designed consciously to attack problems at one specific level. Single-Application Database Systems An organization establishes a database operation using available file system facilities, and designs application programs that interface to the database using a centrally maintained package which implements the required degree of data and structure description. The original airline reservation system at American Airlines, SABRE, many large information systems, such as MEDLARS (a system to query the medical literature), and military command and control systems are examples of this approach. Single-Application-Type Database Systems A group of users working in some type of application area recognizes the commonality of their needs. They or their vendor design a system to match their needs. User differences are incorporated into tables and schemas specific to the user. This step often follows success with a more single-minded system. Examples of this approach are the generalized airline reservation systems (PARS), clinical information systems (TOD, GEMISCH), and bills-of-materials systems (BOMP). Multiple-Application-Type Database Systems A vendor or academic group designs a system with the intent to serve the general database needs in a better fashion. An effort is made to provide a complete set of services. There will, of course, be a tendency to emphasize aspects relating to the experience of the designers, so that in practice a great deal of difference is found among the generalized systems. Another source for generalized systems is a continued evolution from single application or application-type services. An understanding of the history of generalized systems helps to explain features of their design. The development of the CODASYL specification and of the relational model for databases has provided a basis for generalized systems that are relatively independent of past history. Generalized systems developed independently encountered so far in the text are PRTV, RETRIEVE, SOCRATE, and SQL/DS. The IDS and IMS systems owe much to the BOMP applications.
Multimedia applications using a database programming language-INADA
Proceedings of the Third IEEE International Conference on Multimedia Computing and Systems
Databases become widely applied to such areas as computer-aided design, computer-aided manufacturing, computer-integrated manufacturing, software engineering, and multimedia applications. Data structures and data processes handled in these areas are so complex that it is impossible to process such data eciently with relational databases. Therefore, many researchers and commercial organizations have focused on object-oriented databases to benet by their high abilities to model entities in the real world and good performance, and developed prototype and commercial systems. In this dissertation, we exploit memory-mapped I/O environment instead of using buer pool environment which almost other work employs to implement persistence of objects. In the buer pool environment systems have t o c o n vert data formats between on primary memory and on secondary storage, and to decompose data bigger than the buer size. On the contrary, w e c a n a void the problem with the memory-mapped I/O environment. This dissertation also discusses several implementations of persistent pointers. As a result, we know the fact that performance of non-swizzling approaches is not so poor compared with that of swizzling approaches. Moreover, with taking functionalities provided by nonswizzling approaches into account, a non-swizzling approach can be a good alternative i n order to implement persistent pointers. As we manipulate objects with a long life span, it is needed to change forms and/or behaviors of persistent objects so as to adapt existed objects to up-to-date requirements for applications. To this end, we introduce multiple type objects in this dissertation: any persistent object can get/lose their types dynamically in this concept. Also, this dissertation proposes object-oriented views. The view mechanism in relational databases is quite convenient for users. The mechanism allows users to deal with relations Abstract as what they expect, and provides securities on the relations in some sense. Recently many researchers have tried to integrate the view mechanism in relational databases into objectoriented databases. We propose a view mechanism that is implemented by applying the multiple type concept to sets of objects. Update on a view can be automatically propagated to its base set in the implementation. I would like to oer special thanks to the members of Makinouchi and Yoshida Laboratories in the Department of Computer Science and Communication Engineering at Kyushu University. In particular, I thank Keiichi Teramoto (currently with Toshiba Co., Japan) for that he discussed various issues concerning most of this dissertation with me, and implemented prototype systems to concrete our ideas. I w ould also like to thank Dr. Masatoshi Arikawa (currently at Hiroshima City U n i v ersity) and Mr. Susumu Kuroki for all of the assistance that they provided during my graduate career. Finally, I w ould like to express my sincere gratitude and thanks to my father and my mother for always believing in me and for helping me to believe that I could earn a degree of doctor. Getting a degree is extremely hard work, and I could not have m a d e i t w i t h o u t their unconditional supports. In the 1980s, many relational database (RDB) systems were developed and put on the market. Since then, RDBs have been generally accepted around the world. These databases have been mainly used in the business area, for example, for the management of personnel matters and/or sales and inventory data in a company. Also, in the 1980s, many researchers tried to apply database systems more and more widely to such areas as knowledge bases, articial intelligence, software engineering, computer-1 Introduction Any persistent object can get and/or lose any type, or class in C++ and INADA. Adding and deleting types can be done at any time they are needed. Thus, users can model real world entities which c hange themselves as time goes by with this concept. It has to be noticed that the multiple inheritance mechanism cannot cover all the facilities that the proposed multiple type object mechanism. We also proposed views in the object-oriented framework. Many researchers have d i scussed integrating view mechanisms into object-oriented database systems [MM91, Rund92, SLT91, TYI88]. However, they could not implement the function of views completely. T h e y tried to implement object-oriented views as virtual classes. In order to create a view, they needed to reconstruct the class hierarchy for integrating the virtual classes into the hierarchy. It is very dicult because there is one and only one class hierarchy in their models. We d o not take this approach. Instead, we implement an object-oriented view as a virtual set. A set in INADA is an object having interfaces which are dened by the system so that the system can process set-oriented queries. More detailed explanation concerning this is given later on. 1.3 Organization of The Dissertation The remainder of this dissertation discusses the issues mentioned above in detail. Chapter 2 discusses how to make objects persistent and to implement persistent pointers within the framework of the memory-mapped le I/O environment. To examine several approaches to persistent p o i n ter implementations, we s i m ulated all the several approaches as using the class library of INADA. We s h o w the result of the simulation, and discuss them in Chapter 2. The discussion concludes that a non-swizzling approach is one of good choices for implementing persistent pointers. Chapter 3 introduces multiple type objects. The syntax and semantics in respect of the objects in INADA are explained in detail. An implementation of multiple type objects is also described. The implementation exploited the exibility of the non-swizzling approach, which is a natural consequence of the discussion in Chapter 2. Chapter 4 proposes object-oriented views. Some simple examples are employed to help readers understand the mechanism intuitively. Chapter 4 also proposes programming con
An entity-based database interface
2014
Abstract: A user interface to a database designed for casual, interactive use is presented. The system is entity-based · the data display to the user is based upon entities (e.g., persons, documents, organizations) that participate in relationships, rather than upon relations alone as in the relational data model (Codd[1970)).. Examples from an implementation of the system are shown, for a prototype personal database (PDB), developed in connection with the ZOG system at Carnegie-Mellon University (Robertson et al[1977]). Some details of the interface and associated issues concerning relational normal forms, views, and knowledge-based assistance are presented. Experience with the prototype system suggests that the entity-based presentation is appropriate for types of casual interactive use that existing database interfaces do not address, such as browsing. It is proposed that such an interface could be used to supplement a query language or other interface to allow users both kinds o...
An implementation of relational interface to an information retrieval system
Information Systems, 1981
Abstract In the paper a specialized relational interface to information retrieval systems is presented. Its aim is to enable the user to obtain aggregated data (eg total information about objects described by the database) in a simple and concise way. An additional relational database is produced by extraction of data from the main database. Data to be extracted are defined by the user in the terms of the DDL. The relational database is processed by means of the DML based on the relational algebra. Additional instructions of the DML enable the ...
Relational Database Programming
2016
Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights.
Relational Non Relational
We report the comparison between the two leading type of Database storage components prevailing in the industry. The Database is largely concerned with managing massive amount of data in a consistent, stable, repeatable and quick manner. The prominent features of both relational as well as non relational databases have been specified which form the basis of the comparison between the two types of database. The relational model is based on mathematical theory(set theory, relational theory) whereas the nonrelational databases may or may not have a single groundwork mathematical theory. Relational model is beneficial when it comes to reliability, flexibility, robustness, scalability requirements but in order to cater to the needs of modern applications where the data is huge and generally unstructured; Non-relational databases show true signs of usability here. Based on the characteristics, commonly used tools of relational and non relational databases are mentioned along with brief introduction of the tools. Comparison has been done between the tools to notify the distinctive features of tools of relational and non relational database. Conclusive remarks about the two categories of database have been mentioned.
Semantic Access: Semantic Interface for Querying Databases
Very Large Data Bases, 2000
Semantic Binary Object-oriented Data Model (Sem-ODM) provides an expressive data model (similar to Object-oriented Data Models) with a well-known declarative query facility - SQL (similar to relational databases). Advantages of using Sem-ODM include (i.) friendlier and more intelligent generic user interfaces; (ii.) comprehensive enforcement of integrity constraints; (iii.) greater flexibility; (iv.) substantially shorter application programs; and (v.) easier query facility.
Providing Object-Oriented Access To Existing Relational Databases
In Proceedings of the 32nd Annual Southeast …, 1997
The ability to use relational database technology and object-oriented technology together in an environment that preserves past investments in relational databases and applications is very important. Many information systems use relational database systems for e cient ...
US 20010018684A1
(19) United States
(12) Patent Application Publication (10) Pub. No.: US 2001/0018684 A1
(43) Pub. Date:
Mild et al.
Aug. 30, 2001
(54) SYSTEM AND METHOD FOR ACCESSING
(57)
(75) Inventors: Wilhelm Mild, Boeblingen (DE); Ingo
The present invention relates to a System and method for
accessing non-relational data Stored in records on a host
System by a relational access method. The implementation
of a relational interface component allows data transforma
tion and type conversion and gives a relational interface to
non-relational data. An integrated mapping component is
NON-RELATIONAL DATA BY RELATIONAL
ACCESS METHODS
Franzki, Schoenaich (DE)
Correspondence Address:
William A. Kinnaman, Jr.
IBM Corporation
2455 South Road (M/S P386)
Poughkeepsie, NY 12601 (US)
(73) Assignee: International Business Machines Cor
poration, Armonk, NY (US)
(21) Appl. No.:
09/791,924
(22) Filed:
Feb. 23, 2001
(30)
Foreign Application Priority Data
Feb. 25, 2000 (DE)........................................ OO 103.9650
Publication Classification
(51) Int. Cl. .................................................... G06F 7700
(52) U.S. Cl. .................................................................. 707/1
ABSTRACT
used to define the relational Structure of non-relational
records or data. This relational Structure is used by the
application program or database request. The mapping com
ponent allows one to define columns with their characteristic
(i.e. byte offset, data type, length). The definitions can be
grouped in maps equivalent to a relational table and views
representing a Subset of the columns defined in a map.
Multiple different maps and views can be defined for one
record. The information of the maps, columns and views are
Stored in a repository. The inventive interface component
uses the definitions Stored in the repository to access the
non-relational data and splits the records. Preferably based
on the SQL language non-relational data like VSAM data
can be accessed from any program using the relational
interface component. The original non-relational data
remains unchanged and older programs work without
changes. The present invention gives new possibilities for
host based programs using non-relational acceSS methods
and Supports the integration, transition and migration into
relational environments.
Application program
VSAMACCeSS Method
Patent Application Publication Aug. 30, 2001 Sheet 1 of 4
US 2001/0018684 A1
Application program
VSAMACCeSS Method
Steve Mer
Charly Brown
SELECT
name
age FROM table WHERE
FIG 2
c 471
Patent Application Publication Aug. 30, 2001 Sheet 2 of 4
Record Mapping
WSEWSAM Record structure from EMPPROG.COBOL
Column:
so title:
ae
- Offset:
25
- length:
35
-type:STRING
RECMAP DEFINE (MAP (EMPTABLE)
MAPCOLUMN ((name
FIELD (OFFSET(25), LENGTH(35), TYPE(STRING}))
RECARD (MYVSAM.RECARD)
CATALOG (MYUSERCATALOG) )
FIG. 3
Obtain VSAM record
structure information
Define a map
Define a view
F.G. 4A
US 2001/0018684 A1
Patent Application Publication Aug. 30, 2001 Sheet 3 of 4
US 2001/0018684 A1
VSE/VSAM Record Structure as used in EMPPROG.COBOL
Manager
Programmer
Mike Jonathan
Jane Smith
Designer
Steve Miller
Secretary
Charly Brown
FIG.4C
MY.USERCATALOG f MY VSAM.CLUSTERI EMPVEW
4711
Mike Jonathan
Jane Smith
Steve Miller
Charly Brown
FIG. 4D
Manager
Programmer
Designer
Secretary
Patent Application Publication Aug. 30, 2001 Sheet 4 of 4
VSE/ESA
old program
ACCeSS View
newlchanged program
Select pin?,name from
FIG. 5
Application program
VSAMSOL interface
VSAMACCeSS Method
FIG. 6
Mapping.
repository
US 2001/0018684 A1
Aug. 30, 2001
US 2001/0018684 A1
SYSTEMAND METHOD FOR ACCESSING
NON-RELATIONAL DATA BY RELATIONAL
ACCESS METHODS
the program (e.g., a COBOL copybook or a C header file).
After having this non-relational Structure of the record, at
least one map for each record is generated that maps the
non-relational data structure into a relational data structure
BACKGROUND OF THE INVENTION
0001) 1. Field of the Invention
0002 The present invention relates to a system and
method for accessing non-relational data Stored in records
on a host System. More Specifically the present invention
relates to a System and method for accessing non-relational
data or records by means of relational application programs
or relational access methods.
0003 2. Description of the Related Art
0004. Application programs in host environments use
access methods for reading and writing data. Many host
operating systems, especially the IBM VSE/ESA operating
system, offer non-relational access methods (IBM VSAM).
Non-relational access methods do not use or take care of any
Structure within the record except a key path. Each appli
cation program using Such records or data needs to define its
own view for the data managed by the non-relational acceSS
method. Different programs use different methods to man
age the Structure for Storing data. Therefore, developer of
application programs needs Special knowledge about the
operating System for writing records into a storage medium.
0005. In today's IT environments, standard interfaces
become more and more important for application develop
ers. In e-business applications the standard interfaces for
relational databases like ODBC and the IBM DB2 Call
Level Interface are well known and used for data access.
0006. Application programs using a standardized inter
face for relational databases are unable to acceSS records
Stored in a non-relational way.
0007. In the client/server environment independent soft
ware vendors offer a client/server architecture allowing
access to non-relational managed records or data by appli
cation programs designed to access relational managed
records or data only. A disadvantage of Such an architecture
is that the client as well the Server requires additional
programs for achieving the communication between the
relational application program Stored on the client Site and
the non-relational access method Stored on the Server site.
Furthermore, each client System requires its own program.
Finally, programs installed on the Server as well on the client
need the same version.
having columns and rows. The maps are Stored in a Storage
medium, e.g. a repository. A further embodiment of the
present invention allows one to generate views that are
based on the map information. Each view includes a Subset
of the columns defined in the map.
0011. An interface component is implemented for receiv
ing relational requests and executing them. The interface
component accesses the map specified in the relational
request, retrieves column information for accessing the data
element from the map and generates an optimized non
relational request using column information for accessing
the data element. The optimized non-relational request is
executed via a non-relational acceSS method.
0012. By the implementation of the host side interface
accesses to non-relational data can be made Via Standardized
commands like SQL. The integration, transition and migra
tion from the non-relational into relational environment is
accomplished without requiring additional program prod
ucts or adaptions of the original non-relational data.
BRIEF DESCRIPTION OF THE DRAWINGS
0013 The present invention will be described in more
detail by a preferred embodiment of the present invention in
connection with accompanied drawings in which:
0014 FIG. 1 shows a prior art host system using non
relational data.
0015 FIG. 2 shows an example for mapping a non
relational record into relational view according to the
present invention.
0016 FIG. 3 shows an example for generating a column
based on the record Structure as shown in FIG. 2 according
to the present invention.
0017 FIGS. 4A-4D show the inventive method for gen
erating maps and ViewS based on the record Structure as
shown in FIG. 2.
0018 FIG. 5 shows the inventive interface architecture
for mapping non-relational record Structure into a relational
view.
0019 FIG. 6 shows the inventive method for accessing
non-relational data by programs using relational access
methods.
SUMMARY OF THE INVENTION
0008. It is therefore an object of the present invention to
provide a System and method for accessing non-relational
records or data by programs using relational acceSS methods
avoiding the disadvantages of the prior art Systems.
0009. This object is solved by the features of the inde
pendent claims. Further embodiments of the invention are
DESCRIPTION OF THE PREFERRED
EMBODIMENTS
0020. The implementation of an inventive relational
interface (e.g. VSAMSQL) component allows data transfor
mation and type conversion and gives a relational interface
to non-relational data.
laid down in the Subclaims.
0021. An integrated mapping component is used to define
0.010 The inventive method for accessing non-relational
data Stored in records by means of programs using relational
access methods Starts with the Step of gathering information
the relational Structure of non-relational records or data. This
Preferably, this information is obtained from source code of
columns with their characteristics (i.e. byte offset, data type,
that describes the non-relational data Structure of the record.
relational Structure is used by the application program or
database request.
0022. The mapping component allows one to define
Aug. 30, 2001
US 2001/0018684 A1
length). The definitions can be grouped into maps equivalent
structure as shown in FIG. 2. To enable the work with
views can be defined for one record.
process of Structuring/mapping data must be done first. This
Step, also called record mapping, defines the Structure of the
VSE/VSAM record and stores it in the mapping repository.
to a relational table and views representing a Subset of the
columns defined in a map. Multiple different maps and
0023 The information of the maps, columns and views
are Stored in one repository. The inventive interface uses the
definitions Stored in the repository to access the non-rela
tional data and Splits the records.
0024 Preferably based on the SQL language non-rela
tional data like VSAM data can be accessed from any
program using the relational interface component.
0.025 The original non-relational data remains
unchanged and older programs work without
0.026 changes. The present invention allows access to
non-relational managed data or records in a relational man
ner (in tables/maps and views) by Standardized requests like
VSAM data via the new inventive interface VSAMSOL, the
(In a relational database Such information is stored in the
database directory). Each part of a VSAM record that is to
be addressable as an independent data element via the
VSAMSOL interface is defined as a column in a so-called
map via the System-integrated mapping utility RECMAP. A
column definition contains the title of the column, the offset
within the record, the length of the field and the data type
(e.g. STRING, INTEGER). The characteristics for the col
umns are Stored in the mapping repository. A map can
contain one or more columns related to one VSAM record.
However multiple maps can be defined for one VSAM
record. To use only a part of the columns defined in a map
the construct of a view is used. A view contains a Subset of
SQL commands using the inventive relational interface
the columns defined in a map. Also multiple views can be
defined for a map. For example the View may contain name
and Salary or name and function or name, function and age.
data. The host System contains a operating System that
provides a non-relational acceSS method for writing and
reading data. Non-relational access methods do not use or
take care of any structure within the record except a key
path. Each program using Such records or data needs to
define its own view for the data managed by the non
relational acceSS method. Different programs use different
methods to manage the Structure for Storing data.
0033 FIG. 4B shows a sample VSAM record (non
relational record) that is mapped according to the present
component (e.g. VSAMSQL).
0.027 FIG. 1 shows a host system using non-relational
0028 FIG. 2 shows a VSAM record structure EMP
PROG.COBOL. The VSAM data has a non-relational struc
ture. The record consists of the data elements, e.g. data
empno (=employee number), function, name (=employee
name), Salary, age, dept (department). Only the application
program itself knows the order, length and structure of each
data element Stored in the record.
0029. Each record structure is transformed into a rela
tional view. In the preferred embodiment of the present
invention the relational view is defined by rows and col
umns. The data contained in the VSAM record must be
transformed in a column and row view representation. For
example the columns are defined by employee number,
function, name, Salary, age and department. Each row within
each column contains data concerning a certain employee.
The relational representation which is mainly used in rela
tional databases is accessed by SQL requests. SQL requests
may be created by Specifying a certain column from a certain
table with a selected row, e.g. Select “name, age (column)”
from table EMPTABLE where empno=471(row). The SQL
requests are sent to the VSAM interface component VSAM
SOL.
0030 FIG. 3 shows in detail how a column according to
FIG. 2 is generated. Each VSAM record consists of several
data elements that are defined by title, offset, length and
type.
0.031) Each data element that is to be addressable is
defined as a column. For example the data element with the
offset 25, length 35, type: string, title: name will be defined
as a column and is Stored in a mapping repository. The
column is accessible over MAP name EMPTABLE.
0.032 FIG. 4A shows a method for generating maps and
ViewS according to the present invention based on the record
invention supported by the RECMAP utility as follows.
With the RECMAP utility a map is defined with the name
EMPTABLE for the structure of FIG. 4B that contains the
following columns:
0034 empno field (offset (0), length (12), type (inte
ger)
0035 function field (offset (12), length (12), type
(string)
0036) name field (offset (24), length (20), type
(string)
0037 salary field (offset (44), length (9), type (inte
ger)
0038 age field (offset (53), length (4), type (integer)
0.039 dept field (offset (0), length (12), type
(packed).
0040. This information is stored in the mapping reposi
tory and is used by the VSAMSOL interface.
0041. The result is a logical relational table accessible via
the VSAMSOL interface using the information stored in the
mapping repository as shown above (see FIG. 4C).
0042 Based on the sample of FIG. 4C a view is defined
as follows. Supported by the RECMAP utility a view is
defined with the name EMPVIEW based on the map EMPT
ABLE which contains a Subset of the columns defined in the
map as follows:
0043 RECMAP DEFINE (MAP(EMPTABLE)
VIEW(EMPVIEW)
0044) VIEWCOLUMN(empid, REFCOLUMN(empno))
0045
VIEWCOLUMN(department,
REFCOL
UMNOdept))
0046) VIEWCOLUMN(FIRST NAME, REFCOL
UMNOname))
Aug. 30, 2001
US 2001/0018684 A1
0047) VIEWCOLUMN(function, REFCOLUMN
(function))
0.048 Views may be defined according to the system's
requirements.
0049. The result is a logical relational view, accessible
via the VSAMSOL interface using the information stored in
the mapping repository (see FIG. 4D).
0050 FIG. 5 shows the access view to VSAM data by
generating an optimized non-relational request using
column information for accessing Said data element;
and
executing Said optimized non-relational request Via a
non-relational acceSS method.
2. A method according to claim 1, wherein Said non
relational Structure information is obtained from Source
code.
3. A method according to claim 1, wherein Said non
using the inventive VSAMSQL interface in the IBM VSE/
ESA environment. The original VSAM data remains
unchanged, older programs work without changes. The
relational structure information is obtained from a COBOL
VSAMSOL interface uses the same VSAM data, but the
relational Structure information is obtained from a C header
file.
access is done on a column level. The interface is able to do
data transformation and type conversion. Based on the SQL
language VSAM data can be accessed from any VSE/ESA
program using the VSAMSQL interface. The VSAMSQL
interface is preferably based on the DB2 CLI standard
interface. When a new program issueS SQL Statements
against VSAM data the VSAMSOL interface translates the
SQL statement into VSE/VSAM requests. Together with the
mapping definitions from the mapping repository it splits the
record into predefined columns. Then the columns are
accessed independently of each other. All VSAM related
logic is handled internally and is completely hidden from the
programming interface. Additionally the requests are opti
mized for VSAM specifications, for example by automati
cally Selecting the best index key.
0051 FIG. 6 shows the inventive method for accessing
non-relational data by programs using a relational access
method.
0.052 The application program designed to relational
access methods uses for example a dynamic SQL request
with the prefix VSAMSOL to redirect the request to the
inventive interface VSAMSOL.
0053) The VSAMSQL interface analyses the request,
accesses the mapping repository that contains the maps and
Views, identifies the Selected map or view, retrieves the
column information (offset, length) from the Selected map or
View, generates an optimized VSAM request and executes
the optimized VSAM request using the VSAM access
method.
What is claimed is:
1. A method for accessing data Stored in records having a
non-relational data Structure by means of a program using a
relational acceSS method, each of Said records containing at
least one data element, Said method comprising the Steps of:
gathering information that describes the non-relational
data Structure of Said records,
generating a map that maps Said non-relational data
Structure to a relational data Structure having columns
and rows,
Storing Said map in a storage medium; and
receiving a relational request Specifying a map and
executing Said request using an interface component
that performs the Steps of:
accessing the map specified in Said relational request to
retrieve column information for accessing Said data
element from Said map;
copybook.
4. A method according to claim 1, wherein Said non
5. A method according to claim 1, further comprising the
Steps of
generating a view based on Said map that includes a Subset
of the columns defined in Said map; and
Storing Said view in a Storage medium.
6. A method according to claim 5, wherein Said Step of
generating a map and Said Step of generating a View are
automatically performed by a mapping tool.
7. A method according to claim 5, wherein Said map and
Said view are Stored in a mapping repository.
8. A method according to claim 1, wherein each defined
addressable data element in a record is defined as a separate
column.
9. A method according to 1, wherein each column is
defined by an arbitrary name for the column, offset within
the record, length of field in the record and data type.
10. A method according to claim 1, wherein each record
or part thereof is defined in multiple maps.
11. A method according to claim 1, wherein each map or
part thereof is defined in multiple views containing a Subset
of columns defined in the map.
12. A method according to claim 1, wherein Said relational
request is a SQL request that is Specified by one or more
columns and the name of a related map or view.
13. A computer program product containing Software
code for executing the method of claim 1 when said program
product is run on a digital computer.
14. A method for accessing data Stored in records having
a non-relational data Structure that includes at least one data
element by means of a program using a relational access
method, each record or part thereof being defined in a map
in a relational view having columns and rows, Said method
comprising the Steps of:
receiving a relational request Specifying a map and
executing Said request using an interface component
that performs the following Steps:
accessing the map specified in Said relational request;
retrieving column information for accessing Said data
element from Said map;
generating an optimized non-relational request using
Said column information for accessing Said data
element; and
executing Said optimized non-relational request Via a
non-relational acceSS method.
Aug. 30, 2001
US 2001/0018684 A1
15. A computer program product containing Software
code for executing the method of claim 14 when said
program product is run on a digital computer.
16. A System for accessing data Stored in records having
a non-relational data Structure via a program using a rela
tional acceSS method, comprising:
a repository containing a map or view that maps said
non-relational data structure to a relational data Struc
ture having columns and rows, and
an interface component for mapping relational requests
from Said program to non-relational requests by means
of information from Said repository.
17. A method for mapping a non-relational data Structure
of a record to a relational data structure, comprising the Steps
of:
gathering information that describes the non-relational
data Structure of Said record;
generating a map that maps Said non-relational data
Structure to a relational data Structure having columns
and rows, and
Storing Said map in a storage medium.
18. A method according to claim 17, further comprising
the Steps of:
generating a view based on Said map that includes a Subset
of data elements defined in Said map; and
Storing Said view in a Storage medium.
19. A computer program product containing Software
code for executing the method of claim 18 when Said
program product is run on a digital computer.
k
k
k
k
k
Related papers
Colloquy: Musicology and the Middlebrow
Journal of the American Musicological Society, 2020
Czy groby komorowe z X i początku XI w. są pochówkami pierwszych chrześcijan w Polsce piastowskiej i na Rusi?/Are the chamber graves of the 10th and early 11th century, the graves of the early Christians in Polish Piast state and in Rus’?
Hierofanie, wierzenia, obrzędy … Kultura symboliczna w średniowieczu między pogaństwem a chrześcijaństwem, eds. S. Rosik, S. Jędrzejewska, K. Kollinger, Rzeszów 2018, pp. 159-186.
The Genealogy of Justice and Laws in Epicureanism
Ancient Philosophy , 2022
The role of storytelling as a possible trauma release for war veterans: A narrative approach
HTS Teologiese Studies/Theological Studies, 2024
Más allá del ensayo. Perspectivas metodológicas de un género literario por excelencia
Forum. Revista Departamento de Ciencia Política, 2020
‘Vague Native Rights to Land’: British Imperial Policy on Native Title and Custom in New Zealand, 1837–53
The Journal of Imperial and Commonwealth History, 2010
Radio Frequency Interference Mitigation
arXiv: Instrumentation and Methods for Astrophysics, 2017
L'habitat de La Tène ancienne du Château à Roissy-en-France (Val-d'Oise)
Revue archéologique d'Ïle de France, 2008
Reflections on Decentralization, Community Empowerment and Sustainable Development in Cameroon
International Journal of Emerging Trends in Social Sciences, 2017
Prevalence of schistosomiasis and associated factors among students attending at elementary schools in Amibera District, Ethiopia
Open Journal of Preventive Medicine, 2013
Pazar Elma Fabrikası - Pazar Apple Factory
Demir Elma: Doğa, İnsan, Kültür - Nature, Human, Culture, 2024
Because a Man is Just a Bonus: A Qualitative Study on Women Who Decide Not to Marry
OISAA Journal of Indonesia Emas, 2023
Alteration of submarine basaltic glass from the Ontong Java Plateau: A STXM and TEM study
Earth and Planetary Science Letters, 2007
Histological Findings Following Excision of Peritoneal Endometriosis With and Without Using Aqua Blue Contrast Technique (ABCt™)
Journal of Minimally Invasive Gynecology, 2015
2,5-Dichlorothiophene 1,1-dioxide
Acta Crystallographica Section E Structure Reports Online, 2009
Clinical genetic testing and counselling in autism spectrum disorder
Medizinische Genetik, 2020