← Back to branch summary

~openerp-community/openobject-doc/ksa-openobject-doc-6.0

« back to all changes in this revision

Viewing changes to i18n/ru/source/bi/config_interface/config_interface.rst

  • Committer: Don Kirkby
  • Date: 2011-02-21 20:46:11 UTC
  • mfrom: (433.1.53 openobject-doc)
  • Revision ID: donkirkby+launpd@gmail.com-20110221204611-1ykt6dmg4k3gh5dh
[MERGE] revisions 477 to 486 from the 5.0 branch.

Show diffs side-by-side

added added

removed removed

Lines of Context:
i18n/ru/source/bi/config_interface/config_interface.rst
 
1
 
 
2
.. i18n: Configuration Interface
 
3
.. i18n: =======================
 
4
..
 
5
 
 
6
Configuration Interface
 
7
=======================
 
8
 
 
9
.. i18n: The main goal of any user connecting to OpenObject BI is to fetch the data from database using the powerful MDX queries.
 
10
..
 
11
 
 
12
The main goal of any user connecting to OpenObject BI is to fetch the data from database using the powerful MDX queries.
 
13
 
 
14
.. i18n: To run any MDX Query there is a need to make a cube and the user can define / configure its own custom cube using two interface : 
 
15
..
 
16
 
 
17
To run any MDX Query there is a need to make a cube and the user can define / configure its own custom cube using two interface : 
 
18
 
 
19
.. i18n: .. _schema_configuration-link:
 
20
.. i18n: 
 
21
.. i18n: Introduction
 
22
.. i18n: ----------------------------------
 
23
..
 
24
 
 
25
.. _schema_configuration-link:
 
26
 
 
27
Introduction
 
28
----------------------------------
 
29
 
 
30
.. i18n: Designer by default displays all schema in the tree form and provide options for adding the new.:
 
31
..
 
32
 
 
33
Designer by default displays all schema in the tree form and provide options for adding the new.:
 
34
 
 
35
.. i18n: .. image::  images/1.png
 
36
.. i18n:    :scale: 65
 
37
..
 
38
 
 
39
.. image::  images/1.png
 
40
   :scale: 65
 
41
 
 
42
.. i18n: --------
 
43
..
 
44
 
 
45
--------
 
46
 
 
47
.. i18n: Creating the Schema : Schema defines the database from where the data is to be fetched. It gives a meaning ful name to the database connection.:
 
48
..
 
49
 
 
50
Creating the Schema : Schema defines the database from where the data is to be fetched. It gives a meaning ful name to the database connection.:
 
51
 
 
52
.. i18n: .. image::  images/2.png
 
53
.. i18n:    :scale: 65
 
54
.. i18n:     
 
55
.. i18n: --------
 
56
.. i18n: 
 
57
.. i18n:     
 
58
.. i18n: Database Connection specified the paramaters for connecting to the database. It generally includes type of the database (postgres,oracle,mysql), username, password , database to use.:
 
59
..
 
60
 
 
61
.. image::  images/2.png
 
62
   :scale: 65
 
63
    
 
64
--------
 
65
 
 
66
    
 
67
Database Connection specified the paramaters for connecting to the database. It generally includes type of the database (postgres,oracle,mysql), username, password , database to use.:
 
68
 
 
69
.. i18n: .. image::  images/3.png
 
70
.. i18n:    :scale: 65
 
71
.. i18n:         
 
72
.. i18n: --------
 
73
..
 
74
 
 
75
.. image::  images/3.png
 
76
   :scale: 65
 
77
        
 
78
--------
 
79
 
 
80
.. i18n: Once we configure the database connection the next step is to load the database using introspection. This will load the structure of the database. by structure we mean tables, columns and the relations. This will help in defining cube easily. As the structure is loaded their will be no query to the database again and again:
 
81
..
 
82
 
 
83
Once we configure the database connection the next step is to load the database using introspection. This will load the structure of the database. by structure we mean tables, columns and the relations. This will help in defining cube easily. As the structure is loaded their will be no query to the database again and again:
 
84
 
 
85
.. i18n: .. image::  images/4.png
 
86
.. i18n:    :scale: 65
 
87
.. i18n:         
 
88
.. i18n: --------
 
89
..
 
90
 
 
91
.. image::  images/4.png
 
92
   :scale: 65
 
93
        
 
94
--------
 
95
 
 
96
.. i18n: The next step is to configure the database loaded. This is useful to hide unnecessary table and columns. If database is of openerp it can be auto configured:
 
97
..
 
98
 
 
99
The next step is to configure the database loaded. This is useful to hide unnecessary table and columns. If database is of openerp it can be auto configured:
 
100
 
 
101
.. i18n: .. image::  images/4a.png
 
102
.. i18n:    :scale: 65
 
103
.. i18n:        
 
104
.. i18n: --------
 
105
.. i18n: 
 
106
.. i18n:  
 
107
.. i18n: Once the cube schema is created we can go for creating the cube:
 
108
..
 
109
 
 
110
.. image::  images/4a.png
 
111
   :scale: 65
 
112
       
 
113
--------
 
114
 
 
115
 
 
116
Once the cube schema is created we can go for creating the cube:
 
117
 
 
118
.. i18n: .. image::  images/5.png
 
119
.. i18n:    :scale: 65
 
120
.. i18n:       
 
121
.. i18n: --------
 
122
.. i18n: 
 
123
.. i18n:   
 
124
.. i18n: Cube is the structure that is based on the schema (database), It will configure the way to retrieve the data:
 
125
..
 
126
 
 
127
.. image::  images/5.png
 
128
   :scale: 65
 
129
      
 
130
--------
 
131
 
 
132
  
 
133
Cube is the structure that is based on the schema (database), It will configure the way to retrieve the data:
 
134
 
 
135
.. i18n: .. image::  images/6.png
 
136
.. i18n:    :scale: 65
 
137
.. i18n:         
 
138
.. i18n: --------
 
139
..
 
140
 
 
141
.. image::  images/6.png
 
142
   :scale: 65
 
143
        
 
144
--------
 
145
 
 
146
.. i18n: Cube requires the fact table to be define. Fact table are the key tables in which measures are stored and we can branch to other tables for other parameters. For example for sales we can define sale_order as our fact table as it will gives the details of the sales. Fact table can be join of tables.
 
147
.. i18n: The fact table is given meaningful name:
 
148
..
 
149
 
 
150
Cube requires the fact table to be define. Fact table are the key tables in which measures are stored and we can branch to other tables for other parameters. For example for sales we can define sale_order as our fact table as it will gives the details of the sales. Fact table can be join of tables.
 
151
The fact table is given meaningful name:
 
152
 
 
153
.. i18n: .. image::  images/7.png
 
154
.. i18n:    :scale: 65
 
155
.. i18n:        
 
156
.. i18n: --------
 
157
.. i18n: 
 
158
.. i18n:  
 
159
.. i18n: And the cube screen will be
 
160
..
 
161
 
 
162
.. image::  images/7.png
 
163
   :scale: 65
 
164
       
 
165
--------
 
166
 
 
167
 
 
168
And the cube screen will be
 
169
 
 
170
.. i18n: .. image::  images/8.png
 
171
.. i18n:    :scale: 65
 
172
.. i18n:         
 
173
.. i18n: --------
 
174
..
 
175
 
 
176
.. image::  images/8.png
 
177
   :scale: 65
 
178
        
 
179
--------
 
180
 
 
181
.. i18n: After cube we can decide upon the dimensions to be used for the cube. For example we want to look on products sold , Dates, City etc.. to analyis the sales accordingly.
 
182
.. i18n: We decide what are the measures to be used. For example items sold. So we can decide the dimension and measures:
 
183
..
 
184
 
 
185
After cube we can decide upon the dimensions to be used for the cube. For example we want to look on products sold , Dates, City etc.. to analyis the sales accordingly.
 
186
We decide what are the measures to be used. For example items sold. So we can decide the dimension and measures:
 
187
 
 
188
.. i18n: .. image::  images/9.png
 
189
.. i18n:    :scale: 65
 
190
.. i18n:         
 
191
.. i18n: --------
 
192
..
 
193
 
 
194
.. image::  images/9.png
 
195
   :scale: 65
 
196
        
 
197
--------
 
198
 
 
199
.. i18n: Adding the dimension Products. So we will be able to see product wise item sold:
 
200
..
 
201
 
 
202
Adding the dimension Products. So we will be able to see product wise item sold:
 
203
 
 
204
.. i18n: .. image::  images/10.png
 
205
.. i18n:    :scale: 65
 
206
..
 
207
 
 
208
.. image::  images/10.png
 
209
   :scale: 65
 
210
 
 
211
.. i18n: After dimension we explain how to get the prodcuts details in the hierarchy. It requires to configure the fact table:
 
212
..
 
213
 
 
214
After dimension we explain how to get the prodcuts details in the hierarchy. It requires to configure the fact table:
 
215
 
 
216
.. i18n: .. image::  images/12.png
 
217
.. i18n:    :scale: 65
 
218
.. i18n:         
 
219
.. i18n: --------
 
220
..
 
221
 
 
222
.. image::  images/12.png
 
223
   :scale: 65
 
224
        
 
225
--------
 
226
 
 
227
.. i18n: After adding the hierarchy  we decide from which field the product name will come:
 
228
..
 
229
 
 
230
After adding the hierarchy  we decide from which field the product name will come:
 
231
 
 
232
.. i18n: .. image::  images/14.png
 
233
.. i18n:    :scale: 65
 
234
.. i18n:         
 
235
.. i18n: --------
 
236
..
 
237
 
 
238
.. image::  images/14.png
 
239
   :scale: 65
 
240
        
 
241
--------
 
242
 
 
243
.. i18n: The fully configured cube tree will look like:
 
244
..
 
245
 
 
246
The fully configured cube tree will look like:
 
247
 
 
248
.. i18n: .. image::  images/15.png
 
249
.. i18n:    :scale: 65
 
250
..
 
251
 
 
252
.. image::  images/15.png
 
253
   :scale: 65
 
254
 
 
255
.. i18n: Connecting to an Existing Database
 
256
.. i18n: ----------------------------------
 
257
..
 
258
 
 
259
Connecting to an Existing Database
 
260
----------------------------------
 
261
 
 
262
.. i18n: One can very easily connect to the existing database. The details requiered are 
 
263
..
 
264
 
 
265
One can very easily connect to the existing database. The details requiered are 
 
266
 
 
267
.. i18n: #. Fact Name : Logical Name of the database
 
268
.. i18n: 
 
269
.. i18n: #. Database Name: Pyhsical Database name to be used
 
270
.. i18n: 
 
271
.. i18n: #. Database type : Type of the database it can be PostgreSQL, MySQL, Oracle etc.
 
272
.. i18n: 
 
273
.. i18n: #. Connection type : Port or Socket
 
274
.. i18n: 
 
275
.. i18n: #. Database Host : Server name like localhost
 
276
.. i18n: 
 
277
.. i18n: #. Database Port : Port to be used for making connection to the database
 
278
.. i18n: 
 
279
.. i18n: #. Database Login: Login name for accessing a database
 
280
.. i18n: 
 
281
.. i18n: #. Database Password:Password for the user in login
 
282
..
 
283
 
 
284
#. Fact Name : Logical Name of the database
 
285
 
 
286
#. Database Name: Pyhsical Database name to be used
 
287
 
 
288
#. Database type : Type of the database it can be PostgreSQL, MySQL, Oracle etc.
 
289
 
 
290
#. Connection type : Port or Socket
 
291
 
 
292
#. Database Host : Server name like localhost
 
293
 
 
294
#. Database Port : Port to be used for making connection to the database
 
295
 
 
296
#. Database Login: Login name for accessing a database
 
297
 
 
298
#. Database Password:Password for the user in login
 
299
 
 
300
.. i18n: ------
 
301
..
 
302
 
 
303
------
 
304
 
 
305
.. i18n: Giving this detail will generate a string like ''postgres://postgres:postgres@localhost:5432/terp''
 
306
..
 
307
 
 
308
Giving this detail will generate a string like ''postgres://postgres:postgres@localhost:5432/terp''
 
309
 
 
310
.. i18n: ------
 
311
..
 
312
 
 
313
------
 
314
 
 
315
.. i18n: Strings so generated is a connection string for making connection to the database.
 
316
..
 
317
 
 
318
Strings so generated is a connection string for making connection to the database.
 
319
 
 
320
.. i18n: Writing a Schema
 
321
.. i18n: ----------------
 
322
..
 
323
 
 
324
Writing a Schema
 
325
----------------
 
326
 
 
327
.. i18n: .. describe::  What is Schema ?
 
328
..
 
329
 
 
330
.. describe::  What is Schema ?
 
331
 
 
332
.. i18n: Schema in general means shape or more generally plan . In the context of OpenObject BI it defines the logical model, consisting of cubes, hierarchies, and members, and a mapping of this model onto a physical model.
 
333
..
 
334
 
 
335
Schema in general means shape or more generally plan . In the context of OpenObject BI it defines the logical model, consisting of cubes, hierarchies, and members, and a mapping of this model onto a physical model.
 
336
 
 
337
.. i18n: The logical model consists of the constructs used to write queries in MDX language: cubes, dimensions, hierarchies, levels, and members.
 
338
..
 
339
 
 
340
The logical model consists of the constructs used to write queries in MDX language: cubes, dimensions, hierarchies, levels, and members.
 
341
 
 
342
.. i18n: The physical model is the source of the data which is presented through the logical model. It is typically a star schema, which is a set of tables in a relational database; later, we shall see examples of other kinds of mappings.
 
343
..
 
344
 
 
345
The physical model is the source of the data which is presented through the logical model. It is typically a star schema, which is a set of tables in a relational database; later, we shall see examples of other kinds of mappings.
 
346
 
 
347
.. i18n: Making Schema
 
348
.. i18n: +++++++++++++
 
349
..
 
350
 
 
351
Making Schema
 
352
+++++++++++++
 
353
 
 
354
.. i18n: In OpenObject BI schemas are represented in a XML file. It can be designed in the way OpenERP does. The details of XML file can be seen at *Creating XML*
 
355
..
 
356
 
 
357
In OpenObject BI schemas are represented in a XML file. It can be designed in the way OpenERP does. The details of XML file can be seen at *Creating XML*
 
358
 
 
359
.. i18n:         
 
360
..
 
361
 
 
362