Are you tired of having to schedule a data model change just to do one simple attribute addition? Look at what is involved, changing the data model is the simple part. After you make the change you need to merge down the data model to all the sub alternatives, and not to mention all the replicated databases. Also you need to complete any processes that are required by your company to do a data model change.

FCSI has developed a revolutionary method of allowing end users to modify the data model without the need for doing the complex data model change process. We store the user changes in a text join that is associated with the objects in the database. This allows an end user the ability to add, remove, or modify attributes on the objects at any time.

What for?

This technology is to support new types of data that you may be getting. Do you want to start recording new attributes being provided even if you do not know if you will use them in the future? This functionality allows you to quickly add or modify the new attributes so you can start recording the data and decide later to officially add it to the data model.

Do you want to test new functionality and you need a new attribute? Instead of requesting a data model change from your administrator, you can quickly add the new attribute and do your testing before you propose a change to the data model.

How can this be done?

This technology is based on storing XML data inside the database. And yes, in order to use this functionality as is, you need to do a data model change that adds a text join to all your objects. Other methods of storing the XML data could be developed, you just need to decide how the changes (which are already accomplished in the Smallworld VDMS technology) will be managed from alternative to alternative.

The text join is used as XML storage area. When you configure the XML fields, you give it the type of field it is (integer, float, string, etc.) and if it is visible to the editors and query tools. When you edit the attribute field in either the object editor or on the Magik prompt, the data is converted into XML entries and added or changed in the XML text join. Here is an example of the XML data stored in the text join.

How is the data presented?

The data looks and acts just like any other attribute field in the database. It can be included in the object editors and can be queried in the Query tools. You can also access and modify the attribute fields in Magik code identical to any other field. So to the end user they do not know if this data is a true physical field on the database or if it is an XML attribute.

Below is a screen shot of what the editors and query builder look like to the end user.

Caching is done to support performance similar to any other field.

How do you configure the fields?

We provide a GUI interface into the configuration file that allows you to add XML fields to the data. It also allows you to make the fields visible to the end user. You can select what type of field value the attribute will support, such as integer, float, string, date, or boolean. Here is a snapshot of the configuration tool.

Pricing

This pricing includes 1 week of on site training and support to configure the functionality to your specific needs. Additional costs may be added for travel outside the continental United States. Please contact us for more details.

Send mail to webmaster@field-csi.com with questions or comments about this web site.
Copyright © 2007 Field Consulting and Services, Inc.
Last modified: 05/30/07