NESNE-İLİŞKİSEL DBMS'LER

Nesne yönelimi, yazılım geliştirmenin klasik sorunlarının bazılarını çözmek için büyük umut vaat eden bir yazılım inşası yaklaşımıdır. Nesne teknolojisinin ardındaki temel konsept, tüm yazılımların mümkün olan her yerde standart, yeniden kullanılabilir bileşenlerden yapılmış olmasıdır. Geleneksel olarak, yazılım mühendisliği ve veritabanı yönetimi ayrı disiplinler olarak var olmuştur. Veri tabanı teknolojisi, bilgi depolamasının statik yönlerine odaklanırken, yazılım mühendisliği yazılımın dinamik yönlerini modellemiştir.

Üçüncü nesil veri tabanı yönetim sistemlerinin, yani Nesne-İlişkisel Veri Tabanı Yönetim Sistemleri (ORDBMS'ler) ve Nesne Yönelimli Veri Tabanı Yönetim Sistemleri'nin (OODBMS'ler) gelmesiyle, iki disiplin hem verilerin hem de işlemlerin eşzamanlı modellenmesine izin vermek için birleştirildi. Ancak, bu yeni nesil DBMS'lerle ilgili bazı sorunlar olmuştur. İlişkisel sistemlerin son otuz yılda başarısı açıktır ve gelenekçiler ilişkisel modeli ek (nesne yönelimli) yeteneklerle genişletmenin yeterli olduğuna inanırlar. Diğerleri, temelde bir ilişkisel modelin, bilgisayarlı tasarım, bilgisayar destekli yazılım mühendisliği ve coğrafi bilgi sistemleri gibi karmaşık uygulamaları ele almak için yetersiz olduğuna inanmaktadır. Bu bölümde, SQL'e yapılan uzantılara odaklanan ORDBMS'yi ele alıyoruz. Nesneye yönelik kavramları ilişkisel sistemlere entegre etmek, gelişmiş veritabanı uygulamalarını desteklemek için daha evrimsel bir yaklaşım olarak kabul edilir.

Gelişmiş Veri Tabanı Uygulamaları

Bilgisayar endüstrisi son on yılda önemli değişiklikler gördü. Veri tabanı sistemlerinde, sipariş işleme, stok kontrolü, bankacılık ve havayolu rezervasyonları gibi geleneksel ticari uygulamalar için RDBMS'lerin yaygın olarak kabul edildiğini gördük. Bununla birlikte, mevcut RDBMS'lerin ihtiyaçları geleneksel iş veritabanı uygulamalarından oldukça farklı olan uygulamalar için yetersiz olduğu kanıtlanmıştır.

Bu uygulamalar şunları içerir:

• Bilgisayar destekli tasarım (CAD);

• Bilgisayar destekli üretim (CAM);

• Bilgisayar destekli yazılım mühendisliği (CASE);

• Ağ yönetim sistemleri;

• Ofis bilgi sistemleri (OIS) ve multimedya sistemleri;

• Dijital yayıncılık;

• Coğrafi bilgi sistemleri (GIS);

• Etkileşimli ve dinamik web siteleri.

Bilgisayar destekli tasarım (CAD)

Bir CAD veritabanı, örneğin binalar, uçaklar ve entegre devre yongaları gibi mekanik ve elektrik tasarımla ilgili verileri depolar. Bu tür tasarımlar bazı ortak özelliklere sahiptir:

• Tasarım verileri, her biri az sayıda örneği olan çok sayıda tür ile karakterize edilir. Geleneksel veritabanlarına genellikle zıttır. Örneğin, DreamHome veritabanı yalnızca bir düzine kadar ilişkiden oluşur, ancak PropertyForRent, Client ve Viewing gibi ilişkiler binlerce dosya içerebilir.

• Tasarımlar çok büyük olabilir, belki de çoğu zaman birbirine bağlı alt sistem tasarımlarıyla birlikte milyonlarca parçadan oluşabilir.

• Tasarım statik değildir, zamanla gelişir. Bir tasarım değişikliği gerçekleştiğinde, sonuçları tüm tasarım gösterimleriyle yayılmalıdır. Tasarımın dinamik doğası, başlangıçta bazı eylemlerin öngörülemeyeceği anlamına gelebilir.

• Güncellemeler, topolojik veya işlevsel ilişkiler, toleranslar vb. nedeniyle geniş kapsamlıdır. Bir değişikliğin çok sayıda tasarım nesnesini etkilemesi muhtemeldir.

• Genellikle, her bileşen için birçok tasarım alternatifi düşünülmekte ve her parça için doğru sürüm korunmalıdır. Bu, bir çeşit sürüm kontrolü ve konfigürasyon yönetimi içerir.

• Tasarımla ilgili yüzlerce personel olabilir ve büyük bir tasarımın birden fazla sürümünde paralel olarak çalışabilirler. Buna rağmen, son ürün tutarlı ve koordineli olmalıdır. Buna bazen kooperatif mühendisliği denir.

Bilgisayar destekli üretim (CAM)

Bir CAM veritabanı, ayrık üretime (montaj hattındaki arabalar gibi) ve sürekli üretime (kimyasal sentez gibi) ilişkin verilere ek olarak, bir CAD sistemine benzer verileri depolar. Örneğin, kimyasal imalatta, reaktör kabı sıcaklıkları, akış hızları ve verimler gibi sistemin durumu hakkındaki bilgileri izleyen uygulamalar vardır. Valf açma, reaktör haznelerine daha fazla ısı uygulama ve soğutma sistemlerinin akışını arttırma gibi çeşitli fiziksel işlemleri kontrol eden uygulamalar da vardır. Bu uygulamalar genellikle bir hiyerarşide düzenlenir, fabrikanın tamamını izleyen bir üst düzey uygulama ve bireysel üretim süreçlerini izleyen düşük seviyeli uygulamalar. Bu uygulamalar gerçek zamanlı olarak yanıt vermeli ve sıkı toleranslar içinde optimum performansı sağlamak için prosesleri ayarlayabilmelidir. Uygulamalar, farklı koşullara yanıt vermek için standart algoritmalar ve özel kuralların bir kombinasyonunu kullanır. Operatörler, sistemin korumak zorunda olduğu karmaşık geçmiş verilere dayanarak performansı optimize etmek için zaman zaman bu kuralları değiştirebilir. Bu örnekte, sistem, doğada hiyerarşik olan büyük miktarda veriyi korumalı ve veriler arasında karmaşık ilişkileri sürdürmelidir. Ayrıca değişiklikleri incelemek ve yanıtları oluşturmak için verilerde hızlı bir şekilde gezinebilmelidir.

Bilgisayar destekli yazılım mühendisliği (CASE)

Bir CASE veritabanı, yazılım geliştirme yaşam döngüsünün aşamaları ile ilgili verileri depolar: planlama, ihtiyaç toplama ve analiz, tasarım, uygulama, test, bakım ve dokümantasyon. CAD'de olduğu gibi, tasarımlar son derece büyük olabilir ve kooperatif mühendisliği normdur. Örneğin, yazılım konfigürasyon yönetimi araçları, proje tasarımı, kod ve dokümantasyonun aynı anda paylaşılmasını sağlar. Ayrıca, bu bileşenler arasındaki bağımlılıkları takip eder ve değişim yönetimine yardımcı olurlar. Proje yönetimi araçları,

potansiyel olarak oldukça karmaşık birbirine bağlı görevlerin zamanlaması, maliyet tahmini ve ilerleme takibi gibi çeşitli proje yönetimi faaliyetlerinin koordinasyonunu kolaylaştırır.

Ağ yönetim sistemleri

Ağ yönetim sistemleri, iletişim hizmetlerinin bir bilgisayar ağında sunulmasını koordine eder. Bu sistemler ağ yolu yönetimi, sorun yönetimi ve ağ planlaması gibi görevleri gerçekleştirir. Daha önce tartıştığımız kimyasal üretim örneğinde olduğu gibi, bu sistemler de karmaşık verileri ele alıyor ve gerçek zamanlı performans ve sürekli çalışma gerektiriyor. Örneğin, bir telefon görüşmesi, bir mesajı göndericiden alıcıya yönlendiren bir ağ anahtarlama cihazları zinciri içerebilir:

Node Link Node Link Node Link Node

her düğüm bir ağ aygıtındaki bir bağlantı noktasını temsil eder ve her Bağlantı bu bağlantı için ayrılmış bir bant genişliği dilimini temsil eder. Bununla birlikte, bir düğüm birkaç farklı bağlantıya katılabilir ve oluşturulan herhangi bir veritabanının karmaşık bir ilişki grafiğini yönetmesi gerekir. Bağlantıları yönlendirmek, sorunları teşhis etmek ve yükleri dengelemek için ağ yönetim sistemlerinin bu karmaşık grafikte gerçek zamanlı olarak hareket edebilmesi gerekir.

Büro bilgi sistemleri (OIS) ve multimedya sistemleri

Bir OIS veritabanı, elektronik posta, belgeler, faturalar vb. Dahil olmak üzere bir işletmedeki bilgilerin bilgisayar kontrolü ile ilgili verileri depolar. Bu alana daha iyi destek sağlamak için, adlar, adresler, tarihler ve para dışında daha geniş bir veri türü yelpazesiyle ilgilenmemiz gerekir. Modern sistemler şimdi serbest biçimli metinleri, fotoğrafları, şemaları ve ses ve video dizilerini işler. Örneğin, bir multimedya belgesi metni, fotoğrafları, elektronik tabloları ve sesli yorumları kullanabilir. Dokümanlar, Bölüm 30'da tartıştığımız gibi, belki SGML (Standartlaştırılmış Genelleştirilmiş İşaretleme Dili), HTML (Köprü Metni İşaretleme Dili) veya XML (genişletilmiş İşaretleme Dili) gibi bir biçimlendirme dili kullanılarak açıklanan belirli bir yapıya sahip olabilir. İnternet teknolojisine dayalı elektronik posta ve bülten panoları gibi sistemler kullanan birçok kullanıcı arasında paylaşılabilir. † Yine, bu tür uygulamaların sayı ve metin dizelerinden oluşan tupllardan çok daha zengin bir yapıya sahip verileri depolaması gerekir. Elektronik aygıtlar kullanarak el yazısı notları yakalama konusunda artan bir ihtiyaç vardır. Her ne kadar birçok not, el yazısı analiz tekniklerini kullanarak ASCII metnine kopyalanabilse de, bu verilerin çoğu olamaz. Kelimelere ek olarak, el yazısı verileri çizimler, diyagramlar vb. İçerebilir.

DreamHome vaka çalışmasında, multimedyayı kullanmak için aşağıdaki gereksinimleri bulabiliriz:

• Görüntü verileri. Bir müşteri kiralık mülklerin görüntü veritabanını sorgulayabilir. Bazı sorgular, istenen özelliklerin görüntülerini tanımlamak için basit bir yazılı açıklama kullanabilir. Diğer durumlarda, müşterinin istenen özelliklerde bulunabilecek özelliklerin (cumbalı pencereler, iç kaplama veya çatı bahçeleri gibi) grafiksel görüntülerini kullanarak sorgulaması faydalı olabilir.

• Video verisi. Bir müşteri, kiralık mülklerin bir video veritabanını sorgulayabilir. Yine, bazı sorgular, istenen özelliklerin video görüntülerini tanımlamak için basit bir yazılı açıklama kullanabilir. Diğer durumlarda, müşterinin istenen özelliklerin (deniz veya çevresindeki tepelerin manzaraları gibi) video özelliklerini kullanarak sorgulaması faydalı olabilir.

• Ses verileri. Bir müşteri, kiralık mülklerin özelliklerini tanımlayan bir ses veritabanını sorgulayabilir. Bir kez daha, bazı sorgular istenen özelliği tanımlamak için basit bir yazılı açıklama kullanabilir. Diğer durumlarda, müşterinin istenen özelliklerin ses özelliklerini kullanması yararlı olabilir (yakındaki trafikten gelen gürültü seviyesi gibi).

• Notlar. Personel, kiralık mülklerin denetimlerini gerçekleştirirken notlar oluşturabilir. Daha sonraki bir tarihte, herhangi bir yerdeki kuru çürüme ile daireyle ilgili tüm notları bulmak için bu tür verileri sorgulamak isteyebilir.

Dijital yayıncılık

Yayıncılık endüstrisinin gelecek on yılda iş uygulamalarında köklü değişiklikler geçirmesi muhtemel. Artık elektronik ortamda kitap, dergi, makale ve makaleleri saklamak ve bunları tüketicilere yüksek hızlı ağlar üzerinden sunmak mümkün. Ofis bilgi sistemlerinde olduğu gibi, metin, ses, görüntü ve video verileri ve animasyondan oluşan multimedya belgelerini işlemek için dijital yayıncılık genişletilmektedir. Bazı durumlarda, çevrimiçi duruma getirilebilecek bilgi miktarı, bir DBMS'nin yönetmesi gereken en büyük veritabanlarını oluşturacak olan petabayt (1015 byte) sırasına göre çok büyüktür.

Coğrafi bilgi sistemleri (GIS)

GIS veri tabanı, arazi yönetimi ve su altı araştırmalarında kullanılanlar gibi çeşitli mekansal ve geçici bilgileri saklar. Bu sistemlerdeki verilerin çoğu anket ve uydu fotoğraflarından elde edilmiştir ve çok büyük olma eğilimindedir. Aramalar, gelişmiş desen tanıma tekniklerini kullanarak örneğin şekil, renk veya dokuya dayalı özellikleri tanımlamayı içerebilir. Örneğin, EOS (Dünya Gözlem Sistemi), NASA tarafından 1990'larda başlatılan, topluluğun atmosferi, okyanusları ve toprağı ile ilgili uzun vadeli eğilimlerden endişe duyan bilim adamlarını destekleyecek bilgileri toplamak için başlatılan bir uydu topluluğudur. Bu uyduların yılda bir petabayt bilgi birikiminin üçte birinden fazlasına geri döneceği tahmin edilmektedir. Bu veriler diğer veri kaynaklarıyla entegre edilecek ve EOSDIS'te (EOS Veri ve Bilgi Sistemi) depolanacaktır. EOSDIS, hem bilim insanlarının hem de bilim adamlarının bilgi ihtiyaçlarını karşılayacaktır. Örneğin, öğrenciler dünya hava durumu modellerinin bir simülasyonunu görmek için EOSDIS'e erişebilecekler. Bu veritabanının büyük boyutu ve çok fazla miktarda bilgi talebinde bulunan binlerce kullanıcıyı destekleme ihtiyacı, DBMS'ler için birçok zorluk getirecektir.

Interaktif ve dinamik web siteleri

Giysi satmak için çevrimiçi bir kataloğu olan bir Web sitesini düşünün. Web sitesi, siteye önceki ziyaretçiler için bir dizi tercih sunar ve bir ziyaretçinin şunları yapmasına izin verir:

• Katalogdaki öğelerin küçük resimlerine göz atın ve destek detayları içeren tam boyutlu bir görüntü elde etmek için birini seçin;

• Kullanıcı tanımlı bir kriter kümesiyle eşleşen öğeleri aramak;

• Özel bir spesifikasyona (örneğin renk, beden, kumaş) dayalı herhangi bir kıyafetin 3B renderini elde etmek;

• Hareket, aydınlatma, fon, fırsat ve benzeri durumları hesaba katan görüntüyü değiştirmek;

• Kenar çubuğunda sunulan eşyalardan kıyafetle gitmek için aksesuarları seçin;

• Maddenin ek ayrıntılarını içeren bir seslendirme yorumu seçin;

• Uygun indirimlerle faturanın akan toplamını görüntülemek;

• Satın alma işlemlerini güvenli bir çevrimiçi işlemle sonlandırın.

Bu tür bir uygulama için gereklilikler, yukarıda belirtilen gelişmiş uygulamaların bazılarından farklı değildir: multimedya içeriğini (metin, ses, görüntü, video verileri ve animasyon) işlemeye ve ekranı kullanıcıya göre etkileşimli olarak değiştirmeye ihtiyaç vardır. tercihler ve kullanıcı seçimleri. Site, karmaşık verilerin yanı sıra, 3B oluşturma sağlama karmaşıklığına da sahiptir. Böyle bir durumda veri tabanının sadece ziyaretçiye bilgi sunmakla kalmayıp, ziyaretçiye dinamik olarak kişiselleştirilmiş bilgi ve atmosferi sağlamak için aktif bir şekilde satış yapmakla meşgul olduğu ileri sürülmektedir (King, 1997). Bölüm 29 ve 30'da tartıştığımız gibi, Web şimdi veri yönetimi için nispeten yeni bir paradigma sunmaktadır ve XML gibi diller, özellikle e-Ticaret pazarı için önemli vaatlerde bulunmaktadır. Forrester Research Group ve eMarketer’e göre, ABD’nin 2011 yılı online perakende satışları yaklaşık 225 milyar ABD doları olarak gerçekleşmiş ve 2016’da bilgisayar ve tüketici elektroniği, %20’sini oluşturan giyim ve aksesuarları ile 2016 yılında 362 milyar ABD dolarına yükseleceği öngörülmektedir. Pazarın. Perakende Araştırma Merkezi, Avrupa'nın 2012 yılında 232 milyar ABD doları online perakende satışla ABD'yi aşacağını tahmin ediyordu. Küresel işletmeler arası (B2B) pazarın, tüketiciden tüketiciye (B2C) pazarından daha büyük olması beklenmektedir ve B2B gelirlerinin, önümüzdeki yıllarda B2C gelirlerini birçok kez aşması beklenmektedir. Şirketler artık dünya çapındaki 2,5 milyon çevrimiçi tüketiciye (dünya nüfusunun% 35'i) küresel web varlıklarıyla ulaşabiliyor. İnternet kullanımı arttıkça ve teknoloji daha karmaşık hale geldikçe, Web sitelerinin ve işletmeler arası işlemlerin çok daha karmaşık ve birbiriyle ilişkili verileri ele aldığını göreceğiz.

Diğer gelişmiş veritabanı uygulamaları şunlardır:

• Sentetik kimyasal bileşikler ve genetik materyal için moleküler modeller gibi sistemleri temsil eden karmaşık verileri depolayabilen bilimsel ve tıbbi uygulamalar.

• AI uygulamaları için bilgi depolayabilecek ve temel oluşturabilecek uzman sistemler.

• Karmaşık ve birbiriyle ilişkili nesneler ve prosedür verileri içeren diğer uygulamalar.

RDBMS'lerin Zayıf Yönleri

4. Bölümde, ilişkisel modelin birinci dereceden yordam mantığına dayanarak nasıl güçlü bir teorik temele sahip olduğunu tartıştık. Bu teori, ilişkisel veritabanlarını tanımlamak ve işlemek için artık standart dil haline gelen bir bildirim dili olan SQL'in geliştirilmesini

destekledi. İlişkisel modelin diğer güçlü yönleri basitliği, Çevrimiçi İşlem İşleme (OLTP) için uygunluğu ve veri bağımsızlığı için sağladığı desteklerdir. Bununla birlikte, ilişkisel veri modeli ve özellikle ilişkisel DBMS'ler dezavantajları olmadan değildir. Tablo 9.1, nesne yönelimli yaklaşımın savunucuları tarafından sıklıkla dile getirilen bazı önemli zayıflıkları listelemektedir. Bu bölümdeki bu zayıf yönleri tartışıyoruz ve okuyucuları bu zayıf yönlerin uygulanabilirliğini kendileri için yargılamaya bırakıyoruz.

“Gerçek dünya” varlıklarının zayıf temsili

Normalleşme süreci genellikle “gerçek dünya” daki varlıklara karşılık gelmeyen ilişkilerin yaratılmasına yol açar. “Gerçek dünya” oluşumunun, bu yapıyı yansıtan fiziksel bir temsil ile birçok ilişkiye bölünmesi yetersizdir. sorgu işleme sırasında birçok birleşime yol açar. Bölüm 23'te göreceğimiz gibi, birleşme yapılacak en pahalı işlemlerden biridir.

Anlamsal aşırı yükleme

İlişkisel model, verileri temsil etmek için tek bir kurguya sahiptir ve veriler arasındaki ilişkileri: ilişki. Örneğin, iki varlık A ve B arasındaki çoktan çoğa (*: *) bir ilişkiyi temsil etmek için, biri A ve B varlıklarının her birini temsil eden ve biri ilişkiyi temsil eden üç ilişki oluştururuz. Varlıklar ve ilişkiler arasında ayrım yapma veya varlıklar arasında var olan farklı ilişki türlerini ayırt etme mekanizması yoktur. Örneğin, 1: * ilişki Has, Sahip, Yönet, vb. Olabilir. Eğer böyle bir ayrım yapılabilirse, o zaman anlambilimi operasyonlara dahil etmek mümkün olabilir. İlişkisel modelin anlamsal olarak aşırı yüklendiği söylenir. Anlamsal veri modelleri, yani verilerin anlamını daha fazla temsil eden modeller kullanılarak bu sorunun üstesinden gelmek için birçok girişimde bulunulmuştur. İlgilenen okuyucu, Hull ve King (1987) ve Peckham ve Maryanski (1988) tarafından hazırlanan anket çalışmalarına yönlendirilmektedir. Bununla birlikte, ilişkisel model anlamsal özellikler olmadan tamamen değildir. Örneğin, etki alanları ve anahtarlar (bkz. Bölüm 4.2) ve işlevsel, çok değerli ve birleştirme bağımlılıkları vardır (bkz. Bölüm 14 ve 15).

Bütünlük ve genel kısıtlamalar için zayıf destek

Bütünlük, saklanan verilerin geçerliliği ve tutarlılığı anlamına gelir. Bütünlük genellikle, veritabanının ihlal etmesine izin verilmeyen tutarlılık kuralları olan kısıtlar olarak ifade edilir. Bölüm 4.3'te, varlık ve referans bütünlüğü kavramlarını tanıttık ve Bölüm 4.2.1'de de bir tür kısıtlama olan alanlar tanıttık. Maalesef, birçok ticari sistem bu kısıtlamaları tam olarak desteklememektedir ve bunların uygulamalara dahil edilmesi gerekmektedir. Bu, elbette, tehlikelidir ve çabanın tekrarlanmasına ve daha da kötüsü tutarsızlıklara yol açabilir. Ayrıca, ilişkisel modelde genel kısıtlamalar için destek yoktur, bu da yine DBMS'ye veya uygulamaya yerleştirilmeleri gerektiği anlamına gelir. 6. ve 7. Bölümlerde gördüğünüz gibi, SQL standardı, bazı sınırlama türlerinin Veri Tanımlama Dili'nin (DDL) bir parçası olarak belirtilmesine izin vererek bu iddia edilen eksikliğin kısmen giderilmesine yardımcı olur.

Homojen veri yapısı

İlişkisel model hem yatay hem de dikey homojenliği varsaymaktadır. Yatay homojenlik, bir ilişkinin her bir demetinin aynı özelliklerden oluşması gerektiği anlamına gelir. Dikey homojenlik, bir ilişkideki belirli bir sütundaki değerlerin hepsinin aynı alandan gelmesi gerektiği anlamına gelir.

Birçok RDBMS şimdi ikili büyük nesnelerin (BLOB'lar) depolanmasına izin veriyor. Bir BLOB, bir görüntüyü, dijitalleştirilmiş bir video veya ses dizisini, bir prosedürü veya herhangi bir büyük yapılandırılmamış nesneyi temsil eden ikili bilgileri içeren bir veri değeridir. DBMS, BLOB'un içeriği veya iç yapısı ile ilgili hiçbir bilgiye sahip değildir. Bu, DBMS'nin doğal olarak zengin ve yapılandırılmış veri türlerinde sorgular ve işlemler gerçekleştirmesini önler. Genellikle, veritabanı bu bilgiyi doğrudan yönetmez, ancak bir dosyaya referans içerir. BLOB'ların kullanımı zarif bir çözüm değildir ve bu bilgiyi harici dosyalarda saklamak, DBMS tarafından doğal olarak sağlanan korumaların çoğunu reddeder. Daha önemlisi, BLOB'lar başka BLOB'lar içeremez, bu yüzden bileşik nesnelerin şeklini alamazlar. Ayrıca, BLOB'lar genellikle nesnelerin davranışsal yönlerini görmezden gelir. Örneğin, bir resim bazı ilişkisel DBMS'lerde bir BLOB olarak saklanabilir. Ancak, resim yalnızca kaydedilebilir ve görüntülenebilir. Resmin iç yapısını değiştirmek veya resmin parçalarını görüntülemek veya değiştirmek mümkün değildir. BLOB'ların kullanımına bir örnek, Şekil 19.12'de verilmiştir.

Sınırlı operasyonlar

İlişkisel model, SQL spesifikasyonunda sağlanan işlemler ve set odaklı işlemler gibi yalnızca sabit bir işlem kümesine sahiptir. Ancak, SQL yeni işlemlerin belirlenmesine izin vermez. Yine, bu gerçek dünyadaki birçok nesnenin davranışını modellemek için çok kısıtlayıcı. Örneğin, bir GIS uygulaması tipik olarak noktalar, çizgiler, çizgi grupları ve çokgenler kullanır ve mesafe, kesişme ve çevreleme için işlemlere ihtiyaç duyar.

Özyinelemeli sorguları işleme zorluğu

Verinin atomikliği, ilişkisel modelde yinelenen gruplara izin verilmemesi anlamına gelir. Sonuç olarak, özyinelemeli sorguları, yani bir ilişkinin kendisiyle olan ilişkileri (doğrudan veya dolaylı olarak) sorgulamak son derece zordur. Personel numaralarını ve ilgili yöneticinin personel numarasını saklayan Şekil 9.1 (a) 'da gösterilen basitleştirilmiş Personel ilişkisini

düşünün. S005 personelini doğrudan veya dolaylı olarak yöneten tüm menajerleri nasıl buluruz? Hiyerarşinin ilk iki seviyesini bulmak için şunları kullanırız:

SELECT managerStaffNoFROM Staff

WHERE staffNo = ‘S005’UNIONSELECT managerStaffNo

FROM StaffWHERE staffNo = 5

(SELECT managerStaffNoFROM StaffWHERE staffNo = ‘S005’);

Bu sorgunun tam cevabını bulmak için bu yaklaşımı kolayca genişletebiliriz. Bu özel örnek için, bu yaklaşım işe yarar çünkü hiyerarşideki kaç seviyenin işlenmesi gerektiğini biliriz. Ancak, “Her bir personel için, bireyi doğrudan veya dolaylı olarak yöneten tüm yöneticileri bulun” gibi daha genel bir sorgu sormamız istenirse, bu yaklaşım etkileşimli SQL kullanarak uygulanamaz. Bu sorunun üstesinden gelmek için SQL, yinelemeyi kolaylaştıran yapılar sağlayan üst düzey bir programlama dilinde gömülü olabilir (bkz. Ek I). Ek olarak, birçok RDBMS benzer yapıya sahip bir rapor yazarı sağlar. Her iki durumda da, gerekli işlevselliği sağlayan sistemin doğasında olan yetenekleri yerine bir uygulamadır. Bu tür bir sorguyu ele almak için önerilen ilişkisel cebir için bir uzatma, geçici geçişli kapatma veya özyinelemeli kapatma işlemidir (Merrett, 1984):

Bu işlem yalnızca belirli sayıda ilişkisel cebir işlemiyle gerçekleştirilemez, ancak Birleştirme, Projeksiyon ve Birlik işlemleriyle birlikte bir döngü gerektirir. Bu operasyonun sadeleştirilmiş Personel ilişkimizdeki sonucu Şekil 9.1 (b) 'de gösterilmiştir.

Empedans uyumsuzluğu

Bölüm 6.1'de, SQL-92'nin işlemsel eksiksizlikten yoksun olduğunu belirttik. Bu, RDBMS'ler için çoğu Veri İşleme Dilinde (DML'ler) geçerlidir. Bu sorunun üstesinden gelmek ve ek esneklik sağlamak için SQL standardı, daha karmaşık veritabanı uygulamaları geliştirmeye yardımcı olmak için gömülü SQL sağlar (bkz. Ek I). Bununla birlikte, bu yaklaşım bir empedans uyumsuzluğu yaratır, çünkü farklı programlama paradigmalarını karıştırıyoruz:

• SQL, veri satırlarını işleyen bildirimsel bir dil iken, C gibi üst düzey bir dil bir kerede yalnızca bir satır veri işleyebilen yordamsal bir dildir.

• SQL ve 3GL'ler verileri temsil etmek için farklı modeller kullanır. Örneğin, SQL, geleneksel programlama dillerinde bulunmayan yerleşik tarih ve aralık veri türlerini sağlar. Bu nedenle, uygulama programının hem programlama çabasında hem de çalışma zamanı kaynaklarının kullanımında yetersiz olan iki sunum arasında dönüşüm yapılması gereklidir. Bu tür bir dönüşüm için programlama çabası ve kod alanının% 30 kadarının harcandığı tahmin edilmektedir (Atkinson ve diğerleri, 1983). Ayrıca, iki farklı tip sistem kullandığımız için, uygulamayı otomatik olarak bir bütün olarak kontrol etmek mümkün değildir. Bu sorunların çözümünün ilişkisel dilleri satır düzeyinde nesne yönelimli dillerle değiştirmenin değil, ayar düzeyindeki olanakları programlama dillerine getirmenin olduğu tartışılmaktadır (Tarih, 2000). Bununla birlikte, OODBMS'lerin temeli, DBMS’nin veri modeli ve ana bilgisayar programlama dili arasında daha sorunsuz bir entegrasyon sağlamaktır. Bu konuya Bölüm 27'de geri dönüyoruz.

RDBMS'lerle ilgili diğer sorunlar

• Ticari işlemlerdeki işlemler genel olarak kısa sürelidir ve iki fazlı kilitleme gibi eşzamanlılık kontrolü ilkeleri ve protokolleri özellikle karmaşık tasarım nesneleri için daha yaygın olan uzun süreli işlemler için uygun değildir (bu kitapta daha sonra Bölüm 22.4'e bakınız). ).

• Şema değişiklikleri zor. Veritabanı yöneticileri veritabanı yapılarını değiştirmek için müdahale etmeli ve genellikle bu yapılara erişen programlar yeni yapılara uyum sağlamak için değiştirilmelidir. Bunlar mevcut teknolojilerde bile yavaş ve zahmetli süreçlerdir. Sonuç olarak, çoğu kuruluş mevcut veritabanı yapılarına kilitlenir. Yeni gereksinimleri karşılamak için iş yapma şeklini değiştirmeye istekli olsalar bile, bu değişiklikleri yapamazlar, çünkü bilgi sistemlerini değiştirmek için gereken zaman ve masrafı karşılayamazlar (Taylor, 1992). Daha fazla esneklik ihtiyacını karşılamak için, doğal şema gelişimine hitap eden bir sisteme ihtiyacımız var.

• RDBMS'ler, içeriğe dayalı ilişkisel erişimi (bir veya daha fazla tahmini temel alan seçimi olan bildirimsel ifadeler) kullanacak şekilde tasarlanmıştır ve gezinme erişiminde (yani, bireysel kayıtlar arasındaki harekete göre erişim) yetersizdir. Gezinme erişimi, önceki bölümde tartıştığımız karmaşık uygulamaların çoğu için önemlidir. Bu üç problemden ilk ikisi sadece ilişkisel sistemler için değil, birçok DBMS'ye uygulanabilir. Aslında, bu tür mekanizmaların uygulanmasını önleyen ilişkisel modelde altta yatan bir sorun yoktur. SQL standardının en son sürümleri olan SQL: 2003, SQL: 2006, SQL: 2008 ve SQL: 2011, yeni veri türlerini ve işlemlerini bir parçası olarak tanımlayabilme yeteneği gibi birçok yeni özelliğin tanıtılmasıyla

birlikte bu eksikliklerin bazılarına değiniyor. veri tanımlama dili ve dili hesaplamalı olarak tamamlamak için yeni yapıların eklenmesi.

Nesneleri İlişkisel Veri Tabanında Saklamak

C ++ veya Java gibi nesne yönelimli bir programlama diliyle kalıcılık kazanmaya yönelik bir yaklaşım, altta yatan depolama motoru olarak bir RDBMS kullanmaktır. Bu, sınıf örneklerinin (yani nesnelerin) bir veya daha fazla ilişki üzerine dağıtılmış bir veya daha fazla tuza eşlenmesini gerektirir. Bu bölümde tartıştığımız gibi, sorunlu olabilir. Tartışma amaçları için, bir Kadro üst sınıfına ve üç alt sınıfa sahip Şekil 9.2'de gösterilen kalıtım hiyerarşisini göz önünde bulundurun: Yönetici, Satış Görevlisi ve Sekreter. Bu tür bir sınıf hiyerarşisini ele almak için gerçekleştirilecek iki temel görevimiz vardır:

• Sınıf hiyerarşisini temsil edecek ilişkileri tasarlayın.

• Nesnelere nasıl erişileceğini tasarlayın, bunun anlamı:

- nesneleri tuplere ayırmak ve ayrışmış nesneleri ilişkilerde saklamak için kod yazmak;

- İlişkileri incelemek ve nesneleri yeniden yapılandırmak için kod yazmak. Şimdi bu iki görevi daha ayrıntılı olarak açıklıyoruz.

Sınıfları İlişkilerle Eşlemek

Her biri anlamsal bilgi kaybıyla sonuçlanmasına rağmen, sınıfları ilişkilerle eşleştirmek için bir takım stratejiler vardır. Nesneleri kalıcı kılma ve nesneleri veritabanından geri okuma kodu seçilen stratejiye bağlıdır. Üç alternatif düşünüyoruz:

(1) Her sınıfı veya alt sınıfı bir ilişkiyle eşleyin.

(2) Her alt sınıfı bir ilişkiyle eşleyin.

(3) Hiyerarşiyi tek bir ilişkiyle eşleyin.

Her sınıfı veya alt sınıfı bir ilişkiyle eşleyin

Bir yaklaşım, her sınıfı veya alt sınıfı bir ilişkiyle eşlemektir. Şekil 9.2'de verilen hiyerarşi için bu, aşağıdaki dört ilişkiyi verecektir (altı çizili birincil anahtarla):

Staff (staffNo, fName, lName, position, sex, DOB, salary)Manager (staffNo, bonus, mgrStartDate)SalesPersonnel (staffNo, salesArea, carAllowance)Secretary (staffNo, typingSpeed)

Her bir özniteliğin temelindeki veri türünün RDBMS tarafından desteklendiğini varsayıyoruz, ancak bu böyle olmayabilir; bu durumda bir veri türünün diğerine dönüşümünü işlemek için ek kod yazmamız gerekir. Ne yazık ki, bu ilişkisel şema ile anlamsal bilgiyi kaybettik: artık hangi ilişkinin üst sınıfı temsil ettiği ve hangi ilişkilerin alt sınıfları temsil ettiği artık net değil. Bu nedenle, bu bilgiyi, başka yerlerde de belirttiğimiz gibi, kodun ve ortaya çıkan tutarsızlıkların ortaya çıkma potansiyelinin tekrarlanmasına yol açabileceği gibi, her uygulamaya dahil etmek zorunda kalacağız.

Her alt sınıfı bir ilişkiyle eşleyin

İkinci bir yaklaşım, her bir alt sınıfı bir ilişkiyle eşlemektir. Şekil 9.2'de verilen hiyerarşi için bu, aşağıdaki üç ilişkiyi verir:

Manager (staffNo, fName, lName, position, sex, DOB, salary, bonus, mgrStartDate)SalesPersonnel (staffNo, fName, lName, position, sex, DOB, salary, salesArea, carAllowance)Secretary (staffNo, fName, lName, position, sex, DOB, salary, typingSpeed)

Yine, bu haritalamada anlamsal bilgileri kaybettik: Bu ilişkilerin artık tek bir genel sınıfın alt sınıfları olduğu açık değildir. Bu durumda, tüm personelin bir listesini çıkarmak için her ilişkiden gelen trolleri seçip sonuçları birleştirmeliyiz.

Hiyerarşiyi tek bir ilişkiyle eşleyin

Üçüncü bir yaklaşım, miras hiyerarşisinin tamamını tek bir ilişkiyle eşleştirmek, bu durumda:

Staff ( staffNo, fName, lName, position, sex, DOB, salary, bonus, mgrStartDate, salesArea,carAllowance, typingSpeed, typeFlag)

TypeFlag niteliği, her bir dilin hangi tür olduğunu ayırt etmek için bir ayırımcıdır (örneğin, bir Yönetici grubu için 1, bir SalesPersonnel grubu için 2 ve bir Sekreter grubu için 3 değeri içerebilir). Yine, bu haritalamada anlamsal bilgileri kaybettik. Ek olarak, bu haritalama, o dize için geçerli olmayan nitelikler için istenmeyen sayıda boş değer üretecektir. Örneğin, bir Yönetici grubu için salesArea, carAllowance ve typingSpeed nitelikleri boş olacaktır.

İlişkisel Veritabanındaki Nesnelere Erişim

İlişkisel veritabanının yapısını tasarladıktan sonra, şimdi veritabanına nesneleri eklememiz ve ardından nesneleri okumak, güncellemek ve silmek için bir mekanizma sağlamamız gerekir. Örneğin, önceki bölümdeki ilk ilişkisel şemaya bir nesne eklemek için (her sınıf için bir ilişki oluşturduğumuz), kod programatik SQL kullanarak aşağıdaki gibi görünebilir (bkz. Ek I):

Öte yandan, Yönetici kalıcı bir sınıf olarak bildirildiyse, aşağıdaki (endikatif) ifade, nesneyi bir OODBMS'de kalıcı kılar:

Manager * pManager = newManager;

İlişkisel veritabanından bir miktar veri almak istiyorsak, 1000 sterlinin üzerindeki bonusu olan yöneticiler için ayrıntıları söyleyin, kod aşağıdaki gibi görünebilir:

Manager* pManager 5 new Manager; // create a new Manager objectEXEC SQL WHENEVER NOT FOUND GOTO done; // set up error handlingEXEC SQL DECLARE managerCursor // create cursor for SELECTCURSOR FORSELECT staffNo, fName, lName, salary, bonusFROM Staff s, Manager m // Need to join Staff and ManagerWHERE s.staffNo 5 m.staffNo AND bonus > 1000;EXEC SQL OPEN managerCursor;for ( ; ; ) {EXEC SQL FETCH managerCursor // fetch the next record in the resultINTO :staffNo, :fName, :lName, :salary, :bonus;pManager->staffNo 5 :staffNo; // transfer the data to the Manager objectpManager->fName 5 :fName;pManager->lName 5 :lName;pManager->salary 5 :salary;pManager->bonus 5 :bonus;strcpy(pManager->position, “Manager”);

}EXEC SQL CLOSE managerCursor; // close the cursor before completing

Öte yandan, bir OODBMS'de aynı veri kümesini almak için aşağıdaki kodu yazabiliriz:

os_Set<Manager*> &highBonus= managerExtent->query(“Manager*”, “bonus > 1000”, db1);

Bu ifade, veri tabanından gerekli örnekleri (bonus> 1000) bulmak için Manager sınıfının (managerExtent) kapsamını sorgular (bu örnekte, db1). Ticari OODBMS ObjectStore, os_Set adlı bir koleksiyon şablon sınıfına sahiptir; bu örnekte, Yönetici nesnelerine <Yönetici *> işaretçileri içerecek şekilde örneklenmiştir. Bölüm 28.3'te, ObjectStore ile nesne kalıcılığı ve nesne alımının ek ayrıntılarını sunuyoruz. Önceki örnekler, nesne yönelimli bir dilin ilişkisel bir veritabanına eşleştirilmesinde rol oynayan karmaşıklıkları göstermek için verilmiştir. Bölüm 27 ve 28'de tartıştığımız OODBMS yaklaşımı, programlama dili veri modelinin ve veri tabanı veri modelinin daha sorunsuz bir entegrasyonunu sağlamaya çalışır, böylece daha önce tartıştığımız gibi daha önce ele alabileceğimiz karmaşık dönüşümlere olan ihtiyacı ortadan kaldırır.

Nesne İlişkisel Veri Tabanı Sistemlerine Giriş

İlişkisel DBMS'ler şu anda baskın bir veritabanı teknolojisidir ve 2011'de dünya genelinde toplam yazılım geliri 24 milyar ABD doları olarak tahmin edilmektedir ve 2016 yılına kadar yaklaşık 37 milyar ABD doları olacağı tahmin edilmektedir. Yakın zamana kadar, DBMS'nin seçimi ilişkisel DBMS ile ABD arasında nesne yönelimli DBMS. Bununla birlikte, birçok RDBMS ürünü satıcısı, OODBMS'nin tehdidi ve vaadinden haberdardır. Geleneksel ilişkisel DBMS'lerin, Bölüm 9.1'de açıklanan ileri düzey uygulamalar için uygun olmadığına ve ilave işlevlerin gerekli olduğuna katılıyorlar. Bununla birlikte, genişletilmiş RDBMS'lerin yeterli işlevsellik sağlamayacağı veya yeni karmaşıklıkla yeterince başa çıkmak için çok yavaş olacağı iddiasını reddetmektedirler. Ortaya çıkan gelişmiş veritabanı uygulamalarını incelersek, kullanıcıların genişletilebilir bir tür sistemi, kapsülleme, kalıtım, polimorfizm, yöntemlerin dinamik bağlanması, ilk normal olmayanlar da dahil olmak üzere karmaşık nesneler gibi birçok nesne yönelimli özelliği kullandıklarını görüyoruz nesneler ve nesne kimliği oluşturur. İlişkisel modelin eksikliklerini gidermenin en belirgin yolu, modeli bu özelliklerle genişletmektir. Her biri farklı özellik kombinasyonları uygulamış olmasına rağmen, birçok genişletilmiş ilişkisel DBMS tarafından benimsenen yaklaşım budur. Dolayısıyla, tek bir genişletilmiş ilişkisel model yoktur; bunun yerine, özellikleri uzatmaların yapıldığı yola ve derecesine bağlı olan çeşitli modeller vardır. Bununla birlikte, tüm modeller aynı temel ilişkisel tabloları ve sorgu dilini paylaşır, hepsi bir miktar “nesne” kavramını içerir ve bazıları veri tabanındaki yöntemleri (veya prosedürleri veya tetikleyicileri) ve ayrıca verileri saklama yeteneğine sahiptir. İlişkisel veri modelini genişleten sistemler için çeşitli terimler kullanılmıştır. Bu sistemleri tanımlamak için kullanılan orijinal terim Genişletilmiş İlişkisel DBMS (ERDBMS) idi ve Evrensel Sunucu veya Evrensel DBMS (UDBMS) terimi de kullanılmıştır. Bununla birlikte, son yıllarda daha açıklayıcı bir Nesne İlişkisel DBMS terimi, sistemin bazı “nesne” kavramını içerdiğini belirtmek için kullanılmıştır. Bu bölümde, Nesne İlişkisel DBMS (ORDBMS) terimini kullanıyoruz. Önde gelen RDBMS tedarikçilerinden üçü - Oracle, Microsoft ve IBM - her birinin sağladığı işlevsellik biraz farklı olsa da, sistemlerini

ORDBMS'lere genişletti. RDBMS ve OODBMS'nin bir melezi olarak ORDBMS kavramı, RDBMS ile edinilen bilgi ve deneyim zenginliğini koruyarak çok çekicidir - öyle ki bazı analistler ORDBMS'nin% 50 daha büyük olacağını tahmin ediyor RDBMS'den daha pazar payı.

Beklenebileceği gibi, bu alandaki standartlar etkinliği, SQL standardının uzantılarına dayanmaktadır. Ulusal standartlar organları 1991'den beri SQL'e yönelik nesne uzantıları üzerinde çalışmaktadır. Bu uzantılar, SQL için 1999, SQL: 1999, 2003, (SQL: 2003), 2006 olarak adlandırılan sürümlerle birlikte SQL standartlarının bir parçası olmuştur. (SQL: 2006), 2008 (SQL: 2008) ve 2011 (SQL: 2011). SQL standardının bu sürümleri, ilişkisel model ve sorgu dili için uzantıları standartlaştırmaya devam eden bir girişimdir. Bu bölümde SQL'in nesne uzantılarını biraz detaylı olarak tartışıyoruz. Bu kitapta, genellikle standartların 1999, 2003, 2006, 2008 ve 2011 sürümlerine atıfta bulunmak için SQL: 2011 terimini kullanırız.

Stonebraker’ın görünümü

Stonebraker (1996), Şekil 9.3'te gösterildiği gibi, veritabanı dünyasının dört kadranlı bir görünümünü önermiştir. Sol alt kadranda, basit verileri işleyen ve verileri sorgulamak için hiçbir gereksinimi olmayan uygulamalardır. Bu uygulama türleri (örneğin, Microsoft Word gibi standart metin işleme paketleri), temel işletim sistemini kalıcılık için temel DBMS işlevselliğini elde etmek üzere kullanabilir. Sağ alt kadranda, karmaşık verileri işleyen, ancak yine de verileri sorgulamak için önemli bir gereksinim bulunmayan uygulamalardır. Bu uygulama türleri için - örneğin, bilgisayar destekli tasarım paketleri - bir OODBMS uygun bir DBMS seçimi olabilir. Sol üst kadranda, basit verileri işleyen ve aynı zamanda karmaşık sorgulama gereksinimleri olan uygulamalardır. Birçok geleneksel iş uygulaması bu kadranda yer alır ve bir RDBMS en uygun DBMS olabilir. Son olarak, sağ üst kadranda, karmaşık verileri işleyen ve karmaşık sorgulama gereksinimleri olan uygulamalardır. Bu, Bölüm 9.1'de incelediğimiz gelişmiş veritabanı uygulamalarının çoğunu temsil eder ve bu uygulamalar için Stonebraker, bir ORDBMS'nin DBMS'nin en uygun seçenek olabileceğini savunur.

Her ne kadar ilginç olsa da, bu çok basit bir sınıflandırmadır ve ne yazık ki birçok veritabanı uygulaması bu kadar kolay bölümlenemez. Ayrıca, Bölüm 28.2'de tartışacağımız ODMG veri modelinin ve sorgu dilinin tanıtılması ve nesneye yönelik veri yönetimi özelliklerinin SQL'e eklenmesiyle, ORDBMS ve OODBMS arasındaki fark daha az belirgindir.

ORDBMS'lerin Avantajları

Bölüm 9.2'de belirtilen zayıf yönlerin çoğunun çözülmesinin avantajlarının yanı sıra, ilişkisel veri modelini genişletmenin temel avantajları yeniden kullanım ve paylaşımdan kaynaklanmaktadır. Yeniden kullanma, her uygulamada kodlanmış yerine DBMS sunucusunu merkezi olarak standart işlevsellik sağlayacak şekilde genişletme özelliğinden kaynaklanır. Örneğin, uygulamalar, iki nokta arasındaki mesafeyi, bir nokta ile bir çizgi arasındaki mesafeyi, bir noktanın çokgenin içinde olup olmadığını ve iki nokta arasındaki mesafeyi hesaplayan ilişkili işlevleri olan, noktaları, çizgileri ve çokgenleri temsil eden uzamsal veri türlerini gerektirebilir. poligonal bölgeler diğerleri arasında örtüşür. Bu işlevselliği sunucuya yerleştirebilirsek, ihtiyacı olan her uygulamada tanımlamak zorunda kalmamamız ve sonuç olarak da işlevselliğin tüm uygulamalar tarafından paylaşılmasını sağlar. Bu avantajlar aynı zamanda hem geliştirici hem de son kullanıcı için üretkenliği arttırmaktadır.

Açıkça görülen bir diğer avantaj, genişletilmiş ilişkisel yaklaşımın, ilişkisel uygulamalar geliştirmeye başlamış olan önemli bilgi ve tecrübeyi koruduğudur. Bu, çok sayıda kuruluşun değiştirmeyi çok pahalı bulduğu için bu önemli bir avantajdır. Yeni işlevsellik uygun şekilde tasarlanırsa, bu yaklaşım mevcut veritabanı özelliklerinin ve işlevlerinin faydalarını kaybetmeden kuruluşların yeni uzantılardan evrimsel bir şekilde yararlanmalarına olanak sağlamalıdır. Bu nedenle, bir ORDBMS, kavram kanıtı projeleri olarak bütünleştirici bir şekilde tanıtılabilir. SQL: 2011 standardı, SQL2 standardıyla uyumlu olacak şekilde tasarlanmıştır ve bu nedenle SQL: 2011 ile uyumlu olan herhangi bir ORDBMS bu özelliği sağlamalıdır.

ORDBMS'lerin Dezavantajları

ORDBMS yaklaşımı, karmaşıklığın ve de buna bağlı artan maliyetlerin belirgin dezavantajlarına sahiptir. Ayrıca, ilişkisel modelin temel sadeliğinin ve saflığının bu uzatma türleriyle kaybolduğuna inanan ilişkisel yaklaşımın savunucuları da vardır. Mevcut ilişkisel teknoloji ile optimum performans elde edemeyen uygulamaların azınlık olacağı için RDBMS'nin genişletildiğine inananlar da var. Ek olarak, nesne yönelimli temizleyiciler de bu uzantılardan etkilenmemektedir. Nesne-ilişkisel sistemlerin terminolojisinin açığa çıktığını savunuyorlar. Nesne modellerini tartışmak yerine, “kullanıcı tanımlı veri türleri” gibi terimler kullanılır. Nesne yönelimi terminolojisi, “soyut türler”, “sınıf hiyerarşileri” ve “nesne modelleri” gibi terimlerle doludur. Ancak, ORDBMS satıcıları, nesne modellerini, bazı ek karmaşıklıklarla ilişkisel modele genişletme olarak göstermeye çalışıyor. Bu potansiyel olarak, bu iki teknoloji arasındaki büyük anlamsal boşluğu vurgulayarak, nesne yönelimi noktasını özlüyor. Nesne uygulamaları, ilişkisel temelli uygulamalar kadar veri merkezli değildir. Nesneye yönelik modeller ve programlar, gerçek dünyayı daha yakından yansıtmak için ilişkileri ve kapsüllenmiş nesneleri derinden birleştirir. Bu, SQL'de ifade edilenlerden daha geniş bir ilişki kümesini tanımlar ve nesne tanımlarında serpiştirilmiş işlevsel programları

içerir. Aslında, nesneler temelde veri uzantıları değil, gerçek dünyadaki ilişkileri ve davranışları ifade etme gücü çok daha büyük olan tamamen farklı bir kavramdır.

6. Bölümde, veritabanı dili hedeflerinin, asgari kullanıcı çabasıyla kullanılabilme kabiliyetine sahip olduğunu ve öğrenmesi nispeten kolay olması gereken bir komut yapısına ve sözdizimine sahip olduğunu ekledik. 1989’da yayımlanan ilk SQL standardı bu hedefleri karşıladı. 1992'deki sürümün boyutu 120 sayfadan yaklaşık 600 sayfaya çıktı ve bu hedeflere ulaşıp ulaşmadığı daha tartışmalı. Ne yazık ki, SQL: 2011 standardının boyutu daha da korkutucu ve bu iki hedefin artık yerine getirilmediği ya da standart organları tarafından bile göz önüne alınmadığı anlaşılıyor.

SQL: 2011

Bölüm 6 ve 7'de, genellikle SQL2 veya SQL-92 olarak adlandırılan, standardın 1992 sürümünde bulunan özelliklere odaklanan, ISO SQL standardının özellikleri hakkında kapsamlı bir eğitim sağladık. ANSI (X3H2) ve ISO (ISO / IEC JTC1 / SC21 / WG3) SQL standardizasyonu, en son sürümü SQL: 2011 olan nesne yönelimli veri yönetimini desteklemek için SQL özelliklerine özellikler eklemiştir (ISO, 2011a). Daha önce de belirttiğimiz gibi, SQL: 2011 standardı son derece geniş ve kapsamlı ve aşağıdaki bölümlere ayrılmıştır:

(1) ISO / IEC 9075-1: SQL / Çerçeve.

(2) ISO / IEC 9075–2: yeni veri tipleri, kullanıcı tanımlı türler, kurallar ve tetikleyiciler, işlemler, depolanan rutinler ve ciltleme yöntemleri (gömülü SQL, dinamik SQL ve doğrudan SQL çağrısı) içeren SQL / Foundation .

(3) ISO / IEC 9075–3: SQL Access Group ve X / Open'ın CLI'sine dayanarak Ek I'de tartışacağımız gibi veritabanına bir API arayüzü sağlanmasını belirten SQL / CLI (Çağrı Seviyesi Arayüzü) tanımlar.

(4) ISO / IEC 9075–4: Prosedürlerin ve kullanıcı tanımlı fonksiyonların bir 3GL veya SQL'de yazılmasını ve veritabanında saklanmasını ve SQL'in hesaplamalı olarak tamamlanmasını sağlayan SQL / PSM (Kalıcı Kayıtlı Modüller).

(5) ISO / IEC 9075–9: Dış tabloların ve veri bağlantısı veri türlerinin kullanılması yoluyla dış verilerin yönetimini desteklemek için SQL uzantılarını tanımlayan SQL / MED (Dış Veri Yönetimi).

(6) ISO / IEC 9075–10: SQL deyimlerini Java programlarına yerleştirme olanaklarını tanımlayan SQL / OLB (Nesne Dili Bağlamaları).

(7) ISO / IEC 9075–11: İki şema tanımlayan SQL / Schemata (Bilgi ve Tanım Şemaları), INFORMATION_SCHEMA ve DEFINITION_ SCHEMA. Bilgi Şeması, tablolar, görünümler ve sütunlar gibi veritabanı nesneleri hakkındaki görünümleri tanımlar. Bu görünümler Tanım Şeması'ndaki temel tablolara göre tanımlanmıştır.

(8) ISO / IEC 9075–13: Java'da yazılmış statik yöntemlerin SQL tarafından başlatılan yordamlar olarak çağrılmasını sağlamak ve sınıfları kullanmak için SQL uzantılarını tanımlayan

SQL / JRT (Java Programlama Dilini Kullanarak Java Rutinleri ve Türleri) Java'da SQL yapılı tipler olarak tanımlanır.

(9) ISO / IEC 9075–14: XML belgelerinin oluşturulmasını ve değiştirilmesini sağlamak için SQL uzantılarını tanımlayan SQL / XML (XML ile İlgili Özellikler). Bu bölümde, bu özelliklerden bazılarını inceliyoruz ve aşağıdaki konuları ele alıyoruz:

• satır tipleri ve referans tipleri için tip yapıcıları;

• Üst tip / alt tip ilişkilerine katılabilecek kullanıcı tanımlı tipler (farklı tipler ve yapısal tipler);

• kullanıcı tanımlı prosedürler, fonksiyonlar, yöntemler ve operatörler;

• toplama tipleri için tip yapıcılar (diziler, kümeler, listeler ve çoklu kümeler);

• büyük nesneler için destek — İkili Büyük Nesneler (BLOB'lar) ve Büyük Karakterler (CLOB'lar);

• özyineleme.

Ek K'da tartıştığımız nesne yönelimli konseptlerin çoğu öneridedir. SQL: 1999 standardının kesin sürümü programın önemli ölçüde gerisinde kaldı ve nesne yönetimi özelliklerinden bazıları standardın sonraki bir sürümüne ertelendi. Bunların çoğu hala SQL: 2011'de eksik.

Satır Türleri

Bir satır türü, tablolardaki satır türlerini temsil etmek için bir veri türü sağlayan bir alan adı / veri türü çifti dizisidir, böylece tüm satırlar değişkenlerde saklanabilir, değişkenlere argümanlar olarak iletilebilir ve işlev çağrılarından döndürülen değerler olarak döndürülebilir. Satır değerleri, bir tablonun sütununun satır değerleri içermesine izin vermek için de kullanılabilir. Temelde, satır bir tablonun içine yerleştirilmiş bir tablodur.

ÖRNEK 9.1 Satır türünün kullanımı

Satır türlerinin kullanımını göstermek için, şube numarası ve adresinden oluşan basitleştirilmiş bir Şube tablosu oluşturur ve yeni tabloya bir kayıt ekleriz:

CREATE TABLE Branch (

branchNo CHAR(4),

address ROW(street VARCHAR(25),

city VARCHAR(15),

postcode ROW(cityIdentifier VARCHAR(4),

subPart VARCHAR(4))));

INSERT INTO Branch

VALUES(‘B005’, ROW(‘23 Deer Rd’, ‘London’, ROW(‘SW1’, ‘4EH’)));

UPDATE Branch

SET address = ROW (‘23 Deer Rd’, ‘London’, ROW(‘SW1’, ‘4EH’))

WHERE address = ROW (‘23 Deer Rd’, ‘London’, ROW(‘SW1’, ‘4EH’));

Kullanıcı tanımlı türler

SQL: 2011, daha önce soyut veri türleri (ADT'ler) olarak adlandırdığımız, kullanıcı tanımlı türlerin (UDT'ler) tanımlanmasına izin verir. Önceden tanımlanmış tiplerle aynı şekilde kullanılabilirler (örneğin, CHAR, INT, FLOAT). UDT'ler iki kategoriye ayrılır: farklı türler ve yapılandırılmış türler. Basit UDT tipi, aynı temel tipler arasında farklılaşmaya izin veren farklı tiptir. Örneğin, aşağıdaki iki farklı türü oluşturabiliriz:

CREATE TYPE OwnerNumberType AS VARCHAR(5) FINAL;

CREATE TYPE StaffNumberType AS VARCHAR(5) FINAL;

Şimdi bir türün örneğini diğer türün bir örneği olarak ele almaya çalışırsak, bir hata oluşacaktır. Her ne kadar SQL, alanların yaratılmasının farklı veri türleri arasında ayrım yapmasına izin vermesine rağmen, bir SQL alanının amacı, yalnızca bu alanla birlikte bir sütunda saklanabilecek geçerli değerler kümesini sınırlamaktır. Daha genel bir durumda, bir UDT tanımı bir veya daha fazla nitelik tanımından, sıfır veya daha fazla rutin beyandan (yöntem) ve sonraki bir sürümde operatör beyanlarından oluşur. Genel olarak rutinleri ve işleçleri rutin olarak adlandırırız. Ek olarak, CREATE ORDERING FOR deyimini kullanarak UDT için eşitlik ve sıralama ilişkilerini de tanımlayabiliriz. Bir özelliğin değerine ortak nokta gösterimi (.) Kullanılarak erişilebilir. Örneğin, pis, fNameof türü VARCHAR özniteliğine sahip olan UDT PersonType örneğini varsayarsak, fNameattribute işlevine şu şekilde erişebiliriz:

p.fName

p.fName =‘A. Smith’

Kapsülleme ve gözlemci ve mutatör fonksiyonları

SQL, bir kullanıcı nitelik, bir gözlemci (get) işlevi ve bir mutator (set) işlevini referans almaya çalıştığında çağrılan bir çift yerleşik yordam sağlayarak, yapılandırılmış türlerin her bir özelliğini kapsar. Gözlemci işlevi, özniteliğin geçerli değerini döndürür; mutator işlevi, attrib-ute değerini parametre olarak belirtilen bir değere ayarlar. Bu fonksiyonlar kullanıcı tarafından UDT tanımında yeniden tanımlanabilir. Bu şekilde, öznitelik değerleri kapsüllenir ve kullanıcıya yalnızca bu işlevleri çağırarak erişilebilir. Örneğin, PersonTypewo'daki fNameattribute için gözlemci işlevi şöyle olabilir:

Yapıcı fonksiyonlar ve NEW ifadesi

A (public) yapıcı işlevi, türün yeni örneklerini oluşturmak için otomatik olarak tanımlanır. Yapıcı işlevi, UDT ile aynı ada ve türe sahiptir, sıfır argümanları alır ve özniteliklerin varsayılan değerlerine ayarlanmış olan türün yeni bir örneğini döndürür. Kullanıcı tanımlı yapıcı yöntemleri, yapılandırılmış bir türün yeni oluşturulan örneğini başlatmak için kullanıcı tarafından sağlanabilir. Her yöntem, yapılandırılmış türle aynı ada sahip olmalıdır, ancak parametreler sistem tarafından sağlanan yapıcıdan farklı olmalıdır. Ek olarak, her kullanıcı tanımlı yapıcı yöntem, parametre sayısında veya parametre veri türlerinde farklılık göstermelidir. Örneğin, PersonTypeas türü için bir kurucu başlatabiliriz:

CREATE CONSTRUCTOR METHOD PersonType(fN VARCHAR(15),

lN VARCHAR(15), sx CHAR) RETURNS PersonType SELF AS RESULT

BEGIN

SET SELF.fName 5 fN;

SET SELF.lName 5 lN;

SET SELF.sex 5 sx;

RETURN SELF;

END;

NEW ifadesi, sistem tarafından sağlanan yapıcı işlevini çağırmak için kullanılabilir; Örneğin:

SET p = NEW PersonType();

Kullanıcı tanımlı yapıcı yöntemleri, NEW ifadesi bağlamında çağrılmalıdır. Örneğin, yeni bir PersonTypean örneği oluşturabilir ve önceki kullanıcı tanımlı yapıcı yöntemini şu şekilde çağırabiliriz:

SET p = NEW PersonType(‘John’, ‘White’, ‘M’);

Bu etkili bir şekilde çevrilir:

SET p = PersonType().PersonType(‘John’, ‘White’, ‘M’);

Diğer UDT yöntemleri

UDT örnekleri, belirtilen sipariş özelliklerini sergilemek için kısıtlanabilir. SADECE BY ve SİPARİŞ FULL BY yan tümceleri cümleleri, UDT örneklerini karşılaştırmak için özel özellikler belirlemek için kullanılabilir. Sipariş yapılabilir

Nitelikli yöntemleri kullanarak:

• RELATIVE. Göreceli yöntem, eşittir için 0 döndüren, küçük değer için negatif bir değer ve büyük değer için pozitif bir değer veren bir işlevdir.

• MAP. Map yöntemi, UDT türünün tek bir argümanını alan ve önceden tanımlanmış bir veri türü döndüren bir işlev kullanır. İki UDT'nin karşılaştırılması, bunlarla ilişkili iki harita değerinin karşılaştırılmasıyla elde edilir.

•STATE. Durum yöntemi, bir emir belirlemek için işlenenlerin özelliklerini karşılaştırır. CAST işlevleri, farklı UDT'ler arasında kullanıcı tarafından belirlenen dönüşüm işlevlerini sağlamak için de tanımlanabilir. Standardın sonraki bir versiyonunda, yerleşik operatörlerin bazılarının geçersiz kılınması da mümkün olabilir.

ÖRNEK 9.2 Yeni bir UDT'nin tanımı

Yeni bir UDT'nin oluşturulmasını göstermek için, bir PersonType için bir UDT oluştururuz.

CREATE TYPE PersonType AS(

dateOfBirth DATE,

fName VARCHAR(15),

lName VARCHAR(15),

sex CHAR)

INSTANTIABLE

NOT FINAL

REF IS SYSTEM GENERATED

INSTANCE METHOD age () RETURNS INTEGER,

INSTANCE METHOD age (DOB DATE) RETURNS PersonType;

CREATE INSTANCE METHOD age () RETURNS INTEGER

FOR PersonType

BEGIN

RETURN/* age calculated from SELF.dateOfBirth*/;

END;

CREATE INSTANCE METHOD age (DOB DATE) RETURNS PersonType

FOR PersonType

BEGIN

SELF.dateOfBirth = /* code to set dateOfBirth from DOB*/;

RETURN SELF;

END;

Bu örnek ayrıca, mağaza ve sanal niteliklerin kullanımını da gösterir. Saklanan bir özellik, bir özellik adı ve veri türü olan varsayılan türdür. Veri türü, diğer UDT'ler dahil olmak üzere bilinen herhangi bir veri türü olabilir. Buna karşılık, sanal nitelikler depolanan verilere değil, türetilmiş verilere karşılık gelir. (Gözlemci) yaşı işlevi kullanılarak türetilen ve (mutatör) yaşı işlevi kullanılarak atanan zımni bir sanal özellik yaşı vardır. Kullanıcının bakış açısına göre, saklanan bir özellik ile sanal bir özellik arasında ayırt edici bir fark yoktur - her ikisine de karşılık gelen gözlemci ve mutator fonksiyonları kullanılarak erişilebilir. Sadece UDT'nin tasarımcısı farkı anlayacaktır. INSTANTIABLE anahtar sözcüğü, bu tür için örneklerin oluşturulabileceğini gösterir. INSTANTIABLE, belirtilmiş olsaydı, bu türden örnekler oluşturamazdık, yalnızca bir alt türünden. NOT FINAL anahtar sözcüğü, bu kullanıcı tanımlı türden alt türler oluşturabileceğimizi gösterir.

Alt Tipler ve Süper Tipler

SQL: 2011, UDT'lerin UNDER yan tümcesini kullanarak alt / üst tip hiyerarşisine katılmalarına izin verir. Bir tür birden fazla alt tür içerebilir, ancak şu anda yalnızca bir üst tür (yani, birden fazla devralma desteklenmez). Bir alt tip, üst tipinin tüm özelliklerini ve davranışlarını (metotlarını) devralır ve diğer herhangi bir UDT gibi ek nitelikleri ve metotları tanımlayabilir ve kalıtsal metodları geçersiz kılabilir.

ÖRNEK 9.3 UNDER yan tümcesini kullanarak bir alt tür oluşturulması

StaffTyptyp alt türü PersonType alt türü oluşturmak için şunu yazıyoruz:

CREATE TYPE StaffType UNDER PersonType AS(staffNo VARCHAR(5),position VARCHAR(10) DEFAULT‘Assistant’,salary DECIMAL(7, 2),branchNo CHAR(4))INSTANTIABLENOT FINALINSTANCE METHOD isManager () RETURNS BOOLEAN;CREATE INSTANCE METHOD isManager() RETURNS BOOLEANFOR StaffTypeBEGINIF SELF.position =‘Manager’ THENRETURN TRUE;ELSERETURN FALSE;END IFEND)

StaffType, CREATE TYPE içinde tanımlanmış niteliklere sahip olmasının yanı sıra, ilişkili gözlemci ve mutator fonksiyonlarıyla ve belirtilen tüm yöntemlerle birlikte PersonType'ın kalıtsal niteliklerini de içerir. Özellikle, REF IS SYSTEM GENERATED maddesi de devralınmıştır. Ek olarak, bir örnek yöntem tanımladık, belirtilen personelin bir Yönetici olup olmadığını kontrol eden Yönetici.

Bir alt tip örneği, tüm süper tiplerinin bir örneği olarak kabul edilir. SQL: 2011 ikame edilebilirlik kavramını desteklemektedir: yani, bir üst tip örneği beklendiğinde, alt tipin bir örneği yerine kullanılabilir. Bir UDT tipi, TYPE yüklemi kullanılarak test edilebilir. Örneğin, bir UDT verildiğinde, Udt1 diyelim, aşağıdaki testleri uygulayabiliriz:

TYPE Udt1 IS OF(PersonType) // Check Udt1is the PersonTypeor any of its subtypes

TYPE Udt1 IS OF(ONLY PersonType) // Check Udt1is the PersonType

SQL: 2011'de, çoğu programlama dilinde olduğu gibi, bir UDT'nin her bir örneği, örneğe atanan en düşük alt türe karşılık gelen tam olarak en spesifik türle ilişkilendirilmelidir. Bu nedenle, eğer UDT'nin birden fazla doğrudan üst tipe sahip olması durumunda, örneğin ait olduğu tek bir tip olmalı ve bu tek tip, örneğin ait olduğu tüm tiplerin bir alt tipi olmalıdır. Bazı durumlarda, bu çok sayıda tür oluşturulmasını gerektirebilir. Örneğin, bir tür hiyerarşisi, Studentand Staffas alt tipleriyle maksimum üst tip bir Kişi'den oluşabilir; Öğrencinin kendisinin üç doğrudan alt tipi olabilir: Lisans, Lisansüstü ve PartTimeStudent, Şekil 9.4 (a) 'da gösterildiği gibi. Bir örnek Kişi ve Öğrenci türüne sahipse, bu durumda en belirgin tür Öğrenci, Kişi alt türü olduğundan, yapraksız tür Öğrenci'dir. Bununla birlikte, mevcut tip hiyerarşisi ile bir örnek, Şekil 9.4 (b) 'de gösterildiği gibi bir PTStudentStaff tipi yaratmadıkça, PartTimeStudent ve Staff türüne sahip olamaz. Yeni yaprak tipi, PTStudentStaff, o zaman bu örneğin en özel türüdür. Benzer şekilde, tam zamanlı lisans ve lisans üstü öğrencilerden bazıları yarı zamanlı çalışabilir (tam zamanlı çalışanların yarı zamanlı öğrenci olmalarının aksine) ve bu nedenle FTUGStaff ve FTPGStaff için alt türler eklemek zorunda kalacağız. Bu yaklaşımı genelleştirirsek, potansiyel olarak çok sayıda alt tip yaratabiliriz. Bazı durumlarda, kısaca tartıştığımız gibi kalıtımın, türlerin aksine tablolar düzeyinde kullanılması daha iyi bir yaklaşım olabilir.

Ayrıcalıklar

Bir alt tip oluşturmak için, bir kullanıcının alt tip tanımında bir üst tip olarak belirtilen kullanıcı tanımlı tür üzerinde UNDER imtiyazı olması gerekir. Ek olarak, bir kullanıcının yeni tip içinde referans verilen herhangi bir kullanıcı tanımlı tür üzerinde KULLANIM imtiyazı olması gerekir. SQL'den önce: 1999, SELECT ayrıcalığı yalnızca tablo ve görünüm sütunlarına uygulanır. SQL: 1999'dan, SELECT ayrıcalığı, yapılandırılmış türler için de geçerlidir, ancak yalnızca bu türlerin örnekleri yazılan tablolarda depolandığında ve yalnızca dereference operatörü bir REF değerinden başvurulan satıra kullanıldığında ve sonra başvurulan bir yöntem çağırdığında kürek çekmek. Herhangi bir sıradan SQL tablosunun bir sütununda depolanan bir yapılandırılmış değere bir yöntem çağırırken, bu sütunda SELECT ayrıcalığı gerekir. Yöntem bir mutator işlevi ise, sütunda UPDATE ayrıcalığı gerekir. Ek olarak, çağrılan tüm yöntemlerde EXECUTE ayrıcalığı gerekir.

Kullanıcı Tanımlı Rutinler

Kullanıcı tanımlı rutinler (UDR'ler) verileri değiştirmek için yöntemler tanımlar ve UDT'ler için gerekli davranışı sağlayan UDT'lere ek bir yardımcıdır.

Bir ORDBMS, bu alanda UDR'lerin daha fazla manipüle edilebilecek (tablo gibi) karmaşık değerlere dönmesine izin verilmesi ve uygulama geliştirmeyi basitleştirmek için işlev adlarının aşırı yüklenmesini destekleme gibi önemli esneklik sağlamalıdır. SQL: 2011'de, UDR'ler bir UDT'nin bir parçası olarak veya ayrıca bir şemanın parçası olarak tanımlanabilir. SQL tarafından başlatılan bir yordam bir yordam, işlev veya yöntem olabilir. Harici olarak, C, C ++ veya Java gibi standart bir programlama dilinde sağlanabilir veya Kısım 9.5.10'da tartışıldığı gibi dili hesaplamalı olarak tamamlayan uzantılar kullanılarak tamamen SQL'de tanımlanabilir. SQL çağrısı prosedürü, bir SQL CALL ifadesinden çağrılır. Her biri bir giriş parametresi (IN), bir çıkış parametresi (OUT) veya her iki giriş ve çıkış parametresi (INOUT) olabilen sıfır veya daha fazla parametreye sahip olabilir ve tam olarak SQL içinde tanımlanmışsa bir gövdeye sahiptir . Bir SQL çağrılan işlevi bir değer döndürür; belirtilen parametrelerin giriş parametreleri olması gerekir. Bir girdi parametresi sonuç olarak belirlenebilir (RESULT anahtar sözcüğünü kullanarak), bu durumda parametrenin veri türü RETURNS türünün türüyle eşleşmelidir. Böyle bir fonksiyona her zaman RREURN parametresinin çalışma zamanının türü en özel türüyle aynı olan (bkz. Bölüm 9.5.3) (bu türün bazı alt türleri değil) değeri döndürdüğü için tipik koruma adı verilir. Mutator fonksiyonları

her zaman tip korur. SQL çağrılan bir yöntem bir işleve benzer, ancak bazı önemli farklılıkları vardır:

• bir yöntem tek bir UDT ile ilişkilidir;

• Bir UDT ile ilişkili her yöntemin imzası bu UDT'de belirtilmeli ve yöntemin tanımı UDT'yi belirtmelidir (ve ayrıca UDT ile aynı şemada da görünmelidir).

Üç tür yöntem vardır:

• UDT'nin yeni oluşturulan bir örneğini başlatan kurucu yöntemler;

• bir UDT'nin belirli örneklerinde çalışan örnek yöntemleri;

• Bazı nesne yönelimli programlama dillerinde sınıf yöntemlerine benzeyen ve örnek düzeyinde değil UDT düzeyinde çalışan statik yöntemler.

İlk iki durumda, yöntemler, veri türü ilişkili UDT'ninki olan SELF adlı ek bir ilk parametre içerir. PersonType için kullanıcı tanımlı yapıcı yönteminde SELF parametresinin bir örneğini gördük. Bir yöntem üç yoldan biriyle çağrılabilir:

• daha önce tartışıldığı gibi NEW ifadesi kullanılarak bir yapıcı yöntem çağrılır;

• Standart nokta notasyonu kullanılarak bir örnek metodu çağrılır; örneğin, p.fName veya genelleştirilmiş çağrı formatını kullanarak, örneğin, (p AS StaffType). fName ();

• :: kullanılarak statik bir yöntem çağrılır; örneğin, eğer totalStaff bir StaffType statik yöntemi ise, bunu StaffType :: totalStaff () olarak çağırabiliriz. İşletim sisteminin dosya deposundaki karşılık gelen "derlenmiş kod" u tanımlayan harici bir cümle belirtilerek tanımlanan bir dış rutin. Örneğin, veritabanında depolanan bir nesne için küçük resim oluşturan bir işlev kullanmak isteyebiliriz. İşlevsellik SQL'de sağlanamaz ve bu nedenle EXTERNAL deyimiyle aşağıdaki CREATE FUNCTION deyimini kullanarak harici olarak sağlanan bir işlevi kullanmak zorundayız:

CREATE FUNCTION thumbnail(INmyImage ImageType) RETURNS BOOLEANEXTERNAL NAME‘/usr/dreamhome/bin/images/thumbnail’LANGUAGE CPARAMETER STYLE GENERALDETERMINISTICNO SQL;Bu SQL deyimi, thumbnail adındaki SQL işlevini harici bir dosya olan “thumbnail” ile ilişkilendirir. Bu derlenmiş işlevi sağlamak kullanıcının sorumluluğundadır. Bundan sonra, ORDBMS, bu nesne dosyasını veritabanı sistemine dinamik olarak bağlamak için bir yöntem sağlayacaktır, böylece gerektiğinde çağrılabilir. Bunu başarma prosedürü, SQL standardının sınırları dışındadır ve bu nedenle uygulama tarafından tanımlandığı şekilde bırakılmıştır. Bir rutin belirli bir girdi kümesi için her zaman aynı dönüş değerlerini döndürmesi durumunda belirleyicidir. NO NO SQL, bu işlevin SQL ifadesi içermediğini gösterir. Diğer seçenekler READS SQL DATA, MODIFIES SQL DATA ve CONTAINS SQL'dir.

Polimorfizm

Farklı rutinler aynı ada sahip olabilir; yani rutin isimler aşırı yüklenebilir, örneğin bir UDT alt tipinin bir üst tipten miras alınan bir yöntemi aşağıdaki kısıtlamalara tabi olarak yeniden tanımlamasına izin vermek için aşırı yüklenebilir:

• Aynı şemadaki hiçbir iki işlevin aynı imzasına, yani aynı argüman sayısına, her argüman için aynı veri tipine ve aynı dönüş tipine sahip olmasına izin verilmez.

• Aynı şemadaki iki prosedürün aynı ada ve aynı sayıda parametreye sahip olmasına izin verilmez.

Geçersiz kılma, yalnızca yöntemler için geçerlidir ve sonra yalnızca gizli SELF argümanının çalışma zamanı değerini temel alır (bir yöntem tanımının parametrelere sahip olduğunu ve bir yöntem başlatmanın argümanları olduğunu unutmayın). SQL, genelleştirilmiş bir nesne modeli kullanır, böylece rutine tüm argümanların türleri, soldan sağa sırayla hangi rutinin çağrılacağını belirlerken dikkate alınır. Bir argümanın veri tipi ile belirtilen parametrenin veri tipi arasında tam bir eşleşme olmadığında, en yakın eşleşmeyi belirlemek için tip öncelik listeleri kullanılır. Belirli bir çağrı için rutin belirleme için kesin kurallar oldukça karmaşıktır ve burada tüm detayları vermeyiz, ancak örneğin yöntemlerin mekanizmasını gösteriyoruz.

Örnek yöntem çağrısı

Bir örnek yönteminin uygun şekilde başlatılmasının saptanması için mekanizma, statik analiz ve çalışma zamanı yürütmesini temsil eden iki faza ayrılır. Bu bölümde, bu aşamalara genel bir bakış sunuyoruz. İlk aşama şu şekilde ilerler:

• Uygun ada sahip tüm rutinler tanımlanır (kalan tüm rutinler elenir).

• Tüm prosedürler / fonksiyonlar ve kullanıcının EXECUTE ayrıcalığına sahip olmadığı tüm yöntemler elimine edilir.

• Örtülü SELF argümanının bildirilen türü (veya alt tipi) ile ilişkili olmayan tüm yöntemler ortadan kalkar.

• Parametreleri, yöntem çağrısındaki argüman sayısına eşit olmayan tüm metotlar elimine edilir.

• Kalan yöntemler için, sistem her parametrenin veri türünün karşılık gelen argümanın öncelik listesiyle eşleştiğini kontrol eder ve uyuşmayan yöntemleri ortadan kaldırır.

• Kalan aday yöntem yoksa, sözdizimi hatası oluşur. Kalan aday yöntemleri için ikinci (çalışma zamanı) aşaması aşağıdaki şekilde ilerler:

• Metod çağırmada örtük argümanın çalışma zamanı değerinin en spesifik tipi, aday metotlardan birini içeren bir tip tanımına sahipse, o zaman bu metot yürütmek için seçilir.

• Metod çağrısı için örtük argümanın çalışma zamanı değerinin en spesifik tipi, aday yöntemlerden birini içermeyen bir tür tanımına sahipse, yürütme için seçilen yöntem, ilişkili türü, tümünün en yakın üst türü olan aday yöntemdir. süper tipler böyle bir yönteme sahip.

Bağımsız değişken değerleri, uygunsa parametre veri türlerine dönüştürülür ve yöntemin gövdesi yürütülür.

Referans Türleri ve Nesne Kimliği

Nesne kimliği, asla değişmeyen ve nesneyi diğer tüm nesnelerden ayıran nesnenin bu yönüdür (bkz. Ek K.3). İdeal olarak, bir nesnenin kimliği isminden, yapısından ve konumundan bağımsızdır ve nesne silindikten sonra bile devam eder, böylece başka bir nesnenin kimliğiyle asla karıştırılamaz. Diğer nesneler, bir nesnenin kimliğini kendisine referans vermenin benzersiz bir yolu olarak kullanabilir. SQL: 1999'dan önce, tablolar arasındaki ilişkileri tanımlamanın tek yolu, Bölüm 7.2.4'te tartışıldığı gibi REFERENCES'te referans tablo kısıtlama maddesi REFERENCES kullanılarak ifade edilebilen birincil anahtar / yabancı anahtar mekanizmasını kullanmaktı. SQL: 1999'dan beri, başvuru türleri satır türleri arasındaki ilişkileri tanımlamak ve tablodaki bir satırı benzersiz şekilde tanımlamak için kullanılabilir. Bir referans tipi değeri bir (yazılan) tabloda saklanabilir ve bu baz olarak tanımlanmış olan bazı baz tablodaki belirli bir satıra doğrudan referans olarak kullanılabilir (C veya C ++ 'daki bir imleç tipine benzer şekilde) . Bu bakımdan, bir referans tipi, nesne yönelimli DBMS'lerin nesne tanımlayıcısı (OID) ile benzer bir işlevsellik sağlar (bkz. Ek K.3). Bu nedenle, referanslar bir satırın birden fazla tablo arasında paylaşılmasına izin verir ve kullanıcıların sorgulardaki karmaşık birleştirme tanımlarını çok daha basit yol ifadeleriyle değiştirmelerini sağlar. Referanslar ayrıca optimize ediciye, değere dayalı birleşimler kullanmak yerine verileri yönlendirmek için alternatif bir yol sunar. Bir CREATE TYPE deyiminde REF IS SYSTEM ÜRETİLDİ, ilişkili 9.2 REF türünün gerçek değerlerinin Örnek 9.2'de oluşturulan PersonType'ta olduğu gibi sistem tarafından sağlandığını belirtir. Başka seçenekler de var fakat detayları burada atlıyoruz; varsayılan, REF IS SYSTEM ÜRETİLDİR. Kısaca gördüğümüz gibi, bazı yapılandırılmış tiplerde bir taban masası oluşturulabilir. Tablo için diğer sütunlar belirtilebilir, ancak REF IS <columnName> SYSTEM GENERATED fıkrası kullanılarak en az bir sütun belirtilmelidir, yani ilişkili REF türünde bir sütun belirtilmelidir. Bu sütun, ilişkili taban tablonun satırları için benzersiz tanımlayıcılar içermek için kullanılır. Belirli bir satır için tanımlayıcı, satır tabloya eklendiğinde atanır ve silinene kadar o satırla ilişkili kalır.

Tablo Oluşturmak

SQL2 standardıyla yukarı doğru uyumluluğu sağlamak için, tablo tek bir UDT'den oluşsa bile, bir tablo oluşturmak için CREATE TABLE ifadesini kullanmak gerekir. Başka bir deyişle, bir UDT örneği yalnızca bir tabloda sütun değeri olarak depolanırsa devam edebilir.

ÖRNEK 9.4 Bir UDT'ye dayalı bir tablonun oluşturulması

PersonTypeUDT kullanarak bir tablo oluşturmak için şunu yazabiliriz:

CREATE TABLE Person (info PersonTypeCONSTRAINT DOB_Check CHECK(dateOfBirth > DATE‘1900-01-01’));orCREATE TABLE Person OF PersonType(dateOfBirth WITH OPTIONSCONSTRAINTDOB_Check CHECK (dateOfBirth> DATE‘1900-01-01’)REF IS PersonID SYSTEM GENERATED);

İlk örnekte, 'Person.info.fName' gibi bir yol ifadesi kullanarak Persontable'ın sütunlarına erişirdik; ikinci versiyonda, 'Person.fName' gibi bir yol ifadesi kullanarak sütunlara erişirdik. Daha da önemlisi, ikinci versiyon (CREATE TABLE... OF OF deyimi) kullanılarak oluşturulan tablolara daktilo tabloları denir. Yazılan bir tablonun satırları nesne olarak kabul edilir ve her iki durumda da aynı UDT kullanılmış olmasına rağmen ilk sürümdeki satırlar değildir. Yazılan bir tablonun dayandığı yapılandırılmış türün her özelliği için bir sütunu vardır. Ek olarak, yazılan bir tablo, tablonun her satırı için benzersiz bir OID (referans olarak bilinir) içeren kendi kendine başvuran bir sütuna sahiptir. Nesneler, herhangi bir ilişkisel tablodaki gibi normal INSERT ifadesi kullanılarak yazılı bir tabloya eklenir. Kendinden referanslı sütun ve yapılandırılmış türün nitelikleri dışında, tablo tanımına ek sütun eklenemez. OID, yazılan tabloya yeni bir satır eklendiğinde otomatik olarak oluşturulur. Bununla birlikte, kendi kendini referans alan sütunda depolanan OID'lere erişmek için, açıkça REF IS yan tümcesini kullanarak sütun adını vermeliyiz (örneğimizdeki PersonIDin). Yazılan tablo tanımının ayrıca UDT: sistem tarafından üretilen, kullanıcı tarafından üretilen veya türetilmiş olan ilgili spesifikasyonlarla tutarlı bir referans oluşturma spesifikasyonunu da tekrarlaması gerektiğini unutmayın.

ÖRNEK 9.5 UNDER yantümcesini kullanarak bir alt-tablonun oluşturulması

Tablo devralmayı kullanan personel için bir tablo oluşturabiliriz:

CREATE TABLE Staff OF StaffType UNDER Person;

Personel Tablosuna satır eklediğimiz zaman, devralınan sütunların değerleri Personel Tablosuna eklenir. Benzer şekilde, sıraları Stafftable'dan sildiğimizde, sıralar her ikisi de Staffand Persontables'dan kaybolur. Sonuç olarak, tüm Kişi satırlarına eriştiğimizde, bu aynı zamanda tüm Personel ayrıntılarını içerecektir.

Tablo hiyerarşisinin popülasyonunda kısıtlamalar vardır:

• Süper Personcan'ın her bir sırası, Kadro'da en fazla bir satıra karşılık gelir.

• Staffmust'taki her satırda, Kişi'de tam olarak karşılık gelen bir satır bulunur.

Tutulan anlambilim, içerme anlamındadır: Bir alt çizelgedeki bir satır, üstbilgilerinde “içerilir”. SQL INSERT, UPDATE ve DELETE ifadelerinin, alt satırlar ve süper satırlar değiştirilirken (en azından kavramsal olarak) bu tutarlılığı sürdürmesini bekleriz:

• Bir alt tabloya bir satır eklendiğinde, tablonun kalıtsal olan sütunlarının değerleri, tablo hiyerarşisinde yukarıya doğru basamaklandırılarak karşılık gelen süper noktalara yerleştirilir. Örneğin, Şekil 9.4 (b) 'ye bakıldığında, PTStudentStaff’a bir satır eklersek, miras alınan sütunların değerleri Öğrenci ve Personel’e eklenir ve ardından Miras Alınan sütunların değerleri Öğrenci / Personel’in

Kişiye eklenmiş.

• Bir alt tablodaki bir satır güncellendiğinde, üstlerindeki devralınan sütunların değerlerini süper tablolarda güncellemek için bir önceki prosedür uygulanır.

• Bir satır bir üstüste güncellendiğinde, doğrudan ve dolaylı alt tabloların ilgili satırlarındaki tüm kalıtsal sütunların değerleri de buna göre güncellenir. Üstbilginin kendisi bir alt tablo olabileceğinden, tutarlılığın sağlanması için önceki koşulun da uygulanması gerekecektir.

• Bir alt / üst tabanda bir satır silindiğinde, tablo hiyerarşisindeki ilgili satırlar silinir. Örneğin, bir Öğrenci sırasını silersek, ilgili Kişi ve Lisans / Yüksek Lisans / PartTimeStudent / PTStudentStaff satırları silinir. SQL: 2011, kullanıcı açıkça tüm örneklerin depolandığı tek bir tablo oluşturmadıkça, belirli bir UDT'nin tüm örneklerini saklamak için bir mekanizma sağlamaz. Bu nedenle, SQL: 2011'de belirli bir UDT'nin tüm örneklerine bir SQL sorgusu uygulamak mümkün olmayabilir. Örneğin, şöyle bir tablo oluşturduysak:

CREATE TABLE Client(

info PersonType,

prefType CHAR,

maxRent DECIMAL(6, 2),

branchNo VARCHAR(4) NOT NULL);

daha sonra PersonTypeare örnekleri şimdi iki tabloya dağıldı: Staffand Client. Bu sorun, UNDER yan tümcesini kullanarak varolan bir tablonun tüm sütunlarını miras alan bir tablonun oluşturulmasına izin veren tablonun devralma mekanizması kullanılarak bu özel durumda aşılabilir. Beklenildiği gibi, bir alt tablo her sütunu üst bölümünden devralır. Bir tablo hiyerarşisindeki tüm tabloların aynı tip hiyerarşideki karşılık gelen tiplere sahip olması gerektiğini ve tablo hiyerarşisindeki tabloların tip hiyerarşisindeki karşılık gelen tiplerle aynı göreceli konumlarda olması gerektiğini unutmayın. Bununla birlikte, tür hiyerarşisindeki her türün, tabloların tanımlandığı türlerin bitişik olması şartıyla tablo hiyerarşisinde gösterilmesi gerekmez. Örneğin, Şekil 9.4 (a) 'ya atıfta bulunarak, Personel hariç her türlü tablo oluşturmak yasal olacaktır; Ancak, Öğrenci için bir tane oluşturmadan Kişi ve Lisansüstü için tablolar oluşturmak yasalara aykırı olacaktır. Ayrıca, ek sütunların alt tablo tanımının bir parçası olarak tanımlanamayacağını da unutmayın.

ÖRNEK 9.6 Bir ilişki tanımlamak için bir referans türü kullanma

Bu örnekte, PropertyForRent ve Staff arasındaki ilişkiyi bir referans türü kullanarak modelliyoruz.

CREATE TABLE PropertyForRent(

propertyNo PropertyNumber NOT NULL,

street Street NOT NULL,

city City NOT NULL,

postcode PostCode,

type PropertyType NOT NULL DEFAULT‘F’,

rooms PropertyRooms NOT NULL DEFAULT4,

rent PropertyRent NOT NULL DEFAULT600,

staffID REF(StaffType) SCOPE Staff

REFERENCES ARE CHECKED ON DELETE CASCADE,

PRIMARY KEY(propertyNo));

Örnek 7.1'de, geleneksel birincil anahtar / yabancı anahtar mekanizmasını kullanarak PropertyForRent ve Personel arasındaki ilişkiyi modellendik. Bununla birlikte, ilişkiyi modellemek için bir referans türü REF (StaffType) kullandık. SCOPE yan tümcesi ilişkili başvuru tablosunu belirtir. REFERANSLAR KONTROL EDİLDİ, referans bütünlüğünün korunması gerektiğini gösterir (alternatif, REFERANSLAR KONTROL EDİLMEZ). DELETE CASCADE, SQL2'de var olan normal referans eylemine karşılık gelir. ÇALIŞMA GELİŞTİRME yan tümcesinin gerekli olmadığını unutmayın, çünkü Stafftable'daki sütun staffID'si güncellenemiyor.

Ayrıcalıklar

Yeni bir alt tür oluşturmak için gereken ayrıcalıklarda olduğu gibi, bir kullanıcı başvurulan üstbilgide UNDER ayrıcalığına sahip olmalıdır. Ek olarak, bir kullanıcının yeni tablo içinde referans verilen herhangi bir kullanıcı tanımlı tür üzerinde KULLANIM imtiyazı olması gerekir.

Verileri Sorgulama

SQL: 2011, tabloları sorgulamak ve güncellemek için SQL2 ile aynı sözdizimini, nesneleri işlemek için çeşitli uzantıları sağlar. Bu bölümde, bu uzantıların bazılarını gösteriyoruz.

ÖRNEK 9.7 Belirli bir sütunu, özel satırları al

Tüm Müdürlerin isimlerini bulun.

SELECT s.lName

FROM Staff s

WHERE s.position =‘Manager’;

Bu sorgu, konum sütununa erişmek için WHERE yan tümcesinde dolaylı olarak tanımlanmış gözlemci işlevini çağırır.

ÖRNEK 9.8 Kullanıcı tanımlı bir işlevi çağırmak

Tüm Müdürlerin isimlerini ve yaşlarını bulun.

SELECT s.lName, s.age

FROM Staff s

WHERE s.isManager;

Bu alternatif yöneticileri bulma yöntemi, WHERE yan tümcesinin bir göstergesi olarak kullanıcı tanımlı yöntemi isManager kullanır. Bu yöntem, eğer personel üyesi bir yönetici ise,

TRUE boole değerini döndürür (bakınız Örnek 9.3). Ek olarak, bu sorgu ayrıca devralınan sanal (gözlemci) işlev yaşını SELECT listesinin bir öğesi olarak çağırır.

ÖRNEK 9.9 Seçimi kısıtlamak için ONLY kullanımı

65 yaşın üzerindeki veritabanındaki tüm kişilerin isimlerini bulun.

SELECT p.lName, p.fName

FROM Person p

WHERE p.age> 65;

Bu sorgu, yalnızca Kişisel olarak açıkça belirtilmiş olan satırların ayrıntılarını değil, aynı zamanda, bu durumda, Personel ve Müşteri'nin herhangi bir doğrudan veya dolaylı alt dizinine eklenen herhangi bir satırdaki adları da listeler. Bununla birlikte, tüm insanların ayrıntılarını istemek yerine, yalnızca herhangi bir alt tablo hariç, Persontable'ın belirli örneklerinin ayrıntılarını istediğimizi varsayalım. Bu ONLY anahtar kelime kullanılarak elde edilebilir:

SELECT p.lName, p.fName

FROM ONLY(Person) p

WHERE p.age> 65;

ÖRNEK 9.10 Dereference operatörünün kullanımı

‘PG4’ özelliğini yöneten personelin adını bulun.

SELECT p.staffID–>fName AS fName, p.staffID–>lName AS lName

FROM PropertyForRent p

WHERE p.propertyNo =‘PG4’;

Referanslar, nesne referanslarının bir satırdan diğerine gitmesini sağlayan yol ifadelerinde kullanılabilir. Bir referansı geçmek için referans operatörü (->) kullanılır. SELECT ifadesinde, p.staffID bir tablonun sütununa erişmenin normal yoludur. Bununla birlikte, bu özel durumda, sütun, Personel tablosunun bir satırına referanstır ve bu nedenle, başvurulan çizelgenin sütunlarına erişmek için dereference operatörünü kullanmalıyız. SQL2'de, bu sorgu bir birleşim veya iç içe alt sorgu gerektirebilirdi. Personel üyesini PG4 özelliği için yalnızca ilk ve soyadı yerine almak için aşağıdaki sorguyu kullanırız:

SELECT DEREF(p.staffID) AS Staff

FROM PropertyForRent p

WHERE p.propertyNo =‘PG4’;

Referans tipleri yabancı anahtarlara benzese de, önemli farklılıklar vardır. SQL: 2011'de referans bütünlüğü yalnızca tablo tanımının bir parçası olarak belirtilen bir referans kısıtı tanımı kullanılarak korunur. Kendi başlarına, referans türleri referans bütünlüğü sağlamaz. Bu

nedenle, SQL referans tipi ODMG nesne modelinde sağlanan ile karıştırılmamalıdır. ODMG modelinde, OID'ler türler arasındaki ilişkileri modellemek için kullanılır ve referans bütünlüğü otomatik olarak tanımlanır.

Koleksiyon Çeşitleri

Koleksiyonlar, diğer türdeki koleksiyonları tanımlamak için kullanılan tür kurucularıdır. Koleksiyonlar, bir tablonun tek bir sütununda birden fazla değer depolamak için kullanılır ve bir tablodaki bir sütunun gerçekten başka bir tablo içerdiği iç içe geçmiş tablolara neden olabilir. Sonuç, birden fazla ana ayrıntı seviyesini temsil eden tek bir tablo olabilir. Böylece, koleksiyonlar fiziksel veritabanı yapısının tasarımına esneklik katar. SQL: 1999 bir ARRAY koleksiyon türü tanıttı ve SQL: 2003, MULTISET koleksiyon türünü ekledi ve standardın sonraki bir sürümü parametreli LIST ve SET koleksiyon türlerini tanıtabilir. Her durumda, eleman tipi olarak adlandırılan parametre önceden tanımlanmış bir tip, bir UDT, bir satır tipi veya başka bir koleksiyon olabilir, ancak bir referans tipi veya bir referans tipi içeren bir UDT olamaz. Ek olarak, her bir koleksiyon homojen olmalıdır: tüm elemanlar aynı tipte veya en azından aynı tip hiyerarşiden olmalıdır. Koleksiyon türleri şu anlama gelir:

• ARRAY — maksimum sayıda öğeye sahip tek boyutlu bir dizi;

• MULTISET — kopyalara izin veren sıralanmamış koleksiyon;

• LIST — yinelenenlere izin veren sipariş edilen koleksiyon;

• SET — yinelenenlere izin vermeyen sıralanmamış koleksiyon.

Bu türler, Bölüm 28.2'de tartışılacak olan ODMG 3.0 standardında tanımlanmış olanlara benzer, Torba adı SQL MULTISET ile değiştirildi.

ARRAY koleksiyon türü

Bir dizi, öğelerin dizideki sıradaki konumlarına göre başvurulan mutlaka zorunlu olmayan farklı değerlerin sıralı bir koleksiyonudur. Bir dizi, bir veri tipi ve isteğe bağlı olarak en yüksek kardinalite ile bildirilir; Örneğin:

VARCHAR(25) ARRAY[5]

Bu dizinin elemanlarına 1 ile maksimum kardinalite arasında değişen bir indeks ile erişilebilir (CARDINALITY işlevi dizideki mevcut elemanların sayısını döndürür). Eğer aynı kardinaliteye sahiplerse ve her sıralı eleman çifti aynıysa ve karşılaştırılabilir tipteki iki dizinin aynı olduğu kabul edilir. Bir dizi türü, öğeleri köşeli parantez içine alınmış virgülle ayrılmış bir liste olarak numaralandırmak veya 1 dereceli bir sorgu ifadesi kullanarak tanımlamak suretiyle tanımlanabilen bir dizi türü yapıcısı tarafından belirtilir; Örneğin:

ARRAY[‘Mary White’, ‘Peter Beech’, ‘Anne Ford’, ‘John Howe’, ‘Alan Brand’]

ARRAY(SELECT rooms FROM PropertyForRent)

ÖRNEK 9.11 Koleksiyonun kullanımı ARRAY

Bir şubenin üç telefon numarasına sahip olması gerekliliğini modellemek için sütunu bir ARRAY koleksiyon türü olarak uygulayabiliriz:

telNo VARCHAR(13) ARRAY[3]

Aşağıdaki sorguyu kullanarak B003 şubesindeki ilk ve son telefon numaralarını alabiliriz:

SELECT telNo[1], telNo[CARDINALITY (telNo)]

FROM Branch

WHERE branchNo =‘B003’;

MULTISET Koleksiyon Türü

Çoklu ayar, kopyalara izin verilen, tümü aynı türde, sıralanmamış bir öğeler topluluğudur. Bir multiset sırasız olduğundan, bir multiset'in ayrı ayrı elemanlarına atıfta bulunmak için sıralı bir pozisyon yoktur. Dizilerin aksine, bir multiset (maksimum uygulama sınırı belirlenmiş olsa da), maksimum kardinalliği bildirilmemiş sınırsız bir koleksiyondur. Her ne kadar çoklu ayarlar tablolara benzese de, tablolarla aynı sayılmazlar ve operatörlerin bir çoklu bilgisayarı bir masaya (UNNEST) ve bir masayı bir çoklu ekrana (MULTISET) dönüştürmek için sağlanmıştır. Kümeler için önerilen ayrı bir tür bulunmamaktadır. Bunun yerine, küme yalnızca özel bir tür multiset'tir: yinelenen öğeleri olmayan. Bir multisetin ayarlanmış olup olmadığını kontrol etmek için bir belirti verilmiştir. Aand Bsay, karşılaştırılabilir eleman türlerinin iki çoklu kümesi, eğer aynı kardinalliğe sahiplerse ve ancak xin A'daki her bir eleman için aynıysa ve aynıdır, Athat elemanlarının sayısı, xitself dahil olmak üzere, x ile aynıdır, Bthat elemanlarının sayısına eşittir. x eşittir. Yine dizi türlerinde olduğu gibi, çoklu ayar türünde bir yapıcı, öğelerini köşeli parantez içine alınmış virgülle ayrılmış bir liste olarak numaralandırarak veya derece 1 olan bir sorgu ifadesi kullanarak veya bir tablo değeri yapıcısı kullanarak tanımlanabilir.

Çoklu cihazlardaki işlemler şunları içerir:

• SET işlevi, bir set oluşturmak için kopyaları çoklu cihazdan kaldırmak için.

• Mevcut elemanların sayısını döndürmek için CARDINALITY işlevi.

• ELEMENT işlevi, eğer multiset sadece bir elemente sahipse (veya multisette eleman yoksa null) bir multisenin elemanını döndürmek için. Çoklu cihazda birden fazla eleman varsa, bir istisna ortaya çıkar.

• İki çoklu şebekenin birliğini hesaplayan MULTISET UNION; ALL veya DISTINCT anahtar kelimeleri kopyaları saklamak veya kaldırmak için belirtilebilir.

• İki multisetenin kesişimini hesaplayan MULTISET INTERSECT; DISTINCT anahtar kelimesi kopyaları çıkarmak için belirtilebilir; ALL anahtar kelimesi, sonuçta, her bir işlenende bu değerin minimum örnek sayısı kadar çok sayıda değer örneği yerleştirmek için belirtilebilir.

• İki multisetin farkını hesaplayan MULTISET EXCEPT; Yine, DISTINCT anahtar kelimesi kopyaları çıkarmak için belirtilebilir; ALL anahtar kelimesi, sonuçta birinci işlenendeki eksi ikinci işlenenin örnek sayısına ek olarak, bir değerin birkaç örneğini yerleştirmek için belirtilebilir.

Çoklu ağlar için üç yeni toplama işlevi vardır:

• Bir grubun her satırındaki argüman değerinden bir çoklu ayar yaratan COLLECT;

• Bir grubun tüm satırlarında çoklu ayar değerine sahip çoklu ayarlı bir birleşme oluşturan FUSION;

• Bir grubun tüm satırlarında çoklu ayar değerinin çoklu ayar kesişimini oluşturan INTERSECTION.

Ek olarak, multisets ile kullanım için bir takım tahminler vardır:

• Karşılaştırma tahmini (yalnızca eşitlik ve eşitsizlik);

• DISTINCT yüklemi;

• MEMBER tahmini;

• SUBMULTISET, bir multiset'in diğerinin submultiset olup olmadığını test eden tahmini;

• IS A SET/ IS NOT A SET değil, bir multiset'in set olup olmadığını kontrol eder.

ÖRNEK 9.12 Koleksiyonun kullanımı MULTISET

Çalışanlar tablosunu, bir dizi akrabanın ayrıntılarını içerecek şekilde genişletin ve sonra John White’ın akrabalarının adlarını ve soyadlarını bulun. Bir sonrakiOfKin sütununun tanımını Çalışanlar'a şu şekilde ekleriz (NameType bir fName ve lNameattribute içerir):

nextOfKin NameType MULTISET

The query becomes:

SELECT n.fName, n.lName

FROM Staff s, UNNEST(s.nextOfKin) AS n(fName, lName)

WHERE s.lName =‘White’ AND s.fName =‘John’;

ÖRNEK 9.13 FUSION ve INTERSECTION özetleme fonksiyonlarının kullanımı

Aşağıdaki tabloyu göz önünde bulundurun, PropertyViewDates, tarih özelliklerini vererek potansiyel kiracılar tarafından görüntülendi:

Füzyon, ilk önce bu satırları boş bırakarak hesaplanır (bu durumda, PL94 özelliği için satır). Ardından, kalan üç çoklu bölgenin her bir üyesi, sonuç kümesine kopyalanır. Kavşak, bu satırları null ile tekrar atmak ve daha sonra giriş multisetlerinde kopyaları bulmak suretiyle hesaplanır.

Tipli Görünümler

SQL: 2011 ayrıca, bazen nesne görünümleri veya referans verilebilir görünümler olarak adlandırılan yazılı görünümleri de destekler. Belirli bir yapılandırılmış türe dayalı olarak yazılmış bir görünüm oluşturulur ve bu yazılan görünüme göre bir alt görünüm oluşturulabilir. Aşağıdaki örnek, yazılan görünümlerin kullanımını göstermektedir.

ÖRNEK 9.14 Yazılan görünümlerin oluşturulması

Aşağıdaki ifadeler, PersonType ve StaffType yapılandırılmış türlerine göre iki görünüm oluşturur:

CREATE VIEW FemaleView OF PersonType (REF IS personID DERIVED)

AS SELECT fName, lName

FROM ONLY(Person)

WHERE sex =‘F’;

CREATE VIEW FemaleStaff3View OF StaffType UNDER FemaleView

AS SELECT fName, lName, staffNo, position

FROM ONLY(Staff)

WHERE branchNo =5‘B003’;

(REF IS IS ID NEDEN EDİLDİ), daha önce tartışılan kendini referans veren sütun belirtimidir. Bir alt görünüm tanımlarken, bu fıkra belirtilemez. Bir maksimum denetim tanımlanırken, SİSTEM ÜRETİLMİŞ seçeneğinin kullanılamamasına rağmen, yalnızca KULLANICI ÜRETİLMİŞ veya TÜREVLİ seçeneğine rağmen, bu madde belirtilebilir. KULLANICI ÜRETİLDİĞİ belirtilirse, görünümün derecesi, ilişkili yapılandırılmış türün öznitelik sayısından birdir; DERIVED belirtilirse, derece, ilişkili yapılandırılmış türdeki özniteliklerin sayısıyla aynıdır ve ek bir

kendine başvuru sütunu eklenmez. Normal görünümlerde olduğu gibi WITH CHECK OPTION deyiminde olduğu gibi yeni sütun adları belirtilebilir.

Kalıcı Saklı Modüller

Dili hesaplamalı olarak tamamlamak için SQL'e bir dizi yeni ifade türü eklenmiştir, böylece nesne davranışı (yöntemler) veritabanından SQL ifadeleri olarak depolanıp çalıştırılabilir.

Tetikleyiciler

Bir tetikleyici, DBMS tarafından otomatik olarak adlandırılmış bir tablodaki değişikliğin yan etkisi olarak yürütülen bir SQL (bileşik) ifadesidir. Bir SQL yordamına benzer, çünkü bildirim, çalıştırılabilir ve koşul işleme bölümleriyle adlandırılmış bir SQL bloğudur. Bununla birlikte, bir rutinin aksine, bir tetikleyici eşitlediğinde ve bir tetikleyicide herhangi bir argüman yoksa, bir tetikleyici örtük olarak yürütülür. Bir tetikleyici çalıştırma eylemi, bazen tetikleyiciyi ateşlemek olarak bilinir. Tetikleyiciler aşağıdakiler dahil birçok amaç için kullanılabilir:

• Girdi verilerinin doğrulanması ve aksi takdirde zor olmasa da zor olacak karmaşık bütünlük kısıtlarının tablo kısıtlamaları ile sürdürülmesi;

• Bir tablo bir şekilde güncellendiğinde yapılması gereken eylem için destekleyici uyarıları (örneğin, elektronik posta kullanarak);

• yapılan değişiklikleri kaydederek ve kim tarafından denetim bilgisini sağlamak;

• Bölüm 26'da tartışıldığı gibi destek çoğaltması. CREATE TRIGGER ifadesinin temel biçimi aşağıdaki gibidir:

CREATE TRIGGER TriggerNameBEFORE | AFTER | INSTEAD OF<triggerEvent> ON<TableName>[REFERENCING<oldOrNewValuesAliasList>][FOR EACH{ROW | STATEMENT[WHEN(triggerCondition)]<triggerBody>Olayları tetiklemek, tablodaki satırların eklenmesi, silinmesi ve güncellenmesini içerir. Yalnızca ikinci durumda, bir tablonun belirli adlandırılmış sütunlarını kapsayacak şekilde bir tetikleyici olay da ayarlanabilir. Bir tetikleyicinin, ÖNCE, SONRA veya INSTEAD OF ile ilişkili bir zamanlaması vardır. İlişkili olay gerçekleşmeden önce bir BEFORE tetikleyicisi ateşlenir, ilişkili olay gerçekleştikten sonra bir AFTER tetikleyicisi ateşlenir ve tetikleyici olayı yerine bir INSTEAD OF tetikleyicisi ateşlenir. Tetiklenen eylem, iki yoldan biriyle çalıştırılabilen bir SQL prosedürü ifadesidir:

• olaydan etkilenen her satır için (HER ÇOK SATIR). Buna satır düzeyinde tetikleyici denir;

• olayın tamamı için yalnızca bir kez (HER ŞEY İÇİN), varsayılandır.

Buna ifade düzeyinde tetikleyici denir.

<oldOrNewValuesAliasList>, şunlara başvurabilir:

• bir satır seviyesi tetiklemesi durumunda eski veya yeni bir satır (ESKİ / YENİ veya ESKİ SATIR / YENİ SATIR);

• Bir AFTER tetiklemesi durumunda eski veya yeni bir masa (OLD TABLE / NEW TABLE).

Açıkça, eski değerler insert olayları için geçerli değildir ve yeni değerler olayları silmek için geçerli değildir. Bir tetikleyicinin gövdesi aşağıdakileri içeremez:

• COMMIT veya ROLLBACK gibi SQL işlem bildirimleri;

• CONNECT veya DISCONNECT gibi SQL bağlantı ifadeleri;

• Tabloların, kullanıcı tanımlı türlerin veya diğer tetikleyicilerin oluşturulması veya silinmesi gibi SQL şema tanımı veya manipülasyon ifadeleri;

• SET OTURUM ÖZELLİKLERİ, SET ROL, SET ZAMAN BÖLGESİ gibi SQL oturum ifadeleri.

Ayrıca, SQL, mutasyona neden olan tetikleyicilerin, yani aynı tetikleyiciyle sonuçlanan bir değişikliğe neden olan tetikleyicilerin tekrar, muhtemelen sonsuz bir döngüde başlatılmasına izin vermez. Bir tabloda birden fazla tetikleyici tanımlanabildiği için, tetikleyicilerin ateşlenme sırası önemlidir. Tetikleyici olay (INSERT, UPDATE, DELETE) yürütüldüğünde tetikleyiciler ateşlenir. Aşağıdaki sıraya uyulur:

(1) Masada herhangi bir BEFORE deyimi düzeyinde tetikleyicinin yürütülmesi.

(2) İfadeden etkilenen her satır için:

(a) herhangi bir BEFORE satır seviyesi tetikleyicisinin yürütülmesi;

(b) ifadenin kendisinin yerine getirilmesi;

(c) herhangi bir referans kısıtlamanın uygulanması;

(d) Herhangi bir AFTER sıra seviye tetikleyicisinin yürütülmesi.

(3) Masada herhangi bir AFTER deyimi düzeyinde tetikleyicinin yürütülmesi.

Bu siparişten, BEFORE tetikleyicilerinin referans bütünlüğü kısıtlamaları kontrol edilmeden önce etkinleştirildiğini unutmayın. Bu nedenle, tetikleyicinin çağrılmasına neden olan istenen değişikliğin veritabanı bütünlüğü kısıtlamalarını ihlal etmesi ve izin vermemesi gerekebilir. Bu nedenle, BEFORE tetikleyicileri veritabanını daha fazla değiştirmemelidir. Aynı tetikleyici olayı ve aynı eylem süresine sahip bir masada birden fazla tetikleyici olması durumunda (ÖNCE veya SONRA), SQL standardı tetikleyicilerin oluşturuldukları sırayla yürütüleceğini belirtir. Şimdi bazı örneklerle tetikleyicilerin oluşturulmasını gösteriyoruz.

ÖRNEK 9.15 AFTER INSERT tetikleyicisinin kullanılması

Her newPropertyForRent satırı için bir dizi mailshot kaydı oluşturun. Bu örneğin amaçları için, muhtemel kiracı ayrıntılarını ve mülk ayrıntılarını kaydeden bir Mailshot tablosu olduğunu varsayalım.

CREATE TRIGGER InsertMailshotTableAFTER INSERT ON PropertyForRent

REFERENCING NEW ROW AS pfrBEGIN ATOMICINSERT INTO Mailshot VALUES(SELECT c.fName, c.lName, c.maxRent, pfr.propertyNo, pfr.street, pfr.city, pfr.postcode, pfr.type, pfr.rooms, pfr.rentFROM Client cWHERE c.branchNo 5 pfr.branchNo AND(c.prefType 5 pfr.type AND c.maxRent<5 pfr.rent))END;Bu tetikleyici yeni satır eklendikten sonra yürütülür. FOR EACH deyimi, bir INSERT deyiminin bir seferde yalnızca bir satır eklemesi nedeniyle varsayılan olarak FOR EACH STATEMENT seçeneğine ayarlanmadı. Tetikleyicinin gövdesi, eşleşen tüm istemci satırlarını bulan alt sorguyu temel alan bir INSERT ifadesidir.

ÖRNEK 9.16 AFTER INSERT tetikleyicisinin koşullu kullanımı

Bir mülkün kirası değiştiyse, geçerli tüm posta kayıtlarını değiştiren bir tetikleyici oluşturun.

CREATE TRIGGER UpdateMailshotTableAFTER UPDATE OF rent ON PropertyForRentREFERENCING NEW ROW AS pfrFOR EACH ROWBEGIN ATOMICDELETE FROM Mailshot WHERE maxRent> pfr.rent;UPDATE Mailshot SET rent 5 pfr.rentWHERE propertyNo 5 pfr.propertyNo;END;Bu tetikleyici, PropertyForRentrow'un kiralama alanı güncellendikten sonra yürütülür. FOR EACH ROW cümlesi belirtilmiştir, çünkü tüm emlak kiraları bir UPDATE ifadesinde, örneğin bir yaşam maliyeti artışı nedeniyle arttırılmış olabilir. Tetikleyicinin gövdesinde iki SQL ifadesi vardır: yeni kiralama fiyatının müşterinin fiyat aralığının dışında olduğu bu anlık kayıtları silmek için bir DELETE ifadesi ve bu mülkle ilgili tüm satırlarda yeni kiralama fiyatını kaydetmek için bir UPDATE ifadesi. Tetikleyiciler, uygun şekilde kullanıldığında çok güçlü bir mekanizma olabilir. En büyük avantaj, standart işlevlerin veritabanında depolanabilmesi ve veritabanına yapılan her güncellemeyle tutarlı şekilde uygulanabilmesidir. Bu, uygulamaların karmaşıklığını önemli ölçüde azaltabilir. Bununla birlikte, bazı dezavantajlar olabilir:

• Karmaşıklık. İşlevsellik uygulamadan veritabanına taşındığında, veritabanı tasarımı, uygulaması ve yönetimi görevleri daha karmaşık hale gelir.

• Gizli işlevsellik. İşlevselliği veritabanına taşımak ve bir veya daha fazla tetikleyici olarak saklamak, işlevselliği kullanıcıdan gizleme etkisine sahip olabilir. Bu, kullanıcı için işleri basitleştirebilse de, ne yazık ki, planlanmamış ve potansiyel olarak istenmeyen ve hatalı olabilecek yan etkileri de olabilir. Kullanıcı artık veritabanına ne olacağı üzerinde kontrol sahibi değil.

• Performans ek yükü. DBMS, veritabanını değiştiren bir ifadeyi yürütmek üzereyken, şimdi bir tetikleyicinin ifade tarafından tetiklenip tetiklenmediğini kontrol etmek için tetikleyici koşulunu değerlendirmek zorundadır. Bunun DBMS üzerinde bir performans etkisi vardır. Açıkça, tetikleyici sayısı arttıkça, bu ek yük de artar. En yoğun zamanlarda, bu ek yük performans sorunları yaratabilir.

Ayrıcalıklar

Bir tetikleyici oluşturmak için, kullanıcının belirtilen tabloda TRIGGER ayrıcalığına, WHEN yan tümcesinde triggerCondition'da belirtilen tüm tablolarda SELECT ayrıcalığına ve tetikleyici gövdesinde SQL ifadelerini yürütmek için gereken ayrıcalıklara sahip olması gerekir.

Büyük Nesneler

Büyük bir nesne, uzun metin dosyası veya grafik dosyası gibi büyük miktarda veri tutan bir veri türüdür. SQL: 2011'de üç farklı büyük nesne veri türü tanımlanmıştır:

• İkili Büyük Nesne (BLOB), karakter kümesi veya harmanlama ilişkisine sahip olmayan bir ikili dize;

• Karakter Büyük Nesnesi (CLOB) ve Ulusal Karakter Büyük Nesnesi (NCLOB), her iki karakter dizesi.

SQL büyük nesnesi, bazı veritabanı sistemlerinde görünen orijinal BLOB türünden biraz farklıdır. Bu tür sistemlerde, BLOB yorumlanmamış bir bayt akışıdır ve DBMS, BLOB içeriği veya iç yapısı ile ilgili hiçbir bilgiye sahip değildir. Bu, DBMS'nin görüntüler, video, kelime işlem belgeleri veya Web sayfaları gibi doğal olarak zengin ve yapılandırılmış veri türlerinde sorgu ve işlem gerçekleştirmesini önler. Genel olarak, bu, herhangi bir işlem gerçekleştirilmeden önce tüm BLOB'un ağ boyunca DBMS sunucusundan istemciye aktarılmasını gerektirir. Buna karşılık, SQL büyük nesnesi bazı işlemlerin DBMS sunucusunda gerçekleştirilmesine izin verir. Karakter dizgileri üzerinde çalışan ve karakter dizgileri döndüren standart dize işleçleri, aşağıdaki gibi karakter büyük nesne dizelerinde de çalışır:

• Karakter dizisi işlenenleri belirtilen sırada birleştirilerek oluşturulan karakter dizesini döndüren birleştirme işleci (string1 istring2).

• Belirtilen bir diziden bir başlangıç konumundan belirli bir uzunluk için çıkarılan bir dizgeyi döndüren SUBSTRING karakter dizgisi işlevi

• Karakter bindirme fonksiyonu, OVERLAY (startpos FOR FROM dizisinden2 dizisi2 PLACING dizisi2), dizinin1 alt dizesini, başlangıç konumu ve dizge2 ile uzunluk olarak değiştirir. Bu, şuna eşdeğerdir: SUBSTRING (string1 'den 1 - uzunluk için 1 - 1) istring2 iSUBSTRING (string1' den startpos + uzunluk).

• Katlama fonksiyonları, bir dizedeki tüm karakterleri büyük / küçük harfe dönüştüren UPPER (string) ve LOWER (string).

• Öncelikli ve / veya izleyen dize1 karakterlerinin kaldırılmasıyla dize2 döndüren trim işlevi, TRIM ([LEADING | TRAILING | BOTH string1 FROM] string2). FROM yan tümcesi belirtilmezse, tüm önde gelen ve sondaki boşluklar string2'den kaldırılır.

• Belirtilen dizenin uzunluğunu döndüren CHAR_LENGTH (string) uzunluk işlevi.

• string1 içindeki string1'in başlangıç pozisyonunu döndüren POSITION (string1 IN string2) pozisyon fonksiyonu.

Bununla birlikte, CLOB dizelerinin çoğu karşılaştırma işlemine katılmasına izin verilmemesine rağmen, bir LIKE belirtisine ve eşittir (<>) operatörlerini kullanan bir karşılaştırma veya nicel karşılaştırma karşılaştırmasına katılabilirler. Bu kısıtlamaların sonucu olarak, bir CLOB dizesi olarak tanımlanan bir sütun, GROUP BY deyimi, ORDER BY deyimi, benzersiz veya başvuru kısıtlama tanımı, bir birleştirme sütunu veya bir birinde referans olarak verilemez. işlemleri ayarlayın (UNION, INTERSECT ve EXCEPT). İkili büyük nesne (BLOB) dizgisi, sekizli dizisi olarak tanımlanır. Tüm BLOB dizeleri, oktetleri aynı sıradaki pozisyon ile karşılaştırarak karşılaştırılabilir. Aşağıdaki operatörler LOB dizelerinde çalışır ve BLOB dizelerini döndürür ve önceden tanımlanmış olanlarla benzer işlevselliğe sahiptir:

• BLOB birleştirme işleci (i);

• BLOB substring işlevi (SUBSTRING);

• BLOB bindirme fonksiyonu (GENEL);

• BLOB trim işlevi (TRIM).

Ek olarak, BLOB_LENGTH ve POSITION işlevleri ve LIKE yüklemesi BLOB dizeleriyle de kullanılabilir.

ÖRNEK 9.17 Karakter ve İkili Büyük Nesnelerin Kullanımı

Personel için bir özgeçmiş ve resim tutmak için Puf masa uzatın.

ALTER TABLE StaffADD COLUMN resume CLOB(50K);ALTER TABLE StaffADD COLUMN picture BLOB(12M);Stafftable'a iki yeni sütun eklendi: 50K uzunluğunda bir CLOB olarak tanımlanan özgeçmiş ve 12M uzunluğunda bir BLOB olarak tanımlanan resim. Büyük bir nesnenin uzunluğu, sırasıyla kilobayt, megabayt veya gigabayt olduğunu belirten isteğe bağlı bir K, M veya G belirtimi ile sayısal bir değer olarak verilir. Belirtilmemişse, varsayılan uzunluk uygulama tarafından tanımlanır.

Oracle'da Nesne Yönelimli Uzantılar

Ek H'de, Oracle tarafından desteklenen temel veri türleri, PL / SQL prosedür programlama dili, saklı prosedürler ve fonksiyonlar ve tetikleyiciler de dahil olmak üzere, Oracle'ın bazı standart olanaklarını inceleyeceğiz. Yeni SQL: 2011 standardında görünen nesne yönelimli özelliklerin çoğu Oracle'da bir biçimde veya başka bir şekilde görünüyor. Bu bölümde, Oracle’daki nesne yönelimli özelliklerden bazılarını kısaca tartışıyoruz.

Kullanıcı tanımlı veri türleri

Ek H.2.3'te tartıştığımız dahili veri tiplerini desteklemenin yanı sıra, Oracle iki kullanıcı tanımlı veri tipini de destekler: nesne tipleri ve koleksiyon tipleri.

Nesne türleri

Bir nesne türü, bir SQL: 2011 nesne türü için tartıştığımıza benzer bir isim, yerleşik veri türlerine veya muhtemelen başka nesne türlerine dayalı bir dizi niteliğe ve bir dizi yönteme sahip bir şema nesnesidir. Örneğin, Adres, Personel ve Şube Tiplerini aşağıdaki gibi oluşturabiliriz:

CREATE TYPE AddressType AS OBJECT(street VARCHAR2(25),city VARCHAR2(15),postcode VARCHAR2(8));CREATE TYPE StaffType AS OBJECT(staffNo VARCHAR2(5),fName VARCHAR2(15),lName VARCHAR2(15),position VARCHAR2(10),sex CHAR,DOB DATE,salary DECIMAL(7, 2),MAP MEMBER FUNCTION age RETURN INTEGER,PRAGMA RESTRICT_REFERENCES(age, WNDS, WNPS, RNPS))NOT FINAL;CREATE TYPE BranchType AS OBJECT(branchNo VARCHAR2(4),address AddressType,MAP MEMBER FUNCTION getbranchNo RETURN VARCHAR2(4),PRAGMA RESTRICT_REFERENCES(getbranchNo, WNDS, WNPS,RNDS, RNPS));Daha sonra aşağıdaki ifadeyi kullanarak bir Şube (nesne) tablosu oluşturabiliriz:

CREATE TABLE Branch OF BranchType(branchNo PRIMARY KEY);

Bu, BranchNo sütunları ve AddressType türündeki address ile bir Branchtable oluşturur. Branchtable'daki her satır BranchType türünde bir nesnedir. Pragma cümlesi, üye işlevlerinin veritabanı tablolarına ve / veya paket değişkenlerine okuma / yazma erişimini reddeden bir derleyici yönergesidir (WNDS, veritabanı tablolarını değiştirmez, WNPS, paketlenmiş değişkenleri değiştirmez, RNDS, veritabanı tablolarını sorgulamaz ve RNPS'yi belirtir. demektir ki paket değişkenleri referans göstermez). Bu örnek ayrıca, Oracle’da başka bir nesnel-ilişkisel özelliği göstermektedir: yöntemlerin belirtilmesi.

Yöntemler

Bir nesne türünün yöntemleri üye, statik veya açık bir karşılaştırma olarak sınıflandırılır. Bir üye metodu, türünü içeren nesne tipi olan ilk parametresi olarak her zaman örtülü veya açık

bir SELF parametresi olan bir işlev veya prosedürdür. Bu tür yöntemler gözlemci ve mutator işlevleri olarak kullanışlıdır ve bencil tarzda çağrılır, örneğin yöntemin nesnenin nitelikleri arasındaki tüm argümanlarını bulduğu nesne.method (). BranchType yeni tipinde bir gözlemci üye yöntemi getbranchNo tanımladık; kısaca bu yöntemin uygulanmasını göstereceğiz. Statik metot, bir SELF parametresi içermeyen bir fonksiyon veya prosedürdür. Bu tür yöntemler, kullanıcı tanımlı yapıcıları veya döküm yöntemlerini belirlemek için kullanışlıdır ve bu yöntem, typename.method () 'deki gibi tür adıyla nitelendirilerek çağrılabilir. Nesne türlerinin örneklerini karşılaştırmak için bir karşılaştırma metodu kullanılır. Oracle, belirli bir türdeki nesneler arasında bir sipariş ilişkisi tanımlamak için iki yol sağlar:

• bir harita, Oracle’ın yerleşik türleri karşılaştırma yeteneğini kullanır. Örneğimizde, branchNoattribute içindeki değerleri temel alarak iki dal nesnesini karşılaştıran yeni tür BranchType için bir harita yöntemi tanımladık. Kısa zamanda bu yöntemin uygulanmasını gösteriyoruz.

• Bir emir, verilen nesne tipindeki iki nesneyi karşılaştırmak için kendi iç mantığını kullanır. Sipariş ilişkisini kodlayan bir değer döndürür. Örneğin, ilk küçük ise if1, eşitse 0, ilk büyük ise 1 olabilir.

Bir nesne türü için, bir harita yöntemi veya bir sipariş yöntemi tanımlanabilir, ancak her ikisi de tanımlanamaz. Bir nesne türünün karşılaştırma yöntemi yoksa, Oracle o tür iki nesne arasındaki ilişkiden daha büyük veya daha az belirleyemez. Ancak, aşağıdaki iki nesneyi aşağıdaki kuralları kullanarak eşit olup olmadığını belirlemeye çalışabilir:

• tüm nitelikler boş ve eşit ise, nesneler eşit olarak kabul edilir;

• iki nesnenin eşit olmayan değerlere sahip olmadığı bir özellik varsa, nesnelerin eşit olmadığı kabul edilir;

• aksi takdirde, Oracle karşılaştırmanın mümkün olmadığını bildirir (boş).

PL / SQL, Java ve C'de yöntemler uygulanabilir ve biçimsel parametrelerinin sayı, düzen veya veri türünde farklı olması koşuluyla aşırı yükleme desteklenir. Önceki örnekte, daha önce BranchTypean ve StaffTypeas türleri için daha önce belirtilen üye işlevlerinin gövdesini oluşturabiliriz:

CREATE OR REPLACE TYPE BODY BranchType ASMAP MEMBER FUNCTION getbranchNo RETURN VARCHAR2(4) ISBEGINRETURN branchNo;END;END;CREATE OR REPLACE TYPE BODY StaffType ASMAP MEMBER FUNCTION age RETURN INTEGER ISvar NUMBER;BEGINvar:5 TRUNC(MONTHS_BETWEEN(SYSDATE, DOB)/12);RETURN var;

END;END;GetbranchNo üye işlevi yalnızca branchNo özniteliğinin değerini döndüren bir gözlemci yöntemi değil, aynı zamanda bu tür için karşılaştırma (harita) yöntemi olarak da işlev görür. Kısa zamanda bu yöntemin kullanımına bir örnek vereceğiz. SQL: 2011'de olduğu gibi, kullanıcı tanımlı fonksiyonlar da CREATE TYPE ifadesinden ayrı olarak bildirilebilir. Genel olarak, kullanıcı tanımlı işlevler aşağıdaki yerlerde kullanılabilir:

• bir SELECT ifadesinin seçim listesi;

• NERED Maddesindeki bir koşul;

• SİPARİŞ BY veya GROUP BY cümleleri;

• INSERT ifadesinin VALUES yan tümcesi;

• bir UPDATE deyiminin SET cümlesi.

Oracle ayrıca, kullanıcı tanımlı operatörlerin CREATE OPERATOR deyimi kullanılarak oluşturulmasına izin verir. Yerleşik operatörler gibi, kullanıcı tanımlı bir operatör giriş olarak bir dizi işlenen alır ve bir sonuç döndürür. Yeni bir operatör tanımlandıktan sonra, diğer yerleşik operatörler gibi SQL ifadelerinde kullanılabilir.

Yapıcı yöntemler

Her nesne türünün, nesne türünün belirtimine göre yeni bir nesne oluşturan sistem tanımlı bir yapıcı yöntemi vardır. Yapıcı yöntem, nesne türüyle aynı ada sahip ve nesne türünün öznitelikleriyle aynı ada sahip ve aynı olan parametrelere sahip. Örneğin, yeni bir BranchType örneği oluşturmak için aşağıdaki ifadeyi kullanabiliriz: BranchType (‘B003’, AddressType (‘163 Main St’, ‘Glasgow’, ‘G11 9QX’); AddressType (‘163 Main St’, ‘Glasgow’, ‘G11 9QX’ ifadesi) ifadesinin kendisinin AddressType türü için yapıcıyı başlattığını unutmayın.

Nesne tanımlayıcıları

Bir nesne tablosundaki her satır nesnesi, varsayılan olarak her satır nesnesi için atanmış benzersiz bir sistem tarafından oluşturulan tanımlayıcı olan ilişkili bir mantıksal nesne tanımlayıcısına (OID) sahiptir. OID'nin amacı, bir nesne tablosundaki her satır nesnesini benzersiz şekilde tanımlamaktır. Bunu yapmak için, Oracle nesne tablosunun OID sütununda bir dizin oluşturur ve tutar. OID sütunu kullanıcılardan gizlenir ve iç yapısına erişimi yoktur. OID değerleri kendi içlerinde çok anlamlı olmasa da, OID'ler nesneleri almak ve gezinmek için kullanılabilir. (Nesne tablolarında görünen nesnelere satır nesneleri, ilişkisel tablo sütunlarını içeren nesneler veya diğer nesnelerin nitelikleri olarak sütun nesneleri denir.) Oracle her satır nesnesinin benzersiz bir OID'ye sahip olmasını gerektirir. Benzersiz OID değeri, satır nesnesinin birincil anahtarından gelmek veya CREATE TABLE deyiminde OBJENT IDENTIFIER PRIMARY KEY ya da OBJECT IDENTIFIER SYSTEM SİSTEMİ (varsayılan) cümlesini kullanarak sistem tarafından üretilmek üzere belirtilebilir. Örneğin, Branchtable'ın oluşumunu şu şekilde yeniden ifade edebiliriz:

CREATE TABLE Branch OF BranchType(branchNo PRIMARY KEY)

OBJECT IDENTIFIER IS PRIMARY KEY;

REF data type

Oracle, başvuruları belirtilen nesne türündeki satır nesnelerine yerleştirmek için REF adlı yerleşik bir veri türü sağlar. Aslında, iki satır nesnesi arasındaki ilişkiyi modellemek için bir REF kullanılır. Bir REF, başvurduğu nesneyi incelemek veya güncellemek ve başvurduğu nesnenin bir kopyasını elde etmek için kullanılabilir. Bir REF'de yapılabilecek tek değişiklik, içeriğini aynı nesne tipindeki farklı bir nesneye referansla değiştirmek veya boş bir değer atamaktır. Uygulama düzeyinde, Oracle, REF'leri oluşturmak için nesne tanımlayıcıları kullanır.

SQL: 2011'de olduğu gibi, bir SCOPE yan tümcesi kullanarak yalnızca belirli bir nesne tablosuna referanslar içerecek şekilde bir REF kısıtlanabilir. Bir REF tarafından tanımlanan nesnenin kullanılamaz duruma gelmesi mümkün olduğu için, örneğin nesnenin silinmesiyle, Oracle SQL, bu koşul için REF'leri test etmek için bir ZORUNLU DEĞERLENDİRMEYE sahiptir. Oracle ayrıca, bir REF tarafından belirtilen nesneye erişmek için bir referans düzenleme operatörü olan DEREF sağlar. Örneğin, bir şubenin yöneticisini modellemek için, BranchTypeto türünün tanımını değiştirebiliriz:

CREATE TYPE BranchType AS OBJECT(branchNo VARCHAR2(4),address AddressType,manager REF StaffType,MAP MEMBER FUNCTION getbranchNo RETURN VARCHAR2(4),PRAGMA RESTRICT_REFERENCES(getbranchNo, WNDS, WNPS,RNDS, RNPS));Bu durumda, yöneticiyi REF StaffType referans tipiyle modelledik. Bu sütuna kısaca nasıl erişileceğine dair bir örnek görüyoruz.

Kalıtım

Oracle, bir alt türün tek bir ana türden türetilmesine izin veren tek bir mirası destekler. Alt tip, süper tipin tüm niteliklerini ve yöntemlerini miras alır ve ayrıca yeni nitelikler ve yöntemler ekleyebilir ve miras alınan yöntemlerden herhangi birini geçersiz kılabilir. SQL: 2011'de olduğu gibi, UNDER yan tümcesi, alt türü belirtmek için kullanılır.

Koleksiyon türleri

Çok değerli öznitelikleri ve çoktan çoğa ilişkilerin modellenmesi için Oracle şu anda iki koleksiyon türünü desteklemektedir: dizi türleri ve iç içe geçmiş tablolar.

Dizi türleri Bir dizi, hepsi aynı veri türünde olan sıralı bir veri öğeleri kümesidir. Her öğenin, dizideki öğesinin konumuna karşılık gelen bir sayı olan bir dizini vardır. Bir dizi, sabit veya değişken bir boyuta sahip olabilir, ancak ikinci durumda, dizi türü bildirildiğinde en büyük boyutun belirtilmesi gerekir. Örneğin, bir şube, aşağıdaki yeni türü bildirerek Oracle’da modelleyebileceğimiz üç telefon numarasına sahip olabilir:

CREATE TYPE TelNoArrayType AS VARRAY(3) OF VARCHAR2(13);

Bir dizi türünün oluşturulması boşluk ayırmaz, bunun yerine şu şekilde kullanılabilecek bir veri türü tanımlar:

• İlişkisel bir tablonun bir sütununun veri tipi;

• Bir nesne türü özelliğini

• Bir PL / SQL değişken parametresi veya işlev dönüş türü.

Örneğin, BranchTypeto türünü şu yeni türün bir niteliğini içerecek şekilde değiştirebiliriz:

phoneList TelNoArrayType,

Bir dizi normalde satır içi, yani satırındaki diğer verilerle aynı tablo alanında saklanır. Ancak, yeterince büyükse, Oracle bir BLOB olarak saklar.

İç içe tablolar İç içe geçmiş bir tablo, tümü aynı veri türünde olan sıralanmamış bir veri öğeleri kümesidir. Yerleşik tipte veya nesne tipinde tek bir sütuna sahiptir. Sütun bir nesne türü ise, tablo, nesne türünün her bir niteliği için bir sütun içeren, çok sütunlu bir tablo olarak da görüntülenebilir. Örneğin, çalışanlar için yakın akraba modellemek için yeni bir tür tanımlayabiliriz:

İç içe geçmiş bir tablonun satırları, kullanıcı tarafından doğrudan sorgulanamayan ancak bakım amacıyla DDL ifadelerinde referans alınabilen ayrı bir depolama tablosunda saklanır. Bu saklama tablosundaki gizli bir sütun, Nested_Table_Id, satırları karşılık gelen üst satırlarla eşleştirir. Belirli bir Personel sırasının iç içe geçmiş tablosunun tüm öğeleri, farklı bir Personel sırasına ait Nested_Table_Idand öğelerinin aynı değerine sahiptir ve farklı bir Nested_Table_Id değeri farklıdır. NextOfKinnested tablosunun satırlarının NextOfKinStorageTable adlı ayrı bir depolama tablosunda saklanacağını belirledik. STORE AS maddesinde, biz

Ayrıca, depolama tablosunun aynı ebeveyne ait satırları kümelemek için dizin-organize (ORGANİZASYON DİZİNİ) olduğunu belirtti. COMPRESS değerini belirledik, böylece dizin anahtarının Nested_Table_Idpart öğesi, bir ana satır nesnesinin her satırı için tekrarlanmak yerine, bir ana satırın her satırı için yalnızca bir kez saklanacak. Nested_Table_Id belirtimi ve

depolama tablosunun birincil anahtarı olarak verilen nitelikleri iki amaca hizmet eder: indeks için anahtar işlevi görür ve ana tablonun her satırındaki iç içe geçmiş bir tablonun sütunlarının benzersizliğini zorlar (lName, telNo). . Bu sütunları anahtarın içine ekleyerek, ifade, sütunların her çalışanın içinde farklı değerler içermesini sağlar.

Oracle'da, koleksiyon tarafından yazılan değer kapsüllenmiştir. Sonuç olarak, bir kullanıcının bir koleksiyonun içeriğine Oracle tarafından sağlanan arabirimler aracılığıyla erişmesi gerekir. Genel olarak, kullanıcı iç içe geçmiş bir tabloya eriştiğinde, Oracle tüm toplama değerini kullanıcının istemci işlemine geri döndürür. Bunun performans etkileri olabilir ve bu nedenle Oracle, toplama değerine bir tutamağa benzeyen bir konumlandırıcı olarak iç içe geçmiş bir tablo değeri döndürme özelliğini destekler. RETURN AS LOCATOR yan tümcesi, iç içe geçmiş tablonun alındığında konumlandırıcı formunda döndürüleceğini belirtir. Bu belirtilmezse, varsayılan değer VALUE'dur; bu, iç içe geçmiş tüm tablonun yalnızca konumlandırıcı yerine iç içe tablonun yerine döndürüleceğini belirtir. İç içe geçmiş tablolar, dizilerden aşağıdaki şekillerde farklılık gösterir:

• Diziler maksimum boyuttadır, ancak iç içe geçmiş tablolar yoktur.

• Diziler her zaman yoğundur, ancak iç içe geçmiş tablolar seyrek olabilir ve böylece tek tek öğeler iç içe geçmiş bir tablodan silinebilir, ancak bir diziden silinemez.

• Oracle, dizi verilerini satır içi (aynı tablo alanında) depolar ancak iç içe geçmiş tablo verilerini, iç içe geçmiş tabloyla ilişkilendirilmiş, sistem tarafından oluşturulan bir veritabanı tablosu olan bir mağaza tablosunda satır dışı depolar.

• Veritabanında depolandığında, diziler sıralarını ve aboneliklerini korur, ancak iç içe geçmiş tablolar yoktur.

Nesne Tablolarını Değiştirme

Bu bölümde, daha önce gösterim amacıyla oluşturulan örnek nesneleri kullanarak nesne tablolarının nasıl değiştirileceğini kısaca tartışacağız. Örneğin, Stafftable'a aşağıdaki gibi nesneler ekleyebiliriz:

IN SERT INTO Staff VALUES(‘SG37’, ‘Ann’, ‘Beech’, ‘Assistant’, ‘F’, ‘10-Nov-1960’, 12000, NextOfKinNestedType());

IN SERT INTO Staff VALUES(‘SG5’, ‘Susan’, ‘Brand’, ‘Manager’, ‘F’, ‘3-Jun-1940’, 24000, NextOfKinNestedType());

NextOfKinNestedType () ifadesi, boş bir nextOfKinattribute oluşturmak için bu tür yapıcı yöntemini çağırır. Aşağıdaki ifadeyi kullanarak iç içe geçmiş tabloya veri ekleyebiliriz:

INSERT INTO TABLE(SELECT s.nextOfKin

FROM Staff s

WHERE s.staffNo =‘SG5’)

VALUES(‘John’, ‘Brand’, ‘0141-848-2000’);

Bu ifade, iç içe geçmiş tabloyu ekleme hedefi olarak tanımlamak için bir TABLE ifadesi kullanır; yani, Stafftable'da "SG5" olan bir StaffNoof öğesinin bulunduğu satır nesnesinin nextOfKincolumn öğesindeki iç içe geçmiş tablo. Son olarak, Branchtable'a bir nesne ekleyebiliriz:

INSERT INTO Branch

SELECT‘B003’, AddressType(‘163 Main St’, ‘Glasgow’, ‘G11 9QX’), REF(s),

TelNoArrayType(‘0141-339-2178’, ‘0141-339-4439’)

FROM Staff s

WHERE s.staffNo 5‘SG5’;

or alternatively:

INSERT INTO Branch VALUES(‘B003’, AddressType(‘163 Main St’, ‘Glasgow’,

‘G11 9QX’), (SELECT REF(s) FROM Staff s WHERE s.staffNo 5‘SG5’),

TelNoArrayType(‘0141-339-2178’, ‘0141-339-4439’));

Nesne tablolarını sorgulama Oracle'da, aşağıdaki sorguyu kullanarak sipariş edilen bir şube numarası listesi verebiliriz:

SELECT b.branchNo

FROM Branch b

ORDER BY VALUE(b);

Bu sorgu örtük olarak getbranch karşılaştırma metodunu çağırır. BranchType türü için bir harita metodu olarak tanımladığımızdan, branşmanların artan bir sıraya göre verilerini sıralar. Aşağıdaki sorguyu kullanarak her dal için tüm verileri döndürebiliriz:

SELECT b.branchNo, b.address, DEREF(b.manager), b.phoneList

FROM Branch b

WHERE b.address.city =‘Glasgow’

ORDER BY VALUE(b);

Yönetici nesnesine erişmek için DEREF operatörünün kullanımına dikkat edin. Bu sorgu, branchNocolumn, bir adresin tüm sütunlarını, manager nesnesinin tüm sütunlarını (StaffType türünde) ve ilgili tüm telefon numaralarının değerlerini yazar. Aşağıdaki sorguyu kullanarak belirli bir branştaki tüm personel için akraba verilerinin bir sonraki adımını alabiliriz:

SELECT b.branchNo, b.manager.staffNo, n.*

FROM Branch b, TABLE(b.manager.nextOfKin) n

WHERE b.branchNo =‘B003’;

Birçok uygulama toplama türlerini işleyemez ve bunun yerine verilerin düzleştirilmiş bir görünümünü gerektirir. Bu örnekte, TABLE anahtar sözcüğünü kullanarak iç içe seti kümelendiriyoruz veya düzleştirdik. Ayrıca, b.manager.staffNois ifadesinin y.staffNo için bir kısaltma ve notasyona sahip olduğunu not edin, burada y = DEREF (b.manager).

Nesne Görünümleri

Bölüm 4.4 ve 7.4'te görüşler kavramını inceledik. Bir görünümün sanal bir tablo olduğu gibi, bir nesne görüntüsü de sanal bir nesne tablosu. Nesne görünümleri, verilerin farklı kullanıcılar için özelleştirilmesine izin verir. Örneğin, bazı kullanıcıların hassas kişisel veya maaşla ilgili bilgileri görmesini önlemek için Stafftable'ın bir görünümünü oluşturabiliriz. Oracle'da, artık yalnızca bazı verilere erişimi kısıtlamakla kalmayan, aynı zamanda bazı yöntemlerin bir silme yöntemi gibi kullanılmasını da engelleyen bir nesne görünümü oluşturabiliriz. Ayrıca nesne görüşlerinin, tamamen ilişkisel temelli bir uygulamadan nesne yönelimli bir uygulamaya basit bir geçiş yolu sağladığı, böylece şirketlerin bu yeni teknolojiyi denemelerine olanak sağladığı iddia edildi.

Örneğin, Bölüm 9.6.1'de tanımlanan nesne türlerini yarattığımızı ve DreamHome için aşağıdaki ilişkisel şemayı, bu tür ilişkili türlerde BranchType ve StaffType ile oluşturduğumuzu ve doldurduğumuzu varsayalım:

Branch(branchNo, street, city, postcode, mgrStaffNo)

Telephone(telNo, branchNo)

Staff(staffNo, fName, lName, position, sex, DOB, salary, branchNo)

NextOfKin(staffNo, fName, lName, telNo)

Aşağıdaki nesne görünümü mekanizmasını kullanarak bir nesne-ilişkisel şema oluşturabiliriz:

CREATE VIEW StaffView OF StaffType WITH OBJECT IDENTIFIER(staffNo) ASSELECT s.staffNo, s.fName, s.lName, s.sex, s.position, s.DOB, s.salary,CAST(MULTISET(SELECT n.fName, n.lName, n.telNoFROM NextOfKin n WHERE n.staffNo = s.staffNo)AS NextOfKinNestedType) AS nextOfKinFROM Staff s;CREATE VIEW BranchView OF BranchType WITH OBJECT IDENTIFIER(branchNo) ASSELECT b.branchNo, AddressType(b.street, b.city, b.postcode) AS address,MAKE_REF(StaffView, b.mgrStaffNo) AS manager,CAST(MULTISET(SELECT telNo FROM Telephone tWHERE t.branchNo = b.branchNo) AS TelNoArrayType) AS phoneListFROM Branch b;

Her durumda, CAST / MULTISET ifadesinin içindeki SELECT alt sorgusu, ihtiyaç duyduğumuz verileri seçer (ilk durumda, personel üyesi için akraba sıradakilerin bir listesi ve ikinci durumda, şube için telefon numaralarının bir listesi) . MULTISET anahtar sözcüğü, bunun bir

singleton değeri yerine bir liste olduğunu gösterir ve CAST operatörü bu listeyi istenen türe atar. Ayrıca, nesne tanımlayıcısı birincil anahtar tabanlı bir nesne tablosundaki bir satır veya nesne görünümünde bir satır için REF oluşturan MAKE_REF operatörünün kullanıldığını unutmayın. WITH OBJECT IDENTIFIER, nesne görünümündeki her satırı tanımlamak için anahtar olarak kullanılacak nesne türünün özelliklerini belirtir. Çoğu durumda, bu özellikler temel tablonun birincil anahtar sütunlarına karşılık gelir. Belirtilen nitelikler benzersiz olmalı ve görünümde tam olarak bir satır tanımlamalıdır. Bir nesne tablosunda veya bir nesne görünümünde nesne görünümü tanımlanmışsa, bu madde ihmal edilebilir veya BEDAVA TANIMCI VARSAYILAN belirtilebilir. Her durumda, benzersizliği sağlamak için karşılık gelen temel tablonun birincil anahtarını belirledik.

Ayrıcalıklar

Oracle, kullanıcı tanımlı türler için aşağıdaki sistem ayrıcalıklarını tanımlar:

• CREATE TYPE - kullanıcının şemasında kullanıcı tanımlı türler oluşturmak için;

• CREATE ANY TYPE - herhangi bir şemada kullanıcı tanımlı türler oluşturmak için;

• ALTER ANY TYPE- herhangi bir şemada kullanıcı tanımlı türler değiştirmek için;

• DROP ANY TYPE - adlandırılmış türleri herhangi bir şemada bırakmak;

• EXECUTE ANY TYPE - herhangi bir şemada adlandırılmış tiplerin kullanılması ve referans gösterilmesi;

• UNDER ANY TYPE - nihai olmayan nesne türlerinin altında alt tipler oluşturmak için;

• UNDER ANY VIEW - herhangi bir nesne görünümünde alt görünümler oluşturmak için.

Ek olarak, EXECUTE şema nesnesi ayrıcalığı, kullanıcının bir tablo tanımlamak için türü kullanmasını, ilişkisel bir tabloda bir sütunu tanımlamasını, adlandırılmış türün bir değişkenini veya parametresini bildirmesini ve türün yöntemlerini çağırmasını sağlar.

Sorular

1- Sizden DreamHome Genel Müdüründen, kuruluş için nesne-ilişkisel bir DBMS'nin uygulanabilirliği hakkında bir rapor araştırması ve hazırlaması istendi. Rapor, RDBMS teknolojisini ORDBMS teknolojisiyle karşılaştırmalı ve ORDBMS'in organizasyon içinde uygulanmasının avantajlarını ve dezavantajlarını ve algılanan sorunlu alanları ele almalıdır. Rapor aynı zamanda nesne yönelimli bir DBMS'nin uygulanabilirliğini de göz önünde bulundurmalı ve DreamHome için iki sistemin bir karşılaştırmasını içermelidir. Son olarak, rapor ORDBMS for DreamHome'un uygulanabilirliği hakkında tam olarak gerekçelendirilmiş sonuçlar içermelidir.

2- İlişkisel bir veritabanını nesne ilişkisel veritabanına dönüştürürken göz önünde bulundurulacak önemli konuları tartışın.