A-Level ICT (Paperback)
by P.M. Heathcote (Author)Review:
Chapter 17 - Introduction to database systems . Most of the material is OK - but it is very brief. I disagree with the section called Flat File - p92. I quote from the book "A flat file is a database held in a single file." This is rubbish. Hierarchical databases used to be stored in a single file. In deed it is possible to store a network database entirely in a single file - but this would be undesirable for performance issues. Multi-user databases typically are store in several files on separate disk-drives to minimize bottlenecks of dataflow. My understanding of a flat file is to do with the structure of the data. Tables are flat, so relational databases are flat regardless of whether they are stored in one file or many. There seems to be a confusion between tables and files. I think the author is referring to multi-table databases and comparing them with single table databases or traditional file systems that have a simple record structure.
Chapter 18 - Relational Databases. Not much is said about what a relational database is, other than data is stored in tables. Then there follows two bad examples that are discussed. The first is a library database, with a description of what is required. Then it is stated that there are two obvious entities BORROWER and BOOK. There is no mention here made about what an entity is. This example continues in chapter 56 (page 304) and entities are mentioned in chapter 55 (page 301). It looks as if this book has been written by using cut and paste - some of the material being pasted in the wrong place.
Chapter 19 - Tables, forms, queries and reports. The material here is not too bad, but very brief. I would expect that the teacher would have to supply extra material, or a book on Access etc would have to be used. There is however an awful mistake, Figure 19.7 - a relationship diagram suggests a one-one relationship between two of the tables. I think that this should be a one-many relationship as well. In any case there is no point having one-one relationships, you could have combined the two tables - that would have been better.
Chapter 55 - Data modelling. This chapter talks about traditional file systems compared with database systems. It mentions program-data independence, but fails to mention logical data independence. Much of the material on the database approach is far too brief and lacks examples. There is a brief section on ER modelling. Here the types of relationship are mentioned and an example diagram included. There are however no pointers at to how you arrive at such a diagram. That is, any sort of design methodology is missing.
Chapter 56 - Relational Database design. This is the chapter where I found the most fault. Here we have an ER diagram wiith two tables - BORROWER and BOOK. There should be a many-many relationship here because a borrower can borrow many books and a book can be borroed by many people. Normalisation should be spelt Normalization(See Oxford Dictionary of computing 3/e p307). The definition for first normal form is bad (page 305) "A table is in first normal form if it contains no repeating attributes or groups of attributes. This is wrong. A table must be in first normal form by definition - otherwise what you have is not a table. The standard definition for first normal form is "A table is in first normal form if and only if all attributes are atomic - that is all attributes have a single value. This definition causes problems for the example on page 306. I would say that this table is in first normal form provide that the primary key is studentnumber, coursenumber. Then all you need to do is duplicate data, where there are blanks. The definitions and examples for second and third normal forms are also poor. I particular, there is a complete absence of functional dependencies - the standard tool used to determine how to partition tables into second and third normal form.
Chapter 57 - Database Management. The section on the role of a DBA is weak. Quite commonly a DBA has nothing to do with the database design, though it will be necessary for them to understand it for reasons of maintenance. Section 11 mentions "Keeping users informed of changes in the database structure". This is complete rubbish. Users should be protected from changes because of data-independence. In particular all queries should use a View - Corresponding to the conceptual level or user level of the database. Another reason why you wouldn't want users to be informed about the structure or changes to the database would be reason of security. The rest of the chapter briefly mentions The data dictionary, The DBMS, Querying the database, using SQL, and Client-server database but with insufficient depth to be of any use.
14 - allocating password to each user. This will be done by the System manager. They will need this to log on to the computer, regardless of whether they will use the database. Access rights of the database are then based on usernames already given out.
Your comments?
No comments:
Post a Comment