forked from cheng/wallet
84 lines
3.3 KiB
HTML
84 lines
3.3 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
<style>
|
||
body {
|
||
max-width: 30em;
|
||
margin-left: 2em;
|
||
}
|
||
p.center {text-align:center;}
|
||
</style>
|
||
<link rel="shortcut icon" href="../rho.ico">
|
||
<title>User model of secrets and coins</title>
|
||
</head>
|
||
<body><a href="./index.html"> To Home page</a>
|
||
<h1>User model of secrets and coins</h1><p>
|
||
|
||
The entity relationship model is a view of your data, not in normal form, but
|
||
as it is meaningful and useful to the user. </p><p>
|
||
|
||
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</p><p>
|
||
|
||
|
||
|
||
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.</p><p>
|
||
|
||
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.</p><p>
|
||
|
||
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 <i>and</i> the UI <i>and</i> the insertion and deletion rules.</p><p>
|
||
|
||
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.</p><p>
|
||
|
||
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</p><p>
|
||
|
||
So your data model not only tells you how to construct your schema, but also your UI and data objects</p>
|
||
|
||
<HR>
|
||
|
||
<h2>Entities:</h2>
|
||
<dl>
|
||
<dt>Coin</dt>
|
||
<dd>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</dd>
|
||
<dt>Payment</dt>
|
||
<dd>a group of coins, and what happened to them. Payments are linked to contracts, bills, invoices, and the like</dd>
|
||
<dt>Invoice</dt>
|
||
<dd>Demand for payment, claim that goods have in fact been delivered – not quite the concept we want.
|
||
Dictionary says “see bill”</dd>
|
||
<dt>Order</dt>
|
||
<dt>Offer</dt>
|
||
<dt>Bid</dt>
|
||
</dl>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<p style="background-color: #ccffcc; font-size: 80%;">These documents are
|
||
licensed under the <a href="http://creativecommons.org/licenses/by-sa/3.0/" rel="license">Creative
|
||
Commons Attribution-Share Alike 3.0 License</a></p>
|
||
</body>
|
||
</html>
|