>> OKAY, WE WILL GO AHEAD AND GET 
STARTED. HELLO I'M CHRIS. THANK 
YOU FOR JOINING ME. I AM A PROGRAM 
MANAGER. I DRIVE ENTERPRISE FEATURES 
FOR SCALEABILITY, MODELING AND THINGS 
LIKE THAT. WE HAVE JOSH WITH US 
TODAY AS WELL. AND JOSH HAS A MIC 
AND I DON'T KNOW IF YOU WANT TO 
INTRODUCE YOURSELF, JOSH. >> I HAVE 
A MIC. I'M JOSH THE GROUP PROGRAM 
MANAGER FOR SQL SERVICE AND A ZURE. 
>> JOSH AND I CAN ANSWER ANY QUESTIONS 
AS WE GO. SO THE PURPOSE OF TODAY'S 
SESSION IS TO LOOK ATED ENDER PRIZE 
BI ALSO IN ANALYSIS SERVICES FOR 
SCALEABILITY, MANAGEABILITY AND 
OPEN PLATFORM CONNECTIVITY. SO WE 
HAVE SOME ANNOUNCEMENTS FOR SOME 
OF THE FEATURES. WE WILL JUST DISCUSSION 
THE VISION. DOES THE MIC SOUND OKAY 
OR IS IT RINGING A LITTLE BIT? NOT 
TOO BAD? THANK YOU. THANK YOU. OKAY. 
IS THAT A LITTLE BIT BETTER? GOOD. 
SORRY ABOUT THAT. SO TRADITIONALLY 
WE'VE POSITIONED ANALYSIS SERVICES 
FOR ENTERPRISE BI. IT HAS A 20 YEAR 
HERITAGE. WHO IS HERE FOR HIS SESSION 
THIS MORNING AS AMIR MENTIONED, 
ANALYSIS SERVICES CAME OUT IN WHAT 
WAS THEN CALLED 7. THAT WAS LIKE 
OVER 20 YEARS AGO. SO WE HAVE A 
DEEP HERITAGE IN ENTERPRISE BI. 
WE ARE ALSO -- I THINK IT'S FAIR 
TO SAY THE ONLY ONE OF THE TRADITIONAL 
BI VENDORS THAT REALLY EMBRACED 
SELF-SERVICE BI EARLY ON. WE BUILT 
POWER BI. SO WE ARE THEREFORE -- 
WE THEREFORE HAVE A STRONG PRESENCE 
IN BOTH CAMPS. WE'RE NOT LIKE SOME 
OTHER COMPANIES THAT MIGHT BUY SOME 
KIND OF MODERN BI VENDOR SO THEY 
CAN CLAIM THEY HAVE A PRESENCE IN 
SELF-SERVICE BI. WE DON'T HAVE TO 
DO THAT. WE ARE ALREADY NUMBER 1 
IN SELF-SERVICE BI IN MY OPINION 
AN PRETTY MUCH EVERYONE'S AS FAR 
AS I CAN TELL YOU. IF YOU LOOK AT 
THE MAGIC QUADRANT THEY WOULD AGREE 
WE ARE CLEAR LEADERS. SO AS I SAY 
WE HAVE BEEN CLEAR LEAD IN OTHER 
WORDS BOTH CAMPS FOR A LONG TIME. 
WE'RE THE ONLY VENDOR TO BE RANKED 
IN THE LEADERS QUADRANT FOR THE 
LAST 12 YEARS. SO 12 YEARS AGO SELF-SERVICE 
BI DIDN'T EVEN EXIST AS A DISCIPLINE. 
SO THAT SHOWS WE HAVE A DEEP HERITAGE 
IN SELF-SERVICE BI AND WE STILL 
KEPT THAT LEADER SPOT BECAUSE AS 
I SAY, WE EMBRACE SELF-SERVICE BI 
EARLY. EARLY ON. BUT NOW THE WAVE 
AT THE MOMENT IS AROUND CONVERGE 
WEDNESDAY AND HAVING AN END-TO-END 
PLATFORM THAT WILL ENABLE SELF-SERVICE 
BI US EARS. WE HAVE AN ADVANTAGE 
THERE GIVEN WE RUN ON AZURE AND 
INTEGRATE WITH THE WHOLE AZURE ECOSYSTEM 
AND INTEGRATED SECURITY MODEL. WE 
HAVE DATA FLOWS THAT INTEGRATE AND 
WE HAVE GOOD INTEGRATION WITH SUPER 
DATA WAREHOUSE ET CETERA. SO WE 
PROVIDE THAT END-TO-END SYSTEM. 
WE ARE WELL POSITIONED TO CONVERGE 
SELF SERVICE BI ON A SINGLE PLATFORM. 
WE ARE MICROSOFT. WE RUN ON AZURE 
AND BOTH OF OUR PRODUCTS, ANALYSIS 
SERVICES AND POWER BI RUN ON THE 
SAME ENGINE. POWER BI RUNS ON THE 
POWER SERVICES ENGINE. WE DON'T 
NEED TO REINVENT THE WHEEL EVERY 
TIME WE ENABLE AN ENTERPRISE FEATURE 
IN POWER BI. BECAUSE A LOST THE 
TIME THAT FEATURE ALREADY EXISTS 
IT IS ALREADY SUPPORTED BY THE ANALYSIS 
SERVICES ENGINE . SO EVEN IN REFRESH 
WE WILL TALK ABOUT DEPENDS ON PARTITIONS. 
THAT PROSECUTETICIAN FOR 20 YEARS 
THAT IS JUST AN EXAMPLE. SINCE THE 
VERY FIRST VERSION YOU COULD PROGRAMATICALLY 
PARTITION IN SERVICES. WE ARE VERY 
WELL POSITIONED TO CONVERGE THE 
TWO CAMPS AND TO HAVE A SINGLE ALL 
INCLUSIVE PLATFORM THAT WORKS FOR 
ALL BUSINESS INTELLIGENCE USERS. 
IF YOU LOOK AT THE LIFE CYCLE OF 
A LIFE CYCLE IT IS NOT JUST AS CLEAR 
CUT. SOME IMPLEMENTATIONS ARE SOMEWHERE 
IN MIDDLE. SOMETIMES AN ARTIFACT 
AS FAR AS OUT AS ANALYST MAKING 
A DISCOVERY THAT NEEDS TO BE TO 
GET PROMOTE TODAY ENTER PRIZE BI. 
WE WANT TO DO THAT IN A SEAMLESS 
WITHOUT REINVENTING THE WHEEL AND 
PROVIDE MEET COLLABORATION BETWEEN 
THE BUSINESS AND IT. SO ANY QUESTIONS, 
COMMENTS, FEEDBACK, OPINIONS? FEEL 
FREE TO CHIME IN. NO? OKAY. YES, 
GO A HE HAD HAD. >> THERE USED TO 
BE. WE HAD TO PULL TO THAT ARE A 
LONG LIST OF REASONS I WON'T GET 
INTO NOW. WE WILL ENABLE COMPARATIVE 
FUNCTIONALITY IN A BETTER MORE RELIABLE 
WAY. THERE WERE SOME ISSUES WITH 
THAT BECAUSE OF THE FACT THAT -- 
DESPITE THE FACT THAT THEY SHARE 
THE SAME ENGINE NOT ALL OF THE SAME 
FEATURES ARE ENABLED IN BOTH. NEW 
DATA SOURCES WILL COME THROUGH IN 
POWER BI. IT IS A TON OF WORK TO 
TEST THEM AND SHIP THEM IN AZURE. 
THAT'S WHY THEY ARE A LAG AND THEY 
DON'T SHOW UP AT THE SAME TIME. 
IT IS STREAM LINED NOT JUST FROM 
THE CUSTOMER'S PERSPECTIVE BUT OURS 
TO HAVE ONE PLATFORM WITH ONE SINGLE 
SET OF TOOLING AND ONE SET OF DATA 
SOURCES. THERE WERE SOME ISSUES 
WITH IMPORT FROM PBIX. WE WILL DO 
A BETTER JOB WITH THAT GOING FORWARD 
AND A LOT OF THAT WILL HINGE AROUND 
WHAT WE ARE DOING FOR CONVERGE META 
DATA. YOU WILL SEE THAT COMING FORWARD. 
IT WILL WORK BETTER. UNFORTUNATELY 
THERE ISN'T RIGHT NOW. OKAY? ANY 
OTHER QUESTIONS? I WILL JUST TAKE 
-- I AM GOING TO PROBABLY TAKE EVERY 
5 OR 10 MINUTES AND ALLOW 2 OR 3 
QUESTIONS AN THEN MOVE ON. YES, 
GO AHEAD. >> SO ARE YOU SEEING -- 
REALLY QUICKLY. WE MIGHT HAVE TO 
TAKE THIS ONE OFF LINE I'M AFRAID. 
ARE YOU SEEING ISSUES WHERE THE 
AZURE SERVER IS JUST GETTING PEGGED 
BECAUSE OF BACKGROUND REFRESH QUERIES 
IN BI OR BECAUSE OF THE VISUALS 
IN A PARTICULAR REPORT? SO IT IS 
FOR A PARTICULAR REPORT OR BACKGROUND 
REFRESH? SO YOU WOULD HAVE TO GO 
THROUGH. YOU WOULD HAVE TO GO THROUGH 
AND CHECK THE MODEL AND CHECK THE 
QUERIES. I AM NOT ABLE TO ANSWER 
THAT ONE I'M AFRAID. I WILL MOVE 
ON AN THEN WE WILL TAKE MORE QUESTIONS. 
SO AGGREGATIONS. WHO HERE IS AWARE 
OF AGGREGATIONS? IS IT GOOD. GOOD. 
THAT'S A GOOD SIGN. SO WE LAUNCHED 
AGGREGATIONS. WE KIND OF INTRODUCED 
IT AT THE APPLICATION SUMMIT LAST 
YEAR AND IT CAME OUT IN PUBLIC PREVIEW 
SPORTLY AFTER. AS YOU ARE I CAN 
SHOW YOU HOW TO SET IT UP IN A MOMENT. 
SO UP UNTIL NOW IT HAS BEEN IN PUBLIC 
PREVIEW. THE MAIN REASON FOR THAT 
WAS THAT IT DIDN'T GET WORK WITH 
ROW LEVEL SECURITY. IF YOU HAD A 
DESK TOP MODEL AND YOU HAD AILING 
GAS SET UP ON IT IT WOULD DISALLOW 
YOU FROM CREATING LOW LEVEL SECURITY 
FILTERS OR VICE VERSA. SO WE ARE 
PLEASED TO LET YOU KNOW, PLEASE 
TO ANNOUNCE THAT IN THE JULY DESK 
TOP RELEASE IT WILL WORK WITH ROW 
LEVEL SECURITY AND AGGREGATIONS 
WILL THEN GENERALLY AVAILABLE. SO 
YOU WILL BE ABLE TO USE IT WITH 
ENTERPRISE MODEL AND UNLOCK MASSIVE 
DATA SET AS IT WILL BE GENERALLY 
AVAILABLE IN THE JULY DESK TOP RELEASE. 
SO I'M GOING TO SHOW YOU HOW THAT 
WORKS. THAT'S PROBABLY THE MAIN 
KIND OF TECHNICAL DEMO THAT I AM 
GOING TO DO. ALL RIGHT? >> SO LET 
ME SEE. WHO HERE HAS SEEN THE DEMO? 
I HAVE DONE IT A TON OF TIMES. CLICK, 
CLICK, CLICKY, DROPY, DROPY. WHO 
HERE HAS NOT SEEN IT. OH MY GOODNESS. 
IT SHOCKS ME HOW MANY PEOPLE HAVEN'T 
SEEN IT. SO YOU WILL HAVE TO WAIT 
A MOMENT TO SEE WHETHER I CAN GET 
IT GOING. BASICALLY I HAVE JUST 
DONE THE KEYNOTE AND WE'LL BE LUCKY 
IF WE CAN GET IT GOING. I WILL COME 
BACK TO THAT IN JUST A MOMENT. SO 
WHAT I AM GOING TO DO WHILE THAT 
IS LOADING, WHILE THAT IS RUNNING, 
I AM GOING TO -- LET ME JUST -- 
SORRY. I APOLOGIZE. SO ONCE THAT 
IS RUNNING I'M GOING TO INTRODUCE 
THE CONCEPT TO YOU. SO UP UNTIL 
LAST SUMMER IN POWER BI THE DATA 
SET HAD TO BE IMPORT OR QUIET QUERY. 
BOTH FLAVORS IT IS STILL LIKE THIS. 
SO THE WHOLE MODEL IS QUIET DIET 
QUERY. IT IS ACTING AS A VIRTUAL 
META DATA LAYER. IT WILL TAKE QUERIES 
GENERATED BY USERS INTERACTING WITH 
POWER BI AND TRANSLATE THEM TO THE 
NATAL SQL CON DEVELOPMENT OF WHATEVER 
THE DIRECT QUERY SOURCE IS AT RUN 
TIME. WHEREAS. PORT YOU WOULD CACHE 
ALL OF THE DATA IN MEMORY. WE USE 
OUR IN MEMORY CACHE AND. SO IMPORT 
GIVES YOU BLAZING FAST PERFORMANCE. 
I THINK IT IS FAIR TO SAY, I DON'T 
HAVE ANY BENCHMARKS TO QUOTE. YET 
THERE ARE SOME SPECIFIC CASES WHERE 
YOU NEED TO OPTIMIZE CERTAIN CALCULATIONS 
TO BE EFFICIENT. FRUSTRATION AGGREGATION 
S IN MY OPINION WE HAVE THE FASTEST 
BI ENGINE ON THE PLANET. BUT THE 
PROBLEM WAS THAT FOR A LARGE DATA 
SET YOU HAD TO FIT ALL OF THE DATA 
INTO MEMORY. RIGHT? SO YOU WOULD 
NEED A LOT OF MANAGEMENT AND IT 
WAS A LOT OF MANAGEMENT OVERHEAD 
AS WELL. YOU WOULD HAVE TO REPLICATE 
THAT INTO MEMORY AND USE -- YOU 
COULD USE INCREMENTAL REFRESH TO 
MAKE IT EASIER BUT YOU HAD TO MANAGE 
THAT. AS OF LAST SUMMER WE INTRODUCED 
COMPOSITE MODELS. THIS IS COMPOSITE 
MODELS THERE ARE DIFFERENT DEFINITIONS 
OF COMPOSITE MODELS. AS I AM DESCRIBING 
IT LET'S US MIX DIRECT QUERY AND 
IMPORT TABLES IN THE SAME MODEL. 
THAT IS THE MAIN THING. IT ALSO 
LET'S YOU HAVE MULTIPLE DIET QUERY 
SOURCES. THE ONE I AM FOCUSING ON 
IS IMPORTS AND QUIET QUERY IN THE 
SAME MODEL. YOU COULD PICK AN CHOOSE 
WHICH TABLES TO IMPORT TO GIVE YOU 
A MUCH BETTER BANG FOR YOUR BUCK. 
YOU COULD OPTIZE FOR YOUR EXECUTIVE 
DASHBOARD. YOU COULD LEAVE NEAR 
REALTIME TABLES IN DIET QUERY SO 
YOU WOULDN'T NEED TO REFRESH THEM. 
AND THEN ON TOP OF THIS WE INTRODUCED 
THE AGGREGATIONS FEATURE WHICH LET'S 
YOU CREATE ANOTHER TABLE IN THIS 
CASE SALES AG WHICH IS AN AGGREGATION 
OF SALES SO. LET'S SAY WE TAKE THE 
SUM OF SALES. WE GROUP BY DATE ED 
AND GEOGRAPHY ID. WE GET A FEW MILLION 
INSTEAD OF 10 BILLION THAT IS A 
LOT EASIER TO OPTIMIZE AND CACHE 
NO MEMORY. NOW ANY QUERIES GENERATED 
BY USERS INTERACTING WITH VISUALS, 
AS USERS INTERACT WITH POWER BI 
IT WILL GENERATE BACK QUERIES TO 
THE DATA SET UNDER THE COVERS AN 
THEN ANALYSIS SERVICES WILL DEPENDING 
ON WHETHER IT IS IN DIET QUERY MODE 
OR IMPORT IF IT IS IN IMPORT GET 
THE DATA FROM THE CACHE. HIT THE 
CACHE IT IS GROUPING BIER AND CITY 
WHICH IS THIS DARK GREEN SHADE. 
AND THEN WE THEN SAY ACTUALLY I 
WANT TO GROUP IT BY CUSTOMER NAME 
NOW. CUSTOMER IS NOT AT THE GRANULARITY 
BUT CAN HIT CACHE. THE TABLE WILL 
HAVE ONE ROW IN THE GEOGRAPHY TABLE. 
THERE WOULD BE MULTIPLE CUSTOMERS 
IT WOULDN'T KNOW WHICH TO AGRICULTURE 
GATE TO. IT WOULD REVERT TO DIRECT 
QUERY. THE USER KNOWS NOTHING ABOUT 
THIS. THIS IS COMPLETELY ABSTRACTED 
FROM THE USER. THE USER JUST KNOWS 
THAT THEY GET BLAZING FAST PERFORMANCE 
FOR THE MAJORITY OF THE QUERIES. 
WHEN THEY DRILL DOWN TO THE DETAIL 
LEVEL THERE MAY BE A PERFORMANCE 
SLIGHT PERFORMANCE HIT, BUT GENERALLY 
YOU WOULD WANT THAT HAPPEN IN A 
CONTROLLED WAY DRILL THROUGH SCENARIO. 
WITH BI QUERIES YOU WILL GET A HIGH 
AGGREGATION HIT RATE BECAUSE MOST 
BI QUERIES ARE CONSIDERING GATED. 
YOU CAN DESIGN THIS TO REALLY GET 
GOOD AGGREGATION HIT RATES. YOU 
WILL NOTICE WHEN I WAS IN IMPORT 
WHEN I WAS GROUPING BY YEAR AND 
CITY, THE DATE TABLE WAS DARK GREEN 
TO REPRESENT BEING AN IMPORT TABLE. 
AND THEN WHEN IT SWITCHED TO QUIET 
QUERY. THE DATE TABLE IS DYNAMICALLY 
SWITCHED TO BE DIRECT QUERY. SO 
THE DATE TABLE HAS A JEWEL STORAGE 
MODE. THIS IS MORE EFFICIENT SO 
THAT WHEN IT SWITCHES TO DIET QUERY 
AND CAN PUSH THAT DOWN TO THE SOURCE. 
THEY HAVE A DUAL STORAGE MODE CLEAR? 
ANY QUESTIONS? YES THE QUESTION 
WAS DO DATES HAVE TO BE IN THE SAME 
SOURCE. YES, IT DOES. IT WOULD BE 
THE SAME AS IF DATE WAS DIRECT QUERY 
FROM A DIFFERENT SOURCE THAT WOULD 
BE DEEMED A WEAK RELATIONSHIP AS 
WELL. SO IT'S GOT TO BE FROM THE 
SAME SOURCE FOR IT TO BE CONSIDERED 
A STRONG RELATIONSHIP. I ACTUALLY 
HAVE A SLIDE REALLY QUICKLY TO ANSWER 
THAT. THIS ONE. THIS WOULD BE DEEMED 
WEAK IT WOULD NOT PUSH DOWN TO THE 
SOURCE. IF WE MAKE DATE JULIA ASSUMING 
DATE IS FROM THE SAME SOURCE IT 
COULD PUSH THAT SUM GROUP DOWN TO 
THE SOURCE. SO IF IT WAS FROM A 
DIFFERENT SOURCE IT WOULD HAVE TO 
DO A JOINT ON THE POWER BI SIDE. 
IT WOULD PUT A BUNCH OF FILTERS 
IN BASED OFF THE PRIVACY LEVELS 
AND IT WOULD NOT BE A STRONG RELATIONSHIP. 
WE NEED IT TO BE A STRONG RELATIONSHIP 
TO BE OBSERVED FOR AGGREGATIONS. 
HERE BASICALLY AS LONG AS IT IS 
A SINGLE SOURCE THE TABLE ON THE 
ONE SIDE WHICH IS TYPICALLY THE 
DYNAMIC TABLE IS THE ONE THAT IS 
JEWEL. ANY OTHER QUESTIONS? LET'S 
SEE HOW WE ARE DOING. YES, YOU CAN 
ASK A QUESTION. IT SOUNDS LIKE YOU 
HAD AN EXPRESSION THAT WAS NOT BEING 
FOLDED WHERE IT WAS PULLING MORE 
DATA THAN WAS NECESSARY. OKAY. YEAH. 
OKAY. I MEAN, I'M AFRAID WE WOULD 
HAVE TO LOOK UP THAT ONE ON A CASE-BY-CASE 
CASES. EACH HAVE DIFFERENT QUERY 
FOLDING CAPABILITIES. THE OPT UM 
IS THAT IT PUSHES AS MUCH OF THE 
LOGIC DOWN TO THE SOURCE. THERE 
ARE RULES WHEN IT CAN AND CAN'T 
DO THAT. THERE ARE OPTIMIZATIONS 
TO GET AROUND THAT. IT WOULD TAKE 
A WHILE TO GET NO THAT I'M AFRAID. 
IT WOULD CONDITIONED ON THE SOURCE. 
SQL SOURCES PUSH THAT LOGIC DOWN 
TO THE SOURCES CLEANER THAN OTHER 
SOURCES GENERALLY. WE WOULD HAVE 
TO LOOK AT IT ON A CASE BY CASE 
BASIS I'M AFRAID. I AM GOING TO 
JUST GO AHEAD AND I'M GOING TO GO 
AHEAD AND JUST SHOW YOU HOW TO SET 
UP AGGREGATIONS ON A RELATIONAL 
SOURCE. OKAY? THEN I WILL SHOW US 
THE RLESS FEATURES. GIVE ME ONE 
SECOND HERE. YOU COULD CERTAINLY 
CHOOSE YOUR OWN COLOR FOR THE REPORT 
AS WILL SHOWED IN A SESSION THAT 
WILL BE LIKE IN POWERPOINT. YOU 
CAN HOVER OVER AND IT UPDATES THE 
COLOR PALLET AND YOU CAN SET THE 
FONTS AND EVERYTHING MUCH MORE EASILY. 
FOR THE FRAME, I BELIEVE THAT'S 
GOING TO BE THIS GRAY NOW. OKAY. 
SO ALMOST THERE. I CAN TAKE ANOTHER 
QUICK QUESTION IF YOU WANT. YES, 
GO AHEAD. SORRY, DO YOU MIND? IS 
THERE A MIC? I CAN'T REALLY HEAR 
THE PERSON. SORRY. >> WE HAVE PRETTY 
LARGE RELATIONAL DATABASES. ONE 
THING THAT HAS KEPT US AWAY FROM 
POWER BI OFFERS WE CAN DO COMPLEX 
CHARTS. JOINTS. >> ARE YOU TALKING 
ABOUT FOR DIRECT QUERY OR IMPORT? 
>> ARE YOU TALKING ABOUT MULTI DIMENSIONAL? 
IS IT SO YOU ARE NOT USING MULTI 
DIMENSIONAL. >> COMPOSITE KEY JOINTS. 
>> IT IS ON THE BACKGROUND. >> YOU 
CAN DO COMPOSITE KEY JOINTS AND 
TABULAR ON DIRECT QUERY. THERE IS 
A BACK FUNCTION. INTO ONE COLUMN 
AND YOU DO A JOIN. THAT YOU WOULD 
COULD IN IMPORT WORK. WORK TERRIBLY 
IN DIRECT QUERY MODE. IF YOU LOOK 
UP COMPOSITE KEYS IT SHOULD COME 
UP. IF YOU USE THAT DAX TO PUT NO 
ONE COLUMN IT WILL LOOK THE SAME 
IN THE MODEL. COLONEL GENERATE AS 
A COMPOSITE CO-AND PERFORM A HECK 
OF A LOT BETTER. >> OKAY, WE WILL 
MOVE ON AND THEN WE WILL TAKE SOME 
MORE QUESTIONS. SO I HAVE GOT THIS 
MODEL WHICH IS A DYNAMIC MODEL IN 
CASE YOU ARE MA'AM WITH IT. I HAVE 
GOT THIS AGGREGATION TABLE. THIS 
HAPPENS TO BE POPULATED IN THE SQL 
DATABASE, PRE-PREPARED AGGREGATION 
TABLE. AND I JUST RAN THE GET DATA 
WIZARD AN BROUGHT IN THESE TABLES. 
EVERYTHING IS DIRECT QUERY RIGHT 
NOW. YOU CAN SEE HERE FOR EACH TABLE 
THEY ARE ALL DIRECT TABLE. I HAVEN'T 
GOT ANY AGGREGATIONS DEFINED ON 
THIS MODEL AT ALL. OR ON THIS DATA 
SET. SO I HAVE GOT A QUERY HERE 
THAT IS ASKING FOR THE SUM OF CELLS 
GROUPED BY YEAR. OKAY? AND AS YOU 
CAN SEE IT IS RUNNING IN DIRECT 
QUERY. IT IS QUERYING THE INTERNET 
CELLS WHICH IS THE SALES TABLE WHICH 
IS SUPPOSEDLY THE 10 BILLION ROWS. 
IT DOESN'T HAVE SO BILLION ROWS 
IN IT. IT RAN QUICKLY. IF IT DID 
IT WOULD RUN SLOW AN REQUIRE OPTIMIZATION. 
SO THE AGGREGATION TABLE IS AN AGGREGATION 
OF THE SALES TABLE. IMAGINE I DO 
A SUM GROUP BY THE CUSTOM ID, DATE 
ID AND PRODUCT SUBCATEGORY ID. I 
WILL HAVE MANY LESS ROWS IN HERE. 
I WILL GO AHEAD AND JUST SET UP 
-- JUST ONE SIMPLE AGGREGATION FOR 
NOW. I'M GOING TO SAY -- THESE ARE 
ALL OF THE COLUMNS IN THE AGGREGATION 
TABLE. YOU CAN JUST ABOUT THESE 
CEASE COLUMNS HERE. SO THOSE ARE 
THE SAME COUPLES LISTED HERE. SO 
THE SUM OF SALES AMOUNT IS THE AMOUNT 
FROM THE SALES TABLE. I WILL SET 
IT UP AS THE SUM FROM THE SALES 
TABLE OF THE SALES AMOUNT COLUMN 
YOU WILL NOTICE I AM GETTING THIS 
MESSAGE NOW. THIS IS ONLY IN THE 
JULY DESK TOP RELEASE THAT YOU WILL 
SEE THIS MESSAGE. IT IS SAYING THAT 
IT WILL SET THE AGGREGATION TABLE 
TO HIDDEN FOR ME. BEFORE IT WAS 
A BEST PRACTICE TO ALWAYS SET TO 
TO HIDDEN. IN THE JULY RELEASE IT 
IS MORE THAN A BEST PRACTICE. THE 
HIDDEN PROPERTY IS OPTIONAL. IF 
A NON-ADMIN USER QUEER EARS THE 
AGGREGATION TABLE WE USE OBJECT 
LEVEL SECURITY TO MAKE IT NOT ADDRESSABLE. 
A NON-ADMIN REQUEST NOT EVEN QUERY 
A AGGREGATION TABLE. I WILL COME 
BACK TO THIS IN A LITTLE BIT. IT 
WILL SET THE TABLE TO HIDDEN FOR 
ME WHICH IS A GOOD INDICATION OF 
THE FACT THAT I SHE NOT BE EXPOSING 
DATA FROM IT DIRECTLY TO THE END 
USERS. IT'S THERE. AS YOU CAN SEE 
IT GOT HIDDEN FOR ME. IT'S THERE 
AS A PERFORMANCE OPTIMIZATION. ALL 
RIGHT? OKAY. SO I SET THAT UP. NOW 
I'M GOING TO GO AHEAD AND RUN THE 
SAME QUERY AGAIN. I GET BACK THE 
SAME RESULTS BUT THIS TIME THAT 
STUDIO IS NICE ENOUGH TO TELL ME 
THAT I GOT AN AGGREGATION HIT. IF 
WE LOOK AT THE SQL THAT WAS SUBMITTED 
IT IS GETTING DATA A FROM THE AGGREGATION 
TABLE INSTEAD. SO EVERYTHING IS 
IN DIRECT QUERY MODE. BUT THE ENGINE 
REDIRECTED TO THE AGGREGATION TABLE 
IN DIRECT QUERY MODE. OKAY? SO IF 
YOU THINK ABOUT THIS, THIS ALONE 
EVEN WITHOUT IMPORT IS ALREADY VERY 
USEFUL. YOU COULD OPTIZE THE AGGREGATION 
TABLE IN YOUR DATA WAREHOUSE OR 
IN YOUR SOURCE SYSTEM MUCH MORE 
EASILY. IT WILL HAVE FAR LESS ROWS 
IN IT. IT COULD BE A MATERIALIZED 
VIEW. IF YOU HAVE NEAR REALTIME 
REQUIREMENTS YOU COULD HAVE YOUR 
MATERIALIZED VIEW SHOW THE CHANGES 
TO THE 10 BILLION ROW TABLE INSTANTLY 
WITHOUT HAVING TO REFRESH THAT DATA 
INTO POWER BI. SO IT IS REALLY GOOD 
FOR THOSE REALTIME REQUIREMENTS 
AND YOU CAN OPTIMIZE IT USING COLUMN 
SCORE ET CETERA. A LOT EASIER THAN 
YOU COULD A 10 BILLION ROW FACT 
TABLE AND YOU CAN DESIGN IT TO CATCH 
THE MAJORITY OF QUERIES WITH IT. 
ALL RIGHT? MAKE SENSE? I'M NOW GOING 
TO GO AHEAD AND SET THE STORAGE 
MODE OF THIS TABLE TO IMPORT. SO 
IT IS TELLING ME IF I AM GOING TO 
SET THIS TO IMPORT IT IS RECOMMENDING 
THAT I ALSO SET THE RELATED DIMENSION 
TABLES TO DUAL. DUAL IS WHAT WE 
DISCUSSED EARLIER IN THE SLIDES. 
IT FIGURED OUT THE MINIMUM SET THAT 
NEED TO BE SET TO JEWEL ON THE ONE 
SIDE OF ONE TOM RELATIONSHIPS. IT 
IS OFFERING TO SET THOSE. IF WE 
GO WITH THE DEFAULT IT WILL BE FINE 
AND WE WILL KEEP THE STRONG RELATIONSHIP 
THAT'S WE WERE TALKING ABOUT EARLIER 
SO THEY WILL BE OBSERVED FOR AGGREGATION 
HITS. OKAY? IF I HAD A BIG DIRECT 
QUERY MODEL WITH A HUNDRED TABLES 
AND CACHE A COUPLE OF TABLES POWER 
DESK TOP WOULD FIGURE OUT THE NUMBER 
OF TABLES TO SET TO JEWEL FOR ME. 
SO IT IS USEFUL FOR -- YOU COULD 
ARGUE THAT IT IS ARGUE THAT IT IS 
POWER BI. IT RUNS ON THE BACK END. 
BUT IT IS NOT ENABLED IN AZURE SERVICES 
FLAVORS OF MODELS. SO THAT'S THE 
SUMMARY OF IT. OKAY? AT THIS POINT 
I DID. WHEN I HAD IT AS QUIET CHEERY 
THAT'S WHY I CALLED IT OUT. WHEN 
I WAS IN DIET QUERY THE AGGREGATION 
TABLE ITSELF WAS IN DIET QUERY THAT 
COULD BE ON MATERIALIZED VIEW OR 
SOMETHING THAT WOULD BE EASIER TO 
KEEP IN SYNC, NOW THIS IS GOING 
TO BE IMPORT I AM RESPONSIBLE FOR 
MAKING SURE THAT I AM GOING TO MEET 
MY BUSINESS REQUIREMENTS AND THE 
DATA WILL BE KEPT IN LINE WITH THE 
BUSINESS REQUIREMENTS. IF I AM DOING 
A LOAD ONCE PER NIGHT IT WON'T BE 
A PROBLEM. IF I HAVE CHANGES DURING 
THE DAY I MAY NEED TO USE ROW VERSIONING 
SORE SOMETHING LIKE THAT SO THE 
DATA IS UPDATED THE DIET QUERY AND 
IMPORT QUERIES AT THE SAME TIME. 
OKAY? YOU DO NEED TO MANAGE THAT. 
THAT IS A CONSIDERATION WHEN YOU 
HAVE THE IMPORT AGGREGATION TABLE. 
BUT THIS IS GOING TO BE THE FASTEST 
PERFORMANCE. RIGHT? SO THIS IS NOW 
IMPORT. NOW IF I RUN THIS QUERY 
AGAIN WE STILL GET A HIT. THIS TIME 
WE GOT THE DATA FROM IMPORT INSTEAD 
OF A DIET QUERY THIS IS A SCAN. 
THAT IT USE TODAY RETRIEVE DATA 
FROM THE STORAGE ENGINE. IF I SWITCH 
TO THIS QUERY THIS CANNOT HIT THE 
CACHE. THIS IS GROUPED BY PRODUCT 
NAME INSTEAD OF BIER. SO JUST LIKE 
IN THE SLIDES ONE ROW WILL HAVE 
ONE ROW IN PRODUCT CATEGORY. LET 
ME ZOOM IN A BIT. I CAN'T SEE IT 
MYSELF. WILL HAVE ONE ROW IN PRODUCT 
CATEGORY. MANY ROWS IN PRODUCTS 
IT WOULDN'T KNOW WHICH ROW IN THE 
PRODUCT TABLE TO AGRICULTURE GATE 
TO. SO THEREFORE IT SAYS SORRY I 
DIDN'T HIT THE CACHE AND IT REVERTED 
TO DIRECT QUERY AND IT IS QUERYING 
THE BIG 10 BILLION ROW TABLE. SO 
EVERYTHING IS WORKING AS DESIGNED 
RIGHT NOW. EVERYTHING YOU HAVE SEEN 
SO FAR IS THE WAY THAT IT WORKED 
IN PUBLIC PREVIEW AND HAS WORKED 
IN PUBLIC PREVIEW UNTIL NOW. SO 
EXCEPT FOR THE AUTO HIGH HIDING 
OF THE TABLE. WHAT I AM GOING TO 
SHOW NOW IS HOW IT WORKS WITH LOW 
LEVEL SECURITY THE NEW BIT. YOU 
CAN SEE THAT THERE ARE A TON OF 
OTHER FUNCTION THAT'S WORK WITH 
IT AS WELL. SO LET'S COME IN TO 
HERE AND I'M GOING TO SHOW YOU THE 
ROLES WE ARE HALFWAY. I GOT A ROLE 
HERE WITH NO FILTERS DEFINED ON 
IT AT ALL. I HAVE ALSO GOT ANOTHER 
BACK STUDIO INSTANCE HERE WHICH 
I AM GOING TO CONNECT AND I'M GOING 
CONNECT AS EXAMINE PER ONATING A 
USER THAT IS A MEMBER OF AGS TEST. 
HOPEFULLY THIS WILL WORK. ALL RIGHT. 
JUST ONE SECOND. I AM I AM PER ON 
ATE A USER THAT IS A MEMBER OF THAT 
ROLE. THEN WE'LL SET SOME FILTER 
S UP. OKAY. THAT'S THE ONE. SORRY. 
IN FACT, I CAN JUST USE THE PREVIOUS 
ONE. MANAGE ROLES EVEN THOUGH IT 
IS CALLED AGS. I AM I AM PER ON 
ATE A MEMBER OF THIS ROLE. SO THE 
TIMING AND RUN THE QUERY. SO RIGHT 
NOW THERE IS NO FILTERS. I AM SEEING 
THE CELLS FOR ALL OF THE COUNTRY 
REGION CODES. BY THE WAY, I GOT 
AN AGGREGATION HIT. THIS CAME FROM 
THE AGGREGATION TABLE. SO NOW I 
WILL SET UP A FILTER A FILL ON THE 
GEOGRAPHY TABLE. I AM GOING TO SAY 
MEMBERS OF THIS ROLE CAN ONLY SEE 
CELLS IF THEY ARE IN THE USE. THE 
GEOGRAPHY TABLE IF YOU WILL SEE 
HERE FILTERS THE CUSTOMER TABLE 
WHICH FILTERS BOTH THE AG TABLE 
AND THE SALES TABLE. SO THIS IS 
THE OPT ITEM SET UP FOR ILS. YOU 
NEED A FILTER THAT CAN GET TO BOTH. 
YOU WILL SEE WHY IN JUST A SECOND. 
GO AHEAD AND DO THAT. NOW IF I RUN 
THIS QUERY AGAIN YOU WILL SEE I 
CAN ONLY SEE THE CELLS IN THE USE 
AND IT STILL GOT AN AG HIT. IT SAID 
-- I WANT TO GET THE DATA FROM THE 
AGGREGATION DATA. I NEED TO BE ABLE 
TO APPLY THIS FILTER. THE FILTER 
CAN TILL TERRIBLE. SO IT WAS FINE. 
IT GOT THE DATA FROM THE FILTER. 
THIS IS WHERE IT IS MORE COMPLEX. 
IN MOST CASES OR PRETTY MUCH RECALL 
OF THE CASES THIS IS HOW YOU WOULD 
SET IT UP. SET IT UP SO THE FILTER 
CAN FILTER. IF YOU HAPPEN TO SET 
IT UP WITH A FILTER THAT CAN ONLY 
FILTER THE DETAIL TABLE LIKE SOMETHING 
ON THE PRODUCT TABLE CANNOT FILTER 
THE AG TABLE THEN THIS IS ACTUALLY 
LESS SALES THAN WE SAW A MOMENT 
AGO. THIS IS SALES IN THE U. S. 
BUT ONLY FOR RED PRODUCTS. WE DON'T 
HAVE THE ABILITY TO SEE THE NON-RED 
PRODUCTS. NOW IT ATTEMPTED TO HIT 
THE AGGREGATION BUT IT FAILED. AND 
THE IS IT WAS NOT ABLE TO APPLY 
THE FILTER. IT CAN'T APPLY THE FILTER 
TO THE AGGREGATION TABLE IT WOULD 
HAVE BEEN INSECURE TO GET THE DATA 
FROM THE TABLE. THIS SHOWS WHY WE 
HAVE MADE IT SO IF YOU ARE NOT AN 
ADMIN USER IF YOU ARE NOT ADMIN 
USER YOU CAN'T EVEN QUERY THAT AGGREGATION 
TABLE AT ALL. SO IN FACT, HERE IN 
DESK TOPIC IMPERSONATE A MEMBER 
OF THIS ROLE RIGHT HERE. IF I COME 
TO THE DATA VIEW I CAN SEE THE DATA 
EXCEPT IF I GO TO THE AD TABLE YOU 
CAN'T SEE ANY DATA IN THERE. SO 
A MEMBER OF THIS ROLE WOULD BE INSECURE 
TO LET THEM QUERY THE AGGRAVATION 
TABLE. IF YOU ARE NOT AN ADMIN USER 
AN AS ADMIN WHEN I AM DOING MODEL 
IN DESK TOP FOR VALIDATION AND TESTING 
PURPOSES BUT IF I AM ACCESSING THE 
DATA SET THROUGH A ROLE IN THE POWER 
BI SERVICE THEN I'M NOT AN ADMIN 
SERVICE AND I CAN'T QUERY THE ADMINISTRATION 
TABLE BECAUSE THERE COULD BE SECURITY 
ISSUES IF WE ALLOWED THAT. IF I 
AM SWITCHED BACK TO THE MODELER 
WHO IS AN ADMIN MODELER THEY CAN 
SEE THE DATA. MAKE SENSE? THE LAST 
CASE I HAVE GOT HERE IS WHAT IF 
I HAVE A FILTER THAT CAN FILTER 
THE AGGREGATION TABLE BUT NOT THE 
DETAIL TABLE? SO THIS ONE ACTUALLY 
MAKES NO SENSE WHATSOEVER BECAUSE 
YOU KNOW THE USERS CAN SEE THE BIG 
SALES TABLE. I HAVE ANOTHER VERSION 
OF THAT SAME DATA IN THE AGGREGATION 
TABLE WHICH IS SECURED. THEY CAN'T 
EVEN ACCESS IT. IT MAKES NO SENSE. 
SO WE ARE SAYING YOU KNOW WHAT, 
WE'RE NOT GOING TO ALLOW THIS. SO 
THERE IS A VALIDATION THAT SAYS 
YOU CAN'T EVEN SET THIS UP. OKAY. 
THAT'S IT. THAT IS THE MOST COMPLEX 
PART OF AGGREGATIONS IN MY OPINION 
HOW IT INTER GREATS WITH IRS. THERE 
ARE A LOT OF QUESTIONS -- WE HAD 
TO MAKE A LOT OF DECISIONS WHETHER 
WE ALLOW ACCESS OR NOT. WE BASICALLY 
TOOK THE STRICTEST APPROACH. THIS 
IS SECURITY WE TAKE SECURITY SERIOUSLY. 
WE HAVE TAKEN A STRICT APPROACH 
TO IT. THAT'S HOW IT PLAYS. 99 OF 
THE CASES YOU WOULD BE FINE YOU 
WOULD MAKE SURE IT CAN BE APPLIED 
TO BOTH THE AG TABLE AND DETAIL 
TABLE. ANY QUESTIONS? >> SO THE 
QUESTION WAS, IS THERE ANY WAY OF 
PRODUCING A LOG OF IRS BEING APPLIED 
WHEN INCOMING QUERIES COME IN. CORRECT? 
SO THERE IS ANALYSIS SERVICES AND 
IN AZURE SERVICES WE HAVE AZURE 
DO I NOT LICK LOGGING THAT PROVIDES 
THAT LEVEL OF DETAIL. THIS IS SOMETHING 
THAT WE HAVE ON THE BACKLOG TO INTRODUCE 
THAT KIND OF GRANULAR LOGGING FOR 
POWER BI AS WELL. ONCE WE HAVE END 
POINTS WHICH WE WILL DISCUSS YOU 
COULD RUN SQL PROFILER AND CHECK 
SOME EVENTS THAT WAY. BUT THERE 
IS NO -- THERE IS NO EQUIPMENT OF 
AZURE DIAGNOSTIC IN AZURE TODAY 
THAT GIVES THAT YOU FINE LEVEL LOG 
IN THAT YOU CAN KEEP ALL OF THE 
LOGS ON YOUR INSTANCE FOR 30 DAYS 
OR WHATEVER YOU WANT. PROFILE OR 
SOMETHING LIKE THAT WOULD WORK. 
WITH POWER ABI THAT ALREADY WORKS. 
YES. ANY OTHER QUESTIONS? I WILL 
TAKE ONE QUESTION. SO THE QUESTION 
WAS IS THERE ANY PLAN ON THE ROAD 
MAP TO GET AGGRAVATIONS INTO ANALYSIS 
SERVICES? NOT CURRENTLY BECAUSE 
WE ARE FOCUS OWING ON GOING THE 
OTHER WAY. INSTEAD OF -- IF WE WERE 
TO -- WE WANT TO PUT ALL OF THE 
FUNCTIONALITY INTO BOWER BI TO HAVE 
A SINGLE INCLUSIVE PLATFORM. ANY 
WORK WE DO GOING THE OTHER WAY THERE 
IS SOMETHING THAT DIDN'T GET DONE 
FOR OUR CORE STRATEGY. UNFORTUNATELY 
NOT IN THE IMMEDIATE FUTURE. OKAY? 
SO THAT'S A GOOD QUESTION. SO THE 
QUESTION WAS AND CORRECT ME IF I 
AM WRONG THAT YOUR ORGANIZATION 
USES ANALYSIS SERVICES TO GET THE 
MAXIMUM REUSABILITY THAT SINGLE 
VERSION OF THAT TRUTH THAT SIMILAR 
ANTIC MODEL THAT IS REUSED THROUGHOUT 
YOUR ORGANIZATION. YOU WANT LOTS 
OF DIFFERENT REPORTS MAYBE NOT EVEN 
POWER BI YOU MIGHT BE USING EXCEL 
ET CETERA. TO ALL GET DATA FROM 
THE SAME SIMILAR ANTIC MODEL. WE 
RECOGNIZE THAT AS A CORE SCENARIO. 
ACTUALLY THAT ALREADY WORKS IN POWER 
BI WE LAUNCHED THE END POINTS WHICH 
IS THE NEXT SET OF SLIDES. THAT 
ALREADY GIVES YOU OPEN PLATFORM 
CONNECTIVITY FROM EXCEL AND EVEN 
OUR COMPETITOR BI PRODUCTS OUT THERE. 
PRETTY MUCH EVERY OTHER COMPETITIVE 
CONNECTS PRODUCTIVITY BECAUSE IT 
HAS BEEN A MARKET LEADER FOR 20 
YEARS. SO ALL OF THOSE CAN NOW CONNECT 
TO THE POWER BI DATA SET AS THOUGH 
IT WERE ANALYSIS SERVICES. THAT 
ALREADY HAPPENS TODAY. AND THEN 
LIKE WE SHOWED IN HIS SESSION WE 
HAVE GOT OTHER FEATURES IN THAT 
SPACE DATA SET SO I CAN HAVE A DATA 
SET IN POWER BI THAT IS CONSUMED 
FROM LOTS OF DIFFERENT REPORTS AND 
LOTS OF DIFFERENT WORK SPACES NOW. 
WE ARE OPENING IT UP JUST LIKE ANALYSIS 
SERVICES. OKAY? THAT IS ONE OF THE 
CORE SCENARIO. WE ARE DEFINITELY 
OPENING THAT UP IN POWER BI. SO 
THAT IS ALSO A GOOD QUESTION. USING 
THAT AZURE SERVICES? SO THE QUESTION 
WAS IS IT OKAY TO CONTINUE WORKING 
WITH AZURE AND AZURE SERVICES OR 
IS THAT MISALIGNED WITH THE ROAD 
MAP. JOSH MAY WANT TOY LANE ATE. 
THE WAY WE ARE WORKING ON THIS IS 
THAT IT WILL BE A CLEAN LIFT AND 
SERVICE. ONCE ALL OF THE REQUIRED 
FEATURES THAT YOU NEED LIKE OPEN 
PLATFORM CONNECTIVITY THAT IS ALREADY 
THERE. BUT SCALE BEYOND 10 GIGABYTES 
THAT WILL BE COMING SOON. IF YOU 
ARE WORKING ON AZURE SERVICES BECAUSE 
YOU NEED ONE OF THOSE FEATURES THAT 
ISN'T THERE YET IN POWER BI. KEEP 
CHECKING. ONCE IT IS READY IN POWER 
BI CHANGE THE SERVER NAME TO WORK 
SPACE URL WILL WORK THE STABLE WE 
WILL ENABLE SQL SERVER DATA TOLLS 
FOR THOSE LIFT AND SHIFT SCENARIOS. 
>> WE ARE DOING DEVELOPMENT. WE 
ARE STILL DOING DEVELOPMENT ON AZURE 
SERVICES. TO THE NEXT FEW SLIDES 
THERE ARE FEATURES GOING OUT. ONE 
WAS ANNOUNCED TODAY. THIS PARTICULAR 
FEATURE IS NOT ON THE ROAD MAP FOR 
ARDS. THERE ARE OTHER THINGS. >> 
WE HAVE ONLY GOT 1 MINUTES GET. 
I BETTER GET TO THESE ANALYSIS FEATURES 
THEN WE WILL TAKE QUESTIONS AT THE 
END IF THAT'S OKAY? IT OKAY. SO 
OKAY. SO WE HAVE ALREADY DISCUSSED 
THAT. OPEN PLATFORM CONNECTIVITY. 
PERFECT SEGWAY YOU CONNECT TO A 
SERVER NAME USING A VARIETY OF CLIENT 
TOOLS FOR ANALYSIS SERVICES, MANAGEMENT 
TOOLS, PROFILER FOR DEBUGGING AND 
6 DATA TOOLS FOR REMODEL BEING. 
YOU WILL BE ABLE TO DO THE SAME 
WITH A POWER WORK BASE INSTEAD. 
THANK YOU. SO THE READ ONLY VERSION 
OF THIS IS ALREADY IN PUBLIC PREVIEW. 
THE READ-RIGHT WILL BE COMING SOON. 
-WR ITE WILL COME SOON. I WILL BUSINESS 
THROUGH THESE. IT GIVES YOU A VERY 
RICH PROGRAMMING MODEL USING OBJECT 
MODEL TELL ME THERE ARE COMMUNITY 
TOOLS THAT USE IT. AND SCRIPTING 
IS SCRIPTING LANGUAGE AND POWER 
SHOP COMMAND ALL OF THAT WILL PRETTY 
MUCH ALL OF THAT WILL MIGRATE OVER 
TO POWER BI. AND THEN WE INTRODUCED 
INCREMENTAL REFRESH WHICH I HAVE 
DISCUSSED BRIEFLY. THE DEAL WITH 
INCREMENTAL REFRESH I HAVE A BIG 
MODEL LIKE 50 BIG A BITES. IT DOESN'T 
MAKE SENSE. THAT COULD BE 10 TARA 
BITES IN ITS RAW FORM. IT DOESN'T 
MAKE SENSE TO REFRESH ALL OF THAT 
DATA EVERY TIME WE DO A REFRESH. 
I WANT TO REFRESH ONLY THE DATA 
THAT HAS CHANGED. THIS IS SOMETHING 
WE HAVE BEEN ABLE TO DO FOR 20 YEARS 
YOU WOULD HAVE TO RUN CODE OR SCRIPTS 
TO DO THAT. IN POWER BI WE HAVE 
IT SIMPLIFY TODAY A DIALOGUE THAT 
LET'S YOU PICK YOUR POLICY FOR I 
THINK MENIAL REFRESH. THE FIRST 
TIME YOU DO A REFRESH IT WILL TAKE 
LONG FOR REFRESH IT NEEDS TO LOAD 
THE HISTORY. SUBSEQUENT REFRESHES 
ARE GOING TO BE MUCH FASTER. BECAUSE 
IT WILL ONLY LOAD THE DATA THAT 
HAS CHANGED. ALL RIGHT? AND THEN 
CRAWL BEINGLATION GROUPS. SO WHO 
HERE HAS SCENE CALCULATION GROUPS 
AND ERRED HEARD OF CALCULATION? 
NOT THAT MANY OF YOU. SO WHO HERE 
HAS USED MULTI DIMENSIONAL ANALYSIS 
SERVICES MULTI DIMENSIONAL? A HANDFUL 
OF YOU. SO MULTI DIMENSIONAL IS 
A VERY RICH, SIMILAR ANTIC MODELING 
TOOL THAT ONLY WORKS FOR SQL SERVICES 
ON PREM OR IAS. PROBABLY ONE OF 
THE MOST POWER FEATURES OF MULTI 
DIMENSIONAL IS CALCULATED MEMBERS 
TO REUSE CALCULATIONS IN COMPLEX 
MODELS. SO TABULAR HASN'T HAD THAT 
FUNCTIONALITY. SO WE HAVE HAD TO 
CREATE LOTS OF DIFFERENT MEASURES 
FOR EACH OF THE CALCULATIONS. SO 
WE LAUNCHED IT FOR SQL SERVICE ANALYSIS 
SERVICES IN THE CTP. IT IS IN PREVIEW 
RIGHT NOW CALCULATION GROUPS WHICH 
IS THE TAB LARRY WE HAVE LENT OF 
MULTI DIMENSIONAL CALCULATED MEMBERS 
AND AS OF TODAY, IT IS NOW OFFICIALLY 
SUPPORTED IN AZURE ANALYSIS SERVICES. 
OKAY? SO THE TOOLING STILL HASN'T 
BEEN DONE AND THAT WILL GET DONE 
BY THE TIME THE SQL SERVICE AND 
AZURE 2019 HITS RTM OR GENERAL AVAILABILITY. 
IN THE MEANTIME THERE ARE TOOLS 
LIKE TABLET EDITOR WHICH IS AN OPENSOURCE 
COMMUNITY TOOL THAT LET'S YOU OFFER 
GROUPS. SO THE CONCEPT IS -- SO 
IT'S GOING TO SHIP IN AZURE AS OF 
TODAY. IT WILL BE AVAILABLE IN POWER 
BI THROUGH THE END POINT. ONCE WE 
HAVE RED WRITE READ-WRITE. IF YOU 
ARE PARTICULARLY FAMILIAR WITH THESE 
COMPACT LEVELS. THE DEAL IS IF YOU 
HAVE A COMPLEX MODEL LET'S SAY YOU 
HAVE A HUNDRED BASE MEASURES LIKE 
CELLS AND OLD ACCOUNTS AND RESELLER 
CELLS. YOU HAVE THESE MEASURES. 
FOR EACH OF THEM YOU MIGHT HAVE 
SOME COMMON CALCULATION THAT'S NEED 
TO BE APPLIED LIKE THE CLASSIC ONES 
ARE THE TIME INTELLIGENCE YEAR OVER 
YEAR GROWTH ET CETERA. SO THE WAY 
YOU WOULD HAVE TO DO IT IN TABULAR 
AND POWER BI UP UNTIL CALCULATION 
GROUPS YOU WOULD HAVE TO CREATE 
SEPARATE MEASURES FOR EACH OF THEM. 
FOR CELLS AND ORDERS I WOULD HAVE 
ANOTHER SALES TO DATE MEASURE ET 
CETERA. SO YOU CAN SEE IT WILL EXPLODE 
THE NUMBER OF MEASURES DRAMATICALLY. 
IT WILL HAVE THIS PROLIFERATION 
WHICH WILL MAKE THE CONSUMPTION 
EXPERIENCE FOR USERS THEY WILL HAVE 
TO CYST THROUGH. IF YOU HAVE A HUNDRED 
BASE MEASURES AND YOU HAVE 10 OF 
THOSE REICABLE THAT WOULD BE A THOUSAND 
THEY HAVE TO CYST THROUGH. THE MANAGEMENT 
OVERHEAD IS A LOT WORSE TOO BECAUSE 
YOU WOULD HAVE TO MANAGE A THOUSAND 
MEASURES. WITH CALCULATION GROUPS 
WHAT YOU CAN DO IS YOU CAN DEFINE 
THAT LOGIC JUST ONCE. AS YOU CAN 
SEE IT LOCKS A LOT LIKE HOW YOU 
WOULD WRITE A MEASURE. IF I AM ABLE 
TO SWITCH THIS DISPLAY SETTING HERE. 
SO YOU CAN SEE THAT FOR EXAMPLE 
-- SWITCHING SORRY. THERE WE GO. 
SO FOR EXAMPLE IF I ZOOM IN -- I'M 
NOT SURE WHAT JUST HAPPENED THERE. 
OKAY. NOT TO WORRY. OH, DEAR. POWERPOINT 
IS NOT MY BEST FRIEND SOMETIMES. 
NOT TO WORRY. SO THE POINT IS THAT 
YOU DEFINE THOSE REUSABLE CALCULATIONS 
IN A VERY SIMILAR WAY TO HOW YOU 
WOULD DEFINE THEM BY CREATING A 
MEASURE. BUT THEY ARE NOW REUSABLE 
FOR ALL OF THE MEASURES. WHERE HAS 
IT GONE? HERE? YOU CAN EVEN OVERRIDE 
THE FORMAT SPRING. THIS IS AN ISSUE 
FOR POWER BI FOR A WHILE THAT YOU 
CAN'T HAVE REAL DYNAMIC STRINGS. 
THERE IS A FORMAT THAT YOU CAN USE 
TO RETURN A STRING THAT IS FORMATTED. 
BUT THEN YOU CAN'T USE THAT IN VISUALS 
THAT REQUIRE A NUMERIC TYPE. WITH 
CALCULATION GROUPS YOU CAN DEFINITELY 
DO THAT. YOU CAN SET THE DYNAMIC 
SPRING. IN THIS CASE I AM SETTING 
THE FORMAT OF THE YEAR OVER YEAR 
GROWTH PERCENTAGE TO BE A PERCENTAGE 
WHEREAS ALL OF THE OTHER ONES I 
DON'T SET THE FORMAT STRING SO THEY 
WILL INHERIT THE DATA TYPE OF THE 
BASE MEASURE IF I USE CELLS IT WILL 
SHOW THAT AS CURRENCY. ORDERS YEAR 
TO DATE IT WILL SHOW THAT AS INTEGER 
OR WHOLE NUMBER. YEAR OVER YEAR 
PERCENTAGE IT WILL ALWAYS SHOW IT 
AS PERCENTAGE. I DEFINED THESE ONCE 
THEY ARE REUSABLE FOR ALL OF THE 
MEASURES IN THE MODEL. THEN THE 
USER EXPERIENCE IS VERY SIMPLE BECAUSE 
THE CALCULATION GROUP IS PRESENTED 
AS A TABLE. YOU JUST DRAG THE COLUMN 
ON AND IT WILL JUST -- IT WILL REUSE 
THOSE CALCULATIONS FOR ANY OF THE 
MEASURES THAT WANT TO SUBSCRIBE 
TO IT. IF -- HERE I HAVE ONE. THIS 
IS A MATRIX I HAVE GOT CELLS. I 
DEFINED THAT CALCULATION GROUP THAT 
I SAW IN THE SLIDE. SO I HAVE GOT 
THE TIME INTELLIGENCE CALCULATION 
GROUP WITH A SINGLE COLUMN CALLED 
TIME CALCULATION IT IS A TABLE AND 
COLUMN TO THE USERS. THEY CAN DRAG 
IT ON TO THE COLUMNS OF THE MATRIX 
VISIBLE. NOW I GET ALL OF THE CALCULATIONS 
APPLIED. AGAIN I CAN USE THIS FOR 
ANY OF THE MEASURES IN MY MODEL. 
I DON'T NEED TO CLICK A THOUSAND 
MEASURES THIS IS USEFUL FOR THE 
COMPLEX MODELS. , YES, GO AHEAD. 
YES, IT WILL WORK WITH FISCAL CALENDARS. 
EVEN NON-TIME INTELLIGENCE SCENARIO 
USE IT. ALL RIGHT. AND JUST REALLY 
BRIEFLY, HOW MUCH TIME DO I GOT? 
I GOT 5 MINUTES. YES? SO THE QUESTION 
WAS IS THERE AZURE SERVICES OR IS 
IT -- AZURE SERVICES TODAY. THEY 
WILL BE SUPPORTED IN POWER BI WHEN 
THE READ WRITE CAPABILITY COMES 
IN THE NOT TOO DISTANT FUTURE. EVENTUALLY 
THEY WILL BE TOOLING FOR IT IN POWER 
BI. I CAN STAY BEHIND. I DON'T HAVE 
ANY COMMITMENTS. I CAN STAY FOR 
5 OR 10 MINUTES AT THE END. OTHERWISE 
I WILL RUN OUT OF TIME. I HAVE OTHER 
STUFF TO SHOW. I BITTER JUST RUN 
THROUGH THIS. I WOULD JUST LIKE 
TO SHOW YOU REALLY QUICKLY SOME 
OTHER MORE INTERESTING SCENARIOS 
YOU CAN USE IT FOR THINGS LIKE CURRENCY 
CONVERSION. IF I EDIT THIS . IF 
I BRING IN THE CURRENCY NAME ON 
TO THE COLUMNS IT GETS CONVERTED 
TO ALL OF THE REPORTING CURRENCIES. 
AND THIS IS NOT A STRING MEASURE 
THIS STILL WORKS WITH VISUALS THAT 
DEPEND ON NUMERIC DATA TYPES. OKAY? 
IS IT THANK YOU. I KNOW THIS HAS 
BEEN A PAIN POINT FOR A FEW PEOPLE. 
I HAVE ONLY GOT 3 MINUTES I WILL 
BUSINESS THROUGH THOSE FUNCTIONS. 
WHIZTHROUGH THOSE. THERE IS A GOOD 
SET OF DOCUMENTATION THERE. THE 
LAST THING I WANT TO SHOW IS A SUMMARY 
OF WHAT IS COMING AND WHAT IS NEW 
IN AZURE SERVICES 2019. SO WE JUST 
SAW CALL LACK GROUPS. MANY RELATIONSHIPS 
ARE BEING LAUNCHED TODAY THEY ARE 
BOTH ON THE AZURE BLOGS AS OF TODAY. 
MANY RELATIONSHIPS JUST LIKE CALCULATION 
GROUPS WILL BE SUPPORTED IN SSVT 
BY THE TIME SQL SERVICE 2019 GETS 
TO AVAILABILITY. IT IS FOR MULTI 
DIMENSIONAL ONLY. IT MEANS THAT 
IT SUPPORTS BETTER PERFORMERRING 
DEC QUERIES THAT THE POWER BI WILL 
AGAINER ATE. WE HAVE THE NEW DEC 
FUNCTIONS I WILL COVER THE RESOURCE 
GOVERANCE THIS IS ONE PIECE I WOULD 
LIKE TO COVER. THESE ARE SERVICE 
SETTINGS ON YOUR AZURE SERVER. SO 
YOU CAN SET THE REFRESH POLICY TO 
DISABLE BACKGROUND CASH REFRESHES 
TO POWER BI WHERE YOU HAVE SIMILAR 
ANTIC MODEL THAT IS REUSED ACROSS 
HUNDREDS OF REPORTS. EVERY TIME 
YOU DO A REFRESH ESPECIALLY DURING 
THE DAY EVERY TIME YOU DO A REFRESH 
POWER BI WILL TRY TO REFRESH ITS 
CACHES. YOU CAN SWITCH THAT OFF 
WITH THE CLIENT REFRESH POLICY. 
MEMORY MANAGEMENT HELPS PROTECT 
THE SERVER FROM RUN AWAY QUERIES 
AND THESE BIG EXTRACT QUERIES AND 
MILLIONS OF ROWS. THIS IS BRAND 
NEW. WE HAVEN'T ANNOUNCED THIS OR 
LET ANYONE KNOW ABOUT THIS YET. 
WE ARE LAUNCHING QUERY INTER LEAVING 
IN THE NOT TOO DISTANT FUTURE. SERVER 
SETTINGS SO THE MAIN ONE WILL BE 
SCHEDULE AND BEHAVIOR TO EXPLAIN 
HOW THIS WORKS. TODAY IF YOU HAVE 
VERY CPU INTENSIVE QUERIES FOR ANALYSIS 
SERVES AND YOU NEED TO KNOW IT IS 
NOT ALL QUERIES THAT TAKE LONGER. 
THERE ARE LOTS OF DIFFERENT REASONS 
FOR CPU INTENSIVE QUERIES IT IS 
BASICALLY FIRST IN FIRST OUT. YOU 
HAVE QUERY RUN RUNS FOR A LONG TIME. 
QUERY 2 AND 3 ARE SUBMITTED AFTER 
THE QUERY 1 START. THEY HAVE TO 
WAIT UNTIL QUERY 1 IS FINISHED UNTIL 
THEY CAN GET TO THE CPU. THEN THEY 
GET BLOCKED. WHEREAS WITH QUERY 
INTERLEAVING THEY WILL SHARE THE 
CPU RESOURCES. THE POINT AT WHICH 
ALL 3 ARE FINISHED IS THE SAME POINT 
AS BEFORE. BUT QUERIES 2 AND 3 GET 
TO FINISH A LOT EASIER. THEY GET 
TO SHARE THE CPU. THAT IS QUERY 
INTERLEAVING IT IS WITH SHORT QUERY 
BIAS. THE KEY FAULT SETTINGS THERE 
WILL BE SOME OTHER SETTINGS. THE 
DEFAULT AS SOON AS YOU SCHEDULE 
ON BEHAVIOR IT WILL BE ENABLED FOR 
SHORT QUERY BIAS. QUERY 1 IS RUNNING 
FOR A WHILE BEFORE QUERY 2 AND 3 
COME IN. I WILL GIVE MORE RESOURCES 
TO QUERY 2 AND 3 BECAUSE I WILL 
ASSUME THAT THEY ARE FAST QUERIES. 
THEY ARE ASSUMED FAST UNTIL PROVEN 
SLOW. SO THE IDEA IS WHEN YOU GOT 
A ICIER ON A DASH BOARD SUBMITTING 
A TON OF QUERIES MOST WOULD BE FAST 
QUERIES WE WANT TO ANSWER THOSE 
WITHOUT BLOCKING THEM. ALL OF THIS 
WILL BE COMING IN THE NOT TOO DISTANT 
FUTURE FOR AZURE SERVICES WE WILL 
SEE IF WE CAN GET IT IN SQL. THANK 
