Up next in 10
Ata Aöf Veri Tabanı Yönetim Sistemleri 2024-2025 Final
https://lolonolo.com/2026/04/29/ata-aof-veri-tabani-yonetim-sistemleri-2024-2025-final-sorulari/
https://lolonolo.com
Show More Show Less View Video Transcript
0:00
Herkese merhaba. Bu kapsamlı özete hoş
0:02
geldiniz. Bugün veri tabanı yönetim
0:04
sistemlerinin dünyasına şöyle harika
0:05
derinlemesine bir giriş yapıyoruz. Şöyle
0:08
düşünün. Bir veri tabanını anlamak
0:10
aslında devasa ve ultra modern bir ev
0:12
inşa etmeye inanılmaz benzer. Yani
0:15
sağlam atılmış bir temele, kusursuz
0:17
kurgulanmış bir iskelete, o duvarların
0:19
arkasına gizlenmiş akıllı bir tesisata
0:22
ve tabii ki en dışta kırılmaz sağa
0:24
sağlam güvenlik kilitlerine ihtiyacımız
0:26
var. Bugün bu veri tabanı evimizi o
0:28
temelinden çatısına kadar adım adım hep
0:31
birlikte inşa edeceğiz. Sınavınızda
0:33
karşınıza çıkacak o en kritik noktaları
0:35
bu inşaatın her bir tuğlasında birlikte
0:37
keşfedeceğiz. Hazırsanız hadi
0:39
başlayalım. Hemen içeriye dalalım.
0:42
Gündemimiz şu şekilde. Birinci adımda
0:44
SQL temelleri ve sorgu mantığı var.
0:47
İkinci adımda tablo işlemleri ve
0:49
ilişkilerle iskeleti kuracağız.
0:51
Üçüncüsünde saklı yordamlar ve
0:53
servislerle tesisatı döşeyeceğiz. Ve son
0:56
olarak güvenlik, loglama ve kurtarmayla
0:58
kapılarımızı kilitleyeceğiz. O halde
1:00
hemen birinci bölümle yani evimizin o
1:03
sağlam temeliyle başlıyoruz. SQL
1:05
temelleri ve sorgu mantığı. Bakın bu
1:08
aşama gerçekten evimizin temeli. Betonu
1:11
ne kadar sağlam dökersek üzerine inşa
1:13
edeceğimiz o devasa veri tabloları da o
1:15
kadar dayanıklı ve hızlı çalışır. Peki
1:18
durup hiç düşündünüz mü tüm bu sistemler
1:20
aslında neden var? Yani neden sadece
1:22
basit düz dosyalar kullanıp geçmiyoruz?
1:25
İşte tam bu noktada veri bağımsızlığı
1:27
dediğimiz o harika kavram devreye
1:29
giriyor. Veri tabanı yönetim sistemini
1:32
sizin için tüm oy yorucu ve karmaşık
1:33
işleri halleden usta bir müteahit gibi
1:35
düşünün. Gerçekten de öyle. Kullanıcı
1:38
olarak sizin verinin diskte mantıksal
1:40
veya fiziksel olarak nerede nasıl
1:42
tutulduğunu bilmenize hiç ama hiç gerek
1:44
yok. Siz sadece SQL sorgularınızı
1:47
kullanarak ne istediğinizi söylersiniz.
1:49
Arkanıza yaslanırsınız ve gerisini
1:51
sistem halleder. Harika değil mi? Şimdi
1:53
verilerimizi getirirken temel bir
1:55
sentaks kullanırız. Fakat burada
1:57
sınavlar için gerçekten altın değerinde
1:59
bir kuralımız var. Lütfen buna çok
2:01
dikkat edin. Tablolardan veri çekerken
2:04
her zaman from kelimesini kullanırız.
2:06
Asla on kelimesini değil. Aslında mantık
2:09
çok basit. Veriyi bir kaynaktan
2:11
çekersiniz. Yani from dersiniz. Gidip de
2:13
verinin üzerine basmazsınız. Select
2:16
sütun adları. From tablo adı yapısı veri
2:19
çekmenin en temel, en klasik ve
2:21
kesinlikle hatasız kuralıdır. Peki siz
2:24
bu sorguyu yazdığınızda o karanlık arka
2:26
planda neler oluyor dersiniz. Aslında
2:29
SQL motoru adeta aracınızdaki bir GPS
2:32
cihazı gibi çalışır. Sorgunuzu
2:34
çalıştırdığınız an sistem veriye ulaşmak
2:36
için o en hızlı rotayı yani tam olarak
2:38
hangi indeksleri kullanacağını anında
2:40
hesaplar, istatistikleri çıkarır ve
2:42
bunları bir ön belleğe kaydeder. İşte
2:45
SQL'in sizin için çizdiği bu en hızlı ve
2:47
verimli arka plan haritasına gerçek
2:49
yürütme planı yani actual execution plan
2:52
diyoruz. Şimdi bu kısım gerçekten çok
2:54
ilginç. SMS yani SQL Server Management
2:58
Studio ortamında tekrar eden işlemleri
3:00
ne kadar kolay otomatize edebildiğimizi
3:02
göreceksiniz. Diyelim ki yazdığınız bir
3:05
sorguyu artıştırmanız
3:08
gerekiyor. Kodu defalarca kopyalayıp
3:10
yapıştırmak büyük bir zaman kaybı
3:12
olurdu. Değil mi? Bunun yerine sorgunun
3:14
hemen sonuna sadece go 5 yazıyorsunuz.
3:17
Hepsi bu. Bu tek satırlı küçücük komut
3:20
koca bir işlemi peş peşe otomatik olarak
3:22
tekrar etmenizi sağlıyor. Kesinlikle
3:24
hayat kurtarıcı bir ipucu. Temel
3:26
işlemlerden bahsederken matematikle
3:28
ilgili çok net bir kuralımız daha var.
3:30
Veri tabanında kayıtları saymak için
3:32
sıklıkla o meşhur count fonksiyonunu
3:34
kullanırız. Ancak eğer bu matematiksel
3:37
fonksiyonun içerisine filtre değeri
3:39
olarak doğrudan nal yani boşluk hiçbir
3:42
şey gönderirseniz sonuç her zaman ama
3:44
istisnasız her zaman koca bir sıfır
3:47
çıkacaktır. Sınavda karşınıza çıkarsa
3:49
artık bu tuzağa düşmeyeceğinizi
3:51
biliyorum. Geldik ikinci bölüme. Tablo
3:53
işlemleri ve ilişkiler. Artık evimizin
3:56
iskeletini kurma vakti. Temelimizi sapa
3:58
sağlam attık. Şimdi sıra evimizin ahşap
4:01
ve çelik iskeletini kurup odalarımızı
4:03
birbiriyle ilişkilendirmeye geldi.
4:05
Evimize yeni eşyalar yani tablomuza yeni
4:07
veriler eklerken ınsert into komutunu
4:10
kullanıyoruz. Fakat ufak bir uyarım var.
4:12
Sistem bu konuda inanılmaz titizdir.
4:14
Belirttiğiniz sütun sıralamasıyla
4:16
ekleyeceğiniz veri değerlerinin
4:17
sıralaması birbirine mükemmel bir
4:19
şekilde uymak zorunda. Yoksa isim
4:21
sütununa yaş verisi gitmesi gibi tam bir
4:24
felaket yaşarsınız. Düşünsenize birine
4:26
adını soruyorsunuz ve size 35 diyor.
4:28
İstemeyiz, değil mi? Ayrıca metin veya
4:31
tarih formatında veri giriyorsanız
4:33
bunları her zaman tek tırnak işaretleri
4:35
arasına almayı sakın unutmayın. Bu veri
4:37
girişinin o değişmez en katı kuralıdır.
4:40
Bazen de elimizde farklı klasörlerdeki
4:42
belgeler gibi birden fazla farklı veri
4:45
seti bulunur ve biz bunları tek bir
4:47
liste halinde alt alta sıralamak
4:49
isteriz. İşte modern T sequel'de bu iş
4:52
için Union all yapısı adeta imdadımıza
4:55
yetişir. Farklı setleri hızlıca ve tek
4:57
bir hamlede üst üste yığmak için
5:00
inanılmaz verimli bir araçtır. Şimdi
5:02
buradaki kritik nokta şu: Eşyaları
5:04
odadan çıkarmakla evi tamamen dozerle
5:07
yıkmak çok farklı eylemlerdir. Değil mi?
5:09
Mevcut veriyi temizlemek için delete
5:11
kullanırsınız. Bu sadece satırları
5:13
siler, odayı boşaltır. Fakat drop komutu
5:16
işte o dozerle eve girmek gibidir.
5:18
Tabloyu veya tüm veri tabanını yapısal
5:20
olarak kökünden yok eder. Ve çok çok
5:23
önemli bir not. SPL'de delete database
5:26
diye bir komut kesinlikle yoktur. Yapıyı
5:28
komple uçurmak istiyorsanız drop
5:29
kullanacaksınız. Bunu aklınızın bir
5:31
köşesine mutlaka yazın. Peki her şeyi
5:33
silmek yerine sadece bir bilgiyi
5:35
değiştirmek istersek ne olacak? İşte
5:37
mevcut verileri güncelleyen update
5:39
komutu bu konuda adeta bir jimnastikçi
5:42
kadar esnektir. Yeni güncel değeri aynı
5:44
tablonun içinden alabileceğiniz gibi bir
5:46
join işlemiyle tamamen başka bir
5:48
tablodan veya inanabiliyor musunuz? Aynı
5:50
sunucudaki bambaşka bir veri tabanından
5:52
bile çekip kullanabilirsiniz. Size
5:54
veriyi düzenlemek için resmen sınırsız
5:56
bir özgürlük alanı sunar. Tablolarımız
5:59
yani odalarımız oluştu. Peki bunlar
6:01
birbirine nasıl bağlanacak? Varlık
6:04
ilişki modeli tasarlarken günlük hayatı
6:05
düşünmek her zaman en iyisidir. Bir
6:07
öğrencinin birden fazla ders alması veya
6:09
bir müşterinin e-ticaret sitesinden aynı
6:12
anda birkaç sipariş vermesi durumu. Bu
6:14
senaryoların tamamına biz veri tabanı
6:15
mimarisinde bire çok yani one to many
6:18
ilişki türü diyoruz. Gerçek dünyanın
6:20
sisteme aktarılmış açık ara en popüler
6:22
halidir bu. Bir senaryo düşünelim.
6:24
Diyelim ki şirketin borçular listesini
6:26
arıyorsunuz. Borcu olup da hiç ödeme
6:28
yapmayanları bulmanız gerek. Böyle
6:30
eşleşmeyen kayıtları nasıl buluruz? İşte
6:32
bu noktada o eşleşmeyen boşluklara yani
6:35
nal değerlere odaklanmalıyız. Sınavlar
6:38
için yine kritik bir ipu. Left join yani
6:41
sol birleştirme kullanarak sol tabloyu
6:44
olduğu gibi alır ve sağ tablonun
6:46
karşılığı olmayan o boş yani nal
6:48
kayıtlarını filtreleyerek aradığımız
6:50
cevaba şıp diye ulaşırız. Geldik 3üncü
6:52
bölüme. Saklı yordamlar ve servisler.
6:55
Artık o akıllı tesisatı çekme vakti
6:58
iskeletimiz. Tamam. Şimdi sıra evimizin
7:00
duvarlarının içine o gizlenmiş, hayatı
7:02
inanılmaz kolaylaştıran su elektrik
7:05
tesisatına ve akıllı ev otomasyonuna
7:07
geldi. Tam bu aşamada size harika bir
7:09
soru sormak istiyorum. Sisteminizde
7:11
sürekli tekrarlanan her gün belki
7:13
yüzlerce binlerce kez yapılan işlemleri
7:15
nasıl hızlandırırsınız? Her defasında
7:17
aynı kodları en baştan yazıp sunucuya
7:19
göndermek sizce de mantıksız değil mi?
7:21
Kesinlikle mantıksız. Ve bu da şunu
7:23
harika bir şekilde gösteriyor. Stort
7:25
procedure yani saklı yordamlar hız ve
7:28
verimlilik için bizim mükemmel
7:30
çözümümüzdür. Bunlar veri tabanı
7:32
sunucusunda önceden derlenmiş,
7:34
kaydedilmiş, dışarıdan parametre
7:36
alabilen ve doğrudan içeride ışık
7:38
hızında çalışan SQL kod bloklarıdır.
7:41
Kodu sadece bir kez yazar ve
7:42
derlersiniz. sonrasında defalarca en
7:45
yüksek performansla tıkır tıkır çalışır.
7:48
Peki duvarın içindeki bu saklı yoranlar
7:51
dış dünyadaki o modern uygulamalarımızla
7:54
nasıl konuşur? Bir web veya masaüstü
7:57
uygulaması bu kod bloklarını exact veya
8:00
execute komutuyla çağırır. Saklı
8:02
yordamlar gerçekten çok yeteneklidir.
8:04
Dışarıdan sadece veriyi işlemek için
8:07
input yani girdi parametreleri almakla
8:09
kalmazlar. İçeride yaptıkları o karmaşık
8:11
hesaplamaların sonucunu veya veri
8:13
tabanında yeni ürettikleri tap taze bir
8:16
ID numarasını output parametreleri
8:18
aracılığıyla doğrudan kendisini çağıran
8:20
ana uygulamaya geri döndürebilirler.
8:22
Pratikliğe bakar mısınız? Evimiz giderek
8:25
daha da akıllanıyor. Şunu da kesinlikle
8:27
bilmeliyiz ki modern SQL Server
8:29
sistemleri sadece o düz Excel benzeri
8:32
iki boyutlu tablolardan ibaret değildir.
8:34
Analysis services kısaca SSS adında
8:37
devasa bir bileşeni daha vardır. SSS
8:40
elinizdeki o inanılmaz boyuttaki
8:42
verileri alır ve çok boyutlu olup
8:44
küpleri halinde adeta yeniden modeller.
8:46
Bu sayede sadece kayıt tutmakla
8:48
kalmazsınız. veri madenciliği yani data
8:50
mining yaparak geleceği öngören o
8:52
inanılmaz hızlı istatistiksel analizleri
8:55
anında yürütebilirsiniz. Ve geldik son
8:57
bölüme. 4. bölüm. Güvenlik, loglama ve
9:01
dosya sistemleri. Kilitler ve devasa bir
9:04
sigorta poliçesi. Evimiz bitti,
9:06
tesisatımız harika çalışıyor ama kapıda
9:09
o ağır kilitlerimiz ve sağlam bir
9:11
sigorta poliçemiz yoksa bu kurduğumuz
9:13
muhteşem yapının hiçbir anlamı kalmaz.
9:14
Değil mi? Veri kontrol dili yani DCL
9:17
içerisinde güvenliğin çelik kapısı
9:20
diyebileceğimiz çok net bir komut
9:21
vardır. Dinay. Eğer belirli bir
9:24
kullanıcının veya grubun spesifik bir
9:26
tablo üzerinde veri eklemesini,
9:28
silmesini veya o veriyi görmesini kesin,
9:31
net ve mutlak bir şekilde reddetmek yani
9:34
yasaklamak istiyorsanız kullanacağınız
9:36
tek komut budur. Geçit yok demektir.
9:38
Güvenliği sağladık. Dışarıdan kimse
9:40
giremiyor. Peki ya içeride donanımsal
9:43
bir felaket yaşarsak? Sistemin çökmesine
9:45
karşı en büyük sigorta poliçemiz tam
9:48
kurtarma modeli yani food recovery
9:50
modeldir. Yeni açılan bir SQL veri
9:52
tabanı zaten varsayılan olarak bu
9:54
modelle gelir. Bu sistem veri
9:56
tabanındaki tabiri caizse her bir
9:58
nefesi, her bir işlemi saniye saniye LDF
10:01
ve MDF dosyalarına kaydeder ve size
10:04
adeta zamanda yolculuk yaparak sıfır
10:06
veri kaybıyla sistemi geriye döndürme
10:08
şansı sunar. Resmen bir zaman makinesi.
10:11
Ancak burada çok dikkatli olmalısınız.
10:14
Bu işlemi saniye saniye kaydeden LDF log
10:16
dosyaları sürekli havayla dolan ve şişen
10:19
devasa bir balon gibidir. Disklerin
10:22
kontrolsüzce dolup patlamasını
10:23
engellemek için bu dosyaların
10:25
özelliklerine mutlaka bir büyüme kuralı
10:27
olan autogrowad ve maksimum bir boyut
10:30
limiti yani max file size koymak
10:32
zorundasınız. Aksi takdirde bu dosyalar
10:35
şişer, genişler ve sunucudaki tüm diski
10:37
bir kara delik gibi yutarlar. Bu ayarı
10:40
sakın ama sakın atlamayın. Evet, bu
10:42
harika inşaatı bitirdik. En temel
10:44
kurallardan o akıllı otomasyonlara ve
10:47
çelik gibi güvenlik önlemlerine kadar
10:49
her şeyi tek gördük. Şimdi bu kapsamlı
10:51
özetimizi tamamlarken size o son ve
10:54
düşündürücü soruyu sormak istiyorum.
10:56
Bugün incelediğimiz bu devasa SQL
10:58
ekosistemine baktığınızda kendi
11:00
verileriniz bugün gerçekte ne kadar
11:02
güvende ve ne kadar optimize. Umarım
11:04
bugün beraber kurduğumuz bu yapı hem
11:06
sınavınızda hem de profesyonel
11:08
hayatınızda o büyük resmi çok daha net
11:10
görmenizi sağlar. Hepinize şimdiden
11:12
üstün başarılar dilerim. Öğrenmeye devam
11:14
edin. Hoşça kalın.