1. Introduction

This HOWTO guides you through the installation of SQL Anywhere Studio 7.0.2 for Linux and the basic operation and administration of Adaptive Server Anywhere databases.

1.1. New versions of this document

The latest version of this document should always be available at the Linux Documentation project website (http://www.linuxdoc.org/).

1.2. Content and Audience

Within this document, you will find a list of the supported Linux distributions ("Section 2"). It is intended for moderately experienced users of Linux or UNIX. Familiarity with relational database concepts is certainly useful, but not a requirement. "Section 1.5" contains a summary of relational database concepts.

1.3. Adaptive Server Anywhere features

Adaptive Server Anywhere (Adaptive Server Anywhere) is the full SQL relational database management system at the heart of SQL Anywhere Studio. Ideally suited for use as an embedded database, in mobile computing, or as a workgroup server, it includes the following among its features:

Some of the more specific features include:

For further details about Adaptive Server Anywhere, please visit the following links:

1.4. Quirks

1.4.1. Alt and Function keys

Sometimes the Alt keys or the F1-F10 keys may not function in the terminal where you are running Interactive SQL.

To emulate the Alt key, press Ctrl-A. Then press whatever key was to be pressed with the Alt key. For example, instead of pressing Alt-F, you would press Ctrl-A, then F.

To emulate the function keys, press Ctrl-F, followed by the number of the function key you wanted to press. For example, instead of pressing F9, you would press Ctrl-F, then 9. For F10, use the zero key.

1.5. What's a Relational Database?

If you are already familiar with relational databases, you can skip this section.

1.5.1. Definition

A relational database-management system (RDBMS) is a system for storing and retrieving data, in which the data is organized in tables. A relational database consists of a collection of tables that store interrelated data.

If that doesn't quite make sense yet, read on.

1.5.2. Example

Suppose you have some software to keep track of sales orders, and each order is stored in the form of a table, called sales_order. It has information about the customer (for example, her name, address and phone number), the date of the order, and information about the sales representative (for example his name, department, and office phone number). Let's put all this into a table, with the data for a few orders:

Table 1. The sales_order table

cust_name cust_address cust_city_state_zip cust_phone order_date emp_name emp_dept emp_phone
M. Devlin 3114 Pioneer Ave. Rutherford, NJ 07070 2015558966 19930316 R. Overbey Sales 5105557255
M. Devlin 3114 Pioneer Ave. Rutherford, NJ 07070 2015558966 19940405 M. Kelly Sales 5085553769
J. Gagliardo 2800 Park Ave. Hull, PQ K1A 0H3 8195559539 19940326 M.Garcia Sales 7135553431
E. Peros 50 Market St. Rochester, NY 14624 7165554275 19930603 P. Chin Sales 4045552341
E. Peros 50 Market St. Rochester, NY 14624 7165554275 19940127 M.Garcia Sales 7135553431
E. Peros 50 Market St. Rochester, NY 14624 7165554275 19940520 J. Klobucher Sales 7135558627

Everything appears nice and ordered, but there's a fair bit of redundancy. M. Devlin's name appears twice, along with his address and phone number. E. Peros' details appear three times. If you look carefully at the employee side of things, you'll notice that M. Garcia is repeated, as well.

Wouldn't it be nice if you could separate that information and only store it once, rather than several times? In the long term, it would certainly save disk space and allow for greater flexibility. Since redundant data entry is minimized, it would also reduce the chances of erroneous data entering the database, increasing consistency. Well, we can see three different entities involved here: the customer, the order, and the employee. So let's take each of the individuals, put them into categories, and give them identification numbers so they can be referenced.

Table 2. The customer table

id name address city_state_zip phone
101 M. Devlin 3114 Pioneer Ave. Rutherford, NJ 07070 2015558966
109 J. Gagliardo 2800 Park Ave. Hull, PQ K1A 0H3 8195559539
180 E. Peros 50 Market St. Rochester, NY 14624 7165554275

Table 3. The employee table

id name dept phone
299 R. Overbey Sales 5105557255
902 M. Kelly Sales 5085553769
667 M.Garcia Sales 7135553431
129 P. Chin Sales 4045552341
467 J. Klobucher Sales 7135558627

Table 4. The new sales_order table

id cust_id order_date sales_rep_id
2001 101 19930316 299
2583 101 19940405 902
2576 109 19940326 667
2081 180 19930603 129
2503 180 19940127 667
2640 180 19940520 467

As you can see, each customer's information is stored only once, and the same goes for each employee. The sales_order table is a lot smaller, too. Each row, representing a sales order, refers to a cust_id and an emp_id.

By looking up the customer corresponding to a cust_id (which is unique), one can find all the needed data on that customer, without having to repeat it in sales_order. In addition, an id column has been added. Its purpose will be explained in the next section.

Why do this, you ask? By eliminating redundancy, this kind of structure reduces the opportunities for inconsistencies to seep in, in addition to lowering storage requirements. If you had to change E. Peros' address in the old sales_order table, you'd have to do it three times, which would take three times as long and give you three times as many chances to make an error. In the newer table, all you'd have to do is change her address once, in the customer table. Also, by carefully separating data, you make access control simpler.

Finally, can you spot another redundancy? The employee table has "Sales" all the way down the dept column. For an organization with multiple departments, you'd want to add a department table and reference it from a dept_id column instead.

1.5.3. Primary and Foreign Keys

As described in the previous section, you can separate a table into interrelated tables. But how do you go about relating tables to each other? In relational databases, primary keys and foreign keys help you link tables together. Primary keys are columns that uniquely identify each row of a table, and foreign keys define the relationship between the rows of two separate tables. Proper use of primary and foreign keys will help you efficiently hold information without excessive redundancy.

Every table should have a primary key to ensure that each row is uniquely identified. This often takes the form of an ID number being assigned to each row, as in the previous section's example. The id column forms the primary key.

As long as you can guarantee the uniqueness of the data in a particular column, though, that column can be a primary key. For example, if you only want one entry per day to be put into a particular table, you could use the date as that table's primary key.

Tables are related to one another by foreign keys. In the sales_order example, the cust_id and sales_rep columns would be called foreign keys to the customer and employee tables, respectively. For terminology's sake, you might want to know that in this case, the sales_order table is called the foreign or referencing table, while the customer and employee tables are called the primary or referenced tables.