Barker and IE notation: read a relationship as two sentences

Start with a customer who has never ordered

Use two explicit rules: a customer may place zero or many orders; an order must belong to exactly one customer. In IE, the orders end shows zero-to-many and the customer end shows exactly one. In Barker, read the relationship half nearest the starting entity for optionality, then the opposite end for maximum cardinality. Relationship names help turn each direction into a sentence.

Do not reuse the meaning of a dashed line from a different notation. Barker's solid and dashed halves express required and optional participation. Identifier participation is a separate issue; a UID bar identifies a relationship that contributes to the child identifier.

Translate the sentence into database constraints

CREATE TABLE customers (customer_id BIGINT PRIMARY KEY);
CREATE TABLE orders (
  order_id BIGINT PRIMARY KEY,
  customer_id BIGINT NOT NULL,
  FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);

Create a customer with no orders: that must succeed. Create an order with an unknown customer: that must fail. Create an order with a NULL customer id: that must also fail. The order id remains the complete order identifier, so this required relationship is non-identifying.

A line cannot enforce every business rule

Changing the requirement to “every customer must have an order” adds a minimum-child-count rule. A foreign key from orders to customers cannot enforce it: the customer can still exist without any child. Enforce the operation as a transaction or through an explicit workflow and decide how imported or abandoned accounts are handled.

Likewise, a one-to-one drawing needs a uniqueness rule on the referencing key in the physical schema. Inspect the actual DDL rather than assuming the symbol creates every constraint. YourERD provides relationship previews; use the child's PK/FK/NN flags and any written uniqueness rules to review the physical meaning.