{"_id":"551469918ad90b1700b32fc0","project":"55078477fa89210d00c8ca23","user":"5507846643d3400d0052fd09","githubsync":"","category":{"_id":"5509d0dbe463aa3d000dd352","pages":["5509d0dbe463aa3d000dd354","5509d0dbe463aa3d000dd355","5509d0dbe463aa3d000dd356","5509d0dbe463aa3d000dd357","5509d0dbe463aa3d000dd358","5509e8a9e463aa3d000dd3a6","5509e9fbbc9cc21900200f48","5509f7fae463aa3d000dd3e0","550b2788635c660d00528295","550c0ce1f23ffc230037b96b","550c1b67f23ffc230037b980","550c2308351eeb19006b16c0","550de8078387ac0d00ed9d8f","550deb606c0b4c0d00fd4382","551052834980621900063311","5514436ae0e4bf1900378d05","551469918ad90b1700b32fc0","552924f7d739240d00a347bd"],"version":"5509d0dae463aa3d000dd351","__v":14,"project":"55078477fa89210d00c8ca23","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-03-17T01:33:44.491Z","from_sync":false,"order":0,"slug":"documentation","title":"Documentation"},"version":{"_id":"5509d0dae463aa3d000dd351","forked_from":"55078478fa89210d00c8ca26","project":"55078477fa89210d00c8ca23","__v":5,"createdAt":"2015-03-18T19:24:10.735Z","releaseDate":"2015-03-18T19:24:10.735Z","categories":["5509d0dbe463aa3d000dd352","5509d0dbe463aa3d000dd353","5509d1664c7c3f2300aac023","550c237bf23ffc230037b98c","55192997822f9c23006e9571","55192a8f337285170047f867"],"is_deprecated":false,"is_hidden":false,"is_beta":true,"is_stable":true,"codename":"","version_clean":"0.9.0","version":"0.9"},"__v":0,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-03-26T20:18:25.550Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"auth":"required","params":[],"url":""},"isReference":false,"order":1,"body":"Origins merges the concepts of an [entity-attribute-value (EAV)](https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model) data model and a [bi-temporal](https://en.wikipedia.org/wiki/Temporal_database#Bitemporal_relations) model to form the basis of its [Information Model](doc:information-model).\n\nThe EAV model is a flexible, denormalized data model which enables virtually any kind of data to be represented. This level of flexibility enables modeling attributes and values as entities themselves for describing [domain models](https://en.wikipedia.org/wiki/Domain_model). A domain model describes the concepts and semantics of a data represented in that domain, like a schema or data dictionary.\n\nMost databases can be referred to as [place-oriented systems](http://www.infoq.com/presentations/Value-Values). These systems only maintain the current state of the data and do so by updating values *in-place*. When an update (or delete) like this occurs, the prior data is gone and cannot be accessed again. Many database systems do maintain some kind of [historical log](https://en.wikipedia.org/wiki/Write-ahead_logging) to recover from crashes, but this data is buried and not accessible to end users.\n\nThe set of [use cases](#use-cases) that Origins targets share a set of observed qualities:\n\n- Data can be logically grouped in domains based on the observed workflows\n- Many data depend on data in other domains (i.e. relationships)\n- Domain maintainers operate [concurrently](https://en.wikipedia.org/wiki/Concurrent_computing)\n\nThe implication of concurrency and point of contention for dependent domains is [coordination](https://en.wikipedia.org/wiki/Coordination). Coordination is **hard** and exponentially so as the number of dependencies increase.\n\nOrigins handles this challenge by providing tools for correcting dependency conflicts. This is made possible by comparing information before and after dependency changes occur. Domain maintainers can evaluate the outcome of this change and respond accordingly. Exposing time provides transparency as domains evolve, but more importantly is the basis for establishing trust with users of the data.\n\n- Check out the [FAQ](doc:faq) for common questions.\n- For a deeper dive into the design, read about the [Information Model](doc:information-model).\n- Are you interested in this project? See how you can [get involved](doc:contributing) (not just for developers!)","excerpt":"Overview of the design motivations for Origins.","slug":"design","type":"basic","title":"Design"}

Design

Overview of the design motivations for Origins.

Origins merges the concepts of an [entity-attribute-value (EAV)](https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model) data model and a [bi-temporal](https://en.wikipedia.org/wiki/Temporal_database#Bitemporal_relations) model to form the basis of its [Information Model](doc:information-model). The EAV model is a flexible, denormalized data model which enables virtually any kind of data to be represented. This level of flexibility enables modeling attributes and values as entities themselves for describing [domain models](https://en.wikipedia.org/wiki/Domain_model). A domain model describes the concepts and semantics of a data represented in that domain, like a schema or data dictionary. Most databases can be referred to as [place-oriented systems](http://www.infoq.com/presentations/Value-Values). These systems only maintain the current state of the data and do so by updating values *in-place*. When an update (or delete) like this occurs, the prior data is gone and cannot be accessed again. Many database systems do maintain some kind of [historical log](https://en.wikipedia.org/wiki/Write-ahead_logging) to recover from crashes, but this data is buried and not accessible to end users. The set of [use cases](#use-cases) that Origins targets share a set of observed qualities: - Data can be logically grouped in domains based on the observed workflows - Many data depend on data in other domains (i.e. relationships) - Domain maintainers operate [concurrently](https://en.wikipedia.org/wiki/Concurrent_computing) The implication of concurrency and point of contention for dependent domains is [coordination](https://en.wikipedia.org/wiki/Coordination). Coordination is **hard** and exponentially so as the number of dependencies increase. Origins handles this challenge by providing tools for correcting dependency conflicts. This is made possible by comparing information before and after dependency changes occur. Domain maintainers can evaluate the outcome of this change and respond accordingly. Exposing time provides transparency as domains evolve, but more importantly is the basis for establishing trust with users of the data. - Check out the [FAQ](doc:faq) for common questions. - For a deeper dive into the design, read about the [Information Model](doc:information-model). - Are you interested in this project? See how you can [get involved](doc:contributing) (not just for developers!)