关系型数据库规则与数据类型全解析
在关系型数据库的世界里,有一系列重要的规则和丰富的数据类型,这些规则确保了数据库的高效、稳定运行,而合理选择数据类型则是保证数据准确存储的关键。下面我们来详细了解这些规则和数据类型。
关系型数据库的重要规则
-
规则4:基于关系模型的动态在线目录
- 数据库描述在逻辑层面的表示方式与普通数据相同,授权用户可以使用相同的关系语言对其进行查询。
- 关系数据库必须是自描述的,即包含描述自身结构的系统表,或者数据库描述存储在用户可访问的表中。
-
SQL Server的新版本通过
INFORMATION_SCHEMA系统视图使这一规则更接近现实。INFORMATION_SCHEMA是一个模式,包含一组视图,可查看表、关系、约束甚至数据库代码的元数据。其他信息可在系统视图(SYS模式)中查看,这些新视图比旧的系统表更易读和使用。
-
规则5:综合数据子语言规则
-
关系系统可支持多种语言和终端使用模式,但至少有一种语言的语句可表示为字符串,且能支持以下功能:
- 数据定义
- 视图定义
- 数据操作(交互式和通过程序)
- 完整性约束
- 授权
- 事务边界(开始、提交和回滚)
- 该规则要求存在一种关系数据库语言(如SQL)来操作数据。Transact - SQL(T - SQL)为SQL Server实现了这些功能。SQL是非过程化语言,只需向关系服务器提问,它就会完成工作。
-
关系系统可支持多种语言和终端使用模式,但至少有一种语言的语句可表示为字符串,且能支持以下功能:
-
规则6:视图更新规则
- 理论上可更新的视图,系统也应能更新。视图是虚拟表,为不同用户提供数据库结构的不同视图。这是实践中最难实现的规则之一,目前没有商业产品能完全满足。
-
在SQL Server中,视图可更新的条件是语句中不更新多个表,也不更新派生或常量字段。SQL Server 2000可使用
INSTEAD OF触发器实现视图更新,但操作可能不那么直接,使用时需谨慎,尤其是视图包含GROUP BY子句和聚合函数时。
-
规则7:高级插入、更新和删除
-
处理基本关系或派生关系作为单个操作数的能力不仅适用于数据检索,也适用于数据的插入、更新和删除。该规则强调关系数据库的面向集合特性,要求在插入、删除和更新操作中把行视为集合,禁止仅支持逐行导航式修改数据库的实现。SQL语言通过
INSERT、UPDATE和DELETE语句实现这一规则。 - 需注意,即使CLR不允许访问数据存储的物理文件,但BCP可以绕过这一限制。使用可绕过典型SQL语法修改数据的低级工具时要格外小心,以免引入数据不一致问题。
-
处理基本关系或派生关系作为单个操作数的能力不仅适用于数据检索,也适用于数据的插入、更新和删除。该规则强调关系数据库的面向集合特性,要求在插入、删除和更新操作中把行视为集合,禁止仅支持逐行导航式修改数据库的实现。SQL语言通过
-
规则8:物理数据独立性
- 无论存储表示或访问方法如何变化,应用程序和终端活动在逻辑上不受影响。即使数据库内部的数据存储和访问方法改变,应用程序仍需使用相同语法正常工作。这意味着数据的物理存储方式应独立于逻辑访问方式,用户无需关心数据的存储和访问方式,只需了解所需数据的基本定义。
-
以下操作不应影响用户对数据的视图:
- 添加索引:索引决定数据存储方式,但用户通过SQL不会知道索引的使用。
- 修改存储引擎:微软会定期修改SQL Server的操作方式(尤其是重大版本升级),但SQL语句访问数据的方式应与以前版本相同,且性能可能更好。
- SQL Server通过分离关系引擎和存储引擎,并使用OLE DB传递数据,实现了这一规则。
-
规则9:逻辑数据独立性
- 当对基表进行理论上不影响数据完整性的更改时,应用程序和终端活动在逻辑上不受影响。与规则8一起,该规则使用户或应用程序不受数据库底层实现的影响,特定的访问或存储技术以及表结构的变化不应影响用户处理数据的能力。
- 例如,向表中添加列或拆分表(不增减列)时,调用数据库的应用程序应不受影响。可以创建视图来实现这一点,如:
CREATE VIEW baseTable
AS
SELECT baseTableId, column1, column2
FROM baseTableA
JOIN baseTableB
ON baseTableA.baseTableId = baseTableB.baseTableId
- 若在视图上实现`INSTEAD OF`触发器,可无缝管理视图。但处理标识列时需注意,即使数据不用也需输入。需注意,若系统中删除列或表,该规则可能无法实现,但仅添加列和数据时可以。建议始终通过名称访问RDBMS中的数据,而不是通过位置或使用`SELECT *`通配符。
-
规则10:完整性独立性
-
特定关系数据库的完整性约束必须能用关系数据子语言定义并存储在目录中,而不是在应用程序中。数据库必须支持以下两种完整性约束:
-
实体完整性:主键的任何组件都不允许为
NULL值。 -
引用完整性:关系数据库中每个非
NULL的外键值,必须存在同一域中的匹配主键值。
-
实体完整性:主键的任何组件都不允许为
- 该规则要求数据库语言支持完整性约束,以限制可输入数据库的数据和可进行的数据库修改。SQL Server 2005通过约束和触发器提供了实现这些约束的工具。
-
特定关系数据库的完整性约束必须能用关系数据子语言定义并存储在目录中,而不是在应用程序中。数据库必须支持以下两种完整性约束:
-
规则11:分布独立性
- 关系DBMS的数据操作子语言必须使应用程序和终端活动在数据物理集中或分布时逻辑上不受影响。这意味着数据库语言应能操作其他计算机系统上的数据,可将RDBMS中的数据拆分到多个物理系统,而用户无需察觉。SQL Server 2005支持SQL Server源和其他类型源之间的分布式事务,还支持联合数据库服务器无缝分担负载。
-
规则12:非颠覆规则
-
若关系系统有或支持低级(一次处理一条记录)语言,该低级语言不能用于颠覆或绕过高级(一次处理多条记录)关系语言表达的完整性规则或约束。大多数SQL Server 2005应用程序遵循此规则,但SQL Server 2005在以下两个方面违反了该规则:
- 批量复制:默认情况下,可使用批量复制例程直接向表中插入数据,绕过数据库服务器验证。
- 禁用约束和触发器:有语法可禁用约束和触发器,从而颠覆该规则。使用这两个功能时需谨慎,以免破坏数据完整性。
-
若关系系统有或支持低级(一次处理一条记录)语言,该低级语言不能用于颠覆或绕过高级(一次处理多条记录)关系语言表达的完整性规则或约束。大多数SQL Server 2005应用程序遵循此规则,但SQL Server 2005在以下两个方面违反了该规则:
数据库数据类型
选择合适的数据类型以匹配逻辑建模的域是一项重要任务。不同数据类型在实现和性能上可能有很大差异。以下是常见的数据类型及其适用场景:
| 数据类型分类 | 具体数据类型 | 描述 |
| — | — | — |
| 精确数值数据 | bit | 存储0、1或NULL,用于布尔类型列 |
| | tinyint | 存储0 - 255的非负整数,适用于值范围确定且较小的情况,如数据仓库中的代理键 |
| | smallint | 存储 - 32,768 - 32,767的整数,若能保证值在该范围内可使用,但不建议用于主键 |
| | int | 存储 - 2,147,483,648 - 2,147,483,647的整数,是常用的整数类型 |
| | bigint | 存储 - 9,223,372,036,854,775,808 - 9,223,372,036,854,775,807的整数,用于需要大整数的情况 |
| | decimal | 存储 - 10^38 + 1 - 10^38 - 1的值,可精确表示小数 |
| | money | 存储 - 922,337,203,685,477.5808 - 922,337,203,685,477.5807的值,用于货币数据 |
| | smallmoney | 存储 - 214,748.3648 - +214,748.3647的值,是
money
的较小范围版本 |
| 近似数值数据 | float (N) | 存储 - 1.79E + 308 - 1.79E + 308的值,提供大范围的近似数值 |
| | real | 存储 - 3.40E + 38 - 3.40E + 38的值,是
float(24)
的同义词 |
| 日期和时间 | smalldatetime | 存储1900年1月1日 - 2079年6月6日的日期 |
| | datetime | 存储1753年1月1日 - 9999年12月31日的日期 |
| 字符(或字符串)数据 | char | 固定长度字符数据,最长8000字符 |
| | varchar | 可变长度字符数据,最长8000字符 |
| | varchar(max) | 大可变长度字符数据,最大长度2^31 - 1字节(2GB) |
| | text | 大文本值,最大长度2^31 - 1字节(2GB),已过时,建议使用
varchar(max)
|
| | nchar, nvarchar, ntext | 分别是
char
、
varchar
和
text
的Unicode版本 |
| 二进制数据 | binary | 固定长度二进制数据,最长8000字节 |
| | varbinary | 可变长度二进制数据,最长8000字节 |
| | varbinary(max) | 大二进制数据,最大长度2^31 - 1字节(2GB) |
| | image | 大二进制数据,最大长度2^31 - 1字节(2GB),已过时,建议使用
varbinary(max)
|
| 其他数据类型 | timestamp (或rowversion) | 用于乐观锁定 |
| | uniqueidentifier | 存储全局唯一标识符(GUID)值 |
| | cursor | 用于在变量中存储游标引用 |
| | table | 用于保存对本地临时表的引用 |
| | XML | 用于存储和操作XML值 |
| | sql_variant | 可存储大多数数据类型 |
精确数值数据详解
精确数值数据在存储时没有误差,因为它们在小数点(或基数)前后有固定位数。常见的精确数值数据类型包括
bit
、
int
、
bigint
、
smallint
、
tinyint
、
decimal
和
money
。下面对其中部分整数类型进行详细介绍:
-
bit
-
定义域
:0、1或NULL。
-
存储
:表中每8个
bit
列实例需要1字节存储,因此8个
bit
列与1个
bit
列占用的表空间相同。
-
讨论
:
bit
值可作为类似布尔值使用,但它不是真正的布尔值,其值为0和1而不是
True
和
False
。更准确地说,它是一个“标志”,值为1表示标志已设置。许多程序员喜欢用字符值
'yes'
或
'no'
,但使用
bit
类型在编程中更方便。可对
bit
列建立索引,但单独索引通常没什么价值,最好与其他列一起索引。
-
tinyint
-
定义域
:0 - 255的非负整数。
-
存储
:1字节。
-
讨论
:
tinyint
是非常小的整数值,若处理的值始终在该范围内,它是理想选择。例如,可作为域表的主键,该表的值数量有限。在数据仓库中,它可使代理键更小。但要确保值不会超过256个,否则建议使用更大的数据类型。
-
smallint
-
定义域
: - 32,768 - 32,767的整数。
-
存储
:2字节。
-
讨论
:若能保证只需要该范围内的值,
smallint
是有用的类型。但不建议将其用于主键,使用统一的数据类型(如
int
)可使数据库代码更一致。有时
smallint
会被用作布尔值,这在早期Visual Basic中可能常见,但会浪费空间且容易让其他SQL Server程序员困惑。
通过了解这些关系型数据库规则和数据类型,我们能更好地设计和管理数据库,确保数据的准确性和系统的高效运行。在实际应用中,要根据具体需求合理选择规则和数据类型,以达到最佳效果。
关系型数据库规则与数据类型全解析
近似数值数据
近似数值数据用于存储数值的近似值,适用于科学应用以及数值范围变化较大的场景。与精确数值数据不同,近似数值数据类型在存储时可能不会精确存储你期望的值,但它们在特定场景下非常有用。
| 数据类型 | 描述 | 取值范围 |
|---|---|---|
| float (N) | 提供大范围的近似数值存储 | -1.79E + 308 至 1.79E + 308 |
| real | float(24) 的同义词 | -3.40E + 38 至 3.40E + 38 |
float
类型根据指定的参数
N
来确定精度,
N
的取值范围是 1 到 53。
real
类型则相当于
float(24)
,它在存储和处理浮点数时使用较少的字节,因此在对精度要求不是特别高的情况下可以节省存储空间。
在使用近似数值数据类型时,需要注意由于存储近似值可能带来的误差。在进行数学计算时,这些误差可能会累积,从而影响最终结果的准确性。因此,在对精度要求较高的场景,如金融计算,应避免使用近似数值数据类型,而选择精确数值数据类型。
日期和时间数据类型
日期和时间数据类型用于存储日期值,包括一天中的时间。以下是常见的日期和时间数据类型及其特点:
| 数据类型 | 描述 | 取值范围 |
|---|---|---|
| smalldatetime | 存储日期和时间,精度较低 | 1900 年 1 月 1 日至 2079 年 6 月 6 日 |
| datetime | 存储日期和时间,精度较高 | 1753 年 1 月 1 日至 9999 年 12 月 31 日 |
smalldatetime
类型占用 4 个字节的存储空间,其精度为分钟,即存储的时间会被舍入到最接近的分钟。
datetime
类型占用 8 个字节的存储空间,精度更高,可精确到 3.33 毫秒。
在选择日期和时间数据类型时,应根据实际需求来决定。如果应用程序对日期和时间的精度要求不高,且数据范围在
smalldatetime
的范围内,那么使用
smalldatetime
可以节省存储空间。如果需要更高的精度和更广泛的日期范围,则应选择
datetime
类型。
字符(或字符串)数据类型
字符(或字符串)数据类型用于存储文本数据,如名称、注释等。以下是常见的字符数据类型及其特点:
| 数据类型 | 描述 | 最大长度 |
|---|---|---|
| char | 固定长度字符数据 | 8000 字符 |
| varchar | 可变长度字符数据 | 8000 字符 |
| varchar(max) | 大可变长度字符数据 | 2^31 - 1 字节(2GB) |
| text | 大文本值 | 2^31 - 1 字节(2GB),已过时,建议使用 varchar(max) |
| nchar, nvarchar, ntext | Unicode 版本的 char、varchar 和 text | 相应的长度限制 |
char
类型存储固定长度的字符数据,如果存储的数据长度小于定义的长度,会用空格填充。
varchar
类型存储可变长度的字符数据,只占用实际存储数据所需的空间。
varchar(max)
用于存储大的可变长度字符数据,适用于需要存储大量文本的场景。
text
类型曾经用于存储大文本值,但现在已被
varchar(max)
取代,因为
varchar(max)
提供了更好的性能和兼容性。
nchar
、
nvarchar
和
ntext
是 Unicode 版本的字符数据类型,用于存储包含多种语言字符的文本。
在选择字符数据类型时,应根据存储数据的长度和是否需要支持 Unicode 来决定。如果数据长度固定,且不需要支持多种语言,可选择
char
类型;如果数据长度可变,可选择
varchar
类型;如果需要存储大量文本,应选择
varchar(max)
类型。
二进制数据类型
二进制数据类型用于存储以字节形式表示的数据,而不是人类可读的值,如文件或图像。以下是常见的二进制数据类型及其特点:
| 数据类型 | 描述 | 最大长度 |
|---|---|---|
| binary | 固定长度二进制数据 | 8000 字节 |
| varbinary | 可变长度二进制数据 | 8000 字节 |
| varbinary(max) | 大二进制数据 | 2^31 - 1 字节(2GB) |
| image | 大二进制数据 | 2^31 - 1 字节(2GB),已过时,建议使用 varbinary(max) |
binary
类型存储固定长度的二进制数据,如果存储的数据长度小于定义的长度,会用零填充。
varbinary
类型存储可变长度的二进制数据,只占用实际存储数据所需的空间。
varbinary(max)
用于存储大的二进制数据,适用于需要存储大型文件或图像的场景。
image
类型曾经用于存储大二进制数据,但现在已被
varbinary(max)
取代,因为
varbinary(max)
提供了更好的性能和兼容性。
在选择二进制数据类型时,应根据存储数据的长度和是否需要可变长度来决定。如果数据长度固定,可选择
binary
类型;如果数据长度可变,可选择
varbinary
类型;如果需要存储大量二进制数据,应选择
varbinary(max)
类型。
其他数据类型
除了上述常见的数据类型外,还有一些特殊的数据类型,它们在特定的场景下有独特的用途。
-
timestamp (或 rowversion)
:用于乐观锁定,它是一个自动递增的二进制数,每次表中的行被更新时,
timestamp列的值会自动更新。通过比较timestamp值,可以判断数据是否被其他事务修改过。 - uniqueidentifier :存储全局唯一标识符(GUID)值,GUID 是一个 128 位的数字,在全球范围内是唯一的。常用于分布式系统中,确保数据的唯一性。
- cursor :用于在变量中存储游标引用,游标是一种用于遍历结果集的数据库对象。通过使用游标,可以逐行处理查询结果。
- table :用于保存对本地临时表的引用,临时表是在会话期间临时创建和使用的表,用于存储中间结果。
- XML :用于存储和操作 XML 值,支持对 XML 数据进行查询、修改和验证。
-
sql_variant
:可存储大多数数据类型,它允许在一个列中存储不同类型的数据。但使用
sql_variant会增加数据处理的复杂性,应谨慎使用。
数据类型选择的重要性
选择合适的数据类型是确保数据库中数据准确存储的关键步骤。不同的数据类型在存储效率、性能和功能上有很大差异。以下是选择数据类型时需要考虑的几个因素:
1.
数据范围
:确保选择的数据类型能够容纳所需存储的数据范围。例如,如果存储的整数范围在 0 到 255 之间,选择
tinyint
类型比
int
类型更节省空间。
2.
精度要求
:对于数值数据,要根据精度要求选择精确数值数据类型或近似数值数据类型。在金融计算中,应选择精确数值数据类型以避免误差。
3.
存储效率
:考虑数据类型的存储需求,选择占用空间最小的数据类型。例如,对于固定长度的数据,使用
char
类型可能比
varchar
类型更节省空间。
4.
兼容性
:确保选择的数据类型与应用程序和数据库系统兼容。某些数据类型可能在特定的数据库系统中不支持,或者在不同的版本中有不同的行为。
5.
功能需求
:根据应用程序的功能需求选择合适的数据类型。例如,如果需要存储和操作 XML 数据,选择
XML
类型;如果需要实现乐观锁定,选择
timestamp
类型。
以下是一个简单的流程图,展示了选择数据类型的基本步骤:
graph TD;
A[确定数据类型分类] --> B{数据是否为数值?};
B -- 是 --> C{是否需要精确存储?};
C -- 是 --> D[选择精确数值数据类型];
C -- 否 --> E[选择近似数值数据类型];
B -- 否 --> F{数据是否为日期和时间?};
F -- 是 --> G[选择日期和时间数据类型];
F -- 否 --> H{数据是否为字符或字符串?};
H -- 是 --> I{数据长度是否固定?};
I -- 是 --> J[选择 char 或 nchar 类型];
I -- 否 --> K[选择 varchar 或 nvarchar 类型];
H -- 否 --> L{数据是否为二进制?};
L -- 是 --> M{数据长度是否固定?};
M -- 是 --> N[选择 binary 类型];
M -- 否 --> O[选择 varbinary 类型];
L -- 否 --> P[选择其他特殊数据类型];
通过遵循这些原则,我们可以选择最合适的数据类型,提高数据库的性能和数据质量。在实际应用中,还需要根据具体情况进行调整和优化。
总之,关系型数据库的规则和数据类型是数据库设计和管理的基础。深入理解这些规则和数据类型,能够帮助我们构建高效、稳定和可靠的数据库系统。在实际操作中,要根据具体需求合理运用这些知识,不断优化数据库的性能和数据质量。
超级会员免费看
2346

被折叠的 条评论
为什么被折叠?



