Re: OOP - a question about database access

"H. S. Lahman" <h.lahman_at_verizon.net> wrote in message news:<3FA6C49F.2020404_at_verizon.net>...

I am crossposting from comp.objects to comp.database.theory because I would like to know also the opinion of the database folks.

> > You probalby meant system instead of application.
>
> No, I meant /application/.

Then you don't use the concepts properly. A GUI application is an application, a DBMS is another application, a data management specialized application. When they work together they form a system.

> > Persistence mechanisms are encapsulated by the DBMS, they are
> > transparent to application developers.
>
> And how does the application solution access the DBMS? It has to pick a
> mechanism like SQL, ODBC, an Oracle engine API, or whatever.

You are calling mechanism to everything. SQL is not a mechanism, it is a language.

The application GUI access the DBMS using a communication layer like ODBC, and using SQL as the communication language.

GUI applications can be viewed as user friendly replacements for the DBMS consoles like Oracle's SQL Plus. In many cases, skilled users could use SQL Plus directly without the need of a taylored GUI application.

> Both that
> access and the DB schema needs to be decoupled from the application
> solution for anything beyond RAD/USER pipeline applications.

What is beyond RAD applications?

> >> That is, the problem solution does not care
> >>if data is stored in an RDB, an OODB, flat files, or clay tablets.
> >
> >
> > The problem solution does not care, but it is essential for the
> > developers to know if the application is communicating with an RDBMS,
> > a file processor, the OS file system etc.
>
> Only the developer providing the persistence access subsystem or layer
> within the application needs to understand that stuff.

The persistence subsystem is a part of the DBMS. Tables are persistent by default, but you can create temporary tables if you want.

Of course the application developer must know if he is accessing to an SQL DBMS or to a mere disk file.

> In particular,
> whatever optimization is required to alleviate the persistence
> bottleneck should be encapsulated away from the application solution.

Yes, in the DBMS. The DBMS manages the physical persistence mechanisms like the hard disks.

> Whoever is developing the solution to the business problem should focus
> on that solution and be completely indifferent to data schemas, access
> mechanisms, and I/O optimization.

How can a data management solution be indiferent to the data representation manipulation model used?

> > The DBMS option is the only sensible if you need more than trivial
> > data management capabilities.
>
> There is a whole world of applications beyond data display.
>
> >
> >>One may use OO to implement the persistence access subsystem or layer,
> >>but that view will be quite different than the business view.
> >
> > One may use OO to implement DBMSes. They must be general purpose
> > DBMSes independent to any business problem.
> >
> > A good DBMS is expensive to build so in most cases you should use an
> > existing one.
>
> Of course. But that doesn't mean the application needs to know which
> one is being used or be affected if one changes one's mind later and
> swaps in another.

True. Standard data management languages and communication protocols are for that, but they are not really standard at practice. Although entry level SQL-92 is widely supported.

With a careful design an SQL DBMS could be replaced by another whithout a high cost. But it is not very frequent. I worked for a company which changed the application development language 6 or 7 times, but the DBMS was always the same (Oracle).

Applications are replaced a lot more frequently than DBMSes.

If you have all your business logic in the centralized database, among many other advantages the applications are easier to replace.

> >>As a result one can abstract persistence mechanisms in terms
> >>of paradigm invariants so that the classes are generic things like
> >>Table, Schema, Row, and Field
> >
> > But it is not an issue for the information system developer because
> > persistence is solved by the DBMS behind the scenes. In many cases it
> > is undocumented.
>
> You seem to be including some sort of data warehousing or data mining
> capabilities in your definition of DBMS that would allow abstract
> queries.

Data warehouses are only a special kind of databases. Data warehouses share several characteristics, and specialized DBMSes can take advantage of the knowledge of such characteristics in order to achieve better performance. Nothing else.

DBMSes should be programmable and extendable. Data mining is also querying.

> For any DBMS I know of the schema had better be documented for
> it to be directly accessible via SQL or whatever.

I don't find sense here.

> >>That application of invariants leads to things like JDBC/ODBC/SQL that
> >>largely hide the mundane details of the mechanisms through automation.
> >
> > JDBC/ODBC are bridges between the application and the DBMS.
> >
> > SQL is the communication language between the application and the
> > DBMS, and it is also the database design language. SQL has three
> > parts: structural, integrity and manipulative.
>
> But they are all infrastructures provided to decouple the application
> from direct communication with the DB engine.

No, they are provided to communicate the presentation application with the DBMS.

> Using them restricts the
> application to very particular and often proprietary modes of
> persistence.

DBMSes free application from the persistence issues. You simply must know that non temporary tables are persistent, and nothing else to say.

But who cares about the physical format the DBMS use?

If you talk about the communication layers like ODBC, ADO.NET, etc. It is rather easy to change one for the other. You only need to touch few code lines if any.

> My issue is about decoupling at a higher level than the DB engine. The
> application solution needs to be independent of those assumptions.

Independent to the data model?

This is an absurd.

> One
> does that by encapsulating those persistence mechanisms within a
> subsystem or layer whose interface is independent of those mechanisms
> (i.e., it manifests the problem solution's view of the data).

Again, the DBMS does that. DBMS exposes only logical data structures. The physical persistence implementation and the physical data structures are hidden to the users.

> One then
> takes advantage of the automation providing such infrastructures by
> using those sorts of paradigms /within/ the subsystem or layer.

One then takes advantage of the automation and abstraction provided by the DBMS.

> >>Bottom line: starting out with an RDB as a central part of the
> >>application
> >
> > System, not application.
>
> No, /application/. In my world a system is usually comprised of
> multiple applications.

Two applications are multiple applications, and you have at least two. The DBMS and the presentation application.

> A corporate accounting group owns a Financial
> system but that system is composed of distinct applications like General
> Ledger, Accounts Payable, Payroll, etc. Each of those applications will
> typically have several subsystems.

Subsystems are systems, and the DBMS is part of the General Ledger system, the Payroll system, etc.

> >>is not going to be very helpful in understanding OO because
> >>a lot of the OO stuff will be hidden in the infrastructures like
> >>JDBC/ODBC and the tools the JDeveloper IDE provides.
> >
> > Agreed, it would be better to try to develop a non data centric
> > system, like a game, a text processor, etc.
> >
> > You typically need very little from OO in order to develop a business
> > information system: An SQL DBMS, a database design script and a client
> > app developed with a RAD, draging and dropping components in forms.
>
> That's only true for a RAD/USER pipeline application.

You can develop any business information system with this approach.

Regards
  Alfredo Received on Tue Nov 04 2003 - 14:09:00 CET