Veri modeli oluşturmak
[English below]
Neden veri modeline ihtiyaç duyulur? Bir veri modeli oluştururken nelere dikkat etmek gerekir? Modelleme yapmadan da verileri analiz için kullanamaz mıyız? Hazırsanız başlıyoruz…
Veri modeli nedir ve neden bir veri modeline ihtiyaç duyulur?
Veri modeli tanımını yapmadan önce veri ambarı kavramını biraz açmak gerekir. Veri ambarları bir veya birden fazla kaynaktan beslenen, ihtiyaç duyulan analizleri karşılayacak şekilde tarihsel derinliği olan ilişkisel veri tabanlarıdır. Tam bu noktada da veri modeli, bu ilişkisel kurguyu tanımlamak için oluşturduğumuz yapıdır.
Biraz daha sade bir anlatımla, bir ya da birden fazla üreticiden aldığımız çeşitli ürünleri zamanı geldiğinde beraber paketleyerek satmayı planladığınızı düşünün. Hangi ürün hangi ürünle beraber paketlenebilir ve hangi ürün hangi rafta durmalı konusuna karar vermeden kuracağınız bir deponun başarılı bir şekilde yönetilmesi ihtimali yoktur, hele ki size 3–5 yıl yetecek kadar ürünü depolamayı planlıyorsanız. Şu durumda ilk yapmanız gereken ürünleri tiplerine göre ayırmak, doğru koşullarda saklayabileceğiniz raflara yerleştirmek ve tercihen beraber paketlenecek ürünleri birbirlerine yakın raflara koymak olmalıdır. Aksi takdirde deponuzdaki kaos sizin iş yapmanıza engel olacaktır.
İşte tam olarak da bu sebeple bir veri modeli olmaksızın çalışan bir veri ambarını düşünmek pek mantıklı olmayacaktır.
Peki bir veri modeli oluştururken nelere dikkat etmeliyiz?
İlk ve en önemli konu veri modeliniz iş ihtiyaçlarını karşılayacak şekilde kurgulanmalıdır. Yani, et satmayı planlıyorsanız mutlaka bir buzdolabınız olmalı değil mi? Peki bunu nasıl yaparız?
Eğer şanslıysanız ve bir veri ambarı projesinin ilk kuruluşuna denk geldiyseniz bolca talep toplama toplantısı yapmaya hazır olun. Veri ambarının hizmet vermesi planlanan iş birimleriyle bir araya gelerek akıllarındaki ihtiyacı anlayıp ona göre bir planlama yapın. Ne kadar geriye dönük veriye ihtiyaç var? Hangi veriler gerçekleşmeleri (fact), hangi veriler varlıkları (entity) ve hangi veriler bu varlıkların boyutlarını (dimension) gösteriyor? Bu verilerin kaynağı neresi? Verilerin zaman içinde değişen değerlerinin orijinal hallerine de ihtiyacınız olacak mı yoksa son haldeki durumlarıyla mı ilgileniyorsunuz? Daha bir çok cevaplanması gereken sorunuz olacak emin olun.
Sorularınızın cevaplarını aldıktan sonra tek tek her birimden aldığınız ihtiyaçların başka hangi birimler tarafından da istenildiğini çıkartmaya çalışın. Ortaklayabildiğiniz iş kurallarının peşinde düşün, ortaklayamadıklarınız için de kurgunuzun nerelerde esnemesi gerektiğini planlamaya çalışın. Tebrikler! Veri modellemede ilk aşamayı tamamladınız.
İkincil olarak en çok önem vermeniz gereken konu, size var olduğu söylenen verinin peşine düşmek olmalı. Gerçekte bu veriler hangi kaynaklarda duruyor? Ne kadar bir veriden bahsediyoruz, alan ihtiyacımız ne olacak? Bu verinin büyüklüğü size anlatıldığı kadar mı? Erişimlerinizi alıp, sorgularınızı yazmaya başlamanın zamanıdır.
Üçüncü konu, verilerin güncelliği. Diyelim ki ilk iki aşamayı kazasız atlattınız. Artık önünüzde planlamanız gereken yeni bir konunuz var. Farklı kaynaklardan gelecek verilerin aynı güncellikte birbiriyle eşleşmesi. Buradaki en büyük sıkıntı kimi sistemin veriyi güncelleme sıklığının iş birimlerinin sizden beklediğinden yavaş olması olacaktır. İki çözüm yöntemi önerebilirim. Ya kaynağı hızlandırmayı deneyin ya da iş birimi ikna edin. Verinin güncelliği konusunda kontrol edemediğiniz noktalarda kahramanlık yapmanızı tavsiye etmem.
Dördüncü önemli nokta ise veri kalitesi. Bu konu apayrı bir başlık altında konuşulmasını gerektirdiğinden ilerleyen günlerde ayrıca bir yazıyla anlatacağım. Ancak inanın en çok gürültünün kopacağı yer burası olacak.
Herşey tamam, haydi modeli oluşturalım dediğinizde ise karşınıza konunun akademik kısmı çıkacak. Inmon ve Kimball modelleme teknikleri. Veri normalizasyonu konusu da ayrıca incelenmeyi hak ettiğinden bu konuya da başka bir yazıda ayrıca değineceğim.
Veri modeli olmadan analiz yapamaz mıyız?
Bunca zahmete ne gerek var model yapmadan da veriyi analiz edemez miyiz? Denemesi bedava demek isterdim ama inanın maliyeti bedavanın çok ama çok üstünde olacaktır. Karışıklık içinde boğulup, uyumsuz verileri eşlemeye çalışırken, değişen ya da herkes tarafından farklı yorumlanan iş kurallarını anlamaya çalışırken defalarca harcayacağınız eforlara hazır olun.
Peki sıfırdan bir veri ambarı kurmuyorsak?.. O da ayrı bir yazının konusu elbette.
Creating a data model
Why is there a need for a data model? What should be considered when creating a data model? Can’t we use data for analysis without modeling? If you are ready, let’s get started…
What is a data model and why is there a need for a data model?
Before defining the data model, it is necessary to explain the concept of a data warehouse a little. Data warehouses are relational databases with historical depth that are fed from one or more sources to meet the required analyses. At this point, the data model is the structure we create to define this relational structure.
In simpler terms, imagine that you plan to sell various products from one or more manufacturers by packaging them together when the time comes. Without making decisions about which product can be packaged with which product and which product should be placed on which shelf, it is not possible to successfully manage a warehouse, especially if you plan to store enough products for 3–5 years. In this case, the first thing you need to do is to separate the products by type, place them on shelves where you can store them under the right conditions, and preferably place the products that will be packaged together on shelves close to each other. Otherwise, the chaos in your warehouse will hinder your work.
This is exactly why it wouldn’t make much sense to think of a data warehouse that operates without a data model.
So what should we pay attention to when creating a data model?
The first and most important issue is that your data model should be structured to meet the business needs. In other words, if you plan to sell meat, you must have a refrigerator, right? So how do we do this?
If you are lucky enough to be involved in the initial establishment of a data warehouse project, get ready to collect plenty of requests from business units by holding tons of meetings. Meet with the business units for which the data warehouse is planned to serve, understand their needs, and plan accordingly. How much historical data is needed? Which data represents facts, which data represents entities, and which data shows the dimensions of these entities? Where is the source of this data? Will you need the original values of the data that change over time, or are you interested in their current state? You will definitely have many more questions that need to be answered.
After receiving the answers to your questions, try to figure out which other units are also asking for the needs you have collected from each unit. Think about the common business rules, and try to plan for the flexibility of your structure where you cannot find common ground. Congratulations! You have completed the first stage of data modeling.
Secondly, the most important thing you should focus on is chasing after the data that is said to exist. Where are these data actually stored? How much data are we talking about, what will be our space requirement? Is the size of this data as it’s been told to you? It’s time to get your access and start writing your queries.
The third issue is the freshness of the data. Let’s say you’ve successfully passed the first two stages. Now you have a new issue to plan ahead for. Ensuring that data from different sources matches each other in terms of freshness. The biggest problem here will be the slow frequency of some systems updating data compared to what the business units expect from you. I can suggest two solutions. Either try to speed up the source or convince the business unit. I wouldn’t advise you to play the hero in areas where you can’t control the accuracy of the data.
The fourth important point is the quality of the data. Since this issue requires a separate discussion, I will write about it separately in the coming days. But believe me, this is where most of the noise will be.
When you say “everything is okay, let’s create the model,” the academic part of the subject will appear before you. Inmon and Kimball modeling techniques. The subject of data normalization also deserves to be examined separately, so I will also address this issue in another article.
Can’t we analyze the data without a model?
Why bother making a model when we can’t analyze the data without it? I wish I could say it’s free to try, but trust me, the cost will be way, way beyond free. Get ready to spend countless efforts trying to map mismatched data, trying to understand changing or differently interpreted business rules while drowning in confusion.
But what if we’re not building a data warehouse from scratch?.. That’s a whole different topic of discussion, of course. Which I plan to write about it soon.
