Information system and process for storing data therein

Details Information system and process for storing data therein Information system and process for storing data therein

1998-04-10

2001-03-27

Black, Thomas G. (Department: 2771)

Data processing: database and file management or data structures

Database design

Data structure types

C707S793000

Reexamination Certificate

active

06208992

ABSTRACT:

The invention concerns an information system, a process for storing data from a database in a store of an information system, wherein access to the database is possible via a program running in a dp system, and a data structure.
The term information system refers to a system for the entry, storage, processing/linking, representation, retrieval/evaluation and output of information or data. This type of system consists of a dp system, a database system, a database management system and application programs and evaluation programs which are able to access the information system, as well as input and output devices.
According to Duden's “Informatik”, 1993, pages 157 ff., the term database system, or database for short, refers to a system used to describe, store and retrieve large quantities of data that can be used by several application programs. The database system consists of a database in which data can be stored, as well as management programs which can store, process, evaluate and retrieve the data according to the specified descriptions.
According to Candace C. Fleming and Barbara von Halle on page 11 of their “Handbook of Relational Data Base Design” published in 1989 by Addison-Wesley Publishing Company, the term data modeling refers to a process used to design correct, consistent and flexible databases that can be accessed by several users simultaneously using any database technologies.
The quality of a database depends mainly on the quality of its data modeling and the resulting logical and physical data structures. For this reason, effective data modeling has been an important development and research objective for many years.
In 1977, for instance, ANSI, the American National Standards Institute (ANSI/X3/SPARC Committee) developed a set of requirements for database systems. These requirements distinguish between the following three design stages for data modeling in a database system (Fleming, v. Halle, pages 18 ff.):
(1) External schema: A way of looking at the data, description of the data structure and the required editing and processing rules from the point of view of an user or programmer and with his/her requirements in mind (according to Thomas A. Bruce, “Designing Quality Databases with IDEF1X Information Models”, Dorset House Publishing, 1992, p. 532).
(2) Internal schema or physical model: An arrangement of the data in a physical model in accordance with the internal (physical) access logic of the database management system, e.g. in relational, sequential, hierarchical or otherwise structured database systems (Bruce, p. 543).
With existing data modeling solutions, a physical model describes objects or entities—which can be persons, items, places etc.—attributes (also known as properties or characteristics) of the objects and of the relationships of the objects to each other. All the information in a database, i.e. both the objects and their relationships, as well as the attributes of objects and/or relationships are represented by tables, e.g. in a relational database.
(3) Conceptual schema: An integrated view of the data required and processed in the overall business environment, regardless of its physical arrangement and storage (as represented in the physical model), and regardless of how it is viewed by users and/or programmers (as represented in the external schema) (Bruce, p. 529).
In the case of existing data modeling solutions, the data structures and the access and processing applications in the conceptual schema are derived from a concrete task within a project, e.g. creation of a merchandise management system. Concrete business activities and the anticipated data to be processed at implementation are used to identify or describe the objects to be processed (business rules).
In compliance with the requirements of the data modeling procedure, it is thus essential to develop at least the above-mentioned three different logical (external and conceptual schemata) or physical models when designing a database system.
This is described by Fleming and von Halle, pages 20 ff. In the internal schema, a separate table is defined for each important object (cf. pages 280 ff.). These objects are stored together with their most important attributes in tables of varying structure. This means that there are at least as many object tables as there are objects. This in turn means that object tables of varying structure are created on account of the different object attributes or different relationships between objects they contain. Each table has to have its specific input, access, modification and deletion algorithms.
An extension of business activity or the need to add data at a later date involves the modification or extension of all the data structure models. This always goes hand in hand with a redesign of the (physical and logical) database structure, i.e. with appropriate modeling and restructuring cost and effort. It also involves what is often an extremely complex and cost-intensive modification of the application programs by programming experts insofar as the external viewpoint and modified editing and processing rules are affected. Each small modification of the logical and physical data structure involves changing the access and processing algorithms.
The implementation times for subsequent modifications of this type do not in the least correspond with the necessary operative requirements as regards the availability of information.
The exchange of data between information systems of varying structure is only possible on the basis of the “lowest common denominator”, i.e. of the small amount of corresponding data, if at all, and only then if the data for describing similar objects, attributes and relationships is structured in a similar way.
Prior art allows storage of only those attributes whose meaning—defined by the appropriate field (=column) in the appropriate object table—is pre-specified. The attributes have fixed links to certain object types, as the attributes are only stored for a specific object type in the fields (columns) of the table. The data to be stored later has to be provided for and implemented in full as early as at the data structure creation stage. Information contents with changing or unpredictable data structures either cannot be supported at all, or only in a rudimentary fashion.
Relationships between objects are not much different: They can only be linked with each other if the relationships between the objects were defined when the database structure was created.
Prior art allows for attributes with fixed links to certain relationships, as the attributes can only be stored for a certain relationship in the fields (columns) of the table.
Different processing rules for objects—the result of organizational, dp or security requirements—are applied to each individual object table or relationship table. This means that the cost and effort involved in implementing these rules and monitoring their correct functionality increases at least at the same pace as the number of tables.
Prior art allows for the development of information systems or data structure models and the resulting dp applications for the entry, storage, processing, evaluation and output of information to be defined and resolved in a highly task-oriented manner. This goes back to the prevailing school of thought on database design, as described e.g. in the manual by Fleming and von Halle, as well as to the requirements profiles (invitation to tender software, specification sheets) of information system operators.
However, information systems structured in such a specific way lead to high expenditure on development, redesign, programming, maintenance and support.
In contrast to the above, the objective of the invention is to create an information system, a process for storing data and a data structure which avoid the disadvantages of prior art and enable extensions to be made to the information system or database as required, even at a later date.
Another objective of the invention is to allow the stored data to be combined as far as possible.
A further objecti

Affiliated with

Also associated with

Rating

Information system and process for storing data therein does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Information system and process for storing data therein, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Information system and process for storing data therein will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2515706