Veritabanı Yaratılması Hakkında Özet Bilgiler

Bir veritabanın yaratılmasına geçmeden önce uyulmasında ve gözönünde bulundurulmasında yararlı olacak bazı noktaları belirtelim. Bu kuralları özet olarak açıklarsak ;
Ø Veritabanının oluşturmadan önce yapılması gerekenler,
Ø Tabloların, alanların yaratılması ve kullanılmasında dikkat edilecekler,
Ø Tablolara erişim yöntemlerinin belirlenmesinde ki hususlar,
Ø Veritabanın entegre bir şekilde çalışması,
Ø Unutulmaması gerekenler,



Veritabanının oluşturmadan önce yapılması gerekenler,

1. Kurulacak veritabanın hangi amaca hizmet edeceği önceden kesinlikle bilinmelidir. Bilgisayarlar kullanılarak elle yapılan işleri daha hızlı ve daha doğru bir biçimde yapılması amaç olduğuna göre mevcut düzenin çok iyi analiz edilmesi gereklidir. Yapılan işleri yerinde görerek, yapan kişilerle konuşarak gerekli tüm dökümanları toplayarak, işlerin sırasını, önemini, önceliğini belirleyerek sahada çalışma yapılmalıdır.
2. Veritabanını oluşturacak olan nesneleri, detaya girmeden kullanım yeri, amaçlarına göre standart isimlendirilmelidir. Nesnelerin önüne veya sonuna belirleyici tanımlamalar koymak sonrasında inceleme ve geliştirmede yarar sağlayacaktır. Stok’la ilgili nesnelerin STK_, Personel ile ilgili olanların PER_ ile başlaması gibi veya parametre dosyalarına _PAR ekinin konulması. Bunun nesneler içinde kullanılacak olan alan isimlerinde de yapılması tavsiye edilir. Formların FRM, Query’lerin QRY, Reportların RPT ile başlaması bir bütünü anlamakta kolaylık sağlayacaktır.
3. Yaratılacak olan veritabanın ömrünün ne kadar olacağı belirlenmeli ve 2000 yılı örneğinde olduğu gibi sorun yaratacak kısıtlamalardan kaçınılmalıdır. Bugünün sorunlarına çözüm getirilmesine yönelik olarak hazırlanan çözümün gelecek zamanların ihtiyaçlarına da cevap verebilecek durumda olması kesinlikle gözden kaçırılmamalıdır.
4. Veritabanını oluşturan tabloların ve/veya alanların birbiriyle olan ilişkilerini gösterecek, gerektiğinde kontrol edilmesini sağlayacak data modelleme araçlarından yararlanılmalıdır.
5. Veritabanı kurulması sırasında ki tüm aşamalarda toplanan tüm bilgi kesinlikle kağıt üzerinde tutulmalıdır. Projenin her bölümünde oluşan sonuçlar, aksaklıklar yazılı hale getirilmelidir.

6. Oluşturulan veritabanının fiziksel uygulamaya geçilmeden önce mantık olarak kağıt üzerinde (hayal gücünüzü de kullanarak) test edilmeli, çalıştırılmalıdır.

7. Veritabanını oluşturan tabloların ve alanların belirlenmesinde girilecek olan bilgiler kadar istenen bilgilerin de ne olacağının önceden bilinmesi önemlidir. Bu amaçla hangi ekranların, hangi raporların kullanılması gerektiği iyice araştırılmalıdır. Özellikle kullanıcıların elle tutmuş oldukları dosyaları hazırlamış oldukları raporlar toplanmalı ve veritabanında ki tablo ve alanların bunları verebilecek şekilde düzenlenmiş olduğundan emin olunmalıdır.

8. Veritabanında tutulacak olan bilgilere erişim zamanlarının veya sıklıklarının ne olacağı önceden bilinmelidir. Hangi bilgiye sürekli erişilecek, haftalık veya aylık raporlarda ne olacak ? bu tür soruların önceden cevaplandırılmış olması hem veritabanının hem de programların kullanıcı ihtiyaçlarına cevap verecek şekilde hazırlanmasında yarar sağlayacaktır.
9. Tüm bu işlemler sırasında, belli dönemlerde ve uygulamaya geçilmeden önce kullanıcılarla bilgi alışverişinde bulunulmalı ve sonuçlar paylaşılmalıdır. Unutulmamalıdır ki kullanıcıların projeye dahil edilmediği, alınmadığı, sonuçların paylaşılmadığı durumlarda bir karşı konulmayla karşılaşılacaktır.Bunun da sonucu yapılan her türlü uygulamalar başarısız olarak nitelendirilecektir.

Tabloların, alanların yaratılması ve kullanılmasında dikkat edilecekler,

1. Her zaman yaratılmakta olan tabloların, alanların değişebileceği unutulmamalıdır. Bundan dolayı tasarım sırasında ki tüm değişikliklerin nedenleri, ne içinleri yazılı bir biçimde kayıt altında tutulmalıdır.

2. Tablo isimleri ve tablo içindeki alan isimleri açıklayıcı ve belirleyici olmalıdır. Birden fazla tabloda yer alacak olan alanlar varsa bunlar bütün tablolarda aynı isimlerle kullanılmalıdır. Örneğin stok_no alanı bütün stok tablolarında ep aynı isimle yer almalıdır. Alan isimlerinin öncesi veya sonrasında takılar takılması alan isimlerinin anlaşılmasında kolaylık sağlayacaktır. Per_AdiSoyadi, Mus_AdiSoyadi gibi. Bu arada özellikle Türkçe karakterlerin kullanılmamasına dikkat edilmelidir. Ayrıca bazı özel işaretlerin (%,&, ‘ gibi) veya kısıtlanmış kelimelerin (NOT, END, IN, LIST, vb.) de alan isimlerinde kullanılmamalıdır.

3. Bütün tabloların son dört alanı ; kaydı yaratan kullanıcı, kayıt yaratma tarihi/saati, kayıt güncelleyen kullanıcı ve kayıt güncelleme tarihi/saati bilgilerini içermelidir. Böylece kayıtlara kimlerin ne zaman eriştiği bilgisine sahip olunacaktır.

4. Tablolarda tekrarlayan alanlardan kaçınılmalı ama abartıya kaçınılmamalıdır. Kayıtların ve alanların veritabanı genelinde bir yerde tutulması tavsiye edilmekle beraber bazı durumlarda bazı alanların tekrar etmesi de gerekecektir. Buna işin durumuna ve özelliğine göre karar verilecektir. Veritabanın iyileştirilmesine yönelik çalışmalarda aşırıya kaçınılmaması tavsiye edilir.

5. Tablolar üzerinde kayıt ekleme, kayıt silme, kayıt değiştirme ve sorgulama yapacak olan kullanıcıların belirlenerek bunlara erişim yetkilerinin verilmesi unutulmamalıdır.

6. Veritabanın kullanılacağı yerlerin, ortamların durumuna bağlı olarak bazı değişiklikleri yapmak kaçınılmazdır. B.r WEB uygulamasında yerel kullanıcılar olabileceği gibi yabancı kullanıcılarında olacağı unutulmamalıdır. Onların girebilecekleri alanlar eklenmelidir.

7. Alanların bazılarına mutlaka değer girişinin yapılacağı durumlarda alanları tanımlarken NOT NULL, ilk değerin verilmesi gerek durumlarda DEFAULT deyimleri kullanılmalıdır.

8. Tablolarda ki Adres alanlarının iki veya üç alanda tutulması tavsiye edilir. Böylece ekran veya yazıcı üzerinde adreslerin gösterilmesinde sorunlar (uygun olmayan yerden kesmek gibi) yaşanmaz. Aynı şekilde telefon veya fax numaralarının başındaki kodlamalarında ayrı alanda tutulması ileride olabilecek sorunlara karşı bir önlem niteliğindedir.

9. Alanların veri tiplerinin belirlenmesinde (Sayısal, alfasayısal, tarih vb.) dikkat edilmeli ve doğru seçimlerde bulunulmalıdır. İçeriklere bağlı olarak sayı tiplerinde genişlikten (LONG INTEGER, INTEGER veya DECIMAL) dolayı sorunlar yaşanmamalıdır.

10. Bazı durumlarda kullanılmak üzere tablolarda SILINMIS ve/veya GECERSIZ işaretlerin konulacağı alanlar olmalıdır. Örnek olarak bazı muhasebe hesaplarının geçici olarak kapatılması veya bazı stokların geçersiz hale getirilmesi durumlarında bu alanlar kullanılmalıdır.

11. Alan isimlendirilmesinde aşırıya kaçınılmamalıdır. Unutulmamalı ki bu alan isimleri programlama sırasında programcılar tarafından kullanılacaktır.

Tablolara erişim yöntemlerinin belirlenmesinde ki hususlar,

1. Tablolara hızlı erişim için kullanılan INDEX dosyalarının ne fazla ne eksik olması gerekir. Bunun için hangi tabloya nasıl erişileceği belirlenmeli, erişim sırasında ne kadar bilginin kullanılacağı önceden belirlenmelidir.

2. Bir tabloya ait ne kadar fazla index dosyası varsa, kayıt ekleme, değiştirme ve silme işlemlerinde ki performansta o kadar düşük olur.

3. Kayıt sayısı az olan tablolara index kurmaya gerek yoktur.

4. Tablolara bağlantılarda FOREIGN KEY kullanılması bilginin doğruluğu ve düzgünlüğü için mutlak şarttır. Bütün index dosyalarda tekrar etmeyen (unique) alanlar kullanılmalıdır.

5. Kullanıcıların veya programcıların tablolara erişimlerini kolaylaştıracak alanlardan indexlerin oluşturulmasına dikkat ediniz. Örneğin 20 karakterlik bir numara üzerinden index oluşturulursa kullanıcının bu 20 karakteri doğru bir şekilde girmesi halinde index kullanılacağı unutulmamalıdır.
Veritabanın entegre bir şekilde çalışması,
1. İş kurallarına ve işin gelişimine kolaylıkla uyum sağlayabilecek tablolar ve alanların kullanılmasına önem verilmelidir.İşin bir bölümünün değişmesi, yenilenmesi durumda bütün tablolarda veya ilgili alanların çoğunda değişikliğe gidilmemesi gerekir.

2. Veritabanı üzerinde kaç yıllık bilgilerin tutulacağı önceden belirlenmelidir. Orta vadeli (beş yıllık) veya uzun vadeli (10 yıllık) sürelerde bilgilerin başka yerlere taşınıp orada tutulması ve gerektiğinde erişilmesi yöntemleri başlangıçta uygulanmalıdır.

3. Tablolara girilen kayıtların amaçlara doğru olarak hizmet edecek şekilde olmasına dikkat edilmeli ve gereksiz, kullanılmayan kayıtlar tablolardan temizlenmelidir. Bu işlemler veritabanı bazında belli periyotlarda uygulanmalıdır.

4. Veritabanı üzerinde çalışacak fonksiyonlar ve/veya procedurler belirlenerek bunların tek bir yerde toplanmasına uyulmalıdır.

5. Veritabanın yedeklerinin alınması ve gerektiğinde geri dönüşler için izlenecek yollar önceden belirli olmalıdır.
Unutulmaması gerekenler,

Projenin her aşaması, kağıt üzerinde, yazılı bir biçimde tutulmalıdır. Değişiklikler, ilaveler tarih bazında, version numaralandırılmasına gidilerek takip edilmelidir. Bunların nedenleri, nasılları ve kimler tarafından istendiği ve kimler tarafından yapıldığı kayıt altına alınmalıdır.

Her uygulama, her seferinde , gerektiğinde değişik kişiler tarafından test edilmelidir.

Veritabanına bir bütün olarak bakılmalı ve gerektiğinde bölümlere ayrılarak analiz edilmelidir. Bu analizler sırasında yardımcı araçlardan, bilgilerden yararlanılmalıdır.

DEVAMI...

UML de Use Case Diyagramı

Bir önceki Makalemizde bir modelleme mantığına neden ihtiyaç duyulduğuna, bize ne kazandıracağına, ne kaybettireceğine değinmiştik. UML i güçlü olarak nasıl kullanabileceğinizi göstermeye çalışmıştım.

Bu makalede UML ile analiz yapma mantığının beklide en önemli diyagramı olan Use Case e değineceğim. Bildiğim kadarı ile Use Case diyagramları ilk kez 1960 lı yıllarda Ericsson firmasında kullanılmaya başlanmış. UML ile analiz yapmak demek analizin bir çıktısı olarak kullanabileceğiniz bir diyagram oluşturabilmek, analizdeki ihtiyaçlarınızı anlatabiliyor olmak ve en önemlisi de ortak olarak herkesin anlayabileceği yorumlayabileceği bir diyagram olarak gösterebiliyor olmaktır.

İyi bir Use Case diyagramı çizebilmek için iyi bir analiz yapmanız gerekmektedir. İyi bir analizi yaparken de, kolay anlaşılır, basit, sade ve iş adımlarını bir senaryo olarak düşünmek gerekir. Use Case diyagramları iş analizi yaparken kullanacağınız diyagram şeklidir. Dolayısı ile içerisinde teknik bilgiyi çok fazla içermez.

Use Case UML diyagramlarının içinde en çok kullanılan diyagramlardan bir tanesidir. Use Case diyagramını mutlaka görmüş ya da kullanmışsınızdır. Use Case diyagramı diğer UML diyagramlarından farklı bir diyagramdır. Kuralları çok daha azdır. Daha çok işi kuş bakışı anlatmakla ilgilidir ve kullanıcıdan kullanıcıya modellemesi değişebilir.

Use Case diyagramı sistemin iş yapma yöntemlerini belirttiğim gibi kuş bakışı tasarlamanızı sağlar. Bu kuş bakışı tasarımda, işi kimin yaptığı ve ne işler yaptığı ile ilgilidir. İşi yapan kişiler, işlemleri tetikleyen kişilerdir ve onların yaptığı işlemleri adım adım göstermektir olay. Buradaki soru işareti yaptıkları işleri hangi seviyede göstereceğiniz. Yine önceki makalede belirttiğim gibi bunun kesin bir tanımı yok, önemli olan sizin standardınızın nasıl olduğu, sizin UML i okumasını istediğiniz kişilerin nasıl anladığıdır. Use Case diyagramlarının mantığı basit olduğu için müşterilerinize kısa bir tanıtımla üzerinde konuşabiliyor, diyagramları inceliyor olabilirsiniz. Oluşturduğunuz analiz dokümanlarına da ekleyerek, hem müşteriye hem de teknik kişilere iş kurallarını bu kuralları kimlerin gerçekleştireceğini anlatabilirsiniz.

Use Case diyagramı basit olmalıdır, müşterilerde inceleyeceği için gereksiz teknik bilgiden kaçınılmalıdır. Örneğin sistemin mail attırmasını istiyorsanız, “Exchange Server mail atar” gibi bir deyim yerine “Mail gönderilir” gibi daha basit bir tanımlama tercih ederseniz anlaşılabilirlik çok daha artar.

“Kullanıcı SMS gönderir”

Bu kelime bir Use Casedir. Use Case, kelime anlamına bakıp, birebir çevirdiğiniz de kullanım durumu demektir. Peki kullanım durumunu ne demektir ?. Kullanım durumu bir sistemin, başka bir sistem ya da kullanıcı grubu tarafından, bir amaç için, bu amacın bir sonucu olacak şekilde yaptığı işlemleri ve akışları anlatan diyagram şeklidir. Bir kullanım durumu, aslında senaryolardan oluşmuş bir işlemin akışıdır. Biraz sonra Use Case diyagramının elemanlarının neler olduğunu ve ne amaçla kullanıldığını inceleyeceğiz ama önce senaryo nun ne olduğuna bakalım.

Senaryo kavramı aslında ikiye ayrılır. Birincisi kullanım senaryoları (Use Scenario) , ikincisi ise kullanıcı senaryolarıdır. (User Scenario) Bu iki tipte Use Case lerden türeyen tiplerdir. Kullanım senaryoları, belli, spesifik, özel bir aktör için yapılan iştir. Örneğin “Cenk SMS gönderir” yada “Cenk Turkcell ile SMS gönderir” gibi örneklenebilir, aslında yapılan iş temel olarak Use Case de yapılan iştir, sadece yapan kişi ve yapılan iş biraz daha özeleşmiştir ancak yapılan sonuçta “SMS göndermek” tir. Cenk’in telefon etmesi ile, satış takımının telefon etmesi farklı kullanım senaryolarıdır. Diğer senaryo tipi olan kullanıcı senaryoları da sistemi kullanacak bir kişinin gözünden bütün sistemi anlatır. Bunun için bütün sistemin Use Casenin belirlenmiş olması gerekmektedir aslında. Kullanıcı senaryoları, bir kitaptaki kahramanın kendi hayatını, kendi gördüklerini, yaşadıklarını anlatmasına benzer. O kahramanın yerinde herhangi biriside olabilirdi, ama o kahraman özel olarak yaşayıp bunları görmüştür. Yani “Cenk SMS gönderir”, “Cenk e cevap SMS i gelir”, “Cenk cevap SMS indeki kodu Web sitesine girer” gibi devam edilebilir.

Senaryoların kullanılması için belirttiğim gibi bütün Use Caselerin yani genel durumların belirli olması gerekmektedir, ondan sonra bu spesifik kullanıcıların üzerine gidilmesi sistemi çok daha başarılı modellemenizi, bir konuyu unutmamanızı sağlar. Özellikle Kullanıcı Senaryosunu kendi oluşturduğunuz Use Case ler üzerinden müşteriniz ile konuşarak deneyiniz. Eksik bir noktanın kalmaması çok önemlidir.

Yukarıdaki örnekleri verirken spesifik bir kullanıcı yada bir kullanıcı grubu kullanılır gibi kelimeler kullandım, bu kullanıcıların kimler olduklarını ve bizim Use Case diyagramlarımızda ne işe yaradıklarını tam olarak konuşmadık. Bu kullanıcılara Use Case diyagramların aktör denir. Diyagramlarda aktörler çok kolay ve basit olması açısından çöp adamlar ile gösterilirler. Aktör, bizim yazacağımız yazılımın dışındaki bir kişi ya da kişi grubu, dışarıdaki bir sistem yada teknik araçlar olabilirler, aktörler bizim sistemimize bir işlem yaparlar, bu işlemi de belirli bir amaç için yapmaları gerekmektedir. Olay gerçekleştiğinde bu amacı sağlamalıdırlar. Bir aktör bizim sistemimizle iletişime girdiğinde bir den çok amacı olabilir, ancak biz bunları tek tek gösteririz ki karmaşıklık olmasın.

Aktörleri ve Use Case leri tanıdık, aktörler ile Use Case leri birleştiren çizgiye de, ilişki (Associations) denir. Şimdi analiz yaparken Use Case leri nasıl belirleyeceğinize bakalım, çok temel olarak “Kullanıcı SMS gönderir” kelimesine bakalım, yukarıda da belirttiğimiz gibi aslında bu bir Use Case dir. “Kullanıcı” kelimesi aktör, “SMS” kelimesi kapsamı, “gönderir” kelimesi ise amacı anlatır. Böyle bir Use Case diyagramı aşağıdaki gibi gösterilebilir,

Gördüğünüz gibi olduça basit, bu Use Case i biraz daha büyütelim



Bu Use Case diyagramında gördüğünüz gibi bir aktör birden çok Amaçla (Use Case ile) iş yapabilirken, bir amacı (Use Case i) gerçekleştiren birden çok kullanıcıda olabilir.

Önceki makalelerde de belirttiğim gibi, Use Case ler diyagram olarak kullanır. Ancak Use Case leri yazarak da oluşturabilirsiniz. Bu da çok geçerli bir yöntemdir, eğer müşteriniz Use Case diyagramlarını okumayı red ediyorsa, bir sonraki makalede yazacağımız Aktivite diyagramlarını da kullanarak, Use Case lerinizi adım adım yazabilirsiniz. Diyagram çizmeyerek yazmanız bile analizlerinizi çok güçlü kılacaktır.

Use Case diyagramlarında aslında çok fazla özellik vardır. Ancak bu özellikler çok da fazla kullanılmaz aslında, kullanıldığında diyagramı güçlendirir, daha detaylı bilgi verir, ancak kompleksliğide arttırdığı için, çok bilinmez, dolayısı ile de okunamaz, bir müddet sonra yavaş yavaş kullanılmaz, bu konulara hızlıca değinmek istiyorum. kapsamlı bir UML dokümanı gördüğünüz zaman en azından okuyabilmenizde yardımcı olması adına,

İlki “System Boundary” diye geçen bazı kaynaklarda “Domain” olarak da anlatılan aslında kapsamınızı tuttuğunuz bir dikdörtgendir, bu dikdörtgenin içindeki Use Case ler bu kapsam içindedir anlaşılır.

İkincisi olarak İlişki (Associations) ın özelliklerini inceleyelim, adında anlaşılacağı gibi iki nesne arasında ilişki kurmak ile ilgilidir. Örneğin bir aktör ü başka bir aktörden türetebilirsiniz (Generalization ilişkisi, bildiğimiz OO daki inheritance gibi.) Bu daha çok senaryoları oluşturmak ile ilgilidir. Daha detay bilgi vermek bazında işinizi görebilir, üçgen şeklindeki ok ile gösterilir.

Bunların dışında temel olarak kullanılan iki tane daha ilişki tipi vardır. Extends (genişletir), Uses (kullanır, içerir) bu ikisi genelde çok birbirine karıştırılır. Aslında temeli mantığı çok basittir.

Extends de var olan bir Use Case i geliştirip yeni işlemler ekleyerek kullanırız, Uses de ise varolan bir Use Case i diğer bir adım içinde aynen kullanırız.

Bu iki tipte, aynı türetme mantığındaki gibi kullanılır, tek fark üzerindeki tipleridir. (UML de bu tiplere, Stereotype yani şablon denilir) Extends için “<>”, Uses için “<>” kullanılır.

Use Case dokümanları ile ilgili genel bilgileri inceledik, basit Use Case diyagramları çizdik, bu makale serisi tamamlandıktan sonra komple bir sistemi çizdiğimizde bu diyagramlar çok daha anlaşılır olacaktır. Unutmayın bilgisayar dünyasında hep olduğu gibi, ne kadar çok yaparsanız okadar iyi olursunuz, Use Case diyagramlarını bu bilgiler ışığında oluşturmaya çalışın. Başta olmuyormuş gibi gelecek ama bir müddet sonra okadarda zor olmadığını göreceksiniz.

Bir sonraki makalede Use Case ler ile birlikte İş analizi yapmak için kullanılan diyagramlardan olan aktivite diyagramlarına değineceğim, o zaman Use Case diyagramları da daha anlam kazanacaktır.

İstek eleştiri ve önerileriniz için aşağıdaki mail adresimi kullanabilirsiniz.

Levent Cenk ÇAĞLAR

levent@cenkcaglar.com

DEVAMI...