Re: Sub-Entities in Designer/2000

From: Alex N. Yablokov <A_Yablokov_at_itco.msk.su>
Date: 1997/06/30
Message-ID: <01bc8569$e3d66470$0741a8c0_at_apple>#1/1


Mapping Entities to Tables:
[Quoted] There is four variant of mapping Super/Sub entities into table structure.

  1. "Super-type implementation" In Super-type implementation, a single table implements the Super and all Sub-type entities. The table includes columns for all attributes of the super-type and sub-type entities. DB Wizard generate special column in table - DISCRIMINATOR COLUMN to identify which entity belong record in table. Advantages of this method:
    1. Access to the super-type is simple.
    2. Views can be used to display the sub-types Disadvantages:
    3. Mandatory columns mapped from sub-types must allow NULL values. You must add to decrative constraints to implement the rule.
  2. "Explicit Sub-type implementation" This implementation trnsforms the sub-types entities into separate tables, with one table for each. The attributes from sub-types are mapped to columns in the tables. The attributes from the super-type are inherited as columns in all resulting tables. Advantages:
    1. The optionality of all attributes in entities is preserved and can be enforced by declarative manner on DB level. Disadvantages:
    2. Access to Super-type requiers the UNION operator.
  3. "Implicit Sub-type implementation" The implementation creates a table for the super-type and one for each of the sub-types.The table for each sub-type holds columns for each attrubute in specific sub-entity and colums for each attribute in super-type entity. The table for super-type only holds columns for each attribute in the super-type entity. Advantages:
    1. It allows you to have instances of super-type that are not classifiable as being one of its sub-type (which also could be regarded as disadvantages, depending on the situations).
    2. The optionality of all attributes in model is preserved.
    3. Access to the super-type is simple. Disadvantages:
    4. To create instanse of sub-type the module must create records in the sub-type table and in the super-type table.
  4. "Arc implementation" Thes implementation transforms each entity in the same manner as the implicit sub-type implementation with one addition: you also get foregn keys in the super-type table which reference a sub-type tables. These foregn keys arced at the super-type end. Because of the arc you are not allowed create super-type, that are not classifiable as one of the sub-type. Other than that advantages and disadvantages of thes method is same as in implicit sub-type implementation.

P.S. It is not possible to define a single, superior design for sub-types. The decision is depending on situation.


--
Alex Yablokov. Russia, Moscow.
Information Technologies Co.
----------------------------------------------------------------------------
--


walsh_at_womex.com ÚÁÐÉÓÁÎÏ × ÓÔÁÔØÀ <867671777.26288_at_dejanews.com>...

> It's been a while since I used Designer/2000 so this question might
> sound silly to some.
>
> Can anyone give me a synopsis of how Designer/2000 translates sub/super
> entities into tables at generate time.
>
> I have an entity person which holds the common data for all people on
> our database (both customers and employees) and an entity employee which
> holds additional information such as vacation entitlement etc. My
> feeling is that employee is a sub-entity of person, is this correct in
> the D2K context and if so what is the likely table structure that will
> be created.
>
> thanks in advance
> --
> regards,
>
> Michael Walsh
> WOMEX
> Russell Court,
> St Stephens Green
> Dublin 2.
> Rep of Ireland.
>
> tel: +353-1-402 6615
> fax: +353-1-478 5818
>
> mail: walsh_at_womex.com
> www: http://www.womex.com
>
> -------------------==== Posted via Deja News ====-----------------------
> http://www.dejanews.com/ Search, Read, Post to Usenet
>
Received on Mon Jun 30 1997 - 00:00:00 CEST

Original text of this message