View
226
Download
0
Category
Preview:
Citation preview
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ž.)
Recommended