DITA Session 3: Databases, YAY.


In week 3 our DITA session was focused on 'Structuring and querying information stored in databases'.


At first I found it hard to grasp the relevance of this topic, which may sound strange as of course databases and information retrieval are central to the role of an information professional and revolutionized the organization, management and storage of data. But when we got onto the exercises for the session I became a bit confused at the nature of the SQL querying language that we used to interrogate the database. I mean, I understood the concept of what we were doing, but I couldn't see how to apply this in the real world, as all the databases I use at work are much simpler to operate - less picky about the terms you enter! So the next day when i got to work (in a corporate law library) I asked my (only) colleague if she had had any experience with SQL  and database querying, and she gave me a very interesting insight into the development of the legal information databases that we use in our library, and how methods for querying them have changed over time. She said that when she started in librarianship in the mid 90s, it was necessary to interrogate databases using all the operators that I had experienced the day before in the practical exercise. So after that I had a bit more of an idea of how SQL fits into the information world.

Background:

Evolution from the File Approach to the Database Approach:

With the advent of computers into organizations in the 50s and 60s, data began to be stored in files, with different departments controlling different files of data. Often this lead to the duplication of data and meant that data representation was not standardized across departments. Another disadvantage of this approach was 'program-data dependency' whereby the physical structure and storage of the data files and records are defined in the application program, meaning that a change to the storage structure of a file cannot be made without also changing the application program.

The limitations of the File Based approach led to the development of databases and database management systems (DBMS). A database is defined by Connolly and Begg (2010) as: 'A shared collection of logically related data and its description, designed to meet the information needs of an organization.'  This definition highlights the communal nature of databases that makes them so successful. Instead of isolated files full of data, databases hold centralized records of data that can be managed uniformly and efficiently.

Relational databases:

This software represents the second generation of DBMSs (the first being network and hierarchical; good description can be found here :http://www.theukwebdesigncompany.com/articles/types-of-databases.php). Relational databases allow information from different tables of data to be searched simultaneously in order to respond to user queries with relevant data. Relational databases are made up of tables (relations) which each have their own names, and are made up of named columns (attributes) of data, and rows (tuples) which contain one value per column. Relational databases can be linked together using 'keys'. A primary key in a table is used to uniquely identify a row in that table. A foriegn key can be inserted into a table, and will represent the primary key of a different table. This is useful as it means that if table A is updated and its data is represented by a foriegn key in table B, it will not be necessary to update all the records in table B.