Welcome Guest Search | Active Topics | Members | Log In

Definicje interfejsów - po co jest "feature"? Options · View
KK
Posted: Thursday, December 16, 2004 12:48:53 PM
Rank: Advanced Member

Joined: 12/7/2004
Posts: 226
Points: 30
michal wrote:

zeby zbudowac taka metabaze, musimy porozwijac Osobe,
poniewaz chcemy dopuscic kazde zapytanie typu
os(.dziecko)*.imie. to oznacza, ze hierarchia w obiekcie
reprezentujacym w metabazie klase osoba,
musialaby byc nieskonczenie dluga, aby mozna bylo
statycznie wyewaluowac takie zapytanie. trzeba
by zatem zbudowac cos takiego, co oczywiscie nie jest mozliwe:


Quote:

natomiast jesli zrobimy sobie (w metabazie!) w obiekcie dziecko
referencje na osobe, to wszystko jest ok:

Code:
entry
+--Osoba
  +--imie
  +--dziecko -> Osoba



A skąd będziemy wiedzieli, w którym miejscu w strukturze metabazy wstawić referencję zamiast obiektu? Mój przykład z domem pokazuje, że cykl rekurencyjny może być długi i złożony.

Quote:

3. w metabazie zagniezdzania zatem nie ma, sa tylko referencje (czyli jest
tak jak chce KK), natomiast w bazie danych zagniezdzanie jest
(czyli tak jak chce KS). to oznacza, ze dopuszczalny jest np. taki obiekt:

Code:
+--Osoba
   +--imie="Jan"
   +--dziecko
      +--imie="Stefan"
      +--dziecko
         +--imie="Felek"



Skoro w metabazie będziemy zamieniać (niejawnie) obiekty na referencje i bedziemy akceptować i to i to, to po co nam dwa rodzaje bytów (tym bardziej, że mamy te elipsy, o których dowiedziałem się z innego wątku)?

Quote:

podsumowujac, z punktu widzenia jezyka dobre jest zarowno:

Code:
class Osoba {
  imie : string;
  dziecko<0..*> : Osoba;
}


jak i:

Code:
class Osoba {
  imie : string;
  dziecko<0..*> : ref Osoba;
}



Rozumiem, że różnica jest teraz tylko taka, że w pierwszym przypadku Dziecko nie może być jednocześnie dzieckiem w innej Osobie. A w drugim może. Różnica jest wyłącznie semantyczna bo w bazie danych jak pokazał Michał będzie tak samo. Tak?

michal
Posted: Thursday, December 16, 2004 1:23:51 PM

Rank: Advanced Member

Joined: 12/6/2004
Posts: 332
Points: -61
Quote:
A skąd będziemy wiedzieli, w którym miejscu w strukturze metabazy wstawić
referencję zamiast obiektu? Mój przykład z domem pokazuje,
że cykl rekurencyjny może być długi i złożony.


jezeli w metabazie reprezentujemy podobiekt o nazwanym typie
zlozonym, to zawsze beda referencje. np.:

Code:
class Osoba {
    imie : string;
    dziecko<0..2> : Osoba;
    rodzic<0..2> : ref Osoba;    
}


to mamy:

Code:
Osoba
+--+--imie
   +--dziecko -> Osoba
   +--rodzic -> Osoba


przyklad z domem nie stanowi moim zdaniem problemu, bo tylko
od programisty zalezy jak duzy bedzie poziom zagniezdzania
juz w konkretnych obiektach bazy danych. wazne jest
to, zeby metabaza sobie z tym poradzila, czyli zeby
dla metabazy poziom zagniezdzania byl skonczony.
a to daja nam wlasnie referencje.

jezeli zatem sprawdzamy zapytanie pod wzgledem typologicznym,
to to by nam wystarczylo. drobnym problemem jest tutaj
operacja podstawiania, bo jezeli metabaza widzi
ze i to jest referencja i to jest referencja, to skad
typechecker ma wiedziec czy na dziecko mozna podstawic
ref Osoba czy Osoba? mysle ze mozna to rozwiazac
wprowadzajac do metabazy dwa rodzaje referencji
na oba te przypadki

Quote:
Skoro w metabazie będziemy zamieniać (niejawnie) obiekty na referencje
i bedziemy akceptować i to i to, to po co nam dwa rodzaje bytów
(tym bardziej, że mamy te elipsy, o których dowiedziałem się z innego wątku)?


moim zdaniem z obu wersji mozna korzystac prawie dokladnie tak samo.
roznica jest tylko na poziomie fizycznym, tzn. albo obiekt
jest fizycznie zagniezdzony (i jest usuwany razem z nadobiektem), albo nie.
stencel
Posted: Thursday, December 16, 2004 6:50:46 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
michal wrote:
1. Zagniezdzanie obiektow jest konieczne, chociazby znowu dlatego:

Code:
module SuperAplikacja {
  p : Employee;
  Prac : Employee;
  Emp<0..*> : Employee;
}


jezeli zatem w modulach obiekty maja byc zagniezdzone, to w innych
obiektach zlozonych tez musi byc taka mozliwosc.


Tak, tak, tak. Dziekuje Michale za "modulowy" zdrowy rozsądek. I znow moduly uratowaly zdrowy tok myslenia (tak jak przy niezmienniczosci nazw). Ze wzgledu na moduly musi byc dowolne zagniezdzanie.

I kropka.

michal wrote:
natomiast jesli zrobimy sobie (w metabazie!) w obiekcie dziecko referencje na osobe, to wszystko jest ok:


I tak rzeczywiscie jest. Otworzcie Księgę Ksiąg w rozdziale 10 strona 417. Tam jest informacja jakie sa rodzaje linkow w grafie schematu (metabazie). Sa nimi:

* is_owner_of (reprezentuje zagniezdzenie)
* points_to (reprezentuje referencje)
* inherits_from (reprezentuje dziedziczenie).

Oczywiscie w metabazie nie ma zagniezdzania (nawet obiektow prostych), wiec jest elegancko i jednolicie.

michal wrote:
mysle ze mozna to rozwiazac wprowadzajac do metabazy dwa rodzaje referencji na oba te przypadki


To z ostatniego Twojego postu. Tak rzeczywiscie jest (zgodnie z Księgą). To sa dwa rozne linki w metabazie (is_owner_of i points_to)

michal wrote:
moim zdaniem z obu wersji mozna korzystac prawie dokladnie tak samo. roznica jest tylko na poziomie fizycznym, tzn. albo obiekt jest fizycznie zagniezdzony (i jest usuwany razem z nadobiektem), albo nie.


Fizycznie moze byc rozmaicie (pointer mozna implementowac zagniezdzeniem i odwrotnie), natomiast my rozmawiamy o poziomie logicznym, gdzie rozroznienie zagniezdzenie/pointer jest istotne.

Users browsing this topic
Guest


Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Main Forum RSS : RSS

Powered by Yet Another Forum.net version 1.9.1.6 (NET v2.0) - 11/14/2007
Copyright © 2003-2006 Yet Another Forum.net. All rights reserved.
This page was generated in 0.073 seconds.