İlişkileri Çizin

🌐 28 dilde daha mevcut

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku

Data Architect kursunun 2. bölümü olan Veriyi Anlam İçin Modellemek bölümündeki 6 modülden 2.‘si. Her modül kendi başına okunabilir. Önceki: İsimlere Kulak Verin · Sonraki: Mantıksal Modeli Kurun

Bu modülün yanıtladığı soru: Aday varlıkları kavramsal bir veri modeline nasıl dönüştürürüm?

Tahtada isimler var. Şimdi kutular arasındaki çizgileri öğrenmek istiyorum, çünkü bir varlıklar topluluğu henüz gerçek anlamda bir veri modeli değildir. Anlamın büyük kısmı ilişkilerde yaşar. Bir Perakende Ortağı dağıtım merkezleri işletir. Bir yük listesi teslimatları listeler. Bir teslimat bir Alıcıya gider. Bir ekip bir kamyonu kullanır. Bu ifadelerin her biri bana iş hakkında bir şey söyler ve her biri sormam için bir soru daha verir.

İşin Diliyle Başlayın

Hâlâ Salesforce’tan bahsetmek istemiyorum. Bunun bir arama ilişkisi mi yoksa ana-ayrıntı ilişkisi mi olması gerektiğini sormuyorum, Salesforce bağlantı nesnelerini (Salesforce Junction Object) düşünmüyorum ya da bir üst kayıt silindiğinde ne olacağına karar vermiyorum. İş ilişkisini anlamaya çalışıyorum.

“Bir Perakende Ortağı dağıtım merkezleri işletir” ifadesini alın. Basit görünüyor. Ama bir Perakende Ortağının bir DC’si mi olabilir, çok mu? Steve Trucking’de her Perakende Ortağı, Steve Trucking’in hizmet verdiği her bölgede bir bölgesel dağıtım merkezi işletir; yani çok. Bir DC birden fazla Perakende Ortağına ait olabilir mi? Bir DC kendi personeli ve geçmişiyle kendi başına önemli mi, yoksa yalnızca bir adres mi? Bir Perakende Ortağı ayrılırsa onun DC’leri hâlâ umurumuzda mı?

Bunlar Salesforce soruları değil. İş sorularıdır ve yanıtları modeli tamamen değiştirebilir.

Çizgileri Okuyun

Daha derine inmeden önce, bundan sonra her diyagramda kullanacağımız dili size vermek istiyorum. Küçük bir dil. İki kutu arasındaki bir çizgi, iki şeyin ilişkili olduğunu söyler; uçlarındaki işaretler de kaç tane olduğunu.

Hiç işareti olmayan sade bir çizgiyle başlayın. Beyaz tahtada ben de oradan başlarım: bu iki ismin ilişkili olduğunu biliyorum, yalnızca nasıl olduğunu henüz sormadım. Sonra uçlar işaret alır. Çizgiyi kesen tek bir çubuk bir anlamına gelir. Kaz ayağı, yani bir kuşun ayağı gibi üçe ayrılan uç, çok anlamına gelir. Bu modülün ilerleyen kısmında ilkinin yanında ikinci bir işaret, bir çubuk ya da bir daire belirdiğini göreceksiniz; o da farklı bir soruyu yanıtlar: hiç olmayabilir mi?

Hatırlanacak tek kural: her işareti dokunduğu kutuda okursunuz. Kutuya en yakın işaret en fazla kaç tane olabileceğini, ondan sonraki işaret en az kaç tane olabileceğini söyler.

Click to enlarge

Otur, Bekle, Modelle

Steve Trucking’den önce 1. modüldeki köpeklere dönelim. Beş kutumuz vardı: Sahip, Yetiştirici, Köpek, Irk ve Numara. Şimdi aralarındaki çizgileri soruyorum.

Bir mi çok mu? Bir sahibin birden fazla köpeği olabilir; Ana’nın iki köpeği var. Bir köpeğin bir sahibi vardır, en azından bizim modelimizde. Bu bire-çoktur: Sahip tarafında bir çizgi, Köpek tarafında bir karga ayağı. Yetiştirici de aynı biçimdedir: bir yetiştirici birçok köpek yetiştirir.

Hiç olmayabilir mi? Max barınaktan geldi, yani hiç yetiştiricisi yok. Yetiştirici ucu bir daire alır: bir köpeğin sıfır ya da bir yetiştiricisi vardır. Ama her köpeğin bir sahibi vardır, bu yüzden o uç ikinci bir çizgi alır: tam olarak bir.

Çoka-çok mu? Bir köpek birçok numara bilir ve bir numarayı, diyelim Otur’u, birçok köpek bilir. Bu çoka-çoktur ve tam da gizli bir kavram aramaya gittiğim yer burasıdır. Bu köpeğin bu numarayı bilmesiyle ilgili bir şey var mı? Onu ne kadar iyi yaptığı ve ne zaman öğrendiği. İlişkinin kendine ait olguları vardır, bu yüzden kendi başına bir şey olur: Köpek Numarası; köpeğin adı önce gelir, çünkü onu yönlendiren köpektir.

Her çizgi ne anlama geliyor? Bir sahip bir köpeğe sahiptir. Bir yetiştirici onu yetiştirir. Bir köpek numaralarını bilir. Çizgilere ad verin, herkes modeli size geri okuyabilsin.

Şimdi mi, zaman içinde mi? Bella’nın bugün Otur’da ne kadar iyi olduğu mu önemli, yoksa oraya nasıl geldiği mi? Bir eğitmen onu birkaç ayda bir kontrol ediyorsa, her kontrol kendi başına bir kayıttır: ait olduğu Köpek Numarası’nın altında, tarih, beceri düzeyi ve kontrolü kimin yaptığıyla birlikte bir Numara Değerlendirmesi. Bir şeye dönüşmüş bir ilişkinin bile kendi geçmişi olabilir.

Irk’ı şimdilik bağlantısız bırakıyorum. Hâlâ 1. modüldeki soru duruyor: kendi başına bir kutu mu, yoksa köpeğin üzerinde bir sözcük mü? 4. modül bunu çözüyor.

Click to enlarge

Bu soruların her biri gerçek bir işletmede de aynı şekilde işler. Şimdi onları Steve Trucking’e soralım.

“Bir mi, Çok mu?” Diye Sorun

Bir ilişki hakkında anlamak istediğim ilk şeylerden biri onun kardinalitesidir. Bu veritabanı terimidir; soru ise çok daha basittir: bunlardan kaç tanesi şunlardan kaç tanesiyle ilişkili olabilir? Kavramsal düzeyde üç temel kalıp vardır.

Bu, sürecin önemli bir adımıdır: iki farklı ismi alın ve ilişkilerini anlayın. Çoğu durumda bu bire-çok ya da çoka-bir ilişkidir. Bire-bir ilişkiyle ancak nadir durumlarda karşılaşırsınız.

Bire-çok her yerdedir. Bir Perakende Ortağının çok sayıda dağıtım merkezi vardır. Bir yük listesi çok sayıda teslimatı listeler. Bir rotada yaklaşık on durak vardır. Böyle bir dil duyduğumda çizgiyi çizmeye başlarım.

Ve şimdi çizgi işaretlerini alır. Her uç, dokunduğu kutudan kaç tane olduğunu söyler: bir için çubuk, çok için kaz ayağı. Her kutudan okuyun: bir Perakende Ortağının çok sayıda Dağıtım Merkezi vardır.

Click to enlarge

Bire-bir ilişkiler vardır ama nadirdir ve birini bulduğumda bazı sorular sorarım. Bunlar gerçekten iki farklı isim mi, yoksa aynısı mı? Farklıysa aralarındaki bire-bir ilişki nedir? Ve her zaman bire-bir mi olacak, yoksa yalnızca şu an için mi bire-bir? Bunlar veri modelini tasarlamada temel sorulardır. Herhangi bir sabah bir ekip ile bir kamyon bire-bir görünür: iki kişi, bir kamyon, bir rota. Bir ay boyunca öyle değildir ve bu modeldeki en ilginç ilişki tam orada saklanıyor.

Çoka-çok ilişkiler özellikle ilginçtir, çünkü çoğu zaman bize işte başka bir kavram olduğunu söylerler. Bir ekip zaman içinde birden fazla kamyon sürebilir mi? Evet. Bir kamyonu birden fazla ekip sürebilir mi? Ömrü boyunca kesinlikle. Yani ekipler ve kamyonlar arasında çoka-çok bir ilişki vardır. Ama şimdi daha fazlasını bilmek istiyorum. İş, bir ekibin bir kamyonu ne zaman kullandığını önemsiyor mu? Hangi rota için, hangi gün? Atamayı kim yaptı? İlişkinin kendisi önemsediğimiz bilgiler taşıyorsa başka bir iş kavramı keşfetmişizdir: Ekip Ataması (Crew Assignment).

Bu önemli bir modelleme alışkanlığıdır. Bazen en ilginç şey, başta duyduğumuz isimlerden biri değildir. İki isim arasındaki ilişkide saklanıyordur.

İlişkiler Birer Şeye Dönüşebilir

Yöneticilerin farklı düşünmeye başlamasını istediğim yerlerden biri burası. Salesforce’ta nesnelerden ve alanlardan bahsetmeye alışkınız; dolayısıyla kutuları önemli kısım, çizgileri de tesisat gibi görmek kolaydır. Ama ilişkinin kendisinin bir iş anlamı olabilir.

Bir teslimatı ve üzerindeki ürünleri düşünün. Bir teslimat birkaç ürün taşıyabilir; örneğin bir çamaşır makinesi ve bir kurutma makinesi. Bir ürün, aynı buzdolabı modeli, binlerce teslimatta yer alır. Buraya kadar kolay. Peki ya bu teslimatta o üründen kaç tane olduğunu, kurulumunun yapılıp yapılmayacağını ya da eskisinin götürülüp götürülmeyeceğini bilmem gerekirse? Artık yalnızca Teslimat ile Ürün arasındaki bir ilişkiyle ilgilenmiyorum. Bir Teslimat Kalemiyle (Delivery Item) ilgileniyorum ve bu kavram kendine ait bir varlığı hak ediyor.

Salesforce’tan geliyorsanız şimdiden “Bu bir bağlantı nesnesi” diye düşünüyor olabilirsiniz. Yanılmıyorsunuz. Ama oradan başlamak istemiyorum. Bir Teslimat Kalemi, bir Salesforce bağlantı nesnesi (Salesforce Junction Object) olmadan önce bir iş kavramıdır. Önce iş, sonra uygulama.

Bu ilişki varlıkları için, sonunda nerede inşa edilirlerse edilsinler, birkaç alışkanlığım var.

Adını koyun. İşin bunun için zaten bir sözcüğü varsa onlarınkini kullanın. Yoksa iki üst varlığın adlarını alıp birleştirin. Bir sipariş ve bir ürün düşünün. Aralarındaki şey Sipariş Kalemidir (Order Item): sipariş ve siparişteki kalem. Her iki üst varlığın da alt varlığıdır ve Salesforce’ta bir Salesforce bağlantı nesnesi olabilir. Ama hangi ad önce gelir: Kalem Siparişi (Item Order) mi, Sipariş Kalemi (Order Item) mi? Her üst varlığın ne tür veri olduğuna bakın. Ürün referans verisidir; sipariş işlem verisidir ve onu yönlendiren siparişin kendisidir. Dolayısıyla Sipariş Kalemi ya da Sipariş Ürünü olur; tıpkı Salesforce’taki Fırsat Ürünü gibi. Steve Trucking’de bu Teslimat Kalemidir. Yönlendiren ad önce gelir ve kayıt, bakacağınız her listede sahibinin yanında sıralanır.

Ona kendi anahtarını verin. Bir Teslimat Kaleminin Teslimat artı Ürün ile tanımlandığını söyleyip orada durmak caziptir. Bu bir bileşik anahtardır ve bileşik anahtarlarla uğraşmak çok daha zordur: kayda işaret eden her sistem iki yarıyı birden taşımak zorundadır. İlişki varlığına kendi tanımlayıcısını verin; Teslimat artı Ürün’ü kaydın kimliği olarak değil, benzersizlikle ilgili bir kural olarak tutun.

Click to enlarge

Üzerinde neyin olmadığına dikkat edin: bir seri numarası. Bir miktar ile bir seri numarası aynı kayda ait değildir. Miktar bir şeyden birkaç tane sayar; seri numarası tek bir belirli şeyi tanımlar. İşin seri numaralarına ihtiyacı varsa her birim kendi kaydı olur ve beş buzdolabı beş kayıttır. Altında bir Teslimat Kalemi Ayrıntısı bulunan bir Teslimat Kalemi için bir gerekçe göremiyorum. Ya biri ya diğeri: miktarlı bir toplam ya da birim başına bir kayıt. Burada miktar.

Geçmiş isteyen özniteliklere dikkat edin. Bazı ilişki varlıkları oluşturulduktan sonra sabit kalır: bu teslimattaki çamaşır makinesi bu teslimattaki çamaşır makinesi olarak kalır. Diğerleri değişmeye devam eder. Bir ekip bu hafta 117 numaralı kamyonu kullanır, gelecek hafta kamyon başka bir ekibe geçer. İlişki değiştiğinde ve iş önceki halini önemsediğinde ilişki varlığının tarihlere ihtiyacı vardır; dikkat edilmesi gereken de Ekip Atamasıdır. İşin şimdiyi mi yoksa zaman içini mi önemsediğini erkenden sorun; birazdan buna döneceğiz.

İlişkilerin Kardinalitenin Ötesinde Anlamı Vardır

Bir ilişkiyi anlamak için “bire-çok” yeterli değildir. İlişkinin ne anlama geldiğini de bilmek isterim.

Bir teslimatın bir konumu vardır. Hangisi? Çıktığı dağıtım merkezi mi? Gittiği Alıcının evi mi? Bunlar birbirinin yerine kullanılamaz. İki model tamamen aynı kutulara ve aynı kardinaliteye sahip olabilir ve çizgiler bambaşka anlamlara gelebilir. İyi bir modelin yalnızca çizgilerle bağlanmış kutulardan ibaret olmamasının nedeni budur. Çizgilerin adlara ihtiyacı vardır. Diyagramımı başka bir mimara verirsem bir ilişkinin ne anlama geldiğini tahmin etmek zorunda kalmamalı; iş birimine gösteriyorsam da onların tanıdığı bir dili kullanmalı.

Click to enlarge

İsteğe Bağlılık da Önemlidir

“Kaç tane?” sorusunun içinde başka bir soru saklıdır: ilişki zorunlu mu? Bir teslimat bir rotaya konmadan önce var olabilir mi? Olmak zorunda: yük listesi teslimattan bir iki gün önce gelir ve rotalar bir önceki akşam kesinleşir. Bir teslimat Perakende Ortağı olmadan var olabilir mi? Hayır; her teslimat bir ortağın yük listesinden gelir. Bu, isteğe bağlılıktır.

Yine, doğrudan bir Salesforce Zorunlu onay kutusuna atlamayın. “Her teslimatın bir Perakende Ortağı olmalıdır” demek ile “Salesforce, kayıt oluşturulurken Perakende Ortağı alanını zorunlu tutmalıdır” demek arasında fark vardır. Sonunda aynı uygulamaya dönüşebilirler ama aynı ifade değildirler. Birincisi bir iş kuralıdır; ikincisi onu uygulamanın bir yoludur. Mimarlar olarak ikincisine karar vermeden önce birincisini anlamak isteriz.

Diyagramda isteğe bağlılık her uçtaki ikinci işarettir. Kutuya en yakın işaret en fazla kaç tane olabileceğidir: bir için çubuk, çok için kaz ayağı. Ondan sonraki işaret en azıdır: ikinci bir çubuk en az bir anlamına gelir, bir daire sıfır olabileceği anlamına gelir. Yani her Teslimat tam olarak bir Yük Listesinde yer alır ve bir Yük Listesi bir ya da çok sayıda Teslimatı listeler. Bir Teslimat sıfır ya da bir Durakta yer alır, rotaya konana kadar hiçbirinde; bir Durakta da sıfır ya da çok sayıda Teslimat bırakılır.

Click to enlarge

Zaman İlişkileri Değiştirir

Sık sorduğum bir soru: şimdiyi mi kastediyorsunuz, yoksa zaman içini mi?

Bir ekip bir kamyonu kullanır. Şu anda mı? Bugünkü rota için mi? O iki kişi birlikte çalıştığı sürece mi? Bunlar farklı modeller ortaya çıkarır. İş yalnızca bir ekibin bugün hangi kamyonu kullandığını önemsiyorsa model basit kalabilir. Bir ekibin sürdüğü her kamyonu, ne zaman ve hangi rotada sürdüğünü bilmesi gerekiyorsa geçmişe ihtiyacımız vardır ve keşfettiğimiz o Ekip Ataması birden çok önemli hale gelir.

Click to enlarge

Bu, modelleme hatalarının yaygın bir kaynağıdır. Mevcut durumu modelleriz, çünkü ekranda görebildiğimiz odur. Sonra haftalar sonra bir Perakende Ortağı bir hasar talebinde bulunur ve biri sorar: “17 Mart’ta 117 numaralı kamyon hangi ekipteydi?” Ve atama her değiştiğinde yanıtın üzerine yazdığımızı fark ederiz.

Bu geçmişi tutmanın bir yolu, atamayı kendi başına bir kayıt yapmaktır. Bir ekip atandığında başlangıç tarihli bir Ekip Ataması oluştururuz. Atama değiştiğinde eski kayda bir bitiş tarihi koyar ve kendi başlangıç tarihiyle yeni bir kayıt oluştururuz. Artık “Altı ay önce o atama kimdeydi?” sorusu, alan geçmişini ya da bir veri değişikliği günlüğünü kazmak yerine yanıtlaması kolay bir soru olur. Ve bir ekibin çok sayıda ataması olduğunda biri hangisinin güncel olduğunu soracaktır; bu yüzden bir Aktif işareti de eklerdim.

Click to enlarge

Bu yüzden biri bana bir ilişkiden bahsettiğinde yalnızca şeylerin nasıl ilişkili olduğunu sormam. Şunu sorarım: bu ilişki değişiyor mu ve geçmişini önemsiyor muyuz?

Yapılandırmadan Önce Çizin

Steve Trucking modelimiz işe yarar hale geliyor. Hangi ilişkilerin bire-çok olduğunu, bir çoka-çok ilişkinin nerede başka bir kavram sakladığını, hangi ilişkilerin isteğe bağlı olduğunu ve hangilerinin zamanla değiştiğini biliyoruz. Ve hâlâ bir Salesforce nesnesi oluşturmadık. Bu kasıtlı.

Click to enlarge

Bu diyagram iş biriminin önüne koyabileceğim bir şey olmalı ve doğru olup olmadığını bana söylemek için Salesforce bilmeleri gerekmemeli. Salesforce terimleriyle dolu olduğu için onu doğrulayamıyorlarsa fiziksel tasarıma çok hızlı geçmişim demektir.

Mimarın Burada Karar Verdikleri

Kavramsal bir modeldeki ilişkiler üzerinde çalışırken karar verdiğim şeyler:

• Ana iş varlıklarının birbirleriyle nasıl ilişkili olduğu.
• Her ilişkinin, şimdi ve zaman içinde, bire-bir mi, bire-çok mu, çoka-çok mu olduğu.
• Her ilişkinin zorunlu mu isteğe bağlı mı olduğu.
• Bir çoka-çok ilişkinin anlamlı bir iş kavramı saklayıp saklamadığı.
• İlişkinin zamanla değişip değişmediği ve geçmişine ihtiyacımız olup olmadığı.

Arama ilişkisi mi ana-ayrıntı ilişkisi mi, bağlantı yapılandırması, zincirleme silme davranışı ve paylaşım fiziksel kararlardır; oraya geleceğiz. Şu anda hâlâ daha önemli soruyu yanıtlıyoruz: bu iş gerçekte nasıl işliyor? Varlıkları ve aralarındaki ilişkileri anladığımızda onları tanımlayan ayrıntıları eklemeye başlayabiliriz. İşte o zaman kavramsal modelimiz bir mantıksal veri modeline dönüşmeye başlar.