<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="tr">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">Veri Yogun Bilgi Sistemleri İçin Melez Bir Veri Mimarisi Önerisi</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">Osman</forename><surname>Murat</surname></persName>
							<email>murat.osman.unalir@ege.edu.tr</email>
							<affiliation key="aff0">
								<orgName type="department">Bilgisayar Mühendisligi Bölümü</orgName>
								<orgName type="institution">Ege Üniversitesi</orgName>
								<address>
									<postCode>35100</postCode>
									<settlement>Bornova, İzmir</settlement>
									<country>Türkiye</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Emrah</forename><surname>Ünalır</surname></persName>
							<affiliation key="aff0">
								<orgName type="department">Bilgisayar Mühendisligi Bölümü</orgName>
								<orgName type="institution">Ege Üniversitesi</orgName>
								<address>
									<postCode>35100</postCode>
									<settlement>Bornova, İzmir</settlement>
									<country>Türkiye</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Burak</forename><surname>İnan</surname></persName>
							<affiliation key="aff0">
								<orgName type="department">Bilgisayar Mühendisligi Bölümü</orgName>
								<orgName type="institution">Ege Üniversitesi</orgName>
								<address>
									<postCode>35100</postCode>
									<settlement>Bornova, İzmir</settlement>
									<country>Türkiye</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Emre</forename><surname>Yönyül</surname></persName>
							<affiliation key="aff0">
								<orgName type="department">Bilgisayar Mühendisligi Bölümü</orgName>
								<orgName type="institution">Ege Üniversitesi</orgName>
								<address>
									<postCode>35100</postCode>
									<settlement>Bornova, İzmir</settlement>
									<country>Türkiye</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Fatmana</forename><forename type="middle">S</forename><surname>Olca</surname></persName>
							<affiliation key="aff0">
								<orgName type="department">Bilgisayar Mühendisligi Bölümü</orgName>
								<orgName type="institution">Ege Üniversitesi</orgName>
								<address>
									<postCode>35100</postCode>
									<settlement>Bornova, İzmir</settlement>
									<country>Türkiye</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Vahab</forename><surname>¸entürk</surname></persName>
							<affiliation key="aff0">
								<orgName type="department">Bilgisayar Mühendisligi Bölümü</orgName>
								<orgName type="institution">Ege Üniversitesi</orgName>
								<address>
									<postCode>35100</postCode>
									<settlement>Bornova, İzmir</settlement>
									<country>Türkiye</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Petek</forename><surname>Mostafapour</surname></persName>
							<email>v.mostafapour@gmail.com</email>
							<affiliation key="aff0">
								<orgName type="department">Bilgisayar Mühendisligi Bölümü</orgName>
								<orgName type="institution">Ege Üniversitesi</orgName>
								<address>
									<postCode>35100</postCode>
									<settlement>Bornova, İzmir</settlement>
									<country>Türkiye</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Dilek</forename><surname>Yıldız</surname></persName>
							<affiliation key="aff0">
								<orgName type="department">Bilgisayar Mühendisligi Bölümü</orgName>
								<orgName type="institution">Ege Üniversitesi</orgName>
								<address>
									<postCode>35100</postCode>
									<settlement>Bornova, İzmir</settlement>
									<country>Türkiye</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Devrim</forename><surname>Yılmazer</surname></persName>
							<email>devrimisli@gmail.com</email>
							<affiliation key="aff0">
								<orgName type="department">Bilgisayar Mühendisligi Bölümü</orgName>
								<orgName type="institution">Ege Üniversitesi</orgName>
								<address>
									<postCode>35100</postCode>
									<settlement>Bornova, İzmir</settlement>
									<country>Türkiye</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><surname>İşli</surname></persName>
							<affiliation key="aff0">
								<orgName type="department">Bilgisayar Mühendisligi Bölümü</orgName>
								<orgName type="institution">Ege Üniversitesi</orgName>
								<address>
									<postCode>35100</postCode>
									<settlement>Bornova, İzmir</settlement>
									<country>Türkiye</country>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">Veri Yogun Bilgi Sistemleri İçin Melez Bir Veri Mimarisi Önerisi</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">1EC4DE23C6C10467B5A206AEF4C52608</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-25T02:05+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>Bulut bilişim teknolojileriyle birlikte bilgi sistemlerinde işlenen veri hacmi artmaktadır. Veri hacminin artmasının yanında, veriye hızlı erişim en önemli gereksinimdir. İlişkisel veri modeli kullanımının yanında ilişkisel olmayan veri modellerinin de kullanımı önemli boyutlara ulaşmıştır. Bu çalışmada veri yogun bilgi sistemleri için melez bir veri mimarisi önerisinde bulunulmaktadır. Öncelikle büyük veri kapsamında farklı veri modellerinin temel özellikleri tartışılmaktadır. Örnek bir bilgi sisteminin gereksinimleri dogrultusunda farklı veri modellerine duyulan gereksinimler vurgulanmaktadır. İlgili bilgi sistemini temel alan bir durum çalışması metamodel mimarisine uygun olarak ontolojik bir yapıda tasarlanmıştır. Melez veri mimarisini meydana getiren farklı veri modellerinin anahtardeger veri modeline dönüştürülebilirligi gösterilmiştir. Bilgi sisteminin ilgili veri servislerinin temel özellikleri farklı teknolojiler kapsamında sunulmuştur.</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="tr">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Giriş</head><p>Bulut bilişim istenilen yerden bilgisayar agları, sunucuları, depolama, uygulama gibi bilişim kaynaklarına servisler aracılıgıyla erişimine olanak tanır <ref type="bibr" target="#b0">[1]</ref>. Bu kaynakları kullanmak için yönetim ve servis etkileşimi maliyetlerini en aza indirmeyi hedefler <ref type="bibr" target="#b1">[2]</ref>. Böylece altyapı, esneklik ve kaynakların kullanılabilirligi gibi sorunlarla ugraşılmadıgından ve sonuç olarak ana işe odaklanılmakta işlenen verinin hacmi de artmaktadır. Ancak bu durum verinin yönetilmesini zorlaştırır. Büyük veri, ilişkisel veri modeli yaklaşımıyla ölçeklenemeyen verinin verimli bir şekilde depolanmasına, yönetilmesine ve işlenmesine olanak tanır <ref type="bibr" target="#b2">[3]</ref>. Bulut bilişim, büyük verinin hesaplama ve işleme süreçlerine imkan sunmakla birlikte servis modeli olarak da hizmet eder.</p><p>Büyük verinin hacim, hız ve çeşitlilik olmak üzere 3 karakteristik özelligi vardır <ref type="bibr" target="#b3">[4]</ref>, <ref type="bibr" target="#b4">[5]</ref>. Hacim, çok büyük miktarlardaki veriye, hız ise verinin kaynaklar arası aktarılma süratine karşılık gelmektedir. C ¸eşitlilik, farklı biçimde ve kaynaktaki verilerin toplanmasıyla ilgilenmektedir.</p><p>Farklı veri modellerinin bir bilgi sisteminde bir arada kullanılabilmesi için melez bir veri mimarisine gereksinim duyulmaktadır. Not only SQL (NoSql) olarak adlandırılan ilişkisel olmayan veri modelleri bir veri mimarisinin çözümünde sadece ilişkisel veri modelinin kullanılamayacagını ifade etmektedir <ref type="bibr" target="#b5">[6]</ref>. NoSql veri modelleri anahtar-deger, çizge, doküman ve sütun veritabanı olmak üzere 4 alt kategoriye ayrılır. Anahtar-deger veritabanı okuma ve yazma işlemlerini hızlandırır. C ¸izge veritabanı dügümlerin baglar aracılıgıyla kolay bir şekilde dolaşılmasını saglar. Doküman veritabanı farklı biçimlerdeki veri kaynaklarının daha esnek işletilmesine olanak tanır. Sütun veritabanı ilişkili sütunların bir sütun ailesinde toplanmasıyla uygulamalara geniş kapsamlı sorgu ve veri çözümlemeleri yapabilme yetenegini sunar.</p><p>C ¸ok çeşitli kalıcılık (Polyglot persistence) <ref type="bibr" target="#b6">[7]</ref>, ihtiyaç duyulan melez yaklaşımı tanımlamak için kullanılır. Ancak buradaki her veri yönetim modeli ayrı birer yönetimsel karmaşıklıga sahiptir. Saklanan veri arttıkça performans kayıpları oluşmakta ve oluşan bu kayıpların giderilmesi de birbirinden farklılık gösterebilmektedir. Buna göre tasarlanan mimarinin gereksinimine uygun veri mo-delinin seçilmesi önem kazanmaktadır <ref type="bibr" target="#b7">[8]</ref>. Bu çalışma kapsamında, Ögrenci Bilgi Sistemi ( ÖBS) için farklı veri modellerini barındıran melez bir veri mimarisi önerilmektedir. ÖBS; ögretim üyeleri, ögrenciler ve derslere ilişkin bilgilerin saklandıgı bir sistemdir. Ögretim üyelerinin verdigi dersler, ögrencilerin kayıtlandıgı dersler, derse ait sınav sonuçları, ögrenci ve ögretim üyelerinin özgeçmişleri yer almaktadır.</p><p>Bu çalışmanın ikinci bölümünde büyük veri yönetimi için veri modelleri tanıtılmıştır. Üçüncü bölümünde ise bu veri modelleri üzerinde ÖBS ile ilgili durum çalışması yapılmıştır. Son olarak önerilen melez veri modelinin getirileri tartışılmış ve ileriki çalışmalar anlatılmıştır.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">Büyük Veri Yönetimi için Veri Modelleri</head><p>Veri yönetimi için ilişkisel veritabanı sistemleri F. Codd <ref type="bibr" target="#b8">[9]</ref> tarafından öne sürüldükten sonra zamanla geliştirilmiş ve böylece verilerin tutulması, saklanması ve işlenmesinde büyük kolaylıklar saglanmıştır. Ancak zamanla sistemleri kullanan kişi sayısı ve buna paralel olarak saklanan veri boyutu artmaya başlamıştır. Farklı kullanıcılar aynı tabloya eş zamanlı olarak erişmek istediginde, işlemlerin öncelik sırasına göre bitmesi beklenmektedir. Özellikle işlem hacminin yogun oldugu sistemler üzerinde uzun süreli beklemeler olabilmekte, bu da sistemin kullanıcılara cevap veremez duruma gelmesine ve performans kayıplarına sebep olmaktadır. Büyük hacimli verilerin merkezi sunucularda depolanması ve geleneksel veri analiz yöntemleri ile analiz edilmesinin verimsiz ve pahalı oldugu kanıtlanmıştır <ref type="bibr" target="#b9">[10]</ref>. İlişkisel veritabanlarında yapılan iyilileştirmeler veri boyutu uyarlanabilirlik gereksinimini ve performans ihtiyacını karşılayamamaktadır. Bu sebeple yatayda veya dikeyde veri boyutu uyarlanabilir bir veri saklama yapısına ihtiyaç duyulmuştur. Bu kapsamda farklı amaçlara göre özelleşmiş veritabanı çözümleri geliştirilmiştir. 2003 yılında ilk veri boyutu uyarlanabilir veritabanı ortaya çıkmış ve sonraki yıllarda da farklı amaçlar için yeni veritabanları geliştirilmeye devam etmiştir <ref type="bibr" target="#b5">[6]</ref> .</p><p>Karmaşıklık ve boyuta göre veritabanları incelendiginde ilişkisel veritabanı digerlerine göre kolay çözüm sunmasına ragmen veri boyutu uyarlanabilir degil-dir <ref type="bibr" target="#b10">[11]</ref>. Diger veritabanlarında ise veri boyutu arttıkça daha zor çözüm üretilmektedir. Hem karmaşıklık hem de veri boyutu uyarlanabilirlik kısıtlarını saglamak amacıyla farklı veri modelleri içeren sistemlerde büyük veri destekleyen veri-tabanlarından birkaçının kullanılması gerekmektedir. Bu durum birden fazla veri deposunun işlenmesi nedeniyle veri yönetim sorunlarına neden olmaktadır. Karşılaşılan veri modelleme sorununa çözüm olarak farklı veri modellerinin tek bir veri depolama altyapısına dönüştürülmesi önerilmiştir.</p><p>Bu yaklaşım, verinin esnek olarak modellenmesine olanak saglamaktadır <ref type="bibr" target="#b11">[12]</ref>. Ancak verilerin hangi veri modeline uygun oldugunun belirlenmesi önemlidir. En az karmaşıklıga ve en uyarlanabilir veri boyutuna sahip veritabanı olması nedeniyle digerlerinin anahtar-deger veritabanına dönüştürülmesi daha az maliyetlidir. Bu şekilde, farklı veritabanlarında yer alan verileri ortak bir veritabanına dönüştürerek farklı veri modellerini destekleyen bir veri modeli mimarisi önerilmiştir. Birden çok veri modelini anahtar-deger veri modeline dönüştüren çalışmalardan FoundationDB <ref type="bibr" target="#b12">[13]</ref>, farklı veri modellerindeki veriler için ilişkisel, çizge ve doküman veritabanlarını destekleyen bir yapı oluşturmuştur. ArangoDB <ref type="bibr" target="#b13">[14]</ref> ise doküman, çizge, anahtar-deger veritabanlarını destekleyen esnek açık kaynak bir veritabanı olarak sunulmuştur. Veritabanları arasındaki dönüşüm işlemleri sırasında yaşanabilecek herhangi bir problem, veriler arasında tutarsızlık ve veri kaybına neden olabilmekte, veritabanları arası dönüşümler ise bekleme sürelerine yol açabilmektedir. Veritabanları arası dönüşüm yerine veri modellerine göre verileri; çizge, doküman, sütun ve anahtar-deger veritabanlarında saklama gereksimi vardır. Bu çalışma kapsamında, bu farklı modellerdeki veriler arasındaki ilişkileri anahtar-deger veritabanında tutan veri yogun bilgi sistemlerine yönelik bir veri mimarisi önerilmektedir. Bundan sonraki alt başlıklarda sırasıyla ilişkisel, doküman, anahtar-deger, sütun ve çizge veritabanı kavramları detaylandırılmıştır.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.1">İlişkisel Veritabanı</head><p>Verilerin birbirinden farklı ve belirli özelliklere göre ilişkilendirilmiş tablolarda tutuldugu veritabanı yönetim sistemidir. Tablolar satır ve sütunlardan oluşmaktadır. Tablo içerisindeki her sütun bir nitelige karşılık gelmekte ve oluşturma aşamasında tanımlanmaktadır. Her satır ise bir kayda karşılık gelmekte ve veri girişi sırasında belirlenmektedir. Tabloda ayrıca tanımlayıcı niteliginde birincil anahtar alan ve tablolar arası geçişi saglayan ikinci anahtar alan bulunur. Bu alanlar kullanılarak farklı tablolar birleştirilebilir ve birbirine baglı veriler tek seferde sorgulanabilir. İlişkisel veritabanı kavramı, verileri saklamak için kullanılan mevcut dosyalama sisteminin veri ilişkilerini ve veri bütünlügünü saglayamaması üzerine oluşturulmuştur. İlişkisel veritabanları sagladıgı tutarlılık ve bütünlük avantajları sayesinde, uzun bir süre verilerin saklanması için yeterli olmuş ve pek çok veritabanı sisteminin temelini oluşturmuştur.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.2">Doküman Veritabanı</head><p>Doküman veritabanı sistemleri, ilişkisel olmayan veri modellerinden biridir. Yarı-yapılandırılmış veriler olarak bilinen doküman tabanlı bilgilerin saklanması, alınması ve yönetilmesinde kullanılan bir veri modelidir. Tablolara karşılık derlemler, satırlara karşılık dokümanlar, sütunlara karşılık da alanlar kullanılmaktadır. Sıradan bir şema yerine degişken bir şema temel alınmaktadır. Bazı alanların tüm kayıtlarda kullanılmadıgı durumlarda, ilişkisel veritabanlarında fazladan yer kaplarken bu alanlar doküman veritabanlarında yer almaz. Veri modeli tek tip degildir ve veriye göre esneklik gösterir. Böylece bir dokümanda yer almayan bazı alanlar bir başka doküman içerisinde kullanılabilir. Herhangi bir alan eklemek veya çıkarılmak istendiginde yapısal bir degişiklik yapılmamış olur ve sadece ilgili doküman degiştirilir. Böylece, gerekli degişikliklerin yapılması için fazladan bir zaman gerekmemektedir.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.3">Anahtar-Deger Veritabanı</head><p>Veritabanı sistemleri içerisinde karmaşıklıgı en az olanıdır. Bir anahtar ve bu anahtara karşılık gelen degerin saklandıgı veritabanı sistemidir. Eger bir anahtarın degeri biliniyor ise, anahtarın tuttugu deger getirilebilir. Deger alanı, yapılandırılmamış veri türündedir. Yani degerin içerigi sayı, baglantı, metin, vb. gibi farklı veri yapılarından oluşabilir. Örnegin, Twitter sosyal agında atılan her tweet için bir tweet numarası ve içerigi bulunmaktadır. Böyle bir yapının, anahtardeger veritabanında tutulması uygundur. Bu veritabanı türünde genel olarak deger kısmında yapısal olmayan veriler tutulmaktadır.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.4">Sütun Veritabanı</head><p>Anahtar-deger depoları ve doküman veritabanları satır odaklıdır. Bu tür veritabanlarının amacı bir yada daha fazla kısıta göre belirlenen bütün veriyi getirmektir. Bazı durumlarda uygulamalar bütün belgenin derlemi yerine belirli sütunların oluşturdugu alt kümelere ihtiyaç duyar. Sütun veritabanı, satırları sütun derlemleri gibi yapılandırabilir. Tek bir satır birçok sütun içerebilir. İlişkili sütunların bir sütun ailesinde toplanması ile çok varlıklı sütun verilerine erişilebilir. Sütun ailesindeki bu esneklik, ilişkisel veritabanları tarafından saglanan işlevsellige benzer olarak, uygulamalara geniş kapsamlı karmaşık sorgu ve veri analizlerinin yapılmasına olanak saglar.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.5">C ¸izge Veritabanı</head><p>Veri hacmi arttıkça ilişkisel veritabanında veri üzerinde arama mümkün olmakta, ancak zincirleme ilişkiler getirilecegi zaman birleştirme maliyetleri dogmaktadır. Doküman ve anahtar-deger veritabanlarında ise arama ilişkisel veritabanına göre daha zordur. Doküman veritabanlarında degerler döküman içerisinde, anahtar-deger veritabanlarında ise anahtara karşılık gelen deger kısmında yer alır. Zincirleme ilerlemek için herhangi bir birleşim yapısı olmadıgından, degerler aranıp bulunmalı ve eşlenmelidir. Ayrıca arama mümkün olsa bile veri üzerinde dolaşıp ilerleme mümkün olmamaktadır. C ¸izge veritabanlarında veriler; dügümler, dügümler arasındaki ayrıtlar ve dügümler ile ayrıtların özellikleri şeklinde tutulur. Ayrıtlar üzerinden ilerlenerek dügümler arasında gezmek ve arama yapmak mümkündür. Belirli dügümlere veya ayrıtlara özel aramalar yapılabilmektedir.</p><p>3 Durum C ¸alışması: Büyük Veri Modellerinin Ögrenci Bilgi Sistemi Üzerinde Uygulanması ÖBS kapsamında; ögrenci bilgileri, ögretim üyesi bilgileri, dersler, ögrencinin aldıgı ders bilgileri, ögrenci ve ögretim üyelerinin özgeçmişleri, ögrenci ve ögretim üyelerinin sosyal medya üzerinde yaptıgı paylaşımlar yer alır. Dersler hakkındaki görüşler, ögrenci, ögretim üyesi ve derse ait sosyal ag hesapları aracılıgıyla toplanır. Ögrenciler, ÖBS'ye giriş yaptıktan sonra herhangi bir ögretim üyesi tarafından verilen bir veya birden fazla derse kayıt olabilmekte ve kayıtlı oldukları derslere ilişkin sınav sonuçlarına erişebilmektedir. Ögrenciler, ögretim üyeleri veya dersler bir sosyal ag hesabına sahip olabilmektedir. Ögrenci ve ögretim üyelerinin sistemde kayıtlı bir veya birden fazla özgeçmiş belgesi bulunabilmektedir. Ayrıca ögrenci ve ögretim üyelerine ait kişisel bilgiler, iletişim bilgileri de saklanmaktadır.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1">Durum C ¸alışması Gereksinimleri</head><p>İlişkisel Veritabanı Gereksinimi Tasarlanan bilgi sisteminde ögrenci ve ögretim üyelerine ait kişisel bilgiler ilişkisel veritabanında ayrı tablolarda saklanır. Kişisel bilgiler tablosu kimlik numarası, adres, telefon numarası ve eposta gibi bilgilerden oluşur. Bu bilgilere erişim ögrenciler için ögrenci numarası, ögretim üyeleri için ögretim üyesi numarası olarak tanımlanan anahtar sahalar ile saglanır. Tanımlanan veri tipleri ve ilişkilere göre bu veriler ilişkisel veritabanında tutularak ihtiyaçlar karşılanabilmekte, veriler arasındaki ilişkiler kullanılarak ögrenci ve ögretim üyelerine ait kişisel bilgilere kolaylıkla ulaşılabilmektedir. Doküman Veritabanı Gereksinimi ÖBS'de bazı veriler ilişkisel veri modelinde saklanırken, bazı verilerin ilişkisel olarak modellenmesinde zorluklar yaşanmaktadır. Genel olarak özgeçmiş biçiminin degişime açık oldugu ve kayıtlar arasında farklılık olabilecegi görülmektedir. Ders içerik bilgilerinde de benzer bir durum söz konusudur. Ders bilgilerinin "dersin çıktıları" alanı her derse göre farklılık göstermektedir. Kayıt bazında alan özelleştirilmesine ihtiyaç duyulan bu gibi durumlarda klasik ilişkisel veri modeli yetersiz kalmaktadır. Özgeçmiş ve ders bilgileri için erişim maliyetlerini azaltan, performans artışı saglayan ve yatayda boyutunun degiştirilebilindigi dinamik bir veri modeline ihtiyaç duyulmaktadır. Bu gereksinimleri karşılayabilecek bir veri modeli olarak doküman veritabanı kullanılabilir.</p><p>Anahtar-Deger Veritabanı Gereksinimi ÖBS'de; ögrenci, ögretim üyesi ve diger kullanıcıların birer rolü bulunur. Bir ögrenci sadece kendisi ile ilgili bilgileri görüp degişiklikler yapabilir. Benzer şekilde bir ögretim üyesi de kendi bilgileri ve verdigi derslerin bilgilerini görüp üzerinde işlemler yapabilir. Bu nedenle ÖBS'de her bir kullanıcıya kullanıcı numarası ve şifre verilip kullanıcı bu numara ve şifre ile sisteme giriş yaptıgında kendi rolüne göre yetkileri belirlenir. Kullanıcı işlem yaparken de bu oturum bilgilerinden yararlanır. Kullanıcının numarası ve oturum bilgisi ayrı bir veri modelinde tutulur. Sistemde her ögrencinin aldıgı derslerin listesi bulunur. Benzer şekilde her bir derse kayıtlı ögrencilerin de numaraları tutulmak istenmektedir. Bu gereksinime göre ders kodu ve ögrenci numarası gibi ikilileri saklayan bir veri modeli bulunmalıdır. Özellikle ders-ögrenci ilişkilerinin yogun oldugu ders kayıt ve ekle-sil haftalarında bu yapının işlem hacminin artması ile sistem beklemelerinin en düşük düzeyde tutulması gerekmektedir. Bu kapsamda hızlı, esnek ve veri boyutu uyarlanabilir bir veri modeli kullanılmalıdır. En az karmaşıklıga sahip ve hızlı cevap verme gereksinimi söz konusu oldugunda çözüm olarak anahtar-deger veritabanı yaklaşımı önerilir.</p><p>Sütun Veritabanı Gereksinimi Sütun veritabanları verilere hızlı erişim saglamakta ve özel sorgu setlerini desteklemektedir. Bu nedenle sütun veritabanlarından faydalanabilmek için, uygulamada çalışan genel sorguları eniyileyen sütun aileleri tasarlanmalıdır. ÖBS'de ögrencilere ait dersler ve notların bir arada tutulması gerekir. Her ne kadar tablo yapısı olarak ilişkisel veritabanına benzese de, ilişkisel veritabanında yer alan bir tablonun aksine, sütun ailesi içinde sütunlar, her satır için degişmez bir şemaya uymak zorunda degildir. Sütun ailesi anahtar-deger çiftlerinin haritası gibi düşünülürse, ögrenciler için ders notlarının bir arada tutulması istenen veriye dogrudan erişimi saglayacaktır.</p><p>C ¸izge Veritabanı Gereksinimi ÖBS'de; ögrencilerin birbirlerini takip etme durumu, ögretim üyeleri ile olan danışmanlık ve takip ilişkileri, derse kayıtlanma ilişkileri, ögretim üyelerinin ders verme ilişkileri, ögrencilerin ve ögretim üyelerinin sosyal ag hesaplarına ilişkin sayfaları bulunmaktadır. Bu verilere ve ilişkilere uygun bir çözüm çizge veritabanı olarak öngörülebilir. Buna göre ögrenciler, ögretim üyeleri, dersler ve bölümler çizgedeki dügümlere karşılık gelmektedir. Bu dügümlerin her birinin kendine özgü özellikleri bulunmakta ve dügümlerin de birbirleri ile ilişkileri yer almaktadır.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.2">Durum C ¸alışması Tasarımı</head><p>Tasarlanan bilgi sisteminde ihtiyaç duyulan farklı veri modellerini kullanan servisleri yönetebilmek için bir üst modele ihtiyaç vardır. ÖBS'nin dayandıgı bu üst modelde bilgi sistemindeki hangi veri modelinin hangi servis(ler) ile baglantılı oldukları ve bu veri modellerinin birlikte çalışabilirliginin nasıl yönetilecegi tanımlanmalıdır. Öncelikle üst modelde tanımlı eşlemeye göre, sistemde birbirleri ile ilişkili ve geçişlere sahip modüllerin belirleyici özelliklerinin eşlemeleri ayrı bir anahtar-deger veritabanında tutulmalıdır. İkinci olarak üst modelde gelen isteklerin ilişkili modüllere iletilmesini saglayan bir yönetim mekanizması yer almalıdır. Böylece bilgi sistemine gelen istekler tiplerine göre uygun modül ile ilişkilendirilebilir. Tasarlanan bu üst model için ontolojik bir yaklaşım uygundur. Üst-Nesne C ¸erçevesi <ref type="bibr" target="#b14">[15]</ref> açısından düşünüldügünde tasarlanan mimarinin M2 ve M1 katmanları açısından incelenmesi gerekir.   Ögrenci Bilgi Sistemi'nin melez veri modeli gerekliligi birden fazla veri modelini ilgilendiren karmaşık sorgularda ortaya çıkmaktadır. ÖBS'ye gelen karmaşık sorgu S ¸ekil 3'teki ontolojik gösterimdeki eşlemelere <ref type="bibr" target="#b16">[17]</ref> göre ayrıştırılarak sorguların işletilecegi alt modüller belirlenir. Her bir alt sorgunun işletilmesiyle elde edilen sonuçlarının anahtar-deger eşlemeleri S ¸ekil 4'teki gibi elde edilir. Ara sonuçlar baglantılı oldugu modüle eşlenir ve bu modülde çalıştırılacak olan baglı sorgu oluşturulur. Bu mantıkla sorgular zincirleme şekilde son alt sorguya kadar işletilir ve sonuç olarak karmaşık sorgunun cevabı elde edilir.</p><p>Örnegin ÖBS'de bir ögrencinin aldıgı dersleri veren ögretim üyelerinin sosyal ag bilgilerine erişilmek istensin. Bu karmaşık sorgu ontolojik gösterimine göre çözümlenerek kayıtlanılan dersler, ögretim üyeleri bilgileri ve sosyal ag bilgileri olmak üzere üç alt sorguya ayrılır. Öncelikle kayıtlanılan ders bilgileri anahtardeger veritabanından getirilir. Kayıtlanılan dersi veren ögretim üyelerine olan baglantı ontolojik gösterime göre elde edilir ve bu baglantı ilişkisel veritabanı olarak bulunur. İlişkisel veritabanına olan baglantı anahtar-deger veritabanı dönüşümü üzerinden yapılır ve ögretim üyelerine ait bilgiler elde edilir. Ontoloji gösterimindeki ilişkilere göre ögretim üyelerinin sosyal ag bilgileri çizge veritabanı üzerinden bulunur. Ögretim üyelerinin bilgileri anahtar-deger dönüşümü ile eşlenir ve sosyal ag bilgilerini elde etmek için çizge veritabanında çalıştırılacak sorgu oluşturulur. Oluşturulan sorgu çizge veritabanında işletilerek gerekli bilgiler elde edilir.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.3">Durum C ¸alışması Modülleri</head><p>Sosyal Ag C ¸izgesi Modülü Ögrenciler, ögretim üyeleri, dersler gibi dügümlerin ve birbirleri arasındaki ilişkiler için çizge veritabanı uygun bir yaklaşımdır. S ¸ekil-4.a'da ÖBS'deki örnek bir verinin çizge veritabanı üzerindeki temsili ve anahtardeger veritabanına dönüştürülmüş hali görülmektedir. ÖBS üzerinden sosyal ag çizgesi modülüne gelen istekler modül tarafından ele alınarak işlem tipi belirlenir. İşlem tipi dolaşma veya sorgu olmasına göre çizge servisi üzerine farklı şekillerde yönlendirilir. Eger istek dolaşma ise çizge servisinin dolaşma özelliginin kullanılması için kullanıcı servis arayüzü üzerine yönlendirilir.</p><p>Özgeçmiş ve Ders Bilgileri İçin Doküman Veritabanı Modülü Dinamik bir yapıya sahip olan özgeçmiş ve ders bilgilerinin tutulması için doküman veritabanı seçilerek artan/azalan alanlar ve farklı biçimlere sahip şemalar için performanslı bir çözüm önerilmiştir. Özgeçmiş kayıtları ve ders bilgileri birbirlerine göre farklılıklar gösterdigi için veri tekrarları ya da boş alanlar olmadan doküman veri modeli olarak saklanmaktadır. İhtiyaç duyuldugunda kayda doküman olarak ulaşılabildigi gibi, dokümanın alt alanlarına da verilen etiket adıyla ulaşılarak arama işlemi gerçekleştirilebilmektedir. Ögrenci ve Ögretim Üyesi Bilgileri İçin İlişkisel Veritabanı Modülü Ögrenci ve ögretim üyesi bilgileri yapısal olarak degişiklik göstermeyen ve birbiri ile baglantılı veriler oldugundan ilişkisel veritabanında tutulur. İlişkisel veritabanında bir veya birkaç adımda erişilecek veri için, anahtar-deger veritabanında pek çok adım gerekebilir. S ¸ekil 4.e'de ilişkisel veritabanı üzerinde, S ¸ekil 4.f'de ise anahtar-deger veritabanı üzerinde ögrenci ve ögretim üyesi tabloları temsili olarak gösterilmiştir. Ögrenci ve ögretim üyesine ait kişisel bilgiler için ise ayrı bir tablo yaratılmış, ögrenci ve ögretim üyesi tabloları ilişkilendirilmiştir.</p><p>Sütun Veritabanı Modülü ÖBS için geliştirilen sütun veritabanı yapısında süper sütun adı statik olarak " Ögrenci Notları" olarak belirlenmiştir. Ancak yapı geregi ögrenciler ve aldıkları dersler için gerekli olan sütun adları dinamik olarak tutulmaktadır. S ¸ekil 4.g'de ögrenciler ve her birinin kayıtlandıkları ders ve derse ait notlar belirtilmiştir.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.4">Durum C ¸alışması Teknolojileri</head><p>İlişkisel Veritabanı Servisi Bulut üzerinde yer alan bir ilişkisel veritabanının kolay bir şekilde kurulması, çalıştırılması saglayan web servisleridir. Klasik ilişkisel veritabanından farklı olarak, maliyet açısından verimlidir ve yeniden boyutlandırılabilmektedir. Ayrıca, otomatik yedekleme ve hata denetimi, yazılım düzeltmeleri, geri yükleme işlemleri ve güvenli erişim alanlarının yönetilmesine imkan saglar <ref type="bibr" target="#b17">[18]</ref>. Amazon RDS <ref type="bibr" target="#b18">[19]</ref>, Microsoft SQL Azure <ref type="bibr" target="#b19">[20]</ref> ve Google Cloud SQL <ref type="bibr" target="#b20">[21]</ref> servisleri ile ilişkisel veritabanı hizmetleri kullanılabilir.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Doküman Veritabanı Servisleri</head><p>ÖBS'de, ögretim üyesi özgeçmiş bilgileri ve ders bilgileri için doküman tabanlı veri modelinin kullanılması uygun görülmüştür. Kayıt içindeki alanların farklılık gösterdigi durumlarda verilerin ilişkisel modelde tutulması veri tekrarlarına veya hücrelerin boş kalmasına sebep olabilir. Farklı tablolarda tutulmasının sonucu olarak birleştirme maliyeti ortaya çıkabilir. Doküman veritabanı hizmetlerinin servis olarak kullanabilecegi teknolojilere MongoDB <ref type="bibr" target="#b21">[22]</ref> on Amazon EC2 <ref type="bibr" target="#b22">[23]</ref> ve Google Cloud Platform <ref type="bibr" target="#b23">[24]</ref> örnek verilebilir.</p><p>Anahtar-Deger Veritabanı Servisleri ÖBS'de oturum bilgileri kullanıcı adı ve şifre şeklinde tutulur. Anahtar-deger veritabanı yapısı ile paralellik saglanarak tasarlanan sistemin hızının artırılması planlanmaktadır. Ayrıca kayıt zamanlarının da yogunlugu göz önünde bulunduruldugunda ögrenci-ders ikilisinin saklanması da uygun olabilir. Anahtar-deger veritabanı yapısı ile kayıt zamanlarında sistemin kapasitesi artırılarak uyarlanabilir veri boyutu saglanacak, sistemde beklemeler en düşük seviyeye indirgenecektir. Bu kapsamda kullanılabilecek anahtar-deger veritabanı servislerine Amazon DynamoDB <ref type="bibr" target="#b24">[25]</ref> ve Google BigTable <ref type="bibr" target="#b25">[26]</ref> üzerinde çalışan MapReduce <ref type="bibr" target="#b26">[27]</ref> örnek olarak verilebilir.</p><p>Sütun Veritabanı Servisleri ÖBS'de ögrencilere ait ders notları Cassandra <ref type="bibr" target="#b27">[28]</ref>'da tutulmaktadır. Satır ve sütunlardan oluşan çizelge şeklinde verilerin tutulabilir ve sütunlar, sütun ailesi olarak adlandırılan gruplara ayrılabilir. Sütun veritabanında her satır bir anahtar içerir ve bu anahtara göre veri getirilir. ÖBS kapsamında sütun veritabanı kullanılarak ögrenci bilgisi ve ders bilgisinin iki sütun ailesinde tutulması düşünülmüştür. Böylece çok kullanılacagı düşünülen, ögrencilerin ders ve sonuç bilgileri bir arada tutularak daha az okuma işlemiyle bu bilgilere erişilebilmektedir.</p><p>C ¸izge Veritabanı Servisleri ÖBS'de kullanılacak çizge veritabanının servis olarak sunması göz önünde bulundurularak Graphenedb <ref type="bibr" target="#b28">[29]</ref> seçilmiştir. Neo4j [30]'nin destekledigi biçimde tutulan veriler Graphenedb ile de saklanabilmektedir. REST servisi üzerinden bir baglantı adresi, kullanıcı adı ve şifre ile saklanan verilere erişilir. Ayrıca mevcut çizge yapısı bir arayüz ile sorgulanabilmekte, gezilebilmekte ve güncellenebilmektedir. C ¸izgenin görsel temsili de kullanıcılar açısından anlaşılmasına ve gezilebilmesine olanak saglamaktadır.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4">Sonuç</head><p>Bu çalışmada büyük veri gereksinimlerine uygun veri modellerinin mimari yaklaşımları ele alınmıştır. Aynı anda birden çok mimariye olan gereksinime deginilmiş ve örnek bir durum çalışması oluşturulmuştur. Bu durum çalışması için melez bir veri modeli mimarisi önerilmiştir. ÖBS örnek mimarisinin gerçekleştiriminde tercih edilebilecek büyük veri teknolojileri ve bunları servis olarak sunan çözümler de ele alınmış ve bunların ileride hibrit modelin gerçekleştiriminde ne şekilde kullanılacagına ışık tutulmuştur.</p><p>İşlevsel fonksiyonlar kapsamlı bir şekilde gerçekleştirilmek istense de tüm veri erişim senaryoları tahmin edilemeyebilir. Bu çalışmada sunulan tasarımda istisna durumlar göz ardı edilebileceginden, gerçekleştirim aşamasında çok çeşitli kalıcılık önemli hale gelmektedir. Yönetim modelinin düzgün bir şekilde gerçekleştirilmesi ve bu modeli kullanan bir veri yönetim katmanının uygulama bazında oluşturulması büyük önem taşımaktadır. Veri yönetim katmanı sayesinde farklı veri modelleri arasında iletişim ve tutarlılık saglanıp ihtiyaca yönelik uygun veri modeli yaklaşımından faydalanan bir veri yönetim sistemi gerçeklenmiş olacaktır. İlerleyen aşamada önerilen mimarinin gerçekleştirimi yapılacak ve okuma-yazma sorgu performansları mevcut veri modelleriyle karşılaştırılacaktır.</p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head>Fig. 1 .</head><label>1</label><figDesc>Fig. 1. Büyük Veri Modeli Taslagı</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_1"><head>Fig. 2 .</head><label>2</label><figDesc>Fig. 2. Durum C ¸alışmasının Tasarımı</figDesc><graphic coords="7,134.77,365.27,350.50,123.00" type="bitmap" /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_2"><head>Fig. 3 .</head><label>3</label><figDesc>Fig. 3. Büyük Veri Modelinin Gösterimi</figDesc><graphic coords="8,174.68,116.83,266.00,168.00" type="bitmap" /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_3"><head>Fig. 4 .</head><label>4</label><figDesc>Fig. 4. Örnek Veri Modellerinin Anahtar-Deger Veritabanı Üzerinde Temsilleri</figDesc><graphic coords="9,166.15,321.35,283.05,294.30" type="bitmap" /></figure>
		</body>
		<back>
			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<analytic>
		<title level="a" type="main">A view of cloud computing</title>
		<author>
			<persName><forename type="first">Michael</forename><surname>Armbrust</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Armando</forename><surname>Fox</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Rean</forename><surname>Griffith</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Anthony</forename><forename type="middle">D</forename><surname>Joseph</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Randy</forename><surname>Katz</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Andy</forename><surname>Konwinski</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Gunho</forename><surname>Lee</surname></persName>
		</author>
		<author>
			<persName><forename type="first">David</forename><surname>Patterson</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Ariel</forename><surname>Rabkin</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Ion</forename><surname>Stoica</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Matei</forename><surname>Zaharia</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Commun. ACM</title>
		<imprint>
			<biblScope unit="volume">53</biblScope>
			<biblScope unit="issue">4</biblScope>
			<biblScope unit="page" from="50" to="58" />
			<date type="published" when="2010-04">April 2010</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<monogr>
		<title level="m" type="main">The nist definition of cloud computing</title>
		<author>
			<persName><forename type="first">Peter</forename><surname>Mell</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Tim</forename><surname>Grance</surname></persName>
		</author>
		<imprint>
			<date type="published" when="2011">2011</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<monogr>
		<author>
			<persName><forename type="first">James</forename><surname>Manyika</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Michael</forename><surname>Chui</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Brad</forename><surname>Brown</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Jacques</forename><surname>Bughin</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Richard</forename><surname>Dobbs</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Charles</forename><surname>Roxburgh</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Angela</forename><forename type="middle">Hung</forename><surname>Byers</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Mckinsey</forename><surname>Global Institute</surname></persName>
		</author>
		<title level="m">Big data: The next frontier for innovation, competition, and productivity</title>
				<imprint>
			<date type="published" when="2011">2011</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b3">
	<monogr>
		<title level="m" type="main">Principles of Big Data: Preparing, Sharing, and Analyzing Complex Information</title>
		<author>
			<persName><forename type="first">Jules</forename><forename type="middle">J</forename><surname>Berman</surname></persName>
		</author>
		<imprint>
			<date type="published" when="2013">2013</date>
			<publisher>Morgan Kaufmann Publishers Inc</publisher>
			<pubPlace>San Francisco, CA, USA</pubPlace>
		</imprint>
	</monogr>
	<note>1st edition</note>
</biblStruct>

<biblStruct xml:id="b4">
	<analytic>
		<title level="a" type="main">3d data management: Controlling data volume, velocity and variety</title>
		<author>
			<persName><forename type="first">Douglas</forename><surname>Laney</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">META Group Research Note</title>
		<imprint>
			<biblScope unit="volume">6</biblScope>
			<date type="published" when="2001">2001</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b5">
	<analytic>
		<title level="a" type="main">Scalable sql and nosql data stores</title>
		<author>
			<persName><forename type="first">Rick</forename><surname>Cattell</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">SIGMOD Rec</title>
		<imprint>
			<biblScope unit="volume">39</biblScope>
			<biblScope unit="issue">4</biblScope>
			<biblScope unit="page" from="12" to="27" />
			<date type="published" when="2011-05">May 2011</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b6">
	<monogr>
		<title level="m" type="main">NoSQL distilled : a brief guide to the emerging world of polyglot persistence, chapter Polyglot Persistence</title>
		<author>
			<persName><forename type="first">J</forename><surname>Pramod</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Martin</forename><surname>Sadalage</surname></persName>
		</author>
		<author>
			<persName><surname>Fowler</surname></persName>
		</author>
		<imprint>
			<biblScope unit="page" from="133" to="134" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b7">
	<analytic>
		<title level="a" type="main">Nextgen data persistence pattern in healthcare: Polyglot persistence</title>
		<author>
			<persName><forename type="first">Srikrishna</forename><surname>Prasad</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Sha</forename><surname>Nunifar</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Fourth International Conference on Computing, Communications and Networking Technologies (ICCCNT)</title>
				<imprint>
			<publisher>IEEE</publisher>
			<date type="published" when="2013">2013. 2013</date>
			<biblScope unit="page" from="1" to="8" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b8">
	<analytic>
		<title level="a" type="main">A relational model of data for large shared data banks</title>
		<author>
			<persName><forename type="first">E</forename><forename type="middle">F</forename><surname>Codd</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Commun. ACM</title>
		<imprint>
			<biblScope unit="volume">13</biblScope>
			<biblScope unit="issue">6</biblScope>
			<biblScope unit="page" from="377" to="387" />
			<date type="published" when="1970-06">June 1970</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b9">
	<monogr>
		<title level="m" type="main">Big Data Application Architecture Q&amp;A: A Problem -Solution Approach</title>
		<author>
			<persName><forename type="first">Nitin</forename><surname>Sawant</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Himanshu</forename><surname>Shah</surname></persName>
		</author>
		<imprint>
			<date type="published" when="2013">2013</date>
			<publisher>Apress</publisher>
			<pubPlace>Berkely, CA, USA</pubPlace>
		</imprint>
	</monogr>
	<note>1st edition</note>
</biblStruct>

<biblStruct xml:id="b10">
	<analytic>
		<title level="a" type="main">10 rules for scalable performance in &apos;simple operation&apos; datastores</title>
		<author>
			<persName><forename type="first">Michael</forename><surname>Stonebraker</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Rick</forename><surname>Cattell</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Commun. ACM</title>
		<imprint>
			<biblScope unit="volume">54</biblScope>
			<biblScope unit="issue">6</biblScope>
			<biblScope unit="page" from="72" to="80" />
			<date type="published" when="2011-06">June 2011</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b11">
	<monogr>
		<ptr target="http://blog.foundationdb.com/video-recap-solving-the-nosql-data-modeling-dilemma" />
		<title level="m">Solving the nosql data modeling dilemma</title>
				<imprint>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b12">
	<monogr>
		<title/>
		<author>
			<persName><surname>Foundationdb</surname></persName>
		</author>
		<ptr target="https://foundationdb.com" />
		<imprint>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b13">
	<monogr>
		<title/>
		<author>
			<persName><surname>Arangodb</surname></persName>
		</author>
		<ptr target="https://www.arangodb.com" />
		<imprint>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b14">
	<monogr>
		<ptr target="http://www.omg.org/mof/" />
		<title level="m">Meta-Object Facility</title>
				<imprint>
			<publisher>MOF</publisher>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b15">
	<analytic>
		<title level="a" type="main">Ontology-based integration of information-a survey of existing approaches</title>
		<author>
			<persName><forename type="first">Holger</forename><surname>Wache</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Thomas</forename><surname>Voegele</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Ubbo</forename><surname>Visser</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Heiner</forename><surname>Stuckenschmidt</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Gerhard</forename><surname>Schuster</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Holger</forename><surname>Neumann</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Sebastian</forename><surname>Hübner</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">IJCAI-01 workshop: ontologies and information sharing</title>
				<imprint>
			<publisher>Citeseer</publisher>
			<date type="published" when="2001">2001. 2001</date>
			<biblScope unit="page" from="108" to="117" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b16">
	<analytic>
		<title level="a" type="main">A survey on ontology mapping</title>
		<author>
			<persName><forename type="first">Namyoun</forename><surname>Choi</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Il-Yeol</forename><surname>Song</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Hyoil</forename><surname>Han</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">SIGMOD Rec</title>
		<imprint>
			<biblScope unit="volume">35</biblScope>
			<biblScope unit="issue">3</biblScope>
			<biblScope unit="page" from="34" to="41" />
			<date type="published" when="2006-09">September 2006</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b17">
	<monogr>
		<ptr target="http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html" />
		<title level="m">Amazon RDS Documentation</title>
				<imprint>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b18">
	<monogr>
		<title/>
		<author>
			<persName><forename type="first">Rds</forename><surname>Amazon</surname></persName>
		</author>
		<ptr target="http://aws.amazon.com/rds/" />
		<imprint>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b19">
	<monogr>
		<ptr target="http://azure.microsoft.com/tr-tr/services/sql-database/" />
		<title level="m">Microsoft SQL Azure</title>
				<imprint>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b20">
	<monogr>
		<ptr target="https://cloud.google.com/sql/" />
		<title level="m">Google Cloud SQL</title>
				<imprint>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b21">
	<monogr>
		<ptr target="https://www.mongodb.org/" />
		<title level="m">mongoDB</title>
				<imprint>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b22">
	<monogr>
		<ptr target="http://aws.amazon.com/ec2/" />
		<title level="m">Amazon Elastic Compute Cloud (EC2</title>
				<imprint>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b23">
	<monogr>
		<ptr target="https://cloud.google.com/" />
		<title level="m">Google Cloud Platform</title>
				<imprint>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b24">
	<monogr>
		<title/>
		<author>
			<persName><forename type="first">Amazon</forename><surname>Dynamodb</surname></persName>
		</author>
		<ptr target="http://aws.amazon.com/dynamodb/" />
		<imprint>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b25">
	<monogr>
		<ptr target="https://cloud.google.com/bigtable/" />
		<title level="m">Google Big Table</title>
				<imprint>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b26">
	<monogr>
		<ptr target="http://hadoop.apache.org/docs/r1.2.1/mapred_tutorial.html" />
		<title level="m">Hadoop Map Reduce</title>
				<imprint>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b27">
	<monogr>
		<ptr target="http://cassandra.apache.org/" />
		<title level="m">Apache Cassandra</title>
				<imprint>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b28">
	<monogr>
		<title/>
		<author>
			<persName><surname>Graphenedb</surname></persName>
		</author>
		<ptr target="http://www.graphenedb.com/" />
		<imprint>
			<date type="published" when="2015">2015</date>
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
