0

Veritabanı Temel kavramlar ve Modelleme Bölüm 4

Evet İlişkilerden de bahsettikten sonra şimdi gelelim veritabanı ile nasıl konuşup , nasıl anlaşacağımıza… Herkes’in bir dili olduğu gibi veritabanı ile konuşmanın da bir dili var bu dilin adı ad ” SQL ( Structured Query Language ) ” .

Çok eskiden beri kullanılan ve pek değişmeyen ve değişeceğini de pek ummadığımız bir veritabanı konuşma dili . Tabi bu yazıda sql dilinin komutlarından bahsetmeyeceğim onun için internette aratma yaparsanız birçok yer var hatta ingilizceniz iyi ise w3school    gayet güzel. 

Madem SQL komutlarını da hallettik (“Bu aradaki kısım biraz uzun zaman alabilir :)) şimdi veritabanı nasıl modellenir nelere dikkat edilir bunlardan bahsedelim.

Veritabanı tasarımı gerçekten hem zor hemde zaman alan bir iştir çünkü işin temeli burada atılacaktır ve oluşturduğunuz veri yapısına göre arayüz tasarlayıp tabiri caiz ise üstüne elbise dikeceksiniz.

Program yazarken algoritma yapmaya üşendiğimiz gibi bir projeye karar verince hemen bilgisayar başına geçenlerimiz çok olabilir. Ancak bu gerçekten program yazarken de veritabanı tasarlarken de güzel bir yöntem değildir. Kağıt ve Kalem hiç bir zaman modası geçmeyen öğrenme materyalleridir. Öncelikle kağıt kalemi alıp kendi yada sizden isteyen kişinin ihtiyacını tam olarak şekillendirmeniz lazım. Problemi iyi analiz etmek lazım. Problemi Açık bir şekilde ifade etmemiz lazım…. Tabloları mümkün mertebe alt tablolara bölüp içindeki verilerin atomik  yapıda olmasını sağlamak lazım.  Atomik yapı nedir ???   Atomik yapıdan kastımız girilen veri daha bölünemeyecek halde olmasıdır. 

Diyelim ki adSoyad diye bir alan yaptınız ve içine ” Ahmet ÇETİN” şeklinde bir data yerleştirdiniz. Bu data atomik bir data değil. neden ? çünkü ben Ahmet , i ayrı ÇETİN ‘i ayrı sorgularda kullanmak isteyebilirim. Örnegin : Soyadı Çetin olanları görmek istesem nasıl olacak gibi…

Tablolarımızın isimlerini verirken , tablolara eklediğimiz alan isimlerini verirken belirli bir notasyon takip etmeliyiz. bir öyle bir böyle bir yapı kurmamalıyız. Çünkü bir sistem tasarlıyorsunuz ve her zaman derli toplu ve anlaşılabilir olmalı

Tablolardan sonra alanlara uygun veri türleri atanmalı ki tutarsız bilgi eklenmesin

Kayıt içinde zorunlu alan olup olmadığına karar verilmeli veritabanımız eğer zorunlu alanlar dolmazszsa kaydı yapmayacaktır.

Primary Key’ler belirlenmeli ve bu alanlar “UNIQUE” yani benzersiz değerler almalıdır. Eğer tablonuz da doğal  bir primary key varsa “Tc numarası ” gibi bunu primary key yapabilirsiniz. Eğer yoksa “ID” şeklinde bir sentetik bir primary key oluşturmak lazım ve bunu auto increment ile otomatik arttırmalı.

 

admin

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir