Database building

[Marc R. Bertrand]

Hello,

Do some of you know some pretty good books or web tutorials on
building databases, if any? By that I mean, when looking at a
business, the sound way of choosing the proper fields and the proper
way to group these fields to construct the tables that make up a
database, while anticipating database growth.

I have learned quite a bit of SQL (thanks to Chris Fehily's Visual
Quickstart Guide SQL) but now I want to find some practical examples,
some let's say "real life examples" of database building of the type:
here is the business, it does this and that, so here is what we need:
build a database that will enable us to input this and that and that
will produce this report and that report. That type of stuff.

I have looked at Access databases that can be built with the wizard,
but I want to create databases from scratch: for example, I want to
study a business situation and create an Access database for the
business, the tables, forms, reports, and queries and all good stuff,
and be forced to establish the relationships myself. Because in the
end, the reports all got to make sense. I want to at least be
presented with business or even non-business situations situations and
create the tables and relationships, these being critical.

Thanks.

Marc R. Bertrand

[Jeffrey R. Bailey]

Database Design for Mere Mortals by Michael J. Hernandez sounds like what
you are looking for. ISBN 0-201-69471-9

--
Jeffrey R. Bailey
"Marc R. Bertrand" <mr*@goalseek.net> wrote in message
news:26**************************@posting.google.c om...

Hello,

Do some of you know some pretty good books or web tutorials on
building databases, if any? By that I mean, when looking at a
business, the sound way of choosing the proper fields and the proper
way to group these fields to construct the tables that make up a
database, while anticipating database growth.

I have learned quite a bit of SQL (thanks to Chris Fehily's Visual
Quickstart Guide SQL) but now I want to find some practical examples,
some let's say "real life examples" of database building of the type:
here is the business, it does this and that, so here is what we need:
build a database that will enable us to input this and that and that
will produce this report and that report. That type of stuff.

I have looked at Access databases that can be built with the wizard,
but I want to create databases from scratch: for example, I want to
study a business situation and create an Access database for the
business, the tables, forms, reports, and queries and all good stuff,
and be forced to establish the relationships myself. Because in the
end, the reports all got to make sense. I want to at least be
presented with business or even non-business situations situations and
create the tables and relationships, these being critical.

Thanks.

Marc R. Bertrand

[Pete]

> Do some of you know some pretty good books or web tutorials on

building databases, if any? By that I mean, when looking at a
business, the sound way of choosing the proper fields and the proper
way to group these fields to construct the tables that make up a
database, while anticipating database growth.

I have learned quite a bit of SQL (thanks to Chris Fehily's Visual
Quickstart Guide SQL) but now I want to find some practical examples,
some let's say "real life examples" of database building of the type:
here is the business, it does this and that, so here is what we need:
build a database that will enable us to input this and that and that
will produce this report and that report. That type of stuff.
There is more than one thing at issue here: you want to learn the
implementation details of how to work with Access specifically, but
also on a conceptual basis of how to construct a general database
structure? For the latter, the database design, I recommend data flow
diagrams. A link (you can search elsewhere for possibly better
explanations):

http://www.agilemodeling.com/artifac...lowDiagram.htm

When you're just learning Access, complicated databases aren't even in
your horizon because of sheer difficulty of getting even the simple
things done right. You can, for example, store a customer list and
enable the form to change their addresses. But when you get to
complicated workflow issues, like digitizing a task for an entire
department of employees, it helps to fully understand how the
employees work--what they do, so to speak. You can draw a data flow
diagram of any business process, and this helps you ...understand...
how the current process works, so that you can improve upon it.

I'm awful at explaining things, but prodigiously talented at finding
documents that successfully convey what I'm _vainly attempting_ to:

http://www2.cs.utep.edu/~cs4310/docu...%20Diagram.doc

The above provides you with a far better explanation than I can hope
to give.

I have looked at Access databases that can be built with the wizard,
but I want to create databases from scratch: for example, I want to
study a business situation and create an Access database for the
business, the tables, forms, reports, and queries and all good stuff,
and be forced to establish the relationships myself. Because in the
end, the reports all got to make sense. I want to at least be
presented with business or even non-business situations situations and
create the tables and relationships, these being critical.

A tidbit about relational databases--if you aren't aware of the
benefits of normalization, read up on it--this is what separates
Access from an Excel spreadsheet.

(sorry if link is split over two lines)
http://www.abcdataworks.com/Develope...baseDesign.doc
As for learning Access-specific knowledge, there are books and books.
The most commonly-recommendd book is the Access [version number]
Developer's Handbook by Getz, Litwin, etc. It's more advanced than an
intro to Access, but it has everything you need to work with Access.
If you need a more basic/intermediate book to get you off the ground,
someone else may have a suggestion.

If you're just looking for a nudge, check out the Relationships window
of the database. This is where you enforce referential integrity
among your tables.
Pete