dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:data_object
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:data_object [2021/06/15 11:08] nick |
dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:data_object [2022/02/09 05:19] (current) nick |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| - | A **Data Object (DO)** is a collection of one or more pieces of data that when aggregated together impart meaning to the whole. In other words, **Data Object** is an alternate way of saying “this group of data should be considered as one piece of data.” | + | A **[[dido:public:ra:xapend:xapend.a_glossary:d:data_object|Data Object (DO)]]** is a collection of one or more pieces of data that when aggregated together impart meaning to the whole. In other words, **Data Object** is an alternate way of saying “this group of data should be considered as one piece of data.” |
| - | A common example of DOs are data tables where each row represents one Data Object and the columns represent the pieces of data that comprise the object. Some other examples of DOs include arrays, structures, collection of other Data Objects, and scalar types (i.e., not the value but rather the type). | + | A common example of DOs are data tables where each row represents one Data Object and the columns represent the pieces of data that comprise the [[dido:public:ra:xapend:xapend.a_glossary:o:object|object]]. Some other examples of DOs include arrays, structures, collection of other Data Objects, and scalar types (i.e., not the value but rather the type). |
| <figure> | <figure> | ||
| Line 12: | Line 12: | ||
| </figure> | </figure> | ||
| - | Another way to conceptualize a “data object” is as a way of compartmentalizing information into smaller, reusable pieces that are easier to understand and analyze with [[dido:public:ra:xapend:xapend.a_glossary:s:sme | Subject Matter Experts (SMEs) ]] usually being responsible for the definitions. It is a good idea to model Data Objects as concepts in [[dido:public:ra:xapend:xapend.a_glossary:u:uml]] or [[dido:public:ra:xapend:xapend.b_stds:tech:omg:sysml | System Modeling Language (SysML)]]. | + | Another way to conceptualize a “data object” is as a way of compartmentalizing information into smaller, reusable pieces that are easier to understand and analyze with [[dido:public:ra:xapend:xapend.a_glossary:s:sme | Subject Matter Experts (SMEs) ]] usually being responsible for the definitions. It is a good idea to model Data Objects as concepts in [[dido:public:ra:xapend:xapend.b_stds:tech:omg:uml | Unified Modeling Language (UML)]] or [[dido:public:ra:xapend:xapend.b_stds:tech:omg:sysml | System Modeling Language (SysML)]]. |
| ===== Different Datastore Architectures ===== | ===== Different Datastore Architectures ===== | ||
| [[dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:data_object | Return to Top ]] | [[dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:data_object | Return to Top ]] | ||
| - | Data Objects are stored in memory or permanent storage using any number of architectures. In addition, regardless of how a Data Object is stored in Memory or on permanent storage, while in transit the data may use a different architecture. For example, a [[dido:public:ra:xapend:xapend.a_glossary:r:rdbms]] may be transmitted over the wired using a set of key-value pairs such as [[dido:public:ra:xapend:xapend.a_glossary:j:json | JSON]]. | + | Data Objects are stored in memory or permanent storage using any number of architectures. In addition, regardless of how a Data Object is stored in Memory or on permanent storage, while in transit the data may use a different architecture. For example, a [[dido:public:ra:xapend:xapend.a_glossary:r:rdbms]] may be transmitted over the wired using a set of [[dido:public:ra:xapend:xapend.a_glossary:k:key|key]]-value pairs such as [[dido:public:ra:xapend:xapend.a_glossary:j:json | JSON]]. |
| There is no single internal organization of a Data Object and it depends on the implementor of the Data Object to select and use the models that work best for the intended purpose of the Data Object. Some common models described by Grant(( | There is no single internal organization of a Data Object and it depends on the implementor of the Data Object to select and use the models that work best for the intended purpose of the Data Object. Some common models described by Grant(( | ||
| Line 38: | Line 38: | ||
| <html> | <html> | ||
| <dt>Relational datastores</dt> | <dt>Relational datastores</dt> | ||
| - | <dd>Relational datastores are tabular in that they store data in tables with rows and columns. The tables are interconnected through columns shared in common between tables. In the above image, the arrows show the columns that connect the data in various tables. SQL Datastores are particularly well suited for systems dealing with transactions, such as customer relations management tools and accounting software. They are not, however, structured in such a manner as to "play well" with object-oriented programming languages, necessitating object-relational mapping tools. (See Grant) | + | <dd>Relational datastores are tabular in that they store data in tables with rows and columns. The tables are interconnected through columns shared in common between tables. In the above image, the arrows show the columns that connect the data in various tables. SQL Datastores are particularly well suited for systems dealing with transactions, such as customer relations management tools and accounting software. They are not, however, structured in such a manner as to "play well" with [[dido:public:ra:xapend:xapend.a_glossary:o:oop|object-oriented programming]] languages, necessitating object-relational mapping tools. (See Grant) |
| </dd> | </dd> | ||
| </html> | </html> | ||
| Line 47: | Line 47: | ||
| [[dido:public:ra:xapend:xapend.a_glossary:n:nosql]] Datastores, as the name implies, generally do not rely on SQL, though some may use SQL-like languages. Some, in fact, say NoSQL stands for "Not only SQL." NoSQL Datastores are generally less structured, more diverse, and newer overall than their SQL counterparts. Some common examples are listed below. (See Grant) | [[dido:public:ra:xapend:xapend.a_glossary:n:nosql]] Datastores, as the name implies, generally do not rely on SQL, though some may use SQL-like languages. Some, in fact, say NoSQL stands for "Not only SQL." NoSQL Datastores are generally less structured, more diverse, and newer overall than their SQL counterparts. Some common examples are listed below. (See Grant) | ||
| - | <html> | + | ^ Wide Column | Wide Column Stores are similar to SQL Datastores in that they use tables of rows and columns (i.e., [[ dido:public:ra:xapend:xapend.a_glossary:d:dm | Data Model ]]). The columns, however, can change with each row, creating a 2-dimensional effect.(See Grant) | |
| - | <dt>Wide Column Data Model</dt> | + | ^ Key-Value | Key-Value Datastores are essentially hash tables, both of which can be compared to a dictionary, in which one key (a word entry) corresponds to many underlying fields of information. The underlying fields for the keys in Key-Value Datastores can vary from key to key, lending the system a great deal of flexibility in the data it can store. The key-value-pair system matches well with object-oriented programming, and since a key's values are not predetermined with placeholders as in a table, Datastores of this type perform very well in certain circumstances.(See Grant)| |
| - | <dd>Wide Column Stores are similar to SQL Datastores in that they use tables of rows and columns. The columns, however, can change with each row, creating a 2-dimensional effect.(See Grant) | + | ^ Graph Data Model | Graph Datastores are suited for data that is highly interconnected, because of the "relationships" (also known as "edges") it maintains between nodes. As a result, complex data lookup can perform very highly because of the existing connections between data. Since SQL Datastores implicitly compare tables of highly ordered data, SQL is poorly suited to the nature of Graphs, in which the relationships are a concrete part of the [[dido:public:ra:xapend:xapend.a_glossary:d:datastructure|data structure]]. Graphs, in fact, do not have a standardized language, and usually rely on a proprietary system.(See Grant) | |
| - | </dd> | + | ^ Document Data Model | Document-Oriented Datastores are one of the most prominent types of non-relational Datastores and are actually a variety of Key-Value Datastores. They differ mainly in the way the Datastores engine processes the data, rather than their structure. Documents are very closely related to objects in [[dido:public:ra:xapend:xapend.a_glossary:p:programlang|programming languages]], and documents are very flexible. They can have any number of fields and fields can vary between documents. Documents themselves each have a unique key used to retrieve the documents themselves, and the keys often have an index to hasten lookup. (See Grant) | |
| - | <dt>Key-Value</dt><dd>Key-Value Datastores are essentially hash tables, both of which can be compared to a dictionary, in which one key (a word entry) corresponds to many underlying fields of information. The underlying fields for the keys in Key-Value Datastores can vary from key to key, lending the system a great deal of flexibility in the data it can store. The key-value-pair system matches well with object-oriented programming, and since a key's values are not predetermined with placeholders as in a table, Datastores of this type perform very well in certain circumstances.(See Grant)</dd> | + | |
| - | + | ||
| - | <dt>Graph Data Model</dt> | + | |
| - | <dd>Graph Datastores are suited for data that is highly interconnected, because of the "relationships" (also known as "edges") it maintains between nodes. As a result, complex data lookup can perform very highly because of the existing connections between data. Since SQL Datastores implicitly compare tables of highly ordered data, SQL is poorly suited to the nature of Graphs, in which the relationships are a concrete part of the data structure. Graphs, in fact, do not have a standardized language, and usually rely on a proprietary system.(See Grant) | + | |
| - | </dd> | + | |
| - | + | ||
| - | <dt>Document Data Model</dt> | + | |
| - | <dd>Document-Oriented Datastores are one of the most prominent types of non-relational Datastores and are actually a variety of Key-Value Datastores. They differ mainly in the way the Datastores engine processes the data, rather than their structure. Documents are very closely related to objects in programming languages, and documents are very flexible. They can have any number of fields and fields can vary between documents. Documents themselves each have a unique key used to retrieve the documents themselves, and the keys often have an index to hasten lookup. (See Grant) | + | |
| - | </dd> | + | |
| - | + | ||
| - | </html> | + | |
| ===== DIDO Data Object Datastores ===== | ===== DIDO Data Object Datastores ===== | ||
| [[dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:data_object | Return to Top ]] | [[dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:data_object | Return to Top ]] | ||
| - | The mechanism used to store a Data Object in a properly architected, designed, and implement DIDO should not be of concern to the user of the DIDO. Those details should be abstracted from the DIDO user encapsulation and the use of APIs. However, how the data is transmitted from within the DIDO to the outside is of importance. The current DIDO industry trend is to use **Key-Value** pairs where the **Value** is another Data Object or a primitive datatype (i.e., atom). This allows the data to be transmitted relatively efficiently (still as text); be human-readable; flexible and dynamic in nature. Many modern programming languages require little to no processing by the programmers to access the Key-Value pairs in the data. For example, Javascript inherently constructs [[dido:public:ra:xapend:xapend.a_glossary:j:json]] Objects for transmission or more permanent storage and allows the objects to be easily realized when they are received in transmission or read from storage. | + | The mechanism used to store a Data Object in a properly architected, designed, and implement DIDO should not be of concern to the user of the DIDO. Those details should be abstracted from the DIDO user encapsulation and the use of APIs. However, how the data is transmitted from within the DIDO to the outside is of importance. The current DIDO industry trend is to use **Key-Value** pairs where the **Value** is another Data Object or a primitive [[dido:public:ra:xapend:xapend.a_glossary:d:data_type]] (i.e., atom). This allows the data to be transmitted relatively efficiently (still as text); be human-readable; flexible and dynamic in nature. Many modern programming languages require little to no processing by the programmers to access the Key-Value pairs in the data. For example, [[dido:public:ra:xapend:xapend.a_glossary:j:javascript|Javascript]] inherently constructs [[dido:public:ra:xapend:xapend.a_glossary:j:json]] Objects for transmission or more permanent storage and allows the objects to be easily realized when they are received in transmission or read from storage. |
| <figure> | <figure> | ||
| {{ :dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:screen_shot_2021-05-23_at_10.57.02_am.png?600 |}} | {{ :dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:screen_shot_2021-05-23_at_10.57.02_am.png?600 |}} | ||
| - | <caption>Data in Motion often uses JSON</caption> | + | <caption>[[dido:public:ra:xapend:xapend.a_glossary:d:data_in_motion|Data in Motion]] often uses JSON</caption> |
| </figure> | </figure> | ||
| Originally, [[dido:public:ra:xapend:xapend.a_glossary:x:xml]] was used to accomplish the same thing as JSON, but XML required more data to represent the same information and the manipulation of the XML Documents was not as "natural" or as "native" to the programmers as the recreated objects from JSON. | Originally, [[dido:public:ra:xapend:xapend.a_glossary:x:xml]] was used to accomplish the same thing as JSON, but XML required more data to represent the same information and the manipulation of the XML Documents was not as "natural" or as "native" to the programmers as the recreated objects from JSON. | ||
| - | Many programming languages (i.e., PHP, Java, C#, C++, Rust, Solidity, etc) and frameworks have adopted JSON as a standard way to transmit and receive data. This makes [[dido:public:ra:1.4_req:2_nonfunc:05_interoperability | Interoperability]] and integration easier since both ends of the "pipe" can be written in languages that are best suited for the task at hand. | + | Many programming languages (i.e., PHP, Java, C#, C++, Rust, Solidity, etc) and frameworks have adopted JSON as a standard way to transmit and receive data. This makes [[dido:public:ra:1.4_req:2_nonfunc:05_interoperability | Interoperability]] and integration easier, since both ends of the "pipe" can be written in languages that are best suited for the task at hand. |
| ===== DIDO Data Objects in Relational Database ===== | ===== DIDO Data Objects in Relational Database ===== | ||
| [[dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:data_object | Return to Top ]] | [[dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:data_object | Return to Top ]] | ||
| - | //Keep in mind, Ethereum is the database, smart contracts are the data tables, and transactions from wallets are the rows in each table.//(( | + | //Keep in mind, [[dido:public:ra:xapend:xapend.a_glossary:e:ethereum|Ethereum]] is the database, smart contracts are the data tables, and transactions from wallets are the rows in each table.//(( |
| Andrew Hong, | Andrew Hong, | ||
| Hands-On Tutorials, | Hands-On Tutorials, | ||
| Line 88: | Line 77: | ||
| [[https://towardsdatascience.com/your-guide-to-basic-sql-while-learning-ethereum-at-the-same-time-9eac17a05929]] | [[https://towardsdatascience.com/your-guide-to-basic-sql-while-learning-ethereum-at-the-same-time-9eac17a05929]] | ||
| )) | )) | ||
| + | |||
| + | <figure> | ||
| + | {{ :dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:screen_shot_2021-06-15_at_10.17.46_am.png?500 |}} | ||
| + | <caption></caption> | ||
| + | </figure> | ||
dido/public/s_cli/05_contents/01_prt/02_basics/01_commondef/data_object.1623769698.txt.gz · Last modified: 2021/06/15 11:08 by nick
