Re: Sub-Entities in Designer/2000
Date: 1997/06/30
Message-ID: <33b8ebac.2895271_at_nntp.ix.netcom.com>#1/1
This isn't quite correct. There is no direct way to create the "implicit" method (which is probably the most common means of implementing subtypes). You would have to handcraft this approache; the Database Design Wizard doesn't support it.
The "arc" method is a bit uglier than Alex describe; not only are the FK's existing and "arc'ed" from the supertype table to the subtypes, the Database Design Wizard also creates surrogate keys for each subtype table. This doesn't even conform to the theoretical model for arc'ed implementations; I've never seen any experience designer use the the traditional arc approach, let alone this bizarre creation.
The only 3 methods directly supported by the Database Design Wizard are "supertype", "subtype" and "arc".
"Alex N. Yablokov" <A_Yablokov_at_itco.msk.su> wrote:
>Mapping Entities to Tables:
>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:
> a) Access to the super-type is simple.
> b) Views can be used to display the sub-types
> Disadvantages:
> a) 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:
> a) The optionality of all attributes in entities is preserved and can
>be enforced by declarative manner on DB level.
> Disadvantages:
> a) 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:
> a) 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).
> b) The optionality of all attributes in model is preserved.
> c) Access to the super-type is simple.
> Disadvantages:
> a) 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
>>
-JJ
Jeffrey Jacobs & Associates
Oracle Designer/2000 Consulting & Training
951-2 Old Country Road, Suite 119, Belmont, CA 94002
Voice: 415-571-7092, FAX: 800-665-1379
Email: jmjacobs_at_ix.netcom.com
Received on Mon Jun 30 1997 - 00:00:00 CEST