We also had same requirment to determine weekend between given 2 dates, we did it something like below.
OWB expersion can be used to write CASE statement. It uses standard weekend ( sat and Sun)

SELECT promo_id,
promo_name,
promo_subcategory,
promo_begin_date,
promo_end_date,
promo_end_date-promo_begin_date
+
(CASE WHEN TO_NUMBER(TO_CHAR(promo_begin_date,’D')) = 7 THEN 0 ELSE TO_NUMBER(TO_CHAR(promo_begin_date,’D')) enD
– CASE WHEN TO_NUMBER(TO_CHAR(promo_end_date,’D')) = 7 THEN 0 ELSE TO_NUMBER(TO_CHAR(promo_end_date,’D')) enD )/7 * 2
+ CASE WHEN TO_NUMBER(TO_CHAR(promo_begin_date,’D')) = 7 THEN 2 ELSE 0 enD
+ CASE WHEN TO_NUMBER(TO_CHAR(promo_begin_date,’D')) = 1 THEN 1 ELSE 0 enD
+ CASE WHEN TO_NUMBER(TO_CHAR(promo_end_date,’D')) = 7 THEN -1 ELSE 0 enD ) diff_excluding_WEEKENDs
FROM sh.promotions;

;-)

We tried, admittedly with v9 of OWB, to use the hints capabilities inside OWB…and it was a nightmare…which was another nail in the coffin of it’s usage at the time. I don’t know if that part of the product has “moved on” but if it hasn’t then I’m not sure I’d agree as to it’s ease of use…whatever the case, it simply can’t be as easy as adding them to the SQL in a view.

As I said, we’ve reached a point now where we’re just upgrading to 10gR2 of OWB and therefore perhaps, being on a recent release, we’ll be able to reassess our position over the coming period. I’m looking forward to that.

Cheers
Jeff

@Jeff
>…I can’t see anyone developing on a warehouse without being a proficient SQL developer…

I wish that were the case… but not always. When an organization dives into creating their first data warehouse, the developers familiar with the source systems quite often get the call… and they may be OLTP-style developers without advanced analytic and aggregate SQL ability. Some of these developers may not even have experience writing complex joins, as it’s not done in the source systems they are used to. I find that OWB forces some of these developers to write complex set-based processes, where, left to their own devices, they may revert to cursor-based PL/SQL.

> …hints… gets a bit tricky if it’s all inside OWB…
Actually, using hints in OWB (if you are so inclined) is quite easy. Just Configure the mapping, and there you go.

> What about debugging?
OWB has a debugger that’s not too bad. And, in versions 10.2.0.4 and 11g, showing incoming and outgoing SQL from a particular operator is easy… just as easy as if the code were in a view. And you can always trace it as well.

Petr

Completely agree that there is no “always true” answer…I guess the article someone needs to write is one that debates the reasoning behind either choice…I’ve thought about doing that myself, but I haven’t got the time at the minute.

Yes, that’s why we’re considering the “inside OWB” route going forwards…the documentation reasoning….but I’m not necessarily sure that the documentation is meaningful per se.

Yes, I’d have a “pretty picture” but unless I train the end users, they wouldn’t be able to understand it any more than they can looking inside the view – for the more complex mappings – easy ones perhaps. The developers would be able to use it, but I can’t see anyone developing on a warehouse without being a proficient SQL developer…and, in my experience at least, they’d much rather write a view than paint pretty pictures.

I know from experience on the current implementation I’m working on, that the code falls into 30% simple views and 70% complicated views buckets and consequently, for the majority of mappings, only the “exceptional developers” will be able to make use of that documentation – not that that’s a bad thing of course.

The more complex it is, the more likely I’d want to write it in SQL, rather than build it inside OWB…adding that to the fact that it’s easier to develop using one approach rather than two, that then leads me to writing everything in views rather than OWB. Your mileage, as they say, may vary.

If you then start talking automatically generating code, is it easier to generate the complex SQL for views and simple OMB mappings using OMBPlus, or use OMBPlus to generate all of it? I’d suggest the former since use of the less widely known OMBPlus, is minimal then.

What about tuning? You build a complex mapping and deploy it…it doesn’t run right due to a bad plan, so you need to tune it…there are, of course, a number of ways to tackle that…but if your method of choice is adding hints, then that, from my understanding, gets a bit tricky if it’s all inside OWB…but very simple if it’s a view. Of course using hints is a debatable point in it’s own right, but that’s another debate altogether!

What about debugging? Our debugging process with views is simply debugging a piece of SQL…with the OWB approach I guess that’s a bit more complicated?

It’s a tricky one really and one that the architects team at my current client have debated numerous times over the past few years. We’re using the complex views approach currently but we’re open to moving if and when we see compelling reasons to do so.

Cheers
Jeff

The data warehouse project I am working on at the moment gives me a choice of an analytic view to get previous states of an item or “writing” some complex map in OWB – the measures for this fact are based on the nature of the transition and not the state itself. In terms of simplicity (and probably performance) the view is highly attractive; but of course it obscures the transformation.

;-)

The documentation reason is perhaps the only reason our team is considering the “do it inside OWB” approach now…but of course we have all these exceptional developers who are used to writing views to do the “work” and not particularly used to writing OWB mappings using the “inside the tool” techniques and a whole codebase that uses the views approach, so it would be a bit radical if we were to change our strategy now…the old adage, if it ain’t broke, don’t fix it, springs to mind.

Cheers
Jeff

@Jeff
It depends on your requirements. With some shops, the key is getting to market quickly, and with exceptional developers doing all the complex logic, that model has tremendous upside. Other organizations will use OWB to allow a mix of talents and skill levels in a development team to all contribute to the same code in a modular fashion. In those scenarios, having the “pretty pictures” as you say serves to better document the source-to-target mappings inherent in the process. That’s one of the real benefits of OWB… it can adjust to your skill level to provide different ways of accomplishing the same task.

Personally, I choose to put the logic in OWB whenever possible. However, when I take that position, and then find myself having to do logic in a view, I am possibly watering down the rest of the OWB logic because I have essentially placed the logic in two places. Your approach always maintains the logic in one place, so it certainly gets points in that regard.

It’s interesting that you raise the point of OWB not being able to do something and then coding around it inside a view…I spend a lot of time on a Data Warehouse system that is largely based on that way of doing things, i.e. views with all the “work” in them and simple OWB mappings that take those views and push the generated transactions to targets.

The design approach to use code inside views, was taken for that system, at a time when OWB was on version 9 (way old now) and when it was quite immature in terms of functionality – perhaps the right choice then as we kept hitting similar issues to the one you describe, where we couldn’t do what we wanted with OWB.

Whether it’s the right choice now? Well, I think there are still some advantages to choosing the views to do all the “complex” coding rather than drawing pretty pictures in OWB…but this client is actively looking at whether they should be using more of the OWB product going forwards.

Might be nice to see a comparison piece about why one should choose one approach over the other…

Cheers
Jeff

For every day that is NOT a business day, it simply gets the business_day_num of the previous day.

Then, calculating the # of business days between two given dates becomes a simple subtraction.

Hope this helps,
Scott