mainframe Database question 
Author Message
 mainframe Database question

I don't know if this is the right newsgroup, but you guys are pretty
knowledgeable so....

I am putting up a quick and dirty simple CICS system at work.  One
screen will accomodate all fields.  One update screen (and one read only
inquiry screen.)

I wanted a VSAM file with one record per a unique key (one record
appearing on a screen.)  Seemed simple enough to me.

Our data base people got a hold of it and no no no!  They wanted a
detailed explanation of the entire system and all the fields.  They are
now "normalizing" my data record, and say there will be at least several
keys.

Quite frankly, I think they'll milking this project.  I fail to
understand why I need multiple segments.  My batch reports, which were
gonna come via sorting the file as I needed it for a report, will now be
a pain.  A programmer has also started the online part, and I'm afraid
she'll have to rewrite the program.  We have a tight deadline and
limited budget.

Could someone tell me what "normalization" is?  For a project this
simple, is all this stuff really necessary?  Won't this stuff add
unnecessary I/O overhead to each transaction---more than any benefit?
 (When I read the file to fulfill an inquiry, I will need EVERY field to
fill the screen---so what's the point of breaking the file into pieces?)

Thanks.



Mon, 29 Dec 1997 03:00:00 GMT  
 mainframe Database question

Quote:
>Could someone tell me what "normalization" is?  For a project this
>simple, is all this stuff really necessary?  Won't this stuff add
>unnecessary I/O overhead to each transaction---more than any benefit?
> (When I read the file to fulfill an inquiry, I will need EVERY field to
>fill the screen---so what's the point of breaking the file into pieces?)

The only reason I could think of for normalizing would be if some of your
data duplicated data already kept by the system.

Normalizing is a method applied to a database design to break it down so
that each record represents a single entity. You don't mix addresses with
credit history with other statistics, etc. You break it down and then tie it
together with common keys. While it seems like a pain for the initial
development, in the long run, it makes things easier to maintain and expand.

What you designed is probably perfect for your project, but what project
ever remains the same or isn't changed and expanded over time? The idea is
to make the task of going back into it and making changes easier down the
road.

You might see if you can get them to explain their reasoning, and if it
still seems like overkill, then try to work out a compromise that is
acceptable to both of you.



Mon, 29 Dec 1997 03:00:00 GMT  
 mainframe Database question

Quote:
>Per Robert's note...
>Thanks for your comments.

>I have no duplicate data.  All fields relate to each other.

>I've also learned that the database analyst assigned to my project is
>new at this, and following orders from above.  Sadly, I think this is a
>case of office politics, where the data base group is pushing their
>views unnecessarily just to justify their existence.  My mgmt has
>ordered me to go along with whatever they ask for, without discussing
>the merits.  (In other words, they don't want to {*filter*}heads.)

sigh....   The more things change, the more they stay the same.
--


WB0GNO          |  on CompuServe:  72103,443
                |  via snail-mail: 81230-1371


Tue, 30 Dec 1997 03:00:00 GMT  
 mainframe Database question
Per Robert's note...

Thanks for your comments.

I have no duplicate data.  All fields relate to each other.

I've also learned that the database analyst assigned to my project is
new at this, and following orders from above.  Sadly, I think this is a
case of office politics, where the data base group is pushing their
views unnecessarily just to justify their existence.  My mgmt has
ordered me to go along with whatever they ask for, without discussing
the merits.  (In other words, they don't want to {*filter*}heads.)



Tue, 30 Dec 1997 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. ST Mainframe databases

2. Mainframe APL2 Question

3. Mainframe speed (was Floating Point Questions)

4. mainframe question

5. mainframe question

6. A Question Re: CLIPPER 5 Talking to Mainframes

7. New to REXX, Mainframe Screen Submit Job Question

8. Academic question - re: mainframes/PC

9. Mainframe COBOL JCL question

10. Some questions about ICL Mainframe COBOL.

11. cobol ii - mainframe question

12. MAINFRAME/DB2 question

 

 
Powered by phpBB® Forum Software