Tại sao các cơ sở dữ liệu quan hệ hoạt động hoàn toàn, do sự phức tạp theo cấp số nhân của việc tìm câu trả lời (theo kích thước của truy vấn)?

Dường như được biết rằng để tìm câu trả lời cho truy vấn qua cơ sở dữ liệu quan hệ D , người ta cần có thời gian | D | | Q | và người ta không thể thoát khỏi số mũ | Q | .$Q$$D$$|D|^{|Q|}$$|Q|$

Vì có thể rất lớn, chúng tôi tự hỏi tại sao cơ sở dữ liệu hoạt động hoàn toàn trong thực tế.$D$

Có phải đó chỉ là vấn đề của các truy vấn thông thường không lớn trong các ứng dụng trong thế giới thực? (Sau đó, thật thú vị khi biết kích thước thông thường của các truy vấn được đặt cho các hệ thống cơ sở dữ liệu quan hệ là gì và kích thước "tối đa" của các truy vấn được hệ thống DB dự kiến ​​có thể trả lời một cách hiệu quả trong thực tế là gì .)

Ghi chú về số mũ không 'tháo rời'$|Q|$

Để chỉ ra rằng số mũ không thể tháo rời, người ta có thể sử dụng truy vấn hỏi liệu có tồn tại một cụm kích thước n trong biểu đồ được cung cấp bởi cơ sở dữ liệu hay không. Để kiểm tra xem một đồ thị có n -clique có phải là một vấn đề NP-đầy đủ hay không. Hơn nữa, nó không phải là tham số cố định, với tham số n . Chi tiết có thể được tìm thấy trong, ví dụ, Libkin, L.: Các yếu tố của lý thuyết mô hình hữu hạn. Springer (2004) hoặc Papadimitriou, CH, Yannakakis, M.: Về sự phức tạp của các truy vấn cơ sở dữ liệu. J. Tính toán. Hệ thống. Khoa học 58 (3), 407 Điện427 (1999)$|Q|$$n$$n$$n$

Có nhiều lớp truy vấn "dễ", ngay cả trong trường hợp xấu nhất. Cụ thể, nếu lớp truy vấn chỉ chứa các truy vấn kết hợp và mỗi truy vấn có giới hạn chiều rộng (ví dụ treewidth, treewidth của biểu đồ tỷ lệ, độ rộng siêu phân đoạn hoặc độ rộng mô đun) thì truy vấn có thể được trả lời bằng cách sử dụng một cái gì đó như cây nối , cùng với phép liệt kê lực lượng cho các phần cục bộ của truy vấn đi chệch khỏi cây. Điều này đòi hỏi thời gian đa thức, với mức độ của đa thức được xác định bởi tham số chiều rộng.

Có vẻ như nhiều truy vấn gặp phải trong thực tế là cả kết hợp và có chiều rộng nhỏ. Vì vậy, thời gian chạy đa thức có mức độ thấp trong trường hợp này.

Dániel Marx đã trình bày một bài báo tại STOC 2010 về chiều rộng dưới mô hình gần đây, phiên bản đầy đủ bao gồm một bản tóm tắt hay về các khái niệm khác nhau về chiều rộng và cách xây dựng CSP liên quan đến hình thức cơ sở dữ liệu (phiên bản hội nghị thiếu điều này).

• Dániel Marx, thuộc tính siêu dữ liệu có thể truy cập để thỏa mãn ràng buộc và truy vấn kết hợp , 2010 arxiv: 0911.0801

Đây không phải là một câu trả lời hoàn chỉnh, vì nó không giải quyết được sự phức tạp "điển hình" của các truy vấn cơ sở dữ liệu, nhưng ngay cả với phân tích trường hợp xấu nhất cũng có các truy vấn dễ dàng.

Người ta có thể sử dụng truy vấn Q_n để kiểm tra xem một biểu đồ, được biểu diễn dưới dạng cơ sở dữ liệu, có chứa một cụm với n phần tử hay không. Để kiểm tra xem một đồ thị có một cụm là một vấn đề NP-đầy đủ. Hơn nữa, nó không phải là tham số cố định, với tham số n (có nghĩa là D ^ n).

Một cách khác để trả lời câu hỏi này là "họ không!"

Nếu bạn cung cấp cho triển khai DBMS điển hình một truy vấn có số lượng tham gia rất lớn, thì nó thậm chí sẽ không vượt qua giai đoạn lập kế hoạch / tối ưu hóa (chứ chưa nói đến việc đánh giá), ngay cả khi truy vấn có tính chu kỳ hoặc có cấu trúc rất đơn giản như András ám chỉ ở trên.

Nhưng, đối với khối lượng công việc DBMS "điển hình", các truy vấn như vậy dường như không phát sinh.

Đây là một phiên bản thực tế hơn của câu trả lời của tigreen từ quan điểm của một người thực sự sử dụng nhiều cơ sở dữ liệu (quan hệ): Toàn bộ điểm và sự phức tạp của ứng dụng của họ là cấu trúc chúng theo cách họ yêu cầu ít nhất là tham gia cho mỗi và mọi truy vấn cần thiết nhất có thể và đó là lý do tại sao họ thực sự làm việc . Nói cách khác, đừng hy vọng cơ sở dữ liệu sẽ tự mình giải quyết các vấn đề phức tạp - chúng sẽ không, nhưng nếu được sử dụng một cách khôn ngoan thì chúng là một công cụ thực sự tiện dụng và có thể áp dụng.

Tham gia chỉ là bậc hai trên các mối quan hệ nhiều-nhiều. Đây là tương đối hiếm: trong thực tế, hầu hết các mối quan hệ và tham gia là 1-nhiều, vì vậy chúng sẽ mất thời gian tuyến tính nếu chỉ mục / khóa được xác định. Các câu hỏi với nhiều tham gia nhiều-nhiều là một vấn đề nghiêm trọng.