The (then) Borland (today: Embarcadero) Delphi programming language & RAD development environment has been accessing databases with objects since at least 1995.
Delphi is both the name of an the "Object Pascal" programming language and a RAD Object Oriented Integrated Development Environment, which since it's first version provided objects for interacting with tables, queries and or views in a relational databases.
The original 1995 version Delphi 1.0 client/server based objects (TTable, TQuery, TDataset, TDatabase, TSession) serves as sufficient prior art to for the claims in question, however the "Midas" (now "Datasnap") multi-tier technology that was released around 1997 with the advent of Delphi 3.0 provides additional prior art should there be quibbles with the former.
In particular, I submit the following comments in response to the claims above:
- A method for enabling an object oriented user application to access a relational database having one or more physical tables segmented into rows and columns, comprising:
Generally Delphi's database components since version 1.0 has had this exact goal, of allowing an object oriented user application to access a relational database. In particular, the TTable (1 physical table or view) or TQuery (1 or more tables or views) are therefore 2 concrete classes providing access to an underlying relational database and therefore direct prior art.
defining a logical table comprising a subset of columns from at least
one of the one or more physical tables;
Both TQuery and TTable instances define logical tables for use in a Delphi application and so serve as prior art here as well.
designating one column of the
logical table as a logical primary key column;
First note that in general, keys need not be single column, so the claim here is oddly limiting for something that is supposed to be for general use and expanding the state of the art.
Nonetheless, Delphi supports several ways of defining both single and multi-part keys for its data access objects that serves as direct prior art here.
1) TField objects (which are contained in TQuery/TTable etc) support (at least) the TField.ProviderFlags property (e.g. property "pfInKey") which allows one to specify that a particular TField is a key field for the containing logical table object.
2) TTable components (amongst others) can additionally store both field and index definitions which imply whether a field is part of a logical primary key or not: TTable.IndexDefs for example contains a list of index definitions, each index definition has several properties, including the list of fields making up the index, and properties to specify various aspects of the index, including whether it defines a primary key (Index.Options include enumerated value ixPrimary)
3) Midas TClientDataset similarly is a completely logical dataset class that allows a user to define field, field properties (including key specification) as well as having an IndexDefs property that can define logical indexes and primary key, and which can be used to access data from a back-end relational database.
forming a normalized
relational schema object representing the logical table;
The term "relational schema" usually refers to a database schema, which usually includes multiple tables (or relations), so this statement referring to a singular "logical table" whilst simultaneously referring to a "normalized relational schema" seems on it's face confused and at best poorly worded.
Maybe the author meant "relation schema", where "relation" is a formal name for what we would otherwise call a table, and the "relation schema" is then informally the description of the structure of the table (rows, columns) and so on.
Either way, as mentioned before, any of the many TDataset descendant object included in Delphi, and in particular TTable, TQuery and TClientDataset serves as prior art as objects representing a logical table (relation) in a Delphi application.
For more on this apparent confusion of terminology, see:
responsive to the normalized relational schema object, one or more
object classes associated with the normalized relational schema
Part of the work done by the Delphi environment is to generate instances of TQuery, TTable, TClientDataset and so on, and to populate these objects with the attendant field definitions, index definitions, keys and so on, or to allow the developer to specify these manually by hand if so desired.
These objects form part of a so called datamodule object, which itself is an instance of the TDatamodule class. Delphi allows one to define relationships between various "TDataset" objects (TDataset being the ancestor of several of the classes previously mentioned and so being a collective term for any Delphi application "logical table"), thereby establishing relationships between the logical objects and thus effectively a relational schema.
The TDatamodule then is prior art for the "relational schema object", and whether it is normalized or not depends on the developer and how he/she designs the logical tables in question, but suffice it to say that a normalized form is supported if desired.
and employing an object of an object class including the one
or more object classes associated with the normalized relational
schema object and a respective corresponding logical primary key value
to access data in the at least one of the physical tables in the
As a concrete prior art example: A TClientdataset class instance named "cdsCustomer", housed with other TClientDatasets (say "cdsOrder" with a master-detail relationship with cdsCustomer) in a TDatamodule instance, with a suitably defined primary key field & index on the "CustomerId" logical field (together with suitable supporting Midas backend) will allow the Delphi application containing this clientdataset to retrieve data in a back-end relational database table called say "tblCustomers", locate a specific CustomerID in the logical table, modify values in the logical table (without at that point having any link with the back-end) and eventually sync the update back to the database.
In summary, this claim describes nothing more than what Delphi's object access classes have already been providing since at least 1995.
Delphi release dates:
Delphi Developers guide (c) 1995 Borland: