Database Design Issuee

Question

Dear All,
Need your expert Comments on this Issue.
We are about to design an application. One of the Entities in our Business process is a " Site " . Now for a single Site , there are 10 different department who store their own information .
e.g A Site named " Site-01" is expected to have 3 or 4 o5 different small houses.
A site has 5 Generators to suppy electricity etc.
Now Building a Room or house at a site is the responsibility of Civil Work Department while providing the Generator is the responsibilty of Power Department
I am a bit confused as how to design the table. should i design the seperate tables for Power , CIvil, RN or
Should i create a single table which has Site ID as its primary key and it may hold all information related to a Site , even though it is for different department,
eg.
A site table may look like
Site id CIvil Work Start date, Houses Build date, Generator provided dat
etc
Actually i am a bit confused as some ppl say that each department should have different tables, while some say that it should be a single table with different views.
IF it is a single table, then there must be some fields who will be empty , such as Civil work complete date will be empty unles until CIvil work gets completed, ,,
etc etc..
Please have your input so that i may get clear on this issue.
Looking forward to earliest resposes.
Thanks alot

Answer 1

> Do i need to created different tables for storing different department Progress date informatio
w.rt to Site
If there is a single SITE entity, a single DEPT entity, a single PROGRESS entity will be used. E.g.
PROGRESS = ( site_id, dept_id, progress_id, <attributes> )
The DEPT_ID constraint will be a foreign key to the DEPT table - to ensure the relationship of one DEPT entity can have many PROGRESS entities.
However, let's say that there are two department entities, one called PLANNING and the other ELECTRICTAL.
It is incorrect to use the name of the entity as an attribute. A single PROGRESS entity will then need to have the name of the entity as an attribute, e.g.
PROGRESS = ( site_id, entity_name_for_dept, dept_id, progress_id, <attributes> )
You cannot built referential integrity using dynamic table names that are stored as attributes (column values). SQL does not allow you to define such a constraint.
Another factor to consider is the attributes of PROGRESS entity. If the PLANNING's progress entity is different in attributes than ELETRICAL's progress entity, than there need to be two different progress entities. One should not force entities that look similar in nature to the the exact same entity. This type of mashing entities result in a table with 100+ columns, with columns 1-10 applicable to a relationship table1, columns 11-50 applicable for a relationship with table2, and so on.
The converse also applies. If an entity is used by both User1 and User2 (or Dept1 and Dept2), do not now create two different entities - one for each user/dept. This will require all the code (SQL, PL/SQL, Java, etc) that deals with these entities to know who the user or department is that is currently logged on, and base on that, dynamically select the appropriate table for that session.
In this case, SQL provides a feature called views to create different data sets (of the same table) for different users. Oracle extends this type of functionality by providing FGAC (Fine Grained Access Control) and VPBD's.