A proposal for specifying data requirements

I've been watching this group for a couple of months now and have noticed
that most design questions are posed in narrative form. I propose we come up
with a "language" to descibe the data requirements. For example:

An Employee works on many Projects as Role (examples: Manager, Designer,
QA, etc.
A Project has many Employees working on it.

A Deparment has many Employees
An Employee works in one department

An Employee worked on Project for WeekEndingDate as Role for Hours.

If we could express "data facts" in such a manner, it would be much easier
to offer design advice. I am not proposing a strict
specification language, just something where we get an idea of relationships
among tables and and relationships among tables and columns.

Also, posters should at least post their first pass at a solution.

All the best,

Eva n

On Wed, 02 Apr 2008 22:35:36 GMT, "Evan Keel" wrote:

An Employee works on many Projects as Role (examples: Manager, Designer,
QA, etc.
A Project has many Employees working on it.

A Deparment has many Employees
An Employee works in one department

An Employee worked on Project for WeekEndingDate as Role for Hours.

If we could express "data facts" in such a manner, it would be much easier
to offer design advice. I am not proposing a strict
specification language, just something where we get an idea of relationships
among tables and and relationships among tables and columns.

Also, posters should at least post their first pass at a solution.

All very good ideas... but how will you inform the unending stream of new
Access designers coming to these newsgroups for the first time? Bear in mind
that even if we could post a daily FAQ or recommended posting style, very few
folks would read it.

So... who will bell the cat, asked the mouse?
--

John W. Vinson [MVP]

Your suggestions seem like a variant on describing entity-relationships, but
perhaps with an Object-Role twist.

Yes, a "convention" for defining the data requirements could help.

As John points out, folks who don't know/use the convention will still post
using their own explanations.

And even someone who understands the convention may not understand his/her
situation well enough to define it with that level of precision. Sometimes
the very first step in designing an application is helping the user clarify
just what it is s/he is after!

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

"Evan Keel" wrote in message
et...
I've been watching this group for a couple of months now and have noticed
that most design questions are posed in narrative form. I propose we come
up
with a "language" to descibe the data requirements. For example:

An Employee works on many Projects as Role (examples: Manager, Designer,
QA, etc.
A Project has many Employees working on it.

A Deparment has many Employees
An Employee works in one department

An Employee worked on Project for WeekEndingDate as Role for Hours.

If we could express "data facts" in such a manner, it would be much easier
to offer design advice. I am not proposing a strict
specification language, just something where we get an idea of
relationships
among tables and and relationships among tables and columns.

Also, posters should at least post their first pass at a solution.

All the best,

Eva n

Your right, but first you learn to speak the the language there is not much
point in asking a Russian for directions in French!
Five days ago when I set out to build a database for my local sports
Association. The only thing I knew about access, was that is where publisher
stored my mailing list.
The first thing I did was contact my local technical College. Who gave me
the link to VTC.com (no doubt there are plenty of other similar web sites out
there. If you look)
I took their online course on access and four days later. I have a database
capable of handling the thousands of different record combinations that go
with the different classes age groups and heats of our sporting events. I'm
now looking at automating some of the functions. So that means back to
VTC.com for a course in Visual Basic's.
Yesterday was the first time I've posted a message on this site and the
first thing that struck me was. There are quite a few people posting here
who have absolutely no idea of the power of Access. So my first advice to
any of these people would would be go to VTC.com, or a similar site and take
a course. They are excellent value.
--
binny


"Evan Keel" wrote:

I've been watching this group for a couple of months now and have noticed
that most design questions are posed in narrative form. I propose we come up
with a "language" to descibe the data requirements. For example:

An Employee works on many Projects as Role (examples: Manager, Designer,
QA, etc.
A Project has many Employees working on it.

A Deparment has many Employees
An Employee works in one department

An Employee worked on Project for WeekEndingDate as Role for Hours.

If we could express "data facts" in such a manner, it would be much easier
to offer design advice. I am not proposing a strict
specification language, just something where we get an idea of relationships
among tables and and relationships among tables and columns.

Also, posters should at least post their first pass at a solution.

All the best,

Eva n

"John W. Vinson" wrote in message
...
On Wed, 02 Apr 2008 22:35:36 GMT, "Evan Keel"
wrote:

An Employee works on many Projects as Role (examples: Manager, Designer,
QA, etc.
A Project has many Employees working on it.

A Deparment has many Employees
An Employee works in one department

An Employee worked on Project for WeekEndingDate as Role for Hours.

If we could express "data facts" in such a manner, it would be much
easier
to offer design advice. I am not proposing a strict
specification language, just something where we get an idea of
relationships
among tables and and relationships among tables and columns.

Also, posters should at least post their first pass at a solution.

All very good ideas... but how will you inform the unending stream of new
Access designers coming to these newsgroups for the first time? Bear in
mind
that even if we could post a daily FAQ or recommended posting style, very
few
folks would read it.

So... who will bell the cat, asked the mouse?
--

John W. Vinson [MVP]

Hmm..excellent points. I'm not the sharpest knife in the drawer.

Evan

Yes! ER + ORM. The problem with ORM is that it results in very big diagrams.
Every attribute is a symbol. But what ORM and NIAM do well is looking at
the data world as a set of facts.

Evan
"Jeff Boyce" wrote in message
...
Your suggestions seem like a variant on describing entity-relationships,
but
perhaps with an Object-Role twist.

Yes, a "convention" for defining the data requirements could help.

As John points out, folks who don't know/use the convention will still
post
using their own explanations.

And even someone who understands the convention may not understand his/her
situation well enough to define it with that level of precision.
Sometimes
the very first step in designing an application is helping the user
clarify
just what it is s/he is after!

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

"Evan Keel" wrote in message
et...
I've been watching this group for a couple of months now and have
noticed
that most design questions are posed in narrative form. I propose we
come
up
with a "language" to descibe the data requirements. For example:

An Employee works on many Projects as Role (examples: Manager,
Designer,
QA, etc.
A Project has many Employees working on it.

A Deparment has many Employees
An Employee works in one department

An Employee worked on Project for WeekEndingDate as Role for Hours.

If we could express "data facts" in such a manner, it would be much
easier
to offer design advice. I am not proposing a strict
specification language, just something where we get an idea of
relationships
among tables and and relationships among tables and columns.

Also, posters should at least post their first pass at a solution.

All the best,

Eva n