I have created my first database in Access for a colleague, the purpose of this database is to allow my colleague to search for an individual that has skills/coverage in three key areas (Expertise Area, Industry Coverage,and Geographic Coverage). The database contains the following 5 Tables
Key Personal (KP) Table
Organisation Table
Area of Expertise Coverage
Geographic Coverage Table
Industry Coverage
The Three tables (Area of Expertise, Geographic Coverage and Industry Coverage) have the same data structure an example using the Geographic Coverage is shown below:
ID - KPID - AreaName - GeoCoverage
1 - 1 - Melbourne - Yes
2 - 1 - Sydney - No
3 - 1 - Hobart - Yes
4 - 1 - Brisbane - Yes
This then repeats for each Key Personal
The Key Personal Table has the following structure:
KPID - KPName - OrgID
1 - John - 1
2 - James - 1
3 - Molly - 2
The Organisation Table has the following Structure
OrgID - OrgName
1 - Business 1
2 - Company 1
The Relationship between the Tables is shown below:
I have created a form to allow my Colleague to filter based on the three criteria, results are then shown in a sub-form, an example is shown in the picture below:
My question is whether there is a way to group the results by KPID, e.g. in the example above I have 12 lines for KP7 as they have Area of Expertise across multiple areas (and Area of Expertise has not been filtered for). This is only an issue when not all 3 criteria have been defined.
What i envisage this would look like is that KPID, Name and Organisation would be the top level line and then you could expand (using a + symbol) to view the various Area of Expertise of the individual.
As this is my first time using MS Access and creating a database any other comments/feedback around my database and data structure would be much appreciated.
When two tables in Access have one or more fields in common,you can embed the datasheet from one table in another. This is called Subdatasheet. And this Subdatasheets can be nested up to eight levels. Using this you can have subdatasheets for organization,Area of Expertise,Geographic Coverage and Industry Coverage.
for a way to create subdatasheet refer to below link:
Related
This is my db design:
Portfolio:
- id
- name
- invested
- total
- ...... etc
And my second table
Investments:
- id
- portfolio_id
- amount
--- etc
so according to the logic, a each user can have only one portfolio and each portfolio can have multiple investments:
So basically "portfolio" can have multiple investments and "investments" can also have multiple Portfolio right ? (each user have one Portfolio), thus should i use many to many or one to many ?
As each user have unique profile, investments relates to their profile alone ( it cant be accessed by others ) so should i use one to many here ?
Consider a Associative Entity to bridge between the two tables instead of relying on a many-to-many relationship.
This is useful if you you need to have an investment mapped to multiple portfolios, but to answer your question, if you did it this way, each investment could be linked to more than one portfolio, which does not make any sense. While it is possible for the same stock name to be invested, this would require a separate table for the investment_options, not the same exact investment linked to a different portfolio. Your table should not ever be many-to-many.
Since you said that each user has a unique profile, the correct answer for your problem would be to use a One-To-Many relationship, linking one Portfolio to many Investments.
This is a comment that doesn't fit in the comments section.
For the relationship to be many-to-many you'll need to add an extra table that represents the relationship. For example:
Portfolio:
- id
- name
- invested
- total
Portfolio_Investment:
- portfolio_id
- investment_id
Investments:
- id
- amount
Notice the column portfolio_id is not longer present in Investments.
This question already has answers here:
Native JSON support in MYSQL 5.7 : what are the pros and cons of JSON data type in MYSQL?
(5 answers)
json column vs multiple columns
(4 answers)
Closed 4 years ago.
What is the best way to implement information with a one to many relationship in a large automation system located on a local server?
Getting a report and record it is the most important point of the system.
For example, consider a travel agency that has several guides that perform one tour in week. To record the agency's information, best way is use three tables, one to store the agency's information and one to store personalized guide information and one to store relationship(one to many) but whit this way, changing the person's guide information that will perform a tour this week will change, so the report received from the system will also change. Another method of storing is to use a table, in which the agency's information is stored, and the person's information is also stored in a column in the json format.For example, consider the following table.
Agency Table:
agency_id | name | phone_number | address | guides_details (That information stored in this column is stored in json format like name, mobile and ....)
Now my question is:
Given the fact that the storage size for the project is not important (due to the use on the local server), is the second method suitable for large-scale information storage (archive)? Or, if there's another way to archive it, teach me please.
Generally, its a bad practice to store JSON data in a table if it can be expressed in a tabular format. The reason for this is because you would not be able to query those details in your database language with ease.
I would suggest the following tables:
Agency Table
agency_id | (any other static information)
Agency Details Table
agency_detail_id | agency_id | created_date | name | phone_number | address | (any other changeable details)
Guide Table
guide_id | (any other static information)
Guide Details Table
guide_detail_id | guide_id | created_date | phone | email | (any other changeable details)
Tour Table
tour_id | name | date | agency_detail_id | guide_detail_id
Reasoning:
The details table for agency and guide will allow you to keep different versions of each agency and guide for different tours and will allow you to preserve the ability to link the records back to which agency or guide the tour belongs to even if the details are different.
We have broken the guide details up into a table so that it can easily be queried against.
I´m new to database design and never took class on it, i have problem with structuring my database and assigning primary keys.
I have a list of cities, each city has 5 types of public transport. Each type of public transport has different ticket price, main station and CSV file with route coordinations etc. in every city. Then i need to daily calculate average cost of transportation in every city for each type of public transport based on route coordinations (distances), price, time it takes etc.
Table cities:
city (Primary key)
Table public transport:
city, type of transport, ticket price, main station, file1, file2
Table results:
city, type of transport, date, cost
How should i connect these tables (assuming their structure is right)? In table public transport, i think city should be foreign key but type of transport will repeat for every city so i dont think it can be primary key of this table - the same for table results.
The main idea is that you don't wish to repeat ya self. Not only is it an overhead but also it's quite error prone when you wish to change multiple entries that represent the same thing.
There are guidelines on database normalization which help you to ensure that your data is on a form that's easy to maintain and work with.
You don't need to become an expert in understanding which form does what, but being able to identify what should be kept separated is a must when it comes to database designing.
You should list what you know:
Different cities.
Different type of transport.
Different ticket prices.
Different stations.
If you create a separate table for all of those then it'll be easy to link them together in rows in a table that then represents something on a larger scale. Every entry should have a separate id that will be your primary key, you need to be able to allow e.g. multiple cities with the same name, thus not being able to hold a unique value if they are to be the primary key.
E.g. now it would be easy to identify routes for a city, there can be multiple routes in a city
route_id | city_id | route_name
1 2 test1
2 2 test2
You then could add another table that represent which kind of transport is tied with this specific kind of route.
route_id | transport_id
1 3
2 4
You're then able to create a new table that holds points of stations that are a part of your route and you can even identify whether it's a main route or not.
route_connected_id | route_id | station_id | main_route
1 1 2 1 // a main route
2 1 3 0 // not a main route
And it goes on and on, separating the most simple entries allows you to create complex relationships where all you have to do is link ids.
This is the basic idea which should hopefully get you started, whether you find it helpful or not then I recommend that you take a look on the reading material that I suggested, i.e. database normalization.
This is my first project outside of school so I'm rusty and lacking practice.
I want to create a database but I'm not sure if I'm doing ok so far. I need a little help with the reports table.
The situation:
The food bank has multiple agencies who hand out food
Each agency has to submit a report with how many families/people served from a long list of zip codes.
I thought of putting a fk on Report to Zips table. But will that make selecting multiple zips impossible?
Maybe I'm way off base. Does someone have a suggestion for me?
A better name for this table might be FoodService or something. I imagine the kind of reports you really want to end up are not just a single row in this table, so naming it Report is a bit confusing.
In any case, each Report is the unique combination of {Agency ID, ZIP code, Date} and of course Agency ID is a foreign key. The other columns in this table would be number of families and people served, as you've indicated. This means you'll have rows for each agency-ZIP-date combination like this:
Agency | ZIP | Date | FamiliesServed | PeopleServed
Agency A | 12345 | Jan-12 | 100 | 245
Agency A | 12340 | Jan-12 | 20 | 31
Agency B | 12345 | Jan-12 | 80 | 178
Agency B | 12340 | Jan-12 | 0 | 0
Are these totals also broken down by "program"? If so, program needs to be part of the primary key for this table. Otherwise, program doesn't belong here.
Finally, unless you're going to start storing data about the ZIP codes themselves, you don't need a table for ZIP codes.
Usually having orphan tables like "Food" is a sign something's missing. If there's that much data involved, you'd think it would link in to the order model in some capacity, or at the very least you'd have some kind of indication as to which agency stocks which kind of food.
What's curiously absent is how data like "families-served" is computed from this schema. There doesn't seem to be a source for this information, not even a "family served" record, or a spot for daily or weekly summaries to be put in and totalled.
A "Zips" table is only relevant if there is additional data that might be linked in by zip code. If you have a lat/long database or demographic data this would make sense. Having an actual foreign key is somewhat heavy handed, though. What if you don't know the zip? What if, for whatever reason, the zip is outside of the USA? How will you handle five and nine digit zip codes?
Since zips are not created by the user, the zips table is mostly auxiliary information that may or may not be referenced. This is a good candidate for an isolated "reference" table.
Remember that the structure of a diagram like this is largely influenced by the front-end of the application. If users are adding orders for food items, that translates into relationships between all three things. If agencies are producing reports based on daily activity logs, then once again you need relationships between those three entities.
The front end is usually based on use-cases, so be sure you're accommodating all of those that are relevant.
I have two types of job posts -- company job posts and project job posts. The following would be the input fields (on the front-end) for each:
*company*
- company name
- company location
- company description
*project*
- project name
- project location
- project description
- project type
What would be best database design for this -- one table, keeping all fields separate -
`job_post`
- company_name
- company_location
- company_description
- project_name
- project_description
- project_type
- project_location
One table combining the fields -
`job_post`
- name
- location
- description
- project_type
- is_company (i.e., whether a company (True) or project (False)
Or two tables, or something else? Why would that way be preferable over the other ways?
Depending on a lot of factors including the maximum size of this job, I would normalize the data even further than 2 separate tables, perhaps having a company name table, etc... as joining multiple tables results in much faster queries than one long never ending table full of all of your information. What if you want to add more fields to projects but not companies?
In short, I would definitely use multiple tables.
You have identified 3 major objects in your OP; the job, the project, and the company. Each of these objects will have their own attributes, none of which will are associated to the other objects, so I would recommend something akin to (demonstrative only):
job
id
name
company
id
name
project
id
name
link_job_company_project
job_id
company_id
project_id
This type of schema will allow you to add object specific attributes without affecting the other objects, yet combine them all together via the linking table into a 'job post'.
This surely got to do with volume of data stored in the table . In an abstract view one table looks pretty simple . But as Ryan says what if requirements change tomorrow and more columns to be added for one type either company or project. If you are with the prediction that large amount of data top be stored in the table in future even I will prefer 2 tables which will avoid unnecessary filtering of large amount of data which is a performance overhead.