2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Database Management of Robot Configuration Data
Magdalena Bozyk1, Fredrik Mannerstedt2
ABB Automation Technology Products
1
mbk99004@student.mdh.se
2
fmt99001@student.mdh.se
Department of Computer Engineering
Mälardalen University
Västerås, April 2002
Supervisor at university: Dag Nyström
Examiner at university: Christer Norström
Supervisors at ABB Automation Technology Products:
Dan Rylander, Håkan Fortell, Anders Lager
1
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Abstract
ABB Automation Technology Products´ system for management of configuration data has today become inefficient.
Due to the increase of robot types the amount of configuration files has increased. Therefore it is difficult to get an
overall picture of the situation.
The main goal of this thesis is to investigate if a commercial database management system can be used. Also how to
extract the stored data. The database management system we chose was Oracle8iTM. To make the database easier to
overview, we used only a part of the configuration data.
Using a ADO (a standard API) we also developed an application from where a user can extract data and create
configuration files. Further more we found tools that simplify development of databases and database applications.
The result of this thesis is that a database with applications made with help of database management system,
development tools and standard APIs is more efficient and easier, than the system ABB Automation Technology
Product uses today.
2
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Sammanfattning
Systemet som idag används på ABB Automation Technology Products för att hantera robotkonfigurationsdata är
ineffektivt. Detta beroende på att det har skett en ökning av antalet robot typer och därmed en ökning av antalet
konfigurationsfiler. Det är därför svårt att få en överblick över situationen.
Det främsta målet med detta examensarbete är att undersöka om ett kommersiellt databasverktyg kan användas.
Samt att undersöka hur datat ska extraheras. Som kommersiellt databasverktyg valde vi Oracle8iTM. För att göra
databasen mer överskådlig använde vi bara en del av robotkonfigurationsdatat.
Genom att använda ADO (ett standard API) utvecklade vi också ett verktyg med vilket en användare kan extrahera
data samt att skapa konfigurationsfiler. Vi hittade även verktyg som kan förenkla utvecklingen av databaser och
databasapplikationer.
Resultatet vi kom fram till var att det är bättre att använda ett kommersiellt databasverktyg, utvecklingsverktyg samt
ett standard API är mer effektivt än det system som idag används på ABB Automation Technology Products.
3
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Preface – Acknowledgement
This degree thesis was done at ABB Automation Technology Products, during the period July 2001 to February
2002, as a part of the education Master of Science at Mälardalen University in Västerås, Sweden. The work was
performed by Magdalena Bozyk and Fredrik Mannerstedt.
We sincerely thank our supervisors Dan Rylander, Håkan Fortell and Anders Lager at ABB Automation Technology
Products and Dag Nyström at The Department for Computer Science and Engineering at Mälardalen University.
4
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Table of Contents
CHAPTER 1 .................................................................................................................................. 7
1
INTRODUCTION ..................................................................................................................... 7
1.1
Background ................................................................................................................. 7
1.2
Purpose........................................................................................................................ 8
CHAPTER 2 .................................................................................................................................. 9
2
AN INTRODUCTION TO DATABASES....................................................................................... 9
2.1
The traditional File-based approach .......................................................................... 9
2.2
The Database approach ............................................................................................ 10
2.3
Database Languages ................................................................................................. 15
2.4
Data Model ................................................................................................................ 15
2.5
Relational Model ....................................................................................................... 18
CHAPTER 3 ................................................................................................................................ 25
3
SQL INTRODUCTION ........................................................................................................... 25
3.1
SQL commands .......................................................................................................... 25
CHAPTER 4 ................................................................................................................................ 32
4
DATABASE DESIGN ............................................................................................................. 32
4.1
Overview of Database Design ................................................................................... 32
4.2
The Entity-Relationship Model.................................................................................. 32
4.3
Normalization ............................................................................................................ 37
4.4
Conceptual Database Design .................................................................................... 44
4.5
Logical Database Design .......................................................................................... 45
4.6
Physical Database Design ........................................................................................ 45
CHAPTER 5 ................................................................................................................................ 47
5
WHAT WE DID ................................................................................................................... 47
5.1
Design of Conceptual Data Model ............................................................................ 47
5.2
Design of Logical Data Model .................................................................................. 48
5.3
Design of Physical Data Model ................................................................................ 50
5.4
Implementation .......................................................................................................... 51
CHAPTER 6 ................................................................................................................................ 52
6
DATABASE CLIENT TECHNOLOGY ...................................................................................... 52
6.1
Embedded SQL .......................................................................................................... 52
6.2
Application Program Interface (API) ....................................................................... 52
6.3
Database Client Technology Summary ..................................................................... 56
CHAPTER 7 ................................................................................................................................ 58
7
ADO OBJECT MODEL ........................................................................................................ 58
7.1
The Connection Object .............................................................................................. 59
7.2
The Command Object ................................................................................................ 59
7.3
The Recordset Object ................................................................................................ 60
7.4
The Record Object ..................................................................................................... 60
5
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
7.5
7.6
7.7
7.8
7.9
The Fields Collection and the Field Object .............................................................. 60
The Parameter Object ............................................................................................... 60
The Properties Collection and the Property Object.................................................. 61
The Errors Collection and the Error Object ............................................................. 61
The Stream Object ..................................................................................................... 61
CHAPTER 8 ................................................................................................................................ 62
8
APPLICATION MANUAL ...................................................................................................... 62
CHAPTER 9 ................................................................................................................................ 65
9
DEVELOPMENT TOOLS ....................................................................................................... 65
9.1
Oracle Developer ...................................................................................................... 65
9.2
Oracle Designer ........................................................................................................ 68
9.3
DeZign for Databases ............................................................................................... 72
CHAPTER 10 .............................................................................................................................. 73
10
CONCLUSIONS ................................................................................................................ 73
REFERENCES ............................................................................................................................ 75
APPENDIXES ............................................................................................................................. 76
APPENDIX A ............................................................................................................................... 77
Entity Descriptions ................................................................................................................ 77
APPENDIX B ............................................................................................................................... 78
Relationship descriptions ...................................................................................................... 78
APPENDIX C ............................................................................................................................... 79
Attribute Descriptions ........................................................................................................... 79
APPENDIX D ............................................................................................................................... 88
Tables created during Design of Conceptual Data Model ................................................... 88
APPENDIX E ............................................................................................................................. 101
Entity-Relationship Diagram .............................................................................................. 101
APPENDIX F.............................................................................................................................. 102
Relvars in DBDL (Database Definition Language) ............................................................ 102
6
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Chapter 1
1
Introduction
This chapter gives a short introduction to the background and purpose of this thesis. Today’s system will also be
described.
1.1
Background
ABB Automation Technology Products´ system for handling of configuration data has today become inefficient.
Due to the increase of robot types, the amount of configuration files has increased. Therefore it is difficult to get an
overall picture of the situation.
1.1.1
Today’s system
ABB Robotics has developed a program to handle the increasing amount of configuration files (cfg-files). These
files are stored in a database. The program creates configuration files and h-files on the basis of 3 file types (see
fig1.1). These are moc.typ, moc.dat, and dat-files. There are approximately 500 dat-files.
*.dat
moc.typ
moc.dat
param_db
*.cfg
*.h
moc.mmcO.cfg
moc.mmcS.cfg
moc_cfg.eng
Figure 1.1. The functionality of the program.
moc.typ contains the structure and the integrity rules of the database. There are three security levels described in
moc.typ. Those are user mode, service mode, and encrypted mode. In user mode the customer has the right to read
and write the data. In service mode the customer can only read the data. The data that is secret to the competitors is
stored in encrypted mode. It is put in different configuration files on the basis of security level.
moc.dat contains information about which dat-files must be used to create configuration files.
All the data in the database is stored in dat-files. There are files with shared data and files with data that is specific
for every robot type.
The database is hierarchical (see chapter 2.4.1) with more than one root. Figure 1.2 shows a part of the database as a
hierarchical tree. A node is a collection of related data. The arrows show the hierarchy and relations between the
nodes and are represented in the database as pointers.
7
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
MECHANICAL_UNIT
ROBOT_TYPE
ROBOT
AXC_FILTER
JOINT
ARM
ARM_TYPE
ACC_DATA
ARM_C_POINT
PAR_ARM_LOAD
Figure 1.2. A part of the database as a hierarchical tree.
There are several disadvantages with today’s system:
 It is difficult to handle the large amount of cfg-files.
 When a configuration file for specific robot is put together, data is read from several different dat-files.
More detailed – some of the data from the previously loaded file is replaced by data from the new file.
 The size of the program and the amount of cfg-files make it hard to get an overall picture of the system.
1.2
Purpose
The main goal of this thesis is to investigate if a commercial database management system can be used, and how to
extract the stored data.
8
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Chapter 2
2
An introduction to databases
Databases are often used in our day-to-day life even we are not aware of using one. A database can be considered to
be a collection of related data and the Database Management System (DBMS) to be the software that manages and
controls accesses to the database. An example, where a database is used is in the supermarket. When the cashier runs
a bar code reader over each of the purchases, a database is accessed to find out its price. At the same time, the
number of such item is reduced in the database. If a customer telephones the supermarket, an assistant can check
whether that item is in the stock by running an application program. Another example is when you are buying a
flight ticket. Before you can buy a ticket, the salesman has to check if there is an unoccupied chair. To do that he
checks in the airline database. Other examples are registry of motor vehicles, register of members in a sports club
and registry of employees at a company. On this collection of related data mentioned earlier a user can, in a
structured way, manipulate the stored information. Such manipulations are made by so-called queries, some
examples are write and delete information, and search for information in the database. The terms “data” and
“information” are treated as synonymous in this report.
2.1
The traditional File-based approach
The definition of a file-based system is:
A collection of application programs that perform services for the end-users such as the production of
reports. Each program defines and manages its own data.
File-based systems were an early attempt to computerize the manual filing system. For example, in an organization a
manual file is set up to hold all external and internal correspondence relating to a project, product, task, client, or
employee. Often, there are many such files, and for safety they are stored in locked cabinets, located in secure places
of the building. Examples of filing systems in our day-to-day life might be receipts, guarantees, bank statements etc.
The manual filing system works well when the number of items to be stored is small. However, the manual filing
system breaks down when we have to cross-reference the information in the files. For example, a typical estate
agent’s office might have a separate file for each property for sale. Consider the effort that would be required to
answer the following questions:



2.1.1
What three-bedroom apartment with a balcony do you have for sale?
Do you have a detached house with sea view and two toilets?
What is the average house price?
Limitations of the file-based approach
Separation and isolation of data
It is difficult to access data when it is isolated in separate files. Suppose we want to produce a list of all houses with
sea view and at least two bedrooms. First we have to make a list of all houses with a sea view, and from that list sort
out all houses with at least two bedrooms.
Duplication of data
Uncontrolled duplication of data is undesirable for several reasons:
 It costs time and money to enter the data more than once. It also takes up additional storage space.
Often the duplication of data can be avoided by sharing data files.
 Duplication of data can lead to loss of integrity; in other words, the data is no longer consistent.
9
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Data dependence
The physical structure and storage of the data files and records are defined in the application code. This means that
changes to an existing structure are difficult. A change might be to increase a field in the file. There are several steps
to go through:
 Open the original file for reading.
 Open a temporary file with the new structure.
 Read a record from the original file, convert the data to conform to the new structure, and write it to the
temporary file. Repeat this step for all records in the original file.
 Delete the original file.
 Rename the temporary file (to the original files name).
 Finally, all programs that access the file must be modified to conform the new file structure. This
characteristic of file-based systems is known as program-data dependence.
2.2
The Database approach
The definition of a database is:
A shared collection of persistent, logically related data (and a description of this data), designed to meet the
information needs of an organization.
A database is a single, large repository of data, which is used simultaneously by many users. By persistent data
means that once the data has been stored in the database it can be removed only by an explicit request to the DBMS,
not as a side effect of some program completing execution.
2.2.1
The Database Management System
The definition of a Database Management System (DBMS) is:
A software system that enables users to define, create, and maintain the database and provides controlled
access to the database.
The DBMS is the software that interacts with the users’ application programs and the database. Its major aim is to
provide users with an abstract view of data, hiding certain details of how data is stored and manipulated. A DBMS
provides often following facilities:
 It allows users to define the database, usually through a Data Definition Language (DDL). The DDL
allows the users to specify the data types and structures, and the constraints on the data to be stored in
the database.
 It allows users to manipulate the stored data through a Data Manipulation Language (DML). There are
two types of DML, procedural and non-procedural. The main difference is that procedural language
specifies how the output of a DML statement is to be obtained, while a non-procedural language
describes only what data is to be obtained. The most common non-procedural language is Structured
Query Language (SQL).
 It provides controlled access to the database. Among others, it prevents an unauthorized person from
accessing the database. It also maintains the consistency of the stored data and allows shared access to
the database.
Examples of some famous DBMS are, DB2 from IBM, Informix, INGRES from Inprise and finally Microsoft
SQL Server, MySQL and Oracle.
A DBMS environment consists of five major components: hardware, software, data, procedure, and people, as
illustrated in figure 2.1.
10
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Data
Hardware
Software
Procedures
People
Figure 2.1. DBMS’s environment.
Hardware
To be able to run the DBMS requires hardware. The parts at least needed are: a client and a server and finally, the
database itself, as shown in figure 2.2, the database, is where the information is stored, while it is in the server that
the DBMS-environment is. The client, which is an ordinary personal computer, is where the user is. An ordinary
way to design the system is to use the so-called client-server architecture. This consists of a number of personal
computers (the clients), connected to a central computer (the server). The server runs the back-end of the DBMS,
that is, the part of the DBMS that manages and controls access to the database. The clients run the front-end of the
DBMS, that is, the part that interfaces with the users.
Client 2
Client 3
Client 1
LAN
Requests for data
Selected data returned
Server
with DBMS
Database
Figure 2.3. Client-server artchitecture
Software
The software component consists of the DBMS software itself and the application programs, together with the
operating system and the network software, if the DBMS is being used over a network. This component is the
software layer between the physical database and the user. All queries from the user are handled here.
Data
Perhaps the most important component of the DBMS is the data. In figure 3 we can se that the data acts as a bridge
between the machine components and the human components. The structure of the database is called a schema,
where a schema contains of many tables.
11
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Procedures
Procedures refer to the instructions and rules that govern the design and the use of the database. The users of the
system and the staff that manage the database require documented procedures on how to use or run the system.
These may consist of instructions on how to:
 Start, stop, and log on to the DBMS.
 Make backup copies of the database.
 Use a particular DBMS facility or application program.
 Handle hardware and software failures. For example identify and fix the failed component and how to
recover the database.
 Change the structure of the table, reorganize the database across multiple disks, improve performance, or
archive data to secondary storage.
People
There are three different types of users:
 Starting with the programmer, he is responsible for programming the database application. Common
programming languages are COBOL, PL/I, C++, Java or another high-level language. The database is
accessed by SQL-query that is sent to the DBMS. It can either be an on- or off-line database. An online
database can be accessed through a computer or terminal connected to the network.
 The second type of user is the “end user” (the ordinary user). He can through a computer or terminal
connected to the network access the database. To read information from the database, the user can send a
query to the database. One example on an often-used query-language is SQL (Structured Query
Language). Some of the SQL-commands, that can be used to manipulate the database are SELECT and
INSERT. Instead of learning all the SQL commands, the user can use a graphical tool to manipulate the
database. Some of the tools are Oracle and Access. Generally, the graphical tools have worse
performance, but the advantage is that they are easy to learn for beginners.
 Finally, there is the Data-Administrator (DA) and the Database-Administrator (DBA). It is the DA´s
task to decide what to store in the database and it is the DBA’s task to implement what the DA has
decided.
2.2.2
Advantages of database management systems
Control of data redundancy
A traditional file-based system wastes space by storing the same information in more than one file. In contrast, the
database approach attempts to eliminate the redundancy by integrating the files so that several copies of the same
data are not stored. However, the redundancy is not entirely eliminated. Sometimes it is necessary to duplicate data
items to improve performance or key data to model relationship.
Data consistency
Eliminating or controlling redundancy reduces the risk of inconsistency. If a data item is stored only once in the
database, any update to its value has to be performed only once and the new value is immediately available to all
users.
Sharing of data
In a file-based system, the files are owned by the people and department using them. In a database system the
database belongs to the entire organization and is shared by all authorized users. In this way, more users share more
of the data. Furthermore, new applications can rely on functions provided by the DBMS.
Increased concurrency
In some file-based systems, if two or more users are allowed to access the same file simultaneously, it is possible
that the accesses will interfere with each other. If so, the result will be loss of information or even loss of integrity.
Many of today’s DBMS’s can prevent such problems from occurring.
12
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
2.2.3
Disadvantages of database management systems
Complexity
The functionality we expect from a database makes the DBMS extremely complex. To fully take advantage of the
database, everyone working with the database (the database designers and developers, the data and database
administrators and the end-users) must understand its functionality. Failure to do so can lead to bad design
decisions, which can have serious consequences for an organization.
Size and additional hardware costs
The complexity and breadth of functionality makes the DBMS extremely large. It is occupying many megabytes of
disk space and requiring substantial amounts of memory to run efficiently. As a consequence additional disc storage
might be needed. Furthermore, to achieve the required performance it may be necessary to purchase a larger
machine, or even a larger machine dedicated to running the DBMS.
Higher impact of a failure
The centralization of recourses increases the vulnerability of the system. Since all users and applications rely on the
availability of the DBMS, the failure of any component can bring operations to halt.
Performance
Since a file-based system is written for a specific application, its performance is generally very good. However, the
DBMS is written to be more general to serve many applications instead of just one. The effect is that some
applications may run slower with DBMS than with a file-based system.
2.2.4
Functions in a DBMS
In this section we will look at some of the functions and services we can expect to be provided by a database
management system.
1
Data storage, retrieval and update
A database’s fundamental function is to provide the user the ability to store, retrieve, and update data
in the database. The DBMS should hide the internal physical implementation details (such as file
organization and storage structure) from the user.
2
A user-accessible catalog
A DBMS must provide the user with a catalog in which descriptions of data items are stored.
3
Transaction support
A transaction is a series of actions, carried out by a single user or an application program, which
accesses or changes the contents of the database. For example, suppose that you want to transfer
money from one bank account (A) to another bank account (B). A transaction like that consists of two
actions. First the money will be withdrawn from bank account A, and then they will be depositing on
bank account B. Both, or none of these two actions must be executed. Otherwise, the total sum on the
both accounts will be incorrect and the database will be in an inconsistent state (some changes have
been made and others not). Consequently, the changes that have been made will have to be undone in
order to return to a consistent state again.
4
Concurrency control service
One major benefit in using DBMS is that several users can access the shared data at the same time.
Concurrent access is relatively easy if all of the users are only allowed to read information from the
database. However, when two or more users are accessing the database simultaneously and at least one
of them is updating data, there may be interference that may result in inconsistencies. In table 2.1, T1
and T2 are two transactions executing concurrently.
13
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Time
1
2
3
4
T1
read(X)
x = x – 10
write(X)
T2
read(x)
x = x + 100
write(X)
X
100
100
200
90
Table 2.1. The Lost Update Problem.
The final balance would be £190 if T1 and T2 were executed one after the other, regardless of which
was performed first. T1 and T2 start at nearly the same time and both read the balance as £100. T2
increases X by £100 to £200 and stores (write) the update in the database. Meanwhile, T1 decrements
its copy X by £10 to £90 and stores this value in the database, overwriting the previous update and
there by “loosing” £100. The DBMS must ensure that interference can not occur when multiple users
are accessing the database.
5
Recovery services
We mentioned earlier that if a transaction fails, the database has to be returned to a consistent state.
This may be as a result of a system crash, media failure, a hardware or software error causing the
DBMS to stop, or it may be a result of the user detecting an error during the transaction and aborting
the transaction before it completes. In all cases, the DBMS must provide a mechanism to recover the
database to a consistent state.
6
Authorization services
Security is an important term when it comes to databases. It is common that we want to protect the
information stored in the database from being seen by all users.
7
Support for data communication
Most users access the database from terminals. These terminals can either be connected directly to the
computer hosting the DBMS or connected to computers hosting the DBMS over a network. In both
cases, the DBMS receives requests as communication messages and respond in a similar way. All such
transmissions are handled by a Data Communication Manager (DCM). Although the DCM is not a part
of the DBMS, it is necessary for the DBMS to be capable of being integrated with a variety of DMCs,
if the system is to be commercially viable. The same principle works for personal computers, so that
one centralized database can be established for many users to share.
8
Integrity services
Database integrity is related to security. It is concerned with correctness, consistency and quality of the
stored data. Integrity is expressed as constraints and rules for both the data in the database and the
changes to the data. The DBMS ensures that the integrity rules and constraints are followed.
9
Services to promote data independence
The DBMS must have ability to hide the actual structure of the database from users and applications. It
is easy to provide physical data independence. Changes to the type of physical storage of the database
are easy to hide from the users. It is, however, difficult to hide from users the changes to the logical
structure of the database. Additions to the structure are possible to hide, but not removals. Some
DBMSs do not allow any changes to the logical structure of the database.
14
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
10 Utility services
The DBMS should provide utility services, which help the DBA to effectively take care of the
database. Some utilities can be produced by the DBA, or provided by a third party. Other utilities,
which really work at the physical representation of the database, can only be provided by the vendor of
the DBMS. The DBMS utilities are:
 Import and export routines that load, unload and reload the database to and from files.
 Reorganization routines that rearrange the data in the stored database for various reasons.
 Statistical analysis programs that collect and analyze the statistics about the database performance,
as file sizes, I/O counts, etc.
 Monitoring routines that monitor database usage and operation.
 Garbage collection that releases and reallocates space from files, when needed.
2.3
Database Languages
A data sublanguage consists of two parts: a Data Definition Language (DDL) and a Data Manipulation
Language (DML). The DDL is used to specify the database schema and the DML is used to both read and update
the database.
2.3.1
The Data Definition Language
The database schema 1 is specified by a set of definitions expressed by means of a special language called Data
Definition Language. The DDL is used to define a schema or to modify an existing one. It allows the DBA or user to
describe and name the entities, attributes, and relationships required for the application, together with any associated
integrity and security constraints. It cannot be used to manipulate data.
2.3.2
The Data Manipulation Language
Data manipulation operations usually include the following:

Insertion of new data into the database.

Modification of data stored in the database.

Retrieval of data contained in the database.

Deletion of data from the database.
To do perform these operations, the Data Manipulation Language is used. There are two different types of DML:
procedural and non-procedural. The main difference between these two languages is that non-procedural
languages describe what output is to be obtained while the procedural languages specify how the output of a DML
statement is to be obtained. The most common non-procedural language is Structured Query Language (SQL).
2.4
Data Model
The data model is a definition of how a database is built. There are in principle two types of databases. There are
relational databases and non-relational databases. Historically there were only non-relational databases, such as
hierarchical and network databases. In the seventies the relational model was developed and today it is the most
used model. Object-oriented high-level languages have given an idea to object databases, which some people regard
to be a serious competitor to relational databases. More recently, object/relational systems (systems that integrate
object and relational technologies) have started to appear.
1
The overall description of a database is called database schema.
15
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
2.4.1
Hierarchical Data Model
Thirty years ago, the most spread way of data management was the hierarchical model. The reason why many
enterprises choused this model was that it seemed to be the most natural way of object classification. The idea
behind the hierarchical model is that the information in the database can be adjusted to its application. This way of
thinking can be applied in many cases, but the whole concept looses its meaning if the same information is to be
used in some other way. The other reason behind this model is that, thirty years ago, the only available storage
medium was the magnetic tape, where the data had to be stored in some chronological order. In the seventies the
need for the chronological order disappeared, when the magnetic disk with random access was introduced.
The structure of the hierarchical model follows the general tree structure with one root node and several, or no child
nodes (see fig. 2.3).
Root Node
(Parent)
Line
Root of Subtree
Child Nodes
Siblings
Subtree
Figure 2.3. General tree structure
Every node represents an object of interest and can be represented of a structure (record) type. The object of interest
may be of the same type; but this is not necessary. The lines and the order of the nodes represent the relationships
(connections) between the objects of interest. This is usually represented as pointers (or addresses) embedded in
every structure type, or by the physical order between the structures. The nodes can be linked in three different
ways:
 From parent to child
 From child to parent
 From sibling to sibling
The data is accessed by pre-order (top-down) traversing or by post-order (bottom-up). This way it is easy to access
individual nodes within the tree structure.
The hierarchical model is a post-hoc model, which means that the model was developed after the data was managed
in this way for a while. There is no standard, either for the architecture or the language syntax (the arrangement
between the sentences), because no formal organization was ever established for this purpose.
Advantages
The biggest advantage with this type of database is that it is easy to grasp by the users, because the hierarchy is
based on the purpose of the database. Another advantage is that it is easy to make sure that there are no pointers that
do not point anywhere, because all the structures depend on the existence of other structures.
16
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Disadvantages
One disadvantage is that it is not possible to store a structure that does not have any existing parent structure. This
problem has often been evaded by creating dummy parent structures. Another disadvantage with this model is that it
only can handle the relationships one-to-one and one-to-many. Relationships such as many-to-many and complex,
no-hierarchical relationships are handled by ad hoc2 methods, which do not follow the hierarchical model. The third
disadvantage is that the whole database must be reorganized when the use of it is changed.
2.4.2
Relational Model
In the paper A relational model of data for large shared data banks (1970), E. F. Codd introduced the relational
model. Codd’s goal with the model was:
 Introducing high level of data independence. Applications should not be influenced by changes in the
internal data representation. Further more, the internal data representation should not be influenced by
the applications.
 Supplying the base for dealing with data semantics 3, consistency and redundancy.
 To enable expansion of set-oriented data manipulation languages (operators and results are whole
tables).
Commercial systems based on the relational model started to appear in the late 1970s and early 1980s. Now, the
relational database systems are the most used by the industry and the academic world. The reason is that the
principles of the relational model are very easy to understand (though the description of them may seem
complicated).
According to the relational model, the data is shown as rows in tables and every row can be seen as true
propositions4. Operations on the data create new true propositions from the existing propositions.
The reason to why database that only contains tables is called relational is that a relation is a mathematical term for a
table. Some other terms are:
 Tuple – row
 Attribute – column
 Relation variable (relvar) – name and structure of the table
 Relation value – relation (table)
 Primary key – values in one column that is unique for every row.
 Foreign key – value that references to a primary key in other table.
The relational model is defined by three aspects (which will be described in next chapters):
 Structural aspect: Data in the database is perceived by the users as tables and nothing but tables.
 Integrity aspect: The tables satisfy certain integrity rules.
 Manipulative aspect: Operators available to the user for manipulating the tables, derive tables from
tables.
Every relation value contains a heading (a set of column-names) and a set of rows (a body) that matches the
heading. The heading denotes a predicate (a template for how every row is to be interpreted). In the case of EMP in
fig. 2.4 the predicate could be
Employee EMP# is named FIRST_NAME LAST_NAME and works in department DEPT.
Every row in the table contains a true proposition that is a result of heading’s predicate and values in every
corresponding column:
Employee E3 is named Håkan Fortell and works in department DMF.
2
(made or happening) only for a particular purpose or need, not planned in advance
meaning and purpose of data
4
In logic, proposition is a sentence that evaluates to either true or false. A true proposition always evaluates to true.
3
17
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Foreign
Key
Primary
Key
DEPT
Relvar
EMP
DNAME
RESPONSIBILITY
MANAGER
DMF
DMC
DMA
Motion Functions
Motion Control
Application Process
E4
E5
E1
EMP#
E1
E2
E3
E4
E5
E6
FIRST_NAME
Lennart
Christer
Håkan
Dan
Jesper
Anders
Primary
Key
Attribute
PARENT
DEPT
DM
DM
DM
LAST_NAME
Sundstedt
Norström
Fortell
Rylander
Bergsjö
Lager
DEPT
DMA
DM
DMF
DMF
DMC
DMF
Relation
Tuple
Foreign Key
Figure 2.4. Some Terms in Relational Model.
The most important advantage of the relational model is that it is based on logic and mathematics, which makes it
consistent and defined without flaws. Because of this feature the relational model is used as base for teaching
students. This can be seen as a cause for the widespread use of the model. Another advantage is that the way a user
perceives the database does not have to be the same as the physical design of it. This creates the possibility of
different users using and perceiving the database in different ways. The third advantage of this model is that the
database is scaleable and independent of the applications. This gives the database the possibility to grow and
change, and also to be used by new applications.
A big disadvantage of the model is that it is very theoretical and hence hard to put to practice. Therefore most of the
relational DBMSs are only more or less based on the relational model. The fact that the relational model is abstract
may also be viewed as a disadvantage. It can be very difficult to translate reality to tables. It may even be
unnecessary to work on such an abstract level, if the database is only to be used in one way.
2.5
Relational Model
2.5.1
Structure
Terms
The relational model is composed of three parts that manage the structure, integrity and manipulation of data. Every
part has its own terms. The most important terms that concern the structure are shown in figure 2.5.
If we see a relation as a table, a tuple will be then a row and an attribute a column. The number of tuples is called
cardinality and the number of attributes is called degree. The primary key is a value that is used for indexing tuples.
Finally, a domain is a set of all possible values that an attribute in some relation may have.
18
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Domains
DMF,
DMC, DCS
Relvar
Tuples
Cardinality
DEPARTMENT
DNAME
DMF
DMC
DMA
NAME
Primary
Key
Relation
EMP_AMOUNT
EMP_AMOUNT
12
14
8
MANAGER
E4
E5
E1
EMP#
Attribute
Degree
Figure 2.5. Structural Terminology
Domains
Domains are actually data types, more generally user-defined data types, but may also be simple system-defined
data types. System-defined data types are supplied by the system in use (in this place the DBMS). Those may be
integer, character, float (decimals and huge numbers), etc. The user defines his data types, by indicating what name
the data type should have, and how it should be represented (what system-defined data type should be used). The
reason why the domains should be user-defined data types is that the physical representation should be hidden from
users. Many DBMSs do not supply this possibility, which causes the user to know how the data is represented. In
this case the EMP_AMOUNT in figure 2.5 will be of the domain of integer.
The domain is not only defined through its data type, but also through the definition of which values are acceptable
for the domain and what operations may be performed on these values. For example, 20 and 30 are acceptable
values for EMP_AMOUNT, but –10 and 3.5 are not.
Important rules to remember are:
 Every attribute has a unique name.
 All values are of some data type.
 All values in an attribute are from the same domain.
Relation Values
It is important to understand the difference between relations and relvars. We can view relvars as variables and
relations as values the relvars may have. There is also a difference between a relation and a table. Relation is an
abstract object and table is a way of representing it. In the tabular representation of a relation, we can see that it
contains a heading and a body, as we stated in previous chapter. The heading is a set of pairs (column-name,
column-type), but the column-type is usually omitted.
Important rules for a given relation are:
 Every tuple is unique
 Tuples are unordered (even if they look ordered in the tabular representation)
 Attributes are unordered
 Every tuple has exactly one value for each attribute
19
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Views
There are two types of relation variables, base relvars and views (virtual relvars). The difference between them is
that the base relvars “really” exist, which means that they represent data that is in the database. Views do not
“really” exist; they supply other ways of perceiving the “real data”. They are created by the database administrator
or by the user himself, using some queries on one or more relations (base and virtual). When the underlying data
changes the views change accordingly, and vice versa.
There are four strong reasons why views exist:
 Views provide security for hidden data. Forcing a user to access the database through views stops him
from seeing and accessing sensitive data.
 Views allow different users to use and see data in different ways at the same time. The users can
effectively work on the portion of the database that is of concern to them and ignore the rest.
 Views provide shorthand for queries. It allows the user to create a view and work on it, instead of
repeating the same operations in every query.
 Views provide logical data independence. If the changes in the structure of the database do not concern
a user, they can be hidden from him.
The database that a user sees may include both base relvars and views. The user may not know which relvars are
base and which are virtual. It follows that there should not be any distinctions between base and virtual relvars.
View support is difficult to implement and one of the difficulties is view updating. What updates should be applied
to what underlying base relvars in order to implement the original view update? The update problem has been the
subject of considerable research and many different approaches have been proposed to its solution. The other
difficulty is not having a distinction between views and base relvars.
SQL /92 support views, but views are distinct from base relvars in the way that the support for view updating is very
limited. The view is updateable if and only if:
 Duplicate rows are not to be eliminated from the query result.
 The definition of elements that are to be showed in the result of the query should contain attributes
(column names) and not constants, expressions, or aggregate functions. And no column name appears
more than once.
 The view must have a single table as a source. And if that table itself is a view it has to satisfy this
condition too. Furthermore the user has to have the required privileges for the source base relvar.
 The query should not have nested subqueries that reference to the same view as the head query.
 The result of the query should not be grouped.
 The row that is added through the view may not violate the integrity constraints of the base table (i.e.,
when a new row is added, the attributes that are not included in the view must be set to null, but this
must not violate the “not null” integrity constraint of the base table).
2.5.2
Integrity
Integrity refers to the accuracy or correctness of data in the database. There are two types of constraints in the
relational database:
 State constraints – specify the correct states of a given database.
 Transition constraints – specify the legal transitions from a given state to another.
We can also see keys as a type of integrity rules. But the first topic here will be nulls.
Nulls and The Missing Information Problem
Null is often used as the logical value “unknown”. In fact it is not a value but represents the absence of a value. In
the database it can mean that a value cannot be applied to a particular tuple. It can also mean that the value has not
been supplied. Nulls cause problems in the relational model, which is based on predicate calculus. The predicate
calculus is two-valued – it has only the values true and false. Allowing nulls in the model forces us to use highervalued logic (with the value don’t know), which in the end causes anomalies in the database. Some scientists say
that this problem, called Missing Information Problem, is not fully understood and therefore should not be added to
the relational model. Others say that the problem exists and that we need a solution now.
20
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Though there is a discussion whether null is part of the relational model or not, all of the commercial DBMSs
support nulls. Therefore we choose to treat nulls as if they where part of the relational model.
State Constraints
State constraints guarantee that the database is in a correct state at any given time. There are several different types
of state constraints:
 Type constraints – specify the legal values of a given type;
 Attribute constraints – specify the legal values for a given attribute;
 Relvar constraints – specify the legal values for a given relvar;
 Database constraints – specify the legal values for a given database;
A type constraint is just an enumeration of the legal values of the type. It should be checked during the selection of
some value.
An attribute constraint is part of the definition of the attribute in question. Any attempt to introduce an attribute
value that is not of the relevant type, should be rejected from the database.
A relvar constraint is a constraint on an individual relvar. It should be checked as part of the execution of any
operation that might cause the constraint to be violated.
A database constraint interrelates to two or more relvars. In general, database constraints checking cannot be done
immediately, but must be deferred to end-of-transaction time (COMMIT time). If the database constraint is violated
at COMMIT time, the transaction is rolled back.
Transition Constraints
The state constraints do not address the fact, that some transitions are not correct although they start at a correct state
and result in another correct state. Therefore there should exist transition constraints that take care of that problem.
For better understanding of the problem we illustrate it with an example. A database concerning people might have
series of transition constraints having to do with changes of marital status.
Valid transitions in that database could be:
 never married to married
 married to widowed
 married to divorced
 widowed to married
Non-valid transactions in that database would be:
 never married to widowed
 never married to divorced
 widowed to divorced
 divorced to widowed
Candidate Keys
Candidate keys have a property called uniqueness property. It means that attributes that are included in the primary
key have no two tuples that are duplicates of one another. The only way of pinpointing some specific tuple is by
some candidate key value; therefore they should not include attributes that are irrelevant for this purpose. This is the
other property of a candidate key – the irreducibility property. It means that no proper subset of the candidate key
may have the uniqueness property.
Primary key is a candidate key, which is used to reference a specific tuple. If a relvar has more than one candidate
key, the keys, which are not the primary key, are called alternate keys. The primary key should be:
 The candidate key with the minimal set of attributes;
 The candidate key that is less likely to have its values changed;
 The candidate key that is less likely to lose uniqueness in the future.
 The candidate key with fewest characters (for those with textual attributes(s));
 The candidate key that is easiest to use from the users’ point of view.
21
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Along with the primary key concept, the model has historically included a rule called entity integrity rule. This rule
says that the primary key of a base relvar is not allowed to accept nulls. The problem with this rule is that it is only
restricted to primary keys and base relvars. Using nulls in alternate keys and in all candidate keys in views lead to
oddities that break the rules of the relational model.
Foreign Keys
A foreign key is a set of attributes of one relvar whose values are required to match values of some candidate key of
some other relvar. This is known as referential constraint. Along with this constraint, the relational model includes
the rule, called referential integrity rule, that the database must not contain any unmatched foreign key values. The
term unmatched key value means a (non-null) foreign key value in some referencing relvar for which there does not
exist a matching value of the relevant referenced relvar.
To fulfill this constraint we cannot freely update the database. If we delete a tuple, which is referenced by a foreign
key in another relvar, we break the referential integrity rule. The solution to this problem is called referential
actions. They should be declared with the foreign key declaration, when declaring a relvar. The declaration states,
which referential action should be done after each update action. These actions are:
 Cascade – means that an update or delete action on a relvar should “cascade” through matching tuples
in (other) relvars.
 Restrict – means that an update action should not go through if the relvar has matching tuples in
(other) relvars.
 No action – means that an update action is performed exactly as requested. This action does not solve
the problem at all.
 Set null – means that the foreign key should be set to null, when executing an update action, if the
relvar has matching tuples in (other) relvars.
 Set default – the same as set null, but the foreign key should be set to the defined default value instead
of null.
Which action is to be used, depends on the situation. When a tuple in one relation is existence-dependant on tuple in
second relation, than update (deletion) of a tuple in the second relation should result in cascade-action. Suppose that
we have two relvars: EMPLOYEES that contain information of all employees and PROGRAMMERS that contain
information about programmers. When an employee resigns he has to be erased from the EMPLOYEES-relation. If
he happens to be a programmer, the tuple in the PROGRAMMER-relation has to be deleted too.
When a tuple in one relation is not existence-dependant on tuple in the second relation, we have two choices. For
example, if we also have a relation called PROJECT, which contain information about projects and foreign key
referencing to the employee that is the manager of the project. When the manager resins and the company do not
want to quit the project, the action used could be “set default/null”. Set default can be implemented by assigning the
former project manager’s boss
2.5.3
Data manipulation
The manipulative part of the relational model shows which operations the users are allowed to use on the data.
These operations include updating, retrieving of data and changing the structure of the database.
Programming languages that are used by the commercial systems in purpose of manipulating of data can be divided
into

procedural, which means that the user shows the system how the data should be manipulated;

Non-procedural, which means that the user shows the system only what data and what manipulation is
needed.
The relational model includes the base for these languages. The base is relational calculus and relational algebra.
They are formal structures and they are not user-friendly, but they include all the basic operations for the data. They
exist as the base for development of programming languages and are used for comparison of such.
The relational algebra can be seen as procedural language, because it shows how the DBMS should create new
relations from old ones. The relational calculus can instead be seen as non-procedural language, because it is used to
define a new relation in terms of already existing relations. Shortly, the relational calculus shows what the problem
22
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
is and the relational algebra shows how to solve the problem. The relational algebra and the relational calculus are
equivalent to each other, which means that every operation that we can do with the relational algebra can be done
with the relational calculus.
Relational calculus
The relational calculus is based on the branch of mathematical logic that is called the predicate calculus. There are
two types of the relational calculus. One is tuple-oriented and the other is domain-oriented. The tuple-oriented
calculus manipulates whole relations and the domain-oriented manipulates domains. There exists only one tupleoriented calculus, however there are several, domain-oriented types of calculus.
Relational algebra
The relational algebra created by Codd is called the original algebra. It consists of eight operators (see fig. 2.6).
They can be divided into two groups with four operators in each:
 traditional set operators: union, intersection, difference and Cartesian product;
 special relational operators: restrict, project, join and divide;
Restrict returns a relation containing all tuples from a specified relation that satisfy a specified condition. We can
call the result for a “horizontal” subset of a given relation.
Project returns a relation containing all (sub)tuples that remain in a specified relation after specified attributes have
been removed. We can call the result for “vertical” subset of the given relation.
Product returns a relation containing all possible tuples that are a combination of two tuples, one from each of two
specified relations.
Union returns a relation containing all tuples that appear in either or both of two specified relations.
Intersect returns a relation containing all tuples that appear in both of two specified relations.
Difference returns a relation containing all tuples that appear in the first and not the second of two specified
relations.
Join returns a relation containing all possible tuples that are a combination of two tuples, one from each of two
specified relations, such that the two tuples contributing to any given combination have a common value for the
common attributes of the two relations (and that common value appears jus once, not twice, in the result tuple).
Divide takes two unary relations and one binary relation and returns a relation containing all tuples from one unary
relation that appear in the binary relation matched with all tuples in the other unary relation.
Since Codd defined the original algebra, numerous writers have proposed new algebraic operators but all of them
can be defined with the eight operators from the original algebra. The original algebra is not a minimal set either.
The three operators join, intersect, and divide can be defined in terms of the other five.
23
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Restrict
Product
Project
a
x
a x
b
y
a y
c
b x
b y
c x
c y
Union
Intersection
Difference
Join
Divide
a1
b1
b1
c1
a1
b1
c1
a
a
x
x
a2
b2
b2
c2
a2
b2
c2
b
a
y
z
a3
b3
b3
c3
a3
b3
c3
c
a
z
b
x
c
y
a
Figure 2.6 The Original Eight Operators
24
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Chapter 3
3
SQL introduction
SQL is the common generic language for querying a relational database. However each flavor of database (Informix,
Oracle, MS Access…) has it's own special version of the language. For the most part, they are similar, but there are
some subtle differences that will become apparent as “Syntax Errors” when you try a command from one database
in the environment of another.
Instead of having many different standards for querying a database, a universal foundation for updating, creating and
extracting data from a database was created. This standard, called Structured Query Language (SQL), was
developed in the late 1970’s at an IBM laboratory in San Jose, California, and is often referred to as "sequel”. It was
originally developed for IBM's DB2 product (a relational database management system, which is still used). Thanks
to this foundation, database programmers did not have to understand the specifics of how data is physically stored in
each database management system. To update a database before SQL was invented a programmer would have to
understand how data was physically stored for example the number of bytes in a record, stop tags etc. This made it
difficult to port if the underlying database system was changed. It required a lot more coding as well.
An SQL query is not necessarily a question to the database. It can be a command to do one of the following:




Build or delete a table.
Insert, modify, or delete rows or fields.
Search several tables for specific information and return the results in a specific order.
Modify security information.
3.1
SQL commands
The examples used in this chapter were generated using Oracle8i.
For the examples in this chapter, the table below has been used.
EmployeeIdNo
005
034
059
081
097
118
FirstName
Mary
Joe
Patricia
Bill
Sam
Sarah
LastName
Scott
Smith
Lawson
Jones
Jones
Ackerman
Salary
74,000,
63,000,
48,000,
42,000,
36,000,
32,000,
Position
Manger
Manager
Staff
Staff
Entry-level
Entry-level
Table 3.1. EmployeeTable.
25
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Command termination
All commands are terminated by a semicolon (;). New line is ignored and hence a command may be entered over
several lines.
Command line
The usual prompt is “SQL>” when the SQL client is expecting a new command. If a command is being entered
over multiple lines the prompt becomes “ “ until a semicolon terminates the command.
Select and from
The SELECT and FROM commando is the most frequently used statement. It lists the selected columns in the
selected tables. To select all employees, the syntax is:
SELECT FirstName, LastName
FROM EmployeeTable;
To get all columns of a table without typing all column names, use:
SELECT * FROM EmployeeTable;
Where
Using just SELECT and FROM, you are limited to returning every chosen row in the table, se example above.
Using these two key words on the “EmployeeTable” table, you get all three rows.
With WHERE in your vocabulary, you can be more selective. The WHERE clause returns the instances in the
table that meet the required condition. To find the first and last name of the employee with employee id number
5, write:
SELECT FirstName, LastName
FROM EmployeeTable
WHERE EmployeeIdNo = 5;
The result will be:
Mary Scott
The WHERE description in the example above, EmployeeIdNo = 5, is known as a condition (an operation which
evaluates to True or False). The same can be done for text columns:
SELECT EmployeeIdNo
FROM EmployeeTable
WHERE POSITION = ‘Manager’;
This displays the ID Numbers of all Managers (thus 5 and 34). Generally, with text columns, stick to equal to or
not equal to, and make sure that any text that appears in the statement is surrounded by single quotes (').
After SELECT and FROM, WHERE is the third most frequently used SQL term.
Relational Operators
There are six Relational Operators in SQL, these are:
=
<> or != (see manual)
<
>
<=
>=
Equal
Not Equal
Less Than
Greater Than
Less Than or Equal To
Greater Than or Equal To
Table 3.2. Relational operators.
26
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
3.1.1
Inequalities
When you need to find everything except for certain data, use the inequality symbol, which can be either <> or
!=, depending on your SQL implementation. For example, to find everyone who is not a manager, type this:
SELECT *
FROM EmployeeTable
WHERE Position != ‘Manager’;
And & Or
The AND operator joins two or more conditions, and displays a row only if that row's data satisfies ALL
conditions listed (i.e. all conditions hold true). For example, to display all managers making over $70,000, use:
SELECT EmployeeIdNo
FROM EmployeeTable
WHERE Salary > 70000 AND Position = 'Manager';
The OR operator joins two or more conditions, but returns a row if any of the conditions listed hold true.
In & Between
An easier way of using compound conditions uses In or Between. For example, if you wanted to list all managers
and staff:
SELECT FirstName, LastName
FROM EmployeeTable
WHERE Position IN (‘Manager’, ‘Staff’);
Or to list those making greater than or equal to $30,000, but less than or equal to $50,000, use:
SELECT FirstName, LastName
FROM EmployeeTable
WHERE Salary BETWEEN 30000 AND 50000;
To list everyone not in this range, try:
SELECT FirstName, LastName
FROM EmployeeTable
WHERE Salary NOT BETWEEN 30000 AND 50000;
Similarly, NOT IN lists all rows excluded from the IN list. Additionally, NOT's can be thrown in with AND's &
OR's, except that NOT is a unary operator (evaluates one condition, reversing its value, whereas, AND's & OR's
evaluate two conditions), and that all NOT's are performed before any AND's or OR's. SQL Order of Logical
Operations (each operates from left to right) are NOT, AND, OR.
Like
To search for employees, whose last name starts with “L”, use the “like” command.
SELECT FirstName, LastName
FROM EmployeeTable
WHERE LastName LIKE 'L%';
The percent sign (%) is used to represent any possible character (number, letter, or punctuation) or set of
characters that might appear after the “L”. To find those people with LastName's ending with the letter “N”, use
'%N', or if you wanted the "N" in the middle of the word, try '%N%'. The “%” can be used for any characters in
the same position relative to the given characters.
27
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Order by
From time to time you will want to present the results of your query in some kind of order. As you know,
however, SELECT FROM gives you a listing, and unless you have defined a primary key, your query comes out
in the order the rows were entered. Compare the examples below:
SELECT *
FROM EmployeeTable;
The result will be:
005
034
059
081
097
118
Mary
Joe
Patricia
Bill
Sam
Sarah
Scott
Smith
Lawson
Jones
Jones
Ackerman
74,000,
63,000,
48,000,
42,000,
36,000,
32,000,
Manger
Manager
Staff
Staff
Entry-level
Entry-level
Table 3.3. Result of “SELECT * FROM EmployeeTable”
The order of the output is exactly the same order as the order in which the data was entered. The ORDER BY
clause gives you a way of ordering your results. For example, to list the data with the highest number or letter
first, you would use the following ORDER BY clause:
SELECT *
FROM EmployeeTable
ORDER BY LastName desc;
The result will be:
034
005
059
097
081
118
Joe
Mary
Patricia
Sam
Bill
Sarah
Smith
Scott
Lawson
Jones
Jones
Ackerman
63,000,
74,000,
48,000,
36,000,
42,000,
32,000,
Manager
Manger
Staff
Entry-level
Staff
Entry-level
Table B.4. Result of query “SELECT * FROM EmployeeTable ORDER BY LastName desc”
The DESC at the end of the ORDER BY clause orders the list in descending order instead of the default
(ascending) order.
Aggregate Functions
There are five important aggregate functions: SUM, AVG, MAX, MIN, and COUNT. They are called aggregate
functions because they summarize the results of a query, rather than listing all of the rows.





SUM () gives the total sum of all the rows, in a numeric column.
AVG () gives the average value of the given column.
MAX () gives the largest value figure in the given column.
MIN () gives the smallest value figure in the given column.
COUNT(*) gives the number of rows satisfying the conditions.
These functions are defined in the ANSI standard. Most implementations of SQL have extensions to these
aggregate functions. Some implementations may use different names for these functions.
The function SUM returns the sum of all selected fields. To find the total salary the company pays, write:
SELECT SUM(Salary)
FROM EmployeeTable;
28
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
The AVG function computes the average of a column, and like the SUM function, AVG works with numbers
only.
To compute the total average the company pays, use this:
SELECT AVG(Salary)
FROM EmployeeTable;
MAX is a function that works with both characters and numbers. It return the highest (closest to Z) string. To
find the “last employee” (in alphabetical order), write:
SELECT MAX(LastName)
FROM EmployeeTable;
MIN does the expected thing and works like MAX except it returns the lowest member of a column. To find the
employee with lowest id number, use this:
SELECT MIN(EmployeeIdNo)
FROM EmployeeTable;
The function COUNT returns the number of rows that satisfy the condition in the WHERE clause. For example,
to find out the number of “manager” working at the company, write:
SELECT COUNT(LastName)
FROM EmployeeTable
WHERE Position = 'Manager';
Group by
The GROUP BY command is used to associate an aggregate function (especially COUNT) with groups of rows.
To calculate each positions average salary, write:
SELECT Position, AVG(Salary)
FROM EmployeeTable
GROUP BY Position;
Distinct
The DISTINCT commando eliminates any duplicates after a query. To find out the different positions at the
company (each position is only written ones), write:
SELECT DISTINCT Position FROM EmployeeTable;
Having
HAVING is very similar to WHERE except the statements within it are of an aggregate nature. It enables you to
use aggregate functions in a comparison statement. The example below calculates the total salary for each
position and return only those with a total salary more than $80,000.
SELECT Position, SUM(Salary) AS total
FROM EmployeeTable
GROUP BY Position
HAVING SUM(Salary) > 80000;
The commands mentioned so far are used mostly by the single user. The rest of this chapter we will discus
commands used mostly by the DataBase Administrator.
Create database
First, a database must be created. Many modern systems (including Oracle8i) include graphical tools that enable
you to completely build the database with the click of a mouse button. This timesaving feature differs between
different databases, depending on the options your database management system (DBMS) supports and how
detailed you want to be when building a database.
29
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Create table
When creating a table using Oracle8i, several constraints apply when naming the table. First, the table name can
be no more than 30 characters long and must start with a letter. Because Oracle is case insensitive, you can use
either uppercase or lowercase for the individual characters. The remaining characters can be letters, numerical or
the symbols _, #, $, and @. The name cannot be one of the Oracle or SQL reserved words such as SELECT.
The process of creating a table is far more standardized than the CREATE DATABASE statement. Here is the
basic syntax for the CREATE TABLE statement:
The example below creates a table containing five:
CREATE TABLE EmployeeTable(
EmployeeIdNo
FirstName
LastName
Salary
Position
NUMBER(3),
VARCHAR2(10),
VARCHAR2(15),
NUMBER(6),
VARCHAR2(20));
Alter table
The ALTER TABLE statement enables the database administrator or designer to change the structure of a table
after it has been created. The ALTER TABLE command enables you to do two things:
 Add a column to an existing table
 Modify a column that already exists
To add a column (PhoneNo) to a table, write:
ALTER TABLE EmployeeTable
ADD (PhoneNo NUMBER(10));
To modify the size of a column, write:
ALTER TABLE EmployeeTable
MODIFY LastName char(25);
Note: You can increase or decrease the length of columns; however, you can not decrease a column's length if
the current size of one of its values is greater than the value you want to assign to the column length.
Insert
The INSERT...VALUES statement enters data into a table one record at a time. It is useful for small operations
that deal with just a few records. The basic format of the INSERT...VALUES statement adds a record to a table
using the columns you give it and the corresponding values you instruct it to add. You must follow three rules
when inserting data into a table with the INSERT...VALUES statement:
 The values used must be the same data type as the fields they are being added to.
 The data's size must be within the column's size. For instance, you cannot add an 80-character string to
a 40-character column.
 The data's location in the VALUES list must correspond to the location in the column list of the column
it is being added to. (That is, the first value must be entered into the first column, the second value into
the second column, and so on.)
To add a new record to a table, write:
INSERT INTO EmployeeTable
VALUES (005, 'Mary', 'Scott', 74000, 'Manager');
Note: The INSERT statement does not require column names. If the column names are not entered, SQL lines up
the values with their corresponding column numbers. In other words, SQL inserts the first value into the first
column, the second value into the second column, and so on.
30
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Update
Once the information has been stored in the database, we might find that there is a need to modify the data. To
do that, the UPDATE command is used. This statement checks the WHERE clause first. For all records in the
given table in which the WHERE clause evaluates to TRUE, the corresponding value is updated.
UPDATE EmployeeTable
SET Salary = 54000, Position = 'Manager'
WHERE LastName ='Jones' AND FirstName = 'Bill';
If the part “AND FirstName = 'Bill' ” had been left out, two rows would have been updated. The two rows
where the last name is Jones.
Drop table
SQL provides a command to completely remove a table from a database. The DROP TABLE command deletes a
table along with all its associated views and indexes. After this command has been issued, there is no turning
back. The syntax for DROP TABLE is:
DROP TABLE EmployeeTable;
Delete
In addition to adding data to a database, you will also need to delete data from a database. To delete person the
with employee id number 118, use the following syntax:
DELETE FROM EmployeeTable
WHERE EmployeeIdNo = 118;
Depending on the use of the DELETE statement's WHERE clause, SQL can do the following:
 Delete single rows
 Delete multiple rows
 Delete all rows
 Delete no rows
Here are several points to remember when using the DELETE statement:
 The DELETE statement cannot delete an individual field's values (use UPDATE instead). The
DELETE statement deletes entire records from a single table.
 Like INSERT and UPDATE, deleting records from one table can cause referential integrity problems
within other tables. Keep this potential problem area in mind when modifying data within a database.
 Using the DELETE statement deletes only records, not the table itself. Use the DROP statement to
remove an entire table.
Commit
The commit command makes changes made to the database system permanent. The commands given between
two commits are called a transaction.
Rollback
Takes back any changes to the database that you have made, back to the last time you gave a commit command.
Notice that some software uses automatic committing, there for the Rollback command may not work.
The option USE ROLLBACK SEGMENT tells Oracle which database segment to use for rollback storage space.
This option is an Oracle extension to standard SQL syntax.
31
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Chapter 4
4
Database design
4.1
Overview of Database Design
Database design is the process of creating a design for a database. The major aims of database design are:
 To represent the data and the relationships between data required by all users and applications.
 To provide a data model that supports all transactions required on the data.
 To specify a minimal design to achieve the stated performance requirements (i.e., response times,
etc.) for the system.
These aims are not always easy to achieve. The most difficult is usually to achieve good system performance.
Often the designer has to make trade-offs between the aims.
The two main approaches to database design are bottom-up and top-down approaches. Bottom-up approach
starts at the level of attributes, which are analyzed for associations between them. Then, the attributes are
grouped into relvars. The process of normalization (see chap. 4.3) represents a bottom-up approach to design.
The bottom-up approach is not suitable for complex databases with large amounts of attributes (sometimes
hundreds of thousands of them). It is hard to find the associations between the attributes and it may be difficult to
establish all the attributes.
Top-down approach is more suitable for complex databases. This approach starts with defining high-level
objects of interest and relationships between them. Then successive top-down refinements are applied to identify
low-level objects of interest, and the associated attributes. The Entity-Relationship (ER) model is a top-down
approach (see chap. 4.2).
The process of database design is divided into three stages
 Conceptual Database Design – the process of constructing a model of the information used in an
enterprise, independent of all physical considerations.
 Logical Database Design – the process of construction a model of the information used in an
enterprise based on a specific data model (e.g., relational model), but independent of a particular
DBMS and other physical considerations.
 Physical Database Design – the process of producing a description of the implementation of the
database on secondary storage. It describes the storage structures and access methods used to
achieve efficient access to the data.
4.2
The Entity-Relationship Model
Data modeling is used for better understanding of the semantics (meaning) of the data and serves as a common
platform between users and designers. During building of the data model the designer discovers the semantics of
the enterprise’s data that exist whether or not they happen to be formally recorded. The model ensures that the
designer understand:
 Each user’s perspective of the data;
 The nature of the data itself, independent of its physical representations;
 The use of data across application areas;
32
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
The most popular high-level data model is the Entity-Relationship (ER) Model. The reason may be that ER
model includes along with semantic objects a corresponding diagramming technique. The diagrams provide a
simple and easy to understand way of showing the features of the design of any given database.
The basic semantic concepts that ER model include are entities, relationships and attributes.
4.2.1
Entities
Entity is an object of interest. It is a “thing” that can be uniquely identified and talked about. There are two types
of entities. They are called weak entity and strong (or regular) entity. Weak entity is existence-dependent on
some other entity, which means that it cannot exist if that other entity does not exist. Regular (strong) entity is an
entity that is not existence-dependent on any other entity (i.e., not weak entity).
Regular entities are represented in the diagram by rectangles labeled with the name of the entity. The weak
entities have are represented by double-lined rectangles.
Example
Suppose that we are designing a database for a company that wants to collect information on their managers,
programmers, and other employees, project assignments, projects and departments. These are the “objects of
interest” for the company and can be identified as the entities (see fig. 4.1). The information about project
assignments includes “which employee does what on which project”. When the project is quitted or interrupted,
so are the assignments; and the same happens when an employee resins. Therefore you can say that
PROJECT_ASSIGNMENT is existence-dependent on both the EMPLOYEE / PROGRAMMER / MANAGER
and PROJECT. So that entity is a weak one.
EMPLOYEE
DEPARTMENT
PROGRAMMER
MANAGER
PROJECT
PROJECT_ASSIGNMENT
Figure 4.1. Entities.
4.2.2
Relationships
Relationship is a meaningful association among entities. The entities involved in a given relationship are called
participants in that relationship.
Relationships are represented as diamonds containing the name of the relationship in question. The participants
of the relationship are connected to the relationship by solid lines. If the relationship connects a weak entity to
the strong entity (on which the weak entity depends) the diamond symbol of the relationship has double lines.
EMP_DEP
PARENT_DEP
EMPLOYEE
PROGRAMMER
MANAGER
DEPARTMENT
DEP_MAN
EMP_PA
PROJECT_ASSIGNMENT
PRO_PA
PROJECT
Figure 4.2. Relationships.
33
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Example
What are the meaningful associations between the entities in previous example? All the types of employees work
in some department. Some departments have over- and under-departments. All departments have managers.
Employees have different project assignments. The project assignments belong to different projects. These
associations are the relationships between the entities (see fig. 4.2).
4.2.3
Attributes
Entities and relationships have properties, called attributes. Attributes are “things” that you would like to know
or can say about the entities or relationships. Each kind of attribute draws its values from a corresponding value
set called domain.
Attributes can be:
 simple – an attribute composed of a single component with an independent existence;
 composite – an attribute composed of multiple components, each with independent existence;
 key – an attribute, or set of attributes that uniquely identifies individual occurrences of an entity or
relationship;
 single-valued – an attribute that holds a single value for a single entity or relationship;
 multi-valued – an attribute that holds multiple values for a single entity or relationship;
 missing – (e.g., “unknown” or “not applicable”)
 derived – an attribute that represents a value that is derivable from the value of a related attribute
or set of attributes, not necessarily in the same entity or relationship;
 base – an attribute that is not derived;
Attributes (simple, single-valued, base attributes) are represented as ellipses labeled with the name of the
attribute in question and attached to the relevant entity or relationship by solid line. If the attribute is composite,
its component attributes are shown as ellipses attached to the relevant composite attribute. The key attributes’
names are underlined. The ellipse has double lines if the attribute is multi-valued and the ellipse is dotted
(dashed) if the attribute is derived.
FIRST
MIDDLE
LAST
RESPONSIBILITY
ADDRESS
NAME
EMPLOYEE
EMP#
EMP_DEP
EMP#
PROGRAMMER
PARENT_DEP
MANAGER
NAME
DEPARTMENT
ADDRESS
DEP_MAN
EMP#
#_OF_EMPLOYEES
NAME
ADDRESS
NAME
PR#
EMP_PA
BUDGET
PROJECT_ASSIGNMENT
PRO_PA
HOURS_WORKED
RESPONSIBILITY
PROJECT
DESCRIPTION
START
END
Figure 4.3. Attributes.
34
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Example
Attributes are the type of information that the company in our example wants to gather. Such information is
employee’s number, name, address, salary, and so on. In figure 4.3 we can see that the employee’s number has
been chosen as a primary key and that Name is a composite attribute, composed of attributes First, Middle and
Last. In the case of the departments the gathered information would be their names, responsibilities, amount of
employees, and so on. The attribute #_of_employees is a derived attribute. The amount of employees working at
the department can be acquired by counting the employees in the future database, which can be automated.
4.2.4
Structural Constraints
Structural constraints are restrictions on the relationships and participating entities. The designer needs to
determine them for preserving the integrity in the future database. The two main types of structural constraints
are cardinality and participation constraints.
Degree of a relationship is the number of participants in the relationship. The most common degree for
relationships is binary. Cardinality ratio is the number of possible relationships for each participating entity. The
cardinality ratios for binary relationships are one-to-one (1:1), one-to-many (1:M), and many-to-many (M:N).
Each line that connects the entity to the relevant relationship is labeled “1” or “M” to indicate the cardinality.
There are two types of participation constraints, total (sometimes referred to as mandatory) and partial (optional).
If an entity’s existence requires the existence of an associated entity in a particular relationship, then the
participation is total. Otherwise the participation is partial.
The participants in each relationship are connected by lines to the relationship. If the participation is partial, the
lines are single. If the participation is total the lines are double.
FIRST
MIDDLE
LAST
RESPONSIBILITY
NAME
ADDRESS
EMP_DEP
M
M
PROGRAMMER
EMPLOYEE
1
PARENT_DEP
M
EMP#
1
MANAGER
1
1
EMP#
M
1
NAME
DEPARTMENT
1
1
ADDRESS
DEP_MAN
EMP#
#_OF_EMPLOYEES
NAME
ADDRESS
NAME
PR#
EMP_PA
BUDGET
M
PROJECT_ASSIGNMENT
M
PRO_PA
HOURS_WORKED
RESPONSIBILITY
1
PROJECT
DESCRIPTION
START
END
Figure 4.4. Structural Constraints.
Example
We can see that all of the relationships in our example are binary (an employee is either a programmer, manager,
or other). But how can we tell the cardinality ratios? It is quite simple. For example, one department can have
several employees, but an employee can only work in one department. That is a one-to-many (1:M) relationhip.
35
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
A department has only one manager, and he is manager of only that department – 1:1 relationship. This is
marked in figure 4.4.
What about participation constraints? They are just as logical as the cardinality ratios. An employee does not
have to be working on any project assignment (partial participation), but a project assignment always has some
employee working on it (total participation). There is no department without a manager (total participation), and
no manager without a department (total participation). For more participation constraints, check figure 4.4.
4.2.5
Entity Subtypes and Supertypes
Every entity is of some type and it can be of several types simultaneously. For example, if some employees are
programmers and all programmers are employees then entity type PROGRAMMER is a subtype of entity type
EMPLOYEE and entity type EMPLOYEE is a supertype of entity type PROGRAMMER. Furthermore, all
properties of employees and all relationships in which employees participate automatically apply to
programmers, but the converse is not true.
The reason why this concept was introduced into ER model is that it avoids describing similar concepts more
than once and makes the ER diagram more readable. The other reason is that it adds more semantic information
to the design in a form that is familiar to many people.
The supertypes and subtypes are represented by drawing a line from the supertype rectangle to the subtype
rectangle and marking with an arrowhead at the subtype rectangle.
Example
As described before, programmers are employees – and so are the managers. Therefore entities
PROGRAMMER and MANAGER are subtypes of the EMPLOYEE entity. All the attributes that were indentical
for all the three relationships are now moved to EMPLOYEE, together with the relationships. Figure 4.5 shows
clearly, that the diagram has been more readable.
FIRST
MIDDLE
LAST
RESPONSIBILITY
NAME
ADDRESS
EMP_DEP
PARENT_DEP
M
1
EMPLOYEE
M
1
NAME
DEPARTMENT
1
1
EMP#
DEP_MAN
PROGRAMMER
1
#_OF_EMPLOYEES
MANAGER
PR#
EMP_PA
BUDGET
M
PROJECT_ASSIGNMENT
M
PRO_PA
HOURS_WORKED
RESPONSIBILITY
1
PROJECT
DESCRIPTION
START
END
Figure 4.5. Entity Subtypes and Supertypes.
36
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
4.3
Normalization
The process of normalization was first developed by E. F. Codd (the creator of relational model) in 1972.
Normalization is a process of producing relations with desirable properties, given the data requirements of an
enterprise. It is a formal method that identifies relations based on their candidate keys and the functional
dependencies among their attributes. It is often performed as a series of tests on a relation to determine if it
satisfies or violates the requirements of a given normal form. The normalization is performed so that a database
can be normalized to a specific form to prevent occurrence of redundancies and update anomalies.
The process of normalization involves decomposition (breaking down) a given relvar into other relvars, which
can be seen as projection. The process of decomposition is required to be reversible, so that no information is
lost in the process. In other words normalization is a process of nonloss (also called lossless) decomposition.
The first three sections are quite tricky. They describe different kinds of dependencies between attributes in a
relvar. They are the underlying theory for the process of normalization and therefore hard to omit.
4.3.1
Functional Dependencies
Functional dependency (FD) is a many-to-one relationship from one set of attributes to another. For example, if
A and B are attributes of relvar R, B is functionally dependent on A (denoted A  B ), if each value of A is
associated with exactly one value of B. In other words, in every possible legal value of R, whenever two tuples
agree on their A value, they also agree on their B value.
A
B
Figure 4.6. Diagram of the functional dependency
AB
Functional dependency is a formalized way of showing meaning or semantics of the attributes in a relation. FDs
represent integrity constraints between the attributes, which eventually will have to be implemented. The
complete set of FDs for a given relvar can be very large. Therefore it is desirable to find a (ideally) much smaller
set of FDs that imply the previous set of FDs. If such a set can be found, it is sufficient that the DBMS enforce
just the functional dependencies in this set, and all the functional dependencies will then be enforced
automatically. This is what the process of normalization does.
The process of normalization is based on the set of inference rules:
1. Reflexivity – If B is a subset of A, then A  B .
2. Augmentation – If A  B , then AC  BC (AB means A union B).
3. Transitivity – If A  B and B  C , then A  C .
4. Self-determination – A  A .
5. Decomposition – If A  BC , then A  B and A  C .
6. Union – If A  B and A  C , then A  BC .
7. Composition – If A  B and C  D , then AC  BD .
37
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
4.3.2
Multi-Valued Dependencies
Multi-valued dependency (MVD) represents dependency between attributes in a relation. If A, B and C are
attributes of relvar R, and for every value of A there is a set of values for B, and a set of values for C (but B and
C are independent of each other) than we have multi-valued dependency between A, B and C.
We represent MVDs between attributes A, B, and C in a relvar with this notation:
A  B
A  C
(Read A multi-determines B and A multi-determines C). It is even common to represent both multi-valued
dependencies in one statement:
A  B | C
Multi-valued dependencies are generalization of functional dependencies, which means that every FD is an
MVD, but the converse is not true.
4.3.3
Join Dependencies
Join dependence (JD) is a property of decomposition. If R is a relvar and A, B, …, Z are subsets of the attributes
of R. Then we say that R satisfies the JD
  A, B,..., Z 
(Read “star A, B, …, Z”) if and only if every legal value of R is equal to the join of its projections on A, B, .., Z.
Which means that no spurious rows are generated when relvars are reunited through a natural join operation.
MVD is a special case of JD, which means that all MVDs are JDs, but the converse is not true. Formally:
A  B | C   AB, AC  .
The join dependence is the most general form of dependency possible. That means, that there is no higher form
of dependency such that JD is a special case of that form. However this is restricted to dependencies that only
deal with decomposing relvars via projections and recomposing them via joins.
4.3.4
First Normal Form (1NF)
First normal form is one of the forms initially proposed by Codd. A relvar is in 1NF if and only if, in every legal
value of that relvar every tuple contains exactly one value for each attribute. This means that relvars are always
in 1NF. And if the relvar is not in 1NF, it is not really a relvar due to relational model.
But, a relvar that is only in first normal form has a structure that is undesirable for many reasons, the most
important being update anomalies. This is why further normalization is required.
38
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
To explain the train of thought we use a fictive suppliers and parts database (found in C.J Date, 7:th edition).
The data about the suppliers and shipments is put together into a single relvar:
FIRST (S#, STATUS, CITY, P#, QTY)
PRIMARY KEY (S#, P#)
where






S# - unique supplier number;
P# - unique part number for every kind of part;
STATUS – a rating or status value of the supplier;
CITY – location of the supplier;
QTY – quantity for the shipment made by the certain part supplied by a certain supplier;
FDs (see fig. 4.7):
 S # , P#  QTY
 S #  CITY
 S #  STATUS
 CITY  STATUS
S#
CITY
QTY
P#
STATUS
Figure 4.7. Functional Dependencies of FIRST.
The problem with update anomalies with each of the three operations:
 INSERT – We cannot insert that a particular supplier is located in a particular city until that supplier
supplies at least one part.
 DELETE – If we delete a whole FIRSRT tuple for a particular supplier, we delete not only the shipment
connecting that supplier to a particular part but also the information that the supplier is located in a
particular city.
 UPDATE – The city value for a given supplier appears in FIRST many times, in general. This redundancy
causes update problems.
4.3.5
Second Normal Form (2NF)
Second normal form is one of the original forms defined by Codd. It applies to relvars with composite keys. A
relvar with a single attribute primary key is automatically in at least 2NF. A relvar is in 2NF if and only if it is in
1NF and every nonkey attribute is irreducibly dependent on the primary key. Thus normalization of 1NF relvars
to 2NF involves the removal of partial dependencies on the primary key.
In FIRST we can identify partial dependencies:
S #  CITY
S #  STATUS
39
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Transformation the relvar to into 2NF requires creation of new relvars so that the attributes that are not fully
dependent on the primary key are associated with only the appropriate part of the key. We replace relvar FIRST
by the two relvars
SECOND (S#, STATUS, CITY)
PRIMARY KEY S#
and
SP (S#, P#, QTY)
PRIMARY KEY (S#, P#)
The FD diagrams for these two relvars are given in fig. 4.8)
CITY
S#
QTY
S#
P#
STATUS
Figure 4.8. Functional Dependencies of SECOND and SP.
This new structure overcomes the problems with updates described earlier. But relvar SECOND still suffers of
update anomalies:
 INSERT – We cannot insert the fact that a particular city has a particular status.
 DELETE – If we delete a whole SECOND tuple for a particular city, we delete not only the
information for the supplier concerned, but also the information that that city has that particular
status.
 UPDATE – The status for a given city appears in SECOND many times, in general.
4.3.6
Third Normal Form (3NF)
Third normal form is the last form defined by Codd alone in 1972. A relvar is in 3NF if and only if it is in 2NF
and every nonkey attribute is nontransitively dependent on the primary key. Thus the normalization of 2NF
relations to 3NF involves the removal of transitive dependencies. The relvar SP does not have transitive
dependencies on the primary key, it is therefore already in 3NF. But SECOND the dependency of STATUS on
S# is transitive via CITY.
Transformation to 3NF requires removal of the transitively dependent attributes from the relation by placing
them in a new relation along with a copy of their determinant. Thus the solution to the problem is to replace
SECOND by the projections:
SC (S#, CITY)
PRIMARY KEY S#
and
CS (CITY, STATUS)
PRIMARY KEY CITY
The FD diagrams for all the relvars are given in fig. 4.9
40
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
S#
CITY
CITY
STATUS
S#
QTY
P#
Figure 4.9. Functional Dependencies of SC, CS and SP.
This new structure overcomes all the problems with update anomalies sketched earlier.
4.3.7
Boyce-Codd Normal Form (BCNF)
Boyce-Codd normal form is a stronger definition of third normal form that was introduced by R. Boyce and E. F.
Codd in 1974. The previous 3NF did not deal with the case of relvars that had two or more candidate keys, such
that the candidate keys were composite, and their overlapped (i.e., had at least one attribute in common).
A relvar is in BCNF if and only if all the determinants are candidate keys. Where 3NF allows the FD A  B in a
relvar if B is a primary-key attribute and A is not a candidate key, BCNF require that A must be a candidate key,
if the FD is to remain the relvar.
It is easy to see that relvars SC, CS and SP are in BCNF. The reason is that the candidate keys are the only
determinants in the relvars. So, we will now see an example with two overlapping candidate keys. The example
is again a fictive supplier and parts database. We consider a relvar SSP (suppliers and shipments):
SSP (S#, SNAME, P#, QTY)
where






candidate keys are:
 (S#, P#)
 (SNAME, P#)
S# - unique supplier number;
P# - unique part number for every kind of part;
SNAME – unique supplier name
QTY – quantity for the shipment made by the certain part supplied by a certain supplier;
FDs (see fig. 4.10):
 S # , P#  QTY
SNAME, P#  QTY
 S #  SNAME
 SNAME  S #

S#
P#
QTY
SNAME
Figure 4.10. Functional Dependencies of SSP.
41
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
This relvar is not in BCNF, because it contains two determinants S# and SNAME, that are not candidate keys for
the relvar. Transformation to BCNF requires breaking the relvar down into two projections:
SS (S#, SNAME)
SP (S#, P#, QTY)
or
SS (S#, SNAME)
SP(SNAME, P#, QTY)
Both decompositions are equally valid and all of the projections are in BCNF.
Any relvar can be decomposed into BCNF, but it is not always desirable. The reason is that it is not always
possible to preserve all the functional dependencies in the decomposition. When the right and left sides of some
FD are in different relvars it is difficult to enforce that FD and the integrity constraint is lost. In this case it is
better to stop the normalization at 3NF, which always preserves dependencies.
4.3.8
Fourth Normal Form (4NF)
Fourth normal form was introduced by Fagin in 1977. It deals with practical situations that are very rare. A
relvar is in 4NF if and only if it is in Boyce-Codd normal form and contains no nontrivial multi-valued
dependencies. A MVD A  B is trivial if either A is a superset of B or the union of A and B is the entire
heading.
Take a look at the relvar HCTX in table 4.1. It is hierarchic relvar containing information about courses,
teachers, and text. The meaning of the relvar is that a course can be teached by any of the teachers and uses all of
the specified texts as references. Here follows other assumptions used in the relvar:
 for a given course exists any number corresponding teachers and any number corresponding texts;
 teachers and texts are independent of one another;
 a given teacher or a given text can be associated with any number of courses.
COURSE
TEACHERS
TEXTS
Physics
TEACHER
Prof. Green
Prof. Brown
TEXT
Basic Mechanics
Principles of Optics
Math
TEACHER
Prof. Green
TEXT
Basic Mechanics
Vector Analysis
Trigonometry
Table 4.1. Relvar HCTX.
Suppose that we would like to eliminate the relation-valued attributes. One way to do this is to replace HTX by
CTX, with three scalar attributes COURSE, TEACHER, and TEXT. The result may be seen in table 4.2.
42
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
COURSE
Physics
Physics
Physics
Physics
Math
Math
Math
Table 4.2. Relvar CTX
TEACHER
Prof. Green
Prof. Green
Prof. Brown
Prof. Brown
Prof. Green
Prof. Green
Prof. Green
TEXT
Basic Mechanics
Principles of Optics
Basic Mechanics
Principles of Optics
Basic Mechanics
Vector Analysis
Trigonometry
It is obvious that there is much redundancy in relvar CTX, which will cause update anomalies. The reason is the
two multi-valued dependencies in the relvar: COURCE  TEACHER | TEXT . The way to be free of them is
to normalize the relvar to 4NF.
The normalization of BCNF relations to 4NF involves the removal of the MVD from the relvar by placing the
attributes in a new relvar along with a copy of the determinant. The way to normalize relvar CTX into 4NF is to
decompose it into two projections (result in fig. 4.11):
CT (COURSE, TEACHER)
and
CX (COURSE, TEXT)
COURSE
Physics
Physics
Math
TEACHER
Prof. Green
Prof. Brown
Prof. Green
COURSE
Physics
Physics
Math
Math
Math
TEXT
Basic Mechanics
Principles of Optics
Basic Mechanics
Vector Analysis
Trigonometry
Figure 4.11. Relvars CT and CX.
4.3.9
Fifth Normal Form (5NF)
Fifth normal form (even called projection-join dependency) was introduced by Fagin in 1979. It deals with
practical situations that are even more rare than fourth normal form. A relvar is in 5NF if it has no join
dependencies (JDs).
Consider the relvar PIS in table 4.3. It contains information about properties, items and suppliers. It describes
items provided by suppliers to properties.
PG#
PG4
PG4
PG16
PG16
PG36
ITEM
Bed
Chair
Bed
Table
Chair
S#
S1
S2
S2
S1
S3
Table 4.3. Relvar PIS.
43
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Suppose that we want to add a constraint that the supplier S1 can only provide items bed and table. Suppose that
we want to add a constraint that property PG4 only wants to be provided with bed and chair. These constraints
are not supported by the structure of the relvar, because it is possible to add rows that S1 supplies a chair to
PG16 or that S3 supplies a table to PG4. This problem shows the join dependency on the relvar PIS:
 PG # , ITEM , ITEM , S #, S # , PG #
As there is a JD in the relvar PIS, therefore it is not in 5NF. Because normalization of 4NF to 5NF requires
removal of join dependencies, by decomposing the relvar to projections shown by the join dependencies.
Normalization of the relvar PIS requires it to be decomposed to relvars (see fig. 4.12):
PI (PG#, ITEM)
IS (ITEM, S#)
SP (S#, PG#)
PG#
ITEM
PG4
Bed
PG4
Chair
PG16
Bed
PG16
Table
PG36
Chair
Figure 4.12. Relvars PI, IS, SP.
ITEM
Bed
Chair
Bed
Table
Chair
S#
S1
S2
S2
S1
S3
S#
S1
S2
S2
S1
S3
PG#
PG4
PG4
PG16
PG16
PG36
A relvar in fifth normal form is guaranteed to be free of anomalies that can be eliminated with projections. This
makes the 5NF the ultimate normal form, when applied to joins and projections.
4.4
Conceptual Database Design
The first step of the database design is to construct a conceptual database model for each user view of the part of
the enterprise that is to be modeled. The conceptual data model is completely independent of implementation
details of any physical considerations, programming languages, application programs and the DBMS.
A user view is the data (about some functional area of the enterprise) required by a particular user to perform
some task or make a decision. The conceptual data model for a user view is called local conceptual model. The
reason of decomposing the design into user views is to divide the design into more manageable tasks.
Using the Entity-Relationship modeling, the conceptual design methodology comprises of these steps (done for
each user view):
1.
2.
3.
4.
5.
6.
7.
8.
Identify entity types in the user’s view of the enterprise;
Identify the important relationships that exist between the identified entity types;
Identify and associate attributes with entity or relationship types;
Determine attribute domains;
Determine candidate and primary key attributes for each entity;
Determine entity subtypes and supertypes (optional step);
Draw Entity-Relationship diagram that is a conceptual representation of a user view of the enterprise;
Review local conceptual data model with user to ensure that the model represents user’s view of the
enterprise;
44
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
4.5
Logical Database Design
The second step of the database design is to map the conceptual data models to the logical data model for the
part of the enterprise that is to be modeled. Logical data model is still independent of all the physical
considerations. However it is dependent of the target data model for the database, which in this case is the
relational data model.
The first part of the logical database design is to design the local conceptual model. A logical model for each
user view is designed in these steps:
1.
2.
3.
4.
5.
6.
7.
Refine the local conceptual model and map it to local logical data model;
Derive relvars from local logical data model;
Validate model using normalization;
Validate model against user transactions;
Draw Entity-Relationship diagram that is a local logical representation of user’s view of the enterprise;
Define integrity constraints given in the user’s view of the enterprise;
Review local logical data model with user to ensure that the model represents user’s view of the enterprise;
Next part of the logical database design is to integrate the local logical data models into global logical data
model, which represents all the user views. The activities in this part of the design are:
1.
2.
3.
4.
5.
4.6
Merge local logical data models into single global logical model of the enterprise;
Validate global logical data model using normalization and against the required transactions;
Check for future growth;
Draw final Entity-Relationship diagram that is a global logical representation of the enterprise;
Review global logical data model with users to ensure that it is a representation of the enterprise;
Physical Database Design
Last step of database design is to decide how the database is to be implemented. The main aim is to produce a
description of the implementation of the database on secondary storage. Which include storage structures,
security and access methods used to achieve efficient access to the data. This means that physical database
design is dependent on a specific DBMS system.
This step should on larger systems be separated from conceptual and logical database design steps, because it
deals with different subject matter – the how, not the what. The what must be understood before the how can be
determined and the two are different skills, which are often found in different people.
First part of the physical database design is to produce a basic working relational database schema from the
global logical data model:
1.
2.
Decide how to represent the base relvars identified in the global logical data model in the target DBMS;
Design enterprise constraints for target DBMS;
The second part of the physical database design is to determine the file organizations and access methods that
will be used to store the base relations:
1.
2.
3.
4.
5.
Analyze transactions to understand the functionality of them;
Choose an efficient file organization for base relations;
Choose secondary indexes if they will improve the performance of the system;
Consider the introduction of controlled redundancy (relaxing the normalization) if it will improve the
performance of the system;
Estimate disk space requirements of the database;
45
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
The last part is to design the security mechanisms for the database as the users have specified them:
1. Design user views from local conceptual data models;
2. Design access rules to the base relations and user views;
Once the initial design has been implemented, it will be necessary to monitor and tune it to correct inappropriate
design decisions of reflect changing requirements.
46
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Chapter 5
5
What We Did
Our work is not designing a completely new database, but redesigning an existing one. Because of this, the
process differs a bit from the process of database design described earlier in this work.
After a good look on today’s system, we understood that 1400 configuration files, 485 dat-files, and over 14500
lines of text in MOC.typ was just too much to work with. So we decided to cat the database and lower the
amount of data. We chose to work with only 10 s. k. types: MECHANICAL_UNIT, ROBOT, ROBOT_TYPE,
JOINT,
AXC_FILTER,
ARM,
PARALLEL_ARM_LOAD,
ARM_TYPE,
ACC_DATA,
and
ARM_CHECK_POINT. Further more we decided to work with only one robot family, the IRB 4400 family. We
chose the cfg-files: 4400_1.95_45.cfg, 4400_1.95_60.cfg, 4400_2.45_30.cfg, 4400_s2.45_30.cfg,
4400_sc2.45_30.cfg, and 4400_2.6_10.cfg.
Because of the role of the configuration file, we cannot do any drastic changes to the database. Lack of temporal
predictability of the data stops us from making any assumptions about it.
5.1
Design of Conceptual Data Model
During the design of the conceptual data model the designer is supposed to work with user views. Because of the
fact, that today’s system is a global physical implementation, we developed a global conceptual model. Though
global, it is still a conceptual model and does not have any physical consideration or considerations to any data
model (e. g. relational).
First we identified the entity types in the database. As entities are supposed to be objects of interest and the types
in today’s system are just that, it was obvious to us, that they are the entities. We recorded the names,
descriptions, aliases and occurrences of the entities in the same way as Connolly Et al (2002) describes. The
documentation is in appendix A. All the entities are regular (strong).
As attributes associated to the entities we took the attributes described in the MOC.typ, except attributes that are
pointers to types, which are not any of the ten chosen. All the attributes are simple, single-valued, base attributes.
The documentation of the attributes (appendix C) includes
 attribute name and description;
 entity it is associated to;
 data type and length;
 default, min, and max values;
 constraints.
All of this information could be find in MOC.typ.
It is also important to decide, whether the attributes allow or disallow nulls. We decided that all attributes that
have a default value could not allow nulls.
Every entity has an attribute called name. Every such attribute is described as “unique name” or “unique ID
name”. It is obvious, that they were meant to have a function of primary keys, so we marked them as such. And
because of entity integrity, no primary key can allow nulls; we wrote it down in the documentation.
47
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
We estimated the relationships between the entities from the hierarchy of today’s system. The estimation is that
every type pointing to another type has a relationship with it. But the determination of cardinality ratio and the
participation is not that easy.
To do that we studied the data in configuration files. Because one configuration file contains information about
one robot, all the cardinalities are one-to-one. Putting the data as is into a relational database would produce
anomalies as several values for each attribute in one tuple (reusability of primary keys), or redundancy (tuples
with identical data).
What we did, was map the entities into tables and attributes into columns (ahead of time) and add a new column
to every table annotating the name of a configuration file, the data was from. After that we took a table at a time
(starting at the leafs of the hierarchy tree) and looked for identical tuples. All the identical tuples were merged
into one tuple and all of them got new, unique primary key values. The new primary key values were copied to
pointer attributes in the parent table instead of the old values. Then we took a new table and repeated the work.
After we were done, we succeed to lower the total amount of rows from 216 to 88, 21 being the highest in a table
(36 before). The result is in appendix D.
Now we could judge the cardinality ratio of the relations. If there was several tuples with the same value in the
pointer attribute in one table, the cardinality ratio of the relationship was many-to-one. Otherwise it was one-toone.
We determined the participation by looking at the pointer attributes. If all of them had values, than the
participation was total. Otherwise it was partial. The six relationships between ROBOT and JOINT are an
exception. Because a robot does not have to have six axles and because it does not have to use all of its arms, all
the relationships are partial. All this is documented (see appendix B).
We could not determine the alternate keys, because of the temporal unpredictability of the data. We could not
either specialize/generalize the entity types. All the entities exist in their own right and there are no similarities
between them.
The last thing we did was to divide the primary key of ROBOT into three attributes: family, arm_length, and
default_load_mass. There was no special reason to that, besides showing that it can be done.
After all this, we drew the entity relationship diagram and the conceptual model was finished. The diagram does
not include the attributes, because there is to many of them. Adding them to the diagram would make it
unreadable, which would be the opposite of the purpose of the diagram. The diagram is in appendix E.
5.2
Design of Logical Data Model
Designing the Logical Data Model means mapping the local conceptual data models into a single global model.
The work is usually done in two steps:
1.
2.
Build local logical data models based on the local conceptual data models.
Combine the local logical data models into a single global data model.
Due to lack of user views, we do not have any local conceptual data models, but single global conceptual data
model. This means, that the second step will be unnecessary.
48
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Mapping conceptual data model into (relational) logical data model includes removing or replacing undesirable
features:






For every many-to-many (M:N) relationship, replace it with an intermediate entity and two M:1
relationships to the newly identified entity.
For every complex relationship (more than two participants), replace it with an intermediate entity
and required number of 1:M relationships to the newly identified entity.
For every recursive relationship (entity with a relationship with itself), decompose it to identify an
intermediate entity.
For every relationship with attributes, decompose it to identify entities.
Decompose multi-valued attributes to identify entities.
Remove all redundant relationships. A relationship is redundant if the same information can be
obtained via other relationships.
Our conceptual data model lacks such features and therefore we did not have to implement these steps.
As part of the mapping process we re-examined the 1:1 relationships. The two entities with such relationship
may represent the same object in the enterprise. In such a case they should be merged together. We decided that
we couldn’t do such changes to the design. One reason is that we cannot be certain if all the 1:1 relationships are
really 1:1 relationships. They could be 1:M relationships and only the data we chose to examine made they look
like 1:1 relationships. The second reason is that leaving the design as is, would make it ease to produce the
configuration files, which is the main aim of the database.
Now the time had come to deriving the relvars from the newly created logical data model, to represent the
entities and the relationships. All relvars were described with Database Definition Language (DBDL) for
relational databases. The language is very straightforward and easy to understand.
For every entity in the logical data model, we created a relvar that includes all the attributes of that entity.
In relational model the relationship that an entity has with another entity is represented by the primary
key/foreign key mechanism. It is done by so called “key migration”, which means copying the primary key
attributes from one entity to the other to act as the foreign key. And such attributes do already exist in the model,
the ones that were pointer attributes in MOC.typ. They could by used as they were with exception of the pointer
attribute in MECHANICAL_UNIT that references to ROBOT. Because ROBOT’s primary key had three
attributes, the foreign key in MECHANICAL_UNIT must do the same. So we replaced the attribute
use_robot_with use_robot_family, use_robot_arm_length, and use_robot_load_mass to match family,
arm_length, and default_load_mass attributes in ROBOT. The relvar descriptions in DBDL can be seen in
appendix F.
Next step should be to validate the model using normalization. The problem is that we cannot examine the
grouping of attributes due to data’s unpredictability. So we leave this work to be done by them who understand
true meaning of the data.
The model should also be validated against transactions. The thought is to check if all the entities, relationships,
and attributes required by the transactions are provided by the model. The most important transaction in this
database is creating a configuration file, given the type of the robot.
A configuration file contains all the data about one robot. Which means, that all the data in the database, about
one robot should be possible to retrieve. We checked the Entity Relationship diagram for prove. All the entities
are directly or indirectly connected to MECHANICAL_UNIT (which in today’s system is the root of the
hierarchy). That confirms that all the data is retraceable from the database.
At this time we should draw the Entity Relationship diagram, that contains the changes to the model. Because we
had not done any changes, the ER model stays as it was.
The last thing we did was to define integrity constraints. Without them the logical model would not be the
complete and accurate representation.
49
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
We considered the five types of integrity constraints:
 required data;
 attribute domain constraints;
 entity integrity;
 referential integrity;
 enterprise constraints.
If and what attributes must always contain a value (do not allow nulls) we have identified during the design of
the conceptual model. The same applies for set of values that are legal for every attribute. The information was
in MOC.typ.
The entity integrity – notion that the primary key of a relation (entity) cannot hold nulls is so straightforward,
that it also was considered during the design of the conceptual model.
To uphold the referential integrity a foreign key must either contain a value that refers to an existing occurrence
in the parent relation or not contain any value at all (null).
Whether a foreign key may or may not allow nulls is a question of its own. The answer is that if the participation
of the child relation (the one with foreign key) in the relationship is total, than nulls are not allowed. The
participation is partial, the nulls should be allowed.
To ensure the rest of the referential integrity we specified existence constraints – conditions under which a key
(primary and foreign) must be inserted, updated or deleted:
1.
2.
3.
4.
5.
6.
Insert occurrence into child relation – the foreign key attribute of the new occurrence is set to
null (if allowed) or to a value of an existing parent occurrence.
Delete occurrence from child relation – it causes no problem because the referential integrity is
not affected.
Update foreign key of child occurrence – similar to case 1.
Insert occurrence into parent relations – it causes no problem for referential integrity.
Delete occurrence from parent relation – the referential integrity is lost if there exists a child
occurrence referencing to the deleted parent occurrence. There are several strategies to consider
(described in chapter 2.5.2). Because we not only wanted to uphold the integrity but also wanted to
keep all the data intact, so we chose to restrict the delete action (not allow it to go through) in such
situation.
Update primary key of parent occurrence – the referential integrity is lost, as in case5. And we
chose the same strategy as in previous case.
The last integrity constraints to consider were enterprise constraints, which govern the “real world” transactions.
Such rules are the tree security levels of the attributes described in MOC.typ (more in chapter 1.1.1). As all other
things found in MOC.typ, all of them were noted during the design of the conceptual model.
At the end, we documented the integrity constratints and updated the derived relvars.
5.3
Design of Physical Data Model
During physical database design the designer produces a description of the implementation of the databas using
information of the logical data model and the functionality offered by the target database management system
(DBMS).
Besides knowing how to create the base relvars it is important to know if the DBMS does support the definition
of:
 primary keys, foreign keys, and alternate keys;
 required data;
 domains;
 enterprise constraints;
50
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
As DBMS we chose Oracle8iTM. It has an evaluation version that is a full version, and our school has means of
assistance for this DBMS.
Deciding how to implement the base relvars is relatively easy, because Oracle8i TM is compliant with 1992 ISO
SQL Standard (SQL 2). But we still needed to make some changes to the design. All data types were changed to
datatypes supported by Oracle SQL: char and number. The amount of digits id determined by min and max
values. If the data type was float, we chose to have 6 digits after the decimal point.
Oracle SQL supports only attribute names shorter than 30 characters, so we had to shorten some of them. All the
constraints as keys, min, max, default values and nulls are supported in Oracle SQL. The restriction of the delete
and update actions, as part of referential integrity upholding (see previous section) is default in Oracle8i TM.
We chose not to do any more steps of the physical database design, because our aim was to investigate if a
commercial DBMS can be used, not how well we can tune the database on a given DBMS.
5.4
Implementation
We implemented the design using the Oracle SQL (see appendix G). Then we filled the database with
configuration data in the same way (appendix H).
51
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Chapter 6
6
Database Client Technology
In this chapter we will describe different strategies of how to write applications querying tables in a relational
database. We will also explain different API’s and the differences between them.
6.1
Embedded SQL
One of the problems of writing applications querying tables in a database is the lack of standard between
different programming languages. However, the most common problem is the lack of standard between different
DBMS. One standard is embedded SQL, where the SQL-code is written directly in the applications source code,
where every SQL-statement begins with “EXEC SQL”. This has, with some difficulty been implemented in
some compilers, since the compiler has to take any peculiarity in the DBMS into consideration. Therefore, it has
been working best when the manufacturer of the DBMS used also is the manufacturer of the compiler. One
example is Oracles PRO*C which is adapted to Oracle database.
Another difficulty in combining SQL with a certain programming language is that traditional programming is
based on execution row after row, while an SQL-query executes several rows at a time.
6.2
Application Program Interface (API)
Obviously, there has been, and there is, a need of an alternative to embedded SQL. Therefore, many of the
DBMS-manufactures supply database client technologies for calling their database.
A database is a very complex piece of software. Therefore, programs that communicate with a database can be
very complicated to write. To simplify this process, database client technologies often are used. They provide an
interface that is less complex than the underlying database.
These technologies are called APIs, which is an abbreviation of Application Program Interface. Figure 6.1
shows a database interface performing operations using multiple types of databases. An API is a collection of
routines, protocols, and tools for building software applications and to provide them with portable code. By
providing all the building blocks, the programmer only has to worry about the calls and its parameters and not
the details of the implementation, which may vary from system to system. Using the API technology guarantees
that all programs using a common API will have the same interface. Some of the APIs are so general that they
will work on several databases. It does not matter which API is choosen for the database connection. All are
based on similar principles; to provide functions for handling the data batch by batch on the server, but line by
line in the application.
52
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Figure 6.1. A database interface (API) can perform complex operations using multiple types of databases.
Microsoft’s Data Access Components (MDAC)
6.2.1
A way to solve the incompatibilities between different DBMS is to implement some form of general interface.
One example is Microsoft Data Access Components (MDAC). It provides data access that is independent of data
stores, tools, and languages. It has a high level, easy-to-use interface, and a low-level, high performance
interface to almost any database available. When using the Window-platform, it is most common to use any of
Microsoft’s technologies. Over the years they have been fairly many and extensive. Some of them and how they
relate are shown in figure 6.2.






ODBC (Open Database Connectivity)
MFC (Microsoft Foundation Classes)
DAO (Data Access Objects)
RDO (Remote Data Objects)
OLE DB (Object–Linking and Embedding Database)
ADO (ActiveX Data Objects)
Figure 6.2. Microsoft Data Access Connections.
53
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Each of these technologies can be a useful tool for developing database client applications. The question of when
and where to use each client technology can be very confusing.
There are three primary technologies in MDAC. ActiveX Data Objects is a high-level, easy-to-use interface to
OLE DB. Object–Linking and Embedding Database is a low-level, high performance interface to a variety of
data stores. Both ADO and OLE DB can work with relational (tabular) and nonrelational (hierarchical or stream)
data. The last one, Open Database Connectivity is another low-level, high performance interface that is designed
specifically for relational data stores. These three technologies (among others) will be presented in more detail
below.
Open Database Connectivity (ODBC)
ODBC was designed by Microsoft in the late ‘80s and early ‘90s to provide an interface to relational databases.
It is a low-level, high performance interface that supplies a homogenous programming interface to relational
database systems. These days, ODBC has become quite popular and is a generally accepted standard. By using
ODBC, any application can communicate with any RDBMS, who has an ODBC-driver available. The ODBC
API is mainly used for querying a relational database with standard-SQL. A program developer can via ODBC,
in principle, write the program without taking, which the receiving RDBMS is, into consideration. The program
connects to particular drivers that link the program to the correct database. This means that the choice of
compiler, is no longer depending on which database to connect to.
The ODBC’s big disadvantage is its bad performance. Often, the ODBC-drivers only task is to function as a
standardized link between the application and the provider of the DBMS’s native API.
Another disadvantage is that it sometimes can be difficult to call the ODBC. Therefore it is common to
encapsulate ODBC-calls in some kind of architecture, for example ADO or DAO from Microsoft.
Figure 6.3. The ODBC architecture. The ODBC API enables client applications to configure and control the
database at relatively low-level.
MFC ODBC Classes
ODBC was created to provide a uniform interface to relational databases, se figure X.6. However, the ODBC
API isn't necessarily simple. The MFC ODBC classes make ODBC programming much less complex. It
provides classes that simplify the ODBC API, but do not offer the low-level control that the ODBC API does.
Therefore, the MFC ODBC classes could be classified as a high-level database interface.
Data Access Objects (DAO)
DAO provides a useful object model for database programming. It talks directly to Access- and Jet databases and
to other databases through the Jet engine, as shown in Figure X.4. It is the ADO object model that makes DAO
54
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
better suited for object oriented development compared to a straight API. DAO provides a set of objects for
connecting to a database and performing queries.
DAO has one major disadvantage, it is that if the DAO API is used to talk to a database server such as Oracle
or SQL Server, all the calls into the database and data coming out of the database must pass through the
Access/Jet engine.
Its advantage is that DAO is easier to use than the ODBC API, but does not provide the degree of low-level
control given by the ODBC API. Therefore DAO is classified as a high-level database interface.
Figure 6.4. The DAO architecture.
Remote Data Objects (RDO)
Originally, RDO was developed as an abstraction of the ODBC API for Visual Basic programmers. Therefore,
RDO is closely tied to ODBC and Visual Basic. RDO is like DAO, easier to use than the ODBC API and it does
not offer the low-level control. Therefore it can be classified as a high-level database interface. Unlike DAO,
RDO calls the ODBC API directly. This results in better performance for applications that use the relational
database service.
Object-Linking and Embedding Database (OLE DB)
OLE DB is a general model of how applications access data. The model assumes the data is not directly
accessible by the application but resides in some separate data store, such as a file, a database, or a resource on
the Internet. OLE DB can like ODBC be classified as a low-level database API, and it has the same functionality
as ODBC. However expanded when it comes to nonrelational databases, OLE DB has its functionality to
comprise even that kind of data source. Basically, in this model the application requests information (via ADO)
from an intermediary source that returns a copy of the desired data to the application. Data delivered to the
application is held in a cache, which is used to locate, examine, and manipulate items of data. Furthermore, the
cache facilitates adding new data items and modifying or deleting existing ones. If appropriate, any changes
made in the cache are written back to the data store.
There are two kinds of OLE DB software: OLE DB consumers and OLE DB providers. Figure 5 illustrates the
relationship between them.
An OLE DB consumer is any application that uses or consumes OLE DB interfaces. For example, any
application that uses OLE DB to connect to a database server would be an OLE DB consumer. OLE DB
providers are DLLs that implement the OLE DB interfaces and do the actual communication with the data
source. OLE DB providers and ODBC drivers are similar in function. The difference between them is that OLE
DB providers implement COM interfaces instead of API functions. The concept of consumers and providers is
fundamental to OLE DB.
There is an OLE DB provider called MSDASQL.DLL that can talk to ODBC data sources. This is used by the
data sources that have an ODBC driver but do not have an OLE DB provider.
According to Microsoft, OLE DB is the future of database client development on the Windows platform.
Microsoft’s own development efforts are focused on OLE DB. ODBC will still be used in its present form, but it
is unlikely that there will be any further updates.
55
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Figure 6.5. The OLE DB architecture.
ActiveX Data Objects (ADO)
ADO is an Application Program Interface (API) that lets the programmer write applications that can access and
manipulate relational and nonrelational databases from both Microsoft and other database providers. ADO was
introduced in the winter of 1996. ADO is built on top of OLE DB, and is an OLE DB consumer. Applications
that use ADO use OLE DB interfaces indirectly. ADO’s and DAO’s object models are very similar, but the
ADO model is more flexible.
ADO was evolved from an earlier Microsoft data interface named Remote Data Objects. RDO works with
Microsoft’s ODBC to access relational databases, but not with nonrelational databases such as IBM’s ISAM and
VSAM.
According to Microsoft, ADO objects provides a fast, easy, and productive means for accessing all kinds of data
sources. ADO is implemented with a small footprint, and minimal network traffic in key internet scenarios.
ADO simplifies OLE DB, which is large and complex. A program that use OLE DB must use some complex
COM interfaces. Therefore is ADO much easier to use than OLE DB and can be classified as a high-level
database interface. ADO can also be used with more programming languages than OLE DB. For example
scripting languages, such as VBScript and JavaScript. The reason why OLE DB can not be used from a scripting
language is that these types of languages do not have pointers and therefore can not use a COM interface.
ADO provides a layer of abstraction between the application or client and the low-level OLE DB interface. ADO
is an object-oriented interface, well suitable for programming in higher level languages, such as Visual Basic.
ADO is a part of a data access strategy from Microsoft. It is called Universal Data Access (UDA) and is based
on the idea that instead of building a database of their own, they provide a universal access to already existing
databases. To make this work, Microsoft and other database companies provide a “bridge” program between the
database and Microsoft’s OLE DB. That is the low-level interface to databases. OLE DB is the underlying
system service that is used by a programmer using ADO.
6.3
Database Client Technology Summary
The database client technologies and how they relate to each other are shown in Figure X.6.
Of all the technologies mentioned above, OLE DB and ADO have the most promising future. These two
technologies are where Microsoft is doing its development work. The other technologies are not being
discontinued, but will not be further updated by Microsoft.
ADO’s object model is simple and have enough performance. Therefore is ADO the best way to start doing a
database client development.
56
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Figure 6.6. The database client technologies and how they relate to each other.
57
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Chapter 7
7
ADO Object Model
In this chapter we will give a brief introduction to the ADO Object Model, ADO Objects, and ADO Collections.
The ADO object model defines a collection of programmable objects that can be used in Visual Basic, Visual
C++, Microsoft Visual Basic, Java, and any platform supporting both COM and Automation. These objects
provide the functionality to connect to data sources, sending queries, update recordsets, and report errors. The
ADO object model contains following objects:









Connection
Command
Recordset
Record
Field
Error
Parameter
Properties
Stream
It also contains these collections:




Fields
Parameters
Properties
Errors
Figure 7.1. The objects and how they relate to each other.
The centerpieces of the ADO object model are the Connection, Recordset, and Command objects. The
Connection object is used to establish connection with the database server. To view, and manipulate the returned
data the Recordset object is used. And finally, the Command object, which is used to send commands, such as
queries, updates, and so on, to the database. The language that is used depends on the underlying providers for
the database. If it is relational databases, the command language is generally SQL.
58
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
7.1
The Connection Object
The connection object allows a user to establish a communication link with a data source. It provides a
technology to initialize and establish a connection, execute queries, and to send transactions. The underlying
OLE DB provider that is used for connecting is not limited to the ODBC providers. To specify a provider, use
the Provider property. If no provider is specified, MSDASQL (the ODBC provider) is the default provider used
for the connection, see figure X.5. To establish a connection, use the Open method of the connection object.
Before establishing connections, applications can set up a connection string. It contains a series of argument, for
example username, password, and data source (the name of the data source). All three arguments can be stated
by the user before the application is connected to the data source. Other properties that can be set up by the
Connection object are connection time-out, default database, and connection attributes.
Any kind of command can be executed by using the execute method of the Connection object. If the executed
command returns rows, a default Recordset object is created and returned. To specify a more complex Recordset,
create a new Recordset object, associate it with the Connection, and open the cursor.
The following example, written in Microsoft’s Visual Basic, demonstrates how to open a connection to an
Oracle database through a connection string whereupon a query is sent to the database.
Dim Cn As New ADODB.Connection
Dim rs As New ADODB.Recordset
Dim ConnectionString As String
ConnectionString "Provider= OraOLEDB.Oracle.1; Data Source= Example_db"
Cn.Open (ConnectionString)
Set rs = Cn.Execute (“SELECT * FROM Example_Table”)
Example 7.1. Connecting to a database.
7.2
The Command Object
The Command object represents a command, also known as a query statement, which can be processed by the
data source. Commands can return rows, and if the provider is capable, it can also handle parameters. The
Command object is optional in the ADO model because some data providers can not supply command execution.
The Provider is software that exposes data to an ADO application either directly or via a service provider, one
example is query processing.
Commands can be simple SQL statements or some other language the data provider recognizes. It can also be
calls to stored procedures in the database. A stored procedure is a precompiled collection of code such as SQL
statements. They are stored within a database and can be executed with one call from an application. The
Command is executed by using the Command’s Execute method. Another way is to create a Recordset object
and associate it with the Command object when opening the cursor (cursor is a database element that controls
record navigation).
Depending on what is specified in the ActiveConnection property, the command object either opens a new
connection or uses an existing one to perform queries. To use an existing connection, set the ActiveConnection
property to a reference of a connection object. If the ActiveConnection property is specified with a connection
string, a new connection is established for the command object. Executing query strings can generate a
Recordset object, multiple Recordset objects, or no result set at all. For example, when a data definition language
query is executed, no result is set. When a single SELECT statement is executed, a Recordset is generated.
Finally, when a batch of SELECT statements or a stored procedure is executed, more than one Recordset is
generated.
59
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
7.3
The Recordset Object
The Recordset object provides methods for manipulating result sets from a provider. Possible operations are to
add, update, delete, and scroll through record in the result set. When using the ADO Object Model, almost all
manipulation of data is done by using Recordset objects. All Recordset objects consist of records (rows) and
fields (columns). The following example demonstrates how to use the Recordset object to open a connection and
retrieve a result set. A connection string is used, the attributes passwd_tb, user_tb, and db_tb are all stated by the
user and correspond to password, username, and the name of the database respectively. When the query has been
sent, the answer is printed to the screen.
Dim rs As New ADODB.Recordset
Dim ConnectionString As String
ConnectionString = "Provider=OraOLEDB.Oracle.1;" & _
"Password=" & passwd_tb & ";" & _
"Persist Security Info=True;" & _
"User ID=" & user_tb & ";" & _
"Data Source=" & db_tb & ";"
rs.Open "select * from EmployeeTable", ConnectionString
While (Not rs.EOF)
Debug.Print rs(0)
rs.MoveNext
Wend
rs.Close
‘ Print the first column of the table of the current Recordset
‘ Move to the next Recordset i.e. move to the next row in the table
Example 7.2. Connecting to a database and sending a query.
Note: The “& _” character combination is used for continuing long lines in Visual Basic.
7.4
The Record Object
The Record object represents one row of data, and has some similarities with a one-row Recordset. Depending
on the provider, Record objects may be returned directly from the provider instead of a one-row Recordset. One
example, is when an SQL query that returns only one row is executed.
7.5
The Fields Collection and the Field Object
The Field interface represents a column in a Recordset that is used to obtain, and modify values.
The Fields collection and the Filed object provide operations to access each data column of the current record.
The Fields collection can be accessed through the Recordset object and the Field object can be accessed through
the Fields collections using the default indexing method. The Field object can be used to compose a new record
or change existing data.
7.6
The Parameter Object
The parameter Collection provides parameter information and data for the Command object. The Command
object includes a collection of Parameter objects. If the provider can support commands with parameters, the
Parameters collection will contain one parameter object for each parameter in the command. The Parameters
collection consists of Parameter objects. Both the Parameters collection and the Parameter object are only
needed when the query string in the Command object requires parameters.
60
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
7.7
The Properties Collection and the Property Object
The Properties collection contains all the Property objects for a specific instance or an object. And the Property
object represents a dynamic characteristic of an ADO object that is defined by the provider. There are two types
of properties: built-in and dynamic.
Built-in properties are implemented in ADO and immediately available to any new object using the
MyObject.Property syntax.
Dynamic properties are defined by the underlying data provider. These properties appear in the Properties
collection for the appropriate ADO object. Dynamic properties can be referenced only through the collection,
using the MyObject.Properties (0) or MyObject.Properties (“name”) syntax.
7.8
The Errors Collection and the Error Object
The Error object represents an error returned from a data source. To retrieve provider error information, the
Errors collection and Error object is used. Errors are always retrieved from the Connection object, but can be
generated by a method call or property of the Connection, Command, or Recordset objects. This object is only
needed when the data source can return multiple errors for a single call, therefore is this object optionally.
The Errors collection can also store warnings. A warning does not stop the code from executing, and a its
positive number values differentiate it from a real error. The Error object makes it possible to retrieve the error
description and source of the error.
7.9
The Stream Object
In tree-structured hierarchies such as a file system or an e-mail system, a Record may have a default binary
stream of bits associated with it that contains the contents of the file or the e-mail. A Stream object is used to
manipulate fields or records containing these streams of data.
61
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Chapter 8
8
Application Manual
In this chapter we will present a user’s manual to the application we wrote.
To the database, we wrote an application from where a user can extract data from the database and create a
configuration file. The application is written in Microsoft’s Visual Basic.
In the first form (Login form), the user states username, password and the name of the database. The username is
“sys” and the password is “change_on_install”. The name of the database is xjobb.serop.abb.se.
Figure 8.1. Login form
When the user has logged in, the second form (Query form) is loaded. In this form, the user can send an SQLquery to the database, search for a table, search for an attribute in a table and create a configuration file.
62
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Figure 8.2. Query form
If the user want to send a query to the database, write the SQL-code in the textbox named “Query” and click on
“Ask query (sql)”. Note, the ending semicolon (;) must be excluded. The answer will be shown in the grid. To
have the answer written to a file, state the path and filename in the textbox named “File name”, and click on
“Write to file”. The file contains of two columns, the left is the name of the attributes and the right is the value.
The contents of a table can viewed (without writing SQL-code) by stating the name of the table in the textbox
named “Table” and clicking on “Show table”. The answer will be shown to the grid. Even here, the answer can
be written to a file. State the path and filename, and click on “Write to file”.
To search for an attribute name in a table, state the name of the table in the textbox named “Table” and the name
of the attribute (or part of it) in the textbox named “Find”. Note that the name of the attribute must be written in
capital letter. All attribute names containing the string will be shown in message boxes. To have the answer
written to a file, state the path and filename, and click on “Write to file”.
Sometimes it is desirable to have the answer written to a file, to do that, state the path and name of the file in the
textbox named “Filename” and click on “Write to file”. If no filename is stated, the default name is “New_File”
and is placed directly under C:.
The answer of the last performed query is placed in a variable called answer_query. This variable must be
cleared before a new query is sent to the database. This is done by clicking on the “Clear form” button. This
clears all the textboxes in the form as well.
One of the principal purposes of this application is the possibility of making a syntactic correct configuration
file. To do that, state the arm length, load mass and robot family. Filename is optional, if no filename is stated
the default name is robotfamily_armlength_loadmass.cfg. The file is placed directly under C:.
To get help online, write the name of the textbox or button in the textbox named “Find”. The requested help will
be shown in a message box.
63
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Disconnecting the database is done by clicking on the “Disconnect” button. The Login form is loaded and the
user can login to another database.
The program is ended by clicking on the “End program” button.
64
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Chapter 9
9
Development Tools
Database applications are usually written in third-generation programming language (C++, Java, COBOL, and
Fortran) or using a fourth-generation language, such as SQL, embedded in a third generation language.
Fourth-generation language (4GL) is a “shorthand programming language”. It is non-procedural – the user
defines only what is to be done. 4GL applications are built with so-called fourth-generation tools. The user only
defines parameters to the tools that use them to generate an application. The use of fourth-generation tools can
improve productivity and produce programs that are easier to maintain.
Target DBMSs often have they own fourth-generation languages and tools:
4GLs for databases encompass:
 presentation languages (query languages, report generators);
 specialty languages (database languages);
 application generators that define insert, update and retrieve data from the applications;
 very high-level languages that are used to generate application code;
DBMS generator tools often are:
 form generators;
 report generators;
 graphics generators;
 application generators;
9.1
Oracle Developer
Oracle Developer is an environment for building database applications. Its features enable very fast creation of
fully functional applications. For that purpose Oracle Developer provides these integrated builders:
 Project Builder;
 Form Builder;
 Report Builder;
 Graphics Builder;
 Procedure Builder;
 Schema Builder;
 Query Builder;
 Translation Builder.
The builders are easy to understand and easy to use with help of many tools, wizards and templates. The design
of the applications is almost 100% visual, made with design editors, drag-and-drop, and visible class inheritance
(similar to Microsoft Visual Basic). Object Navigator gives a hierarchical picture of forms, charts, reports etc in
the projects.
The application needs to be written only once to be deployed in many ways:
 application and database on the same machine;
 client/server configuration;
 distributed database;
 web based configuration.
65
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Figure 9.1. Overview of Oracle Developer
9.1.1
Project Builder
Project Builder is the most important part of the Oracle Developer. It coordinates all the parts of the application
into one central project. The files associated with the application can be of any type, including forms, reports,
displays, 3GL modules, documentation, and test scripts. For simple editing of the files Project Builder provides
the Launcher, a toolbar to which you can add the (even third-party) editing tools. The whole project can be built
by one simple command in which all the files will be compiled according to their types.
9.1.2
Form Builder
With Form Builder users can build applications for retrieving, entering, modifying and saving information in the
database. A complete application can be combined of four types of modules:




Form Modules – main body of a Form Builder application, includes the objects that end users
interact with.
Menu Modules – comprised of menus and menu code.
Object Library Modules – common repository for standard Form Builder objects.
PL/SQL Library Modules – collection of client-side code that can be shared across modules and
applications.
The objects that users use to interact with the application are called items. Items also display information to endusers. They are divided between blocks, which are logical containers for items. Blocks are the basic unit of
information in a form module ant are placed on background objects, called canvases. Canvases can contain
multiple blocks and other graphic elements. Canvases can contain multiple blocks and other graphic elements.
Every canvas must be linked with a window. A window shows the canvases, one at a time. By itself, a window is
just and empty frame with title bar, menus, scrollbars and other handles for interaction.
9.1.3
Reports Builder
Reports Builder is used to design production-quality reports, in a variety of formats, to meet the need of sharing
information on a timely basis, across an enterprise. Reports Builder looks and works very similarly to the Form
Builder.
66
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
A report is determined by two models, data model and layout model. The data model defines the data to be
included in the report. The layout model defines the positioning and appearance of data and other objects in the
report.
9.1.4
Graphics Builder
Graphics Builder produces interactive graphical applications, called displays, which represent and interact with
data visually. Each display contains a layout, on which all the graphical objects are shown. A layout contains
layers with individual visual components, like charts, graphics, and text. At runtime user can hide, show a
rearrange layers to present different graphical view.
The display also contains menus, data queries and PL/SQL constructs.
9.1.5
Procedure Builder
Procedure Builder is an editor, compiler and debugger for program units, libraries, and triggers in PL/SQL.
9.1.6
Schema Builder
Schema Builder enables quick, graphical creation, copying, modifying and removing of database objects such as
tables, views, indexes and relationships. A schema is a logical collection of such objects, which schema Builder
uses as a way of viewing and modifying any combination of objects in the database. The Schema Builder does
not save the schema itself, but performs SQL operation on objects included in the schema.
9.1.7
Query Builder
Query Builder is an easy-to-use data access tool that is used for quick data retrieving for analysis and reporting.
A query is built in these steps:





Select Tables – Select tables from which you want to retrieve data. Query Builder automatically
displays underlying relationships between the chosen tables.
Select Columns – Select the columns you want to be retrieved from the database.
Refine the Query – Create conditions with Query Builder’s graphical interface, or the Query
Builder will retrieve every row from every column you selected.
Execute the Query – Query Builder displays the requested data in from of a table.
Manipulate and Format Query Results – Perform variety of operation on the displayed data
 define new columns;
 sort columns;
 group columns;
 select which columns to display;
 select how the data is to be displayed;
 set up summary;
 break columns.
67
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
9.1.8
Translation Builder
Translation Builder is a tool that simplifies translation of applications into any language supported by Oracle
Products. The translation is done in four steps:




9.2
Import Strings – Import translatable string from the application.
Add Translation (optional) – Add and reuse previous translation (called attached glossaries) in the
target language.
Translate Strings – Translate string with Translation editor. The attached glossary can be used as
lookup feature.
Export Strings – Translation Builder merges the translation with the original application, which
now contains both original and translated strings.
Oracle Designer
Oracle Designer is a toolset for automating construction of flexible, graphical, client/server applications. It
combines business and design modeling and works integrated with Oracle Developer.
On the server side Oracle Designer supports various database types, most important of them being Oracle7 and
Oracle8 databases. On the client side Oracle Designer supports
 generation of Oracle Developer forms, reports and libraries;
 generation of Visual Basic applications;
 generation of WebServer applications;
 generation of MS Help integrated with other generated applications;
Oracle Designer enables effective team working. All data is stored in central Repository, which can be split into
separate applications. All members of the project can have access to the relevant parts. The managers can
monitor the work in progress by special impact analysis tools.
Development approaches supported by Oracle Developer are
 End User Driven;
 Information Driven;
 Process Model Driven;
 Design Capture Driven;
Figure 9.2. Oracle Designer Development Process.
68
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
The development process is divided into, process modeling, system analysis, transformation, design and
generation (see figure 9.2).
Design Editor
The generation environment of Oracle Designer is called Design Editor. It is a single user interface for both
client and server applications. The design information is stored as design level object definitions that are shared,
synchronously maintained, and used to generate databases and client applications by the cooperative generators.
The work can be done in three different ways. The user can
 use different special purpose design components to create, edit and delete the design level objects.
 work with help of design guides that guide him/her through the entire process.
 work with design wizards, which step him/her through specific tasks.
To present the user with only the information that is needed to perform main design processes, the information is
presented in different views.
9.2.1
Repository
Repository underlies the whole development and stores all the objects and information needed for it. The
Repository can be controlled using the Repository Management Tools.
Repository Administration Utility
Repository Administration Utility is a tool for managing a Repository environment. The manager can:
 install, upgrade and back up the repository;
 display the contents;
 recreate invalid objects;
 edit or extend structure of user features.
Repository Object Navigator
For creating and maintaining application systems and their object definitions, Oracle Designer provides the
Repository Object Navigator. This tool can be used in any stage of the database or application development. It
presents the information in the Repository (objects, hierarchies and links) in a structure that is easy to navigate.
The Repository Object Navigator can be used for invoking other Oracle Designer editing tools.
Matrix Diagrammer
Matrix Diagrammer is a tool for manipulating Repository elements in the form of matrix diagrams. Such
diagram consists two-three axes, each corresponding to different element type, and intersection cells, which
indicate the association between two elements. Different matrices are used in different stages of system
development.
Repository Reports
The Repository Reports tool is used for examining the contents of the Repository. It provides 100 predefined
reports, but advanced users can create their own reports.
9.2.2
Process Modeling
Process modeling means developing a diagram that shows the activities of the business and the sequence in
which they take place. The modeling helps the project members to understand how the organization functions.
The model provides a focus for the group to agree on effectiveness of the processes and possible improvements
to them.
Process Modeller
Process Modeller is the tool designed for process modeling. It integrates business process models into the
systems developing process. Describing business processes is very easy and is done by point-and-click methods.
Process Modeller provides multimedia features to enhance a process diagram with icons, sound images and
video clips, and animation features for dynamic process illustration.
69
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
9.2.3
System Analysis
System Analysis means specifying and recording a detailed description of the business requirements of an
organization. Oracle Designer provides environment for creating diagrammatic models of the entities, functions
and flows of data in the system that make up the organization.
Entity Relationship Diagrammer
The information needs of a business can be defined as an Entity-Relationship Diagram using the Oracle Designer
Entity Relationship Diagrammer. The diagrams can be drawn for entire systems, or for subsets of systems, which
is enabled by the fact that one entity can appear in numerous diagrams.
Function Hierarchy Diagrammer
Function Hierarchy Diagrammer is used to model hierarchies of all the functions that are preformed by a
business identified in process modeling. Function hierarchy shows the activities carried out by the business. By
the process of decomposition, an analyst takes these high-level functions and decomposes them into more
detailed functions. The lowest level of functions are called elementary business functions and are defined in
terms of the events that trigger them, the entities, and the relationships between the entities and their attributes.
With help of the Function Hierarchy Diagrammer the analyst can identify which parts of the business can be
automated.
Dataflow Diagrammer
Dataflow diagramming means creation of diagrams that show how the data flows through the business
organization. The diagrams are drawn to show the data dependencies, system components and context of project.
Each diagram represents a single business function (high-level oar elementary) for an application system.
Dataflow Diagrammer enables creating and maintaining business functions, datastores, dataflows and externals.
9.2.4
Transformation
With transformation tools project members can quickly transform requirements defined during system analysis
into default database and application designs. These designs can immediately be generated to prototypes and
reviewed by users.
Database Transformer
The Database Transformer creates the database design from entity-relationship diagrams created by project
members and stored in the Repository. The Transformer creates table definitions of entity types, column
definitions of attributes, and constraint definitions to implement the relationships, unique identifiers and indexes,
which support foreign keys.
The project member has complete control over the types and details of mappings used in transformation process.
The model can be created in one step, or can be progressively refined. It can be done as a whole or a small area
at a time. Which types of elements that the Database Transformer creates or modifies is up to the user.
Application Transformer
Based on the existing database design Application Transformer creates application design from the function and
business unit definitions stored in the Repostitory. The functions are converted into candidate modules, which
can be implemented as some of the supported applications. The data usages of the functions are transformed to
module data usages that define what tables and columns a module uses, and how it uses them. Business units
defined in process modeling (describe parts of business, the data used by the part and functions carried out by it)
are used to create candidate menu modules and menu structures.
The candidate modules, menu modules, and module data usages are included in the design only when the user
accepts them.
9.2.5
Designing and Generating Databases
Design Editor is a single modeling and generation editor for databases. It enables the project member to:
70
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt



optimize the database design and define tables, columns and other elements with server model editor;
define the procedural logic that implements business rules using Logic Editor component;
invoke the Server Generator.
Server Generator
Server Generator enables building of databases from design specifications in the Repository. This tool can
generate DDL scripts to create physical database structures or create the physical database structure itself, for
several database types. The Server Generator is also used for creating Server API interface utilities that enables
client applications to insert, update, delete, lock and query data in the tables. One interesting feature is that the
Server Generator can extract database definitions from existing, physical databases, or from DDL scripts and
store the captured definitions in the Repository.
9.2.6
Designing and Generating Applications
Design Editor provides a single modeling and generation environment for several application languages.
Form Generator
Form Generator creates applications with all the features of Oracle Developer Form Builder applications.
Generated forms include Oracle Applications standard functionality (descriptive flexfields, current record
indicator items). For efficiency the code can be partitioned between the client and the sever using the API
created by Server Generator. Module Components of different languages can be included in the generated Form
Builder application. Form Builder applications created by Oracle Developer can be reverse-engineered into the
Oracle Designer Repository.
Report Generator
The Report Generator is used for generating Oracle Developer reports. As default the reports are saved as Oracle
Developer Report Builder report definition files. They can also be generated for HTML, HTMLCCS, or PDF
output for deployment on the WWW. The reports can also be integrated with other Oracle Developer
applications
Visual Basic Generator
Oracle Designer can produce fully-functional Visual Basic applications with the Visual Basic Generator. The
applications comprise one or more windows, each containing one ore more zones through which data can be
queried or manipulated with either Oracle Objects for OLE or Visual Basic DAO programming interface. These
applications can be loaded into a Visual Basic design environment where the user can make more refinements.
WebServer Generator
For creation of WebServer applications there is WebServer Generator. During generation WebServer Generator
creates (besides the application) PL/SQL packages, which are installed onto an Oracle WebServer. The
application can be run with any HTML Browser. The application enables user to manipulate and query data over
the WWW and uses the created PL/SQL API packages.
Library Generator
Oracle Designer Library Generator creates Oracle Developer library modules. Such module can be used by all of
Oracle Developer modules. Library Generator can also capture existing Oracle Developer library modules into
the Oracle Designer Repository.
MS Help Generator
Project member can create Microsoft Windows Help with MS Help Generator. It is independent from application
generators, which enables the project member to choose if he wants to generate MS Help during module design
or when the application design is complete. During the design of MS Help user defines Help text against
modules, module components, and items.
71
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
9.3
DeZign for Databases
DeZign for Databases (third-party shareware) is a data-modeling tool that helps designing desktop and
client/server databases. The design is done with entity-relationship diagrams. The model information can be
displayed at various levels, which can be used at various stages of model development:
 entity level;
 primary key level;
 attribute level;
 primary key with unique attributes level.
The logical and physical data models are supported by automatic foreign key migration at design time. Directly
from the ER Diagram, DeZign can create DDL (Data Definition Language) scripts for different supported
database-types.
DeZign for databases supplies version-control system by automatic saving of older versions of the diagram when
the user saves the project to disc.
Reports with descriptions and other relevant information in different levels of detail can be generated and
exported to HTML-files or text-files.
Reverse engineering (import of DDL scripts) is provided by separate utilities called ImportER Scripts, ImportER
Tables and ImportER Access.
Figure 9.3. Overview of DeZign for Databases.
72
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Chapter 10
10
Conclusions
The purpose of the thesis was to investigate if it is possible to use a commersial database management system
instead of param_db. The thesis also included writing an application with which a user can create configuration
files and extract data without knowing SQL.
First, we chose Oracle8iTM as database management system. After that we limited the amount of data which we
used to create a relational database. To furhter lower the amount of data, we eliminated the redundant data.
When we were done, we succeed to lower the total amount of rows from 216 to 88.
The application was implemented in Microsoft Visual Basic. To connect the application with the database we
used the ActiveX Data Object (ADO) Application Program Interface (API).
We also found that there are many tools that faciliate design and development of the databases and the database
applications. The tools are supplied by both the DBMS developers and Third Part suppliers.
The result of this thesis is that using a commersial database management system is not only possible but very
desirable. The usage of DBMA gives many advantages, as almost automatic control of data redundancy and
consistency. The user can get an overall picture, because the database is easy to make user-friendly with help of
databse applications. Users of such applications do not have to be familiar with SQL or the DBMS in use. Such
applications are also relativelly easy to develop due to the APIs and the supplied development tools. Usage of a
commercial system gives even more advantages in the form of sharing of data. For example, users can
simultaneously access the data in the database. For that purpose, the database has to be stored on a server or be
distributed. Furthermore the database can be made accessible to the customers through the Internet. In this way,
the customers can (after few inputs and choices) download the right configuration file to their controllers. As it is
today, the employees have to waste their time on creating the configuration files and sending them to the right
customers.
Using the commersial database management system has also disadvantages. A DBMS is more complex than a
special purpose made database system, because it has much more functionality. If the ABB Automation
Technology Products chouses to use a commersial system, at least one person must fully understand its
functionality. Due to the complexity of the DBMS, the database and the DBMS demands lots of space. In our
case, the database took almoste one gigabyte of the secondary storage, and most of it was the DBMS and its
functionality. Such size and complexity has a negative influence on the performance of the database. Special
purpose databases tend to be less complex, demand less space and have in overall better performance. But the
commersial system’s performance can be tuned, which can reduce the less disarable features.
The focuse of this work has not been on deciding wheter Oracle8i TM is best suited as a database management
system for handeling the configuration files. Desiding wich DBMA is best suited need not to be ommitted and
therefore such investigation could be a goal for another thesis.
A careful design of the whole database should be made. Finding better key values is very important, because the
one used today are not informative ehough. Furher more a throughout normalization should be done on the
design by someone who understands true meaning of the configuration data. And a careful physical design
should be made for the chosen DBMS during which efficiency and security should be the main goals.
Manual insertion of data into the database would be painfully monotone, due to the huge amount of data. Beside,
this type of solution is prone to produce many errors. The best way to insert the data to the database would be to
produce a parser, that reads the data from the dat-files and produces SQL-code, which upon running would do
the insertion.
73
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
A research could be done to find out if the configuration files are the best way of moving configuration data
between the configuration database and the database on the controllers, of if there is a better way.
We can now state, that we have succeeded with this thesis, because we have managed to prove that the
commersial database management system can be used instead of the system used today (param_db). We have
shown how such system can be used, and how to extract the configuration data.
74
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
References
Connory, T. and Begg, C. (2002). Database Systems 3rd edition, Addison Wesley
Date, C. J. An introduction to database systems, 7:th edition
DeZign for Databases, http://www.datanamic.com/dezin/index.html
Forms Developer 6i Quick Tour, follows the installation of Oracle Developer
Hierarchical Database Models, http://escher.cs.ucduvis.edu/ecs189f/lect18.htm
Oracle8tm (1997). Application Developer’s Guide release 8.0, Oracle.
Oracle Designer Product Overview, http://otn.oracle.com/doc/des60/24611/contents.htm
Report Developer 6i Quick Tour, follows the installation of Oracle Developer
SQL övningskompendium (2000), Department of Business Studies and Information System at Mälardalen
University
75
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Appendixes
A.
B.
C.
D.
E.
F.
Entity Descriptions
Relationship Descriptions
Attribute Descriptions
Tables Created during design of Conceptual Data Model
Entity-Relationship Diagram
Relvars in DBDL (Database Definition Language)
76
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Appendix A
Entity Descriptions
Entity name
MECHANICAL_UNIT
ROBOT
ROBOT_TYPE
JOINT
AXC_FILTER
Description
Mechanical unit, can be
robot or a single
Aliases
A mechanical unit with
more than one axis
A type of the robot in use
Specific individual
A joint is an axis. It moves
an arm.
Control filter for en axis
ARM
PARALLEL_ARM_LOAD
Arm is a part of a robot.
ARM_TYPE
ACC_DATA
ARM_CHECK_POINT
Type of the arm in use
Occurrence
Every unit that is
controlled by the system is
a mechanical unit
Every robot is a
mechanical unit
Every robot is of some
type
There is as many joints as
axis per robot
Every axis is controlled in
some way
Every joint has an arm
Some arms have to use
parallel arm load.
77
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Appendix B
Relationship descriptions
Entity type
Relationship type
Entity type
MECHANICAL_UNIT
ROBOT_TYPE
JOINT
is a
is type of
is part of
moves
controls
is of
ROBOT
ROBOT
ROBOT
ARM
JOINT
ARM_TYPE
ARM
ARM
ARM_TYPE
AXC_FILTER
ARM
ACC_DATA
ARM_CHECK_POINT
PARALLEL_ARM_LOAD
Cardinality
ratio
1:1
1:M
1:M
1:1
1:M
1:1
1:M
1:M
1:M
Participation
P:T
T:T
T:P
T:T
T:T
T:T
T:T
T:P
T:P
78
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Appendix C
Attribute Descriptions
Entity
Names of attributes
Description
MECHA
NICAL_
UNIT
name
Mechanical unit name
use_robot_family
use_robot_arm_load
use_robot_load_mass
user_frame_moved_by
stand_by_state
speed_offset_adjustment
activate_at_start_up
do_not_allow_deactivation
ROBOT
family
arm_length
default_load_mass
use_robot_type
use_joint_0
use_joint_1
use_joint_2
use_joint_3
use_joint_4
use_joint_5
base_frame_pos_x
Data type
and length
char[16]
Constraint
S, O
Mechanical unit contains
robot
Mechanical unit contains
robot
Mechanical unit contains
robot
Name of robot or single
that moves the user
frame
If NO, then the unit goes
to control on
immediately with Motor
on
Adjust speed offset when
activating mech unit after
Warm/Cold start
Activate the mech. unit
at start-up
Mech. unit is not allowed
to be deactivated
Name of the robot family
The chooseable arm
length
Mass of default load [kg]
char[10]
Id name of robot type
Id name of 1st joint
Id name of 2nd joint
Id name of 3rd joint
Id name of 4th joint
Id name of 5th joint
Id name of 6th joint
Position of base frame
wrt world coord system
[m]
char[20]
char[16]
char[16]
char[16]
char[16]
char[16]
char[16]
float
Default
value
Key
Null?
Derived
primary
No
No
S
foreign
Yes
No
char[10]
S
foreign
Yes
No
char[10]
S
foreign
Yes
No
char[16]
S
Yes
No
BOOL
S
No
No
BOOL
S
FALSE
No
No
BOOL
S
FALSE
No
No
BOOL
S
FALSE
No
No
primary
primary
No
No
No
No
primary
No
No
foreign
foreign
foreign
foreign
foreign
foreign
foreign
0
No
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
No
No
No
0
No
No
0
No
No
char[10]
char[10]
char[10]
base_frame_pos_y
float
base_frame_pos_z
float
same as
default_
load_ma
ss in
ROBOT
_TYPE
S
S,O
S,O
S,O
S,O
S,O
S,O
S,O, 1000 to
1000
S,O, 1000 to
1000
S,O, 1000 to
79
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
base_frame_orient_u0
Orientation of base frame
wrt world coord system
[quaternion]
float
1
No
No
S,O, –1
to 1
S,O, –1
to 1
S,O, –1
to 1
S,O
0
No
No
0
No
No
0
No
No
Yes
No
0
No
No
0.0
No
No
0.0
No
No
0.0
No
No
0.0
No
No
0.001
No
No
0.001
No
No
0.001
No
No
0.0001
No
No
0.0001
No
No
0.0001
No
No
float
S,O,
6.28318
6
to
6.28318
6
0.0 to
500.0
-5.0 to
5.0
-5.0 to
5.0
-5.0 to
5.0
S,O, 0
to 4.0
S,O, 0
to 4.0
S,O, 0
to 4.0
S,O, 0
to 1.0
S,O, 0
to 1.0
S,O, 0
to 1.0
S,O
0
No
No
float
S,O
0
No
No
float
S,O
0
No
No
float
S,O
0
No
No
float
S,O
0
No
No
float
S,O
0
No
No
float
S
0
No
No
float
S
0
No
No
float
S
0
No
No
float
S
0
No
No
base_frame_orient_u1
float
base_frame_orient_u2
float
base_frame_orient_u3
float
base_frame_coordinated
Name of robot or single
that moves this robot's
base position
Orientation of gravity wrt
base frame [rad]
char[16]
base_mass
Mass of base [kg]
float
base_mass_centre_x
Mass centre of base xcoordinate [m]
Mass centre of base ycoordinate [m]
Mass centre of base zcoordinate [m]
Orientation tolerance for
general kinematics [rad]
Orientation tolerance for
general kinematics [rad]
Orientation tolerance for
general kinematics [rad]
Position tolerance for
general kinematics [m]
Position tolerance for
general kinematics [m]
Position tolerance for
general kinematics [m]
Cartesian upper x bound
for work area [m]
Cartesian lower x bound
for work area [m]
Cartesian upper y bound
for work area [m]
Cartesian lower y bound
for work area [m]
Cartesian upper z bound
for work area [m]
Cartesian lower z bound
for work area [m]
Cartesian bound on arm
check point [m]
Cartesian bound on arm
check point [m]
Cartesian bound on arm
check point [m]
Cartesian bound on arm
float
gravity_beta
base_mass_centre_y
base_mass_centre_z
rot_x_tol
rot_y_tol
rot_z_tol
pos_x_tol
pos_y_tol
pos_z_tol
upper_work_area_x
lower_work_area_x
upper_work_area_y
lower_work_area_y
upper_work_area_z
lower_work_area_z
lower_arm_cp_bound_x
lower_arm_cp_bound_y
lower_arm_cp_bound_z
upper_arm_cp_bound_x
1000
S,O, -1
to 1
float
float
float
float
float
float
float
float
float
80
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
upper_arm_cp_bound_y
upper_arm_cp_bound_z
ROBOT_
TYPE
linear_jog_allowed
use_six_axis_corvec
name
type
error_model
no_of_joints
master_robot
use_default_load
default_load_mass
check point [m]
Cartesian bound on arm
check point [m]
Cartesian bound on arm
check point [m]
linear jog allowed
Use six axis corvec
Unique robot_type Id
name
Choice of pre-defined
robot
types from
man_robot_type
Model used to determine
kinematic configuration,
ex. "NOMINAL"
Number of joints in the
robot's kinematic
description
States if this robot is the
system master robot
Id name of default load
Mass of default load [kg]
float
S
0
No
No
float
S
0
No
No
FALSE
FALSE
No
No
No
No
No
No
char[16]
No
No
char[16]
No
No
int
No
No
FALSE
No
No
bool
bool
char[20]
primary
bool
char[20]
float
0
Yes
No
No
No
0
No
No
float
float
-3 to 3
0
No
No
float
-3 to 3
0
No
No
float
0 to
1000
0
No
No
float
0 to
1000
0
No
No
float
0 to
1000
0
No
No
upper_joint_0_bound_reduce
d
Center of mass location
for default load [m]
Center of mass location
for default load [m]
Center of mass location
for default load [m]
Inertia at center of
gravity of default load
[kg*m*m]
Inertia at center of
gravity of default load
[kg*m*m]
Inertia at center of
gravity of default load
[kg*m*m]
Reduced upper joint limit
for 1st joint [rad]
0 to
10000
-3 to 3
float
100000
No
No
lower_joint_0_bound_reduce
d
Reduced lower joint limit
for 1st joint [rad]
float
-100000
No
No
lower_joint_2_bound_reduce
d
Reduced lower joint limit
for 3rd joint [rad]
float
-100000
to
10000
-100000
to
100000
-100000
to
10000
1 to 100
1 to 20
1 to 10
-100000
No
No
1
1
1
No
No
No
No
No
No
float
0
No
No
float
0
No
No
float
0
No
No
default_load_mass_centre_x
default_load_mass_centre_y
default_load_mass_centre_z
default_load_inertia_x
default_load_inertia_y
default_load_inertia_z
soft_static_position_ratio
soft_static_speed_ratio
soft_influence_pos_speed_rat
io
work_area_cylinder_radius
work_area_cylinder_min_z
work_area_cylinder_max_z
float
float
float
Cylindrical bound on arm
check point [m]
Cylindrical bound on arm
check point [m]
Cylindrical bound on arm
check point [m]
81
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
base_pose_rot_u0
base_pose_rot_u1
base_pose_rot_u2
base_pose_rot_u3
supervision_deactivate_in_au
to_mode
par_id_type
JOINT
name
logical_axis
use_axc_filter
use_arm
connector_board
uncalibrated_control_master_
type
normal_control_master_type
lock_joint_in_hardware
lock_joint_in_ipol
lock_joint_in_servo
passive_joint
slave_to_joint
stand_alone_mode_allowed
AXC_
FILTER
name
position_controller_mode_4
ms
reserve_time_slot
anti_windup_tracking_time
ARM
speed_ref_based_torque_limi
tation
name
use_arm_type
use_acc_data
use_check_point
Rotation between int and
ext baseframe definitions
[quaternion]
Rotation between int and
ext baseframe definitions
[quaternion]
Rotation between int and
ext baseframe definitions
[quaternion]
Rotation between int and
ext baseframe definitions
[quaternion]
Supervision is deactive in
aoto and 100% manual
mode
Type of identification
allowed for this robot
Unique joint name
Axis number as seen by
RAPID program
used axc filter
Id name for arm
Connector board number
(1..4)
uncalibrated control
master type
normal control master
type
Flag indicating if the
joint has mea and drive
system in DSP
Flag indicating if the
joint is permanently
locked in ipol
Flag indicating if the
joint is permanently
locked in ipol
Flag indicating if the
drive unit should be
passive or not
The joint is a position
slave to joint named xxx
This joint is allowed to
move by external control
axc filter name
float
-1 to 1
1
No
No
float
-1 to 1
0
No
No
float
- 1 to 1
0
No
No
float
-1 to 1
0
No
No
BOOL
FALSE
No
No
char[16]
default
No
No
primary
No
No
No
No
foreign
foreign
No
No
No
No
No
No
Run position loop with 4
ms sampling time
Reserves ctl time slot ==
mea time slot
Time constant for the
torque_limit_excess
feedback [s]
Set calculation-mode for
torque limit speed
Unique ARM Id name
Id name for arm type
Id name for acc data
Id name for check point
BOOL
char[16]
short
S
S, 0 to
12
char[16]
char[16]
int
S
S, 1 to 4
char[16]
S
No
No
char[16]
S
No
No
bool
S
FALSE
No
No
bool
FALSE
No
No
bool
FALSE
No
No
bool
FALSE
No
No
Yes
No
No
No
No
No
FALSE
No
No
BOOL
FALSE
No
No
float
-1
No
No
BOOL
FALSE
No
No
No
No
No
Yes
No
No
No
No
char[16]
S
bool
S
1
FALSE
char[16]
char[16]
char[16]
char[16]
char[24]
primary
S,O
S
S,O
S
primary
foreign
foreign
foreign
82
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
independent_joint_on
upper_joint_bound
lower_joint_bound
Lower joint limit (arm
side), rad
float
upper_joint_bound_max
Maximal value for
upper_joint_bound (arm
side), rad
float
lower_joint_bound_min
Minimal value for
lower_joint_bound (arm
side), rad
float
ind_upper_joint_bound
Independent upper joint
limit (arm side), rad
float
ind_lower_joint_bound
Independent lower joint
limit (arm side), rad
float
upper_coupled_joint_bound_
2
Coupled upper joint limit
with joint[this + 2] (arm
side), rad
float
lower_coupled_joint_bound_
2
Coupled lower joint limit
with joint[this + 2] (arm
side), rad
float
upper_joint_coupl_bound
Coupled upper joint limit
rel joint[this - 1] (arm
side), rad
Coupled lower joint limit
rel joint[this - 1] (arm
side), rad
Calibration position (arm
side) rad
float
S
S,O,
125663
7 to
125663
7
S,O,
125663
7 to
125663
7
200000
00 to
200000
00
200000
00 to
200000
00
S, O,
200000
00
to
200000
00
S,O,
200000
00 to
200000
00
S,O,
251327
4 to
251327
4
S,O,
251327
4 to
251327
4
-3 to 3
float
- 3 to 3
0
No
No
float
0
No
No
Acceleration ratio for
identification of payload
float
S,O –
1000 to
1000
S, 0.2 to
1.0
1.0
No
No
lower_joint_coupl_bound
cal_position
load_id_acc_ratio
Upper joint limit (arm
side), rad
bool
float
FALSE
1885
No
No
No
No
-1885
No
No
200000
00
No
No
200000
00
No
No
0
No
No
0
No
No
100000
No
No
-100000
No
No
0
No
No
83
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
performance_quota
supervision_jam_time_factor
supervision_load_factor
supervision_speed_factor
supervision_pos_factor
sync_speed_high
sync_speed_low
ext_const_torque
PARALLE
L_ARM
_LOAD
ARM_
TYPE
inertia
Performance reduction
(1.0 = normal
performance)
Trim factor for JAM
supervision
Trim factor for LOAD
supervision
Trim factor for all three
SPEED supervisions
Trim factor for both POS
supervisions
High sync speed on arm
side, (rad/s) or (m/s)
(Rot/Lin)
Low sync speed on arm
side, (rad/s) or (m/s)
(Rot/Lin)
This is A in Ext_torque =
A + | k * (fi-fi0)
float
S,O,
0.45 to
1.0
S, 0.1 to
10.0
S, 0.1 to
10.0
S, 0.05
to 10.0
S, 0.1 to
10.0
S, 0.0 to
2.0
1.0
No
No
1.0
No
No
1.0
No
No
1.0
No
No
1.0
No
No
0.2
No
No
float
S, 0.0 to
2.0
0.016
No
No
float
S,O, 0.0
to
100000.
0
S,O,
100000.
0 to
100000.
0
S,O,
100000.
0 to
100000.
0
0.0
No
No
0.0
No
No
0.0
No
No
No
No
0
No
No
0
No
No
0
0
0
0
No
No
No
No
No
No
No
No
0
No
No
0
No
No
primary
No
No
foreign
Yes
No
FALSE
No
No
float
float
float
float
float
ext_prop_torque
This is k in Ext_torque =
A + | k * (fi-fi0) |
float
ext_prop_zero_angle
This is fi0 in Ext_torque
= A + | k * (fi-fi0) |
float
name
arm load name
char[16]
length
float
mass
float
mass_centre_x
mass_centre_y
mass_centre_z
inertia_x
float
float
float
float
inertia_y
float
inertia_z
float
name
use_parallel_arm_load
independent_move_off
direction_x
direction_y
direction_z
Unique ARM_TYPE Id
name
Id name for parallel arm
load
Independent move is not
possible with arm
Unit vector for positive
direction
char[16]
primary
0 to
2000
0 to
1000
-3 to 3
-3 to 3
-3 to 3
0 to
1000
0 to
1000
0 to
1000
S,O
char[16]
BOOL
float
-1 to 1
0
No
No
float
float
- 1 to 1
-1 to 1
0
0
No
No
No
No
84
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
home
Arm's home position
[rad] or [m]
Arm length, [m]
Offset between arm's 1st
and 2nd joints, x
direction [m]
Offset between arm's 1st
and 2nd joints, y
direction [m]
Offset between arm's 1st
and 2nd joints, z
direction [m]
Angle between the arm's
two joints. [rad]
Joint angle of arm in
home position. [rad]
X coordinate of centre of
rotation of axis
float
rot_axis_pose_pos_y
Y coordinate of centre of
rotation of axis
float
rot_axis_pose_pos_z
Z coordinate of centre of
rotation of axis
float
rot_axis_pose_orient_u0
Orientation u0 of rotation
axis
Orientation u0 of rotation
axis
Orientation u0 of rotation
axis
Orientation u0 of rotation
axis
Arm mass [kg]
float
Center of mass location
in arm's coord system
[m]
Center of mass location
in arm's coord system
[m]
Center of mass location
in arm's coord system
[m]
Inertia about arm's center
of mass kgm**2
Inertia about arm's center
of mass kgm**2
Inertia about arm's center
of mass kgm**2
Supervised maximum ztorque [Nm]
Normalized auxiliary
torque margin
Max acc utilization
quota, [0..1], 1.0 = use
full dyn mod acc
Maximum allowed ztorque for micro sample
length
offset_x
offset_y
offset_z
attitude
theta_home_position
rot_axis_pose_pos_x
rot_axis_pose_orient_u1
rot_axis_pose_orient_u2
rot_axis_pose_orient_u3
mass
mass_centre_x
mass_centre_y
mass_centre_z
inertia_x
inertia_y
inertia_z
max_bend_trq_z
bend_trq_z_margin
bend_trq_z_max_acc_quota
max_micro_sample_bend_trq
_z
- 10 to
10
0 to 100
-10.0 to
10.0
0
No
No
0
0
No
No
No
No
float
-10.0 to
10.0
0
No
No
float
-10.0 to
10.0
0
No
No
float
0
No
No
0
No
No
0
No
No
0
No
No
0
No
No
1
No
No
0
No
No
0
No
No
0
No
No
0
No
No
float
- 10 to
10
- 10 to
10
S,O, 1000 to
1000
S,O, 1000 to
1000
S,O, 1000 to
1000
S,O, -1
to 1
S,O, -1
to 1
S,O, -1
to 1
S,O, -1
to 1
0 to
10000
-3 to 3
0
No
No
float
- 3 to 3
0
No
No
float
- 3 to 3
0
No
No
float
0
No
No
float
0
No
No
float
0
No
No
100000
No
No
0.9
No
No
1.0
No
No
0
No
No
float
float
float
float
float
float
float
float
float
float
0 to
100000
0.1 to
1.0
float
float
0 to
100000
85
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
max_rapid_weave_bend_trq_
z
max_micro_sample_torque
max_rapid_weave_torque
rear_length
length_of_housing
max_dyn_fric
min_dyn_fric
max_stat_fric
min_stat_fric
min_inertia
max_inertia
transm_inertia
relative_stiffness
max_acc
max_acc_quota
rel_dist_torque_model_error
abs_dist_torque_model_error
torque_margin_for_speed_rat
io_0
torque_margin_for_speed_rat
io_1
torque_margin_for_speed_rat
io_cutin
emergency_stop_torque_mar
gin
ACC_
DATA
name
wc_acc
supervision [Nm]
Maximum allowed ztorque for rapid weave
supervision [Nm]
Maximum allowed
torque (gear or motor)
for micro sample
supervision [Nm]
Maximum allowed
torque (gear or motor)
for rapid weave
supervision [Nm]
Arm's length towards the
rear of the robot [m], for
checkpoint
Length of upper arm
housing [m]
Max dynamic friction
factor , Nm/rad/s
Min dynamic friction
factor, Nm/rad/s
Max static friction, Nm
Min static friction, Nm
Min arm inertia, kgm**2,
(not including motor,
brake, transm)
Max load+arm inertia,
kgm**2 (not including
motor, brake, transm)
Transmission inertia
kgm**2 (arm side)
Relative stiffness of arm,
1.0 = normal stiffness
tuning
Arm max acc, rad/s**2
Max acc utilization
quota, [0..1], 1.0 = use
full dyn mod acc
Relative disturbance
torque model error. 0.1 =
10% error
Saves extra torque to be
used for acc.Arm side.No
couplings are handled
Normalized torque
margin for low speeds
Normalized torque
margin for high speeds
Normalized cutin point
for high speed torque
margin
Torque margin for
dynmod emergency stop
calculations, 0.1 = save
10% as margin
acc data name
Worst case motor acc,
rad/s**2 (arm side)
float
0 to
100000
0
No
No
float
0 to
100000
0
No
No
float
0 to
100000
0
No
No
0
No
No
0
No
No
float
0
No
No
float
0
No
No
float
float
float
0
0
0
No
No
No
No
No
No
float
0
No
No
0
No
No
1.00
No
No
200
No
No
No
No
float
float
float
0 to 100
-1 to
1000
float
float
float
S,O, 0.2
to 1.0
float
0 to 0.5
0.0
No
No
float
0 to
100000
0.0
No
No
float
0.1 to
1.0
0.1 to
1.0
0.1 to
1.0
0.9
No
No
0.9
No
No
1.0
No
No
float
0 to 1
0
No
No
char[16]
S,0
No
No
float
S,0, 0 to
1000
No
No
float
float
primary
86
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
wc_dec
wc_dacc_ratio
wc_ddec_ratio
ARM_
CHECK_
POINT
name
Worst case motor dec,
rad/s**2 (arm side)
Worst case motor acc
derivate ratio
Worst case motor dec
derivate ratio
arm check point name
float
float
float
char[24]
checktype
position_x
char[16]
float
position_y
float
position_z
float
S,0, 0 to
1000
S,0, 0.1
to 1.0
S,0, 0.1
to 1.0
S,0
S,0
S,0, -3
to 3
S,0, -3
to 3
S,0, -3
to 3
No
No
1.0
No
No
1.0
No
No
No
No
No
No
No
No
No
No
No
No
primary
87
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Appendix D
Tables created during Design of Conceptual Data Model
MECHANICAL_UNIT
name
4400_2.45_30
4400_1.95_60
4400_1.95_45
4400_2.6_10
4400_s2.45_30
4400_sc2.45_30
use_robot_family
4400
4400
4400
4400
4400
4400
use_robot_arm_length
2.45
1..95
1.95
2.6
s2.45
sc2.45
stand_by_state
TRUE
TRUE
TRUE
TRUE
TRUE
TRUE
speed_offset_adjustment
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
use_robot_load_mass
30
60
45
10
30
30
active_at_start_up
TRUE
TRUE
TRUE
TRUE
TRUE
TRUE
user_frame_moved_by
NULL
NULL
NULL
NULL
NULL
NULL
do_not_allow_deactivation
TRUE
TRUE
TRUE
TRUE
TRUE
TRUE
AXC_FILTER
name
irb_1
position_controller_mode_4ms
TRUE
reserve_time_slot
TRUE
anti_windup_tracking_time
-1
speed_ref_based_torque_limitation
FALSE
ARM_CHECK_POINT
name
irb_1
checktype
POS
position_x
-0.4
position_y
0
position_z
0.265
ACC_DATA
name
irb_1
irb_2
irb_3
irb_4
wc_acc
3
6
15
20
wc_dec
3
6
15
20
wc_dacc_ratio
1.0
1.0
1.0
1.0
wc_ddec_ratio
1.0
1.0
1.0
1.0
PARALLEL_ARM_LOAD
name
irb_1
irb_2
irb_3
length
0
0
0
mass
14
120
69
mass_centre_x
0
0.442
0.398
mass_centre_y
0
0
0
mass_centre_z
0.443
0
0
inertia_x
0
0
0
inertia_y
0
0
0
inertia_z
0
0
0
88
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
ROBOT
family
4400
4400
4400
4400
4400
4400
arm_length
2.45
1.95
1.95
2.6
s2.45
sc2.45
use_joint_3
irb_4
irb_10
irb_10
irb_17
irb_4
irb_4
default_load_mass
30
60
45
10
30
30
use_joint_4
irb_5
irb_5
irb_5
irb_18
irb_5
irb_5
use_joint_5
irb_6
irb_6
irb_6
irb_19
irb_6
irb_6
use_robot_type
4400_30
4400_60
4400_45
4400_10
4400_30
4400_30
use_robot_calib
NULL
NULL
NULL
NULL
NULL
NULL
base_frame_pos_x
0
0
0
0
0
0
use_joint_0
irb_1
irb_7
irb_11
irb_14
irb_1
irb_21
base_frame_pos_y
0
0
0
0
0
0
base_frame_orient_u1
base_frame_orient_u2
base_frame_orient_u3
1
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
rot_z_tol
0.001
0.001
0.001
0.001
0.001
0.001
base_mass
0.0
0.0
0.0
0.0
0.0
0.0
pos_x_tool
0.0001
0.0001
0.0001
0.0001
0.0001
0.0001
upper_work_area_y
0
0
0
0
0
0
lower_arm_cp_bound_y
0
0
0
0
0
0
linnear_jog_allowed
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
pos_y_tool
0.0001
0.0001
0.0001
0.0001
0.0001
0.0001
base_mass_centre_x
0.0
0.0
0.0
0.0
0.0
0.0
pos_z_tool
0.0001
0.0001
0.0001
0.0001
0.0001
0.0001
lower_work_area_y
0
0
0
0
0
0
base_mass_centre_y
0.0
0.0
0.0
0.0
0.0
0.0
upper_work_area_x
0
0
0
0
0
0
upper_work_area_z
0
0
0
0
0
0
lower_arm_cp_bound_z
0
0
0
0
0
0
use_joint_2
irb_3
irb_9
irb_13
irb_16
irb_3
irb_3
base_frame_pos_z
0
0
0
0
0
0
base_frame_orient_u0
gravity_beta
0
0
0
0
0.523599
0.523599
use_joint_1
irb_2
irb_8
irb_12
irb_15
irb_20
irb_20
base_mass_centre_z
0.0
0.0
0.0
0.0
0.0
0.0
base_frame_coordinate
d
NULL
NULL
NULL
NULL
NULL
NULL
rot_x_tol
0.001
0.001
0.001
0.001
0.001
0.001
rot_y_tol
0.001
0.001
0.001
0.001
0.001
0.001
lower_work_area_x
0
0
0
0
0
0
lower_work_area_z
0
0
0
0
0
0
upper_arm_cp_bound_x
0
0
0
0
0
0
lower_arm_cp_bound_x
0
0
0
0
0
0
upper_arm_cp_bound_y
0
0
0
0
0
0
upper_arm_cp_bound_z
0
0
0
0
0
0
use_six_axis_corvec
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
89
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
ROBOT_TYPE
name
4400_30
4400_60
4400_45
4400_10
type
IRB4400_FLOOR
IRB4400_FLOOR
IRB4400_FLOOR
IRB4400_FLOOR
default_load_mass
30
60
45
10
error_model
NOMINAL
NOMINAL
NOMINAL
NOMINAL
default_load_mass_centre_x
0.3
0.17
0.07
0.1
default_load_intertia_x
0.03
0.6
0.4
0.06
default_load_intertia_y
0.03
0.6
0.4
0.06
lower_joint_0_bound_reduced
-100000
-100000
-100000
-100000
master_robot
TRUE
TRUE
TRUE
TRUE
default_load_mass_centre_y
0
0
0
0
default_load_intertia_z
0.03
0.6
0.4
0.06
lower_joint_2_bound_reduced
-100000
-100000
-100000
-100000
soft_influence_pos_speed_ratio
2.5
2.5
2.5
2.5
work_area_cylinder_max_z
0
0
0
0
no_of_joints
6
6
6
6
supervision_deactivate_in_auto_mode
FALSE
FALSE
FALSE
FALSE
default_load_mass_centre_z
0.21
0.22
0.23
0.1
upper_joint_0_bound_reduced
100000
100000
100000
100000
soft_static_position_ratio
18.2
18.2
18.2
18.2
work_area_cylinder_radius
0
0
0
0
base_pose_rot_u0
1
1
1
1
use_default_load
NULL
NULL
NULL
NULL
base_pose_rot_u1
0
0
0
0
soft_static_speed_ratio
5
5
5
5
work_area_cylinder_min_z
0
0
0
0
base_pose_rot_u2
0
0
0
0
base_pose_rot_u3
0
0
0
0
par_id_type
coupling
coupling
coupling
coupling
90
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
JOINT
name
logical axis
use_axc_filter
use_arm
connector_board
uncalibrated_contol_master_type
irb_1
irb_2
irb_3
irb_4
irb_5
irb_6
irb_7
irb_8
irb_9
irb_10
irb_11
irb_12
irb_13
irb_14
irb_15
irb_16
irb_17
irb_18
irb_19
irb_20
irb_21
1
2
3
4
5
6
1
2
3
4
1
2
3
1
2
3
4
5
6
2
1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_1
irb_2
irb_3
irb_4
irb_5
irb_6
irb_7
irb_8
irb_9
irb_10
irb_11
irb_12
irb_13
irb_14
irb_15
irb_16
irb_17
irb_18
irb_19
irb_20
irb_21
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
UCCM0
normal_control_master_type
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
FFWCM1
lock_joint_in_hardware
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
lock_joint_in_pool
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
lock_joint_in_servo
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
passive_joint
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
91
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
JOINT fotrs
slave_to_joint
NULL
NULL
NULL
NULL
NULL
NULL
NULL
NULL
NULL
NULL
NULL
NULL
NULL
NULL
NULL
NULL
NULL
NULL
NULL
NULL
NULL
stand_alone_mode_allowed
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
92
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
ARM_TYPE
name
IRB4400_1
IRB4400_2
IRB4400_3
IRB4400_4
IRB4400_5
IRB4400_6
IRB4400_7
IRB4400_8
IRB4400_9
IRB4400_10
IRB4400_11
IRB4400_12
IRB4400_13
IRB4400_14
IRB4400_15
IRB4400_16
IRB4400_17
IRB4400_18
IRB4400_19
IRB4400_20
IRB4400_21
offset_y
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
use_parallel_arm_load
NULL
irb_1
irb_2
NULL
NULL
NULL
NULL
irb_1
irb_2
NULL
NULL
irb_1
irb_3
NULL
irb_1
irb_2
NULL
NULL
NULL
irb_1
NULL
offset_z
0
0
0.15
0
0
0
0
0
0.15
0
0
0
0.15
0
0
0.15
0
0
0
0
0
attitude
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
independent_move_off
TRUE
TRUE
TRUE
TRUE
TRUE
FALSE
TRUE
TRUE
TRUE
TRUE
TRUE
TRUE
TRUE
TRUE
TRUE
TRUE
TRUE
TRUE
FALSE
TRUE
TRUE
theta_home_position
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
direction_x
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
rot_axis_pose_pos_x
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
direction_y
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
direction_z
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
rot_axis_pose_pos_y
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
home
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
length
0.68
0.89
1.38
1.18
0
0.14
0.68
0.89
0.88
0.68
0.68
0.89
0.88
0.68
0.89
1.5
1.3
0
0.085
0.89
0.68
offset_x
0
0.2
0
0
0
0
0
0.2
0
0
0
0.2
0
0
0.2
0
0
0
0
0.2
0
rot_axis_pose_pos_z
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
93
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
ARM_TYPE forts.
rot_axis_pose_orient_u0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
mass_centre_y
0
0
-0.014
0
0
0
0
0
0
0
0
0
0
0
0
-0.0136
0
0
0
0
0
rot_axis_pose_orient_u1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
mass_centre_z
0
0.34
-0.012
0
0
0
0
0.34
-0.0163
0
0
0.34
-0.0163
0
0.34
-0.014
0
0
0
0.34
0
inertia_x
0
8.06
1.745
0
0
0.0033
0
8.06
0
0
0
8.06
0
0
8.06
1.7319
0
0
0.0033
8.06
0
rot_axis_pose_orient_u2
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
inertia_y
0
9.279
75.487
0
0
0.021
0
9.279
36.1872
0
0
9.279
36.1872
0
9.279
44.02
0
0
0.021
9.279
0
inertia_z
37.9
0
75.865
0
0
0.021
37.9
0
36.0129
0
37.9
0
36.0129
37.9
0
44.02
0
0
0.021
0
97
rot_axis_pose_orient_u3
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
max_bend_trq_z
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
bend_trq_z_margin
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
mass
406
73
185.3
0
0
3.9
406
73
153.1
0
406
73
153.1
406
73
149.1
0
0
0.9
73
636
mass_centre_x
0.027
0
0.392
0
0
-0.103
0.027
0
0.2048
0
0.027
0
0.2048
0.027
0
0.222
0
0
-0.057
0
-0.197
bend_trq_z_max_acc_quota
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
94
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
ARM_TYPE forts.
max_micro_sample_bend_trq_z
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
length_of_housing
0
0
0.2
0
0
0
0
0
0.2
0
0
0
0.2
0
0
0.2
0
0
0
0
0
max_dyn_fric
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
max_rapid_weave_bend_trq_z
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
min_dyn_fric
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
max_micro_sample_torque
1650
1650
1650
589
545
209
1650
1650
1650
589
1650
1650
1650
1650
1650
1650
589
93.5
42.2
1650
1650
max_stat_fric
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
min_stat_fric
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
max_rapid_weave_torque
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
min_inertia
50.6
8.8
35.2
0.136
0.0423
0.0033
50.6
8.8
35.2
0.136
50.6
8.8
35.2
50.6
8.8
35.2
0.136
0.0423
0.0033
8.8
50.6
max_inertia
1100
350
300
14.4
14.4
6.15
910
265
200
14.4
910
265
200
910
265
200
6
6
5
350
1100
rear_length
0
0
0.3
0
0
0
0
0
0.3
0
0
0
0.3
0
0
0.3
0
0
0
0
0
transm_inertia
2.8
2.8
2.8
0.792
0.362
0.1152
27.6
27.6
27.6
0.792
27.6
27.6
27.6
2.8
2.8
2.8
0.414
0.895
0.719
2.8
2.8
95
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
ARM_TYPE forts.
relative_stiffness
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
max_acc
10000
10000
10000
10000
10000
10000
10000
10000
10000
10000
10000
10000
10000
10000
10000
10000
10000
10000
10000
10000
10000
max_acc_quota
0.9
0.95
0.9
0.85
0.9
0.9
0.9
0.9
0.95
0.85
0.95
0.95
1
0.9
0.9
0.9
0.9
0.8
0.8
0.95
0.9
torque_margain_for_speed_ratio_0
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
rel_dist_torque_model_error
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
torque_margain_for_speed_ratio_1
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
0.9
abs_dist_torque_model_error
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
torque_margin_for_speed_ratio_cutin
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
96
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
ARM_TYPE forts.
emergency_stop_torque_margin
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
97
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
ARM
name
irb_1
irb_2
irb_3
irb_4
irb_5
irb_6
irb_7
irb_8
irb_9
irb_10
irb_11
irb_12
irb_13
irb_14
irb_15
irb_16
irb_17
irb_18
irb_19
irb_20
irb_21
use_arm_type
IRB4400_1
IRB4400_2
IRB4400_3
IRB4400_4
IRB4400_5
IRB4400_6
IRB4400_7
IRB4400_8
IRB4400_9
IRB4400_10
IRB4400_11
IRB4400_12
IRB4400_13
IRB4400_14
IRB4400_15
IRB4400_16
IRB4400_17
IRB4400_18
IRB4400_19
IRB4400_20
IRB4400_21
lower_joint_bound
-2.879793
-1.396263
-0.523599
-3.49066
-2.094395
-6.98132
-2.879793
-1.396263
-0.523599
-3.49066
-2.879793
-1.396263
-0.523599
-2.879793
-1.396263
-0.523599
-3.49066
-2.094395
-6.98132
-1.396263
-2.879793
use_acc_data
irb_1
irb_2
irb_2
irb_3
irb_3
irb_3
irb_1
irb_2
irb_2
irb_3
irb_1
irb_2
irb_2
irb_1
irb_2
irb_2
irb_3
irb_4
irb_4
irb_2
irb_1
upper_joint_bound_max
2.879793
1.658063
2.70526
1260
2.094395
1260
2.879793
1.658063
1.047198
1260
2.879793
1.658063
1.047198
2.879793
1.658063
2.70526
1260
2.094395
1260
1.570796
2.879793
use_check_point
NULL
NULL
irb_1
NULL
NULL
NULL
NULL
NULL
irb_1
NULL
NULL
NULL
irb_1
NULL
NULL
irb_1
NULL
NULL
NULL
NULL
NULL
lower_joint_bound_min
-2.879793
-1.396263
-0.523599
-1260
-2.094395
-1260
-2.879793
-1.396263
-1.134464
-1260
-2.879793
-1.396263
-1.134464
-2.879793
-1.396263
-0.523599
-1260
-2.094395
-1260
-1.396263
-2.879793
independent_joint_on
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
FALSE
ind_upper_joint_bound
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
upper_joint_bound
2.879793
1.658063
2.70526
3.49066
2.094395
6.98132
2.879793
1.658063
2.70526
3.49066
2.879793
1.658063
2.70526
2.879793
1.658063
2.70526
3.49066
2.094395
6.98132
1.570796
2.879793
ind_lower_joint_bound
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
98
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
ARM forts.
upper_coupled_joint_bound_2
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
100000
load_id_acc_ratio
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
lower_coupled_joint_bound_2
-100000
-100000
-100000
-100000
-100000
-100000
-100000
-100000
-100000
-100000
-100000
-100000
-100000
-100000
-100000
-100000
-100000
-100000
-100000
-100000
-100000
performance_quota
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
upper_joint_coupl_bound
0
0
1.047198
0
0
0
0
0
1.047198
0
0
0
1.047198
0
0
1.047198
0
0
0
0
0
supervision_load_factor
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
lower_joint_coupl_bound
0
0
-1.134464
0
0
0
0
0
-1.134464
0
0
0
-1.134464
0
0
-1.134464
0
0
0
0
0
supervision_speed_factor
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
cal_position
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
supervision_pos_factor
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
99
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
ARM forts.
sync_speed_high
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
0.2
sync_speed_low
0.016
0.016
0.016
0.016
0.016
0.016
0.016
0.016
0.016
0.016
0.016
0.016
0.016
0.016
0.016
0.016
0.016
0.016
0.016
0.016
0.016
ext_const_torque
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
ext_prop_torque
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
ext_prop_zero_angle
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
100
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Appendix E
Entity-Relationship Diagram
AXC_FILTER
1
MECHANICAL_
UNIT
1
controls
Is a
1
M
M
JOINT
ROBOT
Is part
of
M
1
1
Is type of
moves
ROBOT_TYPE
1
1
M
ARM
M
1
Is of
1
ARM_C_POINT
1
ARM_TYPE
1
ACC_DATA
M
1
PARALLEL_ARM_L
OAD
101
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
Appendix F
Relvars in DBDL (Database Definition Language)
MECHANICAL_UNIT
(name, use_robot_family, use_robot_arm_lengt, use_robot_load_mass,
user_frame_moved_by, stand_by_state, speed_offset_adjustment,
activate_at_start_up, do_not_allow_deactivation)
Primary Key
(name)
Foreign Key
(use_robot_family, use_robot_arm_length, use_robot_load_mass)
references
ROBOT
(family, arm_length, default_load_mass)
On Update
restrict
On Delete
restrict
ROBOT
(family, arm_length, default_load_mass, use_robot_type, use_joint_0, use_joint_1,
use_joint_2, use_joint_3, use_joint_4, use_joint_5, base_frame_pos_x, base_frame_pos_y,
base_frame_pos_z, base_frame_orient_u0, base_frame_orient_u1, base_frame_orient_u2,
base_frame_orient_u3, base_frame_coordinated, gravity_beta, base_mass, base_mass_centre_x,
base_mass_centre_y, base_mass_centre_z, rot_x_tol, rot_y_tol, rot_z_tol, pos_x_tol, pos_y_tol,
pos_z_tol, upper_work_area_x, lower_work_area_x, upper_work_area_y, lower_work_area_y,
upper_work_area_z, lower_work_area_z, lower_arm_cp_bound_x, lower_arm_cp_bound_y,
lower_arm_cp_bound_z, upper_arm_cp_bound_x, upper_arm_cp_bound_y,
upper_arm_cp_bound_z, linear_jog_allowed, use_six_axis_corvec)
Primary Key (family, arm_length, default_load_mass)
Foreign Key
(use_robot_type)
On Update
restrict
On Delete
restrict
references
ROBOT_TYPE
(name)
Foreign Key
(use_joint_0)
On Update
On Delete
references
JOINT
(name)
restrict
restrict
(use_joint_1)
On Update
On Delete
references
JOINT
(name)
restrict
restrict
(use_joint_2)
On Update
On Delete
references
JOINT
(name)
restrict
restrict
(use_joint_3)
On Update
On Delete
references
JOINT
(name)
restrict
restrict
(use_joint_4)
On Update
On Delete
references
JOINT
(name)
restrict
restrict
(use_joint_5)
On Update
references
JOINT
(name)
restrict
Foreign Key
Foreign Key
Foreign Key
Foreign Key
Foreign Key
102
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
On Delete
ROBOT_TYPE
restrict
(name, type, error_model, no_of_joints, master_robot, use_default_load,
default_load_mass, default_load_mass_centre_x, default_load_mass_centre_y,
default_load_mass_centre_z, default_load_inertia_x, default_load_inertia_y,
default_load_inertia_z, upper_joint_0_bound_reduced,
lower_joint_0_bound_reduced, lower_joint_2_bound_reduced,
soft_static_position_ratio, soft_static_speed_ratio,
soft_influence_pos_speed_ratio, work_area_cylinder_radius,
work_area_cylinder_min_z, work_area_cyliner_max_z, base_pose_rot_u0,
base_pose_rot_u1, base_pose_rot_u2, base_pose_rot_u3,
supervision_deactiv_in_auto_m, par_id_type)
Primary Key (name)
JOINT
(name, logical_axis, use_axc_filter, use_arm, connector_board, uncalibrated_control_master_t,
normal_control_master_type, lock_joint_in_hardware, lock_joint_in_ipol, lock_joint_in_servo,
passive_joint, slave_to_joint, stand_alone_mode_allowed)
Primary Key (name)
Foreign Key
(use_axc_filter)
On Update
restrict
On Delete
restrict
references
AXC_FILTER (name)
Foreign Key
(use_arm)
On Update
On Delete
references
ARM
(name)
restrict
restrict
AXC_FILTER (name, position_controller_mode_4ms, reserve_time_slot, anti_windup_tracking_time,
speed_ref_based_torque_limitat)
Primary Key (name)
ARM
(name, use_arm_type, use_acc_data, use_check_point, independent_joint_on,
upper_joint_bound, lower_joint_bound, upper_joint_bound_max, lower_joint_bound_min,
ind_upper_joint_bound, ind_lower_joint_bound, upper_coupled_joint_bound_2,
lower_coupled_joint_bound_2, upper_joint_coupl_bound, lower_joint_coupl_bound,
cal_position, load_id_acc_ratio, performance_quota, supervision_jam_time_factor,
supervision_load_factor, supervision_speed_factor, supervision_pos_factor, sync_speed_high,
sync_speed_low, ext_const_torque, ext_prop_torque, ext_prop_zero_angle)
Primary Key (name)
Foreign Key
(use_arm_type)
On Update
restrict
On Delete
restrict
references
ARM_TYPE
(name)
Foreign Key
(use_acc_data)
On Update
restrict
On Delete
restrict
references
ACC_DATA
(name)
Foreign Key
(use_check_point)
references
ARM_CHECK_POINT
(name)
103
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
On Update
On Delete
restrict
restrict
104
2016-03-07
Magdalena Bozyk & Fredrik Mannerstedt
ARM_TYPE (name, use_parallel_arm_load, independent_move_off, direction_x, direction_y, direction_z,
home, length ,offset_x, offset_y, offset_z, attitude, theta_home_position, rot_axis_pose_pos_x,
rot_axis_pose_pos_y, rot_axis_pose_pos_z, rot_axis_pose_orient_u0, rot_axis_pose_orient_u1,
rot_axis_pose_orient_u2, rot_axis_pose_orient_u3, mass, mass_centre_x, mass_centre_y,
mass_centre_z, inertia_x, inertia_y, inertia_z, max_bend_trq_z, bend_trq_z_margin,
bend_trq_z_max_acc_quota, max_micro_sample_bend_trq_z, max_rapid_weave_bend_trq_z,
max_micro_sample_torque, max_rapid_weave_torque, rear_length, length_of_housing,
max_dyn_fric, min_dyn_fric, max_stat_fric, min_stat_fric, min_inertia, max_inertia,
transm_inertia, relative_stiffness, max_acc, max_acc_quota, rel_dist_torque_model_error,
abs_dist_torque_model_error, torque_margin_for_sped_ratio_0,
torque_margin_for_sped_ratio_1, torque_margin_sped_ratio_cutin,
emergency_stop_torque_margin)
Primary Key (name)
Foreign Key (use_parallel_arm_load)
On Update
restrict
On Delete
restrict
PARALLEL_ARM_LOAD
references
PARALLEL_ARM_LOAD
(name)
(name, length, mass, mass_centre_x, mass_centre_y, mass_centre_z, inertia_x,
inertia_y, inertia_z)
Primary Key (name)
ARM_CHECK_POINT
(name, checktype, position_x, position_y,
position_z)
Primary Key (name)
AXC_FILTER (name, position_controller_mode_4ms, reserve_time_slot, anti_windup_tracking_time,
speed_ref_based_torque_limitat)
Primary Key (name)
105