Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-09-13
2003-01-14
Vu, Kim (Department: 2172)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000, C707S793000
Reexamination Certificate
active
06507833
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to computer systems and more particularly to a method and apparatus for dynamically rendering components at run time.
BACKGROUND OF THE INVENTION
For a number of years now, database management systems have been used to store and to manage data critical to a company's operation, such as sales data, employee data, and customer information. One type of database management system that has emerged as the most prevalent is the relational database management system (RDBMS). In an RDBMS, information is stored in structures known as tables. A table typically comprises a plurality of columns and rows, with each column representing an attribute of a record and each row representing a particular record. In a relational database, information is manipulated by way of queries. A query is a statement that specifies which attributes of which records are to be manipulated, and what operations are to be performed on them. A query is typically written using a structured query language, such as SQL, that is understood by the RDBMS. When a query is submitted, the RDBMS parses and executes the query to manipulate the data as specified. In a relational database, queries can be used to perform all data manipulations, including insert, retrieve, update, and delete.
Queries are powerful tools for manipulating data in a relational database. However, their usefulness may be limited by the amount of knowledge that they require on the part of the user. In order to construct a query, a user needs to be familiar with the structured query language used by the RDBMS. Such a language can be fairly complex and difficult to master. In addition, the user needs to know what information is stored in which tables. This in turn requires that the user be familiar with the schema of the database. In many implementations, end users of the database do not possess this level of sophistication. Hence, they cannot effectively interact with the database using queries.
To facilitate interaction between users and the database, applications such as forms and reports are typically developed. In a typical RDBMS, a form is used to insert, update, and delete information from the database. A report is usually used to retrieve mass amounts of information from the database and to present the information to the user in a particular format. Other applications have also been developed to present information to the user in other formats, including charts, menus, and hierarchies. One of the major underlying purposes of an application is to provide an interface for enabling a user to interact with the database without having to manually formulate queries. Queries are still used to interact with the RDBMS, but the burden of generating and manipulating the queries is on the application, not the end user. In essence, an application transfers the complexity of interacting with a database from the end user to the application developer.
Currently, applications are developed using one of two major methodologies. The first methodology involves writing actual computer code to define the functionality of the application. The application may be written in one of many different computer languages including C, C++, and Java. Using the chosen language, the developer defines the layout of the application and sets forth the logic for implementing the desired functionality. Once written, the application is stored as a static set of code, either in compiled form or as a source file. At run time, the application is executed just like any other program to enable a user to interact with the database. According to this methodology, each application is a separate and distinct executable entity. Thus, there needs to be a separate executable file for each and every form, report, etc.
A second methodology involves the use of an application development tool, such as Developer 2000 manufactured by Oracle Corporation of Redwood Shores, Calif. An application development tool typically comprises a design time engine and a run time engine. Using the design time engine, a developer defines the format of an application. The developer can also specify logic for controlling the functionality of the application. Once the defining process is completed, the design time engine generates an application, and stores it away as a static entity. One of the advantages of using a development tool is that it relieves the developer of having to write any actual computer code. Once the application is generated by the design time engine, it is ready for execution. At run time, the run time engine interprets the application, and renders the format and functionality defined by the developer. According to this methodology, each application is stored as a separate and distinct entity. Thus, as was the case with the first methodology, there needs to be a separate entity for each and every form, report, etc.
These two methodologies are generally effective for developing applications; however, they do have significant drawbacks which render them impracticable in certain implementations. One such drawback is that they require a relatively high level of sophistication from the application developer. With the first methodology, the developer needs to be a skilled programmer, having familiarity with both a programming language and the workings of a database. With the second methodology, while the developer is no longer required to write actual computer code, the developer still needs to learn to use the development tool. With a development tool such as Developer 2000 which has a deep and robust set of capabilities, the learning process can be quite involved. In many implementations, it would be desirable to have relatively unsophisticated users define and deploy applications. In such implementations, these two methodologies cannot be used.
Also, note that according to both methodologies, each application is stored as its own separate static entity. This means that for every form, report, or any other application used by a company, a separate static entity is stored and maintained. For large companies, the number of different applications can easily run into the thousands. With this large number of applications, the storage needed for all of the separate entities can be enormous. The process of maintaining and updating the entities can also be extremely tedious. In light of these shortcomings, an improved methodology for developing and deploying applications is needed.
SUMMARY OF THE INVENTION
To overcome the shortcomings of the prior art, the present invention provides an improved application development/deployment mechanism which enables relatively unsophisticated users to develop applications, and which does not require each application to be stored as its own large static entity. According to the present invention, there is provided a generic builder engine and a plurality of generic component rendering engines. As used herein, the term component refers to any application or any portion of an application for facilitating interaction between a user and a database, including but not limited to forms, reports, menus, charts, and hierarchies.
The general purpose of the builder engine is to make it simple for a user to define a particular component (i.e. to develop an application). The builder engine solicits from the developer, through a simple dialog, all of the information needed to define the component. In effect, the builder engine guides the developer through the defining process, thereby enabling a relatively unsophisticated developer to define a component. In one embodiment, the builder engine takes the form of a generic engine which solicits information from a developer based upon predefined metadata . More specifically, for each type of component that a developer can define, there is an associated set of predefined metadata. This metadata specifies what information needs to be solicited from the developer to define an instance of that type of component, and how that information should be solicited. Based upon this met
Beck Christopher
Hichwa Michael
Nishio Leo
Hickman Palermo & Truong & Becker LLP
Nicholes Christian A.
Oracle Corporation
Truong Bobby K.
Truong Cam-Y
LandOfFree
Method and apparatus for dynamically rendering components at... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for dynamically rendering components at..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for dynamically rendering components at... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3065112