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

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

Staff members are called officers in portal.

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