Skip to main content

Veritabanı Tasarımı: Önlemek için Ortak Hatalar

Yüzlerce kayıt veya milyonlarca kayıt bulunduran bir veritabanıyla çalışsanız da, uygun veritabanı tasarımı her zaman önemlidir. Bilgiyi sadece daha kolay elde etmekle kalmayacak, aynı zamanda gelecekte veritabanını genişletmeyi de kolaylaştıracaktır. Ne yazık ki, gelecekte işleri zorlaştırabilecek birkaç tuzağa düşmek kolaydır.

Bir veritabanının normalleştirilmesi konusunda yazılmış bütün kitaplar var, ancak burada gösterilen yaygın hatalardan kaçınmanız durumunda, iyi bir veritabanı tasarımı için doğru yolda olacaksınız.

Veritabanı Hatası # 1: Tablodaki Alanları Yineleme

İyi bir veritabanı tasarımı için temel bir kural, tekrar eden verileri tanımak ve bu yinelenen sütunları kendi tablolarına koymaktır. Tablodaki yinelenen alanlar, elektronik tablo dünyasından gelenler için yaygındır, ancak elektronik tablolar tasarımla düz olma eğilimindeyken, veritabanları ilişkisel olmalıdır. 2D'den 3D'ye gitmek gibi.

Neyse ki, tekrarlayan alanlar genellikle tespit etmek kolaydır. Sadece bu tabloya bir göz atın:

Sipariş KimliğiÜrün1product2product3
1Oyuncak ayılarJöle Fasulye 
2Jöle Fasulye  

 

Bir sipariş dört ürün içerdiğinde ne olur? Üçten fazla ürünü desteklemek için masaya başka bir alan eklememiz gerekecek. Verileri girmemize yardımcı olması için masa etrafında bir müşteri uygulaması oluşturduğumuzda, yeni ürün alanıyla değiştirmemiz gerekebilir. Ve tüm siparişleri Jellybeans'le sırayla nasıl bulabiliriz? Tablodaki her ürün alanını aşağıdaki gibi görünebilen bir SQL deyimi ile sorgulamaya zorlayacağız: SELECT * FROM Ürünleri WHERE Ürün1 = 'Jöle Fasulyesi' VEYA Product2 = 'Jöle Fasulyesi' VEYA Ürün3 = 'Jöle Fasulyesi'.

Bütün bilgileri bir araya getiren tek bir tabloya sahip olmak yerine, her biri ayrı bir bilgi parçasına sahip olan üç tabloya sahip olmalıyız. Bu örnekte, siparişin kendisi hakkında bilgi içeren bir Siparişler tablosu, tüm ürünlerimizle birlikte bir Ürünler tablosu ve ürünleri siparişe bağlayan bir ProductOrders tableti istiyoruz.

Sipariş KimliğiMüşteri KimliğiSipariş tarihiGenel Toplam
171/24/1719.99
291/25/1724.99

 

Ürün kimliğiÜrünsaymak
1Oyuncak ayılar1
2Jöle Fasulye100

 

ProductOrderIDÜrün kimliğiSipariş Kimliği
10111
10221

 

Her tablonun kendine özgü bir kimlik alanına sahip olduğuna dikkat edin. Bu birincil anahtardır. Tabloları, başka bir tabloda bir yabancı anahtar olarak birincil anahtar değeri kullanarak bağlarız. Ana anahtarlar ve yabancı tuşlar hakkında daha fazla bilgi edinin.

Veritabanı Hatası # 2: Tabloyu Tabloya Aktarma

Bu başka bir ortak hatadır, ama her zaman tekrarlayan alanlar kadar göze çarpmaz. Bir veritabanı tasarlarken, bir tablodaki tüm verilerin kendisiyle ilgili olduğundan emin olmak istersiniz. Farklı olanı tespit etmek için çocuğun oyununa benzer. Bir muz, çilek, şeftali ve televizyonunuz varsa, televizyon seti muhtemelen başka bir yere aittir.

Aynı hatlarda, satış elemanlarından oluşan bir tablonuz varsa, bu tablodaki tüm bilgiler, özellikle satış sorumlusuyla ilişkili olmalıdır. Bu satış kişisine özgü olmayan ekstra bilgiler veritabanınızda başka bir yere ait olabilir.

SalesIDİlkSonAdresTelefon numarasıOfisOfis telefonu
1SamElliot118 Main St, Austin, Teksas(215) 555-5858Austin şehir merkezi(212) 421-2412
2Alicedemirci504 2nd Street, New York, NY(211) 122-1821New York (Doğu)(211) 855-4541
3Joekilise428 Aker St, Austin, TX(215) 545-5545Austin şehir merkezi(212) 421-2412

 

Bu tablo, her bir satış temsilcisi ile ilgili gibi görünebilir olsa da, aslında masanın içine gömülü bir tablo var. Office ve OfficeNumber'in "Austin Downtown" ile nasıl tekrar edildiğine dikkat edin. Bir ofis telefon numarası değişirse ne olur? Tek bir bilgi değişiminin tek bir veri setini güncellemeniz gerekecek, ki bu asla iyi bir şey değil. Bu alanlar kendi masalarına taşınmalıdır.

SalesIDİlkSonAdresTelefon numarasıOfficeID
1SamElliot118 Main St, Austin, Teksas(215) 555-58581
2Alicedemirci504 2nd Street, New York, NY(211) 122-18212
3Joekilise428 Aker St, Austin, TX(215) 545-55451

 

OfficeIDOfisOfis telefonu
1Austin şehir merkezi(212) 421-2412
2New York (Doğu)(211) 855-4541

 

Bu tasarım türü ayrıca satış masası tablosunda bir karmaşa kabusu yaratmadan Office tablosuna ek bilgi eklemenizi sağlar. Bu bilgilerin satış personeli tablosunda olması durumunda, cadde adresini, şehiri, eyaleti ve posta kodunu takip etmenin ne kadar işe yarayacağını düşünün!

Veritabanı Hatası # 3: İki Alana Daha Fazla Bilgi Verilmesi

Ofis bilgilerini satış sorumlusu tablosuna katmak o veritabanındaki tek sorun değildi. Adres alanında üç bilgi parçası vardı: sokak adresi, şehir ve eyalet. Veritabanındaki her alan sadece tek bir bilgi parçası içermelidir. Tek bir alanda birden fazla bilgi parçanız olduğunda, bilgi için veri tabanını sorgulamak zorlaşabilir.

Mesela, Austin’deki tüm satış insanlarına bir sorgulama yapmak istersek? Sadece verimsiz olan, ancak kötü bilgi verebilen adres alanında arama yapmamız gerekecek. Ne de olsa Portland, Oregon'da Austin caddesinde biri yaşıyorsa ne olur?

İşte tablo şöyle görünmeli:

SalesIDİlkSonAdres1Adres2KentBelirtmek, bildirmekZipTelefon
1SamElliot118 Ana St AustinTeksas787202155555858
2Alicedemirci504 2. St New YorkNY100222111221821
3Joekilise428 Aker StApt 304AustinTeksas787162155455545

 

Burada dikkat edilmesi gereken birkaç şey var.İlk olarak, "Adres1" ve "Adres2", tekrarlanan alanlar hatası altında görünecek gibi görünüyor.

Ancak, bu durumda, kendi tablosunda gitmesi gereken tekrar eden veri grubundan ziyade, doğrudan satış sorumlusuyla ilişkili ayrı veri parçalarına atıfta bulunmaktadırlar.

Ayrıca, kaçınılması gereken bir bonus hatası olarak, telefon numarasının biçimlendirmesinin tablodan nasıl çıkarıldığını öğrenin. Mümkün olduğunda, alan biçimini saklamaktan kaçınmalısınız. Telefon numaraları söz konusu olduğunda, insanların bir telefon numarası yazması için birçok yol vardır: 215-555-5858 veya (215) 555-5858. Bu, bir satış elemanını telefon numaralarıyla aramayı veya aynı bölge kodunda satış yapan kişileri aramayı daha zor hale getirecektir.

Veritabanı Hatası # 4: Doğru Birincil Anahtar Kullanılmıyor

Çoğu durumda, birincil anahtarınız için otomatik olarak artan bir sayı veya başka bir üretilen sayı veya alfanümerik kullanmak isteyeceksiniz. İyi bir tanımlayıcı yapacakmış gibi görünse bile, birincil anahtar için gerçek bilgiler kullanmaktan kaçınmalısınız.

Örneğin, her birinin kendi bireysel sosyal güvenlik numaramız vardır, bu nedenle bir çalışan veritabanı için sosyal güvenlik numarasını kullanmak iyi bir fikir gibi görünebilir. Ancak nadir olsa da, bir sosyal güvenlik numarasının bile değişmesi mümkündür ve asla birincil anahtarımızın değişmesini istemeyiz.

Ve gerçek bilgiyi anahtar değer olarak kullanmak problemdir. Değişebilir.

Veritabanı Hatası # 5: Adlandırma Kuralı Kullanılmıyor

Veritabanınızı tasarlamaya başladığınızda bu çok büyük bir şey gibi görünmeyebilir, ancak bilgi almak için veritabanına karşı sorgu yazma noktasına geldiğinizde, alan adlarını ezberlerken adlandırma kurallarına sahip olmanıza yardımcı olacaktır.

Sadece isimleri FirstName, LastName bir tabloda ve first_name, başka bir tabloda last_name olarak saklanırsa bu işlemin ne kadar zor olacağını düşünün.

En popüler iki adlandırma kuralı, alandaki her kelimenin ilk harfini büyük harflerle veya alt çizgi kullanarak sözcükleri ayırmaktır. Ayrıca, ilk sözcük dışında her kelimenin ilk harfini büyük harfle yazan bazı geliştiricileri de görebilirsiniz: firstName, lastName.

Tekil tablo isimlerini veya çoğul tablo isimlerini kullanmaya da karar vermek istersiniz. Sipariş tablosu veya Siparişler tablosu mu? Müşteri tablosu veya Müşteriler tablosu mu? Yine, bir Sipariş tablosuna ve Müşteriler tablosuna takılmak istemezsiniz.

Seçtiğiniz adlandırma kuralı, bir adlandırma kuralı seçmek ve bunlara bağlı kalmak kadar önemlidir.

Veritabanı Hatası # 6: Yanlış Dizin Oluşturma

Dizin oluşturma, özellikle veritabanı tasarımında yeni olanlar için doğru olan en zor şeylerden biridir. Tüm birincil anahtarlar ve yabancı anahtarlar endekslenmelidir. Bunlar birlikte tabloları birbirine bağlar, dolayısıyla bir endeks olmadan, veritabanınızdan çok düşük performans görürsünüz.

Ama çok sık kaçırılan diğer alanlar. Bunlar "WHERE" alanlarıdır. Aramanızı WHERE yan tümcesinde bir alanı kullanarak daraltacaksanız, o alana bir dizin koymayı düşünmek istersiniz. Ancak, tabloyu aşırı derecede endekslemek istemezsiniz, bu da performansa zarar verebilir.

Nasıl karar verilir? Bu veritabanı tasarımı sanatının bir parçasıdır. Bir tabloya kaç tane dizin koymanız gerektiği konusunda kesin sınırlar yoktur. Öncelikle, bir WHERE yan tümcesinde sık kullanılan herhangi bir alanı dizine eklemek istiyorsunuz. Veritabanınızı doğru bir şekilde dizine ekleme hakkında daha fazla bilgi edinin.