Genel Hiyerarşilerin dönüşümü

Question

Değerli arkadaşlar;

Genel hiyerarşiler yani kısaca birbiri ile aynı tür varlıkların modellenmesi kullanılan yapılardır.Diyagramda süper ve alt tiplerin de ilişkisel modelinde direk bir karşılığı yoktur.

Sizinde bildiğiniz gibi birbirine benzeyen varlıkların modellenmesi veri modellemenin en karmaşık konularından biridir.

Örnek

Müşteriyi ve Tedarikçiyi alt tür Kişiyi de süper tür olarak düşünelim bu tür yapı en basit şekilde üç türlü modele dönüştürülebilir.

YÖNTEMLER

1.Yöntem;

Süper türler için ve her alt tür için ayrı,ayrı tablolar

Süper tür ortak özellikler .........................KİŞİ tablosu açılacak

Alt Türler kendine has    ..........................MÜŞTERİ ve TEDARİKÇİ tabloları açılacak

 

2.Yöntem;

Yalnızca tek bir ortak tip tablosu.

Tüm bu özellikler tabloda  saklanacaktır.Bir kaydın hangi alt tipe ait olduğu kategori fieldi eklenerek belirlenecek..............................................KİŞİ tablo adında tek bir tablo açılacak.

 

3.Yöntem

Her alt tip için bir tablo.

Süper tür tablosu yok..........................Yok!

Süper tür özellikleri her alt tip tablosunda tekrar eder.......................MÜŞTERİ ve TEDARİKÇİ iki adet tablo açılır.

Arkadaşlar şimdi siz bir projeye başlasanız hangi yöntemi seçerdiniz veya FileMaker de önerebileceğiniz bildiğiniz başka bir yöntem var mı? Ustalardan burada detaylı bilgi isteriz.

Saygılarımla selam ederim hayırlı programlamalar.

 

 

Answer 1

Nuri abi merhaba, kendi bakış açımla hızlı bir değerlendirme de ben yapayım.

 

İlişki ve tablo yapısı için kullanılabilecek bir çok yöntem var. Doğrusu şu, iyisi bu demek tek başına yeterli ve mümkün değil. Proje özelinde değerlendirmek lazım. Özellikle "custom" projelerde önemli kriterlerden birisi de Şemsi abinin dediği gibi müşteri kullanım alışkanlığı.

 

Bu tip kararlar vermeyi gerektiren konuları optimizasyon problemlerine benzetiyorum, her bir karar için artılar da eksiler de var. Ayrıca kısıtlarımız var.

Artılar ve eksiler genel anlamda teknik tarafı; bizi rahatlatacak, işin süresini artıracak yada kısaltacak, karmaşıklığı artıracak yada azaltacak faktörler.

Kısıtlar ise projenin süresi, bütçesi, büyüklüğü, kullanım şekli, alışkanlıklar gibi artırabileceğimiz maddeler. Mevcut kısıtların içinde kalmak şartıyla bizim için en faydalı yöntemi proje için belirlemek lazım.

 

Ek bir not, eninde sonunda kararlı çalışan bir çözümü müşteriye ulaştırmak önemli. Arka planda kaç tablo olduğu, script, layout sayısı kullanıcıyı ilgilendirmez. Kullanıcı için kullanıcı deneyimi, kararlı çalışan sistem, kolay kullanım ve bakım önceliklidir. Veritabanı yapısı da muhakkak iyi düşünülmeli ancak kullanıcı ihtiyaçları, süreçler iyi analiz edilmesi şart. Bende burada daha çok UX (kullanıcı deneyimi) hakkında soruların eksiğinden yakınıyorum. Neyseki Şemsi abi arada güzel örnekler paylaşıyor.

Answer 2

Nuri Hocam,bu tür tercihler genellikle çalışılan ülkedeki anlayış ya da alışkanlıklar ile ilgili sanırım.Amerikalılar genellikle,temasa geçilen hatta temas ihtimali olan herkesi "Contacts" adıyla bir tabloda tutuyor,müşteriye,tedarikçiye fatura ve satışa,teklife vs vs aklınıza gelecek her tabloya oradan çağırıyorlar.Müşteri mi,tedarikçi mi "Contacts" içinde ayırıyorlar.

Bizde ise bu tür bir akış,çok alışabileceğimiz bir mantık değil.Bence bize en uygun yaklaşım;Müşteri ya da tedarikçi tablolarının her biri için bire-çok ilişki biçimiyle ayrı ayrı kişi tabloları oluşturmak...

Ancak bütün bunlar belki bir paket yazılım için geçerli olabilir ya da olmalıdır.Müşteriye özel tasarlanan bir yazılımda ise konu,örnekleriyle son kullanıcıya izah edilerek kullanım alışkanlıklarına uygun bir akış şeması tasarlamak daha doğru gibi....

Answer 3

Şemsi bey;

Baştan şunu belirtmek isterim ki burada bu konular pek değinilmiyor veya tartışılmıyor bu konuda soruda gelmiyor olabilir ancak bu sorduğum soru veri modellemenin ana damarı Varlıkların hiyerarşisi Süper key'ler alt tipler Normalizasyon kuralları ,DeNormalizasyon İlişki türleri gibi konular bu konu Amerikada uzun ,uzun tartışılıyor bizde İngilizce olmadığı için Translate ile çat pat birşeyler öğrenmeye çalışıyorum böyle bir tartışmayı burada dile getirip Üstadlardan bu konularda fikirlerini öğrenmek istedim.

Ben Personel taşıma dosyası üzerinde çalışıyorum 1. ve 3 üncü yöntemlerde dosyamı planlayıp işimi gördüm ama acaba başka yaklaşımlar varmı diye merak ettim. Ray Clagon Filemaker 9 da İnventory adlı bir dosyada KİŞİLER diye bir tablo açmış burada id_müşteri ve id_taşeron diye iki anahtar alan belirleyip Taşeron ve Müşterileri tek bir tabloda tutmuş zaten satış faturası ve Alış Faturası ayrı ayrı tablo olduğu için bi sıkıntı olmamış Alış faturasını id_taşeron ile ilişki kurdurmuş Satış faturasını id_müşteri ile ilişki kurmuş.Filemaker burada esnek istediğiniz şekilde planlanıyor ancak artıları eksileri nedir diye tartışılsın istedim bu konuyu ben veritabanının temeli olarak görüyorum.

Saygılarımla selem ederim.