[MS SQL] Update Column

[turkosh]

Hoi,
Ik ben bezig met een datawarehousing project(je). Nu heb ik een redeleijk simpele fact table gemaakt met 3 dimensie tabellen (Datum, Winkel, Product)
Die fact table houdt op dit moment bij wat(hoeveel), waar, wanneer verkocht is. Dit was om te testen hoe ik dit vervolgens in Analysis Manager kon weergeven. Al met al werkte het netjes.
Het is de bedoeling dat ik uiteindelijk omzet, kosten, winst overzichten krijg - wat nu niet het geval is.
ik dacht ik neem een colom "omzet" op in facts die d.m.v. [aantal verkopen] * [product prijs] wordt berekend. Toen stuitte ik op problemen.
De [product prijs] staat in product table. Dus gebruik maken van de formule veld voor colom definitie ging niet door.
Toen dacht ik ik plaats ook een [Product prijs] kolom in facts. Maar die moet vervolgens ook gevuld worden met de correcte prijzen. Hoe kan ik nou voor alle fact records die ik heb de correcte prijs erbij zetten. Het gaat hierbij om zo'n 1,5 miljoen records die van correcte prijs moeten worden voorzien.
Ik kan wel de fact table verwijderen en opnieuw opzetten met nu wel de juiste (en gevulde) kolommen, maar ik dacht er zal vast wel een betere manier zijn om dit voor elkaar te krijgen.
Ik dacht een combo For loop met een update statement, maar weet niet zeker hoe dat moet.

[Janoz]

Een formule colom opnemen in je tabel? Ik denk dat je een beetje in de war bent met excel.

De normale manier om dit te bereiken is een query te bouwen waarin de producttabel koppelt aan de fact tabel. Hier kun je vervolgens die berekende 'kolom' opnemen. Wat je iig niet moet doen is het product bij de fact tabel inzetten omdat je dan redelijk veel redundante informatie krijgt. Zie voor meer informatie hierover google met de zoekterm normaliseren .

Ergo: Wat je nu aan het doen bent (die omzet berekening) moet je niet bij de tabel bouwer doen, maar bij de query bouwer.

[Verwijderd]

het is in mssql mogelijk om met een update waarden in tabel a te wijzigen aan de hand van waarden in tabel B. Je moet dan een update statement met een from clause hebben.

code:

Update a set a.prijs = b.prijs from a,b where a.produktnummer = b.produktnummer

[turkosh]

design view van een tabel geeft een optie formula (onderaan ergens) aan waar je een waarde aan een kolom kan toekennen die samengesteld is uit andere kolommen.
Maar dat geldt dus alleen voor de kolommen binnen het tabel.
Je hebt gelijk voor wat betreft redundantie. vandaar dat ik eerst probeerde de omzet te berekenen met de bestaande product prijs kolom in product tabel. maar dat werkte in dit geval niet. Het laatste wat ik wil is een extra prijs kolom in facts. Maar kosten en baten analyse hoort er eenmaal bij, naast aantal verkopen.

En FFrenzy: bedankt voor je hulp

uiteindelijk heeft dit gewerkt (zonder een for loop):

code:

 Update facts set facts.omzet = product.[product prijs]*facts.[aantal verkocht] from facts,product where product.product_key = facts.product_key

Hiermee heb ik dus geen extra kolom met prijs nodig voor in de facts tabel

[Janoz]

Bedenk je wel dat deze kolom niet niet de actuele status weergeeft, maar de status zoals deze was toen je deze query uitvoerde. Normalitair hoor je deze query uit te voeren op het moment dat de gegevens opgevraagd worden, en niet de resultaten in de tabel zelf opslaan.

[turkosh]

Daar heb je gelijk in.
Eigenlijk zou ik dit update elke keer moeten aanroepen als ik DTS uitvoer voor de meest recente gegevens.

[Janoz]

NEE! Deze gegevens moet je niet in de tabel op gaan slaan. Deze afgeleide informatie moet je afleiden. Als je het al als een tabel zou willen laten lijken hoor je een view te gebruiken. Een view is een fake tabel die dmv een query oid wordt gegenereerd. Hij is gewoon als tabel te gebruiken, maar heeft dan wel actuele data .

[EfBe]

Je kunt ook een user defined function maken en die als basis gebruiken voor je computed column.

Of natuurlijk een view.

(doe even een enter in die lange regel met die query)

[ Voor 19% gewijzigd door EfBe op 05-04-2004 14:26 ]

[turkosh]

Hoe raad je mij dan aan om een VIEW te importeren in Analysis Manager (cube)? Dat zou ik heel graag willen weten, want dat maakt het leven veel makkelijker!

Gevonden!!!! Jippie
Oh ja, DTS deed moeilijk met views. Nu weet ik het weer.

[ Voor 21% gewijzigd door turkosh op 05-04-2004 14:36 ]

[cameodski]

Als het enigszins mogelijk is, moet je inderdaad geen redundante informatie opslaan, maar het kan bij hele grote tabellen gebeuren, dat je uit performance oogpunt er gewoonweg niet onderuit kunt.
In dat geval moet je of triggers gebruiken of in de dts package voor het opnieuw processen, de gegevens in de fact table bijwerken.

[whoami]

Janoz schreef op 05 april 2004 @ 14:23:
NEE! Deze gegevens moet je niet in de tabel op gaan slaan. Deze afgeleide informatie moet je afleiden. Als je het al als een tabel zou willen laten lijken hoor je een view te gebruiken. Een view is een fake tabel die dmv een query oid wordt gegenereerd. Hij is gewoon als tabel te gebruiken, maar heeft dan wel actuele data .

Het gaat hier om een dataware house project, wat dus inhoudt dat er ook historische gegevens opgeslagen worden.
Dingen zoals 'totaal factuurbedrag' bv moet je imo wel gaan opslaan in je databank. Als je die factuur nl. 10 jaar na datum nog eens opvraagt, dan moet daar nl. hetzelfde bedrag staan zoals 10 jaar geleden; de prijzen van de produkten kunnen nl. veranderd zijn, er kan andere business-logica (kortingen, etc...) op toegepast worden enzovoort.

[cameodski]

whoami schreef op 05 april 2004 @ 20:02:
Het gaat hier om een dataware house project, wat dus inhoudt dat er ook historische gegevens opgeslagen worden.
Dingen zoals 'totaal factuurbedrag' bv moet je imo wel gaan opslaan in je databank. Als je die factuur nl. 10 jaar na datum nog eens opvraagt, dan moet daar nl. hetzelfde bedrag staan zoals 10 jaar geleden; de prijzen van de produkten kunnen nl. veranderd zijn, er kan andere business-logica (kortingen, etc...) op toegepast worden enzovoort.

De vraag is alleen of je dit soort prijswijzigingen niet op een andere plaats moet opslaan. Het lijkt me tenminste logisch dat je dat ook nog op andere plaatsen wilt kunnen zien dan alleen in de fact table tbv de datawarehouse.

[Janoz]

whoami schreef op 05 april 2004 @ 20:02:
[...]


Het gaat hier om een dataware house project, wat dus inhoudt dat er ook historische gegevens opgeslagen worden.
Dingen zoals 'totaal factuurbedrag' bv moet je imo wel gaan opslaan in je databank. Als je die factuur nl. 10 jaar na datum nog eens opvraagt, dan moet daar nl. hetzelfde bedrag staan zoals 10 jaar geleden; de prijzen van de produkten kunnen nl. veranderd zijn, er kan andere business-logica (kortingen, etc...) op toegepast worden enzovoort.

Daar heb je helemaal gelijk in. Ik heb zelfs nog overwogen om het in mijn post op te nemen. De reden dat ik dat niet heb gedaan is omdat het in de gestelde requirements hier niet van toepassing is. Het veld prijs opnemen in de fact tabel omdat de omzet berekenen dan veel makkelijker is, is geen valide reden. Het veld prijs opnemen in de factuur tabel omdat de prijs afhankelijk wordt van de factuur en niet van het product is inderdaad wel een valide reden.

[turkosh]

Het is wel zo dat ik in de productie DB wel een extra prijs kolom bijhou in verkooplijst tabel, dit in verband met de veranderende prijzen en bijhouden van accurate historische gegevens. Dus ik zou die prijzen ook wel kunnen importeren in de data warehouse.
Als ik dat doe dan moet ik in principe dus wel de prijs opnemen in de facts table van mijn data warehouse. De "product prijs" van mijn product table is namelijk de meest recente prijs.

[cameodski]

turkosh schreef op 06 april 2004 @ 11:20:
Het is wel zo dat ik in de productie DB wel een extra prijs kolom bijhou in verkooplijst tabel, dit in verband met de veranderende prijzen en bijhouden van accurate historische gegevens. Dus ik zou die prijzen ook wel kunnen importeren in de data warehouse.
Als ik dat doe dan moet ik in principe dus wel de prijs opnemen in de facts table van mijn data warehouse. De "product prijs" van mijn product table is namelijk de meest recente prijs.

Aan de actuele product prijs heb je toch niets in je datawarehouse, omdat je er nog geen verkopen bij hebt?
En als je wel verkopen hebt, dan heb je die prijs daar volgens mij ook al in staan.