Veri düzenleri
Leonard Shapiro ÇEVİREN: JÜLİDE ERGÜDER
Moni bir database sistemi satın aldınız. Bir dBASE ya da buna benzer bir şey. Yeni oyuncağınızı çok mu çok seviyorsunuz. Raporlarını artık çabucak yazabiliyorsunuz, herhangi bir konuda özel malumat edinmek istediğinizde, hazır bilgiye kolayca erişebiliyorsunuz. Database'inizle daha çok ve çeşitli şeyler yapabilmeyi arzu ettiniz ve böylece sisteminize durmaksızın yeni bilgiler eklediniz. Başkaları da database sisteminizi kullanabilmek için kuyruk oldular. Bunun üzerine yeni bilgi yükleme yolları üzerinde kafa yormaya başladınız. Sisteme yeni dosyalar ve dosyalara da yeni bilgiler yığıldıkça yığıldı. Ve malzeme biriktikçe ipin ucunu kaçırmaya başladınız. Database kütüklerine ne yüklediğinizi tam ve kesin olarak hatırlayamıyorsunuz. Aynı bilgi farklı farklı dosyalardaymış gibi geliyor. Bir program ya da bir database kütüğünü değiştirdiğinizde, öbür programlar ve kütükler etkileniyor. Yeni bilgi yüklemek istediğinizde, bazı kütüklerin genişletilmesi mi yoksa yeni bir kütük açılması mı gerektiğine bir türlü karar veremiyorsunuz. Data'nızın yeni bir yapılanmaya şiddetle ihtiyacı var. Database'inize verileri düzenleme yönteminin ilkelerini tatbik etmelisiniz. Tıpkı, programlarınıza yapılanmış programlamanın ilkelerini uygulamanız gerektiği gibi.
Dosyalar da Yapılanabilir
Yapılanmış programlamayı kullanmazdan evvel, geniş programlar kaydeden hepimiz, lenduha gibi uzun ve idaresi müşkül programlardan şikayet eder dururduk. Yapılanmış programlamanın ilkeleri, WHILE, IF vb. birkaç minik yapıtaşı kullanarak küçük program modülleri oluşturma yolunu gösterdi ve programınızın daha anlaşılır olmasını sağladı. Bu sistem işe yaradı. Yapılanmış programların hem kusurlarının giderilmesi hem de sürekli bakımı daha kolaydı. Aslında, yapılanmış programlama öylesine geniş kabul gördü ki, dBASE II gibi bilgisayar “dilleri” -GOTO ifadelerini atlayıp yapılanmış programlamanın yapı taşlarını dahil ederek- birkaçını kapsamına aldı.
Verilerin düzenlenmesi, bilgilerin yapılanmış programlamanın programınıza sağladığı türden bir örgütlenme (iç düzen) temin eden bir ilkeler ve araçlar bütündür. Bu yöntem, mikro bilgisayar camiasında nispeten az biliniyor. Ama, asıl bilgisayar cemaatinin başka isimleri tarafından yıllardır tanınıyor. Verilerin sisteminin farklı yönlerine (veçhelerine) database düzenleme teorisi, normalleştirme ya da veri örneklemesi deniliyor. Bu makalede verilerin düzenlenmesi yönteminin üç önemli ilkesini tartışacağız: 1. Verileriniz programlarınız kadar önemlidir. 2. Veri kütüklerinizin yapısı neredeyse içerikleri derecesinde önem taşır, 3. Bazı dosya düzenlemeleri tehlikelidir.
İmdat
İşinizde bir bilgisayar programlama guru'su (mürşit) sayılıyorsunuz. Herkes yardımcı olmanız için kapınızı aşındırıyor. Bilgisayar programlama bağlantılarına (Bak. Şekil 1.) ilişkin, HELP (İmdat) adlı düzenlenmiş bir database kütüğünüz var. Help'teki her kaydın da üç alanı var: Bilgisayar ürününün ismi, bu ürünle bağlantı kuracak kişinin adı ve bu kişinin bulunabileceği bir telefon numarası. Bu bilgiyi Help database'inizden çıkarabilmek amacıyla Findhelp adlı bir program hazırladınız. Findhelp ile bilgisayar ürününün adını verdiğinizde, Findhelp anında size yardımcı olacak kişinin adı ile telefon numarasını ekrana düşürecektir. Programı herkesin hizmetine sunun, bu sayede çok sayıda kişi bu programdan istifade edebilecektir. Bilhassa, firmanızda en çok rağbet gören Paperclip kelime işleme programında yardımcı olabilir. Programınız, Paperclip konusunda yardım için Esin'e başvurulması talimatını veriyor, ama Esin bazen meşgul olabiliyor. Doğan, Esin ölçüsünde yardım edemese de, Doğan'ın her an el altında olduğunu keşfediyor. Böylece, Doğan'ın adını Help database'e ekliyor (Bak. Şekil 2). Ama, bu yeni durum anında bir mesele yarattı. Findhelp programını hazırlarken, Help dosyasındaki bilgisayarın her parçası için bir bağlantı mevcut olduğunu varsaydınız. Şimdi, Paperclip hakkında bilgi isteyen herkese program Doğan'ın ismini veriyor. Yardım konusunda en fazla yardımcı olabilecek Esin'in adı bile geçmiyor hiç. Bu misal, veri biçimlendirmenin ilk iki ilkesini canlandırıyor. Yusuf, Doğan'ın ismini Help dosyasına ekleyerek, Findhelp programını olduğundan daha az yararlı bir hale getirdi neredeyse, Findhelp programına bir çomak sokulmuş gibi oldu. Uzun lafın kısası, zayıf veriler, zayıf programlar kadar zararlı olabilirler.
Bire bir ilkesi:
İkinci ilke, veri dosyalarınızın yapısının taşıdığı önemle ilgili. Yusuf dosyadan herhangi bir şey çıkarmasa da, bu misaldeki zararın meydana geleceğine dikkat buyurunuz, lütfen. Yusuf, her bir bilgisayar başına ancak bir bağlantının kaydedilebileceği şeklindeki bağımlılık esasını ihlal etti. Findhelp programını hazırladığınızda, bu esası varsaymıştınız. Ama Yusuf'a Help dosyasının yapısını açıkladığınızda, yalnızca dosyadaki üç alanın içeriklerini izah ettiniz. Bağlantı alanının ürün alanına bağımlılığı esası dahil, dosyanın yapısını “Ürün -> Bağlantı” işareti bu bağlantıyı ifade eder. Bağlantı alanında yalnızca bir tek değerin Ürün alanındaki her bir değere tekabül etmesi demektir. Şekil 2'de bağımlılık esasına uyulmuyor zira, aynı ürüne (Procword) iki ayrı bağlantı (Doğan ve Esin) verilmiş. Ürün -> Bağlantı bağımlılığını bir başka ifade şekli de şudur: Ürün alanı Bağlantı alanını belirler. Ürün -> Bağlantı gibi bağımlılıklar, belki de, database sistemlerinde mevcut en önemli yapı türüdür. Mesela, kullanıcı kimlik numaralarını da içeren müşteri database sistemlerinde, genellikle kimlik (ID) numarası, müşterinin adına bağlıdır. Yani, bir müşteri için yalnızca bir tek kimlik (ID) numarası tahsis edilmiştir. Müşteri dosyalarını düzenleyenler sistemde bu bağımlılık ilkesini esas alan programlar mevcut olup olmadığına dikkat etmelidirler. Ki, bu sayede, yeni bir müşterinin ismi ilave edildiğinde, aynı ada kayıtlı başka müşterilerin de bulunup bulunmadığını denetleyebilsinler.
Tehlikeli Dosya
Düzenlemesi
Bağımlılıklar, bazı düzenlemelerin tehlikeli olduğuna dair üçüncü ilke açısından da temel bir ağırlık taşır. Bu ilkeyi de bir başka örnekle canlandıracağım. Esin size telefon edip telefon numarasının değiştiğini haber veriyor. Siz de büyük bir vazifeşinaslık gösterip Procword kayıtlarına bakıyor ve gereken değişikliği yapıyorsunuz. Fakaaat, Procmail ve Procbase programlarına yardımcı olan Esin'in bağlantı değerine sahip olduğunu unuttunuz. Database'iniz şu anda Şekil 3.'de olduğu gibi bir görünüm aldı. Esin ile bağlantı kurmak amacıyla sizin database'inizi kullanan bir kimse, yüzde 67 ihtimalle onun eski -ve tabii, yanlış- numarasını bulacaktır. Dosya düzenlemenizin başka sorunları da yok değil. Diyelim ki, Spread konusunda Cevat fevkalade yardımcı oluyor ve onun özel telefon numarasını elde etmeyi başardınız. Bir gün, Spread arızalandığı için iptal edilince siz de onun kaydını database'den sildiniz. Ertesi hafta, bir arkadaşınız Cevat'ın Comm. için de fevkalade yardımcı olabileceğini söylüyor size. Ama, ne yazık ki, geçmiş olsun Cevat'ın özel telefon numarasını kaybetmiş bulunuyorsunuz. Son bir potansiyel sorun daha: Eğer Esin sizin 100 ürününüz için bağlantı değerine sahipse, onun telefon numarasını yüz ayrı yerde kaydederek database'inizde boşu boşuna bir sürü yer işgal ve israf ediyorsunuz demektir. Kuşkusuz, eğer database'inizin ileride bir telefon rehberi olarak kullanılabileceğini önceden görebilmiş olsaydınız, tüm bu sorunlarınızın önüne geçilebilirdi. Database'inizi biri bağlantılar, öbürü de telefon rehberi olmak üzere, ikiye bölerdiniz. Böylece, her şey halloluverirdi. Verilerin düzenlenmesi, sizi ileriyi görmek zorunda bırakmaksızın elverişli ve uygun dosya yapıları oluşturmanıza imkan veren tahlil araçlar da sağlar. Bu araçlar yukarıda bahsi geçen sorunların doğmasını önler; dosyalar çok geniş ve kendi aralarında ilişkili çok sayıda alanın oluşturduğu karmaşık bir manzara arzettiği zamanlarda bile... Tehlikeli dosya düzenlemelerini engellemek için, dosyanızdaki bağımlılıkların neyin nesi olduklarına iyice vakıf bulunmalısınız. Bağımlılıklar ile tehlikeli dosya yapıları arasındaki bağlantıyı, Help'teki bağımlılıkların veri düzenlenmesi işinden biraz anlayan herkese açık seçik ikaz işaretleri verdiğini göstererek açıklayacağım.
Geçişli Bağımlılıklar
Farzedelim ki, Şekil 4., Help dosyanızdaki tüm bağımlılıkları liste halinde gösteriyor. Ürün'den Bağlantı'ya ve Bağlantı'dan Telefon'a olan geçişli bağımlılığa dikkat buyurunuz. Geçişli bağımlılık A, B ve C alanları iki bağımlılığa sahip olduğu durumlarda ortaya çıkar: A -> B ve B -> C'de (bu bağımlılıklar Ürün -> Bağlantı ve Bağlantı -> Telefon biçimindedir) Ve, B ile A arasında hiç bağımlılık yoktur. Herhangi bir geçişli bağımlılık tehlikeli bir dosyalama yapısına işaret eder. Esin'in telefon numarasının Help dosyasında gereksiz yere tekrar edilişi gibi, A -> B -> C şeklinde bir geçişli bağımlılık her zaman, A'nın farklı değerleri için C değerleriyle birlikte düzenlenen B değerlerinin tekrarlanması sonucunu verecektir. Ve bu tekrarlanış, sırası geldiğinde, eğer tutar bir de database'inizi değiştirirseniz biribirini hiç tutmayan, yanlış bilgilere de yol açabilir. Esin'in telefon numarasının yanlış kaydı meselesinde olduğu gibi. Aynı zamanda, yer israfına da sebep olabilir, bunun örneğini, Esin'in telefon numarasının 100 defa kaydedilmesi olayında gördük. Geçişli bağımlılıklar, dosyaların düzenlenmesinde daimi olarak yapısal sorunlara sebebiyet verirler. Eğer bu tür geçişli bağımlılıklara dikkat ederseniz, yukarıda izah ettiğim güçlüklerden kendinizi korumuş olursunuz.
Ne Yapmalı?
Bu makalenin sizi, database dosyalarınızı yeniden bir göz gezdirmeye ve içerdikleri bağımlılıkların bir dökümünü çıkarmaya ve sonra da geçişli bağımlılıkları bir daha incelemeye sevkedeceğini ümit ediyorum. Ama, öyle uzun boylu büyüleneyim demeyin. Yapılanmış programlamanın gerektiğinde GOTO ifadelerinden istifa etmesi gibi, verilerin düzenlenmesi teorisi de, düzenleyiciye yönelik bir dizi uyarı olarak düşünülmelidir. Help dosyasının tehlikeli olabileceğinde gösterdiğim gibi, çeşitli nedenler onu kendi haline bırakmayı da haklı gösterebilir. Mesela, bir dosyadaki geçişli bağımlılıktan kurtulmanın olağan yolu, dosyayı iki yeni dosyaya bölmektir. Sizin sahip olduğunuz database sistemi bir seferde iki dosyaya bölünmeye müsait olmayabilir. Bu nedenle, eğer dosyalarınızda geçişli ya da gömülü bağımlılıklar keşfederseniz, dosya yapısını değiştirmeye kalkışmadan önce, işin daha da çatallaşabileceğini de hesaba katın. En azından iki önemli soru kalıyor geriye: Bir geçişli veya gömülü bağımlılık keşfettiğinizde, bunu nasıl düzelteceksiniz? Ve database'leri daha işin en başından bu türden bağımlılıklar yaratmamaları için, nasıl düzenlemek gerekiyor? Bu soruların cevaplarını daha ilerki sayılarımızda bulacaksınız. Ayrıca, aşağıda adları verilen kitapların incelenmesi, bu soruların cevaplarını kendi başınıza bulmanızı sağlayacaktır.
Ürün Bağlantı — Telefon no: Spread...... Esin 568-6588 Comm....... Esin 937-8194 Comm....... Doğan 485-0898 Procmail.... Esin 237-8194 Procbase...Esin 237-8194
Şekil 1. Help. Bilgisayar ürünlerinin bir dosya database'i.
Ürün Bağlantı — Telefon no: Procword...Doğan....... 263-2900 Spread...... Sama 568-6588 Ece 237-8194 Comm....... 485-0898 Procmail ... Ece 237-8194 Procbase... 237-8194
Şekil 2. Help'e yeni bir bağlantı ilave ediyor. Doğan eklendi.
Ürün Bağlantı Telefon no: Procword...Doğan....... 525-5793 Spread...... Sn 332-3208 520-1453 Comm....:.. 485-0898 Procmail .... Verm 237-8194 237-8194
Şekil 3. Help'de bir bağlantı için tutarsız, yanlış telefon numaraları, Esin
Bağımlılık > Bağlantı
Database'de her Ürün için yalnızca bir bağlantı mevcut demektir (Bu bağımlılık esası Şekil 2'nin örneğinde geçerli değildir. Çünkü, Procword ürünü için birden fazla bağlantı gösterilmiştir.)
Bağımlılık > Telefon
Database'de bir bağlantı verilmiş ve bu bağlantı ile yalnızca bir tek telefon numarası bağlantılı demektir. (Bu bağımlılık esası, Şekil 1'deki örnek için geçerli ama, Şekil 3 için geçerli değildir.)
Şekil 4. Help'te muhtemel bağımlılıklar.