Please would you explain what microcomputer databases are, and how they can help the value?
As Francis Bacon said, “Knowledge itself is power”, and it is a short step to reason that knowledge will rest on a base of information. All decision-makers require reliable and accurate information, but the problem today is that facts bombard all of us from every conceivable direction. Only by filtering out the unimportant or irrelevant facts can we reach those that we consider important. Every time we go through this process we are making a value judgment as to which are the most relevant or important to us.
In another sense we might describe certain facts as “useful”, after we know more about the context in which they arise, and it is this distinction between “data” and “information” that is crucial.
“Data” is a name given to any fact, regardless of who might use it or how it might be used. Thus “£750 per m(2)”, “5%”, “£2,000 pa”, are all facts. Many people might ignore such facts at their face value but if we were told “zone A rentals in Reading are currently £750 per m(2)”, “The current market yield on shops is 5%”, or “The full rental value of Furs House is £2,000 pa (FRI)”, then that data is immediately information to the property valuers among us. Information then can be defined in the following terms as “… any form of communication that is both meaningful to the recipient and adds to their knowledge”.(1)
This raises a further point: how useful is the information to us? In a crude analysis it might be argued that information is only useful if the value of the information exceeds the cost. On a purely subjective basis the information might have six qualities to be “useful”. It should be:
- reliable
- accurate
- relevant
- verifiable
- complete
- intelligible
Normally a valuer in the appraisal process would “… be able to provide figures for … (income, operating expenses, and capitalisation rate) … readily, and should be able to substantiate his figures from available analysed data”(2). In general terms, however, the valuer relies very often on either a paper-based record system for deriving, for instance, comparable sales or lettings, or indeed his own “feel” or “experience” (the “man and boy” argument that a number of young valuers may have encountered in negotiation!).
Increasingly, however, there is a demand from clients for the valuer to be more objective in supporting his valuations. The microcomputer (or “micro”) together with a group of software known as database management system packages offer very real benefits to the valuer.
Information systems
We have seen already how important information is to the property valuer. The environment in which data is collected, stored, analysed and output as information can be envisaged in the form of Figure 1. Such an “information system” has been defined as:
“… a set of organised procedures that when executed provide information for decision-making and or control of the organisation. Information is some tangible or intangible entity that reduces uncertainty about a state or event.”(3)
It is a short step to reason from this that a micro together with appropriate software (ie a database management package) could form the heart of a property information system.
Any information system can be paper-based or computerised, although the components remain the same. Moreover, the valuer can be thought of as a decision-maker in that he is ascribing value to a particular property, but in order to do so he will require useful information. Any form of computer, which may be a large, expensive mainframe, a mid-sized mini or a smaller, relatively low-cost micro, could of course replace the manual paper-based system. But in general a micro-computer with appropriate software could offer at a relatively low cost the following benefits to a valuer wishing to set up a property information system:
- compactness: the physical amount of storage space is decreased since magnetic “floppy” discs take up less space than bulky paper files or unwieldy card indexes;
- speed: with the very fast processing times that even micros can achieve the response time of say a clerk or a valuer to find a certain piece of information is diminished;
- less drudgery: because the micro is so much faster the job of finding information by hand becomes less tedious;
- currency and accuracy are increased: with a micro, information update is easier and, in theory, is less error-prone than a manual system.
Of course the existing paper-based system may well be entirely suitable for a small estate agency for example, but as an organisation grows so the information needs of the organisation grow, and many of the larger London-based general practice surveying firms have long found the need to develop large computerised databases.
Very often property information systems are developed on large mainframes in both private and public organisations. An example of the former is St Quintin’s COMPAS system; an example of the latter, Leeds City Council’s LAMIS concept. (For further information see the book by John Kirkwood already referred to.)
Clearly a major component of a property information system is the database: at a lower level — and even within similar large-scale organisations where corporate strategy has perceived a need — microcomputers and database management system packages have given individuals sizeable computing power on their desktops. So it has become comparatively cheap and easy for valuers to set up computerised property databases using DBMS (Database Management System) packages.
What are DBMS packages?
Together with spreadsheets and word processor packages(4), database management systems (DBMS) form the group of software known as “off-the-shelf standalone” packages available for use on micros. Currently the software market has many of these available and by the end of 1983 there were over 100 types marketed for use on the IBM PC and compatibles.
A DBMS package is a package, or a prewritten set of computer instructions, used to perform the same sorts of task that are performed in recording and filing data, which are traditionally carried out on paper files or index cards.
Using a simple analogy, the “database” at the heart of a DBMS can be thought of as a large filing cabinet, in which there will be separate “files”, which in turn contain “records” made up of a collection of “fields”. More of these terms in a moment, but Figure 2 shows the concept in diagrammatic form. Again it must be stressed that the term database could just as easily be used for manual equivalents such as a telephone directory. The differences is the flexibility of defining relationships between data in a microcomputer DBMS compared with manual systems.
Taking a different analogy the term database is derived, fairly obviously, from the words “data” and “base” and like the base of a structure a database can be thought of as a foundation. It is an accumulation of data or a data “pool” from which relevant groups of facts can be caught, to process as information.
Essentially the DBMS software acts as a “layer” between the database itself and the users the system so that it takes care of the instructions to manipulate the data in ways specified by the user.
If we take the example of a busy estate agent’s office, the staff will normally be in the business of matching vendors and purchasers. The DBMS might view, say, the vendors’ register in the following way. The database would be the data on all vendors; “files” might contain properties for sale in a particular street; “records”, the particulars on a certain property in the street and “fields”, such details as address, property type, code, asking price and so on. It is then quite clear that if a potential purchaser arrives at the office then given certain criteria such as price range, locality, house type and size, it would be a straightforward matter to search the database to find properties that matched the criteria, using the micro and its allied software.
A DBMS package should be distinguished from the more traditional and inflexible “file management system” or file handler package. The latter is used primarily for accessing, retrieving and updating existing files, and can only access one file at a time: the links are predetermined for different applications so that, for example, the agency department in a surveying firm might have a file handler for its own data and the investment department its separate file handler for its data — if, of couse, the firm was badly organised!
This is wasteful in terms of the data, which is duplicated in the overall system. For a single purpose, however, in a small surveying practice, a file handler might be of great benefit. Much depends on the scale of operation of the individual firm.
Relational DBMS packages
For larger firms a DBMS overcomes the disadvantage of file handlers by consolidating various independent files into an integrated and flexible structure.
In essence it offers a systematic approach to storing, updating and retrieving information stored as data, and will allow data in one part of a database to be related to another part so that new associations or links can be created at any time to suit a user’s requirements. This is the “relational” aspect of a DBMS package, or the setting up of relationships between different data elements in the database.
Figure 3 shows the three main types of database manipulation that can be carried with a “relational” DBMS. Thus “Select” will form a new file by retrieving records meeting certain criteria. Notice how fields A to H are identical for each file. “Project” would copy certain columns from one file to create a new file. Thus column C might be Address and F, Property Type, for example. Finally, “Join” will enable two files with varying fields to be joined to form a new file, provided that there is a common field, which in Figure 3 is Field A. The user will be able to carry out these operations very quickly and easily by either typing in commands directly at the keyboard or by selecting commands from a “menu”.
In addition to this type of DBMS there are also what are known as “network” and “hierarchical” types which are much less flexible than the relational data model. (See for instance, Date(5)).
The important point to stress here is that the three DBMS types (shown above right) are all “models”, or simplified representations, of how data is “viewed” by DBMS packages, and in this respect it is important to consider the application before deciding on the DBMS with the most appropriate data model.
References:
(1) J Kirkwood (1984), Information Technology and Land Administration (Estates Gazette)
(2) A Baum and D Mackmin (1981), The Income Appraoch to Property Valuation (Routledge Kegan Paul)
(3) H C Lucas Jnr (1985), The Analysis, Design and Implementation of Information Systems (McGraw Hill)
(4) Mainly for Students, Estates Gazette January 11 1986, p79
(5) C Date (1981), An Introduction to Database Systems (Addison Wesley)
