27
14.3 Database Management Concepts www.ICT-Teacher.com

14.3 Database Management Concepts:

Embed Size (px)

Citation preview

Page 1: 14.3 Database Management Concepts:

14.3 Database Management Concepts

www.ICT-Teacher.com

Page 2: 14.3 Database Management Concepts:

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.

Page 3: 14.3 Database Management Concepts:

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 organisation’s system around the main database.

Page 4: 14.3 Database Management Concepts:

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).

Page 5: 14.3 Database Management Concepts:

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.

Page 6: 14.3 Database Management Concepts:

Relational Database

Database

DBMSAccounts

Purchasing

Stock Control

Personnel

Marketing

Distribution

Sales

Page 7: 14.3 Database Management Concepts:

Data Approach

Sales Order-Processing

Sales Program

DistributionDistribution

Program

SalesData

Distribution Data

Page 8: 14.3 Database Management Concepts:

The Database Administrator

• The person in overall responsibility for the organisation’s 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.

Page 9: 14.3 Database Management Concepts:

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.

Page 10: 14.3 Database Management Concepts:

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.

Page 11: 14.3 Database Management Concepts:

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.

Page 12: 14.3 Database Management Concepts:

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.

Page 13: 14.3 Database Management Concepts:

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 Vet’s practice is shown below:

Entity: Identifier:VET Surname.OWNER Identification initials/number.PET Name and customer’s identification.DRUGS Code on label.

Page 14: 14.3 Database Management Concepts:

Ensure that you use the standard notation for your Entities.PET

PetID Vet OwnerID Animal IllnessTigerDJ830 Sammuels DJ830 Cat FluRexBY56 Higgins BY56 Dog Broken LegTimmyHF Sammuels HF44 Hamster 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.

Page 15: 14.3 Database Management Concepts:

Linked Entities

Pet

Owner

Illness

Vet

Page 16: 14.3 Database Management Concepts:

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.

Page 17: 14.3 Database Management Concepts:

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.

Page 18: 14.3 Database Management Concepts:

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.

Page 19: 14.3 Database Management Concepts:

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,BookCategory)

Page 20: 14.3 Database Management Concepts:

The Student and Loan Tables

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

Page 21: 14.3 Database Management Concepts:

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

Page 22: 14.3 Database Management Concepts:

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.

Page 23: 14.3 Database Management Concepts:

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.

Page 24: 14.3 Database Management Concepts:

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 )

Page 25: 14.3 Database Management Concepts:

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)

Page 26: 14.3 Database Management Concepts:

Entity Diagram

STUDENT

TUTOR

LOAN

BOOK

Page 27: 14.3 Database Management Concepts:

• Pages:

• Doyle: 261 - 269.• Heathcote: 300 - 313.

• Activities: 262, 263, 266.