14.

3 Database Management Concepts

www.ICT-Teacher.com

Objectives
Explain the purpose of a database management system (DBMS). Explain the role of the database administrator. Explain what is meant by data consistency, data integrity, data redundancy and data independence. Describe what is meant by entity relationships and data normalisation.

Data Management
Almost all organisations hold data and it is kept using database software. Data is structured in a way that makes it easy to find the answers to searches. Databases may be flat file or relational. Some specialist software will run the organisations system around the main database.

Database Management System

Hold structured data. Allow the users to create their own style. Allow related entities to be linked together. Data is stored separately from the programs. Data Description Language (DDL), specifies the data to be used in the database. Data Manipulation Language (DML), accesses the required data from the database. Access is by setting up queries using the Structured Query Language (SQL).

Relational DBMS
Allows:
A database to be defined, Users may query (search) the database, Data may be added, amended or deleted, The table structure may be changed upgraded, Data may be imported and exported to other applications, A security system to allow only authorised access.

Relational Database
Database
Accounts DBMS
Purchasing Marketing

Personnel

Stock Control Sales

Distribution

Data Approach

Sales Order-Processing

Sales Program

Sales Data

Distribution

Distribution Program

Distribution Data

The Database Administrator

The person in overall responsibility for the organisations database. Responsibilities include:
The creation and design of the database, Monitoring the performance and adjusting where needed, Keeping staff informed about changes, Controlling the access rights for individuals, including passwords, Maintaining a data dictionary, standardised names and labels, Ensuring the staff have adequate training in its use.

Data Dictionary
The data dictionary should include:
The names of all tables and fields included in the database, The type of each piece of data including length, Validations and restrictions on data, Explanations of data fields that have complicated names, Relationships between tables and key fields, The programs that access the data and the programs that can amend the data.

Data Consistency
The same data may be found in different files, this could be a problem during updating as all the files need to be updated. If the data only appears in one file and other files are linked to that file then the updating need only be done once.

Data Integrity
Data in the database has to be correct, if it is found not to be so then the system may not be useful. Some errors are:
Transcription, typing errors, careful checking is needed in entering and copying data details, Verification; a second check on data entry, Validation; by data type checks, range checks, Regular updating of new and amended data, Correct operating procedures; and older file being used to update a newer file etc.

Data Redundancy
The database once created should be available to all interested parties within the organisation. Departments may like their own copies of data held on the database but work done on these files also needs to be repeated on the main file. Data constantly being repeated is redundant data.

Entity Relationship
The linking of two tables together by means of a common field.
Tables and Normalisation:
Show your Entity relationship diagrams, an example of a Vets practice is shown below: Entity: VET OWNER PET DRUGS Identifier: Surname. Identification initials/number. Name and customers identification. Code on label.

Ensure that you use the standard notation for your Entities. PET PetID TigerDJ830 RexBY56 TimmyHF Vet Sammuels Higgins Sammuels OwnerID DJ830 BY56 HF44 Animal Cat Dog Hamster Illness Flu Broken Leg Unknown

The standard notation for the table Pet is: PET (PetID, Vet, OwnerID, Animal, Illness) PET is the entity name. PetID is the primary key or unique identifier. Vet, OwnerID, Animal, Illness are the attributes. Vet, OwnerID and Illness are in italics as they are both key fields in another table.

Linked Entities
Illness

Pet

Vet

Owner

Student Book Loans from a Library

Consider the following scenario where students take out book loans from a College library:
Each student has a unique ID, and have a personal tutor who is identified by a three letter code. Every book has a unique book ID, and the title and category are recorded. When a loan is made the details of the student and the book are recorded and the loan is either for two weeks (the normal period) or for a day (called a short term loan). The date of the loan is recorded. The loan type is determined by the particular book; some books are normal loan, some are short-term only.

Un-normalised Form
A first attempt at setting up a database for this data has all the attributes in a single table called STUDENT as follows: STUDENT (StudentID, StudentName, TutorID, TutorName,
BookID1, IssueDate1, LoanType1, BookTitle1, BookCategory1, BookID2, IssueDate2, LoanType2, BookTitle2, BookCategory2, BookID3, IssueDate3, LoanType3, BookTitle3, BookCategory3, BookID4, IssueDate4, LoanType4, BookTitle4, BookCategory4)

The table will allow for up to four loans to be made by each student.

First Normal Form (1NF)

"There must be no repeated groups of attributes". These attributes must be taken to a new table: The group of attributes BookID, IssueDate, LoanType, BookTitle, BookCategory are repeated and so must be removed and made into a new table.

Loan Table
LOAN
(BookID,IssueDate,LoanType,BookTitle,BookCategory)
The original table leaves:

STUDENT
(StudentID,StudentName,TutorID,TutorName) The problem we have is that the LOAN data does not record which student made each loan, so the LOAN table is revised to show:

LOAN
(StudentID,BookID,IssueDate,LoanType,BookTitle,Book Category)

The Student and Loan Tables

Relationship 1 One STUDENT will take out many LOANs. Primary key StudentID (in the STUDENT table) links to a foreign key of StudentID (in the LOAN table).

Second Normal Form (2NF)

The second process we have to check is that: "For a table which has a composite primary key, there are no non-key attributes which depend only on knowing part of the primary key". LOAN table has a 'composite' primary key? List each non-key attribute, and suggest which parts of the primary key need to be known for its value to be clear. The 'non-key' attributes in this table are: LoadType, BookTitle, BookCategory

Non Key Attributes

The conclusion is that the LOAN table is not in second normal form, since there are three non-key attributes which could be determined by knowing only the BookID attribute value in the primary key.

Book Table
The solution is to create from the LOAN table, a new table BOOK. STUDENT (StudentID,StudentName,TutorID,TutorName )

LOAN (StudentID,BookID,IssueDate )
BOOK ( BookID, BookTitle, BookCategory ) Relationship 2 There must be a new relationship between the LOAN and BOOK tables.

Third Normal Form (3NF)

There is a final rule which has to be checked. "There must be no non-key attributes where there is a dependency between them". Consider the STUDENT table. STUDENT( StudentID, StudentName, TutorID )

Tutor Table
But, there is a dependency between them since if we know the StudentName attribute, we shall automatically know the value for the TutorID attribute. The answer again is to create a new table: STUDENT (StudentID, StudentName, TutorID) LOAN (StudentID, BookID, IssueDate) BOOK (BookID, BookTitle, LoanType) TUTOR (TutorID, StudentID)

Entity Diagram
STUDENT BOOK

LOAN

TUTOR

 Pages: Doyle: Heathcote: Activities: 261 - 269. 300 - 313. 262, 263, 266.