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.
12 trang |
Chia sẻ: lylyngoc | Lượt xem: 1800 | Lượt tải: 2
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ữ