Sangat sedikit penulis database yang menyebutkan tantangan globalisasi dan lokalisasi dengan cara yang berarti. Ada kekurangan pandangan ke depan yang serupa dari arsitek basis data. Faktanya adalah banyak penulis dan desainer sering kali sangat 'egois':mereka membuat (atau menulis tentang) model data yang hanya menangani zona waktu lokal, alamat, dll.
Pendekatan self-centric memiliki masalah besar:model yang dihasilkan hanya akan mendukung data lokal. Di dunia yang didorong oleh Internet saat ini, aplikasi sering kali diakses secara tak terduga oleh pengguna di seluruh dunia. Kita perlu mendukung sebanyak mungkin fleksibilitas untuk audiens internasional ini. Oleh karena itu, kita perlu merancang model data kita dengan pendekatan global.
Saya cukup beruntung bekerja di lingkungan yang sangat multi-nasional dan multi-bahasa, jadi saya telah belajar bagaimana masalah globalisasi dapat ditangani di awal proyek. Dengan mengingat hal itu, saya telah mengumpulkan tujuh poin penting untuk membuat model data yang akan mendukung penggunaan internasional.
1. Pemformatan Angka
Ada dua hal yang perlu dipertimbangkan saat Anda melihat pemformatan angka:output yang dilihat pengguna (yaitu format), dan tipe data yang mendasarinya.
Anda tidak perlu khawatir tentang bagaimana angka akan ditampilkan dalam model data Anda – sistem database akan menangani penyimpanan angka desimal dan aplikasi Anda harus menyesuaikan dengan cara angka desimal ditampilkan (“.” atau “,” sebagai desimal titik, misalnya). Demikian pula, Anda tidak perlu khawatir tentang pemisah ribuan mana (seperti titik atau koma) yang akan digunakan model data Anda.
Inilah intinya: Pilih tipe data Anda dengan benar saat membuat model. Aplikasi Anda harus menangani pemformatan keluaran.
Misalnya, dalam model aplikasi stasiun cuaca sederhana ini, pengukuran cuaca (suhu, kelembaban, curah hujan) disimpan sebagai angka floating-point. Namun informasi harga dalam desimal, mirip dengan koordinat GPS setiap stasiun cuaca.
2. Mata Uang dan Nilai Tukar
Jika Anda menyimpan informasi yang berkaitan dengan mata uang, maka Anda harus menyimpan jumlah desimal yang benar untuk setiap mata uang. Sebagian besar mata uang memiliki dua tempat desimal, tetapi beberapa tidak memilikinya (yaitu peso Chili), satu (ariary Malagasi), tiga (dinar Tunisia) atau bahkan empat tempat desimal (Unidad de Fomento Chili, unit akun yang digunakan untuk menyatakan kisaran nilai harga.)
Jadi, pastikan bahwa bidang "jumlah" Anda dalam model data mendukung lebih dari dua tempat desimal - sementara empat tempat desimal sangat jarang, itu memang terjadi. Tiga tempat desimal lebih umum. Misalnya, dinar di enam negara berbeda (Bahrain, Irak, Yordania, Kuwait, Libya, Tunisia) dan rial di satu negara (Oman) memerlukan tiga tempat desimal.
Poin Nomor 1: Pilih tipe data Anda dengan benar saat membuat model.
Poin penting lainnya terkait mata uang adalah nilai tukar. Ini menuntut lebih presisi. Banyak sistem hanya menyediakan 4-6 digit signifikan dalam nilai tukar; terkadang ada faktor penskalaan antara mata uang yang memiliki nilai yang sangat berbeda. Namun, empat atau enam angka penting tidak berarti akan ada enam tempat desimal. Periksa nilai tukar antara Rupiah Indonesia dan Euro:0,0000668755. Itu banyak tempat desimal untuk disimpan di bidang nilai tukar Anda.
Poin Nomor 2: Model Anda mungkin perlu menangani tingkat presisi yang tinggi – banyak angka desimal – dalam hal nilai tukar.
Di bawah ini kami telah membuat contoh toko online dengan harga. Kami juga telah menambahkan tabel sederhana (disorot dalam aqua) yang menyimpan nilai tukar mata uang, termasuk nilai tukar historis. Setiap baris dalam exchange_rate tabel ditautkan ke mata uang (currency_id , yang merupakan kode mata uang ISO 4217). Kami mengizinkan satu nilai tukar disimpan untuk setiap mata uang pada hari tertentu (rate_date ), dan memiliki satu nilai tukar aktif untuk setiap mata uang.
Jelas, Anda memerlukan beberapa informasi tambahan untuk menggunakan tabel tarif ini. Misalnya, terhadap mata uang dasar apa nilai tukar ini ditentukan? Euro atau dolar AS mungkin tipikal, tetapi aplikasi Anda memerlukan informasi yang tepat di sini.
Atau, model yang lebih kompleks dapat menyimpan pasangan mata uang, kurs tengah (atau kurs bank) dan kurs 'beli' dan 'jual' di antara pasangan mata uang tersebut.
Poin Nomor 3: Model Anda harus memiliki informasi yang cukup agar aplikasi dapat menggunakan data dengan benar.
3. Nomor Telepon
Saya sering melihat sistem yang hanya mendukung nomor telepon sepuluh digit Amerika Utara dengan kode area tiga digit, pertukaran tiga digit, dan nomor pelanggan empat digit (yaitu 012-345-6789). Bias ini dapat dimengerti sampai batas tertentu; orang membuat sistem yang mendukung pengguna lokal mereka. Namun, pemodelan data tidak boleh mengabaikan kemungkinan bahwa pengguna global mungkin mengakses sistem Anda. (Catatan:Panjang sepuluh digit juga dapat digunakan untuk nomor lain, seperti ponsel Prancis, tetapi formatnya berbeda (yaitu 06 12 34 56 78).)
Mari kita ambil ini sebagai contoh:Misalkan saya tinggal di luar perbatasan Prancis, tetapi saya bekerja di Prancis. Oleh karena itu, meskipun saya mungkin perlu menggunakan aplikasi dan penyedia layanan Prancis, nomor ponsel saya bukan nomor Prancis. Sistem yang memerlukan nomor ponsel sepuluh digit yang dimulai dengan 06 atau 07 tidak akan berfungsi untuk saya. Untuk mendapatkan tiket kereta api Prancis, membeli tiket konser di Prancis (dll, dll), saya akan dipaksa untuk mendapatkan nomor telepon Prancis. Mengganggu, untuk sedikitnya.
Inilah intinya: Saat batasan nomor telepon dimasukkan ke dalam model data, modifikasi model data akan diperlukan untuk mendukung pengguna non-lokal. Idealnya, fleksibilitas yang cukup harus dimasukkan ke dalam model untuk menangani semua kemungkinan.
Model data yang lebih logis akan mendukung nomor telepon dengan panjang yang berbeda (hingga 16 digit di beberapa area) dan karakter non-numerik (seperti simbol “+” universal untuk nomor telepon internasional). Tentu saja, beberapa aplikasi dapat melakukan lebih banyak validasi dengan menerapkan "aturan lokal" yang lebih dikenal oleh pengembang lokal. Aplikasi lain mungkin menggunakan nomor telepon lokal untuk mengakses sumber data lain, seperti memverifikasi atau mengambil alamat berdasarkan nomor telepon.
Model data harus mendukung fleksibilitas dalam menyimpan informasi. Aplikasi atau UI-nya dapat lebih membatasi atau melakukan validasi tambahan.
4. Alamat
Sebagai orang Amerika yang tinggal di luar negeri, saya sering menemukan contoh dan pola model data yang terlalu Amero-centric. Misalnya, orang non-Amerika mungkin tidak mengerti apa itu Zip+4 adalah dan karena itu tidak akan mengerti mengapa seorang penulis menyatakan bahwa domain ini harus memiliki karakteristik NOT NULL.
Pandangan Amerosentris ini bahkan hadir dalam buku-buku. Misalnya, ambil buku yang cukup luas “Pola Model Data. Konvensi Pemikiran” oleh David C. Hay. Penjelasan Tuan Hay yang sangat kompleks tentang alamat, situs, lokasi geografis, bidang tanah, dan elemen struktur geografis termasuk contoh dari Kanada, tetapi meskipun demikian, informasi ini mungkin tidak mudah dipahami oleh semua orang.
Pola Pak Hay mengatakan atribut alamat akan mencakup:
"Teks" alamat, ditambah setidaknya "kota", "negara bagian", dan "kode pos (ZIP)".
Sekarang, Tuan Hay dengan cepat menjelaskan dalam catatan kaki bahwa:
Konteks model akan menentukan apakah atribut ini adalah "kode pos" atau "kode pos". Jika organisasi klien akan beroperasi seluruhnya di Amerika Serikat di masa mendatang, asumsi "kode pos" numerik sembilan digit dua bagian dapat dibuat. Jika tidak, "kode ZIP" harus menjadi "kode pos" dan asumsi pemformatan tidak dimungkinkan.
Namun, ia gagal menyebutkan bahwa "negara bagian" mungkin merupakan negara bagian di AS, provinsi di Kanada, atau atribut nullable untuk hampir semua negara lain, karena "negara bagian" di dalam negara jarang ada di luar AS, Kanada (di mana mereka disebut provinsi tetapi fungsinya sama) dan Australia. Tentu saja, negara lain memiliki provinsi dan wilayah, tetapi ini jarang digunakan sebagai bagian dari alamat.
Untuk mengilustrasikan betapa seriusnya masalah alamat ini, saya membuat model data untuk alamat Amerika dan non-Amerika. (Catatan:Ini bukan model yang lengkap.)
PrimaryPhone dari US_Customer tabel hanya menyimpan nomor telepon dengan sepuluh karakter atau kurang. Desain internasional Customer PrimaryPhone tabel atribut memungkinkan nomor telepon 15 digit ditambah "+", yang merupakan maksimum yang ditentukan oleh E.164.
TimeOffset atribut di US_Customer tabel hanya mengizinkan empat zona waktu:Waktu Timur, Waktu Tengah, Waktu Gunung, dan Waktu Pasifik (disimpan dalam model data sebagai:0 =Timur, 1 =Tengah, 2 =Gunung, 3 =Pasifik). Kebetulan, ini bahkan tidak mencakup semua zona waktu di AS dan wilayahnya. Sebaliknya, Timezone atribut di Customer table menyimpan kode internasional untuk zona waktu pelanggan di mana pun letaknya.
Selanjutnya, mari kita lihat kode pos/zip. AS memerlukan kode ZIP 5 digit (Zip dari US_Address tabel) ditambah ZIP+4 opsional (Zip4 dari US_Address meja). Address tabel memiliki PostCode yang lebih fleksibel bidang. Selain panjang, tidak ada batasan informasi yang dapat disimpan di PostCode; tentu saja, aplikasi dapat menerapkan pemeriksaan pada kode pos.
Perhatikan juga bahwa desain AS dan non-AS keduanya memiliki bidang untuk wilayah dalam suatu negara (State di US_Address tabel dan Region di Address tabel), tetapi desain AS mengharuskan singkatan negara bagian 2 karakter disertakan. Perhatikan juga bahwa desain AS tidak menerima alamat internasional, sedangkan versi alamat internasional menerimanya (oleh karena itu, kode negara ISO 2 karakter Negara dari Address tabel).
Inilah intinya: Jangan batasi model data alamat Anda ke satu lokasi; sisakan ruang yang cukup untuk gaya yang berbeda.
5. Pemformatan Tanggal dan Waktu
Model data tidak boleh peduli dengan beberapa format tanggal dan waktu; aplikasi menangani tampilan yang sebenarnya. Ini dapat dilakukan dengan berbagai cara:
- Gaya awal bulan, umum di Amerika Utara dan di tempat lain:mm-dd-yyyy
- Gaya hari pertama, yang lebih umum di Eropa:dd-mm-yyyy
- Gaya tahun pertama, digunakan sebagai format tanggal ISO 8601:yyyy-mm-dd
Inilah intinya: Ini mungkin berulang, tetapi kami akan mengatakannya lagi:pilih tipe data Anda dengan benar saat membuat model. Ini akan memudahkan kode aplikasi untuk menafsirkan dan menampilkan nilai yang tersimpan.
Item lain dalam kategori ini mungkin sedikit tidak terduga:hari apa minggu itu dimulai. Bagi sebagian orang, ini adalah hari Minggu; untuk yang lain, ini adalah hari Senin (dan kemudian ada kalender Persia, yang memulai minggu pada hari Sabtu).
Waktu juga harus ditampilkan dengan cara yang mudah digunakan. Ingatlah bahwa meskipun model data Anda tidak memerlukan banyak format waktu, Anda dapat menyimpan preferensi waktu pengguna , yaitu format 12 atau 24 jam.
Ini membawa kita ke zona waktu.
6. Zona Waktu
Bukan hal yang aneh untuk menemukan aplikasi yang hanya mengizinkan pengguna beberapa pilihan zona waktu:Waktu Bagian Timur, Waktu Tengah, Waktu Gunung, dan Waktu Pasifik. Ketika saya melihat itu, saya tahu bahwa saya berurusan dengan seorang desainer aplikasi Amero-centric. Beberapa desainer mengizinkan zona waktu untuk dinyatakan sebagai offset dari (biasanya) GMT atau UTC. Namun, banyak yang membuat kesalahan dengan hanya mengizinkan offset bilangan bulat, tidak menyadari bahwa beberapa negara (India, Iran, Pakistan, Afghanistan, dan lainnya) bukan offset bilangan bulat. Mereka sedikit berbeda:Waktu Standar India adalah UTC+5:30. Beberapa lokasi bahkan memiliki offset fraksional yang lebih kecil, seperti Waktu Standar Nepal – UTC+05:45.
Beberapa waktu yang lalu, saya menulis tentang model untuk database survei online. Di sini saya telah menambahkan zona waktu ke tabel pengguna sehingga kami dapat menampilkan tanggal/waktu dalam waktu lokal pengguna.
Untuk informasi lebih lanjut tentang tanggal, waktu, zona waktu, Anda dapat merujuk ke representasi standar ISO 8601 tanggal dan waktu atau artikel Wikipedia ini.
Inilah intinya: Belajar berpikir secara global, bukan hanya lokal.
7. Dukungan Multi-Bahasa
Ada banyak waktu ketika aplikasi Anda mungkin perlu memberikan dukungan multi-bahasa. Dari perspektif model data, Anda mungkin perlu menyimpan informasi dalam berbagai bahasa; namun, sebagian besar penanganan linguistik harus tercakup dalam aplikasi Anda. Implementasi dukungan multi-bahasa berada di luar cakupan artikel ini, tetapi kami telah membahasnya di blog ini.
Lokalisasi sangat penting dan perlu ditangani dengan baik. Seperti yang telah kami tunjukkan, ini berarti lebih dari sekadar mendukung beragam bahasa; ini juga tentang format yang disukai untuk tanggal, waktu, mata uang, dan bahkan indikator desimal.
Pemodelan Data? Berpikir Secara Global
Saat membuat model data Anda, pertimbangkan potensi penggunaan internasional dari aplikasi Anda dan databasenya. Berpikirlah secara global selama fase desain dan Anda akan menghindari beberapa masalah di kemudian hari – bidang nomor telepon yang hanya menerima 3-digit + 3-digit + 4-digit berfungsi dengan baik di AS, tetapi tidak begitu baik di Cina atau India.
Apakah database Anda siap untuk go global? Tujuan Anda seharusnya adalah untuk mengaktifkan fleksibilitas tanpa menciptakan kerumitan yang berlebihan.
