Tôi là nhà phát triển một số phần mềm cây gia đình (viết bằng C ++ và Qt). Tôi không có vấn đề gì cho đến khi một trong những khách hàng của tôi gửi cho tôi một báo cáo lỗi. Vấn đề là khách hàng có hai con với con gái riêng của họ và do đó, anh ta không thể sử dụng phần mềm của tôi vì lỗi.

Những lỗi đó là kết quả của những khẳng định và bất biến khác nhau của tôi về biểu đồ gia đình đang được xử lý (ví dụ: sau khi đi một chu kỳ, chương trình nói rằng X không thể là cả cha và ông của Y).

Làm cách nào tôi có thể giải quyết các lỗi đó mà không xóa tất cả các xác nhận dữ liệu?

Có vẻ như bạn (và / hoặc công ty của bạn) có một sự hiểu lầm cơ bản về những gì mà một cây gia đình được cho là.

Hãy để tôi làm rõ, tôi cũng làm việc cho một công ty có (một trong những sản phẩm của nó) một cây gia đình trong danh mục đầu tư của nó, và chúng tôi đã phải vật lộn với các vấn đề tương tự.

Vấn đề, trong trường hợp của chúng tôi, và tôi giả sử trường hợp của bạn cũng vậy, xuất phát từ định dạng GEDCOM cực kỳ quan tâm về những gì một gia đình nên có. Tuy nhiên định dạng này chứa một số quan niệm sai lầm nghiêm trọng về những gì một cây gia đình thực sự trông như thế nào.

GEDCOM có nhiều vấn đề, chẳng hạn như không tương thích với các mối quan hệ đồng tính, loạn luân, v.v ... Điều đó trong cuộc sống thực xảy ra thường xuyên hơn bạn tưởng tượng (đặc biệt là khi quay ngược thời gian đến 1700-1800).

Chúng tôi đã mô hình hóa cây gia đình của chúng tôi với những gì xảy ra trong thế giới thực: Sự kiện (ví dụ: sinh, cưới, đính hôn, đoàn thể, chết, nhận con nuôi, v.v.). Chúng tôi không đặt bất kỳ hạn chế nào cho những điều này, ngoại trừ những điều không thể về mặt logic (ví dụ: một người không thể là cha mẹ của chính mình, quan hệ cần hai cá nhân, v.v ...)

Việc thiếu xác nhận cho chúng ta một "thế giới thực" hơn, giải pháp đơn giản và linh hoạt hơn.

Đối với trường hợp cụ thể này, tôi sẽ đề nghị loại bỏ các xác nhận vì chúng không giữ được phổ biến.

Để hiển thị các vấn đề (sẽ phát sinh), tôi khuyên bạn nên vẽ cùng một nút nhiều lần nếu cần, gợi ý về sự trùng lặp bằng cách thắp sáng tất cả các bản sao khi chọn một trong số chúng.

Thư giãn khẳng định của bạn.

Không phải bằng cách thay đổi các quy tắc, điều này hầu như rất hữu ích cho 99,9% khách hàng của bạn trong việc bắt lỗi khi nhập dữ liệu của họ.

Thay vào đó, thay đổi nó từ một lỗi "không thể thêm mối quan hệ" thành một cảnh báo với "thêm anyway".

Đây là vấn đề với cây gia đình: chúng không phải là cây. Chúng là đồ thị theo chu kỳ hướng hoặc DAG. Nếu tôi hiểu chính xác các nguyên tắc sinh học của sinh sản con người, sẽ không có bất kỳ chu kỳ nào.

Theo như tôi biết, ngay cả các Kitô hữu cũng chấp nhận hôn nhân (và cả con cái) giữa anh em họ, sẽ biến cây gia đình thành một DAG gia đình.

Đạo đức của câu chuyện là: chọn cấu trúc dữ liệu phù hợp.

Tôi đoán rằng bạn có một số giá trị xác định duy nhất một người mà bạn có thể dựa vào séc của mình.

Đây là một khó khăn. Giả sử bạn muốn giữ cấu trúc một cái cây, tôi đề nghị điều này:

Giả sử điều này: Acó con với con gái riêng của mình.

Athêm mình vào chương trình như Avà B. Khi đã ở trong vai trò của cha, hãy gọi nó là bạn trai.

Thêm một is_same_for_out()chức năng cho biết phần tạo đầu ra của chương trình của bạn rằng tất cả các liên kết đến Bnội bộ sẽ được Atrình bày về dữ liệu.

Điều này sẽ làm cho một số công việc bổ sung cho người dùng, nhưng tôi đoán CNTT sẽ tương đối dễ thực hiện và duy trì.

Xây dựng từ đó, bạn có thể làm việc trên đồng bộ mã Avà Bđể tránh sự không nhất quán.

Giải pháp này chắc chắn không hoàn hảo, nhưng là một cách tiếp cận đầu tiên.

Bạn nên tập trung vào những gì thực sự tạo ra giá trị cho phần mềm của bạn . Là thời gian dành cho việc làm cho nó hoạt động cho MỘT người tiêu dùng có xứng đáng với giá của giấy phép? Có khả năng là không.

Tôi khuyên bạn nên xin lỗi khách hàng này, nói với anh ta rằng tình huống của anh ta nằm ngoài phạm vi của phần mềm của bạn và hoàn lại tiền cho anh ta.

Bạn nên thành lập gia đình Atreides (hiện đại, Dune hoặc cổ đại, Oedipus Rex ) làm trường hợp thử nghiệm. Bạn không tìm thấy lỗi bằng cách sử dụng dữ liệu vệ sinh như một trường hợp thử nghiệm.

Đây là một trong những lý do tại sao các ngôn ngữ như "Đi" không có xác nhận. Chúng được sử dụng để xử lý các trường hợp mà bạn có thể không nghĩ tới, tất cả quá thường xuyên. Bạn chỉ nên khẳng định những điều không thể, không đơn giản là những điều không thể . Làm sau này là những gì mang lại cho khẳng định một danh tiếng xấu. Mỗi khi bạn gõ assert(, đi bộ trong mười phút và thực sự nghĩ về nó.

Trong trường hợp đặc biệt đáng lo ngại của bạn, cả hai đều có thể hiểu được và kinh hoàng rằng một khẳng định như vậy sẽ không có thật trong những trường hợp hiếm gặp nhưng có thể xảy ra. Do đó, hãy xử lý nó trong ứng dụng của bạn, nếu chỉ nói "Phần mềm này không được thiết kế để xử lý tình huống mà bạn trình bày".

Khẳng định rằng ông cố vĩ đại, vĩ đại, vĩ đại của bạn là cha của bạn là không thể là một điều hợp lý để làm.

Nếu tôi đang làm việc cho một công ty thử nghiệm được thuê để kiểm tra phần mềm của bạn, tất nhiên tôi sẽ trình bày kịch bản đó. Tại sao? Mọi 'người dùng' thông minh nhưng chưa thành niên sẽ làm điều tương tự chính xác và thưởng thức trong 'báo cáo lỗi'.

Tôi ghét bình luận về một tình huống sai lầm như vậy, nhưng cách dễ nhất để không tái lập tất cả các bất biến của bạn là tạo một đỉnh ảo trong biểu đồ của bạn hoạt động như một proxy trở lại với người cha loạn luân.

Vì vậy, tôi đã thực hiện một số công việc trên phần mềm cây gia đình. Tôi nghĩ vấn đề bạn đang cố gắng giải quyết là bạn cần có khả năng đi trên cây mà không phải đi vào những vòng lặp vô hạn - nói cách khác, cây cần phải có tính chu kỳ.

Tuy nhiên, có vẻ như bạn đang khẳng định rằng chỉ có một con đường giữa một người và một trong những tổ tiên của họ. Điều đó sẽ đảm bảo rằng không có chu kỳ, nhưng quá nghiêm ngặt. Về mặt sinh học, hậu duệ là một đồ thị chu kỳ có hướng (DAG). Trường hợp bạn có chắc chắn là một trường hợp thoái hóa, nhưng loại điều đó xảy ra mọi lúc trên các cây lớn hơn.

Ví dụ: nếu bạn nhìn vào tổ tiên 2 ^ n bạn có ở thế hệ n, nếu không có sự trùng lặp, thì bạn sẽ có nhiều tổ tiên vào năm 1000 sau Công nguyên hơn so với những người còn sống. Vì vậy, đã có sự chồng chéo.

Tuy nhiên, bạn cũng có xu hướng nhận được các chu kỳ không hợp lệ, chỉ là dữ liệu xấu. Nếu bạn đi ngang qua cây, thì phải xử lý các chu kỳ. Bạn có thể làm điều này trong từng thuật toán riêng lẻ hoặc khi tải. Tôi đã làm nó trên tải.

Tìm chu kỳ thực trong cây có thể được thực hiện theo một số cách. Cách sai là đánh dấu mọi tổ tiên từ một cá nhân nhất định và khi đi qua, nếu người bạn sẽ bước tới tiếp theo đã được đánh dấu, sau đó cắt liên kết. Điều này sẽ cắt đứt các mối quan hệ có khả năng chính xác. Cách chính xác để làm điều đó là bắt đầu từ mỗi cá nhân và đánh dấu mỗi tổ tiên bằng đường dẫn đến cá nhân đó. Nếu đường dẫn mới chứa đường dẫn hiện tại dưới dạng đường dẫn phụ, thì đó là một chu kỳ và sẽ bị phá vỡ. Bạn có thể lưu trữ các đường dẫn dưới dạng vectơ <bool> (MFMF, MFFFMF, v.v.) để so sánh và lưu trữ rất nhanh.

Có một vài cách khác để phát hiện các chu kỳ, chẳng hạn như gửi hai vòng lặp và xem liệu chúng có từng va chạm với thử nghiệm tập hợp con không, nhưng cuối cùng tôi đã sử dụng phương thức lưu trữ cục bộ.

Cũng lưu ý rằng bạn không thực sự cần phải cắt liên kết, bạn chỉ có thể thay đổi liên kết từ liên kết bình thường thành liên kết 'yếu', không tuân theo một số thuật toán của bạn. Bạn cũng sẽ muốn cẩn thận khi chọn liên kết nào được đánh dấu là yếu; đôi khi bạn có thể tìm ra nơi nên phá vỡ chu kỳ bằng cách xem thông tin ngày sinh, nhưng thường thì bạn không thể tìm ra bất cứ điều gì vì quá nhiều dữ liệu bị thiếu.

Một câu trả lời nghiêm túc giả cho một câu hỏi ngớ ngẩn:

Câu trả lời thực sự là, sử dụng một cấu trúc dữ liệu thích hợp. Gia phả của con người không thể được thể hiện đầy đủ bằng cách sử dụng một cây thuần túy không có chu kỳ. Bạn nên sử dụng một số loại biểu đồ. Ngoài ra, hãy nói chuyện với một nhà nhân chủng học trước khi tiếp tục với vấn đề này, bởi vì có nhiều nơi khác có thể xảy ra lỗi tương tự khi cố gắng mô hình hóa phả hệ, ngay cả trong trường hợp đơn giản nhất là "hôn nhân gia trưởng phương Tây".

Ngay cả khi chúng ta muốn bỏ qua các mối quan hệ cấm kỵ cục bộ như được thảo luận ở đây, có rất nhiều cách hoàn toàn hợp pháp và hoàn toàn bất ngờ để giới thiệu chu kỳ vào cây gia đình.

Ví dụ: http://en.wikipedia.org/wiki/Cousin_marẩu

Về cơ bản, hôn nhân anh em họ không chỉ phổ biến và được mong đợi, đó là lý do con người đã đi từ hàng ngàn nhóm gia đình nhỏ đến dân số trên toàn thế giới là 6 tỷ. Nó không thể làm việc theo bất kỳ cách nào khác.

Thực sự có rất ít vũ trụ khi nói về phả hệ, gia đình và dòng dõi. Hầu như bất kỳ giả định nghiêm ngặt nào về các quy tắc gợi ý ai là dì, hoặc ai có thể kết hôn với ai, hoặc làm thế nào trẻ em được hợp pháp hóa cho mục đích thừa kế, có thể bị đảo lộn bởi một ngoại lệ nào đó trên thế giới hoặc lịch sử.

Gợi ý pháp lý tiềm tàng sang một bên, có vẻ như bạn cần phải coi một "nút" trên cây gia đình như một người tiền nhiệm thay vì cho rằng nút đó có thể là người duy nhất.

Có nút cây bao gồm một người cũng như những người kế vị - và sau đó bạn có thể có một nút khác sâu hơn vào cây bao gồm cùng một người với những người kế nhiệm khác nhau.

Một vài câu trả lời đã chỉ ra các cách để giữ các xác nhận / bất biến, nhưng điều này có vẻ như là một sự lạm dụng của các xác nhận / bất biến. Các xác nhận là để đảm bảo một cái gì đó là đúng là đúng và bất biến là để đảm bảo một cái gì đó không nên thay đổi sẽ không thay đổi.

Điều bạn đang khẳng định ở đây là mối quan hệ loạn luân không tồn tại. Rõ ràng họ làm tồn tại, vì vậy khẳng định bạn không hợp lệ. Bạn có thể làm việc xung quanh xác nhận này, nhưng lỗi thực sự nằm ở chính khẳng định đó. Khẳng định nên được loại bỏ.

Cây gia đình của bạn nên sử dụng quan hệ trực tiếp. Bằng cách này, bạn sẽ không có một chu kỳ.

Dữ liệu phả hệ là tuần hoàn và không phù hợp với biểu đồ chu kỳ, vì vậy nếu bạn có xác nhận chống lại chu kỳ, bạn nên loại bỏ chúng.

Cách để xử lý việc này trong chế độ xem mà không tạo chế độ xem tùy chỉnh là coi cha mẹ theo chu kỳ là cha mẹ "ma". Nói cách khác, khi một người vừa là cha vừa là ông nội của cùng một người, thì nút ông nội được hiển thị bình thường, nhưng nút cha được hiển thị dưới dạng nút "ma" có nhãn đơn giản như ("nhìn thấy ông nội" ) và chỉ vào ông nội.

Để thực hiện các phép tính, bạn có thể cần cải thiện logic của mình để xử lý các biểu đồ tuần hoàn để một nút không được truy cập nhiều lần nếu có một chu kỳ.

Điều quan trọng nhất là avoid creating a problem, vì vậy tôi tin rằng bạn nên sử dụng mối quan hệ trực tiếp để tránh có chu kỳ.

Như @markmywords đã nói, #include "fritzl.h".

Cuối cùng tôi phải nói recheck your data structure. Có thể có điều gì đó không ổn ở đó (có thể một danh sách liên kết hai chiều giải quyết vấn đề của bạn).

Khẳng định không tồn tại thực tế

Thông thường các xác nhận không tồn tại liên hệ với dữ liệu trong thế giới thực. Đó là một phần của quy trình công nghệ phần mềm để quyết định, với dữ liệu nào bạn muốn xử lý và dữ liệu nào nằm ngoài phạm vi.

Đồ thị gia đình tuần hoàn

Về "cây" gia đình (thực tế nó là đồ thị đầy đủ, bao gồm cả chu kỳ), có một giai thoại hay:

Tôi kết hôn với một góa phụ có một cô con gái lớn. Cha tôi, người thường đến thăm chúng tôi, đã yêu con gái riêng của tôi và cưới cô ấy. Kết quả là cha tôi trở thành con trai tôi và con gái tôi trở thành mẹ tôi. Một thời gian sau, tôi cho vợ một đứa con trai, là anh trai của bố tôi và chú tôi. Vợ của bố tôi (cũng là con gái tôi và mẹ tôi) có một đứa con trai. Kết quả là tôi có một anh trai và một cháu trai trong cùng một người. Vợ tôi bây giờ là bà tôi, vì cô ấy là mẹ của mẹ tôi. Vì vậy, tôi là chồng của vợ tôi, đồng thời là cháu nội của vợ tôi. Nói cách khác, tôi là ông của chính tôi.

Mọi thứ trở nên kỳ lạ hơn nữa, khi bạn tính đến những người thay thế hoặc "làm cha mờ nhạt".

Làm thế nào để đối phó với điều đó

Xác định chu kỳ là ngoài phạm vi

Bạn có thể quyết định rằng phần mềm của bạn không nên xử lý các trường hợp hiếm gặp như vậy. Nếu trường hợp như vậy xảy ra, người dùng nên sử dụng một sản phẩm khác. Điều này làm cho việc xử lý các trường hợp phổ biến mạnh mẽ hơn nhiều, bởi vì bạn có thể giữ nhiều xác nhận hơn và một mô hình dữ liệu đơn giản hơn.

Trong trường hợp này, hãy thêm một số tính năng nhập và xuất tốt vào phần mềm của bạn để người dùng có thể dễ dàng di chuyển sang một sản phẩm khác khi cần thiết.

Cho phép quan hệ thủ công

Bạn có thể cho phép người dùng thêm quan hệ thủ công. Các mối quan hệ này không phải là "công dân hạng nhất", tức là phần mềm đưa họ theo nguyên trạng, không kiểm tra chúng và không xử lý chúng trong mô hình dữ liệu chính.

Người dùng sau đó có thể xử lý các trường hợp hiếm bằng tay. Mô hình dữ liệu của bạn sẽ vẫn khá đơn giản và các xác nhận của bạn sẽ tồn tại.

Hãy cẩn thận với các quan hệ thủ công. Có một sự cám dỗ để làm cho chúng có thể cấu hình hoàn toàn và do đó tạo ra một mô hình dữ liệu có thể cấu hình đầy đủ. Điều này sẽ không hoạt động: Phần mềm của bạn sẽ không mở rộng quy mô, bạn sẽ gặp các lỗi lạ và cuối cùng giao diện người dùng sẽ trở nên không sử dụng được. Mô hình chống này được gọi là "mã hóa mềm" và "WTF hàng ngày" có đầy đủ các ví dụ cho điều đó.

Làm cho mô hình dữ liệu của bạn linh hoạt hơn, bỏ qua các xác nhận, kiểm tra bất biến

Phương sách cuối cùng sẽ làm cho mô hình dữ liệu của bạn linh hoạt hơn. Bạn sẽ phải bỏ qua gần như tất cả các xác nhận và dựa trên mô hình dữ liệu của mình trên một biểu đồ đầy đủ. Như ví dụ trên cho thấy, có thể dễ dàng trở thành ông của chính bạn, vì vậy bạn thậm chí có thể có chu kỳ.

Trong trường hợp này, bạn nên kiểm tra rộng rãi phần mềm của bạn. Bạn đã phải bỏ qua gần như tất cả các xác nhận, vì vậy có một cơ hội tốt cho các lỗi bổ sung.

Sử dụng một trình tạo dữ liệu thử nghiệm để kiểm tra các trường hợp thử nghiệm bất thường. Có thư viện kiểm tra nhanh chóng cho Haskell , Erlang hoặc C . Đối với Java / Scala có ScalaCheck và Nyaya . Một ý tưởng thử nghiệm sẽ là mô phỏng một quần thể ngẫu nhiên, để nó giao thoa ngẫu nhiên, sau đó cho phần mềm của bạn nhập trước rồi xuất kết quả. Kỳ vọng sẽ là, tất cả các kết nối trong đầu ra cũng nằm trong đầu vào và ngược lại.

Một trường hợp, trong đó một tài sản giữ nguyên được gọi là bất biến. Trong trường hợp này, bất biến là tập hợp "quan hệ lãng mạn" giữa các cá nhân trong dân số mô phỏng. Cố gắng tìm ra càng nhiều bất biến càng tốt và kiểm tra chúng với dữ liệu được tạo ngẫu nhiên. Bất biến có thể là chức năng, ví dụ:

• một người chú ở lại một người chú, ngay cả khi bạn thêm "quan hệ lãng mạn"
• mỗi đứa trẻ đều có cha mẹ
• một dân số có hai thế hệ có ít nhất một ông bà

Hoặc họ có thể là kỹ thuật:

• Phần mềm của bạn sẽ không gặp sự cố trên biểu đồ lên tới 10 tỷ thành viên (cho dù có bao nhiêu kết nối)
• Phần mềm của bạn chia tỷ lệ với O (số nút) và O (số cạnh ^ 2)
• Phần mềm của bạn có thể lưu và tải lại mỗi biểu đồ gia đình lên tới 10 tỷ thành viên

Bằng cách chạy các bài kiểm tra mô phỏng, bạn sẽ tìm thấy rất nhiều trường hợp góc lạ. Sửa chúng sẽ mất rất nhiều thời gian. Ngoài ra, bạn sẽ mất rất nhiều tối ưu hóa, phần mềm của bạn sẽ chạy chậm hơn nhiều. Bạn phải quyết định, nếu nó có giá trị và nếu điều này nằm trong phạm vi phần mềm của bạn.

Thay vì xóa tất cả các xác nhận, bạn vẫn nên kiểm tra những thứ như một người là cha mẹ của chính mình hoặc các tình huống không thể khác và đưa ra lỗi. Có thể đưa ra cảnh báo nếu không chắc chắn để người dùng vẫn có thể phát hiện các lỗi đầu vào phổ biến, nhưng nó sẽ hoạt động nếu mọi thứ đều chính xác.

Tôi sẽ lưu trữ dữ liệu trong một vectơ với một số nguyên vĩnh viễn cho mỗi người và lưu trữ cha mẹ và con cái trong các đối tượng cá nhân trong đó int nói là chỉ số của vectơ. Điều này sẽ khá nhanh để đi giữa các thế hệ (nhưng chậm đối với những thứ như tìm kiếm tên). Các đối tượng sẽ theo thứ tự khi chúng được tạo ra.

Sao y cha (hoặc sử dụng symlink / Reference).

Ví dụ: nếu bạn đang sử dụng cơ sở dữ liệu phân cấp:

$ #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