Veritabanı Geliştirme Süreci

Yazılım mühendisliğinin temel özelliklerinden biri, geliştirme sürecinin, her biri geliştirmenin bir yönüne odaklanan bir dizi aşamaya veya adıma bölünmesidir. Bu adımların toplamı bazen yazılım geliştirme yaşam döngüsü (SDLC) olarak adlandırılır. Yazılım ürünü, nihayet kullanımdan kaldırılana kadar bu yaşam döngüsü boyunca (bazen rafine edildikçe veya yeniden geliştirildikçe tekrar tekrar) ilerler. İdeal olarak, yaşam döngüsündeki her aşama bir sonraki aşamaya geçmeden önce doğruluk açısından kontrol edilebilir.

Yazılım Geliştirme Yaşam Döngüsü - Waterfall

Çoğu yazılım mühendisliği ders kitabında bulabileceğiniz gibi Waterfall modeline genel bir bakışla başlayalım. Aşağıdaki şekilde görülen bu şelale şekli, herhangi bir bilgisayar sistemi geliştirmeye uygulanabilecek genel bir waterfall modelini göstermektedir. Süreci, bir adımın çıktısının bir sonrakinin girdisi olduğu ve bir sonraki adıma geçmeden önce bir adımın tamamlanması gereken katı bir adımlar dizisi olarak gösterir.

Şekil; Şelale modeli

Şelale sürecini, her bir faaliyet için girdi ve çıktılarla birlikte gerekli olan görevleri tanımlamak için bir araç olarak kullanabiliriz. Önemli olan faaliyetlerin kapsamıdır, aşağıda özetlenebilir:

Gereksinimlerin oluşturulması, bir sistemden ne istedikleri konusunda paydaşlara danışılmasını ve paydaşlar arasında anlaşmaya varılmasını içerir ve bir gereksinim beyanı olarak ifade edilir.
Analiz, gereksinimlerin ifade edilmesiyle başlar ve bir sistem spesifikasyonu üretilerek tamamlanır. Spesifikasyon, bir sistemin ne yapması gerektiğinin, nasıl gerçekleştirilebileceğinden bağımsız terimlerle ifade edilen resmi bir temsilidir.
Tasarım, bir sistem spesifikasyonu ile başlar, tasarım belgeleri üretir ve bir sistemin nasıl inşa edilmesi gerektiğine dair ayrıntılı bir açıklama sağlar.
Uygulama, belirli bir tasarım belgesine göre ve sistemin çalışacağı ortamı (örneğin, geliştirme için mevcut özel donanım veya yazılım) dikkate alarak bir bilgisayar sisteminin oluşturulmasıdır. Uygulama, genellikle nihai bir sistem kullanıma sunulmadan önce doğrulanabilen ve test edilebilen bir başlangıç sistemi ile aşamalı olabilir.
Test, uygulanan sistemi tasarım belgeleri ve gereksinim spesifikasyonlarıyla karşılaştırır ve bir kabul raporu ya da genellikle düzeltilmesi için analiz, tasarım ve uygulama süreçlerinin gözden geçirilmesini gerektiren hataların ve kusurların bir listesini oluşturur (test genellikle şelale modelinin yaşam döngüsü boyunca yinelenmesine yol açan görevdir).
Bakım, gereksinimlerdeki veya uygulama ortamındaki değişikliklerle ilgilenmeyi, hata düzeltmeyi veya sistemin yeni ortamlara taşınmasını içerir (örneğin, bir sistemi bağımsız bir PC'den UNIX iş istasyonuna veya ağa bağlı bir ortama geçirmek). Bakım, gerekli değişikliklerin analizini, bir çözümün tasarlanmasını, uygulanmasını ve bakımı yapılan bir yazılım sisteminin ömrü boyunca bu çözümün test edilmesini içerdiğinden, şelale yaşam döngüsü tekrar tekrar gözden geçirilecektir.

Veritabanı Yaşam Döngüsü

Şelale döngüsünü, üç varsayımı içeren bir veritabanı geliştirme modeli için temel olarak kullanabiliriz:

Bir veritabanının geliştirilmesini -yani, bir veritabanındaki verileri tanımlamak için bir şemanın belirlenmesi ve oluşturulması- veritabanını kullanan kullanıcı süreçlerinden ayırabiliriz.
Bir şema ile ilişkili faaliyetleri ayırt etmek için üç şema mimarisini temel olarak kullanabiliriz.
Verilerin semantiğini zorlamak için kısıtlamaları, verileri kullanan her kullanıcı işlemi yerine bir veritabanı içinde bir kez temsil edebiliriz.

Şekil; Veritabanı geliştirme faaliyetlerinin ve çıktılarının şelale modeli.

Bu varsayımları ve yukarıdaki şekli kullanarak, bu diyagramın veritabanı geliştirme faaliyetlerinin ve çıktılarının bir modelini temsil ettiğini görebiliriz. Sadece ilişkisel bir yaklaşıma değil, herhangi bir VTYS sınıfına uygulanabilir.

Veritabanı uygulama geliştirme, gerçek dünya gereksinimlerini elde etme, gereksinimleri analiz etme, sistemin verilerini ve işlevlerini tasarlama ve ardından sistemdeki işlemleri uygulama sürecidir.

Gereksinimlerin Toplanması

İlk adım gereksinimlerin toplanmasıdır. Bu adım sırasında, veritabanı tasarımcıları önerilen sistemi anlamak, veri ve işlevsel gereksinimleri elde etmek ve belgelemek için müşterilerle (veritabanı kullanıcıları) görüşmelidir. Bu adımın sonucu, kullanıcılar tarafından sağlanan ayrıntılı gereksinimleri içeren bir belgedir.

Gereksinimlerin belirlenmesi, veri unsurlarının anlamı ve yorumlanmasına ilişkin bir anlaşmanın yanı sıra hangi kalıcı verilerin depolanmasını istedikleri konusunda tüm kullanıcılara danışılmasını ve aralarında anlaşmaya varılmasını içerir. Veri yöneticisi, veri gereksinimlerini etkileyen kurum içindeki iş, yasal ve etik konuları gözden geçirdiği için bu süreçte kilit bir rol oynar.

Veri gereksinimleri belgesi, kullanıcılarla gereksinimlerin anlaşıldığını teyit etmek için kullanılır. Kolayca anlaşıldığından emin olmak için aşırı resmi veya yüksek kodlu olmamalıdır. Niyet tek bir ortak veri tabanı geliştirmek olduğundan, belge tüm kullanıcıların gereksinimlerinin kısa bir özetini vermelidir - sadece bireylerin gereksinimlerinin bir koleksiyonu değil.

Gereksinimler verilerin nasıl işleneceğini değil, veri öğelerinin neler olduğunu, hangi niteliklere sahip olduklarını, hangi kısıtlamaların geçerli olduğunu ve veri öğeleri arasındaki ilişkileri tanımlamalıdır.

Analiz

Veri analizi, veri gereksinimlerinin belirtilmesiyle başlar ve ardından kavramsal bir veri modeli üretir. Analizin amacı, verilerin hem yüksek hem de düşük seviyeli özelliklerinin ve kullanımlarının ele alınması için kullanıcı gereksinimlerine uygun olacak şekilde verilerin ayrıntılı bir tanımını elde etmektir. Bunlar, öznitelikler için izin verilebilecek olası değer aralığı gibi özellikleri içerir (örneğin, okul veritabanı örneğinde, öğrenci ders kodu, ders başlığı ve kredi puanları).

Kavramsal veri modeli, veritabanı geliştirme sırasında istemciler ve geliştiriciler arasında iletilen şeyin paylaşılan, resmi bir temsilini sağlar - bu verilerin kullanıcı süreçlerinde nihai kullanımına veya verilerin belirli bilgisayar ortamlarında uygulanmasına bakılmaksızın, bir veritabanındaki verilere odaklanır. Bu nedenle, kavramsal bir veri modeli verilerin anlamı ve yapısı ile ilgilenir, ancak nasıl uygulandıklarını etkileyen ayrıntılarla ilgilenmez.

O halde kavramsal veri modeli, bir veritabanının hangi verileri içermesi gerektiğinin ve verilerin karşılaması gereken kısıtlamaların resmi bir temsilidir. Bu, modelin nasıl uygulanabileceğinden bağımsız terimlerle ifade edilmelidir. Sonuç olarak analiz, "Nasıl elde edilir?" sorusuna değil, "Ne gereklidir?" sorusuna odaklanır.

Mantıksal Tasarım

Veritabanı tasarımı, kavramsal bir veri modeli ile başlar ve mantıksal bir şema spesifikasyonu üretir; bu, gerekli olan belirli veritabanı sistemi türünü (ağ, ilişkisel, nesne yönelimli) belirleyecektir. İlişkisel temsil hala belirli bir VTYS'den bağımsızdır; başka bir kavramsal veri modelidir.

Mantıksal tasarım sürecine girdi olarak kavramsal veri modelinin ilişkisel bir temsilini kullanabiliriz. Bu aşamanın çıktısı, kavramsal veri modelindeki verilerin tanımını karşılamak için gereken tüm tabloların ve kısıtlamaların ayrıntılı bir ilişkisel spesifikasyonu, mantıksal şemasıdır. Bu tasarım faaliyeti sırasında, bir veritabanındaki verileri temsil etmek için hangi tabloların en uygun olduğu konusunda seçimler yapılır. Bu seçimler, örneğin değişim esnekliği, tekrarların kontrolü ve kısıtlamaların en iyi nasıl temsil edileceği gibi çeşitli tasarım kriterlerini dikkate almalıdır. Hangi verilerin saklanacağını ve veritabanında nasıl manipüle edilebileceğini belirleyen, mantıksal şema tarafından tanımlanan tablolardır.

İlişkisel veritabanlarına ve SQL'e aşina olan veritabanı tasarımcıları, kavramsal bir veri modeli oluşturduktan sonra doğrudan uygulamaya geçme eğiliminde olabilirler. Ancak, ilişkisel gösterimin SQL tablolarına bu şekilde doğrudan dönüştürülmesi, tamlık, bütünlük, esneklik, verimlilik ve kullanılabilirlik gibi arzu edilen tüm özelliklere sahip bir veritabanı ile sonuçlanmayabilir. İyi bir kavramsal veri modeli, bu özelliklere sahip bir veritabanına yönelik önemli bir ilk adımdır, ancak bu, SQL tablolarına doğrudan dönüşümün otomatik olarak iyi bir veritabanı ürettiği anlamına gelmez. Bu ilk adım, kavramsal veri modeli tanımını karşılamak için gereken tabloları ve kısıtlamaları doğru bir şekilde temsil edecek ve böylece tamlık ve bütünlük gereksinimlerini karşılayacaktır, ancak esnek olmayabilir veya zayıf kullanılabilirlik sunabilir. İlk tasarım daha sonra veritabanı tasarımının kalitesini artırmak için esnetilir. Esnetme, bir şeyi farklı bir amaç için bükme ve bükülürken bazı yönlerini zayıflatma fikirlerini aynı anda yakalamayı amaçlayan bir terimdir.

Aşağıdaki şekil, verilen genel bakışa dayalı olarak veritabanı tasarımında yer alan iteratif (tekrarlanan) adımları özetlemektedir. Temel amacı, hangi tabloların kullanılması gerektiği genel konusunu, her bir tablonun kurucu parçalarının ayrıntılı tanımından ayırmaktır - bu tablolar, birbirlerinden bağımsız olmamakla birlikte, teker teker ele alınmaktadır. Tabloların revizyonunu içeren her yineleme yeni bir tasarıma yol açacaktır; süreç tek bir döngüden daha fazla yinelense bile, toplu olarak genellikle ikinci kesim tasarımlar olarak adlandırılırlar.

Şekil; Veritabanı tasarımında yer alan yinelemeli adımların bir özeti.

İlk olarak, belirli bir kavramsal veri modeli için, temsil ettiği tüm kullanıcı gereksinimlerinin tek bir veritabanı tarafından karşılanması gerekli değildir. Birden fazla veri tabanının geliştirilmesi için farklı yerlerde bağımsız çalışma ihtiyacı veya "kendi" verileri üzerinde departman kontrolü gibi çeşitli nedenler olabilir. Ancak, veritabanları koleksiyonu yinelenen veriler içeriyorsa ve kullanıcıların birden fazla veritabanındaki verilere erişmesi gerekiyorsa, bir veritabanının birden fazla gereksinimi karşılayabilmesi için olası nedenler vardır veya veri çoğaltma ve dağıtımı ile ilgili konuların incelenmesi gerekir.

İkinci olarak, veritabanı geliştirme ile ilgili varsayımlardan biri; bir veritabanının geliştirilmesini, onu kullanan kullanıcı süreçlerinin geliştirilmesinden ayırabileceğimizdir. Bu, bir veritabanı uygulandıktan sonra, şu anda tanımlanmış kullanıcı süreçlerinin ihtiyaç duyduğu tüm verilerin tanımlandığı ve bunlara erişilebileceği beklentisine dayanmaktadır; ancak gelecekteki gereksinim değişikliklerini karşılamamıza izin verecek esnekliğe de ihtiyacımız var. Bazı uygulamalar için bir veritabanı geliştirirken, veritabanına sunulacak ortak istekleri tahmin etmek mümkün olabilir ve böylece tasarımımızı en yaygın istekler için optimize edebiliriz.

Üçüncü olarak, ayrıntılı bir düzeyde, veritabanı tasarımı ve uygulamasının birçok yönü kullanılan belirli VTYS'ye bağlıdır. VTYS seçimi sabitse veya tasarım görevinden önce yapılmışsa, bu seçim uygulamaya kadar beklemek yerine tasarım kriterlerini belirlemek için kullanılabilir. Yani, genel bir tasarım üretmek yerine belirli bir VTYS için tasarım kararlarını dahil etmek ve daha sonra bunu uygulama sırasında VTYS'ye uyarlamak mümkündür.

Tek bir tasarımın iyi bir veritabanının tüm özelliklerini aynı anda karşılayamadığını görmek nadir değildir. Bu nedenle, tasarımcının bu özellikleri önceliklendirmesi (genellikle gereksinim spesifikasyonundaki bilgileri kullanarak) önemlidir; örneğin, belirli bir geliştirmede bütünlüğün verimlilikten daha önemli olup olmadığına ve kullanılabilirliğin esneklikten daha önemli olup olmadığına karar vermek için.

Tasarım aşamamızın sonunda, mantıksal şema, kullanıcı gereksinimlerini karşılamak için uygulanması gereken veritabanını tanımlayan SQL veri tanımlama dili (DDL) ifadeleri ile belirtilecektir.

Uygulama

Uygulama (Implementation), mantıksal bir şemanın özelliklerine göre bir veritabanının oluşturulmasını içerir. Bu, uygun bir depolama şemasının, güvenlik uygulamasının, harici şemanın ve benzerlerinin belirlenmesini içerecektir. Uygulama, mevcut VTYS'lerin, veritabanı araçlarının ve işletim ortamının seçiminden büyük ölçüde etkilenir. Sadece bir veritabanı şeması oluşturmanın ve kısıtlamaları uygulamanın ötesinde ek görevler vardır; verilerin tablolara girilmesi, kullanıcılarla ve kullanıcı süreçleriyle ilgili sorunların ele alınması ve kurumsal veri yönetiminin daha geniş yönleriyle ilişkili yönetim faaliyetlerinin desteklenmesi gerekir. VTYS yaklaşımına uygun olarak, bu endişelerin mümkün olduğunca çoğunun VTYS içinde ele alınmasını istiyoruz. Şimdi bu endişelerden bazılarına kısaca göz atacağız.

Uygulamada, mantıksal şemanın belirli bir VTYS'de uygulanması, VTYS'nin sunduğu belirli özellikler ve olanaklar hakkında çok ayrıntılı bilgi sahibi olmayı gerektirir. İdeal bir dünyada ve iyi yazılım mühendisliği uygulamalarına uygun olarak, uygulamanın ilk aşaması tasarım gereksinimlerinin mevcut en iyi uygulama araçlarıyla eşleştirilmesini ve ardından uygulama için bu araçların kullanılmasını içerir. Veritabanı açısından bu, uygulamamız gereken veritabanına en uygun VTYS ve SQL varyantlarına sahip satıcı ürünlerini seçmeyi içerebilir. Ancak ideal bir dünyada yaşamıyoruz ve çoğu zaman donanım seçimi ve VTYS ile ilgili kararlar, veritabanı tasarımının değerlendirilmesinden çok daha önce verilmiş olacaktır. Sonuç olarak, uygulama, herhangi bir yazılım veya donanım sınırlamasının üstesinden gelmek için tasarımın ek olarak esnetilmesini içerebilir.

Tasarımın Gerçekleştirilmesi

Mantıksal tasarım oluşturulduktan sonra ürettiğimiz tanımlara göre veritabanımızın oluşturulmasına ihtiyacımız var. İlişkisel bir VTYS'ye sahip bir uygulama için, bu muhtemelen mantıksal şema tanımını ve uygun depolama şeması seçimini (VTYS bu düzeyde kontrole izin veriyorsa) karşılayan tablolar ve kısıtlamalar oluşturmak için SQL kullanımını içerecektir.

Bunu başarmanın bir yolu, uygun SQL DDL ifadelerini bir VTYS tarafından yürütülebilecek bir dosyaya yazmaktır, böylece veritabanını tanımlayan SQL ifadelerinin bağımsız bir kaydı, bir metin dosyası olur. Diğer bir yöntem de SQL Server Management Studio veya Microsoft Access gibi bir veritabanı aracı kullanarak etkileşimli olarak çalışmaktır. Mantıksal şemayı uygulamak için hangi mekanizma kullanılırsa kullanılsın, sonuçta tabloları ve kısıtlamaları olan bir veritabanı tanımlanır ancak kullanıcı işlemleri için hiçbir veri içermez.

Veritabanının Doldurulması

Bir veritabanı oluşturulduktan sonra, tabloları doldurmanın iki yolu vardır; ya mevcut verilerden ya da veritabanı için geliştirilen kullanıcı uygulamalarının kullanımı yoluyla.

Bazı tablolar için başka bir veritabanından veya veri dosyalarından mevcut veriler olabilir. Örneğin, bir hastane için veri tabanı oluştururken, veri tabanına dahil edilmesi gereken tüm personele ait bazı kayıtların zaten mevcut olmasını beklersiniz. Veriler dışarıdan bir kurumdan da getirilebilir (adres listeleri sıklıkla dış şirketlerden getirilir) veya büyük bir veri giriş görevi sırasında üretilebilir (basılı kopya manuel kayıtların bilgisayar dosyalarına dönüştürülmesi bir veri giriş ajansı tarafından yapılabilir). Bu gibi durumlarda, veritabanını doldurmak için en basit yaklaşım, VTYS'de bulunan içe ve dışa aktarma olanaklarını kullanmaktır.

Çeşitli standart formatlarda veri içe ve dışa aktarma olanakları genellikle mevcuttur (bu işlevler bazı sistemlerde veri yükleme ve boşaltma olarak da bilinir). İçe aktarma, bir veri dosyasının doğrudan bir tabloya kopyalanmasını sağlar. Veriler içe aktarma işlevini kullanmaya uygun olmayan bir dosya biçiminde tutulduğunda, eski verileri okuyan, bunları gerektiği gibi dönüştüren ve ardından bu amaç için özel olarak üretilen SQL kodunu kullanarak veritabanına ekleyen bir uygulama programı hazırlamak gerekir. Büyük miktarlarda mevcut verinin bir veritabanına aktarılması toplu yükleme olarak adlandırılır. Verilerin toplu yüklenmesi, her seferinde bir tablo olmak üzere çok büyük miktarlarda verinin yüklenmesini içerebilir, bu nedenle kısıtlama kontrolünü toplu yüklemenin sonuna kadar ertelemek için VTYS olanaklarının olduğunu görebilirsiniz.

ER (Varlık İlişkisel) Diyagramı Geliştirmek için Yönergeler

Not: Bunlar, gerçek veritabanı tasarımı (mantıksal model) için güçlü bir temel geliştirmeye yardımcı olacak genel kılavuzlardır.

Bilgi toplama aşamasında keşfedilen tüm varlıkları belgeleyin.
Her bir varlığa ait tüm öznitelikleri belgeleyin. Aday ve birincil anahtarları seçin. Her bir varlık için anahtar olmayan tüm özniteliklerin tam işlevsel olarak birincil anahtara bağlı olduğundan emin olun.
İlk ER diyagramını geliştirin ve uygun personel ile gözden geçirin. (Bunun yinelemeli bir süreç olduğunu unutmayın).
Çok değerli nitelikler ve tekrar eden gruplar için yeni varlıklar (tablolar) oluşturun. Bu yeni varlıkları (tabloları) ER diyagramına dahil edin. Uygun personel ile gözden geçirin.
Tabloları normalleştirerek ER modellemesini doğrulayın.

Alıştırmalar

1. Şelale modelini tanımlayın. Adımları listeleyin.

2. SDLC kısaltması ne anlama gelir ve bir SDLC neyi tasvir eder?

3. Veritabanı tasarımına uyum sağlamak için şelale modelinde nelerin değiştirilmesi gerekir?

4. Veritabanı tasarımında yer alan yinelemeli adımları sağlayın.

Atıf

Veritabanı Tasarımı'nın bu bölümü (aksi belirtilmedikçe tüm görseller dahil) Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Lisansı altında lisanslanan Open University tarafından hazırlanan The Database Development Life Cycle'ın türev bir kopyasıdır.

Önceki Ders: Veritabanı Tasarımı Normalleştirme

Sonraki Ders: Veritabanı Kullanıcıları

Bu Blogda Ara

Üniversite Dersleri