Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Inkrementalno punjenje za BI

[es] :: IS i ERP :: Inkrementalno punjenje za BI

[ Pregleda: 3819 | Odgovora: 16 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

radenko
Ivan Radenkovic
bg

Član broj: 11979
Poruke: 95
*.imlek.co.yu.

Sajt: www.radenkovich.com


+1 Profil

icon Inkrementalno punjenje za BI09.11.2007. u 08:55 - pre 179 meseci
Da li neko zna da predlozi kako projektovati DTS paket ili Stored Procedure za inkrementalno punjenje SQL baze podataka koja se koristi za potrebe Business Inteligence-a, a pritom postoji ogranicenje da ne smeju nikakve izmene i dorade da se vrse nad originalnom tabelom.
Za primer neka posluzi tabela faktura u programu za fakturisanje, a SQL sadrzi istu tu tabelu koju treba dopunjavati novim fakturama? Ne ocekujem resenje korak-po-korak, vec vise koji pristup mislite da je najefikasniji?...
Ivan Radenkovic
www.radenkovich.com
 
Odgovor na temu

rlj77
Ristanović Ljubo
Beograd

Član broj: 22047
Poruke: 7
*.ikomline.net.



Profil

icon Re: Inkrementalno punjenje za BI25.11.2007. u 18:51 - pre 179 meseci
Bilo bi dobro da imaš u tabelama neki inkrementalni brojač ili nešto što liči na to npr. broj dokumenta, naloga za knjiženje itd.
Prilikom svakog pokretanja DTS-a negde zapisati koji je poslednji zapis u pojedinoj tabeli, naravno ta informacija bi figurisala u uslovu za čitanje svake pojedine tabele. Sa izmenjenim zapisima tj update-ima malo je teže. Ako ništa od gore navedenog ne pomaže, preostaje samo da praviš kopije tabela iz kojih prebacuješ podatke u kocke, potrebno je svaki put gledati razlike tj. prebaciti razlike u pomoćne tabele odnosno u kocke.
 
Odgovor na temu

radenko
Ivan Radenkovic
bg

Član broj: 11979
Poruke: 95
*.imlek.co.yu.

Sajt: www.radenkovich.com


+1 Profil

icon Re: Inkrementalno punjenje za BI27.11.2007. u 07:59 - pre 179 meseci
nema inkrementalnog polja, da li neko ima ideju kako bi islo preko left outer joina?
Ivan Radenkovic
www.radenkovich.com
 
Odgovor na temu

Oliver-LDL
Oliver Draskovic
Nemacka

Član broj: 9033
Poruke: 32
*.adsl.alicedsl.de.



Profil

icon Re: Inkrementalno punjenje za BI01.12.2007. u 08:11 - pre 178 meseci
Da li u originalnoj tabeli imas nesto tipa "LastModifiedDate" ili "InsertDate"?

Ako kada insertujes podatke u tvoju BI bazu imas datum inserta onda mozes da radis nesto kao:
"insert into bi_table (select * from original_table where timestamp <= (select max(timestamp) bi_table))"

Jedino je problem sto nema automatskog inserta vec mora da se pravi "job" koji ce da pokrene "delta_update" DTS.

Kakva katastrofa sa kombinovanjem nasih i stranih reci .
Oliver
 
Odgovor na temu

radenko
Ivan Radenkovic
bg

Član broj: 11979
Poruke: 95
*.imlek.co.yu.

Sajt: www.radenkovich.com


+1 Profil

icon Re: Inkrementalno punjenje za BI04.12.2007. u 09:43 - pre 178 meseci
I to resenje prolazi, ali sta u slucajevima kada treba izdvojiti skup podataka iz jedne tabele koji ne postoje u drugoj tabeli po zadatom kljucu? Znaci nema sloga u originalnoj tabeli a imate samo read-only pristup?
Ivan Radenkovic
www.radenkovich.com
 
Odgovor na temu

Oliver-LDL
Oliver Draskovic
Nemacka

Član broj: 9033
Poruke: 32
*.adsl.alicedsl.de.



Profil

icon Re: Inkrementalno punjenje za BI04.12.2007. u 09:56 - pre 178 meseci
Ne razumem deo sa "nema sloga u originalnoj tabeli".
Ako treba da se isprazni BI tabela tj. da se obrisu slogovi koji vise ne postoje u originalnoj tabeli samo treba prosiriti DTS tako da se uradi nesto kao:

DELETE FROM BITable WHERE key NOT IN (SELECT key FROM OriginalTable)

Na ovaj nacin se brisu svi slogovi koji vise ne postoje u originalnoj tabeli a opet nismo uradili nista drugo nego jedan select (readonly je i dalje aktivan).

Ako to nije ono sto treba javi mi :)
Oliver
 
Odgovor na temu

radenko
Ivan Radenkovic
bg

Član broj: 11979
Poruke: 95
*.imlek.co.yu.

Sajt: www.radenkovich.com


+1 Profil

icon Re: Inkrementalno punjenje za BI04.12.2007. u 10:11 - pre 178 meseci
mislio sam da nema sloga koji raste inkrementalno pa da prema njemu prostim filtriranjem radim punjenje.
ovo sa NOT IN je jedno od resenja, medjutim, kroz praksu se pokazalo da radi ocajno sporo.
ja te vrste prebacivanja iz tabele u tabelu u accessu vrsim tako sto napravim levi spoljni spoj sa ciljnom tabelom preko kljuca ali tu postavim filter da je u upitu neka od kolona iz ciljne tabele null (sto znaci da prema zadatoj vezi ne postoji odgovarajuci slog u ciljnoj tabeli) i to radi super brzo, medjutim u praksi gotovo nikad ne radim sa DTS paketima kada su linkovani na drugi server pa me zanima da li to resenje moze da se primeni i kod njih? znaci ne u accessu vec na MSSQL serveru...
znaci treba mi neko dobre volje ko inace radi sa SQL serverima da to proba i da mi kaze koliko je bolje resenje od NOT IN...
Ivan Radenkovic
www.radenkovich.com
 
Odgovor na temu

MatezYU

Član broj: 4114
Poruke: 1586
*.otpbanka.co.yu.



+17 Profil

icon Re: Inkrementalno punjenje za BI11.05.2009. u 08:33 - pre 161 meseci
Podaci u fact tabeli DW-a ne bi trebalo da se brisu nikada jer se tada gubi smisao DW-a i celog BI-a.
 
Odgovor na temu

Dracus
BI Consultant, SAP
Nemacka

Član broj: 206036
Poruke: 34
155.56.68.*



Profil

icon Re: Inkrementalno punjenje za BI11.05.2009. u 09:06 - pre 161 meseci
Pa brisanje iz fact tabela nije bas da se ne radi.

Ako je potrebno da se cuvaju podaci samo 5 godina ja onda ne bih drzao ono sto je starije od toga jer to:
- zahteva vise admin angazovanja
- backup traje duze
- restore traje duze
- upis novih podataka moze da traje duze (brisanje indeksa i ponovo kreiranje,...)

plus jos nekoliko drugih razloga.
Naravno ako su podaci potrebni onda se ne brisu ;-)

 
Odgovor na temu

MatezYU

Član broj: 4114
Poruke: 1586
*.otpbanka.co.yu.



+17 Profil

icon Re: Inkrementalno punjenje za BI11.05.2009. u 14:09 - pre 161 meseci
Citat:
Dracus: Pa brisanje iz fact tabela nije bas da se ne radi.

Ako je potrebno da se cuvaju podaci samo 5 godina ja onda ne bih drzao ono sto je starije od toga jer to:
- zahteva vise admin angazovanja
- backup traje duze
- restore traje duze
- upis novih podataka moze da traje duze (brisanje indeksa i ponovo kreiranje,...)

plus jos nekoliko drugih razloga.
Naravno ako su podaci potrebni onda se ne brisu ;-)


Ajde molim te objasni mi kako ces obrisati 100 miliona rekorda iz fact tabele koja ima 10 milijardi rekorda.
Sa DELETE ce trajati celu vecnost zbog logovanja.
A sto se tice data mininga, on moze da radi dobro jedino ako imas podatke unazad 10 godina tako da ne vidim stvarno svrhu brisanja podataka na dw-u koji su stariji od 5 godina.
 
Odgovor na temu

Dracus
BI Consultant, SAP
Nemacka

Član broj: 206036
Poruke: 34
155.56.68.*



Profil

icon Re: Inkrementalno punjenje za BI11.05.2009. u 14:46 - pre 161 meseci
Pazi ako treba odjednom da obrises 100.000.000 rekorda ako uzmemo da je to dnevni "load" onda to znaci da godisnje imas 36.500.000.000 ili ti na 10 godisnjem nivou da imas 365.000.000.000 rekorda sto je znatno vise od pomenutih 10.000.000.000.

Iz razloga da ne dodje do cuvanja podataka koji vise nisu potrebni treba da se kreiraju job-ovi koji ce da vode racuna da ono sto vise nije potrebno da se cuva se i stvarno vise ne cuva.

Kako se srecem da dosta razlicitih SAP klijenata koji imaju BW baze od par stotina Gb do par desetina Tb (najveca baza koju sam video je imala preko 60Tb) mogu da kazem da je ovo jedan od ogromnih problema jer iako je storage relativno jeftin ipak nije besplatan (prosle nedelje sam gledao jedan HP-ov sistem koji kosta oko 60.000€ za 21Tb) a da ne govorim da je backup ogromnih baza udar za ceo sistem i sve job-ove koji rade paralelno.

Inace oni koji imaju tako velike baze imaju i jak hardware da to izguraju.

Sto se tice data-mining-a, na zalost do sada se nisam susreo ni sa jednim klijentom koji ga koristi.

Cuvanje podataka je uglavnom regulisano zakonskom regulativom (barem za klijente koje sam do sada video).

SAP radi sizing projekte tj. ne radi SAP nego hardware partneri tako da bi se izbegla situacija "a kako sada da obrisemo 100.000.000 rekorda".

Moja poenta je sve sto nije potrebno, iz bilo kog razloga, treba da se obrise i to se praktikuje (barem kod klijenata koje sam ja "upoznao").
 
Odgovor na temu

MatezYU

Član broj: 4114
Poruke: 1586
*.otpbanka.rs.



+17 Profil

icon Re: Inkrementalno punjenje za BI11.05.2009. u 15:11 - pre 161 meseci
Dobro, ali ne vidim smisao brisanja podataka iz fact tabela. Kome oni smetaju ako se tamo nalaze?
Za kvalitetno predvidjanje potrebna je sto duza istorija podataka. Tako da ne vidim razlog brisanja necega sto "vise nece trebati". A i sama ideja DW-a je da ne postoji UPDATE i DELETE nego samo INSERT podataka, stavise zabranjeno je brisati u updatovati podatke.
 
Odgovor na temu

MatezYU

Član broj: 4114
Poruke: 1586
*.otpbanka.rs.



+17 Profil

icon Re: Inkrementalno punjenje za BI13.05.2009. u 18:33 - pre 161 meseci
Dimenzije dw-a spuštaju ključeve na fakt tabelu i nije mi jasno kako će se onda brisati podaci iz fakt tabele. Mislim da brisanje podataka iz fakt tabele nema uopšte smisla pošto je svima u interesu (pogotovo oni koji analiziraju podatke) da imaju što veću količinu podataka i dužu istoriju podataka. A problemi sa velikom količinom podataka se mogu rešiti sa particionisanjem tabela.
 
Odgovor na temu

Dracus
BI Consultant, SAP
Nemacka

Član broj: 206036
Poruke: 34
155.56.68.*



Profil

icon Re: Inkrementalno punjenje za BI14.05.2009. u 09:16 - pre 161 meseci
Citat:
Tako da ne vidim razlog brisanja necega sto "vise nece trebati". A i sama ideja DW-a je da ne postoji UPDATE i DELETE nego samo INSERT podataka, stavise zabranjeno je brisati u updatovati podatke.


Nekako ne mogu da se slozim sa ovom konstatacijom. Brisanje podataka nije zabranjeno cak sta vise mislim da je veoma losa administracija sistema gde se ne vodi racuna o podacima.

U zavisnosti za sta se koristi BW sistem se pravi i plan koliko podaci moraju da se cuvaju. Sve ono sto nije potrebno treba da se obrise, arhivira, pomeri, kako god hoces.

Citat:
Dimenzije dw-a spuštaju ključeve na fakt tabelu i nije mi jasno kako će se onda brisati podaci iz fakt tabele. Mislim da brisanje podataka iz fakt tabele nema uopšte smisla pošto je svima u interesu (pogotovo oni koji analiziraju podatke) da imaju što veću količinu podataka i dužu istoriju podataka. A problemi sa velikom količinom podataka se mogu rešiti sa particionisanjem tabela.


Nije mi jasno kako ovo ima veze. Ti u fakt tabeli imas "fakt" podatke plus kljuceve dimenzija. Ako obrises podatke iz fakt tabele brisu se kljucevi koji su bili vezani za te obrisane podatke ali podaci u dimenzijama ostaju i dalje u dim tabelama tako da dodavanje novih "fakt" podataka moze da se radi bez ikakvih problema.

Poenta BW sistema nije da postani ogromni sistemi u koje cemo stavi sve sto nam padne na pamet. Kada se krecu BW projekti sve radi savrseno ali samo zato sto je malo podataka, onda tokom vremena kako se povecava baza tako klijenti pocinju da se zale, te ovo je sporo, te ono je sporo a kao vrednosti za poredjenje se uzima ono vreme kada nije bilo mnogo podataka i sve je radilo prilicno brzo.

Evo ga tekst jednog SAP servisa koji pokriva ovo o cemu pisemo (Data Volume Strategy for BW)

Your database is a large contributor to your total cost of ownership. By scheduling the Data Volume Strategy for SAP BW service to manage the size and growth of your database, you take a big step toward reducing the costs and getting more out of your investment.

The following bullets all represent advantages your company can take away from the Data Volume Strategy for SAP BW service:
- Reduce necessary disk space. 1GB of disk space can cost between 800 – 1,000 USD per year. This includes hardware, software, maintenance, and human resources related to storage and storage management. After you apply the recommendations given in the service report, experience shows that your database size and growth can be reduced by approximately 15 - 50%, depending on your current housekeeping practices.
- Reduce the growth rate of the database and of individual tables.
- Reduce time needed for managing disk space. While disk space is relatively inexpensive, managing it is not. Managing disk space can take 10 hours or more per GB per year. If an enterprise is experiencing a 30% annual growth rate, the amount of time required to manage the data will double in 3 years.
- Benefit from more efficient use of existing resources such as hard drives, memory, and CPU. Thus, you do not need to buy additional hardware to tackle increased database volumes or new development.
- Increase system availability because administration tasks like software upgrades, database reorganization, data backups, or recovery can be done in less time.
- Improve performance and response time of data loads and query reporting with a smaller database.

Mislim da je ovo napravljeno 2006-e tako da su cene po Gb velike ali poenta je tu.

Sa tobom mogu da se slozim da ono sto je potrebno treba da se cuva (zarad analize, predvidjanja, zakonske regulative) ali "data volume management" je veoma bitan jer kolicina podataka ima ogroman uticaj na ceo BW sistem.

 
Odgovor na temu

MatezYU

Član broj: 4114
Poruke: 1586
*.otpbanka.rs.



+17 Profil

icon Re: Inkrementalno punjenje za BI14.05.2009. u 11:11 - pre 161 meseci
Jedno pitanje sta je to BW?
I na kojoj platrofmi radi SAP? Nisam upucen u SAP, ja radim sa Microsoft SQL serverom 2008...
 
Odgovor na temu

Miroslav Jeftić
Istraživanje ruda
[ES]

Član broj: 37513
Poruke: 6833

Sajt: about:blank


+2199 Profil

icon Re: Inkrementalno punjenje za BI14.05.2009. u 12:01 - pre 161 meseci
Citat:
SAP's data warehouse and reporting interface
SAP Business Information Warehouse (SAP BW) provides data warehousing
functions, a business intelligence platform, and a suite of business
intelligence tools. These tools enable businesses to integrate,
transform, and consolidate relevant business information in SAP BW.
SAP BW facilitates the reporting, analysis and distribution of this
information. On the basis of this analysis, businesses can make
well-founded decisions and determine target-oriented activities. With
the comprehensive predefined information models delivered for different
roles in a business (BI Content), SAP BW increases the usability of
analysis functions and facilitates a quick and cost-effective
implementation.
 
Odgovor na temu

Dracus
BI Consultant, SAP
Nemacka

Član broj: 206036
Poruke: 34
155.56.68.*



Profil

icon Re: Inkrementalno punjenje za BI14.05.2009. u 12:07 - pre 161 meseci
BW je business warehouse.
Inace mi radimo sa vecinom trenutno dostupnih baza tako da nismo tehnoloski vezani samo za jednu platformu.
Prednost imaju Oracle i DB2.
 
Odgovor na temu

[es] :: IS i ERP :: Inkrementalno punjenje za BI

[ Pregleda: 3819 | Odgovora: 16 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.