Germaniya DAX-ga ba'zi alternativalar.
DAX-ga alternativa qidirayotgan xalqaro sarmoyadorlar juda ko'p turli xil imkoniyatlarga ega. AQSh almashinuvidan foydalangan holda Germaniyaga sarmoya kiritishning eng to'g'ridan-to'g'ri usuli bu iShares MSCI Germany Index Fund ETF (NYSE: EWG), ammo Germaniya ekspozitsiyasiga ega boshqa ko'plab fondlar ham mavjud. Bundan tashqari, DAX-da ro'yxatga olinmagan ba'zi Germaniya kompaniyalari AQSh birjalarida ADR sifatida savdo qilishlari va yaxshi sarmoyalar olishlari mumkin.
Nemis ekspozitsiyasi bilan mashhur ETF-lar:
iShares MSCI Germaniya fond jamg'armasi (NYSE: EWG)
Market Vektorlar Germaniya kichik qopqoqli ETF (NYSE: GERJ)
MSCI Evropa ETF (NYSE: VGK)
SPDR DJ EURO Stoxx 50 ETF (NYSE: FEZ)
iShares MSCI EMU ko'rsatkichi ETF (NYSE: EZU)
Ushbu ETFlarni ko'rib chiqayotganda, investorlar o'zlarining portfellariga to'g'ri kelishiga ishonch hosil qilish uchun ularning qanday taqqoslanganligini va mablag'lar bilan bog'liq xarajatlar nisbatlarini ko'rib chiqishlari kerak.
Ushbu maqola DAX o'lchovini DISTINCT COUNT hisob-kitobi asosida tahlil qilishni va mumkin bo'lgan optimallashtirishlarni qanday baholashni tavsiflaydi.
VertiPaq dvigateli DAX tomonidan xotirada yuklangan ma'lumotlarga asoslangan modelni so'raganda foydalaniladi. Vertipaq dvigatelining ishlashi, shuningdek, DISTINCTCOUNT funktsiyasidan foydalangan holda ustundagi noyob qiymatlarni hisoblashda juda yaxshi. Biroq, murakkab hisobotlarda noyob qiymatlarni hisoblash baribir ishlash muammolarini keltirib chiqarishi mumkin. Buning asosiy sababi shundaki, DISTINCTCOUNT hisobotdagi har bir katak uchun hisoblab chiqilishi kerak bo'lgan qo'shilmagan birikma hisoblanadi. Ushbu yig'ilishning xatti-harakatlarini tushunish, nazariy jihatdan sekinroq bo'lgan boshqa ekvivalent iboralar nima uchun aniq hisobotlarda yaxshiroq ishlashni ta'minlay olishini tushuntirishi mumkin.
Ushbu maqolada bir xil DISTINCTCOUNT hisob-kitobini ikkita muqobil usulda qanday bajarish, turli hisobotlarda ishlashni o'lchash va taqqoslash ko'rsatilgan. DISTINCTCOUNT dasturini SUMX / DISTINCT yordamida amalga oshirish mumkin bo'lsa, DISTINCTCOUNT versiyasi odatda yaxshiroq ekanligini ko'rasiz. Ya'ni, agar hisobotlarning zichligi yuqori bo'lmasa va hisoblash vizualizatsiya guruhliligiga mos kelmasa, filtrlarni qo'llamaydi - har doimgidek vaqtni aniqlash funktsiyalari yordamida. SUMX / DISTINCT yaxshi ishlashni taklif qilishi mumkin bo'lgan holatlar mavjud, ammo bitta hisobotni optimallashtirish boshqalarning ishini sekinlashtirishi mumkinmi yoki yo'qligini aniqlab olishingiz kerak. DAX Studio-dan foydalangan holda ishlashni o'lchash sizning modelingiz va hisobotlaringiz uchun nima kutishini bilishning yagona usuli.
DISTINCTCOUNT ko'rsatkichini o'lchash
Mahsulot sotib oladigan noyob mijozlar sonini hisoblash uchun ikkita o'lchov yordamida oddiy hisobotni ko'rib chiqing: # Mijozlar va # Mijozlar YTD. Ikkinchisi birinchisiga yil hisobidan qo'llaniladi.
# Customers :=
DISTINCTCOUNT ( Sales[CustomerKey] )
# Customers YTD :=
CALCULATE (
[# Customers],
DATESYTD ( 'Date'[Date] )
)
Ushbu vizualizatsiya uchun yaratilgan DAX so'rovining bajarilishi nisbatan tez. Shu bilan birga, so'rovlar rejasida ko'p miqdordagi saqlash dvigatellari so'rovlari (SE So'rovlari) bajarilganligi qiziq.
Alohida hisoblash hisobi qo'shimcha bo'lmaganligi sababli, saqlash mexanizmi tomonidan ishlab chiqarilgan natijadan formulalar dvigateli foydalanib, oraliq hisoblash natijalarini to'play olmaydi. Doimiy DISTINCTCOUNT o'lchovi uchun bu muammo emas, chunki hisobotning har bir donadorlik darajasi uchun bitta SE so'rovi mavjud. Masalan, bu avvalgi skrinshotning 26-satrida ko'rinadigan SE so'rovi, 2007 yilda # Mijozlar o'lchovini choraklik granulyatsiyasida hisoblashga mos keladi:
SELECT
'Date'[Calendar Year Quarter Number],
'Date'[Calendar Year Quarter],
DCOUNT ( 'Sales'[CustomerKey] )
FROM 'Sales'
LEFT OUTER JOIN 'Date'
ON 'Sales'[Order Date]='Date'[Date]
WHERE
'Date'[Calendar Year Number] = 2007;
Ushbu bitta SE so'rovi 2017 yilda har bir chorak uchun # Mijozlar natijasiga mos keladigan 4 ta qatorni qaytaradi. Biroq, bitta SE so'rovini yuborish # Mijozlar YTD hisob-kitobi uchun mumkin emas, bu ishlab chiqarilgan har chorak uchun boshqa filtr kontekstiga ega. DATESYTD funktsiyasi bo'yicha. Darhaqiqat, uch chorak oldingi skrinshotdagi 14, 18 va 22 qatorlaridagi SE so'rovlari bilan hisoblab chiqilgan. Tuzilishi Ushbu so'rovlarning har birining tuzilishi 2007 yil oktyabr oyini hisoblashda ishlatilganiga o'xshashdir (xmSQL kodi o'qish uchun soddalashtirilgan):
SELECT
DCOUNT ( 'Sales'[CustomerKey] )
FROM 'Sales'
LEFT OUTER JOIN 'Date'
ON 'Sales'[Order Date]='Date'[Date]
WHERE
'Date'[Date] IN ( 39302.000000, 39094.000000, 39111.000000,..[304 total values, not all displayed] ) ;
Hisobotdagi har bir katakchada boshqa sanalar ro'yxatidan tashkil topgan har xil filtr konteksti mavjud bo'lganligi sababli, 2007 yil oktyabr, 2007 yil noyabr va 2007 yil dekabr oylari uchun talab qilinadigan bir-biriga mos keladigan filtrlarni to'g'ri tavsiflovchi bitta SE so'rovini yaratish mumkin emas.
Ushbu yondashuv qimmatga tushishi mumkinligi sababli, biz mumkin bo'lgan alternativalarni ko'rib chiqishimiz mumkin. DISTINCTCOUNT - bu COUNTROWS va DISTINCT yordamida uzoqroq DAX ifodasi uchun faqat sintaksis shakaridir:
-- DISTINCTCOUNT internally uses COUNTROWS / DISTINCT
# Customers Basic :=
COUNTROWS ( DISTINCT ( Sales[CustomerKey] ) )
# Cliers Basic o'lchovi tomonidan tuzilgan so'rovlar rejasi # Clients bilan bir xil va ikkala o'lchov semantik jihatdan tengdir.
Do'stlaringiz bilan baham: |