text: fig1 shows the preferred embodiment of the invention . the database adapter 100 is a general interface to the functionality provided by the multivariate data management module 102 . the database adapter 100 is customized to be portable to a variety of different dbmss running on a variety of different hardware platforms . the multivariate data management module 102 works in conjunction with a compression module 110 and a serialization module 112 to store serialized , compressed data 118 in a database . retrieval of data from the database uses a deserialization module 114 and a decompression module 116 to convert stored data 118 to the data &# 39 ; s original type . the multivariate data management module 102 also provides the following functionality : creation of a new , empty multivariate dataset . addition of a column to a multivariate dataset . setting the numeric precision of a column . specification of a preferred compression scheme for a column . by default , the multivariate data management module 102 selects a compression scheme for a particular column of data based on the characteristics of the data . however , in order to optimize loading data , client applications may bypass the selection by specifying a compression scheme explicitly . addition of a row to a multivariate dataset . setting the value of a particular element in a multivariate dataset . getting the number of columns in a multivariated at a set . getting the name of a column in a multivariate dataset . getting the type of a column in a multivariate dataset . getting the numeric precision of a column in a multivariate dataset . getting the value of a particular element in a multivariate dataset . getting the extents of a named set of columns in the multivariate dataset for use as a multi - dimensional key . discarding all columns in a multivariate dataset except a named set ( classical projection ). discarding all rows in a multivariate dataset except those whose values fall in particular ranges ( classical selection ). conversion of a multivariate dataset to a compact byte stream . building a multivariate dataset from a compact byte stream . generation of a multi - dimensional index key representing the ranges of values in one or more columns of a chip . selection of particular rows of a chip based on range criteria . selection of particular columns of a chip based on a list of column names . retrieval of rows of a chip as a row type ( in databases that support returning row types ). insertion of the contents of a chip into a table . conversion of groups of rows of a table or view into chips . the database adapter 100 provides a general interface to the multivariate data management module 102 . however , in appropriate situations it is helpful to provide specialized modules customized for particular types of data . fig1 shows three examples of such modules 104 : ( 1 ) the statistical module provides the ability to perform statistical computations on multivariate data . ( 2 ) the gis module provides the ability to manipulate points , lines , polygons , and coverages that have been represented as multivariate data . it includes functions for spatial predicates and operations . ( 3 ) the raster module provides operations on raster images that have been stored as multivariate data . typically , the database adapter 100 is preferably used by either a general purpose dbms 106 or by a client program 108 . fig1 shows a general purpose dbms 106 making calls directly to the multivariate data management module 102 through the database adapter 100 . alternatively , a client program 108 can use the invention by making calls to the database adapter 100 , to specialized data modules 104 or directly to the multivariate data management module 102 . data is compressed by the compression module 110 . this module compresses each column within a chip individually , very often resulting in the use of different algorithms for different columns . after compression , the data is serialized by the serialization module 112 to produce a compact byte stream . the compact byte stream represents compressed data by means of descriptive tags and associated sequences of bytes . the compact byte stream is in a machine - independent format . the compression module 110 uses one set of routines to compress floating point values and a parallel set of routines to compress integer values . where the data are provided as floating point numbers , many schemes have difficulty producing any useful compression , due principally to the difficulty in accurately doing arithmetic and making comparisons between floating point values . where floating point values are used , a test is made to assess whether it is worthwhile to attempt compression . this test is true when : ( 1 ) the tolerance has been set to a positive value indicating that approximate values may be used ; or ( 2 ) the floating point values can be represented as the product of a set of integers with a single floating point value . for floating point values , the compression schemes can be lossy . only enough information is saved to be able to reconstruct floating point values to a specified level of precision ( tolerance ). the tolerance is specified as a parameter of each column and is an absolute value . for example , if temperatures stored as floating point values are only needed to be used with an accuracy of 2 decimal digits , the tolerance parameter would be specified as 0 . 01 . a zero value specified for the tolerance is taken to mean that the choice of compression schemes is limited to those that exactly preserve the original values . the compression module 110 has a suite of compression schemes and applies the one that results in the greatest space savings . in some cases , the output of one compression scheme results in a reduced set of values that can be compressed further with a subsequent scheme . the type of the compression chosen is expressed in the first four bytes of the compressed output so that the decompression module 116 knows which complementary methods to use for decompression . the logic of the compression of floating point values is shown generally as 200 in fig2 . the compression schemes employed are : a list of values is treated as an arithmetic sequence if it can be expressed in the form : where r is the first value , i is an index running from 1 to the number of values in the list and d is the difference . the check for whether the input array can be sufficiently accurately represented as an arithmetic sequence : ( a ) calculates the differences between successive pairs of values in the array ; and ( b ) performs a tolerant comparison ( equal to within half of the specified tolerance value ) of each calculated difference with the first of the differences so calculated . if the test is successful , the result is a descriptive tag and the values for r and d . a list of values is treated as an arithmetic cycle if it can be expressed as a repeating arithmetic sequence of the form : where r is the first value , i is an index running from 1 to the number of values in the list , p is an offset , q is the length of the cycle and d is the difference . the algorithm to determine if an arithmetic cycle is present is shown in fig4 . this first finds the minimum and maximum values in the input values , a , as well as the minimum distance between two consecutive values . from this , it infers the length of a repeating arithmetic sequence . an arithmetic cycle is stored with a descriptive tag and the values for p , q , r and d . if there is sufficient duplication in the list of values ( typically , if more than 50 % of the values in a list are duplicates of an adjacent value ), then a run - length encoding is used . the algorithm for run - length encoding is shown in fig5 . the result of the encoding is a descriptive tag and signed one byte integer counts followed by values . a byte count in the range − 128 to − 1 represents a run of unrepeated values of length 128 to 1 respectively . a byte count in the range 0 to 127 represents a run of repeated values of length 2 to 129 respectively . the run counts are stored separately from the run values so that the run values can be further compressed by another compression scheme . a list of values is treated as a repeating sequence if it can be expressed in the form : where s is a smaller set of values which repeat , q is the cycle length and i is an index running from 1 to the number of values in the list . the algorithm for values to be encoded as a repeated sequence is shown in fig6 . a repeating sequence is represented by a descriptive tag , the value for q and a smaller set of values s ( that may be further compressed ). for example , the list 9 , 6 , 4 , 9 , 6 , 4 , 9 , 6 , 4 , 9 can be reduced to a cycle length of 3 and values 9 , 6 , 4 . just as the elements of a list may be represented as a repeated sequence , so may the differences between successive elements . if the differences satisfy the requirements for a repeated sequence , then the list of values can be reduced to a descriptive tag , the value for the cycle length q and the smaller list of values s , which may be subject to another compression pass . this form of encoding is very useful for expressing timestamps ( usually floating point values representing the number of seconds since jan . 1 , 1970 , utc ) such as 4 pm every tuesday and 6 pm every thursday . for example , the list 7 , 8 , 11 , 10 , 11 , 14 , 13 , 14 , 17 can be reduced to 7 ( the first element ), 3 ( the cycle length ) and the smaller list 1 , 3 , − 1 . if all the values in a list can be expressed in the form : where the elements of s are integers all expressible either as one , two or three bytes , then the list is reduced to a descriptive tag , a value specifying how many bytes each element of s requires , the values for r and d and the list of values s . fig7 shows the algorithm employed to calculate the smallest number of bytes required to store the values in the list . this value (“ mantissasize ”), the scale employed and the initial value are used to encode the complete list of values in a fixed point encoding as is shown in fig8 . just as a list of values may be encoded as fixed point so may the differences between successive elements . this is possible when the list of values can be expressed in the form : where i is an index running from 2 to the number of values in the list and the elements of s are integers all expressible either as one , two or three bytes . encoding the differences as fixed point is very similar to encoding the original list of values . the result has a descriptive tag , a value specifying how many bytes each element of requires , the values for a 1 and d and the list of values s . if a list of 64 - bit floating point values can be expressed as 32 - bit floating point values without violating the precision requirements , the list is reduced to 32 - bit floats . the preceding methods are only concerned with exploiting linear relationships . image data typically has relationships extending in two dimensions , allowing greater compression options . the adapter also supports portable network graphics (“ png ”) and joint photographic experts group (“ jpeg2000 ”) formats in the client access api , but does not automatically select them . these methods must be specified by the database designer and are intended to be used , where appropriate , by image loading client programs . compression of integer data is shown in fig3 . the algorithm follows the pattern of that for floating point values but without use of the tolerance parameter . in effect the tolerance parameter is 1 . the decompression module holds a suite of decompression routines complementary to the compression routines . the first 4 bytes in the serialized data to be decompressed identify the type of the decompression . for the codes matching the compression routines listed above , the decompression module simply calls the appropriate decompression library . there is a special decompression code with a value of 1000 . this decompression code is used to indicate that the decompression routine is actually present external to the invention itself . in this case , the textual name of the compression routine follows ( as a null - terminated string , not exceeding 30 characters ). this name is used as a key to look up the name of a decompression routine in a table with the following schema : the named decompression routine is accessed through the sql interface and returns the decompressed data re - serialized in the raw form . this mechanism allows the invention to be extended by users to support additional decompression routines inside the server . the serialization module converts scalar values and character strings to a serialized form that is machine - independent . it does this by converting items larger than 8 bits to a little - endian format . the deserialization module converts serialized data to the host machine &# 39 ; s format . it does this by converting the data from little - endian format to the native endian format . the database adapter 100 provides for the construction of multiple indexes , each index using any selected subset of internal columns in the chips as a search key . the process of constructing an index is as follows : an n - dimensional box column is added to the table containing the chips . alternatively , the box column is defined when the table is first created . a function supplied by the invention is used to populate the box column . this function takes a string specifying a subset of internal column names and a chip as an argument , and returns an n - dimensional box that represents the minimum and maximum values of the columns . the function can be called from database insert or update triggers , or it can be invoked explicitly by a client with an update statement . an r - tree or gist index ( whichever is supported by the underlying dbms ) is created on the box column . the following example illustrates the commands that could be used to create an index . in essence , this chip indexing strategy provides the equivalent of multi - dimensional , multi - level aggregate indexes without needing elaborate client support . on databases that support functional indexes , it is possible to create an index without adding or populating a box column . consider the following schema that could be used to store an image in a simple table structure . the following table defines a 4 × 4 patch of pixels for a portion of an image ( of a person &# 39 ; s face ) beginning at row 636 and column 421 . using the native table structure above , this image would require 6 × 16 × 4 = 384 bytes . the same schema could be used to represent the data inside a chip . the choice of an image is simply to illustrate application of the compression schemes to data with differing internal structures . normally , the length of each column would be much larger , and an image - specific compression scheme would be applied to the red_band , green_band , and blue_band columns . however , when the chip was serialized ( for transport to a database or storage inside a blob ), the columns would be individually compressed as follows : 1035 , 1035 , 1035 , 1035 , 1035 , 1035 , 1035 , 1035 , 1035 , 1035 , 1035 , 1035 , 1035 , 1035 , 1035 , 1035 the sequence is checked to see if it can be encoded as an arithmetic sequence . since the entire column has the value 1035 , the column can be serialized as the series with the parameters : start value = 1035 , r = 0 . the column is serialized as the ( arithmetic sequence tag , 1035 , 0 ), for a total length of 12 bytes . 636 , 636 , 636 , 636 , 637 , 637 , 637 , 637 , 638 , 638 , 638 , 638 , 639 , 639 , 639 , 639 the sequence is checked to see if it can be encoded as an arithmetic sequence . it can not since the difference between consecutive values is not constant . the sequence is then checked to see if it can be encoded as an arithmetic cycle . that test also fails . the sequence is then checked to see if it can be encoded using run - length encoding . there are 12 duplicated values , which is & gt ;= the series length 16 / 2 . therefore run - length encoding can be used . the run - length encoding produces the following set of run codes and run values : run codes : 2 , 2 , 2 , 2 run values : 636 , 637 , 638 , 639 the run - length encoding procedure recursively invokes the compression code on the run values . the run values are in turn encoded as the arithmetic sequence ( arithmeticsequencetag , 636 , 1 ). the complete serialization column becomes ( runlength tag , 4 , 4 , 2 , 2 , 2 , 2 , arithmeticsequencetag , 636 , 1 ). the “ 4 , 4 ” in the serialization preceding denotes the number of run codes followed by the number of run values . because the run codes are 1 byte quantities , the total size is 7 × 4 = 28 bytes . 421 , 422 , 423 , 424 , 421 , 422 , 423 , 424 , 421 , 422 , 423 , 424 , 421 , 422 , 423 , 424 the sequence is checked to see if it can be encoded as an arithmetic sequence . however , the differences between consecutive elements are not constant ( they are either 1 or − 3 ) and that check fails . next , the sequence is checked to see if it can be represented as an arithmetic cycle . the code determines that the minimum value is 421 , the maximum value is 424 , the minimum step is 1 , and the apparent cycle length =( 424 - 421 + 1 )/ 1 = 4 , and the cycle offset is 0 . the code then verifies it can correctly reproduce the original sequence from these parameters . as a result the sequence is coded as the values ( arithmeticcycletag , 421 , 1 , 4 , 0 ). the total size is 5 × 4 = 20 bytes . 234 , 250 , 243 , 247 , 242 , 250 , 249 , 247 , 240 , 255 , 255 , 235 , 242 , 242 , 243 , 235 the sequence is checked to see if it can be coded as an arithmetic sequence . this check fails , as does the arithmetic cycle check , the run - length encoding check , and sequence check . the code next computes the differences between consecutive elements to produce the sequence d : 16 , − 7 , 4 , − 5 , 8 , − 1 , − 2 , − 7 , 15 , 0 , − 20 , 7 , 0 , 1 , − 8 . next , it computes the parameters needed to represent each sequence in fixed point notation . both the original sequence and the sequence d require one byte per element , so the original sequence is converted to fixed point notation by subtracting the minimum value ( 234 ), and dividing by the gcd ( 1 ), to produce values = 0 , 16 , 9 , 13 , 8 , 16 , 15 , 13 , 6 , 21 , 21 , 1 , 8 , 8 , 9 , 1 . the entire serialization of the sequence has the form ( fixedpointtag , 1 , 1 , 234 , 0 , 16 , 9 , 13 , 8 , 16 , 15 , 13 , 6 , 21 , 21 , 1 , 8 , 8 , 9 , 1 ). the total size is 4 × 4 + 16 = 32 bytes . 145 , 167 , 148 , 183 , 162 , 167 , 176 , 183 , 156 , 180 , 190 , 172 , 150 , 169 , 152 , 172 the sequence is checked to see if it can be coded as an arithmetic sequence . this check fails , as does the arithmetic cycle check , the run - length encoding check , and sequence check . the code next computes the differences between consecutive elements to produce the sequence d : 22 , − 19 , 35 , − 21 , 5 , 9 , 7 , − 27 , 24 , 10 , − 18 , − 22 , 19 , − 17 , 20 . next , it computes the parameters needed to represent each sequence in fixed point notation . both the original sequence and the sequence d require one byte per element , so the original sequence is converted to fixed point notation by subtracting the minimum value ( 145 ), and dividing by the gcd ( 1 ), to produce values = 0 , 22 , 3 , 38 , 17 , 22 , 31 , 38 , 11 , 35 , 45 , 27 , 5 , 24 , 7 , 27 . the entire serialization of the sequence has the form ( fixedpointtag , 1 , 1 , 145 , 0 , 22 , 3 , 38 , 17 , 22 , 31 , 38 , 11 , 35 , 45 , 27 , 5 , 24 , 7 , 27 ). the total size is 4 × 4 + 16 = 32 bytes . 111 , 133 , 116 , 155 , 129 , 133 , 144 , 155 , 128 , 154 , 168 , 157 , 127 , 152 , 123 , 157 . the sequence is checked to see if it can be coded as an arithmetic sequence . this check fails , as does the arithmetic cycle check , the run - length encoding check , and sequence check . the code next computes the differences between consecutive elements to produce the sequence d : 22 , − 17 , 39 , − 26 , 4 , 11 , 11 , − 27 , 26 , 14 , − 11 , − 30 , 25 , − 29 , 34 . next , it computes the parameters needed to represent each sequence in fixed point notation . both the original sequence and the sequence d require one byte per element , so the original sequence is converted to fixed point notation by subtracting the minimum value ( 111 ), and dividing by the gcd ( 1 ), to produce values = 0 , 22 , 5 , 44 , 18 , 22 , 33 , 44 , 17 , 43 , 57 , 46 , 16 , 41 , 12 , 46 . the entire serialization of the sequence has the form ( fixedpointtag , 1 , 1 , 111 , 0 , 22 , 5 , 44 , 18 , 22 , 33 , 44 , 17 , 43 , 57 , 46 , 16 , 41 , 12 , 46 ). the total size is 4 × 4 + 16 = 32 bytes . a humanly - readable version of the final serialized representation of the chip would be : fixedpointtag , 1 , 1 , 234 , 0 , 16 , 9 , 13 , 8 , 16 , 15 , 13 , 6 , 21 , 21 , 1 , 8 , 8 , 9 , 1 , fixedpointtag , 1 , 1 , 145 , 0 , 22 , 3 , 38 , 17 , 22 , 31 , 38 , 11 , 35 , 45 , 27 , 5 , 24 , 7 , 27 , fixedpointtag , 1 , 1 , 111 , 0 , 22 , 5 , 44 , 18 , 22 , this is stored as a single cell in a single chip column in a single row of a table . in order to load this data , a client program performs the following steps : ( 1 ) a multivariate data object is created using the client libraries provided with the multivariate data management module 102 . ( 2 ) the desired columns are added to the data object and it is populated with data . ( 3 ) the multivariate data object is compressed and serialized . ( a ) for each column in the multivariate data object , the compression module 112 is used to build a compressed , serialized form of the column . for the column named ‘ x ’, the run - length encoding routine converts the data to the run counts { 0 , 0 , 1 , − 1 , 0 } and the run values { 10 , 20 , 30 , 40 , 50 }. the run values are then compressed as an arithmetic sequence with parameters r = 10 and d = 10 . for the column named ‘ y ’, the fixed point encoding routine recognizes that it can encode the run values as r = 0 . 4 , d = 0 . 2 , s =( 3 , 8 , 13 , 23 , 33 , 0 , 2 , 1 , 3 , 98 ), storing s as 1 byte values . for the column named ‘ z ’, the arithmetic cycle encoding routine recognizes that it can encode the values with the parameters r = 3 . 0 , p = 1 , d = 0 . 2 , q = 4 . ( b ) the multivariate data management module 102 then serializes a version identifying tag , the number of rows for which space has been allocated in the multivariate data object , the actual number of rows which have data in them , the number of columns and , for each column , the column &# 39 ; s name , the column &# 39 ; s type , the column &# 39 ; s tolerance , the length of the column &# 39 ; s serialized form and the serialized form of each column &# 39 ; s data . ( c ) the client then issues an sql insert statement , passing in the serialized data , such as : the dschipfrombytes routine in the database adapter 100 is called with the serialized data . this routine copies the serialized data into an object or a blob . the server then stores the new object in the some_chips_table . the client program requests data with an sql select statement , such as : the server invokes the dschipextract routine in the database adapter 100 , passing it a reference to a chip and the two strings . the dschipextract routine converts the two strings to null terminated strings as used by c , and extracts the raw binary data in the chip as an array of bytes . the dschipextract routine then invokes the multivariate data management module 102 to construct a multivariate data object from the array of bytes . the multivariate data management module 102 extracts the following data from the array of bytes . ( a ) aversion identifying tag . ( b ) the maximum number of rows to allocate space for . ( c ) the actual number of rows that have data in them . ( d ) the number of columns . ( e ) for each column , the column &# 39 ; s name , type , tolerance and length . ( f ) for each column , the serialized data for that column is decompressed using the deserialization module 114 and the decompression module 116 . the dschipextract routine then uses the multivariate data management module 102 to discard any rows containing data where x & lt ;− 0 . 4 or x & gt ; 0 . 8 or z & lt ;− 10 or z & gt ; 20 and to discard all columns except x and y . the dschipextract routine then uses the multivariate data management module 102 to serialize the modified multivariate data object ( this process is not broken down further since it has already been described ) and stores the serialized data in an object . the client program typically uses its own copy of the multivariate data management module to deserialize and otherwise access the data in the object . the foregoing is a description of the preferred embodiment of the invention . as is readily apparent to one skilled in the art , variations in the design that do not alter the scope of the invention are contemplated . for example : while the preferred embodiment stores serialized chips as blobs , in some variations they can be stored as binary string types , or in files on a file system . while text is not currently supported as a column type , in some variations it can be included — for example with huffman or lzw compression . while the compression scheme is selected on a per chip basis , in some variations a compression scheme could be selected on the basis of a single chip and used on a number of subsequent chips before another compression scheme is selected .