Rất ít tác giả cơ sở dữ liệu đề cập đến những thách thức của toàn cầu hóa và bản địa hóa theo bất kỳ cách nào có ý nghĩa. Các kiến trúc sư cơ sở dữ liệu cũng thiếu tầm nhìn xa tương tự. Thực tế là nhiều tác giả và nhà thiết kế thường rất ‘tự cho mình là trung tâm’:họ tạo (hoặc viết về) các mô hình dữ liệu chỉ xử lý đúng múi giờ địa phương, địa chỉ, v.v.
Phương pháp lấy chính mình làm trung tâm có một vấn đề lớn:mô hình kết quả sẽ chỉ hỗ trợ dữ liệu cục bộ. Trong thế giới Internet ngày nay, các ứng dụng thường được người dùng trên toàn cầu truy cập một cách bất ngờ. Chúng tôi cần hỗ trợ tính linh hoạt nhiều nhất có thể cho đối tượng quốc tế này. Do đó, chúng ta cần thiết kế các mô hình dữ liệu của mình với cách tiếp cận toàn cầu hóa.
Tôi đủ may mắn được làm việc trong một môi trường đa quốc gia và đa ngôn ngữ, vì vậy tôi đã học được cách xử lý các vấn đề toàn cầu hóa khi bắt đầu dự án. Với ý nghĩ đó, tôi đã tổng hợp bảy điểm quan trọng để tạo ra một mô hình dữ liệu sẽ hỗ trợ việc sử dụng quốc tế.
1. Định dạng số
Có hai điều cần cân nhắc khi bạn xem định dạng số:kết quả đầu ra mà người dùng nhìn thấy (tức là định dạng) và kiểu dữ liệu cơ bản.
Bạn không cần phải lo lắng về cách các số sẽ được hiển thị trong mô hình dữ liệu của mình - hệ thống cơ sở dữ liệu sẽ xử lý việc lưu trữ các số thập phân và ứng dụng của bạn phải điều chỉnh cách hiển thị số thập phân (“.” Hoặc “,” dưới dạng số thập phân chẳng hạn như điểm). Tương tự, bạn không cần phải lo lắng về dấu phân tách hàng nghìn (chẳng hạn như dấu chấm hoặc dấu phẩy) mà mô hình dữ liệu của bạn sẽ sử dụng.
Đây là điểm: Chọn loại dữ liệu của bạn một cách chính xác khi lập mô hình. Ứng dụng của bạn phải xử lý định dạng đầu ra.
Ví dụ, trong mô hình ứng dụng trạm thời tiết đơn giản này, các phép đo thời tiết (nhiệt độ, độ ẩm, lượng mưa) được lưu trữ dưới dạng số dấu phẩy động. Nhưng thông tin giá ở dạng thập phân, tương tự như tọa độ GPS của từng trạm thời tiết.
2. Tiền tệ và tỷ giá hối đoái
Nếu bạn đang lưu trữ thông tin liên quan đến tiền tệ, thì bạn phải lưu trữ số chữ số thập phân chính xác cho mỗi loại tiền tệ. Hầu hết các đơn vị tiền tệ đều có hai chữ số thập phân, nhưng một số không có (tức là peso Chile), một (bảng chữ cái Malagasy), ba (đồng dinar Tunisia) hoặc thậm chí bốn chữ số thập phân (Unidad de Fomento của Chile, một đơn vị tài khoản được sử dụng để biểu thị một phạm vi giá trị.)
Vì vậy, hãy đảm bảo rằng các trường "số tiền" của bạn trong mô hình dữ liệu hỗ trợ nhiều hơn hai chữ số thập phân - trong khi bốn chữ số thập phân là rất hiếm nhưng điều đó xảy ra. Ba chữ số thập phân phổ biến hơn. Ví dụ:đồng dinar ở sáu quốc gia khác nhau (Bahrain, Iraq, Jordan, Kuwait, Libya, Tunisia) và rial ở một quốc gia (Oman) yêu cầu ba chữ số thập phân.
Điểm số 1: Chọn đúng loại dữ liệu của bạn khi lập mô hình.
Một điểm quan trọng khác liên quan đến tiền tệ là tỷ giá hối đoái. Những yêu cầu này thậm chí còn chính xác hơn. Nhiều hệ thống chỉ cung cấp 4-6 chữ số có nghĩa trong tỷ giá hối đoái; đôi khi có một yếu tố tỷ lệ giữa các loại tiền tệ có giá trị rất khác nhau. Tuy nhiên, bốn hoặc sáu chữ số có nghĩa không nhất thiết có nghĩa là sẽ có sáu chữ số thập phân. Kiểm tra tỷ giá hối đoái giữa Rupiah Indonesia và Euro:0,0000668755. Đó là rất nhiều chữ số thập phân cần lưu trữ trong trường tỷ giá hối đoái của bạn.
Điểm số 2: Mô hình của bạn có thể cần xử lý ở mức độ chính xác cao - nhiều chữ số thập phân - khi nói đến tỷ giá hối đoái.
Dưới đây, chúng tôi đã tạo một ví dụ về cửa hàng trực tuyến có giá cả. Chúng tôi cũng đã thêm một bảng đơn giản (được đánh dấu bằng màu nước) lưu trữ tỷ giá hối đoái tiền tệ, bao gồm cả tỷ giá hối đoái trước đây. Mỗi hàng trong exchange_rate bảng được liên kết với một đơn vị tiền tệ (currency_id , là mã tiền tệ ISO 4217). Chúng tôi cho phép một tỷ giá hối đoái được lưu trữ cho mỗi đơn vị tiền tệ vào một ngày cụ thể (rate_date ), và có một tỷ giá hối đoái đang hoạt động cho mỗi loại tiền tệ.
Rõ ràng, bạn sẽ cần một số thông tin bổ sung để sử dụng bảng tỷ lệ này. Ví dụ, tỷ giá hối đoái này được xác định dựa trên loại tiền tệ cơ sở nào? Euro hoặc đô la Mỹ có thể là thông thường, nhưng ứng dụng của bạn sẽ cần thông tin chính xác ở đây.
Ngoài ra, một mô hình phức tạp hơn có thể lưu trữ các cặp tiền tệ, tỷ giá trung bình (hoặc tỷ giá ngân hàng) và tỷ giá "mua" và "bán" giữa các cặp tiền tệ đó.
Điểm số 3: Mô hình của bạn cần có đủ thông tin để ứng dụng có thể sử dụng dữ liệu đúng cách.
3. Số điện thoại
Tôi thường thấy các hệ thống chỉ hỗ trợ một số điện thoại gồm mười chữ số ở Bắc Mỹ với mã vùng ba chữ số, tổng đài ba chữ số và số thuê bao bốn chữ số (tức là 012-345-6789). Sự thiên vị này có thể hiểu được ở một mức độ nào đó; mọi người tạo ra các hệ thống hỗ trợ người dùng cục bộ của họ. Tuy nhiên, mô hình hóa dữ liệu không nên bỏ qua khả năng người dùng toàn cầu có thể truy cập vào hệ thống của bạn. (Lưu ý:Độ dài mười chữ số cũng có thể được sử dụng cho các số khác, chẳng hạn như điện thoại di động của Pháp, nhưng định dạng khác (tức là 06 12 34 56 78).)
Hãy lấy điều này làm ví dụ:Giả sử tôi sống ngay bên ngoài biên giới Pháp, nhưng tôi làm việc ở Pháp. Do đó, mặc dù tôi có thể cần sử dụng các ứng dụng và nhà cung cấp dịch vụ của Pháp, nhưng số điện thoại di động của tôi không phải là số của Pháp. Các hệ thống yêu cầu số điện thoại di động có mười chữ số bắt đầu bằng 06 hoặc 07 sẽ không hoạt động đối với tôi. Để có vé đường sắt Pháp, mua vé xem một buổi hòa nhạc ở Pháp (v.v., v.v.), tôi buộc phải có số điện thoại của Pháp. Ít nhất là Bothersome.
Đây là vấn đề: Khi các ràng buộc về số điện thoại được tích hợp vào mô hình dữ liệu, các sửa đổi mô hình dữ liệu sẽ được yêu cầu để hỗ trợ người dùng không thuộc địa phương. Tốt nhất, nên kết hợp đủ tính linh hoạt vào mô hình để xử lý tất cả các trường hợp xảy ra.
Mô hình dữ liệu hợp lý hơn sẽ hỗ trợ các số điện thoại có độ dài khác nhau (tối đa 16 chữ số ở một số khu vực) và các ký tự không phải số (như ký hiệu “+” chung cho số điện thoại quốc tế). Chắc chắn, một số ứng dụng có thể thực hiện xác thực nhiều hơn bằng cách thực hiện các “quy tắc cục bộ” mà các nhà phát triển địa phương sẽ quen thuộc hơn. Các ứng dụng khác có thể sử dụng số điện thoại địa phương để truy cập các nguồn dữ liệu khác, chẳng hạn như xác minh hoặc truy xuất địa chỉ dựa trên số điện thoại.
Mô hình dữ liệu phải hỗ trợ tính linh hoạt trong việc lưu trữ thông tin. Ứng dụng hoặc giao diện người dùng của nó có thể hạn chế hơn hoặc thực hiện xác thực bổ sung.
4. Địa chỉ
Là một người Mỹ sống ở nước ngoài, tôi thường tìm thấy các ví dụ về mô hình dữ liệu và các mẫu quá đậm chất Mỹ. Ví dụ:một người không phải là người Mỹ có thể không hiểu Zip + 4 là gì và do đó sẽ không hiểu tại sao một tác giả tuyên bố rằng miền này phải có đặc điểm KHÔNG ĐẦY ĐỦ.
Quan điểm lấy người Mỹ làm trung tâm này thậm chí còn xuất hiện trong sách. Ví dụ, lấy cuốn sách khá rộng rãi “Các mẫu mô hình dữ liệu. Các quy ước của Tư tưởng ”của David C. Hay. Lời giải thích rất phức tạp của ông Hay về địa chỉ, địa điểm, vị trí địa lý, thửa đất và các yếu tố cấu trúc địa lý bao gồm các ví dụ từ Canada, nhưng ngay cả như vậy, thông tin này có thể không phải ai cũng nắm được.
Mô hình của ông Hay nói rằng các thuộc tính địa chỉ sẽ bao gồm:
"Văn bản" của địa chỉ, cùng với ít nhất "thành phố", "tiểu bang" và "mã bưu điện (ZIP)".
Bây giờ, ông Hay nhanh chóng giải thích bằng chú thích rằng:
Ngữ cảnh của mô hình sẽ xác định thuộc tính này là "mã ZIP" hay "mã bưu điện". Nếu tổ chức khách hàng sẽ hoạt động hoàn toàn bên trong Hoa Kỳ trong tương lai gần, thì có thể đưa ra giả định về "mã ZIP" gồm chín chữ số, gồm hai phần số. Nếu không, "mã ZIP" phải trở thành "mã bưu chính" và không có giả định định dạng nào có thể thực hiện được.
Tuy nhiên, anh ấy không đề cập đến rằng "tiểu bang" có thể là một tiểu bang ở Hoa Kỳ, một tỉnh ở Canada hoặc một thuộc tính có thể vô hiệu đối với hầu hết bất kỳ quốc gia nào khác, vì "tiểu bang" trong các quốc gia hiếm khi tồn tại bên ngoài Hoa Kỳ, Canada (nơi họ được gọi là tỉnh nhưng hoạt động tương tự) và Australia. Chắc chắn, các quốc gia khác có các tỉnh và khu vực, nhưng chúng hiếm khi được sử dụng như một phần của địa chỉ.
Để minh họa mức độ nghiêm trọng của vấn đề địa chỉ này, tôi đã tạo mô hình dữ liệu cho cả địa chỉ người Mỹ và không phải người Mỹ. (Lưu ý:Đây không phải là mô hình hoàn chỉnh.)
PrimaryPhone của US_Customer bảng chỉ lưu trữ số điện thoại có mười ký tự trở xuống. Thiết kế quốc tế của Customer PrimaryPhone của bảng thuộc tính cho phép một số điện thoại gồm 15 chữ số cộng với “+”, là số tối đa được chỉ định bởi E.164.
TimeOffset trong US_Customer bảng chỉ cho phép bốn múi giờ:Giờ Miền Đông, Giờ Miền Trung, Giờ Miền núi và Giờ Thái Bình Dương (được lưu trữ trong mô hình dữ liệu như:0 =Miền Đông, 1 =Miền Trung, 2 =Miền núi, 3 =Thái Bình Dương). Ngẫu nhiên, điều này thậm chí không bao gồm tất cả các múi giờ ở Hoa Kỳ và các vùng lãnh thổ của Hoa Kỳ. Ngược lại, Timezone trong thuộc tính Customer bảng lưu trữ mã quốc tế cho múi giờ của khách hàng bất kể nó ở đâu.
Tiếp theo, hãy xem mã bưu điện / mã Zip. Hoa Kỳ yêu cầu mã ZIP gồm 5 chữ số (Zip của US_Address bảng) cộng với ZIP + 4 tùy chọn (Zip4 của US_Address bàn). Address bảng có PostCode linh hoạt hơn đồng ruộng. Ngoài độ dài, không có ràng buộc nào về thông tin có thể được lưu trữ trong PostCode; tất nhiên, ứng dụng có thể thực hiện kiểm tra mã bưu chính.
Cũng lưu ý rằng các thiết kế của Hoa Kỳ và không thuộc Hoa Kỳ đều có trường dành cho các vùng trong một quốc gia (State trong US_Address bảng và Region trong Address bảng), nhưng thiết kế của Hoa Kỳ yêu cầu phải bao gồm chữ viết tắt của tiểu bang gồm 2 ký tự. Ngoài ra, hãy lưu ý rằng thiết kế của Hoa Kỳ không chấp nhận địa chỉ quốc tế, trong khi phiên bản địa chỉ quốc tế thì có (do đó mã quốc gia ISO gồm 2 ký tự Quốc gia của Address bảng).
Đây là điểm: Không giới hạn mô hình địa chỉ dữ liệu của bạn ở một khu vực; để lại đủ chỗ cho các phong cách khác nhau.
5. Định dạng Ngày và Giờ
Không nên quan tâm đến các mô hình dữ liệu với nhiều định dạng ngày và giờ; ứng dụng xử lý màn hình thực tế. Điều này có thể được thực hiện theo nhiều cách khác nhau:
- Kiểu đầu tháng, phổ biến ở Bắc Mỹ và các nơi khác: mm-dd-yyyy
- Kiểu ban ngày, phổ biến hơn ở Châu Âu: dd-mm-yyyy
- Kiểu đầu năm, được sử dụng làm định dạng ngày ISO 8601: yyyy-mm-dd
Đây là điểm: Điều này có thể lặp lại, nhưng chúng tôi sẽ nói lại lần nữa:hãy chọn đúng loại dữ liệu của bạn khi lập mô hình. Điều này sẽ giúp mã ứng dụng diễn giải và hiển thị các giá trị được lưu trữ dễ dàng hơn.
Một mục khác trong danh mục này có thể hơi bất ngờ:ngày nào trong tuần bắt đầu. Đối với một số người, đây là Chủ nhật; đối với những người khác, đó là Thứ Hai (và sau đó là lịch Ba Tư, bắt đầu một tuần vào Thứ Bảy).
Thời gian cũng phải được hiển thị theo cách thân thiện với người dùng. Hãy nhớ rằng mặc dù mô hình dữ liệu của bạn không cần nhiều định dạng thời gian, nhưng bạn có thể lưu trữ tùy chọn thời gian của người dùng , tức là định dạng 12 hoặc 24 giờ.
Điều này dẫn chúng ta đến múi giờ.
6. Múi giờ
Không có gì lạ khi tìm thấy các ứng dụng chỉ cho phép người dùng một số lựa chọn múi giờ:Giờ miền Đông, Giờ miền Trung, Giờ miền núi và Giờ Thái Bình Dương. Khi tôi thấy điều đó, tôi biết rằng tôi đang làm việc với một nhà thiết kế ứng dụng lấy người Mỹ làm trung tâm. Một số nhà thiết kế cho phép múi giờ được biểu thị dưới dạng độ lệch so với (thường) GMT hoặc UTC. Tuy nhiên, nhiều người mắc sai lầm khi chỉ cho phép hiệu số nguyên mà không nhận ra rằng một số quốc gia (Ấn Độ, Iran, Pakistan, Afghanistan và những nước khác) không phải là một số nguyên. Chúng khác nhau một chút:Giờ chuẩn của Ấn Độ là UTC + 5:30. Một số vị trí thậm chí còn có chênh lệch phân số nhỏ hơn, chẳng hạn như Giờ chuẩn Nepal - đó là UTC + 05:45.
Cách đây một thời gian, tôi đã viết về một mô hình cho cơ sở dữ liệu khảo sát trực tuyến. Ở đây tôi đã thêm múi giờ vào bảng người dùng để chúng tôi có thể hiển thị ngày / giờ theo giờ địa phương của người dùng.
Để biết thêm thông tin về ngày, giờ, múi giờ, bạn có thể tham khảo cách trình bày ngày và giờ theo tiêu chuẩn ISO 8601 hoặc bài viết này trên Wikipedia.
Đây là vấn đề: Học cách suy nghĩ trên toàn cầu, không chỉ tại địa phương.
7. Hỗ trợ đa ngôn ngữ
Có nhiều lúc ứng dụng của bạn có thể cần cung cấp hỗ trợ đa ngôn ngữ. Từ góc độ mô hình dữ liệu, bạn có thể cần thông tin được lưu trữ bằng nhiều ngôn ngữ; tuy nhiên, hầu hết các xử lý ngôn ngữ nên được đề cập trong ứng dụng của bạn. Việc triển khai hỗ trợ đa ngôn ngữ nằm ngoài phạm vi của bài viết này, nhưng chúng tôi đã thảo luận về nó trong blog này.
Nội địa hóa là rất quan trọng và cần được xử lý đúng cách. Như chúng tôi đã chỉ ra, điều này không chỉ có nghĩa là hỗ trợ các ngôn ngữ đa dạng; nó cũng là về các định dạng ưa thích cho ngày, giờ, đơn vị tiền tệ và thậm chí cả các chỉ số thập phân.
Mô hình hóa dữ liệu? Suy nghĩ trên toàn cầu
Trong khi tạo mô hình dữ liệu của bạn, hãy xem xét khả năng sử dụng quốc tế của ứng dụng của bạn và cơ sở dữ liệu của nó. Hãy suy nghĩ toàn cầu trong giai đoạn thiết kế và bạn sẽ tránh được một số vấn đề sau này - trường số điện thoại chỉ chấp nhận 3 chữ số + 3 chữ số + 4 chữ số hoạt động tốt ở Hoa Kỳ, nhưng không tốt ở Trung Quốc hoặc Ấn Độ.
Cơ sở dữ liệu của bạn đã chuẩn bị sẵn sàng để vươn ra toàn cầu chưa? Mục tiêu của bạn phải là kích hoạt tính linh hoạt mà không tạo ra sự phức tạp quá mức.
