Релатионсхипс анд Повер Пивот

Не морате да будете стручњак за моделирање базе података да бисте користили Повер Пивот. Али важно је разумети односе. Што боље разумете како се подаци чувају и како се њима управља у базама података, ефикасније ћете користити Повер Пивот за извештавање.

Однос је механизам којим одвојене табеле су повезани једни са другима. Однос можете замислити као ВЛООКУП, у којем повезујете податке у једном опсегу података са подацима у другом опсегу података користећи индекс или јединствени идентификатор. У базама података, односи раде исту ствар, али без муке са писањем формула.

Односи су важни јер се већина података са којима радите уклапа у неку врсту вишедимензионалне хијерархије. На пример, можда имате табелу која приказује купце који купују производе. Ови купци захтевају фактуре које имају бројеве рачуна. Те фактуре имају више редова трансакција у којима је наведено шта су купили. Тамо постоји хијерархија.

Сада, у свету једнодимензионалних табела, ови подаци би обично били ускладиштени у равној табели, као што је ова приказана овде.

Подаци се чувају у Екцел табели користећи равну табелу.

Пошто клијенти имају више од једне фактуре, информације о клијенту (у овом примеру, ЦустомерИД и ЦустомерНаме) морају да се понове. Ово узрокује проблем када се ти подаци морају ажурирати.

На пример, замислите да се име компаније Аарон Фитз Елецтрицал промени у Фитз анд Сонс Елецтрицал. Гледајући табелу, видите да више редова садржи старо име. Морали бисте да се уверите да је сваки ред који садржи старо име компаније ажуриран како би одражавао промену. Сви редови које пропустите неће се исправно пресликати на правог купца.

Зар не би било логичније и ефикасније да се само једном запише име и информације о купцу? Затим, уместо да морате стално да пишете исте информације о клијенту, можете једноставно имати неки облик референтног броја клијента.

Ово је идеја која стоји иза односа. Можете одвојити купце од фактура, стављајући сваког у своје табеле. Затим можете користити јединствени идентификатор (као што је ЦустомерИД) да бисте их повезали заједно.

Следећа слика илуструје како би ови подаци изгледали у релационој бази података. Подаци би били подељени у три одвојене табеле: Купци, ИнвоицеХеадер и ИнвоицеДетаилс. Свака табела би тада била повезана коришћењем јединствених идентификатора (ЦустомерИД и ИнвоицеНумбер, у овом случају).

Базе података користе односе за складиштење података у јединственим табелама и једноставно повезују ове табеле једне са другима.

Табела Купци би садржала јединствени запис за сваког купца. На тај начин, ако треба да промените име клијента, требало би да промените само тај запис. Наравно, у стварном животу, табела Купци би укључивала друге атрибуте, као што су адреса клијента, број телефона клијента и датум почетка корисника. Било који од ових других атрибута се такође може лако ускладиштити и управљати у табели купаца.

Најчешћи тип односа је однос један-према-више . То јест, за сваки запис у једној табели, један запис се може упарити са више записа у засебној табели. На пример, табела заглавља фактуре је повезана са табелом детаља фактуре. Табела заглавља фактуре има јединствени идентификатор: Број фактуре. Детаљи фактуре ће користити број фактуре за сваки запис који представља детаљ те конкретне фактуре.

Друга врста односа је однос један-на-један : за сваки запис у једној табели, један и само један подударни запис налази се у другој табели. Подаци из различитих табела у односу један-на-један могу се технички комбиновати у једну табелу.

Коначно, у односу више према много , записи у обе табеле могу имати било који број подударних записа у другој табели. На пример, база података у банци може имати табелу различитих врста кредита (стамбени кредит, кредит за аутомобил и тако даље) и табелу клијената. Клијент може имати много врста кредита. У међувремену, свака врста кредита може бити одобрена многим клијентима.