SSAS全半角空格导致的AS处理错误[转]

全半角空格导致的Analysis
瑟维斯(Service)s处理错误

 

问题讲述

某维度表的字符串列同时现身两条记下,A记录以半角空格(英文空格)截止,B记录以全角空格(中文空格)停止,除此之外其他部分均一致。Analysis 瑟维斯(Service)(Service)处理的时候抛出“Key not
found”的丰富,导致处理败北。

为了尝试,大家创制两张卓殊不难的表:

— 员工交易事实表
Create Table [FactTransaction](
    [TransactionKey] [int]
not null,
    [EmployeeKey] [int]
not null
)

— 员工维度表
Create Table [DimEmployee](
    [EmployeeKey] [int]not null,
    [EmployeeName] [nvarchar](32) not null
)

随着大家初始往维度表中添加几条记下。

insert into
DimEmployee(EmployeeKey,EmployeeName)values(1,’员工 ‘)    — 半角空格

insert into
DimEmployee(EmployeeKey,EmployeeName)values(2,’员工’)    — 全角空格

然后大家在BIDS中新建一个Analysis
Service(Service)的Olap工程,将DimEmployee表作为维度表,并新建目的TotalTransactions ::= Count(TransactionKey)表示每个员工的交易数据:

图片 1

有着安装有限支撑默许,OK,现在始于拍卖Employee维度。那个时候Analysis
Service会提醒您:

Processing Dimension Attribute ‘EmployeeKey’ failed. 1 rows have been
read.

OLAP 存储引擎中留存不当: 处理时找不到以下属性键:
表:“dbo_DimEmployee”,列:“EmployeeName”,值:“员工 ”。该属性为“EmployeeName”。

以此破绽百出翻译成英文就是Key
not found.

图片 2

 

题目分析

发出了哪些事

在大家地方设计的OLAP方案中,一个EmployeeKey有且只可以有一个EmployeeName,EmployeeKey属性的拍卖器重于
EmployeeName属性。那几个依靠关系在维度设计视图中的Attribute Relationship属性关系面板中指定。

图片 3

Analysis Service会在拍卖完EmployeeName属性之后再处理EmployeeKey属性。在处理每一个EmployeeKey属性成员的时候,都会去找对应的EmployeeName属性成员。

地点的处理错误实际上就是,在拍卖EmployeeKey的某个成员的时候,它对应的EmployeeName属性成员应当是“员工
”(全角空格)的——从表记录

图片 4

中可以观看那几个相应关系——可是在性能存储文件(Analysis
Service(Service)自己的积存结构)中却找不到该属性成员。

此间没有报告我们到底是哪些EmployeeKey属性成员处理的时候出了问题,可是由于大家的数据仓库相当简单,大家得以一贯看出来,EmployeeName=“员工 ”(全角空格)的EmployeeKey为2。

那为啥全角空格的EmployeeName属性成员没有导入到Analysis
瑟维斯(Service)(Service)的特性存储文件中吗?大家来展开看一下拍卖EmployeeName时Analysis Service(Service)向Sql Server发起的询问。

SELECT DISTINCT
    [dbo_DimEmployee].[EmployeeName] AS
[dbo_DimEmployeeEmployeeName0_0]
FROM [dbo].[DimEmployee]
AS [dbo_DimEmployee]

将这行代码放到Sql
Server中去实施一下,大家发现sql
Server只给大家回到了半角空格的记录,全角空格的记录被过滤掉了。那也就表达了,为何全角空格的属性成员没能进入Analysis
service中。进而导致重视这些成员的性能处理失利。

 

Sql Server Collation

此间须求提一下Sql
Server的排序规则(Collation)。排序规则会潜移默化多少里面的可比以及种种。具体细节参见MSDN:SQL Server Collation
Fundamentals
。那里我只提一个和那几个题目有关的,并且简单被人忘记的设置,那就是Width-Sensitive(宽度敏感)设置。大家了然,有些字符既有单字节格局(半角字符),又有双字节方式(全角字符),例如1234和1234。如若设置为宽度不灵动,那么Sql Server就会将这么些字符的单双字节方式同等看待。那样您在select distinct的时候,单双字节字符方式的字符串就只可以一个。那也就是干吗下边大家select distinct的时候只出来半角空格的原因。

Sql Server和Analysis 瑟维斯(Service)(Service)排序规则平等为何还会出错?

Analysis 瑟维斯(Service)(Service)自己也有一个排序规则的安装。大家检查了一下这两者的设置,发现是一模一样的。那么Analysis 瑟维斯(Service)在查找“员工 ”(全角空格)属性成员的时候,即使找不到那几个成员,可是相应至少可以匹配到“员工
”(半角空格)的分子才是呀。关键是,半角空格的积极分子也根本不存在。默认情状下,所有字符串类型的维度属性在拍卖时都会被right
trim,也就是最后的空格均会被剔除。

图片 5

也就是说,最后进入Analysis
Service(Service)的性质成员是“员工”,不带任何空格,而这么些成员和全角空格(全角空格不可以被right
trimming掉)的明确无法合作上。

 

分流一下

若果Analysis设置了对每个属性成员左右都trim的话,那么一旦数据仓库出现“
员工”(左侧带全角空格)和“
员工”(左侧带半角空格)的数据的时候,处理失利。

如果数据仓库中同时出现“员工”,“员工
”(全角空格),那么也会招致出错,那是因为select distinct会将右边空格去除之后再相比较数据是还是不是等于。

一经将维度属性的Trimming设置为None的话,那么当数据仓库中冒出“员工”,“员工  
”(若干个半角空格结尾)那样数据的时候,也会造成处理败北,那也是怎么Analysis Service默许设置为right
trimming的其中一个缘故(和Sql Server的一坐一起保持一致)。

假定数量中并且出现“员工
”(半角空格),“员工
”(全角空格),“员工
”(先全角空格,再tab空格)那样的多少整合,处理常规。

 

总结

并发如此的动静,不佳通过改动Sql Server或者Analysis Service(Service)的排序规则来创新那些题目。只好在ETL的阶段对此类数据举行预处理,将最后的全角空格给删除掉。即使工作系统对全半角的分别不感兴趣,也足以一向动用正则表明式将装有全角字符替换成相应的半角字符。

源于为知笔记(Wiz)

相关文章