Bảng thực tế khóa ngoại?


8

Tôi chưa quen với thiết kế mart dữ liệu và cần phải xóa một vài khái niệm.

Tôi đã đọc một chút về mô hình hóa kích thước nơi tôi thấy rằng các bảng thực tế lưu trữ các tham chiếu khóa ngoài đến các bảng kích thước.

Bây giờ, giả sử tôi có bảng thứ nguyên số âm và bảng thứ nguyên phone_extension. (Các bảng này có các chi tiết khác nhau do đó tôi không thể kết hợp chúng)

Theo tôi hiểu, cả hai bảng kích thước này sẽ có các khóa chính số nguyên để có hiệu suất tốt hơn và bảng thực tế sẽ có khóa chính nguyên và cũng lưu trữ các tham chiếu khóa ngoài cho các bảng kích thước này.

Nhưng giả sử tôi có một tình huống là không phải tất cả các số điện thoại đều có phone_extension liên quan đến chúng. (một số số điện thoại không cần phải có tiện ích mở rộng)

Đối với các số điện thoại có phần mở rộng, bảng thực tế sẽ có các tham chiếu khóa ngoài cho cả hai bảng thứ nguyên, nhưng làm cách nào để nắm bắt tình huống chỉ có số điện thoại và không có phần mở rộng cho chúng (và ngược lại, phần mở rộng không có máy phát âm) ?

Tôi có nên nắm bắt thông tin đó với FK của phonenumber trong bảng thực tế có giá trị và phone_extension khóa ngoại không null ?? Hoặc là những đối tượng không liên quan như vậy không được ghi lại trong các bảng thực tế?

Ngoài ra tôi cần tạo báo cáo của mart dữ liệu này. Vậy tôi có bắt đầu bằng cách truy vấn bảng thực tế và truy xuất các giá trị khóa thứ nguyên hoặc báo cáo trực tiếp từ bảng thứ nguyên không?

Cảm ơn bạn đã dành thời gian đọc nó !!
Đánh giá cao sự giúp đỡ !!


có thể là một câu hỏi serverfault?

Câu trả lời:


10

Bạn có thể để FK cho một số bảng kích thước dưới dạng NULL nếu các kích thước đó không được biết hoặc không áp dụng. Bạn chỉ cần nhớ sử dụng các phép nối ngoài khi bạn thực hiện truy vấn báo cáo của mình.

Ngoài ra, một số người tạo bản ghi kích thước "không" và / hoặc "không áp dụng" cho kích thước mart dữ liệu và sau đó điền FK của bảng thực tế để chỉ vào những thứ này thay vì sử dụng NULL. Những người làm điều này thích cách tiếp cận này vì họ có ác cảm với những người tham gia bên ngoài.

Những người sử dụng NULL FK trong các bảng thực tế thường có ác cảm với những người có phiên bản tham gia bên ngoài. ;) (nói cách khác, đây là một vấn đề phong cách có thể tạo ra các cuộc chiến tôn giáo)

Tôi nói làm bất cứ điều gì bạn thích, nhưng chọn một cách tiếp cận và kiên quyết với nó.


10

Đừng bỏ null vào Kho hoặc trong Marts.

Kho nên được chuẩn hóa tốt (ít nhất là BCNF) và do đó nên loại trừ null. Nulls có thể được bảo quản trong các bảng phân tầng nếu chúng tồn tại trong các nguồn dữ liệu nhưng chúng không cần thiết trong kho.

Marts nên được thiết kế để hỗ trợ các công cụ trình bày và truy vấn người dùng. Nulls chỉ cản trở những điều đó bởi vì chúng không bao giờ được hiển thị và chúng làm cho các truy vấn của người dùng trở nên phức tạp và dễ bị lỗi hơn - đặc biệt là trong các cột khóa ngoại thường xuyên phải tham gia.


Tôi đồng ý, nhưng vì lý do được trích dẫn bởi Brown: rất có giá trị khi có hồ sơ tổng hợp rõ ràng vì lý do lĩnh vực này sẽ là NULL. NULL không nói gì với người dùng; "Không thể phân tích giá trị", "Trường để trống" hoặc "Chưa có người điều hành tài khoản nào được chỉ định" là hữu ích.
Jon của tất cả các giao dịch

0

Các khóa kích thước trong thực tế không được rỗng và imho có các kích thước để loại bỏ sự cần thiết của các kết nối bên ngoài bên trái của người dùng cuối, các báo cáo, v.v. không có chìa khóa nào cả và thất bại. Thà thất bại còn hơn là tham gia vào thứ nguyên và không biết bạn đã bỏ lỡ hàng nào trong thực tế, cho đến khi một số người dùng cuối cùng tìm thấy nó (nếu điều đó đã từng xảy ra)

tạo một bản ghi "không có" trong kích thước phone_extension và liên kết với nó.

quy tắc của chúng về themb là giá trị nullable duy nhất trong một datamart cuối dwh là chính thực tế, do đó các hàm tổng hợp như avg vẫn hoạt động.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.