According to Kimball, Factless fact table are“fact tables that have no facts but captures the many-to-many relationship between dimension keys.”
A factless fact table is a fact table that does not have any measures. It is essentially an intersection of dimensions (it contains nothing but dimensional keys).
In my case, I am creating a fact table which captures for each employee :
their function
their role
their main manager
their department
their status
EntryDate
ExitDate
The event related to my fact table are :
- when any change is applied to the function, role main manager.. of an
already existing employee
- or a new employee has arrived
I am adding for historical need in my fact :
BI_StartDate
BI_EndDate
Is my fact table a Factless fact ?
The fact is containing the history : How can I track the date of updates if I am having an update of function and type of an employee of the same period ?
This is an example of a Type II dimension.
Notes:
The current record should have a null BI_EndDate
You can either join on Current Info by joining on EmpID and BI_EndDate is null
or
You can join on the record at the time
EmpID and [Comparison date]>=BI_StartDate and [Comparison date] <= ISNULL(BI_EndDate,'20991231')
Futhermore, I think your example of a factless fact seems more in line with many to many relationships.
As an example, think of students and classes. There are many students and many classes but the intersection of these two is a studentClass table. (with the official title of studentEnrollment but that not important).
I don't necessarily call this factless as the measure coming from this table are counts.
Related
I'm supposed to do a stakked column chart visualization about the total number of permits granted by authorizing department. So far ok, the problem is my datamodel.
My datamodel consists in 3 main tables:
PDT's(work permits)
Departamentos (SubDepartments)
Referencia(Departments)
I leave here the type of relationship between them:
The 1st table below It's about subdepartments. The primary key is the ID Column which is directly related to Nombre Column because It refers to Departments name. The thing is that Each of departments are inside another bigger than 1st one E.G.: Petronor is the biggest department, thats why It is not inside another one and the column name of DepartamentoPadreId is null in this field, but Economico Financiera, Fiabilidad y Mantenimiento, Ingeniería y Desarrollo, Producción, P&O, SMA and OTROS are inside of PETRONOR and this is how works this table.
The problem is that names are too long to put in my Dashboard so what I did was create a new table relating the names from DepartmentoPadreId to another with the acronyms.
Now I have my last table where I have the work permits of employees. This permits are made by a Department for another. This means that I have several relations with this table by Departamentos Table. One relation is with the Authorizing Department and another with Authorized Department. And here is my problem
What I expect to get is two stakked column charts with different values for each one. One: the Total number of permits by Authorized Department Second: The total number of permits by Authorizing Department.
The problem is I'm getting the name from the Relacion-Direccion Table because is the only table that contains the name I want to appears in my dashboard and I dont know how to filter It by the specific column in PDTs table I want.
I have 2 questions regarding a project. Would appreciate if I get clarifications on that.
I have decomposed Address into individual entities by breaking down to the smallest
unit. Bur addresses are repeated in a few tables. Like Address fields are there in the
Client table as well as Employee table. Should we separate the Address into a separate table with just a linking field
For Example
Create an ADDRESS Table with the following attributes :
Entity_ID ( It could be a employee ID(Home Address) or a client ID(Office Address) )
Unit
Building
Street
Locality
City
State
Country
Zipcode
Remove all the address fields from the Employee table and the Client table
We can obtain the address by getting the employee ID and referring the ADDRESS table for the address
Which approach is better ? Having the address fields in all tables or separate as shown above. Any thoughts on which design in better ?
Ya definitely separating address is better Because people can have multiple addresses so it will be increasing data redundancy.
You can design the database for this problem in two ways according to me.
A. Using one table
Table name --- ADDRESS
Column Names
Serial No. (unique id or primary key)
Client / Employee ID
Address.
B. Using Two tables
Table name --- CLIENT_ADDRESS
Column Names
Serial No. (unique id or primary key)
Client ID (foreign key to client table)
Address.
Table name --- EMPLOYEE_ADDRESS
Column Names
Serial No. (unique id or primary key)
Client ID (foreign key to employee table)
Address.
Definitely you can use as many number of columns instead of address like what you mentioned Unit,Building, Street e.t.c
Also there is one suggestion from my experience
Please add this five Columns in your each and every table.
CREATED_BY (Who has created this row means an user of the application)
CREATED_ON (At what time and date table row was created)
MODIFIED_ON (Who has modified this row means an user of the application)
MODIFIED_BY (At what time and date table row was modified)
DELETE_FLAG (0 -- deleted and 1 -- Active)
The reason for this from point of view of most of the developers is, Your client can any time demand records of any time period. So If you are deleting in reality then it will be a serious situation for you. So every time when a application user deleted an record from gui you have to set the flag as 0 instead of practically deleting it. The default value is 1 which means the row is still active.
At time of retrieval you can select with where condition like this
select * from EMPOLOYEE_TABLE where DELETE_FLAG = 1;
Note : This is an suggestion from my experience. I am not at all enforcing you to adopt this. So please add it according to your requirement.
ALSO tables which don't have any significant purpose doesn't need this.
Separating address into a seperate table is a better design decision as it means any db-side validation logic etc. only needs to be maintained in one place.
I am wondering if it is okay to have master and detail table for employees?
As per requirments, data can filtered by department by country and by employee code on report level.
If employee's department or country code is changed then the changes will go in detail table and old record will be set to IS_ACTIVE = 'T'.
---------------------Master Table--------------------------------------
**EMPLOYEE_CODE** VARCHAR2(20 BYTE) NOT NULL,
EMAIL VARCHAR2(100 BYTE)
FIRST_NAME VARCHAR2(50 BYTE)
LAST_NAME VARCHAR2(50 BYTE)
WORKING_HOURS NUMBER
---------------------Detail Table--------------------------------------
**PK_USER_DETAIL_ID** NUMBER,
FK_EMPLOYEE_CODE VARCHAR2(20 BYTE),
FK_GROUP NUMBER,
FK_DEPARTMENT_CODE NUMBER,
FK_EMPLOYER_COUNTRY_CODE VARCHAR2(5 BYTE),
FK_MANAGER_ID VARCHAR2(20 BYTE),
FK_ROLE_CODE VARCHAR2(6 BYTE),
START_DATE DATE,
END_DATE DATE,
IS_ACTIVE VARCHAR2(1 BYTE),
INACTIVE_DATE DATE
Employee table will be linked with Timesheet table and for timesheet reports data can be filtered by department, country and by employee code.
OPTION : I
Have one employee table with one Primary Key and create a new entry whenever department or role is updated for an employee.
Add country and department code in the timesheet table.
--> This way i don't need to search employee table.
OPTION : II
Have master and detail table.
Add country and department code in timesheet table.
--> This way i don't need to search employee table plus i will have master detail table
OPTION : NEW
Have master and detail table.
Timesheet table will have EmpCode.
If user move to new location or change department then Insert a new row in the detail table with the new dept Code and same Emp No.
Update an old row and set the End Date field so if he changes his location or department then the End Date field needs to be updated.
Which one is a best option and is there any other better option available?
This is one way of implementing this requirement, and it's an approach many people take. However, it has on emajor drawback: every time you query the current employee status you need to filter the details on start and end date. This may seem like a trivial thing, but you wouldn't believe how much confusion it can cause, and it has performance implications too.
These things matter, because most of the time you will want only the current details, with queries on history being a relatively rare occurence. Consequently you are hampering the implementation of your most common use case to make it easier to implement a less-used one. (Of course I am making assumptions about your business requirements, and perhaps yours is not a run-of-the-mill employee application...)
The better solution would be to have two tables, an EMPLOYEES table with all the detail columns too and an EMPLOYEES_HISTORY table with the same columns plus the start and end date. When you change an employee's record insert a copy of the old record in the History table, probably by a trigger. Your standard processes have just the one table to query, and your history needs are met fully.
By the way, your proposed data model is wrong. Working_hours, email_address and last_name are definitely things which can change and perhaps even first name (e.g. through changes in personal circumstances such as getting married). So all those columns should be held in your details name
Option 3 - Please note that this option is useful only for the reports Point of View.
Whenever you insert the data, create a De-Normalized entry in a new table.
Whenever an entry will be updated, the De-Normalized entry will be updated in the new table.
The New Table will have all De-Normalized columns of Employee.
So while Performing the search, this will benefit you as the results will be calculated without using Joins. Thus, the access time will be reduced.
Records in the new table will be Created/Updated in The Insert/Update Trigger.
Improvements in Option - 2 and Option 1
Don't create redundancy by adding duplicate columns.
I have problem with two parts of database diagram and I need your guidance:)
database has a lot of tables that one of them is about Employee ,the other is about Customer and ... ! I have problem with two tables (Product and OrderDetail) my Product table has 3 columns (ProductID,Name,Cost) and the Other table is OrderDetail that has these columns(OrderDetailID,Cost,Quantity) I have not created this database myself I have found it like a sample database in the internet but I have problem about these two Cost which is in OrderDetail and Product tables ,what is the difference between these Cost? they are the same or not?
thanks
EDITED: sorry all I had a mistake ,the ID for the ordeDetail table is the composite of primary key of Product table and Order table which is Product ID and OrderID and the OrdeDeatil table is a weak entity. SO
OrderDeatil((ProductID,OrderID),Cost,Quantity)
I suppost that the cost in the products table is the current price of the product. On the other hand, the cost in the order details table is the price that was paid for the product for that particular order.
Product prices can go up or down, or discounts might have been given for particular orders. The field in the order details table would store this information.
UPDATE: Further to your updated question, that makes sense. It implies that each order can only list the same product once. The order details table is storing how many items of that product were ordered (quantity) and I would say that cost is the price paid for one item. It could be the total (price * quantity) but that's not a common for such table structures.
Without knowing exactly what this database is meant to capture, I couldn't say for sure, but as a rough guess I would expect that the Product tables Cost column is the cost for a single unit of that product, and the OrderDetail tables Cost column is the cost for an order of some quantity of 'something' - most likely a certain quantity of a product. Note as an interesting aside that there is nothing linking the OrderDetail table to the Product table - if these two tables are meant to be linked you would normally expect a Foreign Key in the OrderDetail table linking it to the Product table. At the moment, there is no way to match OrderDetails to Products.
I have a problem with a many-to-many relation in my tables, which is between an employee and instructor who work in a training centre. I cannot find the link between them, and I don't know how to get it. The employee fields are:
employee no.
employee name
company name
department job title
business area
mobile number
ext
ranking
The Instructors fields are
instructor name
institute
mobile number
email address
fees
in a many-to-many relationship the relationships will be in a 3rd table, something like
table EmployeeInstructor
EmployeeID
InstructorID
to find all the employees for a specific instructor, you'd use a join against all three tables.
Or more likely there will be classes involved --
Employee takes Class
Instructor teaches Class
so you'll have and EmployeeClass table,
an InstructorClass table,
and join through them. And Class needs to be unique, or else you'll need
Class is taught in Quarter on ClassSchedule
and end up joining EmplyeeClassSchedule to InstructorClassSchedule.
This ends up being one of your more interesting relational designs pretty quickly. If you google for "Terry Halpin" and "Object Role Modeling", this is used as an illustrative situation in the tutorial.
First of all, you will need a unique key in both tables. The employee number may work for the employee table, but you will need another for the instructor table. Personally, I tend to use auto incrementing identity fields called ID in my tables. This is the primary key.
Second, create a new table, InstructorEmployee. This table has two columns, InstructorID and EmployeeID. Both fields should be indexed. Now you can create an association between any Employee and any Instructor by creating a record which contains the two IDs.