Veri Modelleri ve Mantıksal Modeller
[English below]
Bu yazımda verinin doğasına bağlı olarak farklılaşan ihtiyaçları karşılamak adına oluşturulmuş olan veri modellerinden bahsedeceğim. Her ne kadar yüzeysel bilgiler verecek olsam da konu çok derin ve uzun soluklu bir konu olduğu için de yazımı birkaç parçaya böleceğim. Elbette bu yazılardan tüm konuya bir uzman kadar hakim olmanızı sağlayacak detayda bir bilgi beklememelisiniz. Temelde amacım, her zaman olduğu gibi, ilk aşamada bir fikir edinmenizi sağlamak ve eğer isterseniz konuyu daha derinlemesine araştırabilmeniz için size bir başlangıç noktası verebilmek.
Ayrıca izninizle, bu yazıma özel olarak, bazı terimleri Türkçe’ye çevirsem de anlamsal bütünlüklerini korumak adına İngilizce orijinal isimlerini de yanlarına yazacağım. Hazırsanız buram buram sektör tarihi kokan yazımın ilk parçasıyla başlıyorum…
Veri tabanı yönetim sistemi nedir?
Veri tabanı motoru, veri tabanı sunucusu ya da veri tabanı yöneticisi adına ne derseniz deyin bir veritabanı yönetim sistemi (Database Management System kısaca DBMS), veritabanında veri oluşturmak, okumak, güncelleştirmek ve silmek (create, read, update, delete kısaca CRUD) için kullanılan temel yazılım bileşenidir. Çoğu veritabanı yönetim sistemi, kullanıcı arayüzü yerine kullanıcılarının temel motorlarıyla etkileşime girmesine olanak tanıyan kendi uygulama programlama arayüzünü (API) içerir.
Tüm veri tabanı yönetim sistemleri aynı değil mi?
Nasıl ki siz giyeceklerinizi kıyafet dolabınızda, yemeklerinizi buzdolabınızda ve kitaplarınızı kütüphanenizde saklıyorsanız, doğaları gereği birbirlerinden farklılaşan verileri sakladığınız veri tabanları da birbirlerinden farklılaşacaklardır.
Peki bu farklı yaratan nedir?
Tam bu noktada veri tabanlarının farklılaşmasını sağlayan şey veriyi yazma ve sorgulama ihtiyacınıza bağlı olarak özelleştirilmiş olan veri tabanı yönetim sistemleridir. Bu özelleştirmeler sayesinde DBMSler elinizdeki verinin doğasına uygun olarak yazma ya da okuma önceliklendirmeleri yapabilir, sorgularınızı optimum performansta çalıştıracak en uygun çalıştırma planını (execution plan) oluşturabilirler. Bu sayede işlemci, hafıza ve bellek kullanımlarını optimize ederler. Ayrıca günümüzde sadece veri tabanı yönetim sistemi özelleşmesinin ötesinde fiziksel katmanda donanımsal olarak özelleşmiş sunucuların kullanımı da sözkonusudur. Yani evinizdeki bilgisayarınızda kurguladığınız bir veritabanı o iş için özelleştirilmiş bir sunucu üzerinde çalışan aynı veritabanından çok daha kötü performansla çalışacaktır.
Çoğu veritabanı yönetim sistemi belirli bir data modeli üzerinde çalışacak şekilde özelleşmiş olsalar da günümüz iş gereksinimlerinin çeşitliliği sebebiyle çoklu model destekleyen veri tabanı yönetim sistemlerini daha çok görmeye başladığımız da bir gerçek.
Haydi gelin bu özelleşmiş veri tabanı modellerinin en bilinenlerine ve kullanım alanlarına kısaca göz atalım…
Mantıksal modeller
Hiyerarşik veri modeli (Hierarchical database model)
1960'lı yılların başında IBM tarafından IMS için ağaç yapısında geliştirilmiş ve segment adı verilen yapıları arasında bire çok (one to many) (1-n) ilişki bulunan veri modelidir. Veriler ebeveyn çocuk (parent-child) ilişkisi ile bağlıdır. Bunu daha net anlamanız açısından kardeşinizin ve sizin ancak ve ancak bir anneniz olabilirken annenizin birden fazla (n adet) çocuğu (siz ve kardeşiniz) olabilir şeklinde özetleyebiliriz.
1960'ların başında doğmuş olmasına rağmen günümüzde özellikle yüksek performans ve erişilebilirlik gerektiren bankacılık, sağlık ve telekomünikasyon sistemlerinde halen yaygın olarak kullanılmaktadır. Okuyucuyu şaşırtacak bir detay daha vereyim, eğer Windows işletim sistemi olan bir bilgisayar kullanıyorsanız uygulamalarınızın kayıtlarını tutan Windows Registry de halen bu yapıyı kullanmaktadır. Ne demişler, çalışıyorsa dokunma…
Ağ (Network) veri modeli
1969 yılında kimilerinde modern veritabanı yönetim sistemlerinin babası olarak da kabul edilen Charles Bachman tarafından yazılan bir makale ile ortaya atılan ve 1971'de CODASYL tarafından yayınlanan standartlar ile daha fazla kullanım alanı bulmuş veri modelidir. Hiyerarşik modelin aksine çoka çok (many to many) (n-n) ilişkilerin de kurulabildiği bu model neredeyse kendisiyle eş zamanlı olarak doğan ilişkisel veri tabanlarının popüler hale gelmesi sebebiyle çok yaygınlaşamamıştır.
Benim fikrimce COBOL programlama dilinin standartlarının oluşmasına ön ayak olması ve halen süpermarket kasaları gibi bir ana bilgisayara (mainframe) bağlı mikro iş istasyonları (workstation) bağlı sistemlerde kullanılması sebebiyle sektörde yetişen yeni neslin en azından adını bilmesinde fayda olduğunu düşündüğüm bir veri modelidir. Ayrıca uzak masaüstü uygulamalarının da halen bu alt yapıyı kullandıklarını da bilmenizde fayda var.
COBOL (COmmon Business-Oriented Language) nedir derseniz de özellikle günümüzde hala işletim sistemlerinin büyük çoğunluğunun harcında bulunan ve aynı zamanda her ne kadar artık yavaş yavaş modern yazılım dillerinde çözülmeye başlansa da büyük montanlı verilerin toplu aktarımları ya da işlem kayıtlarının aktarımlarının yapılması için halen kullanılmaya devam eden bu yazılım dili için buraya bakabilirsiniz.
İlişkisel veri modeli (Relational Database Model)
1969 yılında İngiliz bilgisayar bilimci Edgar Frank Codd tarafından temelleri atılan ve verilerin tuple tabir edilen liste benzeri yapılarda ancak değiştirilemez şekilde tutulduğu ve bu liste benzeri yapılar arasında ilişkilerin tanımlandığı veri modelidir. Tanımın çok karışık olduğunun farkındayım. Size bir sır vereyim buradaki liste alışveriş listeniz olmadığı gibi liste benzeri yapıdan kasıt da bildiğimiz veritabanı tablosundan başkası değil. Yani oluşturulan bir tablonun eleman sayısı (satırlar) artsa da yapısının (kolonlar) değişmemesi sebebiyle listeden farklılaşması söz konusudur.
Şuna baştan neden tablo demedin diyenleriniz olacaktır, öncelikle tablo (table) kavramı SQL kullanan ilişkisel veri tabanlarında özne (peridicate) değişkenine karşılık gelir. Ve çoğu ilişkisel veritabanında verileri sorgulamak için SQL kullanıldığı için de tuple ve tablo benzeşimi çok da yanlış sayılmaz. Ancak Codd’un burada belirttiği tuple tanımını daha matematiksel bir yaklaşımda kullandığını da unutmamak gerekir. İkincil olarak programlama yapan okuyucuların tuple kavramına daha aşina olmalarını beklediğimden dolayı aradaki benzeşimi daha iyi yakalayabilmeleri adına bu şekilde ifade etmemin daha doğru olacağını düşünüyorum.
Günümüzde ilişkisel veri modelinin en yaygın kullanılan model olduğunu söylesek çok da yanlış yapmış olmayız. Kullanıcılar ya da uygulamalar veritabanından bir veriyi almak istediklerinde (ki bunu çoğunlukla SQL kodları ile yaparlar) DBMS bir veya gerekli durumda birden fazla tabloyu uygun ilişki kolonlar üzerinden(primary ve foreign key) bağlayarak (join) bir veri seti olarak cevap döner. Bunu yaparken de tablolar arası olası tüm eşleşmeleri hesaplayıp (cartesian product) istenilen koşulları sağlayan verileri filtreleyerek bu sonucu paylaşır.
Yukarıda bahsettiğim diğer modellerden farklı olarak, ilişkisel veri tabanları ilk başlarda 1970'lerde Codd tarafından ortaya atılan üç değerli mantıkla veri hesaplaması yaparken (true, false, null/missing) zamanla değişen ihtiyaçlar sebebiyle 1986 sonrası ortaya çıkan RDBMS 2 ile birlikte kolonda tutulan verileri istenilen koşullar için dört değerli (four-valued logic) hesaplayabilir hale gelmişlerdir. Bunlar, doğru, yanlış, uygulanabilir yokluk, uygulanamaz yokluk (True, False, Missing but Applicable, Missing but Inapplicable) olarak adlandırılır. Daha detaylı bilgi için Codd’un kendi makalesine bakabilirsiniz.
Hatta yeri gelmişken benim tavsiyem kendisinin diğer çalışmalarına da göz atmanız. Zira kendisinin fikirleri sektörün evriminde çok büyük önem taşır. Hatta şöyle bir örnek vereyim, Codd kendi yarattığı ilişkisel veritabanı modelinin potansiyelini IBM müşterilerine gösterdikten sonra IBM müşterilerinin baskısı sebebiyle System-R projesini başlatmış ve Codd’un kendi Alpha dilini kullanmak yerine Donald D. Chamberlin ve Raymond F. Boyce tarafından ilişkisel olmayan bir dil olan SEQUEL’i (Structured English QUEry Language) oluşturmuştur. Yine de, SEQUEL, ilişkisel olmayan sistemlere kıyasla o kadar üstündü ki, 1979'da Larry Ellison kurucusu olduğu Oracle Veritabanı’nda bir kopyasını kullanmıştır. Bu arada orijinal adın telif hakkı nedeniyle SEQUEL’in SQL olarak yeniden adlandırılması gerekmiş ve SQL 1986 yılında Amerikan Ulusal Standartlar Enstitüsü (ANSI) tarafından ve 1987 yılında Uluslararası Standartlar Örgütü (ISO) tarafından bir standart olarak kabul edilmiştir. Halen günümüzde yaygın olarak kullanılmaktadır.
Okuyucuyu daha fazla yormamak adına şimdilik yazının ilk bölümünü burada bitiriyorum. Bir başka yazımda mantıksal veri modellerine kaldığım yerden devam edeceğim.
Data Models and Logical Models
In this article, I will talk about data models that are created to meet the different needs depending on the nature of the data. Although I will provide superficial information, the topic is very deep and long-lasting, so I will divide my writing into a few parts. Of course, you should not expect detailed information that will make you as knowledgeable as an expert from these writings. Basically, my goal, as always, is to give you an idea in the first place and to provide you with a starting point if you want to research the topic more in depth.
If you’re ready, I’m starting with the first part of my article that smells of industry history…
What is a database management system?
A database engine, database server, or whatever you want to call it, a database management system (DBMS for short) is the basic software component used to create, read, update, and delete data in a database (also known as CRUD). Most database management systems include their own application programming interface (API) that allows users to interact with their basic engines, rather than a user interface.
Aren’t all database management systems the same?
Just like you keep your clothes in your closet, your food in your fridge, and your books in your library, the databases where you store different data will naturally differ from each other.
So what creates this difference?
At this point, what makes databases different is the database management systems that are customized depending on your need to write and query data. With these customizations, DBMSs can prioritize writing or reading data according to the nature of the data you have, and create the most suitable execution plan to run your queries at optimum performance. This way, they optimize processor, memory, and memory usage. In addition, nowadays, the use of hardware-specialized servers beyond the customization of the database management system is also possible. In other words, a database that installed on your home computer will run with much worse performance than a server specialized for that task.
Although most database management systems are specialized to work on a specific data model, it is a fact that we are starting to see more and more database management systems that support multiple models due to the diversity of today’s business requirements.
Now let’s take a brief look at the most well-known of these specialized database models and their uses…
Logical models
Hierarchical data model
Developed by IBM in the early 1960s for IMS, it is a data model with tree structures which has segments with one-to-many (1-n) relationships. The data is connected by parent-child relationships. To understand this more clearly, we can summarize it as your sibling and you can only have one mother, while your mother can have multiple (n) children (you and your sibling).
Despite being born in the early 1960s, it is still widely used, especially in banking, health, and telecommunications systems that require high performance and accessibility. Here’s another surprising detail for the reader: if you are using a computer with the Windows operating system, the Windows Registry that stores your application records still uses this structure. As they say, if it works, don’t touch it…
Network data model
It is a database model that was introduced with an article written by Charles Bachman, whom is considered by some as the father of modern database management systems, in 1969 and gained more usage with the standards published by CODASYL in 1971. Unlike the hierarchical model, this model, where many-to-many (n-n) relationships can be established, did not become widespread due to the increasing popularity of relational database systems that emerged almost simultaneously with it.
In my opinion, it is a data model that at least the new generation in the industry should know the name of, especially due to its role in the establishment of COBOL programming language standards and its continued use in systems connected to a mainframe, such as supermarket cash registers. It is also worth noting that remote desktop applications still use this infrastructure.
If you’re wondering what COBOL (COmmon Business-Oriented Language) is, you can look here for more information. It is a software language that is still used for bulk data transfers or transaction records, although it is slowly being phased out in modern programming languages.
Relational Database Model
The relational data model, which was founded by the English computer scientist Edgar Frank Codd in 1969, is a data model where data is kept in structures similar to lists called tuples and relationships are defined between these list-like structures. I know the definition is quite complicated. Let me tell you a secret, the list here is not your shopping list, and the list-like structure refers to nothing other than the database table we know. So, even if the number of elements (rows) in a table increases, its structure (columns) does not change, making it different from a list.
Some of you might ask why I didn’t use the term “table” from the beginning. First of all, the concept of a table corresponds to the predicate variable in relational databases that use SQL. And since SQL is mostly used to query data in most relational databases, it’s not entirely wrong to compare tuples and tables. However, it should not be forgotten that Codd used the definition of a tuple in a more mathematical approach. Secondly, I expect readers who are familiar with programming to be more familiar with the concept of a tuple, so I think it would be more accurate to express it this way to better capture the similarity.
It wouldn’t be entirely wrong to say that the relational data model is the most widely used model today. When users or applications want to retrieve data from a database (which they mostly do with SQL codes), the DBMS connects one or more tables through appropriate relationship columns (primary and foreign keys) and returns it as a data set. In doing so, it calculates all possible matches between the tables (cartesian product) and filters the data that meets the desired conditions to share this result.
Unlike the other models I mentioned above, relational databases while initially calculating the data with a three-valued logic (true, false, null/missing) proposed by Codd in the 1970s. Nowadays they are able to calculate the data with a four-valued logic (True, False, Missing but Applicable, Missing but Inapplicable) for the desired conditions with RDBMS 2, which emerged after 1986, due to changing needs in the industry. For more detailed information, you can look at Codd’s own article.
By the way, while I’m at it, my advice is to take a look at his other works. His ideas are of great importance in the evolution of the sector. In fact, let me give you an example: after Codd showed the potential of the relational database model that he created to IBM customers, IBM started the System-R project due to the pressure from their customers, and instead of using Codd’s own Alpha language, IBM developed a non-relational language called SEQUEL (Structured English QUEry Language) by Donald D. Chamberlin and Raymond F. Boyce. However, SEQUEL was so superior to non-relational systems that Larry Ellison, whom is the founder of Oracle Software company, used a copy of it in Oracle Database in 1979. By the way, the original name had to be renamed from SEQUEL to SQL due to copyright reasons, and SQL was accepted as a standard by the American National Standards Institute (ANSI) in 1986 and by the International Organization for Standardization (ISO) in 1987. It is still widely used today.
I’m ending the first part of the article here for now, so as not to tire the reader out. I’ll continue from where I left off with logical data models in another article.
