Program Workflow (1 Viewer)

Frank64

Registered User.
Local time
Today, 11:00
Joined
Jun 18, 2015
Messages
11
Please what drives the setup of a database?
Is it the desired reports or the readily reachable data for table formulation?
 

spikepl

Eledittingent Beliped
Local time
Today, 12:00
Joined
Nov 3, 2010
Messages
6,144
What desire drives a shovel?

Access is similarly a versatile tool that can be used in untold different ways, so your question has no general answer.
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 11:00
Joined
Sep 12, 2006
Messages
15,613
I think I can offer a slightly different opinion.

I think a database setup should always be data driven. Identify all the data/attributes your system needs to manage. (your knowledge of the business processes and concepts of the forms should guide you here, but it isn't at all about the forms per se. (IMO)). The hard bit is knowing everything you need, and not taking things for granted. Do not let the concept of the way the user thinks it should work deflect you from this analysis. It really isn't (or shouldn't be) about the presentation of the data at all. The presentation can be achieved by manipulating the data, rather than the other way round.

Often though the user will take things for granted that the developer needs to know. The data analysis really has to manage every possible nuance. Even if something occurs once a year, you need to be able to handle it.

Think about price management. You can have generic price lists, quantity breaks, special rates for certain customers, limited special offers, clearance deals, special rates for "sets" of products. You may have complicated discounts applied at order level, or some other level.The data structure needs to be able to deal with all the eventualities that might arise.

next analyse the data/attributes into normalised tables. (again, the same thoughts in respect of the processes and forms, but not so much, as you know which data you need to process)

now you should be able to develop the forms, reports and other database objects that you need to manage the data. The correct data analyse will ensure this development takes place in a harmonious way.

As you begin to develop, it may be become clear that your data analysis was incomplete, or could be improved. It is better to fix this, and rework, then continue with a sub-optimal data analysis.

That's my thoughts, anyway.
 

jdraw

Super Moderator
Staff member
Local time
Today, 07:00
Joined
Jan 23, 2006
Messages
15,361
Very interesting question --totally out of context.

In my view, the driver for database can be many and varied.
If you have processes that waste a lot of resources, then you decide to revamp the processes to reduce that waste.
Is the driver:
- to have streamlined processes,
- to reduce duplication of effort,
- to improve communication between processes and staff
- to take control holistically
- to apply technology as appropriate
- to improve company balance sheet (reduce costs)

In general a clear understanding of the business issue/opportunity is key to know what you are trying to achieve/solve.
 

Frank64

Registered User.
Local time
Today, 11:00
Joined
Jun 18, 2015
Messages
11
I think I can offer a slightly different opinion.

I think a database setup should always be data driven. Identify all the data/attributes your system needs to manage. (your knowledge of the business processes and concepts of the forms should guide you here, but it isn't at all about the forms per se. (IMO)). The hard bit is knowing everything you need, and not taking things for granted. Do not let the concept of the way the user thinks it should work deflect you from this analysis. It really isn't (or shouldn't be) about the presentation of the data at all. The presentation can be achieved by manipulating the data, rather than the other way round.

Often though the user will take things for granted that the developer needs to know. The data analysis really has to manage every possible nuance. Even if something occurs once a year, you need to be able to handle it.

Think about price management. You can have generic price lists, quantity breaks, special rates for certain customers, limited special offers, clearance deals, special rates for "sets" of products. You may have complicated discounts applied at order level, or some other level.The data structure needs to be able to deal with all the eventualities that might arise.

next analyse the data/attributes into normalised tables. (again, the same thoughts in respect of the processes and forms, but not so much, as you know which data you need to process)

now you should be able to develop the forms, reports and other database objects that you need to manage the data. The correct data analyse will ensure this development takes place in a harmonious way.

As you begin to develop, it may be become clear that your data analysis was incomplete, or could be improved. It is better to fix this, and rework, then continue with a sub-optimal data analysis.

That's my thoughts, anyway.

Hi Dave:
I must acknowledge, your response makes a lot of sense to me. Others had thought that,the question was irrelevant but I think one's ability to raise any good program will be relative to the workflow chart one is able to draw from the scratch.
In view of that, your response appeals volumes.

Regards,

Frank
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 06:00
Joined
Feb 28, 2001
Messages
26,996
In all non-trivial cases, the data must drive the design just as surely as the dog must wag the tail (as opposed to the tail wagging the dog).

In trivial cases, you are contriving situations in which to learn some principle - and that is totally OK. In non-trivial cases, you have a problem to solve and it is usually based on a complex business or scientific process. No less an authority than Niklaus Wirth, the "father" of the PASCAL language, stated that 80% of all problems with programs stem from problems the initial data layout. Stated another way, if you don't start with the data flow and data components of your problem, you have 4 chances in 5 to screw it up badly.
 

Frank64

Registered User.
Local time
Today, 11:00
Joined
Jun 18, 2015
Messages
11
The Doc Man:
Thanks a lot for your feedback.
I think it makes a lot of sense that the data has to drive the program. After all in our conventional life, one will have to move from the known to the unknown.

Regards,

Frank
 

Users who are viewing this thread

Top Bottom