source: main/eko-disco-specs/trunk/data.rst @ 10779

Last change on this file since 10779 was 10777, checked in by Henrik Bettermann, 11 years ago

Shorten description.

File size: 11.4 KB
Line 
1
2.. |n0| replace:: n\ :sub:`0`
3.. |m0| replace:: m\ :sub:`0`
4
5.. _label-data-entities:
6
7Data Entities
8=============
9
10These are the data entities the new system is supposed to model. Each
11of these entities should be addable, editable, and removable as
12covered in more detail in :ref:`label-use-cases`.
13
14For each entity we give a short description to tell what it means,
15what its purpose is and in what regards (and how) it should be handled
16by the system. Again the more detailed actions on these entities
17provided by the system are described in the :ref:`label-use-cases`
18section.
19
20The data entities are sorted alphabetically, not by importance or
21similar. Used description terms should link to other respective
22entities/terms where possible.
23
24Each data entitiy description provides a list of use cases and other
25data entities connected. Connections to other data entities contain a
26relationship telling how many instances of the described entity are
27connected to how many instances of the related entity.
28
29The following relation types may occur (in both directions):
30
31  - 1:1 (one on one)
32  - n:1 (many on one)
33  - n:m (many on many)
34  - p:1 (many or none on one)
35  - p:q (many or none on many or none)
36  - p:n (many or none on many)
37  - b:1 (one or none on one)
38
39with
40
41  - n, m element of {1, 2, ...},
42  - p, q element of {0, 1, 2, ...}
43  - b element of {0, 1}
44
45Examples:
46
471:p service-contract relation means that each service
48offered can result in various contracts, but each contract is
49only based on one service.
50
51p:q useraccount-userrole relation means that each user account can have no role
52or several roles and each role can be assigned to no user account
53or several user accounts.
54
55Relations can always be read in two directions.
56
57.. _label-contact-address:
58
59Contact Address
60---------------
61
62A postal address.
63
64Connected to: :ref:`label-contact-data` (p:1)
65
66Used in the following use cases:
67
68
69.. _label-contact-data:
70
71Contact Data
72------------
73
74The data neccessary to contact some :ref:`label-customer`,
75:ref:`label-officer` or similar entity. Contact data might contain several
76addresses, phone numbers, emails, etc.
77
78Connected to: :ref:`label-customer` (1:1),
79:ref:`label-contact-address` (1:p), :ref:`label-contact-email`
80(1:n), :ref:`label-contact-phone` (1:p)
81
82Used in the following use cases:
83
84
85.. _label-contact-email:
86
87Contact Email
88-------------
89
90An email address with optional additional clear name. For email
91addresses we store some timestamp that indicates when the respective
92email address was last checked successfully (thus marking it a 'valid'
93one). No timestamp means, the email address has never been checked.
94
95Connected to: :ref:`label-contact-data` (n:1),
96:ref:`label-timestamp` (1:q),
97:ref:`label-user-account` (1:b)
98
99Used in the following use cases:
100
101
102.. _label-contact-phone:
103
104Contact Phone
105-------------
106
107Mobile phone number which is capable of receiving sms text messages.
108
109Connected to: :ref:`label-contact-data` (p:1)
110
111Used in the following use cases:
112
113
114.. _label-contract:
115
116Contract
117--------
118
119A contract is created whenever a :ref:`label-customer` orders some
120:ref:`label-service` from the system. It is always connected to a
121:ref:`label-customer` and a :ref:`label-service` .
122
123A contract is not necessarily written on paper and signed by
124people. Instead it is an abstraction used inside the system.
125
126It is always created from a :ref:`label-service`, which tells about
127the basic data, with additional parameters set that depend on the type
128of :ref:`label-service` ordered.
129
130Contracts can trigger :ref:`label-transaction`\ s. For instance if some
131:ref:`label-customer` orders a service. When the service charges
132become due, a respective :ref:`label-transaction` is triggered.
133
134Contracts can have multiple :ref:`label-supp-contract`\ s.
135
136Connected to: :ref:`label-service` (p:1), :ref:`label-customer` (p:1),
137:ref:`label-supp-contract` (1:p), :ref:`label-transaction` (1:p),
138:ref:`label-meter` (1:b)
139
140Used in the following use cases:
141
142
143.. _label-customer:
144
145Customer
146--------
147
148A user data entity and beneficiary of :ref:`label-contract`\ s.
149
150Customers are added to the system by initial import (migration phase),
151being created by staff or can register themselves (self-registration)
152to the system.
153
154Each customer has a :ref:`label-user-account`.
155
156Customers have to provide :ref:`label-contact-data` and get
157:ref:`label-login-credentials` to login to the system.
158
159Once logged in, customers get a 'My Eko-Disco' page where they can
160
161- see their current orders
162
163- watch their consumption
164
165- order more services
166
167- handle contractual problems
168
169- get help if problems arise
170
171- retrieve bills
172
173- change their passwords
174
175Customers can order :ref:`label-service`\ s and pay these (kinds of
176payment depend on the type of service/good ordered and the available
177payment methods).
178
179Customers and their data can be managed by customers themselves (for
180instance when postal addresses change), and by officers.
181
182Connected to: :ref:`label-contract` (1:p),
183:ref:`label-contact-data` (1:1), :ref:`label-login-credentials` (1:1),
184:ref:`label-user-account` (b:1)
185
186
187.. _label-location:
188
189Location
190--------
191
192A real-world location. Used for instance for meters to store
193information about their place. The location of a meter does not necessarily
194correspond with one of the :ref:`label-contact-address`\ es.
195Locations can either be less formal, for instance describing a location
196in words, or very precise by using GPS data.
197
198Connected to: :ref:`label-meter` (1:p)
199
200
201.. _label-login-credentials:
202
203Login Credentials
204-----------------
205
206A set of username and password assigned to user accounts. Passwords are
207stored inside the system using strong cryptographic hash functions.
208
209Passwords can be reset on request.
210
211Connected to: :ref:`label-customer` (1:1), :ref:`label-user-account` (1:1)
212
213
214.. _label-meter:
215
216Meter
217-----
218
219A meter measures power consumption. It has a place where it is
220installed and might be connected to one or several contracts. For a
221given time a meter can be connected to one or zero contracts.
222
223Each meter has to provide a :ref:`label-location` that tells, where it
224is installed.
225
226Meters also contain a history of meter values
227(:ref:`label-meter-value`), which is basically a list of meter values
228at a given time.
229
230Connected to: :ref:`label-contract` (b:1),
231:ref:`label-meter-value` (1:n), :ref:`label-location` (p:1)
232
233
234.. _label-meter-value:
235
236Meter Value
237-----------
238
239The value of a :ref:`label-meter` at a certain point in time
240(providing a :ref:`label-timestamp`) authorized by some user or device.
241
242It serves mainly for computing power consumption of
243:ref:`label-customer`\ s.
244
245When a new meter value is added to the system (the respective
246:ref:`label-meter` is 'updated'), the system also registers how the
247the new value was entered, i.e. by whom and when.
248
249The system will be prepared to collect meter values in two ways:
250
251a) (push-method): by being fed with respective data by authorized
252   users (officers)
253
254b) (pull-method): by polling dedicated hardware that provides the
255   neccessary interface (automatic remote-reading).
256
257The second choice requires appropriate hardware to be in place, which
258in detail is not part of this specs. The system will, however, be
259prepared to collect meter data from external devices.
260
261Connected to: :ref:`label-meter` (n:1), :ref:`label-timestamp` (1:1),
262:ref:`label-user-account` (p:1)
263
264
265.. _label-officer:
266
267Officer
268-------
269
270A user data entity of a staff member with certain permissions to manage
271portal data.
272
273Each officer has a :ref:`label-user-account`.
274
275Actors are called :ref:`Manager <label-actors>`\ s if they are officers with
276local managing permission.
277
278Connected to: :ref:`label-login-credentials` (1:1),
279:ref:`label-user-account` (b:1),
280:ref:`label-user-role` (1:p)
281
282
283
284.. _label-report:
285
286Report
287------
288
289Administrative report or list to give overviews over current state of
290business. Includes lists of customers sorted by various categories
291(type of contract, amount of fees paid, etc.), lists of services
292sorted by various categories, etc.
293
294Reports are generated as PDF documents and are available for download
295by authorized users.
296
297Connected to: (almost everything else)
298
299
300.. _label-service:
301
302Service
303-------
304
305The system will provide different services to
306:ref:`label-customer`\ s. These can have arbitrary forms, including
307one-time services (like installation of meters) and open-ended
308long-time services (like delivering power based on contract). Services
309are managable by staff like goods offered in a shop.
310
311Services define the conditions under which they can be ordered by
312:ref:`label-customer`\ s, including prices, runtimes, etc.
313
314Services also serve as factories for :ref:`label-contract`\ s.
315
316Connected to: :ref:`label-contract` (1:p)
317
318Used in the following use cases:
319
320
321.. _label-supp-contract:
322
323Supplementary Contract
324----------------------
325
326A supplementary contract always belongs to some already existing
327:ref:`label-contract` but comes with an own set of
328parameters. A typical supplementary contract materialises if a customer
329orders an amount of electrical energy on the bases of a 'main' contract
330achieved between the customer and the distribution company.
331The parent contract for instance may guarantee a special price
332per kilowatt hour of electrical energy.
333
334Supplementary contracts are created by :ref:`label-contract`\ s.
335
336Connected to: :ref:`label-contract` (p:1),
337:ref:`label-service` (p:1), :ref:`label-customer` (p:1),
338:ref:`label-transaction` (1:p)
339
340
341.. _label-timestamp:
342
343Timestamp
344---------
345
346A timestamp can be a calendar date or a calendar date plus some day
347time.
348
349The system will internally use UTC-based timestamps only to minimize
350ambiguities. In menus, frontends, etc. timestamps are displayed in
351local Lagos time.
352
353Connected to: :ref:`label-meter-value` (1:1),
354:ref:`label-contact-email` (p:1)
355
356
357.. _label-transaction:
358
359Transaction
360-----------
361
362A transaction is some business-relevant action taken. A transaction
363means basically, that something happened, that leads to increased or
364decreased customer accounts. Normally this is something like a
365payment, some service order or similar.
366
367Transactions do always belong to one certain customer account. They
368also contain some amount of money which is thereby transfered to or
369from a customer's account. They also always reference a service which
370is consumed, purchased, or (pre-)paid by the respective customer.
371
372Connected to: :ref:`label-customer` (p:1), :ref:`label-service`
373(p:1), :ref:`label-contract` (p:1)
374
375Used in the following use cases:
376
377
378.. _label-user-account:
379
380User Account
381------------
382
383A user account is a set of user data and :ref:`label-login-credentials`
384which allows a user (agent) to authenticate against the system and
385let the system store some information required for user handling,
386such as real name, email address and/or mobile phone number. An email
387address and/or phone number ensures that the user can be contacted
388electronically by the system.
389
390:ref:`label-user-role`\s are assigned to user accounts and managed by the
391system to grant authorization for the various views of the portal.
392Real-world officers (staff members) and customers are different to the
393system as they will get different roles. Also anonymous users
394(users without user account) are accepted by the system to provide
395marketing pages, service offers, etc.
396
397Users can be blocked or removed from the system.
398
399Connected to: :ref:`label-login-credentials` (1:1),
400:ref:`label-customer` (1:b),
401:ref:`label-user-role` (p:q),
402:ref:`label-contact-email` (b:1)
403
404
405.. _label-user-role:
406
407User Role
408---------
409
410A set of permissions assigned to a group of :ref:`label-user-account`\ s.
411
412Connected to: :ref:`label-user-account` (p:q)
413
Note: See TracBrowser for help on using the repository browser.