Museo&Web
Planning Kit for a Quality Site for Small and Medium Sized Museums
Inserting a database into a Web Site
This page will explain how to insert an existing database into a Web Site in such a way that the contents are easily accessible and consultable with any browser. This should be independent of the format of the database, of the physical support on which the database is memorised, of the internal structure of the database and of the operative system in which it was created.
It is assumed that the database is already optimised and that its internal organisation is adequate for the aims mentioned. In other words, this document does not demonstrate logical organisation (through entity and relations), nor explain how to structure and optimise the database.
Format of the database is to be taken to mean the format in which the data in the database is memorised. This refers to the software product (RdatabaseMS, Relational Data Base Management System) in which the database was constructed and run.
The level of digital complexity means that to obtain better results, the work should be collaboration between an informatics technician and an expert on contents. The role of the expert in contents is fundamental, especially in the preliminary phase of planning the database and the modes for query and visualisation of the data via the Web Site.
The steps to take and the choices to make in order to insert the database in the Web Site areessentially the following. This is a generalised list and not all steps may be necessary in all cases.
a) Preliminary steps concerning the structure, the format and the complexity of the database
1. Identify the format and the RdatabaseMS used to create the database.
In other words, identify theRdatabaseMS (programme) and format, which were used to create the database. This information serves to understand how the data are to be treated and to help convert the database into a format consistent with the declared aims. It is also important to identify the physical support that contains the database. In the case of old databases the support used for memorising data may be obsolete and hardware for reading it may no longer be commercially available (take for example old 5.25 inch floppy discs, plasmon discs, tapes etc).
2. Understand or decide into what format the database should be converted. In other words, decide feasibility and costs of the above. The choice must take account of the following considerations:
- Ease and simplicity of running the database to regime. In terms of professionals involved; how complex will running the new base be?
- Cost of running the database to regime. How costly will it be to run the database in terms of buying and maintaining appropriate hardware and software, taking into account the option of open source software which is free of licence fees?
- The type of server available for publicising and putting the database on-line.
- The cost of converting data, taking into account point 1 above. If the database is still on old support, the possibility and convenience of converting the data should be carefully evaluated.
- The performance required in order to ensure access to the on-line database in terms of number of simultaneous connections and the speed of response of the web pages. For this operation, the choice is usually reduced to two possibilities, based on the considerations below:
- For databases that are not over-large, are simple to run and easily transportable and maintainable, the best choice lies in products such as Access or Filemaker. The database is in a single file that contains “all the necessary” for functioning: tables, queries, masks for entering and modifying data.
- For medium to large databases and for large professional databases requiring high performance, security, extreme efficiency and where the data must be inter-operable and adhere to standards, the choice lies with products such as SQLServer, MySQL, and Oracle. These products however, have a higher cost in terms of professionals necessary for use/maintenance and higher power of calculus/elaboration necessary for correct functioning.
3. Identify and understand the structure of the database and its complexity.
In other words, know the number of tables that make up the database and the number of relationships between them. This is important in order to decide point 5 below. The structure of the database – number of tables, number and type of relations between the tables, indices, names of tables and fields etc – and its complexity.
4. Convert the database
Convert the database from the original format to the new one. This point varies according to the characteristics of the “original” database and the “new” database. Its complexity may vary greatly from case to case. For example in the case of “complex ” RdatabaseMS (SQL Server, MySQL, and Oracle), importation of data from “minor” databases (Access, Filemaker, Excel) is usually simple and guided step by step. Here, two particular cases are summarised; one important for spreading the products involved (Access) and the other involving an increasingly widespread open source product, MySQL.
4.1 from Access 97 to Access 2000
4.2 from Access 2000 to MySQL
Here, at the end of point a) the database is available and ready for use on a Web Site and we also have a lot of information on its structure. Knowledge of the latter is vital in order to proceed to step b). Real implementation on a Web Site.
b) Inherent operations for access to data of the database
Once the database has been converted to the selected format, the next step is to see how the database will be consulted on the site. This means:
5. Decide the number and type or queries to implement in the site.
Decide the type of questions the users can ask the site. For each query, it is important to decide:
- How to organise the query form: The number and type of fields (input text, combo box, check box etc.). Tools for limiting user error as far as possible must be chosen and implemented. For example, if the user has to choose from a limited number of given options, then a combo box or cascading menu should be used. This allows users to choose only from among limited and given options. An input box, where the text input is free, is therefore more subject to typing and spelling errors.
- How to organise the Results Page. See point 6.
- How to organise the Details page. See point 7.
6. Results page.
Decide which data should be shown and in what form. This is a choice of layout and page layout of the results of the query. The most common formats are:
- Table form: the results page is a table. The results appear in the cells of a table that is formatted into rows and columns. The first row contains the names of the single fields and the other rows contain the corresponding data.
- “Flat” format: each field chosen to be visualised is presented on a new line, preceded by a label of identification.
“Paging” refers to the choice of number of results to be shown per page. The choice should be neither too low (this would result in forcing the user to browse many pages before eventually reaching the desired result) nor too high (this means more work for the server and thus slower page viewing with possible errors in page view)
7. A Details Page with details of the single results.
When the previous results page has a subcollection of all the information extracted as a result of the query, a page with more detailed results can be realised. This solution is appropriate when the amount of information to view is very large and in order to avoid “overloading” the information on the results page. Having found the information they were looking for, users can find more detailed information on the details page. The quantity of information to be viewed and the page layout should be chosen in this case too.
The section “musei e monumenti” of the site of the Direzione generale per il paesaggio, le belle arti, l'architettura e l'arte contemporanee (http://www.pabaac.beniculturali.it) is a good example for points 6 and 7. The following figures refer to this site.
Figure 1. Form for search within a database
http://www.pabaac.beniculturali.it/...
Figure 2. Results page: a search results in a list of monuments
http://www.pabaac.beniculturali.it/opencms/opencms/BASAE/sito-BASAE/MenuPrincipale_BASAE/...
Figure 3. Details page: exhaustive information on each single monument of the search http://www.pabaac.beniculturali.it/opencms/export/BASAE/sito-BASAE/...
c) Implementation
All that remains is to implement the functions of access and consultation of the database via the Web Site. Web Pages should be realised, in appropriate script language, leading to selection and consultation of information present in the database. Here too, the choice of script language implies considerations such as:
- the type of server chosen oravailable for publishing the site,
- the type of RdatabaseMS chosen,
- Considerations related to the cost of buying and running the Web Site and the RdatabaseMS.
d) Maintenance
9. When the database is up and running to regime, i.e. correctly inserted into the Web Site, it will be important to establish policies for regular updating of data, for maintenance of the base of data and for backup/restore.
- Updating means planning if, how frequently, how and with what software tools, the on-line data should be updated.
- Maintenance means planning check controls for consistency of the data and quality of the database.
- Backup/restore means planning periodical copying to avoid loss of data as a result of accident.