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

全半角空格导致的Analysis
Services处理错误

 

题目讲述

某某维度表的字符串列同时起些微漫漫记下,A记录为半角空格(英文空格)结束,B记录为全角空格(中文空格)结束,除此之外别组成部分都一致。Analysis 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的Olap工程,将DimEmployee表作为维度表,并新建指标TotalTransactions ::= Count(TransactionKey)表示每个员工的市数额:

不无安装保障默认,OK,现在启幕拍卖Employee维度。这个时段Analysis
Service会提示您:

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

OLAP 存储引擎中有似是而非: 处理常寻找不顶以下属性键:
表:“dbo_DimEmployee”,列:“EmployeeName”,值:“员工 ”。该属性为“EmployeeName”。

其一荒唐翻译成英文就是Key
not found.

 

问题浅析

发生了哟事

每当咱们地方设计的OLAP方案受到,一个EmployeeKey有且不得不发出一个EmployeeName,EmployeeKey属性的拍卖依赖让
EmployeeName属性。这个仗关系在维度设计视图中之Attribute Relationship属性关系面板中指定。

Analysis Service会在拍卖完EmployeeName属性之后还处理EmployeeKey属性。在处理各一个EmployeeKey属性成员的时节,都见面失掉追寻对应的EmployeeName属性成员。

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

被得以望这个相应关系——但是于性质存储文件(Analysis
Service自己的积存结构)中却招来不至该属性成员。

此间没有报我们究竟是哪位EmployeeKey属性成员处理的时节发了问题,但是由我们的数据仓库非常简单,我们可直接扣下,EmployeeName=“员工 ”(全角空格)的EmployeeKey为2。

那么为什么全角空格的EmployeeName属性成员没有导入到Analysis
Service的特性存储文件中也?我们来开展看一下处理EmployeeName时Analysis 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排序规则平等为什么还见面出错?

Analysis Service自己为时有发生一个排序规则之装。我们检查了一晃当下二者的装置,发现凡是一样的。那么Analysis Service在检索“员工 ”(全角空格)属性成员的时光,即使找不交此成员,但是该至少可以配合到“员工
”(半角空格)的积极分子才是呀。关键是,半角空格的分子也向来未有。默认情况下,所有字符串类型的维度属性在处理常犹见面于right
trim,也即是最后的空格均会被删。

也就是说,最终上Analysis
Service的性成员是“员工”,不牵动任何空格,而这成员及全角空格(全角空格无法给right
trimming掉)的引人注目无法配合上。

 

散一下

只要Analysis设置了针对性每个属性成员左右还trim的话,那么一旦数据仓库出现“
员工”(左边带全角空格)和“
员工”(左边带半角空格)的数目的时,处理失败。

要是数据仓库中又出现“员工”,“员工
”(全角空格),那么为会见招出错,这是坐select distinct会将右手空格去除之后再度于数据是否等。

苟将维度属性之Trimming设置为None的语,那么当数据仓库中出现“员工”,“员工  
”(若干个半交锋空格结尾)这样数据的时光,也会招致处理失败,这也是为何Analysis Service默认设置为right
trimming的里一个缘由(和Sql Server的所作所为保持一致)。

假设数额中而起“员工
”(半角空格),“员工
”(全角空格),“员工
”(先全角空格,再tab空格)这样的数量整合,处理常规。

 

总结

起这么的情事,不好通过改Sql Server或者Analysis Service的排序规则来修正这个题目。只能在ETL的级差对该类数据开展预处理,将最终的全角空格给抹掉。如果工作体系对全半竞的别不感兴趣,也可一直动用正则表达式将有全角字符替换成相应的半角字符。

出自为解笔记(Wiz)

相关文章