I defined Master tables (data definition tables, static in nature) to generate content in my web page; and Transaction tables to store data entered by users (these tables are dynamic in nature). Consider following example:
Set of Master tables consisting of State having 1:M relationship with City, City having 1:M relationship with Locality. A Transaction table User to store personal details entered by a user. The User table has address attributes like Address, State, City and Locality. These can be defined as 1:M relationships from corresponding Master Tables (a particular record in State, City, Locality tables can be a part of multiple records in User table).
Is the design correct? I think it's sufficient to define 1:M relationship between Locality and User tables since the other two attributes (City and State) can be obtained from relationships between the Master tables. Would it be better to change the ER design to the following?
Are there alternatives to my requirement?
What queries do you have? Do you ever need to search by state or city? Even if you do search by those, it may not impact what I am about to say...
Since locality, city, and state are 'nested' and it is not likely for the names to change, I suggest that both of your options are "over-normalized". One table with all three items in it is the way I would go.
As I see it, there are two main reasons for normalizing:
Locating some string that is likely to change. By putting it in a separate table and pointing to that table, you can change it on only one place. This is not needed in your example.
Saving space (hence providing speed, etc). This does apply in your example, but only at the locality level, not at address. You might argue that city and state can be dedupped; I would counter with "The added complexity (extra tables) does not warrant the minimal benefit.".
A side note: If locality is zipcode, then your option 1 is in trouble at least one place I know of: Los Altos and Los Altos Hills (two different cities in California) both have sections of zipcodes 94022 and 94024.
Related
My application has users and properties, both of which can have addresses. This application is also going to be heavily analytical, and we will need to be able to grab all addresses that belong to a specific city, zip, county, or state.
Storing Countries, States, and Counties is easy, because a state belongs to exactly 1 country, and a county belongs to exactly 1 state.
However, when storing zip codes and cities, the problem becomes a bit more complex. A state can have multiple zip codes, and a zip code can belong to multiple states. A zip codes and cities can also belong to multiple states/counties. Heck, some cities and zips might not even belong to any counties like Washington, DC.
Is there an established database model I can use to ensure that I account for all edge cases, while at the same time allowing querying by each type?
However, when storing zip codes and cities, the problem becomes a bit
more complex.
Firstly you need to create Countries,cities,States and zip_codes.
It's obvious there is M:M relationship between States and Zip_codes entities, so you will need to create a new table and let us call it States_Zip_codes which comprises two foreign keys State_id FK and Zip_Id as FK.
A zip codes and cities can also belong to multiple states/counties.
In this case the relationship is one to many, so Zip_code_id (the primary key of Zip_codes table) is a FK in States table and so on.
I don't understand the nature of relation it's many to many or one to many
some cities and zips might not even belong to any counties like
Washington, DC
So in city_name field (property) it would be null
Hope that helps.
.
I am new in DB design,need advice to design correct number of tables and columns from excel sheet with this columns:
If multiple locations available or Foil is Y for a cardname then you see multiple rows for that cardname.
Identify the entities that your data model needs to represent.
An entity is briefly defined as: a person, place, thing, concept or event that can be uniquely identified, is important to the business, and we can store information about.
Also, identify the relationships between the entities.
The usual approach is consultation with the data owner/system owner; asking appropriate questions, throwing some ideas down in an entity relationship model, and asking further questions reviewing what is right about the model, and what isn't... altering and refining the model.
From the very brief description in the question, we would likely propose, as a starting point, some proposed entities: card and location.
Identify candidate keys:
What uniquely identifies a card?
What uniquely identifies a location?
Identify the cardinality of relationships (how many on each side of the relationship?
Can a location be related to more than one card?
Can a card have more than one location?
Must a card be related to a location (can we have a card that doesn't have a location?
etc.
Then, then assign the non-key attributes to the appropriate entities. Aim for third normal form.
"Each attribute is dependent on the key, the whole key, and nothing but the key. So help me Codd."
I'm designing a database that holds information on suppliers, clients, users, client sites etc that all have address data. I have elected to use three standard address lines, town/city, county and postcode fields.
My question is, would it be better to have these fields in all the tables that require them or have a address table and just link the address id to the relavent table?
Many Thanks
Gavin.
If it's possible for multiple fields to have the same address, I'd put the addresses in their own table. This helps prevent insertion/update anomalies, among other things. If every address is unique, it might not be that important.
In general, a rule of thumb is "never repeat data". So, if multiple rows have the same values, there's a chance those values can be moved into their own table.
I've a table of USERS in mysql that is in relation m:n with a CITY table.
User are 3 types identified by a field TYPE: regular, admin, super.
The regular user could be linked at maximum with 1 city.
The admin user could be linked at max just with 1 city.
The Super user is linked with all cities.
Is correct to store all 3 types of user in just one table and having n:m that for most user is just 1:m and just the SUPER USER is a pure n:m. is that the correct approach?
Personally, I don't think you need separate relational table (even if it is mostly good idea for future improvements, should you decide that user needs to connect to more than 1 city).
What I would do instead, is create city_id column in users table, and fill it accordingly. I am saying this because of the SUPER USERSs, as you call them. If you create separate relational table, it will have (number of super users) * (number of cities) entries, and since super user can see all cities, you would need to add (number of cities) rows to the table, each time you create a new user. Also, each time you create a new city, you would need to add (number of super users) rows to the relational table.
Instead, as I said, I would just use city_id in the users table, and if the user if super user then he sees all cities, and if not, only the city from city_id column.
This is just my personal preference.
Let me know what you think.
I am trying to determine how the tables need to be linked in which ways.
The employees tables is directly linked to a number of tables which provide more information. A few of those tables have even more details.
Employees have a unique employeeid but I understand best practice is to still have a id?
Customers have a unique customerid
Employees have a manager
Managers are employees
Customers have a manager associated with them. manager associated with them
Employees may have a academic, certification and/or professional information.
With all of this said what would be the best recommendation for creating primary and foreign keys? Is there a better way to handle the design?
EDIT
Updated diagram to reflect feedback thus far. See comments to understand changes taking place.
Though your question is sensible, before you go any further in design, I would suggest for you to spend some time understanding relationships, foreign keys and how they propagate through relationships.
The diagram is utterly wrong. It will help it you start naming primary keys with full name, TableNameID, like EmployeeID; then it will become obvious how keys propagate through relationships. If you had full names you would have noticed that all your arrows are pointing in the wrong direction; parent and child are reversed. Anyway, takes some practice. So I would suggest that you rework the diagram and post the new version, so that we can comment on that one. It should start looking something like this (just a small segment)
EDIT
This is supposed to point you to towards the next step. See if you can read description (specification) and follow the diagram at the same time.
Each employee has one manager, a manager manages many employees.
A manager is an employee.
Each customer is managed by an employee who acts as an account manager for that customer.
Account manages for a customer may change over time.
Each employee is a member of one team, each team has many employees.
Employee performance for each employee is tracked over time.
Employee may have many credentials, each credential belongs to one employee only.
Credential is academic or professional.
Employees have unique employeeID but I understand best practice is to
still have a id?
No. (But keep reading.) You need an id number in two cases: 1) when you don't have any other way to identify an entity, and 2) when you're trying to improve join performance. And that doesn't always work. ID numbers always require more joins, but when the critical information is carried in human-readable codes or in natural keys, you don't need a join to get to it. Also, routine use of ID numbers often introduces data integrity problems, because unique constraints on natural keys are often omitted. For example, USPS postal codes for state names are unique, but tables that use ID numbers instead of USPS postal codes often omit the unique constraint on that two-character column. In your case, you need a unique constraint on employee number regardless. (But keep reading.)
Employees have a manager.
Does the table "team" implement this requirement? If the "manager" table identifies managers, then your other manager columns should reference "manager". (In this diagram, that's customers, team, and customer_orders.)
Managers are employees.
And that information is stored in the table "manager"?
Customers have a manager associated with them.
And so does each order. Did you mean to do that?
Employees may have a academic, certification and/or professional
information.
But apparently you can't record any of that information unless you store a skill first. That doesn't sound like a good approach. Give it some more thought.
Whenever you design tables with overlapping predicates (overlapping meanings), you need to stop and sit on your hands for a few minutes. In this case, the predicates of the tables "employees" and "customers" overlap.
If employees can be customers, which is the case for almost every business, then you have set the stage for update anomalies. An employee's last name changes. Clearly, you must update "employees". But do you have to update "customers" too? How do you know? You can't really tell, because those two tables have independent id numbers.
An informal rule of thumb: if any real-world entity has more than one primary key identifying it in your database, you have a problem. In this case, an employee who is also a customer would have two independent primary keys identifying that person--an employee id and a customer id.
Consider adding a table of persons, some of whom will be employees, and some of whom will be customers. If your database is well-designed and useful, I'll bet that later some of the persons will be prospects, some will be job applicants, and so on. You will need an id number for persons, because in the most general case all you can count on knowing is their name.
At some point, you'll have to take your database design knowledge to the next level. For an early start, read this article on people's names.