Disjoint and reflexive relationships in Access

[Guest]

Is it possible to implement a disjoint relationship w/total specialization in
Microsoft Access? When building the database in access do tables in disjoint
relationships need to be rolled up into the primary table? My final question
pertains to unary/reflexive relationships. If I do not have Micrsoft Access
Project, can I still map a reflexive relationship in regular access? Thanks
everyone.

 

[Larry Linson]

Is it possible to implement a disjoint relationship w/total specialization
in
Microsoft Access? When building the database in access do tables in
disjoint
relationships need to be rolled up into the primary table? My final
question
pertains to unary/reflexive relationships. If I do not have Micrsoft
Access
Project, can I still map a reflexive relationship in regular access?
Thanks
everyone.

Reflexive relationships can be expressed in Microsoft Access (but most often
they are called "self-join" as we of the Great Access Unwashed don't often
delve deep into relational terminology). You simply add the same table
twice, or more, as a data source in the Query Builder, and drag and drop to
join on the appropriate column.

Please clarify, in simple database terms, what you mean by "disjoint
relationship w/ total specialization" because Googling on those terms only
returns one apparently-relevant hit, which is a Power-Point presentation on
data modeling.

Larry Linson
Microsoft Access MVP

 

[Guest]

Let me see if I can clarify things a bit. I am really trying to implement a
supertype/subtype relationship. The supertype table is "Cars" for example
and the subtype tables are "UsedCars" and "NewCars" for example. If the
attributes that are unique to "UsedCars" and "NewCars" are incorporated into
the supertype table "Cars" there will be a lot of null data that is retrieved
when a query is processed. A disjoint relationship means that the supertype
"Cars" can only match one of the subtype tables "UsedCars" and "NewCars".
Totalspecialization means that the supertype table must have a matching
subtype table. I apologize if my explanation is confusing. Let me know if
there is anything further I can add to clear things up. Thank you so much

 

[dbahooker]

Access is for retards.

SQL Server has much much stronger functionality in this regard
Access Data Projects allow you to re-use much of your existing forms
and reports.

-Aaron
ADP Nationalist

 

[William Hindman]

....its a pretty standard relational approach in Access once you get past the
language barrier.

....tblCars
...........CarsID PK/AN
...........TypeID Long 1=New, 2=Used
...........CommonFields

tblUsed
...........CarsID PKFK tblCars
...........SpecificFields

tblNew
...........CarsID PK/FK tblCars
...........SpecificFields

William Hindman

 

[dbahooker]

you could also write a relationship against a QUERY in Access... I dont
think that is used very often; but it seems like that might be a better
option than having a simple CARS table.

you were trying to have a generic table; and CARS would be an entry in
the generic table; not necessarily a whole table called CARS.. right?

-Aaron

 

[James A. Fortune]

Let me see if I can clarify things a bit. I am really trying to implement a
supertype/subtype relationship. The supertype table is "Cars" for example
and the subtype tables are "UsedCars" and "NewCars" for example. If the
attributes that are unique to "UsedCars" and "NewCars" are incorporated into
the supertype table "Cars" there will be a lot of null data that is retrieved
when a query is processed. A disjoint relationship means that the supertype
"Cars" can only match one of the subtype tables "UsedCars" and "NewCars".
Totalspecialization means that the supertype table must have a matching
subtype table. I apologize if my explanation is confusing. Let me know if
there is anything further I can add to clear things up. Thank you so much

Please post back if you discover anything of interest regarding this
problem. Think of the problem of automatically translating from one
spoken language to another through software, or later hardware. The two
language trees eventually meet at a concept node. Going up the first
tree toward the concept node is automatic and instantaneous. Going down
the second tree requires lots of decisions to be made automatically.

James A. Fortune
(e-mail address removed)