Re: Schema and Bases in ORACLE?

mkupries_at_rz.uni-potsdam.de ( Mario Kupries) wrote:
>Hello,
>
>
> as in object oriented databases you can define several bases for one
> database schema. Within the bases of the schema you can reference classes and
> objects. Outside the schema these information are encapsulated.
>
> 1.) May I define several bases for one schema as well in ORACLE?
>
> 2.) May I communicate between these bases (no encapsulation)?
>
> 3.) Is the encasulation on schema level realized in ORACLE?

In Oracle's implementation, there is one "database" associated with one or more instances (these are run-time type things). In Oracle-land, "database" refers to the datafiles that implement persistence (datafiles are associated with tablespaces and datafiles contain the data, indices, rollback segments, logfiles, control files, etc.) (This is true for single instance servers but, unfortunately, the terminology gets confused in a parallel server environment.)

In Informix and DB2, the runtime thing can have one or more "databases" and at least for DB2, a "database" is an accounting-type convenience. I don't know personally about the other major rdbms players.

In Oracle (as for most rdbms), a "schema" is really a usercode (or as my first Oracle instructor taught me, "a schema is a sandbox and in that sandbox are the toys we play with -- tables, views, indices, constraints, stored procs.") Technically, an object (not an o-o object but a rdbms object) should be refered to by a multi-part (at least 3) naming convention. I think it goes

<catalog>.<schema>.<object>

In Oracle, to access SCOTT's EMP table running on an Oracle server in Honolulu, you'd say

SCOTT.EMP_at_HONOLULUDB.HAWAIIDOMAIN_at_CHINATOWN

The stuff after the at-sign describes what's called a database link (you create it using the "create database link ..." Oracle sql command). Basically, the link describes the name of the Oracle instance, a domain name and optionally, the specific parallel instance name in the event you're running parallel servers. You also have to add some parameters to the Oracle listener process' init file and entries for the sql*net config files to make the communication stuff work. [This is black magic stuff.]

But yeah, you can "communicate" between different instances. And they can be made "transparent" (thank God for synonyms).

Encapsulation is another matter.

In relational databases, most everything is "public" -- by that, I mean that there is no notion of "public", "private", "protected" interfaces like there is for c++, for instance. By default, things I create in my sandbox are mine alone unless I (or a friendly dba) explicitly grant access to my playthings to a bunch of other people to play with. "Visibility" is controlled on the table (or columns of tables), rows (through views) or stored procedures (through execute privileges). Again, I (or my buddy dba) grants certain kinds of access privileges ("select", "update", "delete", "insert", "drop", and others -- the first four are what you o-o people call "crud") on tables, views, stored procedures and so forth.

I don't know what will happen with Oracle v 8.0 where some of the o-o mechanisms will first appear.

If I'm wrong in any of this, then I'd like to hear from an expert on these (arcane) matters. I often have a hard time talking with you o-o folks when I have my rdbms hat on -- then when I put on my o-o hat, I cannot make myself understood by my dba brothers and sisters.

I hope this helps.

aloha
ayn Received on Wed Jul 03 1996 - 00:00:00 CEST