İngilizce Metin: https://o-date.github.io/draft/book/arranging-and-storing-data-for-the-long-haul-databases.html
🔧 Launch the Databases Binder. Database Binder’ı başlatın
Planınıza ve yapınıza göre verilerinizi bir kez topladıktan sonra, tamamını sizin ve diğer araştırmacıların bir süre daha kullanabilmesini sağlayacak şekilde birbirine bağlamanın bir yolunu bulmanız gerekecektir. Bu ders kitabı “dijital arkeoloji” hakkında olduğundan, dijital verilerinizin doğası oldukça değişken olabilir. Fiziksel bir kazıdan elde edilen bilgilerle çalışıyor olabilirsiniz ya da kazıdan birkaç derece uzakta ve mevcut araştırma verilerini bir araya getirmek için çalışıyor olabilirsiniz. Okumaya devam ederken farklı çerçeve olasılıklarını göz önünde bulundurmalısınız.
Peki veritabanı nedir ve hangi tür veritabanı kullanmalısınız?
Format seçimi:
Pek çok insanın iyi veritabanı platformları, kötü olanlar ve bu ikisi arasında kalanlar hakkında pek çok fikri vardır. Ancak bunun evrensel olarak doğru kabul edilen bir cevabı yoktur ve pek çok şey teknik kaynaklara ve deneyim düzeyine bağlıdır. Başka deyişle, birçok durumda ilişkisel bir veritabanı en güçlü seçenektir, ancak, elektronik tablolarda bilginin iyi işlenmesi, veritabanı iyi uygulandığı takdirde sizin ve diğer araştırmacıların ihtiyaçlarını karşılayabilir. Kuruluşlarımız kullanmamıza izin verilen yazılım platformlarını dikte edebilir, bunlar genellikle Microsoft Access veya Excel’dir.
Kararınızı verilerinizin karmaşıklığına göre verebilirsiniz. Kazı birimleri, özellikler ve eserler hakkında çok sayıda iç içe geçmiş bilgi içeren saha verileriyle mi çalışıyorsunuz? Yoksa araştırma yoluyla topladığınız değerlerin daha basit bir listesini mi saklıyorsunuz?
Her proje için geçerli olan mükemmel bir format seçimi yoktur, ancak akılda tutulması gereken bazı dengeler vardır. Seçimlerinizde işbirliği yapanların sayısı, internet bağlantısı, saha tabletleri gibi donanımların varlığı ve yazılım uyumluluğu gibi hususlar dikkate alınabilir.
Flat tables (Düz Tablolar)
Dijital veri oluşturan birçok kişinin ilk durağı, toplanan değerleri elektronik bir tabloya koymaktır. Elektronik tablolar, metin ve sayısal değerleri anlamlı şekillerde düzenlemek için hızlı ve kolay araçlardır.
Excel
Saha arkeolojisinde, kazı verilerinin ve eser kataloglarının Excel elektronik tablolarında saklandığını görmek son derece yaygındır. Microsoft Excel çoğu bilgisayarda standart olarak gelir ve birçok ofis ortamında hazır bulunur. Excel’in çok fazla gücü vardır, ancak artı ve eksilerine dikkat edilmesi gerekir.
Artıları
Excel ve benzeri elektronik tablo uygulamalarının cazibesi kolay olmalarında yatmaktadır. Çok az miktarda teknik bilgi ile yapılandırılmış veri koleksiyonlarının oluşturulması, bazen doğrudan bir çalışma kitabında formüller ve grafikler aracılığıyla karmaşık analitik işlemlerin gerçekleştirilmesi mümkündür.
Eksiler
Excel akıllı olmaya çalışırken bazen aşırıya kaçar. Bunun en iyi örneği Excel’in tarihleri otomatik biçimlendirme eğilimidir. Excel’in tarihleri işleme yöntemi, 8/1/2018 (yazar Amerikalı olduğu için 1 Ağustos) gibi bir şeyi 43311 seri numarasına dönüştürmektir. Tuhaf, değil mi? Daha da tuhaflaşıyor. Excel bu numaraları atamak için 1900 tarih sistemini kullanır. Bu seri numarası, 1 Ocak 1900 ile girilen tarih arasındaki gün sayısını temsil eder. Bu, sadece 1900’den önceki tarihlerle çalışan bizler için zor olmakla kalmaz, ayrıca, tarih olmayan şeyleri tarih değerlerine dönüştürerek bu tarih seri numaralarına benzeyen sayı değerleri için de sorunlara neden olabilir. Aslında, Excel tarih olabilecek her türlü kalıbı arar ve bunları dönüştürür. Bu, genetikle ilgili verilerde önemli bir sorun haline gelmiştir. Bkz (Ziemann, Eren ve El-Osta 2016). Bu tür hatalara karşı bir önlem, Excel’de metin olarak biçimlendirilebilecek tarihlere benzeyen değerleri içerebilecek herhangi bir sütunun manuel olarak biçimlendirilmesidir. Ya da bu kadar önemli bir şey için Excel kullanmamaktır.
Excel, başkaları dosyaya erişmeye çalıştığında bozulabilecek çok sayıda formül akrobasisi olmadan veri girişini kısıtlamayı veya standartlaştırmayı zorlaştırır. Seçim listelerinden seçim yapma gibi kontroller olmadan elektronik tablolarda veya düz metin formatlarında çalışırken yazım hatalarına ve biçimlendirme sorunlarına karşı dikkatli olunmalıdır.
Anlamlı bilgileri renk kodları veya kalın metin gibi biçimlendirmelerle saklamak cazip gelse de, çok kötü bir fikirdir. Biçimlendirmeler, yazılım sürümleri ve uygulamalar arasında kolayca bozulabilir.
Özellikle Excel’in sürüm kontrolünü yapmak ya da zaman içindeki değişikliklerin geçmişini takip etmek son derece zordur. Düz metin ve açık formatlar genellikle çok daha kolay sürüm kontrolüne ve yaşam süreleri boyunca verilerle birlikte taşınan değişiklikler hakkındaki metaverilere izin verir (daha fazla bilgi için Git ve sürüm kontrolü hakkındaki ODATE bölümüne bakınız).
Virgül veya Sekme ile ayrılmış metin dosyaları (.csv, .tsv, .txt)
Artıları
Bu tür metin dosyaları veri depolamanın en basit yollarından ve dolayısıyla en dayanıklı olanlarından bazılarıdır. Bunlar Excel veya Google E-Tablolar gibi elektronik tablo programlarında tablo olarak açılabilirken, içerisindeki bilgiler düz metin düzenleyicisinde okunmaya devam edebilir. Altta yatan çok karmaşık bir yapı olmadığından, bu tür düz metin dosyalarının sürüm kontrolünü yapmak veya dosyanın ömrü boyunca yapılan değişikliklerle ilgili bilgileri saklamak ve görüntülemek çok kolaydır. Çoğu durumda, elektronik tablo verilerinde çalışmanız ve bunları kaydetmeniz gerekiyorsa, Excel veya diğer biçimler yerine bu biçimlerden birini seçin. (CSV veya TSV dosyanızda tarihler varsa ve Excel kullanarak kaydederseniz, biçimlendirmenizi bozabilir. Tarih sütunlarınızın Metin olarak biçimlendirildiğinden emin olunuz).
Eksiler
Bir dereceye kadar düz metin dosyalarını kullanırken biçimlendirme üzerinde daha az kontrol sahibi olabilirsiniz (ancak bu hata değil, bir özelliktir).
Verilerin düzenlenmesinde elektronik tabloların kullanılması konusunda harika tavsiyeler için Karl Broman ve Kara Woo Broman ve Woo (2018) tarafından The American Statistician‘da yayınlanan bu yararlı makaleye bakınız.
Topladığınız verileri doğrudan düz tablolara yerleştirmek oldukça kolay ve verimli olabilir. Bir insan için elektronik tabloyu açmak ve okumak oldukça kolaydır. Bunlar muhtemelen verileri bu şekilde depolamanın en büyük avantajlarıdır.
Ancak, veriler düz dosyalarda bulunuyorsa, bu verilerin bir araya nasıl geldiğini açıklamak zor olabilir – her alanı açıklayan meta veriler başka bir dosyada saklanmalıdır. Tutarsızlıkları ortadan kaldırmak için herhangi bir kontrol yapılmazsa, veri girişi verimsiz ve hataya açık olabilir. Ayrıca hata ve yazım yanlışları yapmak da çok kolaydır. Not: Excel’deki değerler DÜŞEYARA gibi işlevlerle ilişkilendirilebilir ve girdi maskeleriyle kısıtlamalar ayarlanabilir, ancak bu, bu tür geliştirmelerin istikrarsızlığı nedeniyle yapmanız gerektiği anlamına gelmez. Kendinizi bu tür davranışların çoğunu uygularken buluyorsanız, diğer veritabanı türlerine bakmak için iyi bir işarettir.
JSON ve XML
Araştırma verilerinizi başından itibaren doğrudan bu formatlara girmeyecek olsanız da (ve girmemeniz gerekse de), birçok web kaynağı verileri tutmak için JSON (JavaScript Object Notation) veya XML (Extensible Markup Language) belgelerini kullanır. JSON ve XML, düz metin belgelerini bilgisayarların (ve insanların) hiyerarşiyi ve veriler arasındaki ilişkileri anlamasını sağlayacak şekilde yazmaya yarayan formatlardır.
JSON şöyle görünür (kaynak):
{
"firstName": "John",
"lastName": "Smith",
"isAlive": true,
"age": 27,
"address": {
"streetAddress": "21 2nd Street",
"city": "New York",
"state": "NY",
"postalCode": "10021-3100"
},
"phoneNumbers": [
{
"type": "home",
"number": "212 555-1234"
},
{
"type": "office",
"number": "646 555-4567"
},
{
"type": "mobile",
"number": "123 456-7890"
}
],
"children": [],
"spouse": null
}XML şu şekilde görünür:
<?xml version="1.0" encoding="ISO8859-1" ?> <CATALOG> <CERAMIC_TYPE> <NAME>Pearlware</NAME> <MATERIAL>Refined Earthenware</MATERIAL> <MANU_TECH>Press Molded</MANU_TECH> <EXT_INT_SURFACE>Lead Glazed</EXT_INT_SURFACE> </CERAMIC_TYPE> <CERAMIC_TYPE> <NAME>Faience</NAME> <MATERIAL>Refined Earthenware</MATERIAL> <MANU_TECH>Wheel Thrown</MANU_TECH> <EXT_INT_SURFACE>Tin Glaze</EXT_INT_SURFACE> </CERAMIC_TYPE> </CATALOG>
Bazı kod benzeri biçimlendirmeleri görebileceğinizi, ancak yine de içeriği okuyabileceğinizi ve organizasyon hakkında bir fikir edinebileceğinizi unutmayın.
İlişkisel veritabanları
İlişkisel bir veritabanı, bilgisayarlara nesnelerin birbirine nasıl bağlandığını anlatan ilişkilerle birbirine bağlanmış birçok farklı tablodan oluşur. Genel olarak, her tablo bir ‘varlık türünü’ (bağlamlar, eserler, OSL örnekleri, vb.) temsil eder ve satır ve sütunlardan oluşur. Satırlar söz konusu varlık türünün örneklerini (örn. bağlam 0321, AR009876, S112), sütunlar ise bu örneğe atfedilen değerleri (örn. toprak dokusu, kapandığı tarih, hammadde, ayrışma indeksi, vb.) Satırlara kayıt, sütunlara da bazen değişken veya öznitelik adı verilir.
Çoğu ilişkisel veritabanı, gösteriyi yürütmek için SQL’e ya da Yapılandırılmış Sorgu Diline güvenir. Her SQL komutu aslında belirli bir eylemi gerçekleştirmek için gereken tüm parametreleri içeren bağımsız bir mantıksal ifadedir. Eğer bir şey doğru değilse, bir hata bildirilir ve hiçbir sonuç döndürülmez.
Örneğin, aşağıdaki komut, belirtilen tablodan adı geçen iki sütunun içeriğini alır:
SELECT column1, column2, ... FROM table_name;
MS Access gibi masaüstü SQL ofis veritabanı ürünleri, ilişkilerin kurulmasına ve sorguların oluşturulmasına yardımcı olmak için bir grafik kullanıcı arayüzü (GUI) ile birlikte gelir. Aslında GUI kullanılarak gerçekleştirilebilecek her görev, kullanıcıların görüşünden gizlenen SQL komutlarının uygulanmasını maskeler. Bu nedenle verilerinizin perde arkasında nasıl dönüştürüldüğünü daha iyi anlamak için SQL’in temellerini öğrenmek faydalı olacaktır. Farklı veritabanı yönetim sistemleri SQL’in farklı diyalektlerini kullansa da, genellikle aynı temel ilkeleri uygularlar.
Yaygın masaüstü uygulama seçenekleri:
- Microsoft Access
- FileMaker Pro
- Open Office Base
Bu tüketici sınıfı veritabanı uygulamaları SQL veritabanlarına harika bir giriş noktası olabilir, inanılmaz derecede hayal kırıklığına da neden olabilir ve genellikle her ikisi de olabilir. Bu tür uygulamaları kullanarak karmaşık ilişkilere sahip veritabanları oluşturmak nispeten kolaydır. Bu tür bir veritabanı, veri girişinde kısıtlamaları ayarlamada kullanılabilecek entegre formlar oluşturma yeteneği nedeniyle de mükemmel bir seçimdir. Açılır listeleri doldurmak için “yetki tabloları” oluşturabilir ve özel kimlik numaralarında, tarihlerde vb. gerekli kalıpları kontrol etmek için giriş maskeleri ayarlayabilirsiniz.
MS Access kırılganlığıyla bilinir. Birden fazla kullanıcının tek bir veritabanı üzerinde işbirliği yapması zordur. Eski ve yeni yazılım sürümleri arasındaki dönüşüm beklenmedik hatalara neden olabilir.
Sunucu Tabanlı SQL Veritabanları
Veri depolama veya sunma uygulamanız web üzerinde çalışıyorsa, SQL arka ucunuz muhtemelen MySQL, MariaDB veya PosgreSQL gibi bir şeydir. Veritabanı, birden fazla kullanıcının aynı anda erişebileceği bir sunucuda bulunur. Veriler merkezi ve birleşiktir ve bu nedenle kullanıcılar arasında da tutarlıdır.
SQL veritabanları tablolardan oluşmasına rağmen, çoğu ikili dosyalar şeklinde saklanır. Verileri okumak için doğru program olmadan bu dosyaları açmaya çalışırsanız, buna benzer bir şey elde edersiniz:
İkili bir veritabanı dosyasını metin olarak açmak iyi bir fikir değil!
Bu nedenle, bu bilgileri ayrıştırabilen bir yazılım kullanılarak açılmalıdırlar. Kullanıcılar, bir istemci aracılığıyla veritabanının depolandığı sunucuya bağlanarak veritabanını okurlar. Kullanıcılar genellikle sunucu yöneticisi tarafından verilen ve belirli hassas verilere erişimi yönetmek veya kısıtlamak ya da yetkisiz kişilerin verileri düzenleme veya değiştirme yeteneklerini sınırlamak için kullanılan oturum açma kimlik bilgilerini girerler. Veri giriş formları veya otomatik olarak oluşturulan görselleştirmeler veya raporlar genellikle hizmet verdikleri veritabanlarının belirli yönlerini yansıtacak şekilde özel olarak hazırlanır.
Bazı popüler açık kaynak veritabanı istemcileri:
- MySQL Workbench
- Sequel Pro
- Table Plus
- DBeaver
- PostgreSQL
Grafik Veritabanları
Grafik veritabanı nispeten yeni bir gelişmedir. İlişkisel veritabanlarının aksine grafik veritabanı hem ilgilenilen nesneyi hem de bu nesnenin ilgilenilen başka bir nesneyle olan ilişkisini kaydeder.Genellikle bu, insanlara referans verilerek gösterilir; bir kişi tek bir nokta (düğüm) olarak nesneleştirilebilir, bu kişi başka bir kişiyle (başka bir düğüm) ilişkilendirilebilir. Bu ilişki bir çizgi (kenar) olarak modellenir, ilişki istediğiniz herhangi bir şey olabilir; Dave Sue’nun kardeşidir, Dave Sue ile arkadaştır, Sue Dave ile aynı okula gitmiştir.
Bu örneklerin üçü de doğru olabilir, ancak yönlü ilişkiler de olabilir, örneğin Dave Sue’nun kardeşi olabilir, ancak Sue Dave’in Kardeşi olamaz, bu nedenle bu yönlüdür. Bunu iki yönlü bir ilişki haline getirmek için: Dave Sue’nun kardeşidir, Sue da Dave’in kardeşidir. Eğer Sue Dave ile aynı okula gittiyse, bunun tersi de doğru olmalıdır ve arkadaşlıkların da iki yönlü olmasını beklersiniz. Ancak Dave Sue’dan hoşlandıysa bunun tersi doğru olmayabilir.
Matematikte çizge teorisi olarak adlandırılan durumda, tek bir kenarla birbirine bağlanmış iki düğümümüz vardır. Düğümler herhangi bir nesneyi temsil edebilir, nesnenin öznitelikleri olabilir, örneğin: isim, yaş, boy, vb. Arkeolojik bir örnek olarak nesne “eser” olabilir, öznitelikler de esere özgü olmalıdır; sözgelimi “kim tarafından bulunduğu” adlı bir özniteliği olabilir, ancak bir kişi düğümü oluşturmak ve ardından eserin belirli bir kişi tarafından bulunduğunu belirtmek için bir ilişki veya kenar kullanmak daha iyi olacaktır. Eğer bir kişi birçok eser bulduysa, o zaman diğer birçok eser düğümüyle birleştirilecektir.
Bu, Ağ Analizi ve nesne-yüklem-özne veri yapısını kullanan nesne yönelimli yaklaşımlarda bulunan benzer bir kavramdır.
Grafik veritabanlarının kendi sorgu dilleri vardır: cypher. Birçok yönden SQL’e benzer ancak daha da basittir. Grafik veritabanları SELECT ifadesini kullanmak yerine desen eşleştirmeyi kullanır.
MATCH (n)
RETURN n;En basit model tüm düğümleri eşleştirmektir, bir kez eşleştirildiklerinde döndürülmeleri gerekir. Bu, ilgili tüm düğümleri döndürmek için daha da geliştirilebilir.
MATCH (n)-[r]-()
RETURN n, r;Giriş seviyesi grafik veritabanı Neo4J‘dir. İleri düzey bir grafik veritabanı Agensgraph‘tır. Her ikisi de cypher sorgulama dili (query language) ile sorgulanabilir.
2.4.1 Çıkarımlar
İlişkisel veritabanlarının ve düz veri yapılarının artılarını ve eksilerini anlamak için zaman ayırın.
Excel ve elektronik tablo yazılımlarına dikkat edin. Bazen uygundur, ancak riskleri çoktur.
Mümkün olduğunda CSV gibi düz metin formatlarına yönelin.
2.4.2 İleri Okuma
Data Carpentry’den Data Organization in Spreadsheets for Social Scientists
Data Carpentry’den Data Organization in Spreadsheets for Ecologists
Data Carpentry’den SQL for Social Science Data
SSRC labs’dan Thinking about Data
2.4.3 Alıştırmalar
Referanslar
Ziemann, Mark, Yotam Eren, and Assam El-Osta. 2016. “Gene Name Errors Are Widespread in the Scientific Literature.” Genome Biology 17 (1): 177. doi:10.1186/s13059-016-1044-7.
Broman, Karl W., and Woo K. 2018. “Data Organization in Spreadsheets.” The American Statistician 72 (1): 2–10. doi:10.1080/00031305.2017.1375989.