Databashantering Av Robotkonfigurationsdata

18/01/18 Magdalena Bozyk & Fredrik Mannerstedt

Database Management of Robot Configuration Data

Magdalena Bozyk1, Fredrik Mannerstedt2 ABB Automation Technology Products [email protected] [email protected]

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 18/01/18 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.

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.

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.

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 7.5 The Fields Collection and the Field Object...... 60 7.6 The Parameter Object...... 60 7.7 The Properties Collection and the Property Object...... 61 7.8 The Errors Collection and the Error Object...... 61 7.9 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

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.

MECHANICAL_UNIT

ROBOT_TYPE ROBOT

AXC_FILTER JOINT

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.

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:

 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?

2.1.1 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.

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.

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 1 Client 3

Requests for data Selected data returned

Database Server with DBMS

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.

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.

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.

Time T1 T2 X 1 read(x) 100 2 read(X) x = x + 100 100 3 x = x – 10 write(X) 200 4 write(X) 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.

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.

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.

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 semantics3, 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 3 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.

Foreign Primary Key Key

DNAME RESPONSIBILITY MANAGER PARENT DEPT DEPT DMF Motion Functions E4 DM DMC Motion Control E5 DM Relation DMA Application Process E1 DM Relvar EMP# FIRST_NAME LAST_NAME DEPT E1 Lennart Sundstedt DMA EMP E2 Christer Norström DM E3 Håkan Fortell DMF E4 Dan Rylander DMF Tuple E5 Jesper Bergsjö DMC E6 Anders Lager DMF

Foreign Key Primary Attribute 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.

Domains DMF, DMC, DCS Relvar

DEPARTMENT

DNAME NAME EMP_AMOUNT EMP_AMOUNT MANAGER EMP# y t s i e l

l DMF 12 E4 a p n u i DMC 14 E5 d T r

a DMA 8 E1 C

Primary Attribute Key Relation 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

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 higher- valued 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.

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.

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 18/01/18 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 tuple- oriented 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.

Product Restrict Project

a x a x

b y a y

Union Intersection Difference

Join Divide

a1 b1 b1 c1 a1 b1 c1 a a x x a

a2 b2 b2 c2 a2 b2 c2 b a y z

a3 b3 b3 c3 a3 b3 c3 c a z

Figure 2.6 The Original Eight Operators

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 FirstName LastName Salary Position 005 Mary Scott 74,000, Manger 034 Joe Smith 63,000, Manager 059 Patricia Lawson 48,000, Staff 081 Bill Jones 42,000, Staff 097 Sam Jones 36,000, Entry-level 118 Sarah Ackerman 32,000, Entry-level

Table 3.1. EmployeeTable.

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:

= Equal <> or != (see manual) Not Equal < Less Than > Greater Than <= Less Than or Equal To >= Greater Than or Equal To

Table 3.2. Relational operators.

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.

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 Mary Scott 74,000, Manger 034 Joe Smith 63,000, Manager 059 Patricia Lawson 48,000, Staff 081 Bill Jones 42,000, Staff 097 Sam Jones 36,000, Entry-level 118 Sarah Ackerman 32,000, 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 Joe Smith 63,000, Manager 005 Mary Scott 74,000, Manger 059 Patricia Lawson 48,000, Staff 097 Sam Jones 36,000, Entry-level 081 Bill Jones 42,000, Staff 118 Sarah Ackerman 32,000, 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;

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.

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 NUMBER(3), FirstName VARCHAR2(10), LastName VARCHAR2(15), Salary NUMBER(6), Position 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.

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.

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;

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_ASSIGNMENT PROJECT

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_D EP PARENT_D EP

EMPLOYEE PROGRAMMER MANAGER DEPARTMENT

DEP_MAN EMP_P A

PROJECT PROJECT_ASSIGNMENT PRO_P A

Figure 4.2. Relationships.

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.

FIRS MIDDL LAS T E T RESPONSIBILIT Y NAM EMP_D ADDRES E EP PARENT_D S EP EMP EMPLOYEE MANAGER DEPARTMENT NAME PROGRAMMER #

EMP # ADDRES DEP_MAN S EMP # #_OF_EMPLOYEE NAM S E ADDRES NAM S E PR # EMP_P A BUDGET

PROJECT_ASSIGNMENT PROJECT PRO_P STAR A T

EN HOURS_WORKE DESCRIPTION RESPONSIBILIT D D Y

Figure 4.3. Attributes.

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.

FIRS MIDDL LAS T E T RESPONSIBILIT Y NAM EMP_D ADDRES E EP PARENT_D S EP M M M 1 1 M EMP EMPLOYEE MANAGER DEPARTMENT NAME PROGRAMMER # 1 1 1 1 1 EMP # ADDRES DEP_MAN S EMP # #_OF_EMPLOYEE NAM S E ADDRES NAM S E PR # EMP_P A BUDGET M PROJECT_ASSIGNMENT M PROJECT PRO_P 1 STAR A T

EN HOURS_WORKE DESCRIPTION RESPONSIBILIT D D Y 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. 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.

FIRS MIDDL LAS T E T RESPONSIBILIT NAM Y EMP_D ADDRES E PARENT_D S EP EP M M 1 1 EMPLOYEE DEPARTMENT NAME

1 1 EMP # DEP_MAN 1 PROGRAMMER MANAGER #_OF_EMPLOYEE S

PR # EMP_P A BUDGET M PROJECT_ASSIGNMENT M PROJECT PRO_P 1 STAR A T

EN HOURS_WORKE DESCRIPTION RESPONSIBILIT D D Y

Figure 4.5. Entity Subtypes and Supertypes.

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.

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 .

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.

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

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

S# S# CITY CITY STATUS 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#

P# QTY

Figure 4.10. Functional Dependencies of SSP.

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

TEACHER TEXT Physics Prof. Green Basic Mechanics Prof. Brown Principles of Optics

TEXT TEACHER Basic Mechanics Math Prof. Green 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.

COURSE TEACHER TEXT Physics Prof. Green Basic Mechanics Physics Prof. Green Principles of Optics Physics Prof. Brown Basic Mechanics Physics Prof. Brown Principles of Optics Math Prof. Green Basic Mechanics Math Prof. Green Vector Analysis Math Prof. Green Trigonometry Table 4.2. Relvar CTX

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 TEACHER COURSE TEXT Physics Prof. Green Physics Basic Mechanics Physics Prof. Brown Physics Principles of Optics Math Prof. Green Math Basic Mechanics Math Vector Analysis Math 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# ITEM S# PG4 Bed S1 PG4 Chair S2 PG16 Bed S2 PG16 Table S1 PG36 Chair S3 Table 4.3. Relvar PIS.

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 ITEM S# S# PG# PG4 Bed Bed S1 S1 PG4 PG4 Chair Chair S2 S2 PG4 PG16 Bed Bed S2 S2 PG16 PG16 Table Table S1 S1 PG16 PG36 Chair Chair S3 S3 PG36 Figure 4.12. Relvars PI, IS, SP.

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. Identify entity types in the user’s view of the enterprise; 2. Identify the important relationships that exist between the identified entity types; 3. Identify and associate attributes with entity or relationship types; 4. Determine attribute domains; 5. Determine candidate and primary key attributes for each entity; 6. Determine entity subtypes and supertypes (optional step); 7. Draw Entity-Relationship diagram that is a conceptual representation of a user view of the enterprise; 8. Review local conceptual data model with user to ensure that the model represents user’s view of the enterprise;

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. Refine the local conceptual model and map it to local logical data model; 2. Derive relvars from local logical data model; 3. Validate model using normalization; 4. Validate model against user transactions; 5. Draw Entity-Relationship diagram that is a local logical representation of user’s view of the enterprise; 6. Define integrity constraints given in the user’s view of the enterprise; 7. 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. Merge local logical data models into single global logical model of the enterprise; 2. Validate global logical data model using normalization and against the required transactions; 3. Check for future growth; 4. Draw final Entity-Relationship diagram that is a global logical representation of the enterprise; 5. Review global logical data model with users to ensure that it is a representation of the enterprise;

4.6 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. Decide how to represent the base relvars identified in the global logical data model in the target DBMS; 2. 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. Analyze transactions to understand the functionality of them; 2. Choose an efficient file organization for base relations; 3. Choose secondary indexes if they will improve the performance of the system; 4. Consider the introduction of controlled redundancy (relaxing the normalization) if it will improve the performance of the system; 5. Estimate disk space requirements of the database;

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.

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.

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-to- one.

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. Build local logical data models based on the local conceptual data models. 2. 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.

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.

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. 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. 2. Delete occurrence from child relation – it causes no problem because the referential integrity is not affected. 3. Update foreign key of child occurrence – similar to case 1. 4. Insert occurrence into parent relations – it causes no problem for referential integrity. 5. 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. 6. 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;

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 Oracle8iTM 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 Oracle8iTM.

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).

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.

Figure 6.1. A database interface (API) can perform complex operations using multiple types of databases.

6.2.1 Microsoft’s Data Access Components (MDAC)

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.

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 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.

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.

Figure 6.6. The database client technologies and how they relate to each other.

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.

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.

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) ‘ Print the first column of the table of the current Recordset rs.MoveNext ‘ Move to the next Recordset i.e. move to the next row in the table Wend rs.Close

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.

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.

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 SQL- query to the database, search for a table, search for an attribute in a table and create a configuration file.

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.

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.

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.

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 end- users. 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.

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.

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:

 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.

9.2 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.

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.

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:  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

72 18/01/18 Magdalena Bozyk & Fredrik Mannerstedt or when the application design is complete. During the design of MS Help user defines Help text against modules, module components, and items.

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.

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 Oracle8iTM 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.

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.

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

Appendixes

A. Entity Descriptions B. Relationship Descriptions C. Attribute Descriptions D. Tables Created during design of Conceptual Data Model E. Entity-Relationship Diagram F. Relvars in DBDL (Database Definition Language)

Appendix A

Entity Descriptions

Entity name Description Aliases Occurrence MECHANICAL_UNIT Mechanical unit, can be Every unit that is robot or a single controlled by the system is a mechanical unit ROBOT A mechanical unit with Specific individual Every robot is a more than one axis mechanical unit ROBOT_TYPE A type of the robot in use Every robot is of some type JOINT A joint is an axis. It moves There is as many joints as an arm. axis per robot AXC_FILTER Control filter for en axis Every axis is controlled in some way ARM Arm is a part of a robot. Every joint has an arm PARALLEL_ARM_LOAD Some arms have to use parallel arm load. ARM_TYPE Type of the arm in use ACC_DATA ARM_CHECK_POINT

Appendix B

Relationship descriptions

Entity type Relationship type Entity type Cardinality Participation ratio MECHANICAL_UNIT is a ROBOT 1:1 P:T ROBOT_TYPE is type of ROBOT 1:M T:T JOINT is part of ROBOT 1:M T:P moves ARM 1:1 T:T AXC_FILTER controls JOINT 1:M T:T ARM is of ARM_TYPE 1:1 T:T ACC_DATA ARM 1:M T:T ARM_CHECK_POINT ARM 1:M T:P PARALLEL_ARM_LOAD ARM_TYPE 1:M T:P

Appendix C

Attribute Descriptions

Entity Names of attributes Description Data type Constr- Default Key Null? Derived and length aint value MECHA name Mechanical unit name char[16] S, O primary No No NICAL_ UNIT use_robot_family Mechanical unit contains char[10] S foreign Yes No robot use_robot_arm_load Mechanical unit contains char[10] S foreign Yes No robot use_robot_load_mass Mechanical unit contains char[10] S foreign Yes No robot user_frame_moved_by Name of robot or single char[16] S Yes No that moves the user frame stand_by_state If NO, then the unit goes BOOL S No No to control on immediately with Motor on speed_offset_adjustment Adjust speed offset when BOOL S FALSE No No activating mech unit after Warm/Cold start activate_at_start_up Activate the mech. unit BOOL S FALSE No No at start-up do_not_allow_deactivation Mech. unit is not allowed BOOL S FALSE No No to be deactivated ROBOT family Name of the robot family char[10] primary No No arm_length The chooseable arm char[10] primary No No length default_load_mass Mass of default load [kg] char[10] same as primary No No default_ load_ma ss in ROBOT _TYPE use_robot_type Id name of robot type char[20] S foreign No No use_joint_0 Id name of 1st joint char[16] S,O foreign Yes No use_joint_1 Id name of 2nd joint char[16] S,O foreign Yes No use_joint_2 Id name of 3rd joint char[16] S,O foreign Yes No use_joint_3 Id name of 4th joint char[16] S,O foreign Yes No use_joint_4 Id name of 5th joint char[16] S,O foreign Yes No use_joint_5 Id name of 6th joint char[16] S,O foreign Yes No base_frame_pos_x Position of base frame float S,O, 0 No No wrt world coord system -1000 to [m] 1000 base_frame_pos_y float S,O, 0 No No -1000 to 1000 base_frame_pos_z float S,O, 0 No No

-1000 to 1000 base_frame_orient_u0 Orientation of base frame float S,O, -1 1 No No wrt world coord system to 1 [quaternion] base_frame_orient_u1 float S,O, –1 0 No No to 1 base_frame_orient_u2 float S,O, –1 0 No No to 1 base_frame_orient_u3 float S,O, –1 0 No No to 1 base_frame_coordinated Name of robot or single char[16] S,O Yes No that moves this robot's base position gravity_beta Orientation of gravity wrt float S,O, 0 No No base frame [rad] - 6.28318 6 to 6.28318 6 base_mass Mass of base [kg] float 0.0 to 0.0 No No 500.0 base_mass_centre_x Mass centre of base x- float -5.0 to 0.0 No No coordinate [m] 5.0 base_mass_centre_y Mass centre of base y- float -5.0 to 0.0 No No coordinate [m] 5.0 base_mass_centre_z Mass centre of base z- float -5.0 to 0.0 No No coordinate [m] 5.0 rot_x_tol Orientation tolerance for float S,O, 0 0.001 No No general kinematics [rad] to 4.0 rot_y_tol Orientation tolerance for float S,O, 0 0.001 No No general kinematics [rad] to 4.0 rot_z_tol Orientation tolerance for float S,O, 0 0.001 No No general kinematics [rad] to 4.0 pos_x_tol Position tolerance for float S,O, 0 0.0001 No No general kinematics [m] to 1.0 pos_y_tol Position tolerance for float S,O, 0 0.0001 No No general kinematics [m] to 1.0 pos_z_tol Position tolerance for float S,O, 0 0.0001 No No general kinematics [m] to 1.0 upper_work_area_x Cartesian upper x bound float S,O 0 No No for work area [m] lower_work_area_x Cartesian lower x bound float S,O 0 No No for work area [m] upper_work_area_y Cartesian upper y bound float S,O 0 No No for work area [m] lower_work_area_y Cartesian lower y bound float S,O 0 No No for work area [m] upper_work_area_z Cartesian upper z bound float S,O 0 No No for work area [m] lower_work_area_z Cartesian lower z bound float S,O 0 No No for work area [m] lower_arm_cp_bound_x Cartesian bound on arm float S 0 No No check point [m] lower_arm_cp_bound_y Cartesian bound on arm float S 0 No No check point [m]

lower_arm_cp_bound_z Cartesian bound on arm float S 0 No No check point [m] upper_arm_cp_bound_x Cartesian bound on arm float S 0 No No check point [m] upper_arm_cp_bound_y Cartesian bound on arm float S 0 No No check point [m] upper_arm_cp_bound_z Cartesian bound on arm float S 0 No No check point [m] linear_jog_allowed linear jog allowed bool FALSE No No use_six_axis_corvec Use six axis corvec bool FALSE No No ROBOT_ name Unique robot_type Id char[20] primary No No TYPE name type Choice of pre-defined char[16] No No robot types from man_robot_type error_model Model used to determine char[16] No No kinematic configuration, ex. "NOMINAL" no_of_joints Number of joints in the int No No robot's kinematic description master_robot States if this robot is the bool FALSE No No system master robot use_default_load Id name of default load char[20] 0 Yes No default_load_mass Mass of default load [kg] float 0 to No No 10000 default_load_mass_centre_x Center of mass location float -3 to 3 0 No No for default load [m] default_load_mass_centre_y Center of mass location float -3 to 3 0 No No for default load [m] default_load_mass_centre_z Center of mass location float -3 to 3 0 No No for default load [m] default_load_inertia_x Inertia at center of float 0 to 0 No No gravity of default load 1000 [kg*m*m] default_load_inertia_y Inertia at center of float 0 to 0 No No gravity of default load 1000 [kg*m*m] default_load_inertia_z Inertia at center of float 0 to 0 No No gravity of default load 1000 [kg*m*m] upper_joint_0_bound_reduce Reduced upper joint limit float -100000 100000 No No d for 1st joint [rad] to 10000 lower_joint_0_bound_reduce Reduced lower joint limit float -100000 -100000 No No d for 1st joint [rad] to 100000 lower_joint_2_bound_reduce Reduced lower joint limit float -100000 -100000 No No d for 3rd joint [rad] to 10000 soft_static_position_ratio float 1 to 100 1 No No soft_static_speed_ratio float 1 to 20 1 No No soft_influence_pos_speed_rat float 1 to 10 1 No No io work_area_cylinder_radius Cylindrical bound on arm float 0 No No check point [m]

work_area_cylinder_min_z Cylindrical bound on arm float 0 No No check point [m] work_area_cylinder_max_z Cylindrical bound on arm float 0 No No check point [m] base_pose_rot_u0 Rotation between int and float -1 to 1 1 No No ext baseframe definitions [quaternion] base_pose_rot_u1 Rotation between int and float -1 to 1 0 No No ext baseframe definitions [quaternion] base_pose_rot_u2 Rotation between int and float - 1 to 1 0 No No ext baseframe definitions [quaternion] base_pose_rot_u3 Rotation between int and float -1 to 1 0 No No ext baseframe definitions [quaternion] supervision_deactivate_in_au Supervision is deactive in BOOL FALSE No No to_mode aoto and 100% manual mode par_id_type Type of identification char[16] default No No allowed for this robot JOINT name Unique joint name char[16] S primary No No logical_axis Axis number as seen by short S, 0 to No No RAPID program 12 use_axc_filter used axc filter char[16] foreign No No use_arm Id name for arm char[16] S foreign No No connector_board Connector board number int S, 1 to 4 1 No No (1..4) uncalibrated_control_master_ uncalibrated control char[16] S No No type master type normal_control_master_type normal control master char[16] S No No type lock_joint_in_hardware Flag indicating if the bool S FALSE No No joint has mea and drive system in DSP lock_joint_in_ipol Flag indicating if the bool FALSE No No joint is permanently locked in ipol lock_joint_in_servo Flag indicating if the bool FALSE No No joint is permanently locked in ipol passive_joint Flag indicating if the bool FALSE No No drive unit should be passive or not slave_to_joint The joint is a position char[16] S Yes No slave to joint named xxx stand_alone_mode_allowed This joint is allowed to bool S FALSE No No move by external control AXC_ name axc filter name char[16] primary No No FILTER position_controller_mode_4 Run position loop with 4 BOOL FALSE No No ms ms sampling time reserve_time_slot Reserves ctl time slot == BOOL FALSE No No mea time slot anti_windup_tracking_time Time constant for the float -1 No No torque_limit_excess feedback [s] speed_ref_based_torque_limi Set calculation-mode for BOOL FALSE No No

tation torque limit speed ARM name Unique ARM Id name char[16] S,O primary No No use_arm_type Id name for arm type char[16] S foreign No No use_acc_data Id name for acc data char[16] S,O foreign No No use_check_point Id name for check point char[24] S foreign Yes No independent_joint_on bool S FALSE No No upper_joint_bound Upper joint limit (arm float S,O, 1885 No No side), rad - 125663 7 to 125663 7 lower_joint_bound Lower joint limit (arm float S,O, -1885 No No side), rad - 125663 7 to 125663 7 upper_joint_bound_max Maximal value for float - 200000 No No upper_joint_bound (arm 200000 00 side), rad 00 to 200000 00 lower_joint_bound_min Minimal value for float - - No No lower_joint_bound (arm 200000 200000 side), rad 00 to 00 200000 00 ind_upper_joint_bound Independent upper joint float S, O, 0 No No limit (arm side), rad - 200000 00 to 200000 00 ind_lower_joint_bound Independent lower joint float S,O, 0 No No limit (arm side), rad - 200000 00 to 200000 00 upper_coupled_joint_bound_ Coupled upper joint limit float S,O, 100000 No No 2 with joint[this + 2] (arm - side), rad 251327 4 to 251327 4 lower_coupled_joint_bound_ Coupled lower joint limit float S,O, -100000 No No 2 with joint[this + 2] (arm - side), rad 251327 4 to 251327 4 upper_joint_coupl_bound Coupled upper joint limit float -3 to 3 0 No No rel joint[this - 1] (arm side), rad lower_joint_coupl_bound Coupled lower joint limit float - 3 to 3 0 No No rel joint[this - 1] (arm

side), rad cal_position Calibration position (arm float S,O – 0 No No side) rad 1000 to 1000 load_id_acc_ratio Acceleration ratio for float S, 0.2 to 1.0 No No identification of payload 1.0 inertia performance_quota Performance reduction float S,O, 1.0 No No (1.0 = normal 0.45 to performance) 1.0 supervision_jam_time_factor Trim factor for JAM float S, 0.1 to 1.0 No No supervision 10.0 supervision_load_factor Trim factor for LOAD float S, 0.1 to 1.0 No No supervision 10.0 supervision_speed_factor Trim factor for all three float S, 0.05 1.0 No No SPEED supervisions to 10.0 supervision_pos_factor Trim factor for both POS float S, 0.1 to 1.0 No No supervisions 10.0 sync_speed_high High sync speed on arm float S, 0.0 to 0.2 No No side, (rad/s) or (m/s) 2.0 (Rot/Lin) sync_speed_low Low sync speed on arm float S, 0.0 to 0.016 No No side, (rad/s) or (m/s) 2.0 (Rot/Lin) ext_const_torque This is A in Ext_torque = float S,O, 0.0 0.0 No No A + | k * (fi-fi0) to 100000. 0 ext_prop_torque This is k in Ext_torque = float S,O, 0.0 No No A + | k * (fi-fi0) | - 100000. 0 to 100000. 0 ext_prop_zero_angle This is fi0 in Ext_torque float S,O, 0.0 No No = A + | k * (fi-fi0) | - 100000. 0 to 100000. 0 PARALLE name arm load name char[16] primary No No L_ARM _LOAD length float 0 to 0 No No 2000 mass float 0 to 0 No No 1000 mass_centre_x float -3 to 3 0 No No mass_centre_y float -3 to 3 0 No No mass_centre_z float -3 to 3 0 No No inertia_x float 0 to 0 No No 1000 inertia_y float 0 to 0 No No 1000 inertia_z float 0 to 0 No No 1000 ARM_ name Unique ARM_TYPE Id char[16] S,O primary No No TYPE name use_parallel_arm_load Id name for parallel arm char[16] foreign Yes No

load independent_move_off Independent move is not BOOL FALSE No No possible with arm direction_x Unit vector for positive float -1 to 1 0 No No direction direction_y float - 1 to 1 0 No No direction_z float -1 to 1 0 No No home Arm's home position float - 10 to 0 No No [rad] or [m] 10 length Arm length, [m] float 0 to 100 0 No No offset_x Offset between arm's 1st float -10.0 to 0 No No and 2nd joints, x 10.0 direction [m] offset_y Offset between arm's 1st float -10.0 to 0 No No and 2nd joints, y 10.0 direction [m] offset_z Offset between arm's 1st float -10.0 to 0 No No and 2nd joints, z 10.0 direction [m] attitude Angle between the arm's float - 10 to 0 No No two joints. [rad] 10 theta_home_position Joint angle of arm in float - 10 to 0 No No home position. [rad] 10 rot_axis_pose_pos_x X coordinate of centre of float S,O, 0 No No rotation of axis -1000 to 1000 rot_axis_pose_pos_y Y coordinate of centre of float S,O, 0 No No rotation of axis -1000 to 1000 rot_axis_pose_pos_z Z coordinate of centre of float S,O, 0 No No rotation of axis -1000 to 1000 rot_axis_pose_orient_u0 Orientation u0 of rotation float S,O, -1 1 No No axis to 1 rot_axis_pose_orient_u1 Orientation u0 of rotation float S,O, -1 0 No No axis to 1 rot_axis_pose_orient_u2 Orientation u0 of rotation float S,O, -1 0 No No axis to 1 rot_axis_pose_orient_u3 Orientation u0 of rotation float S,O, -1 0 No No axis to 1 mass Arm mass [kg] float 0 to 0 No No 10000 mass_centre_x Center of mass location float -3 to 3 0 No No in arm's coord system [m] mass_centre_y Center of mass location float - 3 to 3 0 No No in arm's coord system [m] mass_centre_z Center of mass location float - 3 to 3 0 No No in arm's coord system [m] inertia_x Inertia about arm's center float 0 No No of mass kgm**2 inertia_y Inertia about arm's center float 0 No No of mass kgm**2 inertia_z Inertia about arm's center float 0 No No of mass kgm**2 max_bend_trq_z Supervised maximum z- float 0 to 100000 No No

torque [Nm] 100000 bend_trq_z_margin Normalized auxiliary float 0.1 to 0.9 No No torque margin 1.0 bend_trq_z_max_acc_quota Max acc utilization float 1.0 No No quota, [0..1], 1.0 = use full dyn mod acc max_micro_sample_bend_trq Maximum allowed z- float 0 to 0 No No _z torque for micro sample 100000 supervision [Nm] max_rapid_weave_bend_trq_ Maximum allowed z- float 0 to 0 No No z torque for rapid weave 100000 supervision [Nm] max_micro_sample_torque Maximum allowed float 0 to 0 No No torque (gear or motor) 100000 for micro sample supervision [Nm] max_rapid_weave_torque Maximum allowed float 0 to 0 No No torque (gear or motor) 100000 for rapid weave supervision [Nm] rear_length Arm's length towards the float 0 No No rear of the robot [m], for checkpoint length_of_housing Length of upper arm float 0 to 100 0 No No housing [m] max_dyn_fric Max dynamic friction float 0 No No factor , Nm/rad/s min_dyn_fric Min dynamic friction float 0 No No factor, Nm/rad/s max_stat_fric Max static friction, Nm float 0 No No min_stat_fric Min static friction, Nm float 0 No No min_inertia Min arm inertia, kgm**2, float 0 No No (not including motor, brake, transm) max_inertia Max load+arm inertia, float 0 No No kgm**2 (not including motor, brake, transm) transm_inertia Transmission inertia float -1 to 0 No No kgm**2 (arm side) 1000 relative_stiffness Relative stiffness of arm, float 1.00 No No 1.0 = normal stiffness tuning max_acc Arm max acc, rad/s**2 float 200 No No max_acc_quota Max acc utilization float S,O, 0.2 No No quota, [0..1], 1.0 = use to 1.0 full dyn mod acc rel_dist_torque_model_error Relative disturbance float 0 to 0.5 0.0 No No torque model error. 0.1 = 10% error abs_dist_torque_model_error Saves extra torque to be float 0 to 0.0 No No used for acc.Arm side.No 100000 couplings are handled torque_margin_for_speed_rat Normalized torque float 0.1 to 0.9 No No io_0 margin for low speeds 1.0 torque_margin_for_speed_rat Normalized torque float 0.1 to 0.9 No No io_1 margin for high speeds 1.0 torque_margin_for_speed_rat Normalized cutin point float 0.1 to 1.0 No No io_cutin for high speed torque 1.0

margin emergency_stop_torque_mar Torque margin for float 0 to 1 0 No No gin dynmod emergency stop calculations, 0.1 = save 10% as margin ACC_ name acc data name char[16] S,0 primary No No DATA wc_acc Worst case motor acc, float S,0, 0 to No No rad/s**2 (arm side) 1000 wc_dec Worst case motor dec, float S,0, 0 to No No rad/s**2 (arm side) 1000 wc_dacc_ratio Worst case motor acc float S,0, 0.1 1.0 No No derivate ratio to 1.0 wc_ddec_ratio Worst case motor dec float S,0, 0.1 1.0 No No derivate ratio to 1.0 ARM_ name arm check point name char[24] S,0 primary No No CHECK_ POINT checktype char[16] S,0 No No position_x float S,0, -3 No No to 3 position_y float S,0, -3 No No to 3 position_z float S,0, -3 No No to 3

Appendix D

Tables created during Design of Conceptual Data Model

MECHANICAL_UNIT name use_robot_family use_robot_arm_length use_robot_load_mass user_frame_moved_by 4400_2.45_30 4400 2.45 30 NULL 4400_1.95_60 4400 1..95 60 NULL 4400_1.95_45 4400 1.95 45 NULL 4400_2.6_10 4400 2.6 10 NULL 4400_s2.45_30 4400 s2.45 30 NULL 4400_sc2.45_30 4400 sc2.45 30 NULL stand_by_state speed_offset_adjustment active_at_start_up do_not_allow_deactivation TRUE FALSE TRUE TRUE TRUE FALSE TRUE TRUE TRUE FALSE TRUE TRUE TRUE FALSE TRUE TRUE TRUE FALSE TRUE TRUE TRUE FALSE TRUE TRUE

AXC_FILTER name position_controller_mode_4ms reserve_time_slot anti_windup_tracking_time speed_ref_based_torque_limitation irb_1 TRUE TRUE -1 FALSE

ARM_CHECK_POINT name checktype position_x position_y position_z irb_1 POS -0.4 0 0.265

ACC_DATA name wc_acc wc_dec wc_dacc_ratio wc_ddec_ratio irb_1 3 3 1.0 1.0 irb_2 6 6 1.0 1.0 irb_3 15 15 1.0 1.0 irb_4 20 20 1.0 1.0

PARALLEL_ARM_LOAD name length mass mass_centre_x mass_centre_y mass_centre_z inertia_x inertia_y inertia_z irb_1 0 14 0 0 0.443 0 0 0 irb_2 0 120 0.442 0 0 0 0 0 irb_3 0 69 0.398 0 0 0 0 0

ROBOT family arm_length default_load_mass use_robot_type use_robot_calib use_joint_0 use_joint_1 use_joint_2 4400 2.45 30 4400_30 NULL irb_1 irb_2 irb_3 4400 1.95 60 4400_60 NULL irb_7 irb_8 irb_9 4400 1.95 45 4400_45 NULL irb_11 irb_12 irb_13 4400 2.6 10 4400_10 NULL irb_14 irb_15 irb_16 4400 s2.45 30 4400_30 NULL irb_1 irb_20 irb_3 4400 sc2.45 30 4400_30 NULL irb_21 irb_20 irb_3 use_joint_3 use_joint_4 use_joint_5 base_frame_pos_x base_frame_pos_y base_frame_pos_z irb_4 irb_5 irb_6 0 0 0 irb_10 irb_5 irb_6 0 0 0 irb_10 irb_5 irb_6 0 0 0 irb_17 irb_18 irb_19 0 0 0 irb_4 irb_5 irb_6 0 0 0 irb_4 irb_5 irb_6 0 0 0 base_frame_orient_u0 base_frame_orient_u1 base_frame_orient_u2 base_frame_orient_u3 base_frame_coordinate d 1 0 0 0 NULL 1 0 0 0 NULL 1 0 0 0 NULL 1 0 0 0 NULL 1 0 0 0 NULL 1 0 0 0 NULL

gravity_beta base_mass base_mass_centre_x base_mass_centre_y base_mass_centre_z rot_x_tol rot_y_tol 0 0.0 0.0 0.0 0.0 0.001 0.001 0 0.0 0.0 0.0 0.0 0.001 0.001 0 0.0 0.0 0.0 0.0 0.001 0.001 0 0.0 0.0 0.0 0.0 0.001 0.001 0.523599 0.0 0.0 0.0 0.0 0.001 0.001 0.523599 0.0 0.0 0.0 0.0 0.001 0.001 rot_z_tol pos_x_tool pos_y_tool pos_z_tool upper_work_area_x lower_work_area_x 0.001 0.0001 0.0001 0.0001 0 0 0.001 0.0001 0.0001 0.0001 0 0 0.001 0.0001 0.0001 0.0001 0 0 0.001 0.0001 0.0001 0.0001 0 0 0.001 0.0001 0.0001 0.0001 0 0 0.001 0.0001 0.0001 0.0001 0 0 upper_work_area_y lower_work_area_y upper_work_area_z lower_work_area_z lower_arm_cp_bound_x 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 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 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 linnear_jog_allowed use_six_axis_corvec FALSE FALSE FALSE FALSE FALSE FALSE

FALSE FALSE FALSE FALSE FALSE FALSE

ROBOT_TYPE name type error_model no_of_joints master_robot use_default_load 4400_30 IRB4400_FLOOR NOMINAL 6 TRUE NULL 4400_60 IRB4400_FLOOR NOMINAL 6 TRUE NULL 4400_45 IRB4400_FLOOR NOMINAL 6 TRUE NULL 4400_10 IRB4400_FLOOR NOMINAL 6 TRUE NULL default_load_mass default_load_mass_centre_x default_load_mass_centre_y default_load_mass_centre_z 30 0.3 0 0.21 60 0.17 0 0.22 45 0.07 0 0.23 10 0.1 0 0.1 default_load_intertia_x default_load_intertia_y default_load_intertia_z upper_joint_0_bound_reduced 0.03 0.03 0.03 100000 0.6 0.6 0.6 100000 0.4 0.4 0.4 100000 0.06 0.06 0.06 100000 lower_joint_0_bound_reduced lower_joint_2_bound_reduced soft_static_position_ratio soft_static_speed_ratio -100000 -100000 18.2 5 -100000 -100000 18.2 5 -100000 -100000 18.2 5 -100000 -100000 18.2 5 soft_influence_pos_speed_ratio work_area_cylinder_radius work_area_cylinder_min_z 2.5 0 0 2.5 0 0 2.5 0 0 2.5 0 0 work_area_cylinder_max_z base_pose_rot_u0 base_pose_rot_u1 base_pose_rot_u2 base_pose_rot_u3 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 supervision_deactivate_in_auto_mode par_id_type FALSE coupling FALSE coupling FALSE coupling FALSE coupling

JOINT name logical axis use_axc_filter use_arm connector_board uncalibrated_contol_master_type irb_1 1 irb_1 irb_1 1 UCCM0 irb_2 2 irb_1 irb_2 1 UCCM0 irb_3 3 irb_1 irb_3 1 UCCM0 irb_4 4 irb_1 irb_4 1 UCCM0 irb_5 5 irb_1 irb_5 1 UCCM0 irb_6 6 irb_1 irb_6 1 UCCM0 irb_7 1 irb_1 irb_7 1 UCCM0 irb_8 2 irb_1 irb_8 1 UCCM0 irb_9 3 irb_1 irb_9 1 UCCM0 irb_10 4 irb_1 irb_10 1 UCCM0 irb_11 1 irb_1 irb_11 1 UCCM0 irb_12 2 irb_1 irb_12 1 UCCM0 irb_13 3 irb_1 irb_13 1 UCCM0 irb_14 1 irb_1 irb_14 1 UCCM0 irb_15 2 irb_1 irb_15 1 UCCM0 irb_16 3 irb_1 irb_16 1 UCCM0 irb_17 4 irb_1 irb_17 1 UCCM0 irb_18 5 irb_1 irb_18 1 UCCM0 irb_19 6 irb_1 irb_19 1 UCCM0 irb_20 2 irb_1 irb_20 1 UCCM0 irb_21 1 irb_1 irb_21 1 UCCM0

normal_control_master_type lock_joint_in_hardware lock_joint_in_pool lock_joint_in_servo passive_joint FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE FFWCM1 FALSE FALSE FALSE FALSE

JOINT fotrs slave_to_joint stand_alone_mode_allowed NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE NULL FALSE

ARM_TYPE

name use_parallel_arm_load independent_move_off direction_x direction_y direction_z home length offset_x IRB4400_1 NULL TRUE 0 0 0 0 0.68 0 IRB4400_2 irb_1 TRUE 0 0 0 0 0.89 0.2 IRB4400_3 irb_2 TRUE 0 0 0 0 1.38 0 IRB4400_4 NULL TRUE 0 0 0 0 1.18 0 IRB4400_5 NULL TRUE 0 0 0 0 0 0 IRB4400_6 NULL FALSE 0 0 0 0 0.14 0 IRB4400_7 NULL TRUE 0 0 0 0 0.68 0 IRB4400_8 irb_1 TRUE 0 0 0 0 0.89 0.2 IRB4400_9 irb_2 TRUE 0 0 0 0 0.88 0 IRB4400_10 NULL TRUE 0 0 0 0 0.68 0 IRB4400_11 NULL TRUE 0 0 0 0 0.68 0 IRB4400_12 irb_1 TRUE 0 0 0 0 0.89 0.2 IRB4400_13 irb_3 TRUE 0 0 0 0 0.88 0 IRB4400_14 NULL TRUE 0 0 0 0 0.68 0 IRB4400_15 irb_1 TRUE 0 0 0 0 0.89 0.2 IRB4400_16 irb_2 TRUE 0 0 0 0 1.5 0 IRB4400_17 NULL TRUE 0 0 0 0 1.3 0 IRB4400_18 NULL TRUE 0 0 0 0 0 0 IRB4400_19 NULL FALSE 0 0 0 0 0.085 0 IRB4400_20 irb_1 TRUE 0 0 0 0 0.89 0.2 IRB4400_21 NULL TRUE 0 0 0 0 0.68 0 offset_y offset_z attitude theta_home_position rot_axis_pose_pos_x rot_axis_pose_pos_y rot_axis_pose_pos_z 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.15 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.15 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.15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.15 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

ARM_TYPE forts. rot_axis_pose_orient_u0 rot_axis_pose_orient_u1 rot_axis_pose_orient_u2 rot_axis_pose_orient_u3 mass mass_centre_x 1 0 0 0 406 0.027 1 0 0 0 73 0 1 0 0 0 185.3 0.392 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 3.9 -0.103 1 0 0 0 406 0.027 1 0 0 0 73 0 1 0 0 0 153.1 0.2048 1 0 0 0 0 0 1 0 0 0 406 0.027 1 0 0 0 73 0 1 0 0 0 153.1 0.2048 1 0 0 0 406 0.027 1 0 0 0 73 0 1 0 0 0 149.1 0.222 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0.9 -0.057 1 0 0 0 73 0 1 0 0 0 636 -0.197 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 0 0 0 0 37.9 100000 0.9 1.0 0 0.34 8.06 9.279 0 100000 0.9 1.0 -0.014 -0.012 1.745 75.487 75.865 100000 0.9 1.0 0 0 0 0 0 100000 0.9 1.0 0 0 0 0 0 100000 0.9 1.0 0 0 0.0033 0.021 0.021 100000 0.9 1.0 0 0 0 0 37.9 100000 0.9 1.0 0 0.34 8.06 9.279 0 100000 0.9 1.0 0 -0.0163 0 36.1872 36.0129 100000 0.9 1.0 0 0 0 0 0 100000 0.9 1.0 0 0 0 0 37.9 100000 0.9 1.0 0 0.34 8.06 9.279 0 100000 0.9 1.0 0 -0.0163 0 36.1872 36.0129 100000 0.9 1.0 0 0 0 0 37.9 100000 0.9 1.0 0 0.34 8.06 9.279 0 100000 0.9 1.0 -0.0136 -0.014 1.7319 44.02 44.02 100000 0.9 1.0 0 0 0 0 0 100000 0.9 1.0 0 0 0 0 0 100000 0.9 1.0 0 0 0.0033 0.021 0.021 100000 0.9 1.0 0 0.34 8.06 9.279 0 100000 0.9 1.0 0 0 0 0 97 100000 0.9 1.0

ARM_TYPE forts. max_micro_sample_bend_trq_z max_rapid_weave_bend_trq_z max_micro_sample_torque max_rapid_weave_torque rear_length 0 0 1650 1 0 0 0 1650 1 0 0 0 1650 1 0.3 0 0 589 1 0 0 0 545 1 0 0 0 209 1 0 0 0 1650 1 0 0 0 1650 1 0 0 0 1650 1 0.3 0 0 589 1 0 0 0 1650 1 0 0 0 1650 1 0 0 0 1650 1 0.3 0 0 1650 1 0 0 0 1650 1 0 0 0 1650 1 0.3 0 0 589 1 0 0 0 93.5 1 0 0 0 42.2 1 0 0 0 1650 1 0 0 0 1650 1 0 length_of_housing max_dyn_fric min_dyn_fric max_stat_fric min_stat_fric min_inertia max_inertia transm_inertia 0 0 0 0 0 50.6 1100 2.8 0 0 0 0 0 8.8 350 2.8 0.2 0 0 0 0 35.2 300 2.8 0 0 0 0 0 0.136 14.4 0.792 0 0 0 0 0 0.0423 14.4 0.362 0 0 0 0 0 0.0033 6.15 0.1152 0 0 0 0 0 50.6 910 27.6 0 0 0 0 0 8.8 265 27.6 0.2 0 0 0 0 35.2 200 27.6 0 0 0 0 0 0.136 14.4 0.792 0 0 0 0 0 50.6 910 27.6 0 0 0 0 0 8.8 265 27.6 0.2 0 0 0 0 35.2 200 27.6 0 0 0 0 0 50.6 910 2.8 0 0 0 0 0 8.8 265 2.8 0.2 0 0 0 0 35.2 200 2.8 0 0 0 0 0 0.136 6 0.414 0 0 0 0 0 0.0423 6 0.895 0 0 0 0 0 0.0033 5 0.719 0 0 0 0 0 8.8 350 2.8 0 0 0 0 0 50.6 1100 2.8

ARM_TYPE forts. relative_stiffness max_acc max_acc_quota rel_dist_torque_model_error abs_dist_torque_model_error 1.00 10000 0.9 0.0 0.0 1.00 10000 0.95 0.0 0.0 1.00 10000 0.9 0.0 0.0 1.00 10000 0.85 0.0 0.0 1.00 10000 0.9 0.0 0.0 1.00 10000 0.9 0.0 0.0 1.00 10000 0.9 0.0 0.0 1.00 10000 0.9 0.0 0.0 1.00 10000 0.95 0.0 0.0 1.00 10000 0.85 0.0 0.0 1.00 10000 0.95 0.0 0.0 1.00 10000 0.95 0.0 0.0 1.00 10000 1 0.0 0.0 1.00 10000 0.9 0.0 0.0 1.00 10000 0.9 0.0 0.0 1.00 10000 0.9 0.0 0.0 1.00 10000 0.9 0.0 0.0 1.00 10000 0.8 0.0 0.0 1.00 10000 0.8 0.0 0.0 1.00 10000 0.95 0.0 0.0 1.00 10000 0.9 0.0 0.0 torque_margain_for_speed_ratio_0 torque_margain_for_speed_ratio_1 torque_margin_for_speed_ratio_cutin 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0 0.9 0.9 1.0

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

ARM name use_arm_type use_acc_data use_check_point independent_joint_on upper_joint_bound irb_1 IRB4400_1 irb_1 NULL FALSE 2.879793 irb_2 IRB4400_2 irb_2 NULL FALSE 1.658063 irb_3 IRB4400_3 irb_2 irb_1 FALSE 2.70526 irb_4 IRB4400_4 irb_3 NULL FALSE 3.49066 irb_5 IRB4400_5 irb_3 NULL FALSE 2.094395 irb_6 IRB4400_6 irb_3 NULL FALSE 6.98132 irb_7 IRB4400_7 irb_1 NULL FALSE 2.879793 irb_8 IRB4400_8 irb_2 NULL FALSE 1.658063 irb_9 IRB4400_9 irb_2 irb_1 FALSE 2.70526 irb_10 IRB4400_10 irb_3 NULL FALSE 3.49066 irb_11 IRB4400_11 irb_1 NULL FALSE 2.879793 irb_12 IRB4400_12 irb_2 NULL FALSE 1.658063 irb_13 IRB4400_13 irb_2 irb_1 FALSE 2.70526 irb_14 IRB4400_14 irb_1 NULL FALSE 2.879793 irb_15 IRB4400_15 irb_2 NULL FALSE 1.658063 irb_16 IRB4400_16 irb_2 irb_1 FALSE 2.70526 irb_17 IRB4400_17 irb_3 NULL FALSE 3.49066 irb_18 IRB4400_18 irb_4 NULL FALSE 2.094395 irb_19 IRB4400_19 irb_4 NULL FALSE 6.98132 irb_20 IRB4400_20 irb_2 NULL FALSE 1.570796 irb_21 IRB4400_21 irb_1 NULL FALSE 2.879793 lower_joint_bound upper_joint_bound_max lower_joint_bound_min ind_upper_joint_bound ind_lower_joint_bound -2.879793 2.879793 -2.879793 0 0 -1.396263 1.658063 -1.396263 0 0 -0.523599 2.70526 -0.523599 0 0 -3.49066 1260 -1260 0 0 -2.094395 2.094395 -2.094395 0 0 -6.98132 1260 -1260 0 0 -2.879793 2.879793 -2.879793 0 0 -1.396263 1.658063 -1.396263 0 0 -0.523599 1.047198 -1.134464 0 0 -3.49066 1260 -1260 0 0 -2.879793 2.879793 -2.879793 0 0 -1.396263 1.658063 -1.396263 0 0 -0.523599 1.047198 -1.134464 0 0 -2.879793 2.879793 -2.879793 0 0 -1.396263 1.658063 -1.396263 0 0 -0.523599 2.70526 -0.523599 0 0 -3.49066 1260 -1260 0 0 -2.094395 2.094395 -2.094395 0 0 -6.98132 1260 -1260 0 0 -1.396263 1.570796 -1.396263 0 0 -2.879793 2.879793 -2.879793 0 0

ARM forts.

upper_coupled_joint_bound_2 lower_coupled_joint_bound_2 upper_joint_coupl_bound lower_joint_coupl_bound cal_position 100000 -100000 0 0 0 100000 -100000 0 0 0 100000 -100000 1.047198 -1.134464 0 100000 -100000 0 0 0 100000 -100000 0 0 0 100000 -100000 0 0 0 100000 -100000 0 0 0 100000 -100000 0 0 0 100000 -100000 1.047198 -1.134464 0 100000 -100000 0 0 0 100000 -100000 0 0 0 100000 -100000 0 0 0 100000 -100000 1.047198 -1.134464 0 100000 -100000 0 0 0 100000 -100000 0 0 0 100000 -100000 1.047198 -1.134464 0 100000 -100000 0 0 0 100000 -100000 0 0 0 100000 -100000 0 0 0 100000 -100000 0 0 0 100000 -100000 0 0 0 load_id_acc_ratio performance_quota supervision_load_factor supervision_speed_factor 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 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 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 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 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

ARM forts. sync_speed_high sync_speed_low ext_const_torque ext_prop_torque ext_prop_zero_angle 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0 0.2 0.016 0.0 0.0 0.0

Appendix E

Entity-Relationship Diagram

AXC_FILTER

MECHANICAL_U 1 NIT 1 contro Is a ls 1 M M ROBOT JOINT

1 M Is 1 part of Is type of moves

ROBOT_TYPE 1 1 ARM M M 1

Is of 1 ARM_C_POINT 1 1 ACC_DATA ARM_TYPE M

1 PARALLEL_ARM_LO AD

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) references ROBOT_TYPE (name) On Update restrict On Delete restrict

Foreign Key (use_joint_0) references JOINT (name) On Update restrict On Delete restrict

ROBOT_TYPE (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) references AXC_FILTER (name) On Update restrict On Delete restrict

Foreign Key (use_arm) references ARM (name) On Update restrict On Delete 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) references ARM_TYPE (name) On Update restrict On Delete restrict

Foreign Key (use_acc_data) references ACC_DATA (name) On Update restrict

On Delete restrict

Foreign Key (use_check_point) references ARM_CHECK_POINT (name) On Update restrict On Delete restrict

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) references PARALLEL_ARM_LOAD (name) On Update restrict On Delete restrict

PARALLEL_ARM_LOAD (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)