Nesne-ilişkisel empedans uyumsuzluğu - Object–relational impedance mismatch

Bu makalenin birden çok sorunu var. Lütfen yardım et onu geliştir veya bu konuları konuşma sayfası. (Bu şablon mesajların nasıl ve ne zaman kaldırılacağını öğrenin) Bu makale şu ifadeleri içermektedir: konuyu öznel bir şekilde tanıtır gerçek bilgi vermeden. Lütfen bu tür ifadeleri kaldırın veya değiştirin ve bir konunun önemi hakkında açıklamalar yapmak yerine, bu önemi göstermek için gerçekleri ve atıfları kullanın. (Ağustos 2020) (Bu şablon mesajını nasıl ve ne zaman kaldıracağınızı öğrenin) Bu makale içerir Gelincik kelimeler: genellikle eşlik eden belirsiz ifadeler önyargılı veya doğrulanamaz bilgi. Bu tür ifadeler olmalıdır açıklığa kavuşturuldu veya kaldırıldı. (Ağustos 2020) Bu makale genel bir liste içerir Referanslar, ancak büyük ölçüde doğrulanmamış kalır çünkü yeterli karşılık gelmiyor satır içi alıntılar. Lütfen yardım edin geliştirmek bu makale tanıtım daha kesin alıntılar. (Ağustos 2020) (Bu şablon mesajını nasıl ve ne zaman kaldıracağınızı öğrenin) (Bu şablon mesajını nasıl ve ne zaman kaldıracağınızı öğrenin)

nesne-ilişkisel empedans uyumsuzluğu sıklıkla karşılaşılan kavramsal ve teknik zorluklar dizisidir. ilişkisel veritabanı yönetim sistemi (RDBMS), bir uygulama programı (veya birden çok uygulama programı) tarafından nesne odaklı Programlama dili veya stil, özellikle nesnelerin veya sınıf tanımlarının haritalandı ilişkisel bir şema tarafından tanımlanan veritabanı tablolarına.

Dönem nesne-ilişkisel empedans uyumsuzluğu türetilmiştir elektrik Mühendisliği dönem empedans eşleştirme.

Uyumsuzluklar

Nesneler (örnekler) birbirlerine atıfta bulunur ve bu nedenle bir grafik matematiksel anlamda (döngüler ve döngüler içeren bir ağ). İlişkisel şemalar, aksine, tablo şeklindedir ve ilişkisel cebir, bağlantılı heterojen demetleri tanımlayan (veri alanlarının her alan için farklı türlere sahip bir "satır" halinde gruplanması).

Nesneye yönelik kavramlar

Kapsülleme

Nesneye yönelik programlar, aşağıdakilerle sonuçlanan tekniklerle iyi tasarlanmıştır: kapsüllenmiş nesneler iç temsili gizlenebilir. Nesne yönelimli bir çerçevede, belirli bir nesnenin temel özelliklerinin, nesnenin yanında uygulanan arabirimin dışında herhangi bir arabirime maruz kalmaması beklenir. Ancak çoğu nesne ilişkisel haritalama Bir nesnenin temel içeriğini, nesne uygulamasının belirleyemediği bir arabirimle etkileşime sokmak. Bu nedenle, bu nesne ilişkisel eşleştirme nesnenin kapsüllenmesini ihlal eder, çünkü birçok nesne ilişkisel eşleştirici veritabanı sütunlarına karşılık gelen genel alanları otomatik olarak oluşturur. Birkaç çerçeve bunun yerine Metaprogramlama tekniklerini kullanır, böylece kapsüllemeyi ihlal etmekten kaçınır.

Ulaşılabilirlik

İlişkisel düşüncede, "özel" ve "genel" erişim ihtiyaca göre değişir. Nesne yönelimli (OO) modelde, verilerin durumunun mutlak bir özelliğidir. İlişkisel ve OO modelleri, genellikle görelilik ve mutlaklık sınıflandırma ve özellikleriyle ilgili çatışmalara sahiptir.

Arayüz, sınıf, kalıtım ve çok biçimlilik

Nesne yönelimli bir paradigma altında, nesnelerin arayüzler birlikte o nesnenin iç kısmına tek erişim sağlar. İlişkisel model ise türetilmiş ilişki değişkenlerini kullanır (Görüntüleme ) bütünlüğü sağlamak için farklı bakış açıları ve kısıtlamalar sağlamak. Benzer şekilde, temel OOP kavramları sınıflar nesnelerin miras ve çok biçimlilik, ilişkisel veritabanı sistemleri tarafından desteklenmez.

İlişkisel kavramlarla eşleştirme

İlişkisel veritabanı tabloları bağlantılıysa, ilişkisel kavramlar ve nesneye yönelik kavramlar arasında uygun bir eşleştirme yapılabilir.^{[daha fazla açıklama gerekli ]} -e dernekler içinde bulunan nesneye yönelik analiz.

Veri türü farklılıkları

Mevcut ilişkisel ve OO dilleri arasındaki büyük bir uyumsuzluk, tip sistemi farklılıklar. İlişkisel model, referansa göre öznitelikleri (veya işaretçiler ), oysa OO dilleri referansa göre davranışı benimser ve bekler. Skaler türleri ve operatörleri anlambilim modeller arasında çok farklı olabilir ve haritalamada sorunlara neden olabilir.

Örneğin, çoğu SQL sistem desteği dizi değişen türler harmanlamalar ve kısıtlanmış maksimum uzunluklar (açık uçlu metin türleri performansı engelleme eğilimindeyken), çoğu OO dili harmanlamayı yalnızca rutinleri sırala ve dizeler içsel olarak kullanılabilir belleğe göre boyutlandırılır. Daha incelikli, ancak ilgili bir örnek, SQL sistemlerinin genellikle takip eden Beyaz boşluk karşılaştırma amacıyla bir dizede bulunurken, OO dizge kitaplıkları yapmaz. Bir OO dilindeki diğer ilkel türlerin olası değerlerini kısıtlama meselesi olarak yeni veri türleri oluşturmak genellikle mümkün değildir.

Yapısal ve bütünlük farklılıkları

Bir başka uyumsuzluk, karşıt modellerin yapısal ve bütünlük yönlerindeki farklılıklarla ilgilidir. OO dillerinde, nesneler başka nesnelerden oluşabilir - genellikle yüksek derecede - veya daha genel bir tanımdan uzmanlaşabilir. Bu, ilişkisel şemalarla eşleştirmeyi daha az basit hale getirebilir. Bunun nedeni, ilişkisel verilerin adlandırılmış bir küresel, iç içe olmayan ilişki değişkenleri kümesinde temsil edilme eğiliminde olmasıdır. İlişkilerin kendileri, demetler hepsi aynı başlığa uygundur (bkz. tuple ilişkisel hesap ) OO dillerinde ideal bir karşılığı yoktur. OO dillerindeki kısıtlamalar genellikle bu şekilde bildirilmez, ancak kapsüllenmiş dahili veriler üzerinde çalışan kodu çevreleyen koruma mantığını çevreleyen istisnai durum olarak gösterilir. İlişkisel model ise, beyan edici skaler türler, öznitelikler, ilişki değişkenleri ve bir bütün olarak veritabanı üzerindeki kısıtlamalar.

Manipülatif farklılıklar

Bununla birlikte, anlamsal farklılıklar özellikle kontrastlı modellerin manipülatif yönlerinde belirgindir. İlişkisel model, verilerin sorgulanması ve işlenmesi için içsel, nispeten küçük ve iyi tanımlanmış bir ilkel işleçler kümesine sahipken, OO dilleri genellikle özel olarak oluşturulmuş veya daha düşük seviyeli, büyük / küçük harf ve fiziksel erişim yoluyla sorgu ve manipülasyonu ele alır. yola özgü zorunlu operasyonlar. Bazı OO dillerinde bildirim temelli sorgu desteği vardır alt diller, ancak OO dilleri genellikle listelerle ilgilendiğinden ve belki de karma tablolar manipülatif ilkeller zorunlu olarak Ayarlamak ilişkisel modelin temelli işlemleri.^{[kaynak belirtilmeli ]}

İşlem farklılıkları

Eşzamanlılık ve işlem yönleri de önemli ölçüde farklıdır. Özellikle, işlemler Veritabanları tarafından gerçekleştirilen en küçük iş birimi, ilişkisel veritabanlarında OO dillerindeki sınıflar tarafından gerçekleştirilen tüm işlemlerden çok daha büyüktür. İlişkisel veritabanlarındaki işlemler, dinamik olarak sınırlandırılmış keyfi veri işleme kümeleridir, oysa bir OO dilindeki işlemlerin ayrıntı düzeyi tipik olarak ilkel tipli alanlara yapılan bireysel atamalar düzeyindedir. Genel olarak, OO dillerinde bir izolasyon veya dayanıklılık analogu yoktur, bu nedenle atomiklik ve tutarlılık yalnızca bu ilkel türlerin alanlarına yazılırken sağlanır.

Empedans uyumsuzluğunu çözme

Nesne yönelimli programlar için empedans uyuşmazlığı sorunu etrafında çalışmak, kullanılan belirli mantık sistemlerindeki farklılıkların tanınmasıyla başlar. Uyumsuzluk daha sonra en aza indirilir veya telafi edilir.^[1]

Alternatif mimariler

Nesne-ilişkisel empedans uyumsuzluğu sorunu, OO ve veritabanları arasında evrensel bir sorun değildir. Adından da anlaşılacağı gibi, bu empedans sorunu yalnızca ilişkisel veritabanları. Bu sorunun en yaygın çözümü, aşağıdaki gibi alternatif bir veritabanı kullanmaktır. NoSQL veya XML veritabanı.

Minimizasyon

Binada bazı girişimler oldu nesne yönelimli veritabanı yönetim sistemleri (OODBMS) empedans uyumsuzluğu sorununu önleyecektir. Uygulamada ilişkisel veritabanlarından daha az başarılı olmuşlardır, bununla birlikte, kısmen bir veri modelinin temeli olarak OO ilkelerinin sınırlamaları nedeniyle.^[2] OO dillerinin veritabanı benzeri yeteneklerini aşağıdaki gibi kavramlarla genişletmek için araştırmalar yapılmıştır. işlem belleği.

Empedans uyuşmazlığı sorununa yönelik yaygın bir çözüm, alanı ve çerçeve mantığını katmanlaştırmaktır. Bu şemada, OO dili, daha statik haritalamayı denemek yerine çalışma zamanında belirli ilişkisel yönleri modellemek için kullanılır. Bu yöntemi kullanan çerçeveler, genellikle bir "veri kümesi" bileşeninde bir "satır" olarak veya genel bir "varlık örneği" sınıfı olarak bir demet için bir analoğa ve ayrıca bir ilişki için bir analoga sahip olacaktır. Bu yaklaşımın avantajları şunları içerebilir:

• Etki alanı verilerinin aktarımı, sunumu ve doğrulanmasıyla ilgili çerçeveler ve otomasyon oluşturmak için basit yollar.
• Daha küçük kod boyutu; daha hızlı derleme ve yükleme süreleri.
• Yetenek şema dinamik olarak değiştirmek için.
• İsim alanı ve anlamsal uyumsuzluk sorunlarını ortadan kaldırır.
• Etkileyici kısıtlama kontrolü
• Karmaşık haritalamaya gerek yok

Dezavantajlar şunları içerebilir:

• Statik tip "güvenlik" kontrollerinin olmaması. Yazılı erişimciler bazen bunu azaltmanın bir yolu olarak kullanılır.
• Çalışma zamanı oluşturma ve erişimin olası performans maliyeti.
• Özgün OO yönlerini yerel olarak kullanamama, örneğin çok biçimlilik.

Tazminat

Karışımı söylem seviyeleri OO uygulama kodu içinde sorunlar ortaya çıkarır, ancak telafi etmek için kullanılan bazı ortak mekanizmalar vardır. En büyük zorluk, alan verilerinin modellendiği söylem düzeyinde çerçeve desteği, veri işleme otomasyonu ve sunum kalıpları sağlamaktır. Bunu ele almak için, yansıma ve / veya kod üretimi kullanılmaktadır. Yansıma, kodun (sınıfların) veri olarak ele alınmasına izin verir ve böylece verilerin taşınması, sunumu, bütünlüğü vb. İçin otomasyon sağlar. Generation, varlık yapılarını, sınıfları üreten ve toplu halde destekleyen altyapıyı destekleyen kod oluşturma araçları veya meta programlama dilleri için veri girdileri olarak ele alarak ele alır. Bu planların her ikisi de, bu söylem düzeylerinin birleştiği bazı anormalliklere tabi olabilir. Örneğin, oluşturulan varlık sınıfları tipik olarak etki alanıyla eşleşen özelliklere (örneğin, Ad, Adres) ve ayrıca durum yönetimi ve diğer çerçeve altyapısını (ör. IsModified) sağlayan özelliklere sahip olacaktır.

Çekişme

Bu bölüm içerir Gelincik kelimeler: genellikle eşlik eden belirsiz ifadeler önyargılı veya doğrulanamaz bilgi. Bu tür ifadeler olmalıdır açıklığa kavuşturuldu veya kaldırıldı. (Ocak 2015)

Tarafından tartışıldı Christopher J. Tarih ve diğerleri, bu gerçekten ilişkisel DBMS böyle bir sorun yaratmazdı^[3][4][5] gibi etki alanları ve sınıflar özünde bir ve aynı şeydir. Sınıflar ve ilişkisel şemalar arasında yerel bir eşleme, temel bir tasarım hatasıdır ^[6]; ve bir veritabanı tablosu (ilişki) içerisindeki bireysel demetler, varlıklar arasında ilişkiler kurmak olarak görülmelidir; karmaşık varlıkların kendileri için temsiller olarak değil. Ancak bu görüş, nesne yönelimli programlamanın etkisini ve rolünü, onu bir alan tipi yönetim sisteminden biraz daha fazla kullanarak azaltma eğilimindedir.

Empedans uyumsuzluğu arasında programlamada etki alanı nesneleri ve Kullanıcı arayüzü. Operatörlerin, yöneticilerin ve diğer programcı olmayanların veritabanındaki kayıtlara erişmesine ve bunları değiştirmesine olanak tanıyan gelişmiş kullanıcı arayüzleri, genellikle çeşitli veritabanı özelliklerinin doğası hakkında (ad ve türün dışında) yakın bilgi gerektirir. Özellikle, kullanıcı arayüzlerini, kullanıcı arayüzünün yasa dışı işlemleri (bir işlemin yapılmasına neden olanları) önleyeceği şekilde tasarlamak iyi bir uygulama olarak kabul edilir (son kullanıcı üretkenliği açısından) veritabanı kısıtlaması ihlal edilmek üzere) girilmekten; bunu yapmak, ilişkisel şemalarda bulunan mantığın çoğunun çoğaltılmış kodda.

Bazı kod geliştirme çerçeveleri, veritabanının şemasında temsil edilen belirli mantık biçimlerinden yararlanabilir (örneğin, başvurusal bütünlük kısıtlamaları), böylece bu tür sorunlar, bir vakaya yazılan ad hoc kod yerine kütüphane rutinleri aracılığıyla genel ve standart bir şekilde ele alınır. - olay bazında.

Tartışılmıştır ki SQL, çok sınırlı bir etki alanı türü kümesi (ve diğer iddia edilen kusurlar) nedeniyle doğru nesne ve etki alanı modellemeyi zorlaştırır; ve SQL, bir DBMS ile bir uygulama programı arasında (nesne yönelimli bir tarzda yazılmış olsun ya da olmasın) çok kayıplı ve verimsiz bir arayüz oluşturur. Bununla birlikte, SQL şu anda piyasada yaygın olarak kabul edilen tek ortak veritabanı dilidir^{[kaynak belirtilmeli ]}; Satıcıya özgü sorgu dillerinin kullanılması, önlenebilir olduğunda kötü bir uygulama olarak görülür. Gibi diğer veritabanı dilleri İş Sistemi 12 ve Öğretici D teklif edilmiştir; ancak bunların hiçbiri DBMS satıcıları tarafından geniş çapta benimsenmemiştir.

Oracle ve Microsoft SQL Server gibi ana akım "nesne ilişkisel" DBMS'lerin mevcut sürümlerinde, yukarıdaki nokta sorun teşkil etmeyebilir. Bu motorlarla, belirli bir veritabanının işlevselliği, modern bir OO dilinde (Oracle için Java ve SQL Server için bir Microsoft .NET dili) yazılmış depolanmış kod (işlevler ve prosedürler) aracılığıyla isteğe bağlı olarak genişletilebilir ve bu işlevler çağrılabilir. sırayla SQL deyimlerinde şeffaf bir şekilde: yani kullanıcı bu işlevlerin / prosedürlerin aslında veritabanı motorunun bir parçası olmadığını ne bilir ne de umursar. Modern yazılım geliştirme paradigmaları tam olarak desteklenir: bu nedenle, birden çok veritabanı şemasında yeniden kullanılabilen bir dizi kitaplık yordamı oluşturulabilir.

Bu satıcılar DBMS arka uçta OO-dil entegrasyonunu desteklemeye karar verdiler çünkü ISO SQL-99 komitesinin SQL'e prosedürel yapılar ekleme girişimlerine rağmen SQL'in hiçbir zaman zengin kitaplık ve veri yapılarına sahip olmayacağını fark ettiler. günümüzün uygulama programcıları doğal karşılanmaktadır ve çekirdek SQL dilini genişletmeye çalışmak yerine bunları olabildiğince doğrudan kullanmak mantıklıdır. Sonuç olarak, "uygulama programlama" ve "veritabanı yönetimi" arasındaki fark artık bulanıklaşmıştır: kısıtlamalar ve tetikleyiciler gibi özelliklerin güçlü bir şekilde uygulanması, genellikle çift DBA / OO programlama becerisine sahip bir kişiyi veya bu becerileri birleştiren kişiler arasında bir ortaklık gerektirebilir . Bu gerçek, aşağıdaki "sorumluluk paylaşımı" konusunu da taşıyor.

Bununla birlikte, bazıları, bu tartışmanın tartışmalı olduğunu çünkü şu gerçeğe işaret eder: (1) RDBMS'ler hiçbir zaman nesne modellemeyi kolaylaştırmak için tasarlanmamıştır ve (2) SQL genellikle yalnızca "kayıplı" veya "verimsiz" bir arayüz olarak görülmelidir. RDBMS'lerin tasarlanmadığı bir çözüme ulaşmaya çalışırken kullanılan dil. SQL, büyük veri kümelerini sorgulamak, sıralamak, filtrelemek ve depolamak için tasarlandığı şeyi yapmakta çok etkilidir. Bazıları ek olarak, arka uçta OO dil işlevselliğinin dahil edilmesinin, RDBMS'ye aykırı olarak veri katmanına üst düzey uygulama mantığını kabul ettiğinden, basitçe kötü mimari uygulamayı kolaylaştırdığını belirtecektir.

Burada devletin "kanonik" kopyası bulunur. Veritabanı modeli genellikle veritabanı Yönetim sistemi işletme ile ilgili tek yetkili devlet deposudur; bir uygulama programı tarafından tutulan bu tür bir durumun kopyaları sadece şudur - geçici kopyalar (temeldeki veritabanı kaydı daha sonra bir işlemle değiştirilmişse, güncel olmayabilir). Birçok nesne yönelimli programcı, nesnelerin bellek içi temsillerini kanonik veriler olarak görmeyi ve veritabanını bir destek deposu ve kalıcılık mekanizması olarak görmeyi tercih eder.

Diğer bir çekişme noktası, uygulama programcıları ve uygulama programcıları arasında uygun sorumluluk paylaşımıdır. veritabanı yöneticileri (DBA). Genellikle uygulama kodunda gerekli değişikliklerin (talep edilen yeni bir özelliği veya işlevselliği uygulamak için) veritabanı tanımında karşılık gelen değişiklikleri gerektirdiği durumdur; çoğu kuruluşta, veritabanı tanımı DBA'nın sorumluluğundadır. Bir üretim veritabanı sistemini günde 24 saat sürdürme ihtiyacından dolayı, birçok DBA, veritabanı şemalarında gereksiz veya gereksiz buldukları değişiklikleri yapma konusunda isteksizdir ve bazı durumlarda bunu tamamen reddeder. Gelişimsel veri tabanlarının kullanımı (üretim sistemleri dışında) bir şekilde yardımcı olabilir; ancak yeni geliştirilen uygulama "yayına girdiğinde" DBA'nın herhangi bir değişikliği onaylaması gerekecektir. Bazı programcılar bunu uzlaşmazlık olarak görür; ancak veritabanı tanımındaki herhangi bir değişikliğin bir üretim sisteminde hizmet kaybına neden olması durumunda DBA genellikle sorumlu tutulur - sonuç olarak, birçok DBA, tasarım hatalarının yıkıcı sonuçlara yol açma olasılığının çok daha düşük olduğu uygulama kodunda tasarım değişikliklerini içermeyi tercih eder. .

DBA'lar ve geliştiriciler arasında işlevsel olmayan bir ilişkiye sahip kuruluşlarda, yukarıdaki sorun, bir veritabanı şemasını değiştirme veya değiştirme kararı yalnızca iş ihtiyaçlarından kaynaklanacağından kendini göstermemelidir: ek verileri sürdürmek için yeni bir gereksinim veya Örneğin, kritik bir uygulamanın performans artışı, hem bir şema değişikliğini tetikleyecektir.

Felsefi farklılıklar

OO ve ilişkisel modeller arasındaki temel felsefi farklılıklar şu şekilde özetlenebilir:

• Bildirime dayalı ve zorunlu arabirimler - İlişkisel düşünme, verileri arabirimler olarak kullanma eğilimindedir, arabirimler olarak davranışı değil. Bu nedenle, OO'nun davranışsal eğiminin aksine tasarım felsefesinde açıklayıcı bir eğime sahiptir. (Bazı ilişkisel savunucular, karmaşık davranış sağlamak için tetikleyiciler, depolanmış prosedürler vb. Kullanılmasını önerir, ancak bu ortak bir bakış açısı değildir.)
• Şemaya bağlı - Nesnelerin, bir nesnenin sahip olduğu öznitelikler veya erişimciler için bir "ana şema" izlemesi gerekmezken, tablo satırları varlığın şemasını izlemelidir. Belirli bir satır bir ve yalnızca bir varlığa ait olmalıdır. OO'daki en yakın şey kalıtımdır, ancak genellikle ağaç şeklinde ve isteğe bağlıdır. Ad hoc sütunlara izin veren dinamik veritabanı sistemleri, şema sınırlarını gevşetebilir, ancak bu tür sistemler ya şu anda nadirdir ya da "ilişkisel" olarak sınıflandırılması söz konusudur.
• Erişim kuralları - İlişkisel veritabanlarında, özniteliklere önceden tanımlanmış ilişkisel operatörler aracılığıyla erişilir ve bunlar değiştirilirken, OO her sınıfın kendi durum değiştirme arayüzünü ve uygulamalarını oluşturmasına izin verir. OO'nun "kendi kendini idare eden isim" bakış açısı, ilişkisel modelin izin vermediği her nesneye bağımsızlık verir. Bu bir "standartlara karşı yerel özgürlük" tartışmasıdır. OO, ilişkisel standartların ifadeyi sınırladığını iddia ederken, ilişkisel savunucular kurallara bağlılığın daha soyut matematik benzeri akıl yürütmeye, bütünlüğe ve tasarım tutarlılığına izin verdiğini öne sürüyor.
• İsimler ve fiiller arasındaki ilişki - OO, fiiller (eylemler) ve işlemlerin üzerinde çalıştığı isimler (varlıklar) arasında sıkı bir ilişki kurulmasını teşvik eder. Hem isimleri hem de fiilleri içeren sonuçta ortaya çıkan sıkı bağlı varlık genellikle a olarak adlandırılır. sınıf veya OO analizinde, bir konsept. İlişkisel tasarımlar genellikle bu tür sıkı ilişkilerle ilgili (ilişkisel operatörler dışında) doğal veya mantıklı bir şey olduğunu varsaymaz.
• Nesne kimliği - Nesnelerin (değişmez olanlar dışında) genellikle benzersiz bir kimliği olduğu kabul edilir; Belirli bir zamanda aynı duruma sahip olan iki nesnenin aynı olduğu kabul edilmez. Öte yandan ilişkiler, bu tür bir kimliğin içkin bir kavramına sahip değildir. Bununla birlikte, küresel olarak benzersiz kullanım yoluyla bir veritabanındaki kayıtlar için "kimlik" üretmek yaygın bir uygulamadır. aday anahtarlar; birçok kişi bunun gerçek dünya varlığıyla bire bir yazışması olmayan herhangi bir veritabanı kaydı için kötü bir uygulama olduğunu düşünüyor. (İlişkisel, nesneler gibi, dış dünyada varsa, tanımlama amacıyla etki alanı anahtarlarını kullanabilir). Pratikte ilişkisel sistemler "kalıcı" ve incelenebilir tanımlama teknikleri için uğraşır ve desteklerken, nesne tanımlama teknikleri geçici veya durumsal olma eğilimindedir.
• Normalleştirme – İlişkisel normalleştirme uygulamalar genellikle OO tasarımları tarafından göz ardı edilir. Ancak, bu OO'nun doğal bir özelliği yerine kötü bir alışkanlık olabilir. Alternatif bir görünüm, bir nesneler koleksiyonunun işaretçiler bir tür, eşdeğerdir ağ veritabanı; bu da aşırı derecede normalden uzaklaştırılmış olarak görülebilir ilişkisel veritabanı.
• Şema kalıtımı - Çoğu ilişkisel veritabanı şema devralmayı desteklemez. OOP ile çatışmayı azaltmak için teoride böyle bir özellik eklenebilse de, ilişkisel savunucuların hiyerarşik taksonomilerin ve alt tiplemenin yararına inanma olasılıkları daha düşüktür çünkü set temelli taksonomiler veya sınıflandırma sistemleri ağaçlardan daha güçlü ve esnek. OO savunucuları, miras / alt tipleme modellerinin ağaçlarla sınırlı olması gerekmediğine dikkat çeker (ancak bu, birçok popüler OO dilinde bir sınırlamadır. Java ), ancak ağaç dışı OO çözümlerinin formüle edilmesi ilişkisel tarafından tercih edilen temaya dayalı varyasyon yönetimi tekniklerinden daha zor görülüyor. En azından ilişkisel cebirde yaygın olarak kullanılan tekniklerden farklıdırlar.
• Yapıya karşı davranış - OO, öncelikle programın yapısının makul olmasını (sürdürülebilir, anlaşılabilir, genişletilebilir, yeniden kullanılabilir, güvenli) sağlamaya odaklanırken, ilişkisel sistemler sonuçta ortaya çıkan çalışma zamanı sisteminin ne tür bir davranışa (verimlilik, uyarlanabilirlik, hata toleransı) sahip olduğuna odaklanır. , canlılık, mantıksal bütünlük vb.). Nesne yönelimli yöntemler genellikle nesne yönelimli kodun birincil kullanıcısının ve arabirimlerinin uygulama geliştiricileri olduğunu varsayar. İlişkisel sistemlerde, son kullanıcıların sistemin davranışına bakışının bazen daha önemli olduğu düşünülmektedir. Ancak, ilişkisel sorgular ve "görünümler", bilgileri uygulamaya veya göreve özgü yapılandırmalarda sunmak için yaygın tekniklerdir. Dahası, ilişkisel yerel veya uygulamaya özgü yapıların veya tabloların oluşturulmasını engellemez, ancak birçok yaygın geliştirme aracı doğrudan böyle bir özellik sağlamaz, bunun yerine nesnelerin kullanılacağı varsayılır. Bu, belirtilen geliştirici olmayan ilişkisel bakış açısının ilişkisel doğasında mı yoksa sadece mevcut uygulama ve araç uygulama varsayımlarının bir ürünü olup olmadığını bilmeyi zorlaştırır.
• Küme ve grafik ilişkileri - Farklı öğeler (nesneler veya kayıtlar) arasındaki ilişki, paradigmalar arasında farklı şekilde ele alınma eğilimindedir. İlişkisel ilişkiler genellikle şu kaynaklardan alınan deyimlere dayanır: küme teorisi nesne ilişkileri, grafik teorisi (dahil olmak üzere ağaçlar ). Her biri diğeriyle aynı bilgiyi temsil edebilirken, bilgiye erişmek ve yönetmek için sağladıkları yaklaşımlar farklılık gösterir.

Nesne-ilişkisel empedans uyumsuzluğunun bir sonucu olarak, tartışmanın her iki tarafındaki taraftarlar tarafından diğer teknolojinin terk edilmesi veya kapsamının azaltılması gerektiği sıklıkla tartışılmaktadır.^[7] Bazı veritabanı savunucuları, geleneksel "yordamsal" dilleri bir RDBMS ile birçok OO dilinden daha uyumlu olarak görür; veya daha az OO stilinin kullanılması gerektiğini önerin. (Özellikle, uygulama kodunda uzun ömürlü etki alanı nesnelerinin olmaması gerektiği; var olan bu tür nesnelerin bir sorgu yapıldığında oluşturulması ve bir işlem veya görev tamamlandığında atılması gerektiği tartışılmaktadır). Tersine, bazı OO savunucuları, daha fazla OO dostu kalıcılık mekanizmalarının, örneğin OODBMS geliştirilmeli ve kullanılmalı ve bu ilişkisel teknoloji aşamalı olarak kaldırılmalıdır. Çoğu (çoğu değilse) programcı ve DBA bu bakış açılarının hiçbirine sahip değildir; ve nesne-ilişkisel empedans uyumsuzluğunu yalnızca yaşamın bir gerçeği olarak görmek Bilişim teknolojisi başa çıkmak zorunda.

O / R eşlemesinin bazı durumlarda işe yaradığı, ancak muhtemelen aşırı satıldığı da tartışılmaktadır: sakıncalarının yanı sıra avantajları da vardır. Şüpheciler, bazı durumlarda çok az değer katacağı için, kullanmadan önce dikkatlice düşünmeye değer olduğuna işaret ediyor.^[8]

Ayrıca bakınız

• Nesne-ilişkisel haritalama
• Nesne-ilişkisel veritabanı

Referanslar

Dış bağlantılar

• Nesne-İlişkisel Empedans Uyuşmazlığı - Çevik Veri Denemesi
• Bilgisayar Biliminin Vietnam'ı - Uyumsuzluk problemlerine örnekler