[AccessD] Database Patent

Drew Wutka DWUTKA at Marlow.com
Fri Sep 7 08:54:17 CDT 2007


They aren't truly modifying the design of the database, the database is
designed to allow for modification of the data layout (without changing
the database design).  Not only does that prevent having to modify a
live database, it prevents the need for future development.

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin
at Beach Access Software
Sent: Friday, September 07, 2007 8:04 AM
To: 'Access Developers discussion and problem solving'
Cc: 'Jack Stone'
Subject: Re: [AccessD] Database Patent

Drew:

On the Marlow database, can they modify that database without having to
take
it down?  It's an on-the-fly modification?

TIA

Rocky
 




 	
	

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka
Sent: Thursday, September 06, 2007 10:10 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Database Patent

The beginning of the patent that you are talking about is discussing the
problems of a system where you can't change the design of the tables
while
using the database.  I built a system that got around that limitation.
It's
a 'data entry' system.  We have several computers that record
information
from test equipment.  An example would be our CMM machines.  These
machines
measure things, optically.  It's pretty slick, it uses a black and white
camera that can tell you the height, width and depth of something, based
on
lines and grayscale equations.  We make thermal electric coolers, so to
inspect them, either someone is looking under a microscope and measuring
things, or we can have the CMM inspect stuff, and report the
measurements.

With the first CMM, the guy working with it wanted to record the data
into a
database.  He had two or three 'programs' that recorded their own
distinct
set of data.  I wrote a custom database, with custom .dll's to record
the
data into the database.  So his code (the CMM's have something called
QBasic, which is a modified version of VBScript), would look like this:

MyDll.CeramicWidth=SomeCodeToReferencetheCMMObjectModel
MyDll.RecordData 'puts the set properties into a matching table in the
database.

About 2 years later, we bought another CMM.  This time, however, they
were
planning on having lots of different 'programs', and were expecting more
every time.  With the original system, it's been in use for 4 or 5
years,
and I've never had to add or modify to the original system I built for
that
one.  But now I was faced with a system where the data they wanted to
record
could require new fields, with new data types, descriptions, etc, on a
frequent database.

The patent is discussing this situation, because it is talking about
having
to take a database 'down' to make these modifications.  

What I built was the CMM Data Acquisition program.  The database had a
few
'solid' tables, such as Batches, and Items.  Items for the CMM would be
the
individual coolers that are inspected, and batches would be a group of
items
inspected at the same time.

Then there was the Program table.  It stores the details specific to
each
program. It's name, group, etc.  Then the program field table.
This table determined the field type, the description, the units, etc.
Then there was a table for each data type.  That table housed the value,
the
Item ID, and Field ID (The item table listed the program ID).  So for
every
value that was entered, two indexed long integers were recorded for each
value (be it text, currency, long, double, or date).

There is a person that develops the QBasic code for each 'inspection'
program.  Instead of having to add or modify a table in the database,
the
database structure allows them to create a new 'program table' by
creating
definitions in the tables, and utilizing the multiple 'data'
tables to store the same type of data, identified by item and field
id's.
So each program could be a different 'database design', when in reality,
it's the same database just configured to handle an infinite variety of
variable 'tables'.  As an FYI, the goal was to use this database to
record
ALL test machine data, but I have never had time to go back and finish
this
system. It records the data without a glitch (in fact, to test it, I
built
in place an artificial data entry process, that just ran random
number/data
through batches.  Let it run continuously overnight, and had the
database at
around 500 megs.  Did some report tests, and the data reports I had ran
at
the same speed in the relatively empty database as it did in the system
with
several hundreds of thousands of batch runs (thus millions of items).  I
have basic batch reports, but the goal was to create a dynamic reporting
engine, to let a user 'create' a report based on any 'field' (defined by
the
Program fields table), but just haven't gotten to it.

This was not the first time I used such a structure either.  Our company
website (www.marlow.com) uses an almost identical process for the
products.
If you look the products on our web page, you'll see that the same page
displays both cooler data, and data for other products like TTRSes,
accessories, etc.  This data is all stored in the same structure, not
separate tables designed for the specific products.
While a TEC (cooler) may have a Delta T attribute, a TTRS wouldn't.  Our
drafting department has 'control' of the product data, so they could add
any
type of product they want, from a TECs, to cars, to nuts and bolts, and
the
database never has to be redesigned to handle the different attributes
of
the item.

Make sense?  Not the exact same design of this patent, but the same
idea.

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin
at
Beach Access Software
Sent: Thursday, September 06, 2007 9:57 PM
To: 'Access Developers discussion and problem solving'
Cc: 'Jack Stone'
Subject: Re: [AccessD] Database Patent

This is an existing patent.  The patent  is date Feb. 21, 2007.  Does
your
work predate the patent?  Does it use this two-part scheme of the
records
data set and the categories data set?  Or is yours a different technique
which would duplicate one of the salient advantages of this patent which
is
the ability to alter the design of a database without interruption in
the
service?

Part of what I'm trying to find out here, is knowing if this is a more
or
less common or existing technique or is truly unique.  That would
determine
what value, if anything, the patent would have in a sale of the rights. 

How much of what you did can you share or want to share?

Rocky





 	
	

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka
Sent: Thursday, September 06, 2007 7:24 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Database Patent

Is this an existing patent, or one that is applying for a patent?  I
ask,
because I have actually built databases that pretty much use this
principle.

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin
at
Beach Access Software
Sent: Thursday, September 06, 2007 6:48 PM
To: 'Access Developers discussion and problem solving'
Subject: [AccessD] Database Patent

Dear List:
 
A client who is a patent and trademark attorney is interested in
opinions on
a patent - basically it's a way to update databases on-the-fly by
disconnecting the data from the data definition. 
 
You can download the patent by going to this web page: 

http://www.pat2pdf.org/
 

and entering the patent number 7003524.

I guess I'm looking for opinions on whether this is a solution to a
problem
that exists and whether there is something of value in this approach. 

I know there's some deep database design talent on this list so I'm
thinking
this is the best place to start the research.

Here's a teaser.  From the patent:

TECHNICAL FIELD

The invention relates generally to databases and, more particularly, to
the
underlying schematic structure of databases.

BACKGROUND

Large databases running in publicly accessible environments are
notorious
for their inability to accommodate change. In today's world of massive
access to large databases via the Internet, it is increasingly common to
encounter messages to the effect of "database is down for maintenance"
instead of the actual data requested.

In a conventional database environment, when a change needs to be made
to
the schematic structure of a database, the data in the database must be
extracted from the database in the old structure and re-written to the
database in the new structure. If new data were to be inserted into the
database while said changes were being effected, it could cause
unpredictable effects to the database. Such effects could include
corruption
of pre-existing data, misapplication of database changes, misalignment
of
data relative to internal data boundaries, or any number of problems
that
could render the database effectively incoherent. Such results are
untenable
in most live database deployments.

Conventionally, the most common solution to the problem of updating
during
changes to the schematic structure is to simply disallow it.

Conventional databases also require a tight bind between the data type
and
the data storage. Users require that the data they request be presented
in a
manner consistent with the expected usage of the data. For example, a
date
may be stored in the database as a string of decimal digits (e.g.,
20010303), but to present the data to the user in its raw form would be
unacceptable. A conventional computer user requires that it be presented
in
a manner consistent with its usage (e.g., Saturday, 3, Mar. 2001. In
order
for the date to be presented in a manner consistent with its usage, the
database must carry type-related information along with each unit of
data.

Binding between data and type is conventionally accomplished by
organizing
the data into metaphorical rows and columns. Rows of data are divided
into
pre-defined columns, where each column represents a particular data type
and/or use of the data. Such data/type binding allows a computer program
to
make assumptions and inferences about the data appropriate to its type.
Additional rows of data may be readily added to a database. However, if
a
new column is desired in a database, then the database must typically be
made unavailable for a period of time so that data can be converted into
the
new format. Modifications to pre-existing programs would have to be
made,
along with the requisite testing and debugging necessary to validate any
new
code.

It is also worth noting that in conventional databases there tends to be
redundancy in the storage of data. For example, cities, states, zip
codes,
and telephone area codes may be repeated among a number of rows of data.
Such redundancy results in inefficient use of memory.

In light of the foregoing, it is apparent that there is a need for a
system
and method for modifying the schematic structure of a database without
making the database unavailable for the entry of new data. Preferably,
such
a system and method would, among other things, also minimize redundancy
of
data in a database.

SUMMARY

The present invention, accordingly, provides a database in which an
application program accesses data stored in a records data set (RDS) and
a
categories data set (CDS). The RDS contains at least one RDS entry
having a
data field configured for representing data. The CDS contains at least
one
CDS entry configured for being associated with at least one RDS entry
and
having at least one data type field sufficient to describe the type of
data
contained by the at least one associated RDS entry.

The invention thus provides a database whereby data is isolated from its
definition, thus avoiding the problems associated with the
rows-and-columns
model enumerated above, and permits the underlying schematic form of the
database to be changed based on modifications to the CDS, without
requiring
any actual changes to the schematic structure of the RDS or the
underlying
database. By virtue of this same isolation it is also possible to reduce
data redundancy with varying levels of granularity and create an
object-oriented data model.


MTIA

Rocky

 	
	

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com The information contained in
this
transmission is intended only for the person or entity to which it is
addressed and may contain II-VI Proprietary and/or II-VI
BusinessSensitve
material. If you are not the intended recipient, please contact the
sender
immediately and destroy the material in its entirety, whether electronic
or
hard copy. You are notified that any review, retransmission, copying,
disclosure, dissemination, or other use of, or taking of any action in
reliance upon this information by persons or entities other than the
intended recipient is prohibited.


--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.485 / Virus Database: 269.13.8/993 - Release Date: 9/6/2007
3:18 PM
 

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com The information contained in
this
transmission is intended only for the person or entity to which it is
addressed and may contain II-VI Proprietary and/or II-VI
BusinessSensitve
material. If you are not the intended recipient, please contact the
sender
immediately and destroy the material in its entirety, whether electronic
or
hard copy. You are notified that any review, retransmission, copying,
disclosure, dissemination, or other use of, or taking of any action in
reliance upon this information by persons or entities other than the
intended recipient is prohibited.


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.485 / Virus Database: 269.13.8/993 - Release Date: 9/6/2007
3:18 PM
 

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited.





More information about the AccessD mailing list