Introduction to Sample system

Introduction:

Most large institutions have now a lot invested in a data base system. Generally they have automated such clerical tasks as order entry, inventory control or billing. These systems habitually support a worldwide network of hundreds of terminals. Their function is to reliably store and retrieve large quantities of data. The life of several institutions is critically dependent on such systems when the system is down the corporation has amnesia.

This puts a huge burden on the implementers and operators of such systems. The systems should on the one hand be very high performance and on the other hand they must be very reliable.

Sample system:

Possibly it is best to begin by giving an example of such a system. A large bank may perhaps have one thousand teller terminals (several have 20,000 tellers however at present no single system supports such a large network). For every teller there is a record describing the teller's cash drawer and for each branch there is a record describing the cash position of that branch (bank general ledger) It is probable to have several million demand deposit accounts (say 10,000,000 accounts). Associated with every account is a master record giving the account owner the account balance and a list of recent deposits and withdrawals applicable to this account. This database inhabits over 10,000,000,000 bytes and must all be on-line at all times.

The database is control with application dependent transactions which were written for this application when it was installed. There are several transactions defined on this database to query it and update it. A particular user is authorized to invoke a subset of these transactions. Invoking a deal consists of typing a message and pushing a button. The teller terminal adds the transaction identity, teller identity as well as terminal identity to the message and transmits it to the central data manager. The data communication manager obtains the message and translates it to some canonical form.

It subsequently passes the message to the transaction manager which validates the teller's authorization to invoke the specified transaction and then allocates and dispatches an instance of the transaction. The transaction processes the message and generates a response and terminates. Data communications transports the message to the teller.

Possibly the most common transaction is in this environment is the DEBIT_CREDIT transaction which takes in a message from any teller debits or credits the appropriate account (after running some validity checks) adjusts the teller cash drawer and branch balance and then sends a response message to the teller. The transaction flow is:

DEBIT_CREDIT:
BEGIN_TRANSACTION;
GET MESSAGE;
EXTRACT ACCOUT_NUMBER, DELTA, TELLER, BRANCH
FROM MESSAGE;
FIND ACCOUNT(ACCOUT_NUMBER) IN DATA BASE;
IF NOT_FOUND | ACCOUNT_BALANCE + DELTA < 0 THEN
PUT NEGATIVE RESPONSE;
ELSE DO;
ACCOUNT_BALANCE = ACCOUNT_BALANCE + DELTA;
POST HISTORY RECORD ON ACCOUNT (DELTA);
CASH_DRAWER(TELLER) = CASH_DRAWER(TELLER) + DELTA;
BRANCH_BALANCE(BRANCH) = BRANCH_BALANCE(BRANCH) + DELTA;
PUT MESSAGE ('NEW BALANCE =' ACCOUNT_BALANCE);
END;
COMMIT;

At peak ages the system runs about thirty transactions per second with a response time of two seconds.

The DEBIT_CREDIT transaction is extremely ‘small’. There is one more class of transactions that behave rather differently. For instance once a month a transaction is run which produces a summary statement for every account. This transaction might be explained by:

MONTHLY_STATEMENT:
ANSWER :: = SELECT *
FROM ACCOUNT, HISTORY
WHERE ACCOUNT. ACCOUNT_NUMBER = HISTORY. ACCOUNT_NUMBER
AND HISTORY_DATE > LAST_REPORT
GROUPED BY ACCOUNT. ACCOUNT_NUMBER,
ASCENDING BY ACCOUNT. ACCOUNT_ADDRESS;

That is collect every recent history records for each account and place them clustered with the account record into an answer file. The answers emerge sorted by mailing address.

If every account has about fifteen transactions against it per month then this transaction will read 160,000,000 records and write a similar number of records. A naive functioning of this transaction will take 80 days to execute (50 milliseconds per disk seek implies two million seeks per day.) Nevertheless the system should run this transaction once a month and it must complete within a few hours.

There is a broad spread of transactions among these two types. Two particularly interesting kind of transactions are conversational transactions that carry on a dialogue with the user as well as distributed transactions that access data or terminals at several nodes of a computer network.

Systems of 10000 terminals or 100000000000 bytes of on-line data or 150 transactions per second are in general considered to be the limit of present technology (software and hardware).

Latest technology based Operating System Online Tutoring Assistance

Tutors, at the www.tutorsglobe.com, take pledge to provide full satisfaction and assurance in Operating System help via online tutoring. Students are getting 100% satisfaction by online tutors across the globe. Here you can get homework help for Operating System, project ideas and tutorials. We provide email based Operating System help. You can join us to ask queries 24x7 with live, experienced and qualified online tutors specialized in Operating System. Through Online Tutoring, you would be able to complete your homework or assignments at your home. Tutors at the TutorsGlobe are committed to provide the best quality online tutoring assistance for Operating System Homework help and assignment help services. They use their experience, as they have solved thousands of the Operating System assignments, which may help you to solve your complex issues of Operating System. TutorsGlobe assure for the best quality compliance to your homework. Compromise with quality is not in our dictionary. If we feel that we are not able to provide the homework help as per the deadline or given instruction by the student, we refund the money of the student without any delay.