 |
 |
| LOGIN |  |
REPOSITORY | |
PRODUCTS | |
REGISTER | |
SUPPORT | |
DOWNLOADS | |
CONTACT US | |
XMLRAD.COM |
|
In order to give developers a head-start on developing Universal
Business Modules (UBM) using the e-delos technology, we provide hereunder
the complete reference for one of the largest UBM achievements: the
DelosCONTACT module.
DelosCONTACT is a complete contact management system. It
handles fundamental elements such as Organizations,
Locations, Persons and Media. DelosCONTACT can
interact with numerous other UBMs, such as DelosLOGIN and DelosMAIL, and
is also invoked by Apps such as the DelosPBX.
|
|
||||
The goal of a UBM is to come up with as fine a granularity as possible
with fundamental elements.
1. Identifying groups of fundamental
elements
During this first step, we do not consider relationships between
elements.
Classes of fundamental elements are independent of how they will be
used: do not focus on their manipulation context (e.g. customers,
employees, prospects, students, players).
In the contact management business, such elements can be quickly
identified:
When identified, these classes are named according to the
naming guidelines.
Technically, these groups will become tables in SQL servers. In XML
Schemas, these classes would be element types.
2. Identifying functional
reliationships
It is then time to identify functional relationships between
fundamental elements.
Note: technically speaking, it is possible in e-delos to build
relationships between just about any fundamental elements, ending up with
a far too large amount of relationships. In our example, we would obtain
24 (4!) relationships.
The whole idea of this step is to keep only functional, useful
relationships and eliminate all others. By "functional," we mean "useful
in the context of the company, in human terms."
In DelosCONTACT, a few data paths can be identified fairly
easily:
When you identify these relationships, name them according to the
naming guidelines.
Technically, these paths appear as join tables in SQL servers. In XML
Schemas, these would be subelements of element types.
Each of those, relying on the core of the business, must be checked
against the e-delos guidelines (mainly normal forms
7,
8 and
11).
3. Working on fundamental
information
Fundamental information are columns in tables (fundamental element
classes). For each fundamental element class, fundamental information are
identified.
For instance, in
CPSN, you would identify First name and
Last name, and name these fundamental elements
(CPSN_FIRST_NAME, CPSN_LAST_NAME).Each of those, relying on the core of the business, must be checked
against the e-delos guidelines (essentially normal forms
6 and
10).
During this step, you must identify reference values and
constants, that are then externalized in reference tables. These values
may need to be localized.
Example: a person's kind (Mr., Mrs., Miss).
When working out the reference tables, normal form eleven
(11) can help
you through.
Herebelow is an overview of DelosCONTACT's data model. You can click
on it to see it at a 100% scale. Below it are explanations about how
tables in the model map to physical tables proceeding from applying
the e-delos normal forms, and how typical information requests translate
to SQL in this context.
Further in
On this model, you can see our first core element classes:
CORG, CLOC, CPSN and
CCOM. You can also see the relationships we previously
unveiled: CORGLOC, CORGLOCPSN and
CORGLOCPSNCOM.As a matter of fact, due to application of normal forms, all join
tables are centralized in one physical table, called
K2.
Thus, to retrieve address zip codes for an organization named "ABC," you
would write the following SQL snippet:SELECT CLOC.CLOC_ZIP FROM CORG CORG, CLOC CLOC, K2 CORGLOC WHERE CORG.CORG_NAME = "ABC" AND CORGLOC.K_ID1 = CORG.CORG_ID AND CLOC.CLOC_ID = CORGLOC.K_ID2 Notice that we alias all tables, even those that do not need to be.
This is essential when using many join tables in one query, for it ends
up using
K2 multiple times.Another important point is that all reference tables end up in two
tables that belong to the data model of
LPM, one of e-delos' KPM.
These tables are
KKW, which handles keywords, and
KKWLG, which stores their localized values. We will not
dive more deeply in these notions here, but this is why fetching a
person's kind value (localized in English) would look like this:SELECT CPSNKND.KKWLG_VALUE AS CPSNKND_NAME FROM CPSN CPSN, KKWLG CPSNKND WHERE CPSN.CPSN_ID = 2012638 AND CPSNKND.KKW_ID = CPSN.CPSNKND_ID AND CPSNKND.KKWLG_ID = -21 In the end, this model boils down to 7 physical tables, spanning
on one UBM (Contact) and one KPM (LPM):
CORG,
CLOC, CPSN, CCOM, K2,
KKW, KKWLG. |
© 1999,2000 e-delos. All rights reserved.
Terms of use.