Designing Information Systems

Study Support

Doc. Ing. Ivo Špička, Ph.D.

Ostrava 2015

VYSOKÁ ŠKOLA BÁŇSKÁ – TECHNICKÁ UNIVERZITA OSTRAVA

FAKULTA METALURGIE A

MATERIÁLOVÉHO INŽENÝRSTVÍ

TABLE OF CONTENTS

1.1 System as a general and a technical term ................................................................................ 6

1.1.1 Relation of the system to the environment. ........................................................................ 7

1.1.2 Purposefulness and objectiveness of the system ................................................................ 7

1.2 The development of information technology in the commercial sector ................................... 7

1.2.1 Mainframe batch processing ............................................................................................... 7

1.2.2 Central database systems .................................................................................................... 7

1.3 The advent of the PCs ............................................................................................................... 8

1.4 Network Link ............................................................................................................................. 8

1.5 Concept client / server .............................................................................................................. 8

1.6 The concept thin client/server .................................................................................................. 8

1.7 The recent development of ultra-thin clients ............................................................................ 8

1.7.1 Cloud computing .................................................................................................................. 9

2 OPERATOR PANELS AND PROGRAMMING ................................................................................. 11

2.1.1 Brief description of the MDIS methodology ...................................................................... 11

3.1 Characteristics approaches to the creation of an information system by the company LBMS15

3.2 General principles of analysis and IS design ........................................................................... 16

3.2.1 Types of approaches to the analysis and design of IS ........................................................ 19

4 Types of IS development methodologies and current trends ..................................................... 23

4.1 Types of methodologies .......................................................................................................... 23

4.1.1 State-supported methodologies ........................................................................................ 23

4.1.2 international methodologies ............................................................................................. 23

4.1.3 corporate methodologies .................................................................................................. 24

4.2 Current trends in the evolution and development methodologies. ........................................ 24

4.2.1 Using iterative procedures ................................................................................................. 24

4.2.2 Penetration of object methods, techniques, and tools ..................................................... 24

4.2.3 “Globalization” of the analysis concept ............................................................................. 24

4.2.4 The shift from “hard” to “soft” methods ........................................................................... 24

4.3 The application of methodologies for the implementation of the standard application software (TASW) 25

4.3.1 The emergence and development of so-called agile methodologies ................................ 25

4.4 Agile methodologies of IS development ................................................................................. 25

4.4.1 Incremental (iterative) development of IS with very short iterations ............................... 25

4.4.2 Rigorous automated software testing ............................................................................... 25

4.5 Examples of agile methodologies ........................................................................................... 26

4.5.1 ASD - Adaptive software development .............................................................................. 26

4.5.2 FDD- Feature-Driven development .................................................................................... 26

4.6 XP - Extreme programming .................................................................................................... 27

4.7 Crystal methodologies ............................................................................................................ 27

5 Functional models of information systems ................................................................................ 30

5.1 A structured approach ............................................................................................................ 30

5.1.1 Conceptual level of models, the first layer ........................................................................ 31

5.1.2 Technologic (logic) level of models, the second layer ....................................................... 31

5.1.3 Implementation (physical) level of models, the third layer ............................................... 31

5.2 The context diagram ............................................................................................................... 31

5.3 List of events ........................................................................................................................... 33

5.4 Diagram of the functional structure of the system ................................................................. 34

5.5 Data flow diagram .................................................................................................................. 34

Conceptual level of models, the first layer ..................................................................................... 37

Technologic (logic) level of models, the second layer .................................................................... 37

Implementation (physical) level of models, the third layer ........................................................... 37

6 Data Model ................................................................................................................................ 39

6.1.1 The concept of entity. ........................................................................................................ 40

6.2 Normal forms in the data model ............................................................................................ 42

6.3 Data Integrity ......................................................................................................................... 42

6.4 Data dictionary ....................................................................................................................... 43

6.5 State Transition Diagram ........................................................................................................ 43

7 Data ModelLING ........................................................................................................................ 48

7.1 Fundamentals of creating data models .................................................................................. 48

7.2 Normalization of data model .................................................................................................. 49

The author of the learning material wishes you successful and enjoyable study with this textbook

Doc. Ing. Ivo Špička, Ph.D.

THE BASIC CONCEPTS OF THE SYSTEM THEORY AND THE

SYSTEM ANALYSIS

Study time

40 minutes

Objective

After reading this chapter and elaborating the tasks, you will BE ABLE TO:

understand the importance and significance of computer communication networks in the area of

information systems and the direction of their development;

analyse the trends in information and communication technologies

After reading this chapter and elaborating the tasks, you will ACQUIRE:

knowledge base system in the area of systems engineering

knowledge of the development of information systems and trends in their development

Information on the cloud computing

After reading this chapter and elaborating the tasks, you will BE ABLE TO:

connect the significance of computer networks and the importance of the meaning and function of

the information system

Lecture

Information systems currently symbolize applications called ERP (Enterprises Resource Planning). Their

development in the world and in our country began in the early nineties. Two other major technologies greatly

contributed to the development of the existing business information systems. In 1991, the Internet was made

available for the first time in the Czech Republic. Even earlier, thirty years ago, the personal computer began to be

used, which was another important milestone in business informatics.

Compared with the life of an individual, thirty years is not a long period. At this time, Information and

Communication Technology (ICT) has prevailed:

• information systems have been significantly reflected in the everyday life of businesses and

individuals,

• information systems affected individuals and society,

• information systems acquired their internal “order” and the terminology and

• the area of information systems has shown its limits and possible risks.

Development of information systems (IS) in companies have resulted in changes within the manufacturing

and non-manufacturing technologies and services. The practices and attitudes of people have changed, and changes

have affected all critical business processes and the entire enterprise (business) models. These changes and their

management are dealt with by business informatics. This discipline has become one of essential business disciplines,

together with marketing, accounting, human resources, logistics, and other.

The development of corporate IS can be viewed from different perspectives:

• changing functionality,

• trends in implementation,

• operation and

• expected benefits.

Changes can be described by the acronym ERP (Enterprise Resource Planning). Initially, the emphasis was on

planning (P - Planning), afterwards, the attention was focused on all the company's resources (R - resources), i.e.

mainly material, capacities, and finances. At present, the focus is on the enterprise (E - enterprise, in the broad

sense) and business, especially on efficiency, maintaining and developing the company's competitiveness. However,

we view a company as cooperative and concatenated across networks, a company open to partners and locatable in

any part of the globalized world through information systems.

“Business” benefits of IS company applications are becoming dominant. Thus integrated and optimized

business processes make it possible to reduce costs and support revenues from sales of new, or innovative products

and services. “Life cycle” of company IS does not end with its symbolic commissioning, but continues by means of its

effective operation, maintenance and further development and re-innovation.

Changes and development of information systems in enterprises (particularly small and medium enterprises)

are currently supported, among others, from the funds of the development operational programs earmarked for the

Czech Republic from the EU funds for 2007-2013. (Basl, et al, 2007) explanation.

1.1 SYSTEM AS A GENERAL AND A TECHNICAL TERM

Working with complex and extensive facilities, which include information systems, requires systemic

approach. An information system in an enterprise must be understood not as an isolated independent part of the

whole, but it must be understood comprehensively with all connections and ties in its dynamic development.

1.1.1 Relation of the system to the environment.

Each system exists in a particular environment that surrounds it. When analysing the system, we choose only

those elements from its environment that have significant links to the examined system. Links of the elements of the

environment to the system are called inputs and outputs of the system. The elements of the system linking the

system to its environment are called boundary (limit) elements. The environment affects the system through its

inputs, and vice versa, the system influences its surroundings by its otputs

1.1.2 Purposefulness and objectiveness of the system

If not specified, the purpose for which the system is introduced (this applies quite generally), the criteria for

defining the system are missing. The definition of the system itself emphasizes purposefulness. Using the system for

any purpose other than that for which it was defined (intended), we commit gross errors.

Purposefulness is given (Burý, 2007):

1. in what terms the system is examined.

2. what level of detail is chosen for examination.

The issue of the system objectives is closely related to the selection of suitable distinctive level. If it increases

(more distinctive level), the elements of the system can become

systems themselves. Conversely, if the distinctive level is decreased, the entire system may become part of the

system defined at a less detailed level of resolution.

1.2 THE DEVELOPMENT OF INFORMATION TECHNOLOGY IN THE COMMERCIAL SECTOR

Except in special cases, such as scientific and military applications, which had somewhat different conditions

for the deployment of information technology, the application of information technology in the commercial sector

started approximately in the following steps.

1.2.1 Mainframe batch processing

Large volumes of data are processed in batches by massive (in relation to performance and size) mainframe

computers. They solved the tasks of stock records, statistics, accounting, or other complex calculations. Within the

stipulated deadlines, users handed over materials for processing, and after some time, they received the results in

the form of printed output – i.e. print reports. Dissemination of results of such processing was allowed only in the

form of dissemination of copies of the printed output. It often happened that even relatively well-prepared sets had

a serious shortcoming - almost nobody used them.

1.2.2 Central database systems

In the following years, there was a boom of information technology and the expansion of database software

and transaction processing. The core technology has become centrally maintained database systems which allowed

simultaneous access to the system by multiple users (e.g. air ticket booking system). Text-based specialized terminals

operated by trained staff started to be used for communication.

IBM.

1.3 THE ADVENT OF THE PCS

The era of personal computers - PCs - launched their use for routine office work. In the early days, however,

it was mainly replacement of a typewriter with a computer, or keeping simple office records using spreadsheet

programs or simple databases. Computers in the early days were not connected within a network, so data transfer

was performed only on floppy disks.

1.4 NETWORK LINK

Individual PCs were connected within computer networks (LAN and WAN). The possibility to share both the

files and resources (such as printers) became the main advantage. The ability to communicate via e-mail was added

as well. This concept is called “server / workstation”. However, there are also disadvantages: workers are snowed

under dozens of e-mails that they have not requested and that are sent to them only “in case they are interested”:

chaos in files, their locations and names, and especially the difficulty of teamwork management.

1.5 CONCEPT CLIENT / SERVER

The concept of file transfers is not normally suitable for the purpose of sharing information. There are

several reasons: the file can be edited only by one user at one time, is difficult to secure uniqueness and timeliness of

the document, regardless of the fact that the transfer of the entire file is inefficient. Imagine a large database. Even

when you change only a few items, it would have to be transferred in its entirety. But if tasks are divided between

the central computer and the workstation - the concept client / server, those accessing the server through their

computers with small portions of this application-clients. The advantage is the possibility of the server to offer its

services to virtually unlimited number of users - it depends only on the performance of the server.

1.6 THE CONCEPT THIN CLIENT/SERVER

The original concept client/server assumed quality and expensive software on the client’s side. Additionally,

the software required powerful hardware resources. Performance of servers grew, the bandwidth of computer

networks expanded, which enabled to transmit larger volumes of data. Then the question arose whether to install all

programs on the servers, while on users' computers would only be software capable of providing data entry and

display of results. This proposal came, among others, from Microsoft, which developed Windows NT, bought license

from Citrix Systems Company, and used in the terminal NT 4.0 Server as a part of the project codenamed “Hydra”.

The functionality is maintained in subsequent versions of Windows, including Windows 7 version known under the

term Remote Desktop.

The term thin client was created in 1993 by Tim Negris, vice president of marketing in Server Oracle Corp. At

the time, Oracle wanted to differentiate their server-oriented software from the desktop oriented on Microsoft

products. Ellison subsequently popularized Negris’ word with frequent use in his speeches and interviews about

Oracle products.

1.7 THE RECENT DEVELOPMENT OF ULTRA-THIN CLIENTS

A thin client used the entire operating system that it provides for other computers. Today, there is a trend

towards ultra-thin clients and zero clients. Instead of launching a conventional operating system, only a small core is

run, which only initializes the network, initiates network communication with the specified network protocol, and

provides graphical output from the server.

Thin clients based on web applications

These clients rely on software for the Internet browsers for mediating their own applications and data

storage. The only, but a major failure occurs when the Internet connection fails.

1.7.1 Cloud computing

Cloud computing is the Internet-based development model and use of computer technology. [1] It can also

be described as the provision of services or programs stored on servers on the Internet that users can access, for

example using a web browser or a client of the particular application, and they can use it virtually anywhere. Users

do not pay (assuming that the service is paid) for their own software, but for its use. The offer of applications ranges

from business applications to systems for distributed computing, to the operating systems running on browsers such

as eyeOS, Cloud, or iCloud.

Summary of Terms

System as a general and a technical term. An information system in an enterprise

must be understood not as an isolated independent part of the whole, but it must be

understood comprehensively with all connections and ties in its dynamic development.

The development of information technology in the commercial sector

Except in special cases, such as scientific and military applications, which had

somewhat different conditions for the deployment of information technology, the

application of information technology in the commercial sector started approximately in

the following steps.

Mainframe batch processing.

Central database systems-

Concept client / server. The concept thin client/server. The recent development

of ultra-thin clients

Cloud computing.

At this time, Information and Communication Technology (ICT) has prevailed:

• information systems have been significantly reflected in the everyday life

of businesses and individuals,

• information systems affected individuals and society,

• information systems acquired their internal “order” and the terminology

and

• the area of information systems has shown its limits and possible risks.

Development of information systems (IS) in companies have resulted in changes

within the manufacturing and non-manufacturing technologies and services. The

development of corporate IS can be viewed from different perspectives:

• changing functionality,

• trends in implementation,

• operation and

• expected benefits.

Questions

1. What is the system.

2. What is the trend in ICT

3. What is the trend in the development of information systems

2 OPERATOR PANELS AND PROGRAMMING

Study time

10 hours

Objective

After reading this chapter, and you will

understand the importance of methodologies in the development of information systems

understand the importance of the life cycle

After reading this chapter you will ACQUIRE:

overview of modern methods used

knowledge of the content of the various life cycle stages and their contents

After reading this chapter and elaborating the tasks, YOU WILL BE ABLE TO:

consider the proposal for an information system from different perspectives

Lecture

The information system life cycle covers the entire stage of the creation of information system through its

commissioning to its own operations and maintenance. As an example of a comprehensive life cycle, we can use the

MDIS (Multidimensional Development of Information System) methodology (ŘEPA)

2.1.1 Brief description of the MDIS methodology

The MDIS (Multidimensional Development of Information System) methodology was defined and published

by the University of Economics in Prague in 1992. Its importance lies mainly in the fact that it can be understood as a

guide, as a model way of thinking in the development of the IS. The methodology helps us to structure the work. It is

a sort of list of the most important things we should focus on in various stages of IS development, etc.

An important concept in this method is the word “multidimensional”. Thus, the creators of the methodology

emphasize that the development and deployment of the information system must be viewed from all possible

angles. Each individual perspective is also called the dimension of the system. Underestimating of such

comprehensive analysis led the creators to the development of such comprehensive methodology based on analysis

of the causes of the failures of development companies in the development and deployment of IS in the operation.

The aim is to minimize the possible causes of failure of the development and deployment of IS.

In other words, the thing is not to forget any factor that may affect the success of the development and

ultimate deployment of IS. Individual angles (dimensions) represent the perspective of the user and solution in terms

of IS development. During the development of IS, we start from the user perspectives of the system, and we

gradually transform them to the solver's insights (KAJZAR, 2005).

User views of the system consist of:

• views of the company senior management;

• views of the middle and firing line management;

• views of the executives - end-users of the system.

The solvers’ views of the system include:

• processes – system functions;

• data structures (databases) of the system;

• hardware and software system architecture;

• organizational and legal aspects of the IS development;

• employment, social, and ethical aspects of the use of IS in the enterprise;

• economic (financial) aspects of the development and deployment of IS in the enterprise.

We can also define methodological and organizational views of the system including the methods used

during the development of IS, processed documents, methods of management of IS development, etc.

The MDIS methodology defines the following stages of the life cycle of IS:

• CIS - company information strategy stage;

• ISS - initial study of the system stage;

• GAD - stage of the global analysis and IS design;

• DAD - stage of detailed analysis and IS design;

• IMP - IS implementation stage;

• PIO - stage of putting IS into operation;

• OMD - stage of operation, maintenance, and further development of IS.

Each of the stages includes the following items:

• Stage objective and subtasks;

• Prerequisites (conditions) for the stage opening;

• Criteria (conditions) for the completion of the stage;

• Key documents processed during the stage;

• Critical factors of the stage - factors threatening the fulfilment of the objectives and tasks of the given stage;

• The most important sub-activities of the stage.

3 The topic conclusions

• We have described the different stages of the life cycle of IS as the MDIS (Multidimensional Development of Information System) methodology distinguishes them. They were the following stages: company information strategy stage (EIS), initial study of the system stage (ISS), stage of the global analysis and IS design (GAD), stage of detailed analysis and IS design (DAD), IS implementation stage (IMP), stage of putting IS into operation (PIO), stage of operation, maintenance, and further development of IS (OMD).

For each stage, we characterized:

objectives and subtasks of the stage, conditions for the start of the stage, the criteria for the completion of

the stage, the key documents prepared during the stage, the critical factors of the stage, the most important sub-

operations of the stage.

In the following chapters of the study text, we will further address important processes and activities during

the development of the IS. These processes and activities usually go through several stages of the life cycle of IS –

they will mainly include the following processes:

• analysis and design of IS in the enterprise;

• testing IS;

• putting IS into operation.

Designing the system can be based on two orientations: a technocratic and user one.

Technocratic orientation of the project is reflected by the fact that the application of the technology of data

processing is fully subordinated to the needs and abilities of computers. This is mainly to minimize print reports and

design of data structures with maximum respect to data objects in terms of optimum storage media needs. This

leads to a strong distortion of the working rhythm of the user and it is associated with a strong aversion to

computerization.

The opposite of technocratic orientation is the user design of the information system, which is characterized

by the need to maintain the current shape and form of documents and their flow. The user's aim is to adapt the

automated information system to the existing functional structure of the organization.

Summary of Terms

To understand the complexity and comprehensiveness of information system, it

is necessary to know how the system is developed, and under what circumstances its

deployment and operation can be successful. Without the knowledge of best practices,

we cannot imagine working in a systems approach area today. Methodology, as well as

defined stages of the life cycle of the system will enable us to focus on this complex

topic. For successful work in the development and implementation of information system

in practice, it is always necessary to remember that the most important thing is to know

the goal that we want to achieve, that the cooperation of the contracting authority and

the creator of the system is indispensable, and finally that the promotion of the

information strategy in the company's requires the involvement of top management.

User views of the system consist of:

• views of the company senior management;

• views of the middle and firing line management;

• views of the executives - end-users of the system.

The solvers’ views of the system include:

• processes – system functions;

• data structures (databases) of the system;

• hardware and software system architecture;

• organizational and legal aspects of the IS development;

• employment, social, and ethical aspects of the use of IS in the enterprise; • economic (financial) aspects of the development and deployment of IS in the

enterprise.

Questions

1. What is the life cycle of the information system?

2. Why is it necessary to determine the objective of each stage of the life cycle?

3. What do prerequisites for starting the stage mean?

4. What are the criteria for the completion of the stage?

5. What are the key documents and what is their significance?

6. What do critical factors mean?

AD-HOC APPROACH AND GENERAL PRINCIPLES OF

ANALYSIS AND DESIGN OF IS

Time to study

4 hours

Objective

After reading this paragraph, you will be able to define, describe:

• define the abstraction .principle

• describe the Ad-hoc .approach and general principles of analysis and design of IS

• describe the different levels of abstraction

• describe the principle of the three architectures

Lecture

3.1 CHARACTERISTICS APPROACHES TO THE CREATION OF AN INFORMATION SYSTEM BY THE

COMPANY LBMS

Ad-hoc approach is characterized by

freedom of creation,

prevailing experience of our own and

designers’ attempt to avoid new problems.

The consequence of this approach is that the project is developed according to the plan, but then it is often

redesigned.

Fundamentalist approach consists in

in blind allegiance to the system of procedures, which implies that

solvers often do not understand the specific activities or interactions of intermediate products.

A balanced approach

creates a balance between Ad-hoc approach and fundamentalist approach

pragmatically combines orderliness and discipline with the necessary creative freedom.

3.2 GENERAL PRINCIPLES OF ANALYSIS AND IS DESIGN

In the following paragraphs we turn our attention to the principles and rules which are common to all

methodologies and methods of IS development. The principles that we mention apply to methods of structured,

object and other (hybrid), they are the basis for the CASE (Computer Aided System Engineering) tools and techniques

used in the development of the IS.

Information system is extremely complex and complicated. The first group of principles seeks to combat the

complexity of IS development. These means include:

hierarchical decomposition of the issue

phasing and iteration of the solution procedure

modelling and comparing models

use of graphic means of expression

the principle of abstraction

Hierarchical decomposition of the issue solves division of the complex system into simpler systems

(subsystems), and the decomposition is continued until it reaches the necessary level of detail. Thus a hierarchy of

subsystems is created. In this hierarchy, you can get an idea of the system as a whole, the links between the

subsystems, as well as the form of the system at that level of detail. Hierarchical distribution system facilitates the

planning, organizing and controlling the work of the development team.

Phasing the solution procedure is the division of the complex process of IS development into partial stages

with assigning objectives, tasks, inputs, outputs, documentation, risk, partial activities, responsible persons, financial

cost…

Iteration is a repeated execution of the activities of the individual stages. Each successive repetition of

activities is always carried out at a higher level of understanding of the problem, and it often means repeated returns

to the previous stages. The purpose of the iteration is the progressive processing of the problem at various levels of

distinction - from rough ideas about the solutions to the detailed design of the system.

Modelling is a basic technique used during the IS development. The basic idea of modelling is that we do not

work with the information system itself, but with its appropriately established model. These models and their

development are much cheaper than the system as such. If it turns out that there were mistakes and errors during

the analysis of the system, the correction of those errors is much cheaper than the remedy of such mistakes in case

we built an information system as such.

Graphical means of expression allow us to create a vivid picture of the developed IS. Graphical

representation is capable of carrying far more information than just written text. It is also usually much clearer and

more vivid. Graphical means of expression for the modelling of IS are part of CASE tools focused on the analysis and

design of IS.

The basic principle of analysis and design of IS is the principle of abstraction. Abstraction is the thought

process that eliminates the differences and particularities of individual objects or phenomena, and stresses common,

general, essential characteristics of the observed set of objects or events.

The opposite of abstraction is a thought process called concretization, i.e. a process in which the specific

properties of the observed objects or phenomena are gradually extracted from the general.

We can distinguish the following three levels of abstraction:

categorization;

aggregation;

generalization.

Categorization is the lowest level of abstraction. Means the grouping of elements (events) into classes

(categories) according to criteria that we choose, given the purpose of these elements (events). E.g. school students

are divided into study groups according to fields of study, corporate IS is divided by the type of use in the enterprise,

according to the requirements for safe operation, etc.

Aggregation is a special-purpose group of components (i.e. abstraction of the “part-whole” type), so it is not

a generalization of the common properties of elements. As an example, we will aggregate the elements of computer

components: computer case, monitor, keyboard, mouse - these are elements of the whole, i.e. the computer.

Generalization means the abstraction of the “specific type - common subtype” type. In generalization, we

look for common characteristics of monitored elements and specify the properties of the subordinate unit as a

carrier of specified common properties (attributes).

An example might be a generalization of common features of elements of the “computer administrator”,

“computer operator”, “database systems administrator”, “HW administrator”. The carrier of common characteristics

will be, for example the “worker in charge of the system support of IS/IT in the enterprise”. Generalization may be

multistage. In our example, more general terms can be “IT department worker” or further, more generally the

“company employee”. The opposite of generalization is a thought process called specialization.

Thought processes of abstraction and concretization apply throughout the whole analysis and design of IS.

The principle of differentiation levels is based on imaging a certain selected resolution detail of the

developed system. On the roughest level of resolution, the developed IS is shown as one element cooperating with

its surroundings. The purpose of such imaging is a description of the links of the system with its surroundings.

On the subsequent level of resolution (we call it a “distinctive level 0”), we can already see the system as a

set of cooperating subsystems. Imaging of the particular IS can be further developed up to a level where we can see

the details needed to solve our problem.

The principle of three architectures is closely related to the principle of differentiation levels. All images of

the developed IS at various levels of differentiation are divided into three categories (layers of details). We talk about

so called layered abstraction of the system.

We obtain these layers:

The 1st layer of the system imaging.... conceptual (or essential)

The concept means an approach, an idea. The first layer represents imaging the system at a rough level of

resolution. I.e. imaging the system and its links to the surrounding systems, as well as imaging the system with visible

major subsystems and the relationships between them. This imaging clearly shows which subsystems of our system

operate as an interface between our system and its surroundings, i.e. which subsystems process inputs and outputs

of our system with respect to the surroundings. The purpose of imaging the system in this layer is to answer the

question of what the content of the system is.

The 2nd layer of the system imaging.... technological (or logical)

This layer includes the system imaging that shows how the content of the system is implemented, takes into

account the organization of data (file systems, relational database management system, etc.), system architecture

(client/server). Imaging the system in this layer is not burdened with the implementation specifics, i.e. IS

implementation in a particular information technology environment.

The 3rd layer of the system imaging.... implementation (or physical)

In this layer of imaging, the details of specific implementation are already visible (e.g. properties resulting

from a particular database system. We can see how the system is realized.

The principle of three architectures is applied throughout the whole analysis and design of IS. This results in

models of IS developed at different levels of abstraction. In the individual stages of IS development, we try to process

an IS model in the desired layer. For example, in the stage of global analysis, it is desirable to create a conceptual

model of IS (imaging in the 1st layer), in the stage of the detailed analysis and design of IS, the model is developed

further until the necessary details of layer 3.

Similarly, during the analysis and proposal of a change (innovation) in IS, we try to identify a change and

incorporate it from top to bottom, i.e. from the model at the roughest level of resolution at which the change will be

visible.

The third principle applied during the development of the IS is modelling - creation of a model of the

developed IS. Modelling special-purpose simplified imaging of the system using appropriate imaging agents. It is an

abstract image of reality. Modelling is one of the basic principles and techniques of analysis and design of IS.

What is the purpose of modelling? A model is a formalized means of representation of the developed IS, a

means of understanding between the experts, between the system analyst and expert in the real world (a future IS

user). A model allows us to illustrate the structure of the developed IS (i.e. the structure of processes, data,

management processes) to the selected distinguishing levels, optimize the structure of IS with respect to the

selected criteria. A model allows us to simulate and study the system changes and their impact on sub-subsystems

and surroundings of the system.

Generally, a model can be characterized as follows:

a model is formulated as a system (i.e., it shows the elements and their relationships);

border elements realize the links of the system with the environment (inputs, outputs);

the content (sum of the elements and relationships) of the model is objective - every element of the model

corresponds to some real-world object, or it is an auxiliary element;

arrangement of elements in the model corresponds to the arrangement of elements of the real world, which

is shown by the model.

Creating IS models in practice is facilitated by CASE (Computer Aided System Engineering) tools. These tools

provide means of expression for the graphical representation and the verbal description of models, offer a method

for creating models, structure of models segmented by distinguishing levels. In any case, we cannot imagine the term

IS model only as a graphical representation of the developed IS. The model obviously also includes a verbal

description of the model as a whole and a description of its purpose, the description of each component of the

model, of depicted elements, subsystems, relationships between elements, and relationships between subsystems.

As part of IS, we try to capture all the analysed dimensions of IS, i.e. the dimension:

Working (procedural)

It is a description of the processes that will take place in the system, data flows and relationships between

subsystems.

Data. It is the description of all types of data the developed IS with work with.

Control

It is a description of the temporal context of system events.

Organisational and technological

It is an illustration and description of the organization of work with the particular IS, and a description of the

technologies that will be implemented by the developed IS.

Systemic and technical

It is a description of the implementation of the implementation-dependent system functions and their

temporal continuity.

3.2.1 Types of approaches to the analysis and design of IS

In the course of the historical development, two basic approaches to the analysis and design of IS profiled -

structured approach and object-oriented approach (briefly object). Understanding these approaches is important for

understanding the methods that are usually tied to specific approaches.

Methods based on the structured approach are the result of a long-term development of methods of analysis

and design of IS. Historically, a number of different methods, tools and techniques were developed; for example, the

methods: DeMarco, Gane/Sarson, Warnier/Orr, Yourdon

The term “structured approach” reflects the thought process of “structuring” of the process for examining

the particular issue, as well as of the subject that we examine. In the area of analysis and design of IS, structuring

represents the basic working method, means for combating complexity, and it has a general meaning in the analysis

and design of IS (that is, it is a general thought process not only in the area of structured methods, but also in

developmentally younger object-oriented methods of analysis and design of IS).

We know that one of the basic techniques used in the analysis and design of IS is modelling.

Summary of Terms

Characteristics approaches to the creation of an information system by the

company LBMS

Ad-hoc approach is characterized by

Fundamentalist approach consists in

A balanced approach

General principles of analysis and IS design

In the following paragraphs we turn our attention to the principles and rules

which are common to all methodologies and methods of IS development. The principles

that we mention apply to methods of structured, object and other (hybrid), they are the

basis for the CASE (Computer Aided System Engineering) tools and techniques used in

the development of the IS.

Information system is extremely complex and complicated. The first group of

principles seeks to combat the complexity of IS development. These means include:

hierarchical decomposition of the issue

phasing and iteration of the solution procedure

modelling and comparing models

use of graphic means of expression

the principle of abstraction

We can distinguish the following three levels of abstraction:

categorization;

aggregation;

generalization.

The principle of three architectures is closely related to the principle of

differentiation levels. All images of the developed IS at various levels of differentiation

are divided into three categories (layers of details). We talk about so called layered

abstraction of the system.

The 1st layer of the system imaging.... conceptual (or essential)

The 2nd layer of the system imaging.... technological (or logical)

The 3rd layer of the system imaging.... implementation (or physical)

The third principle applied during the development of the IS is modelling -

creation of a model of the developed IS. Modelling special-purpose simplified imaging of

the system using appropriate imaging agents. It is an abstract image of reality. Modelling

is one of the basic principles and techniques of analysis and design of IS.

Creating IS models in practice is facilitated by CASE (Computer Aided System

Engineering) tools. These tools provide means of expression for the graphical

representation and the verbal description of models, offer a method for creating models,

structure of models segmented by distinguishing levels..

As part of IS, we try to capture all the analysed dimensions of IS, i.e. the

dimension:

Working (procedural)

Organisational and technological

Systemic and technical

In the course of the historical development, two basic approaches to the analysis

and design of IS profiled - structured approach and object-oriented approach (briefly

object).

Qustions

1. What is the Ad-hoc approach?

2. How can we characterize the fundamentalist approach?

3. What are the principles of the balanced approach?

4. What is IS modelling based on?

4 TYPES OF IS DEVELOPMENT METHODOLOGIES AND

CURRENT TRENDS

Time to study

4 hours

Objective

• define the .agile methodology

• describe the .kinds of methods and their classification.

• describe the principles on which the agile methodologies are based

Lecture

We know that the methodology is the general term for the concept of method. The methodology

recommends the use of certain methods during the development of the IS; the individual methods are based on a

structured, object or combined (hybrid) approach to the analysis and design of IS.

4.1 TYPES OF METHODOLOGIES

Methodologies can be divided into the following categories:

4.1.1 State-supported methodologies

The state requires the application of these methodologies in the development of IS as government contracts.

The aim of this approach is to use standardized procedures to ensure the best conditions for the quality of the design

of IS and the final product. An example of state-supported methodologies is, e.g.:

SSADM (Structured Systems Analysis and Design Method) - Great Britain;

SDM (System Development Metodology) - Netherlands;

MERISE - France.

4.1.2 international methodologies

These are methodologies advocated in international cooperation in the area of the design of IS. An example

of an international methodology:

Euromethod.

4.1.3 corporate methodologies

These are methodologies created by the application of general principles and recommendations for the

specific needs of a development company. Examples of corporate methodologies:

SE (System Engineering) – LBMS Company;

Oracle CASE Method;

SAFE (Sybase Advanced Framework to Enable ....) – Sybase Company.

Currently, it is obvious that the authors of methodologies (business methods) apply the general principles of

quality management for software creation, and the general principles of quality management for business processes

according to ISO standards (ISO 9001-International Organization for Standardization).

4.2 CURRENT TRENDS IN THE EVOLUTION AND DEVELOPMENT METHODOLOGIES.

Here are a few key and clearly visible trends:

4.2.1 Using iterative procedures

Iterative procedure, as one of the basic principles of IS development, is applied in the form of a spiral model

of IS development and prototyping technique.

4.2.2 Penetration of object methods, techniques, and tools

This trend is related to the development of object-oriented methods, techniques, tools, object-relational

database management systems, etc.

4.2.3 “Globalization” of the analysis concept

Analysis and design of IS now includes the issue of modelling and optimization of business processes. It is

obvious that before automating business processes in production and management, it is appropriate (necessary) to

optimize these processes according to the selected criteria. Subsequently, support of business processes using IS/IT

should be analysed and designed. The issue of the analysis and design of IS can thus come across the issue of BPI

(Business Process Improvement) or BPR (Business Process Reengineering).

4.2.4 The shift from “hard” to “soft” methods

Analyses of the failures of many development companies showed that one of the causes of failure in the

development and implementation of IS at the customer was the underestimation or neglect of organizational, social,

and psychological dimensions of IS development. The information system is to be understood as a socio-technical

system, it is not possible to consider merely technical aspects of IS/IT. Thus, the current methodologies also include

techniques of analysis of interests and attitudes of different groups of users (of different interest groups in the

enterprise), user training, provision of consulting services. In short - human dimension is also an essential aspect of

the information system.

4.3 THE APPLICATION OF METHODOLOGIES FOR THE IMPLEMENTATION OF THE STANDARD

APPLICATION SOFTWARE (TASW)

I.e. the development of corporate methodologies for implementation of standard IS in a particular company

and a complex issue of customization of IS, i.e. IS adaptation to the customer. It is not just about the configuration IS

parameters, but also the area of work organization, migration of data and operational technology of the original

system, the completion of missing parts (sub-systems) of the standard IS, etc. As an example, we can mention the

methodologies for the implementation of the economic system SAP/R3, the Oracle Company products, etc.

4.3.1 The emergence and development of so-called agile methodologies

The term agile methodologies means (in short) methodologies that try to move away from administratively

demanding practices of IS development in order to speed the development. The emergence of these methodologies

responds to the needs of the development of certain types of IS (smaller systems, web applications, etc.), for which

the procedures and recommendations of the existing methodologies (despite their adaptation) can be felt by

developers as unnecessarily complex and disproportionate in relation to the developed system.

Agile methodologies have specific rules, principles and procedures that must be observed in practice. The

next subsection will focus on the topic of agile methodologies.

4.4 AGILE METHODOLOGIES OF IS DEVELOPMENT

We know that the term “information system” is a broad concept and IS development is a complex process.

Selecting the process of development must therefore depend on the category and type of the developed IS and on

economic conditions so as to meet the IS design goals, i.e. the functional and safely operating IS, a satisfied customer

and a satisfied development company. In the current market of IS design methodologies, so called agile

methodologies are emerging. They represent a group of methodologies based on the fact that the only way to verify

the correctness of the proposed system is develop it as soon as possible, present it to the customer, and adjust it

based on the feedback.

Agile methodologies follow the following principles:

4.4.1 Incremental (iterative) development of IS with very short iterations

The development starts with the most important SW functions, after their testing by the customer, more

functions are gradually added.

emphasis on the communication between the customer and the developer

The customer representatives should be members of the development team, to participate closely in the

design of the system; due to short development iterations, they communicate their experiences to the developers.

4.4.2 Rigorous automated software testing

For the particular SW, a comprehensive set of tests is created, for each SW change there must be must be

pre-assembled tried tests; then the changed software is tested with the set of tests.

In February 2001, representatives of new approaches to software development met and established the

“Alliance for Agile Software Development” and signed the “Manifesto of Agile Software Development”. The

manifesto is published.

4.5 EXAMPLES OF AGILE METHODOLOGIES

The rules of agile methodologies are not something fixed; they constantly evolve in the light of practical

experience. Prior to the application of each methodology in practice, it is necessary to be familiar with its principles,

procedures, and recommendations (see literature, conference papers, sources on the Web). The following sections

briefly describe at least some of the listed methodologies:

4.5.1 ASD - Adaptive software development

The methodology replaces the traditional process of IS development, “Planning-Design-Implementation”

with the dynamic cycle “Speculation-Cooperation-Learning”. The cycle requires continuous learning driven by

changes. Deviations from the plan are not seen as mistakes but as a learning opportunity.

The speculation stage involves determining the date of completion of the project, determining the optimal

number of iterations, dates the completion of each iteration, determining the content of each iteration, assignment

of software components and technologies to individual iterations. In the cooperation stage, the development of

software components is realized. Emphasis is placed (as it follows the principles of agile methodologies) on the

communication and interaction of members of the development team.

Learning phase serves to evaluate and improve the development process at the end of each iteration, i.e. to

evaluate the quality of the developed software, team work, and project status.

4.5.2 FDD- Feature-Driven development

The process of development in this methodology is based on short (about every two-week) product feature-

driven iterations. A features means a partial result, useful from the customer's perspective, measurable and feasible

within the two-week iteration. FDD thus leads developers to creating functional increments every two weeks. FDD

recommends to define the so-called. “lightweight” processes, each process is described briefly in the structure:

input criteria for the process;

tasks (name, participants, responsibilities, description of the task);

verification tools;

input process conditions - tangible outputs.

In all processes, alternatives are recorded. The sequence of processes is as follows:

elaborating a general model of the developed IS;

creating a detailed list of IS features with their solution priorities;

planning the development of each feature, each group (class) of features is assigned the owner, the date of completion;

designing features, i.e. contacting the developers implementing the particular software feature, and processing the sequence diagram of solving the particular feature;

implementation of features.

4.6 XP - EXTREME PROGRAMMING

XP is a methodology suitable for small to medium sized development teams that must cope with a rapidly

changing or unclear assignment. The description and explanation of the methodology can be found in [BEC02]. The

XP methodology is based on the following principles:

it uses timely, concrete, and continuous feedback resulting from short iterative IS development cycles;

incremental approach to planning anticipates that the plan may continue to evolve and change during the project;

it uses automated tests created with the participation of programmers and customers;

the emphasis is on verbal communication between the development team and the customer;

the system design is an evolutionary process taking place continuously throughout the lifetime of the system;

close cooperation of programmers (programming in pairs).

4.7 CRYSTAL METHODOLOGIES

The idea of Crystal methodologies is based on the fact that one methodology does not fit all projects and

development teams. Therefore, Alistair Cockburn defined the technique of creating a methodology “just in time”. It

is based on a three-dimensional matrix (crystal) project characteristics. The matrix dimensions consist of:

the number of people involved in the project;

the degree of importance of the system being developed for the customer;

the project priorities.

According to the level of these prime factors, a methodology is selected, which is further adapted

and tuned according to the needs of a specific project.

Summary of Terms

We know that the methodology is the general term for the concept of method.

The methodology recommends the use of certain methods during the development of

the IS; the individual methods are based on a structured, object or combined (hybrid)

approach to the analysis and design of IS.

Methodologies can be divided into the following categories:

State-supported methodologies

SSADM (Structured Systems Analysis and Design Method) - Great Britain;

SDM (System Development Metodology) - Netherlands;

MERISE - France.

International methodologies

Euromethod.

Corporate methodologies

These are methodologies created by the application of general principles and

recommendations for the specific needs of a development company.

SE (System Engineering) – LBMS Company;

Oracle CASE Method;

SAFE (Sybase Advanced Framework to Enable ....) – Sybase Company.

Here are a few key and clearly visible trends:

Using iterative procedures

The emergence and development of so-called agile methodologies

Agile methodologies follow the following principles:

Incremental (iterative) development of IS with very short iterations

Rigorous automated software testing

FDD- Feature-Driven development

XP - Extreme programming

XP is a methodology suitable for small to medium sized development teams that

must cope with a rapidly changing or unclear assignment.

Crystal methodologies

The idea of Crystal methodologies is based on the fact that one methodology

does not fit all projects and development teams. Therefore, Alistair Cockburn defined the

technique of creating a methodology “just in time”. It is based on a three-dimensional

matrix (crystal) project characteristics.

Questions

1. What is iterative development of IS?

2. What do we call the method of extreme programming?

3. What is the main idea of Crystal methodologies?

5 FUNCTIONAL MODELS OF INFORMATION SYSTEMS

Time to study

3 hours

Objective

After reading this chapter and elaborating the tasks, you will BE ABLE TO:

apply the principles of functional modelling

apply a structured approach to the design of IS

After reading this chapter and elaborating the tasks, you will ACQUIRE:

knowledge of data flow diagrams

knowledge of the principle of the system structural analysis

After reading this chapter and elaborating the tasks, you will BE ABLE TO:

propose a status model of the system

maintain the consistency of the individual functional models

Lecture

5.1 A STRUCTURED APPROACH

A structured approach is historically older approach to the analysis and design of IS. Its principles were

established at the end of the 1970s and during the 1980s. The term “structured approach” reflects the process of

examining the particular issue of the examined subject. Analysis and design of IS must encompass the processes

occurring in the system, and data the system works with and produces.

Group of models display the processes and data flows between them,

receive the system data structures,

capture the system state changes over time,

display the hierarchy of software components of the developed IS.

The structured approach is characterized by relatively independent imaging of the system data structures in

one model; data flows and processes processing data in another model.

We talked about the principle of the three architectures - three layers of imaging the system. During the IS

modelling, we obtain a set of models of the developed IS:

from different perspectives – i.e. we create the individual types of models;

within the same perspectives at different levels of distinguishing details.

Models showing the developed IS from the same point of view and differing by the distinguishing levels can

be grouped into three main layers of imaging the system:

5.1.1 Conceptual level of models, the first layer

A conceptual model is a content description of the system (without implementation details), i.e. we identify

the main data flows (input, internal, output), specify the main data objects, and indicate their characteristics. The

resulting model of reality consists of several kinds of partial models:

data model - contains a static description of the system (elements + links);

functional model - contains a description of the processes and relationships between them; a management

model - a description of time succession of processes.

Conceptual models in other layers of imaging are further processed, details are supplemented.

5.1.2 Technologic (logic) level of models, the second layer

These models already contain:

entity sets and their primary keys in the data model;

relationships between entity sets in the data model;

partial subsystems, their structure, data flows, and storage in the functional model.

5.1.3 Implementation (physical) level of models, the third layer

The developed IS imaging contains such details to enable to start implementation (programming) of the

system. Models must already reflect specifics of the implementation environment, i.e. the programming language

and the applied Database Management System.

To check the consistency of models, there are the best practices within the methods of analysis and design of

IS, for example [ŘEP99] gives rules for checking the consistency of models, drawing from [YOU89]. All the elaborated

models of the developed IS form a whole showing the developed information system from different angles and at

various distinguishing levels.

IS modelling is facilitated by CASE (Computer Aided System Engineering) tools. CASE tools often distinguish

only two basic layers of imaging, namely:

the model varies according to the methodology used. In this text we will use the notation Yourdon-DeMarco.

5.2 THE CONTEXT DIAGRAM

The first model we will discuss is the context diagram. This model ranks among the so-called models of

external behaviour of the system (see Figure 3.1).

As apparent from the above-mentioned terms, the purpose of the model is:

Imaging the developed system in the context of its surroundings;

describing the link of the system to its surroundings;

defining the boundaries of the system, defining external resources, and data recipients.

Elements used in the context diagram include:

Process

The process is defined as a set of activities that transform inputs into the desired outputs.

External entities (terminators)

The external entity (terminator) means the external data source for the modelled system or the recipient of

the modelled system data. The terminator is therefore an external element that is not part of the modelled system.

Data flows

It is a representation of the data flow between the developed system and its surroundings (terminators).

Data Store

It is a place which serves to store data (database).

Here is an example the context diagram for the developed IS “Processing the company payroll” (simplified):

Characteristics of the context diagram:

• It represents the boundary between the developed system and the outside world.

• It demonstrates the developed system as a single process, linked with its surroundings by data

streams.

• It demonstrates who communicates with the system, i.e. external entities (terminators).

External entities may include people, organizations, other information systems, and so on. It shows the input

and output data streams, i.e.: data entering the system from the surroundings, to be processed by the system

(transformed into outputs); processed data output from the system to the surroundings.

Imaging data storage is not typical for the context diagram. The context diagram, however, can also display

data storage if:

the data store is shared by the jointly developed system and terminators;

we want to emphasize the importance of data store that will be created by our developed system, and it will

also be used by the surroundings (the external world);

we want to emphasize data store created by the outside world, and it will be used by our developed system.

In addition to the graphical representation, the model includes:

verbal description of the meaning of the individual external entities;

verbal description of the meaning and content of the shown data streams.

The context diagram is the default model for modelling the information system.

Its purpose is to capture all communication (data flows) between the developed system and its surroundings,

and to capture all the entities communicating with the developed system. It is a model belonging to the conceptual

layer of the developed IS imaging.

5.3 LIST OF EVENTS

A list of events is a model showing of the external behaviour of the system, similar to the context diagram.

However, it is aimed specifically at the data flows entering the developed system from its surroundings, which have

the character of stimuli to trigger a reaction of the system to start other related processes and data flows.

Purpose of the model is: to represent stimuli that act on the system from its surroundings;

to represent external entities that transmit stimuli;

to capture the relationship between stimuli affecting the system and the system’s responses.

Events affecting the system as stimuli can be classified as follows: F-event (Flow) This is an event associated with entering data into the system. E.g. the arrival of goods orders

from the customer, the arrival of invoices for services rendered, the arrival of the patient to the doctor, etc.

F-events are not related data flows within the system, and other related input data. E.g. requesting a delivery

note and comparison of the invoice with the delivery note is a related activity after the initial stimulus “an

invoice arrived”.

T-event (Temporal) This is an even affecting the system as a stimulus that does not, however, depend on

coming data, but on the time (we talk about the time event). For example: on the 3rd day of the month, the

payroll is calculated; every Friday at 17:00, an inventory takes place; on 30 June, it is necessary to send the

respective half yearly report.

C-event (Control) This is an event of the command type, e.g. switching sensors, shut/open. Basically, it is a

special case of T and F events. This type of event occurs especially in systems operating in real time.

The model thus offers a view of the system as a summary of constantly emerging events, and as a string

“event - the system response”.

The system response to events can be divided into the following categories:

output of the report on the occurrence of an event;

output of the report on the aftermath of the event;

only storing the information that an event has occurred (system response only follows the combination of

certain events).

In addition to the graphical representation, the model includes:

verbal description of the meaning of the individual external entities;

verbal description of the meaning and content of the events depicted and derived data flows.

The context diagram must represent all data flows between the system and its environment, including data

flows, which are related data flows with respect to the list of events (part of the subsequent operational technology).

On the other hand, the list of events can display both time events and events of the control type.

5.4 DIAGRAM OF THE FUNCTIONAL STRUCTURE OF THE SYSTEM

The purpose of the system Function Structure Diagram (FSD -) is:

• to describe decomposition of the system at sub-functional units (subsystems);

• to document the functional hierarchy of the system;

• to provide a view of the developed system with a focus on the hierarchical structure of the

system.

The diagram of the functional structure of the system views the system as a whole, which is divided into

further sub-systems up to the required level of detail. FSD was created in the early 20th century as a means to

express the organizational structure of the company and the production.

FSD model elements are as follows:

• functions (process, subsystem);

• connector for displaying links in the tree structure of subsystems.

In the model, we can distinguish several kinds of functions:

• process functions These are functions in charge of data processing (transformation of inputs into outputs).

• dialog function expressing using the menu of options.

• control function for coordinating the activities of other functions. In FSD, there should be no more than one

control function.

The rules for representation of functions: • Graphical representation of the function is a quadrilateral.

• Each function has its number according to the level of decomposition, and its name.

• The numbering of function is performed using decimal notation – e.g. 1, 1.1, 1.2, 1.3, 1.2.1, 1.2.2, ....

• The function name should reflect the function performed – e.g. Dispensing of materials, Ordering goods,

Receiving orders,....

• Description of the function might look like this: 1.1 Dispensing of materials 1.2 Receipt of materials When

constructing FSD, we proceed using the top-down method:

• The highest level is the name of the entire system (representation of the system as a single function).

• The next level (higher level of distinguishing) consists of subsystems that can express different organizational

units in the company, a division of the organization by processing specific business cases (orders, contracts),

etc.

• At other levels of details, we choose the subsystems that should be divided into simpler subsystems

(function). We continue like this until the required level of details.

5.5 DATA FLOW DIAGRAM

The purpose of Data Flow Diagram (DFD) is:

• to show a dynamic view of the developed system;

• to illustrate the points where data are transformed into another form – i.e. to illustrate so called processes;

• to describe which processes and their links comprise the system;

• to illustrate and describe data flows used as inputs and outputs of individual processes.

Data flow diagram does not express the time arrangement of processes or data flows.

The illustrated continuity between processes and data flows in DFD concerns purely data (data enter into

processes and leave them). Illustration of links between data flows and processes according to the time and order of

data flows and processes is missing here.

For DFD, different terms are used in the literature, e.g.:

• functional model of the system;

• word-flow diagram;

• process model;

• bubble chart.

The term “functional model” here reflects the relationship with the static type of the system imaging, i.e.

with the above-described FSD.

To illustrate the system in DFD, the following elements are used:

• processes Process is a set of activities transforming inputs into the required outputs.

• Data Store Data store shows the data storage location, i.e. it represents a static view of the data in the

system (representing data at rest).

• Data Flow Data flow show the movement of data between processes and data store. Data flow represents a

dynamic view of data in the system (representing data in motion).

• terminators (external entities) Terminators are external entities in the same sense as it was in the context

diagram. Terminators can be displayed on the rough levels of distinguishing of the DFD model to emphasize

the relationship “subsystem of the developed IS <-> external entity communicating with it”.

The individual elements of the DFD model are characterized in greater detail below.

Properties of processes: • These are activities transform inputs into outputs.

• Their graphical representation is a circle or an ellipse. ¨

• Processes must be named, and naming each process must reflect the essence of transformation.

• Processes must be numbered. Upon further decomposition of the process into sub-processes, we use the

numbering of sub-processes, so that it clearly shows the hierarchy of the processes. E.g., process 1 is at a

higher level of distinguishing divided into processes 1.1, 1.2, 1.3, then the next level of the hierarchy is

numbered 1.1.1, 1.1.2, 1.2.1, etc.

• Processes can be divided into two main types - data and control processes.

o Data processes reflect any data transformation, i.e. changing the value of data, creation of data,

deletion of data.

o Control processes reflect algorithm of process control, control instructions in time. It is the case of

capturing real-time characteristics of applications. The output of the control process are the control

impulses.

Data flow properties: • Data flow reflects the movement of the entities between parts of the system, between the system and the

surroundings, it illustrates the interconnection (communication) of the system processes, represents data on

the move.

Graphical representation of data flow - arrow.

• Data flow may reflect movement of information, but also of the goods, materials, etc.

• Data flow must be named, the name of data flow must express its contents.

• On the conceptual level of imaging, data flow is an abstraction of any form of data transfer (it says nothing

about the specific technology used to transmit data).

• Data flow from the process to data store represents any kind of modification of data by the particular

process (insert, update, delete).

• Data flow from data store to the process represents the data usage by the particular process (select).

Data Store properties: • Data store is used to model the set of data at rest, interruption of data flow over time (it is a passive element

of the model).

• The data store is the form of connection between processes (data flow is interrupted here over time).

We graphically illustrate data store via two parallel lines.

• On the conceptual level, data store is an abstraction of any form of data store, it says nothing more about the

specific form of storing.

• Implementation of data store may vary - it can be the database in the database server environment, text

files, etc..

• Data store must be named, the name may also reflect the planned implementation - card file, binder, file,

database table, etc.

The reasons for the existence of data store are as follows: • the user requires specific information, therefore it is necessary to save this information; the implementation

generates partial results that must be saved for a certain period.

• Data store is a passive element of the DFD model. Hence - data into and from data store must always flow

through the process (!!).

Properties of terminators (external entities): • They represent the elements lying outside the system we are developing, i.e. the source and recipient of

the data in the surroundings of the system. These external elements can be people, other businesses,

other departments, other information systems, etc.

• Graphical representation of the terminator - a rectangle.

• Data flow between the terminator and the developed IS is part of the interface between the developed

IS and its surroundings.

• Terminator must be named, its name should express the type of source, its location, etc.

• Relationships between the terminators are no longer part of DFD of the developed IS, in terms of the

developed IS, we are not interested in those relationships. If we were interested in data flows between

the terminators (they would be essential for the developed IS); we must replace the terminators with

processes and include them into the framework of the developed IS.

Data flow diagram is first processed at the roughest level of distinguishing. So called system is shown as

several sub-systems (processes), mutually exchanging data. In sub-system models (i.e. imaging at a higher level of

distinguishing), individual processes, data flows and data store are decomposed into simpler elements.

Summary of Terms

A structured approach is historically older approach to the analysis and design of

IS. The term “structured approach” reflects the process of examining the particular issue

of the examined subject. Analysis and design of IS must encompass the processes

occurring in the system, and data the system works with and produces.

We talked about the principle of the three architectures - three layers of imaging

the system. During the IS modelling, we obtain a set of models of the developed IS:

• from different perspectives – i.e. we create the individual types of

models;

• within the same perspectives at different levels of distinguishing details.

Conceptual level of models, the first layer

Technologic (logic) level of models, the second layer

These models already contain:

• entity sets and their primary keys in the data model;

• relationships between entity sets in the data model;

• partial subsystems, their structure, data flows, and storage in the

functional model.

Implementation (physical) level of models, the third layer

THE CONTEXT DIAGRAM

As apparent from the above-mentioned terms, the purpose of the model is:

• Imaging the developed system in the context of its surroundings;

• describing the link of the system to its surroundings;

• defining the boundaries of the system, defining external resources, and

data recipients.

DIAGRAM OF THE FUNCTIONAL STRUCTURE OF THE SYSTEM

The purpose of the system Function Structure Diagram (FSD -) is:

• to describe decomposition of the system at sub-functional units

(subsystems);

• to document the functional hierarchy of the system;

• to provide a view of the developed system with a focus on the

hierarchical structure of the system.

• The function name should reflect the function performed – e.g.

Dispensing of materials, Ordering goods, Receiving orders,..

DATA FLOW DIAGRAM

The purpose of Data Flow Diagram (DFD) is:

• to show a dynamic view of the developed system;

• to illustrate the points where data are transformed into another form –

i.e. to illustrate so called processes;

• to describe which processes and their links comprise the system;

• to illustrate and describe data flows used as inputs and outputs of

individual processes.

Questions

1. What is the principle of a structured approach to analysis and design of IS?

2. What is characteristic of structured design?

3. What is the conceptual model level and what is it used for?

4. Characterize the technological level of models.

5. Explain the contents of the implementation level of the model.

6. Which functional models of the system do you know?

6 DATA MODEL

Time to study

40 minutes

Objective

Build a simple data model

Prepare a draft ERD model

After reading this chapter and elaborating the tasks, you will ACQUIRE:

Overview of methods for data analysis

Knowledge of the concepts of abstraction, specialization and collectivization in the data model

After reading this chapter and elaborating the tasks, you will BE ABLE TO:

Perform data analysis system and understand consistent ties to a functional model of the system

Lecture

The data model does not affect the IS function. We are interested in data, not with respect to their content,

but from the perspective of interdependence and the ability to describe reality. For the design of the IS data base, it

is necessary to know which means we can use to write the information structure to meet all the attributes of the

concept of information. It is extremely important to understand the principles that are the basis of the consistency of

the information system data. Choosing the essential characteristics that define a particular entity, a fact, a

phenomenon, a person... is also significant in other areas of life, not only in the development of the information

system.

This chapter will focus on the issue of the data model in terms of its imaging using ERD (Entity Relationship

Diagram).

The purpose of the data model (ERD - Entity Relationship Diagram) to illustrate the structure of the data the

developed IS, i.e. to represent entities, their attributes, and relationships between sets of entities.

The history of the development of ERD is linked to the name P. Chen – he introduced so called ERA diagrams (Entity

Relationship Diagrams Attributes) in IS modelling. We can also mention M. A. Jackson, the creator of Structure

Diagrams.

ERD show the detailed structure of data stores that are demonstrated in data flow diagrams. Let us first consider the

most important concepts related to ERD.

6.1.1 The concept of entity.

The concept of entity is understood as each object information on which is to be stored in the developed IS.

It must be a distinguishable and identifiable object of reality, e.g. a particular thing, person, object, goods, customer,

building, etc. Attributes of an entity are elements of an entity that are used to describe the properties of an entity.

E.g., the entity “order” might have attributes “number of order”, “item number”, “quantity”, etc. The entity

“employee” may have the attributes “personal number”, “organizational centre”, “income”, “name”, etc. Attribute

values characterize the particular entity, for example, for the employee Novák “2586, the Department of Software

Development, Dalibor Novák, ....”.

Entities having the same attributes (differing only in attribute values) form groups (categories) called sets of

entities. Some attributes or arranged sets of attributes have special significance within the entity to identify the

entity in a given set of entities or for links between entities (different sets of entities). This meaning is related to the

concept of “key”.

Attributes, primary and foreign key

The primary key is an attribute (i.e. an arranged set of attributes), whose value are used to uniquely identify

individual entities.

The primary key must be just one in a given set of entities. For example, in a set of entities “employees”, the

primary key will be the attribute “personal number” if it is unique within all company employees.

A foreign key is an attribute (i.e. an arranged set of attributes) which is in a primary key in a different set of

entities. Foreign key is used to define relationships between entity sets.

The alternative key is an attribute (i.e. an arranged set of attributes), whose values are used to uniquely

identify individual entities, yet this attribute (i.e. an arranged set of attributes) was not elected as the primary key.

The primary key can be only one within a given set of entities. Yet, there may be a different attribute (an

arranged set of attributes) that uniquely identifies the entity. In this case, it is an alternative key. For example, an

employee in a given set of entities is uniquely identified by the attribute “personal identification number”, in

addition to the attribute “personal number”.

An ambiguous key is an attribute (i.e. an arranged set of attributes) that does not uniquely identify the given

entity, but defines it closer, and it is therefore useful for searching and sorting entities according to the specified

characteristics.

If the key consists of one attribute, we talk about a simple key, if the key consists of an arranged set of

attributes, we talk about a composite key.

Bindings in the data model

The data model is also important representation of links (relationships - relations) between sets of entities.

For each relation we determines the level, cardinality, and optionality of the link. We have already come across the

above-mentioned relationship between entity sets “employees” and “workplace”.

The term level of the link is understood as the number of sets of entities linked in the same relation. A set of

entities may be related to itself, then we talk about unary relation.

There can be multiple relations between the two sets of entities. In practice, we usually model cases where

some entity sets have a variety of relationships with other entity sets.

Cardinality relational ties

Another feature of the session is the cardinality (power, multiplicity). The term cardinality is the number of

entities that enter into that relationship.

We distinguish cardinality:

• 1: 1, i.e. one entity (the first set of entities) is tied to one entity of the second set of entities

For example: “employees” 1 possess 1 “employee ID” “employees” “employee ID “

An employee owns only one (just one) employee ID.

• 1: N, i.e. one entity (the first set of entities) is tied with several entities of the second set of entities For example: “employees” 1 possess N “working tools” An employee can generally own more working tools.

• N:1, i.e. more entities (the first set of entities) is tied with a single entity of the second set of entities

For example: “employees” N working 1 “workplace” “employees” “workplace” More employees are working

at one workplace.

• M:N, i.e. more entities (the first set of entities) is tied with several entities of the second set of entities

For example: “employees” M using N “working tools” “employees” “working tools”

An employee is using more working tools, while any tool can be used by more employees simultaneously.

Another example: “authors” M write N “books” More books are registered by the same author, on the

contrary, books written by a team of authors are registered.

Optionality of relational links

Another feature of the relation optionality of a link.

We distinguish:

• optional link, for one occurrence of entity A from the set of entities Ma, there may or may not exist

occurrence of entity B from set of entities Mb.

For example: Use protective equipment “Employee” may or may not use protective equipment. Optional link

is graphically emphasized by an empty circle.

“employees” " « mandatory link, for one occurrence of the entity A from the set of entities Ma, there must

always be at least one occurrence of entity B of the set of entities Mb. Mandatory link will be highlighted with

graphically full circle.

In ERD, we can also capture the relationship of generalization and specialization of entities. In the model,

there may or may not occur entities having common attributes, and entities that also have other special attributes.

Thus, relationships of superior and subordinate entities are formed.

The process of creating a data model

The process of creating a data model will be set in the following points:

1. selecting the most important set of entities (e.g. employee, workplace, cost centre, catalogue of occupations, wage components, etc.);

2. identification of attributes of the individual sets of entities; 3. identification of the primary of the individual sets of entities; 4. finding links (relations) between sets of entities; 5. drawing sets of entities and relationships into ERD; 6. identification of cardinality and optionality of links; 7. removing unnecessary transitive relationships between entities; 8. eliminating of redundant sets of entities and attributes; 9. normalization of the data model; 10. recording limiting conditions for attribute values (integrity constraints); 11. completion of the hierarchy of entity sets (generalization and specialization, parent and child entities); 12. verifying the integrity of data model.

In practice, we proceed in an iterative manner during model creation. Through repeated passages, the model

is gradually made more and more detailed, we complement and refine it. Thus, we elaborate a set of data models

displayed on different levels of distinguishing:

data model on the conceptual level of imaging;

data model on the technological (logical) level of imaging;

data model on the implementation (physical) level of imaging.

On technological and implementation level of imaging, we obtain models called Relation Data Diagram, i.e. a

model of logical data structures and a model of physical data structures.

6.2 NORMAL FORMS IN THE DATA MODEL

During the creation of a data model, we deal with the issue of normalization of the model and the issue of

ensuring data integrity.

The set of entities is in the first normal form if all the attributes are atomic (further indivisible) values.

The set of entities is in the second normal form if it is in first normal form and moreover, each attribute is

dependent on the entire primary key (not only on a part of the key).

The set of entities is in the third normal form if it is in the second normal form and also all non-key attributes

are mutually independent.

Other normal forms (Boyce-Codd normal form, fourth and fifth normal form) serve as special cases. In

practice, data model where all sets of entities are in the third normal form is usually sufficient.

In practice, we sometimes deal with the issue of purpose and application-specific data model

denormalization. The reason for denormalization may be an attempt to improve performance of certain processes

within IS (usually at the expense of other processes). There are ways and techniques of denormalization, techniques

for ensuring the integrity of the denormalised database.

6.3 DATA INTEGRITY

Another area is the issue of data integrity (ensuring the integrity of the database). We distinguish:

integrity of the domain, the data must comply with the specified data type and application rules (business rules - the application logic).

integrity of entities, each entity of the entity set must be clearly identified (using the primary key).

integrity of reference, this means ensuring consistency between sets of entities with links of primary and foreign keys.

Creating a data model is demanding creative work. Poorly treated database design may negatively affect the

performance of the entire information system, and after filling data structures with data, it is very difficult to make

changes to the database design. Usually, you can more easily adjust the calculation algorithm than the structure of

the database. Therefore, in the context of the development team, creating a data model should be entrusted to

experienced database designers.

6.4 DATA DICTIONARY

The purpose of the Data Dictionary (DD) is a description of all system components present in the processed

models. It is a dictionary of all semantic identifiers and the connections between the model elements.

The Data Dictionary is a model in we use the language of verbal description to display the developed IS.

Data Dictionary must contain a description of elements listed in the individual models (data flow, a set of entities,

attributes, relationships, etc.). The description must be clear, comprehensible, must also capture links between the

described elements.

The structure of the element description may be as follows:

unique element identifier;

explanation of the element significance in the developed IS;

description of the composition of the element (from the basic elements);

specifications of format and values that the element may acquire (integrity constraints).

6.5 STATE TRANSITION DIAGRAM

The purpose of the State Transition Diagram (STD) is modelling of time-dependent behaviour of the system.

The State Transition Diagram shows the behaviour of the system and its response to external or internal events.

State Transition Diagrams are particularly important in modelling systems operating in real time (real-time

systems).

State Transition Diagram shows the following types of situations:

state 1 -> event (condition, action) -> state 2.

State Transition Diagram illustrates “what happens if ....”. State Transition Diagram is also called IS

management model, because it shows the system responds to the individual events that are able to influence (direct)

system behaviour.

State Transition Diagram consists of the following major components:

Nodes represent individual states of the system.

Oriented Edges feature state changes, transitions between states.

Event Store is used to store information about past events. The system does not have to respond to the given incident immediately, but after some time, it may react to a particular combination of events, etc.

We graphically represent the state using a circle (diagram node), and transitions between states using the

arrow (oriented diagram edge).

The process of creating State Transition Diagram is as follows:

1. identifying all the states of the system that we differentiate; 2. identifying all possible transitions between states; 3. identifying initial state and end state (states); 4. proceeding from the initial state, we examine the allowable state changes, transitions between states, while

trying to answer the questions:

Is the set of states complete?

Are all states attainable? Is each state accessible?

Is there a transition missing between states in the state diagram?

Can all states (except the final states) be left?

Do the changes in states correspond to all possible events (conditions)? Have not only usual conditions been considered?

It is the given end state actually the final one? Is the system really supposed to stay in such a state? Is not it a case of an analytical error?

During the work on the draft structure of the software system (in the area of structured methods of analysis

and design of IS), we can apply the following techniques:

modular design based on functional decomposition; ¨

modular design based on an analysis of data streams;

modular design based on an analysis of data structures.

In practice, we can use a combination of two partial techniques:

transformational analysis;

transactional analysis.

Transformational analysis consists of deriving SCH from DFD, while we focus on parts of DFD formed by

successive (sequential) processes. Sequential processes gradually transform the input streams to output data

streams, similarly as the transformation of the material takes place on the production line.

Transactional analysis consists of deriving SCH from DFD, while focusing on branching points - on decision-making on

further work process. For example, on the various menus, branching processes according to conditions, etc.

The aim of transactional analysis is to identify DFD processes, which decide where to route the input data flows, or

where to pass process control.

Summary of terms

The purpose of the data model (ERD - Entity Relationship Diagram) to illustrate the structure of the data the

developed IS, i.e. to represent entities, their attributes, and relationships between sets of entities.

ERD show the detailed structure of data stores that are demonstrated in data flow diagrams. Let us first

consider the most important concepts related to ERD.

The concept of entity.

Entities having the same attributes (differing only in attribute values) form groups (categories) called sets of

entities. Some attributes or arranged sets of attributes have special significance within the entity to identify the

entity in a given set of entities or for links between entities (different sets of entities). This meaning is related to the

concept of “key”.

The primary key is an attribute (i.e. an arranged set of attributes), whose value are used to uniquely identify

individual entities.

A foreign key is an attribute (i.e. an arranged set of attributes) which is in a primary key in a different set of

entities. Foreign key is used to define relationships between entity sets.

The alternative key is an attribute (i.e. an arranged set of attributes), whose values are used to uniquely

identify individual entities, yet this attribute (i.e. an arranged set of attributes) was not elected as the primary key.

Bindings in the data model

The data model is also important representation of links (relationships - relations) between sets of entities.

For each relation we determines the level, cardinality, and optionality of the link. We have already come across the

above-mentioned relationship between entity sets “employees” and “workplace”.

We distinguish cardinality:

• 1: 1, i.e. one entity (the first set of entities) is tied to one entity of the second set of entities

• 1: N, i.e. one entity (the first set of entities) is tied with several entities of the second set of entities

• N:1, i.e. more entities (the first set of entities) is tied with a single entity of the second set of entities

• M:N, i.e. more entities (the first set of entities) is tied with several entities of the second set of

entities

The process of creating a data model will be set in the following points:

1. selecting the most important set of entities (e.g. employee, workplace, cost centre, catalogue of

occupations, wage components, etc.);

2. identification of attributes of the individual sets of entities;

3. identification of the primary of the individual sets of entities;

4. finding links (relations) between sets of entities;

5. drawing sets of entities and relationships into ERD;

6. identification of cardinality and optionality of links;

7. removing unnecessary transitive relationships between entities;

8. eliminating of redundant sets of entities and attributes;

9. normalization of the data model;

10. recording limiting conditions for attribute values (integrity constraints);

11. completion of the hierarchy of entity sets (generalization and specialization, parent and child

entities);

12. verifying the integrity of data model.

In practice, we proceed in an iterative manner during model creation. Through repeated passages, the model

is gradually made more and more detailed, we complement and refine it. Thus, we elaborate a set of data models

displayed on different levels of distinguishing:

• data model on the conceptual level of imaging;

• data model on the technological (logical) level of imaging;

• data model on the implementation (physical) level of imaging.

Data Integrity

Another area is the issue of data integrity (ensuring the integrity of the database). We distinguish:

• integrity of the domain, the data must comply with the specified data type and application rules

(business rules - the application logic).

• integrity of entities, each entity of the entity set must be clearly identified (using the primary key).

• integrity of reference, this means ensuring consistency between sets of entities with links of primary

and foreign keys.

State Transition Diagram

The purpose of the State Transition Diagram (STD) is modelling of time-dependent behaviour of the system.

The State Transition Diagram shows the behaviour of the system and its response to external or internal events.

The process of creating State Transition Diagram is as follows:

1. identifying all the states of the system that we differentiate;

2. identifying all possible transitions between states;

3. identifying initial state and end state (states);

4. proceeding from the initial state, we examine the allowable state changes, transitions between

states, while trying to answer the questions:

Transactional analysis consists of deriving SCH from DFD, while focusing on branching points - on decision-

making on further work process. For example, on the various menus, branching processes according to conditions,

etc.

Questions

1. What is the principle of data modelling?

2. Explain the concept of entity, attribute, entity links.

3. Explain the concept of relationship cardinality

4. What is a primary key and what is a foreign key and what role they play in the data model

7 DATA MODELLING

Time to study

40 minutes

Objective

define the meaning and content of data modelling......

describe the principles of component programming

explain the concept of key and to know their types and uses ....

Lecture

This chapter covers the analysis phase in the life cycle of the Information System project called data model

design. Current information systems are designed to store and process large amounts of data. Therefore, when

designing an information system, it is essential to know exactly how the information will be kept and organized.

7.1 FUNDAMENTALS OF CREATING DATA MODELS

The methodologies used divide the view of the data into the logical and physical data model. Logical data

model is independent of the implementation, therefore, it is not necessary to take into account the target

environment, i.e. a specific type of relational database at this stage of the analysis. Logic Model (diagram of entities)

At the beginning of the description of this technique, it is necessary to clarify a few concepts: entity,

attributes, and relationships.

Entity

The definition of this concept is quite difficult - in fact it is a data object. Under this concept, we can imagine

e.g. a certain type of a document used by the given organisation (invoice, employee registration card, or bank

account records, etc.). Entity is described by a noun, and we determine whether it is a type of entity (e.g. entity

Patient) or the occurrence of this entity (“patient number 44 – František Šedý”, etc.). In short, an entity is a grouping

of data that belong together logically and that we examine within the specified analysis.

Attribute

This concept is understood as the items of that entity. E.g. entity Patient will have the attributes patient

number, patient’s name, patient’s address, date of registration, etc. The attributes are determined by their format

and size (e.g. Character 20). In fact, we can say that an entity in the logical design is what a relational table (in

general a file) is in the physical design, and the attribute appears as a column of the table.

Relationship

A relationship defines relationships between entities. There are three types of relationships, namely:

• Relationship type 1:1 An example might be a relationship one worker has one registration cart. This type of relationship of type 1:1 often leads to merging entities, e.g. the registration card is sufficient to identify a worker; the card contains his/her name and it is not necessary to have a list of names of employees in a separate entity.

• Relationship type 1:N. It is the most common type of relationship, and it is characterized by e.g. the relationship “one worker is working on multiple tasks”. The relationship type l:N uses the concept of MASTER for the entity on the “I” side and the concept DETAIL for the entity on the “N” side. Binding is also characterized by the so-called “relationship sentence” that verbally determines the relationship between entities. We use a verb to describe the relationship sentence.

• Relationship type M:N. This relationship can be used only at the beginning of functional and data analysis, and it must later be transferred to the relationship type 1:N When determining the relationships between the entities, we at the same time determine the number of occurrences at the end of each relationship, so called relationship cardinality. It is examined whether e.g. in the relationship between entities Patient - Medical transcription the following states can occur:

1. Does the patient exist separately? 2. Does the prescription exist separately? (i.e. without links to the patient)?

Keys

Each entity has its own attributes. One or more attributes have a more prominent role than other attributes.

Such an attribute is called a key. We distinguish different types of keys:

• The primary key. This type of key must be unique. It means that a certain occurrence of this key must be different from other occurrences of the key to uniquely identify each occurrence of the entity. The primary key may be formed by more attributes together. In this case, we talk about a composite key. If the primary key consists of only one attribute, the term simple key is used.

• Alternative Key. It is the case of one or more attributes that are unique, but were not selected for the primary key. They are possible alternative option to select a primary key.

• Foreign Key. This type of key is an attribute that occurs as the primary key in another entity.

The database is an organized structure of data arranged into tables.

The table is a data structure organized in rows and columns. It is actually a two-dimensional matrix with

named columns and rows containing the data itself.

The line carries the particular information on one occurrence of an entity stored in the database.

The column is the same as the attribute in the logical design, it represents a kind of atomic information.

During the conversion process of the logical data model into a physical database design, we perform normalization

process.

7.2 NORMALIZATION OF DATA MODEL

This technique of editing the data model is used for the following reasons:

• identification of mutual data relationships • association of data to optimum groups • resolving ambiguities • enabling the additional extension of the information system database • creating a common basis of shared data • precise definitions of data items • easy maintenance of data

Data normalization technique is based on precise mathematical rules that are relatively simple, and their use

will separate logical and physical design of the information system. During normalization, the term table is already

introduced, which is determined by its columns and rows. Such a table must have a key (primary or foreign). Before

the normalization technique, tables may contain ambiguities and repeating groups of data.

Questions

1. What does the normalization of the data model mean?

2. What is the primary, foreign, and alternative key?

3. What is the difference between the logical and physical model?

4. What is a database?

Summary of terms

FUNDAMENTALS OF CREATING DATA MODELS

The methodologies used divide the view of the data into the logical and physical data model. Logical data

model is independent of the implementation, therefore, it is not necessary to take into account the target

environment, i.e. a specific type of relational database at this stage of the analysis. Logic Model (diagram of entities)

At the beginning of the description of this technique, it is necessary to clarify a few concepts: entity,

attributes, and relationships.

ENTITY

In short, an entity is a grouping of data that belong together logically and that we examine within the

specified analysis.

Attribute

This concept is understood as the items of that entity. Relationship

A relationship defines relationships between entities. There are three types of relationships, namely:

• Relationship type 1:1.

• Relationship type 1:N.

• Relationship type M:N. This relationship can be used only at the beginning of functional and data

analysis, and it must later be transferred to the relationship type 1:N

• The primary key. This type of key must be unique.

• Alternative Key. It is the case of one or more attributes that are unique, but were not selected for the

primary key.

• Foreign Key. This type of key is an attribute that occurs as the primary key in another entity.

The database is an organized structure of data arranged into tables.

The table is a data structure organized in rows and columns. It is actually a two-dimensional matrix with

named columns and rows containing the data itself.

NORMALIZATION OF DATA MODEL

This technique of editing the data model is used for the following reasons:

• identification of mutual data relationships

• association of data to optimum groups

• resolving ambiguities

• enabling the additional extension of the information system database

• creating a common basis of shared data

• precise definitions of data items

• easy maintenance of data

References

[1] Analýza a návrh informačních systémů [Řepa, 1999] / Václav Řepa. - Vyd. 1.. - Praha : Ekopress, 1999 - 403 s. : il. ISBN 80-86119-13-0 (brož.)

[2] Architektury informačních systémů v průmyslových a obchodních podnicích / Jan Dohnal, Jan Pour. - Vyd. 1.. - Praha : Ekopress, 1997 - 301 s. : il. ISBN 80-86119-02-5 (brož.)

[3] Informační systémy v podnikové praxi [Sodomka, 2010] / Petr Sodomka, Hana Klčová. - 2. aktualiz. a rozš. vyd.. - Brno : Computer Press, 2010 - 501 s. : il. ISBN 978-80-251-2878-7 (váz.)

[4] Informační systémy v podnikové praxi [Sodomka, 2010] / Petr Sodomka, Hana Klčová. - 2. aktualiz. a rozš. vyd.. - Brno : Computer Press, 2010 - 501 s. : il. ISBN 978-80-251-2878-7 (váz.)

[5] Informační systémy v podnikové praxi [Sodomka, 2010] / Petr Sodomka, Hana Klčová. - 2. aktualiz. a rozš.

vyd.. - Brno : Computer Press, 2010 - 501 s. : il. ISBN 978-80-251-2878-7 (váz.)

[6] Inovace podnikových informačních systémů : podpora konkurenceschopnosti podniků / Josef Basl a kolektiv. - 1. vyd.. - Praha : Professional Publishing, 2011 - 150 s. : il. ISBN 978-80-7431-045-4 (váz.)

[7] Podnikové informační systémy : podnik v informační společnosti [Basl, 2008] / Josef Basl, Roman Blažíček. - 2., výrazně přeprac. a rozš. vyd.. - Praha : Grada Publishing, 2008 - 283 s. : il. ISBN 978-80-247-2279-5 (váz.)

[8] Podnikové informační systémy : podnik v informační společnosti [Basl, 2008] / Josef Basl, Roman Blažíček. - 2., výrazně přeprac. a rozš. vyd.. - Praha : Grada Publishing, 2008 - 283 s. : il. ISBN 978-80-247-2279-5 (váz.)

[9] Principy a modely řízení podnikové informatiky / Jiří Voříšek a kolektiv. - Vyd. 1.. - Praha : Oeconomica, 2008 - 446 s. : il. ISBN 978-80-245-1440-6 (brož.)

[10] Projektování informačních systémů I : strukturovaný a objektový přístup / Dušan Kajzar, Ivan Polášek. - Vyd. 1.. - Opava : Slezská univerzita, 2003 - 219 s. : il. ISBN 80-7248-214-9 (brož.)

[11] Tvorba informačních systémů II : proces vývoje informačního systému / Dušan Kajzar. - Vyd. 1.. - Opava : Slezská univerzita, 2005 - 221 s. : il. ISBN 80-7248-288-2 (brož.)

[12] Tvorba WWW stránek pro úplné začátečníky [Broža, 2006] / Petr Broža. - 5. aktualiz. vyd.. - Brno : Computer Press, 2006 dotisk - x, 149 s. : il. ISBN 80-251-1300-0 (brož.)