diff --git a/DataModels/Assets/AggregateExample.svg b/DataModels/Assets/AggregateExample.svg deleted file mode 100644 index 1f2fffc..0000000 --- a/DataModels/Assets/AggregateExample.svg +++ /dev/null @@ -1,334 +0,0 @@ - - --oihUid-oihCreated-oihLastModifiedOIHDataRecord-applcationUid-recordUid-created-lastModifiedOIHApplicationDataRecord-orderNumber-customerNumber-shippingAddressUid-billingAddressUid-date-totalOrder-position-articleUid-description-cost-quantity-amountLineItem-cardNumber-expirationMonth-expirationYear-cardholderCreditCardPaymentInfooihApplicationRecords1..*0..11..*lineItems diff --git a/DataModels/DataModels.md b/DataModels/DataModels.md deleted file mode 100644 index 9aec845..0000000 --- a/DataModels/DataModels.md +++ /dev/null @@ -1,101 +0,0 @@ -# OIH Data Models - -The Open Integration Hub (OIH) provides an asynchronous way of integrating applications and services. Modelling data which is processed by an OIH instance must always consider this fact! - -One consequence is, that it must be possible to sent data records to and receive them from an OIH without the need or even possibility for the receiver to eagerly fetch referenced further records of any kind through an API or data store (like the _optional_ OIH Data Hub). - -A data model representing a certain professional domain normally consists of numerous entities. Hence, it is necessary to split such a data model into smaller parts to enable the transfer of optimized amounts of data through an OIH: - -* __Every OIH-Master-Data-Model (MDM) consists of one or multiple _loosely coupled_ sub-models.__ - -Although it is necessary to split (especially big) data models into smaller sub-models, it often does not make sense to send each entity on its own, when there is a _high cohesion_ between certain entities. Hence, - -* __each sub-model of an MDM can consist of one _or more_ entities.__ - -## Aggregates - -In case the model consists of multiple entities, it *must* be modeled as an __aggregate__: - -> Aggregate is a pattern in Domain-Driven Design. A DDD aggregate is a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items, these will be separate objects, but it's useful to treat the order (together with its line items) as a single aggregate. -> -> An aggregate will have one of its component objects be the aggregate root. Any references from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole. -> -> [s. [Martin Fowler: DDD_Aggregate](https://martinfowler.com/bliki/DDD_Aggregate.html)] - -# Rules and Regulation for MDMs - -To enable the OIH to follow its purpose, the data records being processed have to fulfill some criteria and follow some rules. Some of these rules have to be applied already on the modelling level. - -## OIH Data Records - -An OIH expects and needs, depending on the scenario and the involved components (e.g. with or without a Data Hub involved), more or less meta data on a data record to integrate two or more applications. This is achieved by modelling each sub-model of an MDM as a so called _OIH Data Record_. The OIHDataRecord defines a superset of mandatory and optional (meta) data for records processed by an OIH instance: - -![OIH Record](Assets/OIHDataRecord.svg) - -* __Each of the the sub-models of a MDM has to be marked as an *OIHDataRecord*.__ - -I.e., the root of an MDM's sub-model **must** inherit from / extend _OIHDataRecord_, no matter whether it is modeled as an -aggregate or as a single entity. - -* __Every record passed into an OIH instance must at least be provided with a reference to the record of the application or service being the source of the record__, - -called an _OIHApplicationDataRecord_ containing ... - -+ the OIH's identifier for the application, -+ the record's ID within the application (both mandatory) and -+ optionally its creation and last modification dates within the application. - -When receiving such a record from an OIH, there might also be entries of other applications being part of the integrations scenario with the same MDM in the same OIH. - -Additionally, depending on the scenario and the involved components again, the OIH itself or a connector (according to rules provided by the OIH __==> TO BE DISCUSSED!__) may also provide an OIH-internal UID for the record, along with the creation and last modification dates of the record within the OIH. - -## JSON-Schema - -The OIH specifies JSON as the format that data is processed with. Accordingly, - -* __[JSON Schema](http://json-schema.org) is the given format to describe MDMs__ - -in a way an OIH instance is able to validate data at runtime. And, as MDMs are split into sub-models and the records of those sub-models must be processable independently, - -* __for every sub-model of an MDM there must be a _seperate_ JSON schema describing the entity or aggregate.__ - -As there are situations where entities are reused in (i.e. are part of) two or more aggregates, it is of course adequat to encapsulate those entities in an additional schema file and reference them from the several sub-models to avoid redundancy. - -### Making a sub-model of an MDM an OIH Data Record on the schema level - -There is a predefined JSON-Schema defining the OIHDataRecord (s. [oih-data-record.json](../src/main/schema/oih-data-record.json)). - -* __Every sub-model of an MDM must reference the OIHDataRecord schema and "inherit" from the defined type.__ - -This is done by adding an `allOf`-element to every sub-model's schema: - -```javascript -{ - "$schema": "http://json-schema.org/schema#", - "$id": "http://example.com/schemas/oih/my-model.json", - "title": "MySubmodelAggregate", - "allOf": [ - { - "$ref": "http://openintegrationhub.org/schemas/oih-data-record.json" - } - ], - "properties": { - ... -``` - -# Example: the Order aggregate - -For a sales application, one could split the data model at least into the following sub-models, each of which built as an aggregate: - -* Order -* Address -* Article -* ... - -As an example to model an aggregate capable of being processed of an OIH instance, the following diagram shows a simplified order with its line items: - -![Aggregate example: Order](Assets/AggregateExample.svg) - -The Order's root defines the model as an OIH Data Record by extending it. This way, the _Order_ entity is the one and only entry point to the aggregate. - -The JSON schema for this example is accessible [here](../src/examples/schema/order.json). \ No newline at end of file diff --git a/DataModels/MetaModel.md b/DataModels/MetaModel.md index 83e07d9..2f7e8e9 100644 --- a/DataModels/MetaModel.md +++ b/DataModels/MetaModel.md @@ -1,25 +1,25 @@ -# Introduction - -- _TODO:_ What is the OIH meta model? What is its purpose? - -## Requirements +# Requirements - mulit-tenancy support - conflict management support - extensibility per tenant -# Multi-Tenancy +## Multi-Tenancy SaaS applications and multi-tenancy go hanad in hand. Hence, for the OIH it is essential to support multi-tenancy out pf the box. The meta model to describe master data models in the OIH must provide an identifier for the tenant which is the data's owner. -# Conflict Management Support +## Conflict Management Support - timestamps for _created_ and _last modified_ - alternatively versioning by revision numbers - or both? +## Extensibility per Tenant + +In case the master data model provided by the OIH is lacking of one or more fields or a specific tenant, and there is no sense in applying this extension to the global master data model, there should be a possibility to add those tenant specific fields only in the tenant's specific context. + # Notation / Schema As of now, there are two important contemporary forms in which structured data is exchanged: @@ -29,15 +29,14 @@ As of now, there are two important contemporary forms in which structured data i Both should - sooner or later - be applicable by the OIH at least at its outer boundaries. When it comes to the internals of the OIH, espacially the data hub, it is essential to decide for one of those alternatives, as the OIH will provide automatisms like conflict management, and the focus on one alternative will reduce implemenation efforts and risk. -Proposal: JSON! - +Decision: JSON! -## JSON-Schema vs. GraphQL + +## Schema Definition Language (SDL) -# Extensibility per Tenant +Decision: [JSON-Schema](http://json-schema.org) (s. [https://github.com/openintegrationhub/Data-and-Domain-Models/issues/5](https://github.com/openintegrationhub/Data-and-Domain-Models/issues/5) and [../MasterDataModels/README(.md/.pdf)](../MasterDataModels/README.md)) -In case the master data model provided by the OIH is lacking of one or more fields or a specific tenant, and there is no sense in applying this extension to the global master data model, there should be a possibility to add those tenant specific fields only in the tenant's specific context. # Granularity @@ -47,6 +46,9 @@ In case the master data model provided by the OIH is lacking of one or more fiel - loose coupling - multiple aggregates/entities per master data model +(Done, s. [../MasterDataModels/README(.md/.pdf)](../MasterDataModels/README.md)) + + # Security / Authorization -- ACLs/ACEs \ No newline at end of file +- ACLs/ACEs diff --git a/DataModels/RulesandRegulations.md b/DataModels/RulesandRegulations.md deleted file mode 100644 index 601c571..0000000 --- a/DataModels/RulesandRegulations.md +++ /dev/null @@ -1,51 +0,0 @@ -# Master Data Models - Rules and Regulations - -This document describes the rules and regulations to implement -master data models for the open integration hub. - -## 1. What is a Master Data Model? - -A master data model is a an abstract schema that organizes elements of data. -With this model the data can used and kept synchronized across applications. -With a master data management (MDM) - in the OIH-Project named -"Data Hub" - the master data is stored central. - -For the Open Integration Hub we don't use a canonical data model. Instead we use a model for each context. -In individual contexts objects are different to handle, we have to accept this. -A canonical data model brings massive communication effort, idle times and workarounds. - -## 2. Motivation - -A master data model should be designed with following criterias in focus: -- All use cases and user stories for the different scenarios of integration -between applications of different domains can be matched and the master data of -all the applications can be mapped to the database schema. -- The model is generic and it can be extended on the application level. - -## 3. Requirements - -A master data model for the OIH should be: -- compatible with business models in business-to-business and business-to-consumer. -- generic but extendable for individual applications -- used by the integration services and by the data hub -- cover most of the integration scenarios -- cover the privacy rules and data protection laws -- de facto standard for the address integration scenarios for SME - -## 4. Rules for Implementing a Master Data Model for the Open Integration hub - -To implement a new Master Data Model for a specific context for the Open Integration Hub you -have to deliver some basics first. - -At least a JSON-Schema for the Master Data Model is mandatory. For a better overview -and easier understanding a UML-Diagram would desirable. - -Variable naming has to be in CamelCase with english names. - -First of all each of the OIH-Sub-models has to be marked as an OID Data Record. -The root of a Master Data Model's sub-model must inherit from / extend the -OIHDataRecord, no matter whether it is modeled as an aggregate or as a single entity. -See the reference of the OIH Master Data Model for further informations. - -Please deliver a description of the context of the new OIH-Sub-model you wish to implement, -so other user can get a quick overview of your context. diff --git a/MasterDataModel/Assets/DataModelYQ.sql b/MasterDataModel/Assets/DataModelYQ.sql deleted file mode 100644 index da22dd6..0000000 --- a/MasterDataModel/Assets/DataModelYQ.sql +++ /dev/null @@ -1,643 +0,0 @@ -Unsere Adressdaten bestehen im wesentlichen aus einer Grundtabelle "address" -In SilvERP gibt es Adressdatensätze, die spezifische Erweiterungen erhalten haben. -Diese Erweiterten Adressen sind: - Lieferanten - Kunden - Mitarbeiter - -Die Tabellen sind so zu verstehen, dass JEDER Adresse eine Zeile in der Tabelle "address" hat. Zudem hat ein Kunde eine Zeile in der Tabelle "customer", ein Lieferant eine Zeile in der Tabelle "supplier" und ein Mitarbeiter eine Zeile in der Tabelle "employee". -In diesen erweiterten Zeilen ist jeweils ein Feld "idAddress" enthalten, das auf die grundadresse verweist. -Durch diese Struktur kann ein und die gleiche Adresse auch gleichzeitig Kunde und Lieferant sein, indem es schlicht beide Erweiterungen gibt. - -Felder, deren Name mit "id" beginnt sind 1:1 verbundene Auswahlfelder. Diese Tabellen sind aufgrund der Namensgebung in der Regel selbsterklärend und in dieser Date deswegen nicht noch einmal explizit abgebildet. - -Weiterhin gibt es die Tabelle "connectoraddress", durch die man Adressen beliebigen anderen Adressen zuordnen kann. -Diese Zuordnungen können die Qualität "Ansprechpartner", "Rechnungsadresse" oder "Lieferadresse" haben. -Hierbei werden jeweils Zeilen der Tabelle address miteinander verknüpft. - -Die Tabellenstrukturen lauten: - -CREATE TABLE address ( - -- reserved - idRecord BIGINT NOT NULL, -- - recordState INT NOT NULL DEFAULT '0', -- - idAddressCreate BIGINT NOT NULL DEFAULT '0', -- < > currentUser[id] - addressLevel BIGINT NOT NULL DEFAULT '0', -- < > - recordFlags BIGINT NOT NULL DEFAULT '0', -- < > - tsUpdate BIGINT NOT NULL DEFAULT '0', -- < > - idAddressUpdate BIGINT NOT NULL DEFAULT '0', -- < > - tsVirtualDel BIGINT NOT NULL DEFAULT '0', -- - idAddressVirtualDel BIGINT NOT NULL DEFAULT '0', -- < > - revision BIGINT NOT NULL DEFAULT '0', -- < > - archiveFlag INT NOT NULL DEFAULT '0', -- - poolFlag INT NOT NULL DEFAULT '0', -- < > - -- extensions - idEmployee BIGINT NOT NULL DEFAULT '0', -- - -- extensions - idCompanyUnitDefault BIGINT NOT NULL DEFAULT '0', -- - -- addressdata - addressSource CHAR ( 80) NOT NULL DEFAULT '', -- < > - matchcode CHAR ( 80) NOT NULL DEFAULT '', -- - idChoicerTitle BIGINT NOT NULL DEFAULT '0', -- < > - idChoicerSalutation BIGINT NOT NULL DEFAULT '0', -- - idChoicerAcademicTitle BIGINT NOT NULL DEFAULT '0', -- < > - name1 CHAR ( 80) NOT NULL DEFAULT '', -- - name2 CHAR ( 80) NOT NULL DEFAULT '', -- - name3 CHAR ( 80) NOT NULL DEFAULT '', -- - name4 CHAR ( 80) NOT NULL DEFAULT '', -- - idChoicerGender BIGINT NOT NULL DEFAULT '0', -- < > - dtBirthday DATE, -- < > - appendix1 CHAR ( 80) NOT NULL DEFAULT '', -- < > - appendix2 CHAR ( 80) NOT NULL DEFAULT '', -- < > - appendix3 CHAR ( 80) NOT NULL DEFAULT '', -- < > - appendix4 CHAR ( 80) NOT NULL DEFAULT '', -- < > - street CHAR ( 80) NOT NULL DEFAULT '', -- - city CHAR ( 40) NOT NULL DEFAULT '', -- - zipCode CHAR ( 40) NOT NULL DEFAULT '', -- - zipCodeDirect CHAR ( 40) NOT NULL DEFAULT '', -- - zipCodePostbox CHAR ( 40) NOT NULL DEFAULT '', -- - postbox CHAR ( 40) NOT NULL DEFAULT '', -- < > - idChoicerRegion BIGINT NOT NULL DEFAULT '0', -- contains intrastat regioncode - country CHAR ( 20) NOT NULL DEFAULT '', -- - countryIso CHAR ( 20) NOT NULL DEFAULT '', -- - idCountry BIGINT NOT NULL DEFAULT '0', -- - idLanguage BIGINT NOT NULL DEFAULT '0', -- - idChoicerTour BIGINT NOT NULL DEFAULT '0', -- - -- job - idChoicerJobTitle BIGINT NOT NULL DEFAULT '0', -- < > - department CHAR ( 40) NOT NULL DEFAULT '', -- < > - -- geodata - geoPosition POINT, -- - geoLongitude DOUBLE NOT NULL DEFAULT '0', -- - geoLatitude DOUBLE NOT NULL DEFAULT '0', -- - geoHeight DOUBLE NOT NULL DEFAULT '0', -- - distanceToBase DOUBLE NOT NULL DEFAULT '0', -- - -- tax - taxNo CHAR ( 40) NOT NULL DEFAULT '', -- < > Steuer-Nr. - vatNo CHAR ( 40) NOT NULL DEFAULT '', -- < > USt-Id-Nr. - bvFactoring TINYINT ( 1) NOT NULL DEFAULT '0', -- < > wird factoring zum Abrechnung - bvAddressPickUp TINYINT ( 1) NOT NULL DEFAULT '0', -- < > ist es eine abholadresse - -- communication - phone1 CHAR ( 40) NOT NULL DEFAULT '', -- < > - phone2 CHAR ( 40) NOT NULL DEFAULT '', -- < > - phone3 CHAR ( 40) NOT NULL DEFAULT '', -- < > - phone4 CHAR ( 40) NOT NULL DEFAULT '', -- < > - mobile1 CHAR ( 40) NOT NULL DEFAULT '', -- < > - mobile2 CHAR ( 40) NOT NULL DEFAULT '', -- < > - mobile3 CHAR ( 40) NOT NULL DEFAULT '', -- < > - mobile4 CHAR ( 40) NOT NULL DEFAULT '', -- < > - fax1 CHAR ( 40) NOT NULL DEFAULT '', -- < > - fax2 CHAR ( 40) NOT NULL DEFAULT '', -- < > - fax3 CHAR ( 40) NOT NULL DEFAULT '', -- < > - fax4 CHAR ( 40) NOT NULL DEFAULT '', -- < > - email1 CHAR ( 80) NOT NULL DEFAULT '', -- < > - email2 CHAR ( 80) NOT NULL DEFAULT '', -- < > - email3 CHAR ( 80) NOT NULL DEFAULT '', -- < > - email4 CHAR ( 80) NOT NULL DEFAULT '', -- < > - website1 CHAR (250) NOT NULL DEFAULT '', -- < > - website2 CHAR (250) NOT NULL DEFAULT '', -- < > - website3 CHAR (250) NOT NULL DEFAULT '', -- < > - website4 CHAR (250) NOT NULL DEFAULT '', -- < > - - -- bank - idBankAccount1 BIGINT NOT NULL DEFAULT '0', -- - idBankAccount2 BIGINT NOT NULL DEFAULT '0', -- - idBankAccount3 BIGINT NOT NULL DEFAULT '0', -- - idBankAccount4 BIGINT NOT NULL DEFAULT '0', -- - -- accountdata - userName CHAR ( 40) NOT NULL DEFAULT '', -- < > - userPassword CHAR ( 40) NOT NULL DEFAULT '', -- < > - userPin CHAR ( 40) NOT NULL DEFAULT '', -- < > - userPasswordHint CHAR ( 80) NOT NULL DEFAULT '', -- < > - -- phonetic - ptmatchcode CHAR ( 80) NOT NULL DEFAULT '', -- - ptName1 CHAR ( 80) NOT NULL DEFAULT '', -- - ptName2 CHAR ( 80) NOT NULL DEFAULT '', -- - ptName3 CHAR ( 80) NOT NULL DEFAULT '', -- - ptName4 CHAR ( 80) NOT NULL DEFAULT '', -- - ptAppendix1 CHAR ( 80) NOT NULL DEFAULT '', -- < > - ptAppendix2 CHAR ( 80) NOT NULL DEFAULT '', -- < > - ptAppendix3 CHAR ( 80) NOT NULL DEFAULT '', -- < > - ptAppendix4 CHAR ( 80) NOT NULL DEFAULT '', -- < > - ptStreet CHAR ( 80) NOT NULL DEFAULT '', -- - ptCity CHAR ( 40) NOT NULL DEFAULT '', -- - bvExportCertificate TINYINT ( 1) NOT NULL DEFAULT '0', - -- shop - bvShopAccess TINYINT ( 1) NOT NULL DEFAULT '0', - -- versandhinweise - bvSelfCollector TINYINT ( 1) NOT NULL DEFAULT '0', -- Selbstabholer - bvCarLifter TINYINT ( 1) NOT NULL DEFAULT '0', -- Hebebühne - dispatchHint1 CHAR (250) NOT NULL DEFAULT '', -- Versandhinweis1 - dispatchHint2 CHAR (250) NOT NULL DEFAULT '', -- Versandhinweis2 - dispatchHint3 CHAR (250) NOT NULL DEFAULT '', -- Versandhinweis3 - dispatchHint4 CHAR (250) NOT NULL DEFAULT '', -- Versandhinweis4 - tmFrom TIME NOT NULL DEFAULT '00:00:00', - tmUntil TIME NOT NULL DEFAULT '00:00:00' - - ,PRIMARY KEY (idRecord) -) - -CREATE TABLE customer ( - -- reserved - idRecord BIGINT NOT NULL, -- - recordState INT NOT NULL DEFAULT '0', -- - idAddressCreate BIGINT NOT NULL DEFAULT '0', -- < > - addressLevel BIGINT NOT NULL DEFAULT '0', -- < > - recordFlags BIGINT NOT NULL DEFAULT '0', -- < > - tsUpdate BIGINT NOT NULL DEFAULT '0', -- < > - idAddressUpdate BIGINT NOT NULL DEFAULT '0', -- < > - tsVirtualDel BIGINT NOT NULL DEFAULT '0', -- - idAddressVirtualDel BIGINT NOT NULL DEFAULT '0', -- < > - revision BIGINT NOT NULL DEFAULT '0', -- < > - archiveFlag INT NOT NULL DEFAULT '0', -- - poolFlag INT NOT NULL DEFAULT '0', -- < > - -- backreference - idAddress BIGINT NOT NULL DEFAULT '0', -- - -- general informations - bvCustomer TINYINT ( 1) NOT NULL DEFAULT '0', -- ist Kunde, sonst nur Interessent - idChoicerType BIGINT NOT NULL DEFAULT '0', -- Art - idChoicerBranch BIGINT NOT NULL DEFAULT '0', -- - customerNo CHAR ( 20) NOT NULL DEFAULT '', -- - bvCustomerNoManual TINYINT ( 1) NOT NULL DEFAULT '0', -- Wurde die Kundennummer manuell vergeben - debitorNo CHAR ( 20) NOT NULL DEFAULT '', -- - bvDebitorNoManual TINYINT ( 1) NOT NULL DEFAULT '0', -- Wurde die Nummer manuell vergeben - supplierNo CHAR ( 20) NOT NULL DEFAULT '', -- < > eigene Lieferantennummer beim Kunden - discount DOUBLE NOT NULL DEFAULT '0', -- < > Kundenrabatt - creditLimit DOUBLE NOT NULL DEFAULT '0', -- < > Kreditlimit - dtCreditRating DATE, -- < > Datum der letzten Bonitätsprüfung - creditRating CHAR ( 80) NOT NULL DEFAULT '', -- < > Bonität z. B. AAA oder 2,3 - bvCreditInsurance TINYINT ( 1) NOT NULL DEFAULT '0', -- < > Forderungsausfallversicherung - additionalLimit DOUBLE NOT NULL DEFAULT '0', -- < > zusätzliches, nicht versicherters Limit - bvDunning TINYINT ( 1) NOT NULL DEFAULT '0', -- < > Kunde darf gemahnt werden - consuptionTaxNo CHAR ( 40) NOT NULL DEFAULT '', -- < > Verbrauchs-Steuernummer - idAssistant BIGINT NOT NULL DEFAULT '0', -- id des Sachbearbeiters - idAgent BIGINT NOT NULL DEFAULT '0', -- < > ID des Vertreters - idPriceTerm BIGINT NOT NULL DEFAULT '0', -- < > id from Konditionsgeber - idPaymentTerm BIGINT NOT NULL DEFAULT '0', -- < > ID der Zahlungsbedinung - idDeliveryTerm BIGINT NOT NULL DEFAULT '0', -- < > ID der Lieferbedinung - idAddressInvoice BIGINT NOT NULL DEFAULT '0', -- < > ID der Rechnungsadresse - idAddressDelivery BIGINT NOT NULL DEFAULT '0', -- < > ID der Lieferadresse - additionalDeliveryTerm CHAR ( 80) NOT NULL DEFAULT '', -- < > Zusatz zur Lieferbedingung - idChoicerPackaging BIGINT NOT NULL DEFAULT '0', -- < > ID der Verpackungsart - Choicer 512001 - idDispatchMode BIGINT NOT NULL DEFAULT '0', -- < > ID der Versandart - idPriceGroup BIGINT NOT NULL DEFAULT '0', -- < > - aaIdx INT NOT NULL DEFAULT '0', -- < > fibu kenner - idCurrency BIGINT NOT NULL DEFAULT '0', -- < > - idChoicerPaymentMethod BIGINT NOT NULL DEFAULT '0', -- < > Standard-Zahlungsmethode - idBankAccountPayment BIGINT NOT NULL DEFAULT '0', -- < > - idEdi BIGINT NOT NULL DEFAULT '0', -- < > - idTimeFrameDelivery BIGINT NOT NULL DEFAULT '0', -- < > - idPaymentTypeShop BIGINT NOT NULL DEFAULT '0', -- < > ID der Zahlungsart im Shop - idDispatchModeShop BIGINT NOT NULL DEFAULT '0', -- < > ID der Versandart im Shop - idAddressInvoiceShop BIGINT NOT NULL DEFAULT '0', -- < > ID der Rechnungsadresse im Shop - idAddressDeliveryShop BIGINT NOT NULL DEFAULT '0', -- < > ID der Lieferadresse im Shop - - bvArticleCost1 TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - idArticleCost1 BIGINT NOT NULL DEFAULT '0', -- < > - articleCostThreshold1 DOUBLE NOT NULL DEFAULT '0', -- < > - articleCost1 DOUBLE NOT NULL DEFAULT '0', -- < > - - bvArticleCost2 TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - idArticleCost2 BIGINT NOT NULL DEFAULT '0', -- < > - articleCostThreshold2 DOUBLE NOT NULL DEFAULT '0', -- < > - articleCost2 DOUBLE NOT NULL DEFAULT '0', -- < > - - bvArticleCost3 TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - idArticleCost3 BIGINT NOT NULL DEFAULT '0', -- < > - articleCostThreshold3 DOUBLE NOT NULL DEFAULT '0', -- < > - articleCost3 DOUBLE NOT NULL DEFAULT '0', -- < > - - bvArticleCost4 TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - idArticleCost4 BIGINT NOT NULL DEFAULT '0', -- < > - articleCostThreshold4 DOUBLE NOT NULL DEFAULT '0', -- < > - articleCost4 DOUBLE NOT NULL DEFAULT '0', -- < > - - bvArticleCost5 TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - idArticleCost5 BIGINT NOT NULL DEFAULT '0', -- < > - articleCostThreshold5 DOUBLE NOT NULL DEFAULT '0', -- < > - articleCost5 DOUBLE NOT NULL DEFAULT '0', -- < > - - bvArticleCost6 TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - idArticleCost6 BIGINT NOT NULL DEFAULT '0', -- < > - articleCostThreshold6 DOUBLE NOT NULL DEFAULT '0', -- < > - articleCost6 DOUBLE NOT NULL DEFAULT '0', -- < > - - bvArticleCost7 TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - idArticleCost7 BIGINT NOT NULL DEFAULT '0', -- < > - articleCostThreshold7 DOUBLE NOT NULL DEFAULT '0', -- < > - articleCost7 DOUBLE NOT NULL DEFAULT '0', -- < > - - bvArticleCost8 TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - idArticleCost8 BIGINT NOT NULL DEFAULT '0', -- < > - articleCostThreshold8 DOUBLE NOT NULL DEFAULT '0', -- < > - articleCost8 DOUBLE NOT NULL DEFAULT '0', -- < > - - idChoicerArea BIGINT NOT NULL DEFAULT '0', -- - bvBonus TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - unitBillingIdx INT NOT NULL DEFAULT '0', -- < > - idChoicerFormation BIGINT NOT NULL DEFAULT '0', -- < > - idAdressFormation BIGINT NOT NULL DEFAULT '0', -- < > Verband - idCustomerPriceCondition BIGINT NOT NULL DEFAULT '0', -- < > - idChoicerOrigin BIGINT NOT NULL DEFAULT '0', -- < > - idChoicerStatus BIGINT NOT NULL DEFAULT '0', -- < > - ccCustomerFree1 CHAR ( 80) NOT NULL DEFAULT '', -- < > - ccCustomerFree2 CHAR ( 80) NOT NULL DEFAULT '', -- < > - ccCustomerFree3 CHAR ( 80) NOT NULL DEFAULT '', -- < > - ccCustomerFree4 CHAR ( 80) NOT NULL DEFAULT '', -- < > - freeNote1 CHAR ( 80) NOT NULL DEFAULT '', -- < > - freeNote2 CHAR ( 80) NOT NULL DEFAULT '', -- < > - freeNote3 CHAR ( 80) NOT NULL DEFAULT '', -- < > - freeNote4 CHAR ( 80) NOT NULL DEFAULT '', -- < > - idAddressCarrier BIGINT NOT NULL DEFAULT '0', -- < > - idAddressSupplier BIGINT NOT NULL DEFAULT '0', -- < > - bvDeliveryStop TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - documentFooterText CHAR ( 80) NOT NULL DEFAULT '', -- < > - - - -- ranking for normal business = invoices and credit notes - -- - -- values (turnover and amount): actual year, last 12 months and last 4 years, percent of deviation - -- - rankingMin0 INT NOT NULL DEFAULT '0',-- Ranking im aktuellen Jahr - rankingMin1 INT NOT NULL DEFAULT '0',-- Ranking im letzten Jahr - rankingMin2 INT NOT NULL DEFAULT '0',-- Ranking im vorletzten Jahr - rankingMin3 INT NOT NULL DEFAULT '0',-- etc. - rankingMin4 INT NOT NULL DEFAULT '0',-- - - rankingTurnoverTotal DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz gesamt - rankingQuantityTotal DOUBLE NOT NULL DEFAULT '0',-- < > Menge gesamt - - rankingTurnover12Months DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz letzte 12 Monate - rankingQuantity12Months DOUBLE NOT NULL DEFAULT '0',-- < > Menge letzte 12 Monate - - rankingTurnoverMin0 DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz aktuelles Jahr - rankingTurnoverPer0 DOUBLE NOT NULL DEFAULT '0',-- < > Abweichung Umsatz zum Vorjahr im Prozent - rankingQuantityMin0 DOUBLE NOT NULL DEFAULT '0',-- < > Menge aktuelles Jahr - rankingQuantityPer0 DOUBLE NOT NULL DEFAULT '0',-- < > Abweichung Menge zum Vorjahr im Prozent - - rankingTurnoverMin1Compare DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz Vergleichszeitraum im letzten Jahr zum aktuellen Jahr - rankingQuantityMin1Compare DOUBLE NOT NULL DEFAULT '0',-- < > Menge Vergleichszeitraum im letzten Jahr zum aktuellen Jahr - - rankingTurnoverMin1 DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz letztes Jahr - rankingTurnoverPer1 DOUBLE NOT NULL DEFAULT '0',-- < > Abweichung Umsatz zum vorletzten Jahr im Prozent - rankingQuantityMin1 DOUBLE NOT NULL DEFAULT '0',-- < > Menge letztes Jahr - rankingQuantityPer1 DOUBLE NOT NULL DEFAULT '0',-- < > Abweichung Menge zum vorletzten Jahr im Prozent - - rankingTurnoverMin2 DOUBLE NOT NULL DEFAULT '0',-- < > etc. - rankingTurnoverPer2 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingQuantityMin2 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingQuantityPer2 DOUBLE NOT NULL DEFAULT '0',-- < > - - rankingTurnoverMin3 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingTurnoverPer3 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingQuantityMin3 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingQuantityPer3 DOUBLE NOT NULL DEFAULT '0',-- < > - - rankingTurnoverMin4 DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz vor 4 Jahren - rankingQuantityMin4 DOUBLE NOT NULL DEFAULT '0',-- < > Menge vor 4 Jahren - - - -- ranking for agency business = saleOrders with documentMode = 1011040 - -- - -- values (turnover and amount): actual year, last 12 months and last 4 years, percent of deviation - -- - rankingAgencyMin0 INT NOT NULL DEFAULT '0',-- Ranking Agenturgeschäft im aktuellen Jahr - rankingAgencyMin1 INT NOT NULL DEFAULT '0',-- Ranking Agenturgeschäft im letzten Jahr - rankingAgencyMin2 INT NOT NULL DEFAULT '0',-- Ranking Agenturgeschäft im vorletzten Jahr - rankingAgencyMin3 INT NOT NULL DEFAULT '0',-- etc. - rankingAgencyMin4 INT NOT NULL DEFAULT '0',-- - - rankingAgencyTurnoverTotal DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz gesamt - rankingAgencyQuantityTotal DOUBLE NOT NULL DEFAULT '0',-- < > Menge gesamt - - rankingAgencyTurnover12Months DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz letzte 12 Monate - rankingAgencyQuantity12Months DOUBLE NOT NULL DEFAULT '0',-- < > Menge letzte 12 Monate - - rankingAgencyTurnoverMin0 DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz aktuelles Jahr - rankingAgencyTurnoverPer0 DOUBLE NOT NULL DEFAULT '0',-- < > Abweichung Umsatz zum Vorjahr im Prozent - rankingAgencyQuantityMin0 DOUBLE NOT NULL DEFAULT '0',-- < > Menge aktuelles Jahr - rankingAgencyQuantityPer0 DOUBLE NOT NULL DEFAULT '0',-- < > Abweichung Menge zum Vorjahr im Prozent - - rankingAgencyTurnoverMin1Compare DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz Vergleichszeitraum im letzten Jahr zum aktuellen Jahr - rankingAgencyQuantityMin1Compare DOUBLE NOT NULL DEFAULT '0',-- < > Menge Vergleichszeitraum im letzten Jahr zum aktuellen Jahr - - rankingAgencyTurnoverMin1 DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz letztes Jahr - rankingAgencyTurnoverPer1 DOUBLE NOT NULL DEFAULT '0',-- < > Abweichung Umsatz zum vorletzten Jahr im Prozent - rankingAgencyQuantityMin1 DOUBLE NOT NULL DEFAULT '0',-- < > Menge letztes Jahr - rankingAgencyQuantityPer1 DOUBLE NOT NULL DEFAULT '0',-- < > Abweichung Menge zum vorletzten Jahr im Prozent - - rankingAgencyTurnoverMin2 DOUBLE NOT NULL DEFAULT '0',-- < > etc. - rankingAgencyTurnoverPer2 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingAgencyQuantityMin2 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingAgencyQuantityPer2 DOUBLE NOT NULL DEFAULT '0',-- < > - - rankingAgencyTurnoverMin3 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingAgencyTurnoverPer3 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingAgencyQuantityMin3 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingAgencyQuantityPer3 DOUBLE NOT NULL DEFAULT '0',-- < > - - rankingAgencyTurnoverMin4 DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz vor 4 Jahren - rankingAgencyQuantityMin4 DOUBLE NOT NULL DEFAULT '0',-- < > Menge vor 4 Jahren - - - -- ranking for all normal and agency business - rankingTotalMin0 INT NOT NULL DEFAULT '0',-- Ranking gesamt im aktuellen Jahr - rankingTotalMin1 INT NOT NULL DEFAULT '0',-- Ranking gesamt im letzten Jahr - rankingTotalMin2 INT NOT NULL DEFAULT '0',-- Ranking gesamt im vorletzten Jahr - rankingTotalMin3 INT NOT NULL DEFAULT '0',-- etc. - rankingTotalMin4 INT NOT NULL DEFAULT '0'-- - - - ,PRIMARY KEY (idRecord) -) - -CREATE TABLE supplier ( - -- reserved - idRecord BIGINT NOT NULL, -- - recordState INT NOT NULL DEFAULT '0',-- - idAddressCreate BIGINT NOT NULL DEFAULT '0',-- < > - addressLevel BIGINT NOT NULL DEFAULT '0',-- < > - recordFlags BIGINT NOT NULL DEFAULT '0',-- < > - tsUpdate BIGINT NOT NULL DEFAULT '0',-- < > - idAddressUpdate BIGINT NOT NULL DEFAULT '0',-- < > - tsVirtualDel BIGINT NOT NULL DEFAULT '0',-- - idAddressVirtualDel BIGINT NOT NULL DEFAULT '0',-- < > - revision BIGINT NOT NULL DEFAULT '0',-- < > - archiveFlag INT NOT NULL DEFAULT '0',-- - poolFlag INT NOT NULL DEFAULT '0',-- < > - -- backreference - idAddress BIGINT NOT NULL DEFAULT '0',-- - -- general informations - idChoicerType BIGINT NOT NULL DEFAULT '0',-- - idChoicerBranch BIGINT NOT NULL DEFAULT '0',-- - supplierNo CHAR ( 20) NOT NULL DEFAULT '',-- Lieferantennummer - bvSupplierNoManual TINYINT ( 1) NOT NULL DEFAULT '0',-- Wurde die Lieferantennummer manuell vergeben - creditorNo CHAR ( 20) NOT NULL DEFAULT '',-- - bvCreditorNoManual TINYINT ( 1) NOT NULL DEFAULT '0',-- Wurde die Nummer manuell vergeben - bvDirectDelivery TINYINT ( 1) NOT NULL DEFAULT '0',-- < > macht der Lieferant Direktlieferungen - bvCarrier TINYINT ( 1) NOT NULL DEFAULT '0', -- lieferant ist spediteur - bvSupplierDeclaration TINYINT ( 1) NOT NULL DEFAULT '0',-- < > Lieferanten-Erklärung - dtDeclarationValid DATE, -- < > Lieferanten-Erklärung gültig bis - bvNoSupplierDeclaration TINYINT ( 1) NOT NULL DEFAULT '0',-- < > Lieferanten-dibt keine erklärung ab - dtNoSupplierDeclaration DATE, -- < > keine lieferantenerklärung eingetragen am - bvForecastCalculation CHAR ( 20) NOT NULL DEFAULT '',-- < > Forecast - supplierCustomerNo CHAR ( 20) NOT NULL DEFAULT '',-- eigene Kundennummer beim Lieferanten - - orderValue DOUBLE NOT NULL DEFAULT '0',-- < > Mindestbestellwert - discount DOUBLE NOT NULL DEFAULT '0',-- < > Rabatt - creditLimit DOUBLE NOT NULL DEFAULT '0',-- < > - agencyProvision DOUBLE NOT NULL DEFAULT '0',-- < > Provisionssatz bei Agenturgeschäft - idPaymentTerm BIGINT NOT NULL DEFAULT '0',-- < > - idDeliveryTerm BIGINT NOT NULL DEFAULT '0',-- < > - additionalDeliveryTerm CHAR ( 80) NOT NULL DEFAULT '',-- < > Zusatz zur Lieferbedingung - aaIdx INT NOT NULL DEFAULT '0',-- < > fibu kenner - idCurrency BIGINT NOT NULL DEFAULT '0',-- < > - idChoicerPaymentMethod BIGINT NOT NULL DEFAULT '0',-- < > Standard-Zahlungsmethode - idBankAccountPayment BIGINT NOT NULL DEFAULT '0',-- < > - idEdi BIGINT NOT NULL DEFAULT '0',-- < > - idTimeFrameDelivery BIGINT NOT NULL DEFAULT '0',-- < > - idChoicerPackaging BIGINT NOT NULL DEFAULT '0',-- < > ID der Verpackungsart - Choicer 512001 - idDispatchMode BIGINT NOT NULL DEFAULT '0',-- < > ID der Versandart - - ccArea CHAR ( 80) NOT NULL DEFAULT '',-- < > - bvBonus TINYINT ( 1) NOT NULL DEFAULT '0',-- < > - unitBillingIdx INT NOT NULL DEFAULT '0',-- < > - idChoicerStatus BIGINT NOT NULL DEFAULT '0',-- < > - ccSupplierFree1 CHAR ( 80) NOT NULL DEFAULT '',-- < > - ccSupplierFree2 CHAR ( 80) NOT NULL DEFAULT '',-- < > - ccSupplierFree3 CHAR ( 80) NOT NULL DEFAULT '',-- < > - ccSupplierFree4 CHAR ( 80) NOT NULL DEFAULT '',-- < > - freeNote1 CHAR ( 80) NOT NULL DEFAULT '',-- < > - freeNote2 CHAR ( 80) NOT NULL DEFAULT '',-- < > - freeNote3 CHAR ( 80) NOT NULL DEFAULT '',-- < > - freeNote4 CHAR ( 80) NOT NULL DEFAULT '',-- < > - idAddressCarrier BIGINT NOT NULL DEFAULT '0',-- < > - idAddressSupplier BIGINT NOT NULL DEFAULT '0',-- < > - bvDeliveryStop TINYINT ( 1) NOT NULL DEFAULT '0',-- < > - documentFooterText CHAR ( 80) NOT NULL DEFAULT '',-- < > - - -- ranking for normal business = purchase invoices and purchase credit notes - -- - -- values (turnover and amount): actual year, last 12 months and last 4 years, percent of deviation - -- - rankingMin0 INT NOT NULL DEFAULT '0',-- Ranking im aktuellen Jahr - rankingMin1 INT NOT NULL DEFAULT '0',-- Ranking im letzten Jahr - rankingMin2 INT NOT NULL DEFAULT '0',-- Ranking im vorletzten Jahr - rankingMin3 INT NOT NULL DEFAULT '0',-- etc. - rankingMin4 INT NOT NULL DEFAULT '0',-- - - rankingTurnoverTotal DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz gesamt - rankingQuantityTotal DOUBLE NOT NULL DEFAULT '0',-- < > Menge gesamt - - rankingTurnover12Months DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz letzte 12 Monate - rankingQuantity12Months DOUBLE NOT NULL DEFAULT '0',-- < > Menge letzte 12 Monate - - rankingTurnoverMin0 DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz aktuelles Jahr - rankingTurnoverPer0 DOUBLE NOT NULL DEFAULT '0',-- < > Abweichung Umsatz zum Vorjahr im Prozent - rankingQuantityMin0 DOUBLE NOT NULL DEFAULT '0',-- < > Menge aktuelles Jahr - rankingQuantityPer0 DOUBLE NOT NULL DEFAULT '0',-- < > Abweichung Menge zum Vorjahr im Prozent - - rankingTurnoverMin1Compare DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz Vergleichszeitraum im letzten Jahr zum aktuellen Jahr - rankingQuantityMin1Compare DOUBLE NOT NULL DEFAULT '0',-- < > Menge Vergleichszeitraum im letzten Jahr zum aktuellen Jahr - - rankingTurnoverMin1 DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz letztes Jahr - rankingTurnoverPer1 DOUBLE NOT NULL DEFAULT '0',-- < > Abweichung Umsatz zum vorletzten Jahr im Prozent - rankingQuantityMin1 DOUBLE NOT NULL DEFAULT '0',-- < > Menge letztes Jahr - rankingQuantityPer1 DOUBLE NOT NULL DEFAULT '0',-- < > Abweichung Menge zum vorletzten Jahr im Prozent - - rankingTurnoverMin2 DOUBLE NOT NULL DEFAULT '0',-- < > etc. - rankingTurnoverPer2 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingQuantityMin2 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingQuantityPer2 DOUBLE NOT NULL DEFAULT '0',-- < > - - rankingTurnoverMin3 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingTurnoverPer3 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingQuantityMin3 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingQuantityPer3 DOUBLE NOT NULL DEFAULT '0',-- < > - - rankingTurnoverMin4 DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz vor 4 Jahren - rankingQuantityMin4 DOUBLE NOT NULL DEFAULT '0',-- < > Menge vor 4 Jahren - - -- ranking for agency business = saleOrders with documentMode = 1011040 - -- - -- values (turnover and amount): actual year, last 12 months and last 4 years, percent of deviation - -- - rankingAgencyMin0 INT NOT NULL DEFAULT '0',-- Ranking Agenturgeschäft im aktuellen Jahr - rankingAgencyMin1 INT NOT NULL DEFAULT '0',-- Ranking Agenturgeschäft im letzten Jahr - rankingAgencyMin2 INT NOT NULL DEFAULT '0',-- Ranking Agenturgeschäft im vorletzten Jahr - rankingAgencyMin3 INT NOT NULL DEFAULT '0',-- etc. - rankingAgencyMin4 INT NOT NULL DEFAULT '0',-- - - rankingAgencyTurnoverTotal DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz gesamt - rankingAgencyQuantityTotal DOUBLE NOT NULL DEFAULT '0',-- < > Menge gesamt - - rankingAgencyTurnover12Months DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz letzte 12 Monate - rankingAgencyQuantity12Months DOUBLE NOT NULL DEFAULT '0',-- < > Menge letzte 12 Monate - - rankingAgencyTurnoverMin0 DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz aktuelles Jahr - rankingAgencyTurnoverPer0 DOUBLE NOT NULL DEFAULT '0',-- < > Abweichung Umsatz zum Vorjahr im Prozent - rankingAgencyQuantityMin0 DOUBLE NOT NULL DEFAULT '0',-- < > Menge aktuelles Jahr - rankingAgencyQuantityPer0 DOUBLE NOT NULL DEFAULT '0',-- < > Abweichung Menge zum Vorjahr im Prozent - - rankingAgencyTurnoverMin1Compare DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz Vergleichszeitraum im letzten Jahr zum aktuellen Jahr - rankingAgencyQuantityMin1Compare DOUBLE NOT NULL DEFAULT '0',-- < > Menge Vergleichszeitraum im letzten Jahr zum aktuellen Jahr - - rankingAgencyTurnoverMin1 DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz letztes Jahr - rankingAgencyTurnoverPer1 DOUBLE NOT NULL DEFAULT '0',-- < > Abweichung Umsatz zum vorletzten Jahr im Prozent - rankingAgencyQuantityMin1 DOUBLE NOT NULL DEFAULT '0',-- < > Menge letztes Jahr - rankingAgencyQuantityPer1 DOUBLE NOT NULL DEFAULT '0',-- < > Abweichung Menge zum vorletzten Jahr im Prozent - - rankingAgencyTurnoverMin2 DOUBLE NOT NULL DEFAULT '0',-- < > etc. - rankingAgencyTurnoverPer2 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingAgencyQuantityMin2 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingAgencyQuantityPer2 DOUBLE NOT NULL DEFAULT '0',-- < > - - rankingAgencyTurnoverMin3 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingAgencyTurnoverPer3 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingAgencyQuantityMin3 DOUBLE NOT NULL DEFAULT '0',-- < > - rankingAgencyQuantityPer3 DOUBLE NOT NULL DEFAULT '0',-- < > - - rankingAgencyTurnoverMin4 DOUBLE NOT NULL DEFAULT '0',-- < > Umsatz vor 4 Jahren - rankingAgencyQuantityMin4 DOUBLE NOT NULL DEFAULT '0',-- < > Menge vor 4 Jahren - - -- ranking for all normal and agency business - rankingTotalMin0 INT NOT NULL DEFAULT '0',-- Ranking gesamt im aktuellen Jahr - rankingTotalMin1 INT NOT NULL DEFAULT '0',-- Ranking gesamt im letzten Jahr - rankingTotalMin2 INT NOT NULL DEFAULT '0',-- Ranking gesamt im vorletzten Jahr - rankingTotalMin3 INT NOT NULL DEFAULT '0',-- etc. - rankingTotalMin4 INT NOT NULL DEFAULT '0'-- - - ,PRIMARY KEY (idRecord) -) - - CREATE TABLE employee ( - -- reserved - idRecord BIGINT NOT NULL, -- - recordState INT NOT NULL DEFAULT '0', -- - idAddressCreate BIGINT NOT NULL DEFAULT '0', -- < > - addressLevel BIGINT NOT NULL DEFAULT '0', -- < > - recordFlags BIGINT NOT NULL DEFAULT '0', -- < > - tsUpdate BIGINT NOT NULL DEFAULT '0', -- < > - idAddressUpdate BIGINT NOT NULL DEFAULT '0', -- < > - tsVirtualDel BIGINT NOT NULL DEFAULT '0', -- - idAddressVirtualDel BIGINT NOT NULL DEFAULT '0', -- < > - revision BIGINT NOT NULL DEFAULT '0', -- < > - archiveFlag INT NOT NULL DEFAULT '0', -- - poolFlag INT NOT NULL DEFAULT '0', -- < > - -- backreference - idAddress BIGINT NOT NULL DEFAULT '0', -- - -- general informations - birthName CHAR ( 40) NOT NULL DEFAULT '', -- < > - personnelNo CHAR ( 40) NOT NULL DEFAULT '', -- - bvPersonnelNoManual TINYINT ( 1) NOT NULL DEFAULT '0', -- Wurde die Personalnummer manuell vergeben - dtJobBeginning DATE, -- < > - dtJobEnding DATE, -- < > - freeNote1 CHAR ( 80) NOT NULL DEFAULT '', -- < > - freeNote2 CHAR ( 80) NOT NULL DEFAULT '', -- < > - freeNote3 CHAR ( 80) NOT NULL DEFAULT '', -- < > - freeNote4 CHAR ( 80) NOT NULL DEFAULT '', -- < > - -- role - idChoicerDepartment BIGINT NOT NULL DEFAULT '0', -- Abteilung - idChoicerFunction BIGINT NOT NULL DEFAULT '0', -- Funktion, z.B. Abteilungsleiter, Einkäufer - bvUser TINYINT ( 1) NOT NULL DEFAULT '0', -- - bvAssistant TINYINT ( 1) NOT NULL DEFAULT '0', -- - bvAgent TINYINT ( 1) NOT NULL DEFAULT '0', -- - bvProduction TINYINT ( 1) NOT NULL DEFAULT '0', -- - bvSelfDc TINYINT ( 1) NOT NULL DEFAULT '0', -- < > nur eigene BDE-Erfassung, nur wirksam, falls bvProduction gesetzt - bvLaborTime TINYINT ( 1) NOT NULL DEFAULT '0', -- Personalzeiterfassung - -- costs - chargeRate DOUBLE NOT NULL DEFAULT '0', -- < > - chargeRateInternal DOUBLE NOT NULL DEFAULT '0', -- < > - chargeRateExternal DOUBLE NOT NULL DEFAULT '0', -- < > - -- mail - mailHost CHAR ( 80) NOT NULL DEFAULT '', -- < > - mailUser CHAR ( 80) NOT NULL DEFAULT '', -- < > - mailPassword CHAR ( 80) NOT NULL DEFAULT '', -- < > - mailEncryption INT NOT NULL DEFAULT '0', -- < > 0 = Keine , 1 = STARTTLS, 2 = SSL/TLS - mailAuthMethod INT NOT NULL DEFAULT '0', -- < > 0 = Password, normal - mailFrom CHAR ( 80) NOT NULL DEFAULT '', -- < > - mailFromName CHAR ( 80) NOT NULL DEFAULT '', -- < > - bvMailSmtp TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - bvMailSmtpAuth TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - bvMailIsHtml TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - mailClient CHAR ( 80) NOT NULL DEFAULT '', -- < > - mailCharset CHAR ( 80) NOT NULL DEFAULT '', -- < > - idResourceScheduleGroup BIGINT NOT NULL DEFAULT '0', -- < > - bvTargetTimeActual TINYINT ( 1) NOT NULL DEFAULT '0', -- < > Sollzeit = Istzeit, z.b. bei Aushilfen - dtLastBalance DATE, -- Datum letzte Abrechnung - secondsTarget BIGINT NOT NULL DEFAULT '0', -- < > Sollzeit in sekunden pro Woche - secondsTargetMonth BIGINT NOT NULL DEFAULT '0', -- < > Sollzeit in sekunden pro Monat - minutesRoundUp INT NOT NULL DEFAULT '0', -- < > aufrunden auf nächste Minuten bei Anmeldung - minutesRoundDown INT NOT NULL DEFAULT '0', -- < > abrunden auf vorherige Minuten bei Abmeldung - secondsLastBalance BIGINT NOT NULL DEFAULT '0', -- < > Zeitvortrag bei letzter Abrechnung in Sekunden - secondsActual BIGINT NOT NULL DEFAULT '0', -- < > aktueller Zeitvortrag in Sekunden seit letzter abrechnung - secondsThresholdIncluded BIGINT NOT NULL DEFAULT '0', -- < > Zeit in Sekunden, die im Arbeitsvertrag enthalten sind und nicht als Überstunden in den nächsten Monat mitgenommen werden - type INT NOT NULL DEFAULT '0', -- 1 angestellter, 2 = freier mitarbeiter (sollzeit = istzeit) - vacationStandard DOUBLE NOT NULL DEFAULT '0', -- < > Urlaubsanspruch - vacationHandicapped DOUBLE NOT NULL DEFAULT '0', -- < > Behindertenurlaub - vacationRest DOUBLE NOT NULL DEFAULT '0', -- < > Resturlaub Vorjahr - vacationDeclared DOUBLE NOT NULL DEFAULT '0', -- < > angemeldeter Urlaub - vacationUsed DOUBLE NOT NULL DEFAULT '0', -- < > genommener Urlaub - tmTargetMonday TIME NOT NULL DEFAULT '00:00:00', -- < > Sollzeit Montag - tmTargetTuesday TIME NOT NULL DEFAULT '00:00:00', -- < > Sollzeit Dienstag - tmTargetWednesday TIME NOT NULL DEFAULT '00:00:00', -- < > Sollzeit Mittwoch - tmTargetThursday TIME NOT NULL DEFAULT '00:00:00', -- < > Sollzeit Donnerstag - tmTargetFriday TIME NOT NULL DEFAULT '00:00:00', -- < > Sollzeit Freitag - tmTargetSaturday TIME NOT NULL DEFAULT '00:00:00', -- < > Sollzeit Samstag - tmTargetSunday TIME NOT NULL DEFAULT '00:00:00', -- < > Sollzeit Sonntag - tmBreakMonday TIME NOT NULL DEFAULT '00:00:00', -- < > Pause Montag - tmBreakTuesday TIME NOT NULL DEFAULT '00:00:00', -- < > Pause Dienstag - tmBreakWednesday TIME NOT NULL DEFAULT '00:00:00', -- < > Pause Mittwoch - tmBreakThursday TIME NOT NULL DEFAULT '00:00:00', -- < > Pause Donnerstag - tmBreakFriday TIME NOT NULL DEFAULT '00:00:00', -- < > Pause Freitag - tmBreakSaturday TIME NOT NULL DEFAULT '00:00:00', -- < > Pause Samstag - tmBreakSunday TIME NOT NULL DEFAULT '00:00:00' -- < > Pause Sonntag - - ,PRIMARY KEY (idRecord) -) - -CREATE TABLE connectoraddress ( - -- reserved - idRecord BIGINT NOT NULL, -- - recordState INT NOT NULL DEFAULT '0', -- - idAddressCreate BIGINT NOT NULL DEFAULT '0', -- < > - addressLevel BIGINT NOT NULL DEFAULT '0', -- < > - recordFlags BIGINT NOT NULL DEFAULT '0', -- < > - tsUpdate BIGINT NOT NULL DEFAULT '0', -- < > - idAddressUpdate BIGINT NOT NULL DEFAULT '0', -- < > - tsVirtualDel BIGINT NOT NULL DEFAULT '0', -- - idAddressVirtualDel BIGINT NOT NULL DEFAULT '0', -- < > - revision BIGINT NOT NULL DEFAULT '0', -- < > - archiveFlag INT NOT NULL DEFAULT '0', -- - poolFlag INT NOT NULL DEFAULT '0', -- < > - -- general informations - idAddressSource BIGINT NOT NULL DEFAULT '0', -- idRecord des Kunden oder Lieferanten - idAddressTarget BIGINT NOT NULL DEFAULT '0', -- - isAgent TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - isBillingAddress TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - isDeliveryAddress TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - isLocation TINYINT ( 1) NOT NULL DEFAULT '0', -- < > Standort - ccAddressType CHAR ( 40) NOT NULL DEFAULT '', -- < > - idEmployee BIGINT NOT NULL DEFAULT '0', -- Betreuer - idChoicerFunction BIGINT NOT NULL DEFAULT '0', -- Funktion, z.B. Abteilungsleiter, Einkäufer - idChoicerDepartment BIGINT NOT NULL DEFAULT '0', -- Abteilung - debitorNo CHAR ( 20) NOT NULL DEFAULT '', -- - bvDebitorNoManual TINYINT ( 1) NOT NULL DEFAULT '0', -- Wurde die Nummer manuell vergeben - creditorNo CHAR ( 20) NOT NULL DEFAULT '', -- - bvCreditorNoManual TINYINT ( 1) NOT NULL DEFAULT '0', -- Wurde die Nummer manuell vergeben - agentPriority INT NOT NULL DEFAULT '0', -- < > - billingPriority INT NOT NULL DEFAULT '0', -- < > - deliveryPriority INT NOT NULL DEFAULT '0', -- < > - aaIdx INT NOT NULL DEFAULT '0', -- < > fibu kenner - idCurrency BIGINT NOT NULL DEFAULT '0', -- < > - creditLimit DOUBLE NOT NULL DEFAULT '0', -- < > - bvDeliveryStop TINYINT ( 1) NOT NULL DEFAULT '0', -- < > - freeNote1 CHAR ( 80) NOT NULL DEFAULT '', -- < > - freeNote2 CHAR ( 80) NOT NULL DEFAULT '', -- < > - freeNote3 CHAR ( 80) NOT NULL DEFAULT '', -- < > - freeNote4 CHAR ( 80) NOT NULL DEFAULT '', -- < > - idConnectorAddressInvoice BIGINT NOT NULL DEFAULT '0', -- < > - bvDefaultAddress TINYINT ( 1) NOT NULL DEFAULT '0' -- - - ,PRIMARY KEY (idRecord) -) diff --git a/MasterDataModels/Assets/AggregateExample.svg b/MasterDataModels/Assets/AggregateExample.svg new file mode 100644 index 0000000..603a649 --- /dev/null +++ b/MasterDataModels/Assets/AggregateExample.svg @@ -0,0 +1,335 @@ + + +-oihUid-oihCreated-oihLastModifiedOIHDataRecord-applcationUid-recordUid-created-lastModifiedApplicationDataRecord-orderNumber-customerNumber-shippingAddressUid-billingAddressUid-date-totalOrder-position-articleUid-description-cost-quantity-amountLineItem-cardNumber-expirationMonth-expirationYear-cardholderCreditCardPaymentInfolineItems1..*0..1oihApplicationRecords1..* diff --git a/MasterDataModel/Assets/DataModelSnazzyContacts.png b/MasterDataModels/Assets/DataModelSnazzyContacts.png similarity index 100% rename from MasterDataModel/Assets/DataModelSnazzyContacts.png rename to MasterDataModels/Assets/DataModelSnazzyContacts.png diff --git a/MasterDataModel/Assets/ER-Persons-relations-organizations.png b/MasterDataModels/Assets/ER-Persons-relations-organizations.png similarity index 100% rename from MasterDataModel/Assets/ER-Persons-relations-organizations.png rename to MasterDataModels/Assets/ER-Persons-relations-organizations.png diff --git a/MasterDataModel/Assets/ER-Persons-relations-persons.png b/MasterDataModels/Assets/ER-Persons-relations-persons.png similarity index 100% rename from MasterDataModel/Assets/ER-Persons-relations-persons.png rename to MasterDataModels/Assets/ER-Persons-relations-persons.png diff --git a/MasterDataModel/Assets/ER-organizations-relations-organizations.png b/MasterDataModels/Assets/ER-organizations-relations-organizations.png similarity index 100% rename from MasterDataModel/Assets/ER-organizations-relations-organizations.png rename to MasterDataModels/Assets/ER-organizations-relations-organizations.png diff --git a/MasterDataModel/Assets/GenericFields.svg b/MasterDataModels/Assets/GenericFields.svg similarity index 100% rename from MasterDataModel/Assets/GenericFields.svg rename to MasterDataModels/Assets/GenericFields.svg diff --git a/MasterDataModel/Assets/GenericFieldsMapping.svg b/MasterDataModels/Assets/GenericFieldsMapping.svg similarity index 100% rename from MasterDataModel/Assets/GenericFieldsMapping.svg rename to MasterDataModels/Assets/GenericFieldsMapping.svg diff --git a/MasterDataModel/Assets/GenericFieldsValidationEnvironment.jpg b/MasterDataModels/Assets/GenericFieldsValidationEnvironment.jpg similarity index 100% rename from MasterDataModel/Assets/GenericFieldsValidationEnvironment.jpg rename to MasterDataModels/Assets/GenericFieldsValidationEnvironment.jpg diff --git a/MasterDataModel/Assets/OIHDataModelAddresses.svg b/MasterDataModels/Assets/OIHDataModelAddresses.svg similarity index 100% rename from MasterDataModel/Assets/OIHDataModelAddresses.svg rename to MasterDataModels/Assets/OIHDataModelAddresses.svg diff --git a/MasterDataModel/Assets/OIHDataModelAdressesUML.png b/MasterDataModels/Assets/OIHDataModelAdressesUML.png similarity index 100% rename from MasterDataModel/Assets/OIHDataModelAdressesUML.png rename to MasterDataModels/Assets/OIHDataModelAdressesUML.png diff --git a/MasterDataModel/Assets/OIHDataModelProducts.png b/MasterDataModels/Assets/OIHDataModelProducts.png similarity index 100% rename from MasterDataModel/Assets/OIHDataModelProducts.png rename to MasterDataModels/Assets/OIHDataModelProducts.png diff --git a/DataModels/Assets/OIHDataRecord.svg b/MasterDataModels/Assets/OIHDataRecord.svg similarity index 98% rename from DataModels/Assets/OIHDataRecord.svg rename to MasterDataModels/Assets/OIHDataRecord.svg index ba2848d..f6307fc 100644 --- a/DataModels/Assets/OIHDataRecord.svg +++ b/MasterDataModels/Assets/OIHDataRecord.svg @@ -15,13 +15,13 @@ >OIHDataRecord-lastModifiedOIHApplicationDataRecordApplicationDataRecordoihApplicationRecords1..*oihApplicationRecords What criteria have to be considered for shaping entity types - aggregates derived from bounded context (typical records) as tree structure? diff --git a/MasterDataModel/MasterDataModelAdresses.md b/MasterDataModels/MasterDataModelAdresses.md similarity index 99% rename from MasterDataModel/MasterDataModelAdresses.md rename to MasterDataModels/MasterDataModelAdresses.md index 0a14014..eb7cc09 100644 --- a/MasterDataModel/MasterDataModelAdresses.md +++ b/MasterDataModels/MasterDataModelAdresses.md @@ -65,12 +65,12 @@ - [4.2.4.3 Person to person](#4243-person-to-person) - [4.2.5 Privacy specific requirements](#425-privacy-specific-requirements) - [5. Results](#5-results) -- [6. Questions](#6-questions) + - [5.1 UML Diagram of the OIH Master Data Model for Addresses](#51-uml-diagram-of-the-oih-master-data-model-for-addresses) + - [5.2 JSON Schema of the OIH Master Data Model for Addresses](#52-json-schema-of-the-oih-master-data-model-for-addresses) - This document describes the evaluation of the master data model for address data within in the Open Integration Hub. @@ -809,7 +809,7 @@ For the privacy requirements (and the rights management requirements as well) we ## 5. Results In the following you see the Master Data Model for addresses. -The Master Data Model for Addresses is a sub-model of the so called [OIH Data Record](../DataModels/DataModels.md). +The Master Data Model for Addresses is a sub-model of the so called [OIH Data Record](../MasterDataModels/README.md). The OIHDataRecord defines a superset of mandatory and optional (meta) data for records processed by an OIH instance. ### 5.1 UML Diagram of the OIH Master Data Model for Addresses @@ -831,4 +831,4 @@ From the UML we derive the JSON-Schemas, where we encapsulate the three object t The joint shared definitions are described in a fourth schema. -[JSON Schema for shared definitions](../src/main/schema/addresses/sharedDefinitions.json) +[JSON Schema for shared definitions](../src/main/schema/addresses/shared-definitions.json) diff --git a/MasterDataModel/MasterDataModelProducts.md b/MasterDataModels/MasterDataModelProducts.md similarity index 99% rename from MasterDataModel/MasterDataModelProducts.md rename to MasterDataModels/MasterDataModelProducts.md index 41366c5..2166c63 100644 --- a/MasterDataModel/MasterDataModelProducts.md +++ b/MasterDataModels/MasterDataModelProducts.md @@ -571,4 +571,4 @@ Accordingly, JSON Schema is the given format to describe MDMs. From the UML we derive the JSON-Schema. -[JSON Schema for products](../src/main/schema/products/product.json) +[/src/main/schema/products/product.json](../src/main/schema/products/product.json) diff --git a/MasterDataModels/README.md b/MasterDataModels/README.md new file mode 100644 index 0000000..21d0e9c --- /dev/null +++ b/MasterDataModels/README.md @@ -0,0 +1,183 @@ +# Master Data Models + + + * [1. Preface](#1-preface) + * [2. What is a Master Data Model?](#2-what-is-a-master-data-model) + * [3. Structure](#3-structure) + + [3.1 Aggregates](#31-aggregates) + * [4. Global Rules and Regulations for OMDMs](#4-global-rules-and-regulations-for-omdms) + + [4.1 OIH Data Records](#41-oih-data-records) + + [4.2 JSON-Schema](#42-json-schema) + - [4.2.1 Making a sub-model of an OMDM an OIH Data Record on the schema level](#421-making-a-sub-model-of-an-omdm-an-oih-data-record-on-the-schema-level) + * [5. Example: the Order aggregate](#5-example-the-order-aggregate) + * [6. Rules and Regulations for OMDMs provided by the OIH community](#6-rules-and-regulations-for-omdms-provided-by-the-oih-community) + + [6.1 Naming Conventions](#61-naming-conventions) + - [6.1.1 Types and Properties](#611-types-and-properties) + - [6.1.2 JSON-Schema](#612-json-schema) + + [6.2 UML Class Diagrams](#62-uml-class-diagrams) + + [6.3 Clarify all further aspects of a model with diagrams and/or textually](#63-clarify-all-further-aspects-of-a-model-with-diagrams-andor-textually) + + +## 1. Preface + +The Open Integration Hub (OIH) provides an asynchronous way of integrating applications and services. Modelling data which is processed by an OIH instance must always consider this fact! + +One consequence is, that it must be possible to send data records to and receive them from an OIH without the need or even possibility for the receiver to eagerly fetch referenced further records of any kind through an API or data store (like the (optional) OIH Data Hub). + +This is where the OIH's _Master Data Models_ come into play: + +## 2. What is a Master Data Model? + +There is not _the one_ canonical data model for the OIH as such a canonical data model would result in massive communication effort, idle times and workarounds. Instead a model for each context (domain) is defined: + +* __An OIH Master Data Model (OMDM) describes the data of a certain domain in a depth which is sufficient enough to map and synchronize the specific data of multiple applications in that domain.__ + +In other words, an OMDM is a generic data model in the context of a specific domain, which is designed to cover, if possible, all content-related requirements of the applications integrated with the model. It should be designed with following criteria in focus: + +- All use cases for the different integration scenarios between the involved applications can be matched and the data of all those applications can be mapped to the model. +- The model is generic and it can be extended on the application level. + +Using the OIH's (optional) _Data Hub_, an OMDM enables a _Master Data Management_ for the respective domain by centrally storing the data of the integrated applications. + +## 3. Structure + +A data model representing a certain professional domain normally consists of numerous entities. Hence, it is necessary to split such a data model into smaller parts to enable the transfer of optimized amounts of data through an OIH: + +* __Every OMDM consists of one or multiple _loosely coupled_ sub-models.__ + +Although it is necessary to split (especially big) data models into smaller sub-models, it often does not make sense to send each entity on its own, when there is a _high cohesion_ between certain entities. Hence, + +* __each sub-model of an OMDM can consist of one _or more_ entities.__ + +### 3.1 Aggregates + +* __In case a sub-model consists of multiple entities, it *must* be modeled as an _aggregate_:__ + +> __Aggregate__ is a pattern in Domain-Driven Design. A DDD aggregate is a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items, these will be separate objects, but it's useful to treat the order (together with its line items) as a single aggregate. +> +> An aggregate will have one of its component objects be the aggregate root. Any references from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole. +> +> [s. [Martin Fowler: DDD_Aggregate](https://martinfowler.com/bliki/DDD_Aggregate.html)] + +## 4. Global Rules and Regulations for OMDMs + +To enable the OIH to follow its purpose, the data records being processed have to fulfill some criteria and follow some rules. Some of these rules have to be applied already on the modelling level. + +### 4.1 OIH Data Records + +An OIH expects and needs, depending on the scenario and the involved components (e.g. with or without a Data Hub involved), more or less meta data on a data record to integrate two or more applications. This is achieved by modelling each sub-model of an OMDM as a so called _OIH Data Record_. The OIHDataRecord defines a superset of mandatory and optional (meta) data for records processed by an OIH instance: + +![OIH Record](Assets/OIHDataRecord.svg) + +* __Each of the the sub-models of an OMDM has to be marked as an *OIHDataRecord*.__ + +I.e., the root of an OMDM's sub-model **must** inherit from / extend _OIHDataRecord_, no matter whether it is modeled as an +aggregate or as a single entity. + +* __Every record passed into an OIH instance must at least be provided with a reference to the record of the application or service being the source of the record__, + +called an _OIHApplicationDataRecord_ containing ... + ++ the OIH's identifier for the application, ++ the record's ID within the application (both mandatory) and ++ optionally its creation and last modification dates within the application. + +When receiving such a record from an OIH, there might also be entries of other applications being part of the integrations scenario with the same OMDM in the same OIH. + +Additionally, depending on the scenario and the involved components again, the OIH itself or a connector (according to rules provided by the OIH __==> TO BE DISCUSSED!__) may also provide an OIH-internal UID for the record, along with the creation and last modification dates of the record within the OIH. + +### 4.2 JSON-Schema + +The OIH specifies JSON as the format that data is processed with. Accordingly, + +* __[JSON Schema](http://json-schema.org) is the given format to describe OMDMs__ + +in a way an OIH instance is able to validate data at runtime. And, as OMDMs are split into sub-models and the records of those sub-models must be processable independently, + +* __for every sub-model of an OMDM there must be a _seperate_ JSON schema describing the entity or aggregate.__ + +As there are situations where entities are reused in (i.e. are part of) two or more aggregates, it is of course adequat to encapsulate those entities in an additional schema file and reference them from the several sub-models to avoid redundancy. + +#### 4.2.1 Making a sub-model of an OMDM an OIH Data Record on the schema level + +There is a predefined JSON-Schema defining the OIHDataRecord (s. [/src/main/schema/oih-data-record.json](../src/main/schema/oih-data-record.json)). + +* __Every sub-model of an OMDM must reference the OIHDataRecord schema and "inherit" from the defined type.__ + +This is done by adding an `allOf`-element to every sub-model's schema: + +```javascript +{ + "$schema": "http://json-schema.org/schema#", + "$id": "http://example.com/schemas/oih/my-model.json", + "title": "MySubmodelAggregate", + "allOf": [ + { + "$ref": "http://openintegrationhub.org/schemas/oih-data-record.json" + } + ], + "properties": { + ... +``` + +## 5. Example: the Order aggregate + +For a sales application, one could split the data model at least into the following sub-models, each of which built as an aggregate: + +* Order +* Address +* Article +* ... + +As an example to model an aggregate capable of being processed of an OIH instance, the following diagram shows a simplified order with its line items: + +![Aggregate example: Order](Assets/AggregateExample.svg) + +The Order's root defines the model as an OIH Data Record by extending it. This way, the _Order_ entity is the one and only entry point to the aggregate. + +The JSON schema for this example is accessible under [/src/examples/schema/order.json](../src/examples/schema/order.json). + +## 6. Rules and Regulations for OMDMs provided by the OIH community + +The OIH is an open-source platform maintained by the cloud community under the leadership of the [Cloud Ecosystem](http://www.cloudecosystem.org). It can be run with any model which is designed and implemented by the rules and regulations listed so far. + +In addition to the OIH platform itself, the OIH community also provides and maintains a number of concrete Master Data Models to be used by any OIH instance, such as models for contacts/addresses or products. + +For these models, there are some further rules and regulations to follow in order to be presented in a unified way. This helps to understand and, above all, use them (i.e., implementing OIH Connectors for applications to be integrated with - respectively via - an OIH). + +### 6.1 Naming Conventions + +#### 6.1.1 Types and Properties + +* __All type and property naming has to be in CamelCase:__ + * Type names are always spelled in _upper_ camel case (e.g., UpperCamelCaseType). + * Property names are always spelled in _lower_ camel case (e.g., lowerCamelCaseProperty). +* __All type and property naming has to be done in English language.__ +* __The prefixes _OIH_ and *OIH_* (or _oih_ and *oih_* for properties) are reserved for types and properties of OIH related Types and fields and may not be used for definitions in concrete models.__ + +#### 6.1.2 JSON-Schema + +* __Schema file names are always lowercase__. +* __As a seperator within file names a hyphen (-) may be used__ (e.g. _some-schema.json_). +* __The schema-ID (the _$id_ property in a JSON-Schema) is always structured as follows:__ + * The global context is _http://openintegrationhub.org/schemas/_ + * followed by a context directory and the name of the schema file (including the _.json_ suffix) + + Example: ```"$id": "http://openintegrationhub.org/schemas/products/product.json"``` +* __Every field in a JSON-Schema must have a _description_ property__, as long as it's (even potentially) not self-explanatory. + +### 6.2 UML Class Diagrams + +* __Every OMDM must be depicted by one or more UML Class Diagrams__, which illustrate the static aspect of the model. I.e., amongst others: + * of which different OIH Data Records and entities (types) the OMDM constists, + * how every OIH Data Record itself is composed, + * how the OIH Data Records are related to each other, + * which properties every entity (type) has. +* __Every OIH Data Record is defined by a Generalization relation__ (_OIHDataRecord_ is modelled as the superclass of the respective sub-model, s. [5. Example: the Order aggregate](#5-example-the-order-aggregate)). +* __Property types may, but must not be declared__ in the diagrams as the main purpose of these diagrams is to clarify the structure of an OMDM. + +### 6.3 Clarify all further aspects of a model with diagrams and/or textually + +Schemas and class diagrams only point out static aspects of a data model. Normally, there are further (e.g. dynamic) aspects of a model, that those descriptions do not point out (e.g. the conscious acceptance of redundancy). To enable ISVs and any other developers to understand and work with an OMDM, + +* __all relevant aspects of a model, that are not derivable from JSON-Schemas or UML Class Diagramms have to be described textually and by further illustrations of any kind.__ \ No newline at end of file diff --git a/MasterDataModel/Roadmap.md b/MasterDataModels/Roadmap.md similarity index 97% rename from MasterDataModel/Roadmap.md rename to MasterDataModels/Roadmap.md index 0ebfbec..10b8b58 100644 --- a/MasterDataModel/Roadmap.md +++ b/MasterDataModels/Roadmap.md @@ -5,7 +5,7 @@ The master data model will grow with each application (specific data model) that > The following steps describe a **hands on approach** which results in a master data model - at least the addresses part. Some statements need to be refined due to meetings with domain experts. _Some steps might be skipped in order to result in a master data model._ -**NOTE:** The conceptual approach follows the [MasterDataModelAdresses.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModel/MasterDataModelAdresses.md). All findings together should foster a robust master data model. +**NOTE:** The conceptual approach follows the [MasterDataModelAdresses.md](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/MasterDataModelAdresses.md). All findings together should foster a robust master data model. ## Identify generic address fields * Setup a test case where at least two data models (applications) become synced - **synchronously** diff --git a/MasterDataModel/SnazzyContactsAdapter/.gitignore b/MasterDataModels/SnazzyContactsAdapter/.gitignore similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/.gitignore rename to MasterDataModels/SnazzyContactsAdapter/.gitignore diff --git a/MasterDataModel/SnazzyContactsAdapter/README.md b/MasterDataModels/SnazzyContactsAdapter/README.md similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/README.md rename to MasterDataModels/SnazzyContactsAdapter/README.md diff --git a/MasterDataModel/SnazzyContactsAdapter/component.json b/MasterDataModels/SnazzyContactsAdapter/component.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/component.json rename to MasterDataModels/SnazzyContactsAdapter/component.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/actions/createOrganization.js b/MasterDataModels/SnazzyContactsAdapter/lib/actions/createOrganization.js similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/actions/createOrganization.js rename to MasterDataModels/SnazzyContactsAdapter/lib/actions/createOrganization.js diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/actions/createPerson.js b/MasterDataModels/SnazzyContactsAdapter/lib/actions/createPerson.js similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/actions/createPerson.js rename to MasterDataModels/SnazzyContactsAdapter/lib/actions/createPerson.js diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/actions/deleteOrganization.js b/MasterDataModels/SnazzyContactsAdapter/lib/actions/deleteOrganization.js similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/actions/deleteOrganization.js rename to MasterDataModels/SnazzyContactsAdapter/lib/actions/deleteOrganization.js diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/actions/deletePerson.js b/MasterDataModels/SnazzyContactsAdapter/lib/actions/deletePerson.js similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/actions/deletePerson.js rename to MasterDataModels/SnazzyContactsAdapter/lib/actions/deletePerson.js diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/actions/snazzy.js b/MasterDataModels/SnazzyContactsAdapter/lib/actions/snazzy.js similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/actions/snazzy.js rename to MasterDataModels/SnazzyContactsAdapter/lib/actions/snazzy.js diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/actions/updateOrganization.js b/MasterDataModels/SnazzyContactsAdapter/lib/actions/updateOrganization.js similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/actions/updateOrganization.js rename to MasterDataModels/SnazzyContactsAdapter/lib/actions/updateOrganization.js diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/actions/updatePerson.js b/MasterDataModels/SnazzyContactsAdapter/lib/actions/updatePerson.js similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/actions/updatePerson.js rename to MasterDataModels/SnazzyContactsAdapter/lib/actions/updatePerson.js diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/actions/updatePersonsOrganization.js b/MasterDataModels/SnazzyContactsAdapter/lib/actions/updatePersonsOrganization.js similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/actions/updatePersonsOrganization.js rename to MasterDataModels/SnazzyContactsAdapter/lib/actions/updatePersonsOrganization.js diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/createOrganization.in.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/createOrganization.in.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/createOrganization.in.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/createOrganization.in.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/createOrganization.out.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/createOrganization.out.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/createOrganization.out.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/createOrganization.out.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/createPerson.in.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/createPerson.in.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/createPerson.in.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/createPerson.in.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/createPerson.out.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/createPerson.out.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/createPerson.out.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/createPerson.out.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/deleteOrganization.in.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/deleteOrganization.in.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/deleteOrganization.in.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/deleteOrganization.in.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/deleteOrganization.out.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/deleteOrganization.out.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/deleteOrganization.out.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/deleteOrganization.out.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/deletePerson.in.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/deletePerson.in.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/deletePerson.in.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/deletePerson.in.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/deletePerson.out.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/deletePerson.out.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/deletePerson.out.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/deletePerson.out.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/getOrganizations.out.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/getOrganizations.out.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/getOrganizations.out.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/getOrganizations.out.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/getPersons.in.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/getPersons.in.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/getPersons.in.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/getPersons.in.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/getPersons.out.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/getPersons.out.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/getPersons.out.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/getPersons.out.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/updateOrganization.in.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/updateOrganization.in.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/updateOrganization.in.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/updateOrganization.in.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/updateOrganization.out.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/updateOrganization.out.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/updateOrganization.out.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/updateOrganization.out.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/updatePerson.in.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/updatePerson.in.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/updatePerson.in.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/updatePerson.in.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/updatePerson.out.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/updatePerson.out.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/updatePerson.out.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/updatePerson.out.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/updatePersonsOrganization.in.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/updatePersonsOrganization.in.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/updatePersonsOrganization.in.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/updatePersonsOrganization.in.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/schemas/updatePersonsOrganization.out.json b/MasterDataModels/SnazzyContactsAdapter/lib/schemas/updatePersonsOrganization.out.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/schemas/updatePersonsOrganization.out.json rename to MasterDataModels/SnazzyContactsAdapter/lib/schemas/updatePersonsOrganization.out.json diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/triggers/getOrganizationsPolling.js b/MasterDataModels/SnazzyContactsAdapter/lib/triggers/getOrganizationsPolling.js similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/triggers/getOrganizationsPolling.js rename to MasterDataModels/SnazzyContactsAdapter/lib/triggers/getOrganizationsPolling.js diff --git a/MasterDataModel/SnazzyContactsAdapter/lib/triggers/getPersonsPolling.js b/MasterDataModels/SnazzyContactsAdapter/lib/triggers/getPersonsPolling.js similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/lib/triggers/getPersonsPolling.js rename to MasterDataModels/SnazzyContactsAdapter/lib/triggers/getPersonsPolling.js diff --git a/MasterDataModel/SnazzyContactsAdapter/logo.png b/MasterDataModels/SnazzyContactsAdapter/logo.png similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/logo.png rename to MasterDataModels/SnazzyContactsAdapter/logo.png diff --git a/MasterDataModel/SnazzyContactsAdapter/package-lock.json b/MasterDataModels/SnazzyContactsAdapter/package-lock.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/package-lock.json rename to MasterDataModels/SnazzyContactsAdapter/package-lock.json diff --git a/MasterDataModel/SnazzyContactsAdapter/package.json b/MasterDataModels/SnazzyContactsAdapter/package.json similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/package.json rename to MasterDataModels/SnazzyContactsAdapter/package.json diff --git a/MasterDataModel/SnazzyContactsAdapter/verifyCredentials.js b/MasterDataModels/SnazzyContactsAdapter/verifyCredentials.js similarity index 100% rename from MasterDataModel/SnazzyContactsAdapter/verifyCredentials.js rename to MasterDataModels/SnazzyContactsAdapter/verifyCredentials.js diff --git a/MilestoneOne.md b/MilestoneOne.md index 3e299fa..314852d 100644 --- a/MilestoneOne.md +++ b/MilestoneOne.md @@ -1,29 +1,26 @@ # Milestone 1 -> Generic data model for addresses and products including regulations and decision processes. +> Generic data models for addresses and products including a superordinate model with regulations and decision processes. ## Generic data models ### Meta model -* [Data model](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/DataModels/DataModels.md) +* [Master Data Models (Definitions, Rules and Regulations)](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/README.md) * [Meta model](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/DataModels/MetaModel.md) ### Address model -* Generic data model as [UML class diagram for addresses](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModel/Assets/OIHDataModelAdressesUML.png) -* Generic data model as [JSON schema for addresses - organization](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModel/organization.json) -* Generic data model as [JSON schema for addresses - person](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModel/person.json) -* Generic data model as [JSON schema for addresses - relation](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModel/relation.json) +* Generic data model as [UML class diagram for addresses](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/Assets/OIHDataModelAdressesUML.png) +* Generic data model as [JSON schema for addresses - organization](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/addresses/organization.json) +* Generic data model as [JSON schema for addresses - person](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/addresses/person.json) +* Generic data model as [JSON schema for addresses - relation](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/addresses/relation.json) ### Product model -* Generic data model as [UML class diagram for products](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModel/Assets/OIHDataModelProductUML.svg) -* Generic data model as [JSON schema for products](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModel/Assets/OIHDataModelProductSchema.json) - -## Regulations -* General and specific [domain model regulations](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/DataModels/RulesandRegulations.md) +* Generic data model as [UML class diagram for products](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/Assets/OIHDataModelProducts.png) +* Generic data model as [JSON schema for products](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/src/main/schema/products/product.json) ## Decision processes -* Conceptual elaborations for [addresses](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModel/MasterDataModelAdresses.md) -* Conceptual elaborations for [products](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModel/MasterDataModelProducts.md) +* Conceptual elaborations for [addresses](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/MasterDataModelAdresses.md) +* Conceptual elaborations for [products](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/MasterDataModelProducts.md) \ No newline at end of file diff --git a/Protocols/2017-11-29Workshop.md b/Protocols/2017-11-29Workshop.md index 24ff644..42d7061 100644 --- a/Protocols/2017-11-29Workshop.md +++ b/Protocols/2017-11-29Workshop.md @@ -12,7 +12,7 @@ - Domain models are aggregates of a master data models - The core of the tree structure is the `OIH record` -- A detailed definition of the expression `generic model` is provided in the file about [MasterDataModelAdresses](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModel/MasterDataModelAdresses.md#31-general-requirements): +- A detailed definition of the expression `generic model` is provided in the file about [MasterDataModelAdresses](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/MasterDataModelAdresses.md#31-general-requirements): "In this specific field of investigation, the master data model for addresses describes a generic standard of customer data for the management of addresses. diff --git a/Protocols/2017-12-11Telko.md b/Protocols/2017-12-11Telko.md index 84d6c66..fe06524 100644 --- a/Protocols/2017-12-11Telko.md +++ b/Protocols/2017-12-11Telko.md @@ -34,7 +34,7 @@ Suggested structure/model see: [OIHDataModels](https://github.com/openintegratio - Josefs' results are currently in a textual form because of the missing UML modeling tool. The existing results can easily be transferred into an UML diagram. - The results are not the final model but a first draft - The results will be published on GitHub to provide insights for all project members -- Hansjörg expanded the [MasterDataModelAdresses](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModel/MasterDataModelAdresses.md#423-person-specific-requirements) by chapter 4.2.3 +- Hansjörg expanded the [MasterDataModelAdresses](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/MasterDataModelAdresses.md#423-person-specific-requirements) by chapter 4.2.3 - Missing: Privacy- and digital rights management - A vizual representation such as the one by YQ can be derived from the existing MasterDataModelAdresses file diff --git a/Protocols/2017-12-15WorkgroupTelko.md b/Protocols/2017-12-15WorkgroupTelko.md index b5bb3ab..ddb0c13 100644 --- a/Protocols/2017-12-15WorkgroupTelko.md +++ b/Protocols/2017-12-15WorkgroupTelko.md @@ -18,7 +18,7 @@ - Provided a [Data Model](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/DataModels/DataModels.md) which includes the description of the OIH datasets. ### Hansjörg -- Provided a [UML diagram](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModel/Assets/OIHDataModelAdressesUML.png) on basis of the previous elaborations and the provided by Lutz. +- Provided a [UML diagram](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/Assets/OIHDataModelAdressesUML.png) on basis of the previous elaborations and the provided by Lutz. - Lutz: Field (String, enumartion etc.) so specify the sort of the address. - Lutz: The Fields like _street_, _streetNumber_, _unit_, etc. can be modeled as attributes within the addresses - The idea behind the object `relations` shall be generic diff --git a/Protocols/2017-12-19WorkgroupTelko.md b/Protocols/2017-12-19WorkgroupTelko.md index aa57d00..7b6deca 100644 --- a/Protocols/2017-12-19WorkgroupTelko.md +++ b/Protocols/2017-12-19WorkgroupTelko.md @@ -26,7 +26,7 @@ ### Hansjörg - [x] Generic data model addresses in the shape of an UML class diagram (attached) **by @hschmidthh till 19.12.17** * Write down concrete attributes and update UML diagram **by @hschmidt till 15.12.2017** - - [UML diagram](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModel/Assets/OIHDataModelAdressesUML.png) Lutz: Field (String, enumeration etc.) to specify the sort of the address. + - [UML diagram](https://github.com/openintegrationhub/Data-and-Domain-Models/blob/master/MasterDataModels/Assets/OIHDataModelAdressesUML.png) Lutz: Field (String, enumeration etc.) to specify the sort of the address. - [x] Specific regulations for the generic data model addresses **by @hschmidthh till 19.12.17** - [ ] Generic data model addresses in the shape of a JSON schema **by @hschmidthh till late 19.12.17**