Here is fully normalized relational model. I will adopt a simple notation Table: <PrimaryKeyID>, Column1, Column2 where the <> denotes the column to be prima

Here is fully normalized relational model. I will adopt a simple notation Table: <PrimaryKeyID>, Column1, Column2 where the <> denotes the column to be primary key and Column1, Column2 etc. denote regular non-key attributes. The notation ForeignKeyID from SomeTable denotes a foreign key referring to a row in SomeTable. Persons: <PersonID>, Name, DateOfBirth Men and Women are defined in separate tables, to enforce integrity constraints later, which is why it is not modeled as a Gender attribute in Persons table. These tables have no attributes, simply a listing of men and women. It is a perfectly valid relation that has only one column, by the way. Note that the foreign key here is also the primary key of the table. Men:<PersonID from Persons> Women: <PersonID from Persons> This represents a basic marriage, the only attribute of which is the date. Many specific forms of marriage are captured below. Marraiges: <MarriageID>, DateOfMarriage MarriageID is the primary key for the tables below. The design below permits polygamy, so further integrity constraints would be needed to restrict it. If a marriage is not permitted to be dissolved and no polygamy is permitted, we can place a uniqueness constraint on both Men and Women attributes below. If all types of marriages are permitted in all jurisdictions, these 3 tables below could be unified. ConventionalMarriages: <MarriageID from Marriages>, PersonID from Men, PersonID from Women GayMarriages: <MarriageID from Marriages>, PersonID from Men, PersonID from Men LesbianMarriages: similar to above Notice how a marriage has to exist for a divorce to exist Divorces: <MarriageID from Marriages>, DivorceDate Some features of the model: if a person A & B marry and then they terminate a marriage, and remarry again, it gets a new marriageID. Some integrity constraints: a) Zero or One marriage at a time rule: If a PersonID occurs more than once in the Marriages table, then order the marriages by marriage date, order Divorces by DivorceDate, and enforce the rule: for all except last MarriageID in Ordered(Marriages), ensure Divorces(MarriageID) exists, and DivorceDate(MarriageID) < MarriageDate(next(MarriageID)) b) Polygamy would require more complex integrity constraints. The nice thing about thinking about the problem relationally is that you focus on the data and its interrelationships, and avoid language considerations. Notice how a fully normalized relational model captures a lot of the constraints automatically, and only the most complex of constraints need to be separately stated. Finally, note that this is an abstract model and should be separated from details of storage.