Let's say 2 fact tables Employee_Fact and Manager_Fact are available. And the dimension tables like Organisation_Dim, Location_Dim, Department_Dim, Calender_Dim.
Employee_Fact is connected with all the dimension Tables and Manager_Fact is connected with the alias of the same dimension tables.
In Report 1, I have a table that gives the Organisation_Name, Department_Name, Employee_Salary, Manager Name and Manager Salary. In this report I need the filter Organisation Name, Region. Also, the drill down from Organisation Name --> Department Name --> Location --> Manager Name --> Employee Name.
I have 2nd Report that shows the Organisation Name, Department Name, Department Amount, Location Name, no of Employee. Here I have drill down from Organisation name --> Department name --> Location.
How can I obtain drill down in this scenario. Do I need to add 2 different Hierarchy or only one hierarchy is needed? This confusion occurred as I take values from both fact tables in 1st report.
For the example you described, you would probably be better off not creating aliases of your conformed dimension tables, but instead joining all dimension tables to both fact tables, then creating two contexts. One context would include all of the joins between employee_fact and the dimensions; the other context would include manager_fact and the dimensions.
If there are any dim tables that are not conformed, then they will simply be joined to only one fact table (and, accordingly, will only be in one context).
With this model, you can create a single query that includes measures from both facts, and attributes from one or more dim table. The report engine will automatically create a separate SELECT query for each fact table; but it will be presented as a single block in the report.
You will also only need a single hierarchy since you no longer have multiple copies of dimensions.
Regarding your statement:
I have 2nd Report that shows the Organisation Name,Department Name,
Department Amount, Location Name, no of Employee. Here i have drill
down from Organisation name --> Department name --> Location.
This doesn't really make sense. If your report block already contains Department Name and Location, there would be little value in offering a drilldown from Organization Name.
It was a mistake that I did not select the same drill down objects in my Report too. Rather I selected from other Class Folder which did not give correct hierarchy.
Thanks
Niki
Related
I am trying to create a new dimension in my cube, that is a subset of another dimension. I am working with SQL Server Analyisis Services.
I have a measure that represents the number of employees in my organization, both in brach offices and in the central office, and I have a Location dimension that contains all offices.
I want to create a new dimension that contains only branch offices, so that when I apply it to the measure it show me only the numbers in the branch offices and the total aggregates only the employees in them.
I could create another dimension table with only the branch offices in it, but then I would have employees asigned to an Unknown member (the central office)
I also want to keep the original dimension, where I can see all offices and get the total of employees in the organization.
I understand I could get that result using with my current Location dimension applying a filter to my query, but I was wondering if it was possible to create a "pre-filtered" dimension.
You could add an additional measure (possibly calcualted) called something like Branch Office Employee Count that excludes head off employees. The name of the measure should make a count of 0 against the head office self explanatory.
If this is something your business often measures I'd take this approach. If not I'd put a new field in the existing dimension for filtering/etc.
I am just curious why do we need to use one-one, many-one or one-many and many-many in database
It's all about need , in programming we need to maintain data in databases . in many situations we need to create related tables , these kind of related tables connected with relations . for example if you build a application to maintain the user contacts , then you need to design a table for user and contact . here you will be relate both the tables
If you mean, why do we distinguish between cardinalities of relationships, then the answer is that there is no need. All that matters is that we identify & describe sufficient relationships to describe every application situtation.
The cardinality of participation by entities in a relationship is just one property of the relationship. Eg if table EmployeeManager holds the rows where "manager M manages employee E" then it doesn't matter to filling the table whether there is only one manager per employee or one employee per manager; you just look at the world and put the rows that make a true statement from that statement template into the table. Eg Ditto for interpreting a table: the rows are all those that make the statement template into a true statement about the world. You don't need to know cardinalites to query. Eg if table DepartmentManager holds the rows where "manager M manages department D" then EmployeeManager NATURAL JOIN DepartmentManager holds the rows where "manager M manages employee E AND manager M manages department D" whether or not there is only one manager per employee, or employee per manager, or manager per department, or department per manager.
But the benefits are that if we tell the DBMS then it can keep out invalid states, and if we tell users then it can help them understand what the relationship statement templates mean or why the DBMS disallowed a putative erroneous update.
I am going to model one of the star schemas for a university data warehousing project. We need to compare the actual application count with a target.
There are target counts (set by the colleges every year) associated with Departments, Course groups, and Courses.
The requirement is to ensure that the targets set get correctly allocated and also the progress of applications against the target.
One proposal is to include all the actual counts (department level total accepted count, course group level total accepted count, course level total accepted count) and corresponding target counts (dept level target counts, course group target counts, course target counts) in single fact table. One of the dimensions in this star schema is Course dimensions. It consists of all the
course, course group and department information. I do understand a granularity problem here, but this could be handled at the cube implementation level.
Or if I want to set the target at different hierarchy levels of a dimension, should I build different fact tables? As mentioned below:
Implement 3 fact tables for 3 different types of targets and connect these fact tables to the actual fact table. In this situation, the Course dimension can snowflake into course group dimension and department dimensions. First fact is connected to course. Second fact to course group and the 3rd one to dept. The actual fact table is of granularity of course level so all three fact tables can be connected to the actual fact table via course. Note that the actual fact table is of grain course-level and this can be aggregated to get higher level such as course group and dept actual counts.
Data Architects please comment!
Because it may be relevant, the DBMS I am using is Teradata.
I have two tables named Table A and Table B. Table A contains employee personal and company data (company-issued ID, name, pay type, etc.), and Table B
contains information concerning the jobs each employee has held or is currently holding. The primary key for both tables is the employee's company-issued ID number.
Currently, I am trying to write a query that partly entails retrieving an employee's current position.
This seems like it should be easy, especially since Table B stores "effective" dates and "expiration" dates for each job, however, there is a problem.
In the company I work for, there are two different systems used to track employees. Each system is identified by human resources code.
The codes for each system and which employees are included in that system are as follows:
If you work in a retail store in a non-managerial position, your
system is identified by code "1".
If you work in a retail store in a
managerial position or you work for corporate, your system is
identified by code "2".
Each record in Table B has a field indicating which HR system that particular job is tied to.
Occasionally, someone working at a store in a managerial position may need to have a record in the system identified by code "1" in order to have access to
some store-level systems they need to do their work. When this happens, another job record is added to Table B for that employee that is tied to system "1". In such cases, for that particular employee, their two most current records in Table B will correspond
to their actual position within the company while the other will be the additional record created for them. Additionally, these records often have "effective" dates that are later than the "effective" date for the employee's actual job.
In my query, I need to obtain each employee's actual job from Table B. It is known that every genuine system "1" employee is hourly, while everyone in
system "2" is salaried. Table A has a field indicating each employee's current pay type.
So, basically, for each employee included in my query, I need to filter out any cases where an employee has a system "1" record in Table B while Table A indicates that
the employee is salaried and not include them when calculating the employee's actual current position.
I apologize for the "wall of text" here, but I feel this problem is fairly complex, so I wanted to be sure you were aware of all the relevant details.
Admittedly, I am still learning SQL, so if there are any constructs or aggregate functions that can help, please let me know.
Thank you for your time.
I'm looking at this company's database design, and would like to know the purpose of their design, ie store relationship in one table and the data in another, why do this?
They have this,
EMPLOYEE
Id (PK)
DepartmentId
EMPLOYEE_DATA
EmployeeId (PK)
First Name
Last Name
Position
etc...
Rather than this...
EMPLOYEE
Id (PK)
DepartmentId
First Name
Last Name
Position
etc...
...OR this...(employee can belong to many departments)
EMPLOYEE
Id (PK)
First Name
Last Name
etc...
EMPLOYEE_DEPARTMENT
Id
EmployeeId
DepartmentId
Position
That's a link table, or join table, or cross table.. lots of different names.
How would you assign an employee to two different departments with your design? You can't. You can only assign them to one.
With their design, they can assign the same ID to multiple departments by creating multiple records with the employee ID and different department ID's.
EDIT:
You need to be more specific about what you're asking. Your first question seemed to be asking what the purpose of mapping table was. Then you changed it, then you changed it again.. none of which makes much sense.
It seems now that you are asking what the better design is, which is a totally different question than what you originally asked. Please state specifically what question you want answered so we don't have to guess.
EDIT2:
Upon re-reading, if this is the actual design, then no.. It does not support multiple department id's. Such a design makes little sense, except for one situation. If the original design did not include a department, this would allow them to add a department ID without modifying the original EMPLOYEE_DATA table.
They may not have wanted to update legacy code to support the Employee id, so they added it this way.
Purpose of design is determined by business rules.
Business rules dictate entity (logical model perspective) / table (physical model perspective) design. No design is "bad" if it is built according to the requirements that were determined based on business rules. Those rules can however change over time -- foreseeing such changes and building to accommodate/future-proof the data model can really save time, effort and ultimately money.
The first and third example are the same -- the third example has an extraneous column (EMPLOYEE_DEPARTMENT.id). ORMs don't like composite keys, so a single column is used in place of.
The second example is fine if:
employees will never work for more than one department
there's no need for historical department tracking
Conclusion:
The first/third example is more realistic for the majority of real-world situations, and can be easily customized to provide more value without major impact (re-writing entire table structure). It uses what is most commonly referred to as a many-to-many relationship to allow many employees to relate to many departments.
If an employee can be in more than one department, then you would need a mapping table but I'd do it like the following:
EMPLOYEE
Id (PK)
First Name
Last Name
DEPARTMENT
Id (PK)
Name
EMPLOYEE_DEPARTMENT
EmployeeId_fk (PK)
DepartmentId_fk (PK)
Position
This would allow for multiple positions in multiple departments.
You would do this if an employee can be a member of multiple departments. With the latter table, each employee can only belong to one department.
The only remotely good reason for doing this is to implement an extension model where the master table identifying unique customers does not include all the data for customers that is not always necessary. Instead, you create one core table with the core employee data and and extension table with all the supplementary fields. I've seen people take this approach to avoid creating large tables with many columns that are rarely needed. However, in my experience it's typically premature optimization, and I wouldn't recommend it.
In contrast to many responses, the model included does not support multiple departments per employee - it is not a many to many mapping approach.