Abstract: A method for providing stand-in objects, where relationships among objects are automatically resolved in an object oriented relational database model without the necessity of retrieving data from the database until it is needed. A “fault” class is defined, as well as fault objects whose data haven't yet been fetched from the database. An object that's created for the destination of a relationship whenever an object that includes the relationship is fetched from the database. When an object is fetched that has relationships, fault objects are created to “stand-in” for the destination objects of those relationships. Fault objects transform themselves into the actual enterprise objects—and fetch their data—the first time they're accessed. Subsequently, messages sent to the target objects are responded to by the objects themselves.

Abstract: A method for providing stand-in objects, where relationships among objects are automatically resolved in an object oriented relational database model without the necessity of retrieving data from the database until it is needed. A “fault” class is defined, as well as fault objects whose data haven't yet been fetched from the database. An object that's created for the destination of a relationship whenever an object that includes the relationship is fetched from the database. When an object is fetched that has relationships, fault objects are created to “stand-in” for the destination objects of those relationships. Fault objects transform themselves into the actual enterprise objects—and fetch their data—the first time they're accessed. Subsequently, messages sent to the target objects are responded to by the objects themselves.

Abstract: A method for providing stand-in objects, where relationships among objects are automatically resolved in an object oriented relational database model without the necessity of retrieving data from the database until it is needed. A “fault” class is defined, as well as fault objects whose data haven't yet been fetched from the database. An object that's created for the destination of a relationship whenever an object that includes the relationship is fetched from the database. When an object is fetched that has relationships, fault objects are created to “stand-in” for the destination objects of those relationships. Fault objects transform themselves into the actual enterprise objects—and fetch their data—the first time they're accessed. Subsequently, messages sent to the target objects are responded to by the objects themselves.

Abstract: The present invention comprises a method for allowing a controlling object to interface with any number of user interface objects without requiring separate interface code for each user interface object and without restricting the user interface to certain predetermined designs. The present method provides objects called association objects that are interposed between a controlling object and each user interface object. Each kind of user interface object has a corresponding association object. The association object for a particular kind of user interface object contains code that allows the association object to interact with the specific kind of user interface object with which it is associated. Each association object also presents a standard interface to a controlling object, regardless of the kind of user interface object with which the association object is associated.

Abstract: The present invention creates a model that maps object classes in an object-oriented environment to a data source. The model maps the relationship between properties of each object class and data of the data source. The present invention can be used with a data source such as a relational database, user interface, file system, or object-oriented database. An application's object classes and data source schema are designed independent of the other since the model can be used to map one to the other. The model is comprised of entities and attributes. An entity maps to an object class and to at least one table of the DBMS. An entity contains attributes either simple or derived. A simple attribute maps to a DBMS column. A derived attribute is a combination of other attributes and does not directly map to a DBMS column. A relationship creates a link between entities of the model. A relationship can be used to flatten an attribute or flatten a relationship.

Abstract: The present invention provides a uniform method for dynamically determining an object's communication requirements. The invention provides the ability to determine the requirements for communicating with an object regardless of the object's implementation (i.e., whether keys were implemented as methods or instance variables). The invention is used in conjunction with the runtime description of an object to provide a technique for communicating with an object. The present invention uses "key-value coding" to represent data. Key-value coding uses a dictionary of key-value pairs to represent a property and a value of the property. For example, a data value, "Joe" stored in a column of a database table that contains employees' first names is represented in a key-value pair as: Key="firstName", Value="Joe". The property of the key in this key-value pair is "firstName". The method for loading data into an object is "takeValuesFromDictionary".

Abstract: The present invention creates a model that maps object classes in an object-oriented environment to a data source. The model maps the relationship between properties of each object class and data of the data source. The present invention can be used with a data source such as a relational database, user interface, file system, or object-oriented database. An application's object classes and data source schema are designed independent of the other since the model can be used to map one to the other. The model is comprised of entities and attributes. An entity maps to an object class and to at least one table of the DBMS. An entity contains attributes either simple or derived. A simple attribute maps to a DBMS column. A derived attribute is a combination of other attributes and does not directly map to a DBMS column. A relationship creates a link between entities of the model. A relationship can be used to flatten an attribute or flatten a relationship.