John Kirkwood explains why it is now easier than ever to transfer data between information systems.
An information system consists of three elements – hardware, software and data. Each element is essential, and nothing of value can be achieved if one part is missing.
However, when the first microcomputers appeared on the market in the late 1960s, users had to make do with only one element – the hardware. Apart from the basic operating system, you had to write your own programs – particularly for specialist applications such as investment valuations – and you had to supply your own data. It was rather like selling televisions to people, and then asking them to produce their own programmes!
Since those early days, developments in computer software have, to a great extent, caught up with the advances in hardware technology. Indeed, it could be argued that advances in software development, such as computer-aided design and visualisation, are forcing improvements in processor design.
Today, many microcomputer systems are supplied with a bundle of software, including an operating system (eg DOS and Microsoft Windows), a spreadsheet package, a word processor and a database. All the user has to supply is the data – and in the case of multimedia systems, even that is supplied (eg encyclopedias and dictionaries on CD-ROM).
Capturing data is a time-consuming, labour-intensive activity, involving great expense. The cost to the user can be reduced considerably if there is a large market. Hence, Ordnance Survey supply digitised map data to individual users, at considerably less cost than the initial costs of capturing the data. They are able to do this because so many different groups use maps, such as the police, haulage companies and local authorities.
Similarly, with FOCUS, an on-line database service provided by Property Intelligence, the costs of data collection and dissemination are spread amongst a large number of users. No individual organisation could afford to create and maintain such a resource.
However, much of the information used by property professionals is not available to a mass market, because of issues such as confidentiality and competitive advantage. Thus, an on-line database may provide you with information about a particular property deal, but there may be no way of telling if there was a special relationship between the parties when the deal was struck. For example, in 1971, I occupied a coach house flat on the Calthorpe Estate, Birmingham, for £4 per week. Was this good evidence of rental values? No, I was employed by the Estate at the time!
Apart from these exceptions, most of the data used in the property sector has to be captured by individual organisations in-house, and is not available for purchase on the open market. This includes information about rents, service charges, rent reviews, lease terminations, landlords’ details, tenants’ details and contractors.
When a new property system is first acquired by an organisation, the task of inputting this data can be a considerable one. After the initial effort, though, it is simply a matter of keeping the information up-to-date. The important thing to recognise is that the database represents a valuable resource, which should be managed accordingly.
In practice, many people link a particular database with the application for which it was established. Thus, one set of data is used with a property management system, while another data set is associated with a valuation system. Consequently, some property professionals feel frustrated that they cannot use the data that has been captured for a specific application in a more creative way than the original system permits. That is, they imagine that once data has been ‘devoured’ by one system, it is unavailable for use elsewhere, like food in an animal’s stomach!
The truth is that it has always been possible to link systems, and transfer data, provided that users are willing to expend the necessary resources required to write the conversion programs. In the past, this has often proved to be too expensive and time-consuming to contemplate. However, recent improvements in software, plus the increasing acceptance of internationally recognised standards, have made the task of linking applications a much more straightforward process.
One product that epitomises the ease with which data can be transferred between systems is Blackwell’s Idealist – the Information Manager. This modestly priced database management program includes some extremely effective, and easy-to use features for importing and exporting data, which illustrate how much progress has been made in linking systems.
Using Idealist, it is relatively easy to capture data from existing applications, such as databases, spreadsheets and word processors. Similarly, information may be transmitted with ease to the same type of applications. The following example illustrates this process.
Some years ago, a small system was designed for storing information about the publications held by the department of urban and regional studies at what was then Sheffield City Polytechnic. Using dBase II, a set of records were created, consisting of fields such as ‘name of author’, ‘title of publication’ and ‘date published’. In addition to listing the department’s books and reports, the system was designed to allow users to keep track of loans by staff and students.
There was insufficient time, when the system was being set up, to develop a user-friendly interface with flexible search and retrieval features. Consequently, the processes of entering data and searching for information were rather crude to say the least! However, since it was created, the system has been used extensively and now holds over 5,000 records.
Because Idealist provides a specific facility for importing dBase records, I decided to attempt to transfer the records held on this publications database into the more friendly environment of Blackwell’s product.
Stage one involved creating a record structure in Idealist that was identical to the one created in dBase. First, each field was defined by naming the field, and indicating the type of data to be held (eg text, number, date). Next, a record structure was defined by naming the record, and then identifying those fields that made up the record.
Stage two – the actual process of importing the dBase records – was simplicity itself. First, the method of importing was selected from a menu (ie DBF file). Next, the record type was selected – again from a menu. And, finally, the name of the dBase file, from which the records were to be imported, was named.
The actual process of transferring the 5,000-plus records took enough time to allow me to go and have a coffee. But shortly after I returned, all the data had been successfully transferred to Idealist. Within less than an hour a rather old-fashioned system, containing valuable but difficult-to-get-at information, was transformed into a modern, powerful database. Idealist’s search facilities provide a much more effective set of tools for locating and presenting the data held on the publications database.
Idealist can import records directly from files structured in a wide number of formats, including Idealist’s own natural text and database format, dBASE-compatible DBF files, as well as standard formats such as tab or comma separated files. Users can also import records from text files in other formats, by defining a suitable import format file to convert the data into a form which Idealist can understand.
Thus, for example, it should be possible to import data from a property valuation system, manipulate this within Idealist, and then export the results to a spreadsheet for further calculation or the production of charts.
Using Idealist, I also created a small database, consisting of nearly 500 records, containing basic information on the products included in the Estates Gazette’s Information Technology column over the past 10 years. Each record contains fields for ‘topic’, ‘product’, ‘company’, ‘address’, ‘telephone number’ and ‘issue date’.
This information, originally a WordPerfect file, was quickly imported into the Idealist database. The significant point is that, having accomplished this, it is possible to search through the information more effectively than in the word-processing format.
For example, it is possible to retrieve the records for a given company by searching for matches on the company field. Thus, a search for ‘Trace’ generates five records, including both Trace Solutions and their earlier name, Trace Computers. The user may then highlight one of the fields shown in the record structure, say ‘issue date’, and the system will search for records containing the same data as that contained in the field. Almost instantly, therefore, it is possible to determine that Trace Solutions appeared in the EG on October 30 1993, and that on that date there was also coverage of Fraser Williams, Westrade Fairs and Wigwam.
The above examples are intended to illustrate, by reference to a single product, the potential that now exists for linking systems. Space does not permit the comprehensive coverage of other significant developments in this area, such as dynamic data exchange (DDE) and object linking and embedding (OLE) . But the general point can be made that the only barriers that now exist between systems are in the minds of the users.
