A proposal for specifying data requirements

  • Thread starter Thread starter Evan Keel
  • Start date Start date
E

Evan Keel

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
 
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.
Click to expand...

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?
 
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
 
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.
 
John W. Vinson said:
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?
Click to expand...

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

Evan
Click to expand...
 
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
 
Back
Top