Re: Designing DB in accordance with the relational model
Date: Thu, 11 Nov 2010 02:48:10 -0800 (PST)
Message-ID: <b5e63db1-cc25-4a06-a559-97d7b05952b0_at_j18g2000yqd.googlegroups.com>
On 11 nov, 00:54, Kentauros <joker..._at_gmail.com> wrote:
> On Nov 11, 12:39 am, Hugo Kornelis
>
> <h..._at_perFact.REMOVETHIS.info.INVALID> wrote:
>
> On Nov 11, 12:10 am, Erwin <e.sm..._at_myonline.be> wrote:
>
> > ??????
>
> > By including a relvar for that purpose in your DB design. Plus the
> > needed relvars or attributes for documenting how characters relate to
> > games.
>
> Allright. The second approach.
>
> TYPE GAME POSSREP GAME {S CHAR};
> TYPE ELEMENT POSSREP ELEMENT {S CHAR};
>
> TABLE Games {Game GAME, OrdinalNumber INT}
> PRIMARY KEY {Game};
> TABLE CharactersExistence{Character# CHAR_ID, CharacterName CHAR,
> Game GAME}
> PRIMARY KEY {Character#, Game},
> FOREIGN KEY {Game} REFERENCES TO Games;
> TABLE ElementsExistence{Element ELEMENT, Game GAME}
> PRIMARY KEY {Element},
> FOREIGN KEY {Game} REFERENCES TO Games;
>
> But it seems that the table Characters has to go — characters have
> different sets of characteristics in different games,
Then you need a relvar(/table) for the predicate "<character> has characteristic <characteristic> in game <game>.".
> and I can't
> predict what will (dis)appear or which remained characteristic change
> -- except for name. I think I'd want to have a relation with predicate
> like "Characteristic <Name> with type <Type> existed in game <Game>",
> and I know how to do this... but I'm afraid of it and won't do it.
Well, then we're basically done talking.
