live_tv
Livestream Starting Soon
00
Hours
:
00
Minutes
:
00
Seconds
Up next in 10
Auzef Veri Tabanı Tasarımı 2025-2026 Final Soruları
https://lolonolo.com/2026/01/22/veri-tabani-tasarimi-2025-2026-final-sorulari/
Bu metinler, 2025-2026 dönemi Veri Tabanı Tasarımı dersine ait final sınavı sorularını ve bu soruların temelini oluşturan akademik konu özetlerini kapsamaktadır. Kaynaklarda, ham verinin bilgeliğe dönüşme sürecini anlatan DIKW hiyerarşisi, tablolar arası ilişki türleri ve veri tekrarını önleyen normalizasyon aşamaları detaylıca açıklanmaktadır. Ayrıca analitik sorgulamalar için kullanılan yıldız şema mimarisi ile veri güvenliğini sağlayan özetleme (hashing) teknikleri gibi modern tasarım yaklaşımlarına değinilmektedir. Metin, bankacılık veya konferans sistemleri gibi somut örnekler üzerinden veri tabanı nesnelerinin nasıl seçilmesi gerektiğini ve yönetim sistemlerinin temel işlevlerini öğretici bir dille sunmaktadır. Özetle bu döküman, veri tabanı mimarisinin hem teorik temellerini hem de uygulamalı tasarım prensiplerini bir arada sunan kapsamlı bir rehber niteliğindedir.
https://lolonolo.com
Show More Show Less View Video Transcript
0:00
Her gün kullandığımız uygulamaların,
0:02
yaptığımız bankacılık işlemlerinin ve
0:04
online alışverişin arkasında farkında
0:06
olmadığımız sessiz bir kahraman var. İyi
0:09
tasarlanmış bir veri tabanı. Peki bu
0:11
anlamsız gibi görünen ham veriler nasıl
0:14
oluyor da bu kadar güçlü ve düzenli
0:16
sistemlere dönüşüyor? Bu sihir nasıl
0:18
gerçekleşiyor? Gelin veri yığınlarını
0:20
değerli bilgilere dönüştüren temel
0:22
tasarım ilkelerini birlikte keşfedelim
0:24
ve bu sessiz kahramanın sırlarını bir
0:26
bir açığa çıkaralım. İşte bütün bu
0:28
anlatacaklarımızın merkezindeki soru da
0:30
tam olarak bu. Basit bir gerçeklikten
0:33
yola çıkıp sonunda anlamlı bir karara
0:34
varacağımız bir yolculuk bu. Ve bu
0:36
dönüşüm var ya işte o etkili bir veri
0:39
tabanı tasarımının ardındaki temel
0:41
mantığı oluşturuyor. Her şey doğru
0:43
soruları sormakla başlıyor. Hadi o zaman
0:45
her şeyin başlangıcına yani verinin ta
0:48
kendisine dönelim. Yolculuğumuzun ilk
0:50
durağında tek bir rakamın veya kelimenin
0:52
nasıl olup da stratejik bir karara
0:54
dönüştüğünü anlamamız gerekiyor. Neyse
0:56
ki bu evrimi bize anlatan çok güçlü bir
0:59
model var. D KW hiyerarşisi. Bakın bu
1:02
piramit soyut bir kavramı çok güzel
1:04
somutlaştırıyor. En altta tek başına
1:07
hiçbir anlamı olmayan 7 gibi ham bir
1:09
veri var. Buna bir bağlam eklediğimizde
1:12
mesela hava sıcaklığı dediğimizde bu
1:14
artık bir enformasyon oluyor. Sonra
1:17
kendi tecrübelerimizi kullanarak 7
1:19
derece soğuktur mont giymek lazım
1:20
çıkarımını yaptığımızda bu bilgiye
1:23
dönüşüyor ve en tepeye yani bilgelik
1:25
seviyesine ulaştığımızda bu bilgiye
1:27
dayanarak en kalın montumu seçmeliyim
1:30
kararını veriyoruz. İşte iyi tasarlanmış
1:32
veri tabanları bu hiyerarşinin temelini
1:35
yani veriyi ve enformasyonu sağlam bir
1:37
şekilde inşa etmemizi sağlar. Geri
1:39
kalanı ise bizim analiz yeteneğimize
1:41
kalmış. Tamam, teoriyi anladık. Peki,
1:44
gerçek dünyadaki bu karmaşık kavramları
1:46
alıp bir veri tabanında nasıl
1:48
düzenleyeceğiz? Bu sanki yeni bir
1:51
kütüphane kuruyormuşsunuz da kitapları
1:53
hangi kategorilere ayıracağınıza karar
1:55
veriyormuşsunuz gibi bir şey. İşte ilk
1:57
temel yapı taşımız varlık ya da
2:00
İngilizcedeki popüler adıyla entity.
2:02
Kulağa biraz teknik gelebilir ama
2:04
aslında çok basit. hakkında bilgi
2:06
toplamak istediğimiz her şey bir
2:08
varlıktır ve veri tabanında bir tabloya
2:11
dönüşür. Mesela bir e-ticaret
2:13
sitesindeki müşteriler, sattığınız
2:15
ürünler ya da bir hastanedeki doktorlar
2:18
ve randevular. Bunların hepsi birer
2:20
varlıktır. Haydi şimdi küse bir beyin
2:22
fırtınası yapalım. Kendinizi bir
2:24
anlığına veri tabanı mimarı olarak
2:26
düşünün. Bir banka için veri tabanı
2:28
tasarlıyorsunuz. Bu tablolardan hangisi
2:31
oraya pek de ait değil gibi duruyor?
2:33
Cevap tabii ki araç. Neden? Çünkü bir
2:36
bankanın ana işi para, hesaplar ve
2:38
transferlerdir. Eğer banka özel olarak
2:41
araç kredisi vermiyorsa veya araba alıp
2:43
satmıyorsa araç tablosu tamamen gereksiz
2:46
bir detay olur. İşte size iyi tasarımın
2:49
ilk kuralı. Sadece ve sadece ana
2:52
faaliyet alanıyla doğrudan ilgili olan
2:53
şeyleri modellemek. Ve geldik
2:55
tasarımcıların sık sık karşılaştığı 10
2:57
meşhur probleme. Çoğa çok ilişki. Şöyle
3:00
düşünelim. Bir müşteri onlarca farklı
3:03
ürün alabilir. Aynı şekilde bir ürün de
3:06
binlerce farklı müşteri tarafından satın
3:08
alınabilir. Bu karmaşık ağı nasıl bir
3:10
düzene sokacağız? Çözüm şaşırtıcı
3:13
derecede zarif ve basit. Araya ikisi
3:16
arasında köprü görevi görecek bir
3:17
sipariş tablosu koyuyoruz. Böylece o
3:20
karmaşık ilişkiyi yönetmesi çok daha
3:22
kolay olan iki tane basit bire ilişkiye
3:25
bölmüş oluyoruz. tıpkı kalabalık bir
3:27
kavşağa bir göbek inşa edip trafiği
3:30
düzenlemek gibi kaosu ortadan
3:32
kaldırıyor. Şimdi de veli kütüphanemizi
3:34
temizlemek yani bir çeki düzen vermek
3:37
için kullandığımız kurallar bütününe
3:40
yani normalizasyona geçelim. Buradaki
3:42
amacımız çok net. Her bir bilgi
3:44
parçasının tek ve doğru bir yere sahip
3:47
olduğundan emin olmak. Aslında
3:49
normalizasyonun tanımı çok basit. Veri
3:51
tekrarını ve tutarsızlıkları önlemek
3:53
için tasarlanmış bir optimizasyon
3:55
süreci. Gereksiz kopyaları sistemden
3:57
atarak veri tabanımızı hem daha verimli
4:00
hem de çok daha güvenilir hale
4:01
getiriyor. Gelin normalizasyonun en
4:04
kritik ilk üç adımını basitçe
4:05
özetleyelim. Birinci kural: Her hücrede
4:08
sadece tek bir bilgi olabilir. Yani bir
4:11
müşterinin adresini İstanbul Ankara diye
4:14
tek bir hücreye yazamazsınız. yazarsanız
4:16
sadece İstanbul'daki müşterileri
4:18
listelemek istediğinizde işiniz
4:20
imkansızlaşır. İkinci kural der ki bir
4:23
tablodaki tüm bilgiler o tablonun ana
4:25
konusunu anlatmalı. Mesela sipariş
4:27
detayları tablosunda ürünün fiyatı olur
4:30
ama müşterinin doğum tarihi olmaz. Çünkü
4:33
doğum tarihi siparişin değil müşterinin
4:35
bir özelliğidir. Ve üçüncü kural ki bu
4:38
çok önemli. Eğer bir bilgiyi diğer iki
4:41
bilgiden zaten hesaplayabiliyorsanız onu
4:43
tekrar saklamayın. Toplam fiyatı, adet
4:46
ve birim fiyatı çarparak her zaman
4:47
bulabilirsiniz. Bunu fazladan saklamak
4:50
hem yer israfı hem de ileride veri
4:52
tutarsızlığına yol açacak bir saatli
4:54
bomba demektir. Şimdi normalizasyonla
4:57
ilgili yaygın bir efsaneyi de çürütelim.
5:00
Bazıları bu sürecin daha fazla tablo
5:02
yarattığı için veri hacmini arttırdığını
5:05
düşünür. Ama gerçek tam tersi.
5:07
Normalizasyon gereksiz tekrarları
5:09
ortadan kaldırdığı için aslında veriyi
5:11
optimize eder. Bu da hem erişim hızını
5:14
arttırır hem de tasarım kalitesini
5:16
bambaşka bir seviyeye taşır. Şimdiye
5:18
kadar veriyi nasıl düzgün
5:20
saklayacağımızı konuştuk. Peki ya o
5:22
veriden şimşek hızında raporlar ve
5:24
analizler çıkarmak istersek işte o zaman
5:27
sahneye özel bir yapı çıkıyor. Yıldız
5:29
şema. Yıldız şemasını gözünüzde bir
5:32
güneş sistemi gibi canlandırın. Tam
5:34
merkezde evrenin merkezi gibi duran olay
5:36
tablosu vardır. Burada satış adetleri
5:39
ciro gibi sürekli akan sayısal veriler
5:41
tutulur. Etrafında yörüngede dönen
5:43
gezegenler gibi de boyut tabloları
5:45
bulunur. Bunlar da o olayları ne zaman
5:48
oldu, hangi ürün satıldı, hangi müşteri
5:50
aldı gibi bilgilerle anlamlandırır. Peki
5:53
bu yapının bize faydası ne? Şu geçen ay
5:56
çok hangi bölgede hangi ürün satıldı
5:58
gibi devasa ve karmaşık bir sorunun
6:01
cevabını normalde dakikalar
6:03
sürebilecekken saniyeler içinde
6:05
bulmanızı sağlar. Çünkü yapısı tam
6:07
olarak bu tür analizler için optimize
6:09
edilmiştir. Harika bir sistem kurduk.
6:11
Verilerimiz düzenli, analizlerimiz
6:13
hızlı. Peki ya güvenlik? İşte şimdi
6:15
mimarımızın yolculuğundaki son ve belki
6:18
de en kritik adıma geldik. Veriyi
6:20
korumak. Özellikle de şifreler gibi en
6:22
hassas bilgileri. Hashing'i yani
6:25
özetlemeyi tek yönlü bir cadde gibi
6:27
düşünün. Şifrenizi bu caddeye sokarsınız
6:30
ve cadde sonunda bambaşka tanınmaz bir
6:32
karaktere dönüşür. Ama en önemli
6:34
özelliği ne biliyor musunuz? Bu caddeden
6:36
geri dönüş yoktur. Yani o şifrenin
6:39
özetlenmiş halinden orijinaline ulaşmak
6:41
imkansızdır. İşte bu yüzden bu kadar
6:44
güvenlidir. İşte bu görsel her şeyi bir
6:46
anda anlatıyor. Sol tarafta bir sızıntı
6:49
anında herkesin okuyabileceği güvensiz
6:51
bir şifre var. Sağ tarafta ise onun
6:54
güvenli, özetlenmiş, anlamsız
6:56
karakterlere dönüşmüş hali. Aradaki bu
6:59
fark felaket ile tam güvenlik arasındaki
7:02
farktır. Bunun gerçek dünyadaki anlamı
7:05
şu: En kötü senaryo yaşansa ve veri
7:07
tabanınız çalınsa bile
7:09
kullanıcılarınızın şifreleri güvende
7:11
kalır. Çünkü saldırganların eline geçen
7:13
tek şey çözmeleri imkansız olan o
7:16
anlamsız karakter dizileri olur. Evet,
7:19
böylece kaostan düzenli bilgiye olan
7:21
yolculuğumuzun sonuna geldik. Bütün bu
7:23
kavramları bir araya getirdiğimize göre
7:25
şimdi size şu soruyu sormak istiyorum.
7:28
Kurduğunuz bu yapılar sadece verileri
7:30
saklayan bir depo mu yoksa size yeni
7:32
ufuklar açan, işinizi ileriye taşıyan
7:35
bir hikaye mi anlatıyor? Unutmayın, iyi
7:37
bir veri tabanı sadece size cevaplar
7:40
vermez. Aynı zamanda doğru soruları
7:42
sormanızı da sağlar. Asıl bilgelik de
7:44
işte o hikayeyi dinleyebilmektir.
#Computers & Electronics
#Jobs & Education
#Education
#Reference