OOP DB, nesne yönelimli bir veritabanıdır. Çok seviyeli istemci-sunucu sistemleri

]. Bu, sunucuların ve istemcilerin yeteneklerinin daha verimli kullanımı için veri depolama, işleme ve sunma işlevlerini ayırmanıza olanak tanır.

Çok katmanlı istemci-sunucu mimarisi arasında en yaygın olanı üç katmanlı mimaridir ( üç katmanlı mimari, üç katmanlı), aşağıdaki uygulama bileşenlerinin varlığını varsayar: bağlı bir istemci uygulaması (genellikle "ince istemci" veya terminal derler). uygulama sunucusu, sırayla bağlı veritabanı sunucusu [ , ].

pirinç. 5.4.

Pirinç. 5.4. Katmanlı bir istemci-sunucu mimarisinin temsili

Terminal, son kullanıcı için gerçek uygulama olan birinci seviyeyi temsil eden bir arayüz (genellikle grafik) bileşenidir. İlk seviye, veritabanıyla doğrudan bağlantılara sahip olmamalı (güvenlik gereksinimleri nedeniyle), ana iş mantığıyla yüklenmeli (ölçeklenebilirlik gereksinimleri nedeniyle) ve uygulamanın durumunu (güvenilirlik gereksinimleri nedeniyle) saklamalıdır. En basit iş mantığı ilk seviyeye alınabilir ve genellikle alınır: yetkilendirme arayüzü, şifreleme algoritmaları, giriş değerlerinin geçerliliği ve formata uygunluğu için kontrol edilmesi, terminalde zaten yüklü olan verilerle basit işlemler (sıralama, gruplama, değerleri sayma) .
Uygulama sunucusu ikinci katta yer almaktadır. İkinci seviyede, iş mantığının çoğu yoğunlaşmıştır. Dışında, terminallere aktarılan parçaların yanı sıra üçüncü seviyeye daldırılmış saklı yordamlar ve tetikleyiciler kalır.
Veritabanı sunucusu veri depolama sağlar ve üçüncü seviyeye yerleştirilir. Bu genellikle standart bir ilişkisel veya nesne yönelimli DBMS'dir. Üçüncü seviye, saklı yordamlar, tetikleyiciler ve uygulamayı aşağıdakiler açısından açıklayan bir şema ile birlikte bir veritabanı ise: ilişkisel model, ardından ikinci seviye şu şekilde oluşturulur: yazılım arayüzüİstemci bean'lerini veritabanı uygulama mantığına bağlayan bir A.

En basit konfigürasyonda, fiziksel olarak uygulama sunucusu ile kombine edilebilir veritabanı sunucusu ağ üzerinden bir veya daha fazla terminalin bağlı olduğu tek bir bilgisayarda.

"Doğru" (güvenlik, güvenilirlik, ölçeklendirme açısından) yapılandırmada veritabanı sunucusu bir veya daha fazla kişinin bağlı olduğu ayrılmış bir bilgisayarda (veya kümede) bulunan uygulama sunucuları, sırasıyla terminallerin ağ üzerinden bağlandığı.

Bu mimarinin avantajları şunlardır: [ , , , ]:

istemci yazılımı yönetim gerektirmez;
ölçeklenebilirlik;
yapılandırılabilirlik - seviyelerin birbirinden izolasyonu, arıza durumunda veya seviyelerden birinde planlanmış bakım sırasında sistemi hızlı ve kolay bir şekilde yeniden yapılandırmanıza olanak tanır;
yüksek güvenlik;
yüksek güvenilirlik;
terminaller arasındaki kanalın (ağ) hızı için düşük gereksinimler ve uygulama sunucusu;
Düşük performans gereksinimleri ve teknik özellikler terminaller, maliyet düşürmelerinin bir sonucu olarak.

sunucu bölümünün karmaşıklığı artıyor ve sonuç olarak yönetim ve bakım maliyeti artıyor;
uygulama oluşturmanın daha yüksek karmaşıklığı;
konuşlandırması ve yönetmesi daha zor;
yüksek performans gereksinimleri uygulama sunucuları Ve veritabanı sunucusu ve dolayısıyla sunucu donanımının yüksek maliyeti;
arasındaki kanalın (ağ) hızı için yüksek gereksinimler veritabanı sunucusu Ve uygulama sunucuları.

Verim;
sunum katmanı;
mantık seviyesi;
Veri katmanı;
Veri.

Pirinç. 5.5. Beş katmanlı çok katmanlı mimari "istemci-sunucu"

Görünüm, kullanıcıya doğrudan görüntülenen tüm bilgileri içerir: oluşturulan html sayfaları, stil sayfaları, resimler.

Sunum katmanı, kullanıcı ve sistem arasındaki etkileşimle ilgili her şeyi kapsar. Sunum katmanının temel işlevleri, bilgilerin görüntülenmesi ve kullanıcı tarafından girilen komutların yorumlanması ve bunların mantık ve veri bağlamında uygun işlemlere dönüştürülmesidir.

Mantık seviyesi, amacına ulaşmak için tasarlanmış sistemin ana fonksiyonlarını içerir. Bu işlevler, girdi ve saklanan verilere dayalı hesaplamaları, tüm veri öğelerini kontrol etmeyi ve sunum katmanından komutları işlemeyi ve veri katmanına bilgi iletmeyi içerir.

Veri erişim katmanı, uygulama adına görevler gerçekleştiren üçüncü taraf sistemlerle etkileşim sağlayan bir işlevler alt kümesidir.

Sistem verileri genellikle bir veritabanında saklanır.

5.1.6. Dağıtılmış sistem mimarisi

Bu tür bir sistem, sistem organizasyonu açısından daha karmaşıktır. öz dağıtılmış sistemlerönemli verilerin yerel kopyalarını tutmaktır.

Şematik olarak, böyle bir mimari Şekil l'de gösterildiği gibi gösterilebilir. 5.6.

Pirinç. 5.6.

Kurumsal yönetimde kullanılan verilerin %95'inden fazlası tek bir kişisel bilgisayara yerleştirilebilir ve bu da bağımsız çalışma olanağı sağlar. Bu bilgisayarın oluşturduğu düzeltmeler ve eklemeler akışı, kullandığı veri miktarına kıyasla çok küçüktür. Bu nedenle, sürekli olarak kullanılan verileri bilgisayarlarda depolarsanız ve bunlar arasında depolanan verilere yapılan düzeltmeler ve eklemeler alışverişini düzenlerseniz, iletilen toplam trafik keskin bir şekilde düşecektir. Bu, bilgisayarlar arasındaki iletişim kanalları için gereksinimleri azaltmanıza ve daha sık eşzamansız iletişim kullanmanıza olanak tanır ve bu sayede, kullanan güvenilir dağıtılmış bilgi sistemleri oluşturur. bireysel elemanlar kararsız bağlantıİnternet türü, mobil iletişim, ticari uydu kanalları. Ve öğeler arasındaki trafiğin en aza indirilmesi, böyle bir bağlantıyı çalıştırmanın maliyetini oldukça uygun hale getirecektir. Tabii ki, böyle bir sistemin uygulanması temel değildir ve biri zamanında veri senkronizasyonu olan bir dizi sorunun çözülmesini gerektirir.

Her iş istasyonu bağımsızdır, yalnızca çalışması gereken bilgileri içerir ve tüm sistemdeki verilerin uygunluğu, diğer iş istasyonlarıyla sürekli mesaj alışverişi ile sağlanır. İş istasyonları arasında mesajlaşma uygulanabilir Farklı yollar, e-posta yoluyla veri göndermekten ağlar üzerinden veri iletmeye kadar.

İstemci-sunucu mimarisi(istemci-sunucu mimarisi), kaynaklarının büyük kısmının müşterilerine hizmet veren sunucularda yoğunlaştığı bir bilgi ağı kavramıdır. Söz konusu mimari, iki tür bileşen tanımlar: sunucular ve istemciler.

sunucu - sağlayan bir nesnedir. hizmet istek üzerine diğer ağ nesneleri. Hizmet bir müşteri hizmetleri sürecidir.

Şekil İstemci-Sunucu Mimarisi

Sunucu, istemcilerin talimatlarına göre çalışır ve görevlerinin yürütülmesini yönetir. Sunucu, her işi yürüttükten sonra sonuçları işi gönderen istemciye gönderir.

İstemci-sunucu mimarisindeki hizmet işlevi, çeşitli uygulama işlemlerinin gerçekleştirildiği bir dizi uygulama programı tarafından tanımlanır.

Çağıran süreç hizmet fonksiyonu belirli işlemler yoluyla denir müşteri. Bir program veya kullanıcı olabilir. Müşteriler sunucu kaynaklarını kullanan ve kolaylık sağlayan iş istasyonlarıdır. Kullanıcı arayüzleri. Kullanıcı arayüzleri Bunlar, bir sistem veya ağ ile kullanıcı etkileşimi için prosedürlerdir.

Şekil İstemci-sunucu modeli

İstemci başlatıcıdır ve e-posta veya diğer sunucu hizmetlerini kullanır. Bu süreçte müşteri bir hizmet talep eder, bir oturum kurar, istediği sonuçları alır ve bittiğinde bildirir.

İÇİNDE adanmış ağlar dosya sunucusu özel bir bağımsız bilgisayar bir sunucu ağı işletim sistemi kurulur. Bu bilgisayar olur sunucu. Yazılım ( İLE), iş istasyonunda yüklü olması, sunucuyla iletişim kurmasını sağlar. En yaygın ağ işletim sistemleri şunlardır:

Ağ işletim sistemine ek olarak, ağın avantajlarından yararlanmak için ağ uygulamalarına ihtiyaç vardır.

Sunucu tabanlı ağların sahip olduğu en iyi performans ve artan güvenilirlik. Sunucunun ana sahibi ağ kaynakları, diğer iş istasyonları tarafından kullanılır.

Modern istemci-sunucu mimarisinde, dört nesne grubu ayırt edilir: istemciler, sunucular, veriler ve ağ hizmetleri. İstemciler, kullanıcı iş istasyonlarındaki sistemlerde bulunur. Veriler çoğunlukla sunucularda saklanır. Ağ Servisleri paylaşılan sunucular ve verilerdir. Ek olarak, hizmetler veri işleme prosedürlerini yönetir.

Ağ istemcisi - sunucu mimarisi aşağıdaki avantajlara sahip:

Çok sayıda iş istasyonu içeren ağları düzenlemeye izin verin;

Ağ yönetimini basitleştiren merkezi kullanıcı hesabı, güvenlik ve erişim yönetimi sağlayın;

Ağ kaynaklarına verimli erişim;

Kullanıcının ağda oturum açabilmesi ve kullanıcı haklarına tabi tüm kaynaklara erişebilmesi için tek bir parolaya ihtiyacı vardır.

Bir ağın avantajlarının yanı sıra, istemci-sunucu mimarilerinin bir takım dezavantajları da vardır:

Bir sunucu hatası, en azından ağ kaynaklarının kaybıyla birlikte ağı kullanılamaz hale getirebilir;

Yönetim için kalifiye personel gerektirir;

Daha yüksek ağ ve ağ ekipmanı maliyetine sahip olun.

Ana Sayfa > Belge

Çok düzeyli "istemci-sunucu"

Çok düzeyli istemci-sunucu mimarisi (Multitier mimarisi) - veri işleme işlevinin bir veya daha fazla ayrı sunucuya yerleştirildiği bir tür istemci-sunucu mimarisi. Bu, sunucuların ve istemcilerin yeteneklerinin daha verimli kullanımı için veri depolama, işleme ve sunma işlevlerini ayırmanıza olanak tanır. Çok katmanlı istemci-sunucu mimarisi arasında en yaygın olanı, aşağıdaki uygulama bileşenlerinin varlığını ima eden üç katmanlı bir mimaridir (üç katmanlı mimari, üç katmanlı): bir istemci uygulaması (genellikle "ince istemci" derler). " veya terminal) sunucu Veritabanına bağlı olan uygulama sunucusuna bağlıdır. terminal- Bu, son kullanıcı için gerçek uygulama olan birinci seviyeyi temsil eden bir arayüz (genellikle grafik) bileşenidir. En basit iş mantığı birinci seviyeye taşınabilir ve genellikle taşınır: yetkilendirme arayüzü, şifreleme algoritmaları, giriş değerlerinin doğrulanması Uygulama sunucusu ikinci seviyede bulunur. İkinci seviyede, iş mantığının çoğu yoğunlaşmıştır. Dışında, terminallere aktarılan parçaların yanı sıra üçüncü seviyeye daldırılmış saklı yordamlar ve tetikleyiciler kalır. Veritabanı sunucusu, veri depolama sağlar ve üçüncü seviyeye yerleştirilir. Bu genellikle standart bir ilişkisel veya nesne yönelimli DBMS'dir. Üçüncü düzey, saklı yordamlar, tetikleyiciler ve uygulamayı ilişkisel model açısından açıklayan bir şema içeren bir veritabanıysa, ikinci düzey, istemci bileşenlerini veritabanının uygulama mantığına bağlayan bir programlama arabirimi olarak oluşturulur. En basit konfigürasyonda, uygulama sunucusu, ağ üzerinden bir veya daha fazla terminalin bağlı olduğu bir bilgisayarda veri tabanı sunucusuyla fiziksel olarak birleştirilebilir. "Doğru" (güvenlik, güvenilirlik, ölçeklendirme açısından) yapılandırmada, veritabanı sunucusu, ağ üzerinden bir veya daha fazla uygulama sunucusunun bağlı olduğu, ayrılmış bir bilgisayarda (veya kümede) bulunur; sırayla, terminaller ağ üzerinden bağlanır. Bu mimarinin avantajları şunlardır:

istemci yazılımı yönetim gerektirmez; ölçeklenebilirlik; yapılandırılabilirlik - seviyelerin birbirinden izolasyonu, arıza durumunda veya seviyelerden birinde planlanmış bakım sırasında sistemi hızlı ve kolay bir şekilde yeniden yapılandırmanıza olanak tanır; yüksek güvenlik; yüksek güvenilirlik; terminaller ve uygulama sunucusu arasındaki kanalın (ağ) hızı için düşük gereksinimler; terminallerin performansı ve teknik özellikleri için düşük gereksinimler, sonuç olarak maliyetlerinde bir azalma.Eksiler:

sunucu bölümünün karmaşıklığı artıyor ve sonuç olarak yönetim ve bakım maliyeti artıyor; uygulama oluşturmanın daha yüksek karmaşıklığı; konuşlandırması ve yönetmesi daha zor; uygulama sunucuları ve veritabanı sunucuları için yüksek performans gereksinimleri ve dolayısıyla sunucu donanımının yüksek maliyeti; veritabanı sunucusu ile uygulama sunucuları arasındaki kanalın (ağ) hızı için yüksek gereksinimler.

26. Ölçüm modunda veritabanı ile çalışmanın optimizasyonu.

Eşzamanlılık Denetimi Özellikleri Eşzamanlı erişim kontrolü - farklı DBMS'lerin farkı budur. Bir DBMS'yi bir dosya sisteminden ve bir DBMS'yi diğerinden ayıran şey budur. Bir programcı için veritabanı uygulamasının eşzamanlı erişim koşullarında doğru çalışması önemlidir ve kontrol edilmesi sürekli unutulan da budur. Sıralı erişim koşullarında iyi çalışan teknikler, birkaç oturum tarafından aynı anda uygulandığında çok daha kötü çalışır. Eşzamanlılık kontrol mekanizmalarının belirli bir DBMS'de nasıl uygulandığını tam olarak bilmiyorsanız, o zaman: veri bütünlüğü ihlal edilecektir; uygulama, az sayıda kullanıcıyla bile beklenenden daha yavaş çalışacak; çok sayıda kullanıcıya ölçeklendirme yeteneği kaybolacaktır. problemler eşzamanlı erişim, tespit edilmesi en zor olanıdır - zorluklar, çok iş parçacıklı bir programda hata ayıklamaya benzer. Bir program kontrollü, yapay bir hata ayıklayıcı ortamında iyi çalışabilir, ancak "gerçek dünyada" her zaman çökebilir. Örneğin, yoğun erişim koşulları altında, iki iş parçacığı aynı veri yapısını aynı anda değiştiriyor olabilir. Bu tür hataların tespit edilmesi ve düzeltilmesi oldukça zordur. Engelleme Uygulaması DBMS, aynı anda yalnızca bir işlemin belirli verileri değiştirebilmesi için kilitler kullanır. Basitçe söylemek gerekirse, kilitler eşzamanlı erişimi sağlayan bir mekanizmadır. Eşzamanlı değişiklikleri önleyen belirli bir engelleme modelinin yokluğunda. Oracle DBMS'de engelleme ilkeleri. Oracle, verileri satır düzeyinde ve yalnızca değiştiğinde kilitler. Kilitler asla blok veya masa seviyesine yükseltilmez. Oracle, okuma amacıyla asla verileri kilitlemez. Normal okumalar satırlarda kilit oluşturmaz. Veri yazan bir oturum, veri okuyan oturumları engellemez. Yine, okuma işlemleri yazma işlemleri tarafından engellenmez. Bu, okumaların yazmalar tarafından engellendiği hemen hemen tüm diğer DBMS'lerden temel olarak farklıdır. Bir veri yazma oturumu, yalnızca başka bir yazma oturumu değiştirilmek üzere olan satırı zaten kilitlemişse kilitlenir. Bir okuma oturumu hiçbir zaman bir yazma oturumunu engellemez. Rezerve etmeye çalıştığımız kaynağı kilitleyerek, aynı anda başka hiçbir oturumun kaynağın kullanım planını değiştirmemesini sağlıyoruz. İşlemimiz tamamlanana kadar beklemesi gerekecek - bundan sonra yapılan rezervasyonu görebilecek. Planların çakışma olasılığı böylece ortadan kaldırılır. Geliştirici, çok kullanıcılı bir ortamda bazen çok iş parçacıklı programlamadakiyle aynı hileleri kullanmanın gerekli olduğunu anlamalıdır. Bu durumda, FOR UPDATE yapısı bir semafor gibi çalışır. Kaynak tablosundaki belirli bir satıra sıralı erişim sağlayarak iki oturumun aynı anda kaynak ayırmamasını sağlar. Bu yaklaşım, rezerve edilecek binlerce kaynak olabileceğinden ve oturumların her seferinde belirli bir kaynağı değiştirmesini sağladığımızdan, yüksek derecede eşzamanlılık sağlar. Bu, değişmemesi gereken verileri manuel olarak kilitlemeniz gereken birkaç durumdan biridir. Gerekli olduğunda ve aynı derecede önemli olarak, gerekli olmadığında (gerekli olmadığında bir örnek aşağıda verilmiştir) durumları tanıyabilmek gerekir. Ayrıca bu teknik, diğer DBMS'lerde olduğu gibi kaynağın diğer oturumlar tarafından okunmasını engellemez ve bu da yüksek ölçeklenebilirlik sağlar. çok değişkenlik Oracle DBMS'nin aşağıdakileri sağladığı mekanizmadır: sorgular için okuma tutarlılığı: sorgular yürütmenin başlangıcında tutarlı sonuçlar üretir; engellenmeyen sorgular: sorgular, diğer DBMS'lerde olduğu gibi verileri değiştiren oturumlar tarafından engellenmez. Bunlar iki çok önemli Oracle veritabanı kavramıdır. Çok değişkenlik terimi, Oracle'ın veri tabanında aynı anda birden çok veri sürümünü tutabilmesi gerçeğinden gelir. Çok değişkenliğin özünü anlayarak, veritabanından elde edilen sonuçları her zaman anlayabilirsiniz. Örneğin, bir test tablosu T oluşturduk ve onu verilerle doldurduk. Bu tablo için bir imleç açtık. Bu imleç ile veri seçmedik, sadece açtık. Bir imleci açarken Oracle'ın isteğe "yanıt vermediğini" unutmayın; imleç açıldığında verileri hiçbir yere kopyalamaz (aksi takdirde milyarlarca satır içeren bir tablo için imleci açmanın ne kadar süreceğini hayal edin). İmleç basitçe açılır ve verilere erişirken sorgunun sonuçlarını verir. Başka bir deyişle, imleç aracılığıyla getirilirken tablodaki verileri okuyacaktır. Aynı (veya farklı) oturumda, tablodaki tüm verileri sileriz. Üstelik bu silme işlemini bile gerçekleştiriyoruz (COMMIT). Başka sıra yok, değil mi? Aslında, bir imleç kullanılarak alınabilirler.Aslında, OPEN komutu tarafından döndürülen sonuç seti, imlecin açıldığı anda önceden belirlenmiştir. İmleci açarken tablonun tek bir veri bloğunu okumadık ama sonucun sabit kodlanmış olduğu ortaya çıktı. Verileri getirene kadar bu sonucu bilemeyeceğiz, ancak imlecimizin bakış açısından bu sonuç değişmedi. İmleç açıldığında Oracle tüm bu verileri başka bir konuma kopyalamış değil; Veriler, silme operatörü tarafından geri alma segmenti adı verilen bir veri bölgesine yerleştirilerek saklandı. Okuma tutarlılığının konusu budur ve Oracle'ın çoktan seçmeli şemasının nasıl çalıştığını ve bunun sonuçlarının ne olduğunu anlamazsanız, yalnızca Oracle'ın RDBMS'sinden tam olarak yararlanamayacaksınız, aynı zamanda bunu da yapamayacaksınız. veri bütünlüğünü garanti eden doğru Oracle uygulamalarını oluşturmak. Bu nedenle, diğer VTYS'lerde tutarlılık ve eşzamanlılık uygulamasına alışkınsanız veya bu tür kavramlarla hiç karşılaşmadıysanız (DBMS ile gerçek bir deneyiminiz yoksa), o zaman artık bunların anlaşılmasının işiniz için ne kadar önemli olduğunu anlıyorsunuz. Oracle'ın potansiyelini en üst düzeye çıkarmak için, bu sorunları ve diğer veritabanlarında değil, Oracle'da nasıl çözeceğinizi anlamanız gerekir.

30. Ek sunucusu. Ek sunucusunun yapısı. Ek sunucu kaydı

Uygulama sunucusu, dağıtılmış bir uygulamanın iş mantığının çoğunu kapsar ve veritabanına istemci erişimi. Uygulama sunucusunun ana kısmı uzak veri modülüdür. İlk olarak, normal bir veri modülü gibi, görsel olmayan veri erişimini ve sağlayıcı bileşenlerini barındırmak için bir platformdur. Üzerine yerleştirilen veri kümelerini içine alan bağlantı, işlem ve bileşenlerin bileşenleri, veritabanı sunucusuyla iletişim kuran üç katmanlı bir uygulama sağlar. Bunlar ADO, BDE, InterBase Express, dbExpress teknolojileri için bileşen setleri olabilir. İkinci olarak, uzak veri modülü, istemcilere AppServer arabirimini veya onun soyundan gelenleri sağlayarak uygulama sunucusunun temel işlevlerini uygular. Bunu yapmak için, uzak veri modülü bir baypas içermelidir. sağlayıcı bileşenlerinin sayısı TDataSetProvider. Bu bileşenler, veri paketlerini istemci uygulamaya, özellikle TdientDataSet bileşenlerine iletir ve ayrıca arabirim yöntemlerine erişim sağlar.
Delphi uzak veri modülleri içerir. Bunları oluşturmak için Delphi Deposunun Multitier, WebSnap ve WebServices sayfalarını kullanın.
Uzak Veri Modülü - Otomasyon sunucusunu kapsayan bir uzak veri modülü. DCOM, HTTP, yuvalar aracılığıyla bağlantıları düzenlemek için kullanılır (bkz. Bölüm 21).
Transactioiial Data Module, MTS (Microsoft Transaction Server) sunucusunu kapsayan bir uzak veri modülüdür.
SOAP Sunucusu Veri Modülü - bir SOAP sunucusunu (Basit Nesne Erişimi protokol).
WebSnap Veri Modülü, sunucu olarak Web servislerini ve bir Web tarayıcısını kullanan bir uzak veri modülüdür.
Bir istemciye iletilecek bir dizi veriyi kapsülleyen her bean, data modülünde ilişkili bir sağlayıcı bean'e sahip olmalıdır.

34. Vіdmіnnostі SQL vіd mov vysokogo ryvnya. SQL deyimlerinin kategorileri.

SQL prosedürel bir dil değildir ve genel olarak bir programlama dili değildir.PL/SQL, SQL dilini kapsayan adım adım prosedürel bir programlama dilidir. Sonuç, C++, Pascal, vb. gibi iyi geliştirilmiş bir üçüncü nesil programlama dilidir (3GL). üzerinde.ancak ADA dilinden paketler (package) gibi bir araç miras alınmıştır.PL/SQL sıkı tip kontrolü sağlar, tüm tip uyumsuzluk hataları derleme ve yürütme aşamasında tespit edilir. Açık ve örtük tip dönüştürme de desteklenir.PL/SQL - karmaşık veri yapılarını destekler, esnek bir uygulama programlama ortamı oluşturmak için alt yordam aşırı yüklemesi de sağlanır.PL / SQL dili - üzerinde senkronize hata işleme için bir İstisna İşleyici öğesine (istisna işleyici) sahiptir. PL/SQL kod yürütme aşaması.Ayrıca, nesne yönelimli programlama dilleri düzeyinde veritabanı nesneleri oluşturmak ve bunlarla çalışmak için bazı araçlara sahip olmasına rağmen, PL/SQL dili nesne yönelimli değildir. makineden bağımsız dil programlama. Şebeke bir veya daha fazla ifade üzerinde gerçekleştirilecek eylemi gösteren bir karakterdir. SQL Server tarafından kullanılan operatör kategorileri: Aritmetik Operatörler, Mantıksal Operatörler, Atama Operatörü, Kapsam Çözümleme Operatörü, Bitsel Operatörler, Set Operatörleri, Karşılaştırma Operatörleri, Dize Birleştirme Operatörü, Bileşik Operatörler, Tekli Operatörler

36) Mantıksal SQL ifadeleri. Verimli sorgu oluşturma

AND, OR ve NOT mantıksal işleçleri. AND ve OR operatörleri, WHERE yan tümcelerinde arama terimlerini birleştirmek için kullanılır. DEĞİL operatörü, arama koşulunun değerini tersine çevirir. AND işleci iki koşulu birleştirir ve yalnızca her iki koşul da doğruysa TRUE değerini döndürür. Örneğin, bu sorgu, müşteri kimliğinin (BusinessEntityID) 1 rakamıyla başladığı ve mağaza adının "Bicycle" ile başladığı yalnızca bir satır döndürür: SELECT BusinessEntityID, NameFROM AdventureWorks2008R2.Sales.StoreWHERE BusinessEntityID LIKE "%1" AND Name LIKE N" Bicycle%";OR operatörü ayrıca iki koşulu birbirine bağlar, ancak herhangi bir koşul doğruysa TRUE değerini döndürür. Aşağıdaki sorgu, müşteri kimliğinin 1 ile başladığı veya mağaza adının "Bicycle" ile başladığı 349 satır döndürür: SELECT BusinessEntityID, NameFROM AdventureWorks2008R2.Sales.StoreWHERE BusinessEntityID LIKE "%1" OR Name LIKE N"Bicycle%"; Optimizasyon: SQL sorgu optimizasyonu Giderek daha fazla uygulama veritabanlarını kullanıyor. Giderek daha fazla verinin saklanması ve işlenmesi gerekiyor. Bir uygulama yavaşsa, programcılar, kullanıcılar ve yöneticiler öncelikle zayıf ağ performansından, kötü sunucu donanımından ve birbirlerinden bahseder :). Ve optimizasyonu unutuyorlar ve bu, uygulama performans iyileştirme için acımasız bir analize tabi tutulana kadar devam edecek. Bir uygulamanın hızını artırmanın bir yolu, SQL sorgularını optimize etmektir. Bu yöntem iyidir, çünkü SQL sunucu optimizasyonu ormanına girmeniz gerekmez. Verimsiz SQL sorgularından kaçınmak daha kolaydır. Ancak bu zaten olmuşsa, mevcut hoş olmayan durumlardan çıkış yolları arayın. Genel optimizasyonHer SQL işleminin sözde bir "fayda faktörü" vardır - bu işlemin verimlilik düzeyi. Puan ne kadar yüksek olursa, işlem o kadar "yararlı" olur, bu da SQL sorgusunun daha hızlı yürütüldüğü anlamına gelir.Hemen hemen her koşul, iki işlenenden ve aralarındaki işlemin işaretinden oluşur. ÖrneklerTabloları daha iyi anlamak için sorgu puanının nasıl hesaplandığına dair bir örneğe bakalım... WHERE smallint_column = 123455 puan soldaki alan için (smallint_column), 2 puan tam sayısal işlenen için (smallint_column), 10 puan için karşılaştırma işlemi (=) ve sağdaki değer için 10 puan (12345 ). Toplamda 27 puan aldık. Şimdi daha fazlasını düşünün karmaşık örnek:... WHERE char_column >= varchar_column || "x" Sol kenar boşluğu için 5 puan (char_column), karakter işleneni için 0 puan (char_column), büyük veya eşittir (>=) için 5 puan, mantıksal ifade için 3 puan (varchar_column || "x"), 0 puan karakter işleneni için (varchar_column). Sonuç olarak 13 puan alıyoruz.Doğal olarak her talep için bu tür hesaplamalar yapılması gerekmiyor. Ancak, belirli bir sorgunun koşullarının hızıyla ilgili soru ortaya çıktığında, bu iki tablo kullanılarak bulunabilir. Sorgu hızı ayrıca seçilen veri miktarından ve aşağıda tartışacağımız ek direktiflerden de etkilenir. Ayrıca, "fayda faktörü"nün hesaplanmasının bir evrensel yol optimizasyon. Her şey özel duruma bağlıdır.Sorgu optimizasyonundaki temel yasa, dönüşüm yasasıdır. Koşulu nasıl temsil ettiğimiz önemli değil, asıl mesele sonucun aynı kalması. Örneğe tekrar bakalım. Bir sorgu var: ... WHERE sütun1< column2 AND column2 = column3 AND column1 = 5. Используя перестановку, получаешь запрос: …WHERE 5 < column2 AND column2 = column3 AND column1 = 5. Результат запроса будет один и тот же, а продуктивность разной, потому что использование точного значения (5) влияет на производительность.Если ты изучал С или С++, то знаешь, что выражение x=1+1-1-1 во время компиляции станет x=0. Удивительно, что лишь некоторые БД способны выполнять такие операции. При выполнении запроса БД будет выполнять операции сложения и вычитания и тратить твое драгоценное время. Поэтому всегда лучше сразу рассчитывать такие выражения там, где это возможно. Не … WHERE a - 3 = 5, а … WHERE a = 8.Еще одна возможность оптимизировать запрос - придерживаться ortak fikir SQL'de koşul oluşturma. Başka bir deyişle, koşul şöyle görünmelidir:<колонка> <операция> <выражение>. Örneğin, "... WHERE sütun1 - 3 = -sütun2" sorgusu şu şekilde daha iyi tercüme edilir: ... WHERE sütun1 = -sütun2 + 3. Ve bu optimizasyon hileleri neredeyse her zaman ve her yerde çalışır. Koşulları Optimize Etme Şimdi koşullu SQL deyimlerini kendilerinin optimize etme zamanı. Sorguların çoğu SQL WHERE yönergesini kullanır, bu nedenle koşulları optimize ederek önemli bir sorgu performansı elde edebilirsiniz. Aynı zamanda, nedense, veritabanı uygulamalarının yalnızca küçük bir kısmı koşul optimizasyonunu kullanır. VEAçıkçası, bir dizi çoklu ifadede VE Koşullar, koşulun doğru olma olasılığına göre artan sırada düzenlenmelidir. Bu, koşullar kontrol edilirken veritabanının koşulun geri kalanını kontrol etmemesi için yapılır. Bu öneriler, koşulların baştan kontrol edilmeye başlandığı Oracle veritabanı için geçerli değildir. Buna göre, sıraları tersine çevrilmelidir - doğruluk olasılığının azalan sırasına göre. VEYA Bu operatördeki durum, AND'deki durumun tam tersidir. Koşullar, doğru olma olasılıklarının azalan sırasına göre düzenlenmelidir. Microsoft, sorgu oluştururken bu yöntemi kullanmanızı şiddetle tavsiye eder, ancak çoğu kişi bunu bilmez veya en azından buna dikkat etmez. Ancak yine, bu, koşulların doğru olma olasılığının artan sırasına göre düzenlenmesi gereken Oracle veritabanı için geçerli değildir.Optimizasyon için başka bir koşul, aynı sütunların yan yana yerleştirilmesi durumunda sorgunun çalışması olarak kabul edilebilir. Daha hızlı. Örneğin, ".. WHERE sütun1 = 1 VEYA sütun2 = 3 VEYA sütun1 = 2" sorgusu, "WHERE sütun1 = 1 VEYA sütun1 = 2 VEYA sütun2 = 3" sorgusundan daha yavaş olacaktır. Sütun 2 = 3 koşulunun doğru olma olasılığı sütun 1 = 2'den yüksek olsa bile. VE + VEHatta okulda bana dağılım kanunu anlatılmıştı. A AND (B OR C)'nin (A AND B) OR (A AND C) ile aynı olduğunu söyler. Ampirik olarak, "...WHERE sütun1 = 1 AND (sütun2 = "A" VEYA sütun2 = "B")" gibi bir sorgunun "...WHERE (sütun1 = 1 VE sütun2 = "A)'dan biraz daha hızlı olduğu bulunmuştur. ") VEYA (sütun1 = 1 VE sütun2 = "B")". Bazı veritabanlarının kendileri bu tür sorguları optimize edebilir, ancak güvenli oynamak daha iyidir. DEĞİL Bu işlem her zaman daha "okunabilir" hale getirilmelidir (elbette makul bir şekilde). Böylece, "...NEREDE DEĞİL (sütun1 > 5)" sorgusu "...WHERE sütun1 olur<= 5". Более сложные условия можно преобразовать используя правило де Моргана, которое ты тоже должен был изучить в школе. Согласно этому правилу NOT(A AND B) = (NOT A) OR (NOT B) и NOT(A OR B) = (NOT A) AND (NOT B). Например, условие "...WHERE NOT (column1 >5 OR sütun2 = 7)" daha basit bir forma dönüştürülür: ...WHERE sütun1<= 5 AND column2 <>7. IN Birçok kişi safça "... WHERE sütun1 = 5 VEYA sütun1 = 6"nın "...WHERE sütun1 IN (5, 6)" ile aynı olduğunu varsayar. Aslında öyle değil. IN işlemi, OR serisinden çok daha hızlıdır. Bu nedenle, bazı veritabanları bu iyileştirmeyi kendileri yapsa da, mümkün olduğunda OR'yi her zaman IN ile değiştirmelisiniz. Bir dizi ardışık sayı kullanıldığında IN, BETWEEN olarak değiştirilmelidir. Örneğin, "...sütun1 IN (1, 3, 4, 5) NEREDE" şu şekilde optimize edilir: …sütun1 1 VE 5 VE sütun1 ARASINDA NEREDE<>2. Ve bu sorgu gerçekten daha hızlı. LIKE Bu işlem yalnızca kesinlikle gerekli olduğunda kullanılmalıdır, çünkü tam metin dizinlerine dayalı aramaları kullanmak daha iyi ve daha hızlıdır. Ne yazık ki, arama hakkında bilgi için sizi World Wide Web'e göndermem gerekiyor. CASE Bu işlevin kendisi, bir koşulda birden fazla yavaş işlev çağrısı olduğunda bir sorguyu hızlandırmak için kullanılabilir. Örneğin, "...WHERE yavaş_fonksiyon(sütun1) = 3 VEYA yavaş_fonksiyon(sütun1) = 5" sorgusunda tekrar yavaş_fonksiyon()'u çağırmaktan kaçınmak için CASE:... WHERE 1 = CASE yavaş_fonksiyon(sütun1)WHEN 3 THEN kullanın 1WHEN 5 THEN 1END Sırala TARAFINDAN SİPARİŞ zaman aldığı bilinen sıralama için kullanılır. Veri miktarı ne kadar büyük olursa, sıralama o kadar uzun sürer, bu nedenle onu optimize etmeniz gerekir. Sorgularda sıralama hızını üç faktör etkiler:

seçilen kayıtların sayısı; ORDER BY ifadesinden sonraki sütun sayısı; ORDER BY deyiminden sonra belirtilen sütunların uzunluğu ve türü. Kaynak açısından en yoğun sıralama, dize sıralamadır. Metin alanlarının sabit bir uzunluğu olmasına rağmen, bu alanların içeriklerinin uzunluğu değişebilir (alanın boyutu dahilinde). Dolayısıyla, bir VARCHAR(100) sütununu sıralamanın bir VARCHAR(10) sütununu sıralamaktan daha yavaş olması şaşırtıcı değildir (veriler aynı olsa bile). Ve bunun nedeni, sıralama sırasında veritabanının, içeriğe bakılmaksızın maksimum alan boyutuna göre işlemleri için bellek ayırmasıdır. Bu nedenle, alanları bildirirken her zaman ihtiyacınız olan boyutu kullanmalısınız ve yedekte fazladan bayt ayırmamalısınız.Windows bilgisayarlarda INTEGER türündeki alanlar 32 bit, SMALLINT türündeki alanlar 16 bittir. SMALLINT türündeki alanların sıralamasının daha hızlı olması gerektiğini varsaymak mantıklıdır. Aslında INTEGER sıralaması SMALLINT'ten daha hızlıdır. Ayrıca INTEGER sıralaması CHAR'dan daha hızlıdır.Karakter sıralamasının da açıklaması birden fazla makale alacak kendi nüansları vardır. Hızlı ve yanlış veya yavaş olabilir, ancak daha az hatayla. Sıralama, belirli bir durum için optimize edilmiştir, bu nedenle hiç kimse evrensel önerilerde bulunamaz. Gruplandırmaİşlemi GRUPLANDIRMAYA GÖRE bir sorgu sonucunun bir alt kümesini tanımlamak ve bu alt kümeye uygulamak için kullanılır toplama işlevleri. Gruplandırma işlemini optimize etmek için en etkili yöntemlerden bazılarına bakalım.Hatırlanması gereken ilk şey, gruplandırma için mümkün olduğunca az sütun kullanmaktır. Ayrıca, ekstra koşullardan kaçınılmalıdır. Örneğin, bir SELECT ikincil_anahtar_sütun, birincil_anahtar_sütun, COUNT(*) FROM Table1 GROUP BY ikincil_key_sütun, birincil_anahtar_sütun sorgusunda, ikincil_anahtar_sütun sütunu tamamen gereksizdir. Nedeni basit: ikincil_anahtar_sütun benzersiz bir alandır, NULL değerlere sahip olmayabilir, bu da bazı verilerin basitçe kaybolabileceği anlamına gelir. Ancak GROUP BY yan tümcesinden ikincil_anahtar_sütununu kaldırırsanız, bazı veritabanları GROUP BY yan tümcesinde bildirilmemişse bu alanın belirtilemeyeceğini söyleyen bir hata verebilir. Bu sorunu çözmek için şöyle bir sorgu yazabilirsiniz: SELECT MIN(ikincil_anahtar_sütun), birincil_anahtar_sütun, COUNT(*) FROM Table1 GROUP BY birincil_anahtar_sütun. Bu sorgu, sorgu tasarımı açısından daha hızlı ve "daha doğrudur".Çoğu veritabanında WHERE ve HAVING işlemleri eşdeğer değildir ve aynı şekilde yapılmaz. Bu, aşağıdaki iki sorgunun mantıksal olarak aynı olduğu ancak farklı hızlarda çalıştığı anlamına gelir: SELECT sütun1 FROM Tablo1 WHERE sütun2 = 5 GROUP BY sütun1 HAVING sütun1 > 6SEÇ sütun1 FROM Tablo1 WHERE sütun2 = 5 VE sütun1 > 6 GROUP BY sütun1 İkinci sorgu ilkinden daha hızlıdır. HAVING, koşulun (örnekte sütun 1 > 6) performanstan ödün vermeden ifade edilmesinin zor olduğu nadir durumlarda kullanılmalıdır. Gruplama gerekiyorsa, ancak toplama işlevleri (COUNT(), MIN(), MAX, vb.) kullanılmadan. ), makul kullanım DISTINCT'dir. Bu nedenle, sütun1'i Tablo1'den GROUP BY sütun1'den SEÇ yerine, Tablo1'den SELECT DISTINCT sütun1'i kullanmak daha iyidir.MIN() ve MAX() kullanırken, bu işlevlerin ayrı ayrı daha iyi çalıştığını hesaba katarız. Bu, bunların en iyi şekilde ayrı veya BİRLEŞTİRME sorgularında kullanıldığı anlamına gelir.SUM() işlevini kullanırken, SUM(x) + SUM(y) yerine SUM(x + y) kullanarak daha iyi performans elde edebilirsiniz. Çıkarma için tersi daha iyidir: TOPLA(x) - TOPLA(y), TOPLA(x - y)'den daha hızlıdır. Tablo birleştirmeleri (JOINS) Burada optimizasyon hakkında bir şeyler söylemek zordur, bu yüzden kullanırken KATILMAK. Gerçek şu ki, bu tür işlemleri gerçekleştirme hızı büyük ölçüde tablonun organizasyonuna bağlıdır: yabancı anahtar, birincil anahtar kullanımı, iç içe birleştirmelerin sayısı vb. Bazen doğrudan programda iç içe geçmiş döngüler kullanılarak daha iyi performans elde edilebilir. Bazen JOIN'ler daha hızlı çalışır. Masaları birleştirmenin farklı yollarının nasıl kullanılacağına dair herkese uyan tek bir tavsiye yoktur. Her şey, özel duruma ve veritabanının mimarisine bağlıdır. Alt Sorgular (ALT SORGULAR) Önceden, tüm veritabanları alt sorguları desteklemekle övünemezdi, ancak şimdi neredeyse tüm modern veritabanı bunu yapabilir. Birkaç yıldır alt sorguları uygulayan MySQL bile sonunda onların desteğini aldı. Alt sorgu optimizasyonu ile ilgili temel sorun, sorgu kodunun kendisinin optimizasyonu değil, seçimdir. doğru yol talebi uygulamak için. Alt sorguların kullanıldığı görevler, iç içe döngüler veya JOIN'ler kullanılarak da çözülebilir. JOIN'i kullandığınızda, veritabanının tabloların birleştirileceği mekanizmayı seçmesine izin vermiş olursunuz. Alt sorgular kullanırsanız, iç içe döngülerin kullanımını açıkça belirtmiş olursunuz. Ne seçilir Aşağıda, bir yöntemin veya diğerinin lehine olan argümanlar bulunmaktadır. Duruma göre seçiminizi yapın. JOIN'in Avantajları:

Bir sorgu bir WHERE yan tümcesi içeriyorsa, yerleşik veritabanı optimize edici sorguyu bir bütün olarak optimize ederken, alt sorgular kullanılıyorsa sorgular ayrı ayrı optimize edilir. Bazı veritabanları, JOIN'lerle alt sorgulardan (Oracle gibi) daha verimli çalışır. JOIN'den sonra bilgiler, alt sorgular hakkında söylenemeyen genel "listede" olacaktır. SUBQUERIES'in Avantajları:

Alt sorgular daha gevşek koşullara izin verir. Alt sorgular, JOIN'lerde uygulanması çok daha zor olan GROUP BY, HAVING içerebilir. UPDATE sırasında JOIN'lerde mümkün olmayan alt sorgular kullanılabilir. Son zamanlarda, veritabanlarının kendileri tarafından alt sorguların optimizasyonu (yerleşik iyileştiricileri) önemli ölçüde iyileşti. JOIN'lerin ana avantajı, veritabanına işlemi tam olarak nasıl gerçekleştireceğinizi söylemenize gerek olmamasıdır. Ve alt sorguların ana avantajı, alt sorgu döngüsünün, performansı önemli ölçüde artırabilecek birkaç yinelemeye (tekrar) sahip olabilmesidir. Sonuç Bu makale, SQL sorgularının performansını iyileştirmenin en yaygın yollarını göstermiştir. Ancak, sorguları optimize etmek için daha pek çok püf noktası vardır. Sorgu optimizasyonu bir bilimden çok bir sanat gibidir. Her veritabanının, bu zor görevde yardımcı olabilecek kendi yerleşik iyileştiricileri vardır, ancak hiç kimse tüm işi sizin için yapmayacaktır. Eski bir fizik öğretmeninin dediği gibi: "Problemleri çözmek için onları çözmeniz gerekir." ORDER BY'ın DISTINCT veya GROUP BY gibi işlemlerle birlikte kullanılması önerilmez, çünkü bu operatörler sıralama için yan etkiler oluşturabilir. Sonuç olarak, bazı durumlarda kritik olabilen yanlış sıralanmış bir veri kümesiyle karşılaşabilirsiniz. Bu sonuç optimizasyon için geçerli değildir, ancak bunu unutmamalısınız. Ağ performansını iyileştirmeden ve sunucu donanımını artırmadan önce optimize etmeye çalışın.Herhangi bir SQL işleminin bir "fayda faktörü" vardır. Katsayı ne kadar yüksek olursa, işlem o kadar "yararlı" olur: sorgu daha hızlı yürütülür.Derleyicilerin aksine, tüm veritabanları x=1+1-1-1 ila x=0 gibi ifadeleri basitleştiremez. Sonuç olarak, değerli zamanlarını boş işlemlerle harcarlar. Bunları önceden optimize edin.TOPLA() işlevini kullanırken TOPLA(x) + TOPLA(y) yerine TOPLA(x + y) ile daha iyi performans elde edebilirsiniz.Ancak, çıkarma için TOPLA() işlevleri gerekliyse, tersini kullanın: TOPLA(x) - TOPLA(y). TOPLA(x - y) daha yavaştır.Her veritabanının kendi yerleşik iyileştiricileri vardır, ancak bunlar mükemmel olmaktan uzaktır. Bu yüzden vaktinden önce optimize edin.

38. InterBase'de veritabanlarının fiziksel organizasyonu.

InterBase veritabanı, 0'dan başlayarak sıralı olarak numaralandırılmış sayfalardan oluşur. Sıfır sayfası bir hizmet sayfasıdır ve veritabanına bağlanmak için gerekli bilgileri içerir. Sayfa boyutu - 1 (varsayılan), 2, 4 veya 8 KB. Sayfa boyutu, veritabanı oluşturulduğunda belirlenir, ancak veritabanı kaydedilirken ve geri yüklenirken değiştirilebilir. Veritabanına bir mantıksal erişim için bir sayfa sunucu tarafından okunur Okuma / yazma işlemleri için G / Ç arabelleğinin boyutu sayfa sayısına göre belirlenir (varsayılan olarak - 75). Veritabanı daha sık okunacaksa arabellek boyutunun artırılması gerekir. Daha sık yazılacaksa, arabellek boyutu azaltılabilir.InterBase, kayıtlar için çoklu sürüm modunu destekler. Bir kayıt herhangi bir işlemle değiştirildiğinde, kaydın yeni bir versiyonu oluşturulur; burada verilere ek olarak işlem numarası ve kaydın önceki versiyonuna bir işaretçi yazılır. eski versiyon değişti olarak işaretlendi; girişin bir sonraki sürümüne işaretçisi, yeni oluşturulan sürüme bir bağlantı içerir. Her başlangıç işlemi ile çalışır En son sürüm değişiklikleri onaylanan giriş. Böylece veritabanıyla paralel çalışan işlemler her zaman farklı versiyonlar için kilitleri kaldırmanıza izin veren kayıtlar istemci uygulamaları, aynı anda veritabanındaki aynı verilerle çalışır. Bir kayıt silindiğinde, diskten fiziksel olarak da kaldırılmaz, ancak bu kaydı kullanan tüm aktif işlemler tamamlanana kadar silinmiş olarak işaretlenir.InterBase, bir LDB kaydının tüm sürümlerini sayfalarından birine yerleştirir. Kayıtları sildikten sonra sayfada "delikler" oluşur. eklerken Yeni giriş maksimum "deliğin" boyutu analiz edilir ve eklenen kaydın uzunluğundan azsa sayfa sıkıştırılır ve bu sırada "delikler" birleştirilir. Boşalan alan yeni bir kayıt için yeterli değilse, yeni bir sayfadan yazılır. "Delikler" sayfa hacminin %20'sinden fazlasını kaplamıyorsa sayfa yüklenmesi normal kabul edilir Sayfa seçimi hiçbir şekilde optimize edilmemiştir. Veritabanının ayrı bir hizmet sayfasında, tüm boş sayfaların numaraları saklanır. Sayfaları tahsis ederken, bir veritabanı tablosunun kayıtlarını depolamak için ardışık sayfaları tahsis etmek için herhangi bir işlem yapılmaz, ancak boş listedeki ilk sayfa tahsis edilir. Boş sayfa yoksa veritabanının sonuna yeni bir sayfa eklenir. Yalnızca bu durumda veritabanının boyutu artar, çoklu sürüm modunu ve yetersiz sayfa tahsisini destekleyen kayıt yapısı, veritabanının yüksek oranda parçalanmasına ve sonuç olarak onunla çalışmanın yavaşlamasına yol açar. Bu nedenle, veritabanını periyodik olarak birleştirmek gerekir. Birleştirilmiş bir veritabanı, veritabanı tablo kayıtlarının birbirini izleyen sayfalarda düzenlenmesi ve "çöp" olmaması ile karakterize edilir. Çöp, hiçbir aktif işlemin çalışmadığı kayıt sürümlerini ifade eder. Çöpü kaldırmak için veritabanı şuraya kaydedilir: disk ortamı ve ardından IBConsole yardımcı programı kullanılarak yapılan yedeklemeden geri yüklendi (InterBase'in önceki sürümleri için - InterBase Sunucu Yöneticisi yardımcı programı kullanılarak). Bu işlem, tüm çöplerin kaldırılmasını garanti eder, çünkü veritabanının geri yüklenmesinin kaydedilmesi sırasında olmaması gerekir. aktif bağlantılar diğer kullanıcılardan veri tabanına aktarılır ve bu nedenle aktif işlem yapılamaz. Ek olarak, InterBase şunları sağlar: otomatik silme aktif işlemlerin arka planında çöp. Çöpün otomatik olarak kaldırıldığı aralık, varsayılan olarak 20.000 işlemdir. Bu değer, IBConsole (InterBase Sunucu Yöneticisi) yardımcı programı kullanılarak değiştirilebilir. Otomatik temizleme, yalnızca etkin işlem olmayan kayıt sürümlerini kaldırır. Sonuç olarak, tüm eski sürümler kaldırılamayabilir.

SQL Temelleri

1. Veritabanlarının oluşturulması (Veritabanı Oluştur).

Çeşitli DBMS'lerde, veritabanları oluşturma prosedürü genellikle yalnızca veritabanı yöneticisine atanır. Tek kullanıcılı sistemlerde, varsayılan veri tabanı doğrudan DBMS'nin kendisinin kurulumu ve konfigürasyonu sırasında oluşturulabilir. SQL standardı, veritabanlarının nasıl oluşturulması gerektiğini tanımlamaz, bu nedenle SQL dilinin her lehçesi genellikle farklı bir yaklaşım benimser. Yaratılış süreci Veri tabanı SQL server sisteminde iki aşamadan oluşur: Birincisi, kendi kendini organize eder. veri tabanı ve daha sonra ona ait işlem günlüğü. Bilgiler acc. *.mdf uzantılı dosyalar (için Veri tabanı) ve *.ldf. (İçin işlem günlüğü). Dosyada Veri tabanı ana nesneler hakkında bilgi kaydedilir ( masalar, indeksler, görünümler vb.) ve dosyada işlem günlüğü– işlemlerle çalışma süreci hakkında (veri bütünlüğünün kontrolü, durum Veri tabanı işlemlerden önce ve sonra). yaratılış Veri tabanı SQL server sisteminde CREATE DATABASE komutu kullanılmaktadır. (oluşturma prosedürü Veri tabanı SQL Server'da sunucu yönetici hakları gerektirir.)<определение_базы_данных>::= VERİTABANI OLUŞTUR veritabanı_adı [<определение_файла>[,...N] ] [,<определение_группы>[,...n] ] ] [ OTURUM AÇ (<определение_файла>[,...n] ) ] [ YÜK İÇİN | FOR ATTACH] ON parametresi, diskte saklanan bilgileri yerleştirmek için diskteki dosyaların bir listesini belirtir. veri tabanı. PRIMARY parametresi tanımlar birincil dosya. Eğer atlanırsa, o zaman öncelik listedeki ilk dosyadır. LOG ON seçeneği, yerleştirilecek diskteki dosyaların listesini belirtir. işlem günlüğü. için dosya adı işlem günlüğü isme göre oluşturulmuş Veri tabanı, ve sonuna _log karakterleri eklenir.

SQL'in temelleri.

3. Etki alanlarının oluşturulması (Alan Oluştur). Tablo Oluştur

TABLO OLUŞTUR masa ( [, | ...]); burada tablo, oluşturulacak tablonun adıdır, - Alan Açıklama, - kısıtlamaların ve/veya anahtarların açıklaması (köşeli parantezler isteğe bağlı, dikey çubuk | "veya" anlamına gelir). Alan açıklaması, alan adı ve alan türünden oluşur =col(veri türü | HESAPLAYAN( ) | ihtisas)[ ] Burada col, alanın adıdır; veri türü, herhangi bir geçerli SQL sunucusu türüdür, karakter türleri, ülkenin yerel ayarını tanımlayan bir karakter kümesi olan KARAKTER SETİ'ne sahip olabilir. Rus dili için karakter setini WIN1251;COMPUTED BY ( ) - sunucu düzeyinde hesaplanan bir alanın tanımı, burada - tek bir değer döndüren geçerli bir SQL ifadesi; etki alanı - veritabanında tanımlanan bir etki alanının adı (genel tür); VARSAYILAN - bir alanın varsayılan değerini tanımlayan bir yapı; NULL DEĞİL - alanın olduğunu gösteren bir yapı boş olamaz;COLLATE, seçilen karakter kümesi için sıralama düzenini belirten bir yan tümcedir.Örnek CREATE TABLE lsn_dintkey (id lsn_dintkey, name lsn_dname UNIQUE, found lsn_dfounded, PRIMARY KEY(id)) " söz konusu varlığın özniteliğini depolamak için. Örneğin bir yaş girmeniz gerekiyor ama INTEGER ve SMALLINT veri tipleri çok geniş aralıklar veriyor.Sunucu bize kendi veri tipimizi oluşturma imkanı veriyor, gerekli kısıtlamaları getiriyor. SQL'de bir veri türü etki alanı olarak adlandırılır ve onu oluşturma komutu ALAN OLUŞTUR: OLUŞTURMA ALAN tarihi OLARAK TAM SAYI VARSAYILAN 0 KONTROL ET (DEĞER >= 0 VE DEĞER)<= 120) Рассмотрим приведенную выше команду. Мы попросили сервер создать домен CREATE DOMAIN с именем dage на основе целочисленного типа AS INTEGER, причем, если пользователь не укажет возраст, то будет использовано значение по умолчанию 0 -- DEFAULT 0, и значение поля должно находиться в пределах от 0 до 120 -- CHECK(VALUE >= 0 VE DEĞER<= 120). Мы могли бы указать, что поле будет обязательно для заполнения -- NOT NULL, но в этом нет необходимости, так как NULL значение в любом случае не пройдет проверку CHECK.

SQL Temelleri

5. Batkivska ve pіdlegla DB. Uygulanabilir sağlık güvenliği

Bildirimsel bütünlük kısıtlamaları, tablo oluşturma ifadeleri düzeyinde belirlenir. Bir tabloyu tanımlarken, temel VTYS dilinde bir tanımlayıcı olan ve bu dilde nesneleri adlandırma gerekliliklerine uyması gereken tablonun adı belirtilir. Açıklama, tablo adına ek olarak, her biri bir sütun tanımlamaya veya tanımlanmakta olan tablonun bütünlüğü üzerinde bir kısıtlama tanımlamaya yarayan tablo öğelerinin bir listesini belirtir. En az bir sütun tanımı gerektirir. Yani tek sütunu olmayan bir tablo tanımlanamaz. Bir tablodaki sütun sayısıyla ilgili bir sınırlama yoktur, ancak belirli DBMS'lerin genellikle öznitelik sayısıyla ilgili sınırları vardır. Örneğin, MS SQL Server 6.5'te bir tablodaki maksimum sütun sayısı 250 idi, ancak MS SQL Server 7.0'da zaten 1024'e yükseltildi. Benzersizlik kısıtlamaları ayarlanırken, bu sütun olası bir anahtar olarak tanımlanır; bu sütundaki her giriş değerinin benzersizliğini ifade eder. Ve bu kısıtlama ayarlanmışsa, DBMS, tablonun tamamında bu sütunun yinelenen değerlerinin bulunmadığını otomatik olarak kontrol edecektir. Bütünlük kısıtlaması bölümünde o sütunda bir referans kısıtlaması belirtilirse, tablo için karşılık gelen referans kısıtlama tanımı oluşturulur: FOREIGN KEY(<имя столбца>) < спецификация ссылки>, bu, verilen sütunun değerlerinin ana tablonun ilgili sütunundan alınması gerektiği anlamına gelir. Bu durumda üst tablo, bu tabloyla bire çok (1:M) ilişkisiyle ilişkili tablodur. Bu durumda, ana tablonun her satırı, tanımlanmakta olan tablonun birkaç satırıyla ilişkilendirilebilir. SQL deyimlerinin çevirisi yorumlama modunda gerçekleştirilir, bu nedenle önce ana tablonun ve ardından onunla ilişkili tüm alt tabloların tanımlanması önemlidir. Aksi takdirde, derleyici tanımsız bir nesneye bir referans tanımlayacaktır. İlk olarak, tüm ana tablolar ve ardından alt tablolar açıklanmalıdır.

SQL Temelleri

8. İçecek. Mevduat pidzapiti

Bir alt sorgu, SQL dilinin çok güçlü bir özelliğidir. Bir sonuç kümesi oluşturma sürecinde veya veri değiştirme ifadelerinden birini (DELETE, INSERT, UPDATE) yürütme sürecinde tekrar tekrar yürütülen karmaşık sorgu hiyerarşileri oluşturmanıza olanak tanır. Geleneksel olarak, alt sorgular bazen her biri bir öncekinin daralması olan üç türe ayrılır:

bir dizi satır ve sütun döndüren bir tablo alt sorgusu; yalnızca bir satır, ancak muhtemelen birden çok sütun döndüren bir satır alt sorgusu (bu tür alt sorgular genellikle gömülü SQL'de kullanılır); bir satırdaki bir sütunun değerini döndüren skaler bir alt sorgu. Yuvalanmış bir alt sorgu, parantez içine alınmış ve bir SELECT yan tümcesinin WHERE (HAVING) yan tümcesine veya bir WHERE yan tümcesi kullanan diğer yan tümcelere yerleştirilmiş bir alt sorgudur. Yuvalanmış bir alt sorgu, WHERE (HAVING) yan tümcesinde başka bir yuvalanmış alt sorgu içerebilir ve bu böyle devam eder. İç içe alt sorgunun, ana sorgu tarafından oluşturulan tablonun satırlarını seçerken diğer tablolardan gelen verileri kullanabilecek şekilde oluşturulduğunu tahmin etmek kolaydır (örneğin, menü için yemekler seçerken, mevcudiyet hakkındaki verileri kullanın). pansiyonun kilerindeki ürünler) SELECT * from tbl1 WHERE f2=(SELECT f2 FROM tbl2 WHERE f1=1);İlgili alt sorgular Bir iç alt sorgudan SELECT ifadesinde, SELECT yan tümcesinde belirtilen dış sorgunun sütunları referans olmak Böyle bir alt sorgu, tablonun her satırı için yürütülür ve oluşturulan sonuç kümesine girişi için koşul belirlenir. Örneğin: tbl1 t1 NEREDE f2 IN'den * SEÇİN (f2 FROM tbl2 t2 NEREDE t1.f3=t2.f3); Bu durumda, tbl1 tablosunun her satırı için, f2 alanının değerinin tbl2 tablosu satırının değeriyle eşleşmesi koşulu kontrol edilecektir; burada f3 alanının değeri, harici tablonun f3 alanının değerine eşittir. (tbl1). Bu, ilişkili bir alt sorgunun en basit örneğidir.

Önsöz Veritabanı yönetim sistemleri (subds), adı verilen özel olarak düzenlenmiş dosyalarla (bilgisayar sistemlerinin harici belleğinde uzun süre saklanan veri dizileri) çalışmak üzere tasarlanmış yazılım sistemleridir.
belge
Veritabanı yönetim sistemleri (DBMS), özel olarak düzenlenmiş dosyalarla (uzun süre harici bellekte saklanan veri dizileri) çalışmak üzere tasarlanmış yazılım sistemleridir. bilgi işlem sistemleri), veritabanları olarak adlandırılır.
Http://www citforum ru/database/osbd/contents shtml Modern veritabanlarının temelleri
Makale
Veritabanı yönetimi (alt). Gayri resmi olarak, bir veritabanını iş için gerekli olan ve şu ya da bu şekilde düzenlenmiş bir veri kümesi olarak tanımlayabilirsiniz.
Ders
İlk derste, bir veritabanı (DB) ve bir veritabanı yönetim sistemi (DBMS) kavramlarının genel anlamını ele alacağız. Gayri resmi olarak, bir veritabanını iş için gerekli olan ve şu ya da bu şekilde düzenlenmiş bir veri kümesi olarak tanımlayabilirsiniz.

Klasik istemci-sunucu mimarisi

"İstemci-sunucu" terimi, işlevsel bölümlerinin "istek-yanıt" şemasına göre etkileşime girdiği yazılım kompleksinin böyle bir mimarisi anlamına gelir. Bu kompleksin etkileşimli iki parçasını düşünürsek, bunlardan biri (istemci) aktif bir işlev gerçekleştirir, yani. istekleri başlatır ve diğeri (sunucu) pasif olarak bunlara yanıt verir. Sistem geliştikçe, roller değişebilir, örneğin, bazı yazılım blokları aynı anda bir bloğa göre bir sunucunun ve diğerine göre bir istemcinin işlevlerini yerine getirecektir.

Herhangi bir bilgi sisteminin en az üç ana işlevsel parçası olması gerektiğini unutmayın - veri depolama, işleme ve kullanıcı arayüzü modülleri. Bu parçaların her biri diğer ikisinden bağımsız olarak uygulanabilir. Örneğin, verileri depolamak ve işlemek için kullanılan programları değiştirmeden, aynı verilerin tablolar, grafikler veya histogramlar şeklinde görüntülenmesi için kullanıcı arayüzünü değiştirebilirsiniz. Veri sunumu ve depolama programlarını değiştirmeden, örneğin tam metin arama algoritmasını değiştirerek işleme programlarını değiştirebilirsiniz. Son olarak, veri sunum ve işleme programlarını değiştirmeden, örneğin farklı bir dosya sistemine geçerek veri depolama yazılımını değiştirebilirsiniz.

Klasik bir istemci-sunucu mimarisinde, uygulamanın üç ana bölümünü iki fiziksel modüle dağıtmanız gerekir. Tipik olarak, veri depolama yazılımı sunucuda bulunur (örneğin, bir veritabanı sunucusu), kullanıcı arayüzü istemci tarafındadır, ancak veri işlemenin istemci ve sunucu bölümleri arasında dağıtılması gerekir. Bu, istemci-sunucu sistemlerinin gelişimini büyük ölçüde karmaşıklaştıran birkaç hoş olmayan özelliğin takip ettiği iki katmanlı mimarinin ana dezavantajıdır.

Veri işleme algoritmalarını bölerken, sistemin her iki bölümünün davranışını senkronize etmek gerekir. Tüm geliştiriciler hakkında tam bilgiye sahip olmalıdır. son değişiklikler sisteme yapılan ve bu değişiklikleri anlamak. Bu, farklı uzman gruplarının eylemlerini koordine etmek için önemli çaba harcamak gerektiğinden, istemci-sunucu sistemlerinin geliştirilmesinde, kurulumlarında ve bakımlarında büyük zorluklar yaratır. Geliştiricilerin eylemlerinde genellikle çelişkiler ortaya çıkar ve bu, sistemin gelişimini yavaşlatır ve hazır ve kanıtlanmış öğelerde değişiklik yapmaya zorlar.

Mimarinin farklı öğeleri arasındaki tutarsızlığı önlemek için, iki fiziksel kısımdan birinde veri işleme yapılmaya çalışılır - ya istemci tarafında ("kalın" istemci) veya sunucuda ("ince" istemci veya "2.5" adı verilen bir mimaride). -katmanlı istemci-sunucu"). Her yaklaşımın sakıncaları vardır. İlk durumda, ham ve dolayısıyla yedekli veriler üzerinden iletildiği için ağ gereksiz yere aşırı yüklenir. Ek olarak, hesaplama algoritmasının değiştirilmesi veya bir hatanın düzeltilmesi eş zamanlı gerektirdiğinden, sistemi sürdürmek ve değiştirmek daha zor hale gelir. tam değiştirme tüm arayüz programları, aksi takdirde hatalar veya veri tutarsızlıkları meydana gelebilir. Tüm bilgi işleme sunucuda gerçekleştirilirse (böyle bir şey mümkün olduğunda), yerleşik prosedürleri açıklama ve bunlarda hata ayıklama sorunu ortaya çıkar. Gerçek şu ki, yerleşik prosedürleri tanımlama dili genellikle bildirim niteliğindedir ve bu nedenle prensipte adım adım hata ayıklamaya izin vermez. Ayrıca sunucu üzerinde bilgi işleyen bir sistemin başka bir platforma aktarılması kesinlikle imkansızdır ki bu ciddi bir dezavantajdır.

Çoğunluk modern araçlarÇeşitli veritabanlarıyla çalışan Hızlı Uygulama Geliştirme (RAD), ilk stratejiyi uygular, yani "kalın" istemci, gömülü SQL aracılığıyla veritabanı sunucusuna bir arabirim sağlar. Yukarıda listelenen dezavantajlara ek olarak, "kalın" bir istemciye sahip bir sistemin uygulanmasının bu tür bir çeşidi, genellikle kabul edilemez bir şekilde sağlar. düşük seviye güvenlik. Örneğin, bankacılık sistemlerinde, tüm veznedarlara muhasebe sisteminin ana tablosuna yazma erişimi verilmelidir. Ayrıca, bu sistem Veritabanı sunucusuna erişmek için özel istemci yazılımı kullanıldığından, Web teknolojisine çevirmek neredeyse imkansızdır.

Dolayısıyla, yukarıdaki modeller aşağıdaki dezavantajlara sahiptir.

1. "Şişman" müşteri:
# yönetimin karmaşıklığı;
# yazılım güncellemesi daha karmaşık hale gelir, çünkü değiştirilmesi sistem genelinde aynı anda yapılmalıdır;
# erişim eylemlerle değil tablolarla kısıtlandığından, yetkilerin dağılımı daha karmaşık hale gelir;
# ham verilerin üzerinden iletilmesi nedeniyle ağ aşırı yüklenmiştir;
# Yetkiyi doğru bir şekilde tahsis etmek zor olduğu için zayıf veri koruması.

2. "Şişman" sunucu:
# PL / SQL gibi diller bu tür yazılımları geliştirmek için uygun olmadığı ve hiçbir özelliği olmadığı için uygulama daha karmaşık hale gelir iyi para hata ayıklama;
# PL/SQL gibi dillerde yazılan programların performansı diğer dillerde oluşturulan programlara göre önemli ölçüde düşüktür, bu da bizim için önemlidir. karmaşık sistemler;
# DBMS dillerinde yazılmış programlar genellikle yeterince güvenilir çalışmıyor; bunlardaki bir hata, tüm veritabanı sunucusunun başarısız olmasına neden olabilir;
# Ortaya çıkan programlar, diğer sistemlere ve platformlara tamamen taşınabilir değildir.

Bu sorunları çözmek için çok seviyeli (üç veya daha fazla seviyeli) istemci-sunucu mimarileri kullanılır.

Katmanlı istemci-sunucu mimarileri

Bu tür mimariler, bu durumda bir veya daha fazla ayrı sunucu üzerinde çalışan veri işleme modüllerini daha akıllıca dağıtır. Bunlar yazılım modülleri kullanıcı arabirimleri için bir sunucu ve veritabanı sunucuları için bir istemci görevi görür. Ek olarak, çeşitli uygulama sunucuları, sistemi belirli rolleri gerçekleştiren işlevsel bloklara daha doğru bir şekilde bölmek için birbirleriyle etkileşime girebilir. Örneğin, personel yönetimi için gerekli tüm fonksiyonları yerine getirecek bir personel yönetimi sunucusu seçebilirsiniz. Onunla ayrı bir veritabanı ilişkilendirerek, bu sunucunun tüm uygulama ayrıntılarını kullanıcılardan gizleyebilir ve yalnızca genel işlevlerine erişmelerine izin verebilirsiniz. Ayrıca böyle bir sistemin Web'e uyarlanması çok kolaydır, çünkü tüm verilere göre belirli veritabanı işlevlerine kullanıcı erişimi için html formları geliştirmek daha kolaydır.

Üç katmanlı bir mimaride, "ince" istemci, veri işleme işlevleriyle aşırı yüklenmez, ancak uygulama sunucusundan gelen bilgileri sunmak için bir sistem olarak ana rolünü yerine getirir. Böyle bir arayüz, standart Web teknolojisi araçları - tarayıcı, CGI ve Java kullanılarak uygulanabilir. Bu, istemci ile uygulama sunucusu arasında aktarılan veri miktarını azaltarak, istemci bilgisayarların telefon hatları gibi yavaş hatlar üzerinden bile bağlanmasına olanak tanır. Ek olarak, istemci tarafı o kadar basit olabilir ki çoğu durumda evrensel bir tarayıcı kullanılarak uygulanır. Ancak yine de değiştirmeniz gerekiyorsa, bu prosedür hızlı ve acısız bir şekilde gerçekleştirilebilir. Üç katmanlı istemci-sunucu mimarisi, veritabanının kendisine değil, uygulama sunucusunun belirli işlevlerine erişim hakları aldıkları için kullanıcı izinlerini daha kesin bir şekilde atamayı mümkün kılar. Bu, sistemin güvenliğini (normal mimariye kıyasla) yalnızca kasıtlı bir saldırıdan değil, aynı zamanda personelin hatalı eylemlerinden de artırır.

Örneğin, çeşitli parçaları birkaç uzak sunucuda çalışan bir sistemi düşünün. Geliştiriciden sistemin yeni bir sürümünün alındığını varsayalım, kurulumu için iki seviyeli bir mimaride aynı anda tümünü değiştirmek gerekir. sistem modülleri. Bu yapılmazsa, eski istemcilerin yeni sunucularla etkileşimi, geliştiriciler genellikle sistemin bu tür kullanımına güvenmediğinden, öngörülemeyen sonuçlara yol açabilir. Üç katmanlı bir mimaride durum basitleştirilmiştir. Gerçek şu ki, uygulama sunucusunu ve veri depolama sunucusunu değiştirerek (bu aynı anda yapmak kolaydır, çünkü her ikisi de genellikle yakındadır), mevcut hizmetler kümesini hemen değiştiririz. Böylece, sunucu ve istemci bölümleri arasındaki sürüm uyumsuzluğundan kaynaklanan bir hata olasılığı büyük ölçüde azaltılır. içinde ise Yeni sürüm Bir hizmet ortadan kalktıysa, eski sistemde ona hizmet eden arayüz öğeleri çalışmaz. Hizmetin algoritması değiştiyse, eski arayüzle bile düzgün çalışacaktır.

Çok düzeyli istemci-sunucu sistemleri oldukça kolay bir şekilde Web teknolojisine dönüştürülebilir - bunun için istemci bölümünü evrensel veya özel bir tarayıcıyla değiştirmek ve uygulama sunucusunu bir Web sunucusu ve küçük programlar sunucu prosedürlerini çağırmak. Bu programları geliştirmek için Ortak Ağ Geçidi Arayüzünü (CGI) veya daha yeni Java teknolojisini kullanabilirsiniz.

Ayrıca, üç seviyeli bir sistemde, uygulama sunucusu ile veritabanı arasındaki iletişim kanalı üzerinden birçok bilginin iletildiğini de belirtmek gerekir. Ancak, bu elemanları bağlamak için daha hızlı hatlar kullanılabileceğinden, bu hesaplamaları yavaşlatmaz. Her iki sunucu da genellikle aynı odada bulunduğundan, bu çok az çaba gerektirecektir. Böylece sistemin genel performansı artar - iki farklı sunucu artık tek görev üzerinde çalışmakta ve aralarındaki iletişim en yüksek hızlı hatlar üzerinden gerçekleştirilebilmektedir. minimum maliyet para kaynağı. Doğru, çok seviyeli sistemlerin yeni unsurları olan işlem yöneticilerini çözmek için tasarlanmış ortak hesaplamaların tutarlılığı sorunu var.

İngilizce'den çeviri: Chernobay Yu.A.

İstemci-sunucu sistemlerinin geliştirilmesi

Bir bilgisayar sisteminin mimarisi, donanımın uygulamaları çalıştırma yetenekleriyle birlikte gelişmiştir. En basiti (ve en eskisi), tüm işlemlerin ve işlevlerin sunucu (veya "ana bilgisayar") bilgisayar içinde gerçekleştirildiği "Ana Bilgisayar Mimarisi" idi. Kullanıcılar, sunucuya tuş vuruşunu yakalayarak talimatları ileten ve talimatların sonuçlarını kullanıcıya gösteren "aptal" terminaller aracılığıyla sunucuyla etkileşime girdi. Bu tür uygulamalar tipikti ve sunucu bilgisayarların nispeten büyük işlem gücüne rağmen, genellikle nispeten yavaştı ve her tuş vuruşunu sunucuya iletme ihtiyacı nedeniyle kullanımı elverişsizdi.

PC'nin tanıtılması ve yaygın olarak kullanılması, kendi işlem gücü ve grafik kullanıcı arabirimi, uygulamaların daha karmaşık hale gelmesine ve genişletilmesine izin verdi ağ sistemleri ikinci ana sistem mimarisi türü olan "Dosya Bölümleme"ye yol açtı. Bu PC mimarisinde (veya " iş istasyonu") dosyaları özel bir "dosya sunucusundan" indirir ve ardından uygulamayı (veriler dahil) yerel olarak yönetir. Bu, paylaşılan veri kullanımı, veri güncellemeleri ve aktarılacak veri miktarı az olduğunda işe yarar. dosya paylaşımının ağı daha fazla tıkadığını ve uygulamaların daha karmaşık hale geldiğini ve tüm büyük miktar veriler her iki yönde de aktarıldı.

Bir ağ üzerinden paylaşılan bir dosya aracılığıyla veri işleyen uygulamalarla ilgili sorunlar, 1980'lerin başında bir istemci-sunucu mimarisinin geliştirilmesine yol açtı. Bu yaklaşımda, dosya sunucusunun yerini, dosyaları bağlı iş istasyonlarına (istemciler) basitçe aktarmak ve depolamak yerine veri isteklerini alan ve fiilen yürüten, yalnızca istemci tarafından istenen sonucu döndüren bir veritabanı sunucusu alır. Dosyanın tamamı yerine yalnızca istemci tarafından talep edilen verileri aktaran bu mimari, ağ yükünü büyük ölçüde azaltır. Bu, birden fazla kullanıcının tek bir paylaşılan veritabanına bağlı GUI arayüzleri aracılığıyla verileri güncelleyebildiği bir sisteme izin verdi.

Tipik olarak, istemci ile sunucu arasında iletişim kurmak için Yapılandırılmış Sorgu Dili (SQL) veya Uzaktan Yordam Çağrıları (RPC'ler) kullanılır. İstemci-sunucu mimarisini düzenlemek için çeşitli temel seçenekler aşağıda açıklanmıştır.

İki katmanlı bir mimaride yük, sunucu (veritabanını barındıran) ile istemci (veritabanını barındıran) arasında dağıtılır. Kullanıcı arayüzü). Genellikle farklı yerlerde bulunurlar fiziksel makineler, ancak bu bir gereklilik değildir. Seviyelerin mantıksal olarak ayrılması şartıyla, aynı bilgisayara (örneğin, geliştirme ve test için) yerleştirilebilirler (Şekil 1).

Şekil 1: İki katmanlı mimari

Bu modelde uygulama mantığının ve veri işlemenin dağılımı sorunlu olmuştur ve olmaya devam etmektedir. İstemci "akıllıysa" ve verilerin ana işlemesini yapıyorsa, her istemci kendi yerel kopyasına ihtiyaç duyduğundan, uygulamanın dağıtımı, kurulumu ve bakımı ile ilgili sorunlar vardır. yazılım. İstemci "aptal" ise, uygulama mantığı ve işleme veritabanında uygulanmalıdır ve bu nedenle tamamen kullanılan belirli DBMS'ye bağımlı hale gelir. Her durumda, her müşteri kayıt olmalı ve aldıkları erişim haklarına bağlı olarak belirli işlevleri yerine getirmelidir. Bununla birlikte, iki katmanlı istemci-sunucu mimarisi, kullanıcı sayısı nispeten küçükken (yaklaşık 100 eşzamanlı kullanıcıya kadar) iyi bir çözümdü, ancak kullanıcılar büyüdükçe, bu mimarinin kullanımıyla ilgili bir takım kısıtlamalar ortaya çıktı.

Performans: Kullanıcı sayısı arttıkça performans düşmeye başlar. Performans düşüşü, her birinin sunucuyla kendi bağlantısı olan kullanıcı sayısıyla doğru orantılıdır; bu, sunucunun, veritabanı boştayken bile tüm bu bağlantıları ("Canlı Tut" mesajı kullanarak) canlı tutması gerektiği anlamına gelir.

Güvenlik: Her kullanıcının veri tabanına kendi bireysel erişimi ve uygulamayı çalıştırmak için verilen haklara sahip olması gerekir. Bunu yapmak için, her kullanıcı için erişim haklarını veritabanında saklamanız gerekir. Uygulamaya işlevsellik eklemeniz gerektiğinde ve kullanıcı haklarını güncellemeniz gerektiğinde.

İşlevsellik: Ne tür bir istemci kullanılırsa kullanılsın, veri işlemenin çoğu veritabanında olmalıdır, bu da tamamen üretici tarafından veritabanında sağlanan yeteneklere bağlı olduğu anlamına gelir. Farklı veritabanları farklı özellikleri desteklediğinden, farklı programlama dilleri kullandığından ve hatta tetikleyiciler gibi temel özellikleri farklı şekilde uyguladığından, bu, bir uygulamanın işlevselliğini ciddi şekilde sınırlayabilir.

Taşınabilirlik: İki katmanlı mimari, veritabanının özel uygulamasına o kadar bağımlıdır ki, mevcut uygulamalarçeşitli DBMS için ciddi bir sorun haline gelir. Bu, özellikle DBMS seçiminin satıcı tarafından belirlenmediği dikey pazarlardaki uygulamalarda belirgindir.

Ancak buna rağmen, iki katmanlı mimari, İnternet çağında yeni bir hayat buldu. Kullanıcı arayüzünün "aptal" olduğu bağlantısız bir ortamda (örneğin tarayıcı) iyi çalışabilir. Bununla birlikte, birçok yönden bu uygulama, orijinal ana bilgisayar mimarisine bir gerilemedir.

Yukarıda özetlenen iki katmanlı mimarinin sınırlamalarının üstesinden gelmek için ek bir katman eklenmiştir. Bu mimari, üç katmanlı bir mimariye sahip standart bir istemci-sunucu modelidir. İkincil katmanın (genellikle "orta" veya "kurallar" katmanı olarak anılır) amacı, uygulama yürütmeyi ve veritabanı yönetimini yönetmektir. İki katmanlı modelde olduğu gibi, katmanlar farklı bilgisayarlarda (Şekil 2) veya test modunda aynı bilgisayarda bulunabilir.

Şekil 2: Üç katmanlı mimari

Orta sıranın tanıtılmasıyla, iki katmanlı mimarinin sınırlamaları büyük ölçüde ortadan kaldırıldı ve çok daha esnek ve ölçeklenebilir bir sistem elde edildi. İstemciler artık doğrudan veri sunucusuna değil, yalnızca uygulama sunucusuna bağlandığından, veritabanı içinde uygulama mantığını uygulama ihtiyacı gibi, bağlantıları sürdürme yükü de ortadan kalkar. Veritabanı artık yalnızca veri depolama ve arama işlevlerini yerine getirebilir ve uygulamaları alma ve işleme görevi, üç katmanlı bir mimarinin orta seviyesi tarafından gerçekleştirilebilir. Bağlantı havuzu, kuyruklar ve dağıtılmış işlem işleme gibi unsurlar dahil olmak üzere işletim sistemlerinin geliştirilmesi, orta katmanın gelişimini güçlendirdi (ve basitleştirdi).

Bu modelde, uygulama sunucusunun kullanıcı arayüzünü yönetmediğini ve kullanıcının veritabanını doğrudan sorgulamadığını unutmayın. Bunun yerine, birden fazla müşterinin iş mantığını, hesaplamaları ve arama motoru veri. Ana avantaj, müşterinin daha az yazılım gerektirmesi ve artık ihtiyaç duymamasıdır. doğrudan bağlantı güvenliği artıran veritabanına. Bu nedenle, uygulama daha ölçeklenebilirdir, tek bir sunucuda destek ve kurulum maliyeti, uygulamaları doğrudan müşterinin bilgisayarında veya hatta iki katmanlı bir mimaride sürdürmekten çok daha düşüktür.

Çeşitli işlevleri yerine getirmek için tasarlanmış temel üç seviyeli modellerin birçok çeşidi vardır. Bunlar, dağıtılmış işlem işlemeyi (birden çok DBMS'nin aynı protokolde güncellendiği), mesaj tabanlı uygulamaları (uygulamaların gerçek zamanlı olarak iletişim kurmadığı durumlarda) ve platformlar arası uyumluluğu (Object Request Broker veya "ORB" uygulamaları) içerir.

Katmanlı mimari veya N katmanlı mimari

Kullanıcı sayısındaki genel bir artışın arka planına karşı İnternet uygulamalarının geliştirilmesiyle, ana üç düzey istemci-sunucu modeli ek seviyeler getirilerek genişletildi. Bu tür mimarilere "katmanlı" denir ve tipik olarak ağ sunucusunun tarayıcı istemcisi ile uygulama sunucusu arasındaki bağlantıyı yönetmekten sorumlu olduğu dört katmandan oluşur (Şekil 3).Faydası, birden çok web sunucusunun tek bir sunucuya bağlanabilmesidir. uygulama sunucusu , böylece işlemeyi arttırır Daha eşzamanlı kullanıcılar.

Şekil 3: N katmanlı mimari

Düzeyler ve Katmanlar

Bu terimler (maalesef) sıklıkla karıştırılır. Ancak aralarında büyük bir fark ve bir anlamı var. Temel fark, katmanların fiziksel düzeyde, katmanların ise mantıksal düzeyde olmasıdır. Başka bir deyişle, seviye teorik olarak ayrı bir bilgisayarda bağımsız olarak dağıtılabilir ve katman, seviye içinde mantıksal olarak ayrılabilir (Şekil 4). Yukarıda açıklanan tipik üç katmanlı model tipik olarak her üç seviyede de ayrılmış en az yedi katman içerir.

Katmanlı bir mimari hakkında unutulmaması gereken en önemli şey, her iş parçacığının istek ve yanıtlarının tüm katmanlarda aynı yönde ilerlemesi ve katmanların asla atlanamamasıdır. Böylece Şekil 4'te gösterilen modelde "E" katmanına (veri erişim katmanı) erişebilen tek katman "D" katmanıdır (kurallar katmanı). Benzer şekilde, "C" katmanı (doğrulama uygulama katmanı) yalnızca "B" katmanından (hata işleme katmanı) gelen isteklere yanıt verebilir.