Nesneye yönelik veri modeli. Nesneye yönelik veritabanı modeli

OOMD'de verileri sunarken bireysel veritabanı kayıtlarını tanımlamak mümkündür. Veritabanı kayıtları ile bunların işleme fonksiyonları arasında, nesne yönelimli programlama dillerindeki ilgili araçlara benzer mekanizmalar kullanılarak ilişkiler kurulur.

Standartlaştırılmış nesne yönelimli model, ODMG-93 standardının (Nesne Veritabanı Yönetim Grubu - nesne yönelimli veritabanı yönetim grubu) tavsiyelerinde açıklanmaktadır. ODMG-93'ün tavsiyelerinin tam olarak uygulanması henüz mümkün olmadı. Anahtar fikirleri açıklamak için, nesne yönelimli bir veritabanının biraz basitleştirilmiş bir modelini düşünün.

Nesne yönelimli bir veritabanının (OODB) yapısı, düğümleri nesneler olan bir ağaçla grafiksel olarak temsil edilir. Nesnelerin özellikleri bazı standart türlerle (örneğin dize) veya kullanıcı tarafından oluşturulan bir türle (sınıf olarak tanımlanır) tanımlanır.

String türündeki bir özelliğin değeri bir karakter dizisidir. Tür sınıfının bir özelliğinin değeri, karşılık gelen sınıfın örneği olan bir nesnedir. Bir sınıfın her örnek nesnesi, özellik olarak tanımlandığı nesnenin çocuğu olarak kabul edilir. Bir sınıfın örnek nesnesi kendi sınıfına aittir ve bir ebeveyni vardır. Veritabanındaki genel ilişkiler nesnelerin tutarlı bir hiyerarşisini oluşturur.

Bir kütüphanecilik OOBD'sinin mantıksal yapısının bir örneği Şekil 2'de gösterilmektedir. 2.8.

Burada LIBRARY türündeki bir nesne, SUBSCRIBER, DIRECTORY ve ISSUE sınıflarının örnek nesnelerinin ebeveynidir. BOOK türündeki farklı nesneler aynı veya farklı ebeveynlere sahip olabilir. Aynı üst öğeye sahip KİTAP türündeki nesneler, en azından envanter numarasına göre farklılık göstermelidir (kitabın her örneği için benzersizdir), ancak aynı özellik değerlerine sahip olmalıdır isbn, udk, başlık Ve yazar.

Pirinç. 2.8. Kütüphane bilimi veri tabanının mantıksal yapısı

OODB'nin mantıksal yapısı dışarıdan IDB'nin yapısına benzer. Aralarındaki temel fark, veri manipülasyon yöntemleridir.

Söz konusu veritabanı modelindeki veriler üzerinde eylemler gerçekleştirmek için şunu kullanın: mantıksal işlemler nesne yönelimli kapsülleme, kalıtım ve polimorfizm mekanizmalarıyla geliştirilmiştir. SQL komutlarına benzer işlemler (örneğin veritabanı oluşturmak için) sınırlı ölçüde kullanılabilir.

Bir veritabanının oluşturulması ve değiştirilmesine, hızlı veri alımı için bilgi içeren indekslerin (indeks tabloları) otomatik olarak oluşturulması ve ardından ayarlanması eşlik eder.

Nesne yönelimli veritabanı modeliyle ilişkili olarak kapsülleme, kalıtım ve polimorfizm kavramlarını kısaca ele alalım.

Kapsülleme Bir özellik adının kapsamını, içinde tanımlandığı nesnenin sınırlarıyla sınırlar. Yani, kitabın yazarının telefon numarasını belirten ve telefon adı verilen DIRECTORY türündeki bir nesneye bir özellik eklersek, ABONE ve DIRECTORY nesneleri için aynı isimli özellikler elde ederiz. Böyle bir özelliğin anlamı, içinde kapsüllendiği nesne tarafından belirlenecektir.

Miras, tam tersine, özelliğin kapsamını nesnenin tüm alt öğelerini kapsayacak şekilde genişletir. Böylece, DIRECTORY türündeki bir nesnenin soyundan gelen KİTAP türündeki tüm nesnelere ana nesnenin özellikleri atanabilir: isbn, udc, title ve yazar. Kalıtım mekanizmasının yakın akraba olmayan nesnelere (örneğin, aynı ebeveynin iki çocuğu arasında) genişletilmesi gerekiyorsa, bunların ortak atalarında abs türünde soyut bir özellik tanımlanır. Böylece, LIBRARY nesnesinde bilet ve sayı soyut özelliklerinin tanımlanması, bu özelliklerin SUBSCRIBER, BOOK ve ISSUE gibi tüm alt nesneler tarafından miras alınmasına yol açar. Mülkiyet değerlerinin olması tesadüf değildir. biletŞekilde gösterilen ABONE ve VERİLEN sınıfları aynı olacaktır - 00015.

Polimorfizm V nesne yönelimli programlama dilleri aynı program kodunun farklı veri türleriyle çalışabilmesi anlamına gelir. Başka bir deyişle, farklı türdeki nesnelerin aynı adlara sahip yöntemlere (prosedürler veya işlevlere) sahip olmasına izin verildiği anlamına gelir. Bir nesne programının yürütülmesi sırasında, argümanın türüne bağlı olarak aynı yöntemler farklı nesneler üzerinde çalışır. Nesne yönelimli veritabanımızla ilgili olarak polimorfizm, DIRECTORY sınıfından farklı ebeveynlere sahip BOOK sınıfı nesnelerinin farklı özelliklere sahip olabileceği anlamına gelir. Sonuç olarak, BOOK sınıfının nesneleriyle çalışan programlar polimorfik kod içerebilir.

Bir OODB'de arama, kullanıcı tarafından belirlenen bir nesne ile veritabanında saklanan nesneler arasındaki benzerliklerin bulunmasından oluşur. Hedef nesne adı verilen kullanıcı tanımlı bir nesne (bir nesnenin özelliği tipamaç), genel durumda, veritabanında depolanan nesnelerin hiyerarşisinin tamamının bir alt kümesi olabilir. Hedef nesne ve sorgunun sonucu veritabanının kendisinde saklanabilir. Kütüphaneden en az bir kitap alan abonelerin kütüphane kartı numaraları ve isimlerine ilişkin talep örneği Şekil 1'de gösterilmektedir. 2.9.

Pirinç. 2.9. Hedef nesneye sahip bir veritabanı parçası

Ana itibar OOMD, ilişkisel olanla karşılaştırıldığında, nesneler arasındaki karmaşık ilişkiler hakkındaki bilgileri görüntüleme yeteneğidir. OOMD, bireysel bir veritabanı kaydını tanımlamanıza ve bunları işlemek için işlevleri belirlemenize olanak tanır.

Ana eksiklikler OOMD, yüksek kavramsal karmaşıklık, uygunsuz veri işleme ve düşük hız istekleri yerine getirmek.

90'lı yıllarda OODBMS'in deneysel prototipleri vardı. Şu anda bu tür 300'den fazla DBMS bulunmaktadır. Bazı sistemler nispeten yaygınlaşmıştır, örneğin aşağıdaki DBMS: Cache (InterSystems), ROET (ROET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (ArdentSoftware), ODB-Jupiter (Inteltek Plus Research and Production) Merkezi) yanı sıra Iris, Orion ve Postgres.

OODB'nin gelecekteki avantajları çok geniş bir dağıtıma yol açacaktır. Bunu yapmak için, öncelikle OODB'nin doğasında olan eksiklikleri ortadan kaldıracak sorunları çözmeniz gerekir: veritabanı yapısının esnekliğini artırın, anlaşılır bir programlama dili oluşturun, sorgu ayrıştırma sözdizimini geliştirin, birkaç veri erişim yöntemini tanımlayın, eşzamanlı sorunları çözün erişim, karmaşık veri numaralandırmasını tanımlama, veri koruma ve kurtarma işlemlerini gerçekleştirme. Çözülmesi gereken sorunların listesine devam edilebilir.

Ancak bu sorunlar çözüldükten sonra bile OODB'ye geçiş kademeli olacak ve çok hızlı olmayacak çünkü mevcut çok sayıda ilişkisel DBMS'den nesnel ve öznel nedenlerden dolayı kopmak zor olacaktır. Böyle bir geçişi daha az acı verici kılmak, OODBMS'e yalnızca bir nesnenin değil aynı zamanda ilişkisel bir bileşenin de dahil edilmesi olacaktır. Ayrıca uygulamada giderek daha fazla talep gören OLAP veri ambarı sistemlerini oluşturmak için MMD'nin OODBMS'e dahil edilmesi gerekmektedir.

Nesneye yönelik bir modelde, verileri sunarken bireysel veritabanı kayıtlarını tanımlamak mümkündür. Kayıtlar ve bunların işleme işlevleri arasındaki ilişkiler, nesne yönelimli programlama dillerindeki ilgili araçlara benzer mekanizmalar kullanılarak kurulur.

Nesne yönelimli bir veritabanının basitleştirilmiş bir modelini ele alalım. Nesneye yönelik bir veritabanının yapısı, düğümleri nesneler olan bir ağaçla grafiksel olarak temsil edilir. Nesnelerin özellikleri bazı standart türlerle veya kullanıcı tarafından oluşturulan bir türle (sınıf olarak tanımlanır) tanımlanır. Tür sınıfının bir özelliğinin değeri, karşılık gelen sınıfın örneği olan bir nesnedir. Bir sınıfın her örnek nesnesi, özellik olarak tanımlandığı nesnenin çocuğu olarak kabul edilir. Bir sınıfın örnek nesnesi kendi sınıfına aittir ve bir ebeveyni vardır. Veritabanındaki genel ilişkiler nesnelerin tutarlı bir hiyerarşisini oluşturur. Nesneye yönelik bir kütüphane bilimi veri tabanının mantıksal yapısının bir örneği Şekil 2'de gösterilmektedir. 2.9. Burada, Kitaplık türündeki bir nesne, Abone, Dizin ve Sayı sınıflarının örnek nesnelerinin üst öğesidir. Kitap türündeki farklı nesneler aynı veya farklı ebeveynlere sahip olabilir. Aynı ebeveyne sahip Kitap türündeki nesneler, en azından erişim numarası bakımından farklı olmalıdır (kitabın her örneği için benzersizdir), ancak isbn, udc, title ve yazar özellikleri için aynı değerlere sahip olmalıdır.

Nesneye yönelik bir veritabanının mantıksal yapısı yüzeysel olarak hiyerarşik bir veritabanının yapısına benzer. Aralarındaki temel fark veri işleme yöntemleridir.

Söz konusu veritabanı modelindeki veriler üzerinde eylemler gerçekleştirmek için nesne yönelimli kapsülleme, kalıtım ve polimorfizm mekanizmalarıyla geliştirilmiş mantıksal işlemler kullanılır.

Kapsülleme Bir özellik adının kapsamını, içinde tanımlandığı nesnenin sınırlarıyla sınırlar. Miras aksine, özelliğin kapsamını nesnenin tüm alt öğelerini kapsayacak şekilde genişletir.

Polimorfizm nesne yönelimli programlama dillerinde aynı program kodunun farklı veri türleriyle çalışabilmesi anlamına gelir. Bir başka ifadeyle nesnelerde caizlik anlamına gelir. farklı şekiller aynı adlara sahip yöntemlere (prosedürler veya işlevler) sahiptir. Nesneye yönelik bir veritabanında arama yapmak, kullanıcı tarafından belirlenen bir nesne ile veritabanında saklanan nesneler arasındaki benzerlikleri bulmayı içerir.

Nesne yönelimli veri modelinin ilişkisel modele kıyasla temel avantajı, nesneler arasındaki karmaşık ilişkiler hakkındaki bilgileri görüntüleme yeteneğidir. Nesne yönelimli bir veri modeli, bireysel veritabanı kayıtlarını tanımlamanıza ve bunları işlemek için işlevler tanımlamanıza olanak tanır.

Nesneye yönelik modelin dezavantajları yüksek kavramsal karmaşıklık, uygun olmayan veri işleme ve düşük sorgulama hızıdır.

Nesne yönelimli DBMS'ler arasında POET, Jasmine, Versant, O 2, ODB - Jüpiter, Iris, Orion, Postgres bulunur.

Nesneye yönelik bir modelde (OOM), verileri sunarken bireysel veritabanı kayıtlarını tanımlamak mümkündür. Veritabanı kayıtları ile bunların işleme fonksiyonları arasında, nesne yönelimli programlama dillerindeki ilgili olanaklara benzer mekanizmalar kullanılarak ilişkiler kurulur.

Standart OOM, ODMG-93 standardının (Nesne Veritabanı Yönetim Grubu - nesne yönelimli veritabanı yönetim grubu) tavsiyelerinde açıklanmaktadır. ODMG-93'ün tavsiyelerinin tam olarak uygulanması henüz mümkün olmadı. Örnek için anahtar fikirler Nesneye yönelik bir veritabanının biraz basitleştirilmiş bir modelini ele alalım.

Nesneye yönelik bir veritabanının yapısı, düğümleri nesneler olan bir ağaç şeklinde grafiksel olarak temsil edilebilir. Nesnelerin özellikleri bazı standart türlerle (örneğin dize) veya kullanıcı tarafından oluşturulan bir türle (sınıf olarak tanımlanır) tanımlanır.

Kütüphanecilik OO veri tabanının mantıksal yapısının bir örneği Şekil 2'de gösterilmektedir. 3.14. Burada LIBRARY türündeki bir nesne, SUBSCRIBER, DIRECTORY ve ISSUE sınıflarının örnek nesnelerinin ebeveynidir. Aynı ebeveyne sahip KİTAP türündeki farklı nesneler, en azından erişim numarası bakımından farklı olmalıdır (kitabın her örneği için benzersizdir), ancak aynı özellik değerlerine sahip olmalıdır isbn, udk, başlık Ve yazar.

Şekil 3.14. Kütüphane bilimi veri tabanının mantıksal yapısı

Nesneye yönelik bir veritabanının mantıksal yapısı yüzeysel olarak hiyerarşik bir veritabanının yapısına benzer. Aralarındaki temel fark, veri manipülasyon yöntemleridir. Bir OOM veritabanındaki veriler üzerinde eylemler gerçekleştirmek için nesne yönelimli kapsülleme, kalıtım ve polimorfizm mekanizmalarıyla geliştirilmiş mantıksal işlemler kullanılır. SQL komutlarına benzer işlemler sınırlı ölçüde kullanılabilir (örneğin veritabanı oluşturmak için).

OOM veritabanlarıyla ilişkili olarak kapsülleme, kalıtım ve polimorfizm kavramlarını kısaca ele alalım.

Kapsülleme Bir özellik adının kapsamını, içinde tanımlandığı nesnenin sınırlarıyla sınırlar. Yani, DIRECTORY türündeki bir nesneye, kitabın yazarının telefon numarasını belirten ve adını taşıyan bir özellik eklerseniz telefon, daha sonra SUBSCRIBER ve DIRECTORY nesneleri için aynı isimli özellikleri elde edeceğiz. Böyle bir özelliğin anlamı, içinde kapsüllendiği nesne tarafından belirlenecektir.

Miras, tam tersine, özelliğin kapsamını nesnenin tüm alt öğelerini kapsayacak şekilde genişletir. Böylece, DIRECTORY türündeki bir nesnenin alt öğeleri olan KİTAP türündeki tüm nesnelere, ana nesnenin özellikleri atanabilir: isbn, udk, başlık Ve yazar. Kalıtım mekanizmasının yakın akraba olmayan nesnelere (örneğin, aynı ebeveynin iki çocuğu arasında) genişletilmesi gerekiyorsa, bunların ortak atalarında abs türünde soyut bir özellik tanımlanır. Böylece soyut özelliklerin tanımı bilet Ve sayı LIBRARY nesnesindeki bu özelliklerin tüm alt nesneler SUBSCRIBER, BOOK ve ISSUE tarafından miras alınmasına neden olur. Mülkiyet değerlerinin olması tesadüf değildir. biletŞekilde gösterilen ABONE ve VERİLEN sınıfları aynı olacaktır - 00015.

Polimorfizm nesne yönelimli programlama dillerinde aynı program kodunun farklı veri türleriyle çalışabilmesi anlamına gelir. Başka bir deyişle, farklı türdeki nesnelerin aynı adlara sahip yöntemlere (prosedürler veya işlevlere) sahip olmasına izin verildiği anlamına gelir. Bir nesne programının yürütülmesi sırasında, argümanın türüne bağlı olarak aynı yöntemler farklı nesneler üzerinde çalışır. Nesne yönelimli veritabanımızla ilgili olarak polimorfizm, DIRECTORY sınıfından farklı ebeveynlere sahip BOOK sınıfı nesnelerinin farklı özelliklere sahip olabileceği anlamına gelir. Sonuç olarak, BOOK sınıfının nesneleriyle çalışan programlar polimorfik kod içerebilir.

Nesneye yönelik bir veritabanında arama, kullanıcı tarafından belirlenen bir nesne ile veritabanında saklanan nesneler arasındaki benzerliklerin bulunmasından oluşur. Hedef nesne olarak adlandırılan kullanıcı tanımlı bir nesne (nesnenin özelliği hedef türündedir), genellikle veritabanında depolanan tüm nesneler hiyerarşisinin bir alt kümesi olabilir. Hedef nesne ve sorgunun sonucu veritabanının kendisinde saklanabilir. Kütüphaneden en az bir kitap alan abonelerin kütüphane kartı numaraları ve isimlerine ilişkin talep örneği Şekil 1'de gösterilmektedir. 3.15.

Ana itibarİlişkisel ile karşılaştırıldığında verilerin OOM'si, nesneler arasındaki karmaşık ilişkiler hakkındaki bilgileri görüntüleme yeteneğidir. Verilerin OOM'u, bireysel bir veritabanı kaydını tanımlamanıza ve bunları işlemek için işlevleri belirlemenize olanak tanır.

Dezavantaj OOM'lar, yüksek kavramsal karmaşıklık, veri işlemenin zorluğu ve düşük sorgu yürütme hızıyla karakterize edilir.

Şekil 3.15. Hedef nesneyi içeren veritabanı parçası

Şekil 2'de ilişkisel veri modeli şeklinde sunulan Siparişler görevine tekrar dönelim. 3.8 ve bunu nesne yönelimli bir veritabanı açısından düşünün. Örnekte üç sınıf var: “ Müşteriler», « Emirler" Ve " Mal" Sınıfın nesneleri " Müşteriler» belirli müşterilerdir; sınıf özellikleri - müşteri numarası, müşteri adı Şehir, Durum vb. Sınıf yöntemleri - " Sipariş oluştur», « Faturayı ödemek" ve benzeri. Yöntem, bir nesneye uygulanabilecek bazı işlemlerdir; yöntem, bir nesnenin yapması gereken şeydir. Tabloya karşılık gelen sınıf " sipariş detayları", gerekli değil. Tablo verileri sınıfın bir parçası olabilir " Emirler" Sınıfta kullanılabilirlik " Müşteriler" yöntem " Sipariş oluştur"sınıf nesneleri ile etkileşime yol açar" Emirler" Ve " Mal" Bu durumda kullanıcının nesnelerin bu etkileşimi hakkında bilgi sahibi olmasına gerek yoktur. Kullanıcı yalnızca nesneye erişir " Emirler" ve yöntemi kullanıyor " Sipariş oluştur" Diğer veritabanları üzerindeki etki gerçeği kullanıcıdan gizlenebilir. Eğer yöntem " Sipariş oluştur"sırasıyla yöntemi çağırır" Müşterinin kredi itibarını kontrol edin", o zaman bu gerçek kullanıcıdan da gizlenebilir. İlişkisel veritabanları, aynı işlevleri gerçekleştirmek için Visual Basic for Application'da (VBA) prosedürlerin yazılmasını gerektirir.

90'lı yıllarda OO veritabanı yönetim sistemlerinin deneysel prototipleri vardı. Şu anda bu tür sistemler yaygındır. Bunlar özellikle aşağıdaki DBMS'leri içerir: POET (POET Yazılımı), Jasmine (Bilgisayar Ortakları), Versant (Versant Technologies), O2 (Ardent Yazılımı), ODB-Jüpiter (Inteltek Plus Araştırma ve Üretim Merkezi) ve Iris , Orion ve Postgres.

04/06/2004 Sikha Bagui

Nesneye yönelik veritabanı sistemlerinin geliştirilmesi, ilişkisel veritabanı sistemlerinin sunduğu ve hizmet verdiği uygulama gereksinimlerinden farklı uygulama gereksinimlerinin karşılanması ihtiyacına yanıt olarak 1980'lerin ortalarında başladı. Nesne yönelimli veritabanı teknolojisinin ilişkisel veritabanı teknolojisi kadar yaygınlaşması için nesne yönelimli veritabanı teknolojisindeki gelişmelerin yanı sıra geliştirme topluluğunun hala aşması gereken zorluklara bakalım.

Nesneye yönelik veritabanı sistemlerinin (beşinci nesil veritabanı teknolojileri olarak adlandırılan) geliştirilmesi, ilişkisel veritabanı sistemlerinin karakteristiği olan veri işleme uygulamaları dışındaki uygulamaların gereksinimlerini karşılama ihtiyacı nedeniyle 1980'lerin ortalarında başlamıştır. dördüncü nesil veritabanı teknolojisi). Bilgisayar destekli tasarım (CAD) gibi karmaşık uygulamalarda ilişkisel veritabanı teknolojilerini kullanma girişimleri; bilgisayar destekli üretim (CAM); programlama teknolojisi; Bilgiye dayalı sistemler ve multimedya sistemleri sistemlerin sınırlamalarını ortaya çıkarmıştır. ilişkisel veritabanları (RDB). Yeni nesil veritabanı uygulamaları ortaya çıktıkça, en iyi şekilde veritabanı uygulamaları kullanılarak karşılanabilecek ihtiyaçlar ortaya çıktı. nesne yönelimli veritabanları (OODB).

Nesne yönelimli ve nesne yönelimli veritabanlarının birçok tanımı önerilmiştir, ancak nesne yönelimli veritabanlarını, nesne yönelimini veritabanı yetenekleriyle birleştirenler olarak tanımlayacağız. Nesne yönelimi Gerçek dünya problemlerini daha doğrudan temsil etmeyi ve modellemeyi mümkün kılar ve veritabanı işlevselliği veri istikrarını ve uygulama bilgilerine çok kullanıcılı paralel erişimi sağlamak için gereklidir.

Şu anda piyasada 25'in üzerinde OBD sistemi bulunmaktadır. Bunlar arasında Servio'nun GemStone sistemi, Ontos'un ONTOS'u, Object Design'ın ObjectStore'u ve diğerleri yer alıyor. Ayrıca Oracle, Microsoft, Borland ve Informix tarafından geliştirilen ilişkisel veritabanı yönetim sistemleri nesne yönelimli araçları da içeriyordu. Bu ürünlerin birçoğu 80'li yılların ikinci yarısında ortaya çıktı ve bugün neredeyse on beş yıllık bir geliştirme sürecinden sonra henüz olgunluğa ulaşmadılar; Gerçek uygulamalara yönelik dünya pazarının bugüne kadar OBD sistemlerini kabul etmekte acele etmemesinin nedenlerinden biri de budur. Modern OODB'ler arasında, modern ilişkisel veritabanı sistemleriyle karşılaştırılabilecek neredeyse hiçbir tam teşekküllü sistem yoktur. OBD'nin mevcut durumuyla ilgili ana başarıları ve sorunları tartışalım.

OBD modeli

Nesne yönelimli veritabanı sistemlerinin ortaya çıkmasının nedeni, OODB'lerin geleneksel olanlardan çok daha gelişmiş bir veri modeli sağlaması nedeniyle, gerçek dünya varlıklarının daha yeterli temsili ve modellenmesine duyulan ihtiyaçtı. ilişkisel veritabanları veri. OODB paradigması nesne, tanımlanabilirlik, sınıf, kalıtım, aşırı yükleme ve tembel bağlama gibi bir dizi temel kavrama dayanmaktadır.

Nesneye yönelik bir veri modelinde, gerçek dünyadaki herhangi bir varlık yalnızca tek bir kavramla temsil edilir: nesne. Bir nesnenin kendisiyle ilişkili bir durumu ve davranışı vardır. Bir nesnenin durumu, özelliklerinin değerlerine göre belirlenir - Öznitellikler. Özellik değerleri ilkel değerler (dizeler veya tamsayılar gibi) ve ilkel olmayan nesneler olabilir. İlkel olmayan bir nesne ise bir dizi özellikten oluşur. Bu nedenle nesneler, diğer nesnelere göre yinelemeli olarak tanımlanabilir. Bir nesnenin davranışı kullanılarak belirlenir yöntemler, Bir nesnenin durumu üzerinde çalışan.

Her nesnenin sistem tanımlı bir özelliği vardır. benzersiz tanımlayıcı. Aynı özelliklere ve davranışa sahip nesneler gruplandırılır sınıflar. Bir nesne yalnızca bir sınıfın veya birkaç sınıfın örneği olabilir.

Sınıflar bir sınıf hiyerarşisine göre düzenlenir. Alt sınıf, üst sınıfın özelliklerini ve yöntemlerini miras alır; Ayrıca alt sınıfların bireysel özellikleri ve yöntemleri olabilir. ORION gibi bazı sistemlerde bir sınıfın birden fazla üst sınıfı olabilir. (çoklu miras) diğer sistemlerde üst sınıfların sayısı bir ile sınırlıdır (tek miras).

Çoğu model izin verir aşırı yükleme kalıtsal özellikler ve yöntemler. Aşırı yükleme, bir özellik etki alanını yeni bir etki alanıyla değiştirmekten veya bir yöntemin bir uygulamasını onun başka bir uygulamasıyla değiştirmekten oluşur.

OOBD modelinin avantajları

Nesneye yönelik veritabanları, karmaşık nesnelerin ilişkisel sistemlere göre daha doğrudan temsil edilmesine olanak tanır. OOBD alanındaki mevcut başarılardan bazılarına bakalım. OODB sistemleri kullanıcıların soyutlamaları tanımlamasına olanak tanır; bazı bağlantıların tasarımını kolaylaştırmak; kullanıcı tanımlı anahtarlara olan ihtiyacı ortadan kaldırır; yeni bir karşılaştırma yüklemleri kümesini desteklemek; bazı durumlarda bağlantı ihtiyacı ortadan kalkar; bazı durumlarda daha fazlasını sağlar yüksek performans ilişkisel modele dayalı sistemlerden; versiyonlar ve uzun süren işlemler için destek sağlayın. Son olarak nesne cebiri geliştirildi - her ne kadar henüz ilişkisel cebir kadar ayrıntılı olmasa da.

Özel Soyutlamaları Tanımlama

Nesneye yönelik veritabanları, yeni soyutlamalar tanımlama ve bu soyutlamaların uygulanmasını kontrol etme yeteneği sağlar. Bu yeni soyutlamalar, karmaşık problemlerde gerekli olan veri yapılarına, yeni soyut türleri veri. Başka bir deyişle, modern OODB paketleri kullanıcıya nitelikler ve yöntemler içeren yeni bir sınıf oluşturma, üst sınıflardan nitelik ve yöntemler devralan sınıflara sahip olma, her biri benzersiz bir nesne tanımlayıcıya sahip sınıfın örneklerini oluşturma, bu örnekleri tek tek alma yeteneği verir. bir veya gruplar halinde ve yöntemleri yükleyip yürütün. Ek olarak, OODB'ler nesnelerin diğer nesnelerin koleksiyonları olarak tanımlanmasına olanak tanır ve koleksiyonlar birden fazla düzeyde iç içe yerleştirmeye izin verir. Özellikler ayrıca karmaşık bir yapıya sahip olabilir ve koleksiyon yapıcısı kullanılarak tanımlanır. Dahası, değer olarak ilkel olmayan nesnelere sahip olabilirler, bu da derinlemesine iç içe geçmiş nesne yapılarının oluşturulmasını mümkün kılar.

Çok değerli özellikler, karmaşık veri yapılarını ifade etmek için nesne yönelimli veri modellerinde kullanılır. İlişkisel modelde bu, ek ilişkiler ve birleştirmeler aracılığıyla gerçekleştirilir.

Bahsedilen tüm yeteneklere sahip bir OODB paketi örneği ENCORE'dur. ENCORE'daki veri modeli öncelikle veri soyutlamasına dayanmaktadır. ENCORE, alt tiplemeye (kalıtım), kapsüllemeye, karmaşık yapılara, nesne tanımlamaya ve tembel yöntem bağlamaya olanak tanır. Ayrıca ENCORE, özellikleri kullanarak nesneleri bağlama yeteneği sağlar. ENCORE sisteminde, bir p özelliği, ilişkinin nasıl hesaplandığına dair herhangi bir gösterge olmaksızın, bir x nesnesini bir S nesneleri kümesiyle ilişkilendirir. Doğrudan küme tanımlayıcısı S'yi (veya üyelerinin tanımlayıcılarını) belirterek veya bir birleştirmede olduğu gibi diğer özelliklerin değerlerini eşleştirerek hesaplanabilir.

Bazı bağlantıların hafif tasarımı

Nesneye yönelik veritabanları, iki nesne arasındaki karşılıklı referansları (ikili ilişki) ifade etmek için ters ilişki olanağını destekler. Böyle bir sistem, ileri bağlantı oluşturulduktan hemen sonra uygun bir geri bağlantı kurarak referans bütünlüğünü sağlar. Kaldırma işlemlerini bu bağlantılar aracılığıyla otomatik olarak yayma seçeneği bile vardır. Ters ilişkilerin otomatik bakımını sağlayan bir OODB paketi örneği ObjectStore'dur.

Kullanıcı tanımlı tuşlara gerek yok

OODB modeli, sistem tarafından otomatik olarak oluşturulan ve her nesne için benzersiz olduğu garanti edilen nesne tanımlayıcıları konseptine sahiptir. Bu, OODB modelinin kullanıcı tanımlı anahtarlara olan ihtiyacı ortadan kaldırması gerçeğiyle birleştiğinde, nesne yönelimli veritabanlarına başka avantajlar sağlar. İlk olarak, nesne tanımlayıcısı uygulama tarafından değiştirilemez. İkincisi, bir nesnenin tanımlanabilirliği kavramı, nesneye nasıl erişildiğinden veya nesnenin tanımlayıcı verilerle nasıl modellendiğinden bağımsız olarak ayrı ve tutarlı bir kimlik kavramını gerektirir. Bu nedenle, farklı nesne tanımlayıcılara sahip iki nesne aynı değildir; bu durumda nesneler aynı yapıya sahip olabilir ve tüm özellikleri aynı değerlere sahip olabilir. Nesne tanımlamasının kullanıcı tanımlı anahtarlar aracılığıyla yapıldığı RDB modelinde bu tür nesneler aynı nesne olarak kabul edilecektir.

Karşılaştırma yüklemlerinin varlığı

RDB'de karşılaştırma her zaman yalnızca değerlere dayanır. Bu modelde, tüm anahtar nitelikleri aynı değerlere sahipse iki demet aynı varlıktır. Ancak OODB modelinde başka karşılaştırma türleri de geliştirilmiş ve tanımlanmıştır.

Nesnelerin kimliklerine göre eşitliği. İki nesne, S1 ve S2, eğer aynı nesne iseler (yani aynı nesne tanımlayıcısına sahiplerse) eşittirler.
Değerlere dayalı nesnelerin eşitliği. Bu iki adımda belirlenebilir - (a) aynı değere sahiplerse iki ilkel nesne eşittir; (b) ilkel olmayan iki nesne, eğer aynı sayıda özelliğe sahiplerse eşittirler ve S1 nesnesinin her bir pi özelliği için, S2 nesnesinin ona eşit değerde bir pj özelliği vardır.
Değere dayalı mülkiyet eşitliği.
Mülkiyetlerin kimliklerine göre eşitliği.

Bağlantılara daha az ihtiyaç

Nesne yapıları ve bunun sonucunda ortaya çıkan yol ifadeleri arasında nesne nitelikleri açısından gezinme yeteneği, bize OODB'deki bağlantı sorununa bakmamız için yeni bir yol sağlar. İlişkisel birleştirme, bu ilişkilerdeki karşılık gelen nitelik çiftlerinin değerlerine dayalı olarak iki ilişkiyi eşleştiren bir mekanizmadır. OODB'de iki sınıf karşılık gelen nitelik çiftlerine sahip olabileceğinden, bu modelde hala ilişkisel bir birleştirmeye (veya açık birleştirmeye) ihtiyaç duyulabilir. Örneğin Öğrenci ve Okul sınıflarımız olduğunu ve bu sınıfların her birinin Ad ve Yaş niteliklerine sahip olduğunu varsayalım. Her ne kadar Okul sınıfının Ad ve Yaş özniteliklerinin alanları, Öğrenci sınıfının Ad ve Yaş özniteliklerinin etki alanları ile aynı olmasa da, bu sınıfları bu özniteliklerin değerlerine göre ilişkilendirmek isteyebiliriz (örneğin, Yaşı öğrencinin gittiği okulun yaşından küçük olan tüm öğrencileri bul).

Ancak, daha önce de belirtildiği gibi, yol ifadelerini desteklemek, RDB'deki duruma kıyasla sınıfları bağlama ihtiyacını önemli ölçüde azaltabilir. İlişkisel birleştirme ihtiyacının tamamen ortadan kaldırılabileceği durumlar bile vardır. Örneğin, A sınıfı bir özniteliğin etki alanı B sınıfı olduğunda, başka bir sınıfın öznitelik değerleri olarak depolanan bazı sınıfların nesne tanımlayıcılarının getirilmesi, örtülü nesne birleştirme ihtiyacını ortadan kaldırır.

Bu nedenle, nesne yönelimli veritabanlarında, nesnelerin hiyerarşik olarak iç içe yerleştirilmesiyle oluşturulan örtülü birleştirmeler, açık birleştirmelerden farklıdır. İkincisi ilişkisel birleştirmelere benzer: iki nesne, nitelik değerleri veya nesne tanımlayıcıları ile açıkça karşılaştırılır. Ayrıca, tüm açık birleştirmeler (değerlerin veya tanımlayıcıların karşılaştırmasına dayalı olarak) ilişkisel bir sorgu dilinde ifade edilemez, çünkü bir RDB'de herhangi bir yüklem yalnızca atomik nitelikler içerebilir.

Performans Kazanımı

Modern OODB'ler, modern RDB'lerle karşılaştırıldığında tam donanımlı veritabanı sistemleri değildir; OODB'ler, onlara performans avantajları sağlayan çeşitli özelliklere sahiptir.

Bir OODB'de, etki alanı başka bir Y nesnesi olan bir X nesnesinin özniteliğinin değeri, Y nesnesinin tanımlayıcısıdır. Bu nedenle, bir uygulama X nesnesini zaten almışsa ve şimdi Y nesnesini almak istiyorsa, DBMS bunu alabilir. tanımlayıcısını bularak Y nesnesini bulun. Bu tanımlayıcı nesnenin fiziksel adresini temsil ediyorsa, o zaman bu nesne doğrudan çıkarılabilir; tanımlayıcının mantıksal bir adres olması durumunda, karşılık gelen karma tablosu öğesini bularak nesneyi bulur (sistemin, nesne tanımlayıcıyı fiziksel bir adresle eşleştiren bir karma tablosu tuttuğunu varsayarsak). Bir RDB'de bu o kadar kolay olmayabilir çünkü RDB nesne tanımlayıcılarını desteklemez.
OODB'nin performans avantajı sağlayan ikinci özelliği, çoğu OODB'de, bir nesne belleğe yüklendiğinde, o nesnede saklanan nesne tanımlayıcılarının bellek işaretçilerine dönüştürülmesidir. RDB'ler nesne tanımlayıcılarını saklamadığından, diğer tuple'lara yönelik bellek işaretçilerini depolayamazlar. Bellekte bulunan nesneler arasında gezinememe, RDB'lerin temel bir özelliğidir ve sonuçta ortaya çıkan performans düşüşü, yalnızca ara bellek miktarının artırılmasıyla telafi edilemez. Bu nedenle, belleğe yüklenen ilgili nesnelerde tekrar tekrar gezinmeyi içeren uygulamaları çalıştırırken, OODB'ler performans açısından RDB'lerden önemli ölçüde daha iyi performans gösterebilir.
Ayrıca OODB'ler indekslenmemiş olsa bile sıralı tarama ile nesne yapısına uyan rastgele sorgulamaların yapılması uygun olabilir; nesneler arasında referans yollarını kullanın. Bir istek, bağlantılar tarafından desteklenmeyen bir yönde formüle edildiğinde, bu istek sıralı tarama ile işlenir. Ancak doğrudan referanslarla modellenmeyen nesne ilişkilerine dayalı olarak formüle edilen sorgular verimsiz performans gösterir.

Sürümler ve uzun süren işlemler için destek

RDB, sürüm oluşturmayı veya uzun süreli işlemleri desteklemez. Bu tür bir destek, sınırlı yeteneklere sahip olmasına rağmen bazı OODB'lerde mevcuttur.

Nesne cebiri

Nesne cebiri ilişkisel cebir kadar ayrıntılı veya olgun değildir. Ancak ne olursa olsun böyle bir cebir mevcuttur ve nesneleri koruyan beş temel işlemi tanımlar: birleştirme, fark, seçme, oluşturma ve haritalama. Bu temel işlemlere dayanarak kesişim gibi diğer işlemler de tanımlanabilir. Denkliği korurken nesne cebir ifadelerinin mantıksal optimizasyonuna yönelik dönüşüm kuralları ve'de türetilir. Birleşim, fark ve harita işlemleri öncelikle bire bir eşleme üretirken, seçme ve oluşturma işlemleri bire çok eşleme üretir. Nesne kalıcılığı, cebirsel işlemlerin önceden tanımlanmış veritabanı sınıflarına ait olan nesneleri döndürmesi ve yeni nesneler yaratmaması anlamına gelir. Birleşim operatörü, P kümesinde veya Q kümesinde veya her iki kümede bulunan nesneleri döndürür. Fark operatörü, P kümesine ait olan ancak Q kümesine ait olmayan nesnelerin bir kümesini döndürür. select, girilen kümenin bir alt kümesini döndürür. created girdi kümesine ait olanlardan nesneler üretir. harita, bir yöntem dizisinin her uygulamasından kaynaklanan nesnelerin kümesini döndürür.

OOBD modelinin dezavantajları

Nesneye yönelik yöntemlerin veritabanı teknolojisinin bir tür kuantum sıçraması yapmasına olanak sağlaması bekleniyordu. Ancak yukarıda belirtilen başarılara rağmen OBD'nin bu alandaki durum üzerinde önemli bir etkisi olmamıştır. Hem modelin hem de OOBD teknolojisinin hala zayıf yönleri var.

Nesneye yönelik veritabanları, veritabanı sistemi kullanıcılarının alışık olduğu ve dolayısıyla görmeyi beklediği temel özelliklerden yoksundur. Diğer hususların yanı sıra şunları not edebiliriz: RDB ile OODB arasında birlikte çalışabilirlik eksikliği; minimum sorgu optimizasyonu; standart sorgu cebirinin eksikliği; talepleri destekleyecek araçların eksikliği; görüşlere destek eksikliği; güvenlik sorunları; sınıf tanımlarındaki dinamik değişikliklere yönelik destek eksikliği; bütünlük kısıtlamaları için sınırlı destek; sınırlı performans ayarlama seçenekleri; karmaşık nesneler için yetersiz destek; mevcut nesne yönelimli programlama sistemleriyle sınırlı entegrasyon; sınırlı performans kazancı.

RDB ve OODB arasında birlikte çalışabilirlik eksikliği

OODB'nin veritabanı pazarında önemli bir etkiye sahip olması için bir takım koşulların karşılanması gerekir.

OODB'yi, RDB ile yeterince uyumlu, tam donanımlı veritabanı sistemlerine dönüştürün. Mevcut ve yeni ürünlerin bir arada var olmasını sağlamak için bazı geçiş yollarına ihtiyaç duyulmaktadır. yumuşak bir geçiş birinciden ikinciye.
Uygulama geliştirme araçları ve nesne yönelimli veritabanlarına erişim araçları sunun.
RDB ve OODB mimarilerini birleştirin.
RDB ve OODB veri modellerini birleştirin.

Sorguları optimize etmek için yetersiz araçlar

OODB'deki en önemli sorunlardan biri bildirimsel sorguların optimizasyonudur. OODB sorgularının optimize edilmesi, nesne yönelimli veri modelinin ek karmaşıklığı nedeniyle daha da zorlaşmaktadır. Bu ek karmaşıklık bir dizi faktörden kaynaklanmaktadır.

Kullanıcıların yeni türleri ve sınıfları devralma kullanarak tanımlama yeteneği, sorgu optimizasyonunu hem daha kolay hem de daha zor hale getirir. Bu özelliğin optimizasyona yardımcı olduğu bir örnek, Çalışanlar ve Denetçiler kümelerinin kesişimini içeren bir sorgudur. Çalışan, Süpervizörün bir üst sınıfıysa, optimize edici, Süpervizörlerin, Çalışanların kendi alt kümesi olduğunu varsayabilir ve belirlenen kesişim prosedürünü basitleştirebilir. Ek veri türlerinin optimizasyon seçeneklerini sınırladığı bir örnek, Öğrenciler ve Çalışanlar kümelerinin birleşimidir; Her iki sınıfın da üst sınıfı Person sınıfıdır. Tüm öğrenci ve çalışan süpervizörlerini bulmak istiyorsak, önce join işlemini yapar ve süpervizör() işlevini kullanırdık.
Sorgular koleksiyonlardaki işlemlere dayalı olabilir, ancak kümeleri (veya çoklu kümeleri veya listeleri vb.) etkileyen optimizasyon türleri, bu kümelerde bulunan nesne türlerine ilişkin optimizasyonla birleştirilmelidir. Nesne yönelimli bir sorgu iyileştiricinin, farklı türdeki nesneler arasındaki ilişkileri hesaba katan optimizasyon rutinlerinin yanı sıra, belirli türlere özel optimizasyon rutinlerini uygulayabilmesi gerekir.
OODB'de sorgu işlemenin karmaşıklığı, karmaşık nesnelerin, yöntemlerin ve kapsüllemenin varlığıyla birleşir. Karmaşık nesneler, sorgu işlemeyi daha karmaşık hale getiren yol ifadeleri oluşturur. Özellikle ifadeler rastgele yöntemler içerdiğinde, yol ifadelerinde dizinler oluşturmak, sorgu işlemeyi karmaşık hale getirir. Yöntemlerin yan etkileri varsa sorun daha da karmaşıklaşır. Yol ifadeleriyle ilgili diğer bir sorun, yol ifade yöntemlerinin çağrıldığı bir sıra dayatmaları ve bu sıranın oldukça verimsiz olabilmesidir. Örneğin, Order.part.name yol ifadesi, çok sayıda Sipariş ve az Parça varsa sağdan sola doğru daha iyi değerlendirilir, ancak çok sayıda parça ve az sipariş varsa ifade soldan sağa daha iyi değerlendirilir. Ayrıca bazen yol ifadeleri Birleştirme kullanılarak daha verimli şekilde işlenir. Örneğin, s.comp.name yol ifadesine sahip bir sorgu düşünün; burada s, Öğrenciler kümesine aittir. İlk önce her Şirketin Adını hesaplamak ve sonucu bir demet içinde depolamak (şirket sayısı küçükse) daha verimli olabilir. Daha sonra öğrenciden şirket adına kadar olan ifadenin değerlendirilmesi, öğrenci sınıfının comp özelliğini bazı tuple'ların Company özniteliğinin değeriyle eşleştirerek Students setini bir tuple kümesine birleştirmeyi içerecektir.
OODB sorgu dilleri, optimizasyon sürecini yine önemli ölçüde karmaşıklaştırabilecek iç içe geçmiş yapıların kullanımını destekler. yerel sorun sorgu ifadesinin tamamının küresel bilgisi gerektiğinden küresel bir soruna dönüştürmek.
Nesneler tanımlanabilir olduğunda, iki nesnenin eşitliğinden ne kastedildiği sorusu ortaya çıkar. Bu sorun, yüklemlerde eşitlik karşılaştırma operatörlerinin kullanıldığı ve bir sorgu yürütülürken yeni nesneler oluşturmaya ilişkin kararların alınması gereken dillere de yansır. Nesneye yönelik bir model iyileştirici, yeni nesnelerin yaratılmasıyla ve alternatif eşitlik tanımlarıyla ilgili sorunlarla başa çıkabilmelidir.

Bu sorunlar, nesne yönelimli sorguların optimize edilmesinin son derece zorlu olduğunu ve hala bir araştırma alanı olduğunu göstermektedir. Günümüzün nesne yönelimli veritabanı sistemleri oldukça basit optimizasyon stratejileri sunmaktadır. Bağlantıları optimize etme sorunu da daha fazla dikkat gerektirir.

Standart sorgu cebirinin eksikliği

OODB'nin bir diğer ciddi dezavantajı ise sorgu cebiri standartlarının olmayışıdır. Bu durum sorguların optimizasyonunu da zorlaştırmaktadır. OODB için cebir ve hesaplamaya dayalı birkaç farklı resmi sorgulama dili önerilmiştir. Bu cebirler ve hesaplamalar, hem ifade açısından hem de yeniden yazma kurallarını optimize etme desteği açısından çeşitli açılardan farklılık gösterir. Bu cebirlerin neredeyse tamamı değişkenlere dayanmaktadır; ara sonuçları depolamak için değişkenleri kullanın. OBD paketlerinden biri olan KOLA tamamen işlevsel bir üründür; değişkenleri kullanmaz. Yazar, KOLA cebirinin daha güçlü kural sistemlerinin inşasına izin vermesinin tam olarak değişkenlerin yokluğundan kaynaklandığını iddia ediyor.

RDB'de cebirsel işlemler ile düşük seviyeli fiziksel sistem temelleri arasında yakın bir yazışma vardır. Bu sıkı yazışma, ilişkiler ve dosyalar arasındaki ve demetler ve kayıtlar arasındaki eşlemeler yoluyla elde edilir. Ancak OODB'de nesne cebiri işlemleri ile fiziksel sistemlerin ilkelleri arasında benzer bir sezgisel yazışma yoktur. Yürütme planı oluşturmayı tartışırken, her şeyden önce düşük seviyeli nesne manipülasyon temellerini tanımlamak da gereklidir.

Sorgu desteği eksikliği

Çoğu OODB'de sorgu desteği yoktur. Yeterli olanaklara sahip az sayıda sistemde sorgulama dili ANSI SQL ile uyumlu değildir. Bu sorgu destek araçları arasında iç içe geçmiş alt sorgular, kümeli sorgular (birleşim, kesişim, fark), toplama işlevleri ve GROUP BY, çeşitli sınıfların birleşimidir; yetenekler RDB'de tam olarak desteklenir.

Ek olarak, nesne sorguları için bir standart yoktur, ancak bir nesne dili olan SQL'in geliştirilmesine yönelik girişimlerde bulunulduğunu da söylemek gerekir. SQL3'ün birkaç yıl gecikmesi muhtemeldir.

Görüş desteği eksikliği

OODB görünümleri desteklemez. Bu konuda çeşitli öneriler ortaya atılmış olmasına rağmen OODB'de görüş mekanizmasının nasıl çalışması gerektiği konusunda fikir birliğine varılamamıştır. Nesneye yönelik bir gösterim mekanizmasının geliştirilmesi, nesnenin tanımlanabilirliği gibi model özellikleri nedeniyle karmaşık hale gelir. Görünümdeki bir nesnenin tanımlayıcısı nedir? Öte yandan, verileri ve mirası kapsülleme yeteneğinin, görüşlerin açık tanımlarından kaçınmayı mümkün kıldığına dair bir görüş de vardır.

Güvenlik sorunları

RDB'ler yetkilendirmeyi desteklerken çoğu OODB desteklemez. RDB'ler, kullanıcıların ilişkilerdeki ve görünümlerdeki tanımları ve kayıtları okuma veya değiştirme haklarını vermelerine ve iptal etmelerine olanak tanır. OODB'ler ancak bu işlevselliğin geliştirilmesiyle iş dünyasında daha da yaygınlaşabilecektir.

Bazı OODB sistemleri, kullanıcıların kilitleri açıkça ayarlamasını ve serbest bırakmasını gerektirir. RDB sistemleri, kullanıcı sorgularını ve güncelleme bildirimlerini işlerken kilitleri otomatik olarak ayarlar ve serbest bırakır.

Sınıf tanımlarında dinamik değişikliklere yönelik destek eksikliği

OODB için henüz tek bir standart veri modeli geliştirilmemiş olmasının yanı sıra çoğu OODB, bir sınıfa yeni bir nitelik veya yöntem eklenmesi, bir sınıfa yeni bir üst sınıf eklenmesi gibi veritabanı şemasında dinamik değişiklikler yapılmasına izin vermemektedir. , bir sınıfın üst sınıfını silmek, yeni sınıf eklemek ve sınıfı silmek. RDB'ler kullanıcının ALTER komutunu kullanarak veritabanı şemasını dinamik olarak değiştirmesine olanak tanır; bir ilişkiye yeni bir sütun eklenebilir, bir ilişki silinebilir ve bazı durumlarda bir ilişkiden bir sütunun çıkarılması mümkündür.

Çoğu OODB ayrıca sınıf genişletmelerinin otomatik kontrolünden de yoksundur. Eğer sınıf uzantısı gerekiyorsa, kullanıcı bunun için bir koleksiyon tanımlamalı ve tüm ekleme ve silme işlemlerinin koleksiyona zamanında kaydedilmesini sağlamalıdır.

Bütünlük kısıtlamaları için sınırlı destek

Niteliklerin temel özelliklerini bildirmek için hiçbir mekanizma yoktur (örneğin, bir sınıf niteliği bildirilemez) birincil anahtar sınıf) veya benzersizlik kısıtlamaları, açık bütünlük kısıtlamaları ve yöntem ön ve son koşulları. Bunların hepsi yöntemler kullanılarak yapılabilse de, açık kısıtlamalar daha kullanıcı dostu olacak, daha az hata üretecek ve daha test edilebilir ve değiştirilebilir olacaktır.

Sınırlı performans ayarlama seçenekleri

Çoğu OODB, yalnızca sınırlı parametreli performans ayarlama araçları sağlar. RDB'de kurulumculara, sistem yöneticisi tarafından belirlenen çok sayıda parametreyi belirterek sistem performansını özelleştirme fırsatı verilir. Bu parametreler, bellek arabelleklerinin sayısını, boyutunu içerir. boş alan, gelecekte veri eklemek vb. için veri sayfasında ayrılmıştır. .

Karmaşık nesneler için yetersiz destek

Karmaşık nesnelerin tam işlevselliği hâlâ desteklenmemektedir. Bu bağlantıları kullanarak bağlantılarda gezinebilir ve işlemleri kodlayabilirsiniz, ancak farklı türde bağlantı semantiğini kullanan önceden tanımlanmış genel işlemler yoktur. Tüm referansların bağımsız nesnelere işaret ettiği varsayılır ve karmaşık nesneler içindeki özel ilişkilerin semantiği, kullanıcı tarafından sağlanan işlemlerde gizlenir.

Nesne yönelimli programlama sistemleriyle sınırlı entegrasyon

Kararlı verileri yönetmek için nesne yönelimli programları yeniden yazmak zordur. Burada bir dizi sorun ortaya çıkıyor: isim çatışmaları; sınıf hiyerarşilerini yeniden düzenleme ihtiyacı; OODB'nin sistem operasyonlarını aşırı yükleme eğilimi.

Sınırlı performans kazancı

Tüm veritabanı uygulamalarının yalnızca nesne tanımlayıcılar aracılığıyla veritabanı nesnelerini araması ve işaretçileri kullanarak ana bellekteki nesneleri hızlı bir şekilde yönetmesi gerekiyorsa, o zaman OODB'ler aslında RDB'lerden iki ila üç kat daha iyi performans gösterirdi. Ancak, nesnelere tanımlayıcılar aracılığıyla erişim gerektiren çoğu uygulama aynı zamanda RDB tarafından sağlanan veritabanı erişimi ve güncelleme yeteneklerine de ihtiyaç duyar. Bu özellikler arasında toplu veritabanı yükleme; tek tek nesnelerin oluşturulması, güncellenmesi ve silinmesi (birer birer); sınıftan belirli arama koşullarını karşılayan bir veya daha fazla nesnenin alınması; birkaç sınıfı bağlamak; işlemlerin kaydedilmesi vb. Bu tür uygulamaları çalıştırırken OODB'ler RDB'lere göre herhangi bir performans avantajı sunmaz.

Henüz OODB'de desteklenmeyen özellikler aynı zamanda tetikleyicileri, meta veri kontrollerini ve UNIQUE ve NULL gibi bütünlük kısıtlamalarını da içerir.

***

Bu zayıflıklar nedeniyle OODB'ler beklentilerini karşılayamadı: hedef uygulamaların arzuladığı tüm önemli özellikleri sağlamak. Çoğunluğa uygulanabilir modern sistemler"OOBD" terimi yanlış kullanılıyor. Hemen hemen tüm modern OODB'ler, bazı nesne yönelimli programlama dilleri için kararlı veri depolama sistemleri kadar veritabanı sistemleri değildir. Dolayısıyla nesne yönelimli veri modeli birçok açıdan ilişkisel modelden daha zengin olmasına rağmen nesne yönelimli model henüz tam olarak olgunluğa ulaşmamıştır. Günümüzde OOBD sistemlerinde avantajlardan çok dezavantajların olduğu açıkça görülmektedir.

Edebiyat

S. Abiteboul, A. Bonner, “Nesneler ve görünümler.” ACM SIGMOD Dış. Konf. Verilerin Yönetimi Üzerine, 1991.
M. Atkinson ve diğerleri, "Nesneye Dayalı Veritabanı Sistemi Manifestosu." Nesneye Dayalı Bir Veritabanı Sistemi Oluşturmak: O2'nin Hikayesi. Morgan Kaufman, 1992.
F. Bancilhon, “Nesneye yönelik veritabanı sistemleri.” 7. ACM SIGART/SIGMOD Konf., 1988.
J. Banerjee ve diğerleri, "Nesneye yönelik uygulamalar için veri modeli sorunları." ACM Trans. Ofis Bilgi Sistemleri Üzerine, Ocak 1987.
J. Banerjee, W. Kim, K.C. Kim, “Nesne yönelimli veritabanlarında sorgulamalar.” IEEE Veri Mühendisliği Konf., Şubat. 1988.
D. Beech, "Evrimin temeli ve nesne veritabanlarıyla ilişkisel." Proc. Genişletilmiş Veri Tabanı Teknolojisi, Mart. 1988.
E. Bertino, M. Negri, G. Pelagatti, L. Sbattella, "Nesneye Dayalı Sorgu Dilleri: Kavram ve Sorunlar." Bilgi ve Veri Mühendisliğine İlişkin IEEE İşlemleri, Mart. 1992.
A.W. Brown, Nesneye Dayalı Veritabanları, Yazılım Mühendisliğinde Uygulamalar. New York: McGraw-Hill, 1991.
R.G.G. Cattell, Nesne Veri Yönetimi, Nesneye Dayalı ve Genişletilmiş İlişkisel Veritabanı Sistemleri. Addison-Wesley, 1991.
M. Cherniack, "Fonksiyon(lar) Üzerinden Form(lar): KOLA Sorgu Cebiri." Teknik Rapor, Brown Üniversitesi, Aralık. 1995.
S. Cluet ve diğerleri, "Nesne yönelimli bir veritabanı sistemi için Reloop, Cebir tabanlı sorgulama dili." 1. Uluslararası Konf. Tümdengelimli ve Nesneye Yönelik Veritabanları Üzerine, Aralık. 1989.
EĞER. Cruz, DOODLE: Nesne yönelimli veritabanları için görsel dil. ACM SIGMOD Dış. Konf. Verilerin Yönetimi Üzerine, 1992.
U. Dayal, “Nesne yönelimli veri modelinde sorgular ve görünümler.” 2. Uluslararası İş. Veritabanı Programlama Dilleri Üzerine, Haziran 1989.
K.A. Dittrich, K.R. Dittrich, "Nesneye Yönelik DBMS'lerin Daha İyi Yapması Gereken Yer: Erken Deneyimlere Dayalı Bir Eleştiri." Modern Veritabanı Sistemleri: Nesne Modeli, Birlikte Çalışabilirlik ve Ötesi, ACM Press, Addison Wesley, 1995.
U. Erlingsson, "Nesne Odaklı Sorgu Optimizasyonu", yayınlanmamış taslak.
L. Fegaras, D. Maier, "Nesne Sorgulama Dilleri için Etkili Bir Hesaplamaya Doğru." ACM SIGMOD Dış. Konf. Veri Yönetimi Hakkında, San Jose, Kaliforniya, Mayıs 1995.
L. Fegaras, D. Maier, T. Sheard, "Yansıtıcı Bir Çerçevede Kural Tabanlı Sorgu Optimize Edicilerin Belirlenmesi." 3. Uluslararası Konf. Tümdengelimli ve Nesneye Yönelik Veritabanları üzerine, Phoenix, Arizona, Aralık. 1993.
S. Heiler, S. Zdonik, "Nesne Görünümleri: Vizyonu genişletmek." 6. Uluslararası Konf. Veri Mühendisliği Üzerine, 1990.
J.G. Hughes, Nesneye Yönelik Veritabanları. New York: Prentice-Hall, 1991.
S. Khoshafian, “Nesneye Dayalı Veritabanlarına Bakış.” Bilgi ve Yazılım Teknolojisi, Nisan. 1990.
S. Khoshafian, Nesneye Dayalı Veritabanları, New York: John Wiley & Sons, 1993.
S. Khoshafian, G. Copeland, “Nesne kimliği.” 1. Uluslararası Konf. Nesneye Dayalı Programlama Sistemleri, Diller ve Uygulamalar Üzerine, Ekim 2015. 1986.
W. Kim, “Nesne yönelimli veritabanlarının temeli.” MM Tek. Temsilci, N. ACA-ST-248-88, Ağustos. 1988.
W. Kim, Nesneye Dayalı Veritabanlarına Giriş. MIT Press, 1991.
W. Kim, "Nesneye Dayalı Veritabanı Sistemleri: Vaatler, Gerçeklik ve Gelecek." Modern Veritabanı Sistemleri: Nesne Modeli, Birlikte Çalışabilirlik ve Ötesi, ACM Press, Addison Wesley, 1995.
T.W. Leung ve diğerleri, "Aqua Veri Modeli ve Cebir." Teknik Rapor CS-93-09, Brown Üniversitesi, Mart. 1993.
G. Mitchell, S.B. Zdonik, U. Dayal, “Nesneye Dayalı Sorgu Optimizasyonu - Sorun Nedir?” Teknik Rapor CS-91-41, Brown Üniversitesi, Haziran 1991.
E.A. Rudensteiner, "Çoklu Görüntüleme: Nesne yönelimli veritabanlarında birden çok görünümü desteklemeye yönelik metodoloji." 18. Uluslararası Konf. Çok Büyük Veritabanlarında, 1992.
M. Scholl, H. Schek, “İlişkisel nesne modeli.” 3. Uluslararası Konf. Veritabanı Teorisi Üzerine, LNCS, cilt. 470, Springer Verlag, 1990.
P.G. Selinger ve diğerleri, "İlişkisel bir veritabanı yönetim sisteminde erişim yolu seçimi." ACM SIGMOD Dış. Konf. Verilerin Yönetimi Üzerine, 1979.
M. Stefik, D.G. Bobrow, "Nesneye yönelik programlama: Temalar ve varyasyonlar." AI Mag., Ocak. 1986.
M. Stonebraker ve diğerleri, “Üçüncü Nesil Veri Tabanı Sistemi Manifestosu.” Gelişmiş DBMS İşlevi Komitesi, Kaliforniya Üniversitesi, Berkeley, 1990.
D.D. Straube, M.T. Özsu, “Nesneye yönelik veritabanı sistemlerinde sorgulama ve sorgu işleme.” Bilgi Sistemlerine İlişkin ACM İşlemleri, Ekim. 1990.
D.D. Straube, M.T. Özsu, “Nesneye Yönelik Veri Modeli İçin Yürütme Planı Oluşturma.” 2. Uluslararası Konf. Tümdengelimli ve Nesneye Dayalı Veritabanları üzerine, Münih, Almanya, Aralık. 1991.
S.Y.W. Su, M. Guo, H. Lam, "İlişkilendirme Cebiri: Nesneye Dayalı Veritabanlarının Matematiksel Temeli." Bilgi ve Veri Mühendisliğine İlişkin IEEE İşlemleri, Ekim 2017. 1993.
S.B. Zdonik, D. Maier, eds., Nesneye Dayalı Veritabanı Sistemlerinde Okumalar, Morgan Kauffman, 1989.
S.B. Zdonik, P. Wegner, “Nesneye Dayalı Veritabanı Ortamları için Dil ve Metodoloji.” Hawaii Uluslararası Konf. Sistem Bilimleri üzerine, Ocak. 1986.

Sikha Bagui([e-posta korumalı]) West Florida Üniversitesi Bilgisayar Bilimleri Bölümü'nde öğretim görevlisidir. Veritabanları üzerine üç kitabın ortak yazarı: SQL Öğrenme: Oracle'ı Kullanarak Adım Adım Kılavuz, SQL Öğrenme: Access Kullanarak Adım Adım Kılavuz (Addison Wesley) ve Varlık İlişki Diyagramlarını Kullanarak Veritabanı Tasarımı (CRC Press) .

Sikha Bagui tarafından Journal of Object Technology (JOT), cilt. 2, hayır. 4, Temmuz-Ağustos 2003, sayfa 29-41. Orijinal yayıncının özel izniyle Otkrytye Systemy için Rusçaya çevrilmiştir. Telif hakkı JOT, 2003. Orijinal makale: http://www.jot.fm/issues/issue_2003_07/column2.

Çeviri editöründen

OBD - olgunluk mu yoksa düşüş mü?

Sergey Kuznetsov

Geçtiğimiz birkaç yılda nesne yönelimli veri tabanı alanında çarpıcı bir durgunluk yaşandı; bazıları bunu teknolojinin gerilemesi, bazıları ise teknolojinin olgun ve istikrarlı bir duruma geçişi olarak algılama eğiliminde. Benim gözlemlerime göre bu tür bir durgunluk bazen BT'ye yakın olan ancak veri tabanı uzmanı olmayan kişiler arasında yanılgıların ve hatta mitlerin ortaya çıkmasına neden oluyor. Bu yanılgılardan biri, kişinin kafasındaki terimler kümesini (nesne, nitelik, yöntem, sınıf, kalıtım vb.) genel kabul görmüş nesne yönelimli bir veri modeli olarak almasıdır.

Bu, Sikha Bagui'nin oldukça sıradan bir makalesinin çevirisini yayınlama kararımızı açıklıyor. Böyle bir yayın, en azından bu durgunluğu kesintiye uğratması ve her şeyden önce, OOBD alanının yalnızca bir olgunluk dönemine girmediğini, aynı zamanda aynı noktada birleşmiş heterojen ve karışık fikirlerin bir kümesi olarak kalmaya devam ettiğini göstermesi bakımından haklıdır. teknolojiden ziyade sloganların düzeyi.

Makale, nesne yönelimli veritabanlarına ayrılmış ve 1986-1995 döneminde yayınlanmış 36 yayının analizine dayanmaktadır. Bu nedenle “modern” OODB'nin sıklıkla kullanılan özelliği tamamen adil değildir. Bazen şimdiki zamanda verilen alıntılar bazen oldukça şüpheli görünebilir.

Elbette çok sayıda kaynak farklı terminoloji kullanıyor ve bu bağlamdaki incelemeleri son derece çeşitlidir. Ek olarak, makalelerin çoğu teknik açıdan oldukça karmaşıktır ve bağlam sağlamadan bunlardan alıntı yapmak, yalnızca anlaşılmasını zorlaştırır. En çarpıcı örnek nesne cebirinin geliştirilmesine ilişkin alt bölümdür. İlk üç "temel" işlem - birleştirme, fark, seçme - sezgiseldir (gerçekte orijinal makalenin yazarları yarı birleştirme şeklinde çok belirgin olmayan bir örnekleme seçeneğine izin vermiş olsa da), ancak son ikisi - oluştur ve oluştur harita - tanımlanması zor ve açık olmayan işlemlerdir.

Bagui'nin makalesindeki tuhaf bir özelliğe daha dikkat çekmek istiyorum. 2001 yılına kadar, nesne yönelimli veri modelini standartlaştırmak için tekliflerin üç versiyonunu yayınlayan Object Data Management Group adında uluslararası bir konsorsiyum vardı; en son sürüm olan ODMG 3.0, 2000 yılında yayınlandı. Bu, nispeten tutarlı terminoloji ve bir dereceye kadar nesne yönelimli veri modeli sunan tek belgedir. Bagui'nin bu malzemeyi kullanmaması çok yazık.

DBMS dergisinin, standardın ilk versiyonu olan ODMG-93'e ayrılmış bir makale yayınladığını unutmayın. Kısa inceleme ODMG 3.0 standardı şurada bulunabilir: . Ayrıca Nesneye Dayalı Veritabanı Sistemleri Manifestosu'nun çevirisini ve OODB teknolojisine çok güzel bir genel bakışı da tavsiye edebiliriz.

Edebiyat

Nesne Veri Standardı: ODMG 3.0. R.G.G. Cattel, D.K. Barry, editörler, Morgan Kauffmann, 2000.
L.A. Kaliniçenko, . // DBMS, No.1, 1996.
SD. Kuznetsov. "Üç Veritabanı Manifestosu: Retrospektif ve Beklentiler." “XXI yüzyılın veritabanları ve bilgi teknolojileri” konferansındaki rapor, Moskova, Eylül 2003, http://www.citforum.ru/database/articles/manifests.
M. Atkinson ve diğerleri, // DBMS, No. 4, 1995.
Ark Andreev, Dmitry Berezkin, Roman Samarev, . // Açık Sistemler, No. 3, 2001.

Yukarıda açıklanan MD'yi temel alan veritabanı teknolojileri, veri modellemeye odaklanan statik bir bilgi depolama konseptine dayanmaktadır. Ancak karmaşık, birbirine bağlı veritabanı nesnelerine sahip teknolojinin yeni uygulama alanları, örneğin:

Bilgisayar destekli tasarım;

Otomatik üretim;

Otomatik geliştirme yazılım;

Ofis bilgi sistemleri;

Multimedya sistemleri;

Coğrafi Bilgi Sistemleri;

Yayıncılık sistemleri ve diğerleri, gerçek dünyadaki nesnelerin modellenmesi açısından statik konseptin sınırlı yeteneklerini ortaya koymuştur.

Yeni türdeki karmaşık özel veritabanı uygulamaları için, verilerin ve bu veriler üzerinde etkili olan süreçlerin paralel modellenmesine olanak tanıyan dinamik bir bilgi depolama konsepti etkilidir. Bu, konu alanının anlambilimini dikkate almanıza ve dolayısıyla bu uygulamaları en uygun şekilde tanımlamanıza olanak tanır. Bu kavram, yazılım oluşturmada yaygın olarak kullanılan nesne yönelimli yaklaşıma dayanmaktadır. Bu kavramı uygulayan ve nesne yönelimli paradigmayı (OOP) temel alan MD'ye, nesne yönelimli veri modeli (OODM) adı verilmektedir.

OOMD'nin yapısı, konu alanının bir dizi nesne tarafından tanımlanabileceği varsayımına dayanmaktadır. Her nesne, "gerçek dünya" nesnelerinin durumunu ve onlarla ilişkili eylemleri tanımlayan nitelikleri içeren, benzersiz şekilde tanımlanabilir bir varlıktır. Bir nesnenin mevcut durumu, basit veya karmaşık olabilen bir veya daha fazla öznitelik tarafından tanımlanır. Basit bir öznitelik ilkel bir türde olabilir (örneğin, tamsayı, dize vb.) ve değişmez bir değer alabilir. Bileşik bir nitelik, koleksiyonlar ve/veya referanslar içerebilir. Referans niteliği nesneler arasındaki ilişkiyi temsil eder.

Bir nesnenin temel özelliği, Tanımlamasının benzersizliğidir. Bu nedenle nesne yönelimli bir sistemdeki her nesnenin kendi tanımlayıcısına sahip olması gerekir.

Nesne Tanımlayıcı (OID), tek tek nesneleri etiketlemenin veritabanı içi bir yoludur. Diyalog tabanlı bir sorgu veya bilgi görüntüleyiciyle çalışan kullanıcılar genellikle bu tanımlayıcıları görmez. Bunlar DBMS'nin kendisi tarafından atanır ve kullanılır. Tanımlayıcının semantiği her DBMS'de farklıdır. Rastgele bir değer olabilir veya bir veritabanı dosyasında bir nesneyi bulmak için gerekli bilgileri (örneğin, dosyadaki sayfa numarası ve nesnenin başlangıcından itibaren uzaklığı) içerebilir. Nesneye yapılan referansları düzenlemek için kullanılması gereken tanımlayıcıdır.

Tüm nesneler kapsüllenmiştir, yani nesnenin temsili veya iç yapısı kullanıcıdan gizli kalır. Bunun yerine kullanıcı yalnızca nesnenin bazı işlevleri gerçekleştirebildiğini bilir. Böylece bir WAREHOUSE nesnesi için RECEIVE_GOOD, ISSUE_TOBAP vb. yöntemler kullanılabilir.Kapsüllemenin avantajı, bu nesnelerin kullanıldığı uygulamaları yeniden çalıştırmadan nesnelerin iç temsilini değiştirmenize olanak sağlamasıdır. Başka bir deyişle kapsülleme veri bağımsızlığını ima eder.

Bir nesne, verileri ve işlevleri (OOP'ye göre yöntemler) kapsüller. Yöntemler bir nesnenin davranışını tanımlar. Bir nesnenin öznitelik değerlerini değiştirerek durumunu değiştirmek veya seçilen özniteliklerin değerlerini sorgulamak için kullanılabilirler. Örneğin, yeni bir kiralık mülk hakkında bilgi eklemek, bir çalışanın maaş bilgilerini güncellemek veya belirli bir ürünle ilgili bilgileri yazdırmak için yöntemler olabilir.

Aynı öznitelik kümesine sahip olan ve aynı mesajlara yanıt veren nesneler şu şekilde gruplandırılabilir: Sınıf(literatürde “sınıf” ve “tip” terimleri sıklıkla birbirinin yerine kullanılmaktadır). Bu tür her sınıfın kendi temsilcisi vardır - bir veri öğesi olan bir nesne. Belirli bir sınıfın nesnelerine buna denir kopyalar.

Bazı nesne yönelimli sistemlerde sınıf aynı zamanda bir nesnedir ve kendi niteliklerine ve yöntemlerine sahiptir. sınıf nitelikleri ve sınıf yöntemleri.

OOP'un önemli kavramları şunlardır: sınıf hiyerarşisi ve kapsayıcı hiyerarşisi.

Sınıf Hiyerarşisi bu durumda üst sınıf olarak adlandırılan her sınıfın kendi alt sınıfına sahip olma olasılığını ima eder. Örnek olarak şu zinciri verebiliriz: herhangi bir işletmenin tüm programcıları onun çalışanlarıdır, dolayısıyla OOMD çerçevesinde PROGRAMMERS sınıfının bir nesnesi olan her programcı aynı zamanda bir çalışandır ve bu kişi de, EMPLOYEES sınıfının bir nesnesidir. Böylece PROGRAMCILAR bir alt sınıf, ÇALIŞANLAR ise bir üst sınıf olacaktır. Ancak programcılar aynı zamanda sistem ve uygulama programcıları olarak da ikiye ayrılabilir. Bu nedenle PROGRAMMERS, SIS_PROGRAMMERS ve APPLICATION_PROGRAMERS alt sınıflarının bir üst sınıfı olacaktır. Bu zinciri daha da devam ettirerek, bir alt sınıfın her nesnesinin karşılık gelen üst sınıfın değişkenlerinin ve yöntemlerinin örneklerini miras aldığı bir sınıf hiyerarşisi elde ederiz.

Birkaç tür kalıtım vardır - tekli, çoklu ve seçici. Tekli kalıtım, alt sınıfların en fazla bir üst sınıftan miras alması durumudur. Çoklu kalıtım, birden fazla üst sınıftan miras alınmasıdır. Seçici kalıtım, bir alt sınıfın, üst sınıfından sınırlı sayıda özelliği miras almasına olanak tanır.

Değişken örneklerin kalıtımı denir yapısal miras, yöntem mirası - davranışsal miras aynı yöntemin farklı sınıflar için kullanılabilmesi, daha doğrusu farklı yöntemlerin farklı sınıflar için aynı isimle kullanılabilmesine denir. polimorfizm.

Nesne yönelimli mimarinin başka bir hiyerarşi türü de vardır: kapsayıcı hiyerarşisi. Bazı nesnelerin kavramsal olarak diğerlerinin içinde kapsanabilmesidir. Bu nedenle, DEPARTMENT sınıfının bir nesnesi, bölüm başkanına karşılık gelen EMPLOYEE sınıfı nesnesine bir bağlantı olan HEAD genel değişkenini içermeli ve ayrıca çalışan çalışanlara karşılık gelen nesnelere yönelik bir dizi bağlantıya da bir bağlantı içermelidir. bu bölümde.

Bazı nesne yönelimli sistemlerde sınıf da bir nesnedir ve kendine has nitelikleri ve yöntemleri vardır. Bir sınıfın genel özellikleri, nitelikleriyle tanımlanır. Nesne sınıfı yöntemleri, gerçek dünyadaki nesnelerin özelliklerinin bir tür analogudur. Belirli bir sınıfa ait olan her nesne bu özelliklere sahiptir. Bu nedenle, bir nesne oluştururken, onun doğal özelliklerini tanımlayabilmek için ait olduğu sınıfı bildirmek gerekir.

Kullanıcı ve nesne mesajlar aracılığıyla etkileşime girer. Her mesaja yanıt olarak sistem ilgili yöntemi yürütür.

Nesne modelindeki tüm ilişkiler, genellikle OID'ler olarak uygulanan referans nitelikleri kullanılarak yapılır.

İlişkisel bir veritabanındaki ilişkiler, birincil ve yabancı anahtarların karşılaştırılması ile temsil edilir. Veritabanının kendisinde tablolar arasında ilişki kurmaya yönelik yapılar yoktur; tablolar bağlanırken gerektiği gibi bağlantılar kullanılır. Buna karşılık ilişkiler, nesne yönelimli bir veritabanının temelini oluşturur çünkü her nesne, ilişkili olduğu nesnelerin tanımlayıcılarını içerir.

OOMD'de yalnızca geleneksel bağlantılar değil aynı zamanda kalıtımdan kaynaklanan bağlantılar da uygulanabilmektedir.

Birebir iletişim (1:1) A ve B nesneleri arasında, B nesnesine A nesnesine bir referans niteliği ve (referans bütünlüğünü korumak için) A nesnesine B nesnesine bir referans niteliği eklenerek uygulanır.

Bire çok (1:M) ilişki A ve B nesneleri arasında, A nesnesine, B nesnesine bir referans niteliği ve A nesnesinden B nesnesine bir dizi referans içeren bir öznitelik eklenerek uygulanır (örneğin, bir referans niteliği B(OID2, OID3...) eklenir) A nesnesine ve OID2, OID3,... içeren B nesnesinin örneklerine A referans özelliği eklenir: OID1.

Çoka çoğa (M:N) ilişki A ve B nesneleri arasında, her nesneye bir dizi bağlantı içeren bir öznitelik eklenerek uygulanır.

OOMD'de, bir sınıfa ait bir nesnenin, parçaları olarak diğer sınıflara ait nesneleri içerdiğini tanımlayan "tam parça" ilişkisini kullanabilirsiniz. Üretim veritabanı durumunda, ÜRÜN sınıfı ile PARÇA ve ASSEMBLY sınıfları arasında tam parça ilişkisi olacaktır. Bu bağlantıözel anlambilime sahip çoktan çoğa iletişimin bir çeşididir. Tam parça ilişkisi, bir dizi ilgili nesne tanımlayıcı kullanılarak diğer çoktan çoğa ilişkiler gibi uygulanır. Ancak alışılagelmiş çoktan çoğa ilişkinin aksine, farklı bir anlamsal anlamı vardır.

Nesne yönelimli paradigma kalıtımı desteklediğinden, OOMD "is" tipindeki ilişkileri ve "extends" tipindeki ilişkileri kullanabilir. Genelleme-uzmanlaşma ilişkisi olarak da adlandırılan "öyledir" ilişkisi, alt sınıfların üst sınıfların özel durumları olduğu bir kalıtım hiyerarşisine yol açar. Bu, yeniden miras alınan özelliklerin tanımlanmamasını mümkün kılar. "Genişletme" ilişkisini kullanırken, alt sınıf, üst sınıfın işlevselliğini, özel bir durumuyla sınırlandırmak yerine genişletir.

Bütünlük kısıtlamaları ve veri işlemleri gibi bileşenlerin OOMD'de nasıl uygulandığına bakalım.

Bu bileşenlerin özellikleri modelin özelliklerine göre belirlenir. OOMD'deki bu özgüllük öncelikle nesnelerin kapsüllenmesi, yani gizli iç yapı, verilere yalnızca önceden belirlenmiş yöntemlerle erişim, sınıf hiyerarşisi ve kapsayıcı hiyerarşisi gibi dahili kavramlar tarafından belirlenir.

OOMD'nin özellikleri, nesnenin özellikleri tarafından belirlenir. Nesneleri sınıflara ayırma ihtiyacında kendini gösterir. Her nesne, göreve bağlı olarak bir veya başka bir sınıfa dahil edilir ve bir nesne aynı anda birden fazla sınıfa ait olabilir (örneğin, PROGRAMCILAR ve YÜKSEK ÜCRETLİ aileler). Bir nesnenin bir başka spesifik özelliği de bir sınıftan (alt sınıftan) diğerine “hareket edebilmesidir”. Böylece bir SİSTEM PROGRAMCISI zamanla UYGULAMA PROGRAMCISINA dönüşebilir. Bu nedenle, bir sınıf hiyerarşisi, daha önce göründüğü gibi, hiyerarşik bir modele benzemez; ancak sistemin, sınıf hiyerarşisi içindeki her nesnenin konumunu değiştirebilmesini, örneğin sınıf içinde "yukarı" veya "aşağı" hareket edebilmesini gerektirir. belirli bir hiyerarşi. Ancak daha karmaşık bir süreç de mümkündür; sistem, bir nesnenin herhangi bir zamanda hiyerarşinin keyfi bir tepesine eklenmesine (ayrılmasına) olanak sağlamalıdır.

Önemli rol OOMD'de bağlantıların bütünlüğüne ilişkin kısıtlamalar rol oynar. Nesne yönelimli MD'deki bağlantıların çalışması için bağlantının her iki tarafındaki nesne tanımlayıcılarının birbiriyle eşleşmesi gerekir. Örneğin, ÇALIŞANLAR ile ÇOCUKLARI arasında bir ilişki varsa, çalışanı temsil eden bir nesneye bir çocuğu tanımlayan bir nesne yerleştirildiğinde, bu nesnenin tanımlayıcısının ilgili nesneye ekleneceğine dair bir garanti olmalıdır. İlişkisel veri modelindeki referans bütünlüğüne bir şekilde benzeyen bu tür ilişkisel bütünlük, geri bildirim bağlantıları kullanılarak oluşturulur. İlişkilerin bütünlüğünü sağlamak için tasarımcıya, ters nesne tanımlayıcısının konumunu belirlemek için gerekli olan özel bir sözdizimsel yapı sağlanır. İlişkilerin bütünlüğüne (aynı zamanda ilişkisel bir veritabanındaki referans bütünlüğüne) kısıtlamalar koyma sorumluluğu tasarımcıya aittir.

OOMD'de hem veri tanımlaması hem de manipülasyonu aynı nesne yönelimli prosedür dili kullanılarak gerçekleşir.

ODMG (Nesne Veritabanı Yönetim Grubu) grubu, nesne veritabanı teknolojisinin standartlaştırılması sorunlarıyla ilgilenir. Veritabanı nesnelerinin semantiği için standart bir model tanımlayan bir nesne modeli geliştirdi (ODMG 2.0, Eylül 1997'de kabul edildi). Bu model önemlidir çünkü nesne yönelimli bir DBMS'nin (OODBMS) anlayabileceği ve uygulayabileceği yerleşik anlambilimi tanımlar. Bu anlambilimi kullanan kitaplıkların ve uygulamaların yapısı, bu nesne MD'sini destekleyen farklı OODBMS'ler arasında taşınabilir olmalıdır. ODMG mimarisinin ana bileşenleri şunlardır: nesne modeli (OM), nesne tanımlama dili (ODL), nesne sorgulama dili (OQL) ve C++, Java ve Smalltalk'a bağlanma yeteneği.

ODMG 2.0 standardına uygun nesne veri modeli aşağıdaki özelliklerle karakterize edilir:

Temel yapı taşları nesneler ve değişmezlerdir. Her nesnenin benzersiz bir tanımlayıcısı vardır. Bir değişmezin kendi tanımlayıcısı yoktur ve bir nesne olarak ayrı olarak var olamaz. Değişmez değerler her zaman nesnelere gömülüdür ve tek tek başvurulamaz;

Nesneler ve değişmezler türe göre ayırt edilir. Her türün, o türün tüm nesneleri ve değişmez değerleri tarafından paylaşılan kendi etki alanı vardır. Türlerin davranışları da olabilir. Bir türün bir davranışı varsa, bu türdeki tüm nesneler aynı davranışa sahiptir. Uygulamada tür, nesnenin oluşturulduğu sınıf, bir arayüz veya basit bir veri türü (tamsayı gibi) olabilir. Bir nesne bir türün örneği olarak düşünülebilir;

Bir nesnenin durumu, bir dizi özellik tarafından gerçekleştirilen bir dizi mevcut değerle belirlenir. Bu özellikler bir nesnenin nitelikleri veya bir nesne ile bir veya daha fazla başka nesne arasındaki ilişkiler olabilir;

Bir nesnenin davranışı, nesne üzerinde veya nesnenin kendisinde gerçekleştirilebilecek bir dizi işlemle tanımlanır. İşlemler, her biri kesin olarak tanımlanmış türde olan giriş ve çıkış parametrelerinin bir listesine sahip olabilir. Her işlem aynı zamanda yazılan bir sonucu da döndürebilir;

Veritabanı tanımı, Nesne Tanımlama Dili (ODL) ile yazılmış bir şemada saklanır. Veritabanı nesneleri saklayarak bunların farklı kullanıcılar ve uygulamalar arasında paylaşılmasına olanak tanır.

OODS'yi temel alan DBMS'lere nesne yönelimli DBMS'ler (OODBMS'ler) adı verilir. Bu DBMS'ler üçüncü nesil DBMS'ler olarak sınıflandırılır* (* Veri depolama modellerinin gelişim tarihi genellikle üç aşamaya (nesiller) ayrılır: ilk nesil (1960'ların sonu - 70'lerin başı) - hiyerarşik ve ağ modelleri; ikinci nesil (yaklaşık 1970-1980'ler) - ilişkisel model; üçüncü nesil (1980'ler - 2000'lerin başı) - nesne yönelimli modeller.).

Günümüzde nesne yönelimli veritabanları çeşitli kuruluşlarda çok çeşitli sorunları çözmek için kullanılmaktadır. Bilgi teknolojisi verileri alanındaki birikmiş deneyimlerin analizi ve genelleştirilmesi, nesne yönelimli veritabanlarının kullanımının haklı olduğu uygulamaların belirlenmesini mümkün kılmıştır:

Uygulama çok sayıda etkileşimli parçadan oluşur. Her birinin, başkalarının davranışlarına bağlı olan kendi davranışları vardır;

Sistem büyük hacimli yapılandırılmamış veya karmaşık verileri işlemelidir;

Uygulama verilere öngörülebilir bir şekilde erişecektir, dolayısıyla nesne yönelimli veritabanlarının gezinme özelliği önemli bir dezavantaj olmayacaktır;

Planlanmamış isteklere olan ihtiyaç sınırlıdır;

Saklanan verilerin yapısı hiyerarşiktir veya doğası gereği benzerdir.

Şu anda yazılım pazarında çok sayıda nesne yönelimli DBMS bulunmaktadır. Masada 10.6 bu sınıftaki ticari sistemlerden bazılarını sunmaktadır.

Tablo 10.6

Modern ticari OODBMS,

üreticileri ve uygulama alanları

Temel farklılıklardan biri nesne veritabanları ilişkisel verilerden yeni veri türleri oluşturma ve kullanma yeteneğidir. OODBMS'nin önemli bir özelliği, yeni bir türün oluşturulmasının veritabanı çekirdeğinde değişiklik yapılmasını gerektirmemesi ve nesne yönelimli programlama ilkelerine dayanmasıdır.

OODBMS çekirdeği nesnelerle yapılan işlemler için optimize edilmiştir. Doğal işlemleri arasında nesneleri önbelleğe almak, nesnelerin sürümlerini korumak ve erişim haklarını belirli nesnelere bölmek yer alır. OODBMS, nesnelere paketlenmiş verilere erişim ve bu verilerin alınmasını gerektiren işlemlerde, diğerlerine kıyasla daha yüksek performansla karakterize edilir. ilişkisel DBMS, bunun için bağlantılı verileri getirme ihtiyacı ek dahili işlemlere yol açar.

Bir OODBMS için oldukça önemli olan, nesneleri bir veritabanından diğerine taşıma yeteneğidir.

Oluştururken çeşitli uygulamalar Bir OODBMS'ye dayalı olarak, belirli bir DBMS'nin yerleşik sınıf yapısı önemlidir. Sınıf kitaplığı, kural olarak, yalnızca tüm standart veri türlerini değil, aynı zamanda genişletilmiş bir multimedya kümesini ve video, ses ve bir dizi animasyon karesi gibi diğer karmaşık veri türlerini de destekler. Bazı OODBMS'ler, belge bilgilerinin saklanmasını ve tam metin olarak aranmasını mümkün kılan sınıf kitaplıkları oluşturmuştur (örneğin, Jasmine, ODB-Jüpiter). Temel sınıf yapısının bir örneği Şekil 2'de gösterilmektedir. 10.17.

İçindeki ana konum, veritabanına erişimi kontrol etmek ve indekslemeyi gerçekleştirmek için gerekli tüm özellikleri ve yöntemleri içeren TOdbObject sınıfı tarafından işgal edilmiştir. Diğer tüm sınıflar, uyguladıkları türün doğruluğu için bir tür kontrolü ve belirli bir dizin oluşturucu ekleyerek yöntemlerini geçersiz kılar.

Olarak Şekil l'de görülebilir. 10.17'de, yapıda belgesel bilgilerin işlenmesine odaklanan çeşitli sınıflar vardır - TOdbText, TOdbDocument, TODBTextDocument, vb. Her belge ayrı bir nesneyle temsil edilir. Bu, belgelerin doğal şekilde saklanmasını sağlar. En önemli işlemlerden biri talep üzerine belge aramaktır. Çoğu sınıf için, nesneleri belirli bir anahtarın değerine göre arama yeteneği uygulanır. TOdbText sınıfı için, doğal dilde yazılmış bir ifadeye dayalı olarak arama sorgusu oluşturma yeteneği uygulanmıştır.

TOdbDocument sınıfı özeldir ve farklı türdeki nesneleri içerebilmektedir. Her birinin bir adı olan ve belirli türdeki bir nesneyle ilişkilendirilen alanlardan oluşur. Bu sınıfın varlığı kullanıcıya tür kümesini genişletme fırsatı verir. Bir kap nesnesini (belgeyi) değiştirerek belirli bir alan kümesi ayarlayabilir ve yeni bir Belge türü elde edebilirsiniz.

OODBMS geliştiricileri, ODB-Jüpiter'i temel alarak, evrensel bir depolanan veri yapısına ve güçlü bir arama motoruna sahip, tamamen işlevsel bir bilgi erişim sistemi ODB-Text oluşturdu. ODB-Text sistemi, belgelerin toplu olarak işlenmesi ve kurumsal arşivin sürdürülmesi için bir araçtır. Olası uygulamalar arasında modern bir ofiste belge akışı muhasebesinin otomasyonu, referans ve bilgi sistemlerinin oluşturulması (iyi bilinen Hukuk veritabanlarına benzer), ağ veritabanlarının bakımı, personel kayıtları, bibliyografya vb. yer alır.

41. Uygulamalı entegre devre tasarımının özellikleri. IP gelişiminin aşamaları. (Konu 11, s. 100-103).

11.1.3. Uygulamalı IC'lerin sistem tasarımının özellikleri

İnşa ederken (seçerken, uyarlarken) bilgi sistemiİki ana kavramı, iki ana yaklaşımı kullanabilirsiniz (üçüncü kavram bunların birleşimidir):

1. Bu bilgi sistemi kullanılarak çözülmesi gereken sorunlara odaklanın; problem odaklı yaklaşım (veya tümevarımsal yaklaşım);

2. Belirli bir sistem veya ortamda mevcut (güncellenmiş) teknolojiye yönelim; teknoloji odaklı yaklaşım (veya tümdengelimli yaklaşım).

Konsept seçimi stratejik (taktik) ve/veya uzun vadeli (kısa vadeli) kriterlere, sorunlara, kaynaklara bağlıdır.

Öncelikle mevcut teknolojinin yetenekleri araştırılır ve ardından onların yardımıyla çözülebilecek mevcut sorunlar belirlenirse teknoloji odaklı bir yaklaşıma güvenmek gerekir.

Öncelikle mevcut sorunlar tespit edilip, daha sonra bu sorunları çözmeye yetecek teknoloji devreye sokulursa sorun odaklı bir yaklaşıma güvenmek gerekir.

Aynı zamanda, bir bilgi sistemi oluşturmanın her iki kavramı da birbirine bağlıdır: yeni teknolojilerin getirilmesi, çözülen sorunları değiştirir ve çözülen sorunların değiştirilmesi, yeni teknolojilerin tanıtılması ihtiyacını doğurur; her ikisi de alınan kararları etkiler.

Uygulanan (kurumsal) herhangi bir bilgi sisteminin sistem tasarımı (geliştirilmesi) ve kullanımı, bilgi sisteminin aşağıdaki yaşam döngüsünden geçmelidir:

– tasarım öncesi analiz (başka benzer sistemler oluşturma deneyimi, prototipler, geliştirilmekte olan sistemin farklılıkları ve özellikleri, vb.), sistemin dış belirtilerinin analizi;

– sistem içi analiz, dahili analiz (sistem alt sistemlerinin analizi);

- sistemin sistemik (morfolojik) tanımı (temsili) (sistem hedefinin tanımı, sistem ilişkileri ve çevre, diğer sistemler ve sistem kaynakları - malzeme, enerji, bilgi, organizasyonel, insan, mekansal ve zamansal ile bağlantılar);

– yeterlilik, verimlilik ve sürdürülebilirlik (güvenilirlik) kriterlerinin belirlenmesi;

– sistem alt sistemlerinin işlevsel açıklaması (modellerin tanımı, alt sistemlerin işleyişine yönelik algoritmalar);

– sistemin prototiplenmesi (düzen açıklaması), sistem alt sistemlerinin etkileşiminin değerlendirilmesi (bir düzenin geliştirilmesi - basitleştirilmiş işlevsel açıklamalarla alt sistemlerin uygulanması, prosedürler ve sistem hedefini karşılamak için bu düzenlerin etkileşiminin test edilmesi), yeterlilik, istikrar ve verimlilik kriterlerinin “düzenlerini” kullanmak mümkünken;

– sistemin “montajı” ve test edilmesi - tam teşekküllü fonksiyonel alt sistemlerin ve kriterlerin uygulanması, modelin formüle edilen kriterlere göre değerlendirilmesi;

– sistemin çalışması;

- sistemin ve uygulamalarının daha da geliştirilmesine yönelik hedeflerin belirlenmesi;

– sistemin bakımı - çalışma modunda sistemin yeteneklerinin açıklığa kavuşturulması, değiştirilmesi, genişletilmesi (geliştirilmesi amacıyla).

Bu aşamalar sistemlerin bilginin yeniden yapılandırılmasının ana aşamalarıdır.

Kurumsal bir bilgi sisteminin geliştirilmesi, kural olarak, çok spesifik bir işletme için gerçekleştirilir. İşletmenin söz konusu faaliyetinin özellikleri kesinlikle bilgi sisteminin yapısını etkileyecektir. Ancak aynı zamanda farklı işletmelerin yapıları genel olarak birbirine benzer. Her kuruluş, faaliyet türüne bakılmaksızın, şu veya bu tür şirket faaliyetini doğrudan yürüten birkaç bölümden oluşur. Ve bu durum, ne tür faaliyette bulunursa bulunsun, hemen hemen tüm kuruluşlar için geçerlidir.

Bu nedenle, herhangi bir organizasyon, her biri kendine ait, oldukça karmaşık bir yapıya sahip olabilen, etkileşimli unsurlar (bölümler) kümesi olarak düşünülebilir. Departmanlar arasındaki ilişkiler de oldukça karmaşıktır. Genel olarak, bir işletmenin departmanları arasındaki üç tür bağlantı ayırt edilebilir:

İşlevsel bağlantılar - her departman, tek bir iş süreci içerisinde belirli türdeki işleri gerçekleştirir;

Bilgi iletişimi - departmanlar bilgi alışverişinde bulunur (belgeler, fakslar, yazılı ve sözlü siparişler vb.);

Dış iletişim - bazı departmanlar dış sistemlerle etkileşime girer ve etkileşimleri hem bilgilendirici hem de işlevsel olabilir.

Farklı işletmelerin ortak yapısı, kurumsal bilgi sistemleri oluşturmaya yönelik bazı ortak ilkeleri formüle etmemize olanak tanır.

Genel olarak bir bilgi sistemi geliştirme süreci iki açıdan ele alınabilir:

Zamana göre veya aşamalara göre yaşam döngüsü sistem geliştirilmektedir. Bu durumda, döngüler, aşamalar, yinelemeler ve aşamalar açısından tanımlanan geliştirme sürecinin dinamik organizasyonunu ele alıyoruz.

Proje olarak kurumsal bilgi sistemi geliştirildi. Proje yönetimi ve proje geliştirme aşamasının (yaşam döngüsü aşamaları) pek çok özelliği ortaktır ve yalnızca konu alanından değil aynı zamanda projenin doğasından da bağımsızdır (mühendislik ya da ekonomik proje olması fark etmez). Bu nedenle, öncelikle bir dizi genel proje yönetimi sorununu dikkate almak mantıklıdır.

Bir proje, başlangıçta açıkça tanımlanmış hedeflere sahip, başarılması projenin tamamlanmasını belirleyen ve ayrıca zamanlama, sonuçlar, risk, fon ve kaynak harcama çerçevesi için belirlenmiş gerekliliklere sahip, ayrı bir sisteme yapılan zaman sınırlı, amaca yönelik bir değişikliktir. ve organizasyon yapısı için.

Genellikle karmaşık bir konsept için (özellikle bir proje konsepti gibi), tanıtılan konseptin tüm özelliklerini tam olarak kapsayan net bir formülasyon vermek zordur. Bu nedenle verilen tanımın benzersiz ve eksiksiz olduğu iddiası yoktur.

Bir yönetim nesnesi olarak projenin aşağıdaki ana ayırt edici özellikleri tanımlanabilir:

Değişkenlik, bir sistemin mevcut bir sistemden başka bir sisteme bilinçli olarak aktarılmasıdır.

proje hedefleri açısından açıklanan arzu edilen durum;

Nihai hedefin sınırlandırılması;

Sınırlı süre;

Bütçe sınırlamaları;

Sınırlı kaynaklar gerekli;

Projenin uygulandığı işletme için yenilik;

Karmaşıklık - projenin ilerlemesini ve sonuçlarını doğrudan veya dolaylı olarak etkileyen çok sayıda faktörün varlığı;

Yasal ve organizasyonel destek - proje süresince belirli bir organizasyon yapısının oluşturulması.

İşin verimliliği, kaynakların tahsisini, gerçekleştirilen iş sırasının koordinasyonunu ve iç ve dış rahatsız edici etkilerin telafisini sağlayan proje uygulama sürecinin yönetimi yoluyla sağlanır.

Kontrol sistemleri teorisi açısından bakıldığında, bir kontrol nesnesi olarak bir proje gözlemlenebilir ve kontrol edilebilir olmalıdır, yani projenin ilerleyişinin sürekli olarak izlenebileceği belirli özellikler tanımlanmalıdır (gözlenebilirlik özelliği). Ek olarak, projenin ilerleyişini zamanında etkilemek için mekanizmalara ihtiyaç vardır (kontrol edilebilirlik özelliği).

Kontrol edilebilirlik özelliği, genellikle bilgi sistemleri geliştirme projelerine eşlik eden, konu alanının belirsizlik ve değişkenlik koşullarında özellikle önemlidir.

Uygulaması için gereken karmaşıklık ve iş miktarına bakılmaksızın her proje, gelişiminde belirli aşamalardan geçer: "projenin henüz mevcut olmadığı" durumdan "projenin artık mevcut olmadığı" duruma kadar. Bir fikrin ortaya çıkmasından projenin tamamen tamamlanmasına kadar olan gelişim aşamaları kümesi genellikle aşamalara (aşamalar, aşamalar) ayrılır.

Aşama sayısının ve içeriğinin belirlenmesinde bazı farklılıklar vardır, çünkü bu özellikler büyük ölçüde belirli projenin koşullarına ve ana katılımcıların deneyimine bağlıdır. Ancak bilgi sistemi geliştirme sürecinin mantığı ve temel içeriği hemen hemen tüm durumlarda ortaktır.

Bilgi sistemi geliştirmenin aşağıdaki aşamaları ayırt edilebilir:

Kavramın oluşumu;

Teknik spesifikasyonların geliştirilmesi;

Tasarım;

Üretme;

Sistemin devreye alınması.

Her birine daha ayrıntılı olarak bakalım. İkinci ve kısmen üçüncü aşamalara genellikle sistem tasarım aşamaları adı verilir ve son iki aşama (bazen buraya tasarım aşaması da dahil edilir) uygulama aşamalarıdır.

Kavramsal aşama

Fikirlerin oluşturulması, hedeflerin belirlenmesi;

Kilit bir proje ekibinin oluşturulması;

Müşterinin ve diğer katılımcıların motivasyonunu ve gereksinimlerini incelemek;

İlk verilerin toplanması ve mevcut durumun analizi;

Temel gereksinimler ve sınırlamaların, gerekli malzeme, mali ve iş gücü kaynaklarının belirlenmesi;

Alternatiflerin karşılaştırmalı değerlendirmesi;

Tekliflerin sunulması, incelenmesi ve onaylanması.

Teknik teklifin geliştirilmesi

Projenin ana içeriğinin geliştirilmesi, projenin temel yapısı;

Teknik şartnamelerin geliştirilmesi ve onaylanması;

Projenin temel yapısal modelinin planlanması ve ayrıştırılması;

Projeye ilişkin tahminlerin ve bütçenin hazırlanması, kaynak gereksinimlerinin belirlenmesi;

Takvim planlarının ve genişletilmiş çalışma programlarının geliştirilmesi;

Müşteriyle bir sözleşme imzalamak;

Proje katılımcıları arasındaki iletişim araçlarının devreye alınması ve işin ilerleyişinin izlenmesi.

Tasarım

Bu aşamada alt sistemler ve bunların ilişkileri belirlenerek projeyi hayata geçirmenin ve kaynakları kullanmanın en etkin yolları seçilir. Bu aşamanın tipik çalışması:

Temel tasarım çalışmalarının yürütülmesi;

Özel teknik şartnamelerin geliştirilmesi;

Kavramsal tasarımın gerçekleştirilmesi;

Teknik şartnamelerin ve talimatların hazırlanması;

Tasarım geliştirmenin sunumu, incelenmesi ve onaylanması.

Gelişim

Bu aşamada proje çalışmalarının koordinasyonu ve operasyonel kontrolü gerçekleştirilir, alt sistemler üretilir, entegre edilir ve test edilir. Ana içerik:

Yazılım geliştirme çalışmalarının yürütülmesi;

Sistemin uygulanmasına hazırlık;

Temel proje göstergelerinin izlenmesi ve düzenlenmesi.

Sistemin devreye alınması

Bu aşamada testler yapılır, sistemin gerçek koşullarda deneme çalışması yapılır, proje sonuçları ve olası yeni sözleşmeler üzerinde görüşmeler yapılır. Ana iş türleri:

Kapsamlı testler;

42. IP yaşam döngüsü kavramı. (Konu 11, s. 103-105).