Property and Casualty Insurance Working Group Logical Relational Data Modeling Standards Versio n 1.0 Property and Casualty Insurance Working Group Jun e 16, 2008 Table of Contents Introduction . 4 Purpose . 4 Document Maintenance . 4 Scope . 4 Logical Relational Data Model Definition . 4 ER Diagramming Conventions . 6 Logical Relational Data Modeling Standard Page 2 Property and Casualty Insurance Working Group Modeling Syntax . 6 Diagramming Layout Guidelines . 7 Normal Forms . 8 Writing Definitions of Logical Objects . 9 Logical Object Definition Guidelines: . 9 Entity Definition Guidelines: . 9 Attribute Definition Guidelines : . 9 Naming Logical Objects . 10 Logical Object Naming Guidelines . 10 Entity Naming Guidelines . 11 Attribute Naming Guidelines . 11 Relationship Naming Guidelines . 13 Relationship Standards . 14 Super- types and Sub- types . 15 Entity Keys . 17 Dimensional Data Modeling . 18 Appendix . 19 Class Words . 19 Logical Relational Data Modeling Standard Page 3 Property and Casualty Insurance Working Group Introduction Purpose This document provides standards and guidance for the naming and use of objects in logical relational data models. Logical objects are created and maintained to meet business requirements. Accurate naming clarifies the specific nature of each logical object. Consistency allows the logical names to have persistent value in differentiating data items. Name formation and the use of logical modeling objects are independent of any particular data modeling tool or relational database management system (RDBMS) platform. These logical relational data modeling guidelines are independent of specific CASE tools. The intention of this standard is to establish an agreed- upon basis for developing logical relational data models in order to promote greater quality and consistency across data models and enable objective model reviews. Document Maintenance To suggest improvements, changes or additions to this standard, contact: Gail Austin or Harsh Sharma [email protected] [email protected] Scope These standards apply to all logical relational data models that are developed by OMG submission teams. Logical Relational Data Model Definition The relational model for database management is a database model based on predicate logic and set theory. It was first formulated and proposed in 1969 by Edgar Codd with aims that included avoiding, without loss of completeness, the need to write computer programs to express database queries and enforce database integrity constraints. “Relation” is a mathematical term for “table”, Logical Relational Data Modeling Standard Page 4 Property and Casualty Insurance Working Group and thus “relations” roughly means “based on tables”. It does not refer to the links or “keys” between tables, contrary to popular belief.1 A logical relational data model defines what an organization knows about things of interest to the business and graphically shows how they relate to each other in an entity relationship (ER) diagram. An entity relationship diagram is an abstract conceptual representation of structured data. It uses standard symbols to denote the things of interest to the business (entities), the relationships between entities and the cardinality and optionality of those relationships. The Logical Relational Data Model, in contrast to the more abstract Conceptual Relational Data Model, contains detailed characteristics of the entities (attributes) and their definitions. It generates the structure of a physical data model which in turn generates a database following Model Driven Architecture principles. It is a result of detailed analysis of the business requirements. The following illustration shows how the logical model fits into the overall data modeling process: 1 Wikipedia – relational model Logical Relational Data Modeling Standard Page 5 Property and Casualty Insurance Working Group Ultimately, the logical relational data model helps to solidify and validate business requirements and delivers stable, flexible data structures that are easily navigated and can answer unanticipated questions. ER Diagramming Conventions Modeling Syntax The recommended notation for models is Information Engineering (IE) – “Crow’s Feet” - because it is easier for users to interpret than the Integration Definition for Information Modeling (IDEF1X) notation.2 2 The choice of IE notation will be revisited when the Barker notation becomes more widely available in the modeling tools. Logical Relational Data Modeling Standard Page 6 Property and Casualty Insurance Working Group Diagramming Layout Guidelines Orient entities so that the “toes” of a relationship’s crow’s foot always point down. This puts fundamental entities in the top area of the diagram, and positions associative and subtype entities in the lower area of the diagram. Recommended crow’s feet down convention Avoid dead crows! CONTACT PROFILE PERSON Person Identifier (FK) Person Identifier (FK) Contact Point Identifier (FK) First Name Home Contact Point Indicator Middle Name Work Contact Point Indicator Last Name Legal Name Nickname CONTACT POINT Name Suffix Contact Point Identifier Birth Date Birth Place Name Gender Code PERSON CONTACT POINT Person Identifier (FK) Contact Point Identifier First Name Middle Name Last Name CONTACT PROFILE Legal Name Nickname Person Identifier (FK) Name Suffix Contact Point Identifier (FK) Birth Date Home Contact Point Indicator Birth Place Name Work Contact Point Indicator Gender Code Keep the relationship lines as straight as possible. Avoid unnecessary bends. Too many symbols clutter the diagram and make it confusing to the viewer. Avoid crossing relationship lines. Crossed lines make it difficult to understand which entities are related. Relationship names should be placed on the diagram so that the verbs or verb phrases are read in a clockwise direction from one entity to the related entity. Example: Logical Relational Data Modeling Standard Page 7 Property and Casualty Insurance Working Group POLICY Policy Identifier covers is covered by EXPOSURE Policy Identifier (FK) Insured Object Identifier (FK) Coverage Type Identifier (FK) Normal Forms Normal Forms provide a way to structure data to eliminate undesirable redundancies, inconsistencies and dependencies. Normalization is a formalized technique for creating the most desirable logical model for the given data and business rules. Completed logical models should be in, at least, Boyce/Codd Normal Form (BCNF)3. For a model to be in BCNF, every entity in the model must be in BCNF. The normal forms are summarized below: Firs t Nor ma l For m (1NF) identifies and eliminates repeating groups and establishes a primary key. Secon d Nor ma l For m (2NF) identifies and.