本 HOWTO 指南将引导您完成 SQL Anywhere Studio 7.0.2 Linux 版的安装,以及 Adaptive Server Anywhere 数据库的基本操作和管理。
本文档的最新版本应始终在 Linux 文档项目网站上找到 (http://www.linuxdoc.org/)。
在本文档中,您将找到受支持的 Linux 发行版列表("第 2 节")。本文档面向具有中等经验的 Linux 或 UNIX 用户。熟悉关系数据库概念当然很有用,但不是必需的。"第 1.5 节" 包含关系数据库概念的摘要。
Adaptive Server Anywhere (Adaptive Server Anywhere) 是 SQL Anywhere Studio 核心的完整 SQL 关系数据库管理系统。它非常适合用作嵌入式数据库、移动计算或工作组服务器,其特性包括以下几点:
经济的硬件要求
设计为无需管理即可运行
专为移动计算和同步设计
易于使用
高性能
跨平台解决方案
独立和网络使用
行业标准接口
一些更具体的功能包括:
存储过程和触发器
Java 对逻辑和数据类型的支持
有关 Adaptive Server Anywhere 的更多详细信息,请访问以下链接:
http://www.sybase.com/detail/1,3693,1002624,00.html 是关于 SQL Anywhere Studio 的数据表。它包含一些关于 Adaptive Server Anywhere 的数据,Adaptive Server Anywhere 作为 SQL Anywhere Studio 的组件发布。
http://www.sybase.com/detail/1,3693,1009210,00.html 包含关于 SQL Anywhere Studio 的特性和系统要求的一些信息,并指向 SQL Anywhere Studio Linux 7.0 版本的下载位置。
有时,在您运行 Interactive SQL 的终端中,Alt 键或 F1-F10 键可能无法正常工作。
要模拟 Alt 键,请按 Ctrl-A。然后按要与 Alt 键一起按下的任何键。例如,不用按 Alt-F,您应该按 Ctrl-A,然后按 F。
要模拟功能键,请按 Ctrl-F,然后按您要按下的功能键的数字。例如,不用按 F9,您应该按 Ctrl-F,然后按 9。对于 F10,请使用数字 0 键。
如果您已经熟悉关系数据库,则可以跳过本节。
假设您有一些软件来跟踪销售订单,并且每个订单都以表格形式存储,称为 sales_order。它包含有关客户的信息(例如,她的姓名、地址和电话号码)、订单日期以及有关销售代表的信息(例如他的姓名、部门和办公室电话号码)。让我们把所有这些都放在一个表格中,包含一些订单的数据:
表 1. sales_order 表
客户姓名 | 客户地址 | 客户城市_州_邮编 | 客户电话 | 订单日期 | 员工姓名 | 员工部门 | 员工电话 |
M. Devlin | 3114 Pioneer Ave. | Rutherford, NJ 07070 | 2015558966 | 19930316 | R. Overbey | 销售部 | 5105557255 |
M. Devlin | 3114 Pioneer Ave. | Rutherford, NJ 07070 | 2015558966 | 19940405 | M. Kelly | 销售部 | 5085553769 |
J. Gagliardo | 2800 Park Ave. | Hull, PQ K1A 0H3 | 8195559539 | 19940326 | M.Garcia | 销售部 | 7135553431 |
E. Peros | 50 Market St. | Rochester, NY 14624 | 7165554275 | 19930603 | P. Chin | 销售部 | 4045552341 |
E. Peros | 50 Market St. | Rochester, NY 14624 | 7165554275 | 19940127 | M.Garcia | 销售部 | 7135553431 |
E. Peros | 50 Market St. | Rochester, NY 14624 | 7165554275 | 19940520 | J. Klobucher | 销售部 | 7135558627 |
一切看起来都井井有条,但是存在相当多的冗余。M. Devlin 的名字出现了两次,连同他的地址和电话号码。E. Peros 的详细信息出现了三次。如果您仔细查看员工方面的信息,您会注意到 M. Garcia 也被重复了。
如果可以将这些信息分开,只存储一次而不是多次,那不是很好吗?从长远来看,这肯定会节省磁盘空间并提高灵活性。由于冗余数据输入被最小化,这也将减少错误数据进入数据库的机会,从而提高一致性。好吧,我们可以看到这里涉及三个不同的实体:客户、订单和员工。因此,让我们将每个人分类,并给他们分配识别号码,以便可以引用它们。
表 2. customer 表
ID | 姓名 | 地址 | 城市_州_邮编 | 电话 |
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 |
表 3. employee 表
ID | 姓名 | 部门 | 电话 |
299 | R. Overbey | 销售部 | 5105557255 |
902 | M. Kelly | 销售部 | 5085553769 |
667 | M.Garcia | 销售部 | 7135553431 |
129 | P. Chin | 销售部 | 4045552341 |
467 | J. Klobucher | 销售部 | 7135558627 |
表 4. 新的 sales_order 表
ID | 客户 ID | 订单日期 | 销售代表 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 |
如您所见,每个客户的信息只存储一次,每个员工的信息也是如此。sales_order 表也小了很多。每一行,代表一个销售订单,都引用一个客户 ID 和一个员工 ID。
通过查找与客户 ID(唯一)对应的客户,可以找到关于该客户的所有必要数据,而无需在 sales_order 中重复。此外,还添加了一个 ID 列。其目的将在下一节中解释。
您可能会问,为什么要这样做?通过消除冗余,这种结构除了降低存储要求外,还减少了不一致性渗入的机会。如果您必须在旧的 sales_order 表中更改 E. Peros 的地址,您必须执行三次,这将花费三倍的时间,并给您三倍的机会犯错误。在较新的表中,您只需在 customer 表中更改她的地址一次即可。此外,通过仔细分离数据,您可以使访问控制更简单。
最后,您能发现另一个冗余吗?employee 表的部门列全部都是“销售部”。对于拥有多个部门的组织,您会希望添加一个部门表,并从部门 ID 列引用它。
如上一节所述,您可以将一个表分成相互关联的表。但是,您如何将表相互关联呢?在关系数据库中,主键和外键帮助您将表链接在一起。主键是唯一标识表中每一行的列,外键定义两个单独表的行之间的关系。正确使用主键和外键将帮助您有效地保存信息,而不会产生过多的冗余。
每个表都应该有一个主键,以确保唯一标识每一行。这通常采用为每一行分配 ID 号的形式,如上一节的示例所示。id 列构成主键。
只要您可以保证特定列中数据的唯一性,那么该列就可以作为主键。例如,如果您只想每天在一个特定表中输入一个条目,则可以使用日期作为该表的主键。
表通过外键相互关联。在 sales_order 示例中,客户 ID 和销售代表列将分别称为 customer 表和 employee 表的外键。为了术语的缘故,您可能想知道在这种情况下,sales_order 表被称为外键表或引用表,而 customer 表和 employee 表被称为主键表或被引用表。