In order to address the above challenges and to also provide for the easy creation of these type of normalized relationships in business applications based on the Aptify framework, Aptify 4.0 introduced a new technology called Embedded Database Objects (EDOs).
Aptify has fully supported foreign key creation through the entity administration tool since Version 1.0. In addition, the concept of Virtual Fields has existed throughout all of the versions of the product. In Aptify 3.0, virtual fields were made easier to create through system defined meta-data for defining join relationships and/or specifying calculations. Virtual fields address the report-writers concern about having to join together multiple tables. The virtual fields are automatically joined in as a part of the Base View in each Aptify entity. Report writers in turn use the Base Views and the complexity of the join relationship(s) within those views are hidden from them, thereby making report writing far simpler in nature.
Creating virtual fields in Aptify can partially handle the challenges created by the type of normalized structure described above. However, traditionally, virtual fields have been read-only in nature because by definition they have been pulled in from other entities or calculated on the fly. This is because for joined virtual fields, the field does not physically exist in the entity being operated on, and so it was not logical to attempt to modify the field in the entity.
However, in the case of the Address type of relationship, while a foreign key relationship exists at the database level, an application-level relationship also exists. In the case of the Customers/Orders/Addresses data model shown above, the logical entity model for Customers and Orders contain the Addresses. From a business-users perspective, the Customers record contains one or more addresses and an Orders record contains a Bill To and a Ship To address. To model this type of logical relationship at the application level, the Aptify Framework contains a new type of relationship called an Embedded link. Whenever a foreign key is defined in Aptify, the administrator specifies if the link's type is Standard or Embedded, as illustrated below.
Anchor
The AddressID inside the Company table is marked as an Embedded link type in the top area of this form. This tells the Aptify system that the model should consider the Address that is included within the Companies record through this foreign key relationship to logically be a part of the Company itself.
When a foreign key field is marked as being an Embedded link as in the above example, the Aptify Generic Entity (GE) architecture natively understands that the field's related record must be considered to be part of the logical structure of the containing record and also must be part of the same transactional space whenever a record is created, modified, or deleted. The GE makes this embedded field available through 3 distinct methods of access for both read and write purposes. The methods are described below:
| Anchor |
|---|
...
|
...
|
The GE model uses a class called AptifyDataFieldBase to describe each field within a GE. The data field handles embedded foreign key fields differently than standard foreign key fields by dynamically instantiating the associated Generic Entity object that represents the embedded or contained object. This GE instance is available through the EmbeddedObject method that exists within the AptifyDataFieldBase class and its sub-classes. For example, to access the City field that is part of the contained AddressID embedded link in a Companies record, a developer could use the following code:
With CompanyGEObject.Fields("AddressID").EmbeddedObject
MsgBox .GetValue("City") & ", " & .GetValue("PostalCode")
.SetValue ("City", "San Jose")
.SetValue ("StateProvince", "CA")
End With
The above code example first accesses the City and Postal Code fields and displays their values in a message box. Subsequently, the code sets the value of the City and StateProvince fields of the address record to "San Jose" and "CA," respectively. Notice that the code does not call the GE.Save() method since the process of saving and loading the embedded object is handled automatically by the containing object. Info:
| Info |
|---|
See |
...
...
for more information on Aptify's object model. |
| Anchor |
|---|
...
|
...
|
In addition to direct object access, it is possible to access fields in an embedded object through the containing object's Generic Entity SetValue and GetValue methods using syntax specifying the foreign key field and the embedded object field separated by a period. See the example below that provides the same functionality as the code example shown in Direct Object Access above.
With CompanyGEObject
MsgBox .GetValue("AddressID.City") & _
", " & .GetValue("AddressID.PostalCode")
.SetValue ("AddressID.City", "San Jose")
.SetValue ("AddressID.StateProvince", "CA")
End With
By specifying the AddressID as the prefix, the GE automatically associates the GetValue and SetValue calls with the embedded object that is contained within the DataField for the specified foreign key. This syntax provides for the same exact functionality in accessing/setting field values in the embedded objects, without having to access the embedded object GE directly.
| Anchor |
|---|
...
|
...
|
Just like with fields that are stored in the entity itself, a developer can use the Set and Get methods for Virtual Fields that are derived through join relationships linked through an Embedded foreign key field. For example, assume that there are five virtual fields in the Company table, Line1, Line2, Line3, City, and PostalCode, which are mapped through Aptify meta-data to the same fields within the Addresses entity via the AddressID foreign key inside the Company table. In this case, the fields would be accessed just as if they were physically resident within the Companies entity itself, and the following code will work correctly:
With CompanyGEObject
MsgBox .GetValue("City") & _
", " & .GetValue("PostalCode")
.SetValue ("City", "San Jose")
.SetValue ("StateProvince", "CA")
End With
In a situation where the same table is joined in more than once, it is possible to access the appropriate embedded object automatically with this approach since each virtual field is uniquely named.
For example, assume that a Company has an AddressID field that is used to link in the main address for the company as well as a BillingAddressID that denotes the billing address for the company. The first set of virtual fields mapped to AddressID might be named City, State, PostalCode, etc. The second set of virtual fields that are mapped to the BillingAddressID might be named BillingCity, BillingState, BillingPostalCode, etc. Since each virtual field in Aptify has meta-data that tells Aptify's Generic Entity architecture the foreign key that it is derived from, it is possible to use the above syntax seamlessly for any number of such relationships. The code shown below illustrates this concept using the conceptual fields described in this paragraph.
With CompanyGEObject
.SetValue ("City", "San Jose")
.SetValue ("StateProvince", "CA")
.SetValue ("BillingCity", "Chicago")
.SetValue ("BillingStateProvince", "IL")
End With
Due to the Aptify Generic Entity architecture's native support of embedded database objects, developers can create schemas that are normalized to a high degree, but which are also simple to interact with programmatically since the GE architecture masks the complexity of the data model from the application developer through this abstraction layer. It is still important to consider the type of application being developed and the expected usage patterns for the end-users to determine the degree of normalization desired in a given application. The point of the Aptify GE architecture supporting this form of relationship management in the database is to greatly simplify the development tasks that are required in the event that a highly normalized form is chosen. In fact, with the Aptify embedded object technology, the degree of normalization can be completely separated from the application code thereby allowing application developers and database administrators to have a much greater degree of freedom in designing and tuning their application designs.(However, keep in mind that there are also risks of over-normalizing the database.)