Im starting to learn how to work with database... i had a course in school about 5 years ago and i forgot almost everything. So im starting from 0. I have one project in my mind. A simple storage system for tires at a Vulcanizer(where you go and change tires when winter and summer comes).
So i have in mind 4 tables (client, car, tires, location). I have come up with an er diagram but i have problems with realtion between them. Can you please check if i am good so far? Or would you change something in my case?
More in picture
Looking at your ERD it mostly looks okay apart from the following:
You should have a foreign key location_id within your Tires table so that you know where the tire is stored. This would mean removing Tires_TiresID from your Location table. Unless i am misunderstood, the Client_ClientID is not-needed in the location table. This is because the location table should only hold information about the location its self i.e. address, contact details etc.
If I were you, i would do something along the lines of this:
I.E One Customer can have MANY vehicles.
One Vehicle can have MANY tire types.
One Location can have MANY inventory(tires).
One Tire can be in One Inventory line
Related
I am creating a Pharmacy Database in Access 2016. It is my school Project and first Database Project.
My first problem is that we know that a Pharmacist can have many Patients, so it means that the relationship between Pharmacist and Patient is one-to-many. So in order to create a one-to-many relation, I made Pharmacist_ID as Primary Key.
Now the problem is that we know that the relation of Address and Patient is one-to-one, so how can I accomplish this task?
Another problem is that I already have the address, the city and nationality which are linked with the Pharmacist_ID. Can I link these tables with Patient_ID?
I am confused because the data-type of Pharmacist_ID is Auto-Number. The Patient_ID of the first Patient will be 1 and then Pharmacist_ID of the first Pharmacist will also 1 so what will happen?
Again, I am on MS-Access 2016.
This is the Picture of The RelationShip and you can see the Details of my Tables
Regards,
Arslan Iftikhar
This is for Thomas G check it out Thomas do you think I am doing right or wrong
I will make below changes to Address table:
I will prefer creating one common table for Address which also has City and Nationality (for simplicity else link them like image 2 below)
Added field PID as Number where you can save Pharmacist or Patient ID
Added field Ptype as Number where to save value 1 when Pharmacist and 2 when patient, so we can easily differentiate using this field.
Image 1
Image 2
A few design mistakes in your approach.
I will list a few things I think about, and try to train you to raise the right questions.
My first problem is that we know that a Pharmacist can have many
Patients, so it means that the relationship between Pharmacist and
Patient is one-to-many
The first part is only partially correct, which makes the second part incorrect and might lead to a big design failure.
In a normal world:
a Pharmacist can have many Patients
a Patient can have many Pharmacists
Isn't it ?
Thus you have a m-to-m relationship. How do you solve this? With an intermediate table storing the relation between patients and pharmacists.
The only exception to this, is if you make your software for only one Pharmacist, then your 1-to-m approach will work, but then I dont see any reason to have a Phamarcist table :)
Now the problem is that we know that the relation of Address and
Patient is one-to-one, so how can I accomplish this task?
Are you really sure about this? What happens in such cases then:
Patients members of the same family (living in the same house).
Patients for which the billing address is not the same as home address.
Patients that are also Pharmacists.
Patients owning several houses.
Those are very common cases. If you go the 1-1, you'll end up with A LOT of doubles in your address table.
The REAL reason for which we almost always put addresses in seperate table, is that adresses are rarely one-to-one in information systems. If it was one-to-one, there would be no real reason to store them in additional tables.
I am confused because the data-type of Pharmacist_ID is Auto-Number.
The Patient_ID of the first Patient will be 1 and then Pharmacist_ID
of the first Pharmacist will also 1 so what will happen?
And that is a good question, which should have led you to the design mistake above. You should not have a 1-1 between address and something else (Patient or Pharmacist).
In your Patient AND Pharmacists tables, you should have an AddressID refering the ID in the address table. If you want to let the opportunity to the pharamacists to store:
Home Address
Billing Address
Holiday Address
Whatever additional address
You should either :
Create an AddressID field in your Patient (and eventually Pharmacist table) for each of the address types.
If you really have many types for your addresses, it's better to create an intermediate table handling m-to-m between address and Patient/Pharmacists, with at least a Type column in it.
Edit. Reactions on your new model.
I guess the point of your CITY table is to have a big list of cities? That you can use for comboboxes for instance? If you go that way, you might do the same for countries, or states/regions. That's fine, BUT : the city_id, (and eventually State_ID and Country_ID), should be part of the ADDRESS table. It doesnt make sense to have an address with only a street, house number and po box. That's incomplete, an address should also contain a zip code, city and country to be complete.
I am working on my final year project of bscs degree. I am struggling with the database design as I counter a problem of one to one relationship .I hope you will understand my problem and suggest me a finest solution.
There are three tables:
DomesticQuater(QuaterNo, Location, Address, AllocatedEmpID)
CommercialShops(ShopId, Location, ownername, ownernic)
ElectricMeter(meterno, meterphase)
Only one meter can be allocated to one User either DomesticQuater or commericalShops.
Now where should I place the foreign keys?
i think you should use the meter no as foreign key
for example
DomesticQuater(QuaterNo,meterno,Location,Address,AllocatedEmpID)
CommercialShops(ShopId,meterno,Location,ownername,ownernic)
ElectricMeter(meterno,meterphase)
so in this way against one meter no there will be one domestic user or a commerical user.
I try to design database which contains data about street parking. Parking have gps coordinates, time restriction by day, day of week rules (some days are permitted, other restricted), free or paid status. In the end, I need to do some queries that can specify parking by criteria.
For first overdraw I try to do something like this:
Pakring
-------
parkingId
Lat
Long
Days (1234567)
Time -- already here comes trouble
But it`s not normalized and quickly overflow database. How to design data in the best way?
Update For now I have two approaches
The first one is:
I try to use restrictions tables with many-to-many links.(This is example for days and months). But queries will be complicated and I don`t now how to link time with day.
The second approach is:
Using one restricted table with Type field, that will have priority. But this solution also not normalized.
Just to be clear what data I have.
PakingId Coords String Description(NO PARKING11:30AM TO 1PM THURS)
And I want to show user where he can find street parking by area, time and day.
Thanks to all for your help and time.
This seems like a difficult task. Just a few thoughts.
Are you only concerned with street parking? Parking houses have multiple floors so GPS coordinates won't work unless you stay on the streets.
What is the accuracy of the coordinates? Would it be easier to identify each parking space individually by some other standard. Like unique identifiers of the painted parking squares. (But what happens if people don't park into squares? Or the GPS coordinates accuraycy fails/is not exact enough because of illegal parking? Do you intend to keep records of the parking tickets too?)
Some thought for the tables or information you need to take into account:
time: opening hours, days
price: maybe a different price for different time intervals?
exceptions: holidays, maintenance (maybe not so important, you could just make parking space status active/inactive)
parking slot: id (GPS/random id), status
Three or four tables above could be linked by an intermediate table which reveals the properties of a parking space for every possible parking time (like a prototype for all possible combinations). That information could be linked into another table where you keep records of a actual parking events (so you can for example keep records of people who have or have not paid their bills if you need to).
There are lots of stuff that affect your implementation so you really need to list all the rules of the parking space (and event?). Database structure can be done (and redone) later after you have an understanding of the properties of the events you need to keep records of. And thats the key to everything: understanding what you need to do so you can design and create the implementation. If the implementation (application) doesn't work change the implementation. If the design is faulty redesign. If you don't undestand the whole process (what you really need), everything you do is bound to fail. (Unless you are incredibly lucky but I wouldn't count on luck...)
Try using two tables with an intersection entity between them.
Table parking will have parking_id, lat and long columns. Table Restrictions will have all the type of restrictions that you have in your scenario with something like restriction_id, restriction_day, restriction_time and restriction_status and maybe restriction_type.
Then you can link the two tables with foreign key constraints in the intersection entity.
Example parking_id has restriction_id.
This way a parking can have more than one restriction and a restriction can be applied to more than one parking.
As you seem to have heard of normalization, and following the comment from Damien, you should use different tables to represent different things.
You should then think about how to link those tables together, and in the process define the type of relationship between the 2. Could be one-to-one (this one is the one where you could be tempted to put everything in the same table, but a simple foreign key in a linked table is cleaner), one-to-many (this is where the trouble would begin if you put everything in one table, cause now there will be several lines in the linked table with the same foreign key, and if everything was in the same table, you'd have to myltiply the fields in that table), or many to many (where you would need to add a table only to make the link between 2 other tables, thus with 2 foreign key fields pointing to records in both tables).
For example, in your case, a Parking table could hold the parking name, coordinates, etc.
A second table TimeTable could hold the opening days/time for each parking, with a foreign key to the parkingId (making it a one-to-many rlationship, 1 parking can have many opening frames). The fields of this table could for example be DayOfWeek (number indicating the day), openingTime, closingTime. This would allow you to define several timeframes on the same day, or a single one (if it's always open for example), giving in this case 7 records in this table for this parking (=> one-to-many relationship).
You could then imagine a 3rd table Price where you put data concerning the price of that parking (probably a one-to-many too, with records for hourly rates/long stay/..., and so on depending on the needs and the different "objects" you would need to represent.
Please note these are only rough examples. Database design can sometimes be very tricky and that's a matter I'm not specialist in, but I think these advises can help you go further and come back with another question if you get stuck.
Good luck !
My spider sense is tingling, but I've been thinking about it for 2 hours now and I'd like some more feedback from the hivemind.
I'm creating an application for a school. Its supposed to handle students, teachers, courses, honor roles, grades - the works.
I was wondering how to handle the change of years after each year.
Students move up a grade (or don't).
Teachers are assigned to different grades as their homeroom teacher.
Grades are saved for the year.
There's also the matter of auditing. I need to have an easy way to pull up records from last year or the year before. See what teacher gave which course at what grade at what year.
The problem I'm having is how to handle this.
My thought was to create a new clean database for each year as they come along. So at the end of this year, I'd go to the school and create a new database for them named FooSchool2012 and programatically let the end users change the database they want to use via a connection string.
Since I'm using an ORM it's only a matter of changing the connection string as the databases are the same.
But this reeks of bad design and crappy engineering to me.
Usually my gut is right, so hopefully you guys can let me know of some alternatives on how to handle this.
No, I would not create a new table or database for each year. It breaks first normal form. Every table will be a duplicate except for the name. It's a poor design. And a maintenance headache. Who's going to create the new database, load the schema, and then change all the URLs? If you change the schema after a few years, will you have to change all the back editions as well so people can query the historical data?
Nope, not a good design at all.
It's common to move historical information out into reporting/data warehousing databases. But the scheme you're suggesting is reminiscent of old, mainframe, VSAM flat file methodologies. I'd use relational databases the way they were intended to be used.
I'm sure your solution could be made workable, but it does seem a little needlessly complicated. Couldn't you accomplish the same thing in a single database by referencing the school year? You may want to think about which entities make sense to have "effective dates" (i.e., a start and an end time). The 3rd grade teacher may change mid year, for example, but you could handle that with effective dates.
My thought was to create a new clean
database for each year
If you thought about this for two hours, and your best idea was to create a new database for each year, you're the wrong person to design this database.
That's an observation, not a criticism. You just need to learn a lot more of the fundamentals before you tackle a project like this one. You'll just get frustrated, and the school will suffer.
You need to spend A LOT of time on your database design. Think about maintenance in the long run, it needs to be as easy as possible. The best way is to create a relational database, research bridge,validation, and base tables. To answer your question, I would not do a table for every year. The best way is having the student grade data mapped to a specific unique id representing that student's specific course ID.
I would think about creating a table for each of the nouns:
instructor - PK instructorID,instructorName..
(any other 1:1 instructor information)
Student - PK studentID,StudentName..
(any other 1:1 student information)
Course - PK CourseID, CourseName, CourseDescription..
(any other 1:1 course information)
•Teachers are assigned to different grades as their homeroom teacher.
on the 1:1 instructor table you could have a column called HomeroomGrade and then you
update that column with the current grade. If you wanted to keep a history of the grade
you could have the instructor table be a composite key with another column incrementing up
for the current record.
•Students move up a grade (or don't).
You will need another table showing the relationship of students to a unique courses
grades for that year, but first you need to map the instructor to that specific course.
PK InstructorToCourseID
InstructorID - FK
CourseID - FK
Year - FK
then yet another table mapping the unique course to that student with the grade..
PK InstructorToCourseID FK from previous table
PK StudentID - FK from student information table
Grade
Sorry if im general and vague, but this should give you some ideas on the relationships that can be created.
Full disclosure...Trying feverishly here to learn more about databases so I am putting in the time and also tried to get this answer from the source to no avail.
Barry Williams from databaseanswers has this schema posted.
Clients and Fees Schema
I am trying to understand the split of address tables in this schema. Its clear to me that the Addresses table contains the details of a given address. The Client_Addresses and Staff_Addresses tables are what gets me.
1) I understand the use of Primary Foreign Keys as shown but I was under the assumption that when these are used you don't have a resident Primary Key in that same table (date_address_from in this case). Can someone explain the reasoning for both and put it into words how this actually works out?
2) Why would you use date_address_from as the primary key instead of something like client_address_id as the PK? What if someone enters two addresses in one day would there be conflicts in his design? If so or if not, what?
3) Along the lines of normalization...Since both date_address_from and date_address_to are the same in the Client_Addresses and Staff_Addresses table should those fields just not be included in the main Address table?
Evaluation
First an Audit, then the specific answers.
This is not a Data Model. This is not a Database. It is a bucket of fish, with each fish drawn as a rectangle, and where the fins of one fish are caught in the the gills of another, there is a line. There are masses of duplication, as well as masses of missing elements. It is completely unworthy of using as an example to learn anything about database design from.
There is no Normalisation at all; the files are very incomplete (see Mike's answer, there are a hundred more problem like that). The other_details and eg.s crack me up. Each element needs to be identified and stored: StreetNo, ApartmentNo, StreetName, StreetType, etc. not line_1_number_street, which is a group.
Customer and Staff should be normalised into a Person table, with all the elements identified.
And yes, if Customer can be either a Person or an Organisation, then a supertype-subtype structure is required to support that correctly.
So what this really is, the technically accurate terms, is a bunch of flat files, with descriptions for groups of fields. Light years distant from a database or a relational one. Not ready for evaluation or inspection, let alone building something with. In a Relational Data Model, that would be approximately 35 normalised tables, with no duplicated columns.
Barry has (wait for it) over 500 "schemas" on the web. The moment you try to use a second "schema", you will find that (a) they are completely different in terms of use and purpose (b) there is no commonality between them (c) let's say there was a customer file in both; they would be different forms of customer files.
He needs to Normalise the entire single "schema" first,
then present the single normlaised data model in 500 sections or subject areas.
I have written to him about it. No response.
It is important to note also, that he has used some unrecognisable diagramming convention. The problem with these nice interesting pictures is that they convey some things but they do not convey the important things about a database or a design. It is no surprise that a learner is confused; it is not clear to experienced database professionals. There is a reason why there is a standard for modelling Relational databases, and for the notation in Data Models: they convey all the details and subtleties of the design.
There is a lot that Barry has not read about yet: naming conventions; relations; cardinality; etc, too many to list.
The web is full of rubbish, anyone can "publish". There are millions of good- and bad-looking "designs" out there, that are not worth looking at. Or worse, if you look, you will learn completely incorrect methods of "design". In terms of learning about databases and database design, you are best advised to find someone qualified, with demonstrated capability, and learn from them.
Answer
He is using composite keys without spelling it out. The PK for client_addresses is client_id, address_id, date_address_from). That is not a bad key, evidently he expects to record addresses forever.
The notion of keeping addresses in a separate file is a good one, but he has not provided any of the fields required to store normalised addresses, so the "schema" will end up with complete duplication of addresses; in which case, he could remove addresses, and put the lines back in the client and staff files, along with their other_details, and remove three files that serve absolutely no purpose other than occupying disk space.
You are thinking about Associative Tables, which resolve the many-to-many relations in Databases. Yes, there, the columns are only the PKs of the two parent tables. These are not Associative Tables or files; they contain data fields.
It is not the PK, it is the third element of the PK.
The notion of a person being registered at more than one address in a single day is not reasonable; just count the one address they slept the most at.
Others have answered that.
Do not expect to identify any evidence of databases or design or Normalisation in this diagram.
1) In each of those tables the primary key is a compound key consisting of three attributes: (staff_id, address_id, date_address_from) and (client_id, address_id, date_address_from). This presumably means that the mapping of clients/staff to addresses is expected to change over time and that the history of those changes is preserved.
2) There's no obvious reason to create a new "id" attribute in those tables. The compound key does the job adequately. Why would you want to create the same address twice for the same client on the same date? If you did then that might be a reason to modify the design but that seems like an unlikely requirement.
3) No. The apparent purpose is that they are the applicable dates for the mapping of address to client/staff - not dates applicable to the address alone.
3) Along the lines of
normalization...Since both
date_address_from and date_address_to
are the same in the Client_Addresses
and Staff_Addresses table should those
fields just not be included in the
main Address table?
No. But you did find a problem.
The designer has decided that clients and staff are two utterly different things. By "utterly different", I mean they have no attributes in common.
That's not true, is it? Both clients and staff have addresses. I'm sure most of them have telephones, too.
Imagine that someone on staff is also a client. How many places is that person's name stored? That person's address? Can you hear Mr. Rogers in the background saying, "Can you spell 'update anomaly'? . . . I knew you could."
The problem is that the designer was thinking of clients and staff as different kinds of people. They're not. "Client" describes a business relationship between a service provider (usually, that is, not a retailer) and a customer, which might be either a person or a company. "Staff" describes a employment relationship between a company and a person. Not different kinds of people--different kinds of relationships.
Can you see how to fix that?
This 2 extra tables enables you to have address history per one person.
You can have them both in one table, but since staff and client are separated, it is better to separate them as well (b/c client id =1 and staff id =1 can't be used on the same table of address).
there is no "single" solution to a design problem, you can use 1 person table and then add a column to different between staff and client. BUT The major Idea is that the DB should be clear, readable and efficient, and not to save tables.
about 2 - the pk is combined, both clientID, AddressID and from.
so if someone lives 6 month in the states, then 6 month in Israel, and then back to the states, to the same address - you need only 2 address in address table, and 3 in the client_address.
The idea of heaving the from_Date as part of the key is right, although it doesn't guaranty data integrity - as you also need manually to check that there isn't overlapping dates between records of the same person.
about 3 - no (look at 2).
Viewing the data model, i think:
1) PF means that the field is both part of the primary key of the table and foreign key with other table.
2) In the same way, the primary key of Staff_Addresses is {staff_id,address_id,date_adderess_from} not just date_adderess_from
3) The same that 2)
In reference to Staff_Addresses table, the Primary Key on date_address_from basically prevents a record with the same staff_id/address_id entered more than once. Now, i'm no DBA, but i like my PKs to be integers or guids for performance reasons/faster indexing. If i were to do this i would make a new column, say, Staff_Address_Id and make it the PK column and put a unique constraint on staff_id/address_id/date_address_from.
As for your last concern, Addresses table is really a generic address storage structure. It shouldn't care about date ranges during which someone resided there. It's better to be left to specific implementations of an address such as Client/Staff addresses.
Hope this helps a little.