SQL Server-数据库架构和对象、定义数据完整性(二)

本文涉及的产品
云数据库 RDS SQL Server,独享型 2核4GB
简介: 前言 本节我们继续SQL之旅,本节我们如题来讲讲一些基本知识以及需要注意的地方,若有不妥之处,还望指出,简短的内容,深入的理解,Always to review the basics。 数据库架构和对象 数据库包含架构,而架构又包含对象,架构可以看做是表、视图、存储过程等对象的容器。

前言

本节我们继续SQL之旅,本节我们如题来讲讲一些基本知识以及需要注意的地方,若有不妥之处,还望指出,简短的内容,深入的理解,Always to review the basics。

数据库架构和对象

数据库包含架构,而架构又包含对象,架构可以看做是表、视图、存储过程等对象的容器。架构是一个命名空间,它被用做对象名称的前缀,比如在Cnblogs的架构中有一个名称为Blogs的表,此时我们用架构式限定式名称(即两部分式对象名称)所以Blogs表示为Cnblogs.Blogs。如果我们引用对象时省略了架构名称,SQL Server将会检查对象是否存在用户的默认架构中,如果不是则检查是否存在dbo架构中,当我们创建数据库时,在用户没有显式地指定一个其他架构时,数据库会自动dbo架构作为我们默认的架构。微软也建议在代码中引用对象时始终用【两部分式】对象名称,基于此我们推荐的建议时在引用对象时建议:在代码中始终使用架构限定式的对象名称即两部分式名称。

定义数据完整性

关系模型最大好处则是我们能够自定义数据完整性,同时数据完整性是关系模型不可或缺的一部分,什么是数据完整性,说的通透一点则是对数据进行声明式约束,在SQL Server中声明式约束包括:主键约束、唯一键约束、外键约束、检查约束、默认约束。下面我们一一来介绍这几个约束。

主键约束

下面首先来创建一个表:

CREATE TABLE Blogs
(
 BlogId INT NOT NULL,
 BlogName VARCHAR(max) NOT NULL
);

主键约束用来强制行的唯一性,上述我们无法表示行的唯一性,现在我们添加约束来强制行的唯一性,用PRIMARY KEY约束如下。

ALTER TABLE dbo.Blogs
ADD CONSTRAINT pk_constraint_blogId PRIMARY KEY(BlogId)

在键文件夹中则生成对列BlogId的约束即升级为主键,如下:

当对主键插入重复数据时会提示插入重复键失败,违反约束。为了强制逻辑主键约束的唯一性,SQL Server会在后台创建一个唯一索引,唯一索引是SQL Server为了强制唯一性而使用的一种物理机制,索引(不一定是唯一索引)是为了加速查询,避免不必要的全表扫描。

唯一约束 

唯一约束强制行的唯一性,允许我们在自己的数据库中实现关系模型的备用键概念。它与主键不同,可以在同一个表中定义多个唯一约束同时允许多个NULL标记(类似NULL标记彼此不同),但是SQL Server拒绝重复NULL标记(类似两个NULL标记彼此相等)通过UNIQUE来约束。如下所示对BlogName进行唯一约束。

ALTER TABLE dbo.Blogs
ADD CONSTRAINT uq_constraint_blogname UNIQUE(BlogName)

此时添加唯一约束结果如下

一个个尝试发现居然对字符串和文本类型无法添加唯一约束,涨知识了,不知道为何不能添加唯一约束(学到后面才发现索引字节最大为900,所以这里我们取的max会出错,而不是针对于类型)。

通过上述对主键约束和唯一约束的讲解,我们就搞清楚主键约束和唯一约束了呢?博主看的是SQL Server2012基础教程,教程就讲到这里结束,至此我是还没弄清楚,主键约束和唯一约束到底应该怎样用以及主键约束和唯一约束有什么区别?

(1)对键添加主键约束,那么能不能在此基础上添加唯一约束呢?

我们在上述已经添加BlogId为主键约束的基础上来添加唯一约束,如下

ALTER TABLE dbo.Blogs
ADD CONSTRAINT uq_constraint_blogId UNIQUE(BlogId)

通过上述我们知道对同一列既可以添加主键约束也可以添加唯一约束

(2)上述基础教程中也讲到唯一性约束的列可以允许多个NULL标记,真的是这样?我们看看另外一种情况

我们创建如下表

create table test (
Id INT NOT NULL,
NAME VARCHAR(max) NOT NULL
)

接下来对Id约束为唯一约束。

ALTER TABLE test
ADD CONSTRAINT UNQ UNIQUE(Id)

此时我们对Id添加一个NULL试试看,结果可以插入还是不可以呢?

INSERT INTO TEST VALUES(NULL,'B')

不是唯一约束的列可以为NULL么,难道教程出错了或者sb翻译出错了么,这事我们应该看看定义表时列Id是不能为NULL的,所以到这里我们的疑问算是结束了,唯一约束的列是可以为NULL的。

(3)主键约束和唯一约束的区别?

主键约束:通过对列强制唯一性,此时主键在列上创建一个聚集索引且主键不能为空。

唯一约束:通过对列强制唯一性,此时在列上创建的唯一键为非聚集索引,唯一约束仅仅允许一个NULL值。

二者最大区别在于:主键约束强调的是行的唯一性来标识行,不允许重复,而唯一约束强调的是列的唯一性不允许重复。 

(4)主键约束和唯一约束都可以建立唯一索引

【1】唯一索引通过主键约束和唯一约束都可以创建。

  如果表中不存在聚集索引的话并且我们没有明确指定一个非聚集索引的话,通过主键约束将自动创建一个唯一聚集索引。

  当创建唯一约束时,默认情况下一个非聚集索引会被创建来强制一个唯一约束,如果在表中聚集索引不存在的话,我们可以指定一个聚集索引。

【2】唯一约束和唯一索引区别

我们接下来创建一个表,如下:

CREATE TABLE test
(
 Id INT NOT NULL PRIMARY KEY,
 Code INT
)

首先我只对Code创建唯一索引

CREATE UNIQUE INDEX uq_ix ON dbo.test(Code)

此时我们再在Code列上添加唯一约束:

ALTER TABLE StudyTest.dbo.test
ADD CONSTRAINT uq_nonclster_ix UNIQUE(Code)

此时我们在索引文件夹下可以看到所创建的唯一索引和唯一约束所创建的唯一非聚集索引

看起来二者都是唯一非聚集索引,只是图标不一样而已,二者应该是一样的吧

(5)唯一索引和唯一约束的区别在哪里?唯一约束能替代唯一索引吗?

【1】返回错误码不同

当我们插入数据时,唯一索引返回错误代码为2601

唯一约束返回的错误代码为2627

【2】唯一约束不能筛选,而唯一索引能进行筛选,如下

CREATE UNIQUE NONCLUSTERED INDEX uq_code_filter
ON test(Code) WHERE Code is not null;

总结:上述只是表示二者在使用上的不同,对于唯一约束和唯一索引并没有什么很大的差异,同时对于唯一约束和唯一索引在查询性能上也没有很大的不同,对于唯一约束我们一直强调的是数据完整性,对列进行唯一约束保证其值不能重复,这同时对于建立索引查询时性能会有显著的提升。

外键约束 

外键约束也用来强制数据完整性,外键的目的是限制在外键列中允许的值主要存在于那些被引用列中。下面我们来演示外键约束,我们创建如下雇员表和部门表:

USE SQLStudy;

IF OBJECT_ID('dbo.Department','U') IS NOT NULL
    DROP TABLE dbo.Department

CREATE TABLE [dbo].[Department] (
    [DepartmentID]      INT NOT NULL IDENTITY,
    [DepartmentName]    VARCHAR(50)
)
GO

CREATE TABLE [dbo].[Employee] (
    [EmployeeID]     INT NOT NULL IDENTITY,
    [FirstName]      VARCHAR(50),
    [LastName]       VARCHAR(50),
    [DepartmentID]   INT
)

由上我们知道雇员表是依赖于部门表,一个雇员到底是在哪个部门呢?所以此时雇员表中的部门Id应该是部门表中部门Id的外键,接下来我们进行外键约束,如下:

ALTER TABLE [dbo].[Employee]
ADD CONSTRAINT [FK_Employee_Department]
FOREIGN KEY ( [DepartmentID] ) REFERENCES [dbo].[Department] ( [DepartmentID] )

此时执行完你会发现如下错误:

现在我们知道外键可不是随便就能建立的,为什么会出现我们引用部门表并将其雇员表中部门Id作为外键约束的错误呢?通过上述错误我们知道在引用表即部门表中没有其匹配的主键或候选键,这是指的什么,它的意思是引用表中的外键必须是被引用表中的完整主键,而不是作为被引用表的一部分,说的更加明确一点则是被引用表即部门表中的部门Id应该是主键,在这里我们未对部门表中部门Id进行主键约束而导致如上错误。我们添加主键约束即可

ALTER TABLE [dbo].[Department]
ADD CONSTRAINT [PK_Department] PRIMARY KEY ( [DepartmentID] )
GO

此时外键约束才算建立完成。到这里其实还存在一种可能,当我们需要引用的表中已经存在一个主键,而不是由外键引用的列,此时部门表中的Id不是作为主键,而我们雇员表中的部门Id又需要将部门Id作为外键约束,这个时候我们只需要在部门表中部门Id上创建唯一或者唯一约束即可。

CREATE UNIQUE INDEX [IX_DepartmentID]
ON [dbo].[Department] ( [DepartmentID] )
GO

ALTER TABLE [dbo].[Employee]
ADD CONSTRAINT [FK_Employee_Department]
FOREIGN KEY ( [DepartmentID] ) REFERENCES [dbo].[Department] ( [DepartmentID] )
GO

或者唯一约束

CREATE UNIQUE INDEX [IX_DepartmentID]
ON [dbo].[Department] ( [DepartmentID] )
GO

ALTER TABLE [dbo].[Employee]
ADD CONSTRAINT [FK_Employee_Department]
FOREIGN KEY ( [DepartmentID] ) REFERENCES [dbo].[Department] ( [DepartmentID] )
GO

Check约束 

Check约束定义一个谓词,要插入到表中的行或者被修改的行必须满足此要求。

比如在雇员表中再添加一个薪水字段,很显然薪水必须为正值,此时我们则可以像如下进行Check约束

ALTER TABLE dbo.Employees
 ADD CONSTRAINT CHK_Employees_salary
 CHECK(salary > 0.00)

如果试图插入非正值,将会被数据库所拒绝。我们需要注意的是Check约束只是对于结果为false才会拒绝,如果结果为True或者UNKNOWN是会被接受,即当结果为NULL时也会插入或者修改成功。

默认约束

默认约束无非就是当建立表时给定一个默认值,常见的是在表中存在添加数据的日期这一列,此时我们完全给定一个默认值,取当前的日期。默认约束用DEFAULT关键字表示。例如如下:

ALTER TABLE dbo.Employees
 ADD CONSTRAINT DFT_Employees_updateTime
DEFAULT(GETDATE()) FOR UpdateTime

总结

本节我们详细讲解了主键约束和唯一约束这一块,其余相对比较简单,算是略过,到此结束,下节再会。 

相关实践学习
使用SQL语句管理索引
本次实验主要介绍如何在RDS-SQLServer数据库中,使用SQL语句管理索引。
SQL Server on Linux入门教程
SQL Server数据库一直只提供Windows下的版本。2016年微软宣布推出可运行在Linux系统下的SQL Server数据库,该版本目前还是早期预览版本。本课程主要介绍SQLServer On Linux的基本知识。 相关的阿里云产品:云数据库RDS SQL Server版 RDS SQL Server不仅拥有高可用架构和任意时间点的数据恢复功能,强力支撑各种企业应用,同时也包含了微软的License费用,减少额外支出。 了解产品详情: https://www.aliyun.com/product/rds/sqlserver
目录
相关文章
|
8月前
|
数据库
国产架构完整性、可代替性和性能需要提高呀
数据库、设计软件是我们的短板,企业建构需要核心技术,国产生态需要努力
|
SQL 数据库
数据库原理与应用(SQL Server)笔记 第六章 数据完整性
数据库原理与应用(SQL Server)笔记 第六章 数据完整性
数据库原理与应用(SQL Server)笔记 第六章 数据完整性
|
SQL 关系型数据库 PostgreSQL
PostgreSQL 10.1 手册_部分 II. SQL 语言_第 13 章 并发控制_13.4. 应用级别的数据完整性检查
13.4. 应用级别的数据完整性检查 13.4.1. 用可序列化事务来强制一致性 13.4.2. 使用显式锁定强制一致性 对于使用读已提交事务的数据完整性强制业务规则非常困难,因为对每一个语句数据视图都在变化,并且如果一个写冲突发生即使一个单一语句也不能把它自己限制到该语句的快照。
1157 0
|
SQL 存储 数据库
你真的会玩SQL吗?三范式、数据完整性
你真的会玩SQL吗?系列目录 你真的会玩SQL吗?之逻辑查询处理阶段 你真的会玩SQL吗?和平大使 内连接、外连接 你真的会玩SQL吗?三范式、数据完整性 你真的会玩SQL吗?查询指定节点及其所有父节点的方法 你真的会玩SQL吗?让人晕头转向的三值逻辑 你真的会玩SQL吗?EXIS...
1133 0
|
6天前
|
API 数据库 开发者
构建高效可靠的微服务架构:后端开发的新范式
【4月更文挑战第8天】 随着现代软件开发的复杂性日益增加,传统的单体应用架构面临着可扩展性、维护性和敏捷性的挑战。为了解决这些问题,微服务架构应运而生,并迅速成为后端开发领域的一股清流。本文将深入探讨微服务架构的设计原则、实施策略及其带来的优势与挑战,为后端开发者提供一种全新视角,以实现更加灵活、高效和稳定的系统构建。
13 0
|
20天前
|
负载均衡 测试技术 持续交付
高效后端开发实践:构建可扩展的微服务架构
在当今快速发展的互联网时代,后端开发扮演着至关重要的角色。本文将重点探讨如何构建可扩展的微服务架构,以及在后端开发中提高效率的一些实践方法。通过合理的架构设计和技术选型,我们可以更好地应对日益复杂的业务需求,实现高效可靠的后端系统。
|
20天前
|
监控 持续交付 API
构建高效可扩展的微服务架构
在当今快速迭代和竞争激烈的软件市场中,构建一个高效、可扩展且易于维护的后端系统变得尤为重要。微服务架构作为一种流行的分布式系统设计方式,允许开发者将应用程序划分为一系列小型、自治的服务,每个服务负责执行特定的业务功能。本文将探讨如何利用现代技术栈搭建一个符合这些要求的微服务架构,并讨论其潜在的挑战与解决方案。我们将涵盖服务划分策略、容器化、服务发现、API网关、持续集成/持续部署(CI/CD)以及监控和日志管理等关键主题,以帮助读者构建出既可靠又灵活的后端系统。
|
4天前
|
Kubernetes 安全 Java
构建高效微服务架构:从理论到实践
【4月更文挑战第9天】 在当今快速迭代与竞争激烈的软件市场中,微服务架构以其灵活性、可扩展性及容错性,成为众多企业转型的首选。本文将深入探讨如何从零开始构建一个高效的微服务系统,覆盖从概念理解、设计原则、技术选型到部署维护的各个阶段。通过实际案例分析与最佳实践分享,旨在为后端工程师提供一套全面的微服务构建指南,帮助读者在面对复杂系统设计时能够做出明智的决策,并提升系统的可靠性与维护效率。