2009-06-10 32 views
6

Tôi muốn hỏi ý kiến ​​của bạn về cách thực hành tốt nhất là xử lý giá trị dữ liệu rỗng hoặc rỗng khi nó liên quan đến kho dữ liệu và SSIS/SSAS.Xử lý null trong Datawarehouse

Tôi có một số bảng thực tế và thứ nguyên chứa giá trị null trong các hàng khác nhau.

chi tiết cụ thể:

1) cách tốt nhất để xử lý rỗng ngày/lần giá trị là bao nhiêu? Tôi có nên tạo hàng 'mặc định' trong các tham số thời gian hoặc ngày của tôi và SSIS điểm đến hàng mặc định khi có tìm thấy null không?

2) Cách tốt nhất để xử lý giá trị rỗng/rỗng bên trong dữ liệu thứ nguyên là gì. Ví dụ: Tôi có một số hàng trong thứ nguyên 'Tài khoản' có giá trị trống (không phải NULL) trong cột Tên tài khoản. Tôi có nên chuyển đổi các giá trị rỗng hoặc giá trị rỗng này trong cột thành giá trị mặc định cụ thể không?

3) Tương tự như điểm 1 ở trên - Tôi nên làm gì nếu tôi kết thúc với hàng Facttable không có bản ghi trong một trong các cột thứ nguyên? Tôi có cần bản ghi thứ nguyên mặc định cho mỗi thứ nguyên trong trường hợp điều này xảy ra không?

4) Bất kỳ đề xuất hoặc mẹo nào về cách xử lý các hoạt động này trong dịch vụ tích hợp máy chủ Sql (SSIS)? Cấu hình luồng dữ liệu tốt nhất hoặc các đối tượng chuyển đổi tốt nhất để sử dụng sẽ hữu ích.

Cảm ơn :-)

Trả lời

4

Như câu trả lời trước đó, có thể có nhiều ý nghĩa khác nhau gắn liền với giá trị Null cho thứ nguyên, không xác định, không áp dụng, không xác định, v.v. Nếu hữu ích để có thể phân biệt chúng trong ứng dụng của bạn thêm " các mục tham số giả có thể hữu ích.

Trong mọi trường hợp, tôi sẽ tránh có khóa ngoài hoặc trường tham số thực tế, thậm chí có một giá trị thứ nguyên 'không xác định' sẽ giúp người dùng xác định các truy vấn bao gồm nhóm bắt tất cả nơi chất lượng dữ liệu không phải là 100 % (và nó không bao giờ là).

Một mẹo rất đơn giản mà tôi đã sử dụng cho điều này và chưa cắn tôi là xác định kích thước của tôi thay thế khóa bằng cách sử dụng int IDENTITY (1,1) trong T-sql (bắt đầu từ 1 và tăng 1 mỗi hàng). Khóa giả ("Không khả dụng", "Chưa được gán", "Không áp dụng") được định nghĩa là int âm và được điền bởi một thủ tục được lưu trữ chạy ở đầu quá trình ETL.

Ví dụ một bảng được tạo ra như


    CREATE TABLE [dbo].[Location] 
    (
     [LocationSK] [int] IDENTITY(1,1) NOT NULL, 
     [Name] [varchar](50) NOT NULL, 
     [Abbreviation] [varchar](4) NOT NULL, 
     [LocationBK] [int] NOT NULL, 
     [EffectiveFromDate] [datetime] NOT NULL, 
     [EffectiveToDate] [datetime] NULL, 
     [Type1Checksum] [int] NOT NULL, 
     [Type2Checksum] [int] NOT NULL, 
    ) ON [PRIMARY] 

Và một stored procedure Populating bảng với


Insert Into dbo.Location (LocationSK, Name, Abbreviation, LocationBK, 
         EffectiveFromDate, Type1Checksum, Type2Checksum) 
      Values (-1, 'Unknown location', 'Unk', -1, '1900-01-01', 0,0) 

Tôi đã thực hiện nó một quy tắc để có ít nhất một hàng giả như mỗi chiều là được sử dụng trong trường hợp tra cứu thứ nguyên không thành công và để tạo báo cáo ngoại lệ để theo dõi số lượng sự kiện được chỉ định cho các hàng như vậy.

+0

Thú vị - Bạn có gặp phải vấn đề với SSAS phù hợp với các giá trị nhận diện không? Tôi biết SSAS ghét khi tôi có một giá trị 0 như một bản sắc một thời gian trước đây. – rrydman

+0

Chúng tôi chưa bắt đầu sử dụng SSAS, chúng tôi sẽ bắt đầu sử dụng nó trong một vài tuần. Tôi đoán chúng ta sẽ thấy! –

+0

Tôi đã làm điều tương tự, nhưng tôi chỉ sử dụng 0. Cột nhận dạng cho tất cả các bảng của tôi bắt đầu từ 1, vì vậy tôi đã chèn một hàng 0 cho "Không xác định" cho hầu hết mọi bảng. Tôi thấy không bao giờ có nhu cầu cho nhiều thành viên giả, vì vậy tôi luôn luôn có thể sử dụng 0, có nghĩa là tôi có thể hardcode nó trong ETL bất cứ khi nào tôi chạy qua một tra cứu NULL hoặc thất bại. Tất nhiên, đôi khi NULL có ý nghĩa khác nhau, nhưng sau đó tôi có thể đổi tên thành viên thành "Không", "Không xác định", "Không áp dụng" hoặc bất kỳ nhu cầu kinh doanh nào. –

1
  1. Hoặc NULL hoặc một id dành riêng từ chiều ngày của bạn với ý nghĩa thích hợp. Hãy nhớ NULL thực sự có thể có nhiều ý nghĩa khác nhau, có thể không biết, không áp dụng, không hợp lệ, v.v.

  2. Tôi thích chuỗi rỗng hơn (và không NULLable), nhưng trong dự án tôi đang làm việc bây giờ chuyển đổi chuỗi rỗng thành NULL và cho phép chúng trong cơ sở dữ liệu. Một vấn đề tiềm năng sẽ được thảo luận là một chữ cái trống giữa (không có tên đệm, vì vậy chữ viết tắt ở giữa được biết là trống) khác với chữ viết tắt ở giữa không xác định hoặc ngữ nghĩa tương tự. Đối với tiền, mô hình của chúng tôi cho phép NULLs - Tôi có một vấn đề lớn với điều này trong các sự kiện, vì thông thường, họ thực sự phải là 0, chúng luôn được sử dụng như 0 và chúng luôn luôn phải được bọc với ISNULL(). Nhưng vì chính sách ETL chuyển đổi chuỗi rỗng thành NULL, chúng được đặt thành NULL - nhưng đây chỉ là một tạo phẩm của định dạng tệp truyền tải cố định có khoảng trống thay vì 0 từ một số hệ thống nguồn.

  3. bảng thực tế của chúng tôi thường có một PK dựa trên tất cả các khía cạnh, vì vậy đây sẽ không được phép - nó sẽ được liên kết với một hình nộm hoặc chiều chưa biết

  4. Trong SSIS tôi đã thực hiện một thành phần trang trí mà Trims khoảng cách từ các đầu của tất cả các chuỗi. Chúng tôi thường phải thực hiện rất nhiều xác thực ngày và chuyển đổi trong SSIS, điều này sẽ tốt nhất trong một thành phần.

1

Cảm ơn cho đầu vào,

Hai điều tôi đã làm về dự án mới nhất của tôi là:

1) Được sử dụng gợi ý của Steve về khóa ID tiêu cực đối với Unknown/giá trị tham số đặc biệt. Điều này đã làm việc hoàn hảo và không có vấn đề phát sinh trong quá trình xây dựng khối lập phương SSAS.

2) Tạo biến đổi để kiểm tra xem giá trị có rỗng hay không và nếu có, chuyển đổi thành -1 (bản ghi không xác định trong thứ nguyên) HOẶC nếu đó là giá trị đo, chuyển thành 0. Biểu thức được hiển thị bên dưới làm ví dụ (tôi sử dụng những biến đổi trong cột nguồn gốc):

ISNULL(netWeight) ? 0 : netWeight // This is an example of a Measure column 
ISNULL(completeddateid) ? -1 : completeddateid // This is an example of a dimension key column 

Hy vọng rằng đây sẽ giúp người khác trong thời gian tới ;-)

0

một giải pháp tôi có thể đề nghị được rằng trong ETL-step một bảng chuyển được xác định vào trong đó nhập khẩu hồ sơ được lưu trữ tạm thời SAU tất cả các biến đổi cần thiết. Tôi sẽ thêm một vài thuộc tính phụ vào bảng chuyển giao đó cho phép một người nào đó; bên cạnh các thuộc tính giá trị ban đầu có thể là NULL hoặc một số giá trị không mong muốn khác; để chèn một giá trị "được mã hóa" xác định vấn đề trên một mặt và tên thuộc tính trong đó giá trị sai xảy ra. Sau khi thực hiện điều đó, tôi vẫn có thể quyết định cách sử dụng dữ liệu đã được chuẩn hóa và chuyển giao ở bước sau ... có thể lọc ra các giá trị sai hoặc đề cập đến chúng trong một thứ nguyên lỗi riêng biệt để đưa vào các báo cáo. và cách chúng có thể/có thể ảnh hưởng đến các giá trị tổng hợp.

ví dụ:

error-code attribute= -1 = NULL date -2 = NULL numerical value -3 = NULL PK -4 = NULL text value 

và các thuộc tính khác = IdOrder, BirthDate, OrderAmount vv

Tất nhiên bạn đang gặp rắc rối nhiều hơn nếu hồ sơ thể có nhiều hơn 1 sai giá trị (NULL), nhưng trong trường hợp đó người ta có thể mở rộng số lượng thuộc tính "truy tìm" hoặc "trở lại nguồn" và tìm ra vị trí và lý do xảy ra sự cố (cùng với dep phát triển.)

Đây là một bước có liên quan, tuy nhiên vì lợi ích của sự hoàn chỉnh và chính xác, tôi cho rằng điều đó là không thể tránh khỏi và cần thiết bởi vì nếu không có thể phải đối mặt với thông tin tổng hợp kém.

Có lẽ điều này cũng sẽ giúp ai đó;)

Các vấn đề liên quan