It's a little murky because the article keeps talking about supertypes and subtypes and never really states which of the possible ways to implement inheritance in databases is meant.
But in general terms, the article states:
An accounting transaction must be composed of one or more debit entries and it must be composed of one or more credit entries.
To me this looks and sounds like two foreign keys that reference the same table:
create table accounting_transaction (
id integer primary key,
date date not null,
description text
);
create table accounting_entry (
id integer primary key,
amount float not null,
operator text,
credit_id integer references accounting_transaction(id),
debit_id integer references accounting_transaction(id)
);
with appropriate constraints ensuring the condition stated in the text. But of course there are better ways of designing this. For example:
create table accounting_entry (
id integer primary key,
amount float not null,
operator text,
entry_type integer,
transaction_id integer references accounting_transaction(id)
);
with entry_type signifying credit or debit, and again appropriate constraints.
Edit: Normally, you'd expect an ERD of this kind to signify a different kind of relationship: that from a collection to a fixed number of components that are of the same type but have different meanings in the context of the collection. The classic example is a flight leg that has exactly one departure airport and (hopefully) exactly one destination airport, where of course an airport is an airport.
create table flight_leg(
id integer primary key,
departure_airport integer references airport(id),
destination_airport integer references airport(id)
);
create table airport(
id integer primary key,
iata_code varchar(3) not null,
name text
);
Note the difference in who references whom. For the model in the article this would mean that an accounting_transaction references exactly one debit_entry and exactly one credit_entry, which doesn't seem to be what the author intended.
