1 / 10

Deriving a Relational DB Model from the AIXM CM

This document explores the automatic generation of relational database model tables from AIXM Conceptual Model (CM) utilizing Rose Data Modeler. It discusses the generation process, highlighting challenges including the disregard for stereotypes and associations. Key features such as the conversion of features and objects into tables, primary key generation, and how associations are handled with different multiplicity constraints are examined. General considerations on making a generic or specialized approach, including handling codelists and enumerations, are also discussed, raising philosophical questions about implementing constraints within the database.

jerry-king
Télécharger la présentation

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