The introduction to Data Architects covers motivation, installation, and structure of the data model. The presentation is the first of FIB-DM training materials. Watch the webinar video here. The second part will cover the business content of the model.
For full screen click maximize at the bottom of the online viewer.
Then start slide show in MS-PowerPoint online.
Text of the presentation
Semantics for Data
- Semantics for Data Architects Financial Industry Business Data Model (FIB-DM) An introduction to the ontology-derived Enterprise Data Model. Jurgen Ziemer Ontologist & Data Architect at Jayzed Data Models Inc.
- FIBO is the authoritative model of Financial Industry concepts, their definitions, and relations. The Enterprise Data Management Council (EDMC) is the Global Association of over 200 Financial Institutions (FI). • Data Management best practices • Development and implementation of Data Standards. EDMC members developed the Financial Industry Business Ontology (FIBO), a business conceptual model. More than 1600 classes detail financial instruments, business entities and processes.
- You work at a Financial Institution and already embrace model-driven development, industry standards, and reference models. Finance business stakeholder and expert with a working knowledge of Entity-Relationship and Ontology diagrams. Data Architect and modeler experienced in Enterprise Reference models. You may have used FIBO design patterns and definitions. As an Ontologist with an in-depth understanding of the FIBO, you already use the reference ontology for your design and want to spread adaptation across your enterprise.
- There is a chasm between semantic and conventional data management. The EDMC specified FIBO in Ontology Web Language (OWL). OWL needs highly specialized ontologists. Many banks and investment managers don’t have the expertise inhouse. Large financial institutions started implementations on RDF (“triple”) stores IT-departments must still support and design conventional databases. FIBO is comprehensive with detailed coverage of business entities, loans, securities, derivatives, and indicators.
- 5FIB-DM is the bridge across the chasm.
- The ontology transformed into a data model leverages the design for relational databases. Semantic Triple Store RDF OWL Relational Database Data Model Configurable Ontology to Data-model Transformation FIBO FIB-DM
- Predictions • RDF-stores soon dominate data management systems in knowledge management. • RDBMS remain the dominant database for traditional transactional and business intelligence systems. • Hence, Financial Institutions still need relational models and data modelers. • However, Ontology Web Language replace the Entity-Relationship Model (ERM) as the notation of choice for Industry Domain and Enterprise Models.
- Use Type Level Business Conceptual Enterprise Design Logical Department Physical ProjectDevelopment Implementation Positioning the ontology and data model within the enterprise architecture. Data Model RDFRDBMS RDF OWL Data Message Process Object FIB-DM FIBO
- Semantic Enterprise Architecture Conceptual • FIBO is the domain ontology. • A conceptual business model for the Financial Industry and applied at the enterprise level. Logical • Logical models for data, message, process, and process derive from the ontology Physical • The ontology at the architecture apex ensures common names, definitions and design across the enterprise. • Midsize Financial Institution without Semantic Technologies yet, adopt FIB-DM, a compatible EDW model. • Large institutions use CODT to transform their inhouse ontologies into data models for downstream implementation.
- Financial Industry Business Data Model • Financial Industry Business Data Model of 1875 Entities, complete definitions, annotations, and axioms (business rules). • Data Architects leverage the full content of the Industry Standard. • Common Language and design patterns for Semantic & Relational databases. in = (and other data modeling tools)
- Data Architect Transformation principles & considerations for the derived data model 1. The model must be practical. Overly normalized designs become too abstract for business users and developers. 2. The model must be complete. We don’t want to miss information from the ontology 3. The model has complete documentation. The diagrams depict all subject areas and design patterns. 4. The model maps back to its source, the ontology
- Ontologist Transformation settings for Domain Ontologies CODT, the patent-pending Configurable Ontology to Data Model Transformation enables the ontologist and data architect to control the process and mapping. To transform a domain ontology into a practical enterprise data model, we set: • Anonymous classes do not transform into entities. The setting is to remove the clutter of entities that never become physical from the model. FIB- DM preserves anonymous classes used in class restrictions in the documentation. • Names transform from OWL Camel Case to LDM English Names (capitalization and spaces). E.g. fibo-fbc-fct-fse:DepositoryInstitution becomes Depository Institution • Object Properties transform to PD Associations and Associative Entities (not simple relationships). This preserves the semantically important object property hierarchy and resolves open-world properties. Domain and Range, Class Restrictions determine parent and child entities related to the association/ associative entity.
- Ontologist From FIBO to FIB-DM Class to Entity Subclass to Inheritance (subtype) Object Property to Associative Entity Object Property to Association Class Restrictions, domain and range determine Relationships and Association Links Depository Institution subtype Bank Account is Provided By is Provided By Bank Bank Account Identifier identifies1,n Bank Account is Identified By 1,n Bank Account Bank Account Identifier identifies <<Associative Entity>> provides Bank Depository Institution Ontology graph Conceptual Data ModelTransformation/mapping
- FIB-DM Core is Open Source GNU General Public License (GPL-3.0), an Open Source Initiative® recommended license. Available for download on the FIB-Dm website: https://fib-dm.com/data-model-download/
- A one thousand entity open-source model Derivatives, 94 Indicators, 573 Securities, 178 Business Entities, 269 Finance, Business & Commerce, 318 Foundation, 380 Languages, Countries & Currencies, 57 Semantic Metadata, 5 Core, 1029
- The Business Entities package defines legal entities and formal organizations. DER The package for Derivative instruments. FBC The package defines functional entites, products and services, debt and equities and financial instruments. FND The Foundation package defines basic building blocks for the other packages. All packages depend on Foundation. IND The package with entities to model Economic and Financial Indicators. LCC The base package for Languages, Countries and Currencies. SEC The package for securities. SKOS Simple Knowledge Organization System for taxonomies, classificatins, and controlled vocabularies. SM The base package for Semantic Metadata content. A self-contained standalone data model. Generic Domain Core Extensions Free Open Source Commercial License CAE Corporate Actions & Events CIV Collective Investment Vehicles LOAN Loans & Mortgages MD Market Data Soon to come packages still in FIBO development
- Download FIB-DM Core GO to the FIB-DM download page, https://fib-dm.com/data-model- download/, click on the download widget or menu item.
- Follow the download email instructions From: Service <firstname.lastname@example.org> Sent: Sunday, August 18, 2019, 13:30 To: <email@example.com> Subject: FIB-DM download link Hi Emily Sample Thanks for your interest in the Financial Industry Business Data Model. Here are two download links: PowerDesigner(CDM, conceptual data model) PowerDesigner(LDM, logical data model) PowerDesigner users click on the CDM link. Receive the email with the download links. Users of other DM tools without conceptual model use the LDM.
- Download the ZIP file and extract the model
- Quick tour and validation Expand the packages and navigate to FND Agreements – Agreements. Open the diagram. Leaf-level packages transformed from FIBO ontologies. Higher-level packages are containers to structure the leaf-level packages. For FIB-DM core, the root- level diagrams are: • FND (Foundation) • BE (Business Entities) • FBC (Finance Business and Commerce)
- Package Properties The Package Name is the rightmost string in the ontology namespace. CODT transforms the ontology prefix as the unique code of the package. Note: All ontology classes, properties with the prefix fibo-fnd-agr-agr become model objects of the Agreements package. The URI is the Uniform Resource Identifier of the ontology. It is a traceability link to the source of the model object.
- Package extended attributes The Extended Attributes tab has a list of ontology annotations. The default transformation configuration uses the Abstract to populate the Package Definition. Extended attributes of Data Type Text are multi-line. For example, the Copyright attribute lists the Object Management Group and EDM Council copyrights and the License attribute lists the FIBO MIT license besides Jayzed and GPL-3.0.
- Entity properties The Name is the ontology class Localname, converted from Camel Case to LDM naming convention (capitalized with space between words). The Code transforms from the ontology class Prefix: Localname. The Comment populates from the class annotation RDFS comment and SKOS definition. There are two particular tabs for ontology derived data models, Annotations and Lineage.
- Entity annotations FIBO has extensive documentation captured in annotation properties. 1618 1615 981 782 513 1301119391 Count owl:Class rdfs:label owl:Class skos:definition owl:Class fibo-fnd-utl- av:adaptedFrom owl:Class fibo-fnd-utl- av:explanatoryNote owl:Class fibo-fnd-utl- av:abbreviation owl:Class fibo-fnd-utl- av:synonym The chart shows the number of classes with annotated documentation.
- Entity lineage http://jayzed.com © Jayzed Data Models Inc. 2019 The Lineage tab captures ontology metadata of the source class. The extended attributes provide traceability into the ontology and preserve semantics beyond the entity-relationship model. The Resource Name is class Prefix and Localname. FIB-DM uses the resource name as the entity code, but you can generate your codes in the modeling tool. The Localname is the rightmost string in the Resource Name and URI. The Prefix is an abbreviation of the URI defined in the ontology. The Uniform Resource Identifier of the class is a link into the FIBO source ontology. Restriction and Equivalent class axioms formulate OLW semantics.
- Entity Restriction https://fib-dm.com © Jayzed Data Models Inc. 2019 fibo-fnd-pty-rl:isPlayedBy some (fibo-fnd-pty-pty:isAPartyTo min 0 fibo-fnd-agr-agr:Agreement) Class restrictions limit the set of allowable instances. For example, the Obligor on the previous page must have an Obligation to some Commitment. fibo-fnd-agr-agr:hasObligation some fibo-fnd-agr-agr:Commitment Note that the ontology object property hasObligation transformed into an Associative Entity in the diagram. The transformation processes the class restriction and creates Relationships from Obligor to the associative entity hasObligation. Class restrictions also determine relationship cardinality. Here, the Obligor must have at least one obligation. Class restriction can be very complex logical expressions. Even the Obligor restriction below is beyond ERM expressivity. The Obligor plays a role as a party to an agreement. FIB-DM does not transform anonymous classes (= restrictions) into pseudo entities. However, FIB-DM preserves these business rules for the benefit of downstream physical modelers and application developers.
- Entity Equivalent Defined Classes in OWL formulate conditions for the set of members. Unlike for the Primitive Class, we don’t construct (~ SQL INSERT) instances of the class. The inference engine, a.k.a. Reasoner determines the instances that match the equivalent condition. For example, the FIBO Foundation Code Set is equivalent to the LCC code set: lcc- lr:CodeSet. That means that every instance in lcc-lr:CodeSet is also a member of fibo-fnd-arr-cd:CodeSet. FIB-DM has entities transformed from equivalent classes. The Equivalent Lineage attribute is a hint for the physical modeler to consider an ALIAS. Defined classes may have more complex conditions. For example, the Affiliate entity is a union od Majority Controlling Party and Controlled Company. fibo-be-oac-cpty:MajorityControllingParty or fibo-be-oac- cctl:ControlledCompany The Equivalent Lineage attribute is a hint for the physical modeler to consider a VIEW.
- Multiple Inheritance An ontology class can be a subtype of more than one parent class. For example, the Central Bank is both a Bank and a Monetary Authority. Multiple Inheritance makes sense from a business perspective, and as a conceptual model, FIB-DM keeps multiple supertypes. However, the LDM permits only one supertype. Note that object models also allow multiple inheritances. The Logical Data Modeler can use the same techniques to resolve multiple inheritances: 1. The issue goes away. A logical project model derived from FIB-DM may not scope the Monetary Authority. Then the Central Bank has only one supertype, the Bank. 2. The Logical Modeler changes one or both subtypes into dependent relationships. In the diagram, both Bank and Monetary Authority identifiers constitute the key for the bank. Bank subtype (D) Monetary Authority subtype (D) Central Bank Bank Monetary Authority
- Entity Attributes Currency Currency Name Minor Unit Numeric Code Name Variable characters Variable characters Variable characters Variable characters FIBO is a domain ontology defining business concepts with classes and object properties. There are only 160 data properties in the source ontology. Hence, FIB-DM is an entity-level conceptual data model, sparsely attributed and has no keys. The PowerDesigner CDM has Data Items. These are model objects independent of the entity. The Data Item then gets attached to the entity as an attribute. Data Items as a model object disappear when the modeler derives an LDM from the CDM. The transformation creates Data Items from source ontology data properties. The property domain and class restrictions determine attributes on an entity.
- Associations The PowerDesigner CDM introduces the Association as a model object. Associations stand on their own, rather than depending on two entities. In the example diagram, one or more Identity Documents, such as Passport or Driver’s License, identify a person. The Person can also have precisely one National ID, e.g., Social Security Number. Person is Identified By 0,n National Identification Number identifies 1,1 Identity Document identifies 1,n Identity Document National Identification Number Person identifies Association Links connect the Association to participating entities. Unlike the relationship, the Association can link to more than two entities. Associations become Associative Entities, and the Association Links become relationships when the modeler derives and LDM from the CDM. The CODT process transforms object properties into associations and determines Association Links from the domain and class restrictions.
- Associative Entities Unfortunately, PowerDesigner CDM Associations do not support inheritance. Hierarchies of object properties are an essential OWL construct and widely used in the FIBO. The default configuration to transform a domain ontology into an EDM, therefore, creates Associative Entities from object properties that are or have sub-properties. governs subtype <<Associative Entity>> governs <<Associative Entity>> governs Payment Of <<Associative Entity>> has Jurisdiction <<Associative Entity>> regulates Supply Of <<Associative Entity>> has Governing Jurisdiction
- Associations, a Star Schema? The context diagram below shows the identifies Association and some participating entities. Indeed, the diagram looks like a Star Schema (with a “factless” fact table in the center). While this is perfectly fine for a dimensional data model, and the model check doesn’t complain, the denormalized design would not be appropriate in a relational model. However, as previously done for multiple inheritances, we prioritize the clarity for business users of the design over 4th Normal Form correctness.
- Multi-valued association resolved. After scoping and attribution, the logical data modeler can resolve to 4NF: 1. Once the modeler removes entities without attributes, the issue may disappear. 2. The standard 4NF resolution replaces the identifies association with role-named associations (a subtype of identifies). E.g., Bank Identifier identifies Bank. The entity Lineage tab Restriction on Bank Identifier shows the class restriction. 3. A relationship Role can be added to stipulate the identifier. For example, a Security Identifier Type can tell the application whether to look for a Security Identifier or National Securities Identifying Number. 4. The Physical modeler can decide to roll-up or roll-down the identifies subtypes. As said before, FIB-DM does not prescribe how the data modeler resolves the design. Identifies Selector identifies Currency is Identified by Currency Currency Identifier identifies Currency Bank Identifier identifies BankBank is Identified by Bank Identifier Account is Identified by Account Identifier AccountIdentifier identifies Account identifies Subtypes AccountBankCurrency Bank Identifier Account IdentifierCurrency Identifier identifies identifies Accountidentifies Bankidentifies Currency identifies Selector Type
- Relationships FIB-DM uses Associations and Associative entities to model relationships between entities. Hence, Relationship model objects are merely connecting entities to associative entities. They transform from object property domains and class restrictions. The naming conventions for the code is “parent entity – child entity.” For example: fibo-fbc-dae-dbt:Accrual- fibo-fnd-rel-rel:appliesTo Likewise, Relationship Name and Comment generate as per CODT configuration settings.
- FIB-DM is the bridge across the chasm. Chasm between semantic and conventional data management.