The present invention relates, in general, to the field of data maintenance and, in particular, to a method and a system for managing a database having a plurality of tables.

BACKGROUND

In Information Technology (IT), software applications are important for running any business, and these applications act as the backbone of e-business. Examples of such applications include Supply Chain Management (SCM), Customer Relationship Management (CRM), Enterprise Content Management (ECM), Enterprise Resource Planning (ERP), etc. Typically, these software applications have a lot of data which is referred to by a main application or different applications. Such reference data is known as master data. For instance, in the ERP system, the master data includes customer data, item data, and an account data. In addition, the master data includes information on products, item codes, and suppliers for the supply chain system. Moreover, in the finance system, the master data includes information on cost centers, department codes, and company hierarchies. Typically, the master data is present in a database in the form of one or more tables. It can be defined as the information required for core business entities to capture business transactions and to measure results of these entities. The master data is the data that drives the organization system, such as ERP & business intelligence, and therefore it is often one of the key assets and the core data of any organization. The immense importance of the master data elucidates that it is mandatory to maintain it.

Although a number of solutions are available in the market for maintaining the master data, there are a number of disadvantages associated with these solutions. One of the disadvantages is that these solutions follow a traditional approach of having a business component, a data component, and a presentation component for each table present in the database. Further, the data component, the business component, and the presentation component need to be developed separately for each table present in the database.
Pursuant to this, the effort involved in maintaining data is the multiple of the total number of tables which need to be maintained; thus, a significant amount of effort is required to use these solutions. A huge cost and time is also incurred while developing the components as above. Further, the solutions focus on code-duplication approach, leading to an accumulation of a large number of codes which is difficult to maintain. Moreover, these solutions provide a framework, which is not re-usable across different IT applications/platforms.

In view of the foregoing discussion, there is a need for designing a framework to maintain multiple data tables present in a database such that development effort, time, and cost are significantly reduced. The framework must focus on minimizing code duplication, thereby increasing the maintainability of a business application. Additionally, the framework should be re-usable across different IT applications.

SUMMARY

The present invention discloses a method for managing a database having one or more tables. The method includes receiving an input command from a user for maintaining a table of the one or more tables. In accordance with an embodiment of the present invention, the input command is present in the XML file. After receiving the command, an Extensible Markup Language (XML) file corresponding to the table is identified. The XML file is identified based on the input command provided by the user. Thereafter, a screen suitable for enabling the user to perform one or more functionalities corresponding to the input command is prepared. The screen is prepared by utilizing screen objects corresponding to the XML file. In accordance with an embodiment of the present invention, the same screen classes can be used for all tables. Various examples of the functionalities may include but are not limited to, such as, View, Add, Update and Delete. Subsequently, a query corresponding to the input command is executed for maintaining the table based on the functionalities.

The present invention further discloses a system for managing a database having one or more tables. As disclosed, the system includes a receiving module, a function module, an identification module, a screen preparation module, and a query processing module. The receiving module is configured for receiving an input command from a user for maintaining a table of the one or more tables. The input command may include at least one of: View, Add, Update and Delete. Further, the function module is configured for processing the input command for maintaining the table. Then, the identification module identifies an Extensible Markup Language (XML) file corresponding to the table, the XML file being identified based on the . input command. Thereafter, the screen preparation module prepares a screen suitable for enabling the user to perform the functionalities corresponding to the input command. The screen is prepared by utilizing a screen object corresponding to the XML file. Lastly, the query processing module executes a query corresponding to the input command for maintaining the table based on the functionalities.

Additionally, the present invention discloses a Computer Program Product (CPP) for use with a computer. The CPP includes a computer usable medium having a computer readable program code embodied therein for managing a database having one or more tables. The computer readable program code includes a program instruction means for receiving an input command from a user for maintaining a table of the one or more tables. The computer readable program code further includes a program instruction means for identifying an XML file corresponding to the table, the XML file being identified based on the input command. Furthermore, the computer readable program code includes a program instruction means for preparing a screen suitable for enabling the user to perform one or more functionalities corresponding to the input command, the screen is prepared using a screen object corresponding to the XML file. Moreover, computer readable program code includes a program instruction means for executing a query corresponding to the input command for maintaining the table based on the functionalities.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments of the invention will, hereinafter, be described in conjunction with the appended drawings provided to illustrate, and not to limit the invention, wherein like designations denote like elements, and in which

FIG. 1 illustrates an exemplary environment in which various embodiments of the present invention can be practiced;

FIG. 2 depicts various modules for managing a database having one or more tables, in accordance with an embodiment of the invention;

FIG. 3 is a flowchart for managing a database having one or more tables, in accordance with an embodiment of the present invention;

FIGs. 4a and 4b show a detailed flowchart for managing a database having one or more tables, in accordance with an embodiment of the present invention;

FIG. 5 represents an exemplary snapshot of View screen enabling a user to perform one or more functionalities, in accordance with an embodiment of the present invention; and

FIG. 6 exemplifies another snapshot of Update screen enabling a user to perform one or more functionalities, in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

In the field of Information Technology (IT), every software (or business) application has data storage and hence, they require some User Interface (UI) for data maintenance, in particular, for master data maintenance. In view of this, the present invention proposes a framework for maintaining the master data of a business application, for example, a plurality of tables. The framework is used to develop an admin application for managing the plurality of tables present in a database. Various examples of operations (functionalities) which can be performed on the tables include, but are not limited to, View, Add, Update, and Delete. For managing the tables, one business component, one data component, one controller servlet and four Java Server Pages (JSPs) are developed.
The business component is developed through four methods such as View, Add, Update, and Delete. The data component is developed for accessing the database. The JSPs are used for preparing the View, Add, Update and Delete Screens. Further, the Servlet is used for controlling the flow between the JSPs based on the user input. All the data, including queries, tables, columns, fields and the like is stored in the form of Extensible Markup Language (XML). At the time of enhancement in the main business application, for instance, an enhancement results in addition of 10 tables, few changes are required to be made only in the XML file and no changes are required in the code. In this way, the framework reduces the development time as well increases the maintainability of the business application to a great extent. The framework can be used across different IT applications.

FIG. 1 illustrates an exemplary environment in which various embodiments of the present invention can be practiced. More particularly, FIG. 1 is shown to include an XML-based framework 100. Framework 100 is used to develop the master data maintenance User Interface (UI) applications, more commonly known as admin applications. Through these admin applications, a user is able to View, Add, Update, and Delete the master data of business applications. Typically, the master data of the business application is present in a database in the form of one or more tables. Further, framework 100 can be used along with any presentation and persistence framework to develop such admin applications. While developing the admin application, a developer is free to choose his/her own UI and persistence framework and accordingly, the entire admin application can be developed using framework 100. Framework 100 further includes one or more business rules. The business rules can be used to retrieve data from the database to understand which data needs to be persisted in which database structure and to interpret how to prepare/design the UI application. These rules are stored in the form of XML; therefore these can be modified / added easily without increasing the development time. Moreover, the same rules can be used dynamically to prepare the UI or persistence of the data, thereby avoiding the development of hard-coded UI. Thus, framework 100 reduces the development time as well increases the maintainability of the business application to a great extent.

Framework 100 includes a "jar" file and an XML file which can be modified /copied to create more XMLs according to the requirement of the main business application. For instance, the XML file developed for a single table can be modified to create XMLs for multiple tables which need to be maintained. Framework 100 may be used by a Web application. In accordance with another embodiment of the present invention, framework 100 may be used by a stand-alone client application. Typically, (for caching) applications using framework 100 call the classes in the ".jar" either when the application starts or whenever there is an update in the XMLs. Accordingly, all the data available in the XML form is put in the application's cache in the form of Java objects. These Java objects can be used by the application to develop View, Add, Update, and Delete functionalities, the functionalities are developed based on the input provided by the user.

In accordance with an embodiment of the present invention, framework 100 can also be used by client-server application or any other type of application for which Master Data Maintenance is required.

As shown in FIG. 1, framework 100 includes an XML layer and a data caching layer. XML layer creates one or more XMLs according to the requirement of the functionality.
In particular, an XML file is created for each table for which any of the four operations, including View, Add, Update, and Delete need to be performed through the admin application. The XML file is created in a pre-defined format. Each XML file includes data for operations such as View, Add, Update, and Delete for one table. All the data such as tables, queries, and fields, are stored in the form of XML.

Data caching layer caches the data present in the XML. In accordance with an embodiment of the present invention, the data like business rules, column names, and database queries are stored in the XML. Initially, all XML files are parsed by a parser, such as XML parser, and accordingly, the data is prepared in the form of objects, such as Java objects. In accordance with an embodiment of the present invention, the XML file is parsed at the start of the program / server to build the appropriate screen (table) objects which help to perform the adequate actions on the tables present in the database as well as the preparation of the screen. Each screen (table) object is associated with a corresponding XML file. Further, each screen (table) object is associated with a screen identifier. This identifier is used by the JSP to identify the screen (table) object corresponding to the XML file.

The objects in cache can be used by the application to either prepare the screen (View Screen, Add Screen, Update Screen and Delete Screen) or to update the database records (like view, add, update or delete the database records). As above, various examples of objects may include, but are not limited to, Singleton, AdminTableXMLVO, AdminScreenXMLVO, MessageVO, PreparedQueryVO, ParameterVO, ColumnXMLVO, and ColumnVO.

In accordance with various embodiments of the present invention, objects formed during parsing will be described below in detail.

Singleton object includes HashMap with key and value pairs. The key may be a Table Identifier (ID), and the value pair may represent an AdminTableXMLVO object for each XML table.

AdminTableXMLVO object further includes one or more objects/parameters, but are not
limited to, Boolean verticalView, Boolean multiplePrimaryKeyInView, String tableWidth, AdminScreenXMLVO viewScreen, AdminScreenXMLVO updateScreen, AdminScreenXMLVO addScreen, and AdminScreenXMLVO deleteScreen.

Boolean verticalView parameter indicates whether the screen depicting the table data needs to be in a vertical or a horizontal format.

Boolean multiplePrimaryKeylnView parameter describes whether the screen/table has a compound primary key.

String tableWidth describes the width of the table to be shown on the screen.

AdminScreenXMLVO viewScreen contains data for View screen.

AdminScreenXMLVO updateScreen contains data for Update screen.
AdminScreenXMLVO addScreen contains data for Add screen.

AdminScreenXMLVO deleteScreen contains data for Delete screen.

AdminScreenXMLVO object defines the data (like column name) to be shown on the screen, the table data (like database column name), and the query data.
AdminScreenXMLVO further includes a list footerMessages, headerMessages, column objects, and so forth. In particular, AdminScreenXMLVO includes a list of MessageVO,
PreparedQueryVO, and ColumnXMLVO objects.

MessageVO object includes data to be shown in the header and footer messages of the screen. MessageVO object may be static or dynamic in nature. Further, MessageVO object includes String Data and PreparedQueryVO objects. String data represents the message that needs to be shown on the screen. PreparedQueryVO objects are required when the message contains dynamic data and it needs to be fetched from the database. In case the information is static, the object is NULL.

PreparedQueryVO object includes prepared Query to be fired in the database and the parameters to be used while preparing the query. This object includes String Query which is used to View, Add, Update, and Delete data from the database. PreparedQueryVO lists ParameterVO objects.

ParameterVO object includes data to be used while running the Prepared Query.
ParameterVO object further includes String name, Boolean inSession, and Boolean blobData.

String name represents database column Name. Boolean inSession describes whether the column value needs to be added in the session or not. Further, Boolean blobData describes whether the datatype of the column is Blob or not.

Continuing with objects above, ColumnXMLVO object includes details about table columns and its representation on the screen. ColumnXMLVO object further includes ColumnVO object and PreparedQueryVO object. ColumnVO object contains the detailed information about each column. In particular, ColumnVO object contains String columnName, String displayName, String dataType, String fieldLength, Boolean mandatoryFlag, String description, String boxType, String boxSize, Boolean primaryKeyFlag, String maxValue, and Map columnData.

String columnName represents database column name.

String displayName describes column display name on screen.

String dataType depicts datatype of the column, for example, String, Integer, etc. String fieldLength indicates field length of the column.

Boolean mandatoryFlag describes whether the data in a column is mandatory. String description discloses a detailed description of the column.

String boxType shows the type of the field on the screen. For example, the object shows whether it is TextArea, ComboBox, and Label.

String boxSize indicates the length of the field on the screen.

Boolean primaryKeyFlag depicts whether the column is a primary key.

String maxValue describes the maximum value that can be entered into the field on the screen.

Map columnData describes the Map containing key, value pairs of String columnDataValue, and String columnDisplayDataValue. For instance, few of the columns may take only "Yes" or "No" value, the Map herein will be used to populate these kinds of values.

In addition to the above, framework 100 can be used for configuration, user management, monitoring, querying transactions, and so forth. In accordance with an embodiment of the present invention, framework 100 may follow dynamic content approach to develop the admin application. The dynamic information may include, but is not limited to, header message, footer message, reference table information, and the actions (functionalities) performed by the user.

FIG. 2 depicts various modules 200 for managing a database having one or more tables, in accordance with an embodiment of the invention. The tables represent the master data of a business application. Examples of various types of business applications may include, but are not limited to, Human Resource Management (HRM), Supply Chain Management (SCM), Customer Relationship Management (CRM), Inventory Management, Enterprise Content Management (ECM), and Enterprise Resource Planning (ERP). More specifically, FIG. 2 is shown to include a receiving module 202, a function module 210, a caching module 212, an object retrieving module 214, a query generation module 216, and a display module 218. Function module 210 further includes an identification module 204, a screen preparation module 206, and a query processing module 208.

Receiving module 202 receives an input command from a user for maintaining a table of the one or more tables. These tables are stored in a database. Examples of various types of databases may include, but are not limited to, relational database, operational database, distributed database, database warehouse, and an end-user database. Various examples of the input command may include but not limited to, View, Add, Update, and Delete. After receiving the input command from the user, function module 210 processes it. The processing includes the identification of an Extensible Markup Language (XML) file corresponding to the table by identification module 204. Further, the XML file is identified based on a table Identifier corresponding to the table. In accordance with an embodiment of the present invention, the XML file is created in a pre-defined XML structure. The pre-defined XML structure includes, but not limited to one or more header messages, one or more messages, one or more queries, one or more variables, one or more field columns, one or more footer messages, and one or more input commands. While creating the XML file, one or more classes corresponding to the data present in the XML file are created. The classes may be created in a pre-defined programming language, but are not limited to, Java. In accordance with an embodiment of the present invention, these classes are already created and are present in "Jar" file. Accordingly, the XML structure and class structure can be defined. Further, for each of the classes, one or more objects are created. In . addition to this, the method includes updating the XML file based on the one or more functionalities.

Based on the identified XML file and corresponding screen object, screen preparation module 206 prepares a screen suitable for enabling the user to perform one or more functionalities corresponding to the input command. Examples of the functionalities performed by the user may include viewing data, adding data, updating data, and deleting data. Various examples of the screen presented to the user may include, but are not limited to, View screen, Add screen, Update screen and Delete Screen. These screens are populated with the appropriate header and footer messages. The screen is prepared by using a screen object corresponding to the XML file as described above in conjunction with FIG. 1. The screen object further corresponds to the input command associated with the XML file. Thereafter, query processing module 208 processes a query corresponding to the input command for maintaining the table based on the functionalities. These queries are persent in the XML file and the corresponding screen object. In accordance with an embodiment of the present invention, the query may get modified based on the user action / input. In accordance with an embodiment of the present invention, the query can be defined as: 'select employee_number, employee_name, department, location from employee', 'update employee set employee_name ='Mike Benson' where employee_number='1234', delete from employee where employee_number='1234', insert into employee values ('1234', 'Mike Benson', 'Marketing').

Caching module 212 caches the data at the start of the application / server. In accordance with an embodiment, when the user performs the functionalities like add, update, delete, and view, caching module 212 is used for column name on screen, column name on database, and query to be fired on the database. The data corresponds to one or more commands associated with the table.

In accordance with an embodiment of the present invention, the objects in the cache are used to display data on the screen. In accordance with another embodiment of the present invention, the objects in the cache are used to maintain data present in the database.
Thereafter, object retrieving module 214 retrieves a table object from the plurality of objects. The table object includes the screen objects and one or more parameters corresponding to the table. The table object further includes other screen objects corresponding to one or more input commands for maintaining the table. Thereafter, query generation module 216 generates the query using the XML file (and corresponding object) prior to executing the query. Subsequently, display module 218 displays one or more screens to the user for enabling the user to perform the functionalities.

In accordance with various embodiments of the present invention, these different screens and the corresponding functionalities are described below in detail.

View Screen

View screen enables the user to view data in the tables present in the database. To view a particular table, the user needs to click on a table name to view records in the table. Once the user clicks on the table name, the underlying table id retrieves relevant AdminTableXMLVO object from HashMap in XMLInformation object. Thereafter, AdminScreenXMLVO viewScreen object is retrieved from AdminTableXMLVO object.
Thereafter, view screen is prepared according to the data structure available in XML and data is fetched from the corresponding table based on the query taken from the XML. The user can view the tables he or she wishes to. For instance, the user can view table packaging types as shown in FIG. 5.

Add Screen

Add screen enables the user to add one or more records in the existing tables. In accordance with an embodiment of the present invention, the user may add one or more records in the tables in the database. When the user wishes to perform Add functionality, he/she needs to click on the Add button as shown in FIG. 5. Accordingly, all the details related to Add functionality will be retrieved from AdminScreenXMLVO addScreen object. AdminScreenXMLVO addScreen object prepares the Add screen for the user and consequently enables the user to add data in the database. Once, user adds the record on the screen and clicks on 'Add', the database table is updated using the query present in the XML file (for the corresponding table). Typically, Add functionality is performed when the new values are inputted for all the columns, such as Package Code, Package Name, Max Pieces, and Avg. max weight (as shown in the FIG. 6).

Update Screen

Update screen enables the user to update the existing records of the tables present in the database. When the user wishes to perform Update functionality, he/she needs to click on the Update functionality. In particular, the user can update the data using the drop down as shown in FIG. 6. Pursuant to this, all the details related to update functionality will be retrieved from AdminScreenXMLVO updateScreen object. AdminScreenXMLVO updateScreen object prepares the Update screen for the user, and then enables the user to update data present in the database. Once, the user updates the record on the screen and clicks on 'Update', the database table is updated using the query present in the XML file (for the corresponding table).

Delete Screen

Delete screen enables the user to delete a record (s) of the table present in the database. When the user wishes to perform delete functionality, he/she needs to click on delete functionality as shown in FIG. 5. Subsequently, all the details related to delete functionality will be retrieved from AdminScreenXMLVO delete Screen object. Data associated with AdminScreenXMLVO deleteScreen object helps in the actual deletion of the data present in the database. The database record is deleted using the query present in the XML file (for the corresponding table).

In accordance with an embodiment of the present invention, an exemplary structure of data present in the XML file is shown below.

In accordance with another exemplary embodiment of the present invention, the pre-defined structure of the XML file has been depicted below. The XML structure below shows various parameters such as headers, footers, messages, fields, columns, and the corresponding values.

-

-

-

-

- Currency Table ]]>

SELECT currency_cd, currency_nm, no_of_digits_right, rate_conv_factor FROM currency order by currency_cd

-

-

-

- Add Currency
Table ]]>

-

INSERT INTO currency VALUES (?,?,?,?)

currency_cd
currency_nm
no_of_digits_right
rate_conv_factor

-

-

DELETE FROM currency WHERE currency_cd IN (?)
currency_cd

-

-

-

- Update Currency Master Table ]]>

-

UPDATE currency SET currencynm = ? , noofdigitsright = ? , rate_conv_factor = ? WHERE currency_cd = ?

currency_nm
no_of_digits_right
rate_conv_factor
currency_cd

For a person skilled in the art, it is understood that the structure or format of the XML file as described above is exemplary in nature and is simply used to facilitate the description of the present invention. The structure of the XML file may vary based on the requirements. The structure of the XML file may or may not represent the completeness of a component, but are sufficiently described in a sequence corresponding to the features described above. Thus, it is clear that the invention is not limited to the embodiments described herein.

FIG. 3 is a flowchart for managing a database having one or more tables, in accordance with an embodiment of the present invention.

The method includes receiving an input command from the user for maintaining a table of the one or more tables, at 302. Various examples of the input command may include View, Add, Update, and Delete. The tables are present in the database and the information about them is written in XML file. Each table is associated with the corresponding table identifier. After receiving the input command, at 304, an Extensible
Markup Language (XML) file corresponding to the table is identified, based on the input command. The XML file is identified based on a table Identifier corresponding to the table which needs to be maintained. The XML file is created in a pre-defined XML structure as above. Thereafter, at 306, a screen suitable for enabling the user to perform one or more functionalities corresponding to the input command is prepared. The screen is prepared by using a screen object (discussed above) corresponding to the XML file.

The screen object further corresponds to the input command associated with the XML file. For instance, if the input command relates to Update, then the corresponding Update screen is prepared and will be presented to the user. In another example, if the input command relates to View, then the corresponding View screen is prepared and shown to the user.

At the time of screen preparation, one or more objects corresponding to the data present in the XML file are referred (which are already cached at the start of the application / server).

The data herein corresponds to one or more commands associated with the table. After the objects are cached, an object corresponding to the table for which the command is received is retrieved. Further, the table object includes the screen object and one or more parameters corresponding to the table. The table object comprises other screen objects corresponding to the input commands for maintaining the table. Then at 308, an input data from the user based on the one or more functionalities to be performed by the user is received. For example, if the user clicks on add functionality, then before 310, the user adds a new employee data on the screen and then step 310 is executed. Further, the method includes generating a query prior to executing it. The query is generated by using the XML file. At 310, a query corresponding to the input command is executed for maintaining the table based on the functionalities, including View, Add, Update, and Delete.

In accordance with an embodiment of the present invention, the XML file has a pre-defined XML structure. The pre-defined XML structure includes one or more header messages, one or more messages, one or more queries, one or more variables, one or more field columns, one or more footer messages, and one or more input commands as shown in the above exemplary format. While creating the XML file, one or more classes and the corresponding objects are also created. In accordance with an embodiment of the present invention, the set of classes are prepared as per the structure of XML file and , different objects are created for each XML file / table using the same set of classes. In accordance with an embodiment of the present invention, objects are created using the XML file when the application or server starts. The classes can be created in a pre-defined programming language. Various examples of the pre-defined language may include, but are not limited to Java, VB, and C#.

FIGs. 4a and 4b show a detailed flowchart for managing a database having one or more tables, in accordance with an embodiment of the present invention.

The main objective of this flowchart is to manage data in the tables present in a database. These tables represent the master data of a business application. Further, information about these tables is also there in the XML file. Each table is associated with its corresponding table identifier. To start with, at 402, the method includes creating an XML file for each table present in a database. There are also one or more classes related to XML structure (same set of classes will be re-used for all XMLs/Tables, no need to create separate classes if a new XML / table is added / modified). The classes may be created in a pre-defined language such as Java. . Thereafter, at 404, objects corresponding to the data present in the XML file are cached. Typically, these steps are performed when the application starts or whenever there is an update in XMLs. In accordance with an embodiment of the present invention, the XML file is prepared in a pre-defined XML structure. Further, the XML file is updated whenever required.

Thereafter, at 406, an input command is received from a user. The command is received to maintain a table from a plurality of tables present in the database. After receiving the command, at 408, a table identifier of the table based on the input command is retrieved.
Thereafter, at 410, a table object such as AdminTableXMLVO, corresponding to the table identifier is retrieved. From the retrieved table object, at 412, a screen object based on the input command is retrieved. The screen object is retrieved based on the input command of the user. For instance, AdminScreenXMLVO viewScreen object is retrieved when the user wishes to view the table. According to another example, AdminScreenXMLVO addScreen object is retrieved when the user wishes to add one or more records in the database. Thereafter, at 414, data from the screen object is retrieved to prepare a screen for enabling the user to perform functionality corresponding to the input command. Examples of the functionality performed by the user may include, but are not limited to, View, Add, Update, and Delete. Then, at 416, an input data from the user based on the one or more functionalities to be performed by the user is received. Thereafter, at 418, a database query corresponding to the input command to perform the functionality is executed. Subsequently, at 420, the user is enabled to view data corresponding to the table and can accordingly maintain it.

In accordance with an exemplary embodiment of the present invention, a list of objects/parameters defined in AdminTableXMLVO object is shown below.

AdminTableXMLVO

boolean verticalView

boolean multiplePrimaryKeyInView

String containStaticData

String tableWidth

AdminScreenXMLVO viewScreen

AdminScreenXMLVO updateScreen

AdminScreenXMLVO addScreen

AdminScreenXMLVO deleteScreen

In accordance with an exemplary embodiment of the present invention, objects/parameters defined in AdminScreenXMLVO object are shown below.

AdminScreenXMLVO

List footerMessages

MessageVO

String message

PreparedQueryVO

String Query

List Parameters

ParameterVO

String name

boolean inSession

boolean blobData

In accordance with an exemplary embodiment of the present invention, various parameters of List headerMessages objects are described below.

List headerMessages

MessageVO

String message

PreparedQueryVO

String Query

List Parameters

ParameterVO

String name

boolean inSession
boolean blobData

In accordance with an exemplary embodiment of the present invention, various parameters of PreparedQueryVO are described below.

PreparedQueryVO

String Query

List Parameters

ParameterVO

String name

boolean inSession

boolean blobData

In accordance with an exemplary embodiment of the present invention, variables corresponding to List columns object are defined below.

List columns

ColumnXMLVO

ColumnVO

String columnName

String displayName

String dataType

String fieldLength

boolean mandatoryFlag

String description

String boxType

String boxSize

boolean primaryKeyFlag String maxValue Map columnData

String columnDataValue

String columnDisplayDataValue

In accordance with an exemplary embodiment of the present invention, variables corresponding to PreparedQueryVO object are listed below.

PreparedQueryVO

String Query

List Parameters

ParameterVO

String name

boolean inSession

boolean blobData

In accordance with various embodiments of the present invention, workflow of various operations such as View, Add, Update, and Delete are described below in detail.

Workflow for View Data Tables

Initially, the user inputs a command for viewing a table. Thereafter, the corresponding table identifier is retrieved. Next, the object corresponding to the table id, such as AdminTableXMLVO object is obtained. Once the object is retrieved, the corresponding screen object such as AdminScreenXMLVO is obtained. This screen object is retrieved by calling getViewScreen. Following this, the header and the footer messages are obtained by calling getHeaderMessages and getFooterMessages. Next, the details of all the columns corresponding to the table id are retrieved by calling getColumns. Each ColumnXMLVO object contained in the List object has detailed information about each column. Following this, query preparation is performed by calling getPreparedQueryVO method. Thereafter, the database query can be fired and table view results can be obtained. The data retrieved is stored in objects and can be painted on the view screen, while preparing the view for the user action. The same process is followed . when the user wishes to view other tables present in the database.

Workflow for Add Data Tables

This workflow has been described based on the assumption that the user is already on view screen page. Initially, the user needs to click on "Add" control button on the View Screen page as shown in FIG. 5. After receiving the Add command for a table, the corresponding table id is retrieved. Thereafter, the corresponding object such as AdminTableXMLVO object from the Framework HashMap against the Table Id is retrieved. From the AdminTableXMLVO, the corresponding screen object such as AdminScreenXMLVO addScreen object is retrieved by calling getAddScreen function. Pursuant to this, the appropriate header and footer messages are retrieved by calling getHeaderMessages and getFooterMessages method. Further, details of all the columns to be shown on the Add screen as described above are obtained. Accordingly, Add sceen is shown to the user. Here, the user needs to enter the data that needs to be added and click on the "Add" button/control to add the data on the screen in the database. Subsequent to this, PreparedQueryVO object is obtained from AdminScreenXMLVO object by calling getPreparedQueryVO method. Finally, the database query can be fired and the data can be added. Once the data is added, the user will be shown the view screen.

Workflow for Update Data Tables

This workflow is described based on the assumption that the user is already on view screen page. Initially, the user selects a record to be updated and can accordingly click on the Update button on the View Screen. Following this, the table id corresponding to the selected table record is obtained. Once the table id is obtained, the corresponding AdminTableXMLVO object from the framework HashMap against the key table id is retrieved. Further, the corresponding screen object such as AdminScreenXMLVO updateScreen object is obtained through getUpdateScreen method. Thereafter, the appropriate header and footer messages are retrieved by calling getHeaderMessages and getFooterMessages method. Accordingly, the details of all the columns to be shown on the Update screen are obtained as above and accordingly painted on the Update screen displayed to the user. Thereafter, the user enters the updates and can click on the Update button/control to update the data on the screen. The rest of the process is same as above. Once the data is updated, the user will be shown the view screen.

Workflow for Delete Data Tables

This workflow has been described based on the assumption that the user is already on view screen page. Initially, the user selects a record to be deleted and can accordingly click on the Delete button on the View Screen. Thereafter, the table id corresponding to the selected table record is obtained. Once the table id is obtained, the corresponding AdminTableXMLVO object from the framework HashMap against the key table id is retrieved. Further, the adequate screen object such as AdminScreenXMLVO deleteScreen object is retrieved by calling getDeleteScreen method. Following this, PreparedQueryVO object by calling getPreparedQueryVO method is retrieved. Thereafter, the record/records ids (selected by user) to be deleted are selected from the database. Using the Prepared Query as above, the database query can be fired and the data can be deleted.
Once the data is deleted, the user will be shown the view screen.

The present invention as described above has numerous advantages. The present invention facilitates a framework for managing a database having a plurality of tables, such as the master data. The framework reduces development effort, time, and cost to a great extent. It further minimizes code duplication and thus, business application can be maintained easily. Moreover, the framework can be used across different IT/software applications.

The method and the system for managing a database having a plurality of tables, or any of its components, as described in the present invention, may be embodied in the form of a computer system. Typical examples of a computer system include a general-purpose computer, a programmed microprocessor, a micro-controller, a peripheral integrated circuit element, and other devices or arrangements of devices that are capable of implementing the steps that constitute the method for the present invention.

The computer system typically comprises a computer, an input device, and a display unit.
The computer typically comprises a microprocessor, which is connected to a communication bus. The computer also includes a memory, which may include a Random Access Memory (RAM) and a Read Only Memory (ROM). Further, the computer system comprises a storage device, which can either be a hard disk drive or a removable storage drive such as a floppy disk drive and an optical disk drive. The storage device can be other similar means for loading computer programs or other instructions into the computer system.

The computer system executes a set of instructions (or program instruction means) that - are stored in one or more storage elements to process input data. These storage elements can also hold data or other information, as desired, and may be in the form of an information source or a physical memory element present in the processing machine.
Exemplary storage elements include a hard disk, a DRAM, an SRAM, and an EPROM.
The storage element may be external to the computer system and connected to or inserted into the computer, to be downloaded at, or prior to the time of use. Examples of such external computer program products are computer-readable storage mediums such as CD-ROMS, Flash chips, and floppy disks.

The set of instructions may include various commands that instruct the processing machine to perform specific tasks such as the steps that constitute the method for the present invention. The set of instructions may be in the form of a software program. The software program may be in various forms such as system software or application software. Further, the software program may be in the form of a collection of separate programs, a program module with a large program, or a portion of a program module.
The software may also include modular programming in the form of object-oriented programming. The software program that contains the set of instructions (a program instruction means) can be embedded in a computer program product for use with a computer. The computer program product comprises a computer usable medium with a computer readable program code embodied therein. Processing of the input data by the processing machine may be in response to users' commands, results of previous processing, or a request made by another processing machine.

The modules described herein may include processors and program instructions that are used to implement the functions of the modules described herein. Some or all the functions can be implemented by a state machine that has no stored program instructions or in one or more Application-specific Integrated Circuits (ASICs) in which each function or some combinations of some of the functions are implemented as custom logic.

While the various embodiments of the invention have been illustrated and described, it will be clear that the invention is not limited only to these embodiments. Numerous modifications, changes, variations, substitutions, and equivalents will be apparent to those skilled in the art, without departing from the spirit and scope of the invention.

We claim:

1. A method for managing a database having one or more tables, the method comprising:

a. receiving an input command from a user for maintaining a table of the one or more tables;

b. identifying an Extensible Markup Language (XML) file corresponding to the table, the XML file being identified based on the input command;

c. preparing a screen suitable for enabling the user to perform one or more functionalities corresponding to the input command, the screen being prepared by utilizing a screen object corresponding to the XML file; and

d. executing a query corresponding to the input command for maintaining the table based on the one or more functionalities.

2. The method of claim 1, wherein the input command corresponds to at least one of viewing, adding, deleting and updating of data present in the table.

3. The method of claim 1 further comprising creating the XML file for the table

4. The method of claim 3, wherein the XML file is created in a pre-defined XML structure, the pre-defined XML structure comprising one or more header messages, one or more messages, one or more queries, one or more variables, one or more field columns, one or more footer messages, and one or more input commands.

5. The method of claim 4 further comprising creating one or more classes corresponding to data present in the XML file, wherein the one or more classes are created in a pre-defined programming language.

6. The method of claim 5 further comprising creating one or more objects corresponding to each of the one or more classes.

7. The method of claim 1, wherein the XML file is identified based on a table Identifier corresponding to the table.

8. The method of claim 1, wherein the one or more functionalities comprise at least one of viewing, adding, updating and deleting of data in the table.

9. The method of claiml, wherein the screen object further corresponds to the input command associated with the XML file.

10. The method of claim 1 further comprising caching a plurality of objects corresponding to data present in the XML file, the data corresponds to one or more commands associated with the table.

11. The method of claim 10 further comprising retrieving a table object from the plurality of objects, the table object comprising the screen objects and one or more parameters corresponding to the table.

12. The method of claim 11, wherein the table object comprises other screen objects corresponding to one or more input commands for maintaining the table.

13. The method of claim 1 further comprising generating the query prior to executing the query, the query being generated by utilizing the XML file.

14. The method of claim 1 further comprising updating the XML file based on the one or more functionalities.

15. The method of claim 1 further comprising enabling the user to view data, add data, update data and delete data corresponding to the maintained table.

16. A system for managing a database having one or more tables, the system comprising:

a. a receiving module configured to receive an input command from a user for maintaining a table of the one or more tables;

b. a function module configured for processing the input command for maintaining the table, the function module comprising:

i. an identification module configured for identifying an Extensible Markup Language (XML) file corresponding to the table, the XML file being identified based on the input command;

ii. a screen preparation module configured to prepare a screen suitable for enabling the user to perform one or more functionalities corresponding to the input command, the screen being prepared by utilizing a screen object corresponding to the XML file; and

iii. a query processing module configured to execute a query corresponding to the input command for maintaining the table based on the one or more functionalities.

17. The system of claim 16, wherein the input command corresponds to at least one of viewing, adding, deleting and updating of data present in the table.

18. The system of claim 16, wherein the XML file for the table is created.

19. The system of claim 18, wherein the XML file is created in a pre-defined XML structure, the pre-defined XML structure comprising one or more header messages, one or more messages, one or more queries, one or more variables, one or more field columns, one or more footer messages, and one or more input commands.

20. The system of claim 18, wherein one or more classes are created corresponding to data present in the XML file, wherein the one or more classes are created in a pre-defined programming language.

21. The system of claim 20, wherein one or more objects are created corresponding to each of the one or more classes.

22. The system of claim 16, wherein the identification module identifies the XML file based on a table Identifier corresponding to the table.

23. The system of claim 16, wherein the screen object further corresponds to the input command associated with the XML file.

24. The system of claim 16 further comprising a caching module configured for caching a plurality of objects corresponding to data present in the XML file, the data corresponds to one or more commands associated with the table.

25. The system of claim 16 further comprising an object retrieving module configured for retrieving a table object from the plurality of objects, the table object comprising the screen objects and one or more parameters corresponding to the table.

26. The system of claim 25, wherein the table object comprises other screen objects corresponding to one or more input commands for maintaining the table.

27. The system of claim 16 further comprising a query generation module, the query generation module configured for generating the query prior to executing the query, the query being generated by utilizing the XML file.

28. The system of claim 16, wherein the XML file is updated based on the one or more functionalities.

29. The system of claim 16 further comprising a display module configured for displaying the screen to the user for enabling the user to perform the one or more functionalities.

30. The system of claim 29, wherein the display module enables the user to view data, add data, update data and delete data corresponding to the maintained table.

31. A computer program product for use with a computer, the computer program product comprising a computer usable medium having a computer readable program code embodied therein for managing a database having one or more tables, the computer readable program code comprising:

a. a program instruction means for receiving an input command from a user for maintaining a table of the one or more tables;

b. a program instruction means for identifying an XML file corresponding to the table, the XML file being identified based on the input command;

c. a program instruction means for preparing a screen suitable for enabling the user to perform one or more functionalities corresponding to the input command, the screen being prepared by utilizing a screen object corresponding to the XML file; and

d. a program instruction means for executing a query corresponding to the input command for maintaining the table based on the one or more functionalities.

32. The computer program product of claim 31, wherein the input command corresponds to at least one of viewing, adding, deleting and updating of data present in the table.

33. The computer program product of claim 31, wherein the XML file for the table is created.

34. The computer program product of claim 31, wherein the XML file is identified based on a table Identifier corresponding to the table.

35. The computer program product of claim 31, wherein the one ox more functionalities comprise at least one of viewing, adding, updating and deleting of data in the table.

36. The computer program product of claim 31, wherein the screen object further corresponds to the input command associated with the XML file.

37. The computer program product of claim 31, wherein the computer program code further comprises a program instruction means for caching a plurality of objects corresponding to data present in the XML file, the data corresponds to one or more commands associated with the table.

38. The computer program product of claim 37, wherein the computer program code further comprises a program instruction means for retrieving a table object from the plurality of objects, the table object comprising the screen objects and one or more parameters corresponding to the table.

39. The computer program product of claim 38, wherein the table object comprises other screen objects corresponding to one or more input commands for maintaining the table.

40. The computer program product of claim 31, wherein the computer program code further comprises a program instruction means for generating the query prior to executing the query, the query being generated by utilizing the XML file.

41. The computer program product of claim 31, wherein the XML file is updated based on the one or more functionalities.

42. The computer program product of claim 31, wherein the computer program code further comprises a program instruction means for enabling the user to view data, add data, update data and delete data corresponding to the maintained table.