Chỉ sử dụng 3 dấu thời gian cho một cơ sở dữ liệu SQL bitemporal có thể?

Question

Khi thực hiện một cơ sở dữ liệu bitemporal trong SQL, nó thường được khuyến khích sử dụng các timestamps sau:

• ValidStart
• ValidEnd
• TransactionStart
• TransactionEnd

Tôi đã sử dụng phương pháp này một vài lần trước đây, nhưng tôi đã luôn luôn tự hỏi tại sao chỉ có 3 dấu thời gian, để lại TransactionEnd ra, không chỉ là một thực hiện chính xác. Ở đây một khoảng thời gian giao dịch kéo dài từ TransactionStart sang TransactionStart tiếp theo.

Có bất kỳ lý lẽ mạnh mẽ đối với không chỉ sử dụng 3 timestamps, mà sẽ hạn chế kích thước của cơ sở dữ liệu?

Answer 1

Như đã đề cập trong một chú thích đó là vì đơn giản, vì nó hơi khó thực hiện các truy vấn nhất định mà không có nó.

xem xét ví dụ sau đây. John được sinh ra ở một số địa điểm, Location1, vào ngày đầu tiên năm 1990, nhưng được đăng ký lần đầu được sinh ra vào thứ năm.

Bảng cơ sở dữ liệu, Persons, bây giờ trông như thế này:

+----------+--------------+------------+----------+------------+----------+ 
| Name | Location  | valid_from | valid_to | trans_from | trans_to | 
+----------+--------------+------------+----------+------------+----------+ 
| John  | Location1 | 01-01-1990 |99-99-9999| 05/01/1990 |99-99-9999| 
+----------+--------------+------------+----------+------------+----------+ 

Tại thời điểm này, loại bỏ các cột trans_to sẽ không gây ra quá nhiều rắc rối, nhưng giả sử như sau:

Sau vài năm , nói 20, John chuyển đến Location2 và thông báo cho các quan chức 20 ngày sau đó. này sẽ làm cho cái nhìn Persons bảng như thế này

+----------+--------------+------------+----------+------------+----------+ 
| Name | Location  | valid_from | valid_to | trans_from | trans_to | 
+----------+--------------+------------+----------+------------+----------+ 
| John  | Location1 | 01-01-1990 |99-99-9999| 05/01/1990 |20-01-2010| 
| John  | Location1 | 01-01-1990 |01-01-2010| 20/01/2010 |99-99-9999| 
| John  | Location2 | 01-01-2010 |99-99-9999| 20/01/2010 |99-99-9999| 
+----------+--------------+------------+----------+------------+----------+ 

Giả sử ai đó muốn tìm hiểu "Trường hợp nào thì hệ thống nghĩ rằng John đang sống bây giờ" (thời gian giao dịch), không phân biệt nơi ông thực cuộc sống. Điều này có thể (khoảng) được truy vấn trong SQL theo cách sau

Select Location 
From Persons 
Where Name = John AND trans_from > NOW AND trans_to < NOW 

Giả sử thời gian kết thúc giao dịch đã được gỡ bỏ

+----------+--------------+------------+----------+------------+ 
| Name | Location  | valid_from | valid_to | trans_from | 
+----------+--------------+------------+----------+------------+ 
| John  | Location1 | 01-01-1990 |99-99-9999| 05/01/1990 | 
| John  | Location1 | 01-01-1990 |01-01-2010| 20/01/2010 | 
| John  | Location2 | 01-01-2010 |99-99-9999| 20/01/2010 | 
+----------+--------------+------------+----------+------------+ 

Truy vấn trên là tất nhiên không còn giá trị, nhưng làm cho logic cho cùng truy vấn trong bảng cuối cùng sẽ hơi khó. Vì thiếu trans_to, nó sẽ phải được lấy từ các hàng khác trong bảng. Ví dụ: thời gian trans_to tiềm ẩn cho hàng đầu tiên (vì mục nhập cũ nhất của nó) là số trans_from từ hàng thứ hai, là hàng mới hơn của hai hàng.

Giao dịch kết thúc thời gian là do một trong hai 9999-99-99, nếu hàng là mới nhất, hoặc đó là trans_from từ hàng ngay lập tức thành công nó.

Điều này có nghĩa là dữ liệu liên quan đến một hàng cụ thể, không được lưu giữ hoàn toàn trong hàng đó và các hàng tạo thành sự phụ thuộc lẫn nhau, tất nhiên là không mong muốn. Hơn nữa, có thể khó xác định hàng chính xác nào là hàng kế tiếp của một hàng, điều này có thể làm cho các truy vấn phức tạp hơn nữa

Answer 2

Một ví dụ của việc sử dụng chỉ có một dấu thời gian thay vì hai trong một cơ sở dữ liệu thời gian 1D:

tôi có một cửa hàng và tôi muốn ghi lại khi một người sử dụng X là trong cửa hàng của tôi.

Nếu tôi sử dụng một mô hình với thời gian bắt đầu và thời kỳ cuối cùng, thông tin này có thể được ghi nhận là

X,1,2 
X,3,4 

nên dùng X là trong cửa hàng của tôi giữa 1 và 2 và giữa 3 và 4. Đây là rõ ràng, đơn giản và súc tích.

Nếu tôi mô hình dữ liệu của tôi với chỉ bắt đầu thời gian như một dấu thời gian, tôi sẽ có:

X,1 
X,2 
X,3 
X,4 

nhưng làm thế nào tôi có thể giải thích dữ liệu này? X từ (1,2) và X từ (3,4)? hoặc X từ (2,3) và X từ (1,4)? hoặc X từ (1,2), (2,3), (3,4)? X từ (4, inf) là hợp lệ?

Để hiểu dữ liệu này, tôi cần thêm các ràng buộc/logic/thông tin bổ sung vào dữ liệu hoặc mã của mình: có thể là các khoảng thời gian không chồng chéo, có thể tôi thêm id cho mỗi đối tượng, v.v. Tất cả các giải pháp này không hoạt động trong mọi trường hợp, có thể khó duy trì và các vấn đề khác.

Đối với ví dụ: nếu tôi thêm một id (a, b trong trường hợp này) cho tất cả các mục, nó sẽ cho kết quả:

X,a,1 
X,a,2 
X,b,3 
X,b,4 

thay vì để lưu trữ dữ liệu của tôi trong 2 hàng, 3 cột dữ liệu của tôi sẽ là được lưu trữ trong 4 hàng, 3 cột. Không chỉ tôi không có bất kỳ lợi ích sử dụng mô hình này, nhưng mô hình này có thể được giảm xuống còn:

X,a, 1,2 
X,b, 3,4 

tiếp tục giảm xuống

X, 1,2 
X, 3,4