saada logo

Tutos and Links  
Getting started  
Doing More  
The Web Interface  
VO Publishing  
Tips & Troubelshooting  
Mailing List  
Saada Sites  
How to Contact us ?  
Next Step  
Old Releases  
Inside Saada  
Using UWS Logo

HOME ART > Tutorial > SaadaQL
Constraints using UCDs or Utypes

 In the SaadaDB the data are stored in collections. All collections have the same columns for each category (spectra, picture, ...). These columns are populated with values calculated by Saada or by values copied out from original data. So it may be possible to make selections of more than one collection but with the constraint of only using collection level columns. We postulate here that final user are not able to build SQL joins.

Such queries on heterogeneous data can not include constraints using the original keywords of the products. Those keywords can only be used if the coverage of the query is limited to one class that is to say, a dataset of a same collection with a similar format.

A consequence of this organization is the fact that we can not select data in the whole database by using the native attributes.

 However, we can get round this limitation by using the UCDs or Utypes.

  • UCDs refer to a physical quantity whereas UTypes refer to a VO data model. A SaadaQL query can include one UCD based statement or one Uype base statement, but not both. SaadaQL handles both UCDs and Utypes exactly with the same way. The following rules can be applied to both UCDs and Utypes.
  • Using UCDs or Utypes requires the edition of the meta data associated to attributes (see).
  • UCDs or Utypes can be set for each attribute of each class.
  • Each attribute which possess a UCD can be declared as being used in a request based on UCDs (column queriable of metadata tables).
  • To each attribute one can associate another attribute containing the related error (not implemented in the admin tool yet)
  • A unit can be affected to each attribute. You can choose this unit in a list of units supported by the Saada converter borrowed in CDS. The use of a unit which is not listed is supported by the converter if its elementary components (length, time ...) are identified.

 The definition of the UCDs is universal so they can be used to select data whatever the keywords are. SaadaQL suggests a clause showing the constraints with the UCDs.

Select IMAGE From * In *
WhereUCD{[] = 'target' [none]}

The above query selects all the pictures of the database which do have at least one queriable attribute with a UCD whose value is "target". In this case the units will be ignored.

Select ENTRY From * In *
WhereUCD [src.veloc.hc] > 100000 [m/s]}

The above query selects entries in all tables of the database. Those entries must have a radial velocity higher than 100000 m/s. The value of the operand (e.g. 100000) will be converted in the native units of each table consulted.

 Several queriable columns of a table can match a given UCD. In that case the logical operator is applied. In that case, only the first one is used by the query engine. In fact, using multiple columns with the same UCD can make the query result confusing or even wrong (see).

 Our experience with those UCD query showed that we need to limit the complexity of the queries to get more comprehensive results. A limited set of operators have been defined for this reason.

operator operand role
= String or numeric equals to
 != String or numeric not equals to
> numeric greater than
>= numeric greater than or equals to
numeric lower than
<= numeric lower than or equals to
[] (numeric, numeric) in range, bounds excluded
[=] (numeric, numeric) in range, bounds included
][ (numeric, numeric) out of range, bounds excluded
]=[ (numeric, numeric) out of range, bounds included
  • In the clause WhereUCD the brackets are forbidden
  • The text columns can be used for every operator. Nevertheless the classification operation are done in the lexival order. For instance ’03’ < 2, whereas 3 > 2.
  • UCDs and Utypes give no indication about the column type (numeric or text). A textual co.umn can have the same UCD as another numeric column. That can raise errors with operators making no sense for text :

 Units must appear in the auery. Use the word none or unit to ignore units

  • Query with no unit
WhereUCD {
   [] = 'target' [none]
  • Query with a unit
WhereUCD {
   [phot.flux] > 1e-14 [erg/cm2/sec]
  • If the unit is not recognized the request is going to fail.
  • If a unit is given tables which do not have a unit for a given UCD will be ignored by the query engine.
  • If there is no unit given, all the tables having this UCD are queried whatever the native units are.

 Constraints based on the UCDs can also consider associated errors . The association between a value and its error is set by hand with the UCD editor (not implemented yet).

  • Errors are supposed to be expressed with the same units as parent values.
  • The columns with no related error are considerd as with null errors.
  • The ’*’ character placed after the operator indicates that errors must be taken in account.
Constraint traduction
=* val [=] (val-error, val+error)
 !=* val ][ (val-error, val+error)
>* val > val-error
>=* val >= val-error
<* val < val+error
<=* val <= val+error
[]* (val1, val2) [] (val1-error, val2+errror)
[=]* (val1, val2) [=] (val1-error, val2+errror)
][* (val1, val2) ][ (val1-error, val2+errror)
]=[* (val1, val2) ]=[ (val1-error, val2+errror)
last update 2010-06-11