İlişkisel (İngilizce ilişki - ilişki) kavramı, veritabanı sistemleri alanında tanınmış bir Amerikalı uzmanın, bir IBM çalışanı olan Dr. E. Codd'un (Codd EF, Büyük için İlişkisel Bir Veri Modeli) gelişmeleri ile ilişkilidir. Paylaşılan Veri Bankaları CACM 13:6, Haziran 1970), "ilişkisel veri modeli" terimini ilk kullanan kişi.

Uzun bir süre boyunca, ilişkisel yaklaşım, uygulanması çok büyük makine kaynakları gerektirdiğinden, pratik beklentileri olmayan uygun bir resmi veritabanı analiz aracı olarak kabul edildi. Yalnızca kişisel bilgisayarların ortaya çıkmasıyla, ilişkisel ve ilgili sistemler yayılmaya başladı ve diğer modellere çok az yer kaldı.

Bu modeller, basit bir veri yapısı, kullanıcı dostu bir tablo gösterimi ve veri işleme için ilişkisel cebir ve ilişkisel hesabın resmi aygıtını kullanma yeteneği ile karakterize edilir.

İlişkisel model, verileri iki boyutlu tablolar biçiminde düzenlemeye odaklanır. Her ilişkisel tablo iki boyutlu bir dizidir ve aşağıdaki özelliklere sahiptir:

• - tablonun her elemanı bir veri elemanıdır; yinelenen grup yok;
• - tablodaki tüm sütunlar homojendir, yani. bir sütundaki tüm öğeler aynı türe (sayısal, karakter vb.) ve uzunluğa sahiptir;
• - her sütunun benzersiz bir adı vardır;
• - tabloda aynı satır yok;
• - satır ve sütunların sırası isteğe bağlı olabilir. Bu tür bir tabloya ilişki denir.

İlişkiler kullanılarak oluşturulan bir veritabanına ilişkisel veritabanı denir.

İlişkiler, satırları demetlere veya kayıtlara karşılık gelen tablolar olarak sunulur ve sütunlar, ilişki niteliklerine, etki alanlarına, alanlara karşılık gelir.

Her değeri karşılık gelen kaydı benzersiz olarak tanımlayan bir alana basit anahtar (anahtar alan) denir. Kayıtlar, birkaç alanın değerleriyle benzersiz bir şekilde tanımlanmışsa, böyle bir veritabanı tablosunun bir bileşik anahtarı vardır.

İki ilişkisel tabloyu birbirine bağlamak için, birinci tablonun anahtarını ikinci tablonun anahtarına girmeniz gerekir (anahtarlar eşleşebilir); aksi takdirde, ilk tablonun yapısına bir yabancı anahtar eklemeniz gerekir - ikinci tablonun anahtarı.

İlişkisel bir veri modeli öneren E.F. Codd ayrıca ilişkilerle - ilişkisel cebirle - uygun çalışma için bir araç yarattı. Bu cebirin her işlemi, işlenen olarak bir veya daha fazla tablo (ilişki) kullanır ve sonuç olarak yeni bir tablo üretir, yani. tabloları "kesmenize" veya "yapıştırmanıza" olanak tanır.

İlişkisel modelleri ağdan ve hiyerarşik olanlardan temel olarak ayıran şey şu şekilde söylenebilir: hiyerarşik ve ağ veri modellerinin yapı olarak bir bağlantısı vardır ve ilişkisel olanların değer olarak bir bağlantısı vardır.

Veritabanı tasarımı geleneksel olarak çok zor bir görev olarak kabul edilmiştir. İlişkisel teknoloji bu görevi büyük ölçüde basitleştirir.

Sistemin mantıksal ve fiziksel katmanlarını ayırarak, "gerçek dünya katmanını" sistemin doğrudan destekleyebileceği bir yapıya haritalama sürecini basitleştirir. İlişkisel çerçevenin kendisi kavramsal olarak basit olduğu için, daha eski, daha karmaşık sistemlerde asla mümkün görülmeyecek olan kişisel veri tabanları gibi küçük ve/veya basit (ve dolayısıyla oluşturulması kolay) veritabanlarının uygulanmasına izin verir.

Normalleştirme teorisi ve disiplini, ilişkiler doğal olarak yapılandırılmadığında neler olduğunu göstererek yardımcı olabilir.

İlişkisel veri modeli, dağıtılmış bir mimarinin veritabanlarında kullanım için özellikle uygundur - bir bilgisayar ağının düğümlerinde depolanan herhangi bir bilgi öğesine erişmenizi sağlar. Kayıtların çoklu işlenmesi olan ilişkisel yaklaşımın üst düzey yönüne özellikle dikkat etmek gerekir. Bu, her seferinde bir kayıt işlenirken elde edilemeyen ilişkisel yaklaşımın potansiyelini önemli ölçüde artırır ve her şeyden önce optimizasyonla ilgilidir.

Bu model şunları belirlemenizi sağlar:

• veri depolama ve alma işlemleri;
• Veri bütünlüğünün sağlanmasına ilişkin kısıtlamalar.

İlişkisel türden birçok VTYS'de işin verimliliğini artırmak için katı bir ilişkisel modele karşılık gelen kısıtlamalar benimsenmiştir.

Birçok ilişkisel VTYS, veritabanı dosyalarını, kayıtları satırlar ve alanları sütunlar olarak içeren bir tablo biçiminde kullanıcıya sunar. Tablo biçiminde, bilgi çok daha kolay algılanır. Ancak, fiziksel düzeydeki bir veritabanında veriler, kural olarak, kayıt dizilerini içeren dosyalarda saklanır.

İlişkisel VTYS'nin ana avantajı, belirli ilişkilere dayalı olarak veritabanı dosyalarını bağlama yeteneğidir.

Yapısal bir bakış açısından, ilişkisel modeller hiyerarşik ve ağ modellerinden daha basit ve daha homojendir. İlişkisel modelde, her etki alanı nesnesi bir veya daha fazla ilişkiye karşılık gelir. Nesneler arasındaki ilişkiyi açıkça tanımlamak gerekirse, ilgili nesnelerin tanımlayıcılarının nitelik olarak bulunduğu bir ilişki olarak ifade edilir. İlişkisel modelde, konu alanının nesneleri ve aralarındaki bağlantılar, modelin kendisini büyük ölçüde basitleştirerek aynı bilgi yapıları ile temsil edilir.

E. Codd tarafından önerilen aşağıdaki iki koşul karşılanırsa, bir VTYS ilişkisel olarak kabul edilir:

• ilişkisel veri yapısını destekler;
• · En azından ilişkilerin seçim, izdüşüm ve bağlantı işlemlerini uygular.

Daha sonra, bir dereceye kadar bu tanımı karşılayan bir dizi ilişkisel VTYS oluşturuldu. Çoğu DBMS, ilişkisel modelin önemli uzantılarıdır, diğerleri ise birden fazla verisel modeli destekleyen karmadır.

Bugüne kadar, ilişkisel veritabanları, hem oluşturma sürecinde hem de kullanıcı düzeyinde basitlikleri ve görünürlükleri nedeniyle en yaygın olanı olmaya devam ediyor.

İlişkisel veritabanlarının temel avantajı, en popüler SQL sorgu diliyle uyumlu olmasıdır.

Bu dilde tek bir sorgu ile, birkaç tabloyu geçici bir tabloya birleştirebilir ve bu tablodan gerekli satırları ve sütunları kesebilirsiniz (seçim ve projeksiyon). İlişkisel bir veritabanının tablo yapısı kullanıcılar için sezgisel olduğundan, SQL dili basit ve öğrenmesi kolaydır. İlişkisel model, ilişkisel veritabanlarının evrimi ve uygulanmasının dayandığı sağlam bir teorik temele sahiptir. İlişkisel modelin başarısının yarattığı popülerliğin ardından SQL, ilişkisel veritabanları için ana dil haline geldi.

Ancak, dikkate alınan veritabanı modelinin eksiklikleri de tespit edildi:

• - bir tablonun tüm alanları önceden belirlenmiş türlerde sabit sayıda alan içermesi gerektiğinden, yabancı anahtarlar kullanarak öğelerin bireysel özelliklerini dikkate alan ek tablolar oluşturmak gerekir. Bu yaklaşım, veritabanında herhangi bir karmaşık ilişkinin oluşturulmasını büyük ölçüde karmaşıklaştırır;
• - bilgiyi manipüle etmek ve ilişkileri değiştirmek için yüksek emek yoğunluğu.

İLİŞKİ VERİTABANI VE ÖZELLİKLERİ. İLİŞKİ TABLOLARI ARASINDAKİ İLİŞKİ TÜRLERİ

İlişkisel veritabanı her biri belirli bir türdeki nesneler hakkında bilgi içeren, birbiriyle ilişkili bir dizi tablodur. Bir tablo satırı, bir nesne (örneğin bir ürün, bir müşteri) hakkında veri içerir ve tablo sütunları bu nesnelerin çeşitli özelliklerini - öznitelikleri (örneğin, ad, ürün kodu, müşteri bilgileri) açıklar. Kayıtlar, yani tablo satırları aynı yapıya sahiptir - nesne niteliklerini depolayan alanlardan oluşurlar. Her alan, yani sütun, nesnenin yalnızca bir özelliğini tanımlar ve kesin olarak tanımlanmış bir veri türüne sahiptir. Tüm kayıtlar aynı alanlara sahiptir, yalnızca nesnenin farklı bilgi özelliklerini görüntülerler.

İlişkisel bir veritabanında, her tablonun tablodaki her satırı benzersiz bir şekilde tanımlayan bir birincil anahtara, bir alana veya alanların birleşimine sahip olması gerekir. Anahtar birkaç alandan oluşuyorsa buna bileşik adı verilir. Anahtar benzersiz olmalı ve girişi benzersiz şekilde tanımlamalıdır. Anahtarın değeri ile tek bir giriş bulunabilir. Anahtarlar ayrıca veritabanındaki bilgileri düzenlemek için de kullanılır.

İlişkisel veritabanı tabloları, ilişkisel normalleştirmenin gereksinimlerini karşılamalıdır. İlişkilerin normalleştirilmesi, yinelemeyi ortadan kaldırmanıza izin veren, veritabanında depolanan verilerin tutarlılığını sağlayan ve veritabanının bakımı için işçilik maliyetlerini azaltan tabloların oluşumunda resmi bir kısıtlama aygıtıdır.

Şu alanları içeren Öğrenci tablosunun oluşturulmasına izin verin: grup numarası, tam ad, kayıt numarası, doğum tarihi, uzmanlık adı, fakülte adı. Böyle bir bilgi depolama organizasyonunun bir takım dezavantajları olacaktır:

• bilgilerin çoğaltılması (uzmanlık ve fakülte adı her öğrenci için tekrarlanır), bu nedenle veritabanının hacmi artacaktır;
• tablodaki bilgileri güncelleme prosedürü, her birini düzenleme ihtiyacı nedeniyle zordur. tablo girişleri.

Tablo normalizasyonu bu eksiklikleri gidermek için tasarlanmıştır. Mevcut üç normal ilişki biçimi.

Birincil normal form. Bir ilişkisel tablo, ancak ve ancak satırlarından herhangi birinde herhangi bir alanında birden fazla değer içermiyorsa ve anahtar alanlarından hiçbiri boş değilse, ilk normal forma indirgenir. Yani Öğrenci tablosundan öğrencinin adına göre bilgi almak istiyorsanız, Tam Ad alanı Soyadı, Adı, Patronimik bölümlerine ayrılmalıdır.

İkinci normal form. İlişkisel bir tablo, birinci normal formun gereksinimlerini karşılıyorsa ve birincil anahtara dahil olmayan tüm alanları, işlevsel olarak birincil anahtara tamamen bağımlıysa, ikinci normal formda tanımlanır. Tabloyu ikinci normal forma getirmek için alanların işlevsel bağımlılığını belirlemek gerekir. Alanların işlevsel bağımlılığı, bilgi nesnesi örneğinde açıklayıcı özniteliğin yalnızca bir değerinin anahtar özniteliğin belirli bir değerine karşılık geldiği bir bağımlılıktır.

Üçüncü normal form. Bir tablo, ikinci normal formun gereksinimlerini karşılıyorsa ve anahtar olmayan alanların hiçbiri diğer anahtar olmayan alanlara işlevsel olarak bağımlı değilse, üçüncü normal formdadır. Örneğin, Öğrenci tablosunda (Grup No., Tam Ad, Not Defteri No., Doğum Tarihi, Muhtar) üç alan - Not Defteri No., Grup No., Muhtar geçişli bağımlılık içindedir. Grup numarası kayıt defteri numarasına, Muhtar ise grup numarasına bağlıdır. Geçişli bağımlılığı ortadan kaldırmak için Student tablosunun bazı alanlarının başka bir Grup tablosuna aktarılması gerekir. Tablolar şu şekilde olacaktır: Öğrenci (Grup No., Tam Ad, Not Defteri No., Doğum Tarihi), Grup (Grup No., Muhtar).

İlişkisel tablolarla aşağıdaki işlemler mümkündür:

• Aynı yapıya sahip tabloları birleştirme. Sonuç ortak bir tablodur: önce birincisi, sonra ikincisi (birleştirme).
• Aynı yapıya sahip tabloların kesişimi. Sonuç - her iki tabloda da bulunan kayıtlar seçilir.
• Aynı yapıya sahip tabloların çıkarılması. Sonuç - çıkanda olmayan kayıtlar seçilir.
• Örnek (yatay alt küme). Sonuç - belirli koşulları karşılayan kayıtlar seçilir.
• Projeksiyon (dikey alt küme). Sonuç, kaynak tablolardan bazı alanları içeren bir ilişkidir.
• İki Tablonun Kartezyen Çarpımı Sonuç tablosundaki girdiler, ilk tablodaki her girdinin diğer tablodaki her girdiyle birleştirilmesiyle elde edilir.

İlişkisel tablolar birbiriyle ilişkili olabilir, böylece aynı anda birden çok tablodan veri alınabilir. Tablolar, nihai olarak veritabanının boyutunu azaltmak için birbirine bağlanır. Aynı sütunlara sahiplerse, her tablo çiftinin ilişkisi sağlanır.

Aşağıdaki bilgi bağlantısı türleri vardır:

• bire bir;
• bire çok;
• çoktan çoğa.

bire bir iletişim birinci tablonun bir özniteliğinin ikinci tablonun yalnızca bir özniteliğine karşılık geldiğini ve bunun tersini varsayar.

Bire Çok İlişki birinci tablonun bir özniteliğinin ikinci tablonun birçok özniteliğine karşılık geldiğini varsayar.

Çoktan çoğa ilişki birinci tablonun bir özniteliğinin ikinci tablonun çeşitli özniteliklerine karşılık geldiğini ve bunun tersini varsayar.

İlişkisel veritabanları

İlişkisel bir veritabanı, sütunlar ve satırlar halinde yapılandırılmış bir veya daha fazla ilişkili tablodan oluşur.

İlişkisel veritabanları aşağıdaki gösterimi kullanır:

İlişki - tablo;

Alan - birkaç nesne (sütun) için aynı türden bir kayıt kümesi;

Tuple (kayıt) - bir nesneye karşılık gelen birkaç kayıt kümesini içeren bir tablo satırı;

Nitelik - tek bir alanın satırındaki bir giriş.

Varlık - hakkında bilgi veritabanında saklanan herhangi bir ayırt edilebilir nesne.

Anahtar alanlar

Her veritabanı ilişkisi, ilişkideki her girişi benzersiz şekilde tanımlayan bir alan (veya birkaç alanın birleşimi) içermelidir. Bu tür alanlar, birkaç ilişkiden gelen verileri bağlamanıza ve sonuçta tek bir veritabanı oluşturmanıza olanak tanır. Bu alanlara anahtar alanlar denir.

Aşağıdaki anahtar türleri vardır:

Potansiyel Anahtar- nitelikleri kaydın benzersizliğini sağlayan bir alan (böyle birkaç alan olabilir).

birincil anahtar- ana anahtar olarak seçilen potansiyel anahtarlardan biri (kural olarak, minimum öznitelik uzunluğuna sahiptir).

Yabancı (ikincil) anahtar Bir ilişkide, başka bir ilişkinin birincil anahtarına bağlantı sağlayan bir veya daha fazla alan.

Anahtarı oluşturan alanların sayısına bağlı olarak:

basit anahtar- kaydı benzersiz olarak tanımlayan tek bir özellikten oluşur (öğrencinin kayıt defteri numarası).

bileşik anahtar- toplamı girişi benzersiz şekilde belirleyen iki veya daha fazla özellikten oluşur (bir kişinin pasaportunun serisi ve numarası).

Bir ilişkinin, ilişkideki her kaydı benzersiz bir şekilde tanımlayan benzersiz bir alanı varsa, birincil anahtar olarak kullanılabilir, ancak öznitelik değerleri tüm kayıtlar için farklı olmalıdır. Kişilerin adlarını veya soyadlarını birincil anahtar olarak kullanmamalısınız, çünkü bunlar tekrarlanabilir ve aynı ad ve soyadına sahip kişiler bir ilişkide görünebilir. Şu anda veritabanında kayıtlı tüm kişilerin soyadları farklı olsa bile, kaydedilen kişilerin kompozisyonundaki değişiklikler nedeniyle ilişkideki kayıtlar zaman içinde değişebileceğinden, soyadı alanı anahtar alan olarak kullanılmamalıdır. veritabanlarında.

Birincil anahtar seçerken, anahtar alanının niteliklerinin boş olamayacağını da göz önünde bulundurmalısınız. Bir alan boş değerlere izin veriyorsa, birincil anahtar olarak kullanılmamalıdır.

Ayrıca, bir birincil anahtar seçerken, değerlerinin değişmemesi gerektiği unutulmamalıdır. Eğer değişirse, bu değişiklikle ilgili bilgilerin bu alanla ilgili tüm yönleriyle güncellenmesinin sağlanması gerekir. Sabit değerli bir birincil anahtar kullanmak, bir veritabanındaki ilişkiler arasında senkronizasyonu kolaylaştırır.

Çoğu zaman, birincil anahtar olarak yapay olarak oluşturulmuş bir alan seçilir, öznitelik değerleri aslında bir anlam ifade etmez. Bu alanlar olabilir kod veya Numara, bu alanlar satırın yalnızca sayısal gösterimini içerir ve genellikle bu gösterim bilgisayar tarafından bir sayaç kullanılarak ayarlanır. Bu tür kodlar, gerçek verileri içeren alanların aksine değişikliğe tabi değildir, çünkü Soyadı, Telefon numarası, Adres vb. değişebilir ve tekrarlanabilir.

Kaydın benzersizliğinin bir alan ile sağlanamaması durumunda, iki veya daha fazla alandan oluşan bir bileşik anahtar kullanılır. Bileşik anahtarın bir örneği, seri ve pasaport numarası alanları olabilir, ayrı ayrı seri ve pasaport numarası kaydın benzersizliğini garanti edemez, çünkü aynı seriye sahip pasaportlar olduğu gibi aynı numaraya sahip pasaportlar da var, ancak seri ve iki pasaport sayısının aynı anda tesadüfi mümkün değil.

İlişkisel veritabanı - temel kavramlar

Çoğu zaman, bir veritabanından bahsederken, basitçe bir tür otomatikleştirilmiş veri depolama anlamına gelir. Bu temsil tamamen doğru değildir. Bunun neden böyle olduğu aşağıda gösterilecektir.

Gerçekten de, kelimenin dar anlamıyla bir veritabanı, iş için gerekli olan belirli bir veri kümesidir (gerçek veriler). Ancak, veriler bir soyutlamadır; hiç kimse "sadece veri" görmedi; ortaya çıkmazlar ve kendi başlarına var olmazlar. Veri, gerçek dünya nesnelerinin bir yansımasıdır. Örneğin, depoya alınan parçalar hakkında bilgi depolamak istiyorsunuz. Gerçek dünya nesnesi - ayrıntı - veritabanında nasıl görüntülenecek? Bu soruyu cevaplamak için, iş için gerekli olan parçanın hangi özelliklerinin veya yönlerinin alakalı olacağını bilmeniz gerekir. Bunlar arasında parçanın adı, ağırlığı, boyutları, rengi, üretim tarihi, yapıldığı malzeme vb. Geleneksel terminolojide, bilgileri veritabanında saklanan gerçek dünya nesnelerine varlık denir (bu kelimenin okuyucuyu korkutmamasına izin verin - bu genel olarak kabul edilen bir terimdir) ve gerçek özelliklerine nitelikler denir.

Belirli bir nesnenin her özelliği bir nitelik değeridir. Örneğin, motor parçasının ağırlık özniteliği değeri 50'dir ve bu, bu motorun 50 kilogram ağırlığında olduğu gerçeğini yansıtır.

Veritabanına yalnızca fiziksel nesnelerin yansıtıldığını varsaymak yanlış olur. Soyutlamalar, süreçler, fenomenler - yani bir kişinin faaliyetinde karşılaştığı her şey hakkında bilgi alabilir. Bu nedenle, örneğin, bir veritabanı, bir depoya parça tedariki için siparişler hakkında bilgi depolayabilir (fiziksel bir nesne değil, bir süreç olmasına rağmen). "Sipariş" varlığının nitelikleri, tedarik edilen parçanın adı, parça miktarı, tedarikçinin adı, teslimat süresi vb. olacaktır.

Gerçek dünyanın nesneleri, bilgi faaliyetlerinde dikkate alınması gereken birçok karmaşık bağımlılıkla birbirine bağlıdır. Örneğin, parçalar depoya üreticileri tarafından tedarik edilir. Bu nedenle, "üreticinin adı" özniteliği, parça öznitelikleri arasında yer almalıdır. Ancak, bu yeterli değildir, çünkü belirli bir parçanın üreticisi hakkında ek bilgilere ihtiyaç duyulabilir - adresi, telefon numarası vb. Bu, veritabanının yalnızca parçalar ve satın alma siparişleri hakkında değil, aynı zamanda üreticileri hakkında da bilgi içermesi gerektiği anlamına gelir. Ayrıca veritabanı, parçalar ve üreticiler (her parça belirli bir üretici tarafından üretilir) ve siparişler ile parçalar (her sipariş belirli bir parça için yapılır) arasındaki bağlantıları yansıtmalıdır. Veritabanında yalnızca ilgili, anlamlı ilişkilerin saklanması gerektiğini unutmayın.

Bu nedenle, kelimenin geniş anlamıyla, bir veri tabanı, gerçek dünya nesnelerinin tanımlarının ve belirli bir uygulama alanıyla ilgili olan aralarındaki ilişkilerin bir koleksiyonudur. Aşağıda, bu tanımdan yola çıkarak onu sunum sırasında inceleyeceğiz.

ilişkisel veri modeli

Böylece veritabanında nelerin saklandığı hakkında bir fikrimiz oldu. Şimdi varlıkların, niteliklerin ve ilişkilerin veri yapılarıyla nasıl eşleştiğini anlamamız gerekiyor. Bu, veri modeli tarafından belirlenir.

Geleneksel olarak, tüm VTYS'ler temel alınan veri modeline göre sınıflandırılır. Hiyerarşik, ağ ve ilişkisel veri modellerini ayırmak gelenekseldir. Bazen bunlara bir ilan listesi veri modeli eklenir. Buna göre, ilan listelerine dayalı olarak hiyerarşik, ağ, ilişkisel VTYS veya DBMS'den bahsederler.

Yaygınlık ve popülerlik açısından bugün ilişkisel VTYS rekabetin ötesindedir. Fiili endüstri standardı haline geldiler ve bu nedenle yerel kullanıcı kendi uygulamasında ilişkisel VTYS ile uğraşmak zorunda kalacak. Ayrıntılarına girmeden ilişkisel veri modeline hızlıca bir göz atalım.

Codd tarafından 1969-70 yıllarında matematiksel ilişkiler teorisi temelinde geliştirilmiştir ve en önemlileri tablo, ilişki, satır, sütun, birincil anahtar, yabancı anahtar olan bir kavramlar sistemine dayanmaktadır.

İlişkisel bir veritabanı, tüm verilerin kullanıcıya veri değerlerinin dikdörtgen tabloları şeklinde sunulduğu ve veritabanındaki tüm işlemlerin tablo manipülasyonlarına indirgendiği bir veritabanıdır. Tablo satırlardan ve sütunlardan oluşur ve veritabanında benzersiz bir adı vardır. Tablo, gerçek dünya nesnesinin (varlığının) türünü yansıtır ve her satır belirli bir nesneyi temsil eder. Böylece, Parça tablosu, depoda depolanan tüm parçalar hakkında bilgi içerir ve satırları, belirli parçalar için öznitelik değerleri kümeleridir. Tablonun her sütunu, bir nesnenin belirli bir niteliğinin bir dizi değeridir. Böylece, Malzeme sütunu "Çelik", "Kalay", "Çinko", "Nikel" vb. Miktar sütunu, negatif olmayan tamsayılar içerir. Ağırlık sütunundaki değerler, parçanın kilogram cinsinden ağırlığına eşit reel sayılardır.

Bu değerler yoktan var olmaz. Etki alanı adı verilen bir nesne özniteliği için tüm olası değerler kümesinden seçilirler. Böylece, malzeme sütunundaki değerler, plastik, ahşap, metal vb. tüm olası malzemelerin adları kümesinden seçilir. Bu nedenle, Malzeme sütununda, örneğin "su" veya "kum" gibi ilgili etki alanında olmayan bir değerin görünmesi temelde imkansızdır.

Her sütunun, genellikle tablonun en üstüne yazılan bir adı vardır ( Pirinç. 1). Bir tablo içinde benzersiz olmalıdır, ancak farklı tablolarda aynı ada sahip sütunlar olabilir. Herhangi bir tablonun en az bir sütunu olmalıdır; Sütunlar, tablo oluşturulurken adlarının göründüğü sıraya göre tabloda düzenlenir. Sütunların aksine satırların adları yoktur; tablodaki sıraları tanımlanmamıştır ve sayı mantıksal olarak sınırlandırılmamıştır.

Şekil 1. Bir veritabanının temel kavramları.

Tablodaki satırlar sıralanmadığından, konumuna göre bir satır seçmek mümkün değildir - aralarında "ilk", "ikinci", "son" yoktur. Herhangi bir tablonun bir veya daha fazla sütunu vardır; bu sütunlar, her bir satırı benzersiz olarak tanımlayan değerlerdir. Böyle bir sütuna (veya sütunların birleşimine) birincil anahtar denir. Parça tablosunda, birincil anahtar Parça Numarası sütunudur. Örneğimizde, depodaki her parçanın, Parça tablosundan gerekli bilgilerin alındığı tek bir numarası vardır. Bu nedenle, bu tabloda birincil anahtar Parça Numarası sütunudur. Bu sütundaki değerler çoğaltılamaz - Parça tablosunda Parça Numarası sütununda aynı değere sahip satırlar olmamalıdır. Bir tablo bu gereksinimi karşılıyorsa, buna ilişki denir.

Tabloların ilişkisi, ilişkisel veri modelinin temel bir unsurudur. Yabancı anahtarlar tarafından desteklenir. Bir veritabanının, bir kuruluştaki sıradan çalışanlar (Çalışan tablosu) ve yöneticiler (Yönetici tablosu) hakkındaki bilgileri depoladığı bir örnek düşünün ( Pirinç. 2). Yönetici tablosunun birincil anahtarı Sayı sütunudur (örneğin, personel numarası). Aynı soyadına sahip iki yönetici aynı kuruluşta çalışabileceğinden, Soyadı sütunu birincil anahtar işlevi göremez. Herhangi bir çalışan, veritabanına yansıtılması gereken tek bir lidere tabidir. Çalışan tablosu bir Yönetici Numarası sütunu içerir ve bu sütundaki değerler Yönetici tablosunda Sayı sütunundan seçilir (bkz. Şekil 1). Pirinç. 2). Yönetici Numarası sütunu, Çalışan tablosundaki yabancı bir anahtardır.

Şekil 2. Veritabanı tablolarının ilişkisi.

Veritabanında tablo tanımlayıcıları, sütun tanımlayıcıları vb. gibi "verilerle ilgili veriler" yoksa tablolar saklanamaz ve işlenemez. Bunlara genellikle meta veri denir. Meta veriler ayrıca tablo şeklinde sunulur ve veri sözlüğünde saklanır.

Tablolara ek olarak, ekran formları, raporlar (raporlar), görünümler (görünümler) ve hatta veritabanıyla çalışan uygulamalar gibi başka nesneler de veritabanında saklanabilir.

Bir bilgi sisteminin kullanıcıları için, veri tabanının sadece gerçek dünyanın nesnelerini yansıtması yeterli değildir. Böyle bir yansımanın açık ve tutarlı olması önemlidir. Bu durumda veritabanının bütünlük koşulunu sağladığı söylenir.

Verilerin doğruluğunu ve karşılıklı tutarlılığını garanti altına almak için veri tabanına veri bütünlüğü kısıtlamaları adı verilen bazı kısıtlamalar getirilir.

Birkaç çeşit bütünlük kısıtlaması vardır. Örneğin, bir tablo sütunundaki değerlerin yalnızca ilgili alandan seçilmesi gerekir. Uygulamada, örneğin referans bütünlüğü gibi daha karmaşık bütünlük kısıtlamaları dikkate alınır. Özü, yabancı bir anahtarın tabloda var olmayan bir satırın göstergesi olamayacağı gerçeğinde yatmaktadır. Bütünlük kısıtlamaları, aşağıda tartışılacak olan özel araçlar kullanılarak uygulanır. San.Veritabanı sunucusu .

SQL dili

Tek başına, bilgisayar biçimindeki veriler, bunlara erişmenin bir yolu yoksa, kullanıcının ilgisini çekmez. Verilere erişim, standart bir sorgu dilinde formüle edilmiş veritabanına yapılan sorgular şeklinde gerçekleştirilir. Bugün çoğu DBMS için bu dil SQL'dir.

Bir veritabanına erişimi tanımlamanın bir yolu olarak bu dilin ortaya çıkışı ve gelişimi, ilişkisel veritabanları teorisinin yaratılmasıyla ilişkilidir. SQL dilinin prototipi 1970 yılında IBM'in Santa Teresa laboratuvarında üzerinde çalışılan System/R araştırma projesinin bir parçası olarak ortaya çıktı. SQL artık ilişkisel veritabanı yönetim sistemleriyle arabirim için standarttır. Popülerliği o kadar büyüktür ki, ilişkisel olmayan DBMS geliştiricileri (örneğin, Adabas) sistemlerine bir SQL arabirimi sağlar.

SQL dilinin resmi bir standardı vardır - ANSI/ISO. Çoğu DBMS geliştiricisi bu standarda bağlı kalır, ancak çoğu zaman onu yeni veri işleme yeteneklerini uygulamak için genişletir. bölümünde açıklanacak olan yeni veri yönetimi mekanizmaları San.Veritabanı sunucusu , yalnızca genel olarak dil standardında yer almayan özel SQL ifadeleri aracılığıyla kullanılabilir.

SQL, geleneksel biçiminde bir programlama dili değildir. Üzerine programlar yazılmaz, veritabanına sorgular. Bu nedenle, SQL bildirimsel bir dildir. Bu, elde edilmesi gerekenleri formüle etmek için kullanılabileceği, ancak nasıl yapılması gerektiğini gösteremeyeceği anlamına gelir. Özellikle prosedürel programlama dillerinden (C, Pascal, Ada) farklı olarak SQL, if-then-else, for, while vb.

Dilin sözdizimini ayrıntılı olarak ele almayacağız. Sadece basit örnekleri anlamak için gerekli olduğu ölçüde değineceğiz. Onların yardımıyla en ilginç veri işleme mekanizmaları gösterilecektir.

Bir SQL sorgusu, birbiri ardına noktalı virgülle ayrılmış bir veya daha fazla ifadeden oluşur. Aşağıdaki Tablo 1, ANSI/ISO SQL standardının parçası olan en önemli operatörleri listeler.

Tablo 1. SQL dilinin temel operatörleri.

SQL sorguları, veritabanı nesnelerini benzersiz şekilde tanımlayan adlar kullanır. Özellikle, bunlar tablo adı (Ayrıntı), sütun adı (Ad) ve ayrıca veritabanındaki ek türlere ait olan diğer nesnelerin adlarıdır (örneğin, prosedür ve kuralların adları). tartışılan San.Veritabanı sunucusu . Basit adların yanı sıra karmaşık adlar da kullanılır - örneğin, nitelikli bir sütun adı, sütunun adını ve ait olduğu tablonun adını tanımlar (Detay.Ağırlık). Basit olması için, örneklerde isimler Rusça yazılacaktır, ancak pratikte bu tavsiye edilmemektedir.

Herhangi bir tablodaki her sütun, belirli veri türlerini depolar. Temel veri türleri vardır - sabit uzunluklu karakter dizileri, tam sayılar ve gerçek sayılar ve ek veri türleri - değişken uzunluklu karakter dizileri, para birimleri, tarih ve saat, mantıksal veriler (iki değer - "TRUE" ve "FALSE" ). SQL'de sayısal, dize, karakter, tarih ve zaman sabitlerini kullanabilirsiniz.

Birkaç örneğe bakalım.

"Her tür parça için stoktaki parça sayısını belirle" sorgusu aşağıdaki gibi uygulanır:

İsim, Miktar SEÇ

Detaydan;

Sorgunun sonucu, orijinal tablo Ayrıntısı'ndan alınan Ad ve Miktar olmak üzere iki sütunlu bir tablo olacaktır. Özünde, bu sorgu orijinal tablonun dikey bir izdüşümünü elde etmenizi sağlar (daha kesin olarak, tablo satırları kümesinin dikey bir alt kümesi). Ayrıntı tablosunun tüm satırlarından, iki sütundan alınan değerleri içeren satırlar oluşur - Ad ve Miktar.

SQL'de formüle edilen "hangi çelik parçalar stokta tutulur?" sorgusu şöyle görünür:

Ayrıntılardan

NEREDE Malzeme = "Çelik";

Bu sorgunun sonucu da sadece Kaynak tablodaki Malzeme sütununda "Çelik" değerine sahip satırları içeren bir tablo olacaktır. Bu sorgu, Ayrıntı tablosunun yatay bir projeksiyonunu almanızı sağlar (SELECT ifadesindeki yıldız işareti, tablodaki tüm sütunların seçildiği anlamına gelir).

"Stoktaki plastikten yapılmış ve ağırlığı beş kilogramdan az olan parçaların adını ve sayısını belirleyin" sorgusu şu şekilde yazılır:

İsim, Miktar SEÇ

Ayrıntılardan

NEREDE Malzeme = "Plastik"

Ve ağırlık< 5;

Sorgu sonucu, plastikten yapılmış ve ağırlığı 5 kg'dan az olan parçaların adını ve sayısını içeren Ad, Miktar olmak üzere iki sütunlu bir tablodur. Aslında, seçim işlemi önce yatay bir izdüşüm oluşturma işlemidir (Malzeme = "Plastik" ve Ağırlık için Parça tablosunun tüm satırlarını bulun).< 5), а затем вертикальной проекции (извлечь Название и Количество из выбранных ранее строк).

Dizinler tablolara hızlı erişim sağlayan araçlardan biridir. İndeks, belirli bir tablo satırına işaret eden bir veritabanı yapısıdır. Veritabanı dizini, bir kitaptaki dizin dizini ile aynı şekilde kullanılır. Belirli bir tablo satırının bir veya daha fazla sütunundan alınan değerleri ve o satıra yapılan bir referansı içerir. Dizindeki değerler sıralanmıştır, bu da DBMS'nin tabloyu hızlı bir şekilde aramasını sağlar.

Depo veritabanına bir sorgunun formüle edildiğini varsayalım:

SEÇ İsim Miktar, Malzeme

Ayrıntılardan

NEREDE Numara = "T145-A8";

Bu tablo için dizin yoksa, bu sorguyu yürütmek için VTYS'nin tüm Detay tablosunu taraması, sırayla satırları seçmesi ve her biri için seçim koşulunu kontrol etmesi gerekir. Büyük tablolar için böyle bir sorgunun tamamlanması çok uzun zaman alacaktır.

Daha önce Tablo Detayının Numarası sütununda bir indeks oluşturulmuşsa, tablodaki arama süresi minimuma inecektir. Dizin, Sayı sütunundaki değerleri ve Parça tablosunda bu değere sahip satırın bağlantısını içerecektir. Bir sorgu yürütülürken, DBMS önce dizinde "T145-A8" değerini bulur (ve dizin sıralı ve satırları küçük olduğundan bunu hızlı bir şekilde yapar) ve ardından aranan satırın fiziksel konumunu belirler. indekste referans olarak.

CREATE INDEX SQL deyimi ile bir dizin oluşturulur. Bu örnekte, operatör

BENZERSİZ DİZİN OLUŞTUR Parça dizini

AÇIK Detay (Sayı);

Parça tablosunun Numarası sütununda "Parça Dizini" adlı bir dizin oluşturacaktır.

Bir DBMS kullanıcısı için, ilgi çekici olan SQL dilinin bireysel ifadeleri değil, tek bir bütün olarak tasarlanmış ve onun bakış açısından anlamlı olan bazı dizileridir. Bu tür her SQL ifadesi dizisi, veritabanı üzerinde belirli bir eylemi uygular. Her biri veritabanı tablolarında bazı işlemleri gerçekleştiren birkaç adımda gerçekleştirilir. Bu nedenle, bankacılık sisteminde, belirli bir miktarın kısa vadeli bir hesaptan uzun vadeli bir hesaba aktarılması çeşitli işlemlerde gerçekleştirilir. Bunların arasında - kısa vadeli bir hesaptan tutarı çekmek, uzun vadeli bir hesaba kredi vermek.

Bu işlemin gerçekleştirilme sürecinde, örneğin ilk işlem tamamlanıp ikincisi tamamlanmadığında bir arıza meydana gelirse, para kaybedilir. Bu nedenle, veritabanındaki herhangi bir işlem tamamen yapılmalı veya hiç yapılmamalıdır. Bu eyleme işlem denir.

İşlem işleme, işlemleri geri almak ve veritabanının durumunu geri yüklemek için kullanılan günlüğe dayanır. İşlemler hakkında daha fazla ayrıntı şurada tartışılacaktır: San.Hareket işleme .

SQL dilinin tartışmasını bitirirken, bunun bir sorgu dili olduğunu bir kez daha vurguluyoruz. Üzerinde bir veritabanı ile çalışan karmaşık bir uygulama programı yazamazsınız. Bu amaçla modern DBMS'ler, hem C, Pascal, Ada gibi üçüncü nesil prosedürel dillerin (3GL) temel özelliklerine hem de SQL'i gömme yeteneğine sahip olan dördüncü nesil dili (Forth Generation Language - 4GL) kullanır. program metnindeki ifadelerin yanı sıra kullanıcı arayüzü kontrolleri (menüler, formlar, kullanıcı girişi vb.). Bugün 4GL, veritabanı uygulama geliştirme araçları için fiili standartlardan biridir.

• Tercüme

Çevirmenin notu: makale oldukça eski (2 yıl önce yayınlanmış) olmasına ve büyük bir isme sahip olmasına rağmen, yine de ilişkisel veritabanları ile NoSQL veritabanları arasındaki farklar, avantajları ve dezavantajları hakkında iyi bir fikir verir ve ayrıca kısa bir genel bakış sağlar. ilişkisel olmayan depolama.

Son zamanlarda, birçok ilişkisel olmayan veritabanları ortaya çıktı. Bu, neredeyse sınırsız isteğe bağlı ölçeklenebilirlik istiyorsanız, ilişkisel olmayan bir DB'ye ihtiyacınız olduğunu gösterir.

Bu doğruysa, bu güçlü ilişkisel veritabanlarının savunmasız hale geldiği anlamına mı geliyor? Bu, ilişkisel veritabanlarının günlerinin geçtiği ve yakında biteceği anlamına mı geliyor? Bu makalede, çeşitli durumlarda ilişkisel olmayan veritabanlarının popüler eğilimine bir göz atacağız ve bunun ilişkisel veritabanlarının geleceğini etkileyip etkilemediğini göreceğiz.

İlişkisel veritabanları yaklaşık 30 yıldır var. Bu süre zarfında, ilişkisel depolamaya son vermesi beklenen birkaç devrim patlak verdi. Tabii ki, bu devrimlerin hiçbiri gerçekleşmedi ve hiçbiri ilişkisel veritabanlarının konumunu bir zerre kadar sarsmadı.

Temel bilgilerle başlayalım

İlişkisel bir veritabanı, bir dizi tablodur (varlıklar). Tablolar sütunlardan ve satırlardan (tupler) oluşur. Kısıtlamalar tablolar içinde tanımlanabilir, tablolar arasında ilişkiler mevcuttur. SQL ile, bir veya daha fazla tablodan alınan veri kümelerini döndüren sorgular çalıştırabilirsiniz. Tek bir sorgu içinde, veriler birkaç tablodan birleştirilerek elde edilir (JOIN), çoğu zaman birleştirmek için tablolar arasındaki ilişkileri tanımlayan aynı sütunlar kullanılır. Normalleştirme, verilerde tutarlılığı ve fazlalık olmamasını sağlamak için bir veri modeli yapılandırma sürecidir.

İlişkisel veritabanlarına, ilişkisel veri tabanı yönetim sistemleri (RDBMS) aracılığıyla erişilir. Kullandığımız hemen hemen tüm veritabanı sistemleri Oracle, SQL Server, MySQL, Sybase, DB2, TeraData ve benzeri gibi ilişkiseldir.

Bu baskınlığın nedenleri açık değildir. İlişkisel veritabanlarının varlığı boyunca, veri yönetiminde basitlik, kararlılık, esneklik, performans, ölçeklenebilirlik ve birlikte çalışabilirliğin en iyi karışımını sürekli olarak sundular.

Ancak, tüm bu özellikleri sağlamak için ilişkisel mağazalar dahili olarak inanılmaz derecede karmaşıktır. Örneğin, basit bir SELECT sorgusu, optimize edicinin sorgu zamanında değerlendirdiği yüzlerce potansiyel yürütme yoluna sahip olabilir. Tüm bunlar kullanıcılardan gizlenir, ancak dahili olarak RDBMS, sorguya en uygun maliyet tahmini algoritmaları gibi şeylere dayalı bir yürütme planı oluşturur.

İlişkisel veritabanlarının sorunları

İlişkisel mağazalar basitlik, dayanıklılık, esneklik, performans, ölçeklenebilirlik ve birlikte çalışabilirliğin en iyi karışımını sağlarken, bu alanların herhangi birinde tek bir özelliğe odaklanan benzer sistemlerden mutlaka daha iyi performans göstermezler. Bu büyük bir sorun değildi, çünkü ilişkisel VTYS'nin genel hakimiyeti herhangi bir eksiklikten daha ağır basıyordu. Ancak, geleneksel RDB'ler ihtiyaçları karşılamıyorsa, her zaman alternatifler vardı.

Bugün durum biraz farklı. Uygulamaların çeşitliliği artıyor ve bununla birlikte bu özelliklerin önemi de artıyor. Ve veritabanlarının sayısı arttıkça, bir özellik diğerlerini gölgede bırakmaya başlar. Bu ölçeklenebilirliktir. Web hizmetleri gibi giderek daha fazla uygulama ağır yük altında çalıştığından, ölçeklenebilirlik gereksinimleri çok hızlı bir şekilde değişip büyüyebilir. Kendi sunucunuzda barındırılan ilişkisel bir veritabanınız varsa, ilk sorunu çözmek çok zor olabilir. Sunucudaki yükün bir gecede üçe katlandığını varsayalım. Donanımı ne kadar hızlı yükseltebilirsin? İkinci problemin çözümü de ilişkisel veritabanlarının kullanılması durumunda zorluklara neden olmaktadır.

İlişkisel veritabanları, yalnızca tek bir sunucuda bulunuyorlarsa iyi ölçeklenir. Bu sunucunun kaynakları tükendiğinde, daha fazla makine eklemeniz ve yükü aralarında dağıtmanız gerekecektir. Ve burada ilişkisel veritabanlarının karmaşıklığı, ölçeklenebilirliğe karşı oynamaya başlar. Sunucu sayısını birkaç değil, yüz veya bine çıkarmaya çalışırsanız, karmaşıklık bir büyüklük sırasına göre artar ve ilişkisel veritabanlarını bu kadar çekici kılan özellikler, onları bir platform olarak kullanma şansını hızla azaltır. büyük dağıtılmış sistemler için sıfıra.

Bulut hizmeti satıcıları, rekabetçi kalabilmek için bu sınırlamayla bir şekilde uğraşmak zorundadır, çünkü ölçeklenebilir veri depolaması olmayan bir bulut platformu nedir? Bu nedenle, kullanıcılara ölçeklenebilir depolama alanı sağlamak istiyorlarsa satıcıların yalnızca bir seçeneği vardır. İlişkisel veritabanlarında bulunan diğer özelliklerin pahasına da olsa, ölçekleme yeteneği daha yüksek olan diğer veritabanları türlerini kullanmanız gerekir.

Bu avantajlar ve bunlara yönelik mevcut talep, yeni bir veritabanı yönetim sistemleri dalgasına yol açmıştır.

Yeni dalga

Bu tür bir veritabanına genellikle anahtar-değer deposu denir. Aslında, resmi bir ad yoktur, bu yüzden onu belge odaklı, nitelik odaklı, dağıtılmış veritabanları (ilişkisel de olabilseler de), parçalı sıralanmış diziler, dağıtılmış karma tablolar ve depolar bağlamında görebilirsiniz. değer türü. Bu adların her biri sistemin belirli özelliklerine atıfta bulunsa da, bunların tümü anahtar/değer deposu olarak adlandıracağımız şeyin varyasyonlarıdır.

Adını nasıl koyarsanız koyun, bu "yeni" veritabanı türü o kadar da yeni değildir ve her zaman temel olarak ilişkisel veritabanlarının kullanımının uygun olmayacağı uygulamalar için kullanılmıştır. Ancak, web ve bulutun ölçeklenebilirliğine ihtiyaç duyulmadan bu sistemlere talep düşük kaldı. Şimdi görev, belirli bir sistem için hangi depolama türünün daha uygun olduğunu belirlemektir.
İlişkisel veritabanları ve anahtar/değer depoları temelde farklıdır ve farklı sorunları çözmek için tasarlanmıştır. Özellikleri karşılaştırmak, yalnızca aralarındaki farkı anlamanıza olanak tanır, ancak bununla başlayalım:

Depolama özellikleri

İlişkisel veritabanı	Anahtar/değer depolama
Bir veritabanı tablolardan oluşur, tablolar sütunlar ve satırlar içerir ve satırlar sütun değerlerinden oluşur. Bir tablonun tüm satırları aynı yapıya sahiptir.	Etki alanları için tablolarla bir analoji çizebilirsiniz, ancak tabloların aksine etki alanları bir veri yapısı tanımlamaz. Alan adı, içine istediğiniz her şeyi koyabileceğiniz bir kutudur. Aynı etki alanındaki kayıtlar farklı bir yapıya sahip olabilir.
Veri modeli 1 önceden tanımlanmıştır. Güçlü bir şekilde yazılmıştır, veri bütünlüğünü sağlamak için kısıtlamalar ve ilişkiler içerir.	Kayıtlar, her kaydın kendisiyle ilişkilendirilmiş dinamik bir nitelikler kümesine sahip olduğu bir anahtarla tanımlanır.
Veri modeli, uygulamanın işlevselliğine değil, içerilen verilerin doğal temsiline dayanır.	Bazı uygulamalarda, nitelikler yalnızca dizeler olabilir. Diğer uygulamalarda öznitelikler, programlamada kullanılan türleri yansıtan basit veri türlerine sahiptir: tamsayılar, dizi dizileri ve listeler.
Veri tekrarını önlemek için veri modeli normalleştirilmiştir. Normalleştirme, tablolar arasında ilişkiler oluşturur. İlişkiler, farklı tablolardan gelen verileri birbirine bağlar.	Alanlar arasında ve tek bir alan içinde ilişkiler açıkça tanımlanmamıştır.

Katılım yok

Anahtar-değer depoları kayıt odaklıdır. Bu, belirli bir girişle ilgili tüm bilgilerin onunla birlikte saklandığı anlamına gelir. Bir etki alanı (bir tablo olarak düşünebilirsiniz) sayısız farklı girdi içerebilir. Örneğin, bir alan, müşteriler ve siparişler hakkında bilgiler içerebilir. Bu, verilerin farklı etki alanlarında çoğaltılma eğiliminde olduğu anlamına gelir. Disk alanı ucuz olduğu için bu kabul edilebilir bir yaklaşımdır. Ana şey, ilgili tüm verilerin tek bir yerde depolanmasına izin vermesidir, bu da ölçeklenebilirliği artırır, çünkü farklı tablolardan verileri birleştirme ihtiyacı ortadan kalkar. İlişkisel bir veritabanı kullanırken, gerekli bilgileri tek bir yerde gruplamak için birleşimlerin kullanılması gerekli olacaktır.

Anahtar/değer çiftlerini depolamak için bir ilişkiye duyulan ihtiyaç önemli ölçüde azalırken, ilişkilere hala ihtiyaç duyulmaktadır. Bu tür ilişkiler genellikle birincil varlıklar arasında bulunur. Örneğin, bir sipariş sistemi müşteri, ürün ve sipariş verilerini içeren kayıtlara sahip olacaktır. Bu verilerin bir alanda mı yoksa birkaç alanda mı olduğu önemli değildir. Sonuç olarak, bir müşteri bir sipariş verdiğinde, muhtemelen müşteri ve sipariş bilgilerini aynı kayıtta tutmak istemezsiniz.
Bunun yerine sipariş kaydı, ilgili müşteri ve ürün kayıtlarına işaret eden anahtarları içermelidir. Herhangi bir bilgi kayıtlarda saklanabileceğinden ve ilişkiler veri modelinin kendisinde tanımlanmadığından, veritabanı yönetim sistemi ilişkilerin bütünlüğünü kontrol edemeyecektir. Bu, müşterileri ve sipariş ettikleri ürünleri silebileceğiniz anlamına gelir. Veri bütünlüğünün sağlanması tamamen uygulamanın sorumluluğundadır.

Veri erişimi

İlişkisel veritabanı	Anahtar/değer depolama
Veriler, Structured Query Language (SQL) kullanılarak oluşturulur, güncellenir, silinir ve sorgulanır.	API yöntemi çağrıları kullanılarak veriler oluşturulur, güncellenir, silinir ve sorgulanır.
SQL sorguları, birleştirmeleri kullanarak tek bir tablodan veya birden çok tablodan veri alabilir.	Bazı uygulamalar, filtre koşullarını belirtmek için SQL benzeri sözdizimi sağlar.
SQL sorguları, toplamalar ve karmaşık filtreler içerebilir.	Genellikle yalnızca temel karşılaştırma operatörlerini kullanabilirsiniz (=, !=,<, >, <= и =>).
İlişkisel bir veritabanı genellikle tetikleyiciler, saklı yordamlar ve işlevler gibi yerleşik mantık içerir.	Tüm iş mantığı ve veri bütünlüğü mantığı uygulama kodunda yer almaktadır.

Uygulamalarla etkileşim

Anahtar Değer Mağazaları: Avantajlar

Bu tür sistemlerin ilişkisel mağazalara göre iki belirgin avantajı vardır.

Bulut hizmetleri için uygun

Anahtar/değer depolarının ilk avantajı, daha basit olmaları ve dolayısıyla ilişkisel veritabanlarından daha ölçeklenebilir olmalarıdır. Kendi sisteminizi birlikte barındırıyorsanız ve veri deponuzun arkasına artan yükün üstesinden gelmesi gerekecek bir düzine veya yüz sunucu yerleştirmeyi planlıyorsanız, seçiminiz anahtar/değer depolarıdır.

Bu tür depoların kolayca ve dinamik olarak genişletilebilmesi nedeniyle, çok kiracılı bir web depolama platformu sağlayan satıcılar için de faydalıdır. Böyle bir veritabanı, ölçeklenebilirlik için büyük potansiyele sahip nispeten ucuz bir depolama ortamıdır. Kullanıcılar genellikle yalnızca kullandıkları kadar öder, ancak ihtiyaçları artabilir. Satıcı, yüke bağlı olarak platformun boyutunu dinamik olarak ve neredeyse hiçbir kısıtlama olmadan artırabilecektir.

Kodla daha doğal entegrasyon

İlişkisel veri modeli ve kod nesnesi modeli genellikle farklı şekilde yapılandırılır ve bu da bazı uyumsuzluklara yol açar. Geliştiriciler bu sorunu, ilişkisel modeli nesne modeline eşleyen kod yazarak çözerler. Bu işlemin net ve hızlı bir şekilde elde edilebilir bir değeri yoktur ve uygulamanın kendisini geliştirmek için harcanabilecek oldukça fazla zaman alabilir. Bu arada, birçok anahtar/değer deposu, verileri nesnelerle daha doğal bir şekilde eşleyen bir yapıda depolar. Bu, geliştirme süresini önemli ölçüde azaltabilir.

"İlişkisel veritabanları hantallaşabilir" (bu arada bunun ne anlama geldiği hakkında hiçbir fikrim yok) gibi anahtar/değer depolarını kullanmaya yönelik diğer argümanlar daha az ikna edicidir. Ancak bu tür kasaların destekçisi olmadan önce lütfen bir sonraki bölümü okuyun.

Anahtar/Değer Depoları: Dezavantajlar

İlişkisel veritabanlarındaki kısıtlamalar, en düşük seviyede veri bütünlüğünü garanti eder. Kısıtlamaları karşılamayan veriler fiziksel olarak veritabanına giremez. Anahtar/değer depolarında böyle bir kısıtlama yoktur, bu nedenle veri bütünlüğünün kontrolü tamamen uygulamalara aittir. Ancak, her kodun hataları vardır. İyi tasarlanmış bir ilişkisel veritabanındaki hatalar genellikle veri bütünlüğü sorunlarına yol açmazken, anahtar/değer depolarındaki hatalar genellikle yapar.

İlişkisel veritabanlarının bir başka avantajı da sizi veri modeli geliştirme sürecine zorlamalarıdır. Modeli iyi tasarladıysanız, veritabanı, depolanan verilerin yapısını tam olarak yansıtan, ancak uygulamanın yapısıyla çelişen mantıksal bir yapı içerecektir. Böylece veriler uygulamadan bağımsız hale gelir. Bu, başka bir uygulamanın aynı verileri kullanabileceği ve temel modelde herhangi bir değişiklik yapılmadan uygulama mantığının değiştirilebileceği anlamına gelir. Aynı şeyi anahtar-değer depolama ile yapmak için, ilişkisel model tasarım sürecini, verilerin doğal yapısına dayalı genel sınıflar oluşturan sınıf tasarımıyla değiştirmeyi düşünün.

Ve uyumluluğu unutma. İlişkisel veritabanlarından farklı olarak, bulut tabanlı depolamanın çok daha az ortak standardı vardır. Kavramsal olarak aynı olmalarına rağmen hepsinin farklı API'leri, sorgu arayüzleri ve kendi özellikleri vardır. Bu nedenle satıcınıza güvenseniz iyi olur, çünkü bir şey olursa başka bir servis sağlayıcıya kolayca geçemezsiniz. Ve neredeyse tüm modern anahtar/değer depolarının beta 2'de olduğu gerçeği göz önüne alındığında, güven, ilişkisel veritabanları durumunda olduğundan daha da riskli hale gelir.

Sınırlı veri analizi

Genellikle, tüm bulut depoları, çok sayıda kullanıcı ve uygulamanın aynı sistemi kullandığı anlamına gelen çoklu kiracılık türü üzerine kuruludur. Genel sistemin "kaçırılmasını" önlemek için, satıcılar genellikle isteklerin yürütülmesini bir şekilde sınırlar. Örneğin, SimpleDB'de bir sorgu 5 saniyeden uzun süre çalıştırılamaz. Google AppEngine Datastore'da bir sorguda 1000'den fazla kayıt alamazsınız 3 .

Bu kısıtlamalar basit mantık (az sayıda kaydın oluşturulması, güncellenmesi, silinmesi ve geri alınması) için korkunç değildir. Peki ya uygulamanız popüler hale gelirse? Çok sayıda yeni kullanıcınız ve çok sayıda yeni veriniz var ve şimdi yeni kullanıcı deneyimleri yapmak veya verilerden bir şekilde yararlanmak istiyorsunuz. Burada, veri analizi için basit sorguların bile yürütülmesinden ciddi şekilde kopabilirsiniz. Uygulama kullanım modellerini izleme veya kullanıcı geçmişine dayalı bir öneri sistemi gibi özelliklerin uygulanması en iyi ihtimalle zor olabilir. Ve en kötüsü - basitçe imkansız.

Bu durumda, analitiklerin, anahtar/değer depolamanızdan verilerle doldurulacak ayrı bir veritabanı oluşturması daha iyidir. Bunun nasıl yapılabileceğini önceden düşünün. Sunucuyu bulutta mı yoksa kendi başınıza mı barındıracaksınız? ISP'niz ile aranızda sinyal gecikmelerinden kaynaklanan sorunlar olacak mı? Depolama alanınız bu veri aktarımını destekliyor mu? 100 milyon kaydınız varsa ve aynı anda 1000 kayıt alabiliyorsanız, tüm verilerin aktarılması ne kadar sürer?

Ancak, ölçeklenebilirliğe öncelik vermeyin. Kullanıcılarınız başka bir hizmetin hizmetlerini kullanmaya karar verirse işe yaramaz çünkü bu hizmet daha fazla seçenek ve ayar sağlar.

Bulut depolama

Birçok web hizmeti sağlayıcısı, çok kiracılı anahtar/değer depoları sunar. Çoğu, yukarıda sıralanan kriterleri karşılamaktadır, ancak her birinin kendine özgü özellikleri vardır ve yukarıda açıklanan standartlardan farklıdır. SimpleDB, Google AppEngine Datastore ve SQL Data Services gibi belirli depolama örneklerine bir göz atalım.

Amazon: SimpleDB

SimpleDB, Amazon WebServices'in bir parçası olan öznitelik odaklı bir anahtar/değer deposudur. SimpleDB beta aşamasındadır; kullanıcılar, ihtiyaçları belirli bir limiti aşmadığı sürece ücretsiz olarak kullanabilirler.

SimpleDB'nin çeşitli sınırlamaları vardır. İlk olarak, sorgu yürütme süresi 5 saniye ile sınırlıdır. İkincisi, dizelerden başka veri türü yoktur. Her şey bir dize olarak saklanır, alınır ve karşılaştırılır, bu nedenle tarihleri ​​​​karşılaştırmak için onları ISO8601 formatına dönüştürmeniz gerekir. Üçüncüsü, herhangi bir dizenin maksimum boyutu 1024 bayttır ve bu, bir nitelik olarak saklayabileceğiniz metnin boyutunu (bir ürün açıklaması gibi) sınırlar. Ancak, veri yapısı esnek olduğundan, ProductDescription1, ProductDescription2 ve benzeri öznitelikleri ekleyerek bu sınırlamayı çözebilirsiniz. Ancak öznitelik sayısı da sınırlıdır - maksimum 256 öznitelik. SimpleDB beta sürümündeyken, etki alanı boyutu 10 gigabayt ile sınırlıdır ve tüm veritabanı 1 terabaytı aşamaz.

SimpleDB'nin temel özelliklerinden biri, bir modelin kullanılmasıdır (nihai tutarlılık modeli). Bu model çoklu iş parçacığı için uygundur, ancak bir kayıttaki bir özniteliğin değerini değiştirdikten sonra sonraki okuma işlemlerinin bu değişiklikleri göremeyebileceğini unutmayın. Böyle bir olay gelişme olasılığı oldukça düşüktür, ancak unutulmamalıdır. Satış anında verileriniz tutarsız olduğu için son bileti beş alıcıya satmak istemezsiniz.

Google App Engine Veri Deposu

Google'ın AppEngine Datastore'u, Google'ın dahili yapılandırılmış veri depolama sistemi olan BigTable'ın üzerine inşa edilmiştir.AppEngine Datastore, BigTable'a doğrudan erişim sağlamaz, ancak BigTable ile etkileşim için basitleştirilmiş bir arayüz olarak görülebilir.

AppEngine Datastore, SimpleDB'den daha fazla veri türünü tek bir giriş içinde destekler. Örneğin, bir girdi içinde koleksiyonlar içerebilen listeler.

Google AppEngine ile geliştirme yaparken büyük olasılıkla bu veri deposunu kullanacaksınız. Ancak SimpleDB'den farklı olarak AppEngine Datastore'u (veya BigTable'ı) Google Web Hizmetleri dışında kullanamazsınız.

Microsoft: SQL Veri Hizmetleri

SQL Veri Hizmetleri, Microsoft Azure platformunun bir parçasıdır. SQL Data Services, beta sürümünde ücretsizdir ve veritabanı boyutu sınırlarına sahiptir. SQL Veri Hizmetleri ayrı bir uygulamadır - veri depolayan birçok SQL sunucusunun üzerine eklenen bir eklentidir. Bu mağazalar ilişkisel olabilir, ancak sizin için SDS, tıpkı yukarıda açıklanan ürünler gibi bir anahtar/değer deposudur.

Bulut dışı depolama

Bulut dışında kendi başınıza kurarak kullanabileceğiniz bir dizi depolama alanı da vardır. Bu projelerin neredeyse tamamı genç, alfa veya beta ve açık kaynaklıdır. Açık kaynak ile, kapalı kaynak ürünlere kıyasla olası sorunların ve sınırlamaların daha fazla farkında olabilirsiniz.

KanepeDB

CouchDB ücretsiz, açık kaynaklı, belge odaklı bir veritabanıdır. Veri depolama formatı olarak JSON kullanılır. CouchDB, belge odaklı ve ilişkisel veritabanları arasındaki boşluğu "görünümler" ile kapatmayı amaçlar. Bu görünümler, belgelerdeki verileri tablo benzeri bir biçimde içerir ve dizinler oluşturmanıza ve sorguları çalıştırmanıza olanak tanır.

Şu anda, CouchDB gerçekten dağıtılmış bir veritabanı değildir. Sunucular arasında verileri senkronize etmenize olanak tanıyan çoğaltma özelliklerine sahiptir, ancak bu, yüksek düzeyde ölçeklenebilir bir ortam oluşturmak için gereken dağıtım türü değildir. Ancak, CouchDB geliştiricileri bunun üzerinde çalışıyor.

Voldemort Projesi

Voldemort projesi, çok sayıda sunucu arasında yatay olarak ölçeklenmek üzere tasarlanmış dağıtılmış bir anahtar-değer veritabanıdır. LinkedIn'in geliştirilmesi sırasında doğdu ve yüksek ölçeklenebilirlik gereksinimleri olan çeşitli sistemler için kullanıldı. Voldemort projesi de nihai tutarlılık modelini kullanır.

Moğol

Mongo, 10gen'de Geir Magnusson ve Dwight Merriman (DoubleClick'ten tanıyor olabilirsiniz) tarafından geliştirilen bir veritabanıdır. CouchDB gibi, Mongo da verileri JSON biçiminde depolayan belge tabanlı bir veritabanıdır. Ancak Mongo, saf bir anahtar/değer deposundan çok bir nesne tabanıdır.

çiseleyen yağmur

Drizzle, anahtar-değer mağazalarının üstesinden gelmek üzere tasarlandığı sorunları çözmek için çok farklı bir yaklaşım benimsiyor. Drizzle, MySQL 6.0'ın dallarından biri olarak başladı. Daha sonra geliştiriciler, daha basit ve daha hızlı bir DBMS oluşturmak için bir dizi özelliği (görünümler, tetikleyiciler, derlenmiş ifadeler, saklı yordamlar, sorgu önbelleği, ACL'ler ve bazı veri türleri dahil) kaldırdı. Ancak, Drizzle yine de ilişkisel verileri depolamak için kullanılabilir. Geliştiricilerin amacı, 16 veya daha fazla çekirdekli sistemlerde çalışan web ve bulut uygulamaları için tasarlanmış yarı ilişkisel bir platform oluşturmaktır.

Çözüm

Sonuç olarak, uygulamanız için ilişkisel olmayan bir anahtar/değer deposu seçmeniz için dört neden vardır:

1. Verileriniz ağırlıklı olarak belge odaklıdır ve ilişkisel bir modelden ziyade bir anahtar-değer veri modeline daha uygundur.
2. Etki alanı modeliniz güçlü bir şekilde nesne yönelimlidir, bu nedenle bir anahtar/değer deposu kullanmak, veri dönüşümü için ek kod miktarını azaltacaktır.
3. Veri depolama ucuzdur ve satıcınızın web hizmetleriyle kolayca entegre edilebilir.
4. Ana sorununuz, isteğe bağlı yüksek ölçeklenebilirliktir.

Bununla birlikte, kararınızı verirken, belirli veritabanlarının sınırlamalarının ve ilişkisel olmayan veritabanlarını kullanma yolunda ilerlemeniz durumunda karşılaşacağınız risklerin farkında olun.

Diğer tüm gereksinimler için eski güzel ilişkisel VTYS'yi seçmek daha iyidir. Yani mahkumlar mı? Tabii ki değil. En azından şimdilik.

1 - Bence "veri yapısı" terimi burada daha uygundur, ancak orijinal veri modelini bırakmıştır.
2 - büyük olasılıkla, yazar, yetenekleri açısından, ilişkisel olmayan veritabanlarının ilişkisel olanlardan daha düşük olduğu anlamına geliyordu.
3 - belki de veriler zaten güncel değil, makale Şubat 2009 tarihli.

Voldemort

çiseleyen yağmur

Etiket ekle