14.3 database management concepts:
TRANSCRIPT
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 organisation’s 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
DBMSAccounts
Purchasing
Stock Control
Personnel
Marketing
Distribution
Sales
Data Approach
Sales Order-Processing
Sales Program
DistributionDistribution
Program
SalesData
Distribution Data
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.
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 Vet’s practice is shown below:
Entity: Identifier:VET Surname.OWNER Identification initials/number.PET Name and customer’s identification.DRUGS Code on label.
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.
Linked Entities
Pet
Owner
Illness
Vet
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,BookCategory)
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).
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
TUTOR
LOAN
BOOK
• Pages:
• Doyle: 261 - 269.• Heathcote: 300 - 313.
• Activities: 262, 263, 266.