[Bio] / Sprout / ERDB.pm Repository:
ViewVC logotype

Diff of /Sprout/ERDB.pm

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.7, Thu May 5 03:14:03 2005 UTC revision 1.8, Thu Jun 9 19:06:55 2005 UTC
# Line 32  Line 32 
32  relation that contains two fields-- the feature ID (C<id>) and the alias name (C<alias>).  relation that contains two fields-- the feature ID (C<id>) and the alias name (C<alias>).
33  The B<FEATURE> entity also contains an optional virulence number. This is implemented  The B<FEATURE> entity also contains an optional virulence number. This is implemented
34  as a separate relation C<FeatureVirulence> which contains an ID (C<id>) and a virulence number  as a separate relation C<FeatureVirulence> which contains an ID (C<id>) and a virulence number
35  (C<virulence>). If the virulence of a feature I<ABC> is known to be 6, there will be one row in the  (C<virulence>). If the virulence of a feature I<ABC> is known to be 6, there will be one row in
36  C<FeatureVirulence> relation possessing the value I<ABC> as its ID and 6 as its virulence number.  the C<FeatureVirulence> relation possessing the value I<ABC> as its ID and 6 as its virulence
37  If the virulence of I<ABC> is not known, there will not be any rows for it in C<FeatureVirulence>.  number. If the virulence of I<ABC> is not known, there will not be any rows for it in
38    C<FeatureVirulence>.
39    
40  Entities are connected by binary relationships implemented using single relations possessing the  Entities are connected by binary relationships implemented using single relations possessing the
41  same name as the relationship itself and that has an I<arity> of 1-to-1 (C<11>), 1-to-many (C<1M>),  same name as the relationship itself and that has an I<arity> of 1-to-1 (C<11>), 1-to-many (C<1M>),
# Line 69  Line 70 
70  is described in the L</GenerateEntity> and L</GenerateConnection> methods, though it is not yet  is described in the L</GenerateEntity> and L</GenerateConnection> methods, though it is not yet
71  fully implemented.  fully implemented.
72    
73    =head2 XML Database Description
74    
75    =head3 Data Types
76    
77    The ERDB system supports the following data types. Note that there are numerous string
78    types depending on the maximum length. Some database packages limit the total number of
79    characters you have in an index key; to insure the database works in all environments,
80    the type of string should be the shortest one possible that supports all the known values.
81    
82    =over 4
83    
84    =item char
85    
86    single ASCII character
87    
88    =item int
89    
90    32-bit signed integer
91    
92    =item date
93    
94    64-bit unsigned integer, representing a PERL date/time value
95    
96    =item text
97    
98    long string; Text fields cannot be used in indexes or sorting and do not support the
99    normal syntax of filter clauses, but can be up to a billion character in length
100    
101    =item float
102    
103    double-precision floating-point number
104    
105    =item boolean
106    
107    single-bit numeric value; The value is stored as a 16-bit signed integer (for
108    compatability with certain database packages), but the only values supported are
109    0 and 1.
110    
111    =item key-string
112    
113    variable-length string, maximum 40 characters
114    
115    =item name-string
116    
117    variable-length string, maximum 80 characters
118    
119    =item medium-string
120    
121    variable-length string, maximum 160 characters
122    
123    =item string
124    
125    variable-length string, maximum 255 characters
126    
127    =back
128    
129    =head3 Global Tags
130    
131    The entire database definition must be inside a B<Database> tag. The display name of
132    the database is given by the text associated with the B<Title> tag. The display name
133    is only used in the automated documentation. It has no other effect. The entities and
134    relationships are listed inside the B<Entities> and B<Relationships> tags,
135    respectively. None of these tags have attributes.
136    
137            <Database>
138                    <Title>... display title here...</Title>
139                    <Entities>
140                            ... entity definitions here ...
141                    </Entities>
142                    <Relationships>
143                            ... relationship definitions here...
144                    </Relationships>
145            </Database>
146    
147    Entities, relationships, indexes, and fields all allow a text tag called B<Notes>.
148    The text inside the B<Notes> tag contains comments that will appear when the database
149    documentation is generated. Within a B<Notes> tag, you may use C<[i]> and C<[/i]> for
150    italics, C<[b]> and C<[/b]> for bold, and C<[p]> for a new paragraph.
151    
152    =head3 Fields
153    
154    Both entities and relationships have fields described by B<Field> tags. A B<Field>
155    tag can have B<Notes> associated with it. The complete set of B<Field> tags for an
156    object mus be inside B<Fields> tags.
157    
158            <Entity ... >
159                    <Fields>
160                            ... Field tags ...
161                    </Fields>
162            </Entity>
163    
164    The attributes for the B<Field> tag are as follows.
165    
166    =over 4
167    
168    =item name
169    
170    Name of the field. The field name should contain only letters, digits, and hyphens (C<->),
171    and the first character should be a letter. Most underlying databases are case-insensitive
172    with the respect to field names, so a best practice is to use lower-case letters only.
173    
174    =item type
175    
176    Data type of the field. The legal data types are given above.
177    
178    =item relation
179    
180    Name of the relation containing the field. This should only be specified for entity
181    fields. The ERDB system does not support optional fields or multi-occurring fields
182    in the primary relation of an entity. Instead, they are put into secondary relations.
183    So, for example, in the C<Genome> entity, the C<group-name> field indicates a special
184    grouping used to select a subset of the genomes. A given genome may not be in any
185    groups or may be in multiple groups. Therefore, C<group-name> specifies a relation
186    value. The relation name specified must be a valid table name. By convention, it is
187    usually the entity name followed by a qualifying word (e.g. C<GenomeGroup>). In an
188    entity, the fields without a relation attribute are said to belong to the
189    I<primary relation>. This relation has the same name as the entity itself.
190    
191    =back
192    
193    =head3 Indexes
194    
195    An entity can have multiple alternate indexes associated with it. The fields must
196    be from the primary relation. The alternate indexes assist in ordering results
197    from a query. A relationship can have up to two indexes-- a I<to-index> and a
198    I<from-index>. These order the results when crossing the relationship. For
199    example, in the relationship C<HasContig> from C<Genome> to C<Contig>, the
200    from-index would order the contigs of a ganome, and the to-index would order
201    the genomes of a contig. A relationship's index must specify only fields in
202    the relationship.
203    
204    The indexes for an entity must be listed inside the B<Indexes> tag. The from-index
205    of a relationship is specified using the B<FromIndex> tag; the to-index is specified
206    using the B<ToIndex> tag.
207    
208    Each index can contain a B<Notes> tag. In addition, it will have an B<IndexFields>
209    tag containing the B<IndexField> tags. These specify, in order, the fields used in
210    the index. The attributes of an B<IndexField> tag are as follows.
211    
212    =over 4
213    
214    =item name
215    
216    Name of the field.
217    
218    =item order
219    
220    Sort order of the field-- C<ascending> or C<descending>.
221    
222    =back
223    
224    The B<Index>, B<FromIndex>, and B<ToIndex> tags themselves have no attributes.
225    
226    =head3 Object and Field Names
227    
228    By convention entity and relationship names use capital casing (e.g. C<Genome> or
229    C<HasRegionsIn>. Most underlying databases, however, are aggressively case-insensitive
230    with respect to relation names, converting them internally to all-upper case or
231    all-lower case.
232    
233    If syntax or parsing errors occur when you try to load or use an ERDB database, the
234    most likely reason is that one of your objects has an SQL reserved word as its name.
235    The list of SQL reserved words keeps increasing; however, most are unlikely to show
236    up as a noun or declarative verb phrase. The exceptions are C<Group>, C<User>,
237    C<Table>, C<Index>, C<Object>, C<Date>, C<Number>, C<Update>, C<Time>, C<Percent>,
238    C<Memo>, C<Order>, and C<Sum>. This problem can crop up in field names as well.
239    
240    Every entity has a field called C<id> that acts as its primary key. Every relationship
241    has fields called C<from-link> and C<to-link> that contain copies of the relevant
242    entity IDs. These are essentially ERDB's reserved words, and should not be used
243    for user-defined field names.
244    
245    =head3 Entities
246    
247    An entity is described by the B<Entity> tag. The entity can contain B<Notes>, an
248    B<Indexes> tag containing one or more secondary indexes, and a B<Fields> tag
249    containing one or more fields. The attributes of the B<Entity> tag are as follows.
250    
251    =over 4
252    
253    =item name
254    
255    Name of the entity. The entity name, by convention, uses capital casing (e.g. C<Genome>
256    or C<GroupBlock>) and should be a noun or noun phrase.
257    
258    =item keyType
259    
260    Data type of the primary key. The primary key is always named C<id>.
261    
262    =back
263    
264    =head3 Relationships
265    
266    A relationship is described by the C<Relationship> tag. Within a relationship,
267    there can be a C<Notes> tag, a C<Fields> tag containing the intersection data
268    fields, a C<FromIndex> tag containing the from-index, and a C<ToIndex> tag containing
269    the to-index.
270    
271    The C<Relationship> tag has the following attributes.
272    
273    =over 4
274    
275    =item name
276    
277    Name of the relationship. The relationship name, by convention, uses capital casing
278    (e.g. C<ContainsRegionIn> or C<HasContig>), and should be a declarative verb
279    phrase, designed to fit between the from-entity and the to-entity (e.g.
280    Block C<ContainsRegionIn> Genome).
281    
282    =item from
283    
284    Name of the entity from which the relationship starts.
285    
286    =item to
287    
288    Name of the entity to which the relationship proceeds.
289    
290    =item arity
291    
292    Relationship type: C<1M> for one-to-many and C<MM> for many-to-many.
293    
294    =back
295    
296  =cut  =cut
297    
298  # GLOBALS  # GLOBALS
# Line 2168  Line 2392 
2392                  # Here we have a field list. Loop through its fields.                  # Here we have a field list. Loop through its fields.
2393                  my $fieldStructures = $structure->{Fields};                  my $fieldStructures = $structure->{Fields};
2394                  for my $fieldName (keys %{$fieldStructures}) {                  for my $fieldName (keys %{$fieldStructures}) {
2395                Trace("Processing field $fieldName of $defaultRelationName.") if T(4);
2396                          my $fieldData = $fieldStructures->{$fieldName};                          my $fieldData = $fieldStructures->{$fieldName};
2397                          # Get the field type.                          # Get the field type.
2398                          my $type = $fieldData->{type};                          my $type = $fieldData->{type};

Legend:
Removed from v.1.7  
changed lines
  Added in v.1.8

MCS Webmaster
ViewVC Help
Powered by ViewVC 1.0.3