*   a DBMS can provide many capabilities,
    but amongst those it really MUST provide
    include:
    *   DDL - data definition language
    *   DML - data manipulation language
    *   DCL - data control language

*   we are going to be trying out two SQL statements,
    grant and revoke, which can be said to provide
    part of a a DCL for a DBMS thast implements SQL;

*   grant and revoke allow for more finely-controlled
    access to objects in a database
    (and a database administrator, a DBA, often
    has additional DCL tools as well)

    *   levels of access:
        *   insert
        *   delete 
	*   update
        *   select

    *   syntax for the basic grant SQL statement:

        GRANT comma-separated-privilege-list
        ON object-name
        TO comma-separated-user-list;

        ...and now those users have those level(s)
	of access to that database object;

    *   syntax for the basic revoke SQL statement:

        REVOKE comma-separated-privilege-list
        ON object-name
        FROM comma-separated-user-list;

        ...and now those users DO NOT have those level(s)
	of access to that database object;

*   when you are in sqlplus,
    your work is temporary -- kind of a separate 
    sandbox -- until it is COMMITTED;

    Oracle sqlplus GIVES you autocommits in
    several situations:
    *   when you change the database STRUCTURE
        (say, create table or drop table)

    *   when you properly exit sqlplus

*   what if you want to say, do a commit NOW?
    use the SQL command:

    commit;

    what if you DON'T want some change(s) that
    you have made since the previous commit?
    *   you do the SQL command:

    rollback;

    NOTE: this undoes ALL changes SINCE the
    latest commit;

    (and no, you can't rollback again to go
    to BEFORE that last commit...)

--------
back to	Reading	Packet 3!

*   some KEY-related definitions:

*   a SUPERKEY is a group of one or more 
    attributes that UNIQUELY identifies
    a row in a relation
    (no matter how many rows there may be
    in that relation,
    based on the "rules" of that scenario,
    based on the functional dependencies
    in that scenario...)

    *   note that every true relation
        has at least one superkey --
	the set of ALL of its attributes!
	(since a relation cannot contain
	duplicate tuples!)

*   a superkey is MINIMAL if no subset
    of that superkey is ALSO a superkey

    (this is not saying it has the
    least number of attributes --
    it is saying you can't take away
    any of its attributes and still
    be a superkey)

*   such minimal are also called
    CANDIDATE keys;

    ...they are CANDIDATES for being selected
    to be a particular relation's PRIMARY key

    (so a primary key is the candidate
    key of a relation that you chose to
    be the primary key)

*   COURSE STYLE STANDARD:
    every relation you define is expected
    to have an EXPLICITLY declared
    suitable primary key!