Packages and the big picture

Question

Hitting the chapter on subprograms and packages in the 2-day developer guide brought up material that is completely new to me, so I'm trying to think my way through it and hoped you guys might help me put some of the pieces together into at least a rough overall picture of how this works.
Here's one statement that particularly caught my eye: "Many Oracle customers allow client programs to access the databases only by calling subprograms."
To help explicate this, I'll take as an example a company with a sizeable plant near where I live: Baldor, which makes electric motors. That seems at least roughly like the kind of company that would fit the model of the hr database that Oracle provides as example--big enough to have multiple office locations, decent sized IT department but also lots of users who have no clue with regard to the inner workings of the database but who all still need to acces data of various kinds.
Now suppose I (picturing myself with a good deal more knowledge than I currently have) am supposed to be developer for an Oracle database that is going to handle Baldor's data of various kinds. Aside from the obvious intricacies of setting up all the tables and their interrelationships, what I'm wondering (particularly since I'm coming from Access, where issues of this kind are outside the scope of the program) is how to picture the various interfaces for various user-types.
They're going to have their administrators, who will know how the program works and how to tweak it to improve performance and all that. And they are skilled enough to use several possible interfaces, maybe develop their own, maybe just use one of the various access options that Oracle has in the drawer.
But now, back to the packages and subprograms issue, which is the point of departure for my question: Am I supposed to set the database up so that everything that the non-IT guys in accounting, HR, sales, etc. need is set up in subprograms (that need to be designed accordingly) and will then be presented in various kinds of front ends (generated in whatever programming languages) that non-IT people can comfortably use and which provides additional protection for keeping consistent and accurate data in a context where lots of people are dealing with (and editing) it--i.e, the subprograms provide additional control over how the data is manipulated by the various non-IT people who need it and work with it.
Is that the basic idea of how the subprograms and procedures fit into the overall scheme of things in Oracle?

Answer 1

SQL and PL/SQL (or SQL Server, or MySQL, or ?? implementations of procedural SQL, for that matter) is a specialized skill set. My experience is that Java, .NET, VB, Python, Ruby on Rails, (or whatever comes next) programmers tend to not be very strong in SLQ or PL/SQL. Packages or procedures and functions provide a way to protect the database from these programmers. It also serves to allow more freedom in the front end development because the business rules and logic reside with the data and does not have to be recreated and tested whenever the front end language or platform changes. Used to be Mainframe with CICS, IDMS, IMS. Then client server. Now browser based applications. Next Smart phone applications. After that, who knows. But the data and business logic remains, the only thing that changes is how you get to it.
HTH