Up next in 10
Auzef Veri Tabanı Yönetimi 2025-2026 Vize Soruları
https://lolonolo.com/2026/05/08/veri-tabani-yonetimi-2025-2026-vize-sorulari/
https://lolonolo.com
Show More Show Less View Video Transcript
0:00
Herkese selam. Yaklaşan veri tabanı
0:02
yönetimi vizenize hazırlanmak için
0:03
hazırladığımız bu özel anlatıya hoş
0:06
geldiniz. Bugün o karmaşık gibi görünen
0:08
konuları adım adım çok net bir şekilde
0:10
çözeceğiz ve sınavı sorunsuz bir şekilde
0:12
atlatmanızı sağlayacağız. Sadece en
0:15
kritik noktalara, kaynak materyalin tam
0:17
özüne odaklanıyoruz. Hazırsanız hadi
0:20
lafı hiç uzatmadan hemen konuya dalalım.
0:23
Önümüzde harika bir yol haritası var.
0:25
Birinci sırada veri tabanı sistemlerinin
0:27
evrimi var. Ardından SQL ve yönetim
0:30
araçlarına, oradan tasarım, ERD ve ORM
0:34
kavramlarına geçeceğiz. 4üncü adımda
0:37
büyük veri ve özgür yazılım felsefesine
0:39
değinip en sonda da vize soru
0:41
çözümleriyle her şeyi zihnimize
0:43
kazıyacağız.
0:45
Bölüm 1. Veri tabanı sistemlerinin
0:47
evrimi. Peki her şey nasıl başladı?
0:50
Şimdi veri depolamak deyince
0:52
birçoğumuzun aklına doğal olarak hemen
0:54
Excel geliyor. Excel harika bir araç
0:57
buna şüphe yok. Ama Excel'le gerçek bir
0:59
ilişkisel veri tabanı arasında devasa
1:02
bir uçurum var. Yani neden böyle
1:04
karmaşık bir sisteme ihtiyaç duyduk ki?
1:07
İki sihirli sebep var. Eş zamanlı
1:09
kullanıcı sayısı ve veri tutarlılığı.
1:12
Excel'de aynı anda yüzlerce kişinin aynı
1:15
dosyaya girip bir şeyleri değiştirmeye
1:16
çalıştığını hayal edin. Tam bir kaos
1:18
değil mi? İşte ilişkisel veri tabanları
1:21
tam olarak bu simültane kullanıcı
1:23
karmaşasını çözmek ve verilerin her
1:25
zaman herkes için tutarlı kalmasını
1:27
sağlamak amacıyla inşa edildi. Bu devasa
1:30
ihtiyaca cevap olarak da endüstrinin
1:33
ağır topları sahneye çıktı. Microsoft
1:35
dünyasının vazgeçilmezi SQL Server, dev
1:38
kurumsal B2B hizmetlerinin belkemiği
1:40
olan Oracle Database ve tabii ki açık
1:43
kaynak dünyasının o parlayan yıldızları
1:45
Mysequel ve PostgrQL. İşte bunlar
1:48
verilerin güvenli ve o alıştığımız
1:50
düzenli satır sütun yapısında saklanması
1:52
için endüstrinin altın standartları
1:55
oldular. Ama teknoloji yerinde durmuyor.
1:57
Biliyorsunuz geleneksel sistemler veriyi
2:00
güvenceye almak için sürekli diske
2:02
yazar. Fakat diske yazmak epey zaman
2:04
alan bir işlemdir. Peki ya bize akıl
2:07
almaz bir hız lazımsa? İşte Redis oyunu
2:10
tam burada bozuyor. Geleneksel diske
2:12
yazma mantığını bir kenara bırakıp
2:14
veriyi duran RAM üzerinde yani in memory
2:16
olarak tutuyor. Bu da o hantal disk
2:18
gecikmelerini tamamen çöpe atıp
2:20
milissaniyenin bile altında şimşek
2:22
hızında veri transferi sağlıyor. Sınav
2:24
için bu milisaniye ve RAM ilişkisini
2:26
mutlaka ama mutlaka aklımızın bir
2:28
köşesine yazalım. Tamam. Hız problemini
2:31
Redis'le çözdük. De ki verilerimiz
2:33
eskisi gibi o katı düzenli tablolara
2:35
sığmıyorsa artık günümüzde veri her
2:38
şekilde akıyor. İşte tam bu noktada
2:40
Mongo DB gibi no SQı sistemleri evrildi.
2:43
Mongo DB o sıkıcı ve katı tablolar
2:45
yerine yapılandırılmamış esnek verileri
2:48
Jason benzeri dokümanlar olarak
2:50
saklıyor. Klasik şemalara uymayan bu
2:52
modern dağınık veriler için kesinlikle
2:54
harika bir çözüm. Bölüm 2. SQL ve
2:57
yönetim araçları. Makinelerla nasıl
3:00
konuşuruz? Modern veri tabanlarının
3:02
mimarlarından Edgar F. Cadden çok net
3:04
bir vizyonu vardı. Asıl can alıcı nokta
3:07
tam da onun şu amacında saklı. KOD SQL'i
3:10
yaratırken yeni bir üst seviye dil
3:12
ortaya çıkarmayı hedefledi. Yani sadece
3:15
bilgisayarların soğuk dünyasına ait
3:17
olmayan, aynı zamanda biz insanların da
3:19
mantığını kolayca kavrayabileceği veri
3:21
tabanlarıyla rahatça konuşmamızı
3:23
sağlayan o evrensel köprüyü kurmak
3:25
istedi. Bu köprü dilin dört temel sütunu
3:28
var. Yeni bir kayıt eklemek için ınsert,
3:31
mevcut bir şeyi değiştirmek için update
3:33
ve silmek için delete kullanıyoruz. Ama
3:36
burada çok kritik bir duraklama yapalım.
3:38
Veri sorgulamak için kullandığımız
3:40
select komutu. Bakın bu çok önemli.
3:42
Select tablodaki veriyi hiçbir şekilde
3:45
yapısal olarak değiştirmez. Sadece okur.
3:48
Veriye dokunmadığı için aralarında en
3:51
güvenli dim yerindeyse sadece bana ne
3:54
olduğunu göster diyen yegane komuttur.
3:57
Tabii zamanla şu anlaşıldı. Herkes bu
3:59
kodları satır satır yazmak istemiyor ya
4:02
da buna vakit yok. Evrimin bir sonraki
4:05
doğal adımı bizleri bu kod
4:07
kalabalığından kurtarmaktı. Veri tabanı
4:09
yönetim araçları mesela PHP My Admin
4:12
gibi yazılımlar tam bir kurtarıcı oldu.
4:15
Artık tek bir satır SQL yazmadan sadece
4:18
görsel pencereler, butonlar ve sürükle
4:20
bırak mantığıyla devasa veri tabanlarını
4:22
yönetebiliyoruz. İşleri ne kadar
4:24
hızlandırdığını bir düşünün. Bölüm 3.
4:27
Tasarım ERD ve ORM. Kod yazmadan önceki
4:31
o kritik mimari aşamalar. Hiçbir devasa
4:34
göktelen elinizde sağlam bir mimari plan
4:37
olmadan inşa edilemez. Değil mi? Aynı
4:40
kural veri tabanları için de geçerli.
4:42
Varlık ilişki diyagramı yani ERD
4:45
klavyeye dokunup tek bir satır kod bile
4:47
yazmadan önce masaya yatırdığımız temel
4:50
mimari plandır. Varlıkların
4:52
özelliklerini ve birbiriyle olan
4:54
bağlarını görselleştirmemizi sağlar. Bu
4:56
aşamayı es geçmek karanlıkta yürümeye
4:59
benzer. Diyelim ki planı çizdik, mimari
5:02
tamam, şimdi kodlama zamanı. Ama
5:04
geliştiriciler için her defasında uzun
5:07
uzun HamSQL sorguları yazmak gerçekten
5:09
büyük bir yorgunluk. İşte burada sahneye
5:11
ORM yani object relational mapping
5:14
çıkıyor. ORM programlama dilindeki
5:16
nesneleri alıp doğrudan veri tabanındaki
5:19
tablolarla eşitliyor. Geliştiriciler
5:21
HAMSQL yazmak yerine kendi dillerinde
5:23
alışkın oldukları 10 nesne yönelimli
5:25
kodlarla veri tabanına
5:26
hükmedebiliyorlar. İnanılmaz büyük bir
5:28
rahatlık. Sınavda karşınıza çıkma
5:31
ihtimali çok yüksek olan spesifik bir
5:33
detaya değinelim. Python dünyasında ORM
5:36
denildiğinde akla ilk gelen efsane
5:37
kütüphane Skol elçemidir. Anaconda
5:40
dağıtımı içinde tıkır tıkır çalışan bu
5:42
araç az önce konuştuğumuz o butonlu,
5:45
pencereli görsel yönetim araçlarından
5:47
tamamen farklıdır. Grafiksel bir arayüzü
5:49
yoktur. Tamamen kod tabanlıdır ama bizi
5:52
o karmaşık SQL yazma haallığından
5:54
kesinlikle kurtarır. Bölüm 4. Büyük veri
5:58
ve özgür yazılım. İşin felsefi ve devasa
6:01
boyutları. Geleneksel sistemlerle artık
6:04
başa çıkamayacağımız kadar devasa
6:07
saniyeler içinde çığ gibi büyüyen ve son
6:09
derece karmaşık veri yığınları buna
6:11
büyük veri diyoruz ve bu durum bize
6:13
harika bir şey kanıtlıyor. Mongo DB gibi
6:16
esnek şemalı No cla sistemlerinin
6:18
yükselişi kesinlikle bir tesadüf
6:20
değildi. Büyük verinin bu zaptedilemez
6:22
kaotik yapısı doğal olarak o esnek ve
6:25
yeni nesil sistemleri doğurdu. İşin
6:28
içine bu kadar devasa veri girince
6:30
elbette etik tartışmalar da alevleniyor.
6:33
Bir tarafta şeffaflığı, gizliliği, kodu
6:35
sınırsızca inceleme ve değiştirme
6:37
özgürlüğünü savunan Özgür Yazılım
6:39
felsefesi duruyor. Diğer yandaysa
6:41
yazılımı kullanırken sizin
6:43
hareketlerinizin, verilerinizin zorunlu
6:45
olarak arka planda kaydedilmesi anlamına
6:47
gelen telemetri uygulamaları var.
6:50
Kaynaklarımızın da tarafsızca ortaya
6:52
koyduğu gibi verilerin kullanıcıdan
6:54
bağımsız ve zorunlu olarak toplanması
6:56
doğası gereği şeffaflığı merkeze alan
6:58
Özgür yazılım etiyle tamamen ters
7:00
düşüyor. Ve bölüm 5, vize soru
7:03
çözümleri. Hadi bakalım öğrendiğimiz bu
7:06
evrimsel bilgileri sınav pratiğine
7:08
dökelim. Şöyle bir düşünelim. Soru diyor
7:11
ki, "Veri tabanı tablolarının kod
7:14
yazmadan grafiksel arayüz kullanarak
7:16
tanımlanmasını sağlayan yöntem
7:18
aşağıdakilerden hangisidir? Şıklarımız:
7:21
ORM, veri tabanı yönetim aracı, yapısal
7:24
sorgu dili, programlama dili ve veri
7:27
tabanı yönetim sistemi. Bizi o SQL yazma
7:30
zahmetinden kurtaran sadece tıklayarak
7:33
iş bitirdiğimiz grafiksel arayüzü bir
7:35
hatırlayalım. Evet, buldunuz bile. Cevap
7:38
B şıkkı. Veri tabanı yönetim aracı. PHP
7:41
My Admin veya DBE gibi sistemleri
7:43
konuşmuştuk hatırlarsanız. Bu GUI
7:46
yöntemleri yani görsel arayüzler o
7:48
karmaşık kod dünyasıyla kullanıcı dostu
7:51
pratiklik arasındaki mükemmel
7:52
köprülerdir. Gelelim ikinci sorumuza.
7:55
Verilerin bellek üzerinde tutulup diske
7:58
hemen yazılmaması sayesinde çok hızlı
8:00
veri giriş çıkışına olanak sağlayan VTYS
8:03
aşağıdakilerden hangisidir? Seçenekler
8:06
MySQL, Microsoft Excels, Redis, SQL
8:10
Server ve Mongo DB. Diske yazmanın o
8:13
yavaş hantal yapısından kurtulup RAM'i
8:16
kullanan hani o meşhur milisaniye hızına
8:19
ulaşan sistemi soruyor bize. Kesinlikle
8:22
cevap C şıkkı. Redis. Redis'in o harika
8:25
in memory yani bellek içi depolama
8:28
mimarisi sayesinde disk gecikmelerinin
8:31
nasıl tamamen ortadan kaldırdığını
8:32
detaylıca işlemiştik. Sınav kağıdında
8:35
RAM ve hız kelimelerini yan yana
8:37
gördüğünüz an aklınıza ilk gelecek isim
8:40
Redis olmalı. Ve işte sınav konularını
8:43
başarıyla devirdik. Ancak bitirmeden
8:46
önce sizi şu kritik düşünceyle başa
8:48
bırakmak istiyorum. Geleceğin mimarları
8:50
olarak bu devasa sistemleri sizler inşa
8:53
edeceksiniz. Peki büyük verinin o
8:56
korkutucu derecede devasa gücüyle Özgür
8:58
Yazılımın savunduğu gizlilik ve
9:00
şeffaflık etiği arasındaki o ince
9:02
dengeyi nasıl kuracağız? Bu muazzam gücü
9:05
nasıl adil yöneteceğimiz teknolojinin
9:07
asıl geleceğini belirleyecek. Bu
9:09
anlatının sonuna geldik. Umarım taşlar
9:11
yerine oturmuştur. Vizenizde hepinize
9:14
şimdiden sonsuz başarılar diliyorum.
#Jobs & Education