Vì (a) thông tin bạn đang làm việc dường như là một nguồn tài nguyên tổ chức rất có giá trị và (b) khối lượng dữ liệu sẽ là đáng kể, tôi quyết định (c) xây dựng cơ sở dữ liệu quan hệ trên một trong những các nền tảng SQL chính.
Tất nhiên, đó là một quan điểm rất chung chung, đòi hỏi ba yếu tố cần thiết:
Một lược đồ khái niệm được xác định rõ ràng , trong đó người ta phải xác định và đánh dấu chính xác các nguyên mẫu của sự vật, tức là các loại thực thể (bao gồm các thuộc tính và mối liên hệ của chúng) về mức độ phù hợp trong môi trường kinh doanh mà bạn đang làm việc (ví dụ: Tháp và Cảm biến bạn đề cập).
Như bạn đã biết, điểm này đòi hỏi phải thiết lập giao tiếp liên tục và hiệu quả với các chuyên gia kinh doanh.
Một logic bố trí phản ánh mức độ khái niệm với độ chính xác, bằng phương tiện của bảng (ví dụ, quan hệ toán học) tổ chức cũng được phân định các cột với phù hợp cột tên và loại (tức là, mối quan hệ thuộc tính) và tất cả các tương ứng hạn chế để đảm bảo rằng tuân thủ dữ liệu với tất cả các quy tắc được xác định ở tầng trước.
Do đó, đây là nơi mà sức mạnh to lớn của mô hình quan hệ phát huy tác dụng (mặc dù lợi thế của nó có tác động tích cực ở các mức độ trừu tượng khác).
Một sự sắp xếp vật lý , ví dụ, làm tăng tốc độ thực hiện của các hoạt động thao tác dữ liệu lôgic củadydynamic và đảm bảo các ràng buộc logic.
Do mô hình quan hệ cung cấp tính độc lập dữ liệu vật lý , một hệ thống quản lý cơ sở dữ liệu (DBMS for brevity) có thể cung cấp bất kỳ loại cấu trúc nào ở cấp độ này, không chỉ các chỉ mục, để hỗ trợ các định nghĩa logic. Trong trường hợp các nền tảng SQL hàng đầu, vâng, điều này thường ngụ ý, chính xác, thiết lập một chiến lược lập chỉ mục dựa trên xu hướng truy vấn dành riêng cho cơ sở dữ liệu và bạn đã đưa ra những cân nhắc rất thú vị đối với một số cấu hình có thể nhưng không biết cụ thể nhu cầu thông tin với độ chính xác, đưa ra lời khuyên cụ thể về vấn đề này sẽ không phù hợp.
Các yếu tố khác đáng được đánh giá là, ví dụ, nâng cấp cơ sở hạ tầng mạng để tăng băng thông, cho phép cấu hình máy chủ phù hợp (phần cứng và phần mềm), v.v. Và, nếu, và chỉ khi, một học viên đủ trình độ, anh ta hoặc cô ta mới có thể sửa đổi mã nguồn của DBMS lựa chọn (khả thi hơn trong môi trường nguồn mở, một cách tự nhiên).
Theo cách này, các khía cạnh sau đây mà bạn nêu bật
- Quản lý và truy xuất cấu hình tháp / cảm biến để có ý nghĩa phân tích dữ liệu.
- Trực quan hóa dữ liệu bằng cảm biến hoặc khoảng thời gian để quan sát khí tượng.
- Cung cấp cho khách hàng các bộ dữ liệu / bộ dữ liệu đáng tin cậy và liên tục để so sánh hiệu suất của mô hình và cảm biến (có thể yêu cầu một số xử lý hậu kỳ để phân phối theo định dạng được yêu cầu?).
sẽ được giải quyết tốt, bởi vì bạn sẽ dễ dàng có thể khai báo các truy vấn, ví dụ, có được thông tin ở dạng rất có ý nghĩa. Chẳng hạn, bạn có thể lấy dữ liệu liên quan đến
- Cảm biến được xác định bởi SensorNumber
1750, được cài đặt tại Tháp được xác định bởi TowerNumber 31, giữa Ngày 1 June 2017và Ngày27 June 2017 .
Hơn nữa, vì (1) dữ liệu trong cơ sở dữ liệu quan hệ được quản lý một cách hợp lý theo các tập hợp với sự trợ giúp của các hoạt động dựa trên đại số quan hệ và (2) các công cụ SQL khác nhau được tối ưu hóa về mặt vật lý (nhiều hơn các công cụ khác) cho tập hợp xử lý , bạn có thể, ví dụ,
- so sánh tập a với tập b ;
- tham gia tập c với tập d ;
- có được tập hợp con f thông qua một hạn chế trên tập e ;
- sản xuất n tập con từ n giao điểm;
- thuộc tính dự án n từ tập f
- lấy thông tin từ tập z là kết quả của sự kết hợp của tập x với tập y ;
- và như thế.
Các khả năng thao tác dữ liệu trên thực tế là rất lớn cho thấy tính linh hoạt chưa từng có của mô hình quan hệ vì bạn có thể làm việc không chỉ với các bảng cơ sở (các bảng được khai báo bằng các CREATE TABLE … ( … );câu lệnh) mà còn với các bảng dẫn xuất ( SELECT …;đôi khi được thể hiện qua các hoạt động, đôi khi được cố định là VIEWs) . Nói cách khác, bạn có thể (i) thể hiện các cấu trúc dữ liệu mới dựa trên (ii) các cấu trúc dữ liệu trước hoạt động trên (iii) cấu trúc quan hệ cơ bản duy nhất, nghĩa là mối quan hệ toán học.
Rõ ràng, việc sắp xếp các bảng và cột cơ sở của cơ sở dữ liệu quan hệ có thể phát triển và (a) các bảng hoặc cột cơ sở mới có thể được kết hợp vào đó khi (b) theo dõi các loại thực thể mới hoặc các thuộc tính loại thực thể được coi là đáng giá trong bối cảnh kinh doanh thích hợp. Nói cách khác, cả cấu trúc ban đầu lẫn các ràng buộc mở của cơ sở dữ liệu quan hệ đều được dự kiến là tĩnh hoặc bất biến. Bên cạnh đó, một cơ sở dữ liệu được tổ chức phù hợp ngay từ đầu có xu hướng dễ sửa đổi hơn nhiều khi có yêu cầu thông tin mới.
Để phù hợp với các cân nhắc ở trên, định dạng logic của các bộ áp dụng phải được tạo ra một cách khai báo , ở mức logic cơ sở dữ liệu. Các đồ họa hoặc presentational định dạng của các bộ (ví dụ, màu sắc hay kiểu phông chữ sử dụng) phải lần lượt được xử lý bằng cách mã của một hoặc nhiều chương trình ứng dụng (có, chủ yếu là trong một thủ tục cách, có lẽ với sự giúp đỡ của một đối tượng khung định hướng, HTML, v.v.), để làm cho việc truy cập và trình bày các bộ như vậy thân thiện với người dùng. Chắc chắn, bạn cũng có thể sử dụng phần mềm báo cáo kết nối với cơ sở dữ liệu của bạn.
Mô hình hóa cơ sở dữ liệu liên quan
Cho rằng bạn sẽ làm việc với dữ liệu Cảm biến (trong số các tính năng khác, thường liên quan đến thông tin theo hình chuỗi thời gian ), bạn có thể tìm thấy sự trợ giúp của nhiều thiết kế cơ sở dữ liệu và các nguyên tắc quản trị tổng thể có trong hai câu trả lời đặc biệt, bởi @PerformanceDBA , cho các câu hỏi có tiêu đề:
Các cách tiếp cận quan hệ, tập tin phẳng và NoQuery
Các mô hình quan hệ bằng Tiến sĩ Edgar Codd Frank , mặc dù được công bố vào năm 1970, vẫn còn thực sự là phương pháp hiện đại và thanh lịch nhất (dựa trên logic và lý thuyết tập hợp) để đối phó với các vấn đề về quản lý dữ liệu. Đến lượt, các DBMS SQL riêng biệt là các xấp xỉ phổ biến nhất (mặc dù không tuân thủ đầy đủ nhưng vẫn thực sự mạnh mẽ) đối với các hệ thống được đề xuất trong lý thuyết quan hệ và một số trong số chúng đã được tối ưu hóa rất nhiều (ví dụ, về vật lý của chúng- cơ chế cấp độ) trong nhiều thập kỷ nay. Ngoài ra, tất nhiên các nền tảng SQL chính có thể (và sẽ có thể) hoạt động với công nghệ lưu trữ cập nhật nhất (ví dụ: ổ cứng) và công nghệ xử lý (ví dụ: CPU) khá hiệu quả.
Khi được xây dựng trên một DBMS mạnh mẽ, một cơ sở dữ liệu quan hệ được thiết kế đúng ở cấp độ khái niệm, logic và vật lý sẽ quyết định trở thành một tài sản khép kín, tự mô tả và tự bảo vệ mà (1) đáng tin cậy và (2) cung cấp một phản ứng nhanh, hai khía cạnh mà, như bạn biết, có ý nghĩa rất lớn.
Các tập tin phẳng
Do đó, yêu cầu bồi thường theo sau
Tôi đã nói rằng lý do căn bản để sử dụng các tệp phẳng là họ tin rằng một cơ sở dữ liệu quan hệ sẽ mất quá nhiều chi phí.
dễ dàng bị loại bỏ, bởi vì cách tiếp cận tệp phẳng sẽ là:
- tiền khoa học;
- xa tối ưu cho khối lượng dữ liệu lớn;
- quá cồng kềnh;
- phụ thuộc vào chương trình ứng dụng (và bạn sẽ phải triển khai bằng tay hầu hết các tính năng mà DBMS phù hợp cung cấp nguyên bản);
- hiệu suất của nó sẽ dễ dàng bị phá hoại;
- Vân vân.
Trong khi đó, thời trang quan hệ của EDMuch thuận tiện hơn, có thể nói là ít nhất:
- sẽ cung cấp khả năng mở rộng lớn (nó độc lập ở mức vật lý, do đó bạn có thể tăng cường các cơ chế vật lý cơ bản khi cần thiết);
- sẽ mang lại một phong cách đơn giản để thao tác dữ liệu (thông qua các hoạt động trừu tượng ) và
- có thể làm việc với nhiều chương trình ứng dụng cùng một lúc (ví dụ, một hoặc điện thoại di động nhiều hơn ứng dụng, và / hoặc một hoặc nhiều ứng dụng web, và / hoặc một hoặc nhiều ứng dụng máy tính để bàn, vv).
Tuy nhiên, nếu bạn chọn sử dụng các tệp phẳng, bạn nên đánh giá việc sử dụng một tiện ích mạnh mẽ như Awk , mặc dù không phải là DBMS (và không được thiết kế như vậy), cung cấp các tài nguyên tiện dụng để xử lý các tệp , bản ghi , trường , v.v. . Xem Hướng dẫn sử dụng GNU Awk để biết thêm thông tin về chủ đề này.
NoQuery
Dữ liệu không cấu trúc của người dùng và các thuật ngữ liên quan
Theo tuyên truyền của họ, lời biện minh ban đầu cho việc sử dụng các DBMS của NoQuery là chúng được sử dụng trong các lĩnh vực kinh doanh liên quan đến việc xử lý dữ liệu không cấu trúc của Nott, do đó gọi cho câu hỏi:
- Biểu thức dữ liệu không có cấu trúc mà có nghĩa là gì?
Về mặt đó, phải nói rằng dữ liệu, về bản chất, được cấu trúc; nếu nó không có cấu trúc thì nó sẽ là một thứ gì đó vô nghĩa, do đó, một thứ như vậy (i) không thể được coi là dữ liệu và (ii) sẽ không có giá trị quản trị. Do đó, dữ liệu không có cấu trúc của người dùng là một biểu hiện mâu thuẫn và đáng tiếc.
Một cụm từ khác của những bối cảnh đó là dữ liệu bán cấu trúc của người Bỉ. Cụm từ đó gợi ý rằng có tồn tại dữ liệu được cấu trúc trong một phần hoặc một nửa, do đó, theo đoạn trước, chỉ có một phần dữ liệu có thể được cấu trúc có thể là dữ liệu thực tế, phần còn lại hoặc nửa kia chỉ là một thứ không có hình dạng vì nó thiếu cấu trúc và không thể được gọi là dữ liệu.
Tuy nhiên, một thuật ngữ điển hình khác được tìm thấy trong tiếp thị NoQuery là dữ liệu đa hình hình thức. Nếu thuật ngữ được nói có nghĩa là một dữ liệu giống như dữ liệu có nhiều dạng khác nhau, thì thực tế nó là dữ liệu thông thường , nó xuất hiện ở nhiều dạng khác nhau như mọi khi. Và vì nó có nhiều dạng khác nhau, nên nó thể hiện nhiều cấu trúc riêng biệt , vì vậy không có gì đặc biệt về loại dữ liệu này.
Không cần phải nói, dữ liệu và cấu trúc dữ liệu luôn dễ bị thay đổi , sau đó cũng không có gì bất thường trong vấn đề này.
Tăng trưởng khối lượng dữ liệu
Rõ ràng, khối lượng thông tin được quản lý bằng các hệ thống máy tính chắc chắn đã tăng lên trong những năm qua, và sẽ tiếp tục tăng theo cấp số nhân khi thời gian trôi qua, bởi vì các hệ thống mới đang được xây dựng mỗi ngày, nhưng đó là thực tế không phải làm với cấu trúc của thông tin mỗi se .
Thiếu một nền tảng lý thuyết tròn
Một hạn chế quan trọng của các hệ thống NoQuery (có các lớp khác nhau, ví dụ: tài liệu - và dựa trên biểu đồ ) là không có sản phẩm hiện tại nào mà mặc dù được quảng cáo rầm rộ và được dán nhãn là hiện đại - có một cơ sở lý thuyết hợp lý (nếu có) hỗ trợ cho mỗi và mọi người trong ba yếu tố quan trọng nhất của một DBMS thích hợp, nghĩa là các công cụ cho định nghĩa dữ liệu (a), (b) thao tác và (c) co thắt. Do đó, cách tiếp cận NoQuery thực sự gợi ý một hồi quy cho một kỷ nguyên cổ xưa, trong đó việc xử lý dữ liệu được thực hiện trong một quá trình hành động đặc biệt và không có căn cứ, với tất cả sự phức tạp không cần thiết mà nó đòi hỏi.
Ngày nay, các hệ thống đồ thị được bao gồm trong phổ tần của Noz. Các sản phẩm phần mềm này mời quản lý dữ liệu nhờ vào các hoạt động trên hai cấu trúc riêng biệt: các nút và mối quan hệ , một lần nữa, lại mâu thuẫn với thuật ngữ dữ liệu không cấu trúc của Nott - và chúng nổi bật trong nhóm có nền tảng toán học. Tuy nhiên, các sản phẩm đồ thị khá giống với các nền tảng mạng , được coi là lỗi thời từ hàng chục năm trước (một nhược điểm rõ ràng là, như đã đề xuất ở trên, chúng cần hai cấu trúc để biểu diễn dữ liệu, trong khi DBMS có quan hệ theo nguyên tắc thông tin - chỉ cần một).
Ngay cả khi việc tạo ra các hệ thống NoQuery khác nhau mới hơn về mặt thời gian so với nguồn gốc của phần lớn các DBMS SQL, thì hầu hết các khái niệm dựa trên các sản phẩm NoQuery đều dựa trên nguyên tắc .
Một chương trình NoQuery nên được sử dụng, chủ yếu, trong các tình huống, ví dụ,
- nhân viên CNTT thiếu các kỹ năng kỹ thuật cần thiết để xác định (hoặc để xác định một cách hợp lý) cấu trúc dữ liệu quan tâm, vì sự phức tạp của nó; và / hoặc
- tổ chức không thể đủ khả năng giáo dục và đào tạo phù hợp cho nhân viên hiện tại hoặc không thể thuê nhân viên mới sở hữu giáo dục và đào tạo cần thiết; và / hoặc
- khi tính toàn vẹn và nhất quán của dữ liệu không đặc biệt quan trọng; và / hoặc
- khi pha trộn dữ liệu liên quan với dữ liệu của các hệ thống quan trọng đòi hỏi độ chính xác cao không được mong đợi.
Nhưng, ngay cả khi cấu trúc của dữ liệu có vấn đề không được xác định trước khi tạo ra các hệ thống liên quan, một quặng nhiều người nhất thiết sẽ phải
- khám phá cấu trúc nói trên,
- loại bỏ tất cả các nhiễu xung quanh xung quanh và
- thu thập và liên kết dữ liệu thích hợp
sau khi cơ sở dữ liệu và ứng dụng đã bước vào giai đoạn sản xuất để có thể tận dụng tối đa tất cả các tài nguyên được đầu tư vào một dự án, thì việc phân định cấu trúc dữ liệu là một nhiệm vụ không thể bỏ qua, nó phải được thực hiện sớm hơn hoặc sau đó.
Vì vậy, trong khi đi theo cách của NoQuery là một khả năng, tất cả các yếu tố được đề cập trước đây chắc chắn nên được tính đến.
Phương pháp mạnh mẽ nhất
Ngược lại, tiếp cận các yêu cầu thông tin của môi trường kinh doanh theo cách thức quan hệ, thì với một mô hình chung đằng sau việc đưa ra các khả năng (1) quản lý dữ liệu trong cấu trúc tự nhiên của nó ngay từ đầu, ngay lập tức, giúp giảm bớt sự tích hợp với các nguồn dữ liệu khác và cũng của (2) tạo ra các cấu trúc đáng tin cậy mới bằng cách thao túng một công cụ duy nhất màasas đã giải thích trong các phần trước đó có một cơ sở khoa học mạnh mẽ.
Theo mô tả của bạn về kịch bản được đề cập, bạn đã xác định một cấu trúc cụ thể theo các nhu cầu tổ chức có liên quan, vì vậy tôi đề nghị yêu cầu các chuyên gia trong lĩnh vực kinh doanh xác nhận nó. Kế tiếp, tôi khuyên bạn nên tận dụng (i) các cấu trúc của mối quan hệ, các ràng buộc và các hoạt động mà Patrick cung cấp bởi mô hình quan hệ để xử lý cấu trúc đã nói và dữ liệu tương ứng và (ii) DBMS SQL mà bạn rất có thể sẽ lựa chọn cung cấp các công cụ vật lý rất hiệu quả có thể đáp ứng nhu cầu hiện tại và sẽ cung cấp khả năng mở rộng trong tương lai.