Tips dan praktik terbaik globalisasi (Analysis Services)

Berlaku untuk: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Penting: Informasi dalam artikel ini hanya berlaku untuk solusi model multidaya .

Tips dan panduan ini dapat membantu meningkatkan portabilitas solusi kecerdasan bisnis multidaya Anda dan menghindari kesalahan yang terkait langsung dengan pengaturan bahasa dan kolase.

Menggunakan kolatasi serupa di seluruh tumpukan

Jika memungkinkan, coba gunakan pengaturan kolase yang sama di SQL Server Analysis Services yang Anda gunakan untuk mesin database, berusaha untuk korespondensi dalam sensitivitas lebar dan sensitivitas huruf besar/kecil, dan sensitivitas akses.

Setiap layanan memiliki pengaturan kolasenya sendiri, dengan default mesin database diatur ke SQL_Latin1_General_CP1_CI_AS dan Analysis Services diatur ke Latin1_General_AS. Default kompatibel dalam hal kasus, lebar, dan sensitivitas aksen. Diperingatkan bahwa jika Anda memvariasikan pengaturan salah satu kolase, Anda dapat mengalami masalah ketika properti kolase berbeda dengan cara mendasar.

Bahkan ketika pengaturan kolase secara fungsional setara, Anda dapat mengalami kasus khusus di mana ruang kosong di mana saja dalam string ditafsirkan secara berbeda oleh setiap layanan.

Karakter spasi adalah 'kasus khusus' karena dapat direpresentasikan sebagai satu byte (SBCS) atau kumpulan karakter byte ganda (DBCS) di Unicode. Dalam mesin relasional, dua string senyawa yang dipisahkan oleh spasi -- satu menggunakan SBCS, yang lain di DBCS -- dianggap identik. Dalam Analysis Services, selama pemrosesan, dua string majemuk yang sama tidak identik, dan instans kedua akan ditandai sebagai duplikat.

Untuk detail selengkapnya dan solusi yang disarankan, lihat Kosong dalam string Unicode memiliki hasil pemrosesan yang berbeda berdasarkan kolase.

Rekomendasi kolabasi umum

Analysis Services selalu menyajikan daftar lengkap semua bahasa dan kolase yang tersedia; ini tidak memfilter kolatasi berdasarkan bahasa yang Anda pilih. Pastikan untuk memilih kombinasi yang dapat dikerjakan.

Beberapa kolatasi yang lebih umum digunakan termasuk yang ada dalam daftar berikut.

Anda harus mempertimbangkan daftar ini sebagai titik awal untuk penyelidikan lebih lanjut, daripada rekomendasi definitif yang mengecualikan opsi lain. Anda mungkin menemukan bahwa kolase yang tidak direkomendasikan secara khusus adalah kolase yang paling sesuai untuk data Anda. Pengujian menyeluruh adalah satu-satunya cara untuk memverifikasi apakah nilai data diurutkan dan dibandingkan dengan tepat. Seperti biasa, pastikan untuk menjalankan beban kerja pemrosesan dan kueri saat menguji kolase.

• Latin1_General_100_AS sering digunakan untuk aplikasi yang menggunakan 26 karakter alfabet Latin dasar ISO.

• Bahasa Eropa Utara yang mencakup huruf Skandinavia (seperti ø) dapat menggunakan Finnish_Swedish_100.

• Bahasa Eropa Timur, seperti Rusia, sering menggunakan Cyrillic_General_100.

• Bahasa tionghoa dan kolakuasi bervariasi menurut wilayah, tetapi umumnya Tionghoa Sederhana atau Tionghoa Tradisional.

  Di RRT dan Singapura, Dukungan Microsoft cenderung melihat Bahasa Tionghoa Sederhana, dengan Pinyin sebagai urutan sortir pilihan. Kolase yang direkomendasikan adalah Chinese_PRC (untuk SQL Server 2000), Chinese_PRC_90 (untuk SQL Server 2005) atau Chinese_Simplified_Pinyin_100 (untuk SQL Server 2008 dan yang lebih baru).

  Di Taiwan, lebih umum untuk melihat Bahasa Tionghoa Tradisional dengan urutan sortir yang direkomendasikan didasarkan pada Jumlah Stroke: Chinese_Taiwan_Stroke (untuk SQL Server 2000), Chinese_Taiwan_Stroke_90 (untuk SQL Server 2005) atau Chinese_Traditional_Stroke_Count_100 (untuk SQL Server 2008 dan yang lebih baru).

  Wilayah lain (seperti Wilayah Administratif Khusus Hong Kong dan Wilayah Administratif Khusus Macao) juga menggunakan Bahasa Tionghoa Tradisional. Untuk kolate, di Hong Kong SAR, tidak biasa untuk melihat Chinese_Hong_Kong_Stroke_90 (pada SQL Server 2005). Di Macao SAR, Chinese_Traditional_Stroke_Count_100 (pada SQL Server 2008 dan yang lebih baru) digunakan cukup sering.

• Untuk bahasa Jepang, kolatasi yang paling umum digunakan adalah Japanese_CI_AS. Japanese_XJIS_100 digunakan dalam penginstalan yang mendukung JIS2004. Japanese_BIN2 biasanya terlihat dalam proyek migrasi data, dengan data yang berasal dari platform non-Windows, atau dari sumber data selain mesin database relasional SQL Server.

  Japanese_Bushu_Kakusu_100 jarang terlihat di server yang menjalankan beban kerja Analysis Services.

• Korean_100 direkomendasikan untuk bahasa Korea. Meskipun Korean_Wansung_Unicode masih tersedia dalam daftar, Korean_Wansung_Unicode tidak digunakan lagi.

Sensitivitas kasus pengidentifikasi objek

Mulai SQL Server 2012 SP2, sensitivitas kasus ID objek diberlakukan secara independen dari kolate, tetapi perilaku bervariasi menurut bahasa:

Skrip bahasa	Sensitivitas huruf besar/besar
Alfabet Latin dasar	Pengidentifikasi objek yang dinyatakan dalam skrip Latin (salah satu dari 26 huruf besar atau kecil bahasa Inggris) diperlakukan sebagai tidak peka huruf besar/kecil, terlepas dari kolasenya. Misalnya, ID objek berikut dianggap identik: 54321abcdef, 54321ABCDEF, 54321AbCdEf. Secara internal, Analysis Services memperlakukan karakter dalam string seolah-olah semua huruf besar, dan kemudian melakukan perbandingan byte sederhana yang independen dari bahasa. Perhatikan bahwa hanya 26 karakter yang terpengaruh. Jika bahasanya adalah Eropa Barat, tetapi menggunakan karakter Skandinavia, karakter tambahan tidak akan dalam huruf besar.
Sirilik, Yunani, Koptik, Armenia	Pengidentifikasi objek dalam skrip non-Latin bicameral, seperti Sirilik, selalu peka huruf besar/kecil. Misalnya, Измерение dan измерение dianggap sebagai dua nilai yang berbeda, meskipun satu-satunya perbedaan adalah kasus huruf pertama.

Implikasi sensitivitas huruf besar/kecil untuk pengidentifikasi objek

Hanya pengidentifikasi objek, dan bukan nama objek, yang tunduk pada perilaku casing yang dijelaskan dalam tabel. Jika Anda melihat perubahan cara kerja solusi Anda (sebelum dan sesudah perbandingan -- setelah menginstal SQL Server 2012 SP2 atau yang lebih baru), kemungkinan besar akan menjadi masalah pemrosesan. Kueri tidak terpengaruh oleh pengidentifikasi objek. Untuk bahasa kueri (DAX dan MDX), mesin rumus menggunakan nama objek (bukan pengidentifikasi).

Catatan

Perubahan kode yang terkait dengan sensitivitas huruf besar/kecil telah menjadi perubahan yang melanggar untuk beberapa aplikasi..

Pengujian lokal menggunakan Excel, SQL Server Profiler, dan SQL Server Management Studio

Saat menguji terjemahan, koneksi harus menentukan LCID terjemahan.

Anda dapat melakukan ini dengan mengedit file .odc dengan tangan untuk menyertakan pengidentifikasi lokal string koneksi properti. Cobalah ini dengan sampel database multidmensional Adventure Works.

• Cari file .odc yang ada. Saat Anda menemukan file untuk Adventure Works multidansional, klik kanan file untuk membukanya di Notepad.

• Tambahkan Locale Identifier=1036 ke string koneksi. Simpan dan tutup file.

• Buka Excel | Data | Koneksi yang Ada. Filter daftar untuk hanya menyambungkan berkas pada komputer ini. Temukan koneksi untuk Adventure Works (lihat nama dengan cermat; Anda mungkin memiliki lebih dari satu). Buka sambungan.

  Anda akan melihat terjemahan Bahasa Prancis dari database sampel Adventure Works.

  

Sebagai tindak lanjut, Anda dapat menggunakan SQL Server Profiler untuk mengonfirmasi lokal. Session Initialize Klik peristiwa lalu lihat daftar properti di area teks di bawah ini untuk menemukan <localeidentifier>1036</localeidentifier>.

Di Management Studio, Anda dapat menentukan Pengidentifikasi Lokal pada koneksi server.

• Di Object Explorer | Menghubungkan | Analysis Services | Opsi, klik tab Parameter Koneksi Tambahan.

• Masukkan Locale Identifier=1036 lalu klik Sambungkan.

• Jalankan kueri MDX terhadap database Adventure Works. Hasil kueri harus berupa terjemahan Bahasa Prancis.

  

Menulis kueri MDX dalam solusi yang berisi Terjemahan

Terjemahan menyediakan informasi tampilan untuk nama objek SQL Server Analysis Services, tetapi pengidentifikasi untuk objek yang sama tidak diterjemahkan. Jika memungkinkan, gunakan pengidentifikasi dan kunci untuk objek SQL Server Analysis Services alih-alih keterangan dan nama yang diterjemahkan. Misalnya, gunakan kunci anggota alih-alih nama anggota untuk pernyataan dan skrip Multidimensional Expressions (MDX) untuk memastikan portabilitas di beberapa bahasa.

Catatan

Ingat bahwa nama objek tabular selalu tidak peka huruf besar/kecil, terlepas dari kolaborasi. Nama objek multidmensional, di sisi lain, mengikuti sensitivitas kasus kolase. Karena hanya nama objek multidemikional yang peka huruf besar/kecil, pastikan bahwa semua kueri MDX yang mereferensikan objek multidemikasi disingkat dengan benar.

Menulis kueri MDX yang berisi Nilai Tanggal dan Waktu

Saran berikut untuk membuat kueri MDX berbasis tanggal dan waktu Anda lebih portabel di berbagai bahasa:

1. Menggunakan bagian numerik untuk perbandingan dan operasi

   Saat Anda melakukan perbandingan dan operasi bulan dan hari dalam seminggu, gunakan bagian tanggal dan waktu numerik alih-alih string yang setara (misalnya, gunakan MonthNumberofYear alih-alih MonthName). Nilai numerik paling tidak dipengaruhi oleh perbedaan dalam terjemahan bahasa.

2. Menggunakan string yang setara dalam tataan hasil

   Saat membangun tataan hasil yang dilihat oleh pengguna akhir, pertimbangkan untuk menggunakan string (seperti MonthName) sehingga audiens multibahasa Anda dapat memperoleh manfaat dari terjemahan yang Anda berikan.

3. Menggunakan format tanggal ISO untuk informasi tanggal dan waktu universal

   Satu pakar Analysis Services memiliki rekomendasi ini: "Saya selalu menggunakan format tanggal ISO yyyy-mm-dd untuk string tanggal apa pun yang saya berikan ke kueri di SQL atau MDX karena tidak ambigu dan akan berfungsi terlepas dari pengaturan regional klien atau server. Saya akan setuju bahwa server harus menangguhkan ke pengaturan regionalnya ketika mengurai format tanggal yang ambigu, tetapi saya juga berpikir bahwa jika Anda memiliki opsi yang tidak terbuka untuk interpretasi bahwa Anda lebih baik memilih itu".

4. Gunakan fungsi Format untuk menerapkan format tertentu, terlepas dari pengaturan bahasa regional

   Kueri MDX berikut, yang dipinjam dari posting forum, menggambarkan cara menggunakan Format untuk mengembalikan tanggal dalam format tertentu, terlepas dari pengaturan regional yang mendasar.

   WITH MEMBER [LinkTimeAdd11Date_Manual] as Format(dateadd("d",15,"2014-12-11"), "mm/dd/yyyy")  
   member [LinkTimeAdd15Date_Manual] as Format(dateadd("d",11,"2014-12-13"), "mm/dd/yyyy")  
   SELECT  
   { [LinkTimeAdd11Date_Manual]  
   ,[LinkTimeAdd15Date_Manual]  
   }  
   ON COLUMNS   
   FROM [Adventure Works]  
   
   

Lihat juga

Skenario globalisasi untuk Analysis Services
Tulis Pernyataan Transact-SQL Internasional