Auzef Veri Tabanı Tasarımı 2024-2025 Bütünleme Soruları
https://lolonolo.com/2026/01/25/veri-tabani-tasarimi-2024-2025-butunleme-sorulari/
Bu metin, Veri Tabanı Tasarımı dersinin bütünleme sınavına yönelik hazırlanan kapsamlı bir çalışma kılavuzu ve soru bankasıdır. Kaynak, SQL komutları, veri tiplerinin işlevleri ve normalizasyon formları gibi temel teorik konuları detaylı bir şekilde ele almaktadır. Tablolar arasındaki ilişki türleri, karmaşık yapıları çözmek için kullanılan bağlantı tabloları ve verimliliği artıran medya saklama stratejileri üzerinde durulmaktadır. Ayrıca, analitik amaçlı veri ambarı mimarileri ve Yıldız Şema gibi profesyonel tasarım modelleri hakkında teknik bilgiler sunulmaktadır. Toplamda yirmi adet örnek soru ve açıklama içeren bu doküman, öğrencilerin veri tabanı yönetimi konusundaki yetkinliklerini ölçmeyi ve pekiştirmeyi amaçlamaktadır.
https://lolonolo.com
Show More Show Less View Video Transcript
0:00
Herkese merhaba. Bugün her gün
0:02
kullandığımız uygulamaların arkasındaki
0:04
o görünmez gücü yani dijital dünyamızın
0:07
mimarisi olan veri tabanı tasarımını en
0:10
temelden ele alacağız. Şöyle bir
0:13
düşünün. Bu devasa platformlar bu kadar
0:15
çok veriyi nasıl bu kadar hatasız ve
0:18
hızlı bir şekilde yönetebiliyor? İşte bu
0:20
sorunun cevabı bugün mercek altına
0:22
alacağımız akıllıca tasarlanmış veri
0:24
yapılarında saklı. Yol haritamız da bu
0:26
şekilde. Önce verilerle konuşmanın
0:29
dilini öğreneceğiz. Sonra o veriler
0:31
arasındaki ilişkiler ağını kuracağız.
0:33
Ardından verileri nasıl akıllıca
0:35
depolayacağımıza bakıp son olarak da
0:37
kurduğumuz bu yapının sağlamlığını yani
0:40
bütünlüğünü nasıl koruyacağımızı
0:41
göreceğiz. Hazırsanız başlayalım.
0:44
Pekala. İlk adımımız. Nasıl ki bir
0:47
mimarın alet çantası varsa bizim de veri
0:49
tabanıyla iletişim kurmak için bir
0:51
aracımız var. Bu aracın adı SQL. Aslında
0:55
bu veri tabanlarının anladığı bir dil.
0:58
SQL bize veriyi yönetmek için aslında
1:00
çok basit ama bir o kadar da güçlü
1:02
komutlar veriyor. Dediğinizde yeni bir
1:05
bilgi ekliyorsunuz. Delete ile mevcut
1:07
bir bilgiyi siliyorsunuz ve select ile
1:09
de istediğiniz bilgiyi çağırıp
1:11
okuyorsunuz. İnanın gördüğünüz o en
1:14
karmaşık sistemler bile temelinde bu üç
1:16
eyleme dayanıyor. Peki veri tabanında
1:20
bütün sayılar aynı mıdır? Tabii ki
1:22
hayır. İşte double gibi özel veri
1:25
tipleri de burada devreye giriyor.
1:28
Özellikle finansal hesaplamalar gibi
1:30
virgülden sonraki en küçük basamağın
1:32
bile hayati olduğu durumlarda bu yüksek
1:35
hassasiyetli veri tipi kullanılır. Daha
1:38
fazla yer kaplar ama hata payını sıfıra
1:40
indirir. Bu da bizi bilgisayar
1:42
dünyasının o sihirli sayılarından birine
1:45
getiriyor. 1024. Biz günlük hayatta her
1:48
şeyi 10 ve katları olarak düşünürüz ya.
1:51
Bilgisayarlar 2innin kuvvetleriyle
1:53
çalışır. Bu yüzden de 1 GB tamı tamına
1:56
1000 değil 1024 MBır. Tamam, artık temel
2:01
araçlarımızı ve dilimizi öğrendik. Eee,
2:04
şimdi ne yapacağız? Şimdi verilerimizin
2:07
içinde yaşayacağı o evin planını yani
2:09
mimarisini çizmeye başlayacağız.
2:11
Verileri birbiriyle nasıl
2:13
konuşturacağımızı tasarlayacağız. İşte
2:15
şimdi işlerin gerçekten ilginçleştiği
2:17
yere geldik. Karşınızda veri tabanı
2:20
dünyasının en yaygın ve esnek bağlantı
2:22
türü çoğa çok ilişki. Yani bir şeyin
2:25
birden fazla başka şeye bağlanabilmesi
2:28
ve tam tersinin de mümkün olması durumu.
2:31
Bu kulağa biraz soyut gelmiş olabilir.
2:33
Hemen somutlaştıralım. Mesela bir
2:35
müşteri bir alışverişte birden fazla
2:37
ürün alabilir, değil mi? Aynı şekilde o
2:40
ürünlerden herhangi biri de yüzlerce
2:42
binlerce farklı müşteri tarafından satın
2:44
alınabilir. Ya da bir öğrencinin birden
2:46
fazla derse yazılması ve aynı dersinde
2:49
birden fazla öğrencisi olması. İşte bu
2:52
çoğa çok ilişkinin ta kendisi. Aslında
2:54
farkında olmadan her gün yaşıyoruz. Peki
2:57
sistem bunu nasıl anıyor? Bu karmaşık
3:01
ilişkiyi veri tabanında nasıl kuruyoruz?
3:03
İşte burada mimarların çok zekice bir
3:06
hilesi var. Bağlantı tablosu. Bu tabloyu
3:09
müşteriler ve ürünler tabloları arasına
3:12
atılmış bir köprü gibi düşünün. Kimin
3:14
hangi ürünü aldığının kaydını tutarak bu
3:17
karmaşık ağı yönetmemizi sağlıyor. Tabii
3:19
ki günümüzün veri tabanları sadece metin
3:22
ve sayılardan ibaret değil. İşin içinde
3:24
devasa video dosyaları, yüksek
3:26
çözünürlüklü fotoğraflar, ses kayıtları
3:28
var. Şimdi de bu tür karmaşık verileri
3:31
nasıl akıllıca saklayacağımıza ve analiz
3:33
için nasıl hazırlayacağımıza bakalım.
3:35
Bakın bu ayrım çok ama çok önemli.
3:38
Diyelim ki bir uygulama geliştirdiniz.
3:40
Bir kullanıcının yüklediği videoyu
3:42
olduğu gibi alıp veri tabanına koymak
3:44
yapılacak en büyük hatalardan biri. Veri
3:47
tabanını anında şişirir ve yavaşlatır.
3:50
Peki akıllı yöntem ne? O dosyayı başka
3:53
özel bir sunucuya yüklemek ve veri
3:55
tabanında sadece o dosyanın adresini
3:57
yani bir nevi linkini tutmak. Bu sayede
4:00
veri tabanınız hafif ve hızlı kalı. Bir
4:03
de veri ambarı dediğimiz bir yapı var.
4:05
Bunu bir şirketin devasa arşivi veya
4:08
kütüphanesi gibi düşünebilirsiniz.
4:11
Farklı departmanlardan gelen tüm veriler
4:13
burada bir araya getirilir. Amaç günlük
4:15
işlemleri yapmak değil, geriye dönük
4:18
olarak büyük resmi görmek, trendleri
4:20
analiz etmek ve geleceğe yönelik
4:22
kararlar almak. İşte bu veri ambarlarını
4:25
tasarlarken de en sık kullanılan
4:27
yöntemlerden biri yıldız şeması. Adı
4:30
üstünde tam merkezde bir olgu tablosu
4:32
var. Mesela bütün satış işlemleri burada
4:34
tutuluyor. Bu yıldızın merkezi. Yıldızın
4:37
kolları ise boyut tabloları. Yani o
4:40
satışı hangi müşteri yaptı, hangi ürünü
4:42
aldı, hangi mağazadan aldı gibi
4:44
detayları tutan tablolar. Bu yapı analiz
4:46
sorgularını çok hızlandırıyor. Geldik
4:49
son ve en kritik aşamaya. Harika bir
4:52
plan çizdik. Yapıyı kurduk. Peki bu
4:54
yapının zamanla çürüyüp kaosa dönmesini
4:56
nasıl engelleyeceğiz? İşte verilerimizi
4:59
temiz, tutarlı ve güvenilir tutan
5:01
kurallar bütününe yani veri bütünlüğünü
5:03
korumaya bakacağız. Bu işin teknik
5:05
adıysa normalizasyon. Normalizasyon
5:08
dediğimiz şey ne aslında biliyor
5:10
musunuz? Veri tabanına çeki düzen
5:12
vermek. Bir nevi evi toplamak gibi
5:14
düşünebilirsiniz. Amaç gereksiz veri
5:17
tekrarlarını ortadan kaldırmak ve her
5:19
bilginin olması gereken tek bir mantıklı
5:21
yerde durmasını sağlamak. Bu böyle adım
5:24
adım ilerleyen bir yolculuk. Birinci
5:27
seviyede yani birinci normal formda çok
5:30
temel bir kural vardır. Her hücrede
5:33
sadece tek bir bilgi olabilir.
5:35
İlerledikçe mesela 3üncü normal formda
5:38
daha karmaşık ve dolaylı veri
5:40
bağımlılıklarını temizleriz. Bu yolun
5:42
sonundaki teorik idealse DDNF yani
5:46
kusursuz veri yapısıdır. Bakın bu klasik
5:49
söz aslında normalizasyonun bütün
5:51
felsefesini özetliyor. Ne diyor? Bir
5:53
tablodaki herhangi bir veri sadece ve
5:56
sadece o satırı benzersiz yapan ana
5:58
kimlik bilgisi ile ilgili olmalıdır.
6:00
Başka bir şeyle değil. Mesela siparişler
6:03
tablosuna müşterinin doğum tarihini
6:04
yazmak yanlıştır. Çünkü doğum tarihi
6:07
siparişin değil müşterinin bir
6:08
özelliğidir ve müşteriler tablosunda
6:10
durmalıdır. İşte bu kuralı ihlal
6:12
ettiğimizde o geçişli bağımlılık
6:14
dediğimiz ve veri tutarlılığını bozan
6:16
problemler ortaya çıkar. Demek ki her
6:19
şeyin kilitlendiği nokta ne? Her bir
6:21
deri satırı için asla tekrar etmeyecek
6:23
benzersiz bir kimlik yani bir anahtar
6:26
bulmak. Bir kitap için bu İSBN
6:28
numarasıdır. Bir vatandaş için TC kimlik
6:30
numarasıdır. Bir kullanıcı için e-posta
6:33
adresidir. Ama asla isim olamaz. Çünkü
6:35
aynı isimde binlerce insan olabilir.
6:38
İşte bu doğru anahtarı seçmek sağlam bir
6:40
yapının temel taşıdır. Özetle en başta
6:42
kullandığımız o mimarın planı
6:44
benzetmesine geri dönersek bugün
6:46
gördüğümüz her şey bize şunu gösteriyor.
6:48
İyi ve sağlam bir veri tabanı. şans
6:50
eseri ortaya çıkmaz. Tıpkı depreme
6:52
dayanıklı bir bina gibi yapı, ilişkiler
6:55
ve kurallar hakkında dikkatle düşünülmüş
6:57
bir dizi bilinçli kararın sonucudur ve
7:00
sizi üzerinde düşünmeye değer bu soruyla
7:03
baş başa bırakıyorum. Veri artık bu
7:05
kadar değerli olduğuna göre gelecekte bu
7:07
değeri korumak ve işlemek için nasıl
7:10
daha zekice, daha yenilikçi mimari
7:12
planlar tasarlamamız gerekecek? Bir
7:14
sonraki analizimizde görüşmek üzere.
#Education

