HDTenEightyP/NetNews huggingface dataset:
From: johnmac@fawlty.towers.oz.au (John MacLean)
Subject: Transactions In OSs
Organization: Tower Technology, Sydney
Date: Tue, 8 Sep 1992 23:27:18 GMT

Are there any operating systems (either commercial or research) that
include transaction processing as part of the core operating system.

ie: Can you start a transaction, update two files, and then complete
the transaction; with all the commit and rollback implications.

If so, is there any experimentation going into building a database
system that makes use of these transactions in such a way that both
files and database tables could be updated in a single transaction.

John MacLean.
-- 
This net: johnmac@fawlty.towers.oz.au                   Phone: +61 2 427 2999
That net: uunet!fawlty.towers.oz.au!johnmac             Fax:   +61 2 427 7072
Snail:    Tower Technology, 1 Apollo Pl,                Home:  +61 2 449 5930
          Lane Cove, NSW 2066, Australia.
Newsgroups: comp.databases.theory
From: cdblueth@essex.ecn.uoknor.edu (Chris D Bluethman)
Subject: Normalization and Relations
Date: Wed, 9 Sep 1992 06:17:32 GMT
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK, USA


A question which I am debating...

What are the merits of not putting the zip code attribute
and a state attribute in the same table?  Say an address table.
If you have a relation with last name, street address, phone,
state, and zip, is it really in thrid normal form?  What about
placing zip in this table, and then having state somewhere else?
After all, the zip code does determine the state.  Also can anybody
think of any archives on the net that have text files that talk about
normalization of data? (1NF, 2NF, 3NF, BCNF)  Thanks.  Any help
appreicated...


                                          Chris Bluethman
From: csa09@seq1.keele.ac.uk (Paul Singleton)
Newsgroups: comp.databases.theory
Subject: Re: Normalization and Relations
Date: 11 Sep 92 13:38:18 GMT
Organization: University of Keele, England

From article <gwtn05l.sjs@netcom.com>, by sjs@netcom.com (Stephen Schow):
> There is a methodology called "Extended Relational Analysis" that goes into
> how to design a relational model methodically.
> 
> It basically talks about identifying the entities of your model.  You can
> generally use nouns to refer to these entities.  Each of these entities
> will be represented by a table.

Shouldn't this be: "Each of these entities will be represented by a unique
identifier"?  Simple attributes (e.g. 'name') of these may indeed be stored
in a table.  It seems to me that traditional relational analysis likes to
confuse an entity with a (hopefully) distinguishing attribute of that entity.

I think "functional data modelling" is more careful about this, but I haven't
studied it.

> ... 
> What you have to be careful of is that you could practically call everything
> a noun and get totally out of control trying to normalize your data.  As has
> been said earlier by someone in the group, if a particular entity is not of
> unique interest by itself, or if it does not stand on its own as an entity,
> then it probably shouldn't be one.

Sorry, why would you "get out of control"?  You might get close to the truth.

> There are many exceptions. If you are talking about gobs and gobs of redundant
> data, then it may be worth it.  If you are talking about a one to many
> relation, then it is neccessary.  There are many variables.  But I think it
> is key to try to find a balance between absolute normalization and a more
> conservative approach.

I think it is misguided and hopeless to "try to find a balance ..." without
*first* analysing the application data thoroughly and uncompromisingly.  I
think there should be two data models:

  1)  an exhaustive and fastidious analysis of the application, e.g. with
      attributes such as 'colour' being treated as entities unless we can
      be absolutely sure they are OK as attributes;

  2)  a pragmatic representation schema, deliberately denormalised for
      efficiency and compactness (if necessary), and with all compromises
      *documented* and *rationalised*.

But I've never done this for a living ...
----
  __   __    Paul Singleton (Mr)           JANET: paul@uk.ac.keele.cs
 |__) (__    Computer Science Dept.        other: paul@cs.keele.ac.uk
 |  .  __).  Keele University, Newcastle,    tel: +44 (0)782 621111 x7355
             Staffs ST5 5BG, ENGLAND         fax: +44 (0)782 713082
Newsgroups: comp.databases.theory
From: sjs@netcom.com (Stephen Schow)
Subject: Re: Normalization and Relations
Date: Thu, 10 Sep 92 17:55:28 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

There is a methodology called "Extended Relational Analysis" that goes into
how to design a relational model methodically.

It basically talks about identifying the entities of your model.  You can
generally use nouns to refer to these entities.  Each of these entities
will be represented by a table.

So, for example, if we were designing a personnel database, we might have such
nouns or entities as employee, dept, etc...  

Attributes of employee and dept would be information about them.  They refer
to this in the methodology as modifiers(as in Grammer).  So, if you can say
bla bla of noun, then the bla bla is an attribute of that entity.

What you have to be careful of is that you could practically call everything
a noun and get totally out of control trying to normalize your data.  As has
been said earlier by someone in the group, if a particular entity is not of
unique interest by itself, or if it does not stand on its own as an entity,
then it probably shouldn't be one.

There are many exceptions.  If you are talking about gobs and gobs of redundant
data, then it may be worth it.  If you are talking about a one to many
relation, then it is neccessary.  There are many variables.  But I think it
is key to try to find a balance between absolute normalization and a more
conservative approach.
-- 
------------------------------------------------------------------
Steve Schow    | But you don't have to use the claw, if you
sjs@netcom.com | pick the pear with the big paw paw......
               | Have I given you a clue......?
               |                       - Baloo the Bear
------------------------------------------------------------------
Newsgroups: comp.databases.theory
From: dhepner@cup.hp.com (Dan Hepner)
Subject: Re: Transactions In OSs
Date: Wed, 9 Sep 1992 17:51:10 GMT
Organization: Hewlett-Packard
X-Newsreader: Tin 1.1scd1 PL4

From: johnmac@fawlty.towers.oz.au (John MacLean)

>Are there any operating systems (either commercial or research) that
>include transaction processing as part of the core operating system.

Tolerant Systems produced a distributed Unix which included 
transactions.  This OS is still running in a few places.

>ie: Can you start a transaction, update two files, and then complete
>the transaction; with all the commit and rollback implications.

You can.  And the files can be on separate machines.

>If so, is there any experimentation going into building a database
>system that makes use of these transactions in such a way that both
>files and database tables could be updated in a single transaction.
>John MacLean.

Here was where it never quite added up.  No one wants to write a
DBMS, for excellent reasons.  Existing DBMS products don't ask the 
OS to have transactions, and don't have a sensible way to use OS 
transactions even if they exist.

What we need is an XA compliant Posix filesystem.

Dan Hepner
Newsgroups: comp.databases.theory
From: kaiser@exaib ( Alexander Kaiser)
Newsgroups: comp.databases.theory
Subject: SQL2-Standard
Date: Wed, 9 Sep 92 09:47:21 MESZ
Organization: WU-Wien
Distribution: world
NNTP-Posting-Host: exaib.wu-wien.ac.at


Hello!
We want to buy the SQL2-Standard.
Who can tell me an adress (if possible in Europa) to which we can send our order?


Alexander Kaiser
University of economics and business administration
Department of applied computer science
Augasse 2-6 1090 Vienna/AUstria/Europa

e-mail: kaiser@exaib.wu-wien.ac.at

Newsgroups: comp.databases.theory
From: biesty@ide.com (Bill Biesty)
Subject: Re: Normalization and Relations
Organization: IDE, San Francisco
Date: Wed, 9 Sep 92 20:47:25 GMT

In article <1992Sep9.061732.10792@constellation.ecn.uoknor.edu> cdblueth@essex.ecn.uoknor.edu (Chris D Bluethman) writes:
>What are the merits of not putting the zip code attribute
>and a state attribute in the same table?  Say an address table.
>If you have a relation with last name, street address, phone,
>state, and zip, is it really in thrid normal form?  What about
>placing zip in this table, and then having state somewhere else?
>After all, the zip code does determine the state.  

What your leaving out of the picture is that normalization is
not the end all of data modeling. The Information area is very
important, and generally not available in sytactical form.

So while it is quite possible to normalize the zip code into another
entity with an attribute state, itis rarely done because such
information is not usually interesting. However if you were the
US Post Office, you would probably do it and have additional
attributes like station name, street address, zip code :-)

The textbook example is color. If you're buying a car, color 
is an attribute. If you're manufacturing a car, color is one
or more entities that you use to track, hue, ingredients,
paint manufacturer, number of coats, drying temperature, etc.

Another reason is data stability. The PO changes zip codes, states
and addresses remain much more stable. I have had trouble getting
things mailed to me from mail order places with zip code cross
checking (so they can get the best postal rate) when my zip code
changed. Storing the state, as an override say, is much more
robust that relying on an incomplete code table.

--
Bill Biesty          <biestie@aol.com> (I don't read this too often)
<biesty@ide.com>     These are not the opinions of my employer.
Newsgroups: comp.databases.theory
From: cdk@neptune.dsc.com (Colin Kelley)
Subject: Re: ordered collections
Organization: Digital Sound Corporation
Date: Wed, 9 Sep 1992 16:49:24 GMT

davidm@consilium.com (David S. Masterson) writes:

>>>>>> On 1 Sep 92 15:49:12 GMT, cdk@neptune.dsc.com (Colin Kelley) said:

>> Is there a standard way to implement ordered collections in a relational
>> database that would allow for random insertion?  You could always have a
>> sequence number field to remember the ordering, but if you want random
>> insertion, you may run out of bits in this sequence number and not be able
>> to insert a new entry between two others.

>Well, I don't think there is a standard, but here's one way.

>1. Make the primary key be (sequence_number, current_date).
>2. Generate a new sequence_number for additions to the end of the collection.
>3. Insertion anywhere else uses the sequence_number of preceding item.

I'm confused.  Suppose my collection has entries with these (sequence_number,
current_date) keys:

    (1, 10 Sept 1992 1:00:00)
    (2, 10 Sept 1992 2:00:00)
    (2, 10 Sept 1992 3:00:00)
    (2, 10 Sept 1992 4:00:00)
    (3, 10 Sept 1992 5:00:00)

and at 6:00:00 I want to insert a new entry between the second and third.  It
sounds to me like your algorithm would choose key (2, 10 Sept 1992 6:00:00),
thus forcing me to add the new entry between the fourth and fifth.

Am I missing something?

			-Colin
--
From: roth@ordin.cs.wisc.edu (Bill Roth)
Newsgroups: comp.databases.theory
Subject: Request for info: Efficient updates on Materialzed Relations.
Keywords: deductive, views.
Date: 12 Sep 92 19:45:14 GMT
Organization: University of Wisconsin, Madison -- Computer Sciences Dept.


I'm looking for information regarding efficient updating of
materialized relations(views). If anyone has any references that
they would like to share, please send them to me.

Thanks.

PS: I already have the two Blakeley papers from 1986. More recent
references would be helpful.
-- 

-------------------------------------------------------------------
Bill Roth, University of Wisconsin Computer Sciences Dept.
Internet: roth@cs.wisc.edu. BITNET: ROTH@WISCPSL. HEPNET: PSL::ROTH
From: davidm@consilium.com (David S. Masterson)
Newsgroups: comp.databases.theory
Subject: Re: ordered collections
Date: 10 Sep 92 17:08:20 GMT
	<cdk.716057364@neptune>
Organization: Consilium Inc., Mountain View, California
In-reply-to: cdk@neptune.dsc.com's message of 9 Sep 92 16:49:24 GMT
X-Posting-Software: GNUS 3.13  [ NNTP-based News Reader for GNU Emacs ]

>>>>> On 9 Sep 92 16:49:24 GMT, cdk@neptune.dsc.com (Colin Kelley) said:

> davidm@consilium.com (David S. Masterson) writes:

>>>>>>> On 1 Sep 92 15:49:12 GMT, cdk@neptune.dsc.com (Colin Kelley) said:

>>> Is there a standard way to implement ordered collections in a relational
>>> database that would allow for random insertion?

>>Well, I don't think there is a standard, but here's one way.

>>1. Make the primary key be (sequence_number, current_date).
>>2. Generate a new sequence_number for additions to the end of the collection.
>>3. Insertion anywhere else uses the sequence_number of preceding item.

> I'm confused.

You're right -- I realized later that this didn't make sense... :-(
--
====================================================================
David Masterson					Consilium, Inc.
(415) 691-6311					640 Clyde Ct.
davidm@consilium.com				Mtn. View, CA  94043
====================================================================
"When the government attempts to regulate everything, all is lost."
-- Thibaudeau
Newsgroups: comp.databases.theory
From: u9048979@cc.uow.edu.au (glen eastment)
Subject: Re: What constitutes a 4GL?
Organization: University Of Wollongong
Date: Tue, 8 Sep 92 05:54:10 GMT

dzik@access.digex.com (Joseph Dzikiewicz) writes:

>In article <1992Sep2.025045.9663@cc.uow.edu.au
>>
>>I read somewhere, that the productivity of programmers has only increased by
>>a few per cent since the beginning of computing - if this is true (and I am
>>*not* necessarily saying that it is), then it just about throws out the above
>>theory.
>>

>The explanation that I have heard is that programmers will tend to produce
>the same number of lines of code per day.  With higher order languages,
>a line of code does more.  Therefore, programmers in a higher order language
>are more productive not in terms of lines of code per day, but in terms
>of functionality produced.

That would probably explain it.

>This doesn't explain differences between machine language and
>assembler productivity, but would explain 2GL vs 3GL vs 4GL 
>productivity.

Yes.

>Joe Dzikiewicz

-- 

<GE> a.k.a. u9048979@wampyr.cc.uow.edu.au

_____________________________________________________________________________
Newsgroups: comp.databases.theory
From: sobczak@tplab.enet.dec.com (Piotr Sobczak)
Subject: Re: Transactions In OSs
Reply-To: sobczak@tplab.enet.dec.com (Piotr Sobczak)
Organization: Digital Equipment Corporation
Date: Fri, 11 Sep 1992 10:14:27 GMT


I noticed that the last part of my previous posting got lost.
Here is another attempt.

In my previous message I mentioned DECdtm under VAX/VMS. To answer your last question :

|> If so, is there any experimentation going into building a database
|> system that makes use of these transactions in such a way that both
|> files and database tables could be updated in a single transaction.

DECdtm can coordinate updates from different resource managers.
So yes, you can start a transaction involving both RMS (VAX/VMS flat file system) and Rdb/VMS (DEC's relational database), and all transaction semantics will apply.

I hope this helps.

Piotr Sobczak
Newsgroups: comp.databases.theory
Subject: Re: Transactions In OSs
From: spratt@hawk.cs.ukans.edu (Lindsey Spratt)
Date: Wed, 9 Sep 1992 19:54:59 GMT
Organization: University of Kansas Computer Science Dept


The Multics OS was extended in the early 80s with a "Data Management
System".  This extension involved creating a new file type (DM files),
and associated software to provide transactions/locking/journalling
with any operations done on these DM files. The Multics Relational
Data Store (MRDS) was rebuilt to use the new DM Services (rather than
using the unprotected regular files).

Some modifications were necessary to the hardcore of Multics to
support these DM files - primarily changes to the page control to
integrate the paging and segmentation of DM files with the paging and
segmentation of non-DM (regular) files.
From: carl.pedersen@dartmouth.edu (L. Carl Pedersen)
Newsgroups: comp.databases.theory
Subject: Re: ordered collections
Date: 11 Sep 92 14:51:22 GMT
Followup-To: comp.databases.theory
Organization: Dartmouth College

On 1 Sep 92 15:49:12 GMT, cdk@neptune.dsc.com (Colin Kelley) said:
> 
> Is there a standard way to implement ordered collections in a relational
> database that would allow for random insertion?  You could always have a
> sequence number field to remember the ordering, but if you want random
> insertion, you may run out of bits in this sequence number and not be able
> to insert a new entry between two others.

I'm embarrased to say that Masterson's solution fooled me.  I thought the
only
problem with it was that you couldn't do a bunch of inserts at the same
time -
something I often need to do.

My solution to this is just as you imply:  A floating point sequence
number.  New records get assigned a sequence # between the adjacent two.  I
tell my DBMS to require this key to be unique, so it blows up if I run out
of bits.  In one version of this, I occasionally renumbered - which isn't
*too* hard using ORACLE.

I suppose this is the "standard" technique, but it's ugly and not fully
general.  

Aside from the fact that current systems don't seem to have a solution for
this, I'm not sure there *is* a good solution that is really general and
performs well.

You need to be able to insert between this row and that row.  How do you
specify which row?  Primary key?  What if there is no natural primary key? 
OK, so you put it between the 4th and the 5th one already there, but now
you have changed the ordinal positions of all subsequent records.  Is that
OK?  Maybe.  It's hard to see, though, how this could be efficient for
large collections.

It's easy enough to come up with a scheme for inserting efficiently, and
finding the next record.  You could just have a link to the next record,
based on unique record id - physical address if nothing else.  The problem,
I think, is *specifying* which record you mean.  If the only way to say is
something like, "Put this after the millionth record", we have a problem.

Maybe this just doesn't come up for collections that large.  So far, all of
my applications involve only a few hundred records.
From: miller@cs.rochester.edu (Brad Miller)
Newsgroups: comp.databases.theory
Subject: Re: Transactions In OSs
Date: 9 Sep 92 18:28:22 GMT
Organization: University of Rochester

>Are there any operating systems (either commercial or research) that
>include transaction processing as part of the core operating system.

PERPOS (from Computer Consoles, Inc.; ran on the Tahoe amoung other
machines), did. Nested transactions in fact. You specified which
filesystems were to have an atomic protocol active. Part of the
system also recovered from failure to your TERMINAL so partial
transactions could be recovered from a different terminal (terminals
had to be routed through a separate terminal server from the cpu for
this feature to be active).

PERPOS was intended to be a high-availability operating system for
multiple partially redundant cpus and disks originally developed for
telephony contracts...



--
----
Brad Miller             U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}
-- 
----
Brad Miller             U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}
From: jkim@ece.arizona.edu (Jinwoo Kim)
Newsgroups: comp.databases.theory
Subject: Intelligent Document Retrieval
Date: 4 Sep 92 22:41:16 GMT
Article-I.D.: arizona.1992Sep4.154116.3662
Distribution: world,local
Organization: U of Arizona Electrical and Computer Engineering

Dear Netters,

Does anyone have information about intelligent(?) document
retrieval?  If the user provides a set of documents,
it searches data base or document base using keywords and
find more documents which are relevant to the user input
document. It seems to me that Semantic Net or Neural Net
can be solved this problem (even Genetic Algorithm).

Any comments/references are very much welcomed!

Thanks a lot in advances

      Emil:      jkim@helios.ece.arizona.edu
Newsgroups: comp.databases.theory
From: Lyon_Jim@Tandem.Com (Jim Lyon)
Subject: Re: Transactions In OSs
Followup-To: comp.databases.theory
Organization: Tandem Computers, Inc
Date: Wed, 9 Sep 1992 20:49:56 GMT

In article <1992Sep8.232718.15295@fawlty.towers.oz.au>,
johnmac@fawlty.towers.oz.au (John MacLean) wrote:
> 
> Are there any operating systems (either commercial or research) that
> include transaction processing as part of the core operating system.
> 
> ie: Can you start a transaction, update two files, and then complete
> the transaction; with all the commit and rollback implications.

Tandem's Guardian system has had this capability for about 12 years.
Each file has an attribute that says whether updates to that file
belong to transactions.  This transaction manager existed long before
relational databases a la SQL became popular; we implemented SQL as
another object manager using the same transaction manager.


-- Jim Lyon                          "... where the work is NonStop,
   Lyon_Jim@Tandem.Com                    and we do everything twice."
From: Mark_Sherman@transarc.com
Newsgroups: comp.databases.theory
Subject: Re: transaction processing - DBMS vs TP monitor
Date: 4 Sep 92 14:09:07 GMT
Article-I.D.: transarc.Eedxu3P0Bwxd8B=XwQ
	<1992Aug26.183837.15241@anasaz>
Distribution: usa
Organization: Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.databases.theory: 26-Aug-92 Re: transaction
processing .. Brian Douglass@anasaz (3684)

> On standards, you have the X/Open XA standard to handle the 2PC prototocol,
> and the Posix DTP work group (I forget the number) working to define
> interfaace standards.  In fact, I heard a rumor recently that Tuxedos ATMI
> interface was adopted by the Posix group as the standard interface between
> thepplication. application and TM (anyone have facts?).

The X/Open group has not adopted ATMI as "the standard interface between
the application and TM". As per the X/Open DTP model, the standard
between the application and the TM is called TX, and I think that work
will be progressing soon for public review.
		-Mark
Newsgroups: comp.databases.theory
From: sobczak@tplab.enet.dec.com (Piotr Sobczak)
Subject: Re: Transactions In OSs
Reply-To: sobczak@tplab.enet.dec.com (Piotr Sobczak)
Organization: Digital Equipment Corporation
Date: Thu, 10 Sep 1992 16:29:04 GMT


In article <1992Sep8.232718.15295@fawlty.towers.oz.au>, johnmac@fawlty.towers.oz.au (John MacLean) writes:
|> Newsgroups: comp.databases.theory
|> Path: uvo.dec.com!rdg.dec.com!news.crl.dec.com!deccrl!caen!uunet!munnari.oz.au!metro!ipso!fawlty!johnmac
|> From: johnmac@fawlty.towers.oz.au (John MacLean)
|> Subject: Transactions In OSs
|> Organization: Tower Technology, Sydney
|> Date: Tue, 8 Sep 1992 23:27:18 GMT
|> Message-ID: <1992Sep8.232718.15295@fawlty.towers.oz.au>
|> Sender: johnmac@fawlty.towers.oz.au (John MacLean)
|> Lines: 16
|> 
|> Are there any operating systems (either commercial or research) that
|> include transaction processing as part of the core operating system.
|> 
VAX/VMS includes DECdtm (Distributed Transaction Manager) as of V5.4

|> ie: Can you start a transaction, update two files, and then complete
|> the transaction; with all the commit and rollback implications.
|> 
Yes
Newsgroups: comp.databases