Bazı aile ağacı yazılımlarının geliştiricisiyim (C ++ ve Qt ile yazılmış). Müşterilerimden biri bana bir hata raporu gönderene kadar hiçbir sorun yaşamadım. Sorun şu ki, müşterinin kendi kızı olan iki çocuğu var ve sonuç olarak hatalar nedeniyle yazılımımı kullanamıyor.

Bu hatalar, işlenen aile grafiğiyle ilgili çeşitli iddia ve değişmezlerimin sonucudur (örneğin, bir döngü yürüdükten sonra, program X'in Y'nin babası ve dedesi olamayacağını belirtmektedir).

Tüm veri iddialarını kaldırmadan bu hataları nasıl çözebilirim?

Görünüşe göre siz (ve / veya şirketiniz) bir soy ağacının ne olması gerektiği konusunda temel bir yanlış anlaşılmaya sahipsiniz.

Açıklığa kavuşturalım, ayrıca (ürünlerinden biri olarak) portföyünde bir aile ağacı olan bir şirkette çalışıyorum ve benzer sorunlarla mücadele ediyoruz.

Sorun, bizim durumumuzda, ve ben de sizin durumunuzu varsayalım, bir ailenin ne olması gerektiği konusunda son derece düşünülen GEDCOM formatından geliyor . Ancak bu biçim, bir aile ağacının gerçekte nasıl göründüğüne dair bazı yanlış yanılgılar içerir.

GEDCOM'un aynı cinsiyet ilişkileriyle uyumsuzluk, ensest vb.Gibi birçok sorunu var ... Gerçek hayatta hayal ettiğinizden daha sık gerçekleşir (özellikle 1700-1800'e geri giderken).

Aile ağacımızı gerçek dünyada olanlara göre modelledik: Olaylar (örneğin, doğumlar, düğünler, nişan, sendikalar, ölümler, evlat edinmeler vb.). Mantıken imkansız olanlar dışında bunlara herhangi bir kısıtlama getirmiyoruz (örneğin, kişinin kendi ebeveyni olamaz, ilişkiler iki kişiye ihtiyaç duyar, vb.)

Doğrulama eksikliği bize daha "gerçek bir dünya", daha basit ve daha esnek bir çözüm sunuyor.

Bu özel duruma gelince, evrensel olarak geçerli olmadıkları için iddiaları kaldırmanızı öneririm.

(Bu ortaya çıkacak) sorunları görüntülemek için, aynı düğümü gerektiği kadar çizmenizi, bunlardan birini seçerek tüm kopyaları aydınlatarak çoğaltmayı ima etmenizi öneririm.

İddianızı rahatlatın.

Müşterilerinizin% 99,9'una verilerini girerken hata yakalamada büyük olasılıkla çok yardımcı olan kuralları değiştirerek değil.

Bunun yerine, "yine de ekle" ifadesiyle bir uyarıya "ilişki ekleyemiyorum" hatasını değiştirin.

İşte aile ağaçlarıyla ilgili sorun: ağaç değiller. Bunlar asiklik grafikler veya DAG'lardır. İnsan üreme biyolojisinin prensiplerini doğru anlarsam, herhangi bir döngü olmayacaktır.

Bildiğim kadarıyla, Hıristiyanlar bile, soyağacını bir aile DAG'sine dönüştürecek olan kuzenler arasındaki evlilikleri (ve böylece çocukları) kabul ediyorlar.

Hikayenin ahlaki: doğru veri yapılarını seçin.

Çeklerinizi dayandırabileceğiniz bir kişiyi benzersiz bir şekilde tanımlayan bir değeriniz olduğunu düşünüyorum.

Bu biraz zor. Yapıyı bir ağaç tutmak istediğinizi varsayarsak, şunu öneririm:

Varsayın: Akendi kızıyla çocukları var.

Aolarak programa kendisini ekler Agibi B. Babanın rolündeyken, ona erkek arkadaş diyelim.

is_same_for_out()Çıktı üreten programınızın Bdahili olarak giden tüm bağlantıların Averi sunumunda olması gerektiğini bildiren bir fonksiyon ekleyin .

Bu kullanıcı için fazladan iş yapar, ancak BT'nin uygulanması ve bakımı nispeten kolay olacaktır.

Bundan yola çıkarak kod senkronizasyonu üzerinde çalışabilir Ave Btutarsızlıkları önleyebilirsiniz.

Bu çözüm kesinlikle mükemmel değildir, ancak ilk yaklaşımdır.

Yazılımınız için gerçekten değer yaratan konulara odaklanmalısınız . Bir tüketici için çalışmasını sağlamak için harcanan zaman lisans fiyatına değer mi? Muhtemelen hayır.

Bu müşteriden özür dilemenizi, durumunun yazılımınız için kapsam dışı olduğunu ve geri ödeme yapmasını söylemenizi tavsiye ederim.

Atreides ailesini (modern, Dune veya antik Oedipus Rex ) bir test çantası olarak kurmuş olmalısınız . Dezenfekte edilmiş verileri test durumu olarak kullanarak hataları bulamazsınız.

"Git" gibi dillerin iddialarda bulunmamasının nedenlerinden biri de budur. Muhtemelen düşünmediğiniz vakaları çok sık ele almak için kullanılırlar. Sadece imkansız olduğunu iddia etmelisiniz, sadece olası değil . İkincisini yapmak, iddialara kötü bir itibar veren şeydir. Her yazdığınızda assert(, on dakika yürüyüp gerçekten düşünün.

Özellikle rahatsız edici durumunuzda, böyle bir iddianın nadir fakat olası koşullar altında sahte olması hem düşünülebilir hem de korkunçtur. Bu nedenle, yalnızca "Bu yazılım sunduğunuz senaryoyu işlemek için tasarlanmamıştır" demekse uygulamanızda kullanın.

Büyük, büyük, büyük büyükbabanızın imkansız olarak babanız olduğunu iddia etmek makul bir şeydir.

Yazılımınızı test etmek için işe alınmış bir test şirketi için çalışsaydım, elbette bu senaryoyu sunardım. Neden? Her çocuk, ancak akıllı 'kullanıcı' aynı şeyi yapacak ve sonuçta ortaya çıkan 'hata raporunda' zevk alacaktır.

Böyle berbat bir durum hakkında yorum yapmaktan nefret ediyorum, ancak tüm değişmezlerinizi reddetmemenin en kolay yolu, grafiğinizde ensest babasına vekalet eden bir hayalet tepe noktası oluşturmaktır.

Bu yüzden aile ağacı yazılımları üzerinde biraz çalıştım. Bence çözmeye çalıştığınız sorun, sonsuz döngülere girmeden ağacı yürüyebilmeniz gerektiğidir - başka bir deyişle ağacın döngüsel olmaması gerekir.

Ancak, bir kişi ile atalarından biri arasında sadece bir yol olduğunu iddia ediyorsunuz. Bu, döngü olmadığını garanti eder, ancak çok katıdır. Biyolojik olarak konuşursak, torunlaşma, yönlendirilmiş bir asiklik grafiktir (DAG). Sahip olduğunuz durum kesinlikle yozlaşmış bir durumdur, ancak bu tür şeyler her zaman büyük ağaçlarda olur.

Örneğin, n kuşağında sahip olduğunuz 2 ^ n ataya bakarsanız, çakışma yoksa, MS 1000'de hayatta olanlardan daha fazla ataya sahip olursunuz. Yani, çakışma olmalı.

Ancak, geçersiz, sadece kötü veri döngüleri alma eğilimindedir. Ağacın üzerinden geçiyorsanız, döngüler ele alınmalıdır. Bunu her bir algoritmada veya yükte yapabilirsiniz. Yükte yaptım.

Bir ağaçta gerçek döngüleri bulmak birkaç yolla yapılabilir. Yanlış yol, belirli bir kişiden her atayı işaretlemektir ve çaprazlama yaparken, bir sonraki adıma geçeceğiniz kişi zaten işaretliyse, bağlantıyı kesin. Bu potansiyel olarak doğru ilişkileri kesecektir. Bunu yapmanın doğru yolu, her bir bireyden başlamak ve her bir atayı o kişinin yoluyla işaretlemektir. Yeni yol bir alt yol olarak geçerli yolu içeriyorsa, bu bir döngüdür ve kesilmelidir. Yolları, karşılaştırma ve depolamayı çok hızlı yapan <bool> vektörü (MFMF, MFFFMF vb.) Olarak saklayabilirsiniz.

İki yineleyici göndermek ve alt küme testiyle çarpışıp çarpışmadığını görmek gibi döngüleri algılamanın birkaç yolu daha vardır, ancak yerel depolama yöntemini kullandım.

Ayrıca bağlantıyı gerçekten koparmanız gerekmediğini, normal bir bağlantıdan bazı zayıf algoritmaların takip etmediği bir 'zayıf' bağlantıya dönüştürebileceğinizi unutmayın. Hangi bağlantıyı zayıf olarak işaretleyeceğinizi seçerken de dikkat etmek isteyeceksiniz; bazen doğum tarihi bilgilerine bakarak döngünün nerede kırılması gerektiğini anlayabilirsiniz, ancak çoğu zaman hiçbir şey bulamazsınız çünkü çok fazla veri eksiktir.

Aptalca bir soru için başka bir sahte ciddi cevap:

Asıl cevap, uygun bir veri yapısı kullanmaktır. İnsan şecere, döngüsü olmayan saf bir ağaç kullanılarak tam olarak ifade edilemez. Bir çeşit grafik kullanmalısınız. Ayrıca, daha ileri gitmeden önce bir antropologla konuşun, çünkü "Batılı ataerkil tek eşli evlilik" in en basit durumunda bile, benzer hataların şecere modellemeye çalışırken yapılabileceği başka birçok yer var.

Burada tartışıldığı gibi yerel olarak tabu ilişkilerini göz ardı etmek istesek bile, bir soy ağacına döngüleri tanıtmak için mükemmel derecede yasal ve tamamen beklenmedik yollar vardır.

Örneğin: http://en.wikipedia.org/wiki/Cousin_marriage

Temel olarak, kuzen evlilik sadece yaygın ve beklenen değil, insanların binlerce küçük aile grubundan dünya çapında 6 milyar nüfusa gitmesinin sebebidir. Başka türlü çalışamaz.

Şecere, aile ve soy söz konusu olduğunda gerçekten çok az sayıda evrensel var. Teyzenin kim olabileceğini veya kiminle evlenebileceğini veya çocukların miras amacıyla nasıl meşrulaştırıldığını düşündüren normlar hakkında neredeyse her türlü varsayım, dünyanın veya tarihin herhangi bir yerinde bir istisna ile altüst olabilir.

Potansiyel yasal çıkarımlar bir yana, düğümün tek ve tek kişi olabileceğini varsaymak yerine, bir aile ağacındaki bir 'düğüme' önceki bir kişi olarak davranmanız gerektiği görülmektedir.

Ağaç düğümünün haleflerin yanı sıra bir kişiyi içermesini sağlayın - ve sonra aynı kişinin farklı halefleri olan aynı kişiyi içeren başka bir düğüme sahip olabilirsiniz.

Birkaç cevap, iddiaları / değişmezleri korumanın yollarını göstermiştir, ancak bu, iddiaların / değişmezlerin yanlış kullanımı gibi görünmektedir. İddialar doğru olması gereken bir şeyin doğru olduğundan emin olmak ve değişmezler değişmemesi gereken bir şeyin değişmemesini sağlamak içindir.

Burada iddia ettiğiniz şey, ensest ilişkilerinin olmadığıdır. Açıkçası onlar yapmak sizin iddiası geçersiz nedenle, mevcuttur. Bu iddia üzerinde çalışabilirsiniz, ancak asıl hata iddianın kendisidir. İddia kaldırılmalıdır.

Soy ağacınız yönlendirilmiş ilişkiler kullanmalıdır. Bu şekilde bir döngünüz olmaz.

Şecere verileri döngüseldir ve döngüsel olmayan bir grafiğe sığmaz, bu nedenle döngülere karşı iddialarınız varsa bunları kaldırmalısınız.

Özel görünüm oluşturmadan bunu bir görünümde ele almanın yolu, döngüsel üst öğeye "hayalet" üst öğe olarak davranmaktır. Başka bir deyişle, bir kişi aynı kişiye hem baba hem de büyükbaba olduğunda, büyükbaba düğümü normal olarak gösterilir, ancak baba düğümü, "" büyükbabayı gör "gibi basit bir etikete sahip bir" hayalet "düğümü olarak oluşturulur. ) ve büyükbabayı işaret eder.

Hesaplamalar yapmak için, döngüsel grafikleri işlemek için mantığınızı geliştirmeniz gerekebilir, böylece bir döngü varsa bir düğüm birden fazla ziyaret edilmez.

En önemli şey avoid creating a problem, bu yüzden bir döngüden kaçınmak için doğrudan bir ilişki kullanmanız gerektiğine inanıyorum .

@Markmywords'ün dediği gibi, #inciri "fritzl.h" ekleyin.

Sonunda söylemeliyim recheck your data structure. Belki orada bir şeyler ters gidiyor (belki çift yönlü bağlantılı bir liste sorununuzu çözer).

İddialar gerçeklikten kurtulamıyor

Genellikle iddialar gerçek verilerle temastan kurtulamaz. Hangi verilere ve hangilerinin kapsam dışı olduğuna karar vermek için yazılım mühendisliği sürecinin bir parçasıdır.

Devirli aile grafikleri

Aile "ağaçlar" ile ilgili olarak (aslında döngüler de dahil olmak üzere tam şişmiş grafikler), güzel bir fıkra vardır:

Yetişkin bir kızı olan bir dulla evlendim. Bizi sık sık ziyaret eden babam üvey kızıma aşık oldu ve onunla evlendi. Sonuç olarak, babam oğlum, kızım da annem oldu. Bir süre sonra, eşime babamın kardeşi olan bir oğul ve amcam verdim. Babamın karısının (aynı zamanda kızım ve annem olan) bir oğlu oldu. Sonuç olarak, aynı kişide bir erkek kardeşim ve bir torunum var. Eşim şimdi anneannem, çünkü o annemin annesi. Ben de eşimin kocasıyım ve aynı zamanda eşimin üvey torunuyum. Başka bir deyişle, ben kendi dedem.

Suretler veya "bulanık babalık" dikkate alındığında işler daha da garipleşir .

Bununla nasıl başa çıkılır?

Döngüleri kapsam dışı olarak tanımlayın

Yazılımınızın bu tür nadir durumlarla ilgilenmemesi gerektiğine karar verebilirsiniz. Böyle bir durum meydana gelirse, kullanıcı farklı bir ürün kullanmalıdır. Bu, daha yaygın vakalarla uğraşmayı çok daha sağlam hale getirir, çünkü daha fazla iddia ve daha basit bir veri modeli tutabilirsiniz.

Bu durumda, yazılımınıza bazı iyi alma ve verme özellikleri ekleyin, böylece kullanıcı gerektiğinde farklı bir ürüne kolayca geçiş yapabilir.

Manuel ilişkilere izin ver

Kullanıcının manuel ilişkiler eklemesine izin verebilirsiniz. Bu ilişkiler "birinci sınıf vatandaşlar" değildir, yani yazılım onları olduğu gibi alır, kontrol etmez ve ana veri modelinde ele almaz.

Kullanıcı daha sonra nadir vakaları elle halledebilir. Veri modeliniz hala oldukça basit kalacak ve iddialarınız devam edecektir.

Manuel ilişkilere dikkat edin. Onları tamamen yapılandırılabilir hale getirme ve böylece tamamen yapılandırılabilir bir veri modeli oluşturma cazibesi vardır. Bu işe yaramaz: Yazılımınız ölçeklenmez, garip hatalar alırsınız ve son olarak kullanıcı arayüzü kullanılamaz hale gelir. Bu anti-patern "yumuşak kodlama" olarak adlandırılır ve "Günlük WTF" bunun örnekleri ile doludur.

Veri modelinizi daha esnek hale getirin, iddiaları atlayın, değişmezleri test edin

Son çözüm, veri modelinizi daha esnek hale getirmektir. Neredeyse tüm iddiaları atlamanız ve veri modelinizi tam gelişmiş bir grafiğe dayandırmanız gerekir. Yukarıdaki örnekte gösterildiği gibi, kendi büyükbabanız olmak kolayca mümkündür, böylece döngüler bile yapabilirsiniz.

Bu durumda, yazılımınızı kapsamlı bir şekilde test etmelisiniz. Neredeyse tüm iddiaları atlamanız gerekiyordu, bu yüzden ek hatalar için iyi bir şans var.

Olağandışı test senaryolarını kontrol etmek için bir test veri üreteci kullanın. Haskell , Erlang veya C için hızlı kontrol kütüphaneleri vardır . Java / Scala için ScalaCheck ve Nyaya vardır . Bir test fikri, rastgele bir popülasyonu simüle etmek, rastgele karışmasına izin vermek, ardından yazılımınızın önce içe aktarıp ardından sonucu dışa aktarması olacaktır. Beklenti, çıkıştaki tüm bağlantıların da giriş ve çıkış ayetinde olması olacaktır.

Bir mülkün aynı kaldığı duruma bir değişmez denir. Bu durumda değişmez, simüle edilen popülasyondaki bireyler arasındaki "romantik ilişkiler" kümesidir. Mümkün olduğunca çok değişmez bulmaya çalışın ve bunları rastgele oluşturulmuş verilerle test edin. Değişmezler işlevsel olabilir, örneğin:

• daha "romantik ilişkiler" ekleseniz bile bir amca bir amca kalır
• her çocuğun bir ebeveyni vardır
• iki kuşaktan oluşan bir nüfusta en az bir büyük ebeveyn var

Veya teknik olabilirler:

• Yazılımınız 10 milyar üyeye kadar bir grafikte çökmeyecek (kaç bağlantı olursa olsun)
• Yazılımınız O (düğüm sayısı) ve O (kenar sayısı ^ 2) ile ölçeklendirilir
• Yazılımınız 10 milyar üyeye kadar her aile grafiğini kaydedip yeniden yükleyebilir

Simüle edilmiş testleri uygulayarak, çok sayıda garip köşe kutusu bulacaksınız. Onları düzeltmek çok zaman alacaktır. Ayrıca çok fazla optimizasyon kaybedeceksiniz, yazılımınız çok daha yavaş çalışacaktır. Buna değer olup olmadığına ve bunun yazılımınızın kapsamında olup olmadığına karar vermelisiniz.

Tüm iddiaları kaldırmak yerine, bir kişinin kendi ebeveyni veya diğer imkansız durumlar gibi şeyleri kontrol etmeli ve bir hata sunmalısınız. Belki de kullanıcı sık karşılaşılan giriş hatalarını algılayabilmesi olası değilse uyarı verir, ancak her şey doğruysa çalışır.

Verileri her bir kişi için kalıcı bir tamsayı olan bir vektörde saklar ve adı geçen int'in vektörün endeksi olduğu ebeveynleri ve çocukları kişi nesnelerinde saklarım. Bu, nesiller arasında gitmek için oldukça hızlı olurdu (ancak isim aramaları gibi şeyler için yavaş). Nesneler, oluşturuldukları sıraya göre olacaktır.

Babayı çoğaltın (veya symlink / reference kullanın).

Örneğin, hiyerarşik veritabanı kullanıyorsanız:

$ #each person node has two nodes representing its parents.
$ mkdir Family
$ mkdir Family/Son
$ mkdir Family/Son/Daughter
$ mkdir Family/Son/Father
$ mkdir Family/Son/Daughter/Father
$ ln -s Family/Son/Daughter/Father Family/Son/Father
$ mkdir Family/Son/Daughter/Wife
$ tree Family
Family
└── Son
    ├── Daughter
    │   ├── Father
    │   └── Wife
    └── Father -> Family/Son/Daughter/Father

4 directories, 1 file