Information Technology Reference
In-Depth Information
account number,
will always be generated by the system. If our report had fifty accounts, they would all be
in ascending order with the lowest key first and the highest last. Recalling the restriction
on account number being greater than 9, there is a very good chance that the first record
would have an account number of 10, followed by 11 and 12. However there could be
gaps in the numbers, as we shall see later.
Some computer systems will lock you out of a file if someone else is updating it.
Thus if someone was updating a record in our account file, we may not be able to read
any record in the file. Our system will be a little more permissive, having been designed
by liberals. If someone else is updating the record with account number 395123867, we
won't be able to update that specific record but we can read it and we can read or update
any other record in the file. If two people are updating the file at the same time, most
likely they won't be on the same record but if they just happen to be, we need to take
some precautions.
If two people want to update the record with account number 395123867 at the
same time, one of the two people will get to it first. Let us say that Pat is that person and
he changes the zip code from 14225 to 14229, but he hasn't done the actual updating just
yet. Just before Pat completes the update Chris accesses the same record and the zip code
still has the value 14225. She changes the middle initial from L to P and Pat does his
update, resulting in the new zip code in the record. But then Chris does her update and the
middle initial now is P but the zip code has been returned to the value of 14225, not what
Pat had intended. The changed value has been overlayed. We cannot allow this to happen
and I will get to how this is handled when we work on an update program. I think you can
see that locking the record temporarily should work and not locking the entire file means
that both can update different records at the same time. That would be the way to design
the system.
Designing the files is done by a DBA or data base analyst. He or she does this
with input from other people for efficiency. After all you don't want a file designed that
requires long waits by the users in getting at the data. You also don't need redundant data,
as a field that occurs twice in the file just uses precious space. You also don't want to
keep changing the file definition month after month. This means time needs to be spent
on analysis and design. In our account file our key may actually be larger than we need
but that is something that needs research. I recall a system that I worked on that had three
positions for a transaction code when two might have been sufficient since there weren't
any transaction codes bigger than 99.
That whole consideration of trying to save two digits for dates by using only two
positions for the year instead of four is what caused the Y2K fiasco. I won't get into that
but you can see where time spent planning can save a great deal of time later. There is
much to be considered and if you're working on a project where all the ideas and design
of the system are not firmly in place, it will be impossible to come up with a database
design that will suit everyone and keep management happy. The design of the files will
have to wait.
These are just some problems involved in information technology systems and
you will run into them no matter where you work. The better the system is thought out,
