Re: Help with this db design
Re: Help with this db design
- Subject: Re: Help with this db design
- From: Gustavo Pizano <email@hidden>
- Date: Fri, 21 Mar 2008 17:54:12 -0500
ok so im making it more clear...
The problem to solve it's to implement a Convocation system. So People
can apply to a convocation that is open in the moment (thats why in
table convocation I have a state attribute as boolean). The people
that apply have attributes (the one I puttted in the table Person, the
id attribute its (if I finally understood) the attribute to identyfy a
person in the db and that info its not relevant to the user but the
db). So the people apply to a convocation and the db has 2 tables with
pre-established data, this is the Speciality and the study Level. The
person can only have a study level when applying, but it can have 1 or
more Specialties .
As far as I understand there is gonna be one Convocation opened at a
time, but I should keep record of the people who has applied to an X
convocation, letting me know that a person can apply to 1 or more
convocation. (I hav not clear this yet).
I know, as I said before, this has no direct relation with WO, or
WOnder, but it may help me when starting developing the system.
Thanks 4 the help
Gustavo
On Mar 21, 2008, at 2:56 PM, Jean-François Veillette wrote:
Hmmm ...
- what is id_persion in Person table ? it look like a self
relationship (maybe pointing to a parent) ? if so, give it a
meaningful name (like id_parent or ...)
- what is id_convocation in Person table ? it look like an error,
either a Person has a to-many relationship with Convocation (through
PersonXConvoc) or a to-one with this as a foreign key.
- the old Person primary key id varchar(16) is now an integer,
good. But where is the information that was previously in this
varchar(16) ? is it the new 'document' attribute ?
I suggest, you explain (keep it high level) what are the entities,
what are the relationship between them (including cardinality), it
will be easier to discuss about the implementation in a rdbms.
- jfv
Le 08-03-21 à 14:32, Gustavo Pizano a écrit :
Ok this is what I did. hAving in mind what Jean and James
suggested.<db.pdf>
I know that there should be a middle table to avoid a many2many
relation, i tought that table could be PersonXConv, if no correct
me please.
I want to start from a good db design and UML desing, (I guess
apply for WO too), so I will not have "so many" problems later on.
Thank a lot
Gustavo
On Mar 21, 2008, at 12:46 PM, Jean-François Veillette wrote:
Assuming the relation between a Person and a Convocation is a many-
to-many with a qualified state, you already have your pk and fk,
just not marked appropriately.
In PersonXConvoc, both id_person _and_ id_convocation should be
primary key (as in ExpertiseXPerson).
In EOModeler, you probably do not want the many-to-many to be
modeled though (Person <<-->> Convocation), because if you do so,
you won't have access to your 'state' attribute.
You will have to model the middle table as an entity by itself, so
give it a meaningful name (?Assignment?Meeting?Appointment?). You
will end up with Person <-->> ?Appointment? <<--> Convocation.
I also suspect that the Person id (the primary key) is meaningful
for the user (because you gave it a varchar(16) type), if so, try
to avoid whenever possible (99.99%) to have an attribute that is
also a primary key. Juste give a person a numeric pk (as in other
tables). Since that pk is used as foreign key in other table, you
will avoid trouble later on, when you start updating this
attribute (assuming it's mutable).
- jfv
Le 08-03-21 à 12:54, Gustavo Pizano a écrit :
Well, as you may see db design its not my best quality, I have
done a design here, but I have a problem at how to connect the
PersonXConv with the Person entity, dunno where to put the FK,
any help please? andy suggestion?
F= FK
P=PK
N=NOT NULL
if you need some more info about the model let me know..
Gustavo
PS I jsut wanna have the model well designed so the rest, (in
Hibernate and OFF COURSE in WO ) will be fine so I can show the
teacher the wonders of WO.
<db.pdf>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden