In some cases, when we begin a task of data modelling, we can build walls around our project and treat it as an independent kingdom.  The design process is easier if the project has no need of any inputs from outside nor any need to provide information to anywhere else.  This gives us much more freedom in our design choices.  We can choose tools that suit us, and we don’t need to worry about consistency or cooperation.

However, we often have to allow for interaction with another system or integration within a larger organisation.  The data we model may need to be accessible to others or we may have to provide the data in another format to other users.  Likewise, we may need to read some of our data from other places or even routinely update some of our data from another source.

There was a time in software development when XML was presented the solution to all problems.  XML was new.  XML was shiny.  XML was it!  If you weren’t using XML, you weren’t with it.  According to this sycophantic enthusiasm, XML should be used to input, store, edit and export data.  The need to allow our data to be accessed by others or easily transported for others still remains, and thankfully, the raving phase of the XML fad has passed so that other options are again considered reasonable by most!  Import and export options need to be thought about carefully.

Importing and exporting of data may be sufficient, but in some cases, data must be accessed dynamically and possibly even updated by others.  We need to take all of these demands into account in our design or else our system may become an island of data rendered useless by its isolation.  Of course access to data must also be easily controlled so that it does not fall into the wrong hands – easy access for the good guys; none for the bad guys.