DATABASE DESIGN

BÖLÜM 1: GİRİŞ
Data (veri), ham veya işlenmemiş materyal. İşlendiği zaman information (enformasyon). Örneğin bir sınıftaki
her öğrencinin notu veri iken bu sınıfın not ortalaması information olarak adlandırılır.
Database (veri tabanı), genellikle bilgisayar sistemlerinde depolanan yapılandırılmış verilerden oluşan düzenli
bir koleksiyondur.
Veri tabanı geliştirme süreci 3 adımdan oluşur:
Analiz etmek (Analyze) Kavramsal veri modelleme, Tasarlamak (Design) Veri tabanı tasarımı,
Kurmak (Build) Veri tabanı oluşturma
Table instance (oluşturulan örnek) chart aşağıdakilerden oluşur;
Tablo adı, kolon adları, anahtarlar PK (birincil anahtar), her bir satırdaki veri için benzersiz tanımlayıcı,
FK (yabancı anahtar) tablodaki veriyi başka bir tablodaki verinin PK ile bağlar. Null, bir kolonda değer
bulunmasının zorunlu olduğunu gösterir.
Unique: Kolonda bulunan değerin benzersiz olduğunu gösterir.
Data type: Kolonda bulunan değerin tanımı ve biçimini tanımlar.
VERİ TABANI GELİŞTİRME SÜRECİ Adım 3 Veri tabanı Oluşturma: SQL Notlarına bakın. (İlk kısım)
Hardware (donanım): Bilgisayarın fiziksel kısımları.
Software (yazılım): Donanıma ne yapması gerektiğini söyleyen programlar (talimat setleri).
Operating System (işletim sistemi): Donanımı direkt olarak kontrol eden ve yöneten yazılım.
Application (uygulama): Belirli işlemleri yerine getirmek için özel olarak oluşturulan yazılım programı.
Client (istemci): İstemciler klavyesi, ekranı ve faresi olan iş istasyonları veya bilgisayarlardır.
Server (sunucu): İstemcilerden iş istekleri alan ve çalıştırıp sonuçlarını döndüren daha güçlü bilgisayarlardır.
Tier-2 sistemde istemciler sunucularla direkt iletişim kurabilirken, Tier-3 sistemde sunucu ile istemci arasında
üçüncü bir bilgisayarla iletişim kurar, üçüncü bilgisayar istekleri sunucuya yönlendirir buna application server
veya web server denir.
Grid computing (dağıtılmış hesaplama), çeşitli görevleri gerçekleştirmek için birlikte çalışan bir
bilgisayarlardır.
Cloud Computing (bulut bilişim), istendiği zaman kullanılabilen ve kullanıcılar arasında paylaşılan bilgisayar
kaynakları sağlayan, internet tabanlı bilişim hizmetlerinin genel adıdır.
Infrastructure (altyapı)

BÖLÜM 2: VARLIKLAR (ENTITIES) VE NİTELİKLER (ATTRIBUTES)

Kavramsal Model: İşlevsel ve bilgiye dayalı ihtiyaçları fark etmemizi sağlar. Kavramsal model önemli varlıkları
(veri tabanında tablo olabilecek) ve varlıklar arasındaki ilişkiyi tanımlar. Varlıkların niteliklerini ve benzersiz
tanımlayıcıları (veri tabanında PK olacak nitelikleri) belirtmez.
Mantıksal Model, Fiziksel Model, Veri Modelleme
Entities (varlıklar), işletme için önemli olan bir şeyin hakkında hangi verilerin bilinmesi gerektiği. Genellikle
isimdir. Varlıkların instance (varlıktan oluşturulan örnek) vardır. Instancelar varlıkların tekil oluşumudur.
Kişi – Ali Veli Ürün – W11 home İş – Mühendis Hayvan – Kedi
Varlıklar nontangible (soyut) ve tangible (somut) olabilir.
Attributes (nitelikler), varlıkları tanımlamak, ölçmek, sınıflandırmak ve belirtmek için kullanılır.
Müşteri – Adı, Siparişi, mail, no örnek verilebilir. Bazı nitelikler zamanla değişebilir yaş gibi bu volatile
(değişken) olarak adlandırılır. Nonvolatile (değişken olmayan) arabanın modeli gibi. 3 tip nitelik vardır bunlar
zorunlu nitelik, null nitelik ve isteğe bağlı nitelik.
Unique Identifiers (benzersiz tanımlayıcılar), bir varlığı diğerlerinden ayırmak için kullanılır. T.C. no gibi.
Implementation-Free Models (Pseudo kodun varlıklar için olanı) Kullanılan dile, bilgisayara ve veri tabanına
göre değişmez.
Entity Relationship Model (Varlık İlişki Modeli), bütün varlıkların, niteliklerin ve bunlar arasındaki ilişkilerin
bulunduğu listedir. 4 hedefi vardır: gereken verilerin toplanması, bir verinin sadece bir kez görünmesi,
modellenen veriden başka bir veri türetilmeyecek şekilde modellenmesi, verinin tahmin edilebilir bir yerde
bulunması.

BÖLÜM 3: İLİŞKİLER
Cardinality (sayısallık) – How many ve Optionality (isteğe bağlılılık) – May or must?
Her çalışanın sadece ve sadece bir işi olmalıdır (must)
Her iş bir veya birkaç çalışan tarafından yapılabilir (may)
Varlıklar köşeli kutular ile ifade edilir, tekil isimler kullanılır ve büyük harflerle yazılır.
Zorunlu nitelikler * ile, isteğe bağlı nitelikler o ile, benzersiz tanımlayıcılar # ile gösterilir. Benzersiz
tanımlayıcılar her zaman zorunlu olduğundan ayrıca bir * işaretine gerek yoktur.
Düz çizgiler zorunluluğu, kesik çizgiler isteğe bağlılığı temsil eder. Must veya may
3lü çizgi (karga ayağı) sayısallığı ifade eder. One or more veya one and only one

BÖLÜM 4: SUPERTYPE, SUBTYPE ve İŞLETME KURALLARI

Bazı varlıklar diğer örneklerinin sahip olmadığı ilişki ve özniteliklere sahip olabilir. Örnek olarak ödeme
yöntemleri nakit, çek, ve kredi kartı.
Yapısal iş kuralları, depolanacak bilgi türlerini ve bilgi öğelerinin nasıl ilişkili olduğunu gösterir.
Prosedür kuralları, bir işletmenin ön koşulları, adımları, süreçleri veya iş akışı gereksinimlerini ele alır.

BÖLÜM 5: İLİŞKİNİN TEMELLERİ

Optionality Cardinality Transferability
 Intersection entity
CRUD (CREATE, RETRIEVE, UPDATE, DELETE)
Oluşturma, alma, güncelleme ve silme gereksinimlerinin belirlenmesi, bir analiz yöntemidir.
Fonskiyonlar için anahtar kelimeler;
CREATE - INPUT, ENTER, LOAD, IMPORT, RECORD, & CREATE
Bunların hepsi veri tabanında bir kayıt oluşturulacağını belirtir.
RETRIEVE - VIEW, REPORT, BRING UP, PRINT, FIND, READ, & LOOK UP
Bunların hepsi veri tabanından bir bilgi alıncağını belirtir.
UPDATE - CHANGE, MODIFY, ALTER, & UPDATE
Bunların hepsi veri tabanında halihazırda bulunan verinin değiştirileceğini belirtir.
DELETE - DISCARD, REMOVE, TRASH, PURGE, & DELETE
Bunların hepsi veri tabanında halihazırda bulunan verinin silineceğini belirtir.

BÖLÜM 6: BENZERSİZ TANIMLAYICILAR (UIDs) VE NORMALİZASYON

Doğru benzersiz tanımlayıcıyı seçmek önemlidir bir veriyi geri kalan verilerden ayırır.

Artificial UIDs, doğuştan olmayan sonradan eklenen değerler. Öğrenci numarası gibi.

Artificial UID Intersection entity.

CANDIDATE (ADAY) KEY
İki veya daha fazla UID mevcutsa, bunlardan biri primary öteki candidate olarak adlandırılır.
Normalizasyon
Arkadaşlarımızın telefon numaralarını 3 farklı yerde sakladığımızı düşünelim. Defter, cep telefonu ve
bilgisayar. Eğer arkadaşlarımızdan biri telefon numarasını değiştirirse 3 farklı yerden değiştirmek uğraştırıcı
olur. Aynı şekilde eğer veri tabanında bir veri birden fazla yerde tutulursa hem gereksiz yer kullanır hem
değiştirirken uğraştırıcı olur veya kayıtlardan yanlış girilebilir.
Normalizasyonun amacı veriyi tek bir yerde ve mümkün olan en iyi yerde tutmaktır.
İlk Normal Durum ((1NF) First Normal Form)
Çoğul değer alabilen öznitelikler olmamalıdır.
 Store information in one place only and in the best possible place.
İkinci Normal Durum ((2NF) Second Normal Form)
UID olmayan öznitelikler UID’e bağlı olmasını (özelliği veya özelliği olmasını) gerektirir.

Bankanın konumu hesap numarasının bir özelliği değildir.

Eğer banka konumu konumu değişirse o bankada açılan
hesapların güncellenmesi gerekir.

Item Price yanlış tabloda kullanılmış. Bu ikinci kuralın ihlalidir. Item Price, Product tablosunda bulunmalı.

Üçüncü Normal Durum ((3NF) Third Normal

Form)
UID olmayan öznitelik başka bir UID olmayan özniteliğe bağımlı olamaz.
 Third normal form requires that not only every non-key column be dependent on the entire primary
key, but that non-key columns be independent of each other.

Geçişken bağımlılıklara izin vermez. Geçişken bağımlılık, bir varlığın özniteliğinin söz konusu
varlığın başka bir özniteliğine bağlı olmasıdır.
Eğer mağaza adresi değişirse, o mağazadan satın alınan bütün CDlerin
adresinin değişmesi gerekir.
Mağaza adresi CD numarasına (CD’nin UIDsi) bağlıdır. Ama aynı
zamanda mağaza ismine (UID olmayan) de bağlıdır. Bu 3NF kuralının
ihlalidir ve tablo normalize edilebilir.

CD ile ilişkili mağaza varlığı oluşturularak normalizasyon yapılabilir.

Partner birth date, partner’in özniteliğidir employee’nin

değil.
UID olmayan öznitelikler kendi özniteliklerine sahip
olamazlar.

BÖLÜM 7: ARCS (YAYLAR), HİYERARŞİLER, REKÜRSİF MODELLEME

Constraints: Kısıtlamalar.
Exclusive or: Bir varlığın 2 veya daha fazla varlıkla ilişkisinin aynı anda sadece birinin geçerli olmasıdır. Bu
tür ilişkiler yaylarla gösterilir.
Burada yayın dışında kalanlar sadece bir
TRANING EVENT örneği (instance) ile ilişkisi olabilir.
Yaylar birbirini dışlayan ilişkileri göstermek için kullanılır
(Mutually exclusive)

Each MEMBERSHIP must be held by one COMPANY or

must be held by one CUSTOMER, but not both.
Yayın dışında kalanların ilişkileri ya hepsi zorunlu ya
hepsi isteğe bağlı olmalıdır.

Sub/Supertype’lar yaylar ile ifade edilebilir. Benzer özniteliklerin yaylar ile ifade edilmesine gerek yoktur.
Solda hiyerarşi, sağda rekürsif modelleme.

BÖLÜM 8: DEĞİŞİKLİKLER VE TARİHSEL MODELLEME

Data over time zamanla değişen veri. Örneğin kiralama.

Bu tablo sadece şimdiki kiracasını gösterir. Tablo M:M olarak

düzenlenmeli ve UID’ler seçilmelidir.
 Option 1: Barred relationship
Bu şekilde çizmek tasarımımıza uygun değildir çünkü MOVIE
STAR’ın aynı JEWELRY PIECE’i farklı tarihlerde kiralamasına
izin vermez.
X kişisi K kolyesini t tarihinde kiralamış olsun. Bu ilişkiye göre X
kişisi K kolyesini bir daha kiralayamaz çünkü UID aynı
kombinasyondaki MOVIE STAR id ve JEWELERY PIECE code
birden fazla girilemez.

Option 2: Barred
relationship and Rental Date
RENTAL DATE’i UID yapmak farklı tarihlerde aynı
JEWELERY PIECE kiralamasına izin verir fakat aynı zamanda
diğer MOVIE STAR lar da aynı tarihte kiralayabilirler.
Her instance benzersiz değerlere sahip olduğundan model
buna izin verir ancak gerçek hayatta bu mümkün değildir.

Option 3: Barred relationship between MOVIE STAR and

RENTAL HISTORY with Rental Date
Bu model ise o tarihte aynı MOVIE STAR ın birden fazla
JEWELRY PIECE kiralamasına izin vermez.
Çünkü, MOVIE STAR id + rental date benzersiz olmalıdır.

Option 4: Barred relationship between JEWELRY PIECE

and RENTAL HISTORY with Rental Date
Bu model ise JEWELRY PIECE aynı tarihte sadece bir kez
kiralanabilir.
JEWELRY PIECE code ve rental date kombinasyonu
benzersizdir.

Barred relationship: A relationship that participates an entity’s UID.

Değişimleri Modellemek 1 - Zaman
3. Normal Durum kuralına göre, UID olmayan öznitelikler kendi
özniteliklerine sahip olamaz. Bu tabloda tutulmak istenen sıcaklık değerleri
gün ile ilişkilendirildiğinden kural ihlali olur.

Bu tabloları ayırmak bize daha fazla veri tutabilme imkanı sağlar.

Örneğin artık DAY tablosuna tatil günlerini dahil edebiliriz.

Conditional non-transferability
Bazı durumlarda transfer edilebilirken örneğin
shift daha başlamamışken bazı durumlarda
transfer edilemez. Bu durum ERD’de
gösterilemeyeceğinden dökümantasyonda
belirtilmelidir.

Değişimleri Modellemek 2 – Fiyat

Appreciation (Değer, takdir) Değerin veya fiyatın artması, özellikle
zamanla
Depreciation (amortisman) Değerin azalması veya kaybı savaş, aşınma,
piyasa koşulları
Fiyat değişimleri neden kullanılır?
Stock market (Borsa)
Fuel Industry (Yakıt endüstrisi)
Construction Businesses (İnşaat şirketleri)
…

Okunabilirlik için ortak düşünceler

ERD çizerken herhangi bir resmi kural yoktur. Tabloda önemli olan, bütün varlıkların, özniteliklerin ve
ilişkilerin bulunması ve ERD’nin açık ve okunabilir olması önemlidir.

Büyük hacimli varlıklar genelde sol üst veya sağ üst köşeye konur.
BÖLÜM 9: MAPPING (HARİTALAMA)
İlişkisel veri tabanı konseptlerine giriş

Peki tabloda aradığımız değeri bulmak için tek tek bütün satırlara mı bakacağız? Hayır. Bunun için SQL
kullanacağız. (SQL kısımları SQL Notları dosyasında mevcut bu dosya sadece veri tabanı tasarımını içerir.)

PRIMARY KEY (BİRİNCİL ANAHTAR)

CANDIDATE KEY (UNIQUE KEY / ALTERNATE KEY)
COMPOSITE KEY (KOMPOZİT ANAHTAR) Birden fazla
PK’dan oluşur.

FOREIGN KEY (İKİNCİL ANAHTAR)

Başka bir tablonun PK’sı o tabloda FK’dir.
Sütun bütünlüğü kuralları Bir sütun, o sütun için tanımlanan veri tipiyle tutarlı olmalıdır.
Veri bütünlüğü kuralları (Data-integrity veya constraints (kısıtlamalar)) veritabanın ilişkisel olarak doğru
durumda olmasını sağlar.

Unique Key olan PAYROLL_ID kısmı tabloda aynı değere sahip başka bir satır olamayacağı anlamına gelir.
Basit Haritalama : Dönüşüm süreci
İlişki haritalama

İsteğe bağlı ilişkiler ek bir programlama ile belirtilmelidir.

Transfer edilemez ilişki tablodaki FK’in değiştirilemeyeceği anlamına gelir.
 Bu durumda FK’in önemi artar çünkü aynı zamanda PK durumundadır.
Barred relationship örneği
Cascade barred relationship örneği

Many to many ve one to one ilişkilerin haritalanması. M:M Intersection entity FK sütunları tabloları gösterir.
O:O bir FK ve UK oluşturulur. Eğer ilişki tek taraflı zorunlu ise fk o tabloda oluşturulur.

Opsiyonel O:O ise işletmenin kurallarına göre değişebilir.

FK işletme için hangi tablo daha uygunsa ona yerleştirilebilir.
Bunun bir kuralı yoktur.
 Yaylar haritalanırken FK’ler mandatory olsa bile isteğe bağlı
kabul edilmedilir çünkü sadece biri geçerli olabilir (XOR)
Ek bir kodlama iki FK’den birinin bir sütunu ifade etmesi için
gereklidir. Bunun için check constraintler kullanılabilir.

Alttip Haritalama