DBMS işlevleri.

DBMS işlevleri yüksek ve düşük seviyededir.

Üst düzey işlevler:

1. Veri tanımı - bu işlevi kullanarak, veritabanında hangi bilgilerin depolanacağı belirlenir (tür, veri özellikleri ve birbirleriyle nasıl ilişkilendirilecekleri).

2. Veri işleme. Bilgi farklı şekillerde işlenebilir: seçim, filtreleme, sıralama, bir bilginin diğeriyle birleştirilmesi, toplamların hesaplanması.

3. Veri yönetimi. Bu işlev, verileri kimlerin görüntüleyebileceğini, düzeltebileceğini veya yeni bilgiler ekleyebileceğini ve ayrıca paylaşılan erişim için kuralları tanımlayabileceğini belirtir.

Düşük seviyeli fonksiyonlar:

1. Harici bellekte veri yönetimi;

2. RAM tampon yönetimi;

3. İşlem yönetimi;

4. Veritabanına bir değişiklik günlüğünün tanıtılması;

5. Veritabanının bütünlüğünü ve güvenliğini sağlamak.

İşleme göre bölünmez bir işlem dizisi olarak adlandırılır ve DBMS tarafından başından sonuna kadar izlenir ve bir işlem başarısız olursa tüm dizi iptal edilir.

DBMS günlüğü - Kullanıcı tarafından erişilemeyen ve veritabanındaki tüm değişiklikler hakkındaki bilgileri kaydetmek için kullanılan özel bir veritabanı veya ana veritabanının bir parçası.

DBMS Günlüğünün Tanıtımı yazılımdaki hataların yanı sıra donanım arızaları ve arızaları durumunda veritabanındaki depolamanın güvenilirliğini sağlamak için tasarlanmıştır.

Veritabanı bütünlüğü - Bu, veritabanının bir özelliğidir, yani konu alanı bilgilerini eksiksiz, tutarlı ve yeterli şekilde yansıtan içerir.

DBMS sınıflandırması.

DBMS sınıflandırılabilir:

1. Program türlerine göre:

a. Veritabanı sunucuları (örneğin, MS SQL Server, InterBase (Borland)) - bilgisayar ağlarındaki veri merkezlerini düzenlemek ve SQL ifadeleri (yani sorgulara yanıt veren programlar) kullanarak istemci programları tarafından talep edilen veritabanı yönetimi işlevlerini uygulamak için tasarlanmıştır;

b. DB istemcileri - veri isteyen programlar. PFSDBMS, elektronik tablolar, kelime işlemciler, e-posta programları istemci programları olarak kullanılabilir;

c. Tamamen işlevsel veritabanları (MS Access, MS Fox Pro) - tablolar oluşturmanıza ve değiştirmenize, veri girmenize, sorgular oluşturmanıza ve biçimlendirmenize, raporlar geliştirmenize ve bunları yazdırmanıza olanak tanıyan gelişmiş bir arayüze sahip bir program.

2. DBMS'nin (ve DB'nin) veri modeline göre:

a. Hiyerarşik - bilgi depolamanın ağaç yapısına dayanır ve bir bilgisayarın dosya sistemine benzer; ana dezavantaj, çoktan çoğa ilişkisinin uygulanamamasıdır;

b. Ağ - hiyerarşik olanların yerini alan ve uzun sürmeyen ana dezavantaj, ciddi uygulamalar geliştirmenin karmaşıklığıydı. Ağ ile hiyerarşik olan arasındaki temel fark, hiyerarşik yapıda "kayıt - soyundan gelen" yalnızca bir ataya sahip olması ve ağın soyundan gelenlerde herhangi bir sayıda ataya sahip olabilmesidir;

c. İlişkisel - verileri, aralarında belirli bağlantıların bulunduğu tablolarda bulunan;

d. Nesne odaklı - verileri nesneler biçiminde depolarlar ve onlarla çalışırken temel avantajı, onlara nesne yönelimli bir yaklaşım uygulayabilmenizdir;

e. Hibrit, yani nesne - ilişkisel - ilişkisel ve nesneye yönelik veritabanlarının yeteneklerini birleştirmek. Böyle bir veritabanına bir örnek Oracle'dır (önceden ilişkiseldi).

3. DBMS'nin tek tek parçalarının konumuna bağlı olarak, ayırt edilirler:

a. yerel - tüm parçaları tek bir bilgisayarda bulunan;

b. ağ.

Ağ şunları içerir:

- organizasyon dosyası ile - sunucu;

Böyle bir organizasyonda, tüm veriler dosya-sunucu adı verilen ve ağa bağlı olan tek bir bilgisayarda bulunur. Gerekli bilgileri bulurken, birçok gereksiz bilgi dahil olmak üzere tüm dosya aktarılır. Ve sadece yerel bir kopya oluştururken gerekli kayıt bulunur.

- bir istemci-sunucu organizasyonu ile;

Veritabanı sunucusu istemciden gelen bir talebi kabul eder, verilerde gerekli kaydı arar ve istemciye aktarır. Sunucuya yapılan sorgu, yapılandırılmış sorgu dili SQL'de oluşturulur, bu nedenle veritabanı sunucularına SQL sunucuları denir.

- dağıtılmış DBMS geniş bir bölgede bulunan onlarca ve yüzlerce sunucu içerir.

İlişkisel veritabanı modelinin temel hükümleri.

İlişkisel veritabanı tüm verilerin tablolar halinde düzenlendiği ve bu veriler üzerindeki tüm işlemlerin tablolar üzerindeki işlemlere indirgendiği bir veritabanı olarak adlandırılır.

İlişkisel veritabanlarının özellikleri:

1. Veriler, sütun ve satırlardan oluşan tablolarda saklanır;

2. Her sütun ve satırın kesişme noktasında bir değer vardır;

3. Her sütun - alanın, adı olarak hizmet veren kendi adı vardır - bir öznitelik ve bir sütundaki tüm değerler aynı türdendir;

4. Sütunlar, gelişigüzel bir sırada düzenlenen satırların aksine, bir tablo oluştururken belirtilen belirli bir sırada düzenlenir. Tablonun tek bir satırı olmayabilir, ancak en az bir sütun olmalıdır.

İlişkisel veritabanı terminolojisi:

İlişkisel veritabanı öğesi	Sunum formu
1. Veritabanı	Tablo seti
2. Veritabanı şeması	Bir dizi tablo başlığı
3. Tutum	Tablo
4. İlişki diyagramı	Tablo Sütun Başlıkları Satırı
5. Öz	Nesne özelliklerinin açıklaması
6. Nitelik	Sütun başlığı
7. Etki Alanı	Birçok geçerli öznitelik değeri
8. Birincil anahtar	Tablodaki her kaydı benzersiz şekilde tanımlayan benzersiz bir tanımlayıcı
9. Veri türü	Tablodaki elemanların değerlerinin türü
10. Tuple	Dize (yazma)
11. Önem	Tablodaki satır sayısı
12. Tutum derecesi	Alan sayısı
13. Vücut ilişkisi	Çoklu ilişki grupları

İlişkisel bir veritabanı tasarlarken, veriler birkaç tabloya yerleştirilir. Anahtarlar kullanılarak tablolar arasında ilişkiler kurulur. Tabloları bağlarken, ana ve ek (alt) tablolar seçilir.

Tablolar arasında aşağıdaki ilişki türleri vardır:

1. 1: 1 formunun ilişkisi (bire bir) ana tablodaki her kaydın ek tablodaki bir kayda karşılık geldiği ve tersine ek tablodaki her kaydın ana tablodaki bir kayda karşılık geldiği anlamına gelir.

2. İlişki türü 1: M (birden çoğa) ana tablodaki her kaydın ek tablodaki birkaç kayda karşılık geldiği ve tersine ek tablodaki her kaydın ana tablodaki yalnızca bir kayda karşılık geldiği anlamına gelir.

3. M: 1 gibi ilişki (çoktan bire) ana tablodaki bir veya daha fazla kaydın ikincil tablodaki yalnızca bir kayda karşılık geldiği anlamına gelir.

4. M formunun ilişkisi: M (çoktan çoğa) - bu, ek tablonun birkaç kaydının ana tablonun birkaç kaydına karşılık geldiği ve tersinin de geçerli olduğu zamandır.

5. MS Access'in ana bileşenleri.

MS Access'in ana bileşenleri (nesneleri) şunlardır:

1. Tablolar;

3. Formlar;

4. Raporlar;

5. Makrolar:

Modüller.

Tablo Verileri kayıtlar (satırlar) ve alanlar (sütunlar) şeklinde depolamak için tasarlanmış bir nesnedir. Her alan kaydın ayrı bir bölümünü içerir ve her tablo belirli bir soru hakkındaki bilgileri depolamak için kullanılır.

soruşturma - tablolarda saklanan veriler hakkında bir soru veya değiştirilecek kayıtların seçilmesi için bir talimat.

Form Tablo alanlarına veri girmek, görüntülemek ve değiştirmek için kontroller yerleştirebileceğiniz bir nesnedir.

Bildiri Kullanıcı tanımlı bilgileri belirli bir şekilde sunmanıza, görüntülemenize ve yazdırmanıza olanak sağlayan bir nesnedir.

Makro - belirli bir görevi otomatikleştirmek için kullanılabilecek bir veya daha fazla makro. Makro, bir makronun temel yapı taşıdır; bir görevi otomatikleştirmek için diğer makrolarla birleştirilebilen bağımsız bir talimat.

Modül - tek bir isim altında saklanan bir dizi açıklama, talimat ve prosedür. MS Access'te üç tür modül vardır: form modülü, rapor modülü ve genel modül. Form ve rapor modülleri, formlar ve raporlar için yerel bir program içerir.

6. MS Access'te Tablolar.

MS Access'te tablo oluşturmak için aşağıdaki yöntemler vardır:

1. Tablo modu;

2. Oluşturucu;

3. Tablo Sihirbazı;

4. Tabloların içe aktarılması;

5. Tablolarla ilişki.

İÇİNDE masa modu veriler boş bir tabloya girilir. Veri girişi için 30 alanlı bir tablo sağlanmıştır. Kaydettikten sonra, MS Access her alana hangi veri tipinin atanacağına kendisi karar verir.

Yapıcı bağımsız olarak alanlar oluşturma, alanlar için veri türlerini seçme, alan boyutları ve alan özelliklerini ayarlama yeteneği sağlar.

Modda bir alan tanımlamak için Yapıcı ayarlanır:

1. Alan adı , her tabloda harflerin, sayıların, boşlukların ve özel karakterlerin birleşiminden oluşan benzersiz bir ada sahip olması gereken, " .!” “ ". Maksimum isim uzunluğu 64 karakterdir.

2. Veri tipi geçerli değerlerin türünü ve aralığını ve bu alan için ayrılan bellek miktarını tanımlar.

MS Access veri türleri

Veri tipi	Açıklama
Metin	İsimler ve adresler, telefon numaraları, posta kodları (255 karaktere kadar) gibi metin ve numaralar.
Not alanı	Yorumlar ve açıklamalar gibi uzun metin ve sayılar (64.000 karaktere kadar).
Sayısal	Parasal hesaplamalar haricinde matematiksel hesaplamalara izin veren sayısal veriler için genel veri türü.
Tarih Saat	Tarih ve saat değerleri. Kullanıcı standart şekiller seçebilir veya özel bir format oluşturabilir.
Parasal	Parasal değerler. Parasal hesaplamalar için sayısal veri türlerinin kullanılması önerilmez, çünkü hesaplanırken yuvarlanabilirler. Para birimi değerleri her zaman, ondalık noktadan sonra belirtilen sayıda ondalık basamakla görüntülenir.
Sayaç	Otomatik olarak gösterilen ardışık sayılar. Numaralandırma 1'den başlar. Sayaç alanı, bir anahtar oluşturmak için uygundur. Bu alan, Size özelliği Long olarak ayarlanmış sayısal bir alanla uyumludur.
Mantıklı	Değerler, iki olası değerden biri olan Evet / Hayır, Doğru / Yanlış, Açık / Kapalı şeklindedir.
OLE Nesne Alanı	OLE protokolünü destekleyen diğer programlarda oluşturulan nesneler.

3. Tarlaların en önemli özellikleri:

- Alan boyutu alanda depolanan maksimum veri boyutunu ayarlar.

- Alan biçimi belirli bir veri türünü görüntülemek için bir formattır ve verileri ekranda görüntülerken veya yazdırırken sunmak için kuralları belirler.

- Alan imzası tablolarda, formlarda, raporlarda görüntülenen metni ayarlar.

- Değer koşulu girişi kontrol etmenize izin verir, koşulların ihlali durumunda giriş değerlerinde kısıtlamalar belirler, girişi yasaklar ve Hata mesajı özelliği ile belirtilen metni görüntüler;

- Hata mesajı Değer üzerinde Koşul tarafından belirtilen kısıtlamalar ihlal edildiğinde ekranda görüntülenen mesaj metnini belirtir.

Kontrol tipi - tablo tasarımcısı penceresindeki Değiştirme sekmesinde ayarlanan bir özellik. Bu özellik, alanın tabloda gösterilip gösterilmeyeceğini ve hangi biçimde - alan olarak mı yoksa birleşik giriş kutusu olarak mı görüntüleneceğini belirler.

Benzersiz (birincil) anahtar tablolar, birkaç alanla basit veya karmaşık olabilir.

Bir anahtar tanımlamak için, anahtarı oluşturan alanlar vurgulanır ve araç çubuğundaki düğmeye basılır. anahtar alanveya komut yürütülür Düzenleme / Anahtar Alan.

© 2015-2019 site
Tüm hakları yazarlarına aittir. Bu site yazarlık iddiasında bulunmaz, ancak ücretsiz kullanım sağlar.
Sayfanın oluşturulduğu tarih: 2016-02-16

yüksek performans sağlayan dil araçlarının ve yazılım sistemlerinin geliştirilmesi ve veritabanı tasarımı teorisinin temellerinin oluşturulması. Bununla birlikte, ilişkisel DBMS'lerin genel kullanıcısı için, bu kavramların gayri resmi eşdeğerleri başarıyla uygulanabilir:

"İlişki" - "tablo" (bazen dosya), "tuple" - "satır" (bazen kayıt), "öznitelik" - "sütun", "alan".

Bu, "kayıt" ın "kaydın örneği" ve "alan" ın "alan adı ve türü" anlamına geldiğini varsayar.

İlişkisel veritabanı

İlişkisel veritabanı, bir veritabanında depolanması gereken tüm bilgileri içeren bir ilişkiler koleksiyonudur. Bununla birlikte, kullanıcılar böyle bir veritabanını bir tablo koleksiyonu olarak algılayabilir. Belirtilmelidir:

Her tablo aynı türden satırlardan oluşur ve benzersiz bir adı vardır; Satırların sabit sayıda alanı (sütunu) ve değeri (birçok

genel alanlara ve yinelenen gruplara izin verilmez). Başka bir deyişle, tablonun bir satır ve bir sütunun kesiştiği her konumda, her zaman tam olarak bir değer vardır veya hiçbir şey yoktur;

Bir tablonun satırları birbirinden zorunlu olarak en az tek bir değerle farklı olmalıdır; bu, böyle bir tablonun herhangi bir satırının açık bir şekilde tanımlanmasını mümkün kılar;

Adlar, tablonun sütunlarına benzersiz bir şekilde atanır ve her birine homojen veri değerleri (tarihler, soyadlar, tam sayılar veya parasal tutarlar) yerleştirilir;

Veritabanının eksiksiz bilgi içeriği, açık veri değerleri olarak temsil edilir ve bu sunum yöntemi tek yöntemdir; Bir tablo üzerinde işlem yapılırken, bilgi içeriğine bakılmaksızın satırları ve sütunları herhangi bir sırada işlenebilir. Bu, tablo adlarının ve sütunlarının mevcudiyetinin yanı sıra, bunların herhangi bir satırını veya belirtilen özelliklere sahip herhangi bir satır kümesini (örneğin, varış yeri "Paris" olan uçuşlar ve varış saati) seçebilme becerisiyle kolaylaştırılır.

12 saate kadar).

İlişkisel verileri değiştirme

İlişkisel bir veri modeli öneren E.F. Codd ayrıca ilişkilerle rahatça çalışmak için bir araç - ilişkisel cebir yarattı. Bu cebirin her işlemi, işlenenleri olarak bir veya daha fazla tablo (ilişki) kullanır ve sonuç olarak yeni bir tablo oluşturur, yani. tabloları "kesmenize" veya "yapıştırmanıza" izin verir (Şekil 1.5).

İncir. 1.5. İlişkisel cebirin bazı işlemleri

İlişkisel cebirin tüm işlemlerini ve hemen hemen her kombinasyonunu uygulamaya izin veren veri işleme dilleri oluşturulmuştur. Bunların arasında en yaygın SQL (Yapılandırılmış Sorgu Dili - yapılandırılmış

sorgu Dili) ve QBE (Örneklerle Sorgu). İkisi de-

kullanıcının, elde etme prosedürünü belirtmeden hangi verilerin elde edilmesi gerektiğini belirttiği çok yüksek seviyedeki dillerle ilgilidir.

Bu dillerden herhangi birinde tek bir sorgu ile, birden çok tabloyu geçici bir tablo halinde birleştirebilir ve ondan gerekli satır ve sütunları (seçim ve projeksiyon) kesebilirsiniz.

İlişkisel Veritabanı Tasarımı, Tasarım Hedefleri

Yalnızca küçük kuruluşlar tek bir tam entegre veritabanında veri paylaşabilir. Çoğu zaman, kuruluşun çalışanlarının (yani sistemin gelecekteki kullanıcıları) tüm bilgi gereksinimlerini kapsamak ve anlamak neredeyse imkansızdır. Bu nedenle, büyük kuruluşların bilgi sistemleri, genellikle çeşitli departmanların birbirine bağlı birkaç bilgisayarı arasında dağıtılan birkaç düzine veritabanı içerir. (Yani büyük şehirlerde, farklı bölgelerde bulunan bir değil, birkaç sebze üssü oluşturulur.)

Ayrı veritabanları, bir veya birkaç uygulamalı problemi çözmek için gerekli tüm verileri veya herhangi bir konu alanıyla ilgili verileri (örneğin, finans, öğrenciler, öğretmenler, aşçılık vb.) Birleştirebilir. İlki genellikle uygulama veritabanları olarak adlandırılır ve ikincisi konu veritabanları olarak adlandırılır (bilgi uygulamaları ile değil, kuruluşun konuları ile ilgilidir). İlki lojistik veya rekreasyon üsleriyle, ikincisi ise sebze ve giyim üsleriyle karşılaştırılabilir.

Konu veritabanları, veri öğeleri kümesi uygulanan veritabanlarının veri öğeleri kümelerini içerdiğinden, mevcut ve gelecekteki uygulamalar için destek sağlamaya izin verir. Sonuç olarak, konu veritabanları oluşturuldu

gayri resmi, değişen ve bilinmeyen sorguları ve uygulamaları (veri gereksinimlerini önceden belirlemenin imkansız olduğu uygulamalar) ele almak için bir çerçeve sağlayın. Bu tür bir esneklik ve uyarlanabilirlik, konu veri tabanları temelinde oldukça istikrarlı bilgi sistemleri oluşturmayı mümkün kılar, örn. Eski uygulamaları yeniden yazmak zorunda kalmadan çoğu değişikliğin yapılabildiği sistemler.

Veritabanı tasarımını mevcut ve öngörülebilir uygulamalara dayandırarak, yüksek verimli bir bilgi sisteminin oluşturulmasını önemli ölçüde hızlandırmak mümkündür, örn. yapısı en yaygın veri erişim yollarını hesaba katan bir sistem. Bu nedenle, uygulamalı tasarım hala bazı geliştiricilerin ilgisini çekmektedir. Ancak, bu tür bilgi sistemlerinin uygulama sayısı arttıkça, uygulanan veri tabanlarının sayısı hızla artmakta, veri çoğaltma seviyesi keskin bir şekilde artmakta ve bakımlarının maliyeti artmaktadır.

Bu nedenle, dikkate alınan tasarım yaklaşımlarının her biri, tasarım sonuçlarını farklı yönlerde etkiler. Hem esneklik hem de verimlilik elde etme arzusu, hem konu hem de uygulamalı yaklaşımları kullanan bir tasarım metodolojisinin oluşmasına yol açmıştır. Genel durumda, konu yaklaşımı, ilk bilgi yapısını oluşturmak için kullanılır ve uygulanan yaklaşım, veri işlemenin verimliliğini artırmak için onu iyileştirmek için kullanılır.

Bir bilgi sistemi tasarlarken, bu sistemin hedeflerini analiz etmek ve bireysel kullanıcıların (kuruluşun çalışanları) gereksinimlerini belirlemek gerekir. Veri toplama, kuruluşun varlıklarını ve bu varlıkları kullanan süreçleri inceleyerek başlar. Varlıklar "benzerlik" (belirli eylemleri gerçekleştirmek için kullanım sıklıkları) ve aralarındaki ilişkisel bağlantıların sayısına (uçak - yolcu, öğretmen - disiplin, öğrenci - oturumu, vb.) Göre gruplandırılır. En büyük benzerliğe ve (veya) en yüksek ilişkilendirici bağlantılara sahip varlıklar veya varlık grupları, konu veritabanlarında birleştirilir. (Genellikle varlıklar, resmi yöntemler kullanılmadan konu veritabanlarında birleştirilir - "sağduyuya" göre).

Veritabanı tasarımının temel amacı, depolanan verilerin fazlalığını azaltmak ve sonuç olarak, kullanılan bellek miktarından tasarruf etmek, yedek kopyaları güncellemek için birden çok işlemin maliyetini azaltmak ve ilgili bilgilerin depolanmasından kaynaklanan tutarsızlık olasılığını ortadan kaldırmaktır. farklı yerlerde aynı nesne. Sözde "temiz" DB projesi ("Her gerçek bir yerde") ilişki normalleştirme metodolojisi kullanılarak oluşturulabilir.

Normalleştirme, bir tabloyu verileri dahil ederken, değiştirirken ve silerken daha iyi özelliklere sahip iki veya daha fazlasına bölmektir.

Normalleştirmenin nihai amacı, her olgunun yalnızca tek bir yerde göründüğü bir veritabanı tasarımına sahip olmaktır, yani. bilgi fazlalığı hariçtir. Bu, bellekten tasarruf etmek için değil, saklanan verilerin olası tutarsızlığını ortadan kaldırmak için yapılır.

İlişkisel bir veritabanındaki her tablo, tablonun her satırının ve sütununun kesişme noktasında her zaman tek bir atomik değer olması ve bu tür değerlerin hiçbir zaman olamayacağı koşulunu karşılar. Bu koşulu karşılayan herhangi bir tabloya normalleştirilmiş denir. Aslında, normalleştirilmemiş tablolar, örn. Yinelenen gruplar içeren tablolara ilişkisel bir veritabanında bile izin verilmez.

Normalleştirilmiş herhangi bir tablo otomatik olarak şuradaki bir tablo olarak kabul edilir birincil normal form, 1NF olarak kısaltılır. Yani, kesinlikle konuşursak, "normalleştirilmiş" ve "1NF'de" aynı anlama gelir. Bununla birlikte, pratikte, "normalleştirilmiş" terimi genellikle daha dar anlamda kullanılmaktadır.

- "tamamen normalleştirilmiş", yani projenin herhangi bir normalleştirme ilkesini ihlal etmediği anlamına gelir.

Şimdi, 1NF'ye ek olarak, normal seviyelerin daha fazla

malizasyon - ikinci normal form (2NF), üçüncü normal form

(3NF) vb. Esasen, bir tablo 1NF'de ise 2NF'dedir

ve ayrıca özü aşağıda ele alınacak olan bazı ek koşulları karşılar. Tablo, 2NF'de ise ve ek olarak başka bir ek koşulu karşılıyorsa 3NF'dedir

vb.

Bu nedenle, her normal form bir anlamda daha sınırlıdır, ancak aynı zamanda öncekinden daha arzu edilir. Bunun nedeni, "(N + 1). Normal formun", "N. normal formda" bulunan bazı çekici olmayan özelliklere sahip olmamasıdır. N'inci normal forma göre (N + 1). Normal forma empoze edilen ek koşulun genel anlamı, bu çekici olmayan tekillikleri ortadan kaldırmaktır.

Normalleştirme teorisi, tablonun alanları arasında bir veya daha fazla ilişkinin varlığına dayanır. Bu tür iki bağımlılık tanımlanmıştır:

rasyonel ve belirsiz.

İşlevsel bağımlılık.Tablonun B alanı işlevsel olarak aynı tablonun A alanına bağlıdır, ancak ve ancak herhangi bir anda, A alanının farklı değerlerinin her biri için, B alanının farklı değerlerinden yalnızca biri zorunlu olarak mevcutsa. burada A ve B alanlarının bileşik olabileceği varsayılmaktadır.

Tam işlevsel bağımlılık. B alanı tam işlevde

işlevsel olarak A'ya bağlıysa ve işlevsel olarak A alanının herhangi bir alt kümesine bağlı değilse, bileşik A alanına işlevsel bağımlılık.

Çok değerli bağımlılık... A Alanı belirsiz bir şekilde B alanını tanımlar.

Bir veri modeli, işlemeye yönelik veri yapıları ve işlemlerinin bir koleksiyonudur. Veri modelini kullanarak, nesnelerin yapısını ve bunlar arasında kurulan ilişkileri görselleştirebilirsiniz. Veri modellerinin terminolojisi, "veri öğesi" ve "bağlayıcı kurallar" kavramlarıyla karakterize edilir. Bir veri öğesi, herhangi bir veri setini açıklar ve bağlanma kuralları, veri öğelerinin ilişkisine yönelik algoritmaları belirler. Bugüne kadar birçok farklı veri modeli geliştirilmiştir, ancak pratikte üç ana model kullanılmaktadır. Hiyerarşik, ağ ve ilişkisel veri modellerini tahsis edin. Buna göre, hiyerarşik, ağ ve ilişkisel DBMS hakkında konuşurlar.

О Hiyerarşik veri modeli. Hiyerarşik olarak organize edilmiş veriler, günlük yaşamda çok yaygındır. Örneğin, bir yüksek öğretim kurumunun yapısı çok düzeyli bir hiyerarşik yapıdır. Hiyerarşik (ağaç benzeri) bir veritabanı, sıralı bir öğe kümesinden oluşur. Bu modelde, orijinal unsurlar diğer unsurları doğurur ve bu unsurlar da bir sonraki unsurları meydana getirir. Her çocuğun yalnızca bir ebeveyni vardır.

Organizasyon şemaları, materyal listeleri, kitaplardaki içindekiler tablosu, proje planları ve diğer birçok veri koleksiyonları hiyerarşik bir şekilde sunulabilir. Atalar ve nesiller arasındaki bağlantıların bütünlüğü otomatik olarak korunur. Temel kural: hiçbir soy, ebeveyni olmadan var olamaz.

Bu modelin temel dezavantajı, tasarım sırasında veri tabanının temelinde oluşturulan hiyerarşiyi kullanma ihtiyacıdır. Sürekli verilerin yeniden düzenlenmesine duyulan ihtiyaç (ve genellikle bu yeniden düzenlemenin imkansızlığı), daha genel bir model - ağın yaratılmasına yol açtı.

О Ağ veri modeli. Verilerin organize edilmesine yönelik ağ tabanlı yaklaşım, hiyerarşik yaklaşımın bir uzantısıdır. Bu model, üretilen her bir öğenin birden fazla ana öğeye sahip olabilmesi açısından hiyerarşik modelden farklıdır. ■

Ağ veritabanı, ilgili kuruluşun verilerinde bulunan tüm ilişki türlerini doğrudan temsil edebildiğinden, bu veriler her türlü yolla gezilebilir, keşfedilebilir ve sorgulanabilir, yani ağ modeli tek bir hiyerarşi ile bağlantılı değildir. Bununla birlikte, bir ağ veritabanına bir sorgu oluşturmak için, yapısını derinlemesine araştırmak (bu veritabanının bir diyagramına sahip olmak) ve veritabanında gezinmek için bir mekanizma geliştirmek gerekir ki bu da bunun önemli bir dezavantajıdır. veritabanı modeli.

İlişkisel veri modeli hakkında. İlişkisel bir veri modelinin arkasındaki temel fikir, herhangi bir veri kümesini iki boyutlu bir tablo olarak temsil etmektir. En basit haliyle, ilişkisel bir model tek bir iki boyutlu tabloyu tanımlar, ancak çoğu zaman bu model, birkaç farklı tablo arasındaki yapıyı ve ilişkileri açıklar.

İlişkisel veri modeli

Bu nedenle, bilgi sisteminin amacı, verihakkında nesnelerhesaba katılarak gerçek dünya bağlantılarınesneler arasında. DB teorisinde, verilere genellikle öznitelikler venesneler - varlıklar.Nesne, nitelik ve bağlantı, I.S.'nin temel kavramlarıdır.

Bir obje(veya varlık) var olan bir şeydir ve farkedilebilirbaşka bir deyişle, bir nesne, bir adı ve benzer bir nesneyi diğerinden ayırt etmenin bir yolu olan "bir şey" olarak adlandırılabilir. Örneğin her okul bir nesnedir. Nesneler aynı zamanda bir kişi, bir okuldaki bir sınıf, bir firma, bir alaşım, bir kimyasal bileşik, vs.'dir. Nesneler yalnızca maddi nesneler değil, aynı zamanda gerçek dünyayı yansıtan daha soyut kavramlar da olabilir. Örneğin olaylar, bölgeler, sanat eserleri; kitaplar (basılı ürünler olarak değil, eserler olarak), tiyatro gösterileri, filmler; yasal normlar, felsefi teoriler vb.

Öznitelik(veya verilen)- bu, belirli bir nesneyi karakterize eden ve nesnenin belirli bir örneği için belirli bir sayısal, metinsel veya başka bir değer alan bir göstergedir. Bilgi sistemi, belirli bir konu alanıyla ilişkili olarak tasarlanmış nesneler kümesiyle çalışır ve belirli öznitelik değerleri(veriler) belirli nesnelerin. Örneğin, okuldaki dersleri bir nesneler koleksiyonu olarak ele alalım. Bir sınıftaki öğrenci sayısı, sayısal bir değer alan bir veridir (bir sınıfın 28'i, diğerinin 32'si vardır). Sınıfın adı, metinsel bir anlam alan belirli bir addır (birinin 10A, diğerinin 9B olması vb.).

İlişkisel veri tabanlarının gelişimi, 1960'ların sonlarında, tartışılan ilk makalelerin ortaya çıkmasıyla başladı; veri tabanlarının tasarımında, veri sunmanın olağan ve doğal yollarını kullanma imkanı - sözde tabular veri modelleri.

İlişkisel veritabanları teorisinin kurucusunun, makaleyi yayınlayan IBM çalışanı Dr.E.Codd olduğu düşünülmektedir. Büyük Paylaşımlı Veri Bankaları için İlişkisel Veri Modeli(Büyük toplu veri bankaları için ilişkisel veri modeli). Bu makale, "ilişkisel veri modeli" terimini kullanan ilk makale oldu. 70'lerde Amerika Birleşik Devletleri'nde Dr. E. Codd tarafından geliştirilen ilişkisel veritabanları teorisi, verileri verimli bir şekilde organize etmek için kuralları açıklayan güçlü bir matematiksel temele sahiptir. E. Codd tarafından geliştirilen teorik temel, veritabanı tasarımı teorisinin geliştirilmesinin temeli haline geldi.

Eğitimde matematikçi olan E. Codd, veri işleme için küme teorisinin (birleşme, kesişim, fark, Kartezyen çarpım) aygıtlarının kullanılmasını önerdi. Herhangi bir veri setinin matematikte "ilişkiler" olarak bilinen özel bir türden iki boyutlu tablolar olarak temsil edilebileceğini kanıtladı.

İlişkiselbu tür bir veritabanı, tüm verilerin kullanıcıya dikdörtgen veri değerleri tabloları şeklinde sunulduğu ve veritabanı üzerindeki tüm işlemlerin manipüle tablolara indirgentiği düşünülmektedir.

Tablo şunlardan oluşur: sütunlar (alanlar)ve çizgiler (kayıtlar);veritabanı içinde benzersiz bir ada sahiptir. Tabloyansıtır nesne türügerçek dünya (öz),ve her biri string belirli bir nesnedir.Bir tablodaki her sütun, bir nesnenin belirli bir niteliği için bir değerler koleksiyonudur. Değerler, nesne özniteliğinin tüm olası değerleri kümesinden seçilir. alan adı.

En genel haliyle, bir alan, alan öğelerinin ait olduğu bazı temel veri türleri ve veri öğelerine uygulanan rastgele bir mantıksal ifade belirtilerek tanımlanır. Bir veri öğesinde mantıksal bir koşulu değerlendirirken sonuç "true" ise, bu öğe etki alanına aittir. En basit durumda, bir alan aynı türden geçerli bir potansiyel değerler kümesi olarak tanımlanır. Örneğin, tüm çalışanların doğum tarihlerinin seti "Doğum Tarihi Etki Alanını" ve tüm çalışanların adları "Çalışan Adı Etki Alanını" oluşturur. Doğum tarihi etki alanı, zamandaki noktalar hakkındaki bilgileri depolamak için bir veri türüne sahiptir ve çalışan adı etki alanı bir karakter veri türü olmalıdır.

İki değer aynı etki alanından geliyorsa, iki değeri karşılaştırabilirsiniz. Örneğin, iki değer doğum tarihi alanından geliyorsa, hangi çalışanın daha yaşlı olduğunu belirlemek için bunları karşılaştırabilirsiniz. Değerler farklı alanlardan alınırsa, karşılaştırmalarına izin verilmez, çünkü büyük olasılıkla mantıklı değildir. Örneğin, bir çalışanın adını ve doğum tarihini karşılaştırmaktan kesin bir şey gelmeyecektir.

Her sütunun (alan), genellikle tablonun üst kısmına yazılan bir adı vardır. Belirli bir DBMS içinde tablolar tasarlarken, her alan için kendi bir türdiğer bir deyişle, onu görüntülemek için bir dizi kural tanımlamanın yanı sıra bu alanda depolanan veriler üzerinde gerçekleştirilebilecek işlemleri tanımlayın. Tür grupları, farklı DBMS'ler için farklı olabilir.

Alan adı tabloda benzersiz olmalıdır, ancak farklı tablolarda aynı ada sahip alanlar olabilir. Herhangi bir tablo en az bir alana sahip olmalıdır; alanlar, oluşturulduğunda adlarının göründüğü sıraya göre tabloda düzenlenir. Alanlardan farklı olarak dizelerin adları yoktur; tablodaki sıraları tanımlanmamıştır ve sayı mantıksal olarak sınırlı değildir.

Tablodaki satırlar sıralı olmadığı için pozisyonuna göre bir satır seçmek imkansızdır - aralarında "birinci", "ikinci", "son" yoktur. Herhangi bir tabloda, satırlarının her birini benzersiz şekilde tanımlayan değerler olan bir veya daha fazla sütun vardır. Böyle bir sütuna (veya sütun kombinasyonuna) denir birincil anahtar... Yapay bir alan, genellikle bir tablodaki kayıtları numaralandırmak için kullanılır. Bu tür bir alan, örneğin, tablodaki her kaydın benzersizliğini sağlayabilen sıralı olabilir. Anahtarın aşağıdaki özelliklere sahip olması gerekir.

Benzersizlik.Herhangi bir anda, ilişkinin iki farklı tuplesinin anahtarda bulunan özniteliklerin birleşimi için aynı değeri yoktur. Yani tabloda aynı kimlik veya pasaport numarasına sahip iki satır olamaz.

Minimumluk.Anahtarda bulunan özelliklerin hiçbiri, benzersizliği ihlal etmeden anahtardan çıkarılamaz. Bu, hem pasaport numarasını hem de kimlik numarasını içeren bir anahtar oluşturmanın gerekli olmadığı anlamına gelir. Demeti benzersiz bir şekilde tanımlamak için bu özniteliklerden herhangi birini kullanmak yeterlidir. Ayrıca anahtara benzersiz olmayan bir öznitelik eklememelisiniz, yani bir kimlik numarası ile bir çalışanın adının bir kombinasyonunu anahtar olarak kullanmak yasaktır. Çalışan adını anahtardan çıkararak, her satırı yine de benzersiz şekilde tanımlayabilirsiniz.

Her ilişkinin en az bir olası anahtarı vardır, çünkü tüm niteliklerinin toplamı benzersizlik koşulunu karşılar - bu, ilişkinin tanımından kaynaklanır.

Olası anahtarlardan biri rastgele seçilir. birincil anahtar olarak.Varsa kalan olası anahtarlar, alternatif anahtarlar.Örneğin, birincil anahtar olarak bir kimlik numarası seçerseniz, pasaport numarası bir alternatif anahtar olacaktır.

Tabloların ilişkisi, ilişkisel veri modelinin temel bir unsurudur. O destekleniyor yabancı anahtarlar.

İlişkisel bir veritabanı modelini açıklarken, açıklama düzeyine (teori veya uygulama) ve sisteme (Access, SQL Server, dBase) bağlı olarak aynı kavram için genellikle farklı terimler kullanılır. Tablo 2.3 kullanılan terimleri özetler.

Tablo 2.3.Veritabanı terminolojisi

Veritabanı Teorisi ____________ İlişkisel Veritabanları _________ SQL Server __________

İlişki Tablosu Tablosu

Tuple Kayıt Satırı

Öznitelik Alanı _______________ Sütun

İlişkisel veritabanları

İlişkisel veritabanıveritabanında depolanması gereken tüm bilgileri içeren bir ilişkiler kümesidir. Diğer bir deyişle, veritabanı, tüm verileri depolamak için gereken tablo kümesini temsil eder. İlişkisel veritabanı tabloları mantıksal olarak birbirleriyle ilişkilidir.İlişkisel bir veritabanı için tasarım gereksinimleri birkaç kuralda özetlenebilir.

О Her tablonun veritabanında benzersiz bir adı vardır ve aynı türden satırlardan oluşur.

О Her tablo sabit sayıda sütun ve değerden oluşur. Bir satırın bir sütununda birden fazla değer saklanamaz. Örneğin yazar, yayın tarihi, tiraj vb. Bilgileri içeren bir tablo varsa yazarın adının bulunduğu sütun birden fazla soyadı içeremez. Kitap iki veya daha fazla yazar tarafından yazılmışsa, ek tablolar kullanmanız gerekecektir.

О Tabloda hiçbir zaman birbirini kopyalayan iki sıra olmayacaktır. Tablodaki herhangi bir satırı benzersiz bir şekilde tanımlayabilmek için satırlar en az bir değer farklı olmalıdır.

О Her sütuna tablo içinde benzersiz bir ad atanır; homojen değerlerin (tarihler, soyadlar, telefon numaraları, para toplamları vb.) bu sütuna yerleştirilmesi için belirli bir veri türü belirlenir.

О Veritabanının eksiksiz bilgi içeriği, verinin kendisinin açık değerleri biçiminde temsil edilir ve bu sunum yöntemi tek yöntemdir. Örneğin, tablolar arasındaki ilişki, ilişkileri yapay olarak tanımlayan herhangi bir işaretleyiciye değil, karşılık gelen sütunlarda depolanan verilere dayanır.

О Verileri işlerken, tablonun herhangi bir satırına veya sütununa özgürce başvurabilirsiniz. Tabloda saklanan değerler, verilere erişilme sırasına herhangi bir kısıtlama getirmez. Kolon AÇIKLAMASI,

Veritabanı (DB), belirli bir konu alanı, konu veya görevle ilgili olarak belirli kurallara göre düzenlenmiş ve bilgisayar belleğinde tutulan nesneler, süreçler, olaylar veya olgular hakkında bilgi koleksiyonudur. Kullanıcıların bilgi ihtiyaçlarını ve bu veri koleksiyonunun bir bütün olarak veya herhangi bir kısmının uygun şekilde depolanmasını sağlayacak şekilde düzenlenmiştir.

İlişkisel veritabanı, her biri belirli bir türdeki nesneler hakkında bilgi içeren birbirine bağlı bir tablolar kümesidir. Tablonun her satırı, bir nesne (örneğin, araba, bilgisayar, müşteri) hakkında veriler içerir ve tablonun sütunları, bu nesnelerin çeşitli özelliklerini içerir - özellikler (örneğin, motor numarası, işlemci markası, şirketlerin telefon numaraları veya müşteriler).

Tablodaki satırlara kayıt adı verilir. Tablonun tüm kayıtları aynı yapıya sahiptir - nesnenin niteliklerini saklayan alanlardan (veri öğeleri) oluşur (Şekil 1). Her kayıt alanı bir nesne özelliği içerir ve belirli bir veri türünü temsil eder (örneğin, metin dizesi, sayı, tarih). Birincil anahtar, kayıtları tanımlamak için kullanılır. Birincil anahtar, değerlerin bileşimi tablodaki her kaydı benzersiz şekilde tanımlayan bir tablo alanları kümesidir.

İncir. 1. Tablodaki nesnelerin adları

Verilerle çalışmak için veritabanı yönetim sistemleri (DBMS) kullanılır. DBMS'nin ana işlevleri:

Veri tanımı (veritabanı yapısının açıklaması);

Veri işleme;

Veri yönetimi.

Veritabanı yapısının geliştirilmesi, bir veritabanı tasarımında çözülen en önemli görevdir. Bir veritabanının yapısı (tablolarının kümesi, biçimi ve ilişkileri), bir veritabanı kullanarak uygulamalar oluştururken ana tasarım kararlarından biridir. Geliştirici tarafından oluşturulan DB yapısı, DBMS veri tanımlama dilinde açıklanmıştır.

Herhangi bir DBMS, verilerle aşağıdaki işlemleri gerçekleştirmenize izin verir:

Tablolara kayıt ekleme;

Bir tablodan kayıtların kaldırılması;

Veritabanı tablolarındaki bir veya daha fazla kayıttaki bazı alanların değerlerini güncelleme;

Belirli bir koşulla eşleşen bir veya daha fazla kayıt arayın.

Bu işlemleri gerçekleştirmek için bir sorgu mekanizması kullanılır. Sorgu yürütmenin sonucu ya belirli kriterlere göre seçilen bir kayıt kümesidir ya da tablolardaki değişikliklerdir. Veritabanına yapılan sorgular, bunun için özel olarak oluşturulmuş ve "yapılandırılmış sorgu dili" (SQL - Yapılandırılmış Sorgu Dili) adı verilen bir dilde oluşturulur.

Veri yönetimi genellikle verileri yetkisiz erişimden korumak, verilerle çok kullanıcılı çalışma modunu desteklemek ve verilerin bütünlüğünü ve tutarlılığını sağlamak olarak anlaşılır.

• Aktar

Çevirmenin notu: Makale oldukça eski olmasına (2 yıl önce yayınlanmıştır) ve yüksek sesle başlığa sahip olmasına rağmen, ilişkisel veritabanları ile NoSQL veritabanları arasındaki farkları, avantajlarını ve dezavantajlarını iyi bir şekilde anlamayı sağlar ve ayrıca -ilişkisel depolama.

Son zamanlarda pek çok ilişkisel olmayan veri tabanı ortaya çıktı. Bu, neredeyse sınırsız isteğe bağlı ölçeklenebilirlik istiyorsanız, ilişkisel olmayan bir veritabanına ihtiyacınız olduğunu gösterir.

Bu doğruysa, bu güçlü ilişkisel veritabanlarının savunmasız olduğu anlamına mı geliyor? Bu, ilişkisel veritabanı günlerinin sona erdiği ve yakında biteceği anlamına mı geliyor? Bu makalede, çeşitli durumlar için ilişkisel olmayan veritabanlarının popüler kaymasına 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 ortalıkta. Bu süre zarfında, ilişkisel depolamayı sona erdirmesi beklenen birkaç devrim patlak verdi. Elbette bu devrimlerin hiçbiri gerçekleşmedi ve bunlardan biri ilişkisel veri tabanlarının konumunu bir nebze olsun sallamadı.

Temel bilgilerle başlayalım

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

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

Bu hakimiyetin nedenleri açık değildir. İlişkisel veritabanları tarihi boyunca, veri yönetiminde tutarlı bir şekilde basitlik, sağlamlık, esneklik, performans, ölçeklenebilirlik ve birlikte çalışabilirliğin en iyi karışımını sunmuşlardır.

Bununla birlikte, tüm bu özellikleri sağlamak için ilişkisel depolama dahili olarak inanılmaz derecede karmaşıktır. Örneğin, basit bir SELECT sorgusu, optimize edicinin doğrudan çalışma zamanında değerlendireceği yüzlerce potansiyel yürütme yoluna sahip olabilir. Bunların hepsi kullanıcılardan gizlenir, ancak RDBMS'nin içinde, maliyetlendirme algoritmaları gibi şeylere ve sorguya en uygun olana dayalı bir yürütme planı oluşturur.

İlişkisel veritabanı sorunları

İlişkisel depolama basitlik, sağlamlık, esneklik, performans, ölçeklenebilirlik ve birlikte çalışabilirliğin en iyi karışımını sağlarken, bunların her birinde belirli bir özelliğe odaklanan benzer sistemlerden daha iyi performans göstermesi gerekmez. İlişkisel DBMS'lerin ezici hakimiyeti herhangi bir eksikliğe ağır bastığı için bu büyük bir sorun değildi. Bununla birlikte, 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 listelenen özelliklerin önemi de artıyor. Veritabanlarının sayısı arttıkça, bir özellik diğerlerini gölgede bırakmaya başlar. Ölçeklenebilirlik. Web hizmetleri gibi yüksek yük koşullarında daha fazla uygulama çalıştıkça, ölçeklenebilirlik gereksinimleri çok hızlı bir şekilde değişebilir ve önemli ölçüde büyüyebilir. Kendi sunucunuzda bulunan ilişkisel bir veritabanınız varsa, ilk sorunu çözmek çok zor olabilir. Sunucu yükünün bir gecede üçe katlandığını varsayalım. Donanımı ne kadar hızlı yükseltebilirsiniz? İkinci problemin çözümü, ilişkisel veri tabanlarının kullanılması durumunda da zorluklara neden olur.

İlişkisel veritabanları, yalnızca tek bir sunucuda bulunmaları durumunda iyi ölçeklenir. Bu sunucunun kaynakları tükendiğinde, daha fazla makine eklemeniz ve yükü bunlar arasında dağıtmanız gerekecektir. İlişkisel veritabanlarının karmaşıklığının ölçeklenebilirliğe karşı oynamaya başladığı yer burasıdır. Sunucu sayısını birkaç değil, yüz veya bine çıkarmaya çalışırsanız, karmaşıklık büyük ölçüde artar ve ilişkisel veritabanlarını bu kadar çekici kılan özellikler, onları kullanma şansını hızla sıfıra indirir. büyük dağıtılmış sistemler için bir platform.

Rekabette kalabilmek için bulut satıcıları bu sınırlamayla bir şekilde mücadele etmelidir, çünkü ölçeklenebilir veri depolaması olmadan bu ne tür bir bulut platformudur. Bu nedenle, satıcıların, kullanıcılara ölçeklenebilir depolama alanı sağlamak istiyorlarsa yalnızca bir seçeneği vardır. İlişkisel veritabanlarında bulunan diğer yetenekler pahasına da olsa, daha ölçeklenebilir olan diğer veritabanı türlerini kullanmanız gerekir.

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

Yeni dalga

Bu tür bir veritabanı genellikle bir anahtar-değer deposu olarak adlandırılır. Aslında, resmi bir isim yoktur, bu nedenle onu belge odaklı, öznitelik odaklı, dağıtılmış veritabanları (ilişkisel de olabilirler), parçalanmış sıralı diziler, dağıtılmış karma tablolar ve depolama bağlamında bulabilirsiniz. yazın. Bu isimlerin her biri sistemin belirli özelliklerini belirtirken, hepsi anahtar-değer depolaması olarak adlandıracağımız bir temanın varyasyonlarıdır.

Ancak, adı ne olursa olsun, bu "yeni" veritabanı türü o kadar da yeni değildir ve her zaman öncelikle ilişkisel veritabanlarının uygun olmadığı uygulamalar için kullanılmıştır. Bununla birlikte, ölçeklenebilirlik için web'e ve buluta ihtiyaç duyulmadan, bu sistemler yüksek talep görmüyordu. Şimdi zorluk, belirli bir sistem için hangi tür depolamanın daha uygun olduğunu belirlemektir.
İlişkisel veritabanları ve anahtar-değer depoları temelde farklılık gösterir ve farklı sorunları çözmek için tasarlanmıştır. Özellikleri karşılaştırmak yalnızca aralarındaki farkı anlamanıza izin verecektir, ancak bununla başlayalım:

Depolama özellikleri

İlişkisel veritabanı	Anahtar-değer depolaması
Bir veritabanı tablolardan oluşur, tablolar sütun ve satırlardan oluşur ve satırlar sütun değerlerinden oluşur. Bir tablodaki tüm satırlar aynı yapıya sahiptir.	Etki alanları için tablolarla bir benzetme kurabilirsiniz, ancak etki alanları için tablolardan farklı olarak veri yapısı tanımlanmamıştır. Alan, istediğiniz her şeyi koyabileceğiniz bir kutudur. Aynı alan içindeki kayıtlar farklı yapılara sahip olabilir.
Veri Modeli 1 önceden tanımlanmıştır. Türleri güçlüdür ve veri bütünlüğünü sağlamak için kısıtlamalar ve ilişkiler içerir.	Kayıtlar, her kayıt kendisiyle ilişkilendirilmiş dinamik bir öznitelik kümesine sahip olarak anahtara göre tanımlanır.
Veri modeli, uygulamanın işlevselliğine değil, içerilen verilerin doğal temsiline dayanmaktadır.	Bazı uygulamalarda, öznitelikler yalnızca dizeler olabilir. Diğer uygulamalarda, özniteliklerin programlamada kullanılan türleri yansıtan basit veri türleri vardır: tamsayılar, dizeler dizileri ve listeler.
Veri tekrarını önlemek için veri modeli normalleştirilir. Normalleştirme, tablolar arasında ilişkiler oluşturur. İlişkiler, farklı tablolardaki verileri birbirine bağlar.	İlişkiler, alanlar arasında ve tek bir alan içinde açıkça tanımlanmamıştır.

Birleşme yok

Anahtar-değer depoları kayıt odaklıdır. Bu, belirli bir kayıtla ilgili tüm bilgilerin onunla birlikte saklandığı anlamına gelir. Bir alan adı (tablo olarak düşünebileceğiniz) sayısız farklı kayıt içerebilir. Örneğin, bir alan adı müşteriler ve siparişler hakkında bilgi içerebilir. Bu, verilerin genellikle farklı alanlar arasında kopyalandığı anlamına gelir. Disk alanı ucuz olduğu için bu kabul edilebilir bir yaklaşımdır. Önemli olan, ilgili tüm verilerin tek bir yerde depolanmasına izin vermesidir, bu da ölçeklenebilirliği artırır, çünkü farklı tablolardan verileri birleştirmeye gerek yoktur. İlişkisel bir veritabanı kullanırken, gerekli bilgileri tek bir yerde gruplamak için birleştirmeleri kullanmanız gerekir.

Anahtar-değer çiftlerini depolamak için bir ilişkiye olan ihtiyaç önemli ölçüde azalsa da, ilişkilere hala ihtiyaç vardır. Bu tür ilişkiler genellikle ana varlıklar arasında mevcuttur. Örneğin, bir sipariş sistemi, müşteriler, ürünler ve siparişler hakkında veri içeren kayıtlara sahip olacaktır. Bu verilerin bir alanda mı yoksa birden fazla alanda mı olduğu önemli değildir. Sonuç olarak, bir müşteri bir sipariş verdiğinde, muhtemelen müşteriyi ve sipariş bilgilerini tek bir kayıtta tutmak istemezsiniz.
Bunun yerine, sipariş kaydı ilgili müşteri ve ürün kayıtlarına işaret eden anahtarlar içermelidir. Kayıtlar herhangi bir bilgiyi depolayabildiğinden ve ilişkiler veri modelinin kendisinde tanımlanmadığından, veritabanı yönetim sistemi ilişkilerin bütünlüğünü kontrol edemeyecektir. Bu, sipariş ettikleri müşterileri ve ürünleri silebileceğiniz anlamına gelir. Veri bütünlüğünü sağlamak tamamen uygulamaya bağlıdır.

Veri erişimi

İlişkisel veritabanı	Anahtar-değer depolaması
Veriler Yapılandırılmış Sorgu Dili (SQL) kullanılarak oluşturulur, güncellenir, silinir ve sorgulanır.	Veriler, API yöntemi çağrıları kullanılarak oluşturulur, güncellenir, silinir ve sorgulanır.
SQL sorguları, birleştirmeleri kullanarak hem tek bir tablodan hem de birden çok tablodan veri alabilir.	Bazı uygulamalar, filtre koşullarını belirlemek için SQL benzeri sözdizimi sağlar.
SQL sorguları, toplamaları ve karmaşık filtreleri içerebilir.	Genellikle, yalnızca temel karşılaştırma operatörlerini (\u003d ,! \u003d,<, >, <= и =>).
İlişkisel bir veritabanı genellikle tetikleyiciler, saklı yordamlar ve işlevler gibi gömülü mantığı içerir.	Tüm iş ve veri bütünlüğü mantığı uygulama kodunda yer alır.

Uygulamalar ile etkileşim

Anahtar-değer depoları: faydalar

Bu tür sistemlerin ilişkisel depolamaya göre iki farklı avantajı vardır.

Bulut hizmetleri için uygundur

Anahtar-değer depolarının ilk avantajı, ilişkisel veritabanlarından daha basit ve dolayısıyla daha ölçeklenebilir olmalarıdır. Kendi sisteminizi birlikte barındırıyorsanız ve veri deponuzun arkasındaki artan yükü kaldırması gereken bir düzine veya yüz sunucuyu barındırmayı planlıyorsanız, anahtar-değer depoları sizin seçiminizdir.

Kolay ve dinamik olarak genişletilebilir olduklarından, çok kiracılı bir web depolama platformu sağlayan satıcılar için de kullanışlıdır. Böyle bir veritabanı, büyük ölçeklenebilirlik potansiyeline sahip nispeten ucuz bir depolama ortamını temsil eder. Kullanıcılar genellikle yalnızca kullandıkları kadar ödeme yapar, ancak ihtiyaçları artabilir. Satıcı, herhangi bir kısıtlama olmaksızın dinamik ve pratik olarak yüke bağlı olarak platformun boyutunu artırabilecektir.

Daha doğal kod entegrasyonu

İlişkisel veri modeli ve kod nesne modeli genellikle farklı şekilde oluşturulur ve bu da bazı uyumsuzluklara yol açar. Geliştiriciler, ilişkisel modeli nesne modeline eşleyen kod yazarak bu sorunu çözerler. Bu sürecin net ve hızlı bir şekilde elde edilebilecek bir değeri yoktur ve uygulamanın geliştirilmesine harcanabilecek oldukça fazla zaman alabilir. Bu arada, birçok anahtar / değer çifti, verileri nesnelerle daha doğal bir şekilde eşleşen bir yapıda depolar. Bu, geliştirme süresini önemli ölçüde azaltabilir.

"İlişkisel veritabanları beceriksizleşebilir" gibi anahtar-değer depolarını kullanmak için diğer argümanlar (bu arada, bunun ne anlama geldiğine dair hiçbir fikrim yok) daha az zorlayıcıdır. Ancak bu tür depoların savunucusu olmadan önce bir sonraki bölüme göz atın.

Anahtar-değer depoları: dezavantajlar

İlişkisel veritabanlarındaki kısıtlamalar, en düşük seviyede veri bütünlüğünü sağlar. Fiziksel olarak kısıtlamaları karşılamayan veriler veritabanına giremez. Anahtar-değer depolarında bu tür kısıtlamalar yoktur, bu nedenle veri bütünlüğü kontrolü tamamen uygulamalara bağlıdır. Bununla birlikte, herhangi bir kodda 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 bu tür sorunlara yol açar.

İlişkisel veritabanlarının bir diğer avantajı, sizi bir veri modeli geliştirme sürecine zorlamalarıdır. İyi tasarlanmış bir modeliniz varsa, 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 uygulama mantığının temel modelde herhangi bir değişiklik yapılmadan değiştirilebileceği anlamına gelir. Aynı şeyi anahtar-değer depolamayla yapmak için, ilişkisel model tasarım sürecini, doğal veri yapısına dayalı genel sınıflar oluşturan sınıf tasarımıyla değiştirmeyi deneyin.

Uyumluluğu da unutmayın. İlişkisel veritabanlarının aksine, bulut tabanlı depolamanın daha az ortak standardı vardır. Kavramsal olarak farklı olmasalar da, hepsinin farklı API'leri, istek arayüzleri ve kendilerine özgü özellikleri vardır. Bu nedenle, satıcınıza güvenmeniz daha iyi olur, çünkü bir şey olursa, başka bir servis sağlayıcıya kolayca geçiş yapamazsınız. 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üvenmek ilişkisel veritabanlarından daha da riskli hale geliyor.

Sınırlı veri analizi

Tipik olarak, tüm bulut depolaması çoklu kiralama türü üzerine kuruludur, bu da çok sayıda kullanıcının ve uygulamanın aynı sistemi kullandığı anlamına gelir. Tüm sistemin "ele geçirilmesini" önlemek için, satıcılar genellikle sorgu yürütmeyi bir şekilde kısıtlar. Örneğin, SimpleDB'de bir sorgu 5 saniyeden uzun süremez. Google AppEngine Datastore, istek başına 1000'den fazla kayıt alamaz 3.

Bu kısıtlamalar basit mantık için (az sayıda kayıt oluşturma, güncelleme, silme ve geri alma) korkutucu değildir. Peki ya uygulamanız popüler olursa? Çok sayıda yeni kullanıcınız ve birçok yeni veriniz var ve şimdi kullanıcılar için yeni deneyimler oluşturmak veya bir şekilde verilerden yararlanmak istiyorsunuz. Verileri analiz etmek için basit sorgularla bile karışıklığa gidebileceğiniz yer burasıdır. Uygulama kullanım modellerini izleme veya kullanıcı geçmişine dayalı bir öneri sistemi gibi özellikler en iyi ihtimalle yanıltıcı olabilir. Ve en kötüsü, tamamen imkansızdır.

Bu durumda, analitik için, anahtar-değer deponuzdaki verilerle doldurulacak ayrı bir veritabanı oluşturmak 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? Siz ve sağlayıcınız arasındaki sinyal gecikmelerinden dolayı herhangi bir sorun olacak mı? Depolamanız bu veri aktarımını destekliyor mu? 100 milyon kaydınız varsa ve bir seferde 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 faydasız olacaktır, çünkü bu hizmet daha fazla seçenek ve ayar sağlar.

Bulut depolama

Birçok web servis sağlayıcısı, çok kiracılı anahtar-değer mağazaları sunar. Birçoğu yukarıda listelenen kriterleri karşılar, 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 örnek havuzlara bir göz atalım.

Amazon: SimpleDB

SimpleDB, Amazon WebServices'e dahil olan, anahtar-değer özniteliğine yönelik bir depodur. SimpleDB beta sürümündedir; kullanıcılar, ihtiyaçları belirli bir sınırı aşmadığı sürece ücretsiz olarak kullanabilirler.

SimpleDB'nin birkaç sınırlaması 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 dizge olarak saklanır, alınır ve karşılaştırılır, bu nedenle tarihleri \u200b\u200bkarşılaştırmak için onları ISO8601 biçimine dönüştürmeniz gerekir. Üçüncüsü, herhangi bir dizenin maksimum boyutu 1024 bayttır ve bu, bir öznitelik olarak depolayabileceğiniz metnin boyutunu (örneğin, ürün açıklaması) sınırlar. Ancak, veri yapısı esnek olduğundan, "Ürün Açıklaması1", "Ürün Açıklaması2" vb. Öznitelikleri ekleyerek bu sınırlamayı aşabilirsiniz. Ancak özniteliklerin 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 terabayttan büyük olamaz.

SimpleDB'nin temel özelliklerinden biri, nihai bir tutarlılık modelinin kullanılmasıdır. Bu model, çok iş parçacıklı işler 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örmeyebileceğini unutmayın. Olayların böyle bir 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ş müşteriye satmak istemezsiniz.

Google AppEngine Veri Deposu

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

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

Bu, Google AppEngine ile geliştirirken büyük olasılıkla kullanacağınız veri deposudur. 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 ücretsiz, beta sürümündedir ve veritabanı boyutu sınırlarına sahiptir. SQL Data Services ayrı bir uygulamadır - verileri depolayan birçok SQL sunucusu üzerinde bir eklenti. Bu mağazalar ilişkisel olabilir, ancak sizin için SDS, yukarıda açıklanan ürünler gibi bir anahtar-değer deposu.

Bulut dışı depolama

Bulut dışında kendi başınıza kurarak kullanabileceğiniz çok sayıda havuz da vardır. Bu projelerin neredeyse tamamı genç, alfa veya beta ve açık kaynak. Açık kaynak ile, tescilli ürünlere kıyasla potansiyel sorunların ve sınırlamaların daha fazla farkında olabilirsiniz.

CouchDB

CouchDB, ücretsiz ve açık kaynaklı bir belge odaklı veritabanıdır. JSON, veri depolama biçimi olarak kullanılır. CouchDB, "görünümler" kullanarak belge tabanlı ve ilişkisel veritabanları arasındaki boşluğu doldurmayı amaçlamaktadır. Bu tür görünümler, tabloya benzer bir biçimde belgelerden alınan verileri içerir ve dizinler oluşturmanıza ve sorgu çalıştırmanıza olanak tanır.

CouchDB şu anda gerçekten dağıtılmış bir veritabanı değil. Verileri sunucular arasında senkronize tutmak için ç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 sunucuya ölçeklenmek üzere tasarlanmış bir anahtar-değer dağıtılmış veritabanıdır. LinkedIn'in geliştirilmesi sırasında doğmuştur ve yüksek ölçeklenebilirlik gereksinimleri olan birkaç sistem için kullanılmıştır. Voldemort projesi ayrıca nihai bir tutarlılık modeli kullanır.

Mongo

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 formatında saklayan belge odaklı bir veritabanıdır. Bununla birlikte, Mongo, salt bir anahtar-değer deposundan çok bir nesne tabanıdır.

Çiseleme

Drizzle, anahtar-değer mağazalarının uğraşmak üzere tasarlandığı sorunları çözmek için çok farklı bir yaklaşım sunar. Drizzle, MySQL 6.0'ın bir dalı olarak başladı. Daha sonra geliştiriciler, daha basit ve daha hızlı bir DBMS oluşturmak için bir dizi işlevi (görünümler, tetikleyiciler, derlenmiş ifadeler, depolanan prosedürler, sorgu önbelleği, ACL'ler ve bazı veri türleri dahil) kaldırdı. Bununla birlikte, Drizzle yine de ilişkisel verileri depolamak için kullanılabilir. Geliştiricilerin amacı, 16 veya daha fazla çekirdekli sistemler üzerinde çalışan web ve bulut uygulamaları için tasarlanmış yarı ilişkisel bir platform oluşturmaktır.

Karar

Sonuç olarak, uygulamanız için ilişkisel olmayan anahtar-değer depolamasını seçmenizin dört nedeni vardır:

1. Verileriniz büyük ölçüde belge odaklıdır ve ilişkisel bir veri modelinden çok bir anahtar-değer veri modeline daha uygundur.
2. Etki alanı modeliniz son derece nesne yönelimli olduğundan, anahtar-değer depolaması kullanmak, verileri dönüştürmek için ihtiyaç duyduğunuz ekstra kod miktarını azaltacaktır.
3. Veri ambarı ucuzdur ve satıcınızın web hizmetleriyle entegre edilmesi kolaydır.
4. Temel endişeniz, talep üzerine yüksek ölçeklenebilirliktir.

Ancak, kararınızı verirken, belirli veritabanlarının sınırlamalarını ve ilişkisel olmayan veritabanlarını kullanmayı seçerseniz karşılaşacağınız riskleri aklınızda bulundurun.

Diğer tüm gereksinimler için, eski güzel ilişkisel DBMS'yi seçmek daha iyidir. Öyleyse mahkum mu? Tabii ki değil. En azından şimdilik.

1 - Bence "veri yapısı" terimi burada daha uygun, ancak orijinal veri modelini bıraktı.
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ğunu kastetti.
3 - Veriler zaten güncelliğini yitirmiş olabilir, makale Şubat 2009 tarihli.

voldemort

çiselemek

Etiket ekle