User model of secrets and coins

The entity relationship model is a view of your data, not in normal form, but as it is meaningful and useful to the user.

This model is to be communicated to the user, either in documentation, or, better, in the layout of screens, so that by simply bringing up screens, the user recognizes the model

After you construct your entity relationship model you work backwards to a normal form schema that supports some select statements and insertion deletion rules that support the entity relationship model.

An entity is a real thing in the world that the customer cares about, and also a select statement. A relationship is a connection between one real world thing and another, and also a bunch of rules governing insertion and deletions, and primary and foreign keys, such that the database things behave in a way that models the things in the world.

Though the schema shall be in normal form, the user interface shall model the things the user knows, the entities and their relationships, so the ER model tells one how to construct the schema and the UI and the insertion and deletion rules.

The ER model is thus high level documentation of the schema and user interface. The schema shall be in normal form, the ER model in reality form.

The ER model also defines your data objects, which encapsulate the database. For example if a relationship between to object sets is hierarchical, your data objects give you access as if you were using a hierarchical, rather than relational, database. Thus if entity A belongs to entity B, hierarchical deletion and insertion is implicit, and not only does the program follow that rule, and the database enforce that rule, but the program accesses the database through a data object that provides no means of breaking that rule, no means of performing an action that would cause your database to generate an error message. Your database is in normal form, but your data objects are in closer-to-reality form

So your data model not only tells you how to construct your schema, but also your UI and data objects

Entities:

Coin

user only sees value, and information as to whether spent or unspent. Spent or unspent is actually a property of the coin’s involvement in payments and backups

Payment

a group of coins, and what happened to them. Payments are linked to contracts, bills, invoices, and the like

Invoice

Demand for payment, claim that goods have in fact been delivered – not quite the concept we want. Dictionary says “see bill”

Order

Offer

Bid

These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License