somusar/Sisendel: A Tutorial Introduction

We Generate Your Software.

Products

Services

Company

Please note: this document is currently under revision.
The information herein contained, while still valid, does not reflect the latest state of the described technology.

The Somusar/SoProTech[tm] Booklet Series Volume III "somusar/Sisendel: A Tutorial Introduction" Printer friendly

Contents
1. Introduction
2. Sisendel Software Entities
3. Sisendel Basic Types
4. Sisendel User Types
5. Contents of an Entity File
6. Section `CORE`
7. Section `DEFS`
8. Section `DB`
8.1	Applying an SQL mold
9. Section `LOGIC`
10. Section `UI`
11. Implicit Section `DOC`
12. Section `ADJUST`
13. Further Reading

Chapter 8 - Section `DB`

The database section of an entity file allows to define how the data related to a given entity should be grouped and managed by a data management system, such as a relational database, or a file system. Section DB will typically contain a definition of the database table and key, or keys, to access the data. Such definitions can be expressed in terms of collections of fields; in fact, the only Sisendel language rule applicable within section DB is the collection definition described in the corresponding paragraph .

8.1 - Applying an SQL mold top

The DB mold applied to collections DB.table and DB.pkey of entity "company/employee.ef" produces an SQL file, containing a script to create a database table for that entity, as shown in the following code example.

Code Example 12 - From DB.table and DB.pkey to "employee.sql"

This generated SQL script is derived from collections DB.table and DB.pkey of entity employee. The mapping between the members of DB.table and the SQL source code lines is as follows:

Field empl_id is mapped to line 6;

Field person is mapped to lines 7-11;

Field info is mapped to lines 12-15;

Field dept is mapped to line 16;

Field position is mapped to line 17;

Field salary is mapped to line 18.

Collection DB.pkey is mapped to line 19.
A few notes on the project conventions applied to the SQL mapping of fields whose type is an entity:

Embedded entities, such as person, require that all members of their DB.table collection be included as columns in the generated SQL table of the embedding entity;

linked entities such as dept require that all members of their DB.pkey collection be included as columns in the generated SQL table.

Moreover, by project conventions the identifiers of the SQL table columns contain no underscore "_": such project-wide conventions are usually implemented in one mold, and can be very easily and quickly changed, if needed, and re-applied consistently to all projects that use that particular mold.

Source code - File "company/DB/employee.sql"

    1      --
    2      -- This SQL script created by somusar/SoProMach[tm]
    3      --
    4      
    5      create table employee (
    6          emplid                    int            not null,
    7          lastname                  varchar(40)    not null,
    8          firstname                 varchar(40)    not null,
    9          emailaddr                 varchar(60)    not null,
   10          telephone                 varchar(40)        null,
   11          cellphone                 varchar(40)        null,
   12          infoage                   int            not null,
   13          infossn                   varchar(40)    not null,
   14          infonationalitycountry    varchar(40)    not null,
   15          infophotoimgfile          varchar(1024)  not null,
   16          deptdeptid                varchar(10)    not null,
   17          position                  varchar(40)    not null,
   18          salary                    decimal(10,2)  not null,
   19          constraint pk_employee    primary key    (emplid)
   20      )
   21      ;
   22

[Previous chapter] [Next chapter] [Back to top]

Chapter 8 - Section DB

8.1 - Applying an SQL mold top

Chapter 8 - Section `DB`