here,i have seen diagram in which there is no primary key for entity.
in this diagram,item's order_level and price has no primary key.if there is not primary key then it is how to show in data dictionary?
It's one of:
1.) All attributes combined are it's primary key
2.) It's a weak identity and the diagram you are showing is incomplete
3.) The diagram is wrong/not showing the primary key. (Seen this many times in textbooks where ER diagrams are explained by example and the key is often missing if it's not needed to explain whatever.)
Related
I defined a field of unique IDs as primary key. I retrieve them from an external application in the form of a string: "q:x:y:z", q x y and z all being being hex values
I currently store them as TEXT. I also use them in link-tables for n-n relationships.
I could split it and make them all ints and create a compound primary key.
How would a TEXT field PRIMARY KEY perform against a compound PRIMARY KEY of (INT1, INT2, INT3, INT4)? I could test this myself, but it involves a bit of setup. It would be really helpful to get input from people with hands-on experience. To give you an indication of size, I'm talking at most a few dozen million records, the (only theoretical) maximum being 500.000^2.
Showing Foreign key in the ER diagram is Valid or not?
I am showing the foreign key in erd, is this correct?
ER is a conceptual model and it have entity types connected by relationes, it never shows a foreign key.
I am having some confusion on how to determine a primary key in regards to an ERD model.
Say for example,
I created the following table to keep track of employees salary.
Sal_His(Emp#, Salary, Reason, Raise-Date)
How would I determine which key would become the primary key?
A primary key can also be a combination of multilple fields.
In your case, Emp# and Raise-Date together might form the primary key.
EDIT At the logical level, those two fields form a compound primary key. That primary key indentifies uniquely each row of the table (unless an employee can have multiple raises per day) and is irreducible because none of those fields alone is sufficient to uniquely identify your records.
When you get to the physical level, you might want to introduce a surrogate primary Key (an ID) and create a unique index on the two columns (RaiseDate, Emp#).
You can find more information about the benefits and drawbacks of this approach here.
I only use primary key integer ID for it's "auto-increment function".
What if I don't need an "auto-increment"? Do I still need primary key if I don't care the uniqueness of record?
Example: Lets compare this table:
create table if not exists `table1`
(
name text primary key,
tel text,
address text
);
with this:
create table if not exists `table2`
(
name text,
tel text,
address text
);
table1 applies primary key and table2 don't. Is there any bad thing happen to table2?
I don't need the record to be unique.
SQLite is a relational database system. So it's all about relations. You build relations between tables on keys.
You can have tables without a primary key; it is not necessary for a table to have a primary key. But you will almost always want a primary key to show what makes a record unique in that table and to build relations.
In your example, what would it mean to have two identical records? They would mean the same person, no? Then how would you count how many persons named Anna are in the database? If you count five, how many of them are unique, how many are mere duplicates? Such queries can be done properly, but get overly complicated because of the lacking primary key. And how would you build relations, say the cars a person drives? You would have a car table and then how to link it to the persons table in your example?
There are cases when you want a table without a primary key. These are usually log tables and the like. They are rare. Whenever you are creating a table without a primary key, ask yourself why this is the case. Maybe you are about to build something messy ;-)
You get auto-incrementing primary keys only when a column is declared as INTEGER PRIMARY KEY; other data types result in plain primary keys.
You are not required to declare a PRIMARY KEY.
But even if you do not do this, there will be some column(s) used to identify and look up records.
The PRIMARY KEY declaration helps to document this, enforces uniqueness, and optimizes lookups through the implicit index.
I am using ASP.NET and the Entity Framework to make a website. I currently have a map table for a many to many relationship between... let's say users and soccer teams. So:
Users
Teams
UserTeams
Part 1: Is it best practice to use a composite key for the primary key of the map table? In other words:
UserTeams table
PK UserId
PK TeamId
PreferenceId
Part 2: The caveat is that I also have another table. Let's call it "UserTeamPredictions" that stores the user's predictions for a given team for each year. That table has a foreign key that points back to the map table. So it looks something like this:
UserTeamPredictions table
PK UserTeamPredictionId
FK UserId
FK TeamId
Prediction
PredictionYear
This seems to work fine in the Entity Framework, however, I have had some problems when referencing relationships in third-party controls that I use like Telerik. Even though it might not be the ideal data setup, should I change the table structure/relationships so that its easier to work with in the code with data binding and other things?
The change would be to add an integer primary key to the UserTeams map table, allowing the UserTeamPredictions table to reference the key directly, instead of through the composite key as it currently does:
UserTeams table
PK UserTeamId
FK UserId
FK TeamId
PreferenceId
UserTeamPredictions table
PK UserTeamPredictionId
FK UserTeamId
Prediction
PredictionYear
What do you think!?
You should change it. Search stack overflow for discussions on "natural keys" - it's almost universally agreed that surrogate keys are better, especially when using entity generation. Natural or composite keys do not play well with entity framework style DAL layers in general. For example, Lightspeed and Subsonic both require that you have a single unique column as a PK... Lightspeed in it's current version even goes so far to insist that your column is called "Id", although that will be changing next version.
I would choose not to. I would use a surrogate key and put a unique index on the UserId and TeamId columns. I get really sick of composite keys when there are more than two, and rather than have a mix of composite and surrogate keys, I choose to go with all surrogate, meaningless autoincrement keys wherever possible.
This has the bonus of giving you good performance on joins, and means you always know the key for a given table (table name + ID), without having to reference the schema. Some ORM tools only work properly with single column rather than composite keys, too.