Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion THe OverRelational Manifesto (ORM)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
U-gene  
View profile  
 More options Apr 6 2006, 11:49 am
Newsgroups: comp.databases.theory
From: "U-gene" <grigorie...@yandex.ru>
Date: 6 Apr 2006 08:49:26 -0700
Local: Thurs, Apr 6 2006 11:49 am
Subject: Re: THe OverRelational Manifesto (ORM)
Thank you. This question seems to be good and I have to take some time
to answer it. But can I answer you? My question is not new for me
because I asked some person who knows D well before but nobody can
answer me. In this question I propose my interlocutors to compare ORM
and TTM.

Little preliminaries. In this example I'm possible inaccurate and I
omit very important subjects (keys for example). And it is big enough.

The long entry.
Goods are shipped from warehouses. We have to know how many goods was
shipped from some warehouse.

//We create type to describe warehouse
CREATE CLASS WAREHOUSE
{
 Name String;

}

GO

//We create type to describe shipment
CREATE CLASS SHIPMENT
{
  //--
  No INTEGER;
  WareFrom WAREHOUSE;
  //--it was information from header of invoice
  ShipmentItems SET OF  //-- and this is a set of invoice lines
  {
    Article STRING;
    Pieces INTEGER;
  }

}

GO

//information of invoice lines implemented as  stored
ALTER CLASS SHIPMENT IMPLEMENT ShipmentItems AS STORED;
GO

//O, I've forgotten about constructors,
ALTER CLASS WAREHOUSE
ADD WAREHOUSE(InitialName STRING)
IMPLIMENT AS
BEGIN
 Name = InitialName;
END
GO

//slightly other way
ALTER CLASS SHIPMENT
ADD SHIPMENT(InitialNo INTEGER, InitialWareFrom WAREHOUSE);
GO

ALTER CLASS SHIPMENT
IMPLIMENT SHIPMENT(InitialNo INTEGER, InitialWareFrom WAREHOUSE) AS
BEGIN
 No = InitialNo;
 Warehouse = InitialWarehouse;
END
GO

//Now I can create a number of new objects in our DB

//create object to describe some warehouse
NEW WAREHOUSE("SomeWarehouse");
//NEW in non-pocedural commands, so I can write...
GO

//create object to describe some shipment...
NEW SHIPPMENT(1, Object(Warehouse<Name = "SomeWarehouse">));
GO

//...and edit this object
INSERT SHIPMENT<No = 1>.ShipmentItems VALUES ("SomeArticle", 100);
GO
...

Now we can create relational variable openly (i mean that we already
have a lot of relational variables created implicitly; i call them
R-variables) and implement it as variable which contain value
calculated on values contained in that, created implicitly R-variables.
One of these R-variables we implicitly created before is R-variable
named as 'Shipment'. In this R-variable scalar attributes named as
'ShipmentItems.Article', 'ShipmentItems.Pieces', 'WareFrom' (and
possible other ones) exist.

CREATE ShippedGoods AS SET OF
{
 Article STRING;
 Pieces INTEGER

}

IMPLEMENT AS
SELECT ShipmentItems.Article,Sum(ShipmentItems.Pieces)
FROM Shipment
WHERE WareFrom<Name = SomeName>
GROUP BY ShipmentItems.Article;
GO

Really variable ShippedGoods is full analogue of view.

It was just entry into my question. The question is much shorter.

With time we have started to sale our goods. So now we have to define
new type to describe sale events. But every sale is a shipment too, so
we define type SALE as subtype of SHIPMENT.

CREATE CLASS SALE
EXTEND SHIPMENT
{
...
SaleItems SET OF
 {
  Article STRING;
  Pieces INTEGER;
  Price FLOAT;
 }

}

GO

//here we have to store information of sale lines
ALTER CLASS SALE
IMPLEMENT SaleItems AS STORED;
GO

Of course, we mustn't forget, that sold quantity of goods have to be
shipped from warehouse. So we have to re-implement inherited component
ShipmentItems as calculated on values contained(stored) in component
SaleItems.

ALTER CLASS SALE
IMPLEMENT ShippedItems AS
SELECT Article, Sum(Pieces)
FROM SaleItems
GROUP BY Article;
GO

So in class SALE information about shipped goods is calculated.

And after the definition of new class SALE we have to do NOTHING on
early defines view ShippedGoods to get information both about real
shipments and about shipments for sales.

In other words in R-variables the information is collected both from
components defined as stored and from components defined as calculated.
A lot of subtypes of type SHIPMENT can exist in system and in each
subtype the component ShippedItems can be re-implemented in different
ways - we must know nothing about it but every time we will get
correct information in early defines view ShippedGoods (of course if
implementation is correct).

Is it possible in D?

Anyway I answer you question in sometime.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.