İlişkileri modelleme
Bu makalede, Azure Tablo depolama çözümlerinizi tasarlamanıza yardımcı olacak modelleme işlemi açıklanır.
Etki alanı modelleri oluşturmak, karmaşık sistemlerin tasarımında önemli bir adımdır. Genellikle, iş etki alanını anlamanın ve sisteminizin tasarımını bilgilendirmenin bir yolu olarak varlıkları ve aralarındaki ilişkileri tanımlamak için modelleme işlemini kullanırsınız. Bu bölüm, etki alanı modellerinde bulunan bazı ortak ilişki türlerini Tablo hizmeti tasarımlarına nasıl çevirebileceğinize odaklanır. Mantıksal veri modelinden fiziksel NoSQL tabanlı bir veri modeline eşleme işlemi, ilişkisel veritabanı tasarlarken kullanılandan farklıdır. İlişkisel veritabanları tasarımı genellikle yedekliliği en aza indirmek için iyileştirilmiş bir veri normalleştirme işleminin ve veritabanının nasıl çalıştığının nasıl uygulandığını soyutlayan bildirim temelli bir sorgulama özelliğini varsayar.
Bir-çok ilişkileri
İş etki alanı nesneleri arasında bire çok ilişkiler sık sık gerçekleşir: örneğin, bir departmanda birçok çalışan vardır. Tablo hizmetinde her biri belirli senaryoyla ilgili olabilecek artıları ve dezavantajları olan bire çok ilişkileri uygulamanın çeşitli yolları vardır.
Her departmanın çok sayıda çalışanı ve her çalışanın belirli bir departmanla ilişkili olduğu on binlerce departmanı ve çalışan varlığı olan çok uluslu/bölgesel büyük bir şirket örneğini düşünün. Yaklaşımlardan biri, aşağıdakiler gibi ayrı departman ve çalışan varlıklarını depolamaktır:
Bu örnekte PartitionKey değerini temel alan türler arasındaki örtük bire çok ilişkisi gösterilmektedir. Her departmanda birçok çalışan olabilir.
Bu örnekte aynı bölümdeki bir departman varlığı ve ilgili çalışan varlıkları da gösterilir. Farklı varlık türleri için farklı bölümler, tablolar ve hatta depolama hesapları kullanmayı seçebilirsiniz.
Alternatif bir yaklaşım, aşağıdaki örnekte gösterildiği gibi verilerinizi normalden çıkarmak ve yalnızca normal dışı departman verilerine sahip çalışan varlıklarını depolamaktır. Bu özel senaryoda, departman yöneticisinin ayrıntılarını değiştirme gereksiniminiz varsa, bu normalleştirilmiş yaklaşım en iyi yöntem olmayabilir çünkü bunu yapmak için departmandaki tüm çalışanları güncelleştirmeniz gerekir.
Daha fazla bilgi için bu kılavuzun devamında yer alan Normal dışıleştirme düzenine bakın.
Aşağıdaki tabloda, bire çok ilişkisi olan çalışan ve departman varlıklarını depolamak için yukarıda özetlenen yaklaşımların her birinin artıları ve dezavantajları özetlenmiştir. Ayrıca çeşitli işlemleri ne sıklıkta gerçekleştirmeyi beklediğinizi de göz önünde bulundurmalısınız: Bu işlem yalnızca seyrek gerçekleşiyorsa pahalı bir işlem içeren bir tasarıma sahip olmak kabul edilebilir.
| Yaklaşım | Avantajlar | Dezavantajlar |
|---|---|---|
| Ayrı varlık türleri, aynı bölüm, aynı tablo |
|
|
| Ayrı varlık türleri, farklı bölümler, tablolar veya depolama hesapları |
|
|
| Tek varlık türüne normalleştirme |
|
|
*daha fazla bilgi için bkz. Varlık Grubu İşlemleri
Bu seçenekler arasında nasıl seçim yapabileceğiniz ve hangi avantajların ve dezavantajların en önemli olduğu, belirli uygulama senaryolarınıza bağlıdır. Örneğin, bölüm varlıklarını ne sıklıkta değiştirirsiniz; tüm çalışan sorgularınızın ek departman bilgilerine ihtiyacı var mı? Bölümlerinizdeki veya depolama hesabınızdaki ölçeklenebilirlik sınırlarına ne kadar yakınsınız?
Bire bir ilişkiler
Etki alanı modelleri varlıklar arasında bire bir ilişkiler içerebilir. Tablo hizmetinde bire bir ilişki uygulamanız gerekiyorsa, her ikisini de almanız gerektiğinde ilişkili iki varlığı nasıl bağlayabileceğinizi de seçmeniz gerekir. Bu bağlantı, anahtar değerlerindeki bir kurala göre örtük veya ilgili varlığın her varlığında PartitionKey ve RowKey değerleri biçiminde bir bağlantı depolanarak açık olabilir. İlgili varlıkları aynı bölümde depolamanız gerekip gerekmediğine ilişkin bir tartışma için, Bire çok ilişkiler bölümüne bakın.
Tablo hizmetinde bire bir ilişkileri uygulamanıza yol açabilecek uygulama konuları da vardır:
- Büyük varlıkları işleme (daha fazla bilgi için bkz . Büyük Varlıklar Düzeni).
- Erişim denetimleri uygulama (daha fazla bilgi için bkz. Paylaşılan Erişim İmzalarıyla erişimi denetleme).
İstemciye katılma
Tablo hizmetinde ilişkileri modellemenin yolları olsa da, Tablo hizmetini kullanmanın iki temel nedeninin ölçeklenebilirlik ve performans olduğunu unutmamalısınız. Çözümünüzün performansını ve ölçeklenebilirliğini tehlikeye atacak birçok ilişkiyi modellediğiniz fark ederseniz, tablo tasarımınızda tüm veri ilişkilerini oluşturmanın gerekli olup olmadığını kendinize sormalısınız. İstemci uygulamanızın gerekli birleştirmeleri gerçekleştirmesine izin verirseniz, tasarımı basitleştirebilir ve çözümünüzün ölçeklenebilirliğini ve performansını geliştirebilirsiniz.
Örneğin, sık değişmeyen veriler içeren küçük tablolarınız varsa, bu verileri bir kez alıp istemcide önbelleğe alabilirsiniz. Bu, aynı verileri almak için tekrar tekrar gidiş dönüşleri önleyebilir. Bu kılavuzda incelediğimiz örneklerde, küçük bir kuruluştaki bölüm kümesinin küçük olması ve seyrek değişmesi, istemci uygulamasının bir kez indirebileceği ve verileri aradıkça önbelleğe alabildiği veriler için iyi bir aday olmasını sağlar.
Devralma ilişkileri
İstemci uygulamanız, iş varlıklarını temsil etmek için devralma ilişkisinin bir parçasını oluşturan bir sınıf kümesi kullanıyorsa, bu varlıkları Tablo hizmetinde kolayca kalıcı hale ekleyebilirsiniz. Örneğin, istemci uygulamanızda tanımlanan aşağıdaki sınıf kümeniz olabilir; burada Kişi soyut bir sınıftır.
Tablo hizmetindeki iki somut sınıfın örneklerini, aşağıdaki gibi görünen varlıkları kullanarak tek bir Kişi tablosu kullanarak kalıcı hale gelebilirsiniz:
İstemci kodunda aynı tabloda birden çok varlık türüyle çalışma hakkında daha fazla bilgi için bu kılavuzun devamında yer alan Heterojen varlık türleriyle çalışma bölümüne bakın. Bu, istemci kodundaki varlık türünün nasıl tanınacaklarına ilişkin örnekler sağlar.