OntoWiki

You have no permissions to edit this model.

Saving has been disabled.

# Exported with the Erfurt API - http://aksw.org/Projects/Erfurt

@base <http://www.archimind.nl/archimindLOD/index.php/view/r/> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix ns0: <http://archimind.nl/archimind/index.php/view/> .
@prefix ns1: <http://www.archimind.nl/archimind/index.php/resource/properties/> .
@prefix ns2: <http://www.archimind.nl/archimind/index.php/> .
@prefix ns3: <http://www.archimind.nl/archimindLOD/index.php/view/r/> .
@prefix ontology1288790966584: <http://www.semanticweb.org/ontologies/2010/10/Ontology1288790966584.owl#> .
@prefix ontowiki_wikipage: <http://localhost/ontowiki_WikiPage/> .
@prefix owl2xml: <http://www.w3.org/2006/12/owl2-xml#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sadocontology1: <http://www.archimind.nl/archimindLOD/index.php/view/r/sadocontology1.owl:> .
@prefix sioc: <http://rdfs.org/sioc/ns#> .
@prefix sioct: <http://rdfs.org/sioc/types#> .
@prefix sysconf: <http://localhost/OntoWiki/Config/> .
@prefix uva-sa-ontology: <http://www.archimind.org/archimind/UvA-SA-ontology.owl#> .
@prefix view: <http://localhost/ontowiki/view/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://www.archimind.nl/archimindLOD/index.php/view/r/sadocontology1.owl:12_logical_and_implementation_view_-_background_-_rationale_-_relational_database_syste> ontowiki_wikipage:content """
	Relational database system

	 

	Explanation 
	 
	

	In a relational database system, data is stored in tables that have relationships to each other using primary and foreign keys. The combining of these tables (terminology: joining of tables) to retrieve certain data can often be an expensive task. The relational database system would have to store multiple tables of data in order to prevent duplication. A (part of the database) could look like this for example: 
	 
	Table: communication
<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\" style=\"width:624px;\" width=\"624\">
	<tbody>
		<tr>
			<td>
				
					communication_id
			</td>
			<td>
				
					first_person_id
			</td>
			<td>
				
					second_person_id
			</td>
			<td>
				
					project_id
			</td>
		</tr>
		<tr>
			<td>
				
					1
			</td>
			<td>
				
					172
			</td>
			<td>
				
					383
			</td>
			<td>
				
					9292
			</td>
		</tr>
		<tr>
			<td>
				
					2
			</td>
			<td>
				
					383
			</td>
			<td>
				
					482
			</td>
			<td>
				
					3038
			</td>
		</tr>
		<tr>
			<td>
				
					3
			</td>
			<td>
				
					383
			</td>
			<td>
				
					593
			</td>
			<td>
				
					492
			</td>
		</tr>
	</tbody>
</table>

	 
	Table: persons
<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\" style=\"width:624px;\" width=\"624\">
	<tbody>
		<tr>
			<td>
				
					person_id
			</td>
			<td>
				
					full_name
			</td>
			<td>
				
					profession
			</td>
		</tr>
		<tr>
			<td>
				
					172
			</td>
			<td>
				
					David Smith
			</td>
			<td>
				
					Junior Programmer
			</td>
		</tr>
		<tr>
			<td>
				
					383
			</td>
			<td>
				
					Jeremy Bakersfield
			</td>
			<td>
				
					Senior Programmer
			</td>
		</tr>
		<tr>
			<td>
				
					482
			</td>
			<td>
				
					Lucas Morgan
			</td>
			<td>
				
					Medior Programmer
			</td>
		</tr>
		<tr>
			<td>
				
					593
			</td>
			<td>
				
					Hank Copperfield
			</td>
			<td>
				
					Intern
			</td>
		</tr>
	</tbody>
</table>

	 

	Table: subjects
<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\">
	<tbody>
		<tr>
			<td style=\"height:21px;\">
				
					project_id
			</td>
			<td style=\"height:21px;\">
				
					project_title
			</td>
		</tr>
		<tr>
			<td style=\"height:5px;\">
				
					9292
			</td>
			<td style=\"height:5px;\">
				
					Public Transport Information System
			</td>
		</tr>
		<tr>
			<td style=\"height:1px;\">
				
					3038
			</td>
			<td style=\"height:1px;\">
				
					Bank Transaction system
			</td>
		</tr>
		<tr>
			<td>
				
					492
			</td>
			<td>
				
					NFC research
			</td>
		</tr>
	</tbody>
</table>

	 
	From this data, it can be concluded that Jeremy Bakersfield acts as a central bridge of communication for 2 other developers and about three projects about an information system for public transport, a bank transaction system and research about NFC. In order to reach this conclusion three tables need to be joined together, which can cost more and more performance as the data set grows larger. Also, every occurrence of communication gets its own database record. This problem set can easily grow quite large.A list of disadvantages and advantages can be found in the appendix under section: Relational Database system

	 

	Graph database system

	 

	Explanation

	 

	Though relational databases have broadly been used for decades now, they do have their limitations. As stated in the previous paragraphs, joining tables together costs a lot of processing power. In graph databases there are entities and relationships (nodes and edges). These relationships play an important role in the database system.

	 

	<picture></picture>

	These graph databases provide a huge performance advantage over relational databases when querying for information that would otherwise require one or multiple joins.

	<img alt=\"\" src=\"/ckfinder/userfiles/images/8.png\" style=\"width: 436px; height: 242px;\" />

	In a benchmark performed by researchers from the University of Mississippi [1], the performance of a popular relational database (MySQL) is compared to the performance of a popular graph database (Neo4j).

	 

	They say that “Graphs were created to contain approximately 1000, 5000, 10000, and 100000 nodes to aid in assessing scalability. The type of payload data stored in each node also varied. The payloads consisted of random integers, random 8KB strings, and random 32KB strings. Thus, twelve MySQL and twelve Neo4j databases were constructed from the random graphs.”

	 

	They also state that the size of the graph database is usually about 1.5 to 2 times larger in megabytes. This is certainly something to consider, but it doesn’t outweigh the gain in performance since data storage is quite cheap nowadays.

	The queries they’ve used to test the database are divided into two categories: structural and data queries. They define three structural queries:

	 

	-          Find all orphan nodes. That is, find all nodes in the graph that are singletons, with no incoming edges and no outgoing edges
 

	 

	-           

	-          Traverse the graph to a depth of 4 and count the number of nodes reachable

	-          Traverse the graph to a depth of 128 and count the number of nodes reachable

	 

	As well as three data queries:

	-          Count the number of nodes whose payload data is equal to some value

	-          Count the number of nodes whose payload data is less than some value

	-          Count the number of nodes whose payload data contains some search string (length ranges from 4 to 8) 
	 

	They conclude that in the first type of queries, the Neo4j database performed a lot better than the MySQL database. Sometimes this was even an order of magnitude faster. However, the opposite is true for the latter three queries. A list of disadvantages and advantages can be found in the appendix under section: “Graph Database system”.

	 

	Conclusion

	 

	After explaining the two database choices as well as their advantages and disadvantages for this specific situation, a choice needs to be made. In this chapter we outweigh the pros and cons and come to an advice for the stakeholders which type of database system to implement.

	 

	One of the desired key qualities for the application as requested by the stakeholders is performance. They do not wish to wait for a long time in order for an analysis to finish. In order to deal with this problem, we decided to store several analysed data in a database rather than retrieve it every time the user makes a request.

	 

	This alone is however not assurance enough that the system will perform in a fast manner, since a lot of data still needs to be coupled in order to view communication between developers, trace isolated developers, etc. Due to the performance bottleneck that a relational database has the graph database seems like a fit solution for these types of queries.

	 

	As can be read in the explanation section of the graph database, it can perform up to an order of a magnitude faster than a relational database with these types of queries. Queries which take field values and do something with this (i.e. sum them) are performed faster in a relational database, but these are a lot less interesting as the first type will be queried much more.

	 

	The question is then whether the disadvantages of using a graph database can be overcome, the fact that there’s less expertise available and that it needs up to twice as much space to store its data. The latter is certainly no showstopper as disk storage has become cheaper and cheaper in the past few years.

	 

	The fact that the database type hasn’t been around for too much time certainly puts it behind relational databases regarding its maturity as well as availability for high quality tools. However, the concept is gaining attention in the past few years and big companies such as Google, Facebook and LinkedIn now use this technology so this will most likely improve even further over time.

	We conclude that the graph database is therefore the best fit for this problem, provided that the developers that will ultimately create this application study the ins and outs of it thoroughly. The performance gain and the fact that large companies to achieve similar goals use this sort of database system provide us enough confidence to recommend this solution.

	 """ ;
 sadocontology1:contains_knowledge_about sadocontology1:Analsyis_data_in_graph_database, sadocontology1:Analsyis_database_is_relational, sadocontology1:Complexity, sadocontology1:Performance, sadocontology1:Scheduler, sadocontology1:developer ;
 a sadocontology1:WikiPage, owl:NamedIndividual ;
 rdfs:label "12 logical and implementation view - background - rationale - relational database system" .

# Exported with the Erfurt API - http://aksw.org/Projects/Erfurt

@base <http://www.archimind.nl/archimindLOD/index.php/view/r/> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix ns0: <http://archimind.nl/archimind/index.php/view/> .
@prefix ns1: <http://www.archimind.nl/archimind/index.php/resource/properties/> .
@prefix ns2: <http://www.archimind.nl/archimind/index.php/> .
@prefix ns3: <http://www.archimind.nl/archimindLOD/index.php/view/r/> .
@prefix ontology1288790966584: <http://www.semanticweb.org/ontologies/2010/10/Ontology1288790966584.owl#> .
@prefix ontowiki_wikipage: <http://localhost/ontowiki_WikiPage/> .
@prefix owl2xml: <http://www.w3.org/2006/12/owl2-xml#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sadocontology1: <http://www.archimind.nl/archimindLOD/index.php/view/r/sadocontology1.owl:> .
@prefix sioc: <http://rdfs.org/sioc/ns#> .
@prefix sioct: <http://rdfs.org/sioc/types#> .
@prefix sysconf: <http://localhost/OntoWiki/Config/> .
@prefix uva-sa-ontology: <http://www.archimind.org/archimind/UvA-SA-ontology.owl#> .
@prefix view: <http://localhost/ontowiki/view/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://www.archimind.nl/archimindLOD/index.php/view/r/sadocontology1.owl:12_logical_and_implementation_view_-_background_-_rationale_-_relational_database_syste> ontowiki_wikipage:content """<p>
	<strong>Relational database system</strong></p>
<p>
	 </p>
<p>
	<strong>Explanation<br />
	<br />
	</strong></p>
<p>
	In a relational database system, data is stored in tables that have relationships to each other using primary and foreign keys. The combining of these tables (terminology: joining of tables) to retrieve certain data can often be an expensive task. The relational database system would have to store multiple tables of data in order to prevent duplication. A (part of the database) could look like this for example:<br />
	<br />
	Table: communication</p>
<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\" style=\"width:624px;\" width=\"624\">
	<tbody>
		<tr>
			<td>
				<p>
					<strong>communication_id</strong></p>
			</td>
			<td>
				<p>
					<strong>first_person_id</strong></p>
			</td>
			<td>
				<p>
					<strong>second_person_id</strong></p>
			</td>
			<td>
				<p>
					<strong>project_id</strong></p>
			</td>
		</tr>
		<tr>
			<td>
				<p>
					1</p>
			</td>
			<td>
				<p>
					172</p>
			</td>
			<td>
				<p>
					383</p>
			</td>
			<td>
				<p>
					9292</p>
			</td>
		</tr>
		<tr>
			<td>
				<p>
					2</p>
			</td>
			<td>
				<p>
					383</p>
			</td>
			<td>
				<p>
					482</p>
			</td>
			<td>
				<p>
					3038</p>
			</td>
		</tr>
		<tr>
			<td>
				<p>
					3</p>
			</td>
			<td>
				<p>
					383</p>
			</td>
			<td>
				<p>
					593</p>
			</td>
			<td>
				<p>
					492</p>
			</td>
		</tr>
	</tbody>
</table>
<p>
	<br />
	Table: persons</p>
<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\" style=\"width:624px;\" width=\"624\">
	<tbody>
		<tr>
			<td>
				<p>
					<strong>person_id</strong></p>
			</td>
			<td>
				<p>
					<strong>full_name</strong></p>
			</td>
			<td>
				<p>
					<strong>profession</strong></p>
			</td>
		</tr>
		<tr>
			<td>
				<p>
					172</p>
			</td>
			<td>
				<p>
					David Smith</p>
			</td>
			<td>
				<p>
					Junior Programmer</p>
			</td>
		</tr>
		<tr>
			<td>
				<p>
					383</p>
			</td>
			<td>
				<p>
					Jeremy Bakersfield</p>
			</td>
			<td>
				<p>
					Senior Programmer</p>
			</td>
		</tr>
		<tr>
			<td>
				<p>
					482</p>
			</td>
			<td>
				<p>
					Lucas Morgan</p>
			</td>
			<td>
				<p>
					Medior Programmer</p>
			</td>
		</tr>
		<tr>
			<td>
				<p>
					593</p>
			</td>
			<td>
				<p>
					Hank Copperfield</p>
			</td>
			<td>
				<p>
					Intern</p>
			</td>
		</tr>
	</tbody>
</table>
<p>
	 </p>
<p>
	Table: subjects</p>
<table border=\"0\" cellpadding=\"0\" cellspacing=\"0\">
	<tbody>
		<tr>
			<td style=\"height:21px;\">
				<p>
					<strong>project_id</strong></p>
			</td>
			<td style=\"height:21px;\">
				<p>
					<strong>project_title</strong></p>
			</td>
		</tr>
		<tr>
			<td style=\"height:5px;\">
				<p>
					9292</p>
			</td>
			<td style=\"height:5px;\">
				<p>
					Public Transport Information System</p>
			</td>
		</tr>
		<tr>
			<td style=\"height:1px;\">
				<p>
					3038</p>
			</td>
			<td style=\"height:1px;\">
				<p>
					Bank Transaction system</p>
			</td>
		</tr>
		<tr>
			<td>
				<p>
					492</p>
			</td>
			<td>
				<p>
					NFC research</p>
			</td>
		</tr>
	</tbody>
</table>
<p>
	<br />
	From this data, it can be concluded that Jeremy Bakersfield acts as a central bridge of communication for 2 other developers and about three projects about an information system for public transport, a bank transaction system and research about NFC. In order to reach this conclusion three tables need to be joined together, which can cost more and more performance as the data set grows larger. Also, every occurrence of communication gets its own database record. This problem set can easily grow quite large.A list of disadvantages and advantages can be found in the appendix under section: Relational Database system</p>
<p>
	 </p>
<p>
	<strong>Graph database system</strong></p>
<p>
	 </p>
<p>
	<strong>Explanation</strong></p>
<p>
	 </p>
<p>
	Though relational databases have broadly been used for decades now, they do have their limitations. As stated in the previous paragraphs, joining tables together costs a lot of processing power. In graph databases there are entities and relationships (nodes and edges). These relationships play an important role in the database system.</p>
<p>
	 </p>
<p>
	<strong><picture></picture></strong></p>
<p>
	These graph databases provide a huge performance advantage over relational databases when querying for information that would otherwise require one or multiple joins.</p>
<p>
	<img alt=\"\" src=\"/ckfinder/userfiles/images/8.png\" style=\"width: 436px; height: 242px;\" /></p>
<p>
	In a benchmark performed by researchers from the University of Mississippi [1], the performance of a popular relational database (MySQL) is compared to the performance of a popular graph database (Neo4j).</p>
<p>
	 </p>
<p>
	They say that “Graphs were created to contain approximately 1000, 5000, 10000, and 100000 nodes to aid in assessing scalability. The type of payload data stored in each node also varied. The payloads consisted of random integers, random 8KB strings, and random 32KB strings. Thus, twelve MySQL and twelve Neo4j databases were constructed from the random graphs.”</p>
<p>
	 </p>
<p>
	They also state that the size of the graph database is usually about 1.5 to 2 times larger in megabytes. This is certainly something to consider, but it doesn’t outweigh the gain in performance since data storage is quite cheap nowadays.</p>
<p>
	The queries they’ve used to test the database are divided into two categories: structural and data queries. They define three structural queries:</p>
<p>
	 </p>
<p>
	-          Find all orphan nodes. That is, find all nodes in the graph that are singletons, with no incoming edges and no outgoing edges</p>
<br clear=\"all\" />
<p>
	 </p>
<p>
	-           </p>
<p>
	-          Traverse the graph to a depth of 4 and count the number of nodes reachable</p>
<p>
	-          Traverse the graph to a depth of 128 and count the number of nodes reachable</p>
<p>
	 </p>
<p>
	As well as three data queries:</p>
<p>
	-          Count the number of nodes whose payload data is equal to some value</p>
<p>
	-          Count the number of nodes whose payload data is less than some value</p>
<p>
	-          Count the number of nodes whose payload data contains some search string (length ranges from 4 to 8)<br />
	 </p>
<p>
	They conclude that in the first type of queries, the Neo4j database performed a lot better than the MySQL database. Sometimes this was even an order of magnitude faster. However, the opposite is true for the latter three queries. A list of disadvantages and advantages can be found in the appendix under section: “Graph Database system”.</p>
<p>
	 </p>
<p>
	<strong>Conclusion</strong></p>
<p>
	 </p>
<p>
	After explaining the two database choices as well as their advantages and disadvantages for this specific situation, a choice needs to be made. In this chapter we outweigh the pros and cons and come to an advice for the stakeholders which type of database system to implement.</p>
<p>
	 </p>
<p>
	One of the desired key qualities for the application as requested by the stakeholders is performance. They do not wish to wait for a long time in order for an analysis to finish. In order to deal with this problem, we decided to store several analysed data in a database rather than retrieve it every time the user makes a request.</p>
<p>
	 </p>
<p>
	This alone is however not assurance enough that the system will perform in a fast manner, since a lot of data still needs to be coupled in order to view communication between developers, trace isolated developers, etc. Due to the performance bottleneck that a relational database has the graph database seems like a fit solution for these types of queries.</p>
<p>
	 </p>
<p>
	As can be read in the explanation section of the graph database, it can perform up to an order of a magnitude faster than a relational database with these types of queries. Queries which take field values and do something with this (i.e. sum them) are performed faster in a relational database, but these are a lot less interesting as the first type will be queried much more.</p>
<p>
	 </p>
<p>
	The question is then whether the disadvantages of using a graph database can be overcome, the fact that there’s less expertise available and that it needs up to twice as much space to store its data. The latter is certainly no showstopper as disk storage has become cheaper and cheaper in the past few years.</p>
<p>
	 </p>
<p>
	The fact that the database type hasn’t been around for too much time certainly puts it behind relational databases regarding its maturity as well as availability for high quality tools. However, the concept is gaining attention in the past few years and big companies such as Google, Facebook and LinkedIn now use this technology so this will most likely improve even further over time.</p>
<p>
	We conclude that the graph database is therefore the best fit for this problem, provided that the developers that will ultimately create this application study the ins and outs of it thoroughly. The performance gain and the fact that large companies to achieve similar goals use this sort of database system provide us enough confidence to recommend this solution.</p>
<p>
	 </p>""" ;
                                                                                                                                                                   sadocontology1:contains_knowledge_about sadocontology1:Analsyis_data_in_graph_database, sadocontology1:Analsyis_database_is_relational, sadocontology1:Complexity, sadocontology1:Performance, sadocontology1:Scheduler, sadocontology1:developer ;
                                                                                                                                                                   a sadocontology1:WikiPage, owl:NamedIndividual ;
                                                                                                                                                                   rdfs:label "12 logical and implementation view - background - rationale - relational database system" .

Source of Statements about 12 logical and implementation view - background - rationale - relational database system (without imported statements)

Knowledge Bases

Navigation

Source of Statements about 12 logical and implementation view - background - rationale - relational database system (without imported statements)

OntoWiki

Knowledge Bases

Navigation

Login