|
|
 |
|
|
|
User Data Model
|
|
Foreign keys and
dereferencing
|
|
|
|
|
|
Next, consider a
situation where your database has two tables, Patron
and Address, containing records for library patrons
and their addresses respectively, as shown in the
diagram at left.
|
|
 |
Suppose
the foreign key Address_id in the Patron table
tells us the address record associated with a
particular Patron record. When creating a UDM
node associated with such a table, the zDE
automatically creates additional
“dereferencing” nodes for the foreign keys.
Thus, if you used this table to create a UDM
node, the UDM might look like the one shown in
at right. Note how zeroCode has added |
 |
|
|
two nodes named
Address_id__deref and derefValue for this purpose. The
reasoning for this is the following. When you create a
UDM, your intent is to display the data elements in it
on some visual form (e.g., HTML). Often, however,
foreign key values are not displayable, because they are
maintained as integer values intended as “pointers”
to other tables. In this example, the value in the
Address_id column of the Patron table “points” to
the corresponding patron’s address in the Address
table. Naturally, you would not want to show the integer
value of a foreign key, but rather the content of the
record that the foreign key “points” to. In this
example, you might want to show the street address
column of the address record to which the person’s
address_id foreign key points. To enable this, zeroCode
automatically adds the extra dereferencing nodes
containing the necessary data from the “pointed-to”
table (in this example, the Address table).
|
|
|
|
|
|
Relationships among UDM elements
|
|
|
|
|
 Next,
we will look at how to create UDMs that draw
content from multiple tables. Suppose now that you
want to show, in the web page of the above
example, the person’s address as well. Suppose
your database maintains addresses in a separate
Address table that includes columns for street
address, city, state and zip code, and that the
foreign key Address_id in the Patron table tells
us the address of a given patron. The diagram at
left shows the structure of the two tables.
Since
the UDM depicts all the data elements needed in
the page, you can simply add a child to the person
node. Suppose you call it address, and tell the
design tool (the zDE) that its content comes from
the Address table. The zDE then creates children
for the address node corresponding to each of the
columns of the Address table, so your UDM now
looks like the one shown below.
|
| Order independence:
The nodes that
you add to your UDM do not have to be in any
particular order relative to their occurrence in
the database. In this example, even though the
database imposes a parent-child relationship from
the Address table to the Patron table, the UDM is
built in the exact opposite order: the person node
is the parent of the address node. This
underscores a basic principle when designing UDMs:
it is your look-and-feel requirements, and not the
database’s structure, that dictates the UDM’s
layout. |
|
| Data relationships:
When
you add the address child to the person node, you
can use the zDE’s node addition wizard to relate
the Address_id field of the person node (numbered
7 in the diagram above) to the Id field of the
address node, specifying that the Address record
to retrieve is the one in which these two fields
match. This is essential, of course, because you
want to show not just any address record but the
one associated with the person you are showing.
The exact mechanics of how to use the zDE for this
purpose is described in the UDM building demo, and
we will defer this point for the moment. |
|
In
general, zeroCode automatically generates certain
UDMs (called Auto or Standard UDMs) and designers
can create their own UDMs (called Custom UDMs).
For more about UDMs, click here to get into the
various types of UDMs and their functionality. |
|
|
|
|
|
|
|
|
|
|
|
