I'm trying to produce a Dr-patient appointment system. So far I have four tables:-
Patient:- Doctor:- Appointment:- Availability:-
patientID doctorName time time
name room date doctorName
address patientID
doctorName
All relationships are 1 to manys, with the many side coming out of the appointment table.
Patient:- The table for patient details
Doctor:- The table for doctor details
Appointment:- the table for appointments
Availability:- The table which stores timeslots each doctor is available
However this is all relatively new stuff to me and I'm getting quite thrown. Firstly in the doctors table should I have a field for DoctorID and use that as a primary key instead of the doctors name? Even though there's only likely to ever be a handful of records in that table.
Secondly if I was to change to DoctorID in all tables instead of the doctorName would I still easily able to access the doctorsName if and when required? This part is what confuses me, maybe I'm just over thinking these things.
The reason I ask is for example say I was to produce a report of an appointment which showed the doctorID, I should be able to get the doctors name for the report based on the relationship right? Likewise for the patient based on patient ID.
I'm guessing I also have enough information in the tables to check against and prevent appointment clashes.
Many thanks,
You really should use a doctorsid instead of a doctorsName. Because if you are planing to join these tables together then it is much better to join on ints then on varchars.
And another question if you are still going with the varchar solution what will happened if the doctor change its name (marriage or so). The you need to update the realted tables and the doctor table. If you then are going with the int you just have to change it in one place (the doctor table)
Yes and when you are going to produce you appointment report. You need to get the doctors name by joining the tables.
So your table structure should look something like this:
Patient:- Doctor:- Appointment:- Availability:-
patientID DoctorId AppointmentTime AvailabilityTime
PatientName room AppointmentDate DoctorId
address doctorName patientID
DoctorId
Related
Let's assume I am building the backend of a university management software.
I have a users table with the following columns:
id
name
birthday
last_english_grade
last_it_grade
profs table columns:
id
name
birthday
I'd like to have a third table with which I can determine all professors teaching a student.
So I'd like to assign multiple teachers to each student.
Those Professors may change any time.
New students may be added any time too.
What's the best way to achieve this?
The canonical way to do this would be to introduce a third junction table, which exists mainly to relate users to professors:
users_profs (
user_id,
prof_id,
PRIMARY KEY (user_id, prof_id)
)
The primary key of this junction table is the combination of a user and professor ID. Note that this table is fairly lean, and avoids the problem of repeating metadata for a given user or professor. Rather, user/professor information remains in your two original tables, and does not get repeated.
I had a very big excel spreadsheet that I moved into Access to try to deal with it easier. I'm very much a novice. I'm trying to use SQL via Access.
I need to assign a unique identifier to duplicates. I've seen people use DENSE_RANK in SQL but I can't get it to work in Access.
Here's what I'm trying to do: I have a large amount of patient and sample data (20k rows). My columns are called FULL_NAME, SAMPLE_NUM, and DATE_REC. Some patients have come in more than once and have multiple samples. I want to give each patient a unique ID that I want to call PATIENT_ID.
I can't figure out how to do this, aside from typing it out on each row. I would greatly appreciate help as I really don't know what I'm doing and there is no one at my work who can help.
To illustrate the previous answers' textual explanation, consider the following SQL action queries which can be run in an Access query window one by one or as VBA string queries with DAO's CurrentDb.Execute or DoCmd.RunSQL. The ALTER statements can be done in MSAcecss.exe.
Create a Patients table (make-table query)
SELECT DISTINCT s.FULL_NAME INTO myPatientsTable
FROM mySamplesTable s
WHERE s.FULL_NAME IS NOT NULL;
Add an autonumber field to new Patients table as a Primary Key
ALTER TABLE myPatientsTable ADD COLUMN PATIENT_ID AUTOINCREMENT NOT NULL PRIMARY KEY;
Add a blank Patient_ID column to Samples table
ALTER TABLE mySamplesTable ADD COLUMN PATIENT_ID INTEGER;
Update Patient_ID Column in Samples table using FULL_NAME field
UPDATE mySamplesTable s
INNER JOIN myPatientsTable p
ON s.[FULL_NAME] = p.[FULL_NAME]
SET s.PATIENT_ID = p.PATIENT_ID;
Maintain third-norm principles of relational databases and remove FULL_NAME field from Samples table
ALTER TABLE mySamplesTable DROP COLUMN FULL_NAME;
Then in a separate query, add a foreign key constraint on PATIENT_ID
ALTER TABLE mySamplesTable
ADD CONSTRAINT PatientRelationship
FOREIGN KEY (PATIENT_ID)
REFERENCES myPatientsTable (PATIENT_ID);
Sounds like FULL_NAME is currently the unique identifier. However, names make very poor unique identifiers and name parts should be in separate fields. Are you sure you don't have multiple patients with same name, e.g. John Smith?
You need a PatientInfo table and then the SampleData table. Do a query that pulls DISTINCT patient info (apparently this is only one field - FULL_NAME) and create a table that generates unique ID with autonumber field. Then build a query that joins tables on the two FULL_Name fields and updates a new field in SampleData called PatientID. Delete the FULL_Name field from SampleData.
The command to number rows in your table is [1]
ALTER TABLE MyTable ADD COLUMN ID AUTOINCREMENT;
Anyway as June7 pointed out it might not be a good idea to combine records just based on patient name as there might be duplicates. Better way will be treat each record as unique patient for now and have a way to fix patient ID when patient comes back. I would suggest to go this way:
create two new columns in your samples table
ID with autoincrement as per query above
patientID where you will copy values from ID column - for now they will be same. But in future they will diverge
copy columns patientID and patientName into separate table patients
now you can delete patientName column from samples table
add column imported to patients table to indicate, that there might be some other records that belong to this patient.
when patients come back you open his record, update all other info like address, phone, ... and look for all possible samples record that belong to him. If so, then fix patient id in those records.
Now you can switch imported indicator because this patient data are up to date.
After fixing patientID for samples records. You will end up with patients with no record in samples table. So you can go and delete them.
Unless you already have a natural key you will be corrupting this data when you run the distinct query and build a key from it. From your posting I would guess a natural key would be SAMPLE_NUM. Another problem is that if you roll up by last name you will almost certainly be combining different patients into one.
I have two tables DOCTORS and PATIENTS. I want both the doctors and the patients to have contact information (such as telephone numbers, addresses and so on) that aren't fixed. For example we can add multiple phones to either a doctor or a patient.
I thought about creating a separate table e.g. PHONES with fields phoneID, the phone number and a foreign key that points to a contact, such as below:
PHONES
phoneID [pk]
number
contactID [fk]
DOCTORS
docID [pk]
fname
sname
specialization
.
.
.
PATIENTS
patID [pk]
fname
sname
.
.
.
The first problem comes from the fact that the patID and the docID might (and will eventually) have the same value. So relating a phone to one and only one person becomes more difficult.
So far I've thought three possible solutions:
Have custom format primary keys for the doctors and patients. For example doctors could have ids in the form of "d00001", "d00002" and so on, and patients ids like "p00001", "p00002". My concern is this could complicate things unnecessarily.
Another solution would be to keep both doctors and patients in one table, and define if they are a doctor or a patient by using another field.
Create separate PHONE tables for doctors and patients, but that's even more clumsy.
Somehow I think both approaches are not the best. Any advice?
You could introduce a PERSON-table. This is 1:1 related to your doctors and patients (and later maybe to employees, suppliers, institutions, whatever). Let the contacts be related to this person-table.
Application code can model this with inheritance quite easily...
Within your person-table you keep some general information like DisplayName and PersonType (reference to a person-type-table with entries like Doctor, Patient and ...).
Keep this table slim...
If you have to choose out of your own ideas, I'd prefer the second. Keep them in one table and mark them with a type column. Avoid speaking keys...
You are thinking about the relationships wrong.
There is a many to many relationship between person and phone number.
A single person can have many different phone numbers (home, work, mobile, etc.)
A single phone number can be associated with many people (husband, wife, children, co-worker, ...)
I don't see why you need a primary entity with phone number as a primary or alternate key.
I would use 5 tables:
Doctor PK=DoctorID
Patient PK=PatientID
PhoneType PK=PhoneTypeCode
DoctorPhone PK=DoctorID,PhoneTypeCode,PhoneNum
FK1=Doctor.DoctorID
FK2=PhoneType.PhoneTypeCode
PatientPhone PK=PatientID,PhoneTypeCode,PhoneNum
FK1=Patient.PatientID
FK2=PhoneType.PhoneTypeCode
You might consider having distinct DoctorPhoneType and PatientPhoneType tables, given that the phone roles are likely to be different between the two classes of people.
(source: muchmore.url.ph)
Here's it is how I want to design my SQL database table for employee attendance record.
Is this a correct way to do it?
As we can see it goes on increases date column row from 01 Jan 2014 to 31 Dec 2014 also next years too. so is there any other solution for this?
You could do it in the following way
EmployeeMaster
EmployeeId int primary key
EmployeeCode nvarchar(20)
EmployeeName nvarchar(50)
AttendanceDetails
AttendanceDetailsId int primary key
EmployeeId int foreign key references EmployeeMaster Employee Id
DateofDay datetime
PresentAbsent bit
SalaryDetails
SalaryDetailsId
EmployeeId int foreign key references EmployeeMaster Employee Id
Salary float
While selecting and showing you can play with the records with joins.
you can pivot the records like Transpose in mathematics. There are plenty of ways to achieve it
Databases are designed to cope with large amounts of data. Don't worry about the number of rows in your table.
Make sure you can access all the data with efficient queries, this will be much better than fewer rows
Write some ideas down of how you want to access your data, e.g:
Was EmployeeX in on Week2
Recalculate the number of days in a month
How many days off were sick days/holiday
Then work out what table structures you need to support this with simple queries
For the three above it becomes quite clear that your proposed table structure is going to make your SQL difficult.
Something more like EmployeeID | Date | Hours | Expected Hours | Absence Reason Might be more effective
Yes. Your table is in de-normalized form. This is not a correct way to design database. Try to normalize. Split this table into several tables with proper relationships. Search for normalization, learn how to do it.
For example, You shouldn't keep Leave details and salary details along with attendance. Employee can be related with attendance, leave and salary tables by his ID while Employee details will be a separate Table which contains Employee's personal details.
You can do some thing like this:
EmployeeMaster{EmpID,FirstName,LastName,Address1,Address2,Address3,Address4,ContactNo,JoinnedDate}
SalaryMaster{EmpID, Basic, Variable, Allowance, Bonus, EPF,TAX}
LeaveMaster{ LeaveID,EmpID,StartDate,EndDate,Type,NoOfHalfDays)
Attendance { AttID, DateTimePunchedIn,DateTimePunchedOut}
I have a table with a number of course details with the following structure
CourseName
BasicInfo
CourseDetails
OtherInfo
AgeGroup
StartDate
There are a number of courses which have the same CourseName and BasicInfo, CourseDetails but seperate Age and StartDate. The course name for every record already exists but the BasicInfo and CourseDetails is empty.
I have created a form for the user to enter the details. So they get to the first course and enter the details. What I need then is for them to be able to then copy those two fields into each of the records where the CourseName matches.
For the life of me I can't figure out how to do that. Any help would be greatfully appreciated.
If you repeat the same basicInfo and courseDetails multiple times, you should consider putting that information in a seperate table. That way you could include that information every time the course gets selected, and changes only need to be made in 1 place. I don't know what you are trying to achieve, but I think the following structure should send you in the right direction:
Table: Course
id (PK)
courseName
basicInfo
courseDetails
Table: CourseDate
Id (PK)
startDate
courseId (FK)
I hope this helps you at least a little bit. Not sure if I interpreted your question a 100% correct though.
Edited after OP commented.