GB2377044A - Data retrieval system and method for retrieving data - Google Patents
Data retrieval system and method for retrieving data Download PDFInfo
- Publication number
- GB2377044A GB2377044A GB0115889A GB0115889A GB2377044A GB 2377044 A GB2377044 A GB 2377044A GB 0115889 A GB0115889 A GB 0115889A GB 0115889 A GB0115889 A GB 0115889A GB 2377044 A GB2377044 A GB 2377044A
- Authority
- GB
- United Kingdom
- Prior art keywords
- data
- memories
- retrieval system
- version
- components
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computational Linguistics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A data retrieval system for use with a plurality of data memories and a method of retrieving data from the plurality of memories, the memories storing a plurality of data files, with each data memory storing no more than one version of each data file, the system and method storing in a memory an ordered list of the data memories available for access, and searching the data memories for a selected data file consecutively according to the stored ordered list and selecting the first found version of the selected data file. Each data file may have a respective identification key stored in association with it, the key remaining unchanged should the file be modified.
Description
<Desc/Clms Page number 1>
DATA RETRIEVAL SYSTEM AND METHOD RETRIEVING DATA
The present invention relates to a data retrieval system and a method of retrieving data, in particular where a plurality of data memories or repositories store data files, each storing no more than one version of each data file.
Previously, various systems have existed in which data files are modified so as to provide different versions of the same basic data file. The modified versions can be stored together, but, in this case, it is necessary to provide new versions with different names so that they are uniquely identified.
The present application is based on a recognition that, when a user modifies a data file to provide a new version, the old version is not of immediate interest, even though it may be desirable to retain it stored in memory.
Thus, it is proposed that new versions of a data file are stored in a different memory to the previous version.
According to the present invention, there is provided a data retrieval system a data retrieval system for use with a plurality of data memories for storing a plurality of data files, each data memory storing no more than one version of each data file, the data retrieval system including: a memory for storing an ordered list of the data memories available for access; and selection means for searching the data memories for a selected data file consecutively according to the stored ordered list and selecting the first found version of the selected data file.
According to the present invention, there is also provided a method of retrieving data a method of retrieving data from a plurality of data memories for storing a plurality of data files, each data memory storing no more than one version of each data file, the method comprising: storing in a memory an ordered list of the data memories available for access; selecting a data file; searching the data memories consecutively according to the stored ordered list and selecting the first found version of the selected data file.
<Desc/Clms Page number 2>
In this way, a user can arrange data files in memories according to particular needs. A master database of data files may be provided for general use while an individual user has a respective memory into which modified versions of data files may be stored. When the user then wishes to select a particular data file, it is not necessary to consider what versions exist. The retrieval system will automatically retrieve the modified version from the user's respective memory if it is present and, otherwise, select the unmodified version from the general memory.
Of course, any number of memories could be used. In other words, any number of users may have their own memories in which to store the modified versions which they require. Indeed, each user may have a plurality of memories, each storing modified versions for different uses, such as different projects.
Furthermore, it will be appreciated that reference to a plurality of memories is intended to cover divisions of a single memory. In other words, the memories need not be different physical units, but can be provided as different addressed areas of the same data storage unit.
Preferably, each data file has a respective identification key and the data memories store the appropriate respective identification key in associate with each version of each data file.
In this way, new versions of a data file may be stored with different names.
In particular, irrespective of the names of the different versions of the data files, the data retrieval system will be able to identify all the versions of a particular data file.
Preferably, the system further includes an editor for retrieving a data file from one of the plurality of data memories, modifying the retrieved data file and storing the modified data file in another of the plurality of data memories, the modified data file having the same identification key as the retrieved data file.
In this way, the user is also able to prepare the different versions of the data files.
Preferably, the data files include complete files of data and pointers to complete files of data.
In this way, it is possible to store in a data memory towards the top of the ordered list a pointer to a data file in a data memory lower down the list. Thus, when
<Desc/Clms Page number 3>
the data memories are searched for a data file, identification of the pointer will cause the selection means to select the version of that data file from the data memory further down the list.
Preferably, the data memories include a master data memory and a user data memory such that, with the user data memory ordered first and the master data memory ordered second, the selection means selects the version of the selected data file from the user data memory if it exists or the version of the selected data file from the master data memory otherwise.
The data retrieval system may be provided with a user interface.
Preferably, the user interface includes an input with which to specify the data memories available for access and the order of memories in the list.
In this way, a user can specify in which memories the preferred versions of the data files are located.
An input may be provided by which a user may select a data file.
Similarly, the data memories may include at least one local data memory such that, with the user, local and master data memories ordered in that order, the selection means selects the version of the selected data file found first when searching the user, then local and then master data memories.
A plurality of user interfaces may be provided, each with a memory for storing a respective ordered list of the data memories.
In this way, each user interface provides what will be described as a view. In particular, even if different views show the same data file, the actual version of the data file identified will differ according to the particular ordered list stored for that view.
Preferably, the user interface includes means for creating a plurality of data memories for storing a plurality of data files, each data memory storing no more than one version of each data file.
In this way, the user interface is able to set up data memories according to requirements.
<Desc/Clms Page number 4>
Preferably the data retrieval system includes a plurality of data memories for storing a plurality of data files, each data memory storing no more than one version of each data file.
In a preferred embodiment, the data files are components for use in building an image as part of an object oriented operating system.
This is a particularly useful application of the invention, since a software developer will normally wish to select a particular component and it would be desirable to enable this without concern for the particular version. By use of the present invention, where a new version has been developed by the developer or his/her team of developers, the system will automatically choose the version of the component according to the predefined list. Hence, normally, it would select the developer's own version if possible and the development team's version or the original version if not possible.
Thus, the data memories may be repositories for the components.
Similarly, the identification keys may be attributes stored in association with the components.
Preferably, the system includes a configuration manager for use in forming an image from a plurality of components including objects and metaspaces, the configuration manager including: a selector for selecting components from a database for use in the image; an analyser for analysing selected components to determine what other components are required by said selected components; and means for ensuring that all components required by the selected components are themselves selected.
The system may further include a compiler for compiling all of the selected components together to form the image.
In this way, the configuration manager automatically determines whether or not all of the necessary components have been selected to form the image. If not, it can refer to the additionally required components by means of the selection means searching the data memories.
<Desc/Clms Page number 5>
According to the present invention, there is also provided a computer readable storage medium having recorded thereon code components that, when loaded on a computer and executed, will cause that computer to operate as defined above.
The invention will be more clearly understood from the following description given by way of example only, with reference to the accompany drawings, in which:
Figure 1 illustrates a configuration manager display ;
Figure 2 illustrates an attributed entity diagram;
Figure 3 illustrates a local view accessing local and master repositories;
Figure 4 illustrates a hierarchal viewing of repositories ;
Figure 5 illustrates an attributed entity view diagram;
Figure 6 illustrates the four layer structure of a configuration manager;
Figure 7 illustrates an example of a definition change; and
Figure 8 illustrates a version dependant read function.
The invention will be described with reference to an embodiment in which the data files are components for use in an object oriented program wherein a developer will wish to select a particular component. However, as indicated above, the present invention is applicable to data files of any kind. For example, a company may store a master database of standard letters, but departments and individuals themselves may store modified versions of those standards. In this embodiment of the present invention, selection of a particular type, i. e. sort or variety, of standard letter would result in selection of an individual's modified standard letter or, if not available, the department's standard letter or, if not available, the company's standard letter.
Considering the preferred embodiment, applications that run on object oriented systems consist of carefully assembled collections of active objects. It is proposed that these objects should co-exist with the objects required by the operating system in a binary file called an image.
Such images may be run on computers, but will often be required by electronic devices or embedded devices which run the application. In these cases, the image has to be created in its entirety before being loaded onto the device. Since, in
<Desc/Clms Page number 6>
most cases, the image cannot be altered, it is important that it is correctly configured before it is loaded.
To create an image, it is proposed to provide a configuration manager which allows developers to easily define, configure and manage objects in images.
Several kinds of object can exist. Furthermore, it is proposed to provide two kinds of object groupings, namely collections of objects that provide operating system services to application objects to be called metaspaces and collections of
semantically related objects to be called packages. These objects and groupings are z : l known as components of an image.
The configuration manager may be provided with a display 2 as illustrated in Figure 1.
The illustrated display is divided into three views 4,6 and 8 representing respectively a master database, a local database and a project image. It is not necessary to provide more than the master database view 4 and the project image view 8, but, on the other hand, a number of different local database views could be provided.
The master database view 4 provides a representation of all of the components available from a master database to which the configuration manager has access. This master database should include all of the basic components of the object orientated operating system for which an image is being constructed. However, it may also include many other components which have been written and which have become available for general use. In order to construct an image, a user merely selects required components from the master database. In order to do this, in one embodiment, a user could merely drag the representation of a component in the master database view 4 across into the project image view 8. All of the selected components are then illustrated in the project image display 8.
Of course, since the configuration manager has selected one of the components already stored in the master database, it is not necessary for the data of that component to be duplicated in a portion of the memory allocated to the project image. Thus, the configuration manager can record that component by way of a
<Desc/Clms Page number 7>
reference to the appropriate component even though the project view 8 shows the component in question.
Of course, custom components can also be written for the application and these can be recorded as part of the project image or a local database.
The master database can be used as a read-only database and contain components that are shared by a development team. In a preferred embodiment, special administrator rights would be required to replace or add components to the master database.
On the other hand, the local database could be used to store an individual's own components or components which are original components from-the master database that have been modified. Of course, this database could also be shared with other developers.
Thus, where a custom component or a component of the master database that has been modified is selected for the project image or the local database, that component is stored in the memory for the project image or the local database.
Otherwise, where the component of the project image is merely a component from the local database or the master database, the configuration manager need only keep the reference to the appropriate component in the master database.
Preferably, each component in the image has properties that are configurable such as PIC/PID, stack and heap size, scheduling priorities and so on. The developer can create custom properties and change variables for each component. Preferably, the properties of the target platform can also be specified.
Thus, each component of the image preferably has configurable properties, for instance the metaspace on which an object runs or the memory areas where its code and data are to be loaded. The properties that characterize different kinds of components can change, as well as the default values of these properties. Indeed, due to changing requirements, the type of property may also be changed, for instance from an integer value to a string value.
The properties could be modelled using class data members. However, modification of the set of data members or the data members themselves (for example their default values) would then require recompilation depending on the
<Desc/Clms Page number 8>
implementation language. This is the case for C++. It is here recognised that such changes should not require recompilation of the configuration manager and that this requirement should apply to the properties of all components in an image, including packages and metaspaces.
In view of the above, it is now proposed that each component has associated with it a plurality of attributes for modelling the properties of that component.
It is proposed that properties should be modelled with typed attributes, that is, with pairs of classes; classes that implement named types and classes that implement variables corresponding to the type. Both the type and value classes derive
respectively from an MTpc and Attribute Value base class. The attribute value class, as the name suggests represents the value of the property. The type class encapsulates type-information about the property (for example, the default value) and type specific constraints (for example, a maximum value for an integer).
Referring to Figure 2, image components are modelled by derivation from the AttributedEntity base class 10 because the properties (typed attributes) must be allowed to change. This base class is, in essence, a polymorphic container of instances of Attribute Value-derived classes 12. The attribute types for each
component type are grouped together in an instance of the AttributedEntityTypeInfo class 14. This class, similar to the AttributedEntity class 10, maintains a list of polymorphic pointers to AttributeType-derived class instances 16, and can be considered as the metadata of the associated component type.
Some of the attributes allow the configuration manager to analyse the components and to determine what other components are required by them. In particular, the attributes of a component will indicate other components required by that component. Thus, for example, where an object requires a particular metaspace from the operating system, this will be indicated by way of the attributes.
Other attributes may be provided for other purposes such as influencing how the image is built, how the image will behave at run time, etc.
The configuration manager can then ensure that all of those components have been selected, either by prompting the user to select them or by automatically selecting them. The additional components having been selected in this way are then
<Desc/Clms Page number 9>
of course themselves checked such that any components required by them are also selected.
It will be appreciated that, with an arrangement as discussed above, it is possible for a number of users to share the master database and each modify components in different ways according to their needs. To allow collaboration and sharing of components between developers, it is proposed that repositories should be available to permit concurrent access to predefined components. It is proposed that users can modify properties of these components as discussed above without effecting the work of others.
In order to do this, the master, local and project databases discussed above for the configuration manager can be generalised to a plurality of memories such as a master repository, a local repository and a project repository. The master repository is read-only and can be shared by multiple users. The two other repositories are writable. The local repository stores modified versions of items in the master repository as well as new items. It can be shared by different users and projects.
For the configuration manager, the project repository stores modified components that are only relevant to the current project as well as settings necessary to build the image (for example the interrupt handling policy).
In order to identify versions of a particular component, each version of each component is stored in a repository based on a unique key. Modified versions of a component always have the same key as the original, but are stored in a different repository. For example, when a component in the master database/repository is modified, the modified version is stored in the local or project repository using the same key. This is illustrated in Figure 3. In particular, the original component A, having key X, is stored in the master repository with reference to key Z. However, this component has been modified to include a reference to key Y and has been stored in the local repository, but still with key X. The local view of the configuration manager requiring a component with key X takes that component from the local repository. Since that component requires reference to key Y, the configuration manager therefore looks for a component having key Y. Since the local repository does not contain such a component, the local view refers to
<Desc/Clms Page number 10>
component B of the master repository. Thus, it will be seen that a component refers to another component by specifying the key of the referred component. This means that it is not possible for a component to refer to a certain version of another component explicitly. Version is determined by the context in which the reference is evaluated. Browsing the master repository using a master view displays the version that is stored in the master repository, but browsing the local view displays, in order of precedence, the version stored in the local repository or, if this does not exist, the version stored in the master repository.
Thus, as illustrated in Figure 4, this process of evaluating a reference in a context is encapsulated in views. A view is responsible for selecting a-certain version of a component, based on a key or other form of ID. It specifically uses one or more repositories using some order of precedence or hierarchy between those repositories to arrive at the correct version.
Thus, the project view 20 of Figure 4 would first look for a version of a data file in the project repository 26, then the local repository 28 and finally the master repository 30. On the other hand, the local view 22 would look for a version of a data file first in the local repository 28 and then the master repository 30. The master view 24 would merely look in the master repository 30. Of course, the particular hierarchy assigned to the repositories can be different for each view. Thus, another project view might assign a hierarchy with the local repository as first choice, its own project repository as second choice, another project repository as third choice and the master repository as last choice.
This system is applicable to any arrangement in which different versions of the same data file are stored in different repositories. As indicated previously, for the configuration manager discussed above, the graphical user interface (GUI) uses three repositories and three views. There is a view to browse the master database, a view to browse the local database and a view to browse the project repository. Of course, the project view is more complicated, since it also has to take into account the project's image composition which allows the user to explicitly select a certain version of a component to be included in the image.
<Desc/Clms Page number 11>
Component versions are modelled by the configuration manager as instances of the n & My class. This is illustrated in Figure 5.
Repositories are instances of the AttributedEntitySpace class, which is a container for AttributedEntities. Finally, the view is an instance of an AttributedEntity View-derived class, implemented the specific mechanism to resolve references.
The configuration manager is preferably implemented as a four layer structure as shown in Figure 6. In particular, it has 1) a thin persistence layer, 2) a common code base of platform-independent core classes 3) a layer of platform-independent ACM-specific classes and 4) a platform-specific graphical user interface (GUI) layer.
The persistence layer can be used to particular advantage with the configuration manager.
Persistence refers to an object's ability to transcend time or space. A persistent object saves its state in a permanent storage system to make it possible for the process that created the object to terminate, without losing the information represented by the object. Later, the object may be reconstructed by another process and will behave in exactly the same way as it did in the initial process. However, the mere ability to make objects persistent is not sufficient to implement robust persistence, namely persistence that is resilient to changes in the definitions of the persistent classes. Such changes may for instances be required to accommodate design improvements. Components may be designed which are intended for use with the components of a particular master database but will not operate with the components of an earlier equivalent master database.
Changes may give rise to sychronisation problems, for instance class definitions compiled into the program may differ from definitions used by the data files. The result of this is that files in which instances of previous versions of the persistent classes are stored can no longer be read.
In order to overcome this, the configuration manager determines the version of the components of the master database and operates accordingly. Where the version is older than that currently in use, it preferably takes the necessary steps to convert the components. It may also issue some warning to the user. On the other
<Desc/Clms Page number 12>
hand, when the components of the master database are from a more recent version than that currently in use, the configuration manager may merely have to issue a warning to the user and prevent use of those components.
Considering a more specific example of the operation, write and read functions write and read a persistent class's data members, both static and non-static to and from an input/output stream. This approach, however, may cause problems when class definitions are changed as illustrated in Figure 7, which shows two versions of a class A.
The pseudo-code shows two class definitions with corresponding read and write functions for the persistence. The instance of class A, written with the first implementation, cannot be read with the second implementation. In particular, the second implementation will try to read a float, but will encounter an integer.
To overcome this, it is proposed that version information is written out together with the persistent classes. This version information relates to the version of the implementation that was used to write the class.
Each persistent class contains a different read function for each (past) version that must still be supported by the robust persistence mechanism. Each read function reads the values of the corresponding old implementation and coverts them to the values needed by the current implementation. Applied to the example of class A, this results in the pseudo-code illustrated in Figure 8.
When an instance is read, the read function that is used to read the instance is selected from the version information found in the stream. When an instance is read to a stream, it is always written with the current (and latest) implementation so that the write method is not version-based.
Thus, the configuration manager may provide a framework that enables classes to register read functions on a version basis and that is able to select the correct read function, based on the version information found in the stream. The implementation of this framework is centred around three classes. The Persistence Versionlnfo class encapsulates the version information, such as major and minor version number and status such as alpha, beta or release.
<Desc/Clms Page number 13>
The association between the different versions and their corresponding read functions is then managed by the Persistence ClassIOManager. The core of the
robust persistence is the PersistenceManager class, that maintains a PersistenceClass/OManager class for each persistent class.
Considering again the four layer structure illustrated in Figure 6, the persistence layer is thus provided in the first layer.
The second layer comprises the core classes. The common code base consists of a polymorphic hierarchy of attribute type and value classes, classes that model domain class metadata (i. e. type descriptions), a base class that maintains a set of attribute values, the main classes that derive from this class and enable the properties of components to be changed as discussed above, classes that help manage the object repositories, classes that provide an infrastructure for allowing different views of objects in the repositories so as to allow collaboration between different object repositories as discussed above and helper classes.
The first and second layers comprising the common code base and persistent layer together make up the backend of the configuration manager.
The third layer containing the configuration manager specific classes implement the configuration managers logic as discussed above. In particular, the configuration manager determines which components are required by selected components and takes appropriate action.
As discussed above, to function properly some components of an image may require the presence of other components. For example when a developer adds an application object that runs on a particular metaspace, that metaspace and all the objects that comprise it are required.
Preferably, these relationships are modelled by means of a dependencies property defined for different sub classes of the attributed entity bases class to be described below. Dependencies are described as the list of objects, packages and metaspaces that a component requires. The logic layer provides the necessary functionalities to analyse these dependencies and to add any missing component to the image. The components that make up the basic operating system have their dependencies pre configured in the master repository. However, application
<Desc/Clms Page number 14>
developers may also specify dependencies through the graphical user interface (GUI).
Finally, the fourth layer comprises the graphical user interface (GUI) and concerns itself with presentation and input verification using APIs provided by the layers two and three.
Claims (21)
1. A data retrieval system for use with a plurality of data memories for storing a plurality of data files, each data memory storing no more than one version of each data file, the data retrieval system including: a memory for storing an ordered list of the data memories available for access; and selection means for searching the data memories for a selected data file consecutively according to the stored ordered list and selecting the first found version of the selected data file.
2. A data retrieval system according to claim 1 wherein each data file has a respective identification key and the data memories store the appropriate respective identification key in association with each version of each data file.
3. A data retrieval system according to claim 1 or 2 further including: an editor for retrieving a data file from one of the plurality of data memories, modifying the retrieved data file and storing the modified data file in another of the plurality of data memories, the modified data file having the same identification key as the retrieved data file.
4. A data retrieval system according to claim 1,2 or 3 wherein the data files include complete files of data and pointers to complete files of data.
5. A data retrieval system according to any preceding claim wherein the data memories include a master data memory and a user data memory such that, with the user data memory ordered first and the master data memory ordered second, the selection means selects the version of the selected data file from the user data memory if it exists or the version of the selected data file from the master data memory otherwise.
<Desc/Clms Page number 16>
6. A data retrieval system according to claim 5 wherein the data memories include at least one local data memory such that, with the user, local and master data memories ordered in that order, the selection means selects the version of the selected data file found first when searching the user, then local and then master data memories.
7. A data retrieval system according to any preceding claim including a user interface which includes the memory and selection means.
8. A data retrieval system according to claim 7 wherein the user interface includes an input by which a user may select a data file.
9. A data retrieval system according to claim 7 or 8 wherein the user interface includes : an input with which to specify the data memories available for access and the order of the memories in the list.
10. A data retrieval system according to any preceding claim including: a plurality of user interfaces, each with a memory for storing a respective ordered list of the data memories.
11. A data retrieval system according to any preceding claim wherein the user interface includes: means for creating a plurality of data memories for storing a plurality of data files, each data memory storing no more than one version of each data file.
12. A data retrieval system according to any preceding claim further comprising : a plurality of data memories for storing a plurality of data files, each data memory storing no more than one version of each data file.
<Desc/Clms Page number 17>
13. A data retrieval system according to any preceding claim wherein the data files are components for use in building an image as part of an object oriented operating system.
14. A data retrieval system according claim 13 wherein the data memories are repositories for the components.
15. A data retrieval system according to claim 13 or 14 when appendant on claim 3 wherein the identification keys are attributes stored in association with the components.
16. A data retrieval system according to claim 13, 14 or 15 including a configuration manager for use in forming an image from a plurality of components including objects and metaspaces, the configuration manager including : a selector for selecting components from a database for use in the image ; an analyser for analysing selected components to determine what other components are required by said selected components ; means for ensuring that all components required by the selected components are themselves selected ; and the user interface.
17. A data retrieval system according to claim 16 further including : a compiler for compiling all of the selected components together to form the image.
18. A method of retrieving data from a plurality of data memories for storing a plurality of data files, each data memory storing no more than one version of each data file, the method comprising : storing in a memory an ordered list of the data memories available for access ; selecting a data file ;
<Desc/Clms Page number 18>
searching the data memories consecutively according to the stored ordered list and selecting the first found version of the selected data file.
19. A data retrieval system constructed and arranged substantially as hereinbefore described with reference to and as illustrated by Figures 1 to 8 of the
accompanying drawings. t
20. A method of retrieving data substantially as hereinbefore described with reference to and as illustrated by Figures 1 to 8 of the accompanying drawings.
21. A computer readable storage medium having recorded thereon code components that, when loaded on a computer and executed, will cause that computer to operate according to any preceding claim.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB0115889A GB2377044A (en) | 2001-06-28 | 2001-06-28 | Data retrieval system and method for retrieving data |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB0115889A GB2377044A (en) | 2001-06-28 | 2001-06-28 | Data retrieval system and method for retrieving data |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| GB0115889D0 GB0115889D0 (en) | 2001-08-22 |
| GB2377044A true GB2377044A (en) | 2002-12-31 |
Family
ID=9917578
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| GB0115889A Withdrawn GB2377044A (en) | 2001-06-28 | 2001-06-28 | Data retrieval system and method for retrieving data |
Country Status (1)
| Country | Link |
|---|---|
| GB (1) | GB2377044A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7720904B2 (en) * | 2005-05-27 | 2010-05-18 | Microsoft Corporation | Entity projection |
-
2001
- 2001-06-28 GB GB0115889A patent/GB2377044A/en not_active Withdrawn
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7720904B2 (en) * | 2005-05-27 | 2010-05-18 | Microsoft Corporation | Entity projection |
Also Published As
| Publication number | Publication date |
|---|---|
| GB0115889D0 (en) | 2001-08-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7752597B2 (en) | Layered software development and implementation using files | |
| KR100359670B1 (en) | Method and system for organizing internal structure of file | |
| US6446253B1 (en) | Mechanism for achieving transparent network computing | |
| US6098072A (en) | Source code files in a file directory system having multiple hierarchies representing contextual views | |
| US6154748A (en) | Method for visually mapping data between different record formats | |
| JP4197753B2 (en) | Method and system for uniformly accessing multiple directory services | |
| JP4365142B2 (en) | Computer-readable medium, system, and method for associating properties with objects | |
| US7043481B2 (en) | System, method and software for creating, maintaining, navigating or manipulating complex data objects and their data relationships | |
| US5978582A (en) | Method and system for implementing software objects | |
| US6317749B1 (en) | Method and apparatus for providing relationship objects and various features to relationship and other objects | |
| JP2005532637A (en) | Method and system for extending file system APIs | |
| LaLonde | Designing families of data types using exemplars | |
| US7937686B2 (en) | Name-based identifiers of model elements | |
| EP3543843B1 (en) | System and method of rolling upgrades of data traits | |
| US7685155B2 (en) | System and method of providing and utilizing an object schema to facilitate mapping between disparate domains | |
| Batra | SQL primer | |
| US7212212B2 (en) | Context attribute determination | |
| US20070083546A1 (en) | Information management system and information display device | |
| US20080082535A1 (en) | Method and system for automatically generating a communication interface | |
| GB2377045A (en) | Configuration manager | |
| US7827525B1 (en) | Data object utilization in software applications | |
| GB2377044A (en) | Data retrieval system and method for retrieving data | |
| US20070198576A1 (en) | Stateless-object software environment | |
| JPH05313969A (en) | File list display method | |
| EP2354924B1 (en) | Method for persisting software objects |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| WAP | Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1) |