Xét lại việc chuẩn hóa dữ liệu, Phần 2: Các hồ sơ kinh doanh trong thế kỷ 21

Phần đầu của loạt bài 2 phần này đã thảo luận về lưu trữ hồ sơ trước thế kỷ 21 và những ảnh hưởng của các cơ sở dữ liệu quan hệ và Web. Trước khi đưa vào các hệ thống máy tính, các hồ sơ kinh doanh được tạo ra và được lưu trữ như nó vốn có theo định dạng ban đầu chưa chuẩn hóa của chúng. Các ví dụ bao gồm các viên đá, các gậy đếm kiểm hoặc các hình thức trên giấy. Với sự ra đời của các hệ thống máy tính, chuẩn hóa dữ liệu đã được phát minh để chuyển đổi các hồ sơ kinh doanh sang một cách biểu diễn khác, có thể bảo tồn không gian và tránh các dị thường cập nhật trong các cơ sở dữ liệu. Tuy nhiên, việc biểu diễn chuẩn hóa rất khác với gốc ban đầu và khó hiểu.

pdf12 trang | Chia sẻ: lylyngoc | Lượt xem: 1831 | Lượt tải: 2download
Bạn đang xem nội dung tài liệu Xét lại việc chuẩn hóa dữ liệu, Phần 2: Các hồ sơ kinh doanh trong thế kỷ 21, để tải tài liệu về máy bạn click vào nút DOWNLOAD ở trên
Xét lại việc chuẩn hóa dữ liệu, Phần 2: Các hồ sơ kinh doanh trong thế kỷ 21 Giới thiệu Phần đầu của loạt bài 2 phần này đã thảo luận về lưu trữ hồ sơ trước thế kỷ 21 và những ảnh hưởng của các cơ sở dữ liệu quan hệ và Web. Trước khi đưa vào các hệ thống máy tính, các hồ sơ kinh doanh được tạo ra và được lưu trữ như nó vốn có theo định dạng ban đầu chưa chuẩn hóa của chúng. Các ví dụ bao gồm các viên đá, các gậy đếm kiểm hoặc các hình thức trên giấy. Với sự ra đời của các hệ thống máy tính, chuẩn hóa dữ liệu đã được phát minh để chuyển đổi các hồ sơ kinh doanh sang một cách biểu diễn khác, có thể bảo tồn không gian và tránh các dị thường cập nhật trong các cơ sở dữ liệu. Tuy nhiên, việc biểu diễn chuẩn hóa rất khác với gốc ban đầu và khó hiểu. Phần thứ hai của loạt bài 2 phần này xem xét các xu hướng về các định dạng dữ liệu và các hồ sơ kinh doanh trong thế kỷ 21. Phần này bắt đầu bằng một nghiên cứu chi tiết nêu bật những lợi ích của các hồ sơ kinh doanh số hóa chưa chuẩn hóa, như hiệu năng tốt hơn và chi phí thấp hơn để phát triển và bảo trì ứng dụng. Các cách biểu diễn dữ liệu đang nổi lên khác như JSON và RDF cũng được bàn đến, với việc tập trung vào các ưu và khuyết điểm của chúng theo các kịch bản sử dụng có liên quan. Biểu diễn dữ liệu quan hệ và XML: Một sự so sánh Ngày nay, nhiều hệ thống và ứng dụng tạo ra và biểu diễn các hồ sơ kinh doanh như là các tài liệu XML. Ví dụ, mỗi đơn hàng, mỗi lần giao dịch tài chính, mỗi lần hoàn thuế, mỗi yêu cầu bồi thường bảo hiểm và v.v.., thường là một tài liệu XML riêng biệt. Lý do chính là ở chỗ XML là mở rộng, linh hoạt, tự mô tả và thích hợp cho việc kết hợp thông tin có cấu trúc, không có cấu trúc, nửa có cấu trúc. Các đặc tính này làm cho việc biểu diễn trở nên dễ dàng ngay cả với các hồ sơ phức tạp, việc mở rộng biểu diễn dữ liệu khi cần và việc trao đổi các hồ sơ kinh doanh giữa các ứng dụng (A2A) hoặc các tổ chức (B2B). Do đó, XML cũng đã trở thành định dạng dữ liệu được chọn cho các dịch vụ web và SOA (các Kiến trúc hướng dịch vụ). Đáp lại xu hướng này, các nhà cung cấp cơ sở dữ liệu lớn đã tăng thêm các khả năng XML vào các sản phẩm của mình [1] [3] [5] và một vài cơ sở dữ liệu chỉ dùng XML đã nổi lên [6]. Các sản phẩm này cho phép XML được lưu trữ, lập chỉ mục, truy vấn và cập nhật với nhiều đặc tính giống như dữ liệu quan hệ, bao gồm cả các giao dịch ACID, khả năng phục hồi, khả năng mở rộng, tính sẵn sàng cao và v.v.. Những tiến bộ này của công nghệ cơ sở dữ liệu làm cho có khả năng lưu trữ và quản lý các hồ sơ kinh doanh theo định dạng ban đầu của chúng – XML. Phần này so sánh XML với dữ liệu quan hệ về chuẩn hóa hay không chuẩn hóa, dự phòng và hiệu năng. Một ví dụ Do XML là một định dạng dữ liệu phân cấp, nên một tài liệu XML duy nhất có thể biểu diễn một số tùy ý các mối quan hệ một-nhiều – mà không cần chuẩn hóa các mối quan hệ này trong một tập các đối tượng tách rời nhau. Hãy xem xét một hồ sơ kinh doanh mô tả một khách hàng và mỗi khách hàng có thể có nhiều địa chỉ, nhiều số điện thoại, nhiều địa chỉ email, nhiều tên đệm và nhiều tài khoản đầu tư. Hơn nữa, mỗi tài khoản của khách hàng có thể có nhiều vị trí (các cổ phần), mỗi địa chỉ có thể có nhiều mục "đường phố" và v.v.. Trong một lược đồ quan hệ chuẩn hóa, mỗi một trong các mối quan hệ một-nhiều này yêu cầu một bảng bổ sung, như trong Hình 1. Kết quả là, việc lưu trữ hồ sơ kinh doanh đơn lẻ đòi hỏi phải có nhiều câu lệnh INSERT của SQL trong một số bảng, trong ví dụ này lên đến 12 lệnh INSERT trong 12 bảng. Hình 1. Ví dụ về một lược đồ quan hệ chuẩn hóa Tương tự, khi một ứng dụng lấy ra một hồ sơ khách hàng đơn lẻ, nó cần ban hành các câu lệnh SELECT cho tất cả 12 bảng. Đây là một quá trình không hiệu quả bởi vì nó đòi hỏi 12 hoặc nhiều cuộc gọi API riêng biệt hơn tới cơ sở dữ liệu. Mỗi cuộc gọi đều phải gánh chịu lưu lượng mạng, truy cập vào một bảng cơ sở dữ liệu và thiết bị Vào/Ra (I/O) vật lý có khả năng cho bảng và các chỉ mục của nó. Lưu ý rằng một truy vấn đơn nối tất cả 12 bảng, thường tồi tệ hơn nhiều. Ví dụ, nếu một khách hàng có 3 tài khoản với tổng số là 7 vị trí (như trong bảng 1 đến 3), một kết nối qua toàn bộ ba bảng này sẽ trả về 7 hàng, như trong Bảng 4. Trong tập kết quả này, các giá trị được chọn từ bảng khách hàng được lặp lại 7 lần và các giá trị cho mỗi tài khoản được lặp lại cho từng vị trí của chúng. Sự dư thừa này nhanh chóng làm tăng kích thước của tập kết quả đến mức độ trễ truyền thông giữa máy khách-máy chủ làm giảm hiệu năng. Khi thêm nhiều bảng hơn nữa vào kết nối, tập kết quả phát triển một cách nhanh chóng và làm tăng thêm các vấn đề. Bảng 1 đến 3 cho thấy lược đồ quan hệ chuẩn hóa cho dữ liệu khách hàng, tài khoản và vị trí. Bảng 1. Bảng Customer (Khách hàng) Mã khách hàng Tên Họ Ngày sinh Quốc tịch 12345 JohnDoe1965-09-27 Đức Bảng 2. Bảng Account (Tài khoản) Mã khách hàng Số tài khoảnLoại tiền Số dư 12345 985739476 Euro 120.000 12345 985710938 Euro 2786,23 12345 985808142 USD 523.891 Bảng 3. Bảng Positions (Các vị trí) Số tài khoảnKý hiệu Cổ phiếu 985739476 IBM 1.200 985739476 ORCL 2.500 985739476 VFINX 550 985710938 SBTYA 12.000 985710938 VIVAX 75 985808142 DWCT 1.128 985808142 PMCOA8.461 Bảng 4. Ví dụ, dữ liệu không chuẩn hóa trong tập kết quả của truy vấn nối Mã khách hàng Tên Họ Ngày sinh Quốc tịch Số tài khoản Loại tiền Số dư tài khoản Ký hiệu Cổ phiếu 12345 JohnDoe 1965-09-27 Đức 985739476 Euro 120.000 IBM 1.200 12345 JohnDoe 1965-09-27 Đức 985739476 Euro 120.000 ORCL 2.500 12345 JohnDoe 1965-09-27 Đức 985739476 Euro 120.000 VFINX 550 12345 JohnDoe 1965-09-27 Đức 985710938 Euro 2786,23 SBTYA 12.000 12345 JohnDoe 1965-09-27 Đức 985710938 Euro 2786,23 VIVAX 75 12345 JohnDoe 1965-09-27 Đức 985808142 USD 523.891 DWCT 1.128 12345 JohnDoe 1965-09-27 Đức 985808142 USD 523.891 PMCOA8.461 Bảng 4 cũng minh họa sự không chuẩn hóa của một lược đồ cơ sở dữ liệu có thể đưa vào dữ liệu dư thừa như thế nào. Để so sánh, liệt kê 1 cho thấy một cách biểu diễn XML có thể của hồ sơ kinh doanh lô-gic tương tự. Trong khi lược đồ quan hệ chuẩn hóa phân tán thông tin khách hàng trên nhiều trên bảng, thì cấu trúc cây của XML có thể biểu diễn các mối quan hệ một-nhiều giống nhau trong một tài liệu duy nhất. Đồng thời tài liệu đó không chứa bất kỳ sự dư thừa nào, vì một nút cha mẹ (như "Customer ") không được lặp lại cho mỗi nút con của nó (ví dụ như "Account "). Như vậy, XML có thể biểu diễn một hồ sơ kinh doanh trong một tài liệu không chuẩn hóa duy nhất mà không bị dư thừa. Kết quả là, các hồ sơ kinh doanh có thể được chèn vào hoặc lấy ra bằng một câu lệnh SQL duy nhất, làm giảm số lượng các cuộc gọi API cơ sở dữ liệu, tính phức tạp của ứng dụng, chi phí CPU và lưu lượng mạng. Những lợi thế này đã được theo dõi và đo lường trong nhiều hệ thống cơ sở dữ liệu thương mại, khi chúng ta thảo luận trong phần tiếp theo. Liệt kê 1. Biểu diễn XML của dữ liệu Customer, Account và Position John Doe 1965-09-27 German Euro 120000 ... Euro 2786.23 ... USD 523891 ... So sánh hiệu năng quan hệ và XML trong một hệ thống OLTP Các lợi ích của việc chèn vào và lấy ra một hồ sơ kinh doanh như là một tài liệu XML không chuẩn hóa đơn lẻ (chứ không phải là các hàng quan hệ chuẩn hóa) đang làm tăng sự chú ý giữa các học viên thực hành cơ sở dữ liệu. Một công ty hậu cần lớn trên toàn thế giới đã đưa ra gợi ý về giá trị này để thử nghiệm. Một trong những hệ thống OLTP của họ biểu diễn các số hồ sơ kinh doanh cụ thể trong một lược đồ quan hệ chuẩn hóa có chứa 12 bảng. Để lấy ra một hồ sơ kinh doanh, ứng dụng của họ cần ban hành 15 câu lệnh SQL. Hầu hết các hồ sơ kinh doanh được biểu diễn bằng 15 hàng, nhưng một vài hồ sơ có hàng trăm hàng. Để so sánh, họ đã chọn 250.000 hồ sơ kinh doanh và chuyển đổi chúng sang định dạng XML, một tài liệu cho một hồ sơ kinh doanh. Hầu hết các tài liệu có dung lượng 1KB đến 2KB, nhưng một số lên đến 500KB. Kịch bản thử nghiệm đã sử dụng gói sửa lỗi 4 của DB2 9.5 với Linux RHEL 4.6 trên một máy chủ AMD Opteron 8 lõi với 32GB bộ nhớ. Có đến bảy máy tính khách được sử dụng để mô phỏng số lượng ngày càng tăng của người sử dụng đồng thời truy cập vào cơ sở dữ liệu. Mỗi máy khách là một máy tính IBM xSeries 345 (2 lõi). Mỗi bảng trong số 12 bảng quan hệ đã có các chỉ mục thích hợp. Để so sánh, các tài liệu XML được lưu trữ trong một bảng duy nhất, trong một cột XML duy nhất, với một chỉ mục XML duy nhất dựa vào thuộc tính ID (mã định danh) của hồ sơ. Trong thử nghiệm quan hệ, mỗi người sử dụng đồng thời được mô phỏng đã chọn các ID hồ sơ ngẫu nhiên và với mỗi ID đã ban hành một giao dịch với 15 truy vấn SQL để lấy ra tất cả thông tin cho hồ sơ kinh doanh đó. Không tính đến thời gian đã được dùng. Trong thử nghiệm XML, mỗi người dùng đồng thời đã chọn các ID hồ sơ ngẫu nhiên và đã ban hành một truy vấn SQL/XML duy nhất với một biểu thức XPath trong một biến vị ngữ XMLEXISTS để lấy ra một tài liệu XML. Các kết quả được hiển thị trong Hình 2. Trung bình thì các giải pháp XML đã đạt được lưu lượng cao hơn 55% so với lược đồ quan hệ chuẩn hóa. Trong thử nghiệm quan hệ, đã dùng hết công suất xử lý CPU của hệ thống đang thử nghiệm cho 84 người dùng đồng thời khi thực hiện khoảng 3.800 giao dịch mỗi giây. Với các giải pháp XML, hệ thống như vậy đã hỗ trợ lên đến 150 người sử dụng đồng thời và gần 6000 giao dịch mỗi giây. Đồng thời, giải pháp XML đã cho thấy việc sử dụng CPU trên các máy tính khách thấp hơn đáng kể so với giải pháp quan hệ. Hình 2. Hiệu năng lấy ra: XML không chuẩn hóa so với dữ liệu quan hệ chuẩn hóa Đối với công ty hậu cần, các lợi ích của giải pháp XML không chuẩn hóa còn nhiều hơn nữa ngoài hiệu năng cao hơn và tiêu thụ CPU thấp hơn. Ví dụ, mỗi tài liệu XML có sẵn ngay lập tức cho các ứng dụng khách sử dụng, trong khi các hàng quan hệ được lấy ra đã đòi hỏi xây dựng một một hồ sơ kinh doanh - một chi phí bổ sung đã không có trong các phép đo ở Hình 2. Ngoài ra, giải pháp XML có một lược đồ cơ sở dữ liệu đơn giản và dễ duy trì hơn khi định dạng hồ sơ phát triển theo thời gian. Các hồ sơ kinh doanh có cách biểu diễn như nhau trong cơ sở dữ liệu và trong các ứng dụng (XML), làm đơn giản hoá việc phát triển ứng dụng. Lợi ích này cũng đã được báo cáo để xử lý các biểu mẫu dựa trên XML, ghi nhật ký sự kiện và xử lý đơn hàng [ 4]. Việc truy cập XML sử dụng ít CPU hơn so với truy cập tương đương vào các bảng quan hệ chuẩn hóa đang biểu diễn cùng một hồ sơ kinh doanh. Nhiều dữ liệu hơn được truyền giữa cơ sở dữ liệu và máy khách như là một kết quả của phép nối quan hệ để tái tạo lại hồ sơ kinh doanh hơn việc truyền chính hồ sơ kinh doanh đó trong XML. Hơn nữa, XML dễ hiểu hơn vì nó gần hơn, nếu không giống hệt, với hồ sơ kinh doanh trong thế giới thực. Một mô hình logic riêng biệt cho dữ liệu không còn cần thiết nữa. Các ánh xạ giữa các hồ sơ kinh doanh trong thế giới thực và những thứ được lưu trữ bên trong máy tính là không bắt buộc. Web ngữ nghĩa và RDF (Khung công tác định nghĩa tài nguyên) Xu hướng khác là sự nổi lên của Dữ liệu liên kết (Linked Data) và Web ngữ nghĩa (Semantic Web) để nối dữ liệu liên quan. Cụ thể hơn, Dữ liệu liên kết đã được định nghĩa là "một cách thực hành tốt nhất được khuyến cáo để trưng ra, chia sẻ và kết nối các mảnh dữ liệu, thông tin và kiến thức trên Web ngữ nghĩa bằng cách sử dụng các URI và RDF" 61]. Với RDF, tài nguyên được biểu diễn bằng các câu lệnh dưới dạng các biểu thức chủ thể - biến vị ngữ - đối tượng. Các biểu thức này được gọi là bộ ba [ 8] và được hiển thị trong Liệt kê 2 và các Bảng 5, 6 và 7. Liệt kê 2. XML 10 CHRISTINE>/FIRSTNAME> SMITH 408-463-4963 52750.00 27 MICHAEL>/FIRSTNAME> THOMPSON 408-463-1234 41250.00 Bảng 5. Dữ liệu liên kết (Bộ ba RDF) Chủ thể Biến vị ngữ Đối tượng deptid has depname deptid hasdep 15 Sales isa deptname Sales hasdepid 15 emp has deptid emp hasempno 27 emp hasempno 10 27 isanempnofordepid15 10 isanempnofordepid15 Bảng 6. Dữ liệu quan hệ chuẩn hóa (a) Mã định danh bộ phậnTên bộ phận 15 Bán hàng Bảng 7. Dữ liệu quan hệ chuẩn hóa (b) Mã định danh bộ phậnSố nhân viên Tên Họ Điện thoại Tiền lương 15 27 MICHAEL JONES 408-461-1234 41250 15 10 CHRISTINE SMITH408-040-8051 52780 Chuẩn hóa dữ liệu thành bộ ba là một phần thiết yếu của Web ngữ nghĩa để xây dựng các kho lưu trữ RDF mà các tích hợp mạnh mẽ có thể xuất phát từ đó. Bằng cách chia thông tin thành các phần tử nhỏ nhất của nó (bộ ba), có thể biểu diễn dữ liệu thành các đồ thị có chủ thể và đối tượng thành các nút và biến vị ngữ thành vòng cung liên kết. Phần mềm suy luận (các trình suy luận) có thể phân tích các đồ thị và áp dụng các quy tắc để suy ra các câu lệnh mới. Ví dụ, do các bộ phận có các nhân viên và nguồn nhân lực là một bộ phận, nên có thể suy ra một câu lệnh mới là nguồn nhân lực có các nhân viên. Các liên kết của dữ liệu liên kết thường chỉ kết nối thông tin mới nhất, như là trường hợp có các khóa chính và khóa ngoài trong các bảng quan hệ. Ví dụ, việc kiểm tra một đơn đặt hàng, được xây dựng bằng cách liên kết hoặc bằng cách chuyển hướng các khóa quan hệ, thường chọn địa chỉ khách hàng hiện tại chứ không phải địa chỉ của khách hàng tại thời điểm đã đặt hàng. Trong các hệ thống kinh doanh, với lý do kiểm tra và tuân thủ, điều cần thiết là thực hiện một bản chụp thông tin kinh doanh thích hợp vào lúc một sự kiện quan trọng xảy ra, ví dụ như nhận được một đơn đặt hàng hoặc phát hành một tuyên bố của ngân hàng. Mục đích của ảnh chụp không phải dựa trên việc chuyển hướng vào một ngày sau đó để xây dựng lại hồ sơ kinh doanh khi việc kiểm tra hoặc truy vấn diễn ra. Đôi khi ảnh chụp được ký để cung cấp bằng chứng rằng hồ sơ kinh doanh đó đã không bị làm giả kể từ khi tạo ra nó. RDF, như một hình thức cực đoan của chuẩn hóa, tương tự như dữ liệu quan hệ chuẩn hóa về độ khó của nó để xử lý tạo phiên bản và quản lý lịch sử và kiểm toán. RDF khác với dữ liệu quan hệ chuẩn hóa ở chỗ nó không bị ràng buộc với một lược đồ cố định. Khi một tài nguyên có các đặc tính mới, các câu lệnh bổ sung (bộ ba) được thêm vào để biểu diễn dễ dàng các đặc tính. Tuy nhiên, bộ ba đó có thể khó truy vấn hơn so với các lược đồ quan hệ truyền thống. Các cơ chế của Dữ liệu liên kết và Web ngữ nghĩa rất mạnh và có thể tích hợp các hệ thống dường như không liên quan. Các ví dụ bao gồm việc tích hợp khách sạn và các việc đặt chỗ trước trên máy bay, xử lý đơn đặt hàng hoặc gia hạn bảo hiểm với thông tin mạng xã hội. Sự gia tăng các hồ sơ kinh doanh (theo XML) với các chú thích ngữ nghĩa (bộ ba) đưa ra một cách pha trộn các hồ sơ kinh doanh truyền thống với các cấu trúc Dữ liệu liên kết và Web ngữ nghĩa. Một ví dụ thế giới thực là trang Best Buy của các nhà bán lẻ Mỹ, chú giải các trang XHTML của nó để mô tả các sản phẩm, với RDFa (các chú thích RDF) trang đó có thể được xử lý bằng lập trình nhiều hơn, ví dụ bằng các máy tìm kiếm và các trình phân loại [ 9]. Để pha trộn các chú thích ngữ nghĩa với cơ sở dữ liệu quan hệ còn khó khăn hơn vì không có cơ chế tại chỗ để gia tăng dữ liệu quan hệ mà không thay đổi lược đồ cơ sở dữ liệu quan hệ, trái ngược với các hồ sơ kinh doanh được thể hiện bằng XML ở đó các chú thích được áp dụng đơn giản hơn. JSON JSON (JavaScript Object Notation - Ký hiệu đối tượng JavaScript) được dựa trên một tập con của ngôn ngữ lập trình JavaScript và đã trở nên phổ biến để trình bày thông tin cho các khách hàng JavaScript [ 10]. Thực tế, nhiều API REST và API Web, cung cấp các biến thể của cả XML lẫn JSON. JSON có thể được xem như một định dạng trao đổi dữ liệu trọng lượng nhẹ thích hợp để xây dựng các giao diện người dùng của con người với JavaScript. Nó giúp cho con người dễ đọc và viết và dễ phân tích cú pháp và suy luận ra. Bảng 8 cho thấy một mẫu dữ liệu và so sánh JSON với ký hiệu XML. Bảng 8. JSON so với XML JSON XML { "city": "Armonk", "state": "NY", "population": 4080 } Armonk NY 4080 JSON rất thích hợp cho việc định dạng kết quả của một truy vấn đang chạy để làm cho việc xử lý đơn giản hơn cho một khách hàng JavaScript. Do đó, JSON rất phổ biến cho các ứng dụng web. Tuy nhiên, JSON không có các vùng tên, vì vậy ngay cả khi đã có sẵn các ràng buộc, thì không thể chia sẻ, mở rộng hoặc trộn lẫn chúng với nhau một cách dễ dàng được. Việc hỗ trợ các đặc tả cho JSON, như các ngôn ngữ chuyển đổi hay lược đồ, không có hoặc đã không đạt được một mức độ hoàn thiện giống như việc hỗ trợ các đặc tả cho XML. Mặc dù JSON có một số lợi thế giống như XML về chuẩn hóa dữ liệu, nó đã không đạt tới mức độ hoàn thiện của XML (cũng chẳng đạt tới mức độ hoàn thiện của dữ liệu quan hệ và dữ liệu liên kết) như trong bảng 9. Bảng 9. Comparison of relational data, XML, JSON, and XML Quan hệ XML JSON Dữ liệu liên kết Siêu dữ liệu Data Definition Language - Ngôn ngữ định nghĩa dữ liệu (ISO) Lược đồ XML (W3C), Các vùng tên (W3C) Lược đồ JSON (IETF) RDFS (Lược đồ RDF), Bản thể học (W3C và nơi khác) Các ràng buộc Các ràng buộc tính toàn vẹn trong các định nghĩa bảng (ISO) Schematron (ISO), Relax-NG (OASIS) - Các trigger Các trigger quan hệ - - RIF (W3C) Các nối tiếp hóa trao đổi dữ liệu Tiêu chuẩn SQL (ISO) định nghĩa một sự nối tiếp hóa XML những không được sử dụng rộng rãi – Không có sự nối tiếp hóa nào của JSON được chấp thuận . Có các sự nối tiếp hóa XML là một cú pháp được sử dụng rộng rãi để trao đổi dữ liệu (W3C) JSON là một định dạng nối tiếp hóa, cũng có các biểu diễn XML của JSON XML, Turtle RDF Các chú thích Không có phần của mô hình quan hệ Nhiều loại chú thích được định cho các nghĩa lược đồ XML và cho dữ liệu XML - RDFa (W3C) có thể được sử dụng để chú thích XML Các ngôn ngữ truy vấn & CRUD Data Manipulation Language (DML - Ngôn ngữ xử lý dữ liệu), SQL, SQL/XML (ISO) XPath, XQuery (W3C) và những thứ khác cho CRUD JAQL, JSONiq SPARQL (W3C) Các API CRUD & truy vấn Có nhiều cho các ngôn ngữ lập trình khác nhau ví dụ như JDBC, ODBC Khác nhau, bao gồm một số các API quan hệ và các API cụ thể, ví dụ XQJ - SPARQL Kho lưu trữ đồ thị Giao thức HTTP – cho CRUD (W3C) Bộ sưu tập Bảng, Khung nhìn, cơ sở dữ liệu (ISO) Chức năng sưu tập XML (W3C) (W3C) - Các đồ thị RDF (W3C) Các ngôn ngữ chuyển đổi và khác SQL (Các bảng đến các bảng) XSLT (XML sang văn bản, bao gồm XML); XForms SQL XMLTABLE (XML sang quan hệ) JavaScript - Tóm tắt Chuẩn hóa dữ liệu, một quá trình bắt đầu ngay từ đầu trong hầu hết các dự án thương mại, hầu như luôn cản trở việc lưu trữ các hồ sơ kinh doanh dưới dạng ban đầu của chúng, như XML. Hơn nữa, người ta thường cho rằng làm việc với các hồ sơ kinh doanh XML không hiệu quả. Sự so sánh hiệu năng trong bài này đã cho thấy rằng điều này không nhất thiết phải như vậy. Trong thực tế, các chi phí phục hồi và xây dựng lại các hồ sơ kinh doanh từ các bảng chuẩn hóa thường cao hơn chi phí lưu trữ nguyên bản và lấy ra các tài liệu XML không chuẩn hóa. Do đó, ở nơi sử dụng XML để biểu diễn các hồ sơ kinh doanh, cũng nên xem xét XML như là định dạng lưu trữ thích hợp. Việc truy cập dữ liệu là trung tâm-đối tượng thường thực hiện với XML tốt hơn so với các bảng quan hệ chuẩn hóa và cho phép tốc độ giao dịch XML cao [2]. Ngoài ra, XML cho phép các ứng dụng được tạo nguyên mẫu, được phát triển và được tiến hóa với tính linh hoạt khi không cần thiết kế và duy trì các ánh xạ giữa các bảng quan hệ và XML. Các hệ thống lưu trữ mới nổi như Google BigTable và HBase cũng rời khỏi chuẩn hóa. Chúng ủng hộ việc không chuẩn hóa mạnh mẽ và lưu trữ dữ liệu theo cách nó được truy cập. Các cơ sở dữ