SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Mon, 27 Mar 2006 23:39:04 PST8
From:	"Gregory W. Smith" <gsmith@well.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Data Repository/Directory

Content Type: text/plain

"Lynn H. Maxson" wrote:
> Gosh, Uncle Lynn goes away for a weekend for event political.
> He comes back to view a SQL merry-go-round. Before he left
> he felt good that he didn't miss Bob Blair's presentation at the
> last meeting, as apparently once more presenters extended
> the 55-minute hour beyond all bounds. Maybe the great
> scheduer in the sky will insure at the April meeting, which I
> fully expect to attend, that Bob has enough time on the
> schedule for his "Introduction to PM Progamming"
> presentation. I'm sure Nathan who believes that at least six
> months necessary to get comfortable with PM programming
> would like to see that occur in real time, not SCOUG time.:-)
>
> I didn't want to bother in my description of the Data
> Repository/Directory (DR/D) with anything other than possibly
> implementing it using a relational database manager. In truth
> we have three basic forms of database managers: network,
> hierarchical, and relational. You can implement the DR/D with
> any of them with the same results logically. I would actually
> prefer to use hierarchical for performance reasons as no other
> to date has out hustle IMS or VSE DL/I.

Well, it is nice to know that we don't have to dump our PC's
for mainframes for this project.

> I don't know how Greg overlooked the fact that the "unque
> name" consists of two columns, a 16-byte text name and a
> 4-byte, full-word binary index. The the alias table consists of
> four columns representing the "pairing" of two unique names.
> The "association" comes from having them appear together.

I stand corrected. So the revised schema is something
along the lines of:

CREATE DATABASE Repository;

CREATE TABLE Directory (
Name CHAR(16) NOT NULL,
Seq INTEGER NOT NULL,
Type CHAR(1), /* D, C, or T */
Sturcture CHAR(1) /* E or A */
);

CREATE INDEX DirectoryKey ON Directory (
Name, Seq
);

CREATE TABLE Alias (
PrimaryName CHAR(16) NOT NULL,
PrimarySeq INTEGER NOT NULL,
AlternateName CHAR(16) NOT NULL,
AlternateSeq INTEGER
);

CREATE INDEX AliasKey ON Alias (
PrimaryName, PrimarySeq
);

CREATE TABLE Container (
PrimaryName CHAR(16) NOT NULL,
PrimarySeq INTEGER NOT NULL,
AlternateName CHAR(16) NOT NULL,
AlternateSeq INTEBGER NOT NULL
);

CREATE INDEX ContainerKey ON Container (
PrimaryName, PrimarySeq
);

CREATE TABLE Contained (
Name1 CHAR(16) NOT NULL,
Seq1 INTEGER NOT NULL,
Name2 CHAR(16) NOT NULL,
Seq2 INTEGER NOT NULL,
ContainedName CHAR(16),
ContainedSeq INTEGER
);

CREATE INDEX ContinedKey ON Contained (
Name1, Seq1
);

CREATE TABLE Statement (
StatementName CHAR(16) NOT NULL,
StatementSeq INTEGER NOT NULL,
StatementLenght INTEGER,
Statement TEXT(1024)
);

CREATE INDEX StatementKey ON Statement (
PrimaryName, PrimarySeq
);

CREATE TABLE Elements (
ElementName CHAR(16) NOT NULL,
ElementSeq INTEGER NOT NULL,
StatementLenght INTEGER,
Statement BLOB(4096)
);

CREATE INDEX ElementKey ON Element (
ElementName, ElementSeq
);

CREATE TABLE SeventhTable (
StatementName CHAR(16) NOT NULL,
StatementSeq INTEGER NOT NULL,
StatementLenght INTEGER,
Statement TEXT(1024)
);

> You have three forms of analysis: classification, structure, and
> operation. All three have a membership list under a single
> name. In one, classification, this list can appear in any order,
> meaning that it order is unimportant relative to membership.
> The other two, structure and operation, imposed an order
> upon the member ship. Thus you need two tables, one for
^^^^^^^^^^
> membership within a name, the other for order within the
> membership.

Two tables??? Which two tables? Feel free to use the names
from my schema. And if the schema is wrong, feel free to
correct it. Or add a table or two if what you are talking
about is something other than above.

> Neither has anything to do with how a relational database
> works as long whether or not it returns an ordered list. The
> ordering that occurs here does so by association just as it did
> in the alias table. Thus it remains independent of any
> database manager use.
>
> The DR/D interface, that which sits between the editor and
> the database manager, makes the request, in this instance in
> the form of an SQL query, and constructs the statement order
> based on the "associations" returned, which it then passes to
> the editor for presentation. Thus it does not depend upon SQL
> ordering anything.
>
> Though initially we will use a relational database manager,
> open source or not, eventually in keeping with the only one
> language necessary philosophy this too will need implementing
> in SL/I...or whatever language of choice.
>
> Greg will have to forgive Uncle Lynn for his reliance upon his
> experience with bill of material processing in manufacturing
> and distribution accounts which began with punch cards
> shifted to BOMP (Bill Of Material Processing) files (sequential
> files on tape drives) to DBOMP (Disk BOMP) to DL/I (COPICS)
> (Communications Oriented Production and Inventory Control
> System) using CICS, and more recently (in IBM) to DB2 and
> SQL (in the AS/400). In all of them we had the means to
> produce ordered lists...as in punch cards, files, and
> database.:-)

My experience is also in manufacturing. The manufacturing
plants that I work with produce chemicals, fuels, and/or
energy. And a bill of material is insufficient for these
types of factories. My favoriate example from chemical
engineering is soap. A bill of materials for soap is:
x pounds of fat,
y pounds of caustic,
z BTU of energy.
Good luck making a decent soap from just the bill of materials,
even if x, y, and z are specified to 10 significant figures.

> Thus when I apply manufacturing processing techniques to
> source management because I see "raw material" in source
> statements (code) and in source sentences (text) and their
> different (hierarchical) levels of assemblies I didn't really
> expect anyone to have concerns about whether or not an
> ordered output could result.

Even factories that produce THINGS (other than chemicals)
are very concerned about the order of the operations. The
bill of material is insufficent without assembly drawings
and instructions.

--
Gregory W. Smith (WD9GAY) gsmith@well.com

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================

Return to [ 27 | March | 2006 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.