Introduction to Database Systems - Distance Learning...

COURSE MANUAL

Introduction to Database Systems

CIS305

University of Ibadan Distance Learning Centre

Open and Distance Learning Course Series Development

Copyright © 2016 by Distance Learning Centre, University of Ibadan, Ibadan.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior permission of the copyright owner.

General Editor: Prof. Bayo Okunade

University of Ibadan Distance Learning Centre University of Ibadan,

Nigeria

Telex: 31128NG Tel: +234 (80775935727)

E-mail: [email protected] Website: www.dlc.ui.edu.ng

Contents ii

Vice-Chancellor’s Message The Distance Learning Centre is building on a solid tradition of over two decades of service in the provision of External Studies Programme and now Distance Learning Education in Nigeria and beyond. The Distance Learning mode to which we are committed is providing access to many deserving Nigerians in having access to higher education especially those who by the nature of their engagement do not have the luxury of full time education. Recently, it is contributing in no small measure to providing places for teeming Nigerian youths who for one reason or the other could not get admission into the conventional universities. These course materials have been written by writers specially trained in ODL course delivery. The writers have made great efforts to provide up to date information, knowledge and skills in the different disciplines and ensure that the materials are user-friendly.

In addition to provision of course materials in print and e-format, a lot of Information Technology input has also gone into the deployment of course materials. Most of them can be downloaded from the DLC website and are available in audio format which you can also download into your mobile phones, IPod, MP3 among other devices to allow you listen to the audio study sessions. Some of the study session materials have been scripted and are being broadcast on the university’s Diamond Radio FM 101.1, while others have been delivered and captured in audio-visual format in a classroom environment for use by our students. Detailed information on availability and access is available on the website. We will continue in our efforts to provide and review course materials for our courses. However, for you to take advantage of these formats, you will need to improve on your I.T. skills and develop requisite distance learning Culture. It is well known that, for efficient and effective provision of Distance learning education, availability of appropriate and relevant course materials is a sine qua non. So also, is the availability of multiple plat form for the convenience of our students. It is in fulfilment of this, that series of course materials are being written to enable our students study at their own pace and convenience. It is our hope that you will put these course materials to the best use.

Prof. Abel Idowu Olayinka Vice-Chancellor

Foreword As part of its vision of providing education for “Liberty and Development” for Nigerians and the International Community, the University of Ibadan, Distance Learning Centre has recently embarked on a vigorous repositioning agenda which aimed at embracing a holistic and all encompassing approach to the delivery of its Open Distance Learning (ODL) programmes. Thus we are committed to global best practices in distance learning provision. Apart from providing an efficient administrative and academic support for our students, we are committed to providing educational resource materials for the use of our students. We are convinced that, without an up-to-date, learner-friendly and distance learning compliant course materials, there cannot be any basis to lay claim to being a provider of distance learning education. Indeed, availability of appropriate course materials in multiple formats is the hub of any distance learning provision worldwide.

In view of the above, we are vigorously pursuing as a matter of priority, the provision of credible, learner-friendly and interactive course materials for all our courses. We commissioned the authoring of, and review of course materials to teams of experts and their outputs were subjected to rigorous peer review to ensure standard. The approach not only emphasizes cognitive knowledge, but also skills and humane values which are at the core of education, even in an ICT age.

The development of the materials which is on-going also had input from experienced editors and illustrators who have ensured that they are accurate, current and learner-friendly. They are specially written with distance learners in mind. This is very important because, distance learning involves non-residential students who can often feel isolated from the community of learners. It is important to note that, for a distance learner to excel there is the need to source and read relevant materials apart from this course material. Therefore, adequate supplementary reading materials as well as other information sources are suggested in the course materials.

Apart from the responsibility for you to read this course material with others, you are also advised to seek assistance from your course facilitators especially academic advisors during your study even before the interactive session which is by design for revision. Your academic advisors will assist you using convenient technology including Google Hang Out, You Tube, Talk Fusion, etc. but you have to take advantage of these. It is also going to be of immense advantage if you complete assignments as at when due so as to have necessary feedbacks as a guide.

The implication of the above is that, a distance learner has a responsibility to develop requisite distance learning culture which includes diligent and disciplined self-study, seeking available administrative and academic support and acquisition of basic information technology skills. This is why you are encouraged to develop your computer skills by availing yourself the opportunity of training that the Centre’s provide and put these into use.

Contents iv

In conclusion, it is envisaged that the course materials would also be useful for the regular students of tertiary institutions in Nigeria who are faced with a dearth of high quality textbooks. We are therefore, delighted to present these titles to both our distance learning students and the university’s regular students. We are confident that the materials will be an invaluable resource to all.

We would like to thank all our authors, reviewers and production staff for the high quality of work.

Best wishes.

Professor Bayo Okunade Director

Course Development Team Content Authoring Olufade Falade Williams Onifade

Content Editor

Production Editor Learning Design/Assessment Authoring

Managing Editor General Editor

Prof. Remi Raji-Oyelade

Ogundele Olumuyiwa Caleb Folajimi Olambo Fakoya

Ogunmefun Oladele Abiodun Prof. Bayo Okunade

Contents vi

Contents

About this course manual 1

How this course manual is structured .................................................................................................................... 1

Course Overview 3

Welcome to Introduction to Database SystemsCIS305 ................................................................................... 3

Getting around this course manual 4

Margin icons ....................................................................................................................................................................... 4

Study Session 1 5

Introduction to Database Systems ............................................................................................................................ 5 Introduction .......................................................................................................................................................... 5 Terminology .......................................................................................................................................................... 5 1.1 Data and Information................................................................................................................................. 5 1.2 File System ..................................................................................................................................................... 7 1.3 Database Systems ..................................................................................................................................... 10

1.3.1 The Database Systems Environment............................................................................... 10 1.3.2 Advantages of Database Systems ...................................................................................... 11 1.3.3 The Database Management System ................................................................................. 12 1.3.4 DBMS Functions ....................................................................................................................... 12

Study Session Summary ............................................................................................................................................. 13 Assessment ...................................................................................................................................................................... 13 Bibliography .................................................................................................................................................................... 14

Study Session 2 15

Data Models 1 ................................................................................................................................................................. 15 Introduction ....................................................................................................................................................... 15 Terminology ....................................................................................................................................................... 15 2.1 Data Models and Data Modelling ....................................................................................................... 15 2.2 Basic Building Blocks of Data Models .............................................................................................. 16 2.3 Business Rules ........................................................................................................................................... 17

2.3.1 Translating Business Rules into Data Models ............................................................. 18 2.4 Levels of Data Abstraction .................................................................................................................... 19

2.4.1 The External Model ................................................................................................................. 20 2.4.2 The Conceptual Model ........................................................................................................... 21 2.4.3 The Internal Model.................................................................................................................. 21


Study Session 3 24

Data Models 2 ................................................................................................................................................................. 24 Introduction ....................................................................................................................................................... 24 Terminology ....................................................................................................................................................... 24 3.1 Evolution of Data Models ...................................................................................................................... 24

3.1.1 Hierarchical Data Model ....................................................................................................... 25 31.2 Network Data Model ............................................................................................................... 26 3.1.3 The Relational Model ............................................................................................................. 27 3.1.4 Entity-Relationship (ER) Model ........................................................................................ 28 3.1.5 Object-Oriented Model .......................................................................................................... 30 3.1.6 Modern Data Models .............................................................................................................. 30


Study Session 4 33

Network Databases ...................................................................................................................................................... 33 Introduction ....................................................................................................................................................... 33 Terminology ....................................................................................................................................................... 33 4.1 Basic Concepts ........................................................................................................................................... 33 4.2 Data-Structure (D-S) Diagrams .......................................................................................................... 34


Study Session 5 38

The Relational Model (1) ........................................................................................................................................... 38 Introduction ....................................................................................................................................................... 38 Terminology ....................................................................................................................................................... 38 5.1 A Logical View of Data ............................................................................................................................ 38 5.2 Keys ................................................................................................................................................................ 40 5.3 Integrity Rules ........................................................................................................................................... 42


Study Session 6 44

The Relational Model (2) ........................................................................................................................................... 44 Introduction ....................................................................................................................................................... 44 Terminology ....................................................................................................................................................... 45 6.1 Relationships in the Relational Model ............................................................................................. 45 6.2 Database Indexing .................................................................................................................................... 47 6.3 The Data Dictionary................................................................................................................................. 48

Contents viii


Study Session 7 50

The Relational Model (3) ........................................................................................................................................... 50 Introduction ....................................................................................................................................................... 50 Terminology ....................................................................................................................................................... 50 7.1 Relational Algebra .................................................................................................................................... 50

7.1.1 Select ......................................................................................................................................... 51 7.1.2 PROJECT ...................................................................................................................................... 51 7.1.3 UNION ........................................................................................................................................... 52 7.1.4 Intersection ................................................................................................................................ 53 7.1.5 Difference .................................................................................................................................... 53 7.1.6 Product ......................................................................................................................................... 54 7.1.7 DIVIDE .......................................................................................................................................... 54 7.1.8 JOIN ................................................................................................................................................ 55


Study Session 8 58

Information Systems ................................................................................................................................................... 58 Introduction ....................................................................................................................................................... 58 Terminology ....................................................................................................................................................... 58 8.1 Data versus Information ........................................................................................................................ 58 8.2 System ........................................................................................................................................................... 60

8.2.1 System Components and Concepts .................................................................................. 60 8.2.2 System Performance and Standards ............................................................................... 60 8.2.3 System Variables and Parameters .................................................................................... 61 8.2.4 System Modelling..................................................................................................................... 61

8.3 Definition of Information Systems .................................................................................................... 61 8.4Computer Based Information System ............................................................................................... 62

8.4.1 Hardware and Software ........................................................................................................ 63 8.4.2 Databases .................................................................................................................................... 63 8.4.3 Telecommunication and Networks .................................................................................. 64 8.4.4 People and Procedures: ........................................................................................................ 65

8.5 Realizing Information Systems ........................................................................................................... 65 Study Session Summary ............................................................................................................................................. 66 Assessment ...................................................................................................................................................................... 66 Bibliography .................................................................................................................................................................... 66

Study Session 9 67

Computer-Aided Software Engineering (CASE) .............................................................................................. 67 Introduction ....................................................................................................................................................... 67 Terminology ....................................................................................................................................................... 67 9.1 CASE Overview .......................................................................................................................................... 67 9.2 CASE Tool Components ......................................................................................................................... 68

9.3 CASE Diagramming Tools ..................................................................................................................... 69 9.4 CASE Repository ....................................................................................................................................... 69 9.5 Benefits of Using CASE Tools ............................................................................................................... 70 9.6 Limitations of CASE ................................................................................................................................. 71


Study Session 10 73

Unified Modelling Language (UML) ...................................................................................................................... 73 Introduction ....................................................................................................................................................... 73 Terminology ....................................................................................................................................................... 73 10.1 UML Overview ......................................................................................................................................... 73 10.2 UML Diagrams ......................................................................................................................................... 74 10.3 Class Diagram .......................................................................................................................................... 75 10.4 Use Case Diagrams ................................................................................................................................ 78


Study Session 11 81

Data Flow Diagrams (DFD) ....................................................................................................................................... 81 Introduction ....................................................................................................................................................... 81 Terminology ....................................................................................................................................................... 81 11.1 Overview of DFD .................................................................................................................................... 81 11.2 Creating DFDs .......................................................................................................................................... 83

11.2.1 Top-Down Analysis of DFD Creation see figure 11.3 ............................................. 85 11.2.2 Where to Begin Creating DFDs ........................................................................................ 86 11.2.3 What to Avoid During DFD Creation............................................................................. 86 11.2.4 DFD Creation; an Example ................................................................................................ 87


Study Session 12 89

Multi-User Databases .................................................................................................................................................. 89 Introduction ....................................................................................................................................................... 89 Terminology ....................................................................................................................................................... 90 12.1 Transaction Management................................................................................................................... 90 12.2The ACIDS Properties of a Database Transaction ..................................................................... 90 12.3Transaction Standards.......................................................................................................................... 91 12.4Database Recovery ................................................................................................................................. 92

Contents x


Study Session 13 94

REVISION .......................................................................................................................................................................... 94 Introduction ....................................................................................................................................................... 94 Terminology ....................................................................................................................................................... 95 13.1 File Systems and Databases .............................................................................................................. 95 13.2 Data Models .............................................................................................................................................. 95 13.3 The Relational Model ........................................................................................................................... 96 13.4 Information Systems ............................................................................................................................ 96 13.5 Computer Aided Software Engineering ....................................................................................... 96 13.6Concepts in Multi-User Databases ................................................................................................... 97


Notes on Self Assessment Questions 99

References 117

About this course manual

1

About this course manual Introduction to Database SystemsCIS305 has been produced by University of Ibadan Distance Learning Centre. All course manuals produced by University of Ibadan Distance Learning Centreare structured in the same way, as outlined below.

How this course manual is structured

The course overview The course overview gives you a general introduction to the course. Information contained in the course overview will help you determine:

If the course is suitable for you.

What you will already need to know.

What you can expect from the course.

How much time you will need to invest to complete the course.

The overview also provides guidance on:

Study skills.

Where to get help.

Course assignments and assessments.

Margin icons.

We strongly recommend that you read the overview carefully before starting your study.

The course content The course is broken down into Study Sessions. Each Study Session comprises:

An introduction to the Study Session content.

Study Session outcomes.

Core content of the Study Session with a variety of learning activities.

A Study Session summary.

Assignments and/or assessments, as applicable.

Bibliography

CIS305 Introduction to Database Systems

2

Your comments After completing Introduction to Database Systems we would appreciate it if you would take a few moments to give us your feedback on any aspect of this course. Your feedback might include comments on:

Course content and structure.

Course reading materials and resources.

Course assignments.

Course assessments.

Course duration.

Course support (assigned tutors, technical help, etc.)

Your constructive feedback will help us to improve and enhance this course.

Course Overview

3

Course Overview

Welcome to Introduction to Database SystemsCIS305

A database can be simply regarded as a collection of data. More precisely, it is an organized collection of logically related data in such a way that data can be easily managed and accessed. Databases have now become an integral part of our daily life – on the Internet, in financial institutions, in our electoral process etc. The fact remains that databases have come to stay and to become an essential part of our lives therefore necessitating the need to study them in terms of their design, structure, usage, management and applications – this course provides you with the knowledge of databases in those areas.

To get the best out of this course, endeavour to attend all lectures, study all lessons carefully, attempt the exercises within the text and make sure you answer all questions in the pre-test and post-test. Also, it is important that you promptly submit all your assignments and avoid ‘dubbing’ assignments in order to avoid implicating yourself and for you to ensure that you’ve truly learnt what the assignment intends to teach. I wish you the very best.

Course Objectives

At the end of this course, you should be able to

1. Understand the typical difference between file systems and database systems

2. Know the various data models and understand the concept of data modelling

3. Understand the design and development of Information Systems.

4. To understand the different CASE diagramming tools (UML, ) and how they are used to accomplish sound system designs.

4


Getting around this course manual

Margin icons While working through this course manual you will notice the frequent use of margin icons. These icons serve to “signpost” a particular piece of text, a new task or change in activity; they have been included to help you to find your way around this course manual.

A complete icon set is shown below. We suggest that you familiarize yourself with the icons and their meaning before starting your study.

Activity Assessment Assignment Case study

Discussion Group Activity Help Outcomes

Note Reflection Reading Study skills

Summary Terminology Time Tip

Study Session 1Introduction to Database Systems

5

Study Session 1

Introduction to Database Systems Introduction

In this session, we will have an introduction to database systems. We would also discuss file system, database system, data and information.

Learning Outcomes

Outcomes

When you have studied this session, you should be able to:

1.1 discuss data and information

1.2 explain file system

1.3 discuss database system

Terminology Database a collection of information that is organized so that it can

easily be accessed, managed, and updated

DBMS A database management system (DBMS) is a computer software application that interacts with the user, other applications, and the database itself to capture and analyze data.

GUI In computer science, a graphical user interface (GUI), is a type of user interface that allows users to interact with electronic devices through graphical icons and visual indicators such as secondary notation, instead of text-based user interfaces, typed command labels or text navigation.

1.1 Data and Information Data is defined as raw or unprocessed fact. Information is the result of processing data. Processing could involve several activities such grouping, extraction and summarization of the unprocessed fact (data). Organizations generate vast amounts of data from their daily operations and in order to ensure their efficient running, organizations must be able to store such data for various purposes ranging from processing to decision making.

6


For instance, a manufacturing company producing soft drinks and beverages wants to improve sales. Such a company could go on to have the record of sales of their two major products (beverages and drinks) over a period of time, say 2 months. The, details collected at this stage will be referred to as data, because it is yet unprocessed and is therefore not useful for the required purpose, see Figure 1.1a. In order to draw any meaning from this data, there may be need to group the sales record according to the products, sort the sales in descending order starting from the highest sale amount or arrange sales in clusters of their periods (weeks, months, years etc.).

Having done that, it is easier to see which of the products made more sales and at what period of time were sales generally higher or lower, this will help the firm make concrete decisions in order to improve their net sales. The data obtained in Figure 1.1a is processed by grouping according to the type of product and sorting them by date (from the latest to the oldest) and sorting in order to have the information in Figure 1.1b. For an easier view of the product with the higher sales, how do you think we should sort the table?

Figure 1.1: Sales Data

The need to process data for easy storage, retrieval and reporting is a major motivation for database systems. Therefore, in the rest of this lesson, we will examine some other motivations for databases as well as an understanding of what databases are and what they are not.

Date Product Quantity Rate (#)

12/03/2011 Soft drink 1 carton 3000

14/08/2010 Beverage 10 cartons 4000

01/10/2012 23 cartons 4000

15/02/2013 Soft drink 5 cartons 3000






Date Product Quantity Rate (#)








12/03/2011 Soft drink 1 carton 3000


(a) Sales data (unprocessed) (b) Sales data (processed)


7

ITQ

Question

. Define Data

Feedback

. Data is defined as raw or unprocessed fact.

1.2 File System File System refers to a data storage mechanism which stores data in files organized in a tree-like (hierarchical) structure. Therefore, to access a file, we must first access its parent file and the deletion of a file implies the deletion of all its child files. Just like files are managed (stored, retrieved, created and deleted) within a File system, databases are managed by a software called Database Management Software (DBMS) which we will discuss in section 1.3.

For us to understand the need for databases, let us consider the following scenario. A large organization has a large collection (say, 800 GB) of data on their employees, departments, products, sales etc. and this data is accessed simultaneously by several employees. Questions about the data must be answered quickly, changes made to the data by different users must be applied consistently, and access to certain parts of the data (e.g., salaries) must be restricted.

We can try to deal with this data management problem by storing the data in a collection of operating system files. As simple as this approach seems, it has many drawbacks some of which we highlight as follows:

We probably do not have 500 GB of main memory to hold all the data. We must therefore store data in a storage device such as a disk or tape and bring relevant parts into main memory for processing as needed.

Even if we have 500 GB of main memory, on computer systems with 32-bit addressing, we cannot refer directly to more than about 4 GB of data. Therefore, we have to program some methods of identifying all data items.

We have to write special programs to answer each question that users may want to ask about the data. These programs are likely to be complex because of the large volume of data to be searched.

We must protect the data from inconsistent changes made by different users accessing the data concurrently. If programs that access the data are written with such concurrent access in mind, this adds to their complexity.

When system crashes occur while changes are being made to data, we must ensure that data is restored to a consistent state i.e. the changes are either completely effected or completely reversed.

Operating systems provide only a password mechanism for security. This is not sufficiently flexible to enforce security

8


policies in which different users have permission to access different subsets of the data.

This issues reveal to us the drawbacks of the File system which makes it unsuitable for storing large amounts of data for easy retrieval, maintenance of data integrity and enforcement of data security.

From what we’ve seen above, let us quickly identify some of the drawbacks of the File System that motivates the need for a DBMS.

Drawbacks of the File System

1. Structural Dependence: A file system exhibits structural dependence, that is, access to a file is dependent on its structure. For example, if the information in Figure 1b were stored in a file and the program that accesses it reads each field (column of the table) of the file and writes it to output accordingly. Assuming we now add a product id field to the file, we would have to make provision for this in our program. Therefore, all of the file system programs must be modified to conform to the new file structure. In short, because the file system application programs are affected by change in the file structure, they exhibit structural dependence. Conversely, structural independence exists when it is possible to make changes in the file structure without affecting the application program’s ability to access the data.

2. Data Dependence: Changes in the characteristics of data, such as changing a field from integer to decimal, require changes in all the programs that access the file. Because all data access programs are subject to change when any of the file’s data storage characteristics change (that is, changing the data type), the file system is said to exhibit data dependence. Conversely, data independence exists when it is possible to make changes in the data storage characteristics without affecting the application program’s ability to access the data.

3. Data Redundancy: Data redundancy occurs when the same item of data is stored unnecessarily in different places. Data redundancy poses a number of problems in data storage:

a. Data Inconsistency: This occurs when we have different/conflicting versions of the same item of data stored in different places. For instance, changing the product RATE in the product file without changing it in the sales file shown in Figure 1.1 shows inconsistency in the same data item stored in different places.Data that display data inconsistency are also referred to as data that lack data integrity. Data integrity is defined as the condition in which all of the data in the database are consistent with the real-world events and conditions. In other words, data integrity means that Data are accurate—there are no data inconsistencies and Data are verifiable—the data will always yield consistent results.

b. Data Insecurity: Data redundancy can greatly increase the chances of unauthorized access to some copies of data, thus compromising the security of the data in the storage.


9

c. Data Anomalies: Data anomaly is a condition of abnormality in operations carried out on data and this is caused by data redundancy. There are insertion anomalies, update anomalies and deletion anomalies.

4. Lengthy application development time and extensive programming: As seen under structural dependence, making changes to file structure in a file system often requires extensive programming and the overhead is lengthy application development time. One of the most glaring problems with the file system approach is that even the simplest data-retrieval task requires extensive programming. With the older file systems, programmers had to specify what must be done and how it was to be done. As you will learn in upcoming chapters, modern databases use a nonprocedural data manipulation language that allows the user to specify what must be done without specifying how it must be done.

5. Lack of Design and Data Modelling Skills: A new problem that has evolved with the use of personal productivity tools (such as spreadsheet and desktop databases) is that users typically lack the knowledge of proper design and data-modeling skills. People naturally have an integrated view of the data in their environment. For example, consider a student’s class schedule. The schedule probably contains the student’s identification number and name, class code, class description, class credit hours, the name of the instructor teaching the class, the class meeting days and times, and the class room number. In the mind of the student, these various data items compose a single unit. If a student organization wanted to keep a record of the schedules of all of the organization members, an end user might make a spreadsheet to store the schedule information. Even if the student makes a foray into the realm of desktop databases, he or she is likely to create a structure composed of a single table that mimics the structure of the schedule. As you will learn in the coming chapters, forcing this type of integrated data into a single two-dimensional table structure is a poor data design that leads to a large degree of redundancy for several data items.

ITQ

Question

. Highlight the drawbacks of a file system

Feedback . Drawbacks of a File System

1. Structural Dependence 2. Data Dependence 3. Data Redundancy 4. Lengthy application development time and extensive

programming 5. Lack of Design and Data Modelling Skills

10


1.3 Database Systems A database is an organized collection of logically related data for efficient storage, management and retrieval. Database Systems are managed by a software called Database Management System (DBMS). Databases have become an integral part of our present day world. Every time you visit websites such as Google, Facebook, Yahoo, or Amazon, you type in certain requests or click certain button and menu controls, you’re simply retrieving data from some database. Somehow, these systems have become very central to our daily living; the need to study databases (which are behind the scenes of their operations) have subsequently become necessary.

Unlike the File system which stores unrelated data within the same structure, databases seek to organize data in some logically coherent way (even though such data may be distributed within various physical units).

Our discussion of database systems will help highlight its improvements over the file system – their similarities and differences. As shown in Figure 1.2, access to all the contents of a database system is managed and controlled by the DBMS, thus allowing data to be stored in a single logical unit while specifying permissions that allows users authorized access to different portions of data by different users.

1.3.1 The Database Systems Environment The database systems environment explains the different components and actors in a database system. Ranging from the data actually stored in the system to the various types of human professionals who are responsible for managing the database through the DBMS, we discuss each component and actor with details of their roles in the Database system.

1. Data: This is the data actually stored in the database. Data could be of various types; integers, decimals, objects.


11

2. Software: Although, the DBMS is the most notable software needed in a Database system, other software such as the computer operating system and other application and utility programs such as interactive Graphical User Interfaces (GUI) which allow user to submit their queries and generate reports in very easy and interactive ways.

3. Hardware: These are the physical devices and resources responsible for housing the database. These include disk drives (which are the actual physical locations of the database), visual display units, keyboards for entering input etc.

4. People: There are various individuals who use the DBMS; end users, application programmers, database administrators and system administrators.

1.3.2 Advantages of Database Systems As opposed to the file system, databases offer a good number of advantages for data storage, management and retrieval courtesy of the DBMS. Many of these advantages are simply the opposite of the drawbacks of file system discussed in section 1.3.

1. Data Independence: Database systems allow application programs to be as independent as possible from details of data representation and storage. The DBMS provides an abstract view of the data to insulate application code from such details.

2. Data Integrity: If data is always accessed through the DBMS, the DBMS can enforce integrity constraints on the data. For example, before inserting salary information for an employee, the DBMS can check that the department budget is not exceeded.

3. Data Security: Also, the DBMS can enforce access controls that govern what data is visible to different classes of users in order to prevent unauthorized data access while it also ensures that authorized users are not denied access.

4. Efficient and easy data access: A DBMS utilizes a variety of sophisticated techniques to store and retrieve data efficiently. This feature is especially important if the data is stored on external storage devices.

5. Reduced Application development time: Clearly, the DBMS supports many important functions that are common to many applications accessing data stored in the DBMS. This, in conjunction with the high-level interface to the data, facilitates quick development of applications. Such applications are also likely to be more robust than applications developed from scratch because many important tasks are handled by the DBMS instead of being implemented by the application.

6. Concurrent Access: A DBMS schedules concurrent accesses to the data in such a manner that users can think of the data as being accessed by only one user at a time.

7. Crash Recovery: Further, the DBMS protects users from the effects of system failures and crashes by ensuring that the database recovers from system failures and restores data in it to a consistent state.

12


Exercise: Prepare a table that shows the similarities and differences between File System and Database Systems.

1.3.3 The Database Management System Database Management System (DBMS) is the software that manages database systems. Figure 1.3 shows the typical structure of the DBMS also including the different categories of people who use the system. Examples of some common DBMS are Oracle, Microsoft SQL Server, MySQL and Dbase2.

ITQ

Question

. Give examples of DBMS

Feedback . Examples of DBMS includes: Oracle, Microsoft SQL Server, MySQL and Dbase2.

1.3.4 DBMS Functions Some functions of the DBMS include

1. The management of data storage is one of the responsibilities of the DBMS. This is to ensure that data is efficiently stored for


13

easy retrieval. This is achieved through the data dictionary in which the DBMS stores details of data and their relationships.

2. The DBMS facilitates data retrieval and report generation by transformation and presentation of data it in appropriate formats.

3. The DBMS ensures security of data by allowing user access permissions to be specified so that different classes of user are allowed authorized access to different portions of data, hence denying unauthorized user access.

4. The DBMS is also responsible for concurrent user access to data. 5. In case of system failures and crashes, the DBMS ensures that

data is not lost by promptly backing up data for system recovery purposes.

6. The DBMS helps manage data integrity by specifying constraint and rules guiding operations on data (insertion, deletion, updates, retrieval etc.).

7. The DBMS also provides a database access language known as Structured Query Language (SQL) for accessing data in the database and Application Programming Interfaces (API) for application programs to interact with the database.

It is obvious from these functions that many of the advantages offered by database systems are provided by the DBMS. Hence, the DBMS is seen as the backbone of a Database System.

Exercise: In your own opinion, what would database management have been without the DBMS?

Study Session Summary

Summary

In this session, we learnt the basic concepts of data and information and their means of storage.

Assessment

Assessment

SAQ 1.1 (tests Learning Outcome 1.1) Define Data and Information respectively?

SAQ 1.2 (tests Learning Outcome 1.2)

What is a File System?

SAQ 1.3 (tests Learning Outcome 1.3) Define the DBMS and its functions

14


Bibliography

Reading

1. Coronel C., Morris M., and Rob P. Database Systems: Design, Implementation and Management. 9th Edition, Cengage Learning, 2011.

2. Ramakrishnan R. and Gehrke J. Database Management Systems. 2nd Edition, McGrawHill, 2002

Study Session 2Data Models 1

15

Study Session 2

Data Models 1 Introduction

In this session, you will study the concept of data modeling and its basic building blocks. We will also discuss business rules and levels of data abstractions.

Learning Outcomes

Outcomes


2.1 define data modeling and data models

2.2 highlight and explain the basic building blocks data-modeling

2.3 explain what business rules are and how they influence database design

2.4 describe how data models can be classified by level of abstraction

Terminology Blueprints a reproduction of a technical drawing, documenting an

architecture or an engineering design, using a contact print process on light-sensitive sheets.

2.1 Data Models and Data Modelling Data modeling, the first step in designing a database, refers to the process of creating a specific data model for a determined problem domain. (A problem domain is a clearly defined area within the real-world environment, with well-defined scope and boundaries to be systematically addressed). Database design focuses on how the database structure will be used to store and manage end-user data.

In general terms, a model is an abstraction of a more complex real-world object or event. A model’s main function is to help you understand the complexities of the real-world environment. Within the database environment, a data model represents data structures and their characteristics, relations, constraints, transformations, and other constructs with the purpose of supporting a specific problem domain. A data model will basically contain the structure of the data, the operations on the data and the constraints on the data.

16


Data modeling is an iteratively progressive process. It starts with a simple understanding of the problem domain, and as your understanding of the problem domain increases, so does the level of detail provided in the data model. Eventually, the final data model is in effect a “blueprint” containing all the instructions to build a database that will meet end-user requirements. This blueprint is narrative and graphical in nature, meaning that it contains both text descriptions in plain, unambiguous language and clear, useful diagrams depicting the main data elements. Data models are essentially important in facilitating the interaction between the database designer, the application designer and the end user by presenting a blueprint that harmonizes their different views with different levels of abstraction.

ITQ

Question

. What does a data model contain?

Feedback . A data model will basically contain the structure of the data, the operations on the data and the constraints on the data.

2.2 Basic Building Blocks of Data Models The basic building blocks of data models are entities, attributes, relationships and constraints.

Entity: An entity is any real-world object or concept about which data are to be collected and stored. Entities are unique and distinguishable and should be modelled as such. An example of an entity is a STUDENT and instances of this entity may include Shola Buhari, Agbaje Emeka, Isiaka Pedro etc. While entities may be concrete objects such as students, customers, products etc, they could also be abstract concepts such as Sales, Flight Schedule, Course Registration etc.

Attribute: An attribute is a characteristic of an entity. They could be likened to fields of a record in a file. The entity student for instance would have attributes such as SURNAME, FIRST NAME and MATRIC NUMBER. Some of these attributes are expected to be unique while others need not be.

Relationship: This is the association between entities. A STUDENT offers a COURSE, an EMPLOYEE reports to an EMPLOYER and a MANAGER manages a DEPARTMENT are all examples of relationships between entities. There are different types of relationships based on the number of participating entity instances in the relationship. Relationships are bi-directional, so, to discover the type of a relationship, we must read it from both entities involved. For instance, a one-to-many (or many-to-one) relationship can be seen in an organization where it is expected that


17

many EMPLOYEES report to one EMPLOYER and

This one EMPLOYER is reported to by many EMPLOYEES

The maximum participation on the side of the EMPLOYEE entity is many while the maximum participation on the side of the EMPLOYER entity is one.

Many-to-Many (M:N or *…*): A STUDENT can offer many COURSES and a COURSE can be offered by many STUDENTS. On both sides of the relationship, there is a maximum participation of many entities.

One-to-Many (1:M or 1…M): An EMPLOYER is reported to by many EMPLOYEES while many EMPLOYEES report to one EMPLOYER. On the EMPLOYER side of the relationship, there is a maximum participation of one entity (EMPLOYER) while there is a maximum of many entities on the EMPLOYEE side.

One-to-One (1:1 or 1…1): A MANAGER manages one DEPARTMENT and a DEPARTMENT is managed by one MANAGER.

Constraint: A constraint is a restriction placed on data. Constraints are important for enforcing data integrity in databases. For instance, a constraint could state that a students’ CGPA must be between 0.0 and 7.0 or the age of an employee should be between 18 years and 60 years.

Exercise: Try to think of more examples of constraints and the different relationship types

ITQ

Question

. What are the basic building blocks of a data model?

Feedback

. The basic building blocks of data models are entities, attributes, relationships and constraints.

2.3 Business Rules In Database Design, designers might need to gain a thorough understanding of what types of data are in an organization, how the data are used, and in what time frames they are used in order to build a sound data model. However, such data and information do not, by themselves, yield the required understanding of the total business. From a database point of view, the collection of data becomes meaningful only when it reflects properly defined business rules. A business rule is a brief, precise, and unambiguous description of a policy, procedure, or principle within a specific organization.

18


Business rules, derived from a detailed description of an organization’s operations, help create and enforce actions within that organization’s environment. Properly written business rules are used to define entities, attributes, relationships, and constraints which are in turn used to build data models in database design. They could be written like “an agent can serve many customers, and each customer can be served by only one agent”.

Let us take a look at some examples of business rules

A customer may generate many invoices. An invoice is generated by only one customer. A training session cannot be scheduled for fewer than 10

employees or for more than 30 employees.

Note that those business rules establish entities, relationships, and constraints. For example, the first two business rules establish two entities (CUSTOMER and INVOICE) and a 1:M relationship between those two entities. The third business rule establishes a constraint (no fewer than 10 people and no more than 30 people), two entities (EMPLOYEE and TRAINING), and a relationship between EMPLOYEE and TRAINING.

Business rules can be obtained from company managers, policy makers, department managers, written documentation, procedures, standards, operations manuals and through direct interviews with end users.

ITQ

Question

. What is a business rule?

Feedback

. A business rule is a brief, precise, and unambiguous description of a policy, procedure, or principle within a specific organization.

2.3.1 Translating Business Rules into Data Models Since we now know the importance of business rules in data modelling, let us learn how to translate business rules into a data model for database designs. The following points should be borne in mind when translating business rules to data models:

Nouns translate into Entities Verbs translate into Relationships among entities Relationships are bidirectional Two questions to identify the relationship type:

– How many instances of B are related to one instance of A?

– How many instances of A are related to one instance of B?


19

In naming entities, attributes and relationships, you should try to make each object unique and distinguishable from other objects. Names should also be descriptive of objects in the environment and be familiar to users.

ITQ

Question

. List the points to note when translating business rules?

Feedback

. The following points should be borne in mind when translating business rules to data models:

Nouns translate into Entities Verbs translate into Relationships among entities Relationships are bidirectional Two questions to identify the relationship type: – How many instances of B are related to one instance of A? – How many instances of A are related to one instance of B?

2.4 Levels of Data Abstraction Data Abstraction simply means hiding detailed information. We have discussed earlier about data models being developed at different levels of abstraction in order to facilitate the interaction between the different professionals involved with database systems. We will look at the different levels of data abstraction involved in data modelling and how they inform the various professionals involved in the database systems environment. Database designers usually start with an abstracted view of the design and then add details.

American National Standards Institute (ANSI) Standards Planning and Requirements Committee (SPARC) in the early 1970s defined a framework for data modeling based on degrees of data abstraction as follows The External Model, The Conceptual Model and The Internal Model (note that the models are arranged in decreasing order of abstraction). We will look at the data modelling problem of a college called “Small College” and use that to explain the different levels of data abstraction

20


Figure 2.1: Levels of Abstraction

ITQ

Question

. What does data abstraction mean?

Feedback

. Data Abstraction simply means hiding detailed information.

2.4.1 The External Model The external view provides the End users’ view of the data environment i.e. the view that an average end user will have of the data in the database. A data model called Entity-Relationship (ER) diagram is used to represent external views. A specific representation of an external view is called an external schema.

Figure 2.2: External Model for Small College

External Model

Conceptual Model

Internal Model

Increasing level of details

Incr

easin

g le

vel o

f abs

tract

ion


21

ITQ

Question

. What is an External schema?

Feedback

. An external schema is a specific representation of an external view.

2.4.2 The Conceptual Model This model brings together all external views and integrate them into a single global view known as the conceptual schema. The ER model is most widely used for this model using.

Figure 2.3: Conceptual model for Small College

2.4.3 The Internal Model This is a representation of the database as “seen” by the DBMS. It maps the conceptual model to the DBMS. Internal schema depicts a specific representation of an internal model. The Internal model depends on the specific database software, therefore a change in DBMS software requires that the internal model be changed. The Internal model is hardware-independent in that a change in the computer hardware does not affect it and it could be logically independent i.e. a change in the internal model could be made without affecting the conceptual model.

22


Figure 2.4: Internal model for Small College

ITQ

Question

. State one of the features of the internal model

Feedback . The Internal model is hardware-independent in that a change in the computer hardware does not affect it and it could be logically independent i.e. a change in the internal model could be made without affecting the conceptual model.


Summary

In this session, you studied the concept of data modeling and its basic building blocks. We also discussed business rules and levels of data abstractions.

Assessment

Assessment


What is data modeling?



23

Briefly highlight and explain the basic building blocks of data models?


What are business rules and how do they influence database design?


How can data models be classified by level of abstraction?

Bibliography

Reading





24


Study Session 3

Data Models 2 Introduction

In this lesson, you will learn about the different data models, which are often responsible for the structure of database systems.

Learning Outcomes

Outcomes


3.1 define hierarchical data models

3.2 explain network data model

3.3 describe the relational model

3.4 discuss entity-relational model

3.5 define object-oriented model

3.6 explain the modern data model

Terminology DML Data Manipulation Language. It is used to retrieve, store,

modify, delete, insert and update data in database

DDL Data Definition Language (DDL) is a standard for commands that define the different structures in a database. DDL statements create, modify, and remove database objects such as tables, indexes, and users. Common DDL statements are CREATE, ALTER, and DROP.

IBM International Business Machines Corporation is an American multinational technology company

3.1 Evolution of Data Models From our last lesson, we learnt what a data model is and the concept of data modelling. We also learnt the basic building blocks of data models for use in database design. In this lesson, we will examine the various types of data models available for database design. These data models are principally categorized based on their structure and their concept (logic) of representing the data model building blocks.


25

Table 3.1 below gives a summarized view of the data models we will discuss in this lesson arranged according to the order of their evolution. We’ve discussed the File System in lesson 1, so we’ll just start our discussion from hierarchical data models.

Table 3.1: Evolution of Data Models

ITQ

Question

. How are data models categorized?

Feedback

. Data models are principally categorized based on their structure and their concept (logic) of representing the data model building blocks.

3.1.1 Hierarchical Data Model The hierarchical model was developed in the 1960s to manage large amounts of data for manufacturing projects. The basic logical structure of the hierarchical model is represented by an upside-down “tree”. This hierarchical structure contains levels or segments. Each segment is analogous to a record type and there is a set of one-to-many relationships between segments. A typical example of the hierarchical data model is shown in figure 3.1.

Figure 3.1: Hierarchical data model

26


ITQ

Question

. When was the hierarchical model developed?

Feedback

. The hierarchical model was developed in the 1960s

31.2 Network Data Model The network model was created to represent complex data relationships more effectively than the hierarchical model. Hence, it improves database performance by imposing a database standard. However, as shown in figure 3.2, it is similar to the hierarchical model in its structure, but unlike the hierarchical model, a record may have more than one parent record.

The Network model is essentially a collection of records in 1:M relationships with each set composed of two record types:

– An Owner record(s) which is equivalent to the hierarchical model’s parent record

– A Member record(s) which is equivalent to the hierarchical model’s child record.

Although the network model is no longer in use today, it defined some concepts which are still in use today in the database community. Some of these are

– Schema: The conceptual organization of an entire database as viewed by the database administrator.

– Subschema: The database portion “seen” by application programs.

– Data management language (DML): This defines the environment in which data can be managed

– Data definition language (DDL): This enables the administrator to define the schema components.

Some of the reasons for the discontinued use of this model are the fact that it’s cumbersome in structure and it lacks ad hoc query capabilities which placed burden on programmers to generate code for reports. The network model was also known to be prone to havocs in all application programs due to structural changes in the database.


27

Figure 3.2: The Network Data Model

ITQ

Question

. What concepts were defined by the network data model?

Feedback

. The following concepts were defined by the Network data model:

Schema, Sub-schema, Data management language(DML) and Data defining language(DDL).

3.1.3 The Relational Model The Relational model was developed by E.F. Codd (IBM) in 1970.

The relational model represents entities as Tables called relations. A table is basically a matrix consisting of row/column intersections. Each row in a relation is called a tuple (representing an entity instance). Relational models were considered impractical in 1970 because the model was conceptually too simple at the expense of computer overhead. However, its conceptual simplicity set the stage for a database revolution. Figure 3.3. shows the structure of relational model as explained above.

SQL-based relational database applications involve three parts;

User interface which allows end users to interact with the data. A set of tables stored in the database with each table being

independent from another and the rows in different tables being related based on common values in common attributes.

An SQL “engine” which executes all queries.

28


Figure 3.3: Structure of a Relational Model

ITQ

Question

. State the three parts of the SQL-based relational database applications

Feedback

User interface which allows end users to interact with the data. User interface which allows end users to interact with the data. A set of tables stored in the database with each table being

independent from another and the rows in different tables being related based on common values in common attributes.

An SQL “engine” which executes all queries.

3.1.4 Entity-Relationship (ER) Model The Entity-Relationship model, introduced by Chen in 1976 was widely accepted standard for data modeling. Entity relationship diagram (ERD) uses graphical representations to model database components.

An entity is mapped to a relational table. An entity instance (or occurrence) corresponds to a row (tuple) in a relational table. An entity set is a collection of similar entities. The connectivity in a relationship indicates the type of the relationship. ERD have two basic notations shown in Figure 3.4 below – the Chen notation and the Crow’s foot notation

In Chen notation: – Entities are represented by a rectangle with their

attributes in ovals around them – Relationships are represented by a diamond with the

relationship name written in the diamond – Crow’s Foot notation: – Entities are represented by a rectangle with their

attributes listed within the rectangle – Relationships are represented by a straight line (which

could be dashed or solid depending on the participation constraints). The name of the relationship is written on the line


29

– Relationship types are usually by the type of symbol at the end of the relationship lines as shown in figure 3.4.

A conceptual model (full database model) is shown in figure 3.5 for your understanding.

Figure 3.4: ERD Chen and Crow’s foot notation (external model)

Figure 3.5: ERD Crow’s foot and Chen notation (conceptual model)

ITQ

Question

What are the two basic notations of the ERD?

Crow’s foot notation Chen notation

30


Feedback The two basic notations of the ERD are the Chen and Crow notations.

3.1.5 Object-Oriented Model In the Object-Oriented data model, data and relationships are contained in a single structure known as an object. OODM (object-oriented data model) is the basis for OODBMS. An object contains operations, is self-contained and is an abstraction of a real-world entity.

Attributes describe the properties of an object, objects that share similar characteristics are grouped in classes and classes are organized in a class hierarchy. Objects inherit methods and attributes of their parent class. UML based on OO concepts that describe diagrams and symbols is used to graphically model a system.

Figure 3.6: Object-Oriented model (showing two objects and an instance the first object)

ITQ

Question

. What does OODM stands for?

Feedback

. OODM means Object-Oriented Data Model

3.1.6 Modern Data Models Here, we’ll discuss some newer data models which are increasingly being used in modern DBMS. The Extended relational data model (ERDM) is a semantic data model developed in response to increasing complexity of applications. It includes many of Object-Oriented model’s best features and is often described as an object/relational database management system (O/RDBMS). It is primarily geared towards business applications.

The use of complex objects received a boost with the Internet revolution. When organizations integrated their business models with the Internet, they realized the potential of the Internet to access, distribute, and exchange critical business information and this resulted in the widespread adoption of the Internet as a business communication tool. It is in this


31

environment that Extensible Markup Language (XML) emerged as the de facto standard for the efficient and effective exchange of structured, semistructured, and unstructured data. In order to manage the large amounts of data generated in this complex formats, XML databases emerged to manage unstructured data within a native XML format.

Figure 3.7 shows a chart explaining the evolution of the data models discussed so far and their specific semantics characteristics each.

ITQ

Question

. What caused the emergence of the XML database?

Feedback

. In order to manage the large amounts of data generated in the complex formats of an XML, XML databases emerged to manageunstructureddata within a native XML format.


Summary

In this lesson, you learnt about the different data models, which are often responsible for the structure of database systems.

32


Assessment

Assessment


Discuss the Evolution of Data Models

Bibliography

Reading

1. www.google.com


3. Ramakrishnan R. and Gehrke J. Database Management Systems. 2nd Edition, McGrawHill, 2002.

Study Session 4Network Databases

33

Study Session 4

Network Databases Introduction

In this lesson, we will discuss in details, one of the data models discussed in the previous lesson; the network model, and its data structure.

Learning Outcomes

Outcomes


4.1 explain The basic concepts of network data models

4.2 Explain Data-Structure diagrams and their correspondences with the Entity-Relationship model.

Terminology

4.1 Basic Concepts We have discussed the network model in the previous lesson. So we will just build on what we have learnt previously. As we learn about the network model, we will make references to the E-R model we learnt in CIS201 and highlight the correspondences between the two.

Data are represented by collections of records. Similar to an entity in the E-R model. Records and their fields are represented as record type. For instance, a customer record and account record are defined as follows:

Relationships among data are represented by links similar to a restricted (binary) form of an E-R relationship. Restrictions on links depend on whether the relationship is many-many, many-to-one, or one-to-one.

ITQ

Question

. How are relationships among data represented?

Feedback

34


. Relationships among data are represented by links similar to a restricted (binary) form of an E-R relationship.

4.2 Data-Structure (D-S) Diagrams Data-Structure diagrams are the schema representing the design of a network database. A data-structure diagram consists of two basic components; boxes correspond to record types and lines correspond to links. Data-Structure Diagrams specify the overall logical structure of the database.

We will now go on to show the correspondences between D-S and E-R diagrams. For every E-R diagram, there is corresponding D-S diagram.

Figure 4.1: Example of converting D-S diagram to E-R diagram

However, since a link cannot contain any data value, we must represent any E-R relationship that has attributes with a new record type and links as shown in figure 4.2.


35

Figure 4.2: Resolving a relationship that has an attribute

To represent an E-R relationship of degree 3 or higher, connect the participating record types through a new record type that is linked directly to each of the original record types. For instance (as shown in figure 4.3)

1. Replace entity sets account, customer, and branch with record types account, customer, and branch, respectively.

2. Create a new record type Rlink (referred to as a dummy record type).

3. Create the following many-to-one links:

CustRlink from Rlink record type to customer record type

AcctRlnk from Rlink record type to account record type

BrncRlnk from Rlink record type to branch record type

36


Figure 4.3: Representation of ternary relationships in a network model.

ITQ

Question

. What does a Data Structure Diagrams specify?

Feedback

. Data-Structure Diagrams specify the overall logical structure of the database.


Summary

In this lesson, we discussed in details, one of the data models discussed in the previous lesson; the network model.


37

Assessment

Assessment


What are the basic concepts of network data models

Bibliography

Reading



3. Siberschatz …

38


Study Session 5

The Relational Model (1) Introduction

In this session, you will learn the first part of relational models. We would also explore a logical view of data, and examine keys and integrity rules

Learning Outcomes

Outcomes


5.1 define and discuss a logicsl view of data

5.2 explain the term keys

5.3 explain the integrity rules

Terminology Super key a combination of columns that uniquely identifies any row

within a relational database management system (RDBMS) table.

5.1 A Logical View of Data In our first lesson, you learnt that the DBMS manages and controls access to the data and the database structure and that places the DBMS between the application and the database. The result of this flexibility of the DBMS, however, is a more complex physical structure.

The database structures required by both the hierarchical and network database models often become complicated enough to diminish efficient database design. The relational data model however changed all of that by allowing the designer to focus on the logical representation of the data and its relationships, rather than on the physical storage details. We could liken the relational data model to the automatic gearing system in automatic vehicles which replaced the manual systems where you need to shift and adjust gears yourself. In essence, the relational model enables you to view data logically rather than physically and is much easier to understand than the hierarchical and network models.

Study Session 5The Relational Model (1)

39

Logical simplicity tends to yield simple and effective database design methodologies and the table plays a very important role in the relational model. Therefore, our discussion begins with an exploration of the details of table structure and contents.

Table Structure and Characteristics

The logical view of a relational database is based on relations. A relation is thought of as a table. A Table as a two-dimensional structure composed of rows (records or entity instances a.k.a. tuples) and columns (attributes or fields). It is essentially a group of related entities (entity set). We summarize in table 4.1, the characteristics of a table.

Table 5.1: Characteristics of a Table

Figure 3.6 in our previous lesson is a good picture of the structure of a table, but we show a more detailed structure of a table in figure 5.1 below. The figure shows the relation for a database entity STUDENT within the tiny college database.

Figure 5.1: Table (Relation) STUDENT showing its attributes

ITQ

Question

. What is the basis of the logical view of a relational database?

Feedback . The logical view of a relational database is based on relations.

40


5.2 Keys To understand the concept of keys in relational database and their importance, consider the following example. It is believed that everyone offering CIS201 is a student, however, we need to identify each student uniquely in order to properly record scores for each. Your unique identity as a student of this course is your matric number – your matric number in this case is a key. Key is one or more attributes that determine other attributes. Determination in database term means “if you know the value of attribute A, you can determine the value of attribute B”. Thus, if we know your matric number, we can know your name and your score in CIS305. Each row in a table must be uniquely identifiable and this necessitates the selection of one or more of the table attributes as the key attribute.

The principle of determination is very important because it is used in the definition of a central relational database concept known as functional dependence. The term functional dependence can be defined most easily this way: the attribute B is functionally dependent on A if A determines B. More precisely:

The attribute B is functionally dependent on the attribute A if each value in column A determines one and only one value in column B.

Using the contents of the STUDENT table in Figure 5.1, it is appropriate to say that STU_PHONE is functionally dependent on STU_NUM. For example, the STU_NUM value 321452 determines the STU_PHONE value 2134. On the other hand, STU_NUM is not functionally dependent on STU_PHONE because the STU_PHONE value 2267 is associated with two STU_NUM values: 324274 and 324291. (This could happen when roommates share a single landline phone number.) Similarly, the STU_NUM value 324273 determines the STU_LNAME value Smith. But the STU_NUM value is not functionally dependent on STU_LNAME because more than one student may have the last name Smith.

Let us learn the following definitions pertaining to keys and we will use Figure 5.1 to illustrate them

A Composite key is composed of more than one attribute. A Key attribute is any attribute that is part of a key A Superkey is any key that uniquely identifies each row A Candidate key is a superkey without unnecessary attributes A Primary key (PK) is a candidate key chosen to uniquely

identify every row in a relation (or to uniquely determine every other attribute in any given row).

A Secondary key is an attribute or a set of attributes which may not necessarily uniquely identify a row but are used strictly for data retrieval purposes.

A Foreign key (FK) is an attribute whose value matches primary key values in a related table. Foreign keys are used to enforce database referential integrity. A FK contains a value that refers to an existing valid row in another table/relation.


41

For instance, you could use the combination (STU_NUM, STU_LNAME, STU_FNAME, STU_INIT) as a key for the table, this combination is a composite key. Each attribute in the combination is a key attribute. On the other hand, you could decide to use the combination (STU_LNAME, STU_FNAME, STU_INIT) or (STU_LNAME, STU_FNAME, STU_INIT, STU_PHONE) as the key of the relation. Each of these three composite keys can be referred to as a Superkey if it uniquely identifies a row. However, a careful look at the first composite key reveals that STU_NUM is alone sufficient to identify a student without all the other attributes, STU_NUM is therefore a candidate key in this regard. Since the STU_NUM can uniquely identify any given row in this relation, it could be chosen as the primary key, while either the STU_LNAME or STU_FNAME could be used a secondary key. Assume a student’s mother decides to check up her child’s performance in school, she is not expected to know her child’s STU_NUM, but she definitely knows his surname (STU_LNAME) and this could be used to check up several students who possibly share the same surname, then it would be easier for her to identify her own child, that is the essence of a secondary key.

There are still more things to know about keys. Keys should not be null. A Null means no data entry for a particular attribute or field. This is not the same as entering a blank or space because a blank/space is itself a character. As much as possible, nulls should be avoided in other attributes, while they must not be allowed in primary keys.

Nulls could represent an unknown attribute value, a known, but missing, attribute value or a “not applicable” condition. An example of this is seen in the STU_INIT field of our STUDENT table in Figure 5.1, which is empty for the student with STU_NUM = 324258 because he doesn’t have an initial (an example of a “not applicable” condition).

Nulls should be avoided as much as possible because they can create problems when functions such as COUNT, AVERAGE, and SUM are used and can also create logical problems when relational tables are linked (relational tables are linked by their columns).

Relational databases employ what is called Controlled redundancy through the use of keys to create relationships between tables as shown in figure 4.2. Tables within the database share common attributes and these attributes enable such tables to be linked together. In this regard, multiple occurrences of values in a table is not redundant since it is required to make the relationship work, redundancy exists only when there is unnecessary duplication of attribute values.

Data redundancy leads to data anomalies and can destroy the effectiveness of the database. Foreign keys are used by relational databases to control data redundancies by using common attributes shared by tables and is crucial to exercising data redundancy control. Sometimes, data redundancy is necessary and this is one such case.

42


ITQ

Question

. List the terms pertaining to keys

Feedback

. Answer

The following are terms pertaining to keys:

A Composite key A Key attribute A Superkey A Candidate key A Primary key (PK) A Secondary key A Foreign key (FK)

5.3 Integrity Rules Integrity rules are meant to ensure data integrity in the database. Many RDBMs enforce integrity rules automatically, however, it is safer to ensure that your design conforms to entity and referential integrity rules summarized in table 5.2 below. Note that, instead of allowing null attribute values, you should use flags to indicate the absence of an attribute values.

Table 5.2: Integrity Rules


43

ITQ

Question

. What is the significant role of the integrity rule?

Feedback . Integrity rules are meant to ensure data integrity in the database.


Summary

In this session, you learnt the first part of relational models. We also explored a logical view of data, and examine keys and integrity rules

Assessment

Assessment


Define the Logical view of data


Explain the term keys?


Briefly explain the integrity rules

44


Bibliography

Reading


Study Session 6


In this session, we will continue our study into relational models. We would also examine the relationship in the relational model, database indexing and the data dictionary.


45

Learning Outcomes

Outcomes


6.1 highlight the types of relationships in a relational model and

6.2 define database indexing and the need for it.

6.3 explain and define what a data dictionary is.

Terminology

6.1 Relationships in the Relational Model You have already learnt in lesson 2, the types of relationships in a data model. Now let’s highlight some important points about the usage of each of these relationship types in database designs.

1:M Relationship: This is the ideal relationship in Relational data modeling and should be the norm in any relational database design. This is easily implemented in a relational database by placing the primary key of the relation on the one side in the relation on the many side. Figure 5.1a shows the ER diagram of a 1:M relationship between a painter and his/her painting while figure 5.1b shows the relational database tables with the primary key and foreign key used to implement the relationship.

Figure 5.1: 1:M Relationship between PAINTER and PANTING

46


1:1 Relationship: This should be rare in any relational database

design. Sometimes, it means that the entity components were not defined properly. It could indicate that the two entities should actually belong to the same table. However, certain conditions absolutely require their use as in the example shown in figure 5.2 below

Figure 5.2: 1:1 relationship between PROFESSOR and DEPARTMENT

M:N relationships: This cannot really be implemented in a the relational model without resolving it to a set of 1:M relationships. You should avoid problems inherent to M:N relationships by creating a composite entity (associative entity) which serves as a bridge in the relationship. The composite entity includes as foreign, keys the primary keys of tables to be linked (i.e. the tables involved in the relationship). Consider an example in Figure 5.3 below of the M:N relationship between STUDENT and CLASS. The relationship is resolved as shown in figure 5.4 by creating the associative entity called ENROLL.

Figure 5.3: M:N relationship between STUDENT and CLASS

Figure 5.4: An associative entity ENROLL is created to resolve

the M:N relationship to 2 1:M relationships

The primary keys of the two tables STUDENT and CLASS now for a composite primary key for the ENROLL table as shown in figure 5.5


47

Figure 5.5: Creating a composite primary key for the ENROL table

ITQ

Question

. Highlight the types of relationships in a data model

Feedback . The types of relationships includes:

1:M Relationship 1:1 Relationship M:N Relationship

6.2 Database Indexing The volume of data in databases necessitates the need for some means of quickly retrieving needed information from the database. This is achieved using indexes. An index is an orderly arrangement to logically access rows in a table. An index key is the index’s reference point which points to the data location identified by the key. A unique index is the index in which the index key can have only one pointer value (row) associated with it. Each index is associated with only one table. Figure 5.6 shows an example how indexes are created on the table PAINTING. Note that PAINTER_NUM in the table is a foreign key (the primary key of the painter table).

48


Figure 5.6: Indices on the PAINTING table.

ITQ

Question

. What is an index?

Feedback . An index is an orderly arrangement to logically access rows in a table.

6.3 The Data Dictionary As we’ve said earlier a Data dictionary provides detailed accounting of all tables and relationships found within the user/designer-created database. The data dictionary contains (at least) all the attribute names and characteristics for each table in the system – it contains metadata i.e. data about data.

Like the data dictionary, a System catalog contains metadata. However, it contains more details than the data dictionary. It is a detailed system data dictionary that describes all objects within the database.

Because the system catalog contains all required data dictionary information, the terms system catalog and data dictionary are often used interchangeably. In fact, current relational database software generally provides only a system catalog, from which the designer’s data dictionary information may be derived. The system catalog is actually a system-created database whose tables store the user/designer-created database characteristics and contents. Therefore, the system catalog tables can be queried just like any user/designer-created table.

ITQ

Question

. What can be likened to a data dictionary?

Feedback


49

. A system catalog can be likened to a data dictionary as it contains metadata too.


Summary

In this session, we continued our study into relational models. We also examined the relationship in the relational model, database indexing and the data dictionary.

Assessment

Assessment

SAQ 6.1 (tests Learning Outcome 6.1) Highlight and briefly explain the types of relationship in a relational model

SAQ 6.2 (tests Learning Outcome 6.2) What is the essence of database indexing?

SAQ 6.3 (tests Learning Outcome 6.3) What is a data dictionary?

Bibliography

Reading


50


Study Session 7


In this session, we would study the third part of relational model. Here, we would examine the relational algebra.

Learning Outcomes

Outcomes


7.1 Explain the relational algebra and relational set operators.

7.2 use relational set operators to retrieve information from the database

Terminology Domains an identification string that defines a realm of

administrative autonomy, authority or control within the Internet

7.1 Relational Algebra Relational Algebra defines a theoretical way of manipulating table contents using relational. When relational algebra operators are used on existing relations new relations are produced; this property of the operators is referred to as closure. In this lesson, we will learn about the following relational operators: SELECT, PROJECT, UNION, INTERSECT, JOIN, DIFFERENCE, PRODUCT and DIVIDE. Note that these operators are not case-sensitive but are rendered in upper case letters to distinguish as operators.

ITQ

Question

. What distinguishes the operators?

Feedback . The operators are not case sensitive. They are rendered in upper case


51

letters.

7.1.1 Select SELECT, also known as RESTRICT, yields values for all rows found in a table that satisfy a given condition. SELECT can be used to list all of the row values, or it can yield only those row values that match a specified criterion. In other words, SELECT yields a horizontal subset of a table. The effect of a SELECT is shown in Figure 6.1.

Figure 6.1: The SELECT Operator at work

ITQ

Question

. What is the function of the SELECT operator?

Feedback

. SELECT, also known as RESTRICT, yield values for all rows found in a table that satisfies a given condition.

7.1.2 PROJECT PROJECT yields all values for selected attributes. In other words, PROJECT yields a vertical subset of a table. The effect of a PROJECT is shown in Figure 6.2.

52


Figure 6.2: The PROJECT Operator at work

ITQ

Question

. What is the function of PROJECT operator?

Feedback . PROJECT yields all values for selected attributes.

7.1.3 UNION UNION combines all rows from two tables, excluding duplicate rows. The tables must have the same attribute characteristics (the columns and domains must be compatible) to be used in the UNION. When two or more tables share the same number of columns, and when their corresponding columns share the same (or compatible) domains, they are said to be union-compatible. The effect of a UNION is shown in Figure 6.3.

Figure 6.3: The UNION Operator at work


53

ITQ

Question

. What is the function of the UNION operator?

Feedback

. UNION combines all rows from two tables, excluding duplicate rows.

7.1.4 Intersection INTERSECT yields only the rows that appear in both tables. As was true in the case of UNION, the tables must be union-compatible to yield valid results. For example, you cannot use INTERSECT if one of the attributes is numeric and one is character-based. The effect of an INTERSECT is shown in Figure 6.4.

Figure 6.4: The INTERSECTION Operator at work

ITQ

Question

. State the function of the INTERSECT operator?

Feedback

. INTERSECT yields only the rows that appear in both tables.

7.1.5 Difference DIFFERENCE yields all rows in one table that are not found in the other table; that is, it subtracts one table from the other. As was true in the case of UNION, the tables must be union-compatible to yield valid results. The effect of a DIFFERENCE is shown in Figure 6.5. However, note that subtracting the first table from the second table is not the same as subtracting the second table from the first table.

Figure 6.5: The DIFFERENCE Operator at work

54


ITQ

Question

. What is the function of the DIFFERENCE operator?

Feedback

. DIFFERENCE yields all rows in one table that are not found in the other table; that is, it subtracts one table from the other.

7.1.6 Product PRODUCT yields all possible pairs of rows from two tables—also known as the Cartesian product. Therefore, if one table has six rows and the other table has three rows, the PRODUCT yields a list composed of 6 × 3 = 18 rows. The effect of a PRODUCT is shown in Figure 6.6.

Figure 6.6: The PRODUCT Operator at work

ITQ

Question

. What is the Function of the Product operator?

Feedback

. PRODUCT yields all possible pairs of rows from two tables—also known as the Cartesian product.

7.1.7 DIVIDE The DIVIDE operation uses one single-column table (e.g., column “a”) as the divisor and one 2-column table (i.e., columns “a” and “b”) as the dividend. The tables must have a common column (e.g., column “a”). The output of the DIVIDE operation is a single column with the values of column “a” from the dividend table rows where the value of the common column (i.e., column “a”) in both tables matches. Figure 6.7 shows a DIVIDE.


55

Figure 6.7: The DIVIDE Operator at work

ITQ

Question

. State the function of the DIVIDE operator

Feedback

. The DIVIDE operation uses one single-column table (e.g., column “a”) as the divisor and one 2-column table (i.e., columns “a” and “b”) as the dividend.

7.1.8 JOIN JOIN allows information to be combined from two or more tables. JOIN is the real power behind the relational database, allowing the use of independent tables linked by common attributes. There are several types of joins:

NaturalJoin links tables by selecting rows with common values in common attribute(s).

Equijoin links tables on the basis of an equality condition that compares specified columns.

Usually, the equality operator (=) is used in the equijoin and this informs its name. If any other comparison operator is used, it is called a Theta join.

All the several types of joins could either be classified as Inner join or Outerjoin. An inner join is a join that only returns matched records from the tables that are being joined. In an outer join, the matched pairs would be retained, and any unmatched values in the other table would be left null.

The CUSTOMER and AGENT tables shown in Figure 6.8 will be used to illustrate the several types of joins.

56


Figure 6.8: Tables CUSTOMER and AGENT that will be used to illustrate the JOIN operator

Figure 6.9: NATURAL JOIN, step 1: PROJECT

Figure 6.10: NATURAL JOIN, step 2: SELECT

Figure 6.11: NATURAL JOIN. Step 3: PRODUCT


57

ITQ

Question

. List the several types of JOIN operators

Feedback

. The several types of JOIN includes:

Natural Join Equijoin links Theta join.

All the several types of joins could either be classified as Inner join or Outer join.


Summary

In this session, we studied the third part of relational models. We also examined the relational algebra.

Assessment

Assessment


Define Relational Algebra?

SAQ7.2 (tests Learning Outcome 7.2)

List and explain the relational operators that are used in retrieving information from a database.

Bibliography

Reading


58


Study Session 8

Information Systems Introduction

In this session, we will study information systems. We would compare data and information, and cap off the session by defining and realizing information systems.

Learning Outcomes

Outcomes


8.1 give the meanings of data and information and their basic distinctions

8.2 define a system

8.3 define information systems

8.4 discuss computer based information system

8.5 realize information systems,

Terminology Feedback mechanism

is a process that uses the conditions of one component to regulate the function of the other.

CBIS A computer-based information system, or CBIS, uses computers to collect, process, store, analyze and distribute information for a specific purpose, such as meeting a business objective.

Spreadsheets a sheet of paper that shows accounting or other data in rows and columns

WAN Wide area network

8.1 Data versus Information Data can be defined as basic, raw, unprocessed or unorganized facts. Processing data by defining relationships between them and organizing them coherently produces information. Information can therefore be defined as a collection of facts organized in such a way that they have additional value beyond the value of the facts themselves.

Study Session 8Information Systems

59

Data is also defined as distinct pieces of information, usually formatted in a special way. Every software is divided into two general categories: data and programs. Programs are collections of instructions for manipulating data.

Data can exist in a variety of forms – as numbers or text on pieces of paper, as bits and bytes stored in electronic memory, or as facts stored in a person's mind. Actually, data is the plural of datum; a single piece or item of data, but many people often use the term data as both singular and plural.

Table 8.1 shows the types into which data can be classified and figure 8.1 shows the transition from data into information. For any piece of information to be regarded as valuable, it should be accurate, complete, economical, flexible, reliable, relevant, simple, timely, verifiable, accessible and secure.

Table 8.1: Data Types

Data Representation

Text (alphanumeric) data Numbers, letters, and other characters

Image data Graphic images or pictures

Audio data Sound, noise, tones

Video data Moving images or pictures

Figure 8.1: From data to information

ITQ

What makes an information valuable?

Answer

For an information to be valuable, it should have the following features:

Accurate Complete Economical Flexible Reliable Relevant Simple Timely Verifiable

Data Transformation Information

60


Accessible Secure.

8.2 System A system is a collection of elements or components that interact to achieve goals. For instance, a computer system includes both hardware and software.

Important elements of a system are its input, processing and output components/elements. In a Computer Based Information System (CBIS), the input elements could include certain hardware components (e.g. mouse, keyboard, webcam, scanners etc.), the processing elements may include the software components (operating system, database management systems) and the computer processor while the output elements will include the output hardware components such as the printer, display screen, audio speakers etc.

ITQ

Question

.Name the important elements of a system

Feedback

.Important elements of a system are its input, processing and output components/elements.

8.2.1 System Components and Concepts The system boundary defines the system and distinguishes it from everything else.

System types include Simple vs. complex; Open vs. closed; Stable vs. dynamic; Adaptive vs. non-adaptive; Permanent vs. temporary.

ITQ

Question

.What is the essence of a System boundary?

Feedback

.It defines the system and distinguishes it from everything else.

8.2.2 System Performance and Standards Efficiency: A measure of what is produced divided by what is consumed

Effectiveness: A measure of the extent to which a system achieves its goals


61

System performance standard: A specific objective of the system.

8.2.3 System Variables and Parameters System variable: A quantity or item that can be controlled by the decision maker e.g. the price a company charges for a product.

System parameter: A value or quantity that cannot be controlled by the decision maker e.g. the cost of a raw material.

8.2.4 System Modelling A model is an abstraction or an approximation that is used to represent reality. A system model can be Narrative, Physical, Schematic or Mathematical.

A narrative model of a system is an oral or textual description of a system in terms of its components and functionalities. A physical model gives a physical (simulated) representation of an actual system e.g. 3D architectural designs. A schematic model is a graphical representation of a system usually depicted with the use of symbols and notations e.g. a UML diagram. Mathematical models describe a system using mathematical equations and formulae.

ITQ

Question

.What is a model with respect to a system?

Feedback

.A model is an abstraction or an approximation that is used to represent reality. A system model can be Narrative, Physical, Schematic or Mathematical.

8.3 Definition of Information Systems An information system is a set of interrelated components that collect, manipulate, store data and disseminate information and provide a feedback mechanism to monitor performance. It can also be described as an organized combination of people, hardware, software, communications networks, and other resources for collecting data and transforming it, and disseminating information.

Like any other system, an Information System is composed of input, processing, output elements and in addition a feedback component as shown in figure 8.2. Input refers to the activity of gathering and capturing data, processing refers to the activity of converting or transforming data into useful outputs while output refers to useful information, usually in the form of documents and/or reports.

62


Figure 8.2: Information System

The feedback component is an important component of an Information System. As depicted in figure 8.2 above, feedback is simply output fed back into the input or processing components/stages of the system in order to enhance those stages and consequently improve future outputs. Forecasting is a proactive feedback approach used to predict or estimate future outputs.

Information Concepts

We will now define the following concepts/terminologies which are pertinent to information systems.

Process: A set of logically related tasks performed to achieve a defined outcome.

Knowledge: An awareness and understanding of a set of information and ways that information can be made useful to support a specific task or reach a decision.

Knowledge Base:The collection of data along with rules, procedures, and relationships that must be followed to achieve value or a desired outcome.

Value: The value of information is determined by how much impact it has in helping decision makers achieve their desired outcome.

ITQ

Question

.What is the most important component of an Information System?

Feedback

.The most important component of an Information System is the Feedback component.

8.4Computer Based Information System A Computer-Based Information System (CBIS) is an Information System composed of Hardware, Software, databases, telecommunication, network, people and procedures. These components are configured so

Input Processing Output

Feedback


63

that they can interact to collect, store, and process data to produce meaningful information.

8.4.1 Hardware and Software Hardware refers to objects that you can actually touch, like disks, disk drives, display screens, keyboards, printers, boards, and chips. In contrast, software is untouchable. Software exists as ideas, concepts, and symbols, but it has no substance. Software is computer instructions or data. Anything that can be stored electronically is software. The storage devices and display devices are hardware.

We can illustrate the concept of hardware and software using the analogy of a book. The pages and the ink are the hardware, while the words, sentences, paragraphs, and the overall meaning are the software. A computer without software is like a book full of blank pages -- you need software to make the computer useful just as you need words to make a book meaningful.

The distinction between software and hardware is sometimes confusing because they are so integrally linked. Clearly, when you purchase a program, you are buying software. But to buy the software, you need to buy the disk (hardware) on which the software is recorded.

Software is often divided into two categories. Systems software includes the operating system and all the utilities that enable the computer to function. Applications software includes programs that do real work for users. For example, word processors, spreadsheets, and database management systems fall under the category of applications software.

The terms software and hardware are used as both nouns and adjectives. For example, you can say: "The problem lies in the software," meaning that there is a problem with the program or data, not with the computer itself. You can also say: "It's a software problem“.

ITQ

Question

.List the components of a CBIS

Feedback

.The components of a CBIS includes: Hardware, Software, databases, telecommunication, network, people and procedures.

8.4.2 Databases A database is a collection of information organized in such a way that a computer program can quickly select desired pieces of data. You can think of a database as an electronic filing system. Traditional databases are organized by fields, records, and files. A field is a single piece of information; a record is one complete set of fields; and a file is a collection of records. For example, a telephone book is analogous to a

64


file. It contains a list of records, each of which consists of three fields: name, address, and telephone number.

To access information from a database, you need a database management system (DBMS). This is a collection of programs that enables you to enter, organize, and select data in a database.

ITQ

Question

.What is a database management system?

Feedback

.It is a collection of programs that enables you to enter, organize, and select data in a database.

8.4.3 Telecommunication and Networks Telecommunications refer to the electronic transmission of signals for communications. It enables organizations to link computer systems into effective networks. Telecommunication involves all types of data transmission, from voice to video.

Networks refer to the connection of computers and other electronic devices in order to enable electronic communication. Networks could range from covering small areas such as a room to covering wide areas such as an entire country or the whole world.

Networks can be classified according to their sizes as local-area network (LAN) and wide-area network (WAN).In a LAN, the connected devices are geographically close together (that is, in the same building). WANs span a larger geographical region – sometimes across countries.

In addition, networks can also be classified according to topology, protocol and architecture. Topology is the physical or logical layout of devices on a network. Common network types according to topology include a bus, star, and ring.

Protocol defines a common set of rules and signals that computers on the network use to communicate. One of the most popular protocols for LANs is called Ethernet. Another popular LAN protocol for PCs is the IBM token-ring network.

In terms of architecture, networks can be broadly classified as using either a peer-to-peer or client/server architecture.

ITQ

Question

.What are the classes of network?


65

Feedback .Networks can be classified according to their sizes as:

Local Area Network (LAN) Wide Area Network (WAN)

8.4.4 People and Procedures: The most important element in most CBIS is the people. This Includes people who manage, run, program, and maintain the system e.g., IT professionals.

Procedures Includes the strategies, policies, methods, and rules for using the CBIS.

ITQ

Question

.What is the most important element in Computer Based Information System (CBIS)?

Feedback

.The most important element in most CBIS is the people. This Includes people who manage, run, program, and maintain the system e.g., IT professionals.

8.5 Realizing Information Systems Processes involved in realizing IS include

Systems development is the activity of creating or modifying an existing business system.

Systems investigation and analysis defines the problems and opportunities of an existing system.

Systems design determine how a new system will work to meet business needs.

Systems implementation is the process of creating and acquiring system components as defined in the design.

Systems maintenance and review checks and modifies the system so that it continues to meet changing business needs.

ITQ

Question

.What is System development in realizing a Information Systems?

Feedback

66


.System development is the activity of creating or modifying an existing business system.


Summary

In this session, we studied information systems. We also compared data and information, and capped off the session by defining and realizing information systems.

Assessment

Assessment

SAQ 8.1 (tests Learning Outcome8.1) Discuss the differences between Data and Information

.

SAQ 8.2 (tests Learning Outcome 8.2) What is a system?


What is an Information system?


Briefly explain CBIS


State the processes involved in realizing an Information System?

Bibliography

Reading

1. Shelly G. B. and Rosenblatt H. J. (2010). System Analysis and Design. Cengage Learning. 8th edition


Study Session 9Computer-Aided Software Engineering (CASE)

67

Study Session 9

Computer-Aided Software Engineering (CASE)

Introduction Computer Aided Software Engineering (CASE) is a collection of standards and tools that aid the analysis, design and development of Systems. In this session, we would examine CASE tool component and diagramming tools, and limitations of CASE

Learning Outcomes

Outcomes


9.1 define computer aided software engineering

9.2 explain CASE tool components

9.3 describe CASE diagramming tools

9.4 discuss CASE repository

9.5 highlight the benefits of using CASE tools

9.6 list the limitations of CASE

Terminology Methodology the systematic, theoretical analysis of the methods applied

to a field of study.

Repository A software repository is a storage location from which software packages may be retrieved and installed on a computer.

9.1 CASE Overview Computer Aided Software Engineering (CASE) are the software tools that provide automated support for some portion of thesystems development process. It is an abstraction based methodology based on diagrams (pictures). CASE can be used to model any system.

Why Do We Use CASE

68


TEAM: Teams share system development tasks based on the size

of the development team, the size and scope of the project, the skill & experience of the team etc.

Documentation used for communication. STRUCTURED METHODOLOGIES: used to document all

systems to a universally accepted defined standards. Structured Methodology tool of interest : Depending on the CASE tool, the system development activities

covered may include: project identification and selection, project initiation and planning, analysis, design, implementation and maintenance.

Objectives of CASE

To improve quality of developed systems To increase speed of systems development To improve testing process through automatic checking To integrate development activities (common methods) To improve documentation (quality and completeness) To standardise the development process To simplify program maintenance To promote reusability of modules & documentation To improve software portability across environments

ITQ

Question

.Highlight five(5) objectives of CASE

Feedback

.To improve quality of developed systems To improve testing process through automatic checking To improve documentation (quality and completeness) To simplify program maintenance To improve software portability across environments

9.2 CASE Tool Components CASE tool components vary depending on which CASE tool is considered but in general will include:

diagramming facilities means of describing/defining functional and data objects means of identifying relationships between system components central repository of system information error checking facilities (syntax errors) consistency and completeness checks user interface generators database specification


69

code generators project management aids documentation generators It may also provide features for group working, version control,

interfacing facilities and security features.

ITQ

Question

.How does CASE tools components vary?

Feedback

.CASE tool components vary depending on which CASE tool is considered.

9.3 CASE Diagramming Tools CASE Diagramming tools perform the following functions:

checks for syntactic correctness consistency & completeness checks navigation to linked diagrams data dictionary support layering of system components traceability of requirements report generation system simulation/performance analysis (models)

9.4 CASE Repository A repository is a centralised database containing all models (diagrams), data dictionary entries, form & report definitions and system & organisational information. It holds complete information needed to develop a system from initiation to maintenance. It helps supports team Information System development.

70


Figure 9.1: CASE Repository

ITQ

Question

.Mention one of the functions of CASE Repository

Feedback .It holds complete information needed to develop a system from initiation to maintenance.

9.5 Benefits of Using CASE Tools Automation of tedious tasks Syntax/completeness checks ensure consistency Amending/updating achieved far more easily documentation can be kept up-to-date beneficial effect on maintenance More rapid development more feasible to develop & evaluate alternative designs an aid to prototyping Capture of system data for reuse particularly important for OO development May guide the use of a methodology Clearer communication with users Continuity of development with changing staff Standardised quality assurance/test procedures Improvements in system quality Reduction in defects increases morale.


71

ITQ

Question

.Highlight three(3) benefits of using CASE tools

Feedback

.CASE tools helps in:

Capture of system data for reuse May guide the use of a methodology Standardised quality assurance/test procedures

9.6 Limitations of CASE Limited flexibility in documentation. Standards may not suit

organisation or project needs Development approach limited to fit capabilities of the CASE

tool: May not adhere to industry or organisational standards. Training and experience required Front loaded cost of installation of CASE tool & training benefits may outweigh initial costs Incomplete coverage of syntax/ consistency checks Limited intelligence - no checks on overall quality or correctness

ITQ

Question

.What are the limitations in CASE?

Feedback

.Front loaded cost of installation of CASE tool & training benefits may outweigh initial costs Incomplete coverage of syntax/ consistency checks.


Summary

Computer Aided Software Engineering (CASE) is a collection of standards and tools that aid the analysis, design and development of Systems. In this session, we examined CASE tool component and diagramming tools, and also limitations of CASE

72


Assessment

Assessment


Define CASE, state its functions and objectives.


List five(5) general CASE tool components


Highlight the functions of CASE diagramming tools


What is a CASE Repository?


Highlight the benefits of using CASE tools

SAQ 9.6 (tests Learning Outcome 9.6) List five(5) limitations of CASE

Bibliography

Reading



Study Session 10Unified Modelling Language (UML)

73

Study Session 10

Unified Modelling Language (UML)

Introduction In this lesson, we will look at the two major classes of UML diagrams and only look at one example from each class with relevant examples.

Learning Outcomes

Outcomes

When you have studied this session, you should be able to

10.1 explain Unified Modeling Language (UML)

10.2 describe and trace UML diagrams

10.3 identify the different classes of UML diagrams – structural and behavioral diagrams

10.4 use case diagrams

Terminology Artifacts something made or given shape by man, such as a tool or a

work of art, especially an object of archaeological interest".

UML The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the field of software engineering, that is intended to provide a standard way to visualize the design of a system.

10.1 UML Overview UML stands for “Unified Modelling Language”. It is an industry-standard, general purpose visual modelling language for specifying, visualizing, constructing, and documenting the artefacts of software systems. UML is used to understand, design, browse, configure, maintain and control information about systems. It simplifies the process of System Design.

74


UML includes semantic concepts, notations, and guidelines. It has static, dynamic, environmental, and organizational parts. It was motivated by and is intended to support most object-oriented development processes.

UML is not a programming language. It’s a general purpose language unified across application domains, historic notations, development lifecycle etc. UML helps define systems to standard and simplifies system design as it concisely captures several object-oriented development concepts.

ITQ

Question

.What kind of language is the UML?

Feedback

.The UML is a general purpose language unified across applicationdomains, historic notations, development lifecycle etc.

10.2 UML Diagrams UML Diagrams are classified into Structural and Behavioural diagrams as shown in figure 10.1. Structural Diagrams are used to model the static structure of a system. They are used to represent the physical entities and components of the system and also model relationships, associations and dependencies between these elements. Behavioural Diagrams model the behaviour of the system.

They capture the interaction between system elements and also represent the instantaneous states as well as state changes in the system.

The UML is a very comprehensive model and we often do not need to use all the diagrams for small/medium sized systems. Thus, in this lesson we will look at just one example from each class of diagrams. You will possibly learn more about other diagrams in Software Engineering or System Analysis and Design.


75

Figure 10.1: Classes of UML Diagrams

ITQ

Question

.What are the two types of UML Diagrams?

Feedback

.UML Diagrams are classified into Structural and Behavioural diagrams.

10.3 Class Diagram Class Diagrams are static structure diagrams (as defined by UML) used for describing the system structure. They provide a conceptual model of the system in terms of its entities (classes), their attributes and their relationships. Class diagrams are used for requirements capture and end-user interaction.

In a class diagram, each class is represented by a rectangle subdivided into three compartments

Name (1st Compartment) Attributes (2nd Compartment) Operations (3rd Compartment)

Modifiers are used to indicate visibility of attributes and operations.

‘+’ is used to denote Public visibility (everyone has access) ‘#’ is used to denote Protected visibility (friends and derived

classes have access) ‘-’ is used to denote Private visibility (no one has access to this

except itself)

76


‘~’ is used to denote Package visibility (classes within the same

package have access)

The class diagram also makes provisions for an interface which is shown in figure 10.3. An interface specifies the services that are provided and can be implemented by classes. An example of a class is shown in figure 10.2. Table 10.1 gives descriptions and symbols of the relationships used

in class diagrams and figure 10.4 is an example of a class diagram modelling a reservation system for a cinema.

Relationship Function Notation

Association A description of a connection among instances of classes. It may include roles, cardinality and constraints.

Figure 10.2: A UML Class.

Figure 10.3: A UML Interface.

Table 10.1: Relationships and their notations in UML Class diagram


77

Dependency A relationship between classes in which the behaviour or implementation of one class affects the other. Some types of this relationship include «instantiate», «trace», «import», «usage» etc. Dependency is used to model relationship whose true nature cannot be ascertained at early stages of the design.

Generalization A relationship between a more general description and a more specific variety of the general thing, used for inheritance

Realization Relationship between a specification and its implementation, used for interface implementation

Nesting A relationship between a class and its nested inner class

Figure 10.4: An example of a UML class diagram.

78


UML class diagram also uses cardinalities to represent the number of instances of a class that can participate in a relationship. The following are the symbols for the cardinalities and their respective meanings:

One and only one 0..1 Zero or one M..N From M to N (natural language) * From zero to any positive integer 0..* From zero to any positive integer 1..* From one to any positive integer

ITQ

Question

.What are class diagrams used for?

Feedback

.Class diagrams are used for requirements capture and end-user interaction.

10.4 Use Case Diagrams A Use case diagram is a type of Behavioural Diagram defined by UML. A Use Case Diagram is used to present a graphical overview of the functionalities provided by a system. It’s used for capturing user requirements and for describing a set of user scenarios (i.e. possible cases of use, hence, the name, “Use Case”).

The following are the components of a use case diagram:

Actors: A role that a user plays with respect to the system including human users and other systems, e.g. inanimate physical objects (e.g. robot); an external system that needs some information from the current system.

Use case: A set of scenarios that describes an interaction between a user and a system, including alternatives. It is indicated with an oval labelled with the name of the use case.

System boundary: A rectangle diagram representing the boundary between the actors and the system.

Association: Indicates communication between an actor and a use case. It is represented by a solid line with an optional hollow arrowhead. Associations may also include multiplicity to indicate the number of actors that can take an action per time.

Generalization: Indicates relationship between one general use case and a special use case (used for defining special alternatives). It is represented by a line with a triangular arrow head toward the parent use case.

Include: a dotted line labeled «include» beginning at base use case and ending with an arrow pointing to the include use case. The “include” relationship occurs when a chunk of behavior is


79

similar across more than one use case. Use “include” instead of copying the description of that behavior.

Extend: a dotted line labeled «extend» with an arrow toward the base case. The extending use case may add behavior to the base use case. The base case declares “extension points”.

Figure 10.5: Example of a UML Use Case diagram.

Figure 10.5 is an example of UML use case diagram modelling the usage scenarios in a hospital. Pay Bill is a parent use case and Bill Insurance is the child use case (using generalization). Both Make Appointment and Request Medication include Check Patient Record as a subtask (using include). The extension point is written inside the base case Pay bill; the extending class Defer payment adds the behavior of this extension point (using extend).

ITQ

Question

.What is Use case diagram?

Feedback

.A Use case diagram is a type of Behavioural Diagram defined by UML

80



Summary

In this lesson, we will look at the two major classes of UML diagrams and only look at one example from each class with relevant examples.

Assessment

Assessment


What is UML


Identify and explain briefly the classes of UML diagram


Define modifiers and list the types of modifiers used in the class diagram?


List and briefly explain the components of a use case diagram?

Bibliography

Reading

1. J. Rumbaugh, I. Jacobson, G. Booch. The Unified

Modeling Language Reference Manual. Addison-Wesley

Longman Inc, 1999.

2. Majid Ali Kahn. Introduction to UML (presentation).

Spring 2005.

3. Reference Guide for UML 2.0. 2007

Study Session 11Data Flow Diagrams (DFD)

81

4. ByDan Pilone, Neil Pitman. UML 2.0 in a Nutshell.

O’Reilly, June, 2005.

5. Sparx Systems UML Tutorial. Available at

http://www.sparxsystems.com

Donald Bell. UML Basics: An Introduction to the Unified Modeling Language in The Rational Edge, Rational Software. 2003

Study Session 11

Data Flow Diagrams (DFD) Introduction

In this session, you will study data flow diagram (DFD). We would also have an overview of DFD and learn how to create DFDs.

Learning Outcomes

Outcomes


11.1 define what data flow diagrams are

11.2 create data flow diagrams

Terminology DFD graphical representation of the "flow" of data through an

information system, modelling its process aspects.

11.1 Overview of DFD A Data Flow Diagram (DFD) shows how data moves through an information system but does not show the logic or processing steps within the system. A set of DFDs provides a logical model that shows what the system does, but not how it does it. That distinction is important because

82


focusing on implementation issues at this point would restrict your search for the most effective system design.

DFDs use four basic symbols that represent processes, data flows, data stores, and entities. There are several different versions of DFD symbols, but they all serve the same purpose. For the purpose of this lesson, we will use the Gane and Sarson symbol set of DFD. Another popular notation is the Yourdon symbol set; figure 11.1 shows examples of both versions indicting all the four symbol types. Symbols are referenced by using all capital letters for the symbol name.

Having previously studied how to develop E-R diagrams from business rules, it suffices to note that many elements of business processes cannot be represented by E-R diagrams. For instance, below is a list of business processes and entities which cannot be adequately captured by E-R diagrams.

Actors (individuals, organizations) which generate input data and/or receive output data;

Data transformations using specific business rules (which often requires application-level code);

Data storage or display that may or may not correspond to entities (e.g. views, reports, temporary tables, screens);

Data flows between actors, processes or data stores over time Manual versus automated processing.

Many business processes can be so complex that E-R design alone will not give system analysts insight into their businesses. DFDs are the link between initial business analysis, E-R diagrams and relational database models.

Figure 11.1: DFD Symbols

ITQ


83

Question

.What are the business processes and entities the E-R diagrams cannot adequately capture?

Feedback

.Below is the list of business processes and entities which cannot be adequately captured by E-R diagrams

Actors (individuals, organizations) which generate input data and/or receive output data;

Data transformations using specific business rules (which often requires application-level code);

Data storage or display that may or may not correspond to entities (e.g. views, reports, temporary tables, screens);

Data flows between actors, processes or data stores over time Manual versus automated processing.

11.2 Creating DFDs The following guidelines will help simplify and avoid errors in the DFD creation process.

Define Entities: External entities represent persons, processes or machines which produce data to be used by the system or receive data that is output by the system. Examples include Student, Customer and Client; see figure 11.2a.

Define Processes: Processes are discrete actions that transform input data to output data. Examples include Create Student Record, Calculate Purchase Cost and Register Client; see figure 11.2b.

Define Data Stores: Data stores are temporary or permanent repositories of information that are inputs to or outputs of processes. Examples: Student Master, Client List; see figure 11.2c.

Define Data Flows: Data flows represent the transfer of data over time from one “place” (entity, process, data store) to another. An example is seen in a New Student Information (from Student, to Student Master); see figure 11.2d.

Define the System: A system is the collection of all business processes which perform tasks or produce outputs we care about. The system is a single process, connected to external entities and it is represented in a “Context Diagram”.

Define Subsystems: A subsystem gives a more detailed view of the individual processes contained in the context diagram. It includes data stores, more elementary processes etc.

84


Figure 11.2: DFD Creation process.

Table 11.1: Examples of correct and incorrect use of DFD symbols.

Student

2.1

Create Student Record

Student Master D3 New Student Information

a. Entity creation b. Process creation

c. Data store creation d. Data flow creation


85

11.2.1 Top-Down Analysis of DFD Creation see figure 11.3

Create a narrative; a description of the system Create a Context Diagram that contains a single process (“the

system”) and all entities which share data with the system Explode the “parent” context diagram to produce a Diagram 0

(“child”) DFD Create Diagram 1, 2, … , n DFDs that represent “explosions” of

Diagram 0, 1, …, n-1 DFDs until a diagram has only “primitive” processes

Create process descriptions to be implemented by application programs: queries, macros, reports, programming languages

Figure 11.3: Top-down analysis of the DFD creation process.

ITQ

Question

.Highlight the top-down analysis of the DFD creation process?

Feedback

.Create a narrative; a description of the system Create a Context Diagram that contains a single process (“the

system”) and all entities which share data with the system Explode the “parent” context diagram to produce a Diagram 0

(“child”) DFD Create Diagram 1, 2, … , n DFDs that represent “explosions” of

Diagram 0, 1, …, n-1 DFDs until a diagram has only “primitive” processes

86


Create process descriptions to be implemented by application

programs: queries, macros, reports, programming languages

11.2.2 Where to Begin Creating DFDs Start with the data flow from an external entity and work forwards. Start with the data flow to an external entity and work backwards. Examine the data flows into or out of a data store. Examine data flows, entity connections and data stores associated with a particular process. Note fuzzy, ill-defined areas of the system for further clarification.

ITQ

Question

.Where does a data flow begin?

Feedback

.The data flow begins from an external entity and work forwards, start with the data flow to an external entity and work backwards.

11.2.3 What to Avoid During DFD Creation Table 11.2: What to avoid in DFD creation.

S/N What to avoid Diagram

1. Processes with no outputs or no input. Processes whose inputs are obviously inadequate to yield outputs.

2. Having data flows terminate at data stores. Connecting data stores directly to each other.

3. Connecting entities to anything other than processes. Having data flows terminate at data stores

4. Many processes with a single input and output (linear flow).

Making the data flow diagram too cluttered (e.g. 9 processes)

ITQ

Question


87

.Highlight the steps to avoid in creating a DFD

Feedback

.Processes with no outputs or no input. Processes whose inputs are obviously inadequate to yield

outputs. Having data flows terminate at data stores. Connecting data stores directly to each other. Connecting entities to anything other than processes. Having data flows terminate at data stores. Many processes with a single input and output (linear flow). Making the data flow diagram too cluttered (e.g. 9 processes).

11.2.4 DFD Creation; an Example We will now look at a typical example of creating a DFD.

Example:

Buses come to a garage for repairs. A mechanic and helper perform the repair, record the reason for the repair and record the total cost of all parts used on a Shop Repair Order. Information on labor, parts and repair outcome is used for billing by the Accounting Department, parts monitoring by the inventory management computer system and a performance review by the supervisor.

Key process (“the system”): performing repairs and storing information related to repairs

External Entities: Bus, Mechanic, Helper, Supervisor, Inventory Management System, Accounting Department, etc.

Processes: Record Bus ID and reason for repair; Determine parts needed; Perform repair; Calculate parts extended and total cost; Record labor hours, cost

Data stores: Personnel file, Repairs file, Bus master list and Parts list

Data flows: Repair order, Bus record, Parts record, Employee timecard and Invoices

88


Figure 11.4: Context Diagram for the Bus Garage


Summary

In this session, you studied data flow diagram (DFD). We also had an overview of DFD and learnt how to create DFDs.

Assessment

Assessment

SAQ 11.1 (tests Learning Outcome 11.1) Briefly explain what a DFD is?

SAQ 11.2 (tests Learning Outcome 11.2) Explain the process of a DFD creation?

Study Session 12Multi-User Databases

89

Bibliography

Reading



Study Session 12

Multi-User Databases Introduction

In this session, we will explore multi-user database. You will also study transaction management and standard, and database recovery.

Learning Outcomes

Outcomes


12.1 define the concept of transaction management

12.2 highlight and explain the ACIDS properties of a database transaction

90


12.3 explain Standards of database transactions

12.4 define Database recovery techniques

Terminology SQL a special-purpose programming language designed for

managing data held in a relational database management system (RDBMS), or for stream processing in a relational data stream management system (RDSMS).

12.1 Transaction Management A transaction is a logical unit of work that must be either entirely completed or aborted. A successful transaction changes the database from one consistent state to another – one in which all data integrity constraints are satisfied.

Most real-world database transactions are formed by two or more database requests which are equivalents of a single SQL statement in an application program or transaction. A user’s program may carry out many operations on the data retrieved from the database, but the DBMS is only concerned about what data is read/written from/to the database. A transaction is therefore the DBMS’s abstract view of a user program: a sequence of reads and writes.

ITQ

Question

.Define a transaction?

Feedback

.A transaction is a logical unit of work that must be either entirely completed or aborted.

12.2The ACIDS Properties of a Database Transaction

The properties of a transaction are referred to by the ACIDS acronym explained below:

Atomic: Either all actions are carried out or none are. We need not worry about incomplete transactions.

Consistency: DBMS assumes that the consistency holds for each transaction. Consistency defines the permanence of a database’s consistent state.


91

Isolation: Data used during a transaction cannot be used by a second transaction until the first is completed.

Durability: The effects of transaction persists if DBMS informs the user successful execution. Once transactions are committed, they cannot be undone.

Serializability: The concurrent execution of several transactions yields consistent results.

Not all transactions update the database and improper or incomplete transactions can have devastating effects on database integrity. Therefore, there is need for DBMSs to provide means by which users can define enforceable constraints while other integrity rules are enforced automatically by the DBMS. Also, multiuser databases are subject to multiple concurrent transactions which can lead to inconsistency in the database state, thus, the need for strict integrity constraints.

ITQ

Question

.What are the ACIDS properties of a Database Transaction?

Feedback

.The properties of a database transaction are referred to ACIDS which is an acronym which means:

Atomic Consistency Isolation Durability Serializability

12.3Transaction Standards American National Standards Institute (ANSI) has defined standards that govern SQL database transactions. Transaction support in any DBMS is provided by two SQL statements: COMMIT and ROLLBACK. The sequence of every transaction must continue until

COMMIT statement is reached OR ROLLBACK statement is reached OR End of program is reached OR Program is abnormally terminated

DBMSs also provide a Transaction log which stores the following:

ITQ

Question

.What information is stored in the transaction log of a DBMS?

92


Feedback

.The Transaction log provided by the DBMS stores the following:

A record for the beginning of the transaction For each transaction component: Type of operation being performed (update, delete, insert) Names of objects affected by transaction “Before” and “after” values for updated fields Pointers to previous and next transaction log entries for the same

transaction Ending (COMMIT) of the transaction

12.4Database Recovery Database recovery restores database to its previous consistent state based on the atomicity property of transactions. Database recovery is necessitated by failures such as hardware or software failure, human errors or natural disasters. In this lesson we will only discuss transaction recovery, which is an aspect of database recovery.

All portions of a transaction are treated as a single logical unit of work and all operations must be applied and completed in order to produce a consistent database. Transactions, whose operations cannot be completed are aborted and the changes made to the database are rolled back. The following are important concepts in the database recovery process:

Write-ahead-log protocol ensures transaction logs are written before data is updated

Redundant transaction logs ensure physical disk failure will not impair the ability to recover the database.

Buffers are temporary storage areas in primary memory Checkpoints are operations in which the DBMS writes all its

updated buffers to disk

Transaction recovery majorly employs the Deferred-write technique and write-through technique to ensure that the database’s consistent state is recovered after transaction failures.

In Deferred-write technique, only the transaction log is updated. The recovery process is as follows:

identify the last checkpoint If transaction committed before checkpoint Do nothing If transaction committed after checkpoint Use transaction log to redo the transaction If transaction had ROLLBACK operation Do nothing

In Write-through technique the database is immediately updated by transaction operations during transaction’s execution. The recovery process is as follows:

identify the last checkpoint


93

If transaction committed before checkpoint Do nothing If transaction committed after last checkpoint DBMS redoes the transaction using “after” values If transaction had ROLLBACK or was left active Do nothing because no updates were made

ITQ

Question

.What are the techniques deployed to ensure transaction recovery?

Feedback

.Transaction recovery majorly employs the Deferred-write technique and write-through technique to ensure that the database’s consistent state is recovered after transaction failures.


Summary

In this session, we explored multi-user database. You also studied transaction management and standard, and database recovery.

Assessment

Assessment

SAQ 12.1 (tests Learning Outcome 12.1) What depicts a successful transaction?

SAQ 12.2 (tests Learning Outcome 12.2) Explain the ACIDS properties of a database transaction?

SAQ 12.3 (tests Learning Outcome 12.3) According to the American National Standards Institute (ANSI) what statements are provided in a DBMS transaction support stating what guarantees the sequence of a transaction?

SAQ 12.4 (tests Learning Outcome 12.4) Discuss the process in the transaction recovery techniques

94


Bibliography

Reading



Study Session 13

REVISION Introduction

Having learnt so much in the last 12 lessons, we will use this last lesson, to review what we have learnt so far.

Learning Outcomes

Outcomes


13.1 define file systems and databases

13.2 describe data models

13.3 discuss the relational model

13.4 discuss the information system

13.5 explain the concept of computer-aided software engineering

13.6 discuss concepts in multi-user databases

Study Session 13REVISION

95

Terminology CBIS A computer-based information system, or CBIS, uses

computers to collect, process, store, analyze and distribute information for a specific purpose, such as meeting a business objective.

13.1 File Systems and Databases In lesson 1, we learnt that the file system stores records in a hierarchical tree-like structure and often requires extensive programming especially in the case of updates, insertions or deletions. Databases help store data in a compact structure which facilitates the management and retrieval of data. Some of the advantages of databases over file system include Data Independence, No data redundancy, Structural Independence, reduced application development time and the availability data modelling and design.

ITQ

Question

.Mention some of the advantages of a database system over a file system

Feedback

.Some of the advantages of databases over file system include:

Data Independence No data redundancy Structural Independence Reduced application development time and The availability data modelling and design.

13.2 Data Models In lesson 2, we studied the different data models available for database design and how they have evolved over the years. Some of the data models we mentioned were the hierarchical model, the network model, the relational model, the entity-relationship model, the object-oriented model and the object-relational or extended relational model.

ITQ

Question

96


.How many data models were mentioned in these chapter?

Feedback

.There were 6 data models.

13.3 The Relational Model In lessons 4, 5 and 6, we discussed extensively on the relational model. We defined the table as a structure with rows and columns and each row/column intersection gives a single attribute value. We explained the different types of attributes – composite attributes, derived attributes, key attributes. We also explained the cardinalities and connectivities of relationships as 1:M, 1:1 and M:N. We explained the relationship participation constraints. We also looked at indexing and its role in locating database entries. In lesson 6, particularly, we studied the relational algebra operators which guided our understanding of SQL discussed in lessons 12 and 13.

13.4 Information Systems Data can be defined as basic, raw, unprocessed or unorganized facts. Processing data by defining relationships between them and organizing them coherently produces information. A system is a collection of elements or components that interact to achieve goals. An information system is a set of interrelated components that collect, manipulate, store data and disseminate information and provide a feedback mechanism to monitor performance.

A Computer-Based Information System (CBIS) is an Information System composed of Hardware, Software, databases, telecommunication, network, people and procedures. Information Systems are realized through a set of processes; system development, system investigation and analysis, system design, system implementation, system maintenance and review.

ITQ

Question

.What is a system?

Feedback

.A system is a collection of elements or components that interact to achieve goals.

13.5 Computer Aided Software Engineering Computer Aided Software Engineering (CASE) are the software tools that provide automated support for some portion of the systems development process. Depending on the particular one, CASE provides

Study Session 13REVISION

97

several components, some of which include diagramming facilities, a central repository of system information, error checking facilities, user interface generators, code generators, documentation generators etc.

In lessons 10 and 11, we studied UML and DFDs being important CASE diagramming tools for Information Systems design. UML is an industry-standard, general purpose visual modelling language for specifying, visualizing, constructing, and documenting the artefacts of software systems. UML diagrams are classified into the structural and behavioural diagrams. Structural diagrams are used to model the static structure of a system while behavioural diagrams are used to capture the behaviour of the system.

A DFD is a graphical model representing the flow of data within the system. DFD does not reveal the processing logic within the system. DFD has four (4) major symbol notations, entity, process, data store and data flow.

ITQ

Question

.What is a DFD?

Feedback

.A DFD is a graphical model representing the flow of data within the system. DFD does not reveal the processing logic within the system.

13.6Concepts in Multi-User Databases In lesson 12, we studied two basic issues in multi-user databases namely, transaction management and database recovery.

A transaction is a sequence of database actions or a logical unit of work that can either be entirely completed or aborted. The properties of a transaction are Atomicity, Consistency, Isolation, Durability and Serializability.

Database recovery deals with returning the database to its consistent state after a failure. Database transaction recovery uses deferred-write and write-through techniques to recover the database in the event of transaction failures.

Post-Test

Refer to the post-test questions under each lesson.

98



Summary

In this Study Session,

Assessment

Assessment


Define and differentiate a file system and database system


Mention the data models


What does the Relational model represent?

SAQ 13.4 (tests Learning Outcome 13.4) What is an Information system?

SAQ 13.5 (tests Learning Outcome 13.5) What is CASE?

SAQ 13.6 (tests Learning Outcome 13.6) What are the two basic issues under the multi-user databases?

Bibliography

Reading

Notes on Self Assessment Questions

99


SAQ 1.1

Data is defined as raw or unprocessed fact, while Information is the result of processing data. Processing could involve several activities such grouping, extraction and summarization of the unprocessed fact (data).

SAQ 1.2

File System refers to a data storage mechanism which stores data in files organized in a tree-like (hierarchical) structure. Therefore, to access a file, we must first access its parent file and the deletion of a file implies the deletion of all its child files.

SAQ 1.3

Database Management System (DBMS) is the software that manages database systems.

Some functions of the DBMS include

1. The management of data storage is one of the responsibilities of the DBMS. This is to ensure that data is efficiently stored for easy retrieval. This is achieved through the data dictionary in which the DBMS stores details of data and their relationships.

2. The DBMS facilitates data retrieval and report generation by transformation and presentation of data it in appropriate formats.

3. The DBMS ensures security of data by allowing user access permissions to be specified so that different classes of user are

100


allowed authorized access to different portions of data, hence denying unauthorized user access.

4. The DBMS is also responsible for concurrent user access to data. 5. In case of system failures and crashes, the DBMS ensures that

data is not lost by promptly backing up data for system recovery purposes.

6. The DBMS helps manage data integrity by specifying constraint and rules guiding operations on data (insertion, deletion, updates, retrieval etc.).

7. The DBMS also provides a database access language known as Structured Query Language (SQL) for accessing data in the database and Application Programming Interfaces (API) for application programs to interact with the database.

SAQ 2.1

Data modeling, the first step in designing a database, refers to the process of creating a specific data model for a determined problem domain. (A problem domain is a clearly defined area within the real-world environment, with well-defined scope and boundaries to be systematically addressed). Database design focuses on how the database structure will be used to store and manage end-user data.

Data modeling is an iteratively progressive process. It starts with a simple understanding of the problem domain, and as your understanding of the problem domain increases, so does the level of detail provided in the data model. Eventually, the final data model is in effect a “blueprint” containing all the instructions to build a database that will meet end-user requirements. This blueprint is narrative and graphical in nature, meaning that it contains both text descriptions in plain, unambiguous language and clear, useful diagrams depicting the main data elements. Data models are essentially important in facilitating the interaction between the database designer, the application designer and the end user by presenting a blueprint that harmonizes their different views with different levels of abstraction.

SAQ 2.2

The basic building blocks of data models are entities, attributes, relationships and constraints.

Entity: An entity is any real-world object or concept about which data are to be collected and stored. Entities are unique and distinguishable and should be modelled as such. An example of an entity is a STUDENT and instances of this entity may include Shola Bamidele, Ogbaji Amaka, Idris Patrick etc. While entities may be concrete objects such as employees, clients, products etc, they could also be abstract concepts such as Sales, Flight Schedule, Course Registration etc.

Attribute: An attribute is a characteristic of an entity. They could be likened to fields of a record in a file. The entity student for instance would have attributes such as SURNAME, FIRST


101

NAME and MATRIC NUMBER. Some of these attributes are expected to be unique while others need not be.

Relationship: This is the association between entities. There are different types of relationships based on the number of participating entity instances in the relationship. Relationships are bi-directional, so, to discover the type of a relationship, we must read it from both entities involved.

Constraint: A constraint is a restriction placed on data. Constraints are important for enforcing data integrity in databases. For instance, a constraint could state that a students’ CGPA must be between 0.0 and 8.0 or the age of an employee should be between 20 years and 65 years.

SAQ 2.3

In Database Design, designers might need to gain a thorough understanding of what types of data are in an organization, how the data are used, and in what time frames they are used in order to build a sound data model. However, such data and information do not, by themselves, yield the required understanding of the total business. From a database point of view, the collection of data becomes meaningful only when it reflects properly defined business rules. A business rule is a brief, precise, and unambiguous description of a policy, procedure, or principle within a specific organization.

Business rules, derived from a detailed description of an organization’s operations, help create and enforce actions within that organization’s environment. Properly written business rules are used to define entities, attributes, relationships, and constraints which are in turn used to build data models in database design. They could be written like “an agent can serve many customers, and each customer can be served by only one agent”.

Business rules can be obtained from company managers, policy makers, department managers, written documentation, procedures, standards, operations manuals and through direct interviews with end users.

SAQ 2.4

The American National Standards Institute (ANSI) Standards Planning and Requirements Committee (SPARC) in the early 1970s defined a framework for data modeling based on degrees of data abstraction as follows The External Model, The Conceptual Model and The Internal Model (note that the models are arranged in decreasing order of abstraction). Therefore data models can be classified into:

The External Model

The external view provides the End users’ view of the data environment i.e. the view that an average end user will have of the data in the database. A data model called Entity-Relationship (ER) diagram is used to represent external views. A specific representation of an external view is called an external schema.

102


The Conceptual Model

This model brings together all external views and integrate them into a single global view known as the conceptual schema. The ER model is most widely used for this model using.

The Internal Model

This is a representation of the database as “seen” by the DBMS. It maps the conceptual model to the DBMS. Internal schema depicts a specific representation of an internal model. The Internal model depends on the specific database software, therefore a change in DBMS software requires that the internal model be changed. The Internal model is hardware-independent in that a change in the computer hardware does not affect it and it could be logically independent i.e. a change in the internal model could be made without affecting the conceptual model.

SAQ 3.1

The types of data models available for database design. These data models are principally categorized based on their structure and their concept (logic) of representing the data model building blocks.

These data models are explained below:

Hierarchical Data Model: The hierarchical model was developed in the 1960s to manage large amounts of data for manufacturing projects. The basic logical structure of the hierarchical model is represented by an upside-down “tree”. This hierarchical structure contains levels or segments. Each segment is analogous to a record type and there is a set of one-to-many relationships between segments.

Network Data Model: The network model was created to represent complex data relationships more effectively than the hierarchical model. Hence, it improves database performance by imposing a database standard. The Network model is essentially a collection of records in 1:M relationships with each set composed of two record types:

An Owner record(s) which is equivalent to the hierarchical model’s parent record

A Member record(s) which is equivalent to the hierarchical model’s child record.

Although the network model is no longer in use today, it defined some concepts which are still in use today in the database community. Some of these are

Schema: The conceptual organization of an entire database as viewed by the database administrator.

Subschema: The database portion “seen” by application programs.

Data management language (DML): This defines the environment in which data can be managed

Data definition language (DDL): This enables the administrator to define the schema components.


103

Some of the reasons for the discontinued use of this model are the fact that it’s cumbersome in structure and it lacks ad hoc query capabilities which placed burden on programmers to generate code for reports. The network model was also known to be prone to havocs in all application programs due to structural changes in the database.

Relational Model: The Relational model was developed by E.F. Codd (IBM) in 1970.

The relational model represents entities as Tables called relations. A table is basically a matrix consisting of row/column intersections. Each row in a relation is called a tuple (representing an entity instance). Relational models were considered impractical in 1970 because the model was conceptually too simple at the expense of computer overhead. However, its conceptual simplicity set the stage for a database revolution.

Entity-Relationship Model: The Entity-Relationship model, introduced by Chen in 1976 was widely accepted standard for data modeling. Entity relationship diagram (ERD) uses graphical representations to model database components.

An entity is mapped to a relational table. An entity instance (or occurrence) corresponds to a row (tuple) in a relational table. An entity set is a collection of similar entities. The connectivity in a relationship indicates the type of the relationship. ERD have two basic notations – the Chen notation and the Crow’s foot notation

In Chen notation:

Entities are represented by a rectangle with their attributes in ovals around them

Relationships are represented by a diamond with the relationship name written in the diamond

Crow’s Foot notation:

Entities are represented by a rectangle with their attributes listed within the rectangle

Relationships are represented by a straight line (which could be dashed or solid depending on the participation constraints). The name of the relationship is written on the line

Relationship types are usually by the type of symbol at the end of the relationship lines as shown in figure 3.4.

Object-Oriented Model: In the Object-Oriented data model, data and relationships are contained in a single structure known as an object. OODM (object-oriented data model) is the basis for OODBMS. An object contains operations, is self-contained and is an abstraction of a real-world entity.

Modern Data Models: Some newer data models which are increasingly being used in modern DBMS includes the Extended relational data model (ERDM) which is a semantic data model developed in response to increasing complexity of applications. It includes many of Object-Oriented model’s best features and is often described as an object/relational database management system (O/RDBMS). It is primarily geared towards business applications.

104


The use of complex objects received a boost with the Internet revolution. When organizations integrated their business models with the Internet, they realized the potential of the Internet to access, distribute, and exchange critical business information and this resulted in the widespread adoption of the Internet as a business communication tool. It is in this environment that Extensible Markup Language (XML) emerged as the de facto standard for the efficient and effective exchange of structured, semistructured, and unstructured data. In order to manage the large amounts of data generated in this complex formats, XML databases emerged to manage unstructured data within a native XML format.

SAQ 4.1

The basic concepts includes:

Data which are represented by collections of records and is similar to an entity in the E-R model. Records and their fields are represented as record type.

SAQ 4.2 (tests Learning Outcome 4.2) What is a DS diagram and how do they correspond with the ER diagrams?

SAQ 4.2

Data-Structure(DS) diagrams are the schema representing the design of a network database. A data-structure diagram consists of two basic components; boxes correspond to record types and lines correspond to links. Data-Structure Diagrams specify the overall logical structure of the database.

We will now go on to show the correspondences between D-S and E-R diagrams. For every E-R diagram, there is corresponding D-S diagram.


105

SAQ 5.1

The relational data model however changed all of that by allowing the designer to focus on the logical representation of the data and its relationships, rather than on the physical storage details. The relational model enables you to view data logically rather than physically and is much easier to understand than the hierarchical and network models.

Logical simplicity tends to yield simple and effective database design methodologies and the table plays a very important role in the relational model. Therefore, our discussion begins with an exploration of the details of table structure and contents.

The logical view of a relational database is based on relations. A relation is thought of as a table. A Table as a two-dimensional structure composed of rows (records or entity instances a.k.a. tuples) and columns (attributes or fields). It is essentially a group of related entities (entity set).

SAQ 5.2

Key is one or more attributes that determine other attributes. Determination in database term means “if you know the value of attribute A, you can determine the value of attribute B”. Thus, if we know your matric number, we can know your name and your score in CIS307. Each row in a table must be uniquely identifiable and this necessitates the selection of one or more of the table attributes as the key attribute.

The principle of determination is very important because it is used in the definition of a central relational database concept known as functional dependence. The term functional dependence can be defined most easily this way: the attribute B is functionally dependent on A if A determines B. More precisely:

106


The attribute B is functionally dependent on the attribute A if each value in column A determines one and only one value in column B.

Below are some definitions pertaining to keys:

A Composite key is composed of more than one attribute. A Key attribute is any attribute that is part of a key A Superkey is any key that uniquely identifies each row A Candidate key is a superkey without unnecessary attributes A Primary key (PK) is a candidate key chosen to uniquely

identify every row in a relation (or to uniquely determine every other attribute in any given row).

A Secondary key is an attribute or a set of attributes which may not necessarily uniquely identify a row but are used strictly for data retrieval purposes.

A Foreign key (FK) is an attribute whose value matches primary key values in a related table. Foreign keys are used to enforce database referential integrity. A FK contains a value that refers to an existing valid row in another table/relation.

Keys should not be null. A Null means no data entry for a particular attribute or field. This is not the same as entering a blank or space because a blank/space is itself a character. As much as possible, nulls should be avoided in other attributes, while they must not be allowed in primary keys.

Relational databases employ what is called Controlled redundancy through the use of keys to create relationships between tables. Foreign keys are used by relational databases to control data redundancies, by using common attributes shared by tables, and is crucial to exercising data redundancy control.

SAQ 5.3

Integrity rules are meant to ensure data integrity in the database. Many RDBMs enforce integrity rules automatically, however, it is safer to ensure that your design conforms to entity and referential integrity rules.

SAQ 6.1

1:M Relationship: This is the ideal relationship in Relational data modeling and should be the norm in any relational database design. This is easily implemented in a relational database by placing the primary key of the relation on the one side in the relation on the many side.

1:1 Relationship: This should be rare in any relational database design. Sometimes, it means that the entity components were not defined properly. It could indicate that the two entities should actually belong to the same table.

M:N relationships: This cannot really be implemented in a the relational model without resolving it to a set of 1:M relationships. You should avoid problems inherent to M:N relationships by creating a composite entity (associative entity) which serves as a


107

bridge in the relationship. The composite entity includes as foreign, keys the primary keys of tables to be linked (i.e. the tables involved in the relationship).

SAQ 6.2

The essence of database indexing is to be able to quickly retrieve needed information from the database due to the volume of data in the database. This is achieved using indexes. An index is an orderly arrangement to logically access rows in a table. An index key is the index’s reference point which points to the data location identified by the key. A unique index is the index in which the index key can have only one pointer value (row) associated with it. Each index is associated with only one table.

SAQ 6.3

A Data dictionary provides detailed accounting of all tables and relationships found within the user/designer-created database. It contains (at least) all the attribute names and characteristics for each table in the system – it contains metadata i.e. data about data.

Like the data dictionary, a System catalog contains metadata. However, it contains more details than the data dictionary. It is a detailed system data dictionary that describes all objects within the database.

Because the system catalog contains all required data dictionary information, the terms system catalog and data dictionary are often used interchangeably. In fact, current relational database software generally provides only a system catalog, from which the designer’s data dictionary information may be derived.

SAQ 7.1

Relational Algebra defines a theoretical way of manipulating table contents using relational. When relational algebra operators are used on existing relations new relations are produced; this property of the operators is referred to as closure.

SAQ 7.2

1. SELECT: also known as RESTRICT, yields values for all rows found in a table that satisfy a given condition. SELECT can be used to list all of the row values, or it can yield only those row values that match a specified criterion. In other words, SELECT yields a horizontal subset of a table.

2. PROJECT: It yields all values for selected attributes. In other words, PROJECT yields a vertical subset of a table.

3. UNION: UNION combines all rows from two tables, excluding duplicate rows. The tables must have the same attribute characteristics (the columns and domains must be compatible) to be used in the UNION. When two or more tables share the same number of columns, and when their corresponding columns share

108


the same (or compatible) domains, they are said to be union-compatible.

4. INTERSECT: INTERSECT yields only the rows that appear in both tables. As was true in the case of UNION, the tables must be union-compatible to yield valid results. For example, you cannot use INTERSECT if one of the attributes is numeric and one is character-based.

5. PRODUCT: PRODUCT yields all possible pairs of rows from two tables—also known as the Cartesian product. Therefore, if one table has six rows and the other table has three rows, the PRODUCT yields a list composed of 6 × 3 = 18 rows.

6. DIVIDE: The DIVIDE operation uses one single-column table (e.g., column “a”) as the divisor and one 2-column table (i.e., columns “a” and “b”) as the dividend. The tables must have a common column (e.g., column “a”). The output of the DIVIDE operation is a single column with the values of column “a” from the dividend table rows where the value of the common column (i.e., column “a”) in both tables matches.

7. JOIN: JOIN allows information to be combined from two or more tables. JOIN is the real power behind the relational database, allowing the use of independent tables linked by common attributes. There are several types of joins:

NaturalJoin links tables by selecting rows with common values in common attribute(s).

Equijoin links tables on the basis of an equality condition that compares specified columns.

Usually, the equality operator (=) is used in the equijoin and this informs its name. If any other comparison operator is used, it is called a Theta join.

All the several types of joins could either be classified as Inner join or Outerjoin. An inner join is a join that only returns matched records from the tables that are being joined. In an outer join, the matched pairs would be retained, and any unmatched values in the

SAQ 8.1

Data can be defined as basic, raw, unprocessed or unorganized facts. Processing data by defining relationships between them and organizing them coherently produces information. While Information can be defined as a collection of facts organized in such a way that they have additional value beyond the value of the facts themselves.

Data is also defined as distinct pieces of information, usually formatted in a special way.

Data can exist in a variety of forms – as numbers or text on pieces of paper, as bits and bytes stored in electronic memory, or as facts stored in a person's mind. Actually, data is the plural of datum; a single piece or item of data, but many people often use the term data as both singular and plural.


109

For any piece of information to be regarded as valuable, it should be accurate, complete, economical, flexible, reliable, relevant, simple, timely, verifiable, accessible and secure.

An information can be said to be a transformed data having the qualities of a valuable information

SAQ 8.2

A system is a collection of elements or components that interact to achieve goals. For instance, a computer system includes both hardware and software.

Important elements of a system are its input, processing and output components/elements.

SAQ 8.3

An information system is a set of interrelated components that collect, manipulate, store data and disseminate information and provide a feedback mechanism to monitor performance. It can also be described as an organized combination of people, hardware, software, communications networks, and other resources for collecting data and transforming it, and disseminating information.

Like any other system, an Information System is composed of input, processing, output elements and in addition a feedback component. Input refers to the activity of gathering and capturing data, processing refers to the activity of converting or transforming data into useful outputs while output refers to useful information, usually in the form of documents and/or reports.

The feedback component is an important component of an Information System. It is simply output fed back into the input or processing components/stages of the system in order to enhance those stages and consequently improve future outputs. Forecasting is a proactive feedback approach used to predict or estimate future outputs.

SAQ 8.4

A Computer-Based Information System (CBIS) is an Information System composed of Hardware, Software, databases, telecommunication, network, people and procedures. These components are configured so that they can interact to collect, store, and process data to produce meaningful information.

Hardware refers to objects that you can actually touch, like disks, disk drives, display screens, keyboards, printers, boards, and chips. In contrast, software is untouchable. Software exists as ideas, concepts, and symbols, but it has no substance. Software is computer instructions or data. Anything that can be stored electronically is software. The storage devices and display devices are hardware.

110


A database is a collection of information organized in such a way

that a computer program can quickly select desired pieces of data. You can think of a database as an electronic filing system. Traditional databases are organized by fields, records, and files. A field is a single piece of information; a record is one complete set of fields; and a file is a collection of records. To access information from a database, you need a database management system (DBMS). This is a collection of programs that enables you to enter, organize, and select data in a database.

Telecommunications refer to the electronic transmission of signals for communications. It enables organizations to link computer systems into effective networks. Telecommunication involves all types of data transmission, from voice to video.

Networks refer to the connection of computers and other electronic devices in order to enable electronic communication. Networks could range from covering small areas such as a room to covering wide areas such as an entire country or the whole world.

The most important element in most CBIS is the people. This Includes people who manage, run, program, and maintain the system e.g., IT professionals.

Procedures Includes the strategies, policies, methods, and rules for using the CBIS.

SAQ 8.5

Processes involved in realizing IS include:

Systems development is the activity of creating or modifying an existing business system.

Systems investigation and analysis defines the problems and opportunities of an existing system.

Systems design determine how a new system will work to meet business needs.

Systems implementation is the process of creating and acquiring system components as defined in the design.

Systems maintenance and review checks and modifies the system so that it continues to meet changing business needs.

SAQ 9.1

Computer Aided Software Engineering (CASE) are the software tools that provide automated support for some portion of the systems development process. It is an abstraction based methodology based on diagrams (pictures). CASE can be used to model any system.

Why Do We Use CASE

TEAM: Teams share system development tasks based on the size of the development team, the size and scope of the project, the skill & experience of the team etc.

Documentation used for communication.


111

STRUCTURED METHODOLOGIES: used to document all systems to a universally accepted defined standards.

Structured Methodology tool of interest : Depending on the CASE tool, the system development activities

covered may include: project identification and selection, project initiation and planning, analysis, design, implementation and maintenance.

Objectives of CASE

To improve quality of developed systems To increase speed of systems development To improve testing process through automatic checking To integrate development activities (common methods) To improve documentation (quality and completeness)

SAQ 9.2

diagramming facilities user interface generators code generators project management aids documentation generators

SAQ 9.3

The functions of CASE diagramming tools includes:

checks for syntactic correctness consistency & completeness checks navigation to linked diagrams data dictionary support layering of system components traceability of requirements report generation system simulation/performance analysis (models)

SAQ 9.4

A repository is a centralised database containing all models (diagrams), data dictionary entries, form & report definitions and system & organisational information. It holds complete information needed to develop a system from initiation to maintenance. It helps supports team Information System development.

SAQ 9.5

Automation of tedious tasks Syntax/completeness checks ensure consistency Amending/updating achieved far more easily documentation can be kept up-to-date

112


beneficial effect on maintenance More rapid development more feasible to develop & evaluate alternative designs an aid to prototyping Capture of system data for reuse Reduction in defects increases morale.

SAQ 9.6

Limited flexibility in documentation. Standards may not suit organisation or project needs

Development approach limited to fit capabilities of the CASE tool: May not adhere to industry or organisational standards.

Training and experience required Front loaded cost of installation of CASE tool & training benefits may outweigh initial costs

SAQ 10.1

UML stands for “Unified Modelling Language”. It is an industry-standard, general purpose visual modelling language for specifying, visualizing, constructing, and documenting the artefacts of software systems. UML is used to understand, design, browse, configure, maintain and control information about systems. It simplifies the process of System Design.

UML includes semantic concepts, notations, and guidelines. It has static, dynamic, environmental, and organizational parts. It was motivated by and is intended to support most object-oriented development processes.

It is a general purpose language unified across application domains, historic notations, development lifecycle etc. UML helps define systems to standard and simplifies system design as it concisely captures several object-oriented development concepts.

SAQ 10.2

UML Diagrams are classified into:

Structural and; Behavioural diagrams

Structural Diagrams are used to model the static structure of a system. They are used to represent the physical entities and components of the system and also model relationships, associations and dependencies between these elements.

Behavioural Diagrams model the behaviour of the system. They capture the interaction between system elements and also represent the instantaneous states as well as state changes in the system.

SAQ 10.3


113

Modifiers are used to indicate visibility of attributes and operations. Examples of modifiers are:

‘+’ is used to denote Public visibility (everyone has access) ‘#’ is used to denote Protected visibility (friends and derived

classes have access) ‘-’ is used to denote Private visibility (no one has access to this

except itself) ‘~’ is used to denote Package visibility (classes within the same

package have access).

SAQ 10.4

The following are the components of a use case diagram:

Actors: A role that a user plays with respect to the system including human users and other systems, e.g. inanimate physical objects (e.g. robot); an external system that needs some information from the current system.

Use case: A set of scenarios that describes an interaction between a user and a system, including alternatives.

System boundary: A rectangle diagram representing the boundary between the actors and the system.

Association: Indicates communication between an actor and a use case. It is represented by a solid line with an optional hollow arrowhead. Associations may also include multiplicity to indicate the number of actors that can take an action per time.

Generalization: Indicates relationship between one general use case and a special use case (used for defining special alternatives). It is represented by a line with a triangular arrow head toward the parent use case.

Include: a dotted line labeled «include» beginning at base use case and ending with an arrow pointing to the include use case. The “include” relationship occurs when a chunk of behavior is similar across more than one use case. Use “include” instead of copying the description of that behavior.

Extend: a dotted line labeled «extend» with an arrow toward the base case. The extending use case may add behavior to the base use case. The base case declares “extension points”.

SAQ 11.1

A DFD is a Data Flow Diagram that shows how data moves through an information system but does not show the logic or processing steps within the system. A set of DFDs provides a logical model that shows what the system does, but not how it does it.

DFDs use four basic symbols that represent processes, data flows, data stores, and entities. There are several different versions of DFD symbols, but they all serve the same purpose. We have the Gane and Sarson symbol set of DFD. Another popular notation is the Yourdon symbol set.

114


Many business processes can be so complex that E-R design alone will not give system analysts insight into their businesses. DFDs are the link between initial business analysis, E-R diagrams and relational database models.

SAQ 11.2

In creating a DFD, the following terms should be noted:

Entities: External entities represent persons, processes or machines which produce data to be used by the system or receive data that is output by the system. Examples include Student, Customer and Client.

Processes: Processes are discrete actions that transform input data to output data. Examples include Create Student Record, Calculate Purchase Cost and Register Client.

Data Stores: Data stores are temporary or permanent repositories of information that are inputs to or outputs of processes. Examples: Student Master, Client List.

Data Flows: Data flows represent the transfer of data over time from one “place” (entity, process, data store) to another. An example is seen in a New Student Information (from Student, to Student Master).

System: A system is the collection of all business processes which perform tasks or produce outputs we care about. The system is a single process, connected to external entities and it is represented in a “Context Diagram”.

Subsystems: A subsystem gives a more detailed view of the individual processes contained in the context diagram. It includes data stores, more elementary processes etc.

The DFD creation process begins from an entity to a process which are then stored permanently or temporarily, the process from an entity to “process” is the data flow. The flow is therefore a to and fro process between the entities, processes and data stores.

SAQ 12.1

A successful transaction is depicted by changes in the database from one consistent state to another – one in which all data integrity constraints are satisfied.

SAQ 12.2

The ACIDS properties of a database transaction is an acronym explained below:

Atomic: Either all actions are carried out or none are. We need not worry about incomplete transactions.

Consistency: DBMS assumes that the consistency holds for each transaction. Consistency defines the permanence of a database’s consistent state.


115

Isolation: Data used during a transaction cannot be used by a second transaction until the first is completed.

Durability: The effects of transaction persists if DBMS informs the user successful execution. Once transactions are committed, they cannot be undone.

Serializability: The concurrent execution of several transactions yields consistent results.

SAQ 12.3

According to the American National Standards Institute (ANSI), transaction support in any DBMS is provided by two SQL statements: COMMIT and ROLLBACK. The sequence of every transaction must continue until

COMMIT statement is reached OR ROLLBACK statement is reached OR End of program is reached OR Program is abnormally terminated

SAQ 12.4

Transaction recovery majorly employs the Deferred-write technique and write-through technique to ensure that the database’s consistent state is recovered after transaction failures.

In Deferred-write technique, only the transaction log is updated. The recovery process is as follows:

identify the last checkpoint If transaction committed before checkpoint Do nothing If transaction committed after checkpoint Use transaction log to redo the transaction If transaction had ROLLBACK operation Do nothing

In Write-through technique the database is immediately updated by transaction operations during transaction’s execution. The recovery process is as follows:

identify the last checkpoint If transaction committed before checkpoint Do nothing If transaction committed after last checkpoint DBMS redoes the transaction using “after” values If transaction had ROLLBACK or was left active Do nothing because no updates were made

SAQ 13.1

116


The file system stores records in a hierarchical tree-like structure and often requires extensive programming especially in the case of updates, insertions or deletions. Databases help store data in a compact structure which facilitates the management and retrieval of data. Some of the advantages of databases over file system include Data Independence, No data redundancy, Structural Independence, reduced application development time and the availability data modelling and design.

SAQ 13.2

Some of the data models includes the hierarchical model, the network model, the relational model, the entity-relationship model, the object-oriented model and the object-relational or extended relational model.

SAQ 13.3

The Relational Model represents entities as Tables called relations.

SAQ 13.4

An information system is a set of interrelated components that collect, manipulate, store data and disseminate information and provide a feedback mechanism to monitor performance.

Information Systems are realized through a set of processes; system development, system investigation and analysis, system design, system implementation, system maintenance and review.

SAQ 13.5

Computer Aided Software Engineering (CASE) are the software tools that provide automated support for some portion of the systems development process. Depending on the particular one, CASE provides several components, some of which include diagramming facilities, a central repository of system information, error checking facilities, user interface generators, code generators, documentation generators etc.

SAQ 13.6

The two basic issues in multi-user databases includes: transaction management and database recovery.

A transaction is a sequence of database actions or a logical unit of work that can either be entirely completed or aborted. Database recovery deals with returning the database to its consistent state after a failure. Database transaction recovery uses deferred-write and write-through techniques to recover the database in the event of transaction failures.

References

117

References …

Introduction to Database Systems - Distance Learning...

Documents

Transcript of Introduction to Database Systems - Distance Learning...