Re: New theories on how we are artificial intelligence.

"Neo" <neo55592_at_hotmail.com> wrote in message news:4b45d3ad.0305191247.1ff775ab_at_posting.google.com...
> > > > People here believe that we are tuples in a huge database.
> > >
> > > Yes, but they are not talking about a relational database where a
> > > tuple's degree is restricted by the relation(table) that it belongs
> > > to.
> >
> > If one didn't particularly care what names relation variables are given,
then
> > tuples of any degree and of any type can be freely put in a relational
> > database.
>
> It is true that tuples with a relation (table) can have any arbitrary
> degree but they all must be of the same degree. It is possible that
> different tuples with in a single relation can have different degrees?

I suppose the answer to that question is based on definition of or the preciseness of any give person's definition of a relation (the degree to which the purity of the model is maintained). For example, when considering derived relations and generalization/specialization type relationships materialized to show all parent type entity instances along with specialization instances in a single view. With SQL and nulls, this gives the appearance of a ragged edge because of the differences in degree of disparate tuple specializations within the set. On the other hand, with the lack of null values, sentinal values would make tuple size degree appear homogeneous:

For example, a view defined on top of a transaction generalization with purchase order and shortage transaction specializations.

VAR transactions BASE RELATION

{ transaction_id  #gen_trans_id#,
  transaction_date #date_time#,
  transaction_type #transaction_type# }

VAR purchase_orders BASE RELATION
{ transaction_id #gen_trans_id#,

   ordered_from #vendor_code#,
   item_number #vendor_item_number#,
   quantity_ordered #number#,
   vendor_uom #vendor_uom_code# }
   PRIMARY KEY {transaction_id}
   FOREIGN KEY { transaction_id} REFERENCES transactions;

VAR shortages BASE RELATION
{ transaction_id #gen_trans_id#,

   shortage_qty #number#,
   item_number #stock_item_number#,
   item_uom #item_uom_code# }
PRIMARY KEY {transaction_id}
FOREIGN KEY {transaction_id} REFERENCES transactions;

CONSTRAINT trx_disjoint_specialization IS_EMPTY ( purchase_orders {transaction_id} JOIN shortages {transaction_id})

VAR transactions_view VIEW
  (EXTEND transactions ADD 'NA' AS ordered_from,

                                                'NA' AS vendor_item_number,
                                                -1 AS qty_ordered,
                                                'NA' as vendor_uom,
                                                -1 as shortage_qty,
                                                 'NA' as stock_item_number,
                                                 'NA' as item_uom)
     UNION
   (EXTEND (transactions JOIN
                    (purchase_orders
                           RENAME item_number AS vendor_item_number) )
    ADD -1 as shortage_qty,
              'NA' as stock_item_number,
              'NA' as item_uom)
     UNION
    ( (EXTEND transactions ADD 'NA' AS ordered_from,
                                                  'NA' AS
vendor_item_number,
                                                  -1 AS qty_ordered,
                                                  'NA' as vendor_uom)
                JOIN
                    (shortages
                          RENAME item_number AS stock_item_number) )

Couldn't tuple types be restricted by both name and relation type (i.e. VAR <name> BASE RELATION vs. VAR <name> VIEW)? If so, it seems names could be repeated over different tuple types.

Regards,

Dan Guntermann
>
> Is this similar to the name of a set defining the type of its
> elements?
>
> > If you have no restriction on the tuple types you want in your database,
> > then define a database where you don't need to give each relvar
> > a particular name...
>
> Couldn't a tuple be restricted by its attributes alone, where the
> relation it belongs to is no different that any other attribute? Or
> looking at it the other way, doesn't a tuple simply belong to multiple
> relations?
Received on Tue May 20 2003 - 02:45:07 CEST