database design with semantic object models n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Database Design with Semantic Object Models PowerPoint Presentation
Download Presentation
Database Design with Semantic Object Models

Loading in 2 Seconds...

play fullscreen
1 / 18

Database Design with Semantic Object Models - PowerPoint PPT Presentation


  • 152 Views
  • Uploaded on

Database Design with Semantic Object Models. Mapping 7 types of semantic objects into relations. Simple objects. Transform object into relation Make ID into key Other attributes become columns. Composite objects. One relation for base object Include single-valued attributes

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Database Design with Semantic Object Models' - kuper


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
database design with semantic object models

Database Design with Semantic Object Models

Mapping 7 types of semantic objects into relations

simple objects
Simple objects
  • Transform object into relation
  • Make ID into key
  • Other attributes become columns
composite objects
Composite objects
  • One relation for base object
    • Include single-valued attributes
  • One relation for each (simple or group) multi-valued attribute
  • Key of child relation is composite:
    • Foreign key of object
    • Local key of multi-valued attribute
separate versus nested groups
Separate versus nested groups
  • Iterate composite object procedure
  • Outer group is base object for inner group
compound objects
Compound objects
  • Basically 3 types of binary relationships
compound objects1
Compound objects
  • 1:1 - place key of either table into other table
compound objects2
Compound objects
  • 1:N - place key of parent into child table
compound objects3
Compound objects
  • N:M - create intersection table with keys of both relations
hybrid objects
Hybrid objects
  • Create a table for the multi-valued group attribute of the composite object
  • Place key of non-composite object into that table

SALES-ORDER (SalesOrderNumber, Date, Subtotal, Tax, Total, Phone, SalespersonName)

ITEM (ItemNumber, ItemDescription, UnitPrice)

LINE-ITEM (SalesOrderNumber,ItemNumber, Quantity, ExtendedPrice)

hybrid objects1
Hybrid objects
  • Actually, 4 cases of hybrid objects
hybrid object max cardinality
Hybrid Object Max Cardinality
  • Case One
  • ITEM in one ORDER and only one LineItem
hybrid object max cardinality1
Hybrid Object Max Cardinality
  • Case Two
  • ITEM in one or more LineItems within one SALES-ORDER
hybrid object max cardinality2
Hybrid Object Max Cardinality
  • Case Three
  • ITEM in one LineItem within one SALES-ORDER
hybrid object max cardinality3
Hybrid Object Max Cardinality
  • Case Four
  • ITEM in one or more LineItems within one SALES-ORDER
hybrid object common cases
Hybrid object common cases
  • Case 4: O3 is inserted into R-G2 but not as part of its local key
  • Case 1: like 3 but add O1 to R2 and R2(O1,O2) = R-G1(O1,O2)
  • Case 2: like 4 but add O1 to R3 and R-G2(O1,O3) Í R3(O1,O3)
association objects
Association objects
  • One relation for each of the 3 participating objects
    • Each relation has its own key
    • Association relation has parents’ keys as foreign keys
    • If association has no unique ID, use foreign keys
  • Unlike intersection relations, association tables may have additional attributes
super subtype objects
Super/subtype objects
  • One table for parent
  • One table for each subtype
  • Normally same key for all
  • May add subtype attribute(s) to parent for efficiency
    • One label if exclusive
    • One Boolean per type, if not exclusive
archetype version objects
Archetype/version objects
  • One table for archetype
  • One table for version
  • Key of version table contains key of archetype table