1 / 10

Deriving a Relational DB Model from the AIXM CM

Deriving a Relational DB Model from the AIXM CM. Automatic Generation with Rose Data Modeler. Automatic generation of table definitions straightforward Problems: Disregards stereotypes, not controllable Associations: disregards type and navigability.

jerry-king
Download Presentation

Deriving a Relational DB Model from the AIXM CM

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Deriving a Relational DB Modelfrom the AIXM CM

  2. Automatic Generation with Rose Data Modeler • Automatic generation of table definitions straightforward • Problems: • Disregards stereotypes, not controllable • Associations: disregards type and navigability

  3. Relational Schema Derivation – Features and Objects • <<feature>> and <<object>> implemented as tables • artificial primary key (UID) • attribute to column

  4. Relational Schema Derivation – Associations (1) • Association with multiplicity upper bound 1 primary/foreign key dependency

  5. Relational Schema Derivation – Associations (2) • Association with multiplicity upper bound > 1 over additional mapping table

  6. Relational Schema Derivation – Associations (3) • Generalization Equal primary keys of tables of general and special class

  7. Relational Schema Derivation – Choice • <<choice>> stereotype of features/objects over mapping table (XOR: enforce one column null)

  8. General Considerations – generic or specialized? • Generic or highly specialized approach? • One generic SegmentLeg table with type column or one table for every SegmentLeg specialization? • Consistency could still be enforced with constraints

  9. General Considerations – codelists, enums, datatypes • Implementation of <<enumeration>> and <<codelist>> • As enum column type (if available) or as code table? • enum type strictly enforces limited value set • code table better scalable/extendable • Or: simply as string and enforce allowedvalues outside DB? • Implement data types as column typesin DB?  Philosophical question: Implement all constraints in DB?!?

  10. Discussion!?!

More Related