Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha...
Transcript of Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha...
![Page 1: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/1.jpg)
Database Design Concepts C_ITDB211
![Page 2: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/2.jpg)
Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa
Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri
Edited by Isobel Coetzee
Version 1.0
NQF Level 5
Credit value: 12
November 2015 CTI Education Group
![Page 3: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/3.jpg)
TABLE OF CONTENTS
INTRODUCTION .......................................................................................................... 1
Summary of learning outcomes and assessment criteria ............................................... 2
Study Guide alignment ............................................................................................. 8
UNIT 1 – DATABASE FUNDAMENTALS ......................................................................... 9
1.1.1 Database uses ............................................................................................ 10 1.1.2 Physical and logical views of databases ......................................................... 11 1.1.3 Using relational database tables ................................................................... 11 1.1.4 Processing relational database tables ............................................................ 12 1.1.5 The database environment ........................................................................... 12
1.2.1 Database component .................................................................................. 14 1.2.2 DBMS component ....................................................................................... 16 1.2.3 Database application component .................................................................. 18 1.2.4 Common DBMS data types ........................................................................... 19 1.2.5 Personal vs enterprise-class database systems ............................................... 19 1.2.6 Data diagrams ............................................................................................ 21
1.3.1 Relations ................................................................................................... 22 1.3.2 Types of key .............................................................................................. 23
1.4.1 Functional dependency ................................................................................ 26 1.4.2 Normalisation ............................................................................................. 26
UNIT 2: DATABASE DESIGN ...................................................................................... 30
2.1.1 Database development stages ...................................................................... 31 2.1.2 Structured Systems Analysis and Design Method (SSADM)............................... 34 2.1.3 Agile Software Development methodology ..................................................... 34 2.1.4 Rapid Application Development (RAD) methodology ........................................ 35 2.1.5 Spiral methodology ..................................................................................... 35 2.1.6 Waterfall methodology ................................................................................ 36
2.2.1 ER Data Model ............................................................................................ 36
Module aim ........................................................................................................... 1 Module abstract .................................................................................................... 1 Learning outcomes and assessment criteria ......................................................... 2
Module content ..................................................................................................... 3 Lectures................................................................................................................ 3 Class exercises and activities ............................................................................... 4 Information resources .......................................................................................... 4 Recommended information sources ...................................................................... 4 Using this Study Guide ......................................................................................... 5 Purpose ................................................................................................................ 5 Structure .............................................................................................................. 6 Individual units .................................................................................................... 6 Glossary ............................................................................................................... 7 The use of icons .................................................................................................... 7 Alignment to Study Guide ..................................................................................... 8
Concluding remarks .............................................................................................. 8
Learning objectives .............................................................................................. 9 Introduction ......................................................................................................... 9 1.1 Introduction to databases ...................................................................... 10
1.2 Database systems ................................................................................... 13
1.3 Relational Model ..................................................................................... 22
1.4 Functional dependency and normalisation .............................................. 26
1.5 Concluding remarks ................................................................................ 28 1.6 Self-assessment ..................................................................................... 28
Learning objectives ............................................................................................ 30 Introduction ....................................................................................................... 30 2.1 Database design methods and methodologies ........................................ 31
2.2 Relational database design: ER modelling .............................................. 36
![Page 4: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/4.jpg)
2.2.2 ER diagrams .............................................................................................. 41 2.2.3 Sub-type entities ........................................................................................ 45 2.2.4 Recursive relationships ................................................................................ 46 2.2.5 Developing ER diagrams .............................................................................. 46
2.3.1 Normalisation process ................................................................................. 52 2.3.2 Transforming data models into relational design ............................................. 55 2.3.3 Normalisation review ................................................................................... 56 2.3.4 Denormalisation ......................................................................................... 57 2.3.5 Developing database design ......................................................................... 63
UNIT 3 – DATABASE DEVELOPMENT ......................................................................... 69
3.2.1 Creating a database .................................................................................... 71 3.2.2 Showing a database .................................................................................... 73 3.2.3 Selecting a database ................................................................................... 74 3.2.4 Deleting a database .................................................................................... 74 3.2.5 MySQL data types ....................................................................................... 75 3.2.6 Creating a table .......................................................................................... 76 3.2.7 Showing a table .......................................................................................... 78 3.2.8 Describing a table ....................................................................................... 80 3.2.9 Entering data into a table: Form Editor .......................................................... 81 3.2.10 Entering data into a table: Datasheet View .................................................... 82 3.2.11 Deleting data from a table: Datasheet View ................................................... 82 3.2.12 Altering table structure ................................................................................ 83 3.2.13 Working with multiple tables ........................................................................ 84 3.2.14 Working with multiple tables: Relationships Window ....................................... 85 3.2.15 Adding a table: Relationships Window ........................................................... 86 3.2.16 Creating a relationship: Relationships Window ................................................ 86 3.2.17 Working with multiple tables: Edit Relationships Window ................................. 87 3.2.18 Accessing a table: Form Editor ..................................................................... 88
3.3.1 MySQL background ..................................................................................... 88 3.3.2 SQL for data definition................................................................................. 88 3.3.3 Creating a database .................................................................................... 90 3.3.4 Showing a database .................................................................................... 91 3.3.5 Selecting a database ................................................................................... 91 3.3.6 Creating a table .......................................................................................... 92 3.3.7 Showing and describing a table .................................................................... 92 3.3.8 Creating a MySQL table ............................................................................... 93 3.3.9 Relational data ........................................................................................... 97 3.3.10 Relational queries ....................................................................................... 97 3.3.11 Comparison operators ............................................................................... 103 3.3.12 Sorting a query result ............................................................................... 104 3.3.13 Built-in functions and calculations ............................................................... 104 3.3.14 Built-in functions and grouping ................................................................... 105 3.3.15 Querying multiple tables with joins ............................................................. 106 3.3.16 Relational data modification and deletion ..................................................... 107 3.3.17 Table and constraint modification and deletion ............................................. 109 3.3.18 SQL views ................................................................................................ 110
UNIT 4 – DATABASE MANAGEMENT ........................................................................ 113 4.1.1 Responsibilities ......................................................................................... 114
2.3 Relational database design: normalisation ............................................. 52
2.4 Concluding remarks ................................................................................ 67 2.5 Self-assessment ..................................................................................... 68
Learning objectives ............................................................................................ 69 Introduction ....................................................................................................... 69 3.1 MySQL 5.6 database software ................................................................. 70 3.2 MySQL GUI.............................................................................................. 70
3.3 MySQL CMD ............................................................................................. 88
3.4 Concluding remarks .............................................................................. 112 3.5 Self-assessment ................................................................................... 112
![Page 5: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/5.jpg)
4.1.2 Database processing environment I ............................................................ 114 4.1.3 Concurrency control .................................................................................. 115 4.1.4 Security ................................................................................................... 122 4.1.5 Backup and recovery ................................................................................. 124
4.2.1 Database processing environment II ........................................................... 127
4.3.1 Application programming interfaces (APIs) ................................................... 129 4.3.2 N-tier architecture .................................................................................... 129
4.4.1 Object-relational database management ...................................................... 131
GLOSSARY .............................................................................................................. 134 BIBLIOGRAPHY ...................................................................................................... 137
Learning objectives .......................................................................................... 113 Introduction ..................................................................................................... 113 4.1 Database administration ....................................................................... 114
4.2 Database applications processing ......................................................... 127
4.3 Internet applications processing .......................................................... 128
4.4 Distributed database processing ........................................................... 130
4.5 Concluding remarks .............................................................................. 132 4.6 Self-assessment ................................................................................... 132
![Page 6: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/6.jpg)
Introduction Page 1
© CTI Education Group
Introduction
This module covers relational database structures, intermediate database design, management and administration using MySQL. The normalisation
principle is explored in great depth and forms the basis of designing relational databases in this module. The normalized data is to be transformed into an
Entity Relationship diagram (ERD) and translated in physical tables. All concepts taught are translated into practice using MySQL. This module’s scope
builds up to other modules. The concepts taught enable the student to design a database that can be used to interact with other third party applications. The
module scope basically introduces students to practical interaction with the application using the command line interface. This module focuses more on a
client-server topology. It also explores how MySQL functions in Graphics User
Interfaces (GUIs) and command line interfaces (CMDs); these are based on generic Structured Query Language (SQL) and will thus only differ in syntax.
Upon completion of this module, you should be equipped with strong MySQL, database design and database development skills.
The main source of information for Database Design Concepts is this Study
Guide.
In this introductory unit, we provide you with the following information on Database Design Concepts:
A brief description of the aim of the module
An abstract of the module The learning outcomes and assessment criteria involved in the module
An outline of the module content
An outline of the module structure An explanation of the design and proper use of the Study Guide
Module aim
The aim of this module is to afford you the opportunity to develop an understanding of the concepts and issues related to databases and database
design as well as the practical skills to translate such an understanding into the
design and creation of complex databases.
Module abstract
Databases play an integral part in commercial domains as they provide users
with a tool in which to store, model and retrieve data. Database development is fundamental in the areas of computing and Information and Communication
Technology (ICT). Database Management Systems (DBMSs) provide the
systems, tools and interfaces with which an organisation can manage their information and use to assist in the effective running of said organisation.
Databases offer many links to other areas, such as programming, systems
![Page 7: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/7.jpg)
Introduction Page 2
© CTI Education Group
analysis and Human Computer Interaction (HCI); they also embrace issues of compatibility and end user interfacing.
This module also explores database architecture, DBMSs and the use of
databases in organisational contexts. Database design techniques are investigated and successful students will be able to apply their theoretical
understanding to design, create and document a database system.
Learning outcomes and assessment criteria
On successful completion of this module, you will:
1. Discuss the role, purpose and use of databases and data management systems.
2. Identify and explain database design techniques and principles 3. Design, create and document databases
The following table outlines the assessment criteria that are aligned to the
learning outcomes.
Summary of learning outcomes and assessment criteria
Learning outcomes Assessment criteria to pass
On successful completion of
this module, you will: You can:
1. Discuss the role purpose and
use of databases and data
management systems.
1.1 Analyse the key issues and applications of
databases within an organisational environment
1.2 Evaluate the features and advantages of database
management systems
2. Identify and explain database
design techniques &
principles
2.1 Analyse a database developmental methodology –
normalization and ERD
2.2 Apply relation database design for a given data set
(3NF/ERD)
3. Design, create and document
databases
3.1 Apply the database developmental cycle to a given
data set
3.2 Design a fully functional database (containing at
least four interrelational tables) including user
interface
3.3 Provide supporting user and technical
documentation
These outcomes are covered in the module content and are assessed in the
form of written assignments and semester tests. If you comply with and achieve all the pass criteria related to said outcomes, you will pass this
module.
Learning and assessment may be performed across modules, at module level or at outcome level. Evidence may be required at outcome level, although
opportunities exist for covering more than one outcome in an assignment.
![Page 8: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/8.jpg)
Introduction Page 3
© CTI Education Group
Module content
1. Discuss the role purpose and use of databases and data
management systems Databases: database architectures; files and record structures; physical and logical views of data; advantages of using databases; reduction of data
redundancy; data consistency (validity, accuracy, usability and integrity); independence of data; data sharing possibilities; security; enforcement of
standards; database utilities; data dictionaries; query languages and report generators.
Databases in an organisational context: database applications; role of the
database administrator; key organisational issues e.g. integrity, security,
recovery, concurrency; industry standards e.g. Microsoft SQL, Oracle, Sybase and dBase.
Database Management Systems (DBMS): structures; purposes; features and
advantages; applications; methods of data organisation and access.
2. Identify and explain database design techniques & principles Database design methods and methodology: database design within a system
development methodology – normalisation practical to third normal form and Entity Relationship modelling/ERD.
Relational database design: logical tables design; physical table design; relations and primary/foreign/compound keys.
3. Design, create and document databases Database development cycle: developing logical data model; implementing a physical data model based on the logical data model; testing the physical data
model; comparing model with requirements analysis; user interface e.g. input masks, drop-down lists, option buttons and command buttons.
Database software: using appropriate applications software, MySQL; database
tools e.g. create tables, add new rows, alter data, functions, and relational
database languages.
Tools and techniques: field and table design; validation and verification techniques; forms including such features as dropdown lists or check boxes;
reports; queries; macros.
Documentation: technical documentation and user documentation.
Lectures
Each week has four compulsory lecture hours for all students. It is recommended that the lecture hours be divided into two sessions of two
hours each, but this may vary depending on the campus.
![Page 9: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/9.jpg)
Introduction Page 4
© CTI Education Group
Each week has a lecture schedule, which indicates the approximate time that
should be allocated to each activity. The week’s work schedule has also been divided into two lessons.
Class exercises and activities
You will be required to complete a number of exercises and activities in class.
These activities and exercises may also contribute to obtaining a pass, therefore, it is important that you are present in class so that you do not forfeit
the opportunity to be exposed to these exercises and activities.
Activity sheets that are submitted should be kept by the lecturer so that they can be used as proof of criteria that were met, if necessary.
Information resources
You should have access to a resource centre or library with a wide range of
relevant resources. Resources can include textbooks, e-books, newspaper articles, journal articles, organisational publications, databases, etc. You can
access a range of academic journals in electronic format via EBSCOhost. You may have to ask a campus librarian to assist you with accessing EBSCOhost.
Recommended information sources
Avison, D. & Fitzgerald, G. 2006. Information systems development:
methodologies, techniques and tools. London: McGraw Hill Higher Publishing.
Chao, L. 2006. Database development and management. Boston: CRC Press.
Connolly, T. & Begg, C. 2015. Database Systems: A Practical Approach to Design, Implementation and Management.6TH ed.Pearson.ISBN:
9780132943260.
Hoffer. J. et al. 2014. Essentials of Database Management. Pearson.
Howe, D. 2001. Data analysis for database design. Massachusetts:
Butterworth-Heinemann.
Jukic, N. 2014. Database Systems: Introduction to Databases and Data Warehouses. Pearson.
Kroenke, D. 2014. Database Processing. Pearson.
Patrick, J.J. 2009. SQL Fundamentals. Pearson Education.
Ritchie, C. 2002. Relational database principles. London: Thomson Learning.
![Page 10: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/10.jpg)
Introduction Page 5
© CTI Education Group
Anon., 2015. deeptraining.com. [Online]
Available at: http://www.deeptraining.com/ [Accessed 01 October 2015].
Anon., 2015. w3resource. [Online]
Available at: http://www.w3resource.com/mysql-exercises/ [Accessed 1 October 2015].
Sebastian, 2014. Database Design Guide. [Online]
Available at: http://www.smart-it-consulting.com/database/progress-database-design-guide/
[Accessed 01 October 2015].
Vines, R., 2015. geekgirl's. [Online]
Available at: http://geekgirls.com/category/office/databases/ [Accessed 01 October 2015].
Note
Web pages provide access to a further range of Internet information sources.
Students must use this resource with care, justifying the use of information gathered.
Using this Study Guide
As indicated earlier, the Study Guide is your main source of information for this module.
The purpose of the Study Guide is to facilitate your learning and to help you to
master the module content. It also helps you to structure your learning and
manage your time, and provides outcomes and activities to help you master said outcomes.
The Study Guide has been carefully designed to optimise your study time and
maximise your learning, so that your learning experience is as meaningful and successful as possible. To deepen your learning and enhance your chances of
success, it is important that you read the Study Guide attentively and follow all instructions carefully. Pay special attention to the module outcomes at the
beginning of the Study Guide and at the beginning of each unit.
It is essential that you complete the exercises and other learning activities in the Study Guide as your module assessments (examinations, tests and
assignments) will be based on the assumption that you have completed them.
Purpose
The purpose of the Study Guide is to facilitate the learning process and to help you to structure your learning and to master the content of the module. It is
important for you to work through the Study Guide attentively and to follow all
![Page 11: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/11.jpg)
Introduction Page 6
© CTI Education Group
instructions set out therein. In this way you should be able to deepen your learning and enhance your chances of success.
Structure
The Study Guide is structured as follows:
Introduction
Unit 1 Database fundamentals
Unit 2 Database design
Unit 3 Database development
Unit 4 Database management
Glossary
Bibliography
Individual units
The individual units in the Study Guide are structured in the same way. Each unit contains the following features, which should enhance your learning
process:
Unit title
Each unit title is based on the title and/or content of a
specific learning outcome or Assessment Criterion/Criteria as
discussed in the unit.
Learning outcomes and
assessment criteria
The unit title is followed by an outline of the learning
outcomes and assessment criteria, which will guide your
learning process. It is important for you to become familiar
with the learning outcomes and assessment criteria as they
represent the overall purpose of the module as well as the
end product of what you should have learnt in the unit.
Learning objectives
Learning objectives, which follow the learning outcomes and
assessment criteria, are statements that define the expected
goals of the unit in terms of specific knowledge and skills
that you should acquire as a result of mastering the unit
content. Learning objectives clarify, organise and prioritise
learning and help you to evaluate your own progress,
thereby taking responsibility for your learning.
Introduction The learning objectives section is followed by an introduction
that identifies the key concepts of the unit.
Content
The content of each unit contains the theoretical foundation
of the module and is based on the work of experts in the
field of the module. Theory is illustrated by means of
relevant examples.
Concluding remarks
The concluding remarks at the end of each unit provide a
brief summary of the unit as well as an indication of what
you can expect in the following unit.
Self-assessment
The unit ends off with a number of theoretical self-
assessment questions that test your knowledge of the unit
content.
![Page 12: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/12.jpg)
Introduction Page 7
© CTI Education Group
Glossary
As you will see, we include a glossary at the end of the Study Guide. Please
refer to it as often as necessary in order to familiarise yourself with the exact meaning of terms and concepts.
The use of icons
Icons are used to highlight (emphasise) particular sections or points in the
Study Guide, to draw your attention to important aspects of the work or to highlight activities. The following icons are used in the Study Guide:
Activity This icon indicates learning activities/exercises that have to be
completed, whether individually or in groups, in order to assess (evaluate) your understanding of the content of a particular
section.
Definition
This icon appears when definitions of a particular term or concept are given in the text.
Example This icon points to a section in the text where relevant
examples of a particular topic (theme) or concept are provided.
Learning outcome alignment
This icon is used to indicate how individual units in the Study Guide are aligned to a specific outcome and its assessment
criteria.
Supplementary reading This icon indicates that you are expected to do some additional
(supplementary) reading – i.e. you should obtain additional information by consulting relevant, external information
sources.
Test your knowledge This icon appears at the end of each unit, indicating that you
are required to answer self-assessment questions to test your knowledge of the content of the foregoing unit.
![Page 13: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/13.jpg)
Introduction Page 8
© CTI Education Group
Alignment to Study Guide
The following table reflects the alignment between the learning outcomes,
assessment criteria and units in the Study Guide.
Study Guide alignment
Learning outcomes Assessment criteria Study Guide
unit
1. Discuss the role
purpose and use of
databases and data
management systems
1.1 Analyse the key issues and application
of databases within organisational
environments 1
1.2 Evaluate the features and advantages
of database management systems
2. Identify and explain
database design
techniques and
principles
2.1 Analyse a database developmental
methodology – normalization and ERD 2
2.2 Apply relation database design for a
given data set (3NF/ERD)
3. Design, create and
document databases
3.1 Apply the database developmental life
Cycle to a given data set
2 and 3 3.2 Design a fully functional database
(containing at least four inter-relational
tables), which includes a user interface
3.3 Provide supporting user and technical
documentation 4
Concluding remarks
At this point, you should be familiar with the module design and structure as well as with the use of the Study Guide.
In Unit 1, we start with the actual module content by exploring database
fundamentals.
![Page 14: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/14.jpg)
Unit 1 – Database fundamentals Page 9
© CTI Education Group
Unit 1 – Database fundamentals
Unit 1 is aligned with the following learning outcome and assessment criteria:
Learning outcome
LO1 Discuss the role purpose and use of
databases and data management systems
Assessment criteria
AC1.1 Analyse the key issues and applications of databases within an organisational environment
AC1.2 Evaluate the features and advantages of database management systems (DBMSs)
Learning objectives
After studying this unit, you should be able to: Understand the reasons for using databases
Identify the potential problems associated with lists Understand how using related tables helps to avoid the problems
associated with lists Know the components of database systems
Know the purpose of DBMSs
Understand the functions of database applications Understand the conceptual foundation of the Relational Model
Understand the meaning and importance of keys Apply the process of normalisation
Introduction
In this unit, we focus on databases and their role in maintaining information.
We discuss key database design concepts, which form an integral part of storing and retrieving data optimally. We conclude the unit by exploring DBMSs
and how these are applied by databases designers.
Activity
Before we define databases, write down what you think a database is and give examples of where databases are used.
![Page 15: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/15.jpg)
Unit 1 – Database fundamentals Page 10
© CTI Education Group
1.1 Introduction to databases
Database A database is a collection of related information that is organised
so that it can be easily accessed, managed and updated.
Relational (tabular) databases are the most popular as they allow data to be
reorganised and accessed in different ways.
In computing, databases are often classified according to a company’s
approach. Modern applications, such as MySQL and Structured Query Language (SQL) Server, have become popular database tools.
A database is, generally, not portable across different DBMSs, however,
different DBMSs can operate in unison to some extent by using standards, such as SQL and Open Database Connectivity (ODBC), to support a single
application.
1.1.1 Database uses
Databases are used extensively in our day-to-day lives. By using such, items
can be easily tracked, for example, valuable items listed on lists. Lists, in turn, can be split into tables, which are a key component of databases.
Example A list of projects may include the project manager’s name,
identity (ID) and telephone extension. If a particular person is managing ten projects, their information would have to be
entered ten times.
In a list, each row could contain information on more than one theme. A list of projects may thus include the project manager’s
information (name, ID and telephone extension) as well as the project’s information (name, ID, start date and budget).
The advantages of using lists are:
They are simple to design. Entries can be sorted, e.g. alphabetically.
Data can easily be changed.
Spreadsheets can be used to store data.
The disadvantages of using lists are: They cause modification problems.
They cause data inconsistencies. They increase confusion and uncertainty when dealing with updates.
Relational databases are designed to address many information complexity
issues.
![Page 16: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/16.jpg)
Unit 1 – Database fundamentals Page 11
© CTI Education Group
Using an old filing cabinet is one of the most well-known traditional manual processes used for information storage and management. In many paper-
based companies, folders are sorted and stored in the drawers of filing cabinets. Information, in turn, is stored in individual folders within each
drawer; there might even be a sequence of filing cabinets wherein a specific record can be found. Whether a manual process or a database is utilised,
organisation is key to managing information along with finding the correct information in the shortest possible amount of time.
Some of the most common database uses include:
Tracking statistics/trends. Automating manual processes to eliminate paper-based systems.
Managing different types of transaction performed by individuals or
businesses. Maintaining historic information/student records/telephone records
Organising library card catalogues/online music stores/hospital patient records.
1.1.2 Physical and logical views of databases
In most cases, when using databases, you are primarily concerned about using information, not with the actual storage or size of each piece of data. You
would be focused on ensuring that your request or action yields a correct result. When a database system provides you with this, it does not include
details about how data is stored, only a conceptual representation of said data.
A logical database structure refers to the structure of data and the relationship
between different pieces of information. The logical view/user’s view of databases represents data in a format that is meaningful to both the user and
software program that processes said data. Information about the structure and relationship is thus not presented. This type of data model uses logical
concepts (such as objects, their properties and their relationships), which are easy to understand.
A physical database describes how the structure in a logical database and the search paths between them are implemented. Unless indicated otherwise, the
term ‘database’ refers to a logical database. Database specialists use a physical view to make efficient use of storage and processing resources.
Therefore, a logical view refers to how users view data; a physical view refers to how data is physically stored and processed.
1.1.3 Using relational database tables
The problems with using lists were first identified in the 1960s; subsequently,
a number of techniques have been developed to solve them. Over time, a methodology called the ‘Relational Model’ emerged as the leading solution.
Today, almost every commercial database is based on the Relational Model.
![Page 17: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/17.jpg)
Unit 1 – Database fundamentals Page 12
© CTI Education Group
A relational database contains a collection of separate tables. A table holds data about one – and only one – theme (in most circumstances). If a table has
two or more themes, it is broken up into two or more tables.
Tables and spreadsheets (also known as ‘worksheets’) are similar in that you can think of both as having rows, columns and cells. The details that define
tables as something different from spreadsheets are discussed in later units.
There are three basic table modifications, namely: 1. Insert: Insert data by adding data to a table
2. Update: Update data values by changing data in a table without unintended consequences
3. Delete: Delete data values in a table
Each table is assigned an ID column that assigns a unique identifying number
to each row; this is necessary as some tables might have the same name. The IDs are later used as linking columns to other tables.
1.1.4 Processing relational database tables
Some may consider tearing lists up to eliminate processing problems, but what if a user wants to view data in the format of an original list? With the data
separated into different tables, a user will have to jump from one table to the next to find the information that they want; this jumping around will become
tedious.
Several approaches have been invented for combining, querying and
processing tables. Over time, one of those approaches, a language called ‘Structured Query Language’ (SQL), emerged as the leading technique for data
definition and manipulation. Today, SQL is an international standard.
Using SQL, you can: Reconstruct lists from their underlying tables.
Query-specific data conditions. Perform computations on data in tables.
Insert, update and delete data.
1.1.5 The database environment
The database environment is, essentially, a place where databases reside. Within these, users and database administrators will require access to data.
Users might come from within the database environment or might have a remote connection to it. Users and administrators will, typically, perform a
range of tasks. These may include activities, such as data mining (collection), data modification or data insertion. Certain users might be restrained, either
physically or logically, from accessing data. Permissions to access data are, usually, configured by database owners or administrators.
![Page 18: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/18.jpg)
Unit 1 – Database fundamentals Page 13
© CTI Education Group
We will now explore the different components of a database environment.
1.1.5.1 Human component
Data administrators
The function of data administrators is to manage or have direct control over a database.
System developers
System developers are responsible for the development of applications, breaking data down into smaller steps and computer code, and transferring
them into more comfortable and understandable forms for end users.
End users
End users use a system/application.
1.1.5.2 Hardware/software component
User interface
This is what a system/application looks like. It is an easy and understandable way for end users to interact with and deploy.
Application programs
These execute what the system/application’s users would want to do with it.
1.1.5.3 Database component
Repository
This contains all data definitions, screen and report formats, and definitions of other organisation and system components.
DBMS A commercial software system used to create, maintain and provide controlled
access to a database repository.
Database A collection of data that meets the information needs of multiple users in an
organisation.
We have now defined the different database components, however, various possible environments exist for databases. In our case, an ‘environment’ refers
to the system/application configuration in which databases run.
1.2 Database systems
A database system implies that data is managed to some level of quality (measured in terms of accuracy, availability, usability and resilience); this, in
turn, often implies the use of a general-purpose DBMS.
![Page 19: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/19.jpg)
Unit 1 – Database fundamentals Page 14
© CTI Education Group
Well-known DBMSs include Oracle, IBM DB2, Microsoft SQL Server, Microsoft Access, MySQL and SQLite.
A database system has four components (Figure 1), namely:
1. Users 2. Database application
3. DBMS 4. Database
Figure 1 – Components of a database system
Source: Herbert Zuze
A database is a collection of related tables and other structures.
A DBMS is a computer program used to create, process and administer the
database. It receives requests encoded in SQL and translates them into actions. A DBMS is a large, complicated program that is licensed from a
software vendor; companies almost never write their own DBMS programs.
A database application is a set of one or more computer programs; that serves as an intermediary between users and the DBMS. Application programs
read or modify database data by sending SQL statements to the DBMS. They
also present data to users in form and report format. Application programs can be acquired from software vendors; they are also frequently written in-house.
Users employ a database application to keep track of items. They use forms to
read, enter and query data as well as to produce reports.
Of these mentioned components, we will consider the database, DBMS and database application in more detail.
1.2.1 Database component
As indicated earlier, in the broadest sense, a database can be defined as a self-
describing collection of related records or a self-describing collection of related tables.
![Page 20: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/20.jpg)
Unit 1 – Database fundamentals Page 15
© CTI Education Group
The two key terms herein are: 1. Self-describing
2. Related tables
Self-describing A database structure contained within the database itself. The
content of such a database can always be determined by looking inside the database itself; this situation is similar to that of a
library, where you can tell what is in the library by examining the catalogue that resides within it.
You already have a good idea of related tables. An example of related tables would be the ADVISOR and STUDENT tables, which are related by the common
column AdvisorName.
Data about the structure of databases is called ‘meta data’. Examples of meta
data are the names of tables, the names of columns and the tables to which they belong, the properties of tables and columns, etc.
All DBMS products provide a set of tools to display the structure of their
database. Other tools describe the structure of tables and others the components.
The content of a database is illustrated in Figure 2: a database has user data
and meta data, as already explained. It also has indices and other structures that exist to improve performance. Some databases may also contain
application meta data; this is, data that describes application elements, such as forms and reports. For example, MySQL carries application meta data as
part of its databases:
Figure 2 – Database content
Source: Herbert Zuze
![Page 21: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/21.jpg)
Unit 1 – Database fundamentals Page 16
© CTI Education Group
1.2.2 DBMS component
The purpose of a DBMS is to create, process and administer databases. DBMSs
are large, complicated products that are almost always licensed from software vendors. Open source DBMS products are also available.
A DBMS consists of three main components, namely:
1. A data definition language (DDL) 2. A data manipulation language (DML)
3. A data dictionary
A DDL is a formal language used by programmers to conceive a database’s
structure. This could include the creation or alteration of columns, constraints, tables and indices as well as the specification of any database file storage
location.
A DML is a specialised language that is used in conjunction with other programming languages to update data within a database. This language
contains commands that allow for the extraction of data from a database. The most prominent DML is SQL.
A data dictionary is a file that stores definitions of data elements and
characteristics, such as usage, ownership, authorisation and security. Many data dictionaries can produce lists and reports. Most data dictionaries are
passive; they simply report. More advanced types are considered to be active
when a change in the dictionary is automatically utilised by any related program.
DBMS functions include:
• Creating databases • Creating tables
• Creating supporting structures, e.g. indices • Reading database data
• Modifying (inserting, updating or deleting) database data • Maintaining database structures
• Enforcing rules • Controlling concurrency
• Providing security • Performing backup and recovery
DBMSs are used to create databases and tables as well as other supporting structures inside them.
![Page 22: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/22.jpg)
Unit 1 – Database fundamentals Page 17
© CTI Education Group
Example As an example of the latter, suppose that we have a STUDENT
table: The table has 10 000 rows
It includes a column, CourseName, that records the name of the course for which a student is enrolled
We frequently need to access student data via CourseName
Because this is a large database, searching through the table to find, for example, all students in the BSc IT field, would take a
long time. To improve performance, we can create an index (similar to the index at the back of a book) for CourseName to
show which students are enrolled for which courses. Such an
index is an example of a supporting structure that is created and maintained by a DBMS.
DBMSs also read and modify database data. To do this, a DBMS receives SQL
and other requests and transforms it into actions.
Another DBMS function is to maintain the database structure. For example, it might be necessary to change the format of a table or another supporting
structure from time to time.
With most DBMS products, it is possible to declare rules regarding data values.
Example In the IT COURSE database tables, what would happen if a user
mistakenly entered a value of 9 for CustomerID in the
ENROLMENT table? No such customer exists, so such a value would cause numerous errors.
To prevent this situation, it is possible to instruct the DBMS that
any value of CustomerID in the ENROLMENT table must already be a value of CustomerID in the CUSTOMER table. If no such
value exists, the insert or update request should be rejected. The DBMS then enforces these rules, which are called ‘referential
integrity constraints’.
The last three functions of a DBMS have to do with database administration: a DBMS controls concurrency by ensuring that one user’s work does not
inappropriately interfere with another user’s work. Also, a DBMS contains a security system that is used to ensure that only authorised users perform
authorised actions on a database. For example, users can be prevented from
seeing certain data. Similarly, user actions can be confined to making only certain types of data change on specified data. Finally, a DBMS provides
facilities for backing up database data and recovering it from backups, when necessary. Databases, as centralised repositories of data, are valuable
organisational assets.
![Page 23: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/23.jpg)
Unit 1 – Database fundamentals Page 18
© CTI Education Group
Example
Consider the value of a book database to a company such as Amazon.com. Because their database is so important, steps need
to be taken to ensure that no data will be lost in the event of error, hardware or software problems, natural or human
catastrophes.
1.2.3 Database application component
A database application creates and processes forms. A typical form is used for entering and processing data.
The functions of database application programs include:
• Creating and processing forms • Processing user queries
• Creating and processing reports • Executing application logic
• Controlling applications
Forms hide the structure of underlying tables from users. The goal of a form is to present data in a format that is useful to users, regardless of the underlying
table structure. Behind forms, applications process a database in accordance with user actions. Applications generate SQL statements to insert, update or
delete data.
Application programs, further, process user queries. This first generates a
query request and then sends it to the DBMS; results are then formatted and returned to the user.
Applications also create and process reports. This function is somewhat similar
to the former as application programs first query DBMSs for data. The applications then format the query results as a report.
A report displays all database data in a defined order. A report, similar to a
form, is structured according to user needs and not according to the underlying table structure.
In addition to generating forms, queries and reports, application programs take
other actions to update databases in accordance with application-specific logic.
Example
Suppose that a user, using an order entry application, requests ten units of a particular item and when the application queries
the database (via the DBMS), it finds that only eight units are in stock. What should happen?
![Page 24: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/24.jpg)
Unit 1 – Database fundamentals Page 19
© CTI Education Group
It depends on the logic of that particular application. Perhaps no units should be removed from inventory and the user should be
notified or perhaps the eight units should be removed and two more placed on back order. Whatever the case may be, it is the
duty of the application program to execute appropriate logic.
To control an application, applications need to be written so that only logical options are presented to users.
Example
An application may generate a menu with choices. In such a case, the application needs to ensure that only appropriate
choices are available. The application then needs to control data activities with the DBMS. It might direct the DBMS, for example,
to make a certain set of data changes as a unit. The application might tell the DBMS to either make all of the changes or none of
them.
1.2.4 Common DBMS data types
Table 1 summarises the common DBMS data types:
Table 1 – Common DBMS data types
Data type Description
BinaryBinary Length 0 to 8 000 bytes
CharCharacter Length 0 to 8 000 bytes
DateTime An 8 byte DateTime; ranges from January 1, 1753, to December 31,
9999, with an accuracy of three-hundredths of a second
Image Variable length binary data; maximum length of 2 147 483 647 bytes
Integer A 4 byte Integer; ranges from –2 147 483 648 to 2 147 483 647
Numeric Decimal; ranges from 1 038 + 1 to 1 038 − 1
Text Variable length text; maximum length of 2 147 483 648 characters
Varchar Variable length character; length 0 to 8 000 bytes
Source: Herbert Zuze
1.2.5 Personal vs enterprise-class database systems
Database technology can be used in a wide array of applications. On one end of the spectrum, a researcher might use database technology to track
experiment results performed in a laboratory. Such a database might include only a few tables and each table would have, at most, 700 rows. The
researcher would be the only user of this application; this would, typically, be a personal database system.
At the other end of the spectrum, enormous databases support international
organisations. They have hundreds of tables with millions of rows of data and support thousands of concurrent users. These databases are in use 24 hours a
![Page 25: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/25.jpg)
Unit 1 – Database fundamentals Page 20
© CTI Education Group
day, 7 days a week. Just making a backup of this is a difficult task. These databases are enterprise-class database systems.
Figure 3 illustrates the four components of a personal database system. In this
figure, Microsoft Access takes on the role of both the database application and DBMS. Microsoft designed Microsoft Access in this way to make it easier for
people to build personal database systems. Using Microsoft Access, you can switch between DBMS functions and application functions and never know the
difference:
Figure 3 – Personal database system
Source: Herbert Zuze
Microsoft Access 2013 is a commonly used personal DBMS and is available as part of the Microsoft Office 2013 suite.
Personal DBMSs do have limitations in terms of concurrent user connection as
well as the fact that they become easily corrupt.
Enterprise-class DBMSs are widely used in organisations to support business systems. They reside in central locations and can be accessed via ODBC
connections; they are capable of multiple user connections.
The problem with database technology often being hidden is that you do not
understand what is being done on your behalf. If you want to develop larger database systems, you need to learn all hidden technology.
![Page 26: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/26.jpg)
Unit 1 – Database fundamentals Page 21
© CTI Education Group
Figure 4 represents an enterprise-class database system:
Figure 4 – Enterprise-class database system
Source: Herbert Zuze
Supplementary reading
Kroenke, D.M. & Auer, D.J. 2013. Database concepts. 6th edition. New Jersey: Prentice Hall. Chapter 1.
1.2.6 Data diagrams
Different diagrams have been developed to manage data in databases. When
planning a database, you would draw a diagram to see how the elements inside such relate to one another. Each type of diagram is slightly different and
has a place in the development of a database plan.
There are four main types of data diagram, namely: 1. Hierarchical Model
2. Network Model
3. Object-orientated Model 4. Relational Model
1.2.6.1 Hierarchical Model
The Hierarchical Model consists of files with pointers from parent files to child
files that link related information together. It uses a tree structure to represent data. A child file can only have one parent file, while a parent file can have
multiple child files. This means that the structure may have data elements that are repeated (mostly in child elements).
![Page 27: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/27.jpg)
Unit 1 – Database fundamentals Page 22
© CTI Education Group
1.2.6.2 Network Model
The Network Model is similar to the Hierarchical Model, except that pointers
that link related information can point in both directions. It permits many-to-many (N:M) relationships, which are illegal in other models.
This model was created for three main purposes, namely:
1. To represent complex data relationships more effectively 2. To improve database performance
3. To impose a database standard
1.2.6.3 Object-Oriented Model
The Object-Oriented Model organises data into a hierarchical class of objects.
This form of modelling was developed to bring about more persistent storage
of programming language objects.
1.2.6.4 Relational Model
The Relational Model represents data as a set of relations in which data is
stored. Each column is unique and each field may contain unique keys. Relational databases are the most commonly used databases.
Advantages of the Relational Model are:
It reduces data redundancy (this refers to unnecessary data that can be calculated)
It ensures data integrity (this means that data is reliable) It enforces data security
It can be used by many people concurrently It supports shared data
It accommodates changes, growth and new information requirements
Apart from these models, many other models exist, such as object/relational,
semi-structured, associative, entity-attribute-value (EAV) and context diagrams.
1.3 Relational Model
1.3.1 Relations
Relations are two-dimensional tables that consist of rows and columns. Relations have the following characteristics:
Each row holds data that pertain to some entity or a portion of some entity. Each column contains data that represents an attribute of an entity. For
example, in the EMPLOYEE relation, each row would contain data about a particular employee and each column would contain data representing an
attribute of said employee, such as LastName, Phone or E-mailAddress. Each cell must hold a single value; no repeating elements are allowed
![Page 28: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/28.jpg)
Unit 1 – Database fundamentals Page 23
© CTI Education Group
All entries in a column must be of the same kind. For example, if the third column in the first row contains EmployeeNumber, then the third column in
all other rows must also contain EmployeeNumber. Each column must have a unique name.
The order of columns is unimportant. The order of rows is unimportant.
The set of data values in each row must be unique; no two rows may hold identical sets of data value.
Figure 5 illustrates an example of a relation:
Figure 5 – Example of a relation
Source: Herbert Zuze
1.3.2 Types of key
A key is one or more columns of a relation that is used to identify a row. A key
can be unique or non-unique.
Example In the EMPLOYEE relation in Figure 5, EmployeeNumber is a
unique key; it identifies a unique row. A query to display all employees having an EmployeeNumber of 200 will produce a
single row result.
In contrast, Department is a non-unique key. It is a key because it is used to identify a row, but it is non-unique because a value
of Department potentially identifies more than one row.
1.3.2.1 Composite keys
A composite key is a key that contains two or more attributes.
Example Suppose that we are looking for a unique key for the EMPLOYEE
relation: users say that although LastName is not unique, the combination of LastName and Department is unique.
Let us assume that the users know that two people with the same
last name will never work in the same department. Two Johnsons, for example, will never work in Accounting. If that is
![Page 29: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/29.jpg)
Unit 1 – Database fundamentals Page 24
© CTI Education Group
the case, then the combination (LastName, Department) is a unique composite key.
Alternatively, if the users know that the combination (LastName,
Department) is not unique, but that another combination (FirstName, LastName, Department) is unique, then the latter
combination is a composite key with three attributes.
1.3.2.2 Candidate and Primary Keys (PK)
Candidate keys are keys that uniquely identify each row in a relation; they can
be single column keys or they can be composite keys.
A PK is a candidate key that is chosen as the key the DBMS will use to uniquely
identify each row in a relation.
Example Suppose that we have the following EMPLOYEE relation:
EMPLOYEE (EmployeeNumber, FirstName, LastName,
Department, E-mail, Phone)
The users tell us that EmployeeNumber is a unique key, E-mail is a unique key and the composite key (FirstName,
LastName, Department) is a unique key. Therefore, we have three candidate keys.
When designing the database, we choose one of the candidate
keys to be the PK. In this case, for example, we use
EmployeeNumber as the PK. The PK is important not only because it can be used to identify unique rows, but also because
it can be used to represent rows in relationships.
1.3.2.3 Surrogate keys
A surrogate key is a column with a unique, DBMS-assigned identifier added to
a table to be the PK. The unique values of the surrogate key are assigned by the DBMS each time a row is created; in addition, the values never change.
An ideal PK is short, numeric and never changes. Sometimes, one column in a
table will meet these requirements or come close to them. EmployeeNumber in the EMPLOYEE relation should work very well as a PK.
![Page 30: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/30.jpg)
Unit 1 – Database fundamentals Page 25
© CTI Education Group
Example Consider the following relation:
PROPERTY (Street, City, State, ZIP, OwnerID)
The PK of PROPERTY is (Street, City, State, ZIP), which is long
and non-numeric (although it probably will not change). This is thus not an ideal PK. In cases such as this, the database designer
will add a surrogate key, such as PropertyID:
PROPERTY (PropertyID, Street, City, State, ZIP, OwnerID)
Surrogate keys are short, numeric and never change, therefore, they are ideal
PKs. Because the value of the surrogate PK will have no meaning to users, they are often hidden on forms, query results and reports. Most DBMS
products have a facility that automatically generates key values. In Microsoft Access, data type is set to AutoNumber.
1.3.2.4 Foreign Keys (FK) and referential integrity
Values from one relation into a second relation represent a relationship. The values we use are the PK values (including composite PK values, when
necessary) of the first relation. When we do this, the attribute in the second relation that holds these values is the FK. For example, CustomerNumber is
the PK of a relation that is foreign to the table in which it resides.
Example Consider the following two relations, where (apart from the
EMPLOYEE relation) we now have a DEPARTMENT relation to hold
data about departments:
EMPLOYEE (EmployeeNumber, FirstName, LastName, Department, E-mail, Phone)
and
DEPARTMENT (DepartmentName, BudgetCode, OfficeNumber,
DepartmentPhone)
EmployeeNumber and DepartmentName are the PKs of EMPLOYEE and DEPARTMENT respectively.
Now, suppose that Department in EMPLOYEE contains the names
of the departments in which employees work and that
DepartmentName in DEPARTMENT also contains these names. In such a case, Department in EMPLOYEE is said to be a FK to
DEPARTMENT.
![Page 31: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/31.jpg)
Unit 1 – Database fundamentals Page 26
© CTI Education Group
Note that it is not necessary for PKs and FKs to have the same column name. In most cases, it is important to ensure that every value of a FK matches a
value of the PK. Such a rule is called a ‘referential integrity constraint’. Whenever you see a FK, you should always look for an associated referential
integrity constraint.
1.3.2.5 Null values
A null value is a missing value in a cell in a relation. Null values are ambiguous as they are not easy to interpret. There are three possible meanings that can
be deduced from null values, namely: 1. There might be no appropriate value for the entry.
2. There is only one known value for the entry or the value has not yet been decided.
3. The value is unknown.
1.4 Functional dependency and normalisation
1.4.1 Functional dependency
Functional dependency exists when a relationship between two attributes
allows you to uniquely determine the corresponding attribute’s value. The normalisation process starts with this and acts as a constraint between the two
attribute sets in a relation.
Functional dependency helps to identify redundancy problems and suggest
refinements. Information redundancy results from the association of different types of information within a single relationship schema. Decomposing such a
relationship schema may address the problem. Conversely, decomposing may increase the time needed to evaluate queries.
1.4.2 Normalisation
Normalisation is a systematic process of decomposing relations with anomalies into smaller sets of well-structured relation. The process eliminates data
redundancy and ensures data integrity.
![Page 32: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/32.jpg)
Unit 1 – Database fundamentals Page 27
© CTI Education Group
Normalisation ensures that: Rows contain data about an entity.
Columns contain data about attributes of an entity. Cells hold a single value.
All entries in a column are of the same kind. Each column has a unique name.
No two rows hold identical sets of data value.
The benefits of normalisation include: The elimination of data redundancy reduces the size of a database, hence
less money will be spent on storage. Less data for searching means faster querying of data.
No duplication of data results, hence there is a lowered risk of errors.
A change made on a linking record is instantly cascaded across all related tables.
Fewer indices per table mean faster maintenance tasks, such as index rebuilding relational design principles.
Design principles can be regarded as well formed, if:
Every determinant is a candidate key. Any relation that is not well formed is broken down into two or more
relations that are well formed.
The above design principles are at the heart of normalisation.
There are many defined normal forms. Technically, well-formed relations are those that are said to be in Boyce-Codd Normal Form (BCNF), namely:
First normal form (1NF)
Second normal form (2NF) Third normal form (3NF)
Note that further steps (4NF, 5NF, 6NF) were created in order to cater for rare
instances, such as ambiguity among attributes and tables. They are, however, outside the scope of this module, therefore, the focus will fall on the first three
normal forms.
1.4.2.1 Normalisation terminology
Note the following terminology as applicable to normalisation:
Composite PK: a combination of two or more attributes from a group or entity that form a PK for the group or entity involved.
PK: a PK in normalisation is the same as a unique identifier in Entity-Relationship (ER) modelling.
FK: a FK is a data item in a group that has the same value as the PK in
another group; in normalisation, a FK links two groups. Dependency: a data item (in other words, an attribute) that is dependent
on another data item as it has no meaning or purpose without its determinant.
![Page 33: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/33.jpg)
Unit 1 – Database fundamentals Page 28
© CTI Education Group
Normal form: a step or stage during the normalisation process; each normal form applies a certain rule to the data being normalised, which
eventually causes the data to be separated into more logically related groups.
Data group: a data group results from the data being normalised, depending on which normal form is being applied to it; a data group is not
a table or an entity. Repeating group: a set of logically related data that repeats for a specific
unique ID.
1.4.2.2 Normalisation steps
There are a number of steps that should be followed to reach 3NF, namely:
Collect the raw data (0NF).
List the raw data, grouping related data together, and identify a PK (0NF). Remove repeating groups (1NF).
Remove part-key dependencies (2NF). Remove inter-data dependencies (3NF).
Supplementary reading
Kroenke, D.M. & Auer, D.J. 2013. Database concepts. 6th edition. New Jersey: Prentice Hall. Chapter 2.
1.5 Concluding remarks
In this unit, we explained databases and reviewed key concepts related to it.
An overview of DBMSs was provided.
In the next unit, we will explain how databases are designed.
1.6 Self-assessment
Test your knowledge
1. Why is the study of database technology important?
2. Describe the purpose of databases.
![Page 34: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/34.jpg)
Unit 1 – Database fundamentals Page 29
© CTI Education Group
3. What is a modification problem? What are the three possible types of modification problem?
4. What is an ID column?
5. What does SQL stand for and what purpose does it serve?
6. Why is the Relational Model important?
7. List the characteristics that tables must have to be considered as
relations.
8. Give an example of a relation (other than examples from the Study
Guide).
9. Under which circumstances can attributes be of variable length?
10. Define ‘unique’ key and give an example.
11. Define ‘referential integrity constraint’ and give an example.
![Page 35: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/35.jpg)
Unit 2 – Database design Page 30
© CTI Education Group
Unit 2: Database design
Unit 2 is aligned with the following learning outcomes and assessment criteria:
Learning outcomes
LO2 Identify and explain database design techniques and principles
LO3 Design, create and document databases
Assessment criteria AC2.1 Analyse a database developmental methodology –
normalization and ERD AC2.2: Apply relation database design for a given data set
(3NF/ERD)
AC3.1 Apply the database developmental life cycle to a given data set
AC3.2 Design a fully functional database (containing at least four inter-relational tables), which includes a user
interface
Learning objectives
After studying this unit, you should be able to:
Understand the basic stages of database development Understand the purpose and role of data models
Know the principal components of the ER Data Model Know how to present one-to-one (1:1), one-to-many (1:N) and N:M binary
relationships within the ER Data Model Construct ER diagrams
Know how to interpret Information Engineering (IE) Crow’s Foot ER diagrams
Know how to present sub-type entities and recursive relationships within
the ER Data Model Understand the nature and background of normalisation theory
Understand the need for denormalisation
Introduction
In this unit, we focus on database design. We provide an overview of the
database design process and describe data modelling, a technique for
representing database requirements. We also explore how to transform data models into relational database design.
![Page 36: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/36.jpg)
Unit 2 – Database design Page 31
© CTI Education Group
Activity Before we explore database design, write down what you think
about them.
2.1 Database design methods and methodologies
2.1.1 Database development stages
The three primary stages of database development are:
Requirements analysis
Component design Implementation
The above stages form part of the Systems Development Life Cycle (SDLC).
The SDLC is a classic methodology used to develop information systems. Each stage should produce one or more deliverables, which entail the following
(Figure 6): System definition
Requirements analysis Component design
Implementation System maintenance
![Page 37: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/37.jpg)
Unit 2 – Database design Page 32
© CTI Education Group
Figure 6 – SDLC
Source: Herbert Zuze
2.1.1.1 System definition
Input: the need for an information system to support a business process
Output: a project plan
During this stage, the following occurs: The system project goals and scope of information are defined.
The feasibility of the project (cost, schedule, technical, organisational) is assessed.
The project team is chosen. The project (specified tasks, assigned personnel, determined task
dependencies, set schedules) is planned.
![Page 38: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/38.jpg)
Unit 2 – Database design Page 33
© CTI Education Group
2.1.1.2 Requirements analysis
Input: the project plan Output: a set of approved user requirements
The deliverables of this stage may include a data model, User Requirements Document (URD) and Statement Of Work (SOW). Sources of information
include user interviews, forms, reports, queries, use cases and business rules.
During this stage, the following occurs: User interviews are conducted.
Existing systems are evaluated. New required forms, reports and queries are determined.
New application features and functions are identified. Security issues are considered.
A data model is created. The five components of an information system are considered (hardware,
software, data, procedures and people).
2.1.1.3 Component design
Input: approved user requirements Output: a final system design
Database and documented system design may be part of this stage’s
deliverables.
During this stage, the following occurs: Hardware and software specifications are determined.
Database design, business procedures and job descriptions for business personnel are created.
2.1.1.4 Implementation
Input: the final system design
Output: a final system
During this stage, the following occurs:
System components are built. Component tests are conducted.
Components are integrated. Integrated components are tested.
The new system conversion takes place.
![Page 39: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/39.jpg)
Unit 2 – Database design Page 34
© CTI Education Group
2.1.1.5 System maintenance
Input: the implemented system Output: an updated system or a request for system modification using the
SDLC
In this stage, the system is updated with patch service packs and new software
releases. Requests for system changes or enhancements are recorded and prioritised.
2.1.2 Structured Systems Analysis and Design Method (SSADM)
SSADM is a software development approach that divides application development projects into modules, stages, steps and tasks. It provides a
framework in which to describe projects.
SSADM is a formal approach that sets out a cascade or waterfall view of
information system development, in which there are a series of steps, each of which leads to the next.
The SSADM’s steps are:
Conduct a feasibility study. Investigate the current environment.
Determine the business system options. Define the requirements.
Determine the technical system options. Create a logical design.
Create a physical design.
Advantages of the SSADM approach include: It enables users to receive systems on time.
It delivers systems that meet user needs.
It delivers systems which respond to changes in the business environment. It improves the effective and economic use of available skills.
It improves quality by reducing error rates. It improves flexibility.
It improves productivity. It avoids lock-in to single sources of supply.
2.1.3 Agile Software Development methodology
Agile is an iterative and incremental software development approach that focuses on continuous feedback that leads to a refined delivery of working,
tested software. The Dynamic Systems Development Model (DSDM) and Scrum are agile approach examples.
![Page 40: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/40.jpg)
Unit 2 – Database design Page 35
© CTI Education Group
When using the agile approach, risks are minimised by developing software in
iterations, which last one to four weeks. Each iteration can be viewed as a mini project on its own, which has tasks and deliverables at the end of the iteration
period. Released deliverables follow a project cycle of planning, requirements
analysis, design, coding, testing and documentation. The intent of every shippable product/iteration is to result in a meaningful and functional project.
After delivering an iteration, the team evaluates performance and priorities, noting all problems and successes.
Advantages of the agile approach include:
Rapid customer satisfaction owing to the continuous delivery of useful software
Clear communication of requirements owing to active client involvement Easier prioritisation of requirements in accordance with user needs
2.1.4 Rapid Application Development (RAD) methodology
RAD is a faster and higher quality software development approach. RAD does
the following: It gathers information via focus groups or workshops
It employs prototyping and user testing It reuses software components
It keeps review meetings and other team communication informal
Advantages of RAD include: It reduced development time
It increased the reusability of components It encourages customer feedback
2.1.5 Spiral methodology
The Spiral methodology focuses on the early identification and reduction of
project risks. It iterates through four phases, namely: Determine objectives
Identify and resolve risks Develop and test
Plan the next iteration
Advantages of the Spiral methodology include: It is suitable for large and high risk projects
It enhances risk avoidance owing to high amounts of risk analysis Software is produced early on in the SDLC
![Page 41: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/41.jpg)
Unit 2 – Database design Page 36
© CTI Education Group
2.1.6 Waterfall methodology
The Waterfall Methodology (Figure 7) is a popular, rigid and linear traditional
software development approach. Each phase has distinct goals and has to be completed before starting the next; there is no turning back:
Figure 7 – Waterfall Methodology
Source: Herbert Zuze
Advantages of the Waterfall methodology include: It is easy and simple to understand and use.
It is easy to manage owing to the rigidity of the model. Phases are processed and completed one at a time.
2.2 Relational database design: ER modelling
2.2.1 ER Data Model
After system requirements have been gathered, they are transformed into data models. A number of different techniques can be used to create these; by far
the most popular is the ER Data Model, first published by Peter Chen in 1976.
Chen’s basic model has since been extended to create the Extended ER Data Model.
![Page 42: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/42.jpg)
Unit 2 – Database design Page 37
© CTI Education Group
The most important ER Data Model elements are:
Entities Attributes
Identifiers
Relationships
2.2.1.1 Entities
Entity classes vs entity instances
An entity is something that a user wants to track. An entity class is a description of the structure and format of an entity. Entities of a given type are
grouped into entity classes. For example, the STUDENT entity class is a collection of all STUDENT entities. Entity classes are displayed with capital
letters. An entity instance is a specific occurrence of an entity within an entity class (Figure 8):
Figure 8 – ITEM entity with two entity instances
Source: Herbert Zuze
When developing data models, developers analyse forms, reports, queries and
other system requirements. Entities are, usually, the subject of one or more forms/reports or they are a major section in one or more forms/reports.
2.2.1.2 Attributes
Entities have attributes that describe entity characteristics, for example,
ProjectName, StartDate, ProjectType, ProjectDescription. An attribute has a data type (character, numeric, date, currency and the like) and properties that
are determined from system requirements. Properties specify whether an attribute is required, whether this has a default value and value limit as well as
any other constraints.
![Page 43: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/43.jpg)
Unit 2 – Database design Page 38
© CTI Education Group
2.2.1.3 Identifiers
Entity instances have identifiers, which are attributes that name or identify a particular instance in an entity class, for example, SocialSecurityNumber,
StudentID, EmployeeID, etc. An identifier of an entity instance consists of one
or more of the entity’s attributes.
Types of identifier Uniqueness:
An identifier may be unique or non-unique. If an identifier is unique, the data value for it must be unique for all
instances.
Composite: A composite identifier consists of two or more attributes, e.g. OrderNumber
and LineItemNumber, which are both required.
Figure 9 illustrates the levels of entity attribute display:
Figure 9 – Levels of entity attribute display
Source: Herbert Zuze
2.2.1.4 Relationships
Entities can be associated with one another via relationships. The ER Data Model contains relationship classes and instances. Relationship classes are
associations among entity classes whereas relationship instances are associations among entity instances.
Relationship degrees define the number of entity classes participating in a
relationship:
Degree 2 is a binary relationship (Figure 10) Degree 3 is a ternary relationship (Figure 11)
![Page 44: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/44.jpg)
Unit 2 – Database design Page 39
© CTI Education Group
Figure 10 – Binary relationship
Source: Herbert Zuze
Figure 11 – Ternary relationship
Source: Herbert Zuze
There are three types of binary relationship, namely:
1:1
1:N N:M
1:1 binary relationships
A single entity instance in one entity class is related to a single entity instance in another entity class. For example, an employee may have no more than one
locker and a locker may only be accessible to one employee (Figure 12):
Figure 12 – 1:1 binary relationship
Source: Herbert Zuze
1:N binary relationships
A single entity instance in one entity class is related to many entity instances in another entity class. For example, a quotation is associated with only one
item whereas an item may have several quotations (Figure 13):
![Page 45: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/45.jpg)
Unit 2 – Database design Page 40
© CTI Education Group
Figure 13 – 1:N binary relationship
Source: Herbert Zuze
N:M binary relationships Many entity instances in one entity class are related to many entity instances
in another entity class. For example, a supplier may supply several items and a particular item may be supplied by several suppliers (Figure 14):
Figure 14 – N:M binary relationship
Source: Herbert Zuze
Maximum and minimum cardinality
Relationships are named and classified by their cardinality, which is a word
meaning ‘count’.
Each of the three types of binary relationship has different maximum cardinalities. Maximum cardinality is the maximum number of entity instances
that may participate in a relationship instance (one, many or a fixed amount).
Minimum cardinality is the minimum number of entity instances that must participate in a relationship instance. These values, typically, assume a value
of zero (optional) or one (mandatory).
Example In Figure 15, maximum cardinality is many for both ITEM and
SUPPLIER. Minimum cardinality is zero (optional) for ITEM and one (mandatory) for SUPPLIER: a supplier does not have to
supply an item, but an item must have a supplier:
![Page 46: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/46.jpg)
Unit 2 – Database design Page 41
© CTI Education Group
Figure 15 – Relationship cardinalities
Source: Herbert Zuze
2.2.2 ER diagrams
The sketches in Figure 10 to Figure 15 are called ‘ER diagrams’. The relationships in these are called ‘HAS-A relationships’. This term is used
because each entity instance ‘has a’ relationship to a second entity instance, for example, an employee has a badge and a badge has an employee.
Note the following about ER diagrams: Entity classes are shown with rectangles.
Relationships are shown with diamonds. Maximum cardinality is shown inside diamonds.
Minimum cardinality is shown with ovals or hash marks next to entities. The name of an entity is shown inside rectangles.
The name of a relationship is shown near diamonds.
2.2.2.1 Types of ER diagram
The types of ER diagram are: IE: uses ‘crow’s feet’ to show the many sides of a relationship; it is often
referred to as the ‘Crow’s Foot Model’ Integrated Definition 1, Extended 3 (IDEF1X): a version of the ER Data
Model that is a national standard Unified modelling language (UML): a set of structures and techniques for
modelling and designing object-oriented programs and applications
Crow’s Foot symbols Figure 16 illustrates Crow’s Foot symbols:
![Page 47: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/47.jpg)
Unit 2 – Database design Page 42
© CTI Education Group
Figure 16 – Crow’s Foot symbols
Source: Herbert Zuze
Crow’s Foot example: 1:N relationship Figure 17 illustrates a 1:N relationship: Crow’s Foot:
Figure 17 – Two versions of a 1:N relationship
Source: Herbert Zuze
![Page 48: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/48.jpg)
Unit 2 – Database design Page 43
© CTI Education Group
Crow’s Foot example: N:M relationship
Figure 18 illustrates an N:M relationship: Crow’s Foot:
Figure 18 – Two versions of an N:M relationship
Source: Herbert Zuze
Weak entities
A weak entity is an entity that cannot exist in a database without the existence of another entity. Any entity that is not a weak entity is called a ‘strong entity’.
ID-dependent weak entities An ID-dependent weak entity is a weak entity that cannot exist without its
parent entity. An ID-dependent weak entity has a composite identifier. The first part of said identifier is the identifier for the strong entity and the second
part of the identifier is the identifier for the weak entity.
An identifying relationship is a type of relationship that is shown by a solid line representing the relationship between an ID-dependent entity and its parent
entity. A relationship drawn with a dashed line used between strong entities is called a ‘non-identifying relationship’; there are no ID-dependent entities in
this kind of relationship.
![Page 49: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/49.jpg)
Unit 2 – Database design Page 44
© CTI Education Group
Figure 19 illustrates ID-dependent weak entities:
Figure 19 – ID-dependent weak entities
Source: Herbert Zuze
Non-ID-dependent weak entities
All ID-dependent entities are weak entities, however, there are other entities that are weak but not ID-dependent. A non-ID-dependent weak entity may
have a single or composite identifier; the identifier of the parent entity will be a FK.
Figure 20 illustrates non-ID-dependent weak entities:
Figure 20 – Non-ID-dependent weak entities
Source: Herbert Zuze
![Page 50: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/50.jpg)
Unit 2 – Database design Page 45
© CTI Education Group
Figure 21 illustrates strong and weak entity examples:
Figure 21 – Strong and weak entity examples
Source: Herbert Zuze
2.2.3 Sub-type entities
A sub-type entity is a special case of another entity called a ‘super-type’. An attribute of a super-type may be included; this indicates which sub-type is
appropriate for a given instance; this attribute is called a ‘discriminator’.
Sub-types can be exclusive or inclusive:
If exclusive, the super-type relates to, at most, one sub-type. If inclusive, the super-type can relate to one or more sub-types.
2.2.3.1 Sub-type entity identifiers
The relationships that connect super-types and sub-types are called ‘IS-A relationships’; sub-types are the same entities as super-types. The identifier of
a super-type and all of its sub-types is the same attribute.
Figure 22 illustrates sub-type entity examples:
![Page 51: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/51.jpg)
Unit 2 – Database design Page 46
© CTI Education Group
Figure 22 – Sub-type entity examples
Source: Herbert Zuze
2.2.4 Recursive relationships
It is possible for an entity to have a relationship with itself; this is called a
‘recursive relationship’. As with binary relationships, recursive relationships (Figure 23) can be 1:1, 1:N and N:M:
Figure 23 – Recursive relationship
Source: Herbert Zuze
2.2.5 Developing ER diagrams
Example
Heather Sweeney Designs will be used as an ongoing example for the rest of the Study Guide. Heather Sweeney is an interior
designer who specialises in home kitchen design. She offers a variety of free seminars at home shows, kitchen and appliance
stores, and other public locations. She earns revenue by selling books and videos. She also offers custom-design consulting
services.
Figure 24 illustrates Heather Sweeney Designs: a seminar customer list:
![Page 52: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/52.jpg)
Unit 2 – Database design Page 47
© CTI Education Group
Figure 24 – Seminar customer list
Source: Herbert Zuze
Figure 25 illustrates Heather Sweeney Designs: an initial ER diagram:
Figure 25 – Initial ER diagram
Source: Herbert Zuze
![Page 53: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/53.jpg)
Unit 2 – Database design Page 48
© CTI Education Group
Figure 26 illustrates Heather Sweeney Designs: a customer form letter:
Figure 26 – Customer form letter
Source: Herbert Zuze
![Page 54: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/54.jpg)
Unit 2 – Database design Page 49
© CTI Education Group
Figure 27 illustrates Heather Sweeney Designs: a data model with CONTACT:
Figure 27 – Data model with CONTACT
Source: Herbert Zuze
![Page 55: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/55.jpg)
Unit 2 – Database design Page 50
© CTI Education Group
Figure 28 illustrates Heather Sweeney Designs: a sales invoice:
Figure 28 – Sales invoice
Source: Herbert Zuze
![Page 56: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/56.jpg)
Unit 2 – Database design Page 51
© CTI Education Group
Figure 29 illustrates Heather Sweeney Designs: a data model with INVOICE:
Figure 29 – Data model with INVOICE
Source: Herbert Zuze
Figure 30 illustrates Heather Sweeney Designs: a data model with LINE_ITEM:
Figure 30 – Data model with LINE_ITEM
Source: Herbert Zuze
![Page 57: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/57.jpg)
Unit 2 – Database design Page 52
© CTI Education Group
Figure 31 illustrates Heather Sweeney Designs: a final data model:
Figure 31 – Final data model
Source: Herbert Zuze
Business rules need to be recorded. Heather Sweeney Designs has a business
rule that no more than one form letter or e-mail per day is to be sent to a
customer. After the data model has been completed, this needs to be validated. Prototyping is commonly used to validate forms and reports.
Business rules are constraints on database activities and, generally, these arise from business policy and practice.
2.3 Relational database design: normalisation
Recall the introduction to normalisation as discussed in Unit 1 before starting
with this section.
2.3.1 Normalisation process
The normalisation process for normalising relations can be formulated as follows:
Identify all candidate keys in a relation Identify all functional dependencies in a relation
Examine the determinants of said functional dependencies. If any determinant is not a candidate key, the relation is not well formed. In
such a case: Place the columns of the functional dependency in a new relation.
Make the determinant of the functional dependency the PK of the new relation.
Leave a copy of the determinant as a FK in the original relation. Create a referential integrity constraint between the original and new
relations.
![Page 58: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/58.jpg)
Unit 2 – Database design Page 53
© CTI Education Group
Repeat the previous step as many times as necessary until every
determinant of every relation is a candidate key.
Figure 32 acts as an example to explain the above:
Figure 32 – PRESCRIPTION relation and data
Source: Herbert Zuze
Example Consider the following relation:
PRESCRIPTION (PrescriptionNumber, Date, Drug, Dosage, CustomerName, CustomerPhone, CustomerE-mail)
Identify all candidate keys
PrescriptionNumber is a candidate key; it clearly determines
Date, Drug and Dosage. If we assume that a prescription is only for one person, then it also determines CustomerName,
CustomerPhone and CustomerE-mail.
Identify all functional dependencies
To know whether functional dependencies are true for a particular application, we need to look beyond the sample data and ask the
users.
PrescriptionNumber determines all other attributes as described.
By examining the customer columns, we do find a functional dependency, CustomerE-mail, which can be assumed to be a better determinant of attributes: CustomerE-mail →
(CustomerName, CustomerPhone).
This assumption is based on the fact that it is possible for some
customers to share the same e-mail address; it is also possible
that some customers do not have an e-mail address.
Ask whether there are determinants that are not candidate keys
CustomerE-mail is a determinant but not a candidate key.
Therefore, PRESCRIPTION has normalisation problems and is not
![Page 59: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/59.jpg)
Unit 2 – Database design Page 54
© CTI Education Group
well formed. According to this step, we must split the functional
dependency into a new relation of its own:
CUSTOMER (CustomerName, CustomerPhone,
CustomerE-mail)
We make the determinant of the functional dependency, CustomerE-mail, the PK of the new relation. We leave a copy of
such in the original relation as a FK. Thus, PRESCRIPTION is now:
PRESCRIPTION (PrescriptionNumber, Date, Drug, Dosage, CustomerE-mail)
Finally, we create a referential integrity constraint:
CustomerE-mail in PRESCRIPTION must exist in CustomerE-mail
in CUSTOMER.
At this point, if we move through the three steps, we find that
neither of these relations has a determinant that is not a candidate key. We can now say that the two relations are
normalised.
Figure 33 illustrates the result of normalisation on the example:
Figure 33 – Normalised data
Source: Herbert Zuze
Supplementary reading Kroenke, D.M. & Auer, D.J. 2013. Database concepts. 6th
edition. New Jersey: Prentice Hall. Chapter 4.
![Page 60: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/60.jpg)
Unit 2 – Database design Page 55
© CTI Education Group
2.3.2 Transforming data models into relational design
The steps for transforming data models into relational design involve the
following:
Create a table for each entity in a data model: Specify the PKs
Specify the properties of each column, e.g. data types, null status (if any), default values and data constrains (if any)
Normalise the table Create the relationships between tables by replacing FKs
Create strong entity relationships (1:1, 1:N, N:M) Create ID-dependent and non-ID-dependent weak entity relationships
Create sub-types Create recursive relationships (1:1, 1:N, N:M)
2.3.2.1 Representing entities
Follow the process below:
Create a relation for each entity (a relation has a descriptive name and a set of attributes that describe the entity)
Specify a PK
Specify column properties, e.g. data types, null status (if any), default values and data constrains (if any)
Analyse the relation using normalisation rules As normalisation issues arise, the initial relational design may need to
change
2.3.2.2 Representing entities as tables
Figure 34 illustrates representing an entity as a table:
Figure 34 – ITEM entity and table
Source: Herbert Zuze
The entity table with column characteristics are:
ITEM (ItemNumber, Description, Cost, ListPrice, QuantityOnHand) (Figure 35):
![Page 61: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/61.jpg)
Unit 2 – Database design Page 56
© CTI Education Group
Figure 35 – Final ITEM table
Source: Herbert Zuze
2.3.3 Normalisation review
2.3.3.1 Solving problems
Tables that are not normalised will experience problems. These include:
Insertion problems: difficulties inserting data into relations
Modification problems: difficulties modifying data in relations Deletion problems: difficulties deleting data from relations
Most problems are solved by breaking existing tables into two or more tables
through normalisation.
2.3.3.2 Concepts review
Important normalisation concepts are:
Functional dependency: the relationship within a relation that describes how the value of one attribute may be used to find the value of another
attribute
Determinant: an attribute that can be used to find the value of another attribute in a relation
Candidate key: the value of a candidate key can be used to find the value of every other attribute in a table; a simple candidate key consists of only
one attribute whereas a composite candidate key consists of more than one attribute
2.3.3.3 Normal forms
There are many defined normal forms, namely: 1NF
2NF 3NF
BCNF 4NF
5NF
Domain key/normal form (DK/NF)
![Page 62: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/62.jpg)
Unit 2 – Database design Page 57
© CTI Education Group
Figure 36 illustrates a CUSTOMER entity and table:
Figure 36 – CUSTOMER entity and table
Source: Herbert Zuze
Figure 37 illustrates the CUSTOMER entity’s normalised set of tables:
Figure 37 – Normalised CUSTOMER entity tables
Source: Herbert Zuze
2.3.4 Denormalisation
Denormalisation is the process of trying to optimise the read performance of databases by adding redundant data or by grouping data. In some cases,
denormalisation covers up the inefficiencies inherent in relational database software.
A relational normalised database imposes a heavy access load on physical
storage of data even if it is well-tuned for high performance. It may also significantly increase the complexity of the data structure. There are situations,
however, where denormalised relations are preferred.
![Page 63: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/63.jpg)
Unit 2 – Database design Page 58
© CTI Education Group
Figure 38 illustrates the CUSTOMER entity’s denormalised set of tables:
Figure 38 – Denormalised CUSTOMER entity tables
Source: Herbert Zuze
2.3.4.1 Representing weak entities
If an entity is not ID-dependent, use the same techniques as for strong entities. If it is ID-dependent, add a PK to the parent entity.
Figure 39 illustrates a weak entity:
Figure 39 – Weak entity
Source: Herbert Zuze
2.3.4.2 Representing 1:1 relationships
Maximum cardinality determines how relationships are represented. In a 1:1
relationship, the key from one relation is placed in the other as a FK; it does not matter which table receives it.
![Page 64: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/64.jpg)
Unit 2 – Database design Page 59
© CTI Education Group
Figure 40 illustrates a 1:1 relationship:
Figure 40 – 1:1 relationship
Source: Herbert Zuze
2.3.4.3 Representing 1:N relationships
Similar to 1:1 relationships, 1:N relationships are saved by placing the key
from one table into another as a FK. However, in a 1:N the FK always goes into the N-side of the relationship. The 1-side is called the ‘parent’ and the N-side is
called the ‘child’.
Figure 41 illustrates a 1:N relationship:
Figure 41 – 1:N relationship
Source: Herbert Zuze
![Page 65: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/65.jpg)
Unit 2 – Database design Page 60
© CTI Education Group
2.3.4.4 Representing N:M relationships
To create N:M relationships, new tables must be created. Such tables are called ‘intersection tables’. An intersection table has a composite key consisting
of keys from each of the tables that it connects.
Figure 42 illustrates an N:M relationship data model:
Figure 42 – N:M relationship data model
Source: Herbert Zuze
Figure 43 illustrates an N:M relationship database design:
Figure 43 – N:M relationship database design
Source: Herbert Zuze
![Page 66: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/66.jpg)
Unit 2 – Database design Page 61
© CTI Education Group
2.3.4.5 Representing associated relationships
Figure 44 illustrates an associated relationship:
Figure 44 – Associated relationship
Source: Herbert Zuze
2.3.4.6 Representing super-type and sub-type relationships
The identifier of a super-type becomes the PK and FK of each sub-type (Figure 45):
Figure 45 – Super-type and sub-type relationships
Source: Herbert Zuze
2.3.4.7 Representing recursive relationships
Recursive relationships have relations within themselves; they adhere to the
same rules as binary relationships. 1:1 and 1:N relationships are saved using FKs and N:M relationships are saved by creating intersecting relations.
![Page 67: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/67.jpg)
Unit 2 – Database design Page 62
© CTI Education Group
Figure 46 illustrates recursive relationships:
Figure 46 – Recursive relationships
Source: Herbert Zuze
Figure 47 illustrates an N:M recursive relationship:
Figure 47 – N:M recursive relationship
Source: Herbert Zuze
![Page 68: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/68.jpg)
Unit 2 – Database design Page 63
© CTI Education Group
2.3.5 Developing database design
Example Heather Sweeney Designs will again be used as an example.
2.3.5.1 Final data models
Figure 48 illustrates Heather Sweeney Designs: the final data model:
Figure 48 – Final data model
Source: Herbert Zuze
![Page 69: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/69.jpg)
Unit 2 – Database design Page 64
© CTI Education Group
2.3.5.2 Specifying column properties
Column properties must be specified for each table. The column properties for the Heather Sweeney Designs tables are illustrated in Figures Figure 49 to
Figure 54:
Figure 49 – Column properties (SEMINAR)
Source: Herbert Zuze
Figure 50 – Column properties (CUSTOMER)
Source: Herbert Zuze
Figure 51 – Column properties (CONTACT)
Source: Herbert Zuze
![Page 70: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/70.jpg)
Unit 2 – Database design Page 65
© CTI Education Group
Figure 52 – Column properties (INVOICE)
Source: Herbert Zuze
Figure 53 – Column properties (LINE_ITEM)
Source: Herbert Zuze
Figure 54 – Column properties (PRODUCT)
Source: Herbert Zuze
![Page 71: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/71.jpg)
Unit 2 – Database design Page 66
© CTI Education Group
Figure 55 illustrates Heather Sweeney Designs: the final data design:
Figure 55 – Final data design
Source: Herbert Zuze
The final data design for Heather Sweeney Designs is as follows:
SEMINAR (SeminarID, SeminarDate, SeminarTime, Location, SeminarTitle)
CUSTOMER (E-mailAddress, LastName, FirstName, Phone, StreetAddress, City, State, ZIP)
SEMINAR_CUSTOMER (SeminarID, E-mailAddress)
CONTACT (E-mailAddress, ContactDate, ContactNumber, ContactType,
SeminarID)
PRODUCT (ProductNumber, Description, UnitPrice, QuantityOnHand)
INVOICE (InvoiceNumber, InvoiceDate, PaymentType, Subtotal, Shipping, Tax, Total, E-mailAddress)
LINE_ITEM (InvoiceNumber, LineNumber, Quantity, UnitPrice, Total,
ProductNumber)
![Page 72: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/72.jpg)
Unit 2 – Database design Page 67
© CTI Education Group
2.3.5.3 Referential integrity constraints
Figure 56 illustrates Heather Sweeney Designs: referential integrity constraint enforcement:
Figure 56 – Referential integrity constraint enforcement
Source: Herbert Zuze
Supplementary reading Kroenke, D.M. & Auer, D.J. 2013. Database concepts. 6th
edition. New Jersey: Prentice Hall. Chapter 5.
2.4 Concluding remarks
This unit explored database design principles as well as various database
design models.
In the next unit, we will equip you with practical MySQL knowledge as it pertains to database development.
![Page 73: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/73.jpg)
Unit 2 – Database design Page 68
© CTI Education Group
2.5 Self-assessment
Test your knowledge
1. Give an example of a business rule that would need to be documented in a
database development project.
2. Explain the difference between entity classes and entity instances.
3. List the three types of binary relationship. Draw both a traditional ER diagram as well as an IE Crow’s Foot ER diagram for each.
4. Draw an IE Crow’s Foot ER diagram for the entities DEPARTMENT and
EMPLOYEE as well as the 1:N relationship between them. Assume that a
department does not need to have employees, but that every employee is assigned to a department. Include appropriate identifiers and attributes for
each entity.
5. Summarise the SDLC.
6. Describe the different types of relationship. Use examples to motivate and illustrate your answer.
![Page 74: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/74.jpg)
Unit 3 – Database development Page 69
© CTI Education Group
Unit 3 – Database development
Unit 3 is aligned with the following learning outcome and assessment criteria:
Learning outcome
LO3 Be able to design, create and document databases
Assessment criteria
AC3.1 Apply the database developmental life cycle to a given data set
AC3.2 Design a fully functional database (containing at least four inter-relational tables), including user interface
AC3.3 Evaluate the effectiveness of the database solution and suggest methods of improvement
Learning objectives
After studying this unit, you should be able to: Create a database
Create tables Create relationships between tables
Understand basic SQL statements Use basic SQL statements to add, modify and delete data
Use basic SQL statements to process single and multiple tables
Use SQL queries to extract data
Introduction
In this unit, you are introduced to MySQL. You will learn how to create a
database and various database objects. You will also learn how to query a database as well as how to manipulate data using various techniques.
This unit elaborates on the previous units and is meant to provide a solution to a business problem.
![Page 75: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/75.jpg)
Unit 3 – Database development Page 70
© CTI Education Group
3.1 MySQL 5.6 database software
Follow the following steps:
Download MySQL for Windows from http://dev.mysql.com/downloads Install MySQL with an administrator account:
Install MySQL on Windows using the Microsoft Software Installer
Package: o Download and start the MySQL Installation Wizard
o Click Custom Installation > OK Install MySQL additional optional components:
ODBC driver Connecter/net driver
Disable antivirus scanning on the main MySQL data directory (datadir) Disable antivirus scanning on the temporary MySQL data directory
(tmpdir)
MySQL has both a graphics user interface (GUI) and command line interface (CMD).
3.2 MySQL GUI
To access the MySQL GUI (Figure 57), click the following:
Start All Programs
MySQL MySQL Server 5.6
MySQL Workbench 6.1 CE
![Page 76: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/76.jpg)
Unit 3 – Database development Page 71
© CTI Education Group
Figure 57 – MySQL GUI
Source: Nyasha Magutsa
3.2.1 Creating a database
Follow the steps displayed in Figure 58 to Figure 61 to create a database:
Figure 58 – Creating a database
Source: Nyasha Magutsa
![Page 77: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/77.jpg)
Unit 3 – Database development Page 72
© CTI Education Group
Figure 59 – Creating a database (continued)
Source: Nyasha Magutsa
Figure 60 – Creating a database (continued)
Source: Nyasha Magutsa
![Page 78: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/78.jpg)
Unit 3 – Database development Page 73
© CTI Education Group
Figure 61 – Creating a database (continued)
Source: Nyasha Magutsa
3.2.2 Showing a database
Follow the step displayed in Figure 62 to view all databases on a database server:
Figure 62 – Showing a database
Source: Nyasha Magutsa
![Page 79: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/79.jpg)
Unit 3 – Database development Page 74
© CTI Education Group
3.2.3 Selecting a database
Follow the step displayed in Figure 63 to use a database for an operation; you
must select the database:
Figure 63 – Selecting a database
Source: Nyasha Magutsa
3.2.4 Deleting a database
Follow the step displayed in Figure 64 to delete a database; the database’s related objects will be removed; the process is irreversible:
Figure 64 – Deleting a database
Source: Nyasha Magutsa
![Page 80: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/80.jpg)
Unit 3 – Database development Page 75
© CTI Education Group
3.2.5 MySQL data types
MySQL tables contain multiple columns with different data types. Data type is
determined by the data that is stored in a particular column. Table 2 – Numeric data types to Table 5 summarise the different MySQL data types:
Table 2 – Numeric data types
Numeric type Description
TINYINT A very small integer
SMALLINT A small integer
MEDIUMINT A medium-sized integer
INT A standard integer
BIGINT A large integer
DECIMAL A fixed-point number
FLOAT A single precision floating-point number
DOUBLE A double precision floating-point number
BIT A bit field
Source: Herbert Zuze
Table 3 – String data types
String type Description
CHAR A fixed-length non-binary string
VARCHAR A variable-length non-binary string
BINARY A fixed-length binary string
VARBINARY A variable-length binary string
TINYBLOB A very small Binary Large Object (BLOB)
BLOB A small BLOB
MEDIUMBLOB A medium-sized BLOB
LONGBLOB A large BLOB
TINYTEXT A very small non-binary string
TEXT A small non-binary string
MEDIUMTEXT A medium-sized non-binary string
LONGTEXT A large non-binary string
ENUM An enumeration; each column value may be assigned to one
enumeration member only
SET A set; each column value may be assigned to zero or more set
members
Source: Herbert Zuze
Table 4 – Date and time data types
Date and time type Description
DATE A date value in ‘CCYY-MM-DD’ format
TIME A time value in ‘hh:mm:ss’ format
DATETIME A date and time value in ‘CCYY-MM-DD hh:mm:ss’ format
TIMESTAMP A timestamp value in ‘CCYY-MM-DD hh:mm:ss’ format
YEAR A year value in ‘CCYY’ or ‘YY’ format
Source: Herbert Zuze
![Page 81: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/81.jpg)
Unit 3 – Database development Page 76
© CTI Education Group
Table 5 – Spatial data types
Spatial type Description
GEOMETRY A spatial value of any type
POINT A point
LINESTRING A curve
POLYGON A polygon
GEOMETRYCOLLECTION A collection of geometry values
MULTILINESTRING A collection of linestring values
MULTIPOINT A collection of point values
MULTIPOLYGON A collection of polygon values
Source: Herbert Zuze
3.2.6 Creating a table
Create a table identical to Table 6 below:
Table 6 – CONTACT
Column name Data type Key Required
E-mailAddress VARCHAR (100) PK/FK Yes
ContactDate DATE PK Yes
ContactNumber INT (11) No Yes
ContactType VARCHAR (15) No Yes
Source: Herbert Zuze
Follow the steps displayed in Figure 65 – Creating a table to Figure 68 –
Creating a table (continued) to create the above table:
Figure 65 – Creating a table
Source: Nyasha Magutsa
![Page 82: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/82.jpg)
Unit 3 – Database development Page 77
© CTI Education Group
Figure 66 – Creating a table (continued)
Source: Nyasha Magutsa
Figure 67 – Creating a table (continued)
Source: Nyasha Magutsa
![Page 83: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/83.jpg)
Unit 3 – Database development Page 78
© CTI Education Group
Figure 68 – Creating a table (continued)
Source: Nyasha Magutsa
3.2.7 Showing a table
Follow the step displayed in Figure 69 – Showing a table to view all tables in a
database:
Figure 69 – Showing a table
Source: Nyasha Magutsa
![Page 84: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/84.jpg)
Unit 3 – Database development Page 79
© CTI Education Group
![Page 85: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/85.jpg)
Unit 3 – Database development Page 80
© CTI Education Group
3.2.8 Describing a table
Follow the step displayed in Figure 70 – Describing a table to describe a table
in a database:
Figure 70 – Describing a table
Source: Nyasha Magutsa
![Page 86: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/86.jpg)
Unit 3 – Database development Page 81
© CTI Education Group
3.2.9 Entering data into a table: Form Editor
Follow the steps displayed in Figure 71 – Entering data into a table: Form
Editor and Figure 72 to enter data into a table in Form Editor:
Figure 71 – Entering data into a table: Form Editor
Source: Nyasha Magutsa
Figure 72 – Entering data into a table: Form Editor (continued)
Source: Nyasha Magutsa
![Page 87: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/87.jpg)
Unit 3 – Database development Page 82
© CTI Education Group
3.2.10 Entering data into a table: Datasheet View
Follow the step displayed in Figure 73 to enter data into a table in Datasheet
View:
Figure 73 – Entering data into a table: Datasheet View
Source: Nyasha Magutsa
3.2.11 Deleting data from a table: Datasheet View
Follow the steps displayed in Figure 74 and Figure 75 to delete data from a table in Datasheet View:
Figure 74 – Deleting data from a table: Datasheet View
Source: Nyasha Magutsa
![Page 88: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/88.jpg)
Unit 3 – Database development Page 83
© CTI Education Group
Figure 75 – Deleting data from a table: Datasheet View
Source: Nyasha Magutsa
3.2.12 Altering table structure
Add the following columns (Table 7) to the table that you created (refer to
Table 6):
Table 7 – Additional columns to be added to CONTACT
Column name Data type Key Required
ContactID AUTONUMBER PK Yes
CustomerID INT (9) FK Yes
Source: Herbert Zuze
Follow the steps displayed in Figure 76 and Figure 77 to add the columns:
Figure 76 – Adding columns
Source: Nyasha Magutsa
![Page 89: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/89.jpg)
Unit 3 – Database development Page 84
© CTI Education Group
Figure 77 – Adding columns (continued)
Source: Nyasha Magutsa
3.2.13 Working with multiple tables
CustomerID in CUSTOMER must also exist in CONTACT (Figure 78):
Figure 78 – Working with multiple tables
Source: Nyasha Magutsa
![Page 90: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/90.jpg)
Unit 3 – Database development Page 85
© CTI Education Group
3.2.14 Working with multiple tables: Relationships Window
Follow the steps displayed in Figure 79 and Figure 80 to work with multiple
tables in the Relationships Window:
Figure 79 – Working with multiple tables: Relationships Window
Source: Nyasha Magutsa
Figure 80 – Working with multiple tables: Relationships Window (continued)
Source: Nyasha Magutsa
![Page 91: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/91.jpg)
Unit 3 – Database development Page 86
© CTI Education Group
3.2.15 Adding a table: Relationships Window
Follow the step displayed in Figure 81 to add a table in the Relationships
Window:
Figure 81 – Adding a table: Relationships Window
Source: Nyasha Magutsa
3.2.16 Creating a relationship: Relationships Window
To create a relationship between two tables, do the following (Figure 82):
In the Relationships Window, click on Relationship Type Click the Primary Key column in the first table
Click the Relating Column in the second table
![Page 92: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/92.jpg)
Unit 3 – Database development Page 87
© CTI Education Group
Figure 82 – Creating a relationship: Relationships Window
Source: Nyasha Magutsa
3.2.17 Working with multiple tables: Edit Relationships
Window
Follow the step displayed in Figure 83 to work with multiple tables in the Edit Relationships Window:
Figure 83 – Working with multiple tables: Edit Relationships Window
Source: Nyasha Magutsa
![Page 93: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/93.jpg)
Unit 3 – Database development Page 88
© CTI Education Group
3.2.18 Accessing a table: Form Editor
Follow the step displayed in Figure 84 to access a table in Form Editor:
Figure 84 – Accessing a table: Form Editor
Source: Nyasha Magutsa
3.3 MySQL CMD
3.3.1 MySQL background
SQL is a standard language used to access and manipulate databases; it is not
a programming language, as such, rather a data sub-language.
SQL is, further, an American National Standards Institute (ANSI) standard. It was originally developed by IBM in the 1970s.
SQL commands can be broken down into two categories, namely:
1. DDL: used to define database structures
2. DML: used to query and modify database data
Oracle, Sybase, Microsoft SQL Server, Microsoft Access and Ingres are some of the most common relational DBMSs that use SQL.
3.3.2 SQL for data definition
DDL is used to create and alter database structures, such as tables, as well as to insert, modify and delete data. Before creating tables, you must first create
a database. Although there is an SQL statement for creating such, most developers use graphics tools; these tools are, usually, DBMS-specific.
SQL data definition statements include:
CREATE: used to create database objects
ALTER: used to modify the structure and/or characteristics of database
objects
DROP: used to delete database objects
![Page 94: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/94.jpg)
Unit 3 – Database development Page 89
© CTI Education Group
TRUNCATE: used to delete table data while keeping the structure
To access the CMD, click the following: Start
All Programs MySQL
MySQL Server 5.6 MySQL 5.6 Command Line Client
Enter the root password (Figure 85):
Figure 85 – Entering the root password
Source: Nyasha Magutsa
You can now see the default command prompt (Figure 86):
Figure 86 – Default command prompt
Source: Nyasha Magutsa
![Page 95: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/95.jpg)
Unit 3 – Database development Page 90
© CTI Education Group
3.3.3 Creating a database
Before doing anything with your data, you need to create a database. A
database is a container of data; it stores information of any kind. In SQL, a database is a collection of objects that are used to store and manipulate data.
To create a database in SQL, use the CREATE DATABASE statement:
CREATE DATABASE [IF NOT EXISTS] database_name;
A database name should be meaningful and descriptive. IF NOT EXISTS is an
optional part of the statement. The statement prevents you from using a
database name that already exists in your database catalogue. No two databases can have the same name (Figure 87):
Figure 87 – Creating a database
Source: Nyasha Magutsa
![Page 96: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/96.jpg)
Unit 3 – Database development Page 91
© CTI Education Group
3.3.4 Showing a database
To view all databases on a database server, the SHOW DATABASE statement is
used (Figure 88): SHOW DATABASES;
Figure 88 – Showing a database
Source: Nyasha Magutsa
3.3.5 Selecting a database
To use a database for an operation, you must select such. The USE statement
is employed in this case (Figure 89): USE database_name;
Figure 89 – Selecting a database
Source: Nyasha Magutsa
After a database has been selected, all DML and DDL statements will be
affected on such.
![Page 97: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/97.jpg)
Unit 3 – Database development Page 92
© CTI Education Group
3.3.6 Creating a table
To create a table, the CREATE TABLE statement is used. This creates a structure
with defined data types, primary and other keys (optional). MySQL has made provision for specifying the table type (Figure 90):
CREATE TABLE [IF NOT EXISTS] table_name(
column_list
) type = table_-type
Figure 90 – Specifying a table type (syntax)
Source: Nyasha Magutsa
Column constraints to consider are PRIMARY KEY, NOT NULL, NULL and UNIQUE. In
addition to these, there is also a CHECK column constraint. Finally, the DEFAULT
keyword (this is not considered a column constraint) can be used to set initial values.
3.3.7 Showing and describing a table
To view all tables in a database as well as their table structures, the SHOW and
DESCRIBE statements are used (Figure 91 and Figure 92):
SHOW TABLES;
DESCRIBE table_name;
Figure 91 – Showing and describing a table (syntax)
Source: Nyasha Magutsa
Figure 92 – Showing and describing a table
Source: Nyasha Magutsa
![Page 98: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/98.jpg)
Unit 3 – Database development Page 93
© CTI Education Group
3.3.8 Creating a MySQL table
Create a table identical to Table 8 below:
Table 8 – CUSTOMER
Column name Type Key Required
CustomerID AUTONUMBER PK Yes
LastName CHAR (25) No Yes
FirstName CHAR (25) No Yes
Address CHAR (35) No No
City CHAR (35) No No
State CHAR (2) No No
Zip CHAR (10) No No
Source: Herbert Zuze
Your table should look as follows (Figure 93):
Figure 93 – Creating a MySQL table
Source: Nyasha Magutsa
The column constraint NOT NULL indicates that a value must be supplied when a
new row is created.
NULL indicates that null values are allowed, which means that a row can be
created without a value.
You can create database tables using PRIMARY KEY and FOREIGN KEY constraints.
![Page 99: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/99.jpg)
Unit 3 – Database development Page 94
© CTI Education Group
3.3.8.1 ALTER statement
Add a PK constraint to an existing table as follows (Figure 94 and Figure 95):
ALTER TABLE EMPLOYEE
ADD CONSTRAINT Emp_PK PRIMARY KEY(EmpID);
Figure 94 – Altering a table (syntax)
Source: Nyasha Magutsa
Figure 95 – Altering a table
Source: Nyasha Magutsa
Add a composite PK constraint to an existing table as follows:
Drop the existing key (Figure 96 and Figure 97):
ALTER TABLE EMPLOYEE
DROP PRIMARY KEY;
Figure 96 – Altering a table (syntax) (continued)
Source: Nyasha Magutsa
![Page 100: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/100.jpg)
Unit 3 – Database development Page 95
© CTI Education Group
Figure 97 – Altering a table (continued)
Source: Nyasha Magutsa
Add the new composite key (Figure 98 and Figure 99): ALTER TABLE EMPLOYEE
ADD CONSTRAINT EmpName_PK
PRIMARY KEY(EmpID, EmpSurname);
Figure 98 – Altering a table (syntax) (continued)
Source: Nyasha Magutsa
Figure 99 – Altering a table (continued)
Source: Nyasha Magutsa
![Page 101: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/101.jpg)
Unit 3 – Database development Page 96
© CTI Education Group
Add a FK constraint to an existing table as follows (Figure 100 to Figure 103): ALTER TABLE EMPLOYEE
ADD COLUMN ContactID mediumint(9);
Figure 100 – Altering a table (syntax) (continued)
Source: Nyasha Magutsa
Figure 101 – Altering a table (continued)
Source: Nyasha Magutsa
ALTER TABLE EMPLOYEE ADD
CONSTRAINT Emp_FK FOREIGN KEY(ContactID)
REFERENCES Contact(ContactID);
Figure 102 – Altering a table (syntax) (continued)
Source: Nyasha Magutsa
Figure 103 – Altering a table (continued)
Source: Nyasha Magutsa
![Page 102: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/102.jpg)
Unit 3 – Database development Page 97
© CTI Education Group
3.3.9 Relational data
DML is used to query databases and to modify table data. There are three
possible data modification operations, namely:
1. INSERT
2. UPDATE
3. DELETE
Data can be added to a relation by using the INSERT statement. This statement
has two forms, depending on whether data is supplied for all columns. Non-
numeric data must be enclosed in straight single quotes (').
If all column data is supplied, the INSERT statement can be used to insert data
into the EMPLOYEE table (Figure 104): INSERT INTO EMPLOYEE VALUES ('700', 'Golden', 'Barker', 'B', '3');
Figure 104 – Inserting data into a table
Source: Nyasha Magutsa
If the DBMS provides a surrogate key, the PK value does not need to be
specified. SQL comments are enclosed in the symbols /* and */; any text
between these symbols is ignored when SQL statements are executed.
3.3.10 Relational queries
After defining and populating a table, DML can be used to query data in many
ways as well as to change and delete it.
![Page 103: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/103.jpg)
Unit 3 – Database development Page 98
© CTI Education Group
3.3.10.1 SELECT/FROM/WHERE framework
SELECT is the best known SQL statement; it retrieves information from
databases that matches specified criteria using the SELECT/FROM/WHERE
framework (Figure 105):
SELECT ColumnName
FROM TableName
WHERE SomeConditionExists;
Figure 105 – SELECT/FROM/WHERE framework (syntax)
Source: Nyasha Magutsa
The result of a SELECT statement is a relation. This is always true for SELECT
statements. A SELECT statement starts with one or more relations, manipulates
this in some way and then produces relations. Even if the result of the manipulation is a single number, the number is considered to be a relation with
one row and one column. WHERE in a SELECT statement specifies the record to be
retrieved (Figure 106 to Figure 108):
SELECT EmpName
FROM EMPLOYEE
WHERE EmpID = 700;
Figure 106 – SELECT and WHERE statements (syntax)
Source: Nyasha Magutsa
or SELECT *
FROM CUSTOMER
WHERE CustomerID = 2;
Figure 107 – SELECT and WHERE statements (syntax) (continued)
Source: Nyasha Magutsa
![Page 104: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/104.jpg)
Unit 3 – Database development Page 99
© CTI Education Group
Figure 108 – SELECT and WHERE statements
Source: Nyasha Magutsa
The former retrieves all records under CUSTOMER that has the CustomerID ‘2’.
The asterisk (*) wildcard operator, after the keyword SELECT, can be used to
select all columns. The syntax is as follows (Figure 109):
SELECT *
FROM CUSTOMER;
Figure 109 – * wildcard operator (syntax)
Source: Nyasha Magutsa
The former retrieves every row (all columns) from the table CUSTOMER (Figure
110):
Figure 110 – * wildcard operator
Source: Nyasha Magutsa
![Page 105: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/105.jpg)
Unit 3 – Database development Page 100
© CTI Education Group
By default, DBMS products do not check for duplication. Thus, in practice, duplicate rows can occur. If you want a DBMS to check for and eliminate
duplicate rows, you must use the DISTINCT keyword (Figure 111):
SELECT DISTINCT FirstName
FROM CUSTOMER;
Figure 111 – DISTINCT keyword (syntax)
Source: Nyasha Magutsa
Many different conditions can be placed in a WHERE statement. Select all
columns from CUSTOMER where the value of the CustomerID column is
greater than ‘2’ by typing the following (Figure 112): SELECT *
FROM CUSTOMER
WHERE CustomerID > 2;
Figure 112 – WHERE statement (syntax)
Source: Nyasha Magutsa
You can also combine two or more conditions in a WHERE statement by using the
AND and OR keywords. If the AND keyword is used, only rows meeting all of the
conditions will be selected. If the OR keyword is used, rows that meet any of
the conditions will be selected. For example, the query below uses the AND
keyword to retrieve customers with the letter ‘i’ in their first name; they must
also reside in the ‘NW’ state (Figure 113 to Figure 115): SELECT *
FROM CUSTOMER
WHERE FirstName like '%i%'
AND State = 'NW';
Figure 113 – AND keyword (syntax)
Source: Nyasha Magutsa
![Page 106: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/106.jpg)
Unit 3 – Database development Page 101
© CTI Education Group
Figure 114 – AND keyword
Source: Nyasha Magutsa
SELECT EmpName
FROM EMPLOYEE
WHERE EmpID < 9
OR ContactID > 2;
SELECT EmpName
FROM EMPLOYEE
WHERE EmpGrade = 'A'
AND EmpID < 800;
Figure 115 – AND keyword (syntax) (continued)
Source: Nyasha Magutsa
A WHERE statement may, further, include the IN keyword to specify that a
particular column value must be included in the list of values (Figure 116):
SELECT EmpName
FROM EMPLOYEE
WHERE EmpGrade IN ('A', 'B');
Figure 116 – IN keyword (syntax)
Source: Nyasha Magutsa
Any statement may be preceded by the NOT operator, which is to say that all
information will be shown except information matching the specified criteria
(Figure 117 and Figure 118): SELECT EmpName
FROM EMPLOYEE
WHERE ContactID NOT IN (1, 2, 9);
Figure 117 – NOT operator (syntax)
Source: Nyasha Magutsa
![Page 107: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/107.jpg)
Unit 3 – Database development Page 102
© CTI Education Group
Figure 118 – NOT operator
Source: Nyasha Magutsa
The BETWEEN keyword allows a user to specify minimum and maximum values
on one line (Figure 119 and Figure 120):
SELECT EmpName
FROM EMPLOYEE
WHERE ContactID BETWEEN 1 AND 2;
Figure 119 – BETWEEN keyword (syntax)
Source: Nyasha Magutsa
Figure 120 – BETWEEN keyword
Source: Nyasha Magutsa
![Page 108: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/108.jpg)
Unit 3 – Database development Page 103
© CTI Education Group
3.3.11 Comparison operators
Table 9 lists the most common comparison operators:
Table 9 – Comparison operators
Operator Description
= Equal to
> Greater than
< Less than
>= Greater than or equal to
<= Less than or equal to
<> Not equal to
Source: Herbert Zuze
The LIKE keyword is used to select partial values. It is used in combination with
wildcard characters, which represent unknown characters in patterns.
The underscore (_) is used to represent a single, unspecified character. The
percent sign (%) is used to represent a series of one or more unspecified
characters.
In the following query, LIKE is used to find values that fit a pattern (Figure
121):
SELECT *
FROM STUDENT
WHERE ModuleName LIKE 'CINT 1_Networking';
Figure 121 – LIKE keyword (syntax)
Source: Herbert Zuze
A % query could be written as follows (Figure 122):
SELECT *
FROM STUDENT
WHERE Phone LIKE '021 360-%';
Figure 122 – % query (syntax)
Source: Herbert Zuze
If you want to query all students who work in departments that end in ‘ing’,
you can use % as follows (Figure 123):
SELECT *
FROM STUDENT
WHERE DepartmentName LIKE '%ing';
Figure 123 – % query (syntax) (continued)
Source: Herbert Zuze
![Page 109: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/109.jpg)
Unit 3 – Database development Page 104
© CTI Education Group
3.3.12 Sorting a query result
The order of rows in the result of a SELECT statement is somewhat arbitrary. If
this is undesirable, you can use the ORDER BY statement to sort the rows. For
example, the following syntax will display the names, telephone numbers and
modules of all students, sorted by LastName (Figure 124): SELECT FirstName, LastName, Phone, ModuleName
FROM STUDENT
ORDER BY LastName;
Figure 124 – ORDER BY statement (syntax)
Source: Herbert Zuze
By default, SQL sorts rows in ascending order. The ASC and DESC keywords can
be used to specify ascending and descending order. Thus, to sort students in descending order by LastName, type the following (Figure 125):
SELECT FirstName, LastName, Phone, ModuleName
FROM STUDENT
ORDER BY LastName DESC;
Figure 125 – DESC keyword (syntax)
Source: Herbert Zuze
3.3.13 Built-in functions and calculations
SQL allows you to calculate values based on table data. You can use arithmetic
formulae or SQL built-in functions, such as:
COUNT: used to count the number of rows that match specified criteria
MIN: used to find the minimum value in a specific column
MAX: used to find the maximum value in a specific column
SUM: used to calculate the sum of a specific column
AVG: used to calculate the numeric average of a specific column
Examples are illustrated in Figure 126 to Figure 128: SELECT COUNT(EmpID)
FROM EMPLOYEE;
SELECT COUNT(*)
FROM CUSTOMER;
Figure 126 – COUNT built-in function (syntax)
Source: Nyasha Magutsa
![Page 110: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/110.jpg)
Unit 3 – Database development Page 105
© CTI Education Group
Figure 127 – COUNT built-in function
Source: Nyasha Magutsa
SELECT MIN (Hours) AS MinimumHours,
MAX (Hours) AS MaximumHours,
AVG (Hours) AS AverageHours
FROM PROJECT
WHERE ProjID > 7;
Figure 128 – MIN, MAX and AVG built-in functions (syntax)
Source: Nyasha Magutsa
3.3.14 Built-in functions and grouping
In SQL, you can use the GROUP BY statement to group rows by common values;
this increases the utility of built-in functions as you can apply this to groups of rows.
Figure 129 serves as an example:
SELECT ModuleName, Count(*) AS NumberOfStudents
FROM STUDENT
GROUP BY ModuleName;
Figure 129 – GROUP BY statement (syntax)
Source: Herbert Zuze
A GROUP BY statement tells a DBMS to sort a table by the named column and
then to apply the built-in function to groups of rows that have the same value
for the named column. When GROUP BY is used, the name of the grouping
column and built-in function may appear in the SELECT statement. This is the
only time that a column name and built-in function can appear together.
You can further restrict results by using the HAVING statement to apply
conditions to groups that are formed. For example, if you want to consider only
![Page 111: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/111.jpg)
Unit 3 – Database development Page 106
© CTI Education Group
groups with more than two members, you could specify such as follows (Figure 130):
SELECT ModuleName, Count(*) AS NumberOfStudents
FROM STUDENT
GROUP BY ModuleName
HAVING COUNT(*) > 2;
Figure 130 – HAVING statement (syntax)
Source: Nyasha Magutsa
3.3.15 Querying multiple tables with joins
Sometimes more than one table must be processed to obtain the desired information. Sub-queries are effective for processing multiple tables as long as
the results come from a single table. If you, however, need to display data from two or more tables, sub-queries will not work. You then need to use a
JOIN statement. There are five types of JOIN statement, namely: 1. INNER JOIN
2. LEFT OUTER JOIN
3. RIGHT OUTER JOIN
4. FULL OUTER JOIN
5. CROSS JOIN
An INNER JOIN iterates through each row in two tables and matches the rows
that are common. It looks at each row in both tables and, if the condition is
met, the rows are included in the results set. LEFT OUTER JOIN, RIGHT OUTER JOIN
and FULL OUTER JOIN are used to include rows that do not have anything in
common with the other table. This is useful to identify rows that have things in
common along with the ones that do not.
Examples are illustrated in Figure 131 to Figure 133: SELECT EmpName
FROM EMPLOYEE AS E, CONTACT AS C
WHERE E.ContactID = C.ContactID
AND E.EmpGrade LIKE 'A';
Figure 131 – JOIN statement (syntax)
Source: Nyasha Magutsa
![Page 112: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/112.jpg)
Unit 3 – Database development Page 107
© CTI Education Group
Figure 132 – JOIN statement
Source: Nyasha Magutsa
SELECT EmpName
FROM EMPLOYEE AS E JOIN DEPARTMENT AS D
ON E.DeptID = D.DeptID
WHERE D.DeptName LIKE 'Account%';
SELECT EmpName
FROM EMPLOYEE AS E
LEFT JOIN DEPARTMENT AS D
ON E.DeptID = D.DeptID
WHERE D.DeptName LIKE 'Account%';
SELECT EmpName
FROM EMPLOYEE AS E
RIGHT JOIN DEPARTMENT AS D
ON E.DeptID = D.DeptID
WHERE D.DeptName LIKE 'Account%';
Figure 133 – JOIN statements (syntax)
Source: Nyasha Magutsa
3.3.16 Relational data modification and deletion
A DDL contains commands for three possible data modification operations. We have already discussed inserting data; we will now consider modifying and
deleting data.
INSERT and UPDATE statements can be combined into one statement. This uses
the equivalent of if-then-else logic to decide whether to use INSERT or UPDATE.
An advance feature is to learn to use INSERT and UPDATE separately first and
then to consult DBMS documentation.
![Page 113: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/113.jpg)
Unit 3 – Database development Page 108
© CTI Education Group
3.3.16.1 Modifying data
The UPDATE . . . SET command can be used to modify existing data. This is a
powerful command that needs to be used with care. It can modify more than one column value at a time, as shown in the example:
If a customer with CustomerID ‘6’ changes their LastName to ‘Waver’, the
following syntax can be used to update their data (Figure 134 and Figure 135): UPDATE CUSTOMER
SET LastName = 'Waver'
WHERE CustomerID = 6;
Figure 134 – UPDATE statement (syntax)
Source: Nyasha Magutsa
Figure 135 – UPDATE statement
Source: Nyasha Magutsa
The former changes the value of LastName for CUSTOMER. You can use a
SELECT statement to view the result (Figure 136):
SELECT *
FROM Customer
WHERE CustomerID = '6';
Figure 136 – UPDATE statement result (syntax)
Source: Nyasha Magutsa
3.3.16.2 Deleting data
A DELETE statement can be used to eliminate rows. DELETE is deceptively simple
to use and easy to apply in unintended ways thus care should be taken. The following, for example, deletes all employees whose EmpID is 1 000 (Figure
137 and Figure 138):
![Page 114: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/114.jpg)
Unit 3 – Database development Page 109
© CTI Education Group
DELETE
FROM Employee
WHERE EmpID = '1000';
Figure 137 – DELETE statement (syntax)
Source: Nyasha Magutsa
Figure 138 – DELETE statement
Source: Nyasha Magutsa
To delete all rows in EMPLOYEE, use the following syntax (Figure 139): DELETE
FROM Employee;
Figure 139 – DELETE statement (syntax) (continued)
Source: Nyasha Magutsa
3.3.17 Table and constraint modification and deletion
3.3.17.1 DROP TABLE statement
The DROP TABLE statement is also a dangerous SQL statement as it drops a
table’s structure along with all of the table’s data. For example, to drop the
EMPLOYEE table, use the following syntax: DROP TABLE Employee;
A DROP TABLE statement does not work if the table contains or could contain
values needed to fulfil referential integrity constraints. In such a case, an
attempt to issue the statement fails and an error message is generated.
3.3.17.2 Deleting a database
To remove a database, a DROP statement is used. A database’s related objects
will also be deleted; the process is irreversible (Figure 140):
DROP DATABASE [IF EXISTS] database_name;
![Page 115: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/115.jpg)
Unit 3 – Database development Page 110
© CTI Education Group
Figure 140 – DROP statement
Source: Nyasha Magutsa
3.3.18 SQL views
A SQL view is a virtual table created by a DBMS-stored SELECT statement. A
view can combine access to data in multiple tables and even in other views. A
view has no data of its own; it uses data stored in tables or in other views.
Views are created by using a SELECT statement. Views are used just as if they
were a table. The statements that create views may not contain ORDER BY
statements. If the results of a query need to be sorted, the sort order must be
provided by a SELECT statement that processes the view.
A CREATE VIEW statement is used to create view structures (Figure 141 to Figure
143): CREATE VIEW ViewName AS
{SQL SELECT statement};
Figure 141 – CREATE VIEW statement (syntax)
Source: Nyasha Magutsa
CREATE VIEW EmployeeNames AS
SELECT EmpName, EmpSurname,
EmpGrade AS EmployeeRank
FROM EMPLOYEE;
Figure 142 – CREATE VIEW statement (syntax) (continued)
Source: Nyasha Magutsa
![Page 116: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/116.jpg)
Unit 3 – Database development Page 111
© CTI Education Group
Figure 143 – CREATE VIEW statement
Source: Nyasha Magutsa
Once a view has been created, it can be used in the FROM clause of a SELECT
statement (Figure 144 and Figure 145): SELECT *
FROM EmployeeNames
ORDER BY EmpName;
Figure 144 – FROM clause (syntax)
Source: Nyasha Magutsa
Figure 145 – FROM clause
Source: Nyasha Magutsa
SQL views can also be used to: Hide columns or rows
Display computation results Hide complicated SQL syntax
Layer built-in functions
![Page 117: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/117.jpg)
Unit 3 – Database development Page 112
© CTI Education Group
Supplementary reading
Kroenke, D.M. & Auer, D.J. 2013. Database concepts. 6th edition. New Jersey: Prentice Hall. Chapter 5.
3.4 Concluding remarks
This unit provided a practical approach to database development.
In the next unit, we will highlight how databases are managed and documented.
3.5 Self-assessment
Test your knowledge
1. Create a database using the design of Figure 55 in Unit 2. Use MySQL to
create three tables and the CMD to create four tables and their relationships.
2. Explain DDL and DML.
![Page 118: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/118.jpg)
Unit 4 – Database management Page 113
© CTI Education Group
Unit 4 – Database management
Unit 4 is aligned with the following learning outcome and Assessment Criterion:
Learning outcome
LO3 Design, create and document databases
Assessment Criterion
AC3.3 Provide supporting user and technical documentation
Learning objectives
After studying this unit, you should be able to:
Understand the need for and importance of database administration Understand the need for concurrency, security, backup and recovery
Understand the different ways of processing databases Understand the use of locking and the problem of deadlock
Be familiar with ACID (Atomic, Consistent, Isolated, Durable) transactions Know the difference between recovery via reprocessing and
rollback/rollforward Understand rollback/rollforward
Understand Web database processing Understand the basic concepts of big data and structured storage
Understand the basic concepts of data warehouses and data marts
Introduction
In this unit, we focus on database management; this includes sections on problems that can occur when databases are processed concurrently by more
than one user. You will also learn about how databases support data warehouses, modern Business Intelligence (BI) systems and big data.
Activity
Write down what you think database management is about and what kind of business problems can be solved by proper
database management.
![Page 119: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/119.jpg)
Unit 4 – Database management Page 114
© CTI Education Group
4.1 Database administration
4.1.1 Responsibilities
The three major concerns of database administration are:
1. Concurrency control 2. Security
3. Reliability
A database administrator needs to ensure that a system exists to gather and record user reported errors and other problems. A means needs to be devised
to prioritise such errors and problems and to ensure that they are corrected accordingly.
A database administrator also needs to create and manage a process to control
database configuration. This entails procedures to create projects and tasks, record change requests and conduct user and developer reviews of such
requests.
Database administrators are responsible for ensuring that appropriate
documentation is maintained for: Database structures
Concurrency control Security
Backup and recovery Applications
4.1.2 Database processing environment I
Databases come in a variety of sizes and scope, from single user databases to
large organisational databases, such as inventory management systems. Databases also vary in the way that they are processed.
![Page 120: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/120.jpg)
Unit 4 – Database management Page 115
© CTI Education Group
Figure 146 illustrates the database processing environment:
Figure 146 – Database processing environment
Source: Herbert Zuze
Three necessary database administration functions are:
1. Concurrency control 2. Security
3. Backup and recovery
We will now investigate some of the issues surrounding these.
4.1.3 Concurrency control
Concurrency control ensures that one user’s actions do not adversely affect another user’s actions. At the core of concurrency is accessibility. In one
extreme, data becomes inaccessible once a user touches it. Concurrency thus ensures that data that is being considered for update is not shown. In another
extreme, data is always readable even when it is locked for update.
Interdependence refers to changes required by one user that may affect
another user. Concurrency refers to people or applications that may try to update the same information at the same time. Record retention is when
information should be discarded.
![Page 121: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/121.jpg)
Unit 4 – Database management Page 116
© CTI Education Group
4.1.3.1 Need for atomic transactions
Database operations, typically, involve several transactions. These transactions
are atomic and often called ‘Logical Units of Work’ (LUW). Before an operation is committed, all LUW must be successfully completed. If one or more LUW is
unsuccessful, a rollback is performed and no changes are saved to the database. If two transactions are being processed against a database at the
same time, they are termed a ‘concurrent transaction’ (Figure 147):
Figure 147 – Concurrent transaction
Source: Herbert Zuze
4.1.3.2 Lost update problem
If two or more users are attempting to update the same piece of data at the
same time, it is possible that one update may overwrite the other (Figure 148):
![Page 122: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/122.jpg)
Unit 4 – Database management Page 117
© CTI Education Group
Figure 148 – Lost update problem
Source: Herbert Zuze
Other concurrency issues include the following:
Dirty read: a transaction that reads a changed record that has not been
committed to a database Inconsistent read: a transaction that rereads a data set and finds that data
has changed Phantom read: a transaction that rereads a data set and finds that a new
record has been added
4.1.3.3 Resource locking
To avoid concurrency issues, resource locking will not allow transactions to
read from, modify or write to data sets that have been locked. Implicit locks are issued automatically by DBMSs whereas explicit locks are issued by users
requesting exclusive rights to data. Figure 149 illustrates concurrent processing with explicit locks:
![Page 123: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/123.jpg)
Unit 4 – Database management Page 118
© CTI Education Group
Figure 149 – Concurrent processing with explicit locks
Source: Herbert Zuze
4.1.3.4 Serialisable transactions
When two or more transactions are processed concurrently, database results
should be logically consistent with the results that would have been achieved had the transactions been processed in an arbitrary serial fashion. A scheme
for processing concurrent transactions in this way is said to be ‘serialisable’.
One way to achieve serialisable transactions is by using two-phase locking. Two-phase locking allows locks to be obtained and released as they are
needed. A growing phase is when a transaction continues to request additional locks whereas a shrinking phase is when a transaction begins to release locks.
4.1.3.5 Deadlock
As a transaction begins to lock resources, it may have to wait for a particular
resource to be released by another transaction. On occasion, two transactions may indefinitely wait for each other to release a resource; this condition is
known as ‘deadlock’ or a ‘deadly embrace’ (Figure 150):
![Page 124: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/124.jpg)
Unit 4 – Database management Page 119
© CTI Education Group
Figure 150 – Deadlock
Source: Herbert Zuze
4.1.3.6 Optimistic vs pessimistic locking
Optimistic locking (Figure 151) entails: Reading data
Processing transactions Issuing updates
Looking for conflict
Figure 151 – Optimistic locking
Source: Herbert Zuze
If no conflict occurs, a transaction is committed; if not, rollback occurs and the transaction is repeated.
![Page 125: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/125.jpg)
Unit 4 – Database management Page 120
© CTI Education Group
Pessimistic locking (Figure 152) entails: Lock-required resources
Reading data Processing transactions
Issuing commitments Releasing locks
Figure 152 – Pessimistic locking
Source: Herbert Zuze
4.1.3.7 Consistent transactions
Consistent transactions are often referred to by the acronym ACID (Atomic,
Consistent, Isolated, Durable).
Atomic
An atomic transaction is one in which all database actions occur or none occur. A transaction consists of a series of steps; each step must be successful for the
transaction to be saved. This ensures that transactions complete everything as intended before saving changes.
Consistent
No other transactions are permitted until the current transaction has finished. This ensures that transaction integrity has statement level consistency across
all records.
![Page 126: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/126.jpg)
Unit 4 – Database management Page 121
© CTI Education Group
Isolated Within multiuser environments, different transactions may be operating on the
same data. In such a case, the sequencing of uncommitted updates and rollbacks commit changes to data content. The 1992 ANSI SQL (Figure 153)
defines four isolation levels that specify which concurrency control problems are allowed to occur:
Figure 153 – Isolation levels
Source: Herbert Zuze
Durable
A durable transaction is one in which all committed changes are permanent.
4.1.3.8 Cursors
A cursor is a pointer to a set of rows that are the result from a SQL SELECT
statement. Cursors are, usually, defined using SELECT statements (Figure 154):
DECLARE CURSOR TransCursor AS
SELECT *
FROM SALE_TRANSACTION
WHERE PurchasePrice > '10000';
Figure 154 – Cursor (syntax)
Source: Herbert Zuze
There are forward only and scrollable cursor types. In SQL, for forward only or scrollable cursors, there are three types, namely:
Static cursors
Keyset cursors Dynamic cursors
![Page 127: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/127.jpg)
Unit 4 – Database management Page 122
© CTI Education Group
Other DBMS products may define a different set of cursors. In such a case, the forward only cursor is considered a separate cursor type whereas the scrollable
cursor may be static, keyset or dynamic (Figure 155):
Figure 155 – Cursor types
Source: Herbert Zuze
4.1.4 Security
Database security strives to ensure that only authenticated users perform
authorised activities (Figure 156):
Figure 156 – Database security authentication and authorisation
Source: Herbert Zuze
4.1.4.1 Processing rights and responsibilities
Processing rights define who is permitted to do what and when. Individuals
performing activities assume full responsibility for the implications of their actions. Individuals are identified by a username and password.
![Page 128: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/128.jpg)
Unit 4 – Database management Page 123
© CTI Education Group
A DBMS security model (Figure 157) may look like this:
Figure 157 – DBMS security model
Source: Herbert Zuze
Processing rights at Heather Sweeney Designs (Figure 158) may look like this:
Figure 158 – Processing rights
Source: Herbert Zuze
4.1.4.2 Granting permissions
Database users are known as individuals and members with one or more roles.
Access and processing rights may be granted to individuals and/or roles. Users possess a compilation of rights granted to individuals and all roles for which
they are members.
![Page 129: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/129.jpg)
Unit 4 – Database management Page 124
© CTI Education Group
4.1.4.3 Database security guidelines
The following database security guidelines are useful:
Run a DBMS behind a firewall Apply the latest operating system and DBMS service packs and patches
Limit DBMS functionality to needed features only Protect computers that run a DBMS
Manage accounts and passwords
4.1.5 Backup and recovery
Common causes of database failures are: Hardware failures
Programming bugs Human errors/mistakes
Malicious actions
The above are impossible to avoid completely; recovery procedures are thus essential.
4.1.5.1 Recovery via reprocessing
In reprocessing, all activities since a backup was performed are redone; this is a brute force technique. This procedure is costly in terms of effort as data
needs to be re-entered. It is also risky in that human error is likely and paper record keeping may not be accurate.
4.1.5.2 Recovery via rollback and rollforward
Most DBMSs provide a mechanism to record activity in a log file.
To undo a transaction, the log file must contain a copy of every database
record before it was changed; such records are called ‘before-images’. A transaction is undone by applying before-images to a database.
To redo a transaction, the log file must contain a copy of every database
record after it was changed; such records are called ‘after-images’. A transaction is redone by applying after-images to a database.
A log file is used for recovery via rollback or rollforward.
![Page 130: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/130.jpg)
Unit 4 – Database management Page 125
© CTI Education Group
Rollback A log file saves activities in sequence order. It is possible to undo activities in
reverse order back to the original. This is performed to correct/undo erroneous or malicious transactions after a database has been recovered from a full
backup (Figure 159):
Figure 159 – Rollback
Source: Herbert Zuze
Rollforward Activities recorded in a log file may be replayed. In doing so, all activities are
reapplied to a database. This procedure is used to resynchronise restored database data by adding transactions to the last full backup (Figure 160):
Figure 160 – Rollforward
Source: Herbert Zuze
![Page 131: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/131.jpg)
Unit 4 – Database management Page 126
© CTI Education Group
An example of a transaction log (Figure 161) may look like this:
Figure 161 – Transaction log
Source: Herbert Zuze
An example of a recovery (Figure 162 and Figure 163) may look like this:
Figure 162 – Problem processing
Source: Herbert Zuze
![Page 132: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/132.jpg)
Unit 4 – Database management Page 127
© CTI Education Group
Figure 163 – Recovery processing
Source: Herbert Zuze
Supplementary reading Kroenke, D.M. & Auer, D.J. 2013. Database concepts. 6th
edition. New Jersey: Prentice Hall. Chapter 6.
4.2 Database applications processing
4.2.1 Database processing environment II
As stated earlier, databases vary considerably in size, scope and the way in
which they are processed. Some databases only have a few forms and reports whereas others are processed via applications using Internet technology, such
as active server pages (ASPs.NET) or Java server pages (JSPs). Databases can also be processed via application programs or stored procedures and triggers.
A database processing environment is clearly complex. It has multiple: Users
Queries Forms
Reports Application programs
![Page 133: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/133.jpg)
Unit 4 – Database management Page 128
© CTI Education Group
4.2.1.1 Processing constraints
Database processing constraints include:
Enforcing referential integrity Cascading modifications
Cascading deletions Data type constraints
Data size constraints Data value constraints
Null constraints Uniqueness constraints
4.2.1.2 Triggers and stored procedures
Enterprise-class DBMS products include features that enable developers to
create modules of logic and database actions (called ‘triggers’ and ‘stored procedures’). Triggers and stored procedures are written in a language
provided by a DBMS.
A trigger is a stored procedure that is automatically invoked by a DBMS when a specified activity occurs (before, after and instead of).
A stored procedure is a module similar to a sub-routine or function that
performs database actions.
4.3 Internet applications processing
Internet application processing is more complicated than traditional application processing. With Internet application processing, the network becomes an
integral part of the application (Figure 164):
Figure 164 – Internet application processing
Source: Herbert Zuze
![Page 134: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/134.jpg)
Unit 4 – Database management Page 129
© CTI Education Group
4.3.1 Application programming interfaces (APIs)
Every DBMS product has an API. An API is a collection of objects, methods and
properties used to execute DBMS functions. Each DBMS has its own API and it varies from one DBMS product to another. To simplify this situation, the
computer industry has developed standards for database access.
4.3.1.1 ODBC and Object Linking and Embedding Databases (OLEDBs)
The ODBC Standard was developed in the early 1990s; such provides DBMSs
with an independent means of processing relational database data.
OLEDBs were created by Microsoft in the mid-1990s; these are object-oriented interfaces that encapsulate data-server functionality. The design is not just
aimed at relational database access but also at many other types of data access. OLEDBs are readily accessible to programming languages, such as C#
and Java. Such is, however, not as accessible to Visual Basic or other scripting languages.
4.3.1.2 Active data objects (ADOs) and ADO.NET
Microsoft developed ADOs as sets of objects to use in OLEDBs. Any language, including Visual Basic, Visual Basic Script and Jscript, can be used in this
instance.
ADOs have been followed by ADO.NET, which is an improved version; it was
developed as part of a Microsoft .NET initiative. The role of ADO.NET in a Web database processing environment is illustrated in Figure 165:
Figure 165 – ADO.NET
Source: Herbert Zuze
4.3.2 N-tier architecture
Tiers refer to the number of computers involved in a Web database application: The workstation with Web browser is the first tier
The Web server is the second tier; this is on the same server as the DBMS The Web server is the third tier; this is not on the same server as the
DBMS
![Page 135: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/135.jpg)
Unit 4 – Database management Page 130
© CTI Education Group
Figure 166 illustrates an ODBC three-tier Web server architecture:
Figure 166 – ODBC three-tier Web server architecture
Source: Herbert Zuze
Supplementary reading
Kroenke, D.M. & Auer, D.J. 2013. Database concepts. 6th edition. New Jersey: Prentice Hall. Chapter 7.
4.4 Distributed database processing
A database is distributed when it is:
Partitioned Replicated
Both partitioned and replicated
Distributed database processing is fairly straightforward in the case of read-
only replicas but can be very difficult to apply to other installations.
![Page 136: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/136.jpg)
Unit 4 – Database management Page 131
© CTI Education Group
There are different types of distributed database, as shown in Figure 167:
Figure 167 – Types of distributed database
Source: Herbert Zuze
4.4.1 Object-relational database management
Object-Oriented Programming (OOP) is based on objects; it is used as a basis
for many computer programming languages, for example, Java, Visual Basic and C#.
4.4.1.1 Object classes
Object classes have identifiers, properties (data items associated with objects) and methods (programs that allow objects to perform tasks). The only
difference between entity and object classes is methods.
4.4.1.2 Object persistence
Object persistence refers to the values of object properties that are storable and retrievable. Object persistence can be achieved via various techniques,
such as database technologies and relational databases.
![Page 137: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/137.jpg)
Unit 4 – Database management Page 132
© CTI Education Group
4.4.1.3 Object-Oriented DBMSs (OODBMSs)
OODBMSs have never achieved commercial success as it is too expensive to
transfer existing data from relational or Legacy databases. OODBMSs are, therefore, not cost justifiable.
4.4.1.4 Object-relational DBMSs
Some relational DBMS vendors have added object-oriented features to their products, for example, Oracle. These products are known as ‘object-relational
DBMSs’; they support object-relational databases.
Supplementary reading Kroenke, D.M. & Auer, D.J. 2013. Database concepts. 6th
edition. New Jersey: Prentice Hall. Chapter 8.
4.5 Concluding remarks
This unit explored basic database management aspects. Emphasis was placed on how to resolve highlighted issues.
4.6 Self-assessment
Test your knowledge
1. What is the purpose of database administration?
2. What is the purpose of concurrency control?
3. What is the goal of database security systems?
4. Explain two-phase locking.
5. Explain serialisable transactions.
6. Describe, in your own words, the nature of traditional database processing applications.
7. Name three types of trigger.
![Page 138: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/138.jpg)
Unit 4 – Database management Page 133
© CTI Education Group
8. What are stored procedures and how are they used?
9. Name the three major components of Web database applications.
10. What are BI systems?
11. Name and describe the two main categories of BI systems.
12. What are the three sources of data in BI systems?
![Page 139: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/139.jpg)
Glossary Page 134
© CTI Education Group
Glossary
1:1 An abbreviation for a one-to-one relationship between the rows of two
tables
1:N An abbreviation for a one-to-many relationship between the rows of
two tables.
Active Data Object
(ADO)
An implementation of an object linking and embedding database
accessible via object- and non-object-oriented languages; it is used
primarily as a scripting language interface
Application
Programming
Interface (API)
A set of objects, methods and properties used to access the
functionality of a program
Association entity An entity that represents the combination of at least two objects
Attribute A value that represents a characteristic of an entity/column
Big data An enormous data set created by Web applications
Boyce-Codd
Normal Form
(BCNF)
A relation in third normal form, in which every determinant is a
candidate key
Business
Intelligence (BI)
system
An information system used to assist managers and other professionals
to analyse current and past activities as well as to predict future events
Candidate key An attribute or group of attributes that identify a unique row in a
relation; it is chosen to be the primary key
Cardinality
In a binary relationship, the maximum or minimum number of
elements allowed on each side of the relationship: maximum
cardinality can be 1:1, 1:N or N:M; minimum cardinality can be
optional/optional, optional/mandatory, mandatory/optional or
mandatory/mandatory
Composite key A key in a relation that consists of two or more columns
Data
administration
An enterprise-wide function that effectively uses and controls
organisational data assets
Data Definition
Language (DDL) A language used to describe the structure of a database
Data Manipulation
Language (DML) A language used to describe the processing of a database
Data mart
A facility similar to a data warehouse but with a restricted domain;
data is often restricted to a particular type, business function or
business unit
Data model
A model detailing user data requirements; this is, usually, expressed in
an Entity-Relationship Model/a language used to describe the structure
and processing of a database
Data warehouse
A store of enterprise data that is designed to facilitate management
decision making; this includes not only data, but also meta data, tools,
procedures, training, personnel information and other resources
Database A self-describing collection of related records, or, in the case of a
relational database, related tables
Database
administration
A function that effectively uses and controls a particular database and
its related applications
Database
administrator
A person or group responsible for establishing policies and procedures
(used to control and protect a database)
Database backup A copy of database files that can be used to restore it to some previous
consistent state
Database design A graphic display of tables (files) and their relationships; tables are
shown in rectangles and relationships are shown with lines
![Page 140: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/140.jpg)
Glossary Page 135
© CTI Education Group
Database
Management
System (DBMS)
A set of programs used to define, administer and process a database
and its applications
Database schema A complete logical view of a database
Deadlock A condition that can occur during concurrent processing, in which two
(or more) transactions are waiting to access data
Denormalisation A process of intentionally designing a relation that is not normalised;
this is performed to improve performance or security
Distributed
database A database that is stored and processed on two or more computers
Enterprise-class
database system
A database management system capable of supporting the operating
requirements of a large organisation
Entity Something of importance to a user that needs to be represented in a
database
Entity class A set of entities of the same type
Entity instance A particular occurrence of an entity
Entity-relationship
(ER) Model
A model detailing user data; which is represented by entities and
relationships
First normal form
(1NF) A table that fits the definition of a relation
Foreign key (FK) An attribute that is a key in one or more relations other than the one in
which it appears
Form A structured onscreen presentation of selected data from a database;
this is used to input and read data
Functional
dependency
A relationship between attributes, in which one attribute or group of
attributes determine the value of the other
Identifier In an entity, a group of one or more attributes that determine an entity
instance
Identity (ID)-
dependent entity
An entity that cannot logically exist without the existence of another
entity
Information
Engineering (IE)
Crow’s Foot Model
A system of symbols used to construct Entity-Relationship diagrams in
data modelling and database design
Insertion anomaly In a relation, a condition that exists when adding a complete row to a
table
N:M An abbreviation for a many-to-many relationship between the rows of
two tables
Normal Form (NF)
A rule or set of rules governing the allowed structure of a relation;
rules apply to attributes, functional dependencies, domains and
constraints
Normalisation
A process wherein a relation is evaluated to determine whether it is in
a specified normal form; if necessary, said relation is converted to said
specified normal form
Primary key (PK) A candidate key selected to be the key of a relation; this uniquely
identifies the records (rows) in a table relation
Record A group of fields pertaining to the same entity/in the Relational Model,
a synonym for row and tuple
Referential
integrity constraint A relationship constraint imposed on foreign key values
Relation
A two-dimensional array that contains single value entries and no
duplicate rows; the meaning of columns is the same in every row
whereas the order of rows and columns is immaterial
Relational
database
A database that consists of relations; in practice, it contains relations
with duplicate rows
![Page 141: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/141.jpg)
Glossary Page 136
© CTI Education Group
Relational Model A data model in which data is stored in relations and relationships
between rows are represented by data values
Relational schema A set of relations with referential integrity constraints
Relationship An association between two entities, objects or rows of relations
Report A formatted set of information created to meet user needs
Rollback
A process that involves recovering a database, in which before-images
are applied to a saved copy of said database to return to an earlier
checkpoint or other point
Rollforward
A process that involves recovering a database, in which after-images
are applied to a saved copy of said database to return to an earlier
checkpoint or other point
Row A group of columns in a table; all columns in a row pertain to the same
entity
Second normal
form (2NF)
A relation in first normal form, in which all non-key attributes are
dependent on all keys
Serialisable
isolation level
A transaction isolation level that does not allow dirty, non-repeatable
or phantom reads
Star schema In a dimensional database, the structure of a central fact table is linked
to a dimension table
Stored procedure A collection of structured query language statements stored as a file
that can be invoked via a single command
Strong entity In the Entity-Relationship Model, an entity whose existence in a
database does not depend on the existence of any other entity
Structured Query
Language (SQL)
A language used to define the structure and processing of a relational
database; it can be used as a standalone query language or can be
embedded in application programs
Surrogate key A unique, system-supplied identifier used as the primary key of a
relation
Table A database structure of rows and columns that create cells that hold
data values; it is known as a relation in a relational database
Third normal form
(3NF) A relation in second normal form that has no transitive dependencies
Three-tier
architecture
A Web database processing architecture, in which a database
management system and Web server reside on separate computers
Trigger A special type of stored procedure that is invoked by a database
management system when a specified condition occurs
Two-tier
architecture
A Web database processing architecture, in which a database
management system and Web server reside on the same computer
Unique identifier An identifier that determines exactly one entity instance
Unique key A key that identifies a unique row
Weak entity In the Entity-Relationship Model, an entity whose existence in a
database depends on the existence of another entity
![Page 142: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/142.jpg)
Bibliography Page 137
© CTI Education Group
Bibliography Kroenke, D.M. & Auer, D.J. 2013. Database concepts. 6th edition. New Jersey:
Prentice Hall.
![Page 143: Database Design Concepts · 2018-02-28 · Compiled by Michael Mapundu, Herbert Zuze and Nyasha Magutsa Quality assured by Masimba Nyadzibaya, Martin Appiah and Sabelo Muchayiri Edited](https://reader034.fdocuments.in/reader034/viewer/2022042112/5e8e67f94645ef14f63e7426/html5/thumbnails/143.jpg)
Contact details
Bedfordview Campus
9 Concorde Road East, Bedfordview P.O. Box 1389, Bedfordview, 2008 Tel: +27 (0)10 595 2999, Fax: +27 (0)86 686 4950 Email: [email protected]
Bloemfontein Campus
Tourist Centre, 60 Park Avenue, Willows, Bloemfontein P.O. Box 1015, Bloemfontein, 9300 Tel: +27 (0)51 430 2701, Fax: +27 (0)51 430 2708 Email: [email protected]
Cape Town Campus
The Brookside Building, 11 Imam Haron Str (old Lansdowne Road), Claremont P.O. Box 2325, Clareinch, 7740 Tel: +27 (0)21 674 6567, Fax: +27 (0)21 674 6599 Email: [email protected]
Durban Campus
1 Lunar Row, Umhlanga Ridge, Durban
P.O. Box 20251, Durban North, 4016 Tel: +27 (0)31 564 0570/5, Fax: +27 (0)31 564 8978 Email: [email protected]
Durbanville Campus
Kaapzicht, 9 Rogers Street, Tyger Valley P.O. Box 284, Private Bag X7
Tyger Valley, 7536 Tel: +27 (0)21 914 8000, Fax: +27 (0)21 914 8004 Email: [email protected]
East London Campus
12 Stewart Drive, Berea, East London PostNet Suite 373 Private Bag X9063, East London, 5200 Tel: +27 (0)43 721 2564, Fax: +27 (0)43 721 2597 Email: [email protected]
Nelspruit Campus 50 Murray Street, Nelspruit P.O. Box 9497, Sonpark, Nelspruit, 1206 Tel: +27 (0)13 755 3918, Fax: +27 (0)13 755 3918 Email: [email protected]
Port Elizabeth Campus
Building 4, Ascot Office Park Cnr Ascot & Conyngham Roads, Greenacres P.O. Box 40049, Walmer, 6065 Tel: +27 (0)41 374 7978, Fax: +27 (0)41 374 3190 Email: [email protected]
Potchefstroom Campus
12 Esselen Street, Cnr Esselen Street & Steve Biko Avenue, Die Bult, Potchefstroom P.O. Box 19900, Noordbrug, 2522 Tel: +27 (0)18 297 7760, Fax: +27 (0)18 297 7783 Email: [email protected]
Pretoria Campus
22 Umgazi Street, Menlo Park, Pretoria PostNet Suite A147, Private Bag X18, Lynnwood Ridge, 0040 Tel: +27 (0)12 348 3060, Fax: +27 (0)12 348 3063 Email: [email protected]
Randburg Campus
6 Hunter Avenue, Cnr Bram Fischer Drive Ferndale, Randburg P.O. Box 920, Randburg, 2125 Tel: +27 (0)11 789 3178, Fax: +27 (0)11 789 4606 Email: [email protected]
Vanderbijlpark Campus
Building 2, Cnr Rutherford & Frikkie Meyer Boulevards
Vanderbijlpark P.O. Box 6371, Vanderbijlpark, 1900 Tel: +27 (0)16 931 1180, Fax: +27 (0)16 933 1055 Email: [email protected]
Group Head Office
Management Services Building 44 Alsatian Road, Glen Austin Extension 3, Midrand P.O. Box 1398, Randburg, 2125 Tel: +27 (0)11 467 8422, Fax: +27 (0)86 583 6660 Website: www.cti.ac.za
CTI is part of Pearson, the world’s leading learning company. Pearson is the corporate owner, not a registered
provider nor conferrer of qualifications in South Africa. CTI Education Group (Pty) Ltd. is registered with the Department of Higher Education and Training as a private higher education institution under the
Higher Education Act, 101, of 1997. Registration Certificate number: 2004/HE07/004. www.cti.ac.za.