We are trying to set our BI team's reporting standards for Business Objects Universe Designer and Web Intelligence tools. We set some standars like below.
What are your ideas about these standards? Could you please share your standards documents?
Name the universe based on the application.
Give proper name universe objects (classes, dimensions, measures etc) according to
business terminology and being explicit in the definition. For
instance, an object called 'Sales' could be interpreted many
different ways. Is it Sales Revenue, Count of Sales Orders, Count of
Sales Order Lines, Average Sales Amount.
Company logo is put on the upperleft side of the report.
User prompts and last refresh time is put on the upper-right side of the report.
The title and report name describes the scope of the data (for example, university wide, unit specific, school/college level) and any conditions in the report (for example, term, fiscal year, department ID).
The columns of data are arranged in logical order.
When prompts are used, they model how the data should be entered. For example, “Enter the term (e.g. 1760)”
I think that this is a bit off topic for stackoverflow, and some of it is not clear or is commonsense anyway (eg. "columns of data arranged in logical order"), but I would suggest:
that every universe be associated with a three character code (eg. SAL, REV etc).
that every report be uniquely identifiable by a number, prefixed by the Universe code.
that non-trivial objects have as part of their definition a SQL-format comment giving their name and folder.
There two aspects :
Considering the technical aspect of the universe
Considering the end-user aspect of the universe
Technical aspects :
Layout of your tables should reflect your navigation
Version information/changes in either comment / hidden objects
try to use aliases as much as possible to show in what function your table is used.
try to refactor used constants in separate objects and use the #select to use them.
try to have a hierarchic naming convention so that the name will imply the navigation.
find a fitting naming convention for your connections.
User aspects :
DON'T DO THIS folder = table name , object = column name, it comes from dragging and dropping your tables.
object name is not literature, you are limited. It should be clear what the object is. Add comments always comments.
Limit number of folders, limit folder depth, limit number of objects in a folder.
Order the objects based on their use inside folder(most used on top).
Related
I am learning abap, I am unable to build the logic without knowing the table linking in abap, but I know the related fields.
(LIPS-VGBEL = VBAK-VBELN, LIPS-VGPOS = VBAP-POSNR) this all are different fields how this are equal please clarify my doubt.
They are equal, because they have the same domain.
Go to se11 -> lips -> vgbel -> column data elemnt vgbel
If you are doubleklicking, you see, that the domain is vbeln
This is the same domain like the domain of the vbak-vbeln.
It's the same with vbap-posnr and lips-vgpos.
It's still the same domain.
I hope it helped...
This knowledge is more process related than technical. LIPS table is used to maintain Delivery information (item level, LIKP is for header level), and VBAP table is used to maintain Sales Order information (item level, VBAK is for header level).
In the Sales and Distribution process of SAP, you can create a Delivery for a Sales Order. So on LIPS-VGBEL the system will store the preceding Sales Order number (VBAP-VBELN), and on LIPS-VGPOS the system will store the preceding Sales Order item (VBAP-POSNR).
Also, there is another option to retrieve the document flow. You can check table VBFA.
This logic applies to a lot of other tables and processes.
Our company manufactures shoes and I'm given a task to make a FE & BE for it. I decided to make the FE in MS Access for now (will switch to Django web app in 1-2 years most likely, once I get more familiar & comfortable with it) and BE is in MySQL for now.
Basically, our customer can order some product, say "shoeA" x 1080 in individual boxes (each pair has a box) and 24 of such boxes in a carton. Hence the structure for bill of materials (or assemblies... not sure of terminology here) would look like:
Order1
- Carton (size 24) x 45
- Box (1 pair) x 24 -- (45 * 24 = 1080)
- Packing paper x 1
- shoeA x 1
...
But if we look at what shoeA consists of, it's more co-products and raw materials. Moreover, each item can come from different place (ie. warehouse) and can be assembled by different assembly (e.g. shoeA would not be assembled by the same assembly as where the packing is done). The problem is, that multiple assemblies do the same type of work (e.g. multiple packaging assemblies) and so we don't know which assembly will do what at the time of the order (e.g. order can come 6 months in advance and we will know which assembly will do what 2 months in advance).
To complicate things further, 2 assemblies of same 'type' (e.g. packaging assemblies) can require different materials even though they produce the same outcome. For instance our assembly in Turkey just needs the shoeA from us, they will provide the rest of the materials / co-products themselves (ie. boxes / packing paper etc). Of course this will reflect in price, but that's not the problem for now. The point is that both of these assemblies will produce same product in the end (ie. box with a shoe and paper in it).
How would one reflect this in back-end RDBMS? Currently I have:
Please ignore the attributes themselves (other than PK/FK) as they are just place holders until I get things finalised.
I think the big problem you will run into is the possibility of subassemblies. I.e. you may have three parts that get made into one assembly, and that assembly plus two other parts gets made into the shoe.
The way I have usually seen this handled is something like this:
CREATE TABLE part (
id int autoincrement,
is_assembly tinyint,
...
);
CREATE TABLE component (
assembly_id int references part(id),
component_id int references part(id),
qty numeric, -- number used to make assembly
equivalent_to int references part(id)
);
Note that this sort of structure allows you to infinitely nest assemblies.
The equivalency problem can then be solved by adding the equivalent_to part which allows you to handle that.
note you need to track in and out of each part and subassembly separately because you no longer have a 1:1 mapping between parts in and assemblies out.
What you need is to have alternate BOM's (bill of materials) where you have defined options. It looks like your accounting for purchasing to send some items to vender some times and of course there would be a cost difference. The other options is to have a parts supplied list for a PO or Work Order (WO). So on the fly you can vary the parts supplied. If you are supporting an ERP you need to have a prefered method and a reason logic for the switch for example internal labor CAP. If it is a purchasing option from multiple vendors you can use a dependent part. In a ERP you need to know if there is a requirement for all the parts or only some. If your ERP project for both parts and purchasing opt's for the single part Vendor you will have projected a oversupply. Alternet BOMs also can have a vendor flag so vender A requires this for $$ and B requires no part for $$ then a cost based logic can work. Each option can supply the same assembly but cost and workcenter load very. In any case you need the logic to allow the PO or WO to very on the fly for what is really needed in case the vendor is out of a part and needs it supplied only this time or a WO is going to use a different option one time. In any case you need to track what was used and what was produced for how many $ or time so the real cost of the Asm is known.
Fields added : BOM need option number, ranking preference, build or purchase
Purchase option. (vendor quotes can have the BOM option # show cost given that BOM option)
Build Options: Need Asm steps / time /machine or work center for each, ( bill of Labor table for make options) because different WC's could have different labor machine cost.
Cost of purchase option.
When creating WO or PO need to as which BOM Option to default. Backflushing would not be a good option a manual pull/record should be done to keep inventory correct.
I've been trying to develop an internal staff portal for our company. There are departments, job grades, working areas, roles (user, editor, admin, super admin, etc...) and special groups (executives, etc) for user grouping.
User must have one (only one) department.
User must have one (only one) job grades.
User must work in minimum one area.
User must have one (only one) roles.
User may have one or more special groups.
Job grades and roles are hierarchical (an grade or role may be inherited of another one) but other ones not.
Users will see only allowed menus and access permitted routes.
User will also select which users can view it when posting a new content.
e.g:
Combination 1: (IT or Finance department) and (Job Grade is one of 9,10,11) and (Area is one of 1,5,8) and (Exclusive special group is one of 1,5,8) except user id=1
Combination 2: (HR department) and (Job Grade is 11) and user_id=3,4,5
Combinations can be related as AND/OR among themselves like Combination 1 AND combination 2
So, there will be lots of contents and every content will have different group permissions. I try to create a DB schema but it's very hard to get all contents that is visible to logged in user. Serialized data would be good for saving combination sets in db but it looks like impossible with serialized data. Is there an advantage to using MongoDB for this issue? How can i save combinations of group/user permissions in tables also?
I researched lots of ACL and RBAC examples but can't find the optimal solution. Please help.
Btw, i use Laravel Framework.
Thanks.
You need to look into attribute-based access control (ABAC - Wikipedia) and the eXtensible Access Control Markup Language (XACML). NIST, the National Institute of Science & Technology gives a great intro to ABAC here.
XACML will give you the ability to express fine-grained access control policies that use you attributes. In your question you have:
user attributes
department
job grade
working area
role
group
object (resource) attributes
content type
content location
content classification
With XACML you can write rules such as:
A user with grade==1 can do the action==edit on content of type==post
if content.department==user.department.
You can have as many rules as you like including conflicting rules or environment rules (deny access before 9am).
Have a look at the ALFA plugin for Eclipse to write your own policies (Wikipedia | Download).
HTH,
David
How could the following database schema be drawn using E/R diagrams? (A sketch or final image would be helpful). I would also appreciate if you could guide me to a easy-to-understand tutorial on entity-relationships so I could learn how to draw them on paper first.
A CD has a title, a year of production and a CD type. (CD type could be anything: mini-CD, CD-R, CD-RW, DVD-R, DVD-RW...)
A CD usually has multiple songs on different tracks. Each song has a name, an artist and a track number. Entity set Song is considered to be weak and needs support from entity set CD.
A CD is produced by a producer which has a name and an address.
A CD may be supplied by multiple suppliers, each has a name and an address.
A customer may rent multiple CDs. Customer information such as Social Security Number (SSN), name, telephone needs to be recorded. The date and period of renting (in days) should also be recorded.
A customer may be a regular member and a VIP member. A VIP member has additional information such as the starting date of VIP status and percentage of discount.
Is this Entity diagram correct? This is so fracking confusing. I've built this diagram on just intuition rather a systematic approach they teach in a textbook. I still can't wrap my head around the many-to-one relation, weak entities, foreign keys.
There's a fair article on ERDs on Wikipedia.
When you're starting a new ERD - whether it's hand-drawn or computer-drawn - you should focus first on the entities (entity sets). Add the relationships in and then worry about fleshing out your non-key predicates. When you get some experience with ERDs you'll get to the point where you won't need much more work to achieve normalization. It will start to come naturally to you.
There are probably quite a few changes that you'll want to make to your diagram. Since this may be homework, I'll give you an alternative diagram to consider:
This model takes a more sophisticated view of your rules, for example:
Songs can appear many times on the same CD and on different CDs.
A song can be performed by multiple artists within a given track.
Producers can cooperate on a CD.
None of these are necessarily right for your model. It depends on your business rules.
Compare your model with this one and ask yourself what is different and why you might want to take one approach or the other.
take all the major concepts, draw a box for each
in the box put the name of the major concept, like SONG then an underline
under the major concept, list all the attributes like NAME
draw lines from one box to another where those concepts are linked (usually through an attribute) like line from CD to SONG
I'm writing a CMS for various forms and such, and I find I'm creating a lot of drop-downs. I don't really feel like mucking up my database with tons of random key/string value tables for simple drop-downs with 2-4 options that change very infrequently. What do you do to manage this in a responsible way?
This is language-agnostic, but I'm working in Rails, if anyone has specific advice.
We put everything into a single LookUp table in the database, with a column that mapped to an enum that described which lookup it was for (title, country, etc.).
This enabled us to add the flexibility of an "Other, please specify" option in lookup dropdowns. We made a control that encapsulated this, with a property to turn this behaviour on or off on a case-by-case basis.
If the end user picked "Other, please specify", a textbox would appear for them to enter their own value. This would be added to the lookup table, but flagged as an ad hoc item.
The table contained a flag denoting the status of each lookup value: Active, Inactive, AdHoc. Only Active ones would appear in the dropdown; AdHoc ones were those created via the "Other, please specify" option.
An admin page showed the frequency of usage of the AdHoc values, allowing the administrators of the site to promote common popular values into general usage (i.e. changing their Status flag to Active).
This may well be overkill for your app, but it worked really well for ours: the app was basically almost entirely CRUD operations on very business-specific data. We had dozens of lookups throughout the site that the customer wanted to be able to maintain themselves. This gave them total flexibility with no intervention from us.
You cold have one single dropdown table with an extra column to say what the drop down is for... limit the results with a where clause...
At my current position, we implemented a LookupCode table that contains a CodeGroup,Code, and Meaning column, as well as some others (like active). That way you have a single table that contains all of your lookup values are in a single location and you can do some quick lookups to bind to your dropdown lists.