Got a naming and strategy problem here.
My company is trying to haul itself into the warehouse world, little by little. Currently we have a legacy system which holds lots of back office data. It's not well designed, to the extent that lots of data is held more than once. It's up for replacement over the next 2 years (gradually).
There's a bunch of VB, SQL, Access, XL, etc, systems too, some of them linking to the legacy data. Increasingly we are buying packages off the shelf which need to link in as well. We get data feeds from outside the company too.
It's easy to identify data which should be shared between applications - lots of the external feeds and some core legacy data. We also know that increasingly the reports we send to clients and sales materials need to include data fropm many systems, not just the legacy.
Our architect thinks this is a data warehouse. The developers think it might be a warehouse on the reporting side, but the plan is to make this somewhat normalised, so that different reports can share the same data consistently (we have a problem with post-hoc data changes being needed - which is not going to go away).
The data sharing bit should probably be more normalised. This bit tends to be called the 'hub', 'repository', 'shed' or anything else we can think of.
Can anyone tell me what it ought to be called?
Can it be confirmed that we should keep the sharing and the reporting bits separate?
And is there a practical book on this kind of thing?
This all is likely to be done on SQL Server with Crystal Reports; the leagcy system is Mumps though the technology probably doesn't matter.
Thanks for wisdom.
Bill.
My company is trying to haul itself into the warehouse world, little by little. Currently we have a legacy system which holds lots of back office data. It's not well designed, to the extent that lots of data is held more than once. It's up for replacement over the next 2 years (gradually).
There's a bunch of VB, SQL, Access, XL, etc, systems too, some of them linking to the legacy data. Increasingly we are buying packages off the shelf which need to link in as well. We get data feeds from outside the company too.
It's easy to identify data which should be shared between applications - lots of the external feeds and some core legacy data. We also know that increasingly the reports we send to clients and sales materials need to include data fropm many systems, not just the legacy.
Our architect thinks this is a data warehouse. The developers think it might be a warehouse on the reporting side, but the plan is to make this somewhat normalised, so that different reports can share the same data consistently (we have a problem with post-hoc data changes being needed - which is not going to go away).
The data sharing bit should probably be more normalised. This bit tends to be called the 'hub', 'repository', 'shed' or anything else we can think of.
Can anyone tell me what it ought to be called?
Can it be confirmed that we should keep the sharing and the reporting bits separate?
And is there a practical book on this kind of thing?
This all is likely to be done on SQL Server with Crystal Reports; the leagcy system is Mumps though the technology probably doesn't matter.
Thanks for wisdom.
Bill.
