TABLE DESIGN

Hi I have this business rule which makes my table design very complex(at least for me)
My application keeps track of all the patients who are admitted to the hospital with some diagnosis(disease) like TB,asthma,Heart attack etc.Also my application is suppose to keep track of any procedure (operations) like Heart transplant,heart surgery etc performed on the patients.Later,depending upon the diagnosis and procedure ,the patients are clubbed under one group (help is needed to create the table for this group).
To satisfy my requirements I create a the following tables
DIAGNOSIS
Diagnosis_code pk
Diagnosis_Desc
PROCEDURE
Procedure_Code pk
Procedure_Desc
Now I am confused on how to create the table for patient group.I mean if any patient is suffering from a diagnosis like heart attack and has undergone a procedure like Heart transplant then this kind of patient should be clubbed under the group say XYZ.Similarly if any patient is suffering from TB and has undergone a procedure like Kidney transplant then he should be clubbed under the group say ABC.In short for every patient in the hospital this table is read to club the patient under certain group.Example
PatientGroup1 SomeDiagnosisCode1 SomeDiagnosisCode2 SomeProcedureCode1
PatientGroup2 SomeDiagnosisCode1 SomeProcedureCode6
PatientGroup3 SomeDiagnosisCode8 SomeProcedureCode9 Some DiagnosisCode6
etc etc
Please help with the design of the Patient group table.
thanks
MS

Depends on a few factors ...
The most flexible (that I can think of right now) design would be as follows:
DIAGNOSIS
diag_id
diag_desc
PROSEDURE
proc_id
proc_desc
PATIENT
patient_id
patient_name
PATIENT_DIAG -- associates zero, one, or more diagnosis with a patient
patient_diag_id
patient_id
diag_id
PATIENT_PROC -- associates zero, one, or more procedures with a patient
patient_proc_id
patient_id
proc_id
DIAG_PROC_CAT -- identifies a Group
diag_proc_cat_id
diag_proc_cat_desc
DIAG_PROC_CAT_DIAG -- associates zero, one, or more diagnosis with a Group
diag_proc_cat_diag_id
diag_proc_cat_id
diag_id
DIAG_PROC_CAT_PROC -- associates zero, one, or more procedures with a Group
diag_proc_cat_proc_id
diag_proc_cat_id
proc_id
PATIENT_DIAG_PROC_CAT -- associates zero, one, or more Groups with a patient
patient_diag_proc_cat_id
patient_id
pdpc_precedence_nmbr -- (1=highest ... don't need it if you're only gonna allow one association)
diag_proc_cat_id
Put the business rule code in TRIGGERs for PATIENT_DIAG and PATIENT_PROC to INSERT appropriate values into PATIENT_DIAG_PROC_CAT ... INSERT proper rows into DIAG_PROC_CAT, DIAG_PROC_CAT_DIAG, and DIAG_PROC_CAT_PROC tables to support business rule (if patient has same diagnosis and procedures as a Group/Category, then assign that Group/Category to the patient ... if more than one applies, you may or may not allow it ... if you do, indicate which is primary if doubling on reports/ui is a bad thing) ... Users may modify DIAG_PROC_CAT, DIAG_PROC_CAT_DIAG, and DIAG_PROC_CAT_PROC tables as needed to manage their own Groups/Categories.
Good luck.

Similar Messages

Table Designer third rule thick is not working for me. Any suggestions?

I am trying to turn the third rule in a four row table thick. I go into Table Designer and select Every 3rd Thick. The others are all none. The table is not responding to the command to make the third rule thick as I need it to be. Does anyone have any suggestions? Thank you.

To remove table format overrides, you need to go to Table > Format > Custom Ruling and Shading, and set as follows:
For more info, see page 171 of my book.
-Matt
Matt R. Sullivan
co-author Publishing Fundamentals: Unstructured FrameMaker 11

FND tables design

Hi,
I was going through FND Design Data section on eTRM website .
I need to understand a few things about table design here.
I was surprised to see one composite primary key and one composite unique key instead of primary keys in single columns(concurrent_queue_id,concurrent_program_id and concurrent_processor_id) in the following tables
FND_CONCURRENT_QUEUES -- Primary Key: FND_CONCURRENT_PROCESSORS_PK(columns:application_id,concurrent_queue_id)
               Primary Key: FND_CONCURRENT_PROCESSORS_UK1(columns:application_id,concurrent_queue_name)
FND_CONCURRENT_PROGRAMS -- Primary Key: FND_CONCURRENT_PROGRAMS_PK(columns:application_id,concurrent_program_id)
               Primary Key: FND_CONCURRENT_PROGRAMS_UK1(columns:application_id,concurrent_program_name)
FND_CONCURRENT_PROCESSORS -- Primary Key: FND_CONCURRENT_QUEUES_PK(columns:application_id,concurrent_processor_id)
               Primary Key: FND_CONCURRENT_QUEUES_UK(columns:application_id,concurrent_processor_name)
Let's consider FND_CONCURRENT_QUEUES table for instance.
As per my understanding, concurrent manager name and id has to be unique throughout the suite.
But, by decalring them as composite primary/unique key with application_id column,Oracle is saying that the uniqueness of concurrent manager's id and name is maintained across one particular module(application like AP,GL etc) only and not across the entire suite.
Is that actually the case?
Also,this concurrent_queue_id column is used as foreign key for many tables.
Now, for a column to be used as a foreign key, it has to be either unique key or primary key itself alone(not a part of a composite key) in its parent table.
In this case the column is a part of a composite primary key and still being referred from many tables as foreign key.
Please clarify.Any additional comments on this are very welcome.
I have exactly the same questions for the PROGRAMS and PROCESSORS(program library) tables as well.
Thanks,
Rushi

http://etrm.oracle.com/pls/etrmlatest/etrm_search.search
requires a metalink userid

Table design help

I have simple table design issue which I would appreciate some feedback on. Lets say I have two tables to start: users and addresses. Both tables have their primary keys of userid and addressid. Assume no two users can share an addresss.
Is it better to have the userid in the address table, so as to associate the addresses to users OR is it better to have a third table only for associating userid's and addressid's? The latter requires an extra table but appeals to me more because the address table remains purely addresses... seems more appropriate for some reason, but I could be wrong.
Thanks

Frank Kulash wrote:
Hi,
When deciding which is the best option, weigh the costs and benefits of each option. What are the advantages and disadvantages of each?
The two-table model is certainly simpler. Joins will be more efficient, and slighltly less storage will be required.
What is the advantage of the three-table model? Why does it appeal to you? In the imaginary world where no two users can share an address, it makes sense to think of resident as an attribute of address. Each address can be related to (at most) one user, just like each address can be related to (at most) one postal code.
But, as others have said, that is an imaginary world. Even if you're designing an application where you know there is some kind of business rule that prevents two users from being at the same address, can you be sure that business rule won't change next month?
So I see the relevant costs ot the two-table design as: (the probablility of proving inadequate in the future) * (cost of re-writing all the queires based on the two-table design)
I see the costs of the three-table design as: extra time needed to write and execute joins + marginal costs of an additional table.
In practice, few applications really treat address as an entity. It's more common for address to be considered an attribute of the person, or, if a person can have multiple addresses, to have a separate table that links each address to a single person, with no attempt to minimize duplicates.You make two key points here that I'd like to highlight, just for re-emphasis to the OP.
The first is that business rules can change. When analyzing data relationships, one should always ask if the relationship definition is immutable or simply a reflection of the current business rule. For instance, gender is considered to be immutable. If gender is a property of the entity being tracked, you can pretty much figure that there will never be but two possible values, and only one value current at any given time. But if the business rule says an entity can only have one address ... that rule is definitely subject to change. So the design should be such as to already allow for a different rule. I spent 21 years at an auto manufacturing plant. When the plant was first built, the business rule was there would only be one line of vehicles, and only one shift a day. The IT people tried to build systems to allow more flexibility, but the business side said NO. They paid for that for the next 20 years. In the case of the OP's example, it is most definetly possible for a person (or business) to have more than one address, and it is just as possible for more than one person (or business) to share a single address. The system should be designed for that regardless of the business rule.
The other big point is that data designers need to pay close attention to what constitutes an "entity" vs. an "attribute". Making that distinction is key to getting a good 3NF design.

Fact table design horizontal vs vertical

Hi Guys,
I am putting together a list of advantages and disadvatages of horizontal vs vertical fact table orientation.
Vertical:
ID, DimensionKey1, DimensionKey2, Factno (or KPIDimensionKey), Fact
Advantages:
-Easily extendible when new facts are integration
-A lot more rows
-Density
Disadvantages:
-Applications that can only deal with the horizontal format require a few to
transpose the rows into columns (additional computing time)
Horizontal:
ID, DimensionKey1, DimensionKey2, Fact1, Fact2, Fact3, Fact4, Fact5,...
Advantages:
-The most common fact table design
-Possibly faster access
Disadvantages:
-Sparsity
-Not easy to extend

Do you agree or can add something?

Table design question

Hello,
I have a quick question on a table design. I currently have a table that will store approval information on a report. The individual report will need to go through 3 levels of approval before it's considered final. I have considered a few different scenarios on how to design the table but I'm not sure on what is the best choice. Currently I'm using 3 columns that will store each approval. For example,
Table 1:
file_id,
subject,
summary,
division_approve,
program_approve,
group_approve
I thought about using one column and simply stepping through a higher numeric value for each approval but found that doesn't work if I want to view items that were approved only at the division_approve level. Does anyone else have any suggestions? Hopefully I provided enough information.....
Thanks in advance!
Randy

yes, better going for higher level of normalisation and desiging more tables:
tab_aproval ( id,File_id,Approval_authority,rank )
id      File_id Approval_level rank
1     1 first_level 1
2     1 second_level 2
3     1 third_level 3
4     2 first_level 1
5     2 second_level 2
tab_file_approval
file_id, subject, summary, id
1 'doc 1' 'first level done' 1
1 'doc 1' 'second level done' 2
1 'doc 1' 'third level done' 3

Advise on Table design

Dear all,
I have a pool of data which are based organized has CATEGORY and SUB-CATEGORY. When I am configuring the database I should be able to define all categories at once, then being able to define which one is the Parent category of the others.
For exemple if I have a set of Dishes for a restaurant, then I can classify those dishes in different menu category which are then the Parents category for dishes.
Please note that a SUB-CATEGORY can have other sub categories attached.
To have a better idea of what I am trying to do is similar things when you create folders and sub folders on a file system. From the configuration side of the database I should be able to define my category and subcategories and then organize them by a link
ID or other stuff, in the same way I will organize folder.
What will be the best Database table design for that scenario ?
I am not a DBA, but have some basis so try to speak the same language as me :-)
Thanks for help
regards

I think you have it with your design. There are a few ways to represent a hierarchy in SQL, and having two tables like this:
CategoryID    CategoryName
ParentCategoryID
1001
Dishes          NULL
1002          Desserts
1001
1003          Icecream
1002
SubCategoryID    SubCategoryName
CategoryID
10001
Vanilla
1003
10002
Strawberry
1003
10003                   Butterscotch             1003
Make sense ONLY if you can guarantee a two level hierarchy (or a fixed number of levels, where you might have yet another table SubSubCategory). Having a fixed number of levels can make processing a ton easier because your queries can be written in
a straightforward manner because the levels of nodes in the tree remain the same.
Your requirements here:
"CATEGORY can have other sub categories attached."
Leads to the more flexible solution like you have set up:
CategoryID    CategoryName
ParentCategoryID
1001
Dishes          NULL
1002
Starters
1001
1003
Item1
1002
1004
SubCat1
1003
1005
SubCat2
1003
1006
SubCat3
1003
Because adding a subcategory on SubCat3 is as simple as:
1007          SubSubCat1
1006
Processing the hierarchy becomes an iterative process (using a recursive CTE) if you have needs to do a lot of aggregation on groups. There are techniques available to make things go faster than using this pattern in the implementation, but unless
you are going to need 1000s of nodes, then this pattern works great (known as the adjacency list, where you are basically storing the adjacent node in your tree).
Louis
Without good requirements, my advice is only guesses. Please don't hold it against me if my answer answers my interpretation of your questions.

Reg Table Design

Hi,
Iam working on the Customization of table in WebDynpro.I have an application which has 2 views - TableView and CustomView.In the CustomView i have a dropdownbyindex ui element which has the values as "Standard", "Transparent", "Alternating".When the user selects any of these values and clicks on the Apply button, the table design should be changed in the TableView.
Can anyone guide me as how to proceed with this?
I hope i made my requirement very clear.
Regards,
Padmalatha.K
Points will be rewarded.

Hi,
Create an attribute of type "TableDesign" [com.sap.ide.webdynpro.uielementdefinitions.TableDesign]
bind this attribute to the Type property of the table.
In the init set the values as follows. or else change according your need.
wdContext.currentContextElement().setTableDesign(WDTableDesign.STANDARD);
And in the action handler of your drop down by index you can use the following code
In the below code my attribute name is TableDesign
Based on the condition you can use the following code to change the Type.
//Assuming the key returns you the selected value as int 0..1..2
switch (key) {
     case 1:
          wdContext.currentContextElement().setTableDesign(WDTableDesign.ALTERNATING);
          break;
     case 2:
          wdContext.currentContextElement().setTableDesign(WDTableDesign.TRANSPARENT);
          break
     default:
          wdContext.currentContextElement().setTableDesign(WDTableDesign.STANDARD);
          break;
Regards
Ayyapparaj

Table Design "alternating" only in readonly tables? (NW 7.10 SP7)

Hello,
I just found out, that style "alternating" is only applied to a table, when the table is set to read only. Should it be this way?? I see no reason for that behaviour.
Bug or feature in Netweaver 7.10 SP7? Same behaviour is shown already in Developer Studio, Design of table changes only if table is read only.
Frank

Hi
Please refer the below forum:
Problem with table design in 2004s
Re: Reg: Table's Design Property Alternating
Thanks
Susmita

Joe - Why was SURROGATE KEY left out from ISO table design?

The lack of SURROGATE KEY causes lots of confusion and ultimately loss of productivity. Common practice in SQL Server development to make the SURROGATE KEY the PRIMARY KEY, the source of all trouble because it is not really the "PRIMARY KEY" just
a meaningless integer identifier.
Example:
CREATE TABLE Products (
ProductID INT SURROGATE KEY,
ProductNumber char(12) PRIMARY KEY,
Name nvarchar(100) NOT NULL UNIQUE,
ListPrice DECIMAL (12,2) NOT NULL,
Color varchar(10) );
Is there a hope of correcting this issue?
Thanks.
Kalman Toth Database & OLAP Architect
SQL Server 2014 Database Design
New Book / Kindle: Beginner Database Design & SQL Programming Using Microsoft SQL Server 2014

Thanks Joe.
In SQL Server world we do use SURROGATE IDENTITY (or SEQUENCE object) INT in table design. That's like in our DNA even if it conflicts with Codd. AdventureWorks sample:
SELECT ProductID, ProductNumber, Name, ListPrice, Color
FROM Production.Product ORDER BY ProductNumber;
ProductID ProductNumber Name ListPrice Color
899 FR-T67Y-44 LL Touring Frame - Yellow, 44 333.42 Yellow
900 FR-T67Y-50 LL Touring Frame - Yellow, 50 333.42 Yellow
901 FR-T67Y-54 LL Touring Frame - Yellow, 54 333.42 Yellow
902 FR-T67Y-58 LL Touring Frame - Yellow, 58 333.42 Yellow
886 FR-T67Y-62 LL Touring Frame - Yellow, 62 333.42 Yellow
890 FR-T98U-46 HL Touring Frame - Blue, 46 1003.91 Blue
ProductID is the (SURROGATE) PRIMARY KEY
ProductNumber is the NATURAL KEY (created by the accounting department) - this is the real "PRIMARY KEY"
Name is the CANDIDATE KEY (too long to be a key)
In RDBMS theory when we talk about PRIMARY KEY we mean the ProductNumber column which is used in real life.
However, in reality the ProductID INT meaningless number is the PRIMARY KEY, while the meaningful ProductNumber has to settle for a UNIQUE KEY or unique index.
I understand your point that we should not use SURROGATES, but we do. It's like in our (SQL Server) blood. If I go to a company and design for them without SURROGATE IDENTITY/SEQUENCE, they would fire me. From an ORACLE forum: "Basically,
always use a surrogate key. There are a few special cases where a surrogate key really isn't any better than some "natural" key, and whatever effort is needed to create and populate a surrogate key would just be wasted. These situations
are pretty rare.
Here's one example: Say you have a many-to-many relationship between employees and departments, that is, each employee may be related to 0 or more departments, and each department may be related to 0 or more employees, but an given employee can only be
related to a given department 1 time. In that case, a primary key consisting of both columns, dept_id and emp_id, is about as good as a surrogate key. You'd need a unique constraint on (dept_id, emp_id) in any case, and I don't see any need to create a surrogate
key." LINK:
https://community.oracle.com/thread/2527771?tstart=0
I tell you Joe, 90% of the world running on SURROGATE PRIMARY KEY tables, so why should we care about Codd at this point? Even the perfect PRIMARY KEY candidate, social security number, may have problems such as stolen SSNo duplicates among others: "Natural
key. A key that is formed of attributes that already exist in the real world. For example, U.S. citizens are issued a Social Security Number (SSN) that is unique to them (this isn't guaranteed to be true, but it's pretty
darn close in practice). SSN could be used as a natural key, assuming privacy laws allow it, for a
Person entity (assuming the scope of your organization is limited to the U.S.)." LINK:
http://www.agiledata.org/essays/keys.html A good advice from the article: "Don't naturalize surrogate keys. As soon as you display the value of a surrogate
key to your end users, or worse yet allow them to work with the value (perhaps to search), you have effectively given the key business meaning. This in effect naturalizes the key and thereby negates some of the advantages of surrogate keys."
Kalman Toth Database & OLAP Architect
SQL Server 2014 Database Design
New Book / Kindle: Beginner Database Design & SQL Programming Using Microsoft SQL Server 2014

Alternating table design

Hi all !
I have a problem. How can I set the table design to alternating ? In properties I set it up, but ineffectually.

Thanks, but I can't give you points, I will pay you a coffee or tee if you want.

Cannot open table designer

Hi!
I am creating an ASP.NET Web Form hosted on Azure with Visual Studio 2013 Community. When I want to add a table to the database, SQL
Server Object Explorer->SQL server->Database->Table folder->Add, is trying, but won't open the table designer. It says: "Failed to obtain schema information from database DatabaseName. Please close any open editor for this database, check
your connection to this database, and refresh the database in Server Explorer". Well I didn't find any other open editor...What should I do?
Thanks!

Hi GSeriousB,
As per your description, you fail to add a table using visual studio 2013. Please help to post the full error messages.
As my analysis, besides the reason that the login account has no permission to the specific database according to Uri’s post, the issue could be also caused by the SQL Server Data Tools (SSDT) query timeout.
To work around your issue, please make sure to provide your login account the permission to the database, such as ‘db_owner’ database role and increase SSDT query timeout value following the steps below:
1.In SSDT, from the Tools menu, select Options.
2.In the Options pane, expand Business Intelligence Designers.
3.Click the Query Timeout text box, and type the value for the number of seconds, such as 600 seconds.
For more information about the process, please refer to the article:
http://msdn.microsoft.com/en-us/library/bb895188(v=sql.120).aspx
Regards,
Michelle Li

Table Design Suggestions

I would like to request some design assistance/recommendations. We are using Oracle 9i (soon to go to 10g) with both a Delphi Client/Server front end and a VS .Net Web Application. Here is the scenario:
We have a contracts application used by the Air Force and they need to add much more detailed funding data about the contracts. Basically a contract can be funded by one or more funds types (imagine different checking accounts). These funds types can be broken out in a hierarchical manner. Here is an example:
Parent Fund
   Child Fund1
      Child Fund 2
         Child Fund 3
AFCEE
   AF BRAC Overhead
      Technical Assistance
      Program Management
   AF BRAC Project
      Base ABC
      Base DEF
      Base GHI
   AF Restore Act
      ERPIMS
      Technical Assistance
Air Force
   11WG
      AF O&M
         BA01
         BA02
      AF BRAC Project
         Base ABC
         Base DEF
         Base GHI
   ACC
      AF O&M
         BA01
         BA02
         BA03
         BA04
   AF BRAC Overhead
   AF BRAC Project
         Base ABC
         Base DEF
         Base GHIUsing the information above, Contract XYZ can receive Technical Assistance funding from the AFCEE/AF BRAC Overhead funding pool and also from the AFCEE/AF Restore Act funding pool.
When the Project Manager enters the data, initially they may only know they are getting AFCEE funds and later on find out exactly what kind it is. Also Sr. Management is going to want reports that aggregate the dollars by fund type and as you can see in the example above, there are 3 AF BRAC Project funds types each with a different parent. I am going to meet to get a few more details on the Sr. Management report requirements. By the way, there are just under 3000 fund type combinations currently identified but it could easily go over 5000.
I am considering two possible table designs for the lookup table to store this information.
DESIGN 1
Fund_Type_Seq          NUMBER          PK
Fund_Type_Code          VARCHAR2(25)     Not Null
Parent_Fund_Type_Code     VARCHAR2(25)     Null
Fund_Type_Desc          VARCHAR2(500)     Null
DESIGN 2
Fund_Type_Seq          NUMBER          PK
Fund_Type_Root          VARCHAR2(25)     Not Null
Fund_Type_Child1     VARCHAR2(25)     Null
Fund_Type_Child2     VARCHAR2(25)     Null
Fund_Type_Child3     VARCHAR2(25)     Null
DATA TABLE DESIGN (Design of table holding Fund Type data for a contract)
Contract_Seq          NUMBER          PK
Fund_Type_Seq          NUMBER          PK
Funded_Dollars          NUMBER(12,2)     Null
And a couple other columns always in data tables in our system.The reason for the DESIGN 2 is that from a UI perspective, just showing “AF BRAC Project” 3 times without showing its lineage (so to speak) will not be useful to the PM and I am not sure of how to display a fund types entire lineage using design 1 (Possibly using a tree view and using the Connect By Prior / Start With SQL command structure).
So…Any suggestions, recommendations (and telling them that they are insane, while tempting, is unfortunately, not an option).
Thanks
Richard Anderson

Thanks, I was leaning towards the first Design. What I was wondering about was exactly how to query the data. Basically we will have a Contract Table, the Contract_Funding table (a child to contract) and the VVL_Fund_Type table (the Design 1 table). The user will want to pick one or more fund_types as filters to the report. Here is one select statement I came up with (haven't tested it as there are no funding tables). Am I on the right track?
Select c.contract_number,
       c.contract_obligated_amount,
       c.contract_obligated_date,
       ft.Fund_Type_Code,
       cft.funded_dollars
from contract c,
     VVL_Fund_Type ft,
     Contract_Funding cft
where c.contract_seq = cft.contract_seq
and cft.funding_seq = ft.funding_seq
and ft.fund_type_code in (SELECT fund_type
      FROM VVL_Fund_Type
      start with fund_type in (select vft.fund_type_code
            from vvl_fund_type vft
            where vft.Parent_Fund_Type_Code = 'AF O&M'
            connect by Parent_Fund_Type_Code = prior Fund_Type_Code)
            OR
            Fund_Type_Code = 'AF O&M')The 'AF O&M' may actually be a whole set of fund types in which case I would have to use an " in ('xyz, 'abc', etc) clause. The real problem will be if they view the AF O&M code associated with the 11WG as different from the AF O&M code associated with ACC. If that is the case (and I am meeting tomorrow to find out), I haven't a clue as to how to write the query other than maybe using a fund_type_seq in (123, 8378, 2828, 2987) clause.
Thanks Richard Anderson

"Simple" table design?

I have a very simple table design I need to set up, yet every setting I've tried is vexing me.
Table requirements:
1. Header with bold white text and black fill
2. Alternating rows, every 2, after header of a different fill color
3. All table text, excluding header, of a specific style
4. Row strokes to be after every 2nd row, to separate the different fill colors
I set up the following:
A table style with the alternating 2 row fill colors, and row strokes as: Every other row, first 1 row weight 2 pt white, next 1 row weight 0 pt, white, SKIP FIRST 1 ROWS
A paragraph style for the table text to set the font attributes
This setup gives me exactly what I need, except it puts a black row stroke after my first row after the header. I just want the first row stroke to be after the 2nd row (or 3rd row, if you count the header). But it's like it keeps including the header.
ALSO:
I would like to be able to set the header, row heights, left indent, etc., for my tables, but there is nowhere to do that in the table style. Very frustrating, because you can do it manually in the toolbar or menu bars (table options that are not available in the style), and then it overrides your styles.
I have a feeling this may be based on not understanding how table style, paragraph style, cell style and character styles, along with their "based on" settings coincide, but there are far too many combinations of those for me to grasp at this time.
Thanks for any help.
Mike

Figured it out, but I'd still like to know how to adjust ROW HEIGHT and COLUMN WIDTH in my table styles. It appears that if you highlight a row or table, and then change those settings in the upper toolbar, that it does not affect the style. But that's an arduous manual way to have to do it. I would think these settings could be automated somehow. Thanks.

Fact table design advice

Good Morning All,
I'm working on developing a cube that measure's budget and actual cost for a customer that I'm working with. We have serveral dimensions that comes into play:
Organization - this dimension defines the various internal departments at the customer location where each department sets a budget or actual cost for each month.
DateTimePeriod - this dimension defines the transaction date when the budget or actual cost was recorded. This dimension contains year, quarter, month and day columns.
Expense Item - this dimension defines a specific expense item that a budget and actual cost is assigned too such as rent, utility, software licences,etc...
Cost Type - this dimension defines if the cost within the fact table is a budget or actual cost.
Within my fact table I store primary key fields values for each of the dimension table listed above. Included with this table is a cost column that represents the budget or actual cost. The problem that I'm having is....The budget cost and actual cost are seperate
records...For example, I have one record that has the budget cost and then I have another record that has the actual cost....
My feeling is that the budget and cost records should be store on same record instead of seperate records. Also I would like note we're using PerformancePoint to surface the cube data to the client and both the budget and cost needs to drill down to the
month level only for phase 1. I have a feeling that the customer would want in the in future to measure down to the day level...
So my question is....What is a better design:
Keeping the actual and budget costs within a fact table on seperate rows using the Cost Type dimension to identify if the cost is a budget cost or an actual cost or....
Keeping the actual and budget costs within a fact table on the same row and removing the need for a Cost Type dimension......
Please help...
Make sure you mark my reply as the answer if it had solved your request. Brandon M. Hunter MCTS - SharePoint 2010 Configuration

Why? Wouldn't be easier if I make a database change and add the budget and actual cost on the same row??What would be the advantage or disadvantage to your approach???
As per my experience, there could be more than one version of a budget value. Initially we start with budget for an account, and then have the actual for the same account for the same period. If we 100% sure that we get only these two versions (Budget and
Actual) then upto a certain point, two columns implementation is fine. What if the budget is revised, how do you hold it, adding another column? What if you need to maintain a forecast value for same account, same period, create another column for that? Considering
all accounting and budgeting scenario, I still suggest to have multiple rows for all these versions (or scenario, or cost type). Again, refer AdventureWorksDW for seeing this implementation.
Since you are going to build a cube from this, you can easily view accounts recorded like this (which is mostly viewed by business users when analysing accounts). It is an advantage too.
In terms of disadvantages, I see only one disadvantage which is storage cost.
Dinesh Priyankara
http://dinesql.blogspot.com/
Please use Mark as answer (Or Propose as answer) or Vote as helpful if the post is useful.

TABLE DESIGN

Similar Messages

Maybe you are looking for