Basic Access Database Design

[Ronster]

I'm starting a new Access 2003 project which will probably require
around a 100 tables or so with lots of VBA code. My basic question is
should I flowchart the entire application first? There are hundreds
functions for this application and I would like to make sure I see how
they all relate before starting into table design. I'm working with a
user who knows what he wants and we have roughly layed it out. I know
flowcharting could be a very time consuming process and wonder if I
would be better off just jumping into the design, table layout,
normalizing, etc. Any thoughts? Any good books or web sites that
cover start-to-finish Access design? The web sites I have seen rarely
mention flowcharting.

Thanks.

 

[Amy Blankenship]

I'm starting a new Access 2003 project which will probably require
around a 100 tables or so with lots of VBA code. My basic question is
should I flowchart the entire application first? There are hundreds
functions for this application and I would like to make sure I see how
they all relate before starting into table design. I'm working with a
user who knows what he wants and we have roughly layed it out. I know
flowcharting could be a very time consuming process and wonder if I
would be better off just jumping into the design, table layout,
normalizing, etc. Any thoughts? Any good books or web sites that
cover start-to-finish Access design? The web sites I have seen rarely
mention flowcharting.

You can flowchart what you want your forms to do, but I think that's the
only place where a flow chart would be a good metaphor. Not to say you
shouldn't get it down on paper, but just that a flow chart is not what you
need. I've found a white board works well because you can make infinite
changes without much work while you're trying to get the design finalized.
If you have Journal or OneNote you may be able to use it in a similar way.

HTH;

Amy

 

[Steve]

I create a map of the tables for every database I do. The map shows all the
tables all the fields in each table, the flow of information through the
tables, the relationships that exist between the tables and the type of each
relationship. The map visually shows what forms and subforms are needed for
entering data and for displaying data. The map shows what reports and
subreports can be created within the database. While a database is in
development, I keep the map at my right hand and at completion of the
database the map is documentation of the structure of the database.

PC Datasheet
Providing Customers A Resource For Help With Access, Excel And Word
Applications
(e-mail address removed)

 

[Guest]

Both Amy and Steve offer good suggestions. I would like to offer mine.
Before you design any tables or fields. A flow chart is a good idea. I
perfer Visio.
But, it is not the data or the application I flow first. I start with the
business requirements and the work flow. For example, "Customer Places
Order", "Customer Credit Authorized (Y/N)", "Item In Stock (Y/N)", "Create
Picking Ticket", "Create BackOrder", "Order Assembled", "Order Packed", "Ship
Method Selected", ect.

Then determine the data required to support the work flow.

Then design talbes, fields and relationships.

Then design forms and reports.

And so on.

You can always tell if an application has been designed by someone who got
the requirement then immediatly started codeing.

 

[Ronster]

Both Amy and Steve offer good suggestions. I would like to offer mine.
Before you design any tables or fields. A flow chart is a good idea. I
perfer Visio.
But, it is not the data or the application I flow first. I start with the
business requirements and the work flow. For example, "Customer Places
Order", "Customer Credit Authorized (Y/N)", "Item In Stock (Y/N)", "Create
Picking Ticket", "Create BackOrder", "Order Assembled", "Order Packed", "Ship
Method Selected", ect.

Then determine the data required to support the work flow.

Then design talbes, fields and relationships.

Then design forms and reports.

And so on.

You can always tell if an application has been designed by someone who got
the requirement then immediatly started codeing.
--
Dave Hargis, Microsoft Access MVP






- Show quoted text -

All the above are excellent suggestions and I thank you. Dave I like
your suggestion and I do have Visio 2003 and was wondering whether you
preferred one drawing type over another. For example under Business
Process there is the Work Flow Diagram which I haven't worked with
before but looks interesting. I've primarily used basic flow charting
with Visio. I do like the idea of having it all layed out before any
code is written.

Ron

 

[Guest]

I use the work flow and the basic, it depends on what I am modeling. Just
use whatever is comfortable