I'm taking a DBMS course and I need to design and build my own DB. I have a database for a hospital where doctors,nurses,support staff etc are in a ISA relationship to an Employee entity with the rest of the data like the name, address , salary and the rest of the employee data.
Designing a form, I want to be able to add an employee with all of their data in one form.
Is there a way to do a "conditional table" of sorts where if i select "doctor" from a drop-down i get to add to the doctor table too, and same for the rest of the entities under the ISA relationship?
Thx!
As a general rule, when dealing with data, you do NOT flip or switch tables for a given form or relatonal database design.
So, for example. If I have a table of customers. Well, now if I want to mark some of the customers as plumbers, and others as doctors? I don't create two tables.
All I would do is add ONE column to that customers table and it would simply allow me to set the type of customer. The reason for this design is "many" but some significant reasons are:
For each new type of customer, you would not create a new table. Worse, all of the forms, the reports, the SQL, the code you write? Well, all of that code would have to be modified EACH time you create a new table. So, you SIMPLY cannot adopt a design in which the concept of changing a table is part of that process.
Forms are bound to ONE table. For related data, you in most cases will use a sub form.
So, think of even a accounting system. They can have huge numbers of customers, and as a result, you can "query" that table to give you all customers. Or you might ask how many accounting firms are in the customer list. Or make a report that summeries by customer type a "count" of each type of customer.
So, buidling forms, or reports? They cannot on the fly "change" the tables they are using.
So, in place of a tables called:
SalesJan
SalesFeb
SalesMar
etc.
Well, now you can't query sales from Jan to mar, because the data is in different tables.
So, what you do is have ONE table called "sales", and you add ONE column of the date. Now, at the start of each new month, you don't have to create a new table.
Now, of course in some cases it makes sense to create a separate table. For example, a table of customers, and a table of employees in a database is just fine. It makes sense in this case to use two tables, since the information about a customer and what they can do and the kind of information is VERY different then how you would deal with employees.
So, with above? Well, if I need to print mailing labels for all customers and all employees? That would require two different reports. And very likely the table structure for the two tables is different.
Bottom line:
If you working on design or form or report? And you needing to try and change the table that the form/report/code etc is going to operate on? This is a sign that your design approach has gone complete off the rails and is the wrong design.
So, in the case of doctors, nurses etc.? Well, they are all hospital staff, and MOST of the basic information about such employees will be common, much the same, and thus a SINGLE table of "employees" makes the most sense. You would only need a nice "employee type" combo box on that one form, and thus you can add/enter/edit/search any employee in that one table.
The fact that you "want to search" for a employee show that all these people "are" employees and thus belong in one table. And the basic information about all employees is going to be the same anyway. If you find you are attempting to create a new table but with near identical structures over and over, then just like a new table for each month sales, or a new table for each new kind of employee? Simply add the "one" column that allows you to make that distinguish, and not a whole new table.
Now one COULD even attempt to put patients in the same table, but then again, dealing with patents as opposed employees is a considerable different kind of "thing".
So employees are employees - even different kinds. (manager, cleaning staff etc.).
And patients are patients - even different kinds (long term care, emergency etc.).
I have just started a course on database design and have been given a homework where one of the tasks is to list all the entity types of a fictional hospital according to this pdf: http://docdro.id/mbzdtUg.
I am struggling to figure out what should be an entity type and what should not. I will give you a basic example:
"Staff" is obviously an entity type but each of the staff have to have details regarding their qualifications and work experience. Since a staff member can have multiple qualifications and multiple work experiences these cannot be attributes... right? So should "Staff Qualification" and "Staff Work experience" be an entity type?
According to entity definitions I have read entities should be independent and represent objects that actually exist. What does it mean for an entity to be independent exactly? The "Staff Qualification" and "Staff Work experience" entity types would not exist if the entity type "Staff" didn't exist. Therefore they aren't independent (???) nor do they represent something that exists (physical object). Then what are they if not entity types? Should for example "Appointment" be an entity type? I am really confused... any help is appreciated.
Thanks!
EDIT: Should mention that this should be following a Entity-Relationship model (ER)
EDIT 2: Example 2: A patient can be either a outpatient or a inpatient. Should I make these into 2 entity type or only 1 (Patient)?
Looks like you're on the right track and your understanding is correct. If you foresee that Staff table can have multiple qualifications or work experiences - then qualification and work experience itself should be separated into a different entity table, so should the Appointment.
This is also where the normalization comes into place - because you could have two different staff members have the same work experience (or qualification) - then technically you don't want to just simply have a child table for Staff as that would result in a lot of data duplication. Usually, using normalization principles you would instead create a separate entity table WorkExperience where you would have all your different WorkExperiences. There would be no relationship between Staff and WorkExperiences tables. But you would also create StaffWorkExperiences table (joining table/buffer table), which would be a child of Staff (1:M) , but would also have a constraint to WorkExperiences table (M:1). So essentially you would end up with Staff table linking to StaffWorkExperiences table and the StaffWorkExperiences table in turn linking to WorkExperiences table.
Lastly, if you also have a patient table and the patient can be either outpatient or an inpatient - then that is more like a property and there is no need to have an extra table - so you would have only a patient table and then another column (PatientType or something like that) to describe this particular property.
EDIT
I have added an example schema of how this would look like with a joining table.
Anyway. Here's the database design I made. tblGets is my bridge entity between tblStudent and tblOffense though I am not quite sure with my table as of now seeing that it's not in its Third Normal Form (3NF). I can't shake the feeling that my Adviser attribute is dependent upon the Section attribute and the Section attribute is dependent upon Student_ID. So is it best to split the Adviser attribute as an attribute in another table thus creating another many-to-many relationship therefore producing another bridge entity?
Thanks in advance.
To truly normalize the data you could add tables for
1) Section (assuming this is some organizational construct for students)
and
2) Advisor.
The foreign keys for Section and Advisor tables are input in the student table. Section and Advisor tables then get their own ID fields plus section/advisor name.
I imagine Student - Advisor would be many-to-one (many students to one advisor) and section would be many-to-many.
I am modeling a new database and I have a problem to keep my db scheme generic in order to make it able to be updated in the future.
I have drawn a simple scheme which reflects the actual problem, let's say that I have an employee table which has all the common info from all employees. In addition, there are one table per possible assignment which all needs an employee with its custom columns. The business logic allows an employee to have different assignments.
What is the best way to bind each pk of different assignment tables into another table (in this case the Notification table)?
I have three tables, one fact and two dimensions. I want to make a referenced relationship between the fact table(measures) called InternetSales and the Geography table, se image(schemaCubeStructure".
The intermediate table is Customer. I first create the Geography and InternetSales tables and then the Customer with a field from Geography to use later when creating the ref. rel.
Everything works fine until browsing the data in the cube (se image "errorBrowseSalesCube". If i don´t make the relationship between the two tables i get image "correctBrowseSalesCube" which is what i want. That is i don´t get any data when processing with the rel.ref.
See image "dimensionUsageSalesCube for rel.ref.
Why is that i don´t get any data?
correctBrowseSalesCube
errorBrowseSalesCube
dimensionUsageSalesCube
schemaCubeStructure
What fields did you use when setting up your reference dimension relationship between Georgaphy and Internet Sales?
The in the AdventureWorksDW database, the Georgaphy dimension is a snowflake off of Customer dimension. In the AdvWrks cube project, Microsoft includes the geography table and corresponding attributes in the customer ssas dimension (red boxes in screenshot below). However, they could have, as it looks like you are trying to do, simply added the GeographyKey to the customer dimension (red arrow in screenshot below)
This exposes the GeorgaphyKey field when creating the reference dimension relationship so that you can properly define the relationship between the intermediate dimension (customer) and the reference dimension (geography):
After that, you can properly browse the Internet Sales facts by Georgraphy dimension attribute (and user) hierarchies:
The correctBrowse sales cube can be easily explained. It means that the data is not calculated based on the Geography dimension and thus indicates that the connection between the Internet sales and the Geography is not correctly calculated.
I would suggest the following:
Try making the customer a Mesaure (or fact table). Do not rename it just make a measure i.e. the count of customers (can be used as a counter of customers/per region or can be invisible altogether).
Then The customer will appear as a measure in Dimension usage and then connect Geography to Internet sales via a many to many relation Using the customer measure table.