İleri Düzey Datalanguage Tasarım Kavramları

Richard Winter
Jeffrey Hill
Warren Greiff

Computer Corporation of America
15 Aralık 1973

Teşekkür

Datacomputer Projesi süresince, datalanguage’ın geliştirilmesine birçok kişi katkıda bulunmuştur.

Dr. Gordon Everest’in (Minnesota Üniversitesi), Dr. Robert Taylor’ın (Massachusetts Üniversitesi), Profesör Thomas Cheatham’ın (Harvard Üniversitesi) ve Profesör George Mealy’nin (Harvard Üniversitesi) önerileri ve eleştirileri özellikle yararlı olmuştur.

CCA bünyesinde, yazarların yanı sıra çeşitli proje aşamalarında dil tasarımına katılan birkaç kişi daha olmuştur. Hal Murray, Bill Bush, David Shipman ve Dale Stern özellikle önemli katkılar sağlamıştır.

1. Giriş

1.1 Datacomputer Sistemi

Datacomputer, diğer bilgisayarlara veri depolama ve veri yönetimi hizmetleri sunan, büyük ölçekli bir veri yardımcı sistemidir.

Datacomputer, geleneksel veri yönetim sistemlerinden çeşitli yönlerden ayrılır.

Birincisi, özel donanım üzerinde uygulanmıştır ve veri yönetimi için özelleştirilmiş ayrı bir hesaplama sisteminden oluşur.

İkincisi, sistem büyük ölçekte uygulanmıştır. Verilerin, kapasitesi trilyon bit mertebesinde olan kütlesel depolama aygıtlarında saklanması amaçlanmaktadır. Yüz milyar bit mertebesindeki dosyaların çevrimiçi tutulması planlanmaktadır.

Üçüncüsü, farklı ortamlarda çalışan süreçler arasında veri paylaşımını desteklemesi amaçlanmaktadır. Yani, belirli bir veritabanını paylaşan programlar farklı dillerde yazılmış olabilir, farklı işletim sistemleri altında farklı donanımlar üzerinde çalışabilir ve kökten farklı gereksinimlere sahip son kullanıcılara hizmet verebilir. Bir veritabanının bu şekilde ortak kullanılabilmesi için, çeşitli donanım gösterimleri ve veri yapılandırma kavramları arasında dönüşümlerin gerçekleştirilmesi gerekir.

Son olarak, datacomputer çok daha büyük bir sistemin, yani bir bilgisayar ağının, bir bileşeni olarak sorunsuz biçimde çalışacak şekilde tasarlanmıştır. Bir bilgisayar ağında datacomputer, veri yönetimi konusunda uzmanlaşmış bir düğümdür ve diğer düğümler için bir veri yardımcı birimi olarak görev yapar. Datacomputer’ın geliştirildiği Arpanet, 60’tan fazla düğümü olan uluslararası bir ağdır. Bunların bazıları terminal işlemleri için uzmanlaşmıştır, bazıları hesaplama için uzmanlaşmıştır (örneğin ILLIAC IV), bazıları genel amaçlı hizmet düğümleridir (örneğin MULTICS) ve biri (CCA) veri yönetimi için uzmanlaşmıştır.

1.2 Datalanguage

Datalanguage, datacomputer’a yapılan tüm isteklerin ifade edildiği dildir. Veri tanımlama ve oluşturma, depolanmış verilerin geri çağrılması veya değiştirilmesi ve çeşitli yardımcı olanaklara ve hizmetlere erişim için olanaklar içerir. Datalanguage ile datacomputer’ın gerçekleştirebildiği her türlü işlemi belirtmek mümkündür. Datalanguage, datacomputer tarafından kabul edilen tek dildir ve verilere ve hizmetlere erişimin tek yoludur.

1.3 Mevcut Tasarım Çalışması

Şu anda datalanguage için eksiksiz özelliklerin geliştirilmesi üzerinde çalışıyoruz; bu, dil tasarım sürecindeki ikinci yinelemedir.

Daha küçük ölçekli, başlangıç niteliğindeki bir tasarım çalışması, bu dizideki üçüncü çalışma raporunda açıklanan bazı kavramları ve ilkeleri geliştirmiştir. Bunlar, ilk ağ hizmeti yeteneğiyle sonuçlanan yazılım uygulamalarının temelini oluşturmuştur. Bu sistem için bir kullanıcı kılavuzu, 7 numaralı çalışma raporu olarak yayımlanmıştır.

Uygulama ve hizmet sürecinde kazanılan deneyimler, kullanıcı gereksinimlerinin daha ayrıntılı incelenmesi ve potansiyel kullanıcılarla yapılan çalışmalar ile veri yönetimi alanındaki diğer çalışmaların araştırılması sonucunda, datalanguage’ın iyileştirilmesine yönelik oldukça fazla sayıda fikir geliştirilmiştir. Bunlar, şu anda devam eden yinelemede dil tasarımına dahil edilmektedir.

Dil tasarımı tamamlandığında, mevcut yazılıma entegre edilecektir (dil derleyicisinde değişiklikler gerektirecek, ancak sistemin geri kalanı üzerinde çok az etki yaratacaktır).

Datacomputer kullanıcıları yeni dile ilk kez 1975 yılı içinde erişebilecektir.

1.4 Bu Makalenin Amacı

Bu makale, tamamlanmış bir tasarımdan ziyade kavramları ve ön sonuçları sunmaktadır. Şimdi yayımlanmasının iki nedeni vardır.

Birincisi, datacomputer’ı kullanmayı planlayanlara bilgi sağlamaktır. Geliştirme konusundaki niyetlerimiz hakkında bilgi sahibi olmaları kendileri için yararlı olabilir.

İkincisi ise, tasarım kesinleşmeden önce sistem ve dil tasarımcılarının çalışmamız hakkında görüş bildirmelerini mümkün kılmaktır.

1.5 Makalenin Organizasyonu

Makalenin geri kalanı dört bölüme ayrılmıştır.

Bölüm 2, dil tasarımı için en genel değerlendirmeleri ele alır. Bu bölüm, probleme bakış açımızı kapsar; bugüne kadarki çalışmalarımızı etkilemiş ve tasarımın tamamlanmasında atacağımız adımların çoğunu belirleyecektir. Bu bölüm, Bölüm 3 için arka plan sağlar ve çalışmamızı yakından izleyenlere tanıdık gelecek bazı materyalleri gözden geçirir.

Bölüm 3, üzerinde çalıştığımız bazı özgül konuları tartışır. Vurgu, çözümler ve çözüm seçenekleri üzerindedir.

Bölüm 2 ve 3’te, “yukarıdan aşağıya” yaklaşımımızı sunuyoruz: bu, bilinen gereksinimlere ve datalanguage’ın arzu edilen özelliklerine ilişkin anlayışımıza dayalı olarak yaptığımız düşünsel çalışmadır.

Buna karşılık, dili inşa edeceğimiz temel öğeleri geliştirerek, karşı uçtan da çalışmaktayız. Bölüm 4, bu alandaki çalışmamızı sunar: nihai olarak datalanguage’ın kesin anlamsal tanımını sağlayacak bir model datacomputer. Bölüm 4, modelin tamamlanmış olan kısmını açıklar ve bunu diğer çalışmalarımızla ilişkilendirir.

Bölüm 5, hem model üzerinde hem de yukarıdan aşağıya analizimizde geriye kalan çalışmaları ele alır.

2. Dil Tasarımı İçin Değerlendirmeler

2.1 Giriş

Veri yönetimi, donanım ve uygulama programlarından bağımsız olarak, veriyi bir kaynak olarak yönetme görevidir. Beş ana alt göreve ayrılabilir:

1. depolamada veritabanlarının oluşturulması,
2. verinin kullanıma sunulması (örneğin sorguların karşılanması),
3. bilgi eklendikçe, silindikçe ve değiştirildikçe verinin bakımının yapılması,
4. verinin bütünlüğünün güvence altına alınması (örneğin yedekleme ve kurtarma sistemleri, iç tutarlılık denetimleri yoluyla),
5. veritabanlarını, sistemi ve kullanıcıların gizliliğini korumak için erişimin düzenlenmesi.

Bunlar, datacomputer’ın veriye ilişkin başlıca işlevleridir; sistem nihai olarak başka hizmetler de sağlayacak olsa da (örneğin kullanım muhasebesi, performans izleme), bunlar esasen yardımcı niteliktedir ve tüm hizmet tesislerinde ortaktır.

Bu bölüm, problemler ve çözülmesi gereken ortam hakkındaki gözlemlerimize dayanarak, datalanguage tasarımı için genel değerlendirmeleri sunmaktadır. Temel problem veri yönetimidir ve datacomputer, günümüzde mevcut olan birçok veri yönetim sistemiyle aynı hedefleri paylaşır. Ancak datacomputer’ın bazı özellikleri, çözülmesi gereken kendine özgü bir problem kümesi ortaya çıkarmaktadır.

2.2 Donanım Değerlendirmeleri

2.2.1 Ayrı Kutu

Datacomputer, ayrı ve kapalı bir kutu içinde yer alan, eksiksiz bir veri yönetimi yardımcı sistemidir. Yani donanım, veriler ve veri yönetimi yazılımı, genel amaçlı herhangi bir işlem tesisinden ayrılmıştır. Veri yönetimine adanmış ayrı bir kurulum bulunmaktadır. Kullanıcıların datacomputer ile iletişim kurmak için sahip oldukları tek araç datalanguage’tır ve datacomputer’ın tek faaliyeti datalanguage isteklerini işlemektir.

Donanımın adanması açık bir avantaj sağlar: veri yönetimi için özelleştirilebilir. İşlemci(ler) veri yönetimi “komutlarına” sahip olacak şekilde değiştirilebilir; yaygın düşük seviyeli yazılım işlevleri donanıma gömülebilir.

Daha az belirgin, ancak muhtemelen daha önemli bir avantaj ise ayrılığın kendisinden kaynaklanır. Sistem daha kolay korunabilir. Üzerinde yalnızca bakım faaliyetlerinin bulunduğu, tam olarak geliştirilmiş bir datacomputer, son derece dikkatle denetlenen bir ortam sağlayabilir. Birincisi, gerektiği kadar fiziksel olarak güvenli hale getirilebilir. İkincisi, yalnızca CCA’da geliştirilmiş sistem yazılımlarını çalıştırması gerekir; tüm kullanıcı programları, sistem tarafından etkin biçimde yorumlanan yüksek seviyeli bir dilde (datalanguage) yazılır. Dolayısıyla verileri yalnızca datacomputer sistem yazılımı işler ve sistem, düşmanca bir program tarafından ele geçirilmeye karşı çok savunmasız değildir. Bu nedenle, genel amaçlı sistemlerde bulunmayan veri gizliliği ve bütünlüğü hizmetlerini geliştirme potansiyeli olduğundan, datacomputer için (fiziksel olanlar dâhil) gizlilik denetimlerinin geliştirilmesinde, hizmet verdiği sistemlere kıyasla daha az zorluk beklenebilir.

2.2.2 Kütlesel Depolama Donanımı

Datacomputer, verilerinin çoğunu, kendine özgü erişim özelliklerine sahip kütlesel depolama aygıtlarında saklayacaktır. Bu tür donanımlara iki örnek Precision Instruments’ın Unicon 690’ı ve Ampex Corporation’ın TBM sistemidir. Bunlar disklerden oldukça farklıdır ve birbirlerinden de önemli ölçüde ayrılırlar.

Bununla birlikte, kullanıcıların neredeyse tamamı bu aygıtların özelliklerinden habersiz olacaktır; hatta birçoğu kullandıkları verinin datacomputer’da bulunduğunu bile bilmeyecektir. Son olarak, sistemin geliştirilmesi ilerledikçe, veriler görünmez biçimde bir datacomputer’dan diğerine aktarılabilir ve bunun sonucunda, başlangıçta kullanılan fiziksel formattan oldukça farklı bir biçimde saklanabilir.

Böyle bir ortamda, veri isteklerinin fiziksel değil, mantıksal terimlerle ifade edilmesi gerektiği açıktır.

2.3 Ağ Ortamı

Ağ ortamı, datacomputer tasarımı için ek gereksinimler ortaya koyar.

2.3.1 Uzaktan Kullanım

Datacomputer’a uzaktan erişileceği için, etkili veri seçme tekniklerine ve seçim ölçütlerinin ifadesi için iyi mekanizmalara duyulan gereksinim artmaktadır. Bunun nedeni, ağ kullanıcılarının datacomputer ile iletişim kurduğu yolun dar olmasıdır. Günümüzde Arpanet üzerinden tipik bir süreçten sürece aktarım hızı saniyede 30 kilobittir. Yazılım ve protokollerin iyileştirilmesi ve donanım ile iletişim hatlarına ek harcamalar yoluyla bu hız artırılabilse de, yakın zamanda yerel aktarım hızlarına (saniyede megabitler mertebesinde ölçülen) yaklaşmasının olası olmadığı söylenebilir.

Tipik bir istek, ya bir dosyanın bir bölümünün uzak bir siteye aktarılmasını ya da halihazırda datacomputer’da depolanmış bir dosya üzerinde seçici bir güncelleme yapılmasını gerektirir. Bu durumların her ikisinde de, iletilecek ya da değiştirilecek veri kısımlarının iyi bir şekilde belirtilebilmesini sağlayan mekanizmalar, normalde aktarılan veri miktarını azaltacaktır. Bu son derece önemlidir; çünkü datacomputer’da veri depolamanın bit başına maliyeti düşük olsa da, iletim maliyetleri datacomputer kullanımının toplam maliyetinin önemli bir bölümünü oluşturacaktır.

2.3.2 Datacomputer Sisteminin Süreçler Arası Kullanımı

Ağın etkin kullanımı, birbirinden uzakta bulunan süreç gruplarının, belirli bir görevi başarmak veya belirli bir hizmeti sunmak için iş birliği yapabilmesini gerektirir. Örneğin, dizi işleme, veri geri çağırma, bir terminaldeki kullanıcıyla etkileşim ve PL/I gibi bir dilin genel hizmetlerini içeren bir problemin çözümü için, dört işbirlikçi sürecin kullanılması en ekonomik yaklaşım olabilir. Bunlardan biri ILLIAC IV üzerinde, biri datacomputer’da, biri MULTICS üzerinde ve biri de bir TIP üzerinde çalışabilir. Bu dört sürecin kurulması ve aralarında iletişim sağlanması ek yük getirse de, her biri kendi işini o işe özel olarak tasarlanmış bir sistem üzerinde yapmaktadır.

Birçok durumda, uzmanlaşmış sistemin kullanılması, ekonomi veya verimlilik açısından birkaç büyüklük mertebesinde kazanç sağlar (örneğin, datacomputer’daki çevrimiçi depolamanın sermaye maliyeti, geleneksel sistemlerdeki çevrimiçi maliyetlerden iki büyüklük mertebesi daha düşüktür). Sonuç olarak, uzmanlaşmış sistemler üzerinde işbirliği yapan süreçleri içeren çözümleri dikkate almak için güçlü bir teşvik vardır.

Özetle: datacomputer, birçok uzmanlaşmış düğümün bulunduğu bir ağda etkin biçimde kullanılabilmesi için, küçük uzmanlaşmış süreç ağlarının bir bileşeni olarak çalışmaya hazır olmalıdır.

2.3.3 Ortak Ağ Veri İşleme

Büyük bir ağ, birden fazla datacomputer oluşturacak kadar veri yönetimi donanımını destekleyebilir. Bu donanım tek, daha da büyük bir datacomputer halinde birleştirilebilse de, iki (veya muhtemelen daha fazla) sistem olarak yapılandırmanın avantajları vardır. Her sistem, veri depolamada ölçek ekonomileri elde edecek ve veri yönetimi yazılımını destekleyecek kadar büyük olmalıdır.

Önemli veritabanları çoğaltılabilir ve her datacomputer’da bir kopyası bulunabilir; eğer bir datacomputer arızalanırsa veya ağ hatası nedeniyle bağlantısı kesilirse, veriler yine de erişilebilir olur. Dosyanın çoğaltılması gerekmediği durumlarda bile, tanım bilgisi farklı datacomputer’larda tutulabilir; böylece sürekli veri depolaması gereken uygulamalara, en az bir datacomputer’ın girdi almaya hazır olduğu garanti edilebilir.

Bu tür arıza koruma yöntemleri, bir çift datacomputer arasında iş birliği gerektirir; bir bakıma, iki datacomputer’ın tek bir sistem gibi çalışmasını zorunlu kılar. Bir datacomputer sistemler kümesi verildiğinde (ki bu, küçük bir datacomputer ağı olarak düşünülebilir), ağ düzeyinde veri işleme problemine yönelik ek hizmetler sağlama konusunda deneyler yapmak açıkça mümkündür. Örneğin, tüm istekler doğrudan datacomputer-ağına yönlendirilebilir; datacomputer-ağı daha sonra başvurulan her dosyanın nerede saklandığını (yani hangi datacomputer’da olduğunu) ve isteğin en iyi şekilde nasıl karşılanacağını belirleyebilir.

Burada, ağ ortamında iki tür iş birliğinden söz edilmiştir: belirli bir problemi çözmek için süreçler arası iş birliği ve ağ düzeyinde veri işleme probleminde küresel iyileştirmeler sağlamak için datacomputer’lar arası iş birliği. Bunlar, özellikle yakın vadede uygulanabilir olmaları nedeniyle ilgi çekici iki örnektir. Ağda, biraz daha ileri bir gelecekte, çok daha genel iş birliği türleri mümkündür. Örneğin, nihayetinde datacomputer(lar)ın, verilerin, dizinlerin, hizmetlerin ve donanımın ağ genelinde dağıtıldığı, ağ çapında bir veri yönetimi sisteminin parçası olması istenebilir. Tüm sistem, uygun koşullar altında bir bütün olarak çalışabilir. Çoğu istek, yalnızca birkaç düğümün verilerini ve hizmetlerini kullanır. Bu ağ çapındaki sistem içinde birden fazla veri yönetimi sistemi bulunur, ancak tüm sistemler ortak bir dil aracılığıyla birbirine bağlanır. Datacomputer’lar ağdaki en büyük veri yönetimi kaynağını temsil ettiklerinden, ağ çapındaki herhangi bir sistemde mutlaka önemli bir rol oynayacaklardır. Datacomputer’ın dili olan datalanguage, böyle bir sistem için ortak dil olarak son derece uygun bir seçimdir.

Dolayısıyla, ağın datacomputer sisteminin tasarımına getirdiği nihai —her ne kadar geleceğe dönük olsa da— gereksinim, onun ağ çapında veri yönetimi sistemleri için uygun bir ana bileşen olmasıdır. Mümkünse, datalanguage’ın, iş birliği yapan veri yönetimi sistemlerinden oluşan ağ çapındaki bir grubun ortak dili için uygun bir aday olması istenir.

2.4 Databilgisayar Kullanımının Farklı Modları

Bu ağ ortamı içinde, databilgisayar birden fazla rol oynayacaktır. Bu bölümde bu tür dört rol tanımlanmaktadır. Bunların her biri, veri dilinin tasarımı üzerinde kısıtlamalar getirir. Bu rolleri, databilgisayarın sağladığı ve birbiriyle örtüşen dört avantaj açısından inceleyebiliriz:

1. Genelleştirilmiş veri yönetimi hizmetleri
2. Büyük dosya işleme
3. Paylaşımlı erişim
4. Ekonomik hacimsel depolama

Elbette, databilgisayarın kullanılmasının temel nedeni sunduğu veri yönetimi hizmetleri olacaktır. Ancak bazı uygulamalar için belirleyici etken boyut olacaktır; bu anlamda databilgisayar, daha önce yalnızca çevrimdışı depolama ve işleme ile mümkün olan kadar büyük dosyalara çevrimiçi erişim sağlayacaktır. Farklı ve geniş ölçüde değişen donanımlara sahip ağ düğümleri arasında veri paylaşabilme yeteneği, yalnızca databilgisayar tarafından sağlanan bir başka özelliktir. Ölçek ekonomileri, databilgisayarı işletim sistemi yedekleme gibi uygulamalarda bantların yerine geçebilecek uygulanabilir bir alternatif haline getirir.

Doğal olarak, çoğu databilgisayar uygulamasında yukarıdaki etkenlerin bir bileşimi söz konusu olacaktır. Aşağıdaki alt bölümler, databilgisayar ile etkileşimin bazı olası modlarını tanımlar.

2.4.1 Büyük Paylaşımlı Veritabanlarının Desteklenmesi

Bu, neredeyse her açıdan databilgisayarın en önemli uygulamasıdır.

Arpanet databilgisayarı üzerinde yüz milyar bitten fazla veriyi çevrimiçi hale getirecek projeler halihazırda yürütülmektedir. Bunlar arasında, dünyanın dört bir yanına dağılmış 5000 hava durumu istasyonundan elde edilen 10 yıllık hava gözlemlerini nihai olarak içerecek bir veritabanı da bulunmaktadır. Çevrimiçi veritabanları olarak bunlar, boyut açısından emsalsizdir. Uluslararası ilgi görecekler ve çok çeşitli donanımlar üzerinde, çok çeşitli dillerde çalışan kullanıcılar tarafından paylaşılacaktır.

Bu veritabanları uluslararası bir ağda çevrimiçi oldukları ve ilgili alanlardaki araştırmacılar için büyük ilgi uyandırmaları beklendiği için, son derece geniş kullanım örüntülerinin ortaya çıkacağı açıktır. Dolayısıyla güçlü bir gereksinim, bunların ele alınmasında esnek ve genel bir yaklaşımdır. Bir veritabanının farklı kullanıcılarına verinin farklı görünümlerini sağlama gereksinimi, veri dili tasarım çabasının baskın bir kaygısıdır. Bu konu Bölüm 2.5'te ayrı olarak ele alınmaktadır.

2.4.2 Yerel Veri Yönetim Sistemlerinin Genişletilmesi

Yerel veri işleme sistemlerinin (veri yönetim sistemleri, uygulama odaklı paketler, metin işleme sistemleri vb.) databilgisayardan yararlanmak isteyeceklerini varsayıyoruz. Bunu, depolamanın ekonomisi nedeniyle, veri yönetimi hizmetleri nedeniyle ya da databilgisayarda zaten depolanmış olan verilerden yararlanmak istedikleri için yapabilirler. Her durumda, bu tür sistemlerin databilgisayar kullanıcıları olarak bazı ayırt edici özellikleri vardır:

1. Çoğu, hem yerel verileri hem de databilgisayar verilerini kullanacaktır.
2. Birçoğu, yerel isteklerin veri diline çevrilmesiyle ilgilenecektir.

Örneğin, programlama bilgisi olmayan sosyal bilimciler için basit veri erişimi ve istatistiksel analiz yapan bir sistem, databilgisayarda depolanan bir nüfus sayımı veritabanını kullanmak isteyebilir. Böyle bir sistem, çeşitli veri erişim işlevleri gerçekleştirebilir ve databilgisayar ile gelişmiş bir etkileşime ihtiyaç duyabilir. Kullanım örüntüleri, databilgisayarı yalnızca bilinen tek bir dosyaya dayalı belirli bir raporu yazdırmak için kullanan tek bir uygulama programının kullanım örüntülerinden oldukça farklı olacaktır.

Bu sosyal bilimler sistemi, küçük oldukları ve yerel olarak daha verimli erişildikleri için kendi sahasında tuttuğu bazı yerel veritabanlarını da kullanacaktır. Verinin, yerel olarak mı yoksa databilgisayarda mı depolandığına bakılmaksızın, aynı şekilde düşünülmesi uygun olurdu. Elbette yerel yazılımın alt düzeylerinde arayüzleme açısından farklılıklar olmak zorunda kalacaktır; ancak yerel kavramların ve işlemlerin veri diline kolayca çevrilebilmesi arzu edilir.

2.4.3 Databilgisayarın Dosya Düzeyinde Kullanımı

Bu kullanım modunda, diğer bilgisayar sistemleri databilgisayarın çevrimiçi depolama kapasitesinden yararlanır. Bu sistemler için databilgisayar depolaması yeni bir depolama sınıfını temsil eder: banttan daha ucuz ve daha güvenli, yerel disk kadar olmasa da ona yakın derecede erişilebilir. Hatta dosyaları yerel çevrimiçi depolama ile databilgisayar arasında otomatik olarak taşıyabilirler; böylece kullanıcılara her şeyin yerel olarak çevrimiçi depolandığı izlenimini verebilirler.

Bu kullanım modunun ayırt edici özelliği, işlemlerin tüm dosyalar üzerinde yapılmasıdır.

Bu modda çalışan bir sistem yalnızca depolama, geri alma, ekleme, yeniden adlandırma, dizin listeleme ve benzeri yetenekleri kullanır. Bu tür dosya düzeyinde işlemleri ağ topluluğuna kolayca sunmanın açık bir yolu, halihazırda ana bilgisayardan ana bilgisayara dosya aktarımı için kullanılan Dosya Aktarım Protokolü'nden (Network Information Center belgesi #17759 — File Transfer Protocol) yararlanmaktır.

Databilgisayarın bu tür "tüm dosya" kullanımının temel motivasyonu ölçek ekonomilerinin sağladığı avantajlar olsa da, dosya düzeyinde veri paylaşımı da bir kaygı olabilir. Örneğin, ortak ağ yazılımlarının kaynak dosyaları databilgisayarda bulunabilir. Bu dosyalar çok az yapıya sahiptir ya da hiç yapıya sahip değildir; ancak ortak kullanımları, her zaman erişilebilir ortak bir yerde bulunmalarını gerektirir. Bu durum, bu hizmetlerin çoğunun herhangi bir dosya sisteminde mevcut olmasına rağmen, her şeyden çok databilgisayarın ekonomisinden yararlanılması anlamına gelir.

Bu kullanım modu burada anılmaktadır; çünkü veri dili isteklerinin büyük bir yüzdesini açıklayabilir. Her durumda veri dilinde bulunacak yeteneklerden başka bir şey gerektirmez; tek özel gereksinim, bu görevlerin gerçekleştirilmesinin kolay ve basit olmasının sağlanmasıdır.

2.4.4 Dosya Arşivleme için Databilgisayar Kullanımı

Bu da ekonomiye dayalı bir başka uygulamadır. Temel fikir, nadiren — hatta belki hiç — okunması planlanan her şeyi databilgisayarda depolamaktır. Buna yedek dosyalar, denetim kayıtları ve benzerleri dahil olabilir.

Arşivleme ile ilişkili ilginç bir fikir artımlı arşivlemedir. Zaman paylaşımlı bir sistemde çevrimiçi depolanan verilerin yedeklenmesiyle ilgili tipik bir uygulama, son döküme kıyasla farklı olan tüm sayfaların yazılmasıdır. Daha sonra, son tam döküm geri yüklenerek ve istenen sürüme kadar olan tüm artımlı dökümler geri yüklenerek kurtarma yapmak mümkündür. Bu sistem, döküm alma ve depolama için daha düşük maliyet, kurtarma için ise daha yüksek maliyet sunar; kurtarma gereksinimi olasılığının düşük olduğu durumlar için uygundur. Dolayısıyla veri dili, kullanışlı artımlı arşivlemeye izin verecek şekilde tasarlanmalıdır.

Önceki uygulamada (dosya sistemi) olduğu gibi, arşivleme de dil düzeyinde mutlaka ek bir genellik gerektirdiği için değil, beklenen sıklığı ve ekonomisi nedeniyle bir tasarım değerlendirmesi olarak önemlidir. Bu, arşivleme için özel mekanizmaların sistemin içine yerleştirilmesini gerektirebilir.

2.5 Veri Paylaşımı

Verinin denetimli paylaşımı projenin merkezi bir kaygısıdır. Veri paylaşımındaki üç ana alt problem şunlardır:

1. Eşzamanlı kullanım
2. Aynı veritabanının bağımsız kavramları
3. Aynı veritabanının değişen temsilleri

Bir kaynağın birden fazla bağımsız süreç tarafından eşzamanlı kullanımı, dosyaların birbirinden bağımsız, ilişkisiz nesneler olarak kabul edildiği sistemlerde genellikle dosya düzeyinde uygulanır. Bazen sayfa düzeyinde de uygulanır.

Bu problem üzerinde databilgisayar projesi kapsamında halihazırda önemli çalışmalar yapılmıştır. Bu çalışmalar tamamlandığında, dil tasarımı üzerinde bir miktar etkisi olacaktır; ancak genel olarak, eşzamanlı kullanımın bu yönünü bir dil problemi olarak görmüyoruz.

Ancak eşzamanlı kullanım probleminin diğer yönleri, kullanıcının daha bilinçli katılımını gerektirebilir. Bunlar, iç işletim sistemi tarafından bilinen dosyaların sınırlarını aşan veri nesnesi koleksiyonlarının anlambilimiyle ilgilidir. Burada bir güncelleme çakışmasının neyi oluşturduğu sorusu daha karmaşıktır. Yedekleme ve kurtarma ile ilgili benzer sorular ortaya çıkar. Eğer iki dosya ilişkiliyse, birinin önceki bir durumunu geri yüklemek, diğerinin karşılık gelen durumunu geri yüklemeden anlamsız olabilir. Bu problemler henüz araştırılmamıştır.

Veri paylaşımındaki bir diğer problem, bir veritabanının tüm kullanıcılarının o veritabanı hakkında aynı kavrama sahip olmaması gerektiğidir. Örnekler:

1. Gizlilik nedenleriyle, bazı kullanıcılar veritabanının yalnızca bir kısmından haberdar olmalıdır (örneğin, tıbbi dosyalar üzerinde istatistiksel çalışmalar yapan bilim insanlarının ad ve adres bilgilerine erişmesi gerekmez).
2. Program-veri bağımsızlığı için, bordro programları, beceri envanterleri aynı veritabanında depolanıyor olsa bile, yalnızca maaş çeklerinin yazılmasıyla ilgili verilere erişmelidir.
3. Verimliliğin küresel denetimi, uygulama programlamasında sadelik ve program-veri bağımsızlığı için, her uygulama programı işi için en uygun veri organizasyonunu "görmelidir".

Örnek (3)'ü daha ayrıntılı analiz etmek için, öğrenciler, öğretmenler, dersler hakkında bilgi içeren ve ayrıca hangi öğrencilerin hangi dersler için hangi öğretmenlere sahip olduğunu gösteren bir veritabanını düşünelim. Çözülecek probleme bağlı olarak, bir uygulama programının aşağıdaki organizasyonlardan biri için güçlü bir gereksinimi olabilir:

1. Yedeklilikle ilgilenilmeksizin (öğrenci, öğretmen, ders) biçiminde kayıtlar. Bu organizasyonda üç türden herhangi birine ait bir nesne birçok kez ortaya çıkabilir.

2. Aşağıdaki biçimde kayıtlar:

   (öğrenci, (öğretmen, ders), (öğretmen, ders), . . . (öğretmen, ders))

3. Aşağıdaki biçimde kayıtlar:

   (öğretmen, ders, (öğrenci ... öğrenci), ders, (öğrenci ... öğrenci), ders, (öğrenci ... öğrenci))

Elbette başka organizasyonlar da mümkündür.

Bu probleme yönelik bir yaklaşım, depolanan veriler için bir organizasyon seçmek ve ardından uygulama programlarının çıktıyı istedikleri biçimde düzenleyen istekler yazmasını sağlamaktır. Uygulama programcısı, yeniden organizasyon sürecinin geri alma süreciyle birleştirilmesi için isteği ifade etmede yaratıcılığını kullanır ve sonuç görece verimli olur. Bu yaklaşımın yeterli olduğu önemli, pratik durumlar vardır; hatta istenir olduğu durumlar da vardır. Özellikle, verimlilik ya da maliyet baskın bir değerlendirme ise, her uygulama programcısının tüm veri erişim ve organizasyon etkenlerinin farkında olması gerekebilir. Bu, her geri almanın erişim stratejisine ve organizasyona göre ayarlanması gereken devasa bir dosya için söz konusu olabilir; başka herhangi bir çalışma modu kabul edilemez maliyetlere ya da yanıt sürelerine yol açar.

Bununla birlikte, uygulama programları ile veri organizasyonu ya da erişim stratejisi arasındaki bağımlılık genel olarak iyi bir politika değildir. Geniş ölçüde paylaşılan bir veritabanında, veritabanının yeniden düzenlenmesi, erişim yazılımındaki değişiklikler ya da hatta depolama ortamındaki değişiklikler durumunda çok büyük maliyetler anlamına gelebilir. Böyle bir değişiklik, ağ boyunca dağıtılmış yüzlerce uygulama programında yeniden programlama gerektirebilir.

Sonuç olarak, aşağıdakileri içeren bir çalışma modları yelpazesini destekleyen bir dile ihtiyaç duyduğumuzu görüyoruz:

1. Uygulama programı, depolama yapısından, erişim tekniğinden ve yeniden organizasyon stratejisinden tamamen bağımsızdır.
2. Uygulama programı bunları parametrik olarak denetler.
3. Uygulama programı bunları tamamen denetler.

Geniş ölçüde paylaşılan bir veritabanı için, aşağıdaki durumlar dışında tercih edilen politika mod (1) olacaktır:

• Uygulama programcısının, karar verme konusunda sistemden daha iyi bir iş çıkarabilmesi ve
• Bu ek verimlilik gereksiniminin, program-veri bağımsızlığının sağladığı yararlardan daha ağır basması.

Bu soruyu belirli bir uygulama için değerlendirirken, küresel verimlilik analizinin rolünü anlamak önemlidir. Bir veritabanının çok sayıda kullanıcısı olduğunda, bir anlamda en iyi çalışma modu, tüm isteklerin işlenmesinin toplam maliyetini ve verinin depolanmasının toplam maliyetini en aza indiren moddur. Gerçek dünya gereksinimleri değiştikçe uygulamalar gelip gittiğinde, merkezi denetimin avantajları, belirli bir uygulama programı için yapılan optimizasyonun avantajlarından daha ağır basma eğilimindedir.

Üçüncü ana alt problem, öğe düzeyindeki temsillerle bağlantılı olarak ortaya çıkar. Yürütüldüğü ortam nedeniyle, her uygulama programının tercih ettiği bir biçimlendirme kavramları kümesi, uzunluk göstergeleri, doldurma ve hizalama kuralları, sözcük boyutları, karakter temsilleri vb. vardır. Bir kez daha, uygulama programının yalnızca istediği temsillerle ilgilenmesi ve depolanan veri temsiliyle ilgilenmemesi daha iyi bir politikadır. Ancak, belirli bir istek için verimliliğin diğer tüm etkenleri geride bıraktığı durumlar olacaktır.

Bu temsil düzeyinde en az bir ek değerlendirme daha vardır: dönüşüm gerçekleştiğinde olası bilgi kaybı. Bir tür dönüşümünü kim başlatırsa başlatsın (ve bu bazen databilgisayar, bazen de uygulama programı olacaktır), isteğin amacının korunduğunu sağlama sorumluluğunu da üstlenmelidir. Databilgisayar, paylaşılan bir veritabanının tutarlılığı ve anlamından her zaman sorumlu olmak zorunda olduğundan, burada çözülmesi gereken bazı çakışmalar vardır.

Özetlemek gerekirse, veritabanlarının geniş ölçüde paylaşılmasının sonucu, belirli bir veritabanı için veri yönetim politikasını seçerken daha büyük bir sistemin dikkate alınması gerektiğidir. Databilgisayar durumunda bu daha büyük sistem; coğrafi olarak dağıtılmış uygulama programlarından oluşan bir ağ, merkezi bir veritabanı ve merkezi bir veri yönetim sisteminden oluşur. Veri dili için gereksinim, bu daha büyük sistemin yönetiminde esneklik sağlamaktır. Özellikle, dönüşümlerin, veri yeniden organizasyonlarının ve erişim stratejilerinin ne zaman ve nerede yapılacağının denetlenebilmesi gerekir.

2.6 Yüksek Düzeyli İletişim Gereksinimi

Yukarıdaki tüm değerlendirmeler, databilgisayar ile kullanıcıları arasında yüksek düzeyli iletişime duyulan gereksinime işaret etmektedir. Databilgisayar donanımının karmaşık ve ayırt edici doğası, isteklerin, kullanılacak erişim stratejilerine ilişkin temel kararları verebilmesi için databilgisayara iletilmesini zorunlu kılar. Aynı zamanda, depolanan büyük veri miktarları ve bazı kullanıcıların son derece yüksek iletim bant genişliklerine yönelik talepleri, bazı depolama ve iletim şemalarının kullanıcı denetimine bırakılmasını gerekli kılar. Veritabanlarının, aynı verinin farklı görünümlerini isteyen ve farklı kısıtlamalara sahip uygulamalar tarafından kullanılacak olması, databilgisayarın bir kullanıcının isteğini başka bir kullanıcının verisine eşleyebilmesini gerektirir. Databilgisayarın süreçler arası kullanımı, insan müdahalesine gerek kalmaması için veri paylaşımının tamamen denetlenebilir olmasını gerektirir. Veri bütünlüğünü sağlamak ve erişimi denetlemek için kapsamlı olanaklar sunulmalıdır.

2.6.1 Veri Tanımı

Tüm bu gereksinimlerin temelinde, datacomputer’da saklanan verilerin hem işlevsel hem de fiziksel parametreler açısından tamamen tanımlanmış olması gerekliliği yer alır. Verilerin üst düzey bir tanımı, özellikle verilerin paylaşımını ve denetimini sağlamak açısından son derece önemlidir. Datacomputer, farklı donanımlar ile farklı uygulamalar arasında eşleme yapabilmelidir. Bunun en basit biçimi, farklı makinelerdeki kayan nokta sayı gösterimleri arasında dönüşüm yapabilme anlamına gelir. Diğer uçta ise, aynı hava durumu veritabanına yönelik olarak hem ILLIAC IV için matris verileri sağlayabilmesi hem de doğal dil kullanan bir programdan gelen sorgulara yanıt verebilmesi anlamına gelir. Veri tanımları, bit düzeyindeki gösterimlerin yanı sıra verilerin mantıksal özelliklerini ve aralarındaki ilişkileri belirtme yeteneğini sağlamalıdır.

2.6.2 Veri Bütünlüğü ve Erişim Denetimi

Tanımlamakta olduğumuz ortamda, veri bütünlüğünü koruma ve veri kullanımını denetleme sorunları son derece büyük önem kazanır. Datacomputer dosyalarının paylaşımlı kullanımı, datacomputer’ın veri erişimine ilişkin kısıtlamaların kesin bir biçimde uygulandığını garanti edebilme yeteneğine bağlıdır. Farklı kullanıcıların farklı tanımlara sahip olacağı göz önüne alındığında, erişim denetim mekanizmasının doğrudan tanımların kendileriyle ilişkilendirilmesi gerekir. Veriye erişim, onun çeşitli tanımlayıcılarına erişim denetlenerek kontrol edilebilir. Bir kullanıcı, belirli bir veritabanına yalnızca, erişebileceği verileri sınırlayan tek bir özel tanım aracılığıyla erişecek şekilde kısıtlanabilir. Bir veritabanını güncelleyenlerin birbirlerini tanımadığı ve hatta veriye ilişkin farklı bakış açılarına sahip olabildiği bir sistemde, veri bütünlüğünü yalnızca datacomputer güvence altına alabilir. Bu nedenle, veri nesnelerinin alabileceği olası değerler ile nesneler arasındaki olası ya da gerekli ilişkiler üzerindeki tüm kısıtlamalar veri tanımında belirtilmelidir.

2.6.3 Optimizasyon

Veri erişim stratejisine ilişkin kararlar normalde, fiziksel hususlara dair bilginin bulunduğu yer olan datacomputer’da verilmelidir. Veri erişim istekleri üst düzeyde ifade edilmedikçe bu kararların akıllıca alınması mümkün değildir.

Örneğin, aşağıdaki iki durumu karşılaştıralım:

1. Bir istek, Kaliforniya’da yapılmış ve belirli rüzgâr ile basınç koşullarını gösteren tüm hava durumu gözlemlerinin çıktısını talep eder.
2. Bir dizi istek gönderilir; her biri Kaliforniya hava durumu gözlemlerini getirir; bir istek gerekli rüzgâr ve basınç koşullarına sahip bir gözlem bulduğunda, bu gözlemi uzak bir sisteme iletir.

Her iki oturum da aynı sonucu elde eder: belirli bir gözlem kümesinin işlenmek üzere uzak bir siteye iletilmesi. Ancak birinci oturumda datacomputer, en baştan itibaren ihtiyaç duyulan verilerin bir tanımını alır; ikinci durumda ise her biri sürpriz olan bir dizi isteği işler.

Birinci durumda, akıllı bir datacomputer gerekli tüm verileri kütlesel depolama aygıtına tek bir erişimde alma seçeneğine sahiptir. Daha sonra bu verileri, kullanıcı kabul etmeye hazır olana kadar disk üzerinde tamponlayabilir. İkinci durumda ise datacomputer, böyle bir optimizasyonu yapabilmek için ihtiyaç duyduğu bilgiden yoksundur.

Dil, optimizasyonun yapılabilmesi için gerekli bilgileri sağlamaları konusunda kullanıcıları mümkün kılmalı ve teşvik etmelidir. Bunun yapılmamasının maliyeti, kütlesel depolama aygıtları ve büyük dosyalar söz konusu olduğunda, geleneksel sistemlere kıyasla çok daha yüksektir.

2.7 Uygulama Odaklı Kaygılar

Yukarıdaki bölümlerde, datacomputer sisteminin sağlaması gereken bir dizi özelliği tanımladık. Bu bölümde, bu özelliklerin datacomputer kullanıcıları için kolayca erişilebilir olmasını sağlamak açısından gerekli olanlara odaklanıyoruz.

2.7.1 Datacomputer–Kullanıcı Etkileşimi

Bir uygulama, datacomputer ile bir oturum içinde etkileşime girer. Bir oturum, bir dizi isteğin bütünüdür. Her oturum, ağ üzerinden datacomputer’a bağlanmayı, kimliklerin kurulmasını ve hem veri hem de datalanguage için iletim yollarının ayarlanmasını içerir. Datalanguage, datalanguage bağlantısı üzerinden karakter modunda (ağ standart ASCII kullanılarak) iletilir. Hata ve durum iletileri bu bağlantı üzerinden uygulama programına gönderilir.

Veri bağlantısı (PORT olarak adlandırılır) bir bit akışı olarak görülür ve kendine özgü bir tanım verilir. Bu tanımlar, saklanan veriler için verilen tanımlara benzer. En azından bu tanım, datacomputer’ın gelen bit akışını ayrıştırabilmesi için yeterli bilgiyi içermelidir. Ayrıca veri doğrulama bilgilerini de içerebilir. Veriyi datacomputer’da saklayabilmek için, saklanan verinin de bir tanımı olmalıdır. Kullanıcı, saklanan ve iletilen verilerin tanımları arasındaki eşlemeyi sağlar.

Şekil 2-1. Datacomputer/Kullanıcı Etkileşimi Modeli

 _____________________________________
|                                     |        / /
|  ______     ___________             |        \ \
| |      |---|           |            |        / /
| |      |   |   DATA    |            |        \ \
| |      |   |DESCRIPTION|   _______  |    DATALANGUAGE     ___________
| |      |   |___________|  |       |<-------------------->|           |
| |STORED|         |________| USER  | |        PATH        |APPLICATION|
| | DATA |__________________|REQUEST| |                    |  PROGRAM  |
| |      |                  |_______|<----!--------------->|___________|
| |      |               ___________  |   !   DATA PATH
| |      |              |           | |   !    / /
| |      |              |   PORT    |-----!    \ \
| |      |              |DESCRIPTION| |        / /
| |______|              |___________| |        \ \
|_____________________________________|        / /
                                             NETWORK

2.7.2 Veri Paylaşımı için Uygulama Özellikleri

Datacomputer’da saklanan veriler kullanılırken, kullanıcılar uygulamaya özgü olarak uyarlanmış bir veri tanımı sağlayabilir. Bu tanım, saklanan verinin tanımı üzerine eşlenir. Bu tanımlar farklı düzeylerde olabilir. Yani, biri yalnızca belirli öğelerin sırasını yeniden düzenlerken, bir diğeri saklanan gösterimin tamamen yeniden yapılandırılmasını isteyebilir. Her kullanıcının bir başkasının tanımları üzerine inşa edebilmesi için, veri varlıklarına adlandırılmış türler verilmelidir. Bu tür tanımları, elbette tanımladıkları verilerle birlikte saklanmalıdır.

Buna ek olarak, bazı işlevler veriye o kadar sıkı bir biçimde bağlıdır ki (hatta sanal tanım durumunda verinin kendisi olabilirler—Bkz. Bölüm 3), bunların da datacomputer’da yer alması ve veri öğeleriyle olan bağlarının datacomputer tarafından korunması gerekir. Örneğin, bir kullanıcı bir veritabanını, enlem ve boylam türlerinde veriler içeren yapılardan oluşmuş olarak tanımlayabilir. Ayrıca bu türdeki verileri karşılaştırmak için işlevler de tanımlayabilir. Enlem bileşeninin yapısıyla ilgilenmeyen, ancak bu bilgiyi yalnızca diğer ilgi alanındaki alanları çıkarmak için kullanmak isteyen diğer kullanıcılar, bu ortak tanım ve işlevlerden yararlanabilir.

Ayrıca, bu strateji benimsenerek mümkün olduğunca çok sayıda kullanıcı, dosyada kendi temel ilgi alanlarına dolaylı olan değişikliklere karşı duyarsız hâle getirilebilir. Örneğin, enlemler ikili gösterimden karakter biçimine dönüştürülebilir ve bu alanın kullanımı kendi tanımları ve ilişkili işlevleriyle sınırlandırılmışsa, mevcut uygulama sistemleri etkilenmez. Dönüşüm işlevleri tanımlanarak hâlihazırda çalışan programlar üzerindeki etki ortadan kaldırılabilir. Bu tür tanımsal olanakların varlığı, kullanıcı gruplarının paylaşılan verilerle çalışmak için ortak işlevler ve tanımlar geliştirebilmesini ve paylaşılan verilerin kullanımına ilişkin kuralların datacomputer tarafından uygulanabilmesini sağlar. Bu olanaklar, Bölüm 3’te genişletilebilirlik başlığı altında ele alınmaktadır.

Şekil 2-2. Datacomputer ile Çoklu Kullanıcı Etkileşimi

 ___________________________________________      _______________
|                             ____________  |    |  ___________  |
|                            |APPLICATION | |    | |APPLICATION| |
|                           _|    DATA    |_|____|_|  PROGRAM  | |
|                          | |DESCRIPTIONS| |    | |___________| |
|                          | |____________| |    |_______________|
|                          |       ^        |          HOST 1
|  ______                  |       |        |
| |      |                 |  _____|______  |
| |      |                 | |    DATA    | |
| |      |                 | | FUNCTIONS  | |
| |      |                 | |____________| |     _______________
| |      |   ___________   |  ____________  |    |  ___________  |
| |      |  |  STORED   |__| |            | |    | |APPLICATION| |
| |      |__|   DATA    |____|            |_|____|_|  PROGRAM  | |
| |STORED|  |DESCRIPTION|__  |            | |    | |___________| |
| | DATA |  |___________|  | |____________| |    |               |
| |      |        ^        |  ____________  |    |  ___________  |
| |      |        |        | |            | |    | |APPLICATION| |
| |      |   _____|_____   | |            |_|____|_|  PROGRAM  | |
| |      |  |   DATA    |  |_|            | |    | |___________| |
| |      |  | FUNCTIONS |    |____________| |    |_______________|
| |______|  |___________|                   |          HOST 2
|___________________________________________|
                DATACOMPUTER

2.7.3 İletişim Modeli

Datalanguage’ın kavramsal olarak üst düzeyde, sözdizimsel olarak ise düşük düzeyde olmasını amaçlıyoruz. Datalanguage, bir dizi ilkel işlev ile yaygın olarak kullanılan daha üst düzey işlevlerden oluşan bir küme sağlar (datalanguage modeli için Bölüm 4’e bakınız). Ayrıca kullanıcılar, datacomputer ile kavramsal olarak uygulamaya mümkün olduğunca yakın bir düzeyde iletişim kurabilmek için kendi işlevlerini tanımlayabilirler.

Datalanguage’ın sözdizimsel olarak düşük düzeyde olmasının iki nedeni vardır. Birincisi, programların karmaşık bir biçimde istekler oluşturup bunların datacomputer tarafından tekrar parçalanmasının istenmemesidir. İkincisi ise, belirli bir üst düzey sözdizimi seçilmesi durumunda datacomputer’ın, çoğu kullanıcınınkilerle örtüşmeyebilecek bir dizi kural ve terminolojiyi dayatacak olmasıdır.

DATACOMPUTER ORTAMI | DIŞ ORTAM

                               _______
                           |       |____
                    |        __|GENERAL|____
                             |  |  DMS  |____
                    |       |  |_______|
 ___________     __________     ___________   |
|           |   |  HIGHER  |   |           |__|   _______     ________
| PRIMITIVE |___|  LEVEL   |___| LOW-LEVEL |_____| COBOL |   |  COBOL  |
| LANGUAGE  |   | LANGUAGE|   |  SYNTAX   |__   | SERVER|___| PROGRAM |
|___________|   |_________|   |___________|  |  |_______|   |________|
                    |       |   _______
                             |__| ON LINE|
                    |          |  QUERY  |_______
                               |_________|       |
                    |                       ___|____
                                           | TERMINAL|
                    |                      |  USERS  |
                                           |_________|
                    |
                             APPLICATION   APPLICATIONS
                    |          SERVERS

Şekil 2-3
Datacomputer/Kullanıcı Çalışma Ortamı

2.8 Özet

Bu bölümde, mevcut datalanguage tasarım çalışmasını etkileyen başlıca hususları sunduk. Datacomputer, çoğu büyük ölçekli paylaşımlı veri yönetim sistemiyle birçok ortak özelliğe sahiptir; ancak datacomputer kavramına özgü bir dizi baskın kaygıyı da barındırır. Bunların en önemlileri, hem donanım hem de yazılım içeren ayrı bir kutunun varlığı, son derece büyük bir depolama aygıtının denetimi ve bir bilgisayar ağı ortamına gömülü olmasıdır. Böyle bir ortamda veri paylaşımı, tasarımın merkezî bir kaygısıdır. Veri bütünlüğü ve kullanıcı isteklerinin datacomputer tarafından optimize edilebilmesi için hem kapsamlı veri tanımlama olanakları hem de kullanıcı ile datacomputer arasında üst düzey iletişim gereklidir.

Buna ek olarak, datacomputer’ın öngörülen kullanımı, farklı çalışma kipleri için birbiriyle çelişen çeşitli kısıtlamaların karşılanmasını içerir. Çeşitli kullanıcı gereksinimlerini karşılamanın bir yolu, kullanıcıların datalanguage içinde kendi uygulama paketlerini geliştirebilmelerine olanak tanıyan datalanguage özelliklerini sağlamaktır.

3. Temel Dil Kavramları

Bu bölüm, datalanguage’ın temel olanaklarını ele almaktadır. Dilin ayrıntılı özellikleri sunulmamaktadır; ancak tartışma, çeşitli dil özelliklerinin dâhil edilmesinin arkasındaki gerekçeleri kapsamakta ve ayrıca kullandığımız terimleri gayriresmî bir biçimde tanımlamaktadır.

3.1 Temel Veri Öğeleri

Temel veriler, tüm veri yapılarının atomik düzeyidir; daha küçük parçalara ayrılamazlar. Daha üst düzeydeki tüm veri yapıları temelde temel veri öğelerinden oluşur. Birçok türde temel veri öğesi sağlanacaktır. Bir öğenin türü, o öğe üzerinde hangi işlemlerin yapılabileceğini ve bu işlemlerin anlamını belirler. Datalanguage, gerçek dünyayı modellemek için bilgi işlem sistemlerinde yaygın olarak kullanılan bu ilkel veri türlerini sağlayacaktır.

Datalanguage’da aşağıdaki temel veri türleri bulunacaktır: sabit nokta sayılar, kayan nokta sayılar, karakterler, boole’lar ve bitler. Bu türdeki öğeler, işlemlerin bir öğenin türüne dayalı olması anlamında datacomputer sistemi tarafından “anlaşılır”. Datalanguage ayrıca, yalnızca bir yerden başka bir yere taşınacak (iletim dâhil) veriler için yorumlanmamış bir öğe türü de içerecektir. Bu veri türü, yalnızca datacomputer’ın yorumlanmamış türdeki iki öğenin özdeş olup olmadığını belirleyebilmesi gibi en basit anlamda anlaşılacaktır.

Temel öğe türleri üzerinde standart işlemler mevcut olacaktır. Datacomputer kullanıcısının geniş bir veri yönetimi işlevleri yelpazesini tanımlayabilmesi için işlemler sağlanacaktır. Bunlar, datacomputer’ın yoğun hesaplama gerektiren problemleri çözmek amacıyla kullanılmasını teşvik etmek niyetiyle dâhil edilmemiştir.

3.2 Veri Toplulukları

Veri toplulukları, temel veri öğelerinin ve olası olarak diğer veri topluluklarının bileşimleridir. Sağlanan veri topluluğu türleri, veriler arasında hiyerarşik ilişkilerin kurulmasına olanak tanır. Kesin olarak mevcut olacak topluluklar structs, arrays, strings, lists ve directories olarak sınıflandırılır.

Bir struct, veri öğelerinin (bileşenler olarak adlandırılır) statik bir bütünüdür. Bir struct, bileşenlerinin struct’a eklenememesi veya struct’tan silinememesi anlamında statiktir; bileşenler struct’a ayrılmaz biçimde bağlıdır. Struct’ın her bir bileşeniyle, o bileşenin struct’a göreli olarak başvurulmasını sağlayan bir ad ilişkilidir. Struct bütünü, sıklıkla bir kayıt olarak düşünülen şeyi modellemek için kullanılabilir; bu durumda her bileşen, o kaydın bir alanıdır. Bir struct ayrıca, kavramsal olarak diğer bileşenlere göre daha güçlü biçimde ilişkili olan ve birlikte üzerinde işlem yapılabilen bir kaydın bileşenlerini gruplamak için de kullanılabilir.

Diziler (Arrays) veri yapılarında tekrar olanağı sağlar. Bir dizi, bir struct gibi, veri öğelerinin (üyeler olarak adlandırılır) statik bir bütünüdür. Bir dizinin her üyesi aynı türdedir. Her bir üyeyle, o üyenin diziye göreli olarak başvurulmasını sağlayan bir indeks ilişkilidir. Diziler, bir kayıttaki tekrar eden verileri (tekrar eden gruplar) modellemek için kullanılabilir.

Dize (string) kavramı aslında temel veri ile veri bütünlerinin bir melezi niteliğindedir. Dizeler, daha ilkel verilerin (örneğin karakterler) bileşimleri (dizilere benzer şekilde) olmaları bakımından bütünlerdir. Bununla birlikte, genellikle her bir öğenin ayrı ayrı önem taşıdığı bir öğeler kümesi olarak değil, tek bir birim olarak görülmeleri nedeniyle temel veri gibi düşünülürler. Ayrıca, bir dizenin anlamı, tek tek bileşenlerin sırasına büyük ölçüde bağlıdır.

Daha somut olarak ifade etmek gerekirse, belirli dize türleri üzerinde tanımlanmış işlemler vardır. Örneğin, mantıksal operatörler (and, or vb.) bit dizeleri üzerinde işlem yapmak üzere tanımlanmıştır. Ancak, bit dizileri üzerinde tanımlanmış işlemler olmasına rağmen, bit dizilerinden oluşan diziler üzerinde tanımlanmış işlemler yoktur; oysa genel olarak diziler üzerinde ve bitler üzerinde tanımlı işlemler vardır. Karakter, bit ve yorumlanmamış veri dizeleri datalanguage içinde kullanılabilir olacaktır.

Listeler (Lists), benzer üyelerden oluşan koleksiyonlar olmaları bakımından dizilere benzer. Ancak listeler statik değil, dinamiktir. Bir listenin üyeleri listeye eklenebilir ve listeden silinebilir. Bir listenin üyeleri sıralı olmakla birlikte (hatta bir liste üzerinde birden fazla sıralama tanımlanabilir), liste, bir dizide olduğu gibi bir indeks aracılığıyla başvurulmak üzere tasarlanmamıştır. Bir listenin üyelerine, liste boyunca bir sıralama yöntemiyle ilerleme yoluyla başvurulabilir. Bir liste üyesine ya da bir üye kümesine (sanal veri altındaki tartışmaya bakınız), içerik temelli bir tanımlama yöntemiyle de başvurulabilir.

Liste yapısı, yaygın dosya kavramını modellemek için kullanılabilir. Ayrıca, struct’ların bileşeni olarak listelerin kısıtlı kullanımı, dosya seviyesinin altında dinamik hiyerarşik veri ilişkilerinin kurulması açısından güçlü olanaklar sağlar. Örneğin, bir listenin üyeleri kendileri de kısmen listelerden oluşabilir; her ailenin çocuklardan oluşan bir liste ve başka bilgiler içerdiği aileler listesi örneğinde olduğu gibi.

Dizinler (Directories), her tür veri öğesini içerebilen dinamik veri bütünleridir. Bir dizin içinde bulunan veri öğelerine düğüm (node) adı verilir. Bir dizinin her bir düğümüyle, o veri öğesine dizine göreli olarak başvurulmasını sağlayan bir ad ilişkilidir. Listelerde olduğu gibi, öğeler bir dizine dinamik olarak eklenebilir ve dizinden silinebilir. Dizin yeteneğinin sağlanmasının temel motivasyonu, kullanıcının kavramsal olarak ilişkili verileri bir arada gruplamasına olanak tanımaktır.

Dizinlerin yalnızca dosya türü bilgileri içermesi gerekmediğinden, "yardımcı" veriler de dizinin bir parçası olarak saklanabilir. Örneğin, bir kurum veritabanı için maaş aralığı tabloları gibi sabit bilgiler ya da kullanıcı tanımlı işlemler ve veri türleri (aşağıya bakınız), bu bilgileri kullanabilecek verilerle birlikte bir dizin içinde tutulabilir. Ayrıca, dizinler kendileri de bir dizinin parçası olabilir; bu da veri gruplamasında bir hiyerarşiye olanak sağlar.

Dizinler, sistem tarafından denetlenen bilgilerin bazı alt öğelerle birlikte tutulabilmesine olanak verecek şekilde de tanımlanacaktır (örneğin, oluşturulma zamanı, güncelleme zamanı, gizlilik kilitleri vb.). Ayrıca, veri kullanıcısının kendi bilgilerini tanımlamasına ve bu bilgilerin veriyle birlikte tutulmasını denetlemesine izin verilmesi de mümkün olabilir. En azından, datalanguage tasarımı, sistem tarafından yönetilen bilgiler üzerinde parametrik denetime olanak tanıyacaktır.

Dizinler, en genel ve en dinamik veri bütünleri türüdür. Dizin düğümlerinin hem adı hem de açıklaması (aşağıya bakınız), dizinin tanımının bir parçası olmak yerine düğümlerin kendileriyle birlikte bulunur. Ayrıca, dizinlerin iç içe geçme düzeyi dinamiktir; çünkü dizinler dinamik olarak diğer dizinlere eklenebilir. Bu özellik yalnızca dizinler için geçerlidir.

Datalanguage, yukarıda açıklanan veri bütünlerinin bazı özel ve kullanışlı varyasyonlarını da sağlayacaktır. İsteğe bağlı bileşenlere izin veren struct’lar sunulacaktır. Bu durumda bir bileşenin varlığı, diğer bileşenlerin içeriğine bağlı olacaktır. Ayrıca, varlığın veri hiyerarşisinin daha üst bir düzeyinde bulunan bilgilere dayandırılmasına da olanak tanınabilir.

Benzer şekilde, türü çözümlenmemiş bileşenler sağlanacaktır. Yani, bileşen sabit sayıda olası türden biri olabilir. Bileşenin türü, struct’ın diğer bileşenlerinin içeriğine dayanacaktır. Ayrıca, bir bileşenin türünün ya da varlığının, diğer bileşenlerin içeriği dışındaki bilgilere dayanmasına da izin verilmesi arzu edilir. Örneğin, bir bileşenin türü başka bir bileşenin türüne bağlı olabilir. Genel olarak, datalanguage’ın bir öğenin niteliklerinin (aşağıya bakınız) diğer öğelerin niteliklerinin bir fonksiyonu olmasına izin vermesini isteriz.

Ayrıca, karma listeler sağlamayı da isteriz. Karma listeler, birden fazla türde üye içeren listelerdir. Bu durumda üyelerin kendi kendini tanımlayıcı olması gerekir. Yani, tüm üyelerin türleri, o üyenin türünü tanımlayan bilginin bulunabileceği ölçüde benzer olmalıdır.

Türü çözümlenmemiş bileşenlere benzer şekilde, uzunluğu çözümlenmemiş diziler de vardır. Bu durumda, dizinin uzunluğunu tanımlayan bilginin, dizinin kendisiyle ya da diziyi kapsayan bir bütünün diğer bileşenleriyle birlikte taşınması gerekir.

Yukarıdaki tüm durumlarda, bir öğenin türü belli bir dereceye kadar çözümlenmemiştir ve türü tamamen çözen bilgi öğeyle birlikte taşınır. Bu durumların bazılarında ya da belki de tümünde, datacomputer sisteminin bu bilginin bakımından sorumlu olması ve böylece veri kullanıcısı için görünmez kılması mümkündür.

3.3 Genel İlişkisel Yetenekler

Yukarıda tanımlanan veri bütünleri, veriler arasındaki çeşitli ilişkilerin modellenmesine olanak tanır. Kurulabilen tüm ilişkiler hiyerarşiktir.

Hiyerarşik olmayan ilişkileri modelleme yeteneğini sağlamak için iki yaklaşım benimsenebilir. Datalanguage içinde ifade edilebilen veri ilişkilerinin kapsamını genişletecek yeni veri bütünleri türleri tanıtılabilir. Ya da, ilişkilerin temsil edilebileceği bir ilkel olarak hizmet edecek temel bir veri türü olan işaretçi (pointer) tanıtılabilir.

Bir işaretçi, bir öğeden başka bir öğeye bir tür karşılık kuran bir veri türü olacaktır. Yani, bir öğe verildiğinde başka bir öğeyi bulma yöntemidir. İşaretçi türünde öğelere sahip olma yeteneğinin sağlanması, adres kavramının tanıtılmasını gerektirmez; bunu tehlikeli bir adım olarak değerlendiriyoruz. Örneğin, bir personel dosyasındaki bir kaydı işaret edecek şekilde tanımlanan bir öğe, dosyadaki her kayıtta bulunan ve o kaydı benzersiz biçimde tanımlayan bir sosyal güvenlik numarası içerebilir. Genel olarak, bir işaretçi, başka bir öğeyi benzersiz biçimde tanımlamak için kullanılabilen bir bilgi öğesidir.

İşaretçi yaklaşımı daha yüksek derecede esneklik sağlasa da, bunu kullanıcıya daha fazla iş yükü yükleyerek ve datacomputer sisteminin veri üzerindeki denetimini ciddi biçimde sınırlayarak yapar. Melez bir çözüm mümkündür; bu çözümde bazı yeni bütün veri türleri sağlanırken, kısıtlı bir işaretçi veri türü de sunulur. Benimsenecek yaklaşım hâlen incelenmekle birlikte, datalanguage tasarımı hiyerarşik olmayan veri yapılarının ifade edilmesi için bir yöntem içerecektir.

3.4 Verinin Sıralanması

Listeler genellikle sıralı olarak görülür. Ancak, bir listenin sıralı olarak algılanmayan benzer öğelerin dinamik bir koleksiyonunu modellemek için kullanılması da mümkündür. Sırasız durum önemlidir; çünkü bu bilgi verildiğinde, datacomputer yeni üyeleri uygun olan herhangi bir yere ekleyebileceğinden daha verimli olabilir.

Bir listenin sıralanmasının birçok yolu vardır. Örneğin, bir listenin sıralaması üyelerinin içeriğine dayalı olabilir.

En basit durum, temel bir veri öğesinin içeriğini içerir. Örneğin, bir şirketin çalışanlarına ilişkin bilgiler içeren struct’lardan oluşan bir liste, çalışanın sosyal güvenlik numarasını içeren bileşene göre sıralanabilir. Daha karmaşık sıralama ölçütleri de mümkündür. Örneğin, aynı liste çalışanın soyadına göre alfabetik olarak sıralanabilir. Bu durumda sıralama ilişkisi, soyadı ve adı olmak üzere iki öğenin bir fonksiyonudur.

Kullanıcı, temel veri öğelerine dayanan sıralamalar için bile kendi sıralama düzenini tanımlamak isteyebilir. Bir sıralama, yardımcı verileri (yani liste dışındaki verileri) bile kullanabilecek şekilde, bir çalışanın iş unvanına dayanabilir. Ayrıca, bir listenin eklenme sırasına göre tutulması da mümkündür. En genel durumda, kullanıcı ekleme isteklerinin bir parçası olarak bir öğenin nereye yerleştirileceğini belirterek sıralamayı dinamik olarak tanımlayabilir. Yukarıdaki tüm durumlarda, veriler artan ya da azalan sırada tutulabilir.

Bir listenin belirli bir sırada tutulmasına ek olarak, bir liste üzerine dayatılmış bir ya da daha fazla sıralama tanımlamak da mümkündür. Bu sıralamalar, listenin üyelerinin içeriğine dayanmalıdır. Bu durum, listenin fiziksel olarak belirli bir sırada tutulmaması, ancak öyleymiş gibi getirilmesi bakımından sanal veri kavramına (aşağıya bakınız) benzer. Bu tür sıralamalar dinamik olarak oluşturulabilir (sanal veri altında küme tartışmasına bakınız). Dayatılmış sıralamalar, yardımcı yapıların bakımı yoluyla (iç temsil altındaki tartışmaya bakınız) ya da getirme sırasında bir sıralama stratejisinin kullanılmasıyla gerçekleştirilebilir.

Listeler üzerinde sıralamaların sürdürülmesi ve dayatılmasının etkin biçimde uygulanması konusunda çok sayıda çalışma yapılmıştır. Bu çalışmalar, 2 numaralı çalışma belgesinde açıklanmaktadır.

3.5 Veri Bütünlüğü

Herhangi bir veri yönetim sisteminin önemli bir özelliği, sistemin verinin bütünlüğünü güvence altına alabilme yeteneğidir. Veri, insanlar tarafından yapılan hatalı işlemlere ve sistem arızalarına karşı korunmalıdır.

Datalanguage otomatik geçerlilik denetimleri sağlayacaktır. Uygun güvence derecesi ile doğrulama maliyeti arasında gerekli ödünleşimlerin yapılabilmesi için birçok farklı seçenek sunulmalıdır. Datalanguage kullanıcısı aşağıdakileri talep edebilecektir:

• Sürekli doğrulama: veri her güncellendiğinde geçerlilik denetimleri yapılır.
• Erişim sırasında doğrulama: veri başvurulduğunda, ancak getirilmeden önce geçerlilik denetimleri yapılır.
• Düzenli aralıklarla doğrulama: veri düzenli zaman aralıklarında denetlenir.
• Arka plan doğrulaması: sistem boş zamanlarında denetimleri çalıştırır.
• İstek üzerine doğrulama.

Sürekli doğrulama ve erişim sırasında doğrulama, aslında olay tetiklemeli doğrulama kavramının özel durumlarıdır. Bu durumda kullanıcı, veri doğrulama yordamlarının çağrılmasına neden olacak bir olayı belirtir. Bu özellik, örneğin bir güncellemeler "paketi" sonrasında doğrulama yapılması gibi durumları gerçekleştirmek için kullanılabilir. Ayrıca, bu türlerin kombinasyonlarının belirtilmesi için bir mekanizma da yararlı olacaktır.

Bazı veri doğrulama tekniklerinin etkili olabilmesi için, veriyle birlikte bazı doğrulama "kayıt" bilgilerinin tutulması gerekebilir. Örneğin, bir öğenin en son güncellendiğinden beri denetlenip denetlenmediğini belirlemek için kullanılabilecek bilgiler, yakın zamanda bir arka plan doğrulaması yapılmamışsa erişim sırasında doğrulamayı tetiklemek için kullanılabilir. Datacomputer, bu tür özel bilgilerin isteğe bağlı olarak otomatik bakımını sağlayabilir.

Datacomputer sisteminin veri geçerliliğini güvence altına alabilmesi için, kullanıcının geçerli olanın ne olduğunu tanımlaması gerekir. İki tür doğrulama talep edilebilir. İlk durumda, kullanıcı datacomputer’a belirli bir veri öğesinin yalnızca belirli bir değer kümesinden birini alabileceğini söyleyebilir. Örneğin, bir struct’ın renk bileşeni yalnızca 'red', 'green' ya da 'blue' değerlerini alabilir.

Diğer durumda ise, bir bütünün üyeleri arasında belirli bir ilişkinin sağlanması gerekir. Örneğin, bir struct’ın cinsiyet bileşeni 'male' ise, gebelik sayısı bileşeni 0 olmalıdır.

Veri doğrulama, veri bütünlüğü resminin yalnızca yarısıdır. Veri bütünlüğü, hasar görmüş verinin geri yüklenmesi yöntemlerini de kapsar. Bu da yedek bilgilerin tutulmasını gerektirir. Datacomputer sistemini yedek verilerin bakımından ve hatta olası otomatik geri yüklemeden sorumlu kılacak özellikler sağlanacaktır. Bölüm 2’de, dosya yedekleme için datacomputer’ın olası kullanımlarını tartıştık. Bu amaçla sağlanan tüm özellikler, datacomputer’da bulunan dosyaların geri yüklenmesi için yedek bilgilerin tutulması yöntemleri olarak da kullanılabilir olacaktır.

3.6 Gizlilik

Datalanguage, kapsamlı gizlilik ve koruma yetenekleri sağlamak zorunda olacaktır. En basit biçimiyle, dosya düzeyinde bir gizlilik kilidi sağlanır. Bu kilit bir parola anahtarı ile açılır. Bu anahtarla, bir ayrıcalıklar kümesi (okuma, güncelleme vb.) ilişkilidir.

İki düzeyde genellik hedeflenmektedir. Gizlilik, verinin tüm düzeylerinde kullanılabilir olmalıdır. Bu nedenle, dosya grupları da dâhil olmak üzere ilişkili veri grupları, özel dizinler oluşturularak gizli hâle getirilebilir. Ayrıca, kayıtların belirli alanları, bir struct’ın diğer bileşenleri daha geniş (ya da farklı) bir kullanıcı sınıfına görünürken, struct’ın özel bileşenleri olarak gizli hâle getirilebilir.

Ayrıca, kullanıcının kendi mekanizmasını tanımlayabilmesini de isteriz. Bu sayede, son derece kişiselleştirilmiş, karmaşık ve dolayısıyla güvenli mekanizmalar tanımlanabilir. Ayrıca, "herkes kendi maaşını görebilir" gibi özellikler de mümkün olabilir.

3.7 Dönüştürme

Birçok veri türü, bir türün olası değerlerinin bir kısmının ya da tamamının başka bir türün değerlerine "açık" bir karşılığı olması bakımından ilişkilidir. Örneğin, '6' karakterinin tamsayı 6’ya doğal bir dönüşümü vardır ya da altı karakterli 'abc ' dizesinin (sonunda üç boşluk) dört karakterli 'abc ' dizesine (sonunda bir boşluk) doğal bir dönüşümü vardır.

Datalanguage, standart ve yaygın olarak talep edilen çeviriler için dönüştürme yetenekleri sağlayacaktır. Bu dönüştürmeler kullanıcı tarafından açıkça çağrılabilir ya da bir işlem için bir türde veri gerektiğinde ancak başka bir türde veri sağlandığında örtük olarak çağrılabilir. Verinin dönüştürülmesinin örtük olarak çağrılması durumunda, kullanıcı belirli bir veri öğesi için dönüştürmenin gerçekleşip gerçekleşmeyeceği üzerinde denetime sahip olacaktır.

Daha genel olarak, kullanıcının bir öğenin ne zaman dönüştürüleceğini belirleyen koşulları tanımlayabilmesini sağlayan bir olanak sunmak istiyoruz. Ayrıca, kullanıcı, datacomputer sistemi tarafından sağlanmayan türler arası bir dönüştürme için ya da belirli bir türdeki bazı veya tüm öğeler için standart dönüştürme işlemini geçersiz kılmak amacıyla, kendi dönüştürme işlemlerini tanımlayabilmelidir.

3.8 Sanal ve Türetilmiş Veri

Çoğu zaman, veri kullanıcıları için önemli olan bilgiler, açıkça tutulmak yerine verinin içine gömülüdür. Örneğin, hissedarlar dosyasında bir bireyin bir şirketteki payının dolar değeri. Şirketin değeri sık sık değiştiğinden, bu bilginin her kayıtla birlikte tutulması uygulanabilir değildir. Dosyayı, bu tür bilgilerin her kaydın bir parçasıymış gibi kullanabilmek yararlıdır.

Bir kaydın dolar değeri alanına başvurulduğunda, datacomputer sistemi, şirket içindeki sahiplik yüzdesi gibi kayıtta bulunan bilgileri ve muhtemelen kaydın parçası olmayan ancak başka bir yerde tutulan şirket varlıkları gibi bilgileri birlikte kullanarak dolar değerini otomatik olarak hesaplayacaktır. Bu şekilde, veri kullanıcısının bu bilginin gerçekte kayıtta tutulmadığı gerçeğiyle ilgilenmesine gerek kalmaz.

Datalanguage içindeki belirli bir sanal kapsayıcı türü olan küme (set) özel olarak anılmayı hak eder. Bir küme, sanal bir listedir. Örneğin, belirli bir nüfus örneğini temsil eden gerçek bir insan listesi olduğunu varsayalım. Gerçek (ya da fiilî) veri ile, datacomputer üzerinde fiziksel olarak saklanan veriyi kastediyoruz. Bir küme, bu listedeki otomobil sahibi olan tüm üyeleri içerecek şekilde tanımlanabilir.

Küme kavramı, verinin fiziksel çoğaltma olmaksızın birden fazla koleksiyona aitmiş gibi görülmesini sağlayan güçlü bir özellik sunar. Kümeler ayrıca dinamik olarak oluşturulabilmeleri açısından da yararlıdır. Gerçek bir liste verildiğinde, bu listeye dayalı kümeler, önceden tanımlanmış olmaksızın meydana getirilebilir.

Yukarıda belirtildiği gibi, sanal veri son derece ekonomik olabilir. Bu tasarruflar, özellikle kümelerin kullanımı açısından en önemli hale gelebilir. Tasarruflar yalnızca depolama gereksinimleriyle sınırlı değildir; işlem verimliliği açısından da ortaya çıkar. Veriye yalnızca erişildiğinde hesaplamaların yapılması sonucunda işlem süresi azaltılabilir.

Sanal verinin başka sanal veriler cinsinden tanımlanması durumunda, eniyileme yoluyla verimli çalışma elde etme yeteneği daha da artar. Kümeler için, iç içe geçmiş hesaplamaların basit bir şekilde eniyilenmesiyle büyük tasarruflar sağlanabilir.

Yukarıdaki fikirler bir örnekle daha açık hale gelir. Otomobil sahiplerinden oluşan A kümesi oluşturulduktan sonra, A temel alınarak ev sahiplerinden oluşan HA kümesi tanımlanabilir. HA üyeleri, hem otomobil sahibi hem de ev sahibi olan kişilerin tek bir adımda geri getirilmesiyle çok verimli bir şekilde elde edilebilir. Bu yöntem, önce A kümesini fiilen üretip ardından bunu kullanarak HA kümesini oluşturmaktan daha etkilidir. Bu durum, bilgi parçalarından birinin ya da her ikisinin (otomobil sahipliği ve ev sahipliği) indekslenmiş olduğu durumlarda da (bkz. iç temsil altındaki tartışma) ve hiçbirinin indekslenmediği durumlarda da geçerlidir.

Sanal veri üzerinde işlemler talep edildiğinde de aynı kazanımlar elde edilir. Örneğin, H kümesi özgün insan listesine dayalı olarak ev sahipleri kümesi şeklinde tanımlanmış olsaydı, HA kümesi A ve H kümelerinin kesişimi (bkz. işleçler hakkındaki tartışma) olarak tanımlanabilirdi. Bu durumda da HA tek bir adımda hesaplanabilir. Kümelerin kullanımı, kullanıcının veri işlemlerini kendi kavramsal görüşüne yakın bir biçimde talep etmesine olanak tanır ve bu talebin etkin biçimde işlenmesi sorununu datacomputer’a bırakır.

Sanal verinin bir başka kullanımı veri paylaşımını gerçekleştirmektir. Bir öğe, sanal olarak, başka bir öğenin içeriği şeklinde tanımlanabilir. Bu öğenin ne olabileceğine herhangi bir kısıtlama getirilmezse, aynı veriye iki erişim yolu tanımlama yeteneğine sahip oluruz. Dolayısıyla, veri iki ya da daha fazla bütünleşik yapıya tabi kılınabilir. Başka bir deyişle, veriye iki ya da daha fazla erişim yolu vardır.

Bu yetenek, birden fazla veri ilişkisine ait olan verinin modellenmesinde kullanılabilir. Örneğin, iki dosya, yinelenmiş kopyalar tutulmaksızın aynı kayıtları içerebilir.

Ayrıca, veri paylaşımı aracılığıyla veriye farklı şekillerde bakmak da mümkün olacaktır. Paylaşılan veri, nasıl (ve nihayetinde kim tarafından) erişildiğine bağlı olarak farklı davranışlar gösterebilir. Aynı veriye birden fazla erişim yoluna sahip olma yeteneği ile erişim sırasında hesaplanan veriye sahip olma yeteneği her ikisi de genel sanal veri yeteneğinin parçası olsa da, kullanım özellikleri farklı olduğundan, datalanguage bunları muhtemelen ayrı özellikler olarak sunacaktır.

Türetilmiş veri, diğer bilgilerden hesaplanabilen yedekli veri olması bakımından sanal veriye benzer. Sanal veriden farklı olarak fiziksel olarak tutulur. Kullanıcı, aşağıdakilere dayalı ödünleşimleri değerlendirerek sanal ve türetilmiş veri arasında seçim yapabilir:

• hesaplama maliyetinin tahmini,
• güncelleme sıklığı,
• depolama maliyetinin tahmini ve
• erişim sıklığı.

Örneğin, bir dosyanın bir bölümdeki çeşitli projelere ait bütçelerin listesini içerdiğini varsayalım. Bölüm bütçesi, bireysel proje bütçelerinin bir fonksiyonu olarak hesaplanabilir. Bu bilginin, nispeten sık erişilmesinin beklendiği, ancak seyrek güncelleneceği (örneğin yılda bir kez) öngörüldüğü için, türetilmiş veri olarak tanımlanması uygun olabilir.

Kullanıcıya, türetilmiş verinin ne zaman hesaplanacağı konusunda denetim sağlayan seçenekler sunulacaktır. Bu seçenekler, veri geçerliliği işlemlerinin denetimi için sağlananlara benzer olacaktır. Veri doğrulama ve türetilmiş veri kavramları, ilgili veriler üzerinde bir işlemin gerçekleştirilmesi gerekmesi bakımından benzerdir. Veri doğrulama durumunda, türetilen bilgi verinin durumu olur.

3.9 İç Temsil

Bu noktaya kadar yalnızca verinin üst düzey, mantıksal yönlerini ele aldık. Veri, herhangi bir zamanda, mutlaka bir fiziksel aygıt üzerinde bulunmak zorunda olduğundan, verinin bir temsili seçilmelidir. Bazı durumlarda bu seçimi datacomputer sistemine bırakmak uygundur. Örneğin, başka verilerin iletimi sürecinde kullanılan, ancak kendisi yalnızca datacomputer üzerinde bulunan bilginin temsili, kullanıcı açısından hiçbir önem taşımayabilir.

Bununla birlikte, kullanıcının temsil seçimini denetleyebilmesi önemlidir. Verinin yorumlanmasından ziyade çoğunlukla iletimini gerektiren herhangi bir uygulamada, veri, datacomputer ile iletişim kuran sistemle tutarlı bir biçimde tutulmalıdır.

Temel veri türleri açısından, datalanguage etkileşimde bulunduğu sistemlerde yaygın olarak kullanılan temsillerin çoğunu sağlayacaktır. Bazı türler için (ör. sabit nokta) bu, temsilin parametrik (ör. işaret kuralı, boyut) olarak tanımlanmasına olanak tanınarak gerçekleştirilecektir. Diğer durumlarda (ör. kayan nokta) belirli temsiller sunulacaktır (ör. System/360 kısa kayan nokta, System/360 uzun kayan nokta, PDP-10 kayan nokta vb.).

İç temsil sorunlarının bir başka yönü bütünleşik yapılara ilişkindir. Bütünleşik yapıların temsilinde seçilen yöntem, verinin işlenme maliyetini büyük ölçüde etkileyebilir. Verinin nasıl kullanılacağına dair fikre yalnızca kendisi sahip olduğundan, kullanıcının bu temsil üzerinde denetime sahip olması gerekir.

Datalanguage, veri yapılarının verimli biçimde uygulanmasına olanak tanıyan çeşitli temsil seçenekleri sunacaktır. Buna yardımcı yapıların kullanılabilirliği de dahildir.

Bu yapılar, datacomputer sistemi tarafından otomatik olarak sürdürülen yapılardır. Bu yapılar; üyelerin içeriklerine dayalı olarak veri koleksiyonlarının alt kümelerinin verimli bir şekilde geri getirilmesi (yani indekslerin yaygın kavramı), bir veri koleksiyonu üzerinde sıralamaların verimli biçimde sürdürülmesi, veri bütünlüğü amacıyla yedekli bilginin tutulması ve davranışsal özellikleri erişim yoluna bağlı olan paylaşılan verinin verimli biçimde ele alınması için kullanılabilir. Burada, datalanguage tasarım çabasının, veri kullanıcısının verisinin beklenen kullanımını tanımlayabilmesini sağlayan yöntemler sunmayı hedefleyeceği; böylece iç temsil ayrıntılarının datacomputer’a bırakılabileceği belirtilmelidir.

3.10 Veri Öznitelikleri ve Veri Sınıfları

Bir öğenin türü, o öğe üzerinde hangi işlemlerin geçerli olduğunu ve bunların ne anlama geldiğini belirler. Veri öznitelikleri, veri türünün ayrıntılandırmalarıdır. Veri öznitelikleri, işlemlerin anlamını etkiler. Örneğin, sabit nokta öğelerinin ölçekli olarak tanımlanabilmesi seçeneğini sunmak isteriz. Bu durumda ölçek faktörü, sabit nokta verisinin bir özniteliği olacaktır ve bu veri üzerindeki işlemlerin anlamını etkileyecektir. Öznitelik kavramı, bir öğenin işlenmesine ilişkin bilginin, o öğe üzerindeki tüm işlemlerin çağrılmasına değil, doğrudan öğenin kendisine iliştirilmesine olanak tanıması açısından yararlıdır.

Öznitelik kavramı, temel verilerin yanı sıra bütünleşik verilere de uygulanabilir. Örneğin, bir listenin bir özniteliği, yeni bir üyenin nereye ekleneceğini tanımlayabilir. Seçenekler şunlar olabilir: listenin başına ekle; listenin sonuna ekle; ya da üyenin içeriğine dayalı belirli bir sıraya göre ekle. Yukarıdaki özniteliklerden biriyle bir listeye yeni bir üye eklemek, yeni üyenin nereye ekleneceğini belirtmeye gerek kalmadan basit bir ekleme isteği gönderilerek yapılabilir.

Veri sınıfı kavramı, aslında veri özniteliği kavramının tersidir. Bir veri sınıfı, veri türlerinin bir koleksiyonudur. Veri sınıfı kavramı, bir öğenin özgül türünden bağımsız olarak işlemlerin tanımlanmasına olanak tanır. Örneğin, aritmetik veri sınıfı sabit nokta ve kayan nokta veri türlerinden oluşacak şekilde tanımlanarak, karşılaştırma işleçleri (equal, less_than vb.) verinin sabit ya da kayan nokta olmasından bağımsız olarak aritmetik veri üzerinde çalışacak şekilde tanımlanabilir. Ayrıca, veri bütünleği kavramı da dizinleri, listeleri vb. kapsayan bir sınıf olarak görülebilir. Aritmetik veri üzerinde tanımlı işlemler olduğu gibi, keyfi bütünleşikler üzerinde tanımlı işlemler de vardır.

Veri sınıfları ile veri öznitelikleri arasındaki ters ilişki çok güçlüdür. Örneğin, liste kavramı, üye türlerinden bağımsız olarak (ör. tamsayı listeleri, karakter dizisi listeleri vb.) tüm liste türlerini kapsayan bir veri sınıfı olarak görülebilir. Bir listenin üyelerinin türleri (ör. tamsayı, karakter dizisi vb.) ise öznitelik olarak değerlendirilir. Veri öznitelikleri ve sınıfları aynı zamanda göreli kavramlardır. Liste kavramı bir veri sınıfı olarak görülebileceği gibi, veri bütünleği kavramına göreli olarak bir öznitelik olarak da ele alınabilir.

3.11 Veri Tanımı

Bir veri tanımı, bir veri öğesinin özelliklerinin (bkz. öznitelikler hakkındaki tartışma) ifadesidir. Bir tanımda kaydedilen özelliklere örnekler şunlardır: bir öğenin adı; boyutu; veri türü; iç temsili; gizlilik bilgisi; vb.

Datalanguage, veri tanımlarının belirtilmesi için mekanizmalar içerecektir. Bu tanımlar datacomputer tarafından işlenecek ve veri öğesine her başvurulduğunda kullanılacaktır. Kullanıcı, veriyi fiziksel olarak ancak önce tanımlarını belirterek oluşturabilecektir. Bir tanımın özellikleri, işlevlerine göre gruplara ayrılabilir. Bazıları temsil ayrıntılarını belirtme işlevine sahiptir ve çoğu kullanıcı için ilgi çekici olmayacaktır; ad gibi diğerleri ise neredeyse evrensel ilgiye sahiptir.

Tüm kullanıcı verileri, daha büyük bir (kullanıcı ya da sistem) veri yapısının parçasıdır. Veriyi içeren yapılar, veriye bir erişim yolu oluşturur. Bu yolu izleme sürecinde, datacomputer sistemi veri öğesinin tam bir tanımını biriktirmek zorundadır. Örneğin, bir dizinin bir veri öğesinin tanımı, dizinin o düğümüyle ilişkili olarak bulunabilir. Bir listenin ya da dizinin üyeleri, listenin ya da dizinin tanımının bir parçası olarak tanımlanır. Görünürde iki istisnayı ele almamız gerekir. Birincisi, verinin bazı yönleri (kullanıcı isteği üzerine) sisteme bırakılabilse de, bu yönler yine de tanımlıdır; sistem tarafından tanımlanırlar. Yukarıda tartışıldığı gibi, bazı veriler bir dereceye kadar kendi kendini tanımlar nitelikte olacaktır (ör. karma listelerin üyeleri). Ancak, tam tanımın nasıl belirleneceğine ilişkin bir yöntem tanımlandığından, bunlar da kapsayıcı bir yapı içinde bütünüyle tanımlanmıştır.

Burada, erişim yolunda tam bir tanıma ne kadar erken ulaşılırsa, datacomputer’ın bir veri öğesini işleyen istekleri o kadar etkili biçimde işlemesinin muhtemel olduğu belirtilmeye değerdir. Bununla birlikte, tam tanımı erişim yolunun üst düzeylerinde bulunmayan verilere sahip olabilme yeteneği, veri yapılarının tanımlanmasında daha fazla esneklik sağlar.

3.12 Veri Başvurusu

Veriye başvurulamadıkça veri işlenemez. Verinin tanımlanmadan var olamaması gibi, veriye bir erişim yolu olmadan da var olması mümkün değildir. Veri başvurusunun yöntemi, veriye erişim yolunun tanımlanmasıdır. Yukarıda belirtildiği gibi, herhangi bir öğeye, onu içeren veri bütünleğine göreli olarak başvurmanın bir yöntemi vardır. Dizinlerin düğümlerine ve yapıların bileşenlerine, düğüm ya da bileşenle ilişkili ad üzerinden başvurulur. Dizilerin üyelerine, üyeyle ilişkili indeks üzerinden başvurulur. Listelerin üyelerine, üyenin konumunu belirten bir yöntemle ya da üyenin içeriğiyle benzersiz biçimde tanımlanması yoluyla başvurulur. Keyfi herhangi bir veri öğesine başvurmak için, erişim yolunun zincirdeki her bir bağlantısının açık ya da örtük tanımıyla tamamen belirlenmesi gerekir. Sanal veri durumunda zincirde ek bir örtük bağlantı vardır; bu da verinin diğer veri öğelerinden elde edilmesinde kullanılan yöntemdir. Ayrıca, işaretçilerin sağlanması durumunda (bkz. genel ilişkisel yetenekler hakkındaki tartışma), bunların da bir öğeye erişim zincirinde bir bağlantı olarak hizmet edebileceği belirtilmelidir.

Datalanguage tasarımı, erişim yolunun bir bölümünün örtük olarak tanımlanabilmesini sağlayan yöntemler sunarak veri öğelerine başvurma sorununu kolaylaştıracak (ve maliyeti azaltacaktır). Örneğin, datalanguage bir "bağlam" kavramı sağlayacaktır. Datacomputer ile etkileşim süreci boyunca, verilerin bağlam içinde doğrudan başvurulabilmesi için bağlam düzeyleri kurulabilir. Örneğin, bir oturum başlatılırken kullanıcı bir dizin tanımlayabilir (hatta büyük olasılıkla tanımlamak zorunda kalacaktır); bu dizin o oturumun bağlamı olacaktır. Bu dizine bağlı olan tüm öğelere bu bağlam içinde doğrudan başvurulabilir. Bir diğer özellik kısmi nitelendirme olacaktır. Yapıların derin bir iç içe geçmiş yapısı içine gömülü bir öğeye başvurmak için her yapı düzeyinin belirtilmesi gerekmez. Yalnızca öğeyi benzersiz olarak tanımlamak için yeterli olan ara düzeylerin belirtilmesi gerekir.

3.13 İşlemler

Bu bölümde, verilerin işlenmesinde merkezi öneme sahip olan datalanguage’ın yerleşik işlevlerini ele alıyoruz. Öğeler üzerinde çalışan işlevler, kümeler üzerinde çalışan işlevler, ilkel işlevler ve üst düzey işlevler tartışılmaktadır.

Öğeler üzerinde çalışan ilkel işlemler arasında en ilgi çekici olanlar atama, karşılaştırmalar, mantıksal işlemler, aritmetik işlemler ve dönüştürme işlevleridir.

İlkel atama, bir değeri bir öğeden diğerine aktarır; bu öğelerin aynı türde olması gerekir. Farklı türlerde olduklarında ya bir dönüştürme yapılmalıdır ya da ilkel olmayan bir atama biçimi söz konusudur.

Karşılaştırma işleçleri, aynı türden bir öğe çiftini kabul eder ve verilen bir koşulun sağlanıp sağlanmadığını gösteren bir boolean nesnesi döndürür. Tür, kaç farklı koşulun karşılaştırılabileceğini belirler. Sayısal öğelerden oluşan bir çift, hangisinin daha büyük olduğunu görmek için karşılaştırılabilirken, yorumlanmamış öğelerden oluşan bir çift yalnızca eşitlik açısından karşılaştırılabilir. Genel olarak, "büyüktür" kavramı yalnızca çok yaygın biçimde uygulanan bir kavram olduğunda bir veri türü için yerleşik olarak bulunur. Karşılaştırma işleçleri, küme veri alt kümeleri tanımlanırken dahil etme koşullarının oluşturulmasında kullanılır.

Bir karşılaştırma işleminin sonucu bir boolean öğedir; değeri TRUE veya FALSE olan bir öğe. Mantıksal ilkel işlemler sağlanır ve bunlardan genelleştirilmiş boolean işlevleri oluşturulabilir. Mantıksal ve karşılaştırma işleçleri ile, nesnelerin kümelere dahil edilmesine yönelik karmaşık koşullar belirtilebilir.

Sayısal verilerin işlenmesi için aritmetik işleçler kullanılabilir olacaktır. Burada genel hesaplama ile ilgilenmiyoruz; daha çok veri seçimi, alan ayırma, alt indis hesaplama, yineleme denetimi vb. bağlamlarda aritmetiğin uygulanmasıyla ilgileniyoruz.

Dönüştürme, genelleştirilmiş veri çevirisinin önemli bir parçasıdır ve kapsamlı bir yerleşik dönüştürme olanağı sağlamayı hedefliyoruz. Özellikle, her "standart" ya da yaygın olarak kullanılan dönüştürme işlevi için verimli bir sistem yordamı sağlamayı isteyeceğiz. Özellikle karakter dizisi verilerine ve bu verilerden yapılan dönüştürmeler büyük önem taşır; örneğin sayısal öğelerin karakter dizisi gösteriminde, tek bir veri türüne karşılık gelen birçok olası biçim vardır. Karakter kümeleri arasında dönüştürme ile doldurma ve kırpma işlemleri, dönüştürme sorunları olarak ele alınır.

Kümeler üzerinde tanımlanan ilkel işleçlerin iki temel sınıfı vardır: veri başvurusu ile ilgili olanlar (önceki bölüme bakınız) ve bileşen ekleyip silenler. Var olan bir bileşenin değiştirilmesi atama yoluyla gerçekleştirilir ve bu, küme üzerinde değil bileşen üzerinde yapılan bir işlemdir.

Bileşen ekleme ve silme yalnızca bileşimi doğası gereği statik olmayan kümeler için tanımlıdır. Dolayısıyla bir LIST’e bileşen eklenebilir, ancak bir ARRAY’e eklenemez. Silmeyi belirtmek için hangi bileşenin silineceğinin ve hangi kümeden silineceğinin (paylaşımlı olması durumunda) belirtilmesi gerekir. Ekleme ise yeni bileşenin, kümenin ve bazen de yardımcı bilgilerin belirtilmesini gerektirir. Örneğin, bazı küme türleri yapının herhangi bir yerine yeni bileşenlerin eklenmesine izin verir; bu durumlarda, mevcut bileşenlere göre bir konum belirtilmelidir.

Çoğu zaman bir listenin bazı üyeleri üzerinde işlem yapmak ya da bir üye grubunu kendi başına bir liste gibi ele almak istenir. Örneğin, 30 yaşından önce kalp hastalığı geliştiren hastaların tıbbi geçmişinin analiz için uzak bir programa iletilmesi yaygın olabilir. Bunlar, büyük bir hasta listesinin yalnızca birkaç üyesi olabilir.

Bu durumda yapılacak işlem uzak sisteme iletimdir; bu işlem hasta listesinin birkaç üyesi üzerinde gerçekleştirilir. İletilecek olanlar bir küme olarak düşünülür; bu küme, belirli bir listenin şu iki koşulu sağlayan tüm üyelerini içerir: (1) yaşın 30’dan küçük olması ve (2) kalp hastalığına sahip olması.

Kümeler açıkça tanımlanabilir ya da uygun başvuru mekanizmalarıyla örtük olarak tanımlanabilir. Bir kümenin tanımı, üyeliğin belirlenmesinden ve üyelere erişimden ayrıdır. Tanım, küme üyeliği için adayların belirtilmesini ve üyeleri üye olmayanlardan ayırt etmeye yarayan bir kuralın belirtilmesini içerir; örneğin "30 yaşın altında ve kalp hastalığı olan" gibi bir dahil etme koşulu. Belirleme, kuralın tüm adaylara etkin biçimde uygulanmasını içerir. Üyelik belirlendiğinde, üyeler sayılabilir, ancak verinin kendisine mutlaka erişilmiş olmaz. Bir üyeye erişildiğinde ise içeriği üzerinde işlem yapılabilir.

Bir küme üzerinde bu işlemlerin her birini gerçekleştirmek için ilkel işlemler sağlanacaktır; ancak genellikle her adımın ne zaman yapılacağına datacomputer’ın karar vermesi en uygun olacaktır. Kullanıcıların datacomputer’ın etkili biçimde eniyileme yapabileceği bir düzeyde çalışabilmesini sağlamak için, kümeler üzerinde üst düzey işleçler sunulacaktır. Bunlardan bazıları birleşim ve kesişim gibi mantıksal işleçlerdir. Bunlar küme girdileri alır ve küme çıktıları üretir. Ayrıca bir kümeyi tümleyen bir işleç de mevcuttur (tanım tüm olası adayları belirlediğinden, bir kümenin her zaman iyi tanımlanmış bir tümleyeni vardır).

Bu üst düzey işleçler, tanımlanmış herhangi bir kümeye uygulanabilir; küme üyelerinin belirlenmiş ya da erişilmiş olması gerekmez. Sistem, mümkün olduğunda üyelere fiilen erişmeden bu tür işlemleri gerçekleştirecektir.

Kümeler üzerindeki diğer bazı işlemler; üyelik sayımı, bir kümeyi kümeler kümesine bölme ve bir kümeler kümesini tek bir kümede birleştirmedir. Bir küme, ilk küme verildiğinde ikinci kümenin üyelerinin iyi tanımlanmış bir şekilde belirlenebilmesi koşuluyla, başka bir kümeye başvurmak için kullanılabilir. Örneğin, C kümesi okulda başarısı düşük olan tüm çocukları içerebilir. F kümesi ise, üyeleri C kümesinde bir çocuğu olan ailelere ilişkin kayıtlar olacak şekilde tanımlanabilir.

Kümeler üzerindeki diğer yararlı işlemler şunlardır: bir kümenin tüm üyelerini bir kümeye eklemek, bir kümenin tüm üyelerini silmek (çoğu zaman böyle büyük çaplı bir değişiklik, aynı değişikliklerin tek tek istenmesine kıyasla çok daha verimli biçimde yapılabilir) ve bir kümenin tüm üyelerini belirli bir şekilde değiştirmek.

Bir küme, her bir üyesine fiilen erişilip fiziksel olarak toplanarak bir listeye dönüştürülebilir.

Listeler üzerindeki bazı işlemler şunlardır: listelerin daha büyük listeler halinde birleştirilmesi, bir listenin daha küçük listelere bölünmesi, bir listenin sıralanması ve sıralı iki listenin (sıralamayı koruyarak) birleştirilmesi.

Bu, üst düzey işlemlerin tam bir dökümü olmayı amaçlamamaktadır; yalnızca yol gösterici niteliktedir. Çok yaygın olarak kullanılan ve sistem içinde, kullanıcıların dil içinde uygulayabileceklerinden belirgin biçimde daha iyi gerçekleştirilebilen işlemler için üst düzey işlevleri yerleşik olarak sağlamayı planlıyoruz. Burada anılan işlevlerin çoğu için, iyi uygulamalara ilişkin önemli bir bilgi birikimi vardır. Özellikle, ters dosya erişiminde kullanılan teknikler, veriye fiilen erişmeden birçok küme işleminin gerçekleştirilmesini sağlar.

3.14 Denetim

Datalanguage’ın denetim özellikleri, temel veri öğelerine karşılık veri kümelerinin durduğu konumda, temel işlemlere karşılık gelir. Denetim özellikleri, datalanguage tarafından sağlanan temel isteklerden karmaşık istekler oluşturmak için kullanılır.

Koşullu istekler, belirli koşullar altında belirli isteklerin yürütülmesini belirterek kullanıcının normal istek akışını değiştirmesine olanak tanır. Genel olarak datalanguage, bir koşullar kümesine ya da bir öğenin değerine bağlı olarak birden fazla istekten en fazla birinin seçilerek yapılabilmesini sağlayacaktır. En basit biçimiyle koşul, verilen bir isteğin isteğe bağlı olarak yürütülmesine olanak tanır.

Yinelemeli istekler, bir isteğin (gövde olarak adlandırılır) sabit ya da değişken sayıda kez ya da belirli bir koşul sağlanana kadar yürütülmesine neden olur. Datalanguage, sayaçlara dayalı standart yinelemeli istek türünün yanı sıra, bazı küme yapılarının tüm üyeleri üzerinde benzer işlemlerin yapılmasına olanak tanıyan yinelemeli istekler sağlayacaktır. Bir kümenin altındaki tüm öğelerin işlenmesini gerektiren manipülasyonların doğrudan ifade edilebilmesini sağlayarak, datacomputer kullanıcı isteklerini işlerken daha verimli olabilir. Örneğin, karakter dizileri üzerinde çalışan kullanıcı tanımlı bir dönüştürme süreci, sürecin karakterlerin ardışık olarak işlenmesini gerektirdiği datacomputer’a açıkça bildirildiğinde çok daha verimli biçimde uygulanabilir.

Datalanguage ayrıca paralel yinelemeyi de sağlayacaktır. Örneğin, kullanıcı iki ya da daha fazla listenin paralel olarak sıralanmasını gerektiren işlemleri belirtebilecektir. Bu, bir dosyanın içeriğinin bir düzeltme bilgileri dosyasına dayanarak güncellenmesi durumunda yapılır.

Bileşik istekler, tek bir bütün olarak davranan istek koleksiyonlarıdır. Bunlar öncelikle birden fazla deyimin koşullu olarak yürütülmesine ya da yinelemesine olanak tanımak için sağlanır. Bileşik istekler ayrıca istek işleme akışını denetlemek için kullanılabilecek istek başvuru noktaları sağlar. Yani bileşik istekler "adlandırılabilir". Datalanguage kullanıcısı, bir bileşik isteğin koşullu olarak sonlandırılmasına neden olacak denetim bilgilerini belirtebilecektir. Adlandırma sağlanarak, kullanıcı daha önce girilmiş herhangi sayıda bileşik isteğin sonlandırılmasını sağlayabilir.

Geleneksel goto yeteneğini sağlamayı düşünmüyoruz. Bir goto isteğini dahil etmeyerek, datacomputer’ın (eniyileme yoluyla) verimli çalışabilme olasılığı artırılmaktadır. Ayrıca bu yolla, datalanguage kullanıcısını veri manipülasyonlarını açık bir üslupla belirtmeye zorlamayı umuyoruz.

Bileşik isteğin iki biçimi sağlanacaktır: sıralı ve sırasız. Sırasız durumda kullanıcı, isteklerin herhangi bir sırayla gerçekleştirilebileceğini datacomputer’a bildirmektedir. Bu, datacomputer’ın daha verimli çalışmasına olanak tanımalı ve hatta paralel işlemeyi mümkün kılabilir.

Datacomputer ile bir oturum sırasında, bir kullanıcının geçici veriye gereksinim duyması muhtemeldir. Yani, isteklerin işlenmesi için kısa süreliğine gerekli olan bilgileri hatırlamak üzere kullanılan veriler. Bu kısa süre bir oturum ya da bir oturumun küçük bir bölümü olabilir. Datalanguage bir geçici veri olanağı sağlayacaktır. Geçici verilerin oluşturulması, kullanılması ve elden çıkarılması kolay olacaktır. Bu, sistemin veriyle ilgili birçok kararı (isteğe bağlı olarak) almasına izin verilerek gerçekleştirilecektir. Örneğin, geçici bir tamsayı öğesinin gösterimi çoğu zaman kullanıcı için önem taşımaz. Kalıcı veriler için sağlanan bazı özellikler, geçici veriler açısından ilgisiz kabul edilecektir.

Geçici veriler, blok olarak adlandırılacak bir istek koleksiyonu ile ilişkilendirilecektir. Bir blok, onu oluşturan isteklerle birlikte verinin tanımlanması ve bloğa girildiğinde otomatik olarak oluşturulması, bloktan çıkıldığında ise yok edilmesi dışında, bileşik bir istekten farklı olmayacaktır.

3.15 Genişletilebilirlik

Datalanguage’ın hedefleri, veri yapısı olanaklarını iki düzeyde sağlamaktır. Bir düzeyde kullanıcı, veri yönetimi işlerinin büyük bölümünü otomatik olarak yapan ve bazı durumlarda datacomputer’ın veri üzerinde denetim sahibi olmasına izin verildiği için daha etkili çalışmasını sağlayan üst düzey veri yeteneklerinden yararlanabilir. Ancak diğer bir düzeyde, kullanıcının uygulamasını ilkel kavramlar cinsinden tanımlamasına olanak tanıyan özellikler sağlanır. Bu yolla datacomputer kullanıcısı çok çeşitli veri kurguları oluşturabilir ve verileri üzerinde gerçekleştirebileceği manipülasyonlar açısından büyük bir esnekliğe sahip olur. Ayrıca datacomputer ile ilkel düzeyde etkileşerek, kullanıcı datacomputer tarafından kullanılan yöntemler üzerinde önemli ölçüde denetim uygulayabilir; bu da standart olmayan uygulamalar için kaynakların daha etkili kullanılmasına yol açabilir. Datalanguage, kullanıcının datacomputer sisteminin kendi uygulamasına özel olarak uyarlanmış özellikler sağlıyor gibi göründüğü bir ortam oluşturmasına olanak tanıyan özellikler sunacaktır.

Yukarıda tartışılan denetim özellikleri, işlemlerin uygun biçimde bileştirilmesi yoluyla veri üzerinde kullanılabilen işlemlerin genişletilmesine olanak tanır. Datalanguage, bileşik bir isteğin yeni bir istek ( function olarak adlandırılır) olarak tanımlanmasına yönelik bir yöntem sağlayacaktır. Bu yolla, belirli veriler üzerinde yeni bir işlem bir kez tanımlanabilir ve daha sonra tekrar tekrar kullanılabilir. Kullanıcının genel işlemler tanımlayabilmesi için, datalanguage parametreli olabilen işlevler sağlayacaktır. Yani işlevler yalnızca belirli veriler üzerinde çalışmakla kalmayacak, aynı zamanda belirli bir türdeki herhangi bir veri üzerinde çalışacak şekilde tanımlanabilecektir. Bu yetenek yalnızca temel veri türleriyle (örneğin tamsayılar) ya da hatta belirli küme türleriyle (örneğin tamsayılardan oluşan dizi) sınırlı olmayacak, aynı zamanda veri sınıfları üzerinde çalışan işlevlerin tanımlanabilmesini de içerecektir. Örneğin, liste üyelerinin türünden bağımsız olarak listeler üzerinde çalışan işlevler tanımlanabilir. Ayrıca mevcut işlevlerin genişletilmesi ve değiştirilmesi ile yeni işlevlerin geliştirilmesi olanağı da sağlanacaktır. Buna, bir işlevin tanımlı olduğu veri türlerinin genişletilmesi ya da belirli veri türleri için bir işlevin davranışının değiştirilmesi de dahildir.

İşlemlerde olduğu gibi, yukarıda tartışılan veri kümeleri, kullanıcının ilkel veri türlerini uygun bileşim yoluyla genişletmesine olanak tanır. Örneğin, tamsayılardan oluşan iki boyutlu bir dizi, tamsayı dizilerinden oluşan bir dizi oluşturularak elde edilebilir. Veri türleri için durum, işlemlerinkine benzerdir. Datalanguage, verilerin bir bileşimini yeni bir veri türü olarak tanımlama yeteneğini sağlayacaktır. Ayrıca, yeni veri tanımını esasen parametreleştirerek genel veri yapılarının tanımlanması yeteneği de sağlanacaktır. Bu, iki boyutlu dizi genel kavramının, dizilerin dizisi olarak tanımlanmasına olanak tanır. Bir kez tanımlandıktan sonra, tamsayılardan oluşan iki boyutlu diziler, boole’lardan oluşan iki boyutlu diziler vb. oluşturulabilir. Fonksiyonlarda olduğu gibi, mevcut veri türlerini genişletme ya da değiştirme gereksinimi de vardır. Bir kişi, belirli bir veri türüne uygulanan öznitelikleri genişletmek isteyebilir; yani yeni öznitelikler eklemek ya da mevcut öznitelikler için yeni seçenekler eklemek isteyebilir.

Denetim özellikleri de genişletilebilir. Bir veri yapısını özel bir biçimde işlemek ya da kullanıcı tanımlı bir veri yapısını işlemek için özel denetim özelliklerine gereksinim duyulabilir. Örneğin, bir ağaç türü veri yapısı, listelerin listeleri cinsinden tanımlanmışsa, kullanıcı belirli bir işlemin belirtilen bir ağacın her bir öğesi üzerinde gerçekleştirilmesini sağlayan bir denetim fonksiyonu tanımlamak isteyebilir. Veri türleri ve fonksiyonlarda olduğu gibi, mevcut denetim özelliklerini değiştirme ve genişletme yeteneğinin yanı sıra yenilerini oluşturabilme yeteneğine de gereksinim vardır.

Datalanguage, veri tanımlarını ve işlemleri, verilerin ele alındığına çok benzer bir şekilde ele alma yeteneğini sağlayacaktır. Tanımları ve işlemleri, verileri tanımlayıp işleyebildiği gibi tanımlayıp işleyebilir. Veri türlerinden, işlemleri dikkate almadan söz etmek olanaksızdır; aynı şekilde, üzerinde çalıştıkları veri türlerini anlamadan işlemlerden söz etmek de olanaksızdır. Kullanıcının datacomputer sisteminin davranışını etkileyebilmesi için, datalanguage tasarımı datacomputer’ın işlemsel çevriminin bir tanımını içerecektir. Verinin tüm yönlerinin (veri öznitelikleri, veri sınıfları, kümelerin alt öğeleriyle ilişkileri vb.) datalanguage işlemleriyle etkileşimleri açısından kesin tanımları yapılacaktır. Bu yolla datacomputer, datacomputer kullanıcısına kullandığı datalanguage’ın tasarımında etkin bir katılımcı olma yeteneği verecek araçlar sunabilir.

4. Datalanguage Anlambilimi için Bir Model

Dil anlambilimini ve dil işleme tekniklerini tanımlamak ve bunlarla deney yapmak amacıyla bir model datacomputer geliştiriyoruz.

Modelin temel öğeleri şunlardır:

1. Bir dizi ilkel fonksiyon
2. İlkel fonksiyonlar kullanılarak veri nesnelerinin oluşturulabildiği, işlenebildiği ve silinebildiği bir ortam
3. Veri değerleri koleksiyonlarının, bunların tanımlarının, ilişkilerinin ve adlarının gösterimi için bir yapı
4. İlkel fonksiyonları yürüten bir yorumlayıcı
5. Çok basit bir dilde istekleri alan, bağlama ve makro genişletme işlemlerini gerçekleştiren ve iç anlamsal ilkel fonksiyonlara çağrılar üreten bir derleyici

Modelleme çabalarımız başarılı olursa, model, bu makalenin 2 ve 3. bölümlerinde özelliklerini tanımladığımız datalanguage benzeri bir dili kabul edene kadar evrilecektir. Bundan sonra, son belirtimin yazılması süreci, modellenmemiş ayrıntıların modellenmiş yapı ile uzlaştırılmasını gerektirecektir. Model içinde hiçbir zaman ele alamayabileceğimiz oldukça büyük bir ayrıntı sözdizimidir; bu durumda uzlaştırma daha kapsamlı olacaktır; ancak anlamsal yapının sözdizimini belirlemesi gerektiğine, bunun tersinin değil, güçlü bir biçimde inanıyoruz; dolayısıyla problemi ele almak için doğru konumda olacağız.

Yukarıda listelenen öğelerin her biri için bir model kurarak, dili tasarlarken çok gevşek bir anlamda dili “uyguluyor” sayılırız. Etkili olarak, yalnızca kâğıt üzerinde çalışmak yerine bir laboratuvarda çalışırız. Laboratuvarda kurduğumuz datacomputer’ın performansı ya da kullanılabilirliğiyle ilgilenmediğimiz için, bir uygulayıcının en çok zaman alan bazı kaygılarına bulaşmadan geliştirme yapabiliriz. Bununla birlikte, yalnızca kâğıt üzerinde çalışmak yerine inşa edip kurcaladığımız için, fikirleri uygulama deneyimiyle normalde gelen bazı avantajları da elde ederiz.

Model datacomputer, EL1 dili kullanılarak ECL içinde geliştirilmiş bir programdır. Şu anda programı çalıştırmakla değil, geliştirme süreciyle ilgileniyoruz. Birincil gereksinimimiz, datalanguage henüz var olmadan önce, veri yapıları, fonksiyon tanımları ve örnekleri belirtmek için iyi tanımlanmış ve esnek bir gösterime sahip olmaktır. EL1 bu amaç için elverişlidir. Gerçekten çalışan ve basit bir datacomputer gibi davranan bir programa sahip olmak, anlambilimi bir programlama dilinde belirtmenin aslında bir yan ürünüdür. Programın çalışması gerekli değildir, ancak bazı güzel özellikler sağlar. İlkel fonksiyon dizilerini otomatik olarak derlemek, karmaşık örneklerde ortamın durumunu göstermek, tutarsızlıkları (hata biçiminde) otomatik olarak keşfetmek gibi şeyler yaparak “laboratuvar” etkisini güçlendirir.

EL1’in datalanguage anlambilimini belirtmek için elverişli bir gösterim olmasının iki temel nedeni vardır. Birincisi, dillerin hem kavramlar hem de veri tanımındaki hedefler açısından belirli ölçüde ortak noktaları olmasıdır. (Kısmen, bu durum EL1’in kendisinin datalanguage sorununa yaklaşımda iyi bir fikir kaynağı olmasından kaynaklanır.) Her iki dil de, altta yatan gösterimden bağımsız olarak veriler üzerinde yapılan işlemleri vurgular. İkinci neden ise EL1’in genişletilebilir olmasıdır; aslında birçok ilkel fonksiyon, genişletme olanakları kullanılarak doğrudan EL1 içine gömülebilir. Zaman zaman, ilgimizi çeken sorunları açığa çıkarmak için, yapabileceğimizden daha azını gömmeyi tercih ettik.

Şu ana kadar model, öncelikle tasarım sorunlarını ve tasarım kararları arasındaki ilişkileri ortaya çıkarmada yararlı olmuştur. Ayrıca, tam sistemin pek çok öğesini (derleyici, yorumlayıcı, ortam vb.) içerdiği için, herhangi bir önerinin oldukça kapsamlı bir analizini teşvik eder.

Bu bölümde modeli sunarken, EL1’deki biçimsel tanımlardan ziyade fikirleri ve örnekleri vurgulamayı seçtik. Bunun nedeni, fikirlerin bu aşamada daha kalıcı ve daha ilgili olmasıdır (biçimsellikler oldukça sık değişmektedir) ve insanların biçimsel tanımları yalnızca fikirlere ulaşmak için okuyacaklarını varsaymamızdır. Dil tamamlandığında biçimsel tanımlar kendi başlarına ilginç olabilir; bu aşamada ise muhtemelen yalnızca bizim için ilgi çekicidir.

Bölüm çok sayıda alt bölüme ayrılmıştır. İlk birkaç alt bölüm, veri nesnelerinin, tanımların ve nesneler arasındaki ilişkilerin temel kavramlarıyla ilgilidir. Daha sonra ilkel anlamsal fonksiyonları tartışır ve 4.7 ve 4.8 bölümlerinde gayriresmî tanımlar ve örnekler sunarız. Bölüm 4.9, derleme, yorumlama ve yürütme çevrimi üzerine kısa bir tartışmadır. Bölüm 4.10, ilkel fonksiyonların ilgi çekici bir şey yapmak için nasıl birleştirilebileceğine dair oldukça ayrıntılı bir örnek sunar: içeriğe göre seçmeli geri getirme. Son iki bölüm, üst düzey fonksiyonlar ve bazı sonuçlara ilişkin tartışmalarla konuyu toparlar.

4.1 Nesneler

Bir nesne bir ada, bir tanıma ve bir değere sahiptir. Diğer nesnelerle ilişkilendirilebilir.

Ad, dil fonksiyonları aracılığıyla nesneye erişmek için kullanılabilen bir semboldür.

Tanım, nesnenin özelliklerinin bir belirtimidir; bunların birçoğu değerin anlamı ya da gösterimiyle ilişkilidir.

Değer, nesnede nihai ilgi konusu olan bilgidir.

Nesneler arasındaki ilişkiler hiyerarşiktir. Her nesne doğrudan en fazla dört başka nesneyle ilişkilendirilebilir; bunlar sırasıyla ebeveyn, çocuk, sol kardeş ve sağ kardeş olarak adlandırılır.

Bu özel ilişki kavramı, bugüne kadar modele yerleştirilmiş olanların tümüdür. Gelecekteki birincil hedeflerimizden biri, nesneler arasında daha genel ilişkilerle deney yapmaktır.

4.2 Tanımlar

Bir tanımın bileşenleri ad, tür ve _türe bağlı parametreler_dir. 4.1’de nesneler için tanımlanan şemaya benzer bir düzene göre, diğer tanımlarla hiyerarşik olarak ilişkilendirilebilir.

Ad, nesneler durumunda olduğu gibi, başvurma işlevi görür.

Tür, datalanguage içinde kesin bir anlam geliştirmeyi beklediğimiz, tanımsız ve sezgisel bir fikirdir (bu konudaki bazı fikirler için bölüm 3.10’a bakınız). Mevcut model açısından, yalnızca aşağıdakilerden biri anlamına gelir:

• LIST
• STRUCT
• STRING
• BOOL
• DESC
• DIR
• FUNC
• OPD

Bunların her biri, programlamadaki yaygın fikirlere karşılık gelen bir değer türünü ifade eder (OPD hariç; OPD bölüm 4.7’de açıklanmaktadır) ve bunlar üzerinde belirli işlemler tanımlıdır.

_Türe bağlı parametreler_e örnek olarak, bir STRING’i tanımlamak için gereken iki öğe verilebilir: boyut seçeneği ve boyut. STRING bir karakter dizisidir; STRING’in boyutu, içindeki karakter sayısıdır. Bir STRING sabit boyutluysa, boyut seçeneği FIXED olur ve boyut, her zaman içerdiği karakter sayısıdır. Bir STRING değişken boyutluysa, boyut seçeneği VARYING olur ve boyut, onun en büyük değeridir (daha ayrıntılı bir düzende açıkça bir en küçük değeri de olabilir).

Bir nesnenin tanımı STRING türünde olduğunda, yaygın olarak nesnenin bir STRING olduğu söylenir.

4.3 Değerler

Değer, verinin kendisidir.

BOOL türündeki bir nesne yalnızca TRUE ya da FALSE değerlerinden birine sahip olabilir.

STRING türündeki bir nesnenin değerleri "ABC", "JOHN" ya da "BOSTON" gibi olabilir.

Her değerin bitler cinsinden bir gösterimi vardır. Dolayısıyla bir BOOL tek bir bit ile gösterilir; TRUE’yu temsil etmek için bir, FALSE’u temsil etmek için sıfır kullanılır.

4.4 Bazı Örnekler

Burada nesneleri, tanımları ve değerleri içeren bazı yapı örnekleri verilmiştir. Bu açıklamalar ve çizimlerde amaç, bu ilkel yapılar hakkında bazı fikirler aktarmaktır; açıklık adına çizimlerde önemli ölçüde ayrıntı atlanmıştır.

Şekil 4-1 iki nesne göstermektedir. X, STRING türündedir ve "ABC" değerine sahiptir. Y, BOOL türündedir ve TRUE değerine sahiptir.

Şekil 4-1
İki temel nesne

Şekil 4-2, DIR türünde bir nesneyi (bir dizin) ve ilişkili nesneleri göstermektedir. Dizin SMITH adını taşır. Bu dizine X ve Y adlı iki nesne girilmiştir.

Şekil 4-2
İki üyeli bir dizin

DIR fikri, çoğu sistemdeki dosya dizini fikrine benzer. Bir dizin, adlandırılmış nesnelerin depolanabildiği, serbestçe eklenip silinebildiği bir yerdir. Dizindeki girdiler, ebeveyni o dizin olan tüm nesnelerdir.

Şekil 4-3, daha katı bir biçimde yapılandırılmış bir nesne grubunu göstermektedir. Burada bir STRUCT olan R ve STRING çiftini oluşturan A ve B vardır. Şekil 4-3’te “nesne” olarak etiketlenen kutuların, Şekil 4-2’de “nesne” olarak etiketlenenlerle birbirleriyle tam olarak aynı ilişkileri taşıdığına dikkat ediniz. Ancak Şekil 4-3 için geçerli olup Şekil 4-2 için geçerli olmayan iki koşul vardır:

1. R’nin değeri, A ve B’nin değerlerini içerir.
2. R, A ve B’nin tanımları birbirleriyle ilişkilidir.

STRUCT’ların aşağıdaki özellikleri vardır:

1. STRUCT içindeki her bileşenin adı ve tanımı, STRUCT oluşturulduğunda belirlenir.
2. STRUCT’un bir değerinde, bileşen değerlerinin ortaya çıkış sırası sabittir.

Şekil 4-3
İki üyeli bir STRUCT

Şekil 4-4, L adlı bir LIST’i göstermektedir. Burada benzer bir nesne yapısı ima edilir; ancak yapının düzenliliği nedeniyle, “nesne” olarak etiketlenen kutuların tümü gerçekte mevcut değildir.

Şekil 4-4
Bir LIST

L, sayısı değişken olan bileşenlere sahiptir ve bunların tümü, L’nin tanımına bağlı olan tanımı karşılar.

L’deki her bir string için bir “nesne” kutusu hayal edebiliriz. Bu kutuların her biri kendi string’ine ve bu string’lerin ortak tanımına işaret ederdi. Bunun yerine, gereksinim duydukça bu tür kutuları oluşturmayı düşünürüz.

4.5 Türlerin Tanımları

Aşağıda, mevcut model açısından türlerin daha kesin bazı tanımları verilmektedir. Bunlar, nesneler, tanımlar ve değerler yapımızın anlambilimini daha sağlam biçimde yerleştirme amacına hizmet eder; ancak tamamlanmış dil belirtimi için bir tanım sağladıkları düşünülmemelidir.

STRING türündeki bir nesnenin değeri, bir karakter dizisidir (şekil 4-1).

BOOL türündeki bir nesnenin değeri, bir doğruluk değeridir (TRUE ya da FALSE — şekil 4-1).

DIR türündeki bir nesnenin, her biri kendi tanımına ve değerine sahip olan alt nesneleri vardır. Alt nesneler istenildiği gibi eklenip silinebilir (şekil 4-2).

STRUCT türündeki bir nesnenin, her birinin STRUCT’un tanımına bağlı bir tanımı ve STRUCT’un değeri içinde yer alan bir değeri olan alt nesneleri vardır. Bileşenlerin sayısı, sırası ve tanımı STRUCT oluşturulduğunda sabittir (şekil 4-3).

LIST türündeki bir nesne, LIST’in işlenmesinde uygun tekniklerin kullanılmasıyla varlığı benzetilen hayali alt nesnelere sahipmiş gibi düşünülebilir. Bunların her biri aynı tanıma sahiptir ve bu tanım LIST’in tanımına bağlıdır. Her birinin LIST’in değeri içinde yer alan ayrı bir değeri vardır. Gerçekte yalnızca LIST nesnesi, LIST ve bileşen tanımları ve değerler mevcuttur (şekil 4-4).

DESC türündeki bir nesnenin değeri bir tanımdır. Bu değer, diğer nesnelerin tanımı olarak hizmet eden varlıkla aynı türdendir.

FUNC türündeki bir nesnenin değeri bir fonksiyon çağrısıdır. Fonksiyonlar tartışıldıktan sonra bunun hakkında daha fazla şey söyleyebileceğiz.

OPD türündeki bir nesnenin değeri bir işlem tanımlayıcısıdır (ayrıntılar için 4.7’ye bakınız).

4.6 Nesne Ortamı

Model datacomputer’da üç kategori nesne vardır. Bunlar p/nesneler, t/nesneler ve i/nesnelerdir.

P/nesneler, dil fonksiyonlarıyla açıkça oluşturulan kalıcı nesnelerdir. Gerçek datacomputer’daki saklanan veri fikrine karşılık gelirler. Üç özel nesne vardır. Bunlar, dil fonksiyonlarının yürütülmesi sonucu değil, ortamın ilklendirilmesinin bir parçası olarak oluşturulmaları bakımından özeldir. Bunların adları STAR, BLOCK ve TOP/LEVEL’dır. Üçü de DIR türündedir.

Bir nesne, STAR’a bağlıysa p/nesnedir; BLOCK’a bağlıysa t/nesnedir. TOP/LEVEL, BLOCK’a bağlıdır (şekil 4-5 ve 4-6’ya bakınız).

               _________________
              |                 |
              |  _____________  |
              | |    YILDIZ   | |
              | |_____________| |
              |  AD             |        ____________
              |  _____________  |       |  ________  |
              | |         ____|_|______\| |  DİZİN  | |
              | |_____________| |      /| |________| |
              |  AÇIKLAMA       |       |  TÜR       |
              |  _____________  |       |____________|
              | |             | |        AÇIKLAMA
              | |_________|___| |
              |  ÇOCUK    |     |
              |___________|_____|
               NESNE     |
                          |
                          |
                          |
                          V

                    TÜM P/NESNELER

Şekil 4-5
YILDIZ ve p/nesneler

T/nesneler, geçici nesnelerdir ve dil fonksiyonlarıyla açıkça oluşturulur. Ancak bunlar, hem isteklere yerel olan hem de "üst seviye" (yani herhangi bir isteğe yerel olmayan, ancak silinmeye veya çıkış yapılmaya kadar var olan) kullanıcı tanımlı geçicilere karşılık gelir.

                _________________
               |                 |
               |  _____________  |
               | |    BLOK     | |
               | |_____________| |
               |  AD             |        ____________
               |  _____________  |       |  ________  |
               | |         ____|_|______\| |  DİZİN  | |
               | |_____________| |      /| |________| |
               |  AÇIKLAMA       |       |  TÜR       |
               |  _____________  |       |____________|
               | |             | |        AÇIKLAMA
               | |_________|___| |
               |  DEĞER    |     |
               |___________|_____|
                NESNE     |
                           |
                           |
                ___________V_____
               |                 |
               |  _____________  |
               | | ÜST/SEVİYE  | |
               | |_____________| |
               |  AD             |        ____________
               |  _____________  |       |  ________  |
               | |         ____|_|______\| |  DİZİN  | |
               | |_____________| |      /| |________| |
               |  AÇIKLAMA       |       |  TÜR       |
               |  _____________  |       |____________|
               | |         ____|_|___     AÇIKLAMA
               | |_____________| |   |
               |  KARDEŞ         |   |
               |  _____________  |   |___\ TÜM BLOKLAR VE
               | |             | |       / YEREL T/NESNELER
               | |_________|___| |
               |  ÇOCUK    |     |
               |___________|_____|
                           |
                           |
                           V

                      TÜM KÜRESEL
                      T/NESNELER

Şekil 4-6
BLOK, ÜST/SEVİYE ve t/nesneler

I/nesneler, bazı dil fonksiyonlarının yürütülmesi sırasında oluşturulması ve silinmesi örtük olan, sistem tarafından tanımlanmış dahili nesnelerdir.

I/nesneler, doğrudan fonksiyon çağrılarından ( FUNC türündeki nesnelerden) sarkıtılır ve her zaman bu tür fonksiyon çağrılarının yürütülmesine yereldir. Bunlar, (1) sabit değer ve (2) derleyici veya yorumlayıcı tarafından üretilmiş geçici kavramlarına karşılık gelir.

4.7 İlkel Dil Fonksiyonları

Burada, modelde hâlihazırda uygulanmış olan ve muhtemelen en fazla ilgi uyandıracak ilkel dil fonksiyonlarını ele alıyoruz. Bu bölümde vurgu, fonksiyonların birbirleriyle ilişkilendirilmesi üzerinedir. Bölüm 4.8 daha fazla ayrıntı ve örnek içermektedir.

Atama

Atama, hedef ve kaynak olarak adlandırılan bir nesne çifti üzerinde çalışır. Kaynağın değeri hedefin değerine kopyalanır. Şekil 4-7, X hedef ve Y kaynak olacak şekilde bir atamanın yürütülmesinden önce ve sonra X ve Y nesnelerinin durumunu göstermektedir. Şu anda atama yalnızca BOOL türündeki nesneler ve STRING türündeki nesneler için tanımlıdır. İlgili nesnelerin açıklamalarının özdeş olması gerekir.

               _________________        _________________
              |                 |      |                 |
              |  _____________  |      |  _____________  |
              | |             | |      | |             | |
              | |      X      | |      | |      Y      | |
              | |_____________| |      | |_____________| |
              |  AD             |      |  AD             |
              |  _____________  |      |  _____________  |
              | |             | |      | |             | |
              | |_______|_____| |      | |_______|_____| |
              |  DEĞER  |       |      |  DEĞER  |       |
              |_________|_______|      |_________|_______|
               NESNE    |             NESNE      |
                        |                        |
               _________V_______        _________V_______
              |                 |      |                 |
              |      "ABC"      |      |      "DEF"      |
              |_________________|      |_________________|
               DEĞER                    DEĞER

                           ATAMA ÖNCESİ

               _________________        _________________
              |                 |      |                 |
              |  _____________  |      |  _____________  |
              | |             | |      | |             | |
              | |      X      | |      | |      Y      | |
              | |_____________| |      | |_____________| |
              |  AD             |      |  AD             |
              |  _____________  |      |  _____________  |
              | |             | |      | |             | |
              | |_______|_____| |      | |_______|_____| |
              |  DEĞER  |       |      |  DEĞER  |       |
              |_________|_______|      |_________|_______|
               NESNE    |             NESNE      |
                        |                        |
               _________V_______        _________V_____
              |                 |      |                 |
              |     "DEF"       |      |     "DEF"       |
              |_________________|      |_________________|
               DEĞER                    DEĞER

                           ATAMA SONRASI

Şekil 4-7
Atamanın etkisi

LIST'leri işlemek için bir ilkel fonksiyonlar sınıfı tanımlanmıştır. Bunlara listops adı verilir. Tüm listops işlemleri, işlem tanımlayıcısı ya da OPD adı verilen özel bir nesneyi girdi olarak alır.

Bir LIST üzerinde tam bir işlem gerçekleştirmek için bir listops dizisinin yürütülmesi gerekir. Bu tür dizilerin bileşimine ilişkin anlamsal kısıtlamalar vardır ve tüm diziyi tek büyük bir işlem olarak düşünmek en iyisidir. Böyle bir işlemin durumu OPD içinde tutulur.

Şekil 4-4'e geri dönelim. Bu resimde "nesne" olarak etiketlenmiş bir kutu vardır; bu kutu LIST'in tamamını temsil eder. Herhangi bir üye üzerinde işlem yapabilmek için, o üyeyi temsil eden bir nesne kutusuna ihtiyaç duyarız. Şekil 4-8, ek bir nesne kutusu içeren yapıyı göstermektedir; yeni kutu, herhangi bir anda bir üyeyi temsil eder. Değeri, LIST değerinin bileşenlerinden biridir; açıklaması ise LIST açıklamasına bağımlıdır. 4-8'de bu nesnenin adı M'dir.

4-8'de, M için bir açıklama ve değer sağlamak üzere yeterli yapı mevcuttur ve bu, M üzerinde bir öğe olarak işlemlerin yürütülmesine izin vermek için yeterlidir. Ancak, M nesnesi ile L nesnesi arasında doğrudan bir bağlantı yoktur. Yapı, Şekil 4-9'da gösterilen bir OPD'nin eklenmesiyle tamamlanır.

       _________________         _________________
      |                 |       |  _____________  |
      |  _____________  |       | |             | |
      | |      L      | |       | |_____________| |
      | |_____________| |       |  TÜR            |
      |  AD             |       |  _____________  |
      |  _____________  |       | |             | |
      | |         ____|_|______\| |__________|__| |
      | |_____________| |      /|  ÇOCUK     |    |
      |  AÇIKLAMA       |       |____________|____|
      |  _____________  |        AÇIKLAMA |
      | |             | |                    |
      | |_________|___| |        ____________V____
      |  DEĞER    |     |       |  _____________  |
      |___________|_____|       | |    STRING   | |/___
       NESNE     |             | |_____________| |\   |
                  |             |  TÜR            |    |
       ___________V_____        |_________________|    |
      |                 |        AÇIKLAMA           |
      |  _____________  |                              |
      | |    "ABC"    | |        _________________     |
      | |_____________| |       |                 |    |
      |  _____________  |       |  _____________  |    |
      | |     "XY"    | |       | |      M      | |    |
      | |_____________| |       | |_____________| |    |
      |  _____________  |       |  AD             |    |
      | |    "ZLM"    |/|___    |  _____________  |    |
      | |_____________|\|   |   | |         ____|_|____|
      |        :        |   |   | |_____________| |
      |        :        |   |   |  AÇIKLAMA       |
      |  _____________  |   |   |  _____________  |
      | |    "BBBF"   | |   |___|_|____         | |
      | |_____________| |       | |_____________| |
      |_________________|       |  DEĞER          |
       DEĞER                    |_________________|
                                 NESNE

Şekil 4-8
LIST ve üye nesneleri

_________________         _________________
      |  _____________  |       |  _____________  |
      | |      L      | |       | |             | |
      | |_____________| |       | |_____________| |
      |  AD             |       |  TÜR            |
      |  _____________  |       |  _____________  |
      | |         ____|_|______\| |             | |
      | |_____________| |      /| |__________|__| |
      |  AÇIKLAMA       |       |  ÇOCUK     |    |
      |  _____________  |/__     |____________|____|
      | |             | |\  |    AÇIKLAMA |
      | |_________|___| |   |    ____________V____
      |  DEĞER    |     |   |   |  _____________  |
      |___________|_____|   |   | |    STRING   | |/___
       NESNE     |         |   | |_____________| |\   |
                  |         |   |  TÜR            |    |
       ___________V_____    |   |_________________|    |
      |  _____________  |   |    AÇIKLAMA           |
      | |    "ABC"    | |   |    _________________     |
      | |_____________| |   |   |                 |    |
      |  _____________  |   |   |  _____________  |    |
      | |     "XY"    | |   |___|_|____         | |    |
      | |_____________| |       | |_____________| |    |
      |  _____________  |       |  LIST           |    |
      | |    "ZLM"    | |       |  _____________  |    |
      | |_____________| |       | |             | |    |
      |        :        |       | |_________|___| |    |
      |        :        |       |  ÜYE      |     |    |
      |  _____________  |       |     :     |     |    |
      | |    "BBBF"   |/|___    |     :     |     |    |
      | |_____________|\|   |   |___________|_____|    |
      |_________________|   |    OPD        |          |
       DEĞER                |    ___________V_____     |
                            |   |  _____________  |    |
                            |   | |      M      | |    |
                            |   | |_____________| |    |
                            |   |  AD             |    |
                            |   |  _____________  |    |
                            |   | |         ____|_|____|
                            |   | |_____________| |
                            |   |  AÇIKLAMA       |
                            |   |  _____________  |
                            |___|_|____         | |
                                | |_____________| |
         Şekil 4-9              |  DEĞER          |
    OPD, LIST ve üye            |_________________|
                                 NESNE

OPD, LIST ve Üye

OPD, nesne ilişkisini kurar ve yürütülmekte olan ilkel listops dizisi hakkında bilgi içerir. OPD içinde yeterli bilgi tutulduğunda, Şekil 4-9'da LIST'in ve küresel liste işleminin bütünlüğünün korunması için yeterli olan bir yapı elde edilir. LIST ve üye işaretçilerine ek olarak OPD, aşağıdakileri belirten bilgiler içerir:

1. dizi için hangi alt işlemlerin etkinleştirildiği,
2. geçerli alt işlem,
3. geçerli LIST üyesinin örnek numarası,
4. liste sonu göstergesi.

Alt işlemler add/member, delete/member, change/member ve get/member'dır. Hepsi geçerli üye üzerinde uygulanır. Yalnızca bir dizinin başında etkinleştirilmiş olan alt işlemler o dizi sırasında yürütülebilir; nihayetinde, bunun ima ettiği niyetlere dair önceden bilgi sahibi olma durumu, eşzamanlılık denetimi ve iyileştirme için önemli bilgiler sağlayacaktır.

Şu anda bir OPD, tek bir üye nesnesini tek bir LIST nesnesiyle ilişkilendirir. Bu, ifade edilebilecek işlem dizileri sınıfı üzerinde önemli bir kısıtlama getirir. Birden fazla üyeye eşzamanlı erişim gerektiren herhangi bir LIST dönüşümü, birden fazla dizi olarak temsil edilmelidir. (Ve her ikisi de tek bir süreç tarafından denetlense bile, bu tür dizilerin eşzamanlı yürütülmesinin ima ettiği sorunları henüz çözmüyoruz.)

Bir LIST'in herhangi bir dönüşümü, ara sonuçların geçici nesnelerde saklanmasıyla yine de gerçekleştirilebilir; ancak, dilin anlamsal yapısına birden fazla geçerli üye fikrini dâhil etmek, bu tür geçicileri kullanmaktan kesinlikle daha arzu edilir. Listops'un önemli bir gelecek genişletmesi bu sorunla ilgilenecektir.

Altı adet listops vardır: listop/begin, listop/end, which/member, end/of/list, open/member ve close/member.

Listop/begin ve Listop/end

Listop/begin ve listop/end, sırasıyla bir listops dizisini başlatma ve sonlandırma işlevlerini yerine getirir. Listop/begin, LIST ve üye nesnelerini, bir OPD'yi ve etkinleştirilecek alt işlemlerin bir belirtimini girdi olarak alır. OPD'yi başlatır; buna LIST ve ÜYE nesnelerine bağlantıların kurulması da dahildir. OPD–LIST–üye ilişkisi kurulduktan sonra, dizideki bir listop için yalnızca OPD'nin ve yardımcı parametrelerin girdi olarak sağlanması yeterlidir. Geriye kalan her şey OPD'den türetilebilir.

Listop/end, OPD'yi temizler ve listop/begin tarafından edinilmiş tüm kaynakları serbest bırakır.

Which/member

Which/member, herhangi bir alt işlem için geçerli üyeyi belirler. Bu, ilk LIST üyesi, son LIST üyesi veya bir sonraki LIST üyesi olabilir. Bu listop yalnızca hangi üye üzerinde işlem yapılacağını tanımlar; üyenin içeriğini erişilebilir hâle getirmez.

Open/member ve Close/member

Open/member ve close/member parantezleri bir alt işlemi sınırlar. Alt işlem, open/member için bir argüman olarak belirtilir. Open/member her zaman üye nesnesinden üye değerine bir işaretçi kurar; close/member ise bu işaretçiyi her zaman temizler. Ayrıca, bu listopların her biri, alt işleme bağlı olarak bazı eylemler gerçekleştirebilir.

Eylemin ayrıntıları, LIST’in depolamadaki gösterimine, bir LIST üyesinin boyutuna ve uygulamada yapılan seçimlere bağlıdır.

Open/member ile close/member’in yürütülmesi arasındaki sürede veriye erişilebilir. Her zaman okunabilir; add/member ve change/member alt işlemleri durumunda ayrıca yazılabilir.

End/of/list

End/of/list, OPD içindeki bir bayrağı sınar ve BOOL türünde bir nesne döndürür. Nesnenin değeri bayrağın değeriyle aynıdır; bir get/member, change/member veya delete/member işlemi, which/member’in "sonun ötesine" taşınmış olması nedeniyle başarısız olacaksa TRUE olur. Bu listop, tüm üyeler işlendiğinde koşullu olarak sonlanan yordamlar yazılabilmesini sağlamak için sağlanmıştır.

Get/struct/member

Get/struct/member, STRUCT’lerin ele alınabilmesini sağlar. STRUCT değerine işaret eden bir STRUCT nesnesi verildiğinde, verilen bir üye nesnesinden üye değerine bir işaretçi kurar. (Kurulan işaretçi Şekil 4-10’da kesik çizgiyle gösterilmiştir.)

 _________________         _________________
|  _____________  |       |  _____________  |
| |      F      | |       | |   STRUCT    | |
| |_____________| |       | |_____________| |
|  NAME           |       |  TYPE           |
|  _____________  |       |  _____________  |
| |         ____|_|______\| |             | |
| |_____________| |      /| |__________|__| |
|  DESCRIPTION    |       |  CHILD     |    |
|  _____________  |       |____________|____|
| |             | |        DESCRIPTION |
| |___________|_| |        ____________V____         _________________
|  VALUE      |   |       |  _____________  |       |  _____________  |
|  ___________|_  |       | |    STRING   | |       | |    STRING   | |
| |           | | |       | |_____________| |       | |_____________| |
| |_________|_|_| |       |  TYPE           |       |  TYPE           |
|  CHILD    | |   |       |  _____________  |       |  _____________  |
|___________|_|___|  ____\| |             | |       | |             | |
 OBJECT     | |     |    /| |_____________| |       | |_____________| |
            | |     |     |  SIBLING        |       |  SIBLING        |
            | |     |     |_________________|       |_________________|
            | |     |      DESCRIPTION               DESCRIPTION    A
            | |     |      ______________________________________   |
            | |     |     |  ____________          ____________  |  |
            | |     |     | |    "ABC"   |        |    FALSE   | |  |
            | |_____|_____| |____________|        |____________| |  |
            |       |     |________A_____________________________|  |
            |       |  ............:                        VALUE   |
 ___________V_____  |  :   _________________                        |
|  _____________  | |  :  |  _____________  |                       |
| |      A      | | |  :  | |      B      | |                       |
| |_____________| | |  :  | |_____________| |                       |
|  NAME           | |  :  |  NAME           |                       |
|  _____________  | |  :  |  _____________  |                       |
| |         ____|_|_|  :  | |         ____|_|_______________________|
| |_____________| |    :  | |_____________| |
|  DESCRIPTION    |    :  |  DESCRIPTION    |
|  _____________  |    :  |  _____________  |
| |         ....|.|....:  | |             | |
| |_____________| |       | |_____________| |
|  VALUE          |       |  VALUE          |
|  _____________  |       |  _____________  |
| |         ____|_|______\| |             | |
| |_____________| |      /| |_____________| |
|  SIBLING        |       |  SIBLING        |
|_________________|       |_________________|
 OBJECT                    OBJECT

        Figure 4-10
 Effect of GET/STRUCT/MEMBER

Kontrol ve Seçim Olanakları

Şimdiye kadar tartışılan ilkel öğeler (assign, listops ve get/struct/member), LIST’ler, STRUCT’ler ve temel öğelerden oluşan yapılar üzerinde işlem yapmak için temel bir olanak sağlar. Yalnızca bunlar kullanılarak, bir hiyerarşik yapının içeriğini başka birine aktarmak, yapıları eklemek, yapıların bölümlerini silmek vb. mümkündür. Daha ilginç işlemler gerçekleştirmek için kontrol ve seçim olanaklarına ihtiyaç vardır.

İlkel if/then, if/then/else, till ve while aracılığıyla basit bir kontrol olanağı sağlanır. Bunların tümü, bir BOOL döndürmesi gereken tek bir ilkel fonksiyon çağrısını değerlendirir. Bu BOOL’un değerine bağlı olarak bazı eylemler gerçekleştirilir.

A ve B fonksiyon çağrıları olsun. If/then(A,B), A TRUE döndürürse B’yi yürütür. If/then/else(A,B,C), A TRUE döndürürse B’yi; A FALSE döndürürse C’yi yürütür. While ve till işleçleri yineleme yapar; önce A, sonra B yürütülür. While, A FALSE döndürdüğünde döngüyü sonlandırır; till ise A TRUE döndürdüğünde döngüyü sonlandırır. Bu durum ilk seferde gerçekleşirse, B hiç yürütülmez.

Şimdiye kadar BOOL döndüren bir fonksiyondan bahsettik: listop end/of/list. Bu özelliğe sahip iki başka fonksiyon sınıfı daha vardır: boolean’lar ve karşılaştırmalar. Üç ilkel boolean (and, or, not) ve altı ilkel karşılaştırma vardır (equal, less/than, greater/than, not/equal, less/than/or/equal, greater/than/or/equal — yayın sırasında yalnızca equal uygulanmıştır).

Boolean’lar BOOL girdileri alır ve BOOL çıktıları üretir; karşılaştırmalar ise aynı tanıma sahip temel nesne çiftlerini girdi olarak alır ve BOOL çıktıları üretir. Öğelerin içerikleri üzerinde boolean’lar ve karşılaştırmalardan oluşan ifadeler, veri yönetim sistemlerinde veriye seçici olarak başvurmak için kullanılan temel araçlardan biridir.

Boolean’lar, karşılaştırmalar ve daha önce tanımlanan ilkel öğelerle birlikte seçici "erişimler" gerçekleştirebiliriz. Yani, değeri 'ABC' olan LIST A’daki tüm öğeleri LIST B’ye aktarabiliriz. Aslında artık, anlamsal olarak genel bir biçimde, keyfi hiyerarşik yapılar üzerinde içerik temelli erişimler ve güncellemeler yapabilme yeteneğine sahibiz. Hatta, iş veri işleme alanındaki tipik uygulamalardan biri olan, bir ana listeye karşı işlem listesinin işlenmesi kadar karmaşık bir şeyi bile programlayabiliriz.

Elbette, datalanguage kullanıcılarının istekleri listop düzeyinde ifade etmelerini beklemeyiz. Ayrıca, burada tanımlanan listoplar, bahsettiğimiz bazı görevleri yerine getirmek için çok verimli bir yol değildir. İyi çözümler elde etmek için hem daha üst düzey işleçlere hem de işlemede başka teknikler kullanan diğer ilkel öğelere ihtiyaç vardır.

Ek Model Fonksiyonları

Daha önce tartışılanlara ek olarak, model şu işlevleri içeren fonksiyonlar barındırır:

1. nitelikli adla bir nesneye başvurma,
2. sabit üretme,
3. veri tanımları üretme,
4. yerel değişkenlere sahip bileşik fonksiyonlar ve bloklar yazma,
5. nesne oluşturma.

Sabitlerin ve veri tanımlarının (özel bir sabit durumu olan) üretilmesine yönelik olanaklar sınırlıdır ve özel bir ilgi uyandıran özelliklere sahip değildir. Açıkça, veri tanımı ilerideki modelleme çalışmasında önemli bir konu olacaktır.

Nesneye başvurma fonksiyonları, t/objects ve p/objects’e başvurulmasına izin verir (bu terimler 4.6’da tanımlanmıştır). Bir p/object, STAR’dan ona giden yol adı verilerek belirtilir. Bir t/object ise, tanımlandığı blok dizininden ona giden yol adı verilerek belirtilir.

Compound/function, bir dizi fonksiyon çağrısının sözdizimsel olarak tek bir çağrı gibi ele alınmasını sağlar. Örneğin, if/then(A,B) içinde B çoğu zaman compound/function’a yapılan bir çağrıdır ve bu da sırasıyla başka fonksiyon çağrılarını gerçekleştirir.

Create iki girdi alır: bir üst nesne ve bir tanım. Üst nesne bir dizin olmalıdır. Yeni nesne dizinin en soldaki çocuğu olarak oluşturulur; adı tanım tarafından belirlenir.

4.8 İlkel Dil Fonksiyonlarının Ayrıntıları

Bu bölüm, önceki bölümde tartışılan ilkel öğeler için özellikler sunar. Genel ilgi taşımadığını düşündüğümüz ayrıntıları hâlâ atlıyoruz; amaç, okuyucunun örnekleri inceleyebilmesi için yeterli bilgiyi sağlamaktır.

İlkel öğelerin çoğu modelde iki düzeyde bulunur. İçsel ilkel öğelere i/functions, dışsal ya da dil ilkel öğelerine ise l/functions denir. Bu iki tür arasındaki ilişki 4.9’da açıklanmaktadır. Bu bölümde i/functions ele alınmaktadır.

L/functions, uç düğümleri atom olan ağaç yapıları biçimindeki form’ları girdi olarak alır ve çıktı olarak verir. Atomlar; fonksiyon adları, nesne adları, değişmez dizge sabitleri, doğruluk değerleri ve ayırıcılardan oluşur. I/functions çağrıları da form’lar olarak ifade edilir.

Herhangi bir form değerlendirilebilir ve bir nesne üretir. Bir fonksiyon çağrısı olan form, fonksiyon tarafından döndürülen değeri verir: başka bir form. Genel olarak, bir fonksiyon çağrısının döndürdüğü form değerlendirildiğinde bir datalanguage nesnesi üretir (yani çizimlerde "nesne kutusu" ile temsil ettiğimiz türden bir nesne).

4.8.1 Ad tanıma fonksiyonları

Bunlar, değerlendirildiğinde bir nesne üreten bir form döndürür.

L/TOBJ

Girdi, TOP/LEVEL’a ya da bir blok dizinine bağlı geçici bir nesneyi adlandırmalıdır.

L/POBJ

Girdi, kalıcı bir nesneyi (yani STAR’a bağlı bir nesneyi) adlandırmalıdır.

Tipik çağrılar L/POBJ(X.Y.Z) ve L/TOBJ(A) şeklindedir.

4.8.2 Sabit üreticiler

Bunların her biri, oluşturulacak bir sabit için bir değer sağlayan atomik bir sembolü girdi olarak alır. Her biri, belirtilen değere ve uygun bir tanıma sahip bir nesneye değerlendirilecek bir form döndürür.

LC/STRING

Tipik bir çağrı LC/STRING('ABC') şeklindedir.

LC/BOOL

Tipik bir çağrı LC/BOOL(TRUE) şeklindedir.

4.8.3 Temel öğe fonksiyonları

Bunlar, temel nesnelere değerlendirilen formları girdi olarak alır ve çıktı olarak verir (alt nesnesi olamayan nesneler—etkili olarak değeri atomik kabul edilen nesneler). Zamanla tüm karşılaştırma işleçleri uygulanacaktır.

L/ASSIGN

Girdiler STRING ya da BOOL’lara değerlendirilmelidir. Çıktı olarak, ikinci girdinin değerini birinciye aktaran bir form üretir.

Tipik çağrı:

L/ASSIGN(L/TOBJ(A),LC/STRING('XYZ'))

Çıktı formu değerlendirildiğinde, 'XYZ' değeri A’nın değerine kopyalanır.

L/EQUAL

Aynı tanıma sahip ve BOOL ya da STRING olan nesnelere değerlendirilen bir çift formu girdi olarak alır. BOOL türünde bir nesneye değerlendirilen bir form döndürür. Girdilerin tanımları ve değerleri özdeşse nesnenin değeri TRUE, aksi halde FALSE’tur.

Tipik çağrı:

L/EQUAL(L/TOBJ(X),LC/STRING('DEF'))

L/AND, L/OR, L/NOT

Standart boolean işleçler. Girdiler BOOL’lara değerlendirilen formlardır; çıktı BOOL’a değerlendirilen bir formdur. L/AND ve L/OR iki girdi alır; L/NOT ise bir girdi alır.

Tipik çağrı:

L/AND(
    L/EQUAL(L/TOBJ(X),LC/STRING('DEF')),
    L/EQUAL(L/TOBJ(Y),LC/STRING('GHI'))
)

Döndürülen form değerlendirildiğinde, hem X’in değeri 'DEF' hem de Y’nin değeri 'GHI' ise TRUE döndürür.

4.8.4 Veri tanımı fonksiyonları

Bunların tümü, bir tanıma değerlendirilen bir form döndürür (yani çizimlerimizde "description" etiketli bir kutu ile temsil edilen şeye).

LD/STRING

Dizge için adı, boyut seçeneğini ve boyutu belirten üç parametre alır.

Tipik çağrı:

LD/STRING(X,FIXED,3)

Bu çağrı, X adlı sabit uzunluklu 3 karakterli bir dizge için bir tanıma değerlendirilen bir form döndürür.

LD/LIST

İki form alır. Birincisi LIST’in adıdır, ikincisi ise LIST üyesinin tanımına değerlendirilen bir formdur.

Tipik çağrı:

LD/LIST(L,LD/STRING(M,FIXED,3))

Şekil 4-11’de gösterilen yapıyı meydana getirir ve üstteki kutu ile temsil edilen tanıma değerlendirilen bir form döndürür.

Şekil 4-11
LIST ve üye tanımları

LD/STRUCT

STRUCT için ad olarak kullanılacak bir form ve tanımlara değerlendirilen bir ya da daha fazla form alır; bunlar üyelerin tanımları olarak kabul edilir.

Tipik çağrı:

LD/STRUCT(R,
    LD/STRING(A,FIXED,3)
    LD/BOOL(B)
)

Şekil 4-12’de gösterilen yapıyı üretir; en üstteki kutuya değerlendirilen bir form döndürür.

Şekil 4-12
STRUCT ve üye tanımları

LD/BOOL, LD/DIR, LD/OPD, LD/FUNC, LD/DESC

Her biri bir ad alır ve tek bir tanım üretir; her biri, üretilen tanıma değerlendirilen bir form döndürür.

Tipik çağrı:

LD/BOOL(X)

4.8.5 Veri oluşturma

L/CREATE

İki form alır ve bunları değerlendirir. İlki DIR türünde bir nesne üretmelidir; ikincisi ise oluşturulacak nesne için bir tanım üretmelidir. Nesneyi oluşturur ve değerlendirildiğinde yeni nesne için bir değer üretecek bir form döndürür.

Basit bir örnek:

L/CREATE(L/TOBJ(X),LD/BOOL(Y))

Şekil 4-13, yukarıdaki çağrının yürütülmesinden önce X dizinini göstermektedir. Yalnızca bir OPD içerir. Yürütmeden sonra dizin, Şekil 4-14’teki gibi görünür. Y için bir değerin oluşturulması, L/CREATE tarafından döndürülen form değerlendirildiğinde gerçekleşir (4.9 Bölümünde ele alınmaktadır).

Şekil 4-13
Y oluşturulmadan önce X ve Z

Şekil 4-14
L/CREATE sonrasında X, Y ve Z

4.8.6 Kontrol

L/IF/THEN, L/IF/THEN/ELSE

Bir formun koşullu olarak değerlendirilmesini istemek için kullanılır.

Tipik çağrı:

L/IF/THEN(
    L/EQUAL(L/TOBJ(A),LC/STRING('ABC')),
    L/ASSIGN(L/TOBJ(B),LC/STRING('DE'))
)

Döndürülen form değerlendirildiğinde şunu yapar: A’nın değeri 'ABC' ise, 'DE' değerini B’nin değerine yazar.

L/WHILE, L/TILL

Bunlar, önceki bölümde açıklandığı gibi koşullu yineleme yapar. Örnekler ileride verilecektir.

L/CF

Bileşik fonksiyon: Bir ya da daha fazla form alır ve değerlendirildiğinde her girdiyi sırayla değerlendirecek bir form döndürür.

Tipik çağrı:

L/CF(
    L/ASSIGN(L/TOBJ(R.A),LC/STRING('XX')),
    L/ASSIGN(L/TOBJ(R.B),LC/STRING('YY'))
)

L/CF’nin çıktısı değerlendirildiğinde, R.A ve R.B için yeni değerler atanır.

4.8.7 Listoplar

Bu ilkel öğeler, LIST’ler üzerinde işlemler gerçekleştirmek için diziler hâlinde yürütülür. L/END/OF/LIST istisnası dışında, bu fonksiyonlar yalnızca etki için değerlendirilen formlar üretir; yani çıktı formlarının kendileri değer döndürmez.

L/LISTOP/BEGIN

Aşağıdakilere değerlendirilen formları girdi olarak alır:

1. bir LIST,
2. geçerli LIST üyesini temsil edecek bir nesne,
3. bir OPD.

Ayrıca, değerleri etkinleştirilecek alt işlemler olarak alınan atomik formlardan oluşan bir liste alır.

Tipik çağrı:

L/LISTOP/BEGIN(
    L/POBJ(F),
    L/TOBJ(R),
    L/TOBJ(OPF),
    ADD,
    DELETE
)

Bu çağrı, F üzerinde gerçekleştirilecek listoplar dizisini başlatacak bir form döndürür. Çağıran, daha önce R ve OPF’yi oluşturmuştur. LIST üyelerini ADD ve DELETE etmeyi amaçlamaktadır.

Bu listoplar dizisindeki sonraki tüm çağrıların yalnızca OPD’yi ve yardımcı parametreleri belirtmesi yeterlidir.

L/LISTOP/END

Bir OPD’ye değerlendirilen bir formu girdi olarak alır. Değerlendirildiğinde OPD’yi temizleyen ve OPD, LIST ve üye nesneleri arasındaki ilişkileri koparan bir form çıktısı verir.

L/WHICH/MEMBER

İki form girdi olarak alınır. Birincisi bir OPD’ye değerlendirilir; ikincisi FIRST, LAST veya NEXT değerlerinden biridir. Çıktı olan form değerlendirildiğinde, bir sonraki alt işlem için yeni bir geçerli üye belirler.

Not: Bu işlem üyenin değerini erişilebilir hâle getirmez; yalnızca OPD içindeki örnek numarasını ayarlayarak onu tanımlar.

Tipik çağrı:

L/WHICH/MEMBER(L/TOBJ(OPF),NEXT)

Bir WHICH/MEMBER işlemi listenin sonunun ötesine ilerlemeye neden olduğunda, OPD içinde bir bayrak ayarlanır.

L/END/OF/LIST

Bir OPD’ye değerlendirilen bir formu girdi olarak alır. Değerlendirildiğinde bir BOOL döndüren bir form çıktısı verir. OPD içindeki liste-sonu bayrağı açıksa bunun değeri TRUE olur.

L/OPEN/MEMBER

Bir OPD’ye değerlendirilen bir formu ve ADD, DELETE, GET veya CHANGE değerlerinden biri olmak zorunda olan bir formu girdi olarak alır. Değerlendirildiğinde, geçerli LIST üyesi üzerinde istenen alt işlemi başlatacak bir form çıktısı verir.

Alt işlem her zaman üye nesnesinden geçerli üye değer örneğine bir işaretçi kurar. Buna ek olarak, ADD durumunda bu değerin oluşturulması gerekir.

Tipik çağrı:

L/OPEN/MEMBER(L/TOBJ(OPF),ADD)

L/CLOSE/MEMBER

Bir OPD’ye değerlendirilen bir formu girdi olarak alır. Değerlendirildiğinde, devam etmekte olan alt işlemi tamamlayan bir form çıktısı verir. Tipik bir çağrı:

L/CLOSE/MEMBER(L/TOBJ(OPF))

Her zaman üye nesnesinden üye değerine olan işaretçiyi temizler. Ayrıca, DELETE durumunda üye değerini LIST’ten kaldırır. ADD durumunda ise üye değerini LIST’e ekler. Eklenen üyeyi geçerli üye yapar; böylece araya WHICH/MEMBER çağrıları girmeden yürütülen bir ADD dizisi, yeni üyeleri sıralı biçimde ekler.

Listops ve birkaç başka ilkel işlemi içeren ayrıntılı bir örnek bölüm 4.10’da yer almaktadır.

4.9 Yürütme döngüsü

Model databilgisayarın iki parçalı bir yürütme döngüsü vardır: önce istekleri derler, sonra bunları yorumlar. Bir “istek” bir l/function çağrısıdır; “derleme” ise istekte yer alan tüm l/function çağrılarını yürütmenin toplam sonucudur (genellikle bu birçok çağrıdır; çünkü çoğu zaman iç içe geçmiş birkaç çağrı seviyesi vardır ve içteki çağrıların sonuçları bir sonraki seviye çağrılara argüman olarak iletilir). Genellikle bir l/function yürütme süreci, bağlama, denetleme ve (sonuçta) iyileştirme ile önceleyen basit bir makro açılımını içerir.

Derlenmiş biçim bütünüyle atomik semboller ve i/function çağrılarından oluşur. i/function’lar, datadil nesnelerini (çizimlerde “object” etiketli kutularla gösterilen varlıklar) girdi olarak alan ve çıktı olarak veren içsel ilkel işlemlerdir.

Tartışılan l/function’ların her biri tek bir i/function’a derlenir; dolayısıyla derlemenin makro açılım yönü şu an için önemsizdir. Ancak genel olarak bu doğru olmayacaktır; bunun şu anda geçerli olmasının tek nedeni, bunların ilkel l/function’lar olmasıdır.

Derle-ve-yorumla döngüsünü kullanma kararı bir miktar açıklama gerektirir. Bunu anlamanın yolu, katı biçimde yorumlayıcı bir sistemde gerçekleştirilecek işlevler açısından düşünmektir. Yürütmenin herhangi bir bölümünden önce, isteğin geçerliliğine ilişkin küresel denetimlerin yapılması gereksinimi yine de olacaktır. Bunun nedeni, hatalı bir isteğin kısmi yürütülmesinin bir veritabanını tutarsız bir duruma sokabilmesidir; bu büyük veya karmaşık bir veritabanıysa, geri kazanım maliyeti oldukça yüksek olacaktır. Bu nedenle, mümkün olan en fazla denetimi yapmak faydalıdır; sistem tam olarak geliştirildiğinde, bu yürütme akışına ilişkin belirli ölçüde basit öngörüyü de içerecektir; her hâlükârda, salt sözdizimsel denetimden çok daha fazlası kastedilmektedir.

Bu tür küresel denetimlerin tümü gerçek yürütmeden önce yapılacağından, belirli bir form için bunlar fiilen yürütmenin bir parçası değildir. Bunları ayrı bir derleme sürecinin parçası olarak gerçekleştirmek, zaten fiilen var olan bir modülerliği yalnızca resmileştirir.

Bununla birlikte, bazı durumlarda denetleme, bağlama ve iyileştirme işlevlerinin —eğer yapılacaklarsa— yorumlama sırasında yürütülmesi gerekecektir. Bu, gerekli bilginin bazı verilere erişilene kadar mevcut olmadığı durumlarda ortaya çıkar. Pratik olduğunda, bu tür durumlar için çoğu işlevi döngünün her iki “yarısı”nın da parçası olarak yürütülebilecek şekilde tasarlayarak çözüm sağlamayı amaçlıyoruz.

Model geliştikçe, bu sorun hakkında daha iyi bir sezgi edinmeyi bekliyoruz; sonuçta, derleme ve yorumlamanın birçok döngüsünün bulunduğu, hatta döngüler içinde döngülerin iç içe geçtiği bir yapı ile sonuçlanmak son derece makuldür.

4.10 LIST’ler üzerinde işlemlere örnekler

Burada, ilkel l/function’ları kullanarak bir LIST üzerinde yapılan bir işlemin örneğini geliştiriyoruz. Önce F adlı bir LIST’i oluşturmak ve ona birkaç üye değeri vermek için gereken function çağrılarını gösteriyoruz. Daha sonra belirli üyeleri seçerek ikinci bir LIST olan G’ye kopyalıyoruz.

F’yi oluşturmak için:

L/CREATE("STAR",LD/LIST(F,
                        LD/STRUCT(R,
                                LD/STRING(A,FIXED,2),
                                LD/STRING(B,FIXED,2))))

Bu çağrı, F’yi kalıcı dizin STAR’ın bir üyesi olarak oluşturur (STAR hakkında ayrıntılar için bölüm 4.6’ya bakınız). STAR sembolü “dil” içinde özel bir statüye sahiptir; doğrudan bir nesneye değerlendirilen az sayıdaki atomik sembolden biridir. (Çoğu kalıcı nesnenin L/POBJ çağrısı yoluyla referans alındığını hatırlayın; STAR sembolünü ayırmak, STAR’ı bir ad olarak ayırmaya ve L/POBJ(STAR) yazmaya denktir. Burada seçtiğimiz çözüm yazımı daha kolaydır.) Bu çağrının yürütülmesi Şekil 4-15’te gösterilen yapıyı kurar (çağrıdan önce var olan STAR hariç). F için başlangıçta oluşturulan değer, boş bir LIST’tir — sıfır üyeli bir LIST.

Şekil 4-15. Oluşturulduktan hemen sonra F

F’ye üye eklemek için listops kullanmamız gerekir ve bunun için iki nesne daha oluşturmamız gerekir: geçerli üyeyi temsil edecek bir nesne ve bir işlem tanımlayıcısı (OPD). Bunlar kalıcı nesneler değil, geçici nesnelerdir; ayrıca “üst seviye”dirler (yani bir isteğe yerel değildirler). Geçici, üst seviye nesneler TOP/LEVEL dizininin üyeleri olarak oluşturulur. Bunları oluşturmak için yapılan çağrılar şunlardır:

L/CREATE(L/TOBJ(TOP/LEVEL),
                    LD/STRUCT(M,
                            LD/STRING(A,FIXED,2),
                            LD/STRING(B,FIXED,2)))

L/CREATE(L/TOBJ(TOP/LEVEL),LD/OPD(OPF))

M’yi geçerli üyeyi temsil etmesi için oluşturuyoruz; tanımı, F’nin bir üyesi için girilen tanımla aynıdır (F’yi oluşturan çağrıya bakınız). Bunu gerçekleştirmenin doğru yolu, gerçek LIST üye tanımını M ile paylaşan bir mekanizmadır; ancak bu mekanizma modelimizde henüz mevcut değildir.

Şimdi F’ye bazı veriler eklemek istiyoruz; her üye, iki adet iki karakterli STRING içeren bir STRUCT olacaktır.

Listop dizisini başlatmak için:

L/LISTOP/BEGIN(L/POBJ(F),L/TOBJ(M),
                        L/TOBJ(OPF),ADD)

Bu çağrı Şekil 4-16’da gösterilen yapıyı kurar. OPD’yi başlatır; onu F ve M’ye işaret edecek şekilde ayarlar ve yalnızca ADD alt işleminin etkin olduğunu kaydeder.

Şekil 4-16. L/BEGIN/LISTOP sonrasında F, OPF ve M

Sonraki adımda geçerli bir üye belirlememiz gerekir. Üyeleri sona eklemek istiyoruz (bu durumda LIST boş olduğu için herhangi bir yere eklemek aynı etkiyi verecektir); bu da LAST’i geçerli üye yaparak gerçekleştirilir.

L/WHICH/MEMBER(L/TOBJ(OP1),LAST)

Şimdi F’ye yeni bir üye eklemek için aşağıdakileri yürütebiliriz:

L/OPEN/MEMBER(L/TOBJ(OPF),ADD)
L/ASSIGN(L/TOBJ(M.A),LC/STRING('AB'))
L/ASSIGN(L/TOBJ(M.B),LC/STRING('CD'))
L/CLOSE/MEMBER(L/TOBJ(OPF))

L/OPEN/MEMBER, M için bir STRUCT değeri oluşturur. F’nin değerini etkilemez. STRUCT değerin her bir üyesi, STRUCT oluşturulduğunda başlatılır. Sonuç Şekil 4-17’de gösterilmiştir; STRUCT üye değerlerinin henüz M.A ve M.B nesneleriyle ilişkili olmadığına dikkat ediniz.

Şekil 4-18, ilk L/ASSIGN ile gerçekleştirilen değişiklikleri gösterir; M.A nesnesinden değere olan işaretçi, L/TOBJ(M.A) tarafından derlenen bir GET/STRUCT/MEMBER ile kurulmuştur. Değer, atama işleci tarafından doldurulmuştur. İkinci atama benzer bir etki yaparak ikinci değeri doldurur. L/CLOSE/MEMBER çağrısı, Şekil 4-18’de M için gösterilen değeri (ikinci üye değeri doldurulmuş hâliyle) alır ve bunu F’nin değerine ekler. Sonuç Şekil 4-19’da gösterilmiştir; Şekil 4-16 ile karşılaştırınız.

Şekil 4-17

L/OPEN/MEMBER sonrasında

_________________         _________________
|  _____________  |       |  _____________  |
| |      M      | |       | |    STRUC    | |
| |_____________| |       | |_____________| |
|  NAME           |       |  TYPE           |
|  _____________  |       |  _____________  |
| |         ____|_|______\| |             | |
| |_____________| |      /| |__________|__| |
|  DESCRIPTION    |       |  CHILD     |    |
|  _____________  |       |____________|____|
 _____|_|____         | |        DESCRIPTION |
|     | |_____________| |                    |
|     |  VALUE          |        ____________V____
|     |  _____________  |       |  _____________  |
|     | |             | |       | |    STRING   | |
|     | |_________|___| |       | |_____________| |
|     |  CHILD    |     |   ___\|  TYPE           |        _____________
|     |___________|_____|  |   /|  _____________  |       |  _________  |
|      OBJECT     |        |    | |         ____|_|______\| | STRING  | |
|                 |        |    | |_____________| |      /| |_________| |
|      ___________V_____   |    |  SIBLING        |       |  TYPE       |
|     |  _____________  |  |    |_________________|       |_____________|
|     | |      A      | |  |     DESCRIPTION           DESCRIPTION    A
|     | |_____________| |  |                                          |
|     |  NAME           |  |     _________________                    |
|     |  _____________  |  |    |  _____________  |                   |
|     | |         ____|_|__|    | |      B      | |                   |
|     | |_____________| |       | |_____________| |                   |
|     |  DESCRIPTION    |       |  NAME           |                   |
|     |  _____________  |       |  _____________  |                   |
|     | |             | |       | |         ____|_|___________________|
|     | |_____________| |       | |_____________| |
|     |  VALUE          |       |  DESCRIPTION    |
|     |  _____________  |       |  _____________  |
|     | |         ____|_|______\| |             | |
|     | |_____________| |      /| |_____________| |
|     |  SIBLING        |       |  VALUE          |
|     |_________________|       |_________________|
|      OBJECT                    OBJECT
|___________________________
                            |
       _____________________V____________________
      |  _____________            _____________  |
      | |             |          |             | |
      | |_____________|          |_____________| |
      |__________________________________________|
       VALUE

Şekil 4-18

İlk L/ASSIGN sonrasında

_________________         _________________
|  _____________  |       |  _____________  |
| |      M      | |       | |    STRUC    | |
| |_____________| |       | |_____________| |
|  NAME           |       |  TYPE           |
|  _____________  |       |  _____________  |
| |         ____|_|______\| |             | |
| |_____________| |      /| |__________|__| |
|  DESCRIPTION    |       |  CHILD     |    |
|  _____________  |       |____________|____|
 _____|_|____         | |        DESCRIPTION |
|     | |_____________| |                    |
|     |  VALUE          |        ____________V____
|     |  _____________  |       |  _____________  |
|     | |             | |       | |    STRING   | |
|     | |_________|___| |       | |_____________| |
|     |  CHILD    |     |   ___\|  TYPE           |        _____________
|     |___________|_____|  |   /|  _____________  |       |  _________  |
|      OBJECT     |        |    | |         ____|_|______\| | STRING  | |
|                 |        |    | |_____________| |      /| |_________| |
|      ___________V_____   |    |  SIBLING        |       |  TYPE       |
|     |  _____________  |  |    |_________________|       |_____________|
|     | |      A      | |  |     DESCRIPTION           DESCRIPTION    A
|     | |_____________| |  |                                          |
|     |  NAME           |  |     _________________                    |
|     |  _____________  |  |    |  _____________  |                   |
|     | |         ____|_|__|    | |      B      | |                   |
|     | |_____________| |       | |_____________| |                   |
|     |  DESCRIPTION    |       |  NAME           |                   |
|     |  _____________  |       |  _____________  |                   |
|   __|_|____         | |       | |         ____|_|___________________|
|  |  | |_____________| |       | |_____________| |
|  |  |  VALUE          |       |  DESCRIPTION    |
|  |  |  _____________  |       |  _____________  |
|  |  | |         ____|_|______\| |             | |
|  |  | |_____________| |      /| |_____________| |
|  |  |  SIBLING        |       |  VALUE          |
|  |  |_________________|       |_________________|
|  |  OBJECT                    OBJECT
|  |___________
|              |
|      ________|_________________________________
|     |  ______V______            _____________  |
|____\| |   "AB"      |          |             | |
     /| |_____________|          |_____________| |
      |__________________________________________|
       VALUE

Şekil 4-19

L/CLOSE/MEMBER sonrasında

_________________
|  _____________  |
| |     STAR    | |
| |_____________| |
|  AD             |
|  _____________  |
| |             | |
| |_________|___| |
|  ÇOCUK    |     |
|___________|_____|
 NESNE      |
 ___________V_____
|  _____________  |
| |      F      | |/______|_|____         | |
| |_____________| |\      | |_____________| |
|  AD             |       |  LİSTE          |
|  _____________  |       |  _____________  |
| |             | |       | |             | |
| |_________|___| |       | |___________|_| |
|  DEĞER    |     |       |  ÜYE        |   |
|___________|_____|       |_____________|___|
 NESNE      |              DEĞER        | OPD
            |              _____________V___
____________V_________    |  _____________  |
| ______________________ |   | |      M      | |
|| _________  _________ ||   | |_____________| |
|||  "AB"   ||  "CD"   |||   |  AD             |
|||_________||_________|||   |  _____________  |
||______________________||   | |             | |
|                 /      |   | |___________|_| |
|                /       |   |_____________|___|
|_______________/________|    NESNE        |
 DEĞER         /       /      _____________V___        _________________
              /       /      |  _____________  |      |  _____________  |
             /       /       | |             | |      | |      B      | |
            /      LİSTE     | |_____________| |      | |_____________| |
           /                 |  AD             |      |  AD             |
          /                  |  _____________  |      |  _____________  |
 YENİ ÜYE DEĞERİ              | |         ____|_|_____\| |             | |
                             | |_____________| |     /| |_____________| |
                             |_________________|      |_________________|
                              NESNE                   NESNE

LİSTE F’nin Oluşturulması

Yalnızca sabitlerin değerlerini değiştirerek, benzer dört ilkelden oluşan grupları çalıştırarak, Şekil 4-20’de gösterilen LİSTE F’yi oluşturabiliriz. Gerekli çağrılar aşağıda gösterilmiştir:

L/OPEN/MEMBER(L/TOBJ(OPF),ADD)
L/ASSIGN(L/TOBJ(M.A),LC/STRING('FF'))
L/ASSIGN(L/TOBJ(M.B),LC/STRING('GH'))
L/CLOSE/MEMBER(L/TOBJ(OPF))

L/OPEN/MEMBER(L/TOBJ(OPF),ADD)
L/ASSIGN(L/TOBJ(M.A),LC/STRING('AB'))
L/ASSIGN(L/TOBJ(M.B),LC/STRING('IJ'))
L/CLOSE/MEMBER(L/TOBJ(OPF))

L/OPEN/MEMBER(L/TOBJ(OPF),ADD)
L/ASSIGN(L/TOBJ(M.A),LC/STRING('CD'))
L/ASSIGN(L/TOBJ(M.B),LC/STRING('LM'))
L/CLOSE/MEMBER(L/TOBJ(OPF))

Add alt işlemi, yeni eklenen üyenin geçerli üye yapılması etkisine sahiptir; dolayısıyla bu dizide L/WHICH/MEMBER çağrılarına gerek yoktur.

Liste işlemleri dizisini sonlandırmak için:

L/END/LISTOP(L/TOBJ(OPF))

Şekil 4-20

L/END/LISTOP Sonrası

_________________
|  _____________  |
| |      F      | |
| |_____________| |
|  AD             |
|  _____________  |
| |         ____|_|_________\
| |_____________| |         /
|  AÇIKLAMA       |
|  _____________  |
| |             | |
| |_________|___| |
|  DEĞER    |     |
|___________|_____|
 NESNE      |
            |
____________V______________
|  __________________________  |
| |  _________    _________  | |
| | |         |  |         | | |
| | |  "AB"   |  |  "CD"   | | |
| | |_________|  |_________| | |
| |__________________________| |
|  __________________________  |
| |  _________    _________  | |
| | |         |  |         | | |
| | |  "EF"   |  |  "GH"   | | |
| | |_________|  |_________| | |
| |__________________________| |
|  __________________________  |
| |  _________    _________  | |
| | |         |  |         | | |
| | |  "AB"   |  |  "IJ"   | | |
| | |_________|  |_________| | |
| |__________________________| |
|  __________________________  |
| |  _________    _________  | |
| | |         |  |         | | |
| | |  "CD"   |  |  "LM"   | | |
| | |_________|  |_________| | |
| |__________________________| |
|______________________________|
 DEĞER

LİSTE G’nin Oluşturulması

Biraz daha ilginç bir alıştırma, F ile aynı açıklamaya sahip, G adlı bir LİSTE oluşturan ve ardından A’sı 'AB' olan F’nin tüm üyelerini G’ye kopyalayan çağrıları kurmaktır.

Önce G’yi, bir OPD’yi ve geçerli üyeyi temsil edecek bir nesneyi oluşturmamız gerekir.

L/CREATE("STAR",LD/LIST(G,
                        LD/STRUCT(R,
                                  LD/STRING(A,STRING,2),
                                  LD/STRING(B,STRING,2)))
L/CREATE(L/TOBJ(TOP/LEVEL),LD/OPD(OPG))
L/CREATE(L/TOBJ(TOP/LEVEL),LD/STRUCT(GM,
                        LD/STRING(A,STRING,2),
                        LD/STRING(B,STRING,2)))

Şimdi, biri G üzerinde, diğeri F üzerinde olmak üzere iki liste işlemleri dizisini başlatmamız gerekir.

L/BEGIN/LISTOP(L/POBJ(F),L/TOBJ(M),
               L/TOBJ(OPF),GET)
L/BEGIN/LISTOP(L/POBJ(G),L/TOBJ(GM),
               L/TOBJ(OPG),ADD)
L/WHICH/MEMBER(L/TOBJ(OPF),FIRST)
L/WHICH/MEMBER(L/TOBJ(OPG),LAST)

Şimdi F’nin üyeleri boyunca ilerleyeceğiz; geçerli üyenin A’sı 'AB' olduğunda, G’ye bir üye ekleyeceğiz. Ardından F’nin geçerli üyesinin değerlerini, G’ye yeni eklenen üyeye kopyalayacağız. Geçerli üye bu ölçütü karşılamadığında ise onunla hiçbir işlem yapmayacağız.

Önce, F’nin sonuna gelene kadar çalışacak bir döngü yazmak için:

L/TILL(L/END/OF/LIST(L/TOBJ(OPF)),x)

Bu çağrıda x yerine ne koyarsak, OPF içinde end/of/list bayrağı ayarlanana kadar tekrar tekrar çalıştırılacaktır.

L/TILL’in beklediği şeyi verebilmek için x’i tek bir fonksiyon çağrısıyla değiştirmemiz gerekir. Ancak x, F’nin her bir üyesi için bir kez çalıştırılacak ve her seferinde birkaç liste işlemi çalıştırmamız gerekecektir. Çözüm, bileşik-fonksiyon fonksiyonu olan L/CF’yi kullanmaktır:

L/TILL(L/END/OF/LIST(L/TOBJ(OPF)),L/CF(y))

Artık y’yi bir dizi fonksiyon çağrısıyla değiştirebiliriz.

Her yinelemede F’nin yeni bir üyesini işlememiz gerekir; başlangıçta ilk üyeyi alacak şekilde ayarlanmış durumdayız. O halde aşağıdaki dizi gereklidir:

L/CF(   L/OPEN/MEMBER(L/TOBJ(OPF),GET),
        z,
        L/CLOSE/MEMBER(L/TOBJ(OPF)),
        L/WHICH/MEMBER(L/TOBJ(OPF),NEXT) )

Yukarıdaki, F’nin geçerli üyesini açacak, ona bir işlem uygulayacak (yukarıda z ile temsil edilmiştir), kapatacak ve bir sonraki üyeyi isteyecek olan bir bileşik fonksiyondur.

z’yi, F’nin geçerli üyesindeki A’nın içeriğini test eden ve ya hiçbir şey yapmayan ya da G’ye bir üye ekleyip F’nin geçerli üyesinin değerlerini kopyalayan bir fonksiyon çağrısıyla değiştirmek istiyoruz. Eğer w, G’ye üye ekleme ve değerleri kopyalama eylemini temsil ediyorsa, bunu şu şekilde ifade edebiliriz:

L/IF(L/EQUAL(L/TOBJ(M.A),LC/STRING('AB')),w)

“Bir üye ekle ve değerleri kopyala”yı ifade etmenin uygun bir yolu şudur:

L/CF(L/OPEN/MEMBER(L/TOBJ(OPG),ADD),
     L/ASSIGN(L/TOBJ(GM.A),L/TOBJ(M.A)),
     L/ASSIGN(L/TOBJ(GM.B),L/TOBJ(M.B)),
     L/CLOSE/MEMBER(L/TOBJ(OPG)) )

Bu, önceki örneğe yeterince benzerdir; dolayısıyla bir açıklamaya gerek yoktur.

Tüm bunları bir araya getirdiğimizde, şunu elde ederiz:

L/TILL(L/END/OF/LIST(L/TOBJ(OPF)),
    L/CF(
        L/OPEN/MEMBER(L/TOBJ(OPF),GET),
        L/IF(L/EQUAL(L/TOBJ(A),LC/STRING('AB')),
            L/CF(
                L/OPEN/MEMBER(L/TOBJ(OPG),ADD),
                L/ASSIGN(L/TOBJ(GM.A),L/TOBJ(M.A)),
                L/ASSIGN(L/TOBJ(GM.B),L/TOBJ(M.B)),
                L/CLOSE/MEMBER(L/TOBJ(OPG))
            )
        ),
        L/CLOSE/MEMBER(L/TOBJ(OPF)),
        L/WHICH/MEMBER(L/TOBJ(OPF),NEXT)
    )
)

İşlemi sonuçlandırmak için şunu çalıştırırız:

L/LISTOP/END(L/TOBJ(OPG))
L/LISTOP/END(L/TOBJ(OPF))

Sonuç, ilk üyesinin değeri ('AB','CD') olan ve ikinci üyesinin değeri ('AB','IJ') olan bir LİSTE G’dir. Yukarıdaki örnek üzerinde birkaç değişiklikle, oldukça fazla sayıda LİSTE işlemi gerçekleştirilebilir.

4.11 Daha Yüksek Düzey Fonksiyonlar

Bu ilkel i/fonksiyonlar yararlı olmakla birlikte, kullanıcıların genellikle datalanguage’da bu kadar düşük bir düzeyde çalışmasını beklemeyiz. Bu ilkelleri, istisnai durumları ele alabilmeleri ve atipik uygulamalar için kendi yüksek düzey fonksiyonlarını geliştirebilmeleri amacıyla kullanıcılara sunmak istiyoruz. Normalde, en azından aşağıdaki yapım düzeyinde çalışmaları gerekir (ki bu, hâlihazırda uygulanmış gerçek datalanguage’da yasaldır):

FOR G.R,F.R WITH A EQ 'AB'
    G.R=F.R
END

Bu görece kısa ifade, bir önceki bölümün sonunda verilen i/fonksiyonlarının ayrıntılı kurgusuyla aynı sonucu gerçekleştirir. Çalışan yazılımda kullanılan anlamsal fonksiyonlara çok benzeyen i/fonksiyonlar tanımlayabilir ve yukarıdaki isteği şu şekilde yazabiliriz:

L/FOR(L/POBJ(G),R,
      L/POBJ(F),R,
      L/WITH(L/EQUAL(L/TOBJ(A),
                     LC/STRING('AB'))))

İ/fonksiyon çağrısı ile onun üzerindeki datalanguage isteği arasındaki farklar esas olarak sözdizimseldir.

L/FOR ve L/WITH gibi fonksiyonları tasarlarken, temel sorunlar doğru kısıtlamaları seçmekle ilgilidir. İlkel düzeyde mevcut olan tüm genelliğe sahip olunamaz. Bu özel fonksiyonlar için bazı önemli seçimler şunlardır:

1. Birden çok girdi ve çıktının ele alınması.
2. FOR’lar iç içe geçtiğinde, dış FOR’ların iç FOR’lar için mevcut seçenekleri nasıl kısıtladığı.
3. Seçim fonksiyonlarının genelliği (bunlar daha sonra FOR’lar üretebilir mi?).
4. İşlemenin nereden başlaması gerektiğine ilişkin seçenekler (çıktı liste(ler)ini güncelliyor muyuz, değiştiriyor muyuz yoksa sonuna mı ekliyoruz?).

Son olarak, bu problem, ortak özelliklere sahip bir LİSTE içindeki üye koleksiyonu fikrinin genelleştirilmiş hâli olan kümeler ile uğraşmanın daha genel problemiyle ilişkilidir. FOR, küme girişi alabilen pek çok operatörden yalnızca biridir.

4.12 Sonuç

Mevcut model, henüz başlangıç aşamasında olmasına rağmen, hiyerarşik veri yapılarının tanımlanmasına ve genelleştirilmiş biçimde işlenmesine izin verecek yeterli sayıda ilkel ve veri türünü zaten içermektedir. İçeriğe göre erişim ve seçici güncelleme gibi yaygın veri yönetimi işlemleri ifade edilebilmektedir.

Bu ilkellerin geliştirilmesinde bu modelin kullanılması, dil öğeleri ve işleme fonksiyonları için kesin, iyi tanımlanmış ve içsel olarak tutarlı belirtimlerin ortaya çıkmasını sağlamıştır. Modelin sağladığı laboratuvar ortamında çalışmak, önemli bir yarar gibi görünmektedir.

5. Gelecek Çalışmalar

Bu bölümde, tasarımda şimdiye kadar nelerin başarıldığını gözden geçiriyor ve datalanguage’ın bu tasarım yinelemesi tamamlanmadan önce yapılması gereken çalışmaları tanımlıyoruz.

5.1 Bir Gözden Geçirme

Başarılarımız arasında en önemlisi olarak, datacomputer sistemi için bir dil geliştirilmesine ilişkin sorunları belirlemiş olmamızı ve bir çözümün geniş hatlarını sunmuş olmamızı görüyoruz. Yaklaşımımızın temel unsurları; verinin tüm yönlerini yakalamada veri tanımının önceliği, veri tanımının mantıksal ve fiziksel özelliklerinin ayrılması, kullanıcıların aynı verinin farklı görünümlerini tanımlayabilme yeteneği, veri öğelerinin farklı kullanımlarıyla fonksiyonları ilişkilendirebilme yeteneği, her olası düzeyde verinin ortak yönlerini yakalama çabası ve kullanıcıların, uygulamalarının izin verdiği kadar yüksek bir düzeyde datacomputer ile iletişim kurabilme yeteneğidir.

5.2 Daha İleri Araştırma Konuları

Genel olarak datalanguage için tamamlanmış bir tasarım ortaya koymak adına daha fazla çalışmaya ihtiyaç olsa da, özellikle daha fazla araştırma gerektiren bazı konuları ayırt edebiliriz.

Şu ana kadar, yalnızca hiyerarşik veri yapıları (yani fiziksel içerme ile modellenebilenler) belirli bir ölçüde geliştirilmiştir. Ayrıca başka veri yapısı türlerini de araştırmayı ve sağlamayı planlıyoruz. Dil çerçevemizin bu tür eklemeleri engelleyecek varsayımlar içermediğinden eminiz.

Erişim düzenlemesine ilişkin mevcut çalışmamız, veriler için birden çok tanımın kullanılmasına odaklanmaktadır. Erişim düzenlemesinin hem teknik hem de idari yönleri üzerinde daha fazla çalışma yapmamız gerekmektedir. Verilerin hem iletim hem de depolama için şifrelenmesi sorunları da araştırılacaktır.

Daha fazla araştırma gerektiren bir diğer konu, süreçlerin datacomputer ile etkileşimi için gereken protokol gereksinimidir.

Tanımın bağımsız modüllere ayrılması daha fazla araştırma gerektirmektedir. Özellikle, mantıksal tanımların, fiziksel tanımların ve ikisi arasındaki eşlemelerin ayrı ayrı belirtimlerine ilişkin hâlihazırda yapılmış çalışmaları incelememiz gerekmektedir.

5.3 Datalanguage Sözdizimi

Geliştirmekte olduğumuz datalanguage için henüz bir sözdizimi önermedik. Kuşkusuz, problemin en zor kısımları anlamsal ve pragmatik konular olmuştur. Çeşitli sözdizimsel biçimlerin aşırı güçlük olmadan seçilip uygulanabileceğinden eminiz. Dilin, farklı kullanıcı türleri için ya da hatta dilin çeşitli alt bölümleri için farklı sözdizimsel biçimlerinin geliştirilmesi en iyisi olabilir. Bölüm 2’de tartışıldığı üzere, datacomputer için kullanıcı sözdiziminin düşük düzeyde olması beklenmektedir. Programların bu sözdiziminde datalanguage istekleri üretmesi kolay olmalıdır.

5.4 Datalanguage Modeli Üzerinde Daha İleri Çalışmalar

Model, Bölüm 3’te açıklanan olanaklara sahip bir dil geliştirmek için mükemmel bir temel sağlamaktadır. Yapılacak çok iş vardır.

Bir süre boyunca vurgu, kümeler, yüksek düzey operatörler, dil genişletme ve veri tanımı üzerinde olacaktır.

Kümeleri, değeri genellikle diğer nesnelerle paylaşılan yeni bir veri türü olarak modellemeyi bekliyoruz. Bunu desteklemek için değerlerin bağlanması ve paylaşılması üzerine ek çalışmalara ihtiyaç vardır.

Kümeler, biraz daha sonra ele alınacak olan genelleştirilmiş ilişkilerin özel bir durumu olarak görülebilir.

FOR gibi yüksek düzey operatörler, mevcut ilkellerden kurulacak ve sonunda tek bir etkiye sahip olacak ancak birden çok olası genişletmeye sahip olacak şekilde tanımlanacaktır. Genişletme, verinin gösterimine ve yardımcı yapıların varlığına bağlı olacaktır.

Veri tanımı çeşitli modüllerine ayrıldığında alternatif genişletmeler mümkün olacaktır. Bu da ayrıca daha fazla araştırma gerektirmektedir.

Dil genişletme probleminin, model datacomputer’ın sağladığı ortamda çok daha kolay ele alınabileceğini düşünüyoruz. Özellikle, laboratuvar ortamının, dili genişleten operatörlerin karmaşık etkileşimlerini ve yaygın etkilerini değerlendirmede yardımcı olmasını bekliyoruz.

Yakın vadede veri tanımı çalışmaları; özniteliklerin yalıtılması, tanımda değişken yapının gösterimi, tanımların tanımı ve yeterli bir yerleşik veri türleri kümesinin geliştirilmesi üzerine odaklanacaktır.

Daha sonra, işaretçilerin gösterimi ve işaret ettikleri adres uzayının anlambilimi işaretçinin tanımında belirtildiğinde, işaretçilerin anlambilimini bir veri türü olarak modellemeyi bekliyoruz.

Modellemede bugüne kadar keşfedilmiş bazı problemler de dâhil olmak üzere, çok sayıda daha alt düzey sorun ele alınacaktır. Bunların bazıları Bölüm 4’teki tartışmalarda işaret edilmiştir.

5.5 Uygulama Desteği

Tasarlamakta olduğumuz datalanguage, veri yönetimiyle ilgili geniş bir problem sınıfını çözen alt sistemlere hizmet sağlamayı amaçlamaktadır. Bu tür alt sistemlere örnek olarak rapor üreteçleri, programcı olmayanlar için çevrimiçi sorgu sistemleri, belge işleme sistemleri, işlem işleme sistemleri, gerçek zamanlı veri toplama sistemleri ve kütüphane ile bibliyografik sistemler verilebilir. Bunların çok daha fazlası vardır.

Amaç, bu tür sistemlerin diğer makineler üzerinde çalışması, datacomputer üzerinde veriye başvurması veya veri depolaması ve datalanguage’dan yoğun biçimde yararlanmasıdır. Böyle bir sistem bütünüyle datalanguage ile yazılmayacaktır; ancak işlevinin büyük bir bileşeni datalanguage istekleriyle ifade edilecektir. Bazı denetleyici modüller bu istekleri oluşturacak ve datalanguage dışındaki işlevleri yerine getirecektir.

Bu tür uygulamalarla başka ortamlarda deneyimimiz bulunmakta ve potansiyel kullanıcılarla görüşmekteyiz; buna karşın, dilimizin onlar için gerçekten yeterli olup olmadığını belirlemek belirli bir çalışma gerektirecektir. Yani, insan odaklı bir çevrimiçi sorgu sistemi geliştirme sorununa doğrudan saldırmıyoruz; bunun yerine, böyle bir sistemi kolayca geliştirmeyi sağlayacak araçları sunmaya çalışıyoruz. Araçların yeterince iyi olup olmayacağını analiz etme konusunda açık bir gereksinim vardır. Elbette, nihai sınama gerçek kullanımda olacaktır; ancak uygulamaya geçmeden önce olabildiğince çok sorunu ayıklamak istiyoruz.

Uygulamaları desteklemenin önemli bir bileşeni, kullanıcı programlarının sıklıkla FORTRAN, COBOL veya PL/1 gibi yüksek seviyeli dillerde yazılacak olmasıdır. Tasarım şekillenirken, datalanguage’ın bu tür kullanıcıları destekleme yeteneğini araştırmak isteyeceğiz.

5.6 Gelecek Planları

Bu makale, datalanguage için yeni bir tasarımın temellerini atmıştır. Bölüm 3, önümüzdeki aylarda ayrıntıları doldurulacak olan bir datalanguage taslağı sunmaktadır. Ayrıntılı bir belirtimin yayımlanmasının ardından, kapsamlı incelemeler, revizyonlar ve uygulama planlarına dahil edilmesini öngörüyoruz. Uygulama, datacomputer hizmetlerinin ve veri yönetimi yeteneklerinin geliştirilmesine yönelik yerleşik planlarla uyumlu olacak şekilde aşamalar halinde gerçekleştirilecektir.

Bu RFC, Alex McKenzie tarafından, eski adıyla BBN Corp. olan GTE’nin desteğiyle, 1/2000 tarihinde çevrimiçi RFC arşivlerine giriş için makine tarafından okunabilir biçime dönüştürülmüştür.