MAPPING</A>. <BR><BR>
  <DL>
    <DT><STRONG>FixedMap</STRONG>
    <DD>::=3D IVecRef <BR><BR>A single itemvector is used to store the =
column data=20
    for the types <STRONG>I</STRONG>, <STRONG>L</STRONG>, =
<STRONG>F</STRONG>,=20
    and <STRONG>D</STRONG>. There are no secondary itemvectors. The=20
    <STRONG>IVecRef</STRONG> instance will point to instances of=20
    <STRONG>IVecIntData</STRONG>, <STRONG>IVecFloatData</STRONG>,=20
    <STRONG>IVecDoubleData</STRONG>, or <STRONG>IVecLongData</STRONG>, =
as=20
    directed by the concrete type. <BR><BR>
    <DT><STRONG>VariableMap</STRONG>
    <DD>::=3D IVecRef IVecRef IVecRef <BR><BR>Two or three primary =
itemvectors are=20
    required when storing string or binary data (Types =
<STRONG>S</STRONG> and=20
    <STRONG>B</STRONG>). <BR><BR>The first two itemvectors contain all =
the data=20
    which is considered small enough to be stored together. The third =
itemvector=20
    is present only if the column contains rather large data in one or =
more=20
    cells. See also section <A=20
    =
href=3D"http://www.equi4.com/metakit/metakit-ff.html#variablesizeddata">V=
ARIABLE=20
    SIZED DATA</A>. <BR><BR>The first reference is to an instance of=20
    <STRONG>IVecDinaryData</STRONG>. It contains the directly stored =
data of the=20
    column. The sizes of the items in this itemvector are given through =
the=20
    second itemvector for the column. It is always present. <BR><BR>The =
second=20
    reference is to an instance of <STRONG>IVecIntData</STRONG>. It =
contains the=20
    item sizes for all the directly data of the column. This reference =
is absent=20
    if the itemvector for directly stored data (see above) is empty =
(size =3D=3D 0).=20
    <BR><BR>The third reference is to an instance of=20
    <STRONG>IVecCatalogData</STRONG>. It contains the information to be =
able to=20
    reach all data of the column which is not stored directly in the =
first=20
    itemvector. This data is called <EM>indirect</EM> because a catalog, =
this=20
    itemvector, is required to find its actual locations. The reference =
is=20
    always present, even if the column does not possess indirectly =
stored data.=20
    <BR><BR>
    <DT><STRONG>SubviewMap</STRONG>
    <DD>::=3D SubMarker NumberOfRows [ Mapping ] <BR><BR>The=20
    <STRONG>Mapping</STRONG> is similar to the one used for the main =
views in=20
    the database. Per column in the subview we have one mapping, as =
declared by=20
    the selected structure of the subview. The whole mapping is not =
present if=20
    the subview is empty (number of rows =3D=3D 0). <BR><BR>
    <DL>
      <DT><STRONG>SubMarker</STRONG>
      <DD>::=3D bpInt /=3D 0 <BR><BR>Purpose unknown. <! --    -- 	This =
might actually be the tag marker used to select between   -- 	one of =
several different alternatives for the structure of the   -- 	subview. =
See notes in section BACKGROUND.   -- =0A=
   --><BR><BR>
      <DT><STRONG>NumberOfRows</STRONG>
      <DD>::=3D bpInt <BR><BR>The number of rows in the subview.=20
    <BR><BR></DD></DL></DD></DL>
  <DT><STRONG>TableOfContents</STRONG>
  <DD>::=3D TocMarker StructureDefinition ViewSizes Mapping <BR><BR>
  <DL>
    <DT><STRONG>TocMarker</STRONG>
    <DD>::=3D bpInt /=3D 0 <BR><BR>Because of the constant value for the =
marker the=20
    exact byte representation is also known: <BR><BR>byte /=3D 0x80 =
<BR><BR>
    <DT><STRONG>StructureDefinition</STRONG>
    <DD>::=3D pString <BR><BR>This string contains the structural =
definitions for=20
    all views in the database. See section <A=20
    =
href=3D"http://www.equi4.com/metakit/metakit-ff.html#structuredefinition"=
>STRUCTURE=20
    DEFINITION</A> for the syntax of its contents. <BR><BR>
    <DT><STRONG>ViewSizes</STRONG>
    <DD>::=3D { bpInt } <BR><BR>This section contains one octet-packed =
integer per=20
    view in the database (subviews not counted), in the same order as =
the views=20
    were defined in <STRONG>StructureDefinition</STRONG>. The stored =
value=20
    declares the number of rows contained in the view. This number is =
the same=20
    across all columns in the view. <BR><BR>
    <DT><STRONG>Mapping</STRONG>
    <DD>::=3D { ColumnMap } <BR><BR>This section contains one mapping of =
a column=20
    to its primary itemvectors per non-empty view (number of rows =
greater than=20
    zero) in the database (subviews not counted) and column in such a =
view.=20
    <BR><BR></DD></DL>
  <DT><STRONG>DataArea</STRONG>
  <DD>::=3D { IVecData | Hole } <BR><BR>The main part of any metakit =
file contains=20
  the data for the various itemvectors required to store column data, =
and=20
  possible holes, i.e unused, free space. <BR><BR>
  <DL>
    <DT><STRONG>Hole</STRONG>
    <DD>::=3D { byte } <BR><BR>Holes are not explicitly listed anywhere, =
but=20
    implicitly determined as the areas of the file not reached through =
any of=20
    the itemvector references in the table of contents. Because of that =
their=20
    size cannot be declared in the grammar. <BR><BR></DD></DL>
  <DT><STRONG>Serialization</STRONG>
  <DD>::=3D Header DataArea TableOfContents Footer </DD></DL><! -- =
__________________________________________=0A=
   --><A=20
name=3Dstructuredefinition>
<H2>STRUCTURE DEFINITION</H2>This section describes the syntax of the =
string=20
containing the structural definition of all views in the database. See=20
<STRONG>StructureDefinition</STRONG> in section <A=20
href=3D"http://www.equi4.com/metakit/metakit-ff.html#formatgrammar">FORMA=
T=20
GRAMMAR</A> for its place in the file. Like for the whole format itself =
we use a=20
grammar in EBNF format to specify the syntax. Note however that the =
symbols used=20
here are distinct from the symbols used for the file format, even if =
they have=20
the same name.=20
<P>In contrast to the overall file format the lexical unit here is a =
single=20
UTF-8 character (<STRONG>Char</STRONG>).=20
<DL>
  <DT><STRONG>Database</STRONG>
  <DD>::=3D View { ',' View } <BR><BR>
  <DT><STRONG>View</STRONG>
  <DD>::=3D ViewName '[' Columns ']' <BR><BR>
  <DT><STRONG>ViewName</STRONG>
  <DD>::=3D { Char\'[' }{1,} <BR><BR>
  <DT><STRONG>Columns</STRONG>
  <DD>::=3D Column { ',' Column } <BR><BR>
  <DT><STRONG>Column</STRONG>
  <DD>::=3D (ColumnName ':' ColumnType) | View <BR><BR>
  <DT><STRONG>ColumnName</STRONG>
  <DD>::=3D { Char\':' }{1,} <BR><BR>
  <DT><STRONG>ColumnType</STRONG>
  <DD>::=3D 'S' | 'I' | 'F' | 'D' | 'B' | 'L' <BR><BR><EM>Note</EM> that =
the=20
  characters used here correspond to the type indicator characters =
introduced in=20
  section <A=20
  =
href=3D"http://www.equi4.com/metakit/metakit-ff.html#typedefinitions">TYP=
E=20
  DEFINITIONS</A> </DD></DL><! -- =
__________________________________________=0A=
   --><A=20
name=3Dglossary>
<H2>GLOSSARY</H2>
<DL>
  <DT><EM>database</EM>
  <DD>A metakit database, consisting of a set of views. <BR><BR>
  <DT><EM>view</EM>
  <DD>In standard database speak a <EM>table</EM>, holding data =
belonging=20
  together. In abstract terms a matrix of <EM>cells</EM>, sliced into =
vertical=20
  <EM>columns</EM> and horizontal <EM>rows</EM>. All cells in a single =
column=20
  have the same <EM>type</EM>, whereas the cells in a <EM>row</EM> can =
be of=20
  different types, and are also the fundamental unit of data belonging =
together.=20
  <BR><BR>
  <DT><EM>column</EM>
  <DD>A vertical section of the data in a <EM>table</EM>. Its =
characteristic=20
  attribute is the <EM>type</EM>, shared by all <EM>cells</EM> in a =
column.=20
  <BR><BR>
  <DT><EM>row</EM>
  <DD>A horizontal section of the data in a <EM>table</EM>. The cells in =
a row=20
  belong together in some way. <BR><BR>
  <DT><EM>cell</EM>
  <DD>The fundamental container for holding data in a <EM>table</EM>. =
Arranged=20
  in a grid of <EM>rows</EM> and <EM>columns</EM>. <BR><BR>
  <DT><EM>subview</EM>
  <DD>A special <EM>type</EM> of <EM>column</EM> where the data in each=20
  <EM>cell</EM> is a <EM>view</EM> in its own right. <BR><BR>
  <DT><EM>type</EM>
  <DD>An attribute of <EM>columns</EM>, it defines the structure of the =
data=20
  stored in the cells of a column. In ambiguous situations this term can =
be=20
  qualified as <EM>column type</EM>. Examples of types are <BR><BR>
  <UL>
    <LI>floating point number=20
    <LI>integer number=20
    <LI>string=20
    <LI><EM>subview</EM>=20
    <LI>... </LI></UL>
  <DT><EM>property</EM>
  <DD>Properties to columns are like classes to instances. They exist=20
  independent of columns, and each column belongs to a property. The =
only=20
  information a property currently holds is its name. This name is =
inherited by=20
  all columns belonging to the property, and actually defines the =
relationship.=20
  All columns with name <STRONG>FOO</STRONG> belong to the property with =
the=20
  same name. The type of a column is not an attribute of the property, =
but of=20
  the column itself. <BR><BR>
  <DT><EM>itemvector</EM>
  <DD>Physical container used to store <EM>column</EM> data. Depending =
on the=20
  <EM>type</EM> and data contained in each column in a <EM>view</EM> =
metakit=20
  will use one or more itemvectors to save all the relevant information. =
Each=20
  itemvector is made up of <EM>items</EM> stored back to back. <BR><BR>
  <DT><EM>item</EM>
  <DD>Fundamental unit for storing data. A contiguous group of items is =
called=20
  <EM>itemvector</EM>. The data of a <EM>cell</EM> in a <EM>column</EM> =
is=20
  stored in a single <EM>item</EM> if and only if the <EM>column</EM> is =

  represented by a one <EM>itemvector</EM>. Else the data of a =
<EM>cell</EM>=20
  will be spread over multiple <EM>items</EM>. The <EM>items</EM> for a=20
  <EM>cell</EM> will be associated through the row index in their =
respective=20
  containers. In other words, the <EM>items</EM> of a <EM>cell</EM> all =
have the=20
  same row index. <BR><BR>
  <DT><EM>indirect</EM>
  <DD>See section <A=20
  =
href=3D"http://www.equi4.com/metakit/metakit-ff.html#variablesizeddata">V=
ARIABLE=20
  SIZED DATA</A>. <BR><BR>
  <DT><EM>offset</EM>
  <DD>An offset is a reference to another location in the metakit file =
or=20
  serialization. It is counted either forward or backward from a =
specific anchor=20
  location in the metakit file or serialization. Both direction and =
anchor=20
  location are part of the specification of an offset value. <BR><BR>
  <DT><EM>pointer</EM>
  <DD>A pointer is an <EM>offset</EM> counted forward from the beginning =
of the=20
  metakit file or serialization. The beginning itself is defined to be =
at=20
  pointer offset 0. </DD></DL><! -- =
__________________________________________=0A=
   --><! --    -- 	Scratch area.   --    -- 	Metakit ideas. Do not store =
a serialized view definition in   -- 	&lt;StructureDefinition&gt;, or =
rather only a minimal definition of   -- 	two views, declared alike the =
file/dir views for the metakit   -- 	filesystem. dir -&gt; view, file =
-&gt; column. This spans up a tree   -- 	structure containing all view =
definitions in a structured   -- 	manner, not only column names and =
types, but additional   -- 	information like encryption, compression, =
alternate subview   -- 	structures, .... Extending that structure then =
allows storing   -- 	derived views (=3D views composed of other views =
through some   -- 	means (join, select, project, functional mappings, =
...),   -- 	constraints, triggers, ... The tree has become a &gt;&gt; =
data   -- 	dictionary. The old &lt;StructureDefinition&gt; can be used =
to   -- 	bootstrap this new dictionary layer. The dictionary should   -- =
	contain the definition of its own structure.   --    -- 	Nice thing =
about this: The file format doesn't have to change   -- 	a bit. This is =
all in the metakit library itself, how it actually uses   -- 	the file.  =
 -- =0A=
   --><! -- __________________________________________=0A=
   --><A=20
name=3Dkeywords>
<H2>KEYWORDS</H2>metakit, database, vector storage, column-oriented <A=20
name=3Dcopyright>
<H2>COPYRIGHT</H2>Copyright (c) 1996-2003 Jean Claude Wippler=20
&lt;jcw@equi4.com&gt;<BR>Copyright (c) 2003 Andreas Kupries=20
&lt;andreas_kupries@users.sourceforge.net&gt;<BR></A></BODY></HTML>