1888 lines
No EOL
94 KiB
HTML
1888 lines
No EOL
94 KiB
HTML
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" xml:lang="en-US">
|
||
<head>
|
||
<title>Designing and Building Enterprise Knowledge Graphs</title>
|
||
<link href="../styles/stylesheet.css" rel="stylesheet" type="text/css"/>
|
||
<link href="../styles/page-template.xpgt" rel="stylesheet" type="application/vnd.adobe-page-template+xml"/>
|
||
<meta content="urn:uuid:81982e4f-53b2-476f-ab11-79954b0aab3c" name="Adept.expected.resource"/>
|
||
</head>
|
||
<body epub:type="bodymatter">
|
||
<section epub:type="chapter">
|
||
<h1 class="chno" epub:type="title"><span epub:type="pagebreak" id="page_45" title="45"/>CHAPTER 3</h1>
|
||
<h1 class="chtitle" epub:type="title">Mapping Design Patterns</h1>
|
||
<p class="noindent">In software engineering, a design pattern is a general repeatable solution within a given context. A design pattern describes a template on how to solve a problem that can be reused in various situations. Design patterns are best practices to help solve common problems and speed up development processes.</p>
|
||
<p class="indent">Inspired by software design patterns, we present mapping design patterns, reusable mapping templates that solve a commonly occurring problem. Reusing mapping design patterns can help prevent subtle issues that may cause problems down the line and improve readability of the mappings by other developers. It is important to note that this is not an exhaustive list of mapping design patterns.</p>
|
||
<p class="indent">These mapping patterns provide a playbook to (1) map relational databases to Concepts, Attributes, and Relationships of the knowledge graph and (2) define the identifiers of the entities in the knowledge graph.</p>
|
||
<p class="indent">The first type of custom mappings are <b>direct custom mappings. A</b> custom mapping is direct if there is a 1:1 correspondence between the following:</p>
|
||
<div class="lf5">
|
||
<table class="tablen" id="tab_1">
|
||
<thead>
|
||
<tr>
|
||
<th class="thead tc"><b>Relational Database</b></th>
|
||
<th class="thead tc"><b>Knowledge Graph</b></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">Table</td>
|
||
<td class="tab1 tc">Concept</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">Column</td>
|
||
<td class="tab1 tc">(Concept/Relationship) Attribute</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">Foreign Key</td>
|
||
<td class="tab1 tc">Relationship</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="indent">The direct custom mappings are direct mappings with the ability to custom define the target, instead of creating the knowledge graph schema based on the source relational schema.</p>
|
||
<p class="indent">A second type of custom mappings are <b>complex custom mappings.</b> A custom mapping is complex if an arbitrary SQL query is required.</p>
|
||
<p class="indent">The rest of the chapter presents a series of mapping design patterns.</p>
|
||
<section>
|
||
<h2 class="head2" id="ch3_1">3.1<span class="space3"/><span epub:type="title">DIRECT CUSTOM MAPPING PATTERNS</span></h2>
|
||
<section>
|
||
<h3 class="head3" id="ch3_1_1">3.1.1<span class="space3"/><span epub:type="title">DIRECT CONCEPT</span></h3>
|
||
<p class="noindent"><b>Context:</b> A table in the relational database represents a concept in the knowledge graph. This means that every single row of the table, which is uniquely identified by the primary key column(s) represents an instance of a concept. Therefore, the direct concept mapping is from the table to a concept.</p>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_46" title="46"/><b>Solution:</b> The table and the corresponding primary key are mapped to a concept</p>
|
||
<figure>
|
||
<div class="image" id="fig_1"><img alt="Image" src="../images/pg46_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">where <span class="underline"><code>ID</code></span> is the primary key column of the table TABLE.</p>
|
||
<p class="exe"><b>Example 3.1</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order</code> table stores all the order transactions.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_2">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="2"><code>sales_flat_order</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>grand_total</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">110</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">100</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> In the knowledge graph, the schema consists of the concept <i>Order.</i></p>
|
||
<div class="box-top">
|
||
<p class="center"><i>(Order)</i></p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —type→ (Order)</p>
|
||
<p class="center">(order-2) —type→ (Order)</p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i></p>
|
||
<figure>
|
||
<div class="image" id="fig_2"><img alt="Image" src="../images/pg46_2.jpg"/></div>
|
||
</figure>
|
||
<p class="indent">This example is visually represented in <a href="#fig3_1">Figure <span class="blue">3.1</span></a>.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_1_2">3.1.2<span class="space3"/><span epub:type="title">DIRECT CONCEPT ATTRIBUTE</span></h3>
|
||
<p class="noindent"><b>Context: A</b> table in the relational database represents a concept in the knowledge graph and a column of that table represents an attribute associated with the concept in the knowledge graph. This means that every single row of the table, which is uniquely identified by the primary key column(s) of that table, represents an instance of representative Concept and the given column of that table represents the attribute associated with the Concept. Therefore, the direct concept attribute mapping is from a column in a table to a concept attribute (and there is also a direct concept mapping from the table to the concept).</p>
|
||
<p class="noindentt"><b>Solution:</b> The table and the corresponding primary key is mapped to a concept <span epub:type="pagebreak" id="page_47" title="47"/>where <span class="underline"><code>ID</code></span> is the primary key column of the table TABLE.</p>
|
||
<figure>
|
||
<div class="image" id="fig3_1"><img alt="Image" src="../images/fig3_1.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.1:</span> Direct concept mapping example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_3"><img alt="Image" src="../images/pg47_1.jpg"/></div>
|
||
</figure>
|
||
<p class="exe"><b>Example 3.2</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order</code> table stores all the order transactions.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_3">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="2"><code>sales_flat_order</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>order_currency_code</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">USD</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">EUR</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concept <i>Order</i> and an associated attribute <i>Currency</i> whose datatype is a string:</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order) —currency→ <code>[string]</code></p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —currency→ <code>[USD]</code></p>
|
||
<p class="center">(order-2) —currency→ <code>[EUR]</code></p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> The direct concept attribute mapping is from the column <code>order_currency_code</code> from the table <code>sales_flat_order</code> to the concept attribute <i>Currency.</i> The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig3_2"><img alt="Image" src="../images/fig3_2.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.2:</span> Direct concept attribute mapping example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_4"><img alt="Image" src="../images/pg48_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_48" title="48"/>This example is visually represented in <a href="#fig3_2">Figure 3.2</a>.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_1_3">3.1.3<span class="space3"/><span epub:type="title">DIRECT RELATIONSHIP</span></h3>
|
||
<p class="noindent"><b>Context: A</b> foreign key attribute of a table represents a relationship in the knowledge graph. This means that every pair of primary key and foreign key attributes per row in the table represents an instance of the relationship between a Concept that is identified by the primary key and another Concept that is identified by the foreign key. Therefore, the direct relationship mapping is from a foreign key to a relationship.</p>
|
||
<p class="noindentt"><b>Solution:</b> The table with corresponding primary key and the column which is a foreign key is mapped to a relationship</p>
|
||
<figure>
|
||
<div class="image" id="fig_5"><img alt="Image" src="../images/pg48_2.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">where <span class="underline">PK</span> is the primary key column of the table TABLE and <span class="underline">FK</span> is a foreign key column that references another table.</p>
|
||
<p class="exe"><span epub:type="pagebreak" id="page_49" title="49"/><b>Example 3.3</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order</code> table stores all the order transactions. The column <code>entity_id</code> is the primary key. The column <code>customer_id</code> is a foreign key that references the <code>customer_entity</code> table and associates the customers to the orders.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_4">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="2"><code>sales_flat_order</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>customer_id</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">100</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">100</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concepts <i>Order</i> and <i>Customer.</i> The relationship <i>placed by</i> connects the <i>Order</i> concept to <i>Customer</i> concept.</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order) —placedBy→ (Customer)</p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —placedBy→ (Customer-100)</p>
|
||
<p class="center">(order-2) —placedBy→ (Customer-100)</p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> The direct relationship mapping is from the foreign key column <code>customer_id</code> from the table <code>sales_flat_order</code> to the relationship <i>placedBy.</i> The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig_6"><img alt="Image" src="../images/pg49_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_3">Figure <span class="blue">3.3</span></a>.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_1_4">3.1.4<span class="space3"/><span epub:type="title">DIRECT RELATIONSHIP ATTRIBUTE</span></h3>
|
||
<p class="noindent"><b>Context: A</b> foreign key attribute of a table represents a relationship in the knowledge graph. This means that every pair of primary key and foreign key attributes per row in the table represents an instance of the relationship between a Concept that is identified by the primary key and another Concept that is identified by the foreign key. Additionally, there is an additional column in the table that represents a relationship attribute. Therefore, the direct relationship attribute mapping is from a column that qualifies a foreign key to a relationship attribute.</p>
|
||
<p class="noindentt"><b>Solution:</b> The table with corresponding primary key and the column which is a foreign key is mapped to a relationship</p>
|
||
<figure>
|
||
<div class="image" id="fig_7"><img alt="Image" src="../images/pg49_2.jpg"/></div>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig3_3"><img alt="Image" src="../images/fig3_3.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.3:</span> Direct relationship mapping example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_50" title="50"/>where <span class="underline">PK</span> is the primary key column of the table TABLE and <span class="underline">FK</span> is a foreign key column that references another table.</p>
|
||
<p class="exe"><b>Example 3.4</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order</code> table stores all the order transactions. The column entity_id is the primary key. The column <code>customer_id</code> is a foreign key that references the <code>customer_entity</code> table and associates the customers to the orders. The column <code>created_at</code> represents the time that the customer started to create the order.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_5">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="3"><code>sales_flat_order</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>customer_id</b></code></th>
|
||
<th class="thead tc"><code><b>created_at</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">2021-01-01T09:00:00</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">2021-01-02T09:30:00</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concepts <i>Order</i> and <i>Customer.</i> The relationship <i>placedBy</i> connects the <i>Order</i> concept to <i>Customer</i> concept. The attribute <i>startTime</i> is associated to the <i>placedBy</i> relationship</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order1) —placedBy{startTime = [datetime]}→ (Customer)</p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order-1) —placedBy{startTime = [2021-01-01T09:00:00]}→ (Customer-100)</p>
|
||
<p class="center">(Order-2) —placedBy{startTime = [2021-01-02T09:30:00]}→ (Customer-100)</p>
|
||
</div>
|
||
<figure>
|
||
<div class="image" id="fig3_4"><img alt="Image" src="../images/fig3_4.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.4:</span> Direct relationship attribute example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_51" title="51"/><i>Mapping:</i> The direct relationship attribute mapping is from the column <code>created_at</code> from the table <code>sales_flat_order</code> to the relationship attribute <i>startTime</i> associated with the relationship <i>placedBy.</i> The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig_8"><img alt="Image" src="../images/pg51_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_4">Figure <span class="blue">3.4</span></a>.</p>
|
||
</section>
|
||
</section>
|
||
<section>
|
||
<h2 class="head2" id="ch3_2">3.2<span class="space3"/><span epub:type="title">COMPLEX CUSTOM CONCEPT MAPPING PATTERNS</span></h2>
|
||
<section>
|
||
<h3 class="head3" id="ch3_2_1">3.2.1<span class="space3"/><span epub:type="title">COMPLEX CONCEPT: CONDITIONS</span></h3>
|
||
<p class="noindent"><b>Context: A</b> subset of the rows in a table represents a concept in the knowledge graph.</p>
|
||
<p class="noindentt"><b>Solution:</b> Define a query needs to be defined that returns the specific rows through a condition that satisfies the definition of the concept</p>
|
||
<figure>
|
||
<div class="image" id="fig_9"><img alt="Image" src="../images/pg51_2.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_52" title="52"/>where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the table and is used to create an identifier TABLE.</p>
|
||
<p class="exe"><b>Example 3.5</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order</code> table stores all the order transactions. <code>The entity_id</code> uniquely identifies each order. However, if the transaction enters a bad state, the <code>entity_id</code> values are negative.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_6">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="2"><code>sales_flat_order</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>grand_total</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">-100</td>
|
||
<td class="tab1 tc">0</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">-101</td>
|
||
<td class="tab1 tc">0</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">110</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">100</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concept <i>Order.</i></p>
|
||
<div class="box-top">
|
||
<p class="center"><i>(Order)</i></p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —type→ (Order)</p>
|
||
<p class="center">(order-2) —type→ (Order)</p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i></p>
|
||
<figure>
|
||
<div class="image" id="fig_10"><img alt="Image" src="../images/pg52_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_5">Figure <span class="blue">3.5</span></a>.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_2_2">3.2.2<span class="space3"/><span epub:type="title">COMPLEX CONCEPT: DATA AS A CONCEPT</span></h3>
|
||
<p class="noindent"><b>Context:</b> A subset of the rows in a table, defined by an enumeration of values over a specific column, represents a concept in the knowledge graph.</p>
|
||
<p class="noindentt"><b>Solution:</b> Define a query that returns the specific rows through a condition on specific values of a column that satisfies the definition of the concept</p>
|
||
<figure>
|
||
<div class="image" id="fig_11"><img alt="Image" src="../images/pg52_2.jpg"/></div>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig3_5"><img alt="Image" src="../images/fig3_5.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.5:</span> Complex custom concept mapping: condition example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_53" title="53"/>where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the table and is used to create an identifier TABLE.</p>
|
||
<p class="exe"><b>Example 3.6</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order</code> table stores all the order transactions. The column <code>status</code> contains the status of the order, such as pending, complete, processing, etc.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_7">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="2"><code>sales_flat_order</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>status</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">pending</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">complete</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">3</td>
|
||
<td class="tab1 tc">processing</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concept <i>PendingOrder.</i></p>
|
||
<div class="box-top">
|
||
<p class="center"><i>(PendingOrder)</i></p>
|
||
</div>
|
||
<figure>
|
||
<div class="image" id="fig3_6"><img alt="Image" src="../images/fig3_6.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.6:</span> Complex custom concept mapping: data as a class example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_54" title="54"/>The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —type→ (PendingOrder)</p>
|
||
<p class="center">(order-3) —type→ (PendingOrder)</p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i></p>
|
||
<figure>
|
||
<div class="image" id="fig_12"><img alt="Image" src="../images/pg54_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_6">Figure <span class="blue">3.6</span></a>.</p>
|
||
<p class="noindentt"><b>Discussion:</b> Similar to the Conditions design pattern. In this case, the condition is specific to enumeration of values associated to a column.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_2_3"><span epub:type="pagebreak" id="page_55" title="55"/>3.2.3<span class="space3"/><span epub:type="title">COMPLEX CONCEPT: JOIN</span></h3>
|
||
<p class="noindent"><b>Context:</b> A concept in the knowledge graph spans multiple tables in the relational databases.</p>
|
||
<p class="noindentt"><b>Solution:</b> Define a query the joins the multiple tables</p>
|
||
<figure>
|
||
<div class="image" id="fig_13"><img alt="Image" src="../images/pg55_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query result and is used to create the identifier.</p>
|
||
<p class="exe"><b>Example 3.7</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order</code> table stores all the order transactions and <code>sales_flat_order_payment</code> stores all the orders that have payments processed. The column <code>entity_id</code> of the <code>sales_flat_order_payment</code> table is a foreign key that references <code>sales_flat_order</code>.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_8">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="2"><code>sales_flat_order</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>...</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc"/>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc"/>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">3</td>
|
||
<td class="tab1 tc"/>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">4</td>
|
||
<td class="tab1 tc"/>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_9">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="2"><code>sales_flat_order_payment</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>...</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc"/>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc"/>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">3</td>
|
||
<td class="tab1 tc"/>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concept <i>Order.</i></p>
|
||
<div class="box-top">
|
||
<p class="center"><i>(Order)</i></p>
|
||
</div>
|
||
<p class="noindent">The business defines an Order as order transactions that have a payment processed. Therefore, the expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —type→ (Order)</p>
|
||
<p class="center">(order-2) —type→ (Order)</p>
|
||
<p class="center">(order-3) —type→ (Order)</p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> The tables <code>sales_flat_order</code> and <code>sales_flat_order_payment</code> need to be joined and the result are mapped to the <i>Order</i> concept in the knowledge graph. The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig3_7"><img alt="Image" src="../images/fig3_7.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.7:</span> Complex custom concept mapping: join example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_14"><img alt="Image" src="../images/pg56_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_56" title="56"/>This example is visually represented in <a href="#fig3_7">Figure <span class="blue">3.7</span></a>.</p>
|
||
<p class="noindent"><b>Discussion: A</b> LEFT/RIGHT/OUTER JOIN are not considered because they would not constrain the original table. If that is the case, then no joins would be needed.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_2_4"><span epub:type="pagebreak" id="page_57" title="57"/>3.2.4<span class="space3"/><span epub:type="title">COMPLEX CONCEPT: DISTINCT</span></h3>
|
||
<p class="noindent"><b>Context: A</b> table represents more than one concept in the knowledge graph. For one of the concepts, the rows that represent the concepts appear duplicated in the table.</p>
|
||
<p class="noindentt"><b>Solution:</b> Define a query that returns the distinct rows that represents the concept, ideally with an attribute that serves as a key that uniquely identifies each distinct row that represents a concept</p>
|
||
<figure>
|
||
<div class="image" id="fig_15"><img alt="Image" src="../images/pg57_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query and is used to create an identifier for the concept.</p>
|
||
<p class="exe"><b>Example 3.8</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order</code> table stores all the order transactions. The column status contains the status of the order, such as pending, complete, processing, etc.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_10">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="4"><code>sales_flat_order</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>...</b></code></th>
|
||
<th class="thead tc"><code><b>customer_id</b></code></th>
|
||
<th class="thead tc"><code><b>first_name</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc"/>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">Juan</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc"/>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">Juan</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">3</td>
|
||
<td class="tab1 tc"/>
|
||
<td class="tab1 tc">101</td>
|
||
<td class="tab1 tc">Ora</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concept <i>Customer.</i></p>
|
||
<div class="box-top">
|
||
<p class="center"><i>(Customer)</i></p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(customer-100) —type→ (Customer)</p>
|
||
<p class="center">(customer-101) —type→ (Customer)</p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i></p>
|
||
<figure>
|
||
<div class="image" id="fig_16"><img alt="Image" src="../images/pg57_2.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_8">Figure <span class="blue">3.8</span></a>.</p>
|
||
<p class="noindentt"><b>Discussion:</b> This appears when a table is a denormalized view (i.e., multiple tables have been joined and values get repeated).</p>
|
||
<figure>
|
||
<div class="image" id="fig3_8"><img alt="Image" src="../images/fig3_8.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.8:</span> Complex custom concept mapping: distinct example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
</section>
|
||
</section>
|
||
<section>
|
||
<h2 class="head2" id="ch3_3"><span epub:type="pagebreak" id="page_58" title="58"/>3.3<span class="space3"/><span epub:type="title">COMPLEX CUSTOM ATTRIBUTE MAPPING PATTERNS</span></h2>
|
||
<p class="noindent">The following attribute mapping patterns can be applied to either Concepts or Relationships.</p>
|
||
<section>
|
||
<h3 class="head3" id="ch3_3_1">3.3.1<span class="space3"/><span epub:type="title">COMPLEX CONCEPT ATTRIBUTE: CONCAT</span></h3>
|
||
<p class="noindent"><b>Context:</b> Multiple columns need to be concatenated in order to represent the attribute.</p>
|
||
<p class="noindentt"><b>Solution:</b> Use the SQL CONCAT function</p>
|
||
<figure>
|
||
<div class="image" id="fig_17"><img alt="Image" src="../images/pg58_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for the attribute’s associated concept.</p>
|
||
<p class="exe"><span epub:type="pagebreak" id="page_59" title="59"/><b>Example 3.9</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>customer_entity</code> table stores all the customers. The customer names are stored by first name and last name.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_11">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="3"><code>customer_entity</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>first_name</b></code></th>
|
||
<th class="thead tc"><code><b>last_name</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">Juan</td>
|
||
<td class="tab1 tc">Sequeda</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">101</td>
|
||
<td class="tab1 tc">Ora</td>
|
||
<td class="tab1 tc">Lassila</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concept <i>Customer</i> and an associated attribute <i>name</i> which represents a full name, and whose datatype is a string.</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order) —currency→ [string]</p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(customer-100) —name→ [Juan Sequeda]</p>
|
||
<p class="center">(customer-101) —name→ [Ora Lassila]</p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> The columns <code>first_name</code> and <code>last_name</code> need to be concatenated with a space in between. The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig_18"><img alt="Image" src="../images/pg59_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_9">Figure <span class="blue">3.9</span></a>.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_3_2">3.3.2<span class="space3"/><span epub:type="title">COMPLEX CONCEPT ATTRIBUTE: MATH
|
||
</span></h3>
|
||
<p class="noindent"><b>Context:</b> Values in different columns need to be applied in a math formula in order to be mapped to an attribute.</p>
|
||
<p class="noindentt"><b>Solution:</b> Use the SQL arithmetic operators and math functions</p>
|
||
<figure>
|
||
<div class="image" id="fig_19"><img alt="Image" src="../images/pg59_2.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for the attribute’s associated concept.</p>
|
||
<p class="exe"><b>Example 3.10</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order</code> table stores all the order transactions.</p>
|
||
<figure>
|
||
<div class="image" id="fig3_9"><img alt="Image" src="../images/fig3_9.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.9:</span> Complex custom attribute mapping: CONCAT example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_12">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="4"><code>sales_flat_order</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>grand_total</b></code></th>
|
||
<th class="thead tc"><code><b>tax_amount</b></code></th>
|
||
<th class="thead tc"><code><b>discount_amount</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">110</td>
|
||
<td class="tab1 tc">8.8</td>
|
||
<td class="tab1 tc">1.2</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">10</td>
|
||
<td class="tab1 tc">0</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_60" title="60"/><i>Target:</i> The knowledge graph schema consists of the concept <i>Order</i> and an associated attribute <i>netsales</i> whose datatype is a float.</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order) —netsales→ <code>[float]</code></p>
|
||
</div>
|
||
<p class="noindent">The business defines <i>netsales</i> by taking the grand total and subtracting the tax and discount. Therefore, the expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —netsales→ <code>[100]</code></p>
|
||
<p class="center">(order-2) —netsales→ <code>[90]</code></p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> To generate the knowledge graph, the definition of <i>netsales</i> is represented in the SQL query. The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig3_10"><img alt="Image" src="../images/fig3_10.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.10:</span> Complex custom attribute mapping: math example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_20"><img alt="Image" src="../images/pg61_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_61" title="61"/>This example is visually represented in <a href="#fig3_10">Figure <span class="blue">3.10</span></a>.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_3_3">3.3.3<span class="space3"/><span epub:type="title">COMPLEX CONCEPT ATTRIBUTE: CASE</span></h3>
|
||
<p class="noindent"><b>Context:</b> Values in a column are codes and each code needs to be mapped to a certain constant.</p>
|
||
<p class="noindentt"><b>Solution:</b> Use the SQL CASE statement to represent the mapping to each fixed value. The entire case statement is mapped to the attribute</p>
|
||
<figure>
|
||
<div class="image" id="fig_21"><img alt="Image" src="../images/pg62_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_62" title="62"/>where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for the attribute’s associated concept.</p>
|
||
<p class="exe"><b>Example 3.11</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order</code> table stores all the order transactions. The column status contains the status of the order as code numbers: 10, 11, etc.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_13">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="3"><code>sales_flat_order</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>...</b></code></th>
|
||
<th class="thead tc"><code><b>status</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc"/>
|
||
<td class="tab1 tc">10</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc"/>
|
||
<td class="tab1 tc">11</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">3</td>
|
||
<td class="tab1 tc"/>
|
||
<td class="tab1 tc">10</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concept <i>Order</i> and an associated attribute <i>orderStatus</i> whose datatype is a string:</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order) —orderStatus→ [string]</p>
|
||
</div>
|
||
<p class="noindent">The order status 10 means Closed and 11 means Pending. The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —orderStatus→ <code>[Pending]</code></p>
|
||
<p class="center">(order-2) —orderStatus→ <code>[Closed]</code></p>
|
||
<p class="center">(order-3) —orderStatus→ <code>[Pending]</code></p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> To generate the knowledge graph, the correspondence of 10 to Closed and 11 to processing is represented in a SQL CASE statement. The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig3_11"><img alt="Image" src="../images/fig3_11.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.11:</span> Complex custom attribute mapping: CASE example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_22"><img alt="Image" src="../images/pg63_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_63" title="63"/>This example is visually represented in <a href="#fig3_11">Figure <span class="blue">3.11</span></a>.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_3_4"><span epub:type="pagebreak" id="page_64" title="64"/>3.3.4<span class="space3"/><span epub:type="title">COMPLEX CONCEPT ATTRIBUTE: NULL</span></h3>
|
||
<p class="noindent"><b>Context: A</b> column can have a NULL, which should be replaced by a constant in order to be mapped to an attribute.</p>
|
||
<p class="noindentt"><b>Solution:</b> Use a SQL function that replaces a NULL with a constant such as <code>IFNULL ()</code>, <code>ISNULL()</code>, <code>COALESCE()</code>, or <code>NVL()</code></p>
|
||
<figure>
|
||
<div class="image" id="fig_23"><img alt="Image" src="../images/pg64_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for the attribute’s associated concept.</p>
|
||
<p class="exe"><b>Example 3.12</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order</code> table stores all the order transactions. The column status contains the status of the order, such as Closed, Processing, etc., including <code>NULL</code>.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_14">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="3"><code>sales_flat_order</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>...</b></code></th>
|
||
<th class="thead tc"><code><b>status</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc"/>
|
||
<td class="tab1 tc">Pending</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc"/>
|
||
<td class="tab1 tc">Closed</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">3</td>
|
||
<td class="tab1 tc"/>
|
||
<td class="tab1 tc">NULL</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concept <i>Order</i> and an associated attribute <i>orderStatus</i> whose datatype is a string:</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order) —orderStatus→ <code>[string]</code></p>
|
||
</div>
|
||
<p class="noindent">A <code>NULL</code> status means unknown. The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —orderStatus→ <code>[Pending]</code></p>
|
||
<p class="center">(order-2) —orderStatus→ <code>[Closed]</code></p>
|
||
<p class="center">(order-3) —orderStatus→ <code>[Pending]</code></p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> To generate the knowledge graph, the correspondence of NULL to Unknown is represented in a SQL COALESCE function. The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig_24"><img alt="Image" src="../images/pg64_2.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_12">Figure <span class="blue">3.12</span></a>.</p>
|
||
<figure>
|
||
<div class="image" id="fig3_12"><img alt="Image" src="../images/fig3_12.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.12:</span> Complex custom attribute mapping: NULL example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_3_5"><span epub:type="pagebreak" id="page_65" title="65"/>3.3.5<span class="space3"/><span epub:type="title">COMPLEX CONCEPT ATTRIBUTE: JOIN</span></h3>
|
||
<p class="noindent"><b>Context:</b> The identifier of the concept is in one table while the column that needs to be mapped is in a different table.</p>
|
||
<p class="noindentt"><b>Solution:</b> Join the tables together such that the identifier of the concept and the column to be mapped is in the same relation</p>
|
||
<figure>
|
||
<div class="image" id="fig_25"><img alt="Image" src="../images/pg65_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for the attribute’s associated concept.</p>
|
||
<p class="exe"><span epub:type="pagebreak" id="page_66" title="66"/><b>Example 3.13</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order</code> table stores all the order transactions. The <code>sales_order_status</code> stores the look up codes of order statuses. The column <code>status_id</code> of the <code>sales_flat_order</code> table is a foreign key that references <code>entity_id</code> of <code>sales_order_status</code>.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_15">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="3"><code>sales_flat_order</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>...</b></code></th>
|
||
<th class="thead tc"><code><b>status_id</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc"/>
|
||
<td class="tab1 tc">10</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc"/>
|
||
<td class="tab1 tc">11</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">3</td>
|
||
<td class="tab1 tc"/>
|
||
<td class="tab1 tc">10</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_16">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="2"><code>sales_order_status</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>status</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">10</td>
|
||
<td class="tab1 tc">Pending</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">11</td>
|
||
<td class="tab1 tc">Closed</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concept <i>Order</i> and an associated attribute <i>orderStatus</i> whose datatype is a string:</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order) —orderStatus→ [string]</p>
|
||
</div>
|
||
<p class="noindent">A NULL status means unknown. The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —orderStatus→ [Pending]</p>
|
||
<p class="center">(order-2) —orderStatus→ [Closed]</p>
|
||
<p class="center">(order-3) —orderStatus→ [Pending]</p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> The tables <code>sales_flat_order</code> and <code>sales_order_status</code> need to be joined in order to associate the status column of <code>sales_order_status</code> with the orders in <code>sales_flat_order</code>. The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig_26"><img alt="Image" src="../images/pg66_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_13">Figure <span class="blue">3.13</span></a>.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_3_6">3.3.6<span class="space3"/><span epub:type="title">COMPLEX CONCEPT ATTRIBUTE: LEFT JOIN</span></h3>
|
||
<p class="noindent"><b>Context:</b> The identifier of the concept is in one table while the column that needs to be mapped is in a different table. However, the join keys may have NULL values.</p>
|
||
<p class="noindentt"><b>Solution:</b> Join the tables together using LEFT JOIN such that the identifier of the concept and the column to be mapped is in the same relation. Then apply the NULL mapping pattern <span epub:type="pagebreak" id="page_67" title="67"/>where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for the attribute’s associated concept.</p>
|
||
<figure>
|
||
<div class="image" id="fig3_13"><img alt="Image" src="../images/fig3_13.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.13:</span> Complex custom attribute mapping: JOIN example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_27"><img alt="Image" src="../images/pg67_1.jpg"/></div>
|
||
</figure>
|
||
<p class="exe"><b>Example 3.14</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order</code> table stores all the order transactions. The <code>sales_order_status</code> stores the look up codes of order statuses. The column <code>status_id</code> of the <code>sales_flat_order</code> table is a foreign key that references <code>entity_id</code> of <code>sales_order_status</code>.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_17">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="3"><code>sales_flat_order</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>...</b></code></th>
|
||
<th class="thead tc"><code><b>status_id</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc"/>
|
||
<td class="tab1 tc">10</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc"/>
|
||
<td class="tab1 tc">11</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">3</td>
|
||
<td class="tab1 tc"/>
|
||
<td class="tab1 tc">11</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">4</td>
|
||
<td class="tab1 tc"/>
|
||
<td class="tab1 tc">NULL</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_18">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="2"><code>sales_order_status</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>status</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">10</td>
|
||
<td class="tab1 tc">Processing</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">11</td>
|
||
<td class="tab1 tc">Closed</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_68" title="68"/><i>Target:</i> The knowledge graph schema consists of the concept <i>Order</i> and an associated attribute <i>orderStatus</i> whose datatype is a string:</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order) —OrderStatus→ <code>[string]</code></p>
|
||
</div>
|
||
<p class="noindent">A <code>NULL</code> status means unknown. The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —orderStatus→ <code>[Pending]</code></p>
|
||
<p class="center">(order-2) —orderStatus→ <code>[Closed]</code></p>
|
||
<p class="center">(order-3) —orderStatus→ <code>[Closed]</code></p>
|
||
<p class="center">(order-4) —orderStatus→ <code>[Pending]</code></p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> The tables <code>sales_flat_order</code> and <code>sales_order_status</code> need to be joined in order to associate the status column of <code>sales_order_status</code> with the orders in <code>sales_flat_order</code>. It has to be a left join in order to not reject the rows with <code>NULL</code> value in the foreign key column. Additionally, the resulting NULL should be replaced with “Unknown.” The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig_28"><img alt="Image" src="../images/pg68_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_14">Figure <span class="blue">3.14</span></a>.</p>
|
||
<p class="noindentt"><b>Discussion:</b> Why does this happen? All orders should have an order status, right? The NULL value is probably indicative of a data quality issue.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_3_7">3.3.7<span class="space3"/><span epub:type="title">COMPLEX CONCEPT ATTRIBUTE: DUPLICATE</span></h3>
|
||
<p class="noindent"><b>Context: A</b> table (or the result of a query) already contains the identifier of the concept and the column that is to be mapped to an attribute. However, there the identifier of the concept is not serving as a key because multiple rows exist with the same identifier but with different values of the colum.</p>
|
||
<figure>
|
||
<div class="image" id="fig3_14"><img alt="Image" src="../images/fig3_14.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.14:</span> Complex custom attribute mapping: LEFT JOIN example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_69" title="69"/><b>Solution:</b> Use an aggregator function (MIN or MAX) and group by the identifier of the concept, in order to guarantee uniqueness</p>
|
||
<figure>
|
||
<div class="image" id="fig_29"><img alt="Image" src="../images/pg69_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for the attribute’s associated concept.</p>
|
||
<p class="exe"><b>Example 3.15</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>customer_date</code> table stores all data about customers and dates: when they joined, their birthdate, etc. The column <code>entity_id</code> is the primary key, <code>customer_id</code> is a foreign key that <span epub:type="pagebreak" id="page_70" title="70"/>references the <code>customer_entity</code> table. Even though the database does not violate any integrity constraints, there is a data quality issue because <code>customer_id</code> has two birthdates: 1985-10-17 and 1986-10-17.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_19">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="5"><code>customer_date</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>customer_id</b></code></th>
|
||
<th class="thead tc"><code><b>date_value</b></code></th>
|
||
<th class="thead tc"><code><b>join_date</b></code></th>
|
||
<th class="thead tc"><code><b>birth_date</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">2020-01-01</td>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">0</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">1985-10-17</td>
|
||
<td class="tab1 tc">0</td>
|
||
<td class="tab1 tc">1</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">3</td>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">1986-10-17</td>
|
||
<td class="tab1 tc">0</td>
|
||
<td class="tab1 tc">1</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">4</td>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">2020-01-01</td>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">0</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">5</td>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">1980-01-01</td>
|
||
<td class="tab1 tc">0</td>
|
||
<td class="tab1 tc">1</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concept <i>Customer</i> and an associated attribute <i>birthDate</i> whose datatype is a date:</p>
|
||
<div class="box-top">
|
||
<p class="center">(Customer) —birthDate→ <code>[date]</code></p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(Customer-1) —birthDate→ <code>[1985 — 10 — 17]</code></p>
|
||
<p class="center">(Customer-2) —birthDate→ <code>[1980 — 01 — 01]</code></p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> To generate the knowledge graph, we need to eliminate the duplicate birthdate. However, it is not known which is the correct birth date. We can do an aggregation over the date_value and arbitrarily choose between MIN or a MAX. The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig_30"><img alt="Image" src="../images/pg70_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_15">Figure <span class="blue">3.15</span></a>.</p>
|
||
<p class="noindentt"><b>Discussion:</b> Why does this happen? We are masking the data quality problem in the mappings.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_3_8">3.3.8<span class="space3"/><span epub:type="title">COMPLEX CONCEPT ATTRIBUTE: CONSTANT TABLE</span></h3>
|
||
<p class="noindent"><b>Context: A</b> table name represents the value that needs to be mapped to an attribute.</p>
|
||
<p class="noindentt"><b>Solution:</b> Project the concept identifier from the table and the constant that the table is representing which is to be mapped to the attribute <span epub:type="pagebreak" id="page_71" title="71"/>where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for the attribute’s associated concept.</p>
|
||
<figure>
|
||
<div class="image" id="fig3_15"><img alt="Image" src="../images/fig3_15.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.15:</span> Complex custom attribute mapping: duplicate example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_31"><img alt="Image" src="../images/pg71_1.jpg"/></div>
|
||
</figure>
|
||
<p class="exe"><b>Example 3.16</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order_payment_paypal</code> table stores all the payment transactions that came through the Paypal payment platform:</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_20">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="2"><code>sales_flat_order_payment_paypal</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>amount_paid</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">110</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">100</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_72" title="72"/><i>Target:</i> The knowledge graph schema consists of the concept <i>Order</i> and an associated attribute <i>paymentMethod</i> whose datatype is a string:</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order) —paymentMethod→ <code>[string]</code></p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —paymentMethod→ <code>[Paypal]</code></p>
|
||
<p class="center">(order-2) —paymentMethod→ <code>[Paypal]</code></p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> To generate the knowledge graph, a constant value “Paypal” is added to each row coming from the <code>sales_flat_order_payment_paypal</code> table. The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig_32"><img alt="Image" src="../images/pg72_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_16">Figure <span class="blue">3.16</span></a>.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_3_9">3.3.9<span class="space3"/><span epub:type="title">COMPLEX CONCEPT ATTRIBUTE: CONSTANT ATTRIBUTE</span></h3>
|
||
<p class="noindent"><b>Context: A</b> column name in a table represents the value that needs to be mapped to an attribute.</p>
|
||
<p class="noindentt"><b>Solution:</b> Project the concept identifier from the table and filter by the column that represents the attribute. Provide a constant that the column is representing which is to be mapped to the attribute</p>
|
||
<figure>
|
||
<div class="image" id="fig_33"><img alt="Image" src="../images/pg72_2.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for the attribute’s associated concept.</p>
|
||
<p class="exe"><b>Example 3.17</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order_payment</code> table stores all the payment transactions and has a flag to know from which payment system it came from:</p>
|
||
<figure>
|
||
<div class="image" id="fig3_16"><img alt="Image" src="../images/fig3_16.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.16:</span> Complex custom attribute mapping: constant table.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_21">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="4"><code>sales_flat_order_payment</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>amount_paid</b></code></th>
|
||
<th class="thead tc"><code><b>paypal</b></code></th>
|
||
<th class="thead tc"><code><b>visa</b></code></th>
|
||
<th class="thead tc"><code><b>mc</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">110</td>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">0</td>
|
||
<td class="tab1 tc">0</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">0</td>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">0</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_73" title="73"/><i>Target:</i> The knowledge graph schema consists of the concept <i>Order</i> and an associated attribute <i>paymentMethod</i> whose datatype is a string:</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order) —paymentMethod→ <code>[string]</code></p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —paymentMethod→ <code>[Paypal]</code></p>
|
||
<p class="center">(order-2) —paymentMethod→ <code>[Paypal]</code></p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> To generate the knowledge graph, a constant value “Paypal” is added to each row coming from the <code>sales_flat_order_payment</code> table where <code>paypal=1</code>, and a constant value <span epub:type="pagebreak" id="page_74" title="74"/>“Visa” is added to each row coming from the <code>sales_flat_order_payment</code> table where <code>visa=1</code>.</p>
|
||
<p class="noindent">The mappings are the following:</p>
|
||
<p class="noindent">Mapping for Paypal</p>
|
||
<figure>
|
||
<div class="image" id="fig_34"><img alt="Image" src="../images/pg74_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">Mapping for Visa</p>
|
||
<figure>
|
||
<div class="image" id="fig_35"><img alt="Image" src="../images/pg74_2.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_17">Figure <span class="blue">3.17</span></a>.</p>
|
||
<p class="noindentt"><b>Discussion:</b> We could also add paypal = 1 and visa = 0 to assure data quality.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_3_10">3.3.10<span class="space3"/><span epub:type="title">COMPLEX CONCEPT ATTRIBUTE: CONSTANT VALUE</span></h3>
|
||
<p class="noindent"><b>Context: A</b> value in a column is a code and it needs to be mapped to a certain constant.</p>
|
||
<p class="noindentt"><b>Solution:</b> Project the concept identifier from the table and filter by value in the column that represents the attribute. Provide a constant that the value is representing which is to be mapped to the attribute</p>
|
||
<figure>
|
||
<div class="image" id="fig_36"><img alt="Image" src="../images/pg74_3.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for the attribute’s associated concept.</p>
|
||
<p class="exe"><b>Example 3.18</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order_payment</code> table stores all the payment transactions and has a flag to know from which payment system it came from:</p>
|
||
<figure>
|
||
<div class="image" id="fig3_17"><img alt="Image" src="../images/fig3_17.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.17:</span> Complex custom attribute mapping: constant attribute.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_22">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="3"><code>sales_flat_order_payment</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>amount_paid</b></code></th>
|
||
<th class="thead tc"><code><b>payment_type</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">110</td>
|
||
<td class="tab1 tc">pp</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">vs</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_75" title="75"/><i>Target:</i> The knowledge graph schema consists of the concept <i>Order</i> and an associated attribute <i>paymentMethod</i> whose datatype is a string:</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order) —paymentMethod→ <code>[string]</code></p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —paymentMethod→ <code>[Paypal]</code></p>
|
||
<p class="center">(order-2) —paymentMethod→ <code>[Paypal]</code></p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> To generate the knowledge graph, a constant value “Paypal” is added to each row coming from the <code>sales_flat_order_payment</code> table where <code>payment_type = pp</code>, and a constant <span epub:type="pagebreak" id="page_76" title="76"/>value “Visa” is added to each row coming from the <code>sales_flat_order_payment</code> table where <code>payment_type = vs.</code> The mappings are the following:</p>
|
||
<p class="noindent">Mapping for Paypal</p>
|
||
<figure>
|
||
<div class="image" id="fig_37"><img alt="Image" src="../images/pg76_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">Mapping for Visa</p>
|
||
<figure>
|
||
<div class="image" id="fig_38"><img alt="Image" src="../images/pg76_2.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_18">Figure <span class="blue">3.18</span></a>.</p>
|
||
<p class="noindentt"><b>Discussion:</b> This is a specific version of the CASE mapping pattern.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_3_11">3.3.11<span class="space3"/><span epub:type="title">COMPLEX CONCEPT ATTRIBUTE: EAV</span></h3>
|
||
<p class="noindent"><b>Context:</b> The relational data is represented in a entity–attribute–value (EAV) model where the attributes of an entity and the corresponding value are all data values in a table.</p>
|
||
<p class="noindentt"><b>Solution:</b> The attribute is mapped to value in the attribute column and the entity and value columns are projected</p>
|
||
<figure>
|
||
<div class="image" id="fig_39"><img alt="Image" src="../images/pg76_3.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">where <span class="underline"><code>ENTITY-ID</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for the attribute’s associated concept.</p>
|
||
<p class="exe"><b>Example 3.19</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>customer_eav_varchar</code> table stores attribute and values that are varchars for customer-related data</p>
|
||
<figure>
|
||
<div class="image" id="fig3_18"><img alt="Image" src="../images/fig3_18.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.18:</span> Complex custom attribute mapping: constant attribute.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_23">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="3"><code>customer_eav_varchar</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>attribute_id</b></code></th>
|
||
<th class="thead tc"><code><b>value</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">Juan</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">Sequeda</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">3</td>
|
||
<td class="tab1 tc">juan@data.world</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">101</td>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">Ora</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">101</td>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">Lassila</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">101</td>
|
||
<td class="tab1 tc">3</td>
|
||
<td class="tab1 tc"><a href="mailto:ora@amazon.com">ora@amazon.com</a></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_77" title="77"/><i>Target:</i> The knowledge graph schema consists of the concept <i>Customer</i> and an associated attribute <i>email</i> and whose datatype is a string.</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order) —email→ <code>[string]</code></p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(customer-100) —email→ <code>[juan@data.world]</code></p>
|
||
<p class="center">(customer-101) —email→ <code><a href="mailto:[ora@amazon.com]">[ora@amazon.com]</a></code></p>
|
||
</div>
|
||
<figure>
|
||
<div class="image" id="fig3_19"><img alt="Image" src="../images/fig3_19.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.19:</span> Complex custom attribute mapping: EAV.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_78" title="78"/><i>Mapping:</i> The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig_40"><img alt="Image" src="../images/pg78_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_19">Figure <span class="blue">3.19</span></a>.</p>
|
||
<p class="noindentt"><b>Discussion:</b> An EAV model is used to enable flexibility given that the relational model is rigid. A triple table, which is a way of storing graph data in a relational database, is a form of an EAV model.</p>
|
||
</section>
|
||
</section>
|
||
<section>
|
||
<h2 class="head2" id="ch3_4"><span epub:type="pagebreak" id="page_79" title="79"/>3.4<span class="space3"/><span epub:type="title">COMPLEX CUSTOM RELATIONSHIP MAPPING PATTERNS</span></h2>
|
||
<section>
|
||
<h3 class="head3" id="ch3_4_1">3.4.1<span class="space3"/><span epub:type="title">RELATIONSHIP: MANY TO MANY</span></h3>
|
||
<p class="noindent"><b>Context: A</b> table represents a many-to-many relationship when it is modeled by having two foreign keys that reference the corresponding entities that are being related. The table can have additional attributes. This means that the pair of foreign keys attributes per row in the table represents an instance of the relationship between Concepts that are identified by the foreign key.</p>
|
||
<p class="noindentt"><b>Solution:</b> An ordered pair of foreign keys from the many-to-many table are mapped to a relationship</p>
|
||
<figure>
|
||
<div class="image" id="fig_41"><img alt="Image" src="../images/pg79_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">where <span class="underline"><code>FK1</code></span> and <span class="underline"><code>FK2</code></span> are foreign key columns that references other tables.</p>
|
||
<p class="exe"><b>Example 3.20</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>customer_shipping_address</code> table stores the many to many relationship of customers and shipping address. The column <code>customer_id</code> is a foreign key that references a customer table and the column <code>shipping_address_id</code> is a foreign key that references an address table. Both columns form a primary key.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_24">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="2"><code>customer_shipping_address</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>customer_id</b></code></th>
|
||
<th class="thead tc"><code><b>shipping_address_id</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">1000</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">1001</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">101</td>
|
||
<td class="tab1 tc">1002</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">101</td>
|
||
<td class="tab1 tc">1000</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concepts <i>Customer</i> and <i>Address.</i> The relationship <i>has shipping address</i> connects the <i>Customer</i> concept to <i>Address</i> concept.</p>
|
||
<div class="box-top">
|
||
<p class="center">(Customer) —hasShippingAddress→ (Address)</p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(customer-100) —hasShippingAddress→ (address-1000)</p>
|
||
<p class="center">(customer-100) —hasShippingAddress→ (address-1001)</p>
|
||
<p class="center">(customer-101) —hasShippingAddress→ (address-1002)</p>
|
||
<p class="center">(customer-101) —hasShippingAddress→ (address-1000)</p>
|
||
</div>
|
||
<figure>
|
||
<div class="image" id="fig3_20"><img alt="Image" src="../images/fig3_20.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.20:</span> Relationship: many to many.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_80" title="80"/><i>Mapping:</i></p>
|
||
<figure>
|
||
<div class="image" id="fig_42"><img alt="Image" src="../images/pg80_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_20">Figure <span class="blue">3.20</span></a>.</p>
|
||
<p class="noindentt"><b>Discussion:</b> The direction of the relationship was established going from Order to an Address. An inverse relationship can use the same body of the mapping rule. The head of the mapping rule would have the order of the foreign key columns swapped.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_4_2"><span epub:type="pagebreak" id="page_81" title="81"/>3.4.2<span class="space3"/><span epub:type="title">RELATIONSHIP: ONE TO MANY WITHOUT DUPLICATES</span></h3>
|
||
<p class="noindent"><b>Context: A</b> table contains data that represents two concepts and the relationship between them. There is no redundancy in the table which means that the primary key of the table can serve as part of the unique identifier for each concept.</p>
|
||
<p class="noindentt"><b>Solution:</b> Create three mappings, one for the first concept, another one for the second concept and a final one for the relationship. All three mappings use the same key</p>
|
||
<figure>
|
||
<div class="image" id="fig_43"><img alt="Image" src="../images/pg81_1.jpg"/></div>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_44"><img alt="Image" src="../images/pg81_2.jpg"/></div>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_45"><img alt="Image" src="../images/pg81_3.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for Concept1 and Concept2.</p>
|
||
<p class="exe"><b>Example 3.21</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>customer_entity</code> table stores all the customers and their addresses. The column <code>entity_id</code> is the primary key.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_25">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="6"><code>customer_entity</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>fname</b></code></th>
|
||
<th class="thead tc"><code><b>lname</b></code></th>
|
||
<th class="thead tc"><code><b>street</b></code></th>
|
||
<th class="thead tc"><code><b>city</b></code></th>
|
||
<th class="thead tc"><code><b>state</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">Juan</td>
|
||
<td class="tab1 tc">Sequeda</td>
|
||
<td class="tab1 tc">123 A St.</td>
|
||
<td class="tab1 tc">Austin</td>
|
||
<td class="tab1 tc">TX</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">Ora</td>
|
||
<td class="tab1 tc">Lassila</td>
|
||
<td class="tab1 tc">456 B St.</td>
|
||
<td class="tab1 tc">Austin</td>
|
||
<td class="tab1 tc">TX</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concepts <i>Customer</i> and <i>Address.</i> The relationship <i>hasAddress</i> connects the <i>Customer</i> concept <i>to Address</i> concept.</p>
|
||
<div class="box-top">
|
||
<p class="center">(Customer) — hasAddress→ (Address)</p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(customer-1) —type→ (Customer)</p>
|
||
<p class="center">(customer-2) —type→ (Customer)</p>
|
||
<p class="center">(address-1) —type→ (Address)</p>
|
||
<p class="center">(address-2) —type→ (Address)</p>
|
||
<p class="center">(customer-1) —hasAddress→ (address-1)</p>
|
||
<p class="center">(customer-2) —hasAddress→ (address-2)</p>
|
||
</div>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_82" title="82"/><i>Mapping:</i> To generate the knowledge graph, we use the entity_id primary key column to uniquely identify the Customer and Address. We have to make sure that the identifier is globally unique and this is done by prefixing a string “customer” and “address” under the assumption that those strings will be part of the identifiers for Customer and Address, respectively. The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig_46"><img alt="Image" src="../images/pg82_1.jpg"/></div>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_47"><img alt="Image" src="../images/pg82_2.jpg"/></div>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_48"><img alt="Image" src="../images/pg82_3.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_21">Figure <span class="blue">3.21</span></a>.</p>
|
||
<p class="noindentt"><b>Discussion:</b> This is the process of denormalizing a table into two tables and establishing a foreign key between them.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_4_3">3.4.3<span class="space3"/><span epub:type="title">RELATIONSHIP: ONE TO MANY WITH DUPLICATES</span></h3>
|
||
<p class="noindent"><b>Context: A</b> table contains data that represents two concepts and the relationship between them. However, there is redundancy in the table which means that the primary key of the table can serve as part of the unique identifier for one concept. There may be another value that can serve as identifier for the second concept but that appears repeated.</p>
|
||
<p class="noindentt"><b>Solution:</b> Create three mappings, one for the first concept using the key of the table, another one for the second concept by definition distinct to get the unique key, and a final one for the relationship</p>
|
||
<figure>
|
||
<div class="image" id="fig_49"><span epub:type="pagebreak" id="page_83" title="83"/><img alt="Image" src="../images/pg82_4.jpg"/></div>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_50"><img alt="Image" src="../images/pg82_5.jpg"/></div>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig3_21"><img alt="Image" src="../images/fig3_21.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.21:</span> Relationship: one to many without duplicates example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<figure>
|
||
<div class="image"><img alt="Image" src="../images/pg83_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">where <span class="underline"><code>ID1</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for Concept1. <span class="underline"><code>ID2</code></span> is a column that uniquely identifies the rows that will mapped to Concept2.</p>
|
||
|
||
<p class="exe"><b>Example 3.22</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order</code> table stores all the order transactions and the customer data. The customer data is redundant because it is repeated for each order transaction. The column <code>entity_id</code> is the primary key for the <code>sales_flat_order</code> table. The column <code>customer_id</code> uniquely identifies a customer, however it is repeated (as with all the other customer data) in the <code>sales_flat_order</code> table.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_26">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="5"><code>sales_flat_order</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>grand_total</b></code></th>
|
||
<th class="thead tc"><code><b>customer_id</b></code></th>
|
||
<th class="thead tc"><code><b>fname</b></code></th>
|
||
<th class="thead tc"><code><b>lname</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">110</td>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">Juan</td>
|
||
<td class="tab1 tc">Sequeda</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">Juan</td>
|
||
<td class="tab1 tc">Sequeda</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">3</td>
|
||
<td class="tab1 tc">95</td>
|
||
<td class="tab1 tc">101</td>
|
||
<td class="tab1 tc">Ora</td>
|
||
<td class="tab1 tc">Lassila</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_84" title="84"/><i>Target:</i> The knowledge graph schema consists of the concepts <i>Order</i> and <i>Customer.</i> The relationship <i>placedBy</i> connects the <i>Order</i> concept to <i>Customer</i> concept.</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order) —placedBy→ (Customer)</p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(customer-100) —type→ (Customer)</p>
|
||
<p class="center">(customer-101) —type→ (Customer)</p>
|
||
<p class="center">(order-1) —type→ (Order)</p>
|
||
<p class="center">(order-2) —type→ (Order)</p>
|
||
<p class="center">(order-3) —type→ (Order)</p>
|
||
<p class="center">(Order-1) —placedBy→ (Customer-100)</p>
|
||
<p class="center">(Order-2) —placedBy→ (Customer-100)</p>
|
||
<p class="center">(Order-3) —placedBy→ (Customer-101)</p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> To generate the knowledge graph, the Order concept is direct custom mapping to the <code>sales_flat_order</code> table, while the Customer concept is mapped to the distinct <code>customer_id</code> of the <code>sales_flat_order</code> table. Finally, the placedBy relationship is mapped to the column pair (<code>entity_id, customer_id</code>). The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig_51"><img alt="Image" src="../images/pg84_1.jpg"/></div>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_52"><img alt="Image" src="../images/pg84_2.jpg"/></div>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_53"><img alt="Image" src="../images/pg84_3.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_22">Figure <span class="blue">3.22</span></a>.</p>
|
||
<p class="noindentt"><b>Discussion:</b> This is the process of denormalizing a table into two tables and establishing a foreign key between them.</p>
|
||
<figure>
|
||
<div class="image" id="fig3_22"><img alt="Image" src="../images/fig3_22.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.22:</span> Relationship: one to many without duplicates example.</p>
|
||
</figcaption>
|
||
</figure>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_4_4"><span epub:type="pagebreak" id="page_85" title="85"/>3.4.4<span class="space3"/><span epub:type="title">RELATIONSHIP: ONE TO ONE WITH DUPLICATES</span></h3>
|
||
<p class="noindent"><b>Context: A</b> table contains data that represents a 1-1 relationship between two concepts. However, the table stores data with a 1-M cardinality.</p>
|
||
<p class="noindentt"><b>Solution:</b> Create a subquery that returns a 1-1 relationship from the table by grouping on the attribute that has duplicate data. Decide which function (MIN, MAX) needs to be applied and on which column based on the usecase. The subquery is then joined with the table <span epub:type="pagebreak" id="page_86" title="86"/>where <span class="underline"><code>ID1</code></span> is a column that is used to create the identifier for the instances of Concept1. <span class="underline"><code>ID2</code></span> is a column that is used to create the identifier for the instances of Concept2.</p>
|
||
<figure>
|
||
<div class="image" id="fig_54"><img alt="Image" src="../images/pg85_1.jpg"/></div>
|
||
</figure>
|
||
<p class="exe"><b>Example 3.23</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order_address</code> table stores all the shipping address data associated to an order transaction. If the shipping address has been updated, then a new tuple is added to the table.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_27">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="4"><code>sales_flat_order_address</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>order_id</b></code></th>
|
||
<th class="thead tc"><code><b>address_id</b></code></th>
|
||
<th class="thead tc"><code><b>created_at</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">10</td>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">1000</td>
|
||
<td class="tab1 tc">2021-01-01 08:00:00</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">11</td>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">1002</td>
|
||
<td class="tab1 tc">2021-01-01 08:30:00</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">12</td>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">1001</td>
|
||
<td class="tab1 tc">2021-01-01 09:00:00</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">13</td>
|
||
<td class="tab1 tc">3</td>
|
||
<td class="tab1 tc">1000</td>
|
||
<td class="tab1 tc">2021-01-01 10:00:00</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concepts <i>Order</i> and <i>Address.</i> The relationship <i>shippedTo</i> connects the <i>Order</i> concept to <i>Address</i> concept. Additionally, the business logic is that an order can only be shipped to one address, hence it is a 1-1 relationship:</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order) —shippedTo→ (Address)</p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(Order-1) —shippedTo→ (address-1002)</p>
|
||
<p class="center">(Order-2) —shippedTo→ (address-1001)</p>
|
||
<p class="center">(Order-3) —shippedTo→ (address-1000)</p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> To generate the knowledge graph, the shippedTo relationship needs to be mapped to the column pair (order_id,address_id). However, note that there may be duplicates. In this example, order_id=1 has two different address_id, 1000 and 1002, and this violates the business logic. In order to return a 1-1 relationship, the SQL query must aggregate all the order_id and address_id by some qualifier, in this case, the maximum created_at. The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig_55"><img alt="Image" src="../images/pg86_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_23">Figure <span class="blue">3.23</span></a>.</p>
|
||
<figure>
|
||
<div class="image" id="fig3_23"><img alt="Image" src="../images/fig3_23.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.23:</span> Relationship: one to one with duplicates.</p>
|
||
</figcaption>
|
||
</figure>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_4_5"><span epub:type="pagebreak" id="page_87" title="87"/>3.4.5<span class="space3"/><span epub:type="title">RELATIONSHIP: CONSTANT TABLE</span></h3>
|
||
<p class="noindent"><b>Context: A</b> table name represents the value that needs to be mapped to a relationship and a corresponding concept.</p>
|
||
<p class="noindentt"><b>Solution:</b> Create a query that returns the identifier used to create instances of the domain of the relationship and define a constant that maps to the range concept of the relationship</p>
|
||
<figure>
|
||
<div class="image" id="fig_56"><span epub:type="pagebreak" id="page_88" title="88"/><img alt="Image" src="../images/pg87_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindentt">where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for Concept1.</p>
|
||
<p class="exe"><b>Example 3.24</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order_payment_paypal</code> table stores all the payment transactions that came through the paypal payment platform.</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_28">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="2"><code>sales_flat_order_payment_paypal</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>amount_paid</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">110</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">100</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concepts <i>Order</i> and <i>PaymentMethod.</i> There are two types of payment methods: <i>Paypal</i> and <i>Visa</i> The relationship <i>hasPaymentMethod</i> connects the <i>Order</i> concept to one of the specific <i>PaymentMethod</i> types.</p>
|
||
<div class="box-top">
|
||
<p class="center">(order) —hasPaymentMethod→ (PaymentMethod)</p>
|
||
<p class="center">(Paypal) —type→ (PaymentMethod)</p>
|
||
<p class="center">(Visa) —type→ (PaymentMethod)</p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —hasPaymentMethod→ (Paypal)</p>
|
||
<p class="center">(order-2) —hasPaymentMethod→ (Paypal)</p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> To generate the knowledge graph, a constant value “Paypal,” which is the same as the concept in the knowledge graph schema, is added to each row coming from the sales_flat_order_payment_paypal table. The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig_57"><img alt="Image" src="../images/pg88_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_24">Figure <span class="blue">3.24</span></a>.</p>
|
||
<p class="noindentt"><b>Discussion:</b> Similar to Attribute Constant table.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_4_6">3.4.6<span class="space3"/><span epub:type="title">RELATIONSHIP: CONSTANT ATTRIBUTE</span></h3>
|
||
<p class="noindent"><b>Context: A</b> column name in a table represents the value that needs to be mapped to a relationship and a corresponding concept.</p>
|
||
<p class="noindentt"><b>Solution:</b> Project the concept identifier from the table and filter by the column that represents the attribute. Provide a constant that the column is representing which is to be mapped to the Concept <span epub:type="pagebreak" id="page_89" title="89"/>where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for Concept1.</p>
|
||
<figure>
|
||
<div class="image" id="fig3_24"><img alt="Image" src="../images/fig3_24.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.24:</span> Relationship: constant table.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_58"><img alt="Image" src="../images/pg89_1.jpg"/></div>
|
||
</figure>
|
||
<p class="exe"><b>Example 3.25</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order_payment</code> table stores all the payment transactions and has a flag to know from which payment system it came from:</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_29">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="5"><code>sales_flat_order_payment</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>amount_paid</b></code></th>
|
||
<th class="thead tc"><code><b>paypal</b></code></th>
|
||
<th class="thead tc"><code><b>visa</b></code></th>
|
||
<th class="thead tc"><code><b>mc</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">110</td>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">0</td>
|
||
<td class="tab1 tc">0</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">0</td>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">0</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_90" title="90"/><i>Target:</i> The knowledge graph schema consists of the concepts <i>Order</i> and <i>PaymentMethod.</i> There are two types of payment methods: <i>Paypal</i> and <i>Visa</i>. The relationship <i>hasPaymentMethod</i> connects the <i>Order</i> concept to one of the specific <i>PaymentMethod</i> types.</p>
|
||
<div class="box-top">
|
||
<p class="center">(order) —hasPaymentMethod→ (PaymentMethod)</p>
|
||
<p class="center">(Paypal) —type→ (PaymentMethod)</p>
|
||
<p class="center">(Visa) —type→ (PaymentMethod)</p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —hasPaymentMethod→ (Paypal)</p>
|
||
<p class="center">(order-2) —hasPaymentMethod→ (Paypal)</p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> To generate the knowledge graph, a constant value “Paypal” is added to each row coming from the <code>sales_flat_order_payment</code> table where paypal=1, a constant value “Visa” is added to each row coming from the <code>sales_flat_order_payment</code> table where visa=1, and so on. The mapping is the following:</p>
|
||
<p class="noindent">Mapping for Paypal</p>
|
||
<figure>
|
||
<div class="image" id="fig_59"><img alt="Image" src="../images/pg90_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">Mapping for Visa</p>
|
||
<figure>
|
||
<div class="image" id="fig_60"><img alt="Image" src="../images/pg90_2.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_25">Figure <span class="blue">3.25</span></a>.</p>
|
||
<p class="noindentt"><b>Discussion:</b> Similar to Attribute Constant Attribute.</p>
|
||
<figure>
|
||
<div class="image" id="fig3_25"><img alt="Image" src="../images/fig3_25.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.25:</span> Relationship: constant attribute.</p>
|
||
</figcaption>
|
||
</figure>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_4_7"><span epub:type="pagebreak" id="page_91" title="91"/>3.4.7<span class="space3"/><span epub:type="title">RELATIONSHIP: CONSTANT VALUE</span></h3>
|
||
<p class="noindent"><b>Context: A</b> value in a column is a code and it needs to be mapped to a Concept in the knowledge graph.</p>
|
||
<p class="noindentt"><b>Solution:</b> Project the concept identifier from the table and filter by value in the column that represents the Concept. Provide a constant that the value is representing which is to be mapped to the Concept</p>
|
||
<figure>
|
||
<div class="image" id="fig_61"><img alt="Image" src="../images/pg91_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for the relationship’s associated concept.</p>
|
||
<p class="exe"><span epub:type="pagebreak" id="page_92" title="92"/><b>Example 3.26</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>sales_flat_order_payment</code> table stores all the payment transactions and has a flag to know from which payment system it came from:</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_30">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="3"><code>sales_flat_order_payment</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>amount_paid</b></code></th>
|
||
<th class="thead tc"><code><b>payment_type</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">110</td>
|
||
<td class="tab1 tc">pp</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">100</td>
|
||
<td class="tab1 tc">vs</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concepts <i>Order</i> and <i>PaymentMethod.</i> There are two types of payment methods: <i>Paypal</i> and <i>Visa</i> The relationship <i>hasPaymentMethod</i> connects the <i>Order</i> concept to one of the specific <i>PaymentMethod</i> types.</p>
|
||
<div class="box-top">
|
||
<p class="center">(order) —hasPaymentMethod→ (PaymentMethod)</p>
|
||
<p class="center">(Paypal) —type→ (PaymentMethod)</p>
|
||
<p class="center">(Visa) —type→ (PaymentMethod)</p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(order-1) —hasPaymentMethod→ (Paypal)</p>
|
||
<p class="center">(order-2) —hasPaymentMethod→ (Visa)</p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> To generate the knowledge graph, a constant value “Paypal” is added to each row coming from the sales_flat_order_payment table where payment_type = pp, and a constant value “Visa” is added to each row coming from the sales_flat_order_payment table where payment_type = vs. The mappings are the following:</p>
|
||
<p class="noindent">Mapping for Paypal</p>
|
||
<figure>
|
||
<div class="image" id="fig_62"><img alt="Image" src="../images/pg92_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">Mapping for Visa</p>
|
||
<figure>
|
||
<div class="image" id="fig_63"><img alt="Image" src="../images/pg92_2.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent">This example is visually represented in <a href="#fig3_26">Figure <span class="blue">3.26</span></a>.</p>
|
||
<figure>
|
||
<div class="image" id="fig3_26"><img alt="Image" src="../images/fig3_26.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.26:</span> Relationship: constant value.</p>
|
||
</figcaption>
|
||
</figure>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_93" title="93"/><b>Discussion:</b> This is a specific version of the CASE mapping pattern. Similar to Concept Attribute Constant Value.</p>
|
||
</section>
|
||
<section>
|
||
<h3 class="head3" id="ch3_4_8">3.4.8<span class="space3"/><span epub:type="title">RELATIONSHIP: BIDRECTIONAL</span></h3>
|
||
<p class="noindent"><b>Context:</b> A table represents a bidrectional relationship between two concepts. This is usually modeled by having two attributes (usually foreign keys) that reference the corresponding concepts that are being related. This means that the pair of attributes per row in the table represents an instance of the relationship between Concepts.</p>
|
||
<p class="noindentt"><b>Solution:</b> Create two mappings. The body of both mappings are the same. The head of each of the two mappings corresponds to the direction of the relationship between the two instances</p>
|
||
<figure>
|
||
<div class="image" id="fig_64"><img alt="Image" src="../images/pg93_1.jpg"/></div>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_65"><img alt="Image" src="../images/pg94_1.jpg"/></div>
|
||
</figure>
|
||
<p class="noindent"><span epub:type="pagebreak" id="page_94" title="94"/>where <span class="underline"><code>ID</code></span> is a column that uniquely identifies each row of the resulting query and is used as the identifier for the relationship’s associated concept.</p>
|
||
<p class="exe"><b>Example 3.27</b></p>
|
||
<p class="noindent"><i>Source:</i> The <code>customer_rel</code> table stores the social network between customers, when a customer connected with another customer:</p>
|
||
<div class="lf5">
|
||
<table class="table2" id="tab_31">
|
||
<thead>
|
||
<tr>
|
||
<th class="tc" colspan="4"><code>customer_rel</code></th>
|
||
</tr>
|
||
<tr>
|
||
<th class="thead tc"><code><b>entity_id</b></code></th>
|
||
<th class="thead tc"><code><b>customer_id1</b></code></th>
|
||
<th class="thead tc"><code><b>customer_id2</b></code></th>
|
||
<th class="thead tc"><code><b>created_at</b></code></th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="tab1 tc">10</td>
|
||
<td class="tab1 tc">1</td>
|
||
<td class="tab1 tc">2</td>
|
||
<td class="tab1 tc">2009-01-01</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<p class="noindent"><i>Target:</i> The knowledge graph schema consists of the concepts <i>Customer</i> and the relationship <i>knows</i> connects a <i>Customer</i> concept with itself, thus it is a bidirectional relationship. If Customer A knows Customer B, then Customer B knows Customer A.</p>
|
||
<div class="box-top">
|
||
<p class="center">(Customer)—knows→(Customer)</p>
|
||
</div>
|
||
<p class="noindent">The expected knowledge graph is the following:</p>
|
||
<div class="box-top">
|
||
<p class="center">(customer-1)—knows→(customer-2)</p>
|
||
<p class="center">(customer-2)—knows→(customer-1)</p>
|
||
</div>
|
||
<p class="noindent"><i>Mapping:</i> The knows relationship is bidrectional, meaning that if customer-1 knows customer-2, it implies that customer-2 also knows customer-1. To generate the knowledge graph, the knows relationship is mapped to the attribute ordered pairs (customer_id1, customer_id2) and (customer_id2, customer_id1). The mapping is the following:</p>
|
||
<figure>
|
||
<div class="image" id="fig_66"><img alt="Image" src="../images/pg94_2.jpg"/></div>
|
||
</figure>
|
||
<figure>
|
||
<div class="image" id="fig_67"><img alt="Image" src="../images/pg94_3.jpg"/></div>
|
||
</figure>
|
||
<p>This example is visually represented in <a href="#fig3_27">Figure <span class="blue">3.27</span></a>.<span epub:type="pagebreak" id="page_95" title="95"/></p>
|
||
<figure>
|
||
<div class="image" id="fig3_27"><img alt="Image" src="../images/fig3_27.jpg"/></div>
|
||
<figcaption>
|
||
<p class="figcaption"><span class="blue">Figure 3.27:</span> Relationship: bidirectional.</p>
|
||
</figcaption>
|
||
</figure>
|
||
</section>
|
||
</section>
|
||
</section>
|
||
</body>
|
||
</html> |