Home -> Usenet -> comp.databases.theory -> Re: Database schema for universal usage

Re: Database schema for universal usage

From: mountain man <hobbit_at_southern_seaweed.com.op>
Date: Wed, 01 Jun 2005 11:29:42 GMT
Message-ID: <G_gne.9263$BR4.2072_at_news-server.bigpond.net.au> 






"Paul" <paul_at_test.com> wrote in message 
news:427f906e$0$578$ed2619ec_at_ptn-nntp-reader03.plus.net...


> Chris wrote:




>> On the level of business management some ideas

>> exist for a company-wide database. However on a technical base I did

>> not find any information about this idea - or any descriptions of

>> people how has tried it. Still looking forward...

>

> Although I've never used it, there are companies like SAP that I

> understand provide massive off-the-shelf database installations that are

> supposed to cover large amounts of standard business requirements. But

> that's only because things like accounting, payroll, etc. are fairly

> standard across companies.




Yes, SAP is a good example, and extremely expensive, of
an application *and* database that can be configured for a
range of differing requirements.  Many many control switches
behind the scenes, parameters being thrown in the general
arena to establish the specific end result.



One approach to the general question asked in this thread
is to split the schema into modules, and then ask the same
question.



Invariably one has a core organisation/business module of
some description (dependent upon what the organisation
does).  But associated with the main business module, are
a series of (presumeably) integrated financial modules:



CORE=main business module

AR=accounts receiveable
AP=creditors
PY= payroll




FX = fixed assets register


GL=general ledger



Variance between the financial modules will exist dependent
upon differing legislative requirements in each country, but
in general the financial modules will be very similar, whereas
the differences between the core business modules of various
organisations will (of course) be extreme.



Undoubtedly there have been various attempts to generate
universal financial modules, and while everything looks good
on paper (as someone else observed) in practice, a number
of heavy duty issues emerge.



The primary issues are related to the fact that these modules
in the end must be integrated, and the interfaces between
the modules are not necessarily trivial - hence generalisation
problems emerge.



The CORE module must feed the AR module usually by
raising invoices. There may be an interface from the AP
module to the CORE for expenses to be itemised prior to
invoicing and recharging. AP, PY and FX must also integrate
into the GL.  The major interface is usually the AR to GL one.



So, this is one manner of making components of your
problem, and hopefully may assist in understanding the
problem from another perspective.




One other approach to this general question is to ask the
question whether anyone has made a study of "collections"
or "classifications" of schemas, seeing that some schemas
are similar, while others are diversely disparate.  I dont
know whether anyone has done a study like this.



But if such a study were made, you would at least have
(in theory;-) a review of the field which is to be somehow
made universal.



2c








-- 
Pete Brown
IT Managers & Engineers
Falls Creek
Australia
www.mountainman.com.au/software


Received on Wed Jun 01 2005 - 13:29:42 CEST












Original text of this message